JP2008511087A - 異種計算環境におけるリソース割り当ての容易化 - Google Patents

Abstract

異種計算環境におけるリソース割り当てが容易化される。異種計算環境のリソース・マネージャは、異種計算環境のどのノードが、それらのネイティブのオペレーティング・システムおよびプラットホームのほかに、付加的なオペレーティング・システムおよびプラットホームをサポートできるかを記述する情報を得る。この情報は次に、特定のジョブを満たすために、リソース・マネージャによりリソース割り当てにおいて用いられる。

Description

本発明は、異種計算環境に関し、詳細には、異種計算環境におけるリソース割り当ての容易化に関する。

異種計算環境は、種々のアーキテクチャおよびオペレーティング・システムを有する複数のノードを含む。例えば、その環境の少なくとも１つのノードが、その環境の少なくとも１つの他のノードと異なるオペレーティング・システムを実行する異なるアーキテクチャに基づいている。異種計算環境の１つの例がグリッド計算環境である。

１つのグリッド計算環境は、大がかりな計算問題を解くために協力するワークステーションまたはサーバのような多くのノードを含む。通常、１つのグリッドは、広い地理的区域上に広がっている。グリッドに寄与する個々のノードは、多くの他の代替的な目的を様々な時に有することがあり、それらは、グリッド・メンバとしてだけでなく、クラスタ内のノードまたは各ワークステーションとして用いられ得る。通常、個々のノードまたはノードのグループを、そのグリッドにとって利用可能にする決定は、そのグリッドがその非グリッド役割においてどれほどビジーであるか、グリッド・ノードについての要求、およびそのノード用に確保されたリソースのタイプを含む、多くの項目に基づく。ストレージ、メモリ、計算パワーおよびファイル・システム・リソースのようなこれらのリソースは、強力で動的な問題解決環境を作り出すために、より大きいグリッドに割り当てられ得る。

現在の技術水準において、グリッド・ノードとそのノード上で実行されるべきジョブの特性との間に強いアフィニティ（親和性）がある。特に、ジョブまたはその一部を走らせるために選ばれたノードは、正しいバージョンのオペレーティング・システムおよび正しいプラットホーム・アーキテクチャ（すなわち、正しい環境）を有する必要がある。これは、特定のプラットホーム上で特定のオペレーティング・システムについてコンパイルおよびリンクされる実行可能ファイルをバインドしたジョブの結果である。例えば、実行可能ファイルは、同じ環境のマシン上でのみ走り得るマシン・レベル命令を含んでいる。この欠点は、実行されるべきジョブと同じ環境を有するノードのみのリソースを割り当てるようにグリッドを限定する。

以前より、この欠点を克服するための試みがなされてきた。しかしながら、異種計算環境においてリソース割り当てを容易にする必要性が依然存在する。

異種計算環境においてリソース割り当てを容易化する方法を講じることにより、先行技術の欠点が克服され、付加的な利点が提供される。

上記で要約された方法に対応するシステムおよびコンピュータ・プログラム製品も、本明細書において説明および特許請求される。

本発明の特徴および利点は、添付図面と共に解釈される以下の詳細な説明から明白である。

異種計算環境におけるリソース割り当てを容易にする能力が提供される。異種環境は、環境のどのノードが特定の要求を処理できるかの決定を担う少なくとも１つのリソース・マネージャを含む。この決定を行うため、これまでは、リソース・マネージャは、要求と同じ環境（すなわち、アーキテクチャおよびオペレーティング・システム）を有するノードが考慮することになろう。さらに、改良として、「仮想マシンの起動を含む計算環境内の管理プロセス（Ｍａｎａｇｉｎｇ Ｐｒｏｃｅｓｓｉｎｇ Ｗｉｔｈｉｎ Ｃｏｍｐｕｔｉｎｇ Ｅｍｖｉｒｏｎｍｅｎｔｓ Ｉｎｃｌｕｄｉｎｇ Ｉｎｉｔｉａｔｉｏｎ Ｏｆ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅｓ）」と表題を付けられた同時継続ＰＣＴ特許出願ＰＣＴ／ＥＰ２００４／０５１４９９号に記載されるように、リソース・マネージャは、要求と同じアーキテクチャの異なる世代のノードも考慮し得るであろう。

特定の要求を処理するために考慮されるべきノードの範囲は、大きく拡張される。例えば、要求と異なるネイティブ環境を有するノードが考慮され得る。これらの異種ノードは、そのネイティブ環境が要求とは異なるが、他の環境をサポートできるので、考慮され得る。

異種計算環境のリソース・マネージャは、環境中の様々なノードから情報を得、ある要求を処理するためにどのノードが使用できるかを決定するためにその情報を用いる。リソース・マネージャにより得られた情報は、それらのノードによりサポートされるがそれらのノードにとりネイティブではない１つ以上の環境（例えば、プラットホームおよびオペレーティング・システム）に関する属性を含む。これらの互換性属性は、特定の要求を処理するために利用可能なノード、従って、リソースの範囲を広げるために、リソース・マネージャにとり利用可能にされる。

異種計算環境の１つの例が図１に示してある。この例において、異種環境は、例えば、インターネット、エクストラネット、またはイントラネットを介してジョブ管理サービス１０４に結合された複数のユーザ・ワークステーション１０２（例えば、ラップトップ、ＴｈｉｎｋＰａｄ（ＩＢＭ社の登録商標）のようなノートブック、パーソナル・コンピュータ、ＲＳ／６０００（ＩＢＭ社の登録商標）等）を含むグリッド計算環境１００である。ジョブ管理サービス１０４は、例えば、ＩＢＭ（Ｒ）により提供されるＷｅｂｓｐｈｅｒｅ（ＩＢＭ社の登録商標）のようなウェブ・アプリケーション・サーバ上で実行、または複数のサーバを横断して分散されるウェブ・アプリケーションを含んでいる。ジョブ管理サービスは、ユーザ要求を受け取り、その要求を環境の適切なノードに渡す責任を負う。１つの例として、１人のユーザは、ウェブ・ブラウザまたはスタンド・アロン・アプリケーションのようなクライアント・アプリケーションを介してジョブ管理サービスと対話する。例えば、Ｐｌａｔｆｏｒｍ（ｗｗｗ．ｐｌａｔｆｏｒｍ．ｃｏｍ）により提供されるＬＳＦ、およびｈｔｔｐ：／／ｗｗｗ．ｓｕｐｅｒｃｌｕｓｔｅｒ．ｏｒｇにおいて利用可能なオープン・ソース・スケジューラであるＭａｕｉ、を含むジョブ管理サービスを含む様々な製品がある。（ＩＢＭ（Ｒ）は、米国ニューヨーク州アーモンクのインターナショナル・ビジネス・マシーンズ・コーポレーションの登録商標である。本明細書中で用いられる他の名称は、インターナショナル・ビジネス・マシーンズ・コーポレーションおよび他社の登録商標、商標または製品名であることがある。）

ジョブ管理サービス１０４はさらに、インターネット、エクストラネットまたはイントラネットを介して１つ以上のデータ・センター１０６に結合されている。各データ・センターは、例えば、メインフレーム、ワークステーションまたはサーバあるいはそれら全部のような１つ以上のノード１０８を含む。環境のノードは、少なくとも１つのノードが異なるアーキテクチャに基づいている、または少なくとも１つの他のノードと異なるオペレーティング・システムを実行する、あるいはその両方であるという点で異種である。例えば、１つのノードはＬｉｎｕｘオペレーティング・システムを走らせるｘ８６アーキテクチャに基づくことができ、別のノードはＡＩＸ（ＩＢＭ社の登録商標）を走らせるＰｏｗｅｒＰＣ（ＩＢＭ社の登録商標）アーキテクチャに基づくことができる。

本明細書中に記載されるように、グリッド計算環境は、大がかりな計算問題を解くために協力する複数のノードを含む。グリッドに寄与する個々のノードは、多くの他の代替的な目的を有し得る。例えば、グリッド内のノードは、個々のワークステーションとして用いられたり、クラスタを形成することができ、その１つの例が図２に示してある。クラスタ２００は、例えば、１組の同種ノード２０２を含んでおり、これらの同種ノードは、クラスタ・リソース・マネージャのようなリソース・マネージャ２０４により管理される。クラスタ・リソース・マネージャは、ユーザからの要求を受信し、個々の要求へのクラスタ・リソースの割り当てを担当する。リソースが割り当てられるやり方は、要求の要件（例えば、ストレージ、ＣＰＵ要件等）に依存する。スループットを最大化するためにリソースを効率的に用いることは、クラスタ・リソース・マネージャの責任である。クラスタ・リソース・マネージャの１つの例は、ニューヨーク州アーモンクのインターナショナル・ビジネス・マシーンズ・コーポレーションにより提供されるＬｏａｄｌｅｖｅｌｅｒ（ＩＢＭ社の登録商標）である。

グリッド計算環境を形成するため、１つ以上のクラスタが一緒に結合され得る。１つのグリッド環境において、図３に示されるように、より大きなグリッドにノードを割り当てるソフトウェアの付加的な層が付加される。グリッド計算環境３００は、複数のクラスタの複数のクラスタ・リソース・マネージャ３０４に結合されるグリッド・リソース・マネージャ３０２のようなジョブ管理サービスを含む。ある要求がグリッド・リソース・マネージャに渡され、そのグリッド・リソース・マネージャは、各々が異なるアーキテクチャおよびオペレーティング・システムを有することがある１つ以上のノードの組を認識する。あるグリッド要求について利用可能なリソースを評価する際にグリッド・リソース・マネージャが利用するのは、このアーキテクチャおよびオペレーティング・システムのプールからである。例えば、ｘ８６クラスタ用にコンパイルされたＬｉｎｕｘ実行可能プログラムであるグリッド要求（例えば、ジョブまたはその一部）が渡される場合、グリッド・マネージャは、候補リソースを選ぶために、これらの条件を正確に満たすノードの組を考慮するだけである。この欠点は図４に例示されており、そこでは、渡された要求のオペレーティング・システムおよびアーキテクチャの制約のせいで、多数のリソースがアイドル状態のままになることがある。

図４を参照すると、グリッド・リソース・マネージャ４００は、クラスタ・リソース・マネージャ４０４に結合された計算ノード４０２を考慮するのみである。なぜならば、グリッド・リソース・マネージャは、それらのノードが、走らされるべき実行可能プログラムと同じ環境を有することを認識しているからである。すなわち、ｘ８６クラスタ用にコンパイルされたＬｉｎｕｘ実行可能プログラムは、それらのノード上で走ることができる。なぜならば、それらはｘ８６アーキテクチャに基づいており、Ｌｉｎｕｘオペレーティング・システムを実行しているからである。ＰｏｗｅｒＰＣ（ＩＢＭ社の登録商標）アーキテクチャ上でＡＩＸ（ＩＢＭ社の登録商標）オペレーティング・システムを走らせる、クラスタ・リソース・マネージャ４０８により管理されるノード４０６は、リソース割り当てのために考慮されない。なぜならば、それらのノードは、渡された実行可能プログラムと同じ環境ではないからである。

しかしながら、本発明の１つの局面に従って、ノード４０６は考慮され得る。すなわち、付加的なノードがさらなるオペレーティング・システムおよびアーキテクチャをサポートできれば、グリッド・リソース・マネージャがそれらの付加的なノードを考慮できるようにする能力が提供される。例えば、あるグリッドの１つ以上のノードが１つの環境に対してネイティブである（すなわち、特定のハードウェア・プラットホームおよびオペレーティング・システムを有する）が、それらのノードが他の環境をサポートでできるということが考えられる。例えば、ＡＩＸ（ＩＢＭ社の登録商標）を実行するＰｏｗｅｒＰＣ（ＩＢＭ社の登録商標）のネイティブな操作環境を有するノードが、Ｌｉｎｕｘを実行するｘ８６環境をサポートできることがある。従って、そのノードは、要求により明示的にまたは黙示的にのいずれか一方で示されるような、どちらか一方の環境を必要とする要求を処理（例えば、プログラムを実行）することができる。

ある要求が、その要求に対してネイティブではないノード上で実行されるために、その要求は、他の環境に移動される。例えば、その要求があるプログラムを走らせることであれば、ネイティブ環境用に書かれているプログラムは、他の環境に移動される。あるプログラムを１つの環境から移動し、それを別の環境において実行可能にするための手法が存在する。１つのそのような手法は、アプリケーション・プログラミング・インタフェース（ＡＰＩ）の使用を含む。プログラムは、１つのＡＰＩにおいて定義された一連の適切に定義されたオペレーティング・システム機能を介して、ファイルの読み取りおよび書き込みのような、オペレーティング・システム・ルーチンにアクセスする。Ｃプログラミング言語のような高レベル・プログラミング言語で書かれた適切に構成されたプログラムは、両方のオペレーティング・システムが同じＡＰＩをサポートするのであれば、１つのオペレーティング・システムから別のオペレーティング・システムに容易に移植できる。例えば、多くのＡＰＩコールを有するＣで書かれたプログラムは、ＡＩＸ（ＩＢＭ社の登録商標）オペレーティング・システム上で走るかもしれないが、ＡＩＸ（ＩＢＭ社の登録商標）がサポートするのと同じＡＰＩの組をＬｉｎｕｘがサポートすれば、Ｌｉｎｕｘ上で走るように容易に移植され得るであろう。あるアプリケーションをｘ８６（Ｉｎｔｅｌ３２ビット）プラットホームから６４ビット・プラットホームＡＰＩに移植する場合に同じことが当てはまり、あるＡＰＩが提供されれば、そのプログラムはかなり容易に移植されるはずである。

ＡＰＩの欠点は、ＡＰＩがプログラミング・インタフェースであり、アプリケーションを１つの環境から別の環境に移植するためにコードの再コンパイルを必要とすることである。ＡＩＸ（ＩＢＭ社の登録商標）において走るＣプログラムの例に再度戻ると、同じプログラムは、Ｌｉｎｕｘの下でそのプログラムをうまく実行させるために、ＬｉｎｕｘＡＰＩを用いての、Ｌｉｎｕｘ環境における再コンパイルを必要とするであろう。１つの環境から別の環境に移植される各プログラムについて再コンパイルを強制するというこの概念は、時間がかかり、時として、ＡＰＩ中の隠された欠陥をむきだしにする。従って、他の手法が求められてきた。

ＡＢＩすなわちアプリケーション・バイナリ・インタフェース（Ａｐｐｌｉｃａｔｉｏｎ Ｂｉｎａｒｙ Ｉｎｔｅｒｆａｃｅ）と呼ばれる１つの手法は、プログラムを異なる環境で走らせるためのより直接的な手法を提供する。ＡＢＩは、１つの環境から実行可能プログラムを取り出し、エミュレーション・ソフトウェア層の使用またはターゲット・マシン上での直接的なハードウェア・サポートにより、別の環境においてその実行可能プログラムを再コンパイルなしで走らせる手法を提供する。ＡＢＩを用いる１つのアーキテクチャは、カリフォルニア州サニーヴェールのＡＭＤにより提供されるＡＭＤ６４アーキテクチャである。ＡＢＩの１つの例が、「２進互換性（Ｂｉｎａｒｙ Ｃｏｍｐａｔｉｂｉｌｉｔｙ）」、ｈｔｔｐ：／／ｇｃｃ．ｇｎｕ．ｏｒｇ／ｏｎｌｉｎｅｄｏｃｓ／ｇｃｃ／Ｃｏｍｐａｔｉｂｉｌｉｔｙ．ｈｔｍｌに記載されている。

ＡＢＩ対応であるノードのような種々のアーキテクチャをサポートできるノードは、グリッド・リソース・マネージャに曝され、その結果、グリッド・リソース・マネージャは、個々のクラスタまたはノードにタスクを割り当てる際にこの情報を用いることができる。これは、ノードのより広いグループがより大きいグリッドに対して利用可能になることを可能にする。

種々の能力をグリッド・リソース・マネージャに曝すことに関連するロジックであって、グリッド・リソース・マネージャが次にそのリソース割り当てにおいてこの情報を用いることができる、ロジックの１つの実施形態が図５に関連して説明される。

ワークステーションのようなノードがオンラインになると（ステップ５００）、そのノードは、クラスタ・リソース・マネージャのようなそのリソース・マネージャに１組の属性を提供する（ステップ５０２）。これらの属性としては、例えば、ノードのプラットホーム（アーキテクチャ）、ノードのオペレーティング・システムおよびオペレーティング・システム・レベル、ならびに、例えば、ＡＢＩを介してそのノードによりサポートされる例えば任意の付加的なオペレーティング・システムまたは任意の付加的なプラットホーム（アーキテクチャ）あるいはその両方を含む１組の互換性属性が含まれる。この情報は、例えば、ウェブ・サービス・コール（Ｗｅｂ Ｓｅｒｖｉｃｅｓ Ｃａｌｌ）またはウェブ・サービス通知（Ｗｅｂ Ｓｅｒｖｉｃｅｓ Ｎｏｔｉｆｉｃａｔｉｏｎ）を介してクラスタ・リソース・マネージャに提供される。例えば、これらの属性を指定するＸＭＬ文書は、ＳＯＡＰコールのようなウェブ・サービス・コールまたは通知を用いてクラスタ・リソース・マネージャに転送される。ＳＯＡＰの１つの例は、“ＳＯＡＰ Ｖｅｒｓｉｏｎ１．２Ｐａｒｔ０：Ｐｒｉｍｅｒ”、Ｎｉｌｏ Ｍｉｔｒａ，ｈｔｔｐ：／／ｗｗｗ，ｗ３．ｏｒｇ／ＴＲ／２００３／ＲＥＣ−ｓｏａｐ１２−ｐａｒｔ０−２００３０６２４／に記載されている。

クラスタ・リソース・マネージャは、この情報を受信し、少なくともノードの互換性属性（例えば、そのノードがサポートする１つ以上の非ネイティブ環境）をグリッド・リソース・マネージャにパーコレートする（ステップ５０４）。１つの例において、この情報は、あるノードからクラスタ・リソース・マネージャに情報を送るために使用されるような同様な機構を用いてグリッド・リソース・マネージャに提供される。例えば、互換性属性は、ＳＯＡＰコールのようなウェブ・サービス・コールを介して、グリッド・リソース・マネージャにより曝されたウェブ・サービスに提供される。情報の提供についての例が本明細書中で示されているが、多くの他の通信媒体が可能である。グリッド・リソース・マネージャは次に、リソースを要求に割り当てる際にこれらの属性を考慮に入れる（ステップ５０６）。

図６は、グリッド・リソース・マネージャがリソース割り当てにおいて互換性属性を使うことができるように互換性属性を得るグリッド・リソース・マネージャの図示である。図６に示されるように、計算ノード６００は各々、ＡＩＸ（ＩＢＭ社の登録商標）およびＰｏｗｅｒＰＣ（ＩＢＭ社の登録商標）のネイティブ環境を有しているが、ｘ８６およびＬｉｎｕｘＡＢＩ互換である。これらのノードは、この情報をそれらのクラスタ・リソース・マネージャ６０２に提供する。このクラスタ・リソース・マネージャは次に、グリッド・リソース・マネージャ６０４までこの情報をパーコレートする。従って、グリッド・リソース・マネージャがＬｉｎｕｘ実行可能プログラムについての要求を受信すると、グリッド・リソース・マネージャは、リソースをどのように割り当てるかを決める際に、ノード６００だけでなくノード６０６も考慮できる。例えば、ノード６００および６０６が必要なリソースを有するかどうかを見るために、それらのノードについての質問をそれらのノード上のマネージャに送ることができる。それらのノードの１つ以上がリソースを有していれば、その要求を処理するためにそれらのノードの少なくとも１つが選ばれる。

異種計算環境におけるリソース割り当てを容易化するための能力が上記で詳細に説明されている。グリッド・リソース・マネージャのようなリソース・マネージャは、異種環境中のどのノードが付加的なオペレーティング・システムおよびプラットホームをサポートできるかを識別する情報を得る。リソース・マネージャは次に、この情報を用いてリソースをどのように割り当てるかを決める。これは、特定の要求について異種計算環境にとり利用可能なリソースの数を有利に拡大する。

ノードは、本明細書において記載されたクラスと異なるクラス（例えば、メインフレーム、ワークステーションまたはサーバ以外）であること、または異なる環境をサポートすること、あるいはその両方が可能である。さらに、異種環境は、別のノードと同じアーキテクチャを有するが世代が異なるノードを含み得る。加えて、ＡＢＩ以外の様々なタイプのインタフェースも、ジョブを異なる環境に移動させるために用いられ得る。さらに、互換性属性をノードからグリッド・リソース・マネージャまたは他のマネージャにパーコレートするために様々な機構が用いられ得る。

さらに別の例として、ユーザは、自動化されたサービスまたはプログラムにより置き換えられ得る。さらに、単一の要求またはジョブは、多数のノード上で同時に走る多数のジョブを含み得る。これは、上述されたものと同様に達成される。例えば、グリッド・リソース・マネージャは、複数のクラスタ・マネージャと接触し、それらのマネージャに複数の要求を管理させる。多くの他の変型例も存在する。さらなる例として、環境は、区分化された１つ以上のノードを含み得る、さらなる例として、本発明の１つ以上の局面は、日立製作所のＰｌｕｇ Ｃｏｍｐａｔｉｂｌｅ Ｍａｃｈｉｎｅｓ（ＰＣＭ）に適用される。他の例も可能である。

本発明により、大がかりなノードの設置基盤を有する組織に対し直ちに経済的利益をもたらす未利用コンピュータ・パワーの活用が可能になる。

本発明は、ソフトウェア、ファームウェア、ハードウェアまたはそれらの何らかの組み合わせにおいて実施できる。

本発明は、例えば、コンピュータ利用可能媒体を有する製造品（例えば、１つ以上のコンピュータ・プログラム製品）に含めることができる。媒体はその中に、例えば、本発明の能力を提供し容易化するためのコンピュータ可読プログラム・コード手段またはロジック（例えば、命令、コード、コマンド等）を有している。製造品は、コンピュータ・システムの一部として含めるか、または別個に販売することができる。

加えて、本発明の能力を実行するためにマシンにより実行可能な命令の少なくとも１つのプログラムを具体化するマシンにより可読な少なくとも１つのプログラム格納デバイスが提供され得る

本明細書中で示される流れ図がまさにその例である。本明細書中に記載されたこれらの図あるいはステップ（または操作）の多くの変型が本発明の精神を逸脱することなく可能であろう。例えば、ステップは異なる順序で実行することができ、あるいはステップは、付加、削除または修正され得る。

本発明の１つ以上の局面を含みかつ用いる異種計算環境の１つの実施形態を図示する。 本発明の１つの局面に従って、図１の異種計算環境において用い得るクラスタの１つの例を図示する。 本発明の１つの局面に従って、グリッド計算環境の複数のクラスタの１つの例を図示する。 グリッドにとり利用可能なリソースが限定されるグリッド計算環境の１つの実施形態を図示する。 本発明の１つの局面に従って、付加的なリソースのグリッドへの提供に関連付けられたロジックの１つの実施形態を図示する。 本発明の１つの局面に従って、付加的なリソースが割り当てのためにグリッドにとり利用可能なグリッド計算環境の１つの実施形態を図示する。

Claims (19)

1. 異種計算環境におけるリソース割り当てを容易にする方法であって、前記異種計算環境のリソース・マネージャにより、前記リソース・マネージャと通信しているノードに関する属性を得るステップであって、前記属性は、前記ノードによりサポートされる少なくとも１つの互換の非ネイティブ環境を指定するものであるステップと、ノードのリソースを要求に割り当てる際に、前記リソース・マネージャにより、前記属性を考慮に入れるステップとを含む方法。
2. 互換の非ネイティブ環境の前記属性は、前記環境のオペレーティング・システムおよびプロセッサを指定する請求項１に記載の方法。
3. 考慮に入れる前記ステップは、前記要求により示された環境とは異なるネイティブ環境を有するが、前記要求により示された前記環境をサポートできる少なくとも１つのノードを考慮するステップを含む請求項１に記載の方法。
4. 前記リソース・マネージャにより前記要求を受信するステップをさらに含み、前記要求は、該要求が処理される環境を示し、割り当てられるリソースを有する前記ノードは、前記環境が前記ノードのネイティブ環境ではないが、前記ノードの属性により示されるように、前記環境をサポートできる請求項１に記載の方法。
5. 前記要求は、実行されるプログラムを含む請求項４に記載の方法。
6. 属性を得る前記ステップは、前記ノードにより前記属性を前記リソース・マネージャに提供するステップを含む請求項１に記載の方法。
7. 前記ノードにより前記属性を前記リソース・マネージャに提供する前記ステップは、前記１つ以上のノードに結合された１つ以上の他のリソース・マネージャを介するものである請求項６に記載の方法。
8. 前記非ネイティブ環境において前記プログラムを走らせるためにアプリケーション・バイナリ・インタフェース（Ａｐｐｌｉｃａｔｉｏｎ Ｂｉｎａｒｙ Ｉｎｔｅｒｆａｃｅ）が用いられる請求項５に記載の方法。
9. 前記異種計算環境はグリッド計算環境を含み、前記リソース・マネージャはグリッド・リソース・マネージャを含む請求項１に記載の方法。
10. 異種計算環境におけるリソース割り当てを容易にするシステムであって、前記異種計算環境のリソース・マネージャにより、前記リソース・マネージャと通信しているノードに関する属性を得るための手段であって、前記属性は、前記ノードによりサポートされる少なくとも１つの互換の非ネイティブ環境を指定するものである手段と、ノードのリソースを要求に割り当てる際に、前記リソース・マネージャにより、前記属性を考慮に入れるための手段とを含むシステム。
11. 互換の非ネイティブ環境の前記属性は、前記環境のオペレーティング・システムおよびプロセッサを指定する請求項１０に記載のシステム。
12. 考慮に入れるための前記手段は、前記要求により示された環境とは異なるネイティブ環境を有するが、前記要求により示された前記環境をサポートできる少なくとも１つのノードを考慮する請求項１０に記載のシステム。
13. 前記リソース・マネージャにより前記要求を受信するための手段をさらに含み、前記要求は、該要求が処理される環境を示し、割り当てられるリソースを有する前記ノードは、前記環境が前記ノードのネイティブ環境ではないが、前記ノードの属性により示されるように、前記環境をサポートできる請求項１０に記載のシステム。
14. 前記要求は、実行されるプログラムを含む請求項１３に記載のシステム。
15. 属性を得るための前記手段は、前記ノードにより前記属性を前記リソース・マネージャに提供するための手段を含む請求項１０に記載の方法。
16. 前記ノードにより前記属性を前記リソース・マネージャに提供するための前記手段は、前記１つ以上のノードに結合された１つ以上の他のリソース・マネージャを介するものである請求項１５に記載のシステム。
17. 前記非ネイティブ環境において前記プログラムを走らせるためにアプリケーション・バイナリ・インタフェース（Ａｐｐｌｉｃａｔｉｏｎ Ｂｉｎａｒｙ Ｉｎｔｅｒｆａｃｅ）が用いられる請求項１４に記載のシステム。
18. 前記異種計算環境はグリッド計算環境を含み、前記リソース・マネージャはグリッド・リソース・マネージャを含む請求項１０に記載のシステム。
19. コンピュータ・システム上で走らされる場合に、先行請求項のいずれかに記載の方法を実行することを前記コンピュータ・システムに命令するための、コンピュータ可読格納媒体上に格納されたコンピュータ・プログラム製品。

Images