Mission Control 2.5 тянет автовосстановление на Kubernetes

В NVIDIA Mission Control 2.5 автономное восстановление, которое раньше жило рядом со Slurm, дошло до Kubernetes через планировщик Run:ai. Обучение на тысячах GPU — ставка уже не «подождём дежурного»: мониторинг и автоматизацию закладывают в кластер сразу, иначе сгорают недели прогонов. MTTR и MTBF в дата-центрах считали задолго до AI factory, но при таком масштабе цена простоя выше.

Run:ai планирует джобы в Kubernetes; поверх — два слоя Mission Control. Job recovery держит контекст задачи и решает, перезапустить её или перенести. Hardware recovery следит за нодами и GPU, уводит подозрительные узлы из пула и запускает диагностику. Слои разделены: планировщик может перекинуть нагрузку на живую ёмкость, не дожидаясь финального разбора причины.

Три сценария сбоя

• Отказ GPU при распределённом обучении — job recovery помечает узел, планировщик перезапускает или переносит задачу, hardware recovery параллельно изолирует ноду.
• Падение воркера или таймаут координации — повтор по политике планировщика без карантина здорового GPU.
• Повторяющиеся предупреждения по GPU или сети — узел снимают с допуска к новым тренировкам заранее.

Версия 2.5 уже доступна; для команд, где остаются и Slurm, и Kubernetes, заявлена одна модель recovery вместо отдельного сценария на каждый оркестратор.

Источник: How NVIDIA Mission Control 2.5 Brings Autonomous Recovery to Kubernetes.