Transcript ppt - KSL

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