ストレージアカウントのカスタマーマネージドフェールオーバーのしくみ

[アーティクル]
10/23/2023

Azure ストレージアカウントのカスタマーマネージドフェールオーバーを使うと、プライマリリージョンのストレージサービスエンドポイントが使用できなくなった場合に、geo 冗長ストレージアカウント全体をセカンダリリージョンにフェールオーバーできます。フェールオーバーの間に、元のセカンダリリージョンが新しいプライマリになり、BLOB、テーブル、キュー、ファイルのすべてのストレージサービスエンドポイントが、新しいプライマリリージョンにリダイレクトされます。ストレージサービスエンドポイントの停止が解決されたら、別のフェールオーバー操作を実行して、元のプライマリリージョンに "フェールバック" できます。

この記事では、ストレージアカウントのカスタマーマネージドフェールオーバーとフェールバックのプロセスのすべてのステージで行われることについて説明します。

重要

階層型名前空間 (Azure Data Lake Storage Gen2) を持つアカウントのカスタマーマネージドアカウントフェールオーバーは現在プレビュー段階であり、次のリージョンでのみサポートされています。

(アジア太平洋) インド中部
(アジア太平洋) 東南アジア
(ヨーロッパ) 北ヨーロッパ
(ヨーロッパ) スイス北部
(ヨーロッパ) スイス西部
(ヨーロッパ) 西ヨーロッパ
(北米) カナダ中部
(北米)米国東部 2
(北米) 米国中南部

プレビューにオプトインする方法については、「Azure サブスクリプションでプレビュー機能を設定する」を参照してください。機能名は AllowHNSAccountFailover を指定します。

ベータ版、プレビュー版、または一般提供としてまだリリースされていない Azure の機能に適用される法律条項については、「Microsoft Azure プレビューの追加使用条件」を参照してください。

プライマリリージョンに影響する重大な障害が発生した場合、Microsoft は階層型名前空間を持つアカウントのフェールオーバーを管理します。詳細については、「Microsoft が管理するフェールオーバー」を参照してください。

フェールオーバーとフェールバックの間の冗長性管理

ヒント

ストレージアカウントのフェールオーバーとフェールバックのプロセス中のさまざまな冗長性状態を詳しく理解するには、「Azure Storage の冗長性」でそれぞれの定義をご覧ください。

ストレージアカウントが GRS または RA-GRS の冗長性用に構成されている場合、データはプライマリとセカンダリ両方のリージョン内でローカルに 3 回レプリケートされます (LRS)。ストレージアカウントが GZRS または RA-GZRS のレプリケーション用に構成されている場合、データはプライマリリージョン内ではゾーン冗長になり (ZRS)、セカンダリリージョン内ではローカルに 3 回レプリケートされます (LRS)。アカウントが読み取りアクセス (RA) 用に構成されている場合は、セカンダリリージョンへのストレージサービスエンドポイントが使用可能である限り、そのリージョンからデータを読み取ることができます。

カスタマーマネージドフェールオーバープロセスの間に、ストレージサービスエンドポイントの DNS エントリは、セカンダリリージョンのエンドポイントがストレージアカウントの新しいプライマリエンドポイントになるように変更されます。フェールオーバーの後、元のプライマリリージョンのストレージアカウントのコピーは削除され、ストレージアカウントは元のセカンダリリージョン (新しいプライマリ) 内で引き続きローカルに 3 回レプリケートされます。その時点で、ストレージアカウントはローカル冗長 (LRS) になります。

ストレージアカウントのプロパティには元と現在の冗長性構成が格納されているため、フェールバック時には、最終的に元の構成に戻ることができます。

フェールオーバーの後で geo 冗長性を回復するには、アカウントを GRS として再構成する必要があります。 (新しいプライマリはフェールオーバー後に LRS になるため、フェールオーバー後に GZRS にすることはできません)。アカウントが geo 冗長として再構成されると、Azure はすぐに新しいプライマリリージョンから新しいセカンダリへのデータのコピーを開始します。セカンダリリージョンに対する読み取りアクセス (RA) 用にストレージアカウントを構成した場合、そのアクセスは使用できるようになりますが、プライマリからのレプリケーションによってセカンダリが最新になるまでに時間がかかる場合があります。

警告

アカウントが geo 冗長として再構成された後、新しいプライマリリージョンの既存のデータが新しいセカンダリに完全にコピーされるまでに、かなり時間がかかる場合があります。

大きなデータ損失を防ぐため、フェールバックを行う前に、最終同期時刻プロパティの値を確認してください。最終同期時刻を、データが新しいプライマリに最後に書き込まれた時刻と比較して、失われる可能性のあるデータを評価します。

フェールバックプロセスは、基本的にはフェールオーバープロセスと同じですが、Azure によってレプリケーションの構成がフェールオーバー前の元の状態に復元される点が異なります (データではなくレプリケーション構成)。そのため、ストレージアカウントがもともと GZRS として構成されていた場合、フェールバック後のプライマリリージョンは ZRS になります。

フェールバックの後で、ユーザーはストレージアカウントを geo 冗長として再び構成できます。元のプライマリリージョンが LRS 用に構成されていた場合は、GRS または RA-GRS として構成できます。元のプライマリが ZRS として構成されていた場合は、GZRS または RA-GZRS として構成できます。その他のオプションについては、「ストレージアカウントがレプリケートされる方法を変更する」を参照してください。

フェールオーバーを開始する方法

フェールオーバーを開始する方法については、「ストレージアカウントのフェールオーバーを開始する」をご覧ください。

注意事項

通常、ストレージアカウントのフェールオーバーには、ある程度のデータ損失が伴い、ファイルとデータの不整合が発生する可能性があります。アカウントのフェールオーバーを始める前に、それがデータに与える影響をよく理解することが重要です。

データ損失と不整合の可能性について詳しくは、「データ損失と不整合を予測する」をご覧ください。

フェールオーバーとフェールバックのプロセス

このセクションでは、カスタマーマネージドフェールオーバーのフェールオーバープロセスの概要を示します。

フェールオーバーの切り替えの概要

カスタマーマネージドフェールオーバーの後:

セカンダリリージョンが新しいプライマリになります
元のプライマリリージョン内のデータのコピーが削除されます
ストレージアカウントが LRS に変換されます
geo 冗長が失われます

次の表は、カスタマーマネージドフェールオーバーとフェールバックのすべてのステージで得られる冗長性の構成をまとめたものです。

変更元 configuration	の後 failover	geo 冗長性の再有効化後	の後フェールバック	geo 冗長性の再有効化後
GRS	LRS	GRS ¹	LRS	GRS ¹
GZRS	LRS	GRS ¹	ZRS	GZRS ¹

¹ geo 冗長性は、カスタマーマネージドフェールオーバーの間に失われ、手動で再構成する必要があります。

フェールオーバーの切り替えの詳細

次の図は、geo 冗長として構成されたストレージアカウントのカスタマーマネージドフェールオーバーとフェールバックの間に行われることを示したものです。 GZRS と RA-GZRS の切り替えの詳細は、GRS と RA-GRS とは若干異なります。

GRS/RA-GRS
GZRS/RA-GZRS

通常の動作 (GRS/RA-GRS)

通常の状況では、クライアントはストレージサービスエンドポイントを通してプライマリリージョンのストレージアカウントにデータを書き込みます (1)。その後、データはプライマリリージョンからセカンダリリージョンに非同期的にコピーされます (2)。次の図は、GRS として構成されたストレージアカウントの、プライマリエンドポイントが使用可能な通常状態を示したものです。

ストレージサービスエンドポイントがプライマリリージョンで使用できなくなる (GRS/RA-GRS)

何らかの理由でプライマリストレージサービスエンドポイントが使用できなくなった場合 (1)、クライアントはストレージアカウントに書き込むことができなくなります。障害の根本的な原因によっては、セカンダリリージョンへのレプリケーションが機能しなくなる可能性があるので (2)、ある程度のデータ損失を予測する必要があります。次の図は、プライマリエンドポイントが使用できなくなり、復旧がまだ行われていないシナリオを示しています。

フェールオーバープロセス (GRS/RA-GRS)

データへの書き込みアクセスを復元するには、フェールオーバーを開始することができます。次の図に示すように、BLOB、テーブル、キュー、ファイルのストレージサービスエンドポイントの URI は変わりませんが、それらの DNS エントリはセカンダリリージョンを指すように変更されます (1)。

通常、カスタマーマネージドフェールオーバーには約 1 時間かかります。

フェールオーバーが完了した後、元のセカンダリが新しいプライマリになり (1)、元のプライマリにあったストレージアカウントのコピーは削除されます (2)。新しいプライマリリージョンでは、ストレージアカウントは LRS として構成され、geo 冗長ではなくなります。次の図に示すように、ユーザーはストレージアカウントへのデータの書き込みを再開できます (3)。

新しいセカンダリリージョンへのレプリケーションを再開するには、アカウントを geo 冗長用に再構成します。

重要

geo 冗長性を使用するようにローカル冗長ストレージアカウントを変換すると、コストと時間の両方がかかることにご注意ください。詳しくは、「フェールオーバーの時間とコスト」をご覧ください。

次の図に示すように、アカウントを GRS として再構成すると、Azure は新しいセカンダリリージョンへのデータの非同期コピーを開始します (1)。

元の停止の原因となった問題が解決されるまで、新しいセカンダリリージョンへの読み取りアクセスは再び使用できるようになりません。

フェールバックプロセス (GRS/RA-GRS)

警告

アカウントが geo 冗長として再構成された後、新しいプライマリリージョンのデータが新しいセカンダリに完全にコピーされるまでに、かなり時間がかかる場合があります。

元の停止の原因になった問題が解決したら、別のフェールオーバーを開始して元のプライマリリージョンにフェールバックできます。その結果、次のようになります。

現在のプライマリリージョンは読み取り専用になります。
お客様が開始したフェールオーバーとフェールバックでは、フェールバックプロセスの間、セカンダリリージョンへのデータのレプリケートは完了できません。そのため、フェールバックを行う前に、最終同期時刻プロパティの値を確認することが重要です。
ストレージサービスエンドポイントの DNS エントリは、セカンダリリージョンのエンドポイントがストレージアカウントの新しいプライマリエンドポイントになるように変更されます。

フェールバックが完了した後、元のプライマリリージョンが再び現在のプライマリリージョンになり (1)、元のセカンダリ内のストレージアカウントのコピーは削除されます (2)。プライマリリージョンでは、ストレージアカウントはローカル冗長として構成され、geo 冗長ではなくなります。次の図に示すように、ユーザーはストレージアカウントへのデータの書き込みを再開できます (3)。