Azure Files のディザスター リカバリーとフェールオーバー
Microsoft は、Azure サービスを常に使用できるようにする作業に取り組んでいます。 ただし、計画外のサービス停止が発生する可能性があるため、リージョンのサービス停止を処理するためのディザスター リカバリー (DR) 計画を立てる必要があります。 ディザスター リカバリー計画の重要な部分は、プライマリ エンドポイントが使用できなくなった場合に、セカンダリ エンドポイントにフェールオーバーするための準備です。 この記事では、ディザスター リカバリー (DR) とストレージ アカウントのフェールオーバーに関連する概念とプロセスについて説明します。
重要
Azure File Sync では、ストレージ同期サービスもフェールオーバーされた場合にのみ、ストレージ アカウントのフェールオーバーがサポートされます。 これは、Azure File Sync では、ストレージ アカウントとストレージ同期サービスが同じ Azure リージョンに存在する必要があるためです。 ストレージ アカウントのみがフェールオーバーされた場合、ストレージ同期サービスがセカンダリ リージョンにフェールオーバーされるまで、同期操作とクラウド階層化操作は失敗します。 Azure File Sync でクラウド エンドポイントとして使用されている Azure ファイル共有を含むストレージ アカウントをフェールオーバーする場合は、「Azure File Sync のディザスター リカバリーのベスト プラクティス」 、と「Azure File Sync サーバーの復旧」 に関するページを参照してください。
復旧メトリックとコスト
効果的な DR 戦略を策定するには、組織で以下について理解する必要があります。
- 中断が発生した場合に失われても差し支えないデータの量 (回復ポイントの目標 (RPO))
- ビジネス機能とデータをどれだけ早く復元できるようにならなければならないか (目標復旧時間 (RTO))
DR のコストは、通常、RPO/RTO が低いかゼロの場合は増加します。 災害後に数秒で稼働する必要があり、一切のデータ損失にも耐えられない企業は DR に対してより多くの料金を支払う一方で、RPO/RTO の数値が高い企業は支払いが少なくなります。 Azure には、さまざまな RPO と RTO の要件に対応できるソリューションが用意されています。
適切な冗長性オプションを選択する
Azure Files には、一時的なハードウェア障害、ネットワーク障害、停電から自然災害まで、計画的および計画外のイベントからデータを保護するためのさまざまな冗長性オプションが用意されています。 すべての Azure ファイル共有で、ローカル冗長 (LRS) またはゾーン冗長ストレージ (ZRS) を使用できます。 詳細については、「Azure Files の冗長性」を参照してください。
Azure Files では、リージョンの障害から保護するために、geo 冗長ストレージ (GRS) と geo ゾーン冗長ストレージ (GZRS) で構成された標準ストレージ アカウントのアカウント フェールオーバーがサポートされています。 アカウントのフェールオーバーでは、プライマリ エンドポイントが使用できなくなった場合に、ストレージ アカウントのフェールオーバー プロセスを開始できます。 フェールオーバーでは、セカンダリ エンドポイントが更新されて、ストレージ アカウントのプライマリ エンドポイントになります。 フェールオーバーが完了すると、クライアントは新しいプライマリ エンドポイントへの書き込みを開始できます。
GRS と GZRS では、データがセカンダリ リージョンに非同期的にコピーされるため、データ損失のリスクが引き続き伴います。つまり、プライマリ リージョンへの書き込みがセカンダリ リージョンにコピーされるまでに遅延が発生します。 障害が発生した時点で、セカンダリ エンドポイントにまだコピーされていないプライマリ エンドポイントへの書き込み操作は失われます。 つまり、プライマリ リージョンに影響する障害が発生した場合、プライマリ リージョンを復旧できない場合にデータ損失が発生する可能性があります。 プライマリ リージョンへの最新の書き込みと、セカンダリ リージョンへの最後の書き込みとの間隔は、RPO と呼ばれます。 現在、データをセカンダリ リージョンへのレプリケートの所要時間に関する SLA はありませんが、Azure Files では通常、RPO は 15 分未満となります。
重要
GRS/GZRS は、Premium Azure ファイル共有ではサポートされていません。 ただし、地理的な冗長性を実現するために、2 つの Azure ファイル共有間で同期できます。
高可用性向けの設計
最初から高可用性対応にアプリケーションを設計することが重要です。 アプリケーションの設計およびディザスター リカバリーの計画に関するガイダンスについては、こちらの Azure リソースを参照してください。
- 回復性に優れた Azure 用アプリケーションの設計:Azure で高可用性アプリケーションを設計するための主要な概念の概要です。
- 回復性のチェックリスト:アプリケーションで高可用性向け設計のベスト プラクティスが実装されていることを確認するためのチェックリストです。
- geo 冗長性を使用して高可用性アプリケーションを設計する: SMB ファイル共有用の geo 冗長ストレージを利用するアプリケーションを構築するための設計ガイダンス。
また、書き込みエラーの可能性に対処するようアプリケーションを設計することもお勧めします。 アプリケーションでは、プライマリ リージョンでの障害の可能性があることを通知するように書き込みエラーを公開する必要があります。
ベスト プラクティスとしては、最終同期時刻プロパティを確認して予想されるデータ損失を評価できるようにアプリケーションを設計します。 たとえば、すべての書き込み操作をログに記録している場合は、最後の書き込み操作の時刻を最終同期時刻と比較することで、セカンダリに同期されていない書き込みを特定できます。
障害を追跡する
Azure Service Health ダッシュボードをサブスクライブして、Azure Files と他の Azure サービスの正常性と状態を追跡できます。
アカウントのフェールオーバー プロセスを理解する
お客様が管理するアカウントのフェールオーバーでは、何らかの理由でプライマリが使用できなくなった場合、ストレージ アカウント全体をセカンダリ リージョンにフェールオーバーすることができます。 セカンダリ リージョンへのフェールオーバーを強制的に実行すると、クライアントは、フェールオーバー完了後にセカンダリ エンドポイントへのデータの書き込みを開始することができます。 フェールオーバーには、通常、約 1 時間かかります。 アカウントのフェールオーバーを開始する前に、ワークロードをできるだけ一時停止することをお勧めします。
アカウントのフェールオーバーを開始する方法の詳細については、「アカウントのフェールオーバーを開始する」を参照してください。
アカウントのフェールオーバーのしくみ
通常の状況では、クライアントのデータはプライマリ リージョンのストレージ アカウントに書き込まれ、そのデータはセカンダリ リージョンに非同期的にコピーされます。 次の図では、プライマリ リージョンが使用可能な場合のシナリオを示します。
プライマリ エンドポイントが何らかの使用不能になると、クライアントはストレージ アカウントに書き込むことができなくなります。 次の図は、プライマリが使用できなくなり復旧がまだ行われていないシナリオを示しています。
お客様は、セカンダリ エンドポイントへのアカウントのフェールオーバーを開始します。 フェールオーバー プロセスでは、Azure Storage によって提供される DNS エントリが更新されて、次の図のように、セカンダリ エンドポイントがストレージ アカウントに対する新しいプライマリ エンドポイントになります。
geo 冗長アカウントの場合は、DNS エントリが更新されて、要求が新しいプライマリ エンドポイントに送られるようになると、書き込みアクセスが復元されます。 既存のストレージ サービス エンドポイントは、フェールオーバー後も同じまま残ります。 ファイル ハンドルとリースはフェールオーバー時に保持されず、クライアントはファイル共有のマウントを解除して再マウントする必要があります。
重要
フェールオーバーが完了すると、ストレージ アカウントは、新しいプライマリ エンドポイント/リージョンでローカル冗長に設定されます。 新しいセカンダリへのレプリケーションを再開するには、geo 冗長用にアカウントを再構成します。
geo 冗長性を使用するようにローカル冗長ストレージ アカウントを変換すると、コストと時間の両方がかかることにご注意ください。 詳細については、「アカウントのフェールオーバーの重要な影響」を参照してください。
データ損失の可能性
注意事項
アカウントのフェールオーバーでは、通常、ある程度のデータ損失が発生します。 アカウントのフェールオーバーを開始した場合の影響を理解しておく必要があります。
データはプライマリ リージョンからセカンダリ リージョンに非同期的に書き込まれるため、プライマリ リージョンが使用できなくなった場合は、最新の書き込みがまだセカンダリ リージョンにコピーされていない可能性があります。
フェールオーバーを強制すると、セカンダリ リージョンが新しいプライマリ リージョンになるため、プライマリ リージョンのすべてのデータが失われます。 フェールオーバー後、新しいプライマリ リージョンはローカルで冗長になるように構成されます。
フェールオーバーが発生した時点でセカンダリに既にコピーされているデータはすべて維持されます。 ただし、プライマリに書き込まれたデータのうち、セカンダリにコピーされていなかったものは、永久に失われます。
最終同期時刻プロパティを確認する
[最終同期時刻 (LST)] プロパティは、プライマリ リージョンのデータがセカンダリ リージョンに書き込まれたことが保証される最後の時刻を示します。 最終同期時刻より前に書き込まれたすべてのデータはセカンダリで使用できますが、最終同期時刻より後に書き込まれたデータは、セカンダリに書き込まれていない場合があり、失われる可能性があります。 障害が発生した場合はこのプロパティを使用して、アカウントのフェールオーバーを開始することによって負う可能性があるデータ損失の量を推定します。
フェールオーバーが発生したときにファイル共有が一貫した状態になるように、システム スナップショットが 15 分ごとにプライマリ リージョンに作成され、セカンダリ リージョンにレプリケートされます。 セカンダリ リージョンへのフェールオーバーが発生すると、共有状態はセカンダリ リージョンの最新のシステム スナップショットに基づくものになります。 プライマリ リージョンで障害が発生した場合、セカンダリ リージョンの内容はプライマリ リージョンよりも遅れている可能性が高いです。これは、プライマリへのすべての書き込みがまだセカンダリにレプリケートされていないためです。 geo ラグやその他の問題により、セカンダリ リージョンの最新のシステム スナップショットは 15 分を超えて遅れる可能性があります。
LST より前にプライマリ リージョンに書き込まれたすべての書き込み操作は、セカンダリ リージョンに正常にレプリケートされています。つまり、セカンダリ リージョンからの読み取りが可能です。 最終同期時刻の後にプライマリ リージョンに書き込まれた書き込み操作は、セカンダリ リージョンにレプリケートされている場合とそうでない場合があります。つまり、読み取りできない可能性があります。
[最終同期時刻] プロパティの値は、Azure PowerShell、Azure CLI、またはクライアント ライブラリのいずれかを使用してクエリできます。 [最終同期時刻] プロパティは、GMT 日付/時刻の値です。 詳細については、「ストレージ アカウントの最終同期時刻プロパティを確認する」を参照してください。
元のプライマリにフェールバックするときは注意が必要である
前述のとおり、プライマリからセカンダリ リージョンにフェールオーバーした後、ストレージ アカウントは新しいプライマリ リージョンでローカル冗長に構成されます。 その後、新しいプライマリ リージョンのアカウントを geo 冗長のために構成することができます。 フェールオーバー後にアカウントが geo 冗長のために構成されると、新しいプライマリ リージョンは直ちに新しいセカンダリ リージョン (元のフェールオーバーの前にプライマリであったもの) へのデータのコピーを開始します。 ただし、新しいプライマリの既存データが完全に新しいセカンダリにコピーされるまで、しばらくかかる場合があります。
ストレージ アカウントが geo 冗長のために再構成された後、新しいプライマリから新しいセカンダリにフェールバックを開始することができます。 この場合、フェールオーバー前の元のプライマリ リージョンが再びプライマリ リージョンとなり、元のプライマリ構成が GRS か GZRS かに応じて、ローカル冗長またはゾーン冗長になるように構成されます。 その場合、フェールオーバー後のプライマリ リージョン (元のセカンダリ) のすべてのデータはフェールバック時に失われます。 フェールバックの前にストレージ アカウントのほとんどのデータが新しいセカンダリにコピーされていなかった場合、大きなデータ損失が発生する可能性があります。
大きなデータ損失を防ぐため、フェールバックを行う前に、 [最終同期時刻] プロパティの値を確認してください。 最終同期時刻を、新しいプライマリにデータが書き込まれた最後の時刻と比較して、予想されるデータ損失を評価します。
フェールバック操作後は、新しいプライマリ リージョンを再び geo 冗長に構成することができます。 元のプライマリが LRS 用に構成されていた場合は、GRS に構成できます。 元のプライマリが ZRS 用に構成されていた場合は、GZRS に構成できます。 その他のオプションについては、「ストレージ アカウントがレプリケートされる方法を変更する」を参照してください。
アカウントのフェールオーバーを開始する
アカウントのフェールオーバーは、Azure portal、PowerShell、Azure CLI、または Azure Storage リソース プロバイダー API から開始できます。 フェールオーバーを開始する方法の詳細については、「アカウントのフェールオーバーを開始する」を参照してください。
Microsoft が管理するフェールオーバー
大きな災害のためにリージョンが失われるような極端な状況では、Microsoft がリージョン間のフェールオーバーを開始できます。 この場合、ユーザーによる操作は必要ありません。 Microsoft 管理のフェールオーバーが完了するまで、ストレージ アカウントに書き込みアクセスを行うことはできません。