仮想マシンのリソース制限 - hitachi.co.jp · © Hitachi, Ltd. 2014. All rights reserved. 1. クラウドにおけるディスクI/Oの問題点 2. 仮想マシンのリソース制限

© Hitachi, Ltd. 2014. All rights reserved.

株式会社日立製作所横浜研究所運用管理システム研究部クラウドサービスプロジェクト

2014/01/20

西島直

日本OpenStackユーザ会第17回勉強会

仮想マシンのリソース制限


１. クラウドにおけるディスクI/Oの問題点

２. 仮想マシンのリソース制限

３. リソース制限した結果

Contents

1


1. クラウドにおけるディスクI/Oの問題点

2


1-1 クラウドにおけるディスクI/Oの問題点

3

仮想マシンのI/O性能が一定ではない

・昨日と今日でI/O性能が違う・I/Oの途中で極端に性能が悪くなる・I/Oを発行するタイミングによって性能にばらつきができる

・ホストマシンのI/O帯域を共有しているので他の仮想マシンがI/Oを発行している場合に影響がでる・仮想マシンだけでなくホストがログの書き込みなどI/Oを発行している・I/Oスケジューラにより仮想マシンのI/Oを公平にしようとしている

理由は様々な要因が絡んでる

仮想マシンの性能見積もりが難しい


1-2 クラウドにおけるディスクI/Oの実験

4

仮想マシンのI/O性能を一定にしたい

・Fedora19 + RDO havana(all in one)でディスクI/Oの性能実験・Xeon(R) CPU E3-1220の4コア/メモリ16G/1TB(SATA600 7200rpm) ・fioで計測、direct I/Oで10MBのファイルをシーケンシャルに60秒間書き込む・vm02は20秒から、vm03とvm04は40秒から書き込み開始

0

5

10

15

20

25

30

35

0 5 10 15 20 25 30 35 40 45 50 55

Mb

/s

秒

vm01 vm02 vm03 vm04

1VMで約25MB/s

4VM合計で約10MB/s


2. 仮想マシンのリソース制限

5


2-1 Instance Resource Quota

6

Yaguang Tang氏のパッチによってlibvirtがもつリソースチューニング機能を利用したフレーバーごとにCPUやdisk I/O, networkのリソース制限がGrizzlyから利用できるようになった

Libvirtのリソースチューニング機能とは？

Libvirtは仮想マシンの制御を抽象化したライブラリ。様々なハイパーバイザをサポートする。仮想マシンをドメインと呼び、ドメインを構成するファイルをXMLで記述している。XMLにはドメインの定義に必要なオプションや、使用するリソースなどがあり、その機能の一部として、cgroupsやQEMUの機能を用いたCPU TuningやBlock I/O Tuningなどがある。

commit 082c4ca417705975b8ef3672ce6ed40661d0f019 Author: Yaguang Tang <[email protected]> Date: Fri Feb 15 22:12:58 2013 +0800 Add libvirt XML schema support for resource tuning parameters Extend the libvirt XML config classes to support for CPU, disk IO, network traffic tuning parameters.

http://libvirt.org/formatdomain.html#elementsCPUTuning http://libvirt.org/formatdomain.html#elementsDisks

https://wiki.openstack.org/wiki/InstanceResourceQuota


2-2 CPUのリソース制限

7

nova-manage flavor set_key --name m1.small --key quota:cpu_shares --value 1024 nova-manage flavor set_key --name m1.small --key quota:cpu_period --value 500000 nova-manage flavor set_key --name m1.small --key quota:cpu_quota --value 1000000

• cpu_shares CPUを利用する時間の比重を指定する。他のVMの設定に基づく相対的な尺度なので値に単位はない。例えばvm01に2048の値が設定され、vm02に1024の値が設定されているとき、前者は後者より2倍のCPU時間を利用する

• cpu_period CPUを利用する時間の間隔（マイクロ秒単位）を指定する。値は1000～1000000が利用可能

• cpu_quota CPUの最大帯域幅（マイクロ秒単位）を指定する。値は1000～18446744073709551を指定する。マイナスの値は帯域幅制御されないことを意味する

実行例：

vm01 vm02

1サイクル

Quota:600msec Period:1000msec

vm01

1000msec

600msec 2 : 1


2-3 Network Trafficのリソース制限

8

nova-manage flavor set_key --name m1.small --key quota:vif_inbound_average --value 10240 nova-manage flavor set_key --name m1.small --key quota:vif_outbound_average --value 10240

• inbound_average, inbound_peak, inbound_burst inboundの平均ビットレート（kbps）を指定する。Averageは必須項目でその他は任意の項目。Peakはそのインターフェースが送信可能な最大帯域幅で、burstはピーク時にバーストできるバイト量を指定する

• outbound_average, outbound_peak, outbound_burst outboundの平均ビットレート（kbps）を指定する。Averageは必須項目でその他は任意の項目。Peakはそのインターフェースが受信可能な最大帯域幅で、burstはピーク時にバーストできるバイト量を指定する

実行例：

注意・Wikiのページは間違っている・inboud_*ではなくvif_inbound_* ・パッチの説明はvif_inbound_*となっている

修正しました


2-4 Disk I/Oのリソース制限

9

nova-manage flavor set_key --name m1.small --key quota:disk_read_bytes_sec --value 1024000 nova-manage flavor set_key --name m1.small --key quota:disk_write_bytes_sec --value 1024000

• total_bytes_sec 1秒間に利用可能なDisk I/Oのスループット量を指定する。read_bytes_secやwrite_bytes_secと同時に利用することはできない

• read_bytes_sec, write_byte_sec 1秒間に利用可能なDisk I/Oの読み込み（書き込み）スループット量を指定する

• total_iops_sec 1秒間に利用可能なDisk I/OのIOPSを指定する。read_iops_secやwrite_iops_secと同時に利用することはできない

• read_iops_sec, write_iops_sec 1秒間に利用可能なDisk I/Oの読み込み（書き込み）IOPSを指定する

実行例：

注意・Wikiのページは間違っている・正しくはdisk_*と”disk_*”が必要・IOPSせ設定する場合もdisk_が必要・パッチの説明はdisk_*となっている

修正しました


2-5 リソース制限したフレーバーの作成方法

10

読み込み、書き込みを1MB/sに制限したフレーバーを作成する

# nova flavor-create q1.small <flavor-id> 2048 20 1 # nova-manage flavor set_key --name q1.small --key quota:disk_read_bytes_sec --value 1024000 Key quota:read_bytes_sec set to 1024000 on instance type q1.small # nova-manage flavor set_key --name q1.small --key quota:disk_write_bytes_sec --value 1024000 Key quota:write_bytes_sec set to 1024000 on instance type q1.small

Horizonからでも設定が可能


2-6 リソース制限した仮想マシンの制限を確認

11

# nova boot --flavor <flavor-id> --image <image-id> --key-name <key-name> 1mb_limited … # cat /var/lib/nova/<uuid>/libvirt.xml … <devices> <disk type="file" device="disk"> <driver name="qemu" type="qcow2" cache="none"/> <source file="/var/lib/nova/instances/3dfed148-c592-4da0-bfe8-753be30528b0/disk"/> <target bus="virtio" dev="vda"/> <iotune> <read_bytes_sec>1024000</read_bytes_sec> <write_bytes_sec>1024000</write_bytes_sec> </iotune> </disk> …

仮想マシンのXMLを確認

<iotune>が追記された

読み込み、書き込み制限を確認

# virsh blkdeviotune instance-00000016 vda total_bytes_sec: 0 read_bytes_sec : 1024000 write_bytes_sec: 1024000 total_iops_sec : 0 read_iops_sec : 0 write_iops_sec : 0

1024kbの制限を確認


3. リソース制限した場合の実験結果

12


3-1 リソース制限の実験

13

・write性能が制限の通りになることが確認できた・4VMで14MB/sになり、制限なしより40%効率的に利用できた

以下の制限を課して性能測定した

・vm01は10MB/s, vm02は1MB/s, vm3は1MB/s, vm04は2MB/sのwrite制限

0

2

4

6

8

10

12

0 5 10 15 20 25 30 35 40 45 50 55

Mb

/s

秒

vm01 vm02 vm03 vm04


• 帯域幅を動的に変更することができない • リソースが余っているときは多くの帯域幅を利用したい • 例えば0秒から20秒は他のVMがいないので帯域を25MB/s利用し

他のVMのI/Oが開始された場合は帯域を制限する等

3-2 リソース制限の課題（１）

14

0

5

10

15

20

25

30

35

0 5 10 15 20 25 30 35 40 45 50 55

Mb

/s

秒

vm01 vm02 vm03 vm04

0

5

10

15

0 5 10 15 20 25 30 35 40 45 50 55

Mb

/s

秒

vm01 vm02 vm03 vm04


• 物理リソースの最大I/O帯域幅以上に設定が可能 • 全ての仮想マシンにI/O帯域の制限が必要

• 左の図はすべてのVMに制限を施した • 右の図はvm1だけ制限を課していない場合（or 物理リソース以上の帯域に

設定した場合）、vm1だけI/O帯域を確保し他のVMはI/O帯域が確保できない

3-3 リソース制限の課題（２）

15

0

1000

2000

3000

4000

5000

6000

vm1

vm2

vm3

vm4

0

1000

2000

3000

4000

5000

6000

vm1

vm2

vm3

vm4

limited vm1 is no limit

Kb/s

時間→ 時間→


• HavanaでCinder Volumeの帯域制限が可能になった（らしい） • Volume Typeに対応付ける

• Hypervisorかback-end、もしくは両方でQoSを実施する • 確かにソースにはそれらしきものがある

3-4 その他

16

[root@havana ~(keystone_admin)]# less nova/virt/libvirt/volume.py … def connect_volume(self, connection_info, disk_info): … # Extract rate_limit control parameters if 'qos_specs' in data and data['qos_specs']: tune_opts = ['total_bytes_sec', 'read_bytes_sec', 'write_bytes_sec', 'total_iops_sec', 'read_iops_sec', 'write_iops_sec'] specs = data['qos_specs'] if isinstance(specs, dict): for k, v in specs.iteritems(): if k in tune_opts: new_key = 'disk_' + k setattr(conf, new_key, v) …

• Cinderのコマンドでqos_specsが設定できる • cinder qos-create <name> write_bytes_sec=102400 consumer=front-end • cinder qos-associate <qos_specs> <volume_type_id>

• 実行してみる • 反映されない…


株式会社日立製作所横浜研究所運用管理システム研究部クラウドサービスプロジェクト

仮想マシンのリソース制限

2014/01/20

西島直

END

17

Documents

仮想マシンのリソース制限 - hitachi.co.jp · © Hitachi, Ltd. 2014. All rights reserved. 1. クラウドにおけるディスクI/Oの問題点 2. 仮想マシンのリソース制限