Как и почему мы проектировали последнее коммерческое облако России и от какого буллшита избавились по ходу
Меня часто спрашивают:
— Почему к вам, а не к гигантам?
Ответ простой:
— Мы не охреневшие.
Сначала я хотел рассказать про нашу сеть хранения, которая быстрее, чем скорость записи на RAID 0, про удивительное конкурентное преимущество «Трезвая поддержка», про 400G‑линки на каждом хосте, про изоляцию сетей и топологию Dragonfly+ с full mesh на уровне зон доступности. Но всё‑таки я решил: самое главное, что мы не охреневшие.
Это главная штука, которую мы решили для себя со старта.
А теперь расскажу, что же мы последовательно делали и что запускаем.
Это прототип нашего облака, сейчас ЦОД выглядит чуть иначе
Вот примерно так одна из площадок выглядит
Площадки и зоны доступности
Основные площадки — это три наших локации в Москве в пределах МКАДа (часть вообще внутри Садового) с новым типом инфраструктуры — когда снаружи непонятно, что это ЦОД, и инфра не собирается в маленький плотный кубик в очевидном месте.
Плюс два московских дата‑центра: IXcellerate North (Север) и IXcellerate South (Юг). По мере готовности двух наших площадок мы мигрируем из IXcellerate в них. Сами точки присутствия мы тоже хитро организовали. Заводить 50 разных операторов в своё свежеоборудованное здание — неприкольно. Поэтому у нас понятный транзитный процесс, который мы скоро завершим: остаётся бордер для стыковки с внешними сетями и пара серваков для резерва внутренней инфры в одной точке, такой же бордер и пара серваков в другой.
И между ними обеими, а также между основной точкой, где всё развёрнуто, проложена хорошая оптическая связь независимыми маршрутами.
Итого у нас получается 5 зон доступности (по 2 внутри IXcellerate/новых и одна на самой первой локации), будет 6. Зоны доступности — это полностью изолированные инфраструктуры: свои непересекающиеся сетевые железки, свои отдельные энерговводы, своё охлаждение, свои источники бесперебойного питания. Полностью. Выход из строя оборудования в одной зоне доступности никак не должен затронуть другую.
Кроме того, у нас есть ЦОД в Александрове, где развёрнуты AZ с воздушным и жидкостным охлаждением, включая иммерсионное. Это отдельные зоны, потому что там разные системы охлаждения и разные физические помещения. Топим мы только старое и десктопное железо, потому что найти серверное оборудование, сертифицированное под иммерсионное охлаждение, практически нереально. Там мы не ставим коммерческих клиентов облака.
Также у нас была точка присутствия в дата‑центре 3data, из‑за которой нас называли перекупами, и, что очень важно, на М9 — главном телекоммуникационном узле в России. Здесь мы можем быстро сделать физический линк с кем угодно, организовать прямой коннект для клиентов, затащить любого оператора, которого нет в основных ЦОДах (хотя там есть практически все). Фактически это наш третий Meet‑Me Room.
Сейчас мы подключаемся к точке обмена трафиком MSK‑IX. Зачем? Это даёт невероятную гибкость: мы можем пириться с кем угодно, как угодно, очень быстро и легко. Можно дать трафик на пользователей любого провайдера напрямую, не поднимаясь на вышестоящих операторов. Это как ещё один Meet‑Me Room, но уже виртуальный.
Связь
Между ключевыми площадками (обоими IXcellerate, М9, 3Data и офисом) мы взяли тёмное волокно, которое нам любезно предоставил «Мастертел», и засветили его на 400 Гбит/с. Про новое — деталей не будет, простите, мы решили поменьше открывать варежку про такие вещи, но уровень тот же.
В будущем планируем расширять ёмкость с помощью DWDM.
Связь с Александровом пока реализована через 10-гигабитный интернет от Ростелекома и 10-гигабитный L2 VPN‑канал до М9. Суммарной пропускной способности в 20 Гбит/с для этой площадки более чем достаточно. Работаем над строительством оптических трасс, но это небыстрая история.
Для сравнения: пиковый трафик всего Cloud.ru, по словам их бывшего сетевого инженера, не превышал 40 Гбит/с. У нас восемь внешних аплинков по 100 Гбит/с.
В каждом из ключевых ЦОДов ядро сети вынесено в отдельный независимый по питанию и инфраструктуре модуль — Meet‑Me Room. У нас прямо трассы с кросс‑панелями: всё красиво разведено. В каждом MMR у нас по четыре линка от разных провайдеров (два основных, два резервных). Мы специально проверяли, чтобы их трассы физически не пересекались и не приходили в один и тот же маршрутизатор.
Суммарная ёмкость каналов — 800 Гбит/с. Это мегаоверкилл, но такой запас — это фундамент для нашего собственного сервиса анти‑DDoS. Мы сейчас внедряем его на базе коммерческой версии одного open‑source‑решения, и, скорее всего, на старте он будет встроенным и бесплатным для всех клиентов.
Вся эта сложная система из AZ, MMR и ЦОДов построена по топологии Dragonfly+. Если упрощать, то каждая AZ и каждый MMR — это независимая группа узлов. В группе серверов — классический Клоз (Node‑Leaf‑Spine). Между всеми группами — full mesh. Это даёт потрясающую отказоустойчивость.
Представим себе худший сценарий: в одном из ЦОДов IXcellerate полностью выходит из строя MMR. Это значит, что все четыре внешних аплинка в этом ЦОДе отваливаются. Что произойдёт? Ничего критичного. Во‑первых, каждая зона доступности в этом упавшем ЦОДе напрямую связана с зонами доступности в другом ЦОДе через те самые 400-гигабитные каналы. Трафик просто пойдёт через бордер второго ЦОДа. Система спроектирована так, чтобы пережить отказ любого компонента.
Железо
Одно‑ и двухюнитовые серверы HPE 11-го поколения. На борту у них:
- Процессоры Intel Xeon 5-го поколения.
- По 2 терабайта оперативной памяти DDR5.
- NVMe для операционной системы и как сверхбыстрые локальные диски для кластерных баз данных (когда у вас кластерная СУБД, ей не нужен сетевой диск, а локальный NVMe даёт сумасшедшую скорость) и SSD для объединения в storage‑сеть.
- Опционально — GPU. Сейчас это в основном NVIDIA, уже наладили закупку B300 для задач инференса и нашей будущей дата‑платформы. GPU мы продаём не поминутно, а с долгосрочным коммитом — минимум на год.
Следующая закупка — это либо HPE 12-го, либо Dell 17-го поколения. Там уже Xeon 6-го поколения.
В сервере стоят две сетевые карты по два порта 100G. Каждая карта подключена к двум разным ToR’ам (лифам). Лифы, в свою очередь, соединены с двумя спайнами. Отказ любого кабеля или коммутатора не приводит к потере связности. Ну и, конечно, в каждой стойке — два независимых ввода питания. Сети задублированы на всех уровнях. При этом нам доступна вся полоса в 400G.
Каждый хост соединяется с тремя независимыми сетями:
- Управление железом (iLO/MGT): отдельная полностью изолированная сеть для управления физическими устройствами.
- OOB: ещё одна физически изолированная сеть с линками 2×25G для управляющих команд, обновлений, метрик и внутреннего доступа хостов. Даже если основная фабрика ляжет, то доступ к хостам останется.
- Основная фабрика: 400G‑сеть для Control Plane и Data Plane. Через Control Plane общаются наши кластеры. Сервисы управления говорят кластеру нагрузок, какие именно ресурсы должны быть и в каком состоянии (да, кубер оперирует понятием «желаемое состояние»). Это отдельный сегмент. Data Plane (SDN + SDS) — это второй отдельный сегмент 400G‑фабрики для трафика клиентских виртуальных машин и сетевых дисков.
Приоритеты трафика разграничиваются через QoS. Сами сети изолируются либо физически, либо через VRF без route‑leaking. Помимо Data Plane и Control Plane, есть ещё четыре служебных сегмента, но о них — как‑нибудь отдельно.
Доступность
Мы делаем гиперскейлер. Гиперскейлер — это про доступность и отказоустойчивость. В нашем случае — на уровне виртуальной машины. Под ней может ломаться что угодно, но если она может быстро и бесшовно мигрировать с сервера на сервер — это норм. Сейчас наша цель — обеспечивать SLA на уровне 99,5%.
К концу года мы целимся в SLA 99,99% для двух виртуальных машин, запущенных в разных зонах доступности, и 99,97% — для одной виртуальной машины или любого другого сервиса. Для дата‑центра уровня TIER-3 — это 99,982% доступности. Наши 99,99% для разнесённых виртуалок — это уже выше. А стоят они в двух сертифицированных TIER-3-ЦОДах и одном несертифицированном.
Выше TIER-3 не прыгнуть. Плюс доступность там считается без учёта времени простоя сети, то есть просто по включению. Ну, точнее, можно поискать Tier-4, но оно того обычно не стоит.
У нас доступность считается с сетью. И это доступность сервисов ВМ, а не пинг до гипервизора. Чтобы ваш сервис упал всего на несколько минут в год, даунтаймы ЦОДа, даунтаймы интернет‑провайдера и даунтаймы самого сервера должны совпасть в одном временном окне. Но так не бывает. Даже надёжный сервер Hewlett‑Packard 12-го поколения в первый год эксплуатации требует около четырёх часов регламентного простоя, плюс его нужно перезагружать для апдейтов.
В облаке таких проблем нет.
Вероятно, мы нарушим это обещание. Такое случается при авариях или идиотских проблемах. Сейчас, на период обкатки в продакшене, уровни гарантий для публичного облака выглядят у нас так:
- Если доступность между 99,5 и 99% — 10% скидки.
- Если доступность 95–99%, то 15% скидки.
- Ниже 95% — 30% скидки.
Убедившись, что с этим справляемся, мы перейдём к более жёстким SLA:
- Если доступность между 99,97 и 99% — 10% скидки.
- Если доступность 95–99%, то 30% скидки.
- Ниже 95% — расчётный период бесплатно.
Для приватных инсталляций возможны ещё более жёсткие гарантии, обсуждаемые в индивидуальном порядке.
По БПЛА‑форсмажорам пока не отвечу, мы в переговорах со страховщиками.
Как же мы достигаем такой надёжности? За счёт правильной физической архитектуры и живой миграции. В этом и есть смысл облаков — воткнуть сервисы в две разные зоны доступности и получить надёжность выше, чем у любого физического ЦОДа. Потому что упасть может что угодно: отдельный сервер, стойка, вся автономная зона, ЦОД или даже целый регион. Наша задача — минимизировать вероятность такого события и его последствий.
Софт
А теперь самое интересное — софт. Мы не используем OpenStack, CloudStack, китайский Z‑Stack или модный Cozy (как мы его прозвали, «козий стек»). Наша платформа — полностью собственная разработка. Почему? Потому что мы всё это попробовали и поняли, что лучше не надо. Если вы нас читаете, то видели часть этих экспериментов.
Любой фреймворк — это компромисс. Ты получаешь что‑то «из коробки», но быстро упираешься в его ограничения. Например, в нижележащей системе есть нужная тебе функция, а API фреймворка её ещё не поддерживает. И ты ничего не можешь с этим сделать. Мы прошли этот путь на раннем этапе беты, когда использовали гибрид из Cozy Stack и наших сервисов, и в итоге приняли решение выпилить его полностью и написать всё с нуля.
Ещё одна важная причина — сертификация. Ни один OpenStack никогда не пройдёт серьёзную сертификацию ФСТЭК или 152-ФЗ УЗ-1.
А собственная разработка может. Мы сейчас как раз этим и занимаемся. Конечно, есть нюанс: при каждом обновлении системы сертификат ФСТЭК нужно получать заново, а это дорого — услуги испытательной лаборатории стоят порядка 400+ тысяч рублей за раз. Как показывает опыт, многие коллеги получают его один раз на какую‑то версию, вывешивают на сайт, а в продакшене крутится уже совсем другое. Мы же для приватных инсталляций будем поддерживать сертифицированные версии, потому что нашли более правильный путь беспрерывной сертификации изменений.
В основе — Kubernetes. Причём мы используем его не только для управляющего контура (control plane), но и для оркестрации всей клиентской нагрузки, включая виртуальные машины. Когда мы накидывали архитектуру с собственным оркестратором, то в какой‑то момент посмотрели на результат и поняли: «Так вот же он, Кубер!» Зачем изобретать велосипед, если есть прекрасный стек технологий, который отлично с ним интегрируется: kubevirt — для виртуализации KVM, Linstor — для SDS, и не без боли — Kube‑OVN — для SDN.
Правда, это не навсегда. Для публичного облака мы уже видим пределы Kubernetes по масштабу и перепиливаем отдельные компоненты. Сейчас переходим на мультикластерную систему.
Для виртуализации мы выбрали самый нативный и стандартный для Linux‑мира стек: KVM — в качестве гипервизора и QEMU — для эмуляции аппаратного обеспечения. Это компоненты, встроенные прямо в ядро Linux. Некоторые конкуренты используют Xen или VMware, но сегодня KVM — это де‑факто стандарт индустрии, и изобретать тут что‑то своё просто не имеет смысла.
Хранение
Вычисления и хранилище находятся на одних и тех же физических серверах. За хранение отвечает система Linstor с DRBD под капотом. Это гиперконвергентная архитектура.
Работает это так: все SSD‑диски на сервере отдаются JBOD. Да, вы не ослышались: JBOD, который не даёт никакой отказоустойчивости, но обеспечивает максимальную производительность. Мы превращаем диски в одну большую быструю «мясорубку». Linstor поверх этого массива нарезает тома для виртуальных машин (с помощью LVM‑thin).
Надёжность обеспечивает DRBD. В тот момент, когда Linstor создаёт том на одном сервере, он тут же создаёт и его полную синхронную реплику на другом, который находится в другом домене отказа, и опционально — в другой зоне доступности. Наше хранилище знает топологию облака и понимает, что реплицироваться нужно в соседнюю геоточку.
Если один сервер (или все его диски разом) выходит из строя, то система мгновенно переключается на работу со второй репликой. Пользователь даже не заметит этого. Репликация синхронная, но за это приходится платить оверхедом. Вообще DRBD поддерживает три схемы репликации: Protocol A — полностью асинхронная, Protocol B — синхронная in‑memory (операция считается выполненной при записи на primary‑диске и при записи в память на ноде с secondary‑диском) и Protocol C — полностью синхронная.
Оверлейные сети
На заре нашего проекта, в бете, всё было просто: каждая виртуалка получала белый IP‑адрес. Это было щедро, но небезопасно: никакой изоляции между клиентами на сетевом уровне. Естественно, нас это не устраивало.
Мы выбрали Kube‑OVN для создания программно‑определяемой сети (SDN). Решение отличное, но очень непростое в настройке. Наш сетевик пытался расспросить всех, до кого только мог дотянуться (а в списке были ведущие архитекторы крупных российских клаудов), а они лишь пожимали плечами. Помню, я потратил два дня на траблшутинг проблемы, почему пакеты не ходят из VPC во внешний мир при правильно настроенном (прямо по инструкции) шлюзе. Пришлось обвесить всё tcpdump'ом и на уровне каждого пакета отслеживать его путь.
Проблема оказалась в связке конфигурации VPC и NAT Gateway — виртуального маршрутизатора, который стоит на границе VPC и Интернета. Пакеты извне на него приходили, он их отправлял внутрь VPC, адресат их получал, а вот ответные пакеты обратно не уходили. И хоть ты тресни! Оказалось, что вещь, которую в документации преподносили как опцию — статические маршруты, — на самом деле является обязательным компонентом. Без прописанных вручную маршрутов к этому NAT Gateway ничего не работало. Мы победили эту проблему.
Следом мы научили систему анонсировать белые IP‑адреса клиентов по BGP. Дефолтный способ работы (ARP) нам не нравится, потому что это L2, а в нашем масштабе он был бы ещё и растянутым, что есть конкретный антипаттерн. Буквально до текущей версии Kube‑OVN не умел корректно анонсировать /32 специфики по BGP и хотел слать целые подсети. Сейчас всё работает как надо. Когда NAT Gateway получает IP‑адрес, с ноды, где он запущен, улетает анонс маршрута /32 нашему пограничному маршрутизатору с помощью BGP‑спикеров. В результате IP становится доступен из всего мира.
Сейчас в арсенале сетей у вас есть:
- Неограниченное количество VPC и подсетей.
- SNAT: все машины внутри VPC могут выходить в интернет через один общий белый IP.
- DNAT: можно пробрасывать трафик с внешнего IP на разные машины и порты внутри VPC по гибким правилам.
- FIP: можно привязать IP к хосту в формате 1:1.
- Static Routes: можно задать любые статичные маршруты внутри VPC между подсетями.
- Policy‑based Routes: то же самое, что и static, но с более гибкой настройкой по условиям.
- Security Groups (читай: файрвол), правила которых применяются на уровне шлюза или отдельного хоста. Тоже без ограничений.
Для оптимизации производительности мы применяем продвинутые приёмчики, среди которых — Mellanox ASAP для аппаратного ускорения и eBPF‑bypass для трафика между ресурсами на одной ноде.
По умолчанию мы создаём рабочую конфигурацию: VPC, сабнет, NAT Gateway с белым IP, SNAT‑rule и Static Route. Всё работает «из коробки». Но мы даём пользователям и тонкие настройки. Правда, тут есть нюанс: если вы не понимаете, что делаете, то появляется миллион способов выстрелить себе в ногу. Поэтому наш совет: если не уверены, то используйте дефолтные настройки.
S3, IAM, биллинг и бэкапы
Мы даём S3-совместимый API для объектного хранилища, чтобы клиенты могли легко перенести свои приложения с Amazon AWS, просто сменив эндпоинт.
Сейчас для скорости мы развернули его на базе Ceph и RADOS Gateway. Но, честно говоря, RADOS Gateway — это так себе решение. Оно начинает деградировать при большом количестве объектов и упирается в производительность одного Ceph‑кластера. Поэтому мы уже пишем собственный API‑шлюз. Он будет работать с группой независимых Ceph‑кластеров, распределяя нагрузку и данные между ними. Этот шлюз будет взаимодействовать с RADOS, который, в отличие от RADOS Gateway, как раз хорош. Это позволит нам масштабироваться практически бесконечно и проще управлять репликацией между автономными зонами.
Сервис управления пользователями и правами доступа (IAM) мы писали с нуля, вдохновляясь архитектурой AWS. Нас интересовало, как они обрабатывают более миллиарда запросов в секунду. Чтобы не перегружать основной сервис, существует легковесный Authentication Runtime Service. Он кэширует необходимые данные и выполняет быструю проверку прав доступа для каждого API‑вызова, будь то чтение объекта из S3 или создание виртуальной машины.
Ключевой принцип безопасности, который мы заложили: API‑ключ можно увидеть только один раз при создании. Дальше он не подлежит чтению, его можно только проверить. Никто, даже мы, не сможет его восстановить. Потерял — перевыпускай новый. Это не шутка. Умный учится на чужих ошибках. Перевыпустить ключ — дело двух кликов.
Биллинг — целая пачка микросервисов, которая должна работать строго консистентно и идемпотентно. Идемпотентность означает, что случайный повторный запрос на списание не спишет деньги дважды. Система должна корректно обрабатывать пополнения через платёжные шлюзы, не допуская фрода, и, конечно же, автоматически останавливать ресурсы пользователя при нулевом балансе. Да, на старте у нас была забавная ситуация, когда ресурсы при нулевом балансе не прибивались. Тем, кто нашёл эту дыру, мы разрешили пользоваться ею до исправления). Багбаунти, кстати, пока нет (хотя коллеги и бета‑тестеры уже накидали пару раз в панамку), про неё думаем.
Бэкапы реализованы через снапшоты. Linstor, используя LVM‑thin, умеет делать мгновенные снимки дисковых томов. Эти снапшоты мы выгружаем в наше S3-совместимое объектное хранилище. Снапшоты, кстати, тоже есть — можно зафиксировать состояние диска в моменте и разворачивать из него виртуалки сколько угодно.
Важно, что хранилище для бэкапов работает на совершенно других, выделенных серверах. Кроме того, у нас есть партнёрство с «Киберпротектом» (это, если что, бывший Acronis, который разделился на Acroni~1 и Acroni~2 с момента начала санкций) для защищённых резервных копий в отдельном хранилище. Прямо под капотом их нет, но по запросу мы их включим.
А для самых параноидальных клиентов мы рассматриваем внедрение ленточных хранилищ. Звучит как анахронизм, но на самом деле — очень крутая штука. У ленты есть одно убойное преимущество — её нельзя заразить шифровальщиком. В смысле можно, но нельзя. Лента надёжна.
Поддержка
Помните историю про «Ваша виртуалка на согласовании» из одного энтерпрайзного облака, когда это должно решаться одной кнопкой в личном кабинете? А вот у кого‑то она до сих пор на согласовании. У кого‑то поломался биллинг, и, когда его починили, заблокировали треть пользователей разом без предупреждения. А у людей — праздники. Как им срочно пополнять баланс? И ответ один: «Не нравится — идите на...» Где‑то надо смотреть 40-минутный вебинар, чтобы разобраться, как поднять простенький сайт…
Мы другие.
Мы небольшая команда инженеров, которая строит продукт для таких же инженеров. Мы — это вы.
И хотим и дальше так делать.
Мы, конечно, накосячим по дороге, и не раз. Но мы быстро всё исправим. И услышим вас. И даже если не будем делать то, чего вы просите, то ответим.
Сейчас мы небольшого размера — сотни серверов. Это топовое современное железо, которое производительнее «среднего по рынку» в несколько раз. Так что по мощности мы соответствуем среднестатистическому облачному провайдеру. Какого размера мы хотим быть? Просто передам привет Селектелу, МТСу и Сберу.
Друзья, мы пришли на этот рынок всерьёз и надолго.
h3llo.cloud