Сервисы 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-инфраструктурой.
Разработка UI к сервисному оркестратору запланирована в дорожной карте продукта.
Категории сервисов¶
В работе OpenStack задействованы как основные, так и вспомогательные сервисы.
Основные сервисы:
Compute service
Networking service
Loadbalancing service
Image service
Volume service
Identity service
Dashboard
Вспомогательные сервисы:
DNS service
Network loadbalancing service
Orchestration service
Key manager service
Compute service (Nova)¶
Nova — сервис, который управляет гипервизорами, виртуальными машинами, жизненным циклом виртуальных машин и предоставляет API-интерфейс.
Nova состоит из следующих компонентов:
Nova-api
Сервис, который принимает и отвечает на API-вызовы конечных пользователей. Обеспечивает соблюдение определённых политик и инициирует большинство действий по оркестрации, таких как запуск экземпляров виртуальных машин.
Nova-scheduler
Сервис, который вычитывает сообщения из очереди и определяет, на каком гипервизоре запустится виртуальная машина.
Nova-conductor
Осуществляет взаимодействие между сервисом nova-compute и базой данных. Это исключает прямой доступ к облачной базе данных, осуществляемый nova-compute.
Nova-compute
Демон, который создаёт и завершает экземпляры виртуальных машин через API гипервизора. Например:
Обработка достаточно сложна. Демон принимает действия из очереди сообщений и выполняет ряд системных команд, таких как запуск экземпляра 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_cpusreserved_host_memory_mbreserved_host_disk_mb
Также можно настроить коэффициенты переподписки по памяти, дискам и процессорам:
cpu_allocation_ratiodisk_allocation_ratioram_allocation_ratio
Существуют параметры, которые позволяют задать начальные значения коэффициентов и использовать API-вызовы для изменения их значений без перезапуска служб Nova-compute:
initial_cpu_allocation_ratioinitial_ram_allocation_ratioinitial_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/
Orchestration 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 обеспечивает аутентификацию и авторизацию клиентов через API-интерфейсы, а также распределённую многопользовательскую авторизацию. Поставщик токенов Keystone настраивается через keystone_token_provider. Значением по умолчанию для этого является 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 состоит из следующих компонентов:
Octavia-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/