次の方法で共有

Azure ストレージのディザスター リカバリー計画とフェールオーバー

  • [アーティクル]

Microsoft は、Azure サービスを常に使用できるようにする作業に取り組んでいます。 そうはいっても、計画外のサービス停止が発生する可能性はあります。 優れたディザスター リカバリー計画の主な構成要素には、次のような戦略が含まれます。

この記事では、geo 冗長ストレージ アカウントに使用できるオプションについて説明します。また、高可用性アプリケーションの開発とディザスター リカバリー計画のテストに関する推奨事項を示します。

適切な冗長性オプションを選択する

Azure Storage には、障害が発生した場合でも可用性と持続性の目標が満たされるように、ストレージ アカウントの複数のコピーが保持されています。 データのレプリケート方法により、提供される保護のレベルが異なります。 各オプションには固有の利点があるため、アプリケーションで必要な回復性の程度に応じたオプションを選びます。

最も低コストの冗長オプションであるローカル冗長ストレージ (LRS) は、1 つのデータセンター内にストレージ アカウントの 3 つのコピーを自動的に格納してレプリケートします。 LRS はサーバー ラックやドライブの障害からデータを保護しますが、データセンター内の火災や洪水などの災害には対応していません。 このような災害が発生した場合、LRS を使うように構成されたストレージ アカウントのすべてのレプリカが失われたり、回復できなくなる可能性があります。

それに対し、ゾーン冗長ストレージ (ZRS) は、ストレージ アカウントのコピーを保持し、同じリージョン内の 3 つの異なる可用性ゾーンにレプリケートします。 可用性ゾーンの詳細については、Azure 可用性ゾーンに関するページを参照してください。

GRS とフェールオーバー

geo 冗長ストレージ (GRS)、geo ゾーン冗長ストレージ (GZRS)、読み取りアクセス geo ゾーン冗長ストレージ (RA-GZRS) は、地理的に冗長なストレージ オプションの例です。 geo 冗長ストレージ (GRS、GZRS、RA-GZRS) を使うように構成されていると、Azure はデータをセカンダリ地理的リージョンに非同期的にコピーします。 これらの地域は、数百、または数千マイル離れた場所にあります。 プライマリ リージョン全体の停止が発生した場合でも、このレベルの冗長性であればデータを復旧できます。

LRS や ZRS とは異なり、geo 冗長ストレージでは、プライマリ リージョンで一時的な停止が発生した場合に、セカンダリ リージョンへの計画外のフェールオーバーもサポートされます。 ストレージ アカウントのサービス エンドポイントの DNS (ドメイン ネーム システム) エントリは、フェールオーバー プロセスの間に、セカンダリ リージョンのエンドポイントが新しいプライマリ エンドポイントになるように自動的に更新されます。 計画外のフェールオーバーが完了すると、クライアントは新しいプライマリ エンドポイントへの書き込みを開始できます。

読み取りアクセス geo 冗長ストレージ (RA-GRS) と読み取りアクセス geo ゾーン冗長ストレージ (RA-GZRS) も geo 冗長ストレージを備えていますが、さらに、セカンダリ エンドポイントへの読み取りアクセスという利点があります。 これらのオプションは、高可用性のビジネス クリティカルなアプリケーション向けに設計されたアプリケーションに最適です。 プライマリ エンドポイントで停止が発生した場合、セカンダリ リージョンへの読み取りアクセス用に構成されたアプリケーションは動作し続けることができます。 Microsoft では、ストレージ アカウントの可用性と持続性を最大限に高めるために、RA-GZRS をお勧めします。

Azure Storage の冗長性について詳しくは、「Azure Storage の冗長性」をご覧ください。

フェールオーバーの計画

Azure Storage アカウントでは、3 種類のフェールオーバーがサポートされています。

1 Microsoft が管理するフェールオーバーを、個々のストレージ アカウント、サブスクリプション、またはテナントについて開始することはできません。 詳細については、「Microsoft が管理するフェールオーバー」を参照してください。
2 カスタマーマネージド フェールオーバー オプションを使用して、ディザスター リカバリー計画を開発、テスト、実装します。 Microsoft が管理するフェールオーバーに依存しないでください。これは、やむを得ない場合にのみ使用されます。

それぞれの種類のフェールオーバーには、固有のユース ケースのセット、対応するデータ損失の想定が含まれ、階層型名前空間が有効なアカウント (Azure Data Lake Storage) がサポートされています。 次の表は、フェールオーバーの種類ごとにそれらの側面をまとめたものです。

Type フェールオーバー スコープ 使用例 想定されるデータ損失 階層型名前空間 (HNS) がサポートされています
顧客が管理する計画フェールオーバー (プレビュー) ストレージ アカウント プライマリ リージョンとセカンダリ リージョンのストレージ サービス エンドポイントを利用でき、お客様がディザスター リカバリー テストを実行できます。

プライマリ リージョンのストレージ サービス エンドポイントを使用できますが、他のサービスが理由でワークロードが正常に機能していません。

地域に影響を与える可能性のあるハリケーンなどの大規模な災害に積極的に備えます。		 いいえ はい
(プレビュー段階)
カスタマーマネージド (計画外) フェールオーバー ストレージ アカウント プライマリ リージョンのストレージ サービス エンドポイントは利用できなくなりますが、セカンダリ リージョンは利用できます。

お客様は Azure Advisory を受け取りました。その中で、Microsoft は、停止によって影響を受ける可能性のあるストレージ アカウントのフェールオーバー操作を実行するように助言しています。		 はい はい
(プレビュー段階)
Microsoft 管理 リージョン全体 重大な障害が発生するとプライマリ リージョンは利用できなくなりますが、セカンダリ リージョンは利用できます。 はい はい

次の表では、フェールオーバーの種類ごとにストレージ アカウントの冗長性の状態を比較します。

フェールオーバーの結果 顧客が管理する計画フェールオーバー (プレビュー) カスタマーマネージド (計画外) フェールオーバー
セカンダリ リージョン セカンダリ リージョンが新しいプライマリになります セカンダリ リージョンが新しいプライマリになります
元のプライマリ リージョン 元のプライマリ リージョンが新しいセカンダリになります 元のプライマリ リージョン内のデータのコピーが削除されます
アカウントの冗長構成 ストレージ アカウントが GRS に変換されます ストレージ アカウントが LRS に変換されます
geo 冗長構成 geo 冗長が維持されます geo 冗長が失われます

次の表は、フェールオーバーとフェールバック プロセスの各ステージでの結果の冗長構成を、フェールオーバーの種類ごとにまとめたものです。

変更元
configuration		 の後
failover		 geo 冗長性の
再有効化後		 の後
フェールバック		 geo 冗長性の
再有効化後
顧客が管理する計画フェールオーバー
GRS GRS 該当なし 1 GRS 該当なし 1
GZRS GRS 該当なし 1 GZRS 該当なし 1
カスタマーマネージド (計画外) フェールオーバー
GRS LRS GRS LRS GRS
GZRS LRS GRS ZRS GZRS

1 geo 冗長性は計画フェールオーバー中も保持され、手動で再構成する必要はありません。

顧客が管理する計画フェールオーバー (プレビュー)

計画フェールオーバーは、計画ディザスター リカバリー テスト、大規模な災害に対するプロアクティブなアプローチ、ストレージ関連以外の障害からの復旧など、複数のシナリオで利用できます。

計画フェールオーバー プロセス中に、プライマリ リージョンとセカンダリ リージョンがスワップされます。 元のプライマリ リージョンが降格され、新しいセカンダリ リージョンになります。 同時に、元のセカンダリ リージョンが昇格され、新しいプライマリになります。 フェールオーバーが完了すると、ユーザーは新しいプライマリ リージョンでデータへのアクセスを続けることができ、管理者はディザスター リカバリー計画を検証できます。 計画フェールオーバーを開始するには、プライマリとセカンダリ両方のリージョンでストレージ アカウントを利用できる必要があります。

プライマリとセカンダリ リージョンがプロセス全体を通して利用できる限り、計画フェールオーバーおよびフェールバック プロセス中のデータ損失は想定されていません。 詳細については、「データ損失と不整合の予測」セクションを参照してください。

この種のフェールオーバーがユーザーとアプリケーションに与える影響を理解するには、計画フェールオーバーとフェールバックのプロセスのすべてのステップで何が行われているかを知っておくと役に立ちます。 プロセスのしくみの詳細については、カスタマー マネージド計画フェールオーバーのしくみを参照してください。

重要

カスタマー マネージド計画フェールオーバーは現在プレビュー段階であり、次のリージョンに限り提供されます。

  • フランス中部
  • フランス南部
  • インド中部
  • インド西部
  • 東アジア
  • 東南アジア

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

重要

計画フェールオーバーの後、Azure Files データが存在する場合、ストレージ アカウントの最終同期時刻 (LST) の値が古いように見えたり、NULL として報告されたりする可能性があります。

システム スナップショットは、フェールオーバーとフェールバックの間に使用される一貫性のある復旧ポイントを維持するために、ストレージ アカウントのセカンダリ リージョンに定期的に作成されます。 カスタマーマネージド計画フェールオーバーを開始すると、元のプライマリ リージョンが新しいセカンダリになります。 場合によっては、計画フェールオーバーの完了後に新しいセカンダリ上に利用できるシステム スナップショットが存在しないことが原因で、アカウントの全体的な LST 値が古いままに見えたり、Null と表示されたりします。

オブジェクトの作成、変更、削除などのユーザー アクティビティによってスナップショットの作成をトリガーすることができるため、計画フェールオーバー後にこれらのアクティビティが発生するアカウントでは、特別な注意は必要ありません。 ただし、スナップショットまたはユーザー アクティビティがないアカウントでは、システム スナップショットの作成がトリガーされるまで、Null LST 値が表示され続ける可能性があります。

必要に応じて、ストレージ アカウント内の共有ごとに次のアクティビティのうちいずれかを行い、スナップショット作成をトリガーします。 完了すると、30 分以内に有効な LST 値がアカウントに表示されます。

  • 共有をマウントし、任意のファイルを読み取り用に開きます。
  • テストまたはサンプルのファイルを共有にアップロードします。

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

プライマリ リージョンのストレージ アカウントでストレージ サービス用データ エンドポイントが利用できなくなった場合、セカンダリ リージョンへの計画外フェールオーバーを開始できます。 フェールオーバーが完了すると、セカンダリ リージョンが新しいプライマリになり、ユーザーはそこでデータにアクセスできるようになります。

この種のフェールオーバーがユーザーとアプリケーションに与える影響を理解するには、計画外フェールオーバーとフェールバックのプロセスのすべてのステップで何が行われているかを知っておくと役に立ちます。 プロセスのしくみの詳細については、カスタマーマネージド (計画外) フェールオーバーのしくみを参照してください。

Microsoft が管理するフェールオーバー

Microsoft は、地理的リージョン全体に影響を与える致命的な災害など、極端な状況においてリージョンのフェールオーバーを開始する場合があります。 これらのイベント中、ユーザーは何も行う必要はありません。 ストレージ アカウントが RA-GRS または RA-GZRS 用に構成されている場合、Microsoft が管理するフェールオーバーの間にアプリケーションはセカンダリ リージョンから読み取ることができます。 ただし、フェールオーバー プロセスが完了するまで、ユーザーにストレージ アカウントへの書き込みアクセス権はありません。

重要

カスタマーマネージド フェールオーバー オプションを使用して、ディザスター リカバリー計画を開発、テスト、実装します。 Microsoft が管理するフェールオーバーに依存しないでください。これは、やむを得ない場合にのみ使用されます。 Microsoft マネージド フェールオーバーは、リージョンやデータセンターなどの物理ユニット全体に対して開始されます。 個々のストレージ アカウント、サブスクリプション、またはテナントに対して開始することはできません。 個々のストレージ アカウントを選んでフェールオーバーできる必要がある場合は、顧客が管理する計画フェールオーバーを使います。

データ損失と不整合を予測する

注意事項

通常、計画外のカスタマーマネージド フェールオーバーには、ある程度のデータ損失が伴い、ファイルとデータの不整合が発生するおそれもあります。 ディザスター リカバリー計画では、アカウントのフェールオーバーを始める前に、それがデータに与える影響をよく検討することが重要です。

データはプライマリ リージョンからセカンダリ リージョンに非同期的に書き込まれるため、プライマリ リージョンへの書き込みがセカンダリにコピーされるまでの間に常に遅延があります。 プライマリ リージョンを利用できなくなった場合、最新の書き込みがセカンダリにまだコピーされていない可能性があります。

計画外フェールオーバーが発生すると、セカンダリ リージョンが新しいプライマリ リージョンになるため、プライマリ リージョンのすべてのデータが失われます。 フェールオーバーが発生した時点でセカンダリ リージョンに既にコピーされていたデータはすべて維持されます。 ただし、プライマリに書き込まれたデータのうち、セカンダリ リージョンにまだ存在していないものは、永久に失われます。

フェールオーバー後、新しいプライマリ リージョンはローカルで冗長 (LRS) になるように構成されます。

また、ストレージ アカウントで次のいずれかが有効になっている場合、ファイルやデータの不整合が発生する可能性があります。

最終同期時刻

最終同期時刻プロパティは、プライマリ リージョンのデータがセカンダリ リージョンにも書き込まれた最後の時刻を示します。 階層型名前空間を持つアカウントの場合、同じ最終同期時刻プロパティは、アクセス制御リスト (ACL) を含む階層型名前空間によって管理されるメタデータにも適用されます。 最終同期時刻以前に書き込まれたすべてのデータとメタデータは、セカンダリで使用できます。 これに対し、最終同期時刻より後に書き込まれたデータとメタデータは、まだセカンダリにコピーされていない場合があり、失われる可能性があります。 停止中に、このプロパティを使って、アカウントのフェールオーバーを開始したときに発生する可能性があるデータ損失の量を推定します。

ベスト プラクティスとしては、最終同期時刻を使って予想されるデータ損失を評価できるようにアプリケーションを設計します。 たとえば、すべての書き込み操作をログすると、最後の書き込み操作の時刻と最終同期時刻を比較できます。 この方法を使うと、セカンダリにまだ同期されておらず、失われる危険性がある書き込みを特定できます。

[最終同期時刻] プロパティの詳細については、「ストレージ アカウントの最終同期時刻プロパティを確認する」を参照してください。

Azure Data Lake Storage のファイル整合性

階層型名前空間が有効になっている (Azure Data Lake Storage) ストレージ アカウントのレプリケーションは、ファイル レベルで行われます。 レプリケーションはこのレベルで行われるため、プライマリ リージョンで障害が発生すると、コンテナーまたはディレクトリ内の一部のファイルが、セカンダリ リージョンに正常にレプリケートされない可能性があります。 ストレージ アカウントのフェールオーバーの後で、コンテナーまたはディレクトリ内のすべてのファイルの整合性は保証されません。

変更フィードと BLOB データの不整合

変更フィードが有効になっているストレージ アカウントのカスタマーマネージド (計画外) フェールオーバーでは、変更フィード ログと BLOB データやメタデータの間で不整合が発生する場合があります。 このような不整合は、変更ログの更新およびプライマリとセカンダリ リージョン間のデータ レプリケーションの非同期的な性質が原因で発生する可能性があります。 次の予防措置を講じて、不整合を回避できます。

  • すべてのログ レコードがログ ファイルにフラッシュされていることを確認します。
  • すべてのストレージ データがプライマリからセカンダリ リージョンにレプリケートされていることを確認します。

変更フィードについて詳しくは、「変更フィードのしくみ」をご覧ください。

他のストレージ アカウント機能でも、変更フィードを有効にする必要があることに注意してください。 このような機能としては、Azure Blob Storage の運用バックアップ、オブジェクト レプリケーション、ブロック BLOB のポイントインタイム リストアなどがあります。

ポイントインタイム リストアの不整合

カスタマー マネージド フェールオーバーは、ブロック BLOB を含む汎用 v2 Standard レベルのストレージ アカウントでサポートされています。 ただし、ストレージ アカウントでカスタマー マネージド フェールオーバーを実行すると、そのアカウントの可能な限り最も早い復元ポイントがリセットされます。 ブロック BLOB のポイントインタイム リストアのデータは、フェールオーバーの完了時刻までのみ一貫性があります。 その結果、ブロック BLOB を復元できるのは、フェールオーバーの完了時刻より前の時点に限られます。 フェールオーバーの完了時刻は、Azure portal のストレージ アカウントの [冗長性] タブでチェックできます。

フェールオーバーの時間とコスト

カスタマーマネージド フェールオーバーが開始から完了するまでにかかる時間はさまざまですが、通常は 1 時間未満です。

計画されたカスタマーマネージド フェールオーバーでは、フェールオーバーとその後のフェールバック後の geo 冗長性は失われませんが、計画外のカスタマーマネージド フェールオーバーでは失われます。

カスタマー マネージド計画外フェールオーバーを開始すると、ストレージ アカウントが新しいプライマリ リージョン内のローカル冗長ストレージ (LRS) に自動的に変換され、元のプライマリ リージョンのストレージ アカウントが削除されます。

アカウントで geo 冗長ストレージ (GRS) または読み取りアクセス geo 冗長ストレージ (RA-GRS) を再び有効にできますが、新しいセカンダリ リージョンにデータを再レプリケートすると料金が発生します。 さらに、アカウントを geo 冗長に再構成する前に、アーカイブされたすべての BLOB をオンライン層にリハイドレートする必要があります。 このリハイドレートでも追加料金が発生します。 価格の詳細については、以下を参照してください。

ストレージ アカウントの GRS を再度有効にすると、アカウント内のデータの新しいセカンダリ リージョンへのレプリケートが開始されます。 レプリケーションの完了までに要する時間は、いくつかの要因によって変わります。 たとえば、以下の要素について考慮します。

  • ストレージ アカウント内のオブジェクトの数とサイズ。 数の多い小さなオブジェクトのレプリケートは、数の少ない大きなオブジェクトのレプリケートよりも時間がかかる場合があります。
  • CPU、メモリ、ディスク、WAN の容量など、バックグラウンド レプリケーションに使用できるリソース。 ライブ トラフィックは geo レプリケーションよりも優先されます。
  • BLOB あたりのスナップショットの数 (該当する場合)。
  • データ パーティション分割戦略 (ストレージ アカウントに表が含まれている場合)。 レプリケーション プロセスでは、使用するパーティション キーの数を超えて拡張することはできません。

サポートされるストレージ アカウントの種類

すべての geo 冗長性のオファリングは、Microsoftが管理するフェールオーバーをサポートしています。 さらに、次の表に示すように、一部のアカウントの種類では、カスタマー マネージド アカウントのフェールオーバーがサポートされます。

フェールオーバーの種類 GRS/RA-GRS GZRS/RA-GZRS
顧客が管理する計画フェールオーバー (プレビュー) 汎用 v2 アカウント
汎用 v1 アカウント
レガシ Blob Storage アカウント		 汎用 v2 アカウント
カスタマーマネージド (計画外) フェールオーバー 汎用 v2 アカウント
汎用 v1 アカウント
レガシ Blob Storage アカウント		 汎用 v2 アカウント
Microsoft マネージド フェールオーバー すべてのアカウントの種類 汎用 v2 アカウント

従来のストレージ アカウント

重要

カスタマーマネージド フェールオーバーは、Azure Resource Manager (ARM) デプロイ モデルを使用してデプロイされたストレージ アカウントでのみサポートされます。 Azure Service Manager (ASM) デプロイ モデル ("クラシック" モデルとも呼ばれます) はサポートされていません。 クラシック ストレージ アカウントをカスタマー マネージド アカウントフェールオーバーの対象にするには、まず ARM モデルに移行する必要があります。 アップグレードを実行するには、ストレージ アカウントにアクセスできる必要があります。そのため、プライマリ リージョンが現在失敗状態の場合は実行できません。

プライマリ リージョンに影響する災害の間、クラシック ストレージ アカウントのフェールオーバーは Microsoft が管理します。 詳細については、「Microsoft が管理するフェールオーバー」を参照してください。

階層型名前空間 (HNS)

重要

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

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

重要

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

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

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

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

サポートされていない機能とサービス

次の機能とサービスは、カスタマーマネージド フェールオーバーではサポートされていません。

  • Azure File Sync では、カスタマーマネージド アカウントのフェールオーバーはサポートされていません。 Azure File Sync のクラウド エンドポイントとして使用されるストレージ アカウントは、フェールオーバーしないでください。 フェールオーバーによってファイルの同期が中断され、新しく階層化されたファイルの予期しないデータ損失が発生するおそれがあります。 詳細については、「Azure File Sync を使用したディザスター リカバリーのベスト プラクティス」をご覧ください。
  • Premium ブロック BLOB 含むストレージ アカウントは、フェールオーバーできません。 現在、Premium ブロック BLOB をサポートするストレージ アカウントでは、geo 冗長がサポートされていません。
  • カスタマー マネージド フェールオーバーは、オブジェクト レプリケーション ポリシーのソース アカウントまたは宛先アカウントのいずれでもサポートされていません。
  • ネットワーク ファイル システム (NFS) 3.0 (NFSv3) は、ストレージ アカウントのフェールオーバーではサポートされていません。 NFSv3 を有効にして geo 冗長性のために構成されたストレージ アカウントを作成することはできません。

機能のサポートの参照用に、次の表を使用してください。

計画されたフェールオーバー 計画外のフェールオーバー
Azure Data Lake Storage サポートされています (プレビュー) サポートされています (プレビュー)
変更フィード サポートされていない サポートされています
オブジェクト レプリケーション サポートされていない サポートされていない
SFTP サポートされています (プレビュー) サポートされています (プレビュー)
NFSv3 GRS はサポートされていません GRS はサポートされていません
ストレージ アクション サポート1 サポート1
ポイントインタイム復元 (PITR) サポートされていない サポートされています

1 カスタマー マネージドの計画されたフェールオーバーまたは計画外のフェールオーバーを開始した場合、ストレージ タスクは元のプライマリ リージョンにフェールバックするまでアカウントで動作できません。 詳細情報。

フェールオーバーはアカウント移行のためのものではない

ストレージ アカウントのフェールオーバーは、ディザスター リカバリー (DR) プランの開発とテスト、またはサービス停止からの復旧に使用される一時的なソリューションです。 フェールオーバーを、データ移行戦略の一環として使用しないでください。 ストレージ アカウントを移行する方法の詳細については、「Azure Storage の移行の概要」を参照してください。

アーカイブ済みの BLOB を含むストレージ アカウント

アーカイブ済みの BLOB を含むストレージ アカウントでは、アカウントのフェールオーバーがサポートされます。 ただし、顧客が管理するフェールオーバーが完了したら、アカウントを geo 冗長に構成する前に、アーカイブされたすべての BLOB をオンライン層にリハイドレートする必要があります。

ストレージ リソース プロバイダー

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 プロパティは、フェールオーバーの完了後、元のプライマリの場所を返します。

Azure 仮想マシン

Azure 仮想マシン (VM) は、ストレージ アカウントのフェールオーバーの一環としてフェールオーバーしません。 障害への対応でセカンダリ リージョンにフェールオーバーする VM は、フェールオーバーの完了後に作成し直す必要があります。 アカウントのフェールオーバーにより、仮想マシン (VM) がシャットダウンされると、一時ディスクに格納されているデータが失われる可能性があります。 Microsoft では、次に示す Azure の仮想マシンに固有の高可用性とディザスター リカバリーのガイダンスを推奨しています。

Azure アンマネージド ディスク

アンマネージド ディスクは、Azure Storage にページ BLOB として格納されます。 VM が Azure で実行されていると、VM にアタッチされているアンマネージド　ディスクはリースされます。 BLOB にリースがある場合、アカウントのフェールオーバーは続行できません。 Azure VM にアタッチされたアンマネージド ディスクを含むアカウントでフェールオーバーを開始するには、その前にディスクをシャットダウンする必要があります。 このため、Microsoft がお勧めするベスト プラクティスには、アンマネージド ディスクからマネージド ディスクへの変換が含まれます。

アンマネージド ディスクを含むアカウントでフェールオーバーを実行するには、次の手順のようにします。

  1. 始める前に、アンマネージド ディスクの名前、その論理ユニット番号 (LUN)、ディスクがアタッチされている VM を記録しておきます。 そうすることで、フェールオーバー後にディスクを再アタッチするのが容易になります。
  2. VM をシャット ダウンします。
  3. VM を削除します。ただし、アンマネージド ディスクの仮想ハード ディスク (VHD) ファイルは残しておきます。 VM を削除した時刻を記録しておきます。
  4. 最終同期時刻が更新されるまで待ち、VM を削除した時刻より後であることを確認します。 このステップでは、フェールオーバー発生時にセカンダリ エンドポイントが VHD ファイルで完全に更新されたことと、新しいプライマリ リージョンで VM が正常に機能することを確認します。
  5. アカウントのフェールオーバーを開始します。
  6. アカウントのフェールオーバーが完了し、セカンダリ リージョンが新しいプライマリ リージョンになるまで待ちます。
  7. 新しいプライマリ リージョンで VM を作成し、VHD を再アタッチします。
  8. 新しい VM を起動します。

VM をシャットダウンすると、一時ディスクに格納されているすべてのデータが失われることに留意してください。

フェールオーバーの代替手段としてデータをコピーする

前述したように、セカンダリ リージョンへの読み取りアクセス用に構成されたストレージ アカウントを使うようにアプリケーションを構成すると、高可用性を維持できます。 ただし、プライマリ リージョン内の停止中にフェールオーバーしない方がよい場合は、代わりにデータを手動でコピーできます。 AzCopy や Azure PowerShell などのツールを使うと、影響を受けたリージョンのストレージ アカウントから、影響を受けていないリージョンの別のストレージ アカウントに、データをコピーできます。 コピー操作が完了したら、読み取りと書き込み両方の可用性のため、影響を受けていないリージョンのストレージ アカウントを使うようにアプリケーションを再構成できます。

高可用性向けの設計

最初から高可用性対応にアプリケーションを設計することが重要です。 アプリケーションの設計とディザスター リカバリーの計画に関するガイダンスについては、次の Azure リソースをご覧ください。

Azure Storage のデータの高可用性の維持については、次のベスト プラクティスをご覧ください。

  • ディスク:Azure Backup を使用して、Azure 仮想マシンで使用される VM ディスクをバックアップします。 また、Azure Site Recovery を使ってリージョンの障害から VM を保護することも検討します。
  • ブロック BLOB:ソフト削除を有効にしてオブジェクトレベルの削除および上書きから保護するか、AzCopy、Azure PowerShell、または Azure Data Movement Library を使用して、他のリージョンの別のストレージ アカウントにブロック BLOB をコピーします。
  • ファイル:Azure Backup を使用して、ファイル共有をバックアップします。 また、予期しないファイル共有の削除を防ぐために、論理的な削除も有効にします。 GRS を使用できないときの geo 情報の場合は、AzCopy または Azure PowerShell を使用して、異なるリージョンの別のストレージ アカウントにファイルをコピーすることができます。
  • テーブル:AzCopy を使用して、テーブル データを、他のリージョンの別のストレージ アカウントにエクスポートします。

障害を追跡する

お客様は、Azure Service Health ダッシュボードをサブスクライブして、Azure Storage と他の Azure サービスの正常性と状態を追跡できます。

また、書き込みエラーの可能性に対処するようアプリケーションを設計することもお勧めします。 アプリケーションでは、プライマリ リージョンでの障害の可能性があることを通知するように書き込みエラーを公開する必要があります。

関連項目