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

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

554
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 две-три недели, они начали запускать рабочие нагрузки. Ещё раз всё перепроверив, мы открыли доступ для всех наших заказчиков.

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

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

4 июля 2023
Локализация как есть: переехать в облако и ничего не потерять
Локализация российских подразделений иностранных компаний стала одним из самых частых запросов на облако в 2022 году. Страховой брокер Remind, лидер цифровизации в своей отрасли, прошел этот путь вместе с Облаком КРОК.

3 минуты
394
22 июня 2023
Nova Container Platform стала доступна в Облаке КРОК
«КРОК Облачные сервисы» объявил о доступности в своем облаке российской платформы оркестрации контейнеров Nova Container Platform от Orion soft. Решение позволяет более чем на 40% ускорить процесс создания и эксплуатации контейнерных приложений, а также сократить time to market более чем на 30%
2 минуты
451
19 июня 2023
Семь трендов на рынке облачных услуг в 2023 году
До 2022 года на рынке облаков в России главенствовали мировые тренды, но сейчас наша страна пошла своим путем. О том, для чего сейчас компании используют облачные технологии и как меняется рынок, рассказал директор по развитию КРОК Облачные сервисы Сергей Зинкевич.
1 минута
658
17 мая 2023
ИТ-инфраструктура в ритейле – поиск компромиссов или фундамент для роста?

Гостем февральского выпуска нашей новой серии онлайн-дискуссий стал Дмитрий Кузеванов, технический директор розничной сети «Азбука вкуса».

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

А какую роль в развитии цифровых сервисов играет ИТ-инфраструктура?

4 минуты
305
scrollup