30 марта сервисы, размещённые в одном из наших основных дата‑центров, оказались недоступны. К инциденту привела авария на опорной подстанции, которая спровоцировала отказ сразу двух вводов питания и последующий каскадный сбой оборудования.
В этой статье подробно покажем, какие именно риски сработали — а для этого объясним, как устроено энергоснабжение в дата‑центре и на что это влияет. С этой точки зрения посмотрим, как развивались события в этот день и что бывает в дата‑центре, когда случаются ситуации, вероятность которых оценивается как «один на десятилетия». В завершение расскажем, что планируем делать дальше, чтобы не допустить повторения, и какой урок из этого могут извлечь другие инженеры.
Как устроено энергоснабжение дата-центра
Для того чтобы понять ход воскресных событий, даже если вы редко сталкиваетесь с инженерной инфраструктурой, потребуется сделать шаг назад и вспомнить, как работают системы энергоснабжения в целом и как устроено резервирование электропитания в дата‑центре на случай аварий. Если вы опытный инженер, и уже хорошо всё это знаете, можете просто промотать немного дальше.
Кратко о национальной электроэнергетической системе в целом. Если сильно упрощать, то систему энергоснабжения в масштабе страны можно поделить на несколько уровней:
- Источники — многочисленные электростанции, которые генерируют энергию: ТЭС, ГЭС, АЭС и т. д.
- Сеть передачи энергии — линии электропередачи (ЛЭП) высокого уровня напряжения, которые образуют «кровеносную систему» для снабжения электричеством всех уголков страны.
- Систему преобразования и распределения. Поскольку по магистральным линиям идёт ток высокого напряжения, для передачи энергии в готовом для потребления виде нужны электроподстанции, которые принимают энергию от генераторов, преобразуют уровень напряжения и распределяют дальше по регион
- Ну и вокруг всего этого есть большой блок эксплуатации: инженерам необходимо следить за исправностью всего оборудования, вовремя проводить ТО, устранять возникающие аварии и минимизировать последствия и так далее. Для этого существуют лучшие практики и правила эксплуатации, в работе им помогает система диспетчерской связи — для этой статьи подробнее расписывать не будем.
Единая энергетическая система России — крупнейшее в мире энергообъединение с централизованным управлением. Чтобы обеспечить электропитанием все субъекты федерации параллельно работают семь объединённых энергетических систем (ОЭС) — Центра, Юга, Северо‑Запада, Средней Волги, Урала, Сибири и Востока. Подробнее о том, как это устроено можно также почитать
здесь.
Чтобы такая масштабная система работала без сбоев, инженеры строят отказоустойчивую сеть и продумывают варианты «страховки», например, то самое резервирование: альтернативные схемы работы на случай отказа какого‑то из узлов. Например, в случае разрыва ЛЭП продумываются альтернативные пути передачи, но не только. У всех подобных систем довольно сложная внутренняя архитектура.
По ту сторону этой системы есть потребители электричества, которые тоже бывают разных уровней, от простых жителей с розетками на 220 В, до сверхкрупных предприятий, которые могут ставить свои трансформаторы для приёма тока высокого напряжения и преобразования энергии для своих нужд.
Как мы учитываем эту информацию при строительстве дата‑центров. Стандарты проектирования дата‑центров предписывают внимательно выбирать место для строительства с учётом всех факторов риска: от доступности инфраструктуры и до вероятности стихийных бедствий и техногенных катастроф. Доступность и надёжность энергоснабжения — как раз один из таких важнейших факторов.
Если вернуться конкретно к дата‑центру Яндекса, то он появился в 2010-х годах на площадке, которая раньше принадлежала заводу и уже имела выгодное положение: она расположена максимально близко к генератору и надёжному поставщику энергии. Для понимания надёжности: самая близкая к дата‑центру подстанция на 220 кВ не сбоила ни разу с 1960 года. Её установленная мощность 251 МВА, и сегодня подстанция обеспечивает параллельную работу нескольких региональных энергосистем.
Заметка на полях: на самом деле, одна довольно крупная авария на нашей памяти случалась в 2015 году, когда на подстанции полностью отключился трансформатор. Но поскольку таких трансформаторов на подстанции подобного уровня несколько — нагрузку удалось перераспределить на другие линии, и мы как потребитель почти ничего не заметили. За счёт чего можно обеспечить резервирование — расскажу чуть ниже.
Такие подстанции проектируются как сложные распределённые системы, чтобы предоставить потребителям определённые гарантии независимости ячеек. Теоретически можно подключиться и к нескольким подстанциям, но в этом нет практического смысла, так как они все являются частью одной системы, замкнутой по своему дизайну. Поэтому существующее решение было наиболее подходящим вариантом.
Когда на площадке был создан первый энергоцентр, дата‑центр потреблял относительно немного, но с учётом планов по загрузке мощностей мы также установили дизель‑генераторные установки (ДГУ) в качестве резервного источника питания. Несмотря на распространённый миф, что «ДГУ всех спасут», эти установки тоже являются точкой отказа. И на этот случай есть несколько вариантов подстраховки.
Что делать с тем, что у ДГУ есть свои риски. Когда в системе электроснабжения происходят нештатные ситуации, у нас всегда есть угроза скачка напряжения, из‑за которого мы рискуем получить пробой изоляции, выход из строя блоков питания и других частей оборудования. Для чувствительного IT‑оборудования это особенно опасно, поэтому на случай аварий схемы подключения продумываются так, чтобы скачок напряжения «не дошёл» до конечного сервера, и переключение для него было максимально бесшовным и незаметным.
Для такого плавного переключения рядом с ДГУ часто стоят источники бесперебойного питания (ИБП), которые могут сразу же принять на себя нагрузку на то время, пока ДГУ заводится и выходит на полную мощность. Другой частый вариант — вместо ДГУ использовать ДРИБП (дизель‑роторные источники бесперебойного питания), которые являются устройством «два в одном» и сочетают в себе возможности ДГУ и ИБП. У них свои особенности, схема подключения будет чуть другой, но в целом это тоже распространённый вариант. Мы его тоже используем.
Также для сокращения времени запуска ДГУ их стараются держать тёплыми, проводят регулярное ТО и тестовые пуски, чтобы убедиться, что резервный источник питания в любой момент готов принять нагрузку.
Но иногда именно в момент аварии ДГУ могут сразу не запуститься именно из‑за того, что что‑то в системе идёт нештатно. А значит, считать такую установку основным источником питания всё равно нельзя, нужен ещё какой‑то резерв.
Как резервирование питания сейчас устроено у нас. Через 10 лет после строительства мы завершили постепенную модернизацию дата‑центра, чтобы привести его в соответствие с растущими нагрузками и лучшими практиками и стандартами проектирования.
Одна из таких зарекомендовавших себя практик — два независимых источника питания. Чтобы минимизировать риски отказа на стороне энергосистемы, можно подключаться к таким источникам напрямую (что мы и сделали). Для этого мы по сути стали потребителем более высокого уровня и заключили договор с федеральным оператором.
В результате мы подключили дата‑центр по линиям высокого напряжения (110 кВ) напрямую к опорной подстанции в сети национального оператора — в нашей схеме это уровень 1.
Как это выглядит:
Нижним уровнем в такой схеме будет технологический модуль дата‑центра — это автономный технологический квант с точки зрения размещения оборудования и инженерных систем. Типичный дата‑центр Яндекса содержит несколько десятков таких модулей: модули сервисов Яндекса, модули облака, пара модулей сетевого центра.
И если на первом уровне опорная подстанция немного остаётся для нас «чёрным ящиком», то на всех последующих мы контролируем всё сами и обеспечиваем резервирование. Пройдёмся по всем уровням, что для этого сделано:
- Уровень 2: построили собственные кабельные линии от опорной подстанции. Так мы избежали использования более хрупких распределительных сетей общего назначения между дата‑центром и подстанцией.
- Для резервирования питания два раздельных ввода питания подключены к раздельным ячейкам питающей подстанции высокого напряжения.
- Уровень 3: построили собственную подстанцию 110кВ. Подстанция введена в эксплуатацию ещё в 2014 году, оборудована двумя трансформаторами 110/10кВ и закрытым распределительным устройством 10кВ.
- Каждый модуль дата‑центра подключается двумя линиями к разным секциям шин 10кВ. И это одна из причин, почему уже упомянутая крупная авария на опорной подстанции в 2015 году прошла незамеченной.
- Уровень 4. Это уровень распределительных линий 10кВ между нашей подстанцией и технологическими модулями дата‑центра. На этом же уровне находятся ДРИБП.
- Они используются для поддержания работоспособности сетевой инфраструктуры дата‑центра, сервисов безопасности, наблюдения и управляющего контура (Observability).
- Уровень 5. Это технологический модуль дата‑центра.Типовая схема подключения всех технологических модулей дата‑центра: два независимых трансформатора 10/04 кВ, ИБП и распределительное устройство, для возможности проведения регламентных работ.
В случае, если один из вводов питания оказывается недоступен, второй ввод может полностью принять нагрузку на себя — мощность дата‑центра рассчитана таким образом, что одного ввода достаточно, чтобы держать электроснабжение полностью загруженного дата‑центра. Осуществлять переключение помогает распределительное устройство, или АВР (автоматический ввод резерва). С его помощью также можно проводить обслуживание на одной из линий.
Для чего остались ДГУ в этой схеме. В дата‑центрах Яндекса дизельные установки используются для поддержания работоспособности управляющего контура дата‑центровых сервисов.
Решение с ДРИБП помогает сократить время реакции операционной команды в случае сбоев по питанию. Так каждый дата‑центр остаётся транзитным для трафика других дата‑центров, а также при этом обеспечивается мягкий взлёт для остальных сервисов. Помимо этого сеть нужна в том числе для мониторинга инженерных систем и рабочих мест сотрудников дата‑центра, чтобы множество проблем можно было заметить удалённо.
Для понимания масштабов и эксплуатационных рисков: проведение планового обхода всего дата‑центра в этой зоне потребует от пары дежурных инженеров 4 часов на ногах. Следовательно, если где‑то не срабатывает автоматика, или сама процедура по регламенту должна выполняться с участием инженера — большой объём работы по устранению серьёзной аварии потребует и серьёзного усиления команды.
Благодаря тому, что сеть и управляющие сервисы дополнительно зарезервированы с помощью ДРИБП, даже если сбой крупный, зона по‑прежнему видна на мониторинге, и связана по сети с другими зонами доступности, а значит, трафик может убегать из одного дата‑центра в другой. Это важная деталь, когда нужно зарезервироваться на уровне всей сети дата‑центров.
Как это работает при резервировании уровнем выше. При планировании схем резервирования мы исходим из того, что сервисы управляющего контура Яндекса должны продолжать работать и при недоступности одного дата‑центра. В этом случае нагрузка должна перераспределяться по остальным зонам доступности.
Поскольку это довольно сложная задача, то помимо самой схемы с дополнительным резервированием, серьёзно продумываются и регламенты эксплуатации. Мы регулярно проводим для команды учения с имитацией падения одного дата‑центра, и как правило продолжаем совершенствовать систему эксплуатации по итогам таких учений.
По нашей статистике от команды эксплуатации за последние четыре года:
- Если иметь в виду линии 110 кВ и нашу высоковольтную часть подстанции, в том числе трансформаторы 63 МВт, — то около десятка раз проводилось плановое обслуживание, при этом дата‑центр находился в рабочем состоянии на одной линии или одном трансформаторе. Было зафиксировано одно неплановое отключение линии из‑за сработки защиты на опорной подстанции: после локализации оказалось, что срабатывание защиты было ложным, но все системы отработали штатно. Все подобные инциденты наше оборудование и наши пользователи не почувствовали.
- По среднему напряжению 10 кВ за четыре года было 56 плановых отключений по одной линии какого‑либо модуля для техобслуживания. Работали на втором вводе, и IT‑оборудование также продолжало функционировать.
Понятно, что все плановые работы идут с предупреждением сервисов соответствующих модулей и с особым регламентом проведения работ.
Но в целом эти данные показывают, что энергосистема большого дата‑центра — это живой и функционирующий механизм. И функционирующий хорошо и надёжно.
Теперь посмотрим, какие из перечисленных рисков сработали для нас в то воскресенье и что привело к «эффекту домино».
Что происходило 30 марта
В 12:25 воскресенья на мониторинге мы заметили недоступность дата‑центра по питанию и сразу приступили к выяснению и устранению проблемы.
Как было видно в системе, в 12:18 на площадке запустились ДРИБП, но уже в 12:20 стало наблюдаться «резкое занижение напряжения». В 12:27 главный инженер обслуживающей организации связался с дата‑центром и сообщил, что на подстанции отключились обе линии 110 кВ, но причина пока неизвестна. А значит, у нас
Проблема № 1: сразу две точки отказа по питанию с непонятным прогнозом, а дизель‑генераторы просто не рассчитаны на то, чтобы принять такую нагрузку.
При этом на площадке находилась только воскресная смена, а значит, мы начинаем уже на этом этапе усиливать команду.
До 13:00 мы полностью сняли всю маршрутизацию трафика для всех наших дата‑центров, чтобы возвращение работоспособности проходило под контролем дежурной смены. Одновременно с этим это помогло в течение первых 30–40 минут дать рекомендации всем пользователям мультизональных сервисов перераспределить нагрузку на другие зоны.
Также примерно в это же время мы получили сообщение с федеральной подстанции, что технически система готова к подаче напряжения, но по регламенту нужно получить разрешение от диспетчерского управления. Возникает
Проблема № 2: при сбоях такого масштаба, которые затрагивают сразу несколько региональных подсистем, «нельзя просто взять и включить всё обратно», нужно убедиться, что это не усугубит ситуацию.
В 15:30 вернулось питание от подстанции и стартовали работы по восстановлению электропитания дата‑центра.
С 15:52 начался запуск инженерных систем из состояния blackout — в первую очередь для модулей облачной платформы. Здесь было важно перед IT‑эксплуатацией проверить работоспособность оборудования, и по регламенту это ручной процесс, с подключением инженера. Здесь появляется
Проблема № 3: не все работы можно провести автоматически, мы зависим от скорости ручных операций.
Но поскольку во время потери питания ДГУ приняли нагрузку от сетевого оборудования и систем эксплуатации, мы смогли быстрее приступить к восстановлению работоспособности сетевого и серверного оборудования.
К 17:04 мы восстановили электропитание и работу оборудования. Приступили к восстановлению работы сервисов.
19:08 — убедились в целостности данных и конфигураций инфраструктурных систем. Приступили к восстановлению работоспособности сервисов.
20:30 — восстановили доступность первых базовых сервисов, рантмайма, хранилища и начали поэтапное восстановление сервисов баз данных.
В 21:55 успешно завершилось включение всех инженерных систем для работы IT‑оборудования в облачных модулях.
Около 22:22 работа основных сервисов полностью восстановлена. Приступили к возвращению балансировки сетевой нагрузки и доступности остальных сервисов и к 00:00 полностью восстановили работоспособность всех сервисов в зоне.
Что мы планируем делать дальше
Как показал наш опыт, маловероятные ситуации, которые случаются раз в 10–20 лет, вполне могут оказаться реальностью. Следовательно, уже сейчас мы ведём переоценку рисков, которые связаны с энергоснабжением дата‑центров.
Самым лёгким вариантом может показаться «просто поставить больше ДГУ», но с одной стороны такое решение нельзя будет реализовать в короткие сроки, а с другой — как мы помним, ДГУ не панацея (см. начало статьи). Поэтому планируем комплексную работу на нескольких уровнях.
На уровне дата‑центров
Мы продолжаем опираться на принятую в Яндексе модель резервирования на случай отказа «−1 ДЦ» и старательно придерживаемся её во всех сервисах. Но при этом мы знаем, что у части пользователей Yandex Cloud нагрузка размещена только в одной зоне, и поэтому для модулей облачной платформы рассматриваем альтернативные схемы резервирования, в том числе с использованием ДГУ как третьего, резервного источника питания.
На уровне сервисов Яндекса
Мы продолжим проведение регулярных учений для отработки действий команды эксплуатации на случай нештатных событий. В этот раз сервисы Яндекса в основном пережили сбой нормально, но мы выявили несколько мер, которые позволят ускорить «холодный» старт зоны.
На уровне Yandex Cloud
Чтобы клиенты облачной платформы также могли реализовать модель «−1 ДЦ» для проектирования высоконадёжных сервисов, есть несколько зон доступности. Мы продолжим развивать инструменты мультизональной отказоустойчивости и пополнять библиотеку архитектурных решений, которыми могут воспользоваться клиенты.
Одно из последних решений — инструмент Zonal Shift. Это механизм оперативного отключения подачи трафика L3/L7-балансировщиков в зону. В условиях полного отказа дата‑центра он уже доказал свою эффективность и помог точечно управлять нагрузкой для сервисов с мультизональной архитектурой. Надеемся, что он поможет клиентам в том числе для проведения учений.
Чему другие инженеры могут научиться на нашем опыте
Мультизональность на такие случаи — это необходимость для mission‑critical‑сервиcов. Мы публикуем этот разбор в том числе для того, чтобы больше компаний могли оценить подобные риски для себя и заранее подготовиться к возможным инцидентам. Чтобы не повторять чужой опыт в подобной ситуации, лучше быть готовым ко всему: знать, как может развиваться проблема, для более быстрой диагностики и минимизации последствий.
