virtualization.info 日本語

本シリーズでは前回、どの仮想化技術採用プロジェクトでも真っ先に行う、つまり仮想インフラに移行させるのに最適な物理サーバの選択について解説した。

前回は、どのサービスでも必ず仮想化できるわけではないことや、なかには特別な注意が必要なものがあることについて見てきた。また、その作業に役立つソリューションで入手可能なものもいくつか検討したが、仮想化市場はまだこの方面が弱いことを認識した。

仮想化するマシンが決まったら次の作業だ。それがこのプロジェクト全体で最も重要なフェーズだ。

キャパシティ・プラニング

キャパシティ・プラニングとはどのようなものだろう？また、プロジェクトのどのフェーズより細心の注意を要するのはなぜだろうか？

このフェーズでは、物理ホスト内部における仮想化した物理マシンの配置を評価し、プロセッサのタイプ、メモリ容量、大容量記憶装置のサイズとタイプ、予備マザーボードのアーキテクチャなど、リソースの必要量を決める。

これらのマシンは、計画された仮想マシンを問題なく格納し、プロジェクト要件に応じながら、同時にさまざまな深刻度の障害に耐え、容易にスケールアップできなくてはならない。

中程度の複雑性を持つプロジェクトで選ばれるハードウェアには、物理的なサーバだけでなく、最低1台のストレージ デバイス、内部接続デバイス、ネットワークカード、そしてケーブルが必要になる。

どの部品も慎重に選び、パフォーマンスのニーズだけで選んではならない。ここでの判断は、投資利益率（ROI）を計算してプロジェクトの価値の有無を判断する次のフェーズに影響していく。

ハードウェアのサイズで重要な値が、コアあたりの仮想マシン（VM／コア）比だ。

どの仮想プラットフォームにも、選んだハードウェアとは別に平均予想パフォーマンスレベルがある。これは、仮想マシンが処理しなくてはならない仮想化エンジン最適化から負荷まで、複数の要因の影響を受ける。また、シングルコア（非マルチコアプロセッサであればシングルCPU）が問題なくサポートできる仮想マシンの数はこれらの要因に依存する。

したがって、「VMware ESX Server 3.0」と「Microsoft Virtual Server 2005 R2」では、同じホストでもVM／コア比が全く異なる。

この値はなぜこれほどあいまいなのだろうか？ 要因の数があまりに多いため、1つの製品に対して明確な比率を示すのが難しく、仮想化ベンダーでは目安を示すのがやっとの状態なのだ。

たとえば VMwareは同社の「ESX Server」が1コアあたり最大8台の仮想マシンを処理できるとしているが、「(VMware) Server」（旧GSX Server）の方は処理できる仮想マシンを最大4台としている。

しかし、これらの数字は仮想マシン上のアプリケーションの技術（COBOLで書かれたレガシーな会計ソフトウェアなどは効率の良いものではない）やI/Oの負荷などによって大幅に上下する。

値がこれほど流動的であっても、仮想化プロジェクトではこれが最も重要なポイントとなり、製品比較では必須となる。この作業は場合によっては不可能で、本稿執筆時点では、MicrosoftはまだVirtual Server 2005 R2の推奨VM／コア比を用意していない。

単なるVM／コア比の計算以外にも、1台の物理的なサーバではなく、複数のサーバの役割まで仮想化するということを必ず覚えておきたい。つまり、実際の物理サーバと同じ方法で仮想マシンのサイズを決めるのが最良のソリューションであるとは限らない。

複数のホストマシンがある場合の典型的な誤りは、同じロジックを持つ仮想マシンを同じ場所に集約するアプローチだ。つまり、最初のホストですべての本番環境マシンを仮想化し、すべての開発マシンは2番目のマシンで仮想化するといった具合だ。

ここには主に2つの要因がある。論理的順序だと考えられるものを維持する自然な願望と、物理的位置が内部のサービスと厳密に関連する（この考え方はグリッドコンピューティングへの進化の過程で徐々に消えていく）という典型的な文化的偏見だ。

このアプローチは、たいていは悪い集約比に結びつく。アーキテクトが本番環境の複数の仮想マシンを同じホストに詰め込もうとすると、サービスの膨大な負荷によってマシンが過負荷になる。その一方で、十分活用されていない仮想マシンを稼動させている別のホストは、計算処理時間の大半を無駄にすることになる。

したがって、キャパシティ・プラニングで大きな課題となるのが、仮想マシンの配置のバランスを取るために補完しあうサービスを見つけることである。

この作業は、全日を通した予想作業負荷、要求される物理リソースの種類、激しい変動傾向など、複数のサービス要因を加味する必要がある。

言うまでもなく、これらの要因は徐々に変化したり、スケーるアップもしくは突然に変化したりするため、企業における仮想管理担当者は環境の変化に応じた仮想マシンの配置転換を実施しなくてはならないのに対し、キャパシティ・プランナーは作業負荷の増大まで予想しなくてはならない。

これでもかなり複雑に思えるが、まだ最大の要因が残っている。各サービスの許容パフォーマンスレベルだ。

たいていは、これがキャパシティ・プラニングのなかで最も見落とされる部分だ。仮想化したアプリケーションは絶対に最高のパフォーマンスを出すと思いこんでしまうのだ。最良の配置にしても、現実は許容範囲で処理を行うための物理リソースがソフトウェアごとにある程度必要になる。

キャパシティ・プラニングでは、補完しあうワークロードのシナリオを検討し、どのサービスでも必ず想定されるパフォーマンスを実現する代替案を熟慮する必要がある。

この作業は非常にたいへんなように思えるが、幸いにもその一部は近い将来簡略化されるようになる。すべての仮想インフラが、作業負荷に応じて仮想マシンを異なるホストにシームレスかつダイナミックに移動できるようになるのだ。 VMwareがつい先ごろ、「Virtual Infrastructure 3」（別名：ESX Server 3.0およびVirtualCenter 2.0）の一部として「Distributed Resource Scheduler」（DRS）と呼ばれるこのような機能を投入している。

Microsoftも、まもなく登場する「Virtual Machine Manager」ツールで同じ機能を投入する見込みだ。

これだけある要因も、既存の複数の製品を使えば一部は管理が可能だ。

最初に来る製品で、おそらく最も完成度が高いと思われるのが現在市場をリードするVMwareのものだ。同社では、「Capacity Planner」ツールをコンサルティングサービスとして提供しており、定価は最大200台のサーバで2万2000ドルとなっている。

このツール最大のメリットが、業界の各種アプリケーションの平均パフォーマンス値が収められた巨大データベースだ。

VMware Capacity Plannerは、これらの値にも基づき、考えられる最適な配置を提案するだけでなく、物理レベルと仮想レベルの両方で問題の起こりそうなアプリケーションも識別する。

このようなツールを販売しているのはVMwareだけではない。たとえばHPは「Solution Sizer」を、そしてSunは「Consolidation Tool」を投入し、プロジェクトのこのフェーズで顧客を大々的に支援している。

いずれの製品も無償だが、対応およびチューニングは特定のサーバのみに限られている。

また、候補サーバの選択フェーズで既に言及した「PlateSpin PowerRecon」は、作業負荷の配置のための、最も費用効果の高いソリューションだと思える。

これは、新しい「Consolidation Planning Module」のおかげで、“業界平均値データベース”機能を除けばVMware Capacity Plannerと同じ機能を提供することができる。

この製品の最高の機能が、同社のPhysical-to-virtual（P2V）製品との統合だ。これについては仮想化技術採用プロジェクトの4番目のフェーズで解説する。これにより、プロジェクト初期段階の論理的かつ統合された作業フローが提供される。

次回は、キャパシティ・プラニングの慎重な実施がいかにプロジェクト全体に見合う（あるいは見合わない）経済価値に結びついていくかを解説する。

＊ご注意：本稿は、昨年英語版サイトで最も閲覧されたニュースのうちの一つとして掲載しております。そのため一部情報が古い可能性もございます。 なお、原文はこちらをご参照ください。