Мы в beeline cloud запустили сервис MetroCluster. Это — отказоустойчивый кластер, который автоматически переключает нагрузку между двумя площадками (дата-центрами) при сбое на одной из них. Продукт подойдет компаниям, которым важна работа сервисов с минимальным временем восстановления — в том числе мы, как облачный провайдер, используем его для решения своих задач. В отличие от классических решений Disaster Recovery, MetroCluster не требует разработки сложных регламентов (DRP), а время восстановления ограничено лишь скоростью запуска виртуальной машины в резервном ЦОДе. Далее мы расскажем об архитектуре решения и его ключевых компонентах.
Что внутри
Общая архитектура MetroCluster включает три географически распределенных дата-центра. Два из них (DC1 и DC3) играют роль площадок аварийного восстановления: они построены на базе платформы виртуализации VMware vSphere, используют общее распределённое хранилище данных и содержат реплики виртуальных томов LUN. На третьей площадке (DC2) размещён управляющий кластер, контролирующий остальные компоненты платформы. Решения соответствуют рекомендациям VMware.
Сеть передачи данных MetroCluster построена по схеме с двумя выделенными контурами: плоскостью данных (data plane) и плоскостью управления (control plane). Кроме того, для объединения площадок в единую сеть используются каналы связи DCI (Data Center Interconnect). Плоскость данных объединяет площадки с ресурсным кластером VMware vSphere. Она также предназначена для передачи трафика виртуальных серверов платформы виртуализации, интернет-трафика и обслуживания каналов связи типа Cloud-to-Cloud или PoP-to-Cloud (предоставляются клиентам в качестве сервиса).
Плоскость управления передает командный трафик и согласует работу элементов программного ядра. Именно control plane связывает все три дата-центра в единую инфраструктуру. Схему решения можно представить следующим образом:
Условные обозначения:
Сетевая фабрика плоскости данных. В неё входят коммутаторы и иные компоненты сети, обеспечивающие передачу трафика виртуальных машин клиентов.
Кластер VMware vSphere, распределенный между двумя дата-центрами.
Коммутаторы, объединяющие хосты и СХД в общую сеть SAN.
Кластер, объединяющий системы хранения данных на площадках DC1 и DC3.
Коммутаторы и иные компоненты сети, обеспечивающие передачу трафика управляющих компонентов платформы.
Кластер VMware vSphere для управления платформой.
Подробнее о компонентах
Платформа виртуализации. В состав платформы входят следующие кластеры:
Управляющий кластер виртуализации для хостинга управляющих виртуальных машин (ВМ) платформы, отвечает за работу системных компонентов виртуализации.
Edge-кластер. Здесь развернуты пограничные виртуальные машины на базе NSX-T.
Управляющий кластер размещен на площадке DC2, чтобы управление ресурсным кластером сохранялось при отказе любой из резервных площадок (DC1 или DC3).
В общем случае схема платформы виртуализации выглядит следующим образом:
На схеме показано размещение кластеров на площадках, VDS-коммутаторы и основные сети, необходимые для работы платформы.
Подсистема сетевого оборудования. Схема подключения на площадках DC1 и DC3 достаточно стандартная и потому не представляет особого интереса. А вот на площадке DC2 изначально отсутствовал выделенный контур сети control plane, необходимый для размещения управляющего кластера и компонентов платформы. Поэтому нам пришлось настраивать дополнительное оборудование, обеспечивающее сетевую связанность между ЦОД. Итоговая схема подключения — на диаграмме:
На схеме видно, что control plane площадки DC2 представляет собой spine/leaf-фабрику с двумя spine- и двумя border leaf-коммутаторами. При необходимости их число можно увеличить. А для взаимодействия с сетями DC1 и DC3 на DC2 установлены BGW-коммутаторы, обеспечивающие связанность в рамках underlay -и overlay-сетей.
Подсистема СХД. Она построена на основе существующей SAN-сети и включает в себя системы хранения данных и SAN-фабрики, размещенные на DC1 и DC3, а также существующий SAN-интерконнект между ними. На каждой площадке размещены локальные копии данных и ВМ клиентов для быстрого восстановления.
Локальные копии данных представлены в виде единого виртуального LUN в режиме Read/Write. При этом на уровне SAN-сети каждый хост ESXi «видит» пути к обеим СХД. Консистентность данных обеспечивает синхронная запись на блочном уровне:
При записи в локальную копию СХД автоматически дублирует данные на удалённую площадку.
Операция записи считается завершённой только после подтверждения от удалённой площадки.
Подсистема хранения данных также включает сервер кворума, расположенный в DC2. Его основная функция — разрешение конфликтных ситуаций при синхронизации данных между локальными СХД на DC1 и DC3. Если во время репликации возникает ошибка, сервер кворума автоматически приостанавливает работу непредпочтительной площадки. Так предотвращается одновременная запись данных при отсутствии синхронизации.
Ниже представлена схема организации SAN-сети:
Подсистема NSX-T. Ресурсный кластер платформы распределен между площадками DC1 и DC3 и управляется одним сервером VMware vCenter. Также используется менеджер NSX-T, отвечающий за инфраструктуру резервных площадок.
Общий дизайн платформы виртуализации можно представить так:
Вот так выглядит архитектура нашего отказоустойчивого кластера. Он обеспечивает бесперебойную работу критических сервисов — для нас и наших клиентов — даже при полном отключении одного из дата-центров. Если у вас есть вопросы, или вы хотите протестировать сервис — напишите нам.
Что еще есть в нашем блоге на Хабре:
От PPP до облака: как развивался и зачем нужен SD-WAN. В целом SD-WAN представляет собой сплав сразу нескольких сетевых технологий, а её история началась в 80-х. Сперва для обмена данными между корпоративными сетями использовали протокол PPP и выделенные линки. Позже пришла технология Frame Relay, а следом — MPLS, которая обеспечила значительную часть функциональности современных SD-WAN. Сегодня программно-определяемые глобальные сети, как правило, использует крупный и средний бизнес с разветвленной сетью филиалов. Однако решение походит и малым компаниям, столкнувшимся с необходимостью организовать распределенную сеть. В статье кроме возможностей SD-WAN, также обсуждаем варианты развертки подобной инфраструктуры, и когда она пригодится [материал для менеджеров и начинающих системных администраторов].
Базовый минимум: зачем вашей компании WAF. Еще один обзорный пост, но теперь ориентированный на начинающих сисадминов и тех, кто делает первые шаги в сфере информационной безопасности. За прошлый год число кибератак на российские компании выросло в 2,5 раза. Сильнее всех «досталось» промышленникам, банковскому сектору и телекомам. А чаще всего целью злоумышленников становились веб-приложения из-за их уязвимостей (по нашей оценке, серьезные недостатки содержат 98% из них). В то же время системы ИИ снизили порог входа в сферу киберпреступлений и открыли новые возможности для «серийных хакеров». Защитить от атак на веб-приложения призвана технология Web Application Firewall (WAF). В статье обсудили, что умеют современные WAF-инструменты, а еще рассказали, что предложит наше решение Cloud WAF Pro.
Управление нагрузкой, теплом и не только: неочевидные нюансы построения S3-хранилищ. Антон Аплемах, владелец продукта cloudfort, рассказал, какие услуги на основе объектных хранилищ использует бизнес и как подойти к выбору такого решения. Также в статье: о сложностях построения хранилищ S3, связанных с управлением теплом, репликацией и чтением данных, а также нагрузкой на жесткие диски — все с точки зрения облачного провайдера. Например, тысячи HDD, размещённых в стойках дата-центра, склонны к перегреву, что увеличивает частоту сбоев и износ механических компонентов. Из-за этого операторы вынуждены тратить до половины потребляемой энергии на охлаждение оборудования. Ещё одна проблема — неравномерная нагрузка на кластер S3-хранилища. Поскольку каждый накопитель поддерживает ограниченное количество I/O-операций, часть дисков может оказаться перегруженной из-за дисбаланса запросов.
Почему отраслевые облачные платформы становятся более значимыми в cloud-индустрии. Первая статья из цикла «ИТ-тренды». Отраслевые (индустриальные) облака обычно развертываются на базе инфраструктуры одного провайдера. При этом он предлагает не только «железо», но и спец. сервисы: например, системы управления складом, инструменты для сбора данных с IoT-устройств или аналитику для конкретных сфер бизнеса. Эксперты отмечают растущий спрос на отраслевые облака — особенно среди промышленников и медицинских организаций. Но есть и нюансы: чрезмерная специализация индустриальных облаков делает инфраструктуру менее гибкой, а клиенты провайдеров рискуют привязкой к вендору (vendor lock-in).
Что почитать и посмотреть разработчикам и менеджерам. Напоследок хотим поделиться подборкой книг, видео и телеграм-каналов для проджект-менеджеров, разработчиков и сисадминов. Тематики достаточно разношерстные: о том, как подготовиться к сложному интервью, как не конфликтовать с руководством и как свыкнуться с ролью начальника (например, если пришлось руководить командой программистов не по своей воле). Есть не только иностранные, но и российские источники: например, путеводитель для проджекта от основателя scrum-студии «Сибирикс», а также памятка-шпаргалка по SQL. Помимо базовых команд, вроде CREATE, UPDATE, DELETE, там описана и более интересная функциональность.
beeline cloud — secure cloud provider. Разрабатываем облачные решения, чтобы вы предоставляли клиентам лучшие сервисы.