Azure Files のディザスターリカバリーとフェールオーバー

[アーティクル]
08/10/2024

Microsoft は、Azure サービスを常に使用できるようにする作業に取り組んでいます。ただし、計画外のサービス停止が発生する可能性があるため、リージョンのサービス停止を処理するためのディザスターリカバリー (DR) 計画を立てる必要があります。ディザスターリカバリー計画の重要な部分は、プライマリエンドポイントが使用できなくなった場合に、セカンダリエンドポイントにフェールオーバーするための準備です。この記事では、ディザスターリカバリー (DR) とストレージアカウントのフェールオーバーに関連する概念とプロセスについて説明します。

重要

Azure File Sync では、ストレージ同期サービスもフェールオーバーされた場合にのみ、ストレージアカウントのフェールオーバーがサポートされます。これは、Azure File Sync では、ストレージアカウントとストレージ同期サービスが同じ Azure リージョンに存在する必要があるためです。ストレージアカウントのみがフェールオーバーされた場合、ストレージ同期サービスがセカンダリリージョンにフェールオーバーされるまで、同期操作とクラウド階層化操作は失敗します。 Azure File Sync でクラウドエンドポイントとして使用されている Azure ファイル共有を含むストレージアカウントをフェールオーバーする場合は、「Azure File Sync のディザスターリカバリーのベストプラクティス」、と「Azure File Sync サーバーの復旧」に関するページを参照してください。

顧客が管理する計画フェールオーバー (プレビュー)

カスタマーマネージド計画フェールオーバーは、計画ディザスターリカバリーテスト、大規模災害に対するプロアクティブなアプローチ、ストレージ関連以外の停止からの復旧など、複数のシナリオでも利用できます。

計画フェールオーバープロセス中に、プライマリリージョンとセカンダリリージョンがスワップされます。元のプライマリリージョンが降格され、新しいセカンダリリージョンになります。同時に、元のセカンダリリージョンが昇格され、新しいプライマリになります。フェールオーバーが完了すると、ユーザーは新しいプライマリリージョンでデータへのアクセスを続けることができ、管理者はディザスターリカバリー計画を検証できます。計画フェールオーバーを開始するには、プライマリとセカンダリ両方のリージョンでストレージアカウントを利用できる必要があります。

プライマリとセカンダリリージョンがプロセス全体を通して利用できる限り、計画フェールオーバーおよびフェールバックプロセス中のデータ損失は想定されていません。詳細については、「データ損失と不整合の予測」セクションを参照してください。

この種のフェールオーバーがユーザーとアプリケーションに与える影響を理解するには、計画フェールオーバーとフェールバックのプロセスのすべてのステップで何が行われているかを知っておくと役に立ちます。プロセスのしくみの詳細については、カスタマーマネージド計画フェールオーバーのしくみを参照してください。

重要

カスタマーマネージド計画フェールオーバーは現在プレビュー段階であり、次のリージョンに限り提供されます。

フランス中部
フランス南部
インド中部
インド西部
東アジア
東南アジア

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

重要

計画フェールオーバーの後、Azure Files データが存在する場合、ストレージアカウントの最終同期時刻 (LST) の値が古いように見えたり、NULL として報告されたりする可能性があります。

システムスナップショットは、フェールオーバーとフェールバックの間に使用される一貫性のある復旧ポイントを維持するために、ストレージアカウントのセカンダリリージョンに定期的に作成されます。カスタマーマネージド計画フェールオーバーを開始すると、元のプライマリリージョンが新しいセカンダリになります。場合によっては、計画フェールオーバーの完了後に新しいセカンダリ上に利用できるシステムスナップショットが存在しないことが原因で、アカウントの全体的な LST 値が古いままに見えたり、Null と表示されたりします。

オブジェクトの作成、変更、削除などのユーザーアクティビティによってスナップショットの作成をトリガーすることができるため、計画フェールオーバー後にこれらのアクティビティが発生するアカウントでは、特別な注意は必要ありません。ただし、スナップショットまたはユーザーアクティビティがないアカウントでは、システムスナップショットの作成がトリガーされるまで、Null LST 値が表示され続ける可能性があります。

必要に応じて、ストレージアカウント内の共有ごとに次のアクティビティのうちいずれかを行い、スナップショット作成をトリガーします。完了すると、30 分以内に有効な LST 値がアカウントに表示されます。

共有をマウントし、任意のファイルを読み取り用に開きます。
テストまたはサンプルのファイルを共有にアップロードします。

復旧メトリックとコスト

効果的な 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 が管理するフェールオーバー