Resource型VPCエンドポイント経由でMulti-AZのAmazon FSx for NetApp ONTAPファイルシステムに接続してみた
Multi-AZ Amazon FSx for NetApp ONTAPを使いたいがTransit VIF用意できない問題、終結説
2024.12.18Multi-AZファイルシステムを作成したいけどTransit Gateway用意できない
こんにちは、のんピ(@non____97)です。
皆さんはMulti-AZ Amazon FSx for NetApp ONTAP(以降、FSxN)ファイルシステムにTransit Gatewayを使わずにアクセスしたいと思ったことはありますか? 私はあります。
VPC外からMulti-AZのFSxNファイルシステムにSMBやNFSで接続する際はTransit Gatewayが必要です。Transit Gatewayが必要な理由は以下記事をご覧ください。
回避策として、以前は上述の記事で紹介しているようにNLBを介して接続する方法を取ることができました。
しかし、FSxNファイルシステムにてエンドポイントIPアドレスにVPCのCIDR範囲内のIPアドレスを指定する場合はNLBで接続する方式が使えません。実際の検証の様子は以下記事をご覧ください。
エンドポイントIPアドレスにVPCのCIDR範囲内のIPアドレスを指定するのはFSxNファイルシステムの推奨です。これによってルーティングがシンプルになります。
つまりはFSxNの推奨構成を取ろうとするとTransit Gatewayを使わざるを得ません。
Direct Connect経由でTransit Gatewayに接続する場合は、Transit VIFが必要になります。
ただし、さまざまな理由でTransit VIFを用意することが難しい場合もあります。
re:Invent 2024のアップデートによって、NLBを用意せずにVPC上のリソースに接続できる、Resource型VPCエンドポイントが登場しました。
Resource型VPCエンドポイントのターゲットとしてFSxNのエンドポイントIPアドレスを指定することで、Transit Gatewayを介さずに接続できるようになるのではないでしょうか。
実際に試してみました。
いきなりまとめ
- Resource型VPCエンドポイント経由でMulti-AZのAmazon FSx for NetApp ONTAPファイルシステムに接続できる
- SSH
- SMB 3.1
- SPNを設定すればKerberos認証も可能
- SPNの設定をしない場合はNTLMv2認証となる
- fsxadminでSSH接続する際には管理IPアドレスではなく、クラスター間エンドポイントIPアドレスに対しての接続で代替可能
- FSxNファイルシステムの管理IPアドレスへResource Configurationの設定をする必要性は薄い
- Resource型VPCエンドポイントを作成するタイミングで、Resource GatewayのENIが作成される
- Resource Gateway作成時に指定したサブネットに十分な空きIPアドレスがなければ、Resource型VPCエンドポイントの作成に失敗する
- 具体的にどのぐらい空きがあれば作成できるかは不明
- 検証した限り250個の空きでは失敗し、1,019個の空きでは成功する
- 実際に消費するIPアドレスは各サブネットごと17個
- Resource型VPCエンドポイントを介して接続する際、接続先からはResource GatewayのENIに設定されている
Ipv4Prefixに内のIPアドレスが送信元IPアドレスと見える - Resource型VPCエンドポイントのDNS名はパブリックDNSゾーンで管理されているため、VPC外からでも名前解決可能
- Resource型VPCエンドポイントのDNS名を名前解決した結果は複数値回答ではなく、Resource型VPCエンドポイントのいずれかのIPアドレスを1つ回答する
- 個人的に気になるポイントは以下
- Resource型VPCエンドポイントのアイドルタイムアウト
- Resource型VPCエンドポイントの同時接続数
- 何かしらの障害で片方のResource GatewayのENIもしくはResource型VPCエンドポイントのENIがダウンした場合は、ActiveのENIのIPアドレスのみ返却してくれるのか
やってみた
検証環境
検証環境は以下のとおりです。
2つのVPCを用意し、片方のVPCにはMulti-AZのFSxNファイルシステムとAD DC、もう片方のVPCにはSMBクライアントのEC2インスタンスを配置させます。
SMBクライアントのEC2インスタンスがドメイン参加できる必要はあるため、2つのVPCはVPCピアリングで接続しています。
FSxNファイルシステムおよび各EC2インスタンス、VPCピアリングまでは完了している状態です。
最終的なゴールはResource型VPCエンドポイントを介してSMBでファイル共有にアクセスできることです。
なお、今回はResource型VPCエンドポイントを使いましたが、Service Network型VPCエンドポイントやService Network型VPC Associationも選択肢に入ります。ただし、これらを使うのはService Networkを介して複数のVPCリソースを共有する場合になります。
VPCエンドポイントとリソースが1:1で十分であれば、Resource型VPCエンドポイントで良いでしょう。
また、コスト面も重要です。
Service Network型VPCエンドポイントやService Network型VPC Associationの場合はService Network型の場合はService NetworkとVPCリソースを関連付けるのにコストがかかります。
具体的には東京リージョンの場合、Service Networkと接続しているVPCリソース1つあたり、0.14 USD/h の料金がかかります。
一方Resource型VPCエンドポイントの場合は、VPCエンドポイントの料金のみです。具体的には東京リージョンの場合、VPCエンドポイントあたり、0.028 USD/h の料金とデータ処理料金 0.01 USD/GB がかかります。
手軽に始めるならResource型VPCエンドポイントという訳です。
参考までにTransit Gatewayの料金は以下のとおりです。
| 項目 | 料金 |
|---|---|
| Transit Gateway attachmentごとの料金 | 0.07 USD/h |
| データ処理料金 | 0.02 USD/GB |
Transit Gatewayと比較してもResource型VPCエンドポイントの方が安いことが分かりますね。
疎通確認
まず、Resource型VPCエンドポイントがない状態で疎通確認をします。
接続先のIPアドレスはFSxNファイルシステムとSVMのそれぞれのIPアドレスです。
SMBクライアントのEC2インスタンスから書くIPアドレスへpingを叩いてみます。
# クラスター間エンドポイントIPアドレス
> ping 10.0.8.138 -n 4
Pinging 10.0.8.138 with 32 bytes of data:
Reply from 10.0.8.138: bytes=32 time<1ms TTL=64
Reply from 10.0.8.138: bytes=32 time<1ms TTL=64
Reply from 10.0.8.138: bytes=32 time=3ms TTL=64
Reply from 10.0.8.138: bytes=32 time<1ms TTL=64
Ping statistics for 10.0.8.138:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 3ms, Average = 0ms
# クラスター間エンドポイントIPアドレス
> ping 10.0.9.245 -n 4
Pinging 10.0.9.245 with 32 bytes of data:
Reply from 10.0.9.245: bytes=32 time=1ms TTL=64
Reply from 10.0.9.245: bytes=32 time<1ms TTL=64
Reply from 10.0.9.245: bytes=32 time=5ms TTL=64
Reply from 10.0.9.245: bytes=32 time=2ms TTL=64
Ping statistics for 10.0.9.245:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 5ms, Average = 2ms
# 管理エンドポイントIPアドレス
> ping 10.0.15.231 -n 4
Pinging 10.0.15.231 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 10.0.15.231:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
# iSCSI IPアドレス
> ping 10.0.8.5 -n 4
Pinging 10.0.8.5 with 32 bytes of data:
Reply from 10.0.8.5: bytes=32 time<1ms TTL=64
Reply from 10.0.8.5: bytes=32 time<1ms TTL=64
Reply from 10.0.8.5: bytes=32 time<1ms TTL=64
Reply from 10.0.8.5: bytes=32 time<1ms TTL=64
Ping statistics for 10.0.8.5:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
# iSCSI IPアドレス
> ping 10.0.9.214 -n 4
Pinging 10.0.9.214 with 32 bytes of data:
Reply from 10.0.9.214: bytes=32 time<1ms TTL=64
Reply from 10.0.9.214: bytes=32 time=1ms TTL=64
Reply from 10.0.9.214: bytes=32 time=1ms TTL=64
Reply from 10.0.9.214: bytes=32 time<1ms TTL=64
Ping statistics for 10.0.9.214:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 1ms, Average = 0ms
# SMB IPアドレス
> ping 10.0.15.239 -n 4
Pinging 10.0.15.239 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 10.0.15.239:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
管理エンドポイントIPアドレスとSMB IPアドレスについては疎通できないことが分かります。
これらのIPアドレスは「エンドポイントIPアドレス範囲」の10.0.15.192/26から払い出されたIPアドレスであり、VPCピアリングを介した場合はルーティングすることができないためです。
クラスター間エンドポイントIPアドレスにSSH接続できることを確認
クラスター間エンドポイントIPアドレスにSSHできることを確認します。
> ssh fsxadmin@10.0.8.138
(fsxadmin@10.0.8.138) Password:
This is your first recorded login.
Unsuccessful login attempts since last login: 4
Your privilege has changed since last login.
FsxId07f1088148f103e3a::> whoami
(security login whoami)
User: fsxadmin
Role: fsxadmin
::> network interface show
Logical Status Network Current Current Is
Vserver Interface Admin/Oper Address/Mask Node Port Home
----------- ---------- ---------- ------------------ ------------- ------- ----
FsxId07f1088148f103e3a
fsxadmin up/up 10.0.15.231/26 FsxId07f1088148f103e3a-01
e0e true
inter_1 up/up 10.0.8.138/24 FsxId07f1088148f103e3a-01
e0e true
inter_2 up/up 10.0.9.245/24 FsxId07f1088148f103e3a-02
e0e true
non-97-svm
iscsi_1 up/up 10.0.8.5/24 FsxId07f1088148f103e3a-01
e0e true
iscsi_2 up/up 10.0.9.214/24 FsxId07f1088148f103e3a-02
e0e true
nfs_smb_management_1
up/up 10.0.15.239/26 FsxId07f1088148f103e3a-01
e0e true
6 entries were displayed.
問題なく接続できました。
fsxadminでSSH接続する際には管理IPアドレスではなく、クラスター間エンドポイントIPアドレスに対しての接続で代替可能です。
そのため、FSxNファイルシステムの管理IPアドレスをターゲットにしたResource型VPCエンドポイントは作成しなくとも運用上問題ないと考えます。
メンテナンス時はもう片方のクラスター間エンドポイントIPアドレスを指定して接続しましょう。
SMBファイル共有の作成
以降のテストをするためにSMBファイル共有を作成します。
SMBサーバーがドメイン参加していることを確認します。
::> cifs show
Server Status Domain/Workgroup Authentication
Vserver Name Admin Name Style
----------- --------------- --------- ---------------- --------------
non-97-svm NON-97-SVM up CORP domain
::> cifs share show
Vserver Share Path Properties Comment ACL
-------------- ------------- ----------------- ---------- -------- -----------
non-97-svm c$ / oplocks - BUILTIN\Administrators / Full Control
browsable
changenotify
show-previous-versions
non-97-svm ipc$ / browsable - -
2 entries were displayed.
/vol_testをパスとするSMBファイル共有を作成します。
::> volume show
Vserver Volume Aggregate State Type Size Available Used%
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
non-97-svm
non_97_svm_root
aggr1 online RW 1GB 972.3MB 0%
non-97-svm
vol_test aggr1 online RW 128TB 860.5GB 0%
2 entries were displayed.
::> cifs share create -share-name vol-test-share -path /vol_test
FsxId07f1088148f103e3a::> cifs share show
Vserver Share Path Properties Comment ACL
-------------- ------------- ----------------- ---------- -------- -----------
non-97-svm c$ / oplocks - BUILTIN\Administrators / Full Control
browsable
changenotify
show-previous-versions
non-97-svm ipc$ / browsable - -
non-97-svm vol-test- /vol_test oplocks - Everyone / Full Control
share browsable
changenotify
show-previous-versions
3 entries were displayed.
SMBサーバーのNetBIOS名を指定してSMBのマウントができないことを確認
SMBサーバーのNetBIOS名を指定してSMBのマウントができないことを確認します。
> New-PSDrive -Name "Z" -PSProvider FileSystem -Root "\\NON-97-SVM.CORP.NON-97.NET\vol-test-share" -Persist
New-PSDrive : The network path was not found
At line:1 char:1
+ New-PSDrive -Name "Z" -PSProvider FileSystem -Root "\\NON-97-SVM.CORP ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (Z:PSDriveInfo) [New-PSDrive], Win32Exception
+ FullyQualifiedErrorId : CouldNotMapNetworkDrive,Microsoft.PowerShell.Commands.NewPSDriveCommand
はい、できませんでした。
エクスプローラでもThe network path was not foundと同様にエラーになります。
ちなみに名前解決はできており、SMB IPアドレスが返ってきます。
> nslookup NON-97-SVM.CORP.NON-97.NET
Server: ip-10-0-0-139.ec2.internal
Address: 10.0.0.139
Name: NON-97-SVM.CORP.NON-97.NET
Address: 10.0.15.239
Resource Gatewayの作成
Resource型VPCエンドポイントを作成するために、Resource Gatewayを用意します。
> aws vpc-lattice create-resource-gateway \
--name non-97-rgw \
--vpc-identifier vpc-043c0858ea33e8ec2 \
--subnet-ids subnet-0ddc1cafa116ba0dd subnet-062714f49313a0ea5 \
--security-group-ids sg-03730d9e2b49e7cbc \
--ip-address-typ IPV4
{
"arn": "arn:aws:vpc-lattice:us-east-1:<AWSアカウントID>:resourcegateway/rgw-0f84e11568c258a2b",
"id": "rgw-0f84e11568c258a2b",
"ipAddressType": "IPV4",
"name": "non-97-rgw",
"securityGroupIds": [
"sg-03730d9e2b49e7cbc"
],
"status": "ACTIVE",
"subnetIds": [
"subnet-0ddc1cafa116ba0dd",
"subnet-062714f49313a0ea5"
],
"vpcIdentifier": "vpc-043c0858ea33e8ec2"
}
サブネットにはFSxNファイルシステムがあるサブネットを指定し、セキュリティグループはFSxNファイルシステムのクライアントが共通的に使用しているものを指定しました。
Resource Configurationの作成
続いて、Resource Configurationを作成します。
> aws vpc-lattice create-resource-configuration \
--name non-97-rcfg-svm \
--allow-association-to-shareable-service-network \
--port-ranges 22 445 2049 \
--protocol TCP \
--type SINGLE \
--resource-configuration-definition ipResource={ipAddress='10.0.15.239'} \
--resource-gateway-identifier rgw-0f84e11568c258a2b
{
"allowAssociationToShareableServiceNetwork": true,
"arn": "arn:aws:vpc-lattice:us-east-1:<AWSアカウントID>:resourceconfiguration/rcfg-09d0bae5a13d2560d",
"id": "rcfg-09d0bae5a13d2560d",
"name": "non-97-rcfg-svm",
"portRanges": [
"22",
"445"
"2049"
],
"protocol": "TCP",
"resourceConfigurationDefinition": {
"ipResource": {
"ipAddress": "10.0.15.239"
}
},
"resourceGatewayId": "rgw-0f84e11568c258a2b",
"status": "ACTIVE",
"type": "SINGLE"
}
IPアドレスはSVMのSMB IPアドレスです。ポートはTCP/22とTCP/445、TCP/2049です。TCP/2049はNFSで使用するポートで勢い余ってつけました。本検証では本来不要です。
Resource型VPCエンドポイントの作成
Resource型VPCエンドポイントを作成します。
> aws ec2 create-vpc-endpoint \
--vpc-endpoint-type Resource \
--resource-configuration-arn arn:aws:vpc-lattice:us-east-1:<AWSアカウントID>:resourceconfiguration/rcfg-09d0bae5a13d2560d \
--vpc-id vpc-0764d7f66aa8fa58a \
--subnet-ids subnet-0493d3cebba9cc691 subnet-0bcd0a0fb136048db \
--security-group-ids sg-0414e809a306108ed \
--private-dns-enabled
{
"VpcEndpoint": {
"VpcEndpointId": "vpce-0e1cbdf9522e6fb17",
"VpcEndpointType": "Resource",
"VpcId": "vpc-0764d7f66aa8fa58a",
"State": "Pending",
"SubnetIds": [
"subnet-0493d3cebba9cc691",
"subnet-0bcd0a0fb136048db"
],
"Groups": [
{
"GroupId": "sg-0414e809a306108ed",
"GroupName": "default"
}
],
"IpAddressType": "IPV4",
"PrivateDnsEnabled": true,
"CreationTimestamp": "2024-12-18T00:42:07.250000+00:00",
"Tags": [],
"OwnerId": "<AWSアカウントID>",
"ResourceConfigurationArn": "arn:aws:vpc-lattice:us-east-1:<AWSアカウントID>:resourceconfiguration/rcfg-09d0bae5a13d2560d"
}
}
> aws ec2 describe-vpc-endpoints --vpc-endpoint-ids vpce-0d12f9b5ec80510a0
{
"VpcEndpoints": [
{
"VpcEndpointId": "vpce-0e1cbdf9522e6fb17",
"VpcEndpointType": "Resource",
"VpcId": "vpc-0764d7f66aa8fa58a",
"State": "Failed",
"SubnetIds": [
"subnet-0493d3cebba9cc691",
"subnet-0bcd0a0fb136048db"
],
"Groups": [
{
"GroupId": "sg-0414e809a306108ed",
"GroupName": "default"
}
],
"IpAddressType": "IPV4",
"PrivateDnsEnabled": true,
"CreationTimestamp": "2024-12-18T00:42:07.250000+00:00",
"Tags": [],
"OwnerId": "<AWSアカウントID>",
"ResourceConfigurationArn": "arn:aws:vpc-lattice:us-east-1:<AWSアカウントID>:resourceconfiguration/rcfg-09d0bae5a13d2560d"
}
]
}
はい、Failedになりました。
AWSマネジメントコンソール上でも失敗とだけ表示されています。
CloudTrailのイベントを眺めていると、VPCエンドポイントを作成しようとしたタイミングでCreateNetworkInterfaceが失敗していました。
{
"eventVersion": "1.10",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROASTFXPUVSRGLKAAAZI:LatticeAssumeRoleSession",
"arn": "arn:aws:sts::<AWSアカウントID>:assumed-role/AWSServiceRoleForVpcLattice/LatticeAssumeRoleSession",
"accountId": "<AWSアカウントID>",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROASTFXPUVSRGLKAAAZI",
"arn": "arn:aws:iam::<AWSアカウントID>:role/aws-service-role/vpc-lattice.amazonaws.com/AWSServiceRoleForVpcLattice",
"accountId": "<AWSアカウントID>",
"userName": "AWSServiceRoleForVpcLattice"
},
"attributes": {
"creationDate": "2024-12-18T00:42:08Z",
"mfaAuthenticated": "false"
}
},
"invokedBy": "vpc-lattice.amazonaws.com"
},
"eventTime": "2024-12-18T00:42:08Z",
"eventSource": "ec2.amazonaws.com",
"eventName": "CreateNetworkInterface",
"awsRegion": "us-east-1",
"sourceIPAddress": "vpc-lattice.amazonaws.com",
"userAgent": "vpc-lattice.amazonaws.com",
"errorCode": "Client.InvalidParameterValue",
"errorMessage": "There aren't sufficient free Ipv4 addresses or prefixes",
"requestParameters": {
"subnetId": "subnet-0ddc1cafa116ba0dd",
"description": "Resource Gateway Interface rgw-0f84e11568c258a2b",
"groupSet": {
"items": [
{
"groupId": "sg-03730d9e2b49e7cbc"
}
]
},
"privateIpAddressesSet": {},
"ipv4PrefixCount": 1,
"tagSpecificationSet": {
"items": [
{
"resourceType": "network-interface",
"tags": [
{
"key": "VpcLatticeManaged",
"value": "true"
}
]
}
]
},
"clientToken": "fae4d8a0-1627-4e6d-b7ea-641b87fea102",
"denyAllIgwTraffic": true
},
"responseElements": null,
"requestID": "3c2258e2-cdb7-4099-923d-3204e347e51c",
"eventID": "2a05d6c2-14ef-49b6-9c78-37c18271ee33",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "<AWSアカウントID>",
"eventCategory": "Management"
}
There aren't sufficient free Ipv4 addresses or prefixesとなっていることから、どうやらResource GatewayのENIを作成しようとしたところ、subnet-0ddc1cafa116ba0ddの空きIPアドレスが無いとエラーになったようです。
本当にこのサブネットに十分な空きIPアドレスはないのでしょうか。
確認してみます。
> aws ec2 describe-subnets \
--subnet-ids subnet-0ddc1cafa116ba0dd \
--query 'Subnets[].AvailableIpAddressCount' \
--output text
212
212個も空きはあります。判定の仕方が謎ですね。
ちなみにVPCエンドポイントを作成しようとしたサブネットの空きIPアドレスも余裕十分です。
> aws ec2 describe-subnets \
--subnet-ids subnet-0493d3cebba9cc691 subnet-0bcd0a0fb136048db \
--query 'Subnets[].AvailableIpAddressCount'
[
250,
251
]
FSxNファイルシステムがあるサブネットに作成しようとしても同様のエラーで失敗となりました。
サブネットの追加とResource Gateway、Resource Configurationの再作成
Resource型VPCエンドポイントを作成する際にResource Gatewayで設定したサブネットに具体的にどのぐらいの空きIPアドレスが求められるのかは不明です。
とりあえず/22と大きめのサブネットを用意してあげて再チャレンジします。
> aws ec2 create-subnet \
--availability-zone us-east-1a \
--vpc-id vpc-043c0858ea33e8ec2 \
--cidr-block 10.0.4.0/22
{
"Subnet": {
"AvailabilityZoneId": "use1-az4",
"OwnerId": "<AWSアカウントID>",
"AssignIpv6AddressOnCreation": false,
"Ipv6CidrBlockAssociationSet": [],
"SubnetArn": "arn:aws:ec2:us-east-1:<AWSアカウントID>:subnet/subnet-029a939990627d570",
"EnableDns64": false,
"Ipv6Native": false,
"PrivateDnsNameOptionsOnLaunch": {
"HostnameType": "ip-name",
"EnableResourceNameDnsARecord": false,
"EnableResourceNameDnsAAAARecord": false
},
"SubnetId": "subnet-029a939990627d570",
"State": "available",
"VpcId": "vpc-043c0858ea33e8ec2",
"CidrBlock": "10.0.4.0/22",
"AvailableIpAddressCount": 1019,
"AvailabilityZone": "us-east-1a",
"DefaultForAz": false,
"MapPublicIpOnLaunch": false
}
}
> aws ec2 create-subnet \
--availability-zone us-east-1b \
--vpc-id vpc-043c0858ea33e8ec2 \
--cidr-block 10.0.12.0/22
{
"Subnet": {
"AvailabilityZoneId": "use1-az6",
"OwnerId": "<AWSアカウントID>",
"AssignIpv6AddressOnCreation": false,
"Ipv6CidrBlockAssociationSet": [],
"SubnetArn": "arn:aws:ec2:us-east-1:<AWSアカウントID>:subnet/subnet-01ca23340c422c467",
"EnableDns64": false,
"Ipv6Native": false,
"PrivateDnsNameOptionsOnLaunch": {
"HostnameType": "ip-name",
"EnableResourceNameDnsARecord": false,
"EnableResourceNameDnsAAAARecord": false
},
"SubnetId": "subnet-01ca23340c422c467",
"State": "available",
"VpcId": "vpc-043c0858ea33e8ec2",
"CidrBlock": "10.0.12.0/22",
"AvailableIpAddressCount": 1019,
"AvailabilityZone": "us-east-1b",
"DefaultForAz": false,
"MapPublicIpOnLaunch": false
}
}
/22なので、使用可能なIPアドレスは1019個あります。
これでエラーになると流石に困ります。
Resource Gatewayのサブネットを後から追加、変更することはできません。
新しくResource Gatewayを作成します。
> aws vpc-lattice create-resource-gateway \
--name non-97-rgw-retry \
--vpc-identifier vpc-043c0858ea33e8ec2 \
--subnet-ids subnet-029a939990627d570 subnet-01ca23340c422c467 \
--security-group-ids sg-03730d9e2b49e7cbc \
--ip-address-typ IPV4
{
"arn": "arn:aws:vpc-lattice:us-east-1:<AWSアカウントID>:resourcegateway/rgw-078bcf4c64e2fc005",
"id": "rgw-078bcf4c64e2fc005",
"ipAddressType": "IPV4",
"name": "non-97-rgw-retry",
"securityGroupIds": [
"sg-03730d9e2b49e7cbc"
],
"status": "ACTIVE",
"subnetIds": [
"subnet-029a939990627d570",
"subnet-01ca23340c422c467"
],
"vpcIdentifier": "vpc-043c0858ea33e8ec2"
}
同様にResource Configurationに紐づくResource Gatewayを変更することもできないので、Resource Configurationを再作成します。
> aws vpc-lattice create-resource-configuration \
--name non-97-rcfg-svm-retry \
--allow-association-to-shareable-service-network \
--port-ranges 22 445 2049 \
--protocol TCP \
--type SINGLE \
--resource-configuration-definition ipResource={ipAddress='10.0.15.239'} \
--resource-gateway-identifier rgw-078bcf4c64e2fc005
{
"allowAssociationToShareableServiceNetwork": true,
"arn": "arn:aws:vpc-lattice:us-east-1:<AWSアカウントID>:resourceconfiguration/rcfg-07e1be0ba948e9054",
"id": "rcfg-07e1be0ba948e9054",
"name": "non-97-rcfg-svm-retry",
"portRanges": [
"22",
"445",
"2049"
],
"protocol": "TCP",
"resourceConfigurationDefinition": {
"ipResource": {
"ipAddress": "10.0.15.239"
}
},
"resourceGatewayId": "rgw-078bcf4c64e2fc005",
"status": "ACTIVE",
"type": "SINGLE"
}
Resource型VPCエンドポイントの作成(リトライ)
下準備ができたのでResource型VPCエンドポイントの作成の再チャレンジです。
> aws ec2 create-vpc-endpoint \
--vpc-endpoint-type Resource \
--resource-configuration-arn arn:aws:vpc-lattice:us-east-1:<AWSアカウントID>:resourceconfiguration/rcfg-07e1be0ba948e9054 \
--vpc-id vpc-0764d7f66aa8fa58a \
--subnet-ids subnet-0493d3cebba9cc691 subnet-0bcd0a0fb136048db \
--security-group-ids sg-0414e809a306108ed \
--private-dns-enabled
{
"VpcEndpoint": {
"VpcEndpointId": "vpce-046678eea41db3874",
"VpcEndpointType": "Resource",
"VpcId": "vpc-0764d7f66aa8fa58a",
"State": "Pending",
"SubnetIds": [
"subnet-0493d3cebba9cc691",
"subnet-0bcd0a0fb136048db"
],
"Groups": [
{
"GroupId": "sg-0414e809a306108ed",
"GroupName": "default"
}
],
"IpAddressType": "IPV4",
"PrivateDnsEnabled": true,
"CreationTimestamp": "2024-12-18T01:05:30.379000+00:00",
"Tags": [],
"OwnerId": "<AWSアカウントID>",
"ResourceConfigurationArn": "arn:aws:vpc-lattice:us-east-1:<AWSアカウントID>:resourceconfiguration/rcfg-07e1be0ba948e9054"
}
}
> aws ec2 describe-vpc-endpoints --vpc-endpoint-ids vpce-046678eea41db3874
{
"VpcEndpoints": [
{
"VpcEndpointId": "vpce-046678eea41db3874",
"VpcEndpointType": "Resource",
"VpcId": "vpc-0764d7f66aa8fa58a",
"State": "Available",
"SubnetIds": [
"subnet-0493d3cebba9cc691",
"subnet-0bcd0a0fb136048db"
],
"Groups": [
{
"GroupId": "sg-0414e809a306108ed",
"GroupName": "default"
}
],
"IpAddressType": "IPV4",
"PrivateDnsEnabled": true,
"NetworkInterfaceIds": [
"eni-030b24f4caa0db830",
"eni-089bc0db66b7c46eb"
],
"CreationTimestamp": "2024-12-18T01:05:30.379000+00:00",
"Tags": [],
"OwnerId": "<AWSアカウントID>",
"ResourceConfigurationArn": "arn:aws:vpc-lattice:us-east-1:<AWSアカウントID>:resourceconfiguration/rcfg-07e1be0ba948e9054"
}
]
}
> aws ec2 describe-vpc-endpoint-associations --vpc-endpoint-ids vpce-046678eea41db3874
{
"VpcEndpointAssociations": [
{
"Id": "vpce-rsc-asc-07d8bb73f802a2dab",
"VpcEndpointId": "vpce-046678eea41db3874",
"AssociatedResourceAccessibility": "Accessible",
"DnsEntry": {
"DnsName": "vpce-046678eea41db3874.rcfg-07e1be0ba948e9054.4232ccc.vpc-lattice-rsc.us-east-1.on.aws",
"HostedZoneId": "Z08285483B41F6ASEM5U1"
},
"AssociatedResourceArn": "arn:aws:vpc-lattice:us-east-1:<AWSアカウントID>:resourceconfiguration/rcfg-07e1be0ba948e9054"
}
]
}
作成できました。
個人的には「作成できてしまいました」という感覚です。
マネジメントコンソールから確認した結果は以下のとおりです。
Resource Gatewayで指定したサブネットで使用可能なIPアドレスを確認すると、Resource型VPCエンドポイント1002個と17個ほど消費していました。
> aws ec2 describe-subnets \
--subnet-ids subnet-029a939990627d570 subnet-01ca23340c422c467 \
--query 'Subnets[].AvailableIpAddressCount'
[
1002,
1002
]
各サブネットでIPアドレスを17個消費するのであれば、212個空きがあったサブネットでも作成できて良いと思いますが謎です。
Resource型VPCエンドポイントの名前解決ができることを確認しましょう。
DNS名はパブリックなので、名前解決は手元の端末からでも可能です。
> dig vpce-046678eea41db3874.rcfg-07e1be0ba948e9054.4232ccc.vpc-lattice-rsc.us-east-1.on.aws @1.1.1.1 +short
10.1.1.197
> dig vpce-046678eea41db3874.rcfg-07e1be0ba948e9054.4232ccc.vpc-lattice-rsc.us-east-1.on.aws +short
10.1.1.197
> dig vpce-046678eea41db3874.rcfg-07e1be0ba948e9054.4232ccc.vpc-lattice-rsc.us-east-1.on.aws +short
10.1.0.156
> dig vpce-046678eea41db3874.rcfg-07e1be0ba948e9054.4232ccc.vpc-lattice-rsc.us-east-1.on.aws +short
10.1.1.197
複数値回答ではなく、Resource型VPCエンドポイントのいずれかのIPアドレスを1つ回答するようです。
検証はできないですが、何かしらの障害で片方のResource GatewayのENIもしくはResource型VPCエンドポイントのENIがダウンした場合は、ActiveのENIのIPアドレスのみ返却してくれるのでしょうか。
ターゲットをMulti-AZで動作させるのであれば気になるポイントです。
もちろん、SMBクライアントのEC2インスタンスからも名前解決できます。
> nslookup vpce-046678eea41db3874.rcfg-07e1be0ba948e9054.4232ccc.vpc-lattice-rsc.us-east-1.on.aws
Server: ip-10-0-0-139.ec2.internal
Address: 10.0.0.139
Non-authoritative answer:
Name: vpce-046678eea41db3874.rcfg-07e1be0ba948e9054.4232ccc.vpc-lattice-rsc.us-east-1.on.aws
Address: 10.1.0.156
Resource型VPCエンドポイント経由でSSHできるか確認
Resource型VPCエンドポイント経由でSSHできるか確認します。
> ssh vsadmin@vpce-046678eea41db3874.rcfg-07e1be0ba948e9054.4232ccc.vpc-lattice-rsc.us-east-1.on.aws
The authenticity of host 'vpce-046678eea41db3874.rcfg-07e1be0ba948e9054.4232ccc.vpc-lattice-rsc.us-east-1.on.aws (10.1.0.156)' can't be established.
ED25519 key fingerprint is SHA256:RcKHdxwGnufeafiwsy4lpwrBX698jdQpg2z/JFMrJ/M.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'vpce-046678eea41db3874.rcfg-07e1be0ba948e9054.4232ccc.vpc-lattice-rsc.us-east-1.on.aws' (ED25519) to the list of known hosts.
(vsadmin@vpce-046678eea41db3874.rcfg-07e1be0ba948e9054.4232ccc.vpc-lattice-rsc.us-east-1.on.aws) Password:
This is your first recorded login.
non-97-svm::> whoami
(security login whoami)
User: vsadmin
Role: vsadmin
non-97-svm::> cifs show
Server Status Domain/Workgroup Authentication
Vserver Name Admin Name Style
----------- --------------- --------- ---------------- --------------
non-97-svm NON-97-SVM up CORP domain
接続できました。いずれのサブネットに属していないフローティングIPアドレスでもルーティングできました。これは期待できます。
比較として、Resource型VPCエンドポイント経由ではなく、SVMの管理IPアドレスを直接指定してSSHしようとしてみます。
> ssh vsadmin@10.0.15.239 -v
OpenSSH_for_Windows_9.5p1, LibreSSL 3.8.2
debug1: Connecting to 10.0.15.239 [10.0.15.239] port 22.
debug1: connect to address 10.0.15.239 port 22: Connection timed out
ssh: connect to host 10.0.15.239 port 22: Connection timed out
はい、できませんでした。意図した挙動です。
Resource型VPCエンドポイント経由でSMBでアクセスできるか確認
Resource型VPCエンドポイント経由でSMBでアクセスできるか確認します。
> New-PSDrive -Name "Z" -PSProvider FileSystem -Root "\\vpce-046678eea41db3874.rcfg-07e1be0ba948e9054.4232ccc.vpc-lattice-rsc.us-east-1.on.aws\vol-test-share" -Persist
Name Used (GB) Free (GB) Provider Root CurrentLocation
---- --------- --------- -------- ---- ---------------
Z 123657.98 860.42 FileSystem \\vpce-046678eea41db3874.rcfg-07...
問題なくアクセスできました。
SMBファイル共有上で読み書きしてみましょう。
> echo test.txt > Z:\test.txt
> ls Z:\
Directory: Z:\
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 12/18/2024 1:23 AM 22 test.txt
> cat Z:\test.txt
test.txt
正常にできますね。
エクスプローラーからもSMBファイル共有にアクセスできました。
SMBセッションの確認をしましょう。
::> cifs session show
Node: FsxId07f1088148f103e3a-01
Vserver: non-97-svm
Connection Session Open Idle Connection
ID ID Workstation Windows User Files Time Count
---------- ------- ---------------- ---------------- --------- ------------ ---------------
303704740 5562508489755983875 46s 1
10.0.4.46 CORP\ 3
Administrator
non-97-svm::> cifs session show -instance
Vserver: non-97-svm
Node: FsxId07f1088148f103e3a-01
Session ID: 5562508489755983875
Connection ID: 303704740
Incoming Data LIF IP Address: 10.0.15.239
Workstation IP Address: 10.0.4.46
Authentication Mechanism: NTLMv2
User Authenticated as: domain-user
Windows User: CORP\Administrator
UNIX User: root
Open Shares: 1
Open Files: 3
Open Other: 0
Connected Time: 5m 41s
Idle Time: 52s
Protocol Version: SMB3_1
Continuously Available: No
Is Session Signed: false
NetBIOS Name: -
SMB Encryption Status: unencrypted
Large MTU Enabled: true
Connection Count: 1
Active Shares: vol-test-share
認証方式がKerberos認証ではなく、NTLMv2になっています。
これはアクセスする際に使用する名前vpce-046678eea41db3874.rcfg-07e1be0ba948e9054.4232ccc.vpc-lattice-rsc.us-east-1.on.awsに紐づくコンピューターオブジェクトが存在しないためです。
FSxNではデフォルトでKerberos認証を失敗するとNTLM認証にフォールバックします。詳細な挙動は以下記事をご覧ください。
DNS CNAMEレコードの設定
Kerberos認証したい場合は以下の2ステップが必要です。
- DNS CNAMEレコードの追加
- SPNの設定
まず、DNS CNAMEレコードの設定をします。
DNSサーバーを兼務しているAD DC上でNON-97-SVM*のDNSレコードを確認します。
> Get-DnsServerResourceRecord -ZoneName "corp.non-97.net" |
Where-Object {$_.HostName -like "NON-97-SVM*"} |
Format-List
DistinguishedName : DC=NON-97-SVM,DC=corp.non-97.net,cn=MicrosoftDNS,DC=DomainDnsZones,DC=corp,DC=non-97,DC=net
HostName : NON-97-SVM
RecordType : A
Type : 1
RecordClass : IN
TimeToLive : 1.00:00:00
Timestamp : 12/17/2024 5:00:00 AM
RecordData : 10.0.15.239
ホスト名がNON-97-SVM-ALIAS.corp.non-97.net、値がvpce-046678eea41db3874.rcfg-07e1be0ba948e9054.4232ccc.vpc-lattice-rsc.us-east-1.on.awsのCNAMEレコードを作成します。
これによってNON-97-SVM-ALIAS.corp.non-97.netでアクセスした時に、vpce-046678eea41db3874.rcfg-07e1be0ba948e9054.4232ccc.vpc-lattice-rsc.us-east-1.on.awsに紐づくIPアドレスでアクセスできます。
> $Alias = "NON-97-SVM-ALIAS.corp.non-97.net"
> $DnsName = "vpce-046678eea41db3874.rcfg-07e1be0ba948e9054.4232ccc.vpc-lattice-rsc.us-east-1.on.aws"
> $AliasHost = $Alias.Split('.')[0]
> $ZoneName = ((Get-WmiObject Win32_ComputerSystem).Domain)
> $DnsServerComputerName = (Resolve-DnsName $ZoneName -Type NS | Where Type -eq 'A' | Select -ExpandProperty Name) | Select -First 1
> Add-DnsServerResourceRecordCName -Name $AliasHost -ComputerName $DnsServerComputerName -HostNameAlias $DnsName -ZoneName $ZoneName
> Get-DnsServerResourceRecord -ZoneName "corp.non-97.net" |
Where-Object {$_.HostName -like "NON-97-SVM*"} |
Format-List
DistinguishedName : DC=NON-97-SVM,DC=corp.non-97.net,cn=MicrosoftDNS,DC=DomainDnsZones,DC=corp,DC=non-97,DC=net
HostName : NON-97-SVM
RecordType : A
Type : 1
RecordClass : IN
TimeToLive : 1.00:00:00
Timestamp : 12/17/2024 5:00:00 AM
RecordData : 10.0.15.239
DistinguishedName : DC=NON-97-SVM-ALIAS,DC=corp.non-97.net,cn=MicrosoftDNS,DC=DomainDnsZones,DC=corp,DC=non-97,DC=net
HostName : NON-97-SVM-ALIAS
RecordType : CNAME
Type : 5
RecordClass : IN
TimeToLive : 01:00:00
Timestamp : 0
RecordData : vpce-046678eea41db3874.rcfg-07e1be0ba948e9054.4232ccc.vpc-lattice-rsc.us-east-1.on.aws.
CNAMEレコード登録後、SMBクライアントのEC2インスタンスからNON-97-SVM-ALIAS.corp.non-97.netの名前解決できることを確認
> nslookup NON-97-SVM-ALIAS.corp.non-97.net
Server: ip-10-0-0-139.ec2.internal
Address: 10.0.0.139
Name: vpce-046678eea41db3874.rcfg-07e1be0ba948e9054.4232ccc.vpc-lattice-rsc.us-east-1.on.aws
Address: 10.1.0.156
Aliases: NON-97-SVM-ALIAS.corp.non-97.net
名前解決できました。
エクスプローラーから\\NON-97-SVM-ALIAS.corp.non-97.netへアクセスします。
その時のセッションは以下のとおりです。
::> cifs sessio show -instance
Vserver: non-97-svm
Node: FsxId07f1088148f103e3a-01
Session ID: 5562508489755983875
Connection ID: 303704740
Incoming Data LIF IP Address: 10.0.15.239
Workstation IP Address: 10.0.4.46
Authentication Mechanism: NTLMv2
User Authenticated as: domain-user
Windows User: CORP\Administrator
UNIX User: root
Open Shares: 1
Open Files: 1
Open Other: 0
Connected Time: 22m 50s
Idle Time: 1m 16s
Protocol Version: SMB3_1
Continuously Available: No
Is Session Signed: false
NetBIOS Name: -
SMB Encryption Status: unencrypted
Large MTU Enabled: true
Connection Count: 1
Active Shares: vol-test-share
Node: FsxId07f1088148f103e3a-01
Session ID: 5562508489755983878
Connection ID: 303704743
Incoming Data LIF IP Address: 10.0.15.239
Workstation IP Address: 10.0.4.37
Authentication Mechanism: NTLMv2
User Authenticated as: domain-user
Windows User: CORP\Administrator
UNIX User: root
Open Shares: 1
Open Files: 0
Open Other: 0
Connected Time: 2s
Idle Time: 2s
Protocol Version: SMB3_1
Continuously Available: No
Is Session Signed: false
NetBIOS Name: -
SMB Encryption Status: unencrypted
Large MTU Enabled: true
Connection Count: 1
Active Shares: ipc$
2 entries were displayed.
5562508489755983878というセッションがエクスプローラーでアクセスした時のセッションです。SPNの設定をしていないため、まだNTLMv2認証になっていますね。
また、このタイミングで気づいたのですが送信元IPアドレスが異なリます。
Resource GatewayのENIを確認すると、Ipv4Prefixに内のIPアドレスが割り振られていました。
> aws ec2 describe-network-interfaces --network-interface-ids eni-06c2d3e93eb1b8297
{
"NetworkInterfaces": [
{
"Attachment": {
"AttachmentId": "ela-attach-0ecdebdd906d3617e",
"DeleteOnTermination": false,
"DeviceIndex": 1,
"InstanceOwnerId": "amazon-aws",
"Status": "attached"
},
"AvailabilityZone": "us-east-1a",
"Description": "Resource Gateway Interface rgw-078bcf4c64e2fc005",
"Groups": [
{
"GroupId": "sg-03730d9e2b49e7cbc",
"GroupName": "non-97-client-sg"
}
],
"InterfaceType": "interface",
"Ipv6Addresses": [],
"MacAddress": "0a:ff:d1:9f:13:f5",
"NetworkInterfaceId": "eni-06c2d3e93eb1b8297",
"OwnerId": "<AWSアカウントID>",
"PrivateDnsName": "ip-10-0-6-79.ec2.internal",
"PrivateIpAddress": "10.0.6.79",
"PrivateIpAddresses": [
{
"Primary": true,
"PrivateDnsName": "ip-10-0-6-79.ec2.internal",
"PrivateIpAddress": "10.0.6.79"
}
],
"Ipv4Prefixes": [
{
"Ipv4Prefix": "10.0.4.32/28"
}
],
"Ipv6Prefixes": [],
"RequesterId": "396074869647",
"RequesterManaged": true,
"SourceDestCheck": true,
"Status": "in-use",
"SubnetId": "subnet-029a939990627d570",
"TagSet": [
{
"Key": "VpcLatticeManaged",
"Value": "true"
}
],
"VpcId": "vpc-043c0858ea33e8ec2",
"DenyAllIgwTraffic": true,
"Operator": {
"Managed": false
}
}
]
}
SPNの設定
SPNの設定をします。
まず、現在のSPN設定を確認します。
> SetSPN -T * -F -Q HOST/NON-97-SVM*
Checking forest DC=corp,DC=non-97,DC=net
CN=NON-97-SVM,OU=FSxForONTAP,DC=corp,DC=non-97,DC=net
cifs/non-97-svm.corp.non-97.net
HOST/non-97-svm.corp.non-97.net
HOST/NON-97-SVM
Existing SPN found!
NON-97-SVM-ALIAS.corp.non-97.netがNON-97-SVM.corp.non-97.netのエイリアスとなるようにSPNを設定します。
> $SmbServerDnsName = "NON-97-SVM.corp.non-97.net"
> $FileSystemHost = (Resolve-DnsName $SmbServerDnsName | Where Type -eq 'A')[0].Name.Split(".")[0]
> $FSxAdComputer = (Get-AdComputer -Identity $FileSystemHost)
> Set-AdComputer -Identity $FSxAdComputer -Add @{"msDS-AdditionalDnsHostname"="$Alias"}
> SetSPN -T * -F -Q HOST/NON-97-SVM*
Checking forest DC=corp,DC=non-97,DC=net
CN=NON-97-SVM,OU=FSxForONTAP,DC=corp,DC=non-97,DC=net
cifs/NON-97-SVM-ALIAS.corp.non-97.net
HOST/NON-97-SVM-ALIAS.corp.non-97.net
HOST/NON-97-SVM-ALIA
cifs/non-97-svm.corp.non-97.net
HOST/non-97-svm.corp.non-97.net
HOST/NON-97-SVM
Existing SPN found!
設定が完了しました。
エクスプローラーから\\NON-97-SVM-ALIAS.corp.non-97.netへアクセスした時のセッションの確認をします。
::> cifs session show -fields windows-user, address, auth-mechanism, shares, protocol-version
node vserver session-id connection-id address auth-mechanism windows-user shares protocol-version
------------------------- ---------- ------------------- ------------- --------- -------------- ------------------ ------ ----------------
FsxId07f1088148f103e3a-01 non-97-svm 5562508489755983875 303704740 10.0.4.46 NTLMv2 CORP\Administrator 1 SMB3_1
FsxId07f1088148f103e3a-01 non-97-svm 5562508489755983879 303704744 10.0.4.43 Kerberos CORP\Administrator 1 SMB3_1
2 entries were displayed.
5562508489755983879のセッションがKerberos認証となっていますね。
Yドライブとしてマウントしましょう。
> New-PSDrive -Name "Y" -PSProvider FileSystem -Root "\\NON-97-SVM-ALIAS.corp.non-97.net\vol-test-share" -Persist
Name Used (GB) Free (GB) Provider Root Curren
tLocat
ion
---- --------- --------- -------- ---- ------
Y 123657.99 860.41 FileSystem \\NON-97-SVM-ALIAS.corp.non-97.n...
> Get-PSDrive Z, Y
Name Used (GB) Free (GB) Provider Root Curren
tLocat
ion
---- --------- --------- -------- ---- ------
Z 123657.99 860.41 FileSystem \\vpce-046678eea41db3874.rcfg-07...
Y 123657.99 860.41 FileSystem \\NON-97-SVM-ALIAS.corp.non-97.n...
正常にマウントできました。
読み書きできるかも確認します。
> ls Y:\
Directory: Y:\
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 12/18/2024 1:23 AM 22 test.txt
> echo test2.txt > Y:\test2.txt
> ls Y:\
Directory: Y:\
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 12/18/2024 1:23 AM 22 test.txt
-a---- 12/18/2024 2:08 AM 24 test2.txt
> cat Y:\test2.txt
test2.txt
問題なくできていますね。
この時のSMBセッションは以下のとおりです。
::> cifs session show -fields windows-user, address, auth-mechanism, shares, protocol-version, connected-time, idle-time
node vserver session-id connection-id address auth-mechanism windows-user shares connected-time idle-time protocol-version
------------------------- ---------- ------------------- ------------- --------- -------------- ------------------ ------ -------------- --------- ----------------
FsxId07f1088148f103e3a-01 non-97-svm 5562508489755983875 303704740 10.0.4.46 NTLMv2 CORP\Administrator 1 51m 11s 4m 32s SMB3_1
FsxId07f1088148f103e3a-01 non-97-svm 5562508489755983880 303704745 10.0.4.39 Kerberos CORP\Administrator 1 6m 4s 4m 32s SMB3_1
2 entries were displayed.
確かにKerberos認証で接続できていますね。
ちなみにそのまま数時間待ちましたが、セッションは張られたままです。
::> cifs session show -fields windows-user, address, auth-mechanism, shares, protocol-version, connected-time, idle-time
node vserver session-id connection-id address auth-mechanism windows-user shares connected-time idle-time protocol-version
------------------------- ---------- ------------------- ------------- --------- -------------- ------------------ ------ -------------- --------- ----------------
FsxId07f1088148f103e3a-01 non-97-svm 5562508489755983875 303704740 10.0.4.46 NTLMv2 CORP\Administrator 1 3h 42m 16s 5m 31s SMB3_1
FsxId07f1088148f103e3a-01 non-97-svm 5562508489755983880 303704745 10.0.4.39 Kerberos CORP\Administrator 1 2h 57m 9s 5m 31s SMB3_1
2 entries were displayed.
「Resource型VPCエンドポイントを介してマウントした場合は、一定期間経過後に勝手にマウントが切れる」ということはなさそうです。
Multi-AZ Amazon FSx for NetApp ONTAPを使いたいがTransit VIF用意できない問題、終結説
Resource型VPCエンドポイント経由でMulti-AZのAmazon FSx for NetApp ONTAPファイルシステムに接続してみました。
問題なくSMBでアクセスし、読み書きできたことから、Multi-AZ Amazon FSx for NetApp ONTAPを使いたいがTransit VIF用意できない問題は終結説があります。
Transit VIFの用意が難しかった方には朗報だと思います。
また、今回のようにフローティングIPアドレスを使用するシステムには非常にありがたい機能です
個人的には気になるのは以下です。
- Resource型VPCエンドポイントのアイドルタイムアウト
- Resource型VPCエンドポイントの同時接続数
- 何かしらの障害で片方のResource GatewayのENIもしくはResource型VPCエンドポイントのENIがダウンした場合は、ActiveのENIのIPアドレスのみ返却してくれるのか
Resource型VPCエンドポイントのアイドルタイムアウトについてはAWS公式ドキュメントを確認しましたが、言及しているものは見つけられませんでした。
今回Resource型VPCエンドポイント経由でSSH接続をしている際に無操作が数分続くとclient_loop: send disconnect: Connection resetとSSHのセッションが切れていました。
手元で計測した限り7分無操作が続くとセッションが切れました。直接SSH接続している場合は数分程度の無操作ではセッションが切れなかったので何かしらのタイムアウトが設定されているのではないかと推測しています。
推測ではGateway Load Balancerと同じく350秒のアイドルタイムアウトが固定で設定されているのではと考えています。Keep-Aliveを組み込めないシステムの場合はもしかするとここがネックになるでしょう。
Resource型VPCエンドポイントの同時接続数についても、AWS公式ドキュメント上では言及ありませんでした。ファイルサーバー用途の場合、大量のクライアントのからのアクセスが予想されます。その時にResource Gatewayが大量の接続を捌くことができるのか気になります。
なお、Resource型VPCエンドポイントのスループットについては、以下のような記載があるため 100Gbps は出るのかなと思っています。
By default, each VPC endpoint can support a bandwidth of up to 10 Gbps per Availability Zone, and automatically scales up to 100 Gbps. The maximum bandwidth for a VPC endpoint, when distributing the load across all Availability Zones, is the number of Availability Zones multiplied by 100 Gbps. If your application needs higher throughput, contact AWS support.
この記事が誰かの助けになれば幸いです。
以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!
![[Amazon FSx for NetApp ONTAP] SMBでファイルオープン中にフェイルオーバーが発生した場合の挙動を確認してみた](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-9e9d102dfa6d7896319b16fe069cdf55/c3bbbeab42ba5764c5a573e979719805/amazon-fsx-for-netapp-ontap)
