Azure Storage は、ローカル冗長ストレージ (LRS)、geo 冗長ストレージ (GRS)、ゾーン冗長ストレージ (ZRS) などの機能を使用して、堅牢な冗長性とディザスター リカバリー機能を提供します。 データの整合性とサービスの可用性を維持するには、計画されたフェールオーバーと計画外のフェールオーバーとその後のフェールバック プロセスの微妙な違いを理解することが重要です。
このドキュメントでは、よく寄せられる質問に回答し、技術的なシナリオ、競合する機能、Azure Storage のフェールオーバーとフェールバックに関連する運用上の影響について説明します。 ベスト プラクティスに関するガイダンスを提供し、データ損失やサポートされていない構成などの潜在的な落とし穴を強調し、フェールオーバー イベント後にストレージ アカウントを元の状態に復元する方法について説明します。 これらの推奨事項に従うことで、組織はディザスター リカバリーの準備を強化し、Azure Storage を使用するときにビジネス継続性を確保できます。
計画フェールオーバーと計画外フェールオーバーの違い
Azure Storage アカウントでは、次の 2 種類のカスタマー マネージド フェールオーバーがサポートされます。
- お客様が管理する計画されたフェールオーバー: お客様は、ストレージ アカウントのフェールオーバーを管理して、ディザスター リカバリー計画をテストできます。
- カスタマー マネージド (計画外) フェールオーバー: 予期しないサービス停止が発生した場合、ストレージ アカウントのフェールオーバーを管理できます。
フェールオーバーの種類ごとに、一意のユース ケースのセットと、データ損失に対応する期待があります。
計画されたフェールオーバー。
計画フェールオーバーは、計画ディザスター リカバリー テスト、大規模な災害に対するプロアクティブなアプローチ、ストレージ関連以外の障害からの復旧など、複数のシナリオで利用できます。 計画されたフェールオーバー プロセス中に、プライマリ リージョンとセカンダリ リージョンがスワップされ、アカウントは geo 冗長のままです。 元のプライマリ リージョンが降格され、新しいセカンダリ リージョンになります。 同時に、元のセカンダリ リージョンが昇格され、新しいプライマリになります。 プライマリとセカンダリ リージョンがプロセス全体を通して利用できる限り、計画フェールオーバーおよびフェールバック プロセス中のデータ損失は想定されていません。
詳細については、 計画されたフェールオーバーのしくみに関する記事を参照してください。
計画外のフェールオーバー
ストレージ サービスのデータ エンドポイントがプライマリ リージョンで使用できなくなった場合は、ストレージ アカウントのセカンダリ リージョンへの計画外のフェールオーバーを開始できます。 フェールオーバーが完了すると、ストレージ アカウントがローカル冗長ストレージ (LRS) になり、セカンダリ リージョンが新しいプライマリになります。 ユーザーは、新しいプライマリ リージョンのデータへのアクセスに進むことができます。
データはプライマリ リージョンからセカンダリ リージョンに非同期的に書き込まれるため、プライマリ リージョンへの書き込みがセカンダリにコピーされるまでの間に常に遅延があります。 計画外のフェールオーバーが開始されると、セカンダリ リージョンが新しいプライマリになると、プライマリ リージョン内のすべてのデータが失われます。 フェールオーバーが発生した時点でセカンダリ リージョンに既にコピーされていたデータはすべて維持されます。 ただし、プライマリに書き込まれたデータのうち、セカンダリ リージョンにまだ存在していないものは、永久に失われます。 ユーザーは、最終同期時刻 (LST) を使用して、プライマリ リージョンとセカンダリ リージョン間の完全同期が最後に完了したことを確認できます。
詳細については、 計画外フェールオーバーのしくみに関する記事を参照してください。
フェールオーバーが完了した後、アカウントにどのような影響がありますか?
フェールオーバー操作の影響は、計画されたフェールオーバーと計画外のフェールオーバーのどちらを開始したかによって異なります。
計画されたフェールオーバー。
- ストレージ アカウントの冗長性はそのまま維持されるか、GRS/RA-GRS に変換されます。
- プライマリ リージョンとセカンダリ リージョンがスワップされます。 元のセカンダリ リージョンが新しいプライマリ リージョンになり、元のプライマリ リージョンが新しいセカンダリ リージョンになります。
- データの損失は想定されていません。
計画外のフェールオーバー
- ストレージ アカウントは geo 冗長性を失い、ローカル冗長ストレージ (LRS) になります。
- アカウントの以前のセカンダリ リージョンがプライマリ リージョンになりました。
- LST の後にストレージ アカウントに書き込みが行われた場合、ユーザーはデータ損失が発生する可能性があります。
計画フェールオーバーと計画外フェールオーバーの影響の概要については、以下を参照してください。
| フェールオーバーの結果 | カスタマー マネージド計画フェールオーバー (プレビュー) | カスタマーマネージド (計画外) フェールオーバー |
|---|---|---|
| セカンダリ リージョン | セカンダリ リージョンが新しいプライマリになります | セカンダリ リージョンが新しいプライマリになります |
| 元のプライマリ リージョン | 元のプライマリ リージョンが新しいセカンダリになります | 元のプライマリ リージョン内のデータのコピーが削除されます |
| アカウントの冗長構成 | ストレージ アカウントが GRS に変換されます | ストレージ アカウントが LRS に変換されます |
| geo 冗長構成 | 地理的冗長性が保たれます | geo 冗長が失われます |
次の表は、フェールオーバーとフェールバック プロセスの各ステージでの結果の冗長構成を、フェールオーバーの種類ごとにまとめたものです。
| 元の構成 | フェールオーバー後 | geo 冗長性を再び有効にした後 | フェールバック後 | geo 冗長性を再び有効にした後 |
|---|---|---|---|---|
| 顧客が管理する計画フェールオーバー | ||||
| GRS | GRS | n/a | GRS | n/a |
| GZRS | GZRS | n/a | GZRS | n/a |
| カスタマーマネージド (計画外) フェールオーバー | ||||
| LRS | LRS | GRS | LRS | GRS |
| GZRS | LRS | GRS | ZRS | GZRS |
フェールオーバー後に SKU をゾーン冗長ストレージ (ZRS) または Geo-Zone 冗長ストレージ (GZRS) に変更できないのはなぜですか?
フェールオーバー操作後のゾーン変換 (ゾーン冗長の追加) の実行は、現在サポートされていません。 計画外のフェールオーバーが完了すると、フェールオーバー操作前の冗長性に関係なく、ストレージ アカウントの冗長性は LRS になります。 計画外のフェールオーバーが完了すると、ユーザーは自分のアカウントを GRS または RA-GRS にのみ変換でき、アカウントを ZRS、GZRS、または RA-GZRS に変換することはできません。 ユーザーが自分のアカウントを ZRS に変換したい場合は、フェールバック操作を実行する必要があります (別の計画外または計画されていないフェールオーバーを元のプライマリ リージョンに戻す)。 フェールバックが完了すると、ユーザーはストレージ アカウントを ZRS、GZRS、または RA-GZRS に戻すことができます。 この動作は計画フェールオーバーと似ていますが、アカウントの冗長性は、元のアカウントの冗長性に関係なく GRS になります。 アカウントを GZRS に変換する場合は、元のプライマリ リージョンにフェールバックしてから、アカウントを GRS から GZRS に変換するように要求を送信する必要があります。
このグラフでは、フェールオーバーとフェールバック後のストレージ アカウントの冗長性の変更について説明します。
| 元の構成 | フェールオーバー後 | geo 冗長性を再び有効にした後 | フェールバック後 | geo 冗長性を再び有効にした後 |
|---|---|---|---|---|
| 顧客が管理する計画フェールオーバー | ||||
| GRS | GRS | n/a | GRS | n/a |
| GZRS | GZRS | n/a | GZRS | n/a |
| カスタマーマネージド (計画外) フェールオーバー | ||||
| LRS | LRS | GRS | LRS | GRS |
| GZRS | LRS | GRS | ZRS | GZRS |
フェールオーバー後にデータ損失が予想されますか?
フェールオーバー後にアカウントでデータ損失が発生するかどうかは、開始したフェールオーバー操作によって異なります。 計画フェールオーバーの場合、計画されたフェールオーバーの完了後にデータ損失は発生しません。 計画外フェールオーバーでは、ユーザーがデータ損失を経験する可能性があります。 ユーザーは、最終同期時刻 (LST) プロパティを使用して、プライマリ リージョンとセカンダリ リージョンの間で完全同期が最後に完了した時刻を確認できます。 LST がセカンダリ リージョンに正常にレプリケートされる前に書き込まれたデータまたはメタデータは、計画外のフェールオーバー後に使用可能になります。 ただし、LST の後に書き込まれたデータまたはメタデータは失われる可能性があります。
計画外のフェールオーバー後にアカウントを LRS から GRS に変換するにはどのくらいの時間がかかりますか?
現在、geo 変換を完了するためのサービス レベル アグリーメント (SLA) はありません。サポート要求を送信することでこのプロセスを迅速化することはできません。 これらの変換を完了するためにかかる期間は、次のようなさまざまな要因によって異なる場合があります。
- ストレージ アカウント内のオブジェクトの数とサイズ。
- CPU、メモリ、ディスク、WAN の容量など、バックグラウンド レプリケーションに使用できるリソース。
SKU の変換時間に影響する要因の詳細については、ストレージ アカウントのフェールオーバーの開始に関する記事を参照してください。 ストレージ アカウントのレプリケーション オプションの変更の詳細については、ストレージ アカウントの冗長性の変更に関する記事を参照してください。
フェールオーバー後にアカウントの "Location" プロパティが "プライマリ リージョン" と異なるのはなぜですか?
Microsoft からは、Azure Storage リソースを操作する 2 つの REST API が用意されています。 これらの API は、Azure Storage に対して実行できるすべてのアクションの基礎を形成します。 データ プレーンと呼ばれる Azure Storage REST API を使用すると、BLOB、キュー、ファイル、テーブル データなど、ストレージ アカウント内のデータを操作できます。 Azure Storage リソース プロバイダー REST API (多くの場合、コントロール プレーンと呼ばれます) を使用すると、ストレージ アカウントと関連リソースを管理できます。
フェールオーバーが完了すると、クライアントは、新しいプライマリ リージョン内の Azure Storage データの読み取りと書き込みを再び行うことができます。 ただし、Azure Storage リソース プロバイダーはフェールオーバーしないため、リソース管理操作は引き続きプライマリ リージョンで実行する必要があります。 Azure Storage リソース プロバイダーはフェールオーバーしないため、フェールオーバーが完了すると、Location プロパティは元のプライマリの場所を返します。
次の図は、計画されたフェールオーバー後に想定される 場所 と プライマリ リージョン の例を示しています。
フェールバックとは
フェールバックとは、フェールオーバー操作を使用してストレージ アカウントを元のプライマリ リージョンに復元するプロセスを説明するために使用する用語です。 計画されていないフェールオーバーまたは計画されたフェールオーバーの後、GRS アカウントの元のセカンダリ リージョンが新しいプライマリ リージョンになります。 アカウントを元のプライマリ リージョンに復元するには、ユーザーが別のフェールオーバー操作を開始する必要があります。
基本的に、フェールバックは、元のフェールオーバー操作がアカウントで実行された後に開始されるフェールオーバーです。 計画外のフェールオーバーと計画されたフェールオーバーのフェールバック エクスペリエンスは、いくつかの点で異なります。
計画されたフェールオーバー。
計画されたフェールオーバーの後、アカウントは geo 冗長のままであるため、ユーザーは別の計画されたフェールオーバーを開始するだけで済みます。 計画されたフェールオーバーを開始する方法の詳細について説明します。
計画外のフェールオーバー
計画外のフェールオーバーの後、アカウントは LRS になります。 フェールバックには、いくつかの手順が必要です。
- アカウントを LRS から GRS に変換します。 LRS から GRS への変換には SLA がないことを忘れないでください。 この変換を完了するときに適用されるデータ帯域幅の料金もあります。
- 計画外のフェールオーバーまたはフェールバックを開始します。
計画外のフェールオーバーを開始する方法の詳細について説明します。
フェールオーバーの競合する機能またはシナリオは何ですか?
フェールオーバーには、いくつかの制限事項と、ユーザーが認識する必要がある競合する機能があります。 次の機能またはシナリオにより、フェールオーバー操作の開始がブロックされます。
計画外のフェールオーバー
- オブジェクト レプリケーション: オブジェクト レプリケーション (OR) を使用してアカウントで計画外のフェールオーバーを開始しようとすると、エラーが発生します。 この場合は、アカウントの OR ポリシーを削除し、もう一度変換を試みることができます。
計画されたフェールオーバー。
- 変更フィード: Change Feed を使用してアカウントで計画されたフェールオーバーを開始しようとすると、エラーが発生します。 この場合は、変更フィードを無効にして、フェールオーバーをもう一度試すことができます。
- オブジェクト レプリケーション: オブジェクト レプリケーション (OR) を使用してアカウントで計画フェールオーバーを開始しようとすると、エラーが発生します。 この場合は、アカウントの OR ポリシーを削除し、もう一度変換を試みることができます。
- ポイントインタイム リストア: ポイントインタイム リストア (PITR) を使用してアカウントで計画フェールオーバーを開始しようとすると、エラーが発生します。 この場合は、PITR と変更フィードを無効にして、フェールオーバーを再試行できます。
- 最終同期時間が 30 分を超える: 計画フェールオーバーは、最終同期時間が 30 分を超えるストレージ アカウントではサポートされていません。
Azure File Sync では、カスタマー マネージドの計画されたフェールオーバーまたは計画外のフェールオーバーはサポートされていません。 Azure File Sync のクラウド エンドポイントとして使用されるストレージ アカウントは、フェールオーバーしないでください。 フェールオーバーによってファイルの同期が中断され、新しく階層化されたファイルの予期しないデータ損失が発生するおそれがあります。 詳細については、「Azure File Sync を使用したディザスター リカバリーのベスト プラクティス」を参照してください。
次のステップ
ストレージ アカウントの回復性の計画の一環として、次の記事で詳細を確認できます。