JP2009537894A - 作業負荷特性に基づいたホストへの仮想マシンのデプロイ - Google Patents

Abstract

候補ＶＭを候補ホストにデプロイすべきかどうかを判定するため、候補ホストから利用可能なリソースと候補ＶＭにより必要とされるリソースとを考慮して、候補ホストから利用可能な幾つかのリソースの各々に対してサブレーティングを計算する。この場合、リソースに対するサブレーティングは、候補ＶＭを候補ホストにデプロイした後に空いているリソースの量に対応する。その後、計算したサブレーティングからレーティングを計算して、候補ホストがどの程度良く候補ＶＭを収容できるかを特徴付ける。候補ホストに対するレーティングをセレクタに提示する。そのセレクタは、候補ＶＭを候補ホストにデプロイすべきかどうかをそのレーティングに基づいて判定する。

Description

本発明は、複数ホストの各々の作業負荷特性と同様、仮想マシンの作業負荷特性とに基づいて、仮想マシンに対するホストを選択することに関する。同様に、本発明は、物理マシンの仮想マシンとしての仮想化およびホストへのデプロイを行うべきかどうか、または行いうるかどうかを、一般的なホストの作業負荷特性と上記の物理マシンの作業負荷特性に基づいて決定することに関する。

理解されるべきであるが、仮想マシン（ＶＭ：ｖｉｒｔｕａｌ ｍａｃｈｉｎｅ）は、ハードウェアシステムをエミュレートするために、コンピューティング装置等（即ち、ホスト）の上で動作するソフトウェア構成等である。必ずしも必要ではないが、一般に、ＶＭはアプリケーション等であり、ホスト上で使用して使用アプリケーション等を具現化することができ、一方で同時に上記使用アプリケーションを上記ホスト装置または上記ホスト上の他のアプリケーションから隔離することができる。１つの一般的な状況では、ホストは複数のデプロイされたＶＭを収容することができ、それぞれのＶＭはホストから利用可能なリソースにより幾つかの所定の機能を実施することができる。それぞれのＶＭは仮想的な形ではあるが実質的にコンピューティング装置であり、従ってその使用アプリケーションおよび外部の両方に対して自身をそのように表現している。

必ずしも必要ではないが、一般に、ホストはそのそれぞれのＶＭを別々のパーティションにデプロイする。上記のホストは、監督アプリケーションまたは「ハイパバイザ」として動作するＶＭモニタ等を有する仮想化層を含むことができる。この場合、仮想化層はホストの各ＶＭの監督機能を監督および／または管理し、それぞれのＶＭと外部との間の可能なリンクとして動作する。

ＶＭの特徴の１つは、仮想的な構成としてのＶＭを自由に停止および再起動できること、ならびに停止しているＶＭをファイル等のように記憶および取り出しできることである。特に、特定のコンピューティング装置上に具現化したＶＭは、きれいにパッケージ化できる単一のソフトウェア構成である。なぜならば、そのソフトウェア構成は、上記ＶＭに関する動作データおよび状態情報を含む、上記ＶＭに関する全てのデータを含むからである。結果として、第１のホストでＶＭを停止し、停止したＶＭを第２のホストに移動して、第２のホストで移動したＶＭを再起動すること、等により、第１のホスト上のＶＭを第２のホストに移動または「マイグレード」することができる。より一般的には、ＶＭを第１のプラットフォームから第２のプラットフォームに同様にマイグレードすることができる。この場合、プラットフォームは異なるホスト、同一ホストの異なる構成、等を表す。後者の場合、理解されるべきであるが、例えばメモリを追加した場合、プロセッサを変更した場合、追加の入力装置を与えた場合、選択した装置を取り外した場合、等にはコンピューティング装置は異なる構成を有してもよい。

ＶＭによる仮想化を使用して、相対的に強力なコンピュータシステムを、独立な、孤立したＶＭの集合に対するホストとして動作させることができる。従って、ホスト上のＶＭは同一のハードウェアプラットフォーム上で共存し、それぞれのＶＭがホストから利用できるリソース、およびホスト経由で利用できるリソースに対してあたかも排他的なアクセスを有するかのように動作する。従って、仮想化によりそれぞれのホストを最適に使用することができ、要求、ニーズ、要件、容量、可用性、および他の一般的な制約に基づいて、一連のホスト／プラットフォームの間でＶＭをマイグレードすることができる。

仮想化により、それぞれがアプリケーションを動作させている物理マシンを有するユーザは上記のアプリケーションを一連のホストに統合して、それにより全体のハードウェアニーズを削減することもできる。従って、１例に過ぎないが、それぞれがサーバ等として動作する複数の物理マシンを有するユーザは、それぞれの物理サーバをＶＭに仮想化できること、および複数の上記ＶＭが１つのホスト上に存在可能なことがわかるであろう。多種多様ではあるが、上記のＶＭにより１つのホストが５個または１０個またはそれ以上の物理マシンに相当するものを収容できることは珍しくない。要約すると、仮想化の結果、ユーザは既存のハードウェアを、そのハードウェアを非常に高い割合で利用することでさらに活用することができる。実際、物理サーバをデプロイすると一般的なユーザは利用可能なハードウェアリソースの約１５パーセントしか平均して利用できないので、ＶＭの収容に関連する予約容量とオーバヘッドを考慮して、仮想化を使用して３倍、４倍、および恐らく５倍、６倍の上記利用率の増大をもたらすことがでる。

より具体的には、一般的なユーザは、基盤ハードウェアを十分に利用しない様々な作業負荷を実行する多数のサーバマシン等を有する。さらに、ハードウェアには寿命に近いものがあり、その既存のハードウェアが十分に利用されていないときにそのハードウェアをより最新で高速なシステムにアップグレードすることが当然であるとするのは難しいかもしれない。従ってユーザは、仮想化を使用して、サーバマシン等をＶＭとして一連のホストに統合するソリューションを可能とすると得であろう。しかしながら、重要なこととして、上記のユーザには、仮想化すべきサーバマシン等の選択と、それぞれのＶＭを収容すべきホストの選択とをガイドできる管理ツールが必要である。

換言すれば、ユーザには、サーバマシン等をＶＭとして一連のホストに配置することをガイドできる管理ツールが必要である。一般に、デプロイメントは、定義した作業負荷と、その作業負荷をサービスする一連の互換性のある物理リソースとを効率的にマッチすることを扱う。デプロイメントが非効率的であるか、または要件に対するリソースの互換性のないマッチを考慮する場合は、ハードウェア利用を最適化するという目標は実現不可能でないとしても困難となる。従って、本発明は互換性があって効率的なデプロイメントを容易にし、ネットワーク、記憶、ライセンス、計算能力、メモリ、等を含むリソース要件を考慮している。

本発明では、候補ＶＭ（ｖｉｒｔｕａｌ ｍａｃｈｉｎｅ）と、その候補ＶＭがデプロイされうる候補ホストコンピューティング装置（ホスト）に関するシステムおよび方法を提供する。上記システムおよび方法は、候補ＶＭを候補ホストにデプロイすべきかどうかの決定を支援するものであり、候補ホストから利用可能なリソースと候補ＶＭが必要とするリソースとを考慮する。

候補ホストから利用できる幾つかのリソースの各々に対してサブレーティングを計算する。この場合、リソースに対するサブレーティングは、候補ＶＭを候補ホストにデプロイした後に空いているリソースの量に対応する。その後、候補ホストが候補ＶＭをどの程度良く収容できるか特徴付けのため、計算したサブレーティングからレーティングを計算する。それぞれの候補ホストに対するレーティングをセレクタに提示する。セレクタは、候補ＶＭを候補ホストにデプロイすべきかどうかを、そのレーティングに基づいて決定する。候補ホストの選択結果は候補ＶＭをデプロイするために受信され、候補ＶＭにより必要とされる選択したホストのリソースは、その候補ＶＭがその選択したホストにデプロイされるまで予約される。その後、候補ＶＭは選択したホストにデプロイされる。

上記の要約、および下記の本発明の実施形態の詳細な説明は、添付図面と関連して読むことにより、より良く理解されるであろう。本発明を例示するため、現段階で好適である実施形態を図面に示してある。しかしながら、理解されるべきこととして、本発明は示した配置と手段に正確に限定されることはない。

［コンピュータ環境］
図１および以下の議論は、本発明および／またはその一部を実装可能な適切なコンピューティング環境を簡潔で一般的に説明することを意図している。必ずしも必要ではないが、本発明を、プログラムモジュールのような、クライアントワークステーションまたはサーバのようなコンピュータにより実行されるコンピュータ実行可能命令の一般的な状況で説明する。一般に、プログラムモジュールには、特定のタスクを実施するか、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造等が含まれる。さらに、本発明および／またはその一部を他のコンピュータシステム構成で実践してもよいことは理解されるべきである。その構成には、ハンドヘルド装置、マルチプロセッサシステム、マイクロプロセッサベースまたはプログラム可能家電製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ等が含まれる。本発明を、通信ネットワークを介して接続したリモート処理装置によりタスクが実施される分散コンピューティング環境において実践することもできる。分散コンピューティング環境において、プログラムモジュールをローカルおよびリモートメモリ記憶装置の両方に配置することができる。

図１に示すように、例示的な汎用コンピューティングシステムは、パーソナルコンピュータ、サーバ、等のような従来のコンピューティング装置１２０を含む。コンピューティング装置１２０は、演算装置１２１、システムメモリ１２２、およびシステムメモリを含む様々なシステムコンポーネントを演算装置１２１に接続するシステムバス１２３を含む。システムバス１２３は、任意の種類のバス構造が可能である。そのバス構造には、メモリバス、またはメモリコントローラ、周辺バス、および任意の様々なバスアーキテクチャを使用するローカルバスが含まれる。システムメモリは、ＲＯＭ（ｒｅａｄ−ｏｎｌｙ ｍｅｍｏｒｙ）１２４およびＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）１２５を含む。ＢＩＯＳ（ｂａｓｉｃ ｉｎｐｕｔ／ｏｕｔｐｕｔ ｓｙｓｔｅｍ）１２６は、例えば起動時にパーソナルコンピュータ１２０内部の要素間での情報転送を支援する基本ルーチンを含み、ＲＯＭ１２４内に記憶される。

パーソナルコンピュータ１２０は、さらに、ハードディスク（図示せず）を読み書きするハードディスクドライブ１２７、取り外し可能磁気ディスク１２９を読み書きする磁気ディスクドライブ１２８、およびＣＤ−ＲＯＭまたは他の光媒体のような取り外し可能光ディスク１３１を読み書きする光ディスクドライブ１３０を含むことができる。ハードディスクドライブ１２７、磁気ディスクドライブ１２８、および光ディスクドライブ１３０をそれぞれ、ハードディスクドライブインタフェース１３２、磁気ディスクドライブインタフェース１３３、および光ドライブインタフェース１３４によりシステムバス１２３に接続する。ドライブおよびその関連コンピュータ可読媒体は、パーソナルコンピュータ１２０向けのコンピュータ可読命令、データ構造、プログラムモジュールおよび他のデータの不揮発性記憶を与える。

本明細書で説明する例示的な環境ではハードディスク、取り外し可能磁気ディスク１２９、および取り外し可能光ディスク１３１を使用するが、コンピュータがアクセス可能なデータを記憶できる他種のコンピュータ可読媒体もその例示的な動作環境で使用できることは理解されるべきである。上記の他種の媒体には、磁気カセット、フラッシュメモリカード、デジタルビデオディスク、ベルヌーイカートリッジ、ＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、ＲＯＭ（ｒｅａｄ−ｏｎｌｙ ｍｅｍｏｒｙ）、等が含まれる。

多数のプログラムモジュールをハードディスク、磁気ディスク１２９、光ディスク１３１、ＲＯＭ１２４またはＲＡＭ１２５に記憶することができる。そのプログラムモジュールには、オペレーティングシステム１３５、１つまたは複数のアプリケーションプログラム１３６、他のプログラムモジュール１３７およびプログラムデータ１３８が含まれる。ユーザは命令および情報を、キーボード１４０およびポインティングデバイス１４２のような入力装置を介してパーソナルコンピュータ１２０に入力することができる。他の入力装置（図示せず）は、マイクロフォン、ジョイスティック、ゲームパッド、パラボラアンテナ、スキャナ、等を含むことができる。これらおよび他の入力装置を、システムバスに接続したシリアルポートインタフェース１４６を介して演算装置１２１に接続することがよくあるが、パラレルポート、ゲームポート、またはＵＳＢ（ｕｎｉｖｅｒａｌ ｓｅｒｉａｌ ｂｕｓ）のような他のインタフェースにより接続してもよい。モニタ１４７または他種のディスプレイ装置も、ビデオアダプタ１４８のようなインタフェース経由でシステムバス１２３に接続する。モニタ１４７に加えて、パーソナルコンピュータは、一般に、スピーカおよびプリンタのような他の周辺出力装置（図示せず）を含む。図１の例示的なシステムは、ホストアダプタ１５５、ＳＣＳＩ（Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ）バス１５６、およびＳＣＳＩバス１５６に接続した外部記憶装置１６２も含む。

パーソナルコンピュータ１２０は、リモートコンピュータ１４９のような１つまたは複数のリモートコンピュータに対する論理接続を使用してネットワーク環境で動作できる。リモートコンピュータ１４９は、別のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイスまたは他の共通ネットワークノードが可能であり、一般にパーソナルコンピュータ１２０に関して上述した要素の全てを含むが、メモリ記憶装置１５０のみを図１に示した。図１に示す論理接続はＬＡＮ（ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）１５１およびＷＡＮ（ｗｉｄｅ ａｒｅａ ｎｅｔｗｏｒｋ）１５２を含む。上記ネットワーク環境は、職場、企業規模のコンピュータネットワーク、イントラネット、およびインターネットで一般的である。

ＬＡＮネットワーク環境で使用するとき、パーソナルコンピュータ１２０をネットワークインタフェースまたはアダプタ１５３を介してＬＡＮ１５１に接続される。ＷＡＮネットワーク環境で使用するとき、パーソナルコンピュータ１２０は一般にモデム１５４、または、インターネットのような広域ネットワーク１５２上で通信を確立する他の手段を含む。モデム１５４は、内部または外部で可能であるが、シリアルポートインタフェース１４６経由でシステムバス１２３に接続される。ネットワーク環境では、パーソナルコンピュータ１２０に関して示したプログラムモジュール、またはその一部をリモートメモリ記憶装置に記憶することができる。示したネットワーク接続は例であって、コンピュータ間の通信リンクを確立する他の手段を使用してもよいことは理解されるであろう。

［ホストおよび仮想マシン］
図２を参照すると、本発明は、ＶＭ（ｖｉｒｔｕａｌ ｍａｃｈｉｎｅ）１２として仮想化され、またはそのように仮想化できる物理マシン１０等の状況で、特に適用できることが分かる。ＶＭ１２の各々は、適切な方法で任意の一連のホスト１４にデプロイされる可能性がある。ここで、物理マシン１０等、ＶＭ１２およびホスト１４は、本発明の精神および範囲から逸脱せずに、任意の適切なサーバマシン等、ＶＭ、およびホストで可能であることに留意されたい。上記のサーバマシン等、ＶＭ、およびホストは関連業界（ｒｅｌｅｖａｎｔ ｐｕｂｌｉｃ）に既知であるか、または明らかなはずであり、従って本明細書では既に与えられている以上にさらに詳細に説明する必要はない。

上述したように、それぞれのＶＭ１２は、ホスト１４へデプロイするときに対応する物理マシン１０等をエミュレートするソフトウェア構成である。従って、ＶＭ１２はホスト１４のリソースを使用して、サーバを具現化するかまたは他の使用アプリケーション等を使用することができ、一方で同時に上記の使用アプリケーションを上記ホスト１４から、および上記ホスト１４上の他のアプリケーションから分離することができる。図示のように、ホスト１４は複数のデプロイしたＶＭ１２を収容することができる。この場合、それぞれのＶＭ１２は独立して幾つかの所定の機能を実施する。例えば、ホスト１４にデプロイしたＶＭ１２の少なくとも一部はデータサーバとして動作可能であり、上記ＶＭ１２の少なくとも一部は、ホスト１４に接続したネットワーク１６に関してネットワークサーバとして動作可能であり、上記ＶＭ１２の少なくとも一部は、メールサーバとして動作可能であり、上記ＶＭ１２の少なくとも一部は、メンテナンス機能、データ収集、ハードウェアモニタリング、誤り訂正、ファイル管理、等を含む低レベル機能を実施することができる。特に、仮想的な形ではあるが、それぞれのＶＭ１２は実質的にコンピューティングマシンである。

ホスト１４自体は、適切なコンピューティング装置で可能である。そのコンピューティング装置には、例えば、デスクトップコンピュータ、ラップトップコンピュータ、ハンドヘルドコンピュータ、データアシスタント、メインフレームコンピュータ、あるいは１つまたは複数のＶＭ１２をホストするのに必要な機能性および容量を有する任意の他種のコンピュータ装置がある。しかしながら、それぞれのＶＭにはホスト１４からの大量のメモリ、Ｉ／Ｏ操作、記憶容量、およびプロセッサ能力が必要であろうことを念頭におき、また、ホスト１４は２、５、１０、２０個またはそれ以上のＶＭ１２を一度に収容することが期待される可能性があることを念頭におくと、ホスト１４は実際に上記のＶＭ１２を収容できるために大量の性能とリソースを有すべきであろう。

それぞれの物理マシン１０等に関して、最も一般的にはそれぞれのＶＭ１２はサーバのような物理マシン１０に対応するが、本発明の精神および範囲から逸脱せずに、実際に任意の種類のコンピューティング装置に対応できることは理解されるべきである。従って、物理マシン１０としてのサーバに加え、それぞれのＶＭ１２は任意の他種のアプリケーション型の物理マシンに対応することができる。その物理マシンには、任意のメンテナンスマシン、データ収集マシン、ハードウェアモニタリングマシン、誤り訂正マシン、ファイル管理マシン、等が含まれるがこれらに限らない。さらに、それぞれのＶＭ１２は任意のサブマシンレベルのアプリケーションに対応することもできる。そのアプリケーションには、ワードプロセッサ、スプレッドシートアナライザ、メールアプリケーション、データベースアプリケーション、ドローイングアプリケーション、コンテンツレンダリングアプリケーション、等が含まれる。

［仮想マシンのデプロイメントの評価］
物理マシン１０等を仮想化するかどうかを決定する際に、ユーザは、（１）物理マシン１０が仮想化に対する受入れ候補であるかどうかを判定し、（２）適切な候補に対して、物理マシン１０をＶＭ（ｖｉｒｔｕａｌ ｍａｃｈｉｎｅ）１２に変換する。物理マシン１０のＶＭ１２への変換を、本発明の精神および範囲から逸脱せずに、任意の適切な方法で実施することができる。物理マシン１０のＶＭ１２への変換は一般に関連業界に既知であって明らかなはずであるので、その変換に対する詳細は、提供するもの以外は本明細書では詳細に説明する必要はない。

いずれにせよ、物理マシン１０に対応するＶＭ１２を生成すると、（３）１つまたは複数の候補ホスト１４を、ＶＭを効率的な方法および／または受け入れられる方法でデプロイ可能なホスト１４として識別し、ならびに（４）上記ＶＭ１２を選択した候補ホスト１４にデプロイすることができる。特に、本発明を使用して、ステップ（１）およびステップ（３）での意思決定を支援することができる。即ち、本発明はシステムを提供し、そのシステムにより、物理マシン１０をＶＭ１２として、仮想化してホスト１４にデプロイすべきかどうか、またはそのようにできるかどうかを、一般的なホスト１４の作業負荷特性と物理マシン１０の作業負荷特性とに基づいて判定することができる。加えて、同じツールを使用して、１つまたは複数の候補ホスト１４がＶＭ１２に対して受け入れられるかどうかを、再度それぞれの候補ホスト１４の作業負荷特性と同様にＶＭ１２の特性とに基づいて決定することができる。

図３を参照する。本発明を実施するシステムを示す。そのシステムにおいて、分かるように、エバリュエータ１８が候補ＶＭ１２と少なくとも１つの候補ホスト１４とのモデルに関するデータを受信し、それぞれの候補ホスト１４が、その上にデプロイされる候補ＶＭ１２を収容する容量を有するかどうかを判定する。物理マシン１０をＶＭ１２として仮想化してホスト１４にデプロイすべきかどうか、またはデプロイできるかどうかを判定する状況では、候補ＶＭ１２は仮想化した物理マシン１０を特性化したものであり、一方で単一の候補ホスト１４は、ＶＭ１２がデプロイされるホスト１４を特徴付けることを意図した複合的なホスト１４であることに留意されたい。上記の特性化したホスト１４は、状況に応じて、平均的なホスト、最善のホスト、ハイアベレージホスト、等が可能であることに留意されたい。１つまたは複数の候補ホスト１４がＶＭ１２に対して受け入れられるかどうかを決定する状況では、候補ＶＭ１２は、複数の候補ホスト１４のうち任意のものにデプロイされるＶＭ１２である。

いずれの事例でも、エバリュエータ１８は候補ＶＭ１２に対するモデルデータを受信する。そのモデルデータには、候補ＶＭ１２に対する基準プロセッサ構成、および候補ＶＭ１２に対して判定した作業負荷特性が含まれる。上記の基準プロセッサ構成は、例えば、候補ＶＭ１２が、特定の利用可能なリソースを有し、特定の速度で動作する特定のプロセッサを有するもので可能である。候補ＶＭ１２は、一般に関連モデルデータを有する。その関連モデルデータは、基準プロセッサ構成の状況では上記ＶＭ１２の作業負荷の実行に必要な容量を指定し、例えば特定の基準プロセッサ上でＶＭ１２が負担することになるプロセッサ利用率を指定することができる。

上記作業負荷特性は、様々な因子に基づくことができ、従って、プロセッサ（例えば、利用率）、メモリ（単位時間あたりの利用可能量、読み書き量）、記憶容量（単位時間あたりの利用可能量、読み書き量）、ネットワーク１６（使用可能帯域幅、単位時間あたりの読み書き、等）、等のような候補ＶＭ１２の別リソースの利用に関する作業負荷の特性を含むことができる。勿論、上記作業負荷特性は、本発明の精神および範囲から逸脱せずに、ソフトウェアバージョン、組み込まれているハードウェア、等のような非利用因子を含む他の因子に基づくことができる。

また、作業負荷特性を、本発明の精神および範囲から逸脱せずに、他の表現で指定することができる。それに関連して、作業負荷を別の装置内で別のリソースに対して指定できることに留意されたい。例えば、プロセッサ負荷を利用率として指定することができ、一方でネットワーク負荷を、バイト／秒のネットワークトラフィック表現で指定することができる。記憶装置の負荷は記憶装置のスループット仕様を含むことができることにも留意されたい。そのスループット仕様には、ＶＭ１２が単位時間あたりに実施したバイト数およびＩ／Ｏ演算の数が含まれる。ネットワーク負荷を必ずしもバンド幅で指定しなくともよいことにも留意されたい。なぜならば、ネットワークトラフィックがバンド幅に依存しないかもしれないからである。最後に、作業負荷を物理リソースの表現で指定することができることに留意されたい。いずれにせよ、作業負荷をどのように特徴付けても、エバリュエータ１８は上記の特徴付けた作業負荷を、以下で説明する計算に従う形に適切に変換する。上記変換は関連業界に既知であって明らかなはずであるので、提供するもの以外は本明細書では詳細に説明する必要はない。

理解できるように、候補ＶＭ１２に関するプロセッサ構成および作業負荷特性は実際には、候補ＶＭ１２が仮想装置であるので仮想的な構成および特性である。それにも関わらず、上記の仮想的な構成および作業負荷特性を、少なくとも作業負荷特性の因子に関して、それぞれの候補ホスト１４が要求するリソースの判定に適用できる。一般に、本発明では、エバリュエータ１８は入力として、それが候補ＶＭ１２または候補物理マシン１０でも、作業負荷の表現方法を取る。いずれの事例でも、図３で分かるように、作業負荷を、データコレクタ２０、データインタフェース２２等により取得したデータに従ってエバリュエータ１８に対して記述してある。図３に関して、必ずしも上記のデータを、候補物理マシン１０から得た候補ＶＭ１２から得る必要はなく、候補物理マシン１０から直接得ることができることに留意されたい。

同様に、エバリュエータ１８はさらにそれぞれの候補ホスト１４に対してモデルデータを受信する。そのモデルデータには、候補ホスト１４に対する実際のプロセッサ構成、およびそれぞれの候補ホスト１４に対する実際の作業負荷特性が含まれる。前と同様に、上記の実際のプロセッサ構成は、例えば、候補ＶＭ１２を上記候補ホスト１４にデプロイする前に利用可能であった特定のリソースを有し特定の速度で動作する特定のプロセッサを、候補ホスト１４が有することが可能である。ここで、実際の作業負荷特性は、候補ＶＭ１２の作業負荷特性と同じ因子に基づき、従って、プロセッサ、メモリ、記憶容量、ネットワーク１６、等のような候補ホスト１４の別リソースの利用に関する実際の作業負荷の特性を含むことができる。

それぞれの候補ホスト１４および候補ＶＭ１２に関して、作業負荷特性の因子に対するデータの少なくとも一部をデータコレクタ２０等により履歴ベースで、候補ホスト１４の動作中、ＶＭ１２の動作中、ＶＭ１２に対応する物理マシンの動作中、等に取得できることに留意されたい。理解できるように、上記の履歴データコレクタ２０は、本発明の精神および範囲から逸脱せずに、任意の適切な方法で動作することができる。上記データを収集する１つの方法を以下で説明する。上記の履歴データコレクタ２０は関連業界に既知であって明らかなはずであるので、本明細書では詳細に説明する必要はない。

作業負荷特性の因子に対する実際のデータの少なくとも一部を、候補ホスト１４からデータインタフェース２２等により、候補ホスト１４の動作中に現在データとして取得できることにも留意されたい。理解できるように、上記データインタフェース２２は、本発明の精神および範囲から逸脱せずに、任意の適切な方法で動作することができる。上記インタフェース２２は関連業界に既知であって明らかなはずであるので、本明細書では詳細に説明する必要はない。少なくとも幾つかの状況では、同様なデータインタフェース２２を使用して、候補ＶＭ１２に関する少なくとも幾つかの現在データを取得できることにも留意されたい。例えば、上記インタフェース２２は、上記現在データを、候補ＶＭ１２に対応する物理マシン１０から、または既に幾つかのホスト１４上で動作中の場合は候補ＶＭ１２から、収集することができる。

原則として、および本発明の一実施形態では、エミュレータ１８はそれぞれの候補ホスト１４に関するレーティングを出力するように動作する。そのレーティングは、候補ＶＭ１２を上記候補ホスト１４にデプロイできるかどうか、およびそうならば候補ホスト１４がどの程度良く候補ＶＭ１２を収容できるかどうかを特徴付ける。一般に、上記レーティングは、構成および作業負荷特性に基づいて、候補ホスト１４がその上にデプロイされる候補ＶＭ１２を収容する容量を有するかどうか、およびそうならば相対的な表現でどの位容量があるのかを反映する。例えば、レーティングを０から５の間の数字として出力することができる。０は容量なしを意味し、５は最大容量を意味し、中間の値は容量の相対的に中間にある量を意味する。

本発明の一実施形態では、エバリュエータ１８はハード要件とソフト要件に基づいて動作する。ハード要件は、候補ＶＭ１２を候補ホスト１４にデプロイするために満たさなければならない要件として定義されるであろう。例えば、候補ＶＭ１２が候補ホスト１４上に２ギガバイトの記憶空間を必要とし、候補ホスト１４が１ギガバイトしか利用できない場合、候補ＶＭ１２を上記候補ホスト１４にデプロイすべきではない。一般に、ハード要件は、それぞれの候補ホスト１４からのデータインタフェース２２により取得される実際のデータに基づいて評価される。上記ハード要件の例は、一般に上述した作業負荷因子に関する容量に従い、従って、以下を含むことができるがこれらに限定されない。
−プロセッサ能力 − 候補ホスト１４は、候補ＶＭ１２の要件を満たすために十分なプロセッサ可用性を有さなければならず、さらにマルチプロセッサの候補ＶＭ１２は、適切なバージョンの仮想化ソフトウェアを実行している候補ホスト１４上でのみ実行することができる。
−記憶容量 − 候補ホスト１４は、候補ＶＭ１２を記憶し、候補ＶＭ１２にサービスするのに十分な空き記憶容量と関連する記憶リソースとを有さなければならない。
−メモリ容量 − 候補ホスト１４は、候補ＶＭ１２をデプロイした際に候補ＶＭを実行可能とするのに十分なメモリを有さなければならない。
−ネットワーク容量 − 候補ホスト１４は、候補ＶＭ１２が要求した際にネットワーク１６へのアクセスに利用できる十分なネットワーク帯域幅を有さなければならない。

上の全てが実際にあらゆる状況におけるハード要件であるわけではない。１例として、十分な能力がないことによる性能劣化が受け入れられると考えられる場合、プロセッサ能力はハード要件である必要はない。別の例として、十分な容量がないことによる性能劣化が受け入れられると考えられる場合、ネットワーク容量は同様にハード要件である必要はない。

ソフト要件は、任意の特定の候補ホスト１４にデプロイする際に、候補ＶＭ１２からの良好なまたは受け入れられるレベルの性能を実現するために満たすべき要件として定義されるであろう。即ち、ソフト要件を満たすべきであるが、満たされない場合は、デプロイした候補ＶＭ１２はなお動作するがサービスのレベルは劣化する。

候補ＶＭ１２に関してそれぞれの候補ホスト１４に対する前述のレーティングを生成する前に、図４を参照すると、本発明の一実施形態におけるエバリュエータは以下を含む機能を実施する。
−候補ＶＭ１２のプロセッサ利用率を、それと等価な候補ホスト１４のプロセッサのプロセッサ利用率に再調整すること（ステップ４０１）。例えば、候補ＶＭ１２がそのプロセッサの２０％を必要とするが候補ホスト１４のプロセッサがより高速であることが分かった場合、候補ＶＭ１２は上記候補ホスト１４の上記プロセッサの８％のみを必要とするかもしれない。理解されるべきであるが、再調整は、候補ＶＭ１２が必要とするプロセッサ利用率と候補ホスト１４で利用可能なプロセッサ利用率とを等価な装置内で比較するために必要である。理解できるように、上記の再調整を、本発明の精神および範囲から逸脱せずにエバリュエータ１８により、任意の適切な方法で実施することができる。例えば、候補ＶＭ１２のプロセッサと候補ホスト１４のプロセッサの等価なランキングを参照することができる。プロセッサの性能ランキングは、エバリュエータ１８がデータコレクタ２０から受信したモデルデータの一部でなくともよい。代わりに、エバリュエータ１８は性能ランキングを含むプロセッサ構成のライブラリを保持することができる。そのライブラリが評価中のプロセッサを含まない場合、上記プロセッサに対するランキングを、そのライブラリ内の同様なプロセッサ構成のランキングを考慮したアルゴリズムを使用して近似することができる。
−仮想化オーバヘッドの考慮（ステップ４０３）。特に、物理マシン１０をＶＭ１２に仮想化するとき、ホスト１４はＶＭ１２を収容する際に、ＶＭ１２に対する容量だけでなく、ＶＭ１２の仮想化に関連する追加作業または「オーバヘッド」に対する容量も有さなければならないことは理解されるべきである。上記オーバヘッドは、任意のＶＭ１２に存在し、装置のエミュレーション、リソース分割、およびＶＭ１２の仮想化を実現するのに費やすべき他のリソースから生ずる。理解できるように、オーバヘッドの量は候補ＶＭ１２に関連しうる作業負荷のタイプに依存して変化する。例えば、候補ＶＭ１２がネットワーク１６へのアクセスを必要とする場合、オーバヘッドを消費して仮想的なネットワーク要求を実際の要求に変換しなければならない。同様に、候補ＶＭ１２が記憶装置に対するアクセスを必要とする場合、オーバヘッドを消費してディスク要求を実際の要求に変換しなければならない。いずれにせよ、オーバヘッドをエバリュエータ１８により適切な因子に基づいて特徴付けることができる。その因子には、例えば、候補ＶＭ１２が実施すべき作業のタイプ、予想されるディスク要求の数、予想されるネットワーク要求の数、予想されるグラフィック要求の数、メモリアクセスの数、プロセッサ例外の数、実行プロセスの数、等がある。理解できるように、オーバヘッドの考慮を、本発明の精神および範囲から逸脱せずにエバリュエータ１８により任意の適切な方法で実施することができる。
−調整後およびオーバヘッドを考慮した後に候補ホスト１４上の候補ＶＭ１２の実行をシミュレートすること（ステップ４０５）。特に、エバリュエータ１８は利用パラメータ付きの「ダミーＶＭ」１２を候補ホスト１４に配置する。ダミーＶＭ１２は、デプロイした候補ＶＭ１２と少なくとも大よそ対応し、候補ホスト１４上で動作して、候補ホスト１４が上記ダミーＶＭ１２を受け入れられる程度に収容するかどうかを判定する。上記ダミーＶＭ１２による上記シミュレーションを実施して、候補ホスト１４が、少なくともダミーＶＭ１２が示すように候補ＶＭ１２を実際に収容可能であることの確認を試行する。本質的には、ダミーＶＭ１２を候補ホスト１４に配置することで、ダミーＶＭ１２を通した候補ＶＭ１２のリソース要件を候補ホスト１４上の現在のリソース利用と組合せて、候補ＶＭ１２を候補ホスト１４に配置することから生ずるリソース利用を生み出す。

候補ホスト１４上に配置したダミーＶＭ１２を実際にデプロイでき、または交互に概念的にデプロイできることに留意されたい。特に後者の場合に関して、ダミーＶＭ１２を実際に配置／デプロイすることは受け入れられない恐れがある。なぜならば、上記ダミーＶＭ１２は候補ホスト１４の実際のリソースを使用し、従って実際の作業を実施している上記候補ホスト１４にある他のＶＭ１２等に影響を及ぼす可能性があるからである。代わりに、計算による概念的なデプロイメントを実施することができ、その実施において候補ＶＭ１２の性能要件と候補ホスト１４の性能特性を組み合わせて、候補ホスト１４側の利用を、候補ホスト１４にデプロイした上記候補ＶＭ１２により計画する。

前述の仮想化オーバヘッドに関して、上記オーバヘッドは非常に変化し易く候補ＶＭ１２の作業負荷タイプに依存するので、本発明の一実施形態において一定のベンチマーク作業負荷集合を、作業負荷のそれぞれのタイプに対して定義できることにさらに留意されたい。上記作業負荷タイプおよび対応するベンチマークは、データベースサーバ、ウェブサーバ、および端末サーバを含むことができるがこれらに限定されない。それぞれの作業負荷タイプは、その作業負荷タイプに関連するプロセッサ、メモリ、記憶装置、ネットワークのオーバヘッド等の予測を可能とする特定の特性を有する。一般に、作業負荷がより記憶集約的およびネットワーク集約的になると、上記のリソースの仮想化コストのため、より多くのプロセッサオーバヘッドが発生する。

また、仮想化オーバヘッドの見積もりをさらに洗練できることに留意されたい。特に、プロセッサコストを、候補ＶＭ１２と候補ホスト１４との間で転送される１バイトのネットワークおよびディスクＩＯに関連付けることができる。データコレクタ２０から受信したモデルデータにディスクおよびネットワークＩＯ作業負荷が含まれる場合、エバリュエータ１８は１バイトに対するプロセッサコストを上記作業負荷に適用して、プロセッサオーバヘッド全体を取得することができる。プロセッサコストを評価中のプロセッサと異なるプロセッサから取得する場合、コストをステップ４０１で説明したものと同様に再調整することができる。上記の再調整により、様々なプロセッサ構成に渡るモデル仮想化オーバヘッドに必要な労力が削減される。

上述したそれぞれの候補ホスト１４に対するエバリュエータ１８の出力は、候補ＶＭ１２が必要とするリソースと候補ホスト１４で候補ＶＭ１２を仮想化するのに必要なオーバヘッドとを考慮した、候補ホスト１４がどれくらい候補ＶＭ１２を良く収容できるかを特徴付けるレーティングである。本発明の一実施形態では、上記のレーティングを以下の方法でエバリュエータ１８により計算する。

先ず、前述のハード要件のいずれも満たされず候補ホスト１４が利用可能な要求リソースを十分に有さない場合、レーティングは０である。さらに、候補ＶＭ１２が候補ホスト１４で任意のリソースを使用することにより、候補ホスト１４が上記リソースの使用に対して設定した閾値を超過する場合、レーティングは０である（ステップ４０７）。以下でさらに詳細に説明するように、候補ホスト１４にあるそれぞれのリソースは所定の利用閾値を有する。その閾値を超える使用は推奨されない。従って、上記の閾値は、実際に予測より高い使用状況を処理するために候補ホスト１４が利用可能であるべき予約リソースを定義する。候補ＶＭ１２により候補ホスト１４がハード要件または閾値に違反するのでレーティングが０に設定される場合、プロセスはここで停止する。そうでなければ、プロセスはレーティングに対する値を計算することで継続する（ステップ４０９）。

本発明の一実施形態において、サブレーティングを、候補ホスト１４にある幾つかのリソースの各々に対して計算する（ステップ４１１）。上記のリソースは、本発明の精神および範囲から逸脱することなく、例えば、プロセッサの利用、メモリの利用、記憶装置の利用、ネットワークの利用、等のような任意のリソースが可能である。

それぞれのリソースに対するサブレーティングを、リソースに対して設定した閾値、収集したデータに基づいてリソースに対して計算した利用率、およびリソースに割り当てた重みに基づいて、以下のように計算する。
サブレーティング＝（閾値−利用率）×重み

本発明の精神および範囲から逸脱せずに、閾値および重みを任意の適切な因子に基づいて管理者等により選択することができる。閾値は、上述の閥値であり、パーセントとして表すことができ、リソースに対して定義した前述の予約に対応する。上記の予約は幾分任意に定義することができるが、一般にはその環境下での追加容量を合理的に和らげるものを与えるように設定すべきである。例として、リソースが候補ホスト１４の記憶である場合、予約を候補ホスト１４の記憶容量である２０％と定義することができ、この場合、閥値は８０％である。同様に、例えば１５パーセントを予約すると閾値は８５パーセントに設定されるであろう。重みは、レーティング全体を計算するときに、他のリソースと比較してリソースをより重視するか、またはあまり重視しないように動作する。従って、全てのリソースが等しく重要であると考えられる場合、上記のリソースに全て等しい重み、例えば５を与えることができる。従って、或るリソースが別のものより２倍重要であると考えられる場合、その或るリソースにその別のリソースの２倍の重み、例えばそれぞれ６と３を与えることができる。

リソースに対する利用率を、場合によってはデータコレクタ２０および／またはデータインタフェース２２により収集した対応データに基づいて計算し、再び場合によっては、ステップ４０１およびステップ４０３でのようにオーバヘッドに対して調整および／または調節しておくことができることが重要である。エバリュエータ１８により実施される上記利用率の計算を、本発明の精神および範囲から逸脱せずに、任意の適切な方法で実施することができる。一般に、候補ホスト１４の任意の特定のリソースに対して計算される利用率は、候補ＶＭ１２を候補ホスト１４にデプロイしている間、および候補ホスト１２がデプロイされる前に実施された全ての他の機能を候補ホスト１４が実施している間に、候補ホスト１４により割合として利用されるリソース量を表す。従って、例えば、候補ＶＭ１２の前に候補ホスト１４が利用可能なネットワーク容量のうち２０パーセントを利用していた場合、および候補ホスト１２のデプロイ後に候補ホスト１４が上記利用可能なネットワーク容量の４５パーセントを利用すると計画する（即ち、さらに２５パーセントが候補ＶＭ１２に属する）場合、候補ホスト１４に対するネットワークリソースの利用率は４５パーセントの値である。

図５に利用率を図式で示す。特に、図示したように幾つかの特定のリソースに対して、候補ＶＭ１２をデプロイする前の候補ホストは、既存のホストを利用する。その既存のホスト利用は２５パーセントであると示してあり、これは上記候補ホスト１４に既にデプロイした他のＶＭ１２と同様全ての他のホスト動作とを表す。候補ＶＭ１２のデプロイ後、および図示するように、候補ＶＭ１２による追加利用は、４０パーセントと決定されており、その結果、全体で６５パーセントの利用率となる。上記リソースに対して、２０パーセントの予約を設定してあり、図示するように、結果として、閾値は８０パーセント（１００−２０）となり、候補ＶＭ１２のデプロイ後にリソースの１５パーセント（８０−６５）が空いた状態となる。従って、上記リソースに対するサブレーティングは８０パーセントの閾値から６５パーセントの総利用を減じたもの、即ち１５パーセントの空きに、リソースに対して設定した重みを乗じたものになるであろう。要するに、任意のリソースの利用率は、上記リソースを有する候補ホスト１４に候補ＶＭ１２をデプロイした後に空いているリソースのパーセントに最も密接に対応する。

いずれにせよ、サブレーティングを候補ホスト１４のそれぞれの考えうるリソースに対して計算したならば、上記のサブレーティングを合成して、候補ホスト１４に対するレーティングを以下のように生成する（ステップ４１３）。

レーティング＝サブレーティングの合計／サブレーティングの重み合計／正規化値
レーティングはその追加の値を決して下回らないよう、追加の値を、例えば０．５をレーティングの計算に対して加えても良いことに留意されたい。上記のレーティングを０．５に最も近いように丸めることができ、結果は０と５のような最大値との間の数値となる。理解できるように、正規化値は、レーティングの範囲を０と最大値の間に制限するように選択してある。例えば、サブレーティングの合計／サブレーティングの重み合計がその最大値であり、最大レーティングが５であるべきである場合、正規化値は２０、即ち１００／５であろう。

勿論、それぞれの候補ホスト１４とそのサブレーティングに対するレーティングを、本発明の精神および範囲から逸脱せずに、任意の他の適切な方法で計算することもできる。勿論、そのレーティングが、候補ホスト１４が、候補ホスト１４にデプロイする際に候補ＶＭ１２をどの程度良く収容できるかを合理的に表すことを仮定し、候補ホスト１４に既にデプロイした全ての他のＶＭ１２と候補ホスト１４により既に実施された他の動作を考慮している。例えば、ここでのレーティングは、実際に候補ＶＭ１２をデプロイした後に候補ホスト１４が有する空きリソース量を重視するが、上記のレーティングは、代わりに候補ホスト１４で使用される空きリソース量を重視してもよい。

エバリュエータ１８が候補ＶＭ１２に対するそれぞれの候補ホスト１４に対してレーティングを計算した後、エバリュエータはレーティングを管理者等に提示できる（ステップ４１５）。その後、管理者は評価した候補ホスト１４から選択することができる（ステップ４１７）。管理者は２つのデプロイメント戦略、即ち、負荷配分とリソース利用のうち１つに基づいて候補ホスト１４から選択するであろうことに留意されたい。負荷配分では、管理者は、最終的にＶＭ１２をデプロイしている全てのホスト１４がバランスの取れた方法で大よそ同じ負荷でそれを行うように、上記デプロイメント後の大部分のリソース（即ち、空きリソース）で候補ホスト１４に候補ＶＭ１２をデプロイすることを試行する。対照的に、リソース利用では、管理者はそれぞれのホスト１４の利用を最大化することを試行しており、従って候補ＶＭ１２を、上記デプロイメント後に最小リソース（即ち、空きリソース）で候補ホスト１４にデプロイすることを望むであろう。

従って、負荷配分ではデプロイメント後に全てのホスト１４を等しく利用された状態にすることを試行し、リソース利用では、次のホスト１４の使用開始に移る前に或るホスト１４上の利用可能な全てのリソースを使い切ることを試みる。理解されるべきであるが、上で計算したレーティングは候補ホスト１４の空きリソースを重視するので、負荷配分を実施する管理者は最高レーティングの候補ホスト１４を、候補ＶＭ１２のデプロイ先として選択する可能性がある。その候補ホスト１４は定義により、相対的な意味で上記デプロイメント後に最も多い空きリソースを有するであろう。対照的に、リソース利用を実施している管理者は、零でない最小評価の候補ホスト１４を、候補ＶＭ１２のデプロイ先として選択する可能性がある。その候補ホスト１４は定義により、相対的な意味で、上記デプロイメント後に最少の空きリソースを有するであろう。

候補ホスト１４を選択すると、リソースの予約を、恐らく選択したホスト１４に対して生成およびデプロイされる予約ＶＭ１２により、選択したホスト１４で行うことができる（ステップ４１９）。理解できるように、予約ＶＭ１２は、実体的な機能性またはコンテンツが全くない「シェル」ＶＭ１２である。上記予約ＶＭ１２は候補ＶＭ１２のハードウェア構成およびリソース要件を記述するが、候補ＶＭ１２のメモリ、データ、および記憶装置は省略されている。理解できるように、特にある特定のデプロイメント要件が基盤仮想化ソフトウェアのみに既知であって、エバリュエータ１８には既知でない可能性があり、デプロイメント要件は異なるバージョン、リリース、または異なるベンダの仮想化システム間で異なる可能性があるので、予約ＶＭ１２は候補ＶＭ１２のデプロイメントが実際に可能であることの重要な検証を与える。さらに、一般的なＶＭ１２は相対的に大規模、恐らく数ギガバイト以上の規模である可能性があるので、上記ＶＭ１２をホスト１４に、特に低速ネットワーク１６上でコピーすると、それ以上でないにしても数時間かかる恐れがある。従って、予約ＶＭ１２は非常に迅速にデプロイされ、従って候補ＶＭ１２が実際に選択したホスト１４にデプロイされている時間中に候補ＶＭ１２に対するホストリソースを予約するよう動作する（ステップ４２１）。ステップ４１９にあるリソースの予約を、候補ＶＭ１２のデプロイメントがリソースの点で使用するものをさらなるデプロイメントが考慮するように、選択したホスト１４からリソースの使用を借りることにより実現することもできることに留意されたい。

これまで本発明を個々の候補ホスト１４の点で説明してきたが、本発明をホストグループ等に関して同様に実践することもできる。理解できるように、ホストグループはホスト１４の集合であり、そのうちの任意のものは、実際に上記ホストグループにデプロイされる場合は特定の候補ＶＭ１２を収容することができる。しかしながら、ホストグループに対するリソースを少々異なる方法、例えばホストグループの平均的な表現に基づいて、またはホストグループの集合的な表現に基づいて、またはグループの最小設備のホスト１４に基づいて、等により特徴付けることができることに留意されたい。

また、ここまで本発明をホスト１４にデプロイされる候補ＶＭ１２の点で説明したが、本発明を、あるホスト１４に既にデプロイしたが候補ホスト１４に移動されている候補ＶＭ１２に関して実践することもできる。理解できるように、上記の場合は同じ評価手続きが行われるが、候補ＶＭ１２に関する幾つかのデータを少々異なる情報源から取得することができ、候補ＶＭ１２のデプロイを、候補ＶＭ１２を或るホスト１４から、選択したホスト１４に移動することで実現する。

同様に、本発明をこれまで、個々の候補ＶＭ１２の点で説明してきたが、本発明を、候補ホスト１４にデプロイされる複数の候補ＶＭ１２、および候補ホストグループに関して実践することもできる。多対１のデプロイメントには、１つのみではなく多数のＶＭ１２の追加に基づいて候補ホスト１４の仮想的な利用を評価することが含まれる。理解すべきであるが、複数の候補ＶＭ１２に対するリソースは集合的に表される。

とりわけ、多対多のデプロイメントはより複雑である。多対多のデプロイメントを実施するにあたり、あまり計算集約的でない方法は、単純にＶＭ１２の任意の順序付けを選択して、その順序付けに基づいてデプロイすることである。しかしながら、ＶＭ１２の別の順序付けにより全体のデプロイメントがより良くなる可能性があるので、全体的に最適なデプロイメントは実現されない。ヒューリスティックを適用して順序付けを改善することができる。例えば、順序付けは、様々なリソース利用の重み付け集計に基づいて選択した、最大のＶＭ１２から最小のＶＭ１２への順序に基づくことができる。勿論、完全に最適な解決法はＶＭ１２の全ての可能な順序付けを試すことであろうが、前述のヒューリスティックが満足な結果を生成する可能性があるので、上記の解決法は極めて計算的に高価で、概して不要である可能性がある。

上述したように、候補ＶＭ１２の候補ホスト１４へのデプロイメントを特徴付けるレーティングを判定するプロセスを、既に仮想化したＶＭ１２に関してだけではなく、仮想化の候補である物理マシン１０に関しても使用することができる。従って、単一の候補ＶＭ１２をエバリュエータ１８により１つまたは複数の候補ホスト１４に対して評価した。しかしながら、エバリュエータ１８は複数の候補ＶＭ１２を特定の候補ホスト１４に対して、利用可能な候補ホスト１４の代表に対して、複数の候補ホスト１４に対して、等のように評価できることにも留意されたい。最初の２つの場合では、エバリュエータ１８は、実際には複数の候補ＶＭ１２のうち、どれが候補ホスト１４へのデプロイに最適であるかを判定するために使用され、第３の場合では、エバリュエータ１８は、実際には複数の候補ＶＭ１２のうち、どれがどの候補ホスト１４へのデプロイに最適であるかを判定するために使用されるであろう。特に最初の２つの場合に関して、エバリュエータ１８を使用して、候補ホスト１４に仮想化およびデプロイされる対応ＶＭ１２により表されるように、複数の候補物理マシン１０から選択することができる。

［エバリュエータ１８に対する、候補ＶＭ１２、候補ホスト１４のデータ］
上で触れたように、候補ＶＭ１２を物理マシン１０から既に仮想化したか、またはまだ仮想化していないかに依存して、エバリュエータ１８に提示されエバリュエータ１８により使用される候補ＶＭ１２に関するデータを別の情報源から導出することができる。候補ＶＭ１２は全体的に新しくどの物理マシン１０にも依存しない可能性があり、この場合、プロセッサ、メモリ、ネットワーク、および記憶リソース等を含む、予想される必要リソースに基づいて、管理者等が上記候補ＶＭ１２に対するデータを定義できることに留意されたい。とは言っても、物理マシン１０から得た候補ＶＭ１２に関するデータと候補ホスト１４に関するデータを、それぞれ物理マシン１０および候補ホスト１４から取得した構成情報と性能データから得て、上記候補ＶＭ１２と候補ホスト１４をエバリュエータ１８に対してより正確に表すことができる。

特にＶＭ１２またはホスト１４の何れかに対して利用可能な性能データに関して、本発明の精神および範囲から逸脱せずに、上記のデータをサンプル等として収集することができ、データコレクタ２０およびデータインタフェース２２等により任意の適切な方法で集計することができる。その集計により、特に利用が合理的に表現されることを仮定している。特に、リソース利用は一般には相対的に低いが、ビジータイムでは相対的に高いことを理解すると、平均的な利用は上記の利用を特には良く表現しない。代わりに、本発明の一実施形態では、利用を、相対的に高い利用の平均として表す。従って、サンプルデータを集計して上記の高い利用の平均を生成することを、多数の時間層上で実施することができる。特に、それぞれの層では、幾つかのサンプルデータの最高値を平均化する。

例えば、図６を参照すると、特定の利用データを３つの層に編成する。その３つの層は、それぞれ、時間毎、日毎、および週毎のデータを表す第１、第２、および第３の層である。ここで、
−利用データの時間毎サンプルである第１層内の時間毎データを選択する（ステップ６０１）。
−第２層内の日毎データは第１層内の時間毎データの集計であり、特に上記時間毎データの３つの最高サンプルの平均である（ステップ６０３）。
−第３層内の週毎データは第２層内の日毎データの集計であり、特に上記日毎データの３つの最高サンプルの平均である（ステップ６０５）。および、
−エバリュエータ１８が使用する最終的なデータの値は第３層内の週毎データの集計であり、特に上記週毎データの３つの最高サンプルの平均である（ステップ６０７）。

勿論、任意数の層、および、最終値を生成するための層から層への任意の他の集計方法を、本発明の精神および範囲から逸脱せずに使用することもできる。

［結論］
本発明に関連して実施されるプロセスを達成するのに必要なプログラミングは相対的に単純であり、関連プログラミング業界には明らかであるべきである。従って、上記プログラミングはここでは付け加えない。本発明の精神および範囲から逸脱せずに、任意の特定のプログラミングを使用して本発明を達成することができる。

前述の説明で、本発明は、管理者等が物理マシン１０等をホスト１４上のＶＭ１２としてデプロイできる新規で有用なシステムおよび方法を備えることが分かる。上記システムおよび方法は、効率的に定義した作業負荷を一連の互換性のある物理リソースとマッチさせてその作業負荷をサービスし、そのようにして、ネットワーク、記憶装置、プロセッサ能力、メモリ、等を含むリソース要件を考慮した互換性のある、効率的なデプロイメントを促進する。従って、本発明は開示した特定の実施形態に限定されず、添付請求項で定義した本発明の精神および範囲内の修正を網羅することを意図していることは理解されるべきである。

本発明および／またはその一部の態様を組み込み可能な汎用目的コンピュータシステムを表すブロック図である。 ＶＭ（ｖｉｒｔｕａｌ ｍａｃｈｉｎｅ）として仮想化した、またはそのように仮想化でき、その各々が本発明の実施形態において一連のホスト１４のうち任意のものにデプロイされる物理マシンシステム等を示すブロック図である。 本発明の実施形態に従って１つまたは複数のホストにデプロイされる図２の１つまたは複数のＶＭを評価するシステムを示すブロック図である。 図３のシステムと関連して実施され、本発明の実施形態に従って１つまたは複数のホストにデプロイされる１つまたは複数のＶＭを評価するための主要なステップを示すフロー図である。 ＶＭにより使用される図２のホストのリソース表現を示し、特に、図４のサブレーティングがＶＭ１２をホストにデプロイした後に空いた状態のリソースの利用率にどのように対応するかを示すブロック図である。 サンプルデータを集計して、本発明の実施形態に従い図３のシステムと関連して使用できるもののような、リソースに関する利用率データの生成において実施する主要なステップを示すフロー図である。

Claims (20)

1. 候補ＶＭ（ｖｉｒｔｕａｌ ｍａｃｈｉｎｅ）と、前記候補ＶＭがデプロイされうる候補ホストコンピューティング装置（ホスト）とに関する方法であって、前記方法は、前記候補ホストから利用可能なリソースと前記候補ＶＭが必要とするリソースとを考慮して前記候補ＶＭを前記候補ホストにデプロイするかどうかの判定を支援し、
   前記候補ホストから利用可能な幾つかのリソースの各々に対してサブレーティングを計算するステップであって、前記リソースに対するサブレーティングは、前記候補ＶＭを前記候補ホストにデプロイした後に空いているリソースの量に対応するステップと、
   前記の計算したサブレーティングからレーティングを計算して、前記候補ホストがどの程度良く前記候補ＶＭを収容できるかを特徴付けるステップと、
   前記候補ホストに対する前記レーティングをセレクタに提示するステップであって、前記セレクタは、前記候補ＶＭをその前記レーティングに基づいて前記候補ホストにデプロイすべきかどうかを判定するステップと、
   前記候補ホスト上へ前記候補ＶＭをデプロイするため前記候補ホストの選択結果を受信するステップと、
   前記候補ＶＭを前記選択したホストにデプロイするまで、前記候補ＶＭによる要求に応じて前記選択したホストの前記リソースを予約するステップと、
   前記候補ＶＭを前記選択ホストにデプロイするステップと
   を含むことを特徴とする方法。
2. 前記候補ホストが相対的に高いレーティングを有し、前記セレクタが複数のホストに渡る複数のＶＭの負荷配分を実施することを試行する場合は、前記セレクタは候補ホスト上への前記候補ＶＭのデプロイメント先である前記候補ホストを選択し、それにより相対的に高いレーティングは、前記候補ＶＭのデプロイ後に残る相対的に多いリソース量を、前記候補ホストが有することに対応することを特徴とし、前記候補ホストが相対的に低い非零のレーティングを有し、前記セレクタが前記候補ホスト上の複数ＶＭのリソース利用を実施することを試行する場合は、前記セレクタは候補ホスト上への前記候補ＶＭのデプロイメント先である前記候補ホストを選択し、それにより前記の相対的に低いレーティングは、候補ホスト上への前記候補ＶＭのデプロイ後に残る相対的に少ないリソース量を前記候補ホストが有することに対応することを特徴とする請求項１に記載の方法。
3. それぞれのリソースに対する前記サブレーティングを、前記リソースに対して設定した閾値と、収集データに基づいて前記リソースに対して計算した利用と、前記リソースに割り当てた重みとに基づいて、
   サブレーティング＝（閾値−利用率）×重み
   のように計算するステップをさらに含み、前記闇値は、前記リソースに対する容量緩和を与えるために前記候補ホストの前記リソースに対して定義した予約に対応することを特徴とし、それぞれのリソースに対応する前記重みにより、他のリソースと比較して前記リソースを相対的に重視することを特徴とし、前記リソースに対する前記利用は、前記候補ＶＭと任意の他のＶＭを前記候補ホストにデプロイしている間に、前記候補ホストが利用するリソース量を表すことを特徴とする請求項１に記載の方法。
4. 前記利用は、前記候補ＶＭを前記候補ホストにデプロイする前の既存のホスト利用と、前記候補ホストにデプロイした後の前記候補ＶＭからのホスト利用を含むことを特徴とし、前記閾値は予約されたもの以外のリソース量であることを特徴とする請求項３に記載の方法。
5. 前記レーティングを、
   レーティング＝サブレーティングの合計／サブレーティングの重み合計／正規化値
   のように前記サブレーティングとそれぞれの重みとから計算するステップをさらに含み、前記正規化値を、前記レーティングの範囲を０と最大値の間に制限するように選択することを特徴とする請求項３に記載の方法。
6. 前記リソースはプロセッサ利用、メモリ利用、記憶装置利用、およびネットワーク利用を含むことを特徴とする請求項１に記載の方法。
7. 前記リソースはプロセッサ利用を含むことを特徴とし、前記候補ＶＭのプロセッサ利用を、それと等価な前記候補ホストのプロセッサ利用に再調整するステップをさらに含むことを特徴とする請求項１に記載の方法。
8. 前記リソースに関連する仮想化オーバヘッドを考慮した少なくとも１つのリソースをさらに含み、それにより前記仮想化オーバヘッドは、前記候補ホスト上での前記候補ＶＭの仮想化に関連するリソースの追加的な利用を表すことを特徴とする請求項１に記載の方法。
9. 前記候補ホストにデプロイされ前記候補ホスト上で動作する候補ＶＭに対応するダミーＶＭを利用パラメータ付きで前記候補ホストに配置して、前記候補ホストが受け入れられる程度に前記ダミーＶＭを収容するかどうかの判定を少なくともシミュレートすることで、前記候補ホスト上の前記候補ＶＭの実行をシミュレートし、それにより前記候補ホストが、少なくとも前記ダミーＶＭにより表されるように前記候補ＶＭを実際に収容できることを確認するステップをさらに含むことを特徴とする請求項１に記載の方法。
10. 特定をする任意のリソースに関して、前記候補ホストが前記リソースを十分に利用できない場合、前記候補ホストに対するレーティングを零に設定するステップをさらに含むことを特徴とする請求項１に記載の方法。
11. 前記候補ホストで前記候補ＶＭが特定のリソースを使用することにより、前記候補ホストが前記リソースの使用に対して設定した閾値を超過する場合、前記候補ホストに対する前記レーティングを零に設定するステップをさらに含むことを特徴とする請求項１０に記載の方法。
12. 前記候補ＶＭと、複数の候補ホストコンピューティング装置（ホスト）であって、そのうち任意のものに前記候補ＶＭがデプロイされうる複数の候補ホストコンピューティング装置（ホスト）とに関して、前記方法は、それぞれの候補ホストから利用可能なリソースと前記候補ＶＭが必要とするリソースとを考慮して、前記候補ＶＭのデプロイ先である候補ホストの判定を支援し、前記方法はそれぞれの候補ホストに対して、
    前記候補ホストから利用可能な幾つかのリソースの各々に対してサブレーティングを計算するステップであって、前記リソースに対する前記サブレーティングは、前記候補ＶＭを前記候補ホストにデプロイした後に空いているリソース量に対応するステップと、
    前記の計算したサブレーティングからレーティングを計算して、前記候補ホストがどの程度良く前記候補ＶＭを収容できるかを特徴付けるステップと
    を含み、
    前記方法はさらに、それぞれの候補ホストに対する前記レーティングをセレクタに提示するステップであって、前記セレクタは、候補ホスト上への前記候補ＶＭのデプロイ先である前記候補ホストの１つをそのレーティングに基づいて選択するステップを含むこと
    を特徴とする請求項１に記載の方法。
13. 候補ＶＭ（ｖｉｒｔｕａｌ ｍａｃｈｉｎｅ）と、前記候補ＶＭがデプロイされうる候補ホストグループとに関して、前記ホストグループはホストの集合であり、そのうち任意のものは、前記ホストグループに実際にデプロイされる場合に前記候補ＶＭを収容できることを特徴とする請求項１に記載の方法。
14. 複数の候補ＶＭと前記候補ホストとに関して、前記複数の候補ＶＭのうち任意のものは前記候補ホストにデプロイされる可能性があり、前記方法は、前記候補ホストから利用可能なリソースとそれぞれの候補ＶＭが必要とするリソースとを考慮して、前記候補ホストへデプロイすべき候補ＶＭの判定を支援し、前記方法はそれぞれの候補ＶＭに対して、
    前記候補ホストから利用可能な幾つかのリソースの各々に対してサブレーティングを計算するステップであって、前記リソースに対する前記サブレーティングは前記候補ＶＭを前記候補ホストにデプロイした後に空いているリソース量に対応するステップと、
    前記の計算したサブレーティングからレーティングを計算して、前記候補ホストがどの程度良く前記候補ＶＭを収容できるかを特徴付けるステップと
    を含み、
    前記方法は、それぞれの候補ＶＭに対する前記レーティングをセレクタに提示するステップであって、前記セレクタは、前記候補ホストにデプロイする前記候補ＶＭの１つをそのレーティングに基づいて選択するステップをさらに含むこと
    を特徴とする請求項１に記載の方法。
15. 前記候補ＶＭに仮想化されうる候補物理マシンと前記候補ＶＭがデプロイされうる前記候補ホストとに関し、前記方法は、前記候補ホストから利用可能なリソースと前記候補ＶＭが必要とするリソースとを考慮して、前記候補物理マシンを前記候補ＶＭに仮想化して前記候補ＶＭを前記候補ホストにデプロイすべきかどうかの判定を支援することを特徴とする請求項１に記載の方法。
16. 任意の特定のリソースに対するサブレーティングを前記特定のリソースに関して収集した利用データに基づいて計算するステップを含み、前記利用データは、前記候補ＶＭと任意の他のＶＭとを前記候補ホストにデプロイする間に前記候補ホストにより利用されるリソースの量を表し、
    前記利用データの時間毎サンプルである第１層内のデータを選択するステップと、
    前記時間毎データの３つの最高サンプルを平均することで、前記第１層の前記時間毎データから集計した日毎データである第２層内のデータを選択するステップと、
    前記日毎データの３つの最高サンプルを平均することで、前記第２層の前記日毎データから集計した週毎データである第３層内のデータを選択するステップと、
    前記週毎データの３つの最高サンプルを平均することで、前記第３層の前記週毎データから集計した最終値を計算するステップと
    により相対的に高い利用を重視するよう集計したサンプルデータを含むことを特徴とする請求項１に記載の方法。
17. 前記選択ホストのリソースを予約するステップは、予約ＶＭを前記選択ホストにデプロイするステップを含むことを特徴とし、前記予約ＶＭは、実体的な機能性とコンテンツを有さないが、前記候補ＶＭを前記選択ホストにデプロイするまで、前記候補ＶＭの要求に応じて前記選択ホストのリソースを保持するＶＭであることを特徴とする請求項１に記載の方法。
18. 前記候補ＶＭを別のホストにデプロイすることを特徴とし、前記候補ＶＭをデプロイするステップは、前記候補ＶＭを前記別のホストから前記選択ホストに移動するステップを含むことを特徴とする請求項１に記載の方法。
19. 候補物理マシンと前記候補物理マシンがデプロイされうる候補ホストコンピューティング装置（ホスト）とに関する方法であって、前記方法は、前記候補ホストから利用可能なリソースと前記候補物理マシンが必要とするリソースとを考慮して、前記候補物理マシンを前記候補ホストにデプロイすべきかどうかの判定を支援し、
    前記候補ホストから利用可能な幾つかのリソースの各々に対してサブレーティングを計算するステップであって、前記リソースに対する前記サブレーティングは前記候補物理マシンを前記候補ホストにデプロイした後に空いているリソース量に対応するステップと、
    前記の計算したサブレーティングからレーティングを計算して、前記候補ホストがどの程度良く前記候補物理マシンを収容できるかを特徴付けるステップと、
    前記候補ホストに対する前記レーティングをセレクタに提示するステップであって、前記セレクタは、前記候補物理マシンを前記候補ホストにデプロイすべきかどうかをそのレーティングに基づいて判定するステップと、
    候補ホスト上への前記候補ＶＭのデプロイ先である候補ホストの選択結果を受信するステップと、
    前記候補物理マシンを前記選択ホストにデプロイするまで、前記候補ＶＭによる要求に応じて、前記選択ホストのリソースを予約するステップと、
    前記候補物理マシンをその仮想化したバージョンとして前記選択ホストにデプロイするステップと
    を含むことを特徴とする方法。
20. 複数の候補物理マシンと前記候補ホストとに関し、前記複数の候補物理マシンのうち任意のものは前記候補ホストにデプロイされる可能性があり、前記方法は、前記候補ホストから利用可能なリソースとそれぞれの候補物理マシンが必要とするリソースとを考慮して、前記候補物理マシンを前記候補ホストにデプロイすべきかどうかの判定を支援し、前記方法はそれぞれの候補物理マシンに対し、
    前記候補ホストから利用可能な幾つかのリソースの各々に対してサブレーティングを計算するステップであって、前記リソースに対する前記サブレーティングは前記候補物理マシンを前記候補ホストにデプロイした後に空いているリソース量に対応するステップと、
    前記の計算したサブレーティングからレーティングを計算して、前記候補ホストがどの程度良く前記候補物理マシンを収容できるかを特徴付けるステップと
    を含み、
    前記方法は、それぞれの候補物理マシンに対する前記レーティングをセレクタに提示するステップであって、前記セレクタは、前記候補ホストにデプロイする前記候補物理マシンの１つをそのレーティングに基づいて選択するステップをさらに含むこと
    を特徴とする請求項１９に記載の方法。

Images