Методы разделения VK Private Cloud

Разделение Платформы — комплекс мер, позволяющих сегментировать ресурсы облака для эффективного распределения рабочих нагрузок в облаке. С помощью разделения облака решаются следующие задачи:

• Обеспечение прав на персональные данные.
• Физическая изоляция сегментов и избыточность по отношению к другим сегментам.
• Управление группами оборудования с различающимися характеристиками.

Платформа поддерживает следующие методы разделения:

1. Регион.
2. Зона доступности.
3. Агрегаты вычислительных узлов.

Любая инсталляция Платформы включает в себя регион. Регион включает в себя одну или несколько зон доступности. Зона доступности включает в себя один или несколько агрегатов вычислительных узлов (рисунок 1).

Рисунок 1 — Методы разделения Платформы

В таблице 1 приведён сравнительный анализ каждого метода разделения.

Описание разделения инсталляции описывается в разделе 1 (Сведения о проекте) документа Требования к инфраструктуре.

Регион — это отдельная инсталляция, развёртываемая независимо от других инсталляций. Регионы имеют собственные наборы API и порталов для работы пользователей и администраторов, однако могут иметь общие точки интеграции для управления проектами и доступа к ним из различных регионов. Пользователь должен явно указать, в каком именно регионе необходимо создать его рабочую нагрузку. Каждый регион имеет свой набор образов, проектов и несвязанных между регионами сетей.

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

Изолированность программных компонентов Платформы между регионами позволяет локализовать базы данных пользователей Платформы и приложений, размещаемых в Платформе (локализация хранения персональных данных).

Регионы связываются между собой единой опорной сетью. Минимальная пропускная способность сети — 10 Мбит/с.

В текущей версии Платформы поддержка множества регионов носит базовый характер, общими являются интеграции с внешними сервисами (AD/LDAP, NTP, DNS и т.д.). При этом из соображений отказоустойчивости требуется иметь в каждом домене отказа каждого региона свою конечную точку интеграции (локальный сервер общей структуры интегрируемых сервисов).

Зоны доступности — метод разделения ресурсов Платформы, расположенных в пределах региона в целях физического разделения инсталляции и выполнения требований отказоустойчивости.

Зоны доступности должны быть связаны между собой высокоскоростными каналами связи с низким уровнем задержек. По сравнению с требованиями к каналам связи между регионами минимальные требования связи между зонами доступности более высокие — не менее 40 Гбит/с при задержках не более 5 мс.

Зона доступности содержит свои вычислительные узлы, блочные хранилища и сетевое оборудование. С зонами доступности связаны следующие виды рабочих нагрузок:

• Виртуальные машины.
• Виртуальные диски.
• Балансировщики нагрузки.
• Файловые хранилища.
• Экземпляры СУБД.
• Master-узлы и группы узлов кластеров Kubernetes.

Штатное функционирование зоны доступности зависит от следующих служб:

• Образы ВМ.
• Блочные хранилища.
• Сеть.
• Внешние объектные хранилища.

Выход из строя зоны доступности — это любые события, приводящие к деградации способности зоны доступности держать рабочую нагрузку.

При планировании зон доступности необходимо руководствоваться следующими ограничениями:

• Пользователи не будут знать о наличии или отсутствии свободных ресурсов в зоне доступности. При этом при создании рабочей нагрузки пользователю необходимо будет явно указывать зону доступности.
• Зоны доступности призваны разделять оборудование контура рабочих нагрузок по доменам отказа.
• Зоны доступности не следует использовать для сегментации узлов рабочих нагрузок по типам используемого оборудования (подробнее — в разделе Агрегаты вычислительных узлов).
• Зоны доступности не предназначены для организации разных типов рабочего окружения (например: dev, stage и production).

Для проектирования Платформы зона доступности определяется как единичный домен отказа, предназначенный для разделения узлов рабочих нагрузок в целях защиты от различных негативных сценариев: отказ электропитания, отказ сети и т.д. Домен отказа — набор аппаратных компонентов, совместно использующих единую точку отказа.

Существуют четыре классических домена отказа:

• ЦОД.
• Машинный зал.
• Ряд стоек.
• Стойка.

Типовые единые точки отказа приведены в таблице 2.

Оптимальное количество зон доступности — 2 или 3, в зависимости от требований к отказоустойчивости приложений. В двух зонах доступности можно размещать приложения Master-Slave. В трёх зонах доступности можно разместить приложения, требующие кворума сервисов (рисунок 2).

Рисунок 2 — Размещение приложения, требующих кворума сервисов, в трёх зонах доступности

Требования, предъявляемые наличием нескольких зон доступности:

• В каждой зоне доступности Платформа имеет свой набор сетей.
• Необходимо обеспечить связность сетей Management, Cloud Tunnel и Ceph External (Storage).
• Проектные сети выполняются растянутыми на весь набор зон доступности.
• Между сетями Management, Cloud Tunnel, Ceph External (Storage), разных зон доступности не должно быть МСЭ. МСЭ ограничивают производительность и резко повышают сетевые задержки. МСЭ допускаются только на стыке с корпоративной сетью.

Для каждой зоны доступности в документе Требования к инфраструктуре заполняются разделы: 1 (Сведения о проекте), 2 (Серверы), 3 (Конфигурация серверов), 4 (Разметка дисков), 6 (Портовой бюджет) и 8 (Сети).

Агрегат вычислительных узлов (далее — агрегат) — логическое объединение вычислительных узлов внутри одной зоны доступности, выделенных по характеристикам оборудования (например: тип процессора, объём памяти, дополнительное оборудование). Агрегаты используются для повышения гибкости управления ресурсами, обеспечения особых потребностей приложений и обеспечения мер информационной безопасности.

В отличие от зон доступности механизм агрегатов недоступен конечному пользователю, размещение ВМ в определённом агрегате выполняется автоматически на основании метаданных, которые задаются администраторами в свойствах типа ВМ (flavor).

Основные причины применения агрегатов:

• Размещение приложений с особыми требованиями к ресурсам:

  • Высокочастотные процессоры.
  • Экземпляры с большим объёмом RAM.

• Управление переподпиской.

• Монопольное использование ВУ или набора ВУ проектами или ВМ.

• Сетевая изоляция на физическом уровне.

• Требования ИБ для чувствительных данных.

Один ВУ может принадлежать нескольким агрегатам (в отличие от зоны доступности, где один ВУ может принадлежать только одной зоне).

Ограничения для агрегатов ВУ:

• Агрегат существует только в одной зоне доступности.
• В случае исчерпания доступных вычислительных ресурсов в агрегате будет недоступно создание ВМ заданного типа, связанного только с этим агрегатом. Миграция ВМ при отказе ВУ также будет недоступна.

Агрегаты (за исключением агрегата для зоны доступности) не создаются автоматически в ходе инсталляции. Настройки агрегатов необходимо выполнять после инсталляции Платформы в ходе подготовки Платформы к эксплуатации.

В документе Требования к инфраструктуре требования к дополнительным агрегатам отображаются в разделах 2 (Серверы) и 3 (Конфигурации серверов) в виде дополнительной строки для серверов с ролью Compute.

Для управляющего слоя применяется понятие домен отказа. Управляющий слой является единой сущностью, обеспечивающей управление всеми зонами доступности Платформы. Составные части управляющего слоя могут располагаться в тех же доменах отказа, что и некоторые или все зоны доступности Платформы.

В базовом варианте, все управляющие узлы располагаются в одном домене отказа, что обеспечивает полноценное управление всеми зонами доступности Платформы. В случае сбоя или потери связности с доменом отказа, содержащим управляющие узлы, оставшиеся зоны доступности будут продолжать выполнять рабочую нагрузку без возможности внесения изменений. В случае, если Платформа использует коммутационную фабрику, сетевая доступность рабочей нагрузки сохранится, в противном случае, связность будет потеряна (рисунок 3).

Рисунок 3 — Расположение всех управляющих узлов в одном домене отказа

Сохранение управления Платформой может быть достигнуто с помощью архитектуры с управляющим слоем, «растянутым» по трём доменам отказа. Такая архитектура подразумевает распределение управляющих сервисов Платформы по трём доменам отказа. В минимальном варианте на каждый домен отказа приходится по одному серверу слоя управления. Платформа в конфигурации с «растянутым» на три домена отказа управляющим слоем будет устойчива к выходу из строя одного домена отказа (рисунок 4).

Рисунок 4 — Архитектура с управляющим слоем, «растянутым» по трём доменам отказа

Архитектура с «растянутым» более чем на три домена отказа слоем управления не тестировалась, но допустима при условии совместной проработки с VK Tech. При правильном подходе к проектированию, это позволит Платформе быть устойчивой к выходу из строя менее половины доменов отказа.

При потере связности с остальной частью Платформы, площадка, содержащая домен отказа слоя управления и зону доступности, продолжит функционировать изолированно. Управление этой зоной доступности будет недоступно. Рабочая нагрузка продолжит выполняться и сохранит связность в пределах доступных сетевых сегментов.

С точки зрения экономии ресурсов, разумным является следующий подход: при наличии в Платформе произвольного числа зон доступности, слой управления растягивается лишь на три домена отказа. Этого достаточно для обеспечения защиты Платформы от выхода из строя любой одной площадки.