액티브-액티브 재해 복구 장애 조치 구성은 두 개의 사이트에 걸쳐 있을 수 있습니다. 두 사이트 모두 활성화되어 있으며 기본 사이트를 사용할 수 없게 되면 Red Hat Virtualization 환경이 보조 사이트에서 계속 운영되어 비즈니스 연속성을 보장합니다.

액티브-액티브 장애 조치 구성에는 가상 시스템을 실행할 수 있는 호스트가 기본 사이트 및 보조 사이트 둘 다에 있는 확장 클러스터가 포함됩니다. 모든 호스트가 동일한 Red Hat Virtualization 클러스터에 속합니다.

이 구성을 사용하려면 두 사이트에서 쓰기 가능한 복제 스토리지가 필요하므로 가상 시스템이 두 사이트 간에 마이그레이션되고 두 사이트의 스토리지 모두에서 계속 실행될 수 있습니다.

그림 2.1. 클러스터 설정 확장

기본 사이트를 사용할 수 없게 되면 가상 머신을 보조 사이트로 마이그레이션합니다. 사이트를 사용할 수 있게 되고 두 사이트 모두에서 스토리지가 복제되면 가상 머신은 기본 사이트로 자동으로 장애 복구됩니다.

그림 2.2. 실패한 Stretch 클러스터

확장형 클러스터 구성은 자체 호스팅 엔진 환경 또는 독립 실행형 관리자 환경을 사용하여 구현할 수 있습니다. 다양한 유형의 배포에 대한 자세한 내용은 제품 가이드에서 Red Hat Virtualization Architecture 를 참조하십시오.

클러스터의 모든 호스트는 L2 네트워크를 통해 동일한 브로드캐스트 도메인에 있어야 합니다. 따라서 두 사이트 간의 연결은 L2여야 합니다.

L2 네트워크의 사이트 간 최대 대기 시간 요구 사항은 두 설정에 따라 다릅니다. 독립 실행형 Manager 환경에는 최대 대기 시간이 100ms인 반면 셀프 호스트 엔진 환경에는 최대 7ms의 대기 시간이 필요합니다.

Red Hat Virtualization의 스토리지 도메인은 블록 장치(SAN, iSCSI 또는 FCP) 또는 파일 시스템(NAS - NFS, GlusterFS 또는 기타 POSIX 호환 파일 시스템)을 구성할 수 있습니다. Red Hat Virtualization 스토리지에 대한 자세한 내용은 관리 가이드 의 스토리지를 참조하십시오.

사이트에는 L2(공유 계층 2) 네트워크 연결이 있는 두 사이트에서 쓰기 가능한 동기 복제 스토리지가 필요합니다. 복제된 스토리지는 가상 시스템이 사이트 간에 마이그레이션하고 사이트의 스토리지에서 계속 실행되도록 하려면 필요합니다. Red Hat Enterprise Linux 7 이상에서 지원하는 모든 스토리지 복제 옵션을 확장 클러스터에서 사용할 수 있습니다.

우선 순위를 가지도록 기본 사이트에 있는 호스트에서 SPM 역할을 설정합니다. 이 작업을 수행하려면 보조 사이트 호스트에서 SPM 우선 순위를 높은 수준으로 구성하고 SPM 우선 순위를 변경합니다. 기본 사이트 내의 네트워크 장치에 영향을 주는 기본 사이트 오류가 있는 경우, SPM 호스트의 펜싱 장치가 전원 손실과 같이 연결할 수 없게 되면 두 번째 사이트 내의 호스트가 SPM 역할을 넘겨받을 수 없습니다.

이러한 시나리오에서는 가상 시스템이 페일오버를 수행하지만, SPM 역할이 필요한 작업을 제 위치에 추가할 수 없으며, 새 디스크 추가, 기존 디스크 확장, 가상 시스템 내보내기 등의 작업을 실행할 수 없습니다.

전체 기능을 복원하려면 재해의 실제 특성을 감지하고 근본 원인을 수정하고 SPM 호스트를 재부팅한 후 SPM 호스트에 대해 Confirm 'Host has been Rebooted (다시 부팅 확인)를 선택합니다.

이 절차에서는 자체 호스팅 엔진 배포를 사용하여 확장 클러스터를 구성하는 방법을 설명합니다.

액티브-액티브 장애 조치는 기본 사이트의 호스트를 유지 관리 모드로 전환하여 수동으로 수행할 수 있습니다.

이 절차에서는 독립 실행형 관리자 배포를 사용하여 확장 클러스터를 구성하는 방법을 설명합니다.

액티브-액티브 장애 조치는 기본 사이트의 호스트를 유지 관리 모드로 전환하여 수동으로 수행할 수 있습니다.

Red Hat Virtualization은 두 사이트를 포괄할 수 있는 액티브-패시브 재해 복구 솔루션을 지원합니다. 기본 사이트를 사용할 수 없게 되면 Red Hat Virtualization 환경에서 보조 사이트(백업) 사이트로 장애 조치해야 할 수 있습니다.

장애 조치는 다음과 같은 보조 사이트에서 Red Hat Virtualization 환경을 구성하여 수행할 수 있습니다.

장애 조치 및 장애 조치(failback) 프로세스를 수동으로 실행해야 합니다. 이렇게 하려면 사이트 간에 엔터티를 매핑하고 장애 조치(failover) 및 장애 조치(failback) 프로세스를 관리하는 Ansible 플레이북을 생성해야 합니다. 매핑 파일은 Red Hat Virtualization 구성 요소에 장애 조치(failover) 또는 대상 사이트에서 다시 실패한 Red Hat Virtualization 구성 요소를 지시합니다.

다음 다이어그램에서는 Red Hat Ansible Engine을 실행하는 시스템이 고가용성이며 oVirt.disaster-recovery Ansible 역할, 구성된 플레이북 및 매핑 파일에 액세스할 수 있는 액티브- 패시브 설정을 설명합니다. Site A에 가상 머신 디스크를 저장하는 스토리지 도메인이 복제됩니다. 사이트 B에는 가상 머신이나 연결된 스토리지 도메인이 없습니다.

그림 3.1. 액티브-패시브 구성

환경이 Site B로 실패하면 스토리지 도메인이 Site B의 데이터 센터에서 먼저 연결 및 활성화되고 가상 머신이 등록됩니다. 고가용성 가상 시스템은 먼저 페일오버됩니다.

그림 3.2. 백업 사이트로 장애 조치

다시 실행되는 경우 기본 사이트(A)로 다시 실패해야 합니다.

기본 사이트 및 보조 사이트에 동일한 일반 연결이 있는지 확인해야 합니다.

여러 네트워크 또는 여러 데이터 센터가 있는 경우 매핑 파일에 빈 네트워크 매핑을 사용하여 장애 조치 중 모든 엔터티가 대상에 등록하도록 해야 합니다. 자세한 내용은 파일 속성 매핑 을 참조하십시오.

Red Hat Virtualization의 스토리지 도메인은 블록 장치(SAN, iSCSI 또는 FCP) 또는 파일 시스템(NAS - NFS, GlusterFS 또는 기타 POSIX 호환 파일 시스템)을 구성할 수 있습니다. Red Hat Virtualization 스토리지에 대한 자세한 내용은 관리 가이드 의 스토리지를 참조하십시오.

기본 및 보조 스토리지 복제본이 필요합니다. 가상 시스템 디스크 또는 템플릿이 포함된 기본 스토리지 도메인의 블록 장치 또는 공유는 복제해야 합니다. 보조 스토리지는 데이터 센터에 연결할 수 없으며 장애 조치 중에 백업 사이트의 데이터 센터에 추가됩니다.

자체 호스팅 엔진을 사용하여 재해 복구를 구현하는 경우 스토리지 도메인이 실패하지 않으므로 Manager 가상 시스템에서 사용하는 스토리지 도메인에 가상 시스템 디스크가 포함되지 않도록 합니다.

Red Hat Enterprise Linux 7 이상에서 지원하는 복제 옵션이 있는 모든 스토리지 솔루션을 사용할 수 있습니다.

Ansible은 재해 복구 장애 조치 및 장애 복구 장애 조치(failback)를 시작하고 관리하는 데 사용됩니다. 이를 위해 Ansible 플레이북을 생성해야 합니다. Ansible 플레이북 생성에 대한 자세한 내용은 Ansible 설명서를 참조하십시오.

보조 사이트에서 선호도 그룹, 선호도 레이블, 사용자 등 기본 사이트에 있는 환경 속성을 생성하는 것도 좋습니다.

다음 플레이북을 생성해야 합니다.

또한 실패하기 전에 기본 사이트를 정리하는 선택적 플레이북을 만들 수 있습니다.

장애 조치 및 장애 조치를 관리하는 Ansible 시스템에서 /usr/share/ansible/roles/oVirt.disaster-recovery/ 에서 플레이북 및 관련 파일을 생성합니다. 관리할 수 있는 여러 개의 Ansible 시스템이 있는 경우 파일을 모든 Ansible에 복사해야 합니다.

Active-Passive 구성 테스트에서 하나 이상의 테스트 절차를 사용하여 구성을 테스트할 수 있습니다.

# ./ovirt-dr generate/validate/failover/failback
              [--conf-file=dr.conf]
              [--log-file=ovirt-dr-log_number.log]
              [--log-level=DEBUG/INFO/WARNING/ERROR]

---
# 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

---
- name: Failover RHV
  hosts: localhost
  connection: local
  vars:
    dr_target_host: secondary
    dr_source_map: primary
  vars_files:
    - disaster_recovery_vars.yml
    - passwords.yml
  roles:
    - oVirt.disaster-recovery

---
- name: Failback RHV
  hosts: localhost
  connection: local
  vars:
    dr_target_host: primary
    dr_source_map: secondary
  vars_files:
    - disaster_recovery_vars.yml
    - passwords.yml
  roles:
    - oVirt.disaster-recovery

---
- name: clean RHV
  hosts: localhost
  connection: local
  vars:
    dr_source_map: primary
  vars_files:
    - disaster_recovery_vars.yml
  roles:
    - oVirt.disaster-recovery

이 예에서는 이전에 만든 dr-rhv-failover.yml 플레이북을 사용합니다.

페일오버 후에는 기본 사이트에서 다시 실패하기 전에 환경을 정리해야 합니다.

이 예에서는 이전에 만든 dr-cleanup.yml 플레이북을 사용하여 환경을 정리합니다.

장애 조치(failover)되면 기본 사이트로 장애 조치(failover)할 수 있으며 환경을 정리하는 데 필요한 단계를 수행한 경우 기본 사이트로 다시 실패할 수 있습니다.

이 예에서는 이전에 만든 dr-rhv-failback.yml 플레이북을 사용합니다.