小川 大地、飯島 徹
日本ヒューレット・パッカード

 従来のVMotionは、移行する前と後のホスト機に搭載されているプロセッサの世代が同一である必要があった。プロセッサの命令群は、世代が進むにつれて増えていくが、実行される命令群は仮想マシンの移行前後で同じである必要があるからだ。vSphereでは、この制限を緩和するための機能としてEVC(Enhanced VMotion Compatibility)を実装した。

 VMotionは、OSとアプリケーションをひとまとまりにカプセル化する、仮想化だからこそ実現できる画期的な機能である。だが、VMotionでは仮想マシンのゲストOSをシャットダウンせず、アプリケーションを動作させたままホスト間を移行するため、移行元と移行先のプロセッサが、同一ベンダー・同一世代のものでなければならないという制約がある(図1)。

図1●VMotionにおけるプロセッサの制約
[画像のクリックで拡大表示]

 この制約はESXに限ったことではなく、ほかのハイパーバイザーで「ホット・マイグレーション」を実行する場合も同様である。アプリケーションの使用する拡張命令が、移行先のプロセッサでサポートされていれば問題は発生しない。しかし、アプリケーションがどの拡張命令を使うのかESXは予測できないので、安全のためVMotionを実行する前に、必ず両サーバーについてプロセッサの互換性チェックが行われる。不一致がある場合は、図2のようにVMotionの実行がガードされる。

図2●プロセッサの互換性チェックで不一致がある場合はVMotionの実行をガードする
[画像のクリックで拡大表示]

 アプリケーションを独自開発した場合など、どの拡張命令を使用するかを熟知している管理者にとって、このガードは不要と感じるかもしれない。しかし、拡張命令はアプリケーションだけではなく、OSによって使われることもある。アップデート・パッチを適用したことで、新しい拡張命令が使われ出す、といったこともあるため、厳格に把握するのは難しい。

 では、プロセッサに世代の制約がかかると、管理者にはどのようなデメリットがあるのだろうか。

 一つ例を挙げてみよう。サーバー仮想化は、昨今の不況によるIT投資削減の影響もあるが、最初は小さなシステムで試験導入するというケースがほとんどだろう。

 スモールスタートで導入を開始した管理者が1年使ってみて仮想化の便利さを感じ、より集約を進めようとサーバーの追加を検討したとする。しかし、業界標準サーバーはライフサイクルが短いので、既存のプロセッサを搭載したサーバー機を入手できないことが多い。

 もちろん後継製品を搭載したサーバー機であれば購入可能であるが、VMotionで重要な「プロセッサ世代」が異なるため、既存のホストと新規追加したホスト間でVMotionができないという問題に直面する。

 この問題を以前から重要視していたヴイエムウェアは、ESX 3.5 Update 2で新しい技術を実装した。それがEVC(Enhanced VMotion Compatibility)である。

この先は会員の登録が必要です。今なら有料会員(月額プラン)が2020年1月末まで無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら