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

  • [アーティクル]

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

この記事では、グローバル冗長ストレージ アカウント (GRS、GZRS、RA-GZRS) のフェールオーバーに焦点を当て、障害が発生し、その後にフェールオーバーが発生した場合に、高可用性のアプリケーションを設計する方法について説明します。

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

Azure Storage は、持続性と高可用性を確保するために、ストレージ アカウントの複数のコピーを保持します。 アカウントに対して選択する冗長性オプションは、アプリケーションに必要な回復性の程度によって異なります。

ローカル冗長ストレージ (LRS) を使用すると、ストレージ アカウントの 3 つのコピーが単一のデータセンター内に自動的に格納され、レプリケートされます。 ゾーン冗長ストレージ (ZRS) では、同一リージョン内の 3 つの可用性ゾーンのそれぞれにコピーが格納され、レプリケートされます。 可用性ゾーンの詳細については、Azure 可用性ゾーンに関するページを参照してください。

ストレージ アカウントの単一コピーの復旧は、LRS と ZRS で自動的に行われます。

グローバル冗長ストレージとフェールオーバー

グローバル冗長ストレージ (GRS、GZRS、RA-GZRS) を使用して、Azure はデータを少なくとも数百マイル離れたセカンダリ地理的リージョンに非同期でコピーします。 これにより、プライマリ リージョンで障害が発生した場合でも、データを回復できます。 グローバル冗長ストレージの LRS や ZRS と異なる特徴は、プライマリ リージョンに障害が発生した場合にセカンダリ リージョンにフェールオーバーできることです。 フェールオーバーのプロセスは、セカンダリ リージョンのエンドポイントがストレージ アカウントの新しいプライマリ エンドポイントになるように、ストレージ サービス エンドポイントの DNS エントリを更新します。 フェールオーバーが完了すると、クライアントは新しいプライマリ エンドポイントへの書き込みを開始できます。

RA-GRS および RA-GZRS 冗長構成では、プライマリ リージョンで障害が発生した場合、セカンダリ エンドポイントに読み取りアクセスの利点が追加された geo 冗長ストレージが提供されます。 プライマリ エンドポイントで障害が発生した場合、セカンダリ リージョンに対する読み取りアクセス用に構成され、高可用性対応に設計されているアプリケーションでは、セカンダリ エンドポイントから引き続き読み取ることができます。 Microsoft では、ストレージ アカウントの可用性と持続性を最大限に高めるために、RA-GZRS をお勧めします。

Azure Storage での冗長性の詳細については、「Azure Storage の冗長性」を参照してください。

ストレージ アカウント フェールオーバーの計画

Azure Storage アカウントは、次の 2 種類のフェールオーバーをサポートしています。

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

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

Type フェールオーバー スコープ 使用例 想定されるデータ損失 HNS サポート対象
顧客管理 ストレージ アカウント プライマリ リージョンのストレージ サービス エンドポイントは利用できなくなりますが、セカンダリ リージョンは利用できます。

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

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

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

カスタマー マネージド アカウントのフェールオーバーがユーザーとアプリケーションに与える影響を完全に理解するには、フェールオーバーとフェイルバックのプロセスの各手順で発生している内容を把握することが役立ちます。 プロセスのしくみの詳細については、カスタマー マネージド ストレージ アカウントのフェールオーバーのしくみを参照してください。

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

大規模な障害により元のプライマリ リージョンが妥当な時間内に回復できないと判断されるやむを得ない場合では、Microsoft はリージョン フェールオーバーを開始することがあります。 この場合、ユーザーによる操作は必要ありません。 Microsoft 管理のフェールオーバーが完了するまで、ストレージ アカウントに書き込みアクセスを行うことはできません。 ストレージ アカウントが RA-GRS または RA-GZRS 対応に構成されている場合は、アプリケーションはセカンダリ リージョンから読み取ることができます。

重要

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

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

注意事項

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

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

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

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

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

最終同期時刻

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

ベスト プラクティスとしては、最終同期時刻を使用して予想されるデータ損失を評価できるようにアプリケーションを設計します。 たとえば、すべての書き込み操作をログに記録している場合は、最後の書き込み操作の時刻を最終同期時刻と比較することで、セカンダリに同期されていない書き込みを特定できます。

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

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

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

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

変更フィードが有効になっている geo 冗長ストレージ アカウントのストレージ アカウント フェールオーバーでは、変更フィード ログと BLOB データまたはメタデータの間で不整合が発生する場合があります。 このような不整合は、変更ログに対する更新と、プライマリからセカンダリ リージョンへの BLOB データのレプリケーションの両方の非同期性によって発生する可能性があります。 不整合が予想されない唯一の状況は、現在のすべてのログ レコードがログ ファイルに正常にフラッシュされ、すべてのストレージ データがプライマリからセカンダリ リージョンに正常にレプリケートされた場合です。

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

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

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

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

たとえば、保持期間を 30 日に設定したとします。 フェールオーバーから 30 日以上経過した場合は、その 30 日以内の任意の時点に復元できます。 ただし、フェールオーバーから 30 日経過していない場合は、保持期間に関係なく、フェールオーバーより前のポイントまで復元することはできません。 たとえば、フェールオーバーから 10 日経っている場合、可能な限り最も早い復元ポイントは過去 30 日間ではなく、過去 10 日間です。

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

フェールオーバーが開始してから完了するまでの所要時間はさまざまですが、通常は 1 時間未満です。

顧客が管理するフェールオーバーは、フェールオーバー (およびフェイルバック) 後に geo 冗長性を失います。 ストレージ アカウントは、フェールオーバー中に新しいプライマリ リージョンのローカル冗長ストレージ (LRS) に自動的に変換され、元のプライマリ リージョンのストレージ アカウントは削除されます。

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

ストレージ アカウントの GRS を再度有効にすると、アカウント内のデータの新しいセカンダリ リージョンへのレプリケートが開始されます。 レプリケーション時間は、次のような多くの要因に依存します。

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

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

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

フェールオーバーの種類 GRS/RA-GRS GZRS/RA-GZRS
カスタマー マネージド フェールオーバー 汎用 v2 アカウント
汎用 v1 アカウント
レガシ Blob Storage アカウント		 汎用 v2 アカウント
Microsoft マネージド フェールオーバー すべてのアカウントの種類 汎用 v2 アカウント

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

重要

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

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

Azure Data Lake Storage Gen2

重要

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

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

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

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

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

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

次の機能とサービスは、アカウントのフェールオーバーではサポートされていません。

  • Azure File Sync では、お客様が開始するストレージ アカウントのフェールオーバーはサポートされていません。 Azure File Sync でクラウド エンドポイントとして使用されている Azure ファイル共有を含むストレージ アカウントは、フェールオーバーしないでください。 それを行うと、同期の動作が停止し、新しく階層化されたファイルの場合は予期せずデータが失われる可能性があります。 詳細については、「Azure File Sync を使用したディザスター リカバリーのベスト プラクティス」をご覧ください。
  • Premium ブロック BLOB 含むストレージ アカウントは、フェールオーバーできません。 現在、Premium ブロック BLOB をサポートするストレージ アカウントでは、geo 冗長がサポートされていません。
  • カスタマー マネージド フェールオーバーは、オブジェクト レプリケーション ポリシーのソース アカウントまたは宛先アカウントのいずれでもサポートされていません。
  • SSH ファイル転送プロトコル (SFTP) が有効になっているアカウントをフェールオーバーするには、まず アカウントの SFTP を無効にする必要があります。 フェールオーバーが完了した後に SFTP の使用を再開する場合は、これを再度有効にします。
  • ネットワーク ファイル システム (NFS) 3.0 (NFSv3) は、ストレージ アカウントのフェールオーバーではサポートされていません。 NFSv3 を有効にしてグローバル冗長性のために構成されたストレージ アカウントを作成することはできません。

フェールオーバーはアカウント移行のためのものではありません

ストレージ アカウントのフェールオーバーは、データ移行戦略の一環として使用しないでください。 フェールオーバーは、サービス停止の一時的なソリューションです。 ストレージ アカウントを移行する方法の詳細については、「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 を再作成する必要があります。 また、アカウントのフェールオーバーに関連したデータ損失の可能性があります。 Microsoft では、次に示す Azure の仮想マシンに固有の高可用性とディザスター リカバリーのガイダンスを推奨しています。

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

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

ベスト プラクティスとして、アンマネージド ディスクをマネージド ディスクに変換することをお勧めします。 ただし、Azure VM にアタッチされているアンマネージド ディスクを含むアカウントをフェールオーバーする必要がある場合は、フェールオーバーを始める前に、VM をシャットダウンする必要があります。

アンマネージド ディスクは、Azure Storage にページ BLOB として格納されます。 VM が Azure で実行されていると、VM にアタッチされているアンマネージド　ディスクはリースされます。 BLOB にリースがある場合、アカウントのフェールオーバーは続行できません。 フェールオーバーを実行するには、次の手順のようにします。

  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 サービスの正常性と状態を追跡できます。

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

関連項目