PVEのWindows 10ゲストでSR-IOVのVFが動いた！
Proxmox VE 6.3とConnectX-3を使って、ゲストのWindows 10 ProfessionalでSR-IOVのVirtual Functionが動いたぞー！デバイスマネージャで認識させるところまでは楽勝だったが、何度ドライバ当て直してもエラーコード43で動かなくて随分苦労した。結局、PVEのビルトインドライバが古かったのが原因だったけど、それはまた後日。
見せてもらおうか、SR-IOVの性能とやらを！
物理マシンのWindows 10と、PVE上の仮想マシンのWindows 10をConnectX-3の40GBASE-SR接続した環境で、MS謹製ネットワーク性能測定ツールNTttcpを使い速度を測った。物理マシンが送信側、VMが受信側とした結果は下図のとおり。
右下のアクティブなタスクマネージャが物理側で、他のウィンドウはリモートデスクトップ経由のVM側だ。26Gbpsほど出ているのがわかる。同じ条件でVM側をvirtio-netとすると12Gbps程度だった。速度も然ることながらPVEのCPU負荷が段違いなので、さすがSR-IOV。
なお、最大瞬間風速で32Gbps程度出ることは確認した。
FreeBSDのif_bridgeが5倍速くなるらしい
FreeBSDのネットワークブリッジ機能、if_bridge(4)が遅いってのは以前書いたとおりなのだけど、今後、おおむね5倍に高速化される見込みらしい。
FreeBSD Foundationの記事によれば、現状のif_bridgeは、重いBRIDGE_LOCK mutexのせいで、CPUのコア数によらずスループットは最大3.7Mpps程度に制限される。この度、Kristof ProvostがFreeBSD 13-CURRENT上でロックフリーのepoch(9)を使った実装にしたところ、概ね18.6Mppsのパケットフォワードが行え、5倍の改善となったとのこと。
これはなかなかムネアツ。
一方で、現状の実装でも3.7Mpps出るってことは、最大フレームなら理屈上41Gbpsの帯域を有するハズ。にもかかわらず、iperfの実測で3.5Gbpsほどに止まるのは何でだろーなー。全二重通信で帯域が分割される点を考慮しても低すぎのような気が。
参考サイト
FreeBSDのL2ブリッジ（if_bridge）は本当に遅かった
FreeBSDでL2ブリッジを有効にするとネットワーク性能が激烈に落ちるという話がある。なんでも、ブリッジの実装であるif_bridge(4)に存在するたくさんの最適化されてないロックのせいで性能劣化を引き起こしてるとか。
いやいや、いくら何でもそんなに変わらんやろ？と思い、ブリッジの有無でiperfしてみたら、ブリッジ有りの方でありえないほど遅くなって草も生えないんですが。
測定環境は下表の通り。ネットワークまわりのチューニングとかは特にしてない。
| サーバ | クライアント | |
|---|---|---|
| OS | FreeBSD 12.0-RELEASE-p4 amd64 | Windows 10 Pro 1903 x64 |
| CPU | Xeon E5-2648Lv3 | Ryzen 1700 |
| NIC | ConnectX-3 Pro EN (L2SW経由で40Gb接続) | |
| ソフト | iperf 2.0.13 | iperf 2.0.14a |
ご覧の通り、現状のif_bridgeは1GbEには十分だけど、10GbE以上の環境では完全ボトルネックとなってしまう。bhyve使うときに割と困るぞこれ…。
参考サイト
- > if_bridge(4), specially bridge_input() uses lot's of LOCK: Avoid to use it.
- ブリッジ使う、使わない時のコールグラフが載っている
FreeBSDのkern.random.harvest.maskについて
FreeBSDのネットワークチューニングについて調べてると「random harvestを最適化せよ」という指示が随所で出てくる。ネットワークなのに乱数？と不思議に思って調べたメモ。ここで書くことは、全て一次ソースのrandom(4)とrandom_harvest(9)に書いてあり、FreeBSD 12.1-RELEASE時点での情報である。
まずはrandom harvestについて。
FreeBSDは乱数を返すスペシャルファイル/dev/randomを持つが、通常、その実態は擬似乱数生成器となっている。つまり数式で求められた確定的な乱数っぽい数値を返しているに過ぎず、乱数っぽさの維持にはエントロピーの質が重要となる。FreeBSDでは、エントロピーの収集のことをrandom harvestと呼んでいるようだ。良質なエントロピーを育み利用する、という感じなので“harvest”はなかなか的を射た呼び方だと思う。
そのエントロピー収穫先を制御するのがkern.random.harvest.maskカーネル変数というわけ。
値は収穫先ごとのビットフラグで、1ならエントロピー源として使う、0なら使わないことを意味する。10進数のマスク値を見ても良くわからないので、エイリアスであるmask_symbolicやmask_binを見た方がいいだろう。うちの環境では以下のとおりだった。
$ sysctl kern.random kern.random.fortuna.minpoolsize: 64 kern.random.harvest.mask_symbolic: PURE_RDRAND,[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED kern.random.harvest.mask_bin: 00000010000000111111111 kern.random.harvest.mask: 66047 kern.random.random_sources: 'Intel Secure Key RNG'
mask_binがmask値の2進数表現、mask_symbolicがmaskを更に読みやすくしたシステムで利用可能なエントロピー源の一覧で、[]で囲まれた収穫先は使われていないことを意味する。FreeBSD 12.1-RELEASE時点で、24個のエントロピー源が定義されているようだ(sys/sys/random.h)。
ご覧の通りNET_ETHERもエントロピー源として使われている。それがなぜネットワーク性能に影響するかというと、エントロピー収穫の際のロック競合が少なくない影響を及ぼしているとのことだ。とりわけ、10ギガビット以上の高速ネットワークではバカにならないそうで。なるほどねー。
参考サイト
世界最安の40GbE対応スイッチCRS326-24S+2Q+RMがやってきた！
真っ当な流通ルートで購入できるものでは世界最安1)と思われる40GbE対応スイッチ、CRS326-24S+2Q+RMがやってきた！流石は俺たちのMikroTik！！とかいいつつ、同社の製品を買うのは初めてだったりする。
このページに辿り着くくらいの人には釈迦に説法だろうけど、CRS326-24S+2Q+RMは10ギガビット対応のSFP+ポートを24個、加えて40ギガビット対応のQSFP+ポートを2つ備えながら499ドルという超破格を実現した頭おかしいスイッチである。普通に考えたら499ドルは結構な額だが、この性能でこの額は本当に価格破壊もいいところ。しかもEuroDKでは384ドルで売ってる（）。マジでありえん。
というわけで誘惑に勝てずに買ってしまった。8/22(木)に注文して26(月)に配達される40GbE顔負けの高速配送っぷりだったけど、結局受け取りは週末までお預け。送料やら消費税やらで、最終的に448ドル＋1900円となった。
設置場所の問題やらMPOケーブル不足やらで本格的には試せてないが、ひとまず下表環境のiperf3 (MTU=1500)で28Gbpsほど出ることは確認。
| サーバ | クライアント | |
|---|---|---|
| OS | FreeBSD 11.2-RELEASE (x64) | Windows 10 Pro. (x64) |
| M/B | Supermicro X10DRi | MSI X370 SLI PLUS |
| CPU | Xeon E5-2648L v3 @1.8GHz | Ryzen 7 1700 @3.0GHz |
| RAM | Registered DDR4-2400 16GB×4 (2133MHz駆動) | DDR4-2666 16GB×4 |
| NIC | ConnectX-3 Pro EN (PCIe 3.0x8) | |
使われてるスイッチチップは98DX8332っぽい。明言はされてないけど、2.5GbE/5GbEにも対応してる予感…？ポートの速度設定画面にチェックボックスがあるんですけど……。
OSはRouterOSとSwOSのデュアル対応なので、一応L3の処理も可能。だけどスイッチチップで処理できないものはCPU処理となるうえ、内部リンクは1Gbpsなので折角の性能が死ぬ。なので素直にL2スイッチとして使うか、軽めのフィルタでWANを受けるとかに留めるのが吉。幸い10Gポートは腐るほどあるからLAG組んでL3処理は上位ルータに投げてしまえばいいかと。AT-x510-28GTXも泣いて喜ぶね！
ざっくり消費電力は以下の通り。
| 状況 | 消費電力 |
|---|---|
| 待機（SFPモジュールは一切挿してない状態） | 13W |
| 待機（40GBASE-SR4×2でリンクアップ） | 15～16W |
| 40GBASE-SR4でiperf実行 | 17W |
出荷時のRouterOSバージョンではファンが結構うるさいが、6.45.5に更新したらかなり静かになった。基本は停止、内部温度に応じて回転数可変のなかなかアグレッシブな制御をしてくれるようになる。消費電力とあわせて一般のご家庭にも大変やさしい仕様と言える。ありがとうMikroTik。なお、回転時はそれなりに音がする。風切り音よりファン自体の回転音が大きい感じ。個人的には許容範囲内だけど気になる人は気になると思われる。