(57)【要約】  仮想マシン環境におけるハードウェアの仮想化およびリソース管理を提供する、システムおよび方法。ある実施形態によれば、アプリケーションサーバ環境は、コンピュータシステム、アプリケーションサーバおよび仮想マシン（例えば、Ｊａｖａ（登録商標）仮想マシン（すなわちＪＶＭ））を含んでいる。ある実施形態によれば、各物理的なマシンに、仮想化レイヤが提供される。これは、マシン上で仮想マシンを分割するためのハイパーバイザを含んでいる。実行レイヤは、１つのＪａｖａ（登録商標）ベースのアプリケーションを作動し、このアプリケーションをできるだけ効率的に作動することに集中する。他の実施形態によれば、システムは、２つの主な構成要素を含んでいる。すなわち、低レベル、つまり、通常のオペレーティングシステムに代わる実行環境である。そして、高レベル、つまりリソースブローカである。このリソースブローカは、新しい仮想マシンを上位のレイヤに分配すること、および、作動している仮想マシンにおける現在のリソースの使用量をモニタすること、に関与する。
2010500667.tif 000002
【特許請求の範囲】
【請求項１】
仮想マシン環境におけるハードウェア仮想化を提供するためのシステムであって、
仮想化レイヤをさらに有するマシンまたはコンピュータを備え、前記仮想化レイヤは、マシン上で仮想マシンを分割するためのハイパーバイザを含み、さらに
１つのＪａｖａ（登録商標）ベースのアプリケーションを実行するように構成されている実行レイヤと、
Ｊａｖａ（登録商標）ベースのアプリケーションの作動において使用するための、実行レイヤ上で作動するＪａｖａ（登録商標）仮想マシンとを備える、システム。
【請求項２】
複数のマシンと、各マシンに配されている仮想化レイヤとをさらに備える、請求項１に記載のシステム。
【請求項３】
前記実行レイヤは、他のいずれのアプリケーションも実行できない状態で、特定の時間において、前記１つのＪａｖａ（登録商標）ベースのアプリケーションだけを実行することに集中するように構成される、請求項１に記載のシステム。
【請求項４】
前記実行レイヤは、できるだけ効率的に、前記１つのＪａｖａ（登録商標）ベースのアプリケーションを実行するように構成される、請求項３に記載のシステム。
【請求項５】
前記システムは、複数の実行レイヤをさらに備えており、前記実行レイヤの各々は、一度に１つのＪａｖａ（登録商標）ベースのアプリケーションだけをできるだけ効率的に実行するように構成されている、請求項１に記載のシステム。
【請求項６】
複数の実行レイヤの各々は、他のいずれのアプリケーションも実行できない状態で、特定の時間において、前記１つのＪａｖａ（登録商標）ベースのアプリケーションだけを実行することに集中するように構成される、請求項５に記載のシステム。
【請求項７】
複数の実行レイヤは、ハイパーバイザ、仮想化レイヤ、およびマシンにおける同一の組み合わせ上に配置される、請求項５に記載のシステム。
【請求項８】
仮想マシン環境におけるハードウェア仮想化を提供するためのシステムであって、
仮想化レイヤを含むマシンを備え、前記仮想化レイヤは、物理的なマシン上で仮想マシンを分割するためのハイパーバイザを含み、さらに
前記マシン上で作動する複数のＪａｖａ（登録商標）仮想マシンと、
前記複数のＪａｖａ（登録商標）仮想マシンの各々のための個別の実行レイヤを含む、複数の実行レイヤとを備え、前記実行レイヤの各々は、それ自身のＪａｖａ（登録商標）仮想マシンおよびその上で作動しているＪａｖａ（登録商標）アプリケーションにおける、効率的な実行を提供する、システム。
【請求項９】
前記実行レイヤの各々は、他のいずれのアプリケーションも作動できない状態で、それ自身のＪａｖａ（登録商標）仮想マシンおよびその上で作動している１つのＪａｖａ（登録商標）アプリケーションにおける、効率的な実行を提供する、請求項８に記載のシステム。
【請求項１０】
各実行レイヤは、前記Ｊａｖａ（登録商標）アプリケーションを実行するＪＶＭプロセスを、単一プロセスとして、もっぱら処理するオペレーティングシステム（ＯＳ）として提供される、請求項８に記載のシステム。
【請求項１１】
前記ハイパーバイザは、２つ以上の仮想化レイヤと、それらの上で実行されているＪａ
ｖａ（登録商標）仮想マシンとの間でメモリが共有されることを可能とする、請求項８に記載のシステム。
【請求項１２】
前記各Ｊａｖａ（登録商標）仮想マシンのための実行レイヤは、前記ハイパーバイザ・レイヤに対し、異なるＪａｖａ（登録商標）仮想マシン間で共有されている同一のページの存在を知らせる、請求項８に記載のシステム。
【請求項１３】
前記ハイパーバイザは、コピー・オン・ライト（ｃｏｐｙ−ｏｎ−ｗｒｉｔｅ）を用いて、前記同一のページが同じ物理的なページにマップされることを可能とする、請求項１２に記載のシステム。
【請求項１４】
前記ハイパーバイザは、Ｘｅｎハイパーバイザである、請求項８に記載のシステム。
【請求項１５】
前記ハイパーバイザは、ＶＭｗａｒｅハイパーバイザである、請求項８に記載の方法。
【請求項１６】
仮想マシン環境におけるハードウェア仮想化を提供するためのシステムであって、
１つ以上のマシン上で動作する複数の仮想マシンをさらに有する、１つ以上のマシンまたはコンピュータと、
各マシンに配されており、そのマシン上で仮想マシンを分割するためのハイパーバイザを含んでいる仮想化レイヤと、
リソースブローカ・サービスとを備え、前記リソースブローカ・サービスは、
仮想マシンによって与えられるリソースにアクセスするためのリクエストを、アプリケーションから受け取り、
複数の仮想マシンのうち、このリクエストを取り扱うために最適なものを決定し、
仮想化レイヤを介して、選択した仮想マシンに前記リクエストを伝達する、システム。
【請求項１７】
前記最適な仮想マシンに対するリクエストの伝達に関与する、複数のリソースブローカ・エージェントをさらに備える、請求項１６に記載のシステム。
【請求項１８】
前記仮想化レイヤおよびリソースブローカ・サービスは、リクエストを生成したアプリケーションに関する所定の保証に従って、リクエストを配分する、請求項１６に記載のシステム。
【請求項１９】
前記ハイパーバイザは、Ｘｅｎハイパーバイザである、請求項１６に記載のシステム。
【請求項２０】
前記ハイパーバイザは、ＶＭｗａｒｅハイパーバイザである、請求項１６に記載のシステム。
【請求項２１】
仮想マシン環境におけるハードウェア仮想化を提供するためのシステムであって、
１つ以上の物理的なマシンまたはコンピュータ上で作動する複数の仮想マシンと、
各マシンの仮想化レイヤとを備え、前記仮想化レイヤは、物理的なマシン上で仮想マシンを分割するためのハイパーバイザおよび実行レイヤを含み、さらに
リソースブローカ・サービスを備え、前記リソースブローカ・サービスは、仮想マシンによって与えられるリソースにアクセスするためのリクエストをアプリケーションから受け取り、複数の仮想マシンのうちこのリクエストを取り扱うために最適なものを決定し、仮想化レイヤを介して、選択した仮想マシンに前記リクエストを伝達する、システム。
【請求項２２】
前記最適な仮想マシンに対するリクエストの伝達に関与するエージェントを含む、複数のリソースブローカ・エージェントをさらに備える、請求項２１に記載のシステム。
【請求項２３】
前記仮想化レイヤおよびリソースブローカ・サービスは、リクエストを生成したアプリケーションに関する所定の保証に従って、リクエストを配分する、請求項２１に記載のシステム。
【請求項２４】
前記ハイパーバイザは、Ｘｅｎハイパーバイザである、請求項２１に記載のシステム。
【請求項２５】
前記ハイパーバイザは、ＶＭｗａｒｅハイパーバイザである、請求項２１に記載のシステム。
【請求項２６】
仮想マシン・プロキシをさらに備え、前記仮想マシン・プロキシは、第１の物理的なマシンにおけるオペレーティングシステムを介して、第２の物理的なマシンにおける仮想化レイヤおよび仮想マシンに対して、アプリケーションがリクエストを通過させることを可能とする、請求項２１に記載のシステム。
【請求項２７】
仮想マシン環境におけるハードウェア仮想化を提供するための方法であって、
マシン上で仮想マシンを分割するためのハイパーバイザを含んでいる仮想化レイヤをさらに有する、マシンまたはコンピュータを提供するステップと、
１つのＪａｖａ（登録商標）ベースのアプリケーションが実行するように構成されている実行レイヤを提供するステップと、
Ｊａｖａ（登録商標）ベースのアプリケーションの実行において使用するための、実行レイヤ上で作動するＪａｖａ（登録商標）仮想マシンを提供するステップとを備える、方法。
【請求項２８】
複数のマシンと、各マシンに配されている仮想化レイヤとを提供するステップをさらに備える、請求項２７に記載の方法。
【請求項２９】
前記実行レイヤは、他のいずれのアプリケーションも実行できない状態で、特定の時間において、前記１つのＪａｖａ（登録商標）ベースのアプリケーションだけを実行することに集中するように構成される、請求項２７に記載の方法。
【請求項３０】
前記実行レイヤは、できるだけ効率的に、前記１つのＪａｖａ（登録商標）ベースのアプリケーションを実行するように構成される、請求項２９に記載の方法。
【請求項３１】
仮想マシン環境におけるハードウェア仮想化を提供するための方法であって、
仮想マシンによって与えられるリソースにアクセスするためのリクエストを、アプリケーションから受け取るステップと、
複数の仮想マシン、または、複数の物理的なマシンもしくはコンピュータのうち、当該リクエストを取り扱うために最適なものを決定するステップと、
選択された物理的なマシンまたは仮想マシン上で動作する仮想マシンを生成または管理するために、実行レイヤおよびハイパーバイザを含んでいる仮想化レイヤを用いて前記リクエストを伝達するステップと、
選択された仮想マシンにおいて前記リクエストを処理するステップとを備える、方法。
【請求項３２】
前記最適な仮想マシンに対するリクエストの伝達に関与するエージェントを含む、複数のリソースブローカ・エージェントを提供するステップをさらに備える、請求項３１に記載の方法。
【請求項３３】
前記仮想化レイヤおよびリソースブローカ・サービスは、リクエストを生成したアプリケーションに関する所定の保証に従って、リクエストを配分する、請求項３１に記載の方
法。
【請求項３４】
前記ハイパーバイザは、Ｘｅｎハイパーバイザである、請求項３１に記載の方法。
【請求項３５】
前記ハイパーバイザは、ＶＭｗａｒｅハイパーバイザである、請求項３１に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
発明者：ダールステット，ヨーキム
（著作権情報）
この特許文献における開示の一部は、著作権保護下にある内容を含んでいる。その著作権者は、特許商標庁のファイルまたは記録に記載されているものである場合には、この特許文献または特許情報開示に対するいずれの者によるファクシミリ再生についても、異議を唱えるものではない。しかしながら、そうでない場合には、著作権者は、著作権その他すべての権限を有する。
【０００２】
（優先権主張）
この出願は、仮特許出願「仮想マシン環境におけるハードウェア仮想化を提供するためのシステムおよび方法（ＳＹＳＴＥＭ  ＡＮＤ  ＭＥＴＨＯＤ  ＦＯＲ  ＰＲＯＶＩＤＩＮＧ  ＨＡＲＤＷＡＲＥ  ＶＩＲＴＵＡＬＩＺＡＴＩＯＮ  ＩＮ  Ａ  ＶＩＲＴＵＡＬ  ＭＡＣＨＩＮＥ  ＥＮＶＩＲＯＮＭＥＮＴ）；米国出願番号６０／８２１，６７３、出願日２００６年８月７日」、ならびに「仮想マシン環境におけるハードウェアの仮想化を提供するためのシステムおよび方法；米国出願番号１１／８３５，３０７、出願日２００７年８月７日」における利益を主張する。これらの出願は、参照することにより、ここに組み込まれている。
【０００３】
（発明の分野）
本発明は、一般的には、オペレーティングシステム、アプリケーションサーバ、および仮想マシンに関する。より詳細には、本発明は、仮想マシン環境におけるハードウェアの仮想化およびリソース管理を提供するためのシステムおよび方法に関する。
【背景技術】
【０００４】
（背景）
今日における必須のビジネスアプリケーションの多くは、Ｊａｖａ（登録商標）ベースのアプリケーションサーバ（例えば、Ｊａｖａ（登録商標）２のエンタープライズエディションまたはＪ２ＥＥの仕様書に準拠しているプリケーションサーバを含む）において、発展および展開されている。これらのアプリケーションは、伝統的には、シングルベンダのＲＩＳＣコンピュータおよびサーバ、ならびに他の高価なハードウェアプラットフォームにおいて展開されてきている。容易に利用可能でより低コストのＰＣベースのサーバは、適切な代替品とは考えられてこなかった。これは、これらのアーキテクチャとともに使用することの可能な、競争力のある高い性能をもつＪａｖａ（登録商標）仮想マシン（Ｊａｖａ（登録商標）  Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ：ＪＶＭ）がなかったためである。例えばＢＥＡ  Ｓｙｓｔｅｍｓ社のＪＲｏｃｋｉｔ製品のような最新の仮想マシン環境は、ＰＣベースのものを含むさまざまな環境での使用に対してこれらの仮想マシンを最適化することを可能とし、より高い信頼性および性能をもって、低コストの標準ベースのプラットフォームでＪａｖａ（登録商標）アプリケーションが作動できるようにする、という問題に取り組んでいる。ＪＲｏｃｋｉｔ仮想マシンは、要求の厳しいサーバーサイドのＪａｖａ（登録商標）アプリケーションを実行させ、優れた性能、管理容易性および信頼性を実現するために特に適切に設計された、仮想マシンの一例である。
【０００５】
現在の仮想マシン製品の提供は、ソフトウエアによる仮想化については習熟している。しかしながら、現在まで、アプリケーションサーバを仮想プロセスを制御もしくは仮想プロセスに関与できるようにしたままで、その土台となるハードウェアもしくはオペレーテ
ィングシステムのレベルにおける仮想化をサポートすること、または仮想マシンレベルでリソースを管理すること、についてはほとんど実施されてこなかった。
【発明の概要】
【課題を解決するための手段】
【０００６】
（概要）
ここに、仮想マシン環境におけるハードウェア仮想化およびリソース管理を提供するための、システムおよび方法が開示されている。ある実施形態によれば、コンピュータシステム、アプリケーションサーバおよび仮想マシン（例えば、Ｊａｖａ（登録商標）仮想マシン、すなわちＪＶＭ）を含む、アプリケーションサーバ環境が拡張される。これにより、アプリケーションサーバ環境におけるより高いレイヤからシステムにおける実際の処理能力へのインターフェイスを提供し、マシンに依存しない方法で処理の割り当てを実行することが可能となる。ソフトウエアのレイヤは、仮想マシンと仮想化されたＪａｖａ（登録商標）実行システムの効率性を改善するハードウェアとの間に、配されている。ある実施形態によれば、システムは、２つの主な構成要素を有している。すなわち、第１には、低レベル、つまり、通常のオペレーティングシステムに代わる実行環境である。そして、第２には、高レベル、つまりリソースブローカ（ｒｅｓｏｕｒｃｅ  ｂｒｏｋｅｒ）である。このリソースブローカは、新しい仮想マシンを上位のレイヤに分配すること、および、作動している仮想マシンにおける現在のリソースの使用量をモニタすること、に関与する。このように、土台となる物理的マシンを、多数のＪＶＭをサポートするために分割することが可能となっている。加えて、ＣＰＵおよび他のリソースの割り当てに関して、システム内に目標を設定することも可能であり、さらに、システムは、適切にＪＶＭを割り当てることが可能である。
【図面の簡単な説明】
【０００７】
【図１】本発明の実施形態に従う仮想マシンを含む、アプリケーションサーバ環境の実例を示す図である。
【図２】本発明の実施形態に従う階層化された仮想マシンアーキテクチャの実例を示す図である。
【図３】本発明の実施形態に従う複数の階層化されたドメイン環境の実例を示す図である。
【図４】本発明の実施形態に従うユーティリティ・コンピューティング環境において、仮想化レイヤの実施形態をいかに使用することが可能であるのかについて例示する図である。
【図５】本発明の実施形態に従うベアメタル・ドメインの実例をリソースブローカとともに示す図である。
【図６】本発明の実施形態に従うベアメタル・ドメインの実例をＪＶＭプロキシとともに示す図である。
【図７】本発明の実施形態に従う仮想マシン環境のコンポーネントにおける、論理図を示す図である。
【図８】本発明の実施形態に従う仮想化を用いる方法におけるフローチャートを示す図である。
【発明を実施するための形態】
【０００８】
（詳細な説明）
ここに、仮想マシン環境におけるハードウェア仮想化およびリソース管理を提供するためのシステムおよび方法が開示される。ある実施形態によれば、コンピュータシステム、アプリケーションサーバおよび仮想マシン（例えば、Ｊａｖａ（登録商標）仮想マシン、すなわちＪＶＭ）を含む、アプリケーションサーバ環境が拡張される。これにより、アプリケーションサーバ環境におけるより高いレイヤからシステムにおける実際の処理能力へ
のインターフェイスを提供し、マシンに依存しない方法で処理の割り当てを実行することが可能となる。ソフトウエアのレイヤは、仮想マシンと仮想化されたＪａｖａ（登録商標）実行システムの効率性を改善するハードウェアとの間に配されている。ある実施形態によれば、システムは、２つの主な構成要素を有している。すなわち、第１には、低レベル、つまり、通常のオペレーティングシステムに代わる実行環境である。そして、第２には、高レベル、つまりリソースブローカである。このリソースブローカは、新しい仮想マシンを上位のレイヤに分配すること、および、作動している仮想マシンにおける現在のリソースの使用量をモニタすること、に関与する。このように、土台となる物理的マシンを、多数のＪＶＭをサポートするために分割することが可能となっている。加えて、ＣＰＵおよび他のリソースの割り当てに関して、システム内に目標を設定することも可能であり、さらに、システムは、適切にＪＶＭを割り当てることが可能である。
【０００９】
（用語集）
本明細書では、以下の用語が使用されている。
【００１０】
ドメイン：ハイパーバイザ・レイヤの上で実行されるオペレーティングシステムのインスタンス。多数のドメインが、互いに関知することなく、同一のマシン上で作動することが可能である。本明細書では、ドメインを、ゲスト・オペレーティングシステム（ＯＳ）、ゲストまたはＶＭと称することもある。
【００１１】
ベアメタル・ドメイン：本発明の実施形態に従うアプリケーション、仮想化レイヤ、および仮想マシンを実行するドメイン（例えば、一実施形態では、ベアメタル・ドメインは、ベアメタル・オペレーティングシステム（ＯＳ）レイヤに、ＪＶＭ（例えばＪＲｏｃｋｉｔＪＶＭ）を加えたもの、アプリケーションを加えたものを含む）。本明細書では、ベアメタル・ドメインを、ＢＭドメインと称することもある。
【００１２】
ノード：ネットワーク内にある物理的なマシンまたは物理的なコンピュータ。
グリッド・コンピューティング：単一のコンピュータ問題をともに解決するために機能する、多数のノードのセット。
【００１３】
ユーティリティ・コンピューティング：多くのアプリケーションが多くの物理的なマシン上で効率的に実行されることを可能とする、システムまたは環境。ユーティリティ・コンピューティング環境は、特定のアプリケーションのどれを優先するべきかをシステムが決定することを補助するために、アプリケーションにおいて高レベルのポリシーが特定されることを可能とする。ユーティリティ・コンピューティング環境は、さらに、ユーザが、新しいアプリケーションをシステムに展開すること、各アプリケーションに関して高レベルのポリシーおよび／または保証を提供すること、アプリケーションおよびマシンの状態をモニタすること、特定のアプリケーションに対するリソースの利用における急速な増大に対処すること、システムのアップグレードを設定すること、および、高い利用性を提供すること、を可能とする。
【００１４】
図１は、仮想マシンを含み、本発明の実施形態とともに使用されることの可能なアプリケーションサーバ環境の実例を示している。図１に示されているように、アプリケーションサーバ環境１０は、アプリケーションサーバ１４（例えば、ＢＥＡ  Ｓｙｓｔｅｍｓ社によって開発されたＷｅｂＬｏｇｉｃサーバ製品、または他のタイプのアプリケーションサーバ）を、仮想マシン１６（例えば、同様にＢＥＡ  Ｓｙｓｔｅｍｓ社によって開発されたＪＲｏｃｋｉｔＪＶＭ、または他のタイプの仮想マシン）とともに含んでいる。図１は、また、アプリケーションサーバ環境において頻繁に使用される、例えば、開発環境１８、ユーザ統合コンポーネント２０、またはプロセス統合コンポーネント２２などの、任意的なコンポーネントを例示している。これらの任意的なコンポーネントにおける後者の
例としては、それぞれＷｅｂＬｏｇｉｃＷｏｒｋｓｈｏｐ製品、ＷｅｂＬｏｇｉｃＰｏｒｔａｌ製品、およびＷｅｂＬｏｇｉｃＩｎｔｅｇｒａｔｉｏｎ製品が挙げられる。これらも、それぞれＢＥＡ  Ｓｙｓｔｅｍｓ社によって開発されたものである。追加的なコンポーネントを、必要に応じて、この環境に追加することも可能である。
【００１５】
図２は、ある実施形態に従う仮想マシンアーキテクチャにおける、より詳細な実例を示している。図２に示されているように、ＪＲｏｃｋｉｔＪＶＭのような一般的な仮想マシン１６は、システムにおいて実行しているスレッドを管理するスレッド管理コンポーネント１８、ガーベジコレクションのような処理を管理するメモリ管理コンポーネント２０、コード生成コンポーネント２２、およびＪａｖａ（登録商標）モデルコンポーネント２４を備えている。また、一般的な仮想マシンは、仮想マシンの管理に使用するための外部インターフェイス２８を提供する。図２はＪＲｏｃｋｉｔ製品を示しているが、本発明の精神および範囲内において、ＪＲｏｃｋｉｔの実装品に加えて他の仮想マシンを使用できることは明らかであろう。
【００１６】
有効なアプリケーション仮想化を可能とするために、これに対応する、有効なハードウェアリソース仮想化が要求される。これにより、サスペンション、ライブ・プロビジョニング、およびライブ・マイグレーションといった機能を提供することが可能となる。本発明の実施形態によれば、抽象化の外部レイヤが加えられる。これは、土台となるハードウェアに対して比較的に近くに仮想マシンを移動することを可能とする。
【００１７】
図３は、本発明の実施形態に従う複数の階層化されたドメイン環境の実例を示している。図３に示されているように、コンピュータ環境３０は、物理的なコンピュータハードウェア、またはコンピュータマシン３２を備えている。このマシンについては、物理的なサーバ、コンピュータマシン、ネットワークデバイス、または、コンピュータデバイスもしくは処理デバイスの等価タイプとすることが可能である。このコンピュータ環境は、仮想化レイヤ３４を含んでいる。この仮想化レイヤ３４は、一般的なオペレーティングシステムの代わりに、処理デバイスの上部に論理的に位置している。実施形態によれば、この仮想化レイヤは、実行レイヤコンポーネント３８（本明細書では、ベアメタル・レイヤとも称される）、および、ハイパーバイザ・レイヤコンポーネント４０、すなわちハイパーバイザ・レイヤを備えている。現在において有効なハイパーバイザ・レイヤコンポーネントの例としては、Ｘｅｎハイパーバイザ、および、ＶＭＷａｒｅハイパーバイザが挙げられる。他のハイパーバイザ・レイヤおよびハイパーバイザ・レイヤコンポーネントを、他の実施形態にしたがって使用することも可能である。
【００１８】
ハイパーバイザ・レイヤは、サーバのハードウェアとオペレーティングシステムとの間に挿入されている。これは、抽象化レイヤを提供する。この抽象化レイヤは、物理的なサーバのそれぞれが１つ以上の仮想的なサーバを実行することを可能とするとともに、オペレーティングシステムおよびそのアプリケーションを、土台となる物理的なサーバから効果的に切り離すものである。この場合、いったん仮想的なサーバイメージが生成されると、それは、どのサーバ上であっても実行されることが可能となる。同様の原理で、多数の仮想的なサーバは、単一の物理的なサーバまたはマシンを、同時に共有することが可能である。正味の影響は、全体的なサーバ利用を増加することにあり、それと同時に、全ての特定のアプリケーションレイヤにおける性能基準が満足されることを確保するという、リソース保証を得る。
【００１９】
図３にさらに例示されているように、仮想マシン１６は、論理的に、仮想化レイヤの上位に配置されている。ある実施形態によれば、この場合、リソースブローカ３６、またはリソースブローカ・サービスのセットは、仮想マシンの上位の層に提供される。リソースブローカは、アプリケーションサーバ１４、および、他のアプリケーションによって、仮
想化レイヤによって提供されるサービスを利用するために使用される。
【００２０】
いくつかの実施形態では、ローカルネットワーク内におけるＪａｖａ（登録商標）アプリケーションに関するハードウェア仮想化サービスを提供することによって、上記システムを、ユーティリティ・コンピューティング環境の全体における一部として使用することが可能である。ユーティリティ・コンピューティング環境に関連して使用される場合、ネットワーク化されたアプリケーションが仮想マシンと連動することを可能とする、サービスを提供することが可能である。ユーティリティ・コンピューティング環境または多重仮想マシン環境において、提供することの可能なサービスの例としては、以下のものが挙げられる。
【００２１】
・ネットワーク化された環境内におけるいずれかの場所に、新しい仮想マシンまたはＪＶＭを形成する能力
・最小および最大のＣＰＵ、メモリまたはネットワークのバンド幅の利用量のような、リソースの保証
・リソース計測、およびシステムの温度自動調整機能
・より多くの、またはより少ないリソースをアプリケーションが必要とする場合に、これらのリソースを動的に増加または減少する能力
・作動しているアプリケーションをディスクに「一時保留」する、または、それをディスクから「再開」するような機能（本明細書では、「フリーズドライ」と称する）
・「フリーズドライ化された」アプリケーションのクローンを作る能力（Ｕｎｉｘ（登録商標）のｆｏｒｋのような機能と類似のもの、すなわちクローンされたアプリケーションを新しいインスタンス特定値とともに例示する）
・予定されているシステムメンテナンスのために、作動しているインスタンスを他のコンピュータマシンに移動する能力
図４は、ユーティリティ・コンピューティング環境５０内において仮想化レイヤの実施形態をいかに使用することが可能であるのかについての実例を示している。図４に示されているように、アプリケーションは、アプリケーション仮想化機能５２を使用することが可能である。この機能は、アプリケーションサーバ群５６を介して、土台となるハードウェアの仮想化レイヤ５４にアクセスするために、例えば、上記ユーティリティ・コンピューティング・サービスまたはリソースブローカ・サービスを含んでいる。ある実施形態によれば、アプリケーションサーバ群を、ＷｅｂＬｏｇｉｃサーバ環境とすることが可能である。これは、同様に、企業向けクラスタリングなどの、他の高度なサーバ機能を提供することが可能である。
【００２２】
図５は、本発明の実施形態に従うベアメタル・ドメインの実例を、リソースブローカとともに示している。本発明の実施形態によれば、このリソースブローカは、アプリケーションサーバ、および、そこで作動している他のソフトウエア・アプリケーションに対して、サブサービスを提供する。これらのサブサービスは、例えば、新しいＪＶＭを得ること、サーバ上で作動するＪＶＭを設定すること、特定のＪＶＭのリソースを計測すること、および、ＪＶＭのリソースを制御すること、を含むことが可能である。実施形態によれば、ＪＶＭの生成に関する主なコンポーネントは、（上記したような）リソースブローカ６８である。これは、このインスタンスでは、マシン６０，６２のうち、新しい仮想化レイヤのインスタンスを生成するために有効なものを追跡する。実施形態によれば、リソースブローカ・エージェント（ＲＢＡ）６４，６６は、各マシン上に配置されている。他の実施形態によれば、物理的なマシンとエージェントとの間における、どのような１対１のマッピングも不要である。例えば、単一のエージェントが、多数の物理的なマシンをカバーすることが可能である。リソースブローカ・エージェントは、ＪＶＭインスタンス７０，７２，７４の局所的な生成、すなわち、エージェントと同一の物理的なマシン上で動作するＪＶＭの生成および管理に関与する。第１のマシンから第２のマシンへの、または、ク
ラスタ中における、全ての外部通信は、まず、リソースブローカを介して流れる。この場合、リソースブローカは、応答のあったリソースブローカ・エージェントに対するリクエストを指示する。このように、リソースブローカは、エージェント群のように動作し、アプリケーションからのリクエストを遂行するために必要な有効なパワーを有するどの特定のマシンを、どの特定のエージェントが制御するか、について把握する。
【００２３】
ある実施形態によれば、リソースブローカは、一般的なハードウェアの抽象化レイヤである。それは、潛在的に、多数の異なるタイプのマシンとともに使用することの可能なものである。マシンのタイプが領域分割（ｐａｒｔｉｔｉｏｎｉｎｇ）をサポートとしている場合、リソースブローカは、必要に応じて、マシンを領域分割する機能を使用することが可能である。特定のマシンタイプがサポートしている機能に応じて、ハイエンドの機能における異なる部分を有効とすることが可能となる。控えめにいっても、この機能は、リソース利用量における概算の目標値（例えば、少なくとも制限的な保証、制限的な共有、サスペンションなし、およびマイグレーションなし）をもって、新しいＪＶＭがマシン上で生成されることを可能とするはずである。
【００２４】
リソースブローカが実行レイヤと組み合わされた場合、システムは、より良好に作動し、さらに、より広い範囲の機能をサポートすることになるけれども、リソースブローカ自体は、その機能の多くを実行するために、実行レイヤ（つまり、ベアメタル・レイヤ）を必要としないことに注意されたい。
【００２５】
通常の、すなわち非仮想化マシンについては、リソースブローカに加えることが可能であることに注意されたい（ただし、これらの場合には、機能は減少される）。他の実施形態によれば、リソースブローカは、サードパーティ・システムに関するサポートを含むことが可能である。このサードパーティ・システムの例としては、Ａｚｕｌ、Ｓｏｌａｒｉｓ  Ｃｏｎｔａｉｎｅｒｓ、および他のハイパーバイザ・スタックが挙げられる。ある実施形態によれば、ＸｅｎドメインおよびＶＭＷａｒｅゲストも、ネイティブのベアメタル・リソースの保証、リソースの共有、サスペンション、マイグレーション、ホットプラグ可能性、および仮想化ファイルシステムをサポートすることが可能である。
【００２６】
（ＪＶＭプロキシ）
図６は、本発明の実施形態に従うベアメタル・ドメインの実例を、任意的なＪＶＭプロキシとともに示している。上述したように、いくつかの実施形態では、リソースブローカ・サービスは、単独の構成要素のように動作することが可能である。しかしながら、これらの場合には、全ての要素の組み合わせによって提示されるような、同一のリソースの共有および同一のリソースの保証を得られないことになる。図６に示されているように、物理的なサーバマシン８０は、その上で作動する多くのＪＶＭを有することが可能であり、場合によっては、ＪＮＩコードの実行および現実のドライバのアクセスが、通常のオペレーティングシステム（ＯＳ）９０によって取り扱われる。ハイパーバイザ・レイヤ９６の上でそれが実行されている場合には、実行レイヤ９２，９４は、その上で実行しているＪＶＭ８６，８８のいずれについても、その実行を最適化するように構築される。具体的には、ハイパーバイザ・レイヤ／実行レイヤの組み合わせは、データにおける孤立およびコピー・オン・ライトでの共有をサポートし、これにより、同一の物理的なマシン上で作動している多数のＪＶＭのフットプリントを減少する。実施形態によれば、ＯＳレイヤの上位にあるＪＶＭプロキシ８２，８２は、実行レイヤにおける機能およびサービスを、ＯＳを介して呼び出すことを可能とするために提供される。他の実施形態によれば、ベアメタル実行レイヤを、ＪＶＭプロキシの必要性のないままに使用することが可能である。
【００２７】
（性能モニタリングの枠組み−ＣＰＵパワーおよびＣＰＵの共有）
上述したように、システムにおける有用な機能の１つは、アプリケーションの要求に応
えるために、有効なリソースを配分する能力にある。ある実施形態によれば、ＣＰＵパワーは、アプリケーションが消費する、またはアプリケーションが有することを保証されているＣＰＵ時間の量に略等しい。そして、この情報は、有効なマシンまたは他の物理的なハードウェアに対して、ＪＶＭリソースを配分するために使用される。実施形態によれば、全ての測定ユニットは、概算であるとみなされている。そして、この測定は、相対的な測定として使用されている（すなわち、２００のＣＰＵパワーのユニットは、１００のＣＰＵパワーのユニットのほぼ２倍の計算能力ということになる）これもまた常に真実となるはずのことであるが、１つの物理的なマシンが生成することができるとされるユニットの数は、正確に、全ての仮想マシンにおける現在の利用量の総和に、使用されていないユニットを加えたものとなるはずである。この相対的測定は、複数の異なるマシンにわたることを想定した場合に比して、１つの特定のマシンにおいての方が、より良好に機能する可能性があり、より理に適っている。具体的には、より大きく異なる２つのマシンに関しては、この相対的測定は、正確さの足りないものとなる可能性がある。目標は、一般的に、異なるマシン間でのＣＰＵのパワーをできる限り同程度とすることである。
【００２８】
（システムのインターフェイスおよび機能）
表１は、一実施形態に従うシステムによって与えられる、複数のインターフェイスおよび機能のリストである。この機能は、高レベルのアプリケーションがＪＶＭを生成し、クラスタ内のものを含む複数のマシンに、リソースを配分することを可能とする。他の実施形態において、追加的なインターフェイスおよび機能を提供することが可能であるということは、明らかであろう。
【００２９】
【表１】
2010500667.tif 000003
【００３０】
ある実施形態によれば、システムは、４つのタイプのリソースのうちの任意のもの、またはこれらの全てをリクエストし、測定することが可能であり、それは、適切なＪＶＭに
リソースを配分するために使用することの可能なものである。これらは、（上記したような）ＣＰＵパワーの測定、Ｊａｖａ（登録商標）ヒープメモリ、ネットワークバンド幅、および、ディスクＩ／Ｏを含むことが可能である。追加的な実施形態は、リソース測定オプションにおける追加的なタイプを提供することが可能である。
【００３１】
ＣＰＵパワーを要求した場合、上位のレイヤは、最小値（すなわち、有効であることが保証されなければならないもの）、およびウエイトを設定することが可能である。他の３つのリソースのタイプに関しては、最小値のみを特定することが可能である。潛在的には、過剰能力（ｏｖｅｒｃａｐａｃｉｔｙ）は、ウエイトにしたがって、速い順に与えられる。この設計選択は、最適化スペースを根本的に単純化し、サーバの配置をより単純にする。このアプローチの根本的な理由は、大部分のアプリケーションが、処理またはメモリ制限（すなわち、読み込みを待機するためのメモリ制限であり、より多くのメモリが必要なわけではない）になる傾向にあるからである。
【００３２】
ある実施形態によれば、メモリヒープは、アプリケーションの必要性に対する要求に応じて、拡大されて設計される。したがって、最大のヒープサイズは、一般的に特定されることはない。「アウトオブメモリ（ＯｕｔＯｆＭｅｍｏｒｙ）」エラーは、アドレス空間（全く固定できない空間）または物理的なメモリからシステムがはみ出たときに限って、投げられる（これは、より多くのメモリを有するボックスに移動することによって、同一のマシン上のＶＭを他のマシンに移動することによって、または、他のＶＭＳによって使用されているメモリを減少することによって、解決される可能性がある）。
【００３３】
（ハイパーバイザを使用することの利点）
ハイパーバイザを使用することの利点は、一般的には、オペレーティングシステム（ＯＳ）の処理が良好でない場合でも、孤立しているハイパーバイザは良好である、ということを含んでいる。特に、最小量のＣＰＵにおける要求については、処理レベルでは保証することが困難である。システムの完全な状態に対する「一時保留」サービスや「再開」サービスのような機能も、ＯＳレイヤの上位にあるいずれのレイヤでも困難である。この問題は、これが、システムの状態における完全な情報を有している唯一のレイヤである、ということにある（例えば、ＪＶＭは、オープンファイル、マップされたメモリ、ネイティブコードにおけるスレッドなどを把握することが可能である。しかしながら、ＪＶＭは、「再開」において状態を完全に回復することはできない）。ライブ・マイグレーション機能は、より単純である。ハイパーバイザがハードウェアを取り除くために、システムは、作動しているシステムを他のボックスに移動（マイグレーション）する能力を有する。これについては、ＪＶＭレイヤ間の、ＯＳレイヤにわたる、ハイパーバイザ・レイヤに対する連携によって、より効率的に実行することが可能となる。ハイパーバイザを用いることにより、例えば、特定のＣＰＵ時間量をシステムに対して有効とすることが可能となること、および、各コンテナの使用しているＣＰＵ時間量をシステムが測定することが可能となること、を確保することも可能となる。
【００３４】
（特別のＯＳレイヤを使用することの利点）
いくつかの実施形態では、特別のオペレーティングシステム（ＯＳ）レイヤが使用されている。メモリの共有を、多くのレベル（アプリケーション、アプリケーションサーバ、ＪＶＭ、ＯＳ）において実行することが可能となる。しかしながら、スタックにおける特定のレイヤにおいて、より効率的に実行されるタイプの共有もある。具体的には、ＪＶＭとハイパーバイザとの組み合わせからのサポートを組み合わせることにより、システムは、異なるＪＶＭ間で、逆フォークのような（ｉｎｖｅｒｓｅ−ｆｏｒｋ−ｌｉｋｅ）方法で、メモリを共有することが可能となる。これは、「事後に」異なるＪＶＭ間で特定のページが全く同一であることを、システムがハイパーバイザに対して伝えることが可能である、ということを意味する。この場合、ハイパーバイザは、これらのページがコピー・オ
ン・ライト方法によって、同一の物理的なページにマップされる、ことを認めることが可能となる。
【００３５】
さらに、特定のＯＳレイヤは、従前では不可能であったいくつかの機能を可能とする。例えば、ＯＳは、１つのプロセス、すなわちアプリケーションを作動するＪＶＭプロセスを取り扱うだけである。さらに、ＯＳがＪＶＭを理解し、ＪＶＭとＯＳとの間の高度な連携／コミュニケーションが実現され、これにより、強力な最適化が可能となる。ＯＳレベルのサポートがないと不可能な機能もある。例えば、以下のような機能である。
【００３６】
・ミューテータ・スレッドに関するいくつかのページを、これらの領域においてガーベジコレクタが圧縮されている間に無効とすることによる、ポーズレス・コンパクション（ｐａｕｓｅｌｅｓｓ  ｃｏｍｐａｃｔｉｏｎ）
・スマートスレッド・スケジューリング（例えば、ロック上でのスピニングの代わりに、そのロックを保持しているスレッドのスケジュールを決める）
特別のＯＳレイヤは、また、ＯＳレイヤを除去することによって、何らかの効率性を実現することもある。ＯＳレイヤを除去することは、ポーズ時間の短縮、高コンテンション中のより良好な動作、および低メモリにつながる。
【００３７】
ハイパーバイザを追加することは、抽象化の外部レベルを加えることであり、これはまた、極めて自然にシステムをスローダウンする。オペレーティングシステムを除去することにより、システムはこのスローダウンを補償することが可能となり、さらに、おそらくは、それを改善することさえ可能となる。ハイパーバイザを使用して、ゲストＯＳの１つとして導入された通常のオペレーティングシステムを有することによって、ベアメタルは、異なるデバイスのための、および、ハイパーバイザを介してオペレーティングシステムを有するゲストＯＳ上のデバイスドライバと通信する唯一の単純なデバイスのための、書き込みデバイスドライバを回避することが可能である。
【００３８】
（システム設計）
実施形態によれば、システムは、その主なインターフェイスとしてＪａｖａ（登録商標）インターフェイスを含む、リソース管理サービス（Ｒｅｓｏｕｒｃｅ  Ｍａｎａｇｅｍｅｎｔ  Ｓｅｒｖｉｃｅ）を含んでいる。このインターフェイスのユーザは、アプリケーションサーバ、アプリケーション、および企業規模のアプリケーション（例えば、クラスタリング・アプリケーション）を含むことが可能である。一実施形態にかかる実際のＪａｖａ（登録商標）ＡＰＩは、以下に付録Ａとして例示されている。
【００３９】
図７は、本発明の実施形態に従う仮想マシン環境のコンポーネントにおける、論理図１００を示している。仮想化レイヤは、できるだけ小さいことが理想的であるはずである。図７に示されているように、実施形態によれば、これは、ハイパーバイザ（例えば、ＸｅｎまたはＶＭＷａｒｅ、または他のハイパーバイザ）の簡素なレイヤ、オペレーティング環境（例えば、ベアメタル実行レイヤ）の簡素なレイヤ、および、実行エンジンのワイドなブロブ（例えば、ＪＲｏｃｋｉｔ、もしくは他のＪＶＭ）、非常にワイドなアプリケーション（例えば、ＷｅｂＬｏｇｉｃサーバ、もしくは他のアプリケーションサーバ、さらに、カスタマーアプリケーション）における全ての作動、に帰着する。
【００４０】
いくつかの実施形態では、ＯＳレイヤは、補助的な仮想化ハイパーバイザを仮定して構築される（すなわち、ＯＳとハイパーバイザとの間に連携があり、ＯＳがハイパーバイザを認識している）、と想定される。しかしながら、他の実施形態は、共同して機能するＯＳおよびハイパーバイザを使用することが可能である。
【００４１】
図８は、本発明の実施形態に従う仮想化を用いる方法における、フローチャートを示し
ている。図８に示されているように、ステップ１２０では、システムは、アプリケーション（例えば、アプリケーションサーバ、もしくはアプリケーションサーバ上で実行しているカスタマーアプリケーション）から、リソースにアクセスするためのリクエストを受け取る。これは、ＪＶＭによって与えられるべきものである。ステップ１２２では、リソースブローカが、このリクエストを取り扱うために最も適しているマシンのあるリソースブローカ・エージェントがどれなのか、を判断する。これは、例えば、利用可能性または電流負荷に基づいて判断される。ステップ１２４では、リソースブローカ・エージェントが、マシン上でのＪＶＭの動作を生成または管理するために、仮想化レイヤを使用する。この仮想化レイヤは、実行レイヤおよびハイパーバイザを含んでいる。
【００４２】
（付録Ａ）
以下のコードは、本発明の実施形態とともに使用される実際のＪａｖａ（登録商標）ＡＰＩを規定するものである。明らかなことではあるが、本発明の精神および範囲内において、他の実施形態では他のＡＰＩを規定することができる。
Ｒｅｓｏｕｒｃｅ  Ｂｒｏｋｅｒ  ＡＰＩ
ｐａｃｋａｇｅ  ｃｏｍ．ｂｅａ．ｊｖｍｂｒｏｋｅｒ；
ｐｕｂｌｉｃ  ｉｎｔｅｒｆａｃｅ  ＪＶＭＢｒｏｋｅｒ
｛
／＊＊
＊新しいＪＶＭインスタンスを生成する。このＪＶＭインスタンスは、特定のマシン
＊に拘束されており、ＵＵＩＤを有しており、さらに、今後に投入することの可能な
＊ものである。しかし、ＪＶＭは、いかなるリソースもまだ使用していない。
【００４３】
＊／
ｐｕｂｌｉｃ  ＪＶＭ  ｃｒｅａｔｅＪＶＭ（ＪＶＭＲｅｑｕｅｓｔ  ｒｃ）；
／＊＊
＊新しいＪＶＭインスタンスを生成する。
【００４４】
＊＠ｎｏｔｅ  これは、便宜上の方法であり、より詳しい情報に関しては、ｃｒｅａ
＊ｔｅＪＶＭを参照されたい。
【００４５】
＊／
ｐｕｂｌｉｃ  ＪＶＭ  ｃｒｅａｔｅＪＶＭ（）；
／＊＊
＊イメージから新しいＪＶＭインスタンスを生成する。このイメージは、あらかじめ
＊停止しているＪＶＭである。スタート時には、ＪＶＭは、停止状態でスタートされ
＊、再開（）のためのコールは、実行を再開するために要求されることになる。
【００４６】
＊
＊＠ｎｏｔｅ  これは、便宜上の方法であり、より詳しい情報に関しては、ｃｒｅａ
＊ｔｅＪＶＭを参照されたい。
【００４７】
＊／
ｐｕｂｌｉｃ  ＪＶＭ  ｃｒｅａｔｅＪＶＭＦｒｏｍＩｍａｇｅ（ＪＶＭＲｅｑｕｅｓｔ  ｒｃ，  Ｆｉｌｅ  ｉｍａｇｅ）；
｝
／＊＊
＊このインターフェイスは、ＪＶＭリソースブローカのパースペクティブからのＪＶＭ
＊ハンドルを示す。
【００４８】
＊
＊これは、ＪＶＭを構成するために使用されるインターフェイスである。これらの１つ
＊をあなたが有したときに、ＪＶＭは、マシンに拘束される。しかし、それは、まだス
＊タートされることはない。
【００４９】
＊／
ｐｕｂｌｉｃ  ｉｎｔｅｒｆａｃｅ  ＪＶＭ
｛
／＊＊
＊ＪＶＭのＩＰアドレスを取得する。これは、一般的には、１つのＩＰアドレスであ
＊る。
【００５０】
＊
＊／
ｐｕｂｌｉｃ  ＩｎｅｔＡｄｄｒｅｓｓ［］  ｇｅｔＡｄｄｒｅｓｓｅｓ（）；
／＊＊
＊スタートアップ・コマンドをＪＶＭに設定する。
【００５１】
＊
＊＠ｐａｒａｍ  ｎａｍｅ−スタートのための主なクラスの名称
＊＠ｐａｒａｍ  ａｒｇｓ−主なクラスの主な方法に引き継がれるアーギュメント
＊／
ｐｕｂｌｉｃ  ｖｏｉｄ  ｓｅｔＳｔａｒｔＣｏｍｍａｎｄ（Ｓｔｒｉｎｇ  ｎａｍｅ，  Ｓｔｒｉｎｇ［］  ａｒｇｓ）  ｔｈｒｏｗｓ  ＩｌｌｅｇａｌＳｔａｔｅＥｘｃｅｐｔｉｏｎ；
／＊＊
＊パスと呼ばれる所定のマウントポイントをマウントする。パスは、問題になってい
＊るマシン上の、有効な所定のマウントポイントでなければならない。パスは、ＵＮ
＊ＩＸのようなパスである。
【００５２】
＊
＊すなわち、マウント（“／ｗｌｓ”）あるいはマウント（“／ｗｌｓ９０”）；
＊／
ｐｕｂｌｉｃ  ｖｏｉｄ  ｍｏｕｎｔ（Ｓｔｒｉｎｇ  ｐａｔｈ）；
／＊＊
＊ＪＶＭをスタートする。この方法については、一度だけコールすることが可能であ
＊る。
【００５３】
＊／
ｐｕｂｌｉｃ  ｖｏｉｄ  ｓｔａｒｔ（）  ｔｈｒｏｗｓ  ＩｌｌｅｇａｌＳｔａｔｅ
Ｅｘｃｅｐｔｉｏｎ；
／＊＊
＊作動しているＪＶＭを停止する。
【００５４】
＊／
ｐｕｂｌｉｃ  ｖｏｉｄ  ｓｕｓｐｅｎｄ（）；
／＊＊
＊停止しているＪＶＭの実行を再開する。
【００５５】
＊／
ｐｕｂｌｉｃ  ｖｏｉｄ  ｒｅｓｕｍｅ（）；
／＊＊
＊このＪＶＭのための合意されたリソース使用量を、増加あるいは減少するためにコ
＊ールされる。
【００５６】
＊／
ｐｕｂｌｉｃ  ｂｏｏｌｅａｎ  ｃｈａｎｇｅＲｅｑｕｉｒｅｍｅｎｔｓ（ＪＶＭＲｅｑｕｉｒｅｍｅｎｔｓ  ｒｃ）；
／＊＊
＊現在のリソース使用量の概算を取得する。
【００５７】
＊この情報については、より高レベルでのクラスタリング決定を形成するために使用
＊することが可能である。
【００５８】
＊
＊例えば、あなたが、あなたのリクエストしたものと等しいか、それより高いパワー
＊ユニットを使用している場合、このアプリケーションは、おそらく、パワーユニッ
＊ト制限されている（ＣＰＵ／メモリ制限と同様）。このため、可能であれば、より
＊多くのＰＵを局所的にリクエストすることは理に適っている。
【００５９】
＊
＊あるいは、アプリケーションが、そのパワーユニットの全てを使用していない場合
＊、ボトルネックは、おそらく、他の場所にある。そして、より多くのパワーをリク
＊エストすること、あるいは、より多くのインスタンスをスタートすることは、役に
＊立たない。
【００６０】
＊／
ｐｕｂｌｉｃ  ＪＶＭＲｅｓｏｕｒｃｅｓ  ｇｅｔＲｅｓｏｕｒｃｅＵｓａｇｅ（）；
／＊＊
＊このＪＶＭが配置されている、物理的なマシンの取得。物理的とは、ここでは、リ
＊ソースブローカが思うものが物理的なマシンである、ということを意味する。他の
＊いくつかのレイヤは、当然、我々をだまして、仮想マシンが物理的なマシンである
＊と信じ込ませることが可能である。
【００６１】
＊／
ｐｕｂｌｉｃ  Ｍａｃｈｉｎｅ  ｇｅｔＭａｃｈｉｎｅ（）；
／＊＊
＊特定のファイルに、停止されているイメージを保存する（このファイルは、ｓｔｏ
＊ｒｅＩｍａｇｅのコーラからの、ローカルパスとして特定される）。ＪＶＭがコー
＊ラとは異なるマシンにある場合、そのサーバからコーラ（あるいは、コーラが参照
＊するファイルサーバであればなんでも）にデータを移動する必要があるため、この
＊動作の完了までに何秒もかかることがある。
【００６２】
＊
＊この方法については、ＪＶＭが停止されているときだけコールすることが可能であ
＊る。
【００６３】
＊／
ｐｕｂｌｉｃ  ｖｏｉｄ  ｓｔｏｒｅＩｍａｇｅ（Ｆｉｌｅ  ｆ）  ｔｈｒｏｗｓ  ＩｌｌｅｇａｌＳｔａｔｅＥｘｃｅｐｌｉｏｎ；
／＊＊
＊ＪＶＭイベントに興味をもつリスナーを登録する。
【００６４】
＊／
ｐｕｂｌｉｃ  ｖｏｉｄ  ｒｅｇｉｓｔｅｒＬｉｓｔｅｎｅｒ（ＪＶＭＬｉｓｔｅｎｅｒ  ｊ１）；
｝
／＊＊
＊これは、ＪＶＭ上のｌａｎ幅（ｌａｎ−ｗｉｄｅ）の要求を、それがスタートされる
＊前に特定するためのインターフェイスである。この要求は、それがどれくらいの量の
＊リソースを使用することの可能であるのか、という観点と、他のＪＶＭに関連してそ
＊れをどこに配することが可能であるのか、といった、より規模の大きい要求との双方
＊に関する。
【００６５】
＊
＊ＪＶＭのローカルな要求についても、ＪＶＭＲｅｑｕｉｒｅｍｅｎｔｓを参照された
＊い。
【００６６】
＊
＊＠ｓｅｅ  ｃｏｍ．ｂｅａ．ｊｖｍｂｒｏｋｅｒ．ＪＶＭＲｅｑｕｉｒｅｍｅｎｔｓ
＊＠ａｕｔｈｏｒ  Ｊｏａｋｉｍ  Ｄａｈｌｓｔｅｄｔ  （ｊｏａｋｉｍ．ｄａｈｌｓ
＊ｔｅｄｔ＠ｂｅａ．ｃｏｍ）
＊／
ｐｕｂｌｉｃ  ｉｎｔｅｒｆａｃｅ  ＪＶＭＲｅｑｕｅｓｔ  ｛
／＊＊
＊ＪＶＭリソースの要求を取得する。
【００６７】
＊／
ｐｕｂｌｉｃ  ａｂｓｔｒａｃｔ  ＪＶＭＲｅｑｕｉｒｅｍｅｎｔｓ  ｇｅｔＪＶＭＲｅｑｕｉｒｅｍｅｎｔｓ（）；
／＊＊
＊このＪＶＭに関するＪＶＭリソースの要求をセットする。
【００６８】
＊／
ｐｕｂｌｉｃ  ａｂｓｔｒａｃｔ  ｖｏｉｄ  ｓｅｔＪＶＭＲｅｑｕｉｒｅｍｅｎｔｓ（ＪＶＭＲｅｑｕｉｒｅｍｅｎｔｓ  ｒ）；
／＊＊
＊このＪＶＭが所属しているはずの、ＪＶＭのグループを取得する。グループは、通
＊常、リソースブローカに対して、このＪＶＭのセットが同一のアプリケーションの
＊ために機能している、ということを知らせるために使用されている。
【００６９】
＊／
ｐｕｂｌｉｃ  ａｂｓｔｒａｃｔ  ＪＶＭＧｒｏｕｐ  ｇｅｔＪＶＭＧｒｏｕｐ（）；
／＊＊
＊このＪＶＭが所属しているはずの、ＪＶＭのグループをセットする。グループは、
＊通常、リソースブローカに対して、このＪＶＭのセットが同一のアプリケーション
＊のために機能している、ということを知らせるために使用されている。
【００７０】
＊／
ｐｕｂｌｉｃ  ａｂｓｔｒａｃｔ  ｖｏｉｄ  ｇｅｔＪＶＭＧｒｏｕｐ（ＪＶＭＧｒｏｕｐ  ｊｇ）；
／＊＊
＊このＪＶＭがその上で作動していなければならない、特定のマシンを取得する。
【００７１】
＊／
ｐｕｂｌｉｃ  ａｂｓｔｒａｃｔ  Ｍａｃｈｉｎｅ  ｇｅｔＭａｃｈｉｎｅ（）；
／＊＊
＊このＪＶＭに対し、特定のマシン上で作動することを要求する。
【００７２】
＊
＊これは、望ましい振る舞いではない。それは、マシンを最大限に利用するようにリ
＊ソースの予定を決めるリソースブローカの能力を、強く制限することになる。
【００７３】
＊
＊ｓｅｔＭａｃｈｉｎｅを使用することの可能な場合：特別のマシンが、特定のサー
＊ビスにアクセスすることの可能な唯一のものであるとき（すなわち、それは、ＣＩ
＊ＣＳシステムあるいはＲＥＵＴＥＲＳ端子に対する接続を有する、唯一のものであ
＊る）。
【００７４】
＊
＊＠ｎｏｔｅ  これは、パイロットにおいてサポートされている機能ではない。
【００７５】
＊＠ｎｏｔｅ  このアイデアは、ｖ１．０において、これをサポートする予定である
＊。
【００７６】
＊／
ｐｕｂｌｉｃ  ａｂｓｔｒａｃｔ  ｖｏｉｄ  ｓｅｔＭａｃｈｉｎｅ（Ｍａｃｈｉｎｅ
ｍ）：
／＊＊
＊自動スタート値を取得する。
【００７７】
＊／
ｐｕｂｌｉｃ  ａｂｓｔｒａｃｔ  ｉｎｔ  ｇｅｔＡｕｔｏＲｅｓｔａｒｔ（）；
／＊＊
＊０ではない終了コードでＪＶＭがシャットダウンした場合に、再スタートするか否
＊かを指定する。
【００７８】
＊
＊この数字は、あきらめる前に再スタートを何度こころみるか、を指定する。
【００７９】
＊
＊０＝自動再スタートはしない（デフォルト）
＊／
ｐｕｂｌｉｃ  ａｂｓｔｒａｃｔ  ｖｏｉｄ  ｓｅｔＡｕｔｏＲｅｓｔａｒｔ（ｉｎｔ
ｎｔｉｍｅｓ）；
｝
／＊＊
＊このクラスは、ＪＶＭ上のローカルリソース制限を示している。この場合のローカル
＊はＪＶＭ自体に対してローカルということであり、あなたが異なるＪＶＭ間の依存関
＊係に対して要求を出すことを望む、あるいは、特定のＪＶＭを特定のマシン上で実行
＊するといったようなことを望む場合には、あなたは、ＪＶＭＲｅｑｕｅｓｔを調べる
＊べきである。
【００８０】
＊
＊＠ｓｅｅ  ｃｏｍ．ｂｅａ．ｊｖｍｂｒｏｋｅｒ．ＪＶＭＲｅｑｕｅｓｔ
＊／
ｐｕｂｌｉｃ  ｃｌａｓｓ  ＪＶＭＲｅｑｕｉｒｅｍｅｎｔｓ  ｛
ｐｒｉｖａｔｅ  ｓｔａｔｉｃ  ｆｉｎａｌ  ｉｎｔ  ＤＥＦＡＵＬＴ＿ＷＥＩＧＨＴ＝１００；
ｐｒｉｖａｔｅ  ｓｔａｔｉｃ  ｆｉｎａｌ  ｌｏｎｇ  ＭｌＮ＿ＭＥＭＯＲＹ＝１６；／／ｊｒｏｃｋｉｔ  ｓｕｐｐｏｒｔｓ  ｎｏ  ｌｅｓｓ
ｐｒｉｖａｔｅ  ｓｔａｔｉｃ  ｆｉｎａｌ  ｌｏｎｇ  ＭＩＮ＿ＰＵ＝１；
ｐｒｉｖａｔｅ  ｓｔａｔｉｃ  ｆｉｎａｌ  ｌｏｎｇ  ＭｌＮ＿ＮＢＷ＝５０；／／５０ｋＢｉｔ〜ｍｏｄｅｍ  ｓｐｅｅｄ
ｐｒｉｖａｔｅ  ｓｔａｔｉｃ  ｆｉｎａｌ  ｌｏｎｇ  ＭｌＮ＿ＤＳ＝５００；／／０．５ＧＢ
／＊＊
＊ＪＶＭＲｅｑｕｉｒｅｍｅｎｔｓに関する好ましいコンストラクタ。あなたの望む
＊パワーがどの程度の量であるのかを特定するだけである。パワーは、単なるＣＰＵ
＊−ＭＨｚではなく、アプリケーションに使用されているその実際のｂｏｇｏ−ｍｉ
＊ｐｓである。これは、ガーベジコレクションおよびコンピレーションのようなＪＶ
＊Ｍ管理が測定に含まれていないことを意味しており、さらに、より高いパワーを得
＊るために、このシステムが、例えば、より多くのＣＰＵの代わりにより多くのメモ
＊リをあなたに与えることが可能であること、を意味している。
【００８１】
＊／
ｐｕｂｌｉｃ  ＪＶＭＲｅｑｕｉｒｅｍｅｎｔｓ（ｌｏｎｇ  ｍｉｎＰＵ）；
／＊＊
＊ＪＶＭＲｅｑｕｉｒｅｍｅｎｔｓに関する単純なコンストラクタ。全ての要求に関
＊するデフォルトの値をセットする。
【００８２】
＊／
ｐｕｂｌｉｃ  ＪＶＭＲｅｑｕｉｒｅｍｅｎｔｓ（）；
ｐｕｂｌｉｃ  ＪＶＭＲｅｑｕｉｒｅｍｅｎｔｓ（ｌｏｎｇ  ｍｉｎＰＵ，  ｌｏｎｇ
ｍｉｎＭｅｍ，  ｌｏｎｇ  ｍｉｎＮＢ）；
ｐｕｂｌｉｃ  ＪＶＭＲｅｑｕｉｒｅｍｅｎｔｓ（ｌｏｎｇ  ｍｉｎＰＵ，  ｌｏｎｇ
ｍｉｎＭｅｍ，  ｌｏｎｇ  ｍｉｎＮＢ，  ｌｏｎｇ  ｍｉｎＤＳ）；
｝
ｐｕｂｌｉｃ  ｃｌａｓｓ  ＪＶＭＲｅｓｏｕｒｃｅｓ  ｉｍｐｌｅｍｅｎｔｓ  Ｓｅｒｉａｌｉｚａｂｌｅ  ｛
／＊＊
＊使用されているＣＰＵパワー数を戻す（これは、このＪＶＭが実行していた「ジャ
＊バ動作」の回数に関する、最後の３秒間における計算された平均値である）。その
＊考え方は、２倍速いマシンは２倍多くのＣＰＵパワーを実行する能力を有するはず
＊である、ということにある。これがそのケースとなるか否かは、不明確である。
【００８３】
＊／
ｐｕｂｌｉｃ  ｌｏｎｇ  ｇｅｔＣＰＵ  Ｐｏｗｅｒ（）  ｛
ｒｅｔｕｒｎ  ＣＰＵ  Ｐｏｗｅｒ；
｝
／＊＊
＊これは、ＪＶＭの使用している全てのメモリ（ネイティブメモリおよびヒープメモ
＊リを含む）である。
【００８４】
＊／
ｐｕｂｌｉｃ  ｌｏｎｇ  ｇｅｔＭｅｍｏｒｙ（）  ｛
ｒｅｔｕｒｎ  ｍｅｍｏｒｙ；
｝
／＊＊
＊現時点でこのＪＶＭに使用されている、ローカルのディスクスペースの量を取得す
＊る。
【００８５】
＊／
ｐｕｂｌｉｃ  ｌｏｎｇ  ｇｅｔＤｉｓｋＵｓａｇｅ（）  ｛
ｒｅｔｕｒｎ  ｄｉｓｋＵｓａｇｅ；
｝
／＊＊
＊ネットワークバンド幅を取得する（これは、最後の３秒間における計算された平均
＊値である）。
【００８６】
＊／
ｐｕｂｌｉｃ  ｌｏｎｇ  ｇｅｔＮｅｔｗａｒｋＢａｎｄｗｉｄｔｈ（）  ｛
ｒｅｔｕｒｎ  ｎｅｔｗｏｒｋＢａｎｄｗｉｄｔｈ；
｝
｝
ｐｕｂｌｉｃ  ｉｎｔｅｒｆａｃｅ  ＪＶＭＬｉｓｔｅｎｅｒ
｛
ｐｕｂｌｉｃ  ｖｏｉｄ  ａｂｏｕｔＴｏＳｕｓｐｅｎｄ（）；
ｐｕｂｌｉｃ  ｖｏｉｄ  ｒｅｓｕｍｅｄ（）；
／＊＊
＊ＪＶＭが終了した（シャットダウンした）後にコールされる。内部を通過した値は
＊、ＪＶＭに関する終了コード（プロセス…によって戻されるように）である。
【００８７】
＊すなわち、システム終了（値）
ｐｕｂｌｉｃ  ｖｏｉｄ  ｅｘｉｔｅｄ（ｉｎｔ  ｅｘｉｔＣｏｄｅ）；
｝
＊／
ｐｕｂｌｉｃ  ｉｎｔｅｒｆａｃｅ  ＲｅｓｏｕｒｃｅＢｒｏｋｅｒ
｛
／＊＊
＊リソースブローカに関連するマシンのアレイを戻す。
【００８８】
＊／
Ｍａｃｈｉｎｅ［］  ｇｅｔＭａｃｈｉｎｅｓ（）；
／＊＊
＊その「ドメイン」内で現在作動しているとリソースブローカが考えている、Ｊ
＊ＶＭのアレイを戻す。
【００８９】
＊／
ＪＶＭ［］  ｇｅｔＪＶＭｓ（）；
／＊＊
＊プールからマシンを除去するための（おそらく、他のプールに配置するための）要
＊求が、外部ソースから形成される。
【００９０】
＊／
ｐｕｂｌｉｃ  Ｍａｃｈｉｎｅ  ｒｅｌｉｎｑｕｉｓｈＭａｃｈｉｎｅ（）；
ｐｕｂｌｉｃ  ｖｏｉｄ  ａｄｄＭａｃｈｉｎｅ（Ｍａｃｈｉｎｅ  ｍ）；
｝
／＊＊
＊ｊｖｍリソースブローカが実際の物理的なマシンであると信じている何かを、このイ
＊ンターフェイスが示す。マシンに導入されているハイパーバイザがある場合、リソー
＊スブローカの要求に応じて、多数の仮想マシンにマシンを分割することが可能である
＊。
【００９１】
＊／
ｐｕｂｌｉｃ  ｉｎｔｅｒｆａｃｅ  Ｍａｃｈｉｎｅ
｛
／＊＊
＊このＬＡＮ内のマシンのＩＰアドレスを取得する。全てのマシンは、このＬＡＮ内
＊で、正確に１つのＩＰアドレスを有しているはずである（この場合、これらは、当
＊然、それぞれがそれ自身のローカルのＩＰを有することのできるボックス上で、多
＊重ドメインを作動することが可能である）。
【００９２】
＊／
ｐｕｂｌｉｃ  ＩｎｅｔＡｄｄｒｅｓｓ  ｇｅｔＡｄｄｒｅｓｓ（）：
／＊＊
＊どれほどのマシンリソースが現時点で使用されているのかについての、スナップシ
＊ョットを取得する。マシンリソースは、ビッグ４（すなわち、ＣＰＵ／メモリ／デ
＊ィスク／ネットワーク）である。
【００９３】
＊／
ｐｕｂｌｉｃ  ＲｅｓｏｕｒｃｅＵｓａｇｅ  ｇｅｔＲｅｓｏｕｒｃｅＵｓａｇｅ（）；
／＊＊
＊ＭＢ内のマシン上における、メモリの全体量を戻す。
【００９４】
＊／
ｐｕｂｌｉｃ  ｌｏｎｇ  ｇｅｔＴｏｔａｌＭｅｍｏｒｙ（）；
／＊＊
＊ＭＢ内のマシン上における、ディスクスペースの全体量を戻す。
【００９５】
＊／
ｐｕｂｌｉｃ  ｌｏｎｇ  ｇｅｔＴｏｔａｌＤｉｓｋＳｐａｃｅ（）；
／＊＊
＊現在のマシンが、ハイパーバイザのサポートを有しているか否か（および、その後
＊、その結果として、マシンが、ボックスを、リソース保証／一時保留／再開／マイ
＊グレーションの能力を有する多数のボックスに分割できるか否か）をチェックする
＊。
【００９６】
＊／
ｐｕｂｌｉｃ  ｂｏｏｌｅａｎ  ｈａｓＨｙｐｅｒｖｉｓｏｒ（）；
｝
本発明は、好都合なことに、この開示における教示に従ってプログラムされた、標準的な多目的の、あるいは特化されたデジタルコンピュータあるいはマイクロプロセッサを用いて実施することの可能なものである。適切なソフトウエアコーディングについては、ソフトウエア技術の当業者にとって明らかとなるように、この開示の教示に基づいて、熟練
したプログラマーによって容易に準備することが可能である。
【００９７】
いくつかの実施形態では、本発明は、コンピュータプログラム製品を含んでいる。これは、命令を格納した記憶媒体（メディア）であり、本発明のどのプロセスをも実行するために、コンピュータをプログラムする目的で使用することの可能なものである。この記憶媒体は、これらに限られるわけではないが、フロッピー（登録商標）ディスク、光ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、マイクロドライブおよび光磁気ディスクを含む、あらゆるタイプのディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリ・デバイス、磁気あるいは光カード、ナノシステム（分子メモリＩＣを含む）、あるいは、命令および／またはデータを格納することに適したあらゆるタイプのメディアあるいはデバイス、を含むことが可能である。
【００９８】
本発明における前述の説明は、例示および説明の目的のために提供されてきたものである。網羅的であること、あるいは、本発明を開示された形態に厳格に限定することを意図するものではない。熟練の当業者であれば、多くの修正形および変化形を想定するはずである。特に、上記のシステムおよび方法の実施形態は、ＷｅｂＬｏｇｉｃアプリケーションサーバ、およびＪＲｏｃｋｉｔＪＶＭ製品の観点から説明されているけれども、他のタイプのアプリケーションサーバ、ＪＶＭおよび仮想マシン製品を用いたシステムおよび方法を使用してよいことは明らかであろう。同様に、上記の実施形態は、Ｘｅｎハイパーバイザの観点から説明されているけれども、他のタイプのハイパーバイザを使用することも可能である。この実施形態は、本発明の原理および実用的な用途を最もよく説明するために、選択され記載されたものである。したがって、これにより、他の当業者は、さまざまな実施形態に関して、および、想定される特定の使用に適したさまざまな修正形とともに、本発明を理解することが可能となる。本発明の範囲については、以下に示す特許請求の範囲およびその等価物によって規定されることが意図されている。
【図１】
2010500667.tif 000004
【図２】
2010500667.tif 000005
【図３】
2010500667.tif 000006
【図４】
2010500667.tif 000007
【図５】
2010500667.tif 000008
【図６】
2010500667.tif 000009
【図７】
2010500667.tif 000010
【図８】
2010500667.tif 000011
【手続補正書】
【提出日】平成21年4月30日(2009.4.30)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
仮想マシン環境におけるハードウェア仮想化を提供するためのシステムであって、
仮想化レイヤをさらに有するマシンまたはコンピュータを備え、前記仮想化レイヤは、マシン上で仮想マシンを分割するためのハイパーバイザを含み、さらに
１つのＪａｖａ（登録商標）ベースのアプリケーションを実行するように構成されている実行レイヤと、
Ｊａｖａ（登録商標）ベースのアプリケーションの作動において使用するための、実行レイヤ上で作動するＪａｖａ（登録商標）仮想マシンとを備える、システム。
【請求項２】
複数のマシンと、各マシンに配されている仮想化レイヤとをさらに備える、請求項１に記載のシステム。
【請求項３】
前記実行レイヤは、他のいずれのアプリケーションも実行できない状態で、特定の時間において、前記１つのＪａｖａ（登録商標）ベースのアプリケーションだけを実行することに集中するように構成される、請求項１に記載のシステム。
【請求項４】
前記実行レイヤは、できるだけ効率的に、前記１つのＪａｖａ（登録商標）ベースのアプリケーションを実行するように構成される、請求項３に記載のシステム。
【請求項５】
前記システムは、複数の実行レイヤをさらに備えており、前記実行レイヤの各々は、一度に１つのＪａｖａ（登録商標）ベースのアプリケーションだけをできるだけ効率的に実行するように構成されている、請求項１に記載のシステム。
【請求項６】
複数の実行レイヤの各々は、他のいずれのアプリケーションも実行できない状態で、特定の時間において、前記１つのＪａｖａ（登録商標）ベースのアプリケーションだけを実行することに集中するように構成される、請求項５に記載のシステム。
【請求項７】
複数の実行レイヤは、ハイパーバイザ、仮想化レイヤ、およびマシンにおける同一の組み合わせ上に配置される、請求項５に記載のシステム。
【請求項８】
仮想マシン環境におけるハードウェア仮想化を提供するためのシステムであって、
１つ以上のマシン上で動作する複数の仮想マシンをさらに有する、１つ以上のマシンまたはコンピュータと、
各マシンに配されており、そのマシン上で仮想マシンを分割するためのハイパーバイザを含んでいる仮想化レイヤと、
リソースブローカ・サービスとを備え、前記リソースブローカ・サービスは、
仮想マシンによって与えられるリソースにアクセスするためのリクエストを、アプリケーションから受け取り、
複数の仮想マシンのうち、このリクエストを取り扱うために最適なものを決定し、
仮想化レイヤを介して、選択した仮想マシンに前記リクエストを伝達する、システム。
【請求項９】
前記最適な仮想マシンに対するリクエストの伝達に関与する、複数のリソースブローカ・エージェントをさらに備える、請求項８に記載のシステム。
【請求項１０】
前記仮想化レイヤおよびリソースブローカ・サービスは、リクエストを生成したアプリケーションに関する所定の保証に従って、リクエストを配分する、請求項８に記載のシステム。
【請求項１１】
前記ハイパーバイザは、Ｘｅｎハイパーバイザである、請求項８に記載のシステム。
【請求項１２】
前記ハイパーバイザは、ＶＭｗａｒｅハイパーバイザである、請求項８に記載のシステム。
【請求項１３】
仮想マシン環境におけるハードウェア仮想化を提供するための方法であって、
マシン上で仮想マシンを分割するためのハイパーバイザを含んでいる仮想化レイヤをさらに有する、マシンまたはコンピュータを提供するステップと、
１つのＪａｖａ（登録商標）ベースのアプリケーションが実行するように構成されている実行レイヤを提供するステップと、
Ｊａｖａ（登録商標）ベースのアプリケーションの実行において使用するための、実行レイヤ上で作動するＪａｖａ（登録商標）仮想マシンを提供するステップとを備える、方法。
【請求項１４】
仮想マシン環境におけるハードウェア仮想化を提供するための方法であって、
仮想マシンによって与えられるリソースにアクセスするためのリクエストを、アプリケーションから受け取るステップと、
複数の仮想マシン、または、複数の物理的なマシンもしくはコンピュータのうち、当該リクエストを取り扱うために最適なものを決定するステップと、
選択された物理的なマシンまたは仮想マシン上で動作する仮想マシンを生成または管理するために、実行レイヤおよびハイパーバイザを含んでいる仮想化レイヤを用いて前記リクエストを伝達するステップと、
選択された仮想マシンにおいて前記リクエストを処理するステップとを備える、方法。
【請求項１５】
前記最適な仮想マシンに対するリクエストの伝達に関与するエージェントを含む、複数のリソースブローカ・エージェントを提供するステップをさらに備える、請求項１４に記載の方法。
【請求項１６】
前記仮想化レイヤおよびリソースブローカ・サービスは、リクエストを生成したアプリケーションに関する所定の保証に従って、リクエストを配分する、請求項１４に記載の方法。
【請求項１７】
命令を格納したコンピュータ読取可能な記録媒体であって、前記命令がコンピュータによって読取られて実行されると、前記コンピュータに以下のステップを実行させ、前記以下のステップは、
仮想マシンによって与えられるリソースにアクセスするためのリクエストを、アプリケーションから受け取るステップと、
複数の仮想マシン、または、複数の物理的なマシンもしくはコンピュータのうち、このリクエストを取り扱うために最適なものを決定するステップと、
選択された物理的なマシンまたは仮想マシン上で動作する仮想マシンを生成または管理するために、実行レイヤおよびハイパーバイザを含んでいる仮想化レイヤを用いて前記リクエストを伝達するステップと、
選択された仮想マシンにおいて前記リクエストを処理するステップとを含む、コンピュータ読取可能な記録媒体。
【国際調査報告】
2010500667.tif 000012