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

../_images/OpenStack_Services.png

Рис. 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

../_images/OpenStack_Neutron.png

Рис. 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

../_images/OpenStack_Nova.png

Рис. 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.

../_images/OpenStack_Cinder.png

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

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

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

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

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

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

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

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

../_images/OS_Ceilometer.png

Рис. 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/