Control Groups/Linux Container を利用した KVM のリソース制御と
性能評価に関するレポート
2011/02/28
サービスディベロップメントグループ 船ヶ山 慶
研究背景
現在の仮想化技術にあるハイパーバイザー型の問題点として、ゲスト OS(以後 VM)の SLA(Service Level Agreement)、Oos(Quality of Service)が完全に出来ていないことが挙げられ る。※１
そこで、kernel 2.6.27 より kernel にマージされた Control Groups(以後 cgroups)を利用し、 VM の統合リソース制御が行えるか調査し、その性能評価を行う。
今回の性能評価では、マルチコア CPU のリソース制御、ディスク IO 制御、ネットワーク制 御を調査する。※２
また、今回利用した Linux Container(以後 lxc)も合わせて調査する。
※今回のレポートでは NUMA(Non-Uniform Memory Access)については触れない。
※１ Xen には、dm-ioband といったようなディスク I/O 帯域制御ドライバなどがあるが、リソ ース全体をカバーしておらず十分でない。 ※２ メモリについては、すでに KVM や他の仮想化技術でサポートされているため調査しない。
cgroups(Control Groups)
概要
特定のプロセス及びプロセスグループ※３を分離し、リソース管理を行う仕組みで従来の Linux リソース管理をより柔軟、高度に管理する事を目的とした技術である。ライブラリには、libcgroup.so が用意されており、libvirt や後述する Linux Containers もこれを 利用している。
cgroups は Kernel 2.6.27 から追加され、kernel 2.6.29 で全機能をサポートされました。 ライセンスは GPLv2 で、RHEL6 に標準搭載されています。
※３ cgroups では複数のプロセスをまとめて管理することができる。もちろん１プロセスも管 理も可能である。以後文章では、１プロセスも複数のプロセスもプロセスグループで統一する。
cgroup 用語
● cgroup ○ 複数のサブシステムと複数のプロセス(task)をグルーピングし、システムに関連 付けます。 ● サブシステム(subsystem) ○ cgroups によって提供されるリソースコントローラ(スケジューリング、割り当 て)を制御、設定するのに利用します。 ● 階層(hierarchy) ○ 階層構造で表現された cgroup の集まりを表現しています。 ■cgroup 同士の親子関係を表現できます。 ○ プロセスグループ毎にサブシステムと階層が存在します。 ○ 階層内はすべてアクセス権限を変更する事で、root でなくても操作することが可 能です。利用イメージ
以下の図は、各種システムリソースを cgroups で割り振った場合の例である。 ＃A ではユーザ別、＃B ではプロセスグループ別と状況に応じた柔軟なリソース制御を提供し ています。構成と図解（Fedora 14 base）
以下の図はユーザが操作可能なライブラリ、設定ファイル、ファイルシステムです。
● libcg API
○ プロセスグループの作成、編集、削除、アクセス権限等の操作を行う事ができま す。 ● 設定ファイル※４ ○ cgconfig.conf ■cgroup ファイルシステムのマウント情報等の定義を行います。 cgconfigparser を利用しロードします。 ○ cgrules.conf ■プロセスグループを利用可能なグループ、ユーザの指定を行います。 ■cgrulesengd を利用しロードします。 ● ファイルシステム ○ /cgroup を cgroups ファイルシステムとして利用することで、直接操作すること ができます。 ※４ Fedora 14 では図のような構成になっているが、設定次第でどのような構成も取れる様に なっています。 また、Fedora 14 では/sbin/cgconfigparser、/sbin/gcrulesengd 用の起動スクリプトが別途提供 されています。
リソース制御
CPU
CPU のリソース制御では、コアの指定やプロセスグループ単位での重み付けで制御を行うこ とできます。cgroup ファイルシステムからの設定例
guest1 が使用する CPU コアを変更します。 guest1 が現在使用している CPU コアを表示 # cat /cgroup/guest1/cpuset.cpus 0 guest1 の CPU コアを 1 に変更 # echo "1" > /cgroup/guest1/cpuset.cpus guest1 が現在使用している CPU コアを表示(確認) # cat /cgroup/guest1/cpuset.cpus 1＃A は、VM(プロセス)別にコアを指定する場合の図解です。 ＃B は、一つのコアにプロセス別の重み付けを行う場合の図解です。 ※ VM とあるがプロセスグループと同義です。 ※ 今回は触れませんが、CPU のメモリ・ノードの操作も可能である。
メモリ
RAM、スワップの設定やプロセスグループが使用しているメモリの使用状況を確認することが できます。ディスク
ディスク別(Block Device 単位)の使用可否やアクセス権限、IO 制御(重み付け、使用時間等)を 行うことができます。
※CPU の図と同様のことが可能です。
ネットワーク
プロセスグループに、tc(traffic control)で利用する class id を設定することができます。 ※cgroups 自体に帯域制御を行う仕組みはありません。実際の帯域制御は tc が行います。 設定項目
ファイルシステム
cgroups filesystem を mount することで以下のようなファイル群が作成される。これを設定 することで様々な cgroup の設定が可能になります。
subsystem カテゴリ
● cpu.xxx ○ cpu コアの重み付け（優先度）操作 ● cpuset.xxx ○ cpu コアの割り当て操作 ● cpuacct.xxx ○ CPU 使用率などの統計情報をレポート ● memory.xxx ○ 物理メモリの操作、制御とレポート ● net_cls○ iproute2 tc(Traffic Control)で利用する class id の操作 ● blkio.xxx
○ ディスク I/O の重み付け、I/O スケジューラーレポートなど ● device.xxx
○ ディスクのアクセス制御 ● Freezer ○ プロセスグループ(cgroup)全体を一時停止、再開
cgroups 階層
以下は mount コマンドを利用した場合の構成です。cgroup の設定次第で、自由なファイルシ ステム構造にすることも可能です。 # tree /cgroup/ ├── blkio.io_merged IO のマージ要求数レポート(読み取り、書き込み、同期|非同期) ├── blkio.io_queued IO キューに滞留数レポート ├── blkio.io_service_bytes 各デバイスに転送された Byte 数レポート(読み取り、書き込み、同期、非同期、合計) ├── blkio.io_service_time IO 時間レポート(ナノ秒) ├── blkio.io_serviced 特定デバイス上での実行 IO 数レポート(読み込み、書き込み、同期、非同期、合計) ├── blkio.io_wait_time IO スケジューラで待機させられた合計レポート(ナノ秒) ├── blkio.reset_stats cgroup の統計情報のリセット(pseudofiles) ├── blkio.sectors 各ブロック(デバイス)に転送されたセクタ数レポート ├── blkio.time ブロックデバイス単位で使用できる時間を指定することができる(ミリ秒) ├── blkio.weight ブロック IO の重み付け値レポート ├── blkio.weight_device 各デバイス(/dev)の指定を行ってブロック IO 制御を行う。 # ls -al /dev/sdabrw-rw---- 1 root disk 8, 0 2010-12-25 13:55 /dev/sda 8 = メジャーデバイス番号
0 = マイナーデバイス番号
example) echo “dev_maj:dev_minor weight” > /path/to/cgroup/blkio.weight_device ├── cgroup.event_control
├── cgroup.procs ├── cpu.rt_period_us
├── cpu.rt_runtime_us グループが CPU リソースへのアクセスを保持する最長の期間(マイクロ秒) ├── cpu.shares グループがシェアできる割合 ├── cpuacct.stat CPU サイクルレポート(
USER_HZ
) ├── cpuacct.usage すべて CPU 消費時間レポート(ナノ秒) ├── cpuacct.usage_percpu 各 CPU 消費時間の合計レポート(ナノ秒) ├── cpuset.cpu_exclusive ├── cpuset.cpus グループが使用する CPU のコア No を指定 [0, 1, 0-2] ├── cpuset.mem_exclusive ├── cpuset.mem_hardwall ├── cpuset.memory_migrate ├── cpuset.memory_pressure ├── cpuset.memory_pressure_enabled ├── cpuset.memory_spread_page ├── cpuset.memory_spread_slab ├── cpuset.mems グループが使用する CPU 集合のメモリノードを指定 [0, 1, 0-2] ├── cpuset.sched_load_balance ├── cpuset.sched_relax_domain_level ├── devices.allow アクセス可能なデバイス a b,c 両デバイス b ブロックデバイス c キャラクタデバイス x:y x=デバイスのメジャー番号、y=デバイスのマイナー番号 r 読み取り可能 w 書き込み可能 m 書き込み可能(ない場合は作成可) ├── devices.deny アクセス不可能なデバイス ※設定値は、devices.allow と同一 ├── devices.list 利用しているデバイスリスト ※設定値は、devices.allow と同一 ├── memory.failcnt メモリ制限(memory.limit_in_bytes)値を超えた回数レポート ├── memory.force_empty├── memory.limit_in_bytes メモリの最大値を設定します。 無制限にしたい場合は、-1 を設定 ├── memory.max_usage_in_bytes 使用可能なユーザメモリの最大容量レポート(Byte) ├── memory.memsw.failcnt メモリ制限(memory.limit_in_bytes)値を超えた回数レポート ├── memory.memsw.limit_in_bytes メモリと swap の使用容量を設定します。 無制限にする場合は、-1 を設定します。 ├── memory.memsw.max_usage_in_bytes プロセスによって使用されるメモリ使用量と swap 領域の最大値レポート(Byte) ├── memory.memsw.usage_in_bytes プロセスによって使用されているメモリ使用量と swap 領域の合計レポート(Byte) ├── memory.move_charge_at_immigrate ├── memory.oom_control
oom_kill_disable OOM killer を利用するか
under_oom コンテナ内のタスク(プロセス)に OOM Killer を利用するか ├── memory.soft_limit_in_bytes ├── memory.stat メモリ統計情報レポート ├── memory.swappiness ページのスワップ調整(parent : /proc/sys/vm/swappiness) ├── memory.usage_in_bytes プロセスの現在の総メモリ使用量レポート(Byte) ├── memory.use_hierarchy ├── net_cls.classid ネットワークの通信 Control で利用する tc への識別子 ├── notify_on_release ├── release_agent ├── guest1 ※cgroups ├── ... └── tasks 管理している PID リスト
初期セットアップ
cgroups 状態チェック
cgroups のインストール状態を確認します。これは現在利用可能な設定や kernel を確認する 事ができます。(fedora 14)
# lxc-checkconfig
Kernel config /proc/config.gz not found, looking in other places... Found kernel config file /boot/config-2.6.35.4-9m.mo7.x86_64 --- Namespaces ---
Namespaces: enabled
Utsname namespace: enabled Ipc namespace: enabled Pid namespace: enabled User namespace: enabled Network namespace: enabled Multiple /dev/pts instances: enabled
--- Control groups --- Cgroup: enabled
Cgroup namespace: enabled Cgroup device: enabled Cgroup sched: enabled Cgroup cpu account: enabled Cgroup memory controller: enabled Cgroup cpuset: enabled
--- Misc ---
Veth pair device: enabled Macvlan: enabled
Vlan: enabled
Note : Before booting a new kernel, you can check its configuration usage : CONFIG=/path/to/config /usr/bin/lxc-checkconfig
LXC(Linux Containers)
概要
Linux Containers(以後 LXC)は、完全なリソースの分離と制御を行うことができます。 具体的には、ユーザ空間でのコンテナオブジェクトを提供、管理することを目的とした仕組み です。 ※ユーザ空間での使用であるため、ホスト OS の資産を再利用することでハイパーバイザー 型の仮想化技術より効率よく運用することができます。 LXC は、cgroups を含めたオブジェクトをコンテナという単位で管理します。 また、cgroups よりシンプルな設定で管理することができ、各コンテナを起動、停止、一時停 止する機能なども有したオープンソースソフトウェアです。 LXC を使用することで、コンテナ型の仮想化を提供することができます。コンテナ型の仮想化技術は、Solaris Containers や FreeBSD jail、OpenVZ が有名ですが、LXC は cgroup を基礎としてコンテナ型の仮想化を実現しています。 LXC は大きくシステムコンテナとアプリケーションコンテナに分類されてます。 前者は OS 全体の仮想化で init(sysvinit など)から起動 ※６ し仮想 OS 空間を提供します。 後者は chroot と同じでアプリケーションを分離する方式に非常に似ています。また、単一アプ リケーションを分離するだけであるため、非常にシンプルかつ軽量であるのが特徴です。 今回は、アプリケーションコンテナを主軸に説明していきます。 LXC のコンテナ管理は libvirt の管理方法に非常によく似ています。 ※６ 起動プロセスは init(SysVinit)からですので非常に高速に起動します。ですが、一つの Kernel(一般的にはホスト OS)をゲスト OS が共有しているため他の OS 等をゲスト OS とし動 作させる事ができないなど、他のコンテナ型と同じデメリットもあります。
構成と図解
アプリケーションコンテナを実行した場合、以下のような図で起動することができます。
定義
● ケイパビリティ : POSIX Capability(LInux カーネルケイパビリティ)
○ CAP_SYS_MODULE ....
● cgroups : Control Groups
● Virtual Network : 仮想ネットワークデバイス
● utsname : 独立したホスト名
● rootfs : コンテナのファイルシステム
● mount : コンテナへマウント : /lib /bin ...
● console,pty ... : その他
lxc.conf の記述方法(
man, kernel document からの和訳を含みます
)
コンテナは構成ファイル(lxc.conf)を使用して構築されます。 作成時に lxc.conf を指定しない場合、親の定義されている lxc.conf が使用されます。 デフォルトでは、SysV IPC が分離マウントされ、システムリソースは明示的に定義があるま で親のシステムリソースを使用します。※ネットワークも同様です。lxc.utsname
コンテナのホスト名lxc.network.type
ネットワーク仮想化の種類を指定します。 lxc.network.type フィールドは定義があるたびに複数回定義することが可能です。 このようにすることで１つのコンテナに複数のネットワーク仮想化定義を行うことができま す。empty
ループバックアドレスveth
peer network デバイスが１つ作成されます。 コンテナ外には lxc.network.link は指定されてたブリッジに定義されます。vlan
VLAN は lxc.network.link で指定されたコンテナに割り当てられたインターフェ イスとリンクされています。 VLAN ID を指定オプションは lxc.network.vlan.id です。macvlan
macvlan インターフェイスは lxc.network.link で指定されたコンテナに割り当て られたインターフェイスとリンクします。phys
lxc.network.link で指定された既存のインターフェイスは、コンテナに割り当て られています。lxc.network.flags
ネットワークのために実行するアクションを指定します。 up: インターフェイスがアクティブになります。lxc.network.link
実際のネットワークトラフィックに使用するインターフェイスを指定します。lxc.network.name
ネットワークインターフェイス名を指定します。lxc.network.hwaddr
インターフェイスの MAC アドレスを指定します。lxc.network.ipv4
仮想化されたインターフェイスに割り当てる IPv4 アドレスを指定します。 複数のネットワークインターフェースを指定することが可能です。 その場合は複数行記述してください。 format) x.y.z.t / m 192.168.1.123/24。lxc.network.ipv6
仮想化されたインターフェイスに割り当てる IPv6 アドレスを指定します。 複数のネットワークインターフェースを指定することが可能です。 その場合は複数行で記述してください。format) ×：：y/ m 2003:db8:1:0:214:1234:fe0b:3596/64
lxc.pts
仮想 PTS のインスタンスを指定します。lxc.console
コンテナーシステムコンソールパスを指定します。lxc.tty
仮想 TTY のインスタンスを指定します。ライフサイクル
LXC は他の仮想化ソフトと同様に Start -> Running -> Stop のような、状態遷移を行うことが できます。
主要コマンド(
man, kernel document からの和訳を含みます
)
LXC には、コンテナを操作するためのコマンドが提供されています。共通オプション
-?, -h, --help 長いヘルプを出力します。 --usage 使用方法のメッセージを与える。 -q, --quiet 静かに実行します。 -o --logfile=FILE ログの出力先をファイル指定する。 -l --logpriority=LEVEL ログレベルの指定。lxc-wait
説明 特定のコンテナの状態を監視します。 指定した状態になるまで待ちます。 書式 lxc-wait -n コンテナ名 -s 状態 利用方法 停止や状態変更の実行の際に、状態変更を確認する手段として利用する。 オプション -n --name=NAME ターゲットとなるユニークなコンテナー名 形式は英数字の文字列識別子 -s コンテナの状態 OR 演算子 | で重ねてして可能 example) 'RUNNING|STOPPED' 例lxc-wait --name guest1 -s "STARTING|RUNNING"
lxc-stop
説明 コンテナ内で実行されているアプリケーションを停止する。 書式 lxc-wait -n コンテナ名 オプション -n --name=NAME ターゲットとなるユニークなコンテナ名 形式は英数字の文字列識別子lxc-unfreeze
説明 コンテナの一時停止を解除する。 書式lxc-unfreeze -n コンテナ名 オプション -n --name=NAME ターゲットとなるユニークなコンテナー名 形式は英数字の文字列識別子
lxc-start
説明 コンテナを起動します。 書式lxc-start -n コンテナ名 [-f 設定ファイル] [-s KEY=VAL] [command]
利用方法 指定されたコンテナ内の指定されたコマンドを実行します。 オプションで指定された設定ファイルを利用してコンテナ内のコマンドを実行します が、指定が無い場合はグローバルの設定を利用して実行されます。 コマンドが指定されている場合、lxc-start はシステムコンテナを実行には'/bin/init'が利 用されます。 オプション -n --name=NAME ターゲットとなるユニークなコンテナー名 形式は英数字の文字列識別子 -d --daemon デーモンとしてコンテナの実行を行ないます。 -f, --rcfile=FILE コンテナの設定ファイル -s, --define KEY=VAL 設定ファイルで指定された値をオーバーライドすることができます。
lxc-ps
説明 コンテナ内のプロセスを表示します。 書式 lxc-ps [--name コンテナ名] [--lxc] [ps option] オプション -n --name=NAME ターゲットとなるユニークなコンテナー名 形式は英数字の文字列識別子 --lxc コンテナ内のプロセスの出力制限します。 [ps options] 一般的な'ps'コマンドのオプションを指定します。lxc-monitor
説明 コンテナの状態をモニタリングします。 書式 lxc-monitor -n コンテナ名 利用方法 指定されたコンテナの状態を監視します。名前は POSIX2 の正規表現記法を利用する ことができます。 ※すべてのコンテナを指定することも可能です。 オプション -n --name=NAME ターゲットとなるユニークなコンテナー名 形式は英数字の文字列識別子lxc-ls
説明 コンテナの表示を行ないます。 書式 lxc-ls [ls option] オプション [ls option]は一般的な ls オプションを利用することができます。lxc-kill
説明 コンテナにシグナルを送り停止することができます。 書式lxc-kill --name=コンテナ名 SIGNUM
利用方法 指定したコンテナの最初のプロセスに SIGNUM を送信し停止させます。 オプション -n --name=NAME ターゲットとなるユニークなコンテナー名 形式は英数字の文字列識別子 例 コンテナ 123 のプロセス pi1 にシグナル 26 を送信する lxc-execute -n 123 -- pi1 -d 500000 lxc-kill --name=123 26
lxc-freeze
説明 コンテナを一時停止します。 書式 lxc-freeze -n コンテナ名利用方法 明示的に再開コマンドを送るまでは、プロセスはブロックされます。 スケジュールバッチ処理を利用する際などに有効なコマンドです。 オプション -n --name=NAME ターゲットとなるユニークなコンテナー名 形式は英数字の文字列識別子
lxc-execute
説明 コンテナ内でアプリケーションを実行します。 書式lxc-execute -n コンテナ名 [-f 設定ファイル] [-s KEY=VAL ] command
利用方法 指定したコンテナ内の指定されたコマンドを実行します。 設定ファイルにない設定はグローバルの設定を利用して実行されます。 オプション -f, --rcfile=FILE コンテナの設定ファイル -s, --define KEY=VAL 設定ファイルで指定された値をオーバーライドすることができます。
lxc-destroy
説明 コンテナを削除します。 書式 lxc-create -n コンテナ名 利用方法 lxc-create で起動したコンテナを削除します。 オプション -n --name=NAME ターゲットとなるユニークなコンテナー名形式は英数字の文字列識別子
lxc-create
説明 コンテナの作成を行ないます。 書式 lxc-create -n コンテナ名 [-f 設定ファイル] [-t template] 利用方法 設定ファイルを元にコンテナを作成します。 設定ファイルを指定されていない場合、デフォルトの設定を元に作成されます。 オプション -f, --rcfile=FILE コンテナの設定ファイル -t コンテナ作成時に実行したいスクリプト lxc-create コマンドによって呼ばれるスクリプトを指定してください。 lxc-cgroup 説明 コンテナに関連付けされた cgroup コントロールグループを管理します 書式 lxc-start -n name サブシステム [値] オプション -n --name=NAME ターゲットとなるユニークなコンテナー名 形式は英数字の文字列識別子 サブシステム サブシステム制御グループの名前を指定します。 [値] サブシステム制御グループの値を設定することができます。便利なスクリプトサンプル
すべてのコンテナのリストを取得しその状態を取得する。 -- #!/bin/bash for i in $(lxc-ls -1); do lxc-info -n $i done -- すべてのコンテナのすべての PID を表示する。 -- #!/bin/bash for i in $(lxc-ls -1); do lxc-ps --name $i --forest done -- 複数のコンテナを監視します。パラメータは正規表現を受付けることが可能です。 説明 'foo'と'bar'を監視します。 -- #!/bin/bash lxc-monitor -n "foo|bar" -- すべてのコンテナを監視します。 -- #!/bin/bash lxc-monitor -n ".*" -- バックグラウンドで lxc-wait を起動する -- #!/bin/bashlxc-wait -n foo -s STOPPED & LXC_WAIT_PID=$!
--
バックグラウンドでコンテナを起動する --
#!/bin/bash
--
クイックスタート(ssh)
概要
sshd をコンテナ内で動作させます。lxc 設定
lxc の設定は未指定とします。手順
cgroup をマウントmount -t cgroup cgroup /cgroup すでにホストで動作している sshd を停止 /etc/init.d/sshd stop コマンドベースで sshd をコンテナ実行 lxc-execute -n sshd /usr/sbin/sshd 補足 -n sshd : コンテナ名の指定 /usr/sbin/sshd : コンテナ内で実行するコマンド コンテナ内で動作しているか確認 lxc-info -n sshd 'sshd' is RUNNING ssh でログイン ssh localhost 補足 パスワードはホストのパスワード プロセスを表示(ホスト OS 上) $ ps ax
PID TTY STAT TIME COMMAND
1 pts/0 S+ 0:00 /usr/lib64/lxc/lxc-init -- /usr/sbin/sshd 3 ? Ss 0:00 /usr/sbin/sshd
6 pts/2 Ss そく 0:00 -bash 41 pts/2 R+ 0:00 ps ax
KVM を利用した性能測定
概要
Control Groups, LinuxContainers に KVM を配置し、その利用時のパフォーマンス劣化を調査 します。
ベンチマークは複数のベンチマークソフトを使用します。
KVM(Kernel-based Virtual Machine)
● Linux カーネル仮想化基板として Kernel に取り込まれている仮想化技術である。 ● Intel-VT(-x)や AMD-V などの CPU 仮想化支援機構を利用しネイティブ仮想化を実現し
ています。
● エミュレータには Qemu を利用することで、多数の OS をサポートしている。 ● Kernel に取り込まれたことで、Xen ではなく KVM の利用が増えている。
○ 補足 : Kernel 2.6.34 で Xen Guest 、2.6.37 で Xen Host(一部機能)の取り込みが 行われているので、今後はどうなるか未知数である。
性能測定方法
以下の４パターンで性能測定を行う。 ● ホスト ● ゲスト単体 ● ゲスト on Control Groups ● ゲスト on Linux Container 測定箇所 ● CPU ● ディスク ● ネットワークベンチマークソフト
●
kernbench○
kernbench Version 0.50○
fedora 14 kernel source linux-2.6.35●
dbench○
dbench version 4.00○
command : dbench 5●
tbench○
dbench version 4.00○
command : tbench -t 60 5 {IPADDR}■
※物理的に違うサーバに tbench_srv を用意ブリッジ設定
KVM で使用する、ブリッジを新規に作成します。 bash スクリプト例 -- #!/bin/bash _ifconfig=`which ifconfig` _brctl=`which brctl` _route=`which route` _iptables=`which iptables` br_name="{ブリッジ名}" eth="{物理インターフェース名}" ipaddr="{物理インターフェースに割り当てる IP アドレス}" netmask="{物理インターフェースに割り当てるサブネットマスク}" gateway="{ゲートウェイアドレス}"${_ifconfig} eth0 0.0.0.0 promisc up ${_brctl} addbr ${br_name}
${_brctl} addif ${br_name} ${eth} ${_ifconfig} ${br_name} up
${_ifconfig} ${br_name} ${ipaddr} netmask ${netmask} ${_route} add default gw ${gateway}
${_iptables} -I FORWARD -m physdev --physdev-is-bridged -j ACCEPT --
QEMU コマンド
/usr/bin/qemu-kvm ¥ -M pc-0.13 ¥ -enable-kvm ¥ -m 4096 ¥ -smp 2,sockets=1,cores=1,threads=1 ¥ -name guest1 ¥ -uuid 346e3b60-88e7-aeae-26ce-c4d1a1b9b6eb ¥ -nodefconfig ¥ -nodefaults ¥ -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/guest1.monitor,server,nowait ¥ -mon chardev=monitor,mode=readline ¥ -rtc base=utc ¥ -boot c ¥ -drive file=/virt/iso/Fedora-14-x86_64-DVD.iso, ¥ if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw ¥ -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 ¥ -drive file=/virt/images/guest1.img,if=none,id=drive-virtio-disk0,boot=on,format=qcow2 ¥ -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 ¥ -device virtio-net-pci,vlan=0,id=net0,mac=52:54:00:ff:34:5e,bus=pci.0,addr=0x3 ¥ -net tap,vlan=0,name=hostnet0 ¥ -chardev pty,id=serial0 ¥ -device isa-serial,chardev=serial0 ¥ -usb -vnc 0.0.0.0:10 ¥ -k ja ¥ -vga cirrus ¥ -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5サーバー情報
● CPU : 2 core ● Memory : 8G ● Network : 100M● QEMU emulator version 0.13.0 (qemu-kvm-0.13.0) ● OS Fedora 14 x86_64
● kernel version 2.6.35.10-74 ● cgroup version 0.36
● lxc version 0.7.2
測定結果
kernbench を最大負荷で実行した場合の測定結果
コマンド : kernbench
考察
ゲスト単体に比べゲスト on Control Groups とゲスト on Linux Containers に若干のパフォー マンス劣化（１〜２％）が見られたが、Control Groups,Linux Containers の機能を考えると許 容できるパフォーマンスを発揮していると考える。
dbench の測定結果
考察
ゲスト単体に比べゲスト on Control Groups とゲスト on Linux Containers に若干のパフォー マンス劣化（１〜２％）が見られたが、Control Groups,Linux Containers の機能を考えると許 容できるパフォーマンスを発揮していると考える。
※max_latency は、複数回測定を行ったが、ゲスト on Control Groups とゲスト on Linux Containers の両方で安定した値が取得できなかった。 ※ゲスト on Control Groups（グラフ）で劣化が見られるが１M 程度の劣化でありかつ、複数 回の測定をおこなっていないので、誤差と考える。
tbench の測定結果
コマンド : tbench -t 60 5 192.168.55.3 ※192.168.55.3 は物理的に違うサーバに tbench_srv を用意した。考察
ゲスト単体に比べゲスト on Control Groups とゲスト on Linux Containers にパフォーマン ス劣化（１０〜１５％）が見られた。
※max_latency は、複数回測定を行ったが、ゲスト on Control Groups とゲスト on Linux Containers の両方で安定した値が取得できなかった。
最後に
Control Groups、Linux Containers を利用することで、SLA、Qos が行えることが確認できた。 実例として、不意なアクセスによるシステムリソースの枯渇や、他プロセスへの影響をなくす 事ができるなどの利点もあることがわかった。
KVM の性能評価でもわかるように、KVM＋Control Groups、Linux Containers でのパフォー マンス劣化がそれほど発生していないこともわかった。
参考 URL
● Control Group : http://libcg.sourceforge.net/ ● Linux Container : http://lxc.sourceforge.net/
● Kernel Document(cgroups) : http://www.kernel.org/doc/Documentation/cgroups/
● LXC: Linux コンテナー・ツール :
