Azure Virtual Desktop のマルチリージョン事業継続とディザスター リカバリー (BCDR)

Azure Virtual Desktop は、Microsoft Azure 上で実行される包括的なデスクトップおよびアプリの仮想化サービスです。 Azure Virtual Desktop は、組織が事業の回復性を強化するのに役立つ、セキュリティで保護されたリモート デスクトップ エクスペリエンスを実現できます。 簡素化された管理、Windows 10 および 11 Enterprise のマルチセッション、Enterprise 向け Microsoft 365 アプリの最適化などを提供します。 Virtual Desktop を使用すると、Windows デスクトップとアプリを Azure 上に数分でデプロイおよびスケーリングでき、統合されたセキュリティとコンプライアンス機能により、アプリとデータを安全に維持できます。

Virtual Desktop を使用して組織のリモート作業を引き続き有効にする場合は、障害復旧 (DR) 機能とベスト プラクティスを理解することが重要です。 これらのプラクティスにより、リージョン間の信頼性が強化され、データの安全性と従業員の生産性の維持に役立っています。 このアーティクルでは、事業継続とディザスター リカバリー (BCDR) の前提条件、デプロイ ステップ、ベスト プラクティスに関する考慮事項について説明します。 オプション、戦略、アーキテクチャのガイダンスについて学習します。 このドキュメントの内容により、BCDR プランを成功させることができ、計画的および計画外のダウンタイム イベント中に事業の回復性を高めることができます。

障害と停止にはいくつかの種類があり、それぞれに異なる影響を与える可能性があります。 回復性と復旧では、ローカル イベントとリージョン全体イベントの両方について、異なるリモート Azure リージョンでのサービスの復旧を含めて、詳細に説明されています。 この種類の復旧は、”geo ディザスター リカバリー”と呼ばれます。 回復性と可用性のために Virtual Desktop アーキテクチャをビルドすることが重要です。 障害イベントの影響を減らすために、最大のローカル回復性を提供する必要があります。 この回復性により、復旧プロシージャを実行するための要件も減少します。 このアーティクルでは、高可用性とベスト プラクティスに関する情報も提供します。

ゴールとスコープ

このガイドのゴールを次に示します:

• 選択した重要なユーザー データのデータ損失を最小限に抑えながら、最大可用性、回復性、geo ディザスター リカバリー機能を確保します。
• 復旧時間を最小限に抑えます。

これらの目標は、回復ポイントの目標 (RPO) と復旧時間の目標 (RTO) とも呼ばれます。

提案されたソリューションは、ローカルの高可用性、単一の可用性ゾーンの障害からの保護、Azure リージョン全体の障害からの保護を提供します。 これは、サービスを復旧させるために、別の、またはセカンダリの Azure リージョンでの冗長デプロイに依存するものです。 それでも良いプラクティスですが、Virtual Desktop と BCDR をビルドするために使用される手法では、Azure リージョンを ペアにする 必要はありません。 プライマリとセカンダリの場所は、ネットワーク待機時間で許可されている場合、任意の Azure リージョンの組み合わせにすることができます。 複数の地理的リージョンで AVD ホスト プールを運用すると、BCDR に限定されない多くのメリットが得られます。

単一の可用性ゾーンの障害の影響を減らすには、回復性を使用して高可用性を向上させます。

• コンピューティングレイヤーで、Virtual Desktop セッション ホストをさまざまな可用性ゾーンに分散します。
• ストレージレイヤーでは、可能な限りゾーンの回復性を使用します。
• ネットワークレイヤーで、ゾーン回復性がある Azure ExpressRoute と仮想プライベート ネットワーク (VPN) ゲートウェイをデプロイします。
• 依存関係ごとに、単一ゾーン停止の影響をレビューし、軽減策を計画します。 たとえば、Virtual Desktop ユーザーがアクセスする Active Directory ドメイン コントローラーやその他の外部リソースを複数の可用性ゾーンにデプロイします。

使用する可用性ゾーンの数に応じて、1 つのゾーンの損失を補うためにセッション ホストの数を過剰プロビジョニングすることを考慮します。 たとえば、(n-1) ゾーンが使用可能な場合でも、ユーザー エクスペリエンスとパフォーマンスを確保できます。

一部のリージョンでは、種類、レプリケーション オプション、サービス機能、可用性の制限の組み合わせが考えられるため、ストレージ固有のレプリケーションメカニズムの代わりに FSLogix の Cloud Cache コンポーネントを使用することをお勧めします。

OneDrive はこのアーティクルでは扱っていません。 冗長性と高可用性の詳細については、「Microsoft 365でのデータの回復性の SharePoint と OneDrive」を参照してください。

このアーティクルの残りの部分では、2 つの異なる Virtual Desktop ホスト プールの種類のソリューションについて説明します。 このアーキテクチャを他のソリューションと比較できるように、観察も提供されています。

• 個人： この種類のホスト プールでは、ユーザーには永続的に割り当てられたセッション ホストがあり、決して変更されることはありません。 これは個人用であるため、この VM はユーザー データを保存できます。 レプリケーションとバックアップの手法を使用して状態を維持および保護することが前提です。
• プールされた： ユーザーには、デスクトップ アプリ グループを介して直接、またはリモート アプリを使用して、プールから使用可能なセッション ホスト VM の 1 つが一時的に割り当てられます。 VM はステートレスであり、ユーザー データとプロファイルは外部ストレージまたは OneDrive に保存されます。

コストへの影響について説明しますが、主なゴールは、データの損失を最小限に抑えながら、効果的な geo ディザスター リカバリーのデプロイを提供することです。 BCDR の詳細については、次のリソースを参照してください:

• Virtual Desktop に関する BCDR の考慮事項
• Azure Virtual Desktop のディザスター リカバリー

前提条件

コア インフラストラクチャをデプロイし、プライマリとセカンダリの Azure リージョンで使用できることを確認します。 ネットワーク トポロジに関するガイダンスについては、Azure クラウド導入フレームワーク ネットワーク トポロジと接続モデルを使用できます。

• 従来の Azure ネットワーク トポロジ
• Virtual WAN ネットワーク トポロジ (Microsoft 管理)

どちらのモデルでも、プライマリ Virtual Desktop ホスト プールとセカンダリ ディザスター リカバリー環境を異なるスポーク仮想ネットワーク内にデプロイし、同じリージョン内の各ハブに接続します。 プライマリの場所にハブを1つ、セカンダリの場所にハブを1つ配置し、その2つのハブ間で接続を確立します。

ハブは最終的に、オンプレミス リソース、ファイアウォール サービス、Active Directory ドメイン コントローラーなどの ID リソース、Log Analytics などの管理リソースへのハイブリッド接続を提供します。

セカンダリの場所にフェールオーバーされた場合は、基幹業務アプリと依存リソースの可用性を考慮する必要があります。

コントロール プレーンの事業継続性と障害復旧

停止時に顧客のメタデータを保持するために、Virtual Desktop は、コントロール プレーンに事業継続性と障害復旧機能を提供します。 Azure プラットフォームがこのデータとプロセスを管理するため、ユーザーは何も構成したり実行したりする必要はありません。

Virtual Desktop は、個々のコンポーネントの障害に対して耐性があり、障害から迅速に復旧できるように設計されています。 あるリージョンで停止が発生すると、サービス インフラストラクチャ コンポーネントはセカンダリの場所にフェイルオーバーされ、通常どおりに機能し続けます。 引き続きサービス関連のメタデータにアクセスでき、ユーザーは引き続き利用可能なホストに接続できます。 テナント環境やホストがアクセス可能な状態であれば、エンドユーザーとの接続はオンラインのままです。 Azure Virtual Desktop のデータの場所は、ホスト プール セッション ホスト仮想マシン (VM) デプロイの場所とは異なります。 サポートされているいずれかのリージョンで Virtual Desktop メタデータを検索し、別の場所に VM をデプロイできます。 詳細については、「Azure Virtual Desktop サービスのアーキテクチャと回復性」の記事を参照してください。

アクティブ/アクティブとアクティブ/パッシブの比較

ユーザーのセットごとに BCDR 要件が異なる場合は、Microsoftは、構成が異なる複数のホスト プールを使用することをお勧めします。 たとえば、ミッション クリティカルなアプリを持つユーザーは、geo ディザスター リカバリー機能を備えた完全冗長ホスト プールを割り当てることができます。 ただし、開発およびテストユーザーは、ディザスター リカバリーをまったく行わずに別のホスト プールを使用できます。

単一の Virtual Desktop ホスト プールごとに、BCDR 戦略をアクティブ/アクティブまたはアクティブ/パッシブ モデルに基づいて設定できます。 このシナリオでは、1 つの地理的な場所にある同じユーザー セットが特定のホスト プールによって提供されることを前提としています。

• アクティブ/アクティブ

  • プライマリ リージョンのホスト プールごとに、セカンダリ リージョンに 2 つ目のホスト プールをデプロイします。

  • この構成では RTO がほぼゼロになり、RPO には追加コストが発生します。

  • 管理者に介入またはフェールオーバーを要求する必要はありません。 通常の操作中、セカンダリ ホスト プールはユーザーに Virtual Desktop リソースを提供します。

  • 各ホスト プールには、永続的なユーザー プロファイル用の独自のストレージ アカウント (少なくとも 1 つ) があります。

  • ユーザーの物理的な場所と使用可能な接続性に基づいて、待機時間を考慮する必要があります。 西ヨーロッパや北ヨーロッパなどの一部の Azure リージョンでは、プライマリ リージョンまたはセカンダリ リージョンにアクセスする場合、その違いはごくわずかです。 このシナリオは、 Azure Virtual Desktop Experience Estimator というツールを使用して検証できます。

  • ユーザーは、プライマリ ホスト プールとセカンダリ ホスト プールの両方で、デスクトップ アプリケーション グループ (DAG) や RemoteApp アプリケーション グループ (RAG) などのさまざまなアプリケーショングループに割り当てられます。 このケースでは、Virtual Desktop クライアント フィードに重複するエントリが表示されます。 混乱を避けるために、各リソースの目的を反映するクリアな名前とラベルを持つ個別の Virtual Desktop ワークスペースを使用します。 これらのリソースの使用状況についてユーザーに通知します。

    

  • FSLogix プロファイルと ODFC コンテナーを個別に管理するためのストレージが必要な場合は、Cloud Cache を使用して RPO をほぼゼロにします。

    • プロファイルの競合を回避するために、ユーザーが両方のホスト プールに同時にアクセスすることを許可しないようにします。
    • このシナリオのアクティブ/アクティブの性質上、これらのリソースを適切な手順で使用する方法についてユーザーを教育する必要があります。

• アクティブ/パッシブ
  • アクティブ/アクティブと同様に、プライマリ リージョンのホスト プールごとに、セカンダリ リージョンに 2 つ目のホスト プールをデプロイします。
  • セカンダリ リージョンでアクティブなコンピューティング リソースの量は、使用できる予算に応じて、プライマリ リージョンと比較し削減されます。 自動スケーリングを使用してコンピューティング容量を増やすことができますが、より多くの時間が必要であり、Azure の容量は保証されません。
  • この構成では、アクティブ/アクティブ方法と比較して RTO が高くなりますが、コストは低くなります。
  • Azure に停止が発生した場合、フェールオーバー手順を実行するために管理者の介入が必要です。 セカンダリ ホスト プールは、通常、ユーザーに Virtual Desktop リソースへのアクセスを提供しません。
  • 各ホスト プールには、永続的なユーザー プロファイル用の独自のストレージ アカウントがあります。
  • 最適な待機時間とパフォーマンスで Virtual Desktop サービスを使用するユーザーは、Azure の停止が発生した場合にのみ影響を受けます。 このシナリオは、 Azure Virtual Desktop Experience Estimator というツールで検証する必要があります。 セカンダリ ディザスター リカバリー環境では、パフォーマンスが低下した場合でも、パフォーマンスを許容する必要があります。
  • ユーザーは、デスクトップ アプリやリモート アプリなど、1 セットのアプリケーション グループにのみ割り当てられます。 通常の操作中、これらのアプリはプライマリ ホスト プールにあります。 停止時およびフェールオーバー後、ユーザーはセカンダリ ホスト プール内のアプリ グループに割り当てられます。 ユーザーの Virtual Desktop クライアント フィードには重複するエントリは表示されず、同じワークスペースを使用でき、すべてが透明化されています。
  • FSLogix プロファイルと Office コンテナーを管理するためにストレージが必要な場合は、Cloud Cache を使用して RPO をほぼゼロにします。
    • プロファイルの競合を回避するために、ユーザーが両方のホスト プールに同時にアクセスすることを許可しないようにします。 このシナリオはアクティブ/パッシブであるため、管理者はアプリグループ レベルでこのビヘイビアーを適用できます。 フェールオーバー プロシージャの後でのみ、ユーザーはセカンダリ ホスト プールの各アプリ グループにアクセスできます。 プライマリ ホスト プール アプリ グループでアクセスが取り消され、セカンダリ ホスト プール内のアプリ グループに再割り当てされます。
    • すべてのアプリ グループに対してフェールオーバーを実行します。そうしないと、異なるホスト プール内の異なるアプリ グループを使用しているユーザーが、効果的に管理されていない場合にプロファイルの競合が発生する場合があります。
  • ユーザーの特定のサブセットが選択的にセカンダリ ホスト プールにフェールオーバーし、限られたアクティブ/アクティブ ビヘイビアーとテスト フェールオーバー機能を提供できるようになります。 特定のアプリ グループをフェールオーバーすることもできますが、異なるホスト プールのリソースを同時に使用しないようにユーザーを教育する必要があります。

特定の状況では、異なるリージョンにあるセッション ホストが混在する単一のホスト プールを作成できます。 このソリューションの利点は、単一のホスト プールがある場合、デスクトップ アプリとリモート アプリの定義と割り当てを複製する必要が無いということです。 残念ながら、共有ホスト プールの災害復旧にはいくつかの欠点があります。

• プールされたホスト プールの場合、ユーザーを同じリージョン内のセッション ホストに強制することはできません。
• リモート リージョンのセッション ホストに接続すると、ユーザーの待機時間が長く、パフォーマンスが最適でない場合があります。
• ユーザー プロファイルのストレージが必要な場合は、プライマリ リージョンとセカンダリ リージョンのセッション ホストの割り当てを管理するための複雑な構成が必要になります。
• ドレイン モードを使用して、セカンダリ リージョンにあるセッション ホストへのアクセスを一時的に無効にできます。 しかし、このメソッドでは、より複雑で、管理オーバーヘッドが発生し、リソースの使用も効率的ではありません。
• セカンダリ リージョンではセッション ホストをオフライン状態に維持できますが、複雑さと管理オーバーヘッドが発生します。

考慮事項と推奨事項

全般

複数のホスト プールと FSLogix クラウド キャッシュ メカニズムを使用してアクティブ/アクティブまたはアクティブ/パッシブのどちらかの構成をデプロイするには、モデルに応じて、同じワークスペース内または別のワークスペース内にホスト プールを作成します。 この方法では、配置と更新を維持し、両方のホスト プールを最新に保ち、同じ構成レベルにする必要があります。 セカンダリ ディザスター リカバリー リージョンの新しいホスト プールに加えて、次のことが必要です:

• 新しいホスト プールの新しい個別のアプリ グループと関連アプリを作成すること。
• プライマリ ホスト プールへのユーザー割り当てを取り消し、フェールオーバー中に手動で新しいホスト プールに再割り当てすること。

「FSLogix のビジネス継続性とディザスター リカバリーのオプション」を参照してください。

• プロファイルを回復しないについては、このドキュメントでは説明していません。
• クラウド キャッシュ (アクティブ/パッシブ) についてはこのドキュメントで説明していますが、同じホスト プールを使用して実装されています。
• クラウド キャッシュ (アクティブ/アクティブ) については、このドキュメントの残りの部分で説明します。

Virtual Desktop アーキテクチャの設計では、Virtual Desktop リソースの制限を考慮する必要があります。 Virtual Desktop サービスの制限に基づいて設計を検証します。

診断と監視には、プライマリ ホスト プールとセカンダリ ホスト プールの両方で同じ Log Analytics ワークスペースを使用することをお勧めします。 この設定を使用すると、Azure Virtual Desktop Insights は両方のリージョンでのデプロイの統合ビューを提供します。

ただし、プライマリ リージョン全体が使用できない場合は、単一のログの保存先を使用すると問題が発生する可能性があります。 セカンダリ リージョンでは、使用できないリージョンの Log Analytics ワークスペースを使用できません。 この状況が受け入れられない場合は、次の解決策を採用できます。

• 各リージョンに個別の Log Analytics ワークスペースを使用し、Virtual Desktop コンポーネントがローカル ワークスペースにログを記録するように指定します。
• Logs Analytics ワークスペースのレプリケーションとフェイルオーバー機能をテストして確認します。

Compute

• プライマリとセカンダリの障害復旧リージョンの両方のホスト プールをデプロイするには、セッション ホスト VM フリートを複数の可用性ゾーンに分散させる必要があります。 ローカル リージョンで可用性ゾーンを利用できない場合は、可用性セットを使用して、既定のデプロイメントよりもソリューションの回復性を高めることができます。

• セカンダリ ディザスター リカバリー リージョンでのホスト プールのデプロイに使用するゴールデン イメージは、プライマリに使用するイメージと同じである必要があります。 Azure Compute Gallery にイメージを保存し、プライマリとセカンダリの両方の場所に複数のイメージ レプリカを構成する必要があります。 各イメージ レプリカは、最大数の VM の並列デプロイを維持でき、必要なデプロイ バッチ サイズに基づいて複数の VM が必要になる場合があります。 詳細については、「Azure Compute Gallery でのイメージの保存と共有」を参照してください。

  

• Azure Compute Gallery はグローバル リソースではないため、 少なくともセカンダリ ギャラリーをセカンダリ リージョンに用意することをお勧めします。 プライマリ リージョンに、ギャラリー、VM イメージ定義、VM イメージ バージョンを作成したら、 セカンダリ リージョンにも同じオブジェクトを作成してください。 VM イメージバージョンを作成するときに、プライマリ リージョンで使用されるギャラリー、VM イメージ定義、VM イメージ バージョンを指定して、プライマ リリージョンに作成された VM イメージバージョンをコピーできます。 Azure によってイメージがコピーされ、ローカル VM イメージ バージョンが作成されます。 次に示すように、Azure portal または Azure CLI コマンドを使用して、この操作を実行できます。

  イメージ定義とイメージ バージョンを作成する

  az sig image-version create

• セカンダリー ディザスター リカバリーの場所にあるすべてのセッション ホスト VM が、常にアクティブで実行されている必要はありません。 最初は十分な数の VM を作成し、その後は、スケーリング プランなどのオートスケール メカニズムを使用する必要があります。 これらのメカニズムを使用すると、ほとんどのコンピューティング リソースをオフラインまたは割り当て解除状態に維持してコストを削減できます。

• 自動化を使用して、必要な場合にのみセカンダリ リージョンにセッション ホストを作成することもできます。 このメソッドではコストが最適化されますが、使用するメカニズムによっては、より長い RTO が必要になる場合があります。 この方法では、新しいデプロイを行わないフェールオーバー テストは許可されず、特定のユーザー グループに対する選択的フェールオーバーも許可されません。

• セカンダリ リージョンにセッション ホストがオフラインまたは 割り当て解除されている状態では、プライマリ リージョン全体の障害が発生した場合に容量が使用可能になるとは限りません。 また、必要に応じて新しいセッションをオンデマンドでデプロイし、Site Recovery を使用する場合にも適用されます。 コンピューティング容量は、関連するリソースがすでに割り当てられ、アクティブになっている場合にのみ保証されます。

Cloud Cache の使用シナリオでは、マネージド ディスクの Premium レベルを使用することをお勧めします。

Storage

このガイドでは、Virtual Desktop ホスト プールごとに少なくとも 2 つの個別のストレージ アカウントを使用します。 1 つは FSLogix プロファイル コンテナー用で、あと 1 つは Office コンテナー データ用です。 MSIX パッケージには、もう 1 つのストレージ アカウントも必要です。 次の考慮事項が適用されます。

• Azure Files 共有と Azure NetApp Files をストレージの代替手段として使用できます。 オプションを比較するには、「FSLogix コンテナー ストレージ オプション」を参照してください。
• Azure Files 共有では、ゾーン冗長ストレージ (ZRS) の回復性オプション (リージョンで使用可能な場合) を使用して、ゾーンの回復性を提供できます。
• 次の状況では、geo 冗長ストレージ機能を使用できません。
  • ペアでないリージョンが必要です。 geo 冗長ストレージのリージョン ペアは固定されており、変更することはできません。
  • Premium レベルを使用しています。
• RPO と RTO は、FSLogix Cloud Cache メカニズムに比べて高くなります。
• 運用環境でフェールオーバーとフェールバックをテストするのは簡単ではありません。
• Azure NetApp Files は、追加の考慮事項を必要とします。
  • ゾーン冗長はまだ使用できません。 回復性の要件がパフォーマンスよりも重要な場合は、Azure Files 共有を使用します。
  • Azure NetApp Files はゾーンベースにできます。つまり、どの (単一の) Azure 可用性ゾーンを割り当てるかを顧客が決定できます。
  • ゾーンの回復性を提供するためにボリューム レベルでゾーン間レプリケーションを確立できますが、レプリケーションは非同期で行われるため、手動のフェイルオーバーが必要になります。 このプロセスでは、ゼロより大きい回復ポイントの目標 (RPO) と復旧時間の目標 (RTO) が必要です。 この機能を使用する前に、ゾーン間レプリケーションの要件と考慮事項を確認してください。
  • 標準のネットワーク機能を使用している場合は、ネットワークの回復性のために使用できるゾーン冗長 VPN および ExpressRoute ゲートウェイで Azure NetApp Files を使用できます。 詳細については、「サポートされるネットワーク トポロジ」を参照してください。
  • Azure Virtual WAN は、Azure NetApp Files 標準ネットワークと併用する場合にサポートされます。 詳細については、「サポートされるネットワーク トポロジ」を参照してください。
• Azure NetApp Files にはリージョン間レプリケーション メカニズムがあり、 次の考慮事項が適用されます。
  • すべてのリージョンで利用できるわけではありません。
  • Azure NetApp Files ボリュームのリージョン ペアのリージョン間レプリケーションは、Azure Storage のリージョン ペアとは異なる場合があります。
  • ゾーン間レプリケーションと同時に使用することはできません。
  • フェイルオーバーは透明性がなく、フェイルバックにはストレージの再構成が必要です。
• 制限
  • Azure Files 共有と Azure NetApp Files ストレージ アカウントおよびボリュームには、サイズ、1 秒あたりの入出力操作数 (IOPS)、帯域幅 (MBps)に制限があります。 必要に応じて、FSLogix のグループごとの設定を使用して、Virtual Desktop の同じホスト プールに複数の設定を使用できます。 ただし、この構成には、より多くの計画と構成が必要です。

MSIX アプリケーション パッケージに使用するストレージ アカウントは、プロファイル コンテナー用と Office コンテナー用の他のアカウントとは異なるものにする必要があります。 次の Geo ディザスター リカバリー オプションを使用できます。

• プライマリリージョンに geo 冗長ストレージが有効になっている 1 つのストレージ アカウント
  • セカンダリ リージョンは固定されています。 ストレージ アカウントのフェールオーバーがある場合、このオプションはローカル アクセスには適していません。
• プライマリ リージョンに 1 つとセカンダリ リージョンに 1 つ (推奨) の 2 つの独立したストレージ アカウント
  • 少なくともプライマリ リージョンにはゾーン冗長ストレージを使用します。
  • 各リージョンの各ホスト プールには、待機時間が短い MSIX パッケージへのローカル ストレージ アクセスがあります。
  • 両方の場所で MSIX パッケージを 2 回コピーし、両方のホスト プールにパッケージを 2 回登録します。 ユーザーをアプリ グループに 2 回割り当てます。

FSLogix

Microsoft は、次の FSLogix の構成と機能を使用することをお勧めします。

• プロファイル コンテナー コンテンツに個別の BCDR 管理が必要で、Office コンテナーと比較して異なる要件がある場合、それらを分割する必要があります。

  • Office コンテナーには、障害が発生した場合にソースから再構築または再入力できるキャッシュされたコンテンツのみが含まれます。 Office コンテナーでは、バックアップを保持する必要がない場合があるため、コストを削減できます。
  • 異なるストレージ アカウントを使用する場合は、プロファイル コンテナーでのみバックアップを有効にできます。 または、保持期間、使用されるストレージ、頻度、RTO/RPO などの異なる設定が必要です。

• Cloud Cache は、FSLogix コンポーネントであり、基になるストレージ レプリケーション メカニズムに依存することなく、複数のプロファイル ストレージの場所を指定し、プロファイル データを非同期的にレプリケートできます。 最初のストレージの場所に障害が発生したり、到達できない場合、Cloud Cache は自動的にフェイルオーバーしてセカンダリを使用し、効果的に回復性レイヤーを追加します。 Cloud Cache を使用して、プライマリ リージョンとセカンダリ リージョンの異なるストレージ アカウント間で、プロファイル コンテナーとOffice コンテナーの両方をレプリケートします。

  

• セッション ホスト VM レジストリで Cloud Cache を 2 回有効にする必要があります。１回は プロファイル コンテナー用、もう１回は Office コンテナー用です。 Office コンテナーの Cloud Cache を有効にしないことも可能ですが、有効にしないとフェイルオーバーやフェイルバックがある場合、プライマリとセカンダリのディザスター リカバリー リージョン間でデータの不整合が発生する場合があります。 運用で使用する前に、このシナリオを慎重にテストしてください。

• Cloud Cache は、プロファイルの分割とグループごとの設定の両方と互換性があります。 グループごとに、Active Directory グループとメンバーシップの慎重な設計と計画が必要です。 すべてのユーザーが正確に 1 つのグループに属し、そのグループを使用してホスト プールへのアクセスを許可する必要があります。

• セカンダリ障害復旧リージョンのホスト プールのレジストリに指定された CCDLocations パラメーターは、プライマリ リージョンの設定と比較して順番に元に戻されます。 詳しくは、「チュートリアル: Profile コンテナーまたは Office コンテナーを複数のプロバイダーにリダイレクトするように Cloud Cache を構成する」を参照してください。

  ヒント

  この記事では、特定のシナリオに焦点を当てます。 追加のシナリオについては、FSLogix の高可用性オプションと FSLogix の事業継続性と障害復旧オプションで説明されています。

次の例は、Cloud Cache の構成と関連するレジストリ キーを示しています。

リージョン: 北ヨーロッパ

• プロファイル コンテナー ストレージ アカウント URI = \northeustg1\profiles

  • レジストリ キー パス = HKEY_LOCAL_MACHINE > SOFTWARE > FSLogix > Profiles
  • CCDLocations 値 = 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 値 = type=smb,connectionString=\northeustg2\odfc;type=smb,connectionString=\westeustg2\odfc

    

セカンダリ リージョン = 西ヨーロッパ

• プロファイル コンテナー ストレージ アカウント URI = \westeustg1\profiles
  • レジストリ キー パス = HKEY_LOCAL_MACHINE > SOFTWARE > FSLogix > Profiles
  • CCDLocations 値 = type=smb,connectionString=\westeustg1\profiles;type=smb,connectionString=\northeustg1\profiles
• Office コンテナー ストレージ アカウント URI = \westeustg2\odcf
  • レジストリ キー パス = HKEY_LOCAL_MACHINE > SOFTWARE >Policy> FSLogix > ODFC
  • CCDLocations 値 = type=smb,connectionString=\westeustg2\odfc;type=smb,connectionString=\northeustg2\odfc

Cloud Cache レプリケーション

Cloud Cache の構成とレプリケーションメカニズムにより、データ損失を最小限に抑えながら、異なるリージョン間のプロファイル データ レプリケーションが保証されます。 同じユーザー プロファイルのファイルは、1つのプロセスだけが ReadWrite モードで開くことができるため、同時アクセスは避ける必要があります。したがって、ユーザーは両方のホストプールへの接続を同時に開くことはできません。

このアーキテクチャの Visio ファイルをダウンロードします。

データフロー

1. Virtual Desktop ユーザーが Virtual Desktop クライアントを起動し、プライマリ リージョンのホスト プールに割り当てられた発行済みのデスクトップまたはリモート アプリ アプリケーションを開きます。

2. FSLogix は、ユーザー プロファイルとOffice コンテナーを取得し、プライマリ リージョンにあるストレージ アカウントから基になるストレージ VHD/X をマウントします。

3. 同時に、Cloud Cache コンポーネントは、プライマリ リージョン内のファイルとセカンダリ リージョン内のファイルの間のレプリケーションを初期化します。 このプロセスでは、プライマリ リージョンの Cloud Cache によって、これらのファイルに対する排他的な読み取り/書き込みロックが取得されます。

4. 同じ Virtual Desktop ユーザーが、セカンダリ リージョンのホスト プールに割り当てられた別の発行済みアプリを起動する必要があります。

5. セカンダリ リージョンの Virtual Desktop セッション ホストで実行されている FSLogix コンポーネントは、ローカル ストレージ アカウントからユーザー プロファイル VHD/X ファイルをマウントしようとします。 ただし、プライマリ リージョンの Virtual Desktop セッション ホストで実行されている Cloud Cache コンポーネントによってこれらのファイルがロックされているため、マウントは失敗します。

6. 既定の FSLogix と Cloud Cache の構成では、ユーザーはサインインできません。エラーは FSLogix 診断ログ ERROR_LOCK_VIOLATION 33 (0x21) で追跡されます。

   

ID

Virtual Desktop の最も重要な依存関係の 1 つは、ユーザー ID の可用性です。 セッション ホストから完全なリモート仮想デスクトップとリモート アプリにアクセスするには、ユーザーが認証できる必要があります。 Microsoft Entra ID は、この機能を実現する Microsoft の一元化されたクラウド ID サービスです。 Virtual Desktop のユーザー認証には、常に Microsoft Entra ID が使用されます。 セッション ホストは、同じ Microsoft Entra テナントに参加することも、Active Directory Domain Services (AD DS) または Microsoft Entra Domain Services を使って Active Directory ドメインに参加することもでき、柔軟な構成オプションを選択できます。

• Microsoft Entra ID

  • これは、高可用性を備えたグローバルなマルチリージョンおよび回復性のあるサービスです。 このコンテキストでは、Virtual Desktop BCDR プランの一部として他のアクションは必要ありません。

• Active Directory Domain Services

  • Active Directory Domain Service の回復性と可用性を高めるには、リージョン全体で障害が発生した場合でも、プライマリ Azure リージョンに少なくとも 2 つのドメイン コントローラー (DC) をデプロイする必要があります。 これらのドメイン コントローラーは、可能であれば異なる可用性ゾーンに配置する必要があり、セカンダリ リージョンと最終的にはオンプレミスのインフラストラクチャとの適切なレプリケーションを確保する必要があります。 グローバル カタログと DNS ロールを持つセカンダリ リージョンに、少なくとも 1 つ以上のドメイン コントローラーを作成する必要があります。 詳細については、「Azure 仮想ネットワークに Active Directory Domain Services (AD DS をデプロイする」を参照してください。

• Microsoft Entra Connect

  • Active Directory Domain Services で Microsoft Entra ID を使用しており、Microsoft Entra Connect を使用して Active Directory Domain Services と Microsoft Entra ID の間でユーザー ID データを同期している場合、永続的な障害から保護するために、このサービスの回復性と復旧を考慮する必要があります。

  • セカンダリ リージョンにサービスの 2 つ目のインスタンスをインストールし、 ステージング モードを有効にすることで、高可用性とディザスター リカバリーを提供できます。

  • 復旧がある場合、管理者はセカンダリ インスタンスをステージング モードから除外して昇格させる必要があります。 サーバーをステージング モードにするのと同じプロシージャに従う必要があります。 この構成を実行するには、Microsoft Entra グローバル管理者の資格情報が必要です。

    

• Microsoft Entra Domain Services

  • 一部のシナリオでは、Active Directory Domain Services の代わりに Microsoft Entra Domain Services を使用できます。
  • 高可用性を提供します。
  • geo ディザスター リカバリーがシナリオのスコープ内にある場合は、レプリカ セットを使用してセカンダリ Azure リージョンに別のレプリカをデプロイする必要があります。 この機能を使用して、プライマリ リージョンの高可用性を向上させることもできます。

アーキテクチャ図

個人用ホスト プール

このアーキテクチャの Visio ファイルをダウンロードします。

プールされたホスト プール

このアーキテクチャの Visio ファイルをダウンロードします。

フェールオーバーとフェールバック

個人用ホスト プールのシナリオ

個人用ホスト プールのフェールオーバーとフェールバックは異なります。プロファイル コンテナーと Office コンテナーに使用される Cloud Cache と外部ストレージがないためです。 FSLogix テクノロジーを引き続き使用して、セッション ホストからコンテナーにデータを保存できます。 ディザスター リカバリー リージョンにはセカンダリ ホスト プールがないため、レプリケートして配置するために、ワークスペースと Virtual Desktop リソースをさらに作成する必要はありません。 Site Recovery を使用して、セッション ホスト VM をレプリケートできます。

Site Recovery は、いくつかの異なるシナリオで使用できます。 Virtual Desktop については、「Azure Site Recovery における Azure から Azure へのディザスター リカバリー アーキテクチャ」を使用します。

次の考慮事項と推奨事項が適用されます。

• Site Recovery フェールオーバーは自動ではありません。管理者は、Azure portal または Powershell/API を使用してフェールオーバーをトリガーする必要があります。
• PowerShell を使用して、Site Recovery 構成と操作全体をスクリプト化して自動化できます。
• Site Recovery には、サービスレベル アグリーメント (SLA) 内で宣言された RTO があります。 ほとんどの場合、Site Recovery によって数分以内に VM がフェールオーバーされます。
• Azure Backup で Site Recovery を使用できます。 詳細については、「Azure Backup で Site Recovery を使用するためのサポート」を参照してください。
• Virtual Desktop ポータル エクスペリエンスには直接統合がないため、VM レベルで Site Recovery を有効にする必要があります。 また、単一の VM レベルでフェールオーバーとフェールバックをトリガーする必要もあります。
• Site Recovery は、一般的な Azure VM 用の別のサブネットでテスト フェールオーバー機能を提供します。 サービス コントロール プレーンを同時に呼び出す 2 つの同一の Virtual Desktop セッション ホストがあるため、Virtual Desktop VM にはこの機能を使用しないでください。
• Site Recovery では、レプリケーション中に仮想マシン拡張機能は維持されません。 Virtual Desktop セッション ホスト VM のカスタム拡張機能を有効にする場合は、フェールオーバーまたはフェールバック後に拡張機能を再度有効にする必要があります。 Virtual Desktop の組み込み拡張機能 joindomain と Microsoft.PowerShell.DSC は、セッション ホスト VM が作成されたときにのみ使用されます。 最初のフェールオーバー後に失っても安全です。
• Azure リージョン間の Azure VM ディザスター リカバリーのサポート マトリックスを必ずレビューし、Site Recovery Azure から Azure へのディザスター リカバリー シナリオ (特にサポートされている OS バージョン) の要件、制限事項、互換性マトリックスなどを確認してください。
• あるリージョンから別のリージョンに VM をフェールオーバーすると、その VM はターゲット ディザスター リカバリー リージョン内で保護されていない状態で起動されます。 フェールバックは可能ですが、ユーザーはセカンダリ リージョン内の VM を 再保護 し、プライマリ リージョンへのレプリケーションを有効にする必要があります。
• フェールオーバーとフェールバックのプロシージャの定期的なテストを実行します。 次に、特定の Virtual Desktop 環境に基づいて、ステップと復旧アクションの正確なリストを文書化します。

プールされたホスト プールのシナリオ

アクティブ/アクティブ ディザスター リカバリー モデルの望ましい特性の 1 つは、障害が発生した場合にサービスを復旧するために管理者の介入が必要ないということです。 フェールオーバー プロシージャは、アクティブ/パッシブ アーキテクチャでのみ必要です。

アクティブ/パッシブ モデルでは、セカンダリ障害復旧リージョンは、最小限のリソースが構成され、アクティブなアイドル状態である必要があります。 構成は、プライマリ リージョンに合わせて維持する必要があります。 フェールオーバーがある場合、セカンダリ ディザスター リカバリー ホスト プール内のリモート アプリのすべてのデスクトップ グループとアプリ グループへのすべてのユーザーの再割り当てが同時に行われます。

アクティブ/アクティブ モデルと部分フェールオーバーを使用できます。 ホスト プールがデスクトップ グループとアプリケーション グループの提供にのみ使用される場合は、重複しない複数の Active Directory グループ内のユーザーをパーティション分割し、プライマリまたはセカンダリの障害復旧ホスト プールのデスクトップ グループとアプリケーション グループにグループを再割り当てできます。 ユーザーは、両方のホスト プールに同時にアクセスすることはできません。 複数のアプリ グループとアプリがある場合、ユーザーの割り当てに使用するユーザー グループが重複する場合があります。 このケースでは、アクティブ/アクティブ戦略を実装することは困難です。 ユーザーがプライマリ ホスト プールでリモート アプリを起動するたびに、ユーザー プロファイルは FSLogix によってセッション ホスト VM に読み込まれます。 セカンダリ ホスト プールで同じ操作を実行しようとすると、基になるプロファイル ディスクで競合が発生する場合があります。

最初の状況と構成の前提条件を次に示します。

• プライマリ リージョンとセカンダリ ディザスター リカバリー リージョンのホスト プールは、Cloud Cache を含む構成中に配置されます。
• ホスト プールでは、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. セカンダリ リージョンのホスト プールの容量をレビューして調整します。 ここでは、セッション ホストの電源を自動的にオンにする自動スケール プランを利用することをお勧めします。 必要なリソースを手動で開始することもできます。

フェールバックのステップとフローは似ています。プロセス全体を複数回実行できます。 Cloud Cache とストレージ アカウントの構成により、プロファイルと 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 を使用します。

  • データ保管庫の回復性の種類については、オフサイトまたはリージョンのバックアップ ストレージが必要ない場合は、ゾーン冗長ストレージを使用します。 これらのバックアップが必要な場合は、geo 冗長ストレージを使用します。

• Azure NetApp Files は、独自の組み込みバックアップ ソリューションを提供します。

  • 要件と制限事項と共に、リージョンの機能の可用性を確認してください。

• アプリケーション パッケージ リポジトリを簡単に再構築できない場合は、MSIX に使用される個別のストレージ アカウントもバックアップの対象にする必要があります。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパルの作成者:

• Ben Martin Baur |クラウド ソリューション アーキテクト
• Igor Pagliai | FastTrack for Azure (FTA) プリンシパル エンジニア

その他の共同作成者:

• ネルソン・デル・ヴィラル |クラウド ソリューション アーキテクト、Azure Core インフラストラクチャ
• Jason Martinez | テクニカル ライター

次のステップ

• Virtual Desktop の障害復旧計画
• Virtual Desktop の BCDR - クラウド導入フレームワーク
• 回復性と可用性を実現するための Cloud Cache

関連リソース

• 信頼性の高い Azure アプリケーションを設計する
• オンプレミスでアクセスされ、AD DS によってセキュリティで保護される Azure ファイル
• エンタープライズ向け Virtual Desktop
• ディザスター リカバリーによるエンタープライズ ファイル共有
• FSLogix 構成の例