Отказоустойчивость серверов: питание, охлаждение, резервирование

Термины и уровни отказоустойчивости

PSU (от английского Power Supply Unit) — блок питания компьютера, или вторичный источник электропитания.

PDU (англ. power distribution unit) — блок распределения питания, устройство для распределения электрической энергии.

SPOF (Single Point of Failure) — почему чаще всего он «не в сервере»

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

• Путь питания: один PDU, одна группа автоматов, один ввод, один UPS.
• Путь охлаждения: смешивание коридоров, рециркуляция, забитые фильтры, неверная компоновка.
• Сеть: один ToR-коммутатор, один блок питания коммутатора, один аплинк.
• Управление: BMC в той же сети, что и прод, без доступа при аварии.

Практическое правило: «двойной компонент» без «двойного пути» часто даёт ложное чувство безопасности.

Резервирование мощности: N, N+1, N+2, 2N — и что такое “пути”

• N — ровно столько мощности/оборудования, сколько нужно для нагрузки.
• N+1 — к N добавлен один резервный элемент (один UPS-модуль, один вентилятор, один чиллер и т. п.).
• N+2 — запас на два отказа/ремонтных события.
• 2N — два полностью независимых набора, каждый способен нести всю нагрузку (два пути питания/охлаждения).

Ключевой нюанс: резервирование компонентов и резервирование путей распределения — разные вещи. Tier-подход Uptime Institute как раз про предсказуемость инфраструктуры и распределительных путей (power/cooling distribution paths), а не только про «лишний блок» в стойке.

Уровни: компонент → сервер → стойка → зал/ЦОД → площадка/регион → приложение

Полезно мыслить слоями:

• Компонент (вентилятор, диск, PSU, NIC).
• Сервер (двойные PSU, RAID, bonding, ECC).
• Стойка (A/B питание, два PDU, два ToR).
• Зал/ЦОД (UPS, ДГУ, охлаждение, распределение).
• Площадка/регион (DR-сайт, георезерв).
• Уровень приложения: иногда правильно построенное приложение/кластер позволяет сознательно упрощать «железо» на узле (например, не гнаться за максимально дорогими 2N на уровне одной стойки, если сервис выдерживает потерю узла и быстро восстанавливается).

HA vs DR — коротко и по делу

• HA (High Availability): переживаем локальные отказы (компонент/узел/стойка) с минимальным простоем (секунды–минуты).
• DR (Disaster Recovery): переживаем катастрофу площадки (пожар, длительное обесточивание района, недоступность ЦОДа) и восстанавливаемся на другой площадке/в регионе (минуты–часы).

Питание как основа отказоустойчивости

Резервирование внутри сервера: PSU, вводы, распределение нагрузки

Два блока питания (часто обозначают как 1+1) — это лишь половина истории.

Что важно понимать:

• Два PSU ≠ две независимые линии питания. Если оба воткнуты в один PDU/одну группу автоматов — это один путь, один SPOF.
• У серверов обычно два режима:
• Balanced sharing: оба PSU делят нагрузку.
• Standby / cold-redundant: один несёт почти всё, второй в резерве (детали зависят от платформы, но логика одна: при отказе одного другой должен вытянуть пик).

Типовые ошибки в поле:

• Оба PSU подключены в один PDU (или в два «удлинителя» из одной розетки).
• Метки “A/B feed” есть на бумаге, но физически это один и тот же ввод/щит.
• Мощность рассчитана «впритык»: при отказе одного PSU второй уходит в перегруз, и сервер перезагружается.
• Смешаны классы кабелей/разъёмов, плохой контакт → локальный нагрев → аварийные отключения.

Практика подключения:

• PSU1 → PDU A, PSU2 → PDU B.
• PDU A и PDU B питаются от разных автоматов/вводов/UPS (в пределах вашего уровня зрелости).
• На кабелях и PDU — физические метки, чтобы «ошибка рук» не превращалась в массовый даунтайм.

Стойка и помещение: PDU, автоматы, селективность, фазы

Без углубления в электропроект, но с логикой рисков:

• Селективность: при аварии должен отключаться «ближайший» автомат, а не весь ряд/щит.
• Баланс фаз: перекос по фазам = перегрев/срабатывания защиты/непредсказуемые просадки.
• Пиковые режимы: учитывайте не только среднюю мощность, но и пики (boot storm, ребилд массивов, пик вентиляторов при росте температуры).
• Деградация при отказе линии: если у вас две линии A/B, посчитайте, выдержит ли одна линия всю нагрузку (это и есть проверка вашей «N-логики»).

Почему «просто хороший БП» не спасает:качество питания — это не только «среднее напряжение», но и провалы/переходные процессы/время переключений. Именно поэтому на уровне ЦОДа важны архитектура путей и режимы переключений, описываемые в инфраструктурных стандартах и практиках Tier/Topology.

UPS и генератор: что реально даёт “бесперебойность”

UPS решает две разные задачи:

• Перекрыть микропровалы/провалы сети и фильтровать качество питания.
• Держать нагрузку, пока запускается генератор (ДГУ), или пока вы корректно завершите работу.

Топологии UPS:

• Line-interactive: лучше, чем «офисный», но не универсален для критичных нагрузок.
• Online double conversion: обычно даёт наиболее предсказуемую защиту для ИТ-нагрузок (в обмен на стоимость/потери). Терминология и классы встречаются в материалах по IEC 62040 и вендорных глоссариях.

Про bypass (обводная линия):

• Bypass нужен для обслуживания/аварийных режимов, но он же может стать «скрытым SPOF», если не контролировать состояние и условия перехода.

Как выбирать время автономии:

• 5 минут: перекрыть кратковременные отключения и дать время АВР (автоматическому вводу резерва) отработать.
• 10–15 минут: типовой выбор «под запуск ДГУ» (если он есть и реально обслуживается).
• Больше — не всегда лучше: растёт стоимость батарей, требования к обслуживанию и место, а батареи всё равно стареют.

Что обязательно тестировать:

• Реальную ёмкость батарей (а не «паспорт»).
• Переход на батареи и обратно.
• Сценарии обслуживания: что будет, если UPS в bypass, один модуль выведен в ремонт, или отказал контроллер.

Также стоит отметить, что батареи UPS деградируют со временем, поэтому тестирование реальной ёмкости необходимо проводить на регулярной основе - или планово менять их.

Охлаждение и терморежим: отказоустойчивость «через температуру»

Почему перегрев — не только про “вентилятор сломался”

Перегрев сегодня часто проявляется «тихо»:

• Рост плотности: локальные горячие точки возникают быстрее, чем успевают среагировать общие датчики в зале.
• Троттлинг: сервис формально «жив», но производительность падает → SLA по времени ответа «умер».
• Связка с питанием: чем выше температура, тем выше обороты вентиляторов и энергопотребление, тем тяжелее UPS/линии питания — особенно в аварийном режиме, когда вы уже «на одной ноге».

Серверное охлаждение: вентиляторы N+1, датчики, airflow

Внутри сервера отказоустойчивость охлаждения обычно обеспечивается по схеме N+1 (массив вентиляторов переживает отказ одного). Но это работает только если:

• Профили вентиляторов настроены адекватно (а «quiet» не включён там, где нужна предсказуемость).
• Вы мониторите inlet (температуру входящего воздуха), а не только «CPU package».
• Воздух реально проходит через шасси:
• нет «штор» из кабелей;
• крышки/заглушки стоят на месте;
• воздушные каналы не перекрыты.

Чек-лист внутри стойки:

• Серверы ориентированы фронт→тыл (front-to-back).
• Кабель-менеджмент не перекрывает выдув.
• Пустые юниты закрыты blanking panels (иначе рециркуляция съест запас).

Уровень стойки/зала: горячий/холодный коридор, управление потоками

Самая частая причина «непонятных» перегревов — смешивание потоков:

• горячий воздух возвращается на вход (inlet) соседним серверам;
• холодный воздух «утекает» в пустоты и не доходит до фронта оборудования.

Минимально достаточные практики:

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

Нормативные диапазоны: температура/влажность/точка росы и скорость изменений

Важно не «держать как можно холоднее», а держать стабильно и без риска конденсации.

Что измеряют на практике:

• Dry-bulb: обычная температура воздуха.
• RH: относительная влажность.
• Dew point: точка росы (критична для риска конденсации).
• Rate of change: скорость изменения параметров (резкие скачки опаснее «чуть выше среднего»).

Рекомендации и классы условий для ИТ-оборудования публикуются ASHRAE TC 9. 9 (в т. ч. в reference card).

Резервирование компонентов: что резервировать в сервере, а что — на уровне системы

Диски и данные: RAID vs репликация vs бэкапы

Развести понятия — критично:

• RAID защищает от отказа диска внутри узла, но не от удаления данных, шифровальщика, логической ошибки и многих отказов контроллера.
• Репликация повышает доступность (HA), но может реплицировать и ошибку данных или их удаление.
• Бэкап — единственный инструмент (если сделан надёжно) «вернуться назад во времени».

Практические нюансы:

• Hot-swap и spare сокращают время реакции, но rebuild может серьёзно просадить производительность: «сервер не упал», но SLA по I/O уже не выдерживается.
• RAID хорош для: OS-диска, локальных сервисов, небольших массивов, где простота важнее.
• Для критичных данных чаще выигрывает системный уровень: репликация/распределённое хранилище + обязательные бэкапы.

Сеть: два порта ≠ отказоустойчивость

Частые ложные конструкции:

• «Два порта, но один коммутатор» — SPOF.
• «Два коммутатора, но у обоих один PDU/одна линия питания» — SPOF.

Рабочая логика:

• bonding/teaming/LACP — это про агрегирование и переживание отказа линка/порта, но не заменяет разнос по устройствам.
• Для настоящей устойчивости: разные ToR-коммутаторы/разные пути/разные PDU для сетевого оборудования.

Память и CPU: ECC, RAS, “тихие ошибки”

ECC — это не «для учёных», а для предсказуемости:

• виртуализация, базы данных, файловые системы, кеши — везде важна целостность данных;
• “тихие ошибки” в памяти могут выглядеть как «странные падения» приложений.

RAS-функции (на уровне платформы) — часть общей стратегии: меньше необъяснимых сбоев и проще диагностика.

Управление и доступ: BMC как часть доступности

Отказоустойчивость — это ещё и «доступность управления при аварии»:

• отдельная сеть управления (out-of-band);
• ACL/изоляция;
• мониторинг BMC-событий (питание, температура, вентиляторы, сенсоры).

Мониторинг и автоматизация: без этого резервирование не работает

Что мониторить обязательно

Минимальный набор метрик:

• Питание: PSU status, входные линии A/B, потребление (W/A), события по питанию.
• Температуры/охлаждение: inlet/outlet, CPU, VRM (если доступно), обороты вентиляторов.
• Диски/RAID: SMART/предиктивные показатели, состояние массива, rebuild/degraded, ошибки контроллера.
• Сеть: состояние линков, ошибки/потери пакетов, latency до ключевых узлов.
• UPS: нагрузка, уровень батарей, события, режим bypass.

Алертинг и реакции

Разделите уровни:

• Критично (немедленно): отказ линии питания, UPS на батарее, перегрев inlet, RAID degraded без hot spare.
• Важно (в течение часа): рост ошибок на диске, деградация вентилятора, рост дропов на линке.
• Инфо: тренды температуры/потребления.

Автодействия (только если протестировано):

• миграция/evacuation в виртуализации;
• graceful shutdown при исчерпании батареи UPS;
• ограничение нагрузки/поднятие оборотов вентиляторов.

Правило: не автоматизируйте то, что не тестировали.

Тестирование отказоустойчивости: “доверяй, но проверяй”

Набор практических тестов

Используйте как чек-лист и фиксируйте результаты:

• Pull PSU: обесточить один блок питания на работающем сервере. Проверить: сервер не перезагрузился; второй PSU не в перегрузе; есть алерт.
• Отключить PDU A (целиком) для части стойки. Проверить: всё критичное осталось на B; ничего «случайно» не сидит исключительно на A.
• Отключить линию питания A upstream (если архитектура позволяет безопасно). Проверить: корректность A/B на уровне распределения, а не только в стойке.
• Тест UPS на событие входа: переход на батареи и возврат. Проверить: корректные события/алерты, стабильность нагрузки.
• Тест времени автономии: контролируемый разряд до заданного порога (безопасно). Проверить: совпадение с расчётом, корректная реакция (shutdown/migration).
• Тест генератора (если есть): запуск, выход на режим, переключение. Проверить: время, стабильность, отсутствие «провала» при переходе.
• Температурный тест “inlet rise”: имитация ухудшения airflow (например, временно убрать заглушку/изменить нагрузку в безопасных пределах). Проверить: рост inlet виден, алерты срабатывают до троттлинга.

Если зрелость высокая, можно аккуратно применять идеи Chaos Engineering: небольшие контролируемые «поломки» в проде по регламенту — но только после того, как базовые тесты безопасны и повторяемы.

“Симптом → причина → что делать → как проверить”

Регламенты: обслуживание и постмортемы

Без регламентов резервирование деградирует:

• батареи UPS стареют и теряют ёмкость;
• фильтры забиваются, airflow ухудшается;
• вентиляторы изнашиваются, растёт шум/вибрации;
• «почти аварии» забываются и повторяются.

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

Баланс стоимости и доступности: как выбрать уровень резервирования под задачу

Удобная логика выбора:

• Dev/Test: допустимы простои → достаточно базового «надёжного сервера» + бэкапы при необходимоти.
• Веб-сервисы SMB: простой уже стоит денег → двойные PSU, корректный A/B, базовый UPS, мониторинг, RAID/репликация по ситуации.
• Базы данных/VDI/критичные сервисы: простой дорог → кластер 2–3 узла, разнос по стойкам/ToR, проверенные процедуры обслуживания без даунтайма.
• Когда простой недопустим: DR-площадка/георезерв, тесты восстановления, регулярные учения.

Частые неочевидные ошибки

• Две PSU, но один PDU/одна группа автоматов.
• “A/B feed” — это два удлинителя в одной розетке.
• Два коммутатора, но оба питаются от одной линии (или оба от одного UPS).
• UPS есть, но батареи деградировали — и это никто не проверял.
• UPS постоянно в bypass (или уходит в bypass при нагрузке), а алертов нет.
• Мощность рассчитана по «среднему», а при аварии/пике один PSU/линия не вытягивает.
• В стойке нет заглушек, коридоры смешаны → рециркуляция убивает запас по температуре.
• Мониторинг видит CPU, но не видит inlet — перегрев начинается «в стойке», а не в кристалле.
• Кабель-менеджмент перекрывает выдув/впуск, airflow «есть на схеме», но не в железе.
• RAID спасает от диска, но rebuild резко просаживает I/O → SLA падает без явного “down”.
• Репликация настроена, но бэкапов нет (или они не восстановимы).
• Два NIC, но один ToR/один аплинк — SPOF.
• BMC в прод-сети без изоляции: при сетевой аварии вы теряете управление.
• «Резервирование есть», но нет процедуры обслуживания без остановки.
• Никто не проводит pull-the-plug тесты: «работает на бумаге».

Уровни резервирования мощности: N / N+1 / 2N

Терминология Tier/Topology и логика распределительных путей подробно привязана к инфраструктурным стандартам Uptime Institute.

Итоговый чек-лист внедрения

Питание

• ✅ Развести PSU1→PDU A, PSU2→PDU B (физически разные PDU). Проверка: Pull PSU без перезагрузки.
• ✅ Убедиться, что PDU A и PDU B питаются от разных автоматов/вводов/UPS (на вашем уровне). Проверка: отключение PDU A.
• ✅ Пересчитать мощность в режиме аварии (одна линия/один PSU). Проверка: нагрузочный тест + метрики W/A.
• ✅ Настроить алерты по PSU status, input A/B, событиям питания. Проверка: тестовые отключения.
• ✅ Для стойки: баланс фаз и контроль селективности (минимально — аудит и маркировка). Проверка: документ + выборочные измерения.
• ✅ UPS: проверка батарей, тест перехода на батареи/обратно. Проверка: плановый тест, журнал событий.
• ✅ Если есть ДГУ: тест запуска и переключения. Проверка: контролируемое учение.

Охлаждение

• ✅ Мониторить inlet у фронта (не только CPU). Проверка: алерт при превышении порога.
• ✅ Поставить blanking panels на пустые U, закрыть “дыры” в стойке. Проверка: падение inlet после внедрения.
• ✅ Привести кабель-менеджмент в порядок (не перекрывать airflow). Проверка: визуальный аудит + тренды.
• ✅ Обеспечить базовую компоновку горячий/холодный коридор, минимизировать смешение потоков. Проверка: теплокарта/обход.
• ✅ Регламент чистки фильтров/профилактики. Проверка: периодичность + отметки в журнале.

Резервирование + мониторинг + тесты

• ✅ Чётко развести RAID/репликацию/бэкапы и закрепить в архитектуре. Проверка: тест восстановления из бэкапа.
• ✅ Настроить алерты RAID degraded/rebuild, SMART, предиктивные ошибки. Проверка: тестовый сценарий degraded.
• ✅ Сеть: разнести по двум ToR/путям, проверить питание сетевого оборудования. Проверка: отключение одного ToR/аплинка.
• ✅ BMC: отдельная сеть управления и доступ при аварии. Проверка: отключение прод-сети.
• ✅ Регулярные “pull-the-plug” тесты по графику (питание/UPS/сеть/температура). Проверка: протоколы тестов.
• ✅ Постмортемы даже по “почти авариям”. Проверка: шаблон + действия по итогам.

Источники

• Tier-подход, уровни и логика распределительных путей: Uptime Institute — Tier Classification System, Tier Standard: Topology.
• Термины и практики по ИБП (в т. ч. double conversion) и глоссарии: ABB Technical Glossary (PDF), ABB: Line-interactive vs online double conversion (PDF), а также материалы по IEC 62040 (предпросмотр стандарта).
• Терморежимы и параметры среды: ASHRAE TC 9. 9 Thermal Guidelines Reference Card (PDF).
• Энергоэффективность и связка “ИТ-нагрузка ↔ охлаждение ↔ электрика” (как инженерная практика, без фанатизма): DOE — Best Practices Guide for Energy-Efficient Data Center Design (PDF).
• Про метрику PUE и корректный смысл измерений: LBNL / The Green Grid — PUE: A Comprehensive Examination (PDF).