VMware のライブマイグレーション機能であるvMotion は、初期のvSphere から使用可能な機能となり、バージョンアップを重ねる度に継続して機能拡張がなされています。vSphere 5.0 では、vMotion パフォーマンスの改善が行われており、最新のvSphere 5.1 では、共有ストレージを必要としない拡張vMotion が可能となりました。パフォーマンスの部分は、単純な機能比較では分かりにくい、目立たないところではありますが、運用上影響のあるところになります。
クラスタ内で負荷を均等化し、仮想化環境の統合率を高めるDRS（Distributed Resource Scheduler）といったvSphere の機能も、vMotion のテクノロジーがベースとなっています。お客様がDRS の導入をためらう理由として、稼働中の仮想マシンをライブマイグレーションすることによる、サービスに与える影響への懸念があります。今回ご紹介する試験の結果から、vSphere 4.1 を使用した多くのケースでサービスの中断なしに移行可能なこと、さらに非常に高負荷な環境であってもvSphere 5.0 の機能拡張によりスムーズに移行可能なことが確認できます。
以下のTechnical Paper では、vMotion のアーキテクチャと具体的な改善点、vSphere 4.1 とvSphere 5.0 を比較したvMotion のパフォーマンス試験、vMotion のベストプラクティスが提供されています。このテクニカルホワイトペーパーの内容について、一部要約する形でご紹介していきます。
VMware vSphere® vMotion® Architecture, Performance and Best Practices in VMware vSphere® 5
アーキテクチャ
仮想マシンのライブマイグレーションは、ハイスピードネットワークリンク越しに仮想マシンの状態を、移行元ホストから移行先ホストへ移行します。vMotion の実行状態には次の3つのコンポーネントがあります。
1. 仮想デバイスの状態（CPU、ネットワーク、ディスクアダプタ、SVGA等）
2. ネットワークとSCSI 装置の接続
3. 仮想マシンの物理メモリ
1. 仮想デバイスの状態
vMotion は、vSphere の仮想マシンの仮想デバイスの状態を8MB 以下のサイズにシリアル化する機能を活用します。ケースによっては128MB を超えることもあり、ハイスピードネットワーク越しに素早く移動することができます。
2. ネットワークとSCSI 装置の接続
vNIC は物理アダプターと独立した独自のMAC アドレスを持っているため、仮想マシンはホスト間を移動することができ、同一のサブネットにおいて移行後にもネットワークコネクションを維持することが可能です。移行先のvSphere ホストは、RARP（Reverse ARP）パケットを物理ネットワークに送信し、スイッチのMAC アドレステーブルを更新します。移行は、クライアントから完全に透過的に行われます。また、SAN やNAS といった共有ストレージは、ディスク状態の移行を容易にします。
3. 仮想マシンの物理メモリ
仮想マシンの物理メモリは、移行するコンポーネントの中で大きな要素となり、メモリ移行の効率性は、vMotion のパフォーマンスにおいて、最も重要な部分となります。仮想マシンのメモリ状態は3つのフェーズを経由します。
Phase 1: ゲストトレースフェーズ
このフェーズから移行が開始されます。トレースは移行中にゲストによって実施される変更をトラックするため、ゲストのメモリページで実行されます。メモリトレースは短時間ながら顕著なワークロードスループットの低下を引き起こす可能性があります。このインパクトは、ゲストメモリサイズに比例します。
Phase 2: プリコピーフェーズ
仮想マシンのメモリは、反復したプロセスで移行元から移行先ホストにコピーされます。プロセスの最初にメモリ全部をコピーし、続くプロセスでは、前回のコピーから修正された部分のみをコピーします。コピーされるメモリページの数は、移行中のゲストOSにより、vSphereホスト上で変更されるメモリに依存します。
Phase 3: スイッチオーバフェーズ
最後のフェーズにおいて、移行元vSphere ホストは瞬間的に静止し、最後のメモリ変更が移行先にコピーされ、仮想マシンは移行先のvSphere ホストで再開します。ゲストはこのステップ中に短時間停止します。 このフェーズ間隔は一般的に1秒未満ですが、ゲストのパフォーマンスインパクト（一時的な遅延の増加）が一番大きなフェーズとなります。影響はネットワーク、共有ストレージ、ホストハードウェア、vSphere のバージョン、ゲストのワークロードといった複数の要素に依存します。
vSphere 5.0 の機能拡張
1. 複数のネットワークアダプタの使用
vSphere 5.0 では、vMotion に複数のネットワークアダプタを使用する、マルチネットワークアダプタ機能が追加されています。後のセクションでご紹介するテストの結果から分かるように、移行時間を大幅に削減することが可能です。1台の仮想マシンのvMotion の際も、VMkernel はvMotion トラフィックを全ての有効なネットワークアダプタにロードバランスします。
2. Metro vMotion
vSphere 5.0 は、遅延に対応したメトロvMotion 機能を提供します。vMotion ネットワークの遅延の制限を10msec に増加させます。遅延に関しては下記KBも合わせてご参照ください。
High latency vMotion networks (2008096)
3. SDPS （Stun During Page Send）
vSphere 5.0 では、プリコピーフェーズにおけるメモリコピーの収束問題によりvMotion が失敗することがなくなりました。vSphere 4.1 以前のバージョンでは、仮想マシンが、vMotion によるプリコピーより早いペースでメモリを修正してしまうような高負荷環境で、vMotion が失敗するケースがありました。vSphere 5.0 の機能拡張では、仮想マシンをスローダウンし、メモリ修正レートをプリコピーの転送レートより遅くして、結果としてvMotion の失敗を防ぎます。
4. その他改善
・メモリトレースのインパクト改善
・vMotion 後に通常のパフォーマンスに戻るまでの時間の改善
・10GbE 帯域を効果的に使用する改善
パフォーマンス評価
vMotion のパフォーマンスを計測するにあたり、ウェブサーバ、メールサーバ、データベースサーバを含む、重要なTier1 アプリケーションの大きなドメインと、大規模デスクトップ仮想マシンの移行を必要とするVDI シナリオを考慮しています。下記それぞれケースについて、解説をしていきます。
1. ウェブ環境におけるvMotion パフォーマンス
2. メール環境におけるvMotion パフォーマンス
3. データベース環境におけるvMotion パフォーマンス
4. VDI/Cloud 環境におけるvMotion パフォーマンス
図1. テスト環境の構成
図1にテスト環境の構成を示します。詳細な試験環境の構成については、テクニカルホワイトペーパーを参照ください。
1. ウェブ環境におけるvMotion パフォーマンス
このセクションでは、ウェブアプリケーションサーバのパフォーマンスへの、vMotion の影響について検証しています。試験では、vMotion 中にサービス品質要件を満たしているユーザセッションの数に焦点を当てており、SLA を保証するクラウド環境へのWeb アプリケーション実装を検討しているお客様の手助けになるものです。
試験には、SPEC（Standard Performance Evaluation Corporation）によって規定される、業界標準のWeb サーバワークロードであるSPECweb2005 を使用します。詳細な試験環境の構成については、テクニカルホワイトペーパーを参照ください。
試験では専用の10GbE ネットワークアダプタをvMotion トラフィックに使用しています。図2の試験結果は、vMotion 実行時間がvShpere 4.1 に比べて、vSphere 5.0 では37%の削減があり、vMotion のパフォーマンス改善があることを示しています。10GbE の帯域を効率的に最大限使用するvSphere 5.0 の機能拡張により最適化されています
図2. vMotion 移行時間 （vSphere 4.1, vSphere 5.0）
図3のグラフでは、vSphere 4.1 環境でQoS（TIME_GOOD）を満たすSPECweb2005 のユーザセッション数をプロットしています。vMotion 実行中に顕著な2カ所のパフォーマンスの影響が表れています。最初の凹みはゲストトレースフェーズで発生し、2番目の凹みはソースホスト上の仮想マシンが瞬間的に静止し、移行先ホスト上で再開するスイッチオーバフェーズで発生しています。この2つの凹みにも関わらず、ネットワークコネクションのドロップ、タイムアウトは発生せずにSPECweb2005 のベンチマークは継続して動作しました。
図3. vMotion 移行時のWeb サーバのパフォーマンス（vSphere 4.1）
図4のグラフでは、vSphere 5.0 環境でQoS（TIME_GOOD）を満たすSPECweb2005 のユーザセッション数をプロットしています。vSphere 5.0 の機能拡張で、メモリトレースの影響を最小化しているため、ゲストトレースフェーズの凹みは小さくなり、スイッチオーバフェーズでのみ顕著な凹みが確認できます。このような高負荷にもかかわらず、スイッチオーバフェーズでゲストが静止する時間は約1秒となり、移行後に通常レベルのパフォーマンスに戻るまでは5秒未満となります。
図4. vMotion 移行時のWeb サーバのパフォーマンス（vSphere 5.0）
vSphere 4.1 とvSphere 5.0 を比べたとき、vMotion 移行時間と移行中のゲストパフォーマンスに、大きな改善があることが確認できます。
次のWeb 環境における試験では、10GbE ネットワークと1GbE ネットワークを使用した際のパフォーマンスを、それぞれvSphere4.1 とvSphere 5.0 で比較しています。試験は、表1に記載された異なる負荷の3つの仮想マシン（アイドル状態、平均的な負荷、高負荷）でそれぞれで実施しています。
表1. テストシナリオ（vSphere 4.1, vSphere 5.0）
図5 の試験結果は、10GbE ネットワークをvMotion に使用した際のメリットを明確に表しています。vMotion 実行時間は、1GbE に比べ大幅に短くなっています。各テストシナリオについて、個別に説明を行います。
図5. 10GbE と1GbE ネットワークでのvMotion 移行時間（vSphere 4.1, vSphere 5.0）
アイドル状態の仮想マシン：仮想マシンがアイドル状態（CPU アクティビティなし）になっていますが、メモリは完全にtouch された状態（ゼロページではない）のシナリオです。
補足：vSphere はゼロページのデータ移行を最適化するため、このシナリオでは110秒かかっている1GbE を使用したケースでも、メモリがtouch された状態でないブート直後の仮想マシンの移行時間は9秒以下となります
平均的な負荷の仮想マシン：仮想マシンのCPU 使用率は、140%（esxtop %USED）となり、クライアントからのネットワークトラフィックは、2.5Gbps 程度ある状態です。10GbE ネットワークを使用したとき、vSphere 4.1, vSphere 5.0 両方で移行時間は大幅に短縮され、vSphere 5.0 の移行時間はvSphere 4.1 より若干短縮されています。
高負荷の仮想マシン：仮想マシンのCPU 使用率は、325%（esxtop %USED）で、クライアントからのネットワークトラフィックは、6Gbps 程度ある状態です。2つ目のシナリオと同様に、10GbE ネットワークを使用したとき、移行時間は大幅に短縮されています。
vSphere 4.1 で1GbE ネットワークのvMotion 移行中には、高い遅延が発生し、ネットワークコネクションのドロップがあったため、vSphere 4.1 のグラフをグレーで表示しています。VMkernel のログから、仮想マシンが1GbE ネットワークで転送するよりも早くメモリの修正を行うメモリアクセスパターンが確認できます。vSphere 5.0 では、SDPS（Stun During Page Send）がプリコピー失敗時に機能し、vMotion の進行をスムーズにするため、vMotion 中のコネクションドロップはありませんでした。
vSphere 5.0 のvMotion 機能強化により、高負荷の仮想マシンを実行したときや、ネットワーク帯域に制限があるときにも、クライアントのサービス影響は最小化されます。
2. メール環境におけるvMotion パフォーマンス
メールは組織において重要なコミュニケーションツールであり、IT部門はメールシステムをミッションクリティカルなアプリケーションと見なしています。このセクションの試験では、ワールドワイドのビジネス環境で広範囲に使用されているMicrosoft Exchage Server 2010 をvMotion の影響調査で使用します。
パフォーマンスの測定には、Exchange サーバの公式なパフォーマンス測定ツールである、MS Exchange Load Generator 2010（LoadGen）を使用します。詳細な試験環境の構成については、テクニカルホワイトペーパーを参照ください。
試験は、下記2つのシナリオで実施します。
シナリオ1: vMotion を1台のメールボックスサーバ（4000のヘビーユーザが使用）仮想マシンで実施する
シナリオ2: vMotion を2台のメールボックスサーバ（8000のヘビーユーザが使用）仮想マシンで実施する
図6は、Exchange サーバのvMotion にかかる時間をvSphere 4.1 とvSphere 5.0 で比較しています。移行元と移行先のホストは、1本の10GbE ポートで構成されています。
図6. vMotion 移行時間（vSphere 4.1, vSphere 5.0）
シナリオ1でvMotion の移行時間は、vSphere 4.1 では71秒となるのに対し、vSphere 5.0 では47秒となり、33%短くなっています。シナリオ2でも同様、vSphere 5.0 を使用した場合トータルの移行時間は34%短くなります。
表2は、シナリオ1においてvSphere 4.1 とvSphere 5.0 のアプリケーションに対する影響を比較したものです。
表2. vMotion 移行時のゲストへの影響（vSphere 4.1, vSphere 5.0）
この表は、vMotion 実行中にLoadGen で確認された、最大のキューレングスを示しています。キューレングスは、Exchage 環境のユーザエクスペリエンスとSLA を調査するための一般的なメトリックとして使用されるもので、キューの中のタスクの数は、Exchage サーバが迅速なタスクのディスパッチに失敗したときに増えていきます。vSphere 5.0 は219で、vSphere 4.1 の294より小さな値となっており、ユーザはvSphere 5.0 環境においてより良いレスポンスを得ることが確認できます。
移行中にTask Exception はカウントされていません。これは、vSphere 4.1 及びvSphere 5.0両方の環境において、vMotion 移行中にドロップしたExchenge サーバのタスクはないことを意味します。
このテスト結果は、大きなメモリを使用したEmail アプリケーション環境で、vMotion の影響が最小化されていることを示しています。
3. データベース環境におけるvMotion パフォーマンス
データベースのワークロードは、CPU、メモリ、ストレージといったリソースを極端に消費することから、vMotion パフォーマンス測定において重要な指標となります。このセクションでは、MS SQL サーバのOLTP パフォーマンスに対するvMotion の影響を調査しています。
ベンチマークツールとしては、オープンソースのDVD Store Version2 （DS2）を使用しています。DS2 は、顧客がログインし、製品をブラウズするといった、オンラインのeコマースDVDストアをシミュレートします。詳細な試験環境の構成については、テクニカルホワイトペーパーを参照ください。
試験は、下記2つのシナリオで実施します。
シナリオ1: 1台の仮想マシンによるシングルインスタンスSQL サーバ
シナリオ2: 2台の仮想マシンによるマルチインスタンスSQL サーバ
図7は、シナリオ1とシナリオ2での、vMotion の移行時間を表しています。この結果は、vSphere 5.0 を使用した際にトータルの移行時間を削減することを示します。また、シナリオ1（1台の仮想マシン）の移行時間において、2つのネットワークアダプタを使用したケースで移行時間が短縮されていることから、単一の仮想マシンがvMotion を実行する際でも、複数のネットワークアダプタが透過的にvMotion トラフィックをロードバランスすることが分かります。
vSphere 5.0 で追加された複数のネットワークアダプタをvMotion で使用する機能は、単一及び複数の仮想マシン移行において、トータルの移行時間をダイナミックに削減します。
図7. vMotion 移行時間（vSphere 4.1, vSphere 5.0）
図8は、vSphere 4.1 環境でベンチマーク中のSQL サーバの秒毎のオーダプロセスをプロットしており、2つの顕著な凹みが確認できます。最初の凹みは、ゲストトレースフェーズで発生し、2つ目の凹みはスイッチオーバフェーズで発生しています。スイッチオーバフェーズの間隔は1秒未満となり、通常のパフォーマンス再開までに必要な時間は、スイッチオーバステージの後9秒程度となります。かなりの負荷を処理している時であっても、全体的なパフォーマンス影響は深刻なものではありません。
図8. SQLサーバへの影響（vSphere 4.1）
図9は、vSphere 5.0 環境でベンチマーク中のSQL サーバの秒毎のオーダプロセスをプロットしており、1つの顕著な凹みが確認できます。vSphere 4.1 環境で確認されたゲストトレースフェーズの凹みは、vSphere5.0 でのメモリトレース影響の最小化により、小さなものになっています。アプリケーションのスループットが0になるスイッチオーバの間隔は0.5秒未満となり、通常のパフォーマンス再開までの時間は約7秒となります。
図9. SQL サーバへの影響（vSphere 5.0）
vSphere 5.0 は、vSphere 4.1 と比べたときに、vMotion 移行時間と、vMotion 中のゲストパフォーマンス影響に改善があります。これらのテスト結果は、vMotion のパフォーマンス影響は、大きなリソースを必要とするDB アプリケーション環境でも最小化されることを示しています。
4. VDI/Cloud 環境におけるvMotion パフォーマンス
VDI/Cloud 環境では、1台のホストに数百の小〜中サイズの仮想マシンが統合されるという点で、良く似た特徴を持っています。これらの環境の管理には、ダウンタイムのないメンテナンスや、トラブルシューティングといった観点で、vMotion を使用するメリットがあります。
VDI/Cloud 環境においてサービス影響時間を最小化するために、仮想マシンの移行時間はとても重要な指標になります。そのため、このセクションでの試験は、トータルの移行時間に焦点をあてています。試験は64台のデスクトップ仮想マシンを持つVMware View 環境で、ベンチマークツールとしてVMware View Planner2.0 を使用し実施しています。詳細な試験環境の構成については、テクニカルホワイトペーパーを参照ください。
図10は、移行テストの結果をサマライズしています。移行元と移行先ホストは、1つの10GbE ポートで構成されています。vSphere 5.0 では、移行元と移行先ホストでvMotion 用に2つの10GbE ポートを構成したケースもテストしました。
図10. VDI 環境での仮想マシン移行シナリオ（vSphere 4.1, vSphere 5.0）
この結果から、vSphere 4.1 と比べたときに、トータルの移行時間がvSphere 5.0 で大きく削減されていることが分かります（vSphere 4.1: 11分, vSphere 5.0: 2分）。
2つの10GbE アダプタを使用した際の改善は、このテストシナリオではわずかなものとなっています。これは、複数のエージェントが動作するvCenter サーバと、移行元、移行先のvSphere ホスト間のマネジメントレイヤの遅延が、帯域使用率を制限しているためです。この遅延のインパクトは、テストシナリオのように小さな仮想マシンだけで構成されたシナリオではより顕著になります。
図11. 移行シナリオにおけるネットワーク使用帯域（vSphere 4.1）
図11は、64台の仮想マシンの移行シナリオの間に、vMotion によって使用されるネットワーク帯域を示しています。vSphere 4.1 では、すでのホストあたり同時8台までの移行がサポートされており、結果として8個の分離したフェーズができています。それずれのフェーズで8台平行した仮想マシンの移行があり、ピーク時の帯域は8Gbps 近くになりますが、フェーズ間のネットワーク帯域の使用率は、vCenter 上で実行される複数のエージェント、移行元、移行先ホスト間のマネジメントレイヤの同期遅延によりidle としてマークされます。結果、仮想マシンあたりの平均移行時間は6秒であるのに、トータルの移行時間は11分になります。
図12. 移行シナリオにおけるネットワーク使用帯域（vSphere 5.0）
図12は、vSphere 5.0 でネットワーク帯域を効率的に活用する改善を示しています。vSphere5.1 と比べ、顕著なフェーズがなく、ピーク時のネットワーク使用率は、9Gbpsとなります。結果としてトータルの移行時間は2分に短縮されます。
vMotion ベストプラクティス
1. 10GbE ネットワーク
1GbE ネットワークの代わりに10GbE ネットワークを使用することで、vMotion のパフォーマンスは大きく改善されます。特に大きな仮想マシン（64GB以上）を使用する時は、複数の10GbE ネットワークアダプタを使用することで、さらにvMotion のパフォーマンスは改善されます。
2. CPU キャパシティ
ホストレベルでリソースプールを使用する際は、ホストのCPUキャパシティを全てコミットせず、少なくともvMotion のために30%の予約されないCPUを残します。vMotion を開始するとき、VMkernel は便宜的にCPUリソースを予約しようと試みますが、確保が失敗するとvMotion は進行しても、パフォーマンスに大きな影響があります。同様にリソースプールをDRS で使用するとき、クラスタレベルでは少なくとも10%のCPU キャパシティを予約しないことを計画します。クラスタ内の全てのCPU キャパシティを予約することは、ホスト間のDRS 移行に支障がでます。
3. スワップファイル
vSphere 5.0 及び以前のリリースでは、スワップファイルの保存領域にローカルのデータストアの指定が可能となりましたが、スワップファイルをローカルデータストアに保存することで、vMotion のパフォーマンスに影響がでることがあります。移行にかかる時間に懸念がある場合、仮想マシンのスワップファイルはSAN かNAS といった共有ストレージに保存してください。
4. 複数のネットワークアダプタの使用
vMotion 用に複数のネットワークアダプタを使用する場合、全てのvMotion vmnic を1つのvSwitch 配下に設定し、1つのvMotion vmknic をそれぞれのvmnic に作成してください。vmknic のプロパティで、それぞれのvmknic が異なるvmnic をアクティブで使用し、残りをスタンバイとして設定します。この方法では、もし1つのvmnic が切り離されたとき、vMotion は透過的にスタンバイのvmnic にフェイルオーバします。全てのvmnic が機能している時は、それぞれのvmknic はアサインされた専用のvmnic にトラフィックを転送します。
5. NIOC （Network I/O Control）
複数のトラフィックを同じネットワークアダプタでシェアする必要がある時は、NIOC を使用してください。NIOC については、下記テクニカルホワイトペーパーも合わせてご参照ください。
VMware® Network I/O Control: Architecture, Performance and Best Practices
6. NUMA
ESXi 5.0 では、ESXi ホストのNUMA 構成をゲストOS に公開します。この機能を使用する際は、仮想マシンを同じNUMA アーキテクチャを持ったホストで構成されたクラスタ間に適用してください。これは、最初にvNUMA を有効にされたマシンがパワーオンされた際に、仮想マシンが動作している物理ホストに対応したNUMA トポロジーがセットされるためです。異なるトポロジのホスト間をvMotion で移行した際には、その仮想マシンのvNUMA トポロジは物理NUMA トポロジに最適化されずに、潜在的にパフォーマンスの低下を引き起こします。
結論
VMware vSphere vMotion はvSphere の最も有名な機能の1つで、仮想データセンターの管理に大きな利益をもたらします。アプリケーションの可用性と応答性においてユーザが認知するインパクトなしに、リソースのロードバランスを可能にし、ダウンタイムを防ぎ、トラブルシュートに柔軟性を提供します。
vSphere 5.0 は、vMotion の機能拡張と新機能を紹介していて、その中には複数のネットワークアダプタの使用や、10GbE 帯域の有効活用や、Metro vMotion や、移行中のアプリケーションパフォーマンスへのインパクト削減があります。vSphere 4.1 環境と比較し、vSphere 5.0 の環境でのvMotion パフォーマンスを定量化するために、4つの環境（ウェブ、メール、データベース、VDI/Cloud）で試験を実施しています。結果として、vSphere 5.0 ではvSphere 4.1 に対し、vMotion 移行時間とアプリケーションのパフォーマンスへのインパクトの点で、大きな改善があることが確認できました。
ここまで、vSphere 5.0 でのvMotion のパフォーマンス改善について解説を行ってきました。最新のvSphere 5.1 では今回説明したvSphere 5.0 の機能拡張に加え、共有ストレージを必要としない拡張vMotion が可能になっています。次回は、vSphere 5.1 の拡張vMoiton ついてテクニカルホワイトペーパーを基にご紹介します。
