В начале года мы рассказали о том, как подключали третью зону доступности в нашем облаке: почему вернулись к 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 две-три недели, они начали запускать рабочие нагрузки. Ещё раз всё перепроверив, мы открыли доступ для всех наших заказчиков.
Краткие выводы
Третья зона доступности обеспечила нам и нашим заказчикам надёжную основу для реализации кластерных решений, где требуется кворум. Она ценна и сама по себе как ещё одна площадка, где пользователи могут запускать свои облачные ресурсы. Глядя с высоты приобретённого опыта, мы кое-что, наверно, оптимизировали бы, но сначала на эту высоту надо было забраться. При каждом новом внедрении – помимо третьей площадки у нас есть опыт развёртывания нашей облачной платформы в Турции — мы стараемся что-то кардинально технологически поменять, сделать рывок вперёд, что у нас в принципе, может быть не без трудностей, но получается.
Автор: Дмитрий Ганьжа
