Coordinated and Secure Server Consolidation using Virtual Machines （仮想マシンを用いた調整可能で安全なサーバ統合）

1. Coordinated and Secure Server Consolidation using Virtual Machines（仮想マシンを用いた調整可能で安全なサーバ統合） 田所 秀和

2. 仮想マシンを用いたサーバ統合 VMs Server Server Server 統合 10% 60% 20% 30% • サーバ統合 • リソースの利用効率向上 • 物理マシンの台数削減 • サーバを容易に増減できる • P2V tool で動いているOSをそのまま統合 • 古いOSを使い続けられる VMM

3. 仮想マシンが複数存在 管理者 VMs 管理 管理VM vCPU vCPU vCPU VMM リソースをシェア CPU • 複数の仮想マシン(VM)を同じマシンで動かす • 共通のリソースをVM間で分割 • 仮想マシンモニタ(VMM)が物理CPUを仮想CPUに分配 • 管理VMを使いVMを管理 • VMを他のマシンにマイグレーション • 負荷分散やハードのメンテナンス

4. CPUリソースの競合 VMs vCPU vCPU vCPU VMM CPUリソースを取り合う CPU • 他のVMが動き、重要なタスクが阻害 • 一つの物理CPUを取り合う • 各VMは他のVMを認識できない • 独立してCPUリソースを利用 • 素朴な解法：排他的なリソース割り当て • 利用効率低下

5. 管理VMの脅威 VMs 攻撃 侵入 管理VM VMM • 管理VMに侵入されるとすべてのVMに影響 • 管理のための特権を悪用 • 管理VMへの攻撃 • 素朴な解法：管理VMの特権を減らす • マイグレーションができなくなる • 負荷分散や消費電力削減のためには必須

6. OSによる協調スケジューリング sched sched sched • 各VMのスケジューラが協調し重要なタスクを優先的に実行 • 情報交換のために特別なスレッドが必要 • スケジューリング対象にしてはいけないスレッド • 協調のため、OSに変更が必要 • 動いているOSをそのままサーバ統合できない • 不正確なスケジューリング • 仮想化によりOS内の統計情報が不正確 • 情報取得に時間がかかる CPU

7. 情報漏洩防止のトレードオフ self-migration 管理VM 管理 • ゲストOSによる管理 • 管理VMによる管理を禁止し情報漏洩を防止 • 可能な管理に制限がある • e.g. self-migration • OS自身がメモリを暗号化し管理VMに見せる • CPUが読み書きするメモリは復号化してある必要 • 必要なところだけ暗号化できる 自力でメモリコピー VMM

8. 本研究の貢献 管理者 VMs 管理 管理VM vCPU vCPU vCPU 暗号化 CPUを調停 VMM CPU • 調整可能で安全なサーバ統合 • 仮想マシン間でのプロセススケジューリング • CPUの競合回避と利用率向上を両立 • VMMが直接スケジューリング • 管理VMを経由した情報漏洩の防止 • 従来通りの管理と安全性を両立 • VMMがメモリを暗号化

9. I. 仮想マシン間でのプロセススケジューリング

10. サーバ統合でのスケジューリング VM1 VM2 優先度 DB WEB Indexing VMM Hardware • システム全体でのスケジューリングが重要 • CPUはVM間で共有 • 利用効率を高める • 重要なタスクが他VMのタスクに阻害されうる • 例：システム全体がアイドルの時だけIndexingを動かす • アイドル時スケジューリング • Indexing: 検索のDB作成プロセス

11. システム全体のスケジューリングは難しい VM1 VM2 優先度 DB WEB Indexing VMM Hardware • OSのスケジューリングとVMのスケジューリングだけではうまくいかない • OSによるスケジューリング • VM外のアイドルを検出できない • VMスケジューリング • VM内のプロセスを区別できない • Indexingだけを止めたい

12. 目標 • システム全体でのスケジューリング • 重要なタスクを阻害させない • CPU利用効率向上 • OSを変更しない • 既存のOSをそのままサーバ統合可能 • 複数OSに対応 • サーバ統合では様々なOSが統合される

13. Monarch Scheduler VM1 VM2 DB WEB Indexing Monarch Scheduler 状況に応じてIndexingを止める • VMMが全体を考慮しプロセスの実行を調整 • 柔軟にCPUリソースを割り当て可能 • 利用効率は向上 • ゲストOSのスケジューラの動作を直接変更 • 元のスケジューラを活用 • サーバ統合ではOSを変更せずそのまま統合したい • プロセス実行時間を直接取得 • 正確な統計情報を取得可能 Hardware

14. VMMによるランキューの操作 run queue VM process 実行待ちプロセス CPUで実行中 ランキュー ランキューを直接操作 Monarch Scheduler • VMMがゲストOSのランキューを操作しプロセスを制御 • ランキューからプロセスを外すと停止 • ランキューはプロセスの待ち行列 • ランキューに再挿入し、再開

15. プロセスの状態書き換え running ready blocked プロセスの状態遷移 • VMMが直接プロセスの状態を書き換え停止 • 次のスケジューリング時に停止 • 通常ならランキューの後ろに追加される • 実行中のプロセス • 実行中なのでランキューから単純に外せない • I/O待ち状態に書き換え • I/O待ち(blocked)プロセス • ランキューに存在しない • 停止状態に書き換え

16. 直接プロセス実行時間を取得 スイッチを観察 スイッチを観察 実行時間 process1 process2 process3 • VMMがプロセス時間を測定 • 仮想アドレス空間の変化を観察 [Jones et al. 2006] • ゲストOS内のコンテキストスイッチを推測 • e.g. CR3レジスタへの書き込みを観察 • ゲストOSの統計情報を使わない • 仮想化により不正確 時間

17. アドレス空間とプロセスの対応 • Guest OS kernel ProcHead lighttpd 仮想アドレス空間A ClamAV 仮想アドレス空間B • 仮想アドレス空間をプロセスに対応づける • ゲストOSのすべてのプロセス構造体を解析 • プロセスリストをたどる • すべてのプロセスはリストにつながっている • プロセス中に仮想アドレス空間の情報 • VMMからわかるのは仮想アドレス空間の情報のみ • どのプロセスかは不明

18. ポリシ記述用API VM1 VM2 voidinit() { d_all = get_domain_by_name(“.*”); p_all = get_task_by_name(d_all, “.*”); p_si= get_task_by_name(d_all, “SearchIndexer”); set_period(P); } voidscheduler() { t_all = get_time(p_all, P); t_si = get_time(p_si, P); if (t_all – t_si > 0) suspend(p_si); else resume(p_si); } DB WEB WEB’ Indexing Monarch Scheduler • ポリシーに従いプロセスを制御 • 実行時のプロセスやVMの増減に対応 • サーバがfork • 毎回マッチを取り直す • OSの実装に依存しない記述が可能 Hardware

19. アイドル時スケジューリング VM1 VM2 DB voidscheduler() { t_all = get_time(p_all, P); t_si = get_time(p_si, P); if (t_all – t_si > 0) suspend(p_si); else resume(p_si); } WEB Indexing 状況に応じてIndexingを止める Monarch Scheduler • 定期的にすべてのVMをチェック • 必要なプロセスのCPU使用率を取得 • WebやDBがCPUを使っているとき • Indexingを止める • CPUを使っているプロセスが存在しないとき • Indexingを動かす Hardware

20. 実装 run queue VMs process interrupt schedule Xen Monarch Scheduler • Xen 3.4.2 にMonarch Schedulerを実装 • サポートしているゲストOS • Linux 2.6 (x86_64) • Windows Vista (x86_64) • スケジューラはVMM内のタイマで定期的に起動

21. ゲストOSのデータ構造の操作 page table VM machine memory P2M table kernel image virtual address • ゲストOSのデータ構造を直接操作 • 知識を事前に取得 • デバッグ情報から型情報 • ソースコード • ゲストOSのメモリを直接読み書き • 仮想アドレスからマシンフレーム番号を取得 • ゲストOSのページテーブルを参照 • P2Mテーブルを参照 Xen VMM

22. Linux: データ構造の位置特定 structx8664_pda { task_t* current; ulongdata_offset; …}; Linux memory GS register x8664_pda data_offset+PER_CPU_RUNQUEUES run queue • init_taskがプロセスリストの起点 • カーネルイメージから事前に取得 • ランキューは仮想CPUごとに存在 • ブートするまでアドレスは不明 • 仮想CPUのGSレジスタから • GSレジスタはx8664_pdaを指す

23. Windows: データ構造の位置推定 実行中プロセス 実行待ちプロセス I/O待ちプロセス • Windows Kernel ProcHead current 一定距離 summary 実行待ちリスト配列 IRQL • プロセスリストの取得 • メモリ全体からプロセス候補を探す • プロセスを表すビット列を探索 • ProcHeadがプロセスリストの起点 • リストのうちグローバル変数 • ランキューはProcHeadから一定距離 ランキュー VMM

24. 一貫性を保ったランキュー操作 runqueue scheduler of Linux OS spinlock schedule() { spin_lock(runqueue); RUN QUEUE OPERATION spin_unlock(runqueue); } Monarch Scheduler lock check unlock • ゲストOSが操作していないときランキュー操作 • ロックをチェック • ロックが解放中ならスケジューリング中でない • ゲストOSと同時に操作すれば壊れる

25. 実験 Core 2 Duo 2.4 GHz Memory 6GB Xen 3.4.2 Dom0: Linux 2.6.18.8 DomU: Linux 2.6.16.33 (1GB) DomU: Windows Vista SP1 (1GB) • スケジューリングが可能かを確認 • アイドル時スケジューリング • 優先度スケジューリング • オーバーヘッド • スケジューリングのオーバーヘッド • CPU時間測定のオーバーヘッド • スケジューリング間隔の性能への影響 • OSバージョンの変化の影響

26. アイドル時スケジューリング VM1 VM2 lighttpd SearchIndexer Xen VMM アイドル時だけ動かす • ポリシー • lighttpdが動くときにSearchIndexerを停止 • アイドルの時だけSearchIndexerが動いた • ポリシー通り • レスポンス時間が23%改善した

27. 優先度スケジューリング Monarch Schedulerなし Monarch Schedulerあり VM1 VM2 mencoder ClamAV Xen VMM 優先度を下げる • ポリシー • ClamAVの優先度を下げる • CPU使用率を1/10に • 結果 • ポリシー通り制御できた

28. スケジューリングのオーバーヘッド • VMMからプロセスリストをたどる時間 • プロセス数を変化 • プロセス数を固定しVM数を変化 • 現実的な状況では、オーバーヘッドは小さい • 100プロセスで、 3.6us (Linux), 12.1us (Windows) • 5VMで4.4us

29. webサーバの性能低下 Throughput Response time • lighttpdのスループットと応答時間を測定 • スケジューリング間隔とプロセス数を変化 • リストをたどるだけ • 間隔が短く、プロセス数が増えるほど性能低下 • 10msec以上なら、影響は小さい

30. OSバージョンアップの影響 • OSのバージョンアップ時にMonarch Schedulerが対応すべきことを調査 • Monarch SchedulerはOSの内部構造に強く依存 • Linux 2.6.0から 2.6.32 の33バージョンを調査 • 外部からCFSのランキューを操作する必要 • 赤黒木ライブラリを397行中91か所変更 • CFSは赤黒木を利用

31. 関連研究 • ゲストOSの情報を使いVMをスケジューリング • guest-aware VM scheduling [2009 Kim et al.] • ゲストOSを変更 • task-aware VM scheduling [2008 Kim et al.] • gray box 知識を利用 • Windowsの内部情報をVMMから利用 • Vmwatcher [2007 Jiang et al.], EagleEye [2009 Nguyen et al.] • GREPEXEC • Lares [2008 Bryan et al.] • 専用のドライバが必要

32. ここまでのまとめ • Monarch Schedulerを提案 • 仮想マシンモニタがシステム全体を考慮してプロセススケジューリングを調整 • 柔軟なCPU割り当て • CPU利用効率の向上 • OSの事前の変更が不要 • VMMが直接メモリを書き換え • 複数OSへの対応 • 高水準APIでOSの種類やVMの違いを抽象化 • 正確なスケジューリング • プロセス時間をVMMが直接測定

33. II. 管理VM経由の情報漏洩防止

34. 管理VMを経由した情報漏洩 管理VMに侵入し ユーザVMの情報にアクセス 管理VM ユーザVM メモリ • 管理VMへの攻撃 • すべてのユーザVMに影響 • 管理のためにユーザVMに対して大きな権限 • サスペンド・マイグレーション • ユーザVMのメモリ内情報に簡単にアクセス可能 VMM

35. メモリからの情報漏洩 メモリを覗くだけで機密情報取得可能 ユーザVM /etc/shadow web appパスワード .ssh/id_dsa 暗号化ディスク • メモリ中には機密情報が存在 • パスワード • ファイルキャッシュ • ディスク暗号化でも防げない • メモリ上の情報は暗号化すると正しく動かない

36. 目標 • 管理VM経由の情報漏洩を防止 • 従来通りの管理が可能 • live migration • 負荷分散 • サービスを停止せずにハードウェアメンテナンス • OSを変更しない • 既存のOSをそのままサーバ統合可能

37. VMCrypt 管理VM ユーザVM 暗号化 暗号化メモリ メモリ メモリ • 管理VMへの情報漏洩を防ぐ • VMMが管理VMに対してメモリを暗号化して見せる • 管理に必要なメモリは暗号化せずに見せる • 従来通りの管理が可能 • live migrationに対応 • 準仮想化ゲストOSに対応 • 既存の管理ツールがそのまま使える VMCrypt VMM

38. ２つのメモリビュー 管理VM ユーザVM 暗号化 暗号化ビュー ノーマルビュー メモリ • VMCryptは２つのビューを提供 • 暗号化ビュー • ノーマルビュー • ユーザVMには暗号化せずそのまま見せる • ２つのビューに同時にアクセス可能 • live migrationに必要 • 動いているユーザVMのメモリを転送 VMCrypt VMM

39. ページ単位の暗号化・復号化 (1) 管理VMのマップを検出 (4) 管理VMのアンマップを検出 (2) VMCryptがページを複製 (5) 復号化 (3) VMCryptがページを暗号化 (6) 書き戻す 管理VM ユーザVM ページ’ ページ • 管理VMによるメモリマップ時に暗号化 • アンマップ時に復号化 • ページを複製することで、同時にアクセス可能 • マップ後の変化を知ることができない • live migration問題ない • VMMがページテーブルの変化を検出 Xen VMM

40. 暗号化・復号化を省略し高速化 • 読み込み専用マップでは、アンマップ時に復号化・書き戻しを省略 • 変更がないことを保証できる • 未初期化ページのマップ時は、暗号化を省略 • 情報は漏れない • もともと内容は不要 • 管理VMによって書きこまれたかを管理

41. 非暗号化ページ • p2m table • page table • 暗号化せずに管理VMに見せる • 従来通りの管理を可能にする • 機密情報は含まれない • 実行時に追跡して自動的に区別 • ビットマップで非暗号化ページを管理 • 5種類のページ • start info • ring • shared info

42. 非暗号化ページ: page table ユーザVM ページテーブル ドメイン0 ビットマップ 管理VM MFN32 … … 0 0 0 0 1 32 • マイグレーション時に管理VMがMFNを変更 • ページテーブルの変化を実行時に追跡 • 増えたらビットマップに追加 • ページ属性を設定するハイパーコールをチェック Xen

43. VMCryptを使ったlive migration(1/2) 別ホストへ 管理VM VMのメモリ bitmap kernel kernel ページテーブル ページテーブル • 動いているユーザVMのメモリを別ホストに転送 • VMCryptが自動で暗号化 • ビットマップを埋め込み転送 • メモリを転送 • ページテーブル、P2Mは書き換えつつ転送

44. VMCryptを使ったlive migration(2/2) 別ホストから 管理VM VMのメモリ bitmap kernel ページテーブル • 受け取ったメモリを新しいユーザVMに書き込み • VMCryptが自動で復号化 • ビットマップを取得 • 書き込み後、アンマップ時にVMCryptが復号化 • ページテーブルを書き換え • 新たに割り当てられたメモリを指すように

45. 暗号化鍵の管理 TC 1. Bの鍵を要求 2. Bの公開鍵 Host B Host A 管理VM 管理VM ユーザVM 4. 移送 VMM VMM SessionKey • マイグレーション時は暗号化鍵を共有 • Trusted Coordinator (TC) を経由 • 信頼できるVMMの公開鍵を管理 3. セッション鍵を暗号化して渡す

46. VMCryptはVMMを信頼 ユーザVM 管理VM 検査 Trusted Coordinator VMM TCB ハードウェア TCB • VMMは信頼できる • TCがremote attestationによって確かめる • 信頼できるbootかどうか • 管理VMはVMMのメモリにアクセスできない • Xenのアーキテクチャの特徴 • 管理VMを信頼しない

47. 実験 2.67GHz 8core Memory 12GB Xen 4.0.1 Dom0: Linux 2.6.32-5-xen-amd64 DomU: Linux 2.6.32.27 connected with gigabit ether • 情報漏洩を防げるかテスト • オーバーヘッド • 暗号化ビューを作るオーバーヘッド • ユーザVMの性能低下 • live migrationにかかる時間 • live migration時のオーバーヘッド • 暗号化アルゴリズムはAES • OpenSSLを移植

48. 情報漏洩を防げるかのテスト root@mach# aeskeyfind quattro1.dump bb2e3fe052aedffe8ddffd3fbcfa7d09 ea9b7567ae60e300d00bde56096d3170 Keyfind progress: 100% • 管理VMからユーザVMのメモリを解析 • メモリ中にはAESやRSAの鍵 • VMCryptなし • AESやRSAの鍵を盗むことができた • VMCryptあり • AESやRSAの鍵は見つからなかった

49. 暗号ビューを作るオーバーヘッド • 管理VMからマップ・アンマップにかかる時間 • 1ページ、10万回繰り返し平均 • 実行時間の大部分は暗号化 • それ以外のオーバヘッドは3usec • 最適化の効果あり

50. live migrationにかかる時間 暗号化により全体の時間は約1.8倍に増加 ダウンタイムは1秒未満