Масштабирование KeyStack¶

Характерные проблемы инсталляций upstream OpenStack¶

Одним из важных отличий KeyStack является качественная проработка архитектуры решения, которая обеспечивает отсутствие проблем, присущих большим инсталляциям OpenStack:

В OpenStack все коммуникации происходят через очередь сообщений RabbitMQ и общую СУБД, которые имеют проблемы масштабирования/кластеризации и восстановления работоспособности после сбоя. При увеличении количества узлов количество сообщений в очереди растёт в геометрической прогрессии.
Neutron ML2 OVS — нагрузка растёт в геометрической прогрессии ввиду принципа управления сетевой инфраструктурой через агенты, которые также используют очередь сообщений.

Решения масштабирования¶

Multi-site облако разделяется на регионы (создаются домены отказа со своими собственными изолированными control plane).
При необходимости возможно выделение нескольких Nova Cell внутри Region.
Cell, в отличие от Region, имеет общий сервис Nova, что позволяет как потребителям, использующим API, так и пользователям в графическом портале прозрачно управлять созданием виртуальных машин в разных Cell через единую точку входа.
Функционал Nova Cell позволяет масштабировать Nova. С ним Nova нормально управляет несколькими тысячами хостов, тогда как без него предел — 2-3 сотни.
В OpenStack "из коробки" невозможна миграция ВМ между Region. Также доступна только холодная миграция между Cell. В KeyStack этот функционал (холодная миграция между Region) запланирован в дорожной карте, или его можно использовать партнёрским решением Hystax DR.
Availability Zones (AZ) в KeyStack — логическая группировка гипервизоров, сетевых и baremetal-функций. По сути, AZ — это параметры настройки планировщика для правильного размещения объектов внутри KeyStack в момент их создания. В нашей облачной платформе мы рекомендуем создавать AZ в рамках Cell и не растягивать AZ на несколько Cells, чтобы соблюдать идеологию доменов отказоустойчивости.
Мы рекомендуем использовать OVS-плагин для Neutron как более стабильное и задокументированное решение.
Мы рекомендуем рассмотреть OVN-плагин для Neutron при необходимости масштабирования более чем 200 узлов.

Сегментация нагрузок в KeyStack¶

Категория	Когда использовать?	Пример	Избыточность	Общие сервисы
Cells	Единый API-endpoint для compute или необходимость в дополнительном уровне планировщика Nova	Облако, распределённое на множество площадок, где вы можете создать ВМ "где угодно" или на конкретной площадке	Самая молодая сегрегация. Каждый cell — отдельная БД и менеджер очередей с общими сервисами Nova	Все сервисы
Regions	Отдельный регион с собственными API-endpoints без координации между регионами	Облако, распределённое на множество площадок, где вы можете создать ВМ на конкретной площадке	Различные API-endpoints для каждого региона. Каждый регион имеет свой control-plane	Можно Keystone
Availability Zones	Для создания группы хостов с общими признаками (не ограничивается Nova)	Облако на одной площадке с серверами, запитанными от разных источников	Правка конфигурации в nova.conf и OpenStack БД	Все сервисы
Host Aggregates	Логическое разделение Nova на группы хостов (гипервизоров)	Распределение нагрузки по группам серверов с разными характеристиками и или PCI-устройствами	Правка конфигурации в nova.conf и OpenStack БД	Все сервисы

Выбор multi-site архитектуры¶

В зависимости от требований заказчика, KeyStack можно развернуть в трёх основных конфигурациях multi-site.

Вариант 1

Возможность миграции ВМ внутри Cell (ИС), растянутой между ЦОДами
Один домен отказа
Можно нивелировать детальной проработкой архитектуры домена

Вариант 2

Возможность миграции ВМ внутри Cell (ИС) внутри одного ЦОДа
N доменов отказа
В роадмапе есть возможность холодной миграции между Region
Возможно проработать использование механизмов репликации на базе СХД

Вариант 3

Возможность миграции ВМ внутри Cell (ИС) внутри одного ЦОДа
N доменов отказа
Возможность горячей или холодной миграции средствами партнёрского ПО Hystax