Авария в дата-центре не обязательно означает моментальное исчезновение тысяч сайтов из интернета. Профессиональный ЦОД как раз строится с расчётом на то, что отдельные компоненты будут ломаться, городское электричество будет пропадать, операторы связи будут повреждать кабели, а климатическое оборудование периодически потребует ремонта.
Если инфраструктура спроектирована правильно, многие такие события клиент вообще не замечает. Один источник питания исчезает, нагрузка переходит на другой. Отключается внешняя электросеть, серверы продолжают работать через ИБП, а через несколько секунд запускаются генераторы. Повреждается один канал связи, маршрутизация переключается на резервный.
Проблема начинается тогда, когда авария выходит за пределы предусмотренного сценария. Отказывают сразу несколько связанных систем, резерв оказывается недоступен из-за обслуживания, происходит ошибка персонала или выясняется, что независимые на схеме линии физически проходят через одну точку.
Поэтому слово авария может означать совершенно разные события. Иногда это отказ одного вентилятора, о котором знает только дежурный инженер. Иногда целый серверный зал теряет охлаждение. В наиболее серьёзном сценарии площадка полностью теряет питание, связь или становится физически недоступной.
Для владельца сайта важно понимать эту разницу. Даже лучший дата-центр не гарантирует, что ничего никогда не сломается. Его задача состоит в другом — не позволить обычной неисправности превратиться в остановку всего сервиса.
Что происходит внутри ЦОД в первые минуты аварии
Один из самых понятных сценариев — исчезновение внешнего электроснабжения.
В обычном офисе в этот момент гаснет свет и выключается оборудование, если его не поддерживает локальный ИБП. В профессиональном дата-центре серверы не должны даже заметить переход.
Источники бесперебойного питания постоянно находятся между внешней сетью и критичной нагрузкой. Когда напряжение пропадает, аккумуляторы практически мгновенно продолжают питать серверы.
Одновременно автоматика обнаруживает потерю внешнего источника и запускает дизель-генераторы. Им требуется некоторое время, чтобы выйти на рабочий режим и стабилизировать параметры электроснабжения.
После этого нагрузка переводится с аккумуляторов на генераторы.
Если всё прошло штатно, сайт продолжает работать. Клиент может вообще не узнать, что городская электросеть исчезала.
Дальнейшая задача операторов — следить за генераторами и запасом топлива. Кратковременный сбой можно пережить практически незаметно. Длительная авария уже требует уверенности, что генерация способна работать часами или сутками и топливо можно пополнять без остановки.
Но даже наличие нескольких генераторов не делает систему абсолютно неуязвимой.
Например, генераторы могут оказаться исправными, а проблема возникнет в распределительном оборудовании между ними и серверным залом. Может неправильно сработать автоматика переключения. Несколько устройств способны зависеть от одного общего элемента, который раньше не воспринимался как критичный.
Именно поэтому резервирование оценивается не количеством одинаковых коробок, а всей цепочкой питания.
Для сервера клиента ситуация продолжается уже внутри стойки. Если машина имеет два блока питания и они подключены к независимым линиям A и B, потеря одной ветви не должна выключить её.
Если же оба блока случайно подключены к одной линии или у сервера вообще один PSU, возможности самого ЦОД используются не полностью.
Отказ охлаждения развивается совсем иначе
При потере электричества реакция автоматики практически мгновенная. С охлаждением авария может развиваться постепенно.
Допустим, выходит из строя один кондиционер. В хорошо спроектированной системе его нагрузку принимает резервное оборудование, и температура в серверном зале почти не меняется.
Если перестаёт работать несколько элементов или проблема затрагивает общий контур, ситуация становится серьёзнее.
Серверы продолжают потреблять электричество и каждую секунду выделяют тепло. Пока вычислительное оборудование работает, машинный зал нагревается.
Скорость роста температуры зависит от размера помещения, плотности серверов и оставшейся мощности охлаждения. Высокоплотная GPU-зона в такой ситуации намного чувствительнее обычного зала с относительно экономичными машинами.
Сначала автоматика фиксирует отклонение параметров. Инженеры получают предупреждение и пытаются восстановить систему или перераспределить охлаждение.
Если температура возле отдельных стоек продолжает расти, серверы начинают реагировать сами. Современные процессоры и GPU умеют снижать производительность при перегреве. Вентиляторы переходят на повышенные обороты.
Если и этого недостаточно, оборудование может аварийно завершить работу, чтобы не допустить повреждения компонентов.
Поэтому при серьёзной аварии охлаждения оператор иногда сознательно отключает часть нагрузки. Лучше корректно остановить несколько стоек, чем позволить температуре выйти из-под контроля во всём машинном зале.
Для клиента это выглядит как простой, хотя формально электроснабжение и интернет в дата-центре могут продолжать работать.
Именно поэтому охлаждение является такой же критичной системой ЦОД, как электричество.
Повреждение сети может быть локальным или глобальным
Сетевая авария внешне часто выглядит проще всего: сервер работает, индикаторы горят, операционная система запущена, но пользователи не могут открыть сайт.
Причин может быть множество.
Выходит из строя маршрутизатор, повреждается оптоволоконная линия, возникает проблема у магистрального оператора или ошибка конфигурации приводит к неправильной маршрутизации.
Если у дата-центра несколько независимых каналов связи, трафик обычно перенаправляется через оставшиеся маршруты.
Однако слово независимые здесь особенно важно.
Два разных оператора могут физически использовать одну кабельную канализацию. Если строительная техника повреждает её, исчезают сразу оба соединения.
На логической схеме резервирование существовало, а физически оставалась одна точка отказа.
Похожие проблемы происходят и внутри самого ЦОД. Например, несколько сетевых устройств могут иметь резервные блоки питания, но зависеть от одного общего коммутатора или одной конфигурации.
Иногда сервер остаётся доступным из одной сети, но недоступным из другой части интернета из-за проблемы маршрутизации. Тогда пользователи разных провайдеров видят совершенно разную картину.
Поэтому сообщения сайт у меня работает и сайт у меня не открывается вполне могут одновременно быть правдой.
Отдельную категорию составляют DDoS-атаки. Физическая инфраструктура может быть полностью исправна, но входящий поток вредоносного трафика перегружает канал или защитное оборудование.
В таком случае действия оператора зависят от используемой системы фильтрации. Трафик может перенаправляться на очистку, отдельный адрес временно блокируется или применяются другие защитные меры.
Для владельца сервера важно понимать, что сетевой простой не всегда означает аварию самого здания.
Почему резервирование иногда не спасает и что происходит после серьёзного сбоя
На презентации архитектура дата-центра выглядит красиво: два ввода питания, несколько ИБП, резервные кондиционеры, два оператора связи, генераторы и множество автоматических систем.
Но реальная отказоустойчивость определяется тем, насколько независимы эти компоненты.
Одна из самых неприятных причин крупных аварий — общий элемент, от которого неожиданно зависят несколько резервных систем.
Например, две ветви питания имеют разные ИБП, но проходят через одно распределительное устройство. Два сетевых маршрута заходят в здание с разных сторон, но дальше соединяются в одной точке. Основной и резервный контуры охлаждения используют общий насос или автоматику.
Пока всё работает, такая зависимость незаметна.
Она проявляется именно во время редкого сочетания событий.
Вторая проблема — техническое обслуживание.
Допустим, система построена по принципу N+1. Один компонент можно вывести из работы, а оставшиеся продолжают обеспечивать полную нагрузку.
Но если резервный элемент в этот момент находится на обслуживании, а рабочий неожиданно ломается, запас исчезает.
Именно поэтому плановые работы в ЦОД требуют строгих процедур. Инженеры должны понимать, какие элементы временно недоступны и какой уровень резервирования остаётся на этот период.
Человеческая ошибка является ещё одним крупным фактором.
Человек может выбрать не тот выключатель, применить ошибочную конфигурацию к маршрутизатору, перепутать последовательность переключения оборудования или неверно интерпретировать сигнал автоматики.
Чем сложнее инфраструктура, тем больше потенциальных комбинаций.
Поэтому зрелый дата-центр старается уменьшить зависимость от импровизации. Существуют инструкции, чек-листы, разделение полномочий и процедуры подтверждения критичных действий.
Особенно опасны аварии, которые начинаются с одной небольшой неисправности и затем распространяются дальше.
Например, отказ части охлаждения увеличивает температуру. Дополнительная нагрузка ложится на оставшиеся климатические установки. Они начинают работать на пределе, и одна из них тоже выходит из строя.
Или сетевое устройство отключается, весь трафик переходит на резервное, а его производительности оказывается недостаточно.
Так возникает каскадный отказ.
Именно такие сценарии особенно сложно предусмотреть, потому что каждый отдельный компонент формально работоспособен в нормальных условиях.
Пожар меняет приоритеты полностью
Пожар отличается от большинства инженерных аварий тем, что основной задачей становится уже не сохранение непрерывной работы серверов, а безопасность людей и ограничение распространения повреждений.
Современные дата-центры используют раннее обнаружение продуктов горения. Идеальная ситуация — заметить проблему ещё до открытого пламени.
Если источник локализован вовремя, иногда достаточно отключить конкретное оборудование или электрическую зону.
При развитии события запускаются предусмотренные системы пожаротушения и аварийные сценарии.
В определённых обстоятельствах часть оборудования может быть принудительно обесточена.
Для клиента это неприятно, но сохранение работы сервера не может быть важнее безопасности объекта.
Особенно серьёзный риск представляет физическое повреждение самого здания. После крупного пожара сервер может быть не просто временно недоступен, а уничтожен вместе с дисками.
Именно здесь становится очевидно, почему резервная копия в той же стойке не является полноценным backup.
Даже второй сервер в соседнем зале может не помочь, если авария затрагивает весь объект.
Поэтому критичные данные должны иметь копию вне основной площадки.
После восстановления начинается разбор причин
Когда электропитание, сеть или охлаждение восстановлены, авария ещё не закончена.
Нужно вернуть оборудование в нормальную эксплуатацию и убедиться, что быстрое восстановление не скрывает новую проблему.
После длительного отключения сотни серверов могут начать запускаться практически одновременно. Это создаёт резкий рост электрической нагрузки.
Поэтому большие системы иногда включают поэтапно.
Сначала запускается критичная инфраструктура, затем сетевые устройства, системы хранения и остальные серверы.
У приложений тоже может существовать правильная последовательность запуска. Например, база данных должна быть доступна раньше веб-сервера, который от неё зависит.
После проблем с охлаждением проверяются температуры и аппаратные предупреждения.
После сетевой аварии контролируются маршруты, потеря пакетов и доступность разных операторов.
После проблем с питанием серверы могут сообщить о неисправных блоках питания, батареях RAID-контроллеров или других компонентах.
Затем оператор анализирует журнал событий.
Когда именно появилась первая ошибка? Что произошло после неё? Какая система должна была сработать? Почему она не сработала или почему её оказалось недостаточно?
Такая работа важнее поиска виноватого сотрудника.
Если ошибка одного человека способна отключить весь дата-центр, проблема заключается не только в человеке. Значит, процедура или архитектура позволила одной ошибке получить слишком большие последствия.
После серьёзного инцидента меняются инструкции, настройки автоматики, схемы резервирования или физическая инфраструктура.
Именно так реальные аварии постепенно делают дата-центры надёжнее.
Для клиентов после заметного сбоя обычно публикуется описание инцидента. Насколько оно подробное, зависит от оператора.
Хороший отчёт должен объяснять не только что сломалось, но и почему резервирование не предотвратило простой и какие изменения будут сделаны после аварии.
Фраза произошёл технический сбой практически ничего не сообщает.
Намного полезнее знать, что отказал конкретный элемент электроснабжения, резервная цепочка оказалась недоступна по определённой причине и оператор уже изменил схему или процедуру.
Для владельца сайта есть важный вывод: даже очень надёжный дата-центр остаётся одной физической площадкой.
Если весь бизнес работает на одном сервере в одном здании, серьёзная авария этого здания всё равно способна остановить сервис.
Можно значительно снизить вероятность такого события, но невозможно сделать её равной нулю.
Поэтому требования к архитектуре должны зависеть от стоимости простоя.
Небольшой корпоративный сайт вполне может спокойно работать на одном сервере. Если он несколько часов будет недоступен раз в много лет, бизнес переживёт это без серьёзных последствий.
Интернет-магазин с большим оборотом уже может нуждаться в резервном сервере и быстром восстановлении.
Для финансового сервиса, крупной SaaS-платформы или другой критичной системы может понадобиться распределение между несколькими площадками.
При этом второй дата-центр сам по себе тоже ничего не гарантирует.
Если переключение никогда не тестировалось, резервная площадка может оказаться красивой схемой, которая не работает в реальной аварии.
Данные должны регулярно синхронизироваться, приложения запускаться на резервной стороне, DNS или балансировщик уметь перенаправлять пользователей, а сотрудники должны знать последовательность действий.
Именно поэтому отказоустойчивость является не покупкой отдельного сервера или тарифа, а свойством всей архитектуры.
Дата-центр отвечает за здание и инженерную инфраструктуру вокруг оборудования. Провайдер отвечает за свою часть услуги. Владелец проекта остаётся ответственным за то, насколько само приложение готово пережить потерю сервера или целой площадки.
Хорошо спроектированный ЦОД способен сделать большинство повседневных неисправностей практически незаметными. Выходят из строя вентиляторы, диски в инженерных системах, отдельные каналы, ИБП и насосы, но клиенты продолжают работать.
Именно это и является нормальным состоянием отказоустойчивой инфраструктуры: оборудование ломается, а сервис не останавливается.
Настоящей аварией для пользователя становится момент, когда неисправность превышает запас резервирования или затрагивает несколько связанных систем одновременно.
Поэтому при оценке надёжности дата-центра полезно задавать не вопрос бывают ли здесь аварии. Они возможны в любой сложной технической системе.
Намного интереснее другое: какой отказ площадка способна пережить без остановки, что произойдёт при потере целой системы и насколько хорошо оператор подготовлен к событию, которое уже выходит за пределы обычного сценария.
