Transcript ppt - KSL
仮想計算機を用いたサーバ統合に おける高速なソフトウェア若化手法 光来健一 千葉滋 東京工業大学 ＶＭを用いたサーバ統合 サーバ統合が行われるようになっている 複数のサーバ計算機を１台の計算機に統合 仮想計算機（ＶＭ）が用いられるように ＶＭは仮想計算機モニタ（ＶＭＭ）上で動く システムリソースを管理 VM VM ... VMM ハードウェア ＶＭＭのソフトウェア・エージング ＶＭＭのソフトウェア・エージングが問題に ソフトウェア・エージングとは ソフトウェアの状態が時間とともに劣化する現象 例：システムリソースの不足 ソフトウェア・エージングは全てのＶＭに影響を及 ぼす 例：性能低下 VM VM ... VMM ＶＭＭのソフトウェア若化 予防保守 時々ＶＭＭを停止させ、内部状態を正常に戻して から再開する ＶＭＭのソフトウェア・エージングがＶＭに影響を 及ぼす前に実行される 典型的な例：ＶＭＭの再起動 内部状態を自動的に完全に元に戻せる 最も簡単な手法 問題（1/2）：ダウンタイムの増大 ＶＭＭの再起動は以下を必要とする ＶＭ上で動いているすべてのＯＳの再起動 ＯＳ再起動にかかる時間は増大している １台の計算機で動かせるＶＭの 数の増加 サービスの停止・開始にかかる 時間の増大 ハードウェアリセット BIOS の POST (power-on self test) に時間がかかる VM OS OS VMM ... 問題（2/2）：性能低下 ＯＳ再起動でファイルキャッシュが失われる ファイルキャッシュが回復するまでＯＳは性能を回 復できない ＯＳのファイルアクセス性能はファイルキャッシュに強 く依存 ファイルキャッシュの回復にかかる 時間が増加 プロセス ファイル キャッシュ ファイルキャッシュのサイズが増大 より多くのメモリがＶＭに割り当て可能に 空きメモリはファイルキャッシュになる OS ディスク Warm-VM Reboot 高速なソフトウェア若化手法 効率よくＶＭＭだけを再起動 ＶＭＭ再起動はＯＳ再起動を必要としない 基本的なアイデア ＶＭＭの再起動前にすべてのＶＭをサスペンド 再起動後にＶＭをレジューム チャレンジ ＶＭの巨大なメモリイメージをいかに効率よく扱うか？ ＶＭのオンメモリ・サスペンド ＶＭのメモリイメージをメインメモリ上で凍結 メモリ領域を予約するだけ メモリサイズにほとんど依存しない メモリイメージを遅いディスクに保存するのは効率 が悪い ＶＭのためのACPI S3状態 VM Suspend To RAM 従来のサスペンドは ACPI S4状態 ディスク 凍 結 メインメモリ ＶＭのオンメモリ・レジューム メインメモリ上に保持されているメモリイメージ を解凍 ＶＭのメモリとして直接再利用 遅いディスクから読み込む必要がない ＯＳのファイルキャッシュも復元される 性能低下がない VM ディスク 解 凍 メインメモリ ＶＭＭのクイック・リロード 新しいＶＭＭをハードウェアリセットせずに直 接起動 ＶＭのメモリイメージはＶＭＭ再起動を通して保持 される ソフトウェア的にメモリイメージを保持し続けられる ハードウェアリセットはこれを保証しない ＶＭＭを高速に再起動できる メインメモリ ハードウェアリセットの オーバヘッドなし VM 新VMM preload 旧VMM 他の手法との比較 Cold-VM Reboot ＯＳ再起動を必要とする Saved-VM Reboot Warm-VM Rebootのナイーブな実装 メモリイメージをディスクに保存 再起動の手法 Cold-VM Saved-VM Warm-VM ＶＭ数に依存 Yes No No サービスに依存 Yes No No Yes No No No ＶＭのメモリサイズに依存 No 性能低下 Yes 可用性のためのモデル ＶＭＭとＯＳの両方のソフトウェア若化を考え る必要がある Warm-VM Reboot ＯＳのソフトウェア若化は 独立して行える Cold-VM Reboot ＯＳのソフトウェア若化は ＶＭＭのそれに影響される ＯＳのソフトウェア若化の 回数が増加する ＯＳのソフトウェア若化 ＶＭＭのソフトウェア若化 ＯＳのソフトウェア若化 ＶＭＭのソフトウェア若化 RootHammer Warm-VM Reboot を Xen 3.0.0 に実装 オンメモリ・サスペンド／レジューム Xen のサスペンド／レジュームがベース ＶＭメモリから物理メモリへの VM メモリ マッピングを管理 クイック・リロード Linux の kexec 機構がベース 最近の Xen には同様の機構が含まれている そのままではメモリイメージの再利用はできない 物理 メモリ 実験 Warm-VM Reboot がダウンタイムと性能低 下を減少させられるかどうか調べた 比較 ＯＳ再起動を伴う Cold-VM Reboot サスペンド／レジュームを使った Saved-VM Reboot サーバ ... Linux Linux クライアント VMM 2 dual-core 12 GB 15,000 rpm gigabit Opteron SDRAM SCSI disk Ethernet Linux オンメモリ・サスペンド／レジュームの 性能 メモリ 11 ＧＢのＶＭのサス ペンド／レジューム時間 オンメモリ: 1 秒 Xen: 280 秒 （4分40秒） メモリサイズに比例 11 ＶＭのサスペンド／ レジューム時間 ＯＳ再起動: 58 秒 ＶＭ数に比例 クイック・リロードの効果 VMMのブート ハードウェアリセット VMMのシャットダウン ＶＭなしでＶＭＭのみの 再起動時間を測定 Warm-VM Reboot 70 60 11 秒 クイック・リロードの時間 はほぼ 0 50 40 Cold-VM Reboot 30 59 秒 ハードウェアリセットに起 因する時間は 48 秒 20 10 0 Warm-VM Cold-VM サービスのダウンタイム Warm-VM Reboot ほぼ一定 42 秒 Saved-VM Reboot ＶＭ数に比例 約 7 分 （11 ＶＭ） Cold-VM Reboot サービスの種類に依存 約 2.5 分 （sshd） 約 4 分 （JBoss） JBoss の稼働率 Warm-VM Reboot は４つの９を達成 仮定 ＯＳのソフトウェア若化を毎週行う ダウンタイムは 34 秒 ＶＭＭのソフトウェア若化を４週ごとに行う 平均してＯＳのソフトウェア若化の 0.5 週後 1週 ＯＳのソフトウェア若化 ＶＭのソフトウェア若化 0.5 週 Warm-VM Cold-VM Saved-VM 99.993% 99.985% 99.977% 性能低下 Apache ウェブサーバの スループットを測定 VMM再起動の前後 Warm-VM Reboot 性能低下なし Cold-VM Reboot 69% の性能低下 ＶＭＭのソフトウェア・エージングは 実際に起こるか？ Xen にはメモリリークのバグがあった ＶＭの再起動時 エラー処理を行う際 Xen のヒープサイズはあまり大きくない デフォルトのヒープサイズは 16 MB x86_64 アーキテクチャではある程度増やせる i386 アーキテクチャでは変更できない メモリリークするとメモリ不足になりやすい ＶＭＭとみなすべき範囲は実は広い Xen のドメイン０はＶＭＭとみなすべき 他のＶＭの I/O 処理を行う特権ＶＭ I/O 処理の遅れはＶＭの性能に影響 ＶＭＭに強く依存 ドメイン０の再起動はＶＭＭの再起動を伴う 改造された Linux が動作 カーネルメモリやスワップ スペースが枯渇する可能性 ドメイン０ OS VM VM VMM 関連研究 Microreboot [Candea et al.'04] サブコンポーネントの一部だけを再起動 Warm-VM Reboot は親コンポーネント（ＶＭに対す るＶＭＭ）だけを再起動 チェックポイント／リスタート [Randell '75] ＯＳプロセスを保存・復元 ＶＭのサスペンド／レジュームに似ている サスペンド／レジュームの最適化 メモリイメージの差分だけを保存 メモリイメージを圧縮して保存 まとめ Warm-VM Reboot を提案 オンメモリ・サスペンド／レジューム ＶＭのメモリイメージを凍結・解凍 クイック・リロード ＶＭＭの再起動を通してＶＭのメモリイメージを保持 ＶＭＭの高速なソフトウェア若化を実現 ダウンタイムを最大 83% 削減 ソフトウェア若化後の性能低下なし