Реагування на інциденти для GPU-кластерів: посібники для типових сценаріїв збоїв

Оновлено 8 грудня 2025 року

Оновлення грудня 2025: Збої рідинного охолодження тепер очолюють категорію інцидентів для сучасних GPU-кластерів — відмови CDU, виявлення витоків, проблеми з якістю охолоджувальної рідини. Простій H100/H200 коштує $25-40 тис. за GPU на день, що робить швидке реагування критично важливим. Платформи AIOps (PagerDuty, Datadog) інтегрують спеціалізовані для GPU інструкції. Фреймворки еластичного навчання зменшують зону ураження від збоїв GPU. Оптимізація частоти контрольних точок (10-15 хв) мінімізує втрати навчання від інцидентів.

Коли 500 GPU H100 раптово вимикаються під час критичного навчального прогону, кожна секунда коштує $1200 втраченого обчислювального часу. Коли рідинне охолодження виходить з ладу в GPU-кластері потужністю 2 МВт, температура підвищується на 1°C кожні 30 секунд до термічного відключення. Коли InfiniBand-фабрика розділяється під час розподіленого навчання, 10 000 GPU-годин обчислень стають марними. Ці сценарії вимагають точних, відрепетируваних реакцій, які мінімізують шкоду та швидко відновлюють роботу. Цей посібник надає перевірені на практиці інструкції для інцидентів з GPU-інфраструктурою.

Класифікація інцидентів та рівні серйозності

Інциденти з GPU-інфраструктурою вимагають спеціалізованих класифікацій серйозності, що виходять за межі традиційних IT-фреймворків. Інциденти рівня серйозності 1 (Критичний) включають повний збій кластера, ризик втрати даних або загрози безпеці, що впливають на понад 100 GPU або мають вплив $50 000 на годину. Вони викликають негайну ескалацію до керівництва, залучення постачальників та активацію цілодобового оперативного штабу. Навчання GPT-4 від OpenAI зазнало трьох інцидентів рівня серйозності 1 протягом шести місяців, кожен з яких вимагав залучення CEO через щоденні витрати на навчання в $2 мільйони.

Інциденти рівня серйозності 2 (Високий) впливають на 20-100 GPU або спричиняють 50% зниження продуктивності у більших кластерах. Цільовий час реагування — 15 хвилин із метою вирішення за 2 години. Ці інциденти зазвичай включають часткові відмови охолодження, проблеми з розподілом електроенергії або події розділення мережі. Інфраструктура Meta автоматично викликає чергових інженерів для подій рівня серйозності 2, з ескалацією до старших архітекторів після 30 хвилин без прогресу.

Інциденти рівня серйозності 3 (Середній) впливають на менш ніж 20 GPU або спричиняють 25% зниження продуктивності. Вони включають збої окремих вузлів, проблеми з драйверами або локалізовані мережеві проблеми. Цільовий час вирішення подовжується до 4 годин із прийнятним подальшим контролем наступного робочого дня. Автоматизовані системи обробляють 70% інцидентів рівня серйозності 3 без втручання людини через механізми самовідновлення.

Інциденти рівня серйозності 4 (Низький) включають збої одного GPU або незначні варіації продуктивності до 10%. Вони потрапляють у стандартні робочі процеси обробки заявок із цільовим часом вирішення 24 години. Інфраструктура Anthropic автоматично ізолює уражені ресурси, дозволяючи виробничим навантаженням продовжувати роботу, поки ремонт відбувається під час вікон технічного обслуговування.

Розрахунки фінансового впливу визначають присвоєння рівнів серйозності. Кожен GPU H100 представляє капітальні інвестиції в $30 000 з операційними витратами $50 на годину. Переривання навчання може знецінити дні обчислень вартістю мільйони. Lambda Labs розраховує вартість інциденту як: (уражені GPU × погодинна ставка × очікувана тривалість) + (час відновлення з контрольної точки × вартість кластера) + (штрафи за SLA). Ця формула спричинила класифікацію рівня серйозності 1 для збою 50 GPU через витрати на відновлення з контрольної точки в $500 000.

Процедури реагування на збої електроживлення

Сценарії повної втрати електроживлення вимагають негайного скидання навантаження для запобігання каскадних збоїв під час відновлення. Системи ДБЖ, що підтримують GPU-кластери, зазвичай забезпечують 5-7 хвилин роботи при повному навантаженні. Перші 30 секунд визначають траєкторію інциденту: автоматичні перемикачі резерву повинні спрацювати, генератори повинні запуститися, а системи охолодження повинні продовжувати роботу. Інструкція Microsoft ініціює автоматичне призупинення робочих навантажень протягом 10 секунд після виявлення події з електроживленням.

Фаза 1 (0-30 секунд) зосереджена на збереженні стану. Завдання розподіленого навчання повинні негайно створити контрольну точку, що вимагає попередньо налаштованих місць для контрольних точок з достатньою пропускною здатністю. Команда kubectl exec запускає екстрене створення контрольних точок у Kubernetes-подах. Системи зберігання переключаються в режим прямого запису, забезпечуючи збереження даних. Мережеве обладнання на окремих системах ДБЖ підтримує з'єднання для віддаленого управління.

Фаза 2 (30 секунд - 2 хвилини) включає пріоритезацію навантаження. Некритичні навантаження автоматично завершуються на основі класів пріоритету подів. Навантаження виведення продовжують обслуговування зі зниженою потужністю. Навчальні завдання зберігають стан і коректно завершуються. Системи охолодження зменшуються до мінімально життєздатної роботи, підтримуючи температуру нижче термічних лімітів. Системи управління електроживленням скидають 40% навантаження, подовжуючи час роботи ДБЖ до 15 хвилин.

Фаза 3 (2-5 хвилин) вимагає синхронізації генератора. Автоматичні перемикачі резерву синхронізують вихід генератора з системами ДБЖ перед передачею навантаження. Невдалі запуски генератора викликають негайну ескалацію з процедурами ручного запуску. Перевірка стану паливної системи забезпечує 24-годинну ємність роботи. Центри обробки даних Google підтримують 48-годинні запаси палива з автоматично активованими контрактами на дозаправку під час тривалих відключень.

Процедури відновлення починаються після повернення стабільного електроживлення. Поетапне відновлення запобігає одночасному пусковому струму, що перевантажує системи електроживлення. Системи зберігання ініціалізуються першими, потім мережева інфраструктура, потім обчислювальні вузли з кроком 10%. Ліміти потужності GPU тимчасово знижуються до 80% під час стабілізації. Повна потужність повертається після 30 хвилин стабільної роботи. Автоматизація відновлення CoreWeave повертає 1000 GPU у виробництво за 45 хвилин після відновлення електроживлення.

Реагування на збої системи охолодження

Збої рідинного охолодження ескалюються швидко, з температурою GPU, що зростає на 20°C за хвилину без активного охолодження. Негайне реагування викликає автоматичне обмеження частоти, зменшуючи виділення тепла на 40%. Команда nvidia-smi -pl 400 знижує потужність H100 з 700 Вт до 400 Вт, виграючи критичний час реагування. Міграція навантаження до незачеплених зон починається автоматично, поки ремонтні бригади мобілізуються.

Збої первинного контуру вимагають ізоляції уражених секцій при підтримці потоку до робочих зон. Байпасні клапани перенаправляють потік навколо несправних компонентів. Резервні насоси активуються, підтримуючи 60% потужності потоку. Збої CDU (блоку розподілу охолоджувача) викликають автоматичне перемикання на резервні блоки протягом 30 секунд. Системи RSD (Rack Scale Design) від Supermicro включають автоматизоване управління клапанами, що ізолює збої до окремих стійок.

Збої вторинного контуру між CDU та градирнями впливають на цілі об'єкти. Аварійні чилери активуються протягом 2 хвилин, забезпечуючи тимчасове відведення тепла. Персонал центру обробки даних вручну відкриває аварійну вентиляцію, випускаючи гаряче повітря безпосередньо назовні, незважаючи на втрати ефективності. Портативні охолоджувальні блоки розгортаються в критичних зонах протягом 30 хвилин. Об'єкт Facebook у Принвіллі підтримує 2 МВт потужності портативного охолодження для екстреного реагування.

Виявлення витоку запускає негайні протоколи ізоляції. Датчики води під стійками GPU активують соленоїдні клапани, зупиняючи потік протягом 500 мілісекунд. Уражені стійки автоматично вимикаються, підтримуючи мережеве з'єднання для віддаленої діагностики. Команди відновлення розгортають абсорбуючі матеріали та портативні осушувачі для запобігання корозії. Підводні центри обробки даних Microsoft використовують діелектричні охолоджувальні рідини, повністю усуваючи ризик пошкодження водою.

Додаткове повітряне охолодження підтримує системи рідинного охолодження під час часткових збоїв. Блоки CRAC (кондиціонування повітря комп'ютерних приміщень) збільшують вихідну потужність на 50%, компенсуючи знижену потужність рідинного охолодження. Системи ізоляції гарячих коридорів активуються, покращуючи ефективність охолодження на 20%. Тимчасові вентилятори розгортаються в критичних зонах, забезпечуючи точкове охолодження для перегрітих стійок. Ці заходи підтримують роботу протягом 4-6 годин, необхідних для ремонту рідинного охолодження.

Розділення мережі та втрата з'єднання

Розділення InfiniBand-фабрики миттєво руйнує ефективність розподіленого навчання. Автоматичне виявлення спрацьовує протягом 100 мілісекунд за допомогою heartbeat-сигналів менеджера підмережі. Уражені вузли автоматично ізолюються, запобігаючи частковим оновленням, що пошкоджують стан моделі. Планувальники завдань отримують оновлення топології, перерозподіляючи роботу на здорові розділи. Обробка помилок NCCL чисто завершує уражені колективні операції.

Відновлення вимагає систематичної реконструкції фабрики. Менеджер підмережі opensm перебудовує таблиці маршрутизації, виявляючи уцілілі шляхи. Часткова робота фабрики продовжується зі зниженою пропускною здатністю, поки тривають ремонтні роботи. Деградація ширини каналу з 4x до 2x підтримує з'єднання зі зниженням пропускної здатності на 50%. Інфраструктура EFA (Elastic Fabric Adapter) від Amazon автоматично маршрутизує навколо збоїв, підтримуючи 85% сукупної пропускної здатності під час збоїв одного комутатора.

Збої мережі Ethernet по-різному впливають на навантаження навчання та виведення. Конвергенція BGP (Border Gateway Protocol) завершується протягом 30 секунд для резервних шляхів. Маршрутизація ECMP (Equal-Cost Multi-Path) розподіляє трафік між уцілілими каналами. Пріоритезація трафіку зберігання забезпечує завершення операцій контрольних точок, незважаючи на знижену пропускну здатність. Політики Quality of Service гарантують 40% пропускної здатності для критичних операцій.

Повна ізоляція мережі запускає автономний режим роботи. Вузли продовжують локальні обчислення, буферизуючи результати. Завдання розподіленого навчання призупиняються на бар'єрах синхронізації, зберігаючи стан. Локальне NVMe-сховище буферизує до 1 ТБ даних контрольних точок в очікуванні відновлення з'єднання. Після відновлення мережі буферизовані дані автоматично синхронізуються, відновлюючи операції за хвилини, а не години перезапуску.

Збої DNS та виявлення сервісів перешкоджають плануванню навантажень, незважаючи на функціональну інфраструктуру. Резервні DNS-сервери активуються автоматично зі значеннями TTL (Time To Live) 15 секунд, що дозволяє швидкі оновлення. Поди Kubernetes CoreDNS перезапускаються на незачеплених вузлах протягом 30 секунд. Конфігурації статичних IP в аварійних інструкціях обходять DNS для критичного управлінського доступу. HashiCorp Consul забезпечує стійкість service mesh з автоматичним перемиканням для виявлення сервісів.

Запобігання каскадним збоям апаратного забезпечення

Збої одного GPU можуть каскадуватися через завдання розподіленого навчання, впливаючи на сотні пристроїв. Негайна ізоляція запобігає поширенню помилок. Команда nvidia-smi drain коректно видаляє GPU з пулів ресурсів. Плагіни пристроїв Kubernetes позначають несправні GPU як нездорові, запобігаючи плануванню нових подів. Працюючі навантаження мігрують на здорові ресурси протягом 2 хвилин.

Помилки пам'яті викликають прогресивні відповіді залежно від серйозності. Однобітові помилки, виправлені ECC, продовжують працювати зі збільшеною частотою моніторингу. Двобітові помилки спричиняють негайну міграцію навантаження та карантин GPU. Вичерпання виведення сторінок з експлуатації запускає планування заміни апаратного забезпечення. Автоматизовані системи замовлення підтримують 2% резервного інвентарю для швидкої заміни.

Збої блоків живлення в резервних конфігураціях продовжують працювати зі зниженою потужністю. Конфігурації N+1 втрачають резервування, але підтримують повну роботу. Балансування навантаження перерозподіляє споживання електроенергії між уцілілими блоками живлення. Ефективність знижується на 5-10%, збільшуючи виділення тепла. Планування заміни орієнтоване на 4-годинне реагування для відновлення резервування. Кластери Dojo від Tesla підтримують гарячі резервні блоки живлення, що дозволяють 5-хвилинну заміну.

Збої компонентів материнської плати вимагають ретельної діагностики для розрізнення ремонтопридатних від термінальних збоїв. Ретаймери PCIe іноді потребують переустановлення, відновлюючи роботу без заміни. Збої VRM (модуля регулятора напруги) можуть впливати на окремі GPU, поки інші продовжують працювати. Процедури відновлення BIOS відновлюють пошкоджену прошивку без заміни апаратного забезпечення. Інтегрована діагностика Dell EMC ідентифікує збої на рівні компонентів, дозволяючи цілеспрямований ремонт.

Запобігання тепловим каскадам вимагає агресивного втручання. Температура сусідніх GPU підвищується на 5-10°C, коли сусіди виходять з ладу. Перерозподіл навантаження запобігає утворенню гарячих точок. Порожні стійкові одиниці між несправним обладнанням покращують повітряний потік. Портативні точкові охолоджувачі розгортаються протягом 15 хвилин для критичних зон.

[Контент скорочено для перекладу]