Третью зону доступности в облаке мы развёртывали изначально для решения собственных задач — чтобы обеспечить «честный» кворум для наших внутренних распределённых сервисов. У нас было три собственных дата-центра, но лишь в двух из них были выделены зоны доступности для облака, при этом одна была основной, а вторая от неё зависела. Потенциально это грозило тем, что при отказе первой с проблемами столкнулись бы обе. Сейчас же облако может пережить отказ любой зоны доступности: ресурсы в других зонах останутся доступны и сохранится контроль над ними.
На новой площадке не было продуктивной нагрузки, развёрнутых систем заказчиков и всего прочего, для чего требовалось бы продумывать схемы перехода на новые решения таким образом, чтобы это не сказалось на работе заказчиков. Поэтому при развёртывании третьей площадки в кои-то веки мы были не скованы легаси и могли использовать новые технологии, которые только собирались внедрить в двух существующих зонах доступности.
Однако, от первых расчётов до развёртывания прошло почти три года. Технически всё можно было бы сделать проще и быстрее, но приходилось согласовывать свои планы с реальными возможностями и потребностями. Итак, обо всём по порядку.
Растроение лучше раздвоения
Три зоны доступности (Availability Zone, AZ) — минимальный must have для любого облачного провайдера. Механизмы отказоустойчивости многих современных систем опираются на такие концепции как выбор лидера, голосование и кворум. Суть механизмов голосования в том, что для корректной работы кластера большинство его участников должно быть онлайн. Иными словами, чтобы система сохраняла свою работоспособность, нужно поддерживать связность между большинством узлов в кластере (проблема «раздвоения сознания» — split brain).
Любые кластеры рекомендуется поэтому строить таким образом, чтобы при потере связности из-за отказа сетевой карты/кабеля/драйвера на вычислительном узле кластера или по любой другой причине какая-либо из изолированных частей кластера содержала больше половины от общего числа узлов — тогда кластер продолжит функционировать и согласованность данных не будет нарушена. В случае двух дата-центров кластер приходится разбивать на две неравные части, чтобы большинство находилось в одной из них, либо размещать часть узлов на стороне — в колокейншн или, чего бы нам не хотелось, у другого облачного провайдера.
При размещении кластера в двух ЦОД при недоступности дата-центра, где находится большинство, он перестанет функционировать. Хоть дата-центры КРОК и работают бесперебойно с момента запуска, однако связность между ними может нарушиться по независящим от нас причинам (например, авария на магистрали). Этот риск приходится учитывать, тем более что в инфраструктуре облака используется целый ряд решений, базирующихся на кворумах, в частности Dell EMC PowerFlex, OVN, MongoDB, Ceph (для объектного хранилища S3).
Проблема обеспечения кворума была особенно остра в случае двух последних сервисов, так как их кластеры распределены по зонам доступности облака, чтобы обеспечить избыточность и доступность данных во всех AZ, а также функционирование облака при отказе одной из них. Так, отказ серверов с репликами MongoDB на площадке ru-msk-vol51, где было расположено 3 из 5 узлов, грозил потерей возможности управления облаком клиентами.
При наличии трёх зон доступности с независимыми каналами связи недоступность узлов на одном из ЦОД не сказалась бы на функционировании кластера в двух других, так как большинство узлов сохраняли бы связность. Третья площадка у нас уже была, поэтому первой задачей стало обеспечение межсоединения с ней (Data Center Interconnect, DCI).
«Кровавый энтерпрайз» решает
Третья площадка хоть и находится в относительной близости от первой, но имеет полностью независимую инженерную инфраструктуру — ИБП, ДГУ, каналы связи и т.д. Она предоставляла традиционные услуги ЦОД такие как колокейшн, но никакой инфраструктуры для развёртывания облака там не было, поэтому её пришлось делать с нуля. И прежде всего мы занялись сетью.
Для соединения двух существующих дата-центров использовалось оборудование Extreme Networks, с помощью которого предоставлялись сервисы L2 VPN, L3 VPN, интернет и т.д. Все эти сервисы планировалось предоставлять и в третьем дата-центре, при этом сетевая фабрика должна была обеспечить отказоустойчивую связь между площадками. И мы начали выбирать, с каким вендором и на каком решении всё это делать. Подходящих вариантов оказалось не так и много.
Самым простым решением с точки зрения трудозатрат было бы подключить к существующей фабрике оборудование Extreme и объединить всё с помощью VPLS. Однако, у установленного оборудования заканчивался срок службы (EOL), а работы по замене были плюс-минус сопоставимы с переходом на другую фабрику. Кроме того, подключение третьего ЦОД на уже используемом оборудовании несло потенциальный риск отключений для заказчиков, поэтому мы расширили наш круг поиска решений.
Новое ядро позволяло бы развёртывать сети параллельно существующему ядру, а последующее переключение сетей и сервисов выполнять по мере необходимости, каждое отдельно. В качестве решений для организации сетей ЦОД и управления ими мы рассматривали RunSDN, Brain4Net (B4N) и комбинацию EVPN с VХLAN в качестве протокола инкапсуляции.
RunSDN на тот момент выглядел ещё сырым решением и не поддерживал всю необходимую нам функциональность. У B4N было уже достаточно зрелое решение, но, как и в случае RunSDN, в рассматриваемом нами варианте установки оно предполагало единый слой управления (Control Plane) для всех ЦОД. Мы опасались создавать такой большой Failure Domain, так как любая конфигурационная ошибка или ошибка в коде SDN-решения могла негативно сказаться сразу на всех ЦОД.
Ethernet VPN (EVPN) представляет собой расширение BGP и обеспечивает виртуальное соединение между различными доменами L2/L3 поверх сетей IP или MPLS. Несмотря на свою модность, это была проработанная и понятная технология. И в отличие от централизованного подхода к управлению коммутаторами, Control Plane у неё распределенный, так что ошибки на одном коммутаторе оказывают меньшее влияние на инфраструктуру.
Кроме того, EVPN позволял эффективно решить следующую проблему. Если для соединения двух дата-центров в базовом варианте достаточно кинуть отказоустойчивый линк между ними, то для трех дата-центров все сложнее – получившееся "кольцо" надо как-то по-умному рвать или обрабатывать, чтобы не возникало широковещательных штормов. В EVPN MP-BGP рассылает и принимает анонсы L2-маршрутов, из которых автоматически формируются flood-list’ы, и широковещательный трафик в инкапсулированном виде отправляется только тем пирам, которые должны его получить. Получив широковещательный кадр из EVPN-сегмента, коммутатор пересылает его далее в подключенные к нему сети, но не обратно в EVPN, что и предотвращает штормы.
Изначально для реализации EVPN мы рассматривали Mellanox (теперь входит в NVIDIA) c Cumulus Linux, но субъективные предпочтения сетевиков предопределили выбор в пользу «кровавого энтерпрайза» — мы остановились на Cisco. Закупили оборудование и параллельно существующей фабрике стали возводить новую, соединяющую все три дата-центра.
Засвеченная оптика
Все три имеющихся дата-центра уже были связаны оптикой, так что ничего дополнительно прокладывать не пришлось. Волокна идут разными путями, по разным улицам Москвы. Если пресловутый экскаватор до них докопается, то останется другой маршрут. Если же связность между какими-либо двумя дата-центрами будет нарушена, то они всё равно смогут обмениваться трафиком через третий ЦОД. Главное, внутри дата-центра корректно расключить все волокна между коммутаторами, чтобы все подключения были крест-накрест. Резервирование таким образом решено как на уровне физики, так и отдельных железок — дублирующее оборудование размещено в разных стойках в противоположных концах ЦОД.
В качестве волоконно-оптических трансиверов выбрали SFP от FiberTrade. При их использовании необходимо учитывать один нюанс — под разное железо в них устанавливаются разные прошивки в EPROM. И не все прошивки совместимы со всеми коммутаторами — какие-то заводятся, какие-то нет, какие-то работают кое-как. Мы эти проблемы отловили ещё на этапе тестирования у себя в лабе и подобрали правильную конфигурацию.
Когда пришло оборудование, его смонтировали в одной стойке и начали тестировать. К тому моменту, когда оптическая сеть была готова, всё было преднастроено — оборудование оставалось только поставить и правильно скоммутировать. Правда, тесты на этом не закончились — проводили нагрузочное тестирование, гоняли трафик, забивали линки, настраивали счётчики ошибок и мониторинг. Отрубали питание и выдёргивали линки, чтобы посмотреть как отрабатывает аварийное переключение (failover) и как всё потом восстанавливается, когда мы возвращаем питание и соединение.
И VLAN за VLAN стали переключать трафик на новый интерконнект.
Назад к Ethernet
Третья площадка стала первой, где мы вернулись к использованию Ethernet вместо InfiniBand в качестве высокоскоростной сети. В своё время мы выбрали InfiniBand, поскольку на тот момент он обеспечивал в 5 раз большие скорости при сравнимых затратах. Причины возвращения к Ethernet и перевод на него продуктовой среды заслуживают отдельной статьи (как-нибудь об этом подробнее напишем). Здесь же хотелось рассказать, какие сложности возникли из-за того, что на двух других площадках такие сервисы как Ceph были развёрнуты на InfiniBand и для них нужно было обеспечить связность с новой площадкой на Ethernet.
После того, как связь с новым ЦОД была налажена, мы начали монтировать оборудование под третью копию нашего объектного хранилища S3. Ceph в двух зонах доступности у нас был на InfiniBand, а связь между IP-фабриками в разных дата-центрах осуществлялась с помощью промежуточной сети Ethernet, для соединения же сетей InfiniBand и Ethernet использовались специальные коммутаторы — шлюзы VPI. Поскольку на третьей площадке сразу предусматривался Ethernet, шлюзы-конверторы на новой AZ устанавливать не требовалось. Но всё равно приходилось учитывать ограничения, налагаемые шлюзами на других площадках, так как хосты Ceph связывала единая сеть. Максимальный размер IP-пакета, который они поддерживают — 4092 байта. Из-за того, что этот размер надо было соблюдать на всём пути, пришлось повозиться с настройкой сети, чтобы добиться корректной работы и нормальной производительности через VPI.
Одна из сложностей, которую накладывает InfiniBand — отсутствие маршрутизации IPoIB-трафика. Точнее, мы тогда так думали, на самом деле в каком-то виде маршрутизация есть. В двух зонах доступности была единая сеть для Ceph, поэтому нам этот единый сегмент пришлось прокидывать в третью AZ. В новой фабрике на базе Mellanox c Cumulux Linux мы также использовали EVPN, и здесь он нам пригодился — мы создали сегмент VXLAN, который соединили с уже существующей сетью и "прокинули" его на серверы S3 как обычный VLAN.
Только потом мы узнали, что шлюзы VPI можно сконфигурировать так, чтобы они маршрутизируемый трафик тоже пропускали через себя. Если бы узнали о такой возможности раньше, то миграция была бы чуть проще. Для третьей AZ выделили бы отдельный L3-сегмент сети S3 и смаршрутизировали бы его из двух существующих AZ – L2 тянуть не пришлось бы. В конечном итоге мы всё равно перешли полностью на схему третьего уровня: в каждой стойке своя сеть L3.
При тестировании связности между серверами с Ceph мы столкнулись с проблемой высокого Soft IRQ. Всю жизнь на InfiniBand мы использовали набор драйверов Mellanox OFED, что нас в некоторой степени напрягало — приходилось их постоянно пересобирать под разные ядра и тестировать. Мы тихо надеялись от них отказаться, перейдя на Ethernet, и начать использовать inbox-драйверы (драйверы из поставки ядра Linux).
Однако, как оказалось, адаптивные прерывания не работают на inbox-драйвере нашей тогдашней версии ядра Linux. Нам не очень хотелось тюнить параметры прерываний в карточке, поэтому мы поставили Mellanox OFED и проблема решилась сама. В итоге убедили себя, что с отдельным набором драйверов хоть и больше возни, но при этом мы получаем главное — гибкость в выборе версии драйвера и поддержку от вендора, с которым есть хорошо налаженный контакт.
Перенос Ceph и баз данных Mongo
С настройкой сети для Ceph пришлось повозиться, а вот с репликацией данных особых сложностей не было. Конечно, это не по нажатию кнопки делалось. Мы добавили хосты в Ceph нашими штатными утилитами. В Ceph появился новый datacenter (абстракция Ceph), который поначалу находился вне текущего region и на него не распространялась политика репликации.
Когда все средства мониторинга были настроены, сети протестированы и все было готово к запуску репликации, мы увеличили число реплик каждого пула. В результате 33,333% данных Ceph посчитал находящимися в состоянии degraded, так как три копии нельзя разложить по двум дата-центрам. Затем мы переместили новый datacenter в region, где были текущие два, и эти 33,333% данных начали реплицироваться в новый дата-центр. В общем ничего особенного.
После того как данные были реплицированы, чуть позже перераспределили и мониторы. Их разделили по схеме 2:2:1, чтобы было нечётное количество и чтобы в одной зоне доступности не находилось большинство мониторов. Раньше мониторы были распределены в пропорции 3 к 2, соответственно, в одной зоне доступности находилось больше половины всех. Теперь же любая AZ может быть выключена и всё продолжит работать.
После растягивания объектного хранилища стали потихоньку перетаскивать внутренние базы данных Mongo. Изначально мы планировали перенести их раньше Ceph, но вопрос с третьей репликой стоял более остро. С базами данных всё прошло ещё легче: их суперпросто переносить — только добавляй новые инстансы в существующие кластеры.
У нас есть два типа набора реплик Mongo — условно, зональные и региональные. В зональной реплике хранятся документы ресурсов конкретной зоны доступности: инстансов, дисков, метрик, интерфейсов и всего другого прочего. А в региональной храним данные, которые не привязаны к конкретной AZ — о пользователях, проектах, тарифах и т.п.
В случае зонального набора реплик большинство инстансов кластера располагается в соответствующей зоне доступности и по одному инстансу replica set в каждой другой AZ, однако эти две удалённые реплики не могут стать primary. Они нужны в качестве резервной копии, а также используются для чтения в других AZ. В случае регионального набора реплик в каждой зоне доступности развёрнуто по два инстанса, они все равнозначны и роль primary может взять любой инстанс.
Кроме того, мы смогли наконец-то сделать нормальный отказоустойчивый Zabbix-кластер для мониторинга с распределением баз данных по трём площадкам. В качестве баз данных мы используем — PostgreSQL с плагином TimescaleDB, для их кластеризации patroni в связке с etcd. Zabbix настроен таким образом, что он сам находит все новое оборудование, которое появляется в инфраструктуре, — проверяет, что это за сервер, коммутатор и т.п., какие у него роли и автоматически включает в мониторинг.
При подключении третьей зоны доступности нам пришлось лишь добавить несколько правил и шаблонов для новых ресурсов, которых раньше не было. Это позволило нам полноценно заниматься инфраструктурой, не тратя время на настройку мониторинга. И дальше при развёртывании третьей AZ благодаря автоматическому обнаружению у нас не возникало ситуации, что какой-то сервер или сервис случайно оказался вне контроля, забыт или потерян.
Виртуалки для облачного провайдера
Технологически эта AZ не была скована никаким тяжёлым наследием. Мы кайфовали от того, что можно просто брать и устанавливать новые системы с новыми багами фичами, а не ковыряться в пережитках прошлого.
Но главное, благодаря Ethernet мы смогли вынести сервисы, которым по долгу службы не нужно работать на железе, в виртуальные машины: Control Plane облака стали деплоить в виртуалках на выделенных сервисных узлах, а сеть прокидывали при помощи SR-IOV, что позволило "пробрасывать" внутрь ВМ быструю сеть, не ограниченную производительностью стандартных tun+virtio сетевых интерфейсов ВМ. Виртуальные машины стали использовать даже там, где нам раньше из-за требований к производительности сети приходилось применять только железо.
Десятки физических серверов, на которых раньше жили эти сервисы, в итоге на новой площадке трансформировались в 9 мощных серверов, где были все служебные сервисы. Это позволило сократить количество занимаемых юнитов, сам парк серверов, количество портов в коммутаторах и т.д. При этом повысилась гибкость — мы можем запросто переносить виртуалки между хостами, легко наращивать их ресурсы и максимально быстро создавать любые ВМ по запросу.
Такой вот занятный разворот сюжета... Облачный провайдер, который уже десять лет продает ВМки, перешёл на инфраструктуру с виртуалками внутри облака :)
Что дальше?
К тому моменту, когда инфраструктурная часть была готова, всё больше заказчиков стали спрашивать, как скоро у нас в облаке появится третья зона доступности, и были готовы её использовать. Наше представление о том, как правильно, совпало с реальными потребностями рынка, и мы не могли не откликнуться на этот запрос пользователей. О том, как мы внедряли Compute в третьей зоне доступности, в следующем материале.
