Microsoftのマーケティング部門は多くのエネルギーを費やして、Hyper-V 3.0でVMに割り当て可能なこの最大メモリ量を宣伝している。この量は米VMwareのVMware vSphere 5と肩を並べるものだ。しかし、実際の環境でこうした大量のメモリを割り当てることには注意が必要だ。私はIT分野に15年以上携わっているが、1TバイトのRAMが必要なWindowsワークロードというものは聞いたことがない。そうしたワークロードも存在するかもしれないが、最近では、コンピューティングの問題の大部分は、膨大なメモリを使う処理よりも、大規模並列処理によってより良く解決される傾向がある。

　実のところ、1Tバイトの仮想RAMを持つVMを作成すると、ロードバランシングや高可用性を実現する上でネックになりかねない。

大量の仮想RAM割り当てはトラブルの原因にもなる

　何よりもまず、IT担当者が大規模なVMを移動するのは容易なことではない。ライブマイグレーションでは、大規模なVMを扱える強力なホストが少なくとも2台必要だが、それらを用意するには過大なコストを要するだろう。さらに、VMに適切な可用性を持たせるには、ホストのクラスタが必要だ。

　大規模なVMは、ハードウェア上の問題を招くだけではない。クラスタ内に大規模なVMがあると、ロードバランシングの妨げになる可能性がある。

　この問題を理解するため、1台の大規模なVMを含む数台のVMが稼働する4台のホストから成るクラスタを考えてみよう。ワークロードは、3台のホストの物理リソースをほぼ消費し、もう1台のホストが障害に備えて待機しているとする。この場合、大規模なVMは、クラスタ内のリソースの最適化を阻害する恐れがある。

　各VMのリソース使用量は常に変動するため、ホストは活発にロードバランシングを行う必要がある。1Tバイトの仮想RAMを持つVMをロードバランシングのためにホスト間で移行するには、移行先ホストから他のVMを移行し、空きリソースを確保しておく必要があるかもしれない。このプロセスにより、クラスタ内の負荷がさらにアンバランスになり、ホスト間でのVMの移行が、負荷が安定するまで連鎖的に行われる可能性がある。

　また、クラスタ内のホストの1台が停止した場合、大規模なVMは高可用性機能に悪影響を与えることがある。ノードの停止を認識したら、クラスタ内の他のメンバーは、そのホスト上のVMを最適に再配分する方法を直ちに決定しなければならない。だが、大規模なVMがあると、そのプロセスにそれだけ多くの時間や労力が掛かる。あるいは、サービスを早急に復旧させるために、最適ではない結果を招く（例えば、リソースを大量に消費するVMが、リソースの潤沢な供給を受けられないホストに配置されるなど）こともある。

ハイパーバイザー戦争の一局面

　MicrosoftとVMwareは激しいハイパーバイザー戦争を繰り広げてきたが、両社とも、多くの機能を追加、更新、強化した最新版ハイパーバイザーの投入により、優位に立とうとしているようだ。

　大規模なVMが問題を引き起こす恐れがあるのは、Hyper-Vだけに限らない。VMwareは先頃リリースしたvSphere 5で、VMに割り当て可能な仮想RAMを増やしており、これを受けてIT管理者は、Hyper-V 3.0の場合と同様の問題を警戒している。米Citrix SystemsのXenServerでも、VMに割り当て可能な仮想RAMが増えており、やはり同様の警戒を呼び起こしている。

　結局のところ、VMに割り当て可能な最大メモリ量の増加は、盛んに宣伝されているものの、ベンダー各社のメンツへのこだわりでしかないように見える。自分が選択したハイパーバイザーで、VMに1Tバイトのメモリが割り当て可能でも、VMのワークロードは適切にサイジングしなければならない。さもないと、仮想インフラのパフォーマンスを最適化することはできないだろう。