R&D:VMライブマイグレーションを4から10倍以上へ加速する(20090414-8)
ゲスト執筆者:Kevin Lawton、Bochs開発主任
VMライブマイグレーション(VMware社でいう「VMotion」)は、多数の便利な機能の基盤となる重要な技術だ。たとえば、VMware社のDRSおよびDPMの両機能は移行を使うことでそれぞれ負荷バランシングとパワーマネジメントを行う。 これらは本質的に高いレベルのスケジューリングだが、OSのスケジュール機能より時間精度は粗い。
同じストレージやネットワーキングドメイン内での移行を考えると、限られたネットワーキング帯域幅のなかで移行元と先のサーバ間で転送の必要なVMメモリはかなり大量になる。たとえば、1Gビットネットワークでは、2GバイトのRAMを搭載したVMの移行は最高条件で約20秒になる。また、10Gビットネットワークになると、同じVMの移行が最高条件で約2秒となる。場合によっては、ライブマイグレーションの完了に数分かかることもある。
スケジューリングメカニズムとして比較的遅いVMの移行を使用する場合は多数のリスクや欠点が出てしまい、ポテンシャルをフルに発揮できなくなってしまう。
ただ、ワークロードが増減(および急上昇)する時間はスケジューラが別のサーバでVMのスケジュールを見直すときのレスポンスタイムより大幅に速いため、これが必ずしも当てはまらない。結果的に、スケジューラは極端に保守的でないとSLAを満たせなかったり、負荷に起因する面倒なホットスポットが発生してしまう。 対照的に、スケジューラが即時性の高いVM移行を予想できれば、忠実度が大幅に高い負荷バランシングや、はるかに効率的なパワーマネジメント(稼働中のサーバに間違いなく最小限のVMを詰め込む)が可能になる。 したがって、ライブVM移行の回数が減るほど保守性も必要されなくなり、潜在的なパフォーマンスや節電量を既存のリソースからより多く絞り出せるようになる。
VM移行の加速
VMの移行時間を加速させるときにカギとなることの1つが、コンピュータシステム全体の重複メモリの利用だ。
所定の物理サーバ内の場合と同じように、重複メモリの量は一般的にかなり多い。 VMが似ていれば似ているほど重複の割合も高くなる。 しかし筆者は、サーバ内のメモリ重複を探すのではなくサーバシステム(クラウド)全体のメモリの内容を見てみた。
各サーバが全体のなかのメンバーとなり、それぞれが協力してシステム全体のメモリの重複を特定および適切に記録する。もちろん、これにはメモリの重複分析を行うための何らかの新しいインフラと幅広いテクニックが必要になるが、既存の仮想化ハイパーバイザーに組み込める可能性はある。 強力な利点だ。メモリ容量の分析を選択したサーバ全体にまで拡大することで、すべての物理サーバが一定のタイミングで多種多様なVMをホスティングしていても、はるかに多くの重複を見つけることができる。 対照的に、サーバ内コンテンツ共有は、その範囲が現行のVMワークロードのメモリの内容に制限されている(チャンスが減り、VMの多様性が制限される)。
分散メモリ型重複ネットワークがあれば、非常に具体的なメリットが生まれる。
まず、移行元と先で存在が認識されるメモリは転送の必要がなくなる。転送先の既存のメモリの内容から単純にコピーされる(あるいはポインタで参照する)だけだ。これは、重複の場合のネットワーキングの転送時間と、それが消費したであろう帯域幅の両方を排除してくれる。
したがって、75%の冗長性が見つかるような場合は、メモリの内容のわずか25%と、省略情報に関する何らかのメタ情報の転送が必要になる。
ライブマイグレーションの仕組みにより、これが強力な最適化につながる。一般的に、VMが実行され続ける間にメモリの状態の事前コピーが初回に送信される。それ以降の転送では、しきい値(最低限のデータ容量)になるまで前回との差分だけが転送され、その時点でVMが一時停止されて残りの差分が転送される。
初回のデータ転送が減れば、2回目の時間(そして差分のメモリ容量)が減少することで多大な見返りがある。 2回目が減少すれば、3回目の減少につながる。
もっと具体的に説明すると、こちらのVMware社の話(スライドの11)が、16秒、4秒、1秒、0.25秒という2GバイトのVM(1Gビットネットワーク使用)における段階的な短縮を示している。筆者が調査したメモリ重複ネットワークでは、これが4秒、1.0秒、0.25秒へ短縮できた。 つまり、現行の技術より約4倍高速ということになる。
限界に挑む
4倍の最適化は 前述の20秒の移行ケースを5秒(1Gビット時)、そして2秒のケースを0.5秒(10Gビット時)に加速させることになる。
それだけでも、より積極的な負荷/パワーマネジメントのスケジューリング時間の精度を一段と魅力的にするのに十分なものだ。しかし、消費電力/計算能力/メモリなどのさまざまな代償を払ってさらに最適化を進める方法もいくつかある。
まず、メモリ共有の最適化にはページ単位以下精度(最大65%)や差分エンジン(最大で驚異的な90%)など、多数のテクニックが研究されている。しかし、2番目のテクニックは単独でもほかのテクニックと一緒でも利用できる。
分散メモリの共有ネットワークがある場合、重複していないメモリも推測に基づいてネットワーク内のほかのノードに転送(模写)し、一致するメモリの内容を自由自在に消して、より逼迫した用途に使うことができる。 つまり、サーバネットワーク内の「予備」のメモリを使うことができる。
もちろん、変更頻度の高いメモリ領域はこのようなレプリケーションの候補として必ずしも良くはない。 しかし、筆者が行った調査では、80%あるいは90%の効率的な共有の実現が難しくないことが分かっており、VMの移行移行は新奇なメモリ共有テクニックを採用しなくても5倍から10倍まで加速することができる。
ここから、制限の多いネットワーキング回線で長距離のVM移行を行うときの技術のもう1つのメリットが明らかになる。
VMworldにおけるVMware社の基調講演で明らかになったように、このユースケースは今も進化している。しかし、2カ所の離れた場所にあるデータセンタ間のVM移行について考えてみたい。 言うまでもなく、限りのあるネットワーキング資源をあふれさせるVMメモリデータは省略テクニックを使って減らした方が良い。
また、もう1つ興味深いのは、必ずしも転送元と先のサーバの間に重複データを持つ必要がない点だ。 重複したデータは転送先のデータセンタ、できれば転送先に近いどこかに置くだけでよい。
この場合、重複したデータはデータセンタ内の近距離転送、そして独自データはデータセンタ内で長距離転送することができる。しかも並行処理ができるのだ。
拡張可能なメモリ共有ネットワークインフラがあれば、仮想化のクラウドが大きければ大きいほど、このような最適化のチャンスも増える。 また、ユニークなメモリレプリケーションのための推測用の予備メモリが多く利用できるようになる。
消費電力
サーバや関連チップの起動に多数のオーバーヘッドがかかるため、ハイパーバイザー上で最初に実行されるVMが消費電力の点では最も費用がかかる。 VMを追加(それにより必要な速度と消費電力も増加)すると、電源投入時のコストが既に償却済みになることからコストは徐々に下がっていく。 より細かいスケジューリングを可能にすると、1台の物理サーバ上の平均負荷(およびVM密度)が上がり、リソースの利用率と電力効率の両方が改善される利点がある。 大ざっぱなモデルから予測しているので、この利用率は迅速なスケジューリングを使えばさらに15%以上向上する可能性がある。 これは結果的にハードウェアが15%以上減ることになり、大きな節電につながる可能性もある。
スケジューリング
負荷バランシングとパワーマネジメントのスケジューリングはしばらくの間進化し続けると思う。 ここで説明したテクニックで素晴らしいのは、もっと多くの知識があるため、それをスケジューリングの判断に利用できることだ。 どの2つのVMが共有するポテンシャルでも予知できるため、サーバ間のスケジューリングなどでより似通ったVMを同じ物理サーバ上に配置して密度を高めることができる。 これまでのように、サーバは計算能力が限界に来る前にRAMが無くなってしまう。 したがって、VM密度の高さが最大利用率の実現にとって重要になる。
クラウドと一緒の成長
これは、多くのVMが物理的な特定の場所の外でライブ移行をしない傾向にある仮想化の既存ユースケースに即座にメリットを提供する技術となっている。 しかし、VMworldの基調講演にあるように、これは複数の場所に分散したデータセンタにもうまくスケーリングするほか、複数の物理的な場所にまたがるため、仮想化とともに成長する。 実際、後者の場合はVMの移行時間を最適化し、消費ネットワーク帯域幅を削減することが間違いなく重要となる。そして筆者は、この技術は将来のストレージやネットワーキングの継続稼働ソリューションとうまく結びつくと思っている。
著者について
Kevin Lawtonはx86の仮想化技術の草分けで、いくつもの企業を起業したビジネスや技術のビジョナリーであり、さまざまなアイデアを生み出し、ニュースやビジネス書を大量に読む。マイクロプロセッサベンダーの設立にも携わり、2つのオープンソースプロジェクトを立ち上げて指揮を執り、講演も多数行う。大学でコンピュータサイエンスの学位を取得して最初の就職先はMITリンカーン研究所だった。
著者へのコメントはこちら。この研究内容が特許申請中であることに注意したい。
Copyright © 2003-2009 virtualization.info. All rights reserved.
virtualization.info Network: virtualization.info | virtualization.tv | Virtualization Congress



