Рейтинг
0.00

Yandex Cloud

5 читателей, 272 топика

Превращение в «жука»: эволюция IT-оборудования в дата-центрах Яндекса

Меня зовут Владимир Аксёнов, я работаю в Yandex Infrastructure и руковожу IT‑поддержкой в том самом дата‑центре Яндекса, который стал первой площадкой в собственности компании. Это определило его судьбу первопроходца: именно здесь мы тестируем множество технологий, которые затем распространяются на другие дата‑центры.

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

В этой статье покажу, как за это время поменялось IT‑оборудование, как это повлияло на облик дата‑центров, и что интересного ждём в наших дата‑центрах в 2026 году.

2012: построили свой дата-центр!


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

Сначала здесь появился минимальный набор IT‑инфраструктуры для запуска: NOC‑room и два первых кластера. Туда мы устанавливали оборудование, которое зарекомендовало себя и на предыдущих площадках: серверы и дисковые полки в стойки 19".

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


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

Наши масштабы росли всё быстрее, и нам было нужно всё больше таких стоек с серверами. Деплой каждой требовал времени:
  • Каждый сервер вынуть из коробки.
  • Снять упаковочные материалы.
  • В стойку установить 360+ сухарей/собачек.

  • Накрутить 94 салазки.
  • Установить 47 серверов.
  • Распаковать и скоммутировать сеть управления, сеть передачи данных, подключить кабели питания.


На каждую стойку уходило примерно 1,5–2 человекодня… Мы стали думать, как сократить это время.

2013: первые стоечные решения
В следующем году запустился новый модуль с разделением на горячий и холодный коридор, где можно было ставить не только стандартные стойки 19", но и стоечные решения по стандарту The Open Rack.


Это стойка, в которой серверы не имеют собственного активного охлаждения и блоков питания, а подключены к централизованной системе: всё подключение к питанию предусмотрено в задней части с помощью специальной шины питания — тогда она была на 12 В. Охлаждение тоже интегрированное.


Самое главное — такие решения можно доставить в дата‑центр уже в собранном виде. Некоторые модели приезжали даже с коммутацией, и это был настоящий прорыв. Первые подобные стойки мы заказали у сторонних производителей, а затем наладили своё производство с опорой на стандарты Open Compute Project Foundation (OCP) и стали устанавливать стоечные решения, разработанные Яндексом.

2017: переход на фрикулинг
Следующие годы были посвящены повышению эффективности работы всей системы. Инженеры дата‑центра тестировали фрикулинг — систему, где всё оборудование охлаждается исключительно уличным воздухом. В плане инженерной инфраструктуры это также было прорывное решение, которое обещало серьёзную экономию ресурсов, так что мы использовали его при проектировании и строительстве новых модулей в нашем дата‑центре.


Суть фрикулинга в том, что в холодный коридор поступает воздух БЕЗ доохлаждения: летом — это уличный воздух, а зимой используется уличный воздух с подмесом нагретого воздуха из горячего коридора, чтобы довести минусовую температуру до комфортных 20 градусов. Такое решение позволило отказаться от использования громоздких, сложных в эксплуатации холодильных машин.

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


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

С точки зрения IT‑поддержки важно, что отказ от доохлаждения помогает улучшить PUE (Power Usage Effectiveness) — коэффициент, отражающий эффективность использования энергии в дата‑центре. При использовании доохлаждения PUE находился в районе 1,5, а без него — держится на отметке 1,1, а иногда и меньше. Это значит, что только 10% от всего потребления дата‑центра уходит не на IT‑нужды.

К тому моменту мы уже разработали стоечные решения, которые умели работать при температурах до +40 градусов. Поскольку все наши дата‑центры находятся в средней полосе России, такая температура — скорее аномалия. Но периодически кратковременные периоды жары всё же случаются, и было важно убедиться, что система справится.

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

2017: новый дата-центр с новыми подходами


В том же году запустился новый дата‑центр во Владимире, который изначально был спроектирован под фрикулинг и построен с нулевого цикла — такие строительные работы включали целый комплекс подготовительных мер, например, создание фундамента, прокладку необходимых коммуникаций и так далее. Если в старом дата‑центре для строительства кластера на фрикулинге в бывшем заводском помещении понадобилось убирать старые полы и заливать новые, чтобы разместить инженерное оборудование по высоте, то здесь эти моменты учли ещё на старте строительства. Заодно избавились от проблемы строительной пыли, которая неизбежно появлялась при модернизации старого здания.

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

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

2022: проектирование «жука»
Учитывая весь накопленный опыт эксплуатации, новую площадку мы задумали как возможность объединить всё лучшее из существующих дата‑центров, а также избежать тех неудобств, которые возникли со временем. Так появился новый проект дата‑центров:
  • с фрикулингом;
  • с безразрывной крышей, как в первом дата-центре;
  • с помещениями машинных залов, которые отделены друг от друга дверями.

Сверху на плане выглядело так: в центре складские помещения и офис, а в стороны расходятся четыре помещения для строительства кластеров. Было похоже на насекомое, поэтому мы прозвали этот проект «жук».


В таком едином помещении нет пыли, корпуса по‑прежнему можно вводить в эксплуатацию по мере заполнения, но поскольку они расположены близко, то перемещение в любую погоду комфортное, а переезд IT‑оборудования между модулями проходит беспрепятственно.

В недавно прошедший день работников дата‑центров мы даже заказали торт, вдохновлённый этим проектом:


2025: жизнь первых дата-центров
Ввод новых площадок в эксплуатацию не означает, что мы забываем про прежние дата‑центры.

К настоящему моменту в серверных стойках мы перешли уже к четвёртому поколению серверов, и для них требуется совсем другая инфраструктура, чем было 10–12 лет назад:


Сервер 4.0 предусматривает:
  • более эффективное охлаждение на 10–15%;
  • питание 48 В на сервер (ноду);
  • вместо четырёх NVMe‑дисков теперь шесть, и есть возможность установки двух дисков M2;
  • возможность установки GPU.

Само стоечное решение выглядит уже так:


С 2023 года мы ведём работы по модернизации старой части нашей первой площадки.

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

2026: что будет дальше?


Дата‑центры будущего уже рядом с нами, и вот как они выглядят для нас сейчас:
  • современное помещение, которое сочетает удобство и надёжность;
  • возможность запускать площадку даже с одним модулем и достраивать остальные по мере необходимости;
  • экономичное расходование энергии с PUE не более 1,1;
  • стойки приезжают в дата‑центр в сборе и отправляются в тестирование через 30–40 минут с момента разгрузки фуры.

Уже можно представить, как это будет развиваться дальше:
  • Виден рост потребностей в мощностях для ML‑задач, которые потребляют много электроэнергии. Поэтому площадки будут заполняться очень быстро.
  • Если первые кластеры потребляли киловатты, а существующие якорные дата‑центры — 40–60 МВт, то площадки ближайшего будущего проектируется уже с мощностью 120 и более МВт.
  • Масштабироваться мы и дальше будем площадками, и это будет несколько обособленных сооружений в непосредственной близости, например, как наш «жук».
  • Постоянно увеличивающийся TDP чипов обязывает постепенно переходить к системам жидкостного охлаждения, как в инженерных системах дата‑центров, так и внутри серверов.



Иногда я спрашиваю коллег, работающих в дата‑центре, как они видят будущее нашей площадки. Многие отвечают, что чинить серверы будут роботы (а сотрудники IT‑поддержки, по‑видимому, будут чинить роботов). Но с точки зрения эксплуатации это не так уж далеко от истины. В идеале хочется, чтобы это выглядело так:
  • прихожу в дата‑центр, иду в офис;
  • умная колонка меня приветствует и рассказывает про запланированные на день задачи в формате саммари, докладывает об уровне SLA и каких‑либо изменениях;
  • по цеху ходят сотрудники службы контроля качества в очках дополненной реальности, на которых видны необходимые операции с оборудованием;
  • роботы‑доставщики вокруг развозят компоненты на склад и со склада до места проведения работ;
  • в офисе сидят IT‑специалисты, которые выполняют сложную диагностику, давая задачи AI‑ассистентам.

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

yandex.cloud/ru

До 50 000 ₽ за практическое руководство



Используете облачные сервисы и готовы поделиться своими идеями? Станьте частью сообщества Yandex Cloud в рамках контент‑программы и получите грант до 50 000 рублей за ваш вклад в улучшение документации
yandex.cloud/ru/content-program



Чем весомее вклад, тем больше грантов вы получите! Нам важны любые ваши идеи и опыт работы с сервисами Yandex Cloud.
Особенно мы ценим пошаговые руководства, которые помогают решать конкретные задачи. Если у вас есть интересные сценарии использования сервисов, поделитесь ими с другими пользователями.

С чего начать?
1. Зарегистрируйтесь на GitHub github.com
2. Прочитайте соглашение с контрибьютором github.com/yandex-cloud/docs/blob/master/CONTRIBUTING.md
3. Изучите инструкцию по работе с репозиторием yandex-cloud/docs github.com/yandex-cloud/docs/blob/master/guides/how-to-contribute.md
4. Ознакомьтесь с руководствами по стилю и синтаксису Yandex Flavored Markdown (YFM).
github.com/yandex-cloud/docs/blob/master/guides/how-to-write.md
diplodoc.com/docs/ru/index-yfm

Ждём ваших пул‑реквестов!

Yandex Cloud анонсировала зону доступности на базе нового дата-центра Яндекса



Yandex Cloud наращивает облачные мощности для своих клиентов. На конференции Yandex Neuro Scale 2025 объявили, что в 2026 году Yandex Cloud запустит новую зону доступности — она создана на базе нового дата-центра Яндекса мощностью более 40 МВт. Он расположен недалеко от уже действующего дата-центра компании во Владимирской области.

Новая зона доступности обеспечивает минимальную задержку передачи данных до соседней зоны — менее 1 мс. Общая ёмкость канала между зонами достигает 25,6 Тб/с. Это особенно актуально для банков, ритейлеров и других компаний, которым важна скорость и непрерывность бизнес-процессов: транзанкций, бронирования билетов и запросов во внутренние базы данных. При этом каналы линий связи с другими зонами доступности независимы друг от друга — это обеспечивает дополнительную отказоустойчивость облачной инфраструктуры.
Иван Пузыревский, технический директор платформы Yandex Cloud

Наши клиенты наращивают потребление облачных ресурсов — в первом полугодии 2025 года спрос пользователей на виртуальные процессоры, или vCPU, вырос на 29,6% по сравнению с предыдущим годом. Чтобы обеспечить бесперебойную работу клиентских сервисов, мы не только представили новую зону доступности, но и первыми в России запустили инструменты для проведения учений по отказоустойчивости инфраструктуры.

Средний показатель энергоэффективности дата-центра достигает 1,1 PUE — на 27% лучше среднемировых показателей. Добиться такого результата удалось с помощью технологии фрикулинга — серверные стойки охлаждаются уличным воздухом и зимой, и летом.

Приглашение на Yandex Neuro Scale



Главная конференция Yandex Cloud приближается — уже 24 сентября на Yandex Neuro Scale вы узнаете, как наши технологии позволяют выйти на новый уровень эффективности в бизнесе, разработке и любых рабочих задачах.
Мы собрали лучших экспертов, которые расскажут об инфраструктуре, решениях по работе с данными, безопасности, AI‑инструментах в действии и бизнес‑кейсах.

Топ-5 выступлений для вас
Полная программа уже доступна на сайте конференции. А наша нейросеть сделала персональную подборку выступлений, которые могут вас заинтересовать.
  • Путь от мониторинга к Observability Platform
  • Объектное хранилище завтрашнего дня: новые горизонты применения
  • Next-Gen Infrastructure
  • Умное видео: как AI помогает улучшать опыт взаимодействия с видеоконтентом
  • Технологии поиска для умных и свободных: опыт Альфа-Банка
Оцените подборку в конце письма.


scale.yandex.cloud/program/


Воркшопы
В этом году на площадке вас ждёт больше десяти воркшопов! Вы сможете создать голосового агента и бота в Telegram, собрать эффектную презентацию в Yandex DataLens с помощью AI и многое другое.
Об открытии регистрации на воркшопы мы сообщим отдельно.

Переход на работу по лицензионному договору


Напоминаем, что до 1 сентября 2025 года мы начнём работать с вашей организацией по лицензионному договору. Переход не потребует действий с вашей стороны и не повлияет на работу с сервисами Яндекс 360 для бизнеса.
Переход займёт не более четырёх дней. В это время в вашем кабинете администратора будет показываться предупреждение — оно исчезнет, когда переход завершится.
Напоминаем также, что после перехода стоимость тарифа не будет облагаться НДС на основании подп. 26 п. 2 ст. 149 НК РФ.
Более подробную информацию мы отправили вам в письме от 22−23 июля — все детали вы также можете прочитать на сайте по ссылке ниже.
360.yandex.ru/business/new-legalentity/

Изменение списка адресов и портов


С 1 сентября изменится список адресов и портов, используемых Яндекс 360.
К прежнему списку IP-адресов добавятся:
37.9.69.0/24
37.9.118.128/25
5.45.251.0/24
141.8.148.0/25
77.88.42.0/24
77.88.43.0/25
Если в вашей компании настроена защищенная корпоративная сеть, разрешите доступ к новым IP-адресам.

Приглашаем на митапы about:cloud — infrastructure



Разработчики Yandex Cloud и Yandex Infrastructure приглашают вас посетить митапы about:cloud — infrastructure. В этом году мы впервые проводим их офлайн в нескольких городах.

Даты и города
Выберите город для участия и пройдите регистрацию.
21 августа — Казань
28 августа — Санкт‑Петербург
4 сентября — Новосибирск
11 сентября — Екатеринбург
16 октября — Москва (офлайн + онлайн)
events.yandex.ru/events/aboutcloud/index
В формате неформальной встречи обсудим нюансы разработки и устройство инфраструктуры «под капотом», расскажем о сложностях в разработке и как их избежать, подсветим самые нетривиальные подходы к развертыванию и эксплуатации облачных сервисов.

О чём расскажем
  • Как мы разделили плейны для обеспечения отказоустойчивости сети, а также про опыт развертывания и эксплуатации сетевого control-plane.
  • Как мы строим инфраструктуру поверх инфраструктуры.
  • Про разработку «железного» сервиса и нестандартную методику его тестирования.
  • Как обеспечиваем оптимальную работу сетевых дисков с сохранением производительности.
  • Про наш подход к автоматизации управления метаданными и оптимизацию их хранения в S3
  • Про проблему «серых» отказов в сети и как нам удалось её разрешить.

Переход на работу по лицензионному договору



До 1 сентября  2025 года мы начнём работать с вашей организацией по лицензионному договору. Переход не потребует действий с вашей стороны и не повлияет на работу с сервисами Яндекс 360.

Порядок платежей и списаний
Оставшиеся средства на счёте вашей организации будут перенесены автоматически. В процессе перехода баланс в кабинете администратора может отображаться некорректно — после перехода данные обновятся. Сам переход займёт не более четырёх дней.

Когда начнут действовать изменения
Ближе к дате перехода вашей организации мы пришлём письмо-напоминание со ссылкой на лицензионный договор и покажем предупреждение в кабинете организации — оно исчезнет, когда переход завершится.

После перехода стоимость тарифа больше не будет облагаться НДС на основании подп. 26 п. 2 ст. 149 НК РФ, поэтому у вас не будет возможности принять к вычету НДС в рамках этого договора.
Продолжая использовать сервисы Яндекс 360 для бизнеса после перехода, вы принимаете условия нового договора.

360.yandex.ru/business/new-legalentity/

Обновления Yandex BareMetal: теперь в Public Preview

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




Yandex BareMetal — это выгодно
Сервис позволяет арендовать ресурсы выделенных физических серверов по доступной цене и быстро начинать работу с техническими и бизнес‑задачами.
  • Разработка новых и развитие существующих информационных систем
  • Хостинг сайтов и веб‑приложений
  • Настройка тестовых сред
  • Хранение и обработка данных

yandex.cloud/ru/services/baremetal

Сбой с вероятностью один раз в 20 лет: о мартовском инциденте в дата-центре



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ов. Мы публикуем этот разбор в том числе для того, чтобы больше компаний могли оценить подобные риски для себя и заранее подготовиться к возможным инцидентам. Чтобы не повторять чужой опыт в подобной ситуации, лучше быть готовым ко всему: знать, как может развиваться проблема, для более быстрой диагностики и минимизации последствий.