Надежность питания серверов: тест «выдерни один шнур»

Что показывает тест «выдерни один шнур»

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

Такая проверка помогает заранее найти проблемы, которые обычно всплывают в самый неподходящий момент. Например, оба блока питания подключены к одному PDU, розетки в стойке подписаны неправильно, или ИБП держит нагрузку хуже, чем кажется по индикаторам. На серверах с двойными блоками питания тест показывает, сможет ли система спокойно перейти на второй блок и продолжить работу.

Чаще всего тест вскрывает три группы ошибок: нет реального разведения по вводам A/B, в цепочке есть слабое звено (кабель, разъем, PDU, автомат, ИБП), или мониторинг не фиксирует событие и не уведомляет дежурного.

Успехом считается не сам факт, что сервер «не упал», а предсказуемое поведение всей системы. Хороший результат выглядит так:

• сервисы и ОС продолжают работать без перезагрузки;
• второй блок питания берет нагрузку, а статусы корректно меняются на панели и в системе;
• появляется понятная запись в журналах и уходит уведомление;
• после возврата кабеля схема возвращается в норму без новых ошибок.

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

Подготовка: безопасность, окно работ и план отката

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

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

Заранее предупредите тех, кто заметит любые изменения в сервисах и мониторинге: дежурного администратора и инженера на месте, владельца сервиса, эксплуатацию (электрика/инженера по стойкам), команду мониторинга или SOC, а при необходимости и пользователей.

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

Перед стартом проверьте, что у вас под рукой есть все необходимое:

• физический доступ к серверу и стойке, нормальное освещение;
• понятная маркировка линий питания A и B (или точное понимание, где какая);
• доступ к консоли управления сервером и системе мониторинга;
• контакт человека, который может быстро помочь с электрикой или ИБП;
• время на наблюдение после действия (5-10 минут), а не только на сам «рывок».

И главное про безопасность: не делайте ничего «на весу», не тяните кабель с усилием, не работайте мокрыми руками и не лезьте в распределительные щиты без допуска. Если есть сомнения, остановитесь и позовите специалиста. Надежность питания начинается с дисциплины, а не со смелости.

Как должно быть устроено резервирование питания

Резервирование питания обычно строят вокруг двух независимых линий, условно A и B. Проще говоря, это два отдельных пути, по которым электричество приходит к серверу. В идеале они не пересекаются до самого сервера: разные автоматы, разные кабели, разные розетки, а часто и разные ИБП.

Два блока питания в сервере нужны для того, чтобы он «жил» при потере одной линии. Чаще всего блоки работают в режиме распределения нагрузки: каждый берет часть потребления, а при отказе одной линии оставшийся блок быстро подхватывает 100%.

Чтобы резервирование было настоящим, важны раздельные PDU (распределители питания в стойке) и независимые вводы. Если оба шнура сервера подключены в один и тот же PDU, запитанный от одного автомата или одного ИБП, это не резервирование, а два кабеля в одну точку отказа. Отдельная частая проблема - «случайное объединение» A и B через один удлинитель, общий сетевой фильтр или одну розетку с двумя гнездами.

На практике встречаются такие схемы:

• 2 БП и 2 линии (A в PDU-A, B в PDU-B) - правильный вариант;
• 2 БП и 1 линия - сервер переживет отказ одного БП, но не переживет потерю линии;
• 1 БП и 2 линии - выбрать можно только одну линию, реального резерва нет;
• 2 БП, но обе вилки в одном PDU - выглядит надежно, но падает вместе с PDU или его питанием.

Пошагово: как провести тест без лишнего риска

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

Сначала убедитесь, что это действительно две разные линии. Частая ловушка: оба шнура подключены к одному PDU или к двум розеткам, которые запитаны от одного автомата. Минимальная проверка: проследите кабели до PDU, затем до ИБП или щита, и подпишите, где линия A, а где линия B.

Перед отключением зафиксируйте исходное состояние. Посмотрите текущую нагрузку (CPU, диски, сеть), статус блоков питания на панели сервера, индикаторы на PDU и ИБП, и убедитесь, что уже нет активных критичных предупреждений. Если идет тяжелая операция (резервное копирование, миграция, обновление), тест лучше перенести.

Безопасная последовательность действий:

• подтвердите окно работ и план отката;
• проверьте, что оба БП включены и показывают норму, а питание разведено по разным линиям;
• отключите один шнур (обычно удобнее со стороны PDU) и засеките время реакции;
• убедитесь, что не было перезагрузки: откройте консоль управления, проверьте соединения и сервисы;
• верните шнур обратно и проверьте, что оба БП снова в норме, без новых ошибок.

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

На что смотреть на сервере и блоках питания

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

Сначала посмотрите на индикаторы на лицевой панели и на самих блоках питания. Нормально, если после отключения одного кабеля второй БП продолжает светиться «OK», а на отключенном появляется «fault/AC lost» (или гаснет индикатор входного питания). Допустим короткий звуковой сигнал и ускорение вентиляторов на несколько секунд.

Подозрительно, если есть признаки нестабильности:

• мигание индикаторов, щелчок и заметная пауза, как при перезапуске;
• непрерывная тревога, которая не прекращается после перехода на вторую линию;
• сильный рост шума вентиляторов и нагрев одного БП, который держит всю нагрузку;
• повторяющиеся попытки «запуститься», смена цветов индикаторов, уход в аварийный режим;
• сервер продолжает работать, но пропадает сеть или диски на секунды (косвенный признак просадки).

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

В протокол теста запишите минимум: точное время отключения, какие индикаторы и звуки были до и после, была ли пауза в работе (даже доли секунд), и итог - сервер продолжил работу или нет. Это поможет сопоставить наблюдения с событиями в BMC и в ОС.

Проверяем ИБП, PDU и электрику стойки

Тест легко превращается в проверку не только сервера, но и всей цепочки питания. На схеме часто рисуют две линии, а в реальности обе сходятся в одну точку: один ИБП, один PDU или один автомат.

ИБП: переход на батарею не всегда хороший знак

Если при отключении одной линии ИБП уходит на батарею, это значит, что вы потеряли входное питание ИБП, а не просто «одну из линий до сервера». Обычно так бывает, когда обе линии сервера запитаны от одного и того же ИБП или одного ввода.

Нормальная картина для двух независимых линий такая: отключили A, сервер остался на B, а ИБП (если он есть в линии A) продолжает работать от сети и не разряжает батареи. Переход на батарею уместен только в сценарии, где так и задумано. Тогда важно, чтобы батареи были исправны и времени хватало до восстановления питания.

PDU и автоматы: не «перекашивается» ли нагрузка

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

Проверьте простые вещи: до теста посмотрите нагрузку по обеим линиям (по дисплею ИБП, на измеряемом PDU или по показаниям автомата, если они есть). После отключения одной линии убедитесь, что оставшаяся линия не уходит в перегруз и что автомат не срабатывает через 10-30 секунд. Если после переключения линия держится «впритык», это уже риск при пиковых нагрузках и при старте оборудования.

Фазировка и распределение нагрузки: быстрая сверка

В небольших серверных часто путают «две линии» с «двумя разными розетками». Признак настоящей независимости простой: у линий A и B разные источники и разные защитные устройства.

Без сложных измерений можно сделать аккуратную проверку на уровне стойки: сверить маркировки кабелей A/B, посмотреть, в какие PDU и какие автоматы они подключены, и убедиться, что отключение одной группы не обесточивает вторую. Если при выключении одного автомата исчезают обе «линии», резервирование есть только на бумаге.

Журналы и оповещения: что должно зафиксироваться

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

Какие записи считать нормой

После отключения одного шнура события обычно появляются в нескольких местах. В идеале вы видите понятную цепочку: потеря входа, переход на работу от одного канала, затем восстановление после возврата питания.

Обычно ожидают такие типы событий:

• потеря входного питания на PSU A или PSU B (AC lost, input lost);
• изменение состояния резервирования (redundancy lost, degraded);
• предупреждение о работе без резервирования без остановки сервера;
• восстановление входа (AC restored) после возврата кабеля.

Где смотреть: в контроллере управления сервером (BMC, iLO/iDRAC/IPMI), в событиях ОС (Windows Event Viewer, Linux journald/syslog) и в системе мониторинга. Лучше сверить все три источника.

Время в логах: мелочь, которая ломает расследование

Если время на BMC, ОС и в мониторинге расходится, потом сложно доказать, что было первым: отказ питания, ошибка БП или перезагрузка. Проверьте синхронизацию времени (обычно через NTP) до теста.

Что должно уйти в оповещения

Оповещение должно быть коротким и практичным, чтобы по нему можно было действовать сразу. Минимальный набор: какой сервер и где он стоит (площадка, стойка, сервис), какой блок питания и какой вход потерян, есть ли резервирование прямо сейчас, время события и кому эскалировать (дежурному ИТ и ответственным за электропитание).

Если вы отключили кабель, сервер продолжил работу, а мониторинг молчит, это означает, что реальный отказ заметят только по жалобам. Такой тест ценен именно тем, что показывает «дыры» в наблюдаемости.

Частые ошибки, из-за которых тест заканчивается проблемой

Самая частая причина провала проста: физически «два шнура» есть, а реального резервирования нет.

Первая ловушка - оба кабеля питания подключены к одному источнику. Это может быть одна розетка, один PDU, одна группа автоматов или один ИБП. В момент отключения вы теряете сразу обе «независимые» ветки.

Вторая ошибка - два блока питания установлены, но один не работает или выключен. Причины обычно бытовые: тумблер на самом БП, неплотно вставленный модуль, неправильный кабель, деградация блока, которую никто не заметил.

Третья проблема - запас по мощности на грани. Пока работают два БП, нагрузка делится. После отключения одной линии весь ток идет через оставшийся блок, и он может уйти в защиту.

Четвертая ошибка связана с ИБП: «ложные» переключения или слишком чувствительные пороги выглядят как авария. В итоге вы тестируете не отказ линии, а поведение ИБП и делаете неверные выводы.

Пятая - тест проходит «вслепую». Если нет уведомлений от BMC, ОС и мониторинга, можно пропустить главное: сервер не упал, но один БП уже в ошибке, а второй работает на пределе.

Что проверить, если тест дал неожиданный результат

Вот признаки, что резервирование было «на бумаге»:

• оба шнура приходят в один PDU или в одну группу автоматов;
• один БП не показывает нормальный статус (ошибка, нет индикатора, не виден в IPMI);
• суммарная мощность близка к максимуму одного БП, особенно при пиках;
• ИБП переключается на батарею с задержкой или дает краткий провал;
• нет мониторинга питания и оповещений, поэтому непонятно, что произошло в момент отключения.

Короткий чек-лист успешного результата

Удачный тест выглядит скучно: сервисы продолжают работать, а вы получаете понятные сигналы о том, что одна линия питания действительно отказала и система перешла на резерв.

• Кабели питания реально разведены: вход A уходит в одну линию (или PDU), вход B - в другую, и это подтверждается трассировкой и маркировкой в стойке.
• Проверка прошла на живой нагрузке: сервисы и виртуальные машины работают, нет ручных перезагрузок «на всякий случай».
• ИБП и PDU ведут себя ожидаемо: при отключении одной линии ИБП не переходит на батарею без причины, автоматы не выбивает, PDU не показывает перегрузку.
• В журналах есть ясная запись: событие с точным временем и понятным описанием (например, «AC input lost / PSU redundant state changed»).
• Оповещение дошло до нужных людей: уведомление пришло в реально читаемый канал, и по нему понятно, что произошло.

Проверка здравого смысла: после возврата кабеля питание возвращается в исходное состояние без ошибок, а статус резервирования снова «норма». Если хотя бы один пункт не выполнен, считать тест пройденным рано.

Пример из жизни: стойка в офисе или небольшой серверной

Небольшая компания держит стойку в кладовой: два 1U сервера и один ИБП на 3 кВА. Серверы с двойными блоками питания, в стойке два PDU, но подключали все «как удобнее», без схемы. Один сервер отвечает за файлы и 1С, второй - за резервное копирование и домен.

Тест решили провести на одном сервере в тихое время. На панели горит два индикатора питания, вентиляторы работают ровно. Администратор отключает один шнур, держит его в руке и наблюдает: сервер не должен перезагружаться, а статус питания должен перейти в режим «1 из 2».

Через несколько секунд на сервере появляется предупреждение по одному блоку питания, но в мониторинге тишина. В системном журнале ОС есть запись о потере одного PSU, в журнале контроллера управления (IPMI/iDRAC/iLO) тоже есть событие, а оповещения не пришли.

Пока разбирались, нашли более неприятное: оба шнура питания сервера уходят в один и тот же PDU, а второй PDU запитан от того же ИБП и той же группы розеток. Формально «два шнура есть», но отказ PDU или автомата в щитке выключит сервер полностью.

Исправили быстро:

• развели шнуры по PDU A и PDU B и подписали их;
• проверили, что PDU реально питаются от разных линий или хотя бы от разных выходов ИБП;
• включили алерты по событиям питания в мониторинге и протестировали доставку уведомлений;
• повторили тест и записали ожидаемое поведение и время реакции.

После повторного прогона сервер остался в работе, предупреждение пришло в течение минуты, а в журнале ИБП появился факт изменения нагрузки. На таких мелочах и держится надежность питания, даже если в стойке всего пара машин.

Следующие шаги: закрепляем результат и поддерживаем надежность

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

Сделайте процедуру регулярной: для критичных стоек - раз в квартал, для остальных - раз в полгода, плюс после любых работ с ИБП, PDU, электрикой или замены сервера. Важно, чтобы тест делал не один человек «по памяти», а любая смена по понятному сценарию.

Стоит стандартизировать:

• маркировку шнуров и розеток (A и B, цветом и бирками на обоих концах);
• схему питания стойки (какой PDU относится к A и к B, где вводы);
• шаблон протокола (дата, стойка, сервер, что отключали, что произошло, кто подтвердил);
• правило прокладки (шнуры A и B не идут одной связкой и не упираются в одну точку отказа);
• ответственность и канал оповещений (кто реагирует и куда приходят тревоги).

Аудит питания и переразводка стойки нужны, если вы регулярно видите «красные флаги»: один PDU питает оба БП, линии A и B сидят на одном автомате, ИБП перегружен, или после теста часть серверов уходит в перезагрузку. Часто это всплывает после переездов, расширений и «временных» подключений, которые стали постоянными.

Если нужна помощь с проектированием и внедрением схемы A/B, подбором серверов с двойными блоками питания, интеграцией и поддержкой, это можно закрыть через GSE.kz (gse.kz) как производителя и системного интегратора с круглосуточной технической поддержкой и сервисной сетью по Казахстану. Это удобно, когда важно получить не просто оборудование, а проверяемую отказоустойчивость в эксплуатации.