この記事は、以下のAWSブログを読んで、内容を自分なりに咀嚼したものです。
自分用の学習のメモ的な側面が強く、ONTAP に精通しているわけでもないので、不正確な部分があるかもしれません。
なお、上記日本語版ブログは2022/12/17公開ですが、英語版は12/9です。
ちなみにNLB経由でONTAPにアクセスするブログをAWSの前にクラスメソッドさんが2022/6/1に公開されていました（すごい）。
ONTAP のデプロイタイプについて
はじめに、ONTAP のデプロイタイプにはシングルAZとマルチAZがあり、AWSブログではデプロイタイプがマルチAZの場合の話です。
なお、ONTAPは当初マルチAZのデプロイタイプしかありませんでしたが、2022年4月からデプロイタイプにシングルAZが追加されたという経緯があります。
Amazon FSx for NetApp ONTAP は、シングルアベイラビリティーゾーン (AZ) デプロイをサポートするようになりました。シングル AZ ファイルシステムは、マルチ AZ ファイルシステムのデータ回復モデルを必要としないユースケース向けに設計されています (開発とテストのワークロードの実行、オンプレミスや他の AWS リージョンに既に保存されているデータのセカンダリコピーの保存など)。シングル AZ ファイルシステムは、これらのユースケースでマルチ AZ ファイルシステムよりも低コストのストレージオプションを提供すると同時に、すべてのデータ管理機能を同じように提供します。
https://aws.amazon.com/jp/about-aws/whats-new/2022/04/amazon-fsx-netapp-ontap-single-availability-zone-deployment/
上記引用の通り、シングルAZは本番稼働ワークロードでの利用には推奨されていません。
検証の際にマルチAZでデプロイすると時間がかかるため、シングルAZでデプロイすると時間が短縮できます。
クラスメソッドさんのブログだとマルチAZは45分、シングルAZは25分程度かかるようです。
NLBからONTAPにルーティングする理由
オンプレからマルチAZデプロイタイプの ONTAP にアクセスするには、Transit Gateway が必要となりますが、NLB を利用することでTransit Gateway なしでONTAPにアクセスできるためです。
マルチAZデプロイオプションの場合、ファイルシステムは異なるAZの 2 つのサブネットに跨り、NFS、SMB、管理に使用されるプライベートIPアドレス範囲（以後、「フローティングIPアドレス」と言います。）が存在します。
フローティングIPアドレスは特定のサブネットとは関連づけられておらず、ファイルシステムに関連づけられた VPC ルートテーブルで、「フローティングIPアドレス -> アクティブなファイルサーバーのENI」 にルーティングされるようになっており、この仕組みのおかげでフェイルオーバーを実現できています。
ファイルシステムが存在する VPC の外側からフローティングIPアドレスにアクセスするには、Transit Gateway を利用する必要があります（シングルAZの場合はTransit Gatewayは必要ありません）。
シングル AZ ファイルシステムの場合、NFS または SMB 経由の FSx for ONTAP へのアクセス、または ONTAP CLI または REST API を使用したファイルシステムの管理に使用されるエンドポイントは、アクティブなファイルサーバーの ENI 上のセカンダリ IP アドレスです。セカンダリ IP アドレスは VPC の CIDR 範囲内にあるため AWS Transit Gateway を必要とせず、VPC ピアリング、Direct Connect、VPN を使用してデータにアクセスできます。
https://docs.aws.amazon.com/ja_jp/fsx/latest/ONTAPGuide/access-environments.html
なお、Transit Gateway では、フローティングIPアドレス宛のトラフィックを、ファイルシステムのVPCにルーティングするルートを作成します。
上記により、オンプレからのフローティング IP アドレス宛のトラフィックが、「オンプレ -> Transit Gateway -> ファイルシステムのVPC -> アクティブなファイルシステムのENI」 とルートができるため、ONTAP にアクセスできます。
Transit Gatewayを利用していないユーザーのために、NLBを利用して ONTAP にアクセスする方法を、AWSブログで説明しています。
ファイルシステムの注意点
ファイルシステムを作成する際は、エンドポイントのIPアドレスを、NLB内部操作用に予約されているデフォルトの198.19.x.xのエンドポイントIPアドレスの範囲外から選択する必要があります。
NLB作成手順
- リソースID収集
- NLBターゲットグループ作成
- 「登録解除時における接続終了」の設定
- NLBの作成
- NLBを使用したデータアクセスの検証
リソースID収集
- ONTAPのファイルシステムから、利用しているVPC ID
- NLBを作成するVPCに設定
- 優先サブネットのENIのセキュリティグループID
- NLB作成予定のサブネットCIDRのNFS、SMBのインバウンドトラフィックが許可されているか確認
- ストレージ管理マシン（SVM）のエンドポイントの管理IPアドレス
- NLBのターゲットグループのターゲットに指定
NLBターゲットグループ作成
ターゲットグループは、1 つ、または複数の登録されたターゲットにリクエストをルーティングします。
以下のポート・プロトコルごとにターゲットグループを作成します（合計 3 つ。AWSブログ内の画像を見ると他のプロトコル・ポートも追加しているようなので、場合によっては以下以外のターゲットグループも必要かもしれません。）。
- ポート2049 TCP・UDP（NFS v4, NFS v3）
- ポート111 TCP・UDP（RPC（NFS v3））
- ポート 445 TCP（SMB）
NLB をデプロイするVPCにはONTAPのファイルシステムが存在するVPCを選択し、ターゲットタイプにはIPを選択します。
ターゲットの種類が
ipの場合、次のいずれかの CIDR ブロックから IP アドレスを指定できます。https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/network/load-balancer-target-groups.html#target-type
- ターゲットグループの VPC のサブネット
- 10.0.0.0/8 (RFC 1918)
- 100.64.0.0/10 (RFC 6598)
- 172.16.0.0/12 (RFC 1918)
- 192.168.0.0/16 (RFC 1918)
ターゲットの登録では、ネットワークで「その他のプライベートIPアドレス」を選択してアベイラビリティーゾーンに「すべて」を選択し、SVMの管理IPアドレスを指定します。
「登録解除時における接続終了」の設定
ターゲットグループの設定で、「登録解除時における接続終了」が有効化されていることを確認します。
NLBの作成
スキームを「内部」、IP アドレスタイプを IPv4 に、マッピングではファイルシステムの優先サブネットとスタンバイサブネットを選択します。
リスナーとルーティングを、ターゲットグループごとに作成します。
NLBを使用したデータアクセスの検証
NLB の DNS に任意のクライアントから nslookup などを実行し、解決することを確認します。
確認できたら、最後に NLB の DNS 名を使用して、NFSまたはSMB経由でボリュームをマウントできることを確認して終了です。
注意点
NLB を利用している分、コストがかかりますのでご注意ください。
NLBのアラームについて
AWS ブログでは、以下のメトリクスが紹介されていました。
- HealthyHostCount
- 正常とみなされるターゲットの数
- UnHealthyHostCount
- 異常とみなされるターゲットの数
- ActiveFlowCount
- クライアントからターゲットへの同時フロー（接続）総数
- SYN_SENTとESTABLISHED状態の接続が含まれる
おわりに
以上でAWSブログを自分なりに咀嚼した本記事は終了です。
NLBからONTAPファイルシステムへのルーティングの方法は、ONTAPに限らず他の構成でも利用できそうなので勉強になりました。
