この記事では、 Azure Files での信頼性のサポートについて説明します。 Azure Files には、業界標準のサーバー メッセージ ブロック (SMB) プロトコルとネットワーク ファイル システム (NFS) プロトコルを介してアクセスできる、クラウド内のフル マネージド ファイル共有が用意されています。
Azure を使用する場合、 信頼性は共有責任です。 Microsoft では、回復性と回復性をサポートするさまざまな機能を提供しています。 使用するすべてのサービスでこれらの機能がどのように機能するかを理解し、ビジネス目標とアップタイムの目標を達成するために必要な機能を選択する必要があります。
この記事では、一時的な障害、可用性ゾーンの停止、リージョンの停止など、さまざまな潜在的な障害や問題に対する Azure Files の回復性を確保する方法について説明します。 また、バックアップを使用して他の種類の問題から復旧する方法についても説明し、Azure Files サービス レベル アグリーメント (SLA) に関するいくつかの重要な情報を強調します。
注
Azure Files は、Azure Storage プラットフォームの一部です。 Azure Files の機能の一部は、多くの Azure Storage サービスで共通です。 この記事では、 Azure Storage を使用して、これらの一般的な機能を参照します。
運用環境のデプロイに関する推奨事項
ソリューションの信頼性要件をサポートするために Azure Files をデプロイする方法と、信頼性がアーキテクチャの他の側面にどのように影響するかについては、「Azure Well-Architected Framework での Azure Files のアーキテクチャのベスト プラクティス 」を参照してください。
信頼性アーキテクチャの概要
ローカル冗長ストレージ (LRS) は、ストレージ アカウント内のデータを、ユーザーが選んだプライマリ リージョン内にある 1 つ以上の Azure 可用性ゾーンにレプリケートします。 優先する可用性ゾーンを選ぶことはできませんが、Azure はゾーン間で LRS アカウントを移動または拡張して、負荷分散を向上させることができます。 データがゾーン間で分散される保証はありません。 可用性ゾーンについて詳しくは、「可用性ゾーンとは」をご覧ください。
ゾーン冗長ストレージ (ZRS)、geo 冗長ストレージ (GRS)、geo ゾーン冗長ストレージ (GZRS) は、よりいっそうの保護を提供します。 この記事では、これらのオプションについて詳しく説明します。
Azure Files は、次の 2 つのメディア層で利用できます。
Premium レベルでは、高パフォーマンスのためにソリッド ステート ドライブ (SSD) が使用されます。 このレベルは、待機時間が短いワークロードに推奨されます。
Standard レベルでは、ハード ディスク ドライブ (HDD) がサポートされています。 HDD ファイル共有は、汎用ファイル共有にコスト効率の高いストレージ オプションを提供します。
詳細については、「 Azure Files - ストレージ層のデプロイの計画」を参照してください。
Azure Files はストレージ アカウント レベルで冗長性を実装し、ファイル共有はその冗長性構成を自動的に継承します。 このサービスでは、データ保護のアプローチが異なる複数の冗長性モデルがサポートされています。
一時的な障害に対する回復性
一時的な障害は、コンポーネントにおける短い断続的な障害です。 これらはクラウドのような分散環境で頻繁に発生し、運用の通常の範囲であり、 一時的な障害は、短時間の経過後に自分自身を修正します。 アプリケーションで一時的な障害を処理できることは重要です。通常は、影響を受ける要求を再試行します。
クラウドでホストされるすべてのアプリケーションは、クラウドでホストされている API、データベース、およびその他のコンポーネントと通信する際に、Azure の一時的な障害処理のガイダンスに従う必要があります。 詳細については、「一時的な障害を処理するための推奨事項」を参照してください。
Azure Files を使用するときに一時的な障害を効果的に管理するには、ファイル サイズとネットワーク条件に基づいてファイル操作に適切なタイムアウト値を構成します。 ファイルが大きいほどタイムアウト時間が長くなりますが、小さい操作では短い値を使用してエラーをすばやく検出できます。
NFS 共有へのセキュリティで保護された接続のみが確立されるようにするには、ストレージ アカウントのプライベート エンドポイントを構成することをお勧めします。 プライベート エンドポイントでは、Azure Private Link を使用して、仮想ネットワークのプライベート アドレス空間内からストレージ アカウントに静的 IP アドレスを割り当てます。 プライベート エンドポイントは、動的 IP アドレスの変更による接続の中断を防ぐのに役立ちます。 NFS 共有のセキュリティの詳細については、「 NFS ファイル共有 - セキュリティとネットワーク」を参照してください。
可用性ゾーンの障害に対する回復性
可用性ゾーン は、Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。
Azure Files には、次の 2 種類の可用性ゾーンのサポートが用意されています。
ゾーン冗長ストレージ (ZRS): ZRS 構成では、リージョン内の複数の可用性ゾーンにデータが自動的に分散されます。 LRS とは異なり、ZRS は、Azure が複数の可用性ゾーン間でファイル データを同期的にレプリケートすることを保証します。 ZRS を使用すると、1 つのゾーンで障害が発生した場合でも、データへのアクセスが維持されます。
LRS を使用したゾーン配置: Premium Storage アカウント (SSD メディア層) の場合、ゾーン配置を使用して、Azure Files ストレージ アカウントが存在する特定の可用性ゾーンを選択できます。 仮想マシン (VM) を同じゾーンに配置して、コンピューティングとストレージの間の待機時間を短縮する必要がある場合は、ゾーン配置を使用できます。
Important
単一の可用性ゾーンへのピン留めは、ニーズに合わせてゾーン間の待機時間が長すぎる場合と、待機時間が要件を満たしていないことを確認した後にのみ推奨されます。 ゾーン リソースだけでは、可用性ゾーンの停止に対する回復性は提供されません。 ゾーン リソースの回復性を向上させるには、個別のリソースを複数の可用性ゾーンに明示的にデプロイし、トラフィック ルーティングとフェールオーバーを構成する必要があります。 詳細については、「 ゾーン リソースとゾーンの回復性」を参照してください。
Requirements
リージョンのサポート:
ZRS: ZRS は以下でサポートされています。
可用性ゾーンを持つすべてのリージョンの HDD (標準) ファイル共有。
ストレージ アカウントの種類経由の "SSD (Premium) ファイル共有"。
FileStorageSSD ファイル共有アカウントで ZRS をサポートするリージョンの一覧については、SSD ファイル 共有の ZRS サポートを参照してください。
ゾーン配置を使用する LRS: ゾーン配置を使用する LRS は、サポートされているリージョンの SSD (Premium) ファイル共有で サポートされています。
ファイル共有の種類:
ZRS: ZRS は、すべてのファイル共有の種類でサポートされています。
ゾーン配置を使用する LRS: ゾーン配置を使用する LRS は、次の要件を満たすストレージ アカウントで使用できます。
- Premium Storage 層 (SSD メディア層) を使用する必要があります。
- クラシック Azure ファイル共有のみ (Microsoft.Storage リソース プロバイダーを使用)。 現在、Microsoft.FileShares リソース プロバイダー (プレビュー) を使用して作成されたファイル共有では、ゾーン配置を行うことはできません。
費用
コストへの影響は、使用する可用性ゾーンのサポートの種類によって異なります。
ZRS: ゾーン冗長ストレージ (ZRS) を有効にすると、レプリケーションとストレージのオーバーヘッドが増えるため、ローカル冗長ストレージ (LRS) とは異なるレートで課金されます。
ゾーン配置を使用する LRS: ゾーン配置を使用する LRS は、LRS と同じレートで課金されます。
価格の詳細については、 Azure Files の価格に関するページを参照してください。
可用性ゾーンのサポートを設定する
可用性ゾーンのサポートを使用してファイル共有を作成します。
ZRS: ZRS を使用して新しいファイル共有を作成するには、「 Azure ファイル共有の作成 」を参照し、アカウントの作成時に冗長性オプションとして ZRS または GZRS を選択します。
ゾーン配置を使用する LRS: ゾーン配置を使用して新しいファイル ストレージ アカウントを作成するには、「 新しいゾーン ストレージ アカウントを作成する」を参照してください。
レプリケーションの種類を変更します。
ZRS: 既存のストレージ アカウントを ZRS に変換し、移行オプションと要件については、「 Azure Files の冗長性構成を変更する」を参照してください。
ゾーン配置を使用した LRS:: 既存のストレージ アカウントを Azure で選択したゾーンにピン留めするには、「 既存のストレージ アカウントを Azure で選択したゾーンにピン留めする」を参照してください。
可用性ゾーンのサポートを無効にします。
ZRS: 同じ冗長性構成変更プロセスを使用して、ZRS アカウントを LRS などの非ゾーン構成に変換します。
ゾーン配置を使用する LRS: ゾーンからストレージ アカウントを固定解除し、ゾーン ストレージ アカウントをリージョン ストレージ アカウントに変換するには、「 ゾーンからストレージ アカウントの固定を解除する」を参照してください。
すべてのゾーンが正常な場合の動作
このセクションでは、ファイル ストレージ アカウントが可用性ゾーンのサポート用に構成されていて、すべての可用性ゾーンが動作している場合に想定される内容について説明します。
ゾーン間のトラフィック ルーティング:
ZRS: ゾーン冗長ストレージ (ZRS) を使用する Azure Storage では、複数の可用性ゾーン内のストレージ クラスター間で要求が自動的に分散されます。 トラフィックの分散はアプリケーションに対して透過的であり、クライアント側の構成は必要ありません。
ゾーン配置を使用する LRS: ローカル冗長ストレージ (LRS) を使用する Azure Storage では、選択した可用性ゾーン内のストレージ クラスター間で要求が自動的に分散されます。 トラフィックの分散はアプリケーションに対して透過的であり、クライアント側の構成は必要ありません。
ゾーン間のデータ レプリケーション:
ZRS: ZRS に対するすべての書き込み操作は、リージョン内のすべての可用性ゾーン間で同期的にレプリケートされます。 データをアップロードまたは変更する場合、すべての可用性ゾーンでデータが正常にレプリケートされるまで、操作は完了とは見なされません。 この同期レプリケーションにより、ゾーン障害時の強力な一貫性とデータ損失がゼロになります。
ゾーン配置を使用する LRS: LRS に対するすべての書き込み操作は、ゾーン内の複数のストレージ レプリカ間で同期的にレプリケートされます。 データをアップロードまたは変更する場合、すべてのレプリカでデータが正常にレプリケートされるまで、操作は完了とは見なされません。
ゾーン障害時の動作
このセクションでは、ファイル ストレージ アカウントが可用性ゾーンのサポート用に構成されていて、可用性ゾーンが停止した場合に想定される内容について説明します。
検出と応答:
ZRS: Microsoft はゾーンの障害を自動的に検出し、復旧プロセスを開始します。 ゾーン冗長ストレージ (ZRS) アカウントに対して顧客の操作は必要ありません。ゾーンが使用できなくなった場合、Azure はドメイン ネーム システム (DNS) の再ポイントなどのネットワーク更新を実行します。
ゾーン配置を使用する LRS: 可用性ゾーンの損失を検出する必要があります。 必要に応じて、別の可用性ゾーンで事前に作成したセカンダリ ファイル共有へのフェールオーバーを開始できます。
- 通知: ゾーンがダウンしても、Microsoft から自動的に通知されることはありません。 ただし、 Azure Resource Health を 使用して個々のリソースの正常性を監視したり、 Resource Health アラート を設定して問題を通知したりすることはできます。 また、Azure Service Health を使用して、ゾーンの障害を含むサービスの全体的な正常性を把握し、問題を通知する Service Health アラートを設定することもできます。
アクティブな要求:
ZRS: 処理中の要求は復旧プロセス中に破棄される可能性があり、再試行する必要があります。 アプリケーションでは、これらの一時的な中断を処理するための 再試行ロジックを実装 する必要があります。
ゾーン配置を使用する LRS: 処理中の要求は取り消され、ゾーンが復旧した際に再試行する必要があります。
予想されるデータ損失:
ZRS: 書き込み操作が完了する前にデータが複数のゾーンに同期的にレプリケートされるため、ゾーンの障害時にデータ損失は発生しません。
ゾーン配置を使用する LRS: 影響を受けるゾーン内のファイル共有上のデータは、ゾーンが回復するまで使用できません。
想定されるダウンタイム:
ZRS: トラフィックが正常なゾーンにリダイレクトされるため、自動復旧中に少しのダウンタイム (通常は数秒) が発生する可能性があります。 ZRS 用のアプリケーションを設計するときは、エクスポネンシャル バックオフを使用する再試行ポリシーの実装など、一時的な障害処理の手法に従ってください。
ゾーン配置を使用する LRS: 影響を受けるゾーンのファイル共有は、可用性ゾーンが復旧するまでダウンしたままです。
トラフィックの再ルーティング:
ZRS: Azure は、残りの正常な可用性ゾーンにトラフィックを自動的に再ルーティングします。 サービスは、顧客の介入を必要とせず、存続ゾーンを使用して完全な機能を維持します。 接続されているクライアントから Azure ファイル共有を再マウントする必要はありません。
ゾーン配置を使用する LRS: 必要に応じて、正常なゾーン内の他のファイル ストレージ アカウントに切り替える必要があります。
ゾーンの回復
ゾーン回復の動作は、ファイル ストレージ アカウントが使用するレプリケーションの種類によって異なります。
ZRS: 障害が発生した可用性ゾーンが復旧すると、Azure Storage は、すべての可用性ゾーンで通常の操作を自動的に復元します。 サービスは、停止期間中に発生したすべての操作を同期して、データの整合性を自動的に確保します。
ゾーン配置を使用する LRS: ゾーンが正常な状態になった後、ゾーン内のファイル共有を再び使用できるようになります。 ワークロードに必要なゾーン回復手順とデータ同期は、お客様が担当します。
ゾーンエラーのテスト
ゾーンダウン テスト オプションは、ファイル ストレージ アカウントで使用されるレプリケーションの種類によって異なります。
ZRS: ゾーン冗長ストレージ (ZRS) を使用すると、Azure Storage はレプリケーション、トラフィック ルーティング、ゾーンダウン応答を自動的に管理します。 この機能は完全に管理されているため、可用性ゾーンの障害プロセスを開始または検証する必要はありません。
ゾーン配置を使用する LRS: ファイル ストレージ アカウントを含む可用性ゾーンの停止をシミュレートする方法はありません。 ただし、アップストリーム アプリケーション、ファイアウォール、ゲートウェイ、またはロード バランサーを手動で構成して、別の可用性ゾーン内の別のファイル ストレージ アカウントにトラフィックをリダイレクトできます。
リージョン全体の障害に対する回復性
Azure Blob Storage、Azure Files、Azure Table Storage、Azure Queue Storage などの Azure Storage には、さまざまな要件に合わせて geo 冗長性とフェールオーバーの広範な機能が用意されています。
Important
geo 冗長ストレージ (GRS) は、Azure のペアリングされたリージョン内でのみ機能します。 ストレージ アカウントのリージョンがペアになっていない場合は、 回復性のためにカスタムマルチリージョン ソリューションを使用することを検討してください。
ペアになっているリージョンの GRS
ペアリングされたリージョンでは、Azure Storage によって複数の種類の GRS が提供されます。 どの種類の GRS を使っても、セカンダリ リージョン内のデータは常にローカル冗長ストレージ (LRS) を使ってレプリケートされます。 この方法により、セカンダリ リージョン内のハードウェア障害に対する保護が提供されます。
GRS では、プライマリ リージョンで障害が発生した場合に、Azure のペアリングされたリージョンへの計画的と計画外のフェールオーバーがサポートされます。 GRS は、プライマリ リージョンからペアのリージョンにデータを非同期的にレプリケートします。
geo ゾーン冗長ストレージ (GZRS) は、プライマリ リージョンの複数の可用性ゾーン内のデータを、ペアリングされたリージョンにレプリケートします。
Important
Azure Files では、標準 (HDD) ファイル共有の geo 冗長性 (GRS または GZRS) のみがサポートされます。
Azure Files では、読み取りアクセス geo 冗長ストレージ (RA-GRS) または読み取りアクセス geo ゾーン冗長ストレージ (RA-GZRS) はサポートされていません。 ストレージ アカウントが RA-GRS または RA-GZRS を使用するように構成されている場合、Standard (HDD) ファイル共有が構成され、GRS または GZRS として課金されます。
フェールオーバーの種類
Azure Storage では、さまざまなシナリオに対して 3 種類のフェールオーバーがサポートされています。
カスタマーマネージド計画外フェールオーバー: プライマリ リージョンでリージョン全体のストレージ障害が発生した場合、お客様が復旧を開始する責任があります。
カスタマー マネージドの計画されたフェールオーバー: ソリューションの別の部分でプライマリ リージョンに障害が発生し、ソリューション全体をセカンダリ リージョンに切り替える必要がある場合は、復旧を開始する必要があります。 プライマリ リージョンでストレージが引き続き動作するが、コンプライアンスと監査の要件を確保するために設計されたディザスター リカバリー訓練など、ソリューション全体をセカンダリ リージョンにフェールオーバーする必要がある場合は、計画されたフェールオーバーを使用します。
Microsoft マネージド フェールオーバー: 例外的な状況では、Microsoft がリージョン内のすべての geo 冗長ストレージ (GRS) アカウントのフェールオーバーを開始する場合があります。 ただし、Microsoft が管理するフェールオーバーは最後の手段であり、長期間の停止後にのみ実行される予定です。 Microsoft が管理するフェールオーバーに依存しないでください。
GRS アカウントでは、これらのフェールオーバーの種類のいずれでも使用できます。 フェールオーバーの種類を事前に使用するために、ストレージ アカウントを事前に構成する必要はありません。
Requirements
リージョンのサポート: Azure Storage geo 冗長構成では、セカンダリ リージョンのレプリケーションに Azure のペアになっている リージョンが使用されます。 セカンダリ リージョンは、プライマリ リージョンの選択に基づいて自動的に決定され、カスタマイズすることはできません。 Azure のペアになっているリージョンの完全な一覧については、 Azure リージョンの一覧を参照してください。
ストレージ アカウントのリージョンがペアになっていない場合は、 回復性のためにカスタムマルチリージョン ソリューションを使用することを検討してください。
Standard ファイル共有のみ: Azure Files では、標準 (HDD) ファイル共有の geo 冗長性 (GRS または GZRS) のみがサポートされます。 Premium (SSD) ファイル共有では、LRS または ZRS を使用する必要があります。 Premium ファイル共有があり、より高い回復性を実現するためにリージョン間でデータをレプリケートする場合は、「回復 性のためのカスタム マルチリージョン ソリューション」を参照してください。
GRS と GZRS のみ: Azure Files では、読み取りアクセス geo 冗長ストレージ (RA-GRS) または読み取りアクセス geo ゾーン冗長ストレージ (RA-GZRS) はサポートされていません。 ストレージ アカウントが RA-GRS または RA-GZRS を使用するように構成されている場合、Standard (HDD) ファイル共有が構成され、GRS または GZRS として課金されます。
考慮事項
複数リージョンの Azure Files を実装する場合は、次の重要な要因を考慮してください。
非同期レプリケーションの待ち時間: セカンダリ リージョンへのデータ レプリケーションは非同期です。つまり、データがプライマリ リージョンに書き込まれるときと、セカンダリ リージョンで使用できるようになるまでの間に時間差があります。 この時間差のため、最近のデータがレプリケートされる前にプライマリ リージョンで障害が発生した場合、データが失われる可能性があります。 データ損失は、回復ポイントの目標 (RPO) によって測定されます。 レプリケーションの時間差は 15 分未満と予想されますが、この時間は推定であり、保証されません。
最終同期時刻プロパティを調べて、ストレージ アカウントで計画外フェールオーバーが発生した場合に失われる可能性があるデータの量を把握できます。
最終同期時刻: Azure Files の場合、最終同期時刻はセカンダリ リージョンの最新のシステム スナップショットに基づいています。
ストレージ アカウントに 100 を超えるファイル共有がある場合、最終同期時刻の計算はタイムアウトする可能性があります。 タイムアウトを回避するために、ストレージ アカウントごとに 100 個以下のファイル共有をデプロイすることをお勧めします。
セカンダリ リージョンのアクセス: セカンダリ リージョンは、フェールオーバーが発生するまで読み取りにアクセスできません。
機能の制限事項: GRS またはカスタマー マネージド フェールオーバーを使用する場合、一部の Azure Files 機能はサポートされていないか、制限があります。 これらの制限事項には、特定のファイル共有の種類、アクセス層、管理ツールと操作が含まれます。 geo 冗長性を実装する前に 、機能の互換性に関するドキュメント を確認してください。
費用
複数リージョンの Azure ストレージ アカウント構成では、リージョン間のレプリケーションとセカンダリ リージョンでのストレージに対して追加のコストが発生します。 Azure リージョン間のデータ転送は、標準のリージョン間帯域幅レートに基づいて課金されます。
価格の詳細については、 Azure Files の価格に関するページを参照してください。
複数リージョンのサポートを構成する
- 新しい geo 冗長ストレージ (GRS) アカウントを作成します。 GRS アカウントの作成については、ストレージ アカウントの作成に関する記事をご覧ください。アカウントの作成の間に、GRS、読み取りアクセス geo 冗長ストレージ (RA-GRS)、geo ゾーン冗長ストレージ (GZRS)、または読み取りアクセス geo ゾーン冗長ストレージ (RA-GZRS) を選びます。
既存のファイル ストレージ アカウントで geo 冗長性を有効にします。 既存のファイル ストレージ アカウントを GRS に変換するには、「 Azure Files の冗長性構成を変更する」を参照してください。
Warnung
アカウントが geo 冗長として再構成された後、新しいプライマリ リージョンの既存データが新しいセカンダリ リージョンに完全にコピーされるまで、かなりの時間がかかる場合があります。
大きなデータ損失を防ぐには、計画外フェールオーバーを始める前に、最終同期時刻プロパティの値を確認します。 データ損失の可能性を評価するには、最後の同期時刻と、新しいプライマリ リージョンにデータが書き込まれた最後の時刻を比較します。
geo 冗長を無効にします。 同じ冗長性構成変更プロセスを使用して、GRS アカウントを単一リージョン構成 (LRS または ZRS) に戻します。
すべてのリージョンが正常な場合の動作
このセクションでは、ストレージ アカウントが geo 冗長用に構成されていて、すべてのリージョンが運用されている場合に想定される内容について説明します。
リージョン間のトラフィック ルーティング: Azure Files ではアクティブ/パッシブアプローチが使用され、すべての読み取り操作と書き込み操作がプライマリ リージョンに送信されます。
リージョン間のデータ レプリケーション: 書き込み操作は、まず、構成済みの冗長性の種類 (GRS の場合は LRS、GZRS の場合は ZRS) を使用してプライマリ リージョンにコミットされます。 プライマリ リージョンで正常に完了すると、データはセカンダリ リージョンに非同期的にレプリケートされ、LRS を使用して格納されます。
リージョン間レプリケーションの非同期的な性質は、通常、データがプライマリ リージョンに書き込まれてからセカンダリ リージョンで使用できるようになるまでに遅延時間があることを意味します。 レプリケーション時間は、最終同期時刻プロパティを使って監視できます。
リージョン障害時の動作
このセクションでは、ストレージ アカウントが geo 冗長用に構成されていて、プライマリ リージョンで障害が発生した場合に想定される内容について説明します。
カスタマーマネージド フェールオーバー (計画外): プライマリ リージョンのストレージが使用できない場合は、計画外フェールオーバーを使います。
検出と応答: 万が一、プライマリ リージョンでストレージ アカウントが使用できない場合は、カスタマー マネージドの計画外フェールオーバーの開始を検討できます。 この決定を行うには、次の要因を考慮してください。
プライマリ リージョンのストレージ アカウントへのアクセスに関する問題が Azure Resource Health で示されるかどうか
別のリージョンへのフェールオーバーを実行するよう Microsoft が推奨するかどうか
Warnung
計画外のフェールオーバーでは、 データが失われる可能性があります。 カスタマーマネージド フェールオーバーを始める前に、サービスの復元によってデータ損失のリスクが正当化されるかどうかを判断します。
通知: リージョンが停止しても、Microsoft から自動的に通知されることはありません。 しかし：
Azure Resource Health を使用して個々のリソースの正常性を監視したり、Resource Health アラートを設定して問題を通知することができます。
Azure Service Health を使用して、リージョンの障害を含むサービスの全体的な正常性を把握し、問題を通知する Service Health アラートを設定できます。
アクティブな要求: フェールオーバー プロセス中に、プライマリとセカンダリの両方のストレージ アカウント エンドポイントが読み取りと書き込みの両方で一時的に使用できなくなります。 アクティブな要求はすべて削除される可能性があり、クライアント アプリケーションはフェールオーバーの完了後に再試行する必要があります。
予想されるデータ損失: 非同期レプリケーションの遅延により、最近の書き込みがレプリケートされない可能性があるため、計画外フェールオーバーでは一般にデータ損失が発生します。 最終同期時刻プロパティを調べて、計画外フェールオーバーの間に失われる可能性があるデータの量を把握できます。 予想されるデータ損失は、多くの場合、目標復旧ポイント (RPO) と呼ばれます。 通常、RPO は 15 分未満であると予想できますが、その時間は保証されません。
予想されるダウンタイム: 予想されるダウンタイムの量は、多くの場合、目標復旧時間 (RTO) と呼ばれます。 顧客が管理するフェールオーバーは、通常、アカウントのサイズと複雑さに応じて 60 分以内に完了します。
トラフィックの再ルーティング: フェールオーバーが完了すると、アプリケーションを再構成する必要がないように、Azure によってストレージ アカウント エンドポイントが自動的に更新されます。 アプリケーションがドメイン ネーム システム (DNS) のエントリをキャッシュに保持している場合、アプリケーションで新しいプライマリ リージョンにトラフィックを確実に送信するため、キャッシュのクリアが必要になる場合があります。
フェールオーバー後の構成: 計画外フェールオーバーが完了した後、フェールオーバー先のリージョンのストレージ アカウントではローカル冗長ストレージ (LRS) 層が使われます。 それを再び geo レプリケートする必要がある場合は、geo 冗長ストレージ (GRS) をもう一度有効にして、データが新しいセカンダリ リージョンにレプリケートされるのを待つ必要があります。
カスタマーマネージド フェールオーバーを始める方法について詳しくは、「カスタマーマネージド (計画外) フェールオーバーのしくみ」と「ストレージ アカウントのフェールオーバーを開始する」をご覧ください。
カスタマーマネージド フェールオーバー (計画的): プライマリ リージョンのストレージは動作しているものの、別の理由でソリューション全体をセカンダリ リージョンにフェールオーバーする必要がある場合は、計画フェールオーバーを使います。 たとえば、別の Azure サービスで問題が発生している可能性があり、ソリューション全体にセカンダリ リージョンを使用するように切り替える必要があります。 または、計画されたフェールオーバーを使用して、コンプライアンスと監査の目的でディザスター リカバリー (DR) 訓練を実施することもできます。
検出と応答: フェールオーバーを決定する責任があります。 通常、ストレージ アカウントが正常であっても、リージョン間でフェールオーバーする必要がある場合は、この決定を行います。 たとえば、プライマリ リージョンで復旧できない別のアプリケーション コンポーネントが大幅に停止した場合にフェールオーバーをトリガーできます。
通知: リージョンが停止しても、Microsoft から自動的に通知されることはありません。 しかし：
Azure Resource Health を使用して個々のリソースの正常性を監視したり、Resource Health アラートを設定して問題を通知することができます。
Azure Service Health を使用して、リージョンの障害を含むサービスの全体的な正常性を把握し、問題を通知する Service Health アラートを設定できます。
アクティブな要求: フェールオーバー プロセス中に、プライマリとセカンダリの両方のストレージ アカウント エンドポイントが読み取りと書き込みの両方で一時的に使用できなくなります。 アクティブな要求はすべて削除される可能性があり、クライアント アプリケーションはフェールオーバーの完了後に再試行する必要があります。
予想されるデータ損失: フェールオーバー プロセスは、すべてのデータが同期された後にのみ完了し、RPO が 0 になるため、データ損失は発生しません。
予想されるダウンタイム: 通常、フェールオーバーは 60 分以内に完了します。つまり、アカウントのサイズと複雑さに応じて、予想される RTO は 60 分です。 フェールオーバー プロセス中に、プライマリとセカンダリの両方のストレージ アカウント エンドポイントが読み取りと書き込みの両方で一時的に使用できなくなります。
トラフィックの再ルーティング: フェールオーバーが完了すると、アプリケーションを再構成する必要がないように、Azure によってストレージ アカウント エンドポイントが自動的に更新されます。 アプリケーションが DNS のエントリをキャッシュに保持している場合、アプリケーションで新しいプライマリ リージョンにトラフィックを確実に送信するため、キャッシュのクリアが必要になる場合があります。
フェールオーバー後の構成: 計画されたフェールオーバーが完了した後も、移行先リージョンのストレージ アカウントは引き続き geo レプリケートされ、GRS レベルに残ります。
カスタマーマネージド フェールオーバーを始める方法について詳しくは、カスタマーマネージド (計画的) フェールオーバーのしくみに関する記事と「ストレージ アカウントのフェールオーバーを開始する」をご覧ください。
Microsoft マネージド フェールオーバー: プライマリ リージョンが永続的に回復不能であると Microsoft が判断する重大な災害が発生したまれな場合は、セカンダリ リージョンへの自動フェールオーバーが開始される可能性があります。 Microsoft はプロセス全体を処理し、顧客のアクションは必要ありません。 フェールオーバーが発生するまでの経過時間は、障害の重大度と状況の評価に必要な時間によって異なります。
通知: リージョンが停止しても、Microsoft から自動的に通知されることはありません。 しかし：
Azure Resource Health を使用して個々のリソースの正常性を監視したり、Resource Health アラートを設定して問題を通知することができます。
Azure Service Health を使用して、リージョンの障害を含むサービスの全体的な正常性を把握し、問題を通知する Service Health アラートを設定できます。
Important
カスタマー マネージド フェールオーバー オプションを使用して、DR プランを開発、テスト、実装します。 Microsoft マネージド フェールオーバーに頼らないでください。これが使われる可能性があるのは、極端な状況のみです。 Microsoft マネージド フェールオーバーは、リージョン全体に対して開始される可能性があります。 個々のストレージ アカウント、サブスクリプション、または顧客に対して開始することはできません。 フェールオーバーは、Azure サービスごとに異なる時間に発生する可能性があります。 カスタマーマネージド フェールオーバーを使うことをお勧めします。
リージョンの復旧
フェールバック プロセスは、Microsoft マネージド フェールオーバーとカスタマーマネージド フェールオーバーのシナリオで大きく異なります。
カスタマーマネージド フェールオーバー (計画外): 計画外フェールオーバーの後では、ストレージ アカウントはローカル冗長ストレージ (LRS) で構成されます。 フェールバックするには、geo 冗長ストレージ (GRS) の関係を確立し直して、データがレプリケートされるのを待つ必要があります。
カスタマーマネージド フェールオーバー (計画的): 計画フェールオーバーの後では、ストレージ アカウントは引き続き geo レプリケートされます。 別のカスタマーマネージド フェールオーバーを始めて、元のプライマリ リージョンにフェールバックできます。 同じフェールオーバーに関する考慮事項が適用されます。
Microsoft マネージド フェールオーバー: Microsoft がフェールオーバーを開始するのは、おそらくプライマリ リージョンで重大な災害が発生した場合であり、プライマリ リージョンを復旧できない可能性があります。 タイムラインや復旧計画は、リージョンの災害と復旧作業の程度によって異なります。 詳細については、Azure Service Health 通信を監視する必要があります。
リージョン障害のテスト
GRS アカウントの場合は、メンテナンス期間中に計画されたフェールオーバー操作を実行して、フェールオーバーとフェールバックの完全なプロセスをテストできます。 計画されたフェールオーバーではデータ損失は必要ありませんが、フェールオーバーとフェールバックの両方でダウンタイムが必要です。
回復性のためのカスタム マルチリージョン ソリューション
次の理由により、Azure Storage のリージョン間フェールオーバー機能が不適切な場合があります。
ストレージ アカウントがペアになっていないリージョンにあります。
ビジネスアップタイムの目標は、組み込みのフェールオーバー オプションによって提供される復旧時間やデータ損失によって満たされません。
プライマリ リージョンのペアではないリージョンにフェールオーバーする必要があります。
Azure リージョン間でアクティブ/アクティブ構成が必要です。
- あなたは地理的冗長性をサポートしていないファイル共有の種類を使用しています。
このセクションでは、考慮すべきいくつかのアプローチの概要について説明します。 Azure Storage のマルチリージョン デプロイ トポロジの包括的な概要については、この記事の範囲外です。
次の一般的な大まかなアプローチを検討してください。
複数のストレージ アカウント: Azure Files は、リージョンごとに個別のストレージ アカウントを使用して、複数のリージョンにデプロイできます。 この方法では、リージョンを柔軟に選択し、ペアリングされていないリージョンを使い、レプリケーションのタイミングとデータの整合性をより細かく制御することができます。 リージョンをまたいで複数のストレージ アカウントを実装する場合は、リージョン間のデータ レプリケーションを構成し、負荷分散とフェールオーバーのポリシーを実装して、リージョン間のデータの整合性を確保する必要があります。
アプリケーション レベルのレプリケーション:Azure Data Factory または AzCopy を使用してカスタム レプリケーション ロジックを実装し、異なるリージョンのファイル共有間でデータを同期します。 このアプローチには、カスタム開発と競合解決メカニズムが必要です。
Azure File Sync を使用して、別の Azure リージョンのファイル共有にファイルをレプリケートします。 Azure File Sync を使用すると、SMB Azure ファイル共有 (クラウド エンドポイント)、オンプレミスの Windows ファイル サーバー、および別の Azure リージョン (DR サーバー エンドポイント) 内の仮想マシン (VM) 上で実行されるマウントされたファイル共有の間で同期できます。
この方法では、同期プロセスを調整するために、複数のファイル共有と VM をデプロイする必要があります。
複数リージョンのファイル レプリケーションにこの方法を使用する場合:
クラウドの階層化を無効にして、すべてのデータがファイル サーバー上にローカルに存在することを確認します。
データセット全体を保持するのに十分なストレージを Azure VM にプロビジョニングします。
変更がセカンダリ リージョンに迅速にレプリケートされるように、Azure ではなく、サーバー エンドポイント上のファイルにアクセスして変更します。
バックアップと復元
Azure Files バックアップ は、Azure Files と Azure Backup の間のネイティブ統合であり、偶発的な削除、破損、ランサムウェア攻撃からデータを保護するように設計されています。
Azure Files バックアップでは、同じストレージ アカウント内に格納された共有レベルのスナップショットが作成されます。 この機能により、個々のファイルとファイル共有全体の両方を迅速に回復できます。 また、バックアップ ポリシーを使用して、カスタマイズ可能なバックアップ頻度で長い保有期間を提供することもできます。
スナップショットを作成して格納するには、次の 2 つの方法があります。
共有レベルのストレージ: 運用および短期的な復旧シナリオでは、共有レベルのスナップショットを作成し、同じストレージ アカウント内に格納できます。 共有レベルのスナップショットを使用すると、個々のファイルまたはファイル共有全体を元の場所または別の場所に迅速に復旧できます。
コンテナー化されたバックアップ ストレージ: コンテナー化されたバックアップを使用すると、毎日のスナップショットを Azure Recovery Services コンテナーにコピーできます。 セキュリティを強化するために、このコンテナーはプライマリ ストレージ アカウントから分離され、エアギャップされています。
ペアの Azure リージョンを使用し、GRS を使用するようにコンテナーを構成すると、コンテナーはペアのリージョンにデータをレプリケートします。 このレプリケーションでは、リージョン間の復旧と DR ワークフローがサポートされます。
サービス水準合意書
Azure Storage のサービス レベル アグリーメント (SLA) では、サービスの予想される可用性と、その可用性の期待を達成するために満たす必要がある条件が記述されています。 適用される可用性 SLA は、使用するストレージ層とレプリケーションの種類によって異なります。 詳しくは、「オンライン サービスのサービス レベル アグリーメント (SLA)」をご覧ください。