JPWO2005116832A1 - 分散処理環境におけるジョブの実行を制御するためのコンピュータシステム、方法及びプログラム - Google Patents

Abstract

【課題】 グリッドシステム群を統合して利用する広域分散システムにおいて、システム構成の変更や規模の拡大縮小に容易に対応可能なスケーラブルなシステム構成を実現する。【解決手段】 広域分散システムを構成する各グリッドシステムのグリッドサーバ１００は、自システムを構成するコンピュータ（ローカルリソース）とネットワーク上の他のグリッドシステム（ネットワークリソース）とを含むリソース手段を対象としてジョブの割り当てを行い、このジョブの実行要求を行うスケジューラ１１０と、このスケジューラ１１０とリソース手段との間の通信を中継するリソースエージェント１２０とを備える。リソースエージェント１２０は、リソース手段の情報を管理すると共に、スケジューラ１１０によるジョブの実行要求をそのジョブの割り当てられたリソース手段に代わって受け付け、かかるリソース手段の状況に応じてジョブの実行要求をリソース手段に対して行う。

Description

本発明は、グリッドコンピューティングに関し、特に複数のグリッドコンピューティングシステムを統括的に制御する方法およびそのシステム構成に関する。

近年、ネットワークで接続されたヘテロジーニアス（異機種混在）な情報システムを統合して利用する、グリッドコンピューティングと呼ばれる技術が注目されている。この技術では、ネットワーク上の複数のコンピュータにおけるＣＰＵパワーやデータストレージなどのコンピュータ資源が共有され、仮想的な１つの高性能コンピュータとして利用される。複数のコンピュータに並列処理を行わせることで、１台１台の性能は低くとも高速に大量の処理を実行することが可能となる。

さて、広域ネットワークに接続された分散処理システム群にあるコンピュータ資源を仮想化し、互いの分散処理システム群に存在するコンピュータ資源をユーティリティとして共有して、有効活用することを考える。ここで、分散処理システムとは、ネットワークに接続された多数の多種多様なコンピュータ資源を１つのグループとして管理し、負荷分散およびスケジューリングを行っているシステムをいう。分散処理システム群とは、広域ネットワーク（分散ネットワーク）上に複数存在している一群の分散処理システムを意味する。以下の説明では、分散処理システムを資源が仮想化されたグリッドコンピューティング環境における個々のグリッドコンピューティングシステム（以下、グリッドシステムと略記する）として記述する。

このような、グリッドシステム群に存在するコンピュータ資源を統合して利用する広域的な分散システムを構築するためには、個々のグリッドシステムにおけるコンピュータ資源の管理の他に、グリッドシステム群全体を管理する仕組みが必要である。そこで従来から、このようなグリッドシステム群のコンピュータ資源の負荷分散やスケジューリングを行うためのメタスケジューラの研究、開発が行われている。メタスケジューラを備えた従来のグリッドシステム群の組織形態は、主として集中型スキーム（Centralized Scheme）、階層型スキーム（Hierarchical Scheme）、分散型スキーム（Distributed Scheme）の
３種類に分けられる（集中型スキームおよび階層型スキームについては例えば非特許文献１を参照、分散型スキームについては例えば非特許文献２を参照）。

図１３は、集中型スキームによるシステム構成を概略的に示した図である。
集中型スキームでは、グリッドシステム群全体を管理するセンターサーバのメタスケジューラに、全てのグリッドシステムの情報が集められ、そのメタスケジューラでスケジューリングの決定がなされる。個々のグリッドシステムであるローカルサイト（ローカルディスパッチャ）では、スケジューリングの決定はなされないが、センターサーバのメタスケジューラから投入されたジョブを実行し、ジョブの完了と資源の状態（空いたプロセッサなど）の情報をメタスケジューラに通知する。新しいグリッドシステムの追加などシステム構成を変更する場合、メタスケジューラによるスケジューリングに反映させるためにセンターサーバでの手続きが必要である。

図１４は、階層型スキームによるシステム構成を概略的に示した図である。
階層型スキームでは、センターサーバと各ローカルサイトとの間で、スケジューリングのプロセスをシェアする。センターサーバのメタスケジューラからローカルサイトのスケジューラにジョブをサブミットした後は、メタスケジューラは、そのジョブに対して直接
に関与する必要はない。もし、ジョブのサブミット後に他のローカルサイトに空きができても、各ジョブの実行は、そのジョブが送られた各ローカルサイトにおいて実行される。

図１５は、分散型スキームによるシステム構成を概略的に示した図である。
分散型スキームでは、全てのサイトにメタスケジューラが設けられる。ジョブは、各ローカルサイトのメタスケジューラにサブミットされて、スケジューリングされる。全てのサイトがメタスケジューラを持つので、あるジョブに関して、所定のローカルサイトで一旦スケジューリングされた後に、他のローカルサイトに空きができたならば、当該ジョブを当該他のローカルサイトで実行するようにスケジューリングし直すことができる。各ローカルサイトのメタスケジューラは同一の情報を持つ必要があり、各ローカルサイトの負荷状況等の情報を随時あるいは定期的に交換する。

Chris Smith, "Open Source Metascheduling for Virtual Organizations with the Community Scheduler Framework (CSF)", Technical Whitepaper, Platform Computing Inc. ２００３年８月． Vijay Subramani, "Distributed Job Scheduling on Computational Grids using Multiple Simultaneous Requests", IEEE International Symposium on High Performance Distributed Computing (HPDC 2002), ２００２年．

上述したように、ネットワーク上の複数のグリッドシステム群に存在するコンピュータ資源を統合して利用する広域的な分散システムを構築するため、グリッドシステム群全体を管理する仕組みが従来から提案されている。
しかし、上述した集中型スキームは、メタスケジューラにおいてネットワーク上の各ローカルサイトにあるコンピュータ資源の詳細な情報を管理する必要があるので、新しいグリッドシステムの追加などシステム構成を変更する場合、メタスケジューラによるスケジューリングに反映させるためにセンターサーバでの手続きが必要となる。したがって、システム構成の変更（ローカルサイトの追加、削除、ローカルサイトにおけるコンピュータ資源の変更等）に伴って、メタスケジューラにおける設定の更新を要し、センターサーバにおける運用・管理の負荷が大きくなる。したがって、システム構成の変更や規模の拡大縮小に容易に対応することができず、スケーラブルなシステムにするのは難しい。

また、階層型スキームは、センターサーバのメタスケジューラからローカルサイトのスケジューラにジョブをサブミットした後は、メタスケジューラは、そのジョブに対して直接に関与しないため、ジョブのサブミット後に他のローカルサイトに空きができても、各ジョブの実行は、そのジョブが送られた各ローカルサイトにおいて実行される。このため、必ずしも効率良くジョブが実行されない。
なお、階層型スキームでは、各ローカルサイト間で情報をやりとりすることにより、他のローカルサイトに空きができた場合に、すでに別のローカルサイトにサブミットされたジョブを空いたローカルサイトに再サブミットする仕組みを導入することもできる。しかし、このような仕組みを導入すると、システムが複雑化してしまうため、開発に手間を要する。
また、各ローカルサイト間で情報をやりとりするために、ネットワーク負荷が増大してしまう。さらに、階層型スキームにおいても、集中型スキームと同様に、システム構成の変更に伴ってメタスケジューラにおける設定の更新を要するため、システム構成の変更や規模の拡大縮小に容易に対応することができず、スケーラブルなシステムにするのは難しい。

また、分散型スキームにおいても、全てのローカルサイトのメタスケジューラ間で、各
ローカルサイトの負荷状況等の情報を随時あるいは定期的に交換する必要があるため、ネットワーク負荷が増大してしまう。そして、システム構成の変更に伴って各ローカルサイトのメタスケジューラにおける設定の更新を要するため、システム構成の変更や規模の拡大縮小に容易に対応することができず、スケーラブルなシステムにするのは難しい。
さらに、階層型スキームや分散型スキームでは、メタスケジューラとローカルなスケジューラとを個別に開発しなければならず、開発コストが増大する。

そこで本発明は、グリッドシステム群に存在するコンピュータ資源を統合して利用する広域分散システムにおいて、システム構成の変更や規模の拡大縮小に容易に対応可能なスケーラブルなシステム構成を実現することを目的とする。
また本発明は、効率よくジョブを実行するためにローカルサイト間で情報をやり取りしながら、ネットワーク負荷を軽減することを他の目的とする。
また本発明は、システムの開発コストを増大させることなく、グリッドシステム群を統合した広域分散システムを実現することをさらに他の目的とする。

上記の目的を達成するため、本発明は、ネットワークを介して接続されたコンピュータシステム群（グリッドシステム群）により分散処理を行うネットワークとして実現される。すなわち、この分散処理環境において各グリッドシステムは、ネットワーク上のコンピュータ資源に対して情報処理におけるジョブの割り当ておよび実行要求を行うグリッドサーバと、自システムにおいて実際にジョブを実行するプロセスサーバ等のコンピュータ資源（ローカルリソース）とを備える。各グリッドサーバは、それぞれのローカルリソースとネットワーク上の他のグリッドシステムとを含むリソース手段を対象としてジョブの割り当てを行い、このジョブの実行要求を行うスケジューラと、このスケジューラとリソース手段との間の通信を中継するエージェント（リソースエージェント）とを備える。このエージェントは、リソース手段の情報を管理するソフトウェアモジュールであって、スケジューラによる前記ジョブの実行要求を当該ジョブの割り当てられた当該リソース手段に代わって受け付け、当該リソース手段の状況に応じて当該ジョブの実行要求を当該リソース手段に対して行う。

より詳細には、エージェントは、ローカルリソースおよびネットワーク上で自システムに隣接する（直接に接続されている）他のグリッドシステム（ネットワークリソース）のそれぞれに対して個別に設けられ、各々が対応するリソース手段との間で設定された個別の通信形式でジョブの実行要求を行う。
ローカルリソースに対応するエージェントは、その能力および動作状況に関する情報をかかるローカルリソースから取得して管理し、他のグリッドシステム（ネットワークリソース）に対応するエージェントは、そのグリッドシステムがジョブの実行要求に対して提供可能なリソース能力の情報をかかる他のグリッドシステムにおけるグリッドサーバから取得して管理する。そして、スケジューラは、リソースエージェントに管理されている各情報に基づいて、リソース手段に対するジョブの割り当てを行う。

さらに、このグリッドサーバは、外部からのジョブの実行要求に応答して自システムが提供可能なリソース能力の情報を前記スケジューラから取得するリソース能力情報取得部と、ネットワーク上の他のグリッドシステムにおけるグリッドサーバのエージェントからの問い合わせに応答してリソース能力情報部にて取得された提供可能なリソース能力の情報をこのエージェントに通知するリソース能力情報通知部とを備えるインタフェース手段を有することができる。この場合、スケジューラは、自システムにおけるエージェントから取得される前記リソース能力の情報に基づき、提供可能なリソース能力を計算する。そして、この提供可能なリソース能力の情報をリソース能力情報取得部に渡す。

さらにまた、このグリッドサーバのインタフェース手段は、ネットワーク上の他のグリッドシステムにおけるグリッドサーバのエージェントから送信されたジョブの実行要求を受け付けるジョブ受け付け部と、このジョブ受け付け部にて受け付けられた実行要求にかかるジョブをスケジューラに渡してジョブの割り当ておよび実行を依頼するジョブ実行依頼部とを備える構成とすることができる。

また、上記の目的を達成する他の本発明は、グリッドシステムにおいてジョブのスケジューリングおよび実行要求を行う、次のようなジョブ実行制御方法としても実現される。この方法は、コンピュータシステム（グリッドシステム）が、自システムに含まれるローカルリソースおよびネットワーク上の他のグリッドシステム（ネットワークリソース）のそれぞれに対応して設けたインタフェースモジュールにより、ローカルリソースの能力および動作状況に関する情報をローカルリソースから取得し、ネットワークリソースが提供可能なリソース能力の情報をそのネットワークリソースにおけるグリッドサーバから取得して管理するステップと、インタフェースモジュールにより管理しているこれらの情報に基づいて、ローカルリソースとネットワークリソースとを含むリソース手段を対象としてジョブの割り当てを行うステップと、ジョブの割り当てられたリソース手段に対するジョブ実行リクエストを発行するステップと、を具備する。さらに、このインタフェースモジュールが、発行されたジョブ実行リクエストを一時的に保持し、ジョブの割り当てられたリソース手段の動作状況に応じて、かかるリソース手段に送信するステップを含む。

さらに本発明は、コンピュータを制御して上述したグリッドサーバの機能を実現させるプログラム、あるいはコンピュータに上記のジョブ実行制御方法の各ステップに対応する処理を実行させるプログラムとしても実現される。このプログラムは、磁気ディスクや光ディスク、半導体メモリ、その他の記録媒体に格納して配布したり、ネットワークを介して配信したりすることにより提供される。

以上のように構成された本発明によれば、広域分散システムを構成する各グリッドシステムのグリッドサーバを、エージェントを介して接続し、このエージェントに、担当するグリッドシステムの情報を持たせることにより、担当エージェントの追加、削除によってグリッドシステム群全体の構成の変更に対応できるため、システム構成の変更や規模の拡大縮小に容易に対応可能なスケーラブルなシステム構成を実現できる。
また本発明によれば、各グリッドシステムがネットワーク上で隣接する他のグリッドシステムの情報を持つことによって、結果的にグリッドシステム群全体の情報が各グリッドシステムに共有されることとなるので、各グリッドシステム間で頻繁に情報交換を行う必要がなく、ネットワーク負荷を軽減することができる。
さらに本発明によれば、グリッドシステム群全体を統括制御するための固有の仕組みを必要としないので、システムの開発に要する手間やコストを大幅に削減することができ、かつ様々なネットワーク構造を持ったシステムを容易に構築できるという柔軟性に富んだシステムを実現できる。

以下、添付図面を参照して、本発明を実施するための最良の形態（以下、実施形態）について詳細に説明する。
図１は、本実施形態による広域分散システムの全体構成を示す図である。
本実施形態の広域分散システムは、インターネット等の広域ネットワークに接続されたグリッドシステム群を統合して、各グリッドシステムにおけるコンピュータ資源を相互に利用可能としている。各グリッドシステムは、グリッドコンピューティング技術により、ネットワークに接続された多数の多種多様なコンピュータ資源を１つのグループとして管理し、その負荷分散およびスケジューリングを行っている分散処理システムである。

本実施形態において各々のグリッドシステムは、従属関係を持たず、対等な関係で並列に動作する。また、各グリッドシステムにとって、ネットワーク上で隣接する他のグリッドシステムは、自システム内のローカルリソース（コンピュータ資源）と同様に扱い、ジョブの実行を依頼することができる。ここで、ネットワーク上で隣接するとは、ネットワークを介してデータ交換を直接行うことが可能なグリッドシステムどうしの関係を意味する。また、ローカルリソースとは、グリッドコンピューティングにおいて割り当てられたジョブを実際に実行するプロセスサーバ等のコンピュータ資源を指す。このような本実施形態によるグリッドシステム群の組織形態を、以下、ネットワークスキーム（Network Scheme）と称す。

図２は、図１の広域分散システムを構成する個々のグリッドシステムの構成を示す図である。
図２に示すように、本実施形態によるグリッドシステムは、ジョブの割り当て（スケジューリング）を行うグリッドサーバ（ＧＳ）１００と、グリッドサーバ１００による割り当てにしたがって実際にジョブを実行するローカルリソースとしてのプロセスサーバ（ＰＳ）２００とを備える。また、グリッドサーバ１００は、他のグリッドシステムのグリッドサーバ１００とも接続されている。

本実施形態において、グリッドサーバ１００とプロセスサーバ２００、および複数のグリッドシステムのグリッドサーバ１００どうしは、インターネットその他のコンピュータネットワークにて接続されている。このコンピュータネットワークは、通信プロトコルや、有線か、無線かといった通信形式を問わず、またファイアウォールやその他のアクセス制限を設けたものであっても良い。
また、詳しくは後述するが、上記のネットワークスキームを実現するために、本実施形態のグリッドサーバ１００は、エージェントと呼ぶインタフェースモジュールを備え、このエージェントを介してプロセスサーバ２００や他のグリッドシステムのグリッドサーバ１００と接続する。かかる装置間接続のフレームワークを、以下、エージェントフレームワーク（Agent Framework）と称す。

図３は、本実施形態におけるグリッドサーバ１００およびプロセスサーバ２００を実現するのに好適なコンピュータ装置のハードウェア構成の例を模式的に示した図である。
図３に示すコンピュータ装置は、演算手段であるＣＰＵ（Central Processing Unit：
中央処理装置）１１と、Ｍ／Ｂ（マザーボード）チップセット１２およびＣＰＵバスを介してＣＰＵ１１に接続されたメインメモリ１３と、同じくＭ／Ｂチップセット１２およびＡＧＰ（Accelerated Graphics Port）を介してＣＰＵ１１に接続されたビデオカード１
４と、ＰＣＩ（Peripheral Component Interconnect）バスを介してＭ／Ｂチップセット
１２に接続された磁気ディスク装置（ＨＤＤ）１５、ネットワークインタフェース１６と、さらにこのＰＣＩバスからブリッジ回路１７およびＩＳＡ（Industry Standard Architecture）バスなどの低速なバスを介してＭ／Ｂチップセット１２に接続されたフレキシブルディスクドライブ１８およびキーボード／マウス１９とを備える。

なお、図３は本実施形態を実現するコンピュータ装置のハードウェア構成を例示するに過ぎず、本実施形態を適用可能であれば、他の種々の構成を取ることができる。例えば、ビデオカード１４を設ける代わりに、ビデオメモリのみを搭載し、ＣＰＵ１１にてイメージデータを処理する構成としても良いし、外部記憶装置として、ＡＴＡ（AT Attachment
）やＳＣＳＩ（Small Computer System Interface）などのインタフェースを介してＣＤ
−Ｒ（Compact Disc Recordable）やＤＶＤ−ＲＡＭ（Digital Versatile Disc Random Access Memory）のドライブを設けても良い。

図４は、本実施形態におけるグリッドサーバ１００の機能構成を示す図である。
グリッドサーバ１００は、自システム内のローカルリソースである各プロセスサーバ２００に対するジョブの割り当て（スケジューリング）を行うスケジューラ１１０と、プロセスサーバ２００の管理を行い、プロセスサーバ２００に対するリクエストおよびレスポンスの送受信を中継するリソースエージェント１２０と、自システムをあたかも他のグリッドシステムのリソースであるかのように動作させるためのグリッドサーバ用リソースエージェント・インタフェース（以下「ＧＳエージェント・インタフェース」）１３０とを備える。リソースエージェント１２０は、各プロセスサーバ２００およびネットワーク上で隣接する他のグリッドシステム（ネットワークリソース）ごとに設けられている。そして、スケジューラ１１０は、このリソースエージェント１２０を介して各プロセスサーバ２００および他のグリッドシステムのグリッドサーバ１００にアクセスする。

スケジューラ１１０は、例えば図３に示したプログラム制御されたＣＰＵ１１とメインメモリ１３や磁気ディスク装置１５等の記憶手段とで実現され、その具体的な機能として図４に示すように、リソース能力問い合わせ応答部１１１と、リソース能力取得部１１２と、ジョブ受け付け部１１３と、最適リソース選択部１１４と、ジョブ依頼部１１５とを備える。
リソース能力問い合わせ応答部１１１は、ＧＳエージェント・インタフェース１３０を介して入力される外部からの問い合わせ（リソース能力取得要求）に応じて、提供可能な自システムのリソース能力を計算し返答する。提供可能なリソース能力は、後述のリソース能力取得部１１２により取得される情報に基づいて計算される。また、リソース能力の提供対象に応じて提供可能なリソース能力を変更することもできる。
リソース能力取得部１１２は、自システムが利用可能なリソース能力を各プロセスサーバ２００およびネットワーク上で隣接する他のグリッドシステムに対応するリソースエージェント１２０に問合せ、情報を取得する（以下、これら自システムのローカルリソースとして認識されるプロセスサーバ２００およびネットワークリソースとして認識される他のグリッドシステムを合わせて、リソース手段と称す）。取得される情報には、自システムにおける本来の処理能力や記憶装置の記憶容量などを静的情報と、実時間の負荷状況に基づく動的情報とが含まれる。
ジョブ受け付け部１１３は、外部のコンピュータシステム（例えばクライアント）やＧＳエージェント・インタフェース１３０からジョブの実行要求を受け付ける。
最適リソース選択部１１４は、リソース能力取得部１１２により取得されたリソース能力の情報に基づき、ジョブに応じてその実行に最適なリソース手段を選択し、ジョブの割り当てを行う。このジョブの割り当てにおける最適化のロジックは任意で良い。
ジョブ依頼部１１５は、最適リソース選択部１１４において選択されたリソース手段に対応するリソースエージェント１２０に対して、ジョブの実行を要求するリクエストを発行する。

本実施形態では、リソースエージェント１２０がスケジューラ１１０と利用可能なリソース手段との間の通信を中継し、スケジューラ１１０によるジョブの実行要求をこれらのリソース手段に代わって受け付ける。そのため、リソース能力取得部１１２の問い合わせ先やジョブ依頼部１１５のリクエストの発行先がリソースエージェント１２０となっているが、それ以外のスケジューラ１１０の機能自体は、既存のスケジューラと変わらない。また、グリッドサーバ１００と個々のプロセスサーバ２００あるいは他のグリッドシステムのグリッドサーバ１００との間における通信形式の違いは、リソースエージェント１２０における設定によって吸収され、スケジューラ１１０自身はリクエストを発行する際に通信形式の差異を考慮する必要がない。したがって、スケジューラ１１０には、既存のグリッドシステムで利用されているスケジューラを用いることができる。

リソースエージェント１２０は、例えば図３に示したプログラム制御されたＣＰＵ１１
とメインメモリ１３や磁気ディスク装置１５等の記憶手段とネットワークインタフェース１６とで実現され、その具体的な機能として図４に示すように、リソース状況管理部１２１と、リソース能力管理部１２２と、ジョブ受け付け部１２３と、ジョブ依頼部１２４とを備える。
リソース状況管理部１２１は、対応するリソース手段にアクセスして、該当するプロセスサーバ２００（ローカルリソース）またはグリッドシステム（ネットワークリソース）における現在の動作状況を把握する。
リソース能力管理部１２２は、対応するリソース手段のジョブ実行能力に関する統計情報等を管理し、スケジューラ１１０のリソース能力取得部１１２からの問い合わせに応じて、管理している情報を返す。ここで、ジョブ実行能力に関する統計情報等とは、単にＣＰＵ自身の処理能力や記憶装置の記憶容量の静的な情報だけでなく、ＣＰＵに対する負荷の時間変動や動作傾向といった動的な内容を統計的に処理して得られた情報を含む。
リソース状況管理部１２１およびリソース能力管理部１２２に管理されるこのようなリソース情報は、リソースエージェント１２０が対応しているリソース手段から取得し、図３のメインメモリ１３や磁気ディスク装置１５等の記憶手段に格納する。
ジョブ受け付け部１２３は、スケジューラ１１０のジョブ依頼部１１５から発行されたジョブ実行リクエストを受け付ける。
ジョブ依頼部１２４は、ジョブ受け付け部１２３により受け付けられたジョブ実行リクエストを対応するリソース手段に送信する。

ＧＳエージェント・インタフェース１３０は、例えば図３に示したプログラム制御されたＣＰＵ１１とメインメモリ１３や磁気ディスク装置１５等の記憶手段とネットワークインタフェース１６とで実現され、その具体的な機能として図４に示すように、リソース能力情報取得部１３１と、リソース能力情報通知部１３２と、ジョブ受け付け部１３３と、ジョブ実行依頼部１３４とを備える。
上述したように、ＧＳエージェント・インタフェース１３０は、グリッドシステムをネットワーク上の他のグリッドシステムに対して当該他のグリッドシステムのローカルリソースと同様に利用可能とするための機能である。このＧＳエージェント・インタフェース１３０により、グリッドサーバ１００は、他のグリッドシステムのグリッドサーバ１００からの要求を受け付け、自システムが利用可能なリソース手段を用いてジョブを実行した結果を返すことができる。

リソース能力情報取得部１３１は、外部からのジョブの実行要求に対して提供可能な自システムのリソース能力の情報（リソース情報）を、スケジューラ１１０に問い合わせて取得する。
リソース能力情報通知部１３２は、受信したリソース能力取得要求に応じて、リソース能力情報取得部１３１において取得されたリソース情報を、リソース能力取得要求の送信元に通知する。リソース能力取得要求がネットワーク上の他のグリッドシステムにおけるグリッドサーバ１００の対応するリソースエージェント１２０から受信された場合は、当該リソースエージェント１２０に通知する。リソースエージェント１２０では、リソース状況管理部１２１およびリソース能力管理部１２２がこの通知を受け付け、メインメモリ１３や磁気ディスク装置１５等の記憶装置に格納して管理する。リソース能力情報通知部１３２からグリッドサーバ１００への通知は、定期的に行っても良いし、自システムの動作状況が変更された際に行うようにしても良い。また、グリッドサーバ１００のリソースエージェント１２０から任意のタイミングで対応する他のグリッドシステムのグリッドサーバ１００へ問い合わせても良い。
ジョブ受け付け部１３３は、他のグリッドシステムにおけるグリッドサーバ１００のリソースエージェント１２０のジョブ依頼部１２４から送信されたジョブ実行リクエストを受け付ける。
ジョブ実行依頼部１３４は、ジョブ受け付け部１３３により受け付けられたジョブのス
ケジューリングおよび実行を、スケジューラ１１０に依頼する。

次に、プロセスサーバ２００の機能構成と、対応するリソースエージェント１２０との関係について説明する。
図５は、プロセスサーバ２００の機能構成とグリッドサーバ１００のリソースエージェント１２０との関係を示す図である。
図５に示すように、プロセスサーバ２００は、図３に示したようなコンピュータ装置をグリッドシステムにおけるプロセスサーバ２００として機能させるためのプロセスサーバ用リソースエージェント・インタフェース（以下「ＰＳエージェント・インタフェース」）２１０を備えている。

ＰＳエージェント・インタフェース２１０は、例えば図３に示したプログラム制御されたＣＰＵ１１とメインメモリ１３や磁気ディスク装置１５等の記憶手段とネットワークインタフェース１６とで実現され、その具体的な機能として図５に示すように、ＰＳ状況監視部２１１と、リソース能力情報通知部２１２と、ジョブ受け付け部２１３と、ジョブ実行部２１４とを備える。
ＰＳ状況監視部２１１は、自装置（プロセスサーバ２００）の現在の使用状況や資源の状況を監視し、情報を収集する。
リソース能力情報通知部２１２は、ＰＳ状況監視部２１１において収集されたＰＳの使用状況や資源の状況に関する情報を、グリッドサーバ１００のリソースエージェント１２０に通知する。リソースエージェント１２０では、リソース状況管理部１２１およびリソース能力管理部１２２がこの通知を受け付け、メインメモリ１３や磁気ディスク装置１５等の記憶装置に格納して管理する。リソース能力情報通知部２１２からグリッドサーバ１００への通知は、定期的に行っても良いし、プロセスサーバ２００の動作状況が変更された際に行うようにしても良い。また、グリッドサーバ１００の対応するリソースエージェント１２０から任意のタイミングでプロセスサーバ２００へ問い合わせても良い。
ジョブ受け付け部２１３は、グリッドサーバ１００のリソースエージェント１２０のジョブ依頼部１２４から送信されたジョブ実行リクエストを受け付ける。
ジョブ実行部２１４は、ジョブ受け付け部２１３により受け付けられたジョブを、プロセスサーバ２００の資源を用いて実行する。

グリッドサーバ１００のＧＳエージェント・インタフェース１３０とプロセスサーバ２００のＰＳエージェント・インタフェース２１０とを比較すると、ＰＳ状況監視部２１１が自装置の状況を監視して情報を収集するのに対し、リソース能力情報取得部１３１がスケジューラ１１０に自システムのリソース能力を問い合わせており、また、ジョブ実行部２１４が自装置の資源を用いてジョブを実行するのに対し、ジョブ実行依頼部１３４がスケジューラ１１０にジョブの実行を依頼している点が異なる。これは、ＰＳエージェント・インタフェース２１０が組み込まれたプロセスサーバ２００がグリッドシステムにおいてジョブを実行するローカルリソースであるのに対し、ＧＳエージェント・インタフェース１３０が組み込まれたグリッドサーバ１００がグリッドシステムを統括制御してジョブ実行のスケジューリングを行うサーバであることに基づく相違である。

すなわち、リソース能力取得要求やジョブの実行要求を送信するグリッドサーバ１００のリソースエージェント１２０と、これに対応するＧＳエージェント・インタフェース１３０およびＰＳエージェント・インタフェース２１０との関係では、ＧＳエージェント・インタフェース１３０とＰＳエージェント・インタフェース２１０とは何ら変わりがない。したがって、リソースエージェント１２０は、対応する相手がローカルリソースであるプロセスサーバ２００かネットワークリソースである他のグリッドサーバ１００かに関わらず、同じ機能構成を有することとなる。

このように、リソースエージェント１２０をインタフェースモジュールとして用い、かつグリッドサーバ１００にＧＳエージェント・インタフェース１３０を備えることにより、ネットワーク上で隣接するグリッドサーバ１００どうしは、互いに自システムのローカルリソースと同様に他のシステムを扱ってジョブの割り当てを行うことができ、かつ他のシステムのローカルリソースとして振る舞うことができる。このようなエージェントフレームワークにより、グリッドシステムどうしは従属関係を持たず、対等な関係で並列に動作しながら、相互に他のグリッドシステムを自システムのリソースとして扱うことが可能なネットワークスキームが実現される。

次に、上記のように構成された本実施形態による広域分散システムの動作について説明する。
本実施形態では、所定のクライアントから所定のグリッドシステムに対して発行されたジョブ実行リクエストに応じて、広域分散システムを構成するグリッドシステム群により負荷分散されてジョブが実行される。ここで、クライアントとは、本実施形態の広域分散システムを構成するいずれかのグリッドシステムにアクセス可能なコンピュータやＰＤＡ（Personal Digital Assistant）等の情報機器である。後述する機能を備えたプロセスサーバ２００がクライアントとしてジョブ実行リクエストを発行することもできる。
図６は、本実施形態の広域分散システムにジョブ実行リクエストを発行するクライアントの機能構成とグリッドサーバ１００のスケジューラ１１０との関係を示す図である。
図６に示すように、クライアント３００は、ジョブ実行リクエストの送信先であるグリッドシステムのリソース能力を問い合わせるためのリソース能力問い合わせ部３１０と、ジョブ実行リクエストを発行してグリッドシステムに送信するジョブ依頼部３２０とを備える。なお、クライアント３００は、所望のジョブに対する実行結果が得られれば良く、ジョブの実行に必要なコンピュータ資源の調達はグリッドシステムに任せて良い場合は、リソース能力問い合わせ部３１０は必須の構成要件ではない。これらの機能は、例えばクライアント３００が図３に示したコンピュータ装置にて構成される場合、プログラム制御されたＣＰＵ１１とメインメモリ１３や磁気ディスク装置１５等の記憶手段とで実現される。

本実施形態によりジョブを実行するに際しては、まず上記のクライアント３００のジョブ依頼部３２０がジョブ実行リクエストを発行し、アクセス対象のグリッドシステムにおけるグリッドサーバ１００に送信する。なお、これに先立つ事前調査として、リソース能力問い合わせ部３１０から同グリッドサーバ１００に対してリソース能力取得要求を送信し、グリッドシステムがジョブを実行するに足るリソース能力を備えているかどうかを判断することができる。

グリッドサーバ１００のスケジューラ１１０では、ジョブ受け付け部１１３がクライアント３００から送信されたジョブ実行リクエストを受け付け、最適リソース選択部１１４が、自システムが利用可能なリソース手段を対象として、当該ジョブの割り当てを行う。ジョブの割り当て対象であるリソース手段は、ローカルリソースであるプロセスサーバ２００と、ネットワークリソースである他のグリッドシステムである。

図７は、スケジューラ１１０によるジョブのスケジューリングの動作を説明するフローチャートである。
図７を参照すると、最適リソース選択部１１４は、リソース能力問い合わせ応答部１１１およびリソース能力取得部１１２を介してリソースエージェント１２０から各リソース手段の能力や動作傾向等の統計情報等を取得し（ステップ７０１）、これらの情報およびジョブの種類や特性に基づいて最適なスケジューリングを行う（ステップ７０２）。そして、ジョブ依頼部１１５が、最適リソース選択部１１４による処理結果に基づいて、ジョブが割り当てられたリソース手段の動作状況に関わらずにジョブ実行リクエストを発行し
、そのリソース手段に対応するリソースエージェント１２０に送信する（ステップ７０３）。

最適リソース選択部１１４によるスケジューリングのロジックは任意で良いが、他のグリッドシステムにジョブの実行を依頼すると依頼先のグリッドシステムでもジョブ実行のスケジューリングが行われることから、一般にローカルリソースにジョブを割り振った方が作業効率が高いと考えられる。そこで、まず自システムのローカルリソースであるプロセスサーバ２００に対してジョブを割り振り、プロセスサーバ２００だけでは能力が不足する場合に他のグリッドシステムにジョブの実行を依頼するといった方法をとることができる。

リソースエージェント１２０は、スケジューラ１１０のジョブ依頼部１１５から受け取ったジョブ実行リクエストを対応するリソース手段に送信し、そのリソース手段からジョブの実行結果を受け取ってスケジューラ１１０に返す。ここで、リソースエージェント１２０の動作は、対応するリソース手段がプロセスサーバ２００であるか他のグリッドシステムであるかによる違いはない。
スケジューラ１１０は、リソースエージェント１２０から受け取った各リソース手段によるジョブの実行結果を統合して、クライアント３００に返す。

さて、本実施形態では、ジョブを実行するリソース手段は、ジョブの実行を依頼されたグリッドシステムのローカルリソースであるプロセスサーバ２００である場合とネットワークリソースである他のグリッドシステムである場合とがある。このうち、プロセスサーバ２００は、ＰＳエージェント・インタフェース２１０のジョブ受け付け部２１３がグリッドサーバ１００のリソースエージェント１２０からジョブ実行リクエストを受け付けると、そのリクエストに応じてジョブ実行部２１４がジョブを実行し、実行結果をグリッドサーバ１００のリソースエージェント１２０に返す。

一方、リソース手段がグリッドシステムである場合、リソースエージェント１２０からのジョブ実行リクエストは、当該グリッドシステムのグリッドサーバ１００におけるＧＳエージェント・インタフェース１３０のジョブ受け付け部１３３により受け付けられ、ジョブ実行依頼部１３４により当該グリッドサーバ１００のスケジューラ１１０に送られる。
図８は、リソースエージェント１２０とＧＳエージェント・インタフェース１３０とスケジューラ１１０との関係を示す図である。
ここで、図８と図６とを比較すると、スケジューラ１１０にとっては、ＧＳエージェント・インタフェース１３０との関係と、クライアント３００のＰＳエージェント・インタフェース２１０との関係は等価である。したがって、スケジューラ１１０は、上述したクライアント３００から直接受け取ったジョブ実行リクエストに対する動作と同様に、ＧＳエージェント・インタフェース１３０を介して他のグリッドシステムのグリッドサーバ１００から受け取ったジョブ実行リクエストに対してもスケジューリングを行い、自システムが利用可能なリソース手段に対してジョブの実行を依頼することができる。

ところで、リソースエージェント１２０は、［００２９］で述べたように、対応するリソース手段から現在の動作状況やジョブ実行能力に関する情報（リソース情報）を取得して、リソース状況管理部１２１およびリソース能力管理部１２２により管理している。このリソース情報は、リソース手段がプロセスサーバ２００である場合は、そのＰＳエージェント・インタフェース２１０のＰＳ状況監視部２１１により収集され、リソース能力情報通知部２１２によりリソースエージェント１２０に送られる。
一方、リソース手段が他のグリッドシステムである場合、リソース情報は、当該グリッドシステムのグリッドサーバ１００におけるＧＳエージェント・インタフェース１３０の
リソース能力情報取得部１３１により取得され、リソース能力情報通知部１３２によりリソースエージェント１２０に送られる。ここで、リソース能力情報取得部１３１は、図４に示したように、スケジューラ１１０のリソース能力問い合わせ応答部１１１に問い合わせを行い、これらの情報を受け取る。したがって、リソース能力問い合わせ応答部１１１は、クライアント３００からリソース能力の問い合わせを受ける場合と、ＧＳエージェント・インタフェース１３０から問い合わせを受ける場合とがある。

１つのグリッドシステムに着目した場合、ネットワーク上でこのグリッドシステムに隣接する他のグリッドシステムは、当該グリッドシステムのリソース手段として利用できる一方で、当該グリッドシステムに対してジョブの実行を依頼することもできる。そして、所定のグリッドシステムから当該グリッドシステムに対してジョブの実行が依頼された場合を考えると、当該グリッドシステムは、ジョブの実行を依頼した所定のグリッドシステムを自システムのリソース手段として利用することはできない。
したがって、ＧＳエージェント・インタフェース１３０から問い合わせを受けた場合、スケジューラ１１０は、ＧＳエージェント・インタフェース１３０に対してリソース能力取得要求を送信したグリッドサーバ１００が含まれるグリッドシステムをリソース手段として利用することはできない。したがってこの場合、スケジューラ１１０は、リソース能力取得要求を送信したグリッドサーバ１００が含まれるグリッドシステムを除いて提供可能なリソース能力を計算して、ＧＳエージェント・インタフェース１３０へ返すこととなる。

図９は、本実施の形態による広域分散システムを構成するグリッドシステム群の全体構成を示す図である。
上述したように本実施の形態では、個々のグリッドシステムにおいて、グリッドサーバ１００とローカルリソースであるプロセスサーバ２００との接続、およびグリッドサーバ１００と他のグリッドシステムとの接続を、グリッドサーバ１００に備えたリソースエージェント１２０を介して行うこととした。これにより、図９に示すようなネットワークスキームが実現され、各グリッドシステム群は、それぞれクライアント３００からジョブの実行依頼を受け付けることができ、そのジョブを自システムのローカルリソースであるプロセスサーバ２００によって実行し、あるいはネットワーク上で隣接する他のグリッドシステムに投入して実行させることができる。各グリッドシステムどうしは従属関係を持たず、対等な関係で並列に動作する。

図１０は、本実施形態のネットワークスキームにより接続されたグリッドシステム群の所定のグリッドシステムにジョブが投入された場合の分散の様子を示す図である。
図１０の例では、破線で示された５つのグリッドシステム（グリッドＡ、Ｂ、Ｃ、Ｄ、Ｅ）からなる広域分散システムのうち、グリッドＡにジョブが投入されている。このジョブは、まずグリッドＡのローカルリソースであるプロセスサーバ（ＰＳ）２００に分散投入される。そして、グリッドＡのローカルリソースの能力ではこのジョブを処理しきれず、オーバーフローが発生する場合は、グリッドＡのグリッドサーバ（ＧＳ）１００において、ネットワーク上で隣接するグリッドＢ、Ｃに対応するリソースエージェント１２０とスケジューラ１１０との間で動作状況の確認等のネゴシエーションが行われ、当該ジョブがグリッドＢ、Ｃに投入される。ジョブがグリッドＢ、Ｃに投入された場合、各グリッドＢ、Ｃのローカルリソースで実行され、グリッドＢでオーバーフローが生じる場合には、さらにグリッドＢに隣接するグリッドＤ、Ｅにも当該ジョブが分散投入される。

なお、アプリケーションの種類によっては、グリッドＢ、Ｃの動作状況等に関わらず、グリッドＡからグリッドＢ、Ｃへジョブを渡してしまうこともできる。この場合、グリッドＡのグリッドサーバ１００において、グリッドＢ、Ｃに対応するリソースエージェント１２０が当該ジョブの実行依頼を受け付け、グリッドＢ、Ｃがジョブを受け付け可能な状
態となった時点で、リソースエージェント１２０からグリッドＢ、Ｃへジョブの実行依頼が行われることとなる。
また、上記の説明では、自システムのローカルリソースではジョブを処理しきれずオーバーフローが生ずる場合に他のグリッドシステムにジョブを投入することとした。このように、できるだけローカルリソースで優先的にジョブを処理する方法は、ネットワークの負荷を軽減するために好ましい。しかしながら、ジョブの分散投入の方法はこれに限るものではない。自システムのローカルリソースおよび隣接する他のグリッドシステムの能力やジョブの種類、特性等に鑑み、最適な（実行効率の高い）分散となるように、任意のロジックでジョブの割り当てを行うことができる。

図１１は、図１０のグリッドシステム群において、他のグリッドシステム（グリッドＢ）に対してジョブが投入された場合の分散の様子を示す図である。
図１１に示すように、グリッドＢに投入されたジョブは、まずグリッドＢのローカルリソースであるプロセスサーバ２００に投入され、オーバーフローが発生する場合に、ネットワーク上で隣接するグリッドＡ、Ｄ、Ｅに分散投入される。また、グリッドＡにおいてオーバーフローが生じるならば、さらにグリッドＣにもジョブが分散投入される。
このように、本実施形態のネットワークスキームにより接続されたグリッドシステム群では、各グリッドシステム間に主従関係がなく、対等な関係で並列に動作するため、いずれのグリッドシステムにジョブが投入されても、ネットワーク上で隣接するグリッドシステムに連鎖的にジョブが分散投入され、グリッドシステム群にて構成される広域分散システム全体でジョブを処理することが可能となる。

ここで、本実施形態による広域分散システムがジョブを実行する場合におけるリソース能力の計算方法の一例について説明する。
図１２は、図１０のグリッドシステム群において所定のグリッドシステムにジョブが投入された場合のリソース能力を説明する図である。
図１２において、各グリッドシステムのリソース能力は、次のように定義される。

Ｃ_x：グリッドシステムｘ自身の（ローカルリソースの）リソース能力
Ｃ_{x for user}：クライアントからのジョブの実行要求に対してグリッドシステムｘが提供可能なリソース能力
Ｃ_{x for y}：ネットワーク上でグリッドシステムｘに隣接するグリッドシステムｙからの
ジョブの実行要求に対してグリッドシステムｘが提供可能なリソース能力

すなわち、Ｃ_{x for user}およびＣ_{x for y}は次の数１式により計算される。

図１２を参照すると、クライアント３００からグリッドシステムａ（図１０のグリッドＡ）にジョブの実行要求が行われた場合、このジョブを実行するために提供される処理能力Ｃ_{a for user}は次のように計算される。

Ｃ_{a for user}＝Ｃ_a＋Ｃ_{b for a}＋Ｃ_{c for a}

ここで、グリッドシステムｂ（図１０のグリッドＢ）は、グリッドシステムａの他にグ
リッドシステムｄ、ｅ（図１０のグリッドＤ、Ｅ）とも隣接しているので、グリッドシステムａに対して提供できるリソース能力は自システムのリソース能力とグリッドシステムｄ、ｅから提供されるリソース能力とを加えたものとなる。すなわち、

Ｃ_{b for a}＝Ｃ_b＋Ｃ_{d for b}＋Ｃ_{e for b}

である。一方、グリッドシステムｃ（図１０のグリッドＣ）は、グリッドシステムａとのみ隣接するので、自システムのリソース能力のみを提供でき、

Ｃ_{c for a}＝Ｃ_c

となる。

同様に図１２から、クライアント３００からグリッドシステムｂにジョブの実行要求が行われた場合、このジョブを実行するために提供される処理能力Ｃ_{b for user}は次のように計算される。

Ｃ_{b for user}＝Ｃ_b＋Ｃ_{a for b}＋Ｃ_{d for b}＋Ｃ_{e for b}

そして、グリッドシステムａ、ｄ、ｅからそれぞれグリッドシステムｂに提供されるリソース能力は、次のようになる。

Ｃ_{a for b}＝Ｃ_a＋Ｃ_{c for a}
Ｃ_{d for b}＝Ｃ_d
Ｃ_{e for b}＝Ｃ_e

また、クライアント３００からグリッドシステムｄにジョブの実行要求が行われた場合、このジョブを実行するために提供される処理能力Ｃ_{d for user}は次のように計算される。

Ｃ_{d for user}＝Ｃ_d＋Ｃ_{b for d}

そして、グリッドシステムｂからグリッドシステムｄに提供されるリソース能力は次のようになる。

Ｃ_{b for d}＝Ｃ_b＋Ｃ_{a for b}＋Ｃ_{e for b}

このうち、リソース能力Ｃ_{a for b}、Ｃ_{e for b}については上述の通りである。
なお、以上の計算方法は例示に過ぎず、この方法に限らないことは言うまでもない。

以上のように本実施形態では、各グリッドシステムは、直接的には自システムのリソース能力と自システムに隣接する他のグリッドシステムが提供するリソース能力とを求めることで、所定のグリッドシステムに対してジョブの実行要求がなされた場合の広域分散システム全体の処理能力がわかることとなる。したがって、図１３〜１５に示した従来技術のように、メタスケジューラを設けて広域分散システム全体のグリッドシステムやそのローカルリソースの状態を把握するための情報交換を行う必要がなく、ネットワーク負荷を大幅に軽減することができる。

本実施形態は、グリッドシステムのグリッドサーバ１００とローカルリソースであるプ
ロセスサーバ２００とを、グリッドサーバ１００に設けられたリソースエージェント１２０をインタフェースモジュールとして接続すると共に、かつグリッドサーバ１００とネットワーク上で隣接する他のグリッドシステムのグリッドサーバ１００とを、同様のリソースエージェント１２０を介して接続した。このため、ネットワーク上で隣接する各グリッドシステムのグリッドサーバ１００は、相互に相手のグリッドシステムを自システムのローカルリソースと同様に扱うことができ、これにより、グリッドシステム群が上述したネットワークスキームによって接続された広域分散システムを実現することが可能となる。
各グリッドサーバ１００のスケジューラ１１０は、他のグリッドシステムと自システムのローカルリソースとを区別する必要がないため、広域分散システム用の特別の仕組みを導入する必要はない。また、広域分散システムを構成するグリッドシステム群を統括的に管理するメタスケジューラを設ける必要もない。このため、システムの開発に要する手間やコストを大幅に削減することができる。

さらに本実施形態では、ローカルリソースおよび隣接する他のグリッドシステムからなるリソース手段の情報を、各リソース手段に対応させて設けられたリソースエージェント１２０が管理するため、スケジューラ１１０は各リソース手段の動作状態を考慮することなくリソースエージェント１２０に対してジョブの割り当てを行えば良い。したがって、広域分散システムを構成するグリッドシステム群に新たなグリッドシステムが追加されたり、グリッドシステム群から所定のグリッドシステムが除外されたりした場合、これらのグリッドシステムに隣接するグリッドシステムにおいて、対応するリソースエージェント１２０を追加あるいは削除するだけで対応することができる。このため、システムの拡張性や柔軟性が非常に高い。
そして、ネットワーク上で隣接するグリッドシステムを担当するリソースエージェント１２０の数を加減することにより、階層構造やカスケード構造など、任意のネットワーク構造を持った広域分散システムを容易に構築することができる。
例えば、１つのグリッドシステムにのみ他のグリッドシステムを担当するリソースエージェント１２０を多数設けることにより、この１つのグリッドシステムをセンターとして用い、他のグリッドシステム群をバックアップとして運用する、集中型スキームに似た運用形態のシステムを構築できる。
また、個々のグリッドシステムにおいて他のグリッドシステムを担当するリソースエージェント１２０を１つだけ設けることにより、各グリッドシステムがカスケード的に接続されたシステムを構築できる。
さらに、リソースエージェント１２０の設定によって、ネットワークに障害が起きた場合に使用される代替のグリッドシステムを定義しておくことも容易に可能なので、障害に対して堅牢な広域分散システムを構築することが可能である。

本実施形態による広域分散システムの全体構成を示す図である。 図１の広域分散システムを構成する個々のグリッドシステムの構成を示す図である。 本実施形態におけるグリッドサーバおよびプロセスサーバを実現するのに好適なコンピュータ装置のハードウェア構成の例を模式的に示した図である。 本実施形態におけるグリッドサーバの機能構成を示す図である。 本実施形態におけるプロセスサーバの機能構成とグリッドサーバのリソースエージェントとの関係を示す図である。 本実施形態の広域分散システムにジョブ実行リクエストを発行するクライアントの機能構成とグリッドサーバのスケジューラとの関係を示す図である。 本実施形態のスケジューラによるジョブのスケジューリングの動作を説明するフローチャートである。 本実施形態におけるリソースエージェントとＧＳエージェント・インタフェースとスケジューラとの関係を示す図である。 本実施の形態による広域分散システムを構成するグリッドシステム群の全体構成を示す図である。 本実施形態のネットワークスキームにより接続されたグリッドシステム群の所定のグリッドシステムにジョブが投入された場合の分散の様子を示す図である。 図１０のグリッドシステム群において、他のグリッドシステムに対してジョブが投入された場合の分散の様子を示す図である。 図１０のグリッドシステム群において所定のグリッドシステムにジョブが投入された場合のリソース能力を説明する図である。 集中型スキームによる広域分散システムのシステム構成を概略的に示した図である。 階層型スキームによる広域分散システムのシステム構成を概略的に示した図である。 分散型スキームによる広域分散システムのシステム構成を概略的に示した図である。

符号の説明

１１…ＣＰＵ（Central Processing Unit：中央処理装置）、１３…メインメモリ、１５
…磁気ディスク装置（ＨＤＤ）、１６…ネットワークインタフェース、１００…グリッドサーバ、１１０…スケジューラ、１１１…リソース能力問い合わせ応答部、１１２…リソース能力取得部、１１３…ジョブ受け付け部、１１４…最適リソース選択部、１１５…ジョブ依頼部、１２０…リソースエージェント、１２１…リソース状況管理部、１２２…リソース能力管理部、１２３…ジョブ受け付け部、１２４…ジョブ依頼部、１３０…ＧＳエージェント・インタフェース、１３１…リソース能力情報取得部、１３２…リソース能力情報通知部、１３３…ジョブ受け付け部、１３４…ジョブ実行依頼部、２００…プロセスサーバ、２１０…ＰＳエージェント・インタフェース、２１１…ＰＳ状況監視部、２１２…リソース能力情報通知部、２１３…ジョブ受け付け部、２１４…ジョブ実行部、３００…クライアント、３１０…リソース能力問い合わせ部、３２０…ジョブ依頼部

Claims (14)

1. 複数のコンピュータシステムをネットワークを介して接続する分散処理環境において、当該ネットワークに接続されたコンピュータシステムであって、
   ジョブを実行するコンピュータ資源（ローカルリソース）と、
   ジョブの割り当ておよび実行要求を行うグリッドサーバとを備え、
   前記グリッドサーバが、
   前記ネットワーク上で前記コンピュータシステム（自システム）に接続されている少なくとも１つの他のコンピュータシステム（ネットワークリソース）および前記ローカルリソースに関する情報（リソース情報）を管理し、これらのリソースにジョブの実行を要求するエージェントと、
   第１のジョブの実行をもとめる第１の要求に応答して、前記リソース情報に基づき、前記ローカルリソースおよび前記ネットワークリソースのうち１または複数のリソースに当該第１のジョブを割り当てるスケジューラと、を具備することを特徴とする、
   コンピュータシステム。
2. 前記エージェントは、各々の前記ネットワークリソースおよび前記ローカルリソースごとに設けられることを特徴とする、請求項１に記載のコンピュータシステム。
3. 前記エージェントによって管理される前記リソース情報は、対応する前記ローカルリソースまたは前記ネットワークリソースの処理能力に関する静的情報を含むことを特徴とする、請求項２に記載のコンピュータシステム。
4. 前記エージェントによって管理される前記リソース情報は、対応する前記ローカルリソースまたは前記ネットワークリソースの実時間における負荷状況に関する動的情報を含むことを特徴とする、請求項２記載のコンピュータシステム。
5. 前記グリッドサーバは、
   前記ネットワーク上の他のコンピュータシステムから送信された第２のジョブの実行をもとめる第２の要求を受け付け、当該第２の要求を前記スケジューラに渡して当該第２のジョブの割り当てを依頼する第１のインタフェース手段をさらに具備することを特徴とする、請求項１に記載のコンピュータシステム。
6. 前記第１のインタフェース手段は、
   前記他のコンピュータシステムからの問い合わせに応じて、前記コンピュータシステム（自システム）に関する前記リソース情報を、当該他のコンピュータシステムに通知する手段をさらに有することを特徴とする、請求項５に記載のコンピュータシステム。
7. 前記ローカルリソースに対応する前記エージェントは、当該ローカルリソースの処理能力および動作状況に関する情報を前記リソース情報として管理し、
   前記ネットワークリソースに対応する前記エージェントは、当該ネットワークリソースが前記第１の要求に対して提供可能なリソースの処理能力に関する情報を前記リソース情報として管理し、
   前記スケジューラは、前記エージェントに管理されている前記リソース情報に基づいて、前記第１のジョブの割り当てを行うことを特徴とする、
   請求項２に記載のコンピュータシステム。
8. 前記ローカルリソースは、
   対応する前記エージェントからの問い合わせに応じて、前記リソース情報を当該エージェントに通知する第２のインタフェース手段をさらに具備することを特徴とする、請求項
   ２に記載のコンピュータシステム。
9. それぞれがジョブを実行するローカルのコンピュータ資源（ローカルリソース）を有する複数のコンピュータシステムをネットワークを介して接続する分散処理環境において、ジョブの実行を制御するための方法であって、
   前記ネットワークに接続された第１のコンピュータシステムが、自身の前記ローカルリソースからその処理能力に関する第１のリソース情報を、前記ネットワーク上で当該第１のコンピュータシステムと接続されている少なくとも１つの第２のコンピュータシステム（ネットワークリソース）からその処理能力に関する第２のリソース情報を、それぞれ取得して管理するステップと、
   前記第１のコンピュータシステムが、第１のジョブの実行をもとめる第１の要求に応答して、前記第１および第２のリソース情報に基づいて、前記ローカルリソースと前記ネットワークリソースを対象として前記第１のジョブの割り当てを行うステップと、
   前記第１のコンピュータシステムが、前記第１のジョブの割り当てられたリソースに対して当該第１のジョブの実行をもとめる第２の要求を発行するステップと、
   を含むことを特徴とするジョブ実行制御方法。
10. 前記第１のコンピュータシステムが、発行された前記第２の要求を一時的に保持し、前記第１のジョブの割り当てられた前記リソースの動作状況に応じて、当該リソースに送信するステップをさらに有することを特徴とする、請求項９記載の方法。
11. 前記第２のコンピュータシステムが、前記ネットワーク上で当該第２のコンピュータシステムと接続されている少なくとも１つの第３のコンピュータシステムとの関係で、前記第１のコンピュータシステムと同等のステップを実行することを特徴とする、請求項１０記載の方法。
12. 前記第２のコンピュータシステムが、前記第１のコンピュータシステムからの問い合わせに応答して、前記第２のリソース情報を通知するステップを有することを特徴とする、請求項９記載の方法。
13. それぞれがジョブを実行するローカルのコンピュータ資源（ローカルリソース）を有する複数のコンピュータシステムをネットワークを介して接続する分散処理環境において、前記ネットワークに接続された第１のコンピュータシステムに、
    前記ネットワークに接続された第１のコンピュータシステムが、自身の前記ローカルリソースからその処理能力に関する第１のリソース情報を、前記ネットワーク上で当該第１のコンピュータシステムと接続されている少なくとも１つの第２のコンピュータシステム（ネットワークリソース）からその処理能力に関する第２のリソース情報を、それぞれ取得して管理する処理と、
    前記第１のコンピュータシステムが、第１のジョブの実行をもとめる第１の要求に応答して、前記第１および第２のリソース情報に基づいて、前記ローカルリソースと前記ネットワークリソースを対象として前記第１のジョブの割り当てを行う処理と、
    前記第１のコンピュータシステムが、前記第１のジョブの割り当てられたリソースに対して当該第１のジョブの実行をもとめる第２の要求を発行する処理と、
    を実行させることを特徴とするプログラム。
14. 前記第１のコンピュータシステムが、発行された前記第２の要求を一時的に保持し、前記第１のジョブの割り当てられた前記リソースの動作状況に応じて、当該リソースに送信する処理を前記コンピュータにさらに実行させることを特徴とする請求項１３に記載のプログラム。
    

Images