Технический справочник. Основные компоненты zVirt

1. Менеджер управления

Менеджер управления обеспечивает централизованное управление средой виртуализации. Доступ к Менеджеру управления можно получить через несколько различных интерфейсов, при этом каждый по-разному обеспечивает доступ к среде виртуализации.

Рисунок 1. Архитектура Менеджера управления

Менеджер управления предоставляет графические интерфейсы и API-интерфейс. Каждый интерфейс подключается к Менеджеру управления, т. е. к приложению, доставляемому встроенным экземпляром Wildfly. Помимо Wildfly, существует ряд других компонентов, которые поддерживают Менеджер управления.

2. Среда исполнения zVirt

К среде zVirt подключены один или несколько хостов. Хост — это сервер, который предоставляет физическое оборудование, используемое виртуальными машинами.

На хосте работает оптимизированная среда исполнения zVirt Node, предназначенная для создания хостов виртуализации.

Рисунок 2. Архитектура хоста

Модуль Kernel-based Virtual Machine (KVM): Модуль Kernel-based Virtual Machine (KVM) — это загружаемый модуль ядра, который обеспечивает полную виртуализацию с помощью расширений аппаратных средств Intel VT или AMD-V. Хотя сам модуль KVM работает в пространстве ядра, выполняющиеся на нем гостевые процессы работают как отдельные процессы QEMU в пространстве пользователя. С помощью KVM хост делает свое физическое оборудование доступным для виртуальных машин.
Эмулятор QEMU: QEMU — это мультиплатформенный эмулятор для полной эмуляции системы. QEMU эмулирует систему полностью, например, ПК, в том числе один или несколько процессоров и периферийные устройства. Эмулятор можно использовать для запуска различных операционных систем или для отладки системного кода. QEMU, работая в связке с KVM и процессором с соответствующими расширениями виртуализации, обеспечивает полную аппаратную виртуализацию.
Агенты хоста Менеджера управления, VDSM: В zVirt, VDSM запускает действия над виртуальными машинами и хранилищем, а также поддерживает связь между хостами. VDSM отслеживает ресурсы хоста: память, хранилище и сеть. Кроме того, VDSM занимается диспетчеризацией задач при создании виртуальных машин, сборе статистики и журналов. Экземпляр VDSM запускается на каждом хосте и получает команды управления от Менеджера управления через перенастраиваемый порт 54321.
VDSM-REG: VDSM с помощью VDSM-REG регистрирует каждый хост в Менеджере управления. VDSM-REG предоставляет информацию о самом себе и своем хосте через порт 80 или порт 443.
libvirt: Libvirt поддерживает управление виртуальными машинами и ассоциированными с ними виртуальными устройствами. Когда Менеджер управления запускает команды жизненного цикла виртуальной машины (запуск, остановка, перезагрузка), VDSM вызывает libvirt на соответствующих хостах для их выполнения.
Менеджер пула хранения (Storage Pool Manager, SPM): Менеджер пула хранения (Storage Pool Manager, SPM) — это роль, назначаемая одному хосту в центре данных. Хост SPM обладает исключительным правом вносить все изменения в метаданные структуры домена хранения в конкретном центре данных. Сюда относятся создание, удаление и управление виртуальными дисками, снимками и шаблонами, а также выделение ресурсов хранилища для динамически расширяемых блочных устройств в SAN хранилищах. Роль SPM можно передать любому хосту в центре данных. В результате у всех хостов в центре данных должен быть доступ ко всем доменам хранения, заданным в центре данных.

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

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

3. Компоненты, поддерживающие Менеджер управления

3.1. WildFly

WildFly — это сервер приложений Java, предоставляющий фреймворк для эффективной разработки и доставки кросс-платформенных приложений Java. Менеджер управления доставляется через WildFly.

Версию WildFly, поставляемую вместе с Менеджером управления, нельзя использовать для обслуживания других приложений. Она была настроена специально для обслуживания Менеджера управления. Если сервер WildFly, входящий в состав Менеджера управления, использовать в дополнительных целях, то это отрицательно сказывается на его способности обслуживать среду zVirt.

3.2. Сбор отчетов и данных истории

Менеджер управления включает в себя хранилище (DWH, Data Warehouse), которое собирает данные мониторинга о хостах, виртуальных машинах и хранилищах, а также в нем предусмотрено несколько предварительно заготовленных отчетов. Заказчики могут анализировать свои среды и создавать отчеты с помощью любых инструментов запросов, поддерживающих SQL.

В процессе установки Менеджера управления создаются две базы данных:

Менеджер управления использует базу данных engine в качестве основного хранилища данных. В этой базе данных хранится информация о среде виртуализации, например, о ее состоянии, конфигурации и производительности.
В базе данных ovirt_engine_history содержится информация о конфигурации и статистические показатели, которые консолидируются с течением времени из операционной базы данных engine. Данные о конфигурации в базе данных engine проверяются ежеминутно, а изменения реплицируются в базу данных ovirt_engine_history. Отслеживание изменений в базе данных позволяет получить информацию об объектах в базе данных, а также проанализировать и повысить производительность среды zVirt и устранить неполадки.

Дополнительные сведения о создании отчетов на основе базы данных ovirt_engine_history см. в разделе База данных истории в Руководстве по хранилищу zVirt.

Репликация данных в базу данных ovirt_engine_history выполняется сервисом ovirt-engine-dwhd.

Эти базы данных создаются на экземпляре Postgres, который выбирается во время установки.

3.3. Службы каталогов

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

389ds
389ds RFC-2307 Schema
Active Directory
IBM Security Directory Server
IBM Security Directory Server RFC-2307 Schema
IPA
Novell eDirectory RFC-2307 Schema
OpenLDAP RFC-2307 Schema
OpenLDAP Standard Schema
Oracle Unified Directory RFC-2307 Schema
RFC-2307 Schema (Generic)
RHDS
RHDS RFC-2307 Schema
iPlanet

Существует также локальный, внутренний домен, предназначенный только для целей администрирования. В этом внутреннем домене есть только один пользователь: администратор (admin).

4. Хранилище

В zVirt используется централизованная СХД для виртуальных дисков, шаблонов, снимков и файлов ISO. Хранилище логически сгруппировано в пулы хранения, которые состоят из доменов хранения. Домен хранения объединяет в себе емкость хранилища и метаданные, которые описывают внутреннюю структуру хранилища (См. раздел Типы доменов хранения):

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

Домены хранения — общие ресурсы, которые должны быть доступны для всех хостов центра данных.

5. Сеть (Network)

Сетевая архитектура zVirt обеспечивает связь между разными элементами среды zVirt. Сетевая архитектура не только поддерживает сетевое подключение, но и позволяет разделять сети.

Рисунок 3. Сетевая архитектура

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

5.1. Уровень сетевой инфраструктуры

В основе сетевой архитектуры zVirt лежат некоторые стандартные аппаратные и программные устройства:

Сетевые карты (NIC) — это физические устройства сетевого интерфейса, через которые хост подключается к сети.
Виртуальные сетевые карты (vNIC) — это логические сетевые карты, которые работают на физических сетевых картах хоста и обеспечивают сетевое подключение виртуальных машин.
Несколько сетевых карт объединяют в единый bond-интерфейс.
Мосты (bridges) — это метод пересылки пакетов в сетях с коммутацией пакетов. Это основа логических сетей виртуальных машин.

5.2. Логические сети

Логические сети позволяют разделять сетевой трафик в зависимости от требований среды. Типы логических сетей:

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

Все логические сети могут быть либо обязательными, либо необязательными.

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

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

zVirt отделяет сетевой трафик, связанный с управлением, от сетевого трафика, связанного с миграцией, что позволяет использовать выделенную сеть (без маршрутизации) для миграции на лету и гарантирует, что сеть управления (ovirtmgmt) не потеряет связь с гипервизорами во время миграции.

5.3. Описание логических сетей на разных уровнях

Логические сети по-разному воздействуют на каждый уровень среды виртуализации.

Уровень центра данных: Логические сети задаются на уровне центра данных. В каждом центре данных по умолчанию есть сеть управления ovirtmgmt. Желательно, но необязательно добавить другие логические сети. Назначить Сеть ВМ (VM Network) и задать пользовательское значение MTU можно на уровне центра данных. Логическую сеть, заданную центру данных, также необходимо добавить в кластеры, которые используют эту логическую сеть.
Уровень кластера: Логические сети предоставляются из центра данных, и их необходимо добавить в кластеры, которые будут их использовать. По умолчанию каждый кластер подключен к сети управления. При желании можно добавить в кластер логические сети, которые были заданы для родительского центра данных кластера. Когда необходимая логическая сеть добавлена в кластер, она должна быть добавлена для каждого хоста в кластере. Дополнительные логические сети можно добавить к хостам по мере необходимости.
Уровень хоста: Логические сети виртуальных машин реализуются для каждого хоста в кластере в виде программного моста, ассоциированного с определенным сетевым интерфейсом. В логических сетях невиртуальных машин нет ассоциированных мостов; они ассоциированы с сетевыми интерфейсами хостов напрямую. На каждом хосте есть сеть управления, реализованная как мост с помощью одного из сетевых устройств, включенного в среду zVirt. Дополнительные необходимые логические сети, добавленные в кластер, следует ассоциировать с сетевыми интерфейсами на каждом хосте, чтобы они заработали с кластером.
Уровень виртуальной машины: Логические сети могут быть доступны для виртуальных машин так же, как сеть может быть доступна для физической машины. Виртуальная машина может подключить свою виртуальную сетевую карту к любой логической сети виртуальной машины, которая была реализована на хосте, на котором она работает. После этого виртуальная машина сможет подключиться к любым другим устройствам или приемникам, доступным в логической сети, к которой она подключена.

Пример 1. Сеть управления (Management Network)

Логическая сеть управления под названием ovirtmgmt создается автоматически при установке Менеджера управления. Сеть ovirtmgmt выделена для трафика управления между Менеджером управления и хостами. Если другие мосты специального назначения не настроены, то ovirtmgmt будет мостом по умолчанию для всего трафика.

6. Центры данных

Центр данных — это высший уровень абстракции в zVirt. В центре данных содержится три вида информации:

Хранилище: Включает типы хранилищ, домены хранилищ и информацию о подключении доменов хранилищ. Хранилище задано для центра данных и доступно всем кластерам в нем. Все хосты в кластерах центра данных имеют доступ к одним и тем же доменам хранения.
Логические сети: Сюда относятся такие данные, как сетевые адреса, теги VLAN и поддержка STP. Можно задать логические сети для центра данных и применить их к кластерам.
Кластеры: Кластеры — это группы хостов с совместимыми ядрами процессоров, будь то процессоры AMD или Intel. Кластеры представляют собой домены миграции; виртуальные машины можно переместить на лету на любой хост в кластере, но не на другие кластеры. В одном центре данных может быть несколько кластеров, а каждый кластер может содержать несколько хостов.

7. Уровни совместимости центров данных и кластеров

У центров данных и кластеров zVirt есть версия совместимости.

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

Версия совместимости кластера описывает возможности zVirt, поддерживаемые всеми хостами в кластере. Совместимость кластера устанавливается в соответствии с версией операционной системы наименее подходящего хоста в кластере.

8. Безопасность

8.1. Шифрование паролей

Для повышения уровня информационной безопасности системные пароли в конфигурационных файлах шифруются с помощью алгоритма AES (Advanced Encryption Standard).

Шифрование паролей применяется к следующим файлам:

/etc/ovirt-engine/engine.conf.d/11-setup-sso.conf
/etc/ovirt-engine/engine.conf.d/10-setup-database.conf
/etc/ovirt-engine/engine.conf.d/10-setup-dwh-database.conf
/etc/ovirt-engine/engine.conf.d/10-setup-pki.conf
/etc/ovirt-engine-dwh/ovirt-engine-dwhd.conf.d/10-setup-grafana-database.conf.
/etc/ovirt-engine/aaa/***.local.properties
/etc/ovirt-engine/engine.conf.d/10-setup-cinderlib-database.conf

8.2. Цифровая подпись пакетов

Для повышения доверия к распространяемому программному обеспечению реализовано подписание файлов с помощью электронной цифровой подписи. В метаданных теперь указывается производитель «Orionsoft».

Для проверки цифровой подписи используйте команду rpm -K <package>.

Пример 2. Проверка цифровой подписи пакетов

rpm -K cockpit-299.fl-1.19278.wip.zvirt.el8.x86_64.rpm (1)
cockpit-299.fl-1.19278.wip.zvirt.el8.x86_64.rpm: digests signatures OK (2)

rpm -K cockpit-310.2-1.fc40.src.rpm (3)
cockpit-310.2-1.fc40.src.rpm: digests SIGNATURES NOT OK (4)

1	- проверка цифровой подписи пакета, скачанного с официального репозитория Orionsoft.
2	- проверка пройдена успешно.
3	- проверка цифровой подписи пакета, скачанного со стороннего репозитория.
4	- проверка не пройдена.

Также можно проверить производителя в метаданных пакетов с помощью rpm -qi <package>.

rpm -qi cockpit-299.fl-1.19278.wip.zvirt.el8.x86_64.rpm (1)

Name        : cockpit
Version     : 299.fl
...
Vendor      : "Orionsoft" (2)
...

rpm -qi cockpit-310.2-1.fc40.src.rpm (3)

warning: cockpit-310.2-1.fc40.src.rpm: Header V4 RSA/SHA256 Signature, key ID a15b79cc: NOKEY (4)
Name        : cockpit
Version     : 310.2
...
Vendor      : Fedora Project (5)
...

1	- проверка метаданных пакета, скачанного с официального репозитория Orionsoft.
2	- вендором данного пакета является Orionsoft.
3	- проверка метаданных пакета, скачанного со стороннего репозитория.
4	- присутствует предупреждение об отсутствии ключа.
5	- вендором данного пакета является Fedora Project.