WO2005116832A1

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

Info

Publication number: WO2005116832A1
Application number: PCT/JP2005/009350
Authority: WO
Inventors: Kazutoshi Sugimoto; Takashi Yonezawa; Kazuhisa Misono
Original assignee: International Business Machines Corporation
Priority date: 2004-05-31
Filing date: 2005-05-23
Publication date: 2005-12-08
Also published as: CN1954295A; JPWO2005116832A1

Abstract

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

Description

明細書

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

技術分野

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

背景技術

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

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

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

3種類に分けられる (集中型スキームおよび階層型スキームについては例えば非特許文献 1を参照、分散型スキームについては例えば非特許文献 2を参照)。

[0005] 図 13は、集中型スキームによるシステム構成を概略的に示した図である。

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

[0006] 図 14は、階層型スキームによるシステム構成を概略的に示した図である。

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

[0007] 図 15は、分散型スキームによるシステム構成を概略的に示した図である。

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

[0008] 非特許文献 1： Chris Smith, "Open Source Metascheduling for Virtual Organizations with the Community Scheduler Framework (CSF)", Technical Whitepaper, Platform Computing Inc. 2003年 8月 .

非特許文献 2 : Vi jay Subramani, "Distributed Job Scheduling on Computational Grids using Multiple simultaneous Requests , IEEE International Symposium on High Performance Distributed Computing (HPDC 2002), 2002年.

発明の開示

発明が解決しょうとする課題

[0009] 上述したように、ネットワーク上の複数のグリッドシステム群に存在するコンピュータ資源を統合して利用する広域的な分散システムを構築するため、グリッドシステム群全体を管理する仕組みが従来から提案されて!ヽる。

しかし、上述した集中型スキームは、メタスケジューラにおいてネットワーク上の各口一カルサイトにあるコンピュータ資源の詳細な情報を管理する必要があるので、新し V、グリッドシステムの追加などシステム構成を変更する場合、メタスケジューラによるスケジユーリングに反映させるためにセンターサーバでの手続きが必要となる。したがつて、システム構成の変更（ローカルサイトの追加、削除、ローカルサイトにおけるコンビユータ資源の変更等）に伴って、メタスケジューラにおける設定の更新を要し、センタ一サーバにおける運用 '管理の負荷が大きくなる。したがって、システム構成の変更や規模の拡大縮小に容易に対応することができず、スケーラブルなシステムにするのは難しい。

[0010] また、階層型スキームは、センターサーバのメタスケジューラからローカルサイトのスケジユーラにジョブをサブミットした後は、メタスケジューラは、そのジョブに対して直接に関与しないため、ジョブのサブミット後に他のローカルサイトに空きができても、各ジヨブの実行は、そのジョブが送られた各ローカルサイトにおいて実行される。このため

、必ずしも効率良くジョブが実行されない。

なお、階層型スキームでは、各ローカルサイト間で情報をやりとりすることにより、他のローカルサイトに空きができた場合に、すでに別のローカルサイトにサブミットされたジョブを空、たローカルサイトに再サブミットする仕組みを導入することもできる。しかし、このような仕組みを導入すると、システムが複雑ィ匕してしまうため、開発に手間を要する。

また、各ローカルサイト間で情報をやりとりするために、ネットワーク負荷が増大してしまう。さら〖こ、階層型スキームにおいても、集中型スキームと同様に、システム構成の変更に伴ってメタスケジューラにおける設定の更新を要するため、システム構成の変更や規模の拡大縮小に容易に対応することができず、スケーラブルなシステムにするのは難しい。

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

さらに、階層型スキームや分散型スキームでは、メタスケジューラとローカルなスケジユーラとを個別に開発しなければならず、開発コストが増大する。

[0012] そこで本発明は、グリッドシステム群に存在するコンピュータ資源を統合して利用する広域分散システムにお、て、システム構成の変更や規模の拡大縮小に容易に対応可能なスケーラブルなシステム構成を実現することを目的とする。

また本発明は、効率よくジョブを実行するためにローカルサイト間で情報をやり取りしながら、ネットワーク負荷を軽減することを他の目的とする。

また本発明は、システムの開発コストを増大させることなぐグリッドシステム群を統合した広域分散システムを実現することをさらに他の目的とする。

課題を解決するための手段

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

[0014] より詳細には、エージェントは、ローカルリソースおよびネットワーク上で自システムに隣接する（直接に接続されている)他のグリッドシステム (ネットワークリソース）のそれぞれに対して個別に設けられ、各々が対応するリソース手段との間で設定された個別の通信形式でジョブの実行要求を行う。

ローカルリソースに対応するエージェントは、その能力および動作状況に関する情報を力かるローカルリソース力も取得して管理し、他のグリッドシステム (ネットワークリソース）に対応するエージェントは、そのグリッドシステムがジョブの実行要求に対して提供可能なリソース能力の情報を力かる他のグリッドシステムにおけるグリッドサーバ力も取得して管理する。そして、スケジューラは、リソースエージェントに管理されている各情報に基づいて、リソース手段に対するジョブの割り当てを行う。

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

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

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

発明の効果

[0019] 以上のように構成された本発明によれば、広域分散システムを構成する各グリッドシステムのグリッドサーバを、エージェントを介して接続し、このエージェントに、担当するグリッドシステムの情報を持たせることにより、担当エージェントの追加、削除によつてグリッドシステム群全体の構成の変更に対応できるため、システム構成の変更ゃ規模の拡大縮小に容易に対応可能なスケーラブルなシステム構成を実現できる。また本発明によれば、各グリッドシステムがネットワーク上で隣接する他のグリッドシステムの情報を持つことによって、結果的にグリッドシステム群全体の情報が各グリツドシステムに共有されることとなるので、各グリッドシステム間で頻繁に情報交換を行う必要がなぐネットワーク負荷を軽減することができる。

さらに本発明によれば、グリッドシステム群全体を統括制御するための固有の仕組みを必要としないので、システムの開発に要する手間やコストを大幅に削減することができ、かつ様々なネットワーク構造を持ったシステムを容易に構築できると!、う柔軟性に富んだシステムを実現できる。

発明を実施するための最良の形態

[0020] 以下、添付図面を参照して、本発明を実施するための最良の形態 (以下、実施形態）について詳細に説明する。

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

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

[0022] 図 2は、図 1の広域分散システムを構成する個々のグリッドシステムの構成を示す図である。

図 2に示すように、本実施形態によるグリッドシステムは、ジョブの割り当て (スケジュ一リング)を行うグリッドサーバ（GS) 100と、グリッドサーバ 100による割り当てにしたがって実際にジョブを実行するローカルリソースとしてのプロセスサーバ（PS) 200とを備える。また、グリッドサーバ 100は、他のグリッドシステムのグリッドサーバ 100とも接続されている。

[0023] 本実施形態において、グリッドサーバ 100とプロセスサーバ 200、および複数のダリッドシステムのグリッドサーバ 100どうしは、インターネットその他のコンピュータネットワークにて接続されている。このコンピュータネットワークは、通信プロトコルや、有線力無線かといつた通信形式を問わず、またファイアウォールやその他のアクセス制限を設けたものであっても良ヽ。

また、詳しくは後述する力上記のネットワークスキームを実現するために、本実施形態のグリッドサーバ 100は、エージェントと呼ぶインタフェースモジュールを備え、このエージェントを介してプロセスサーバ 200や他のグリッドシステムのグリッドサーバ 1 00と接続する。力かる装置間接続のフレームワークを、以下、エージェントフレームヮ ~~ク (Agent Framework)と称す。

[0024] 図 3は、本実施形態におけるグリッドサーバ 100およびプロセスサーバ 200を実現するのに好適なコンピュータ装置のハードウェア構成の例を模式的に示した図である図 3に示すコンピュータ装置は、演算手段である CPU (Central Processing Unit : 中央処理装置） 11と、 MZB (マザ一ボード）チップセット 12および CPUバスを介して CPU11に接続されたメインメモリ 13と、同じく MZBチップセット 12および AGP ( Accelerated Graphics Port)を介して CPU11に接続されたビデオカード 1

4と、 PCI (Peripheral Component Interconnect)バスを介して M/Bチップセット 12に接続された磁気ディスク装置 (HDD) 15、ネットワークインタフェース 16と、さらにこの PCIバスからブリッジ回路 17および IS A (Industry Standard Architecture)バスなどの低速なバスを介して M/Bチップセット 12に接続されたフレキシブルディスクドライブ 18およびキーボード Zマウス 19とを備える。

[0025] なお、図 3は本実施形態を実現するコンピュータ装置のハードウェア構成を例示するに過ぎず、本実施形態を適用可能であれば、他の種々の構成を取ることができる。例えば、ビデオカード 14を設ける代わりに、ビデオメモリのみを搭載し、 CPU11にてイメージデータを処理する構成としても良いし、外部記憶装置として、 ATA (AT Attachment

)や SCSI (Small Computer System Interface)などのインタフェースを介して CD -R (Compact Disc Recordable)や DVD— RAM (Digital Versatile Disc Random Access Memory)のドライブを設けても良い。

[0026] 図 4は、本実施形態におけるグリッドサーバ 100の機能構成を示す図である。

グリッドサーバ 100は、自システム内のローカルリソースである各プロセスサーバ 20 0に対するジョブの割り当て（スケジューリング）を行うスケジューラ 110と、プロセスサーバ 200の管理を行、、プロセスサーバ 200に対するリクエストおよびレスポンスの送受信を中継するリソースエージェント 120と、自システムをあた力も他のグリッドシステムのリソースであるかのように動作させるためのグリッドサーバ用リソースエージェント 'インタフェース（以下「GSエージェント 'インタフェース」） 130とを備える。リソースェージェント 120は、各プロセスサーバ 200およびネットワーク上で隣接する他のグリツドシステム (ネットワークリソース）ごとに設けられている。そして、スケジューラ 110は、このリソースエージェント 120を介して各プロセスサーバ 200および他のグリッドシステムのグリッドサーバ 100にアクセスする。

[0027] スケジューラ 110は、例えば図 3に示したプログラム制御された CPU11とメインメモリ 13や磁気ディスク装置 15等の記憶手段とで実現され、その具体的な機能として図 4に示すように、リソース能力問い合わせ応答部 111と、リソース能力取得部 112と、ジョブ受け付け部 113と、最適リソース選択部 114と、ジョブ依頼部 115とを備える。リソース能力問、合わせ応答部 111は、 GSエージェント ·インタフェース 130を介して入力される外部力の問い合わせ (リソース能力取得要求）に応じて、提供可能な自システムのリソース能力を計算し返答する。提供可能なリソース能力は、後述のリソース能力取得部 112により取得される情報に基づいて計算される。また、リソース能力の提供対象に応じて提供可能なリソース能力を変更することもできる。

リソース能力取得部 112は、自システムが利用可能なリソース能力を各プロセスサーバ 200およびネットワーク上で隣接する他のグリッドシステムに対応するリソースェージェント 120に問合せ、情報を取得する（以下、これら自システムのローカルリソースとして認識されるプロセスサーバ 200およびネットワークリソースとして認識される他のグリッドシステムを合わせて、リソース手段と称す)。取得される情報には、自システムにおける本来の処理能力や記憶装置の記憶容量などを静的情報と、実時間の負荷状況に基づく動的情報とが含まれる。

ジョブ受け付け部 113は、外部のコンピュータシステム（例えばクライアント）や GSェージェント 'インタフェース 130からジョブの実行要求を受け付ける。

最適リソース選択部 114は、リソース能力取得部 112により取得されたリソース能力の情報に基づき、ジョブに応じてその実行に最適なリソース手段を選択し、ジョブの割り当てを行う。このジョブの割り当てにおける最適化のロジックは任意で良!、。ジョブ依頼部 115は、最適リソース選択部 114において選択されたリソース手段に対応するリソースエージェント 120に対して、ジョブの実行を要求するリクエストを発行する。

[0028] 本実施形態では、リソースエージェント 120がスケジューラ 110と利用可能なリソース手段との間の通信を中継し、スケジューラ 110によるジョブの実行要求をこれらのリソース手段に代わって受け付ける。そのため、リソース能力取得部 112の問い合わせ先やジョブ依頼部 115のリクエストの発行先がリソースエージェント 120となって!/、る

1S それ以外のスケジューラ 110の機能自体は、既存のスケジューラと変わらない。また、グリッドサーバ 100と個々のプロセスサーバ 200あるいは他のグリッドシステムのグリッドサーバ 100との間における通信形式の違いは、リソースエージェント 120における設定によって吸収され、スケジューラ 110自身はリクエストを発行する際に通信形式の差異を考慮する必要がない。したがって、スケジューラ 110には、既存のグリッドシステムで利用されて、るスケジューラを用いることができる。

[0029] リソースエージェント 120は、例えば図 3に示したプログラム制御された CPU11 とメインメモリ 13や磁気ディスク装置 15等の記憶手段とネットワークインタフェース 16 とで実現され、その具体的な機能として図 4に示すように、リソース状況管理部 121と、リソース能力管理部 122と、ジョブ受け付け部 123と、ジョブ依頼部 124とを備える。リソース状況管理部 121は、対応するリソース手段にアクセスして、該当するプロセスサーバ 200 (ローカルリソース）またはグリッドシステム（ネットワークリソース）における現在の動作状況を把握する。

リソース能力管理部 122は、対応するリソース手段のジョブ実行能力に関する統計情報等を管理し、スケジューラ 110のリソース能力取得部 112からの問い合わせに応じて、管理している情報を返す。ここで、ジョブ実行能力に関する統計情報等とは、単に CPU自身の処理能力や記憶装置の記憶容量の静的な情報だけでなぐ CPUに対する負荷の時間変動や動作傾向といった動的な内容を統計的に処理して得られた情報を含む。

リソース状況管理部 121およびリソース能力管理部 122に管理されるこのようなリソース情報は、リソースエージェント 120が対応しているリソース手段から取得し、図 3のメインメモリ 13や磁気ディスク装置 15等の記憶手段に格納する。

ジョブ受け付け部 123は、スケジューラ 110のジョブ依頼部 115から発行されたジョブ実行リクエストを受け付ける。

ジョブ依頼部 124は、ジョブ受け付け部 123により受け付けられたジョブ実行リクェストを対応するリソース手段に送信する。

GSエージェント 'インタフェース 130は、例えば図 3に示したプログラム制御された C PU11とメインメモリ 13や磁気ディスク装置 15等の記憶手段とネットワークインタフエース 16とで実現され、その具体的な機能として図 4に示すように、リソース能力情報取得部 131と、リソース能力情報通知部 132と、ジョブ受け付け部 133と、ジョブ実行依頼部 134とを備える。

上述したように、 GSエージェント 'インタフェース 130は、グリッドシステムをネットヮーク上の他のグリッドシステムに対して当該他のグリッドシステムのローカルリソースと同様に利用可能とするための機能である。この GSエージェント 'インタフェース 130 により、グリッドサーバ 100は、他のグリッドシステムのグリッドサーバ 100からの要求を受け付け、自システムが利用可能なリソース手段を用いてジョブを実行した結果を返すことができる。

[0031] リソース能力情報取得部 131は、外部力ものジョブの実行要求に対して提供可能な自システムのリソース能力の情報（リソース情報）を、スケジューラ 110に問い合わせて取得する。

リソース能力情報通知部 132は、受信したリソース能力取得要求に応じて、リソース能力情報取得部 131において取得されたリソース情報を、リソース能力取得要求の送信元に通知する。リソース能力取得要求がネットワーク上の他のグリッドシステムにおけるグリッドサーバ 100の対応するリソースエージェント 120から受信された場合は、当該リソースエージェント 120に通知する。リソースエージェント 120では、リソース状況管理部 121およびリソース能力管理部 122がこの通知を受け付け、メインメモリ 1 3や磁気ディスク装置 15等の記憶装置に格納して管理する。リソース能力情報通知部 132からグリッドサーバ 100への通知は、定期的に行っても良いし、自システムの動作状況が変更された際に行うようにしても良い。また、グリッドサーバ 100のリソースエージェント 120から任意のタイミングで対応する他のグリッドシステムのグリッドサーノ 100へ問い合わせても良い。

ジョブ受け付け部 133は、他のグリッドシステムにおけるグリッドサーバ 100のリソースエージェント 120のジョブ依頼部 124力も送信されたジョブ実行リクエストを受け付ける。

ジョブ実行依頼部 134は、ジョブ受け付け部 133により受け付けられたジョブのスケジユーリングおよび実行を、スケジューラ 110に依頼する。

[0032] 次に、プロセスサーバ 200の機能構成と、対応するリソースエージェント 120との関係について説明する。

図 5は、プロセスサーバ 200の機能構成とグリッドサーバ 100のリソースエージェント 120との関係を示す図である。

図 5に示すように、プロセスサーバ 200は、図 3に示したようなコンピュータ装置をグリツドシステムにおけるプロセスサーバ 200として機能させるためのプロセスサーバ用リソースエージェント.インタフェース（以下「PSエージェント 'インタフェース」） 210を備えている。

[0033] PSエージェント 'インタフェース 210は、例えば図 3に示したプログラム制御された C PU11とメインメモリ 13や磁気ディスク装置 15等の記憶手段とネットワークインタフエース 16とで実現され、その具体的な機能として図 5に示すように、 PS状況監視部 21 1と、リソース能力情報通知部 212と、ジョブ受け付け部 213と、ジョブ実行部 214とを備える。

PS状況監視部 211は、自装置 (プロセスサーバ 200)の現在の使用状況や資源の状況を監視し、情報を収集する。

リソース能力情報通知部 212は、 PS状況監視部 211にお、て収集された PSの使用状況や資源の状況に関する情報を、グリッドサーバ 100のリソースエージェント 12 0に通知する。リソースエージェント 120では、リソース状況管理部 121およびリソース能力管理部 122がこの通知を受け付け、メインメモリ 13や磁気ディスク装置 15等の記憶装置に格納して管理する。リソース能力情報通知部 212からグリッドサーバ 100 への通知は、定期的に行っても良いし、プロセスサーバ 200の動作状況が変更された際に行うようにしても良い。また、グリッドサーバ 100の対応するリソースエージェント 120から任意のタイミングでプロセスサーバ 200へ問、合わせても良!、。

ジョブ受け付け部 213は、グリッドサーバ 100のリソースエージェント 120のジョブ依頼部 124から送信されたジョブ実行リクエストを受け付ける。

ジョブ実行部 214は、ジョブ受け付け部 213により受け付けられたジョブを、プロセスサーバ 200の資源を用いて実行する。

[0034] グリッドサーバ 100の GSエージェント 'インタフェース 130とプロセスサーバ 200の P Sエージェント 'インタフェース 210とを比較すると、 PS状況監視部 211が自装置の状況を監視して情報を収集するのに対し、リソース能力情報取得部 131がスケジューラ 110に自システムのリソース能力を問い合わせており、また、ジョブ実行部 214が自装置の資源を用いてジョブを実行するのに対し、ジョブ実行依頼部 134がスケジユーラ 110にジョブの実行を依頼している点が異なる。これは、 PSエージェント 'インタフエース 210が組み込まれたプロセスサーバ 200がグリッドシステムにおいてジョブを実行するローカルリソースであるのに対し、 GSエージェント 'インタフェース 130が組み込まれたグリッドサーバ 100がグリッドシステムを統括制御してジョブ実行のスケジュ一リングを行うサーバであることに基づく相違である。

[0035] すなわち、リソース能力取得要求やジョブの実行要求を送信するグリッドサーバ 10 0のリソースエージェント 120と、これに対応する GSエージェント 'インタフェース 130 および PSエージェント 'インタフェース 210との関係では、 GSエージェント 'インタフエース 130と PSエージェント 'インタフェース 210とは何ら変わりがない。したがって、リソースエージェント 120は、対応する相手がローカルリソースであるプロセスサーバ 2 00かネットワークリソースである他のグリッドサーバ 100かに関わらず、同じ機能構成を有することとなる。

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

[0037] 次に、上記のように構成された本実施形態による広域分散システムの動作について説明する。

本実施形態では、所定のクライアントから所定のグリッドシステムに対して発行されたジョブ実行リクエストに応じて、広域分散システムを構成するグリッドシステム群により負荷分散されてジョブが実行される。ここで、クライアントとは、本実施形態の広域分散システムを構成するいずれかのグリッドシステムにアクセス可能なコンピュータや P DA (Personal Digital Assistant)等の情報機器である。後述する機能を備えたプロセスサーバ 200がクライアントとしてジョブ実行リクエストを発行することもできる。

図 6は、本実施形態の広域分散システムにジョブ実行リクエストを発行するクライアントの機能構成とグリッドサーバ 100のスケジューラ 110との関係を示す図である。図 6に示すように、クライアント 300は、ジョブ実行リクエストの送信先であるグリッドシステムのリソース能力を問い合わせるためのリソース能力問い合わせ部 310と、ジョブ実行リクエストを発行してグリッドシステムに送信するジョブ依頼部 320とを備える。なお、クライアント 300は、所望のジョブに対する実行結果が得られれば良ぐジョブの実行に必要なコンピュータ資源の調達はグリッドシステムに任せて良、場合は、リソース能力問い合わせ部 310は必須の構成要件ではない。これらの機能は、例えばクライアント 300が図 3に示したコンピュータ装置にて構成される場合、プログラム制御された CPU 11とメインメモリ 13や磁気ディスク装置 15等の記憶手段とで実現される。

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

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

[0040] 図 7は、スケジューラ 110によるジョブのスケジューリングの動作を説明するフローチヤートである。

図 7を参照すると、最適リソース選択部 114は、リソース能力問い合わせ応答部 111 およびリソース能力取得部 112を介してリソースエージェント 120から各リソース手段の能力や動作傾向等の統計情報等を取得し (ステップ 701)、これらの情報およびジヨブの種類や特性に基づいて最適なスケジューリングを行う（ステップ 702)。そして、ジョブ依頼部 115が、最適リソース選択部 114による処理結果に基づいて、ジョブが割り当てられたリソース手段の動作状況に関わらずにジョブ実行リクエストを発行し、そのリソース手段に対応するリソースエージェント 120に送信する（ステップ 703)。

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

[0042] リソースエージェント 120は、スケジューラ 110のジョブ依頼部 115から受け取ったジョブ実行リクエストを対応するリソース手段に送信し、そのリソース手段力もジョブの実行結果を受け取ってスケジューラ 110に返す。ここで、リソースエージェント 120の動作は、対応するリソース手段がプロセスサーバ 200であるか他のグリッドシステムであるかによる違いはない。

スケジューラ 110は、リソースエージェント 120から受け取った各リソース手段によるジョブの実行結果を統合して、クライアント 300に返す。

[0043] さて、本実施形態では、ジョブを実行するリソース手段は、ジョブの実行を依頼されたグリッドシステムのローカルリソースであるプロセスサーバ 200である場合とネットヮークリソースである他のグリッドシステムである場合とがある。このうち、プロセスサーバ 200は、 PSエージェント 'インタフェース 210のジョブ受け付け部 213がグリッドサーノ 100のリソースエージェント 120からジョブ実行リクエストを受け付けると、そのリクェストに応じてジョブ実行部 214がジョブを実行し、実行結果をグリッドサーバ 100のリソースエージェント 120に返す。

[0044] 一方、リソース手段がグリッドシステムである場合、リソースエージェント 120からのジヨブ実行リクエストは、当該グリッドシステムのグリッドサーバ 100における GSエージェント 'インタフェース 130のジョブ受け付け部 133により受け付けられ、ジョブ実行依頼部 134により当該グリッドサーバ 100のスケジューラ 110に送られる。

図 8は、リソースエージェント 120と GSエージェント 'インタフェース 130とスケジユーラ 110との関係を示す図である。

ここで、図 8と図 6とを比較すると、スケジューラ 110にとつては、 GSエージェント'ィンタフェース 130との関係と、クライアント 300の PSエージェント 'インタフェース 210との関係は等価である。したがって、スケジューラ 110は、上述したクライアント 300から直接受け取ったジョブ実行リクエストに対する動作と同様に、 GSエージェント 'インタフェース 130を介して他のグリッドシステムのグリッドサーバ 100から受け取ったジョブ実行リクエストに対してもスケジューリングを行、、自システムが利用可能なリソース手段に対してジョブの実行を依頼することができる。

[0045] ところで、リソースエージェント 120は、 [0029]で述べたように、対応するリソース手段力現在の動作状況やジョブ実行能力に関する情報 (リソース情報)を取得して、リソース状況管理部 121およびリソース能力管理部 122により管理している。このリソース情報は、リソース手段がプロセスサーバ 200である場合は、その PSエージェント'ィンタフェース 210の PS状況監視部 211により収集され、リソース能力情報通知部 21 2によりジソースエージェント 120に送られる。

一方、リソース手段が他のグリッドシステムである場合、リソース情報は、当該グリッドシステムのグリッドサーバ 100における GSエージェント 'インタフェース 130のリソース能力情報取得部 131により取得され、リソース能力情報通知部 132によりリソースエージェント 120に送られる。ここで、リソース能力情報取得部 131は、図 4に示したように、スケジューラ 110のリソース能力問、合わせ応答部 111に問、合わせを行い、これらの情報を受け取る。したがって、リソース能力問い合わせ応答部 111は、クライアント 300からリソース能力の問、合わせを受ける場合と、 GSエージェント 'インタフエース 130から問い合わせを受ける場合とがある。

[0046] 1つのグリッドシステムに着目した場合、ネットワーク上でこのグリッドシステムに隣接する他のグリッドシステムは、当該グリッドシステムのリソース手段として利用できる一方で、当該グリッドシステムに対してジョブの実行を依頼することもできる。そして、所定のグリッドシステムから当該グリッドシステムに対してジョブの実行が依頼された場合を考えると、当該グリッドシステムは、ジョブの実行を依頼した所定のグリッドシステムを自システムのリソース手段として利用することはできな、。

したがって、 GSエージェント 'インタフェース 130から問い合わせを受けた場合、スケジユーラ 110は、 GSエージェント 'インタフェース 130に対してリソース能力取得要求を送信したグリッドサーバ 100が含まれるグリッドシステムをリソース手段として利用することはできない。したがってこの場合、スケジューラ 110は、リソース能力取得要求を送信したグリッドサーバ 100が含まれるグリッドシステムを除いて提供可能なリソース能力を計算して、 GSエージェント 'インタフェース 130へ返すこととなる。

[0047] 図 9は、本実施の形態による広域分散システムを構成するグリッドシステム群の全体構成を示す図である。

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

[0048] 図 10は、本実施形態のネットワークスキームにより接続されたグリッドシステム群の所定のグリッドシステムにジョブが投入された場合の分散の様子を示す図である。図 10の例では、破線で示された 5つのグリッドシステム（グリッド A、 B、 C、 D、 E)からなる広域分散システムのうち、グリッド Aにジョブが投入されている。このジョブは、まずグリッド Aのローカルリソースであるプロセスサーバ（PS) 200に分散投入される。そして、グリッド Aのローカルリソースの能力ではこのジョブを処理しきれず、オーバーフローが発生する場合は、グリッド Aのグリッドサーバ（GS) 100において、ネットワーク上で隣接するグリッド B、 Cに対応するリソースエージェント 120とスケジューラ 110との間で動作状況の確認等のネゴシエーションが行われ、当該ジョブがグリッド B、こ投入される。ジョブがグリッド B、 Cに投入された場合、各グリッド B、 Cのローカルリソースで実行され、グリッド Bでオーバーフローが生じる場合には、さらにグリッド Bに隣接するグリッド D、 Eにも当該ジョブが分散投入される。

[0049] なお、アプリケーションの種類によっては、グリッド B、 Cの動作状況等に関わらず、グリッド Aからグリッド B、 Cへジョブを渡してしまうこともできる。この場合、グリッド Aのグリッドサーバ 100において、グリッド B、 Cに対応するリソースエージェント 120が当該ジョブの実行依頼を受け付け、グリッド B、 Cがジョブを受け付け可能な状態となつた時点で、リソースエージェント 120からグリッド B、 Cへジョブの実行依頼が行われることとなる。

また、上記の説明では、自システムのローカルリソースではジョブを処理しきれずォ一バーフローが生ずる場合に他のグリッドシステムにジョブを投入することとした。このように、できるだけローカルリソースで優先的にジョブを処理する方法は、ネットワークの負荷を軽減するために好ましい。し力しながら、ジョブの分散投入の方法はこれに限るものではな、。自システムのローカルリソースおよび隣接する他のグリッドシステムの能力やジョブの種類、特性等に鑑み、最適な (実行効率の高い)分散となるように、任意のロジックでジョブの割り当てを行うことができる。

[0050] 図 11は、図 10のグリッドシステム群において、他のグリッドシステム（グリッド B)に対してジョブが投入された場合の分散の様子を示す図である。

図 11に示すように、グリッド Bに投入されたジョブは、まずグリッド Bのローカルリソースであるプロセスサーバ 200に投入され、オーバーフローが発生する場合に、ネットワーク上で隣接するグリッド A、 D、 Eに分散投入される。また、グリッド Aにおいてォーバーフローが生じるならば、さらにグリッド Cにもジョブが分散投入される。

このように、本実施形態のネットワークスキームにより接続されたグリッドシステム群では、各グリッドシステム間に主従関係がなぐ対等な関係で並列に動作するため、 V、ずれのグリッドシステムにジョブが投入されても、ネットワーク上で隣接するグリッドシステムに連鎖的にジョブが分散投入され、グリッドシステム群にて構成される広域分散システム全体でジョブを処理することが可能となる。

[0051] ここで、本実施形態による広域分散システムがジョブを実行する場合におけるリソース能力の計算方法の一例について説明する。

図 12は、図 10のグリッドシステム群において所定のグリッドシステムにジョブが投入された場合のリソース能力を説明する図である。

図 12において、各グリッドシステムのリソース能力は、次のように定義される。

C：グリッドシステム X自身の（ローカルリソースの）リソース能力 C ：クライアントからのジョブの実行要求に対してグリッドシステム xが提供可能なリソース能力

C ：ネットワーク上でグリッドシステム Xに隣接するグリッドシステム yからのジョブの実行要求に対してグリッドシステム Xが提供可能なリソース能力

すすななわち、 C および C は次の数 1式により計算される。

[数 1] し X for user し x + -/yeall adjacents of x Ί for χ

c χ for y = x + \U^ηzedll adjacents of x except y z for x

[0052] 図 12を参照すると、クライアント 300からグリッドシステム a (図 10のグリッド A)にジョブの実行要求が行われた場合、このジョブを実行するために提供される処理能力 C は次のように計算される。

C =C +C +C

ここで、グリッドシステム b (図 10のグリッド B)は、グリッドシステム aの他にグリツドシステム d、 e (図 10のグリッド D、 E)とも隣接しているので、グリッドシステム aに対して提供できるリソース能力は自システムのリソース能力とグリッドシステム d、 eから提供されるリソース能力とを加えたものとなる。すなわち、

C =C +C +C

である。一方、グリッドシステム c (図 10のグリッド C)は、グリッドシステム aとのみ隣接するので、自システムのリソース能力のみを提供でき、

c =c

となる。

[0053] 同様に図 12から、クライアント 300からグリッドシステム bにジョブの実行要求が行われた場合、このジョブを実行するために提供される処理能力 C は次のように計算される。

C =C +C +C +C そして、グリッドシステム a、 d、 eからそれぞれグリッドシステム bに提供されるリソースは、次のようになる a for b =c a +c c for a

C =C

d for b d

C =C

e for b e

[0054] また、クライアント 300からグリッドシステム dにジョブの実行要求が行われた場合、このジョブを実行するために提供される処理能力 C は次のように計算される。

d for user

C =C +C

d for user d b for d

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

C =C +C +C

b for d b a for b e for b

このうち、リソース能力 c 、いては上述の通りである。

a for b c につ

e for b

なお、以上の計算方法は例示に過ぎず、この方法に限らないことは言うまでもない

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

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

さらに本実施形態では、ローカルリソースおよび隣接する他のグリッドシステムからなるリソース手段の情報を、各リソース手段に対応させて設けられたリソースエージェント 120が管理するため、スケジューラ 110は各リソース手段の動作状態を考慮することなくリソースエージェント 120に対してジョブの割り当てを行えば良い。したがって、広域分散システムを構成するグリッドシステム群に新たなグリッドシステムが追加されたり、グリッドシステム群力所定のグリッドシステムが除外されたりした場合、これらのグリッドシステムに隣接するグリッドシステムにお、て、対応するリソースエージェント 120を追加あるいは削除するだけで対応することができる。このため、システムの拡張性や柔軟性が非常に高い。

そして、ネットワーク上で隣接するグリッドシステムを担当するリソースエージェント 1 20の数を加減することにより、階層構造やカスケード構造など、任意のネットワーク構造を持った広域分散システムを容易に構築することができる。

例えば、 1つのグリッドシステムにのみ他のグリッドシステムを担当するリソースエージェント 120を多数設けること〖こより、この 1つのグリッドシステムをセンターとして用い、他のグリッドシステム群をバックアップとして運用する、集中型スキームに似た運用形態のシステムを構築できる。

また、個々のグリッドシステムにおいて他のグリッドシステムを担当するリソースエージェント 120を 1つだけ設けることにより、各グリッドシステムがカスケード的に接続されたシステムを構築できる。

さらに、リソースエージェント 120の設定によって、ネットワークに障害が起きた場合に使用される代替のグリッドシステムを定義しておくことも容易に可能なので、障害に対して堅牢な広域分散システムを構築することが可能である。

図面の簡単な説明 [図 1]本実施形態による広域分散システムの全体構成を示す図である。

[図 2]図 1の広域分散システムを構成する個々のグリッドシステムの構成を示す図である。

[図 3]本実施形態におけるグリッドサーバおよびプロセスサーバを実現するのに好適なコンピュータ装置のハードウェア構成の例を模式的に示した図である。

[図 4]本実施形態におけるグリッドサーバの機能構成を示す図である。

[図 5]本実施形態におけるプロセスサーバの機能構成とグリッドサーバのリソースエージェントとの関係を示す図である。

[図 6]本実施形態の広域分散システムにジョブ実行リクエストを発行するクライアントの機能構成とグリッドサーバのスケジューラとの関係を示す図である。

[図 7]本実施形態のスケジューラによるジョブのスケジューリングの動作を説明するフローチャートである。

[図 8]本実施形態におけるリソースエージェントと GSエージェント 'インタフェースとスケジユーラとの関係を示す図である。

[図 9]本実施の形態による広域分散システムを構成するグリッドシステム群の全体構成を示す図である。

[図 10]本実施形態のネットワークスキームにより接続されたグリッドシステム群の所定のグリッドシステムにジョブが投入された場合の分散の様子を示す図である。

[図 11]図 10のグリッドシステム群において、他のグリッドシステムに対してジョブが投入された場合の分散の様子を示す図である。

[図 12]図 10のグリッドシステム群において所定のグリッドシステムにジョブが投入された場合のリソース能力を説明する図である。

[図 13]集中型スキームによる広域分散システムのシステム構成を概略的に示した図である。

[図 14]階層型スキームによる広域分散システムのシステム構成を概略的に示した図である。

[図 15]分散型スキームによる広域分散システムのシステム構成を概略的に示した図である。符号の説明

11〜CPU (Central Processing Unit:中央処理装置）、 13· "メインメモリ、 15

…磁気ディスク装置（HDD)、 16…ネットワークインタフェース、 100···グリッドサーバ、 110···スケジューラ、 111···リソース能力問い合わせ応答部、 112···リソース能力取得部、 113···ジョブ受け付け部、 114…最適リソース選択部、 115…ジョブ依頼部、 120···リソースエージェント、 121···リソース状況管理部、 122···リソース能力管理 123···ジョブ受け付け咅^ 124···ジョブ依頼咅^ 130 -GSエージェント 'インタフエース、 131···リソース能力情報取得部、 132···リソース能力情報通知部、 133···ジヨブ受け付け部、 134···ジョブ実行依頼部、 200···プロセスサーノ、 210 PSエージェント 'インタフェース、 211 "'PS状況監視部、 212···リソース能力情報通知部、 2 13···ジョブ受け付け咅^ 214—ジョブ実行咅^ 300···クライアント、 310···リソース會力問い合わせ部、 320…ジョブ依頼部

Claims

請求の範囲

[1] 複数のコンピュータシステムをネットワークを介して接続する分散処理環境にぉ、て

、当該ネットワークに接続されたコンピュータシステムであって、

ジョブを実行するコンピュータ資源（ローカルリソース）と、

ジョブの割り当ておよび実行要求を行うグリッドサーバとを備え、

前記グリッドサーバが、

前記ネットワーク上で前記コンピュータシステム（自システム）に接続されて、る少なくとも 1つの他のコンピュータシステム（ネットワークリソース）および前記ローカルリソースに関する情報（リソース情報）を管理し、これらのリソースにジョブの実行を要求するエージェントと、

第 1のジョブの実行をもとめる第 1の要求に応答して、前記リソース情報に基づき、前記ローカルリソースおよび前記ネットワークリソースのうち 1または複数のリソースに当該第 1のジョブを割り当てるスケジューラと、を具備することを特徴とする、コンピュータシステム。

[2] 前記エージェントは、各々の前記ネットワークリソースおよび前記ローカルリソースごとに設けられることを特徴とする、請求項 1に記載のコンピュータシステム。

[3] 前記エージェントによって管理される前記リソース情報は、対応する前記ローカルリソースまたは前記ネットワークリソースの処理能力に関する静的情報を含むことを特徴とする、請求項 2に記載のコンピュータシステム。

[4] 前記エージェントによって管理される前記リソース情報は、対応する前記ローカルリソースまたは前記ネットワークリソースの実時間における負荷状況に関する動的情報を含むことを特徴とする、請求項 2記載のコンピュータシステム。

[5] 前記グリッドサーバは、

前記ネットワーク上の他のコンピュータシステム力送信された第 2のジョブの実行をもとめる第 2の要求を受け付け、当該第 2の要求を前記スケジューラに渡して当該第 2のジョブの割り当てを依頼する第 1のインタフェース手段をさらに具備することを特徴とする、請求項 1に記載のコンピュータシステム。

[6] 前記第 1のインタフェース手段は、前記他のコンピュータシステムからの問い合わせに応じて、前記コンピュータシステム（自システム）に関する前記リソース情報を、当該他のコンピュータシステムに通知する手段をさらに有することを特徴とする、請求項 5に記載のコンピュータシステム。

[7] 前記ローカルリソースに対応する前記エージェントは、当該ローカルリソースの処理能力および動作状況に関する情報を前記リソース情報として管理し、

前記ネットワークリソースに対応する前記エージェントは、当該ネットワークリソースが前記第 1の要求に対して提供可能なリソースの処理能力に関する情報を前記リソース情報として管理し、

前記スケジューラは、前記エージェントに管理されている前記リソース情報に基づ V、て、前記第 1のジョブの割り当てを行うことを特徴とする、

請求項 2に記載のコンピュータシステム。

[8] 前記ローカルリソースは、

対応する前記エージェントからの問い合わせに応じて、前記リソース情報を当該ェージェントに通知する第 2のインタフェース手段をさらに具備することを特徴とする、請求項

2に記載のコンピュータシステム。

[9] それぞれがジョブを実行するローカルのコンピュータ資源（ローカルリソース）を有する複数のコンピュータシステムをネットワークを介して接続する分散処理環境において、ジョブの実行を制御するための方法であって、

前記ネットワークに接続された第 1のコンピュータシステム力自身の前記ローカルリソース力その処理能力に関する第 1のリソース情報を、前記ネットワーク上で当該第 1のコンピュータシステムと接続されている少なくとも 1つの第 2のコンピュータシステム (ネットワークリソース)力もその処理能力に関する第 2のリソース情報を、それぞれ取得して管理するステップと、

前記第 1のコンピュータシステム力第 1のジョブの実行をもとめる第 1の要求に応答して、前記第 1および第 2のリソース情報に基づいて、前記ローカルリソースと前記ネットワークリソースを対象として前記第 1のジョブの割り当てを行うステップと、前記第 1のコンピュータシステムが、前記第 1のジョブの割り当てられたリソースに対して当該第 1のジョブの実行をもとめる第 2の要求を発行するステップと、を含むことを特徴とするジョブ実行制御方法。

[10] 前記第 1のコンピュータシステムが、発行された前記第 2の要求を一時的に保持し、前記第 1のジョブの割り当てられた前記リソースの動作状況に応じて、当該リソースに送信するステップをさらに有することを特徴とする、請求項 9記載の方法。

[11] 前記第 2のコンピュータシステムが、前記ネットワーク上で当該第 2のコンピュータシステムと接続されている少なくとも 1つの第 3のコンピュータシステムとの関係で、前記第 1のコンピュータシステムと同等のステップを実行することを特徴とする、請求項 10 記載の方法。

[12] 前記第 2のコンピュータシステムが、前記第 1のコンピュータシステムからの問い合わせに応答して、前記第 2のリソース情報を通知するステップを有することを特徴とする、請求項 9記載の方法。

[13] それぞれがジョブを実行するローカルのコンピュータ資源（ローカルリソース）を有する複数のコンピュータシステムをネットワークを介して接続する分散処理環境において、前記ネットワークに接続された第 1のコンピュータシステムに、

前記ネットワークに接続された第 1のコンピュータシステム力自身の前記ローカルリソース力その処理能力に関する第 1のリソース情報を、前記ネットワーク上で当該第 1のコンピュータシステムと接続されている少なくとも 1つの第 2のコンピュータシステム (ネットワークリソース)力もその処理能力に関する第 2のリソース情報を、それぞれ取得して管理する処理と、

前記第 1のコンピュータシステム力第 1のジョブの実行をもとめる第 1の要求に応答して、前記第 1および第 2のリソース情報に基づいて、前記ローカルリソースと前記ネットワークリソースを対象として前記第 1のジョブの割り当てを行う処理と、

前記第 1のコンピュータシステムが、前記第 1のジョブの割り当てられたリソースに対して当該第 1のジョブの実行をもとめる第 2の要求を発行する処理と、

を実行させることを特徴とするプログラム。

[14] 前記第 1のコンピュータシステムが、発行された前記第 2の要求を一時的に保持し、前記第 1のジョブの割り当てられた前記リソースの動作状況に応じて、当該リソースに送信する処理を前記コンピュータにさらに実行させることを特徴とする請求項 13に記載のプログラム。