Azure Site Recovery 사용하여 용량 계획
organization 계획되거나 계획되지 않은 중단 시 데이터를 안전하게, 앱 사용 가능 및 워크로드를 온라인으로 유지하는 BCDR(비즈니스 연속성 및 재해 복구) 전략을 채택해야 합니다.
Azure Stack Hub의 Azure Site Recovery 기본 사이트에서 보조 위치로 VM(가상 머신) 워크로드의 복제를 통해 중단 시 조직 데이터, 애플리케이션 가용성 및 워크로드의 안전을 지원할 수 있는 서비스를 제공합니다. 예를 들어 기본 사이트에서 중단이 발생하면 보조 위치로 장애 조치(failover)하여 앱에 액세스합니다. 기본 사이트가 다시 실행되는 즉시 장애 복구(failback)할 수 있습니다. 자세한 내용은 사이트 복구 정보를 참조하세요.
두 Azure Stack Hub 스탬프에서 VM 복제를 사용하도록 설정하려면 다음 두 가지 환경을 구성합니다.
-
원본 환경:
- 테넌트 VM이 실행되는 Azure Stack Hub 스탬프입니다.
-
대상 환경:
- Azure Site Recovery 리소스 공급자가 실행되는 위치입니다.
비즈니스 연속성 및 재해 복구 계획의 성공을 위한 필수 구성 요소는 용량 계획입니다. 용량 계획 중에 고려해야 할 몇 가지 요소가 있습니다.
보호하려는 특정 워크로드에 대한 RTO(복구 시간 목표) 및 RPO(복구 지점 목표)입니다.
워크로드 및 애플리케이션 특성:
- 해당 VM 내에서 데이터가 변경되는 빈도입니다.
- 생성되거나 제거되는 데이터의 양
- 애플리케이션 디자인의 모양 등은 어떻게 합니까?
VM 크기, 디스크 수 및 각 VM이 다른 VM에 연결되는 방식.
- 여러 VM이 필요한 솔루션의 경우 해당 VM을 시작해야 하는 순서를 이해합니다.
원본 환경과 대상 환경 간의 네트워크 대역폭입니다. 이 구성 요소는 RPO에 영향을 줄 수 있습니다.
이러한 각 사항은 중요하며 BCDR 계획을 빌드할 때 광범위한 영향을 미칩니다.
다음 섹션에서는 Azure Site Recovery 관점에서 고려할 기본 사항을 나열합니다. 각 BCDR 계획은 서로 다르며 보호하려는 워크로드의 세부 사항을 기반으로 합니다. 따라서 이 목록은 포괄적이지 않습니다.
원본 고려 사항
원본 환경에서 Azure Stack Hub는 Azure Site Recovery VM 어플라이언스 실행합니다. VM은 Azure Stack Hub 사용자 구독에서 실행되는 Standard_DS4_v2 (8개 vCPU, 28Gb 메모리, 32개의 데이터 디스크) VM입니다.
원본 환경에서 다음 영역을 고려합니다.
Quota:
- Azure Site Recovery VM 어플라이언스 만들기에 충분한 할당량이 있어야 합니다. 전체 계획에 따라 하나 이상의 항목이 필요합니다.
Azure Site Recovery VM 어플라이언스 대한 스토리지:
Azure Site Recovery VM 어플라이언스 자체에는 VM 크기로 정의된 데이터 요구 사항이 있습니다.
용량을 계획할 때 어플라이언스 VM에 장애 복구(failback) 및 다시 보호 메커니즘을 실행하기에 충분한 스토리지가 있는지 확인합니다.
참고
스토리지 제한 사항이 있는 경우 장애 복구(failback) 및 다시 보호(re-protect)가 실패할 수 있으며 오류 내부 오류가 발생했습니다 . 사용자는 어플라이언스 이벤트 로그를 검사 실제 Azure Resource Manager 오류를 확인해야 합니다. 자세한 내용은 Azure Site Recovery 알려진 문제를 참조하세요.
대역폭:
- 초기 복제는 높은 대역폭 사용량을 생성합니다.
- 각 VM의 변경 내용은 복제 정책 및 각 애플리케이션 유형에 따라 복제됩니다.
대상 고려 사항
대상 환경에는 용량 계획에 대해 고려해야 할 두 가지 사항이 있습니다.
Azure Site Recovery 서비스 요구 사항: 워크로드를 반드시 보호하지 않고 Azure Site Recovery 실행하는 데 사용되는 양입니다.
보호된 워크로드 요구 사항입니다.
대상 환경에서는 원본(자격 증명 모음당 어플라이언스 하나)에서 VM을 보호하기 위해 각 Site Recovery 어플라이언스 대해 하나의 Azure Site Recovery 자격 증명 모음을 만들어야 합니다. 용량 관점에서 제한되는 것은 아니지만 전체 환경의 디자인을 계획할 때 고려해야 합니다.
Azure Site Recovery RP 리소스
Azure Stack Hub에 Azure Site Recovery 설치하려면 Site Recovery 리소스 공급자(RP)를 설치해야 합니다.
참고
Microsoft.SiteRecovery-1.2301.2216.2287에서는 Azure Stack Hub의 Azure Site Recovery Event Hubs를 종속성으로 요구하지 않습니다.
이 서비스는 Azure Stack Hub 관리자 구독에서 만들어지고 Azure Stack Hub 자체에서 관리되므로 구성이 필요하지 않습니다. 그러나 모든 서비스와 마찬가지로 이러한 리소스는 메모리, 스토리지를 사용하며 특정 vCPU가 할당됩니다.
| 서비스 | vCore | 메모리 | 디스크 크기 |
|---|---|---|---|
| Azure Site Recovery | 12 | 42GB | 1.4TB |
참고
이러한 리소스는 Azure Stack Hub의 관리 쪽에 있는 Azure Stack Hub 서비스입니다. 설치되면 플랫폼이 이러한 리소스를 관리합니다.
보호되는 작업
BCDR 계획을 만들 때 보호된 워크로드의 모든 측면을 고려합니다. 다음 목록은 완료되지 않으며 시작점으로 처리해야 합니다.
VM 크기, 디스크 수, 디스크 크기, IOPS, 데이터 변동 및 생성된 새 데이터.
네트워크 대역폭 고려 사항:
- 델타 복제에 필요한 네트워크 대역폭입니다.
- 대상 환경에서 Azure Site Recovery 원본 환경에서 가져올 수 있는 처리량입니다.
- 한 번에 일괄 처리할 VM 수입니다. 이 숫자는 지정된 시간 안에 초기 복제를 완료하는 예상 대역폭을 기반으로 합니다.
- 지정된 대역폭에 대해 달성할 수 있는 RPO입니다.
- 낮은 대역폭이 프로비전되는 경우 원하는 RPO에 미치는 영향입니다.
스토리지 고려 사항:
- 초기 복제에 필요한 데이터 양입니다.
- 이러한 간격 동안 유지되는 복구 지점 수 및 보호된 각 VM에 대한 데이터 증가 방법
- 사용자가 충분한 할당을 갖도록 대상 Azure Stack Hub 사용자 구독에 할당해야 하는 할당량 수입니다.
- 복제를 위한 캐시 스토리지 계정입니다.
컴퓨팅 고려 사항:
- 장애 조치(failover)가 발생하면 대상 Azure Stack Hub 사용자 구독에서 VM이 시작됩니다. 이러한 VM 리소스를 시작할 수 있도록 충분한 할당량 할당이 있어야 합니다.
- VM을 보호하는 동안 보호된 VM이 원본 환경에서 활성화되면 vCPU, 메모리 등과 같은 VM 관련 리소스가 대상 환경에서 소비되지 않습니다. 이러한 리소스는 테스트 장애 조치(failover)와 같은 장애 조치(failover) 프로세스 중에만 관련됩니다.
Azure Stack Hub의 Azure Site Recovery scope 계산의 시작점은 다음과 같습니다. 특히 사용된 캐시 스토리지 계정의 경우 다음과 같습니다.
장애 조치(failover)가 있는 경우 정상 작업 중에 복제된 디스크 수를 평균 RPO에 곱합니다. 예를 들어 (2MB * 250s)이 있을 수 있습니다. 캐시 스토리지 계정은 일반적으로 디스크당 몇 KB에서 500MB까지입니다.
최악의 시나리오를 감안할 때 장애 조치(failover)가 있는 경우 하루 종일 평균 RPO를 통해 복제된 디스크 수를 곱합니다.
중요
Azure Site Recovery 일부 부분이 작동하지 않지만 다른 부분이 작동하는 경우 Azure Site Recovery 시간 초과를 결정하기 전에 스토리지 계정에 최대 하루 동안 difflog가 있을 수 있습니다.
새 VM으로 장애 복구(failback)합니다. 각 일괄 처리의 디스크 크기 합계를 계산합니다.
- 대상이 빈 디스크이므로 대상 VM을 적용하려면 전체 디스크를 캐시 스토리지 계정에 복사해야 합니다.
- 연결된 데이터는 복사한 후에 삭제되지만 모든 디스크 크기의 합계로 최대 사용량이 표시될 수 있습니다.
보호하려는 솔루션의 세부 사항에 따라 BDCR 계획을 만듭니다.
다음 표는 환경에서 실행되는 테스트의 예입니다. 이 인사이트를 사용하여 고유한 애플리케이션에 대한 기준을 가져올 수 있지만 각 워크로드는 다릅니다.
구성
| 블록 크기 | 처리량/디스크 |
|---|---|
| 2MB | 2MB/초 |
| 64KB | 2MB/초 |
| 8KB | 1MB/초 |
| 8KB | 2MB/초 |
결과
| 지원되는 디스크 수 | 총 처리량 | 총 OPS | Bottleneck |
|---|---|---|---|
| 68 | 136MB/s | 68 | 스토리지 |
| 60 | 120MB/s | 2048 | 스토리지 |
| 28 | 28MB/s | 3584 | Azure Site Recovery CPU 및 메모리 |
| 16 | 32MB/s | 4096 |
참고
8Kb는 Azure Site Recovery 지원하는 데이터의 가장 작은 블록 크기입니다. 8Kb 미만의 모든 변경 내용은 8Kb로 처리됩니다.
더 자세히 테스트하기 위해 일관된 유형의 워크로드를 생성했습니다. 예를 들어 디스크당 최대 1MB/s에 달하는 8Kb 블록의 일관된 스토리지 변경이 있습니다. 이 시나리오는 하루 중 여러 시간에 또는 다양한 크기의 급증에서 변경이 발생할 수 있다는 점을 감안할 때 실제 워크로드에서는 그렇지 않을 수 있습니다.
이러한 임의 패턴을 복제하기 위해 다음을 사용하여 시나리오를 테스트했습니다.
- 동일한 Azure Site Recovery VM 어플라이언스 통해 보호되는 VM 120개(Windows 80개, Linux 40개).
각 VM은 시간당 최소 두 번 임의 간격으로 생성되며, 임의 블록은 5개의 파일에서 총 5Gb의 데이터를 생성합니다.
Azure Site Recovery 서비스에서 중간 부하가 낮은 모든 120개 VM에서 복제가 성공했습니다.
참고
이러한 숫자는 기준선으로만 사용해야 합니다. 반드시 선형으로 스케일링하지는 않습니다. 동일한 VM 수의 다른 일괄 처리를 추가하면 초기 VM보다 영향이 적을 수 있습니다. 결과는 사용되는 워크로드 유형에 따라 크게 달라집니다.
계획 및 테스트 방법
애플리케이션 및 솔루션 워크로드에는 특정 RTO(복구 시간 목표) 및 RPO(복구 지점 목표) 요구 사항이 있습니다. 효과적인 BCDR(비즈니스 연속성 및 재해 복구) 디자인은 솔루션별 메커니즘을 사용하므로 이러한 요구 사항을 충족하는 플랫폼 수준 기능을 모두 활용합니다. BCDR 기능을 설계하려면 DR(플랫폼 재해 복구) 요구 사항을 캡처하고 디자인에서 이러한 모든 요소를 고려합니다.
애플리케이션 및 데이터 가용성 요구 사항:
- 각 워크로드에 대한 RTO 및 RPO 요구 사항
- 활성-활성 및 활성-수동 가용성 패턴에 대한 지원
성능에 대한 구성 요소 근접성을 사용하여 장애 조치(failover)를 위한 다중 리소스 배포에 대한 지원 가동 중단 시 기능이 감소하거나 성능이 저하된 애플리케이션 작업이 발생할 수 있습니다.
참고
애플리케이션은 기본적으로 실행할 것을 알고 있거나 여러 Azure Stack Hub 환경에서 실행할 수 있는 특정 구성 요소가 있을 수 있습니다. 이 경우 Azure Site Recovery 사용하여 이 기능이 없는 구성 요소(예: Azure Stack Hub 환경에 프런트 엔드를 배포할 수 있는 프런트 엔드 또는 백 엔드 형식 솔루션)를 사용하여 VM만 복제할 수 있습니다.
프로덕션 및 DR 네트워크에서 겹치는 IP 주소 범위를 사용하지 마세요.
- IP 주소가 겹치는 프로덕션 및 DR 네트워크에는 애플리케이션 장애 조치(failover)를 복잡하게 하고 지연할 수 있는 장애 조치(failover) 프로세스가 필요합니다. 가능하면 모든 사이트에 동시 연결을 제공하는 BCDR 네트워크 아키텍처를 계획합니다.
대상 환경 크기 조정:
- 원본 및 대상을 1:1 방식으로 사용하는 경우 대상 환경에 약간 더 많은 스토리지를 할당합니다. 이는 디스크 책갈피의 기록이 발생하는 방식 때문입니다. 이 할당은 데이터 변경 내용만 포함하므로 2배 증가하지 않습니다. 데이터 형식 및 예상되는 변경 내용에 따라 대상에 1.5배에서 2배 더 많은 스토리지가 있는 복제 정책은 장애 조치(failover) 프로세스에 문제가 발생하지 않도록 합니다.
- 대상 Azure Stack Hub 환경을 여러 Azure Stack Hub 원본의 대상으로 사용하는 것이 좋습니다. 이 경우 전체 비용을 낮추지만 특정 워크로드가 중단되면 어떻게 되는지 계획해야 합니다. 예를 들어 우선 순위를 지정해야 하는 원본입니다.
- 대상 환경이 다른 워크로드를 실행하는 데 사용되는 경우 BCDR 계획에는 이러한 워크로드의 동작이 포함되어야 합니다. 예를 들어 대상 환경에서 개발/테스트 VM을 실행할 수 있으며 원본 환경에서 문제가 발생하는 경우 대상의 모든 VM을 해제하여 보호된 VM을 시작하는 데 충분한 리소스를 사용할 수 있도록 할 수 있습니다.
BCDR을 테스트하고 정기적으로 유효성을 검사해야 합니다. 테스트 장애 조치 프로세스를 사용하거나 전체 워크로드를 이동하여 흐름의 엔드 투 엔드 유효성을 검사하여 이 작업을 수행할 수 있습니다.