仮想マシン間にまたがる プロセススケジューリング 田所秀和　　光来健一　　千葉滋 東京工業大学

仮想マシン環境でのスケジューリング 仮想マシン(VM)を使ったサーバ統合 システム全体で優先度を付けたい リソースの利用効率の向上 例: DB > WEB > backup データベースプロセス ウェブプロセス バックアッププロセス ウェブやデータベースの サービスを阻害させない VM1 VM2 優先度 DB WEB backup VMM Hardware

システム全体でのスケジューリングは難しい OSのスケジューリングとVMのスケジューリングだけで はうまくいかない OSのスケジューリングのみ WEB と DB, backup 間に 優先度はつけられない VM1 ＜ VM2 DBが止まった場合、 WEB ＜ backup になってしまう VM1 ＞ VM2 DB ＜ WEBになってしまう VM1 VM2 優先度 WEB ？ DB backup

システム全体でのスケジューリングは難しい OSのスケジューリングとVMのスケジューリングだけで はうまくいかない OSのスケジューリングのみ WEB と DB, backup 間に 優先度はつけられない VM1 ＜ VM2 DBが止まった場合、 WEB ＜ backup になってしまう VM1 ＞ VM2 DB ＜ WEBになってしまう VM2 優先度 VM1 DB WEB backup

システム全体でのスケジューリングは難しい OSのスケジューリングとVMのスケジューリングだけで はうまくいかない OSのスケジューリングのみ WEB と DB, backup 間に 優先度はつけられない VM1 ＜ VM2 DBが止まった場合、 WEB ＜ backup になってしまう VM1 ＞ VM2 DB ＜ WEBになってしまう DBが止まるとbackupが動く VM2 優先度 VM1 backup WEB DB

システム全体でのスケジューリングは難しい OSのスケジューリングとVMのスケジューリングだけで はうまくいかない OSのスケジューリングのみ WEB と DB, backup 間に 優先度はつけられない VM1 ＜ VM2 DBが止まった場合、 WEB ＜ backup になってしまう VM1 ＞ VM2 DB ＜ WEBになってしまう VM1 優先度 WEB VM2 DB backup

VM間で協調するスケジューラの問題 複雑なスケジューリングが必要 OSを変更する必要 止めてはならないプロセス 無視すべきプロセス スケジューリングスレッド自身 無視すべきプロセス syslogd OSを変更する必要 スケジューリングスレッドを 動かす 協調して スケジューリング 優先度 sched sched DB WEB backup

仮想マシンモニタによるプロセススケジューリング 仮想マシンモニタ(VMM)が 直接ゲストOSのランキューを操作 ゲストOSのスケジューリングポリシーを変更 ゲストOSの変更が不要 ポリシー例 WEBまたはDBが動いているときは backupを止める VM1 ＜ VM2 WEBとDBだけが動いているときは、 DBの優先度を最高にする VM1 VM2 DB WEB backup VMM ランキューを直接操作

ゲストOSのランキューを操作する手順 一定時間毎に全てのVMをチェック VMを一時停止 ゲストOSがランキューを操作していないことを確認 データ構造を破壊しないように ランキューを操作していたらそのままVMを再開 ポリシーに従ってランキューを操作する VMを再開

システムの構成 スケジューラプロセス ドメイン0はスケジュール対象 外 VMMとしてXenを利用 ゲストOSはLinuxを対象 ドメイン0のプロセスで実装 ランキュー操作 VMの優先度操作 ドメイン0はスケジュール対象 外 スケジューラプロセスが常に動くように ドメイン0では通常のアプリケーションは動かさない ドメイン0 ドメインU ドメインU DB WEB sched backup Xen VMM

スケジューリングのためのランキュー操作 プロセスの一時停止 プロセスの実行の再開 注意点 タスク構造体を取り除く タスク構造体を戻す ランキューにつながれたプロセスの数も更新 ゲストOSの意味を保つ 実行中のプロセスは取り除かない OS内のいろいろな場所にプロセスの情報が残っているので難しい 今後の課題

一貫性を保ったランキューの操作 ゲストOSが操作していないときのみランキューを操 作 VMMがランキューのスピンロックを調べる メモリを読むことでチェック SMP カーネルを使用 SMPカーネルの場合スピンロックを用いて排他制御を行う ドメインUのスケジューラ schedule() { spin_lock(runqueue); ランキューの操作 spin_unlock(runqueue); };

ドメインUのカーネルメモリへのアクセス ドメインUのページをドメイン0上 のプロセス空間にマップ ページ境界をまたがないように アクセス ページテーブル 仮想アドレス ドメインUのページをドメイン0上 のプロセス空間にマップ ドメインUの仮想アドレスが含まれるマシンメモリのページ番号を求める ページ境界をまたがないように アクセス 構造体のメンバ変数など メモリマップはページ単位 ドメイン0 ドメインU マップ Xen VMM P2Mテーブル マシンメモリ

ドメインUのメモリ操作のための型情報取得 カーネルのデバッグ情報から型情報を取得 カーネルを CONFIG_DEBUG_KERNEL=y でコンパイル デバッグ情報から型情報の取得には gdb を使用 カーネルのコンフィグやマクロの解析が不要 コンパイラが解析する struct runqueue { spinlock_t lock; unsigned long nr_running; #ifdef CONFIG_SMP unsigned long long cpu_load[3]; #endif … }; % gdb vmlinux-debug (gdb) ptype runqueue_t type = struct runqueue { spinlock_t lock; long unsigned int nr_running; long unsigned int cpu_load[3]; … } ソースコード デバッグ情報

data_offset + PER_CPU_RUNQUEUES ランキューのアドレスの取得 仮想CPUのGSレジスタからrunqueueのアドレスを取得 Linux 2.6 ではCPU毎にランキューが存在 レジスタの値はVMMへのハイパーコールを用いて取得 x8664_pda は各CPU毎に固有のデータを管理(x86_64) struct x8664_pda { task_t * current; ulong data_offset; … }; ドメインUのメモリ GSレジスタ x8664_pda runqueue data_offset + PER_CPU_RUNQUEUES

スケジューリング性能を調べる実験 4つの実験をおこなった ドメインUへのメモリアクセスによるオーバーヘッド 優先度による性能の変化 スケジューリングを行う間隔の影響 プロセススケジューリングの挙動 環境 CPU: PentiumD 3.4GHz Memory: 2G (Dom0/DomU　1Gbyte/512Mbyte) Xen 3.0.4 (x86_64) Linux kernel 2.6.16.33

ドメインUのメモリアクセスのオーバーヘッド 仮想アドレスからフレーム番号の取得がボトルネック ゲストOSのページテーブルを引くのに時間がかかる ランキュー上のプロセスをたどるのに必要なマップの回数最大 (42+実行待ちプロセスの数)*VCPUの数*ドメインの数 処理 時間（マイクロ秒） ドメインの一時停止と再開 14.84 仮想アドレスに対応するフレーム番号の取得 68.95 ページをドメイン0のプロセスにマップ・アンマップ 13.72 1ワードのメモリアクセス 0.00

優先度をつけたことによる性能の変化 lighttpdとtripwireを同時に動かす ポリシー lighttpdの性能は単独の時と ほぼ同じ 同じドメインと、別ドメイン ポリシー lighttpdの優先度をあげる lighttpdの性能は単独の時と ほぼ同じ 別ドメインの場合でもlighttpdを 優先できた

スケジューリング精度 円周率を計算するpi1とpi2を同時に起動 ポリシー pi1が動いている間はpi2は実行しない 間隔が長い 間隔が短い 同じドメイン上 ポリシー pi1が動いている間はpi2は実行しない スケジューラプロセスが 動く間隔を変える 間隔が長い 精度低下 間隔が短い オーバーヘッド大 精度は上がる

プロセススケジューリングの挙動 (1/2) 4つのプロセスをスケジューリング ポリシー ドメインU1で3つ、ドメインU2で1つ プロセスはすべて円周率を計算するプログラム ポリシー Pi1の優先度を最低にする pi1をドメインUの中で他にプロセスが動いていないときのみ動かす ドメインU1 ドメインU2 pi2 pi4 pi3 優先度最低 pi1 Xen VMM

プロセススケジューリングの挙動 (2/2) ポリシーが実現できた グラフの各線が下のときはプロセスが止まっている 上のときは動いている pi1が20秒付近で動いているのはバグ

関連研究 Virtual Machine Introspection [NDSS'03, Garfinkel et al.] [SOSP'05, Joshi et al.] VMMからゲストOSの状態を取得 Antfarm [USENIX'06, Jones et al.], Geiger [ASPLOS'06, Jones et al.] VMM からゲストOSを仮定せずにプロセスやキャッシュの状態を取得する技術 FoxyTechnique [VEE'07, Yamada et al.] VMMが仮想デバイスの振舞いを変更することで、ゲストOSの振舞いを間接的に変更する技術

まとめと今後の課題 仮想マシンモニタによるプロセススケジューリングを 提案 今後の課題 ゲストOSのメモリを直接操作し、スケジューリングを変更 システム全体でプロセスに優先度を付けることが可能 実際にスケジューリングが行えることを確認 今後の課題 I/Oバウンドなプロセスの制御 CPUで実行中のプロセスの制御 ゲストOSがWindowsの場合でのプロセス制御