可用性および耐久性:　シングル AZ およびマルチ AZ のファイルシステム

Amazon FSx for Windows File Server は、2 種類のファイルシステムのデプロイを提供します。シングル AZ およびマルチ AZ です。以下のセクションでは、ワークロードに適したデプロイタイプを選択するのに役立つ情報を提供します。サービスの可用性の SLA (サービスレベルアグリーメント) については、「Amazon FSx Service Level Agreement」(Amazon FSx サービスレベルアグリーメント) を参照してください。

シングル AZ ファイルシステムは、単一の Windows ファイルサーバーインスタンスと、単一のアベイラビリティーゾーン (AZ) 内の一連のストレージボリュームで構成されます。シングル AZ ファイルシステムでは、ほとんどの場合、単一のコンポーネントの障害からそのデータを保護できるように自動的に複製されます。Amazon FSx はハードウェア障害を継続的に監視し、障害が発生したインフラストラクチャコンポーネントを交換することで、障害イベントから自動的に回復します。シングル AZ ファイルシステムは、これらの障害回復イベント中、およびファイルシステムに設定したメンテナンスウィンドウ内の計画的なファイルシステムのメンテナンスの間、通常 20 分未満オフラインになります。シングル AZ ファイルシステムでは、複数のコンポーネントに障害が発生したり、単一ファイルサーバーに障害が発生してファイルシステムが一貫性のない状態になったりして、まれにファイルシステムの障害を回復できない場合があります。その場合は、最新のバックアップからファイルシステムを回復できます。

マルチ AZ ファイルシステムは、Windows Server フェイルオーバー クラスタリング (WSFC) テクノロジーと 2 つの AZ のそれぞれにあるストレージボリュームセットを活用して、2 つの AZ (優先 AZ とスタンバイ AZ) に分散した Windows ファイルサーバーの高可用性クラスターで構成されます。データは、個々の AZ 内と 2 つの AZ 間で同期的に複製されます。シングル AZ 配置と比較して、マルチ AZ 配置では AZ 間でデータをさらに複製することで耐久性が向上し、スタンバイ AZ に自動的にフェイルオーバーされるため、計画的なシステムメンテナンスや計画外のサービス中断時の可用性が向上します。これにより、引き続きデータにアクセスできるようになり、インスタンスの障害や AZ の中断からデータを保護することに役立ちます。

シングル AZ またはマルチ AZ ファイルシステムのデプロイを選択する

高い可用性と耐久性モデルを備えたマルチ AZ ファイルシステムは、ほとんどのプロダクションワークロードで使用することをお勧めします。シングル AZ 配置は、テストおよび開発ワークロード、アプリケーションレイヤーにレプリケーションが組み込まれ、追加のストレージレベルの冗長性を必要としない特定の本番ワークロード、および可用性と目標復旧時点 (RPO) のニーズが緩い本番ワークロード向けのコスト効率の高いソリューションとして設計されています。可用性と RPO のニーズが緩やかなワークロードでは、計画的なファイルシステムのメンテナンスや計画外のサービス中断が発生した場合、最大 20 分間の一時的な可用性の喪失を許容できます。また、まれに、最新のバックアップ以降のデータ更新の損失が発生することもあります。

デプロイタイプがサポートする機能

以下の表は、FSx for Windows ファイルサーバーのファイルシステムデプロイタイプがサポートする機能の概要を示したものです。

デプロイタイプ	SSD ストレージ	HDD ストレージ	DFS 名前空間	DFS レプリケーション	カスタム DNS 名	CA の共有
シングル AZ 1	✓		✓	✓	✓
シングル AZ 2	✓	✓	✓		✓	✓*
マルチ AZ	✓	✓	✓		✓	✓*

注記

* シングル AZ 2 ファイルシステムに継続的に使用可能 (CA) な共有を作成することは可能ですが、SQL Server HA のデプロイにはマルチ AZ ファイルシステムの CA 共有を使用する必要があります。

FSx for Windows ファイルサーバーのフェイルオーバープロセス

マルチ AZ ファイルシステムは、以下のいずれかの条件が発生した場合、優先ファイルサーバーからスタンバイファイルサーバーに自動的にフェイルオーバーします。

• アベイラビリティーゾーンの機能停止が発生した場合。

• 優先ファイルサーバーが使用できなくなった場合。

• 優先ファイルサーバーが計画的なメンテナンスを実行する場合。

あるファイルサーバーから別のファイルサーバにフェイルオーバーすると、新しいアクティブファイルサーバーは自動的にすべてのファイルシステムの読み取りおよび書き込みリクエストを処理し始めます。優先サブネットのリソースが使用可能になると、Amazon FSx は優先サブネット内の優先ファイルサーバーに自動的にフェイルバックします。アクティブファイルサーバ上の障害を検出してからスタンバイファイルサーバがアクティブ状態に推進するまで、フェイルオーバーは通常 30 秒以内に完了します。元のマルチ AZ 設定へのフェールバックも 30 秒以内に完了し、優先サブネット内のファイルサーバーが完全に復旧した後にのみ実行されます。

ファイルシステムがフェイルオーバーしてフェイルバックする短い期間、I/O が一時停止し、Amazon CloudWatch メトリクスが一時的に使用できなくなる場合があります。

マルチ AZ ファイルシステムでは、フェイルオーバーおよびフェイルバック中にトラフィックが継続している場合、このときに実行したすべてのデータ変更をファイルサーバー間で同期する必要があります。書き込みが多いワークロードや IOPS が多いワークロードの場合、このプロセスには最大で数時間かかることがあります。ファイルシステムの負荷が軽いうちに、フェイルオーバーがアプリケーションに与える影響をテストすることをお勧めします。

Windows のクライアントでのフェイルオーバーのエクスペリエンス

あるファイルサーバーから別のファイルサーバにフェイルオーバーすると、新しいアクティブファイルサーバーは自動的にすべてのファイルシステムの読み取りおよび書き込みリクエストを処理し始めます。優先サブネットのリソースが使用可能になると、Amazon FSx は優先サブネット内の優先ファイルサーバーに自動的にフェイルバックします。ファイルシステムの DNS 名が変わらないため、フェイルオーバーは Windows アプリケーションに対して透過的に行われ、マニュアル操作することなくファイルシステムオペレーションを再開することができます。アクティブファイルサーバ上の障害を検出してからスタンバイファイルサーバがアクティブ状態に推進するまで、フェイルオーバーは通常 30 秒以内に完了します。元のマルチ AZ 設定へのフェールバックも 30 秒以内に完了し、優先サブネット内のファイルサーバーが完全に復旧した後にのみ実行されます。

Linux のクライアントでのフェイルオーバーのエクスペリエンス

Linux のクライアントは、DNS ベースの自動フェイルオーバーをサポートしていません。そのため、フェイルオーバー時にスタンバイファイルサーバーに自動的に接続されることはありません。マルチ AZ ファイルシステムが優先サブネット内のファイルサーバーにフェイルバックした後、ファイルシステムオペレーションを自動的に再開します。

ファイルシステムでフェイルオーバーをテストする

マルチ AZ ファイルシステムのスループット容量を変更することでフェイルオーバーをテストすることができます。ファイルシステムのスループット容量を変更すると、Amazon FSx はファイルシステムのファイルサーバーを切り替えます。マルチ AZ ファイルシステムはセカンダリサーバーに自動的にフェイルオーバーし、Amazon FSx は優先サーバーファイルのサーバーを最初に置き換えます。その後、ファイルシステムは自動的に新しいプライマリサーバーにフェイルバックし、Amazon FSx がセカンダリファイルサーバーを置き換えます。

Amazon FSx コンソール、CLI、および API で、スループット容量更新リクエストの進行状況をモニタリングできます。更新が正常に完了すると、ファイルシステムがセカンダリサーバーにフェイルオーバーされ、プライマリサーバーにフェイルバックします。ファイルシステムのスループット容量の変更、およびリクエストの進行状況のモニタリングに関する詳細については、「スループット容量の管理」を参照してください。

シングルおよびマルチ AZ ファイルシステムリソースの使用

サブネット

VPC を作成すると、同じリージョンのアベイラビリティーゾーン (AZ) すべてにおよびます。アベイラビリティーゾーンは、他のアベイラビリティーゾーンの障害から隔離されるように設計された別個の場所です。VPC を作成した後、各アベイラビリティーゾーンに 1 つまたは複数のサブネットを追加することができます。各アベイラビリティーゾーンにはデフォルト VPC のサブネットがあります。各サブネットが 1 つのアベイラビリティーゾーン内に完全に含まれている必要があり、1 つのサブネットが複数のゾーンに及ぶことはできません。シングル AZ Amazon FSx ファイルシステムを作成する際は、ファイルシステムに対して単一のサブネットを指定します。選択したサブネットは、ファイルシステムが作成されるアベイラビリティーゾーンを定義します。

マルチ AZ ファイルシステムを作成する場合、2 つのサブネットを指定します。1 つは優先ファイルサーバー用、もう 1 つはスタンバイファイルサーバー用です。選択する 2 つのサブネットは、同じ AWS リージョン内の異なるアベイラビリティーゾーンに存在する必要があります。

AWS アプリケーション内では、レイテンシーを最小限に抑えるために、優先ファイルサーバーと同じアベイラビリティーゾーンでクライアントを起動することをお勧めします。

ファイルシステム Elastic Network Interface

Amazon FSx ファイルシステムを作成すると、Amazon FSx はファイルシステムに関連付ける Amazon Virtual Private Cloud(VPC) に 1 つ以上の elastic network interface をプロビジョニングします。ネットワークインターフェイスを使用して、クライアントは FSx for Windows ファイルサーバーのファイルシステムと通信することができます。このネットワークインターフェイスは、お客様のアカウントの VPC の一部ですが、Amazon FSx のサービス範囲内として考えられます。マルチ AZ ファイルシステムには、ファイルサーバーごとに 1 つずつ、合計 2 つの Elastic Network Interface があります。シングル AZ ファイルシステムには 1 つの elastic network interface があります。

警告

ファイルシステムに関連付けられている Elastic Network Interface は、変更または削除しないでください。このネットワークインターフェイスを変更または削除すると、VPC とファイルシステムとの間の接続が完全に失われる可能性があります。

以下の表は、FSx for Windows ファイルサーバーファイルシステムデプロイタイプのサブネット、elastic network interface および IP アドレスリソースの概要を示したものです。

ファイルシステムのデプロイタイプ	サブネット数	Elastic Network Interface 数	IP アドレス番号
シングル AZ 2	1	1	2
シングル AZ 1	1	1	1
マルチ AZ	2	2	4

ファイルシステムが作成されると、ファイルシステムが削除されるまでその IP アドレスは変更されません。

重要

Amazon FSx は、パブリックインターネットからのファイルシステムへのアクセス、またはファイルシステムへの公開をサポートしていません。インターネットから到達可能なパブリック IP アドレスである Elastic IP アドレスがファイルシステムの Elastic Network Interface に添付されると、Amazon FSx は自動的にデタッチします。