Хосты

Введение

Хосты, также известные как гипервизоры, — это физические серверы, на которых выполняются гипервизоры РОСА Виртуализация.

Система виртуализации РОСА Виртуализация может поддерживать одновременную работу многих ВМ под управлением ОС Windows или ОС Linux. На машине хоста виртуальные машины выполняются как отдельные процессы и потоки Linux, а управляются эти ВМ удаленно виртуализированным ЦУ. К виртуализированному ЦУ присоединяется один или несколько хостов виртуализации.

На хостах виртуализации включены средства защиты. Система SELinux и межсетевой экран полностью настроены и активированы по умолчанию. "Статус" SELinux на выбранном хосте отображается в разделе "Режим SELinux" вкладки "Общие" подробного просмотра. При добавлении в окружение обычных хостов в виртуализированном ЦУ можно открыть необходимые порты этих хостов.

Общее описание хоста виртуализации

Обычный хост — это физический 64-битный сервер с модулями Intel® VT или AMD-V под управлением гипервизора РОСА Виртуализация.

Физический хост РОСА Виртуализация должен соответствовать следующим техническим характеристикам:

принадлежит только одному кластеру в Системе (см. Кластеры);
имеет ЦП с поддержкой модулей аппаратной виртуализации AMD-V или Intel® VT;
имеет процессор с поддержкой всех функций того типа виртуального ЦП, который был выбран при создании кластера, к которому принадлежит данный хост;
имеет объем ОЗУ минимум 2 ГБ;
обслуживается системным администратором с системными полномочиями (администратор имеет права суперпользователя).

Гипервизоры РОСА Виртуализация

Для наблюдения за ресурсами хоста и выполнения задач администрирования на хостах виртуализации используется веб-интерфейс Cockpit. Прямой доступ к хостам виртуализации с помощью SSH или консоли не поддерживается, поэтому веб-интерфейс Cockpit предоставляет графический интерфейс также и для задач, выполняемых перед тем, как хост будет добавлен в виртуализированный ЦУ, таких как настройка сетевой конфигурации и установка виртуализированного ЦУ (диспетчера виртуализации). Кроме того, во вкладке "Терминал" веб-интерфейса можно выполнять консольные команды.

Доступ к веб-интерфейсу хоста виртуализации

Доступ к веб-интерфейсу Cockpit хоста виртуализации осуществляется в веб-браузере по адресу https://полное_доменное_имя_хоста_или_IP:9090.

Номер порта 9090 — это стандартный номер порта для доступа к веб-интерфейсу Cockpit.

В составе Cockpit также есть панель мониторинга "Виртуализация", где показывается состояние работоспособности хоста, ключ SSH хоста, статус виртуализированного ЦУ, виртуальные машины и их статистика.

Для сбора информации отладки на хостах виртуализации используется инструмент автоматизированных отчетов об ошибках (Automatic Bug Reporting Tool).

Задачи при работе с хостами

Добавление хостов в виртуализированный ЦУ

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

Примечание — Перед добавлением хоста в Систему виртуализации РОСА Виртуализация необходимо осуществить его предварительную настройку, аналогичную настройке хоста при первичной установке Системы виртуализации (см. документ ).

Примечание — Перед добавлением хоста при создании моста управления, использующего статический адрес IPv6, следует отключить управление Network Manager в конфигурационном файле сетевых интерфейсов (ifcfg) данного хоста.

Необходимые условия для добавления нового хоста в инсталляцию РОСА Виртуализация

При добавлении нового хоста в инсталляцию РОСА Виртуализация необходимо добавить на новый хост в конфигурационный файл /etc/hosts информацию обо всех уже имеющихся в Системе виртуализации хостах, СУСВ, сервере IPA (или другом сервере каталогов). В файл /etc/hosts на ранее установленных хостах и в СУСВ добавляется информация о новом хосте.

Процедура добавления хоста в виртуализированный ЦУ включает в себя следующие этапы, описанные в пп. Первичная установка и инициализация хоста‒Добавление хоста в виртуализированный ЦУ:

Первичная установка и инициализация хоста.
Настройка системных параметров хоста гипервизора.
Добавление в файл /etc/hosts на ранее установленных хостах и в СУСВ информации о новом хосте.
Добавление хоста в виртуализированный ЦУ с использованием Портала администрирования.

Первичная установка и инициализация хоста

Установка гипервизора РОСА Виртуализация осуществляется непосредственно на физический сервер без предустановленной ОС.

Процедура установки и первичной инициализации хоста описывается в п. Установка гипервизора на физический .

Настройка системных параметров хоста гипервизора

Настройка параметров системного окружения осуществляется администратором в консоли каждого из хостов с установленным гипервизором.

Доступ к консоли с использованием веб-интерфейса

Для доступа к консоли в веб-интерфейсе хоста нужно перейти на вкладку "Терминал" панели навигации интерфейса соответствующего хоста гипервизора (рисунок 158).

Рисунок 158 ‒ Консоль хоста в веб-интерфейсе

Доступ к консоли с использованием командной строки

Для доступа к консоли хоста можно воспользоваться SSH-соединением.

Для получения доступа к консоли через SSH необходимо использовать имя учетной записи суперпользователя root и пароль, выбранный ранее при установке, а именно выполнить команду в терминале, указав имя хоста (в примере ниже имя хоста host1.rosa.lan следует заменить на имя хоста, развернутого в вашем ЦОД):

ssh root@host1.rosa.lan

Примечание – Команды по настройке хоста, указанные в п. Редактирование файла /etc/hosts с именами хостов, могут выполняться в консоли с доступом через SSH или в терминале, открытом в браузере веб-интерфейсе администрирования хоста

Разрешение имен DNS

При отсутствии в сети сервера DNS можно использовать конфигурационный файл /etc/hosts для настройки разрешения имен DNS в IP-адреса сетевых ресурсов.

Конфигурационный файл /etc/hosts содержит построчный список IP-адресов и соответствующих имен DNS для их преобразования при обращении.

Редактирование файла /etc/hosts с именами хостов

В консоли хоста нужно открыть редактор mc (mcedit) и указать в файле /etc/hosts IP-адреса и имена DNS взаимодействующих компонентов РОСА Виртуализация – хостов с установленными гипервизорами, ВМ СУСВ и сервера IPA.

Для начала редактирования файла /etc/hosts с использованием редактора mcedit нужно выполнить команду в консоли:

mcedit /etc/hosts

После завершения редактирования следует выйти из редактора, сохранив результат. Для выхода из редактора можно использовать клавишу ё. Если в файл были внесены изменения, то будет предложено их сохранить или выйти без сохранения. Для сохранения внесенных изменений при выходе из редактора необходимо выбрать в диалоговом окне "Сохранить при выходе" опцию ё.

Примечания:
Для сохранения результатов редактирования файла в редакторе mcedit следует нажать F2. Для выхода из редактора нажимают F10. При использовании редактора в окне браузера также можно нажать на кнопки F2 и F10, используя курсор мыши и левую клавишу мыши.
Также можно использовать для редактирования любой другой текстовый редактор, например vi. Для редактирования файла с использованием редактора vi нужно выполнить команду:

vi /etc/hosts

Для выхода из редактора vi необходимо использовать команду :q.

Для перехода в режим редактирования в редакторе vi (режим INSERT) можно нажать клавишу Insert. После внесения необходимых изменений следует нажать клавишу Esc, затем ввести команду :x.

Пример файла /etc/hosts c IP-адресами и именами DNS взаимодействующих компонентов РОСА Виртуализация – хостов с установленными гипервизорами, ВМ СУСВ и сервера IPA:

10.10.20.4  susv.rosa.lan       # ВМ СУСВ
10.10.20.6  host1.rosa.lan      # хост гипервизора
10.10.20.7  host2.rosa.lan      # хост гипервизора
10.10.20.8  host3.rosa.lan      # хост гипервизора
10.10.20.9  ipa.rosa.lan        # сервер IPA
10.10.20.10 host4.rosa.lan      # хост гипервизора

Данный пример файла /etc/hosts предполагает, что ранее в РОСА Виртуализация уже были установлены хосты host1 ‒ host3, и сейчас осуществляется добавление нового хоста host4. Файл добавляется на новый хост host4. На ранее установленные хосты и в СУСВ необходимо добавить строку в файл /etc/hosts с указанием IP адреса нового хоста:

10.10.20.10host4.rosa.lan# хост гипервизора

Важно – Эта операция должна быть выполнена на каждом из ранее установленных хостов и в СУСВ.

Важно – При наличии в сетевом окружении сервера DNS соответствующие записи с именами хостов и их IP-адресами должны быть внесены на сервер DNS. При этом добавленные имена хостов должны быть разрешимы на каждом из хостов и в СУСВ.

Примечание – Указание в файле /etc/hosts IP-адресов и имен DNS взаимодействующих компонентов РОСА Виртуализация позволяет обеспечить функционирование системы при недоступном корпоративном DNS сервере.

После завершения настройки системных параметров нового хоста гипервизора можно переходить к его добавлению в виртуализированный ЦУ.

Добавление хоста в виртуализированный ЦУ

Для добавления хоста в виртуализированный ЦУ нужно выполнить следующие действия:

в главном меню Портала администрирования перейти в "Ресурсы → Хосты", и откроется форма с отображением информации о доступных хостах (рисунок 159);

Рисунок 159 ‒ Форма "Ресурсы → Хосты" с отображением информации о доступных хостах

нажать кнопку Добавить для добавления хоста в РОСА Виртуализация, и откроется форма "Новый хост" для определения параметров добавляемого хоста (рисунок 160);

Рисунок 160 ‒ Форма "Новый хост". Вкладка "Общие"

из выпадающего списка выбрать "Дата-центр" и "Хост кластера" для нового хоста. По умолчанию используется дата-центр default и кластер default;
указать "Имя хоста / IP" нового хоста (рисунок 160). В поле "Порт SSH" автоматически добавится стандартный номер порта SSH — 22;
выбрать метод аутентификации, используемый диспетчером виртуализации для подключения к хосту:

при использовании аутентификации по паролю ввести пароль суперпользователя root в поле "Пароль";
при использовании аутентификации по открытому ключу SSH скопировать ключ из поля "Открытый ключ SSH" (рисунок 161) в файл /root/.ssh/authorized_keys на хост, добавляемый в СУСВ;

Рисунок 161 ‒ Ключ из поля "Открытый ключ SSH" необходимо скопировать на хост

опционально нажать на кнопку Дополнительные параметры (рисунок 162), чтобы настроить следующие дополнительные "Параметры хоста":

Рисунок 162 ‒ "Новый хост" — настройка дополнительных параметров

отключить автоматическую настройку межсетевого экрана;
добавить отпечаток SSH хоста для повышения уровня безопасности. Это можно сделать вручную или получить отпечаток автоматически;

опционально настроить "Управление питанием" на вкладке "Управление питанием" (рисунок 163), если у хоста есть поддерживаемая карта управления питанием;

Рисунок 163 ‒ "Новый хост" — вкладка "Управление питанием"

нажать кнопку OK.

Новый хост появится в списке хостов со статусом "Устанавливается", при этом проследить за процессом установки можно в разделе "События" в "Секции уведомлений" (пиктограмма колокольчик).

После некоторого ожидания статус хоста сменится на "Запущен".

Параметры хоста

Общие параметры

Общие параметры хоста применяются во время изменения сведений о хосте под управлением гипервизора РОСА Виртуализация или при добавлении хоста в виртуализированный ЦУ.

В таблице 49 описываются параметры вкладки "Общие" окон "Новый хост" или "Параметры хоста".

Параметры вкладки "Управление питанием"

В таблице 50 описываются параметры вкладки "Управление питанием" (рисунок 163) окон "Новый хост" или "Параметры хоста".

В таблице 51 содержится описание полей в окне "Параметры агента блокады".

Параметр вкладки "SPM"

В таблице 52 описывается параметр вкладки "SPM" окон "Новый хост" или "Параметры хоста" (рисунок 164).

Рисунок 164 ‒ Вкладка "SPM"

Параметры вкладки "Консоль и GPU"

В таблице 53 описываются параметры вкладки "Консоль и GPU" окон "Новый хост" и "Параметры хоста" (рисунок 165).

Рисунок 165 ‒ Вкладка "Консоль и GPU"

Параметр вкладки "Поставщик сети"

В таблице 54 описывается параметр вкладки "Поставщик сети" окон "Новый хост" и "Параметры хоста".

Параметры вкладки "Ядро"

В таблице 55 описываются параметры вкладки "Ядро" (рисунок 166) окон "Новый хост" и "Параметры хоста".

Рисунок 166 ‒ Вкладки "Ядро" (параметры ядра хоста)

Наиболее часто встречающиеся параметры загрузки ядра приводятся в виде флажков для удобства быстрого выбора.

Для более сложного редактирования и добавления любых необходимых дополнительных параметров можно использовать свободное текстовое поле с меткой "Командная строка ядра". При изменении любых консольных параметров необходима переустановка хоста.

Примечание — Перед тем как вносить изменения в параметры хостов, присоединенных к виртуализированному ЦУ, эти хосты необходимо перевести в "режим обслуживания". Затем для применения внесенных изменений эти хосты необходимо переустановить.

Примечания:
В случае если параметры загрузки ядра отображаются серым цветом, следует нажать на кнопку Сбросить. В результате параметры загрузки ядра станут доступны.
В IBM POWER8 функционал IOMMU активирован по умолчанию.

Параметр вкладки "Виртуализированный ЦУ"

В таблице 56 описывается параметр вкладки "Виртуализированный ЦУ" (рисунок 167) окон "Новый хост" и "Параметры хоста".

Рисунок 167 ‒ Вкладка "Виртуализированный ЦУ"

Настройка параметров управления питанием хоста

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

Для настройки параметров управления питанием хоста необходимо:

в главном меню Портала администрирования выбрать "Ресурсы → Хосты" и выбрать хост;
выбрать "Управление → Обслуживание" и нажать кнопку OK для подтверждения;
после перевода хоста в режим обслуживания нажать кнопку Изменить;
перейти на вкладку "Управление питанием";
установить флажок "Включить управление питанием", чтобы активировать соответствующие поля;
установить флажок "Интеграция kdump", чтобы предотвратить проведение операции блокады хоста во время выполнения аварийного дампа ядра;

Примечание — Если параметр "Интеграция kdump" включается или отключается на хосте, этот хост необходимо переустановить для настройки параметров "kdump".

опционально установить флажок "Отключить контроль управления питанием со стороны политики", если "Управление питанием" хоста не должно контролироваться политикой планирования кластера хоста;
для добавления нового устройства управления питанием нажать на кнопку +;
в окне "Параметры агента блокады" указать "Имя пользователя" и "Пароль" для устройства управления питанием;
выбрать "Тип" устройства управления питанием из выпадающего списка;
в поле "Адрес" указать IP-адрес;
указать номер "Порта SSH", используемого устройством управления питанием для связи с хостом;
указать номер "Слота", используемого для идентификации платы устройства управления питанием;
настроить "Параметры" устройства управления питанием в форме списка записей "ключ-значение", разделенных запятыми;

Примечание — В случае использования как адресов IPv4, так и адресов IPv6 (по умолчанию), следует оставить поле "Параметры" пустым. При использовании только адресов IPv4 нужно ввести в поле "Параметры" значение "inet4_only=1", а при использовании только адресов IPv6 ввести в поле "Параметры" значение "inet6_only=1".

установить флажок "Защищенное", чтобы включить защищенное соединение между устройством управления питанием и хостом;
чтобы убедиться в том, что все значения корректны, нажать кнопку Проверка. В случае успешной проверки будет показано сообщение: "Проверка выполнена, статус хоста: запущен";
нажать кнопку OK, чтобы закрыть окно "Параметры агента блокады";
во вкладке "Управление питанием" при необходимости развернуть "Дополнительные параметры" и с помощью кнопок со стрелками ↑ (вверх) и ↓ (вниз) настроить порядок, в котором виртуализированный ЦУ будет выполнять поиск прокси для операции блокады в кластере хоста и в дата-центре;
нажать кнопку OK.

В результате на Портале администрирования появится и станет доступным выпадающее меню "Управление → Управление питанием".

Настройка параметра приоритета SPM хоста

Диспетчер пула хранилища (SPМ) — это роль управления, присваиваемая одному из хостов в дата-центре для контроля доступа к доменам хранилищ. Диспетчер пула хранилища должен быть всегда доступен, и в случае недоступности хоста SPM эта роль будет присвоена другому хосту. Поскольку роль SPM использует некоторые из доступных ресурсов хоста, очень важно отдать приоритет тем хостам, которые могут выделить эти ресурсы.

Параметр приоритета SPM хоста изменяет вероятность присвоения роли SPM хосту (например, хосту с высоким приоритетом роль SPM будет присвоена раньше хоста с низким приоритетом).

Для настройки параметра приоритета SPM нужно выполнить следующие действия:

перейти в "Ресурсы → Хосты";
нажать кнопку Изменить;
перейти на вкладку "SPM" (рисунок 164);
установить флажок в значение "Низкий", "Нормальный" (по умолчанию), "Высокий" для указания необходимого приоритета SPM хоста или в значение "Никогда", чтобы хосту не была присвоена роль SPM;
нажать кнопку OK.

Настройка на хосте сквозного доступа к PCI

В данном разделе описывается, как установить и настроить технологию SR-IOV в РОСА Виртуализация.

Включение технологии сквозного доступа дает возможность виртуальной машине использовать устройство хоста так, как если бы оно было напрямую подключено к ВМ. Чтобы включить функцию сквозного доступа к PCI, необходимо активировать модули виртуализации и функционал IOMMU.

Примечание — Аппаратное обеспечение хоста должно соответствовать требованиям применения сквозного доступа к PCI.

Для подготовки хоста для применения сквозного доступа к PCI необходимо:

включить в BIOS модули виртуализации и IOMMU;
включить флаг "IOMMU" в ядре.

Для этого нужно установить флажок "Сквозной доступ к устройству хоста и SR-IOV" при добавлении хоста в виртуализированный ЦУ или вручную отредактировать конфигурационный файл загрузчика grub (см. следующую процедуру ручной активации IOMMU).

Примечание — IOMMU активирован по умолчанию при использовании аппаратного обеспечения IBM POWER8.

В следующей пошаговой инструкции потребуется перезагрузка хоста. Если хост уже был присоединен к виртуализированному ЦУ, необходимо сначала перевести хост в режим обслуживания.

Для ручной активации IOMMU нужно выполнить следующие действия:

отредактировать конфигурационный файл загрузчика grub:

для Intel® добавить запись "intel_iommu=on" в конец строки GRUB_CMDLINE_LINUX в конфигурационном файле /etc/default/grub:

GRUB_CMDLINE_LINUX="nofb splash=quiet console=tty0 ... intel_iommu=on

для AMD добавить запись "amd_iommu=on" в конец строки GRUB_CMDLINE_LINUX в конфигурационном файле /etc/default/grub:

GRUB_CMDLINE_LINUX="nofb splash=quiet console=tty0 ... amd_iommu=on

Примечание — Вместо записей "intel_iommu=on" или "amd_iommu=on" рекомендуется использовать записи "intel_iommu=pt" или "amd_iommu=pt" соответственно для Intel® или AMD. Параметр "pt" активирует IOMMU только для устройств, используемых в сквозном доступе, что улучшает производительность хоста. Но параметр "pt" может поддерживаться не всеми аппаратными составляющими. Если параметр "pt" не работает на конкретном хосте, следует использовать исходный параметр "on".

если сквозной доступ будет неудачным по причине отсутствия поддержки переназначения прерываний аппаратными составляющими, то в случае доверенных ВМ использовать параметр "allow_unsafe_interrupts". Этот параметр не включается по умолчанию, поскольку его активация потенциально может открыть хост атакам MSI со стороны ВМ. Для активации этого параметра добавить запись "allow_unsafe_interrupts=1" в строку options в конфигурационном файле /etc/modprobe.d:

options vfio_iommu_type1 allow_unsafe_interrupts=1

обновить информацию в файле grub.cfg и перезагрузить хост для применения изменений:

grub2-mkconfig -o /boot/grub2/grub.cfg
reboot

Перевод хоста в режим обслуживания

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

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

Примечание — Виртуальные машины, привязанные к хосту и не подлежащие миграции, выключаются. Для проверки, какие машины привязаны к хосту, следует нажать кнопку Привязано к хосту на вкладке "Виртуальные машины" в подробном просмотре хоста.

Для перевода хоста в режим обслуживания:

перейти в "Ресурсы → Хосты" и выбрать хост;
нажать "Управление → Обслуживание". В результате будет открыто окно "Хосты обслуживания" (рисунок 168);

Рисунок 168 ‒ Перемещение хоста в режим обслуживания

опционально указать "Причину" перемещения хоста в режим обслуживания, которая будет указана в журнале и при повторной активации хоста из режима обслуживания;

Примечание — Поле "Причина" для указания обстоятельств перевода хоста в режим обслуживания появится только в случае, если эта возможность была включена в параметрах кластера (см. п. Общие параметры кластера).

опционально выбрать нужные параметры для хостов с поддержкой Gluster:

выбрать параметр "Игнорировать кворум Gluster и проверки самовосстановления" для избежания проверок по умолчанию. По умолчанию во время перевода хоста в режим обслуживания виртуализированный ЦУ проверяет, не был ли потерян кворум Gluster. Виртуализированный ЦУ также проверяет хост на наличие задач по самовосстановлению, на которые может повлиять перевод хоста в режим обслуживания. Если кворум будет потерян или если выполняются действия по самовосстановлению, которые не должны быть затронуты, виртуализированный ЦУ не разрешит перевести хост в режим обслуживания. Этот параметр используется только в случае, если нет никаких других способов перевести хост в режим обслуживания;
выбрать параметр "Остановить службу Gluster", чтобы остановить выполнение всех служб Gluster во время перевода хоста в режим обслуживания;

Примечание — Указанные параметры появятся в окне "Хосты" обслуживания, только если выбранный хост поддерживает Gluster.

нажать кнопку OK для запуска режима обслуживания.

Статус хоста изменится на значение "Подготовка к обслуживанию", а после успешного окончания подготовки — на значение "Обслуживание". Если хосту была присвоена роль SPM (диспетчер пула хранилища), то роль SPM переходит к другому хосту. Когда хосты находятся в режиме обслуживания, VDSM не прекращает свою работу. Все выполняющиеся ВМ мигрируют на другие хосты.

Примечание — При сбое миграции какой-либо ВМ следует нажать на хосте "Управление → Активировать" для остановки действий по переводу этого хоста в режим обслуживания, а затем на виртуальной машине нажать кнопку Прервать миграцию для остановки миграции.

Активация хоста из режима обслуживания

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

Для активации хоста из режима обслуживания необходимо:

нажать "Ресурсы → Хосты" и выбрать хост;
нажать "Управление → Активировать".

Статус хоста изменится на значение "Не присвоено", а после завершения операции — на значение "Запущен". Теперь на хосте могут выполняться виртуальные машины. ВМ, мигрировавшие с хоста при переводе хоста в режим обслуживания, не возвращаются автоматически, но их можно вернуть вручную. Если до перевода в режим обслуживания хост выполнял роль SPM (диспетчер пула хранилища), эта роль не возвращается автоматически к хосту при активации из режима обслуживания.

Настройка правил межсетевого экрана хоста

С помощью утилиты Ansible можно настроить постоянную конфигурацию правил межсетевого экрана хоста.

Важно — Кластер должен быть настроен на работу с firewalld, а не с устаревшим типом межсетевого экрана iptables.

Для настройки правил межсетевого экрана для хостов нужно выполнить следующие действия:

для добавления частного порта межсетевого экрана отредактировать файл /etc/ovirt-engine/ansible/ovirt-host-deploy-post-tasks.yml.example на машине диспетчера виртуализации следующим образом:

firewalld:
port: "12345/tcp"
permanent: yes
immediate: yes
state: enabled

сохранить файл как /etc/ovirt-engine/ansible/ovirt-host-deploy-post-tasks.yml.

Новые или повторно установленные хосты настраиваются с обновленными правилами межсетевого экрана.

Существующие хосты необходимо переустановить с помощью пунктов меню "Установка → Переустановить" и с выбранным параметром "Автоматически настроить межсетевой экран хоста".

Удаление хоста

Для удаления хоста нужно:

нажать "Ресурсы → Хосты" и выбрать хост;
нажать "Управление → Обслуживание";
после перевода хоста в режим обслуживания нажать кнопку Удалить, чтобы открыть окно подтверждения "Удалить хост(ы)";
если хост является частью кластера хранилища Gluster и на хосте имеются кирпичи тома или если хост не отвечает, установить флажок "Принудительное удаление";
нажать кнопку OK.

Повторная установка хостов

Для повторной установки хостов виртуализации и стандартных хостов необходимо использовать Портал администрирования и учитывать следующие предварительные условия:

Если миграция включена на уровне кластера, ВМ будут автоматически мигрировать на другой хост в кластере. Рекомендуется обновлять ПО на хосте при относительно низкой загруженности хоста.
В кластере должен быть резерв памяти, достаточный для выполнения обслуживания хостов в составе этого кластера. В противном случае миграция ВМ закончится неудачно. Для снижения потребления памяти во время обновления ПО хостов выключить некоторые из ВМ до начала перевода хостов в режим обслуживания.
Перед началом повторной установки следует убедиться, что кластер содержит более одного хоста. Не рекомендуется обновлять ПО на всех хостах одновременно. Один из хостов должен быть доступен для выполнения задач роли SPM (диспетчер пула хранилища).

В следующую последовательность действий для повторной установки включаются остановка и перезапуск хостов:

нажать "Ресурсы → Хосты" и выбрать хост;
нажать "Управление → Обслуживание";
нажать "Установка → Повторная установка", чтобы открыть окно "Установка хоста";
нажать кнопку OK для повторной установки хоста.

После успешной переустановки хост будет иметь статус "Запущен". Все ВМ, мигрировавшие с хоста, теперь смогут вернуться.

Примечание — После успешной регистрации хоста виртуализации в виртуализированном ЦУ и последующей переустановки этот хост может получить ошибочный статус "Сбой установки". В этом случае следует нажать "Управление → Активировать" на Портале администрирования. В результате статус хоста сменится на "Запущен", и хост будет готов к работе.

Индивидуализация хостов с помощью меток

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

Для индивидуальной настройки хостов с помощью меток нужно:

нажать "Ресурсы → Хосты" и выбрать хост;
нажать пиктограмму (три точки) (Больше действий), затем нажать кнопку Назначить теги;
установить флажки для необходимых меток;
нажать кнопку OK.

Просмотр статуса работоспособности хоста

В дополнение к обычному "Статусу" у хостов есть внешний статус работоспособности. Информация о внешнем статусе работоспособности доставляется модулями или внешними системами или же настраивается администратором.

Внешний статус работоспособности отображается слева от имени хоста в виде следующих значков:

OK ‒ без значка;
Информация ‒ "синяя i";
Предупреждение ‒ "желтый восклицательный знак";
Ошибка ‒ "красный крестик";
Сбой ‒ "вилка".

Чтобы узнать дополнительные подробности о работоспособности хоста, следует нажать на имя хоста и перейти на вкладку "События".

Примечание — Внешний статус работоспособности хоста также можно узнать с помощью REST API (элемент "external_status" в запросе GET).

Просмотр устройств хоста

Для просмотра устройств хоста требуется:

нажать "Ресурсы → Хосты";
нажать на имя хоста, чтобы перейти к подробному просмотру;
перейти на вкладку "Устройства хоста".

Во вкладке "Устройства хоста" приводится подробный список устройств хоста, включая информацию о подключении устройства к ВМ и об использовании ВМ в данный момент. Если на хосте можно настроить прямое присвоение устройств, то эти устройства можно напрямую подключить к ВМ для улучшения производительности.

Доступ к веб-интерфейсу Cockpit с Портала администрирования

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

Для доступа к Cockpit с Портала администрирования нужно:

в Портале администрирования нажать "Ресурсы → Хосты" и выбрать хост;
нажать кнопку Консоль хоста.

В результате в новом окне браузера будет открыта страница входа веб-интерфейса Cockpit.

Отказоустойчивость хостов

Высокая доступность хостов

В РОСА Виртуализация хост со статусом "Не отвечает" отличается от хоста со статусом "В нерабочем состоянии". Нерабочие хосты могут обмениваться информацией с диспетчером виртуализации, но имеют некорректную конфигурацию (например, отсутствие локальной сети). Неотвечающие хосты не могут поддерживать связь с диспетчером виртуализации.

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

Примечание — Для автоматической проверки параметров операции блокады рекомендуется настроить следующие параметры engine-config ‒ PMHealthCheckEnabled (по умолчанию ‒ "false") и PMHealthCheckIntervalInSec (по умолчанию ‒ "3600 секунд"). При значении "true" параметр PMHealthCheckEnabled будет проверять всех агентов хоста согласно временному интервалу, указанному параметром PMHealthCheckIntervalInSec, и в случае обнаружения проблемы выдаст предупреждение.

После перезагрузки действия по управлению питанием могут быть выполнены автоматически хостом-прокси или вручную на Портале администрирования. Все ВМ, выполняющиеся на неотвечающих хостах, будут остановлены, а высокодоступные ВМ будут запущены на другом хосте. Для действий по управлению питанием необходимо как минимум два хоста.

Примечание — На хосте, где выполняются высокодоступные ВМ, "Управление питанием" должно быть включено и настроено.

После запуска диспетчера виртуализации и окончания времени молчания (по умолчанию ‒ 5 минут) диспетчер виртуализации автоматически попытается огородить неотвечающие хосты, на которых включено управление питанием.

Примечание — Время молчания можно настроить с помощью параметра DisableFenceAtStartupInSec. Данный параметр engine-config помогает предотвратить ситуации, когда диспетчер виртуализации пытается выполнить операцию блокады для загружающихся хостов. Это может случиться после перебоя в работе дата-центра, так как процесс загрузки хоста занимает больше времени, чем процесс загрузки диспетчера виртуализации.

Управление питанием с помощью прокси

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

Хост-прокси имеет статус "Запущен" или "Обслуживание" и находится в том же кластере или дата-центре, что и огораживаемый хост.

Настройка параметров операции блокады на хосте

Параметры операции блокады настраиваются во вкладке "Управление питанием" окон "Новый хост" или "Параметры хоста". Управление питанием дает возможность Системе огородить проблемный хост, используя такие дополнительные интерфейсы, как карта удаленного доступа RAC.

Все действия по управлению питанием выполняются через хост-прокси, а не напрямую виртуализированным ЦУ. Для действий по управлению питанием необходимо как минимум два хоста.

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

нажать "Ресурсы → Хосты" и выбрать хост;
нажать кнопку Изменить;
перейти на вкладку "Управление питанием" (рисунок 169);

Рисунок 169 ‒ "Управление питанием" хоста

установить флажок "Включить управление питанием", чтобы активировать поля ввода;
установить флажок "Интеграция Kdump", чтобы предотвратить огораживание хоста во время выполнения аварийного дампа ядра;

Примечание — Хост необходимо переустанавливать каждый раз при изменении (активации или деактивации) параметра "Интеграция Kdump".

опционально установить флажок "Отключить контроль управления питанием со стороны политик", если управление питанием хоста не должно контролироваться политикой планирования кластера, в который входит хост;
нажать на кнопку +, чтобы открыть окно "Параметры агента блокады" для добавления нового устройства управления питанием;
указать "Адрес", "Имя пользователя" и "Пароль" **для устройства управления питанием;
из выпадающего списка выбрать "Тип" устройства управления питанием;
указать номер "Порта SSH", используемый устройством управления питанием для связи с хостом;
указать номер "Слота", используемого для идентификации платы устройства управления питанием;
настроить "Параметры" устройства управления питанием в форме списка записей "ключ-значение", разделенных запятыми;
установить флажок "Защищенное", чтобы включить защищенное соединение между устройством управления питанием и хостом;
чтобы убедиться в том, что все значения корректны, нажать кнопку Проверка. В случае успешной проверки будет показано сообщение: "Проверка выполнена, статус хоста: запущен";

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

нажать кнопку OK для закрытия окна "Параметры агента блокады";
опционально во вкладке "Управление питанием" развернуть "Дополнительные параметры" и с помощью кнопок со стрелками ↑ (вверх) и ↓ (вниз) указать порядок, в котором виртуализированный ЦУ будет вести поиск хоста-прокси для операции блокады в кластере или дата-центре;
нажать кнопку OK.

Следует обратить внимание, что "!" (восклицательный знак) рядом с именем хоста исчез, что означает успешную настройку управления питанием хоста.

Служба Kdump и параметры fence_kdump

Для просмотра статуса службы Kdump нужно нажать на имя хоста во вкладке "Общие". Значения статуса службы Kdump:

Включено ‒ Kdump настроен, и служба Kdump выполняется;
Отключено ‒ служба Kdump не выполняется (в этом случае "Интеграция Kdump" не будет работать должным образом);
Неизвестно ‒ данный статус отображается только на хостах с более ранними версиями VDSM, не сообщающими о статусе Kdump.

Включение параметра "Интеграция Kdump" во вкладке "Управление питанием" окон "Новый хост" или "Параметры хоста" создает стандартную конфигурацию агента fence_kdump. Если сетевая конфигурация окружения не слишком сложна, а полное доменное имя диспетчера виртуализации разрешается на всех хостах, то исходных параметров fence_kdump будет достаточно для использования.

При этом существуют случаи, когда бывает необходима продвинутая конфигурация fence_kdump. В окружениях с более сложными сетевыми параметрами может понадобиться вручную настроить виртуализированный ЦУ и/или слушатель fence_kdump.

Например, если полное доменное имя виртуализированного ЦУ разрешается не на всех хостах с активированной "Интеграцией Kdump", то настроить правильное имя хоста или адрес IP можно с помощью engine-config:

engine-config -s FenceKdumpDestinationAddress=A.B.C.D

Другие примеры случаев, когда также могут понадобиться изменения конфигурации:

Виртуализированный ЦУ с двумя сетевыми картами, одна из которых общедоступна, а вторая предназначена для сообщений fence_kdump.
Необходимость запуска слушателя fence_kdump по-другому IP-адресу или на другом порту.
Необходимость настройки частного интервала для уведомлений fence_kdump в целях предотвращения возможных потерь пакетов.

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

Для настройки слушателя fence_kdump необходимо:

создать новый файл (например, my-fence-kdump.conf) в каталоге /etc/ovirt-engine/ovirt-fence-kdump-listener.conf.d/;
указать частные параметры согласно синтаксису "ПАРАМЕТР=значение" и сохранить файл;

Примечание — Измененные значения параметров также должны быть согласованы с параметрами engine-config, приведенными в Настройка Kdump с помощью engine-config.

перезапустить слушатель fence_kdump:

systemctl restart ovirt-fence-kdump-listener.service

В таблице 57 описываются параметры настройки слушателя fence_kdump.

Настройка Kdump с помощью engine-config

Для просмотра текущих параметров Kdump необходимо выполнить следующую команду:

engine-config -g ПАРАМЕТР

Для настройки Kdump с помощью engine-config нужно выполнить следующие действия:

отредактировать конфигурацию Kdump согласно синтаксису "ПАРАМЕТР=значение":

engine-config -s ПАРАМЕТР=значение

Важно — Измененные значения параметров также должны быть согласованы с параметрами настройки слушателя fence_kdump, приведенными в таблица 57.

перезапустить службу ovirt-engine:

systemctl restart ovirt-engine.service

переустановить все хосты, а также при необходимости активировать параметр "Интеграция Kdump".

В таблице 58 описываются параметры конфигурации Kdump.

Мягкая блокада хостов

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

Мягкая блокада (огораживание) с использованием SSH — это процесс, во время которого диспетчер виртуализации пытается перезапустить VDSM на неотвечающем хосте с помощью протокола SSH. В случае неудачи ответственность за проведение операции блокады падает на внешнего агента огораживания, если ранее агент был настроен.

Мягкое огораживание с помощью SSH выполняется следующим образом: на хосте должна быть настроена и включена возможность проведения операции блокады, а также должен существовать действительный хост-прокси (второй хост, имеющий статус "Запущен" в том же дата-центре). По истечении времени ожидания подключения между диспетчером виртуализации и хостом происходит следующее:

при первом сбое сети статус хоста меняется на "Идет подключение";
диспетчер виртуализации выполняет три попытки запросить у VDSM его статус или ждет в течение временнòго интервала, определенного загрузкой хоста. Формула определения этого интервала настраивается с помощью значений TimeoutToResetVdsInSeconds (по умолчанию 60 сек.) + DelayResetPerVmInSeconds (по умолчанию 0.5 сек.) х (число выполняющихся на хосте ВМ) + DelayResetForSpmInSeconds (по умолчанию 20 сек.) x 1 (если хост выполняет роль SPM) или 0 (если хост не выполняет роль SPM). Чтобы дать VDSM максимальное время на ответ, диспетчер виртуализации выбирает наибольший из двух вышеупомянутых параметров (три попытки определить статус VDSM или интервал, рассчитанный по приведенной формуле);
если по истечении интервала хост по-прежнему не отвечает, выполняется команда vdsm restart с использованием протокола SSH;
если команда vdsm restart не сможет восстановить соединение между хостом и диспетчером виртуализации, то статус хоста меняется на "Не отвечает", и, если было настроено управление питанием, выполнение операции блокады передается внешнему агенту.

Примечание — Мягкое огораживание с помощью SSH может выполняться для хостов без настроенного управления питанием. Эта операция отличается от обычного огораживания, которое может выполняться только для хостов с настроенным управлением питанием.

Использование возможностей хоста по управлению питанием

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

Для использования возможностей хоста по управлению питанием нужно выполнить следующие действия:

нажать "Ресурсы → Хосты" и выбрать хост.
Из выпадающего меню "Управление питанием" выбрать одну из следующих возможностей:

Перезапустить ‒ параметр останавливает работу хоста, пока статус хоста не сменится на "Не запущен". После того как агент удостоверился в том, что хост не запущен, высокодоступные ВМ перезапускаются на другом хосте в кластере. Затем агент перезапускает хост и статус готового к использованию хоста изменяется на "Запущен".
Запустить ‒ параметр запускает хост и дает ему присоединиться к кластеру. "Статус" готового к использованию хоста изменяется на "Запущен".
Остановить ‒ параметр выключает питание хоста. Перед тем как использовать этот параметр, убедиться в том, что ВМ, выполняющиеся на хосте, уже мигрировали на другие хосты в кластере. В противном случае произойдет аварийное прерывание работы этих ВМ, и на другом хосте будут перезапущены только высокодоступные ВМ. После остановки хоста статус изменяется на "В нерабочем состоянии".

нажать кнопку OK.

Примечание — Если "Управление питанием" не включено, для перезапуска или остановки работы хоста сначала выбрать необходимый хост, затем из выпадающего меню "Управление" выбрать один из следующих пунктов: "Управление SSH", "Перезапустить" или "Остановить".

Если на хосте было настроено два агента блокады, их можно использовать по очереди или параллельно. В случае параллельных агентов для остановки хоста нужно, чтобы оба агента ответили на команду "Остановить"; а когда один из агентов ответит на команду "Запустить", хост начнет работу. В случае последовательных агентов для остановки или запуска хоста сначала используется первичный агент, а в случае его сбоя используется вторичный агент.

Ручное изолирование не отвечающего хоста

В случае если хост внезапно перестает отвечать (например, по причине аппаратного сбоя), то это может значительно повлиять на производительность окружения. При этом в случае отсутствия устройства управления питанием или в случае некорректной настройки такого устройства хост можно перезапустить вручную.

Важно — параметр "Подтвердить", что хост был перезагружен" следует использовать только в случае, если хост был перезагружен вручную. Использование этого параметра во время работы хоста может привести к повреждению образа ВМ.

Для ручного изолирования не отвечающего хоста необходимо:

нажать "Ресурсы → Хосты" и убедиться в том, что хост действительно имеет статус "Не отвечает";
перезагрузить хост вручную (например, осуществить физическое взаимодействие с оборудованием непосредственно в серверной);
выбрать хост, нажать пиктограмму (три точки) (Больше действий) и далее кнопку Подтвердить, что хост был перезагружен;
установить флажок "Одобрить действие" и нажать кнопку OK;
если перезагрузка хоста занимает много времени, настроить параметр ServerRebootTimeout и указать, сколько секунд должно длиться ожидание перед тем, как хост получит статус "Не отвечает":

engine-config --set ServerRebootTimeout=целое_число