Обновление драйверов и библиотек на сервере с ускорителями NVIDIA без остановки расчётов
Из чего состоит программный стек ускорителей, какие механизмы позволяют обновлять его без остановки узла, в каком порядке выполняются работы и что проверяется после.
Программная часть сервера с ускорителями состоит из нескольких слоёв: драйвер ядра, библиотеки вычислений, среда контейнеризации с поддержкой ускорителей, прикладные библиотеки обучения и инференса. Слои связаны требованиями к версиям, и обновление одного из них без учёта остальных останавливает расчёты на часы. При этом обновляться приходится регулярно: новые версии библиотек поддерживают новые типы данных и дают прирост производительности на том же оборудовании.
Ниже — из чего состоит программный стек ускорителей NVIDIA, какие механизмы позволяют обновлять его без остановки узла, в каком порядке выполняются работы и что закладывается в регламент обслуживания парка.
Слои программного обеспечения и их связи
| Слой | Что делает | Чем ограничена версия | Требует ли перезагрузки |
|---|---|---|---|
| Драйвер ядра | Доступ к устройству, распределение памяти, планирование | Версией ядра операционной системы | Не всегда — есть механизм обновления без перезагрузки |
| Библиотека вычислений | Программный интерфейс к ускорителю | Минимальной версией драйвера | Нет |
| Библиотеки линейной алгебры и свёрток | Ускоренные операции обучения и инференса | Версией библиотеки вычислений | Нет |
| Средства работы с контейнерами | Проброс устройства в контейнер | Версией драйвера и среды выполнения | Перезапуск службы |
| Библиотека межузлового обмена | Обмен между ускорителями и узлами | Драйвером и сетевым стеком | Перезапуск задачи |
| Прикладные библиотеки | Обучение и инференс моделей | Версиями нижележащих библиотек | Нет |
Ключевое свойство стека — совместимость снизу вверх ограниченного диапазона. Библиотека вычислений работает с драйвером не ниже определённой версии, но не требует точного совпадения. Это и даёт основной приём: драйвер обновляется реже, прикладные библиотеки — чаще, и большая часть обновлений выполняется без вмешательства в ядро.
Приёмы, позволяющие не останавливать расчёты
- Разделение обновлений по слоям. Прикладные библиотеки и библиотеки вычислений обновляются в образе контейнера, а драйвер на узле остаётся прежним. Задача запускается с новым образом, узел при этом не трогается.
- Совместимость драйвера в пределах ветки. Внутри одной ветки драйвера прикладной код перекомпиляции не требует. Это позволяет планировать обновление драйвера отдельно и редко.
- Обновление драйвера без перезагрузки. Модуль ядра выгружается и загружается заново при условии, что ни один процесс не удерживает устройство. Узел выводится из планировщика, дожидается завершения текущих задач, обновляется и возвращается в работу.
- Поочерёдное обслуживание узлов. В кластере узлы обновляются группами. Планировщик перестаёт направлять новые задачи на выводимую группу, текущие завершаются штатно.
- Контрольные точки в обучении. Длительное обучение сохраняет состояние с заданной периодичностью. Это делает перезапуск задачи недорогим и снимает требование к непрерывности узла.
- Разделение парка на группы. Часть узлов держится на проверенной версии стека, часть — на новой. Так новая версия проверяется на фактической нагрузке без риска для всего парка.
Порядок выполнения работ
- Сверка матрицы совместимости. До начала работ фиксируются текущие версии всех слоёв и целевые. Проверяется, что целевая версия прикладной библиотеки поддерживается целевой библиотекой вычислений, а та — целевым драйвером.
- Проверка на выделенном узле. Один узел выводится из работы, на нём разворачивается целевой стек, прогоняется контрольная задача с измерением времени и проверкой результата.
- Сравнение результатов. Сверяются не только скорость, но и числовые результаты: изменение версии библиотеки может изменить порядок операций и, соответственно, последние разряды результата.
- Вывод группы узлов. Планировщику запрещается назначать новые задачи, ожидается завершение текущих.
- Обновление и проверка. После обновления выполняется диагностика: видимость всех ускорителей, корректность топологии связей, отсутствие ошибок в журнале, пропускная способность между устройствами.
- Возврат в работу и наблюдение. Узлы возвращаются в планировщик, первые сутки отслеживаются частота ошибок и время выполнения типовых задач.
- План отката. Предыдущие версии сохраняются, порядок возврата описан заранее. Откат выполняется тем же способом, что и обновление.
Что проверяется после обновления
Диагностика узла после работ занимает минуты и снимает большую часть последующих вопросов:
- Все установленные ускорители видны, число совпадает с паспортным.
- Топология связей между устройствами соответствует схеме: прямые соединения не перешли в обмен через центральный процессор.
- Пропускная способность между устройствами и между узлами соответствует ожидаемой.
- Коррекция ошибок памяти включена, счётчики исправленных и неисправленных ошибок в норме.
- Ограничения по мощности и температурные пороги не изменились после обновления.
- Контрольная задача даёт прежний результат и сопоставимое время.
Как это закладывается в регламент
Обновление стека — плановая работа, и её частота согласуется с характером нагрузки. Практический подход для парка из нескольких узлов:
- Драйвер. Обновляется по необходимости — при переходе на новое поколение ускорителей, при исправлении значимых ошибок, при требовании новой библиотеки. Частота — несколько раз в год.
- Библиотеки вычислений и прикладные библиотеки. Обновляются через образы контейнеров, частота задаётся командами, которые ведут расчёты.
- Окно работ. Назначается на период низкой загрузки, длительность считается по самой долгой незавершённой задаче.
- Фиксация версий. Состав стека на каждом узле хранится в описании конфигурации, а не в памяти администратора.
Для парка со смешанным составом — например, когда рядом с ускорителями NVIDIA работают ускорители MetaX — стеки ведутся раздельно, и общий узел под оба типа устройств не собирается. Порядок реакции на отказ и состав работ по сопровождению входят в сервисное обслуживание.
Частые вопросы
Нужно ли перезагружать сервер при обновлении драйвера? Не всегда. Если ни один процесс не удерживает устройство, модуль ядра заменяется без перезагрузки. Перезагрузка потребуется при смене версии ядра операционной системы.
Можно ли держать разные версии библиотек для разных задач? Да, если задачи выполняются в контейнерах: каждая несёт свой набор библиотек, а драйвер на узле общий.
Что делать, если после обновления упала скорость? Сверить топологию связей и режим работы памяти, проверить ограничения по мощности и температуре, затем сравнить контрольную задачу с прежними измерениями. При подтверждённом падении выполняется откат по заранее описанному порядку.
Обязательно ли обновляться? Нет. Обновление оправдано приростом производительности, поддержкой новых типов данных или требованиями применяемых библиотек. Обновление без такой причины добавляет риск без выигрыша.
Как обновлять единственный сервер? Через контрольные точки в задачах и короткое окно работ. Для единственного узла план отката важнее, чем скорость обновления.
Что мы делаем
Поставляем ускорители NVIDIA и серверные платформы под них, проверяем совместимость с действующей платформой, собираем конфигурацию под задачу и сопровождаем парк — перечень работ в разделах подбора оборудования и сервиса. Материалы по инфраструктуре кластера собраны в блоге направления, остальные направления поставок — в перечне направлений.
Напишите на sale@tkasiatorg.ru состав парка и задачи, под которые он работает, — подберём конфигурацию и назовём сроки поставки.
