Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to 仮想化環境での利用者公平性
Similar to 仮想化環境での利用者公平性 (20)
More from Takuya ASADA
More from Takuya ASADA (20)
Recently uploaded
Recently uploaded (7)
仮想化環境での利用者公平性
- 2. 仮想化環境の公平性？ • KVMのゲストをたくさん立ち上げた時、ノード間 の通信性能やCPU利用時間の公平性はどの程度保 たれているのか • CPU利用時間 • 通信量 • レイテンシ • VM辺りの負荷のばらつき 12年11月20日火曜日
- 3. 測ってみよう • レイテンシ・通信量・CPU使用率などの面で どの程度公平なスケジュールが行われるのか • VM数を実CPU数以上に増やした時に何が起 きるか • 仮想NICとSR−IOVでは性能特性がどのよう に異なるか 12年11月20日火曜日
- 4. 性能測定環境 • ２台のLinux機・10G NIC • 1∼64台のKVMゲスト・128プロセスの netperf 1VM→VMあたり128フロー 2VM→VMあたり64フロー 4VM→VMあたり32フロー… 64VM→VMあたり2フロー • TCP Request/Responseモード 1byteのパケットをピンポン VMホスト ゲスト テスト機 10G NIC 10G NIC ゲスト netperf netserver netperf 12年11月20日火曜日
- 5. ハード／ソフトのスペック Distribution Ubuntu Server 12.10 Linux Kernel 3.5.0-18-generic QEMU-KVM 1.2.0 Netperf 2.5.0 CPU(VMホスト) Intel Core i7 980 (3.33GHz) Memory(VMホスト) 24GB CPU(テスト機) Intel Core i7 860 (2.8GHz) Memory(テスト機) 8GB NIC Intel 82599(ixgbe) 物理6コア、論理12コア 12年11月20日火曜日
- 6. ゲストマシンの設定 • 仮想CPU：1つ • 仮想NICの設定 • macvtapでbridge / vhost-net • SR-IOV • 512MBのメモリ割り当て 12年11月20日火曜日
- 7. おさらい：SR-IOV • 物理NICがVMに対して仮想NICを直接提供 IOはハイパーバイザーを介在せずに行われる • 割込みだけは仮想化出来ていないのでKVMを通じて転送される • 最も性能が高いがハード対応が必要／ゲストのパケットをフィルター・改変する事は難しい NIC カーネル カーネル ゲスト ユーザ PF PFドライバ qemu kvm VF ドライバ TCP/IP スタック NIC2 フォワード 割り込み 物理割り込み 割り込み 割込み ハンドラ VF DMAパススルー ハイパーバイザ 12年11月20日火曜日
- 8. macvtap <interface type='direct'> <mac address='52:54:00:6b:28:01'/> <source dev='eth1' mode='vepa'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> </interface> 12年11月20日火曜日
- 9. SR-IOV <hostdev mode='subsystem' type='pci' managed='yes'> <source> <address domain='0x0000' bus='0x04' slot='0x10' function='0x2'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </hostdev> 12年11月20日火曜日
- 10. 比較対象としての 実機性能測定 • ２台のLinux機・10G NIC • KVMゲストでnetserver実行 • 128プロセスのnetperf • TCP Request/Responseモード 1byteのパケットをピンポン VMホスト テスト機 10G NIC 10G NIC netperf netserver netperf netserver 12年11月20日火曜日
- 12. 秒間トランザクション数 0 1375.00 2750.00 4125.00 5500.00 1 2 4 8 16 32 64 vhost-net SR-IOV baremetal VM数 transaction/sec 物理コア数に近い辺りで 性能最高 12年11月20日火曜日
- 13. レイテンシ 0 750.00 1500.00 2250.00 3000.00 1 2 4 8 16 32 64 vhost-net SR-IOV baremetal VM数 レイテンシ値 物理コア数に近い辺りで レイテンシ最適 12年11月20日火曜日
- 14. CPU負荷 0 25.00 50.00 75.00 100.00 1 2 4 8 16 32 64 vhost-net SR-IOV baremetal VM数 パーセンテージ 負荷をVM数分のコア数に しか分散できてない 12年11月20日火曜日
- 15. VM間の偏り （ 秒間トランザクション数） 0 25.00 50.00 75.00 100.00 1 2 4 8 16 32 64 vhost-net SR-IOV VM数 パーセンテージ vhost-net < 10% SR-IOV < 30% 12年11月20日火曜日
- 16. VM間の偏り （ レイテンシ） 0 25.00 50.00 75.00 100.00 1 2 4 8 16 32 64 vhost-net SR-IOV VM数 パーセンテージ vhost-net < 10% SR-IOV < 30% 12年11月20日火曜日
- 17. VM間の偏り （ CPU負荷） 0 25.00 50.00 75.00 100.00 1 2 4 8 16 32 64 vhost-net SR-IOV VM数 パーセンテージ vhost-net < 10% SR-IOV < 20% 12年11月20日火曜日
- 18. 比較結果 • 物理コア数に近いVM数だと性能が一番良いように 見える • 物理コア数の10倍のVMを実行しても、この負荷パタ ーンでは極端なレイテンシの悪化や負荷の偏りなど は見られなかった • 物理環境と比べてかなり性能が悪い →負荷を複数コアへ分散出来ていない事が原因の候 補として考えられる 12年11月20日火曜日
- 20. 仮想環境上でコア分散？ • 仮想CPU数を1-16まで増やしてみる • コアを増やしただけではネットワークス タックが並列で走らない • ✕ RSS：仮想NIC・VFが未対応 • ○ RPS：ゲスト側Linuxの設定で有効化し てみる 12年11月20日火曜日
- 21. RPS $ echo "f" > /sys/class/net/eth1/queues/rx-0/ rps_cpus $ echo 4096 > /sys/class/net/eth1/queues/ rx-0/rps_flow_cnt $ echo 32768 > /proc/sys/net/core/ rps_sock_flow_entries 12年11月20日火曜日
- 23. 秒間トランザクション数 （vhost-net） 0 1375.00 2750.00 4125.00 5500.00 1 2 4 8 16 32 64 cpu1 cpu2 cpu4 cpu8 cpu16 baremetal VM数 transaction/sec VM =< 4ならやや改善 12年11月20日火曜日
- 24. 秒間トランザクション数 （vhost-net, RPS） 0 1375.00 2750.00 4125.00 5500.00 1 2 4 8 16 32 64 cpu1 cpu2 cpu4 cpu8 cpu16 baremetal VM数 transaction/sec VM =< 4ならRPSで 性能改善 12年11月20日火曜日
- 25. 秒間トランザクション数 （SR-IOV） 0 1375.00 2750.00 4125.00 5500.00 1 2 4 8 16 32 cpu1 cpu2 cpu4 cpu8 cpu16 baremetal VM数 transaction/sec VM =< 4ならやや改善 12年11月20日火曜日
- 26. 秒間トランザクション数 （SR-IOV, RPS） 0 1375.00 2750.00 4125.00 5500.00 1 2 4 8 16 32 cpu1 cpu2 cpu4 cpu8 cpu16 baremetal VM数 transaction/sec VM =< 4ならRPSで 性能改善 12年11月20日火曜日
- 27. レイテンシ （vhost-net） 0 750.00 1500.00 2250.00 3000.00 1 2 4 8 16 32 64 cpu1 cpu2 cpu4 cpu8 cpu16 baremetal VM数 レイテンシ値 tpsとだいたい同じ傾向 12年11月20日火曜日
- 28. レイテンシ （vhost-net, RPS） 0 750.00 1500.00 2250.00 3000.00 1 2 4 8 16 32 64 cpu1 cpu2 cpu4 cpu8 cpu16 baremetal VM数 レイテンシ値 tpsとだいたい同じ傾向 12年11月20日火曜日
- 29. レイテンシ （SR-IOV） 0 750.00 1500.00 2250.00 3000.00 1 2 4 8 16 32 cpu1 cpu2 cpu4 cpu8 cpu16 baremetal VM数 レイテンシ値 tpsとだいたい同じ傾向 12年11月20日火曜日
- 30. レイテンシ （SR-IOV, RPS） 0 750.00 1500.00 2250.00 3000.00 1 2 4 8 16 32 cpu1 cpu2 cpu4 cpu8 cpu16 baremetal VM数 レイテンシ値 tpsとだいたい同じ傾向 12年11月20日火曜日
- 31. CPU負荷 （vhost-net） 0 25.00 50.00 75.00 100.00 1 2 4 8 16 32 64 cpu1 cpu2 cpu4 cpu8 cpu16 VM数 パーセンテージ VM =< 4なら、cpu = 1 の時より負荷を分散で きている？ 12年11月20日火曜日
- 32. CPU負荷 （vhost-net, RPS） 0 25.00 50.00 75.00 100.00 1 2 4 8 16 32 64 cpu1 cpu2 cpu4 cpu8 cpu16 VM数 パーセンテージ RPSでより負荷を分散 12年11月20日火曜日
- 33. CPU負荷 （SR-IOV） 0 25.00 50.00 75.00 100.00 1 2 4 8 16 32 cpu1 cpu2 cpu4 cpu8 cpu16 VM数 パーセンテージ 12年11月20日火曜日
- 34. CPU負荷 （SR-IOV, RPS） 0 25.00 50.00 75.00 100.00 1 2 4 8 16 32 cpu1 cpu2 cpu4 cpu8 cpu16 VM数 パーセンテージ 12年11月20日火曜日
- 35. VM間の偏り （ 秒間トランザクション数／vhost-net） 0 25.00 50.00 75.00 100.00 1 2 4 8 16 32 64 cpu1 cpu2 cpu4 cpu8 cpu16 VM数 パーセンテージ cpu >= 8,VM >=16の時に 15%を超える偏り 12年11月20日火曜日
- 36. VM間の偏り （ 秒間トランザクション数/vhost-net, RPS） 0 25.00 50.00 75.00 100.00 1 2 4 8 16 32 64 cpu1 cpu2 cpu4 cpu8 cpu16 VM数 パーセンテージ cpu >= 8,VM >=16の時に 15%を超える偏り 12年11月20日火曜日
- 37. VM間の偏り （ 秒間トランザクション数／SR-IOV） 0 25.00 50.00 75.00 100.00 1 2 4 8 16 32 cpu1 cpu2 cpu4 cpu8 cpu16 VM数 パーセンテージ 総スレッド数が物理CPU数を 超えた辺りで大きな偏り 12年11月20日火曜日
- 38. VM間の偏り （ 秒間トランザクション数／SR-IOV, RPS） 0 25.00 50.00 75.00 100.00 1 2 4 8 16 32 cpu1 cpu2 cpu4 cpu8 cpu16 VM数 パーセンテージ 総スレッド数が物理CPU数を 超えた辺りで大きな偏り 12年11月20日火曜日
- 39. VM間の偏り （ レイテンシ／vhost-net） 0 25.00 50.00 75.00 100.00 1 2 4 8 16 32 64 cpu1 cpu2 cpu4 cpu8 cpu16 VM数 パーセンテージ tpsとだいたい同じ傾向 12年11月20日火曜日
- 40. VM間の偏り （ レイテンシ／vhost-net, RPS） 0 25.00 50.00 75.00 100.00 1 2 4 8 16 32 64 cpu1 cpu2 cpu4 cpu8 cpu16 VM数 パーセンテージ 12年11月20日火曜日
- 41. VM間の偏り （ レイテンシ／SR-IOV） 0 25.00 50.00 75.00 100.00 1 2 4 8 16 32 cpu1 cpu2 cpu4 cpu8 cpu16 VM数 パーセンテージ 総スレッド数が物理CPU数を 超えた辺りで大きな偏り 12年11月20日火曜日
- 42. VM間の偏り （ レイテンシ／SR-IOV, RPS） 0 25.00 50.00 75.00 100.00 1 2 4 8 16 32 cpu1 cpu2 cpu4 cpu8 cpu16 VM数 パーセンテージ 総スレッド数が物理CPU数を 超えた辺りで大きな偏り 12年11月20日火曜日
- 43. VM間の偏り （ CPU負荷／vhost-net） 0 25.00 50.00 75.00 100.00 1 2 4 8 16 32 64 cpu1 cpu2 cpu4 cpu8 cpu16 VM数 パーセンテージ あまり大きな偏 りは見られない 12年11月20日火曜日
- 44. VM間の偏り （ CPU負荷／vhost-net, RPS） 0 25.00 50.00 75.00 100.00 1 2 4 8 16 32 64 cpu1 cpu2 cpu4 cpu8 cpu16 VM数 パーセンテージ あまり大きな偏 りは見られない 12年11月20日火曜日
- 45. VM間の偏り （ CPU負荷／SR-IOV） 0 25.00 50.00 75.00 100.00 1 2 4 8 16 32 cpu1 cpu2 cpu4 cpu8 cpu16 VM数 パーセンテージ VM数の上昇で 若干増加 12年11月20日火曜日
- 46. VM間の偏り （ CPU負荷／SR-IOV, RPS） 0 25.00 50.00 75.00 100.00 1 2 4 8 16 32 cpu1 cpu2 cpu4 cpu8 cpu16 VM数 パーセンテージ VM数の上昇で 若干増加 12年11月20日火曜日
- 47. 比較結果 • 仮想マシンで実機性能の半分以上を出せたのはVM数がごく少なく vCPU数がかなり多い時のみ → この条件でしかRPSで性能が出ない • 総vCPU数を多くしても意外と性能は下がらない • SR-IOVの場合にVF数が物理コア数を超えた辺りでかなり性能に偏 りがでる • NIC上のキューに対して受信処理に割り当てるコアが不足して このような状況になると推測 • vhost-netではそのような現象が見られず、総vCPU数を増やしても 比較的公平に処理されているように見える 12年11月20日火曜日
- 51. cgroup tool install $ apt-get install cgroup-bin 12年11月20日火曜日
- 53. cd /sys/fs/cgroup/cpu $ mkdir grp_a $ echo ‘12254’ > grp_a/tasks $ echo ‘2184’ > grp_a/tasks $ echo ‘512’ > grp_a/cpu.shares $ mkdir grp_b $ echo ‘9012’ > grp_b/tasks $ echo ‘1024’ > grp_b/cpu.shares グループ作成 グループ所属プロセ スを追加（PID） グループ内のタスクで使用出来 るCPU時間の相対的配分値 12年11月20日火曜日
- 54. libvirtdとcgroup • /sys/fs/cgroup/cpu/libvirt/qemu/<VM名>に VM関連プロセスが自動登録される • /sys/fs/cgroup/cpu/libvirt/qemu/<VM名>/ vcpuNにvcpuプロセスが自動登録される • libvirt経由でcgroupのリソース制限設定 が出来る 12年11月20日火曜日
- 55. virshとcgroup $ virsh schedinfo vm0 Scheduler : posix cpu_shares : 1024 vcpu_period : 100000 vcpu_quota : -1 $ virsh schedinfo --set cpu_shares=512 vm0 12年11月20日火曜日
- 56. ２つのグループに公平にリ ソースを割り当ててみる • /sys/fs/cgroup/grp_a • VMインスタンス：６個 • cpu.shares：デフォルト（１０２４） • /sys/fs/cgroup/grp_b • VMインスタンス：１０個 • cpu.shares：デフォルト（１０２４） 12年11月20日火曜日
- 57. グループの作り方 $ virsh start <VM名> $ mkdir /sys/fs/cgroup/cpu/grp_a $ cat /sys/fs/cgroup/cpu/libvirt/qemu/<VM名>/tasks > tmp $ cat /sys/fs/cgroup/cpu/libvirt/qemu/<VM名>/ vcpu*/tasks >> tmp $ cat tmp > /sys/fs/cgroup/cpu/grp_a/tasks 12年11月20日火曜日
- 58. vhost-net/16VM時のCPU実行時間 （cgroup未使用時） 0 625000000 1250000000 1875000000 2500000000 実行時間 12年11月20日火曜日
- 61. vhost-net/16VM時のネットワークIO （cgroup使用時） 0 1375000 2750000 4125000 5500000 データ量 grp_a grp_b 12年11月20日火曜日
- 64. 比較結果 • グループに分けるだけでデフォルトでグループスケ ジューリングが行われ、実測値でもグループに対し て公平にCPUが配分されている事が確認できる • CPUを絞る事で結果的にネットワークIOを絞る事 もある程度出来ている • でもあまり厳密じゃない（実測14%くらいの誤差） 12年11月20日火曜日
- 65. CFS bandwidth control • このグループはcpu.cfs_period_usの単位時 間中に最大cpu.cfs_quota_usだけ実効出来る • グループ内のプロセスはperiod単位時間 中、同時に実行されうるのでquotaはperiod を超えうる（2CPUでめいいっぱい走った らquota = period * 2） 12年11月20日火曜日
- 69. 検証結果 • 確かにグラフ上は綺麗になるのだが、CPUがどんなに 空いていてもquotaまで行ったら絶対実行されない • かといって実行しきれない程のquotaを与えると設定し ない場合と変わらなくなる • CPUもネットワークIOもちょうどよくぴったり1.0とい う訳にはいかなかった • periodが長すぎるとVMが長い間実行されなくて良くな いことが起きそう 12年11月20日火曜日
- 70. net_cls $ tc class add dev virbr0 parent 10: classid 10:1 htb rate 24Mbit $ echo 0x100001 > /sys/fs/cgroup/net_cls/ grp_a/net_cls.classid プロセスから送信されるパケットにtcの タグを付ける事により帯域制限が出来る 12年11月20日火曜日
- 71. まとめ • KVMによる仮想化環境のリソース割り当ての公平性について 検証した • 今回の実験の条件下では、実CPU数を大きく超えるVM数で も極端なレイテンシの悪化や負荷の偏りなどは見られなか った • 但し、SR-IOVの場合にVF数が物理コア数を超えた辺りでか なり性能に偏りが発生した • cgroupを用いてマルチユーザ時にユーザ間のCPU割り当てを 公平に出来る事を確認した 12年11月20日火曜日