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

Для 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. Кроме того, сгенерированный файл маппинга переменных не будет содержать атрибут для этого домена хранения, так как он не должен быть перенесен.

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

Создайте 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.

Запустите Ansible command to generate the mapping file. The primary site’s configuration will be prepopulated.
```
# ansible-playbook dr-olvm-setup.yml --tags "generate_mapping"
```
Настройте сгенерированный файл .yml в соответствии с конфигурацией резервной площадки. Более подробно см. раздел Атрибуты файла маппинга

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

Создание сценариев восстановления (Failover) и возврата (Failback)

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

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

Опционально, создайте файл паролей (например 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 при запуске сценариев.

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

Создайте сценарий 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"

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

PreviousИнструкция по установке NextРуководство администратора

Last updated 10 months ago