Руководство администратора

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

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

• Дополнительного сервера управления.

• Резервного дата-центра и кластеров.

• Сети с такими же общими связями, как и на основной площадке.

• Активные серверы, способные запускать виртуальные машины после отработки отказа.

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

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

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

Рекомендации для сети

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

Рекомендации для хранилищ

Для хранения данных может быть использовано блочное устройство (iSCSI или FC), или файловая система (NAS/NFS или GlusterFS). Поддерживаются только домены хранения данных, которые реплицируются между площадками.

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

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

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

По умолчанию метаданные автоматически обновляются с интервалом в 60 минут. Это означает, что вы потенциально можете потерять изменения в течение последнего интервала. Чтобы избежать такой потери, вы можете вручную обновить метаданные с портала администрирования, перейдя в раздел домена хранения и нажав «Обновить OVF» . Или вы можете изменить параметры сервера управления, чтобы изменить частоту обновления, например:

engine-config -s OvfUpdateIntervalInMinutes=30 
systemctl restart ovirt-engine

Атрибуты файла маппинга переменных

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

• Атрибуты площадки

  Атрибуты, которые сопоставляют сведения о сервере управления (Engine) на основной и резервной площадках, например:

  dr_sites_primary_url: https://manager1.mycompany.com/ovirt-engine/api
  dr_sites_primary_username: admin@internal
  dr_sites_primary_ca_file: /etc/pki/ovirt-engine/ca.pem
  
  # Please fill in the following properties for the secondary site:
  dr_sites_secondary_url: https://manager2.mycompany.com/ovirt-engine/api
  dr_sites_secondary_username: admin@internal
  dr_sites_secondary_ca_file: /etc/pki/ovirt-engine/ca.pem

• Атрибуты доменов хранения

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

  dr_import_storages:
  - dr_domain_type: nfs
    dr_primary_name: DATA
    dr_master_domain: True
    dr_wipe_after_delete: False
    dr_backup: False
    dr_critical_space_action_blocker: 5
    dr_warning_low_space: 10
    dr_primary_dc_name: Default
    dr_discard_after_delete: False
    dr_primary_path: /storage/data
    dr_primary_address: 10.64.100.xxx
    # Fill in the empty properties related to the secondary site
    dr_secondary_dc_name: Default
    dr_secondary_path: /storage/data2
    dr_secondary_address:10.64.90.xxx
    dr_secondary_name: DATA

• Атрибуты кластера

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

  dr_cluster_mappings:
    - primary_name: cluster_prod
      secondary_name: cluster_recovery
    - primary_name: fc_cluster
      secondary_name: recovery_fc_cluster

• Сведения о Affinity-группах

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

  dr_affinity_group_mappings:
  - primary_name: affinity_prod
    secondary_name: affinity_recovery

• Сведения о Affinity-метках

  Атрибуты, которые сопоставляют Affinity-метки, которым принадлежат виртуальные машины, например:

  dr_affinity_label_mappings:
  - primary_name: affinity_label_prod
    secondary_name: affinity_label_recovery

• Домены аутентификации, авторизации и учетные данные

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

  dr_domain_mappings:
  - primary_name: internal-authz
    secondary_name: recovery-authz
  - primary_name: external-authz
    secondary_name: recovery2-authz

• Сведения о ролях

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

  dr_role_mappings:
  - primary_name: admin
    Secondary_name: newadmin

• Сведения о сети

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

  dr_network_mappings:
  - primary_network_name: ovirtmgmt
    primary_profile_name: ovirtmgmt
    primary_profile_id: 0000000a-000a-000a-000a-000000000398
    # Fill in the correlated vnic profile properties in the secondary site for profile 'ovirtmgmt'
    secondary_network_name: ovirtmgmt
    secondary_profile_name: ovirtmgmt
    secondary_profile_id:  0000000a-000a-000a-000a-000000000410

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

  dr_network_mappings:
  # No mapping should be here

• Сведения о внешних LUN-дисках

  Атрибуты LUN позволяют регистрировать виртуальные машины на соответствующем внешнем диске LUN ​​после операций failover и failback, например:

  dr_lun_mappings:
  - primary_logical_unit_id: 460014069b2be431c0fd46c4bdce29b66
    primary_logical_unit_alias: My_Disk
    primary_wipe_after_delete: False
    primary_shareable: False
    primary_logical_unit_description: 2b66
    primary_storage_type: iscsi
    primary_logical_unit_address: 10.35.xx.xxx
    primary_logical_unit_port: 3260
    primary_logical_unit_portal: 1
    primary_logical_unit_target: iqn.2017-12.com.prod.example:444
    secondary_storage_type: iscsi
    secondary_wipe_after_delete: False
    secondary_shareable: False
    secondary_logical_unit_id: 460014069b2be431c0fd46c4bdce29b66
    secondary_logical_unit_address: 10.35.x.xxx
    secondary_logical_unit_port: 3260
    secondary_logical_unit_portal: 1
    secondary_logical_unit_target: iqn.2017-12.com.recovery.example:444