Руководство пользователя

Для XRM версии 1.0

Автоматизация аварийного восстановления с помощью 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 <generate/validate/failover/failback>
                        [--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.

Создание файла маппинга переменных завершится ошибкой, если у вас есть какие-либо диски виртуальных машин в домене хранения для self-hosted engine. Кроме того, сгенерированный файл маппинга переменных не будет содержать атрибут для этого домена хранения, так как он не должен быть перенесен.

Последовательность действий для создания файла маппинга переменных.

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 в соответствии с конфигурацией резервной площадки. Более подробно см. раздел Атрибуты файла маппинга

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

Создание сценариев восстановления (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

Выполнение процедуры восстановления

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

Необходимо также убедиться, что:

• Engine и хосты на резервном сайте работают.

• реплицированные домены хранения находятся в режиме чтения/записи.

• к резервному сайту не подключены реплицированные домены хранения.

• машина с запущенным сервером управления XRM и Ansible, которая может подключаться через SSH к Engine на основной и резервной площадке с необходимыми пакетами и файлами:

  1. Пакет ovirt-ansible-collection

  2. Файл маппинга параметров и сценарии переключения.

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

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

ansible-playbook dr-ovirt-failover.yml --tags "fail_over"

Когда основная площадка станет активной после аварийного сбоя, убедитесь, что была выполнена корректная ее очистка после сбоя перед выполнение процедуры возврата сервисов.