Azure NetApp Files は、Azure内にシームレスに統合され、ネットワーク ファイル システム (NFS) プロトコルとサーバー メッセージ ブロック (SMB) プロトコルを介したクライアント間でのファイル共有を可能にする、ネイティブなエンタープライズ レベルのファイル ストレージ ソリューションです。 Azure NetApp Filesは高パフォーマンス向けに設計されており、サービスとして管理されるスケーラブルで安全なファイル ストレージを提供します。
Azureを使用する場合、信頼性は共有責任です。 Microsoft では、回復性と回復性をサポートするさまざまな機能を提供しています。 使用するすべてのサービスでこれらの機能がどのように機能するかを理解し、ビジネス目標とアップタイムの目標を達成するために必要な機能を選択する必要があります。
この記事では、一時的な障害、可用性ゾーンの停止、リージョンの停止など、さまざまな障害や問題に対する NetApp Files の回復性を確保する方法について説明します。 また、バックアップを使用して他の種類の問題から復旧する方法についても説明し、Azure NetApp Files サービス レベル アグリーメント (SLA) に関するいくつかの重要な情報を強調します。
運用環境のデプロイに関する推奨事項
ソリューションの信頼性要件をサポートするためにAzure NetApp Filesをデプロイする方法、および信頼性がアーキテクチャの他の側面にどのように影響するかについては、Azure Well-Architected Framework のAzure NetApp Filesに関する
信頼性アーキテクチャの概要
Azure NetApp Filesを使用するには、capacity プールを含み、volumes をホストする NetApp アカウントを構成する必要があります。 容量とスループットはそれぞれ独立して構成でき、さまざまなニーズに対応するデータ保護オプションを管理できます。 異なる場所にある場合でも、ボリューム間のレプリケーションを有効にできます。
一時的な障害に対する回復性
一時的な障害は、コンポーネントにおける短い断続的な障害です。 これらはクラウドのような分散環境で頻繁に発生し、運用の通常の範囲であり、 一時的な障害は、短時間の経過後に自分自身を修正します。 アプリケーションで一時的な障害を処理できることは重要です。通常は、影響を受ける要求を再試行します。
クラウドでホストされているすべてのアプリケーションは、クラウドでホストされている API、データベース、およびその他のコンポーネントと通信する際に、Azure一時的な障害処理ガイダンスに従う必要があります。 詳細については、「一時的な障害を処理するための推奨事項」を参照してください。
クラウド ベースのソリューションに影響を与える可能性がある一時的な障害の種類に加えて、プラットフォームの更新、サービスの更新、ソフトウェアのアップグレードなど、不定期の計画メンテナンスもAzure NetApp Filesに影響する可能性があります。
NFS や SMB などのファイル プロトコルの観点では、これらのイベント中に発生する可能性のある入出力 (I/O) の一時停止をアプリケーションが適切に処理できる場合、一時的な障害による影響はほとんどありません。 I/O の一時停止は通常、数秒から 30 秒程度の短い時間です。 一部のアプリケーションには、I/O の一時停止を処理するためにチューニングが必要になる場合があります。
NFS プロトコルは堅牢であり、クライアントとサーバー間のファイル操作は通常どおり継続されます。 一部のアプリケーションでは、30 から 45 秒間の I/O の一時停止に対応できるよう、チューニングが必要になることがあります。 ストレージ サービスのメンテナンス イベントに備えて、アプリケーションの回復性設定を把握しておいてください。
SMB プロトコルを使用する対話型アプリケーションでは、通常、標準のプロトコル設定で十分です。 Azure NetApp Filesでは、SMB の継続的可用性もサポートされています。これにより、SMB 透過的フェールオーバーが有効になります。 SMB 透過的フェールオーバーにより、サービス メンテナンス イベントによる中断を回避できます。 信頼性とユーザー エクスペリエンスの向上も実現されます。
SMB の継続的な可用性は、特定のアプリケーションでのみ使用できます。
その他の推奨事項については、アプリケーションの回復性に関する FAQ (Azure NetApp Filesを参照してください。
可用性ゾーンの障害に対する回復性
Availability zones は、Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。
Azure NetApp Filesでは、ボリュームの zonal デプロイがサポートされます。 Azure NetApp Filesの可用性ゾーン ボリューム配置機能を使用して、選択した単一の可用性ゾーンに各ボリュームをデプロイします。 この機能は、Azure NetApp Filesがその可用性ゾーンに存在し、十分な容量を持っている場合にのみ使用できます。 待機時間の影響を受けやすいアプリケーションがある場合は、Azureコンピューティング リソースやその他のサービスと同じ可用性ゾーンにボリュームをデプロイできます。
次の図では、実線の矢印が付いたオレンジ色の矢印は、ピアリングされた仮想ネットワーク内のリージョン内のすべての仮想マシン (VM) が、すべてのAzure NetApp Files リソースにアクセスする方法を表しています。 緑色の矢印は、同じゾーン内Azure NetApp Filesボリュームにアクセスする VM が可用性ゾーン障害ドメインを共有する方法を表します。 プラットフォーム レベルでは、異なるボリューム間でレプリケーションは行われません。
この図は、Azure リージョン内の 3 つの可用性ゾーンを示しています。 実線の矢印が付いたオレンジ色の矢印は、可用性ゾーン間で VM とAzure NetApp Filesリソースを表すアイコンを接続します。 緑色の矢印は、同じ可用性ゾーン内の VM と Azure NetApp Files ボリュームを接続します。
高い信頼性要件を満たすには、単一ゾーンの展開では不十分です。 異なる可用性ゾーン内のボリューム間にデータを非同期的にレプリケートするために、ゾーン間レプリケーションを使用できます。 ゾーン間レプリケーションは、可用性ゾーン ボリュームの配置とは別に構成する必要があります。
可用性ゾーンで障害が発生した場合は、ユーザーが障害を検出し、別のゾーンの別のボリュームに切り替える必要があります。
必要条件
リージョンのサポート: クロスゾーン レプリケーションは、Azure NetApp Files をサポートするすべての availability ゾーン対応リージョン で使用できます。Azure NetApp Files における可用性ゾーンでのボリューム配置は、ゾーンごとのデータ管理を可能にします。 同じ可用性ゾーン内の VM に接続すると、待機時間が短くなります。 ただし、可用性ゾーンのボリューム配置では、VM や他のリソースとの近接配置は保証されません。そのため、ボリュームがデータセンター内の異なる物理的領域に配置される場合があります。
異なるAzure サブスクリプション間でのレプリケーションは、同じMicrosoft Entra テナント内にある場合にのみ許可されます。
Azure NetApp Filesの可用性ゾーンの詳細については、「リージョン間レプリケーションと管理可用性ゾーンボリュームの配置を使用するための考慮事項を参照してください。
費用
Azure NetApp Filesで可用性ゾーン ボリュームの配置を有効にするための追加料金は発生しません。 これらのゾーン内にデプロイする容量プールとリソースに対してのみ課金されます。
レプリケートされたボリュームは容量プールでホストされます。 ゾーン間レプリケーションのコストは、プロビジョニングされた容量プールのサイズとサービス レベルに基づきます。 データ レプリケーションに追加コストはかからなくなります。
可用性ゾーンのサポートを設定する
ボリュームの配置とゾーン間レプリケーションを個別に構成する必要があります。
ボリュームの配置:
可用性ゾーンのサポートを使用して、新しいボリュームを作成するか、既存のボリュームを構成します。 Azure NetApp Filesのボリュームの可用性ゾーンを構成するには、Azure NetApp Files の可用性ゾーンボリュームの配置
管理に関するページを参照してください。 可用性ゾーンを使用して Terraform マネージド ボリュームをデプロイする場合は、他の構成が必要です。 詳細については、「Terraform マネージド ボリュームの可用性ゾーンの設定」を参照してください。
ロールベースのアクセス制御を使用する場合は、正しいアクセス許可を必ず構成してください。
可用性ゾーン間でボリュームを移行します。 ボリュームを可用性ゾーンに配置するように構成した後、指定された可用性ゾーンを変更することはできません。 可用性ゾーン間でボリュームを移動することはできません。
ボリュームの可用性ゾーンのサポートを無効にします。 ボリュームを可用性ゾーンに配置するように構成した後は、可用性ゾーンのサポートを無効にすることはできません。
ゾーン間レプリケーション:
ゾーン間レプリケーションを有効にします。 ソリューションの回復性を向上させるには、別のボリュームのゾーン間レプリケーションを構成します。
ゾーン間レプリケーションを無効にします。 ゾーン間レプリケーションを無効にするには、レプリケーションのペアリングを解除します。 詳細については、
Azure NetApp Files を参照してください。
すべてのゾーンが正常な場合の動作
このセクションでは、複数のAzure NetApp Files ボリュームが別々の可用性ゾーンにデプロイされ、ゾーン間レプリケーションが有効になり、すべての可用性ゾーンが動作する場合に想定される内容について説明します。
ゾーン間のトラフィック ルーティング: 受信要求は、選択した可用性ゾーンにある特定のボリュームにルーティングされます。
ゾーン間のデータ レプリケーション: Azure NetApp Files クロスゾーン レプリケーションは、ソース ボリュームに対するすべての変更がターゲット ボリュームに非同期的にレプリケートされることを意味します。 レプリケーションの実行頻度を決定できます。 ゾーン間レプリケーションでは、10 分ごと、1 時間ごと、毎日の 3 つのレプリケーション スケジュールがサポートされます。
Important
ゾーン間レプリケーションを使用する大規模ボリュームでは、10 分間のレプリケーション スケジュールはサポートされていません。
ゾーン障害時の動作
このセクションでは、複数のAzure NetApp Files ボリュームが別々の可用性ゾーンにデプロイされ、ゾーン間レプリケーションが有効になっていて、可用性ゾーンが停止した場合に想定される内容について説明します。
検出と応答: ユーザーが可用性ゾーンの損失を検出し、フェールオーバーを開始する必要があります。
フェールオーバーは手動プロセスです。 宛先の可用性ゾーンにフェールオーバーするときなど、宛先ボリュームをアクティブ化する必要があるときは、レプリケーション ピアリングを中断してから、宛先ボリュームをマウントする必要があります。 詳細については、 宛先ボリュームへのフェールオーバーを参照してください。
Notification: Azure NetApp Files ボリュームの正常性を監視するには、Azure Monitorメトリックを使用できます。 Azure Monitorは、1 秒あたりの入出力操作 (IOPS)、待機時間、容量使用量などのリアルタイム メトリックを使用して、ゾーンダウン シナリオを示す異常を検出します。 管理者がファイル共有の再調整、フェールオーバー、またはその他のディザスター リカバリー プロトコルをすぐに実行して対応できるように、アラートと通知を管理者に送信するよう構成できます。
アクティブな要求: ゾーンダウン イベント中に、アクティブな要求で中断や待機時間の増大が発生する可能性があります。
予想されるデータ損失: ゾーン フェールオーバー中に発生する可能性のあるデータ損失量、つまり回復ポイントの目標 (RPO) は、構成するゾーン間レプリケーション スケジュールによって異なります。
レプリケーションのスケジュール 一般的な RPO 10 分ごと 20 分 時間単位 2 時間 毎日 48 時間未満 予期されるダウンタイム: 別のゾーンにフェールオーバーするには、ピアリング関係を解除して宛先ボリュームをアクティブ化し、2 番めのサイトで読み取りと書き込みのデータ アクセスを提供する必要があります。 ピアリングの中断をトリガーすると、1 分以内にフェールオーバーが完了することが予想されます。
ただし、ゾーン フェールオーバー中に発生する可能性のあるダウンタイムの合計、つまり目標復旧時間 (RTO) は、システムまたはプロセスがゾーンの損失を検出し、フェールオーバー プロセスを開始するまでに要する時間など、複数の要因によって異なります。 また、応答を自動化するかどうか、または手動の手順が必要かどうかを決定することも重要です。 適切に準備された構成の場合、プロセス全体の完了には通常、数分から 1 時間かかります。
トラフィックの再ルーティング: アプリケーション トラフィックをリダイレクトして、新しくアクティブにした宛先ボリュームに接続する必要があります。 詳細については、 宛先ボリュームへのフェールオーバーを参照してください。
ゾーンの回復
フェールバックは手動プロセスであり、再同期操作を実行し、レプリケーションを再確立し、クライアントがアクセスするためのソース ボリュームを再マウントする必要があります。 詳細については、
ゾーンエラーのテスト
ボリュームのスナップショットを使用して、ゾーン間レプリケーション構成を安全にテストできます。 クロスゾーン レプリケーション構成をテストする方法の概要については、「
リージョン全体の障害に対する回復性
既定では、Azure NetApp Filesは単一リージョン サービスです。 リージョンが使用できなくなった場合、そのリージョンに格納されているボリュームも使用できなくなります。 リージョンの障害が発生した場合の回復性を向上させるために、Azure NetApp Filesではリージョン間レプリケーションがサポートされます。 あるリージョンのAzure NetApp Files ボリューム (ソース) から、Microsoft が事前選択する別のリージョンの別のAzure NetApp Files ボリューム (宛先) に非同期的にデータをレプリケートできます。 この機能により、リージョン全体が停止したり障害が発生した場合に、重要なアプリケーションをフェールオーバーすることができます。
注
1 つのボリュームを別の可用性ゾーン "および" 別のリージョンにレプリケートすることもできます。 詳細については、「Azure NetApp Files レプリケーションを参照してください。
必要条件
リージョンのサポート: ボリュームをレプリケートできるセカンダリ リージョンは、プライマリ リージョンによって異なります。 詳細については、サポートされているリージョンのペアを参照してください。
考慮事項
異なるAzure サブスクリプション間でのレプリケーションは、同じMicrosoft Entra テナント内にある場合にのみ許可されます。
Azure NetApp Filesでのリージョン間レプリケーションに関連するその他の考慮事項については、「リージョン間レプリケーションの使用に関する考慮事項」を参照してください。
費用
リージョン間レプリケーションの料金は、レプリケートするデータの量に基づいています。 詳細およびシナリオの例については、「リージョン間レプリケーションのコスト モデル」を参照してください。
複数リージョンのサポートを構成する
リージョン間レプリケーションを有効にする: ソリューションの回復性を向上させるには、リージョン間レプリケーションを構成します。
リージョン間レプリケーションを無効にする: レプリケーションのペアリングを解除することで、リージョン間レプリケーションを無効にできます。 詳細については、
Azure NetApp Files を参照してください。
すべてのリージョンが正常な場合の動作
このセクションでは、リージョン間レプリケーションを使用するようにAzure NetApp Files ボリュームが構成されていて、両方のリージョンが動作している場合に想定される内容について説明します。
リージョン間のトラフィック ルーティング: 着信要求は、プライマリ リージョンにある特定のボリュームにルーティングされます。
リージョン間のデータ レプリケーション: Azure NetApp Files リージョン間レプリケーションは、ソース ボリュームに対するすべての変更が、ターゲット ボリュームに非同期的にレプリケートされることを意味します。 レプリケーションの実行頻度を決定できます。 リージョン間レプリケーションでは、10 分ごと、1 時間ごと、毎日の 3 つのレプリケーション スケジュールがサポートされます。
Important
リージョン間レプリケーションを使用する大規模ボリュームでは、10 分間のレプリケーション スケジュールはサポートされていません。
レプリケーションの正常性の監視: ピアリング関係の正常性を監視し、予期されるしきい値をレプリケーションのラグが超えた場合に通知するようにアラートを構成できます。 詳細については、レプリケーション関係の正常性の表示と状態の監視に関するページを参照してください。
リージョン障害時の動作
このセクションでは、リージョン間レプリケーションを使用するようにAzure NetApp Files ボリュームが構成されていて、プライマリ リージョンが停止した場合に想定される内容について説明します。
検出と応答: ユーザーがリージョンの損失を検出し、フェールオーバーを開始する必要があります。 フェールオーバーは手動プロセスです。 宛先リージョンにフェールオーバーするときなど、宛先ボリュームをアクティブ化する必要があるときは、レプリケーション ピアリングを中断してから、宛先ボリュームをマウントする必要があります。 詳細については、 宛先ボリュームへのフェールオーバーを参照してください。
Notification: Azure NetApp Files ボリュームの正常性を監視するには、Azure Monitorメトリックを使用できます。 Azure Monitorは、IOPS、待機時間、容量使用量などのリアルタイム メトリックを使用して、リージョンダウン シナリオを示す異常を検出します。 管理者がファイル共有の再調整、フェールオーバー、またはその他のディザスター リカバリー プロトコルをすぐに実行して対応できるように、アラートと通知を管理者に送信するよう構成できます。
アクティブな要求: リージョンダウン イベント中に、アクティブな要求で中断や待機時間の増大が発生する可能性があります。
予想されるデータ損失: リージョンのフェールオーバー中に予想されるデータ損失 (RPO) の量は、構成するリージョン間レプリケーション スケジュールによって異なります。
レプリケーションのスケジュール 一般的な RPO 10 分ごと 20 分未満 時間単位 2 時間未満 毎日 48 時間未満 予想されるダウンタイム: 別のリージョンにフェールオーバーするには、ピアリング関係を解除して宛先ボリュームをアクティブ化し、2 番目のサイトで読み取りと書き込みのデータ アクセスを提供する必要があります。 ピアリングの中断をトリガーすると、1 分以内にフェールオーバーが完了することが予想されます。
ただし、ゾーンのフェールオーバー中に予想されるダウンタイム (RTO) の合計量は、システムまたはプロセスがゾーンの損失を検出し、フェールオーバー プロセスを開始するのにかかる時間など、複数の要因によって異なります。 また、応答を自動化するかどうか、または手動の手順が必要かどうかを決定することも重要です。 適切に準備された構成の場合、プロセス全体の完了には通常、数分から 1 時間かかります。
トラフィックの再ルーティング: アプリケーション トラフィックをリダイレクトして、新しくアクティブにした宛先ボリュームに接続する必要があります。 詳細については、 宛先ボリュームへのフェールオーバーを参照してください。
リージョンの復旧
プライマリ リージョンが復旧した後は、フェールバックを実行する責任があります。 フェールバックは手動プロセスであり、再同期操作を実行し、レプリケーションを再確立し、クライアントがアクセスするためのソース ボリュームを再マウントする必要があります。 詳細については、
リージョン障害のテスト
ボリュームのスナップショットを使用して、リージョン間レプリケーション構成を安全にテストできます。 リージョン間レプリケーション構成をテストするための高度なアプローチについては、「
バックアップと復元
Azure NetApp Files backup は、長期的な復旧、アーカイブ、コンプライアンスのためのフル マネージド バックアップ ソリューションを提供することで、Azure NetApp Filesのデータ保護機能を拡張します。 サービスによって作成されるバックアップは、短期的な復旧または複製に使用できるボリューム スナップショットとは別に、Azure ストレージに格納されます。 サービスが実行するバックアップは、リージョン内の新しいAzure NetApp Files ボリュームに復元できます。 Azure NetApp Files バックアップでは、ポリシー ベースの (スケジュールされた) バックアップと手動 (オンデマンド) バックアップの両方がサポートされます。
さらにセキュリティを強化するために、Azure NetApp Files snapshotsパフォーマンスに影響を与えることなく、安定性、スケーラビリティ、高速回復性を追加します。 バックアップ、リージョン間レプリケーション、ゾーン間レプリケーションなど、他の冗長性ソリューションの基盤が提供されます。
ほとんどのソリューションでは、バックアップのみに依存しないでください。 代わりに、このガイドで説明されている他の機能を使用して、回復性の要件をサポートします。 ただし、バックアップでは、他の方法では行わないリスクから保護されます。 詳細については、「冗長性、レプリケーション、バックアップとは」を参照してください。
サービス水準合意書
Azure サービスのサービス レベル アグリーメント (SLA) では、各サービスの予想される可用性と、その可用性の期待を達成するためにソリューションが満たす必要がある条件について説明します。 詳細については、オンラインサービスのSLAを参照してください。