«Резервный» блок питания сидел на том же вводе: разбор отключения

MAATRIX

У сервера было два блока питания, два кабеля, две маркировки на PDU — A и B. На бумаге и в презентации дата-центра это называлось «резервированное электропитание», и именно поэтому клиент выбрал именно эту площадку. А потом внешнее электричество пропало, и упало всё — оба блока питания одновременно, вместе с IPMI и вместе с соседними стойками в том же ряду. Ниже — разбор того, как выяснилось, что «резерв» был резервом только на бумаге, и что с этим можно сделать на стороне арендатора, если вы не можете залезть внутрь чужого дата-центра и перепаять шину.

Что случилось

Сервер стоял в колокейшене у стороннего дата-центра, арендованном через провайдера, у которого была официальная схема «двух независимых вводов» — то есть каждая стойка получает питание по двум разным линиям, A и B, каждая от своего распределительного щита, а в идеале — от разных подстанций или хотя бы разных высоковольтных фидеров. На сервере стоял блок питания с резервированием (redundant PSU): один шнур в PDU A, второй — в PDU B. Формально это ровно та конфигурация, которую советуют для отказоустойчивости — подробнее о том, зачем вообще нужен второй блок питания и что он реально резервирует, есть отдельный разбор: резервный блок питания и отказоустойчивость.

В момент, когда во внешней сети произошло отключение (авария на стороне энергоснабжающей организации, не у самого дата-центра), сервер должен был продолжить работать: пропадает внешнее электричество — ATS (автоматический ввод резерва) переключает нагрузку на дизель-генератор, ИБП тем временем держит нагрузку на аккумуляторах те несколько десятков секунд, пока генератор не выйдет на рабочий режим. Именно так устроен путь электричества в нормальном дата-центре, и если вам интересно, как это работает по шагам от ввода до розетки в стойке — есть отдельная статья: как устроен дата-центр: путь электричества.

Но сервер выключился. Полностью. Без graceful shutdown, без записи в syslog о падении напряжения — просто обрыв связи, как будто выдернули шнур из розетки. Причём не только сервер: IPMI/iDRAC тоже не отвечал, хотя эти интерфейсы обычно живут на отдельном низковольтном контуре и переживают перезагрузку основного питания сервера. Если недоступен даже IPMI — значит, пропало питание не на сервере, а на всей стойке или на её сегменте PDU.

Что показывали мониторинг и логи

Первый сигнал пришёл не с самого сервера — а из внешнего мониторинга, который держал независимый Uptime Kuma на другой площадке и опрашивал сервер по HTTP и по ICMP. Оба чек-пойнта легли в одну и ту же минуту. Дальше — тишина: ни ICMP-ответа, ни TCP-хэндшейка, ни ответа на IPMI по отдельному management-интерфейсу.

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

Провайдер дата-центра позже опубликовал технический статус-репорт (это стандартная практика у площадок, которые дорожат репутацией): внешнее электричество пропало на входном щите, ATS зафиксировал переключение, дизель-генератор запустился и вышел на рабочий режим — но часть нагрузки к этому моменту уже была обесточена и не «подхватилась» автоматически, потому что соответствующий сегмент распределения не был переключён на защищённый ввод.

Тут стоит сразу оговорить: точные тайминги переключения ATS, время выхода генератора на режим и то, сколько конкретно стоек не подхватилось — это внутренняя телеметрия дата-центра, у арендатора VPS или выделенного сервера к ней доступа обычно нет. Ориентируйтесь не на секунды из этого разбора (мы их не измеряли и не будем придумывать), а на саму структуру расследования — она универсальна для подобных инцидентов.

Первые гипотезы — и почему их отбросили

Когда падает сервер с резервированным питанием, разумно проверить по порядку несколько версий, от простой к сложной.

Гипотеза 1: сгорел один блок питания, а второй не справился с нагрузкой в одиночку. Отбрасывается быстро: если бы отказал один PSU, второй должен был продолжить питать сервер — именно для этого он и есть, redundant PSU рассчитан на полную нагрузку сервера в одиночку. К тому же упал не один сервер, а весь ряд стоек разных клиентов — совпадение отказа десятков независимых блоков питания в одну секунду статистически исключено.

Гипотеза 2: сработала защита по перегрузке (breaker trip) из-за скачка нагрузки. Тоже отбрасывается: перед падением не было роста потребления — ни на этом сервере, ни, судя по публичному статус-репорту, на других пострадавших стойках. Автомат срабатывает от превышения тока, а не просто так, и обычно задевает одну ветвь, а не целый ряд сразу.

Гипотеза 3: отказал ИБП (батарея разряжена или неисправна). Похоже на правду в первом приближении — ИБП действительно держит нагрузку на переходный период, пока не подключится генератор. Но эта версия не объясняет, почему часть стоек в том же машинном зале, формально запитанных от того же ИБП-парка, пережила отключение без проблем. Если бы дело было в самом ИБП как едином узле — легло бы либо всё, либо ничего, а не выборочно одни ряды.

Гипотеза 4 (рабочая): проблема не в оборудовании, а в топологии подключения конкретного сегмента. Она объясняет и «выборочность» (легли не все, а конкретные ряды), и синхронность (упало всё разом, а не по одному серверу), и отсутствие предвестников в метриках (нагрузка была нормальной вплоть до самого отключения).

Как нашли реальную причину: один луч на двоих

Дальше это уже не задача арендатора — это работа инженеров дата-центра, но результат расследования они раскрыли в постмортеме, и он поучителен. При плановых электромонтажных работах несколько месяцев назад часть распределительных щитов в одном из машинных залов перекоммутировали. По документации ввод B для этого ряда должен был идти от отдельного щита, защищённого генератором наравне с вводом A. По факту после перекоммутации кабель ввода B для нескольких PDU оказался заведён с той же секции щита, что и ввод A — то есть физически на один и тот же ввод, просто через разные автоматы.

Пока внешнее электричество было — разницы никто не видел: оба PDU получали напряжение, оба блока питания сервера работали, всё в мониторинге зелёное. Проблема не проявляется в нормальном режиме, она проявляется только в момент реального отключения внешнего фидера — именно тогда, когда резервирование и должно было сработать. Это классическая ловушка отказоустойчивости: система выглядит избыточной ровно до того момента, пока не понадобится её избыточность на практике.

По сути «резервный» блок питания на сервере был совершенно исправен, кабель был подключён, PDU B физически существовал и даже показывал напряжение — но electрически он не был независимым источником. Когда пропало внешнее электричество на этом вводе, пропало сразу и на A, и на B, потому что для конкретно этих стоек это был один и тот же ввод с двух разных розеток.

Почему так вообще возможно: как устроено резервирование питания

Стоит понимать, что «два блока питания» и «два PDU» — это ещё не резервирование по вводу. Полноценная схема резервирования электропитания в дата-центре обычно строится по нескольким уровням, и на каждом из них резерв можно случайно (или намеренно, экономя на инфраструктуре) свести к нулю:

Формальная классификация дата-центров по уровню отказоустойчивости (Tier по методологии Uptime Institute, от Tier I до Tier IV) как раз про это: чем выше уровень, тем строже требования к тому, что резервные пути должны быть по-настоящему независимыми и regularно проверяться отключением боевого ввода («pull the plug» тест). Дата-центр может официально продавать себя как площадку с резервированным питанием и при этом не иметь Tier III/IV сертификации именно потому, что резерв не тестировался живым отключением, а существовал только «на бумаге» и в схеме подключения.

Что изменили после инцидента — и что можно сделать со стороны арендатора

Провайдер дата-центра после разбора сделал то, что должен делать любой оператор в такой ситуации: провёл аудит физической топологии всех PDU в затронутых рядах, сверил фактическую разводку с проектной документацией, исправил перекоммутацию и — что важнее — ввёл регулярный тест переключения ATS с реальным (не имитационным) отключением одного из вводов на тестовом сегменте, чтобы подобные расхождения между схемой и реальностью не копились месяцами незамеченными.

Проблема в том, что вы как арендатор VPS или выделенного сервера физически не можете залезть в щитовую чужого дата-центра и проверить, куда на самом деле заведён кабель PDU B. Это ответственность площадки, а не ваша. Но у вас есть рычаги на своём уровне:

• Не доверять маркировке PDU на слово. «Два блока питания» и «резервированное электропитание» в описании тарифа — это заявление, а не доказательство. Спрашивайте у провайдера, тестируют ли они переключение вводов реальным отключением (а не только на бумаге), и как часто.
• Спрашивать про Tier-уровень и про то, что именно сертифицировано — весь дата-центр или конкретный зал/ряд. Формулировка «дата-центр уровня Tier III» ничего не говорит о конкретной стойке, если сертифицирован не весь объект.
• Читать SLA не только по проценту аптайма, а по формулировкам о причинах простоя. 99,9% в договоре звучит солидно, но если в тексте есть исключения вида «аварии на стороне внешнего энергоснабжения не засчитываются», SLA вас в такой ситуации не защитит. Про то, как на самом деле читать проценты аптайма в договоре, есть отдельный разбор: SLA в договоре: как читать проценты.
• Не полагаться на резервирование внутри одной площадки для по-настоящему критичных сервисов. Если простой стоит вам денег или репутации, единственная надёжная защита от инцидента такого рода — это не «резервный блок питания», а второй сервер в другом дата-центре, а в идеале в другом регионе. Резервирование внутри одной стойки страхует от отказа отдельного компонента, но не от системной проблемы всего зала или площадки.
• Проверять, как ведёт себя система после жёсткого обесточивания, а не только во время его. Внезапное падение питания — это ещё и риск не подняться сразу после возврата электричества: файловая система не размонтирована штатно, виртуалка может не стартовать автоматически. Это отдельная и довольно частая беда — разбор именно такого случая есть здесь: виртуалка не стартует после сбоя питания.

Если вы арендуете сервер именно у нас, распределение критичных нагрузок между разными локациями — это буквально вопрос выбора региона при заказе, а не отдельный проект: RU, US и UK — это физически разные площадки с разными провайдерами электроснабжения, и держать основной и резервный сервер в разных локациях снимает именно тот класс риска, который разобран в этой статье.

Частые вопросы