Azure Stack Hub에 배포된 VM 보호

  • 아티클

이 문서를 가이드로 사용하여 Azure Stack Hub에 배포된 사용자 배포 IaaS VM(가상 머신)에 대한 데이터 보호 및 재해 복구 전략을 개발하는 데 도움이 됩니다.

데이터 손실 및 연장된 가동 중지 시간으로부터 보호하려면 사용자 애플리케이션 및 해당 데이터에 대한 백업 복구 또는 재해 복구 계획을 구현합니다. 각 애플리케이션은 organization 포괄적인 BC/DR(비즈니스 연속성 및 재해 복구) 전략의 일부로 평가되어야 합니다.

IaaS VM을 보호하기 위한 고려 사항

역할 및 책임

먼저 보호 및 복구의 컨텍스트에서 애플리케이션 소유자 및 운영자에게 귀속되는 역할 및 책임을 명확하게 이해해야 합니다.

사용자는 VM을 보호할 책임이 있습니다. 운영자는 Azure Stack Hub를 온라인 및 정상 상태로 유지할 책임이 있습니다. Azure Stack Hub에는 인프라 서비스에서 내부 서비스 데이터를 백업하고 사용자가 만든 VM, 사용자 또는 애플리케이션 데이터가 있는 스토리지 계정 또는 사용자 데이터베이스를 포함한 사용자 데이터를 포함하지 않는 서비스가 포함되어 있습니다.

애플리케이션 소유자/설계자 Azure Stack Hub 운영자
- 애플리케이션 아키텍처를 클라우드 디자인 원칙에 맞춥니다.
- 필요에 따라 기존 애플리케이션을 현대화하여 클라우드 환경에 맞게 준비합니다.
- 애플리케이션에 허용되는 RTO 및 RPO를 정의합니다.
- 보호해야 하는 애플리케이션 리소스 및 데이터 리포지토리를 식별합니다.
- 애플리케이션 아키텍처 및 고객 요구 사항에 가장 적합한 데이터 및 애플리케이션 복구 방법을 구현합니다.		 - organization 비즈니스 연속성 및 재해 복구 목표를 식별합니다.
- organization BC/DR 목표를 충족하기에 충분한 Azure Stack Hub 인스턴스를 배포합니다.
- 애플리케이션/데이터 보호 인프라를 설계하고 운영합니다.
- 보호 서비스에 대한 관리형 솔루션 또는 셀프 서비스 액세스를 제공합니다.
- 애플리케이션 소유자/설계자와 협력하여 애플리케이션 디자인을 이해하고 보호 전략을 권장합니다.
- 서비스 복구 및 클라우드 복구를 위해 인프라 백업을 사용하도록 설정합니다.

원본/대상 조합

데이터 센터 또는 사이트 중단으로부터 보호해야 하는 사용자는 다른 Azure Stack Hub 또는 Azure를 사용하여 고가용성 또는 빠른 복구를 제공할 수 있습니다. 기본 및 보조 위치를 사용하면 사용자는 두 환경에 걸쳐 활성/활성 또는 활성/수동 구성으로 애플리케이션을 배포할 수 있습니다. 덜 중요한 워크로드의 경우 사용자는 보조 위치의 용량을 사용하여 백업에서 애플리케이션의 주문형 복원을 수행할 수 있습니다.

하나 이상의 Azure Stack Hub 클라우드를 데이터 센터에 배포할 수 있습니다. 치명적인 재해에서 살아남기 위해 다른 데이터 센터에 하나 이상의 Azure Stack Hub 클라우드를 배포하면 워크로드를 장애 조치하고 계획되지 않은 가동 중지 시간을 최소화할 수 있습니다. Azure Stack Hub가 하나만 있는 경우 Azure 퍼블릭 클라우드를 복구 클라우드로 사용하는 것이 좋습니다. 애플리케이션을 실행할 수 있는 위치의 결정은 정부 규정, 기업 정책 및 엄격한 대기 시간 요구 사항에 따라 결정됩니다. 애플리케이션당 적절한 복구 위치를 유연하게 확인할 수 있습니다. 예를 들어 한 구독에 애플리케이션이 다른 데이터 센터에 데이터를 백업하고 다른 구독에서 데이터를 Azure 퍼블릭 클라우드에 복제하도록 할 수 있습니다.

애플리케이션 복구 목표

애플리케이션 소유자는 주로 애플리케이션 및 organization 허용할 수 있는 가동 중지 시간 및 데이터 손실의 양을 결정할 책임이 있습니다. 허용되는 가동 중지 시간과 허용 가능한 데이터 손실을 정량화하여 재해가 organization 미치는 영향을 최소화하는 복구 계획을 만들 수 있습니다. 각 애플리케이션에 대해 다음을 고려합니다.

  • RTO(복구 시간 목표)
    RTO는 인시던트 후 앱을 사용할 수 없는 최대 허용 시간입니다. 예를 들어 RTO가 90분이면 재해가 시작된 후 90분 이내에 앱을 실행 상태로 복원할 수 있어야 합니다. RTO가 낮은 경우 지역 가동 중단으로부터 보호하기 위해 두 번째 배포를 대기 상태로 계속 실행할 수 있습니다.
  • 복구 지점 목표(RPO)
    RPO는 재해 발생 시 허용되는 최대 데이터 손실 기간입니다. 예를 들어 매시간 백업되고 다른 데이터베이스에 대한 복제가 없는 단일 데이터베이스에 데이터를 저장하면 최대 1시간의 데이터가 손실될 수 있습니다.

또 다른 메트릭은 MTTR( 평균 복구 시간 )이며, 이는 실패 후 애플리케이션을 복원하는 데 걸리는 평균 시간입니다. MTTR은 시스템의 경험적 값입니다. MTTR이 RTO를 초과하는 경우 시스템의 오류로 인해 정의된 RTO 내에서 시스템을 복원할 수 없으므로 허용할 수 없는 비즈니스 중단이 발생합니다.

보호 옵션

Backup 복원

애플리케이션 및 데이터 세트를 백업하면 데이터 손상, 실수로 인한 삭제 또는 재해로 인한 가동 중지 시간으로부터 신속하게 복구할 수 있습니다. IaaS VM 기반 애플리케이션의 경우 게스트 내 에이전트를 사용하여 볼륨에 저장된 애플리케이션 데이터, 운영 체제 구성 및 데이터를 보호할 수 있습니다.

게스트 내 에이전트를 사용하여 백업

게스트 OS 에이전트를 사용하여 VM을 백업하는 데는 일반적으로 운영 체제 구성, 파일/폴더, 디스크, 애플리케이션 이진 파일 또는 애플리케이션 데이터 캡처가 포함됩니다.

에이전트에서 애플리케이션을 복구하려면 VM을 수동으로 다시 만들고, 운영 체제를 설치하고, 게스트 에이전트를 설치해야 합니다. 이 시점에서 데이터를 게스트 OS로 복원하거나 애플리케이션에 직접 복원할 수 있습니다.

중지된 VM에 디스크 스냅샷 사용하여 백업

백업 제품은 IaaS VM 구성 및 중지된 VM에 연결된 디스크를 보호할 수 있습니다. Azure Stack Hub API와 통합되는 백업 제품을 사용하여 VM 구성을 캡처하고 디스크 스냅샷을 만듭니다. 애플리케이션에 대해 계획된 가동 중지 시간이 가능한 경우 백업 워크플로를 시작하기 전에 VM이 중지된 상태인지 확인합니다.

VM을 실행하기 위해 디스크 스냅샷 사용하여 백업

중요

포털에서 디스크 스냅샷을 사용하는 것은 현재 실행 중인 VM에 대해 지원되지 않습니다. 실행 중인 VM에 연결된 디스크의 스냅샷 만들면 성능이 저하되거나 VM에서 운영 체제 또는 애플리케이션의 가용성에 영향을 미칠 수 있습니다. 권장 사항은 Storage RP 증분 스냅샷 기능과 통합되는 백업 공급업체 솔루션 또는 계획된 가동 중지 시간이 옵션이 아닌 경우 게스트 내 에이전트를 사용하여 애플리케이션을 보호하는 것입니다.

확장 집합 또는 가용성 집합의 VM

임시 리소스로 간주되는 확장 집합 또는 가용성 그룹의 VM은 VM 수준에서 백업해서는 안 됩니다(특히 애플리케이션이 상태 비저장인 경우). 확장 집합 또는 가용성 집합에 배포된 상태 저장 애플리케이션의 경우 애플리케이션 데이터(예: 스토리지 풀의 데이터베이스 또는 볼륨)를 보호하는 것이 좋습니다.

복제/수동 장애 조치(failover)

최소한의 데이터 손실 또는 최소 가동 중지 시간이 필요한 애플리케이션의 경우 게스트 OS 또는 애플리케이션 수준에서 데이터 복제를 사용하도록 설정하여 데이터를 다른 위치에 복제할 수 있습니다. Microsoft SQL Server 같은 일부 애플리케이션은 기본적으로 복제를 지원합니다. 애플리케이션이 복제를 지원하지 않는 경우 게스트 OS의 소프트웨어를 사용하여 디스크를 복제하거나 게스트 OS에서 에이전트로 설치하는 파트너 솔루션을 사용할 수 있습니다.

이 방법을 사용하면 애플리케이션이 한 클라우드에 배포되고 데이터가 다른 클라우드 온-프레미스 또는 Azure에 복제됩니다. 장애 조치(failover)가 트리거되면 대상의 애플리케이션을 시작하고 복제된 데이터에 연결해야 서비스 요청을 시작할 수 있습니다.

고가용성/자동 장애 조치(failover)

몇 초 또는 몇 분 동안만 가동 중지 시간을 허용할 수 있는 상태 비 상태 비정상 애플리케이션의 경우 고가용성 구성을 고려합니다. 고가용성 애플리케이션은 모든 인스턴스가 요청을 서비스할 수 있는 활성/활성 토폴로지의 여러 위치에 배포되도록 설계되었습니다. 로컬 하드웨어 오류의 경우 Azure Stack Hub 인프라는 두 개의 상단 랙 스위치를 사용하여 물리적 네트워크에서 고가용성을 구현합니다. 컴퓨팅 수준 오류의 경우 Azure Stack Hub는 배율 단위에서 여러 노드를 사용하며 VM을 자동으로 장애 조치(failover)합니다. VM 수준에서 가용성 집합에서 확장 집합 또는 VM을 사용하여 노드 오류가 애플리케이션을 중단하지 않도록 할 수 있습니다. 동일한 애플리케이션을 동일한 구성의 보조 위치에 배포해야 합니다. 애플리케이션을 활성/활성으로 만들기 위해 부하 분산 장치 또는 DNS를 사용하여 요청을 사용 가능한 모든 인스턴스로 전송할 수 있습니다.

복구 없음

사용자 환경의 일부 앱은 계획되지 않은 가동 중지 시간 또는 데이터 손실에 대한 보호가 필요하지 않을 수 있습니다. 예를 들어 개발 및 테스트에 사용되는 VM은 일반적으로 복구할 필요가 없습니다. 애플리케이션 또는 데이터 세트에 대한 보호 없이 수행하는 것이 사용자의 결정입니다.

Azure Stack Hub 배포에 대한 중요한 고려 사항:

권장 주석
데이터 센터에 이미 배포된 외부 백업 대상으로 VM 백업/복원 권장 기존 백업 인프라 및 운영 기술을 활용합니다. 추가 VM 인스턴스를 보호할 준비가 되도록 백업 인프라의 크기를 조정해야 합니다. 백업 인프라가 원본과 가까이 있지 않은지 확인합니다. VM을 원본 Azure Stack Hub, 보조 Azure Stack Hub instance 또는 Azure로 복원할 수 있습니다.
Azure Stack Hub 전용 외부 백업 대상으로 VM 백업/복원 권장 새 백업 인프라를 구입하거나 Azure Stack Hub에 대한 전용 백업 인프라를 프로비전할 수 있습니다. 백업 인프라가 원본과 가까이 있지 않은지 확인합니다. VM을 원본 Azure Stack Hub, 보조 Azure Stack Hub instance 또는 Azure로 복원할 수 있습니다.
VM을 전역 Azure 또는 신뢰할 수 있는 서비스 공급자에 직접 백업/복원 권장 데이터 개인 정보 및 규정 요구 사항을 충족할 수 있는 한, 글로벌 Azure 또는 신뢰할 수 있는 서비스 공급자에 백업을 저장할 수 있습니다. 이상적으로 서비스 공급자는 Azure Stack Hub를 실행하므로 복원할 때 운영 환경에서 일관성을 얻을 수 있습니다.
별도의 Azure Stack Hub instance VM 복제/장애 조치(failover) 권장 장애 조치(failover)의 경우 확장된 앱 가동 중지 시간을 방지할 수 있도록 두 번째 Azure Stack Hub 클라우드가 완전히 작동해야 합니다.
Azure 또는 신뢰할 수 있는 서비스 공급자에 직접 VM 복제/장애 조치(failover) 권장 데이터 개인 정보 및 규정 요구 사항을 충족할 수 있는 한 데이터를 글로벌 Azure 또는 신뢰할 수 있는 서비스 공급자에 복제할 수 있습니다. 이상적으로 서비스 공급자는 Azure Stack Hub를 실행하므로 장애 조치(failover) 후 운영 환경에서 일관성을 얻을 수 있습니다.
동일한 백업 대상으로 보호되는 모든 애플리케이션을 호스트하는 동일한 Azure Stack Hub에 백업 대상을 배포합니다. 독립 실행형 대상: 외부에서 백업 데이터를 복제하는 권장
되지 않는 대상: 권장		 Azure Stack Hub에 백업 어플라이언스 배포하도록 선택하는 경우(운영 복원 최적화를 위해) 모든 데이터가 외부 백업 위치에 지속적으로 복사되는지 확인해야 합니다.
Azure Stack Hub 솔루션이 설치된 동일한 랙에 물리적 백업 어플라이언스 배포 지원되지 않음 현재 다른 디바이스는 원래 솔루션의 일부가 아닌 랙 스위치의 맨 위에 연결할 수 없습니다.

복원된 IaaS VM에 대한 고려 사항

백업에서 컴퓨터를 복원한 후 VM을 일부 변경해야 합니다. 이러한 개체는 다음과 같습니다.

  • MAC 주소
    가상 네트워크 어댑터는 새 MAC 주소를 가져옵니다. 원래 MAC 주소를 유지하는 메서드는 없습니다.
  • IP 주소
    VM에 내부적으로 설정된 고정 IP가 있는 경우 가상 네트워크 어댑터의 내부 IP를 원래 IP와 일치하도록 설정할 수 있습니다. VNET에 IP 주소가 사용 중인 외부 환경에 대한 S2S VPN이 있는지 고려해야 할 수 있습니다.
  • 불필요한 아티팩트
    VM이 VMware vSphere와 같은 다른 플랫폼에서 백업된 경우 몇 가지 추가 단계에 따라 원본에서 불필요한 아티팩트 클린 합니다.

다음 단계

이 문서에서는 Azure Stack Hub에 배포된 사용자 VM을 보호하기 위한 일반적인 지침을 제공했습니다. Azure 서비스를 사용하여 사용자 VM을 보호하는 방법에 대한 자세한 내용은 다음을 참조하세요.