仮想マシン間プロセススケジューリングの 実環境への適用にむけて

Presentation on theme: "仮想マシン間プロセススケジューリングの 実環境への適用にむけて"— Presentation transcript:

1 仮想マシン間プロセススケジューリングの 実環境への適用にむけて
田所秀和 （東工大） 光来健一 （九工大/CREST） 千葉　滋 （東工大）

2 仮想マシン環境でのスケジューリング 仮想マシン（VM）をつかったサーバ統合 システム全体で優先度をつけにくくなる リソースの利用効率向上
Backup が他のサービスを阻害しないようにしたい OSのスケジューリングのみ WEB と backup 間に優先度は つけられない VMスケジューリングを併用 DBが止まった場合backupの 優先度が高くなってしまう VM1 VM2 優先度 DB backup WEB VMM Hardware

3 Monarch Scheduler [田所ら ‘08] (1/2)
仮想マシンモニタがゲストOSのランキューを操作 ゲストOSのスケジューリングポリシーを変更 プロセスを止める：プロセスをランキューから外す プロセスを再開：ランキューに戻す ゲストOSの変更が不要 ゲストOS内で特別あつかいする スレッドが不要 VM1 VM2 DB backup WEB VMM ランキューを直接操作

4 Monarch Scheduler [田所ら ‘08] (2/2)
システム全体でプロセスに優先度をつける ポリシー例 Backupの優先度最低 他のサービスを阻害しないよう WEB or DBが動いているときはbackupを停止 VMMが定期的にゲストOSを調査 VM1 VM2 優先度 DB backup WEB VMM Hardware 優先度最低

5 本発表：MonarchSchedulerの拡張
I/Oバウンドプロセスの制御 ランキューに載りにくい 定期的にチェックする方法では難しかった 約74％はI/O待ち iozoneで調査 WindowsゲストOSに対応 Linuxとは違う ソースコードが無い 公開情報が少ない シンボルのアドレスがロード時まで不定

6 I/Oバウンドプロセス制御の問題(1/2) プロセスをウェイトキューから除く ウェイトキューの発見が難しい
さまざまな場所に存在 nfsはモジュールのロード時にヒープに生成 ランキューは起動時に生成され、CPU毎に存在 単純に戻すだけでは再開させられない可能性 永遠にI/O待ちの可能性 定期的に調べるだけでは、I/Oが完了したか不明

7 I/Oバウンドプロセス制御の問題(2/2) ゲストOSのI/Oスケジューラでの操作 ドメイン０での操作
リクエストが存在する時間が短い ドメイン０での操作 フロント、バック間のリクエストの対応付けが難しい リクエストとプロセスの対応が難しい ハードウェア Xen VMM フロントエンド ドライバ バックエンド ドライバ 実ドライバ ドメイン０ ドメインU Xen I/O アーキテクチャ I/O Scheduler

8 プロセスの状態変更で制御 I/O待ちプロセスの状態を書き換え 再開させるときは、ランキューに挿入
{,UN}INTERRUPTIBLE を STOPPED に I/O完了時に自発的に止まる 通常ならI/O完了時にRUNNINGになりランキューへ 再開させるときは、ランキューに挿入 状態をRUNNINGにしてから interruptible VMM interruptible VMM stopped stopped VMM stoppedに変更 I/O完了後

9 data_offset + PER_CPU_RUNQUEUES
Windowsでのランキューの位置特定 VMMから直接発見する方法は不明 LinuxではGSレジスタからたどれる デバッガを使っても直接は不明 レジスタからたどれるか不明 Linuxの場合 struct x8664_pda { task_t * current; ulong data_offset; …}; Linuxのメモリ GSレジスタ x8664_pda data_offset + PER_CPU_RUNQUEUES ランキュー

10 Windowsのランキュー位置推定 PsActiveProcessHeadの発見が目標
current IRQL 実行待ち リスト配列 ProcHead 固定長 離れている ランキュー Windows Kernel 実行中プロセス 実行待ちプロセス アイドルプロセス VMM summary

11 プロセスリストの発見 プロセス候補をメモリ全体から探す プロセスかをチェック Xenのスナップショット機能を利用
プロセス型を表すビット列を探索 オブジェクトは型を表すヘッダを保持 GREPEXEC [bugcheck ’06] を利用 プロセスかをチェック 実行ファイル名がアスキー文字 プロセスIDが４の倍数 プロセス全体が一つの環状リストになっている

12 PsActiveProcessHeadの発見
プロセスとはアドレスが異なる プロセスの上位３２ビットは 0xfffffa80 ProcHeadの上位３２ビットは0xfffff800 % ./search_mem ~root/debutante.save 0 Idle priority: 0 next: 0xffffffffffffff18, prev: 0xffffffffffffff18 4 System priority: 8 next: 0xfffffa8002c97c10, prev: 0xfffff800017ad338 WmiPrvSE.exe priority: 8 next: 0xfffffa c10, prev: 0xfffffa8002f1ab50 explorer.exe priority: 8 next: 0xfffffa8002f1ab50, prev: 0xfffffa80036c5040 taskeng.exe priority: 8 next: 0xfffffa a40, prev: 0xfffffa80035c3040 rdpclip.exe priority: 8 next: 0xfffffa80036c5040, prev: 0xfffffa dwm.exe priority: 8 next: 0xfffffa80036d66c0, prev: 0xfffffa a40 priority: 0 next: 0xa ff18, prev: 0x1fff1c ….. svchost.exe priority: 8 next: 0xfffffa800307dc10, prev: 0xfffffa8002f58c10 logon.scr priority: 4 next: 0xfffff800017ad338, prev: 0xfffffa8000c9fc10

13 Windowsでのランキューの一貫性 ランキューが操作されていないときのみ、ランキューを操作 Linuxの場合は、スピンロックをチェック
VMMが割り込み要求レベル(IRQL)をチェック SYNCH_LEVEL以上なら、スケジューリング中の可能性 SYNCH_LEVEL未満なら、スケジューリング中でない Linuxのスケジューラ schedule() { spin_lock(runqueue); ランキューの操作 spin_unlock(runqueue); };

14 実験 目的 Linuxで、I/Oバウンドプロセスを制御できるか Windowsで、ランキューの位置特定にかかる時間
実験環境 Core2Duo 2.4GHz、メモリ6Gbyte Xen (x86_64) ドメイン0 ：Linux 、メモリ2Gbyte ドメインU：Linux , Windows Vista SP1、メモリ1Gbyte

15 実験：I/Oバウンドプロセスの制御 iozoneを制御 CPU時間の増加量から、実行を判断 ディスクベンチマークツール 停止中 iozone
Xen VMM ドメイン０ ドメインU Monarch Scheduler

16 実験：ランキューの位置特定時間 ドメインUのメモリサイズを変化 メモリイメージを書き出す場所を変化 メモリサイズに比例
実ディスク tmpfs メモリサイズに比例 ディスクI/Oが ボトルネック

17 実験：スケジューリングの挙動 4つのプロセスをスケジューリング PI1 の優先度を最低 ドメインU1で3つ、ドメインU2で1つ
プロセスは円周率の計算 PI1 の優先度を最低 Xen VMM ドメインU1 ドメインU2 PI3 PI4 PI1 PI2 優先度最低

18 関連研究 ゲストOSの情報を使いVMをスケジューリング Windowsの内部情報に依存した手法
Task-aware VM Scheduling [VEE’09 Kim et al.] Gray-box知識を利用 Guest-aware VM Scheduling [europar’08 kim et al.] ゲストOSからプロセスの優先度情報を取得 Windowsの内部情報に依存した手法 VMwatcher [CCS’07 Jiang et al.] GREPEXECを使いプロセスを推定 Lares [PS’08 Payne et al.] ゲストOSにカーネルモジュールを追加

19 まとめと今後の課題 まとめ 今後の課題 Monarch Schedulerの拡張 WindowsでのI/Oバウンドプロセスの制御
VMMからI/Oバウンドなプロセスを制御 WindowsゲストOSにも対応 今後の課題 WindowsでのI/Oバウンドプロセスの制御 現在実行中のプロセス制御 現実的なアプリケーションを対象とした実験