ディザスター リカバリーとストレージ アカウントのフェールオーバー

  • [アーティクル]

Microsoft は、Azure サービスを常に使用できるようにする作業に取り組んでいます。 そうはいっても、計画されていないサービスの停止が発生する可能性はあります。 アプリケーションで回復性が必要な場合は、geo 冗長ストレージを使用して、データが 2 番目のリージョンにコピーされるようにすることをお勧めします。 さらに、お客様は、リージョン規模のサービス停止に対処するため、ディザスター リカバリー計画を用意する必要があります。 ディザスター リカバリー計画の重要な部分は、プライマリ エンドポイントが使用できなくなった場合に、セカンダリ エンドポイントにフェールオーバーするための準備です。

Azure Storage では、geo 冗長ストレージ アカウントのアカウント フェールオーバーがサポートされています。 アカウントのフェールオーバーでは、プライマリ エンドポイントが使用できなくなった場合に、ストレージ アカウントのフェールオーバー プロセスを開始できます。 フェールオーバーでは、セカンダリ エンドポイントが更新されて、ストレージ アカウントのプライマリ エンドポイントになります。 フェールオーバーが完了すると、クライアントは新しいプライマリ エンドポイントへの書き込みを開始できます。

アカウント フェールオーバーは、Azure Resource Manager デプロイを使用する汎用 v1、汎用 v2、および BLOB Storage アカウントの種類で使用できます。 階層型名前空間が有効になっているストレージ アカウントでは、アカウントのフェールオーバーはサポートされていません。

この記事では、アカウントのフェールオーバーに関する概念とプロセスについて、および顧客への影響が最小限になるようにストレージ アカウントの復旧を準備する方法について説明します。 Azure portal または PowerShell でアカウントのフェールオーバーを開始する方法については、アカウントのフェールオーバーの開始に関するページを参照してください。

Note

Azure を操作するには、Azure Az PowerShell モジュールを使用することをお勧めします。 作業を開始するには、Azure PowerShell のインストールに関する記事を参照してください。 Az PowerShell モジュールに移行する方法については、「AzureRM から Az への Azure PowerShell の移行」を参照してください。

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

Azure Storage は、持続性と高可用性を確保するために、ストレージ アカウントの複数のコピーを保持します。 アカウントに対して選択する冗長性オプションは、必要な回復性の程度によって異なります。 リージョン規模の障害に対する保護の場合は、geo 冗長ストレージ用にアカウントを構成し、セカンダリ リージョンからの読み取りアクセスのオプションは指定しても指定しなくてもかまいません。

geo 冗長ストレージ (GRS) または geo ゾーン冗長ストレージ (GZRS) では、少なくとも数百マイル離れた 2 つの地理的リージョンにデータが非同期的にコピーされます。 プライマリ リージョンで障害が発生した場合、セカンダリ リージョンがデータの冗長ソースとして機能します。 ユーザーがフェールオーバーを開始して、セカンダリ エンドポイントをプライマリ エンドポイントに変換することができます。

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

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

警告

geo 冗長ストレージでは、データ損失のリスクが伴います。 データはセカンダリ リージョンに非同期的にコピーされるため、データがプライマリ リージョンに書き込まれてからセカンダリ リージョンに書き込まれるまでの間に遅延があります。 障害が発生した時点で、セカンダリ エンドポイントにまだコピーされていないプライマリ エンドポイントへの書き込み操作は失われます。

高可用性向けの設計

最初から高可用性対応にアプリケーションを設計することが重要です。 アプリケーションの設計およびディザスター リカバリーの計画に関するガイダンスについては、次の 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 サービスの正常性と状態を追跡できます。

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

アカウントのフェールオーバー プロセスを理解する

お客様が管理するアカウントのフェールオーバーでは、何らかの理由でプライマリが使用できなくなった場合、ストレージ アカウント全体をセカンダリ リージョンにフェールオーバーすることができます。 セカンダリ リージョンへのフェールオーバーを強制的に実行すると、クライアントは、フェールオーバー完了後にセカンダリ エンドポイントへのデータの書き込みを開始することができます。 フェールオーバーには、通常、約 1 時間かかります。

Note

カスタマー マネージド アカウントのフェールオーバーは、階層型名前空間 (Azure Data Lake Storage Gen2) を持つアカウントではまだサポートされていません。 詳細については、「Azure Data Lake Storage Gen2 で使用できる BLOB ストレージ機能」を参照してください。

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

アカウントのフェールオーバーのしくみ

通常の状況では、クライアントのデータはプライマリ リージョンの Azure Storage アカウントに書き込まれ、そのデータはセカンダリ リージョンに非同期的にコピーされます。 次の図では、プライマリ リージョンが使用可能な場合のシナリオを示します。

クライアントはプライマリ リージョンのストレージ アカウントにデータを書き込む

プライマリ エンドポイントが何らかの使用不能になると、クライアントはストレージ アカウントに書き込むことができなくなります。 次の図は、プライマリが使用できなくなり復旧がまだ行われていないシナリオを示しています。

プライマリを使用できないため、クライアントはデータを書き込むことができない

お客様は、セカンダリ エンドポイントへのアカウントのフェールオーバーを開始します。 フェールオーバー プロセスでは、Azure Storage によって提供される DNS エントリが更新されて、次の図のように、セカンダリ エンドポイントがストレージ アカウントに対する新しいプライマリ エンドポイントになります。

お客様がセカンダリ エンドポイントへのアカウントのフェールオーバーを開始する

geo 冗長アカウントの場合は、DNS エントリが更新されて、要求が新しいプライマリ エンドポイントに送られるようになると、書き込みアクセスが復元されます。 BLOB、テーブル、キュー、およびファイルに対する既存のストレージ サービス エンドポイントは、フェールオーバー後も同じまま残ります。

重要

フェールオーバーが完了すると、ストレージ アカウントは、新しいプライマリ エンドポイントでローカル冗長に構成されます。 新しいセカンダリへのレプリケーションを再開するには、geo 冗長用にアカウントを再構成します。

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

データ損失の可能性

注意事項

アカウントのフェールオーバーでは、通常、ある程度のデータ損失が発生します。 アカウントのフェールオーバーを開始した場合の影響を理解しておく必要があります。

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

フェールオーバーを強制すると、セカンダリ リージョンが新しいプライマリ リージョンになるため、プライマリ リージョンのすべてのデータが失われます。 フェールオーバー後、新しいプライマリ リージョンはローカルで冗長になるように構成されます。

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

[最終同期時刻] プロパティは、プライマリ リージョンのデータがセカンダリ リージョンに書き込まれたことが保証される最後の時刻を示します。 最終同期時刻より前に書き込まれたすべてのデータはセカンダリで使用できますが、最終同期時刻より後に書き込まれたデータは、セカンダリに書き込まれていない場合があり、失われる可能性があります。 障害が発生した場合はこのプロパティを使用して、アカウントのフェールオーバーを開始することによって可能性があるデータ損失の量を推定します。

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

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

元のプライマリにフェールバックするときは注意が必要である

プライマリ リージョンからセカンダリ リージョンにフェールオーバーした後、ストレージ アカウントは新しいプライマリ リージョンでローカル冗長に構成されます。 その後、新しいプライマリ リージョンのアカウントを geo 冗長のために構成することができます。 フェールオーバー後にアカウントが geo 冗長のために構成されると、新しいプライマリ リージョンは直ちに新しいセカンダリ リージョン (元のフェールオーバーの前にプライマリであったもの) へのデータのコピーを開始します。 ただし、新しいプライマリの既存データが完全に新しいセカンダリにコピーされるまで、しばらくかかる場合があります。

ストレージ アカウントが geo 冗長のために再構成された後、新しいプライマリから新しいセカンダリにフェールバックを開始することができます。 この場合、フェールオーバー前の元のプライマリ リージョンが再びプライマリ リージョンとなり、元のプライマリ構成が GRS/RA-GRS か GZRS/RA-GZRS かに応じて、ローカル冗長またはゾーン冗長になるように構成されます。 その場合、フェールオーバー後のプライマリ リージョン (元のセカンダリ) のすべてのデータはフェールバック時に失われます。 フェールバックの前にストレージ アカウントのほとんどのデータが新しいセカンダリにコピーされていなかった場合、大きなデータ損失が発生する可能性があります。

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

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

アカウントのフェールオーバーを開始する

アカウントのフェールオーバーは、Azure portal、PowerShell、Azure CLI、または Azure Storage リソース プロバイダー API から開始できます。 フェールオーバーを開始する方法の詳細については、「アカウントのフェールオーバーを開始する」を参照してください。

その他の注意点

このセクションで説明されている追加の考慮事項を確認し、フェールオーバーを強制した場合にアプリケーションとサービスが受ける可能性がある影響について理解してください。

アーカイブ済みの 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 の仮想マシンに固有の高可用性とディザスター リカバリーのガイダンスを推奨しています。

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

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

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

  • 変更フィードが有効になっているストレージ アカウントは、フェールオーバーではサポートされていません。 たとえば、Azure Blob Storage の運用バックアップには変更フィードが必要です。 このため、運用バックアップが構成されているストレージ アカウントでは、フェールオーバーはサポートされません。 フェールオーバーを開始する前に、運用バックアップとその他の変更フィードを必要とする機能を無効にする必要があります。
  • Azure File Sync では、ストレージ アカウントのフェールオーバーはサポートされていません。 Azure File Sync でクラウド エンドポイントとして使用されている Azure ファイル共有を含むストレージ アカウントは、フェールオーバーしないでください。 それを行うと、同期の動作が停止し、新しく階層化されたファイルの場合は予期せずデータが失われる可能性があります。
  • 階層型名前空間が有効になっているストレージ アカウント (Data Lake Storage Gen2 など) は、現時点ではサポートされていません。
  • Premium ブロック BLOB 含むストレージ アカウントは、フェールオーバーできません。 現在、Premium ブロック BLOB をサポートするストレージ アカウントでは、geo 冗長がサポートされていません。
  • 任意の WORM 不変ポリシー対応コンテナーを含むストレージ アカウントをフェール オーバーすることはできません。 ロックされていない、またはロックされている時間ベースのリテンション期間または訴訟ホールド ポリシーでは、コンプライアンスを維持するためにフェール オーバーが防止されます。

フェールオーバーの代わりとしてのデータのコピー

ストレージ アカウントがセカンダリへの読み取りアクセス用に構成されている場合、セカンダリ エンドポイントから読み取るようにアプリケーションを設計できます。 プライマリ リージョンで障害が発生したときにフェールオーバーしたくない場合は、AzCopy、Azure PowerShell、Azure Data Movement Library などのツールを使用して、セカンダリ リージョンのストレージ アカウントから、影響を受けていないリージョンの別のストレージ アカウントに、データをコピーできます。 その後は、アプリケーションの参照先をそのストレージ アカウントにして、読み取りと書き込みの両方に利用できます。

注意事項

アカウントのフェールオーバーは、データ移行戦略の一環として使用しないでください。

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

大きな災害のためにリージョンが失われるような極端な状況では、Microsoft がリージョン間のフェールオーバーを開始できます。 この場合、ユーザーによる操作は必要ありません。 Microsoft 管理のフェールオーバーが完了するまで、ストレージ アカウントに書き込みアクセスを行うことはできません。 ストレージ アカウントが RA-GRS または RA-GZRS 対応に構成されている場合は、アプリケーションはセカンダリ リージョンから読み取ることができます。

関連項目