仮想化環境のための管理システム、方法、およびコンピュータ・プログラム
【課題】 仮想化環境のための管理システムおよび方法を提供する。
【解決手段】 この管理システムおよび方法は、資格に基づく使用制限を有するコンピュータ・エンティティを含む。プロセッサを使用し、メモリ・ストレージ・デバイス上にプログラミングされ、メモリ・ストレージ・デバイスから実行されるリソース・マネージャは仮想化環境内のリソースを管理するように構成される。資格使用率モジュールは、リソース・マネージャに結合され、仮想化環境の変化に応じて資格関連制約を追跡し、リソース・マネージャが資格関連制約を含む割り振り決定を行えるようにして、コンピュータ・エンティティについて使用制限を満たしていることを保証するように構成される。
【解決手段】 この管理システムおよび方法は、資格に基づく使用制限を有するコンピュータ・エンティティを含む。プロセッサを使用し、メモリ・ストレージ・デバイス上にプログラミングされ、メモリ・ストレージ・デバイスから実行されるリソース・マネージャは仮想化環境内のリソースを管理するように構成される。資格使用率モジュールは、リソース・マネージャに結合され、仮想化環境の変化に応じて資格関連制約を追跡し、リソース・マネージャが資格関連制約を含む割り振り決定を行えるようにして、コンピュータ・エンティティについて使用制限を満たしていることを保証するように構成される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、仮想化システム管理に関し、詳細には、仮想化環境（virtualizedenvironment）を管理する際の使用権（usage right）および使用制限（usage limitation）の理由を説明するように構成されたシステムおよび方法に関する。
【背景技術】
【０００２】
最新のエンタープライズ・ソフトウェアは、かなりの額の購入コスト、複雑なライセンス条件、ライセンス違反の場合の顧客に対する重大な罰則を伴う。伝統的に、ソフトウェアは単純にインストール済みコピーに関してライセンスされており、すなわち、顧客はインストールされたソフトウェアの各コピーごとに特定の金額を支払ってきた。したがって、顧客用のソフトウェアのコストは、顧客が使用している（または、より正確には、インストールした）コピーの数に、顧客がコピーごとに支払った価格を掛けたものである。使用されているもう１つの技法はいわゆる「ライセンス・プール」である。この技法では、顧客は現在実行しているソフトウェアのコピーについてのみ支払い、必要な数のコピーをインストールすることができるが、そのうちの非常に多くのコピーは同時に実行することができる。これらのモデルはいずれも、ワークステーション・ソフトウェア、すなわち、個々のパーソナル・コンピュータ上で実行されるソフトウェアの分野で広く使用されてきており、依然として広く使用されている。
【０００３】
最新のサーバ・ソフトウェアにはさらに複雑なライセンス条件がある。推進例として、「プロセッサ・バリュー・ユニット（Processor Value Unit）」方法またはＰＶＵについて考慮する。この手法は、インストール済みインスタンスによって単純にソフトウェアをライセンスするのではなく、顧客がそのソフトウェアから受け取る潜在的な価値を測定しようという試みに基づいてライセンスするものである。
【０００４】
ＰＶＵベースのプロダクト・ライセンシングは、そのプロダクトについて均一料金を請求するわけではない。その代わりに、プロダクトにはＰＶＵに関して値段が付けられる。ＰＶＵライセンス・プロダクトを購入するときに、顧客は、どのくらいの数のＰＶＵが必要であるかを算出し、その数に当該プロダクトのＰＶＵあたりの価格を掛ける。
【０００５】
例として、アプリケーション・サーバの表示価格はＰＶＵあたり６０ドルである。価格計算を完了するために、顧客は次に、そのプロダクトを実行する予定であるＣＰＵを調べる。各プロセッサ・タイプごとに「コアあたりのＰＶＵ」値が定義されており、それはどのくらいの数のＰＶＵを購入すべきかを顧客に示すものである。たとえば、この例の表には、すべてのプロセッサ（複数コア付き）についてコアあたりのＰＶＵ値の価格を５０としてリストされている。したがって、８つのコアを有する１台のマシン上でアプリケーション・サーバを実行したいと希望する顧客は、８＊５０＝４００ＰＶＵのアプリケーション・サーバを備える必要がある。ＰＶＵあたりのコストが６０ドルである場合、これは６０＊４００＝２４，０００ドルを要することになるであろう。
【０００６】
ＰＶＵベースのライセンシングの重要な態様の１つは、顧客がインストールし実行するアプリケーション・サーバのコピー数ではなく、そのコピーがアクセスするＰＶＵの数のみが重要であることである。たとえば、顧客はその代わりにそれぞれが４つのコアを有する２台のマシンを実行することを決定することができ、ＰＶＵ要件は依然として４００（２＊４＊５０）になるであろう。加えて、顧客は２台のマシンのそれぞれでアプリケーション・サーバの７つのコピーを実行することを決定することができ、その顧客のＰＶＵ要件は引き続き４００になるであろう。
【０００７】
この方式では、ＰＶＵはプロダクト間で交換可能ではない。ＰＶＵは、ＣＰＵタイプ間およびマシン間で交換可能である。例として、アプリケーション・サーバについて４００のＰＶＵを購入した顧客は、顧客が希望するマシンであればどのマシン上でもアプリケーション・サーバを実行することができるが、ただし、顧客は合計で４００を超えるＰＶＵを必要とするＣＰＵ上で実行しないものとする。しかし、顧客は、アプリケーション・サーバの実行を停止して、その代わりにＰＶＵ方式を使用してライセンスされた他の（第２の）ソフトウェア・プロダクトを実行することはできない。第２のソフトウェア・プロダクトのＰＶＵあたりの価格はアプリケーション・サーバの価格とは異なるので、顧客はあるプロダクトについて購入したＰＶＵを使用して他のプロダクトを実行することはできない。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
その結果として、任意の所与のシステムには様々なライセンス・プロダクトが配備されることになり、顧客はライセンスの条件の遵守を保証するために各プロダクトごとにその資格（entitlement）および使用率（usage）を追跡する必要があることが分かる。
【課題を解決するための手段】
【０００９】
仮想化環境のための管理システムおよび方法は、資格に基づく使用制限を有するコンピュータ・エンティティを含む。プロセッサを使用し、メモリ・ストレージ・デバイス上にプログラミングされ、メモリ・ストレージ・デバイスから実行されるリソース・マネージャは仮想化環境内のリソースを管理するように構成される。資格使用率モジュール（entitlement-usage module）は、リソース・マネージャに結合され、仮想化環境の変化に応じて資格関連制約を追跡し、リソース・マネージャが資格関連制約を含む割り振り決定を行えるようにして、コンピュータ・エンティティについて使用制限を満たしていることを保証するように構成される。
【００１０】
仮想化環境内のリソースを管理するための方法は、１組の資格に関する制約を表すステップと、配置すべきコンピューティング・エンティティについて、許可される資格の数およびタイプを決定するステップとを含む。結果として得られる配置ソリューションが現在使用可能な資格を超えないように、配置プログラムが進行するにつれて、現行候補配置ソリューションについて資格使用率が計算される。
【００１１】
上記その他の特徴および利点は、添付図面に関連して読むべきものである、その例示的な諸実施形態に関する以下の詳細な説明から明らかになるであろう。
【００１２】
本発明は、以下の図面に関連して好ましい諸実施形態に関する以下の説明において詳細を提供するものである。
【図面の簡単な説明】
【００１３】
【図１】仮想化環境を管理する際にライセンシング／資格を考慮するシステム／方法のブロック図／流れ図である。
【図２】本発明の原理による配置管理システムに関する例示的な例を示すブロック図である。
【図３】ライセンシング／資格を考慮しながら環境を管理するための例示的な例を示すブロック図である。
【図４】追加されたＶＭによりライセンシング／資格を考慮しながら図３の環境を管理するための他の例示的な例を示すブロック図である。
【図５】ＰＶＵ共用によりライセンシング／資格を考慮しながら図４の環境を管理するための他の例示的な例を示すブロック図である。
【図６】追加されたＶＭの配置位置を考慮しながら図３の環境を管理するための他の例示的な例を示すブロック図である。
【図７】ＰＶＵ共用により追加されたＶＭの配置位置を考慮しながら図４の環境を管理するための他の例示的な例を示すブロック図である。
【図８】一実施形態によりコンピュータ・エンティティと資格のバンドルとの関係を示すモデル構成体のブロック図である。
【図９】例示的な一実施形態によりライセンシング／資格を考慮する配置方法を示すブロック図／流れ図である。
【図１０】他の例示的な実施形態によりライセンシング／資格を考慮する他の配置方法を示すブロック図／流れ図である。
【発明を実施するための形態】
【００１４】
本発明の原理により、仮想化環境の統合管理のためのシステムおよび方法が提供される。特に有用な諸実施形態では、管理システムは、ライセンス認識（license awareness）を含み、この認識をその決定およびアクションに使用する。たとえば、管理システムが新しい仮想計算機を配備し、既存の仮想計算機をあちらこちらにマイグレーションすることができる場合、ライセンス認識を含むことの利益はさらに重大なものになる。
【００１５】
仮想化とは、コンピューティング・リソースを抽象的なものにする能力を指す一般的用語である。この実施形態は、コンピュータ・システム（たとえば、ストレージまたはネットワークも使用できるが、これらとは対照的なもの）の仮想化を含む、プラットフォーム仮想化に含めることができる。あるタイプの仮想化は完全仮想化であり、その場合、通常は分離された複数のオペレーティング・システム・インスタンスを単一コンピュータ上で実行することができる。その他のタイプの仮想化、たとえば、オペレーティング・システム・レベルの仮想化も含まれ、その場合、単一オペレーティング・システム内に通常は分離された複数の空間が提示され、その内部でプログラムが実行される。
【００１６】
完全仮想化の例としては、いくつか例を挙げると、ＩＢＭ（Ｒ）のＤＬＰＡＲ（ｐＳｅｒｉｅｓおよびｚＳｅｒｉｅｓ上）、ＩＢＭ（Ｒ）のｚ／ＶＭ、ＶＭｗａｒｅ（Ｒ）のプロダクト・ファミリー、Ｃｉｔｒｉｘ（Ｒ）のＸｅｎＳｅｒｖｅｒおよびＸｅｎ、Ｌｉｎｕｘ（ＴＭ）のＫＶＭを含む。「オペレーティング・システム・レベルの仮想化」の一般的な例としては、ＡＩＸオペレーティング・システム用のＩＢＭ（Ｒ）のＷＰＡＲ、Ｓｕｎ（Ｒ）のＳｏｌａｒｉｓ Ｃｏｎｔａｉｎｅｒ、Ｌｉｎｕｘ（ＴＭ）のＶＳｅｒｖｅｒを含む。
【００１７】
仮想計算機は、たとえば、オペレーティング・システム・インスタンス（完全仮想化の場合）または空間（オペレーティング・システム・レベルの仮想化の場合）のいずれかを参照することができる。仮想化の関連態様の１つは、ＣＰＵ割り振りを制御する能力である。たとえば、単一の物理マシン上で複数の仮想計算機を実行する場合、それぞれの仮想計算機がアクセスできる、物理マシン内のＣＰＵ（または物理ＣＰＵ）およびその数を制限することは可能である。
【００１８】
たとえば、８つのプロセッサ・コアを有する単一の物理マシンについて考慮する。この物理マシンは３つの仮想計算機を実行することができ、そのうちの第１の仮想計算機は２つの仮想ＣＰＵを有し、第２の仮想計算機は４つの仮想ＣＰＵを有し、第３の仮想計算機は８つの仮想ＣＰＵを有する。仮想計算機内部で実行されるソフトウェアは、仮想計算機がアクセスできるＣＰＵの数に等しくすることができる。
【００１９】
他の態様はライブ・マイグレーション（パーティション・モビリティおよびマイグレーションとも呼ばれる）を含む。これは、サービスを中断せずに仮想計算機をある物理マシンから他の物理マシンに移動する能力を指す。
【００２０】
仮想化とソフトウェア・ライセンシングとの共通部分は、ＰＶＵタイプのライセンシングと仮想化を結合することができる。上記の仮想計算機の例と以前のアプリケーション・サーバの例を結合すると、顧客は元の４００ＰＶＵ要件について３つの仮想計算機すべてでアプリケーション・サーバを実行することを許可されるはずである。８つの物理コアがすべて使用されるので、８つすべてをライセンスしなければならない。単一マシン上でアプリケーション・サーバの複数のコピーを実行してもライセンス要件は変更されず、個別の仮想計算機内で異なるインスタンスが実行されるということは、このライセンシング方式では関連性はない。換言すれば、このマシン上でアプリケーション・サーバを実行するために顧客が購入する必要がある最も多いＰＶＵは４００であり、いくつのインスタンスまたは仮想計算機が稼働中であるかは重要ではない。
【００２１】
ＰＶＵの共用について考慮する。この事例では、８つの仮想ＣＰＵである仮想計算機がまず作成される。その後、４つの仮想ＣＰＵと２つの仮想ＣＰＵである仮想計算機が作成される。第２の２つのＶＭについては追加のライセンスが不要であるので、それらは、第１の仮想計算機を作成するために必要であったライセンスを「共用」する。しかし、第１の仮想計算機については特別なことは何もなく、この例では、単に最初に作成されたものであり、物理コアをライセンスする必要性が促進された。次の２つの仮想計算機を配備するために追加のライセンスは一切不要である。
【００２２】
たとえば、顧客が第１の仮想計算機（２つの仮想ＣＰＵを有するもの）でアプリケーション・サーバを実行するだけである場合など、顧客が４００未満のＰＶＵを必要とする場合がある。この場合、顧客は１００ＰＶＵのみ（２つの物理コアのそれぞれについて５０ずつ）を必要とする。このプラットフォーム上のこのタイプのライセンシングでは、顧客は仮想ＣＰＵの合計または物理コアの数のうちの少ない方に十分なＰＶＵを有する必要がある。明瞭にするために詳細が省略されているので、ＰＶＵタイプのライセンシングの上記の説明は制限するためのものではなく、クラスタ化およびその他のプラットフォーム・タイプの問題は完全に除外されていることを理解されたい。上記の説明は、単に本発明の原理を実装できる環境を例証するためのものである。加えて、他のソフトウェア・プロバイダは他のライセンシング方式を有する。しかし、そのうちのいくつかは、上記のＰＶＵベースの方式と同様の態様を有する。
【００２３】
仮想化がエンドユーザ・データ・センタでますます普及するにつれて、仮想化管理がより重要なものになる。性能管理、高可用性、および省電力の分野では、大幅な進歩が見られた。しかし、顧客に重大な利益をもたらすのに無視されてきた領域はライセンス管理である。とりわけ、その他の管理関心事とともにライセンス管理を考慮する能力は特に有用である。配備およびマイグレーションのいずれも、任意の所与の時点でシステムが使用するライセンスの数を変更する可能性がある。たとえば、上記で使用した３つの仮想計算機のケースについてもう一度考慮するが、初めにその上にいかなる仮想計算機も配備されていない第２の物理マシンを導入する。第１の物理マシンから第２の物理マシンに仮想計算機をマイグレーションすると、システム全体をライセンスするのに必要なＰＶＵの数が増加することになり、以前あったものより多くの物理コアがアプリケーション・サーバを実行していることが理解できるであろう。配備およびマイグレーションを伴う多数の他のケースも引用できるであろう。
【００２４】
本発明の原理によれば、統合管理システムはライセンス認識機能を含む。管理システムが新しい仮想計算機を配備するか、あるいは既存の仮想計算機をあちらこちらにマイグレーションするか、またはその両方を行うことができる場合、決定を行うかまたはこのようなアクションを実行する際にライセンス認識が考慮される。このシステムは、他の管理考慮事項に加えてライセンス要件を考慮する。
【００２５】
本発明全体を通して、単一の顧客に言及するが、この実施形態は、インフラストラクチャを共用する個別のライセンスを有する１組の顧客に等しく適用可能である。この実施形態によって提供されるいくつかの特徴としては以下のものを含む。すなわち、現在の顧客のソフトウェア・プロダクトについて、情報、ライセンス資格、および対応するライセンス・タイプを尋ねるために、システム管理者から情報を引き出すか、またはソフトウェア供給業者に電子的に接触することなど、１つまたは複数のメカニズムにより入手することである。これらのライセンス資格およびライセンス・ルールは、現在のライセンス使用率を計算できるように、管理されているインフラストラクチャに関する十分な情報を収集するために考慮に入れられる。この情報は、システム内の様々な物理マシンの数および特性、現在配備されている仮想計算機の数および特性（適用可能な場合）、どのソフトウェア・プロダクトがインストールされ、それがどこにインストールされているかに関する情報を含むが、これらに限定されない。
【００２６】
管理中のシステムに対する潜在的な変更について考慮すると、この実施形態は、そのシステムに対するその変更の効果を（必要なライセンスに関して）計算することができ、その他のシステムレベルの影響（たとえば、性能、可用性、消費電力などを含む）に加えて、ライセンス要件に対するその影響に関して種々の組の潜在的変更を評価する。この実施形態は、顧客のライセンス資格内にシステムを保持するように、システムに対して行う１組の変更を選択することができる。これが不可能である場合、システムをオーバライドするための様々な手法が可能である。一実施形態では、システムはライセンス資格をオーバライドすることができない。他の実施形態では、システムはそのようにオーバライドすることができるが、システム管理者の許可がある場合に限られる。また、その他の実施形態も可能である。
【００２７】
一例では、データ・センタは１００台の物理マシンを含む。すべてのライセンス・プロダクトを同じ物理マシン上に配置し、他のものはいずれも使用しないことにより、ライセンス使用率を最小限にすることができる（このような手法は消費電力に対して有益な効果をもたらすであろう）。しかし、単一物理マシンのリソースはすべてのライセンス・プロダクトを十分に処理するためには不十分であるので、システムの性能はおそらく悪化するであろう。このようなソリューションは可用性に対して否定的な影響も及ぼすので、その単一マシンが故障すると、あらゆるものが故障することになる。
【００２８】
当業者であれば分かるように、本発明の諸態様はシステム、方法、またはコンピュータ・プログラム（computer program product）として実施することができる。したがって、本発明の諸態様は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）、またはハードウェアとソフトウェアの態様を結合する実施形態の形を取ることができ、いずれも一般に本明細書で「回路」、「モジュール」、または「システム」と呼ぶことができる。さらに、本発明の諸態様は、そこにコンピュータ可読プログラム・コードが実施されている１つまたは複数のコンピュータ可読媒体（複数も可）で実施されたコンピュータ・プログラムの形を取ることができる。
【００２９】
１つまたは複数のコンピュータ可読媒体（複数も可）の任意の組み合わせを使用することができる。コンピュータ可読媒体は、コンピュータ可読信号媒体またはコンピュータ可読記憶媒体にすることができる。コンピュータ可読記憶媒体は、たとえば、電子、磁気、光、電磁、赤外線、または半導体のシステム、装置、またはデバイス、もしくは上記のものの任意の適切な組み合わせにすることができるが、これらに限定されない。コンピュータ可読記憶媒体のより具体的な例（非網羅的なリスト）としては、１つまたは複数のワイヤを有する電気接続、ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、消去可能プログラマブル読み取り専用メモリ（ＥＰＲＯＭまたはフラッシュ・メモリ）、光ファイバ、ポータブル・コンパクト・ディスク読み取り専用メモリ（ＣＤ−ＲＯＭ）、光ディスク・ストレージ・デバイス、磁気ディスク・ストレージ・デバイス、または上記のものの任意の適切な組み合わせを含むことになるであろう。本明細書に関しては、コンピュータ可読記憶媒体は、命令実行システム、装置、またはデバイスによりあるいはそれに関連して使用するためのプログラムを収容または保管することができる任意の有形媒体にすることができる。
【００３０】
コンピュータ可読信号媒体は、たとえば、ベースバンド内でまたは搬送波の一部として、コンピュータ可読プログラム・コードがそこに実施されている伝搬データ信号を含むことができる。このような伝搬信号は、電磁、光、またはそれらの任意の適切な組み合わせを含むがこれらに限定されない様々な形のうちのいずれかを取ることができる。コンピュータ可読信号媒体は、コンピュータ可読記憶媒体ではないが、命令実行システム、装置、またはデバイスによりあるいはそれに関連して使用するためのプログラムを通信、伝搬、または伝送することができる任意のコンピュータ可読媒体にすることができる。コンピュータ可読媒体上に実施されたプログラム・コードは、無線、有線、光ファイバ・ケーブル、ＲＦなど、または上記のものの任意の適切な組み合わせ含むがこれらに限定されない任意の適切な媒体を使用して伝送することができる。
【００３１】
本発明の諸態様の動作を実行するためのコンピュータ・プログラム・コードは、Ｊａｖａ、Ｓｍａｌｌｔａｌｋ、Ｃ＋＋などのオブジェクト指向プログラミング言語ならびに「Ｃ」プログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語を含む、１つまたは複数のプログラミング言語の任意の組み合わせで作成することができる。このプログラム・コードは、完全にユーザのコンピュータ上で、部分的にユーザのコンピュータ上で、スタンドアロン・ソフトウェア・パッケージとして、部分的にユーザのコンピュータ上でかつ部分的にリモート・コンピュータ上で、あるいは完全にリモート・コンピュータまたはサーバ上で、実行することができる。後者のシナリオでは、リモート・コンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ）または広域ネットワーク（ＷＡＮ）を含む任意のタイプのネットワークにより、ユーザのコンピュータに接続される場合もあれば、（たとえば、インターネット・サービス・プロバイダを使用してインターネットにより）外部コンピュータに対して接続が行われる場合もある。
【００３２】
本発明の諸態様については、本発明の諸実施形態による方法、装置（システム）、およびコンピュータ・プログラムの流れ図あるいはブロック図またはその両方に関連して以下に説明する。流れ図あるいはブロック図またはその両方の各ブロックならびに流れ図あるいはブロック図またはその両方の複数ブロックの組み合わせは、コンピュータ・プログラム命令によって実装することができることが理解されるであろう。これらのコンピュータ・プログラム命令を汎用コンピュータ、特殊目的コンピュータ、またはその他のプログラマブル・データ処理装置のプロセッサに提供し、そのコンピュータまたはその他のプログラマブル・データ処理装置のプロセッサを介して実行された命令が流れ図あるいはブロック図またはその両方の１つまたは複数のブロックに指定された機能／動作を実装するための手段を作成するようなマシンを生産することができる。
【００３３】
また、これらのコンピュータ・プログラム命令は、コンピュータ可読媒体に保管された命令が、流れ図あるいはブロック図またはその両方の１つまたは複数のブロックに指定された機能／動作を実装する命令を含む装置（article of manufacture）を生産するような特定の方法で機能するよう、コンピュータ、その他のプログラマブル・データ処理装置、またはその他のデバイスに指示することができるコンピュータ可読媒体に保管することもできる。
【００３４】
または、これらのコンピュータ・プログラム命令は、コンピュータ、その他のプログラマブル装置、またはその他のデバイス上で一連の動作ステップを実行させて、コンピュータまたはその他のプログラマブル装置上で実行された命令が流れ図あるいはブロック図またはその両方の１つまたは複数のブロックに指定された機能／動作を実装するためのプロセスを提供するようなコンピュータ実装プロセスを生成するために、コンピュータ、その他のプログラマブル・データ処理装置、またはその他のデバイス上にロードすることもできる。
【００３５】
図面内の流れ図およびブロック図は、本発明の様々な諸実施形態によるシステム、方法、およびコンピュータ・プログラムについて可能な実装例のアーキテクチャ、機能、および動作を例示している。この点に関しては、流れ図またはブロック図内の各ブロックは、指定の論理機能（複数も可）を実装するための１つまたは複数の実行可能命令を含む、コードのモジュール、セグメント、または一部分を表すことができる。また、いくつかの代替実装例では、ブロック内に示された機能は図面内に示された順序から外れて行われる可能性があることにも留意されたい。たとえば、連続して示されている２つのブロックは、関係する機能に応じて、実際にはほぼ同時に実行される場合もあれば、ときには逆の順序で実行される場合もある。また、ブロック図あるいは流れ図またはその両方の各ブロックならびにブロック図あるいは流れ図またはその両方の複数ブロックの組み合わせは、指定の機能または動作を実行する特殊目的ハードウェアベースのシステムによって、または特殊目的ハードウェアとコンピュータ命令の組み合わせによって、実装可能であることも留意されるであろう。
【００３６】
次に、同様の番号が同じかまたは同様の要素を表している図面を参照し、初めに図１を参照すると、仮想化環境において統合管理を提供するために使用権、制限、および制約を考慮に入れるシステム１０１が例示的に描写されている。システム１０１は、物理マシン１０２、１０４と、仮想計算機（ＶＭ）１０６と、リソース・マネージャ１１０と、ライセンシング／資格制約管理モジュール１１２と、ストレージ・リソース・マネージャ１１４とを有する仮想環境を例示的に含む。システム１０１は、コンピュータ・アーチファクトまたはエンティティの供給、変更、実行、マイグレーションなどが行われる、データ・センタ環境、ネットワーク環境、または任意のその他のコンピュータ環境を含むことができる。コンピュータ・アーチファクトまたはエンティティは仮想計算機（ＶＭ）を含むことができる。仮想計算機は、この例示的なシステム説明のために例示的に使用される。アプリケーションまたは他の計算エンティティも同様に使用できることを理解されたい。
【００３７】
アプリケーション１１６は個々のＶＭ１０６によって処理され、物理マシン１０２、１０４は複数のＶＭ１０６を処理することができる。各ＶＭ１０６は、ブート時にＶＭ１０６に割り振られたリソース（ネットワーク、メモリ、およびＣＰＵ）の一部分を有し、同じ物理マシン１０２、１０４内で共同処理（co-host）される他のＶＭ１０６とリソースを共用する。物理マシンは複数のＶＭ１０６を処理することができる。ＶＭ１０６は、他の物理マシンまたは環境にマイグレーションすることができる。
【００３８】
ストレージ・リソース・マネージャ１１４は、システム１０１内のストレージ間でストレージ使用率をモニターする役割を担う。リソース・マネージャ１１０は、仮想計算機１０６の配置または再位置決め（マイグレーション）および再供給に関する決定を行う役割を担い、必要なときに、たとえば、潜在的な再位置決めのためにＶＭ１０６が選択されたときに、モジュール１１２およびストレージ・リソース・マネージャ１１４と調整する。配置とは、所与の仮想計算機が所与の時点にどこで実行しなければならないかという決定を指す。
【００３９】
配置決定は、複数の異なる考慮事項に基づいて行うことができる。たとえば、仮想計算機の性能を意識した配置ではＶＭ配置の結果として性能利得を考慮し、仮想計算機の制約を意識した配置は制約に基づくものである。制約を意識した決定は、割り振り制限（たとえば、「これを特定の位置に配置してはならない」、「これは位置ｘ、ｙ、ｚのみに移動することができる」）およびコロケーション制限（「これはそれと共存できない」、「これはいずれとも共存できない」など）を考慮することができる。ライセンスを意識した配置は、性能を意識した配置あるいは制約を意識した配置またはその両方に含めることができる。仮想計算機の初期配備では、配備時に追加の貢献を考慮することができる。たとえば、ネットワーク接続、ストレージの可用性などである。
【００４０】
リソース・マネージャ１１０およびハイパーバイザ１２０は、ＶＭストレージ、マイグレーション、アプリケーション実行、およびその他の管理機能を管理する際に使用される。ライセンシング制約管理モジュール１１２は、リソース・マネージャ１１０およびハイパーバイザ１２０のうちの一方または両方と統合することができる。マイグレーション中に、システム１０１は以下の例示的な機能を実行する。すなわち、（１）リソース・マネージャ１１０はマイグレーションまたは再供給のためにＶＭ１０６を指定する。（２）リソース・マネージャ１１０はライセンシング制約管理モジュール１１２を調査して、ＶＭ１０６をその現在の位置から新しい位置に移動するときに制約が存在するかどうかを判断する。これは、新しい位置への移動または古い位置からの移動を防止するための制約が存在するかどうかを判断することを含む。ライセンシング制約管理モジュール１１２は、サービス・レベル・アグリーメント（ＳＬＡ）、ライセンス契約、著作権情報などから得られる可能性のある制約情報を保管する。有用な諸実施形態によれば、ライセンシング制約管理モジュール１１２は、リソースの変更に関する決定プロセスの一部としてリソース・マネージャ１１０によって調査される。ライセンシング制約管理モジュール１１２は、各資格タイプの現行レベルの使用率を呼び出し側に提供することができる。
【００４１】
リソース・マネージャ１１０は、その決定にライセンス認識を含む管理システムを提供する。管理システムが新しい仮想計算機（１０６）を配備するか、既存の仮想計算機（１０６）をあちらこちらにマイグレーションするか、アプリケーションまたはＶＭを実行するか、あるいはＶＭ（１０６）を再供給するか、またはこれらの組み合わせを行うと、ライセンス認識が重要になり、管理システムは他の管理考慮事項に加えてライセンス（およびその他の使用制約）について考慮する。システム１０１のライセンシング制約管理モジュール１１２は、競合する制約に優先順位を付ける能力をさらに含む。
【００４２】
ライセンシング制約管理モジュール１１２は、現在の顧客のソフトウェア・プロダクトについて、情報、ライセンス資格、対応するライセンス・タイプなどを尋ねるために、システム管理者から情報を引き出すこと、ソフトウェア供給業者に電子的に接触することを含む、様々なメカニズムを使用して、資格データを入手する。リソース・マネージャ１１０（あるいはライセンシング制約管理モジュール１１２またはその両方）は、ライセンス資格およびライセンス・ルールの理由を説明し、現在のライセンス使用率を計算できるように、管理されているインフラストラクチャに関する十分な情報を収集する。この情報は、たとえば、システム１０１内の物理マシン１０２、１０４の数および特性、現在配備されている仮想計算機１０６の数および特性（適用可能な場合）、どのソフトウェア・プロダクトがインストールされているかならびにその位置に関する情報などを含むが、これらに限定されない。
【００４３】
管理中のシステムに対する潜在的な変更について考慮すると、そのシステムに対するその変更について、このような変更の効果を（必要なライセンスなどに関して）計算する必要がある。その他のシステムレベルの影響（たとえば、性能、可用性、消費電力などを含む）に加えて、ライセンス要件に対するその影響に関して種々の組の潜在的変更を評価することができる。システムが顧客のライセンス資格内に保持されることを保証することができる１組の変更が選択される。これが不可能である場合、システムをオーバライドするための様々な手法が可能であるか、またはライセンス契約の精神に従う最良のソリューションを選択することができる。一実施形態では、システムはライセンス資格をオーバライドすることができない。他の実施形態では、システムはそのようにオーバライドすることができるが、システム管理者の許可がある場合に限られる。また、その他の実施形態も可能である。
【００４４】
仮想化環境に関するプロダクト・ライセンス・ルールは複雑な場合が多い。最近では、インストールされたコピーの数に基づくのではなく、プロダクトがどの程度の作業を実行できるかに基づいて、プロダクトの料金を請求する場合がある。その結果、ライセンス使用率は、プロダクトのインストールされたコピーがどのように物理ハードウェア上に配置されるかによって決まる。仮想化環境に対処するための例示的な例として、プロセッサ・バリュー・ユニット（ＰＶＵ）が使用される。ＰＶＵのスコアによって、特定のプロセッサ・タイプのライセンス・コストは決定される。プロダクトが使用するプロセッサごとに支払いを行わなければならない。同じプロダクトの複数のコピーが使用する１つのプロセッサについては、１回だけ支払えば良い。あるプロダクトが１つのプロセッサを使用できるＶＭにインストールされると、そのプロセッサはそのプロダクトによって使用され、停止されたプロダクトおよび停止されたＶＭは使用率としてカウントされる。グリニッジ標準時の午前０時に始まる２４時間の期間ごとにあるプロダクトによって使用される各プロセッサがカウントされ、ＶＭマイグレーションはＰＶＵ使用率に影響し、ＶＭｗａｒｅに関する特殊なクラスタ化ルールは、分散リソース・スケジューリング（ＤＲＳ：Distributed Resource Scheduling）が使用されているときに（しかし、そのときに限られる）過剰請求を防止する。
【００４５】
図２を参照すると、配置システム１８０は図１の制約マネージャ１１２内に含まれている。資格使用率を決定するためには、配置システム１８０がすべての可能な配置についてすべての資格の現行使用率を計算できることが必要である。加えて、配置システム１８０は、その配置に対して特定の変更を行うためにこれらの資格使用率に対する効果を計算できることも必要である。本明細書に記載されているライセンス資格、より具体的には（説明のみのために）ＰＶＵライセンスを一例に挙げると、配置システム１８０は、各物理マシン（１０４）上の物理コアの数、これらの物理コアのそれぞれのＰＶＵの「点数」、各仮想計算機内の各プロダクトがアクセスできる仮想コアの数、各仮想計算機内のプロダクト（複数も可）という情報を把握する必要がある。
【００４６】
この情報が与えられると、配置システム１８０は、任意の時点で、仮想計算機の所与の配置が消費する資格の数を計算することができる。したがって、配置ルーチンが進行するにつれて、すべてのステップで使用された各資格の量を再計算できることが分かる。さらに、配置ルーチンが変更を行うことを考慮する場合、そのルーチンは、その変更がシステム内の一つ一つの資格について及ぼすと思われる効果を計算することができる。
【００４７】
システム１８０を実装するために、必要な情報を決定するためのセンサが実装される。物理マシン（ＰＭ）センサ１８２は物理マシン（１０４）の特性を検出し、その物理マシンは次に、所与のプロセッサ・タイプおよび数量に関するＰＶＵの「点数」を把握しているソフトウェア・コンポーネント（たとえば、データベース）またはＰＶＵエキスパート１８４と結合される。仮想計算機（ＶＭ）センサ１８６は仮想計算機に関する情報を提供し、プロダクト・センサ１８８はインストールされたプロダクトおよびそのライセンス条件に関する情報を提供する。配置システム１８０は、この情報およびその他の必要なデータの収集をサポートするために拡張された変更済みＰＭセンサ１８２およびＶＭセンサ１８６を含むことができる。
【００４８】
配置システム１８０は、（センサからの）システム・データを配置実行器（placementexecutor）１９０内の標準形に伝達し、配置システムの関心事をセンサの特定の実装例から分離する。配置実行器１９０は次に、どの変更を行うかについて決定を行いながら、その標準形を検査することになる。この標準形は、本明細書に記載されている通り、資格のバケット（ＢｏＥ：Buckets of Entitlement）などを含むことになる。
【００４９】
加えて、システム１８０の実装例は、時間の経過につれてシステムの進行中の最適化および管理を含む。センサ（１８２、１８６、１８８）からのイベントは、現行配置を再評価するよう配置システム１８０をトリガすることになる。これらのイベントとしては、資格要件または資格可用性に対する変更を含むことになる。
【００５０】
図３を参照すると、本発明の原理による概念を実証するために簡易化したＰＶＵシステム２００が描写されている。４台の物理マシン（ＰＭ）２０２はそれぞれ、４つの物理コンピュータ処理装置（ｐＣＰＵ）２０４を含む。それぞれのｐＣＰＵ２０４は、たとえば、５０ＰＶＵを含む。すべてのＶＭ２０６および２０７は２つのｖＣＰＵ２０８を含む。図２では、３つのＶＭ２０６がアプリケーション・サーバ（ＡＳ）アプリケーション、たとえば、ＩＢＭ（Ｒ）のＷｅｂｓｐｈｅｒｅ Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒ（ＴＭ）を実行し、１つのＶＭ２０７がデータベース（ＤＢ）アプリケーション（たとえば、ＩＢＭ（Ｒ）のＤＢ２（ＴＭ））を実行する。それぞれのＶＭ２０６が２つのｐＣＰＵ２０４を使用するので（それぞれ２×５０＝１００）、アプリケーション・サーバ・アプリケーション（ＡＳ）のＰＶＵ使用率は３００である。それぞれのＶＭ２０７は２つのｐＣＰＵ２０４を使用するので（それぞれ２×５０＝１００）、データベース・アプリケーション（ＤＢ）のＰＶＵ使用率は１００である。
【００５１】
図４では、第４のＶＭ２０６’がアプリケーション・サーバ・アプリケーションを実行し、このアプリケーションのためのＰＶＵ消費が３００から４００に増加する。図５では、新しいＶＭ２０９が作成され、同じマシンおよびＣＰＵを共用することによる恩恵を受ける。すでにＰＶＵカウントにカウントされているプロセッサ上にＶＭ２０９を含めることにより、追加のＰＶＵ消費はまったく発生しない。
【００５２】
もう一度、図３を参照して、顧客が４００ＰＶＵのＡＳアプリケーションを購入したとする。セットアップ時（またはその他の時点）にシステム１０１の強制モード（enforcement mode）中に、ライセンス・モジュール１１２またはリソース・マネージャ１１０（図１）は遵守をチェックする。４００ＰＶＵが使用率について提案されているが、このシナリオでは、ＤＢ用に１００が使用されており、顧客はＤＢアプリケーションの使用を認可されていないものと想定する。この場合、違反が存在する。システム１０１（図１）は、顧客に接触し、１００ＰＶＵのＤＢアプリケーションについてその顧客をサインアップするかまたは単に現行のライセンス契約書の下でそのアプリケーションが使用不能であるという警告を送出することができる。一実施形態では、強制モードは、資格を遵守していることを保証するためにＤＢアプリケーションの無許可使用を遮断することになるであろう。
【００５３】
図６では、図３の構成により新しいＶＭ２０９（図５と同様）の追加が可能になるが、ＶＭ２０９の配置には選択肢が存在する。ＶＭ２０９用として４つの位置２１２が存在する。いずれの位置でも結果的に４００というＡＳ ＰＶＵ消費になり、すべての配置が有効である。しかし、ＶＭ２０９の配置はそれぞれの位置２１２にあるものであり、その配置はそれぞれの場合に応じて同等ではないものとなる。管理決定は、ＶＭ２０９の最良の位置を決定するための性能ベースの配置など、追加の基準を含むことができる。
【００５４】
一例では、ＶＭ２０９に加えて、他のＶＭ（図示せず）をＡＳ用に配置する必要がある場合、ＰＶＵ限界４００を超えることになるので、それは不可能である。すべてのオプションがＡＳ ＰＶＵ限界に違反するので、新しいＶＭを配置することはできない。顧客は、ＡＳアプリケーションについてより多くのＰＶＵをサインアップすることができるかまたはその他のアクションを取ることができるであろう。もう１つのシナリオはこの問題を解決することができる。図７に描写されている通り、第１の新しいＶＭ２０９は４つの位置２１２のうちの１つの第１のＰＭ２０２（左端のＰＭ）上に配置され、新しいＶＭ２１１はＰＶＵ共用をトリガするように配置することができる（図５を参照）。このようにして、ＡＳ用のＰＶＵは４００というＰＶＵ限界より下に維持され、余分なＶＭ２１１に対応する。
【００５５】
もう１つの例では、１つのＰＭ２０２だけがＰＶＵ共用に使用可能である。ＰＶＵ遵守を保証し、性能のバランスを取るために、ＶＭのマイグレーションを使用することができる。たとえば、リソースを共用し、ＰＶＵ消費を回避するために、ＰＭ２０２を完全に占有することができる。
【００５６】
ＶＭを移動すると、２４時間ルールに問題を引き起こす可能性がある。任意のＰＭ２０２が２４時間の期間内に使用中である場合、ＰＶＵによる支払いがなされなければならない。たとえば、２つのＡＳ ＶＭが存在する。一方のＶＭは午前０時に実行されて午前６時に破壊され、第２のＶＭは正午に作成されて午後６時に破壊される。任意の時点で１００ＰＶＵのみが使用中であっても、このシナリオのＰＶＵ消費は２００になる。ライセンス圧縮を回避するために、２４時間ルールが存在する。したがって、ＶＭをマイグレーションすることは、追加のコストを含む可能性がある。これは、特殊なＰＶＵカウント・ルールを使用して対処することができる。このようなルールは、資格遵守を保証し、使用率を最適化するために、制約として入力し、本発明の原理により使用することができる。
【００５７】
上記の通り、もう１つの例では、所与の日の使用率は２４時間ルールの下で２００ＰＶＵになる。新しいＶＭがまったく配置されない場合、ＶＭが解任されると次の日の使用率はゼロになる。しかし、ＩＢＭ（Ｒ）ライセンス・メトリック・ツール（ＩＬＭＴ）は、クライアントが自分の全容量および仮想化容量（副容量）を決定するのを支援するものであり、ＰＶＵライセンス要件（またはその他のＰＶＵメトリック・ツール）は、ＶＭが解任されたことを把握していない。このようなツールは、たとえば、何も変化していないものと想定して、４週間カウントし続けることになる。また、これは、本発明の原理によるライセンスを意識した配置を使用して対処することもできる。
【００５８】
図８を参照すると、アプリケーション、仮想計算機、コンピュータ・エンティティなどについてライセンスを意識した配置を行うために、モジュール１１２（およびシステム１８０）によりモデリング構成体３０２を使用することができる。ＶＭ配置はソフトウェア・ライセンス使用率に影響を及ぼす。ソフトウェア・ライセンス料は、ソフトウェアがインストールされたマシンのタイプおよび容量、ならびにソフトウェア・インスタンスに対するリソースの可用性によって決まる。動的配置は、ソフトウェア・ライセンス・ルールの違反を招く可能性がある。例示的な一実施形態によれば、構成体３０２は、接続による関係を定義し、ソフトウェア・コンポーネントのソフトウェア・ライセンス条件を取り込む。それぞれのＶＭ／アプリケーション３０６およびコンテナ３０８は、１つまたは複数の資格のバケット（ＢｏＥ）３０４に関連付けられている。ＢｏＥ３０４は、ライセンス容量およびライセンス使用率の計算ルールを含み、その他の種類の制限もモデリングするために使用することができる。ライセンス条件のタイプは、全容量ベースであるか、副容量ベースであるか、インスタンスの数に基づくか、物理マシンの数などに基づくことができる。
【００５９】
ライセンスを意識した配置によってモニターされる環境には、１つまたは複数のトポロジ３１０が含まれる。トポロジ３１０は、ＶＭ／アプリケーション３０６およびコンテナ３０８に関する構造を提供する。トポロジ３１０、ＶＭ／アプリケーション３０６、およびコンテナ３０８はいずれも、リソース・マネージャ（１１０、図１）によって処理されるリソース要件を有し、性能、システム管理、ライセンスなどに関連する可能性のある制約を含むことができる。
【００６０】
ＢｏＥ３０４は、トポロジ作成時に定義され、配備時に配置システムに提供される。ＢｏＥ３０４は、アプリケーション・モニターを使用して、実行時に検出することができる。ある手法では、ＶＭイメージ３０６はＢｏＥ３０４に関連付けられる。新しいソフトウェアがＶＭにインストールされると、ユーザによって新しいＢｏＥを定義することができる。配置方法（たとえば、図９および図１０を参照）は、（たとえば、強制モードで）ＢｏＥ３０４を超えないことを保証する。一実施形態では、動作モードとしては、ライセンス条件を決して超えない強制モードを含むことができる。他のモードとしては警告モードを含むことができ、たとえば、強制によって性能の低下を招くかどうかをユーザに尋ねるか、または強制によってトポロジの配備が妨げられるかどうかをユーザに尋ねることができる。その他のモードは、特定のシステムに基づいて適合させることができる。
【００６１】
モデリング概念３０２により、有利なことに、配置制約３１４に汎用拡張を追加することができる。これにより、その制約が容易に識別可能になる。資格は、単一マシンまたはアプリケーションに関する制約より複雑な制約３１４の表現を可能にし、すなわち、資格制限は複数のアプリケーションなどにまたがる可能性がある。資格はアーチファクト間で共用することができる。有利なことに、種々のタイプのライセンスについて、また種々のタイプの複雑な制約についても、将来、追加の実装例をサポートするように、配置問題の表現に資格が追加される。
【００６２】
資格プロバイダまたはＢｏＥ３０４は、所与の資格のうちのいくつが使用可能であるか、その資格のうちのいくつが現在使用中であるかを計算する方法、示唆された変更が資格使用率に対してどのような影響を及ぼすかを計算する方法の表現を含むことができる。ＢｏＥ３０４は、公式、要件を含むルックアップ・テーブル、プログラム論理などを含むことができる。配置問題では、資格クライアント３１２は既存のアーチファクト（たとえば、アプリケーション／ＶＭ３０６、コンテナ３０８など）に結びつけられる。単一の資格クライアント３１２は、そのアーチファクトを単一の資格プロバイダ３０４に結びつけ、プロバイダが全体的な使用率を計算するのを支援するためにアーチファクトごとの使用率情報を伝達する。
【００６３】
図９を参照すると、一実施形態により資格を含む模範的な配置方法が示されている。ブロック４０２では、初期配置のために、変更が提案され、計算される。ブロック４０４では、配置ソリューションが改善されたかどうかについて判断が行われる。改善がまったくない場合、最後の最良ソリューションがブロック４０６の出力になる。改善が達成された場合、ブロック４０８で資格違反を回避するために配置ソリューションが変更される。ブロック４１０で十分な時間がある場合、この方法はもう一度繰り返し、ブロック４０２に戻る。十分な時間がない場合、この方法はブロック４０６に移行する。
【００６４】
図１０を参照すると、他の実施形態により資格を含む模範的な配置方法が示されている。ブロック４１２では、初期配置のために、内部で資格を考慮して、候補配置からの変更が計算される。ブロック４１４では、配置ソリューションが十分に改善されたかどうかについて判断が行われる。改善がまったくない場合、最後の最良ソリューションがブロック４１６の出力になる。改善が達成された場合、しかもブロック４２０で十分な時間がある場合、この方法はもう一度繰り返し、ブロック４１２に戻る。十分な時間がない場合、この方法はブロック４１６に移行する。
【００６５】
仮想化環境におけるライセンス資格の管理のためのシステムおよび方法の好ましい諸実施形態（限定のためではなく、例示のためのものである）について説明してきたが、上記の教示を考慮して、当業者により修正および変形が可能であることは注目に値する。したがって、開示されている特定の実施形態において、特許請求の範囲によって概要が示されている本発明の範囲内にある変更を行うことができることを理解されたい。したがって、特許法が要求するように詳細かつ入念に本発明の諸態様について説明してきたが、特許証によって保護される請求内容は特許請求の範囲に明記されている。
【技術分野】
【０００１】
本発明は、仮想化システム管理に関し、詳細には、仮想化環境（virtualizedenvironment）を管理する際の使用権（usage right）および使用制限（usage limitation）の理由を説明するように構成されたシステムおよび方法に関する。
【背景技術】
【０００２】
最新のエンタープライズ・ソフトウェアは、かなりの額の購入コスト、複雑なライセンス条件、ライセンス違反の場合の顧客に対する重大な罰則を伴う。伝統的に、ソフトウェアは単純にインストール済みコピーに関してライセンスされており、すなわち、顧客はインストールされたソフトウェアの各コピーごとに特定の金額を支払ってきた。したがって、顧客用のソフトウェアのコストは、顧客が使用している（または、より正確には、インストールした）コピーの数に、顧客がコピーごとに支払った価格を掛けたものである。使用されているもう１つの技法はいわゆる「ライセンス・プール」である。この技法では、顧客は現在実行しているソフトウェアのコピーについてのみ支払い、必要な数のコピーをインストールすることができるが、そのうちの非常に多くのコピーは同時に実行することができる。これらのモデルはいずれも、ワークステーション・ソフトウェア、すなわち、個々のパーソナル・コンピュータ上で実行されるソフトウェアの分野で広く使用されてきており、依然として広く使用されている。
【０００３】
最新のサーバ・ソフトウェアにはさらに複雑なライセンス条件がある。推進例として、「プロセッサ・バリュー・ユニット（Processor Value Unit）」方法またはＰＶＵについて考慮する。この手法は、インストール済みインスタンスによって単純にソフトウェアをライセンスするのではなく、顧客がそのソフトウェアから受け取る潜在的な価値を測定しようという試みに基づいてライセンスするものである。
【０００４】
ＰＶＵベースのプロダクト・ライセンシングは、そのプロダクトについて均一料金を請求するわけではない。その代わりに、プロダクトにはＰＶＵに関して値段が付けられる。ＰＶＵライセンス・プロダクトを購入するときに、顧客は、どのくらいの数のＰＶＵが必要であるかを算出し、その数に当該プロダクトのＰＶＵあたりの価格を掛ける。
【０００５】
例として、アプリケーション・サーバの表示価格はＰＶＵあたり６０ドルである。価格計算を完了するために、顧客は次に、そのプロダクトを実行する予定であるＣＰＵを調べる。各プロセッサ・タイプごとに「コアあたりのＰＶＵ」値が定義されており、それはどのくらいの数のＰＶＵを購入すべきかを顧客に示すものである。たとえば、この例の表には、すべてのプロセッサ（複数コア付き）についてコアあたりのＰＶＵ値の価格を５０としてリストされている。したがって、８つのコアを有する１台のマシン上でアプリケーション・サーバを実行したいと希望する顧客は、８＊５０＝４００ＰＶＵのアプリケーション・サーバを備える必要がある。ＰＶＵあたりのコストが６０ドルである場合、これは６０＊４００＝２４，０００ドルを要することになるであろう。
【０００６】
ＰＶＵベースのライセンシングの重要な態様の１つは、顧客がインストールし実行するアプリケーション・サーバのコピー数ではなく、そのコピーがアクセスするＰＶＵの数のみが重要であることである。たとえば、顧客はその代わりにそれぞれが４つのコアを有する２台のマシンを実行することを決定することができ、ＰＶＵ要件は依然として４００（２＊４＊５０）になるであろう。加えて、顧客は２台のマシンのそれぞれでアプリケーション・サーバの７つのコピーを実行することを決定することができ、その顧客のＰＶＵ要件は引き続き４００になるであろう。
【０００７】
この方式では、ＰＶＵはプロダクト間で交換可能ではない。ＰＶＵは、ＣＰＵタイプ間およびマシン間で交換可能である。例として、アプリケーション・サーバについて４００のＰＶＵを購入した顧客は、顧客が希望するマシンであればどのマシン上でもアプリケーション・サーバを実行することができるが、ただし、顧客は合計で４００を超えるＰＶＵを必要とするＣＰＵ上で実行しないものとする。しかし、顧客は、アプリケーション・サーバの実行を停止して、その代わりにＰＶＵ方式を使用してライセンスされた他の（第２の）ソフトウェア・プロダクトを実行することはできない。第２のソフトウェア・プロダクトのＰＶＵあたりの価格はアプリケーション・サーバの価格とは異なるので、顧客はあるプロダクトについて購入したＰＶＵを使用して他のプロダクトを実行することはできない。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
その結果として、任意の所与のシステムには様々なライセンス・プロダクトが配備されることになり、顧客はライセンスの条件の遵守を保証するために各プロダクトごとにその資格（entitlement）および使用率（usage）を追跡する必要があることが分かる。
【課題を解決するための手段】
【０００９】
仮想化環境のための管理システムおよび方法は、資格に基づく使用制限を有するコンピュータ・エンティティを含む。プロセッサを使用し、メモリ・ストレージ・デバイス上にプログラミングされ、メモリ・ストレージ・デバイスから実行されるリソース・マネージャは仮想化環境内のリソースを管理するように構成される。資格使用率モジュール（entitlement-usage module）は、リソース・マネージャに結合され、仮想化環境の変化に応じて資格関連制約を追跡し、リソース・マネージャが資格関連制約を含む割り振り決定を行えるようにして、コンピュータ・エンティティについて使用制限を満たしていることを保証するように構成される。
【００１０】
仮想化環境内のリソースを管理するための方法は、１組の資格に関する制約を表すステップと、配置すべきコンピューティング・エンティティについて、許可される資格の数およびタイプを決定するステップとを含む。結果として得られる配置ソリューションが現在使用可能な資格を超えないように、配置プログラムが進行するにつれて、現行候補配置ソリューションについて資格使用率が計算される。
【００１１】
上記その他の特徴および利点は、添付図面に関連して読むべきものである、その例示的な諸実施形態に関する以下の詳細な説明から明らかになるであろう。
【００１２】
本発明は、以下の図面に関連して好ましい諸実施形態に関する以下の説明において詳細を提供するものである。
【図面の簡単な説明】
【００１３】
【図１】仮想化環境を管理する際にライセンシング／資格を考慮するシステム／方法のブロック図／流れ図である。
【図２】本発明の原理による配置管理システムに関する例示的な例を示すブロック図である。
【図３】ライセンシング／資格を考慮しながら環境を管理するための例示的な例を示すブロック図である。
【図４】追加されたＶＭによりライセンシング／資格を考慮しながら図３の環境を管理するための他の例示的な例を示すブロック図である。
【図５】ＰＶＵ共用によりライセンシング／資格を考慮しながら図４の環境を管理するための他の例示的な例を示すブロック図である。
【図６】追加されたＶＭの配置位置を考慮しながら図３の環境を管理するための他の例示的な例を示すブロック図である。
【図７】ＰＶＵ共用により追加されたＶＭの配置位置を考慮しながら図４の環境を管理するための他の例示的な例を示すブロック図である。
【図８】一実施形態によりコンピュータ・エンティティと資格のバンドルとの関係を示すモデル構成体のブロック図である。
【図９】例示的な一実施形態によりライセンシング／資格を考慮する配置方法を示すブロック図／流れ図である。
【図１０】他の例示的な実施形態によりライセンシング／資格を考慮する他の配置方法を示すブロック図／流れ図である。
【発明を実施するための形態】
【００１４】
本発明の原理により、仮想化環境の統合管理のためのシステムおよび方法が提供される。特に有用な諸実施形態では、管理システムは、ライセンス認識（license awareness）を含み、この認識をその決定およびアクションに使用する。たとえば、管理システムが新しい仮想計算機を配備し、既存の仮想計算機をあちらこちらにマイグレーションすることができる場合、ライセンス認識を含むことの利益はさらに重大なものになる。
【００１５】
仮想化とは、コンピューティング・リソースを抽象的なものにする能力を指す一般的用語である。この実施形態は、コンピュータ・システム（たとえば、ストレージまたはネットワークも使用できるが、これらとは対照的なもの）の仮想化を含む、プラットフォーム仮想化に含めることができる。あるタイプの仮想化は完全仮想化であり、その場合、通常は分離された複数のオペレーティング・システム・インスタンスを単一コンピュータ上で実行することができる。その他のタイプの仮想化、たとえば、オペレーティング・システム・レベルの仮想化も含まれ、その場合、単一オペレーティング・システム内に通常は分離された複数の空間が提示され、その内部でプログラムが実行される。
【００１６】
完全仮想化の例としては、いくつか例を挙げると、ＩＢＭ（Ｒ）のＤＬＰＡＲ（ｐＳｅｒｉｅｓおよびｚＳｅｒｉｅｓ上）、ＩＢＭ（Ｒ）のｚ／ＶＭ、ＶＭｗａｒｅ（Ｒ）のプロダクト・ファミリー、Ｃｉｔｒｉｘ（Ｒ）のＸｅｎＳｅｒｖｅｒおよびＸｅｎ、Ｌｉｎｕｘ（ＴＭ）のＫＶＭを含む。「オペレーティング・システム・レベルの仮想化」の一般的な例としては、ＡＩＸオペレーティング・システム用のＩＢＭ（Ｒ）のＷＰＡＲ、Ｓｕｎ（Ｒ）のＳｏｌａｒｉｓ Ｃｏｎｔａｉｎｅｒ、Ｌｉｎｕｘ（ＴＭ）のＶＳｅｒｖｅｒを含む。
【００１７】
仮想計算機は、たとえば、オペレーティング・システム・インスタンス（完全仮想化の場合）または空間（オペレーティング・システム・レベルの仮想化の場合）のいずれかを参照することができる。仮想化の関連態様の１つは、ＣＰＵ割り振りを制御する能力である。たとえば、単一の物理マシン上で複数の仮想計算機を実行する場合、それぞれの仮想計算機がアクセスできる、物理マシン内のＣＰＵ（または物理ＣＰＵ）およびその数を制限することは可能である。
【００１８】
たとえば、８つのプロセッサ・コアを有する単一の物理マシンについて考慮する。この物理マシンは３つの仮想計算機を実行することができ、そのうちの第１の仮想計算機は２つの仮想ＣＰＵを有し、第２の仮想計算機は４つの仮想ＣＰＵを有し、第３の仮想計算機は８つの仮想ＣＰＵを有する。仮想計算機内部で実行されるソフトウェアは、仮想計算機がアクセスできるＣＰＵの数に等しくすることができる。
【００１９】
他の態様はライブ・マイグレーション（パーティション・モビリティおよびマイグレーションとも呼ばれる）を含む。これは、サービスを中断せずに仮想計算機をある物理マシンから他の物理マシンに移動する能力を指す。
【００２０】
仮想化とソフトウェア・ライセンシングとの共通部分は、ＰＶＵタイプのライセンシングと仮想化を結合することができる。上記の仮想計算機の例と以前のアプリケーション・サーバの例を結合すると、顧客は元の４００ＰＶＵ要件について３つの仮想計算機すべてでアプリケーション・サーバを実行することを許可されるはずである。８つの物理コアがすべて使用されるので、８つすべてをライセンスしなければならない。単一マシン上でアプリケーション・サーバの複数のコピーを実行してもライセンス要件は変更されず、個別の仮想計算機内で異なるインスタンスが実行されるということは、このライセンシング方式では関連性はない。換言すれば、このマシン上でアプリケーション・サーバを実行するために顧客が購入する必要がある最も多いＰＶＵは４００であり、いくつのインスタンスまたは仮想計算機が稼働中であるかは重要ではない。
【００２１】
ＰＶＵの共用について考慮する。この事例では、８つの仮想ＣＰＵである仮想計算機がまず作成される。その後、４つの仮想ＣＰＵと２つの仮想ＣＰＵである仮想計算機が作成される。第２の２つのＶＭについては追加のライセンスが不要であるので、それらは、第１の仮想計算機を作成するために必要であったライセンスを「共用」する。しかし、第１の仮想計算機については特別なことは何もなく、この例では、単に最初に作成されたものであり、物理コアをライセンスする必要性が促進された。次の２つの仮想計算機を配備するために追加のライセンスは一切不要である。
【００２２】
たとえば、顧客が第１の仮想計算機（２つの仮想ＣＰＵを有するもの）でアプリケーション・サーバを実行するだけである場合など、顧客が４００未満のＰＶＵを必要とする場合がある。この場合、顧客は１００ＰＶＵのみ（２つの物理コアのそれぞれについて５０ずつ）を必要とする。このプラットフォーム上のこのタイプのライセンシングでは、顧客は仮想ＣＰＵの合計または物理コアの数のうちの少ない方に十分なＰＶＵを有する必要がある。明瞭にするために詳細が省略されているので、ＰＶＵタイプのライセンシングの上記の説明は制限するためのものではなく、クラスタ化およびその他のプラットフォーム・タイプの問題は完全に除外されていることを理解されたい。上記の説明は、単に本発明の原理を実装できる環境を例証するためのものである。加えて、他のソフトウェア・プロバイダは他のライセンシング方式を有する。しかし、そのうちのいくつかは、上記のＰＶＵベースの方式と同様の態様を有する。
【００２３】
仮想化がエンドユーザ・データ・センタでますます普及するにつれて、仮想化管理がより重要なものになる。性能管理、高可用性、および省電力の分野では、大幅な進歩が見られた。しかし、顧客に重大な利益をもたらすのに無視されてきた領域はライセンス管理である。とりわけ、その他の管理関心事とともにライセンス管理を考慮する能力は特に有用である。配備およびマイグレーションのいずれも、任意の所与の時点でシステムが使用するライセンスの数を変更する可能性がある。たとえば、上記で使用した３つの仮想計算機のケースについてもう一度考慮するが、初めにその上にいかなる仮想計算機も配備されていない第２の物理マシンを導入する。第１の物理マシンから第２の物理マシンに仮想計算機をマイグレーションすると、システム全体をライセンスするのに必要なＰＶＵの数が増加することになり、以前あったものより多くの物理コアがアプリケーション・サーバを実行していることが理解できるであろう。配備およびマイグレーションを伴う多数の他のケースも引用できるであろう。
【００２４】
本発明の原理によれば、統合管理システムはライセンス認識機能を含む。管理システムが新しい仮想計算機を配備するか、あるいは既存の仮想計算機をあちらこちらにマイグレーションするか、またはその両方を行うことができる場合、決定を行うかまたはこのようなアクションを実行する際にライセンス認識が考慮される。このシステムは、他の管理考慮事項に加えてライセンス要件を考慮する。
【００２５】
本発明全体を通して、単一の顧客に言及するが、この実施形態は、インフラストラクチャを共用する個別のライセンスを有する１組の顧客に等しく適用可能である。この実施形態によって提供されるいくつかの特徴としては以下のものを含む。すなわち、現在の顧客のソフトウェア・プロダクトについて、情報、ライセンス資格、および対応するライセンス・タイプを尋ねるために、システム管理者から情報を引き出すか、またはソフトウェア供給業者に電子的に接触することなど、１つまたは複数のメカニズムにより入手することである。これらのライセンス資格およびライセンス・ルールは、現在のライセンス使用率を計算できるように、管理されているインフラストラクチャに関する十分な情報を収集するために考慮に入れられる。この情報は、システム内の様々な物理マシンの数および特性、現在配備されている仮想計算機の数および特性（適用可能な場合）、どのソフトウェア・プロダクトがインストールされ、それがどこにインストールされているかに関する情報を含むが、これらに限定されない。
【００２６】
管理中のシステムに対する潜在的な変更について考慮すると、この実施形態は、そのシステムに対するその変更の効果を（必要なライセンスに関して）計算することができ、その他のシステムレベルの影響（たとえば、性能、可用性、消費電力などを含む）に加えて、ライセンス要件に対するその影響に関して種々の組の潜在的変更を評価する。この実施形態は、顧客のライセンス資格内にシステムを保持するように、システムに対して行う１組の変更を選択することができる。これが不可能である場合、システムをオーバライドするための様々な手法が可能である。一実施形態では、システムはライセンス資格をオーバライドすることができない。他の実施形態では、システムはそのようにオーバライドすることができるが、システム管理者の許可がある場合に限られる。また、その他の実施形態も可能である。
【００２７】
一例では、データ・センタは１００台の物理マシンを含む。すべてのライセンス・プロダクトを同じ物理マシン上に配置し、他のものはいずれも使用しないことにより、ライセンス使用率を最小限にすることができる（このような手法は消費電力に対して有益な効果をもたらすであろう）。しかし、単一物理マシンのリソースはすべてのライセンス・プロダクトを十分に処理するためには不十分であるので、システムの性能はおそらく悪化するであろう。このようなソリューションは可用性に対して否定的な影響も及ぼすので、その単一マシンが故障すると、あらゆるものが故障することになる。
【００２８】
当業者であれば分かるように、本発明の諸態様はシステム、方法、またはコンピュータ・プログラム（computer program product）として実施することができる。したがって、本発明の諸態様は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）、またはハードウェアとソフトウェアの態様を結合する実施形態の形を取ることができ、いずれも一般に本明細書で「回路」、「モジュール」、または「システム」と呼ぶことができる。さらに、本発明の諸態様は、そこにコンピュータ可読プログラム・コードが実施されている１つまたは複数のコンピュータ可読媒体（複数も可）で実施されたコンピュータ・プログラムの形を取ることができる。
【００２９】
１つまたは複数のコンピュータ可読媒体（複数も可）の任意の組み合わせを使用することができる。コンピュータ可読媒体は、コンピュータ可読信号媒体またはコンピュータ可読記憶媒体にすることができる。コンピュータ可読記憶媒体は、たとえば、電子、磁気、光、電磁、赤外線、または半導体のシステム、装置、またはデバイス、もしくは上記のものの任意の適切な組み合わせにすることができるが、これらに限定されない。コンピュータ可読記憶媒体のより具体的な例（非網羅的なリスト）としては、１つまたは複数のワイヤを有する電気接続、ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、消去可能プログラマブル読み取り専用メモリ（ＥＰＲＯＭまたはフラッシュ・メモリ）、光ファイバ、ポータブル・コンパクト・ディスク読み取り専用メモリ（ＣＤ−ＲＯＭ）、光ディスク・ストレージ・デバイス、磁気ディスク・ストレージ・デバイス、または上記のものの任意の適切な組み合わせを含むことになるであろう。本明細書に関しては、コンピュータ可読記憶媒体は、命令実行システム、装置、またはデバイスによりあるいはそれに関連して使用するためのプログラムを収容または保管することができる任意の有形媒体にすることができる。
【００３０】
コンピュータ可読信号媒体は、たとえば、ベースバンド内でまたは搬送波の一部として、コンピュータ可読プログラム・コードがそこに実施されている伝搬データ信号を含むことができる。このような伝搬信号は、電磁、光、またはそれらの任意の適切な組み合わせを含むがこれらに限定されない様々な形のうちのいずれかを取ることができる。コンピュータ可読信号媒体は、コンピュータ可読記憶媒体ではないが、命令実行システム、装置、またはデバイスによりあるいはそれに関連して使用するためのプログラムを通信、伝搬、または伝送することができる任意のコンピュータ可読媒体にすることができる。コンピュータ可読媒体上に実施されたプログラム・コードは、無線、有線、光ファイバ・ケーブル、ＲＦなど、または上記のものの任意の適切な組み合わせ含むがこれらに限定されない任意の適切な媒体を使用して伝送することができる。
【００３１】
本発明の諸態様の動作を実行するためのコンピュータ・プログラム・コードは、Ｊａｖａ、Ｓｍａｌｌｔａｌｋ、Ｃ＋＋などのオブジェクト指向プログラミング言語ならびに「Ｃ」プログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語を含む、１つまたは複数のプログラミング言語の任意の組み合わせで作成することができる。このプログラム・コードは、完全にユーザのコンピュータ上で、部分的にユーザのコンピュータ上で、スタンドアロン・ソフトウェア・パッケージとして、部分的にユーザのコンピュータ上でかつ部分的にリモート・コンピュータ上で、あるいは完全にリモート・コンピュータまたはサーバ上で、実行することができる。後者のシナリオでは、リモート・コンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ）または広域ネットワーク（ＷＡＮ）を含む任意のタイプのネットワークにより、ユーザのコンピュータに接続される場合もあれば、（たとえば、インターネット・サービス・プロバイダを使用してインターネットにより）外部コンピュータに対して接続が行われる場合もある。
【００３２】
本発明の諸態様については、本発明の諸実施形態による方法、装置（システム）、およびコンピュータ・プログラムの流れ図あるいはブロック図またはその両方に関連して以下に説明する。流れ図あるいはブロック図またはその両方の各ブロックならびに流れ図あるいはブロック図またはその両方の複数ブロックの組み合わせは、コンピュータ・プログラム命令によって実装することができることが理解されるであろう。これらのコンピュータ・プログラム命令を汎用コンピュータ、特殊目的コンピュータ、またはその他のプログラマブル・データ処理装置のプロセッサに提供し、そのコンピュータまたはその他のプログラマブル・データ処理装置のプロセッサを介して実行された命令が流れ図あるいはブロック図またはその両方の１つまたは複数のブロックに指定された機能／動作を実装するための手段を作成するようなマシンを生産することができる。
【００３３】
また、これらのコンピュータ・プログラム命令は、コンピュータ可読媒体に保管された命令が、流れ図あるいはブロック図またはその両方の１つまたは複数のブロックに指定された機能／動作を実装する命令を含む装置（article of manufacture）を生産するような特定の方法で機能するよう、コンピュータ、その他のプログラマブル・データ処理装置、またはその他のデバイスに指示することができるコンピュータ可読媒体に保管することもできる。
【００３４】
または、これらのコンピュータ・プログラム命令は、コンピュータ、その他のプログラマブル装置、またはその他のデバイス上で一連の動作ステップを実行させて、コンピュータまたはその他のプログラマブル装置上で実行された命令が流れ図あるいはブロック図またはその両方の１つまたは複数のブロックに指定された機能／動作を実装するためのプロセスを提供するようなコンピュータ実装プロセスを生成するために、コンピュータ、その他のプログラマブル・データ処理装置、またはその他のデバイス上にロードすることもできる。
【００３５】
図面内の流れ図およびブロック図は、本発明の様々な諸実施形態によるシステム、方法、およびコンピュータ・プログラムについて可能な実装例のアーキテクチャ、機能、および動作を例示している。この点に関しては、流れ図またはブロック図内の各ブロックは、指定の論理機能（複数も可）を実装するための１つまたは複数の実行可能命令を含む、コードのモジュール、セグメント、または一部分を表すことができる。また、いくつかの代替実装例では、ブロック内に示された機能は図面内に示された順序から外れて行われる可能性があることにも留意されたい。たとえば、連続して示されている２つのブロックは、関係する機能に応じて、実際にはほぼ同時に実行される場合もあれば、ときには逆の順序で実行される場合もある。また、ブロック図あるいは流れ図またはその両方の各ブロックならびにブロック図あるいは流れ図またはその両方の複数ブロックの組み合わせは、指定の機能または動作を実行する特殊目的ハードウェアベースのシステムによって、または特殊目的ハードウェアとコンピュータ命令の組み合わせによって、実装可能であることも留意されるであろう。
【００３６】
次に、同様の番号が同じかまたは同様の要素を表している図面を参照し、初めに図１を参照すると、仮想化環境において統合管理を提供するために使用権、制限、および制約を考慮に入れるシステム１０１が例示的に描写されている。システム１０１は、物理マシン１０２、１０４と、仮想計算機（ＶＭ）１０６と、リソース・マネージャ１１０と、ライセンシング／資格制約管理モジュール１１２と、ストレージ・リソース・マネージャ１１４とを有する仮想環境を例示的に含む。システム１０１は、コンピュータ・アーチファクトまたはエンティティの供給、変更、実行、マイグレーションなどが行われる、データ・センタ環境、ネットワーク環境、または任意のその他のコンピュータ環境を含むことができる。コンピュータ・アーチファクトまたはエンティティは仮想計算機（ＶＭ）を含むことができる。仮想計算機は、この例示的なシステム説明のために例示的に使用される。アプリケーションまたは他の計算エンティティも同様に使用できることを理解されたい。
【００３７】
アプリケーション１１６は個々のＶＭ１０６によって処理され、物理マシン１０２、１０４は複数のＶＭ１０６を処理することができる。各ＶＭ１０６は、ブート時にＶＭ１０６に割り振られたリソース（ネットワーク、メモリ、およびＣＰＵ）の一部分を有し、同じ物理マシン１０２、１０４内で共同処理（co-host）される他のＶＭ１０６とリソースを共用する。物理マシンは複数のＶＭ１０６を処理することができる。ＶＭ１０６は、他の物理マシンまたは環境にマイグレーションすることができる。
【００３８】
ストレージ・リソース・マネージャ１１４は、システム１０１内のストレージ間でストレージ使用率をモニターする役割を担う。リソース・マネージャ１１０は、仮想計算機１０６の配置または再位置決め（マイグレーション）および再供給に関する決定を行う役割を担い、必要なときに、たとえば、潜在的な再位置決めのためにＶＭ１０６が選択されたときに、モジュール１１２およびストレージ・リソース・マネージャ１１４と調整する。配置とは、所与の仮想計算機が所与の時点にどこで実行しなければならないかという決定を指す。
【００３９】
配置決定は、複数の異なる考慮事項に基づいて行うことができる。たとえば、仮想計算機の性能を意識した配置ではＶＭ配置の結果として性能利得を考慮し、仮想計算機の制約を意識した配置は制約に基づくものである。制約を意識した決定は、割り振り制限（たとえば、「これを特定の位置に配置してはならない」、「これは位置ｘ、ｙ、ｚのみに移動することができる」）およびコロケーション制限（「これはそれと共存できない」、「これはいずれとも共存できない」など）を考慮することができる。ライセンスを意識した配置は、性能を意識した配置あるいは制約を意識した配置またはその両方に含めることができる。仮想計算機の初期配備では、配備時に追加の貢献を考慮することができる。たとえば、ネットワーク接続、ストレージの可用性などである。
【００４０】
リソース・マネージャ１１０およびハイパーバイザ１２０は、ＶＭストレージ、マイグレーション、アプリケーション実行、およびその他の管理機能を管理する際に使用される。ライセンシング制約管理モジュール１１２は、リソース・マネージャ１１０およびハイパーバイザ１２０のうちの一方または両方と統合することができる。マイグレーション中に、システム１０１は以下の例示的な機能を実行する。すなわち、（１）リソース・マネージャ１１０はマイグレーションまたは再供給のためにＶＭ１０６を指定する。（２）リソース・マネージャ１１０はライセンシング制約管理モジュール１１２を調査して、ＶＭ１０６をその現在の位置から新しい位置に移動するときに制約が存在するかどうかを判断する。これは、新しい位置への移動または古い位置からの移動を防止するための制約が存在するかどうかを判断することを含む。ライセンシング制約管理モジュール１１２は、サービス・レベル・アグリーメント（ＳＬＡ）、ライセンス契約、著作権情報などから得られる可能性のある制約情報を保管する。有用な諸実施形態によれば、ライセンシング制約管理モジュール１１２は、リソースの変更に関する決定プロセスの一部としてリソース・マネージャ１１０によって調査される。ライセンシング制約管理モジュール１１２は、各資格タイプの現行レベルの使用率を呼び出し側に提供することができる。
【００４１】
リソース・マネージャ１１０は、その決定にライセンス認識を含む管理システムを提供する。管理システムが新しい仮想計算機（１０６）を配備するか、既存の仮想計算機（１０６）をあちらこちらにマイグレーションするか、アプリケーションまたはＶＭを実行するか、あるいはＶＭ（１０６）を再供給するか、またはこれらの組み合わせを行うと、ライセンス認識が重要になり、管理システムは他の管理考慮事項に加えてライセンス（およびその他の使用制約）について考慮する。システム１０１のライセンシング制約管理モジュール１１２は、競合する制約に優先順位を付ける能力をさらに含む。
【００４２】
ライセンシング制約管理モジュール１１２は、現在の顧客のソフトウェア・プロダクトについて、情報、ライセンス資格、対応するライセンス・タイプなどを尋ねるために、システム管理者から情報を引き出すこと、ソフトウェア供給業者に電子的に接触することを含む、様々なメカニズムを使用して、資格データを入手する。リソース・マネージャ１１０（あるいはライセンシング制約管理モジュール１１２またはその両方）は、ライセンス資格およびライセンス・ルールの理由を説明し、現在のライセンス使用率を計算できるように、管理されているインフラストラクチャに関する十分な情報を収集する。この情報は、たとえば、システム１０１内の物理マシン１０２、１０４の数および特性、現在配備されている仮想計算機１０６の数および特性（適用可能な場合）、どのソフトウェア・プロダクトがインストールされているかならびにその位置に関する情報などを含むが、これらに限定されない。
【００４３】
管理中のシステムに対する潜在的な変更について考慮すると、そのシステムに対するその変更について、このような変更の効果を（必要なライセンスなどに関して）計算する必要がある。その他のシステムレベルの影響（たとえば、性能、可用性、消費電力などを含む）に加えて、ライセンス要件に対するその影響に関して種々の組の潜在的変更を評価することができる。システムが顧客のライセンス資格内に保持されることを保証することができる１組の変更が選択される。これが不可能である場合、システムをオーバライドするための様々な手法が可能であるか、またはライセンス契約の精神に従う最良のソリューションを選択することができる。一実施形態では、システムはライセンス資格をオーバライドすることができない。他の実施形態では、システムはそのようにオーバライドすることができるが、システム管理者の許可がある場合に限られる。また、その他の実施形態も可能である。
【００４４】
仮想化環境に関するプロダクト・ライセンス・ルールは複雑な場合が多い。最近では、インストールされたコピーの数に基づくのではなく、プロダクトがどの程度の作業を実行できるかに基づいて、プロダクトの料金を請求する場合がある。その結果、ライセンス使用率は、プロダクトのインストールされたコピーがどのように物理ハードウェア上に配置されるかによって決まる。仮想化環境に対処するための例示的な例として、プロセッサ・バリュー・ユニット（ＰＶＵ）が使用される。ＰＶＵのスコアによって、特定のプロセッサ・タイプのライセンス・コストは決定される。プロダクトが使用するプロセッサごとに支払いを行わなければならない。同じプロダクトの複数のコピーが使用する１つのプロセッサについては、１回だけ支払えば良い。あるプロダクトが１つのプロセッサを使用できるＶＭにインストールされると、そのプロセッサはそのプロダクトによって使用され、停止されたプロダクトおよび停止されたＶＭは使用率としてカウントされる。グリニッジ標準時の午前０時に始まる２４時間の期間ごとにあるプロダクトによって使用される各プロセッサがカウントされ、ＶＭマイグレーションはＰＶＵ使用率に影響し、ＶＭｗａｒｅに関する特殊なクラスタ化ルールは、分散リソース・スケジューリング（ＤＲＳ：Distributed Resource Scheduling）が使用されているときに（しかし、そのときに限られる）過剰請求を防止する。
【００４５】
図２を参照すると、配置システム１８０は図１の制約マネージャ１１２内に含まれている。資格使用率を決定するためには、配置システム１８０がすべての可能な配置についてすべての資格の現行使用率を計算できることが必要である。加えて、配置システム１８０は、その配置に対して特定の変更を行うためにこれらの資格使用率に対する効果を計算できることも必要である。本明細書に記載されているライセンス資格、より具体的には（説明のみのために）ＰＶＵライセンスを一例に挙げると、配置システム１８０は、各物理マシン（１０４）上の物理コアの数、これらの物理コアのそれぞれのＰＶＵの「点数」、各仮想計算機内の各プロダクトがアクセスできる仮想コアの数、各仮想計算機内のプロダクト（複数も可）という情報を把握する必要がある。
【００４６】
この情報が与えられると、配置システム１８０は、任意の時点で、仮想計算機の所与の配置が消費する資格の数を計算することができる。したがって、配置ルーチンが進行するにつれて、すべてのステップで使用された各資格の量を再計算できることが分かる。さらに、配置ルーチンが変更を行うことを考慮する場合、そのルーチンは、その変更がシステム内の一つ一つの資格について及ぼすと思われる効果を計算することができる。
【００４７】
システム１８０を実装するために、必要な情報を決定するためのセンサが実装される。物理マシン（ＰＭ）センサ１８２は物理マシン（１０４）の特性を検出し、その物理マシンは次に、所与のプロセッサ・タイプおよび数量に関するＰＶＵの「点数」を把握しているソフトウェア・コンポーネント（たとえば、データベース）またはＰＶＵエキスパート１８４と結合される。仮想計算機（ＶＭ）センサ１８６は仮想計算機に関する情報を提供し、プロダクト・センサ１８８はインストールされたプロダクトおよびそのライセンス条件に関する情報を提供する。配置システム１８０は、この情報およびその他の必要なデータの収集をサポートするために拡張された変更済みＰＭセンサ１８２およびＶＭセンサ１８６を含むことができる。
【００４８】
配置システム１８０は、（センサからの）システム・データを配置実行器（placementexecutor）１９０内の標準形に伝達し、配置システムの関心事をセンサの特定の実装例から分離する。配置実行器１９０は次に、どの変更を行うかについて決定を行いながら、その標準形を検査することになる。この標準形は、本明細書に記載されている通り、資格のバケット（ＢｏＥ：Buckets of Entitlement）などを含むことになる。
【００４９】
加えて、システム１８０の実装例は、時間の経過につれてシステムの進行中の最適化および管理を含む。センサ（１８２、１８６、１８８）からのイベントは、現行配置を再評価するよう配置システム１８０をトリガすることになる。これらのイベントとしては、資格要件または資格可用性に対する変更を含むことになる。
【００５０】
図３を参照すると、本発明の原理による概念を実証するために簡易化したＰＶＵシステム２００が描写されている。４台の物理マシン（ＰＭ）２０２はそれぞれ、４つの物理コンピュータ処理装置（ｐＣＰＵ）２０４を含む。それぞれのｐＣＰＵ２０４は、たとえば、５０ＰＶＵを含む。すべてのＶＭ２０６および２０７は２つのｖＣＰＵ２０８を含む。図２では、３つのＶＭ２０６がアプリケーション・サーバ（ＡＳ）アプリケーション、たとえば、ＩＢＭ（Ｒ）のＷｅｂｓｐｈｅｒｅ Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒ（ＴＭ）を実行し、１つのＶＭ２０７がデータベース（ＤＢ）アプリケーション（たとえば、ＩＢＭ（Ｒ）のＤＢ２（ＴＭ））を実行する。それぞれのＶＭ２０６が２つのｐＣＰＵ２０４を使用するので（それぞれ２×５０＝１００）、アプリケーション・サーバ・アプリケーション（ＡＳ）のＰＶＵ使用率は３００である。それぞれのＶＭ２０７は２つのｐＣＰＵ２０４を使用するので（それぞれ２×５０＝１００）、データベース・アプリケーション（ＤＢ）のＰＶＵ使用率は１００である。
【００５１】
図４では、第４のＶＭ２０６’がアプリケーション・サーバ・アプリケーションを実行し、このアプリケーションのためのＰＶＵ消費が３００から４００に増加する。図５では、新しいＶＭ２０９が作成され、同じマシンおよびＣＰＵを共用することによる恩恵を受ける。すでにＰＶＵカウントにカウントされているプロセッサ上にＶＭ２０９を含めることにより、追加のＰＶＵ消費はまったく発生しない。
【００５２】
もう一度、図３を参照して、顧客が４００ＰＶＵのＡＳアプリケーションを購入したとする。セットアップ時（またはその他の時点）にシステム１０１の強制モード（enforcement mode）中に、ライセンス・モジュール１１２またはリソース・マネージャ１１０（図１）は遵守をチェックする。４００ＰＶＵが使用率について提案されているが、このシナリオでは、ＤＢ用に１００が使用されており、顧客はＤＢアプリケーションの使用を認可されていないものと想定する。この場合、違反が存在する。システム１０１（図１）は、顧客に接触し、１００ＰＶＵのＤＢアプリケーションについてその顧客をサインアップするかまたは単に現行のライセンス契約書の下でそのアプリケーションが使用不能であるという警告を送出することができる。一実施形態では、強制モードは、資格を遵守していることを保証するためにＤＢアプリケーションの無許可使用を遮断することになるであろう。
【００５３】
図６では、図３の構成により新しいＶＭ２０９（図５と同様）の追加が可能になるが、ＶＭ２０９の配置には選択肢が存在する。ＶＭ２０９用として４つの位置２１２が存在する。いずれの位置でも結果的に４００というＡＳ ＰＶＵ消費になり、すべての配置が有効である。しかし、ＶＭ２０９の配置はそれぞれの位置２１２にあるものであり、その配置はそれぞれの場合に応じて同等ではないものとなる。管理決定は、ＶＭ２０９の最良の位置を決定するための性能ベースの配置など、追加の基準を含むことができる。
【００５４】
一例では、ＶＭ２０９に加えて、他のＶＭ（図示せず）をＡＳ用に配置する必要がある場合、ＰＶＵ限界４００を超えることになるので、それは不可能である。すべてのオプションがＡＳ ＰＶＵ限界に違反するので、新しいＶＭを配置することはできない。顧客は、ＡＳアプリケーションについてより多くのＰＶＵをサインアップすることができるかまたはその他のアクションを取ることができるであろう。もう１つのシナリオはこの問題を解決することができる。図７に描写されている通り、第１の新しいＶＭ２０９は４つの位置２１２のうちの１つの第１のＰＭ２０２（左端のＰＭ）上に配置され、新しいＶＭ２１１はＰＶＵ共用をトリガするように配置することができる（図５を参照）。このようにして、ＡＳ用のＰＶＵは４００というＰＶＵ限界より下に維持され、余分なＶＭ２１１に対応する。
【００５５】
もう１つの例では、１つのＰＭ２０２だけがＰＶＵ共用に使用可能である。ＰＶＵ遵守を保証し、性能のバランスを取るために、ＶＭのマイグレーションを使用することができる。たとえば、リソースを共用し、ＰＶＵ消費を回避するために、ＰＭ２０２を完全に占有することができる。
【００５６】
ＶＭを移動すると、２４時間ルールに問題を引き起こす可能性がある。任意のＰＭ２０２が２４時間の期間内に使用中である場合、ＰＶＵによる支払いがなされなければならない。たとえば、２つのＡＳ ＶＭが存在する。一方のＶＭは午前０時に実行されて午前６時に破壊され、第２のＶＭは正午に作成されて午後６時に破壊される。任意の時点で１００ＰＶＵのみが使用中であっても、このシナリオのＰＶＵ消費は２００になる。ライセンス圧縮を回避するために、２４時間ルールが存在する。したがって、ＶＭをマイグレーションすることは、追加のコストを含む可能性がある。これは、特殊なＰＶＵカウント・ルールを使用して対処することができる。このようなルールは、資格遵守を保証し、使用率を最適化するために、制約として入力し、本発明の原理により使用することができる。
【００５７】
上記の通り、もう１つの例では、所与の日の使用率は２４時間ルールの下で２００ＰＶＵになる。新しいＶＭがまったく配置されない場合、ＶＭが解任されると次の日の使用率はゼロになる。しかし、ＩＢＭ（Ｒ）ライセンス・メトリック・ツール（ＩＬＭＴ）は、クライアントが自分の全容量および仮想化容量（副容量）を決定するのを支援するものであり、ＰＶＵライセンス要件（またはその他のＰＶＵメトリック・ツール）は、ＶＭが解任されたことを把握していない。このようなツールは、たとえば、何も変化していないものと想定して、４週間カウントし続けることになる。また、これは、本発明の原理によるライセンスを意識した配置を使用して対処することもできる。
【００５８】
図８を参照すると、アプリケーション、仮想計算機、コンピュータ・エンティティなどについてライセンスを意識した配置を行うために、モジュール１１２（およびシステム１８０）によりモデリング構成体３０２を使用することができる。ＶＭ配置はソフトウェア・ライセンス使用率に影響を及ぼす。ソフトウェア・ライセンス料は、ソフトウェアがインストールされたマシンのタイプおよび容量、ならびにソフトウェア・インスタンスに対するリソースの可用性によって決まる。動的配置は、ソフトウェア・ライセンス・ルールの違反を招く可能性がある。例示的な一実施形態によれば、構成体３０２は、接続による関係を定義し、ソフトウェア・コンポーネントのソフトウェア・ライセンス条件を取り込む。それぞれのＶＭ／アプリケーション３０６およびコンテナ３０８は、１つまたは複数の資格のバケット（ＢｏＥ）３０４に関連付けられている。ＢｏＥ３０４は、ライセンス容量およびライセンス使用率の計算ルールを含み、その他の種類の制限もモデリングするために使用することができる。ライセンス条件のタイプは、全容量ベースであるか、副容量ベースであるか、インスタンスの数に基づくか、物理マシンの数などに基づくことができる。
【００５９】
ライセンスを意識した配置によってモニターされる環境には、１つまたは複数のトポロジ３１０が含まれる。トポロジ３１０は、ＶＭ／アプリケーション３０６およびコンテナ３０８に関する構造を提供する。トポロジ３１０、ＶＭ／アプリケーション３０６、およびコンテナ３０８はいずれも、リソース・マネージャ（１１０、図１）によって処理されるリソース要件を有し、性能、システム管理、ライセンスなどに関連する可能性のある制約を含むことができる。
【００６０】
ＢｏＥ３０４は、トポロジ作成時に定義され、配備時に配置システムに提供される。ＢｏＥ３０４は、アプリケーション・モニターを使用して、実行時に検出することができる。ある手法では、ＶＭイメージ３０６はＢｏＥ３０４に関連付けられる。新しいソフトウェアがＶＭにインストールされると、ユーザによって新しいＢｏＥを定義することができる。配置方法（たとえば、図９および図１０を参照）は、（たとえば、強制モードで）ＢｏＥ３０４を超えないことを保証する。一実施形態では、動作モードとしては、ライセンス条件を決して超えない強制モードを含むことができる。他のモードとしては警告モードを含むことができ、たとえば、強制によって性能の低下を招くかどうかをユーザに尋ねるか、または強制によってトポロジの配備が妨げられるかどうかをユーザに尋ねることができる。その他のモードは、特定のシステムに基づいて適合させることができる。
【００６１】
モデリング概念３０２により、有利なことに、配置制約３１４に汎用拡張を追加することができる。これにより、その制約が容易に識別可能になる。資格は、単一マシンまたはアプリケーションに関する制約より複雑な制約３１４の表現を可能にし、すなわち、資格制限は複数のアプリケーションなどにまたがる可能性がある。資格はアーチファクト間で共用することができる。有利なことに、種々のタイプのライセンスについて、また種々のタイプの複雑な制約についても、将来、追加の実装例をサポートするように、配置問題の表現に資格が追加される。
【００６２】
資格プロバイダまたはＢｏＥ３０４は、所与の資格のうちのいくつが使用可能であるか、その資格のうちのいくつが現在使用中であるかを計算する方法、示唆された変更が資格使用率に対してどのような影響を及ぼすかを計算する方法の表現を含むことができる。ＢｏＥ３０４は、公式、要件を含むルックアップ・テーブル、プログラム論理などを含むことができる。配置問題では、資格クライアント３１２は既存のアーチファクト（たとえば、アプリケーション／ＶＭ３０６、コンテナ３０８など）に結びつけられる。単一の資格クライアント３１２は、そのアーチファクトを単一の資格プロバイダ３０４に結びつけ、プロバイダが全体的な使用率を計算するのを支援するためにアーチファクトごとの使用率情報を伝達する。
【００６３】
図９を参照すると、一実施形態により資格を含む模範的な配置方法が示されている。ブロック４０２では、初期配置のために、変更が提案され、計算される。ブロック４０４では、配置ソリューションが改善されたかどうかについて判断が行われる。改善がまったくない場合、最後の最良ソリューションがブロック４０６の出力になる。改善が達成された場合、ブロック４０８で資格違反を回避するために配置ソリューションが変更される。ブロック４１０で十分な時間がある場合、この方法はもう一度繰り返し、ブロック４０２に戻る。十分な時間がない場合、この方法はブロック４０６に移行する。
【００６４】
図１０を参照すると、他の実施形態により資格を含む模範的な配置方法が示されている。ブロック４１２では、初期配置のために、内部で資格を考慮して、候補配置からの変更が計算される。ブロック４１４では、配置ソリューションが十分に改善されたかどうかについて判断が行われる。改善がまったくない場合、最後の最良ソリューションがブロック４１６の出力になる。改善が達成された場合、しかもブロック４２０で十分な時間がある場合、この方法はもう一度繰り返し、ブロック４１２に戻る。十分な時間がない場合、この方法はブロック４１６に移行する。
【００６５】
仮想化環境におけるライセンス資格の管理のためのシステムおよび方法の好ましい諸実施形態（限定のためではなく、例示のためのものである）について説明してきたが、上記の教示を考慮して、当業者により修正および変形が可能であることは注目に値する。したがって、開示されている特定の実施形態において、特許請求の範囲によって概要が示されている本発明の範囲内にある変更を行うことができることを理解されたい。したがって、特許法が要求するように詳細かつ入念に本発明の諸態様について説明してきたが、特許証によって保護される請求内容は特許請求の範囲に明記されている。
【特許請求の範囲】
【請求項１】
仮想化環境のための管理システムであって、
資格に基づく使用制限を有する少なくとも１つのコンピュータ・エンティティと、
プロセッサを使用し、メモリ・ストレージ・デバイス上にプログラミングされ、前記メモリ・ストレージ・デバイスから実行されるリソース・マネージャであって、前記リソース・マネージャが仮想化環境内のリソースを管理するように構成されるリソース・マネージャと、
前記リソース・マネージャに結合され、前記仮想化環境の変化に応じて資格関連制約を追跡し、前記リソース・マネージャが前記資格関連制約を含む割り振り決定を行えるようにして、前記少なくとも１つのコンピュータ・エンティティについて前記使用制限を満たしていることを保証するように構成される、資格使用率モジュールと、
を含む、システム。
【請求項２】
前記少なくとも１つのコンピュータ・エンティティが、仮想計算機、アプリケーション、およびコンテナのうちの少なくとも１つを含む、請求項１記載のシステム。
【請求項３】
前記リソース・マネージャが、少なくとも１つの他の考慮事項に基づいて配置決定を行う、請求項１記載のシステム。
【請求項４】
前記少なくとも１つの他の考慮事項が、性能、コスト、およびセキュリティのうちの少なくとも１つを含む、請求項３記載のシステム。
【請求項５】
前記リソース・マネージャが、候補配置変更に基づいて配置決定を行うように構成されたプログラムを含む、請求項１記載のシステム。
【請求項６】
前記リソース・マネージャが、資格違反を回避するために配置ソリューションを変更することにより配置決定を行うように構成されたプログラムを含む、請求項１記載のシステム。
【請求項７】
前記少なくとも１つのコンピュータ・エンティティに関連し、前記少なくとも１つのコンピュータ・エンティティについて前記資格ベースの制約を識別するように構成される、資格のバケットをさらに含む、請求項１記載のシステム。
【請求項８】
その間に資格を超えることができない強制モードと、前記資格を超えるために個別の許可が必要である警告モードとをさらに含む、請求項１記載のシステム。
【請求項９】
仮想化環境内のリソースを管理するための方法であって、
コンピュータ記憶媒体内に１組の資格に関する制約を表すステップと、
配置すべきコンピューティング・エンティティについて、許可される資格の数およびタイプを決定するステップと、
結果として得られる配置ソリューションが現在使用可能な前記資格を超えないように、配置プログラムが進行するにつれて、プロセッサを使用して、現行候補配置ソリューションについて資格使用率を計算するステップと、
を含む、方法。
【請求項１０】
１組の資格に関する制約を表す前記ステップが、制約情報を含むファイルについて指定された拡張を提供するステップを含む、請求項９記載の方法。
【請求項１１】
前記１組の資格に関する前記制約によりリソース使用率を制限するステップをさらに含む、請求項９記載の方法。
【請求項１２】
前記コンピューティング・エンティティが仮想計算機を含む、請求項９記載の方法。
【請求項１３】
前記１組の資格がライセンス条件を含み、前記方法が、コンピュータ・エンティティおよびモデル・ライセンス制約に関連する資格のバケット内に前記ライセンス条件を取り込むステップをさらに含む、請求項９記載の方法。
【請求項１４】
結果として得られる配置ソリューションが現在使用可能な前記資格およびそれぞれのメトリックのしきい値を超えないように、現行候補配置ソリューションについて、性能メトリック、コスト・メトリック、およびセキュリティ・メトリックのうちの少なくとも１つを計算するステップをさらに含む、請求項９記載の方法。
【請求項１５】
資格違反を回避するために配置ソリューションを変更するステップをさらに含む、請求項９記載の方法。
【請求項１６】
その間に資格を超えることができない強制モードと、前記資格を超えるために個別の許可が必要である警告モードとを提供するステップをさらに含む、請求項９記載の方法。
【請求項１７】
各資格タイプの現行レベルの使用率を呼び出し側に提供するステップをさらに含む、請求項９記載の方法。
【請求項１８】
コンピュータ・プログラムであって、請求項９乃至１１および請求項１３乃至１７のいずれかに記載の前記ステップすべてを実行するようになっているコンピュータ・プログラム。
【請求項１】
仮想化環境のための管理システムであって、
資格に基づく使用制限を有する少なくとも１つのコンピュータ・エンティティと、
プロセッサを使用し、メモリ・ストレージ・デバイス上にプログラミングされ、前記メモリ・ストレージ・デバイスから実行されるリソース・マネージャであって、前記リソース・マネージャが仮想化環境内のリソースを管理するように構成されるリソース・マネージャと、
前記リソース・マネージャに結合され、前記仮想化環境の変化に応じて資格関連制約を追跡し、前記リソース・マネージャが前記資格関連制約を含む割り振り決定を行えるようにして、前記少なくとも１つのコンピュータ・エンティティについて前記使用制限を満たしていることを保証するように構成される、資格使用率モジュールと、
を含む、システム。
【請求項２】
前記少なくとも１つのコンピュータ・エンティティが、仮想計算機、アプリケーション、およびコンテナのうちの少なくとも１つを含む、請求項１記載のシステム。
【請求項３】
前記リソース・マネージャが、少なくとも１つの他の考慮事項に基づいて配置決定を行う、請求項１記載のシステム。
【請求項４】
前記少なくとも１つの他の考慮事項が、性能、コスト、およびセキュリティのうちの少なくとも１つを含む、請求項３記載のシステム。
【請求項５】
前記リソース・マネージャが、候補配置変更に基づいて配置決定を行うように構成されたプログラムを含む、請求項１記載のシステム。
【請求項６】
前記リソース・マネージャが、資格違反を回避するために配置ソリューションを変更することにより配置決定を行うように構成されたプログラムを含む、請求項１記載のシステム。
【請求項７】
前記少なくとも１つのコンピュータ・エンティティに関連し、前記少なくとも１つのコンピュータ・エンティティについて前記資格ベースの制約を識別するように構成される、資格のバケットをさらに含む、請求項１記載のシステム。
【請求項８】
その間に資格を超えることができない強制モードと、前記資格を超えるために個別の許可が必要である警告モードとをさらに含む、請求項１記載のシステム。
【請求項９】
仮想化環境内のリソースを管理するための方法であって、
コンピュータ記憶媒体内に１組の資格に関する制約を表すステップと、
配置すべきコンピューティング・エンティティについて、許可される資格の数およびタイプを決定するステップと、
結果として得られる配置ソリューションが現在使用可能な前記資格を超えないように、配置プログラムが進行するにつれて、プロセッサを使用して、現行候補配置ソリューションについて資格使用率を計算するステップと、
を含む、方法。
【請求項１０】
１組の資格に関する制約を表す前記ステップが、制約情報を含むファイルについて指定された拡張を提供するステップを含む、請求項９記載の方法。
【請求項１１】
前記１組の資格に関する前記制約によりリソース使用率を制限するステップをさらに含む、請求項９記載の方法。
【請求項１２】
前記コンピューティング・エンティティが仮想計算機を含む、請求項９記載の方法。
【請求項１３】
前記１組の資格がライセンス条件を含み、前記方法が、コンピュータ・エンティティおよびモデル・ライセンス制約に関連する資格のバケット内に前記ライセンス条件を取り込むステップをさらに含む、請求項９記載の方法。
【請求項１４】
結果として得られる配置ソリューションが現在使用可能な前記資格およびそれぞれのメトリックのしきい値を超えないように、現行候補配置ソリューションについて、性能メトリック、コスト・メトリック、およびセキュリティ・メトリックのうちの少なくとも１つを計算するステップをさらに含む、請求項９記載の方法。
【請求項１５】
資格違反を回避するために配置ソリューションを変更するステップをさらに含む、請求項９記載の方法。
【請求項１６】
その間に資格を超えることができない強制モードと、前記資格を超えるために個別の許可が必要である警告モードとを提供するステップをさらに含む、請求項９記載の方法。
【請求項１７】
各資格タイプの現行レベルの使用率を呼び出し側に提供するステップをさらに含む、請求項９記載の方法。
【請求項１８】
コンピュータ・プログラムであって、請求項９乃至１１および請求項１３乃至１７のいずれかに記載の前記ステップすべてを実行するようになっているコンピュータ・プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【公開番号】特開２０１１−２５３５２３（Ｐ２０１１−２５３５２３Ａ）
【公開日】平成２３年１２月１５日（２０１１．１２．１５）
【国際特許分類】
【出願番号】特願２０１１−１０２７０５（Ｐ２０１１−１０２７０５）
【出願日】平成２３年５月２日（２０１１．５．２）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡ
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
【公開日】平成２３年１２月１５日（２０１１．１２．１５）
【国際特許分類】
【出願日】平成２３年５月２日（２０１１．５．２）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡ
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
[ Back to top ]