Автоматический ремонт для кластеров Together GPU: от сбоя GPU до исправного узла

В масштабах кластера сбои GPU — это суровая реальность. Ошибка Xid, двухбитовая ошибка ECC, выпадение GPU из шины PCIe или нестабильное соединение InfiniBand могут остановить распределенное обучение или вывести из строя инференс-реплику. Обнаружить, что что-то пошло не так, обычно проще всего. Самое сложное — это все этапы между моментом сбоя и возвращением узла в исправное состояние.

Ранее в этом году мы объявили о запуске функций полностью автоматического восстановления узлов. Клиенты наших кластеров GPU и наша собственная платформа инференса используют эту возможность для повышения отказоустойчивости рабочих нагрузок и минимизации времени простоя. Нашим клиентам очень нравится эта функция, и мы решили подробно разобрать систему, чтобы объяснить, как она работает и почему мы спроектировали ее именно так.

Сначала мы внедрили систему проверок «пассивного состояния здоровья», которая непрерывно следит за каждым узлом как внутри вашей виртуальной машины, так и на хосте под ней. Когда проверка обнаруживает сбой, авторемонт рекомендует наиболее щадящее действие для его устранения и показывает сопутствующие доказательства, на которых основана эта рекомендация. Вы заранее, сбой за сбоем, решаете, будет ли исправление ждать одобрения или выполнится автоматически. Вы также определяете, как долго авторемонт будет ждать завершения работающей рабочей нагрузки. Ваши собственные детекторы могут инициировать ремонт через тот же конвейер, записав всего одну аннотацию на узле.

ДоступностьВ настоящее время общедоступны: пассивные проверки состояния, рекомендации по ремонту, политика автовосстановления (включая согласие для каждого сбоя и узла), элементы управления ожиданием простоя, лестница эскалации, защитные механизмы, а также ремонт через API и консоль.Предварительная версия: контракты на восстановление на основе меток узлов, которые позволяют использовать собственные системы обнаружения, такие как NVSentinel или пользовательские контроллеры.Мы постоянно добавляем новые сигналы обнаружения и действия по восстановлению, чтобы обеспечить максимальное покрытие и минимальное время восстановления.

Почему состояния NotReady недостаточно

Большинство систем авторемонта узлов ориентируются на один сигнал: узел перешел в состояние NotReady. Этот сигнал выглядит одинаково независимо от того, сломан узел или просто временно недоступен. Когда событие в системе хранения или сети затрагивает множество узлов одновременно, каждый затронутый узел переходит в состояние NotReady. В нашу систему встроен предохранитель, предотвращающий массовую замену узлов. Кроме того, состояние NotReady не объясняет причину сбоя узла, поэтому нет оснований выбирать между перезагрузкой и заменой машины.

Поэтому авторемонт подчиняется одному правилу: никакой ремонт узла не происходит без предшествующей неудачной проверки состояния, и каждое исправление сопровождается подтверждающими данными.

Конвейер

Конвейер состоит из четырех этапов: обнаружение сбоя, принятие решения о том, нужно ли и когда действовать, ремонт узла и повторная проверка машины. Первые три этапа выполняются в вашем кластере. Четвертый этап выполняется на нашей стороне, на физическом хосте, который ваш узел только что освободил. Запросы на основе меток узлов от ваших собственных инструментов обнаружения поступают на этап принятия решений и обрабатываются точно так же, как и наши.

1. Обнаружение с обеих сторон гипервизора

Графические процессоры в кластерах Together GPU пробрасываются напрямую в вашу виртуальную машину для достижения производительности «голого железа» (bare-metal). Это означает, что сбои GPU видны изнутри виртуальной машины, в то время как сбои хоста и фабрики видны со стороны хоста. Таким образом, обнаружение работает по обе стороны гипервизора и стекается в единый центр.

Внутри вашей виртуальной машины экспортеры отслеживают:

• лог ядра — на предмет ошибок Xid и выпадения GPU из шины PCIe;
• DCGM — на предмет двухбитовых ошибок ECC, сбоев переназначения строк (row-remap), частоты повтора PCIe и теплового троттлинга;
• Node Problem Detector — на предмет доступных только для чтения файловых систем, аварийных остановок XFS, зависаний ядра и повторяющихся перезапусков kubelet или containerd.

В Slurm экспортер сообщает об узлах, отмеченных как DOWN или DRAIN.

На стороне хоста мы отслеживаем состояние линий InfiniBand и их нестабильность (flapping), связывая их с виртуальной машиной, которой принадлежат эти линии. Мы также проверяем доступность хоста, поэтому неработающий хост отображается как проблема на вашем узле, а не как молчание системы.

Каждое оповещение передает стабильную сводку, описание на понятном языке и машиночитаемый набор данных с доказательствами. Для ошибки Xid это каждый код и его мнемоника NVIDIA. Для теплового троттлинга — пиковая температура и количество срабатываний троттлинга. Плоскость управления передает эти строки в неизменном виде, поэтому консоль, API (в поле linked_alerts) и ваши уведомления всегда говорят одно и то же.

Мы разделяем наблюдаемое и то, с чем можно действовать. Каждое оповещение, имеющее отношение к ремонту, записывается и помечает ваш узел как Degraded (деградировавший). Только сигналы с сопоставленным действием инициируют ремонт. Нехватка места на диске, например, фиксируется, но не вызывает перезагрузку, потому что перезагрузка ее не исправит. Оповещение без сопоставленного действия подсчитывается и заносится в лог (оно никогда не отбрасывается молча) и направляется нашей службе поддержки для расследования.

2. Политика: мы решаем что, вы решаете — что и когда

Категория «Что» находится в ведении платформы. Каждый сигнал сопоставляется с наиболее мягким действием, которое его исправляет, поэтому вам никогда не придется гадать, какой код Xid что означает:

Категория «Что и когда» остается за вами. На вкладке «Ремонт» для политики автовосстановления по умолчанию установлено значение «Одобрять перед ремонтом» (Approve before repair): каждая рекомендация ожидает человека, который может принять или отклонить действие. Вы можете изменить значение по умолчанию на «Полностью автоматически» (Fully automatic), но это не глобальный переключатель. Чек-лист действий по ремонту группирует сбои по типу вызываемого ими ремонта, и вы выбираете те, которым доверяете выполнение без участия оператора. Внутри группы Xid вы можете настроить согласие для каждого кода. Типичная конфигурация автоматически одобряет перезагрузку для кодов Xid 119 и 95, но оставляет миграции требующими подтверждения. Чек-лист Xid также работает в режиме «Одобрять перед ремонтом», если вы хотите оставить короткий список сбоев для автоматического выполнения, в то время как все остальное ожидает вашего рассмотрения.

Категория «Когда» также остается за вами. Ремонт приводит к переводу узла в режим обслуживания (drain), поэтому функция «Ожидать простоя» (Wait for idle) удерживает узел до тех пор, пока он действительно не освободится. В Kubernetes это означает, что на узле нет работающих подов, запрашивающих GPU. В Slurm это означает, что планировщик сообщает об отсутствии выделенных ресурсов на узле. Максимальное время ожидания ограничивает эту задержку: по умолчанию оно составляет 2 часа с возможностью увеличения до 24. Опция «Не прерывать работающие задачи» (Do not interrupt running jobs) полностью снимает это ограничение. Установите время ожидания как минимум равным вашему интервалу создания контрольных точек (checkpoint interval). Если срок ожидания истекает, ремонт продолжается, а таймаут фиксируется в логах.

Каждое исправление фиксирует, кто его запросил (Together Health Checker для автоматического ремонта), кто его одобрил (имя пользователя или Auto-Approved), какое правило приняло решение и когда.

3. Использование собственного детектора

Команды, управляющие крупными парками графических процессоров, уже имеют системы обнаружения, которым они доверяют: панели мониторинга DCGM, NVSentinel, собственные сканеры, проверки на уровне заданий. Любое исправление, независимо от его источника, преобразуется в единую запись в нашей плоскости управления. Это дает проверкам емкости, аудиту и защитным механизмам единую точку сбора.

Существует три способа интеграции:

• API. Создайте запрос на ремонт экземпляра, указав режим, необязательный идентификатор от клиента для обеспечения идемпотентности и, при необходимости, выполненную проверку состояния или оповещение, на которое вы ссылаетесь в качестве доказательства. Вы также можете просматривать список, получать детальную информацию, одобрять, отклонять и отменять ремонт.
• Консоль. Меню ⋮ на любом узле открывает диалоговое окно «Ремонт» с обнаруженными проблемами и рекомендуемым действием.
• Метки узлов (Предварительная версия). Любой детектор с правами RBAC на запись метаданных узла может инициировать ремонт, добавив к узлу одну аннотацию и одну метку. Аннотация содержит имя детектора, стабильный идентификатор запроса, режим ремонта, время обнаружения сбоя и понятную человеку причину.

Наш оператор кластера проецирует метку узла вплоть до плоскости управления. Восстановление регистрируется с детектором в качестве внешнего инициатора, поэтому оно всегда имеет привязку к источнику и никогда не сможет выдать себя за пользователя. Имя детектора плюс идентификатор запроса составляют ключ идемпотентности во всем кластере (включая уже завершенные восстановления), поэтому детектор, который повторно заявляет о той же неисправности при каждом сканировании, не сможет перезагрузить узел дважды. Для авторизации используется собственная RBAC вашего кластера, без ключа API и тикетов на подключение.

Запросы на аннотации могут запрашивать Перезагрузку (Reboot), Быстрое пересоздание (Quick reprovision) или Миграцию (Migrate). Удаление (Remove) остается доступным только людям. Как и клик в консоли, эти запросы обходят очередь одобрения, но они по-прежнему проходят через тот же шлюз сбора доказательств, проверку емкости и бюджеты, что и все остальное. Ограничение на уровне кластера гарантирует, что сбойный детектор причинит лишь ограниченный ущерб, а не катастрофу.

4. Действия по восстановлению и лестница эскалации

Каждое восстановление проходит один и тот же жизненный цикл: перевод в режим изоляции (cordon), ожидание (согласно вашей политике), дренаж (drain), выполнение действия, возврат в пул (rejoin). В консоли отображается переход узла через этапы: Изоляция (Cordoning) → Дренаж (Draining) → Восстановление / Миграция (Repairing / Migrating) → Подключение (Joining) → Работа (Running).

Действия (от самых легких к самым тяжелым):

• Перезагрузка (Reboot). Перезапуск виртуальной машины на месте. Локальные данные /scratch и /tmp сохраняются.
• Быстрое пересоздание (Quick reprovision). Пересборка виртуальной машины из чистого образа на исправном хосте. Локальные данные теряются.
• Миграция на новый хост (Migrate to new host). Пересборка виртуальной машины на другом оборудовании и отправка старого хоста на повторную валидацию.
• Удаление (Remove). Извлечение узла для RMA. Всегда инициируется человеком.

Одинаковые исправления не повторяются по кругу. Если сбой возвращается на ту же машину после того, как аналогичное действие уже выполнялось дважды, следующая рекомендация поднимается на одну ступень выше. Третий цикл перезагрузок по коду Xid превращается в пересоздание, а третье пересоздание — в миграцию. Эта лестница отслеживается для каждой машины, кластера, предупреждения и кода Xid. Попытки старше недели не учитываются, как и отмененные или разрешенные самостоятельно рекомендации.

Миграции защищены проверкой доказательств. Миграция — это единственное действие, которое потребляет реальную емкость. Для него требуется либо критическое предупреждение, в настоящее время срабатывающее на узле, либо критическое предупреждение на той же машине в течение последних десяти дней. Запрос, не удовлетворяющий ни одному из этих условий, вместо этого выполняется как Быстрое пересоздание.

Цикл питания хоста (Предварительная версия). Некоторые неисправности, включая Xid 79, требуют отключения питания графического процессора, чего перезагрузка виртуальной машины сделать не может, даже если само железо исправно. Вместо того чтобы задействовать новый хост, мы можем перезапустить питание текущего, на котором вы находитесь. В системе отсутствуют какие-либо учетные данные BMC. Проверка ID загрузки предотвращает повторную попытку отключения питания хоста, который уже возобновил работу.

Кластеры, которым требуется гарантированное окно замены, могут зарезервировать емкость под горячие запасные узлы (hot spare), чтобы миграции производились из этого резерва, а не за счет общей доступности. Обратитесь к своей команде по работе с клиентами для получения подробностей.

5. Предохранители на случай шторма предупреждений

Сбойный выпуск драйвера, авария хранилища или разделение сети могут сделать десятки узлов выглядящими неисправными одновременно. Восстановление на уровне узла не может устранить причину на уровне кластера, поэтому механизмы защиты реализованы многоуровнево и независимо:

• Устойчивость (Persistence). Сигнал должен сохраняться в течение определенного для каждого сигнала времени, прежде чем он превратится в рекомендацию.
• Период ожидания (Cooldown). После любого восстановления узел получает примерно 30 минут покоя, прежде чем сможет быть сгенерирована новая рекомендация.
• Бюджет параллелизма (Concurrency budget). Бюджет рассчитывается исходя из количества узлов в кластере, и оператор выполняет только одно восстановление для каждого пула узлов за раз.
• Автоматический выключатель (Circuit breaker). Когда один кластер генерирует всплеск взаимосвязанных автоматических восстановлений, выключатель срабатывает. Множество одновременно отказывающих узлов указывает на проблему на уровне кластера, и восстановление узлов по одному ее не решит.
• Одна цель на одно восстановление (One target per repair). Схема обеспечивает соблюдение этого правила, поэтому ошибка не может распространиться веером по множеству узлов.
• Автоматическое разрешение (Auto-resolve). Рекомендация, предупреждение по которой исчезает до того, как кто-либо предпримет действия, пропадает сама по себе.

Плоскость управления реплицирована, и каждая операция записи идемпотентна и проверяется на соответствие ожидаемому состоянию. Две реплики, соревнующиеся за один и тот же узел, создают одно восстановление, а не два.

6. Машина проходит повторную валидацию самостоятельно

Когда узел мигрирует с машины или удаляется с нее, эта машина не должна сразу возвращаться в пул и не должна простаивать в очереди в ожидании, пока кто-то прочитает диагностику. Как только старая виртуальная машина исчезает, машина автоматически переходит в режим валидации. Тестовая виртуальная машина выполняет те же проверки GPU, NCCL, InfiniBand и хранилища, которые проходит абсолютно каждая новая машина перед добавлением в парк. Ни один человек не прикасается к машине в промежутке между уходом вашего узла и вынесением вердикта.

Существует три вердикта:

• Пройдено (Passed). Машина возвращается в пул. Тикет не создается, и никого не вызывают пейджером, поэтому временная неисправность остается временной.
• Не пройдено (Failed). Автоматически создается аппаратный тикет с прикрепленными результатами тестов по каждому пункту и логами. Машина остается вне пула до тех премен, пока ее не починят и она снова не пройдет проверку.
• Прервано (Aborted). Проверки не смогли выполниться, например, потому что хост был перераспределен или тестовая виртуальная машина не смогла разместиться. Машина восстанавливается в прежнее состояние, и никаких санкций к ней не применяется.

Тикет создается только при явном сбое.

Создано с расчетом на расширение за пределы одного ускорителя

Решения о восстановлении основываются на предупреждениях, узлах и машинах, а не на поставщике графического процессора. Тип GPU важен для размещения и емкости, но рекомендации, политика, эскалация, бюджеты, триггеры и повторная валидация не делают для него исключений. Специфичные для вендора компоненты — это обнаружение (экспортеры Xid и DCGM) и комплекс диагностических тестов. Подключение нового ускорителя означает добавление этих элементов, а все последующие компоненты остаются неизменными.

Использование

Откройте свой кластер в консоли и перейдите на вкладку Восстановления (Repairs). Там находятся ожидающие рекомендации и история, а вверху располагается политика автовосстановления (Auto-remediation policy). Каждое исправление в API содержит свои связанные предупреждения (linked_alerts), поэтому ваши собственные инструменты видят те же доказательства, что и консоль.

Что дальше

• Поддержка NVSwitch. Неисправности SXid, объединенные для каждого узла, с читаемыми описаниями.
• Статус обратно на узле. Ход восстановления записывается в метаданные узла, чтобы внешние детекторы могли замкнуть цикл там же, где они его открыли.
• Единое представление работоспособности. Переход по клику от неудачной проверки к вызванному ею восстановлению и обратно, а также представление работоспособности, событий и истории восстановления для каждого узла.

Расскажите нам о том, что выходит из строя в ваших кластерах и что мы пока не отслеживаем. Этот список определяет то, что мы будем создавать в следующем релизе.

-> Начать работу в консоли-> Документация: Восстановление узлов · Проверки работоспособности