Архитектура дистрибутива облачной платформы KeyStack
Описание дистрибутива
KeyStack — дистрибутив облачной платформы от компании ITKey, основанный на OpenStack
Дистрибутив базируется на нескольких элементах:
CI-конвейер;
OpenStack IaaS;
OpenStack baremetal;
ELK (EFK) stack;
Prometheus.
CI-конвейер состоит из следующего набора компонентов:
Gitlab
GitLab — это инструмент для хранения и управления репозиториями Git. Помимо хранения кода, он позволяет организовать процесс CI/CD.
Hashicorp Vault
Программное решение, которое помогает организациям снизить риск взлома и раскрытия данных с помощью автоматизации безопасности на основе идентификации и шифрования как услуги. В решении используется функционал хранения чувствительной информации — паролей, токенов, SSL-сертификатов и другой чувствительной информации.
Sonatype Nexus
Это программный продукт, реализующий функционал управления репозиториями. Используется для хранения докер-образов, pip,rpm, deb и прочих артефактов.
Netbox
Это веб-приложение с отрытым исходным кодом, предназначенное для моделирования и документирования современных сетей. Сочетая традиционные практики управления IP-адресами (IPAM) и управления инфраструктурой центра обработки данных (DCIM) с мощными API и расширениями, NetBox представляет собой идеальный “источник достоверной информации” для автоматизации сети.
Гостевые/Хост ОС и гипервизоры
В качестве хост ОС KeyStack использует дистрибутив на базе Ubuntu linux актуальной LTS версии. При необходимости в качестве хост ОС возможно использование дистрибутива Астра Линукс.
В качестве гостевых ОС поддерживаются распространённые ОС Linux и MS Windows. Со списком поддерживаемых гостевых ОС можно ознакомиться по ссылке: https://www.linux-kvm.org/page/Guest_Support_Status.
В качестве базового гипервизора используется KVM как самый зрелый и проверенный гипервизор. При необходимости возможно использование гипервизора VMware ESXi (в рамках существующей инсталляции VMware vSphere).
Работа с Baremetal серверами
KeyStack Baremetal поддерживает следующие действия с поддерживаемыми физическими серверами:
Установка ОС на сервера;
Подключение в сеть;
Базовые действия администрирования (start/restart/stop/delete);
Подключение СХД к серверам.
Сервис объектного хранилища (в дорожной карте)
В дистрибутиве предусмотрен сервис объектного хранилища. Его особенности:
Построен на базе CEPH, в Single-site и Multi-site конфигурациях;
Хранение образов OpenStack Glance, из которых развёртываются ВМ;
Предоставления S3-совместимого хранилища потребителям платформы.
Работа с учетными записями
В качестве основы для управления учётными записями используется Keycloak. Keykloak позволяет решить следующие задачи:
Централизованное управление учётными записями;
Обеспечение политик безопасности — срок действия учётной записи, срок действия пароля и др.;
Возможность интеграции со службой каталогов Заказчика (LDAP, AD, SAML, OpenID).
Мониторинг
В референс-архитектуре KeyStack в качестве системы мониторинга используется Prometheus. OpenStack имеет хорошую совместимость с Prometheus, возможна интеграция на уровне:
Агентов мониторинга на хост-ОС;
Экспортеров OpenStack для мониторинга состояния виртуальной инфраструктуры;
Возможно произвести интеграцию с существующей платформой мониторинга клиента.
Преимущества и сценарии использования KeyStack
Архитектура KeyStack
KeyStack основан на технологии OpenStack
Основными модулями KeyStack являются:
Наименование |
Краткое описание |
|---|---|
OpenStack Nova |
Контроллер вычислительных ресурсов, отвечает за создание ВМ |
OpenStack Keystone |
Сервис идентификации, отвечает за аутентификацию и авторизацию всех субъектов в KeyStack |
OpenStack Neutron |
Контроллер программно-определяемых сетей в KeyStack, отвечает за управление виртуальными сетями тенантов (проектов) |
OpenStack Glance |
Библиотека образов виртуальных машин, отвечает за хранение образов ОС для последующего развёртывания ВМ |
OpenStack Cinder |
Сервис работы с блочными устройствами хранения данных, отвечает за предоставления ВМ дискового пространства и операции с дисковым пространством |
OpenStack Horizon |
Графический интерфейс администрирования |
OpenStack Heat |
Инфраструктурный оркестратор |
OpenStack Barbican |
Сервис безопасного хранения секретов (пароли, ключи, X509 сертификаты) |
OpenStack Octavia |
Контроллер сетевых балансировщиков как сервис |
OpenStack Ironic |
Сервис управления и провижининга физическими серверами (Bare Metal Provisioning) |
OpenStack Designate |
Контроллер DNS как сервис |
HA модуль ITKey |
Контроллер HA для виртуальных машин |
DRS модуль ITKey |
Контроллер DRS для виртуальных машин |
Одним из важнейших модулей KeyStack является сервисный оркестратор (построен на базе CI/CD-пайплайнов), предназначенный для централизованного управления инфраструктурой. Возможности встроенного сервисного оркестратора KeyStack:
Управление multi-site инфраструктурой — при деплое большой инсталляции (>1500 хостов) применяется схема разделения инсталляции на regions и cells, и сервисный оркестратор позволяет управлять разными регионами как единым облаком;
Сервисный каталог — портал с XaaS услугами в режиме самообслуживания;
Day-2 автоматизация — автоматизация жизненного цикла сервисов после создания;
Управление kubernetes-инфраструктурой.
:bolditalic:`Разработка UI к Сервисному оркестратору запланирована в дорожной карте продукта.`
Реализация отказоустойчивости
Отказоустойчивость инсталляций реализуется следующими механизмами защиты (с 100%̆ совместимостью с upstream-кодом):
Control plane:
Выделяется 3 или более контроллеров для создания кворума;
Все API-сервисы OpenStack — stateless, и они запускаются на каждом контроллере с балансировкой haproxy;
Кластеризуемые сервисы разворачиваются в режиме “Active-Active” ;
Защита СУБД осуществляется с помощью MariaDB Galera.
Data plane:
Мощности Data plane рассчитываются с запасом, чтобы HA-модуль ITKey смог отработать.
Характерные проблемы инсталляций upstream OpenStack
Одним из важных отличий KeyStack является качественная проработка архитектуры решения, которая обеспечивает отсутствие проблем, присущих большим инсталляциям OpenStack:
В OpenStack все коммуникации происходят через очередь сообщений RabbitMQ и общую СУБД, которые имеют проблемы масштабирования/кластеризации и восстановлении работоспособности после сбоя. При увеличении количества узлов количество сообщений в очереди растёт в геометрической прогрессии;
Neutron ML2 OVS — нагрузка растёт в геометрической прогрессии ввиду принципа управления сетевой инфраструктурой через агенты, которые также используют очередь сообщений.
Решение
Multi-site облако разделяется на Regions (создаются домены отказа со своими собственными изолированными 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 |
Regions |
Availability Zones |
Host Aggregates |
|
|---|---|---|---|---|
Когда использовать? |
Единый API-endpoint для compute или необходимость в дополнительном уровне планировщика Nova |
Отдельный регион с собственными API-endpoints без координации между регионами |
Для создания группы хостов с общими признаками (не ограничивается Nova) |
Логическое разделение Nova на группы хостов (гипервизоров) |
Пример |
Облако, распределённое на множество площадок, где вы можете создать ВМ “где угодно” или на конкретной площадке |
Облако, распределённое на множество площадок, где вы можете создать ВМ на конкретной площадке |
Облако на одной площадке с серверами, запитанными от разных источников |
Распределение нагрузки по группам серверов с разными характеристикам и или PCI-устройствами |
Избыточность |
Самая молодая сегрегация. Каждый cell — отдельная БД и менеджер очередей с общими сервисами Nova |
Различные API-endpoints для каждого региона. Каждый регион имеет свой control-plane |
Правка конфигурации в nova.conf и OpenStack БД |
Правка конфигурации в nova.conf и OpenStack БД |
Общие сервисы |
Все сервисы |
Можно Keystone |
Все сервисы |
Все сервисы |
Выбор multi-site архитектуры
В зависимости от требований Заказчика, KeyStack можно развернуть в трёх основых конфигурациях multi-site
Вариант 1
Возможность миграции ВМ внутри Cell (ИС), растянутой между ЦОДами;
Один домен отказа;
Можно нивелировать детальной проработкой архитектуры домена.
Вариант 2
Возможность миграции ВМ внутри Cell (ИС) внутри одного ЦОДа;
N доменов отказа;
В роадмапе есть возможность холодной миграции между Region;
Возможно проработать использование механизмов репликации на базе СХД.
Вариант 3
Возможность миграции ВМ внутри Cell (ИС) внутри одного ЦОДа;
N доменов отказа;
Возможность горячей или холодной миграции средствами партнерского ПО Hystax.
Сетевая архитектура KeyStack:
В референсной архитектуре KeyStack предлагается использовать OVS для управления сетевой инфраструктурой в OpenStack-облаке.
SDN |
Плюсы |
Минусы |
|---|---|---|
OVN |
OVN — продолжение OVS, отказ от коммуникации через RabbitMQ, совместимость с Kubernetes, возможности масштабирования |
Самый новый проект (с 2015 года) |
OVS |
Проверенное годами решение |
Схема с агентами и RabbitMQ налагает ограничения на масштабирование |
Маршрутизация трафика виртуальной инфраструктуры во внешние сети
Для примера на схеме отображены 2 варианта маршрутизации:
Трафик VM1, VM6 маршрутизируется через Gateway-узлы при помощи SNAT.
На виртуальные машины VM3, VM4, VM5 назначен Floating IP (назначаемый внешний адрес), и их трафик проходит напрямую во внешнюю сеть без Gateway-узлов.
Прочие функции KeyStack
Octavia позволяет создавать балансировщики в виртуальных машинах, контейнерах или на baremetal, а также поддерживает следующие типы балансировки:
HTTP-балансировка;
HTTP-балансировка с health-монитором;
Session-persistent HTTP-балансировка;
TCP-балансировка;
UDP-балансировка;
QoS ruled-балансировка;
Балансировка с ACL по IP;
Non-terminated HTTPS-балансировка;
TLS-terminated HTTPS-балансировка;
TLS-terminated HTTPS-балансировка с SNI;
TLS-terminated HTTPS-балансировка c аутентификацией;
HTTP/2-балансировка с ALPN TLS расширением;
Другие режимы балансировки.