A Fast Rejuvenation Technique for Server

仮想計算機を用いたサーバ統合に
おける高速なソフトウェア若化手法
光来健一
千葉滋
東京工業大学
ＶＭを用いたサーバ統合
 サーバ統合が行われるようになっている
 複数のサーバ計算機を１台の計算機に統合
 仮想計算機（ＶＭ）が用いられるように
 ＶＭは仮想計算機モニタ（ＶＭＭ）上で動く
 システムリソースを管理
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% 削減
 ソフトウェア若化後の性能低下なし

Download Report