はじめに
vNICのオプション機能であるvirtio-net multi-queueについて解説します。
What’s This?
詳しくはこちらをご覧ください。
ざっくり述べると、トラフィックの処理はデフォルトでは1つのvCPUしか使用されていませんが、それを2つ以上にする技術です。関連してそうな記事貼っておきます。
WIndowsの場合、VirtIOの詳細設定を確認すると、「Maximum Number of RSS Queues」があります。
デフォルトで16が設定されており、これが意味することは「最大16個のvCPUをトラフィックの処理に使用することができる」ということです。
ただし、こちらあくまでもOS(正確にはNIC)目線の設定となり、vNICに専用の設定を反映させることで、初めて受信トラフィック処理に使用可能なvCPU数を増やすことができます。
今回、2台のWindows Serverを用いて検証を行ってみたいと思います。
検証方法
2つのWindows Serverを構築し、それぞれ異なるノードに配置します。
※192.168.0.148と表示されておりますが、192.168.0.52のIPアドレスを付与しております。
VMを右クリック > Migrateを行った後、VMの更新にて、「この仮想マシンをエージェント仮想マシンとして使用」を有効化しました。
こうすることで、この2つのVMは現在稼働しているノードからマイグレーションされることはありません。
その後、フォルダ内に1024KBサイズの空ファイルを1000個作成します。
そして、Windows-Server-2022-1からWindows-Server-2022-2へ1000個のファイルをもう一つのサーバにコピーします。
この時、コピーが完了するまでの時間やスループットの変化を確認したいと思います。
なぜ、容量の少ないファイルを大量に、NWを介してコピーする検証をすることで、パフォーマンスの変化が期待できるのかと言うと、ファイルの各々にTCPコネクションを張る作業を短期間で大量に行うことが想定されるので、この処理を行うvCPU数が1から2以上に増加すれば、スループットの向上が見込まれると仮定したからです。
こうした、サイズの小さいファイルを大量に転送する場合、スループットがかなり悪いです。スループットが上がりきる前にファイル転送が完了してしまうためです。
気になる方は、1000個で合計1GiBのファイル、1個で1GiBのファイルをNW経由で転送してみてください。スループットが全く異なります。
検証
デフォルトの状態
約36秒 約30KB/s前後で推移
※実際は5回程度行いました。
設定変更
任意のCVMからnutanixユーザーで次のコマンドを実行します。
acli vm.shutdown Windows-Server-2022-2 acli vm.nic_update Windows-Server-2022-2 50:6b:8d:82:19:ba queues=4 acli vm.on Windows-Server-2022-2
設定変更後
約28秒 約35-40KB/sで推移
※実際は5回程度行いました。
設定変更をするまでは何度トライしても35KB/sを超えることはありませんでしたが、設定変更後は超えるようになりました。
今回の場合、約20%程度ファイル転送が速くなりました。
VMに搭載されているvCPUの数、そのVMが常時使用しているvCPU数やCPU使用率、Top Of Rackの性能、帯域の混雑具合など、様々な要素に影響を受けるので、検証結果については、あくまでも参考程度となります。
管理人が社内環境を用いて検証した場合は1.5~2倍のスループットを達成しました。
そのため、商用環境で使用する場合は、必ず検証を行いましょう。
注意事項
- vCPUを余分に使うのでCPU使用率が増加します。といっても数%程度ですが。
- VMに割り当てたvCPU数を超えるとCPU Ready Timeが増加してパフォーマンス低下に繋がります。
- 商用環境で使用する場合は厳密なテストを行ったうえで導入を検討してください。
コメント