ライブマイグレーション
「ライブマイグレーション」─このハイカラな響きに魅了され、この機能に興味を持った方は少なくないのではないでしょうか。事実、仮想化関連の講演や商品紹介において、この言葉は多くの関心を集めています。クラウド環境での動的負荷分散、無停止でのサーバの保守・運用といった真面目な側面を差し引いても、技術者・ユーザを問わず興奮させる何かがあるようです。
もちろんKVM/QEMUにもこの機能は実装されていて、注目を集めています。この記事では、そのライブマイグレーションに関して、現在、開発者間で活発に議論されている性能改善に関する取り組みの最新動向を紹介します。
プリコピー・マイグレーション
ライブマイグレーションでは、現在仮想マシンを実行しているノード（移行元ノード）から、仮想マシンを移したいノード（移行先ノード）へ、仮想マシンの実体（インスタンス）を転送（コピー）する必要があります。この中には、仮想マシンに割り当てているメモリ、仮想マシンが利用する仮想デバイスの状態等、移行先のハイパーバイザが仮想マシンを実行するために必要な情報が全て含まれています。そして、ゲストが利用する仮想ディスクが、共有ストレージにより移行先からも利用できると仮定すると[1]、最も転送量が多くなるのは、昨今、容量が増すばかりのメモリ（RAMイメージ）です。
このメモリの転送方式として、プリコピー・マイグレーションがあります。これはQEMUも採用している最も標準的なものであり、以下の手順により、変化するゲストメモリを喪失することなく移行先に転送します。
- 1．反復転送
- 仮想マシンを止めずにメモリの内容を移行先に転送し、転送処理の間にゲストがさらに更新したページ（ダーティページ）は、反復的に再度転送する。
- 2．ストップ＆コピー
- 仮想マシンを停止し、1．の反復の後にダーティになった残りのページを全て転送する。
メモリ転送の完了後は、移行先で速やかに仮想マシンの実行を再開させます。
すでにお気づきの方も多いと思いますが、ライブとは言うものの、手順2.（ストップ＆コピー）の処理の間、仮想マシンは停止します。この停止時間こそ、「ライブマイグレーションのダウンタイム」と呼ばれる問題児なのです。
ダウンタイムとの格闘
仮想化製品を売り込む立場に立つと、「ダウンタイムは最大何ミリ秒」といった売り込み文句は不可欠です。「ライブ」とうたうからには、30秒サービスの応答がなくなるようでは納得されないからです。しかし、技術的に難しい点も多く、開発者のダウンタイムとの戦いが現在も続いています。
QEMUの反復収束
QEMUでは、ダウンタイムを制御するため、ストップ＆コピー時に転送すべき残りのダーティページが少なくなるように工夫しています。具体的には、反復転送時に、目標ダウンタイムとネットワークの転送速度からある割合を計算し、その割合以下にダーティページが収束するまで反復を続けます。
手元の環境でライブマイグレーションを試すだけであれば、これ以上の戦いは不要かもしれません。しかし、製品としてダウンタイム上限をうたうためには、これだけでは不十分です。反復中、メモリを転送する処理よりも、ゲストによるメモリの更新の方が速い場合、反復を重ねてもダーティページの割合が一向に収束しないという事態が生じるからです。
XBRLE差分圧縮ライブマイグレーション
この問題への対策として、帯域がボトルネックになるネットワーク上での転送そのものを削減することで、メモリ収束の高速化、ダウンタイムの削減を図る手段があります。SAP Research社のBenoit Hudzia氏等が提案するXBRLEを利用した差分圧縮転送方式です。
昨年のKVM Forum 2011での発表と、QEMUの開発者用メーリングリストに投稿されている内容（パッチ）を見るとわかりますが、この方式は、ゲストが頻繁に更新するホットなページをキャッシュします。そして、反復の過程で再度同じページを転送することになった場合、前回キャッシュしておいた内容との差分を圧縮して移行先に送ります。移行先でも同様に保持している前回のページ内容に、受け取った差分を足して最新のページ内容を復元することができるため、更新されたページの内容をそのまま送るよりも転送量を抑えられるという訳です。なお、XBRLEというのは、XOR + Binary Run Length Encodingを略したもので、この方式で用いられている圧縮アルゴリズムの名前です[2]。
KVM Forum 2011では、SAP ERPのような大量のメモリを必要とする商用アプリケーションが動作中でも、満足できるダウンタイムで移行が完了すると発表されており、今後の開発動向が楽しみな技術の１つです。
ポストコピー・マイグレーション
全く別のアプローチとして、ポストコピー・マイグレーションがあります。この方式は、そもそもメモリ更新が収束するまでダーティページを何度も転送するのではなく、最初にCPUのレジスタ等、移行先での実行開始に最低限必要な状態だけを転送し、その他のメモリ内容は、移行先で動き出したゲストが実際に参照した際、オンデマンドで移行元から転送します。
KVM/QEMUへの適用は、産業技術総合研究所の広渕崇宏（Takahiro Hirofuchi）氏がKVM Forum 2011で提唱し、VA Linux Systems Japan社の山幡為佐久（Isaku Yamahata）氏が、アップストリームへの採用を目指し、パッチを投稿しました。
実装方式からも分かりますが、この方式では、移行先でページが参照された時にまだページが移行元に存在する場合、ネットワーク越しのページ転送による遅延が生じます。この遅延を極力抑えるため、移行先でのゲストの実行のバックグランドで未転送のページを転送しておくなど、様々な工夫が加えられています。しかし、未知の負荷特性に対しどのような影響が生じるのかはまだ分からない点も多いため、開発者間でもこの方式の性能に対する見解は分かれています。
なお、パッチのレビューでは、Transparent Huge Pagesでお馴染みのRed Hat社のAndrea Arcangeli氏等、著名なカーネルハッカーも参戦し、様々なアイデアが議論されています。将来、KVM/QEMUのライブマイグレーションがプリコピー／ポストコピーのいずれになるのか、それとも2方式から選択可能になるのか、今後の動向に注目が集まっています。
更なる性能改善を目指して
今回は、KVM/QEMUのライブマイグレーションが抱えるダウンタイムに関連した性能問題を取り上げ、最新の開発動向を紹介しました。しかし、ライブマイグレーションに関する性能問題は他にもいろいろと存在します。
実は、筆者も、プリコピーの反復転送時に繰り返される、ダーティページのトラッキングに起因するゲスト遅延という問題の改善に取り組んでいます。
LinuxCon Japan 2012でも、ライブマイグレーションに関する発表があると思いますので、お楽しみに。今後のライブマイグレーション性能改善にご期待あれ！
