재해 복구 사용 사례에 NSX 페더레이션과 함께 SRM(VMware Site Recovery Manager™)을 사용할 수 있습니다.
Site Recovery Manager는 NSX 페더레이션과 함께 다음 워크플로를 지원합니다.
- NSX 페더레이션 GM(글로벌 관리자) VM은 GM VM의 전체 및 테스트 복구를 지원합니다(NSX 페더레이션 관리 클러스터 VIP의 사용 여부에 관계없이 지원됨).
- 계산 VM은 계산 VM의 전체 및 테스트 복구를 지원합니다. 재해 복구 사이트의 복구된 VM에는 이러한 NSX 태그를 기준으로 하거나 IP 주소 및 VM 이름과 같이 그러지 않은 NSX 태그 및 방화벽 규칙이 있습니다.
복구 중에 그룹 및 방화벽 규칙이 재해 복구 위치에서 복제되도록 하려면 재해 복구 위치를 관리하는 NSX 로컬 관리자에 복구 시에 NSX 태그가 있어야 합니다.
NSX 페더레이션 3.2 이전에는 SRM이 로컬 관리자 간에 VM 태그 복제를 지원하지 않았습니다. 그 결과 NSX는 VM 태그를 기준으로 하는 보안을 복구된 VM에 복제하지 않았습니다. VM 태그(예: IP 주소 또는 VM 이름)를 기준으로 하지 않는 보안은 복구된 VM에 적용될 수 있습니다.
NSX 페더레이션 릴리스 4.1.1에서는 두 필드인 replication _type
및 tag_delay_delete_time
이 스토리지 어레이 복제를 지원합니다. 기본 사이트에서 SRM의 복구 사이트로의 스토리지 어레이 복제를 사용하는 경우 태그 복제 정책 replication type
을 STORAGE_ARRAY_REPLICATION으로 생성하거나 업데이트합니다.
기본 사이트에서 복구 사이트로의 재해 복구 또는 계획된 마이그레이션 옵션을 사용하여 가상 시스템을 마이그레이션할 SRM에서 보호 계획을 실행하면 가상 시스템이 복구 사이트로 이동되고 기본 사이트에서 가상 시스템이 삭제됩니다. 관련 가상 시스템이 기본 사이트에서 삭제되고 tag_delay_delete_time 설정 내의 복구 사이트에 표시되면 기본 사이트의 태그가 복구 사이트의 가상 시스템에 복제됩니다. 스토리지 어레이 복제의 경우 VM이 기본 사이트에서 삭제된 후 복구 사이트에 표시되는 시간은 페일오버, 스토리지 어레이 성능 및 ESXi 호스트로 구성된 VM 수에 따라 다릅니다.
vSphere 복제를 사용하여 기본 사이트에서 SRM의 복구 사이트로 VM을 복제하는 경우 가상 시스템이 기본 사이트에서 삭제되지 않습니다. 따라서 태그 복제 정책에서 replication_type 또는 tag_delay_delete_time을 지정할 필요가 없습니다.
GM API를 사용하여 LM 간 VM 태그 복제 구성
PUT https://{{gm}}/global-manager/api/v1/global-infra/vm-tag-replication-policies/policy1 { "display_name":"vm tag replication policy Paris to London", "description":"vm tag replication policy1", "protected_site": "/global-infra/sites/LM_Paris", "replication_type": "STORAGE_ARRAY_REPLICATION", "tag_delay_delete_time": 30, "recovery_sites": [ "/global-infra/sites/LM_London" ], "groups":[ "/global-infra/domains/default/groups/Web-VM-Group", "/global-infra/domains/default/groups/DB-VM-Group" ], "vm_match_criteria": "MATCH_BIOS_UUID_NAME"
PUT https://{{gm}}/global-manager/api/v1/global-infra/vm-tag-replication-policies/policy1 { "display_name":"vm tag replication policy Paris to London", "description":"vm tag replication policy1", "protected_site": "/global-infra/sites/LM_Paris", "recovery_sites": [ "/global-infra/sites/LM_London" ], "groups":[ "/global-infra/domains/default/groups/Web-VM-Group", "/global-infra/domains/default/groups/DB-VM-Group" ], "vm_match_criteria": "MATCH_BIOS_UUID_NAME"
vm_match_criteria
에는 두 개의 가능한 값 MATCH_BIOS_UUID_NAME 또는 MATCH_NSX_ATTACHMENT_ID가 있습니다. 복구 시 SRM은 모든 구성이 SRM에서 유효하도록 두 값을 모두 복사합니다. 그러나 다른 제품이 VM 복제를 완료하고 하나는 복사하지만 다른 값은 복사하지 않는 경우에는 적절한 vm_match_critria 값을 사용하여 GM을 구성합니다.
VM이 기본 사이트에서 사라지고 보호된 사이트에 표시되는 데 걸리는 시간을 예측하려면 보호 계획에 대한 테스트를 수행하고 스토리지 동기화 종료와 우선 순위 X VM 전원 켜기 단계 완료 사이의 시간 간격을 측정할 수 있습니다. tag_delay_delete_time
을 예상 시간보다 크게 설정합니다. 또 다른 팁은 Site Recovery Manager에서 보호 계획을 실행하고 tag_delay_delete_time
을 보호된 사이트에서 VM을 종료 단계와 SRM에서 보호 계획 실행을 수행하는 동안 우선 순위 X VM 전원 켜기 단계 완료 사이에 걸리는 시간보다 크게 설정하는 것입니다.
GM API를 사용하여 LM 간 VM 태그 복제 확인
GET https://{{gm}}/global-manager/api/v1/global-infra/vm-tag-replication-policies
{ "protected_site": "/global-infra/sites/LM_Paris", "recovery_sites": [ "/global-infra/sites/LM_London" ], "vm_match_criteria": "MATCH_BIOS_UUID_NAME", "groups": [ "/global-infra/domains/default/groups/Web-VM-Group", "/global-infra/domains/default/groups/DB-VM-Group" ], "resource_type": "VMTagReplicationPolicy", "id": "policy1", "display_name": "vm tag replication policy Paris to London", "description": "vm tag replication policy1", "path": "/global-infra/vm-tag-replication-policies/policy1", "relative_path": "policy1", "parent_path": "/global-infra", "unique_id": "9ee18586-5480-41d9-8223-690c9226d763", "marked_for_delete": false, "overridden": false, "_create_time": 1638413861377, "_create_user": "admin", "_last_modified_time": 1638413861377, "_last_modified_user": "admin", "_system_owned": false, "_protection": "NOT_PROTECTED", "_revision": 0 }
NSX는 복구 사이트의 항목을 하나만 지원합니다. 자세한 내용은 "NSX 글로벌 관리자 REST API 가이드" 에서 vm-tag-replication-policies/policy-name API를 참조하십시오.