# Руководство пользователя **Автоматизация аварийного восстановления с помощью `xrm`** `xrm` расположен в каталоге `./xrm-cli-install/` и предназначен для автоматизации следующих операций: * Создание файла маппинга переменных для основной и резервной площадки для аварийного восстановления (failover) и возврата (failback) * Проверка корректности файла маппинга переменных * Выполнение аварийного восстановления на резервную площадку * Выполнение возврата на основную площадку Пример запуска`xrm`: Перейти в контейнер XRM-CLI (при необходимости): ``` sudo docker exec -it xrm-cli /bin/bash ``` ``` # cd xrm-cli-install/ # ./xrm --help Log file: '/tmp/xrm-dr-1673361380128.log' usage: xrm [--conf-file=dr.conf] [--log-file=log_file.log] [--log-level=DEBUG/INFO/WARNING/ERROR] Here is a description of the following actions: generate Generate the mapping var file based on primary setup validate Validate the var file mapping failover Start a failover process to the target setup failback Start a failback process to the source setup ``` Поддерживаются следующие опциональные настройки: * Установка параметров действий в конфигурационном файле dr.conf. * Изменение расположения конфигурационного файла с помощью параметра `--conf-file` * Установка расположения файла журналов с помощью параметра `--log-file` * Установка уровня детализации журналов с помощью параметра `--log-level` **Создание файла маппинга переменных** Сценарий Ansible, используемый для создания файла маппинга переменных, предварительно заполняет файл сущностями основного сайта. Затем вам необходимо вручную добавить в файл объекты резервного сайта, такие как IP-адреса, кластер, affinity-группы, affinity-метки, внешние диски LUN, домены авторизации, роли и профили vNIC. {% hint style="info" %} Создание файла маппинга переменных завершится ошибкой, если у вас есть какие-либо диски виртуальных машин в домене хранения для self-hosted engine. Кроме того, сгенерированный файл маппинга переменных не будет содержать атрибут для этого домена хранения, так как он не должен быть перенесен. {% endhint %} Последовательность действий для создания файла маппинга переменных. 1. Создайте Ansible сценарий с использованием yaml файла (напримерd `dr_ovirt_setup.yml`) для выполнения процедуры генерации. Пример: ``` --- - name: Setup oVirt environment hosts: localhost connection: local vars: site: https://ovirt.example.com/ovirt-engine/api username: admin@internal password: pwd123 ca: /etc/pki/ovirt-engine/ca.pem var_file: disaster_recovery_vars.yml roles: - disaster_recovery collections: - ovirt.ovirt ``` Для дополнительной безопасности пароль Engine может храниться в зашифрованном виде в файле`.yml`. 2. Запустите Ansible command to generate the mapping file. The primary site’s configuration will be prepopulated. ``` # ansible-playbook dr-olvm-setup.yml --tags "generate_mapping" ``` 3. Настройте сгенерированный файл .yml в соответствии с конфигурацией резервной площадки. Более подробно см. раздел [Атрибуты файла маппинга](https://kb.x-rm.ru/dokumentaciya/dokumentaciya-xrm/rukovodstvo-administratora#atributy-faila-mappinga-peremennykh) Если используется несколько серверов, с которых предполагается выполнение операций аварийного восстановления и возврата, то скопируйте файл маппинга параметров на все необходимые серверы. **Создание сценариев восстановления (Failover) и возврата (Failback)** Перед созданием сценариев восстановления и возврата убедитесь, что вы создали и настроили файл маппинга переменных, который необходимо добавить в сценарии. Для создания сценариев выполните следующие шаги: 1. Опционально, создайте файл паролей (например `passwords.yml`) для хранения паролей Engine основной и резервной площадки, пример: ``` --- # This file is in plain text, if you want to # encrypt this file, please execute following command: # # $ ansible-vault encrypt passwords.yml # # It will ask you for a password, which you must then pass to # ansible interactively when executing the playbook. # # $ ansible-playbook myplaybook.yml --ask-vault-pass # dr_sites_primary_password: primary_password dr_sites_secondary_password: secondary_password ``` Для дополнительной безопасности пароли могут быть сохранены в файле в зашифрованном виде. В этом случае вам потребуется использовать параметр `--ask-vault-pass` при запуске сценариев. 2. Создайте сценарий Ansible, используя failover файл yaml (например, dr-ovirt-failover.yml) для выполнения процедуры восстановления: ``` --- - name: oVirt Failover hosts: localhost connection: local vars: dr_target_host: secondary dr_source_map: primary vars_files: - disaster_recovery_vars.yml roles: - disaster_recovery collections: - ovirt.ovirt ``` 3. Создайте сценарий Ansible, используя failback файл yaml (например, dr-ovirt-failback.yml) для выполнения процедуры возврата: ``` --- - name: oVirt Failback hosts: localhost connection: local vars: dr_target_host: primary dr_source_map: secondary vars_files: - disaster_recovery_vars.yml roles: - disaster_recovery collections: - ovirt.ovirt ``` **Выполнение процедуры восстановления** Перед выполнением аварийного переключения убедитесь, что вы прочитали и поняли рекомендации по работе с сетью и хранилищами из [Руководства администратора](https://kb.x-rm.ru/dokumentaciya/x-recovery-manager/rukovodstvo-administratora). Необходимо также убедиться, что: * Engine и хосты на резервном сайте работают. * реплицированные домены хранения находятся в режиме чтения/записи. * к резервному сайту не подключены реплицированные домены хранения. * машина с запущенным сервером управления XRM и Ansible, которая может подключаться через SSH к Engine на основной и резервной площадке с необходимыми пакетами и файлами: 1. Пакет `ovirt-ansible-collection` 2. Файл маппинга параметров и сценарии переключения. * SanLock должен снять все блокировки хранилища с реплицированных доменов хранения, до запуска процедуры аварийного восстановления. Эти блокировки снимаются автоматически примерно через 80 секунд после аварийного сбоя основной площадки. Чтобы выполнить аварийное восстановление на резервную площадку, запустите сценарий на сервере управления с помощью следующей команды: ``` ansible-playbook dr-ovirt-failover.yml --tags "fail_over" ``` Когда основная площадка станет активной после аварийного сбоя, убедитесь, что была выполнена корректная ее очистка после сбоя перед выполнение процедуры возврата сервисов.