Azure Virtual Desktop のディザスター リカバリー

  • [アーティクル]

組織のデータを安全な状態に保つために、事業継続とディザスター リカバリー (BCDR) 戦略を適応して管理する必要があります。 確実な BCDR 戦略により、計画的および計画外のサービスまたは Azure の停止中にアプリとワークロードの稼働状態が保たれます。 これらの計画は、Microsoft が管理する Azure Virtual Desktop サービスとは対照的に、お客様が管理するセッション ホスト仮想マシン (VM) に対応している必要があります。 管理領域の詳細については、Azure Virtual Desktop でのディザスター リカバリーの概念に関するページを参照してください。

Azure Virtual Desktop サービスは、高可用性を念頭に置いて設計されています。 Azure Virtual Desktop は、独立したコンポーネントの複数のインスタンスが複数の Azure リージョンに分散された、Microsoft によって管理されるグローバル サービスです。 いずれかのコンポーネントで予期しない停止が発生した場合、トラフィックは残りのインスタンスのいずれかに転送されるか、Microsoft によって、別の Azure リージョン内の冗長インフラストラクチャへの完全フェールオーバーが開始されます。

セッション ホスト VM でリージョンの停止中もユーザーが接続できるようにするには、高可用性とディザスター リカバリーを念頭に置いてインフラストラクチャを設計する必要があります。 一般的なディザスター リカバリー計画には、仮想マシン (VM) を別の場所にレプリケートすることが含まれます。 停止中に、プライマリ サイトはセカンダリ ロケーションのレプリケートされた VM にフェールオーバーされます。 ユーザーは中断されることなく、引き続きセカンダリ ロケーションからアプリにアクセスできます。 VM のレプリケーションに加え、セカンダリ ロケーションでユーザー ID にアクセスできる状態を保つ必要があります。 プロファイル コンテナーを使用している場合は、それらをレプリケートする必要もあります。 最後に、プライマリ ロケーションのデータに依存するすべてのビジネス アプリを、確実にデータの残りの部分と共にフェールオーバーできるようにします。

つまり、停止中にユーザーの接続を保つには、次のことを行う必要があります。

  • セカンダリ ロケーションに VM をレプリケートします。
  • プロファイル コンテナーを使用している場合は、セカンダリ ロケーションにデータのレプリケーションを設定します。
  • プライマリ ロケーションに設定したユーザー ID が、セカンダリ ロケーションで利用可能であることを確認します。 可用性を確保するには、セカンダリ ロケーションで (またはそこから) Active Directory ドメイン コントローラーを使用できるようにします。
  • プライマリ ロケーションにある基幹業務アプリケーションとデータも必ずセカンダリ ロケーションにフェールオーバーされるようにします。

アクティブ/パッシブとアクティブ/アクティブのディザスター リカバリー計画

ディザスター リカバリー インフラストラクチャには、アクティブ/パッシブとアクティブ/アクティブの 2 種類があります。 それぞれの種類のインフラストラクチャは異なる方法で機能するため、それらの違いを見てみましょう。

アクティブ/パッシブの計画は、アクティブな 1 つのリソース セットがあるリージョンと、必要になるまで無効になっている (パッシブな) リージョンがある場合です。 アクティブなリージョンがシステム停止や災害によってオフラインになった場合、組織はパッシブ リージョンをオンにし、該当のユーザーを全員そこに移動させることによって、そちらに切り替えることができます。

もう 1 つのオプションは、アクティブ/アクティブのデプロイです。この場合は、両方のインフラストラクチャのセットを同時に使用します。 一部のユーザーは停止の影響を受ける可能性がありますが、影響はダウンしたリージョン内のユーザーに限定されます。 依然としてオンライン状態であるもう 1 つのリージョン内のユーザーは影響を受けず、回復は、機能しているアクティブなリージョンに再接続する、影響を受けたリージョン内のユーザーに限定されます。 アクティブ/アクティブのデプロイは、次のような多くの形式で行うことができます。

  • リージョンの 1 つがダウンした場合に影響を受けるユーザーに対処するために、各リージョンにインフラストラクチャをオーバープロビジョニングします。 この方法の潜在的な欠点は、追加のリソースを維持することでより多くのコストがかかることです。
  • 両方のアクティブなリージョンに追加のセッション ホストを用意するが、不要なときには割り当てを解除します。これにより、コストが削減されます。
  • ディザスター リカバリー中にのみ新しいインフラストラクチャをプロビジョニングし、影響を受けたユーザーが新しくプロビジョニングされたセッション ホストに接続できるようにします。 この方法では、障害発生時に新しいインフラストラクチャをできるだけ早くデプロイできるように、コードとしてのインフラストラクチャ ツールを使用した定期的なテストが必要です。

使用できるディザスター リカバリー計画の種類の詳細については、Azure Virtual Desktop でのディザスター リカバリーの概念に関するページを参照してください。

作業を開始する前にまず行うべきことは、組織にとって最適な方法を特定することです。 計画が整ったら、復旧計画の構築を開始できます。

VM レプリケーション

まず、セカンダリ ロケーションに VM をレプリケートする必要があります。 これを行うためのオプションは、VM の構成方法によって異なります。

  • Azure Site Recovery を使用して、個人用とプールされたホスト プールの両方にあるすべての VM に対してレプリケーションを構成できます。 このプロセスのしくみの詳細については、「Azure VM を別の Azure リージョンにレプリケートする」を参照してください。 ただし、同じイメージから構築したプールされたホスト プールがあり、ローカルに格納されている個人ユーザー データがない場合は、それらをレプリケートしないことを選択できます。 代わりに、VM を事前に構築し、電源をオフにしておくという選択肢があります。 また、障害が発生している間にのみセカンダリ リージョンに新しい VM をプロビジョニングすることもできます。 これらの方法を選択する場合、必要なのは、1 つのホスト プールとそれに関連するアプリケーション グループおよびワークスペースを設定することだけです。
  • フェールオーバーの場所にあるすべてのリソースをオフにしたままで、フェールオーバー リージョンに新しいホスト プールを作成することができます。 この方法の場合、フェールオーバー リージョンに新しいアプリケーション グループとワークスペースを設定する必要があります。 その後、Azure Site Recovery プランを使用して、ホスト プールをオンにできます。
  • フェールオーバー リージョン内の VM をオフにしたままで、プライマリおよびフェールオーバー リージョンの両方にビルドされた VM によって設定されるホスト プールを作成することができます。 この場合、必要なのは、1 つのホスト プールとそれに関連するアプリケーション グループとワークスペースを設定することだけです。 Azure Site Recovery プランを使用して、この方法でホスト プールの電源をオンにすることができます。

「Azure から Azure へのディザスター リカバリー アーキテクチャ」で説明されているように、他の Azure の場所への VM のレプリケーションを管理するには、Azure Site Recovery を使用することをお勧めします。 個人用ホスト プールには特に Azure Site Recovery を使用することをお勧めします。これは、名前が示すとおり、個人用ホスト プールには、ユーザーにとって個人的な情報が含まれている傾向があるためです。 Azure Site Recovery では、サーバーベースとクライアントベースの両方の SKU がサポートされます。

Azure Site Recovery を使用する場合は、これらの VM を手動で登録する必要はありません。 セカンダリ VM の Azure Virtual Desktop エージェントによって、最も近いサービス インスタンスに接続するために最新のセキュリティ トークンが自動的に使用されます。 セカンダリ ロケーションの VM (セッション ホスト) は、自動的にホスト プールの一部になります。 エンドユーザーはプロセス中に再接続する必要がありますが、その他の手動操作はありません。

停止中に既存のユーザー接続が存在する場合は、管理者がセカンダリ リージョンへのフェールオーバーを開始する前に、現在のリージョンでのユーザー接続を終了する必要があります。

Azure Virtual Desktop (クラシック) でユーザーを切断するには、このコマンドレットを実行します。

Invoke-RdsUserSessionLogoff

Azure Virtual Desktop でユーザーを切断するには、このコマンドレットを実行します。

Remove-AzWvdUserSession

プライマリ リージョンのすべてのユーザーをサインアウトしたら、プライマリ リージョンの VM をフェールオーバーして、ユーザーがセカンダリ リージョンの VM に接続できるようにすることができます。

仮想ネットワーク

次に、停止中のネットワーク接続について考えます。 セカンダリ リージョンに仮想ネットワーク (VNET) を設定したことを確認する必要があります。 ユーザーがオンプレミスのリソースにアクセスする必要がある場合は、それらにアクセスするようにこの VNET を構成する必要があります。 VPN、ExpressRoute、または仮想 WAN を使用して、オンプレミス接続を確立することができます。

プライマリ ネットワークの設定が維持され、ピアリングは必要とされないため、Azure Site Recovery を使用してフェールオーバー リージョンに VNET を設定することをお勧めします。

ユーザー ID

次に、ドメイン コントローラーを確実にセカンダリ ロケーションで使用できるようにします。

ドメイン コントローラーを使用可能な状態に保つには、次の 3 つの方法があります。

  • セカンダリ ロケーションに 1 つ以上の Active Directory ドメイン コントローラーを配置する
  • オンプレミスの Active Directory ドメイン コントローラーを使用する
  • Azure Site Recovery を使用して Active Directory ドメイン コントローラーをレプリケートする

ユーザー プロファイル

ユーザー プロファイルの管理には FSLogix を使用することをお勧めします。 詳しくは、「FSLogix のビジネス継続性とディザスター リカバリーのオプション」を参照してください。

データのバックアップ

データをバックアップするオプションもあります。 Azure Virtual Desktop データをバックアップするには、次のいずれかの方法を選択できます。

  • コンピューティング データの場合は、Azure Backup を使用して個人用ホスト プールのみをバックアップすることをお勧めします。
  • Storage データの場合、推奨されるバックアップ ソリューションは、ユーザー プロファイルの格納に使用したバックエンド ストレージによって異なります。

アプリ間の依存関係

最後に、プライマリ リージョンにあるデータに依存するすべてのビジネス アプリを、確実にセカンダリ ロケーションにフェールオーバーできるようにします。 また、必ず、アプリが新しい場所で動作するのに必要な設定を構成してください。 たとえば、アプリのいずれかが SQL バックエンドに依存している場合は、セカンダリ ロケーションに確実に SQL をレプリケートしてください。 フェールオーバー プロセスの一環として、または既定の構成として、セカンダリ ロケーションを使用するようにアプリを構成する必要があります。 Azure Site Recovery プランのアプリの依存関係をモデル化できます。 詳細については、「復旧計画について」を参照してください。

ディザスター リカバリー テスト

ディザスター リカバリーを設定した後、プランをテストして動作することを確認します。

プランのテスト方法に関するいくつかの推奨事項を次に示します。

  • テスト VM からインターネットにアクセスできる場合、新しい接続のために既存のセッション ホストが引き継がれますが、元のセッション ホストへの既存の接続はすべてアクティブのままになります。 テストを実行する管理者が、プランをテストする前にすべてのアクティブ ユーザーをサインアウトしていることを確認してください。
  • メンテナンス期間中は、ユーザーを中断させないように完全なディザスター リカバリー テストのみを実行する必要があります。
  • ビジネス クリティカルなすべてのアプリケーションとデータがテストの対象になっていることを確認してください。
  • 一度に最大 100 台の VM のみをフェールオーバーすることをお勧めします。 それよりも多くの VM がある場合は、それらを数回に分けて 10 分置きにフェイルオーバーすることをお勧めします。

次のステップ

停止に関するプランに加え、データを安全な状態に保つ方法について不明な点がある場合は、セキュリティ ガイドを確認してください。