カスタマー マネージド計画フェールオーバー (プレビュー) のしくみ
カスタマー マネージド計画フェールオーバーは、障害や復旧の計画とテスト、予想される大規模な障害の予防的な修復、非ストージ関連の停止などのシナリオで役立ちます。
計画フェールオーバー プロセス中に、ストレージ アカウントのプライマリ リージョンとセカンダリ リージョンがスワップされます。 元のプライマリ リージョンは降格され、新しいセカンダリになりますが、元のセカンダリ リージョンは昇格され、新しいプライマリになります。 計画フェールオーバーを開始するには、プライマリとセカンダリ両方のリージョンでストレージ アカウントを利用できる必要があります。
この記事では、カスタマー マネージド計画フェールオーバーとフェールバック中、プロセスのすべてのステージで何が起こるかについて説明します。 予期しないストレージ エンドポイントの停止によるフェールオーバーのしくみについては、カスタマー マネージド (計画外) フェールオーバーのしくみに関するページを参照してください。
重要
カスタマー マネージド計画フェールオーバーは現在プレビュー段階であり、次のリージョンに限り提供されます。
- フランス中部
- フランス南部
- インド中部
- インド西部
- 東アジア
- 東南アジア
ベータ版、プレビュー版、または一般提供としてまだリリースされていない Azure の機能に適用される法律条項については、「Microsoft Azure プレビューの追加使用条件」を参照してください。
重要
計画フェールオーバーの後、Azure Files データが存在する場合、ストレージ アカウントの最終同期時刻 (LST) の値が古いように見えたり、NULL として報告されたりする可能性があります。
システム スナップショットは、フェールオーバーとフェールバックの間に使用される一貫性のある復旧ポイントを維持するために、ストレージ アカウントのセカンダリ リージョンに定期的に作成されます。 カスタマーマネージド計画フェールオーバーを開始すると、元のプライマリ リージョンが新しいセカンダリになります。 場合によっては、計画フェールオーバーの完了後に新しいセカンダリ上に利用できるシステム スナップショットが存在しないことが原因で、アカウントの全体的な LST 値が古いままに見えたり、Null と表示されたりします。
オブジェクトの作成、変更、削除などのユーザー アクティビティによってスナップショットの作成をトリガーすることができるため、計画フェールオーバー後にこれらのアクティビティが発生するアカウントでは、特別な注意は必要ありません。 ただし、スナップショットまたはユーザー アクティビティがないアカウントでは、システム スナップショットの作成がトリガーされるまで、Null LST 値が表示され続ける可能性があります。
必要に応じて、ストレージ アカウント内の共有ごとに次のアクティビティのうちいずれかを行い、スナップショット作成をトリガーします。 完了すると、30 分以内に有効な LST 値がアカウントに表示されます。
- 共有をマウントし、任意のファイルを読み取り用に開きます。
- テストまたはサンプルのファイルを共有にアップロードします。
計画フェールオーバーとフェールバック中の冗長性管理
ヒント
カスタマー マネージド フェールオーバーとフェールバックのプロセス中のさまざまな冗長性状態の詳細については、「Azure Storage の冗長性」でそれぞれの定義を参照してください。
計画フェールオーバー プロセス中、プライマリ リージョンのストレージ サービス エンドポイントは、残りの更新がセカンダリ リージョンにレプリケートされるまで読み取り専用になります。 次に、すべてのストレージ サービス エンドポイントのドメイン ネーム サービス (DNS) エントリが切り替わります。 ストレージ アカウントのセカンダリ エンドポイントが新しいプライマリ エンドポイントになり、元のプライマリ エンドポイントは新しいセカンダリになります。 プライマリとセカンダリのリージョンが切り替わっても、各リージョン内のデータのレプリケーションはそのままで変更されません。
計画フェールバック プロセスは、基本的に計画フェールオーバー プロセスと同じですが、1 つの例外があります。 計画フェールバック中、Azure によってストレージ アカウントの元の冗長性構成が保存され、フェールバック時に元の状態に復元されます。 たとえば、ストレージ アカウントが元々は GZRS として構成されていた場合、フェールバック後にそのストレージ アカウントは GZRS になります。
Note
カスタマー マネージド (計画外) フェールオーバーとは異なり、計画フェールオーバーでは、エンドポイントの DNS エントリが新しいセカンダリに変更される前に、プライマリ リージョンからセカンダリ リージョンへのレプリケーションを完了する必要があります。 このため、プロセス全体を通じてプライマリとセカンダリの両方のリージョンが使用できる限り、計画フェールオーバーまたはフェールバック中にデータ損失が発生することは想定されません。
フェールオーバーを開始する方法
フェールオーバーを開始する方法については、「アカウントのフェールオーバーを開始する」をご覧ください。
計画フェールオーバーとフェールバックのプロセス
以下の図は、ストレージ アカウントのカスタマー マネージド計画フェールオーバーおよびフェールバック中の動作を示しています。
通常の状況では、クライアントはストレージ サービス エンドポイントを通してプライマリ リージョンのストレージ アカウントにデータを書き込みます (1)。 その後、データはプライマリ リージョンからセカンダリ リージョンに非同期的にコピーされます (2)。 次の図は、GRS として構成されたストレージ アカウントの通常の状態を示しています。
計画フェールオーバー プロセス (GRS/RA-GRS)
セカンダリ リージョンへのストレージ アカウントのフェールオーバーを開始して、ディザスター リカバリー テストを開始します。 次の手順では、フェールオーバー プロセスに説明します。その後の図は、それを図示したものです。
- 元のプライマリ リージョンは読み取り専用になります。
- プライマリ リージョンからセカンダリ リージョンへのすべてのデータのレプリケーションが完了します。
- セカンダリ リージョンのストレージ サービス エンドポイントの DNS エントリが昇格され、ストレージ アカウントの新しいプライマリ エンドポイントになります。
フェールオーバーには、通常、約 1 時間かかります。
フェールオーバーが完了すると、元のプライマリ リージョンは新しいセカンダリ (1) になり、元のセカンダリ リージョンは新しいプライマリ (2) になります。 BLOB、テーブル、キュー、ファイルのストレージ サービス エンドポイントの URI は同じままですが、それらの DNS エントリは、新しいプライマリ リージョン (3) を指すように変更されます。 ユーザーは、新しいプライマリ リージョンでストレージ アカウントへのデータの書き込みを再開でき、次の図に示すように、データは、新しいセカンダリ (4) に非同期でコピーされます。
フェールオーバー状態の間にディザスター リカバリー テストを実行します。
計画フェールバック プロセス (GRS/RA-GRS)
テストが完了したら、別のフェールオーバーを実行して、元のプライマリ リージョンにフェールバックします。 次の図に示すように、フェールオーバー プロセスの動作は次のようになります。
- 元のプライマリ リージョンは読み取り専用になります。
- 現在のプライマリ リージョンから現在のセカンダリ リージョンへのすべてのデータのレプリケーションが完了します。
- ストレージ サービス エンドポイントの DNS エントリは、最初のフェールオーバーが実行される前にプライマリだったリージョンを指すように変更されます。
通常、フェールバックには約 1 時間かかります。
フェールバックが完了すると、ストレージ アカウントは元の冗長性構成に復元されます。 ユーザーは、元のプライマリ リージョンでストレージ アカウントへのデータの書き込みを再開でき (1)、元のセカンダリへのレプリケーションがフェールオーバー前と同様に続行されます (2)。
