概要
当エントリーでは、Nutanix Clusters on AWS (以後NCA)を構築するVPCのネットワークリソースの消費についてAWS視点で確認していきます。
NCAの場合、一般的なEC2インスタンスとは異なり、EC2ベアメタルインスタンスを利用してその中にVMが起動するような構成となる為、AWSインフラ視点だと少し特殊な環境と言えましょう。
以下blogにて構築後のリソースについて情報を残しましたが、Elastic Network Interface (以後ENI) がどうなっているのかよくわからない と疑問を感じた方もいらっしゃると思います。(私も執筆時よくわかっていませんでした)
当エントリーはネットワークに関する挙動についての足補という位置づけとなります。
- 概要
- NCAネットワーク構成
- NCA構築後に作成されるENIの確認
- (1) ベアメタルインスタンスにアタッチされているENI
- (2) Nutanix Cluster のネームタグが付与されている謎のENI
- (3) UVM起動時に作成されるENI
- ネットワークリソースと消費について整理して纏めると
- 3台構成の場合
- 最小ネットワーク構成について考える
- まとめ
- 関連エントリー
NCAネットワーク構成
今回は、ややこしさ防止の為に z1.metal * 1台構成で見ていきます。
My Nutanix経由で新規VPCから構築し、PublicからPrismアクセスを許可する構成です。 この場合は、Prism用の Network Load Balancer(以後NLB)が自動的に作成されます。
NCA構築後に作成されるENIの確認
今回の構成だと NCA 構築直後にはENIが4つあります。
※ PublicからPrismアクセスを許可しなければ NLBは作成されないので3つとなります
※ UVM用サブネットと関連付け作業後に更にENIが追加されていきます
[cloudshell-user@ip-10-0-63-159 tmp]$ aws ec2 describe-network-interfaces --query "NetworkInterfaces[].[InterfaceType,NetworkInterfaceId,PrivateIpAddress,Description]" --output text interface eni-0ccb048e9ce36ac02 10.0.128.156 nat_gateway eni-068ef4febb0de70fc 10.0.129.148 Interface for NAT Gateway nat-0693de39ed6850cf4 network_load_balancer eni-0d83dfff2ad84151f 10.0.129.79 ELB net/Nutanix-Cluster-7105F40C3670/d736a186936e72c2 interface eni-038d8ad8a7b2a37cc 10.0.128.99
NAT Gateway用とNLB用のENIは、AWSインフラの視点ではごく一般的なものなので今回は割愛し、それ以外の以下2つのENIについて詳細を見ていきます。
- (1) interface eni-0ccb048e9ce36ac02 10.0.128.156
- (2) interface eni-038d8ad8a7b2a37cc 10.0.128.99
(1) ベアメタルインスタンスにアタッチされているENI
interface eni-0ccb048e9ce36ac02 10.0.128.156 は
ベアメタルインスタンスに、ネームタグが付与されていないENIとしてアタッチされています。
表向きは、Management Subnet の 10.0.128.0/24 内から おそらくランダムで割り当てられた.156 が付与されていますが、更にセカンダリとして同セグ内として4つ付与されている事が判ります。
セカンダリとしては3つが割り当てられ、Prism内の画面では利用用途を確認する事が出来ます。
※逆にAWSからは用途までを確認する事は出来ません = 意識しなくても良い内容とも言えます
- Virtual IPaddress : 10.0.128.22
- iSCSI Data Services IPaddress : 10.0.128.9
- Configure CVM ntnx-i-0d83024ef9cbb3057-a-cvm : 10.0.128.234
[cloudshell-user@ip-10-0-63-159 tmp]$ aws ec2 describe-network-interfaces --network-interface-ids eni-0ccb048e9ce36ac02 { "NetworkInterfaces": [ { "Attachment": { "AttachTime": "2021-10-26T02:21:03+00:00", "AttachmentId": "eni-attach-0bf31e3d397219fcf", "DeleteOnTermination": true, "DeviceIndex": 0, "NetworkCardIndex": 0, "InstanceId": "i-0d83024ef9cbb3057", "InstanceOwnerId": "XXXXXXXXXXXX", "Status": "attached" }, "AvailabilityZone": "ap-northeast-1a", "Description": "", "Groups": [ { "GroupName": "Nutanix Cluster 7105F40C3670 Internal Management", "GroupId": "sg-02f67034a52e357ca" }, { "GroupName": "Nutanix Cluster 7105F40C3670 User Management", "GroupId": "sg-0bdd4707637d6f114" } ], "InterfaceType": "interface", "Ipv6Addresses": [], "MacAddress": "06:37:24:17:69:81", "NetworkInterfaceId": "eni-0ccb048e9ce36ac02", "OwnerId": "XXXXXXXXXXXXX", "PrivateDnsName": "ip-10-0-128-156.ap-northeast-1.compute.internal", "PrivateIpAddress": "10.0.128.156", "PrivateIpAddresses": [ { "Primary": true, "PrivateDnsName": "ip-10-0-128-156.ap-northeast-1.compute.internal", "PrivateIpAddress": "10.0.128.156" }, { "Primary": false, "PrivateDnsName": "ip-10-0-128-234.ap-northeast-1.compute.internal", "PrivateIpAddress": "10.0.128.234" }, { "Primary": false, "PrivateDnsName": "ip-10-0-128-22.ap-northeast-1.compute.internal", "PrivateIpAddress": "10.0.128.22" }, { "Primary": false, "PrivateDnsName": "ip-10-0-128-9.ap-northeast-1.compute.internal", "PrivateIpAddress": "10.0.128.9" } ], "RequesterManaged": false, "SourceDestCheck": false, "Status": "in-use", "SubnetId": "subnet-05f830856c41ea9a1", "TagSet": [], "VpcId": "vpc-037ff121309c28c43" } ] } [cloudshell-user@ip-10-0-63-159 tmp]$
(2) Nutanix Cluster のネームタグが付与されている謎のENI
interface eni-038d8ad8a7b2a37cc 10.0.128.99 にはNutanix Cluster XXXXXXXXXXXXXX といったネームタグが付与されているので、構築直後のNCAをAWSインフラ視点で眺めた際にはこちらのENIが最初に目に付くと思いますが、気になるのが、status: available である点です。
つまりはNutanixの利用するENIとして作成されているが、どのリソースにもアタッチされておらず利用していない状況です。
謎だったので (Nutanix Japan合同会社の方にご協力頂き) 当ENIについて確認をしたところ、将来の為の予約アドレスとして確保しているリソースであるという裏が取れました。
AWSのVPC予約アドレスと似たようなものと考えれば良さそうです。
ただしAWSのVPC予約アドレスとは異なり、ENIという実体を作成する事でIPアドレスを確保(予約)する特性がある事から、NCA構築後に status: available のENIがあっても混乱しないように管理者として意識しておきたいところです。
[cloudshell-user@ip-10-0-63-159 tmp]$ aws ec2 describe-network-interfaces --network-interface-ids eni-038d8ad8a7b2a37cc { "NetworkInterfaces": [ { "AvailabilityZone": "ap-northeast-1a", "Description": "", "Groups": [ { "GroupName": "default", "GroupId": "sg-0ec88f5b5f79a22c2" } ], "InterfaceType": "interface", "Ipv6Addresses": [], "MacAddress": "06:cf:5e:3e:ff:a1", "NetworkInterfaceId": "eni-038d8ad8a7b2a37cc", "OwnerId": "XXXXXXXXXXXXXX", "PrivateDnsName": "ip-10-0-128-99.ap-northeast-1.compute.internal", "PrivateIpAddress": "10.0.128.99", "PrivateIpAddresses": [ { "Primary": true, "PrivateDnsName": "ip-10-0-128-99.ap-northeast-1.compute.internal", "PrivateIpAddress": "10.0.128.99" } ], "RequesterId": "AROAYMK2PIVKKICERMPEU:AssumeRoleSession1635211798.5303185", "RequesterManaged": false, "SourceDestCheck": true, "Status": "available", "SubnetId": "subnet-05f830856c41ea9a1", "TagSet": [ { "Key": "Name", "Value": "Nutanix Cluster 7105F40C3670" }, { "Key": "nutanix:clusters:cluster-id", "Value": "63VYwPRqWOegOpQn" }, { "Key": "nutanix:clusters:owner", "Value": "nutanix-clusters" }, { "Key": "nutanix:clusters:gateway", "Value": "https://gateway-external-api.console.nutanix.com" }, { "Key": "nutanix:clusters:cluster-uuid", "Value": "0005cf38-07f9-6af4-8a2a-7105f40c3670" } ], "VpcId": "vpc-037ff121309c28c43" } ] } [cloudshell-user@ip-10-0-63-159 tmp]$
(3) UVM起動時に作成されるENI
初期構築時には存在しませんが、UVM用Subnetを作成しPrism内でネットワーク設定を実施して、VMを対象ネットワークに作成、電源をONとした際に、UVM用のENIが自動で作成されてベアメタルインスタンスにアタッチされます。
当作業の詳細は以下blog参照 blog.serverworks.co.jp
今回は、10.0.130.0/24 としてUVM用サブネットを作成し関連付けを行ったところ、 .4 (AWSのサブネットで利用可能な範囲の先頭を抑える挙動)として作成され、VMをDHCP有効 (AWSのDHCPサーバー参照設定) で2台構築したところ .236 と .19 とランダムで割り当てられました。
以下の通り、セカンダリとして関連付けされ、Prism内でVMを作成/削除を実施すると即関連付け設定が反映(同期)される挙動をします。
[cloudshell-user@ip-10-0-102-85 tmp]$ aws ec2 describe-network-interfaces --network-interface-ids eni-07665531e98171a4f { "NetworkInterfaces": [ { "Attachment": { "AttachTime": "2021-10-26T04:03:03+00:00", "AttachmentId": "eni-attach-0d58ab066a12a53e4", "DeleteOnTermination": true, "DeviceIndex": 1, "NetworkCardIndex": 0, "InstanceId": "i-0d83024ef9cbb3057", "InstanceOwnerId": "XXXXXXXXXXXXX", "Status": "attached" }, "AvailabilityZone": "ap-northeast-1a", "Description": "nutanix:clusters:instance-id=i-0d83024ef9cbb3057,nutanix:clusters:cnc=0005cf38-07f9-6af4-8a2a-7105f40c3670,br0.uvms", "Groups": [ { "GroupName": "Nutanix Cluster 7105F40C3670 UVM", "GroupId": "sg-0fe88ca7da26e5613" } ], "InterfaceType": "interface", "Ipv6Addresses": [], "MacAddress": "06:2f:6a:31:30:9b", "NetworkInterfaceId": "eni-07665531e98171a4f", "OwnerId": "XXXXXXXXXXX", "PrivateDnsName": "ip-10-0-130-4.ap-northeast-1.compute.internal", "PrivateIpAddress": "10.0.130.4", "PrivateIpAddresses": [ { "Primary": true, "PrivateDnsName": "ip-10-0-130-4.ap-northeast-1.compute.internal", "PrivateIpAddress": "10.0.130.4" }, { "Primary": false, "PrivateDnsName": "ip-10-0-130-236.ap-northeast-1.compute.internal", "PrivateIpAddress": "10.0.130.236" }, { "Primary": false, "PrivateDnsName": "ip-10-0-130-19.ap-northeast-1.compute.internal", "PrivateIpAddress": "10.0.130.19" } ], "RequesterId": "AROAYMK2PIVKKBJVOK4AA:i-0d83024ef9cbb3057", "RequesterManaged": false, "SourceDestCheck": true, "Status": "in-use", "SubnetId": "subnet-058ecbdd44281d251", "TagSet": [], "VpcId": "vpc-037ff121309c28c43" } ] } [cloudshell-user@ip-10-0-102-85 tmp]$
(参考) プライマリIPアドレスの用途
ENIの表向きであるプライマリIPアドレスの用途について Nutanixのドキュメントに以下記載があります。
プライマリIPアドレスは、AHVIPAMから割り当てる必要があります。ENIプライマリIPアドレスは、UVMで使用するvNICIPアドレスとして使用されることはありません。
この情報の通り、Nutanix側からENI作成した際に自動的に割り当てられたものであり、利用される事はないIPアドレスと理解して良さそうです。(ENIが存在する為に必要なものであると解釈して問題なし)
(参考) DHCPサーバーについて
NCAでは、デフォルトでAWSのDHCPサーバーを参照する設定が埋め込まれた状態で起動します。(VPCの先頭第4オクテット .2 が利用されます。ちなみにDNSも同様)
UVMs use only the DHCP servers provided by the cluster.
という注意点の記載があるのですが、上で紹介した動作(Nutanix側のVMのIPアドレス管理とENIのセカンダリIPアドレス割り当ての同期)をする必要があるからDHCPサーバーの参照先設定は、NCA構築後デフォルトで設定されているAWSのDHCPサーバーから変更しないでくださいね と解釈する事が出来ます。
こちらについては、AWSではなくNutanixインフラ側の担当者として意識したいところです。
ネットワークリソースと消費について整理して纏めると
以下のような図になりました。
- 朱書き: 消費するPrivate IP Addressの数
- オレンジ吹き出し: AWS API側で手動で作業する必要がある内容
- グレーアウト: 構成によっては存在しない任意の項目
(自分が理解するために書いたモノなので吹き出しだらけですみません)
(参考) MAX50である理由とENIの制限についてのおさらい
ネットワークインターフェイスあたりの IP アドレス数の上限は、インスタンスタイプによって異なります。
NCAが対応している EC2ベアメタルインスタンスとしては以下がハードリミットとなります。(全部同じようですが)
[cloudshell-user@ip-10-0-186-20 ~]$ aws ec2 describe-instance-types --filters "Name=instance-type,Values=i3.metal,z1d.metal,i3en.metal,m5d.metal" --query "InstanceTypes[].{Type: InstanceType, MaxENI: NetworkInfo.MaximumNetworkInterfaces, IPv4addr: NetworkInfo.Ipv4AddressesPerInterface}" --output table
--------------------------------------
| DescribeInstanceTypes |
+----------+----------+--------------+
| IPv4addr | MaxENI | Type |
+----------+----------+--------------+
| 50 | 15 | m5d.metal |
| 50 | 15 | z1d.metal |
| 50 | 15 | i3en.metal |
| 50 | 15 | i3.metal |
+----------+----------+--------------+
[cloudshell-user@ip-10-0-186-20 ~]$
つまりは、NCA1台構成の場合はVMが49台。
NCA3台構成の場合はVMが49*3=147台 が最大構成となりそうです。
この事から、UVM用サブネットは /24 で 良い というよりは、/24 が 良いと言えそうです。
3台構成の場合
以下のような消費イメージとなります。
(参考) 3台構成の時のUVM用 ENIの挙動について
少々マニアックな内容ですが、検証したところ
- VMの1台目を起動した際に、UVM用ENIの1つ目が
.4をプライマリとして作成され、VMのPrivate IPアドレスがセカンダリに付与 - VMの2台目を起動した際に、UVM用ENIの2つ目が
.5をプライマリとして作成され、VMのPrivate IPアドレスがセカンダリに付与 - VMの3台目を起動した際に、UVM用ENIの3つ目が
.6をプライマリとして作成され、VMのPrivate IPアドレスがセカンダリに付与
ENIの視点で分散配置される形となりました。
こちらの挙動から プライマリは UVM用サブネットの先頭から数値を押さえていく仕様のようです。
そして、その後の分散方式はラウンドロビンではなく、Least Connectionのようなざっくりイメージとなります。 (セカンダリに一番割り当て少ないENIへと優先的に割り当てられながら極力均等に分散させる挙動をします)
最小ネットワーク構成について考える
以上の事から、NCA用としてVPCを新規作成およびUVMサブネットを仮に2つ作成する場合は、VPCのネットワークCIDRとして/22 あれば問題ないと言えます。
(NCA以外で当該VPCを将来活用していく可能性がある場合はその限りではないですが)
NCAは、既存のオンプレミス環境のNutanix Clusterから延伸してハイブリットクラウドやDRの観点、AWSサービス活用の観点で導入を検討されるケースが多い事から、環境の規模からしてPrivateネットワークにそこまで余裕がないケースもあるかと思います。
NCA専用としてVPCを利用する場合は、My Nutanix経由で構築時にデフォルトで埋め込まれる 10.0.0.0/16 では広大な無駄を発生させてしまいます。
オンプレミス環境で利用しているものとのバッティングに注意するだけでなく、ネットワークリソース的に無駄のない設計にしたいものです。
ただしサブネットに関しては、新規VPCを指定して NCAを構築する場合は、暗黙で全て /24 で払い出されますので、特殊な要件がある場合を除き、手動で作成する場合も /24 で統一するのが無難かつ人間の運用面でメリットがあると言えます。
まとめ
NCAがAWS側のネットワークリソースをどのように消費するかについて確認しながら情報を整理してみました。
NCAはVPCのネットワークCIDRを指定するだけで簡単に構築出来て"いい感じに"動いてくれるものですが、AWSインフラ視点でENIの用途やらネットワークリソース消費の挙動について把握しておく事で、いざトラブルシューティングで役に立つ場合もあるかと思います。
