適切な災害復旧シナリオを識別する
広域の供給停止やデータセンターの故障による深刻な影響を限定的に留めるために、組織で適切なディザスター リカバリー保護を準備しなければなりません。 適切な保護戦略の設定は、主に Azure Virtual Desktop の機能に影響を与える可能性があるさまざまな故障シナリオに依存します。
目標とメトリック
ディザスター リカバリー プロセスでは、組織を完全な運用に戻すために実行される各手順間の調整が必要です。 これらの手順を正しくまとめるのは、共通の明確に定義されたサービス レベル目標の存在です。 ディザスター リカバリー (DR) サービスには、次のメトリックが含まれている必要があります。
- 復旧時点目標 (RPO): サービス復旧のためにクライアント向けに回復しなければならない必要最小限のデータ量で、これは復旧させることを想定してバックアップしたアセットをおおよそベースにしています。 逆の言い方では、この量を100 から減算した割合で示される量は、許容可能な最大のデータ損失量と考えられる可能性があります。
- 復旧時間目標 (RTO): 許容可能な最大の復旧プロセス実行時間長で、それはどのくらいのダウンタイムを組織が許容可能であるかの指標ともみなすことができます。
- 保持期間: バックアップ セットが次回更新され置換されるまで、保持されなければならない期間。
RPO と RTP は互いにバランス良く認識されなければなりませんので、顧客はより高い復旧時点を達成するためには、より長い復旧時間を許容することを判断することになります。 利用可能なバンド幅や、ダウンタイムのリスクによる復旧時間が問題になると、顧客が高い復旧時点目標を達成できないことがあります。
このユニットの残りの部分では、3 つの異なる故障シナリオと、Azure Virtual Desktop のビジネス継続性とディザスター リカバリー (BCDR) を準備する方法について説明します。
- シナリオ 1: データ、メタデータ、またはリソースのローカル破損
- シナリオ 2: Azure リージョン内における、可用性ゾーンの単一データセンターの故障
- シナリオ 3: Azure リージョンの機能停止
注:
Azure Virtual Desktop の個々のコンポーネントを保護する方法については、このモジュールのサマリーユニットにある "詳細情報" のセクションを参照してください。
シナリオ 1: データ、メタデータ、またはリソースのローカル破損
Azure Virtual Desktop 環境がセッション ホストエラーまたは FSLogix プロファイルの破損の影響を受けたと仮定しましょう。 このような場合、最も一般的な復旧方法は、バックアップからプロファイルを復元するか、セッション ホストを再構築することです。 このユニットでは、これらそれぞれの方法が各 Azure Virtual Desktop 環境のコンポーネントにどのように適用されるかを概観します。
Azure Virtual Desktop サービス
Azure Virtual Desktop サービスは引き続き完全に機能し、こうしたタイプの故障の影響を受けていません。 Microsoft は、提供したサービス レベル アグリーメント (SLA) 内ですべてをバックアップし稼働させる責任があります。
AD DS と Microsoft Entra Domain Services
Active Directory ドメイン コントローラーは、Azure Virtual Desktop に欠くことができないコンポーネントであり、常にアクセスできる必要があります。 故障が機能に影響しないことを確実にするために、複数のドメイン コントローラーを作成したことを確認して下さい。 Azure Virtual Machines にドメイン コントローラーがある場合は、それらを同じ可用性セットに構成していることを確認します。 ドメイン コントローラーがオンプレミスのコンピューターとして稼働している場合は、オンプレミス ネットワークと Azure 仮想ネットワークの間の接続について、冗長性を備えた設計にする必要があります。 Azure ExpressRoute を使用して、冗長パスと接続を管理します。 Active Directory システムの状態をバックアップし、必要に応じて復元します。 Microsoft Entra Domain Services を使用している場合、Microsoft は冗長ドメイン コントローラーを維持し、計画外の障害からそれらを保護する責任を負います。
ホスト プール
平常時の運用保守におけるホスト プールは、使用できなくなってしまう可能性があります。 ホスト プールは、Azure Virtual Desktop とアプリをユーザーに提供します。 これらはデスクトップ イメージから設定されるため、エラーが発生し、デスクトップ イメージが使用可能な場合は、それらを再作成できます。 Azure Virtual Desktop を介して使用されるアプリケーションには、離れたホスト プールを使用することもできます。 このホスト プールについても、同様のディザスター リカバリーのアプローチを検討する必要があります。
仮想ネットワーク
仮想ネットワークはマネージド サービスであり、このタイプの故障の影響を受けません。 Azure Virtual Network では、プライベート接続にてすべてのリソースを展開可能なプライベート IP ブロックが提供され、境界内でそれらのリソースのセキュリティを確保できます。 したがって、1 つのデータセンターのローカル リソースで障害が発生した場合でも、仮想ネットワークがダウンしたり、サービスが停止することはありません。
FSLogix プロファイルと MSIX アプリ アタッチ
FSLogix ストレージ テクノロジの選択に応じて、Azure Files 共有と Azure NetApp Files スナップショットに適した Azure Backup を構成できます。 または、バックアップ サービスを利用して、サーバー VM 上のファイルとフォルダーを保護することもできます。
画像
多くの場合、Azure Virtual Desktop 環境の通常の運用保守の過程で、デスクトップ イメージに変更を加える場合があります。 破損が発生した場合に迅速に回復できるように、イメージのバックアップを維持する必要があります。
シナリオ 2: Azure リージョン内における、可用性ゾーンの単一データセンターの故障
Azure リージョンは、レイテンシが予め定められた境界内に展開され、リージョン専用の低レイテンシ ネットワークで接続された、データセンターのセットです。 Azure リージョンでデータセンターまたはゾーンが停止した場合、BCDR for Azure Virtual Desktop には、次のセクションに示す推奨事項を含める必要があります。
Azure Virtual Desktop サービス
Azure Virtual Desktop サービスは引き続き完全に機能し、このタイプの故障の影響を受けていません。 Microsoft は提示した SLA の範囲内で、すべてをバックアップし稼働させる責任があります。
AD DS と Microsoft Entra Domain Services
1 つのデータセンターの故障を回避するには、1 つの可用性ゾーン内に少なくとも 2 つのドメイン コントローラーを展開します。 Microsoft Entra Domain Services を使用している場合、テナントがリージョンでサポートされている場合、Microsoft はテナントの 2 つのドメイン コントローラーを別の可用性ゾーンで管理します。
ホスト プール
ホスト プール VM の回復性については、VM の可用性ゾーンを使用して Azure Virtual Desktop ホスト プールを展開することができます。 可用性ゾーンを使用することで、ホスト プール内の VM を、同じリージョン内ながら異なるデータセンターに分散させることができます。
仮想ネットワーク
仮想ネットワークはマネージド サービスであり、このタイプの故障の影響を受けません。 信頼できるリソースが常に適切なネットワーク接続で構成されていることを確認する必要があります。 たとえば、ベーシック ロード バランサーの使用ではゾーンの可用性が満たされていないため、このタイプの故障の影響を受ける可能性があります。
FSLogix プロファイルと MSIX アプリ アタッチ
Azure Files をプレミアム ゾーン冗長ストレージとともに使用して、可用性ゾーンのサポート力を利用します。 このシナリオでは、データセンターが停止した場合でも、FSLogix プロファイルと MSIX アプリ アタッチ VHD を引き続き使用できます。
画像
この種のエラーは、別のゾーンで使用可能になるため、イメージには影響しません。
シナリオ 3: Azure リージョンの機能停止
完全な Azure リージョンの障害は、可能性が非常に低く、まれです。 ただし、このような障害が発生した場合にも備える必要があります。 Azure Virtual Desktop に BCDR を導入するためには、次の推奨事項を実装することを検討してください。
Azure Virtual Desktop サービス
Azure Virtual Desktop サービスは依然として完全に機能し、このタイプの故障の影響を受けていません。 Microsoft は提示した SLA の範囲内で、すべてをバックアップし稼働させる責任があります。
AD DS と Microsoft Entra Domain Services
この種類の障害に備えて、マネージド ドメインを拡張して、Microsoft Entra テナントごとに複数のレプリカ セットを設定できます。 レプリカ セットは、Microsoft Entra Domain Services をサポートする任意の Azure リージョン内のピアリングされた仮想ネットワークに追加できます。
オンプレミス ドメイン コントローラーを使用する場合は、VPN、ExpressRoute、または仮想ワイド エリア ネットワーク (仮想 WAN) を使用して、新しいリージョンの仮想ネットワークへの接続を構成する必要があります。 Microsoft Entra Domain Services を使用する場合は、別のリージョンに追加のレプリカ セットを作成できます。 新しいレプリカ セットをホストする追加リージョンの仮想ネットワークは、Microsoft Entra Domain Services のプライマリ セットをホストするネットワークと通信できる必要があります。 レプリカ セット間のサイト内 レプリケーションには、仮想ネットワーク間のピアリングを使用することをお勧めします。
ホスト プール
アクティブ/アクティブおよびアクティブ/パッシブ構成で Azure Virtual Desktop ホスト プールをデプロイできます。
アクティブ/アクティブ: アクティブ/アクティブ構成では、1 つのホスト プールに複数のリージョンの VM を含めることができます。 複数のリージョンのストレージ間でユーザーの FSLogix プロファイルをアクティブにレプリケートするには、クラウド キャッシュ機能を組み合わせる必要があります。 MSIX アプリアタッチの場合は、他のリージョンの追加のファイル共有で別のコピーを使用します。 各リージョンの VM には、場所を指定するためのクラウド キャッシュ レジストリが含まれている必要があります。 また、ローカルの保存場所に対して優先されるようにグループ ポリシーを構成する必要があります。 この Azure Virtual Desktop の展開は、ユーザーの観点から最も高い効率を提供します。 これは、障害が発生した場合、残りのリージョンのユーザーは、もう一度サインインしなくてもサービスを引き続き使用できるためです。 ただし、この構成はコストがかかり、展開が複雑になり、パフォーマンスは最適化されていません。
アクティブ/パッシブ: アクティブ/パッシブ構成の場合は、Azure Site Recovery を使用して、ドメイン コントローラーを伴うセカンダリ リージョン内の VM をレプリケートできます。 Azure Site Recovery を使用する場合は、これらの VM を手動で登録する必要はありません。 代わりに、セカンダリ VM の Azure Virtual Desktop エージェントは、最新のセキュリティ トークンを自動的に使用して、それに最も近いサービス インスタンスに接続します。 これにより、セッション ホストがホスト プールに自動的に参加し、ユーザーは VM にアクセスするためにのみ再接続する必要があります。 この構成では、フェールオーバー リージョンに、すべてのリソースをオフにしてセカンダリ ホスト プール ( ホット スタンバイとして知られています) を作成することもできます。 その後、Azure Site Recovery の復旧計画を使用してホスト プールを有効にし、オーケストレートされたプロセスを作成します。 また、フェールオーバー リージョンに新規のアプリケーション グループを作成し、ユーザーを割り当てる必要があります。
仮想ネットワーク
リージョンにおける不具合は、仮想ネットワークと、仮想ネットワークに展開されたサービスに影響します。 セカンダリ リージョンの仮想ネットワークを計画する必要があります。 仮想ネットワークを手動で作成して、プライマリ ネットワークとのピアリングを設定することができます。 また、Azure Site Recovery を使用してフェールオーバー リージョンの仮想ネットワークを設定し、プライマリ ネットワークの設定を保持することもできます。
オンプレミス ネットワークに接続されている Azure Virtual Desktop では、オンプレミス ネットワークとの接続性を担保しながら、セカンダリ リージョンに仮想ネットワークを構成する必要があります。
FSLogix プロファイルと MSIX アプリ アタッチ
Azure NetApp Files はリージョン間レプリケーションをサポートしているため、FSXlogix プロファイルと MSIX アプリ アタッチのストレージ オプションとして使用できます。 標準 パフォーマンスの Azure Files は、リージョン間レプリケーションもサポートします。 FSLogix エージェントは、複数のプロファイルの場所をサポートするように構成できます。これにより、障害が発生した場合の可用性を確保できます。 プライマリの場所が失敗した場合、FSLogix エージェントは VM Azure Site Recovery の一部としてレプリケートされます。 エージェントは、セカンダリ リージョンを指すプロファイル パスを自動的に使用しようとします。
アクティブ/アクティブ シナリオおよび RTO または RTA が 1 日未満の場合、FSLogix プロファイルを使ってクラウド キャッシュを利用することをお勧めします。 クラウド キャッシュは FSLogix の機能で、特別に有効化して構成する必要があります。 これにより、ユーザー セッション中に全て連続して更新できる複数のリモート ロケーションを利用できるようになります。
画像
プライマリ デスクトップ イメージを変更するたびに、セカンダリ リージョン内のイメージをレプリケートする必要があります。 Azure Compute Gallery を使用して、リージョン間でカスタム イメージを共有できます。 プライマリ リージョンで障害が発生した場合は、デスクトップ イメージのクローンをソースとしてホスト プールを作成するために使用できます。
アプリの依存関係
プライマリ リージョンで使用可能なリソースに依存するアプリケーションでは、セカンダリの場所で同じリソースが必要です。 たとえば、いくつかのアプリケーションが 1 つのリージョンに展開された SQL バックエンドに接続されている場合、SQL をセカンダリの場所にも確実にレプリケートして下さい。 Azure Virtual Machines 上の SQL Server の場合は、Azure Site Recovery を使用できます。 サービスとしてのプラットフォーム (PaaS) ソリューション を利用する SQL には、アクティブ geo レプリケーションまたは自動フェールオーバー グループを使用できます。 これらのリソースは、BCDR プラン全体に含める必要があります。 加えて、保護プランにおけるアプリの依存関係をモデル化できる Azure Site Recovery プランを含める必要があります。