お客様が管理する計画フェールオーバーは、ディザスター リカバリーの計画とテスト、予想される大規模な災害の予防的な修復、ストレージに関連しない停止などのシナリオで役立ちます。
計画フェールオーバー プロセス中に、ストレージ アカウントのプライマリ リージョンとセカンダリ リージョンがスワップされます。 元のプライマリ リージョンは降格され、新しいセカンダリになりますが、元のセカンダリ リージョンは昇格され、新しいプライマリになります。 計画フェールオーバーを開始するには、プライマリとセカンダリ両方のリージョンでストレージ アカウントを利用できる必要があります。
この記事では、カスタマー マネージド計画フェールオーバーとフェールバック中、プロセスのすべてのステージで何が起こるかについて説明します。 予期せぬストレージエンドポイントの障害によるフェイルオーバーがどのように機能するのかを理解するには 、「顧客管理(計画外)フェイルオーバーの仕組み」をご覧ください。
計画フェールオーバーとフェールバック中の冗長性管理
ヒント
カスタマー マネージド フェールオーバーとフェールバックのプロセス中のさまざまな冗長性状態の詳細については、「Azure Storage の冗長性」でそれぞれの定義を参照してください。
計画フェールオーバー プロセス中、プライマリ リージョンのストレージ サービス エンドポイントは、残りの更新がセカンダリ リージョンにレプリケートされるまで読み取り専用になります。 次に、すべてのストレージ サービス エンドポイントのドメイン ネーム サービス (DNS) エントリが切り替わります。 ストレージ アカウントのセカンダリ エンドポイントが新しいプライマリ エンドポイントになり、元のプライマリ エンドポイントは新しいセカンダリになります。 プライマリとセカンダリのリージョンが切り替わっても、各リージョン内のデータのレプリケーションはそのままで変更されません。
計画フェールバック プロセスは、基本的に計画フェールオーバー プロセスと同じですが、1 つの例外があります。 計画フェールバック中、Azure によってストレージ アカウントの元の冗長性構成が保存され、フェールバック時に元の状態に復元されます。 たとえば、ストレージ アカウントが元々は GZRS として構成されていた場合、フェールバック後にそのストレージ アカウントは GZRS になります。
メモ
カスタマー マネージド (計画外) フェールオーバーとは異なり、計画フェールオーバーでは、エンドポイントの DNS エントリが新しいセカンダリに変更される前に、プライマリ リージョンからセカンダリ リージョンへのレプリケーションを完了する必要があります。 このため、プライマリおよびセカンダリーの両方がプロセス全体を通じて利用可能であれば、計画されたフェイルオーバーやフェイルバック中にデータ損失は予想されません。
フェールオーバーを開始する方法
フェールオーバーを開始する方法については、「アカウントのフェールオーバーを開始する」をご覧ください。
計画されたフェールオーバーとフェールバックの過程
以下の図は、ストレージ アカウントのカスタマー マネージド計画フェールオーバーおよびフェールバック中の動作を示しています。
通常の状況では、クライアントはストレージ サービス エンドポイントを通してプライマリ リージョンのストレージ アカウントにデータを書き込みます (1)。 その後、データはプライマリ リージョンからセカンダリ リージョンに非同期的にコピーされます (2)。 次の図は、GRS として構成されたストレージ アカウントの通常の状態を示しています。
計画フェールオーバー プロセス (GRS/RA-GRS)
セカンダリ リージョンへのストレージ アカウントのフェールオーバーを開始して、ディザスター リカバリー テストを開始します。 以下は、計画フェールオーバー プロセスの手順に説明します。その後の図は、それを図示したものです。
プライマリ リージョンとセカンダリ リージョンの両方のストレージ アカウントで、読み取りアクセスと書き込みアクセスの両方が一時的に失われます。
プライマリ リージョンからセカンダリ リージョンへのすべてのデータのレプリケーションが完了します。
セカンダリ リージョンのストレージ サービス エンドポイントの DNS エントリが昇格され、ストレージ アカウントの新しいプライマリ エンドポイントになります。
フェールオーバーには、通常、約 1 時間かかります。
フェールオーバーが完了すると、元のプライマリ リージョンは新しいセカンダリ (1) になり、元のセカンダリ リージョンは新しいプライマリ (2) になります。 BLOB、テーブル、キュー、ファイルのストレージ サービス エンドポイントの URI は同じままですが、それらの DNS エントリは、新しいプライマリ リージョン (3) を指すように変更されます。 ユーザーは、新しいプライマリ リージョンでストレージ アカウントへのデータの書き込みを再開でき、次の図に示すように、データは、新しいセカンダリ (4) に非同期でコピーされます。
フェールオーバー状態の間にディザスター リカバリー テストを実行します。
メモ
Azure Files はステートフル接続を維持します。つまり、データへのアクセスを続行するには、フェールオーバー後にアプリケーションでファイル共有の再マウントまたは再起動が必要になる場合があります。
計画フェールバック プロセス (GRS/RA-GRS)
テストが完了したら、別のフェールオーバーを実行して、元のプライマリ リージョンにフェールバックします。 次の図に示すように、フェールオーバー プロセスの動作は次のようになります。
プライマリ リージョンとセカンダリ リージョンの両方のストレージ アカウントで、読み取りアクセスと書き込みアクセスの両方が一時的に失われます。
現在のプライマリ リージョンから現在のセカンダリ リージョンへのすべてのデータのレプリケーションが完了します。
ストレージ サービス エンドポイントの DNS エントリは、最初のフェールオーバーが実行される前にプライマリだったリージョンを指すように変更されます。
通常、フェールバックには約 1 時間かかります。
フェールバックが完了すると、ストレージ アカウントは元の冗長性構成に復元されます。 ユーザーは、元のプライマリ リージョンでストレージ アカウントへのデータの書き込みを再開でき (1)、元のセカンダリへのレプリケーションがフェールオーバー前と同様に続行されます (2)。
