vMotion introduced - VirtualCenter 1.0 - 2003

VirtualCenter 1.0.1 Release Notes

かなり古のバージョンになりますが、2003 年に vMotion が初めて登場したそうです。この頃はまだ vCPU の最大数も 2 vCPU と少なかったのですが、Intel の CPU は CPU で Prestonia や Gallatin といった NetBurst アーキテクチャでコア数も少なかったので、基本的には低負荷サーバーの集約が主だったのではないかと思います。

RDM support - VirtualCenter 1.2 - 2004

VirtualCenter 1.2 Release Notes

ここで Raw Disk Mapping (RDM) を使った仮想マシンの vMotion がサポートされます。RDM は mapping ファイルで LUN を指定することや物理 RDM (pRDM)、仮想 RDM (vRDM…は余り使われないかな) もあるので対応に時間が掛かったのだと思われます。

私にとって、VirtualCenter 1.2 と ESX 2.5 の組み合わせが初めての VMware との邂逅でした。そして HP BL40p + EVA の組み合わせで vMotion したのが、初 vMotion。また、要件にあった 1TB の VMDK ファイルを作りたくないのと、バックアップ方法が禄に思いつかなかったので、RDM も組み合わせたのも初めてでした。

数年後、病的に RDM が蔓延しバックアップ、仮想マシンの増設、拡張の運用が回らなくなった現場を散見し、頭抱えて絶望することになろうとは…。苦渋の決断で選択するものですよ、RDM。

Distributed Resource Scheduler (DRS) - VirtualCenter 2.0 - 2006

VMware Infrastructure 3 Release Notes - ESX Server 3.0, VirtualCenter 2.0

実は VirtualCenter 2.0 / ESX 3.0 の時代は VMware 製品に関わっていなかったのですが、DRS は 2006 年に登場したとのこと。

DRS によって、負荷の髙い物理サーバーから負荷の低い物理サーバーへ仮想マシンが vMotion で移動されます。これを繰り返すことによって物理サーバーの負荷が平準化され、各物理サーバーの負荷の見極めが行いやすくなります。例えば、DRS を利用せず物理サーバーの負荷が 60 % だったとすると、残りの余裕は 40 % になります。クラスタ内に他の物理サーバーがあっても自動的に移動できないので他の物理サーバーの余裕を合算して考えることが出来ません。そのため、物理サーバー毎にキャパシティ管理を行うことになり、物理サーバーが増えれば増えるほど、仮想マシンが増えれば増えるほど、運用者が考慮しなければならない変数が増えていってしまいます。

一方、5 台のクラスタで DRS を利用し、同じように単体の物理サーバーの負荷が 60 % だったとします。さて残りの余裕は？と考えたとき、DRS は仮想マシンをよしなに vMotion してくれるので、残りの余裕は 40% ではなく、5 台分の 40% をかき集めた 200% が残りの余裕と考えることが出来ます。こちらの例では、キャパシティ管理を物理サーバー単位ではなく、クラスタ単位で行うことが出来、キャパシティ管理のための変数が激減します。そして 200% も余っているのであれば、最初の単体サーバーの負荷は 70% でも良いのではないか？80% でもよいのではないかとなり、結果物理サーバーの台数が減り、ソフトウェアライセンスコストが減り、電気代、空調、ラックスペースも減り CAPEX がみるみる減っていく効果を享受できるようになります。

仮想デスクトップ環境は 1 物理サーバーで 100+ 仮想マシンを稼働させ、かつ、それぞれの仮想マシンの負荷の合計はまず読めないので、まず DRS は必須になるでしょう。いや、サーバー仮想化の環境であっても必須だと思いますよ、ほんとに。

一部ソフトウェアのライセンスは DRS というよりは vMotion が仇になります。すでに vCenter Server 跨ぎの vMotion が可能になり、さらにはクラウドに vMotion できる時代もそう遠くないので、その辺も踏まえるとソフトウェアの選択はライセンス形態というのも極めて重要な選択基準となりえるのだなーとしみじみ思います。OSS ならば !! という向きもあると思いますが、自力で保守・運用できるのであればともかく、保守・運用サービスを受ける場合はライセンス同様その料金プランを十全に把握している必要があるでしょう。

DRS を使いたいけども使えないんだ、という方が挙げる “できない理由” に「DRS で勝手に動かれると、物理サーバーの障害時の vSphere HA でどの仮想マシンが再起動したのか分からなくなる」というのがあります。これは、クラスタのイベントを見ると HA による再起動というイベントが仮想マシン毎に確認できます。これをもって影響を受けた仮想マシンのリストすることが出来きるのではないでしょうか。

Upgrade vMotion - VirtualCenter 2.0.1 - 2006

VirtualCenter 2.0.1 Release Notes

Release Notes でもあまりフォーカスして説明されていませんが、簡易版ながら vCenter Server 5.1 でサポートされる X-vMotion がこのバージョンで実装されています。ESX 2.[1,5].[2,3] / VMFS 2 上の仮想マシンを、ESX 3.0.1~ / VMFS 3 上へ vMotion して Virtual Infrastructure 環境をアップグレードすることがサポートされていました。もちろん仮想マシンは起動したままですので、物理サーバーの移動とデータストアの移動を同時にやってのけていたのです。

ここでは Storage vMotion の原型になる機能によって VMFS 2 から VMFS 3 へのデータコピーが行われています。

もっとも移行後には、仮想ハードウェアバージョンのアップグレードや VMware Tools のアップグレードを行うために再起動が必要になるため、手放しで喜べる機能ではありませんでした。しかし、再起動のタイミングは仮想マシン毎に決められるので、運用者としては全仮想マシン一斉再起動の調整よりは、アプリケーションサイドと調整は行いやすかったのではないかと思います。

移行元となる ESX 2.1.x、ESX 2.5.x のバージョンは KB で限定されているので注意が必要でした。

Migration Upgrade with VMotion Supports Upgrades Only from Specific Versions of ESX Server 2.x

Distributed Power Management (DPM) - VirtualCenter 2.5 - 2007

VMware Infrastructure 3 Release Notes - ESX Server 3.5, VirtualCenter 2.5

DPM は仮想マシンを物理サーバー群に集中し、仮想マシンがいなくなった物理サーバーの電源を停止させます。これによってインフラの消費電力を抑えることが出来ます。

これは結構悩ましい機能で、「あまり停止させているとそもそもその物理サーバーは買わなくて良かったんではないか？」とか「いざ必要になった時に電源を On にすると、そこそこの確率で障害が起きている」といった考えから積極的に使われているかというとそうでもなかったり…。

しかし、仮想デスクトップ環境では、昼間に対し夜間はほぼ無風となることから、夜間 DPM で物理サーバーを停止させるケースもあるようです。

これを DPM ではなく PowerCLI のスクリプトで Enter Maintenance Mode > PowerOff > PowerOn (iLO,iDRAC,IPMI) > Exit Maintenance Mode させる場合もあります。

Storage vMotion (CLI) - VirtualCenter 2.5 - 2007

VMware Infrastructure 3 Release Notes - ESX Server 3.5, VirtualCenter 2.5

これまでの vMotion は、仮想ディスク以外の仮想マシン (CPU、メモリ、NIC、HBA etc.) を動かしていましたが、Storage vMotion は仮想ディスクが格納されるデータストアを移動させる機能です。この頃はまだ、GUI が用意されておらず VI Remote CLI などの svmotion コマンドから実行しなければなりませんでした。

初期の頃の Storage vMotion の実行中には REDO log が生成されていました。つまり、Storage vMotion 中はデータストアの使用量が仮想マシンの挙動に応じて増えていました。。その昔 200 台近い P2V を実施するプロジェクトの最中、90% 近い使用量のデータストアの容量調整のため、DB を Export するバッチ処理中の仮想マシンを Storage vMotion してしまい、データストアフルの恐怖に怯えたのは良い思い出 🙁

DB の Export 処理はこのトラブルの翌日に聞いた…。古のセオリー DB Export と Hulft 転送のコンボでした Orz

Enhanced vMotion Compatibility (EVC) - VirtualCenter 2.5U2 - 2008

VMware Infrastructure 3 Release Notes

VirtualCenter 2.5U2 というタイミングで実装されていたのを忘れていました…Orz

2016/10/1 追記

EVC はクラスタ内の物理ホストがゲスト OS に見せる CPU の機能をマスクし、異なる世代の CPU が混ざった場合でも vMotion が円滑に行えるようにするための機能です。特に新しいハードウェア環境への移行時や、ハードウェア増強時で CPU の世代が新しくなった場合に威力を発揮します。EVC を有効にせずに、移行や増強を行うと…ｶﾞｸﾌﾞﾙ。

vMotion は起動中の仮想マシンを、ゲスト OS が起動したまま物理ホスト A から物理ホスト B に移動させます。このとき CPU の状態も一緒に移行するのですが、物理ホスト A と物理ホスト B の CPU 機能が一致していないと問題が起きます。例えば、物理ホスト A の CPU で SSE 4.2 がサポートされているにもかかわらず、物理ホスト B の CPU では SSE 4.2 がサポートされていないとします。この状態でもし vMotion してしまうと、ゲスト OS にとっては稼働中に CPU の命令セットやレジスタ構成が変わってしまうことになり非常に問題となります。

これを避けるために、クラスタ内に新旧入り乱れた世代の CPU を持つ物理ホスト群がある場合には、EVC で古い世代の CPU を設定します。つまり、新しい世代の CPU を搭載した物理ホストで仮想マシンが起動した場合でも、仮想マシンは古い世代の CPU 機能しか使いません。これにより、新しい世代の CPU を搭載した物理ホストで仮想マシンを起動しても、これは古い世代の CPU の機能しか使えないため、古い世代の CPU を搭載した物理ホストに vMotion することができます。

つまるところ…vSphere の環境を作成したら、問答無用で EVC の設定を有効にし、存在する最も古い世代の CPU を選択すべし、ということです。なお、EVC を設定しても、仮想マシンを停止して起動しないと CPU に対するマスクが機能しません。注意すべきはゲスト OS の再起動でもダメ、仮想マシンのリセットでもダメです。

詳細は以下の KB を参照してください。

次のエントリでは vCenter Server/vSphere とリブランドされた 4.x 世代の機能を見ていきます。

vMotion の歴史 (2) – VirtualCenter 1.0 ~ 2.5