1 / 19

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

仮想マシン間プロセススケジューリング の 実 環境への適用にむけて. 田所秀和 （東工大） 光来健一 （九工大 /CREST ） 千葉　滋 （東工大）. 仮想マシン環境でのスケジューリング. 仮想マシン（ VM ）をつかったサーバ統合 リソースの利用効率向上 システム全体で優先度をつけにくくなる Backup が他のサービスを阻害しないようにしたい OS のスケジューリングのみ WEB と backup 間に優先度は つけられない VM スケジューリングを併用 DB が止まった場合 backup の 優先度が高くなってしまう. VM1. VM2. 優先度.

mareo
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

  4. Monarch Scheduler [田所ら ‘08] (2/2) • システム全体でプロセスに優先度をつける • ポリシー例 • Backupの優先度最低 • 他のサービスを阻害しないよう • WEBor DBが動いているときはbackupを停止 • VMMが定期的にゲストOSを調査 VM1 VM2 優先度 DB WEB backup 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スケジューラでの操作 • I/Oリクエストを止めれば、発行したプロセスが止まる • リクエストが存在する時間が短い • ドメイン０での操作 • フロント、バック間のリクエストの対応付けが難しい • リクエストとプロセスの対応が難しい Xen I/O アーキテクチャ I/OScheduler ドメインU ドメイン０ バックエンドドライバ フロントエンドドライバ 実ドライバ Xen VMM ハードウェア

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

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

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

  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 2212 WmiPrvSE.exe priority: 8 next: 0xfffffa8001659c10, prev: 0xfffffa8002f1ab50 2424 explorer.exe priority: 8 next: 0xfffffa8002f1ab50, prev: 0xfffffa80036c5040 2200 taskeng.exe priority: 8 next: 0xfffffa8003696a40, prev: 0xfffffa80035c3040 2248 rdpclip.exe priority: 8 next: 0xfffffa80036c5040, prev: 0xfffffa8003680040 2316 dwm.exe priority: 8 next: 0xfffffa80036d66c0, prev: 0xfffffa8003696a40 4 priority: 0 next: 0xa800000009ff18, prev: 0x1fff1c ….. 1112 svchost.exe priority: 8 next: 0xfffffa800307dc10, prev: 0xfffffa8002f58c10 680 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で、ランキューの位置特定にかかる時間 • Windowsにおける、スケジューリングの挙動 • 実験環境 • Core2Duo 2.4GHz、メモリ6Gbyte • Xen 3.3.0 (x86_64) • ドメイン0 ：Linux 2.6.18.8、メモリ2Gbyte • ドメインU：Linux 2.6.16.33, Windows Vista SP1、メモリ1Gbyte

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

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

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

  18. 関連研究 • ゲストOSの情報を使いVMをスケジューリング • 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の拡張 • VMMからI/Oバウンドなプロセスを制御 • WindowsゲストOSにも対応 • 今後の課題 • WindowsでのI/Oバウンドプロセスの制御 • 現在実行中のプロセス制御 • 現実的なアプリケーションを対象とした実験

More Related