Управление средой
1. Управление hosted engine
1.1. Обслуживание hosted engine
1.1.1. Описание режимов обслуживания hosted engine
Режимы обслуживания позволяют запускать, останавливать и модифицировать виртуальную машину с Менеджером управления без вмешательства со стороны агентов с признаком высокой доступности, а также перезапускать и модифицировать узлы с ролью hosted engine
в среде, не мешая работе Менеджера управления.
Существуют три режима обслуживания:
-
глобальный (global) – всем агентам с признаком высокой доступности в кластере запрещено вести мониторинг состояния виртуальной машины с Менеджером управления. Глобальный режим обслуживания должен применяться для любых операций настройки или обновления, требующих остановки службы ovirt-engine, таких как обновление до более новой версии zVirt.
-
локальный (local) – агенту с признаком высокой доступности на узле, выдающем команду, запрещено вести мониторинг состояния виртуальной машины с Менеджером управления. В локальном режиме обслуживания этот узел освобождается от размещения виртуальной машины с Менеджером управления; если же виртуальная машина с Менеджером управления размещалась на нем на момент перевода в этот режим, то Менеджер управления будет перенесен на другой узел при условии, что один из узлов доступен. Локальный режим обслуживания рекомендуется при применении системных изменений или обновлений к узлу с ролью hosted engine
. -
не назначен (none) – отключает режим обслуживания, обеспечивая работоспособность агентов с признаком высокой доступности.
1.1.2. Установка локального режима обслуживания
Включение локального режима обслуживания останавливает агент с признаком высокой доступности на одном узле с ролью hosted engine
.
Установка локального режима обслуживания из Портала администрирования:
-
Переведите узел с ролью hosted engine
в локальный режим обслуживания:-
На Портале администрирования нажмите и выберите узел с ролью hosted engine
. -
Нажмите и OK. Для этого узла автоматически инициируется локальный режим обслуживания.
-
-
После выполнения всех задач обслуживания выключите режим обслуживания:
-
На Портале администрирования нажмите и выберите узел с ролью hosted engine
. -
Нажмите .
-
Установка локального режима обслуживания из командной строки:
-
Авторизуйтесь на узле с ролью hosted engine
и переведите его в локальный режим обслуживания:# hosted-engine --set-maintenance --mode=local -
После выполнения всех задач обслуживания выключите режим обслуживания:
# hosted-engine --set-maintenance --mode=none
1.1.3. Установка глобального режима обслуживания
Включение глобального режима обслуживания останавливает агенты с признаком высокой доступности на всех узлах с ролью hosted engine
в кластере.
Установка глобального режима обслуживания из Портала администрирования:
-
Переведите все узлы с ролью hosted engine
в глобальный режим обслуживания:-
На Портале администрирования нажмите и выберите любой узел с ролью hosted engine
. -
Нажмите Дополнительные действия (More Actions)
, затем нажмите Включить глобальное обслуживание высокой доступности (Enable Global HA Maintenance).
-
-
После выполнения всех задач обслуживания выключите режим обслуживания:
-
На Портале администрирования нажмите и выберите любой узел с ролью hosted engine
. -
Нажмите Дополнительные действия (More Actions)
, затем нажмите Отключить глобальное обслуживание высокой доступности (Disable Global HA Maintenance).
-
Установка глобального режима обслуживания из командной строки:
-
Авторизуйтесь на узле с ролью hosted engine
и переведите его в глобальный режим обслуживания:# hosted-engine --set-maintenance --mode=global -
После выполнения всех задач обслуживания выключите режим обслуживания:
# hosted-engine --set-maintenance --mode=none
1.2. Управление виртуальной машиной с Менеджером управления
Утилита hosted-engine предлагает много команд, помогающих управлять виртуальной машиной с Менеджером управления. Запустить hosted-engine можно на любом узле с ролью hosted engine
. Чтобы увидеть все доступные команды, выполните hosted-engine --help. Чтобы увидеть дополнительную информацию по конкретной команде, выполните hosted-engine --command --help.
1.2.1. Обновление конфигурации hosted engine
Чтобы обновить конфигурацию hosted engine, воспользуйтесь командой hosted-engine --set-shared-config. Эта команда обновляет конфигурацию hosted engine в общем домене хранения после первоначального развертывания.
Чтобы просмотреть текущие значения параметров конфигурации, воспользуйтесь командой hosted-engine --get-shared-config.
Чтобы просмотреть список всех доступных ключей конфигурации и соответствующих им типов, введите следующую команду:
# hosted-engine --set-shared-config _key_ --type=_type_ --help
где type может принимать одно из следующих значений:
| Значение | Описание |
|---|---|
|
Устанавливает значения в локальном экземпляре /etc/ovirt-hosted-engine/hosted-engine.conf на локальном хосте, поэтому только этот хост использует новые значения. Чтобы применить новое значение, перезапустите службы ovirt-ha-agent и ovirt-ha-broker. |
|
Устанавливает значения в /etc/ovirt-hosted-engine/hosted-engine.conf на общем хранилище, поэтому все хосты, развернутые после изменения конфигурации, используют эти значения. Чтобы применить новое значение на хосте, повторно разверните хост. |
|
Устанавливает значения в /var/lib/ovirt-hosted-engine-ha/ha.conf на локальном хранилище. Новые настройки вступают в силу немедленно. |
|
Устанавливает значения в /var/lib/ovirt-hosted-engine-ha/broker.conf на локальном хранилище. Чтобы применить новые настройки, перезапустите службу ovirt-ha-broker. |
1.2.2. Настройка уведомлений по электронной почте
Можно настроить уведомления по электронной почте с помощью SMTP для любых изменений состояния высокой доступности на узлах с ролью hosted engine
. Обновляемые ключи: email.smtp-server, email.smtp-port, email.source-email, email.destination-emails и notify.state_transition.
Чтобы настроить уведомления по электронной почте:
-
На узле с ролью hosted engine
установите ключ smtp-serverв значение, соответствующее желаемому адресу SMTP-сервера:# hosted-engine --set-shared-config email.smtp-server __smtp.example.com__ --type=brokerЧтобы убедиться, что файл конфигурации hosted engine был обновлен, выполните:
# hosted-engine --get-shared-config email.smtp-server --type=broker broker : smtp.example.com, type : broker -
Убедитесь, что SMTP-порт по умолчанию (порт 25) настроен:
# hosted-engine --get-shared-config email.smtp-port --type=broker broker : 25, type : broker -
Укажите адрес электронной почты, который SMTP-сервер должен использовать для отправки уведомлений. Указать можно только один адрес.
# hosted-engine --set-shared-config email.source-email _source@example.com_ --type=broker -
Укажите адрес электронной почты для получения уведомлений. Можно указать несколько адресов через запятую.
# hosted-engine --set-shared-config email.destination-emails _destination1@example.com_,_destination2@example.com_ --type=broker
Чтобы убедиться в правильной настройке SMTP для среды hosted engine, измените состояние высокой доступности на узле с ролью hosted engine
и проверьте, были ли отправлены уведомления по электронной почте. Например, можно изменить состояние высокой доступности, переведя агенты с признаком высокой доступности в режим обслуживания. Дополнительную информацию см. в разделе Обслуживание hosted engine.
1.3. Настройка слотов памяти, резервируемых для hosted engine на дополнительных хостах
Если виртуальная машина с Менеджером управления выключается или ее нужно перенести, то узел с ролью hosted engine
должен иметь достаточно памяти, чтобы виртуальная машина с Менеджером управления смогла перезапуститься на нем или чтобы ее можно было перенести на него. Эту память можно зарезервировать на нескольких узлах с ролью hosted engine
с помощью политики планирования. Прежде чем запускать или переносить какие-либо виртуальные машины, политика планирования проверяет, достаточно ли памяти для запуска виртуальной машины с Менеджером управления останется на указанном количестве дополнительных узлов с ролью hosted engine
. Дополнительную информацию по политикам планирования см. в разделе Создание политики планирования.
Чтобы добавить дополнительные узлы с ролью hosted engine
в Менеджер управления, см. раздел Добавление узлов с ролью hosted engine в Менеджер управления.
Настройка слотов памяти, резервируемых для hosted engine на дополнительных хостах:
-
Нажмите и выберите кластер, содержащий узлы с ролью hosted engine
. -
Нажмите Изменить (Edit).
-
Откройте вкладку Политика планирования (Scheduling Policy).
-
Нажмите
и выберите HeSparesCount. -
Введите количество дополнительных узлов с ролью hosted engine
, которые будут резервировать достаточно свободной оперативной памяти для запуска виртуальной машины c Менеджером управления. -
Нажмите OK.
1.4. Добавление узлов с ролью hosted engine в Менеджер управления
Узлы с ролью hosted engine
добавляются так же, как и стандартные хосты, но с дополнительным шагом – развертыванием хоста в качестве узла с ролью hosted engine
. Общий домен хранения определяется автоматически, и при необходимости узел можно использовать в качестве хоста для аварийного переключения, чтобы разместить на нем виртуальную машину с Менеджером управления. К среде hosted engine можно подключать и стандартные хосты, но на них не может размещаться виртуальная машина с Менеджером управления. Чтобы обеспечить высокую доступность виртуальной машины с Менеджером управления, необходимо иметь как минимум два узла с ролью hosted engine
. Добавлять хосты можно и с помощью REST API.
-
Все узлы с ролью hosted engine
должны находиться в одном кластере. -
Если вы повторно используете узел с ролью hosted engine
, удалите его имеющуюся конфигурацию hosted engine. См. раздел Удаление хоста из среды hosted engine.
-
На Портале администрирования нажмите .
-
Нажмите Новый (New).
Информацию о дополнительных настройках хоста см. в разделе Описание настроек и средств управления в окнах "Новый хост" и "Изменить хост".
-
В выпадающем списке выберите Центр данных (Data Center) и Хост кластера (Host Cluster) для нового хоста.
-
Введите имя и адрес нового хоста в поля Имя (Name) и FQDN/IP. В поле порт SSH (SSH Port) автоматически подставляется порт 22 – стандартный номер SSH-порта.
-
Выберите метод аутентификации, который будет использоваться для доступа Менеджера управления к хосту.
-
Укажите пароль root-пользователя, чтобы использовать аутентификацию по паролю.
-
Либо скопируйте ключ, отображаемый в поле Публичный ключ SSH (SSH PublicKey), в /root/.ssh/authorized_keys на хосте, чтобы использовать аутентификацию по открытому ключу.
-
-
При желании настройте управление питанием, если у хоста есть поддерживаемая карта управления питанием. Информацию о конфигурации управления питанием см. в разделе Описание настроек управления питанием хоста.
-
Откройте вкладку Hosted Engine.
-
Выберите ДА в выпадающем списке.
-
Нажмите OK.
1.5. Переустановка существующего хоста в качестве узла с ролью hosted engine
Существующий стандартный хост в среде hosted engine можно преобразовать в узел с ролью hosted engine
, на котором может размещаться виртуальная машина с Менеджером управления.
| Настоятельно рекомендуется при установке или переустановке операционной системы хоста сначала отключить все подключенные к хосту существующие хранилища, не относящиеся к ОС, чтобы избежать случайной инициализации их дисков и потенциальной потери данных. |
-
Нажмите и выберите хост.
-
Нажмите и OK.
-
Нажмите Настройки → Переустановить (Reinstall).
-
Откройте вкладку Hosted Engine и в выпадающем списке выберите Развернуть (DEPLOY).
-
Нажмите OK.
Хост переустанавливается с конфигурацией hosted engine и помечается значком
на Портале администрирования.
1.6. Загрузка виртуальной машины с Менеджером управления в режиме восстановления
В этом разделе описано, как загрузить виртуальную машину с Менеджером управления в режиме восстановления, если она не запускается.
-
Подключитесь к одному из узлов с ролью hosted engine
:$ ssh root@__host_address__ -
Переведите hosted engine в глобальный режим обслуживания:
# hosted-engine --set-maintenance --mode=global -
Проверьте, имеется ли уже запущенный экземпляр виртуальной машины с Менеджером управления:
# hosted-engine --vm-statusЕсли экземпляр виртуальной машины с Менеджером управления уже работает, подключитесь к его хосту:
# ssh root@__host_address__ -
Выключите виртуальную машину:
# hosted-engine --vm-shutdownЕсли виртуальная машина не выключается, выполните следующую команду:
# hosted-engine --vm-poweroff -
Запустите виртуальную машину с Менеджером управления в режиме паузы:
#hosted-engine --vm-start-paused -
Задайте временный пароль VNC:
#hosted-engine --add-console-passwordЭта команда выводит информацию, необходимую для авторизации на виртуальной машине с Менеджером управления с помощью VNC.
-
Авторизуйтесь на виртуальной машине с Менеджером управления с помощью VNC. Виртуальная машина с Менеджером управления по-прежнему в режиме паузы, поэтому кажется, что она зависла.
-
Возобновите работу виртуальной машины с Менеджером управления с помощью следующей команды на ее хосте:
После выполнения следующей команды появится меню загрузчика. Нужно войти в режим восстановления до того, как загрузчик продолжит нормальный процесс загрузки. Прежде чем продолжить выполнение этой команды, прочтите информацию о следующем шаге входа в режим восстановления. # /usr/bin/virsh -c qemu:///system?authfile=/etc/ovirt-hosted-engine/virsh_auth.conf resume HostedEngine -
Загрузите виртуальную машину с Менеджером управления в режиме восстановления.
-
Отключите глобальный режим обслуживания
# hosted-engine --set-maintenance --mode=none
Теперь можно запускать задачи восстановления на виртуальной машине с Менеджером управления.
1.7. Удаление хоста из среды hosted engine
Чтобы удалить узел с ролью hosted engine
из среды, переведите узел в режим обслуживания, деинсталлируйте узел и при желании удалите его. Этим узлом можно управлять как обычным хостом после того, как службы с признаком высокой доступности были остановлены, а файлы конфигурации hosted engine были удалены.
Удаление хоста из среды hosted engine:
-
На Портале администрирования нажмите и выберите узел с ролью hosted engine
. -
Нажмите и OK.
-
Нажмите Настройки → Переустановить (Reinstall).
-
Откройте вкладку Hosted Engine и в выпадающем списке выберите Отменить развертывание (UNDEPLOY). Это действие останавливает службы ovirt-ha-agent и ovirt-ha-broker и удаляет файл конфигурации hosted engine.
-
Нажмите OK.
-
При желании нажмите Удалить (Remove). Откроется окно подтверждения Удалить хост(ы) (Remove Host(s)).
-
Нажмите OK.
1.8. Изменение FQDN Менеджера управления в hosted engine
Можно использовать команду ovirt-engine-rename для обновления записей FQDN Менеджера управления.
Подробную информацию см. в разделе Переименование Менеджера управления с помощью инструмента oVirt Engine Rename.
2. Резервные копии и миграция
2.1. Резервное копирование и восстановление Менеджера управления
2.1.1. Общая информация о резервном копировании Менеджера управления
Используйте инструмент engine-backup для регулярного резервного копирования Менеджера управления. Инструмент создает резервную копию базы данных и файлов конфигурации engine в виде одного файла, и его можно запускать, не прерывая работу службы ovirt-engine.
Существует несколько вариантов развёртывания менеджера управления:
-
Развертывание менеджера управления в режиме Hosted Engine.
-
Развертывание менеджера управления в режиме Standalone.
-
Развертывание менеджера управления в режиме Standalone (all-in-one).
В подразделах ниже рассмотрены процедуры резервного копирования в каждом из способов развёртывания.
2.1.2. Синтаксис команды резервного копирования engine (engine-backup)
Команда engine-backup выполняется в одном из трёх стандартных режимов:
# engine-backup --mode=backup
# engine-backup --mode=restore
# engine-backup --mode=verify
Режимы можно расширить набором параметров, уточняющих объем резервного копирования и различных учетных данных для базы данных engine. Команда engine-backup --help откроет полный список параметров и их функций.
| Параметр | Описание |
|---|---|
|
Определяет, будет ли команда выполнять операцию резервного копирования, восстановления или проверки резервной копии. Доступны три варианта: резервное копирование ( |
|
Указывает путь и имя файла, в который будут делаться резервные копии в режиме резервного копирования, и путь и имя файла, из которого будут считываться данные резервной копии в режиме восстановления или проверки. Это обязательный параметр. |
|
Указывает путь и имя файла, в который будут записываться журналы операций резервного копирования или восстановления. Этот параметр обязателен в режимах резервного копирования и восстановления. |
|
Определяет охват операции резервного копирования или восстановления. По умолчанию используется значение |
| Значение | Описание |
|---|---|
|
Полная резервная копия всех баз данных и файлов конфигурации Менеджера управления |
|
Резервная копия только файлов в системе |
|
Резервная копия только базы данных Менеджера управления |
|
Резервная копия только базы данных Хранилища (DWH) |
|
Резервная копия только базы данных Cinderlib |
|
Резервная копия только базы данных Grafana |
Параметр --scope можно прописать несколько раз в одной команде engine-backup.
Следующие параметры доступны только для команды engine-backup в режиме восстановления (restore). Синтаксис приведенных ниже параметров применяется к восстановлению базы данных Менеджера управления. Аналогичные параметры предусмотрены для восстановления базы данных Хранилища (DWH). См. синтаксис параметров для Хранилища (DWH) с помощью команды engine-backup --help.
| Параметр | Описание |
|---|---|
|
Создает базу данных PostgreSQL, куда будет выполнено восстановление из резервной копии базы данных Менеджера управления. Это обязательный параметр при восстановлении из резервной копии на удаленном хосте или новой установке, в которой еще не сконфигурирована база данных PostgreSQL. |
|
Позволяет указать другие учетные данные, чтобы восстановление базы данных Менеджера управления можно было выполнить с использованием учетных данных, отличных от тех, что хранятся в самой резервной копии. См. дополнительные параметры, необходимые для этого параметра, с помощью команды |
или
|
Восстанавливает (или не восстанавливает) разрешения пользователей базы данных. Один из этих параметров обязателен при восстановлении резервной копии. |
Если в резервной копии содержатся разрешения для дополнительных пользователей базы данных, то восстановление резервной копии с параметрами --restore-permissions и --provision-db (или --provision-dwh-db) приведет к созданию дополнительных пользователей со случайными паролями. Необходимо обязательно изменить эти пароли вручную, если дополнительным пользователям нужен доступ к восстановленной системе.
|
2.1.3. Резервное копирование и восстановление менеджера управления развёрнутого в режиме Hosted Engine.
- Исходные данные
-
-
Первый центр данных. Имя -
Default.-
Имя кластера - Default. В кластере два хоста:
host1.contoso.comиhost2.contoso.com. -
Имя домена хранения -
hosted_storage. ТипiSCSI. В домене размещена ВМ - менеджер управления. -
Имя домена хранения -
storage_nfs. ТипNFS. В нём размещены диски ВМ. -
На двух хостах добавлены обязательные сети
VLAN 100, 101.
-
-
Второй центр данных. Имя -
DataCenter2.-
Имя кластера -
Cluster2. В кластере один хост:host3.contoso.com. -
Имя домена хранения -
storage-nfs-datacenter2. ТипNFS. -
На хост добавлена обязательная сеть
VLAN 102.
-
Адрес менеджера управления -
https://manager.contoso.com/ovirt-engine/ -
2.1.3.1. Процедура резервного копирования
Рекомендуется регулярно выполнять процедуру резервного копирования базы данных менеджера управления. Процедура рекомендуется выполняться в нерабочее время.
- Рекомендуемый способ резервного копирования
-
-
Подключитесь по SSH к хосту, на котором в текущий момент работает ВМ
HostedEngine. -
Включите режим глобального обслуживания:
hosted-engine --set-maintenance --mode=global -
Проверьте, что режим глобального обслуживания включен:
hosted-engine --vm-statusв выводе команды должно быть:
!! Cluster is in GLOBAL MAINTENANCE mode !!: -
Подключитесь по SSH к ВМ HostedEngine.
-
Остановите сервис
ovirt-engine:systemctl stop ovirt-engine.service -
Cоздайте эталонную резервную копию базы данных менеджера управления:
engine-backup --scope=all --mode=backup --file=firstbackup.bck --log=firstbackup.log -
Сохраните полученные файлы в хранилище вне среды виртуализации.
-
Создайте ещё одну резервную копию базы данных менеджера управления:
engine-backup --scope=all --mode=backup --file=backup.bck --log=backuplog.log -
Сохраните полученные файлы в хранилище вне среды виртуализации.
-
Запустите сервис
ovirt-engine:systemctl start ovirt-engine.service -
Подключитесь по SSH к хосту, на котором в текущий момент работает ВМ HostedEngine.
-
Выйдите из режима глобального обслуживания
hosted-engine --set-maintenance --mode=none -
Проверьте, что режим глобального обслуживания выключен:
hosted-engine --vm-statusВ выводе не будет сообщения:
!! Cluster is in GLOBAL MAINTENANCE mode !!
-
2.1.3.2. Процедура восстановления
При сбое в работе менеджера управления может быть принято решение о восстановлении. Восстановление может происходить в нескольких вариантах:
-
Из резервной копии на хост, ранее находившийся в кластере.
-
Из резервной копии на вновь созданный (чистый хост).
-
Из резервной копии на новый хост, ранее не находившийся в кластере. При этом исходное master-хранилище (с менеджером управления) недоступно.
-
Из резервной копии до предыдущего состояния.
Для восстановления, необходимы соблюсти ряд условий:
-
Исходные домены хранения должны быть доступны.
-
Режим
multipathдолжен быть настроен. Рекомендуемые настройки для multipath. -
Произведена настройка фильтра LVM по инструкции.
-
Произведена настройка IP адресов, маски подсети, DNS.
-
Выделено не менее 60 ГБ свободного пространства на диске.
Восстановление работы менеджера управления из резервной копии на хост, ранее находившийся в кластере
Перед развертыванием необходимо подготовить новое (чистое) хранилище для менеджера управления. Так же, необходимо соблюсти условия, описанные в [инструкции](#requirements).
-
Подключитесь на хост ранее находившихся в кластере и подготовленный для размещения ВМ HostedEngine (в данном кластере ранее был расположен менеджер управления) и командой
hosted-engine --vm-statusпроверьте, на каком из хостов запущен (находится в аварийном режиме) менеджер управления. -
Подключитесь по SSH к этому хосту.
-
Включите режим глобального обслуживания и отключите менеджер управления:
hosted-engine --set-maintenance --mode=global hosted-engine --vm-shutdown -
Проверьте, что режим глобального обслуживания включен:
hosted-engine --vm-statusв выводе команды должно быть:
!! Cluster is in GLOBAL MAINTENANCE mode !! -
Проверьте командой
dnf update, что репозиторий zVirt включен и доступен. -
Выполните установку пакета
ovirt-engine-applianceиз репозитория:dnf install -y ovirt-engine-appliance -
Скопируйте резервную копию
backup.bck, созданную ранее, на хост. -
Перейдите в директорию с резервной копией и начните процедуру развертывания:
hosted-engine --deploy --restore-from-file=backup.bckВ процессе развертывания будет задан ряд вопросов, отвечайте на них в соответствии с предпочтениями, но на вопросы указанные ниже необходимо ответить следующим образом:
[ INFO ] Stage: Environment setup During customization use CTRL-D to abort. Continuing will configure this host for serving as hypervisor and will create a local VM with a running engine. The provided engine backup file will be restored there, it's strongly recommended to run this tool on an host that wasn't part of the environment going to be restored. If a reference to this host is already contained in the backup file, it will be filtered out at restore time. The locally running engine will be used to configure a new storage domain and create a VM there. At the end the disk of the local VM will be moved to the shared storage. The old hosted-engine storage domain will be renamed, after checking that everything is correctly working you can manually remove it. Other hosted-engine hosts have to be reinstalled from the engine to update their hosted-engine configuration. Are you sure you want to continue? (Yes, No)[Yes]: - выбрать Yes;[ INFO ] skipping: [localhost] Renew engine CA on restore if needed? Please notice that if you choose Yes, all hosts will have to be later manually reinstalled from the engine. Renew CA if needed? (Yes, No)[No]: - выбрать Yes;[ INFO ] skipping: [localhost] Pause the execution after adding this host to the engine? You will be able to connect to the restored engine in order to manually review and remediate its configuration. This is normally not required when restoring an up to date and coherent backup. Pause after adding the host? (Yes, No)[No]: на данном этапе необходимо выбрать ответ исходя из конфигурации среды виртуализации. Если на хосте необходимо произвести дополнительные настройки (например, добавить неосновные сети VLAN) выберите - Yes, если в этом нет необходимости выберите - No.Если на предыдущем шаге
Pause after adding the host?был выбран вариант ответаYes, то скрипт остановит свою работу. Будет предложено подключиться к менеджеру управления по временной ссылке. В примере это адресhttps://host2.contoso.com:6900/ovirt-engine/к которому можно подключиться и произвести необходимые настройки, например добавить обязательные сети VLAN.[ INFO ] You can now connect to https://host2.contoso.com:6900/ovirt-engine/ and check the status of this host and eventually remediate it, please continue only when the host is listed as 'up' [ INFO ] TASK [ovirt.ovirt.hosted_engine_setup : include_tasks] [ INFO ] ok: [localhost] [ INFO ] TASK [ovirt.ovirt.hosted_engine_setup : Create temporary lock file] [ INFO ] changed: [localhost -> localhost] [ INFO ] TASK [ovirt.ovirt.hosted_engine_setup : Pause execution until /tmp/ansible.6kktq7yy_he_setup_lock is removed, delete it once ready to proceed]После выполнения настроек, необходимо удалить временный файл /tmp/ansible.6kktq7yy_he_setup_lock, будет продолжена работа мастера. После успешного завершения работы мастера можно подключиться по исходному FQDN менеджера управления.
Восстановление работы менеджера управления из резервной копии на новый хост, ранее не находившийся в кластере.
Перед развертыванием необходимо:
-
Соблюсти условия, описанные в инструкции.
-
Все исходные хранилища должны быть доступны (в случае недоступности хранилищ будет ошибка
Cannot access the Storage Domain attached to the DataCenter). -
Установить zVirt Node на хост в соответствии с разделом Установка хоста виртуализации;
-
Подготовьте настройки на хосте в соответствии с разделом Настройка репозитория;
Далее необходимо выполнить следующие шаги:
-
Подключитесь на любой из хостов, ранее находившихся в кластере (в данном кластере ранее был расположен менеджер управления). Если они доступны, командой
hosted-engine --vm-statusпроверьте, на каком из хостов запущен (находится в аварийном режиме) менеджер управления. -
Подключитесь по SSH к этому хосту.
-
Включите режим глобального обслуживания:
hosted-engine --set-maintenance --mode=global hosted-engine --vm-shutdown -
Проверьте, что режим глобального обслуживания включен:
hosted-engine --vm-statusв выводе команды должно быть:
!! Cluster is in GLOBAL MAINTENANCE mode !! -
Подключитесь по SSH на новый хост. Проверьте командой
dnf update, что репозиторий zVirt включен и доступен. -
Выполните установку пакета
ovirt-engine-applianceиз репозитория:dnf install -y ovirt-engine-appliance -
Скопируйте резервную копию backup.bck, созданную ранее, на хост.
-
Перейдите в директорию с резервной копией и начните процедуру развертывания:
hosted-engine --deploy --restore-from-file=backup.bck -
На вопрос о паузе после добавления хоста необходимо выбрать
Yes.[ INFO ] skipping: [localhost] Pause the execution after adding this host to the engine? You will be able to connect to the restored engine in order to manually review and remediate its configuration. This is normally not required when restoring an up to date and coherent backup. Pause after adding the host? (Yes, No)[No]: Yes -
На вопрос
… reinstalled from the engine to update their hosted-engine configurationнеобходимо выбратьYes.[ INFO ] Stage: Environment setup During customization use CTRL-D to abort. Continuing will configure this host for serving as hypervisor and will create a local VM with a running engine. The provided engine backup file will be restored there, it's strongly recommended to run this tool on an host that wasn't part of the environment going to be restored. If a reference to this host is already contained in the backup file, it will be filtered out at restore time. The locally running engine will be used to configure a new storage domain and create a VM there. At the end the disk of the local VM will be moved to the shared storage. The old hosted-engine storage domain will be renamed, after checking that everything is correctly working you can manually remove it. Other hosted-engine hosts have to be reinstalled from the engine to update their hosted-engine configuration. Are you sure you want to continue? (Yes, No)[Yes]: Yes; -
Настройте сеть. Сценарий определит возможные сетевые адаптеры для использования, выберите необходимый.
-
На вопрос о перевыпуске сертификат необходимо ответить
Yes[ INFO ] skipping: [localhost] Renew engine CA on restore if needed? Please notice that if you choose Yes, all hosts will have to be later manually reinstalled from the engine. Renew CA if needed? (Yes, No)[No]: Yes; -
В пункте, где необходимо указать путь к архиву с
OVAфайлом, оставьте рекомендуемое значение по умолчанию. -
Введите пароль
rootдля менеджера управления. -
При необходимости введите открытый ключ SSH, который позволит Вам войти в менеджер управления в качестве пользователя
root, и укажите, следует ли разрешить доступSSHдля пользователяroot. -
Введите количество
vCPUи объем ОЗУ. -
Введите MAC-адрес менеджера управления или используйте сгенерированный адрес.
-
Выберите способ получения IP-адреса:
DHCPилиStatic. Если вы укажетеStatic, введите IP-адрес менеджера. -
Укажите, следует ли добавлять записи для менеджера управления в
/etc/hosts. -
Укажите данные для отправки уведомлений по электронной почте.
-
Введите пароль для пользователя
admin@internal. -
Если на шаге
Pause after adding the host?был выбран вариант ответаYes, то скрипт остановит свою работу. Будет предложено подключиться к менеджеру управления по временной ссылке. В примере это адресhttps://host2.contoso.com:6900/ovirt-engine/к которому можно подключиться и произвести необходимые настройки, например: добавить обязательные сети VLAN, запустить домены хранения.[ INFO ] You can now connect to https://host2.contoso.com:6900/ovirt-engine/ and check the status of this host and eventually remediate it, please continue only when the host is listed as 'up' [ INFO ] TASK [ovirt.ovirt.hosted_engine_setup : include_tasks] [ INFO ] ok: [localhost] [ INFO ] TASK [ovirt.ovirt.hosted_engine_setup : Create temporary lock file] [ INFO ] changed: [localhost -> localhost] [ INFO ] TASK [ovirt.ovirt.hosted_engine_setup : Pause execution until /tmp/ansible.6kktq7yy_he_setup_lock is removed, delete it once ready to proceed]После выполнения настроек, необходимо удалить временный файл /tmp/ansible.6kktq7yy_he_setup_lock, будет продолжена работа мастера.
-
Выберите тип используемого хранилища и укажите данные для подключения.
-
Выберите размер диска менеджера управления.
-
После успешного завершения работы мастера можно подключиться по исходному FQDN менеджера управления.
Восстановление работы менеджера управления из резервной копии на новый хост, ранее не находившийся в кластере. При этом исходное master-хранилище (с менеджером управления) недоступно.
Перед развертыванием необходимо:
-
Соблюсти условия, описанные в пунктах 2-5 инструкции.
-
Установить zVirt Node на хост в соответствии с разделом Установка хоста виртуализации;
-
Подготовьте настройки на хосте в соответствии с разделом Настройка репозитория;
-
Необходимо учесть, что будет создан новый Центр данных, новый Кластер. Хост, на который будет произведена установка возьмёт на себя обслуживание менеджера управления. Добавить новый менеджер управления в ранее созданные Центр данных, и Кластер невозможно.
Далее необходимо выполнить следующие шаги:
-
Подключитесь по SSH на новый хост. Проверьте командой
dnf update, что репозиторий zVirt включен и доступен. -
Выполните установку пакета
ovirt-engine-applianceиз репозитория:dnf install -y ovirt-engine-appliance -
Скопируйте резервную копию
backup.bck, созданную ранее, на хост. -
Перейдите в директорию с резервной копией и начните процедуру развертывания:
hosted-engine --deploy --restore-from-file=backup.bck -
На вопрос об имени центра данных необходимо ввести новое (ранее не использовавшееся) имя центра данных.
--== VM CONFIGURATION ==-- Please enter the name of the datacenter where you want to deploy this hosted-engine host. [Default]: -
На вопрос об имени кластера необходимо ввести новое (ранее не использовавшееся) имя кластера.
Please enter the name of the cluster where you want to deploy this hosted-engine host. [Default]: -
На вопрос о паузе после добавления хоста необходимо выбрать
Yes.[ INFO ] skipping: [localhost] Pause the execution after adding this host to the engine? You will be able to connect to the restored engine in order to manually review and remediate its configuration. This is normally not required when restoring an up to date and coherent backup. Pause after adding the host? (Yes, No)[No]: Yes -
На вопрос
… reinstalled from the engine to update their hosted-engine configurationнеобходимо выбратьYes.[ INFO ] Stage: Environment setup During customization use CTRL-D to abort. Continuing will configure this host for serving as hypervisor and will create a local VM with a running engine. The provided engine backup file will be restored there, it's strongly recommended to run this tool on an host that wasn't part of the environment going to be restored. If a reference to this host is already contained in the backup file, it will be filtered out at restore time. The locally running engine will be used to configure a new storage domain and create a VM there. At the end the disk of the local VM will be moved to the shared storage. The old hosted-engine storage domain will be renamed, after checking that everything is correctly working you can manually remove it. Other hosted-engine hosts have to be reinstalled from the engine to update their hosted-engine configuration. Are you sure you want to continue? (Yes, No)[Yes]: Yes; -
Настройте сеть. Сценарий определит возможные сетевые адаптеры для использования, выберите необходимый.
-
На вопрос о перевыпуске сертификат необходимо ответить
Yes[ INFO ] skipping: [localhost] Renew engine CA on restore if needed? Please notice that if you choose Yes, all hosts will have to be later manually reinstalled from the engine. Renew CA if needed? (Yes, No)[No]: Yes; -
В пункте, где необходимо указать путь к архиву с
OVAфайлом, оставьте рекомендуемое значение по умолчанию. -
Введите пароль
rootдля менеджера управления. -
При необходимости введите открытый ключ SSH, который позволит Вам войти в менеджер управления в качестве пользователя
root, и укажите, следует ли разрешить доступSSHдля пользователяroot. -
Введите количество
vCPUи объем ОЗУ. -
Введите MAC-адрес менеджера управления или используйте сгенерированный адрес.
-
Выберите способ получения IP-адреса:
DHCPилиStatic. Если вы укажетеStatic, введите IP-адрес менеджера. -
Укажите, следует ли добавлять записи для менеджера управления в
/etc/hosts. -
Укажите данные для отправки уведомлений по электронной почте.
-
Введите пароль для пользователя
admin@internal. -
Если на шаге
Pause after adding the host?был выбран вариант ответаYes, то скрипт остановит свою работу. Будет предложено подключиться к менеджеру управления по временной ссылке.[ INFO ] You can now connect to https://host2.contoso.com:6900/ovirt-engine/ and check the status of this host and eventually remediate it, please continue only when the host is listed as 'up' [ INFO ] TASK [ovirt.ovirt.hosted_engine_setup : include_tasks] [ INFO ] ok: [localhost] [ INFO ] TASK [ovirt.ovirt.hosted_engine_setup : Create temporary lock file] [ INFO ] changed: [localhost -> localhost] [ INFO ] TASK [ovirt.ovirt.hosted_engine_setup : Pause execution until /tmp/ansible.6kktq7yy_he_setup_lock is removed, delete it once ready to proceed]После выполнения настроек, необходимо удалить временный файл
/tmp/ansible.6kktq7yy_he_setup_lock, будет продолжена работа мастера. -
Выберите тип используемого хранилища и укажите его данные.
-
Выберите размер диска менеджера управления.
-
После успешного завершения работы мастера можно подключиться по исходному FQDN менеджера управления.
-
В результате развёртывания:
-
группа хостов (обозначена 1) находившаяся в кластере
Defaultи центре данныхDefault, где ранее был развёрнут менеджер управления - будет недоступна (т.к. домен хранения вышел из строя); -
группа хостов (обозначена 2) находившаяся в кластере
NewCluster2и центре данныхDataCenter2, может быть доступна / недоступна в зависимости от домен хранения; -
группа хостов (обозначена 3) находившаяся во вновь созданном кластере
MyCluster2022и центре данныхMyDataCenter2022, будет доступна;
-
-
В результате развёртывания, домены хранения:
-
группа доменов хранения (обозначена 1) находившаяся в кластере
Defaultи центре данныхDefault, где ранее был развёрнут менеджер управления - будет недоступна (т.к. домены хранения вышли из строя). Удалить данные домены хранения нельзя, т.к. недоступен хост SPM, выполнявший роль по управлению хранилищем; -
группа доменов хранения (обозначена 2) находившаяся в кластере
NewCluster2и центре данныхDataCenter2, может быть доступна / недоступна в зависимости от домен хранения; -
группа доменов хранения (обозначена 3) находившаяся во вновь созданном кластере
MyCluster2022и центре данныхMyDataCenter2022, будет доступна;
-
Восстановление работы менеджера управления из резервной копии до предыдущего состояния.
Если менеджер управления доступен, но в нем возникла проблема, (например повреждение базы данных или ошибка конфигурации) можно восстановить менеджер управления в предыдущее состояние, используя резервную копию, сделанную до возникновения проблемы.
Перед развертыванием необходимо:
-
Соблюсти условия, описанные в инструкции.
-
Старое хранилище должно быть доступно (в случае недоступности хранилища будет ошибка
Cannot access the Storage Domain attached to the DataCenter). -
Подготовьте настройки на хосте в соответствии с разделом Настройка репозитория;
Далее необходимо выполнить следующие шаги:
-
Подключитесь на любой из хостов, ранее находившихся в кластере (в данном кластере ранее был расположен менеджер управления). Если они доступны, командой
hosted-engine --vm-statusпроверьте, на каком из хостов запущен менеджер управления. -
Подключитесь по SSH к этому хосту.
-
Включите режим глобального обслуживания:
hosted-engine --set-maintenance --mode=global -
Проверьте, что режим глобального обслуживания включен:
hosted-engine --vm-status -
Подключитесь по SSH к менеджеру управления, остановите сервис
ovirt-engineи выполните команду очистки БД менеджера управления:systemctl stop ovirt-engine.service -
В процессе выполнения скрипт предупредит, что будет остановлена служба
engine. Необходимо подтвердить операцию:[root@manager-drp ~]# engine-cleanup [ INFO ] Stage: Initializing [ INFO ] Stage: Environment setup Configuration files: /etc/ovirt-engine-setup.conf.d/10-packaging-jboss.conf, /etc/ovirt-engine-setup.conf.d/10-packaging.conf, /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf Log file: /var/log/ovirt-engine/setup/ovirt-engine-remove-20221222123552-w6qn8l.log Version: otopi-1.9.6 (otopi-1.9.6-1.el8) [ INFO ] Stage: Environment packages setup [ INFO ] Stage: Programs detection [ INFO ] Stage: Environment customization [ INFO ] Stage: Setup validation During execution engine service will be stopped (OK, Cancel) [OK]: OK -
В процессе выполнения скрипт предупредит, что будут удалены все компоненты. Необходимо подтвердить операцию:
[ INFO ] Hosted Engine HA is in Global Maintenance mode. All the installed ovirt components are about to be removed, data will be lost (OK, Cancel) [Cancel]: OK -
В случае успешного завершения операции сообщение будет следующим:
[ INFO ] Stage: Clean up Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-remove-20221222123552-w6qn8l.log [ INFO ] Generating answer file '/var/lib/ovirt-engine/setup/answers/20221222123722-cleanup.conf' [ INFO ] Stage: Pre-termination [ INFO ] Stage: Termination [ INFO ] Execution of cleanup completed successfully -
Выполните команду для загрузки из резервной копии:
engine-backup --mode=restore --file=/root/filename.bak --restore-permissions -
Выполните команду:
sudo /usr/share/ovirt-engine/dbscripts/engine-psql.sh -c "select fn_db_delete_config_value('AdminPassword','general');" -
В случае успешного выполнения будет указана дата и время, на которую произошло восстановление:
Please note: The engine database was backed up at 2022-12-12 15:28:42. Objects that were added, removed or changed after this date, such as virtual machines, disks, etc., are missing in the engine, and will probably require recovery or recreation. - DWH database ovirt_engine_history - Grafana database /var/lib/grafana/grafana.db You should now run engine-setup. Done -
Запустить
engine-setupсоответствующей командой. -
В процессе развертывания, на вопрос о конфигурации
firewallнеобходимо ответитьYes.Setup can automatically configure the firewall on this system. Note: automatic configuration of the firewall may overwrite current settings. Do you want Setup to configure the firewall? (Yes, No) [Yes]: Yes -
В процессе развертывания, на два вопроса о резервном копировании необходимо ответить следующим образом:
If you choose to not back up the database, and Setup later fails for some reason, it will not be able to restore the database and all DWH data will be lost. Would you like to backup the existing database before upgrading it? (Yes, No) [Yes]: No [WARNING] Are you sure you do not want to backup the DWH database? A positive reply makes sense only if you do not need the data in DWH, or have some other, external means to restore it to a working state. Are you sure you do not want to backup the DWH database?(Yes, No) [No]: No -
В процессе развертывания, на два вопроса об операциях
vacuumиfull vacuumнеобходимо ответитьNo.This operation may take a while depending on this setup health and the configuration of the db vacuum process. See https://www.postgresql.org/docs/12/sql-vacuum.html (Yes, No) [No]: No --== OVIRT ENGINE CONFIGURATION ==-- Perform full vacuum on the engine database engine@localhost? This operation may take a while depending on this setup health and the configuration of the db vacuum process. See https://www.postgresql.org/docs/12/sql-vacuum.html (Yes, No) [No]: No -
В случае успешного выполнения необходимо запустить службу
ovirt-engineи подключаться к менеджеру управления.Please run the following command on the engine machine manager.my.local, for SSO to work: systemctl restart ovirt-engine [ INFO ] Stage: Clean up Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-setup-20221222141208-co86sp.log [ INFO ] Generating answer file /var/lib/ovirt-engine/setup/answers/20221222141507-setup.conf [ INFO ] Stage: Pre-termination [ INFO ] Stage: Termination [ INFO ] Execution of setup completed successfully
2.1.3.3. Ошибки при восстановлении
- Ошибка "codec can’t decode byte 0xd0 in position 0:"
-
Во время восстановления может возникнуть ошибка:
ERROR otopi.context context._executeMethod:154 Failed to execute stage 'Environment customization': 'utf-8' codec can't decode byte 0xd0 in position 0: invalid continuation byteРешение: Был введён недопустимый символ. Из таблицы ASCII символ 0xd0 - Р (на кириллице). Необходимо вводить символы только на латинице.
- Ошибка "Unable to stop service libvirtd"
-
Во время восстановления может возникнуть ошибка:
ERROR otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils._process_output:110 fatal: [localhost]: FAILED! => {"changed": false, "msg": "Unable to stop service libvirtd: Job for libvirtd.service canceled.\n"}Решение: перед началом повторной инсталляции не была выполнена процедура очистки предыдущей установки. Необходимо выполнить команду
ovirt-hosted-engine-cleanup, перезагрузить сервер и повторно запустить процедуру развёртывания. - Ошибка "Your system is configured to use a proxy, please add an exception"
-
Во время восстановления может возникнуть ошибка:
2022-12-01 12:17:41,122+0300 DEBUG otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils._process_output:106 {'results': [{'failed': True, 'msg': 'Your system is configured to use a proxy, please add an exception for http://name.domain.ru/ with no_proxy directive.\n', '_ansible_no_log': False, 'changed': False, 'url': 'http://name.domain.ru/', 'ansible_loop_var': 'url', '_ansible_item_label': 'http://name.domain.ru/'}, {'failed': True, 'msg': 'Your system is configured to use a proxy, please add an exception for https://name.domain.ru/ with no_proxy directive.\n', '_ansible_no_log': False, 'changed': False, 'url': 'https://name.domain.ru/', 'ansible_loop_var': 'url', '_ansible_item_label': 'https://name.domain.ru/'}], 'msg': 'All items completed', 'changed': False}Решение: эта ошибка возникает по причине того, что в процессе развертывания менеджер управления (который находится за NAT хоста), будет происходить обращение к прокси-серверу. В свою очередь у прокси-сервера не будет доступа до менеджера управления. Для устранения ошибки необходимо сделать исключение для менеджера. Перед развертыванием менеджера управления необходимо выполнить команду на хосте:
export no_proxy="FQDN-engine"где
FQDN-engine- полное доменное имя менеджера управления. Напримерmynewmanager.test.ru - Ошибка "Transaction contains conflicting jobs 'restart' and 'stop' for abrt-ccpp.service"
-
Во время восстановления может возникнуть ошибка:
Failed to restart abrtd.service: Transaction contains conflicting jobs 'restart' and 'stop' for abrt-ccpp.service. Probably contradicting requirement dependencies configured. See system logs and 'systemctl status abrtd.service' for details.Решение: необходимо остановить и запустить сервис:
systemctl stop abrtd.service systemctl start abrtd.service
2.1.4. Резервное копирование в режиме Stand Alone
- Исходные данные
-
-
Первый центр данных. Имя -
Default.-
Хост с менеджером управления:
manager.contoso.com. -
Имя кластера -
Default. В кластере два хоста:host1.contoso.comиhost2.contoso.com. -
Имя домена хранения -
storage_iscsi. ТипiSCSI. -
Имя домена хранения -
storage_nfs. ТипNFS. -
Два гипервизора с обязательными сетями
VLAN 100, 101.
-
-
Второй центр данных. Имя -
DataCenter2.-
Имя кластера -
Cluster2. В кластере один хост:host3.contoso.com. -
Имя домена хранения -
storage-nfs-datacenter2. ТипNFS. -
Гипервизор с обязательной сетью
VLAN 102.
-
Адрес менеджера управления -
https://manager.contoso.com/ovirt-engine/ -
2.1.4.1. Процедура резервного копирования
Рекомендуется регулярно выполнять процедуру резервного копирования базы данных менеджера управления. Данную процедура рекомендуется выполнять в нерабочее время.
- Рекомендуемый способ резервного копирования
-
-
Подключитесь по SSH к менеджеру управления.
-
Остановите сервис
ovirt-engine:systemctl stop ovirt-engine.service -
Создайте эталонную резервную копию базы данных менеджера управления:
engine-backup --scope=all --mode=backup --file=firstbackup.bck --log=firstbackup.log -
Сохраните полученные файлы в хранилище вне среды виртуализации.
-
Выполните команду:
sudo /usr/share/ovirt-engine/dbscripts/engine-psql.sh -c "select fn_db_delete_config_value('AdminPassword','general');"Результат выполнения:
# sudo /usr/share/ovirt-engine/dbscripts/engine-psql.sh -c "select fn_db_delete_config_value('AdminPassword','general');" fn_db_delete_config_value --------------------------- (1 row) -
Создайте ещё одну резервную копию базы данных менеджера управления:
engine-backup --scope=all --mode=backup --file=backup.bck --log=backuplog.log -
Сохраните полученные файлы в хранилище вне среды виртуализации.
-
Запустите сервис
ovirt-engine:systemctl start ovirt-engine.service
-
2.1.4.2. Процедура восстановления
При сбое в работе менеджера управления может быть принято решение о восстановлении. Восстановление может происходить в нескольких вариантах:
-
Из резервной копии на вновь созданный (чистый хост)
-
Из резервной копии до предыдущего состояния
Требования для восстановления.
Для восстановления, необходимы соблюсти ряд условий:
-
Исходные домены хранения должны быть доступны.
-
Режим
multipathдолжен быть настроен. Рекомендуемые настройки для multipath. -
Произведена настройка фильтра LVM по инструкции.
-
Произведена настройка IP адресов, маски подсети, DNS.
-
При восстановлении на новом хосте, имя хоста должен быть изменено на такое же, которое ранее было у Менеджера управления
Восстановление работы менеджера управления из резервной копии на вновь созданный (чистый хост).
-
Подключитесь по SSH к хосту с установленным zVirt
-
Скопируйте резервную копию backup.bck, созданную ранее, на хост.
-
Перейдите в директорию с резервной копией и и выполните обновление:
engine-backup --mode=restore --file=backup.bck --provision-all-databases -
Выполните команду:
engine-setup --offline -
В процессе развертывания будет задан ряд вопросов, отвечайте на них в соответствии с Вашими предпочтениями, но на вопросы указанные ниже необходимо ответить следующим образом:
Would you like to backup the existing database before upgrading it? (Yes, No) No Are you sure you do not want to backup the DWH database? (Yes, No) Yes One or more of the certificates should be renewed, because they expire soon, or include an invalid expiry date, or they were created with validity period longer than 398 days, or do not include the subjectAltName extension, which can cause them to be rejected by recent browsers and up to date hosts. See https://www.info-lend.ru/develop/release-management/features/infra/pki-renew/ for more details. Renew certificates? (Yes, No) Yes -
Проверьте каталог /etc/ovirt-engine-setup.conf.d/ на наличие дополнительных файлов 20-setup-ovirt-post.conf с таким же именем и числом, если файлы есть - удалите их (например, 20-setup-ovirt-post.conf.20210528124601).
ls -l /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf.* rm -rf /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf.* -
После успешного завершения работы мастера можно подключиться по исходному FQDN менеджера управления.
Восстановление работы менеджера управления из резервной копии до предыдущего состояния.
Если менеджер управления доступен, но в нем возникла проблема, (например повреждение базы данных или ошибка конфигурации) можно восстановить менеджер управления в предыдущее состояние, используя резервную копию, сделанную до возникновения проблемы.
Далее необходимо выполнить следующие шаги:
-
Подключитесь по SSH к менеджеру управления.
-
Остановите сервис
ovirt-engineи выполните команду очистки БД менеджера управления:systemctl stop ovirt-engine.service -
Выполните команду очистки БД менеджера управления:
engine-cleanup -
В процессе выполнения скрипт предупредит, что будут удалены все компоненты. Необходимо подтвердить операцию:
[ INFO ] Hosted Engine HA is in Global Maintenance mode. All the installed ovirt components are about to be removed, data will be lost (OK, Cancel) [Cancel]: OK -
В случае успешного завершения операции сообщение будет следующим:
[ INFO ] Stage: Clean up Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-remove-20221222123552-w6qn8l.log [ INFO ] Generating answer file '/var/lib/ovirt-engine/setup/answers/20221222123722-cleanup.conf' [ INFO ] Stage: Pre-termination [ INFO ] Stage: Termination [ INFO ] Execution of cleanup completed successfully -
Выполните команду для загрузки из резервной копии:
engine-backup --mode=restore --file=/root/backup.bck --restore-permissions -
В случае успешного выполнения будет указана дата и время, на которую произошло восстановление:
Please note: The engine database was backed up at 2022-12-12 15:28:42. Objects that were added, removed or changed after this date, such as virtual machines, disks, etc., are missing in the engine, and will probably require recovery or recreation. - DWH database ovirt_engine_history - Grafana database /var/lib/grafana/grafana.db You should now run engine-setup. Done -
Выполните команду:
sudo /usr/share/ovirt-engine/dbscripts/engine-psql.sh -c "select fn_db_delete_config_value('AdminPassword','general');" -
Запустить
engine-setupсоответствующей командой. -
В процессе развертывания, на вопрос о конфигурации
firewallнеобходимо ответитьYes.Setup can automatically configure the firewall on this system. Note: automatic configuration of the firewall may overwrite current settings. Do you want Setup to configure the firewall? (Yes, No) [Yes]: -
В процессе развертывания, на два вопроса о резервном копировании необходимо ответить следующим образом:
If you choose to not back up the database, and Setup later fails for some reason, it will not be able to restore the database and all DWH data will be lost. Would you like to backup the existing database before upgrading it? (Yes, No) [Yes]: No [WARNING] Are you sure you do not want to backup the DWH database? A positive reply makes sense only if you do not need the data in DWH, or have some other, external means to restore it to a working state. Are you sure you do not want to backup the DWH database?(Yes, No) [No]: Yes -
В процессе развертывания, на два вопроса об операциях
vacuumиfull vacuumнеобходимо ответитьNo.This operation may take a while depending on this setup health and the configuration of the db vacuum process. See https://www.postgresql.org/docs/12/sql-vacuum.html (Yes, No) [No]: No --== OVIRT ENGINE CONFIGURATION ==-- Perform full vacuum on the engine database engine@localhost? This operation may take a while depending on this setup health and the configuration of the db vacuum process. See https://www.postgresql.org/docs/12/sql-vacuum.html (Yes, No) [No]: No -
В случае успешного выполнения необходимо перезапустить службу
ovirt-engineи подключаться к менеджеру управления:systemctl restart ovirt-engine.service
2.1.5. Резервное копирование в режиме Stand Alone All-in-One
- Исходные данные
-
-
Первый центр данных. Имя -
Default.-
Хост с менеджером управления:
manager.contoso.com -
Имя кластера -
Default. В кластере два хоста:host1.contoso.comиhost2.contoso.com. -
Имя домена хранения -
storage_iscsi. Тип iSCSI. -
Имя домена хранения -
storage_nfs. Тип NFS. -
На двух хостах добавлены обязательные сети
VLAN 100, 101.
-
-
Второй центр данных. Имя -
DataCenter2.-
Имя кластера -
Cluster2. В кластере один хост:host3.contoso.com. -
Имя домена хранения -
storage-nfs-datacenter2. Тип NFS. -
На хост добавлена обязательная сеть
VLAN 102.
-
Адрес менеджера управления -
https://manager.contoso.com/ovirt-engine/===== Процедура резервного копирования
-
Рекомендуется регулярно выполнять процедуру резервного копирования базы данных менеджера управления. Данная процедура должна выполняться в нерабочее время.
- Рекомендуемый способ резервного копирования
-
-
Подключитесь по SSH к менеджеру управления.
-
Остановите сервис
ovirt-engine:systemctl stop ovirt-engine.service -
Cоздайте эталонную резервную копию базы данных менеджера управления:
engine-backup --scope=all --mode=backup --file=firstbackup.bck --log=firstbackup.log -
Сохраните полученные файлы в хранилище вне среды виртуализации.
-
Выполните команду:
sudo /usr/share/ovirt-engine/dbscripts/engine-psql.sh -c "select fn_db_delete_config_value('AdminPassword','general');"Корректный результат выполнения:
# sudo /usr/share/ovirt-engine/dbscripts/engine-psql.sh -c "select fn_db_delete_config_value('AdminPassword','general');" fn_db_delete_config_value --------------------------- (1 row) -
Создайте ещё одну резервную копию базы данных менеджера управления:
engine-backup --scope=all --mode=backup --file=backup.bck --log=backuplog.log -
Сохраните полученные файлы в хранилище вне среды виртуализации.
-
Запустите сервис
ovirt-engine:systemctl start ovirt-engine.service
-
2.1.5.1. Процедура восстановления
При сбое в работе менеджера управления может быть принято решение о восстановлении. Восстановление может происходить в нескольких вариантах:
-
Из резервной копии на вновь созданный (чистый хост).
-
Из резервной копии до предыдущего состояния.
Требования для восстановления.
Для восстановления, необходимы соблюсти ряд условий:
-
Исходные домены хранения должны быть доступны.
-
Режим
multipathдолжен быть настроен. Рекомендуемые настройки для multipath. -
Произведена настройка фильтра LVM по инструкции.
-
Произведена настройка IP адресов, маски подсети, DNS.
-
При восстановлении на новом хосте, имя хоста должен быть изменено на такое же, которое ранее было у Менеджера управления
Восстановление работы менеджера управления из резервной копии на вновь созданный (чистый хост)
-
Подключитесь по SSH к хосту с установленным zVirt
-
Скопируйте резервную копию
backup.bck, созданную ранее, на хост. -
Перейдите в директорию с резервной копией и и выполните обновление:
engine-backup --mode=restore --file=backup.bck --provision-all-databases -
Выполните команду:
engine-setup --offline -
В процессе развертывания будет задан ряд вопросов, отвечайте на них в соответствии с Вашими предпочтениями, но на вопросы указанные ниже необходимо ответить следующим образом:
Would you like to backup the existing database before upgrading it? (Yes, No) - выбрать No Are you sure you do not want to backup the DWH database? (Yes, No) - выбрать Yes One or more of the certificates should be renewed, because they expire soon, or include an invalid expiry date, or they were created with validity period longer than 398 days, or do not include the subjectAltName extension, which can cause them to be rejected by recent browsers and up to date hosts. See https://www.info-lend.ru/develop/release-management/features/infra/pki-renew/ for more details. Renew certificates? (Yes, No) - выбрать Yes -
Проверьте каталог /etc/ovirt-engine-setup.conf.d/ на наличие дополнительных файлов 20-setup-ovirt-post.conf с таким же именем и числом, если файлы есть - удалите их (например, 20-setup-ovirt-post.conf.20210528124601).
ls -l /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf.* rm -rf /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf.* -
После успешного завершения работы мастера можно подключиться по исходному FQDN менеджера управления.
Для возвращения хоста с Менеджером управления в кластер, необходимо зайти в веб-интерфейс Менеджера управления и перейти ко вкладке и добавить новый хост. Предыдущий хост нужно удалить из кластера.
Восстановление работы менеджера управления из резервной копии до предыдущего состояния.
Если менеджер управления доступен, но в нем возникла проблема, (например повреждение базы данных или ошибка конфигурации) можно восстановить менеджер управления в предыдущее состояние, используя резервную копию, сделанную до возникновения проблемы.
Далее необходимо выполнить следующие шаги:
-
Подключитесь по SSH к менеджеру управления.
-
Остановите сервис
ovirt-engineи выполните команду очистки БД менеджера управления:systemctl stop ovirt-engine.service -
Выполните команду очистки БД менеджера управления:
engine-cleanup -
В процессе выполнения скрипт предупредит, что будут удалены все компоненты. Необходимо подтвердить операцию:
[ INFO ] Hosted Engine HA is in Global Maintenance mode. All the installed ovirt components are about to be removed, data will be lost (OK, Cancel) [Cancel]: OK -
В случае успешного завершения операции сообщение будет следующим:
[ INFO ] Stage: Clean up Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-remove-20221222123552-w6qn8l.log [ INFO ] Generating answer file '/var/lib/ovirt-engine/setup/answers/20221222123722-cleanup.conf' [ INFO ] Stage: Pre-termination [ INFO ] Stage: Termination [ INFO ] Execution of cleanup completed successfully -
Выполните команду для загрузки из резервной копии:
engine-backup --mode=restore --file=/root/backup.bck --restore-permissions -
В случае успешного выполнения будет указана дата и время, на которую произошло восстановление:
Please note: The engine database was backed up at 2022-12-12 15:28:42. Objects that were added, removed or changed after this date, such as virtual machines, disks, etc., are missing in the engine, and will probably require recovery or recreation. - DWH database ovirt_engine_history - Grafana database /var/lib/grafana/grafana.db You should now run engine-setup. Done -
Выполните команду:
sudo /usr/share/ovirt-engine/dbscripts/engine-psql.sh -c "select fn_db_delete_config_value('AdminPassword','general');" -
Запустите
engine-setupсоответствующей командой. -
В процессе развертывания, на вопрос о конфигурации
firewallнеобходимо ответитьYes.Setup can automatically configure the firewall on this system. Note: automatic configuration of the firewall may overwrite current settings. Do you want Setup to configure the firewall? (Yes, No) [Yes]: -
В процессе развертывания, на два вопроса о резервном копировании необходимо ответить следующим образом:
If you choose to not back up the database, and Setup later fails for some reason, it will not be able to restore the database and all DWH data will be lost. Would you like to backup the existing database before upgrading it? (Yes, No) [Yes]: No [WARNING] Are you sure you do not want to backup the DWH database? A positive reply makes sense only if you do not need the data in DWH, or have some other, external means to restore it to a working state. Are you sure you do not want to backup the DWH database?(Yes, No) [No]: Yes -
В процессе развертывания, на два вопроса об операциях
vacuumиfull vacuumнеобходимо ответитьNo.This operation may take a while depending on this setup health and the configuration of the db vacuum process. See https://www.postgresql.org/docs/12/sql-vacuum.html (Yes, No) [No]: No --== OVIRT ENGINE CONFIGURATION ==-- Perform full vacuum on the engine database engine@localhost? This operation may take a while depending on this setup health and the configuration of the db vacuum process. See https://www.postgresql.org/docs/12/sql-vacuum.html (Yes, No) [No]: No -
В случае успешного выполнения необходимо перезапустить службу
ovirt-engineи подключаться к менеджеру управления:systemctl restart ovirt-engine.service
После восстановления, хост, на котором установлен Менеджер управления, будет в выключенном состоянии. Чтобы вернуть хост с Менеджером управления в кластер в качестве гипервизора, необходимо выполнить следующие шаги:
-
Перейди на вкладку в Менеджере управления.
-
Выберите хост, на котором развёрнут Менеджер управления и переведите его в режим обслуживания Управление → Обслуживание;
-
Переустановите хост, выбрав хост и нажав кнопку Настройки → Переустановить, в дополнительных параметрах ничего менять не нужно;
-
Дождитесь окончания процесса переустановки гипервизора;
-
По окончанию загрузки, Менеджер управления будет перезагружен и вновь добавлен в кластер в качестве хоста гипервизора.
2.1.6. Резервное копирование Менеджера управления через портал администрирования
| Процедуры, описанные в этой инструкции актуальны для версии zVirt 3.2 и выше |
В zVirt имеется возможность ручного резервного копирования менеджера управления через Портал администрирования, а также добавления расписания, в соответствии с которым создание резервных копий будет выполняться в автоматическом режиме.
2.1.6.1. Управление хранилищами резервных копий
На Портале администрирования есть возможность указания удаленного хранилища для сохранения файла резервной копии как в ручном режиме, так и при настройке заданий резервного копирования. Это позволяет сохранить файл резервной копии на хосте/ВМ, отличном от того, на котором расположен менеджер управления и даёт возможность воспользоваться файлом резервной копии, если хост/ВМ с менеджером управления вышли из строя.
Просмотр списка хранилищ резервных копий
Для просмотра и проверки конфигурации хранилищ резервных копий на Портале администрирования нажмите , а затем перейдите на на вкладку Хранилища резервных копий (Backup storages).
Список хранилищ резервных копий представлен в виде таблицы, по умолчанию отображающей следующие сведения о хранилищах:
-
Хост (Host) - FQDN/IP-адрес хоста, на который отправляются файлы резервных копий
-
Порт (Port) - порт, используемый для передачи файлов резервных копий
-
Путь к резервной копии (Backup path) - абсолютный путь к каталогу на удалённой машине, в котором сохраняются файлы резервных копий
-
Пользователь (User) - имя учетной записи пользователя, от имени которого выполняется подключение к удалённой машине для передачи файлов резервных копий
-
Описание (Description) - описание хранилища
Для быстрого поиска нужного хранилища можно воспользоваться строкой поиска.
Поиск осуществляется по значениям во всех столбцах таблицы независимо от видимости столбцов.
При необходимости, видимость столбцов можно изменить в меню настройки
.
Добавление хранилища резервных копий
Для добавления нового хранилища резервных копий, на Портале администрирования выполните следующие действия.
-
Нажмите
-
Перейдите на вкладку Хранилища резервных копий (Backup storages)
-
Нажмите Добавить хранилище (Add Storage)
-
В появившемся окне "Добавление хранилища" ("Adding Storage") настройте следующие параметры:
-
В поле Хост (Host) введите FQDN или IP-адрес хоста, на который будут отправляться файлы резервных копий
-
В поле Порт (Port) укажите порт, который будет использоваться для передачи файлов резервных копий (по умолчанию -
22)Передача файлов резервных копий осуществляется утилитой scp, поэтому используемый по умолчанию порт имеет значение22. Если на удалённой машине изменён стандартный порт для доступа по SSH, в этом поле также необходимо установить соответствующее значение -
В поле Путь к резервной копии (Backup path) укажите абсолютный путь к каталогу на удалённой машине, в котором необходимо сохранять файлы резервных копий
-
В поле Пользователь (User) введите имя учетной записи пользователя, от имени которого необходимо подключаться к удалённой машине для передачи файлов резервных копий (по умолчанию root)
-
В поле Пароль (Password) введите пароль учётной записи, указанной в поле Пользователь (User)
-
Дополнительно: в поле Описание (Description) введите описание хранилища
-
-
Нажмите Проверить соединение (Check the connection).
Если параметры подключения введены корректно, появится уведомление об успешной проверке соединения
В случае появления уведомления об ошибке установки соединения, проверьте корректность настроек и повторите проверку соединения.
-
Нажмите Добавить хранилище (Add Storage)
После выполнения описанной процедуры, в списке хранилищ резервных копий появится новая запись.
Изменение хранилища резервных копий
Чтобы изменить настройки существующего хранилища резервных копий, выполните следующие действия.
-
Нажмите
-
Перейдите на вкладку Хранилища резервных копий (Backup storages)
-
Выделите нужное хранилище и нажмите Редактировать (Edit)
-
Измените нужные настройки
-
Нажмите Проверить соединение (Check the connection).
Если параметры подключения введены корректно, появится уведомление об успешной проверке соединения
В случае появления уведомления об ошибке установки соединения, проверьте корректность настроек и повторите проверку соединения.
-
Нажмите Редактировать хранилище (Edit Storage)
Если операция обновления прошла успешно, появится следующее уведомление:
Удаление хранилища резервных копий
Если некоторые из хранилищ резервных копий больше не требуются, то их можно удалить, выполнив следующие действия.
-
Нажмите
-
Перейдите на вкладку Хранилища резервных копий (Backup storages)
-
Отметьте нужные хранилища галочками и нажмите Удалить (Delete)
-
Подтвердите операцию удаления в появившемся окне
2.1.6.2. Ручное резервное копирование менеджера управления
Пользователи, имеющие определённое разрешение (см. раздел Управление разрешением на резервное копирование менеджера управления), могут создать резервную копию выбранных компонентов менеджера управления через Портал администрирования.
Ручное создание резервной копии менеджера управления
Для запуска резервного копирования менеджера управления выполните следующие действия.
| Если требуется хранение резервной копии на удалённом хранилище, перед выполнением процедуры убедитесь, что подключено хранилище резервных копий (См. раздел Управление хранилищами резервных копий) |
-
Нажмите
-
Убедитесь, что активна вкладка Ручное резервное копирование (Manual backup)
-
Настройте параметры резервного копирования (полное описание параметров см. в таблице Настройки на вкладке "Ручное резервное копирование" ("Manual backup"):
-
В поле Расположение файла резервной копии (Backup file location) введите абсолютный путь к локальному каталогу, в котором будет храниться резервная копия
-
В группе Состав компонентов (Composition of components) выберите компоненты менеджера управления, резервную копию которых необходимо сделать
-
Дополнительно: В меню Хранилище (Storage) выберите добавленное ранее хранилище резервных копий.
-
-
Нажмите Создать резервную копию (Create a backup)
После нажатия на Создать резервную копию (Create a backup) будет отображено уведомление о создании задачи резервного копирования.
Проконтролировать процесс создания резервной копии можно через раздел Задачи
, а также в блоке уведомлений
в подразделе События.
Описание настроек ручного резервного копирования
В таблице ниже представлено общее описание параметров, доступных для настройки на вкладке Ручное резервное копирование (Manual backup)
| Параметр | Описание |
|---|---|
Расположение файла резервной копии (Backup file location) |
Локальное расположение файла резервной копии. По умолчанию /var/lib/zvirt-engine-backup/ |
Состав компонентов (Composition of components) |
Соответствует параметру Должен быть выбран хотя бы один из компонентов. Список доступных для выбора пунктов:
Дополнительную информацию об утилите |
Хранилище (Storage) |
Выбор из настроенных хранилищ резервных копий. Если не выбрано, резервная копия сохраняется локально |
2.1.6.3. Управление задачами резервного копирования менеджера управления по расписанию
Просмотр задач резервного копирования
На Портале администрирования есть возможность просмотра созданных задач резервного копирования по расписанию.
Для этого нажмите и перейдите на вкладку Расписание резервного копирования (Backup schedule).
Список задач резервного копирования представлен в виде таблицы, по умолчанию отображающей следующие сведения:
-
Расписание (Schedule) - выражение в формате quartz cron, определяющее расписание запуска задачи
-
Последний удачный запуск (Last successful Launch) - дата и время последней успешной попытки запуска задачи. Если в поле стоит
-, значит удачной попытки запуска ещё не было. -
Следующий запуск (Next launch) - дата и время следующего запуска задачи. Если в поле стоит
-, запуск не запланирован -
Расположение файла (File location) - абсолютный путь к локальному каталогу, в котором сохраняются файлы резервных копий
-
Хранилище (Storage) - используемое для задачи хранилище резервных копий
-
Описание (Description)
Видимость колонок таблицы можно изменить в меню настройки
.
Каждая запись в таблице имеет переключатель
, позволяющий активировать/деактивировать соответствующую задачу.
Добавление задачи резервного копирования по расписанию
Для создания новой задачи выполните следующие действия.
| Если требуется хранение резервной копии на удалённом хранилище, перед выполнением процедуры убедитесь, что подключено хранилище резервных копий (См. раздел Управление хранилищами резервных копий) |
-
Нажмите
-
Перейдите на вкладку Расписание резервного копирования (Backup schedule)
-
Нажмите Добавить задачу (Add a task).
-
В появившемся окне "Добавление задачи" ("Adding a task") настройте параметры задания резервного копирования (полное описание параметров см. в [Таблице 3.2. Настройки задания резервного копирования](#t3-2)).
-
Убедитесь в том, что переключатель выполнения задачи по расписанию находится в состоянии Задача включена (The task includes)
-
В поле Расположение файла резервной копии (Backup file location) укажите абсолютный путь к локальному расположению файла резервной копии
-
В поле Расписание (Schedule) укажите расписание. Это можно сделать двумя способами:
-
Задать расписание вручную, введя выражение в формате Quartz cron (см. раздел Использование формата Quartz cron для задания расписания)
-
Использовать графический помощник, нажав на кнопку
рядом с полем ввода
-
-
Дополнительно: в поле Описание (Description) введите описание задачи
-
В группе Состав компонентов (Composition of components) отметьте компоненты, резервное копирование которых должна выполнять задача
-
Дополнительно: В меню Хранилище (Storage) выберите добавленное ранее хранилище резервных копий.
-
-
Нажмите Добавить задачу (Add a task)
При успешном добавлении задачи отобразится уведомление.
Также в списке задач появится новая запись.
Проконтролировать процесс создания резервной копии можно через раздел Задачи
, а также в блоке уведомлений
в подразделе События.
| В случае каких-либо проблем с выполнением задачи резервного копирования, сервисом совершается до двух дополнительных (через 30 минут после очередного неуспешного запуска) попыток выполнения задачи резервного копирования. Если следующий момент (по расписанию) наступает раньше запланированного времени повторной попытки, то повторные попытки прекращаются. |
Изменение задачи резервного копирования по расписанию
При необходимости, можно изменить параметры существующей задачи. Для этого выполните следующие действия.
-
Нажмите
-
Перейдите на вкладку Расписание резервного копирования (Backup schedule)
-
Выделите нужную задачу и нажмите Редактировать (Edit)
-
Измените нужные настройки
-
Нажмите Сохранить задачу (Save the task)
Если операция обновления прошла успешно, появится следующее уведомление:
В списке задач также отобразятся обновлённые сведения о задаче.
Удаление задач резервного копирования по расписанию
Если некоторые из задач больше не требуются, то их можно удалить, выполнив следующие действия.
-
Нажмите
-
Перейдите на вкладку Расписание резервного копирования (Backup schedule)
-
Отметьте нужные задачи галочками и нажмите Удалить (Delete)
-
Подтвердите операцию удаления в появившемся окне
После подтверждения операции удаления отобразится уведомление
Отправка результатов операции резервного копирования менеджера управления по расписанию на email
zVirt предоставляет возможность получать информацию о результатах операции резервного копирования, запущенного по расписанию, на указанный в настройках пользователя email-адрес, чтобы не приходилось каждый раз самостоятельно проверять результаты операции вручную.
Операция резервного копирования в общем случае имеет четыре этапа:
-
Начало операции резервного копирования
-
Завершение (успешное или неуспешное) операции резервного копирования
-
Начало переноса файла резервной копии на целевое хранилище
-
Завершение (успешное или неуспешное) переноса файла резервной копии на целевое хранилище
Для активации отправки оповещений о резервном копировании и переносе файла копии на email-адрес соответствующего пользователя выполните следующие действия.
| Для получения уведомлений по электронной почте, убедитесь что почтовый сервер настроен и запущена служба ovirt-engine-notifier (подробнее о настройке уведомлений см. в разделе Уведомления о событиях руководства администратора) |
-
Нажмите
-
Нажмите на имя нужного пользователя. Откроется подробное представления
-
Перейдите на вкладку Уведомления о событиях (Event Notifier)
-
Нажмите Управлять событиями (Manage Events)
-
Разверните (
) раздел Общие события управления (General Management Events) и отметьте галочками нужные события, относящиеся к резервному копированию менеджера управления:
-
Проверьте корректность почтового адреса получателя в поле Получатель почты (Mail Recipient)
-
Нажмите OK
Так же в конфигурационном файле сервиса ovirt-engine-notifier (/usr/share/ovirt-engine/services/ovirt-engine-notifier/ovirt-engine-notifier.conf) есть три параметра, управляющих локализацией и объединением нотификационных email (см. таблицу ниже).
| Параметр | Значение по умолчанию | Описание |
|---|---|---|
|
- |
Содержит в себе список типов уведомлений, для которых нужно объединять email, например:
Если данный параметр не задан - объединения email происходить не будет. В этом случае, если, например, запустить операцию резервного копирования с указанием |
|
5000 |
Содержит в себе предел по разнице времени (в миллисекундах) между сообщениями для объединения в один email. Система отправки оповещений устроена так, что отправляет email уведомления не мгновенно, а с некоторыми интервалами. Соответственно, если перед отправкой имеется несколько уведомлений, которые необходимо объединить в один email (их типы прописаны |
|
- |
Содержит код языка, на который нужно переводить email уведомления. На данный момент поддерживается только два значения |
Подробнее о настройке параметров уведомлений о событиях в ovirt-engine-notifier.conf см. в разделе Уведомления о событиях руководства администратора.
Описание настроек планировщика резервного копирования менеджера управления
В таблице ниже представлено общее описание параметров, доступных для настройки в окнах Добавление задачи (Adding a task) и Редактирование задачи (Editing a task)
| Параметр | Описание |
|---|---|
Расположение файла резервной копии (Backup file location) |
Локальное расположение файла резервной копии. По умолчанию /var/lib/zvirt-engine-backup/ |
Расписание (Schedule) |
Выражение в формате quartz cron, определяющее расписание запуска задачи |
Описание (Description) |
Описание добавляемого задания |
Состав компонентов (Composition of components) |
Соответствует параметру Должен быть выбран хотя бы один из компонентов. Список доступных для выбора пунктов:
Дополнительную информацию об утилите |
Хранилище (Storage) |
Выбор из настроенных хранилищ резервных копий. Если не выбрано, резервная копия сохраняется локально |
При ручном вводе выражения, определяющего расписание запуска задачи, ожидается использование формата Quartz cron. Данный формат состоит из 6 или 7 полей, разделенных пробелом. Каждое поле имеет определённую значимость.
Поля могут содержать любые допустимые значения, а также различные комбинации разрешенных специальных символов для этого поля. Допустимые значения и символы представлены в таблице ниже
| Номер | Имя поля | Допустимые значения | Разрешенные специальные символы |
|---|---|---|---|
1 |
Секунды |
0-59 |
, - * / |
2 |
Минуты |
0-59 |
, - * / |
3 |
Часы |
0-23 |
, - * / |
4 |
День месяца |
1-31 |
, - * ? / L W |
5 |
Месяц |
1-12 или JAN-DEC |
, - * / |
6 |
День недели |
1-7 или SUN-SAT |
, - * ? / L # |
7 |
Год (необязательное) |
Пустое или 1970-2099 |
, - * / |
Значение специальных символов
-
(все значения) - используется для выбора всех значений в поле. Например,в поле минут означает «каждую минуту» -
?(любое значение) - полезно, когда нужно указать что-то в одном из двух полей, в которых этот символ разрешен, но не в другом. Например, если необходимо, чтобы задача запустилась в определенный день месяца (допустим, 10-го числа), но все равно, какой это будет день недели, то можно разместить10в поле "День месяца", а?- в поле "День недели". -
-- используется для указания диапазонов. Например,10-12в поле часов означает "часы 10, 11 и 12" -
,- используется для указания дополнительных значений. Например,MON,WED,FRIв поле "день недели" означает "дни понедельник, среда и пятница". -
/- используется для указания приращений. Например,0/15в поле секунд означает "секунды 0, 15, 30 и 45". А5/15в поле секунд означает "секунды 5, 20, 35 и 50". -
L(последний) - имеет разное значение в каждом из двух полей, в которых оно разрешено. Например, значениеLв поле "день месяца" означает "последний день месяца" - 31 день для января, 28 день для февраля в невисокосные годы. Если это значение используется в поле дня недели само по себе, оно означает просто "7" или "SAT". Но если оно используется в поле дня недели после другого значения, оно означает "последнийxxxдень месяца" - например,6Lозначает "последняя пятница месяца". При использовании опцииLважно не указывать списки или диапазоны значений, так как вы получите путаные/неожиданные результаты. -
W(будний день) - используется для указания ближайшего к данному дню дня недели (понедельник-пятница). Например, если вы укажете15Wв качестве значения для поля "День месяца", это будет означать: "ближайший будний день к 15 числу месяца". Таким образом, если 15-е число приходится на субботу, задача запустится в пятницу 14-го. Если 15-е число приходится на воскресенье, задача запустится в понедельник 16-го. Если 15-е число приходится на вторник, то задача запустится во вторник 15-го. Однако если вы укажете1Wв качестве значения дня месяца, а 1-е число будет субботой, задача запустится в понедельник 3-го числа, поскольку он не будет "перескакивать" через границу дней месяца. СимволWможет быть указан только в том случае, если день месяца - это один день, а не диапазон или список дней. -
#- используется для указания "n-го" XXX дня месяца. Например, значение6#3в поле "День недели" означает "третья пятница месяца" (день6= пятница, а#3= третий в месяце).
| Выражение | Значение |
|---|---|
|
Запуск в 12 часов дня каждый день |
|
Запуск в 10:15 утра каждый день |
|
Запуск в 10:15 утра каждый день в течение 2023 года |
|
Запуск каждую минуту, начиная с 14:00 и заканчивая 14:59, каждый день |
|
Запуск каждые 5 минут, с 14:00 и до 14:55, а также с 18:00 и до 18:55, каждый день |
|
Запуск в 10:15 утра каждый понедельник, вторник, среду, четверг и пятницу |
|
Запуск в 10:15 утра в последний день каждого месяца |
|
Запуск в 10:15 утра в третью пятницу каждого месяца |
2.1.6.4. Управление разрешением на резервное копирование менеджера управления
Пользователю, не имеющему определённое разрешение, недоступна функциональность резервного копирования через Портал администрирования (как однократно, так и работа со сценариями резервного копирования по расписанию).
Для предоставления прав на использование функций резервного копирования через веб-интерфейс, необходимо для нужной роли задать разрешение Резервное копирование менеджера управления (Engine backup management).
| Разрешение Резервное копирование менеджера управления (Engine backup management) доступно только для типа учётной записи Администратор (Admin). |
| Для роли SuperUser разрешение Резервное копирование менеджера управления (Engine backup management) включено по умолчанию. |
Дополнительную информацию по настройке ролей см. в разделах Роли и Системные разрешения в руководстве администратора.
2.2. Перенос базы данных и службы Data Warehouse на отдельную машину
В этом разделе описано, как перенести базу данных и службу Data Warehouse с машины с Менеджером управления на отдельную машину. Размещение службы Data Warehouse (ovirt-engine-dwhd) на отдельной машине снижает нагрузку на каждую отдельную машину и позволяет избежать потенциальных конфликтов, связанным с тем, что ресурсы ЦП и памяти приходится делить с другими процессами.
| zVirt поддерживает установку базы данных и службы Data Warehouse и Grafana на одной машине, хотя можно установить каждый из этих компонентов на отдельных машинах. |
Доступны следующие варианты миграции:
-
Можно перенести службу Data Warehouse (ovirt-engine-dwhd) с машины с Менеджером управления и подключить ее к существующей базе данных Data Warehouse (ovirt_engine_history).
-
Можно перенести базу данных Data Warehouse (ovirt_engine_history) с машины с Менеджером управления, а затем перенести службу Data Warehouse (ovirt-engine-dwhd).
| Данный раздел предполагает, что новая машина развёрнута на основе дистрибутива zVirt Node |
2.2.1. Перенос базы данных Data Warehouse на отдельную машину
Перенесите базу данных Data Warehouse (ovirt_engine_history) до переноса службы Data Warehouse. Используйте engine-backup для создания резервной копии базы данных и ее восстановления на новой машине с базой данных. Дополнительные сведения о engine-backup см. с помощью команды engine-backup --help.
-
Создайте резервную копию базы данных и файлов конфигурации Data Warehouse в Менеджере управления:
# engine-backup --mode=backup --scope=dwhdb --scope=files --file=_file_name_ --log=_log_file_name_ -
Скопируйте файл резервной копии из Менеджера управления на новую машину.
# scp _/tmp/file_name_ _root@new.dwh.server.com:/tmp_ -
Восстановите базу данных Data Warehouse на новой машине.
file_name– это файл резервной копии, скопированный из Менеджера управления.# engine-backup --mode=restore --scope=files --scope=dwhdb --file=_file_name_ --log=_log_file_name_ --provision-dwh-db --restore-permissions
Теперь база данных Data Warehouse и Менеджер управления размещаются на разных машинах. После успешного восстановления базы данных Data Warehouse система предложит выполнить команду engine-setup. Перед выполнением этой команды перенесите службу Data Warehouse.
2.2.2. Перенос службы Data Warehouse на отдельную машину
Службу Data Warehouse (ovirt-engine-dwhd), установленную и настроенную в Менеджере управления, можно перенести на отдельную машину. Размещение службы Data Warehouse на отдельной машине помогает снизить нагрузку на машину с Менеджером управления.
Обратите внимание, что эта процедура переносит только службу Data Warehouse. Информацию о том, как перенести базу данных Data Warehouse (ovirt_engine_history) перед переносом службы Data Warehouse, см. в разделе Перенос базы данных Data Warehouse на отдельную машину.
-
На одной машине должны быть установлены и настроены Менеджер управления и Хранилище Data Warehouse.
-
Чтобы настроить новую машину с Хранилищем Data Warehouse, нужно иметь:
-
Пароль из файла /etc/ovirt-engine/engine.conf.d/10-setup-database.conf Менеджера управления.
-
Разрешенный доступ с машины с Хранилищем Data Warehouse к TCP-порту 5432 машины с базой данных Менеджера управления.
-
Имя пользователя и пароль для базы данных Data Warehouse из файла /etc/ovirt-engine-dwh/ovirt-engine-dwhd.conf.d/10-setup-database.conf Менеджера управления.
-
Если перенос базы данных ovirt_engine_history выполнялся с использованием процедур, описанных в разделе Перенос базы данных Data Warehouse на отдельную машину, то резервная копия включает в себя эти учетные данные, заданные во время настройки базы данных на этой машине.
Для установки этого сценария выполните следующие шаги:
-
Остановка службы Data Warehouse на машине с Менеджером управления
-
Настройка новой машины со службой Data Warehouse
-
Отключение пакета Хранилища Data Warehouse на машине с Менеджером управления.
2.2.2.1. Остановка службы Data Warehouse на машине с Менеджером управления
-
Остановите службу Data Warehouse:
# systemctl stop ovirt-engine-dwhd.service -
Если база данных размещена на удаленной машине, предоставьте доступ вручную, изменив файл postgres.conf. Измените файл /var/lib/pgsql/data/postgresql.conf и скорректируйте строку
listen_addresses, чтобы она выглядела так:listen_addresses = '*'Если этой строки нет или она закомментирована, то добавьте ее вручную.
Если база данных размещена на машине с Менеджером управления и была настроена во время чистой установки Менеджера управления, то доступ предоставляется по умолчанию.
-
Перезапустите службу postgresql:
# systemctl restart postgresql
2.2.2.2. Настройка новой машины со службой Data Warehouse
Порядок опций или настроек, описанных в этом разделе, может отличаться в зависимости от вашей среды.
-
В случае переноса базы данных ovirt_engine_history и службы Data Warehouse на одну и ту же машину выполните перечисленные ниже действия, в противном случае перейдите к следующему шагу.
# sed -i '/^ENGINE_DB_/d' \ /etc/ovirt-engine-dwh/ovirt-engine-dwhd.conf.d/10-setup-database.conf # sed -i \ -e 's;^\(OVESETUP_ENGINE_CORE/enable=bool\):True;\1:False;' \ -e '/^OVESETUP_CONFIG\/fqdn/d' \ /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf # sed -i 's/localhost/<mgr-fqdn>/' \ /etc/ovirt-engine/engine.conf.d/10-setup-database.confгде,
<mgr-fqdn>- FQDN машины с менеджером управления -
Выполните команду
engine-setup, чтобы начать настройку Хранилища Data Warehouse на машине:# engine-setup -
Нажмите Enter, чтобы принять автоматически обнаруженное имя хоста, либо введите альтернативное имя хоста и нажмите Enter:
Host fully qualified DNS name of this server [_autodetected host name_]: -
Нажмите Enter, чтобы автоматически настроить межсетевой экран, либо напечатайте No и нажмите Enter, чтобы сохранить текущие настройки:
Setup can automatically configure the firewall on this system. Note: automatic configuration of the firewall may overwrite current settings. Do you want Setup to configure the firewall? (Yes, No) [Yes]:Если будет выбрана автоматическая настройка межсетевого экрана и ни один менеджер межсетевого экрана не активен, то система предложит выбрать предпочтительный менеджер межсетевого экрана из списка поддерживаемых вариантов. Напечатайте имя менеджера межсетевого экрана и нажмите Enter. Это применимо, даже если список содержит всего один элемент.
-
Введите FQDN и пароль для Менеджера управления. Нажмите Enter, чтобы принять значения по умолчанию в каждом из остальных полей:
Host fully qualified DNS name of the engine server []: _engine-fqdn_ Setup needs to do some actions on the remote engine server. Either automatically, using ssh as root to access it, or you will be prompted to manually perform each such action. Please choose one of the following: 1 - Access remote engine server using ssh as root 2 - Perform each action manually, use files to copy content around (1, 2) [1]: ssh port on remote engine server [22]: root password on remote engine server _engine-fqdn_: _password_ -
Введите FQDN и пароль для машины с базой данных Менеджера управления. Нажмите Enter, чтобы принять значения по умолчанию в каждом из остальных полей:
Engine database host []: _manager-db-fqdn_ Engine database port [5432]: Engine database secured connection (Yes, No) [No]: Engine database name [engine]: Engine database user [engine]: Engine database password: _password_ -
Подтвердите настройки, с которыми будет выполняться установка:
Please confirm installation settings (OK, Cancel) [OK]:
Теперь служба Data Warehouse настроена на удаленной машине. Далее отключите службу Data Warehouse на машине с Менеджером управления.
2.2.2.3. Отключение службы Хранилища Data Warehouse на машине с Менеджером управления
-
Перезапустите Менеджер управления на машине с Менеджером управления:
# service ovirt-engine restart -
Выполните следующую команду, чтобы изменить файл /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf и установить параметры в значение
False:# sed -i \ -e 's;^\(OVESETUP_DWH_CORE/enable=bool\):True;\1:False;' \ -e 's;^\(OVESETUP_DWH_CONFIG/remoteEngineConfigured=bool\):True;\1:False;' \ /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf # sed -i \ -e 's;^\(OVESETUP_GRAFANA_CORE/enable=bool\):True;\1:False;' \ /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf -
Отключите службу Data Warehouse:
# systemctl disable ovirt-engine-dwhd.service -
Удалите файлы Хранилища Data Warehouse:
# rm -f /etc/ovirt-engine-dwh/ovirt-engine-dwhd.conf.d/*.conf /var/lib/ovirt-engine-dwh/backups/*
Теперь служба Хранилища (DWH) и Менеджер управления размещаются на разных машинах.
2.3. Резервное копирование и восстановление виртуальных машин с помощью Резервного домена хранения (Backup Storage Domain)
2.3.1. Описание Резервного домена хранения
Резервный домен хранения – это домен, который можно использовать специально для хранения и миграции виртуальных машин и шаблонов виртуальных машин с целью резервного копирования и восстановления в случае аварии, миграции и т.д. Резервный домен отличается от нерезервного тем, что все виртуальные машины в нем находятся в выключенном состоянии. Виртуальная машина не может работать в резервном домене.
Любой домен хранения данных можно задать в качестве резервного домена. Чтобы включить/выключите эту настройку, установите/снимите флажок "Резервная копия (Backup)" в диалоговом окне "Управление доменом (Manage Domain)". Эту настройку можно включить только после остановки всех виртуальных машин в этом домене хранения.
Невозможно запустить виртуальную машину, хранящуюся в резервном домене. Менеджер управления блокирует эту и любую другую операцию, которая может сделать резервную копию недействительной. Однако можно запустить виртуальную машину на основе шаблона, хранящегося в резервном домене, если диски этой виртуальной машины не являются частью резервного домена. Как и в случае с другими типами доменов хранения, резервные домены можно подключать к центру данных и отключать от него. Таким образом, помимо хранения резервных копий, резервные домены можно использовать для переноса виртуальных машин между центрами данных.
- Преимущества
-
Вот несколько причин использовать резервный домен, а не домен экспорта:
-
В центре данных может быть несколько резервных доменов хранения, но лишь один домен экспорта.
-
Можно выделить резервный домен хранения для резервного копирования и аварийного восстановления.
-
Можно перенести резервную копию виртуальной машины, шаблона или моментального снимка в резервный домен хранения.
-
С резервными доменами миграция большого количества виртуальных машин, шаблонов или файлов OVF выполняется значительно быстрее, чем с доменами экспорта.
-
Резервный домен использует дисковое пространство эффективнее, чем домен экспорта.
-
Резервные домены поддерживают как файловое хранилище (NFS, Gluster), так и блочное (Fiber Channel и iSCSI) – в отличие от доменов экспорта, поддерживающих только файловое.
-
Настройку "Резервная копия (Backup)" для домена хранения можно динамически включать и выключать с учетом ограничений.
-
- Ограничения
-
-
У любой виртуальной машины или шаблона в резервном домене (backup) все диски должны быть в этом же домене.
-
Все виртуальные машины в домене хранения должны быть выключены, прежде чем его можно будет сделать резервным доменом.
-
Невозможно запустить виртуальную машину, хранящуюся в резервном домене, потому что это может привести к изменению данных на диске.
-
Резервный домен не может быть целевым доменом томов памяти (memory volumes), поскольку тома памяти поддерживаются только для активных виртуальных машин.
-
Предварительный просмотр виртуальной машины в резервном домене невозможен.
-
Перенос виртуальной машины "на лету" в резервный домен невозможен.
-
Невозможно задать резервный домен в качестве мастер-домена.
-
Невозможно задать домен hosted engine в качестве резервного домена.
-
Не используйте домен хранения по умолчанию в качестве резервного домена.
-
2.3.2. Установка домена хранения данных в качестве резервного домена.
-
Все диски, принадлежащие виртуальной машине или шаблону в домене хранения, должны находиться в одном и том же домене.
-
Все виртуальные машины в домене должны быть выключены.
-
На Портале администрирования нажмите .
-
Создайте новый домен хранения или выберите существующий домен хранения и нажмите Управление доменом (Manage Domain). Откроется диалоговое окно "Управление доменом (Manage Domains).
-
В блоке Дополнительные параметры (Advanced Parameters) установите флажок "Резервная копия (Backup)".
Теперь домен стал резервным доменом.
2.3.3. Резервное копирование или восстановление виртуальной машины или моментального снимка с использованием резервного домена
Можно выполнить резервное копирование выключенной виртуальной машины или моментального снимка. Затем можно сохранить резервную копию в том же центре данных и восстановиться с нее при необходимости либо перенести ее в другой центр данных.
2.3.3.1. Резервное копирование виртуальной машины
-
Создайте резервный домен. См. раздел Установка домена хранения данных в качестве резервного домена.
-
Создайте новую виртуальную машину на базе виртуальной машины, резервную копию которой вы хотите сделать:
-
Чтобы сделать резервную копию снимка, сначала создайте из него виртуальную машину. См. раздел Создание виртуальной машины из моментального снимка Руководства по управлению виртуальными машинами.
-
Чтобы сделать резервную копию виртуальной машины, сначала клонируйте ее. См. раздел Клонирование виртуальной машины Руководства по управлению виртуальными машинами. Прежде чем продолжить, убедитесь, что клон выключен.
-
-
Экспортируйте новую виртуальную машину в резервный домен. См. раздел Экспортирование виртуальной машины в домен данных Руководства по управлению виртуальными машинами.
2.3.3.2. Восстановление виртуальной машины
-
Убедитесь, что резервный домен хранения, в котором хранится резервная копия виртуальной машины, подключен к центру данных.
-
Импортируйте виртуальную машину из резервного домена. См. раздел Импортирование виртуальной машины из домена данных Руководства по управлению виртуальными машинами.
2.4. Резервное копирование и восстановление виртуальных машин с помощью API резервного копирования и восстановления
2.4.1. API резервного копирования и восстановления
API резервного копирования и восстановления – это набор функций, которые позволяют выполнять полное или пофайловое резервное копирование и восстановление виртуальных машин. API сочетает в себе ряд компонентов zVirt (таких как создаваемые на лету снимки и REST API) для создания и использования временных томов, которые можно подключить к виртуальной машине, содержащей ПО резервного копирования, предоставленное независимым поставщиком ПО.
Информацию о поддерживаемых сторонних вендорах ПО резервного копирования см. на официальном сайте в разделе Совместимое ПО и оборудование.
2.4.2. Резервное копирование виртуальной машины
Используйте API резервного копирования и восстановления для создания резервной копии виртуальной машины. Эта процедура предполагает, что у вас есть две виртуальные машины:
-
виртуальная машина, резервную копию которой нужно сделать
-
резервирующая виртуальная машина - виртуальная машина, на которой установлено ПО для управления резервным копированием
-
Используя REST API, создайте снимок виртуальной машины, резервную копию которой нужно сделать:
POST /api/vms/`_{vm:id}_`/snapshots/ HTTP/1.1 (1) Accept: application/xml Content-type: application/xml <snapshot> <description>BACKUP</description> </snapshot>1 Замените {vm:id}идентификатором виртуальной машины, снимок которой вы делаете. Этот идентификатор можно посмотреть на вкладке Общие (General) окон Создать виртуальную машину (New Virtual Machine) и Изменить виртуальную машину (Edit Virtual Machine) на Портале администрирования и Пользовательским портале.При создании снимка виртуальной машины данные ее текущей конфигурации помещаются в атрибут data атрибута configuration блока initialization, расположенного под снимком. Невозможно делать снимки дисков, помеченных как общие или основанных на дисках Direct LUN. -
Получите данные конфигурации виртуальной машины из атрибута data соответствующего снимка:
GET /api/vms/`_{vm:id}_`/snapshots/`_{snapshot:id}_` HTTP/1.1 (1) (2) All-Content: true Accept: application/xml Content-type: application/xml1 Замените {vm:id}идентификатором виртуальной машины, снимок которой вы сделали ранее.2 Замените {snapshot:id}идентификатором снимка.Добавьте заголовок All-Content: true, чтобы получить дополнительные данные OVF в ответе. Данные OVF в XML-ответе находятся в элементе конфигурации виртуальной машины<initialization><configuration>. Позже вы будете использовать эти данные для восстановления виртуальной машины. -
Получите идентификатор снимка:
GET /api/vms/{vm:id}/snapshots/ HTTP/1.1 Accept: application/xml Content-type: application/xml -
Определите соответствующий снимку идентификатор диска:
GET /api/vms/`_{vm:id}_`/snapshots/`_{snapshot:id}_`/disks HTTP/1.1 Accept: application/xml Content-type: application/xml -
Подключите к резервирующей виртуальной машине снимок как активный диск, используя корректный тип интерфейса (например, virtio_scsi):
POST /api/vms/`_{vm:id}_`/diskattachments/ HTTP/1.1 (1) Accept: application/xml Content-type: application/xml <disk_attachment> <active>true</active> <interface>_virtio_scsi_</interface> <disk id="_{disk:id}_"> (2) <snapshot id="_{snapshot:id}_"/> (3) </disk> </disk_attachment>1 Замените {vm:id}идентификатором резервирующей виртуальной машины, а не той виртуальной машины, снимок которой вы сделали ранее.2 Замените {disk:id}идентификатором диска.3 Замените {snapshot:id}идентификатором снимка. -
Используйте ПО резервного копирования на резервирующей виртуальной машине для резервного копирования данных со снимка, подключенного как диск.
-
Отключите снимок, подключенный как диск, от резервирующей виртуальной машины:
DELETE /api/vms/`_{vm:id}_`/diskattachments/`_{snapshot:id}_` HTTP/1.1 (1) (2) Accept: application/xml Content-type: application/xml1 Замените {vm:id}идентификатором резервирующей виртуальной машины, а не той виртуальной машины, снимок которой вы сделали ранее.2 Замените {snapshot:id}идентификатором снимка. -
При желании удалите снимок:
DELETE /api/vms/`_{vm:id}_`/snapshots/`_{snapshot:id}_` HTTP/1.1 (1) (2) Accept: application/xml Content-type: application/xml1 Замените {vm:id}идентификатором виртуальной машины, снимок которой вы сделали ранее.2 Замените {snapshot:id}идентификатором снимка.
Вы создали резервную копию состояния виртуальной машины в фиксированный момент времени с помощью ПО резервного копирования, установленного на отдельной виртуальной машине.
2.4.3. Восстановление виртуальной машины
Чтобы восстановить виртуальную машину, для которой была создана резервная копия, используйте API резервного копирования и восстановления. Эта процедура предполагает, что у вас есть резервирующая виртуальная машина, на которой установлено ПО, управлявшее предыдущей резервной копией.
-
На Портале администрирования создайте плавающий диск, на который нужно восстановить ВМ из резервной копии. Подробную информацию о порядке создания плавающего диска см. в разделе Создание виртуального диска.
-
Подключите диск к резервирующей виртуальной машине:
POST /api/vms/`_{vm:id}_`/disks/ HTTP/1.1 (1) Accept: application/xml Content-type: application/xml <disk id="_{disk:id}_"> (2) </disk>1 Замените {vm:id}на идентификатор (ID) резервирующей виртуальной машины, а не виртуальной машины, снимок которой вы сделали ранее.2 Замените {disk:id}на идентификатор диска, который вы получили во время резервного копирования виртуальной машины. -
Чтобы восстановить виртуальную машину из резервной копии на диск, используйте программу резервного копирования.
-
Отключите диск от резервирующей виртуальной машины
DELETE /api/vms/`_{vm:id}_`/disks/_{disk:id}_ HTTP/1.1 (1) (2) Accept: application/xml Content-type: application/xml <action> <detach>true</detach> </action>1 Замените {vm:id}на идентификатор (ID) резервирующей виртуальной машины, а не виртуальной машины, снимок которой вы сделали ранее.2 Замените {disk:id}на идентификатор диска. -
Создайте новую виртуальную машину, используя данные конфигурации восстанавливаемой виртуальной машины:
POST /api/vms/ HTTP/1.1 Accept: application/xml Content-type: application/xml <vm> <cluster> <name>cluster_name</name> </cluster> <name>_NAME_</name> <initialization> <configuration> <data> <!-- omitting long ovf data --> </data> <type>ovf</type> </configuration> </initialization> ... </vm>Чтобы при создании виртуальной машины переопределить любое из значений в ovf, переопределите элемент до или после элемента initialization. Не внутри элемента инициализации. -
Подключите диск к новой виртуальной машине:
POST /api/vms/`_{vm:id}_`/disks/ HTTP/1.1 (1) Accept: application/xml Content-type: application/xml <disk id="_{disk:id}_"> (2) </disk>1 Замените {vm:id}на идентификатор новой виртуальной машины[.underline], а не виртуальной машины, снимок которой вы сделали ранее.2 Замените {disk:id}на идентификатор диска.
Вы восстановили виртуальную машину из резервной копии, созданной с помощью API резервного копирования и восстановления.
2.5. Резервное копирование и восстановление виртуальных машин с помощью API инкрементного резервного копирования и восстановления
zVirt предоставляет API инкрементного резервного копирования, который можно использовать для создания полных резервных копий виртуальных дисков форматов QCOW2 или RAW или инкрементных резервных копий виртуальных дисков формата QCOW2 без создания каких-либо временных снимков. Резервные копии данных создаются в формате RAW независимо от того, в каком формате созданы резервные копии виртуального диска - QCOW2 или RAW. Можно восстанавливать гостевые данные формата RAW и диски формата RAW или QCOW2. API инкрементного резервного копирования входит в состав zVirt REST API. Можно создавать резервные копии как работающих, так и неработающих виртуальных машин.
Как разработчик, вы можете использовать API для разработки приложения резервного копирования.
- Особенности
-
Резервное копирование выполняется проще, быстрее и надежнее, чем при использовании API резервного копирования и восстановления. API инкрементного резервного копирования обеспечивает улучшенную интеграцию с приложениями резервного копирования; в него добавлена поддержка резервного копирования и восстановления гостевых данных формата RAW независимо от формата базового диска.
Если некорректная карта битов вызывает сбой резервного копирования, то можно удалить конкретную контрольную точку в цепочке резервного копирования. Запускать полное резервное копирование не нужно.
- Ограничения
-
-
Инкрементное резервное копирование можно выполнять только для дисков формата QCOW2, а не RAW. В процессе резервного копирования резервные копии данных сохраняются в формате RAW.
-
Данные можно восстановить только из резервных копий формата RAW.
-
Инкрементное восстановление не поддерживает восстановление снимков, существовавших на момент резервного копирования. При инкрементном восстановлении восстанавливаются только данные, а не структура томов или образов в снимках, существовавших на момент резервного копирования. Это ограничение обычно присутствует в решениях резервного копирования для других систем.
-
Обычно в решениях резервного копирования при инкрементном восстановлении восстанавливаются только данные, а не структура томов или образов в снимках, существовавших на момент резервного копирования.
-
Некорректное завершение работы виртуальной машины по любой причине может испортить карты битов на диске, что повредит всю цепочку резервного копирования. Восстановление из инкрементной резервной копии с помощью некорректной карты битов приведет к повреждению данных виртуальной машины.
-
Некорректную карту битов можно обнаружить только при запуске резервного копирования. Если на диске есть какие-либо поврежденные карты битов, то операция завершится ошибкой.
В следующей таблице описаны конфигурации дисков, поддерживающие инкрементное резервное копирование.
| При создании диска с помощью Портала администрирования вы задаете тип хранилища, тип предоставления дискового пространства, а также указываете, включено или отключено инкрементное резервное копирование. На основе этих настроек Менеджер управления определяет формат виртуального диска. |
| Тип хранилища | Политика выделения дискового пространства | Статус инкрементного резервного копирования | Формат виртуального диска |
|---|---|---|---|
блочное |
динамическое |
включено |
qcow2 |
блочное |
предварительно размеченное |
включено |
qcow2 (предварительно размеченный) |
файловое |
динамическое |
включено |
qcow2 |
файловое |
предварительно размеченное |
включено |
qcow2 (предварительно размеченный) |
блочное |
динамическое |
отключено |
qcow2 |
блочное |
предварительно размеченное |
отключено |
raw (предварительно размеченный) |
файловое |
динамическое |
отключено |
raw (динамически расширяемое) |
файловое |
предварительно размеченное |
отключено |
raw (предварительно размеченный) |
сеть |
Не применимо |
отключено |
raw |
lun |
Не применимо |
отключено |
raw |
2.5.1. Процесс инкрементного резервного копирования
Для резервного копирования дисков виртуальных машин, для которых уже включено инкрементное резервное копирование, приложение резервного копирования, использующее API инкрементного резервного копирования, должно соблюдать следующую последовательность:
-
Приложение резервного копирования использует REST API для поиска дисков виртуальной машины, которые нужно добавить в резервную копию. Добавляются только диски формата QCOW2.
-
Приложение резервного копирования запускает полное резервное копирование или инкрементное резервное копирование. Вызов API указывает идентификатор виртуальной машины, необязательный идентификатор предыдущей контрольной точки и список дисков для резервного копирования. Если в вызове API не указан идентификатор предыдущей контрольной точки, то начинается полное резервное копирование, охватывающее все данные на указанных дисках, исходя из текущего состояния каждого диска.
-
Менеджер управления подготавливает виртуальную машину к резервному копированию. Во время резервного копирования виртуальная машина может продолжать работать.
-
Приложение резервного копирования запрашивает у Менеджера управления статус резервного копирования до тех пор, пока он не сообщит о готовности начать резервное копирование.
-
При готовности начать резервное копирование приложение резервного копирования создаст объект imagetransfer для каждого диска, включенного в резервную копию.
-
Приложение резервного копирования получает список измененных блоков от ovirt-imageio для каждой передачи образов. Если список изменений недоступен, то приложение резервного копирования выдаст ошибку.
-
Приложение резервного копирования загружает измененные блоки в формате RAW из ovirt-imageio и сохраняет их на резервном носителе. Если список измененных блоков недоступен, то приложение резервного копирования может откатиться к копированию всего диска.
-
Приложение резервного копирования завершает все передачи образов.
-
Приложение резервного копирования завершает резервное копирование с помощью REST API.
2.5.2. Процесс инкрементного восстановления
Приложение резервного копирования, использующее API инкрементного резервного копирования, должно соблюдать следующую последовательность действий для восстановления дисков виртуальных машин, для которых были созданы резервные копии:
-
С помощью приложения резервного копирования пользователь выбирает точку восстановления, исходя из доступных резервных копий.
-
Приложение резервного копирования создает новый диск или снимок существующего диска для хранения восстановленных данных.
-
Приложение резервного копирования запускает передачу выгружаемого образа для каждого диска, задав для параметра
formatзначениеraw. Это позволяет конвертировать формат при выгрузке данных формата RAW на диск формата QCOW2. -
Приложение резервного копирования передает данные, включенные в эту точку восстановления, в imageio с помощью API.
-
Приложение резервного копирования завершает передачи образов.
2.5.3. Задачи, связанные с API инкрементного резервного копирования и восстановления
API инкрементного резервного копирования и восстановления описан в руководстве по REST API
Процесс резервного копирования и восстановления предусматривает выполнение следующих действий:
-
Включение инкрементного резервного копирования либо на новом, либо на существующем виртуальном диске:
-
На новом диске с помощью Портала администрирования
-
На существующем диске с помощью Портала администрирования
-
На новом или существующем диске с помощью вызова API
-
-
Поиск дисков, для которых включено инкрементное резервное копирование
-
Запуск полного резервного копирования
-
Запуск инкрементного резервного копирования
-
Завершение резервного копирования
-
Получение информации о резервной копии
-
Получение информации о дисках в резервной копии
-
Составление списка всех контрольных точек для виртуальной машины
-
Выдача информации по конкретной контрольной точке для виртуальной машины
-
Удаление контрольной точки конкретной виртуальной машины
-
Загрузка объекта imagetransfer для архивирования резервной копии
-
Выгрузка объекта imagetransfer для восстановления из резервной копии
-
Составление списка измененных блоков
-
Загрузка и выгрузка измененных блоков
2.5.3.1. Включение инкрементного резервного копирования на новом виртуальном диске
Включите инкрементное резервное копирование для виртуального диска, чтобы пометить, что он входит в состав инкрементного резервного копирования. При добавлении диска можно включить инкрементное резервное копирование для каждого диска либо с помощью REST API, либо на Портале администрирования. Создавать резервные копии существующих дисков, для которых не включено инкрементное резервное копирование, можно с помощью полного резервного копирования или так, как описано в разделах Резервное копирование и восстановление виртуальных машин с помощью Резервного домена хранения и Резервное копирование и восстановление виртуальных машин с помощью API резервного копирования и восстановления.
| Менеджер управления может добавить диск в инкрементное резервное копирование, даже если оно не включено на диске, но его можно включить, чтобы отслеживать, на каких дисков оно включено. |
Поскольку для инкрементного резервного копирования требуются диски в формате QCOW2, используйте QCOW2 вместо RAW.
-
Добавьте новый виртуальный диск. Дополнительную информацию см. в разделе Создание виртуального диска.
-
При настройке параметров диска установите флажок Включить инкрементное резервное копирование (Enable Incremental Backup).
- Дополнительные ресурсы
2.5.3.2. Включение инкрементного резервного копирования на существующем виртуальном диске формата RAW
Поскольку инкрементное резервное копирование не поддерживается для дисков в формате RAW, для его использования на всех дисках формата RAW поверх должен существовать слой формата QCOW2. При создании снимка создается слой QCOW2, делающий возможным инкрементное резервное копирование на все диски, включенные в снимок, с точки, в которой создается снимок.
| Если на базовом слое диска используется формат RAW, то удаление последнего снимка и объединение верхнего слоя QCOW2 с базовым слоем преобразует диск в формат RAW, тем самым отключая инкрементное резервное копирование, если оно было установлено. Чтобы снова включить инкрементное резервное копирование, можно создать новый снимок, включающий в себя этот диск. |
-
На Портале администрирования нажмите .
-
Выберите виртуальную машину и откройте вкладку Диски (Disks).
-
Нажмите Изменить (Edit). Откроется диалоговое окно Изменить виртуальный диск (Edit Virtual Disk).
-
Установите флажок Включить инкрементное резервное копирование (Enable Incremental Backup).
- Дополнительные ресурсы
2.5.3.3. Включение инкрементного резервного копирования с помощью API
Вы можете использовать запрос по REST API, чтобы включить инкрементное резервное копирование для диска виртуальной машины.
-
Включите инкрементное резервное копирование для нового диска. Например, для нового диска на виртуальной машине с идентификатором
123отправьте запрос:POST /ovirt-engine/api/vms/123/diskattachmentsТело этого запроса должно включать в себя параметр
backup, установленный в значениеincremental, в составе объектаdisk, как показано ниже:<disk_attachment> ... <disk> ... <backup>incremental</backup> ... </disk> </disk_attachment>Ответ:
<disk_attachment> ... <disk href="/ovirt-engine/api/disks/456" id="456"/> ... </disk_attachment>- Дополнительные ресурсы
-
Раздел DiskBackup enum в руководстве REST API
2.5.3.4. Поиск дисков, на которых включено инкрементное резервное копирование
Для указанной виртуальной машины можно вывести список дисков, на которых включено инкрементное резервное копирование, отфильтрованных по свойству резервного копирования.
-
Выведите список дисков, подключенных к виртуальной машине. Например, для виртуальной машины с идентификатором
123отправьте запрос:GET /ovirt-engine/api/vms/123/diskattachmentsОтвет включает в себя все объекты
disk_attachment, каждый из которых включает в себя один или несколько объектовdisk. Например:<disk_attachments> <disk_attachment> ... <disk href="/ovirt-engine/api/disks/456" id="456"/> ... </disk_attachment> ... </disk_attachments> -
Используйте службу disk, чтобы просмотреть свойства диска из предыдущего шага. Например, для диска с идентификатором
456отправьте запрос:GET /ovirt-engine/api/disks/456Ответ включает в себя все свойства для диска. Параметр
backupустановлен в значениеnoneилиincremental. Например:<disk href="/ovirt-engine/api/disks/456" id="456"> ... <backup>incremental</backup> ... </disk>- Дополнительные ресурсы
-
-
Атрибут backup раздела Disk struct в руководстве REST API
-
Раздел DiskBackup enum в руководстве REST API
-
2.5.3.5. Запуск полного резервного копирования с помощью API
После полного резервного копирования можно использовать полученный идентификатор контрольной точки в качестве начальной точки для следующего инкрементного резервного копирования.
При резервном копировании работающей виртуальной машины процесс создает временный диск в том же домене хранения, в котором находится копируемый диск. Процесс резервного копирования создает этот диск, чтобы сделать возможной запись новых данных на работающую виртуальную машину во время резервного копирования. Этот временный диск можно увидеть на Портале администрирования во время резервного копирования. По завершении резервного копирования он автоматически удаляется.
Запуск полного резервного копирования требует вызова запроса с телом и включает в себя ответ.
-
Отправьте запрос с указанием виртуальной машины, с которой нужно снять резервную копию. Например, укажите виртуальную машину с идентификатором
123следующим образом:POST /ovirt-engine/api/vms/123/backups -
В теле запроса укажите диск, с которого нужно снять резервную копию. Например, чтобы запустить полное резервное копирование диска с идентификатором
456, отправьте запрос со следующим телом:<backup> <disks> <disk id="456" /> ... </disks> </backup>Тело ответа должно выглядеть примерно так:
<backup id="789"> <disks> <disk id="456" /> ... ... </disks> <status>initializing</status> <creation_date> </backup>Ответ включает в себя:
-
Идентификатор резервной копии
-
Статус резервной копии, указывающий, что она инициализируется.
-
-
Опрос резервной копии до появления статуса
ready(готова). Ответ включает в себя идентификатор конечной контрольной точки (to_checkpoint_id). Обратите внимание на этот идентификатор и используйте его для задания начальной контрольной точки (from_checkpoint_id) при следующем инкрементном резервном копировании.- Дополнительные ресурсы
-
-
Метод
addслужбы VmBackups в руководстве REST API
-
2.5.3.6. Запуск инкрементного резервного копирования с помощью API
После завершения полного резервного копирования данного виртуального диска последующие инкрементные резервные копии этого диска будут содержать только изменения, внесенные с момента последнего резервного копирования. Используйте значение идентификатора конечной контрольной точки (to_checkpoint_id) из последней резервной копии в качестве значения для идентификатора начальной контрольной точки (from_checkpoint_id) в теле запроса.
При резервном копировании работающей виртуальной машины процесс создает временный диск в том же домене хранения, в котором находится копируемый диск. Процесс резервного копирования создает этот диск, чтобы сделать возможной запись новых данных на работающую виртуальную машину во время резервного копирования. Этот временный диск можно увидеть на Портале администрирования во время резервного копирования. По завершении резервного копирования он автоматически удаляется.
Запуск инкрементного или смешанного резервного копирования требует вызова запроса с телом и включает в себя ответ.
-
Отправьте запрос с указанием виртуальной машины, с которой нужно снять резервную копию. Например, укажите виртуальную машину с идентификатором
123следующим образом:POST /ovirt-engine/api/vms/123/backups -
В теле запроса укажите диск, с которого нужно снять резервную копию. Например, чтобы запустить инкрементное резервное копирование диска с идентификатором
456, отправьте запрос со следующим телом:<backup> <from_checkpoint_id>__previous-checkpoint-uuid__</from_checkpoint_id> <disks> <disk id="456" /> ... </disks> </backup>Если в тело запроса включить диск, не включенный в предыдущую контрольную точку, то запрос также запустит полное резервное копирование этого диска. Пусть, например, с диска с идентификатором 789 резервная копия еще не снималась. Чтобы добавить полное резервное копирование диска 789 к вышеприведенному телу запроса, отправьте тело запроса следующего вида:
<backup> <from_checkpoint_id>__previous-checkpoint-uuid__</from_checkpoint_id> <disks> <disk id="456" /> <disk id="789" /> ... </disks> </backup>Тело ответа должно выглядеть примерно так:
<backup id="101112"> <from_checkpoint_id>__previous-checkpoint-uuid__</from_checkpoint_id> <to_checkpoint_id>__new-checkpoint-uuid__</to_checkpoint_id> <disks> <disk id="456" /> <disk id="789" /> ... ... </disks> <status>initializing</status> <creation_date> </backup>Ответ включает в себя:
-
Идентификатор резервной копии.
-
Идентификатор любого диска, который был включен в резервную копию.
-
Статус, указывающий, что резервная копия инициализируется.
-
-
Опрос резервной копии до появления статуса
ready(готова). Ответ включает в себя идентификатор конечной контрольной точки (to_checkpoint_id). Обратите внимание на этот идентификатор и используйте его для задания начальной контрольной точки (from_checkpoint_id) при следующем инкрементном резервном копировании.- Дополнительные ресурсы
-
-
Метод
addслужбы VmBackups в руководстве REST API
-
2.5.3.7. Получение информации о резервной копии с помощью API
Можно получить информацию о резервной копии, которую можно использовать для запуска нового инкрементного резервного копирования.
Метод list службы VmBackups возвращает следующую информацию о резервной копии:
-
идентификатор каждого диска, с которого была снята резервная копия
-
идентификаторы начальной и конечной контрольных точек резервного копирования
-
идентификатор образа диска в резервной копии, для каждого диска, включенного в процесс резервного копирования
-
статус резервной копии
-
дату создания резервной копии
Когда параметр <status> имеет значение ready (готова), ответ включает в себя идентификатор конечной контрольной точки (to_checkpoint_id), который следует использовать в качестве идентификатора начальной контрольной точки (from_checkpoint_id) при следующем инкрементном резервном копировании, и можно начать загрузку дисков, чтобы выполнить резервное копирование хранилища виртуальной машины.
-
Чтобы получить информацию о резервной копии с идентификатором
456виртуальной машины с идентификатором123, отправьте запрос следующего вида:GET /ovirt-engine/api/vms/456/backups/123Ответ включает в себя резервную копию с идентификатором
456с идентификатором начальной контрольной точки (from_checkpoint_id)999и идентификатором конечной контрольной точки (to_checkpoint_id)666. Диски, включенные в резервную копию, указаны в элементе<link>.<backup id="456"> <from_checkpoint_id>999</from_checkpoint_id> <to_checkpoint_id>666</to_checkpoint_id> <link href="/ovirt-engine/api/vms/456/backups/123/disks" rel="disks"/> <status>ready</status> <creation_date> </backup>- Дополнительные ресурсы
-
Метод
listслужбы VmBackups в руководстве REST API
2.5.3.8. Получение информации о дисках в резервной копии
Можно получить информацию о дисках, которые входят в состав резервной копии, включая режим резервного копирования, который использовался для каждого диска в резервной копии, что помогает определить режим, используемый для загрузки резервной копии.
Метод list службы VmBackupDisks возвращает следующую информацию о резервной копии:
-
Идентификатор и имя каждого диска, с которого была снята резервная копия.
-
Идентификатор образа диска в резервной копии, для каждого диска, включенного в процесс резервного копирования
-
Формат диска.
-
Режим резервного копирования, поддерживаемый диском.
-
Тип резервного копирования, использованный для диска (полное/инкрементное).
-
Чтобы получить информацию о резервной копии с идентификатором
456виртуальной машины с идентификатором123, отправьте запрос следующего вида:GET /ovirt-engine/api/vms/456/backups/123/disksОтвет включает в себя диск с идентификатором
789, а идентификатор образа диска –555.<disks> <disk id="789"> <name>vm1_Disk1</name> <actual_size>671744</actual_size> <backup>incremental</backup> <backup_mode>full</backup_mode> <format>cow</format> <image_id>555</image_id> <qcow_version>qcow2_v3</qcow_version> <status>locked</status> <storage_type>image</storage_type> <total_size>0</total_size> </disk> </disks>- Дополнительные ресурсы
-
Метод
listслужбы VmBackupDisks в руководстве REST API
2.5.3.9. Завершение резервного копирования
При завершении резервного копирования оканчивается процесс резервного копирования, разблокируются ресурсы и производится очистка. Используйте служебный метод резервного копирования finalize
-
Чтобы завершить резервное копирование диска с идентификатором
456на виртуальной машине с идентификатором123, отправьте запрос следующего вида:POST /vms/123/backups/456/finalize- Дополнительные ресурсы
-
finalize POST в руководстве REST API.
2.5.3.10. Создание объекта imagetransfer для инкрементного резервного копирования
Когда резервная копия готова к загрузке, приложение резервного копирования должно создать объект imagetransfer, который инициирует перенос инкрементной резервной копии.
Создание объекта imagetransfer требует вызова запроса с телом.
-
Отправьте запрос следующего вида:
POST /ovirt-engine/api/imagetransfers -
В теле запроса укажите следующие параметры:
-
идентификатор диска (
disk id) -
идентификатор резервной копии (
backup id) -
направление передачи для диска должно быть установлено в значение
download -
формат для диска установлен в значение
raw
Например, чтобы перенести резервную копию диска с идентификатором диска
123и идентификатором резервной копии456, отправьте следующее тело запроса:<image_transfer> <disk id="123"/> <backup id="456"/> <direction>download</direction> <format>raw</format> </image_transfer>- Дополнительные ресурсы
-
-
Метод
addдля создания объекта imagetransfer в руководстве REST API.
-
-
2.5.3.11. Создание объекта imagetransfer для инкрементного восстановления
Чтобы включить восстановление неформатированных (raw) данных из резервной копии с помощью API инкрементного резервного копирования на диск формата QCOW2, приложение резервного копирования должно создать объект imagetransfer.
Если формат переноса – raw, а формат базового диска – QCOW2, то выгружаемые данные на лету преобразуются в формат QCOW2 во время записи в хранилище. Выгрузка данных с диска QCOW2 на диск RAW не поддерживается.
Создание объекта imagetransfer требует вызова запроса с телом.
-
Отправьте запрос следующего вида:
POST /ovirt-engine/api/imagetransfers -
В теле запроса укажите следующие параметры:
-
идентификатор диска или идентификатор снимка
-
направление передачи для диска должно быть установлено в значение
upload -
формат для диска установлен в значение
raw
Например, чтобы перенести резервную копию диска с идентификатором диска
123, отправьте следующее тело запроса:<image_transfer> <disk id="123"/> <direction>upload</direction> <format>raw</format> </image_transfer>- Дополнительные ресурсы
-
-
Метод
addдля создания объекта imagetransfer в руководстве REST API.
-
-
2.5.3.12. Составление списка контрольных точек для виртуальной машины
Отправив запрос, можно получить список всех контрольных точек для виртуальной машины вместе с информацией о каждой контрольной точке.
-
Отправьте запрос с указанием виртуальной машины. Например, укажите виртуальную машину с идентификатором
123следующим образом:GET /vms/123/checkpoints/Ответ включает в себя все контрольные точки виртуальной машины. Каждая контрольная точка содержит следующую информацию:
-
Диски контрольной точки
-
Идентификатор родительской контрольной точки
-
Дата создания контрольной точки
-
Виртуальная машина, к которой она относится
Например:
<checkpoints> <checkpoint id="456"> <link href="/ovirt-engine/api/vms/vm-uuid/checkpoints/456/disks" rel="disks"/> <parent_id>parent-checkpoint-uuid</parent_id> <creation_date>xxx</creation_date> <vm href="/ovirt-engine/api/vms/123" id="123"/> </checkpoint> </checkpoints>- Дополнительные ресурсы
-
-
метод
listдля перечисления контрольных точек виртуальной машины в руководстве REST API.
2.5.3.13. Выдача информации о конкретной контрольной точке виртуальной машины
Можно получить информацию о конкретной контрольной точке виртуальной машины, отправив запрос.
-
Отправьте запрос с указанием виртуальной машины. Например, укажите виртуальную машину с идентификатором
123и идентификатором контрольной точки456как показано ниже:GET /vms/123/checkpoints/456В ответе будет дана следующая информация о контрольной точке:
-
Диски контрольной точки
-
Идентификатор родительской контрольной точки
-
Дата создания контрольной точки
-
Виртуальная машина, к которой она относится
Например:
<checkpoint id="456"> <link href="/ovirt-engine/api/vms/vm-uuid/checkpoints/456/disks" rel="disks"/> <parent_id>parent-checkpoint-uuid</parent_id> <creation_date>xxx</creation_date> <vm href="/ovirt-engine/api/vms/123" id="123"/> </checkpoint>- Дополнительные ресурсы
-
-
метод
listдля перечисления контрольных точек виртуальной машины в руководстве REST API.
2.5.3.14. Удаление контрольной точки
Можно удалить контрольную точку виртуальной машины, отправив запрос DELETE. Можно удалить контрольную точку виртуальной машины, независимо от того, работает ли ВМ или нет.
-
Отправьте запрос с указанием виртуальной машины и контрольной точки. Например, укажите виртуальную машину с идентификатором
123и контрольную точку с идентификатором456как показано ниже:DELETE /vms/123/checkpoints/456/- Дополнительные ресурсы
-
метод
removeслужбы VmCheckpoint в руководстве REST API.
2.5.3.15. Использование API imageio для передачи данных резервного копирования
API imagetransfer запускает и останавливает передачу образов. В результате появится URL-адрес передачи.
Используйте API imageio для фактической передачи данных из URL-адреса передачи.
| Запрос API (API request) | Описание |
|---|---|
|
Выводит параметры сервера, чтобы можно было узнать, какие функции поддерживает сервер. |
|
Выводит информацию о содержимом и выделении образа диска или о блоках, которые изменились во время инкрементного резервного копирования. Эта информация называется экстент (extent). |
|
Программа, выполняющая передачу образа, должна загрузить изменения из резервной копии. Эти изменения называются ожидающие записи экстенты (dirty extents). |
|
Приложение резервного копирования создает новый диск или снимок существующего диска для хранения восстановленных данных. |
3. Автоматизация задач конфигурирования с помощью Ansible
Ansible – это инструмент автоматизации, используемый для конфигурирования систем, развертывания программного обеспечения и непрерывных обновлений. В zVirt предусмотрена ограниченная версия Ansible для автоматизации задач zVirt после установки, таких как настройка и конфигурирование центра данных, управление пользователями и операции с виртуальными машинами.
Ansible предоставляет более простой метод автоматизации задач конфигурирования zVirt по сравнению с REST API и SDK, и его можно интегрировать с другими модулями Ansible.
Инструкции для альтернативных установок и информацию об использовании Ansible см. в Документации по Ansible.
Набор oVirt Ansible (oVirt Ansible Collection) предоставляет модули, роли и плагины для управления различными частями инфраструктуры zVirt. Модули используются для обеспечения связи между Ansible и Менеджером управления. Роли Ansible делают возможным метод модульного исполнения кода Ansible, разбивая большие плейбуки на более мелкие файлы для многократного использования, которые можно использовать совместно с другими пользователями.
Информацию по использованию Ansible для автоматизации работы zVirt смотрите в документе Введение в автоматизацию работы zVirt с помощью Ansible
4. Пользователи и роли
4.1. Общая информация о пользователях
В zVirt есть два типа пользовательских доменов: локальный и внешний. При установке Менеджера управления создаются локальный домен по умолчанию, называемый внутренним (internal) доменом, и пользователь по умолчанию – admin.
Во внутреннем (internal) домене можно создавать дополнительных пользователей с помощью программы ovirt-aaa-jdbc-tool. Учетные записи пользователей, созданные в локальных доменах, называются локальными пользователями. Кроме того, к среде zVirt можно подключить внешние серверы каталогов, такие как Red Hat Directory Server, Active Directory, OpenLDAP и другие поддерживаемые варианты, и использовать их в качестве внешних доменов. Учетные записи пользователей, созданные во внешних доменах, называются пользователями из каталогов.
И локальным пользователям, и пользователям из каталогов нужно назначить соответствующие роли и разрешения через Портал администрирования, прежде чем они смогут работать в среде. Есть два основных типа ролей пользователей: пользователь и администратор. Роль пользователя использует виртуальные ресурсы с Пользовательского портала и управляет ими. Роль администратора поддерживает инфраструктуру системы с помощью Портала администрирования. Роли могут назначаться пользователям применительно к отдельным ресурсам, таким как виртуальные машины и хосты, или применительно к иерархическим структурам объектов, таким как кластеры и центры данных.
4.2. Введение в серверы каталогов
Во время установки Менеджер управления создает пользователя admin во внутреннем (internal) домене. Этот пользователь также называется admin@internal. Эта учетная запись предназначена для использования при первоначальной настройке среды и устранении неполадок. После подключения внешнего сервера каталогов, добавления пользователей из каталогов и назначения им соответствующих ролей и разрешений пользователя admin@internal можно отключить, если он не нужен. Поддерживаются следующие серверы каталогов:
-
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
| Невозможно установить Менеджер управления и IdM (ipa-server) на одну систему. IdM несовместим с пакетом mod_ssl, который необходим Менеджеру управления. |
|
Если в качестве сервера каталогов используется Active Directory и для создания шаблонов и виртуальных машин нужно использовать sysprep, то управление доменом необходимо делегировать пользователю c правами администратора zVirt, чтобы тот мог:
|
4.3. Настройка внешнего провайдера LDAP
4.3.1. Настройка внешнего провайдера LDAP (интерактивная установка)
Расширение ovirt-engine-extension-aaa-ldap позволяет пользователям легко настраивать внешний каталог. Расширение ovirt-engine-extension-aaa-ldap поддерживает множество различных типов серверов LDAP, а для помощи в настройке большинства типов LDAP предоставляется интерактивный скрипт установки.
Если тип сервера LDAP не указан в интерактивном скрипте установки или нужна дополнительная настройка, можно вручную отредактировать файлы конфигурации. Дополнительную информацию см. в разделе Настройка внешнего провайдера LDAP (ручной метод).
Пример для Active Directory см. в инструкции Использование Active Directory в качестве внешней службы каталогов.
-
Нужно знать доменное имя DNS- или LDAP-сервера.
-
Чтобы установить безопасное соединение между LDAP-сервером и Менеджером управления, убедитесь, что подготовлен сертификат Центра сертификации в кодировке PEM.
-
Подготовьте хотя бы одну учетную запись (имя и пароль) для выполнения запросов на поиск и вход на LDAP-сервер.
-
В Менеджере управления установите пакет расширения LDAP:
# dnf install ovirt-engine-extension-aaa-ldap-setup -
Запустите
ovirt-engine-extension-aaa-ldap-setup, чтобы начать интерактивную установку:# ovirt-engine-extension-aaa-ldap-setup -
Выберите тип LDAP, введя соответствующий номер. Если вы не знаете точно, какая схема у вашего LDAP-сервера, выберите стандартную схему для вашего типа LDAP-сервера. Для Active Directory выполните процедуру, описанную в инструкции Использование Active Directory в качестве внешней службы каталогов.
Available LDAP implementations: 1 - 389ds 2 - 389ds RFC-2307 Schema 3 - Active Directory 4 - IBM Security Directory Server 5 - IBM Security Directory Server RFC-2307 Schema 6 - IPA 7 - Novell eDirectory RFC-2307 Schema 8 - OpenLDAP RFC-2307 Schema 9 - OpenLDAP Standard Schema 10 - Oracle Unified Directory RFC-2307 Schema 11 - RFC-2307 Schema (Generic) 12 - RHDS 13 - RHDS RFC-2307 Schema 14 - iPlanet Please select: -
Нажмите Enter, чтобы принять значение по умолчанию и настроить разрешение доменного имени для имени LDAP-сервера:
It is highly recommended to use DNS resolution for LDAP server. If for some reason you intend to use hosts or plain address disable DNS usage. Use DNS (Yes, No) [Yes]: -
Выберите метод политики DNS:
-
Вариант 1: DNS-серверы, перечисленные в /etc/resolv.conf, используются для разрешения IP-адреса. Убедитесь, что файл /etc/resolv.conf актуализирован и содержит корректные DNS-серверы.
-
Вариант 2: введите FQDN или IP-адрес LDAP-сервера. Чтобы узнать доменное имя, можно использовать команду
digс записью SRV. Запись SRV имеет следующий формат:
__service._protocol_._domain_name_Пример:
dig _ldap._tcp.example.com SRV-
Вариант 3: введите список LDAP-серверов через пробел. Используйте FQDN или IP-адреса серверов. Эта политика предусматривает балансировку нагрузки между LDAP-серверами. Запросы распределяются между всеми LDAP-серверами по циклическому алгоритму (round-robin).
-
Вариант 4: введите список LDAP-серверов через пробел. Используйте FQDN или IP-адреса серверов. Эта политика определяет первый LDAP-сервер как LDAP-сервер, по умолчанию отвечающий на запросы. Если первый сервер недоступен, запрос будет направлен на следующий LDAP-сервер в списке.
1 - Single server 2 - DNS domain LDAP SRV record 3 - Round-robin between multiple hosts 4 - Failover between multiple hosts Please select: -
-
Выберите метод безопасного подключения, поддерживаемый LDAP-сервером, и укажите метод получения сертификата Центра сертификации в кодировке PEM:
-
Fileпозволяет указать полный путь к сертификату. -
URLпозволяет указать URL-адрес для сертификата. -
Inlineпозволяет вставить содержимое сертификата в терминал. -
Systemпозволяет указать местоположение по умолчанию для всех файлов Центра сертификации. -
Insecureпропускает проверку сертификата, но соединение по-прежнему шифруется с помощью TLS.
NOTE: It is highly recommended to use secure protocol to access the LDAP server. Protocol startTLS is the standard recommended method to do so. Only in cases in which the startTLS is not supported, fallback to non standard ldaps protocol. Use plain for test environments only. Please select protocol to use (startTLS, ldaps, plain) [startTLS]: _startTLS_ Please select method to obtain PEM encoded CA certificate (File, URL, Inline, System, Insecure): Please enter the password:LDAPS расшифровывается как облегченный протокол доступа к каталогам по SSL. Для SSL-подключений выберите вариант ldaps. -
-
Введите отличительное имя (DN) пользователя, формирующего поисковые запросы. Пользователь должен иметь разрешения для просмотра всех пользователей и групп на сервере каталогов. Пользователь, формирующий поисковый запрос, должен быть указан в аннотации LDAP. Если разрешен анонимный поиск, нажмите Enter, не вводя ничего.
Enter search user DN (for example uid=username,dc=example,dc=com or leave empty for anonymous): `uid=user1,ou=Users,ou=department-1,dc=example,dc=com` Enter search user password: -
Введите базовое отличительное имя (DN):
Please enter base DN (dc=example,dc=com) [dc=example,dc=com]: _ou=department-1,dc=example,dc=com_ -
Выберите
Yes, если вы хотите настроить единый вход для виртуальных машин. Обратите внимание, что эту функцию нельзя использовать с единым входом на Портал администрирования. Скрипт напоминает, что имя профиля должно соотноситься с именем домена. Продолжайте следовать инструкциям в разделе Настройка единого входа (Single Sign-On) для виртуальных машин в руководстве по управлению виртуальными машинами.Are you going to use Single Sign-On for Virtual Machines (Yes, No) [Yes]: -
Укажите имя профиля. Имя профиля видно пользователям на странице входа. В этом примере использовано
example.com.Чтобы переименовать профиль после того, как домен был настроен, измените атрибут ovirt.engine.aaa.authn.profile.nameв файле /etc/ovirt-engine/extensions.d/example.com-authn.properties. Перезапустите службу ovirt-engine, чтобы изменение вступило в силу.Please specify profile name that will be visible to users: _example.com_Рисунок 1. Страница входа на Портал администрированияПользователи должны выбрать профиль из выпадающего списка при первом входе в систему. Информация хранится в файлах cookie браузера и заранее задается при следующем входе пользователя в систему. -
Проверьте работоспособность входа в систему, чтобы убедиться, что LDAP-сервер правильно подключен к среде zVirt. Для запроса на вход введите свои имя пользователя и пароль:
NOTE: It is highly recommended to test drive the configuration before applying it into engine. Login sequence is executed automatically, but it is recommended to also execute Search sequence manually after successful Login sequence. Please provide credentials to test login flow: Enter user name: Enter user password: [ INFO ] Executing login sequence... ... [ INFO ] Login sequence executed successfully -
Убедитесь, что сведения о пользователе верны. Если они неверны, выберите
Abort:Please make sure that user details are correct and group membership meets expectations (search for PrincipalRecord and GroupRecord titles). Abort if output is incorrect. Select test sequence to execute (Done, Abort, Login, Search) [Abort]: -
Рекомендуется вручную проверить функцию поиска. Для поискового запроса выберите
Principalдля учетных записей пользователей или Группа (Group) для учетных записей групп. НаберитеYes, чтобы Разрешить группы (Resolve Groups), если нужно возвращать информацию об учетной записи группы для учетной записи пользователя. После этого будут созданы и отобразятся на экране три файла конфигурации.Select test sequence to execute (Done, Abort, Login, Search) [Search]: _Search_ Select entity to search (Principal, Group) [Principal]: Term to search, trailing '*' is allowed: _testuser1_ Resolve Groups (Yes, No) [No]: -
Выберите
Done, чтобы завершить настройку:Select test sequence to execute (Done, Abort, Login, Search) [Abort]: _Done_ [ INFO ] Stage: Transaction setup [ INFO ] Stage: Misc configuration [ INFO ] Stage: Package installation [ INFO ] Stage: Misc configuration [ INFO ] Stage: Transaction commit [ INFO ] Stage: Closing up CONFIGURATION SUMMARY Profile name is: example.com The following files were created: /etc/ovirt-engine/aaa/example.com.properties /etc/ovirt-engine/extensions.d/example.com.properties /etc/ovirt-engine/extensions.d/example.com-authn.properties [ INFO ] Stage: Clean up Log file is available at /tmp/ovirt-engine-extension-aaa-ldap-setup-20171004101225-mmneib.log: [ INFO ] Stage: Pre-termination [ INFO ] Stage: Termination -
Перезапустите службу ovirt-engine. Созданный профиль теперь доступен на страницах входа на Портал администрирования и Пользовательский портал. Чтобы назначить учетным записям пользователей на LDAP-сервере соответствующие роли и разрешения, например, для входа на Пользовательский портал, см. раздел Администрирование пользовательских задач с Портала администрирования.
# systemctl restart ovirt-engine.service
| Дополнительную информацию см. в файле README расширения аутентификации и авторизации LDAP здесь: /usr/share/doc/ovirt-engine-extension-aaa-ldap-version. |
4.3.2. Подключение Active Directory
-
Нужно знать имя леса Active Directory. Имя леса также называется именем корневого домена.
Примеры наиболее распространенных конфигураций Active Directory, которые нельзя настроить с помощью инструмента ovirt-engine-extension-aaa-ldap-setup tool, приведены здесь: /usr/share/ovirt-engine-extension-aaa-ldap/examples/README.md. -
Необходимо либо добавить DNS-сервер, способный разрешать имя леса Active Directory, в файл /etc/resolv.conf в Менеджере управления, либо выписать DNS-серверы Active Directory и ввести их при появлении запроса от интерактивного скрипта настройки.
-
Чтобы установить безопасное соединение между LDAP-сервером и Менеджером управления, убедитесь, что подготовлен сертификат Центра сертификации в кодировке PEM. Дополнительную информацию см. в разделе Настройка шифрованной связи между Менеджером управления и LDAP-сервером.
-
Если анонимный поиск не поддерживается, то в Active Directory должен быть доступен пользователь с разрешениями на просмотр всех пользователей и групп, чтобы его можно было использовать в качестве пользователя, формирующего поисковые запросы. Запишите отличительное имя (DN) пользователя, формирующего поисковые запросы. Не используйте пользователя с правами администратора для Active Directory.
-
Должна существовать хотя бы одна учетная запись (имя и пароль) для выполнения запросов на поиск и вход в Active Directory.
-
Если развернутый Active Directory охватывает несколько доменов, не забывайте об ограничении, описанном в файле /usr/share/ovirt-engine-extension-aaa-ldap/profiles/ad.properties.
Процедура подключения Active Directory описана в инструкции Использование Active Directory в качестве внешней службы каталогов
4.3.3. Настройка внешнего провайдера LDAP (ручной метод)
Полностью настраиваемое расширение ovirt-engine-extension-aaa-ldap использует протокол LDAP для доступа к серверам каталогов. Аутентификация Kerberos не требуется, если только вы не хотите включить единый вход на Пользовательский портал или Портал администрирования.
Если интерактивный метод настройки, описанный в предыдущем разделе, не подходит для вашего варианта использования, можно вручную изменить файлы конфигурации, чтобы подключить свой LDAP-сервер. В следующей процедуре используются типовые данные. Конкретные значения зависят от специфики настройки.
-
В Менеджере управления установите пакет расширения LDAP:
# dnf install ovirt-engine-extension-aaa-ldap -
Скопируйте файл шаблона конфигурации LDAP в каталог /etc/ovirt-engine. Файлы шаблонов доступны для активных каталогов (ad) и других типов каталогов (simple). В этом примере используется простой шаблон конфигурации.
# cp -r /usr/share/ovirt-engine-extension-aaa-ldap/examples/simple/. /etc/ovirt-engine -
Переименуйте файлы конфигурации, чтобы они соотносились с именем профиля, который нужно сделать видимым для пользователей на страницах входа на Портал администрирования и Пользовательский портал:
# mv /etc/ovirt-engine/aaa/profile1.properties /etc/ovirt-engine/aaa/_example_.properties # mv /etc/ovirt-engine/extensions.d/profile1-authn.properties /etc/ovirt-engine/extensions.d/_example_-authn.properties # mv /etc/ovirt-engine/extensions.d/profile1-authz.properties /etc/ovirt-engine/extensions.d/_example_-authz.properties -
Измените файл конфигурации свойств LDAP, раскомментировав тип LDAP-сервера и обновив поля домена и паролей:
# vi /etc/ovirt-engine/aaa/_example_.propertiesПример 6. Пример профиля: раздел LDAP-сервера# Select one # include = <openldap.properties> #include = <389ds.properties> #include = <rhds.properties> #include = <ipa.properties> #include = <iplanet.properties> #include = <rfc2307-389ds.properties> #include = <rfc2307-rhds.properties> #include = <rfc2307-openldap.properties> #include = <rfc2307-edir.properties> #include = <rfc2307-generic.properties> # Server # vars.server = _ldap1.example.com_ # Search user and its password. # vars.user = uid=search,cn=users,cn=accounts,dc=_example_,dc=_com_ vars.password = _123456_ pool.default.serverset.single.server = ${global:vars.server} pool.default.auth.simple.bindDN = ${global:vars.user} pool.default.auth.simple.password = ${global:vars.password}Чтобы использовать протокол TLS или SSL для взаимодействия с LDAP-сервером, получите корневой сертификат Центра сертификации для LDAP-сервера и используйте его для создания открытого файла хранилища ключей. Раскомментируйте следующие строки и укажите полный путь к открытому файлу хранилища ключей и пароль для доступа к файлу.
Дополнительную информацию о создании открытого файла хранилища ключей см. в разделе Настройка шифрованной связи между Менеджером управления и LDAP-сервером. Пример 7. Пример профиля: раздел хранилища ключей# Create keystore, import certificate chain and uncomment # if using tls. pool.default.ssl.startTLS = true pool.default.ssl.truststore.file = _/full/path/to/myrootca.jks_ pool.default.ssl.truststore.password = _password_ -
Просмотрите конфигурационный файл аутентификации. Имя профиля, видимое для пользователей на страницах входа на Портал администрирования и Пользовательский портал, определяется посредством
ovirt.engine.aaa.authn.profile.name. Расположение профиля конфигурации должно соотноситься с расположением файла конфигурации LDAP. Все поля можно оставить в значениях по умолчанию.# vi /etc/ovirt-engine/extensions.d/_example_-authn.propertiesПример 8. Пример конфигурационного файла аутентификацииovirt.engine.extension.name = _example_-authn ovirt.engine.extension.bindings.method = jbossmodule ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine.extension.aaa.ldap ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engine.extension.aaa.ldap.AuthnExtension ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authn ovirt.engine.aaa.authn.profile.name = _example_ ovirt.engine.aaa.authn.authz.plugin = _example_-authz config.profile.file.1 = ../aaa/_example_.properties -
Просмотрите конфигурационный файл авторизации. Расположение профиля конфигурации должно соотноситься с расположением файла конфигурации LDAP. Все поля можно оставить в значениях по умолчанию.
# vi /etc/ovirt-engine/extensions.d/_example_-authz.propertiesПример 9. Пример конфигурационного файла авторизацииovirt.engine.extension.name = _example_-authz ovirt.engine.extension.bindings.method = jbossmodule ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine.extension.aaa.ldap ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engine.extension.aaa.ldap.AuthzExtension ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authz config.profile.file.1 = ../aaa/_example_.properties -
Убедитесь, что для профиля конфигурации заданы соответствующие владелец и разрешения:
# chown ovirt:ovirt /etc/ovirt-engine/aaa/_example_.properties # chmod 600 /etc/ovirt-engine/aaa/_example_.properties -
Перезапустите службу engine:
# systemctl restart ovirt-engine.service -
Созданный профиль example теперь доступен на страницах входа на Портал администрирования и Пользовательский портал. Чтобы предоставить учетным записям пользователей на LDAP-сервере соответствующие разрешения, например, для входа на Пользовательский портал, см. раздел Администрирование пользовательских задач с Портала администрирования.
| Дополнительную информацию см. в файле README расширения аутентификации и авторизации LDAP здесь: /usr/share/doc/ovirt-engine-extension-aaa-ldap-version. |
4.3.4. Удаление внешнего провайдера LDAP
В этой процедуре показано, как удалить настроенного внешнего провайдера LDAP и его пользователей.
-
Удалите файлы конфигурации провайдера LDAP, заменив имя по умолчанию profile1:
# rm /etc/ovirt-engine/extensions.d/_profile1_-authn.properties # rm /etc/ovirt-engine/extensions.d/_profile1_-authz.properties # rm /etc/ovirt-engine/aaa/_profile1_.properties -
Перезапустите службу ovirt-engine:
# systemctl restart ovirt-engine -
На Портале администрирования перейдите в выберите пользователей этого провайдера (тех, чьим Провайдером авторизации (Authorization provider) является
profile1-authz) и нажмите Удалить (Remove).
4.4. Настройка LDAP и Kerberos для единого входа (SSO)
SSO позволяет пользователям входить на Пользовательский портал или Портал администрирования, не вводя пароль повторно. Учетные данные для аутентификации берутся с сервера Kerberos. Чтобы настроить SSO на Портал администрирования и Пользовательский портал, нужно настроить два расширения: ovirt-engine-extension-aaa-misc и ovirt-engine-extension-aaa-ldap; а также два модуля Apache: mod_auth_gssapi и mod_session. Можно настроить SSO и без использования Kerberos, однако это выходит за рамки данной документации.
| Если включен SSO на Пользовательский портал, то SSO на виртуальные машины невозможен. Если включен SSO на Пользовательский портал, то Пользовательскому порталу не требуется принимать пароль и поэтому невозможно делегировать пароль для входа на виртуальные машины. |
Процедуру по настройке LDAP и Kerberos для единого входа (SSO) смотрите в инструкции Настройка менеджера управления для аутентификации с помощью SSO через LDAP и Kerberos на веб-портале zVirt
4.5. Авторизация пользователя
4.5.1. Модель авторизации пользователей
zVirt использует средства управления авторизацией, основанные на сочетании трех компонентов:
-
Пользователь, выполняющий действие;
-
Тип выполняемого действия;
-
Объект, над которым выполняется действие.
4.5.2. Действия пользователей
Для успешного выполнения действия пользователь должен иметь соответствующее разрешение в отношении объекта, над которым он собирается произвести действие. Каждый тип действия имеет соответствующее разрешение.
Некоторые действия выполняются над несколькими объектами. К примеру, копирование шаблона в другой домен хранения затронет как шаблон, так и домен хранения, являющийся приемником. Пользователь, выполняющий действие, должен иметь соответствующие разрешения в отношении всех объектов, которые затрагивает действие.
4.6. Администрирование пользовательских задач с Портала администрирования
4.6.1. Создание пользователей
Прежде чем добавить пользователей и назначить им роли и разрешения, таких пользователей нужно создать. Для подключения пользователей из внешнего провайдера, воспользуйтесь процедурой, описанной в разделе Настройка внешнего провайдера LDAP. Для создания локального пользователя воспользуйтесь процедурой, описанной в разделе Создание нового пользователя или выполните следующие действия на портале администрирования:
-
В боковой панели нажмите .
-
Нажмите Создать (Create new)
-
В окне Создание локального пользователя (Create Internal User) введите следующие данные:
-
Имя пользователя (User Name)
-
В выпадающем меню Роли пользователя (User Roles) выберите роль/роли пользователя
-
Имя (First Name)
-
Фамилию (Last Name)
-
E-mail
-
Пароль (Password)
По умолчанию политика паролей для учетных записей пользователей на внутреннем домене имеет следующие ограничения:
-
Минимум 6 знаков.
-
При изменении пароля нельзя снова использовать три предыдущих пароля.
-
Пароль не должен содержать следующие специальные символы
! ? " ' , + < > [ ] { } | \ / ~ : ; `
Для получения дополнительной информации о политике паролей и других настройках по умолчанию выполните
ovirt-aaa-jdbc-tool settings show. -
-
-
Нажмите Сохранить (Save)
4.6.2. Назначение разрешений Пользовательского портала
Роли и разрешения, назначенные во время этой процедуры, позволяют пользователю авторизоваться на Пользовательском портале и начать создавать виртуальные машины. Процедура применяется к учетным записям групп.
-
В боковой панели нажмите . Откроется окно Настройка (Configure).
-
Нажмите Системные разрешения (System Permissions).
-
Нажмите Добавить (Add). Откроется окно Добавить системное разрешение (Add System Permission to User).
-
Выберите профиль в разделе Поиск (Search). Профиль – это домен, в котором вы хотите искать. Введите имя или часть имени в текстовое поле и нажмите Поиск (GO). Либо нажмите Поиск (GO), чтобы просмотреть список всех пользователей и групп.
-
Установите нужные флажки, чтобы выбрать необходимых пользователей и группы.
-
Выберите соответствующую роль для назначения в разделе Роль для связи (Role to Assign). Роль UserRole предоставляет учетной записи пользователя разрешение авторизоваться на Пользовательском портале.
-
Нажмите OK.
Авторизуйтесь на Пользовательском портале, чтобы убедиться, что у учетной записи пользователя есть разрешения на авторизацию.
4.6.3. Просмотр информации о пользователях
-
В боковой панели нажмите , чтобы отобразить список всех авторизованных пользователей.
-
Нажмите имя пользователя. Откроется подробное представление, при этом на вкладке Общее (General) обычно отображается общая информация, такая как имя домена, адрес электронной почты и статус пользователя.
-
Другие вкладки позволяют просматривать информацию о группах, разрешениях, квотах и событиях для соответствующего пользователя.
Например, для просмотра групп, которым принадлежит пользователь, откройте вкладку Группы каталогов (Directory Groups).
4.6.4. Просмотр пользовательских разрешений в отношении ресурсов
Пользователям можно назначать разрешения на определенные ресурсы или иерархически структурированные группы ресурсов. По каждому ресурсу можно просматривать списки назначенных пользователей и их разрешения.
-
Найдите и нажмите на имя ресурса. Откроется подробное представление.
-
Откройте вкладку Разрешения (Permissions), чтобы вывести список назначенных пользователей с информацией о роли каждого из них и унаследованных разрешениях для выбранного ресурса.
4.6.5. Удаление пользователей
Если учетная запись пользователя больше не нужна, удалите ее из zVirt.
-
В боковой панели нажмите , чтобы отобразить список всех авторизованных пользователей.
-
Выберите пользователя для удаления. Убедитесь в том, что у него не запущена какая-либо виртуальная машина.
-
Нажмите Удалить (Remove), затем нажмите OK.
Пользователь удаляется из zVirt, но не из внешнего каталога.
4.6.6. Управление сессиями
4.6.6.1. Просмотр авторизованных пользователей
Можно просматривать пользователей, которые находятся в системе в настоящий момент, а также время сеанса и другую информацию. Нажмите , чтобы просмотреть Код сессии БД (Session DB ID), Имя пользователя (User Name), Провайдера авторизации (Authorization provider), Идентификатор пользователя (User id), IP-адрес (Source IP), Время начала сессии (Session Start Time) и Время последней активности сессии (Session Last Active Time) для каждого авторизованного пользователя.
4.6.6.2. Завершение активной сессии пользователя
Можно завершить сеанс пользователя, который в данный момент находится в системе.
-
Нажмите .
-
Выберите сеанс пользователя, который нужно завершить.
-
Нажмите Завершить сессию (Terminate Session).
-
Нажмите OK.
4.6.6.3. Настройка ограничений сессии
В zVirt доступна настройка максимального количества и длительности сессий пользователя.
-
Нажмите .
-
Выберите нужного пользователя.
-
Нажмите Управление сессиями (Manage Sessions).
-
В окне Управление ограничениями пользователя (User configuration) укажите необходимые параметры:
-
Количество сессий (Session number limit): указывает максимальное количество одновременно активных сессий. По умолчанию для admin - не ограничено (0), для остальных пользователей - 1.
-
Время сессий (Session lifetime): указывает максимальную продолжительность сессии пользователя в минутах. По умолчанию для admin - не ограничено (0), для остальных пользователей - 60 минут.
-
-
Нажмите Сохранить (Save).
4.7. Администрирование пользовательских задач через командную строку
Для управления учетными записями пользователей на внутреннем домене можно использовать инструмент ovirt-aaa-jdbc-tool. Изменения, вносимые с помощью этого инструмента, сразу вступают в силу без необходимости перезагрузки службы ovirt-engine. Для просмотра полного списка параметров для пользователей выполните ovirt-aaa-jdbc-tool user --help.
Типичные примеры представлены в настоящем разделе.
| Требуется авторизация на машине с Менеджером управления. |
4.7.1. Создание нового пользователя
Можно создать новую учетную запись пользователя. При желании, с помощью параметра --attribute можно вывести сведения об учетной записи. Для просмотра полного списка параметров выполните ovirt-aaa-jdbc-tool user add --help.
# ovirt-aaa-jdbc-tool user add test1 --attribute=firstName=John --attribute=lastName=Doe
adding user test1...
user added successfully
Можно добавить только что созданного пользователя на Портале администрирования и назначить ему соответствующие роли и разрешения. Для получения дополнительной информации см. раздел Назначение разрешений Пользовательского портала.
4.7.2. Установка пароля пользователя
Можно создать пароль. Нужно задать значение для --password-valid-to, иначе срок действия пароля будет по умолчанию установлен как истекающий прямо сейчас. Дата указывается в формате гггг-ММ-дд ЧЧ:мм:ссX (yyyy-MM-dd HH:mm:ssX). В этом примере -0800 обозначает GMT минус 8 часов. Для просмотра полного списка параметров выполните ovirt-aaa-jdbc-tool user password-reset --help.
# ovirt-aaa-jdbc-tool user password-reset test1 --password-valid-to="2025-08-01 12:00:00-0800"
Password:
updating user test1...
user updated successfully
|
По умолчанию политика паролей для учетных записей пользователей на внутреннем домене имеет следующие ограничения:
Для получения дополнительной информации о политике паролей и других настройках по умолчанию выполните |
После обновления пароля администратора изменения должны быть вручную распространены на ovirt-provider-ovn. В противном случае пользователь с правами администратора будет заблокирован, так как Менеджер управления продолжит использовать старый пароль для синхронизации сетей из ovirt-provider-ovn. Чтобы распространить новый пароль на ovirt-provider-ovn, сделайте следующее:
-
На Портале администрирования нажмите .
-
Выберите ovirt-provider-ovn.
-
Нажмите Изменить (Edit) и введите новый пароль в поле Пароль (Password).
-
Нажмите Тестировать (Test), чтобы проверить, проходит ли успешно аутентификация с предоставленными учетными данными.
-
После успешной проверки аутентификации нажмите ОК.
4.7.3. Настройка допустимого периода неактивности пользователя
Можно настроить допустимый период неактивности пользователя:
# engine-config --set UserSessionTimeOutInterval=_integer_
4.7.4. Предварительное шифрование пароля пользователя
Можно создать предварительно зашифрованный пароль пользователя, используя скрипт ovirt-engine-crypto-tool. Эта опция полезна при добавлении пользователей и паролей в базу данных с помощью скрипта.
|
Пароли хранятся в базе данных Менеджера управления в зашифрованном виде. Скрипт Если пароль предварительно зашифрован, то невозможно выполнить проверку действительности пароля. Пароль будет принят, даже если он не соответствует требованиям политики проверки паролей. |
-
Выполните следующую команду:
# /usr/share/ovirt-engine/bin/ovirt-engine-crypto-tool.sh pbe-encodeСкрипт запросит ввод пароля.
Либо с помощью параметра
--password=file:fileможно зашифровать один пароль, который отображается как первая строка файла. Такой параметр полезен при автоматизации. В следующем примереfile- это текстовый файл, содержащий один пароль для шифрования:# /usr/share/ovirt-engine/bin/ovirt-engine-crypto-tool.sh pbe-encode --password=file:__file__ -
Установите новый пароль с помощью скрипта
ovirt-aaa-jdbc-tool, используя параметр--encrypted:# ovirt-aaa-jdbc-tool user password-reset __test1__ --password-valid-to="2025-08-01 12:00:00-0800" --encrypted -
Введите и подтвердите зашифрованный пароль:
Password: Reenter password: updating user test1... user updated successfully
4.7.5. Просмотр информации о пользователях
Можно посмотреть подробные сведения об учетной записи пользователя:
# ovirt-aaa-jdbc-tool user show test1
В результате выполнения этой команды отображается больше сведений, чем на экране на Портале администрирования.
4.7.6. Изменение информации о пользователе
Информацию о пользователе (например, адрес электронной почты) можно обновить:
# ovirt-aaa-jdbc-tool user edit test1 --attribute=email=jdoe@example.com
4.7.7. Удаление пользователя
Учетную запись пользователя можно удалить:
# ovirt-aaa-jdbc-tool user delete test1
Удалите пользователя с Портала администрирования. Для получения дополнительной информации см. раздел Удаление пользователей.
4.7.8. Отключение внутреннего пользователя с правами администратора
Можно отключить пользователей на локальных доменах, в том числе пользователя admin@internal, созданного в процессе выполнения engine-setup. Убедитесь, что в среде есть хотя бы один пользователь со всеми административными разрешениями, прежде чем отключать пользователя admin по умолчанию.
-
Авторизуйтесь на той машине, на которой установлен Менеджер управления.
-
Убедитесь, что в среду добавлен другой пользователь с ролью SuperUser. Более подробные сведения см. в разделaх Создание пользователей и Назначение разрешений Пользовательского портала.
-
Отключите пользователя admin по умолчанию:
# ovirt-aaa-jdbc-tool user edit `admin` --flag=+disabledЧтобы подключить отключенного пользователя, выполните команду:
ovirt-aaa-jdbc-tool user edit username --flag=-disabled==== Управление группами
С помощью инструмента ovirt-aaa-jdbc-tool можно управлять учетными записями групп во внутреннем домене. Управление учетными записями групп и пользователей происходит похожим образом. Для просмотра полного списка параметров для групп выполните ovirt-aaa-jdbc-tool group --help. Типичные примеры представлены в настоящем разделе.
Создание группы
Далее показано, как создавать учетную запись группы, добавлять пользователей в группу и просматривать подробные сведения о группе.
-
Авторизуйтесь на той машине, на которой установлен Менеджер управления.
-
Создайте новую группу:
# ovirt-aaa-jdbc-tool group add _group1_ -
Добавьте пользователей в группу. Пользователи должны быть уже созданы.
# ovirt-aaa-jdbc-tool group-manage useradd _group1_ --user=_test1_Для просмотра полного списка параметров group-manage выполните ovirt-aaa-jdbc-tool group-manage --help. -
Посмотреть подробные сведения об учетной записи группы:
# ovirt-aaa-jdbc-tool group show _group1_ -
Добавьте только что созданную группу на Портал администрирования и назначьте группе соответствующие роли и разрешения. Пользователи в группе наследуют роли и разрешения группы. Более подробные сведения см. в разделах Создание пользователей и Назначение разрешений Пользовательского портала.
Создание вложенных групп
Далее показано, как создавать группы внутри групп.
-
Авторизуйтесь на той машине, на которой установлен Менеджер управления.
-
Создайте первую группу:
# ovirt-aaa-jdbc-tool group add _group1_ -
Создайте вторую группу:
# ovirt-aaa-jdbc-tool group add _group1-1_ -
Добавьте вторую группу в первую группу:
# ovirt-aaa-jdbc-tool group-manage groupadd _group1_ --group=_group1-1_ -
Добавьте первую группу на Портал администрирования и назначьте группе соответствующие роли и разрешения. Более подробные сведения см. в разделах Создание пользователей и Назначение разрешений Пользовательского портала.
4.7.9. Опрашивание пользователей и групп
Модуль query позволяет запрашивать информацию о пользователях и группах. Для просмотра полного списка параметров выполните ovirt-aaa-jdbc-tool query --help.
Вывод списка с информацией по всем учетным записям пользователей или групп
Далее показано, как вывести список с информацией по всем учетным записям.
-
Авторизуйтесь на той машине, на которой установлен Менеджер управления.
-
Выведите список с информацией обо всех учетных записях.
-
Данные по всем учетным записям пользователей:
# ovirt-aaa-jdbc-tool query --what=user -
Данные по всем учетным записям групп:
# ovirt-aaa-jdbc-tool query --what=group
-
Вывод списка по отфильтрованным данных учетных записей
Далее показано, как использовать фильтры при выводе списка информации по учетным записям.
-
Авторизуйтесь на той машине, на которой установлен Менеджер управления.
-
Отфильтруйте данные учетной записи с помощью параметра
--pattern.-
Выведите список данных учетных записей пользователей с именами, начинающимися со знака
j.# ovirt-aaa-jdbc-tool query --what=user --pattern="name=_j*_" -
Выведите список групп, у которых указан атрибут департамента marketing:
# ovirt-aaa-jdbc-tool query --what=group --pattern="department=_marketing_"
-
4.7.10. Управление настройками учетной записи
Чтобы изменить настройки учетной записи по умолчанию, используйте модуль ovirt-aaa-jdbc-tool settings.
Обновление настроек учетной записи
Далее показано, как обновить настройки учетной записи по умолчанию.
-
Авторизуйтесь на той машине, на которой установлен Менеджер управления.
-
Чтобы увидеть все доступные настройки, выполните команду:
# ovirt-aaa-jdbc-tool settings show -
Измените необходимые настройки:
-
В этом примере заданная по умолчанию длительность сеанса после авторизации изменена на 60 минут для всех учетных записей пользователей. Значение по умолчанию – 10 080 минут.
# ovirt-aaa-jdbc-tool settings set --name=MAX_LOGIN_MINUTES --value=_60_ -
В этом примере изменено количество неудачных попыток входа в систему, которые может предпринять пользователь, прежде чем его учетная запись будет заблокирована. Значение по умолчанию - 5.
# ovirt-aaa-jdbc-tool settings set --name=MAX_FAILURES_SINCE_SUCCESS --value=_3_
Чтобы разблокировать заблокированную учетную запись пользователя, выполните команду ovirt-aaa-jdbc-tool user unlock test1. -
4.8. Конфигурирование дополнительных локальных доменов
Помимо внутреннего (internal) домена по умолчанию, также можно создавать дополнительные локальные домены. Это можно сделать с помощью расширения ovirt-engine-extension-aaa-jdbc, чтобы создавать несколько доменов без подключения внешних серверов каталогов, хотя такой вариант использования редко встречается в корпоративных средах.
Дополнительно созданные локальные домены не будут обновляться автоматически во время стандартных обновлений zVirt и должны быть обновлены вручную при каждом новом релизе. Подробные сведения о создании дополнительных локальных доменов и о том, как обновлять домены, см. в файле README, расположенном здесь: /usr/share/doc/ovirt-engine-extension-aaa-jdbc-version/README.admin.
5. Квоты и политика SLA
5.1. Введение в квоты
Квота – это инструмент ограничения ресурсов, предоставляемый с zVirt. Квоту можно рассматривать как слой ограничений поверх слоя ограничений, установленных разрешениями пользователя.
Квота – это объект центра данных.
Квота позволяет администраторам сред zVirt ограничивать доступ пользователей к памяти, ЦП и хранилищу. Квота определяет ресурсы памяти и хранилища, которые администратор может назначить пользователям. В результате пользователи могут использовать только назначенные им ресурсы. Когда ресурсы по квоте исчерпаны, zVirt не разрешает дальнейшие действия пользователей.
Существует два вида квот:
| Тип квоты | Определение |
|---|---|
Квота на ресурсы среды выполнения (Run-time Quota) |
Эта квота ограничивает потребление ресурсов среды выполнения (например, ЦП и память). |
Квота хранения (Storage Quota) |
Эта квота ограничивает объем доступного хранилища. |
У квоты может быть три режима:
| Режим квотирования | Описание |
|---|---|
Принудительный (Enforced) |
В этом режиме действует квота, которая ограничивает ресурсы для группы или пользователя, на которых распространяется квота. |
Аудит (Audit) |
В этом режиме регистрируются нарушения квот без блокировки пользователей, и он может использоваться для проверки квот. В режиме Аудита можно увеличить или уменьшить объем квоты на ресурсы среды выполнения и объем квоты хранения, доступный пользователям, на которых распространяется квота. |
Выключенный (Disabled) |
Этот режим отключает ограничения на ресурсы среды выполнения и ресурсы хранения, заданные квотой. |
Когда пользователь пытается запустить виртуальную машину, характеристики виртуальной машины сравниваются с допустимыми значениями выделенных ресурсов хранения и выделенных ресурсов среды выполнения, установленными в соответствующей квоте.
Если запуск виртуальной машины приводит к тому, что совокупные ресурсы всех запущенных виртуальных машин, на которые распространяется квота, превышают допустимое значение, определенное квотой, то Менеджер управления отклонит запуск виртуальной машины.
Когда пользователь создает новый диск, запрашиваемый размер диска добавляется к суммарному используемому дисковому пространству всех остальных дисков, на которые распространяется квота. Если с новым диском общее суммарно используемое дисковое пространство превысит квоту, то создать диск не получится.
Квота позволяет совместно использовать ресурсы одного оборудования. Можно использовать жесткие и мягкие пороговые значения. Администраторы могут использовать квоту для установки пороговых значений по ресурсам. Для пользователя эти пороговые значения выглядят как 100% использование определенного ресурса. Для предотвращения сбоев в случае, когда заказчик внезапно превышает пороговое значение, в интерфейсе предусмотрен объем, на который можно "без последствий" кратковременно превысить пороговое значение. При превышении пороговых значений заказчику отправляется предупреждение.
|
Квота накладывает ограничения на работу виртуальных машин. Если ограничения игнорировать, то есть риск, что в какой-то момент вы не сможете использовать свои виртуальные машины и виртуальные диски. Когда действует принудительный режим квотирования, виртуальные машины и диски, которым не назначены квоты, использовать нельзя. Чтобы можно было включить виртуальную машину, ей должна быть назначена квота. Чтобы можно было создать снимок виртуальной машины, диску, ассоциированному с виртуальной машиной, должна быть назначена квота. При создании шаблона из виртуальной машины будет предложено выбрать квоту, которую будет потреблять шаблон. Это позволяет установить для шаблона (и всех будущих машин, созданных на основе шаблона) квоту, отличную от квоты виртуальной машины и диска, на основе которых создан шаблон. |
5.2. Общая квота и индивидуально установленная квота
Пользователи с разрешениями SuperUser могут создавать квоты для отдельных пользователей или квоты для групп.
Групповые квоты могут быть установлены для пользователей Active Directory. Если группе из десяти пользователей предоставлена квота в 1 ТБ хранилища, а один из десяти пользователей заполнит весь терабайт, то вся группа превысит квоту, и ни один из десяти пользователей не сможет использовать хранилище, ассоциированное с их группой.
Квота отдельного пользователя устанавливается только для него одного. Как только отдельный пользователь израсходует всю свою квоту на ресурсы среды выполнения или на ресурсы хранения, то он превысит квоту и больше не сможет использовать хранилище, ассоциированное с его квотой.
5.3. Учет квот
Когда потребителю или ресурсу назначена квота, каждое действие этого потребителя или ресурса, связанное с хранилищем, виртуальным ЦП или памятью, приводит к потреблению или высвобождению ресурсов, заложенных в квоту.
Поскольку квота действует как верхняя граница, ограничивающая доступ пользователя к ресурсам, расчеты квоты могут отличаться от фактического текущего использования пользователем. Квота рассчитывается для максимально возможного роста, а не для текущего использования.
Пользователь запускает виртуальную машину с 1 виртуальным ЦП и 1024 МБ памяти. Это действие потребляет 1 виртуальный ЦП и 1024 МБ из квоты, назначенной этому пользователю. После остановки виртуальной машины 1 виртуальный ЦП и 1024 МБ оперативной памяти высвобождаются и возвращаются обратно в квоту, назначенную этому пользователю. Потребление квоты на ресурсы среды выполнения учитывается только во время фактического времени работы программ потребителя.
Пользователь создает виртуальный диск объемом 10 ГБ с динамическим выделением пространства. Фактическое использование диска может показать, что на самом деле используется только 3 ГБ этого диска. Однако квота потребления составит 10 ГБ, т.е. максимальный объем этого диска с учетом возможного роста.
5.4. Включение и изменение режима квотирования в центре данных
Эта процедура позволяет включить или изменить режим квотирования в центре данных. Необходимо сначала выбрать режим квотирования, а потом уже задавать квоты. Чтобы выполнить эту процедуру, необходимо авторизоваться на Портале администрирования.
Используйте режим Аудит (Audit) для проверки квоты, чтобы убедиться, что она работает в соответствии с вашими ожиданиями. Чтобы создать или изменить квоту, не обязательно использовать режим Аудит (Audit).
-
Нажмите и выберите центр данных.
-
Нажмите Изменить (Edit).
-
В выпадающем списке Режим квотирования (Quota Mode) измените режим квотирования на Принудительный (Enforced).
-
Нажмите OK.
Если во время проверки задать режим квотирования Аудит (Audit), то необходимо будет изменить его на Принудительный (Enforced), чтобы настройки квот вступили в силу.
5.5. Создание новой политики квотирования
Вы включили режим квотирования Аудит (Audit) или Принудительный (Enforcing). Теперь необходимо задать политику квотирования для управления использованием ресурсов в центре данных.
-
Нажмите .
-
Нажмите Новая (Add).
-
Заполните поля Имя (Name) и Описание (Description).
-
Выберите Центр данных (Data Center).
-
В разделе Память и ЦП (Memory & CPU) используйте зеленый бегунок, чтобы задать Пороговое значение для кластера (Cluster Threshold).
-
В разделе Память и ЦП (Memory & CPU) используйте синий бегунок, чтобы задать Допустимое превышение для кластера (Cluster Grace).
-
Кнопкой-переключателем выберите Все кластеры (All Clusters) или Указанные кластера (Specific Clusters). Если вы выбрали Указанные кластера (Specific Clusters), то отметьте флажками кластеры, которые хотите добавить в политику квотирования.
-
Нажмите Изменить (Edit). Откроется окно Изменить квоту (Edit Quota).
-
В поле Память (Memory) кнопкой-переключателем выберите либо Неограниченно (Unlimited) (разрешает неограниченное использование ресурсов Памяти в кластере), либо Ограничить до (limit to), чтобы установить объем памяти для квоты. Если вы выбрали Ограничить до (limit to), то укажите квоту памяти в мегабайтах (МБ) в поле MiB.
-
В поле ЦП (CPU) кнопкой-переключателем выберите либо Неограниченно (Unlimited), либо ограничить до (limit to), чтобы установить объем ЦП для квоты. Если вы выбрали ограничить до (limit to), то укажите количество виртуальных ЦП в поле вЦП (vCpus).
-
Нажмите OK в окне Изменить квоту (Edit Quota).
-
-
В разделе Хранилище (Storage) используйте зеленый бегунок, чтобы задать Пороговое значение для хранилища (Storage Threshold).
-
В разделе Хранилище (Storage) используйте синий бегунок, чтобы задать Допустимое превышение для хранилища (Storage Grace).
-
Кнопкой-переключателем выберите Все домены хранения (All Storage Domains) или Указанные домены хранения (Specific Storage Domains). Если вы выбрали Указанные домены хранения (Specific Storage Domains), то отметьте флажками домены хранения, которые хотите добавить в политику квотирования.
-
Нажмите Изменить (Edit). Откроется окно Изменить квоту (Edit Quota).
-
В поле Квота хранилища (Storage Quota) кнопкой-переключателем выберите либо Неограниченно (Unlimited) (разрешает неограниченное использование ресурсов Хранилища), либо ограничить до (limit to), чтобы установить ограничение на объем памяти, доступной для пользователей согласно квоте. Если вы выбрали ограничить до (limit to), то укажите квоту хранения в гигабайтах (ГБ) в поле GiB.
-
Нажмите OK в окне Изменить квоту (Edit Quota).
-
-
Нажмите OK в окне Новая квота (New Quota).
5.6. Описание настроек пороговых значений квоты
| Параметр | Определение |
|---|---|
Пороговое значение для кластера |
Объем ресурсов кластера, доступных каждому центру данных. |
Допустимое превышение для кластера |
Объем ресурсов кластера, доступный центру данных после достижения порогового значения в кластере, установленного для этого центра данных. |
Пороговое значение для хранилища |
Объем ресурсов хранилища, доступных каждому центру данных. |
Допустимое превышение для хранилища |
Объем ресурсов хранилища, доступный центру данных после достижения порогового значения хранилища, установленного для этого центра данных. |
Если квота установлена на 100 ГБ с допустимым превышением в 20%, то потребителям заблокируют доступ к ресурсам хранилища после того, как они заполнят 120 ГБ хранилища. Если для той же квоты установлено Пороговое значение 70%, то потребители получат предупреждение, когда заполнят больше 70 ГБ хранилища (но при этом они смогут использовать хранилище до тех пор, пока не заполнят 120 ГБ хранилища). "Пороговое значение" и "Допустимое превышение" задаются в привязке к квоте. "Пороговое значение" можно рассматривать как "мягкое ограничение", в результате превышения которого будет выдано предупреждение. "Допустимое превышение" можно рассматривать как "жесткое ограничение", превышение которого делает невозможным дальнейшее потребление ресурсов хранилища.
5.7. Назначение квоты объекту
Назначение квоты виртуальной машине
-
Нажмите и выберите виртуальную машину.
-
Нажмите Изменить (Edit).
-
Из выпадающего списка Квота (Quota) выберите квоту, которую виртуальная машина будет потреблять.
-
Нажмите OK.
Назначение квоты диску
-
Нажмите .
-
Нажмите на имя виртуальной машины. Откроется подробное представление.
-
Откройте вкладку Диски (Disks) и выберите диск, который собираетесь ассоциировать с квотой.
-
Нажмите Изменить (Edit).
-
Из выпадающего списка Квота (Quota) выберите квоту, которую диск будет потреблять.
-
Нажмите OK.
| Чтобы виртуальная машина работала, квоту необходимо выбрать для всех объектов, ассоциированных с виртуальной машиной. Если квота для объектов, ассоциированных с виртуальной машиной, не выбрана, то виртуальная машина не будет работать. В этой ситуации Менеджер управления выдает универсальное сообщение об ошибке, поэтому будет проблематично определить, вызвана ли ошибка тем, что вы не ассоциировали квоту со всеми объектами, ассоциированными с виртуальной машиной. Невозможно сделать снимки виртуальных машин, которым не назначена квота. Невозможно создать шаблоны виртуальных машин, виртуальным дискам которых не назначены квоты. |
5.8. Использование квоты для ограничения ресурсов, доступных пользователю
Далее показано, как использовать квоты для ограничения ресурсов, к которым пользователь имеет доступ.
-
Нажмите .
-
Нажмите на имя целевой квоты. Откроется подробное представление.
-
Откройте вкладку Потребители (Consumers).
-
Нажмите Добавить (Add).
-
В поле Поиск (Search) введите имя пользователя, которого хотите ассоциировать с квотой.
-
Нажмите Поиск (GO).
-
Поставьте флажок рядом с именем пользователя.
-
Нажмите OK.
После этого пользователь появится на вкладке Потребители (Consumers) в подробном представлении.
5.9. Изменение квот
Далее показано, как изменять существующие квоты.
-
Нажмите и выберите квоту.
-
Нажмите Изменить (Edit).
-
Измените поля согласно потребностям.
-
Нажмите OK.
5.10. Удаление квот
Далее показано, как удалять квоты.
-
Нажмите и выберите квоту.
-
Нажмите Удалить (Remove).
-
Нажмите OK.
5.11. Принудительное применение политики SLA
Далее показано, как задать SLA для функций ЦП
-
Нажмите .
-
Нажмите Создать (New) или выберите виртуальную машину и нажмите Изменить (Edit).
-
Откройте вкладку Выделение ресурсов (Resource Allocation).
-
Укажите Общие ЦП (CPU Shares). Возможные варианты: Низкий (Low), Средний (Medium), Высокий (High), Настраиваемый (Custom) и Выключено (Disabled). Виртуальные машины c настройкой Высокая (High) получают в два раза больше долей, чем с настройкой Средний (Medium), а виртуальные машины с настройкой Средний (Medium) получают в два раза больше долей, чем виртуальные машины с настройкой Низкий (Low). Настройка Выключено (Disabled) даёт VDSM указание использовать старый алгоритм для распределения долей; как правило, при таких условиях количество распределяемых долей равно 1020.
Вы настроили политику, которая теперь будет регулировать потребление ЦП пользователями.
6. Уведомления о событиях
6.1. Настройка уведомлений о событиях на Портале администрирования
Менеджер управления может отправлять уведомления определенным пользователям по электронной почте при наступлении определенных событий в среде, которой управляет Менеджер управления. Чтобы использовать эту функцию, необходимо настроить агент передачи почты для доставки сообщений. Через Портал администрирования можно настроить только уведомления по электронной почте. Ловушки SNMP должны быть настроены на машине с Менеджером управления.
-
Убедитесь, что у вас есть доступ к почтовому серверу, который может принимать автоматические сообщения от Менеджера управления и доставлять их по списку рассылки.
-
Нажмите и выберите пользователя.
-
Нажмите на Имя пользователя (User Name), чтобы открыть подробное представление.
-
На вкладке Уведомления о событиях (Event Notifier) нажмите Управление событиями (Manage Events).
-
Нажмите на кнопку Развернуть все (Expand All) или специальные кнопки расширения
, чтобы просмотреть события. -
Поставьте необходимые флажки.
-
Укажите адрес электронной почты в поле Получатель почты (Mail Recipient).
Адрес электронной почты может быть указан как адрес электронной почты для текстовых сообщений (например, 1234567890@carrierdomainname.com) или как групповой адрес электронной почты. -
Нажмите OK.
-
На машине с Менеджером управления скопируйте ovirt-engine-notifier.conf в новый файл с именем 90-email-notify.conf:
# cp /usr/share/ovirt-engine/services/ovirt-engine-notifier/ovirt-engine-notifier.conf /etc/ovirt-engine/notifier/notifier.conf.d/90-email-notify.conf -
Измените 90-email-notify.conf и удалите всё, кроме раздела
EMAIL Notifications. -
Введите корректные переменные электронной почты, как в примере ниже. Этот файл переопределяет значения в оригинальном файле ovirt-engine-notifier.conf.
#---------------------# # EMAIL Notifications # #---------------------# # The SMTP mail server address. Required. MAIL_SERVER=myemailserver.example.com # The SMTP port (usually 25 for plain SMTP, 465 for SMTP with SSL, 587 for SMTP with TLS) MAIL_PORT=25 # Required if SSL or TLS enabled to authenticate the user. Used also to specify 'from' user address if mail server # supports, when MAIL_FROM is not set. Address is in RFC822 format MAIL_USER= # Required to authenticate the user if mail server requires authentication or if SSL or TLS is enabled SENSITIVE_KEYS="${SENSITIVE_KEYS},MAIL_PASSWORD" MAIL_PASSWORD= # Indicates type of encryption (none, ssl or tls) should be used to communicate with mail server. MAIL_SMTP_ENCRYPTION=none # If set to true, sends a message in HTML format. HTML_MESSAGE_FORMAT=false # Specifies 'from' address on sent mail in RFC822 format, if supported by mail server. MAIL_FROM=rhevm2017@example.com # Specifies 'reply-to' address on sent mail in RFC822 format. MAIL_REPLY_TO= # Interval to send smtp messages per # of IDLE_INTERVAL MAIL_SEND_INTERVAL=1 # Amount of times to attempt sending an email before failing. MAIL_RETRIES=4Дополнительные параметры см. в файле /etc/ovirt-engine/notifier/notifier.conf.d/README. -
Включите и перезапустите сервис ovirt-engine-notifier, чтобы внесенные изменения вступили в силу:
# systemctl daemon-reload # systemctl enable ovirt-engine-notifier.service # systemctl restart ovirt-engine-notifier.service
Теперь указанный пользователь будет получать сообщения по электронной почте о событиях в среде zVirt. Выбранные события отображаются для этого пользователя на вкладке Уведомления о событиях (Event Notifier).
6.2. Отмена уведомлений о событиях на Портале администрирования
Если пользователь настроил ряд ненужных уведомлений по электронной почте и хочет их отменить, выполните описанную ниже процедуру.
-
Нажмите .
-
Нажмите на Имя пользователя (User Name). Откроется подробное представление.
-
Откройте вкладку Уведомления о событиях (Event Notifier), чтобы увидеть список событий, о которых пользователь получает уведомления по электронной почте.
-
Нажмите Управление событиями (Manage Events).
-
Нажмите кнопку Развернуть все (Expand All) или специальные кнопки расширения
, чтобы просмотреть события. -
Снимите необходимые флажки, чтобы удалить уведомления для этого события.
-
Нажмите OK.
6.3. Параметры уведомлений о событиях в ovirt-engine-notifier.conf
Файл конфигурации службы уведомлений о событиях находится в /usr/share/ovirt-engine/services/ovirt-engine-notifier/ovirt-engine-notifier.conf.
| Имя переменной | Default (По умолчанию) | Примечания | ||
|---|---|---|---|---|
SENSITIVE_KEYS |
Нет |
Разделенный запятыми список ключей, которые не будут регистрироваться. |
||
JBOSS_HOME |
/opt/rh/eap7/root/usr/share/wildfly |
Местонахождение сервера приложений JBoss, используемого Менеджером управления. |
||
ENGINE_ETC |
/etc/ovirt-engine |
Местонахождение каталога etc, используемого Менеджером управления. |
||
ENGINE_LOG |
/var/log/ovirt-engine |
Местонахождение каталога logs, используемого Менеджером управления. |
||
ENGINE_USR |
/usr/share/ovirt-engine |
Местонахождение каталога usr, используемого Менеджером управления. |
||
ENGINE_JAVA_MODULEPATH |
${ENGINE_USR}/modules |
Полный путь для подсоединения модулей JBoss. |
||
NOTIFIER_DEBUG_ADDRESS |
Нет |
Адрес машины, которую можно использовать для удаленной отладки виртуальной машины Java, используемой службой уведомлений. |
||
NOTIFIER_STOP_TIME |
30 |
Время (в секундах), после которого истечет время ожидания службы. |
||
NOTIFIER_STOP_INTERVAL |
1 |
Время (в секундах), на которое увеличивается значение счетчика времени ожидания. |
||
INTERVAL_IN_SECONDS |
120 |
Интервал (в секундах) между ситуациями отправки сообщений подписчикам. |
||
IDLE_INTERVAL |
30 |
Интервал (в секундах), в который будут выполняться задачи с низким приоритетом. |
||
DAYS_TO_KEEP_HISTORY |
0 |
Эта переменная задает количество дней, в течение которых отправленные события будут сохраняться в таблице истории. Если эта переменная не задана, события остаются в таблице истории в течение неограниченно долгого времени. |
||
FAILED_QUERIES_NOTIFICATION_THRESHOLD |
30 |
Количество неудачных запросов, после которого отправляется уведомление по электронной почте. Уведомление по электронной почте отправляется после первой неудачной попытки доставки уведомлений, а затем каждый раз, когда достигается количество неудачных попыток, указанное этой переменной. Если указать значение 0 или 1, сообщение по электронной почте будет отсылаться при каждой неудачной попытке. |
||
FAILED_QUERIES_NOTIFICATION_RECIPIENTS |
Нет |
Адреса электронной почты получателей, которым будут отправляться уведомления. Адреса электронной почты должны быть разделены запятыми. Этот параметр стал устаревшим после введения переменной FILTER. |
||
DAYS_TO_SEND_ON_STARTUP |
0 |
Давность (в днях) старых событий, которые будут обработаны и отправлены при запуске службы уведомлений. |
||
FILTER |
exclude:* |
Алгоритм, используемый для определения триггеров и получателей уведомлений по электронной почте. Значение этой переменной представляет собой комбинацию операторов включить (include) или исключить (exclude), события и получателя. Например, |
||
MAIL_SERVER |
Нет |
Адрес почтового сервера SMTP. Обязательный параметр. |
||
MAIL_PORT |
25 |
Порт, используемый для связи. Возможные значения: |
||
MAIL_USER |
Нет |
Если для аутентификации пользователя включен SSL, то эту переменную нужно задать. Эта переменная также используется для указания адреса пользователя-отправителя, когда переменная MAIL_FROM не задана. Некоторые почтовые серверы не поддерживают эту функцию. Адрес имеет формат RFC822. |
||
SENSITIVE_KEYS |
${SENSITIVE_KEYS},MAIL_PASSWORD |
Требуется для аутентификации пользователя, если почтовый сервер требует аутентификации или если SSL или TLS включены. |
||
MAIL_PASSWORD |
Нет |
Требуется для аутентификации пользователя, если почтовый сервер требует аутентификации или если SSL или TLS включены. |
||
MAIL_SMTP_ENCRYPTION |
Нет |
Тип шифрования, который должен использоваться для связи. Возможные значения: |
||
HTML_MESSAGE_FORMAT |
false |
Почтовый сервер отправляет сообщения в формате HTML, если эта переменная установлена в значение |
||
MAIL_FROM |
Нет |
Эта переменная указывает адрес отправителя в формате RFC822, если он поддерживается почтовым сервером. |
||
MAIL_REPLY_TO |
Нет |
Эта переменная указывает адреса получателя в формате RFC822 для отправляемых писем, если это поддерживается почтовым сервером. |
||
MAIL_SEND_INTERVAL |
1 |
Число SMTP-сообщений, которые должны отправляться в каждый IDLE_INTERVAL |
||
MAIL_RETRIES |
4 |
Количество попыток отправить электронное сообщение, пока не будет признан факт неудачи. |
||
SNMP_MANAGERS |
Нет |
IP-адреса или FQDN машин, которые будут действовать как менеджеры SNMP. Записи должны быть разделены пробелами и могут содержать номер порта. Например, |
||
SNMP_COMMUNITY |
public |
(только SNMP версии 2) SNMP Community. |
||
SNMP_OID |
1.3.6.1.4.1.2312.13.1.1 |
Идентификаторы объектов-ловушек по умолчанию для оповещений. Когда этот OID определен, все типы ловушек отправляются менеджеру SNMP, дополненные информацией о событии. Обратите внимание, что в случае изменения ловушки по умолчанию сгенерированные ловушки не будут соответствовать информационной базе управления Менеджера управления. |
||
SNMP_VERSION |
2 |
Определяет, какую версию SNMP следует использовать. Поддерживаются ловушки SNMP версий 2 и 3. Возможные значения: 2 или 3. |
||
SNMP_ENGINE_ID |
Нет |
(SNMPv3) Идентификатор Менеджера управления, используемый для ловушек SNMPv3. Это уникальный идентификатор устройства, подключенного через SNMP. |
||
SNMP_USERNAME |
Нет |
(SNMPv3) Имя пользователя, используемое для ловушек SNMPv3. |
||
SNMP_AUTH_PROTOCOL |
Нет |
(SNMPv3) Протокол авторизации SNMPv3. Возможные значения: |
||
SNMP_AUTH_PASSPHRASE |
Нет |
(SNMPv3) Парольная фраза, используемая, когда для SNMP_SECURITY_LEVEL задано значение |
||
SNMP_PRIVACY_PROTOCOL |
Нет |
(SNMPv3) Протокол обеспечения конфиденциальности SNMPv3. Возможные значения:
|
||
SNMP_PRIVACY_PASSPHRASE |
Нет |
Парольная фраза обеспечения конфиденциальности SNMPv3, используемая, когда для SNMP_SECURITY_LEVEL задано значение |
||
SNMP_SECURITY_LEVEL |
1 |
(SNMPv3) Уровень безопасности SNMPv3. Возможные значения:
|
||
ENGINE_INTERVAL_IN_SECONDS |
300 |
Интервал (в секундах) между операциями мониторинга машины, на которой установлен Менеджер управления. Этот интервал измеряется с момента завершения мониторинга. |
||
ENGINE_MONITOR_RETRIES |
3 |
Количество предпринимаемых службой уведомлений попыток проверить статус машины, на которой установлен Менеджер управления, в заданном интервале после неудачи. |
||
ENGINE_TIMEOUT_IN_SECONDS |
30 |
Время (в секундах), которое необходимо выждать, прежде чем служба уведомлений предпримет попытку проверить статус машины, на которой установлен Менеджер управления, в заданном интервале после неудачи. |
||
IS_HTTPS_PROTOCOL |
false |
Этот параметр должен быть установлен в значение |
||
SSL_PROTOCOL |
TLS |
Протокол, используемый коннектором конфигурации JBoss, когда включен SSL. |
||
SSL_IGNORE_CERTIFICATE_ERRORS |
false |
Этот параметр должен быть установлен в значение |
||
SSL_IGNORE_HOST_VERIFICATION |
false |
Этот параметр должен быть установлен в значение |
||
REPEAT_NON_RESPONSIVE_NOTIFICATION |
false |
Эта переменная указывает, будут ли подписчикам отправляться повторные сообщения о неудачных попытках, если машина, на которой установлен Менеджер управления, не отвечает. |
||
ENGINE_PID |
/var/lib/ovirt-engine/ovirt-engine.pid |
Путь и имя PID-файла Менеджера управления. |
6.4. Настройка Менеджера управления на отправку ловушек SNMP
Настройте Менеджер управления на отправку ловушек SNMP одному или нескольким внешним менеджерам SNMP. Ловушки SNMP содержат информацию о системных событиях; они используются для мониторинга среды zVirt. Количество и тип ловушек, отправляемых менеджеру SNMP, можно задать в Менеджере управления.
zVirt поддерживает SNMP версий 2 и 3. SNMP версии 3 поддерживает следующие уровни безопасности:
-
NoAuthNoPriv (1) - Ловушки SNMP отправляются без какой-либо авторизации или конфиденциальности.
-
AuthNoPriv (2) - Ловушки SNMP отправляются с авторизацией по паролю, но без конфиденциальности.
-
AuthPriv (3) - Ловушки SNMP отправляются с авторизацией по паролю и с конфиденциальностью.
-
Один или несколько внешних менеджеров SNMP настроены на получение ловушек.
-
IP-адреса или FQDN машин, которые будут действовать как менеджеры SNMP. При желании задайте порт, через который Менеджер управления получает уведомления о ловушках. По умолчанию: UDP-порт
162. -
SNMP Community (только для SNMP версии 2). Несколько менеджеров SNMP могут принадлежать одному сообществу. Системы управления и агенты могут взаимодействовать, только если они находятся в одном сообществе. Сообщество по умолчанию –
public. -
Идентификатор объекта-ловушки для оповещений. OID, который Менеджер управления предоставляет по умолчанию –
1.3.6.1.4.1.2312.13.1.1. Когда этот OID задан, все типы ловушек отправляются менеджеру SNMP, дополненные информацией о событии. Обратите внимание, что в случае изменения ловушки по умолчанию сгенерированные ловушки не будут соответствовать информационной базе управления Менеджера управления. -
Имя пользователя SNMP, для SNMP версии 3, уровни безопасности 1, 2 и 3.
-
Парольная фраза SNMP, для SNMP версии 3, уровни безопасности 2 и 3.
-
Парольная фраза обеспечения конфиденциальности SNMP, для SNMP версии 3, уровень безопасности 3.
| Менеджер управления предоставляет следующие информационные базы управления (MIB): /usr/share/doc/ovirt-engine/mibs/OVIRT-MIB.txt и /usr/share/doc/ovirt-engine/mibs/REDHAT-MIB.txt. Прежде чем продолжать, загрузите MIB в менеджер SNMP. |
Значения параметров конфигурации SNMP по умолчанию имеются в Менеджере управления в файле конфигурации сервиса уведомлений о событиях /usr/share/ovirt-engine/services/ovirt-engine-notifier/ovirt-engine-notifier.conf. Значения, приведенные в следующей процедуре, основаны на значениях по умолчанию или взятых для примера значениях, представленных в этом файле. Не изменяйте этот файл напрямую, так как системные изменения, такие как обновления, могут аннулировать любые внесенные в этот файл изменения. Вместо этого скопируйте этот файл в /etc/ovirt-engine/notifier/notifier.conf.d/\<integer\>-snmp.conf, где \<integer\> – это число, указывающее приоритет, с которым должен выполняться этот файл.
-
В Менеджере управления создайте файл конфигурации SNMP с именем \<integer\>-snmp.conf, где \<integer\> – это целое число, указывающее порядок обработки файлов. Например:
# vi /etc/ovirt-engine/notifier/notifier.conf.d/20-snmp.confСкопируйте настройки SNMP по умолчанию из файла конфигурации сервиса уведомлений о событиях /usr/share/ovirt-engine/services/ovirt-engine-notifier/ovirt-engine-notifier.conf. В этом файле есть комментарии по всем настройкам. -
Укажите менеджера(ов) SNMP, SNMP Community (только для SNMP версии 2) и OID в формате, приведенном в этом примере:
SNMP_MANAGERS="_manager1.example.com_ _manager2.example.com:162_" SNMP_COMMUNITY=public SNMP_OID=1.3.6.1.4.1.2312.13.1.1 -
Укажите, какую версию SNMP следует использовать: 2 (по умолчанию) или 3:
SNMP_VERSION=3 -
Укажите значение для
SNMP_ENGINE_ID. Например:SNMP_ENGINE_ID="80:00:00:00:01:02:05:05" -
В случае SNMP версии 3 укажите уровень безопасности для ловушек SNMP:
-
Уровень безопасности 1, ловушки NoAuthNoPriv:
SNMP_USERNAME=NoAuthNoPriv SNMP_SECURITY_LEVEL=1 -
Уровень безопасности 2, ловушки AuthNoPriv, пользователь ovirtengine, парольная фраза для аутентификации по SNMP authpass.
SNMP_USERNAME=ovirtengine SNMP_AUTH_PROTOCOL=MD5 SNMP_AUTH_PASSPHRASE=authpass SNMP_SECURITY_LEVEL=2 -
Уровень безопасности 3, ловушки AuthPriv, пользователь ovirtengine, парольная фраза для аутентификации по SNMP authpass и парольная фраза для обеспечения конфиденциальности по SNMP privpass. Например:
SNMP_USERNAME=ovirtengine SNMP_AUTH_PROTOCOL=MD5 SNMP_AUTH_PASSPHRASE=authpass SNMP_PRIVACY_PROTOCOL=AES128 SNMP_PRIVACY_PASSPHRASE=privpass SNMP_SECURITY_LEVEL=3
-
-
Определите, какие события следует отправлять менеджеру SNMP:
Примеры
Пример 11. Отправлять все события на SNMP-профиль, заданный по умолчаниюFILTER="include:*(snmp:) ${FILTER}"Пример 12. Отправлять все события со степенью серьезности ОШИБКА (ERROR) или ОПОВЕЩЕНИЕ (ALERT) на SNMP-профиль, заданный по умолчаниюFILTER="include:*:ERROR(snmp:) ${FILTER}" FILTER="include:*:ALERT(snmp:) ${FILTER}"Пример 13. Отправлять события для VDC_START на указанный адрес электронной почтыFILTER="include:__VDC_START__(snmp:__mail@example.com__) ${FILTER}"Пример 14. Отправлять события для всего, кроме VDC_START, на SNMP-профиль, заданный по умолчаниюFILTER="exclude:__VDC_START__ include:*(snmp:) ${FILTER}"Это фильтр по умолчанию, определенный в ovirt-engine-notifier.conf; если не выключить этот фильтр или не применить переопределяющие его фильтры, то никакие уведомления не будут отсылаться:
FILTER="exclude:*"VDC_START– это пример сообщений журнала аудита. Полный список сообщений журнала аудита содержится в /usr/share/doc/ovirt-engine/AuditLogMessages.properties. Либо отфильтруйте результаты в менеджере SNMP. -
Сохраните файл.
-
Запустите службу ovirt-engine-notifier и убедитесь, что она запускается при загрузке:
# systemctl start ovirt-engine-notifier.service # systemctl enable ovirt-engine-notifier.service
Проверьте менеджер SNMP, чтобы убедиться в получении ловушек.
| Для работы службы уведомлений нужно, чтобы SNMP_MANAGERS, MAIL_SERVER или оба параметра были должным образом определены в /usr/share/ovirt-engine/services/ovirt-engine-notifier/ovirt-engine-notifier.conf либо в переопределяющем файле. |
В этом примере файла конфигурации за основу взяты настройки в ovirt-engine-notifier.conf. Выделенный файл конфигурации SNMP (такой, как этот) переопределяет настройки в ovirt-engine-notifier.conf.
| Скопируйте настройки SNMP по умолчанию из файла конфигурации сервиса уведомлений о событиях /usr/share/ovirt-engine/services/ovirt-engine-notifier/ovirt-engine-notifier.conf в /etc/ovirt-engine/notifier/notifier.conf.d/<integer>-snmp.conf, где <integer> – число, указывающее приоритет, с которым должен выполняться файл. В этом файле есть комментарии по всем настройкам. |
SNMP_MANAGERS="manager1.example.com manager2.example.com:162" (1) SNMP_COMMUNITY=public (2) SNMP_OID=1.3.6.1.4.1.2312.13.1.1 (3) FILTER="include:*(snmp:)" (4) SNMP_VERSION=3 (5) SNMP_ENGINE_ID="80:00:00:00:01:02:05:05" (6) SNMP_USERNAME=<username> (7) SNMP_AUTH_PROTOCOL=MD5 (8) SNMP_AUTH_PASSPHRASE=<authpass> (9) SNMP_PRIVACY_PROTOCOL=AES128 (10) SNMP_PRIVACY_PASSPHRASE=<privpass> (11) SNMP_SECURITY_LEVEL=3 (12)
| 1 | IP-адреса или FQDN машин, которые будут действовать как менеджеры SNMP. Записи должны быть разделены пробелами и могут содержать номер порта. Например, manager1.example.com manager2.example.com:164 |
| 2 | (только SNMP версии 2) строка по умолчанию для SNMP Community. |
| 3 | Идентификатор объекта-ловушки SNMP для исходящих уведомлений. iso(1) org(3) dod(6) internet(1) private(4) enterprises(1) redhat(2312) ovirt(13) engine(1) notifier(1) |
| 4 | Алгоритм, используемый для определения триггеров и получателей уведомлений SNMP. |
| 5 | Версия SNMP. Поддерживаются ловушки SNMP версий 2 и 3. 2 = SNMPv2, 3 = SNMPv3. |
| 6 | (только SNMP версии 3) Идентификатор engine, используемый для ловушек SNMP. |
| 7 | (только SNMP версии 3) Имя пользователя, используемое для ловушек SNMP. |
| 8 | (только SNMP версии 3) Протокол авторизации SNMP. Поддерживаемые значения – MD5 и SHA. Требуется, когда параметр SNMP_SECURITY_LEVEL установлен в значение 2 (AUTH_NOPRIV) или 3 (AUTH_PRIV). |
| 9 | (только SNMP версии 3) Парольная фраза для авторизации по SNMP. Требуется, когда параметр SNMP_SECURITY_LEVEL установлен в значение 2 (AUTH_NOPRIV) или 3 (AUTH_PRIV). |
| 10 | (только SNMP версии 3) Протокол обеспечения конфиденциальности SNMP. Поддерживаемые значения – AES128, AES192 и AES256. Имейте в иду, что протоколы AES192 и AES256 не заданы в RFC3826, поэтому перед их включением убедитесь, что ваш SNMP-сервер поддерживает их. Требуется, когда параметр SNMP_SECURITY_LEVEL установлен в значение 3 (AUTH_PRIV). |
| 11 | (только SNMP версии 3) Парольная фраза обеспечения конфиденциальности SNMP. Требуется, когда параметр SNMP_SECURITY_LEVEL установлен в значение 3 (AUTH_PRIV). |
| 12 | (только SNMP версии 3) Уровень безопасности SNMP. 1 = NOAUTH_NOPRIV, 2 = AUTH_NOPRIV, 3 = AUTH_PRIV. |
7. Утилиты
7.1. Инструмент переименования oVirt Engine Rename
7.1.1. Инструмент переименования oVirt Engine Rename
Когда команда engine-setup выполняется в чистой среде, она генерирует ряд сертификатов и ключей, которые используют FQDN Менеджера управления, сообщенное во время установки. Если FQDN Менеджера управления впоследствии потребуется изменить (например, из-за переноса машины с Менеджером управления в другой домен), то записи об FQDN должны быть обновлены, чтобы отразить новое имя. Команда ovirt-engine-rename автоматизирует эту задачу.
Команда ovirt-engine-rename обновляет записи об FQDN Менеджера управления в следующих местах:
-
/etc/ovirt-engine/engine.conf.d/10-setup-protocols.conf
-
/etc/ovirt-engine/isouploader.conf.d/10-engine-setup.conf
-
/etc/ovirt-engine/logcollector.conf.d/10-engine-setup.conf
-
/etc/pki/ovirt-engine/cert.conf
-
/etc/pki/ovirt-engine/cert.template
-
/etc/pki/ovirt-engine/certs/apache.cer
-
/etc/pki/ovirt-engine/keys/apache.key.nopass
-
/etc/pki/ovirt-engine/keys/apache.p12
|
В процессе обновления прежний FQDN должен разрешаться с помощью DNS. Если в процессе работы ovirt-engine-rename завершается с ошибкой:
необходимо добавить прежний FQDN в файл Команда После выполнения процедуры смены FQDN менеджера управления не удаляйте старое имя хоста из файла /etc/hosts, так как оно необходимо для корректной работы внутренних служб менеджера управления. |
7.1.2. Синтаксис команды переименования oVirt Engine Rename
Базовый синтаксис команды ovirt-engine-rename:
# /usr/share/ovirt-engine/setup/bin/ovirt-engine-rename
Команда также может принимать некоторые параметры.
| Параметр | Описание |
|---|---|
|
Позволяет указать новое FQDN для Менеджера управления без взаимодействия с пользователем. |
|
Позволяет указать путь и имя файла, в который должны быть записаны журналы операции переименования. |
|
Позволяет указать путь и имя файла конфигурации для загрузки в операцию переименования. |
|
Позволяет указать путь и имя файла конфигурации для подключения к операции переименования. Этот параметр можно использовать для указания пути и имени существующего файла ответов для автоматизации операции переименования. |
|
Позволяет указать путь и имя файла, в который записываются ответы и значения, измененные командой |
7.1.3. Переименование Менеджера управления с помощью инструмента oVirt Engine Rename
Можно использовать команду ovirt-engine-rename для обновления записей об FQDN Менеджера управления.
Инструмент проверяет, предоставляет ли Менеджер управления локальный домен ISO или домен хранения данных. Если да, то прежде чем продолжить операцию, инструмент предлагает пользователю извлечь, выключить или перевести в режим обслуживания любую виртуальную машину или домен хранения, подключенный к хранилищу. Это гарантирует, что виртуальные машины не потеряют связь со своими виртуальными дисками, а домены хранения ISO не потеряют связь во время процесса переименования.
-
Подготовьте все DNS и другие соответствующие записи для нового FQDN.
-
Если используется DHCP, обновите конфигурацию DHCP-сервера.
-
Обновите имя хоста в Менеджере управления.
-
Выполните следующую команду:
# /usr/share/ovirt-engine/setup/bin/ovirt-engine-rename -
При появлении запроса нажмите Ввод (Enter), чтобы остановить службу engine:
During execution engine service will be stopped (OK, Cancel) [OK]: -
При появлении запроса введите новое FQDN для Менеджера управления:
New fully qualified server name:__new_engine_fqdn__
Команда ovirt-engine-rename обновит записи FQDN Менеджера управления.
Для hosted engine выполните следующие дополнительные шаги:
-
Выполните следующую команду на каждом существующем узле с ролью hosted engine
:# hosted-engine --set-shared-config fqdn __new_engine_fqdn__ --type=he_localЭта команда изменяет FQDN в локальной копии файла /etc/ovirt-hosted-engine-ha/hosted-engine.conf, имеющейся на каждом узле с ролью hosted engine
. -
Выполните следующую команду на одном из узлов с ролью hosted engine
:# hosted-engine --set-shared-config fqdn __new_engine_fqdn__ --type=he_sharedЭта команда изменяет FQDN в мастер-копии файла /etc/ovirt-hosted-engine-ha/hosted-engine.conf в общем домене хранения.
Теперь все новые и существующие узлы с ролью hosted engine
используют новое FQDN.
7.2. Инструмент Engine-config
7.2.1. Инструмент Engine-config
Инструмент Engine-config – это утилита командной строки для настройки глобальных параметров среды zVirt. Инструмент взаимодействует со списком сопоставлений "ключ-значение", которые хранятся в базе данных engine, и позволяет извлекать и задавать значения отдельных ключей, а также извлекать список всех доступных ключей и значений конфигурации. Кроме того, для каждого уровня конфигурации в среде zVirt могут храниться разные значения.
| Чтобы извлечь или задать значение ключа конфигурации, не нужно запускать ни Менеджер управления, ни WildFly. Поскольку сопоставления "ключ-значение" конфигурации хранятся в базе данных engine, их можно обновлять при работающей службе postgresql. Затем изменения применяются при перезапуске службы ovirt-engine. |
7.2.2. Синтаксис команды engine-config
Можно запустить инструмент engine-config с машины, на которой установлен Менеджер управления. Для получения подробной информации об использовании смотрите справку для команды:
# engine-config --help
Часто встречающиеся задачи:
-
Перечислить доступные ключи конфигурации
# engine-config --list -
Перечислить доступные значения конфигурации
# engine-config --all -
Извлечь значение ключа конфигурации
# engine-config --get _KEY_NAME_Вместо
KEY_NAMEукажите имя нужного ключа, чтобы извлечь значение для заданной версии ключа. С помощью параметра--cverукажите версию конфигурации, для которой нужно извлечь значение. Если версия не указана, будут возвращены значения для всех существующих версий. -
Задать значение ключа конфигурации
# engine-config --set _KEY_NAME_=_KEY_VALUE_ --cver=_VERSION_Вместо
KEY_NAMEукажите имя конкретного ключа, значение которого нужно задать, а вместоKEY_VALUE– значение, которое нужно задать. В средах, где имеется несколько версий конфигурации, необходимо указатьVERSION. -
Перезапустите службу ovirt-engine, чтобы изменения вступили в силу.
# systemctl restart ovirt-engine.service
7.3. Инструмент Engine Vacuum
7.3.1. Инструмент Engine Vacuum
Инструмент Engine Vacuum поддерживает базы данных PostgreSQL, обновляя таблицы, удаляя неиспользуемые строки и тем самым позволяя повторно использовать дисковое пространство. Информацию о команде VACUUM и ее параметрах см. в документации на PostgreSQL.
Команда Engine Vacuum – engine-vacuum. Необходимо авторизоваться в системе как root-пользователь и ввести учетные данные администратора для среды zVirt.
Как альтернативный вариант, можно запустить инструмент Engine Vacuum командой engine-setup, чтобы задать свои параметры для существующей инсталляции:
$ engine-setup
...
[ INFO ] Stage: Environment customization
...
Perform full vacuum on the engine database engine@localhost?
This operation may take a while depending on this setup health and the
configuration of the db vacuum process.
See https://www.postgresql.org/docs/12/static/sql-vacuum.html
(Yes, No) [No]:
Опция Yes запускает инструмент Engine Vacuum в режиме полной очистки.
7.3.2. Режимы работы Engine Vacuum
Инструмент Engine Vacuum имеет два режима работы:
-
Стандартная очистка
Рекомендуется регулярно проводить стандартную очистку.
Стандартная очистка удаляет неиспользуемые версии строк в таблицах и индексах и помечает пространство как доступное для повторного использования в будущем. Для часто обновляемых таблиц очистку следует проводить регулярно. Однако функция стандартной очистки не возвращает пространство операционной системе.
Стандартная очистка без указания параметров обрабатывает каждую таблицу в текущей базе данных.
-
Полная очистка
Полную очистку рекомендуется проводить не регулярно, а тогда, когда нужно вернуть операционной системе значительную часть пространства из объема, занимаемого таблицей. Полная очистка сжимает таблицы путем записи новой копии файла таблицы без неиспользуемого места, тем самым позволяя операционной системе вернуть пространство. Полная очистка может занять много времени.
Полная очистка требует дополнительного места на диске для новой копии таблицы, пока операция не завершится и старая копия не будет удалена. Поскольку полная очистка требует полной блокировки таблицы, ее нельзя запускать одновременно с другими операциями, касающимися использования таблицы.
7.3.3. Синтаксис команды engine-vacuum
Базовый синтаксис команды engine-vacuum:
# engine-vacuum
# engine-vacuum _option_
Запуск команды engine-vacuum без параметров выполняет стандартную очистку.
Команду engine-vacuum можно уточнить с помощью ряда параметров.
| Параметр | Описание |
|---|---|
|
Выводит информацию о том, как использовать команду engine-vacuum. |
|
Запускает стандартную очистку, анализирует базу данных и обновляет статистику оптимизатора. |
|
Анализирует базу данных и обновляет статистику оптимизатора, не выполняя очистку. |
|
Запускает полную очистку. |
|
Задает режим детализации консольного вывода. |
|
Выполняет очистку конкретной таблицы или таблиц. Например:
|
7.4. Инструмент сопоставления VDSM с именем сети
Если имя логической сети длиннее 15 знаков или содержит знаки, отличные от ASCII, то система автоматически сгенерирует имя имя-идентификатор для использования на хосте (vdsm_name), состоящее из букв on и первых 13 знаков уникального идентификатора сети, например, ona1b2c3d4e5f6g. Именно это имя отображается в файлах журналов хоста. Чтобы просмотреть список имен логических сетей и их автоматически сгенерированных имен сетей, используйте инструмент сопоставления VDSM с именами сетей, расположенный в /usr/share/ovirt-engine/bin/.
-
При первом запуске инструмента определите переменную среды
PASSWORD, которая представляет собой пароль пользователя базы данных с доступом на чтение к базе данных Менеджера управления. Например, запустите:# export PASSWORD=_DatabaseUserPassword_ -
Запустите инструмент сопоставления VDSM с именем сети:
# /usr/share/ovirt-engine/bin/vdsm_to_network_name_map --user USERгде
USER– пользователь базы данных с доступом на чтение к базе данных Менеджера управления, чей пароль назначен для переменной средыPASSWORD.
Инструмент отображает список имен логических сетей, сопоставленных с их эквивалентными идентификаторами, используемыми на хостах.
- Дополнительные параметры
-
Можно запустить инструмент со следующими параметрами:
-
--host– имя хоста/IP-адрес сервера баз данных. Значение по умолчанию –localhost. -
--port– номер порта сервера баз данных. Значение по умолчанию –5432. -
--database– имя базы данных. Значение по умолчанию – engine, представляющий собой базу данных Менеджера управления. -
--secure– разрешает безопасное подключение к базе данных. По умолчанию инструмент запускается без безопасного подключения.
-
7.5. Инструмент Log Collector
7.5.1. Инструмент Log Collector
| Перед началом работы с Log Collector необходимо на машину с Менеджером управления установить пакет ovirt-log-collector |
Инструмент сбора журналов позволяет легко собирать соответствующие журналы из среды zVirt при обращении в службу поддержки.
Команда сбора журналов: ovirt-log-collector. Необходимо авторизоваться в системе Менеджера управления как root-пользователь и ввести учетные данные администратора для среды zVirt. Команда ovirt-log-collector -h отображает информацию об использовании, включая список всех действительных опций для команды ovirt-log-collector.
7.5.2. Синтаксис команды ovirt-log-collector
Базовый синтаксис команды сбора журналов:
# ovirt-log-collector _options_ list _all|clusters|datacenters_
# ovirt-log-collector _options_ collect
Поддерживаются два режима работы: вывести список (list) и собрать (collect).
-
Параметр вывести список (
list) выводит список хостов, кластеров или центров данных, подключенных к Менеджеру управления. Вы можете фильтровать сбор журналов по перечисленным объектам. -
Параметр собрать (
collect) выполняет сбор журналов из Менеджера управления. Собранные журналы помещаются в архивный файл в каталоге /tmp/logcollector. Командаovirt-log-collectorприсваивает каждому журналу свое имя файла.
Если не указан другой параметр, то действие по умолчанию – вывести список доступных хостов вместе с центром данных и кластером, к которым они относятся. Для получения конкретных журналов система предложит ввести имена пользователей и пароли.
Команду ovirt-log-collector можно уточнить с помощью ряда параметров.
| Параметр | Описание |
|---|---|
|
Отображает номер версии используемой команды и возвращает к приглашению к вводу. |
|
Отображает информацию об использовании команды и возвращает к приглашению к вводу. |
|
Задает PATH в качестве файла конфигурации, который должен использовать инструмент. |
|
Задает PATH в качестве каталога для сохранения журналов. Каталог по умолчанию – /tmp/logcollector. |
|
Задает TICKET в качестве зарегистрированной заявки (или номера инцидента), которую нужно ассоциировать с SOS-отчетом. |
|
Задает FTP_SERVER в качестве приемника для извлеченных журналов, отправляемых по FTP. Не используйте эту опцию, если это не рекомендовано представителем службы поддержки zVirt. |
|
Задает PATH в качестве конкретного имени файла, который команда должна использовать для вывода журнала. |
|
Задает тихий режим, сводя консольный вывод к минимуму. По умолчанию тихий режим выключен. |
|
Задает режим детализации консольного вывода. По умолчанию режим детализации выключен. |
|
Отображает только информацию о расхождениях во времени между хостами без генерации полного SOS-отчета. |
Параметры Менеджера управления
В соответствии с этими параметрами выполняется фильтрация при сборе журналов и указывается подробная информация об аутентификации для Менеджера управления.
Эти параметры можно комбинировать для получения определенных команд. Например, ovirt-log-collector --user=admin@internal --cluster ClusterA,ClusterB --hosts "SalesHost" указывает *admin@internal в качестве пользователя и ограничивает сбор журналов только хостами SalesHost в кластерах A и B.
| Параметр | Описание |
|---|---|
|
Исключает хосты виртуализации из сбора журналов. |
|
Собирает журналы одного хоста (SPM, если он есть) из каждого кластера. |
|
Задает имя пользователя для авторизации. USER указывается в формате user@domain, где user – имя пользователя, а domain – используемый домен служб каталогов. Пользователь должен существовать в службах каталогов и быть известен Менеджеру управления. |
|
Задает FQDN Менеджера управления, из которого будут собираться журналы, где FQDN нужно заменить на FQDN Менеджера управления. Предполагается, что сборщик журналов работает на том же локальном хосте, что и Менеджер управления; значение по умолчанию – localhost. |
|
Собирает журналы с хостов виртуализации в указанном кластере (CLUSTER) в дополнение к журналам из Менеджера управления. Охватываемые кластер(ы) следует указать в списке имен кластеров или паттернов сопоставления (match patterns) через запятую. |
|
Собирает журналы с хостов виртуализации в указанном центре данных (DATACENTER) в дополнение к журналам из Менеджера управления. Охватываемые центр(ы) данных следует указать в списке имен кластеров или паттернов сопоставления (match patterns) через запятую. |
|
Собирает журналы с хостов виртуализации в указанном списке хостов (HOSTS_LIST) в дополнение к журналам из Менеджера управления. Охватываемые хосты следует указать в списке имен хостов, FQDN или IP-адресов через запятую. Паттерны сопоставления (match patterns) тоже подходят. |
Конфигурация SSH
Параметры в группе конфигурации SSH можно использовать для указания максимального количества одновременных SSH-подключений к гипервизору (гипервизорам) для сбора журналов, порта SSH и используемого файла идентификации.
| Параметр | Описание |
|---|---|
|
Задает PORT в качестве порта, который следует использовать для SSH-подключений к хостам виртуализации. |
|
Задает KEYFILE в качестве открытого SSH-ключа, который следует использовать для доступа к хостам виртуализации. |
|
Задает MAX_CONNECTIONS в качестве максимального количества параллельных SSH-подключений для журналов от хостов виртуализации. Значение по умолчанию = 10. |
Параметры базы данных PostgreSQL
Имя пользователя базы данных и имя базы данных должны быть указаны с использованием параметров pg-user и dbname, если они были изменены относительно значений по умолчанию.
Если база данных находится не на локальном хосте, то используйте параметр pg-dbhost. Для сбора удаленных журналов используйте необязательный параметр pg-host-key. Чтобы удаленный сбор журналов был успешным, на сервере баз данных должен быть установлен SOS-плагин PostgreSQL.
| Параметр | Описание |
|---|---|
|
Выключает сбор журналов из базы данных. Сборщик журналов подключится к базе данных PostgreSQL Менеджера управления и включит данные в отчет о журналах, если только не указан параметр --no-postgresql. |
|
Задает USER в качестве имени пользователя, которое следует использовать для подключения к серверу баз данных. Значение по умолчанию = postgres. |
|
Задает DBNAME в качестве имени базы данных, которое следует использовать для подключения к серверу баз данных. Значение по умолчанию = engine. |
|
Задает DBHOST в качестве имени хоста для сервера баз данных. Значение по умолчанию = localhost. |
|
Задает KEYFILE в качестве открытого идентификационного файла (закрытого ключа) для сервера баз данных. Это значение не устанавливается по умолчанию; оно требуется только в том случае, если база данных не существует на локальном хосте. |
7.5.3. Основные сведения об использовании сборщика журналов (Log Collector)
Когда команда ovirt-log-collector выполняется без указания дополнительных параметров, по умолчанию она собирает все журналы из Менеджера управления и подключенных к нему хостов. Она также собирает журналы баз данных, если только не добавлен параметр --no-postgresql. В следующем примере сборщик журналов запускается для сбора всех журналов из Менеджера управления и трех подключенных хостов.
# ovirt-log-collector
INFO: Gathering oVirt Engine information...
INFO: Gathering PostgreSQL the oVirt Engine database and log files from localhost...
Please provide REST API password for the admin@internal oVirt Engine user (CTRL+D to abort):
About to collect information from 3 hypervisors. Continue? (Y/n):
INFO: Gathering information from selected hypervisors...
INFO: collecting information from 192.168.122.250
INFO: collecting information from 192.168.122.251
INFO: collecting information from 192.168.122.252
INFO: finished collecting information from 192.168.122.250
INFO: finished collecting information from 192.168.122.251
INFO: finished collecting information from 192.168.122.252
Creating compressed archive...
INFO Log files have been collected and placed in /tmp/logcollector/sosreport-rhn-account-20110804121320-ce2a.tar.xz.
The MD5 for this file is 6d741b78925998caff29020df2b2ce2a and its size is 26.7M