Amazon FSx for OpenZFS を使うなら、デプロイメントタイプと、その内部の動作を押さえておきたいところです。現在サポートされているのは、Single-AZ（非HA）、Single-AZ（HA）、Multi-AZ（HA）の3種類です。
新しいファイルシステムを作成する際には、Quick Create と Standard Create の2つの作成方法が用意されています。Quick Create はセットアップ手順を簡略化したもので、Standard Create はより詳細な構成が可能です。
実は Standard Create は単に推奨されているだけでなく、3つのデプロイメントタイプのうち2つでは必須となっています。最初からファイルシステムの構成を細かく制御できるため、ほとんどのケースで Standard Create が望ましい選択肢となります。
Single-AZ（非HA）デプロイメントタイプ
Single-AZ（非HA）は Quick Create では選択できないため、Standard Create の手順を選ぶ必要があります（図1参照）。作成されるファイルシステムは1つで、障害が発生した場合は故障したインフラコンポーネントが置き換えられて自動的に復旧されますが、復旧中はダウンタイムが発生し、データも失われます。まれにファイルシステム自体が復旧不能となり、バックアップ未取得のデータがすべて失われるケースもあります。
なお、適切なセキュリティグループをアタッチし、トラフィックを許可するセキュリティグループルールを正しく設定する必要がある点に注意してください（Quick Create を使うと、デフォルトで VPC のデフォルトセキュリティグループがアタッチされます）。これはすべてのデプロイメントタイプに共通する注意事項です。
図1 — Quick Create の FSx 作成画面。
Single-AZ（HA）デプロイメントタイプ
Single-AZ（HA）では Quick Create と Standard Create のいずれも選べますが、サブネットとセキュリティグループを任意に指定できる Standard Create のほうがおすすめです。
このデプロイメントタイプでは、同一サブネット内に2つのファイルシステムが作成され、合わせてエンドポイント IP アドレスも作成されます（詳細は Multi-AZ のセットアップで掘り下げます）。FSx はこのエンドポイント IP アドレスを使ってフェイルオーバーを処理します。FSx の DNS 名はこのエンドポイント IP アドレスを指しており、エンドポイント IP アドレスは現在アクティブなファイルシステムの ENI にセカンダリ IP アドレスとしてアタッチされています。フェイルオーバーが発生すると、エンドポイント IP アドレスは現在アクティブなファイルシステムの ENI から切り離され、スタンバイ側ファイルシステムの ENI にアタッチされます。これにより DNS は同じ IP を指したままで、メイン側のファイルシステムが完全に復旧するまでの間、その IP がスタンバイ側の ENI に紐付く状態になります。
上記2つのデプロイメントタイプでは最小限の設定で EC2 インスタンスにファイルシステムをマウントできますが、Multi-AZ デプロイメントタイプでは追加の手順が必要になります。
Multi-AZ デプロイメントタイプ
Multi-AZ デプロイメントタイプを利用する際は、必ず Standard Create を選ぶことが重要です。Quick Create ではサブネットの選択もルートテーブルの関連付けもできません。FSx ファイルシステムへのルートテーブルの関連付けは、Multi-AZ 構成でのみ利用可能です。
Quick Create で Multi-AZ をセットアップすると、関連付けにはデフォルトのルートテーブルしか使われません。一方で、サブネットは独自のルートテーブルを使っているのが一般的です。なぜこれが問題になるのでしょうか。この方法でセットアップすると、初期状態ではネットワーク接続が確立されず、接続がタイムアウトしてしまうのです。実際、私のあるクライアントが Quick Create を試したときにこの問題に遭遇し、仕組みを理解するために深掘りすることになりました。
同じ VPC 内のリソースであれば「local」ルート経由で FSx ファイルシステムに自動的に接続できると思うかもしれません。実際、VPC 内の RDS、ElastiCache、EC2 インスタンスといった他の AWS サービスにはこの方法でアクセスでき、Single-AZ の FSx ファイルシステムも同様にアクセス可能です。ところが、ここに思わぬ落とし穴があります。今回のケースではこの前提が成り立たず、「local」ルートだけでは FSx ファイルシステムへの接続を確立できないのです。
では、このケースで接続を有効にするにはどうすればよいのでしょうか。端的に言えば、EC2 インスタンスが配置されているサブネットのルートテーブルを、FSx ファイルシステムに関連付ける必要があります。「ルートテーブル」の横にある「管理」をクリックすれば、ルートテーブルの関連付けや解除を行えます（図2参照）。
図2 — FSx ルートテーブルの関連付け変更。
接続を有効にすると、ルートテーブル内に ENI のエントリが追加されていることが確認できます（図3参照）。この ENI ルートが、インスタンスから FSx ファイルシステムへ到達する経路となります。エントリは、エンドポイント IP アドレスと、現在アクティブなファイルシステムの ENI で構成されています。
図3 — 関連付けられたルートテーブル内の ENI エントリ。
この構成は、フェイルオーバー手順を成立させるために必要なものです。Single-AZ（HA）と同様にエンドポイント IP アドレスを使いますが、AZ が異なる ENI 間ではこの IP アドレスを移動できません。加えて、Single-AZ（HA）ではエンドポイント IP アドレスが既存サブネット内に作成されますが、Multi-AZ デプロイメントではそうではありません。
Multi-AZ のセットアップ
FSx を Multi-AZ モードでセットアップすると、冗長性確保のため、異なる AZ にある2つのサブネットにそれぞれ別のファイルシステムが作成されます。各ファイルシステムは独自の Elastic Network Interface（ENI）を持ちます。セットアップ時、FSx はフェイルオーバー用の特別な IP アドレス（「フローティング」IP）を必要とします。この IP アドレスは単一アドレス（/32）です。
「EndpointIpAddressRange」パラメータで IP アドレス範囲を自身で指定することも、未使用の /28 CIDR 範囲を VPC から FSx に自動選択させることも可能です。
このフローティング IP には重要なポイントがあります。VPC の IP 範囲内には存在しますが、意図的に既存のどのサブネット範囲にも属さないように配置されているのです。つまり Amazon EC2 のネットワーキングの観点からは、この IP アドレスは特定のネットワーキングリソースやサブネットには紐付いていません。
ファイルシステムとその ENI はサブネット内にありますが、エンドポイント IP アドレス、すなわちフローティング IP は VPC 内のどのサブネット CIDR にも含まれていません。フローティング IP 宛てのトラフィックを、現在アクティブなファイルシステムの正しい ENI にルーティングするには、ルートテーブルのエントリが必要です。このルートがなければ、フローティング IP はどのサブネットにも属していないため、トラフィックは破棄されてしまいます（図4参照）。
このような構成になっている理由は、NFS クライアントのフェイルオーバー上の制約により、FSx が DNS ベースのフェイルオーバーを行えないためです。DNS ルックアップはマウント時に一度しか実行されません。そのため FSx は、RDS のような他の AWS Multi-AZ サービスで一般的に採用されている方式とは異なるフェイルオーバーの仕組みを使う必要があります。そうしないと、ファイルシステムのフェイルオーバーが発生するたびに NFS クライアントが再マウントを行わなければならなくなるからです。
つまり、Multi-AZ のプライマリとスタンバイのファイルシステム間でシームレスなフェイルオーバーを実現するには、クライアントが配置されているサブネットのルートテーブルに ENI エントリが必要だということです。ファイルシステムのフェイルオーバーが発生すると、FSx は FSx に関連付けられた顧客側のルートテーブルをすべて更新し、フローティング IP（宛先）は変えずに、ターゲットだけをスタンバイ側ファイルシステムのものに切り替えます。
図4 — FSx セットアップ。
まとめ
本記事では、Amazon FSx for OpenZFS の実装方法、作成時のオプション、ネットワーキングの仕組み、そしてデプロイメントタイプごとに動作が異なる理由について解説しました。
FSx for OpenZFS を組織で活用する方法でお悩みですか？
OpenZFS の Multi-AZ セットアップに限らず、GCP や AWS のインフラソリューション全般を自社で成功させる方法でお悩みなら、ぜひご相談ください。
DoiT International のチームは、シニアレベルのエンジニアだけで構成されています。高度なクラウドコンサルティング、アーキテクチャ設計、デバッグ支援を専門としており、分散データベースの導入を検討中の方も、既存システムの最適化に取り組む方も、複雑な問題のトラブルシューティングを進める方も、ニーズに合わせた専門的なアドバイスをご提供します。
ぜひお問い合わせいただき、クラウドインフラの可能性を最大限に引き出しましょう。