Amazon FSx for NetApp ONTAPにClient VPN経由でSMB接続してみた
2025.03.14リモートからでもファイルサーバーに接続したい
こんにちは、のんピ(@non____97)です。
皆さんはリモートからでもファイルサーバーに接続したいなと思ったことはありますか? 私はあります。
オンプレミス拠点とSite-to-Site VPNやDirect Connectを繋いでいる環境において、Amazon FSx for NetApp ONTAP(以降FSxN)やAmazon FSx for Windows File Server(以降FSxW)をクライアントPCが使用するファイルサーバーとして利用することがあります。
しかし、社外からアクセスする場合はVPN接続をするなどワンステップを挟む必要があります。
VPN接続において、クライアントPCのVPN接続用VPNルーターがオンプレミス拠点内にある場合、ファイルサーバーへ向かうトラフィックはVPNルーターがあるオンプレミス拠点から行われることになります。
この場合、オンプレミス拠点とVPC間を結ぶSite-to-Site VPNやDirect Connectを毎回経由することになります。一度オンプレミス拠点を経由する分、どうしてもレイテンシーが気になります。また、Site-to-Site VPNやDirect Connectで接続するために使用している回線やルーターなどのネットワーク機器の信頼性が乏しい場合は、オンプレミス拠点とVPCとの接続が切れてしまった場合にファイルサーバーに接続することができなくなります。
このような理由からClient VPNを用いてオンプレミス拠点を介さずにファイルサーバーに接続したい場面があります。
実際に今回はFSxNをSMBファイルサーバーとして動作させ、Client VPNを用いて接続を行います。
いきなりまとめ
- Amazon FSx for NetApp ONTAPにClient VPN経由でSMB接続できる
- 正しい認証情報で、SPNが一致していればKerberos認証で接続可能
- SMBの暗号化と併せて利用することも可能
- 検証した限り、パフォーマンスは心許ない
やってみた
検証環境
検証環境は以下のとおりです。
corp.non-97.netのAD DCの作成は以下記事の検証で使用したものを流用します。
また、ドメインユーザーtest-user01とtest-user02を用意し、どちらもFSxAdminGroupというグローバルセキュリティグループに属させています。こちらも以下記事で用意したものを流用します。詳細はやってみた-ドメインユーザーの準備の章をご覧ください。
AD Connectorのサービスアカウントの作成
AD Connectorのサービスアカウントの作成から行います。
以下記事で紹介している手順を参考に行います。
# セキュリティグループを作成
> New-ADGroup `
-Name "Connectors" `
-GroupScope Global `
-GroupCategory Security `
-Path "CN=Users,DC=corp,DC=non-97,DC=net"
# AD Connectorのサービスアカウント作成
> New-ADUser `
-Name "ad-connector" `
-UserPrincipalName "ad-connector@corp.non-97.net" `
-Accountpassword (Read-Host -AsSecureString "AccountPassword") `
-Path "CN=Users,DC=corp,DC=non-97,DC=net" `
-PasswordNeverExpires $True `
-Enabled $True
AccountPassword: ********************************
# サービスアカウントをセキュリティグループに所属させる
> Add-ADGroupMember -Identity "Connectors" -Members "ad-connector"
# 作成したサービスアカウントの確認
> Get-ADUser -Filter 'Name -eq "ad-connector"' -SearchBase "CN=Users,DC=corp,DC=non-97,DC=net"
DistinguishedName : CN=ad-connector,CN=Users,DC=corp,DC=non-97,DC=net
Enabled : True
GivenName :
Name : ad-connector
ObjectClass : user
ObjectGUID : aa75775f-1ee0-4af5-a6f9-efbccefec95f
SamAccountName : ad-connector
SID : S-1-5-21-38571244-2121234638-1230449559-1643
Surname :
UserPrincipalName : ad-connector@corp.non-97.net
サービスアカウントの作成が完了したら、権限の委任を行います。
委任が必要な権限や細かい手順は以下AWS公式ドキュメント権限をサービスアカウントに委任するに記載されています。
以降は設定時のスクリーンショットを貼っておきます。
プロパティを確認して、AD Connectorのサービスアカウントが所属するセキュリティグループに権限が与えられていることを確認します。
AD Connectorの作成
続いて、AD Connectorの作成を行います。
こちらも先ほどの記事に細かいステップを紹介しています。
この時のスクリーンショットは以下のとおりです。
AD Connectorの作成を開始すると、ENIが生えてきます。AD DC on EC2のセキュリティグループのインバウンドルールで許可するために、このENIに割り当てられているセキュリティグループIDを控えておきます。
AD DC on EC2のセキュリティグループのインバウンドルールを更新して、AD Connectorのセキュリティグループからのアクセスを許可します。今回は検証なので全てのプロトコルを許可しました。
実際は以下のように必要なポートを絞ってあげると良いでしょう。
AD Connector で既存の Active Directory のドメインコントローラーにディレクトリリクエストをリダイレクトするには、既存のネットワークのファイアウォールで、Amazon VPC の両方のサブネットの CIDR に対して次のポートを開く必要があります。
- TCP/UDP 53 - DNS
- TCP/UDP 88 - Kerberos 認証
- TCP/UDP 389 - LDAP
これらは、AD Connector をディレクトリに接続する前に必要な最小限のポートです。固有の設定によっては、追加ポートが開かれていることが必要です。
セキュリティグループのインバウンドルールを許可して、しばらく待つとAD Connectorの作成が完了しました。
現時点ではClient VPNとの連携は無効になっていますね。
ACMによるサーバー証明書の発行
次にACMによるサーバー証明書の発行を行います。
Client VPNを利用する場合はサーバー証明書が必要になります。
サーバー証明書の発行をするCAの作成については、AWS公式ドキュメントではOpenVPN easy-rsaが紹介されていました。
ただ、CAの管理はあまりやりたいものではありません。
今回はクライアント証明書を用いた相互認証を行うつもりはないため、プライベートCAを立てるのではなく、ACMで証明書を発行します。
証明書を発行します。
この際、キーアルゴリズムはRSA 2048である必要があります。これはClient VPNの制約です。
クライアント VPN エンドポイントは、1024 ビットおよび 2048 ビットの RSA キーサイズのみサポートしています。また、クライアント証明書の [Subject (件名)] フィールドに CN 属性が含まれている必要があります。
ECDSA P 256で証明書を作成してもClient VPNエンドポイント作成時にACMで発行した証明書は表示されません。次とともに使用可能で表示されている項目もCloudFrontとELBのみとなっています。
RSA 20248で発行した場合は以下のとおりです。
Client VPNエンドポイントの作成
Client VPNエンドポイントの作成を行います。
Client VPNの各種設定周りの紹介は以下記事が非常に参考になります。
クライアント IPv4 CIDRはFSxNが存在するVPCのCIDR10.0.0.0/20と重複しないものを選択します。
また、認証はADを用いたユーザーベースの認証のみを選択します。
カスタムDNSサーバーはSMBファイルサーバーの名前解決をするために、AD DC on EC2のIPアドレスを指定しました。それ以外の特記事項はありません。
カスタムDNSサーバーについては以下記事で詳細に紹介されています。
Client VPNエンドポイントの作成が完了しました。
AD Connector側からもClient VPNの連携ステータスが有効になっていることを確認できました。
ただし、まだ指定したVPC上にENIは生えていません。
ターゲットネットワークの関連付けを行います。
関連付けには10分程度かかります。関連付けが完了すると、Client VPNエンドポイントのステータスもAvailableに変わります。
このタイミングで、Client VPNエンドポイント作成時に指定したIPv4 CIDR内のIPアドレスとENIのIPアドレスをでNATするためのルートテーブルも作成されました。
このままではまだ接続できません。
どのユーザーがどのネットワークにアクセスできるかを定義する承認ルールを追加する必要があります。
今回はDomain Adminsに属するユーザーがVPCのCIDR10.0.0.0/20内に通信できるようにしてあげます。
承認ルールで指定するセキュリティグループのSIDは以下のように確認できます。
> Get-ADGroup -Filter 'Name -eq "Domain Admins"'
DistinguishedName : CN=Domain Admins,CN=Users,DC=corp,DC=non-97,DC=net
GroupCategory : Security
GroupScope : Global
Name : Domain Admins
ObjectClass : group
ObjectGUID : 9c4df8a7-82f9-4dee-adaf-974810f60d13
SamAccountName : Domain Admins
SID : S-1-5-21-38571244-2121234638-1230449559-512
確認したSIDを用いて承認ルールを追加します。
承認ルールが追加されたことを確認します。
設定ファイルのダウンロード
Client VPN接続に必要な設定ファイルをダウンロードします。
今回はセルフサービスポータル機能を有効化しているので、そこからダウンロードします。
セルフサービスポータルについては以下記事をご覧ください。
セルフサービスポータルのURLに接続する認証が求められます。ドメインユーザーの認証情報を入力してログインします。
ログインできました。Download client configurationをクリックして、設定ファイルをダウンロードします。
Client VPNの接続
Client VPNの接続を行います。
先ほどダウンロードした設定ファイルを読み込み、プロファイルを作成しました。
作成したプロファイルを指定して接続します。
認証情報が求められました。Domain Adminsに属するユーザーの認証情報を入力して接続します。
接続済みになりました。
手元の端末で参照しているDNSサーバーを確認すると、カスタムDNSサーバーで指定したIPアドレスとなっていました。
> cat /etc/resolv.conf | grep nameserver
nameserver 10.0.0.139
インターネット上のリソースの名前解決および接続ができるかどうか確認します。
> dig dev.classmethod.jp
; <<>> DiG 9.10.6 <<>> dev.classmethod.jp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20417
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;dev.classmethod.jp. IN A
;; ANSWER SECTION:
dev.classmethod.jp. 16 IN A 3.167.99.120
dev.classmethod.jp. 16 IN A 3.167.99.14
dev.classmethod.jp. 16 IN A 3.167.99.118
dev.classmethod.jp. 16 IN A 3.167.99.98
;; Query time: 200 msec
;; SERVER: 10.0.0.139#53(10.0.0.139)
;; WHEN: Fri Mar 14 12:44:10 JST 2025
;; MSG SIZE rcvd: 111
> curl -I https://dev.classmethod.jp
HTTP/2 200
content-type: text/html; charset=utf-8
cache-control: public, max-age=45, stale-if-error=21600
date: Fri, 14 Mar 2025 03:44:14 GMT
x-middleware-rewrite: /
x-powered-by: Next.js
x-envoy-upstream-service-time: 52
server: envoy
vary: Accept-Encoding
x-cache: Miss from cloudfront
via: 1.1 d2cb7631fe0377fd030ab6f92237ce72.cloudfront.net (CloudFront)
x-amz-cf-pop: IAD55-P7
alt-svc: h3=":443"; ma=86400
x-amz-cf-id: M-jenHxy4YLeBFf_iVzYnFUgPZfftcr6LJP2bnDyTheDmyEewa1mKA==
server-timing: cdn-upstream-layer;desc="REC",cdn-upstream-dns;dur=0,cdn-upstream-connect;dur=0,cdn-upstream-fbl;dur=201,cdn-cache-miss,cdn-pop;desc="IAD55-P7",cdn-rid;desc="M-jenHxy4YLeBFf_iVzYnFUgPZfftcr6LJP2bnDyTheDmyEewa1mKA==",cdn-downstream-fbl;dur=209
はい、問題なくできました。
ターゲットネットワークで指定したサブネットはインターネットへのルーティングはありません。今回はスプリットトンネルを有効化しているため、Client VPNエンドポイントのルートテーブルで定義されていないルート以外はClient VPNのトンネルを経由しません。
スプリットトンネルでプッシュされるルートについては以下記事で詳細に紹介されています。
AD DC on EC2インスタンスに対して手元の端末からpingを叩きます。
> ping 10.0.0.139 -c 4
PING 10.0.0.139 (10.0.0.139): 56 data bytes
64 bytes from 10.0.0.139: icmp_seq=0 ttl=127 time=191.095 ms
64 bytes from 10.0.0.139: icmp_seq=1 ttl=127 time=179.658 ms
64 bytes from 10.0.0.139: icmp_seq=2 ttl=127 time=180.482 ms
64 bytes from 10.0.0.139: icmp_seq=3 ttl=127 time=180.568 ms
--- 10.0.0.139 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 179.658/182.951/191.095/4.715 ms
はい、問題なく通りました。
承認ルールで承認されたユーザーの認証情報でClient VPN接続
せっかくなので、承認ルールで承認されたユーザーの認証情報でClient VPN接続をします。
test-user01というユーザーはDomain Adminsに所属していません。接続してみましょう。
はい、正常に接続できました。
この状態でAD DC on EC2にpingを叩きます。
> cat /etc/resolv.conf | grep nameserver
nameserver 10.0.0.139
> ping 10.0.0.139
PING 10.0.0.139 (10.0.0.139): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
^C
--- 10.0.0.139 ping statistics ---
6 packets transmitted, 0 packets received, 100.0% packet loss
はい、疎通できなくなりました。
承認ルールが意図したとおりに動作していますね。
ドメイン参加していない端末からSMBファイルサーバーへ接続
それでは、実際にSMBファイルサーバーへ接続します。
手元の端末がドメイン参加はしていません。
Domain Adminsに属するユーザーでClient VPN接続し直します。
SMBファイルサーバーの名前解決ができることを確認します。
> dig SMB-SERVER.corp.non-97.net
; <<>> DiG 9.10.6 <<>> SMB-SERVER.corp.non-97.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45179
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;SMB-SERVER.corp.non-97.net. IN A
;; ANSWER SECTION:
SMB-SERVER.corp.non-97.net. 86400 IN A 10.0.8.246
;; Query time: 199 msec
;; SERVER: 10.0.0.139#53(10.0.0.139)
;; WHEN: Fri Mar 14 12:44:43 JST 2025
;; MSG SIZE rcvd: 71
できましたね。
FinderからSMBファイルサーバーへ接続します。
認証情報を求められました。ドメインのAdministratorの認証情報を入力して接続します。
ファイル共有の一覧が表示されました。適当なファイル共有を選択してOKをクリックします。
SMBファイル共有に接続できました。
ファイルのオープンも可能です。
更新もできました。
手元の端末からFSxNファイルシステムへSSHして、現在のSMBセッションを確認します。
> ssh fsxadmin@10.0.8.166
The authenticity of host '10.0.8.166 (10.0.8.166)' can't be established.
ED25519 key fingerprint is SHA256:nyePts9ZGyOQHQ7c/3ucUBmMXHpZlr09DKpbEiLqGGc.
This host key is known by the following other names/addresses:
~/.ssh/known_hosts:104: [localhost]:22222
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.0.8.166' (ED25519) to the list of known hosts.
(fsxadmin@10.0.8.166) Password:
Last login time: 2/26/2025 06:48:30
Your privilege has changed since last login.
::> whoami
(security login whoami)
User: fsxadmin
Role: fsxadmin
Trust Score: -
::> set diag
Warning: These diagnostic commands are for use by NetApp personnel only.
Do you want to continue? {y|n}: y
::*> cifs security show -vserver svm -fields is-smb-encryption-required
vserver is-smb-encryption-required
------- --------------------------
svm true
::*> cifs session show
Node: FsxId0e64a4f5386f74c87-01
Vserver: svm
Connection Session Open Idle Connection
ID ID Workstation Windows User Files Time Count
---------- ------- ---------------- ---------------- --------- ------------ ---------------
3709549515 3309864251140603907 12s 1
10.0.8.252 CORP\ 2
Administrator
::*> cifs session show -instance
Vserver: svm
Node: FsxId0e64a4f5386f74c87-01
Session ID: 3309864251140603907
Connection ID: 3709549515
Incoming Data LIF IP Address: 10.0.8.246
Workstation IP Address: 10.0.8.252
Authentication Mechanism: Kerberos
User Authenticated as: domain-user
Windows User: CORP\Administrator
UNIX User: root
Open Shares: 1
Open Files: 2
Open Other: 0
Connected Time: 4m 28s
Idle Time: 15s
Protocol Version: SMB3_1
Continuously Available: No
Is Session Signed: false
NetBIOS Name: -
SMB Encryption Status: encrypted
Large MTU Enabled: true
Connection Count: 1
Active Shares: previous-version-test-share
Kerberos認証でSMB 3.1系で接続されており、通信は暗号化されていることが分かります。
Kerberos認証なのであれば、セキュリティ要件的にNTLM認証を制御しなければならない場合にも対応できそうですね。
書き込み速度の確認
せっかくなので、書き込み速度も確認します。
手元の端末のインターネット速度を計測すると、上りは250Mbpsほどでした。ぼちぼちなのではないでしょうか。
それでは、fioでSMBファイルサーバーへ書き込みを行います。
> fio \
--directory=/Volumes/previous-version-test-share/test-dir \
--name fio_encrypt_randwrite_4KiB_block_1GiB_4jobs \
--ioengine=psync \
--direct=1 \
--rw=randwrite \
--bs=4K \
--size=1G \
--numjobs=4 \
--runtime=60 \
--eta-newline=10 \
--time_based=1 \
--group_reporting \
--norandommap
fio_encrypt_randwrite_4KiB_block_1GiB_4jobs: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
...
fio-3.39
Starting 4 processes
fio_encrypt_randwrite_4KiB_block_1GiB_4jobs: Laying out IO file (1 file / 1024MiB)
fio_encrypt_randwrite_4KiB_block_1GiB_4jobs: Laying out IO file (1 file / 1024MiB)
fio_encrypt_randwrite_4KiB_block_1GiB_4jobs: Laying out IO file (1 file / 1024MiB)
fio_encrypt_randwrite_4KiB_block_1GiB_4jobs: Laying out IO file (1 file / 1024MiB)
Jobs: 4 (f=0)
Jobs: 4 (f=4): [w(4)][20.0%][w=79KiB/s][w=19 IOPS][eta 00m:48s]
Jobs: 4 (f=4): [w(4)][38.3%][w=87KiB/s][w=21 IOPS][eta 00m:37s]
Jobs: 4 (f=4): [w(4)][56.7%][w=87KiB/s][w=21 IOPS][eta 00m:26s]
Jobs: 4 (f=4): [w(4)][75.0%][w=79KiB/s][w=19 IOPS][eta 00m:15s]
Jobs: 4 (f=4): [w(4)][93.3%][w=79KiB/s][w=19 IOPS][eta 00m:04s]
Jobs: 4 (f=4): [f(4)][100.0%][w=68KiB/s][w=17 IOPS][eta 00m:00s]
fio_encrypt_randwrite_4KiB_block_1GiB_4jobs: (groupid=0, jobs=4): err= 0: pid=45089: Fri Mar 14 13:37:29 2025
write: IOPS=20, BW=83.3KiB/s (85.3kB/s)(5012KiB/60170msec); 0 zone resets
clat (msec): min=177, max=388, avg=187.83, stdev=31.12
lat (msec): min=177, max=388, avg=187.83, stdev=31.12
clat percentiles (msec):
| 1.00th=[ 178], 5.00th=[ 180], 10.00th=[ 180], 20.00th=[ 180],
| 30.00th=[ 180], 40.00th=[ 182], 50.00th=[ 182], 60.00th=[ 182],
| 70.00th=[ 184], 80.00th=[ 184], 90.00th=[ 188], 95.00th=[ 201],
| 99.00th=[ 363], 99.50th=[ 368], 99.90th=[ 384], 99.95th=[ 388],
| 99.99th=[ 388]
bw ( KiB/s): min= 29, max= 96, per=97.24%, avg=81.46, stdev= 4.05, samples=470
iops : min= 5, max= 24, avg=17.48, stdev= 1.03, samples=470
lat (msec) : 250=97.05%, 500=2.95%
cpu : usr=0.01%, sys=0.05%, ctx=1990, majf=0, minf=30
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwts: total=0,1253,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=1
Run status group 0 (all jobs):
WRITE: bw=83.3KiB/s (85.3kB/s), 83.3KiB/s-83.3KiB/s (85.3kB/s-85.3kB/s), io=5012KiB (5132kB), run=60170-60170msec
> fio \
--directory=/Volumes/previous-version-test-share/test-dir \
--name fio_encrypt_randread_1MiB_block_1GiB_4jobs \
--ioengine=psync \
--direct=1 \
--rw=randwrite \
--bs=1M \
--size=1G \
--numjobs=4 \
--runtime=60 \
--eta-newline=10 \
--time_based=1 \
--group_reporting \
--norandommap
fio_encrypt_randread_1MiB_block_1GiB_4jobs: (g=0): rw=randwrite, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=psync, iodepth=1
...
fio-3.39
Starting 4 processes
fio_encrypt_randread_1MiB_block_1GiB_4jobs: Laying out IO file (1 file / 1024MiB)
fio_encrypt_randread_1MiB_block_1GiB_4jobs: Laying out IO file (1 file / 1024MiB)
fio_encrypt_randread_1MiB_block_1GiB_4jobs: Laying out IO file (1 file / 1024MiB)
fio_encrypt_randread_1MiB_block_1GiB_4jobs: Laying out IO file (1 file / 1024MiB)
Jobs: 4 (f=0)
Jobs: 4 (f=4): [w(4)][20.0%][w=4063KiB/s][w=3 IOPS][eta 00m:48s]
Jobs: 4 (f=4): [w(4)][36.7%][eta 00m:38s]
Jobs: 4 (f=4): [w(4)][53.3%][eta 00m:28s]
Jobs: 4 (f=4): [w(4)][71.7%][w=3072KiB/s][w=3 IOPS][eta 00m:17s]
Jobs: 4 (f=4): [w(4)][88.3%][w=3068KiB/s][w=2 IOPS][eta 00m:07s]
Jobs: 4 (f=4): [f(1),w(1),f(2)][3.3%][w=3072KiB/s][w=3 IOPS][eta 30m:05s]
fio_encrypt_randread_1MiB_block_1GiB_4jobs: (groupid=0, jobs=4): err= 0: pid=47478: Fri Mar 14 13:39:31 2025
write: IOPS=2, BW=2255KiB/s (2309kB/s)(136MiB/61762msec); 0 zone resets
clat (msec): min=655, max=4770, avg=1732.73, stdev=680.49
lat (msec): min=655, max=4770, avg=1732.97, stdev=680.47
clat percentiles (msec):
| 1.00th=[ 693], 5.00th=[ 877], 10.00th=[ 1028], 20.00th=[ 1167],
| 30.00th=[ 1318], 40.00th=[ 1502], 50.00th=[ 1620], 60.00th=[ 1720],
| 70.00th=[ 1938], 80.00th=[ 2123], 90.00th=[ 2601], 95.00th=[ 3071],
| 99.00th=[ 3977], 99.50th=[ 4799], 99.90th=[ 4799], 99.95th=[ 4799],
| 99.99th=[ 4799]
bw ( KiB/s): min= 8060, max= 8208, per=100.00%, avg=8134.22, stdev= 8.65, samples=136
iops : min= 4, max= 8, avg= 4.44, stdev= 0.31, samples=136
lat (msec) : 750=1.47%, 1000=7.35%, 2000=68.38%, >=2000=22.79%
cpu : usr=0.01%, sys=0.11%, ctx=943, majf=0, minf=29
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwts: total=0,136,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=1
Run status group 0 (all jobs):
WRITE: bw=2255KiB/s (2309kB/s), 2255KiB/s-2255KiB/s (2309kB/s-2309kB/s), io=136MiB (143MB), run=61762-61762msec
以下記事で同様の検証をしています。
表にまとめると以下のとおりです。
| Client VPN経由 | 読み書き | ブロックサイズ | 平均スループット(MiBps) | 平均IOPS | 平均レイテンシー(usec) | Client VPN経由時との平均スループット差 | Client VPN経由時との平均IOPS差 | Client VPN経由時との平均レイテンシー差 |
|---|---|---|---|---|---|---|---|---|
| No | randwrite | 4KiB | 24.21 | 6,195.62 | 642.58 | - | - | - |
| No | randwrite | 1MiB | 144.26 | 142.55 | 276,500 | - | - | - |
| Yes | randwrite | 4KiB | 0.08 | 17.48 | 187,830 | -99.67% | -99.72% | 29,130.60% |
| Yes | randwrite | 1MiB | 7.94 | 4.44 | 1,732,970 | -94.50% | -96.89% | 526.75% |
- VPNのトンネルを通ることによるレイテンシー
- 距離的なレイテンシー
などに起因して思われるパフォーマンスの低さですね。本番運用する場合は事前にPoCで感覚を掴んでおくと良いでしょう。
とはいえ、パフォーマンスがかなり落ちているので、何か改善したいです。
Macの場合、Large MTUが有効になっていると、どういう訳かパフォーマンスが落ちることがあるようです。
Issue
- Slow performance reported by MacOS SMB clients when copying data to or from an ONTAP SVM CIFS share
- vserver cifs option -is-large-mtu-enabled is enabled
Cause
Not identified
Solution
- Disable large MTU as a workaround
::> set advanced ::*> vserver cifs server options modify -is-large-mtu-enabled false
- Please contact Apple Support for further assistance.
MacOS clients report slow performance when CIFS large-MTU is enabled - NetApp Knowledge Base
試しにLarge MTUを無効にして、再度計測します。
::*> cifs server options show -vserver svm -fields is-large-mtu-enabled
vserver is-large-mtu-enabled
------- --------------------
svm true
::*> cifs server options modify -vserver svm -is-large-mtu-enabled false
::*> cifs server options show -vserver svm -fields is-large-mtu-enabled
vserver is-large-mtu-enabled
------- --------------------
svm false
> fio \
--directory=/Volumes/previous-version-test-share/test-dir \
--name fio_encrypt_randread_1MiB_block_1GiB_4jobs \
--ioengine=psync \
--direct=1 \
--rw=randwrite \
--bs=1M \
--size=1G \
--numjobs=4 \
--runtime=60 \
--eta-newline=10 \
--time_based=1 \
--group_reporting \
--norandommap
fio_encrypt_randread_1MiB_block_1GiB_4jobs: (g=0): rw=randwrite, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=psync, iodepth=1
...
fio-3.39
Starting 4 processes
fio_encrypt_randread_1MiB_block_1GiB_4jobs: Laying out IO file (1 file / 1024MiB)
fio_encrypt_randread_1MiB_block_1GiB_4jobs: Laying out IO file (1 file / 1024MiB)
fio_encrypt_randread_1MiB_block_1GiB_4jobs: Laying out IO file (1 file / 1024MiB)
fio_encrypt_randread_1MiB_block_1GiB_4jobs: Laying out IO file (1 file / 1024MiB)
Jobs: 4 (f=1): [w(4)][5.0%][eta 00m:57s]
Jobs: 4 (f=4): [w(4)][23.3%][w=2045KiB/s][w=1 IOPS][eta 00m:46s]
Jobs: 4 (f=4): [w(4)][41.7%][w=2037KiB/s][w=1 IOPS][eta 00m:35s]
Jobs: 4 (f=4): [w(4)][58.3%][w=1021KiB/s][w=0 IOPS][eta 00m:25s]
Jobs: 4 (f=4): [w(4)][76.7%][w=1020KiB/s][w=0 IOPS][eta 00m:14s]
Jobs: 4 (f=4): [w(4)][95.0%][w=3072KiB/s][w=3 IOPS][eta 00m:03s]
Jobs: 3 (f=3): [_(1),f(2),w(1)][52.5%][eta 00m:57s]
fio_encrypt_randread_1MiB_block_1GiB_4jobs: (groupid=0, jobs=4): err= 0: pid=39455: Fri Mar 14 16:08:43 2025
write: IOPS=1, BW=1513KiB/s (1550kB/s)(92.0MiB/62257msec); 0 zone resets
clat (msec): min=1186, max=5994, avg=2425.80, stdev=859.67
lat (msec): min=1186, max=5995, avg=2425.95, stdev=859.67
clat percentiles (msec):
| 1.00th=[ 1183], 5.00th=[ 1301], 10.00th=[ 1502], 20.00th=[ 1703],
| 30.00th=[ 1905], 40.00th=[ 2232], 50.00th=[ 2333], 60.00th=[ 2467],
| 70.00th=[ 2567], 80.00th=[ 2836], 90.00th=[ 3574], 95.00th=[ 4077],
| 99.00th=[ 6007], 99.50th=[ 6007], 99.90th=[ 6007], 99.95th=[ 6007],
| 99.99th=[ 6007]
bw ( KiB/s): min= 8052, max= 8195, per=100.00%, avg=8127.30, stdev= 8.01, samples=92
iops : min= 4, max= 7, avg= 4.22, stdev= 0.23, samples=92
lat (msec) : 2000=31.52%, >=2000=68.48%
cpu : usr=0.00%, sys=0.04%, ctx=756, majf=0, minf=28
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwts: total=0,92,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=1
Run status group 0 (all jobs):
WRITE: bw=1513KiB/s (1550kB/s), 1513KiB/s-1513KiB/s (1550kB/s-1550kB/s), io=92.0MiB (96.5MB), run=62257-62257msec
ほとんど変わりありませんね。
他にもSMBのMax Creditを5,000ほどに変更するとパフォーマンスが改善されるとの記載がありました。
Issue
- MacOS users are reporting slowness when copying files to SMB shares.
- Copying multiple files degrades overall throughput from the same client.
Cause
- ONTAP default value for CIFS -max-credits caused degraded performance for MacOS Big Sur
- Apple Support appears to be aware of the issue, but details are unknown to NetApp at this time
Solution
- Contact Apple Support
- Workaround:
- Increase CIFS max-credits values as per How ONTAP implements SMB crediting - NetApp Knowledge Base
Note: It appears that setting value around 5000 will result in best performanceSMB performance slow for MacOS clients - NetApp Knowledge Base
ただし、SMBクレジットはクライアントが同時に処理できる未処理のリクエスト数です。
- Modified credit value will only take effect on new cifs sessions
- SMB credits determine the number of outstanding simultaneous requests that the client can have on a particular connection.
- The allowed range is between 2 and 8192
- Default value does not need to be changed unless issue is confirmed to be root cause or vendor states a specific number of credits are needed.
- Follow client vendor recommendations if it differs from the default
- While it is possible to set number of credits to 2, there have been reports that some clients start to misbehave with such a low setting
- Changing the max-credits value is not expected to cause any issues
- Recommendation: Test changes on a test SVM with test clients prior to making the change on a production SVM.
- To troubleshoot, slowly increase the value until the issue is resolved
- As documented in this Microsoft Docs page, Performance tuning for SMB file servers, Windows now defaults to 512 credits.
- For assistance with disabling SMB crediting, contact NetApp Technical Support and reference this article.
fioではpsyncと同期処理を行なっているので、関係はない想定です。
とはいえ、念の為試してみます。
::*> cifs server options modify -vserver svm -is-large-mtu-enabled true
Warning: Enabling CIFS Large MTU may cause performance degradation for clients not using Large MTU.
Do you want to continue? {y|n}: y
::*> cifs server options show -vserver svm -fields is-large-mtu-enabled
vserver is-large-mtu-enabled
------- --------------------
svm true
::*> cifs options show -vserver svm -fields max-credits
vserver max-credits
------- -----------
svm 512
::*> cifs options modify -vserver svm -max-credits 5000
::*> cifs options show -vserver svm -fields max-credits
vserver max-credits
------- -----------
svm 5000
> fio \
--directory=/Volumes/previous-version-test-share/test-dir \
--name fio_encrypt_randwrite_4KiB_block_1GiB_4jobs \
--ioengine=psync \
--direct=1 \
--rw=randwrite \
--bs=4K \
--size=1G \
--numjobs=4 \
--runtime=60 \
--eta-newline=10 \
--time_based=1 \
--group_reporting \
--norandommap
fio_encrypt_randwrite_4KiB_block_1GiB_4jobs: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
...
fio-3.39
Starting 4 processes
fio_encrypt_randwrite_4KiB_block_1GiB_4jobs: Laying out IO file (1 file / 1024MiB)
fio_encrypt_randwrite_4KiB_block_1GiB_4jobs: Laying out IO file (1 file / 1024MiB)
fio_encrypt_randwrite_4KiB_block_1GiB_4jobs: Laying out IO file (1 file / 1024MiB)
fio_encrypt_randwrite_4KiB_block_1GiB_4jobs: Laying out IO file (1 file / 1024MiB)
Jobs: 4 (f=4): [w(4)][6.7%][w=79KiB/s][w=19 IOPS][eta 00m:56s]
Jobs: 4 (f=4): [w(4)][23.3%][w=83KiB/s][w=20 IOPS][eta 00m:46s]
Jobs: 4 (f=4): [w(4)][40.0%][w=91KiB/s][w=22 IOPS][eta 00m:36s]
Jobs: 4 (f=4): [w(4)][58.3%][w=80KiB/s][w=20 IOPS][eta 00m:25s]
Jobs: 4 (f=4): [w(4)][76.7%][w=96KiB/s][w=24 IOPS][eta 00m:14s]
Jobs: 4 (f=4): [w(4)][95.0%][w=95KiB/s][w=23 IOPS][eta 00m:03s]
Jobs: 4 (f=4): [f(4)][100.0%][w=95KiB/s][w=23 IOPS][eta 00m:00s]
fio_encrypt_randwrite_4KiB_block_1GiB_4jobs: (groupid=0, jobs=4): err= 0: pid=84468: Fri Mar 14 16:42:37 2025
write: IOPS=21, BW=85.8KiB/s (87.9kB/s)(5160KiB/60119msec); 0 zone resets
clat (msec): min=179, max=227, avg=183.80, stdev= 5.13
lat (msec): min=179, max=227, avg=183.80, stdev= 5.13
clat percentiles (msec):
| 1.00th=[ 180], 5.00th=[ 180], 10.00th=[ 180], 20.00th=[ 182],
| 30.00th=[ 182], 40.00th=[ 182], 50.00th=[ 184], 60.00th=[ 184],
| 70.00th=[ 184], 80.00th=[ 186], 90.00th=[ 188], 95.00th=[ 192],
| 99.00th=[ 209], 99.50th=[ 215], 99.90th=[ 224], 99.95th=[ 228],
| 99.99th=[ 228]
bw ( KiB/s): min= 28, max= 96, per=96.70%, avg=83.38, stdev= 3.76, samples=473
iops : min= 4, max= 24, avg=17.92, stdev= 0.96, samples=473
lat (msec) : 250=100.00%
cpu : usr=0.01%, sys=0.04%, ctx=1777, majf=0, minf=34
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwts: total=0,1290,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=1
Run status group 0 (all jobs):
WRITE: bw=85.8KiB/s (87.9kB/s), 85.8KiB/s-85.8KiB/s (87.9kB/s-87.9kB/s), io=5160KiB (5284kB), run=60119-60119msec
> fio \
--directory=/Volumes/previous-version-test-share/test-dir \
--name fio_encrypt_randread_1MiB_block_1GiB_4jobs \
--ioengine=psync \
--direct=1 \
--rw=randwrite \
--bs=1M \
--size=1G \
--numjobs=4 \
--runtime=60 \
--eta-newline=10 \
--time_based=1 \
--group_reporting \
--norandommap
fio_encrypt_randread_1MiB_block_1GiB_4jobs: (g=0): rw=randwrite, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=psync, iodepth=1
...
fio-3.39
Starting 4 processes
Jobs: 4 (f=4): [w(4)][20.0%][w=3050KiB/s][w=2 IOPS][eta 00m:48s]
Jobs: 4 (f=4): [w(4)][36.7%][w=2050KiB/s][w=2 IOPS][eta 00m:38s]
Jobs: 4 (f=4): [w(4)][55.0%][w=1025KiB/s][w=1 IOPS][eta 00m:27s]
Jobs: 4 (f=4): [w(4)][73.3%][w=1022KiB/s][w=0 IOPS][eta 00m:16s]
Jobs: 4 (f=4): [w(4)][90.0%][w=2052KiB/s][w=2 IOPS][eta 00m:06s]
Jobs: 1 (f=1): [_(2),f(1),_(1)][100.0%][w=3068KiB/s][w=2 IOPS][eta 00m:00s]
fio_encrypt_randread_1MiB_block_1GiB_4jobs: (groupid=0, jobs=4): err= 0: pid=48860: Fri Mar 14 16:15:34 2025
write: IOPS=1, BW=2042KiB/s (2091kB/s)(123MiB/61691msec); 0 zone resets
clat (msec): min=703, max=4384, avg=1946.72, stdev=819.79
lat (msec): min=703, max=4384, avg=1946.97, stdev=819.75
clat percentiles (msec):
| 1.00th=[ 785], 5.00th=[ 969], 10.00th=[ 1053], 20.00th=[ 1250],
| 30.00th=[ 1469], 40.00th=[ 1552], 50.00th=[ 1653], 60.00th=[ 1921],
| 70.00th=[ 2333], 80.00th=[ 2635], 90.00th=[ 3104], 95.00th=[ 3473],
| 99.00th=[ 4245], 99.50th=[ 4396], 99.90th=[ 4396], 99.95th=[ 4396],
| 99.99th=[ 4396]
bw ( KiB/s): min= 8072, max= 8196, per=100.00%, avg=8134.43, stdev= 7.05, samples=123
iops : min= 4, max= 8, avg= 4.20, stdev= 0.22, samples=123
lat (msec) : 750=0.81%, 1000=6.50%, 2000=55.28%, >=2000=37.40%
cpu : usr=0.00%, sys=0.11%, ctx=854, majf=0, minf=27
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwts: total=0,123,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=1
Run status group 0 (all jobs):
WRITE: bw=2042KiB/s (2091kB/s), 2042KiB/s-2042KiB/s (2091kB/s-2091kB/s), io=123MiB (129MB), run=61691-61691msec
はい、特に結果は変わりませんね。
Client VPNの認証で使用した別のユーザーの認証情報でSMBファイルサーバーに接続
Client VPNの認証で使用した別のユーザーの認証情報でSMBファイルサーバーに接続できるのかも確認しておきます。
SMBのセッションを確認するとKerberos認証をしているようですが、手元の端末はcorp.non-97.netにドメイン参加していないですし、いずれのドメインにも参加していないので「信頼関係を組んでいるから」という線もありません。
keytabファイルも作成はしていないです。
どのタイミングで、どこからKerberos認証のチケットを取得しているのでしょうか。Client VPNがAD Connectorを介して認証するタイミングで行われていたりするのでしょうか。
Client VPNをドメインのAdministratorで認証し、SMBファイルサーバーへ接続する際はtest-user01を使用してみます。
SMBのセッションを確認すると、確かにtest-user01です。
::*> cifs session show -instance
Vserver: svm
Node: FsxId0e64a4f5386f74c87-01
Session ID: 3309864251140603908
Connection ID: 3709549521
Incoming Data LIF IP Address: 10.0.8.246
Workstation IP Address: 10.0.8.252
Authentication Mechanism: Kerberos
User Authenticated as: domain-user
Windows User: CORP\test-user01
UNIX User: root
Open Shares: 1
Open Files: 17
Open Other: 0
Connected Time: 1m 15s
Idle Time: 11s
Protocol Version: SMB3_1
Continuously Available: No
Is Session Signed: false
NetBIOS Name: -
SMB Encryption Status: encrypted
Large MTU Enabled: true
Connection Count: 1
Active Shares: previous-version-test-share
ということで、Client VPNがAD Connectorを介して認証するタイミングではなさそうです。
IPアドレス指定でSMBファイルサーバーに接続
IPアドレス指定でSMBファイルサーバーに接続した場合も確認しておきます。
SMBファイルサーバーのIPアドレスを指定します。
認証情報を入力すると、SMBファイル共有一覧が表示されました。
特にエラーになることもなく、接続も完了しました。
ONTAP CLIでSMBセッションを確認します。
::*> cifs session show -instance
Vserver: svm
Node: FsxId0e64a4f5386f74c87-01
Session ID: 3309864251140603917
Connection ID: 3709549551
Incoming Data LIF IP Address: 10.0.8.246
Workstation IP Address: 10.0.8.117
Authentication Mechanism: NTLMv2
User Authenticated as: domain-user
Windows User: CORP\test-user01
UNIX User: root
Open Shares: 1
Open Files: 22
Open Other: 0
Connected Time: 43s
Idle Time: 0s
Protocol Version: SMB3_1
Continuously Available: No
Is Session Signed: false
NetBIOS Name: -
SMB Encryption Status: encrypted
Large MTU Enabled: true
Connection Count: 1
Active Shares: previous-version-test-share
はい、NTLM認証になったことを確認できました。
Client VPNを介してFSxに接続することはできる
Amazon FSx for NetApp ONTAPにClient VPN経由でSMB接続してみました。
Client VPNを介してFSxに接続することはできます。FSxNで出来たならFSxWでも問題なくできるでしょう。
パフォーマンスが気になるためハードワークはできませんが、もしもの障害時の予備として手順整備をしておくぐらいは良さそうですね。
また、ファイルサーバーに重要なデータを保存しているのであれば、セキュリティも重要視しておきたいです。
クライアント証明書を用いて相互認証をしたり、多要素認証をしたりすることも検討しましょう。
この記事が誰かの助けになれば幸いです。
以上、クラウド事業本部 コンサルティング部の のんピ(@non____97)でした!
![[登壇レポート] Storage-JAWS #7 AWS Pi Day 2025直前スペシャル！ 「Windows Server に FSx for NetApp ONTAP を iSCSI 接続してみた」という内容で登壇してきました #storagejaws #jawsug](https://devio2024-media.developers.io/image/upload/v1741670860/user-gen-eyecatch/wxb5zcp77pvprmifqtkd.png)
