仮想计算机用ー统合高速.pptVIP

仮想計算機を用いたサーバ統合における高速なソフトウェア若化手法 光来健一　　千葉滋 東京工業大学 ＶＭを用いたサーバ統合 サーバ統合が行われるようになっている 複数のサーバ計算機を１台の計算機に統合 仮想計算機（ＶＭ）が用いられるように ＶＭは仮想計算機モニタ（ＶＭＭ）上で動く システムリソースを管理 ＶＭＭのソフトウェア?エージング ＶＭＭのソフトウェア?エージングが問題に ソフトウェア?エージングとは ソフトウェアの状態が時間とともに劣化する現象 例：システムリソースの不足 ソフトウェア?エージングは全てのＶＭに影響を及ぼす 例：性能低下 ＶＭＭのソフトウェア若化 予防保守 時々ＶＭＭを停止させ、内部状態を正常に戻してから再開する ＶＭＭのソフトウェア?エージングがＶＭに影響を及ぼす前に実行される 典型的な例：ＶＭＭの再起動 内部状態を自動的に完全に元に戻せる 最も簡単な手法 問題（1/2）：ダウンタイムの増大 ＶＭＭの再起動は以下を必要とする ＶＭ上で動いているすべてのＯＳの再起動 ＯＳ再起動にかかる時間は増大している １台の計算機で動かせるＶＭの数の増加 サービスの停止?開始にかかる時間の増大 ハードウェアリセット BIOS の POST (power-onself test)　に時間がかかる 問題（2/2）：性能低下 ＯＳ再起動でファイルキャッシュが失われる ファイルキャッシュが回復するまでＯＳは性能を回復できない ＯＳのファイルアクセス性能はファイルキャッシュに強く依存 ファイルキャッシュの回復にかかる時間が増加 ファイルキャッシュのサイズが増大 より多くのメモリがＶＭに割り当て可能に 空きメモリはファイルキャッシュになる Warm-VM Reboot 高速なソフトウェア若化手法 効率よくＶＭＭだけを再起動 ＶＭＭ再起動はＯＳ再起動を必要としない 基本的なアイデア ＶＭＭの再起動前にすべてのＶＭをサスペンド 再起動後にＶＭをレジューム チャレンジ ＶＭの巨大なメモリイメージをいかに効率よく扱うか？ ＶＭのオンメモリ?サスペンド ＶＭのメモリイメージをメインメモリ上で凍結 メモリ領域を予約するだけ メモリサイズにほとんど依存しない メモリイメージを遅いディスクに保存するのは効率が悪い ＶＭのためのACPI S3状態 Suspend To RAM 従来のサスペンドはACPI S4状態 ＶＭのオンメモリ?レジューム メインメモリ上に保持されているメモリイメージを解凍 ＶＭのメモリとして直接再利用 遅いディスクから読み込む必要がない ＯＳのファイルキャッシュも復元される 性能低下がない ＶＭＭのクイック?リロード 新しいＶＭＭをハードウェアリセットせずに直接起動 ＶＭのメモリイメージはＶＭＭ再起動を通して保持される ソフトウェア的にメモリイメージを保持し続けられる ハードウェアリセットはこれを保証しない ＶＭＭを高速に再起動できる ハードウェアリセットのオーバヘッドなし 他の手法との比較 Cold-VM Reboot ＯＳ再起動を必要とする Saved-VM Reboot Warm-VM Rebootのナイーブな実装 メモリイメージをディスクに保存 可用性のためのモデル ＶＭＭとＯＳの両方のソフトウェア若化を考える必要がある Warm-VM Reboot ＯＳのソフトウェア若化は独立して行える Cold-VM Reboot ＯＳのソフトウェア若化はＶＭＭのそれに影響される ＯＳのソフトウェア若化の回数が増加する RootHammer Warm-VM Reboot を Xen 3.0.0 に実装 オンメモリ?サスペンド／レジューム Xen のサスペンド／レジュームがベース ＶＭメモリから物理メモリへのマッピングを管理 クイック?リロード Linux の kexec 機構がベース 最近の Xen には同様の機構が含まれている そのままではメモリイメージの再利用はできない 実験 Warm-VM Reboot がダウンタイムと性能低下を減少させられるかどうか調べた 比較 ＯＳ再起動を伴う Cold-VM Reboot サスペンド／レジュームを使った Saved-VM Reboot オンメモリ?サスペンド／レジュームの性能 メモリ 11 ＧＢのＶＭのサスペンド／レジューム時間 オンメモリ: 1 秒 Xen: 280 秒 （4分40秒） メモリサイズに比例 11 ＶＭのサスペンド／レジューム時間 ＯＳ再起動: 58 秒 ＶＭ数に比例 クイック?リロードの効果 ＶＭなしでＶＭＭのみの再起動時間を測定 Warm-VM Reboot 11 秒 クイック?リロードの時間はほぼ 0 Cold-VM Reboot 59