Резервное копирование и восстановление Менеджера управления

Версия zVirt: 4.2

1. Резервное копирование Менеджера управления

В версии zVirt 4.1 и новее при создании полной резервной копии также создаётся файл резервной копии базы данных OVN с именем xxxxx.ovnnb_db.db (вместо xxxxx в имени файла указывается дата и время создания резервной копии), позволяющий восстановить сущности SDN. Файл сохраняется по тому же пути, что и основная резервная копия.

1.1. Резервное копирование Менеджера управления через портал администрирования

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

1.1.1. Управление хранилищами резервных копий

На Портале администрирования есть возможность указания удаленного хранилища для сохранения файла резервной копии как в ручном режиме, так и при настройке заданий резервного копирования. Это позволяет сохранить файл резервной копии на хосте/ВМ, отличном от того, на котором расположен менеджер управления и даёт возможность воспользоваться файлом резервной копии, если хост/ВМ с менеджером управления вышли из строя.

Просмотр списка хранилищ резервных копий

Для просмотра и проверки конфигурации хранилищ резервных копий на Портале администрирования нажмите Управление (Administration)  Резервное копирование конфигурации (Configuration backup), а затем перейдите на на вкладку Хранилища резервных копий (Backup storages).

bck store list

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

  • Хост (Host) - FQDN/IP-адрес хоста, на который отправляются файлы резервных копий

  • Порт (Port) - порт, используемый для передачи файлов резервных копий

  • Путь к резервной копии (Backup path) - абсолютный путь к каталогу на удалённой машине, в котором сохраняются файлы резервных копий

  • Пользователь (User) - имя учетной записи пользователя, от имени которого выполняется подключение к удалённой машине для передачи файлов резервных копий

  • Описание (Description) - описание хранилища

Для быстрого поиска нужного хранилища можно воспользоваться строкой поиска.

bck store search

Поиск осуществляется по значениям во всех столбцах таблицы независимо от видимости столбцов.

При необходимости, видимость столбцов можно изменить в меню настройки settIcon.

Добавление хранилища резервных копий

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

Порядок действий:
  1. Нажмите Управление (Administration)  Резервное копирование конфигурации (Configuration backup)

  2. Перейдите на вкладку Хранилища резервных копий (Backup storages)

    bck store list
  3. Нажмите Добавить хранилище (Add Storage)

  4. В появившемся окне "Добавление хранилища" ("Adding Storage") настройте следующие параметры:

    • В поле Хост (Host) введите FQDN или IP-адрес хоста, на который будут отправляться файлы резервных копий

    • В поле Порт (Port) укажите порт, который будет использоваться для передачи файлов резервных копий (по умолчанию - 22)

      Передача файлов резервных копий осуществляется утилитой scp, поэтому используемый по умолчанию порт имеет значение 22. Если на удалённой машине изменён стандартный порт для доступа по SSH, в этом поле также необходимо установить соответствующее значение
    • В поле Путь к резервной копии (Backup path) укажите абсолютный путь к каталогу на удалённой машине, в котором необходимо сохранять файлы резервных копий

    • В поле Пользователь (User) введите имя учетной записи пользователя, от имени которого необходимо подключаться к удалённой машине для передачи файлов резервных копий (по умолчанию root)

    • В поле Пароль (Password) введите пароль учётной записи, указанной в поле Пользователь (User)

    • Дополнительно: в поле Описание (Description) введите описание хранилища

  5. Нажмите Проверить соединение (Check the connection).

    Если параметры подключения введены корректно, появится уведомление об успешной проверке соединения

    conn verif succ

    В случае появления уведомления об ошибке установки соединения, проверьте корректность настроек и повторите проверку соединения.

  6. Нажмите Добавить хранилище (Add Storage)

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

Изменение хранилища резервных копий

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

Порядок действий:
  1. Нажмите Управление (Administration)  Резервное копирование конфигурации (Configuration backup)

  2. Перейдите на вкладку Хранилища резервных копий (Backup storages)

    bck store list
  3. Выделите нужное хранилище и нажмите Редактировать (Edit)

  4. Измените нужные настройки

  5. Нажмите Проверить соединение (Check the connection).

    Если параметры подключения введены корректно, появится уведомление об успешной проверке соединения

    conn verif succ

    В случае появления уведомления об ошибке установки соединения, проверьте корректность настроек и повторите проверку соединения.

  6. Нажмите Редактировать хранилище (Edit Storage)

    Если операция обновления прошла успешно, появится следующее уведомление:

    stor edited
Удаление хранилища резервных копий

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

Порядок действий:
  1. Нажмите Управление (Administration)  Резервное копирование конфигурации (Configuration backup)

  2. Перейдите на вкладку Хранилища резервных копий (Backup storages)

    bck store list
  3. Отметьте нужные хранилища галочками и нажмите Удалить (Delete)

  4. Подтвердите операцию удаления в появившемся окне

    stor remove

1.1.2. Ручное резервное копирование менеджера управления

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

Ручное создание резервной копии менеджера управления

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

Если требуется хранение резервной копии на удалённом хранилище, перед выполнением процедуры убедитесь, что подключено хранилище резервных копий (См. раздел Управление хранилищами резервных копий)
Порядок действий:
  1. Нажмите Управление (Administration)  Резервное копирование конфигурации (Configuration backup)

  2. Убедитесь, что активна вкладка Ручное резервное копирование (Manual backup)

    bck eng manual

    Опция База данных Keycloak отображается, если подключен Keycloak.

  3. Настройте параметры резервного копирования (полное описание параметров см. в таблице Настройки на вкладке "Ручное резервное копирование" ("Manual backup")):

    • В поле Расположение файла резервной копии (Backup file location) введите абсолютный путь к локальному каталогу, в котором будет храниться резервная копия

    • В группе Состав компонентов (Composition of components) выберите компоненты менеджера управления, резервную копию которых необходимо сделать

    • Дополнительно: В меню Хранилище (Storage) выберите добавленное ранее хранилище резервных копий.

  4. Нажмите Создать резервную копию (Create a backup)

После нажатия на Создать резервную копию (Create a backup) будет отображено уведомление о создании задачи резервного копирования.

manual back info

Проконтролировать процесс создания резервной копии можно через раздел Задачи tasksIcon, а также в блоке уведомлений EventsIcon в подразделе События.

Пример 1. Отображение выполненной задачи резервного копирования в разделе "Задачи"
manual back task
Пример 2. Отображение события в блоке уведомлений
manual back event
Описание настроек ручного резервного копирования

В таблице ниже представлено общее описание параметров, доступных для настройки на вкладке Ручное резервное копирование (Manual backup)

Таблица 1. Настройки на вкладке "Ручное резервное копирование" ("Manual backup")
Параметр Описание

Расположение файла резервной копии (Backup file location)

Локальное расположение файла резервной копии. По умолчанию /var/lib/ovirt-engine-backup

Состав компонентов (Composition of components)

Соответствует параметру --scope в утилите engine-backup.

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

  • Все компоненты (All components) - при выборе данного пункта должны отмечаться все указанные ниже компоненты. В утилите engine-backup соответствует значению параметра --scope=all

  • Файлы конфигурации (Configuration files) - в утилите engine-backup соответствует значению параметра --scope=files

  • База данных менеджера управления (Manager’s database) в утилите engine-backup соответствует значению параметра --scope=db

  • База данных DWH (DWH database) - в утилите engine-backup соответствует значению параметра --scope=dwhdb

  • База данных Cinderlib (Cinderlib database) - в утилите engine-backup соответствует значению параметра --scope=cinderlibdb

  • База данных Grafana (Grafana database) - в утилите engine-backup соответствует значению параметра --scope=grafanadb

  • База данных Keycloak (Keycloak database) - в утилите engine-backup соответствует значению параметра --scope=keycloakdb (Компонент отображается, если подключен Keycloak)

Дополнительную информацию об утилите engine-backup и её параметрах см. в разделе Синтаксис команды резервного копирования engine-backup

Хранилище (Storage)

Выбор из настроенных хранилищ резервных копий. Если не выбрано, резервная копия сохраняется локально

1.1.3. Управление задачами резервного копирования менеджера управления по расписанию

Просмотр задач резервного копирования

На Портале администрирования есть возможность просмотра созданных задач резервного копирования по расписанию.

Для этого нажмите Управление (Administration)  Резервное копирование конфигурации (Configuration backup) и перейдите на вкладку Расписание резервного копирования (Backup schedule).

bck eng sched list

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

  • Расписание (Schedule) - выражение в формате quartz cron, определяющее расписание запуска задачи

  • Последний удачный запуск (Last successful Launch) - дата и время последней успешной попытки запуска задачи. Если в поле стоит -, значит удачной попытки запуска ещё не было.

  • Следующий запуск (Next launch) - дата и время следующего запуска задачи. Если в поле стоит -, запуск не запланирован

  • Расположение файла (File location) - абсолютный путь к локальному каталогу, в котором сохраняются файлы резервных копий

  • Хранилище (Storage) - используемое для задачи хранилище резервных копий

  • Описание (Description)

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

Каждая запись в таблице имеет переключатель switch, позволяющий активировать/деактивировать соответствующую задачу.

Добавление задачи резервного копирования по расписанию

Для создания новой задачи выполните следующие действия.

Если требуется хранение резервной копии на удалённом хранилище, перед выполнением процедуры убедитесь, что подключено хранилище резервных копий (См. раздел Управление хранилищами резервных копий)
Порядок действий:
  1. Нажмите Управление (Administration)  Резервное копирование конфигурации (Configuration backup).

  2. Перейдите на вкладку Расписание резервного копирования (Backup schedule).

    bck eng sched list
  3. Нажмите Добавить задачу (Add a task).

  4. В появившемся окне "Добавление задачи" ("Adding a task") настройте параметры задания резервного копирования (полное описание параметров см. в Таблице Настройки задания резервного копирования).

    • Убедитесь в том, что переключатель выполнения задачи по расписанию находится в состоянии Задача включена (The task includes)

    • В поле Расположение файла резервной копии (Backup file location) укажите абсолютный путь к локальному расположению файла резервной копии

    • В поле Расписание (Schedule) укажите расписание. Это можно сделать двумя способами:

    • Дополнительно: в поле Описание (Description) введите описание задачи

    • В группе Состав компонентов (Composition of components) отметьте компоненты, резервное копирование которых должна выполнять задача

    • Дополнительно: В меню Хранилище (Storage) выберите добавленное ранее хранилище резервных копий.

  5. Нажмите Добавить задачу (Add a task)

При успешном добавлении задачи отобразится уведомление.

task add

Также в списке задач появится новая запись.

Проконтролировать процесс создания резервной копии можно через раздел Задачи tasksIcon, а также в блоке уведомлений EventsIcon в подразделе События.

Пример 3. Отображение выполненной задачи резервного копирования в разделе "Задачи"
task back task
Пример 4. Отображение события в блоке уведомлений
task back event
В случае каких-либо проблем с выполнением задачи резервного копирования, сервисом совершается до двух дополнительных (через 30 минут после очередного неуспешного запуска) попыток выполнения задачи резервного копирования. Если следующий момент (по расписанию) наступает раньше запланированного времени повторной попытки, то повторные попытки прекращаются.
Изменение задачи резервного копирования по расписанию

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

Порядок действий:
  1. Нажмите Управление (Administration)  Резервное копирование конфигурации (Configuration backup)

  2. Перейдите на вкладку Расписание резервного копирования (Backup schedule)

    bck eng sched list
  3. Выделите нужную задачу и нажмите Редактировать (Edit).

  4. Измените нужные настройки.

  5. Нажмите Сохранить задачу (Save the task).

Если операция обновления прошла успешно, появится следующее уведомление:

task updated

В списке задач также отобразятся обновлённые сведения о задаче.

Удаление задач резервного копирования по расписанию

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

Порядок действий:
  1. Нажмите Управление (Administration)  Резервное копирование конфигурации (Configuration backup).

  2. Перейдите на вкладку Расписание резервного копирования (Backup schedule).

    bck eng sched list
  3. Отметьте нужные задачи галочками и нажмите Удалить (Delete).

  4. Подтвердите операцию удаления в появившемся окне

    task remove

После подтверждения операции удаления отобразится уведомление.

task removed
Отправка результатов операции резервного копирования менеджера управления по расписанию на email

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

Операция резервного копирования в общем случае имеет четыре этапа:

  • Начало операции резервного копирования

  • Завершение (успешное или неуспешное) операции резервного копирования

  • Начало переноса файла резервной копии на целевое хранилище

  • Завершение (успешное или неуспешное) переноса файла резервной копии на целевое хранилище

Для активации отправки оповещений о резервном копировании и переносе файла копии на email-адрес соответствующего пользователя выполните следующие действия.

Для получения уведомлений по электронной почте, убедитесь что почтовый сервер настроен и запущена служба ovirt-engine-notifier (подробнее о настройке уведомлений см. в разделе Уведомления о событиях руководства администратора)
Порядок действий:
  1. Нажмите Управление (Administration)  Пользователи (Users)

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

  3. Перейдите на вкладку Уведомления о событиях (Event Notifier)

  4. Нажмите Управлять событиями (Manage Events)

  5. Разверните (cont arrow) раздел Общие события управления (General Management Events) и отметьте галочками нужные события, относящиеся к резервному копированию менеджера управления:

    back notifier
  6. Проверьте корректность почтового адреса получателя в поле Получатель почты (Mail Recipient)

  7. Нажмите OK

Так же в конфигурационном файле сервиса ovirt-engine-notifier (/usr/share/ovirt-engine/services/ovirt-engine-notifier/ovirt-engine-notifier.conf) есть три параметра, управляющих локализацией и объединением нотификационных email (см. таблицу ниже).

Таблица 2. Параметры локализации и объединения нотификационных email
Параметр Значение по умолчанию Описание

MAIL_MERGE_LOG_TYPES

-

Содержит в себе список типов уведомлений, для которых нужно объединять email, например:

MAIL_MERGE_LOG_TYPES=ENGINE_BACKUP_STARTED,ENGINE_BACKUP_COMPLETED,ENGINE_BACKUP_FAILED

Если данный параметр не задан - объединения email происходить не будет. В этом случае, если, например, запустить операцию резервного копирования с указанием scope=all, система сгенерирует 5 email оповещений (на каждый элемент из scope в отдельности) о начале резервного копирования, а потом еще 5 email о завершении (успешном или неуспешном) резервного копирования. Если в данном параметре указать типы уведомлений, как в примере выше, то каждая пятерка таких email будет объединена в один. Таким образом, получатели оповещений получат не 10 писем, а всего 2 (одно о начале, и одно об окончании).

MAIL_MERGE_MAX_TIME_DIFFERENCE

5000

Содержит в себе предел по разнице времени (в миллисекундах) между сообщениями для объединения в один email. Система отправки оповещений устроена так, что отправляет email уведомления не мгновенно, а с некоторыми интервалами. Соответственно, если перед отправкой имеется несколько уведомлений, которые необходимо объединить в один email (их типы прописаны MAIL_MERGE_LOG_TYPES), то будут объеденины только те уведомления, разница во времени появления которых не превышает значение данного параметра. Это полезно для случая, когда в достаточно короткий срок было запущено две операции резервного копирования, чтобы email уведомления разных операций не объединялись между собой.

MAIL_LOCALE

-

Содержит код языка, на который нужно переводить email уведомления. На данный момент поддерживается только два значения en (английский) и ru (русский). Если код языка не указан (или указан en), то содержимое email уведомлений будет на английском языке. Если указать значение ru, то на русском: MAIL_LOCALE=ru

Подробнее о настройке параметров уведомлений о событиях в ovirt-engine-notifier.conf см. в разделе Уведомления о событиях руководства администратора.

Описание настроек планировщика резервного копирования менеджера управления

В таблице ниже представлено общее описание параметров, доступных для настройки в окнах Добавление задачи (Adding a task) и Редактирование задачи (Editing a task)

Таблица 3. Настройки задания резервного копирования
Параметр Описание

Расположение файла резервной копии (Backup file location)

Локальное расположение файла резервной копии. По умолчанию /var/lib/ovirt-engine-backup

Расписание (Schedule)

Выражение в формате quartz cron, определяющее расписание запуска задачи

Описание (Description)

Описание добавляемого задания

Состав компонентов (Composition of components)

Соответствует параметру --scope в утилите engine-backup.

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

  • Все компоненты (All components) - при выборе данного пункта должны отмечаться все указанные ниже компоненты. В утилите engine-backup соответствует значению параметра --scope=all

  • Файлы конфигурации (Configuration files) - в утилите engine-backup соответствует значению параметра --scope=files

  • База данных менеджера управления (Manager’s database) в утилите engine-backup соответствует значению параметра --scope=db

  • База данных DWH (DWH database) - в утилите engine-backup соответствует значению параметра --scope=dwhdb

  • База данных Cinderlib (Cinderlib database) - в утилите engine-backup соответствует значению параметра --scope=cinderlibdb

  • База данных Grafana (Grafana database) - в утилите engine-backup соответствует значению параметра --scope=grafanadb

Дополнительную информацию об утилите engine-backup и её параметрах см. в разделе Синтаксис команды резервного копирования engine-backup

Хранилище (Storage)

Выбор из настроенных хранилищ резервных копий. Если не выбрано, резервная копия сохраняется локально

Использование формата Quartz cron для задания расписания

При ручном вводе выражения, определяющего расписание запуска задачи, ожидается использование формата Quartz cron. Данный формат состоит из 6 или 7 полей, разделенных пробелом. Каждое поле имеет определённую значимость.

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

q cron
Номер Имя поля Допустимые значения Разрешенные специальные символы

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 = третий в месяце).

Пример 5. Использование формата quartz cron
Выражение Значение

0 0 12 * * ?

Запуск в 12 часов дня каждый день

0 15 10 ? * *

Запуск в 10:15 утра каждый день

0 15 10 * * ? 2023

Запуск в 10:15 утра каждый день в течение 2023 года

0 * 14 * * ?

Запуск каждую минуту, начиная с 14:00 и заканчивая 14:59, каждый день

0 0/5 14,18 * * ?

Запуск каждые 5 минут, с 14:00 и до 14:55, а также с 18:00 и до 18:55, каждый день

0 15 10 ? * MON-FRI

Запуск в 10:15 утра каждый понедельник, вторник, среду, четверг и пятницу

0 15 10 L * ?

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

0 15 10 ? * 6#3

Запуск в 10:15 утра в третью пятницу каждого месяца

1.1.4. Управление разрешением на резервное копирование менеджера управления

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

Для предоставления прав на использование функций резервного копирования через веб-интерфейс, необходимо для нужной роли задать разрешение Резервное копирование менеджера управления (Engine backup management).

role backup
Разрешение Резервное копирование менеджера управления (Engine backup management) доступно только для типа учётной записи Администратор (Admin).
Для роли SuperUser разрешение Резервное копирование менеджера управления (Engine backup management) включено по умолчанию.

Дополнительную информацию по настройке ролей см. в разделах Роли и Системные разрешения в руководстве администратора.

1.2. Резервное копирование Менеджера управления c помощью утилиты engine-backup

В случае, если по каким-то причинам нет возможности использования оснастки на портале администрирования, можно использовать утилиту engine-backup, доступную через командную оболочку Менеджера управления.

1.2.1. Синтаксис команды резервного копирования engine-backup

Команда engine-backup выполняется в одном из трёх стандартных режимов:

# engine-backup --mode=backup
# engine-backup --mode=restore
# engine-backup --mode=verify

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

Таблица 4. Основные параметры
Параметр Описание

--mode

Определяет, будет ли команда выполнять операцию резервного копирования, восстановления или проверки резервной копии. Доступны три варианта: резервное копирование (backup), восстановление (restore) и проверка резервной копии (verify). Это обязательный параметр.

--file

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

--log

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

--scope

Определяет охват операции резервного копирования или восстановления. По умолчанию используется значение all.

Таблица 5. Значения параметра --scope
Значение Описание

all

Полная резервная копия всех баз данных и файлов конфигурации Менеджера управления

files

Резервная копия только файлов в системе

db

Резервная копия только базы данных Менеджера управления

dwhdb

Резервная копия только базы данных Хранилища (DWH)

cinderlibdb

Резервная копия только базы данных Cinderlib

grafanadb

Резервная копия только базы данных Grafana

keycloakdb

Резервная копия только базы данных Keycloak

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

Следующие параметры доступны только для команды engine-backup в режиме восстановления (restore). Синтаксис приведенных ниже параметров применяется к восстановлению базы данных Менеджера управления. Аналогичные параметры предусмотрены для восстановления базы данных Хранилища (DWH). См. синтаксис параметров для Хранилища (DWH) с помощью команды engine-backup --help.

Таблица 6. Параметры базы данных Менеджера управления
Параметр Описание

--provision-db

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

--change-db-credentials

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

--restore-permissions

или

--no-restore-permissions

Восстанавливает (или не восстанавливает) разрешения пользователей базы данных. Один из этих параметров обязателен при восстановлении резервной копии.

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

1.2.2. Использование утилиты engine-backup для резервного копирования

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

  1. Подключитесь по SSH к Менеджеру управления и авторизуйтесь под пользователем root.

  2. Запустите утилиту engine-backup с необходимыми параметрами.

  3. Скопируйте файл резервной копии на отдельное хранилище.

Примеры использования engine-backup
Пример 6. Запуск полного резервного копирования

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

engine-backup

Такой запуск соответствует указанию параметров --scope=all и --mode=backup. Файл резервной копии и журнал будут размещены в каталоге /var/lib/ovirt-engine-backup.

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

Start of engine-backup with mode 'backup'
scope: all
archive file: /var/lib/ovirt-engine-backup/ovirt-engine-backup-20240126165057.backup (1)
log file: /var/log/ovirt-engine-backup/ovirt-engine-backup-20240126165057.log (2)
Backing up:
Notifying engine (3)
- Files
- Engine database 'engine'
- DWH database 'ovirt_engine_history'
- Grafana database '/var/lib/grafana/grafana.db'
Packing into file '/var/lib/ovirt-engine-backup/ovirt-engine-backup-20240126165057.backup'
Notifying engine
Done.
1 - путь к файлу резервной копии.
2 - путь к файлу журнала.
3 - список резервируемых компонентов.

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

engine-backup --file=/tmp/engine-full.backup --log=/tmp/backup.log

Также можно добавить текущую дату и время к именам файлов:

engine-backup --file=/tmp/engine-full-$(date +%d-%m-%Y-%H-%M).backup --log=/tmp/backup-$(date +%d-%m-%Y-%H-%M).log
Пример 7. Запуск резервного копирования баз данных менеджера и DWH
engine-backup --scope=db --scope=dwhdb --scope=files
Обратите внимание, при указании --scope, отличного от all, обязательно также указывать --scope=files.

Пример вывода:

Start of engine-backup with mode 'backup'
scope: db,dwhdb,files
archive file: /var/lib/ovirt-engine-backup/ovirt-engine-backup-20240126174715.backup
log file: /var/log/ovirt-engine-backup/ovirt-engine-backup-20240126174715.log
Backing up:
Notifying engine
- Files
- Engine database 'engine'
- DWH database 'ovirt_engine_history'
Packing into file '/var/lib/ovirt-engine-backup/ovirt-engine-backup-20240126174715.backup'
Notifying engine
Done.

2. Восстановление менеджера управления

2.1. Восстановление из резервной копии с перезаписью существующей конфигурации

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

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

  2. Повреждена база данных Менеджера управления или DWH, но Менеджер управления доступен.

  3. Ошибки в файлах конфигурации, но Менеджер управления доступен.

Данный сценарий одинаково применяется как для режима Hosted Engine, так и для Standalone.
Предварительные требования:
  1. Менеджер управления доступен для управления через SSH или Cockpit.

  2. Для режима Hosted Engine: исходный домен хранения hosted_storage и диск ВМ Hosted Engine доступны и не повреждены.

  3. Наличие файла резервной копии.

Если Менеджер управления развернут в режиме Hosted Engine, предварительно включите режим глобального обслуживания:

  1. Подключитесь к хосту на котором выполняется ВМ Hosted Engine.

  2. Выполните команду для активации режима глобального обслуживания:

    hosted-engine --set-maintenance --mode=global
  3. Убедитесь, что режим глобального обслуживания включен:

    hosted-engine --vm-status
    
    !! Cluster is in GLOBAL MAINTENANCE mode !!
Порядок действий:
  1. Подключитесь к Менеджеру управления по SSH или через Cockpit и авторизуйтесь под пользователем root.

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

    engine-cleanup
    1. Ответьте OK на предупреждение об остановке службы ovirt-engine.

      During execution engine service will be stopped (OK, Cancel) [OK]:OK
    2. Ответьте OK на предупреждение об удалении компонентов.

      All the installed ovirt components are about to be removed, data will be lost (OK, Cancel) [Cancel]:OK
    3. При успешном завершении очистки появится уведомление:

      [ INFO  ] Execution of cleanup completed successfully
  3. Скопируйте файл резервной копии на Менеджер управления (в примере, файл лежит на одном из хостов и называется engine-full.backup):

    scp root@he-host-1.test-env.local:/backups/engine-full.backup ./
  4. Запустите процесс восстановления:

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

      engine-backup \
        --mode=restore \ (1)
        --file=<file_name> \ (2)
        --log=<log_file_name> \ (3)
        --restore-permissions (4)
      1 - использование утилиты в режиме восстановления.
      2 - необходимо указать путь к файлу резервной копии.
      3 - необходимо указать путь к файлу журнала, куда будет записываться информация о процедуре восстановления.
      4 - указывает на необходимость восстановления прав пользователей БД.

      Например:

      engine-backup --mode=restore --file=engine-full.backup --log=restore.log --restore-permissions
    • Для восстановления только баз данных Менеджера и DWH:

      engine-backup \
        --mode=restore \ (1)
        --file=<file_name> \ (2)
        --log=<log_file_name> \ (3)
        --scope=db \ (4)
        --scope=dwhdb \ (5)
        --scope=files \ (6)
        --restore-permissions (7)
      1 - использование утилиты в режиме восстановления.
      2 - необходимо указать путь к файлу резервной копии.
      3 - необходимо указать путь к файлу журнала, куда будет записываться информация о процедуре восстановления.
      4 - указывает на необходимость восстановления базы данных Менеджера.
      5 - указывает на необходимость восстановления базы данных DWH.
      6 - указывает на необходимость восстановления файлов.
      7 - указывает на необходимость восстановления прав пользователей БД.

      Например:

      engine-backup --mode=restore --scope=db --scope=dwhdb --scope=files  --file=engine-dbs.backup --log=restore.log --restore-permissions
  5. При успешном окончании процесса восстановления будет выведено уведомление, содержащее в том числе время и дату резервной копии, до которой был выполнен откат:

    ...
    The engine database was backed up at 2024-01-29 16:47:46.000000000 +0300
    ...
    You should now run engine-setup.
    Done.
  6. Запустите процесс настройки Менеджера командой engine-setup:

    1. Согласитесь с настройкой firewalld:

      Do you want Setup to configure the firewall? (Yes, No) [Yes]:Yes
    2. Ответьте No на запрос о резервном копировании БД:

      Would you like to backup the existing database before upgrading it? (Yes, No) [Yes]:No
    3. Подтвердите отказ от резервного копирования базы DWH:

      Are you sure you do not want to backup the DWH database?(Yes, No) [No]:Yes
    4. Откажитесь от использования vacuum в отношении БД Менеджера и DWH:

      Perform full vacuum on the oVirt engine history
                database ovirt_engine_history@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 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
    5. Проверьте сводку по конфигурации и подтвердите запуск настройки Менеджера:

      Please confirm installation settings (OK, Cancel) [OK]:OK
    6. При успешном выполнении настройки Менеджера появится уведомление:

      [ INFO  ] Execution of setup completed successfully

Сервисы ovirt-engine и zvirt-engine-backend запустятся автоматически.

Если Менеджер управления развернут в режиме Hosted Engine, отключите режим глобального обслуживания:

  1. Подключитесь к хосту на котором выполняется ВМ Hosted Engine.

  2. Выполните команду для активации режима глобального обслуживания:

    hosted-engine --set-maintenance --mode=none
  3. Убедитесь, что режим глобального обслуживания включен:

    hosted-engine --vm-status

    В выводе должно отсутствовать уведомление !! Cluster is in GLOBAL MAINTENANCE mode !!

На этом откат до резервной копии завершен.

При необходимости восстановите конфигурацию SDN.

2.2. Восстановление в режиме Hosted Engine

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

2.2.1. Восстановление в новый домен хранения

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

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

В такой ситуации необходимо наличие файла полной резервной копии на внешнем хранилище.

Предварительные требования:
  1. Исходный домен хранения hosted_storage и диск ВМ Hosted Engine доступны и не повреждены.

  2. В новом хранилище достаточно места для размещения диска ВМ HostedEngine.

  3. Новое хранилище не должно содержать какие-либо данные, иначе развертывание нового Менеджера завершится ошибкой.

  4. Новое хранилище должно быть доступно для всех хостов в центре данных с новым Менеджером управления.

  5. Созданы необходимые записи в зонах прямого и обратного просмотра DNS. Имейте ввиду, что новый Менеджер управления получит тот же FQDN, что и исходный.

  6. В центре данных с менеджером управления должен быть хотя бы один стандартный хост, который примет на себя роль SPM. Если такой хост отсутствует, его можно добавить следующими способами:

    1. Добавить новый стандартный хост к центру данных.

    2. Конвертировать существующий хост с ролью HostedEngine в стандартный. Данная процедура выполняется по данному описанию.

  7. При восстановлении на хост, ранее не находившийся в кластере, этот хост должен иметь уникальное полное доменное имя.

Новый Менеджер управления по данному сценарию может быть восстановлен:

  • На существующий хост с ролью Hosted Engine, включая хост, на котором ВМ Hosted Engine выполнялась до начала процедуры восстановления.

  • На новый хост, ранее не подключенный к среде.

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

Подготовка среды к восстановлению
Описание процедуры

Если Менеджер управления недоступен из-за критических ошибок, пропустите этап подготовки среды и просто выключите ВМ HostedEngine:

  1. Подключитесь по SSH или через Cockpit к хосту, на котором запущена ВМ Hosted Engine (можно определить командой hosted-engine --vm-status) и авторизуйтесь.

  2. Выключите исходный Менеджер управления:

    hosted-engine --vm-shutdown
Порядок действий:
  1. Переместите роль SPM на стандартный хост в этом же центре данных:

    1. На портале администрирования перейдите в Ресурсы  Хосты.

    2. Выделите стандартный хост.

    3. Нажмите Управление > Выбрать как SPM.

    4. Дождитесь окончания процесса переноса роли.

  2. Подключитесь по SSH или через Cockpit к любому хосту с ролью Hosted Engine и авторизуйтесь.

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

    hosted-engine --set-maintenance --mode=global
  4. Убедитесь, что режим глобального обслуживания включен:

    hosted-engine --vm-status
    
    !! Cluster is in GLOBAL MAINTENANCE mode !!
  5. Подключитесь по SSH или через Cockpit к исходному Менеджеру управления и авторизуйтесь.

  6. Остановите и удалите из автозагрузки службу ovirt-engine:

    systemctl disable --now ovirt-engine
    Хотя остановка работы исходного менеджера не является обязательной, она рекомендуется, поскольку гарантирует отсутствие изменений в среде после создания резервной копии. Кроме того, это предотвращает одновременное управление существующими ресурсами исходным и новым менеджером.
  7. Создайте полную резервную копию Менеджера управления и поместите её на внешнее хранилище.

  8. Подключитесь по SSH или через Cockpit к хосту, на котором запущена ВМ Hosted Engine и авторизуйтесь.

  9. Выключите исходный Менеджер управления:

    hosted-engine --vm-shutdown
Восстановление нового Менеджера управления из резервной копии
Описание процедуры

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

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

  2. Настройте репозитории zVirt.

  3. Установите пакет ovirt-engine-appliance:

    dnf install ovirt-engine-appliance
  4. Скопируйте файл резервной копии с внешнего хранилища на хост.

  5. Запустите терминальный мультиплексор:

    tmux
  6. Запустите процесс развертывания Менеджера управления с указанием восстановления из резервной копии (в примере используется файл резервной копии engine-full.backup):

    hosted-engine --deploy --restore-from-file=engine-full.backup
  7. Подтвердите продолжение процедуры развертывания с восстановлением:

    Are you sure you want to continue? (Yes, No)[Yes]:Yes
  8. Подтвердите продолжение процедуры развертывания с использованием IPv4:

    Do you want to continue anyway? (Yes, No)[Yes]:Yes
  9. Убедитесь в корректности IP-адреса шлюза и нажмите Enter:

    Please indicate the gateway IP address [10.252.12.254]:
  10. Подтвердите или введите нужное имя NIC на котором будет настроена сеть управления ovirtmgmt:

    Please indicate a nic to set ovirtmgmt bridge on (enp1s0) [enp1s0]:
  11. Выберите способ проверки сети (если развертывание происходит в изолированной среде, введите none):

    Please specify which way the network connectivity should be checked (ping, dns, tcp, none) [dns]:dns
  12. Введите имя центра данных (необходимо указать имя центра данных, в котором размещался исходный Менеджер управления)

    Data center:Default
  13. Введите имя кластера (необходимо указать имя кластера, в котором размещался исходный Менеджер управления)

    Cluster:Default
  14. На вопрос о перевыпуске сертификата ответьте Yes:

    Renew CA if needed? (Yes, No)[No]:Yes
  15. На вопрос о приостановке после добавления хоста:

    • Ответьте Yes, если на хосте необходимо произвести дополнительные настройки? например, добавить, дополнительные сети к интерфейсам.

    • Ответьте No, если дополнительные настройки не требуются.

    Pause after adding the host? (Yes, No)[No]:Yes
  16. На вопрос об указании пути к OVA нажмите Enter

  17. Укажите количество vCPU, выделенных ВМ HostedEngine:

    Please specify the number of virtual CPUs for the VM. The default is the appliance OVF value [4]:
  18. Укажите объем памяти, выделенный ВМ HostedEngine:

    Please specify the memory size of the VM in MB. The default is the maximum available [14155]:8192
  19. Введите и подтвердите пароль для учетной записи root Менеджера управления:

    Enter root password that will be used for the engine appliance:
    Confirm appliance root password:
  20. При необходимости укажите значение публичного ключа SSH.

  21. Укажите, разрешить ли доступ к Менеджеру по SSH для пользователя root:

    Do you want to enable ssh access for the root user? (yes, no, without-password) [yes]:
  22. Отклоните использование OpenSCAP и FIPS:

    Do you want to apply an OpenSCAP security profile? (Yes, No) [No]:
    Do you want to enable FIPS? (Yes, No) [No]:
  23. Подтвердите предложенный или при необходимости задайте свой MAC-адрес ВМ HostedEngine:

    Please specify a unicast MAC address for the VM, or accept a randomly generated default [00:16:3e:29:70:d6]:
  24. Выберите статическую конфигурацию сети Менеджера управления:

    How should the engine VM network be configured? (DHCP, Static)[DHCP]:Static
  25. Введите сетевую конфигурацию Менеджера управления:

    • Укажите IP-адрес:

      Please enter the IP address to be used for the engine VM []:10.252.12.14
    • Подтвердите предложенный или укажите другой адрес DNS-сервера:

      Engine VM DNS (leave it empty to skip) [10.252.3.250]:
  26. Подтвердите добавление необходимых записей в файл /etc/hosts на Менеджере:

    Add lines to /etc/hosts? (Yes, No)[Yes]:Yes
  27. Настройте параметры SMTP:

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

      --== HOSTED ENGINE CONFIGURATION ==--
      Please provide the name of the SMTP server through which we will send notifications [localhost]:
    • Введите порт для SMTP сервера или примите значение по умолчанию.

      Please provide the TCP port number of the SMTP server [25]:
    • Введите e-mail адрес, откуда будут отсылаться уведомления или примите значение по умолчанию.

      Please provide the email address from which notifications will be sent [root@localhost]:
    • Введите список адресов e-mail через запятую, которые будут получать уведомления или примите значение по умолчанию.

      Please provide a comma-separated list of email addresses which will get notifications [root@localhost]:
  28. Введите и подтвердите пароль для пользователя admin (Учётная запись используется для авторизации в веб-интерфейсе среды виртуализации).

    Enter engine admin password:
    Confirm engine admin password:
  29. Укажите имя хоста для сети управления или примите предложенное значение:

    Please provide the hostname of this host on the management network [he-host-1.test-env.local]:
  30. Если ранее вы ответили Yes на вопрос о приостановке развертывания после добавления хоста, на данном этапе появится возможность подключения к менеджеру управления по временной ссылке для внесения необходимых изменений.

    Для подключения к менеджеру используйте адрес https://<host-fqdn>:6900/ovirt-engine/, где <host-fqdn> - FQDN хоста, на котором выполняется развертывание менеджера.

    После внесения необходимых изменений, удалите файл, указанный в выводе сценария развертывания, например:

    [ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : Pause execution until
    /tmp/ansible.e37p54mi_he_setup_lock (1)
    is removed, delete it once ready to proceed]
    1 - Путь к файлу, который нужно удалить
  31. Укажите параметры нового хранилища, которое будет использоваться в качестве домена hosted_storage для нового Менеджера управления.

  32. Укажите размер диска ВМ Hosted Engine:

    Please specify the size of the VM disk in GiB: [51]:
  33. Дождитесь окончания развертывания Менеджера управления и вывода сообщения:

    Hosted Engine successfully deployed

При необходимости восстановите конфигурацию SDN.

Переустановка хостов с ролью Hosted Engine
Описание процедуры

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

Порядок действий:
  1. Перейдите в Ресурсы  Хосты.

  2. Выделите нужный хост и переведите его в режим обслуживания.

  3. В меню Настройка нажмите Переустановить.

  4. На вкладке Hosted Engine выберите DEPLOY и нажмите OK

Удаление исходного домена hosted_storage
Описание процедуры

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

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

  2. Перейдите в Хранилище  Домены

  3. Нажмите на имя исходного домена hosted_storage (его имя будет содержать постфикс _old_…​) для перехода в подробное представление:

    old hs
  4. Перейдите на вкладку Центр данных.

  5. Нажмите Обслуживание.

  6. После перехода в режим обслуживания нажмите Отсоединить.

  7. После отсоединения домена от центра данных нажмите Удалить. При необходимости активируйте опцию форматирования домена и нажмите OK.

2.2.2. Восстановление при повреждении хранилища hosted_storage

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

  • Потерян доступ к хранилищу hosted_storage из-за проблем, которые невозможно устранить (например, отформатирован LUN с диском ВМ HostedEngine).

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

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

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

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

  2. Новое хранилище не должно содержать какие-либо данные, иначе развертывание нового Менеджера завершится ошибкой.

  3. Созданы необходимые записи в зонах прямого и обратного просмотра DNS. Имейте ввиду, что новый Менеджер управления получит тот же FQDN, что и исходный.

  4. Хост, на котором будет проводится восстановление Менеджера управления должен иметь уникальное полное доменное имя.

  5. Наличие файла полной резервной копии, из которого будет производиться восстановление.

Подготовка среды к восстановлению
Описание процедуры

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

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

Для проверки статуса ВМ HostedEngine используйте следующую команду:

hosted-engine --vm-status

Данная команда может вернуть неизвестный статус Менеджера (например, при повреждении домена hosted_storage). В этом случае на хосте, на котором выполнялась ВМ HostedEngine (если хост не известен, выполните на всех хостах с ролью HE, чтобы убедиться, что ВМ точно выключена), используйте:

virsh -c qemu:///system?authfile=/etc/ovirt-hosted-engine/virsh_auth.conf list

Ожидаемый вывод:

Id   Name   State
--------------------

В списке не должно быть запущенной ВМ HostedEngine.

Вариант 1. Стандартное выключение
  1. Подключитесь по SSH или через Cockpit к хосту, на котором выполняется ВМ HostedEngine и авторизуйтесь.

  2. Выполните стандартную команду выключения ВМ HostedEngine:

    hosted-engine --vm-shutdown
  3. Проверьте статус ВМ:

    virsh -c qemu:///system?authfile=/etc/ovirt-hosted-engine/virsh_auth.conf list

    Ожидаемый вывод (на выключение ВМ требуется некоторое время):

    Id   Name   State
    --------------------

    В списке не должно быть запущенной ВМ HostedEngine

    Использование стандартной команды hosted-engine --vm-status вероятнее всего выдаст неизвестный статус, поэтому используем получение списка ВМ с их статусом непосредственно через virsh.
Вариант 2. Принудительное выключение с помощью virsh
  1. Подключитесь по SSH или через Cockpit к хосту, на котором выполняется ВМ HostedEngine и авторизуйтесь.

  2. Выполните команду выключения ВМ HostedEngine:

    virsh -c qemu:///system?authfile=/etc/ovirt-hosted-engine/virsh_auth.conf destroy HostedEngine
  3. Проверьте статус ВМ (на выключение ВМ требуется некоторое время):

    virsh -c qemu:///system?authfile=/etc/ovirt-hosted-engine/virsh_auth.conf list

    Ожидаемый вывод:

    Id   Name   State
    --------------------

    В списке не должно быть запущенной ВМ HostedEngine

Восстановление Менеджера управления из резервной копии
Описание процедуры

Новый Менеджер управления по данному сценарию может быть восстановлен:

  • На существующий хост с ролью Hosted Engine, включая хост, на котором ВМ Hosted Engine выполнялась до начала процедуры восстановления.

  • На новый хост, ранее не подключенный к среде.

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

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

  2. Настройте репозитории zVirt.

  3. Установите пакет ovirt-engine-appliance:

    dnf install ovirt-engine-appliance
  4. Скопируйте файл резервной копии с внешнего хранилища на хост.

  5. Запустите терминальный мультиплексор:

    tmux
  6. Перейдите в директорию с резервной копией и запустите процесс развертывания Менеджера управления с указанием восстановления из резервной копии (в примере используется файл резервной копии engine-full.backup):

    hosted-engine --deploy --restore-from-file=engine-full.backup
  7. Ответьте на стандартные вопросы по параметрам развертывания (подробно описаны в разделе выше), но обратите внимание на следующее:

    1. Введите имена исходных Центра данных и кластера.

    2. Ответьте Yes на запрос о приостановке развертывания после добавления хоста.

      1. Когда развертывание будет приостановлено подключитесь по временному адресу портала администрирования: https://<host-ip>:6900/ovirt-engine и авторизуйтесь под пользователем admin.

      2. Уничтожьте неработоспособные домены:

        • Перейдите в Хранилище  Домены.

        • Выделите нужный домен и в меню дополнительных действий нажмите Уничтожить.

        • В появившемся окне активируйте опцию Подтвердить операцию и нажмите OK.

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

  8. Дождитесь успешного развертывания Менеджера управления:

    [ INFO  ] Hosted Engine successfully deployed
Восстановление Менеджера управления в новый центр данных и кластер
Данный сценарий предполагает восстановление менеджера управления в новый центр данных и кластер с настройками по умолчанию. Исходные центр данных и кластер необходимо будет удалить. Другие существующие работоспособные центры данных и кластеры сохранят настройки.
Порядок действий
  1. Подключитесь по SSH или через Cockpit к хосту, на котором будет развертываться ВМ HostedEngine и авторизуйтесь.

  2. Настройте репозитории zVirt.

  3. Установите пакет ovirt-engine-appliance:

    dnf install ovirt-engine-appliance
  4. Скопируйте файл резервной копии с внешнего хранилища на хост.

  5. Запустите терминальный мультиплексор:

    tmux
  6. Перейдите в директорию с резервной копией и запустите процесс развертывания Менеджера управления с указанием восстановления из резервной копии (в примере используется файл резервной копии engine-full.backup):

    hosted-engine --deploy --restore-from-file=engine-full.backup
  7. Ответьте на стандартные вопросы по параметрам развертывания (подробно описаны в разделе выше), но обратите внимание на следующее:

    1. Введите новые имена Центра данных и кластера.

  8. Дождитесь успешного развертывания Менеджера управления:

    [ INFO  ] Hosted Engine successfully deployed

При необходимости восстановите конфигурацию SDN.

Переустановка хостов с ролью Hosted Engine
Описание процедуры
Данная процедура выполняется только в случае восстановления Менеджера управления в исходный ЦД и кластер!

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

Порядок действий:
  1. Перейдите в Ресурсы  Хосты.

  2. Выделите нужный хост и переведите его в режим обслуживания.

  3. В меню Настройка нажмите Переустановить.

  4. На вкладке Hosted Engine выберите DEPLOY и нажмите OK

Очистка исходного центра данных
Описание процедуры
Данная процедура выполняется только в случае восстановления Менеджера управления в новый ЦД и кластер!

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

restore to new cluster
Рисунок 1. Исходный (неработоспособный) и новый центры данных
Порядок действий:
  1. Последовательно перенесите все хосты с исходного центра данных в новый:

    1. На портале администрирования перейдите в Ресурсы  Хосты.

    2. Выделите нужный хост и переведите его в режим обслуживания.

    3. Нажмите Изменить и на вкладке Общее выберите целевой центр данных и кластер. Нажмите OK

    4. в меню Настройка нажмите Переустановить. При необходимости, на вкладке Hosted Engine выберите DEPLOY. Нажмите OK и дождитесь переустановки хоста.

  2. Последовательно уничтожьте домены хранения в исходном ЦД:

    1. На портале администрирования перейдите в Хранилище  Домены.

    2. Выделите нужный домен и в меню дополнительных действий нажмите Уничтожить.

    3. В появившемся окне активируйте опцию Подтвердить операцию и нажмите OK.

  3. Удалите кластеры исходного центра данных:

    1. На портале администрирования перейдите в Ресурсы  Кластеры.

    2. Выделите нужный кластеры и в меню дополнительных действий нажмите Удалить.

    3. В появившемся окне нажмите OK.

  4. Удалите исходный центр данных:

    1. На портале администрирования перейдите в Ресурсы  Центры данных.

    2. Выделите исходный ЦД и в меню дополнительных действий нажмите Удалить принудительно.

    3. В появившемся окне активируйте опцию Подтвердить операцию и нажмите OK.

2.2.3. Восстановление Менеджера управления в резервную среду

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

Предварительные требования
  1. Сервер в резервной инфраструктуре полностью идентичен серверам с ролью HostedEngine основной инфраструктуры:

    • Используются процессоры того же семейства.

    • На сервере установлена та же версия zVirt Node, что и в исходной инфраструктуре.

  2. Наличие файла полной резервной копии исходного Менеджера управления.

  3. Сделаны все необходимые записи в зонах прямого и обратного просмотра DNS.

  4. В новом хранилище достаточно места для размещения диска ВМ HostedEngine.

  5. Новое хранилище не должно содержать какие-либо данные, иначе развертывание нового Менеджера завершится ошибкой.

Если между исходной и резервной инфраструктурами есть сетевая связность и в исходной инфраструктуре остались работоспособные хосты, рекомендуем их выключить, чтобы избежать конфликтов IP-адресов, а также подключения старых хостов к новой инфраструктуре.
Порядок действий:
  1. Подключитесь по SSH или через Cockpit к хосту, на котором будет развертываться ВМ HostedEngine и авторизуйтесь.

  2. Настройте репозитории zVirt.

  3. Установите пакет ovirt-engine-appliance:

    dnf install ovirt-engine-appliance
  4. Скопируйте файл резервной копии с внешнего хранилища на хост.

  5. Запустите терминальный мультиплексор:

    tmux
  6. Перейдите в директорию с резервной копией и запустите процесс развертывания Менеджера управления с указанием восстановления из резервной копии (в примере используется файл резервной копии engine-full.backup):

    hosted-engine --deploy --restore-from-file=engine-full.backup
  7. Ответьте на стандартные вопросы по параметрам развертывания (подробно описаны в разделе выше), но обратите внимание на следующее:

    1. Введите новые имена или имена исходных Центра данных и кластера.

      При восстановлении в новый центр данных и кластер все настройки кластера будут сброшены.
    2. Сертификат перевыпускать не нужно.

    3. Обязательно ответьте Yes на запрос о приостановке развертывания после добавления хоста.

      1. Когда развертывание будет приостановлено подключитесь по временному адресу портала администрирования: https://<host-ip>:6900/ovirt-engine и авторизуйтесь под пользователем admin.

      2. Уничтожьте старые домены хранения (в примере на рисунке зачеркнуты):

        Не удаляйте домен ovirt-image-repository.
        • Перейдите в Хранилище  Домены.

        • Выделите нужный домен и в меню дополнительных действий нажмите Уничтожить.

        • В появившемся окне активируйте опцию Подтвердить операцию и нажмите OK.

        delete old dom
      3. Удалите все старые хосты (в примере на рисунке зачеркнуты):

        • Перейдите в Ресурсы  Хосты.

        • Выделите нужный хост и переведите его в режим обслуживания.

        • Нажмите Удалить, а затем OK.

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

        delete old hosts
        Некоторые хосты могут не перейти в режим обслуживания из-за того, что на них "выполняются ВМ", несмотря на то что хосты выключены. Чтобы исправить данную ситуацию, выделите такой хост и в дополнительных действиях нажмите Подтвердить "Хост был перезагружен". После этого повторите попытку перевода в режим обслуживания.
      4. Удалите старые кластеры (в примере на рисунке зачеркнуты):

        При удалении будьте внимательны, чтоб случайно не удалить кластер, в который восстанавливается Менеджер управления.
        • Перейдите в Ресурсы  Кластеры.

        • Выделите нужный кластер

        • В меню дополнительных действий нажмите Удалить, а затем OK.

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

        delete old cl
      5. Удалите сети, связанные со старыми центрами данных (в примере на рисунке зачеркнуты):

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

        • Выделите нужную сеть.

        • Нажмите Удалить, а затем OK.

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

        delete old net
      6. Удалите старые центры данных (в примере на рисунке зачеркнуты):

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

        • Выделите нужную ЦД.

        • Нажмите Удалить, а затем OK.

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

        delete old dc
      7. В консоли хоста, на котором производится восстановление, удалите временный файл, путь к которому указан в выводе сценария развертывания. Процесс развертывания продолжится автоматически.

  8. Дождитесь успешного развертывания Менеджера управления:

    [ INFO  ] Hosted Engine successfully deployed

После успешного восстановления добавьте необходимые ЦД, кластеры, хосты и домены хранения.

При необходимости восстановите конфигурацию SDN.

2.3. Восстановление в режиме Standalone

2.3.1. Восстановление на новый хост

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

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

Предварительные требования
  1. Наличие нового хоста с zVirt Node.

  2. Новый хост должен иметь тот же FQDN, что и исходный хост.

  3. Наличие файла полной резервной копии исходного Менеджера управления.

  4. Сделаны все необходимые записи в зонах прямого и обратного просмотра DNS.

Порядок действий
  1. Подключитесь к новому хосту по SSH или через Cockpit и авторизуйтесь под пользователем root.

  2. Скопируйте файл резервной копии на новый хост (в примере, файл лежит на одном из хостов и называется engine-full.backup):

    scp root@he-host-1.test-env.local:/backups/engine-full.backup ./
  3. Запустите процесс восстановления:

    engine-backup \
      --mode=restore \ (1)
      --file=<file_name> \ (2)
      --log=<log_file_name> \ (3)
      --restore-permissions (4)
    1 - использование утилиты в режиме восстановления.
    2 - необходимо указать путь к файлу резервной копии.
    3 - необходимо указать путь к файлу журнала, куда будет записываться информация о процедуре восстановления.
    4 - указывает на необходимость восстановления прав пользователей БД.

    Например:

    engine-backup --mode=restore --file=engine-full.backup --log=restore.log --restore-permissions
  4. При успешном окончании процесса восстановления будет выведено уведомление, содержащее в том числе время и дату резервной копии, до которой был выполнен откат:

    ...
    The engine database was backed up at 2024-01-29 16:47:46.000000000 +0300
    ...
    You should now run engine-setup.
    Done.
  5. Запустите процесс настройки Менеджера командой engine-setup:

    1. Согласитесь с настройкой firewalld:

      Do you want Setup to configure the firewall? (Yes, No) [Yes]:Yes
    2. Ответьте No на запрос о резервном копировании БД:

      Would you like to backup the existing database before upgrading it? (Yes, No) [Yes]:No
    3. Подтвердите отказ от резервного копирования базы DWH:

      Are you sure you do not want to backup the DWH database?(Yes, No) [No]:Yes
    4. Откажитесь от использования vacuum в отношении БД Менеджера и DWH:

      Perform full vacuum on the oVirt engine history
                database ovirt_engine_history@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 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
    5. Проверьте сводку по конфигурации и подтвердите запуск настройки Менеджера:

      Please confirm installation settings (OK, Cancel) [OK]:OK
    6. При успешном выполнении настройки Менеджера появится уведомление:

      [ INFO  ] Execution of setup completed successfully

Сервисы ovirt-engine и zvirt-engine-backend запустятся автоматически.

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

При необходимости восстановите конфигурацию SDN.

3. Восстановление конфигурации SDN

Предварительные требования:
  1. Менеджер управления в работоспособном состоянии.

  2. Наличие файла резервной копии конфигурации SDN (xxxxx.ovnnb_db.db, где вместо xxxxx - дата и время создания резервной копии).

Порядок действий
  1. Если Менеджер развернут в режиме Hosted Engine, включите режим глобального обслуживания.

  2. Подключитесь по ssh к Менеджеру управления.

  3. При необходимости скопируйте файл резервной копии конфигурации SDN с внешнего хранилища резервных копий на менеджер управления.

  4. Остановите работу службы ovn-northd.service при помощи команды:

    systemctl stop ovn-northd.service
  5. Скопируйте и переименуйте файл резервной копии в директорию /var/lib/ovn/ при помощи команды:

    cp xxxxx.ovnnb_db.db /var/lib/ovn/ovnnb_db.db
  6. Проверьте владельца и группу владельца файла ovnnb_db.db, в параметрах должны быть указаны openvswitch:

    # ls -l
    total 196
    -rw-r-----. 1 openvswitch openvswitch  27279 Feb  6 14:06 ovnnb_db.db
    -rw-r-----. 1 openvswitch openvswitch 169918 Feb  6 14:07 ovnsb_db.db

    Если если владельцами выступают другой пользователь и/или группа, переназначьте их на openvswitch:

    chown openvswitch:openvswitch /var/lib/ovn/ovnnb_db.db
  7. Запустите работу службы ovn-northd.service при помощи команды:

    systemctl start ovn-northd.service
  8. Выполните перезапуск Менеджера управления.

  9. Проверьте восстановленную конфигурацию в меню Сети  Управляемые сети.

  10. Если Менеджер развернут в режиме Hosted Engine, выключите режим глобального обслуживания.