Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

仮想化環境での利用者公平性

2,600 views

Published on

Internet Week 2012

Published in: Technology

仮想化環境での利用者公平性

  1. 1. 仮想化環境での利用者公平性浅田 拓也 @syuu122812年11月20日火曜日
  2. 2. 仮想化環境の公平性?• KVMのゲストをたくさん立ち上げた時、ノード間の通信性能やCPU利用時間の公平性はどの程度保たれているのか• CPU利用時間• 通信量• レイテンシ• VM辺りの負荷のばらつき12年11月20日火曜日
  3. 3. 測ってみよう• レイテンシ・通信量・CPU使用率などの面でどの程度公平なスケジュールが行われるのか• VM数を実CPU数以上に増やした時に何が起きるか• 仮想NICとSR−IOVでは性能特性がどのように異なるか12年11月20日火曜日
  4. 4. 性能測定環境• 2台のLinux機・10G NIC• 1∼64台のKVMゲスト・128プロセスのnetperf1VM→VMあたり128フロー2VM→VMあたり64フロー4VM→VMあたり32フロー…64VM→VMあたり2フロー• TCP Request/Responseモード1byteのパケットをピンポンVMホストゲストテスト機10G NIC10G NICゲストnetperfnetservernetperf12年11月20日火曜日
  5. 5. ハード/ソフトのスペックDistribution Ubuntu Server 12.10Linux Kernel 3.5.0-18-genericQEMU-KVM 1.2.0Netperf 2.5.0CPU(VMホスト) Intel Core i7 980 (3.33GHz)Memory(VMホスト) 24GBCPU(テスト機) Intel Core i7 860 (2.8GHz)Memory(テスト機) 8GBNIC Intel 82599(ixgbe)物理6コア、論理12コア12年11月20日火曜日
  6. 6. ゲストマシンの設定• 仮想CPU:1つ• 仮想NICの設定• macvtapでbridge / vhost-net• SR-IOV• 512MBのメモリ割り当て12年11月20日火曜日
  7. 7. おさらい:SR-IOV• 物理NICがVMに対して仮想NICを直接提供 IOはハイパーバイザーを介在せずに行われる• 割込みだけは仮想化出来ていないのでKVMを通じて転送される• 最も性能が高いがハード対応が必要/ゲストのパケットをフィルター・改変する事は難しいNICカーネルカーネルゲストユーザPFPFドライバqemukvmVFドライバTCP/IPスタックNIC2フォワード割り込み物理割り込み割り込み割込みハンドラVFDMAパススルーハイパーバイザ12年11月20日火曜日
  8. 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=0x00slot=0x07 function=0x0/></interface>12年11月20日火曜日
  9. 9. SR-IOV<hostdev mode=subsystem type=pci managed=yes><source><address domain=0x0000 bus=0x04slot=0x10 function=0x2/></source><address type=pci domain=0x0000 bus=0x00slot=0x04 function=0x0/></hostdev>12年11月20日火曜日
  10. 10. 比較対象としての実機性能測定• 2台のLinux機・10G NIC• KVMゲストでnetserver実行• 128プロセスのnetperf• TCP Request/Responseモード1byteのパケットをピンポンVMホストテスト機10G NIC10G NICnetperfnetservernetperfnetserver12年11月20日火曜日
  11. 11. VM数を1-64まで増加vhost-netとSR-IOV比較12年11月20日火曜日
  12. 12. 秒間トランザクション数01375.002750.004125.005500.001 2 4 8 16 32 64vhost-net SR-IOVbaremetalVM数transaction/sec物理コア数に近い辺りで性能最高12年11月20日火曜日
  13. 13. レイテンシ0750.001500.002250.003000.001 2 4 8 16 32 64vhost-net SR-IOVbaremetalVM数レイテンシ値物理コア数に近い辺りでレイテンシ最適12年11月20日火曜日
  14. 14. CPU負荷025.0050.0075.00100.001 2 4 8 16 32 64vhost-net SR-IOVbaremetalVM数パーセンテージ負荷をVM数分のコア数にしか分散できてない12年11月20日火曜日
  15. 15. VM間の偏り( 秒間トランザクション数)025.0050.0075.00100.001 2 4 8 16 32 64vhost-net SR-IOVVM数パーセンテージvhost-net < 10%SR-IOV < 30%12年11月20日火曜日
  16. 16. VM間の偏り( レイテンシ)025.0050.0075.00100.001 2 4 8 16 32 64vhost-net SR-IOVVM数パーセンテージvhost-net < 10%SR-IOV < 30%12年11月20日火曜日
  17. 17. VM間の偏り( CPU負荷)025.0050.0075.00100.001 2 4 8 16 32 64vhost-net SR-IOVVM数パーセンテージvhost-net < 10%SR-IOV < 20%12年11月20日火曜日
  18. 18. 比較結果• 物理コア数に近いVM数だと性能が一番良いように見える• 物理コア数の10倍のVMを実行しても、この負荷パターンでは極端なレイテンシの悪化や負荷の偏りなどは見られなかった• 物理環境と比べてかなり性能が悪い→負荷を複数コアへ分散出来ていない事が原因の候補として考えられる12年11月20日火曜日
  19. 19. 仮想環境上で複数コアへネットワークIO負荷分散させた時の性能12年11月20日火曜日
  20. 20. 仮想環境上でコア分散?• 仮想CPU数を1-16まで増やしてみる• コアを増やしただけではネットワークスタックが並列で走らない• ✕ RSS:仮想NIC・VFが未対応• ○ RPS:ゲスト側Linuxの設定で有効化してみる12年11月20日火曜日
  21. 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_entries12年11月20日火曜日
  22. 22. vCPU<vcpu placement=static>16</vcpu>12年11月20日火曜日
  23. 23. 秒間トランザクション数(vhost-net)01375.002750.004125.005500.001 2 4 8 16 32 64cpu1 cpu2 cpu4cpu8 cpu16 baremetalVM数transaction/secVM =< 4ならやや改善12年11月20日火曜日
  24. 24. 秒間トランザクション数(vhost-net, RPS)01375.002750.004125.005500.001 2 4 8 16 32 64cpu1 cpu2 cpu4cpu8 cpu16 baremetalVM数transaction/secVM =< 4ならRPSで性能改善12年11月20日火曜日
  25. 25. 秒間トランザクション数(SR-IOV)01375.002750.004125.005500.001 2 4 8 16 32cpu1 cpu2 cpu4cpu8 cpu16 baremetalVM数transaction/secVM =< 4ならやや改善12年11月20日火曜日
  26. 26. 秒間トランザクション数(SR-IOV, RPS)01375.002750.004125.005500.001 2 4 8 16 32cpu1 cpu2 cpu4cpu8 cpu16 baremetalVM数transaction/secVM =< 4ならRPSで性能改善12年11月20日火曜日
  27. 27. レイテンシ(vhost-net)0750.001500.002250.003000.001 2 4 8 16 32 64cpu1 cpu2 cpu4cpu8 cpu16 baremetalVM数レイテンシ値tpsとだいたい同じ傾向12年11月20日火曜日
  28. 28. レイテンシ(vhost-net, RPS)0750.001500.002250.003000.001 2 4 8 16 32 64cpu1 cpu2 cpu4cpu8 cpu16 baremetalVM数レイテンシ値tpsとだいたい同じ傾向12年11月20日火曜日
  29. 29. レイテンシ(SR-IOV)0750.001500.002250.003000.001 2 4 8 16 32cpu1 cpu2 cpu4cpu8 cpu16 baremetalVM数レイテンシ値tpsとだいたい同じ傾向12年11月20日火曜日
  30. 30. レイテンシ(SR-IOV, RPS)0750.001500.002250.003000.001 2 4 8 16 32cpu1 cpu2 cpu4cpu8 cpu16 baremetalVM数レイテンシ値tpsとだいたい同じ傾向12年11月20日火曜日
  31. 31. CPU負荷(vhost-net)025.0050.0075.00100.001 2 4 8 16 32 64cpu1 cpu2 cpu4cpu8 cpu16VM数パーセンテージVM =< 4なら、cpu = 1の時より負荷を分散できている?12年11月20日火曜日
  32. 32. CPU負荷(vhost-net, RPS)025.0050.0075.00100.001 2 4 8 16 32 64cpu1 cpu2 cpu4cpu8 cpu16VM数パーセンテージRPSでより負荷を分散12年11月20日火曜日
  33. 33. CPU負荷(SR-IOV)025.0050.0075.00100.001 2 4 8 16 32cpu1 cpu2 cpu4cpu8 cpu16VM数パーセンテージ12年11月20日火曜日
  34. 34. CPU負荷(SR-IOV, RPS)025.0050.0075.00100.001 2 4 8 16 32cpu1 cpu2 cpu4cpu8 cpu16VM数パーセンテージ12年11月20日火曜日
  35. 35. VM間の偏り( 秒間トランザクション数/vhost-net)025.0050.0075.00100.001 2 4 8 16 32 64cpu1 cpu2 cpu4cpu8 cpu16VM数パーセンテージcpu >= 8,VM >=16の時に15%を超える偏り12年11月20日火曜日
  36. 36. VM間の偏り( 秒間トランザクション数/vhost-net, RPS)025.0050.0075.00100.001 2 4 8 16 32 64cpu1 cpu2 cpu4cpu8 cpu16VM数パーセンテージcpu >= 8,VM >=16の時に15%を超える偏り12年11月20日火曜日
  37. 37. VM間の偏り( 秒間トランザクション数/SR-IOV)025.0050.0075.00100.001 2 4 8 16 32cpu1 cpu2 cpu4cpu8 cpu16VM数パーセンテージ総スレッド数が物理CPU数を超えた辺りで大きな偏り12年11月20日火曜日
  38. 38. VM間の偏り( 秒間トランザクション数/SR-IOV, RPS)025.0050.0075.00100.001 2 4 8 16 32cpu1 cpu2 cpu4cpu8 cpu16VM数パーセンテージ総スレッド数が物理CPU数を超えた辺りで大きな偏り12年11月20日火曜日
  39. 39. VM間の偏り( レイテンシ/vhost-net)025.0050.0075.00100.001 2 4 8 16 32 64cpu1 cpu2 cpu4cpu8 cpu16VM数パーセンテージtpsとだいたい同じ傾向12年11月20日火曜日
  40. 40. VM間の偏り( レイテンシ/vhost-net, RPS)025.0050.0075.00100.001 2 4 8 16 32 64cpu1 cpu2 cpu4cpu8 cpu16VM数パーセンテージ12年11月20日火曜日
  41. 41. VM間の偏り( レイテンシ/SR-IOV)025.0050.0075.00100.001 2 4 8 16 32cpu1 cpu2 cpu4cpu8 cpu16VM数パーセンテージ総スレッド数が物理CPU数を超えた辺りで大きな偏り12年11月20日火曜日
  42. 42. VM間の偏り( レイテンシ/SR-IOV, RPS)025.0050.0075.00100.001 2 4 8 16 32cpu1 cpu2 cpu4cpu8 cpu16VM数パーセンテージ総スレッド数が物理CPU数を超えた辺りで大きな偏り12年11月20日火曜日
  43. 43. VM間の偏り( CPU負荷/vhost-net)025.0050.0075.00100.001 2 4 8 16 32 64cpu1 cpu2 cpu4cpu8 cpu16VM数パーセンテージあまり大きな偏りは見られない12年11月20日火曜日
  44. 44. VM間の偏り( CPU負荷/vhost-net, RPS)025.0050.0075.00100.001 2 4 8 16 32 64cpu1 cpu2 cpu4cpu8 cpu16VM数パーセンテージあまり大きな偏りは見られない12年11月20日火曜日
  45. 45. VM間の偏り( CPU負荷/SR-IOV)025.0050.0075.00100.001 2 4 8 16 32cpu1 cpu2 cpu4cpu8 cpu16VM数パーセンテージVM数の上昇で若干増加12年11月20日火曜日
  46. 46. VM間の偏り( CPU負荷/SR-IOV, RPS)025.0050.0075.00100.001 2 4 8 16 32cpu1 cpu2 cpu4cpu8 cpu16VM数パーセンテージVM数の上昇で若干増加12年11月20日火曜日
  47. 47. 比較結果• 仮想マシンで実機性能の半分以上を出せたのはVM数がごく少なくvCPU数がかなり多い時のみ → この条件でしかRPSで性能が出ない• 総vCPU数を多くしても意外と性能は下がらない• SR-IOVの場合にVF数が物理コア数を超えた辺りでかなり性能に偏りがでる• NIC上のキューに対して受信処理に割り当てるコアが不足してこのような状況になると推測• vhost-netではそのような現象が見られず、総vCPU数を増やしても比較的公平に処理されているように見える12年11月20日火曜日
  48. 48. マルチユーザ時の公平性12年11月20日火曜日
  49. 49. マルチユーザ時の公平性• デフォルトスケジューリングでは、全てのKVMゲストプロセスが公平にCPU時間を割り当てられる→複数のユーザが複数のVMを起動している場合、ユーザ辺りのリソース割当が不公平になる• ユーザ間で公平にスケジューリングして欲しい12年11月20日火曜日
  50. 50. cgroup• プロセスグループに対してリソース(CPU、メモリ、ディスクI/O、ネットワークI/O)の利用を制限・隔離する為のLinuxの機能12年11月20日火曜日
  51. 51. cgroup tool install$ apt-get install cgroup-bin12年11月20日火曜日
  52. 52. $ ls /sys/fs/cgroupblkio ブロックI/Oの制限cpu CPUリソースの制限cpuacct CPUの走行時間などの情報収集cpuset CPUの割り付けに関する制限devices デバイスへのアクセス許可・拒否freezer グループに属するプロセスの一時停止・再開memory メモリリソースの制限net_cls 送出パケットにtc用のタグを設定ns ネームスペース(コンテナ用)12年11月20日火曜日
  53. 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. 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. 55. virshとcgroup$ virsh schedinfo vm0Scheduler : posixcpu_shares : 1024vcpu_period : 100000vcpu_quota : -1$ virsh schedinfo --set cpu_shares=512 vm012年11月20日火曜日
  56. 56. 2つのグループに公平にリソースを割り当ててみる• /sys/fs/cgroup/grp_a• VMインスタンス:6個• cpu.shares:デフォルト(1024)• /sys/fs/cgroup/grp_b• VMインスタンス:10個• cpu.shares:デフォルト(1024)12年11月20日火曜日
  57. 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/tasks12年11月20日火曜日
  58. 58. vhost-net/16VM時のCPU実行時間(cgroup未使用時)0625000000125000000018750000002500000000実行時間12年11月20日火曜日
  59. 59. vhost-net/16VM時のCPU実行時間(cgroup使用時)0625000000125000000018750000002500000000実行時間grp_a grp_b12年11月20日火曜日
  60. 60. vhost-net/16VM時のネットワークIO(cgroup未使用時)01375000275000041250005500000データ量12年11月20日火曜日
  61. 61. vhost-net/16VM時のネットワークIO(cgroup使用時)01375000275000041250005500000データ量grp_a grp_b12年11月20日火曜日
  62. 62. グループごとの合計値比較(cgroup使用時)00.501.001.502.00CPU Netgrp_a grp_b1.101.1412年11月20日火曜日
  63. 63. [参考]グループごとの合計値比較(cgroup未使用時)00.501.001.502.00CPU Netgrp_a grp_b1.641.6512年11月20日火曜日
  64. 64. 比較結果• グループに分けるだけでデフォルトでグループスケジューリングが行われ、実測値でもグループに対して公平にCPUが配分されている事が確認できる• CPUを絞る事で結果的にネットワークIOを絞る事もある程度出来ている• でもあまり厳密じゃない(実測14%くらいの誤差)12年11月20日火曜日
  65. 65. CFS bandwidth control• このグループはcpu.cfs_period_usの単位時間中に最大cpu.cfs_quota_usだけ実効出来る• グループ内のプロセスはperiod単位時間中、同時に実行されうるのでquotaはperiodを超えうる(2CPUでめいいっぱい走ったらquota = period * 2)12年11月20日火曜日
  66. 66. vhost-net/16VM時のCPU実行時間(quota=200000,period=50000)0625000000125000000018750000002500000000実行時間grp_a grp_b12年11月20日火曜日
  67. 67. vhost-net/16VM時のネットワークIO(quota=200000,period=50000)01375000275000041250005500000データ量grp_a grp_b12年11月20日火曜日
  68. 68. グループごとの合計値比較(quota=200000,period=50000)00.501.001.502.00CPU Netgrp_a grp_b1.010.6312年11月20日火曜日
  69. 69. 検証結果• 確かにグラフ上は綺麗になるのだが、CPUがどんなに空いていてもquotaまで行ったら絶対実行されない• かといって実行しきれない程のquotaを与えると設定しない場合と変わらなくなる• CPUもネットワークIOもちょうどよくぴったり1.0という訳にはいかなかった• periodが長すぎるとVMが長い間実行されなくて良くないことが起きそう12年11月20日火曜日
  70. 70. net_cls$ tc class add dev virbr0 parent 10: classid10:1 htb rate 24Mbit$ echo 0x100001 > /sys/fs/cgroup/net_cls/grp_a/net_cls.classidプロセスから送信されるパケットにtcのタグを付ける事により帯域制限が出来る12年11月20日火曜日
  71. 71. まとめ• KVMによる仮想化環境のリソース割り当ての公平性について検証した• 今回の実験の条件下では、実CPU数を大きく超えるVM数でも極端なレイテンシの悪化や負荷の偏りなどは見られなかった• 但し、SR-IOVの場合にVF数が物理コア数を超えた辺りでかなり性能に偏りが発生した• cgroupを用いてマルチユーザ時にユーザ間のCPU割り当てを公平に出来る事を確認した12年11月20日火曜日

×