Внешний вид дата-центра
У Яндекса есть дата-центр мощностью 65 мегаватт, который работает действительно давно. В нём есть разные платформы: одни из них были подключены раньше и до сих пор в работе, а другие мы придумали и затем внедрили чуть позже. Очень интересно изучать по ним историю и смотреть, как развивалась компания с точки зрения аппаратной составляющей и серверных платформ. Я стараюсь отправлять новичков на экскурсию в этот дата-центр.
В начале развития Яндекс был маленькой компанией, которая покупала девятнадцатидюймовые серверы. По мере роста появилось желание эффективно развиваться, экономить электричество и грамотно отводить тепло. Хотелось сделать инфраструктуру эффективной. Мы изучали опыт других компаний, например ОСР (Open Compute Project). Она делает открытые спецификации, в том числе для гиперскейлеров. Поэтому что-то пробовали, заходило — оставляли, не заходило — отказывались от этого и шли дальше.
Открытые проекты про сетевое оборудование
Есть открытые проекты не только про серверные платформы, но и про сетевое оборудование. Чипы в коммутаторах специализированные и узконаправленные, и это не то же самое, что процессоры x86, которые делают в разы чаще. Сделать свой коммутатор сложно, потому что производителей чипов меньше и они ограничивают доступ к SDK этих чипов, и в целом этот рынок довольно закрытый.
По факту коммутатор — это не просто чип, в нём также есть операционная система. Раньше классические вендоры сетевого оборудования, например Cisco, Juniper, Arista, никому не давали доступ. Потом началось движение в сторону дезагрегации и отделения операционной системы от аппаратной части, открытия платформ. Например, есть открытая операционка KUMUS. На самом деле она платная, но может быть одна на несколько моделей. Можно иметь одну операционку и при этом купить несколько аппаратных моделей разных производителей. То есть появляется некая диверсификация.
Например, Microsoft предлагает тем, кто продаёт им свитчи, поддерживать их программно-аппаратный интерфейс SI для взаимодействия с железом. Это принесло чуть больше открытости на рынок. Сейчас это направление есть в том числе в России. Недавно я был на конференции и могу сказать, что есть большой интерес на рынке, в том числе на российском. Ребята хотят развиваться в этом направлении.
Открытая операционная система
На рынке известно, что Яндекс делает для себя серверы, и мы очень часто говорим об этом. При этом мы также часто рассказываем про сетевую часть и наши эксперименты с операционными системами. Достаточно вспомнить все выступления Антона Кортунова (Антон Кортунов — техлид направления инфраструктурных сервисов, Яндекс — прим. ред.) за последние два с половиной года.
Об открытой операционке на свитчах и о коммутаторах собственного производства можно сказать следующее:
- Надо понять, для чего вы хотите это делать. Если экономика — главный фактор, то не всегда это экономически выгодно. Скорее всего, это будет эффективнее, но не настолько, чтобы вы точно захотели идти туда и заниматься этим.
- Может быть, вы хотите делать свои СВЧ. Делать СВЧ не очень просто, но я лелею мысль сделать полностью свою стойку с коммутатором, убрать лишние блоки питания и вентиляторы, создать единый конструктив. Единый конструктив экономит электроэнергию, но не сильно. Один сервер потребляет 10 кВт, а коммутатор — 300–500 Вт. Я скорее за разумный подход, то есть иногда это действительно надо, и мы думаем в этом направлении. Но есть нюансы.
Как правильно построить сеть
Прежде чем строить сеть в дата-центре, надо понять, для чего это нужно, что это за дата-центр, какие нагрузки у вас есть. Потому что заказчики, компании, паттерны и шаблоны нагрузки разные. Может быть, вы строите дата-центр на 10 стоек. Или коммерческие дата-центры на 4000 стоек, но с невысоким подведением питания конкретно на одну стойку. Возможно, вы строите дата-центр такого же масштаба, как в Яндексе: мощностью 40–60 мВт и довольно высоконагруженными стойками.
Есть много типовых дизайнов от сетевых вендоров. Если вы в них укладываетесь и если вас это удовлетворяет, лучше так и делайте. Это проще, понятнее, и в итоге будет меньше багов.
Уроки, которые я получил в ходе работы над инфраструктурой
В моём подразделении есть две части: первая отвечает за облако, другая — за инфраструктуру Яндекса. За пять лет, что я работаю в компании, мы проделали огромную работу, которая связана с унификацией двух подразделений и с облегчением сетевого дизайна.
Как только вы начинаете требовать от сети и от сетевых коробок меньше, вам становится гораздо проще жить, потому что там нечему ломаться. Смотря на опыт развёртывания последнего дата-центра, могу сказать: чем проще сеть и чем лучше отточена автоматика, которую вы сделали до запуска, тем проще пройдёт запуск.
Если вы запускаете современную сеть в дата-центре, то советую использовать типовой дизайн. Если масштабы дата-центра небольшие, используйте решение вендора. Например, VPN Vix Lan отлично работает. Если вам не нужно сильное масштабирование, то можно не смотреть на компании типа Яндекса, Google, Amazon. Я выступаю за те решения, которые можно и нужно применять. Есть разные масштабы, при которых нужно правильно выбирать решения. Чем проще решение, тем лучше.
Не забывайте обязательно подводить к дата-центру три кабеля. Летом 2023 года при строительстве трассы у нас два раза были двойные обрывы.
Про сетевые аварии
По этой теме на nexthop был отличный доклад Саши Деева «Оптимизируем работу с инцидентами и задачами. Делаем работу эффективнее и дешевле», который я рекомендую посмотреть. Саша Деев — руководитель дежурной смены, и он знает всё про то, как заводить протоколы, вести инциденты, контролировать это, делать ретро.
99,9% сетевых аварий решаются простыми и понятными способами:
1. Понять, было ли какое-то действие или какие-либо плановые работы. Если были, то 99% аварий лечится откатом, то есть откатываемся к предыдущему, заведомо рабочему релизу.
2. Если всё-таки не было никаких действий в системе, то нужно локализовывать аварию. Снимать нагрузку, вводить разные элементы и в целом искать то место, где действительно есть проблемы.
Посмотрите на то, какие проблемы у вас бывают, сделайте ретроспективу и поймите, чего не хватает. Начните классифицировать эти проблемы. Разбирая их, вы поймёте, где у вас больше всего болит. Самое важное, чтобы не было проблем через год или два. Если у вас будет векторное движение по улучшению системы, то у вас всё хорошо.
Я выступаю не за те системы, в которых оператор сидит 24/7 и смотрит в монитор. Я скорее за то, чтобы при алармах, например нарушении SLA, автоматически заводили протоколы и звонили дежурным. Система видит нарушение сбоя в SLA/SLO и даёт сигнал человеку, что нужно что-то делать. Я бы порекомендовал это.