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

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

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