次の方法で共有

FSLogix のビジネス継続性とディザスター リカバリーのオプション

  • [アーティクル]

Note

すべての図は、Azure Virtual Desktop に基づく例であり、他の仮想デスクトップ プラットフォームに適用できます。

効果的なビジネス継続性とディザスター リカバリー (BCDR) 計画では、大災害やその他の重大な停止が発生した場合に組織が機能するために必要なプロセスとリソースに重点を置いています。 一般的に移動ユーザー プロファイルは、BCDR 戦略のビジネスまたはミッション クリティカルなコンポーネントとして記述されていません。 仮想デスクトップ環境では、ユーザーはローミング プロファイルがあることに気付きません。 プロファイルは、仮想マシンに関係なく一貫したエクスペリエンスをユーザーに提供するためにローミングされます。 ビジネスまたはミッション クリティカルなデータは、可能な限りユーザーのプロファイルに格納するべきではありません。 OneDrive、SharePoint、またはその他のソリューションを使用すると、ユーザーがプロファイルの一部としてローミングするデータに依存せず、BCDR イベント中にデータを保護するための効果的な手段となります。 このプロセスは、目標復旧時間 (RTO) と目標復旧時点 (RPO) の演習で最もよく説明されます。演習では、コスト メリットとリスク分析を組織とビジネスの目標に基づいて検討できます。

オプション 1: プロファイルを回復しない

このオプションは BCDR 設計のようには見えませんが、ビジネスとミッション クリティカルなデータがユーザーのプロファイルに含まれていないことを確認することに重点を置きます。 災害が発生した場合、ユーザーは新しい場所または新しいストレージ プロバイダーに新しいプロファイルを作成します (その両方も可)。 このオプションは、インフラストラクチャ コストの面で最もコスト効率が高くなりますが、ユーザー エクスペリエンスにはよくない影響を与えます。

FSLogix プロファイル回復なし

図 1: プロファイルを回復しない | FSLogix 標準コンテナー (VHDLocations)

この図では、Azure Virtual Desktop を使用する複数リージョンのホスト プールがあります。 プライマリ リージョンとフェールオーバー リージョンの両方には、リージョン内の高可用性を提供するゾーン冗長ストレージ (ZRS) を使用する専用の Azure Files 共有があります。 フェールオーバー リージョンには、停止または割り当て解除されているセッション ホストがあります。 災害が発生すると、フェールオーバー リージョンがプライマリ リージョンになり、ユーザーはこれらのセッション ホストにサインインし、そのリージョンの Azure Files 共有に新しいプロファイルを作成します。

オプション 2: Cloud Cache (プライマリ / フェールオーバー)

フェールオーバー設計は、災害や障害が発生した場合にインフラストラクチャの可用性と信頼性を確保するための一般的な戦略です。 Cloud Cache を使用すると、この種類のフェールオーバー設計を使用して FSLogix を使用できます。 Cloud Cache を使用すると、プロファイル データを異なる場所に格納する 2 つのストレージ プロバイダーを使用するようにデバイスを構成できます。 Cloud Cache では、プロファイル データが 2 つのストレージ プロバイダーのそれぞれに非同期的に同期されるため、常に最新バージョンのデータが得られます。 一部のデバイスはプライマリの場所にあり、他のデバイスはフェールオーバーの場所にあります。 Cloud Cache は、最初のストレージ プロバイダー (デバイスに最も近い) に優先順位を付け、他のストレージ プロバイダーをバックアップとして使用します。 たとえば、プライマリ デバイスが米国西部にあり、フェールオーバー デバイスが米国東部にある場合は、次のように Cloud Cache を構成できます。

  • プライマリ デバイスでは、最初のオプションとして米国西部のストレージ プロバイダーを使用し、2 番目のオプションとして米国東部のストレージ プロバイダーを使用します。
  • フェールオーバー デバイスでは、最初のオプションとして米国東部のストレージ プロバイダーを使用し、2 番目のオプションとして米国西部のストレージ プロバイダーを使用します。
  • プライマリ デバイスまたは最も近いストレージ プロバイダーが失敗した場合は、フェールオーバー デバイスまたはバックアップ ストレージ プロバイダーに切り替えて、プロファイル データを失うことなく作業を続行できます。

ただし、Cloud Cache でフェールオーバー設計を使用する場合には、いくつかの欠点があります。 1 つには、プロファイル データを 2 つの場所に格納するために追加料金を支払う必要があります。 2 つ目は、フェールオーバー プロセスを手動で開始する必要があります。そのためには、ビジネス利害関係者の承認が必要になる場合があります。 3 つ目は、2 つのストレージ プロバイダーとの非同期の同期が原因で、プロファイル データの待機時間や不整合が発生する可能性があります。

ヒント

  • ユーザーがプライマリの場所のプロファイルにフェールバックすることを許可する前に、すべてのユーザーがフェールオーバーの場所から正常にサインアウトしていることを確認して、プライマリの場所にユーザーのプロファイル データの最新のレプリカがあることを確認してください。
  • Cloud Cache は I/O 集中型システムであり、復元された場所にネットワークやストレージのボトルネックを簡単に引き起こす可能性があります。

FSLogix ディザスター リカバリー フェールオーバー

図 2: Cloud Cache (プライマリ / フェールオーバー) |FSLogix Cloud Cache (CCDLocations)

この図には、Azure Virtual Desktop を使用する複数リージョンのホスト プールがあります。 プライマリ リージョンとフェールオーバー リージョンの両方がこの構成の一部です。 それぞれにゾーン冗長ストレージ (ZRS) を使用する専用の Azure Files 共有があり、リージョン内の高可用性が確保されます。 フェールオーバー リージョンには、停止または割り当て解除されるセッション ホストが含まれています。 障害が発生した場合、フェールオーバー リージョンがプライマリ リージョンになります。 ユーザーはこれらのセッション ホストにサインインし、フェールオーバー リージョンからレプリケートされたプロファイルを読み込みます。

ただし、次の点を考慮する必要があります。

  • BCDR (ビジネス継続性とディザスター リカバリー) イベントが正常であることはほとんどありません。 状況によっては、ユーザー プロファイル データが維持されるとは限りません。
  • フェールオーバー リージョンのセッション ホストにサインイン中のユーザーにデータの損失が発生する可能性があり、さらに悪いケースではコンテナーの破損が発生する可能性があります。

このような状況では、重要なデータに OneDrive や SharePoint などのストレージ プラットフォームを使用することが重要です。 これらのプラットフォームは、データ損失に対する追加の冗長性と保護を提供します。 ディザスター リカバリーの計画は不可欠であり、適切なストレージ戦略を使用すると、リスクを軽減し、ビジネス継続性を確保できます。

オプション 3: Cloud Cache (アクティブ / アクティブ)

インフラストラクチャについて説明するときは、アクティブ/アクティブ設計を使用するのが一般的です。これは FSLogix プロファイル ソリューションにも適用できます。 このオプションを使用すると、ローカル キャッシュに加えられたすべての変更を反映するように、非同期的に更新される 2 つのストレージ プロバイダーで Cloud Cache が設定されます。 アクティブな場所に最も近いストレージ プロバイダーがリストの 1 番目になり、最も遠いプロバイダーがリストの 2 番目になります。 もう一方の場所では、この順序は逆になります。 このオプションでは、プロバイダー データを 2 つの場所に格納するための追加コストが発生し、フェールオーバーを開始する前に、ビジネス利害関係者が手動で決定する必要があります。

ヒント

  • 障害が発生したリージョンが動作している場合、プロファイル データが完全にレプリケートされるまでにかなりの時間がかかる場合があります。
  • Cloud Cache は I/O 集中型システムであり、復元された場所にネットワークやストレージのボトルネックを簡単に引き起こす可能性があります。

アクティブ/アクティブの FSLogix

図 3: Cloud Cache (アクティブ / アクティブ) |FSLogix Cloud Cache (CCDLocations)

図には、2 つの AVD ホスト プールと、特定の Azure リージョンに存在するセッション ホストがあります。 米国西部リージョンに割り当てられているユーザーは、それらの仮想マシンにアクセスします。 米国東部リージョンのユーザーのみがアクセスし、それらの仮想マシンに割り当てられます。 災害が発生した場合、存続しているリージョンには、すべてのユーザーをサポートするのに十分な容量が必要です。 さらに、障害が発生したリージョンのユーザーは、存続しているリージョン内の仮想マシンへのアクセス権が付与されている必要があります。

BCDR イベントが正常であることはなく、イベントの状況によっては、ユーザー プロファイル データがそのまま保護されることは保証されません。 存続しているリージョンのセッション ホストにサインインしたユーザーは、データが失われたり、コンテナーの破損が悪化したりする可能性があります。 この状況では、重要なユーザー データに OneDrive や SharePoint などのストレージ プラットフォームを使用する必要性が高まります。