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 ○ cgroup をプログラムから操作するためのライブラリです。 ○ ● ● プロセスグループの作成、編集、削除、アクセス権限等の操作を行う事ができます。設定ファイル※４ ○ 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 が行います。設定項目 net_cls.classid ファイルシステム 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/sda brw-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 リソースへ再割り当てされるべき間隔(マイクロ秒) ├── 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 ログレベルの指定。レベル : FATAL, CRIT, WARN, ERROR, NOTICE, INFO, DEBUG 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/bash lxc-wait -n foo -s STOPPED & LXC_WAIT_PID=$! -バックグラウンドでコンテナを起動する -#!/bin/bash lxc-execute -n foo mydaemon & -- クイックスタート(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 4? Ss 0:00 sshd: root@pts/2 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 ○ ○ ● fedora 14 kernel source linux-2.6.35 dbench ○ ○ ● kernbench Version 0.50 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 -設定後は、ifconfig, route, brctl コマンドを使い設定の確認を行ってください。 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 KVM は、ブリッジ経由(br0) 測定結果 kernbench を最大負荷で実行した場合の測定結果コマンド : kernbench 使用した kernel : Kernel 2.6.35.6-45.fc14.x86_64 考察ゲスト単体に比べゲスト on Control Groups とゲスト on Linux Containers に若干のパフォーマンス劣化（１〜２％）が見られたが、Control Groups,Linux Containers の機能を考えると許容できるパフォーマンスを発揮していると考える。 dbench の測定結果コマンド : dbench 5 考察ゲスト単体に比べゲスト 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 コンテナー・ツール : ○ http://www.ibm.com/developerworks/jp/linux/library/l-lxc-containers/