NetApp Disaster Recovery는 NetApp Console을 통해 액세스할 수 있는 클라우드 기반 재해 복구 서비스로, VMware 및 Kubernetes 환경을 위한 재해 복구 워크플로우를 자동화합니다. 온프레미스에서 ONTAP 스토리지를 실행하는 VMware 워크로드 또는 Trident에서 관리하는 ONTAP 스토리지를 실행하는 Kubernetes 워크로드를 재해 복구 대상으로 사용할 다른 사이트로 복제합니다. 이 서비스는 ONTAP SnapMirror 기술과 네이티브 VMware 오케스트레이션 또는 Trident Protect 오케스트레이션을 활용하여 워크로드를 보호하는 동시에 압축 및 중복 제거 등 ONTAP 스토리지 효율성을 유지합니다.

재해 복구는 별도의 활성화가 필요하지 않습니다. NetApp Console의 왼쪽 탐색 메뉴에 보호 > *재해 복구*로 자동으로 표시됩니다. NetApp Console에 액세스하려면 브라우저에서 다음 주소를 입력하십시오. "https://console.netapp.com/".

완전한 기능을 지속적으로 사용하려면 재해 복구 라이선스가 필요합니다. 라이선스 또는 구독을 구매하기 전에 30일 무료 평가판을 통해 서비스를 이용해 볼 수 있습니다. 자세한 내용은 "재해 복구 라이선스 설정"을 참조하십시오.

재해 복구는 다음과 같은 보호 목표를 지원합니다.

VMware 워크로드의 경우 NetApp Disaster Recovery는 다음과 같은 데이터 저장소 유형을 지원합니다.

Kubernetes 워크로드의 경우 Disaster Recovery는 ONTAP 스토리지의 NetApp Trident를 통해 프로비저닝된 영구 볼륨을 보호합니다.

재해 복구 서비스는 다음과 같은 라이선스 옵션을 제공합니다.

재해 복구 비용은 복제 계획이 있는 VM 또는 Kubernetes 리소스가 하나 이상 있는 경우 소스 사이트의 데이터 저장소 사용 용량을 기준으로 산정됩니다.

BYOL(Bring Your Own License)의 경우, 데이터 용량이 허용된 용량을 초과하면 추가 용량 라이선스를 취득하거나 NetApp Console에서 라이선스를 업그레이드할 때까지 서비스 내 작업이 제한됩니다.

무료 평가 기간이 종료된 후에도 워크로드 및 복제 계획 등의 리소스를 계속 보고 삭제할 수 있으며, 평가 기간 동안 생성된 모든 예약된 작업을 실행할 수 있습니다. 모든 기능을 사용하여 서비스를 계속 이용하려면 클라우드 공급업체로부터 PAYGO 구독을 구매하거나 NetApp에서 BYOL 라이센스를 구매해야 합니다.

언제든지 라이선스를 구매하거나 구독할 수 있으며, 30일 무료 체험 기간이 종료될 때까지는 요금이 부과되지 않습니다.

재해 복구는 다음과 같은 토폴로지를 지원합니다.

전체 목록은 "재해 복구 필수 조건"을 참조하십시오.

콘솔 에이전트는 NetApp Console이 ONTAP 스토리지 및 VMware vCenter 클러스터와 통신할 수 있도록 하는 소프트웨어 구성 요소입니다. 재해 복구가 제대로 작동하려면 콘솔 에이전트가 필수적입니다. 에이전트는 사설 네트워크(온프레미스 데이터 센터 또는 클라우드 VPC)에 상주하며 ONTAP 스토리지 인스턴스 및 vCenter 클러스터와 통신합니다.

온프레미스 간 재해 복구를 위해서는 온프레미스 콘솔 에이전트를 재해 복구 사이트에 설치하십시오. 온프레미스에서 AWS로의 재해 복구를 위해서는 AWS용 콘솔 에이전트를 AWS VPC에 설치하십시오. 소스 및 대상 vCenter 클러스터는 동일한 콘솔 에이전트를 사용해야 합니다. 재해 복구는 표준 모드 에이전트 배포에서만 작동합니다.

각 Kubernetes 클러스터에는 NetApp Trident가 설치되어 있어야 하고, ONTAP 백엔드 및 스토리지 클래스가 구성되어 있어야 하며, 볼륨 스냅샷 CRD 및 컨트롤러가 설치되어 있어야 합니다. 애플리케이션은 Trident 스토리지 클래스를 통해 프로비저닝된 영구 볼륨을 사용해야 합니다. Kubernetes 클러스터를 사이트로 추가하면 Disaster Recovery에서 해당 클러스터에 Trident Protect를 설치하고 등록하는 과정을 안내합니다. 단계별 명령 및 확인 사항은 "재해 복구를 위한 Kubernetes 클러스터 요구 사항"을 참조하십시오.

사이트는 논리적 컨테이너로, 일반적으로 물리적 데이터 센터 또는 클라우드 위치와 연결되며 하나 이상의 vCenter 클러스터 또는 Kubernetes 클러스터를 호스팅합니다. 복제 계획을 생성하기 전에 소스(프로덕션) 사이트와 대상(재해 복구) 사이트를 모두 추가해야 합니다.

리소스 그룹은 여러 VM, 데이터스토어 또는 Kubernetes 네임스페이스 및 리소스를 단일 단위로 관리하고 공통 스냅샷으로 보호할 수 있도록 하는 논리적 컨테이너입니다. VM은 한 번에 하나의 리소스 그룹에만 속할 수 있습니다. 보호하려는 각 애플리케이션 또는 워크로드에 대해 리소스 그룹을 생성할 수 있으며, VM은 그룹 내에서 구성한 부팅 순서에 따라 켜집니다.

복제 계획은 백업 빈도와 장애 조치 이벤트 처리 방법에 대한 규칙 집합입니다. 여기에는 소스 및 대상 사이트 선택, 리소스 그룹 할당, 복구 매핑 정의, 전원 켜기 동작 구성이 포함됩니다. 복제 계획은 데이터 복제 빈도를 통해 복구 시점 목표(RPO)를 정의합니다.

복구 시점 목표(RPO)는 재해 발생 시 허용 가능한 최대 데이터 손실량을 의미하며, 복제 계획의 복제 빈도 또는 일정에 따라 정의됩니다. 복구 시간 목표(RTO)는 재해 복구에 허용되는 최대 시간을 의미하며, 재해 복구(DR) 사이트로 페일오버하고 모든 가상 머신(VM) 또는 애플리케이션을 재시작하는 데 걸리는 시간으로 결정됩니다.

자세한 절차는 "재해 복구에 사이트 추가"을 참조하십시오.

기본적으로 리소스 검색은 24시간마다 실행되며, 환경에 맞게 일정을 사용자 지정할 수 있습니다. 최소 간격은 30분이고 최대 간격은 24시간입니다. NetApp 최신 정보를 얻기 위해 먼저 몇 차례 수동 검색을 수행한 후 자동 실행 일정을 설정하는 것을 권장합니다. 새로 추가되거나 삭제된 리소스는 다음 예약된 검색 또는 수동 검색 시 인식됩니다.

아니요. 동일한 데이터스토어에 보호된 VM과 보호되지 않은 VM을 함께 호스팅하면 문제가 발생할 수 있습니다. 특히 데이터스토어에 장애 조치가 발생하면 해당 데이터스토어에 있는 보호되지 않은 VM은 장애 조치 후 원본 환경에서 더 이상 존재하지 않으며, Disaster Recovery는 장애 조치 사이트에서 해당 VM을 시작하지 않습니다.

재해 복구를 배포하기 전에 리소스를 구성하여 보호되는 워크로드와 보호되지 않는 워크로드가 서로 다른 데이터 저장소 하위 집합을 사용하도록 하고, 단일 데이터 저장소가 둘 이상의 복제 계획에 의해 보호되지 않도록 해야 합니다.

플랫폼 관리형(ONTAP 관리형) 백업을 사용하려면 MirrorAll 정책을 사용하십시오. MirrorVault 및 *Asynchronous*도 사용할 수 있지만, 장애 조치 또는 장애 복구 중에 선택된 스냅샷이 소스 및 대상 볼륨 모두에 존재하는지 확인해야 합니다. 그렇지 않으면 "공통 스냅샷을 찾을 수 없음" 오류와 함께 작업이 실패합니다. *MirrorLatest*는 장애 조치에 사용할 수 있는 공통 스냅샷이 하나만 남기 때문에 권장하지 않습니다. Disaster Recovery에서 관리하는 SnapMirror 관계의 경우, Disaster Recovery에서 복제 타이밍을 관리하므로 서비스 외부에서 업데이트를 예약하지 마십시오.

예. 보호된 데이터스토어의 소스 볼륨과 대상 볼륨 사이에 SnapMirror 관계가 이미 존재하는 경우, Disaster Recovery는 새 관계를 생성하는 대신 모든 복제 작업에 기존 관계를 사용합니다.

예. 마이그레이션을 위해 구성된 복제 계획을 사용하여 소스 사이트에서 다른 사이트로 VMware 애플리케이션을 마이그레이션할 수 있습니다. 마이그레이션을 시작하면 서비스는 30분마다 마이그레이션이 계획대로 진행되고 있는지 확인합니다. 작업 모니터링에서 진행 상황을 확인할 수 있습니다. 현재 Kubernetes 기반 워크로드에 대한 마이그레이션은 지원되지 않습니다. 을 참조하십시오. "애플리케이션을 다른 사이트로 마이그레이션"

예. 테스트 페일오버 중에 Disaster Recovery는 선택한 스냅샷의 새 FlexClone 볼륨에서 임시 VM을 생성하고 임시 FlexClone 기반 데이터스토어를 ESXi 호스트에 매핑합니다. 이 과정은 추가적인 물리적 용량을 소모하지 않으며, 원본 소스 볼륨을 수정하지 않고, SnapMirror 관계나 프로덕션 워크로드를 중단시키지 않으며, 프로덕션 워크로드는 정상적으로 복제를 계속합니다. 테스트 후에는 페일오버 테스트 정리 작업을 사용하여 테스트 환경을 정리하십시오. 자세한 내용은 "원격 사이트로 애플리케이션 장애 조치"을 참조하십시오.

예. 기본적으로 모든 VM은 동시에 병렬로 부팅되지만, 각 VM에 순차 번호(예: 1, 2, 3)를 할당하여 부팅 순서를 제어하거나, 여러 VM에 동일한 번호를 할당하여 동시에 부팅할 수 있습니다. 또한 VM별로 부팅 지연 시간(0~10분)을 설정하여 시작 시간을 분산시킬 수 있습니다. 이는 우선순위가 높은 VM이 우선순위가 낮은 VM보다 먼저 실행되도록 하는 데 유용합니다.

페일백은 재해 복구 후 원래 소스 사이트로 운영을 복원합니다. 대상 사이트로 페일오버된 관계에서 시작하여 NetApp Disaster Recovery는 복제 방향을 반전하기 전에 모든 변경 사항을 원래 소스 VM 또는 Kubernetes 클러스터로 다시 동기화합니다. 프로세스는 다음과 같습니다.

자세한 내용은 "애플리케이션을 원래 소스로 페일백합니다."을 참조하십시오.

재해 복구 대시보드 를 사용하여 사이트 및 계획의 상태(정상, 연결 끊김 또는 성능 저하)를 확인하고, 최근 경고 및 실패한 작업을 검토하고, 보호된 워크로드와 보호되지 않은 워크로드를 식별하고, 용량을 한눈에 볼 수 있습니다. "재해 복구 계획 상태 보기"을 참조하십시오.

*작업 모니터링*을 사용하여 작업 타임스탬프, 상태 및 시작자(Disaster Recovery에서 시작한 경우 "시스템")를 확인할 수 있습니다. "진행 중" 또는 "대기 중"인 작업은 해당 작업의 Actions 메뉴에서 취소할 수 있습니다. 이는 작업이 중단되었거나 다른 작업을 우선시해야 하는 경우에 유용합니다. "재해 복구 작업 모니터링"을 참조하십시오.

VMware, Kubernetes 또는 모든 워크로드에 대한 보고서를 생성할 수 있으며, 보고서에는 복제 계획 세부 정보, 규정 준수 상태 및 작업 요약이 포함됩니다. 보고서는 PDF, HTML 또는 JSON 파일로 다운로드할 수 있습니다. 1일에서 7일까지의 기간을 포함합니다. 자세한 내용은 "재해 복구 관련 보고서 작성"을 참조하십시오.

AppVault는 Trident Protect가 Kubernetes 보호 데이터를 저장하는 클라우드 스토리지 대상입니다. Kubernetes 복제 계획을 구성하는 동안 AppVault를 생성합니다.