Home > Blogs > Japan Cloud Infrastructure Blog > 月別アーカイブ: 2013年7月

月別アーカイブ: 2013年7月

VMware vSphere 5.X vMotion パフォーマンス

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 ついてテクニカルホワイトペーパーを基にご紹介します。

 

VMware ESXi イメージ管理ベストプラクティス その2

イメージプロファイルの操作

前回、その1でVMware ESXiのイメージをカスタマイズすることの意義や、イメージプロファイル等についてご説明致しました。
今回は、そのイメージプロファイルを操作する手法についてご説明します。

イメージプロファイルの操作にはImage Builderを使います。Image Builderは、vSphere PowerCLIで提供されるコマンドレットの1つで、以下の様な機能を提供します。

 ・既存のイメージプロファイルへのVIBの追加や削除
 ・イメージプロファイルの新規作成
 ・イメージプロファイルを指定したISOイメージ、オフラインバンドルのエクスポート

イメージプロファイルへのVIBの追加

追加作業にはImage Builderのコマンドレットを利用しますが、vSphere PowerCLIをご利用いただいている方であれば特にImage Builderを意識する必要はありません。例えば、既存のイメージプロファイルにダウンロードしてきたドライバ等のVIBを追加するための手順は以下の通りです。

 1. VIBの入手
VMware、サーバベンダー、デバイスベンダー、アプリケーション(vCD/vShieldManager)等からオフラインバンドルに含まれる形で提供
 2. ベースとなるイメージプロファイルとVIBをImage Builderに登録
3. 既存のイメージプロファイルにVIBを追加
4. オフラインバンドルやISOとして書き出す

具体的に、手順2以降は、

2-1. vSphere Power CLIを起動して、VIBを含むオフラインバンドルをImage Builderに登録

 > Add-EsxSoftwareDepot c:\filepath\xxxx-offline_bundle-xxxx.zip

2-2. VIBに定義された名前を確認

 > Get-EsxSoftwarePackage

※Nameの欄に記述されています、この例では、”net-ixgbe” です。

2-3. ベースとなるイメージプロファイルを含むオフラインバンドルをImage Builderに登録

 > Add-EsxSoftwareDepot c:\filepath\VMware-ESXi-5.1.0-xxxxxx-depot.zip
 > $ip = Get-EsxImageProfile

※イメージプロファイルを操作するため、変数に代入しておく。


※イメ-ジプロファイルは通常複数(vmware-toolsを含む物、含まない物の二つ)存在します。上記例では、

 $ip[0]・・・no-tools
 $ip[1]・・・standard (vmware-tools込みのイメージプロファイル)

です。どちらかを選択してVIBを追加することになります。

3-1. 既存のイメージプロファイルを指定して、新しいイメージプロファイルをクローンにて作成

 > New-EsxImageProfile -CloneProfile ($ip[0] or $ip[1]) -Name (New_Profile_name) -v (Vendor_Name)

3-2. 新プロファイル名を指定してVIBを追加

 > Add-EsxSoftwarePackage -ImageProfile (New_Profile_name) -SoftwarePackage (VIB-name)
※VIB-nameは、Get-EsxSoftwarePackageで調べた名前です。


※この例では、net-ixgbeを追加しています

4. 作成したイメージプロファイルを指定して、ISOファイルもしくはオフラインバンドルとしてエクスポート

  ISOファイルとしてエクスポート
    > Export-EsxImageProfile -ImageProfile (New_Profile_name) -ExportToIso -FilePath (Filename)

  オフラインバンドルとしてエクスポート
    > Export-EsxImageProfile -ImageProfile (New_Profile_name) -ExportToBundle -FilePath (Filename)

エクスポートしたISOファイル、オフラインバンドルには追加したVIBが含まれており、ダウンロードした物同様、AutoDeploy起動用のイメージやESXiのインストーラーとして利用することが可能です。

イメージ同士の結合

上記の応用編となりますが、複数のESXiイメージから新しいVIBのみを抽出して新しいイメージプロファイルを作成することも可能です。
この知識は、OEMカスタムイメージを利用している方に、特に有用です。

例えば、青い波線のイメージを作成する際、VMwareのパッチに含まれる最新のvmkernelやvmware-toolsのVIBと、旧OEMカスタムイメージに含まれるより新しいデバイスドライバやCIMプロバイダ等でイメージプロファイルを作成する事が可能です。

この場合は、以下のように行います。

・利用する複数のESXiのイメージプロファイルをImage Builderに登録

 > Add-EsxSoftwareDepot C:\filepath\VMware-ESXi-5.1.0-xxxxxx-depot.zip.zip
 > Add-EsxSoftwareDepot C:\filepath\VMware-ESXi-5.1.0-yyyyyy-depot.zip.zip

・新しいイメージプロファイルを選択して変数へ代入

 > $sp = Get-EsxSoftwarePackage -newest

・$spを指定してイメージプロファイルを新規作成

 > New-EsxImageProfile -NewProfile -SoftwarePackage $sp -Vendor -AcceptanceLevel

あとは、上記4.同様、ISOやオフラインバンドルとしてエクスポートが可能です。

まとめ

今回は、ESXiイメージ管理に関するベストプラクティスについてご紹介いたしました。
この知識を活用することにより、以下のことが可能となります。

 ・最新のドライバを含んだインストールイメージの作成が可能
・ESXi導入時間や障害時のリカバリ時間の短縮
・ドライバが無いことによるインストールの不具合を解消
・Auto Deploy環境におけるイメージ作成・管理が可能

是非ご利用下さい!

ネットワーク仮想化 設計ガイドのレビュー その2

VMware の 仮想ネットワークの最大のポイントは、一定の要件を満たせば既存のネットワーク上に実装することが可能な点です。既存のネットワークにどのような要件が必要か確認していきます。VXLAN そのものの解説については、こちらをご参照ください。

今回は、下図のような物理ネットワークに VXLAN を実装する場合を見ていきます。
この物理ネットワークは、コアスイッチ、リンクを束ねる役割のアグリゲーションスイッチ、ホストを接続する為のアクセススイッチからなる3階層の構成になっています。VXLAN を実装する4台のホストは、1つの L2 セグメント(VLAN 100) に接続されています。
この一般的な物理ネットワークのスイッチにどのような機能要件が必要か確認します。

スイッチの機能要件
1.MTU サイズが変更できること。
2.IGMP Snooping が使用できること。
3.IGMP クエリア が使用できること。

スイッチの機能要件で最も重要なのが、MTU サイズが変更できることになります。
通常の Ethernet フレームに VXLAN ヘッダが加算されるため、スイッチのポートでは、1550 bytes 以上 または、ジャンボフレームを設定します。VXLAN上で、IPv6 を利用する場合には、1600 bytes 以上にします。
VMware の VXLAN の実装では、DF bit が 1 にセットされており、VXLAN が IPフラグメンテーション(分断)されません。通常の Ethernet フレームの MTU サイズは、1500 bytes のため、MTU サイズを変更せずに VXLAN を流してもドロップされてしまいます。

<アクセススイッチ設定サンプル>
#MTU configuration
Switch-Router1# interface gigabitEthernet 1/1
Switch-Router1 (config-if)# mtu 1550
Switch-Router1 (config-if)# end

このようにホストが接続される物理スイッチの各ポートに MTU サイズの設定を行います。

<アクセススイッチ設定サンプル>
#IGMP snooping configuration
Switch-Router1 (config)# ip igmp snooping
Switch-Router1 (config)# end

初期状態で有効になっている場合がありますが、IGMP snooping の設定も必要です。

<アグリゲーションスイッチ設定サンプル>
#IGMP querier configuration
Switch-Router1# interface vlan 100
Switch-Router1 (config-if)# ip igmp snooping querier
Switch-Router1 (config-if)# end

この物理ネットワーク構成の場合は、アグリケーションスイッチが L2 と L3 の境界になっていますので
このスイッチの VLAN Interface に対して、IGMP クエリアの設定が必要になります。
この設定が必要な理由は以降で紹介しておりますが、少々難しい内容になってしまいますので、必要な方は参考にして頂ければと思います。

物理ネットワークのスイッチに必要な機能要件は以上になります。VMware のネットワーク仮想化は、それを実現する為に既存のネットワーク機器を買い替える事無く、その恩恵を得ることが可能となります。

今回は、VXLAN を構成する複数のホストが1つの L2 セグメントに存在するケースを見ていきました。
次回は VXLAN を構成するホストが、サブネットを跨いで存在する場合を見ていきます。

ここからは、IGMP Snooping と IGMP クエリアの機能が必要な理由を解説します。
VMware の VXLAN の実装では、VXLAN 上の未知の宛先に通信する場合にマルチキャストを利用します。
マルチキャスト !? とネットワークに詳しい方が聞くと PIM (Protocol Independent Multicast) を想像される方が多いかと思いますが、この例のように1つの L2 セグメントにホストが接続されている場合は不要です。

IGMP Snooping は、マルチキャストフレームを必要な物理ポートのみに転送するための物理スイッチの機能です。
IGMP クエリアは、マルチキャストフレームを利用する際に必要なマルチキャストルータの機能を L2 スイッチが代行する機能です。
IGMP Snooping が有効な L2 スイッチは、IGMP のやり取りがないと、マルチキャストフレームを転送する必要がないポートと判断し止めてしまいます。(注1)

注1)IGMP のやり取りが無いとは、「IGMP Query や Reportのやり取りがなく マルチキャストを転送する為のテーブルから情報が消えてしまう」という意味です。

この物理ネットワークのように、1つの L2 セグメント内(VLAN 100)で VXLAN を利用する場合は、IGMP Query を出す
マルチキャストルータが存在しないことになり、VTEP ( Virtual Tunnel EndPoint ) は、Report を返すことができません。その結果、注1の理由より、VTEP へのマルチキャストフレーム転送が止まってしまいます。
IGMP クエリアを設定することで、スイッチが代行して、IGMP Query を出すようになり、VTEP も定期的に IGMP Report を返すようになりますので、マルチキャストを転送する為のテーブルから情報がなくなることを防ぐことができます。

IGMP Snooping は スイッチの初期状態で有効になっている場合があり、VXLAN がうまく動かない原因になる可能性がありますので、忘れずに IGMP クエリアの設定をしましょう。

物理スイッチの設定方法や VXLAN の設定方法をさらに詳しく知りたい方は、VMware® VXLAN Deployment Guide をご参照ください。

VMware ESXi イメージ管理ベストプラクティス その1

ESXi 5.xのイメージを管理する!

※この記事は、VMware ESXi 5.x、及び2013年6月時点の情報を前提に記載しています。
将来、変わる可能性がありますので、あらかじめご了承の上ご利用下さい。

まだ一般的にはあまり知られていないようですが、VMware ESXiは起動に必要なモジュール(VIB)を選択して起動(インストール)することが出来る、非常にユニークなHypervisorです。このユニークさが隠れたESXiの凄いところなのですが、この ”選択されるVIB” は必要に応じてカスタマイズすることが可能で、カスタマイズにより以下の様なメリットが得られます。

・最新のドライバを含んだインストールイメージの作成が可能

・ドライバが無いことによるインストールの不具合を解消
最新のサーバへの対応が容易

・ESXi導入時間や障害時のリカバリ時間の短縮
追加のパッチ当てやドライバのインストール作業が不要に

・Auto Deploy環境におけるイメージ作成・管理が可能
追加インストールが事実上不可能なステートレス環境ではこの知識が非常に役に立ちます

ここでは2回に分けて、最適なESXiのイメージ管理手法について具体的な例を挙げながらご説明します。

2種類あるESXi 5.xのイメージ
ESXiのイメージには、ISO、ZIPの2種類があり、以下のような特徴があります。

ISO
・CDに焼くことによりBootableとなり、ESXiのインストールが可能
・オフラインバンドルから作成することも可能

ZIP
・オフラインバンドルの1つであり、ESXi独自のユニークなバイナリ提供方法
・ESXiを起動・インストールするために必要な複数のVIBやイメージプロファイルなどで構成される
・様々なカスタマイズや、 ISOファイルへの書き出しが可能

ESXiのイメージ管理にはISOファイルではなく、ZIPファイル(オフラインバンドル)を利用します。

※オフラインバンドルはESXiイメージ全体の提供だけではなく、デバイスドライバやエージェント類の提供方法としても利用されています。
この場合は、単一のVIBかつイメージプロファイルを含まない形が主となっています。


※VMwareダウンロードサイトより

オフラインバンドルの主な構成要素
オフラインバンドルの構成要素は以下の通りです。

・VIB・・・VMware Infrastructure Bundle
ESXiの構成上必要なパーツで、以下のような物があります
・ESXiベースイメージ(ESXi Kernel)
・デバイスドライバ
・CIMプロバイダ

・イメージプロファイル
起動(インストール)に利用する複数のVIBを選択・定義した物
上記VIBの内、ここで定義された物が起動(インストール)時に読み込まれる
インストーラー(ISOファイル)を書き出す事が可能
カスタマイズが可能

VIB・イメージプロファイルの提供方法


1. vmkernelや一般的なデバイスドライバ等は、VMwareから提供されるオフラインバンドルの中に含まれます。
2. サーバ固有のCIMプロバイダや最新ドライバ等は、1.に追加する形で各OEMベンダー用のカスタムイメージとして
提供されます。
3. VMwareから定期的に提供されるパッチの構成は基本的には1.と同じで、インストールに必要な全てのモジュール
が含まれます。但し、2.は含まれません。
4. デバイスドライバで、元々1.に含まれない物や、Updateされた最新ドライバ類です。
5. VIBには、アプリケーションからESXiにプッシュインストールされる物もあります。
代表的な物が、vSphere HAを構成する際にvCenter ServerからインストールされるFDM Agentです。

必要に応じて、柔軟に青や赤の波線で囲った様なイメージを作成することが今回の目的です。

1.のイメージの中に必要なドライバが含まれているかどうかは、VMwareのCompatibilityGuideのサイトで確認が出来ます。

一例を挙げます。ここのTypeで、

inbox・・・含まれる
async・・・含まれない

事を示します。

次回、その2では、実際のカスタマイズの方法に関してご説明します。