PVEでInfiniband+NFSoRDMAを使う

PVEで共有ストレージを使おうとすると、Infiniband+NFSoRDMAが割と使いやすくて且つ高速なストレージの候補になります。その構築メモです。

個人的な慣れから例によってDebianでの構築となります。ProxmoxBackupServer(PBS)でも可能です。

設定手順

ストレージサーバーのセットアップ

DebianでのInfinibandのあれこれ をもとに、OpenSM,IPoIBが使えるようにしておきます。

root@dev:~# apt install opensm infiniband-diags
 
root@dev:~# for m in ib_umad ib_uverbs ib_ipoib ; do modprobe $m ; echo $m >> /etc/modules ; done

また、 nfs-kernel-serverも入れます。

root@dev:~# apt  install nfs-kernel-server

次に、NFSのRDMAを有効にします。その後、NFSサービスの再起動を行います。

サービス再起動後、portlistにrdma 20049というのが増えていることを確認します。

root@dev:~# vim /etc/nfs.conf
# Uncomment
vers4.2=y
rdma=y
rdma-port=20049

root@dev:~# systemctl restart nfs-kernel-server.service

root@dev:~# cat /proc/fs/nfsd/portlist
rdma 20049
rdma 20049
tcp 2049
tcp 2049

その後、生えてきたipoibインターフェースにIPを割り当てます。マルチパスを使う場合は適宜2つのサブネットを割り当てます。ibのインターフェースについてはip lなどでどの名前で生えてきたか確認します。

また、その際にVLANなどで隔離されていない2つのサブネットを1つのスイッチ上に生やすことになりますが、IBサブネットでDHCPが動いていない限りは問題ありません。

下記の場合はibp101s0とibp101s0d1の2ポートが生えてきた環境の設定です。PCIEスロットの構成によりこの番号は変動します。

root@dev:~# vim /etc/network/interfaces
...
auto ibp101s0
iface ibp101s0 inet static
 address 10.1.1.101/24

auto ibp101s0d1
iface ibp101s0d1 inet static
 address 10.1.2.101/24

設定追加後、 ifreload (入っていれば)もしくは  networking.serviceを再起動します。

root@dev:~# ifreload -a
#or
root@dev:~# systemctl restart networking.service

正しくIFにIPが振られたか確認します。

root@dev:~# ip a
...
6: ibp101s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2044 qdisc fq_codel state UP group default qlen 256
    link/infiniband 80:00:00:2b:fe:80:00:00:00:00:00:00:58:49:56:0e:6a:1a:02:01 brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
    inet 10.1.1.101/24 brd 10.111.1.255 scope global ibp101s0
       valid_lft forever preferred_lft forever
    inet6 fe80::5a49:560e:6a1a:201/64 scope link
       valid_lft forever preferred_lft forever
7: ibp101s0d1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2044 qdisc fq_codel state UP group default qlen 256
    link/infiniband 80:00:00:2d:fe:80:00:00:00:00:00:00:58:49:56:0e:6a:1a:02:09 brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
    inet 10.1.2.101/24 brd 10.111.2.255 scope global ibp101s0d1
       valid_lft forever preferred_lft forever
    inet6 fe80::5a49:560e:6a1a:209/64 scope link
       valid_lft forever preferred_lft forever

最後に、NFSのexportsを編集します。かなりガバオプションですが、このへんは環境により変更してください。

root@dev:~# vim /etc/exports
/srv/ssd/exports 10.1.0.0/16(rw,async,wdelay,insecure,no_root_squash,no_subtree_check)

root@dev:~# exportfs -arv
exporting 10.1.0.0/16:/srv/ssd/exports 

以上でNFS側の設定は完了です。PVE側の設定に移ります。

PVE側のIPoIBモジュールなどの読み込みとIP設定

PVE側で初めてIBを使う場合、必要なモジュールを読み込む必要があるので忘れないように読み込んでおきます。

root@pve15:~# for m in ib_umad ib_uverbs ib_ipoib ; do modprobe $m ; echo $m >> /etc/modules ; done

IPoIBモジュールを読み込むとPVEのGUIに新しいIFが生えてくるので、そのIFにNFSサーバと同じサブネットのIPを追加し、Applyを押しておきます。

直接 /etc/network/interfaces に追加してもよいです。

PVEでNFSoRDMAをマウントする

まずはテストでNFSがマウントできるか直接ターミナルで検証します。マルチパスを使う場合はオプションに max_connect=2を指定する必要があります。4ポートマルチパスもmax_connect=4で可能だとは思いますが検証してません。

root@pve15:~# mkdir /t
root@pve15:~# mount -v -t nfs -o vers=4.2,max_connect=2,proto=rdma,soft 10.1.1.101:/srv/ssd/exports /t
#マルチパスをテストする場合
root@pve15:~# mkdir /t2
root@pve15:~# mount -v-t nfs -o vers=4.2,max_connect=2,proto=rdma,soft 10.1.2.101:/srv/ssd/exports /t2

#rdmaが有効になっているか確認
#マルチパスが有効になっている場合、2回目の/t2が10.1.2.101ではなく10.1.1.101になる
root@pve15:~# mount|grep rdma
10.1.1.101:/srv/ssd/exports on /t type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,soft,proto=rdma,max_connect=2,port=20049,timeo=600,retrans=2,sec=sys,clientaddr=10.1.1.3,local_lock=none,addr=10.1.1.101)
10.1.1.101:/srv/ssd/exports on /t2 type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,soft,proto=rdma,max_connect=2,port=20049,timeo=600,retrans=2,sec=sys,clientaddr=10.1.1.3,local_lock=none,addr=10.1.1.101)

NFS multipath / session trunking使用時にmountコマンドに表示されるIPがおかしい件について

仕様らしいです。

https://support.scc.suse.com/s/kb/NFS-v4-1-or-4-2-mounts-pointing-to-multihomed-systems-do-not-appear-as-expected?language=en_US

Situation

A NFS v4 client system has two or more mounts pointing to different IP addresses (or hostnames).  However, these IP addresses actually belong to the same remote host (a practice known as mulithoming).  For example, an /etc/fstab may contain:

Server1:/export1   /mnt1   nfs   vers=4.2    0  0
Server2:/export2   /mnt2   nfs   vers=4.2    0  0
"Server1" resolves to 192.168.1.1 and "Server2" resolves to 192.168.1.2.  However, both these IP address are bound to one NFS Server machine.

Resolution

This is expected behavior for NFS v4, due to a feature known as "trunking detection."

Connection Refusedが出る場合

ここで Connection Refused のエラーが出る場合、 proto=rdma を抜いてマウントできるか確認してください。それでマウントがうまくいき、かつ cat /proc/fs/nfsd/portlistした際に rdma 20049がいるにも関わらずマウントできない場合、一度NFSサーバ自体の再起動をしてみてください。

オンラインで ib_ipoibモジュールやib_umadを読み込ませたり ip aなどでアドレスを追加した場合、NFS関連のサービスを再起動しても何故かうまくRDMAでマウントができないことがありました。

起動順があるのかもしれませんが、再起動したら動いてしまったので結局何が原因だったのかわかりませんでした…。ただ、、nfs-kernel-server.serviceがenableになっている必要がある、/etc/network/interfacesにiboipインターフェースの記述がある、というのが必要条件に見えました。

しかし、ゼロから構築して同じように作っていっても再起動せずに問題なくRDMAでマウントできることもあり、原因は謎でした。

IOのチェック

fioなどを実行し、NFSをマウントしたディレクトリに対してRDMAが効いているか確認します。問題がなさそうdれあればテストのマウントを解除します

root@pve15:~# apt install fio
root@pve15:~# mkdir /t/fio
root@pve15:~# cd /t/fio
root@pve15:/t/fio# fio --name=fiotest --ioengine=io_uring --iodepth=8 --time_based --runtime=20 --rw=randwrite --bs=8k --size=1G --numjobs=8 --group_reporting
#マルチパスが有効な場合、このときにNFSサーバ側でもPVE側でもいいので新しいターミナルを開きatopなどで2つのパスが使われていることを確認する
#問題がなければゴミ掃除
root@pve15:/t/fio# rm fiotest*
root@pve15:/t/fio# cd 
root@pve15:~# umount /t
root@pve15:~#  umount /t2

storage.cfgの編集

PVEのGUIからストレージの追加を行ってもよいのですが、GUIからNFSを追加しても結局optionsが指定できないため直に編集してしまいます。名前などは適宜変えてください。

一つのホストでstorage.cfgを変更するとその変更が全ホストに伝搬します。

今回はマルチパスを有効にしていますが、2つ目のセッションはマウントできていれば何でもいいのでVMやCTを作るときの選択の邪魔にならないようにcontentをsnippetsだけ有効にしています。(検証してませんがなくても良いかも?)

また、NFSサーバのメンテナンスなどでサーバを落とすときにhardマウントだとマウント側のカーネルが刺さるためsoftにしていますが、環境によって変えてください。

(PVEのストレージのEnableのチェックを外すだけだと既存のNFSのマウントがアンマウントされないように見えます)

root@pve15:~# vim /etc/pve/storage.cfg
...
nfs: nfs-rdma-1
        export /srv/ssd/exports 
        path /mnt/pve/nfs-rdma-1
        server 10.1.1.101
        content iso,images,snippets,vztmpl,backup,rootdir
        options max_connect=2,proto=rdma,soft,vers=4.2
        preallocation off
        prune-backups keep-all=1

nfs: nfs-rdma-2
        export /srv/ssd/exports 
        path /mnt/pve/nfs-rdma-2
        server 10.1.2.101
        content snippets
        options max_connect=2,proto=rdma,soft,vers=4.2
        preallocation off
        prune-backups keep-all=1

保存後、PVEのGUIに追加したストレージが増えていることを確認してください。しばらくするとクラスターの全ホストでマウントされます。

追記: ログにRPC:   addr XX.XX.XX.XX already in xprt switchが出る件について

上記のstorage.cfg編集でも動くのですが、前述のtrunking detectionの仕組みにより、nfs-rdma2側のIPでマウントしようとしても1側のIPでマウントされることになります。

そのため、PVEが正しくマウントされていないと認識してしまい、1秒に1回再マウントをしようとする結果 journalctl -n 10などをすると以下のような出力が無限に出てしまいます。

[1715178.564472] RPC:   addr 10.1.2.101 already in xprt switch
[1715179.501148] RPC:   addr 10.1.2.101 already in xprt switch
[1715180.735531] RPC:   addr 10.1.2.101 already in xprt switch
[1715187.260447] RPC:   addr 10.1.2.101 already in xprt switch
[1715188.168330] RPC:   addr 10.1.2.101 already in xprt switch
[1715189.106795] RPC:   addr 10.1.2.101 already in xprt switch
[1715190.075179] RPC:   addr 10.1.2.101 already in xprt switch
[1715197.833274] RPC:   addr 10.1.2.101 already in xprt switch
[1715198.760290] RPC:   addr 10.1.2.101 already in xprt switch
[1715199.680601] RPC:   addr 10.1.2.101 already in xprt switch
[1715200.656027] RPC:   addr 10.1.2.101 already in xprt switch

影響はないのですが、ログを見るときに邪魔なので、これを止めたい場合はPVEの自動的なマウントのリトライがかからないfstabなどに書く必要があります。

違うIPでも同じサーバであれば接続性があることを教えてあげればあとはSession trunkingの仕組みでサブ側のIPも使うようになります。

それぞれのExportsを書く必要はなく、違うIPでもつながることを教えてあげるだけで良いのでPVE管理外のディレクトリをfstabに書いておくのが良さそうです。

例なので雑ですが動作は確認しています。

NFS側

/srv/ssd/exports 10.1.0.0/16(rw,async,wdelay,insecure,no_root_squash,no_subtree_check)
/a 10.1.0.0/16(rw,async,wdelay,insecure,no_root_squash,no_subtree_check)

PVE側

...
nfs: nfs-rdma-1
        export /srv/ssd/exports 
        path /mnt/pve/nfs-rdma-1
        server 10.1.1.101
        content iso,images,snippets,vztmpl,backup,rootdir
        options max_connect=2,proto=rdma,soft,vers=4.2
        preallocation off
        prune-backups keep-all=1

...
10.1.2.101:/a /mnt/pve/nfs-witness nfs  max_connect=2,proto=rdma,soft,vers=4.2 0 0

VMなどを作成して動きを確認する

マウントされたことを確認したら、VMやCTなどを作成して動作を確認します。

この際に、VMのストレージコントローラーにVirtIO SCSI singleを選択し、ディスクにscisiを選択する必要があります。virtioなどだと思った速度が出ませんでした。

マルチパスが有効な場合、atopなどを開き、2つのIFBインターフェースが使われていることを確認します。

今回はストレージとPVE側でPCIE 30. x16でリンクしたConnect-IBを利用していますが、PCIE x8でリンクしている場合はQDRだと両ポート合計で50Gbps程度になります。FDRだともう少し早いです。

こちらもFDRで全機リンクさせたい気持ちはあるのですが、FDR対応のケーブルを今更何本も買うのは…という気持ちがありQDR止まりです。

まあ、QDRでもその下のストレージさえ速ければ十分な速度が出るので、出物があれば検討しようかな、という感じです。

※追記 FDRでのNFSoRDMA

その後FDRのケーブルがまとめて手に入ったのでFDRでの検証をしてみましたが、FDRの理論値(52Gbps)の2ポート分が出ることを確認しました。

Connect-IB同士でマルチパスを組めば、マシンスペックが良ければ夢の(?)実測100Gbpsも達成可能です。

参考までに、FDRリンクでNFSoRDMA上のqcow2ディスクへベンチマークをかけた際のスコアをいくつか載せておきます。

PVEホスト上のIOキャッシュはしていませんが、NFS側でIOのバッファリングを有効にしているので、基本的にRAMへの読書速度と同等になります。

過去のスクリーンショットからの寄せ集めなので画像に統一感がありませんが…。

以下の環境はベンチマーク専用ではなく実際に使ってる環境のものになります。

他にWindows/LinuxVMやCTが30台くらい動いてしまっているので参考値ですが、VMが増えることによる極端な性能低下は起きないことが確認できます。

ただ、やはりケーブルの入手性が微妙なので高いコストを払ってまで揃えるか…というと微妙です。

また、ケーブルも型番をよく確認しないと実はQDRという可能性もあります。今回はMC2207シリーズでした。

FDRのケーブルはコネクタ付近にFDRというタグが付いているので、謎のケーブルとして安く転がっていたら買うのはありだと思います。

この記事を書いている時点ですでにFDRケーブルなんて10年前のものになるので、そのうちもっとゴミとして放出される気はします。

機会があれば100G Ether上での比較やHDRなどのIBで検証してみたいとは思います。

ただ、実際に使う上ではFDRやQDRでも十二分な性能が出ること、スイッチやHCAの消費電力や発熱を考えると逆にこの辺のほうが妥当な気もします…。

Related articles

• ページ:
  PVEでInfiniband+NFSoRDMAを使う
• ページ:
  DebianでのInfinibandのあれこれ
• ページ:
  DebianでConnect-IBが[Failed to get valid vendor specific ID]で認識できないとき
• ページ:
  LSI 9300-16iのファームウェアをアップデートする
• ページ:
  LSI のRAIDカードでJBODを有効にする