Azure Stack Hub 가상 머신의 재해 복구

이 문서에서는 Azure Stack Hub에서 호스트되는 VM(가상 머신)에서 실행되는 워크로드의 재해 복구에 최적화된 방식을 제공하는 솔루션의 아키텍처 및 디자인 고려 사항에 대해 설명합니다.

아키텍처

이 아키텍처의 Visio 파일을 다운로드합니다.

워크플로

제안된 솔루션의 클라우드 구성 요소에는 다음 서비스가 포함됩니다.

• 이 솔루션의 일부인 모든 클라우드 리소스를 호스팅하는 Azure 구독입니다.

• Azure 리소스에 대한 액세스 권한을 부여하기 위해 Microsoft Entra 보안 주체의 인증을 제공하는 Azure 구독과 연결된 Microsoft Entra ID 테넌트입니다.

• Azure Stack Hub 배포를 호스팅하는 온-프레미스 데이터 센터에 가장 가까운 Azure 지역의 Azure Recovery Services 보관소.

  참고

  온-프레미스 데이터 센터에 가장 가까운 Azure 지역 선택은 이 문서에 포함된 샘플 시나리오에 따라 다릅니다. 재해 복구 관점에서 프로덕션 환경을 호스트하는 위치에서 더 멀리 떨어진 Azure 지역을 선택하는 것이 좋습니다. 그러나 결정은 지역 데이터 피드의 대기 시간을 최소화하거나 데이터 보존 요구 사항을 충족해야 하는 필요성과 같은 다른 요인에 따라 달라질 수 있습니다.

• 개인 피어링 및 Microsoft 피어링으로 구성된 Azure Recovery Services 자격 증명 모음을 호스팅하는 Azure 지역에 온-프레미스 데이터 센터를 연결하는 Azure ExpressRoute 회선. 전자는 장애 조치(failover) 후 대기 시간 요구 사항이 충족되도록 합니다. 후자의 목적은 온-프레미스 워크로드와 Azure의 장애 조치(failover) 사이트 간에 변경 내용을 복제하는 데 걸리는 시간을 최소화하는 것입니다.

• 보호된 Azure Stack Hub VM의 운영 체제 및 데이터 볼륨 복제에 의해 만들어진 VHD 파일이 포함된 Blob을 보유하는 Azure Storage 계정. 이러한 VHD 파일은 장애 조치(failover) 후 자동으로 프로비전되는 Azure VM의 관리 디스크에 대한 원본 역할을 합니다.

• 재해 복구 환경을 호스팅하는 Azure Virtual Network. 부하 분산 장치 및 네트워크 보안 그룹과 같은 구성 요소를 포함하여 프로덕션 워크로드를 호스팅하는 Azure Stack Hub에서 가상 네트워크 환경을 미러링하는 방식으로 구성됩니다. 이 가상 네트워크는 일반적으로 워크로드 수준 복구를 용이하게 하기 위해 ExpressRoute 연결을 통해 Azure Stack Hub 가상 네트워크에 연결됩니다.

  참고

  경우에 따라 RPO(복구 지점 목표) 요구 사항이 덜 엄격한 시나리오에서는 사이트 간 VPN 연결로 충분합니다.

• 부하 분산 장치 및 네트워크 보안 그룹과 같은 구성 요소를 포함하여 프로덕션 워크로드를 호스팅하는 Azure Stack Hub의 가상 네트워크 환경을 미러링하는 방식으로 구성된 테스트 장애 조치(failover)를 위한 격리된 Azure Virtual Network.

제안된 솔루션의 온-프레미스 구성 요소에는 다음 서비스가 포함됩니다.

• 연결된 배포 모델의 Azure Stack Hub 통합 시스템. 시스템은 현재 업데이트(2002년 9월 20일 기준)를 실행하며 고객의 온-프레미스 데이터 센터에 있습니다.

• 이 솔루션에 대한 모든 온-프레미스 VM을 호스트하는 Azure Stack Hub 구독 및 가상 네트워크 또는 여러 피어링된 가상 네트워크.

• Windows Server 2016 또는 2012 R2 Azure Hub Stack VM에서 실행되는 Azure Site Recovery 구성 및 프로세스 서버. 서버는 Azure Recovery Services 자격 증명 모음과의 통신 및 복제 트래픽의 라우팅, 최적화 및 암호화를 관리합니다.

  참고

  기본적으로 구성 서버는 단일 프로세스 서버를 호스팅합니다. 더 많은 양의 복제 트래픽을 수용하기 위해 전용 프로세스 서버를 배포할 수 있습니다.

• 보호할 Azure Stack Hub VM. 지원되는 버전의 Windows Server, CentOS 및 Ubuntu 운영 체제를 실행합니다.

• 보호된 VM에서 실행되는 Site Recovery 모바일 서비스(모바일 에이전트라고도 함). 로컬 디스크의 변경 내용을 추적하고, 복제 로그의 변경 내용을 로그하고, 프로세스 서버에 로그를 복제합니다. 프로세스 서버는 이를 대상 Azure Storage 계정으로 라우팅합니다. 로그는 지정한 Azure Storage 계정에 저장된 Blob을 사용하여 구현되는 관리 디스크에 대한 복구 지점을 만드는 데 사용됩니다.

구성 요소

• Microsoft Entra ID
• Azure Virtual Network
• Azure Recovery Services
• Azure ExpressRoute
• Azure Blob Storage
• Azure Stack Hub

대안

이 문서에 설명된 권장 솔루션이 Azure Stack Hub VM 기반 워크로드에 대한 재해 복구 기능을 제공하는 유일한 방법은 아닙니다. 고객에게는 다음과 같은 다른 옵션이 있습니다.

• 다른 Azure Stack Hub 스탬프로의 장애 조치(failover). 데이터 센터 또는 사이트 중단으로부터 보호해야 하는 사용자는 다른 Azure Stack Hub 배포를 사용하여 재해 복구 조항을 구현할 수 있습니다. 기본 위치와 보조 위치를 통해 사용자는 두 환경에서 활성/수동 구성으로 애플리케이션을 배포할 수 있습니다. 덜 중요한 워크로드의 경우 보조 위치에서 미사용 용량을 사용하여 백업에서 애플리케이션의 주문형 복원을 수행하는 것이 허용될 수 있습니다. 또한 다른 데이터 센터에서 복구 사이트를 구현할 수 있으며, 그러면 Site Recovery를 사용하여 Azure에서 복구 사이트의 복제본을 프로비전합니다. 장애 조치(failover) 사이트 역할을 하는 Azure와 함께 Site Recovery를 사용하는 것이 실행 가능한 솔루션인지 여부를 결정하는 몇 가지 요인이 있습니다. 이러한 요소에는 정부 규정, 기업 정책 및 대기 시간 요구 사항이 포함됩니다.

  참고

  2020년 7월부터 Site Recovery는 이 시나리오를 지원하지 않으므로 구현 시 파트너 또는 사내 솔루션을 사용해야 합니다.

• 백업 및 복원. 애플리케이션과 데이터 세트를 백업하면 데이터 손상, 우발적인 삭제 또는 국지적인 중단으로 인한 가동 중지 시간으로부터 신속하게 복구할 수 있습니다. Azure Stack Hub VM 기반 애플리케이션의 경우 게스트 내 에이전트를 사용하여 애플리케이션 데이터, 운영 체제 구성 및 볼륨에 저장된 데이터를 보호할 수 있습니다. 게스트 OS 에이전트를 사용하여 VM을 백업하는 작업에는 일반적으로 운영 체제 구성, 파일, 폴더, 볼륨, 애플리케이션 이진 파일 및 애플리케이션 데이터 캡처가 포함됩니다. 에이전트에서 애플리케이션을 복구하려면 VM을 다시 만든 다음 운영 체제 및 게스트 에이전트를 설치해야 합니다. 이 시점에서 게스트 OS로 데이터를 복원할 수 있습니다.

• 디스크 스냅샷 백업. 스냅샷을 사용하여 Azure Stack Hub VM 구성 및 중지된 VM에 연결된 디스크를 캡처할 수 있습니다. 이 프로세스에는 VM 구성을 캡처하고 디스크 스냅샷을 만들기 위해 Azure Stack Hub API와 통합되는 백업 제품이 필요합니다.

  참고

  2020년 7월부터 실행 중인 VM에 대한 디스크 스냅샷 사용은 지원되지 않습니다. 실행 중인 VM에 연결된 디스크의 스냅샷을 만들면 성능이 저하되거나 VM에 있는 운영 체제 또는 애플리케이션의 가용성에 영향을 미칠 수 있습니다.

• 동일한 데이터 센터에서 외부 백업 솔루션을 사용하여 VM을 백업 및 복원한 다음 백업을 다른 위치에 복제합니다. 이러한 방식으로 Azure Stack Hub VM을 동일한 Azure Stack Hub 인스턴스나 다른 인스턴스 또는 Azure로 복원할 수 있습니다.

시나리오 정보

Azure Stack Hub에는 구성 요소의 지역화된 오류와 관련된 다양한 시나리오에서 자동 치료를 제공하는 자체 복구 기능이 포함되어 있습니다. 그러나 서버 랙 또는 사이트 수준 재해에 영향을 미치는 중단을 비롯한 대규모 장애에는 추가 고려 사항이 필요합니다. 이러한 고려 사항은 VM 기반 사용자 워크로드에 대한 비즈니스 연속성 및 재해 복구 전략의 일부여야 합니다. 이 전략은 워크로드 복구와 별개인 Azure Stack 인프라의 복구도 고려해야 합니다.

기존 온-프레미스 워크로드 복구 솔루션은 구성하기 복잡하고 유지 관리에 비용과 노동 집약적이며 특히 다른 온-프레미스 위치를 장애 조치(failover) 사이트로 사용하는 경우 자동화하기 어렵습니다. Microsoft는 비용 효율적인 재해 복구 전략을 구현, 보안 및 관리하기 위한 탄력적이고 성능 기반의 고도로 자동화되고 간단한 방법을 제공하기 위해 클라우드 및 온-프레미스 구성 요소의 조합에 의존하는 대체 솔루션을 권장합니다. 이 솔루션의 핵심 요소는 Azure에 있는 장애 조치(failover) 사이트를 사용하는 Site Recovery입니다.

잠재적인 사용 사례

장애 조치(failover) 사이트로 Azure를 사용하는 Site Recovery는 앞서 언급한 모든 단점을 제거합니다. 해당 기능을 사용하여 Microsoft Hyper-V 또는 VMware ESXi 가상화 플랫폼에서 실행되는 서버를 포함하여 실제 서버와 가상 서버를 모두 보호할 수 있습니다. 동일한 기능을 사용하여 Azure Stack Hub VM에서 실행되는 워크로드의 복구를 용이하게 할 수도 있습니다.

핵심 기능

Site Recovery는 두 가지 기능 집합을 제공하여 실제 및 가상 컴퓨터의 보호를 용이하게 하는 재해 복구 솔루션입니다.

• 프로덕션 및 재해 복구 위치 사이에 있는 컴퓨터 디스크에 대한 변경 내용 복제
• 이 두 위치 간의 장애 조치(failover) 및 장애 복구 오케스트레이션

Site Recovery는 세 가지 형식의 장애 조치(failover)를 제공합니다.

• 장애 조치(failover)를 테스트합니다. 이 장애 조치(failover)를 통해 데이터 손실이나 프로덕션 환경에 대한 영향 없이 격리된 환경에서 Site Recovery 구성의 유효성을 검사할 수 있습니다.
• 계획된 장애 조치입니다. 이 장애 조치(failover)는 일반적으로 계획된 가동 중지 시간의 일부로 데이터 손실 없이 재해 복구를 시작할 수 있는 옵션을 제공합니다.
• 계획되지 않은 장애 조치입니다. 이 장애 조치(failover)는 주 사이트의 가용성에 영향을 미치고 잠재적으로 데이터 손실을 초래할 수 있는 계획되지 않은 중단이 발생한 경우 최후의 수단으로 사용됩니다.

Site Recovery는 두 온-프레미스 사이트 간의 장애 조치(failover) 및 장애 복구, 두 Azure 지역 간의 장애 조치(failover) 및 장애 복구, 타사 공급자 클라우드에서 마이그레이션과 같은 여러 시나리오를 지원합니다. 그러나 이 문서의 컨텍스트에서 초점은 Azure Stack Hub VM의 로컬 디스크를 Azure Storage로 복제하고 Azure Stack Hub 스택과 Azure 지역 간의 VM 장애 조치(failover) 및 장애 복구에 있습니다.

Site Recovery 아키텍처 및 해당 구성 요소에 대한 세부 정보는 다음을 비롯한 다양한 조건에 따라 달라집니다.

• 보호할 컴퓨터 형식(실제 대 가상).
• 가상화 환경의 경우 보호할 가상 머신을 호스팅하는 하이퍼바이저 형식입니다(Hyper-V와 VMware ESXi).
• Hyper-V 환경의 경우 Hyper-V 호스트 관리를 위해 SCVMM(System Center Virtual Machine Manager)을 사용합니다.

Azure Stack Hub를 사용하면 아키텍처가 실제 컴퓨터에 적용할 수 있는 아키텍처와 일치합니다. 두 경우 모두 Site Recovery가 하이퍼바이저에 직접 액세스할 수 없기 때문에 이는 특별히 놀라운 일이 아닙니다. 대신 로컬 디스크에 대한 변경 내용을 추적하고 복제하는 메커니즘이 보호된 운영 체제 내에서 구현됩니다.

이를 위해 Site Recovery는 Site Recovery 모바일 서비스(모바일 에이전트라고도 함)를 사용합니다. 이 서비스는 Site Recovery 기반 보호 범위에 VM을 등록할 때 개별 VM에 자동으로 배포됩니다. 보호된 각 VM에서 로컬로 설치된 모바일 에이전트 인스턴스는 운영 체제 및 데이터 디스크의 변경 내용을 지속적으로 모니터링하고 프로세스 서버로 전달합니다. 그러나 보호된 VM에서 발생하는 복제 트래픽의 흐름을 최적화하고 관리하기 위해 Site Recovery는 구성 서버라고 하는 별도의 VM에서 실행되는 추가 구성 요소 집합을 구현합니다.

구성 서버는 Site Recovery 자격 증명 모음과의 통신을 조정하고 데이터 복제를 관리합니다. 또한 구성 서버는 게이트웨이 역할을 하는 프로세스 서버라는 구성 요소를 호스팅하고, 복제 데이터를 수신하고, 캐싱 및 압축을 통해 최적화하고, 암호화하고, 마지막으로 Azure Storage로 전달합니다. 실제로 구성 서버는 Site Recovery와 Azure Stack Hub에서 실행되는 보호된 VM 간의 통합 지점으로 작동합니다. 구성 서버를 배포하고 Azure Recovery Services 자격 증명 모음에 등록하여 해당 통합을 구현합니다.

Site Recovery 구성의 일부로 프로덕션 환경을 미러링하는 방식으로 가상 네트워크, 부하 분산 장치 또는 네트워크 보안 그룹과 같은 인프라 구성 요소를 포함하여 원하는 재해 복구 환경을 정의합니다. 구성에는 복구 기능을 결정하고 다음 매개 변수로 구성되는 복제 정책도 포함됩니다.

• RPO 임계값: 이 설정은 구현하려는 원하는 복구 지점 목표를 나타내며 Site Recovery가 크래시 일치 복구 지점 스냅샷을 생성하는 빈도를 결정합니다. 복제가 연속적이기 때문에 해당 값은 복제 빈도에 영향을 주지 않습니다. Site Recovery는 경고를 생성하고 선택적으로 Site Recovery에서 제공하는 현재 유효 RPO가 지정한 임계값을 초과하는 경우 이메일 경고를 생성합니다. Site Recovery는 5분마다 크래시 일치 복구 지점 스냅샷을 생성합니다.

  참고

  크래시 일관성 스냅샷은 스냅샷을 만들 때 디스크에 있는 데이터를 캡처합니다. 메모리 콘텐츠는 포함하지 않습니다. 사실상 크래시 일치 스냅샷은 운영 체제 또는 로컬에 설치된 앱의 데이터 일관성을 보장하지 않습니다.

• 복구 지점 보존: 이 설정은 각 복구 지점 스냅샷에 대한 보존 기간(시간)을 나타냅니다. 보호된 VM은 보존 기간 내의 모든 복구 지점으로 복구할 수 있습니다. Site Recovery는 프리미엄 성능 계층을 사용하여 Azure Storage 계정에 복제된 VM에 대해 최대 24시간의 보존을 지원합니다. 표준 성능 계층과 함께 Azure Storage 계정을 사용하는 경우 72시간 보존 제한이 있습니다.

• 앱 일치 스냅샷 빈도. 이 설정은 Site Recovery가 애플리케이션 일치 스냅샷을 생성하는 빈도(시간)를 결정합니다. 앱 일치 스냅샷은 보호된 VM에서 실행 중인 애플리케이션의 특정 시점 스냅샷을 나타냅니다. 앱 일치 스냅샷은 12개로 제한됩니다. Windows Server를 실행하는 VM의 경우 Site Recovery는 VSS(볼륨 섀도 복사본 서비스)를 사용합니다. Site Recovery는 Linux용 앱 일치 스냅샷도 지원하지만 사용자 지정 스크립트를 구현해야 합니다. 스크립트는 앱 일치 스냅샷을 적용할 때 모바일 에이전트에서 사용됩니다.

  참고

  Linux를 실행하는 Azure Stack Hub VM에서 앱 일치 스냅샷 구현에 대한 자세한 내용은 Site Recovery에 대한 일반적인 질문을 참조하세요.

지정하는 보호된 Azure Stack Hub VM의 각 디스크에 대해 데이터는 Azure Storage의 해당 관리 디스크에 복제됩니다. 디스크는 원본 디스크의 복사본과 모든 복구 지점 크래시 일치 및 앱 일치 스냅샷을 저장합니다. 장애 조치(failover)의 일부로 보호된 Azure Stack Hub VM의 복제본 역할을 하는 Azure VM에 관리 디스크를 연결할 때 사용해야 하는 복구 지점 크래시 일치 또는 앱 일치 스냅샷을 선택합니다.

일반 비즈니스 운영 중에 보호된 워크로드는 Azure Stack Hub VM에서 실행되며 디스크 변경 내용은 모바일 에이전트, 프로세스 서버 및 구성 서버 간의 상호 작용을 통해 지정된 Azure Storage 계정에 지속적으로 복제됩니다. 테스트, 계획된 장애 조치(failover) 또는 계획되지 않은 장애 조치(failover)를 시작할 때 Site Recovery는 해당 Azure Stack Hub VM의 디스크 복제본을 사용하여 Azure VM을 자동으로 프로비전합니다.

수동 및 자동 단계를 포함하는 복구 계획을 만들어 장애 조치(failover)를 조정하는 옵션이 있습니다. 후자를 구현하려면 사용자 지정 PowerShell 스크립트, PowerShell 워크플로 또는 Python 2 스크립트로 구성된 Azure Automation runbook을 사용할 수 있습니다.

주 사이트를 다시 사용할 수 있게 되면 Site Recovery는 복제 방향 반전을 지원하므로 가동 중지 시간을 최소화하고 데이터 손실 없이 장애 복구를 수행할 수 있습니다. 그러나 Azure Stack Hub에서는 이 방식을 사용할 수 없습니다. 대신 장애 복구하려면 Azure VM 디스크 파일을 다운로드하여 Azure Stack Hub에 업로드하고 기존 또는 새 VM에 연결해야 합니다.

고려 사항

이러한 고려 사항은 워크로드의 품질을 향상시키는 데 사용할 수 있는 일단의 지침 원칙인 Azure Well-Architected Framework의 핵심 요소를 구현합니다. 자세한 내용은 Microsoft Azure Well-Architected Framework를 참조하세요.

안정성

안정성은 애플리케이션이 고객에 대한 약정을 충족할 수 있도록 보장합니다. 자세한 내용은 안정성 핵심 요소 개요를 참조하세요.

Azure Stack Hub는 인프라 고유의 복원력을 통해 워크로드 가용성을 높이는 데 도움이 됩니다. 이 복원력은 Site Recovery로 보호되는 Azure Stack Hub VM과 구성 및 프로세스 서버를 포함하여 온-프레미스 Site Recovery 인프라의 필수 구성 요소에 고가용성을 제공합니다.

마찬가지로 Site Recovery 인프라의 클라우드 기반 구성 요소의 복원력을 사용할 수 있는 옵션이 있습니다. 기본적으로 Azure Recovery Services는 지역 중복입니다. 즉, 해당 구성이 미리 정의된 지역 쌍의 일부인 Azure 지역에 자동으로 복제됩니다. 복원력 요구 사항에 충분한 경우 복제 설정을 로컬 중복으로 변경할 수 있는 옵션이 있습니다. 자격 증명 모음에 보호된 항목이 포함되어 있으면 이 옵션을 변경할 수 없습니다. 언제든지 변경할 수 있지만 표준 성능 계층이 있는 모든 Azure Storage 계정에 대해 동일한 복원력 옵션을 사용할 수 있습니다.

워크로드 보호 범위를 확장하는 솔루션을 디자인 및 구현하여 이 복원력의 정도를 더욱 향상시킬 수 있습니다. 이것이 Site Recovery가 제공하는 부가 가치입니다. Azure Stack Hub에서 실행되는 Site Recovery의 컨텍스트에서 더 자세히 살펴봐야 하는 워크로드 가용성의 두 가지 주요 측면이 있습니다.

• Azure에 장애 조치
• Azure Stack Hub로 장애 복구

RPO(복구 지점 목표) 및 RTO(복구 시간 목표)에 기반한 재해 복구 전략을 개발할 때 두 가지를 모두 고려해야 합니다. RTO 및 RPO는 조직 내의 개별 비즈니스 함수에서 규정한 연속성 요구 사항을 나타냅니다. RPO는 해당 데이터의 가용성에 영향을 준 인시던트 이후 허용 가능한 최대 데이터 손실을 나타내는 기간을 지정합니다. RTO는 이러한 함수의 가용성에 영향을 준 인시던트 이후 비즈니스 함수를 복원하는 데 걸릴 수 있는 최대 허용 기간을 지정합니다.

Azure에 장애 조치

Azure로의 장애 조치(failover)는 Azure Stack Hub VM의 Site Recovery 기반 보호와 관련하여 가용성 고려 사항의 핵심입니다. 워크로드 가용성을 최대화하기 위해 장애 조치(failover) 전략은 잠재적인 데이터 손실(RPO)을 최소화하고 장애 조치(failover) 시간(RTO)을 최소화해야 할 필요성을 모두 해결해야 합니다.

잠재적인 데이터 손실을 최소화하려면 다음을 고려할 수 있습니다.

• 확장성 및 성능 고려 사항에 따라 복제 트래픽의 처리량을 최대화하고 대기 시간을 최소화합니다. 자세한 내용은 이 문서의 다음 섹션을 참조하세요.
• 데이터베이스 워크로드에 대한 앱 일치 복구 지점의 빈도를 높입니다(시간당 최대 하나의 복구 지점). 앱 일치 복구 지점은 앱 일치 스냅샷에서 생성됩니다. 앱 일치 스냅샷은 디스크와 메모리에서 앱 데이터를 캡처합니다. 이 방식은 잠재적인 데이터 손실을 최소화하지만 한 가지 큰 단점이 있습니다. 앱 일치 스냅샷은 Windows에서 볼륨 섀도 복사본 서비스를 사용하거나 Linux에서 사용자 지정 스크립트를 사용하여 로컬에 설치된 앱을 중지해야 합니다. 캡처 프로세스는 특히 리소스 사용률이 높은 경우 성능을 저하시킬 수 있습니다. 비데이터베이스 워크로드에 대한 앱 일치 스냅샷에는 낮은 빈도를 사용하지 않는 것이 좋습니다.

장애 조치(failover) 시간을 최소화하는 기본 방법은 Site Recovery 복구 계획을 사용하는 것입니다. 복구 계획은 기본 사이트와 보조 사이트 간의 장애 조치(failover)를 오케스트레이션하여 보호된 서버가 장애 조치(failover)되는 시퀀스를 정의합니다. 수동 지침 및 자동화된 작업을 추가하여 계획을 사용자 지정할 수 있습니다. 그 목적은 프로세스를 일관되고 정확하며 반복 가능하고 자동화하는 것입니다.

복구 계획을 만들 때 장애 조치(failover)를 위해 복구 그룹에 보호된 서버를 할당합니다. 각 그룹의 서버는 함께 장애 조치(failover)됩니다. 이렇게 하면 장애 조치(failover) 프로세스를 외부 종속성에 의존하지 않고 장애 조치(failover)할 수 있는 서버 집합을 나타내는 더 작고 관리하기 쉬운 단위로 나눌 수 있습니다.

장애 조치(failover) 시간을 최소화하려면 복구 계획 만들기의 일부로 다음을 수행해야 합니다.

• 함께 장애 조치(failover)해야 하는 Azure Stack Hub VM 그룹을 정의합니다.
• 장애 조치(failover)의 최적 시퀀스를 결정하기 위해 Azure Stack Hub VM 그룹 간의 종속성을 정의합니다.
• 가능한 경우 장애 조치(failover) 작업을 자동화합니다.
• 필요한 경우 사용자 지정 직접 작업을 포함합니다.

복구 계획을 정의하고 복구 그룹을 만들어 앱별 속성을 캡처합니다. 예를 들어, SQL Server 기반 백 엔드, 미들웨어 구성 요소 및 웹 프런트 엔드가 있는 기존의 3계층 앱을 고려해 보겠습니다. 복구 계획을 만들 때 각 계층에서 서버의 시작 순서를 제어할 수 있습니다. SQL Server 인스턴스를 실행하는 서버가 먼저 온라인 상태가 된 다음 미들웨어 계층의 서버가 온라인 상태가 되고 그다음에는 웹 프런트 엔드를 호스팅하는 서버가 조인됩니다. 이 시퀀스는 마지막 서버가 시작될 때까지 앱이 작동하도록 합니다. 이를 구현하려면 각 계층의 서버를 포함하는 3개의 복구 그룹으로 복구 계획을 만들기만 하면 됩니다.

장애 조치(failover) 및 시작 순서를 제어하는 것 외에도 복구 계획에 작업을 추가하는 옵션도 있습니다. 일반적으로 두 가지 형식의 작업이 있습니다.

• 자동화. 이 작업은 다음 두 가지 작업 유형 중 하나를 포함하는 Azure Automation Runbook을 기반으로 합니다.
  • 예를 들어, 공용 IP 주소를 만들고 이를 Azure VM에 연결된 네트워크 인터페이스와 연결하는 것을 포함하여 Azure 리소스 프로비전 및 구성.
  • 장애 조치(failover) 후 프로비전된 Azure VM 내에서 실행되는 운영 체제 및 애플리케이션의 구성을 수정합니다.
• 수동. 이 작업은 자동화를 지원하지 않으며 주로 문서화 목적으로 복구 계획에 포함됩니다.

Azure Stack Hub로 장애 복구

Site Recovery 기반 시나리오에서 장애 복구(failback)는 제대로 구현된 경우 데이터 손실을 수반하지 않습니다. 즉, 장애 조치(failover) 전략의 초점은 장애 복구 시간(RTO)을 최소화하는 것입니다. 그러나 앞에서 언급한 것처럼 Azure Stack Hub로 장애 복구할 때 복구 계획에 의존할 수 없습니다. 대신 장애 복구에는 다음과 같은 일련의 단계가 포함됩니다.

1. 재해 복구 환경에서 Azure VM을 중지하고 할당을 취소합니다.
2. 다운로드하려는 VM에 연결된 각 관리 디스크의 URI 매개 변수를 식별합니다.
3. 이전 단계에서 식별한 URI 매개 변수로 식별된 VHD(가상 하드 디스크) 파일을 온-프레미스 환경에 다운로드합니다.
4. VHD 파일을 Azure Stack Hub에 업로드합니다.
5. 업로드된 VHD를 신규 또는 기존 Azure Stack Hub VM에 연결합니다.
6. Azure Stack Hub VM을 시작합니다.

장애 복구 시간을 최소화하는 최적의 방식은 자동화하는 것입니다.

워크로드별 고려 사항

Site Recovery는 SharePoint, Exchange, SQL Server 및 AD DS(Active Directory Domain Services)를 비롯한 Windows Server 기반 앱 및 역할과 통합됩니다. 이를 통해 다음 기능을 사용하여 앱 수준 보호 및 복구를 구현할 수 있습니다.

• SQL Server AlwaysOn 가용성 그룹, Exchange DAG(데이터베이스 가용성 그룹) 및 AD DS 복제와 같은 앱 수준 복제 기술과의 통합
• 단일 또는 다중 계층 애플리케이션을 위한 앱 일치 스냅샷
• 다운로드하여 복구 계획과 통합할 수 있는 프로덕션 준비가 완료된 애플리케이션별 스크립트를 제공하는 풍부한 자동화 라이브러리

또는 워크로드별 복제 메커니즘을 사용하여 사이트 수준 복원력을 제공하는 옵션이 있습니다. 이는 모두 기본적으로 복제를 지원하는 AD DS 도메인 컨트롤러, SQL Server 또는 Exchange에 대한 재해 복구를 구현할 때 일반적으로 사용되는 옵션입니다. 이렇게 하려면 재해 복구 환경에서 이러한 워크로드를 호스팅하는 Azure VM을 프로비전해야 하므로 비용이 증가하지만 다음과 같은 이점을 제공합니다.

• 페일오버 및 장애 복구에 필요한 시간 단축
• 워크로드 수준 장애 조치(failover)를 단순화하여 사이트 수준 장애 조치(failover)가 필요하지 않은 시나리오를 수용합니다.

보안

하이브리드 시나리오에서 사용자 VM 기반 워크로드의 재해 복구를 관리하려면 추가 보안 고려 사항이 필요합니다. 이러한 고려 사항은 다음 범주로 그룹화할 수 있습니다.

• 전송 중 암호화 여기에는 보호된 Azure Stack Hub VM, 온-프레미스 Site Recovery 구성 요소 및 클라우드 기반 Site Recovery 구성 요소 간의 통신이 포함됩니다.

  • 보호된 VM에 설치된 모바일 Agent는 항상 TLS(전송 계층 보안) 1.2를 통해 프로세스 서버와 통신합니다.
  • TLS 1.1 또는 1.0을 사용하기 위해 구성 서버에서 Azure로, 프로세스 서버에서 Azure로의 통신이 가능합니다. 하이브리드 연결의 보안 수준을 높이려면 TLS 1.2 사용을 적용하는 것을 고려해야 합니다.

  참고

  TLS 1.2 기반 암호화 구성에 대한 자세한 내용은 TLS(전송 계층 보안) 레지스트리 설정 및 Windows의 WinHTTP에서 TLS 1.1 및 TLS 1.2를 기본 보안 프로토콜로 사용하도록 업데이트를 참조하세요.

• 미사용 암호화 여기에는 재해 복구 사이트의 Azure Storage 및 Azure VM이 포함됩니다.

  • Azure Storage는 256비트 고급 암호화 표준 암호화를 사용하여 모든 스토리지 계정에 대해 유휴 상태에서 암호화되며 Federal Information Processing Standard 140-2를 준수합니다. 암호화는 자동으로 사용하도록 설정되며 사용하지 않도록 설정할 수 없습니다. 기본적으로 암호화는 Microsoft 관리형 키를 사용하지만 고객은 Azure Key Vault에 저장된 자체 키를 사용할 수 있습니다.
  • Azure VM의 관리 디스크는 플랫폼 관리 암호화 키를 사용하여 해당 스냅샷에도 적용되는 Azure 관리 디스크의 서버 쪽 암호화를 사용하여 자동으로 암호화됩니다.

또한 Site Recovery 복제 디스크의 콘텐츠를 호스팅하는 Azure Storage 계정에 대한 제한된 액세스를 적용할 수 있습니다. 이렇게 하려면 Recovery Services 자격 증명 모음에 대해 관리 ID를 사용하도록 설정하고 Azure Storage 계정 수준에서 다음 Azure RBAC(Azure 역할 기반 액세스 제어) 역할을 해당 관리 ID에 할당합니다.

• Resource Manager 기반 스토리지 계정(표준 성능 계층):
  • 참가자
  • Storage Blob 데이터 Contributor
• Resource Manager 기반 스토리지 계정(프리미엄 성능 계층):
  • 참가자
  • Storage Blob 데이터 소유자

Azure Recovery Services 자격 증명 모음은 다음 보호를 포함하여 해당 콘텐츠를 추가로 보호하는 메커니즘을 제공합니다.

• Azure RBAC. 이를 통해 최소 권한 원칙에 따라 책임을 위임하고 분리할 수 있습니다. Site Recovery 작업에 대한 액세스를 제한하는 세 가지 Site Recovery 관련 기본 제공 역할이 있습니다.
  • Site Recovery 기여자. 이 역할에는 Azure Recovery Services 자격 증명 모음에서 Site Recovery 작업을 관리하는 데 필요한 모든 권한이 있습니다. 그러나 이 역할을 가진 사용자는 자격 증명 모음을 만들거나 삭제할 수 없으며 다른 사용자에게 액세스 권한을 할당할 수 없습니다. 이 역할은 Azure Stack Hub 테넌트에 대한 재해 복구를 사용하도록 설정하고 관리할 수 있는 재해 복구 관리자에게 가장 적합합니다.
  • Site Recovery 운영자. 이 역할에는 장애 조치(failover) 및 장애 복구 작업을 실행하고 관리할 수 있는 권한이 있습니다. 이 역할의 사용자는 복제를 활성화하거나 비활성화할 수 없고, 자격 증명 모음을 만들거나 삭제할 수 없으며, 새로운 인프라를 등록하거나 다른 사용자에게 액세스 권한을 할당할 수 없습니다. 이 역할은 실제 또는 시뮬레이션된 재해 시나리오에서 애플리케이션 소유자 및 IT 관리자의 지시에 따라 Azure Stack Hub VM을 장애 조치(failover)할 수 있는 재해 복구 운영자에게 가장 적합합니다.
  • Site Recovery 읽기 권한자. 이 역할에는 모든 Site Recovery 관리 작업을 추적할 수 있는 권한이 있습니다. 이 역할은 보호된 Azure Stack Hub VM의 상태를 모니터링하고 필요한 경우 지원 티켓을 제기하는 IT 담당자에게 가장 적합합니다.
• Azure 리소스 잠금. Site Recovery 자격 증명 모음에 대한 읽기 전용 및 삭제 잠금을 만들고 할당하여 자격 증명 모음이 실수로 악의적으로 변경되거나 삭제되는 위험을 완화할 수 있는 옵션이 있습니다.
• 일시 삭제. 일시 삭제의 목적은 자격 증명 모음과 해당 데이터를 우발적이거나 악의적인 삭제로부터 보호하는 것입니다. 일시 삭제를 사용하면 삭제된 모든 콘텐츠가 추가로 14일 동안 보존되어 해당 기간 동안 검색할 수 있습니다. 자격 증명 모음 콘텐츠의 추가 14일 보존에는 비용이 발생하지 않습니다. 일시 삭제는 기본적으로 사용하도록 설정되어 있습니다.
• 보안에 중요한 작업 보호. Azure Recovery Services 자격 증명 모음을 사용하면 보호 사용 안 함과 같은 보안에 중요한 작업을 시도할 때마다 추가 인증 계층을 사용하도록 설정할 수 있습니다. 이 추가 유효성 검사는 권한 있는 사용자가 이러한 작업을 수행하는지 유효성을 검사하는 데 도움이 됩니다.
• 의심스러운 작업을 모니터링하고 경고합니다. Azure Recovery Services는 자격 증명 모음 작업과 관련된 보안에 중요한 이벤트에 대한 기본 제공 모니터링 및 경고를 제공합니다.

비용 최적화

비용 최적화는 불필요한 비용을 줄이고 운영 효율성을 높이는 방법을 찾는 것입니다. 자세한 내용은 비용 최적화 핵심 요소 개요를 참조하세요.

이 문서에 설명된 Site Recovery 기반 재해 복구 솔루션의 비용을 고려할 때 온-프레미스 및 클라우드 기반 구성 요소를 모두 고려해야 합니다. Azure Stack Hub 가격 책정 모델은 온-프레미스 구성 요소의 가격 책정을 결정합니다. Azure와 마찬가지로 Azure Stack Hub는 기업계약 및 클라우드 솔루션 공급자 프로그램을 통해 사용 가능한 종량제 계약을 제공합니다. 이 계약에는 각 Windows Server VM에 대한 월별 가격이 포함됩니다. 기존 Windows Server 라이선스를 사용할 수 있는 옵션이 있는 경우 기본 VM 가격 책정에 대한 비용을 크게 줄일 수 있습니다. 그러나 Site Recovery를 사용하면 일반적으로 테넌트별 구성 서버를 구현하는 데 필요한 테넌트당 하나의 Azure Stack Hub VM만 필요합니다.

Azure 관련 요금은 다음 리소스 사용과 관련이 있습니다.

• Azure Recovery Services. 가격 책정은 보호되는 인스턴스 수에 따라 결정됩니다. 모든 보호된 인스턴스는 처음 31일 동안 Site Recovery 요금이 발생하지 않는다는 점에 주목할 가치가 있습니다.

• Azure Storage. 가격 책정은 다음 요소의 조합을 반영합니다.

  • 성능 계층
  • 저장된 데이터의 양
  • 아웃바운드 데이터 전송량
  • 수행된 작업의 수량 및 형식(표준 성능 계층에만 해당)
  • 데이터 중복성(표준 성능 계층만 해당)

• Azure ExpressRoute. 가격 책정은 다음 두 모델 중 하나를 기반으로 합니다.

  • 무제한 데이터입니다. 이 모델에는 모든 인바운드 및 아웃바운드 데이터 전송이 포함된 월별 요금이 포함됩니다.
  • 데이터 요금입니다. 이 모델에는 모든 인바운드 데이터 전송이 무료이고 아웃바운드 데이터 전송이 GB당 청구되는 월별 요금이 포함됩니다.

  참고

  이 평가에는 타사 연결 공급자가 제공하는 실제 연결 비용이 포함되지 않습니다.

• Azure VM. Azure VM의 가격 책정에는 두 가지 구성 요소의 조합이 반영됩니다.

  • 비용을 계산합니다. VM 크기, 가동 시간 및 운영 체제의 라이선스 모델에 따라 비용이 결정됩니다.
  • 관리 디스크 비용. 디스크 크기와 성능 계층에 따라 비용이 결정됩니다.

  참고

  하이드레이션은 특히 기존 재해 복구 솔루션과 비교하여 Site Recovery 기반 구현의 컴퓨팅 비용을 상당히 줄이는 Azure Stack Hub에서 실행되는 워크로드와 함께 일반 비즈니스 운영 중에 Azure VM을 실행할 필요가 없다는 점에 주목할 가치가 있습니다.

  참고

  리소스 가격은 Azure 지역마다 다릅니다.

  참고

  가격 책정에 대한 자세한 내용은 Azure 가격 책정을 참조하세요.

운영 우수성

운영 우수성은 애플리케이션을 배포하고 프로덕션에서 계속 실행하는 운영 프로세스를 다룹니다. 자세한 내용은 운영 우수성 핵심 요소 개요를 참조하세요.

Azure Stack Hub VM의 Site Recovery 기반 재해 복구 관리 용이성과 관련된 주요 고려 사항은 다음과 같습니다.

• Azure Stack Hub에서 Site Recovery 구현
• 장애 조치(failover) 및 장애 복구 프로시저
• 역할 및 책임 위임
• DevOps

Azure Stack Hub에서 Site Recovery 구현

중소 규모 단일 테넌트 환경의 Azure Stack Hub에서 Site Recovery를 구현하려면 Azure Portal에서 Recovery Services Vault의 그래픽 인터페이스로 구동되는 수동 프로비전 프로세스를 따를 수 있습니다. 다중 테넌트 구현의 경우 일반적으로 각 테넌트에 대해 별도의 구성 서버 VM과 별도의 Recovery Services 자격 증명 모음을 설정해야 하므로 구현 프로세스의 일부를 자동화하는 것이 좋습니다. 또한 모바일 에이전트 강제 설치를 위한 원본 컴퓨터 준비에 설명된 프로시저에 따라 모바일 에이전트 배포를 자동화하는 옵션도 있습니다.

장애 조치(failover) 및 장애 복구 프로시저

장애 조치(failover) 관리를 단순화하려면 보호된 모든 워크로드에 대한 복구 계획을 구현하는 것이 좋습니다. 자세한 내용은 이 문서 앞부분의 안정성 섹션을 참조하세요. 장애 복구 프로시저의 관리를 최적화하기 위한 권장 사항도 찾을 수 있습니다.

역할 및 책임 위임

Site Recovery를 사용하여 Azure Stack Hub VM 기반 워크로드의 재해 복구 계획 및 구현에는 일반적으로 관련자의 상호 작용이 포함됩니다.

• Azure Stack Hub 운영자는 Azure Stack Hub 인프라를 관리하여 포괄적인 재해 복구 솔루션을 구현하고 테넌트가 이러한 리소스를 사용할 수 있도록 하는 데 필요한 컴퓨팅, 스토리지 및 네트워크 리소스가 충분한지 확인합니다. 또한 애플리케이션 및 데이터 소유자와 협력하여 워크로드를 Azure Stack Hub에 배포하는 최적의 방식을 결정하는 데 도움을 줍니다.
• Azure 관리자는 하이브리드 재해 복구 솔루션을 구현하는 데 필요한 Azure 리소스를 관리합니다.
• Microsoft Entra 관리자는 Azure 리소스를 프로비전, 구성 및 관리하는 데 사용되는 사용자 및 그룹 개체를 포함하여 Microsoft Entra 리소스를 관리합니다.
• Azure Stack Hub 테넌트 IT 담당자는 장애 조치(failover) 및 장애 복구를 포함하여 Site Recovery를 디자인, 구현 및 관리합니다.
• Azure Stack Hub 사용자는 RPO 및 RTO 요구 사항을 제공하고 요청을 제출하여 워크로드에 대한 재해 복구를 구현해야 합니다.

보호 및 복구의 컨텍스트에서 애플리케이션 소유자 및 운영자에게 할당된 역할과 책임을 명확하게 이해해야 합니다. 사용자는 VM을 보호할 책임이 있습니다. 운영자는 Azure Stack Hub 인프라의 운영 상태를 책임집니다.

DevOps

Site Recovery를 사용하여 VM 수준 복구를 구성하는 것은 주로 IT 운영의 책임이지만 포괄적인 재해 복구 전략에 통합해야 하는 몇 가지 DevOps 관련 고려 사항이 있습니다. Azure Stack Hub는 VM 기반 애플리케이션 및 서비스를 비롯한 다양한 워크로드의 자동화된 배포를 통합하는 IaC(코드 제공 인프라) 구현을 용이하게 합니다. 이 기능을 사용하여 여러 테넌트 시나리오에서 초기 설정을 단순화하는 Site Recovery 기반 재해 복구 시나리오의 프로비전을 단순화할 수 있습니다.

예를 들어, 동일한 Azure Resource Manager 템플릿을 사용하여 조정된 단일 작업에서 애플리케이션에 대한 Azure Stack Hub 스탬프의 VM 기반 워크로드를 수용하는 데 필요한 모든 네트워크 리소스를 프로비전할 수 있습니다. Azure에서 일치하는 리소스 집합을 프로비전하도록 동일한 템플릿을 사용하여 재해 복구 사이트를 프로비전할 수 있습니다. 두 환경 간의 차이점을 설명하려면 각 경우에 서로 다른 템플릿 매개 변수 값을 지정하기만 하면 됩니다.

성능 효율성

성능 효율성은 사용자가 배치된 요구 사항을 효율적인 방식으로 충족하기 위해 워크로드의 크기를 조정할 수 있는 기능입니다. 자세한 내용은 성능 효율성 핵심 요소 개요를 참조하세요.

Azure Stack Hub에 Site Recovery를 배포하려는 경우 구성 및 프로세스 서버에 할당된 처리, 스토리지 및 네트워크 리소스의 양을 고려해야 합니다. 처리 또는 스토리지 요구 사항의 변경 내용을 수용하기 위해 배포 후 Site Recovery 구성 요소를 호스팅하는 Azure Stack Hub VM의 예상 크기를 조정해야 할 수 있습니다. 크기 조정을 위한 세 가지 기본 옵션이 있습니다.

• 수직 확장을 구현합니다. 여기에는 프로세스 서버를 포함하여 구성 서버를 호스팅하는 Azure Stack Hub VM의 프로세서, 메모리 및 디스크 리소스의 양과 형식을 수정하는 작업이 포함됩니다. 리소스 요구 사항을 예측하려면 다음 표의 정보를 사용할 수 있습니다.

  표 1: 구성 및 프로세스 서버 크기 요구 사항

  CPU	메모리	캐시 디스크	데이터 변경률	보호된 컴퓨터
  8개 vCPU 2개 소켓 * 4코어 @ 2.5GHz	16GB	300GB	500GB 이하	< 머신 100대
  12개 vCPU 2개 소켓 * 6코어 @ 2.5GHz	18GB	600GB	500GB-1TB	컴퓨터 100-150대
  16개 vCPU 2개 소켓 * 8코어 @ 2.5GHz	32GB	1TB	1-2TB	머신 150-200대

• 수평 확장을 구현합니다. 여기에는 보호된 Azure Stack Hub VM의 처리 요구 사항을 일치시키기 위해 설치된 프로세스 서버를 사용하여 Azure Stack Hub VM을 프로비전 또는 프로비전 해제하는 작업이 포함됩니다. 일반적으로 배포를 200개 이상의 원본 컴퓨터로 크기 조정해야 하거나 총 일별 변동률이 2TB(테라바이트)를 초과하는 경우 복제 트래픽을 처리하기 위한 추가 프로세스 서버가 필요합니다. 추가 프로세스 서버의 수와 구성을 예상하려면 프로세스 서버의 크기 권장 사항을 참조하세요.

• 복제 정책을 수정합니다. 여기에는 앱 일치 스냅샷에 중점을 둔 복제 정책의 매개 변수 변경이 포함됩니다.

네트워킹 관점에서 복제 트래픽에 사용할 수 있는 대역폭을 조정하는 방법에는 여러 가지가 있습니다.

• VM 크기를 수정합니다. Azure Stack Hub VM의 크기는 최대 네트워크 대역폭을 결정합니다. 그러나 대역폭 보장이 없다는 점에 유의해야 합니다. 대신 VM은 크기에 따라 결정되는 한도까지 사용 가능한 대역폭의 양을 활용할 수 있습니다.

• 업링크 스위치를 바꿉니다. Azure Stack Hub 시스템은 다양한 하드웨어 스위치를 지원하여 여러 업링크 속도를 선택할 수 있습니다. 각 Azure Stack Hub 클러스터 노드에는 내결함성을 위해 랙 스위치 상단에 대한 두 개의 업링크가 있습니다. 시스템은 업링크 용량의 절반을 중요한 인프라에 할당합니다. 나머지는 Azure Stack Hub 서비스 및 모든 사용자 트래픽에 대한 공유 용량입니다. 더 빠른 속도로 배포된 시스템은 복제 트래픽에 더 많은 대역폭을 사용할 수 있습니다.

  참고

  두 번째 네트워크 어댑터를 서버에 연결하여 네트워크 트래픽을 분리할 수 있지만 Azure Stack Hub VM을 사용하여 인터넷에 대한 모든 VM 트래픽이 동일한 업링크를 공유할 수 있습니다. 두 번째 가상 네트워크 어댑터는 실제 전송 수준에서 트래픽을 분리하지 않습니다.

• Azure에 대한 네트워크 연결의 처리량을 수정합니다. 더 많은 양의 복제 트래픽을 수용하려면 Azure Stack Hub 가상 네트워크와 Azure Storage 간의 연결을 위해 Microsoft 피어링과 함께 Azure ExpressRoute를 사용하는 것이 좋습니다. Azure ExpressRoute는 연결 공급자가 제공하는 프라이빗 연결을 통해 온-프레미스 네트워크를 Microsoft 클라우드로 확장합니다. 50Mbps에서 100기가비트까지의 광범위한 대역폭에 대한 ExpressRoute 회로를 구입할 수 있습니다.

  참고

  Azure Stack Hub 시나리오에서 Azure ExpressRoute 구현에 대한 자세한 내용은 Azure ExpressRoute를 사용하여 Azure에 Azure Stack Hub 연결을 참조하세요.

• 프로세스 서버에서 복제 트래픽의 제한을 수정합니다. Microsoft Azure Recovery Services 에이전트의 그래픽 인터페이스에서 프로세스 서버를 호스팅하는 VM의 복제 트래픽이 사용하는 대역폭의 양을 제어할 수 있습니다. 지원되는 기능에는 초당 512킬로비트에서 1,023Mbps 범위의 대역폭 값으로 작업 및 비작업 시간에 대한 제한 설정이 포함됩니다. 또는 Set-OBMachineSetting PowerShell cmdlet을 사용하여 동일한 구성을 적용할 수 있습니다.

• 프로세스 서버에서 보호된 VM별로 할당된 네트워크 대역폭을 수정합니다. 이렇게 하려면 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Azure Backup\Replication 키 내에서 UploadThreadsPerVM 항목의 값을 수정합니다. 기본적으로 값은 4로 설정되지만 사용 가능한 네트워크 대역폭이 충분하면 값을 32로 늘릴 수 있습니다.

시나리오 배포

필수 구성 요소

권장 솔루션을 구현하려면 다음 필수 조건을 충족해야 합니다.

• 다음을 포함하여 Site Recovery 구성 요소의 모든 클라우드 구성 요소를 프로비전하고 관리할 수 있는 충분한 권한이 있는 Azure 구독에 대한 액세스 권한:

  • Azure Stack Hub 프로덕션 환경의 재해 복구 사이트로 지정된 Azure 지역의 Azure Recovery Services 자격 증명 모음.
  • Azure Stack Hub VM의 복제된 디스크 콘텐츠를 호스팅하는 Azure Storage 계정.
  • 계획되거나 계획되지 않은 장애 조치(failover) 후에 하이드레이션된 Azure VM이 연결될 재해 복구 환경을 나타내는 Azure Virtual Network.
  • 테스트 장애 조치(failover) 후 수화된 Azure VM이 연결될 테스트 환경을 나타내는 격리된 Azure Virtual Network.
  • 온-프레미스 환경, Azure Virtual Network 및 보호된 Azure Stack Hub VM의 디스크에서 복제된 콘텐츠가 있는 VHD 파일의 복사본을 호스팅하는 데 사용되는 Azure Storage 계정 간의 Azure ExpressRoute 기반 연결.

• Azure Stack Hub 사용자 구독. 개별 Site Recovery 구성 서버에서 보호하는 모든 Azure Stack Hub VM은 동일한 Azure Stack Hub 사용자 구독에 속해야 합니다.

• Azure Stack Hub 가상 네트워크. 보호된 모든 VM은 프로세스 서버 구성 요소를 호스팅하는 VM에 직접 연결되어야 합니다(기본적으로 구성 서버 VM임).

• 구성 서버와 프로세스 서버를 호스트할 Azure Stack Hub Windows Server VM. VM은 동일한 구독에 속해야 하며 보호해야 하는 Azure Stack Hub VM과 동일한 가상 네트워크에 연결되어야 합니다. 또한 VM은 다음을 수행해야 합니다.

  • Site Recovery 구성 서버 소프트웨어 및 하드웨어 요구 사항 준수
  • 외부 연결 네트워크 요구 사항 설명서를 충족합니다.

  참고

  구성 및 프로세스 서버에 대한 추가 스토리지 및 성능 고려 사항은 이 아키텍처의 뒷부분에서 자세히 설명합니다.

  • 내부 연결 요구 사항을 충족합니다. 특히 보호하려는 Azure Stack Hub VM은 다음과 통신할 수 있어야 합니다.

    • 복제 관리를 위해 인바운드 TCP 포트 443(HTTPS)을 통한 구성 서버
    • 복제 데이터를 배달하기 위해 TCP 포트 9443을 통한 프로세스 서버.

    참고

    Site Recovery 통합 설치를 실행할 때 구성의 일부로 외부 및 내부 연결 모두에 대해 프로세스 서버에서 사용하는 포트를 변경할 수 있습니다.

• 지원되는 운영 체제를 실행하는 보호할 Azure Stack Hub VM Windows Server 운영 체제를 실행하는 Azure Stack Hub VM을 보호하려면 다음을 수행해야 합니다.

  • 관리 권한이 있는 Windows 계정을 만듭니다. 이러한 VM에서 Site Recovery를 사용하도록 설정할 때 이 계정을 지정할 수 있습니다. 프로세스 서버는 이 계정을 사용하여 Site Recovery 모바일 서비스를 설치합니다. 작업 그룹 환경에서는 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System 키에서 LocalAccountTokenFilterPolicy DWORD 레지스트리 항목의 값을 1로 설정하여 대상 Windows Server 운영 체제에서 원격 사용자 액세스 제어를 사용하지 않도록 설정해야 합니다.
  • Microsoft Defender 방화벽에서 파일 및 프린터 공유 및 Windows Management Instrumentation 규칙을 사용하도록 설정합니다.

• Linux 운영 체제를 실행하는 Azure Stack Hub VM을 보호하려면 다음을 수행해야 합니다.

  • 루트 사용자 계정을 만듭니다. 이러한 VM에서 Site Recovery를 사용하도록 설정할 때 이 계정을 지정할 수 있습니다. 프로세스 서버는 이 계정을 사용하여 Site Recovery 모바일 서비스를 설치합니다.
  • 최신 openssh, openssh-server 및 openssl 패키지를 설치합니다.
  • SSH(Secure Shell) 포트 22를 사용하도록 설정하고 실행합니다.
  • 보안 FTP 하위 시스템 및 암호 인증을 사용하도록 설정합니다.

상위 수준 구현 단계

높은 수준에서 Azure Stack Hub의 Site Recovery 기반 재해 복구 구현은 다음 단계로 구성됩니다.

1. Site Recovery로 보호할 Azure Stack Hub VM을 준비합니다. VM이 이전 섹션에 나열된 Site Recovery 필수 조건을 충족하는지 확인합니다.

2. Azure Recovery Services 자격 증명 모음을 만들고 구성합니다. Azure Recovery Services 자격 증명 모음을 설정하고 복제할 항목을 지정합니다. Site Recovery 구성 요소 및 작업은 자격 증명 모음을 사용하여 구성 및 관리됩니다.

3. 원본 복제 환경을 설정합니다. Site Recovery 통합 설치 이진 파일을 설치하고 자격 증명 모음에 등록하여 Site Recovery 구성 서버 및 프로세스 서버를 프로비전합니다.

   참고

   Site Recovery 통합 설치를 다시 실행하여 Azure Stack Hub VM에서 추가 프로세스 서버를 구현할 수 있습니다.

4. 대상 복제 환경을 설정합니다. 재해 복구 사이트를 호스트할 Azure 지역에서 기존 Azure Storage 계정 및 Azure Virtual Network를 만들거나 선택합니다. 복제하는 동안 보호된 Azure Stack Hub VM의 디스크 콘텐츠가 Azure Storage 계정에 복사됩니다. 장애 조치(failover) 중에 Site Recovery는 보호된 Azure Stack Hub VM의 복제본 역할을 하는 Azure VM을 자동으로 프로비전하고 Azure Virtual Network에 연결합니다.

5. 복제를 활성화합니다. 복제 설정을 구성하고 Azure Stack Hub VM에 대한 복제를 사용하도록 설정합니다. 모바일 서비스는 복제가 사용하도록 설정된 각 Azure Stack Hub VM에 자동으로 설치됩니다. Site Recovery는 정의한 정책 설정에 따라 각 Azure Stack Hub VM의 복제를 시작합니다.

6. 테스트 장애 조치(failover)를 수행합니다. 복제가 설정된 후 테스트 장애 조치(failover)를 수행하여 장애 조치(failover)가 예상대로 작동하는지 확인합니다.

7. 계획되거나 계획되지 않은 장애 조치(failover)를 수행합니다. 성공적인 테스트 장애 조치(failover) 후 Azure에 대한 계획된 또는 계획되지 않은 장애 조치(failover)를 수행할 준비가 된 것입니다. 장애 조치(failover)에 포함할 Azure Stack Hub VM을 지정할 수 있는 옵션이 있습니다.

8. 장애 복구를 수행합니다. 장애 복구할 준비가 되면 실패한 Azure Stack Hub VM에 해당하는 Azure VM을 중지하고 디스크 파일을 온-프레미스 스토리지에 다운로드하고 Azure Stack Hub에 업로드한 다음 기존 VM 또는 새 VM에 연결합니다.

요약

결론적으로 Azure Stack Hub는 다른 가상화 플랫폼과 여러 측면에서 다른 고유한 제품입니다. 따라서 워크로드에 대한 비즈니스 연속성 전략과 관련하여 특별한 고려 사항이 필요합니다. Azure 서비스를 사용하면 이 전략의 디자인 및 구현을 단순화할 수 있습니다. 이 아키텍처 참조 문서에서는 연결된 배포 모델에서 Azure Stack Hub VM 기반 워크로드를 보호하기 위해 Microsoft Site Recovery를 사용하는 방법을 살펴보았습니다. 이 방식을 통해 고객은 Azure Stack Hub의 복원력 및 관리 용이성과 Azure 클라우드의 하이퍼스케일 및 글로벌 현재 상태로부터 이점을 얻을 수 있습니다.

여기에 설명된 재해 복구 솔루션은 Azure Stack Hub의 VM 기반 워크로드에만 집중되어 있다는 점에 유의해야 합니다. 이는 가용성에 영향을 미치는 다른 Azure Stack Hub 워크로드 형식 및 시나리오를 고려해야 하는 전체 비즈니스 연속성 전략의 일부일 뿐입니다.

다음 단계

제품 설명서:

• Site Recovery 정보
• Azure Stack Hub 개요
• Microsoft Entra ID란?
• Azure Blob Storage란?
• Azure ExpressRoute란?
• Azure Virtual Network란?

Microsoft Learn 모듈:

• Azure Stack Hub
• Microsoft Entra ID 구성
• 스토리지 계정 구성
• 가상 네트워크 구성
• Azure ExpressRoute 설계 및 구현
• Azure에서 사이트 복구 솔루션 디자인

관련 리소스

• 하이브리드 아키텍처 디자인
• Azure Stack Hub의 파일 및 애플리케이션 백업
• 하이브리드 연결
• 원격 및 현지 지점 작업자를 위한 재해 복구 기능이 있는 하이브리드 파일 공유