Архитектура дистрибутива облачной платформы KeyStack

Описание дистрибутива

KeyStack — дистрибутив облачной платформы от компании ITKey, основанный на OpenStack

Дистрибутив базируется на нескольких элементах:

  • CI-конвейер;

  • OpenStack IaaS;

  • OpenStack baremetal;

  • ELK (EFK) stack;

  • Prometheus.

CI-конвейер состоит из следующего набора компонентов:

GitLab

GitLab — это инструмент для хранения и управления репозиториями Git. Помимо хранения кода, он позволяет организовать процесс CI/CD. Подробнее ознакомиться с документацией по GitLab можно тут: https://docs.gitlab.com/.

Hashicorp Vault

Программное решение, которое помогает организациям снизить риск взлома и раскрытия данных с помощью автоматизации безопасности на основе идентификации и шифрования как услуги. В решении используется функционал хранения чувствительной информации — паролей, токенов, SSL-сертификатов и другой чувствительной информации.
Подробнее ознакомиться с документацией по vault можно тут: https://developer.hashicorp.com/vault/docs.

Sonatype Nexus

Это программный продукт, реализующий функционал управления репозиториями. Используется для хранения докер-образов, pip,rpm, deb и прочих артефактов. Подробнее ознакомиться с решением можно тут: https://www.sonatype.com/products/sonatype-nexus-repository.

Netbox

Это веб-приложение с отрытым исходным кодом, предназначенное для моделирования и документирования современных сетей. Сочетая традиционные практики управления IP-адресами (IPAM) и управления инфраструктурой центра обработки данных (DCIM) с мощными API и расширениями, NetBox представляет собой идеальный “источник достоверной информации” для автоматизации сети. Подробнее ознакомиться с документацией можно тут: https://docs.netbox.dev/en/stable/.

Openstack

Openstack — это набор технологий с открытым исходным кодом. Платформа OpenStack управляет ресурсами виртуальной инфраструктуры, включая виртуальные серверы, устройства хранения, сети и сетевые службы, такие как балансировщики нагрузки, а также предоставляет функции управления пользователям-арендаторам. Подробнее ознакомиться с документацией можно тут: https://docs.openstack.org/.

Гостевые/Хост ОС и гипервизоры

В качестве хост ОС 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

CI/CD-конвейер
KeyStack основан на CI-конвейере (применяется для деплоя инсталляции). Это позволяет использовать KeyStack в цепочке существующего CI/CD-конвейере клиента.
Multi-site облако
Возможно использование KeyStack в качестве отказоустойчивой облачной платформы, размещённой в нескольких ЦОД с общей сетевой связностью.
Публичное облако
KeyStack полностью подходит в качестве платформы для создания и предоставления услуг публичного облака (однако не является платформой для биллинга; при необходимости потребуется интеграция со сторонней биллинговой системой).
Частное облако
KeyStack архитектурно и функционально отлично подходит для создания частного облака.
Предоставление хранилища S3
В дорожной карте KeyStack запланирована реализация CEPH с возможностью организовать S3 с неограниченной масштабируемостью.

Архитектура KeyStack

KeyStack основан на технологии OpenStack

OpenStackScheme

Основные модули 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 к Сервисному оркестратору запланирована в дорожной карте продукта.`

Подробнее об основных модулях можно прочитать в этом разделе. В работе OpenStack задействованы как основные, так и вспомогательные сервисы.

Основные сервисы:

  • Compute service;

  • Networking service;

  • Loadbalancing service;

  • Image service;

  • Volume service;

  • Identity service;

  • Dashboard.

Вспомогательные сервисы:

  • DNS service;

  • Network loadbalancing service;

  • Orchestartion service;

  • Key manager service.

Compute service (Nova)

Nova — сервис, который управляет гипервизорами, виртуальными машинами, жизненным циклом виртуальных машин и предоставляет API-интерфейс.
Nova состоит из следующих компонентов:
Nova-api
Сервис, который принимает и отвечает на API-вызовы конечных пользователей. Обеспечивает соблюдение некоторых политик и инициирует большинство действий по оркестрации, таких как запуск экземпляров виртуальных машин.
Nova-scheduler
Сервис, который вычитывает сообщения из очереди и определяет, на каком гипервизоре запустится виртуальная машина.
Nova-conductor
Осуществляет взаимодействие между сервисом nova-compute и базой данных. Это исключает прямой доступ к облачной базе данных, осуществляемый nova-compute.
Nova-compute
Демон, который создает и завершает экземпляры виртуальных машин через API гипервизора. Например:

  • libvirt для KVM или QEMU

  • VMwareAPI для VMware

Обработка достаточно сложна. По сути, демон принимает действия из очереди сообщений и выполняет ряд системных команд, таких как запуск экземпляра KVM и обновление его состояния в базе данных.

Nova-ssh
Это SSH-сервер, обеспечивающий транспорт для rsync xml-описаний виртуальных машин для миграций между гипервизорами.
Nova-libvirt
Libvirt — наиболее часто используемый драйвер виртуализации в OpenStack. Он использует libvirt при поддержке QEMU и, если доступно, KVM. Libvirt выполняется в контейнере nova_libvirt или как демон, работающий на хосте.
Nova-novncproxy
Серверный демон. Обслуживает службу Nova noVNC Websocket Proxy, которая предоставляет websocket-proxy, совместимый с консолями OpenStack Nova noVNC.
Nova-serialproxy
Серверный демон. Обслуживает службу Nova Serial Websocket Proxy, которая предоставляет websocket-proxy, совместимый с последовательными портами OpenStack Nova.

Подробнее о возможностях Nova, его настройке и возможностях можно узнать тут: https://docs.openstack.org/nova/latest/.

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

  • reserved_host_cpus

  • reserved_host_memory_mb

  • reserved_host_disk_mb

Также можно настроить коэффициенты переподписки по памяти, дискам и процессорам:

  • cpu_allocation_ratio

  • disk_allocation_ratio

  • ram_allocation_ratio

Существуют параметры, которые позволяют задать начальные значения коэффициентов и использовать API-вызовы для их изменения их значений без перезапуска служб Nova-compute:

  • initial_cpu_allocation_ratio

  • initial_ram_allocation_ratio

  • initial_disk_allocation_ratio

Задавать значения данных параметров можно как для конкретных гипервизоров, так и для всех сразу. Для всех гипервизоров сразу — в секцию [DEFAULT] в файле конфигурации config/nova/nova-compute.conf. Для конкретного гипервизора — config/nova/<hypervisor_name>/nova.conf.

Volume service (Cinder)

Служба хранилища блоков OpenStack (Cinder) добавляет виртуальным машинам постоянное хранилище. Оно предоставляет инфраструктуру для управления дисками и взаимодействует с вычислительными ресурсами OpenStack, чтобы предоставить экземплярам диски. Служба также позволяет управлять снимками томов и типами томов.

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

Cinder-api
Принимает запросы API и перенаправляет их в cinder-volume для выполнения действий.
Cinder-volume
Взаимодействует напрямую со службой хранилища блоков и с такими процессами, как cinder-scheduler. Кроме того, взаимодействует с этими процессами при помощи очереди сообщений. Служба cinder-volume отвечает на отправленные службе хранилища блоков запросы чтений и записи, чтобы поддерживать состояние. Может взаимодействовать с разными производителями хранилищ с помощью драйверов.
Cinder-scheduler
Выбирает оптимальный узел производителя хранилища, на котором будет создан том. Похож на компонент nova-scheduler.
Cinder-backup
Служба cinder-backup обеспечивает резервное копирование томов любого типа в хранилище резервного копирования. Аналогично службе cinder-volume, может взаимодействовать с различными производителями хранилищ с помощью драйверов.

В Openstack в качестве системы очередей используется rabbitmq. Взаимодействие между службами Cinder происходит именно через этот сервис.

Подробнее о службе Cinder и его возможностях и сценариях использования можно почитать в официальной документации: https://docs.openstack.org/cinder/latest/.

Orchestartion service (Heat)

Heat — основной проект в программе OpenStack Orchestration. Он реализует механизм оркестрации для запуска нескольких составных облачных приложений на основе шаблонов в виде текстовых файлов, которые можно рассматривать как код. Собственный формат шаблонов Heat развивается, но Heat также стремится обеспечить совместимость с форматом шаблонов AWS CloudFormation, чтобы многие существующие шаблоны CloudFormation можно было запускать в OpenStack. Heat предоставляет как собственный REST API OpenStack, так и API-запросы, совместимые с CloudFormation.

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

Heat-api
Компонент Heat-api предоставляет собственный REST API OpenStack, который обрабатывает запросы API и перенаправляет их в heat-engine для выполнения действий.
Heat-api-cfn
Компонент Heat-api-cfn предоставляет API-запросы в стиле AWS, совместимый с AWS CloudFormation, и обрабатывает API-запросы и перенаправляет их в heat-engine для выполнения действий.
Heat-engine
Компонент Heat-engine выполняет основную работу по организации запуска шаблонов и передаче событий обратно потребителю API.

В Openstack в качестве системы очередей используется rabbitmq. Взаимодействие между службами Heat происходит именно через этот сервис.

Подробнее о службе Heat, ее возможностях и сценариях использования можно почитать в официальной документации: https://docs.openstack.org/heat/latest/.

Image service (Glance)

Служба Glance позволяет пользователям обнаруживать, регистрировать и получать образы виртуальных машин. Она предлагает REST API, который позволяет запрашивать метаданные образа виртуальной машины и получать реальный образ. Вы можете хранить образы виртуальных машин в различных местах: от простых файловых систем до систем объектного хранения, таких как OpenStack Object Storage.

Glance-api
Служба Glance-api принимает API вызовы и позволяет обнаруживать, сохранять и получать информацию об образах. Как правило, используется для загрузки образов виртуальных машин.

Подробнее о службе Glance, ее возможностях и сценариях использования можно почитать в официальной документации: https://docs.openstack.org/glance/latest/.

Identity service (Keystone)

Служба keystone oбеспечивает аутентификацию и авторизацию клиентов через API-интерфейсы, а также распределенную многопользовательскую авторизацию. Поставщик токенов Keystone настраивается через keystone_token_provider. Значением по умолчанию для этого является fernet.

Токены Fernet
Токены Fernet требуют использование ключей, которые необходимо синхронизировать между серверами Keystone. Для этого Kolla Ansible развертывает два контейнера — keystone_fernet, который запускает задания cron для ротации ключей через rsync, когда это необходимо, иkeystone_ssh— SSH-сервер, обеспечивающий транспорт для rsync.

Подробнее о службе Keystone, возможностях и сценариях использования можно почитать в официальной документации: https://docs.openstack.org/keystone/latest/.

Loadbalancing service (Octavia)

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

Octavia состоит из следующих компонентов:

Octaiva-api
Сервис, который принимает и отвечает на API-вызовы конечных пользователей, а также помещает в очередь сообщений для вычитывания сервисом octavia-worker.
Octavia-worker
Сервис, который вычитывает сообщения из очереди и отвечает за оркестрацию амфор. Он взаимодействует с вычислительным драйвером (в некоторых сценариях развертывания), сетевым драйвером и драйвером Amphora для активации экземпляров Amphora, балансировщиков нагрузки и прослушивателей.
Octavia-health-manager
Осуществляет проверку на отсутствующие или нездоровые амфоры в базе данных. Монитор работоспособности проверяет временные метки через настраиваемый интервал, чтобы увидеть, не предоставила ли Amphora контрольный сигнал в течение необходимого периода времени. Если Amphora не сможет сообщить о тактовом сигнале в течение настроенного интервала, диспетчер работоспособности инициирует отработку отказа Amphora и обновит статус прослушивателя в базе данных.

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

Octavia-housekeeping
Управляет запасным пулом амфор и демонтажем амфор, которые больше не нужны. Через настраиваемый интервал времени сервис будет проверять базу данных Octavia, чтобы определить необходимые действия по очистке и обслуживанию. В спецификации управления жизненным циклом амфоры подробно описаны последовательности создания, резервирования и удаления амфор.

Key manager service (Barbican)

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

Служба Barbican состоит из следующих компонентов:

Barbican-api
Предоставляет RESTful API, который поддерживает предоставление секретов Barbican и управление ими.
Barbican-worker
Предоставляет интерфейс Openstack RPC, который взаимодействует с barbican-api очередью сообщений Barbican, читает ее и принимает задания на выполнение.
Barbican-keystone-listener
Прослушивает сообщения службы уведомлений Keystone. Используется для управления представлением проектов Keystone в базе данных Barbican при удалении проектов. Подробнее узнать о возможностях Barbican, его настройке и возможностях можно тут: https://docs.openstack.org/barbican/latest/

Dashboard (Horizon)

Предоставляет графический веб-интерфейс, предназначенный для управления виртуальной инфраструктурой пользователями в рамках предоставленных прав доступа. Подробнее: https://docs.openstack.org/horizon/latest/.

Реализация отказоустойчивости
Отказоустойчивость инсталляций реализуется следующими механизмами защиты (с 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

Multi-site 1

  • Возможность миграции ВМ внутри Cell (ИС), растянутой между ЦОДами;

  • Один домен отказа;

  • Можно нивелировать детальной проработкой архитектуры домена.

Вариант 2

Multi-site 2

  • Возможность миграции ВМ внутри Cell (ИС) внутри одного ЦОДа;

  • N доменов отказа;

  • В роадмапе есть возможность холодной миграции между Region;

  • Возможно проработать использование механизмов репликации на базе СХД.

Вариант 3

Multi-site 3

  • Возможность миграции ВМ внутри Cell (ИС) внутри одного ЦОДа;

  • N доменов отказа;

  • Возможность горячей или холодной миграции средствами партнерского ПО Hystax.

Сетевая архитектура KeyStack

В референсной архитектуре KeyStack предлагается использовать OVS для управления сетевой инфраструктурой в OpenStack-облаке.

SDN

Плюсы

Минусы

OVS

Проверенное годами решение

Схема с агентами и RabbitMQ налагает ограничения на масштабирование

Маршрутизация трафика виртуальной инфраструктуры во внешние сети

Для примера на схеме отображены 2 варианта маршрутизации:

  1. Трафик VM1, VM6 маршрутизируется через Gateway-узлы при помощи SNAT.

  2. На виртуальные машины VM3, VM4, VM5 назначен Floating IP (назначаемый внешний адрес), и их трафик проходит напрямую во внешнюю сеть без Gateway-узлов.

Routing

Прочие функции KeyStack

В KeyStack реализован функционал фильтрации трафика на портах ВМ.
Таким образом, сетевые потоки могут быть отфильтрованы согласно требованиям ИБ Заказчика:
Filyering
В KeyStack реализован сервис LBaaS.
Сервис LBaaS построен на основе OpenStack Octavia и предоставляет сетевые балансировщики как сервис.
LBaaS

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 расширением;

  • Другие режимы балансировки.