次の方法で共有


Azure NetApp Files の信頼性

この記事では、Azure NetApp Files での信頼性のサポートについて説明します。 可用性ゾーン複数リージョンのデプロイによるリージョン内の回復性について説明します。

信頼性は、お客様と Microsoft の間で共有される責任です。 このガイドを使用して、特定のビジネス目標とアップタイム目標を満たす信頼性オプションを決定できます。

Azure NetApp Files は、Azure 内にシームレスに統合されたネイティブなエンタープライズ レベルのファイル ストレージ ソリューションであり、SMB および NFS プロトコルを介してクライアント間でファイル共有を可能にします。 高パフォーマンス向けに設計された Azure NetApp Files は、サービスとして管理されるスケーラブルで安全なファイル ストレージを提供します。

Azure NetApp Files を使用するには、ボリュームをホストする 容量プール を含む NetApp アカウントを構成 する必要があります。 容量とスループットを個別に構成し、さまざまなニーズに合わせて調整されたデータ保護オプションを管理できます。 異なる場所にある場合でも、ボリューム間のレプリケーションを有効にすることができます。

運用環境のデプロイに関する推奨事項

ソリューションの信頼性要件をサポートするために Azure NetApp Files をデプロイする方法と、信頼性がアーキテクチャの他の側面にどのように影響するかについては、「 Azure Well-Architected Framework での Azure NetApp Files のアーキテクチャのベスト プラクティス」を参照してください。

一時的な障害

一時的な障害は、コンポーネントにおける短い断続的な障害です。 これらはクラウドのような分散環境で頻繁に発生し、運用の通常の範囲であり、 一時的な障害は、短時間の経過後に自分自身を修正します。 アプリケーションで一時的な障害を処理できることは重要です。通常は、影響を受ける要求を再試行します。

クラウドでホストされるすべてのアプリケーションは、クラウドでホストされている 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 Transparent Failover では、サービス メンテナンス イベントによって発生する中断が排除されます。 また、信頼性とユーザー エクスペリエンスも向上します。

SMB の継続的な可用性は、 特定のアプリケーションでのみ使用できます。

その他の推奨事項については、 Azure NetApp Files アプリケーションの回復性に関する FAQ を参照してください。

可用性ゾーンのサポート

可用性ゾーン は、各 Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。

Azure NetApp Files では、ボリュームの ゾーン デプロイがサポートされています。 Azure NetApp Files の可用性ゾーン ボリューム配置機能 を使用すると、Azure NetApp Files がその可用性ゾーンに存在し、十分な容量がある限り、各ボリュームを選択した単一の可用性ゾーンにデプロイできます。 待機時間の影響を受けやすいアプリケーションがある場合は、Azure コンピューティング リソースおよび同じゾーン内の他のサービスと同じ可用性ゾーンにボリュームをデプロイできます。

次の図では、(ピアリングされた) VNet 内のリージョン内のすべての仮想マシン (VM) が、すべての Azure NetApp Files リソース (青い矢印) にアクセスできます。 同じゾーンにある Azure NetApp Files ボリュームにアクセスする VM (緑色の矢印) は、可用性ゾーンの障害ドメインを共有します。 プラットフォーム レベルで異なるボリューム間にレプリケーションがないことに注目してください。

NetApp Files 可用性ゾーン ボリュームの配置を示す図。

高い信頼性の要件を満たすには、単一ゾーンのデプロイでは不十分です。 異なる可用性ゾーン内のボリューム間でデータを非同期的にレプリケートするには、 ゾーン間レプリケーションを使用できます。 ゾーン間レプリケーションは、可用性ゾーン ボリュームの配置とは別に構成する必要があります。

可用性ゾーンで障害が発生した場合は、障害を検出し、別のゾーンの別のボリュームに切り替える必要があります。

リージョンのサポート

クロスゾーン レプリケーションは、Azure NetApp Files が存在するすべての可用性ゾーン対応リージョンで使用できます。

考慮事項

  • Azure NetApp Files での可用性ゾーンボリュームの配置は、ゾーンボリュームの配置を提供します。 同じ可用性ゾーン内の仮想マシンに接続すると、待機時間が短くなります。 ただし、仮想マシンやその他のリソースとの近接配置は提供されません。また、ボリュームがデータセンターの別の物理的な部分にある可能性があります。

  • 異なる Azure サブスクリプションが同じ Microsoft Entra テナント内にある限り、レプリケーションは異なる Azure サブスクリプション間で許可されます。

  • Azure NetApp Files の可用性ゾーンに関連するその他の考慮事項については、「クロスゾーン レプリケーションの使用に関する要件と考慮事項」および「可用性ゾーンボリュームの配置の管理」を参照してください。

費用

Azure NetApp Files で可用性ゾーン ボリュームの配置を有効にするための追加料金は発生しません。 これらのゾーン内にデプロイする容量プールとリソースに対してのみ課金されます。

レプリケートされたボリュームは容量プールでホストされます。 そのため、ゾーン間レプリケーションのコストは、通常どおり、プロビジョニングされた容量プールのサイズと階層に基づきます。 データ レプリケーションの追加コストは発生しません。

可用性ゾーンのサポートを設定する

ボリューム配置とクロスゾーン レプリケーションを個別に構成する必要があります。

  • ボリュームの配置:

    • 可用性ゾーンのサポートを使用して、新しいボリュームを作成するか、既存のボリュームを構成します。 Azure NetApp Files でボリュームの可用性ゾーンを構成するには、「Azure NetApp Files の可用性ゾーンボリューム配置の管理」を参照してください。

      可用性ゾーンを使用して Terraform マネージド ボリュームをデプロイする場合は、他の構成が必要です。 詳細については、 Terraform マネージド ボリュームの可用性ゾーンの設定に関するページを参照してください。

      ロールベースのアクセス制御を使用している場合は、 正しいアクセス許可を構成してください

    • 可用性ゾーン間でボリュームを移行する: ボリュームが可用性ゾーンに配置されるように構成された後、指定された可用性ゾーンを変更することはできません。 可用性ゾーン間でボリュームを移動することはできません。

    • ボリュームの可用性ゾーンのサポートを無効にします。 ボリュームが可用性ゾーンに配置されるように構成された後、可用性ゾーンのサポートを無効にすることはできません。

  • ゾーン間レプリケーション:

通常の運用

このセクションでは、Azure NetApp Files ボリュームが複数の可用性ゾーンにデプロイされるように構成され、ゾーン間レプリケーションが有効になり、すべての可用性ゾーンが動作する場合に想定される内容について説明します。

  • ゾーン間のトラフィック ルーティング: 受信要求は、選択した可用性ゾーンにある特定のボリュームにルーティングされます。

  • ゾーン間のデータ レプリケーション: Azure NetApp Files のクロスゾーン レプリケーションは、ソース ボリュームに対するすべての変更が同期先ボリュームに非同期的にレプリケートされることを意味します。 レプリケーションの実行頻度を決定できます。 ゾーン間レプリケーションでは、10 分、毎時、毎日の 3 つのレプリケーション スケジュールがサポートされます。

    Von Bedeutung

    ゾーン間レプリケーションを使用した大容量ボリュームでは、10 分のレプリケーション スケジュールはサポートされません。

ゾーンダウン エクスペリエンス

このセクションでは、Azure NetApp Files ボリュームが複数の可用性ゾーンにデプロイされるように構成され、ゾーン間レプリケーションが有効になり、可用性ゾーンが停止した場合に想定される内容について説明します。

  • 検出と応答: 可用性ゾーンの損失を検出し、フェールオーバーを開始する責任があります。

    Azure NetApp Files ボリュームの正常性を監視するには、Azure Monitor メトリックを使用できます。 ゾーンダウン シナリオを示す異常は、IOPS、待機時間、容量使用量などのリアルタイム メトリックを使用して検出されます。 アラートと通知を管理者に送信するように構成できます。これにより、ファイル共有の再調整やフェールオーバーまたはその他のディザスター リカバリー プロトコルの開始などの即時の応答アクションが可能になります。

    フェールオーバーは手動プロセスです。 宛先の可用性ゾーンにフェールオーバーする場合など、宛先ボリュームをアクティブ化する必要がある場合は、レプリケーション ピアリングを中断してから、宛先ボリュームをマウントする必要があります。 詳細については、 宛先ボリュームへのフェールオーバーを参照してください。

  • アクティブな要求: ゾーンダウン イベント中に、アクティブな要求で中断や待機時間の増加が発生する可能性があります。

  • 予想されるデータ損失: ゾーンのフェールオーバー中に予想できるデータ損失の量 (目標復旧ポイントまたは RPO とも呼ばれます) は、構成するクロスゾーン レプリケーション スケジュールによって異なります。

    レプリケーション スケジュール 一般的な RPO
    10 分ごと 20 分
    毎時 2時間
    毎日 48 時間未満
  • 予想されるダウンタイム: 別のゾーンにフェールオーバーするには、ピアリング関係を解除して宛先ボリュームをアクティブ化し、2 番目のサイトで読み取りと書き込みのデータ アクセスを提供する必要があります。 ピアリングの中断をトリガーした後、1 分以内に完了することが期待できます。

    ただし、ゾーンのフェールオーバー中に予想できるダウンタイムの合計量 (目標復旧時間(RTO) とも呼ばれます)は、システムまたはプロセスがゾーンの損失を検出し、フェールオーバー プロセスを開始するのにかかる時間など、複数の要因によって異なります。 また、応答を自動化するか、手動の手順が必要かを決定することも重要です。 適切に準備された構成の場合、全体的なプロセスには通常、数分から最大 1 時間が必要です。

  • トラフィックの再ルーティング: アプリケーション トラフィックをリダイレクトして、新しくアクティブな宛先ボリュームに接続する必要があります。 詳細については、 宛先ボリュームへのフェールオーバーを参照してください。

フェールバック

フェールバックは、再同期操作を実行し、レプリケーションを再確立し、クライアントがアクセスするためのソース ボリュームを再マウントする必要がある手動プロセスです。 詳細については、「 Azure NetApp Files を使用したディザスター リカバリーの管理」を参照してください。

ゾーン障害を検出するためのテスト

ボリュームのスナップショットを使用して、クロスゾーン レプリケーション構成を安全にテストできます。 クロスゾーン レプリケーション構成をテストする方法の概要については、「 Azure NetApp Files のディザスター リカバリーのテスト」を参照してください。

マルチリージョン サポート

既定では、Azure NetApp Files は単一リージョン サービスです。 リージョンが使用できなくなった場合、そのリージョンに格納されているボリュームも使用できなくなります。 リージョンの障害が発生した場合の回復性を向上させるために、Azure NetApp Files ではリージョン間レプリケーションがサポートされています。 あるリージョンの Azure NetApp Files ボリューム (ソース) から、Microsoft によって事前に選択されている別のリージョンの別の Azure NetApp Files ボリューム (宛先) に非同期的にデータをレプリケートできます。 この機能により、リージョン全体が停止したり障害が発生した場合に、重要なアプリケーションをフェールオーバーすることができます。

1 つのボリュームを別の可用性ゾーン 別のリージョンにレプリケートすることもできます。 詳細については、「 Azure NetApp Files でのゾーン間レプリケーションについて」を参照してください。

リージョンのサポート

ボリュームをレプリケートできるセカンダリ リージョンは、プライマリ リージョンによって異なります。 詳細については、 サポートされているリージョンのペアを参照してください。

考慮事項

異なる Azure サブスクリプションが同じ Microsoft Entra テナント内にある限り、レプリケーションは異なる Azure サブスクリプション間で許可されます。

Azure NetApp Files でのリージョン間レプリケーションに関連するその他の考慮事項については、「 リージョン間レプリケーションを使用するための要件と考慮事項」を参照してください。

費用

リージョン間レプリケーションは、レプリケートするデータのマウントに基づいて課金されます。 詳細とシナリオ例については、 リージョン間レプリケーションのコスト モデルに関するページを参照してください。

複数リージョンのサポートを構成する

通常の運用

このセクションでは、リージョン間レプリケーションを使用するように Azure NetApp Files ボリュームが構成されていて、両方のリージョンが動作している場合に想定される内容について説明します。

  • リージョン間のトラフィック ルーティング: 受信要求は、プライマリ リージョンにある特定のボリュームにルーティングされます。

  • リージョン間のデータ レプリケーション: Azure NetApp Files のリージョン間レプリケーションは、ソース ボリュームに対するすべての変更がターゲット ボリュームに非同期的にレプリケートされることを意味します。 レプリケーションの実行頻度を決定できます。 リージョン間レプリケーションでは、10 分、毎時、毎日の 3 つのレプリケーション スケジュールがサポートされます。

    Von Bedeutung

    リージョン間レプリケーションを使用する 大規模ボリューム では、10 分間のレプリケーション スケジュールはサポートされていません。

  • レプリケーションの正常性を監視する: ピアリング関係の正常性を監視し、レプリケーションのラグが予想されるしきい値を超えた場合に通知するようにアラートを構成できます。 詳細については、 レプリケーション関係の正常性の表示と状態の監視に関するページを参照してください。

リージョンダウン エクスペリエンス

このセクションでは、リージョン間レプリケーションを使用するように Azure NetApp Files ボリュームが構成されていて、プライマリ リージョンが停止した場合に想定される内容について説明します。

  • 検出と応答: リージョンの損失を検出し、フェールオーバーを開始する責任があります。

    Azure NetApp Files ボリュームの正常性を監視するには、Azure Monitor メトリックを使用できます。 リージョンダウン シナリオを示す異常は、IOPS、待機時間、容量使用量などのリアルタイム メトリックを使用して検出されます。 アラートと通知を管理者に送信するように構成できます。これにより、ファイル共有の再調整やフェールオーバーやその他のディザスター リカバリー プロトコルの開始などの即時応答アクションが可能になります。

    フェールオーバーは手動プロセスです。 宛先リージョンにフェールオーバーする場合など、宛先ボリュームをアクティブ化する必要がある場合は、レプリケーション ピアリングを中断してから、宛先ボリュームをマウントする必要があります。 詳細については、 宛先ボリュームへのフェールオーバーを参照してください。

  • アクティブな要求: リージョンダウン イベント中に、アクティブな要求で中断や待機時間の増加が発生する可能性があります。

  • 予想されるデータ損失: リージョンのフェールオーバー中に予想できるデータ損失の量 (目標復旧ポイントまたは RPO とも呼ばれます) は、構成するリージョン間レプリケーション スケジュールによって異なります。

    レプリケーション スケジュール 一般的な RPO
    10 分ごと 20 分未満
    毎時 2 時間未満
    毎日 48 時間未満
  • 予想されるダウンタイム: 別のリージョンにフェールオーバーするには、ピアリング関係を解除して宛先ボリュームをアクティブ化し、2 番目のサイトで読み取りと書き込みのデータ アクセスを提供する必要があります。 ピアリングの中断をトリガーした後、1 分以内に完了することが期待できます。

    ただし、ゾーンのフェールオーバー中に予想できるダウンタイムの合計量 (目標復旧時間(RTO) とも呼ばれます)は、システムまたはプロセスがゾーンの損失を検出し、フェールオーバー プロセスを開始するのにかかる時間など、複数の要因によって異なります。 また、応答を自動化するか、手動の手順が必要かを決定することも重要です。 適切に準備された構成の場合、全体的なプロセスには通常、数分から最大 1 時間が必要です。

  • トラフィックの再ルーティング: アプリケーション トラフィックをリダイレクトして、新しくアクティブな宛先ボリュームに接続する必要があります。 詳細については、 宛先ボリュームへのフェールオーバーを参照してください。

フェールバック

フェールバックは、再同期操作を実行し、レプリケーションを再確立し、クライアントがアクセスするためのソース ボリュームを再マウントする必要がある手動プロセスです。 詳細については、「 Azure NetApp Files を使用したディザスター リカバリーの管理」を参照してください。

リージョンの障害のテスト

ボリュームのスナップショットを使用して、リージョン間レプリケーション構成を安全にテストできます。 リージョン間レプリケーション構成をテストするための高度なアプローチについては、「 Azure NetApp Files のディザスター リカバリーのテスト」を参照してください。

バックアップ

Azure NetApp Files バックアップ は、長期的な復旧、アーカイブ、コンプライアンスのためのフル マネージド バックアップ ソリューションを提供することで、Azure NetApp Files のデータ保護機能を拡張します。 サービスによって作成されたバックアップは、短期的な回復や複製に使用できるボリューム スナップショットに依存せずに、Azure ストレージに格納されます。 サービスによって作成されたバックアップは、リージョン内の新しい Azure NetApp Files ボリュームに復元できます。 Azure NetApp Files バックアップでは、ポリシーベース (スケジュールされた) バックアップと手動 (オンデマンド) バックアップの両方がサポートされます。

さらにセキュリティを強化するために、Azure NetApp Files スナップショットは 、パフォーマンスに影響を与えることなく、安定性、スケーラビリティ、高速復旧性を追加します。 バックアップ、リージョン間レプリケーション、ゾーン間レプリケーションなど、他の冗長性ソリューションの基盤が提供されます。

ほとんどのソリューションでは、バックアップのみに依存しないでください。 代わりに、このガイドで説明されている他の機能を使用して、回復性の要件をサポートします。 ただし、バックアップでは、他の方法では行わないリスクから保護されます。 詳細については、「冗長性、 レプリケーション、バックアップとは」を参照してください。

サービス水準合意書

Azure NetApp Files のサービス レベル アグリーメント (SLA) には、サービスの予想される可用性と、その可用性の期待を達成するために満たす必要がある条件が記述されています。 詳細については、「Online Services のサービス レベル アグリーメント (SLA)」を参照してください。