# Руководство администратора Аварийное восстановление с помощью 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 ```