스토리지 시스템은 공유 장애 지점입니다. Proxmox VE HA는 호스트 장애로부터 테넌트 VM을 보호하지만, 해당 디스크를 호스팅하는 스토리지 시스템의 장애로부터는 보호하지 않습니다. 스토리지 운영 중단은 해당 시스템의 모든 테넌트에 영향을 미칩니다.

고가용성을 판매할 방법이 없습니다. 동기식 복제 및 자동 스토리지 장애 조치가 없으면 공급업체는 데이터 손실 제로 및 더욱 강력한 가동 시간 보장을 제공하는 프리미엄 가용성 등급을 제공할 수 없습니다.

복구 중 테넌트 격리. 복구, 유지 관리 및 재해 복구 테스트는 전체 플랫폼이 아닌 관련 테넌트에만 영향을 미쳐야 합니다.

QDevice에는 여전히 세 번째 위치가 필요합니다. ONTAP Cloud Mediator는 미디에이터 호스트를 제거하는 것이지, corosync QDevice 호스트를 제거하는 것은 아닙니다. QDevice는 모든 Proxmox VE 노드가 TCP 포트 5403을 통해 접근할 수 있는 소형 Linux 호스트가 필요하며, corosync처럼 낮은 지연 시간이 요구되는 것은 아닙니다.

두 클러스터 모두 NetApp Console에 액세스해야 합니다. 클러스터에서 프록시를 사용하는 경우, 프록시의 루트 CA 인증서를 두 클러스터 모두에 설치하십시오. NetApp은 각 클러스터에 서로 다른 프록시 서버를 사용할 것을 권장합니다.

두 옵션 모두 동일한 장애 동작을 계획하십시오. 미디에이터를 사용할 수 없는 경우 데이터 손실 없이 복제가 계속되지만, 미디에이터를 다시 사용할 수 있을 때까지 자동 및 계획된 장애 조치는 불가능합니다. ONTAP Cloud Mediator의 경우, 여기에는 클러스터에서 NetApp Console로의 연결 손실이 포함됩니다.

호스트 고가용성을 뛰어넘는 VM 가용성. 테넌트 VM은 해당 디스크를 호스팅하는 스토리지 시스템에 장애가 발생해도 계속 실행됩니다. ONTAP은 두 번째 AFF 클러스터로 페일오버되며, VM은 재시작 없이 동일한 공유 스토리지에서 I/O를 재개합니다.

프리미엄 가용성 등급. 동일한 클러스터 내의 보호되지 않은 스토리지에 대한 표준 등급과 함께 RPO가 0이고 스토리지 복원력이 뛰어난 VM 서비스를 추가 기능으로 제공할 수 있습니다.

테넌트별 보호 및 장애 조치. 각 테넌트 또는 서비스 계층별로 별도의 보호 스토리지를 통해 다른 테넌트에 영향을 주지 않고 각 테넌트를 독립적으로 보호하고, 장애 조치를 수행하며, 재해 복구를 테스트할 수 있습니다.

두 사이트의 더 나은 활용. 일부 워크로드는 A 사이트를 기본으로, 다른 워크로드는 B 사이트를 기본으로 지정하여 두 데이터 센터 모두에서 활성 워크로드를 처리할 수 있습니다.

스토리지 또는 사이트 장애 발생 시 비즈니스 핵심 VM의 데이터 손실이 전혀 없습니다.

스크립트, 스토리지 재마운트 또는 `/etc/pve/storage.cfg`에 대한 변경 없는 자동 복구.

ONTAP에 내장되어 있으며, Proxmox VE 노드에 추가 소프트웨어 레이어가 없습니다.

하나의 인터페이스에서 일상적인 운영을 수행합니다. Proxmox용 Storage Manager는 보호된 공유 스토리지를 프로비저닝하고 ONTAP 스냅샷 및 FlexClone 기술을 사용하여 VM을 백업, 복원 및 복제합니다.

기업이 클러스터에서 미션 크리티컬 VM만 실행하거나 서비스 제공업체가 모든 테넌트에게 동일한 가용성 계층을 제공하는 경우 등 스토리지의 모든 또는 거의 모든 워크로드에 RPO 제로가 필요한 경우 MetroCluster를 선택하십시오. 워크로드별 구성 없이 하나의 보호 도메인을 얻게 됩니다.

일부 워크로드에만 RPO 0이 필요한 경우(예: 일부 테넌트를 위한 프리미엄 티어) 또는 한 번에 하나의 테넌트나 애플리케이션에 대해 장애 조치 또는 재해 복구 테스트가 필요한 경우 SnapMirror 활성 동기화를 선택하십시오.

SnapMirror NAS용 액티브 동기화는 MetroCluster 구성에서 지원되지 않습니다. 각 클러스터 쌍에 대해 하나의 솔루션을 사용하십시오.

이 솔루션의 corosync, QDevice 및 HA 지침은 두 가지 모두에 적용됩니다. MetroCluster의 경우, 사이트 간 링크 장애 발생 시 데이터를 계속 제공하는 사이트에 QDevice 타이브레이커를 맞추고, HA 노드 선호도 규칙을 사용하여 VM을 활성 SVM과 동일한 사이트에 유지하십시오.

MetroCluster IP는 사이트 간 레이어 3 네트워크를 위해 BGP를 사용하는 VIP LIF도 지원합니다.

SnapMirror 활성 동기화에는 클러스터 간 왕복 시간(RTT)이 10ms 미만이어야 합니다. Proxmox는 모든 노드 간 corosync 지연 시간이 5ms 미만일 것을 권장하므로, corosync 요구 사항이 솔루션의 거리 제한을 설정합니다.

Corosync는 높은 대역폭보다는 낮고 일관된 지연 시간을 필요로 합니다. 스토리지 버스트로 인해 corosync 시간 초과가 발생하지 않도록 스토리지 및 라이브 마이그레이션 트래픽과 분리된 corosync용 전용 네트워크를 사용하십시오.

사이트 간의 서로 다른 물리적 경로에 최소 두 개의 corosync 링크(예: 링크 0 및 링크 1)를 구성하십시오. Corosync는 한 경로에 장애가 발생할 경우 Kronosnet을 사용하여 자동으로 링크를 전환합니다.

Proxmox VE HA는 일반적으로 노드 장애를 감지하고 60초의 워치독 펜싱 타임아웃을 포함하여 약 2분 내에 해당 VM을 복구합니다. 사이트 장애 발생 시 SnapMirror 액티브 동기화 페일오버와 Proxmox VE HA 복구는 병렬로 실행됩니다.

HA 노드 선호도 규칙과 노드 우선순위를 사용하여 VM을 기본 스토리지와 동일한 사이트의 노드에 배치하고, 다른 사이트로 페일오버할 수 있도록 합니다.

사이트 장애 조치 후, 스토리지를 페일백할 때까지 영향을 받는 VM에 대해 HA failback 속성을 0(으)로 설정하십시오. 그렇지 않으면 활성 스토리지가 여전히 사이트 B에 있는 동안 HA는 사이트 A 노드가 복구되는 즉시 VM을 사이트 A 노드로 다시 마이그레이션합니다.

게스트 운영 체제의 디스크 시간 제한이 예상되는 장애 조치 시간보다 길게 설정되어 있는지 확인하십시오. 이렇게 하면 스토리지 장애 조치 중에 게스트 운영 체제에서 I/O 오류가 보고되지 않습니다.

리소스 그룹과 백업 정책을 사용하여 테넌트 또는 애플리케이션의 VM에 동일한 일정과 보존 기간을 적용하십시오.

QEMU 게스트 에이전트가 실행되는 VM의 경우 파일 일관성 백업을 사용하십시오. 이렇게 하면 ONTAP이 스냅샷을 생성하기 전에 게스트 파일 시스템이 정지됩니다.

SMP는 활성 스토리지를 관리합니다. SnapMirror 활성 동기화 장애 조치 후에는 백업 또는 복원 작업을 실행하기 전에 SMP에서 검색을 실행하여 스토리지를 클러스터 B에 매핑해야 합니다.

두 사이트 외부에 세 번째 복사본을 만들거나 더 긴 기간 동안 보존하려면 보호된 볼륨에서 SnapMirror 비동기 팬아웃 관계를 추가하거나 Proxmox Backup Server를 사용하십시오.

SnapMirror 활성 동기화에서는 변조 방지 스냅샷이 지원되지 않으므로 보호된 볼륨에 대해 SMP에서 스냅샷 잠금을 활성화하지 마십시오.

스토리지 또는 사이트 장애 발생 후에도 SMP를 계속 사용할 수 있도록 SnapMirror 활성 동기화로 보호되는 공유 스토리지에서 SMP VM을 HA 리소스로 실행하십시오.

SMP가 어느 사이트에서든 활성 스토리지에 접근할 수 있도록 Proxmox VE 클러스터와 두 개의 ONTAP 클러스터를 SMP에 등록하십시오.

SnapMirror active sync for NAS는 전체 스토리지 VM(SVM)을 보호합니다. SVM의 모든 볼륨을 보호하거나 선택한 볼륨을 제외할 수 있습니다. FlexVol 볼륨만 지원되며, SVM에는 LUN이 포함될 수 없습니다.

보조 SVM은 장애 조치가 발생할 때까지 LIF가 다운된 상태로 대기합니다. ONTAP은 LIF IP 주소, 내보내기 정책, NFS 설정 등 SVM 구성을 복제하므로 장애 조치 후 보조 SVM은 동일한 NFS 엔드포인트를 제공합니다.

NFSv3 이상 버전에서는 장애 조치가 서비스 중단 없이 이루어집니다.

NAS용 SnapMirror 액티브 동기화는 액티브/패시브 방식이므로 사이트 B의 노드에 있는 VM은 사이트 간 네트워크를 통해 기본 SVM에 읽기/쓰기 작업을 수행합니다. 양쪽 사이트에서 활성 워크로드를 실행하려면 복제 방향이 반대인 두 개의 SVM(각 사이트에 하나씩 기본 SVM)을 사용하고 각 VM의 노드 선호도 규칙을 기본 SVM이 위치한 사이트와 일치시키십시오.

SnapMirror NAS용 액티브 동기화는 AFF A-Series 및 C-Series 2노드 클러스터에서 지원됩니다.

nConnect. 단일 NFS LIF 주소에 대해 여러 TCP 연결을 열어줍니다(예 nconnect=4). nConnect는 NFSv3 및 NFSv4.1과 단일 VIP LIF 주소를 지원하므로 레이어 3 네트워크를 비롯한 NAS용 SnapMirror 액티브 동기화에 권장되는 옵션입니다.

세션 트렁킹. 예를 들어 여러 데이터 LIF를 하나의 NFSv4.1 세션으로 그룹화합니다 vers=4.1,trunkdiscovery,max_connect=16. 세션 트렁킹에는 NFSv4.1 이상이 필요합니다. 확장된 레이어 2 네트워크 등 클라이언트가 양쪽 사이트에서 모두 접근할 수 있는 여러 데이터 LIF가 보호되는 SVM에 있는 경우에만 사용하십시오. 자세한 내용은 "NFS 트렁킹"을(를) 참조하십시오.

기본 SVM에 볼륨을 프로비저닝하고, NFS LIF 또는 레이어 3 네트워크의 VIP LIF를 기본 LIF로 선택합니다. 보조 SVM은 장애 조치 후에도 동일한 주소를 사용하므로 스토리지 정의가 유효하게 유지됩니다.

HA가 어느 노드에서든 VM을 재시작할 수 있도록 양쪽 사이트의 모든 Proxmox VE 노드에 스토리지를 마운트하십시오.

내보내기 정책에서 양쪽 사이트의 Proxmox VE 노드를 허용하는지 확인하십시오. ONTAP은 내보내기 정책을 보조 SVM으로 복제합니다.

프로비저닝 후 볼륨이 SnapMirror 활성 동기화 보호에 포함되었는지 확인하십시오.

BGP LIF는 페일오버되지 않습니다. 이중화는 노드당 두 개의 BGP LIF를 통해 이루어지며, 각 LIF는 서로 다른 라우터와 피어링합니다. 노드가 SVM에 대한 모든 BGP 세션을 잃으면 ONTAP은 해당 SVM에 대한 활성 BGP 세션이 있는 다른 노드로 VIP LIF를 이동시킵니다.

각 ONTAP 노드와 각 라우터에 대해 고유한 사설 자율 시스템 번호(ASN)와 함께 외부 BGP(eBGP)를 사용하십시오.

각 BGP LIF와 해당 라우터에 대해 /31 서브넷(넷마스크 255.255.255.254)을 사용하십시오. 홀수 번호 주소는 BGP LIF에, 짝수 번호 주소는 라우터에 할당하십시오.

ONTAP은 라우터의 경로를 처리하지 않습니다. 라우터가 ONTAP에서 /32 호스트 경로를 수락하고 클러스터로 경로 업데이트를 전송하지 않도록 구성하십시오.

Proxmox VE 노드는 VIP 주소와 동일한 서브넷을 공유해서는 안 됩니다. 노드와 스토리지 사이의 경로에는 VRRP 또는 HSRP를 지원하는 이중화된 레이어 3 라우터가 있어야 합니다.

`-use-peer-as-next-hop true`을(를) 사용하여 각 클러스터가 로컬 라우터에서 기본 경로를 학습하도록 BGP 피어 그룹을 구성하십시오. 장애 조치 후 사이트 B에서는 사이트 A 게이트웨이를 가리키는 경로가 유효하지 않습니다.

발신 VIP 트래픽이 사용 가능한 모든 BGP LIF 포트를 사용하도록 다중 경로 라우팅을 활성화하십시오.

BGP 유지 시간을 기본값인 180초에서 줄이십시오. TR-4949에서는 유지 시간을 3초로 권장합니다. 라우터는 유지 타이머가 만료될 때만 장애가 발생한 클러스터에서 경로를 철회하며, 스토리지 시스템 장애 발생 시 사이트 A의 라우터는 온라인 상태를 유지합니다.