Четвёртая будет? Как мы развернули ещё одну зону доступности в нашем ЦОД
Мнение экспертов

Четвёртая будет? Как мы развернули ещё одну зону доступности в нашем ЦОД

1014
7 минут

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

Три котика

К моменту завершения работ над инфраструктурной частью всё больше заказчиков стало спрашивать, когда у нас в облаке появится третья зона доступности. Нам уже не приходилось доказывать необходимость развертывания ещё и вычислительной инфраструктуры — сейлы сами просили сделать её поскорее. Наше представление о том, как правильно, не только совпало с реальными потребностями рынка и с запросами пользователей, но и позволило нам серьёзно повысить надёжность сервисов, обеспечивающих работу облака, благодаря резервированию и распределению нагрузки между площадками. А перенос Control Plane облака на виртуалки позволил оптимизировать использование железа в условиях его ограниченной доступности на рынке.

Ниже мы расскажем как внедряли Compute в третьей зоне доступности в теперь таком уже далёком 2021 году.

Не два, а полтора: снижение нагрузки при аварии

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

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

С тремя же AZ распределение более мягкое: если нагрузка «размазана» равномерно по всем AZ, то при отказе по двум доступным AZ требуется распределить лишь треть всей нагрузки. Таким образом, на случай аварии нужно резервировать меньшие мощности — иметь не двукратный, а полуторный запас.

Кто сверху, кто снизу

От начала первого этапа до начала второго — подготовки вычислительной среды для облака — прошло больше двух лет. За это время архитектура сети на третьей площадке морально устарела. На других площадках начался переход с InfiniBand на Ethernet, а в качестве целевой была выбрана архитектура Клоза (leaf-spine). Поэтому вычислительную часть было решено делать отдельным сегментом, а построенный на предыдущем этапе инфраструктурный сегмент со временем адаптировать и мигрировать.

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

Размещение оборудования в стойке

В каждую стойку поместили по два высокоскоростных коммутатора Mellanox SN2010, вместе они занимают один юнит в середине стойки, а над ними очень удобно располагается гигабитный коммутатор для out-of-band management. Все кабели разводятся в рамках одной стойки, никаких кросс-коммутаций в соседние стойки и между шкафами не делаем. Каждый сервер подключается двумя линками по 25 Гбит/с к этим двум коммутаторам. От leaf-коммутаторов к spine-коммутаторам идут линки по 100 Гбит/с.

Схема сети в новой зоне доступности

Отдельные стойки используются как сетевые, куда сводится вся коммутация и устанавливаются коммутаторы уровня spine, super-spine, management core, граничные и др. Дублирующее оборудование размещается в разных стойках. Всё как полагается.

Сетевая инфраструктура как код

Мы уже давно конфигурируем серверы с помощью Puppet, и вся конфигурация хранится в git. Однако, управление коммутаторами до этого осуществлялось стандартными средствами. С переходом на Ethernet у нас появились коммутаторы, которые можно настраивать как серверы. Мы их тоже начали конфигурировать с помощью Puppet, а конфигурации хранить в гитхаб.

Но сперва на множество появившихся у нас Ethernet-коммутаторов требовалось установить операционную систему. И, соответственно, встал вопрос, как автоматизировать эту процедуру. Cobbler, с помощью которого мы разливали ОС на серверы в облаке, для этой задачи не подходил из-за особенностей работы коммутаторов Mellanox. В частности, для инициализации они используют опции DHCP и протокол Zero-Touch Provisioning (ZTP).

В общих чертах процедура следующая. При первом включении «голый коммутатор» (bare metal switch) пытается найти у себя образ операционной системы. Если он его не находит, то тогда идет на тот веб-сервер, который ему сообщает DHCP в ответ на запрос IP-адреса. После установки ОС и перезагрузки коммутатор вновь запрашивает DHCP и запускает ZTP, который скачивает и выполняет скрипт для настройки коммутатора. Схожая процедура используется при обновлении ранее установленной ОС.

Для автоматизации мы выбрали Puppet, поскольку у нас уже был опыт по настройке с его помощью. Исходя из изложенного алгоритма, нужно было написать манифест Puppet, чтобы мы могли управлять модулем DHCP-сервера. Раньше DHCP-сервер у нас тоже настраивался вручную. Мы автоматизировали настройку DHCP-сервера под эту задачу и вместе с этим обучили его DHCP-опциям, с помощью которых коммутаторы узнают адреса для скачивания.

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

Два пишем, три в уме

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

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

Как пример, внутри VPC — изолированной среды, где пользователи развёртывают свои ресурсы — гарантируется связность между подсетями из разных зон доступности. Связь между площадками на тот момент мы организовывали с помощью своей автоматизации, а не средствами SDN. Поэтому правила OpenFlow для Open vSwitch, которые описывают как связать подсети VPC в разных AZ, были написаны просто, они были peer-to-peer (что-то вроде «трафик от такого VPC упаковать в такой туннель и отправить такому-то хосту»). В самих правилах не предусматривалось наличие больше одной «удалённой» AZ. Их пришлось переписать так, чтобы третья зона доступности могла быть включена в эту схему прозрачно, без переписывания вообще всех сетей.

Ключ на старт

После всей предварительной подготовки тестовое развёртывание и запуск облака прошли гладко: чётко по инструкции — никаких алертов в Sentry не было. Разве что по коду пришлось сделать пару микрофиксов, да устранить некоторые замечания по инфраструктуре — где-то мониторинг забыли настроить, где-то шаблон не навесили.

Большая часть облака обмазана автоматизацией, поэтому стадия развёртывания серверов прошла довольно легко — операционные системы разливаются по PXE, а конфигурации накатываются автоматизировано при помощи Puppet. В третьей AZ мы стали массово использовать новые коммутаторы, которые управляются Puppet, о чем подробно писали выше. К моменту развёртывания у нас уже была наработана по большей части автоматизация для сетевого оборудования, и его мы тоже настраиваем при помощи Puppet.

После развёртывания мы тестировали третью зону доступности в закрытом режиме несколько месяцев — тестировали HA-механизмы для вычислительных узлов и маршрутизаторов, проверяли работу Сapacity Planner, включение/отключение систем хранения и миграцию между ними... Но чего-то примечательного, даже и не вспомнить.

Из неинтересных сетевых глюков выяснили, например, что при перевешивании Elastic IP-адреса он не переезжает из одной AZ в другую из-за того, что новая Ethernet-фабрика с EVPN блокирует GARP-пакеты — не на всём оборудовании они обновлялись и не до всех точек GARP дотягивался. И уже совместно с NVIDIA решали проблемы с подавлением GARP (ARP suppression отбрасывал нужные нам пакеты).

Когда сами всё проверили, стали осторожно пускать туда особо настойчивых заказчиков. Потестировав со своей стороны новую AZ две-три недели, они начали запускать рабочие нагрузки. Ещё раз всё перепроверив, мы открыли доступ для всех наших заказчиков.

Краткие выводы

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

20 декабря 2023
Ритейл использует облака для ускорения своего роста

Согласно исследованию КРОК[1] 92% крупных и средних ритейлеров в России используют облачные сервисы, остальные – собственные ЦОД и сервера. 63% определились с выбором провайдеров и не планируют его менять в ближайшем будущем. При этом с 2022 года розничные сети перешли на российские облака, и сейчас большинство пользуются услугами сразу нескольких, чтобы не попасть в зависимость от одного поставщика.

2 минуты
1119
12 декабря 2023
KT.Team создала полностью автоматизированную систему маркировки товаров для FM Logistic на базе Облака КРОК
KT.Team разработала для международной логистической корпорации FM Logistic решение, помогающее максимально упростить процесс взаимодействия производителей и продавцов с Государственной информационной системой мониторинга оборота товаров (ГИС МТ). Решение называется “Paradigma” и развернуто на базе Облака КРОК, которое обеспечивает надежную платформу для его функционирования.
0 минут
582
8 декабря 2023
КРОК Облачные сервисы поможет компаниям защитить свою облачную инфраструктуру
КРОК Облачные сервисы совместно с «К2 Кибербезопасность» запустили Cloud Security Services (CSS) – комплекс мер и сервисов по обеспечению защиты ИТ-инфраструктуры клиента в облачных средах. Он позволяет выявлять, приоритизировать и митигировать риски и решать проблемы соответствия требованиям регуляторов по защите ИТ-инфраструктуры.
2 минуты
550
1 декабря 2023
КРОК Облачные сервисы первыми из облачных провайдеров получили сертификат PCI DSS 4.0

КРОК Облачные сервисы стал первым облачным провайдером в России, который получил сертификат соответствия новому стандарту безопасности данных платежных карт PCI DSS 4.0. Эта версия станет обязательной к исполнению с 2025 года вместо стандарта PCI DSS 3.2.1., действующего с 2018 г.  За прошедшее время, угрозы и методы защиты данных ушли далеко вперед. В стандарте PCI DSS 4.0 углублен и расширен базовый уровень операционных и технических требований для повышения безопасности платежей и прописаны инновационные методы для борьбы с новыми угрозами.

2 минуты
776
1 ноября 2023
Незаменимых нет. Сервис на базе Nextcloud вместо привычных корпоративных облаков

Привет, Хабр! Меня зовут Александр Фикс, я менеджер по развитию бизнеса КРОК Облачные сервисы. Сегодня поговорим о тренде локализации, о том, что происходит на рынке файлообменников с уходом западных решений и какие альтернативные продукты есть у бизнеса в данный момент.

1 минута
1217
scrollup