カスタマー マネージドの計画外フェールオーバーを使用すると、プライマリ リージョンのストレージ サービス エンドポイントが使用できなくなった場合に、geo 冗長ストレージ アカウント全体をセカンダリ リージョンにフェールオーバーできます。 フェールオーバーの間に、元のセカンダリ リージョンが新しいプライマリ リージョンになります。 その後、すべてのストレージ サービス エンドポイントは 新しい プライマリ リージョンにリダイレクトされます。 ストレージ サービス エンドポイントの停止が解決されたら、別のフェールオーバー操作を実行して、元のプライマリ リージョンにフェールバックできます。
この記事では、プロセスのすべての段階で、顧客が管理する計画外のフェールオーバーとフェールバックの間に何が起こるかについて説明します。
計画外フェールオーバーとフェールバックの間の冗長性管理
ヒント
計画外フェールオーバーおよびフェールバック プロセス中のさまざまな冗長性状態の詳細を理解するには、「Azure Storage の冗長性」を参照してそれぞれの定義を確認してください。
データは、geo 冗長ストレージ (GRS) または読み取りアクセス geo 冗長ストレージ (RA-GRS) 冗長性用に構成されたストレージ アカウントごとに、リージョンごとに 3 回レプリケートされます。 この方法は、レプリケーションがプライマリ リージョンと セカンダリ リージョンの両方で行われることを意味します。 各リージョンは基本的にローカル冗長 (LRS) であり、データのコピーが 3 つ含まれています。
ストレージ アカウントが geo ゾーン冗長ストレージ (GZRS) または読み取りアクセス geo ゾーン冗長ストレージ (RA-GZRS) のレプリケーション用に構成されている場合、データはゾーン冗長ストレージ (ZRS) のプライマリ リージョン内でゾーン冗長になり、LRS セカンダリ リージョン内で 3 回レプリケートされます。 アカウントが読み取りアクセス (RA) 用に構成されている場合は、セカンダリ リージョンからのデータの読み取りは、そのリージョンへのストレージ サービス エンドポイントが利用可能である場合にのみ実行できます。
カスタマー マネージドの計画外フェールオーバー プロセス中に、ストレージ サービス エンドポイントのドメイン ネーム システム (DNS) エントリが切り替えられます。 ストレージ アカウントのセカンダリ エンドポイントが新しいプライマリ エンドポイントになり、元のプライマリ エンドポイントは新しいセカンダリになります。 フェールオーバーの後、元のプライマリ リージョン内のストレージ アカウントのコピーは削除され、ストレージ アカウントはそのまま新しいプライマリ リージョン内ローカルで 3 回レプリケートされます。 その時点で、ストレージ アカウントはローカル冗長となり、LRS を利用するようになります。
元と現在の冗長構成は、ストレージ アカウントのプロパティ内に保存されます。 この機能を使用すると、フェールバック時に元の構成に戻ることができます。 結果として得られる冗長性構成の完全な一覧については、「復旧計画とフェールオーバー」をお読みください。
フェールオーバーの後で geo 冗長性を回復するには、アカウントを GRS として再構成する必要があります。 アカウントが geo 冗長として再構成されると、Azure はすぐに新しいプライマリ リージョンから新しいセカンダリへのデータのコピーを開始します。 ストレージ アカウントをセカンダリ リージョンへの読み取りアクセス用に構成すると、そのアクセスが利用できるようになります。 ただし、プライマリからセカンダリ リージョンへのレプリケーションが完了するにはある程度の時間がかかる場合があります。
警告
geo 冗長性のためにアカウントを再構成した後、新しいプライマリ リージョンの既存のデータが新しいセカンダリに完全にコピーされるまでにかなりの時間がかかる場合があります。
大きなデータ損失を防ぐため、フェールバックを行う前に、[最終同期時刻] プロパティの値を確認してください。 潜在的なディスク損失を評価するには、最終同期時刻を、新しいプライマリにデータが書き込まれた最後の時刻と比較します。
フェールバック プロセスは基本的にフェールオーバー プロセスと同じですが、レプリケーション構成が元のフェールオーバー前の状態に復元される点が異なります。
フェールバックの後で、geo 冗長を利用するようにストレージ アカウントを再構成できます。 元のプライマリが ZRS として構成されていた場合は、GZRS または RA-GZRS に構成できます。 その他のオプションについては、「ストレージ アカウントがレプリケートされる方法を変更する」を参照してください。
計画外フェールオーバーを開始する方法
計画外フェールオーバーを開始する方法については、「アカウントのフェールオーバーを開始する」を参照してください。
注意
通常、計画外フェールオーバーには、何らかのデータ損失とファイルおよびデータの不整合の可能性が伴います。 この種類のフェールオーバーを開始する前に、アカウント フェールオーバーがデータに与える影響を理解しておくことが重要です。
データ損失と不整合の可能性について詳しくは、「データ損失と不整合を予測する」を参照してください。
計画外フェールオーバーおよびフェールバック プロセス
このセクションでは、顧客が管理する計画外フェールオーバーのフェールオーバー プロセスの概要を示します。
計画外フェールオーバーの移行の概要
顧客が管理する計画外フェールオーバーの後:
- セカンダリ リージョンが新しいプライマリになります
- 元のプライマリ リージョン内のデータのコピーが削除されます
- ストレージ アカウントが LRS に変換されます
- geo 冗長が失われます
次の表は、お客様が管理する計画外のフェールオーバーとフェールバックのすべての段階で得られる冗長性の構成をまとめたものです。
| 元 構成 |
後 フェールオーバー |
再有効化後 geo 冗長 |
後 フェールバック |
再有効化後 geo 冗長 |
|---|---|---|---|---|
| GRS | LRS | GRS 1 | LRS | GRS 1 |
| GZRS | LRS | GRS 1 | ZRS | GZRS 1 |
1 ジオ冗長性は、顧客管理の計画外フェールオーバー中に失われ、手動で再構成する必要があります。
計画外フェールオーバーの移行の詳細
次の図は、geo 冗長用に構成されたストレージ アカウントの、顧客が管理する計画外のフェールオーバーとフェールバック プロセスを示しています。 GZRS と RA-GZRS の切り替えの詳細は、GRS と RA-GRS とは若干異なります。
通常の運用 (GRS/RA-GRS)
通常の状況では、クライアントはストレージ サービス エンドポイントを通してプライマリ リージョンのストレージ アカウントにデータを書き込みます (1)。 その後、データはプライマリ リージョンからセカンダリ リージョンに非同期的にコピーされます (2)。 次の図は、GRS として構成されたストレージ アカウントの、プライマリ エンドポイントが使用可能な通常状態を示したものです。
ストレージ サービス エンドポイントがプライマリ リージョンで使用できなくなる (GRS/RA-GRS)
プライマリ エンドポイントが何らかの理由で使用不能になると (1)、クライアントはストレージ アカウントに書き込むことができなくなります。 停止の根本原因によっては、セカンダリ リージョンへのレプリケーションが機能しなくなる可能性があるため (2)、何らかのデータ損失を覚悟しておく必要があります。 次の図は、プライマリ エンドポイントが使用できなくなり復旧がまだ行われていないシナリオを示しています:
計画外フェールオーバー プロセス (GRS/RA-GRS)
データへの書き込みアクセスを復元するには、フェールオーバーを開始することができます。 BLOB、テーブル、キュー、ファイルのストレージ サービス エンドポイント URI は変化しませんが、それらの DNS エントリは、以下に示すようにセカンダリ リージョンを指すよう変更されます。
顧客が管理する計画外のフェールオーバーには、通常約 1 時間かかります。
フェールオーバーが完了した後、元のセカンダリが新しいプライマリになり (1)、元のプライマリ内のストレージ アカウントのコピーが削除されます (2)。 新しいプライマリ リージョンでは、ストレージ アカウントは LRS として構成され、geo 冗長ではなくなります。 次の図に示すように、ユーザーはストレージ アカウントへのデータの書き込みを再開できます (3):
新しいセカンダリにレプリケーションを再開するには、geo 冗長用にアカウントを再構成します。
重要
geo 冗長性を使用するようにローカル冗長ストレージ アカウントを変換すると、コストと時間の両方がかかることにご注意ください。 詳しくは、「フェールオーバーの時間とコスト」を参照してください。
GRS を利用するようにアカウントを再構成すると、次の画像に示すように、Azure は新しいセカンダリ リージョン (1) へのデータの非同期コピーを開始します。
ここでも、元の停止を引き起こした問題が解決されるまで、新しいセカンダリ リージョンへの読み取りアクセスは利用できません。
計画外フェールバック プロセス (GRS/RA-GRS)
警告
アカウントが geo 冗長として再構成された後、新しいプライマリ リージョンのデータが新しいセカンダリに完全にコピーされるまでに、かなり時間がかかる場合があります。
大きなデータ損失を防ぐため、フェールバックを行う前に、[最終同期時刻] プロパティの値を確認してください。 最終同期時刻を、新しいプライマリにデータが書き込まれた最後の時刻と比較して、潜在的なデータ損失を評価します。
元の停止を引き起こした問題が解決したら、元のプライマリ リージョンへのフェールバックを開始できます。 フェールバック プロセスは、前に説明した元のフェールオーバー プロセスと同じです。
考慮すべき重要な点は次のとおりです。
- ユーザーが開始したフェールオーバーとフェールバックでは、フェールバック プロセスの間、データはセカンダリ リージョンへのレプリケーションを完了することが許可されません。 そのため、フェールバックを行う前に、[最終同期時刻] プロパティの値を確認することが重要です。
- ストレージ サービス エンドポイントの DNS エントリが切り替えられます。 セカンダリ リージョン内のエンドポイントは、ストレージ アカウントの新しいプライマリ エンドポイントになります。
フェールバックが完了した後、元のプライマリ リージョンが再び現在のプライマリ リージョンになり (1)、元のセカンダリ内のストレージ アカウントのコピーは削除されます (2)。 プライマリ リージョンのストレージ アカウントはローカル冗長として構成され、geo 冗長ではなくなります。 次の図に示すように、ユーザーはストレージ アカウントへのデータの書き込みを再開できます (3):
元のセカンダリ リージョンへのレプリケーションを再開するには、アカウントを geo 冗長として構成します。
重要
geo 冗長性を使用するようにローカル冗長ストレージ アカウントを変換すると、コストと時間の両方がかかることにご注意ください。 詳しくは、「フェールオーバーの時間とコスト」を参照してください。
アカウントを GRS として再構成すると、次の画像に示すように、元のセカンダリ リージョンへのレプリケーションが再開します:
