このようにライブ・マイグレーションを実装するには、NTFSを核としたディスク構造そのものを設計し直さなければならず、多大な開発期間がかかる。このため、Windows Server 2008に付属していたHyper-Vの初期バージョン(Hyper-V 1.0)では、一時的なダウンが発生するものの、アプリケーションやゲストOSそのもののシャットダウンは不要という、準ライブ・マイグレーション機能「クイック・マイグレーション」が実装された。
クイック・マイグレーションの流れを簡単におさらいしよう。
前述のとおり、仮想マシンを移動するにはメモリとディスクのデータを引き継ぐ必要があるが、クイック・マイグレーションではメモリ・データをいったんディスクに保存し、メモリとディスク内容と一緒に移動先ホストへ引き渡す方法を用いている。メモリをディスクに保存する部分は、PCの休止状態(ハイバネーション)をイメージすると分かりやすい。
従って、クイック・マイグレーションで問題となるダウンタイムは(1)〜(5)の所要時間となる。(1)と(5)の処理はほぼ一瞬で完了し、(3)のディスク切り替えの時間は先に述べたとおり数秒間だ。つまり、ダウンタイムに最も影響するのは、メモリ・データが実際にコピーされる(2)と(4)の処理となる。
では、メモリ・データのコピー時間は何の要素に左右されるのだろうか。筆者が実機を用いてさまざまなパターンのテストを行った結果、次のような結果が得られた。
このグラフから分かるように、ダウンタイムは次の要素に影響されるといえる。
1番目の仮想マシンに割り当てるメモリ設定量に応じてダウンタイムが増えるのは理解しやすいだろう。保存や転送の対象となる領域が増えるからだ。
2番目のファイル・キャッシュの蓄積状況というのは、Windows ServerやLinuxなどのサーバOS特有のものである。OSがファイルを扱う場合、そのファイルはメモリに展開されるが、サーバOSの場合はファイルの使用が終わってもメモリ上のデータは削除せずにキャッシュとして残す。このため、ゲストOS起動直後のメモリ領域はほぼ空の状態(多くが未使用の状態)であるが、稼働時間が長くなるにつれて、ファイル・キャッシュが蓄積されていく。つまり、空の領域が実データで埋められていくにつれてクイック・マイグレーションの所要時間が延びてしまうのだ。
上記のグラフは筆者が実機でテストした結果の一部であるが、実際にはこのグラフにない3番目の「ホストの負荷状況」も考慮しなければならない。筆者の環境では、仮想マシンに4Gbytesのメモリを割り当てた場合に、ホストの負荷がアイドル状態で18秒だったのに対し、最も高負荷の状態では5分弱と、ダウンタイムは約16倍にも延びてしまった。
ここまで、クイック・マイグレーションのダウンタイムについて、テスト結果を含めて解説したが、そもそもクイック・マイグレーションはHyper-V 1.0時代の機能である。引き続きHyper-V 2.0でも利用できるものの、「Hyper-V 2.0にはライブ・マイグレーションがあるから、こんな知識はいまさら意味がない」と感じた読者もいるかもしれない。
しかし、このノウハウはライブ・マイグレーションにも適用される。なぜなら、ライブ・マイグレーションもメモリ・データのコピーを行うからだ。後ほど詳しく解説するが、ライブ・マイグレーションは実行後すぐに移動が完了するわけではない。いくつかのプロセスを通じて全体で数十秒〜数分の処理時間を要する。従って、ライブ・マイグレーションの所要時間を見積もるためにも、こういった知識は理解しておく必要があるだろう。
また、仮想マシンのメモリ内容をいったんディスクに保存するという処理はマイグレーションだけではなく、バックアップで使われるケースもある。バックアップ時間の見積もりにも役立つことがあるはずだ。
Copyright© Digital Advantage Corp. All Rights Reserved.