かなり長いことInfinibandを使っていますが、Infinibandで試そうと思いつつ全く試していなかったことがあります。それがNFS over RDMAです。ESXiでIB+NFSoRDMAに対応していれば試していたのですが、これが非対応だったこととSRPが速すぎてそれ以上追求するモチベーションがわかなかったことが理由でした。しかし、最近PVEを検証する機会があり、その中でどうもIB+NFS+RDMAがいけそうだというのがわかったものの、ほかを探しても一切の情報がないので検証してみました。
PVEに行く前にそもそもNFSoRDMAってどう使うの?という疑問があり色々ググりましたが、NFSサーバ側には svcrdmaモジュールが必要で、クライアント側にはxprtrdmaが必要になるみたいですが、Debian12ではrpcrdma.koのエイリアスとしてすでにInboxでドライバをもっていました。
https://enterprise-support.nvidia.com/s/article/howto-configure-nfs-over-rdma--roce-x
root@debian:~# modinfo svcrdma
filename: /lib/modules/6.1.0-28-amd64/kernel/net/sunrpc/xprtrdma/rpcrdma.ko
alias: rpcrdma6
alias: xprtrdma
alias: svcrdma
license: Dual BSD/GPL
description: RPC/RDMA Transport
author: Open Grid Computing and Network Appliance, Inc.
depends: sunrpc,ib_core,rdma_cm
retpoline: Y
intree: Y
name: rpcrdma
vermagic: 6.1.0-28-amd64 SMP preempt mod_unload modversions
sig_id: PKCS#7
signer: Debian Secure Boot CA
sig_key: 32:A0:28:7F:84:1A:03:6F:A3:93:C1:E0:65:C4:3A:E6:B2:42:26:43
sig_hashalgo: sha256
signature: 15:83:F8:C8:E4:FE:CB:21:AA:92:43:39:E8:FC:5F:61:0C:D9:3E:F9:
28:1D:9A:1C:35:25:58:08:0C:DB:8E:D5:07:36:CD:E4:D5:1E:30:2A:
61:FE:20:AB:DF:98:C0:55:C5:F6:6E:B8:8B:32:42:D4:D5:9A:58:44:
E5:EB:5A:FB:B6:06:E9:1E:B2:0A:F6:D1:FC:64:B1:F9:68:DF:55:06:
D3:70:DB:13:35:99:FF:2B:6C:42:8C:D0:1D:C7:D6:3A:BC:55:04:08:
0A:7D:1D:6A:EF:D6:70:32:BB:A4:B5:D3:2A:62:2E:1A:1C:F9:D4:B4:
B6:87:4E:FF:F8:C3:96:3E:09:2A:86:4C:41:F3:2B:9E:AA:AE:07:0D:
98:A4:EA:D4:5F:5F:E3:CC:DF:42:1F:79:FF:F7:B6:77:DF:09:BF:38:
74:6F:1B:18:D0:48:BF:61:02:DC:25:7A:CE:6D:91:79:06:4B:A2:02:
28:85:A4:D3:7A:21:79:80:31:6C:98:B9:6F:E2:94:BA:CB:AB:A9:03:
6A:A8:17:3F:26:4B:91:42:E0:5C:53:6E:B2:D3:99:63:24:04:FD:32:
3A:FF:2D:48:A5:B5:D4:89:B9:DD:D5:FC:FA:15:5E:1D:35:06:C0:46:
F6:C7:CE:0F:B7:4E:1F:38:F2:5E:A5:46:8E:1C:7C:9C
root@debian:~# modinfo xprtrdma
filename: /lib/modules/6.1.0-28-amd64/kernel/net/sunrpc/xprtrdma/rpcrdma.ko
alias: rpcrdma6
alias: xprtrdma
alias: svcrdma
license: Dual BSD/GPL
description: RPC/RDMA Transport
author: Open Grid Computing and Network Appliance, Inc.
depends: sunrpc,ib_core,rdma_cm
retpoline: Y
intree: Y
name: rpcrdma
vermagic: 6.1.0-28-amd64 SMP preempt mod_unload modversions
sig_id: PKCS#7
signer: Debian Secure Boot CA
sig_key: 32:A0:28:7F:84:1A:03:6F:A3:93:C1:E0:65:C4:3A:E6:B2:42:26:43
sig_hashalgo: sha256
signature: 15:83:F8:C8:E4:FE:CB:21:AA:92:43:39:E8:FC:5F:61:0C:D9:3E:F9:
28:1D:9A:1C:35:25:58:08:0C:DB:8E:D5:07:36:CD:E4:D5:1E:30:2A:
61:FE:20:AB:DF:98:C0:55:C5:F6:6E:B8:8B:32:42:D4:D5:9A:58:44:
E5:EB:5A:FB:B6:06:E9:1E:B2:0A:F6:D1:FC:64:B1:F9:68:DF:55:06:
D3:70:DB:13:35:99:FF:2B:6C:42:8C:D0:1D:C7:D6:3A:BC:55:04:08:
0A:7D:1D:6A:EF:D6:70:32:BB:A4:B5:D3:2A:62:2E:1A:1C:F9:D4:B4:
B6:87:4E:FF:F8:C3:96:3E:09:2A:86:4C:41:F3:2B:9E:AA:AE:07:0D:
98:A4:EA:D4:5F:5F:E3:CC:DF:42:1F:79:FF:F7:B6:77:DF:09:BF:38:
74:6F:1B:18:D0:48:BF:61:02:DC:25:7A:CE:6D:91:79:06:4B:A2:02:
28:85:A4:D3:7A:21:79:80:31:6C:98:B9:6F:E2:94:BA:CB:AB:A9:03:
6A:A8:17:3F:26:4B:91:42:E0:5C:53:6E:B2:D3:99:63:24:04:FD:32:
3A:FF:2D:48:A5:B5:D4:89:B9:DD:D5:FC:FA:15:5E:1D:35:06:C0:46:
F6:C7:CE:0F:B7:4E:1F:38:F2:5E:A5:46:8E:1C:7C:9C[
もう一つNFS関連で試そうと思って試していなかったこととしてNFSのセッショントランク/マルチパス(pNFSと勘違いしていた)もあったので、どうせならこれも試してみようと思い今回以下のものを試してみました。
・IPoIB NFS
・IPoIB NFS マルチパス
・NFSoRDMAマルチパス
検証環境について
今回の検証環境は以下となります
NFSサーバ
OS周り
root@debian:~# uname -a
Linux debian 6.1.0-28-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.119-1 (2024-11-22) x86_64 GNU/Linux
root@debian:~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 12 (bookworm)
Release: 12
Codename: bookworm
ハードウェア周り
X11SPW-TF
CPU:Intel(R) Xeon(R) Gold 6138 CPU @ 2.00GHz 1ソケット
RAM:DDR4 2400 64GB LRDIMM *4 (256GB)
IB HCA;MCX354A-QCBT (QDR Dual port IB HCA@PCIE 3.0 x8)
PVE01/02
OS周り
root@pve01:~# uname -a
Linux pve01 6.8.12-4-pve #1 SMP PREEMPT_DYNAMIC PMX 6.8.12-4 (2024-11-06T15:04Z) x86_64 GNU/Linux
root@pve01:~# pveversion
pve-manager/8.3.1/fb48e850ef9dde27 (running kernel: 6.8.12-4-pve)
ハードウェア周り
JGINYUE B650I NIGHT DEVIL
CPU:16 x AMD Ryzen 7 7700 8-Core Processor (1 Socket)
PVE01 RAM:DDR5 4800 16GB*2 (32GB)
PVE02 RAM:DDR5 4800 8GB*2 (16GB)
IB HCA:MCB194A-FCAT (Connect-IB FDR Dual port HCA@PCIE 3.0x16)
スイッチ
Mellanox SX6036
今回はIBの最大性能を見たいため、NFSサーバはtmpfsなどのオンメモリなファイルシステムを使っても余裕のあるマシンということでLRDIMMが使えるマシンにしました。シングルスレッドの性能的に若干不安がありますが、RDMAが有効ならCPUの性能がなくても十分な性能を発揮するはずです。HCAについては本来はこちらも MCB194A-FCATを使いたかったのですが、拡張スロットにx16がない(エッジレスx8スロットもない)のとそもそも在庫がないのでCX354Aを使っています。
QDRが40Gbpsの8b/10b税を払うと32Gbpsとなり、2ポート合計の実効が64GbpsなのでPCIE3.0 x8の帯域ぴったりになりますが、オーバーヘッドを考えると若干足りてない気がします。そのため、とりあえず効果があるかを確認するためにシングルポートQDR以上の帯域が出れば良いことにします。
ちなみにFDRでリンクしたい場合、ケーブルもFDR対応のものを使わないとQDRになってしまうようです。手持ちのケーブルだと直結してもFDRにはなりませんでした。以前無駄にハマりました。
そこに接続するマシンはシングルスレッドの性能がほしいため、デスクトップ向けのCPUを搭載したマシンを使っています。今回はAliExpressで何故か安く出ていて買ってしまったRyzen 7 7700を搭載したマシンを2台用意しています。マザボも同じくAliで安く出ていた JGINYUE B650I NIGHT DEVIL というITXの板を利用しています。2台とも石、板、箱がAE調達というAEビルドマシンです。板のメーカーについては全く未知ですが、なにげにあとから9000系の対応BIOSを出しているなど、ある程度やる気はあるようで、今のところ素直に動いています。
前提条件
OSのインストールなどが終わり普通に使える状態で、どこかでOpenSMなどのサブネットマネージャが動いていて、リンクが上がっていることとします
root@pve01:~# apt install ibutils
root@pve01:~# ibstat
CA 'mlx5_0'
CA type: MT4113
Number of ports: 2
Firmware version: 10.14.2066
Hardware version: 0
Node GUID: 0x5849560e5cbc0401
System image GUID: 0x5849560e5cbc0401
Port 1:
State: Active
Physical state: LinkUp
Rate: 40
Base lid: 19
LMC: 0
SM lid: 1
Capability mask: 0x26516848
Port GUID: 0x5849560e5cbc0401
Link layer: InfiniBand
Port 2:
State: Active
Physical state: LinkUp
Rate: 40
Base lid: 20
LMC: 0
SM lid: 1
Capability mask: 0x26516848
Port GUID: 0x5849560e5cbc0409
Link layer: InfiniBand
NFSサーバの準備
そのままではipoibが使えないので、ib_ipoibモジュールを読み込みibp~というリンクが生えていることを確認します。検証環境のためIP体系が変ですが、通常は192.168.1.0/24、192.168.2.0/24～とかで大丈夫です。
root@debian:~# ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether ac:1f:6b:bd:03:30 brd ff:ff:ff:ff:ff:ff
altname enp25s0f0
3: eno2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether ac:1f:6b:bd:03:31 brd ff:ff:ff:ff:ff:ff
altname enp25s0f1
root@debian:~# modprobe ib_ipoib
root@debian:~# ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether ac:1f:6b:bd:03:30 brd ff:ff:ff:ff:ff:ff
altname enp25s0f0
3: eno2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether ac:1f:6b:bd:03:31 brd ff:ff:ff:ff:ff:ff
altname enp25s0f1
4: ibp179s0: <BROADCAST,MULTICAST> mtu 4092 qdisc noop state DOWN mode DEFAULT group default qlen 256
link/infiniband 80:00:02:08:fe:80:00:00:00:00:00:00:e4:1d:2d:03:00:49:2c:61 brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
5: ibp179s0d1: <BROADCAST,MULTICAST> mtu 4092 qdisc noop state DOWN mode DEFAULT group default qlen 256
link/infiniband 80:00:02:09:fe:80:00:00:00:00:00:00:e4:1d:2d:03:00:49:2c:62 brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
まずNFSサーバ側に生えたIFにIPを割り振ります。例として 10.111.1.200/24と 10.111.2.200/24を割り振ります。IBはVLANなどの概念はないので同一スイッチの同一サブネット上に2つのIP系ができることになります。IBにもPartitionというものがあるものの、あくまでマルチパスを貼るための都合上の2つのIP体系なので問題ないです。
root@debian:~# ip a add dev ibp179s0 10.111.1.200/24
root@debian:~# ip a add dev ibp179s0d1 10.111.2.200/24
root@debian:~# ip l se up ibp179s0
root@debian:~# ip l se up ibp179s0d1
次にtmpfsでNFSベンチマーク用のオンメモリディレクトリを作成します。今回はRAM領域を240GB作成しています。
root@debian:~# mkdir /exports
root@debian:~# mount -t tmpfs -o size=240G tmpfs /exports/
root@debian:~# mount|grep exports
tmpfs on /exports type tmpfs (rw,relatime,size=251658240k,inode64)
RAM上のFIOベンチマーク
NFSでマウントされる前に、まずはサーバ上での上限を確認します。
root@debian:~# cd /exports/
root@debian:/exports# fio --name=fiotest --ioengine=io_uring --iodepth=1 --time_based --runtime=10 --rw=randread --bs=8k --size=1G --numjobs=1 --group_reporting
bw ( MiB/s): min= 3063, max= 3208, per=100.00%, avg=3187.67, stdev=31.30, samples=19
iops : min=392128, max=410708, avg=408021.58, stdev=4006.29, samples=19
root@debian:/exports# fio --name=fiotest --ioengine=io_uring --iodepth=8 --time_based --runtime=10 --rw=randread --bs=8k --size=1G --numjobs=8 --group_reporting
bw ( MiB/s): min=18787, max=22317, per=100.00%, avg=22060.57, stdev=119.99, samples=152
iops : min=2404778, max=2856698, avg=2823753.89, stdev=15358.64, samples=152
root@debian:/exports# fio --name=fiotest --ioengine=io_uring --iodepth=1 --time_based --runtime=10 --rw=randwrite --bs=8k --size=1G --numjobs=1 --group_reporting
bw ( MiB/s): min= 1726, max= 3838, per=100.00%, avg=2622.56, stdev=1016.40, samples=19
iops : min=221000, max=491292, avg=335687.05, stdev=130099.60, samples=19
root@debian:/exports# fio --name=fiotest --ioengine=io_uring --iodepth=8 --time_based --runtime=10 --rw=randwrite --bs=8k --size=1G --numjobs=8 --group_reporting
bw ( MiB/s): min=11517, max=16850, per=100.00%, avg=14898.87, stdev=168.53, samples=152
iops : min=1474194, max=2156870, avg=1907055.58, stdev=21572.48, samples=152
RAM上ではO_DIRECTがないので(当然)direct=1を外していますが、Q1T1だとRandRead408K IOPS、RandWrite335K IOPSで、Q8T8だとRandRead2.8M IOPS、RandWrite1.9M IOPSでした。
exportsの設定
作成した/exportをNFSの領域に設定します。検証なので*で雑に設定しています。マルチパスを使いたいのでNFS4のオプションである fsid=0にて、/exportsの下をNFSクライアントから見た/(ルートディレクトリ)とします。その下にNFSクライアントからみた/nfs1となるnfs1ディレクトリを作成します。
root@debian:~# echo '/exports *(fsid=0,rw,insecure,no_root_squash,no_subtree_check)' >> /etc/exports
root@debian:~# mkdir /exports/nfs1
root@debian:~# exportfs -avr
exporting *:/exports
PVE側のNFSの設定
ipoibを読み込ませる以外は普通と同じです。ipoibを読み込ませるとNICがリンク一覧に出てくるので、そこからIPを設定します。ipコマンドから同じように設定することもできますが、ipコマンドの設定だとWebUIから設定を変更したタイミングで揮発するのでWebUIを正としたほうが無難です。再起動時にipoibを読み込ませたい場合は/etc/modulesに追記しておきます
root@pve01:~# modprobe ib_ipoib
root@pve01:~# echo ib_ipoib>>/etc/modules
IFが生えたらIPとサブネットだけ設定します。
その後、NFSの設定をします。ただのNFSであればvers=3でよいですが、このあとマルチパスを使いたいので4.2を指定します。PVE特有の話ではなくLinuxでの話になりますが、fsid=0を指定するとNFS3と4でルートディレクトリの始まりが変わるので注意が必要です。(ちなみに上記設定でv3を使う場合は/export/nfs1になります。)
IPoIB上のNFSのベンチマーク
VMを経由せず、まずはマウントしたクライアントから直接fioを実行して性能を確認します
# read
root@pve01:/mnt/pve/rdma# fio --name=fiotest --ioengine=io_uring --iodepth=1 --time_based --runtime=10 --rw=randread --bs=8k --size=1G --numjobs=1 --group_reporting
bw ( KiB/s): min=69104, max=89968, per=100.00%, avg=84469.05, stdev=3966.55, samples=19
iops : min= 8638, max=11246, avg=10558.63, stdev=495.82, samples=19
root@pve01:/mnt/pve/rdma# fio --name=fiotest --ioengine=io_uring --iodepth=8 --time_based --runtime=10 --rw=randread --bs=8k --size=1G --numjobs=8 --group_reporting
bw ( KiB/s): min=135712, max=190992, per=100.00%, avg=165444.00, stdev=1502.60, samples=160
iops : min=16964, max=23874, avg=20680.50, stdev=187.83, samples=160
root@pve01:/mnt/pve/rdma# fio --name=fiotest --ioengine=io_uring --iodepth=8 --time_based --runtime=10 --rw=randread --bs=1M --size=1G --numjobs=8 --group_reporting
bw ( KiB/s): min=305152, max=432128, per=100.00%, avg=371507.20, stdev=3970.09, samples=160
iops : min= 298, max= 422, avg=362.80, stdev= 3.88, samples=160
#write
root@pve01:/mnt/pve/rdma# fio --name=fiotest --ioengine=io_uring --iodepth=1 --time_based --runtime=10 --rw=randwrite --bs=8k --size=1G --numjobs=1 --group_reporting
bw ( KiB/s): min= 16, max=1170816, per=100.00%, avg=559240.53, stdev=486898.18, samples=15
iops : min= 2, max=146352, avg=69905.07, stdev=60862.27, samples=15
root@pve01:/mnt/pve/rdma# fio --name=fiotest --ioengine=io_uring --iodepth=8 --time_based --runtime=10 --rw=randwrite --bs=8k --size=1G --numjobs=8 --group_reporting
bw ( MiB/s): min= 82, max=13513, per=95.40%, avg=3327.49, stdev=630.16, samples=155
iops : min=10592, max=1729712, avg=425919.08, stdev=80659.95, samples=155
root@pve01:/mnt/pve/rdma# fio --name=fiotest --ioengine=io_uring --iodepth=8 --time_based --runtime=10 --rw=randwrite --bs=1M --size=1G --numjobs=8 --group_reporting
bw ( MiB/s): min= 316, max=16376, per=95.07%, avg=3116.83, stdev=768.83, samples=156
iops : min= 316, max=16376, avg=3116.83, stdev=768.83, samples=156
表にまとめると以下です。
| IOPS avg | BW avg (MiByte/s) | BW avg in Gbps | |
| IPoIB single randreadQ1T1 8k | 10558 | 80.5 | 0.675283105 |
| IPoIB single randreadQ8T8 8k | 20680 | 161.5 | 1.354760515 |
| IPoIB single randreadQ8T8 1M | 362 | 354.3 | 2.972084523 |
| IPoIB single randwriteQ1T1 8k | 69905 | 546.1 | 4.581019921 |
| IPoIB single randwriteQ8T8 8k | 425919 | 3327.4 | 27.91226091 |
| IPoIB single randwriteQ8T8 1M | 3116 | 3116.8 | 26.14561965 |
Readに対してWriteおかしくない?????????と思いましたが、何回試してもこの数字でした。atopの通信帯域を見ていましたが、こちらはなぜか16Gbps以上カウントされませんでした。async writeみたいな動きをしていますが、それならreadももっと上がってもいいような気がします。thinking_faceみたいになりながら色々見ましたが何もわからん…IPoIB特有の動きでしょうか…
マルチパスを試す
NFSのマルチパスについて探し方が悪いのかLinuxでの情報がほんとに見つかりませんでしたが、動きを見ているとmax_connectを指定したあと違うIPの同じExportsを違うディレクトリにマウントすると有効化されるようでした。
https://thinksystem.lenovofiles.com/storage/help/index.jsp?topic=%2Fontap_nfs-trunking%2Fclient-mount-task.html&cp=1_14_3_5_3_1_3
NFSサーバ側で/export/nfs1と/export/nfs2を作り、PVEからマウントします。先程と同様/exportにfsid0が指定されているのでPVEの設定に落とすと以下になります。ストレージの設定をWebUIから変えてもoptions以下の内容は変更されないので、contentをISOやContainerなどに変更しても都度optionsの書き直しは不要でした。
nfs: rdma
export /nfs1
path /mnt/pve/rdma
server 10.111.1.200
content images
options vers=4.2,max_connect=2
prune-backups keep-all=1
nfs: rdma2
export /nfs1
path /mnt/pve/rdma2
server 10.111.2.200
content images
options vers=4.2,max_connect=2
prune-backups keep-all=1
その後、データストアを無効化し、アンマウントしたあとに再度有効化すると新しい設定が入るようでした。すぐに入らないので少し待つ必要がありました
root@pve01:~# pvesm set rdma2 --disable 1
root@pve01:~# pvesm set rdma --disable 1
root@pve01:~# umount /mnt/pve/rdma
root@pve01:~# umount /mnt/pve/rdma2
root@pve01:~# pvesm set rdma2 --disable 0
root@pve01:~# pvesm set rdma --disable 0
成功すると違うマウントを指定したはずなのに同じIPでマウントされます。この状態が本当にあっているのかわかりませんが、少なくともatopなどでNICの利用状況を見ていると一つのディレクトリに対する操作を行ったときにそれぞれのNICで通信が発生していました。なんか…違う気がする…
root@pve01:~# mount|grep nfs
10.111.2.200:/nfs1 on /mnt/pve/rdma2 type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,max_connect=2,timeo=600,retrans=2,sec=sys,clientaddr=10.111.2.201,local_lock=none,addr=10.111.2.200)
10.111.2.200:/nfs1 on /mnt/pve/rdma type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,max_connect=2,timeo=600,retrans=2,sec=sys,clientaddr=10.111.2.201,local_lock=none,addr=10.111.2.200
とりあえずベンチを回して差が出たか確認します。
### nfs multipath
# read
root@pve01:/mnt/pve/rdma# fio --name=fiotest --ioengine=io_uring --iodepth=1 --time_based --runtime=10 --rw=randread --bs=8k --size=1G --numjobs=1 --group_reporting
bw ( KiB/s): min=70656, max=86496, per=100.00%, avg=82204.63, stdev=3661.31, samples=19
iops : min= 8832, max=10812, avg=10275.58, stdev=457.66, samples=19
root@pve01:/mnt/pve/rdma# fio --name=fiotest --ioengine=io_uring --iodepth=8 --time_based --runtime=10 --rw=randread --bs=8k --size=1G --numjobs=8 --group_reporting
bw ( KiB/s): min=249520, max=474544, per=99.54%, avg=393720.42, stdev=5737.21, samples=152
iops : min=31190, max=59318, avg=49215.05, stdev=717.15, samples=152
root@pve01:/mnt/pve/rdma# fio --name=fiotest --ioengine=io_uring --iodepth=1 --time_based --runtime=10 --rw=randread --bs=1M --size=1G --numjobs=8 --group_reporting
bw ( KiB/s): min=550912, max=1323008, per=100.00%, avg=808895.33, stdev=20944.35, samples=158
iops : min= 538, max= 1292, avg=789.94, stdev=20.45, samples=158
#write
root@pve01:/mnt/pve/rdma# fio --name=fiotest --ioengine=io_uring --iodepth=1 --time_based --runtime=10 --rw=randwrite --bs=8k --size=1G --numjobs=1 --group_reporting
bw ( KiB/s): min= 32, max=1161296, per=100.00%, avg=616809.41, stdev=469939.92, samples=17
iops : min= 4, max=145162, avg=77101.18, stdev=58742.49, samples=17
root@pve01:/mnt/pve/rdma# fio --name=fiotest --ioengine=io_uring --iodepth=8 --time_based --runtime=10 --rw=randwrite --bs=8k --size=1G --numjobs=8 --group_reporting
bw ( MiB/s): min= 256, max=12827, per=100.00%, avg=4207.57, stdev=578.61, samples=149
iops : min=32824, max=1641910, avg=538569.22, stdev=74061.61, samples=149
root@pve01:/mnt/pve/rdma# fio --name=fiotest --ioengine=io_uring --iodepth=1 --time_based --runtime=10 --rw=randwrite --bs=1M --size=1G --numjobs=8 --group_reporting
bw ( MiB/s): min= 484, max=19754, per=98.44%, avg=4232.42, stdev=820.85, samples=156
iops : min= 484, max=19754, avg=4232.42, stdev=820.85, samples=156
シングルとの差分を表にまとめるとこうなります
| IOPS avg | BW avg (MiByte/s) | BW avg in Gbps | Multipath_efficiency (%) | |
| IPoIB single randreadQ1T1 8k | 10558 | 80.5 | 0.675283105 | |
| IPoIB con=2 randreadQ1T1 8k | 10275 | 80.3 | 0.673605383 | 99.7515528 |
| IPoIB single randreadQ8T8 8k | 20680 | 161.5 | 1.354760515 | |
| IPoIB con=2 randreadQ8T8 8k | 49215 | 384.5 | 3.225420545 | 238.0804954 |
| IPoIB single randreadQ8T8 1M | 362 | 354.3 | 2.972084523 | |
| IPoIB con=2 randreadQ8T8 1M | 789 | 789.9 | 6.626163039 | 222.9466554 |
| IPoIB single randwriteQ1T1 8k | 69905 | 546.1 | 4.581019921 | |
| IPoIB con=2 randwriteQ1T1 8k | 77101 | 602.3 | 5.052459803 | 110.2911555 |
| IPoIB single randwriteQ8T8 8k | 425919 | 3327.4 | 27.91226091 | |
| IPoIB con=2 randwriteQ8T8 8k | 538569 | 4207.6 | 35.29591544 | 126.4530865 |
| IPoIB single randwriteQ8T8 1M | 3116 | 3116.8 | 26.14561965 | |
| IPoIB con=2 randwriteQ8T8 1M | 4232 | 4232.4 | 35.50395296 | 135.7931211 |
相変わらず書き込みの速度だけはぶっ壊れていますが、パスが増えたことによって複数スレッドでの読み込みの速度の増加が確認できたので、マルチパスの効果はあるようです。しかしそれ以上にやはりIPoIBはなにかある気がします。もともと大して期待はしていませんでしたが、それにしても読み込みが合計80Gbpsに対して実測6Gbpsというのは悲しいです。
ただ、効果があるのは確かなので、イーサネットの場合には意味があると思います。
NFSoRDMAを検証する
IPoIBの挙動が謎すぎて時間を取られてしまいましたがようやくメインディッシュです。サーバ側に svcrdmaを、クライアント側に xprtrdmaを読み込ませ、RDMAを有効化していきます。
root@debian:~# modprobe svcrdma
root@debian:~# systemctl restart nfs-kernel-server
このままだとproto=rdmaを指定してRDMAで接続をしようとしたときに接続拒否されるので、portlistにrdmaの標準ポートである20049を追加します。
root@debian:~# cat /proc/fs/nfsd/portlist
tcp 2049
tcp 2049
root@debian:~# echo rdma 20049 > /proc/fs/nfsd/portlist
root@debian:~# cat /proc/fs/nfsd/portlist
rdma 20049
rdma 20049
tcp 2049
tcp 2049
オンザフライでの変更ではなく、設定ファイルで変更する場合は/etc/nfs.confにてrdma=yを有効にしたあとにサービスの再起動が必要になります。
# /etc/nfs.conf
[nfsd]
# debug=0
# threads=8
# host=
# port=0
# grace-time=90
# lease-time=90
# udp=n
# tcp=y
# vers3=y
# vers4=y
# vers4.0=y
# vers4.1=y
# vers4.2=y
rdma=y
rdma-port=20049
root@debian:~# systemctl restart nfs-kernel-server
root@debian:~# cat /proc/fs/nfsd/portlist
rdma 20049
rdma 20049
tcp 2049
tcp 2049
次に、PVE側の設定を行います。事前にコマンドラインからmountコマンドでproto=rdmaで接続できることは確認したので、sotrage.confに合う設定を入れます。今回はRDMAの最大速度を見たいのでいきなりマルチパスで行います
#/etc/pve/storage.cfg
nfs: rdma
export /nfs1
path /mnt/pve/rdma
server 10.111.1.200
content images
options vers=4.2,max_connect=2,proto=rdma
prune-backups keep-all=1
nfs: rdma2
export /nfs1
path /mnt/pve/rdma2
server 10.111.2.200
content images
options vers=4.2,max_connect=2,proto=rdma
prune-backups keep-all=1
root@pve01:~# modprobe xprtrdma
root@pve01:~# echo "xprtrdma" >> /etc/modules
root@pve01:~# pvesm set rdma2 --disable 1
root@pve01:~# pvesm set rdma --disable 1
root@pve01:~# umount /mnt/pve/rdma
root@pve01:~# umount /mnt/pve/rdma2
root@pve01:~# pvesm set rdma2 --disable 0
root@pve01:~# pvesm set rdma --disable 0
しばらく待ち、NFSのマウントオプションにproto=rdmaがある状態でNFSがマウントされたかを確認します。
root@pve01:~# mount|grep rdma
10.111.1.200:/nfs1 on /mnt/pve/rdma type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=rdma,max_connect=2,port=20049,timeo=600,retrans=2,sec=sys,clientaddr=10.111.1.201,local_lock=none,addr=10.111.1.200)
10.111.1.200:/nfs1 on /mnt/pve/rdma2 type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=rdma,max_connect=2,port=20049,timeo=600,retrans=2,sec=sys,clientaddr=10.111.1.201,local_lock=none,addr=10.111.1.200)
まずはPVE01で直接IOを発行してベンチマークをかけます
### nfs over RDMA
#read
root@pve01:/mnt/pve/rdma# fio --name=fiotest --ioengine=io_uring --iodepth=1 --time_based --runtime=10 --rw=randread --bs=8k --size=1G --numjobs=1 --group_reporting
bw ( KiB/s): min=106624, max=131440, per=99.95%, avg=128103.58, stdev=5284.67, samples=19
iops : min=13328, max=16430, avg=16012.95, stdev=660.58, samples=19
root@pve01:/mnt/pve/rdma# fio --name=fiotest --ioengine=io_uring --iodepth=8 --time_based --runtime=10 --rw=randread --bs=8k --size=1G --numjobs=8 --group_reporting
bw ( MiB/s): min= 1092, max= 1991, per=99.85%, avg=1828.98, stdev=30.13, samples=152
iops : min=139790, max=254956, avg=234109.58, stdev=3856.49, samples=152
root@pve01:/mnt/pve/rdma# fio --name=fiotest --ioengine=io_uring --iodepth=1 --time_based --runtime=10 --rw=randread --bs=1M --size=1G --numjobs=8 --group_reporting
bw ( MiB/s): min= 2964, max= 3824, per=99.77%, avg=3633.37, stdev=33.98, samples=152
iops : min= 2964, max= 3824, avg=3633.37, stdev=33.98, samples=152
#write
root@pve01:/mnt/pve/rdma# fio --name=fiotest --ioengine=io_uring --iodepth=1 --time_based --runtime=10 --rw=randwrite --bs=8k --size=1G --numjobs=1 --group_reporting
bw ( KiB/s): min=245120, max=1139216, per=98.00%, avg=782675.37, stdev=331891.63, samples=19
iops : min=30640, max=142402, avg=97834.42, stdev=41486.45, samples=19
root@pve01:/mnt/pve/rdma# fio --name=fiotest --ioengine=io_uring --iodepth=8 --time_based --runtime=10 --rw=randwrite --bs=8k --size=1G --numjobs=8 --group_reporting
bw ( MiB/s): min= 903, max=13740, per=100.00%, avg=5349.23, stdev=563.43, samples=158
iops : min=115650, max=1758800, avg=684700.85, stdev=72119.49, samples=158
root@pve01:/mnt/pve/rdma# fio --name=fiotest --ioengine=io_uring --iodepth=1 --time_based --runtime=10 --rw=randwrite --bs=1M --size=1G --numjobs=8 --group_reporting
bw ( MiB/s): min= 2088, max=16382, per=100.00%, avg=6476.16, stdev=562.35, samples=158
iops : min= 2088, max=16382, avg=6476.16, stdev=562.35, samples=158
IPoIBマルチパスとの比較を表にまとめます
| IOPS avg | BW avg (MiByte/s) | BW avg in Gbps | RDMA_efficiency (%) | |
| IPoIB single randreadQ1T1 8k | 10558 | 80.5 | 0.675283105 | |
| IPoIB con=2 randreadQ1T1 8k | 10275 | 80.3 | 0.673605383 | |
| RDMA con=2 randwriteQ1T1 8k | 16012 | 128.103 | 1.074606107 | 159.5305106 |
| IPoIB single randreadQ8T8 8k | 20680 | 161.5 | 1.354760515 | |
| IPoIB con=2 randreadQ8T8 8k | 49215 | 384.5 | 3.225420545 | |
| RDMA con=2 randwriteQ8T8 8k | 234109 | 1828.98 | 15.34259992 | 475.6775033 |
| IPoIB single randreadQ8T8 1M | 362 | 354.3 | 2.972084523 | |
| IPoIB con=2 randreadQ8T8 1M | 789 | 789.9 | 6.626163039 | |
| RDMA con=2 randwriteQ8T8 1M | 3633 | 3633.3 | 30.47833671 | 459.9696164 |
| IPoIB single randwriteQ1T1 8k | 69905 | 546.1 | 4.581019921 | |
| IPoIB con=2 randwriteQ1T1 8k | 77101 | 602.3 | 5.052459803 | |
| RDMA con=2 randreadQ1T1 8k | 97834 | 782.675 | 6.565555332 | 129.9477005 |
| IPoIB single randwriteQ8T8 8k | 425919 | 3327.4 | 27.91226091 | |
| IPoIB con=2 randwriteQ8T8 8k | 538569 | 4207.6 | 35.29591544 | |
| RDMA con=2 randreadQ8T8 8k | 684700 | 5349.23 | 44.87260427 | 127.1325696 |
| IPoIB single randwriteQ8T8 1M | 3116 | 3116.8 | 26.14561965 | |
| IPoIB con=2 randwriteQ8T8 1M | 4232 | 4232.4 | 35.50395296 | |
| RDMA con=2 randreadQ8T8 1M | 6476 | 6476 | 54.32463836 | 153.0101125 |
ReadQ1T1がもう一声欲しいですが、サーバ側のatopを見ていると1コアのCPU使用率が張り付くことがあり、1セッションのIOはシングルスレッドの性能に依存するようで、サーバ側の限界かもしれません。それ以外は圧倒的に速いです。特に弱かったReadが増強され、Q8T8においては200k IOPSを達成できました。Writeの速度に関しては54Gbpsを記録しました。NFSでこれだけの性能が出たら十分すぎます。
VMを立てて検証してみる
RDMAなストレージが十分に速いことが確認できたら、その上でWindowsVMを立てて実際に速いのか試してみます。Windowsのセットアップの注意点としては、VirtIOを使わないと性能が出ないためSCSIコントローラにVirtIO SCSI Singleを選択する必要があります。また、それに伴いOSインストール時にドライバの読み込みが必要になるので、virtio-driverの入ったISOをマウントするために2つ目のCDROMが必要になります。SATAでセットアップしてから後でVirtIOに変更することもできますが、トラブルを防ぐため正攻法でセットアップしました。
上記の設定をしてインストールを進めていく中で、まず速度の差を実感しました。Win11のセットアップは時間がかかりますが、明らかに速いです。もっとも、これはRyzen 7 7700が速いという気もしますが、IOがネックになっていないというのも大きいと思います。
なんやかんやしてWindowsのセットアップが終わったら、いつものCDMをまわします。以下がその結果で、それぞれMiB/sとIOPSです。
Q1T1については4kで12k IOPSが出ているのでfioのテスト結果と一致しますが、fioで8Q8Tを実行したときには234k IOPSが出ているのに対してVM上では174k IOPSと、いい線いっていますがもう少し出てもいいかと思いました。
帯域についてはQDRの理論上限値32Gbpsで、MB/sに直すと4000MB/sとなり、マルチパスがうまく使えてない気もします。ただ、perfqueryやatopのIBリンクの情報を見ていると、両ポートでパケットの送受信は行われているようです。複数ディスクでのIOが発生したらまた違うのかもしれません。
Writeについては値がぶっ壊れることもなかったので、fioのテスト方法が正しくなかったか、上記のマルチパスがうまく使えていないという問題がある気がします。
virtioの上限についてはPVEホストにtmpfsを作成してVMからRAM上に作成したドライブにベンチマークをした限りはもっと高い値が出たので、何かしらチューニングがあるのかもしれないですが、ぱっと検証した限りはUnsafe WBを使う以外の方法ではこれが限界でした。
ちなみに今回初めてRyzen 7 7700をVMホストとして使いましたが、やっぱりレスポンスがいいので PassMark PerformanceTest をまわしてシングルスレッドの性能を見てみましたが、VMでも4k超えとかなり調子が良いことがわかりました。
ちなみにPassmarkのシングルスレッドの数値と個人的なWindowsを使う感覚としては
～700 なにするのもつらい
1000～1500 もたつくがIOが十分に速ければコア数によってはなんとか使える
1500～2400 IOが速ければそれなりに使える
2400～3000 はやい
3000～4000 目に見えて速い
4000～ 新世界
という感じです。
AMDのCPUの場合、95度に張り付くまでカツカツを攻めるという動きをするので、ついているCPUクーラーと外気温によって大きくスコアが変わるのですが、同じ状態でWindowsをベアインストールして試していたときは4100-4200くらいだったと思います。
なので、多少の仮想化税はありますが、それでも十分速いと思います。ちなみにこのITXの筐体にはAXP90-X47 FULLというFull copperなクーラーを使っています。もともと先に組んだPVE02の筐体に組み込もうとしたのですがクーラーの高さが僅かに高く、箱に入り切らずSHURIKEN 3を買うことに…。
マイグレーションを試してみる
もう一つ気になることとして、PVEでライブマイグレーションをするために正しく共有ストレージとして認識されているか、RAM転送でIBを使うように設定してうまくいくのか、というのがあったので試してみました。ようやくPVE02の出番です。
基本的には01と同じ設定を行い、01側でクラスターを作成して02を参加させました。クラスターを作成するときに、裏LANがあるとそれを追加できるので、IPoIBのインターフェースも追加します。画像では0,1がIBで2がEtherですが、これは数値が高いほうが優先されるという動きになるので、これで作ったあとに間違いに気が付き10.111.1.201を20、10.111.2.201を10、172.20.1.51を1に変えました。
参加した段階でproto=rdmaが書かれたstorage.cfgが02側にも配布されるので、xprtrdmaが読み込まれていれば参加した時点でNFSのRDMAマウントができていました。
ここでハマったのが何故か1G Etherを使ってRAMの転送を行ってしまいIBが使われず困ったのですが、Datacenter→OptionsにMigration settingsという項目があり、どのIPを使うか指定する必要がありました。これをIBの裏LANアドレスを指定することにより、IPoIBですがIBが使われるようになりました。
2024-12-08 04:38:18 use dedicated network address for sending migration traffic (10.111.1.202)
2024-12-08 04:38:18 starting migration of VM 101 to node 'pve02' (10.111.1.202)
2024-12-08 04:38:18 starting VM 101 on remote node 'pve02'
2024-12-08 04:38:19 start remote tunnel
2024-12-08 04:38:20 ssh tunnel ver 1
2024-12-08 04:38:20 starting online/live migration on unix:/run/qemu-server/101.migrate
2024-12-08 04:38:20 set migration capabilities
2024-12-08 04:38:20 migration downtime limit: 100 ms
2024-12-08 04:38:20 migration cachesize: 1.0 GiB
2024-12-08 04:38:20 set migration parameters
2024-12-08 04:38:20 start migrate command to unix:/run/qemu-server/101.migrate
2024-12-08 04:38:21 migration active, transferred 656.7 MiB of 8.0 GiB VM-state, 813.8 MiB/s
2024-12-08 04:38:22 migration active, transferred 1.4 GiB of 8.0 GiB VM-state, 801.0 MiB/s
2024-12-08 04:38:23 migration active, transferred 2.1 GiB of 8.0 GiB VM-state, 803.5 MiB/s
2024-12-08 04:38:24 migration active, transferred 2.9 GiB of 8.0 GiB VM-state, 778.9 MiB/s
2024-12-08 04:38:25 migration active, transferred 3.6 GiB of 8.0 GiB VM-state, 1.0 GiB/s
2024-12-08 04:38:26 migration active, transferred 4.3 GiB of 8.0 GiB VM-state, 783.7 MiB/s
2024-12-08 04:38:27 migration active, transferred 5.2 GiB of 8.0 GiB VM-state, 856.8 MiB/s
2024-12-08 04:38:27 xbzrle: send updates to 36484 pages in 27.2 MiB encoded memory, overflow 2013
2024-12-08 04:38:27 average migration speed: 1.1 GiB/s - downtime 86 ms
2024-12-08 04:38:27 migration status: completed
2024-12-08 04:38:30 migration finished successfully (duration 00:00:12)
TASK OK
ストレージは正しく共有と認識されたので、RAMだけの転送となりました。8GBのRAMを割り当てたWindowsをマイグレしたところ大体10GbpsくらいでRAMの転送がされ、12秒で終わりました。マイグレ中もあえてリモデから色々やっていましたが、一瞬マウスカーソルにラグのようなものが出たと思ったら終わっていました。はやい。
検証した感想
NFSのMPIOやRDMAなどを初めて設定しましたが、かなり良い結果がでたとおもいます。PVE自体は触り始めて1ヶ月経っていないのでお作法的な部分がまだよくわかっていないですが、中身がDebianという15年の付き合いのあるOSなので個人的には非常に取り掛かりやすいです。
PVEはVMwareとは違ってハードウェアの対応の広さや、困ってもLinux的に色々とどうにかできるのが良いと思いました。それ以外にもHAレプリケーションやVMwareでいうVDPがより使いやすいPBSとして提供されているなど、非常によくできていると感じました。
PVE自体にvSAN的なCephもあり、今更ストレージとコンピュートノードを分けるなや!!時代はHCIやで!!! という思想も感じますが、小さいマシンだとIOスロット数の問題やOSD自体のIOコンピュートコストが馬鹿にできないこともあり、できればIOを分けてホストはVM/Containerの処理に専念させたい、ということもあります。
合計100コア以上のXeonSP/EPYCと数TBのRAMと有り余るSSDと100GbEを搭載したマシンが10台以上ある、というような構成ならともかく、家で使うときにはSPoFができることを承知で ストレージはストレージマシンにまとめ、 IBと10Gと起動用SATA DOMに相当するものを積んでおけばとりあえず快適に使える、というのは便利です。
ノードごとにNVMEストレージを揃えたくないという気持ちがあったので、IBさえ繋いでおけばSATA SSDより速い大容量な集約ストレージが使えることになり、これを解決できたのは個人的にかなり大きいです。
また、特にWindowsなどの検証をするとIOの速さが利用度の快適さに直結するので、IOの速さというのは譲れない要件でもあります。ストレージマシンが死ぬと地獄を見るというのは回避できませんが、クラスター型ストレージが死なないかと言われるとまたそれも微妙なところで、メタデータに問題が起きるとこれも地獄になります。
そういった面で問題が起きたときにシンプルさが強さになることもあります。
共有ブロックストレージ+クラスター型ファイルシステムではなく、NFSというファイルベースストレージなのもシンプルでよいです。色々トラブルを踏むとシンプルさに帰結する気がします。
代償としてNFSは細かいIOが苦手、というのがありますが、今回のRDMAの結果からすると十分実用域だと思います。
ただ、散々IBについて話してきましたが、今からお家でInfinibandをおすすめできるか、というと、微妙…むしろやめといたほうが無難、と言わざるを得ないです。
以前も書いたように、IB自体はL2で使う限りはスイッチやHCA含め、帯域に対しての消費電力がかなり低いのでいい面があるのですが、IBはIBでありイーサネットではないので、利用できる用途がかなり限られます。自分もほぼストレージ用インターフェースとしてしか使っていません。
やはり用途が限られるのとIB特有の必要な知識があまり表面に出てこないので、IBまわりは本当に需要がなく、国内外で捨て値で売られています。今回検証に使ったスイッチのSX6036なんて3000円で買っています。元が底値で買っているので、仮にこれから一から揃えるとしても、万が一手放すときには再販価値はない、という前提になります。
まあ16/32Gb FC-SANを始めたいと思うのであればそれよりも安価ですが、FC-SANはドライバさえあれば確実にブロックデバイスとして認識できるというメリットもあります。あまりにもコアなメリットですが特定のときに刺さります。
しかし、再販価値がない前提で物が底値で手に入るというのは、わかっているオタクからすると二束三文で高速IOを手に入れられるというメリットでもあります。「もうIBやめたい」と思いながらも物が安いので抜け出せず、なんだかんだ物が増えてしまいました。
その中で「一部のSASケーブルはIBのQSFPケーブルとしても使える(※ただしQDRのみ)」というしょうもない知識を手に入れたので、ケーブルなどもかなり安く手に入れられるようになりました。一度嵌ると抜け出せない沼です。
総評としては、「確かにIBとRDMAはかなり高速でこれに依存すればノードの構成が楽になるものの、これを目当てに新規でIB一式を揃えようとするのは覚悟が必要になるので手放しでお薦めはできない」でしょうか。
もう少し使ってみたうえで問題が起きたらまた記事にしようと思います。
以上!
[ コメントを書く ] ( 205 回表示 ) | このエントリーのURL |
( 2.5 / 131 ) | ツイート
Windowsのリモートデスクトップですが、実はマルチモニター環境で特定の画面だけにまたがって全画面表示する、という機能があります。この機能を使ってとあるVMで作業するときに「1枚の全画面だと微妙に使いにくいけどマルチモニタすべての画面をリモデに使いたくない」という要件を満たすべく2枚の画面だけを使うようにしていました。
https://www.hanselman.com/blog/how-to-remote-desktop-fullscreen-rdp-with-just-some-of-your-multiple-monitors
https://qiita.com/yusuke-sasaki/items/5f70dc266caf13021838
先に結論を書くと、 RDPで複数画面が使えない!というときは、使いたいディスプレイ同士が0pxで隣接しているかを確認する必要があります。以下、検証のメモです。
実際のモニターのセットアップはこうなっています。グラボの出力順を考慮していないのでぐちゃぐちゃになっていますが、この中から5,6を使ってRDPを全画面表示する、ということをしていました。
今までこれは動いていたのですが、モニターのつながっているグラボの出力端子を入れ替えたタイミングで画面をまたがっての表示が動かなくなってしまいました。
mstsc /lで調べてみると、端子が入れ替わったことによってモニターのIDが変わっていたので、IDを確認してrdpファイルに書かれている順番を入れ替えれば動くだろう、と思いました。しかし、若干の移動はあったもののIDは大きく変わっておらず、何をやってもモニタをまたがって全画面表示ができずプライマリモニタだけ全画面で表示される挙動を示しました。よくわからないので一度マシンを再起動し、もう一度mstsc /lをすると今度は何故かモニターIDが大きく変わっていた(1,3,10,11,12,13から0,1,2,3,4,5になっていた)のですが、それを直しても動かず、色々検証すると下記設定の赤字0,2の2画面表示と2,4及び5,3の2画面表示は問題なく動き、なぜか2,4,5,や4,5と横一列にしようとしたときに5を含むと動かなくなるということがわかりました。
検証に使った最低限の要素だけ含めたrdpファイルは以下になります。
## NG ##
full address:s:VM1
use multimon:i:1
selectedmonitors:s:4,5
dynamic resolution:i:0
## OK ##
full address:s:VM1
use multimon:i:1
selectedmonitors:s:0,2
dynamic resolution:i:0
プライマリモニタがRX7900XTXにつながっていることもあり、最初はRadeon仕草かと思いましたが、
mstsc /lの値をよく見るとmstsc側ID(画像赤文字)の5の起点座標がおかしい事に気が付きました。この場合、0,0から3839,2159が4の値なので5が3840から始まらないといけないのですが、なぜか3853となっており、赤字4と5の間に13ピクセルの隙間があるいうことがわかりました。カッコ内部の値はそれぞれプライマリモニタ(この場合は赤字の4)の左上を0,0として右下に向けて座標がプラスになり、プライマリモニタより左にモニタがあればxはマイナスに、プライマリモニタより上にモニタあればyがマイナスになります。
Windowsの仕様として隣り合うモニタ同士はどこかでくっついていないといけないのですが、赤字5は赤字3とくっついているという扱いになり、4と5は13ピクセル離れている、という認識になっているようです。出力端子を入れ替えたのがちょうど赤字の5にあたるものだったのですが、Windowsで画面の位置を移動したときにそれがズレたようです。わかるかそんなモノ…。
離れてるのであればマウスの移動もできないのではと思いましたが、ある程度の加速度があると多少の隙間を乗り越えて隣のモニタに行けるようです。逆に、隙間があるととてもゆっくりマウスを動かしてモニタの境界線をまたごうとするとブロックされます。密着しているとマウスカーソルの加速度が1px/sでも境界をまたげるようです。たまに感じた違和感はこれだったのか…。
ディスプレイのスナッピングとの格闘の末、最終的に一回り小さい赤字の1以外は0pxで整列できたのですが、どうしても最後の1つが完全密着になりませんでした。1の値は1279,ｰ1440,3840,ｰ1になるべきなのですが、Windowsのディスプレイ設定は2辺と隣り合うことを想定していないのか、赤字の3の左辺、もしくは4の上辺のどちらかにしかスナップせず、逆にどちらかにスナップすると絶対にもう一方は合わないという動きをしていました。
ただ、赤字の0,2,4,5の横一列は整列されたので、当初赤字4,5の2画面でリモデが使えないという問題は解決しました。現状、赤字の1,3を使って画面をまたいでリモデをする、ということができませんが、このパターンはないと思うので諦めました…。座標を使ってディスプレイの場所を指定できる方法があればいいんですが…。
変な環境でディスプレイを出力していてRDPで複数画面が使えない!というときは、使いたいディスプレイ同士が0pxで隣接しているかを確認する必要がある、という、ほんとに使い所のないナレッジを得たのでここに供養します。
追記:
その後またディスプレイポートの差し替えがありスナッピングと格闘していましたが、それを便利にするDPEditというツールがあるのを知りました。
DPEdit -A simple Windows command line utility to accurately set the relative position of displays in a dual- or multi-monitor setup -
dpedit /L でつながっているディスプレイ一覧を取得できます。
dpedit /L
Display #5
Device name: \\.\DISPLAY5
Device string: AMD Radeon RX 7900 XTX
Active: 1
Mirroring: 0
Modes pruned: 0
Primary: 0
Removable: 0
VGA compatible: 0
Dimensions: {3840, 2160}
Position: {3840, 0}
Display #6
Device name: \\.\DISPLAY6
Device string: AMD Radeon RX 7900 XTX
Active: 1
Mirroring: 0
Modes pruned: 0
Primary: 4
Removable: 0
VGA compatible: 0
Dimensions: {3840, 2160}
Position: {0, 0}
Display #10
Device name: \\.\DISPLAY10
Device string: NVIDIA Quadro M2000
Active: 1
Mirroring: 0
Modes pruned: 0
Primary: 0
Removable: 0
VGA compatible: 0
Dimensions: {3840, 2160}
Position: {-7680, 0}
Display #11
Device name: \\.\DISPLAY11
Device string: NVIDIA Quadro M2000
Active: 1
Mirroring: 0
Modes pruned: 0
Primary: 0
Removable: 0
VGA compatible: 0
Dimensions: {2560, 1440}
Position: {1280, -1440}
Display #12
Device name: \\.\DISPLAY12
Device string: NVIDIA Quadro M2000
Active: 1
Mirroring: 0
Modes pruned: 0
Primary: 0
Removable: 0
VGA compatible: 0
Dimensions: {3840, 2160}
Position: {-3840, 0}
Display #13
Device name: \\.\DISPLAY13
Device string: NVIDIA Quadro M2000
Active: 1
Mirroring: 0
Modes pruned: 0
Primary: 0
Removable: 0
VGA compatible: 0
Dimensions: {3840, 2160}
Position: {3840, -2160}
dpedit ［ディスプレイ番号] [x座標] [y座標] でディスプレイを一つづつ、もしくは複数指定して配置を指定できます。上記の内容を5,6,10,11,12,13の順で一発で指定しようとすると以下のようになりますdpedit 5 3840 0 6 0 0 10 -7680 0 11 1280 -1440 12 -3840 0 13 3840 -2160
複雑な配置を行っている場合にピクセルパーフェクトで配置できずにツラミを感じている人は他にもいるようなので、そのうちPowerToysに入るかもしれません
Fine-tune multi-monitor positioning tool #2652 - microsoft / PowerToys -
いずれにしても、これで不毛なイラつきがなくなったのでまた一つPCの利用が快適になりました。
[ コメントを書く ] ( 353 回表示 ) | このエントリーのURL |
( 2.7 / 331 ) | ツイート複数GPUを搭載している環境だと、WindowsのバージョンによってセカンダリGPUの扱いが違うというのがあるのでそのメモです。前回の内容に入れようと思った内容だったのですが長くなりすぎたので分けました。
昔は表示しているディスプレイごとに使うGPUが違った
古のXPからW10の何処かのバージョンまでは、グラボが複数あってそれぞれ画面を出力している場合、その画面を表示しているGPUがその内容を処理していました。
そのため、ゲーム用に使うGUPは画面を1枚だけつなぎ、それ以外の雑多な内容を表示するためのをGPUを別に搭載することによって一種の負荷分散が出来ました。1080を買った直後くらいまでは「ゲーム用GPUは画面を1枚だけ出すのが一番パフォーマンスが出る」という動きをしていた記憶があります。
すべての処理がプライマリGPU処理に
それがWindows10のどこかのバージョン(20H2くらい?)からすべての内容はプライマリGPUで処理し、その結果を各ボードのRAMにコピーする、という挙動になっていました。その結果、 利点としては HEVCの動画やウィンドウモードで起動したゲームなどを、低性能なセカンダリGPUにつながっているディスプレイ領域にもっていってもそれなりに動く、という挙動になりました。
上記はセカンダリGPUとしてつながっているQuadro M2000から出力しているディスプレイにWindowモードで起動したARKを持っていった際のスクショですが、1080でも厳しい内容であっても処理している実態は7900XTXなので余裕で100FPS出ています。
しかし、欠点としてはどうやってもプライマリGPUの負荷だけが上がるようになり、違うGPUにつながっているディスプレイにブラウザなどを置くと、プライマリGPUで描写→セカンダリGPUのVRAMにコピーという無駄なステップが増えてしまったり、セカンダリGPUのVRAMやビデオデコーダが有効活用できないという問題がありました。
無理やりプログラムが使うGPUを指定する
プロセスが利用するGPUは、プロセスが立ち上がるときにプライマリになっているディスプレイ(「このディスプレイをメインディスプレイにする」のディスプレイ)がつながっているGPUとなります。
一時期はブラウザを起動する前にプライマリディスプレイをセカンダリGPU側のディスプレイに変更し、ブラウザの起動が終わったらプライマリディスプレイをもとに戻す、ということを行うことによって強制的にブラウザの処理をセカンダリGPUにさせていた時期もありました。
ただ、これをするとFirefoxがWebGLをレンダリングできなくなるというような問題があったので微妙なところでした。
Win10から処理するGPUを指定できるようになったが…
Windows10の21H2くらいからプロセスを処理させるGPUを指定できたのですが、試したところ省電力、高パフォーマンスというくくりは、UDHグラフィックスなどのiGPUを省電力GPU、それ以外のディスクリートGPUは高パフォーマンスGPUというくくりでした。
なので、両方ともディスクリートであるM2000と1080という組み合わせの場合、どちらかを省エネグラボに指定する、ということは出来ませんでした。
https://forest.watch.impress.co.jp/docs/news/1270962.html
M2000を省電力、1080を高パフォーマンスと指定できる方法がないかと探したのですが、結局iGPU以外は省電力GPUとして指定することは出来ませんでした。
Win11でいつの間にかプロセスのGPU割当機能が追加された
7900XTXに換装後も4k複数枚でブラウザを起動したままにしていると相変わらずVRAMを10GBとか消費することがある(ブラウザを閉じてもDWMが4GBくらい抱えたままになる)のは解消しませんでした。メモリに余裕があるとはいえ流石にどうにかしたいです。
WindowsUpdateを当てたらマシにならないかとWindowsUpdateを当てることにしたのですが、上記のグラフィックスのInsider previewを試すためにDevビルドにしたままなのを忘れていて、久しぶりにUpdateを当てたらWin11のInsider previewが降ってくるという事故を起こしてしまいました。
意図せずWin11(のInsider preview)になってしまったのですが、ロールバックする前に今の環境をWin11にした場合の挙動を確認することにしました。
仕事では13世代のi5を使う関係でW11を使っていますが、W10に比べてすべての動作が緩慢なのでW11をメイン機に入れたくないと思っていましたが、使ってみると「あれ…なんか逆に調子いい?」という感じだったので、そのまま利用を続行しました。CPUはRyzen 5 5600XなのでP/Eコアというものはなく、OSはどちらを使っても問題ないはずなのですが…。
そして、いろいろな設定を巡っているといつの間にかプログラムを処理するGPUを指定できるようになっていました。
W11も初期のバージョンはこの「特定のGPU」という選択肢がなかったように思いますが、いつの間にか増えていました。確認したバージョンは Insider Preview Build 23612 (Dev Channel)となりますが、ビルド的に多分22H2くらいにも入っている気がします。
その結果、ブラウザでなにか調べたり動画を見たりするときにはセカンダリGPUのVRAMやビデオデコーダがが使われるようになり、いい感じに動くようになりました。
もっと前にこれができるようになっていてほしかったですが、ようやく欲しかった機能が実装されました。
まとめ
プライマリGPUがミドルクラス〜ローエンドのグラボを使っていて、補助GPUを使って少しでもプライマリ側の負荷を下げたい、というときにはこのオプションは有効だと思います。
現行のミドルクラスならベース性能がかなり上がっているのでその必要もない気はしますが、VRAMが8GBクラスのものだとゲーム用にメモリを空けるためにブラウザ処理用の補助GPUが欲しくなる気もします。
ちなみに4kだとゲームを起動すると8GB位のメモリはあっという間に使うので、4kでゲームをしたいなら12GB、できれば16GB以上は必要だと感じました。
動画のHWエンコードソフトから使うGPUを選べないような場合も、強制的に使うGPUを指定することによって負荷分散ができるようになります。1080とM2000を組み合わせたときにはOBSやD3DGearのHEVC録画はGPUを分けたほうがゲームのFPSは安定していました。
また、プライマリGPUの性能が高いのであれば、 NVS810 のような1スロットで8枚DPをはやせるGPUでもプライマリGPUの性能によって快適に使えるので、ある種のハブとして使うといった柔軟性がかなり高くなったと思います。
こういったカーネル周りに手が入って良くなっている感じはするので、事故で上げてしまったW11はW10に戻さずに使うことにします。
以上
[ 1 コメント ] ( 331 回表示 ) | このエントリーのURL |
( 3 / 334 ) | ツイート
普段使っているモニタを4k*4枚に変更したのですが、ふとゲームをしようと思ったら今まで使っていたGTX1080では処理能力が足りなくなったためグラボを変えようと思っていたところに、じゃんぱらでRadeon RX7900XTXがなぜか特価で出ていたため久々のRadeonにしました。その時に色々検証したのでその時のメモです。
ことの発端
仕事でモニタを使うときに、置く場所の関係であまり多くのモニタを置くことができなかったので、モニタの中に極限まで情報をぶち込みたいという欲求から27インチの4Kモニタをスケーリング無しで使っていました。目を潰しながら4kを使っているうちに慣れてきたので、家で使っているモニタも4kにしようとすべて置き換えました。
1枚だけ変えると色味が合わないとかベゼル位置が合わないというような微妙なストレスが嫌なので 4kを複数枚買いましたが、使ってて思うのは個人的には27インチWQHDくらいの解像度がベストだと思います。
27インチ4kモニタは11インチのFHDモバイルモニタを4枚並べたときとDPI的に同じになるのでスケーリングなしにするとまあまあ厳しいですが、現代のITエンジニアは眼球に可能な限り多くの情報を詰め込む必要があります。
モニタを変えてからしばらくは忙しくゲームをする暇と気力がなくてオフィス用途でしか使っていませんでしたが、ふとARK: Survival Evolvedを起動してみたところ、すべてEpicの状態で4kネイティブで起動すると20FPSくらいしか出ないという状態でした。
ゲームしたいときに出来ないというのは問題なのと、4k複数枚の環境だと普通に使っていてもDWMプロセスやFirefoxなどのブラウザがVRAMを消費していって8Gのうちの5GBを消費しているようなことがあったので、いい加減グラボを変えたいという思いが強かったので新しいものを買うことにしました。
グラボ選定
最初は4080を買おうと思っていたのですが、じゃんぱらで7900XTXが特売されていたのでVRAMが24GBと多いという利点からこれも候補に上がりました。色々比較すると、
・純粋な3D処理能力は4080よりも高い場面も結構ある
・すべてのタイトルでDLSSなどの機械学習が使える訳では無い
・7900XTXの特価は12万だったが4080はどうしても18万くらいになる
・RTX5000シリーズが先送りになったのでRTX4000シリーズの価格が下る要素がなくなってしまった
・VRAMが多いので雑に使っても心の余裕がある
となり、過去散々ATiのグラボで色々踏んだ事があってもまあいいかなと思えたのでポチりました。
VRAMがそんなに必要になるか、と思うかもしれないですが、3ヶ月位(下手すると1年)再起動せずにブラウザのタブやウィンドウを大量に開いたまま使っているとVRAMの使用量が肥大化していき、VRAMが足りなくなるとブラウザやOSの挙動がおかしくなり、すべてのブラウザを閉じるという必要が出てきます。
ブラウザをすべて閉じても今度はWindowsのDWMがVRAMを握ったままになり、その状態でゲームをするとスワップのような挙動になる事があり、解消には結局再起動が必要になってストレスだったりします。
使い方が悪いのでは??というのはそうなんですが、原状どうにもならないのでこの使い方だとスペックによるパワーで押し切るしかないです。また、4kという解像度が1枚でFHDディスプレイ4枚分の表示面積があるので、それを複数枚となると相応のスペックが必要になります。
27インチで4kの解像度でゲームをする必要があるのかと言われると、別に画質を求めているわけではないのですが、フルスクリーンの解像度変更によって開いているウィンドウがめちゃくちゃになるのが嫌なので、どうしてもネイティブの解像度で出したくなります。
ただ、こういった変な要求がなければ現在では性能や値段、発熱や消費電力の扱いやすさから4070あたりが妥当だと思います。また、自分は今のところ常用デスクトップ機で機械学習をさせるつもりはないのでRadeonも候補になりましたが、普段機ででお絵かきAIも動かしたいというような要望があると必然的にGeforceが候補になるかと思います。
わかっていたけど高い消費電力
グラボを換装した感想ですが、4kでもARKなど今までやってきたゲームがコマ落ちせずかなり快適に動くので1080との性能差を実感しました。ただ、それに比例して消費電力が増えたので、 AMD Software: Adrenalin EditionというAMD謹製のGPUのモニタリング、チューニングをするツールから消費電力を監視し、これを下げる方向にチューニングする方法を模索することにしました。
フレームレート制限で消費電力を下げる
ARKを遊んでいるとGPUだけで350Wくらい行ってしまうので、どうにかこれを下げられないかとアレコレしていると、当然ながら負荷が下がればそれに伴って消費電力も下がることがわかりました。60Hzのディスプレイなので、それ以上のフレームレートは無駄になってしまうため、まずはフレームレートの固定を行いました。
HL2やL4D2などでゲームからV-Syncを有効にすると明らかな入力ラグが出るので今まではティアリング上等で200FPSなどのフレームレートを出していましたが、FreeSync対応モニタなのが有効なのかドライバが賢くなったのかわかりませんが、Adrenalineからフレームレートの制限をかけると気になるラグは出ませんでした。
80-90FPS出ていて350W消費していたのが60固定にすることによって300Wくらいに落ちたので、もう少し下げられないか試してみました
RSRなどのアップスケーリングを試す
Adrenalineの設定にRadeon Super Resolution(RSR)という項目があったのでこれについて調べてみると、ゲームの解像度をネイティブ以下に設定したフルスクリーンゲームを起動した際にドライバ側でネイティブまでアップスケーリングして出力する、という機能だとわかり、試しにゲームから解像度をWQHDにしてRSRを有効にしてみるとかなり効くことがわかりました。
具体的にはRSRを使うことによりフレームレート制限と合わさりGPU負荷が80%まで下がり、消費電力が一気に180W程度にまで落ちました。ただ、ゲーム自体はネイティ解像度以下で出力されるため、開いているウィンドウがぶっ飛ぶ問題は起きてしまいました。
よく見てみるとAdrenalineの説明にFSRをドライバレベルで実行するのがRSRである、という文言があったのでこのFSRについても調べてみましたが、FSRとは FidelityFX Super Resolutionの略であり、こちらは出力するテクスチャの解像度を内部的に落としたあと、グラボでアンチエイリアシングなどの処理をしたあとにアップスケーリングをかけるという技術になるようです。
ただ、FSRについてはゲーム側の対応が必要になるようなので、そもそもARKなどは対応していないのでは?と思いましたが、ゲームのオプションにあるResolution scaleというのがアップスケーリング前に描写するテクスチャの画像になるようです。しらなかった…
FSRについては思いっきり解像度を下げると流石にテクスチャの不鮮明さが目についてしますが、27インチ4kであれば7-8割位のスケーリングならネイティブと遜色ないレベルになりました。
60FPSの制限の中では画質と消費電力のトレードオフになりますが、違和感のないところでWQHDのRSRと同じ180Wかそれよりも若干高い200W程度で落ち着きました。もとの350Wに比べたらだいぶマシになりました。
ついでにDLSSなどについても調べてみる
AMDのグラボなのでNVIDIAの技術であるDLSSは使えないのですが、こちらについても調べてみたところ、やっていることとしてはFSRと同じ低解像度テクスチャのアップスケーリングだとわかりました。
違いとしては、FSRはスケーリング処理をシェーダーとして扱うため特殊なコアが必要ないという特徴がありますが、DLSSはその処理をTensorコアなどの専用プロセッサで行うので対応したグラボが必要になる、ということみたいです。
事実、FSRは1080でも利用できたようなので、実はこれで誤魔化せばグラボを買わなくても耐えられたのでは…という思いはありますが、FSRを行うにもグラボ側の余裕がないと効果がないようなので多分意味はあったと信じます。まあ、VRAMが足りない問題は出ていたので…
DLSSの進化系であるDLSS-FG(Frame Generation)は、実際のレンダリングフレームの間にTensorで(描写済みのテクスチャからいわば画像として)作成したフレームを挟むことによりフレームレートを上げる処理になるようです。同じような技術がFSR3でも実装されるようです。
ただ、補完フレームを挟む必要があるので入力から出力までのバッファが必要になり、入力のレイテンシ低減にはならず、むしろ増える方向になるようです。FSR/DLSSは実際の描写が軽くなるためこれを有効にすることによって入力レイテンシが下がるらしいです。
フレームレートと入力遅延が一致しないというのはなかなか難しいですが、GPUの性能が足りずそもそもコマ落ちするレベルでレイテンシが上がっているようなときにはDLSS-FGのレイテンシのほうがマシになる可能性はあります。
まとめ
昔は「ドライバのフィルタ処理で正しくテクスチャを描写してない!手抜きだ!チートだ!」 みたいなことを言っていた時期がありましたが、今となっては「クソ真面目に描写するのは馬鹿らしいからAI使って補完しようぜ!」みたいなことを言い始めるあたり時代を感じます。まあ前者についてはただの言いがかりですが。
フレームレートを増やす技術というのは言い換えれば同じフレームレートなら負荷が下がる技術ということになるので、極端な高フレームレートディスプレイを使っていないのであれば消費電力を下げる恩恵があるというのを実感しました。
それなら下位のモデルでもいいのではないかと思うかもしれませんが、これらの技術が (RSRは原理的に使えそうではありますが) すべての場面で使えるわけではないというのと、ベーストルクがあるからこそできる余裕というのもあるので、グラボを買うなら個人的にはある程度の上位モデルをおすすめしたいです。
ただ、11月ごろに7900XTXを買ったのですが、2月に4080Superが15万くらいで出るらしいというのを見て「それならそっちにしたわ…」みたいな気持ちはあります…。まあ、こんなことでもないとRadeonを買うこともなかったと思いますし、使ってみたら改めて知ることも多く、AI以外の用途なら悪くないというのがわかったので良しとします。
7900XTXも出始めの頃のドライバの出来は相変わらず散々だったようなので、他人におすすめするときは「Geforce買っておけ」と言いますが…。
FSPカウンタなどで高いフレームレートを見ると気持ちがいいですが、逆に消費電力を減らす方に振ってみるのも面白いと思いました。
以上
余談:過去のATiで踏んだもの
3870を2枚でCrossFireしていたときが一番ひどかったです。CFを使うとどのドライバでも何かしらおかしかったので、その出来の悪いドライバから一番マシなのはどれかを探すのが大変でした。ジャンク漁りかな?
どれも出来が悪いので、毎月出るCatalystドライバに今抱えている問題が直らないかという僅かな願いをかけて更新するのですが、ひどいものだと入れたら最後、青くなって戻ってこれなくなるということが多々ありました。月刊Catalyst!今月号の付属はきれいな青画面つき!!!みたいな感じでした。
まあ、そのあとGTX295を使いましたが 結局nVidiaでもデュアルチップはうまく動かない事が多く、その後使ったHD4890は安定していました。
余談:買ったモニタ
モニタについてはそこまでこだわりがないのですが、1枚だけ変えると色味が合わないとかベゼル位置が合わないというような微妙なストレスが嫌なので、使っていた4枚をすべて交換する前提で安いものを探していました。するとAliで162ドルのものが見つかりました。 (今は絶版になってますが)
モバイルモニタなどの中国製モニタをいくつか試した経験から、今の中国製のモニタのパネルはそれなりに品質が高いという経験則と、ベゼルに変な文字が入っていないのと、何故かこれだけ大きいにも関わらず送料が無料だったので 、試しに1枚買って1ヶ月検証したのですが、そこそこ良かったので計4枚買いました
まあ買った時期によって(もともとできるとは書いていなかった)入力のPiPができるリビジョンとできないリビジョンが混ざっていたとか、 旧リビジョンのモニタについてきたACが公称消費電力が45Wに対して12V/3.33A=40Wという微妙に出力の足りないACで「大丈夫かこれ」とか思っていたら案の定1ヶ月でACが壊れたとか、解像度をWQHDにすると144Hz駆動にする裏オプションが存在するとか、大陸しぐさ満載でしたが、鍛えられてくるとむしろそれが楽しくなってきます。 色んな意味でシビレますね。
ちなみにACについては汎用的な2.2/5.5mm径のACなので在庫が家にくさるほどあり、12V/5Aのものに交換して無事に動きました。それを口実に紛争を開始して部分的な返金を受けられたので良しとします。向こうも知ってか後期リビジョンではACが最初から12V/5Aのものになっていました。色については初期は黄色みが強いですがOSDで調整すればいい感じの発色になりました。
[ コメントを書く ] ( 606 回表示 ) | このエントリーのURL |
( 3 / 322 ) | ツイート
普段便利に使っているESXiの環境ですが、ESXi7x以降になるとvmkAPIのバージョンが上がり、ネイティブドライバが配布されていないとドライバの認識ができないため、古いマイナーなハードウェアがだいぶ認識できなくなります。こちらの環境では未だにストレージがInfinibandとSRPに依存しているので6.7から進めずにいます。
そんな中、普段動いているストレージのIB接続がESXiからみてesxtopでFCMD/sが跳ね上がるときがあり、なんかストレージが調子が悪い、ということが稀に起きるようになってきました。問題が起きるとストレージ自体の再起動をしてもだめな時があり、VMホストを再起動しても解消しないことがありました。いろいろな検証の結果、どうやらVMホストに刺さっているHCAは問題ないようで、ストレージホストに刺さっているHCAがなにか悪そうな感じでした。
このIB HCAも相当長く使っているので、そろそろ交換してみようと思い、手元にCX2の在庫があるもののebayを見てみたら、FDRなHCAが9ドルで売っていたので買ってしまいました。もうIBは買わないと思っていたのですが…。
ハードウェアについて
対象のHCAはEC33という型番で売られており、Connect-IBのDPモデルのようです。ちなみにCX2とブラケットの互換があったため、DDRなCX2からブラケットをはいで使いまわしました。
燦然と輝くFRU PN / NAの文字。謎が多いです。
Connect-X4などはEtherとしても動かせるためまだ需要があるのですが、Connect-IBは完全にIB専用のため、かなり不人気です。9ドルでもいらないというのが全てですが、こちらの環境だと逆にスイッチがEtherを使えないので都合が良いです。
IBについて
IBは基本は広大なL2で使うという単純な作りがゆえ、QDRな32ポート40Gスイッチ(Voltaire Grid Director)であってもポートをたくさん使っても消費電力が70-100W程度と非常に低く、ストレージインターコネクトとして使うにはとても優秀です。
ただ、IBにはL3ルーティングやVLANなどがない(パーティションを分けるためのP keyがあるといえばあるものの…)うえ、SubnetManagerなど独特な作法があり使いづらいし、ネットワーク的にみんなほしいのは結局Etherだよね、となり、EtherでRoCEなどを使うのが今どきのRDMAですが、自宅環境で使おうとすると新しくスイッチとNICを買わないといけない、スイッチを買っても40GだとIBからそこまで変わらない、40Gスイッチで多ポートのものになると消費電力がかなり上がる、などの理由があり、用途次第では未だにIBにはメリットがあります。
FCがそこそこまともに動けばよいのですが、8G-FCでLinuxターゲットを作ったときにはあまりパフォーマンスが出なかったので、結局全て売ってしまいました。その時はLIO+targetcliで検証しましたが、32G-FCとCSCTならもしかしたら改善しているのかもしれません。しかし、FC HBAをイニシエーターではなくターゲットとして動かすには多少の手間があり、かつまだそこまで32G-FCが出回っていないので現在どの程度出るのかは不明です。ただ、RDMAの高速性、低負荷性を見てしまうと微妙な気がします。
SCSTでSRPターゲットが動くのか2022
現在動いているストレージはDebian9までは上げましたが、それからは塩漬けになっています。現在のDebian11はカーネルが5.10となり、カーネルモジュールとしてib_srptを読み込むSCSTはカーネルとの兼ね合いがありそうで無事に使えるのか、Connect-IBはドライバとしてmlx5をつかむのでこれもいけるのか、という疑問がありました。LinuxはINBOXでib_sprtドライバを持っているのですが、LIO+targetcliだとずっと使っているとSRPがなにかのタイミングで刺さるということが多々あり、パフォーマンスもSCSTのほうがかなり良かったので過去の経験からSCSTを使っています。LIOももしかしたら良くなっているのかもしれませんが、過去から現在の実績があるのでSCSTにこだわります。
様々な検証をした結果、結論から言いますと無事に動いています。以下にSCSTのビルド方法などを書きます。
SCSTのビルド
昔は小細工が色々必要でしたが、今は素直にビルドできるようになっています。まずはgit,make,gcc,linux-headersを入れます。
root@debian:~# apt install git make gcc linux-headers-amd64
次に、gitからソースをダウンロードし、makeします。make allでもいいのですが、FCターゲットなど通常使わないものも含まれているため、一つ一つ指定して作ったほうが早く終わります。今回はSCSTに必要なパッケージ、srpt、iscsiモジュールをビルドします。ここで注意が必要なのは、順番的にscst_installを先に持ってこないと他のビルドがコケます
root@debian:~# git clone https://github.com/SCST-project/scst.git
root@debian:~# cd scst/
root@debian:~/scst# make scst_install scstadm_install iscsi_install srpt_install
ビルドが終わったら、depmodで新しく追加されたモジュールを反映します。
root@debian:~/scst# depmod -a
これで、SCSTの前準備が完了しました。正しくモジュールが入ったか、modinfoで確認します。import_nsがSCSTになっていれば問題なくビルドできています。
root@debian:~# modinfo ib_srpt
filename: /lib/modules/5.10.0-10-amd64/extra/ib_srpt.ko
import_ns: SCST
license: Dual BSD/GPL
description: SCSI RDMA Protocol target driver v3.7.0-pre#in-tree (11 January 2022)
author: Vu Pham and Bart Van Assche
depends: scst,ib_core,rdma_cm,ib_cm
retpoline: Y
name: ib_srpt
vermagic: 5.10.0-10-amd64 SMP mod_unload modversions
sig_id: PKCS#7
signer: SCST Kernel Modules
設定ファイルの作成
昔はscstadminで色々やっていましたが、設定ファイルをある程度作って読み込ませたほうが楽なので以下にサンプルを置きます。SCSTのIBのGIDは/sys/class/infiniband/mlx5_0/ports/1/gids/0などにあるので、こちらをcatなどで開きます。
root@debian:~# cat /sys/class/infiniband/*/ports/*/gids/0
fe80:0000:0000:0000:5849:560e:5c50:0401
fe80:0000:0000:0000:5849:560e:5c50:0409
以下のサンプルはFCでいうところのLUNマスキングをしていない、すべての接続を受け入れてマウントを許可する設定になっています。場合によってはマスキングをしないと意図しないマウントが発生してファイルシステムが壊れるので注意してください。今回はVMFSとESXiからの利用のみを想定しています。TARGET_DRIVER copy_managerは無くてもscstadminが勝手に増やすものなので正直なんだかよくわかりませんが、書いておかないとターゲットの更新をするときなどに--forceをつけて読み直したときに色々終わるので必要なものになります。
cat /etc/scst.conf
HANDLER vdisk_fileio {
DEVICE ram0 {
filename /ramdisk/ram.img
}
}
TARGET_DRIVER copy_manager {
TARGET copy_manager_tgt
}
TARGET_DRIVER ib_srpt {
TARGET fe80:0000:0000:0000:5849:560e:5c50:0401{
enabled 1
rel_tgt_id 1
LUN 0 ram0
}
TARGET fe80:0000:0000:0000:5849:560e:5c50:0409{
enabled 1
rel_tgt_id 2
LUN 0 ram0
}
}
#TARGET_DRIVER iscsi {
#
# enabled 1
#
# TARGET iqn.2022-11.dev-debian-04.sn.1234 {
# QueuedCommands 128
# LUN 0 ram0
# enabled 1
#
# }
#
#}
一度これでSCSTを起動します。systemctl start scst.serviceだとなぜかscst_vdiskが読み込まれないので、手で読み込みます
root@debian:~# for a in scst scst_vdisk ib_srpt ; do modprobe $a ; done
その後、scst_adminで設定を直接読み込んで起動します。
root@debian:~# scstadmin -config /etc/scst.conf
これでESXiにOFEDが入っていればそのうちディスクが見えるはずです。
ESXiからマウントして確認する
LUNマスキングをしていないため、SRPが有効になったESXiがいるIBファブリックにつなぐと定期的にクエリが飛んでいるので勝手にターゲットを認識して未使用ディスクとしてESXiにマウントされます。非公式ながらSRPを使えるESXiは6.7U3が最終です。予め必要なセットアップをしたESXiから見てみます。スペックは以下です。
ターゲット
Dell T5810
CPU Xeon E5-1620 v3
RAM 8*4GB @ 2133MHz (32GB)
HCA: Connect-IB@PCIE 3.0 x16接続 (デュアルポート接続)
RAMDISK 25GB
VMホスト
Supermicro X10SRL-F
CPU Xeon E5-2697 v4
RAM: 8*32GB@2133MHz (256GB)
OFED:MLNX-OFED-ESX-1.8.2.5-10EM-600.0.0.2494585
HCA: ConnectX-3 (not VPI/Pro) @PCIE 3.0 x8接続 ( マルチパス)
その結果が以下です。
速い(確信)
QDRなスイッチに接続されているため、理論値的には80Gbps*0.8 in MB/sで8GB/sが最大ですが、CX3がPCIE 3.0のx8でリンクしているため、PCIEの最大が64Gbpsとなり、それの0.8倍となると6.4GB/sが理論値になるのでかなり近いところまで出ています。もう少しIOPSが出てもいい気がしたので、以下のシステムでも検証してみました。
VMホスト
Supermicro C9Z390-PGW
CPU Core i5 9600K @ AllCore4.8GHz
RAM: 4*32GB@2666 MHz (128GB)
OFED:MLNX-OFED-ESX-1.8.2.5-10EM-600.0.0.2494585
HCA: ConnectX-2 @PCIE 2.0 x8接続 (マルチパス)
その結果が以下です。
速い(確信)
刺さっているのがConnectX-2というPCIE2.0の化石なので帯域は頭打ちになっていますが、CPUのクロックが高いのでIOPSがかなり出ています。
Connect-IBをESXiで使いたい人生だった
Connect-IBはmlx5ドライバを使うため、6.7などでOFEDを入れても認識しません。しかし、デバイスにパススルーをかけてLinux VMでSRPを受け付け、そのディスクをもう一度内部のvmkスイッチとiSCSIで接続することによりストレージプロクシとして動かせば見えるのでは??というスケベ心が起きてしまったので試してみました。これが動けばESXiの上で動くドライバ依存がなくなるので、ESXi8も使えるようになります。センスのない絵にすると以下のような感じになります。SRPドライブはVMによりiSCSIに変換され、ESXiの内部ループバック接続によってDatastoreとしてマウントされます。
結論から言うと、動くには動いたのですが、何故かPCIパススルーをかけたLinuxVM上からのSRPドライブに対してそもそもののパフォーマンスが出ないため、あまり意味がありませんでした。ddなどで負荷をかけるとSRPドライブそのものに対するアクセスが物理環境と比べて負荷が高いように見えました。
とはいえ、ストレージプロクシ経由のESXi8.0環境でも1.4GB/sと10Gbps以上は出ていたので、何かしらのチューニングにより改善する可能性はあります。ただ、物理環境では問題なくてもパススルーVM環境だとib_read_bwが通らなかったりなど、なにか一癖ありそうな雰囲気がありました。起動オプションになにか必要なのかもしれません。
また、SRPドライブをiSCSIでエクスポートし直してファイルシステムがこわれないのか、という疑問については問題ありませんでした。ただし、DEVICEの名前を元の名前と揃えておかないとESXiからマウントしたときのeuiが変わってしまうため、これを合わせる必要はありました。
root@debian:~# cat /etc/scst.conf
HANDLER vdisk_blockio{
DEVICE ram0{ #←ここ
filename /dev/sdb
}
}
TARGET_DRIVER iscsi {
enabled 1
TARGET iqn.2022-11.dev-debian-iscsiloop.sn.1234 {
allowed_portal 10.11.1.1
QueuedCommands 128
LUN 0 ram0
enabled 1
}
}
まとめ
Connect-IBについてはIBで使う限りはなかなか良いのですが、ESXiについてはやはり6.7+CX3止まりということになりそうです。IBは損切りしたいのですが、いかんせん速いので結局これを使い続けることになりそうです。今どきのシステムだとハイパーコンバージドな構成でローカルに高速ストレージを積むのが流行りですが、自宅環境だと最低必要台数とハード構成の縛りが結構きつく、多少の冗長化を捨ててもコンピュートノードとストレージノードを分けられたほうがそれぞれに特化した構成が作れるので都合がいいことが多いです。
とはいえ、そろそろNVMeOFとかiSER使いたいので誰か低消費電力な100Gスイッチください…
[ コメントを書く ] ( 616 回表示 ) | このエントリーのURL |
( 3 / 500 ) | ツイート| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 進む> 最後へ>>
自己紹介
、もしくはTwitterまでお願いします。
