Превращение в «жука»: эволюция 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

Обновление Yandex BareMetal: показываем самые популярные сценарии



Сегодня мы выпустили в публичное превью сервис по аренде выделенных серверов Yandex BareMetal — теперь пользователи облака могут арендовать у нас серверы и интегрировать их с облачной средой. С сервисом можно работать по API, а также гранулярно настраивать права доступа к серверам за счёт интеграции с Yandex Identity and Access Management.

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

Что важно для компаний, которые арендуют физические серверы
По данным исследования Yandex Cloud, 59% российских компаний начали использовать услуги аренды физических серверов относительно недавно, в последние 1,5 года.

Какие облачные сервисы наиболее актуальны при интеграции с bare metal:
  • сервисы защиты от DDoS‑атак (59% респондентов);
  • сервисы резервного копирования (48% респондентов);
  • облачный роутер — единая сеть между выделенными серверами и облачной инфраструктурой (46%).

Для чего чаще всего применяют технологии bare metal:
  • для хранения и обработки данных — 70% респондентов;
  • для собственных виртуализаций, например, Openstack или VMware — 66%;
  • для хостинга бизнес‑приложений — 47%;
  • для задач бэкофиса — 44%.
На примере сервисов Yandex Cloud далее мы увидим, как могут решаться разные задачи благодаря интеграции облачных сервисов c выделенными физическими серверами.

Сценарии интеграции с сервисами резервного копирования
Традиционно в составе облачной платформы задача по безопасному и надёжному хранению данных решается при помощи двух технологий:
  • Встроенные в платформу облака технологии защиты дисков виртуальных машин. В случае Yandex Cloud стоит вспомнить про снимки дисков виртуальных машин.
  • Технология объектного хранилища, которая подходит не только для задач по хранению данных приложений, адаптированных к облачной инфраструктуре, но и для хранения резервных копий.

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

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

Какую технологию использовать?
Ответ на вопрос кроется в использовании дополнительных, или наложенных решений для защиты информации. Примером такого облачного сервиса может быть Yandex Cloud Backup, который решает задачи по резервному копированию данных не только для защиты виртуальных машин, но и физических серверов в сервисе Yandex BareMetal. Поскольку физический сервер остаётся неизменным атрибутом традиционной ИТ‑инфраструктуры, то для него важно предусмотреть защиту на всех уровнях. Raid‑массивы призваны защитить от потери данных при выходе из строя одного или нескольких накопителей/блочных устройств. Если же из строя выходит целый сервер, то понадобятся как раз такие специализированные решения.

Как работает интеграция. Cloud Backup использует специализированный агент, который устанавливается в ОС физического сервера, за счёт чего появляется возможность выполнять операции резервного копирования:
  • для всех блочных устройств в составе сервера;
  • для определённых блочных устройств в составе сервера;
  • для определённых файлов и папок (директорий);
  • для данных приложений, требующих контроля целостности (базы данных);
  • также следует отметить, что грамотная настройка стратегии защиты (стратегии резервного копирования) положительно влияет на показатели RPO и RTO.

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

Такая правильно настроенная интеграция с Cloud Backup решает задачу защиты данных от потери на физическом серверном оборудовании в рамках «одного окна», не покидая консоль Yandex Cloud.

Сценарии интеграции с объектным хранилищем
В контексте физических серверов S3-совместимое хранилище может решать несколько задач.

Опция 1. Клиент решил перенести нагрузку из виртуальной машины на физический сервер, при этом приложение использовало технологии облака, и часть данных приложения размещались в S3-хранилище.

Опция 2. Клиент разворачивает на bare‑metal‑серверах кластер баз данных, например, кластер PostgreSQL высокой доступности. Технологии кластеризации, обеспечивающие репликацию данных между всеми вычислительными единицами в кластера позволяют решить задачу доступности базы для конечных потребителей, однако эта технология не помогает защитить данные от порчи или утраты, в случае повреждения базы данных.

Для решения задачи по защите данных следует применять стратегию защиты с использованием технологии Point‑in‑Time Recovery (PITR), которая позволяет восстановить состояние кластера на любой момент времени в интервале от создания самой старой полной резервной копии до архивации самого свежего журнала опережающей записи (Write Ahead Log, WAL). Это позволит приблизить показатели RTO и RPO к минимальным значениям, а хранение резервных копий и WAL транзакций в объектном хранилище (S3) обеспечит сохранность резервных копий.

Основное отличие второго сценария в том, что схема защиты выстраивается на уровне базы данных, защита может быть выполнена без использования дополнительного ПО.

Как работает интеграция с S3-хранилищем в случае с PostgreSQL?
Для реализации потребуется решить две задачи:
  • Подключить кластер к объектному хранилищу с использованием FUSE‑драйвера, которым, например может выступить GeeseFS, оптимизированный для работы с Yandex Object Storage.
  • Интегрировать приватные подсети BareMetal с объектным хранилищем (S3) через сервисное подключение. В решении данной задачи поможет технология Cloud Interconnect, при помощи которой серверы BareMetal смогут взаимодействовать с приватными подсетями в Virtual Private Cloud.

Из каких кубиков складывается головоломка, или как решить задачу?
  • Создать VRF и приватную подсеть в BareMetal.
  • Арендовать физический сервер.
  • Создать сервисное подключение к S3 (Private Endpoint) в одной из имеющихся подсетей в VPC. Смотрим на документацию.
  • Настроить интеграцию с подсетями VPC (из BareMetal в VPC) через Cloud Interconnect. Смотрим на документацию.
  • Если используется собственный DNS‑сервер, создать необходимые ресурсные записи для направления трафика к S3-хранилищу на IP‑адрес сервисного подключения.
Если приватный DNS не используется в BareMetal‑контуре, настроить сопоставление через файл /etc/hosts (storage.yandexcloud.net <--> в IP‑адрес сервисного подключения).

Итоговая диаграмма сетевой связности для доступа к S3 будет выглядеть следующим образом:


Безусловно, доступные сценарии не исчерпываются этими примерами: так, в прошлый раз мы рассказывали о возможностях собственной виртуализации. Однако благодаря появившейся в обновлении интеграции с Cloud Interconnect, а также с расширением функциональности работы через API — можно выстроить и более сложные архитектурные сценарии.

Приглашаем на BareMetal CyberChamp

Приглашаем вас на BareMetal CyberChamp — товарищеский турнир по Dota 2 среди сотрудников Яндекса и клиентов Yandex Cloud, в числе которых: 1С Game Studio, R‑Vision, Иви, ФК Динамо Москва и другие.

Регистрируйтесь и присоединяйтесь к трансляции финала 29 марта, где встретятся команды‑победители группового этапа.

А ещё вас ждёт:
  • экспертная сессия с представителями 1C Game Studio, Astrum Entertainment и сервиса Плюс Гейминг, которые обсудят текущее видение отрасли и поделятся мнением о трендах и технологиях в игровой индустрии;
  • открытый диалог, где мы расскажем о сервисе Yandex BareMetal в преддверии его большого обновления;
  • квиз по Dota 2 c розыгрышем призов.
Мы поддержим онлайн‑трансляцию турнира на выделенных серверах Yandex BareMetal, что обеспечит стабильность и высокое качество стриминга.

champ.yandex.cloud



Yandex BareMetal — не только для gamedev
  • Yandex BareMetal — это сервис по аренде выделенного физического сервера, все ресурсы которого доступны для решения только ваших задач.
  • Защищённые дата‑центры, соответствующие требованиям 152‑ФЗ, стандартам ISO, PCI DSS и ГОСТ Р 57580
  • Готовые конфигурации с возможностью установки своих средств виртуализации, ОС и ПО
  • Дополнительные вычислительные мощности, которые можно оперативно получить для проведения тестирований и поддержки текущих и новых сервисов
  • Управление через KVM в консоли Yandex Cloud или по SSH‑протоколу, контроль доступа с помощью IAM