カスタマーマネージド (計画外) フェールオーバーのしくみ

[アーティクル]
08/12/2024

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

この記事では、カスタマーマネージド (計画外) フェールオーバーとフェールバックの間、プロセスの各ステージで何が起きるのかを説明します。

重要

Azure Data Lake Storage Gen2 が有効になっているアカウントのカスタマーマネージド (計画外) フェールオーバーは、現在プレビュー段階であり、すべてのパブリック GRS/GZRS リージョンでサポートされています。

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

重要

SSH ファイル転送プロトコル (SFTP) が有効になっているアカウントに対する顧客管理 (計画外の) フェールオーバーは現在プレビュー段階であり、すべての GRS/GZRS リージョンでサポートされています。

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

ヒント

計画外フェールオーバーおよびフェールバックプロセス中のさまざまな冗長性状態の詳細を理解するには、「Azure Storage の冗長性」を参照してそれぞれの定義を確認してください。

ストレージアカウントが geo 冗長ストレージ (GRS) または読み取りアクセス geo 冗長ストレージ (RA-GRS) 冗長として構成されている場合、ローカル冗長ストレージ (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 冗長が失われます

次の表は、カスタマーマネージド (計画外) フェールオーバーとフェールバックのすべてのステージにおける冗長構成の状態をまとめたものです。

変更元 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)、元のプライマリ内のストレージアカウントのコピーは削除されます (2)。新しいプライマリリージョンでは、ストレージアカウントは LRS として構成され、geo 冗長ではなくなります。次の図に示すように、ユーザーはストレージアカウントへのデータの書き込みを再開できます (3)。

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

重要

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

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

ここでも、元の停止を引き起こした問題が解決されるまで、新しいセカンダリリージョンへの読み取りアクセスは利用できません。

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

警告

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

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

元の停止を引き起こした問題が解決したら、元のプライマリリージョンへのフェールバックを開始できます。次の画像はこのプロセスを説明したものです。

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

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