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

  • [アーティクル]

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

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

この記事では、アカウントのフェールオーバーに関する概念とプロセスについて、および顧客への影響が最小限になるようにストレージ アカウントの復旧を準備する方法について説明します。 Azure portal または 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 時間かかります。

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

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

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

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

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

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

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

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

重要

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

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

データ損失の可能性

注意事項

アカウントのフェールオーバーでは、通常、ある程度のデータ損失が発生します。 アカウントのフェールオーバーを開始する前に、その影響を理解しておくことが重要です。

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

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

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

最終同期時刻

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

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

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

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

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

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

プライマリ リージョンからセカンダリ リージョンにフェールオーバーした後、ストレージ アカウントは新しいプライマリ リージョンでローカル冗長に構成されます。 その後、新しいプライマリ リージョンのアカウントを 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 から開始できます。 フェールオーバーを開始する方法の詳細については、「アカウントのフェールオーバーを開始する」を参照してください。

Note

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

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

すべての 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) を持つアカウントのカスタマー マネージド アカウント フェールオーバーは現在プレビュー段階であり、次のリージョンでのみサポートされています。

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

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

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

その他の注意点

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

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

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

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

非同期レプリケーションによるストレージ アカウントのフェールオーバー中にデータ損失が発生する可能性を判断する方法の詳細については、「データ損失の可能性」を参照してください。 変更フィードのしくみについては、「変更フィードのしくみ」を参照してください。

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

ポイントインタイム リストア

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

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

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

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

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

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

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

注意事項

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

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

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

Note

Microsoft マネージド フェールオーバーは、リージョン、データセンター、スケール ユニットなどの物理ユニット全体に対して開始されます。 個々のストレージ アカウント、サブスクリプション、またはテナントに対して開始することはできません。 個々のストレージ アカウントを選択的にフェールオーバーできるようにするには、この記事で前述したカスタマー マネージド アカウントのフェールオーバーを使用します。

関連項目