Azure Virtual Desktop을 위한 다중 지역 비즈니스 연속성 및 재해 복구(BCDR)

Azure Virtual Desktop은 Microsoft Azure에서 실행되는 포괄적인 데스크톱 및 앱 가상화 서비스입니다. Virtual Desktop을 사용하면 조직에서 비즈니스 복원력을 강화하는 데 도움이 되는 안전한 원격 데스크톱 환경을 사용할 수 있습니다. 간소화된 관리, Windows 10 및 11 Enterprise 다중 세션 및 엔터프라이즈용 Microsoft 365 앱 최적화를 제공합니다. Virtual Desktop을 사용하면 몇 분 안에 Azure에서 Windows 데스크톱 및 앱을 배포하고 스케일링하여 앱과 데이터를 안전하게 유지하는 데 도움이 되는 통합 보안 및 규정 준수 기능을 제공할 수 있습니다.

Virtual Desktop을 사용하여 조직에 원격 작업을 계속 사용하도록 설정하면 DR(재해 복구) 기능 및 모범 사례를 이해하는 것이 중요합니다. 모범 사례는 지역 간 안정성을 강화하여 데이터 보안 및 직원의 생산성을 유지하는 데 도움이 됩니다. 이 문서에서는 BCDR(비즈니스 연속성 및 재해 복구) 필수 구성 요소, 배포 단계 및 모범 사례에 대한 고려 사항을 제공합니다. 옵션, 전략 및 아키텍처 지침에 대해 알아봅니다. 이 문서의 내용을 통해 성공적인 BCDR 계획을 준비할 수 있으며 계획 및 계획되지 않은 가동 중지 이벤트 중에 비즈니스의 복원력을 더욱 강화할 수 있습니다.

여러 가지 유형의 재해 및 중단이 있으며 미치는 영향은 각각 다를 수 있습니다. 복원력 및 복구는 다른 원격 Azure 지역에서 서비스 복구를 포함하여 로컬 및 지역 범위 이벤트 둘 다에 대해 자세히 설명합니다. 이러한 유형의 복구를 지역 재해 복구라고 합니다. 복원력 및 가용성을 위해 Virtual Desktop 아키텍처를 빌드하는 것이 중요합니다. 실패 이벤트가 미치는 영향을 줄이기 위해 최대 로컬 복원력을 제공해야 합니다. 또한 복원력은 복구 절차를 실행하기 위한 요구 사항을 줄여줍니다. 이 문서에서는 고가용성 및 모범 사례에 대한 정보도 제공합니다.

목표 및 범위

이 가이드의 목표는 다음과 같습니다.

• 선택한 중요한 사용자 데이터에 대한 데이터 손실을 최소화하면서 최대 가용성, 복원력 및 지리적 재해 복구 기능을 보장합니다.
• 복구 시간을 최소화합니다.

이러한 목표를 RPO(복구 지점 목표) 및 RTO(복구 시간 목표)라고도 합니다.

제안된 솔루션은 로컬 고가용성, 단일 가용성 영역 오류로부터의 보호 및 전체 Azure 지역 오류로부터의 보호를 제공합니다. 서비스를 복구하기 위해 다른 또는 보조 Azure 지역에서 중복 배포를 사용합니다. 여전히 좋은 사례이긴 하지만 BCDR을 빌드하는 데 사용된 기술과 Virtual Desktop에는 Azure 지역을 페어링할 필요가 없습니다. 네트워크 대기 시간이 허용하는 경우 기본 및 보조 위치는 Azure 지역 조합일 수 있습니다. 여러 지역에서 AVD 호스트 풀을 운영하면 BCDR에 국한되지 않는 더 많은 이점을 제공할 수 있습니다.

단일 가용성 영역 실패의 영향을 줄이기 위해 복원력을 사용하여 고가용성을 개선합니다.

• 컴퓨팅 계층에서 가상 데스크톱 세션 호스트를 여러 가용성 영역에 분산합니다.
• 스토리지 계층에서 가능하면 항상 영역 복원력을 사용합니다.
• 네트워킹 계층에서 영역 복원력 있는 Azure ExpressRoute 및 VPN(가상 사설망) 게이트웨이를 배포합니다.
• 각 종속성에 대해 단일 영역 중단의 영향을 검토하고 완화를 계획합니다. 예를 들어 여러 가용성 영역에서 Virtual Desktop 사용자가 액세스하는 Active Directory 도메인 컨트롤러 및 기타 외부 리소스를 배포합니다.

사용하는 가용성 영역 수에 따라 세션 호스트 수 오버프로비저닝을 평가하여 한 영역의 손실을 보상합니다. 예를 들어 (n-1)개 영역을 사용할 수 있는 경우에도 사용자 환경 및 성능을 보장할 수 있습니다.

일부 지역에서는 형식, 복제 옵션, 서비스 기능 및 가용성 제한의 조합이 가능하기 때문에 스토리지별 복제 메커니즘 대신 FSLogix의 클라우드 캐시 구성 요소를 사용하는 것이 좋습니다.

OneDrive는 이 문서에서 다루지 않습니다. 중복도 및 고가용성에 대한 자세한 내용은 Microsoft 365의 SharePoint 및 OneDrive 데이터 복원력을 참조하세요.

이 문서의 나머지 부분에서는 서로 다른 두 Virtual Desktop 호스트 풀 유형에 대한 솔루션에 대해 알아봅니다. 이 아키텍처를 다른 솔루션과 비교할 수 있도록 관찰 내용도 제공됩니다.

• 개인: 이 유형의 호스트 풀에서 사용자에게는 영구적으로 할당된 세션 호스트가 있으며, 이는 변경되지 않아야 합니다. 개인용이므로 이 VM은 사용자 데이터를 저장할 수 있습니다. 복제 및 백업 기술을 사용하여 상태를 보존하고 보호한다고 가정합니다.
• 풀링: 데스크톱 애플리케이션 그룹을 통해 직접 또는 원격 앱을 사용하여 풀에서 사용 가능한 세션 호스트 VM 중 하나가 사용자에게 일시적으로 할당됩니다. VM은 상태 비저장이며 사용자 데이터 및 프로필은 외부 스토리지 또는 OneDrive에 저장됩니다.

비용에 미치는 영향에 대해 설명하지만 주요 목표는 데이터 손실을 최소화하면서 효과적인 지역 재해 복구 배포를 제공하는 것입니다. BCDR에 대한 자세한 내용은 다음 리소스를 참조하세요.

• Virtual Desktop에 대한 BCDR 고려 사항
• Virtual Desktop 재해 복구

사전 요구 사항

핵심 인프라를 배포하고 기본 및 보조 Azure 지역에서 사용할 수 있는지 확인합니다. 네트워크 토폴로지에 대한 지침을 얻기 위해 Azure 클라우드 채택 프레임워크 네트워크 토폴로지 및 연결 모델을 사용할 수 있습니다.

• 기존 Azure 네트워킹 토폴로지
• Virtual WAN 네트워크 토폴로지(Microsoft에서 관리)

두 모델에서는 기본 Virtual Desktop 호스트 풀과 보조 재해 복구 환경을 서로 다른 스포크 가상 네트워크 내에 배포하고 동일한 지역의 각 허브에 연결합니다. 기본 위치에 허브를 하나 배치하고 보조 위치에 허브를 하나 배치한 다음 두 허브 간에 연결을 설정합니다.

허브는 결국 온-프레미스 리소스, 방화벽 서비스, ID 리소스(예: Active Directory 도메인 컨트롤러) 및 관리 리소스(예: Log Analytics)에 하이브리드 연결을 제공합니다.

보조 위치로 장애 조치된 경우 LOB(기간 업무) 애플리케이션 및 종속 리소스 가용성을 고려해야 합니다.

제어 평면 비즈니스 연속성 및 재해 복구

Virtual Desktop은 중단 시 고객 메타데이터를 유지하기 위해 제어 평면에 대한 비즈니스 연속성 및 재해 복구를 제공합니다. Azure 플랫폼은 이 데이터와 프로세스를 관리하며 사용자는 아무 것도 구성하거나 실행할 필요가 없습니다.

Virtual Desktop은 개별 구성 요소의 오류에 대한 복원력과 오류로부터 신속하게 복구할 수 있도록 설계되었습니다. 지역에서 중단이 발생하면 서비스 인프라 구성 요소가 보조 위치로 장애 조치되어 계속 정상적으로 작동합니다. 서비스 관련 메타데이터에 계속 액세스할 수 있으며 사용자는 사용 가능한 호스트에 계속 연결할 수 있습니다. 최종 사용자 연결은 테넌트 환경 또는 호스트가 액세스 가능한 상태로 유지되는 경우 온라인 상태를 유지합니다. Virtual Desktop 의 데이터 위치는 호스트 풀 세션 호스트 VM(가상 머신) 배포의 위치와 다릅니다. 지원되는 지역 중 하나에서 Virtual Desktop 메타데이터를 찾은 다음 VM을 다른 위치에 배포할 수 있습니다. 자세한 내용은 Virtual Desktop 서비스 아키텍처 및 복원력 문서에 나와 있습니다.

활성-활성 및 활성-수동

고유한 사용자 집합에 다른 BCDR 요구 사항이 있는 경우 구성이 다른 여러 호스트 풀을 사용하는 것이 좋습니다. 예를 들어 중요 업무용 애플리케이션을 사용하는 사용자는 지역 재해 복구 기능이 있는 완전 중복 호스트 풀을 할당할 수 있습니다. 그러나 개발 및 테스트 사용자는 재해 복구 없이 별도의 호스트 풀을 사용할 수 있습니다.

각 단일 Virtual Desktop 호스트 풀에 대해 BCDR 전략을 활성-활성 또는 활성-수동 모델에 기반해 구성할 수 있습니다. 이 시나리오에서는 한 지리적 위치에 있는 동일한 사용자 집합이 특정 호스트 풀에서 제공된다고 가정합니다.

• 활성-활성

  • 주 지역의 각 호스트 풀에 대해 보조 지역의 두 번째 호스트 풀을 배포합니다.

  • 이 구성은 거의 0 RTO를 제공하며 RPO에는 추가 비용이 있습니다.

  • 관리자가 개입하거나 장애 조치(failover)할 필요가 없습니다. 정상적인 작업 중에 보조 호스트 풀은 사용자에게 Virtual Desktop 리소스를 제공합니다.

  • 각 호스트 풀에는 영구 사용자 프로필에 대한 자체 스토리지 계정(하나 이상)이 있습니다.

  • 사용 가능한 사용자의 실제 위치 및 연결에 따라 대기 시간을 평가해야 합니다. 서유럽 및 북유럽과 같은 일부 Azure 지역의 경우 주 지역 또는 보조 지역에 액세스할 때 차이를 무시할 수 있습니다. Azure Virtual Desktop Experience Estimator 도구를 사용하여 이 시나리오의 유효성을 검사할 수 있습니다.

  • 사용자는 기본 및 보조 호스트 풀에서 DAG(데스크톱 애플리케이션 그룹) 및 RAG(RemoteApp 애플리케이션 그룹)와 같은 다른 애플리케이션 그룹에 할당됩니다. 이 경우 가상 데스크톱 클라이언트 피드에 중복 항목이 표시됩니다. 혼동을 방지하기 위해 각 리소스의 용도를 반영하는 명확한 이름과 레이블을 지정한 별도의 Virtual Desktop 작업 영역을 사용합니다. 이러한 리소스의 사용에 대해 사용자에게 알립니다.

    

  • FSLogix 프로필 및 ODFC 컨테이너를 별도로 관리하기 위해 스토리지가 필요한 경우 Cloud Cache를 사용하여 거의 0개의 RPO를 보장합니다.

    • 프로필 충돌을 방지하기 위해 사용자가 두 호스트 풀에 동시에 액세스하도록 허용하지 마세요.
    • 이 시나리오의 활성-활성 특성으로 인해 적절한 방법으로 이러한 리소스를 사용하는 방법을 사용자에게 교육해야 합니다.

• 활성-수동
  • 활성-활성과 마찬가지로 주 지역의 각 호스트 풀에 대해 보조 지역에 두 번째 호스트 풀을 배포합니다.
  • 사용 가능한 예산에 따라 보조 지역에서 활성 상태인 컴퓨팅 리소스의 양이 주 지역에 비해 줄어듭니다. 자동 스케일링을 사용하여 더 많은 컴퓨팅 용량을 제공할 수 있지만 여기에는 더 많은 시간이 필요하며 Azure 용량이 보장되지 않습니다.
  • 이 구성은 활성-활성 접근 방식에 비해 RTO가 더 높지만 비용이 적게 듭니다.
  • Azure 가동 중단이 발생하는 경우 장애 조치 절차를 실행하려면 관리자 개입이 필요합니다. 보조 호스트 풀은 일반적으로 Virtual Desktop 리소스에 대한 사용자 액세스를 제공하지 않습니다.
  • 각 호스트 풀에는 영구 사용자 프로필에 대한 자체 스토리지 계정이 있습니다.
  • 최적의 대기 시간 및 성능으로 Virtual Desktop 서비스를 사용하는 사용자는 Azure 가동 중단이 발생하는 경우에만 영향을 받습니다. Azure Virtual Desktop Experience Estimator 도구를 사용하여 이 시나리오의 유효성을 검사해야 합니다. 성능이 저하되는 한이 있더라도 보조 재해 복구 환경에서 성능이 허용되어야 합니다.
  • 사용자는 데스크톱 및 원격 앱과 같은 하나의 애플리케이션 그룹 집합에만 할당됩니다. 정상 작동 중에 이러한 앱은 기본 호스트 풀에 있습니다. 가동 중단 중 및 장애 조치 후 사용자는 보조 호스트 풀의 애플리케이션 그룹에 할당됩니다. 사용자의 Virtual Desktop 클라이언트 피드에 중복 항목이 표시되지 않고 동일한 작업 영역을 사용할 수 있으며 모든 항목이 투명합니다.
  • FSLogix 프로필 및 Office 컨테이너를 관리하기 위해 스토리지가 필요한 경우 클라우드 캐시를 사용하여 RPO가 거의 0인지 확인합니다.
    • 프로필 충돌을 방지하기 위해 사용자가 두 호스트 풀에 동시에 액세스하도록 허용하지 마세요. 이 시나리오는 활성-수동이므로 관리자는 애플리케이션 그룹 수준에서 이 동작을 적용할 수 있습니다. 사용자는 장애 조치 절차를 수행한 후에만 보조 호스트 풀의 각 애플리케이션 그룹에 액세스할 수 있습니다. 액세스는 기본 호스트 풀 애플리케이션 그룹에서 취소되고 보조 호스트 풀의 애플리케이션 그룹에 다시 할당됩니다.
    • 모든 애플리케이션 그룹에 대해 장애 조치를 실행합니다. 그러지 않으면 다른 호스트 풀에서 다른 애플리케이션 그룹을 사용하는 사용자가 효과적으로 관리되지 않는 경우 프로필 충돌을 일으킬 수 있습니다.
  • 특정 사용자 하위 집합이 보조 호스트 풀로 선택적으로 장애 조치되도록 허용하고 제한된 활성-활성 동작 및 테스트 장애 조치 기능을 제공할 수 있습니다. 특정 애플리케이션 그룹을 장애 조치할 수도 있지만 다른 호스트 풀의 리소스를 동시에 사용하지 않도록 사용자를 교육해야 합니다.

특정 상황에서는 여러 지역에 있는 세션 호스트가 혼합된 단일 호스트 풀을 만들 수 있습니다. 이 솔루션의 장점은 단일 호스트 풀이 있는 경우 데스크톱 및 원격 앱에 대한 정의 및 할당을 복제할 필요가 없다는 점입니다. 안타깝게 도 공유 호스트 풀에 대한 재해 복구에는 다음과 같은 몇 가지 단점이 있습니다.

• 풀링된 호스트 풀의 경우 사용자를 동일 지역의 세션 호스트로 강제 적용할 수 없습니다.
• 원격 지역의 세션 호스트에 연결할 때 대기 시간이 더 길어지고 최적의 성능을 발휘하지 못할 수 있습니다.
• 사용자 프로필에 스토리지가 필요한 경우 주 및 보조 지역의 세션 호스트에 대한 할당을 관리하기 위한 복잡한 구성이 필요합니다.
• 드레이닝 모드를 사용하여 보조 지역에 있는 세션 호스트에 대한 액세스를 일시적으로 사용하지 않도록 설정할 수 있습니다. 그러나 이 접근 방식을 사용하면 리소스의 복잡성, 관리 오버헤드 및 비효율적인 사용이 발생합니다.
• 보조 지역의 오프라인 상태에서 세션 호스트를 유지 관리할 수 있지만 복잡성과 관리 오버헤드가 더 많이 발생합니다.

고려 사항 및 권장 지침

일반

여러 호스트 풀 및 FSLogix 클라우드 캐시 메커니즘을 사용하여 활성-활성 또는 활성-수동 구성을 배포하기 위해 모델에 따라 동일한 작업 영역 또는 다른 작업 영역 내에 호스트 풀을 만들 수 있습니다. 이 방법을 사용하려면 정렬 및 업데이트를 유지하여 두 호스트 풀을 동기화하고 동일한 구성 수준으로 유지해야 합니다. 보조 재해 복구 지역에 대한 새 호스트 풀 외에도 다음 작업을 수행해야 합니다.

• 새 호스트 풀에 대한 고유 애플리케이션 그룹 및 관련 애플리케이션을 새로 만듭니다.
• 기본 호스트 풀에 대한 사용자 할당을 취소한 다음 장애 조치 중에 새 호스트 풀에 수동으로 다시 할당합니다.

FSLogix에 대한 비즈니스 연속성 및 재해 복구 옵션을 검토합니다.

• 프로필 복구 는 이 문서에서 다루지 않습니다.
• 클라우드 캐시(활성/수동) 는 이 문서에 포함되어 있지만 동일한 호스트 풀을 사용하여 구현됩니다.
• 클라우드 캐시(활성/활성) 는 이 문서의 나머지 부분에서 다룹니다.

Virtual Desktop 아키텍처 디자인에서 고려해야 하는 Virtual Desktop 리소스에는 제한이 있습니다. Virtual Desktop 서비스 제한에 따라 디자인의 유효성을 검사합니다.

진단 및 모니터링의 경우 기본 및 보조 호스트 풀 모두에 대해 동일한 Log Analytics 작업 영역을 사용하는 것이 좋습니다. 이 구성을 사용하여 Azure Virtual Desktop Insights 는 두 지역의 배포에 대한 통합 보기를 제공합니다.

그러나 단일 로그 대상을 사용하면 전체 주 지역을 사용할 수 없는 경우 문제가 발생할 수 있습니다. 보조 지역은 사용할 수 없는 지역에서 Log Analytics 작업 영역을 사용할 수 없습니다. 이 상황이 허용되지 않는 경우 다음 솔루션을 채택할 수 있습니다.

• 각 지역에 대해 별도의 Log Analytics 작업 영역을 사용한 다음 Virtual Desktop 구성 요소가 로컬 작업 영역으로 로그하도록 가리킵니다.
• Logs Analytics 작업 영역 복제 및 장애 조치(failover) 기능을 테스트하고 검토합니다.

Compute

• 주 및 보조 재해 복구 지역에 두 호스트 풀을 모두 배포하려면 세션 호스트 VM 플릿을 여러 가용성 영역에 분산해야 합니다. 가용성 영역을 로컬 지역에서 사용할 수 없는 경우 가용성 집합을 사용하여 기본 배포보다 솔루션의 복원력을 높일 수 있습니다.

• 보조 재해 복구 지역의 호스트 풀 배포에 사용하는 골든 이미지는 주 지역에 사용하는 것과 동일해야 합니다. Azure Compute Gallery에 이미지를 저장하고 주 위치와 보조 위치 둘 다에서 여러 이미지 복제본을 구성해야 합니다. 각 이미지 복제본은 최대 VM 수의 병렬 배포를 유지할 수 있으며 원하는 배포 일괄 처리 크기에 따라 둘 이상의 VM이 필요할 수 있습니다. 자세한 내용은 Azure Compute Gallery에서 이미지 저장 및 공유를 참조하세요.

  

• Azure Compute 갤러리는 전역 리소스가 아닙니다. 보조 지역에 보조 갤러리를 두는 것이 좋습니다. 주 지역에서 갤러리, VM 이미지 정의 및 VM 이미지 버전을 만듭니다. 그런 다음 보조 지역에서도 동일한 개체를 만듭니다. VM 이미지 버전을 만들 때 주 지역에서 사용되는 갤러리, VM 이미지 정의 및 VM 이미지 버전을 지정하여 주 지역에서 만든 VM 이미지 버전을 복사할 수 있습니다. Azure는 이미지를 복사하고 로컬 VM 이미지 버전을 만듭니다. 아래 설명된 대로 Azure Portal 또는 Azure CLI 명령을 사용하여 이 작업을 실행할 수 있습니다.

  이미지 정의 및 이미지 버전을 만듭니다.

  az sig image-version create

• 보조 재해 복구 위치의 모든 세션 호스트 VM이 항상 활성 상태로 실행 중이어야 하는 것은 아닙니다. 처음에는 충분한 수의 VM을 만들어야 하며, 그 후에는 크기 조정 계획과 같은 자동 크기 조정 메커니즘을 사용해야 합니다. 이러한 메커니즘을 사용하면 대부분의 컴퓨팅 리소스를 오프라인 또는 할당 취소된 상태로 유지 관리하여 비용을 절감할 수 있습니다.

• 자동화를 사용하여 필요한 경우에만 보조 지역에 세션 호스트를 만들 수도 있습니다. 이 방법은 비용을 최적화하지만 사용하는 메커니즘에 따라 더 긴 RTO가 필요할 수 있습니다. 이 방법은 새 배포 없이 장애 조치(failover) 테스트를 허용하지 않으며 특정 사용자 그룹에 대한 선택적 장애 조치(failover)를 허용하지 않습니다.

• 보조 지역의 세션 호스트를 오프라인 또는 할당 취소된 상태로 설정해도 주 지역 전체 재해가 발생하는 경우 용량을 사용할 수 있다고 보장하지는 않습니다. 또한 필요할 때 새 세션 호스트가 주문형으로 배포되고 Site Recovery 사용량이 있는 경우에도 적용됩니다. 컴퓨팅 용량은 관련 리소스가 이미 할당되고 활성 상태인 경우에만 보장할 수 있습니다.

Cloud Cache 사용 시나리오의 경우 관리 디스크에 프리미엄 계층을 사용하는 것이 좋습니다.

스토리지

이 가이드에서는 각 Virtual Desktop 호스트 풀에 대해 별도 스토리지 계정을 두 개 이상 사용합니다. 하나는 FSLogix 프로필 컨테이너용이고 다른 하나는 Office 컨테이너 데이터용입니다. 또한 MSIX 패키지에 대한 스토리지 계정도 하나 더 필요합니다. 고려 사항은 다음과 같습니다.

• Azure Files 공유 및 Azure NetApp Files를 스토리지 대안으로 사용할 수 있습니다. 옵션을 비교하려면 FSLogix 컨테이너 스토리지 옵션을 참조 하세요.
• Azure Files 공유는 지역에서 사용할 수 있는 경우 ZRS(영역 중복 스토리지) 복원력 옵션을 사용하여 영역 복원력을 제공할 수 있습니다.
• 다음과 같은 상황에서는 지역 중복 스토리지 기능을 사용할 수 없습니다.
  • 쌍이 없는 지역이 필요합니다. 지역 중복 스토리지에 대한 지역 쌍은 고정되어 있으며 변경할 수 없습니다.
  • 프리미엄 계층을 사용하고 있습니다.
• RPO 및 RTO가 FSLogix Cloud Cache 메커니즘에 비해 더 높습니다.
• 프로덕션 환경에서 장애 조치 및 장애 복구(failback)를 테스트하는 것은 쉽지 않습니다.
• Azure NetApp Files에는 다음과 같은 더 많은 고려 사항이 필요합니다.
  • 영역 중복은 아직 사용할 수 없습니다. 복원력 요구 사항이 성능보다 더 중요한 경우 Azure Files 공유를 사용합니다.
  • Azure NetApp Files는 영역일 수 있습니다. 즉, 고객이 할당할 (단일) Azure 가용성 영역을 결정할 수 있습니다.
  • 영역 간 복제 는 영역 복원력을 제공하기 위해 볼륨 수준에서 설정할 수 있지만 복제는 비동기적으로 수행되며 수동 장애 조치(failover)가 필요합니다. 이 프로세스에는 0보다 큰 RPO(복구 지점 목표) 및 RTO(복구 시간 목표)가 필요합니다. 이 기능을 사용하기 전에 영역 간 복제에 대한 요구 사항 및 고려 사항을 검토합니다.
  • 표준 네트워킹 기능이 사용되는 경우 영역 중복 VPN 및 ExpressRoute 게이트웨이에서 Azure NetApp Files를 사용할 수 있으며, 네트워킹 복원력에 사용할 수 있습니다. 자세한 내용은 지원되는 네트워크 토폴로지를 참조하세요.
  • Azure Virtual WAN은 Azure NetApp Files 표준 네트워킹과 함께 사용할 때 지원됩니다. 자세한 내용은 지원되는 네트워크 토폴로지를 참조하세요.
• Azure NetApp Files에는 지역 간 복제 메커니즘이 있습니다. 다음 고려 사항이 적용됩니다.
  • 일부 지역에서 사용할 수 없습니다.
  • Azure NetApp Files 볼륨 지역 쌍의 지역 간 복제는 Azure Storage 지역 쌍과 다를 수 있습니다.
  • 영역 간 복제와 동시에 사용할 수 없습니다.
  • 장애 조치(failover)는 투명하지 않으며 장애 복구(failback)에는 스토리지 재구성이 필요합니다.
• 제한
  • 크기, IOPS(초당 입력/출력 작업 수), Azure Files 공유 및 Azure NetApp Files 스토리지 계정 및 볼륨 모두에 대한 대역폭 MBps에 제한이 있습니다. 필요한 경우 FSLogix의 그룹별 설정을 사용하여 Virtual Desktop의 동일한 호스트 풀에 둘 이상을 사용할 수 있습니다. 그러나 이 구성에는 더 많은 계획과 구성이 필요합니다.

MSIX 애플리케이션 패키지에 사용하는 스토리지 계정은 프로필 및 Office 컨테이너에 대한 다른 계정과 구별되어야 합니다. 다음 지리적 재해 복구 옵션을 사용할 수 있습니다.

• 주 지역의 지역 중복 스토리지가 활성화되지 않은 모든 스토리지 계정
  • 보조 지역은 고정되어 있습니다. 스토리지 계정 장애 조치가 있는 경우 이 옵션은 로컬 액세스에 적합하지 않습니다.
• 주 지역과 보조 지역에 하나씩 별도의 스토리지 계정 두 개(권장)
  • 적어도 주 지역에 영역 중복 스토리지를 사용합니다.
  • 각 지역의 각 호스트 풀에는 대기 시간이 짧은 MSIX 패키지에 대한 로컬 스토리지 액세스 권한이 있습니다.
  • 두 위치에서 MSIX 패키지를 두 번 복사하고 두 호스트 풀에서 패키지를 두 번 등록합니다. 애플리케이션 그룹에 사용자를 두 번 할당합니다.

FSLogix

다음 FSLogix 구성 및 기능을 사용하는 것이 좋습니다.

• 프로필 컨테이너 콘텐츠에 별도의 BCDR 관리가 있어야 하고 Office 컨테이너와 다른 요구 사항이 있는 경우 분할해야 합니다.

  • Office 컨테이너에는 재해가 발생한 경우 원본에서 다시 작성하거나 다시 채워질 수 있는 캐시된 콘텐츠만 있습니다. Office 컨테이너를 사용하면 백업을 유지할 필요가 없으므로 비용을 줄일 수 있습니다.
  • 다른 스토리지 계정을 사용하는 경우 프로필 컨테이너에서만 백업을 사용하도록 설정할 수 있습니다. 또는 보존 기간, 사용된 스토리지, 빈도 및 RTO/RPO와 같은 다른 설정이 있어야 합니다.

• 클라우드 캐시는 기본 스토리지 복제 메커니즘을 사용하지 않고 여러 프로필 스토리지 위치를 지정하고 프로필 데이터를 비동기적으로 복제할 수 있는 FSLogix 구성 요소입니다. 첫 번째 스토리지 위치가 실패하거나 연결할 수 없는 경우 Cloud Cache는 자동으로 장애 조치하여 보조 스토리지를 사용하고 복원력 계층을 효과적으로 추가합니다. 클라우드 캐시를 사용하여 기본 및 보조 지역의 서로 다른 스토리지 계정 간에 프로필 및 Office 컨테이너를 모두 복제합니다.

  

• 세션 호스트 VM 레지스트리에서 프로필 컨테이너에 대해 한 번, Office 컨테이너에 대해 한 번, 클라우드 캐시를 두 번 사용하도록 설정해야 합니다. Office 컨테이너에 대해 클라우드 캐시를 사용하도록 설정하지 않을 수 있지만, 사용하도록 설정하지 않으면 장애 조치와 장애 복구(failback)가 있는 경우 주 및 보조 재해 복구 지역 간에 데이터가 잘못 정렬될 수 있습니다. 프로덕션 환경에서 사용하기 전에 이 시나리오를 신중하게 테스트하세요.

• 클라우드 캐시는 프로필 분할 및 그룹별 설정과 호환됩니다. 그룹별로 Active Directory 그룹 및 멤버 자격을 신중하게 디자인하고 계획해야 합니다. 모든 사용자가 정확히 하나의 그룹에 속하고 해당 그룹이 호스트 풀에 대한 액세스 권한을 부여하는 데 사용되는지 확인해야 합니다.

• 보조 재해 복구 지역의 호스트 풀에 대한 레지스트리에 지정된 CCDLocations 매개 변수는 주 지역의 설정과 비교하여 순서대로 되돌려집니다. 자세한 내용은 자습서: 프로필 컨테이너 또는 Office 컨테이너를 여러 공급자로 리디렉션하도록 클라우드 캐시 구성을 참조하세요.

  팁

  이 문서에서는 특정 시나리오에 중점을 둡니다. 추가 시나리오는 FSLogix의 고가용성 옵션 및 FSLogix에 대한 비즈니스 연속성 및 재해 복구 옵션에 설명되어 있습니다.

다음 예제에서는 클라우드 캐시 구성 및 관련 레지스트리 키를 보여 줍니다.

주 지역 = 북유럽

• 프로필 컨테이너 스토리지 계정 URI = \northeustg1\profiles

  • 레지스트리 키 경로 = HKEY_LOCAL_MACHINE > SOFTWARE > FSLogix > Profiles
  • CCDLocations value = type=smb,connectionString=\northeustg1\profiles;type=smb,connectionString=\westeustg1\profiles

  참고

  이전에 FSLogix 템플릿을 다운로드한 경우 Active Directory 그룹 정책 관리 콘솔을 통해 동일한 구성을 얻을 수 있습니다. FSLogix에 대한 그룹 정책 개체를 설정하는 방법에 대한 자세한 내용은 FSLogix 그룹 정책 템플릿 파일 사용 가이드를 참조하세요.

  

• Office 컨테이너 스토리지 계정 URI = \northeustg2\odcf

  • 레지스트리 키 경로 = HKEY_LOCAL_MACHINE > SOFTWARE >Policy > FSLogix > ODFC

  • CCDLocations value = type=smb,connectionString=\northeustg2\odfc;type=smb,connectionString=\westeustg2\odfc

    

보조 지역 = 서유럽

• 프로필 컨테이너 스토리지 계정 URI = \westeustg1\profiles
  • 레지스트리 키 경로 = HKEY_LOCAL_MACHINE > SOFTWARE > FSLogix > Profiles
  • CCDLocations value = type=smb,connectionString=\westeustg1\profiles;type=smb,connectionString=\northeustg1\profiles
• Office 컨테이너 스토리지 계정 URI = \westeustg2\odcf
  • 레지스트리 키 경로 = HKEY_LOCAL_MACHINE > SOFTWARE >Policy > FSLogix > ODFC
  • CCDLocations value = type=smb,connectionString=\westeustg2\odfc;type=smb,connectionString=\northeustg2\odfc

클라우드 캐시 복제

클라우드 캐시 구성 및 복제 메커니즘은 데이터 손실을 최소화하면서 서로 다른 지역 간에 프로필 데이터 복제를 보장합니다. 하나의 프로세스에서만 동일한 사용자 프로필 파일을 ReadWrite 모드로 열 수 있으므로 동시 액세스를 피해야 합니다. 따라서 사용자는 두 호스트 풀에 대한 연결을 동시에 열지 않아야 합니다.

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

데이터 흐름

1. Virtual Desktop 사용자가 Virtual Desktop 클라이언트를 시작하고 주 지역 호스트 풀에 할당된 게시된 데스크톱 또는 원격 앱 애플리케이션을 엽니다.

2. FSLogix는 사용자 프로필 및 Office 컨테이너를 검색한 다음 주 지역에 있는 스토리지 계정에서 기본 스토리지 VHD/X를 탑재합니다.

3. 동시에 클라우드 캐시 구성 요소는 주 지역의 파일과 보조 지역의 파일 간의 복제를 초기화합니다. 이 프로세스의 경우 주 지역의 클라우드 캐시는 이러한 파일에 대한 단독 읽기-쓰기 잠금을 획득합니다.

4. 이제 동일한 Virtual Desktop 사용자가 보조 지역 호스트 풀에 할당된 다른 게시된 애플리케이션을 시작하려고 합니다.

5. 보조 지역의 Virtual Desktop 세션 호스트에서 실행되는 FSLogix 구성 요소는 로컬 스토리지 계정에서 사용자 프로필 VHD/X 파일을 탑재하려고 시도합니다. 그러나 이러한 파일은 주 지역의 Virtual Desktop 세션 호스트에서 실행되는 클라우드 캐시 구성 요소가 잠그기 때문에 탑재에 실패합니다.

6. 기본 FSLogix 및 클라우드 캐시 구성에서는 사용자가 로그인할 수 없으며 FSLogix 진단 로그 ERROR_LOCK_VIOLATION 33 (0x21)에서 오류가 추적됩니다.

   

ID

Virtual Desktop의 가장 중요한 종속성 중 하나는 사용자 ID의 가용성입니다. 세션 호스트에서 전체 원격 가상 데스크톱 및 원격 앱에 액세스하려면 사용자가 인증할 수 있어야 합니다. Microsoft Entra ID는 이 기능을 사용하도록 설정하는 Microsoft의 중앙 집중식 클라우드 ID 서비스입니다. Microsoft Entra ID는 항상 Virtual Desktop에 대한 사용자를 인증하는 데 사용됩니다. 세션 호스트는 AD DS(Active Directory 도메인 Services) 또는 Microsoft Entra Domain Services를 사용하여 동일한 Microsoft Entra 테넌트 또는 Active Directory 도메인에 조인할 수 있으므로 유연한 구성 옵션을 선택할 수 있습니다.

• Microsoft Entra ID

  • 고가용성을 갖춘 글로벌 다중 지역 및 복원력 있는 서비스입니다. 이 컨텍스트에서는 Virtual Desktop BCDR 계획의 일부로 다른 작업이 필요하지 않습니다.

• Active Directory Domain Services

  • 지역 전체 재해가 발생하더라도 Active Directory 도메인 Services가 복원력 있고 고가용성이 되도록 하려면 주 Azure 지역에 둘 이상의 DC(도메인 컨트롤러)를 배포해야 합니다. 이러한 도메인 컨트롤러는 가능하면 다른 가용성 영역에 있어야 하며, 보조 지역 및 결국 온-프레미스의 인프라를 사용하여 적절한 복제를 보장해야 합니다. 글로벌 카탈로그 및 DNS 역할을 사용하여 보조 지역에 도메인 컨트롤러를 한 개 이상 만들어야 합니다. 자세한 내용은 Azure 가상 네트워크에서 AD DS(Active Directory 도메인 Services) 배포를 참조하세요.

• Microsoft Entra Connect

  • Active Directory 도메인 Services에서 Microsoft Entra ID를 사용한 다음 Microsoft Entra Connect를 사용하여 Active Directory 도메인 Services와 Microsoft Entra ID 간에 사용자 ID 데이터를 동기화하는 경우 영구 재해로부터 보호하기 위해 이 서비스의 복원력과 복구를 고려해야 합니다.

  • 보조 지역에 서비스의 두 번째 인스턴스를 설치하여 고가용성 및 재해 복구를 제공하고 준비 모드를 사용하도록 설정할 수 있습니다.

  • 복구가 있는 경우 관리자는 보조 인스턴스를 준비 모드에서 전환하여 승격해야 합니다. 서버를 준비 모드로 전환하는 것과 동일한 절차를 따라야 합니다. 이 구성을 수행하려면 Microsoft Entra 전역 관리자 자격 증명이 필요합니다.

    

• Microsoft Entra Domain Services

  • 일부 시나리오에서는 Microsoft Entra Domain Services를 Active Directory 도메인 Services의 대안으로 사용할 수 있습니다.
  • 고가용성을 제공합니다.
  • 지리적 재해 복구가 시나리오의 범위에 있는 경우 복제본 세트를 사용하여 보조 Azure 지역에 다른 복제본을 배포해야 합니다. 이 기능을 사용하여 주 지역에서 고가용성을 높일 수도 있습니다.

아키텍처 다이어그램

개인 호스트 풀

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

풀링된 호스트 풀

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

장애 조치(failover) 및 장애 복구(failback)

개인 호스트 풀 시나리오

프로필 및 Office 컨테이너에 사용되는 클라우드 캐시 및 외부 스토리지가 없으므로 개인 호스트 풀에 대한 장애 조치 및 장애 복구는 다릅니다. FSLogix 기술을 사용하여 세션 호스트의 컨테이너에 데이터를 저장할 수 있습니다. 재해 복구 지역에는 보조 호스트 풀이 없으므로 복제 및 정렬을 위해 더 많은 작업 영역 및 Virtual Desktop 리소스를 만들 필요가 없습니다. Site Recovery를 사용하여 세션 호스트 VM을 복제할 수 있습니다.

여러 시나리오에서 Site Recovery를 사용할 수 있습니다. Virtual Desktop의 경우 Azure Site Recovery의 Azure 간 재해 복구 아키텍처를 사용합니다.

다음 고려 사항 및 권장 사항이 적용됩니다.

• Site Recovery 장애 조치는 자동이 아니므로, 관리자가 Azure Portal 또는 Powershell/API를 사용하여 트리거해야 합니다.
• PowerShell을 사용하여 전체 Site Recovery 구성 및 작업을 스크립팅하고 자동화할 수 있습니다.
• Site Recovery에는 SLA(서비스 수준 계약) 내에 선언된 RTO가 있습니다. 대부분의 경우 Site Recovery는 몇 분 내에 VM을 장애 조치합니다.
• Site Recovery는 Azure Backup과 함께 사용할 수 있습니다. 자세한 내용은 Azure Backup과 함께 Site Recovery 사용 지원을 참조하세요.
• Virtual Desktop 포털 환경에 직접 통합이 없으므로 VM 수준에서 Site Recovery를 사용하도록 설정해야 합니다. 또한 단일 VM 수준에서 장애 조치 및 장애 복구를 트리거해야 합니다.
• Site Recovery는 일반 Azure VM을 위한 별도의 서브넷에 테스트 장애 조치 기능을 제공합니다. 두 개의 동일한 Virtual Desktop 세션 호스트가 동시에 서비스 컨트롤 플레인을 호출하므로 Virtual Desktop VM에는 이 기능을 사용하지 마세요.
• Site Recovery는 복제하는 동안 Virtual Machine 확장을 유지 관리하지 않습니다. Virtual Desktop 세션 호스트 VM에 사용자 지정 확장을 사용하도록 설정하는 경우 장애 조치(failover) 또는 장애 복구(failback) 후 확장을 다시 사용하도록 설정해야 합니다. Virtual Desktop 기본 제공 확장 joindomain 및 Microsoft.PowerShell.DSC는 세션 호스트 VM을 만든 경우에만 사용됩니다. 첫 번째 장애 조치 후 손실되어도 안전합니다.
• Azure 지역 간 Azure VM 재해 복구에 대한 지원 매트릭스를 검토하고 Site Recovery의 Azure 간 재해 복구 시나리오에 대한 요구 사항, 제한 사항 및 호환성 매트릭스 특히, 지원되는 OS 버전을 확인해야 합니다.
• VM을 한 지역에서 다른 지역으로 장애 조치할 경우 VM은 대상 재해 복구 지역에서 보호되지 않는 상태로 시작됩니다. 장애 복구가 가능하지만 사용자는 보조 지역의 VM을 다시 보호한 다음 주 지역으로 다시 복제를 사용하도록 설정해야 합니다.
• 장애 조치 및 장애 복구 절차에 대한 정기적인 테스트를 실행합니다. 그런 다음 특정 Virtual Desktop 환경에 따라 단계 및 복구 작업의 정확한 목록을 문서화합니다.

풀링된 호스트 풀 시나리오

활성-활성 재해 복구 모델의 원하는 특징 중 하나는 가동 중단이 있는 경우 서비스를 복구하는 데 관리자가 필요가 없다는 것입니다. 장애 조치 절차는 활성-수동 아키텍처에서만 필요해야 합니다.

활성-수동 모델에서 보조 재해 복구 지역은 최소한의 리소스가 구성되고 활성 상태인 유휴 상태여야 합니다. 구성은 주 지역에 맞게 유지되어야 합니다. 장애 조치가 있는 경우 보조 재해 복구 호스트 풀의 원격 앱에 대한 모든 데스크톱 및 애플리케이션 그룹에 사용자가 모두 동시에 다시 할당됩니다.

활성-활성 모델 및 부분 장애 조치가 있을 수 있습니다. 호스트 풀이 데스크톱 및 애플리케이션 그룹을 제공하는 데만 사용되는 경우 여러 비오버링 Active Directory 그룹의 사용자를 분할하고 기본 또는 보조 재해 복구 호스트 풀의 데스크톱 및 애플리케이션 그룹에 그룹을 다시 할당할 수 있습니다. 사용자는 두 호스트 풀에 동시에 액세스할 수 없어야 합니다. 애플리케이션 그룹 및 애플리케이션이 여러 개 있는 경우 사용자를 할당하는 데 사용하는 사용자 그룹이 겹칠 수 있습니다. 이 경우 활성-활성 전략을 구현하기가 어렵습니다. 사용자가 기본 호스트 풀에서 원격 앱을 시작할 때마다 세션 호스트 VM에서 FSLogix가 사용자 프로필을 로드합니다. 보조 호스트 풀에서 동일한 작업을 수행하려고 하면 기본 프로필 디스크에서 충돌이 발생할 수 있습니다.

초기 상황 및 구성 가정은 다음과 같습니다.

• 주 지역 및 보조 재해 복구 지역의 호스트 풀은 구성 중에 클라우드 캐시를 포함하여 정렬됩니다.
• 호스트 풀에서는 DAG1 데스크톱과 APPG2 및 APPG3 원격 앱 애플리케이션 그룹이 모두 사용자에게 제공됩니다.
• 주 지역의 호스트 풀에서 Active Directory 사용자 그룹 GRP1, GRP2 및 GRP3은 DAG1, APPG2 및 APPG3에 사용자를 할당하는 데 사용됩니다. 이러한 그룹은 사용자 멤버 자격이 겹칠 수 있지만 여기에서는 모델이 전체 장애 조치와 함께 활성-수동을 사용하기 때문에 문제가 되지 않습니다.

다음 단계에서는 계획된 재해 복구 또는 계획되지 않은 재해 복구 후 장애 조치가 발생하는 시기를 설명합니다.

1. 기본 호스트 풀에서 애플리케이션 그룹 DAG1, APPG2 및 APPG3에 대한 그룹 GRP1, GRP2 및 GRP3에서 사용자 할당을 제거합니다.
2. 연결된 모든 사용자가 기본 호스트 풀에서 강제로 연결이 끊깁니다.
3. 동일한 애플리케이션이 구성된 보조 호스트 풀에서 그룹 GRP1, GRP2 및 GRP3을 사용하여 DAG1, APPG2 및 APPG3에 대한 사용자 액세스 권한을 부여해야 합니다.
4. 보조 지역의 호스트 풀 용량을 검토하여 조정합니다. 여기서는 자동 크기 조정 계획을 사용하여 세션 호스트에서 자동으로 전원을 켭니다. 필요한 리소스를 수동으로 시작할 수도 있습니다.

장애 복구 단계와 흐름은 비슷하며 전체 프로세스를 여러 번 실행할 수 있습니다. 클라우드 캐시 및 스토리지 계정 구성은 프로필 및 Office 컨테이너 데이터가 복제되도록 합니다. 장애 복구 전에 호스트 풀 구성 및 컴퓨팅 리소스가 복구되었는지 확인합니다. 스토리지 파트의 경우 주 지역에 데이터 손실이 있는 경우 Cloud Cache는 보조 지역 스토리지에서 프로필 및 Office 컨테이너 데이터를 복제합니다.

프로덕션 환경에 영향을 주지 않고 몇 가지 구성 변경으로 테스트 장애 조치 계획을 구현할 수도 있습니다.

• 프로덕션을 위해 Active Directory에서 몇 가지 새 사용자 계정을 만듭니다.
• GRP-TEST라는 새 Active Directory 그룹을 만들고 사용자를 할당합니다.
• GRP-TEST 그룹을 사용하여 DAG1, APPG2 및 APPG3에 대한 액세스 권한을 할당합니다.
• GRP-TEST 그룹의 사용자에게 애플리케이션을 테스트하도록 지침을 제공합니다.
• GRP-TEST 그룹을 사용하여 기본 호스트 풀에서 액세스 권한을 제거하고 보조 재해 복구 풀에 대한 액세스 권한을 부여하여 장애 조치 절차를 테스트합니다.

중요 권장 사항:

• PowerShell, Azure CLI 또는 사용 가능한 다른 API 또는 도구를 사용하여 장애 조치 프로세스를 자동화합니다.
• 전체 장애 조치 및 장애 복구 절차를 주기적으로 테스트합니다.
• 정기적인 구성 맞춤 검사를 수행하여 기본 및 보조 재해 지역의 호스트 풀이 동기화되어 있는지 확인합니다.

Backup

이 가이드에서는 프로필 컨테이너와 Office 컨테이너 간에 프로필 분할 및 데이터 분리가 있다고 가정합니다. FSLogix는 이 구성 및 별도의 스토리지 계정 사용을 허용합니다. 별도의 스토리지 계정에서는 다른 백업 정책을 사용할 수 있습니다.

• ODFC 컨테이너의 경우 콘텐츠가 Microsoft 365와 같은 온라인 데이터 저장소에서 다시 작성할 수 있는 캐시된 데이터만 나타내는 경우 데이터를 백업할 필요가 없습니다.

• Office 컨테이너 데이터를 백업해야 하는 경우 저렴한 스토리지 또는 다른 백업 빈도 및 보존 기간을 사용할 수 있습니다.

• 개인 호스트 풀 유형의 경우 세션 호스트 VM 수준에서 백업을 실행해야 합니다. 이 방법은 데이터가 로컬로 저장된 경우에만 적용됩니다.

• OneDrive 및 알려진 폴더 리디렉션을 사용하는 경우 컨테이너 내에 데이터를 저장해야 하는 요구 사항이 필요 없게 될 수 있습니다.

  참고

  OneDrive 백업은 이 문서 및 시나리오에서 고려되지 않습니다.

• 다른 요구 사항이 없으면 주 지역의 스토리지에 대한 백업으로 충분해야 합니다. 재해 복구 환경의 백업은 일반적으로 사용되지 않습니다.

• Azure Files 공유의 경우 Azure Backup을 사용합니다.

  • 자격 증명 모음 복원력 유형의 경우 오프사이트 또는 지역 백업 스토리지가 필요하지 않으면 영역 중복 스토리지를 사용합니다. 이러한 백업이 필요한 경우 지역 중복 스토리지를 사용합니다.

• Azure NetApp Files는 자체 기본 제공 백업 솔루션을 제공합니다.

  • 요구 사항 및 제한 사항과 함께 지역 기능 가용성을 확인해야 합니다.

• 애플리케이션 패키지 리포지토리를 쉽게 다시 작성할 수 없는 경우 MSIX에 사용되는 별도의 스토리지 계정도 백업으로 처리해야 합니다.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

주요 작성자:

• Ben Martin Baur | 클라우드 솔루션 설계자
• Igor Pagliai | FTA(FastTrack for Azure) 수석 엔지니어

기타 기여자:

• Nelson Del Villar | 클라우드 솔루션 설계자, Azure Core 인프라
• Jason Martinez | 기술 문서 작성자

다음 단계

• Virtual Desktop 재해 복구 계획
• VIRTUAL Desktop용 BCDR - 클라우드 채택 프레임워크
• 복원력 및 가용성 생성을 위한 클라우드 캐시

관련 참고 자료

• 신뢰할 수 있는 Azure 애플리케이션 디자인
• 온-프레미스에 액세스하고 AD DS로 보호되는 Azure 파일
• 엔터프라이즈용 Virtual Desktop
• 재해 복구 기능이 있는 엔터프라이즈 파일 공유
• FSLogix 구성 예제