# **Архитектура дистрибутива облачной платформы KeyStack** ## Описание дистрибутива ### KeyStack — дистрибутив облачной платформы от компании ITKey, основанный на OpenStack Дистрибутив базируется на нескольких элементах: - CI-конвейер; - OpenStack IaaS; - OpenStack baremetal; - ELK (EFK) stack; - Prometheus. CI-конвейер состоит из следующего набора компонентов: **GitlLab** GitLab — это инструмент для хранения и управления репозиториями Git. Помимо хранения кода, он позволяет организовать процесс CI/CD. Подробнее ознакомиться с документацией по GitLab можно тут: [https://docs.gitlab.com/](https://docs.gitlab.com/). **Hashicorp Vault** Программное решение, которое помогает организациям снизить риск взлома и раскрытия данных с помощью автоматизации безопасности на основе идентификации и шифрования как услуги. В решении используется функционал хранения чувствительной информации — паролей, токенов, SSL-сертификатов и другой чувствительной информации. Подробнее ознакомиться с документацией по vault можно тут: [https://developer.hashicorp.com/vault/docs](https://developer.hashicorp.com/vault/docs). **Sonatype Nexus** Это программный продукт, реализующий функционал управления репозиториями. Используется для хранения докер-образов, pip,rpm, deb и прочих артефактов. Подробнее ознакомиться с решением можно тут: [https://www.sonatype.com/products/sonatype-nexus-repository](https://www.sonatype.com/products/sonatype-nexus-repository). **Netbox** Это веб-приложение с отрытым исходным кодом, предназначенное для моделирования и документирования современных сетей. Сочетая традиционные практики управления IP-адресами (IPAM) и управления инфраструктурой центра обработки данных (DCIM) с мощными API и расширениями, NetBox представляет собой идеальный "источник достоверной информации" для автоматизации сети. Подробнее ознакомиться с документацией можно тут: [https://docs.netbox.dev/en/stable/](https://docs.netbox.dev/en/stable/). **Openstack** Openstack — это набор технологий с открытым исходным кодом. Платформа OpenStack управляет ресурсами виртуальной инфраструктуры, включая виртуальные серверы, устройства хранения, сети и сетевые службы, такие как балансировщики нагрузки, а также предоставляет функции управления пользователям-арендаторам. Подробнее ознакомиться с документацией можно тут: [https://docs.openstack.org/](https://docs.openstack.org/). ___ ### Гостевые/Хост ОС и гипервизоры В качестве хост ОС KeyStack использует дистрибутив на базе Ubuntu linux актуальной LTS версии. При необходимости в качестве хост ОС возможно использование дистрибутива Астра Линукс. В качестве гостевых ОС поддерживаются распространённые ОС Linux и MS Windows. Со списком поддерживаемых гостевых ОС можно ознакомиться по ссылке: . В качестве базового гипервизора используется 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](Media/Pic_01.png) ### Основные модули 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-инфраструктурой. ***Разработка 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//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](http://docs.amazonwebservices.com/AWSCloudFormation/latest/APIReference/Welcome.html?r=7078), чтобы многие существующие шаблоны CloudFormation можно было запускать в OpenStack. Heat предоставляет как [собственный REST API OpenStack](http://developer.openstack.org/api-ref-orchestration-v1.html), так и API-запросы, совместимые с CloudFormation. Служба оркестрации состоит из следующих компонентов: **Heat-api** Компонент Heat-api предоставляет [собственный REST API OpenStack](http://developer.openstack.org/api-ref-orchestration-v1.html), который обрабатывает запросы 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](https://docs.openstack.org/api-ref/image/v2/), который позволяет запрашивать метаданные образа виртуальной машины и получать реальный образ. Вы можете хранить образы виртуальных машин в различных местах: от простых файловых систем до систем объектного хранения, таких как 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](Media/Pic_02.png) - Возможность миграции ВМ внутри Cell (ИС), растянутой между ЦОДами; - Один домен отказа; - Можно нивелировать детальной проработкой архитектуры домена. **Вариант 2** ![Multi-site 2](Media/Pic_03.png) - Возможность миграции ВМ внутри Cell (ИС) внутри одного ЦОДа; - N доменов отказа; - В роадмапе есть возможность холодной миграции между Region; - Возможно проработать использование механизмов репликации на базе СХД. **Вариант 3** ![Multi-site 3](Media/Pic_04.png) - Возможность миграции ВМ внутри Cell (ИС) внутри одного ЦОДа; - N доменов отказа; - Возможность горячей или холодной миграции средствами партнерского ПО Hystax. ___ ### Сетевая архитектура KeyStack **В референсной архитектуре KeyStack предлагается использовать OVS для управления сетевой инфраструктурой в OpenStack-облаке.** |SDN|Плюсы|Минусы| | :- | :- | :- | |OVS|Проверенное годами решение|Схема с агентами и RabbitMQ налагает ограничения на масштабирование| #### Маршрутизация трафика виртуальной инфраструктуры во внешние сети Для примера на схеме отображены 2 варианта маршрутизации: 1. Трафик VM1, VM6 маршрутизируется через Gateway-узлы при помощи SNAT. 2. На виртуальные машины VM3, VM4, VM5 назначен Floating IP (назначаемый внешний адрес), и их трафик проходит напрямую во внешнюю сеть без Gateway-узлов. ![Routing](Media/Pic_05.png) ___ ### Прочие функции KeyStack **В KeyStack реализован функционал фильтрации трафика на портах ВМ.** Таким образом, сетевые потоки могут быть отфильтрованы согласно требованиям ИБ Заказчика: ![Filyering](Media/Pic_07.png) **В KeyStack реализован сервис LBaaS.** Сервис LBaaS построен на основе OpenStack Octavia и предоставляет сетевые балансировщики как сервис. ![LBaaS](Media/Pic_08.png) 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 расширением; - Другие режимы балансировки.