1.3 СПО OpenStack и ПО TIONIX

СПО OpenStack имеет логический дизайн архитектуры, охватывающий практически все аспекты информационных технологий, связанные со сбором, накоплением и обработкой данных. Конечному пользователю предоставляются утилиты для работы из командной строки, а также – графические средства управления облачными ресурсами [1].

Все ключевые службы OpenStack обращаются в службу идентификации прежде чем позволить выполнение операций, затребованных пользователем/администратором. При этом используется единый программный интерфейс – OpenStack Indentity API [2].

Сетевое взаимодействие между компонентами OpenStack подчинено единому концепт-дизайну [3].

ПО ТIONIX в разной мере использует функциональность СПО Openstack на уровне компонентов [4].

1.3.1 Используемые компоненты OpenStack

Компоненты OpenStack имеют собственные имена, ассоциированные с проектами:

• Dashboard — панель управления облачной инфраструктурой;
• Nova — контроллер вычислительных ресурсов;
• Glance — библиотека образов виртуальных машин;
• Cinder — служба работы с блочными устройствами хранения данных;
• Keystone — служба идентификации;
• Neutron — сетевая служба, устанавливаемая на вычислительные узлы;
• Horizon — графический интерфейс администрирования;
• Heat — оркестратор;
• Ceilometer — средства сбора, нормализации и трансформации данных (телеметрии).

Назначение служб (компонентов) Openstack:

Dashboard (Horizon) –

канонизированная реализация компонента OpenStack’s – Dashboard, которая предоставляет основанный на веб-технологиях интерфейс управления службами OpenStack, такими как Nova, Swift, Keystone и др.

Neutron (Network Service) –

предоставляет «Сеть как сервис» для остальных служб OpenStack и виртуальных машин, функционально расширяемый с помощью плагинов. Подключение к сети производится между интерфейсами устройств (vNIC), управляемыми другими службами OpenStack. Включает в себя пользовательское API для определения сетей и присоединения к ним ВМ;

Nova (Compute Service) –

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

Glance (Image Service) –

позволяет обнаруживать, регистрировать и извлекать образы виртуальных машин;

Cinder (Block Storage Service) –

служба блочного хранилища, используемого для хранения виртуальных дисков на внешнем хранилище данных;

Keystone (Identity Service) –

служба идентификации интегрирует управление аутентификацией, авторизацию и каталог служб. Другие службы OpenStack используют службу идентификации для проверки подлинности пользователей и обнаружения других служб (в рамках развертывания);

Ceilometer (Telemetry Data Collection Service) –

инструмент для сбора различных статистических данных в облаке OpenStack (данные предоставляют службы OpenStack). Основной целью проекта является мониторинг нагрузки и измерение потребления клиентами выделенных облачных ресурсов.

1.3.2 Функциональные связи компонентов OpenStack

Рис. 1.1 Архитектура облачной платформы OpenStack

При создании облачной инфраструктуры (Рис. 1.1) ОП TIONIX в различной мере использует функции следующих компонентов OpenStack [5]:

• панель управления (Dashboard – Horizon);
• служба идентификации (Identity Service – Keystone);
• cетевая служба (Networking Service – Neutron);
• вычислительная служба (Compute Service – Nova);
• служба хранилищ образов (Image Storage Service – Glance);
• служба блочных хранилищ (Block Storage Service – Cinder);
• управление/оркестрация (Orchestration Service – Heat);
• служба телеметрии (Telemetry Service – Ceilometer).

Примечание.

Названия служб OpenStack указаны со ссылками на веб-ресурсы.

1.3.3 Взаимодействие TIONIX с OpenStack

Функциональность модулей TIONIX основана на использовании программных интерфейсов СПО OpenStack [6]. Прежде чем обратиться к какой-либо службе, модуль выполняет запрос на аутентификацию (OpenStack Identity) с указанием реквизитов. В ответ модуль получает токен.

Управляющие функции выполняют модули NodeControl и Scheduler. TIONIX.NodeControl – ключевой модуль облачной платформы. Он обеспечивает централизованное управление аппаратными и виртуальными ресурсами облачной инфраструктуры. TIONIX.Scheduler – планировщик работы вычислительных узлов – является вспомогательным.

В повседневной работе администратора облачной инфраструктуры возникает необходимость вызова определенного функционала OpenStack из командной строки. Такое взаимодействие обеспечивается с помощью так называемого клиента – Openstack Client [7].

Ниже представлена таблица взаимосвязей между модулями облачной платформы TIONIX и компонентами OpenStack.

Таблица 1.2 Взаимосвязи между модулями ОП и компонентами OpenStack

№	Модуль ПО «Тионикс»	Компоненты OpenStack
	TIONIX.NodeСontrol	Neutron, Nova
	TIONIX.Dashboard	Cinder, Keystone, Neutron, Nova, Glance
	TIONIX.Monitor	Ceilometer, Gnocchi
	TIONIX.Scheduler	Cinder, Keystone, Nova
	TIONIX.Client	Horizon
	VDIclient	–
	VDIserver	–
	TIONIX.Agent	–

1.3.4 Сетевая инфраструктура OpenStack

Если задействовать существующую (физическую) сетевую инфраструктуру для выделения IP-адресов и для передачи данных между узлами, то в мультитенантной среде, содержащей несколько арендаторов, это приведет к тому, что имеющаяся система управления сетью будет неспособна эффективно и надежно изолировать трафик между пользователями облачной инфраструктуры.

В этом случае облачная среда нуждается в построении тщательно продуманного стека сетевого управления, который обрабатывал бы все связанные с сетью запросы. Для решения такого рода задач создан абстрактный уровень под названием OpenStack Networking и поддерживающий компонент – сетевая служба (Networking Service). Эта служба, называемая Neutron [8], содержит ассортимент плагинов, обеспечивающих интеграцию с другими сетевыми сервисами.

1.3.4.1 Модель OpenStack Networking

OpenStack Networking базируется на простой модели абстракций, используемой для описания сетевых ресурсов (виртуальные сети, подсети, порты).

Сеть представляет собой изолированный сегмент уровня 2 (L2), аналогичный виртуальной локальной сети (VLAN) в мире физических сетей.

Подсеть – это совокупность IP-адресов (v4 или v6) и ассоциированных с ними конфигураций. IP-адреса из этого пула платформа OpenStack может назначать виртуальным машинам. Каждая подсеть специфицируется как CIDR-диапазон IP-адресов и должен быть ассоциирована с какой-либо сетью. Помимо подсети, арендатор может при желании указать шлюз, список DNS-серверов и набор маршрутов хостов. Все экземпляры виртуальных машин в этой подсети автоматически унаследуют эту конфигурацию.

Порт – это точка подключения к виртуальному коммутатору. Экземпляр виртуальной машины способен подключить свой сетевой адаптер к виртуальной сети через порт. После создания порта он получает фиксированный IP-адрес от одной из указанных подсетей. После высвобождения порта все выделенные ему IP-адреса также высвобождаются и возвращаются в пул адресов. Кроме того, платформа OpenStack позволяет задавать MAC-адреса, которые должен использовать интерфейс.

OpenStack Networking позволяет создавать плагины [9], обеспечивающие поддержку расширенных сетевых возможностей, таких как L2/L3-туннелирование и сквозная поддержка качества обслуживания (QoS). Сторонние поставщики могут создавать, кроме собственных плагинов, различные сетевые сервисы (балансировщики нагрузки, виртуальные частные сети, брандмауэры и т. д.), включаемые в сети арендаторов OpenStack [10].

1.3.4.2 Плагины

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

Выбор определенного плагина осуществляется администратором или IT-архитектором, который способен оценить предлагаемые возможности и согласовать их с требованиями конкретной установки (референсной архитектуры).

Некоторые плагины OpenStack Networking могут использовать базовые механизмы Linux (IP-таблицы и VLAN-сети).

1.3.4.3 Архитектура Neutron

Рис. 1.2 Архитектура сетевой службы Neutron

Neutron server – это основной серверный процесс OpenStack Networking. ПО сервера реализовано в виде демона (Core plugin* на Рис. 1.2), перенаправляющего запросы из API OpenStack Networking в сконфигурированный плагин (ML2 или Vendor-specific). Кроме сервера, в состав OpenStack Networking включены три агента (L2/L3/DHCP), которые могут взаимодействовать с основным процессом. Взаимодействие между сервером и агентами происходит через очередь сообщений (Message queue) или через стандартный API-интерфейс OpenStack Networking.

Агент DHCP (системная служба neutron-dhcp-agent) предоставляет DHCP-сервисы всем сетям арендатора.

Агент L3 (системная служба neutron-l3-agent) поддерживает функциональность L3/NAT [11], чтобы обеспечить виртуальным машинам (в сетях арендаторов) доступ к внешней сети.

Необязательный агент, определяемый плагином (neutron-*-agent), выполняет конфигурирование локального виртуального коммутатора на каждом гипервизоре.

Интеграция с компонентом OpenStack Compute (Nova) является более специфичной. При запуске виртуального экземпляра службой Nova производится связывание с компонентом OpenStack Networking. Цель – включения каждого интерфейса виртуальной сети в соответствующий порт.

1.3.5 Вычислительная инфраструктура OpenStack

Рис. 1.3 Принцип организации вычислительной инфраструктуры (OpenStack)

Управление вычислительными ресурсами реализовано с помощью гипервизора (KVM Hypervisor на Рис. 1.3).

Служба Nova (Compute Service) обеспечивает управление экземплярами виртуальных машин, обращаясь к гипервизору за выполнением API-команд: запуск ВМ; останов ВМ; и т.п.

OpenStack Nova состоит из следующих компонентов (системных служб):

openstack-nova-api – отвечает за обработку пользовательских вызовов API;

openstack-nova-scheduler – планировщик, получает из очереди запросы на запуск ВМ и выбирает узел для запуска;

openstack-nova-conductor – выступает в качестве посредника между базой данных и nova-compute, позволяет осуществлять горизонтальное масштабирование;

openstack-nova-novncproxy – выступает в роли VNС-­прокси и позволяет подключаться к консоли ВМ при помощи веб-браузера;

openstack-nova-consoleauth – отвечает за авторизацию для предыдущего сервиса;

openstack-nova-placement-api – отвечает за отслеживание списка ресурсов и их использование;

openstack-nova-compute – демон, управляющий виртуальными машинами через API гипервизора.

Примечание.

Демон openstack-nova-compute, как правило, запускается на вычислительных узлах, где располагается гипервизор.

Компоненты OpenStack Compute (Nova) взаимодействуют со следующими инфраструктурными компонентами кластера:

• брокером сообщений RabbitMQ и СУБД MySQL/MariaDb;
• сервисом кэширования данных в оперативной памяти (memcached).

Выбор гипервизора для запуска ВМ осуществляется планировщиком [12], согласно весам узлов и после применения фильтров, таких как: необходимый объем оперативной памяти, определенная зона доступности, и т.п.

1.3.6 Инфраструктура хранения образов

Компонент Glance управляет образами в кластере OpenStack, но не отвечает за их фактическое хранение. Glance обеспечивает абстрагирование нескольких технологий хранения, в диапазоне от простых файловых систем до систем хранения объектов, таких как проект Swift (OpenStack Object Storage).

Помимо участия в управлении образами дисков, Glance отвечает за хранение метаданных и сведений о состоянии, описывающих эти образы [13].

OpenStack Image Store – это центральный репозиторий виртуальных образов. Он позволяет пользователям и другим проектам сохранять как публичные, так и частные образы, к которым эти пользователи/проекты могут обращаться (с целью запуска экземпляров).

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

1.3.7 Инфраструктура хранилищ

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

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

– эфемерное хранилище (Ephemeral storage):

Если Вы разворачиваете только службу OpenStack Nova (Compute service), то по-умолчанию ваши пользователи не имеют доступа к какой бы то ни было форме организации постоянного хранения информации (persistent storage). Диски, ассоциированные с виртуальными машинами, являются эфермерными в том смысле, что с точки зрения пользователя они пропадают, как только завершается работа ВМ.

– постоянное хранилище (Persistent storage):

Под постоянным хранилищем подразумевается то, как ресурс хранилища (storage resource) переживает любой другой ресурс и всегда доступен по отношению к (изменяемому) статусу запускаемого инстанса.

Архитектурный дизайн OpenStack [14] предусматривает несколько видов хранилищ:

• объектное хранилище (Object Storage);
• блочное хранилище (Block Storage);
• файловое хранилище (File-based storage).

Ниже приведен принцип организации инфраструктуры блочного хранилища (Рис. 1.4), наиболее употребимого облачными платформами, построенными на основе Openstack и применимыме в рамках референсной архитектуры TIONIX.

Рис. 1.4 Принцип организации инфраструктуры хранилища (OpenStack)

Подключение и использование хранилища (Storage Array) обеспечивается драйвером (driver). Реализация драйвера чувствительна к архитектуре хранилища, с одной стороны и привязана к той или иной службе, с другой. Взаимодействие облачных служб с хранилищем реализуется через слой абстракции – Cinder API [15].

Необходимость создания и/или подключения системы хранения данных к ОП является жизненно важным аспектом для решения общей стоимости владения (TCO). Заказчики, которые хотят сэкономить деньги на инфраструктуре хранения, скорее всего рассмотрят программно-определяемую СХД (SDS). SDS может предложить приемлемое решение для клиентов с крупными инвестициями в наследуемые системы хранения, которым на начальном этапе внедрения не требуется гибкость и масштабируемость.

1.3.8 Телеметрия (измерение производительности, метрики)

Так как OpenStack предоставляет инфраструктуру как услугу конечным клиентам (модель IaaS), важно иметь возможность измерения производительности, чтобы оценивать эффективность работы аппаратной части, масштабируемость, а также получать статистику об использовании объектов [16].

OpenStack предлагает типовое решение – проект Ceilometer. Фактически, этот проект позволяет создать инфраструктуру сбора метрик в облаке, избежав разработку многочисленных решений с одинаковыми функциями [17].

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

Наглядное представление архитектуры службы телеметрии показано ниже (Рис. 1.5).

Рис. 1.5 Архитектура службы телеметрии (Ceilometer)

По умолчанию, в качестве системы хранения (собранных метрик) используется Gnocchi – бэкэнд службы Ceilometer [#]; он устанавливается с помощью автоматизированного сценария (роли Ansible) [18].

Помимо непосредственного хранилища данных, для Gnocchi дополнительно требуется реляционная база данных с поддержкой SQL, которая хранит индексы метрик и их метаданные [19].

Сноски

[1]	https://habr.com/ru/company/mirantis_openstack/blog/189012/

[2]	https://docs.openstack.org/openstack-ansible/latest/ru/user/prod/gnocchi_redis.html

[3]	https://docs.openstack.org/openstack-ansible-os_gnocchi/victoria/

[4]	https://habr.com/ru/company/selectel/blog/340054/

[5]	https://docs.openstack.org/arch-design/design.html

[6]	https://docs.openstack.org/ocata/config-reference/identity.html

[7]	https://docs.openstack.org/arch-design/design-networking/design-networking-concepts.html

[8]	https://www.openstack.org/software/project-navigator/openstack-components

[9]	https://docs.openstack.org/ocata/ru/install-guide-rdo/common/get-started-conceptual-architecture.html

[10]	https://docs.openstack.org/api-quick-start/api-quick-start.html

[11]	https://docs.openstack.org/python-openstackclient/queens/cli/commands.html

[12]	https://ru.bmstu.wiki/OpenStack#Neutron

[13]	https://docs.openstack.org/devstack/latest/plugins.html

[14]	https://www.ibm.com/developerworks/ru/library/cl-openstack-neutron/cl-openstack-neutron-pdf.pdf

[15]	https://wiki.openstack.org/wiki/L3_mixin_to_plugin

[16]	https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html

[17]	https://github.com/openstack/neutron

[18]	https://gnocchi.osci.io

[19]	https://docs.openstack.org/arch-design/design-storage/design-storage-concepts.html

[20]	https://docs.openstack.org/cinder/latest/