Резервные копии и миграция

В данной главе рассмотрен процесс создания резервных копий СУСВ и восстановление СУСВ из резервных копий.

Обзор создания резервных копий СУСВ

Для регулярного резервного копирования СУСВ необходимо использовать утилиту engine-backup. Утилита создает резервные копии БД СУСВ и файлов конфигурации в одном файле, и ее можно запускать без прерывания работы службы ovirt-engine.

Синтаксис команды engine-backup

Команда engine-backup работает в одном из двух базовых режимов:

engine-backup --mode=backup
engine-backup --mode=restore

Эти два режима можно расширить набором параметров, позволяющих уточнить область данных для резервного копирования, а также указать различные учетные данные для БД СУСВ. Полный список параметров и их назначение можно просмотреть, выполнив команду:

engine-backup --help

Базовые параметры команды engine-backup:

--mode ‒ указывает режим выполнения команды: операция создания резервной копии или операция восстановления из резервной копии. Доступные параметры: backup (по умолчанию), restore и verify. Для операций verify или restore необходимо также указать параметр mode;

--file ‒ указывает путь и имя файла (например, file_name.backup), в котором будет сохранена резервная копия в режиме создания резервных копий, и из которого будут читаться данные в режиме восстановления (по умолчанию ‒ /var/lib/ovirt-engine-backup/);

--log ‒ указывает путь и имя файла (например, log_file_name), в который будет записываться журнал операции создания или восстановления резервной копии (по умолчанию ‒ /var/log/ovirt-engine-backup/);

--scope ‒ указывает область данных, включаемых в создание или восстановление резервной копии. Возможны четыре параметра:

all (по умолчанию) — для создания резервной копии или восстановления всех баз данных и данных конфигураций;
files — для создания резервной копии или восстановления только файлов Системы;
db — для создания резервной копии или восстановления только БД СУСВ;
dwhdb — для создания резервной копии или восстановления только БД хранилища данных.

В одной и той же команде engine-backup параметр --scope можно указывать несколько раз.

Параметры БД СУСВ доступны только при использовании команды engine-backup в режиме restore. Синтаксис параметров, описанный ниже, применяется при восстановлении БД СУСВ. Те же параметры существуют для восстановления БД хранилища данных. Синтаксис параметров для хранилища данных см. в выводе команды:

engine-backup –help

--provision-db ‒ создает БД PostgreSQL, в которую будет восстанавливаться резервная копия БД СУСВ. Этот параметр является обязательным при восстановлении из резервной копии на удаленном хосте или в свежей установке, не имеющей уже настроенной БД PostgreSQL. При использовании в режиме восстановления к этому параметру по умолчанию добавляется параметр —restore-permissions;

--provision-all-databases ‒ создает БД для всех дампов памяти, включенных в архив. Если параметр включен, это является значением по умолчанию;

--change-db-credentials ‒ дает возможность указать другие учетные данные при восстановлении БД СУСВ с учетными данными, отличными от сохраненных непосредственно в архиве. Дополнительные параметры, необходимые данному параметру, см. в выводе команды backup –help;

--restore-permissions или --no-restore-permissions ‒ восстанавливает или не восстанавливает полномочия пользователей БД. Один из этих параметров является требуемым при восстановлении из резервной копии. При использовании параметра --provision-*** **в режиме восстановления --restore-permissions применяется по умолчанию.

Примечание — Если в резервной копии содержатся предоставления полномочий дополнительным пользователям БД, то при восстановлении с использованием параметров --restore-permissions и --provision-db (или --provision-dwh-db) создаются дополнительные пользователи со случайно созданными паролями. Если дополнительным пользователям требуется доступ к восстановленной Системе, то эти пароли необходимо сменить вручную. См. дополнительную информацию по ссылке.

Создание резервных копий с помощью команды engine-backup

Резервные копии СУСВ при активной СУСВ можно создавать с помощью команды engine-backup.

Для указания, что именно требуется поместить в архив, добавляют один из следующих аргументов к параметру --scope:

all ‒ полная резервная копия всех БД и файлов конфигурации СУСВ. Это является значением по умолчанию для параметра —scope;
files ‒ резервная копия только файлов в Системе;
db ‒ резервная копия только БД СУСВ;
dwhdb ‒ резервная копия только БД хранилища данных;
cinderlibdb ‒ резервная копия только БД Cinderlib;
grafanadb ‒ резервная копия только БД Grafana.

Параметр --scope можно указывать несколько раз.

Команду engine-backup можно настроить на создание резервной копии для дополнительных файлов. При восстановлении эта команда восстанавливает все файлы из архива.

Примечания:
Для восстановления из резервной копии в свежей установке СУСВ недостаточно только архива с БД СУСВ, также нужен доступ к файлам конфигурации. При указании области действия, отличной от all, необходимо также указать --scope=files, либо создать резервную копию файловой системы.
Полные сведения о команде engine-backup можно получить в выводе команды engine-backup —help на машине СУСВ.

Последовательность действий для создания резервных копий с помощью команды engine-backup:

войти в Систему на машине СУСВ;
создать резервную копию:

engine-backup

Следующие параметры применяются по умолчанию: --scope=all; --mode=backup.

Эта команда создает резервную копию в /var/lib/ovirt-engine-backup/file_name.backup и файл журнала /var/log/ovirt-engine-backup/log_file_name.

Для сохранения окружения используется файл архива file_name.tar.

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

Пример 1. Создание полной резервной копии:

engine-backup

Пример 2. Резервная копия БД СУСВ:

engine-backup --scope=files --scope=db

Пример 3. Резервная копия БД хранилища данных:

engine-backup --scope=files --scope=dwhdb

Пример 4. Добавление в архив конкретных файлов:

создать каталог для хранения специальных параметров конфигурации команды engine-backup:

mkdir -p /etc/ovirt-engine-backup/engine-backup-config.d

создать в новом каталоге текстовый файл с именем ntp-chrony.sh и следующим содержимым:

BACKUP_PATHS="${BACKUP_PATHS}
/etc/chrony.conf
/etc/ntp.conf
/etc/ovirt-engine-backup"

при запуске команды engine-backup использовать команды engine-backup использовать –scope=files..

В создание и восстановление из резервной копии входят /etc/chrony.conf, /etc/ntp.conf и /etc/ovirt-engine-backup.

Восстановление из резервной копии с помощью команды engine-backup

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

Восстановление из резервной копии в свежую установку

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

Последовательность действий для восстановления из резервной копии:

выполнить вход в Систему на машине диспетчера. Если восстанавливается БД СУСВ на удаленный хост, то необходимо также войти в Систему на этом хосте и выполнить там требуемые действия. Аналогичным образом при восстановлении БД хранилища данных на удаленный хост на этом хосте необходимо войти в Систему и выполнить требуемые действия;
выполнить полное восстановление либо только восстановление резервной копии БД:

Полное восстановление:

engine-backup --mode=restore --file=file_name \
--log=log_file_name --provision-db

При использовании параметра --provision-* в режиме восстановления параметр --restore-permissions применяется по умолчанию.

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

engine-backup --mode=restore --file=file_name \
--log=log_file_name --provision-db -- provision-dwh-db
```

При восстановлении резервной копии только БД восстановить файлы конфигурации и архив БД:
```
engine-backup --mode=restore --scope=files --scope=db \
--file=file_name -- log=log_file_name --provision-db
```

В примере ниже восстанавливается резервная копия БД диспетчера.

engine-backup --mode=restore --scope=files --scope=dwhdb \
--file=file_name -- log=log_file_name --provision-dwh-db
```

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

```bash Terminal
You should now run engine-setup. Done.
```
3. для создания конфигурации восстановленного диспетчера запустить команду и следовать подсказкам:
```bash Terminal
engine-setup

В результате СУСВ будет восстановлен в версии, сохраненной в резервной копии.

Восстановление из резервной копии с перезаписью существующей установки

Команда engine-backup может восстановить резервную копию на машину, где уже была установлена и настроена СУСВ. Это удобно в ситуациях, когда сначала была создана резервная копия окружения, затем в окружение были внесены изменения, а далее необходимо эти изменения отменить с восстановлением окружения.

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

Последовательность действий для выполнения восстановления из резервной копии с перезаписью существующей установки

войти в Систему на машине СУСВ;
удалить файлы конфигурации и очистить БД, связанную с диспетчером, выполнив команду:

engine-cleanup

Примечание — Команда engine-cleanup только очищает БД СУСВ; БД не будет удалена из Системы, а также не будут удалены пользователи, владеющие этой БД.

восстановление полной резервной копии или резервной копии только БД. Нет необходимости создавать новую БД или указывать учетные записи, т. к. пользователи и БД уже существуют.

Восстановление из полной резервной копии:

engine-backup --mode=restore --file=file_name \
--log=log_file_name --restore- permissions

Восстановление только БД с помощью восстановления файлов конфигурации и архива БД:
```
engine-backup --mode=restore --scope=files --scope=db \
--scope=dwhdb -- file=file_name --log=log_file_name --restore-permissions
```

Примечание — Чтобы восстановить только БД диспетчера (если, например, БД хранилища данных расположена на другой машине), можно опустить параметр --scope=dwhdb.

В случае успеха будет показано следующее сообщение:

You should now run engine-setup.
Done.

повторная настройка диспетчера:

engine-setup

Восстановление из резервной копии с использованием других учетных данных

Команда engine-backup может восстановить резервную копию на машину, где СУСВ уже ранее была установлена и настроена, в ситуации, когда данные учетных записей БД в резервной копии отличаются от данных, используемых на машине, где будет восстановлена эта резервная копия. Это удобно, если в одной Системе нужно развернуть из резервной копии установку, созданную и настроенную в другой Системе.

Примечание — При восстановлении из резервной копии с перезаписью существующей установки перед запуском команды engine-backup необходимо выполнить команду engine-cleanup для очистки существующей установки. Команда engine-cleanup только очищает БД СУСВ, но не удаляет ее из Системы и не удаляет пользователей-владельцев этой БД, поэтому нет необходимости создавать новую БД или указывать данные учетных записей. Тем не менее, если данные учетной записи владельца БД неизвестны, их нужно изменить до того, как выполнять восстановление из резервной копии.

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

выполнить вход в Систему на машине СУСВ;
для удаления файлов конфигурации диспетчера и очистки БД СУСВ запустить следующую команду и следовать подсказкам:

engine-cleanup

сменитm пароль владельца БД engine, если данные его учетной записи неизвестны:

войти в командную строку postgresql:
```
su ‒ postgres -c 'psql'
```
сменить пароль пользователя-владельца БД engine:
```
postgres=# alter role user_name encrypted password 'new_password';
```

В случае необходимости повторить эти действия для пользователя-владельца БД ovirt_engine_history.

восстановить полный архив или архив только с БД с параметром --change-db-credentials для передачи учетных данных новой БД. Значение параметра database_location для БД, локальной относительно диспетчера, равно "localhost".

Примечание — В следующем примере параметр --*password используется для каждой БД без указания пароля, в результате этого для каждого пароля БД выводится запрос командной строки.

Как вариант, для каждой БД можно использовать параметр --*passfile=password_file для защищенной передачи паролей утилите engine-backup без необходимости вводить пароли в интерактивном запросе командной строки.

Для восстановления полной резервной копии выполняют:

engine-backup --mode=restore --file=file_name --log=log_file_name \
--change-db- credentials --db-host=database_location –db \
name=database_name --db-user=engine --db-password --no-restore-permissions

Если в составе полного восстановления также восстанавливается БД хранилища данных, то необходимо включить данные учетных записей для дополнительной БД:

engine-backup --mode=restore --file=file_name --log=log_file_name \
--change-db-credentials --db-host=database_location \
--dbname=database_name --db-user=engine --db-password \
--change-dwh-db-credentials --dwh-db-host=database_location \
--dwh-db- name=database_name --dwh-db-user=ovirt_engine_history \
--dwh-db-password --no-restore-permissions

Восстановление только резервной копии БД с помощью восстановления файлов конфигурации и архива БД:

engine-backup --mode=restore --scope=files --scope=db \
--file=file_name --log=log_file_name --change-db-credentials \
--db-host=database_location --db- name=database_name \
--db-user=engine --db-password --no-restore-permissions

В примере ниже восстанавливается резервная копия БД диспетчера.

engine-backup --mode=restore --scope=files --scope=dwhdb \
--file=file_name --log=log_file_name --change-dwh-db-credentials \
--dwh-db-host=database_location --dwh-db-name=database_name  \
--dwh-db-user=ovirt_engine_history –dwh-db-password \
--no-restore-permissions

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

You should now run engine-setup.
Done.

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

engine-setup

Создание резервной копии и восстановление из резервной копии виртуализированного ЦУ

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

При указании файла резервной копии во время развертывания архив восстанавливается на новой СУСВ с новым доменом хранилища виртуализированного ЦУ. Старый диспетчер удаляется, а старый домен хранилища переименовывается и может быть удален вручную после проверки корректности работы нового окружения. Настоятельно рекомендуется выполнять развертывание на свежем хосте; если в архиве резервной копии окружения присутствовал хост, использованный для развертывания, он будет удален из восстановленной БД для избегания конфликтов в новом окружении. При развертывании на новом хосте новому хосту нужно присвоить новое имя. Повторное использование имени существующего хоста, включенного в резервную копию, может привести к конфликтам в новом окружении.

Создание резервной копии виртуализированного ЦУ

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

создать резервную копию исходной СУСВ с помощью утилиты engine-backup;
развернуть новый виртуализированный ЦУ и восстановить СУСВ из резервной копии;
подключить репозитории СУСВ на новой СУСВ;
переустановить узлы виртуализированного ЦУ для обновления их конфигурации;
удалить домен хранилищ старого виртуализированного ЦУ.

Данная процедура предполагает, что у администратора есть доступ к исходному диспетчеру и права на внесение изменений.

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

Предварительные требования для создания резервной копии виртуализированного ЦУ:

Полное доменное имя, подготовленное для СУСВ и хоста. В DNS должны быть настроены записи для прямого и обратного поиска. Полное доменное имя новой СУСВ должно совпадать с именем исходной СУСВ.
Уровень совместимости ЦОД должен быть настроен на последнюю версию для обеспечения совместимости с обновленной версией хранилища.
В окружении должен присутствовать минимум один обычный хост. Этот хост (а также любые другие обычные хосты) будет оставаться активным для выполнения роли диспетчера пула хранилища (SPM) и размещения любых выполняющихся ВМ. Если обычный хост еще не является диспетчером пула хранилища, следует передать эту роль до начала создания резервной копии, выбрав обычный хост и нажав нажав "Управление → Выбрать как диспетчер пула хранилища (SPM)".

В случае отсутствия доступных обычных хостов есть два способа их добавить:

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

Создание резервной копии исходной СУСВ

Резервная копия исходной СУСВ создается с помощью команды engine-backup и копирования файла архива резервной копии в отдельное местоположение, чтобы к нему сохранялся доступ в любой момент работы.

Дополнительные сведения о параметрах engine-backup --mode=backup см. в п. Создание резервных копий с помощью команды engine-backup.

Последовательность действий по созданию резервной копии исходной СУСВ

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

hosted-engine --set-maintenance --mode=global

выполнить вход в Систему на исходной СУСВ и остановить службу ovirt-engine:

systemctl stop ovirt-engine
systemctl disable ovirt-engine

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

выполнить команду engine-backup, указав имя создаваемого файла резервной копии и имя файла создаваемого журнала процесса создания резервной копии:

engine-backup --mode=backup --file=file_name --log=log_file_name

скопировать файлы на внешний сервер. В примере ниже storage.example.com является полным доменным именем сервера сетевого хранилища, на котором будет храниться резервная копия до того момента, когда она понадобится, а /backup/ — это любая предназначенная папка или путь:

scp -p file_name log_file_name storage.example.com:/backup/

выполнить вход в Систему на одном из узлов виртуализированного ЦУ и выключить исходную СУСВ:

hosted-engine --vm-shutdown

После создания резервной копии СУСВ требуется развернуть новый виртуализированный ЦУ и восстановить резервную копию на новой ВМ.

Восстановление резервной копии в новом виртуализированном ЦУ

Для восстановления резервной копии диспетчера во время развертывания нужно запустить сценарий hosted-engine на новом хосте и использовать параметр --restore-from-file=path/to/file_name.

Примечания:
Если используется хранилище iSCSI, и цель iSCSI фильтрует подключения согласно списку управления доступом (ACL) инициатора, то развертывание может закончиться неудачно с ошибкой STORAGE_DOMAIN_UNREACHABLE. Для предотвращения этой ошибки необходимо обновить конфигурацию iSCSI до начала развертывания виртуализированного ЦУ:
Если выполняется повторное развертывание на уже существующем хосте, то необходимо обновить параметры инициатора iSCSI хоста в файле /etc/iscsi/initiatorname.iscsi. Типизированное имя (IQN) инициатора должно совпадать с именем, ранее отображенным на цель iSCSI, либо необходимо его обновить до нового IQN, если это применимо.
При развертывании на свежем хосте необходимо обновить конфигурацию цели iSCSI для принятия подключений с этого хоста.

Следует обратить внимание, что IQN можно обновлять либо на стороне хоста (инициатор iSCSI), либо на стороне хранилища (цель iSCSI).

Последовательность действий по восстановлению резервной копии в новом виртуализированном ЦУ:

скопировать файл резервной копии на новый хост. В примере ниже host.example.com является полным доменным именем хоста, а /backup/ — это любая предназначенная папка или путь:

scp -p file_name host.example.com:/backup/

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

tmux

запустить сценарий hosted-engine, указав путь до файла с резервной копией:

hosted-engine --deploy –restore-from-file=/backup/file_name

Чтобы остановить работу сценария и прервать развертывание в любой момент, можно использовать клавиши CTRL+D.

чтобы начать развертывание, выбрать "Yes";
настроить сеть. Сценарий обнаружит сетевые контроллеры, пригодные для использования в качестве моста управления окружением;
при необходимости использования настраиваемого программно-аппаратного устройства для установки ВМ указать путь к архиву OVA, иначе оставить поле пустым;
ввести пароль root для СУСВ;
ввести открытый ключ SSH, с помощью которого можно будет выполнить вход в Систему диспетчера в качестве пользователя root, и указать, нужно ли разрешать доступ с использованием SSH для root;
ввести конфигурацию памяти и ЦП для ВМ;
указать MAC-адрес для ВМ диспетчера или принять случайно созданный адрес. Если ВМ должна получать адрес IP с помощью DHCP, убедиться в наличии действительного зарезервированного DHCP для этого MAC-адреса. Сценарий развертывания не настраивает сервер DHCP;
указать сетевые параметры ВМ. При указании статического IP указать IP диспетчера;

Примечание — Статический IP должен принадлежать к той же самой подсети, что и хост. Если, например, хост располагается в "10.1.1.0/24", то IP ВМ СУСВ должен располагаться в том же диапазоне подсети ("10.1.1.1-254/24").

указать, нужно ли добавлять запись ВМ диспетчера и запись базового хоста в файл /etc/hosts на ВМ, и убедиться в разрешаемости имен хостов;
указать имя и номер порта TCP сервера SMTP, почтовый адрес для отсылки уведомлений и список адресов-получателей этих сообщений через запятую;
указать пароль пользователя admin@internal для доступа к Порталу администрирования. Сценарий создаст ВМ.

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

[ INFO ] You can now connect to https://<host name>: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]
[ INFO ] TASK [ovirt.ovirt.hosted_engine_setup : Pause execution until
/tmp/ansible.<random>_he_setup_lock is removed, delete it once ready to proceed]

Приостановка процесса дает возможность администратору:

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

настроить тип используемого хранилища:

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

Примечание — Не следует использовать точку монтирования старого домена хранилища виртуализированного ЦУ для нового домена хранилища, т. к. присутствует риск потери данных.

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

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

для хранилища Gluster указать полный адрес и путь до хранилища вместе с любыми параметрами монтирования;

Примечания:
Не следует использовать точку монтирования строго домена хранилища виртуализированного ЦУ для нового домена хранилища, т. к. присутствует риск потери данных ВМ.
Поддерживаются только хранилища Gluster с типом replica 1 и replica 3. Необходимо убедиться, что том настроен следующим образом: bash Terminal gluster volume set VOLUME_NAME group virt gluster volume set VOLUME_NAME performance.strict-o-direct on gluster volume set VOLUME_NAME network.remote-dio off gluster volume set VOLUME_NAME storage.owner-uid 36 gluster volume set VOLUME_NAME storage.owner-gid 36 gluster volume set VOLUME_NAME network.ping-timeout 30

для Fibre Channel выбрать LUN из списка автоматически обнаруженных. Адаптеры шины хоста должны быть заранее настроены и подключены, а LUN не должен содержать никаких существующих данных. Сведения о том, как повторно использовать уже существующий LUN, см. в п. Повторное использование LUN;

указать размер диска диспетчера;
сценарий продолжит свое выполнение до завершения развертывания; в процессе развертывания будут изменены ключи SSH диспетчера;
чтобы разрешить клиентским машинам доступ к новому диспетчеру без ошибок, связанных с SSH, удалить запись исходного диспетчера из файла .ssh/known_hosts на любой из клиентских машин, ранее имевших доступ к исходному диспетчеру;
после завершения развертывания выполнить вход в Систему на ВМ новой СУСВ и подключить необходимые репозитории.

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

Действия по переустановке хостов РОСА Виртуализация на Портале администрирования включают в себя остановку и перезапуск работы хостов.

Примечание — Настоятельно рекомендуется перед началом установки или переустановки ОС хостов отсоединить любые существующие, не относящиеся к ОС хранилища, прикрепленные к хостам. Это позволит избежать случайной инициализации этих дисков и связанной с этим возможной потери данных.

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

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

Последовательность действий по повторной установка хостов:

нажать "Ресурсы → Хосты" и выбрать хосты;
выбрать "Управление → Обслуживание" и нажать кнопку OK;
выбрать "Установка → Переустановить";
в открывшемся окне "Установить хост" перейти на вкладку "Виртуализированный ЦУ" и в выпадающем списке выбрать "Развернуть";
для переустановки хоста нажать кнопку OK.

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

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

После переустановки узлов виртуализированного ЦУ статус нового окружения можно проверить, выполнив на одном из узлов следующую команду:

hosted-engine —vm-status

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

Восстановление виртуализированного ЦУ из существующей резервной копии

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

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

Настоятельно рекомендуется выполнять развертывание на свежем хосте; если хост, используемый для развертывания, существовал в окружении, для которого создавалась резервная копия, то он будет удален из восстановленной БД во избежание конфликтов в новом окружении. Если развертывание выполняется на новом хосте, этому хосту необходимо присвоить уникальное имя. Повторное использование имени хоста, включенного в резервную копию, может привести к конфликтам в новом окружении.

Последовательность восстановления виртуализированного ЦУ состоит из следующих ключевых действий:

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

Данная процедура подразумевает, что у администратора нет доступа к исходному диспетчеру и что у нового хоста есть доступ к файл резервной копии.

Предварительные требования для восстановления виртуализированного ЦУ:

Полное доменное имя, подготовленное для СУСВ и хоста. В DNS должны быть настроены записи для прямого и обратного поиска.
Полное доменное имя нового диспетчера должно совпадать с именем исходного диспетчера.

Восстановление из резервной копии на новом виртуализированном ЦУ

Для восстановления диспетчера из резервной копии во время развертывания нужно запустить на новом хосте сценарий hosted-engine с помощью параметра --restore-from-file=path/to/file_name.

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

Если выполняется повторное развертывание на уже существующем хосте, то необходимо обновить параметры инициатора iSCSI хоста в файле /etc/iscsi/initiatorname.iscsi. Типизированное имя (IQN) инициатора должно совпадать с именем, ранее отображенным на цель iSCSI, либо необходимо его обновить до нового IQN, если это применимо.
При развертывании на свежем хосте необходимо обновить конфигурацию цели iSCSI для принятия подключений с этого хоста.

Последовательность действий по восстановлению из резервной копии на новом виртуализированном ЦУ:

скопировать файл резервной копии на новый хост. В примере ниже host.example.com — это полное доменное имя хоста, а /backup/ — любая назначенная папка или путь:

scp -p file_name host.example.com:/backup/

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

tmux

запустить сценарий hosted-engine, указав путь до файла с резервной копии:

hosted-engine --deploy --restore-from-file=backup/file_name

Чтобы остановить работу сценария и прервать развертывание в любой момент, можно использовать клавиши CTRL+D.

чтобы начать развертывание, выбрать "Yes";
настроить сеть. Сценарий обнаруживает сетевые контроллеры, пригодные к использованию в качестве моста для управления окружением;
при необходимости использования настраиваемого программно-аппаратного устройств для установки ВМ, указать путь к архиву OVA. В противном случае оставить поле пустым;
ввести пароль root для диспетчера;
ввести открытый ключ SSH, с помощью которого можно будет выполнить вход в Систему диспетчера в качестве пользователя root, и указать, нужно ли разрешать доступ с использованием SSH для root;
ввести конфигурацию памяти и ЦП для ВМ;
указать MAC-адрес для ВМ диспетчера или принять случайно созданный адрес. Если ВМ должна получать IP-адрес с помощью DHCP, убедиться в наличии действительного зарезервированного DHCP для этого MAC-адреса. Сценарий развертывания не настраивает сервер DHCP;
указать сетевые параметры ВМ. При указании статического IP указать IP СУСВ;

Примечание — Статический IP должен принадлежать к той же самой подсети, что и хост. Если, например, хост располагается в "10.1.1.0/24", то IP ВМ СУСВ должен располагаться в том же диапазоне подсети ("10.1.1.1-254/24").

указать, нужно ли добавлять запись ВМ диспетчера и запись базового хоста в файл /etc/hosts на ВМ; убедиться в разрешаемости имен хостов;
указать имя и номер порта TCP сервера SMTP, почтовый адрес для отсылки уведомлений и список адресов-получателей этих сообщений через запятую;
указать пароль пользователя admin@internal для доступа к Порталу администрирования. Сценарий создаст ВМ.

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

[ INFO ] You can now connect to https://<host name>: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]
[ INFO ] TASK [ovirt.ovirt.hosted_engine_setup : Pause execution until
/tmp/ansible.<random>_he_setup_lock is removed, delete it once ready to proceed]

Приостановка процесса дает возможность администратору:

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

выбрать тип используемого хранилища:

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

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

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

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

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

Примечания:
Не следует использовать точку монтирования старого домена хранилища виртуализированного ЦУ для нового домена, т. к. существует риск потери данных ВМ
Поддерживаются только хранилища Gluster с типом replica 1 и replica 3. Убедитесь, что том настроен следующим образом:

gluster volume set VOLUME_NAME group virt
gluster volume set VOLUME_NAME performance.strict-o-direct on gluster volume set VOLUME_NAME network.remote-dio off gluster volume set VOLUME_NAME storage.owner-uid 36
gluster volume set VOLUME_NAME storage.owner-gid 36 gluster volume set VOLUME_NAME network.ping-timeout 30

Для Fibre Channel выбрать LUN из списка автоматически обнаруженных. Адаптеры шины хоста должны быть заранее настроены и подключены, а LUN не должен содержать никаких существующих данных.

указать размер диска диспетчера. Сценарий продолжит свое выполнение до завершения развертывания.
В процессе развертывания будут изменены ключи SSH диспетчера. Чтобы разрешить клиентским машинам доступ к новому диспетчеру без ошибок, связанных с SSH, удалить запись исходного диспетчера из файла .ssh/known_hosts на любой из клиентских машин, ранее имевших доступ к исходному диспетчеру.
После завершения развертывания выполнить вход в Систему на ВМ новой СУСВ и подключить необходимые репозитории.

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

Переустановка хостов РОСА Виртуализация на Портале администрирования включает в себя остановку и перезапуск работы хостов.

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

Предварительные требования для переустановки хостов:

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

Последовательность действий по переустановке хостов:

нажать "Ресурсы → Хосты" и выбрать хосты;
выбрать "Управление → Обслуживание" и нажать кнопку OK;
выбрать "Установка → Переустановить". Будет открыто окно "Установить хост";
перейти на вкладку "Виртуализированный ЦУ" и в выпадающем списке выбрать "Развернуть";
для переустановки хоста нажать кнопку OK.

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

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

hosted-engine --vm-status

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

Удаление домена хранилища

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

нажать "Хранилище → Домены";
перевести домен хранилища в режим обслуживания и отсоединить его:

нажать на имя домена хранилища для подробного просмотра;
перейти на вкладку "Дата-центр";
нажать кнопку Обслуживание, затем нажать кнопку OK;
нажать кнопку Отсоединить, затем нажать кнопку OK;

нажать кнопку Удалить;
опционально выбрать "Форматировать домен", т. е. содержимое хранилища будет потеряно, и поставить флажок для удаления содержимого домена;
нажать кнопку OK.

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

Перезапись виртуализированного ЦУ существующей резервной копией

В ситуации, когда виртуализированный ЦУ доступен, но испытывает проблемы, такие как повреждение БД или ошибки конфигурации, которые трудно откатить, то окружение можно восстановить до предыдущего состояния с помощью резервной копии, созданной до того, как появились проблемы (если она была сделана).

Процесс восстановления виртуализированного ЦУ до предыдущего состояния

Процесс восстановления виртуализированного ЦУ до предыдущего состояния состоит из следующих шагов:

перевести окружение в глобальный режим обслуживания;
восстановить резервную копию на ВМ СУСВ;
отключить режим обслуживания.

Дополнительные сведения о параметрах engine-backup --mode=restore см. в п. Создание резервных копий с помощью команды engine-backup.

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

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

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

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

hosted-engine --set-maintenance --mode=global

перед тем как продолжить, убедиться, что окружение находится в глобальном режиме обслуживания:

hosted-engine --vm-status

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

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

С помощью команды engine-backup можно восстановить резервную копию на машине, где виртуализированный ЦУ уже ранее был установлен и настроен. Это удобно в тех ситуациях, когда сначала была сделана резервная копия окружения, затем в это окружение были внесены изменения, которые затем необходимо отменить с помощью восстановления окружения из резервной копии.

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

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

выполнить вход в Систему на ВМ СУСВ;
удалить файлы конфигурации и очистить БД, связанную с диспетчером.

engine-cleanup

Примечание — Команда engine-cleanup только очищает БД диспетчера; БД не будет удалена из Системы, а также не будут удалены пользователи, владеющие этой БД .

восстановить полную резервную копию или резервную копию только БД, в которой нет необходимости создавать новую БД или указывать учетные записи, т. к. пользователи и БД уже существуют:

восстановление из полной резервной копии:

engine-backup --mode=restore --file=file_name --log=log_file_name \
--restore- permissions

восстановление только БД с помощью восстановления файлов конфигурации и архива БД:
```
engine-backup --mode=restore --scope=files --scope=db --scope=dwhdb \
-- file=file_name --log=log_file_name --restore-permissions
```

Примечание — Чтобы восстановить только БД СУСВ (если, например, БД хранилища данных расположена на другой машине), можно опустить параметр --scope=dwhdb.

В случае успеха будет показано следующее сообщение:

You should now run engine-setup.
Done.

повторно настроить диспетчер:

engine-setup

Отключение глобального режима обслуживания

Последовательность действий по отключению глобального режима обслуживания:

войти в Систему ВМ СУСВ и выключить ее;
войти в Систему на одном из узлов виртуализированного ЦУ и отключить глобальный режим обслуживания:

hosted-engine --set-maintenance --mode=none

После выхода из глобального режима обслуживания ovirt-ha-agent запускает ВМ СУСВ, а затем автоматически запускается СУСВ.

убедиться в том, что окружение работает:

hosted-engine --vm-status

В выводимых сведениях присутствует статус виртуализированного ЦУ. Значение статуса должно быть одним из следующих: {"health": "good", "vm": "up", "detail": "Up"}.

Пока ВМ не начала работу и только загружается, ЦУ еще не запущен и может иметь один из следующих статусов: {"reason": "bad vm status", "health": "bad", "vm": "up", "detail": "Powering up"}. В этом случае следует подождать несколько минут и повторить попытку.

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

Резервное копирование конфигурационных файлов и баз данных

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

Раздел "Бэкап"

В разделе "Бэкап" можно вручную запустить процесс создания резервной копии. Здесь также доступны различные опции для настройки резервного копирования, такие как выбор типов данных (конфигурационные файлы, базы данных), указание путей и выбор хранилища (рисунок 237).

Рисунок 237 ‒ Вкладка "Бэкап"

Резервное копирование будет запущено по нажатию кнопки Создать бэкап. Если резервное копирование завершится успешно, то появится сообщение об успешном завершении. Если возникнет ошибка, будет представлен подробный лог по этапам выполнения резервного копирования.

Раздел "Расписание"

На вкладке "Расписание" можно настроить автоматическое выполнение резервного копирования в заданное время. Возможно указать периодичность запуска, время и другие параметры, чтобы резервное копирование происходило без участия администратора (рисунок 238).

Рисунок 238 ‒ Вкладка "Расписание"

В этой форме (рисунок 239) нужно заполнить те же параметры что и при ручном запуске, а также настроить cron-выражение для запуска по расписанию. Для этого нужно выбрать часы (1 или несколько), дни недели (можно не заполнять, тогда считается, что выбраны все дни недели), дни месяца (1 или несколько). Также нужно выбрать дату "Начать с". С этой даты и времени будет рассчитан первый запуск. В форме есть подсказка "Будет запущено". Меняя дату можно подстроить дату и время первого запуска. Последующие запуски будут рассчитаны автоматически.

Рисунок 239 ‒ Форма добавления расписания

После запуска задачи у нее будет обновляться параметр "Последний успешный запуск" в таблице.

Раздел "Хранилища"

В разделе "Хранилища" можно создавать и настраивать удаленные хранилища, куда будут копироваться резервные копии (рисунок 240). Хранилище представляет собой удаленную машину, к которой осуществляется доступ по SSH. Здесь также можно редактировать существующие хранилища, изменяя их параметры (рисунок 241).

Рисунок 240 ‒ Вкладка "Хранилища"

Рисунок 241 ‒ Форма редактирования "Хранилища"

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

Миграция хранилища данных на отдельную машину

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

Примечание — На одной и той же машине поддерживается только совместная установка БД хранилища данных, службы Data Warehouse и Grafana, хотя каждый из этих компонентов можно установить отдельно от других на отдельной машине.

Существуют следующие возможности миграции:

Можно выполнить миграцию службы Data Warehouse с машины СУСВ и подключить ее к существующей БД хранилища данных (ovirt_engine_history).
Можно выполнить миграцию БД хранилища данных с машины СУСВ, а затем перенести службу Data Warehouse.

Миграция БД хранилища данных на отдельную машину

До начала миграции службы Data Warehouse нужно перенести БД хранилища данных (ovirt_engine_history). Для создания резервной копии БД и восстановления ее на машине новой БД необходимо использовать команду engine-backup. Дополнительные сведения об engine-backup см. в выводе команды:

engine-backup --help

Примечание — На одной и той же машине поддерживается только совместная установка БД хранилища данных, службы Data Warehouse и Grafana, хотя каждый из этих компонентов можно установить отдельно от других на отдельной машине.

На новом сервере БД должна быть установлена минимальная конфигурация.

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

создать резервную копию БД и файлов конфигурации хранилища данных на диспетчере:

engine-backup --mode=backup --scope=grafanadb --scope=dwhdb \
--scope=files -- file=file_name --log=log_file_name

скопировать файл резервной копии с диспетчера на новую машину:

scp /tmp/file_name root@new.dwh.server.com:/tmp

установить engine-backup на новой машине:

dnf install ovirt-engine-tools-backup

установить пакет сервера PostgreSQL:

dnf install postgresql-server postgresql-contrib

инициализировать БД PostgreSQL, запустить службу postgresql и настроить запуск этой службы при загрузке:

su ‒ postgres -c 'initdb'
systemctl enable postgresql
systemctl start postgresql

восстановить БД хранилища данных на новой машине из файла file_name — это файл резервной копии, скопированный с диспетчера.

engine-backup --mode=restore --scope=files --scope=grafanadb \
--scope=dwhdb -- file=file_name --log=log_file_name --provision-dwh-db

При использовании параметра --provision-* в режиме восстановления параметр --restore-permissions применяется по умолчанию.

БД хранилища данных теперь располагается на машине, отдельной от машины, на которой располагается диспетчер. После успешного восстановления БД хранилища данных подсказка командной строки указывает выполнить команду engine-setup. До запуска этой команды нужно выполнить миграцию службы Data Warehouse.

Миграция службы Data Warehouse на отдельную машину

Служба Data Warehouse, установленная и настроенная на СУСВ, может мигрировать на отдельную машину. Размещение службы Data Warehouse на отдельной машине помогает снизить нагрузку на машину СУСВ.

Следует обратить внимание, что в процессе данной процедуры выполняется миграция только службы Data Warehouse.

Сведения о том, как выполнить миграцию БД хранилища данных (ovirt_engine_history) до миграции службы Data Warehouse, приведены в п. Миграция БД хранилища данных на отдельную машину.

Примечание — На одной и той же машине поддерживается только совместная установка БД хранилища данных, службы Data Warehouse и Grafana, хотя каждый из этих компонентов можно установить отдельно от других на отдельной машине.

Предварительные требования для миграции службы Data Warehouse на отдельную машину:

СУСВ и хранилище данных должны быть ранее установлены на одну и ту же машину.
Для настройки новой машины хранилища данных необходимы следующие сведения:
- пароль из файла /etc/ovirt-engine/engine.conf.d/10-setup- database.conf на диспетчере;
- возможность доступа с машины хранилища данных на машину диспетчера на порте TCP 5432;
- имя пользователя и пароль для БД хранилища данных из файла /etc/ovirt-engine-dwh/ovirt-engine-dwhd.conf.d/10-setup-database.conf на диспетчере. Если миграция БД ovirt_engine_history проводилась по инструкции, описанной в п. Миграция БД хранилища данных на отдельную машину, то файл резервной копии содержит эти данные, т. к. они были созданы во время настройки БД на этой машине.

Инструкция состоит из нескольких шагов, описанных в пп. Остановка службы Data Warehouse на машине диспетчера‒Отключение службы Data Warehouse на диспетчере:

остановка службы Data Warehouse на машине диспетчера;
настройка новой машины хранилища данных;
создание конфигурации на новой машине хранилища данных;
отключение пакета Data Warehouse на машине диспетчера.

Остановка службы Data Warehouse на машине диспетчера

Последовательность действий по остановке службы Data Warehouse на машине диспетчера:

остановка службы Data Warehouse:

systemctl stop ovirt-engine-dwhd.service

если БД размещается на удаленной машине, то необходимо предоставить доступ, вручную отредактировав файл postgres.conf, изменив строку "listen_addresses" в файле /var/lib/pgsql/data/postgresql.conf следующим образом:

listen_addresses = '*'

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

Если БД размещается на машине диспетчера и была настроена во время чистой установки СУСВ, то доступ предоставляется по умолчанию.

перезапустить службу postgresql:

systemctl restart postgresql

Настройка новой машины хранилища данных

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

если на одну и ту же машину переносится и БД 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

удалить файлы PKI apache/grafana, чтобы они могли быть созданы заново командой engine-setup с корректными значениями:

rm -f \
/etc/pki/ovirt-engine/certs/apache.cer \
/etc/pki/ovirt-engine/certs/apache-grafana.cer \
/etc/pki/ovirt-engine/keys/apache.key.nopass \
/etc/pki/ovirt-engine/keys/apache-grafana.key.nopass  \
/etc/pki/ovirt-engine/apache-ca.pem \
/etc/pki/ovirt-engine/apache-grafana-ca.pem

для начала создания конфигурации хранилища данных на машине запустить команду:

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, что применимо и в тех случаях, когда доступен только один диспетчер межсетевых экранов;
ввести полное доменное имя и пароль диспетчера; для принятия значений по умолчанию в каждом из других полей нажать клавишу 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:
- Access remote engine server using ssh as root
- 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

указать полное доменное имя и пароль машины БД диспетчера; для принятия значений по умолчанию в каждом из других полей, нажать 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 на машине диспетчера.

Отключение службы Data Warehouse на диспетчере

Предварительные требования к машине:

служба Grafana на машине должна быть отключена:
```
systemctl disable --now grafana-server.service
```
Последовательность действий по отключению службы 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/*

Служба Data Warehouse теперь размещается на машине, отдельной от машины диспетчера.

Создание и восстановление ВМ из резервных копий с использованием домена хранения резервных копий

Что такое домены хранения резервных копий

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

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

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

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

Некоторые причины для использования доменов хранения резервных копий вместо доменов экспорта:

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

Ограничения использования:

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

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

Предварительные требования для настройки домена хранения данных:

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

на Портале администрирования выбрать "Хранилище → Домены";
создать новый домен хранения или выбрать уже существующий и нажать "Управление доменом";
в открывшемся окне "Управление доменами" в "Дополнительных параметрах" отметить флажком пункт "Хранение резервных копий".

В результате домен станет доменом хранения резервных копий.

Создание и восстановление резервной копии ВМ или снимка с помощью домена хранения резервных копий

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

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

создать домен хранения резервных копий (см. п. Настройка домена хранения данных в качестве домена хранения резервных копий);
создать новую ВМ на основе ВМ, для которой нужно создать резервную копию:

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

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

Управление резервным копированием ВМ подробно описано в документе .