Azure Stack Hub에 배포된 VM 보호 - 러기드

  • 아티클

이 문서를 가이드로 사용하여 사용자가 Azure Stack Hub에 배포하는 VM(가상 머신)을 보호하기 위한 계획을 개발합니다.

데이터 손실 및 계획되지 않은 가동 중지 시간으로부터 보호하려면 Azure Stack Hub의 VM 기반 애플리케이션에 대한 데이터 보호 및 재해 복구 계획을 구현합니다. 구현된 보호 계획은 비즈니스 요구 사항 및 애플리케이션 설계에 따라 달라집니다. 이 계획은 organization 포괄적인 BC/DR(비즈니스 연속성 및 재해 복구) 전략에 의해 설정된 프레임워크를 따라야 합니다.

애플리케이션 복구 목표

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

  • RTO(복구 시간 목표)
    RTO는 인시던트 후 앱을 사용할 수 없는 최대 허용 시간입니다. 예를 들어 RTO가 90분이면 재해가 시작된 후 90분 이내에 앱을 실행 중 상태로 복원할 수 있어야 합니다. RTO가 낮은 경우 지역 가동 중단으로부터 보호하기 위해 두 번째 배포를 대기 상태로 계속 실행할 수 있습니다.

  • 복구 지점 목표(RPO)
    RPO는 재해 발생 시 허용되는 최대 데이터 손실 기간입니다. 예를 들어 매시간 백업되고 다른 데이터베이스에 대한 복제가 없는 단일 데이터베이스에 데이터를 저장하면 최대 1시간의 데이터가 손실될 수 있습니다.

평가를 수행하여 각 애플리케이션에 대한 RTO 및 RPO를 정의합니다.

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

IaaS VM에 대한 보호 옵션

Backup-restore

VM 기반 앱에 대한 가장 일반적인 보호 체계는 백업 소프트웨어를 사용하는 것입니다. VM 백업에는 일반적으로 운영 체제, 운영 체제 구성, 애플리케이션 이진 파일 및 VM 내에 포함된 영구 애플리케이션 데이터가 포함됩니다. 백업은 게스트 OS의 에이전트를 사용하여 애플리케이션, OS 또는 파일 시스템/볼륨을 캡처하여 만들어집니다. 또 다른 방법은 Azure Stack Hub API와의 통합을 사용하여 VM 구성에 대한 정보를 읽고 VM에 연결된 디스크를 스냅샷 에이전트가 없는 방법입니다. Azure Stack Hub는 하이퍼바이저에서 직접 백업을 지원하지 않습니다.

백업 전략 계획

백업 전략 계획 및 크기 조정 요구 사항 정의는 보호해야 하는 VM 인스턴스 수를 정량화하는 것부터 시작합니다. 시스템의 모든 VM을 백업하는 것이 애플리케이션을 보호하는 가장 효과적인 방법이 아닐 수 있습니다. Azure Stack Hub를 사용하면 확장 집합 또는 가용성 집합의 VM을 VM 수준에서 백업해서는 안 됩니다. 이러한 VM은 VM 집합을 스케일 인 또는 스케일 아웃할 수 있으므로 임시로 간주됩니다. 이상적으로 유지해야 하는 모든 데이터는 데이터베이스 또는 개체 저장소와 같은 별도의 리포지토리에 있습니다. 스케일 아웃 아키텍처에 배포된 애플리케이션에 유지 및 보호해야 하는 데이터가 포함된 경우 애플리케이션에서 제공하거나 에이전트를 사용하여 네이티브 기능을 사용하여 애플리케이션 수준 백업이 필요합니다.

Azure Stack에서 VM을 백업하기 위한 중요한 고려 사항:

  • 분류
    • 사용자가 VM 백업을 옵트인하는 모델을 고려합니다.
    • 애플리케이션의 우선 순위 또는 비즈니스에 미치는 영향에 따라 SLA(복구 서비스 수준 계약)를 정의합니다.
  • 규모
    • 많은 수의 새 VM을 온보딩할 때(백업이 필요한 경우) 엇갈려진 백업을 고려합니다.
    • 백업 데이터를 효율적으로 캡처하고 전송하여 솔루션의 리소스 콘텐츠를 최소화할 수 있는 백업 제품을 평가합니다.
    • 증분 또는 차등 백업을 사용하여 백업 데이터를 효율적으로 저장하는 백업 제품을 평가하여 환경의 모든 VM에서 전체 백업의 필요성을 최소화합니다.
  • 복원
    • 백업 제품은 가상 디스크, 기존 VM 내의 앱 데이터 또는 전체 VM 리소스 및 연결된 가상 디스크를 복원할 수 있습니다. 필요한 복원 체계는 앱을 복원하는 방법에 따라 달라집니다. 예를 들어 전체 VM 또는 VM 집합을 복원하는 대신 템플릿에서 SQL 서버를 다시 배포한 다음 데이터베이스를 복원하는 것이 더 쉬울 수 있습니다.

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

복구를 지원하는 대체 방법은 데이터를 다른 환경에 복제하는 것입니다. 데이터는 에이전트를 사용하여 데이터베이스 복제와 같은 애플리케이션 또는 게스트 OS의 운영 체제 또는 Azure Stack Hub API와 통합하여 VM 수준으로 범위를 지정할 수 있습니다. 재해가 발생할 경우 보조 위치로 장애 조치(failover)가 필요합니다. 장애 조치(failover)는 SQL 가용성 그룹과 같은 애플리케이션 또는 에이전트 또는 클러스터 기술을 사용하는 게스트 OS 수준에서 또는 보호 제품을 사용하여 VM 수준에서 기본적으로 처리할 수 있습니다.

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

기본적으로 고가용성을 지원하거나 클러스터 소프트웨어를 사용하여 노드 간에 고가용성을 달성하는 애플리케이션은 하나의 Azure Stack Hub 또는 여러 Azure Stack Hub 인스턴스에 있는 VM 그룹에 배포할 수 있습니다. 모든 경우에 애플리케이션 트래픽이 올바르게 라우팅되도록 하려면 일부 수준의 부하 분산이 필요합니다. 이 구성에서 애플리케이션은 오류에서 자동으로 복구할 수 있습니다. 로컬 하드웨어 오류의 경우 Azure Stack Hub 인프라는 물리적 인프라에서 고가용성 및 내결함성을 구현합니다. 컴퓨팅 수준 오류의 경우 Azure Stack Hub는 N-1 구성의 배율 단위에서 여러 노드를 사용합니다. VM 수준에서 가용성 및 확장 집합은 노드 오류가 분산 애플리케이션을 중단하지 않도록 노드 수준 선호도 방지를 보장하기 위해 배율 단위의 각 노드를 장애 도메인으로 모델링합니다.

보호 없음

일부 애플리케이션에는 유지해야 하는 데이터가 없을 수 있습니다. 예를 들어 개발 및 테스트에 사용되는 VM은 일반적으로 복구할 필요가 없습니다. 또 다른 예는 실패 시 CI/CD 파이프라인에서 다시 배포할 수 있는 상태 비정상 애플리케이션입니다. VM을 불필요하게 보호하지 않도록 보호가 필요하지 않은 애플리케이션을 식별하는 것이 중요합니다.

파트너 제품