JP2006277617A - ジョブ管理装置、ジョブ管理プログラム、及びジョブ管理方法 - Google Patents

Abstract

【課題】 理想的なグリッド分散環境を実現できると共に、計算機資源の拡張性にも優れ、かつ計算機の秘匿性を実現できるジョブ管理装置を提供する。
【解決手段】 各バッチシステム３ａ、３ｂ…３ｎをＰ２Ｐにおけるピアとして分散し、それらバッチシステム３ａ，３ｂ，３ｃを連携させて情報を共有化する。そして、各バッチシステム３ａ、３ｂ…３ｎにおけるジョブの情報を相互のバッチシステムで伝播させることによりジョブを実行させる暇なバッチシステム３ａの計算機資源６ａ…６ｎを決定し、多忙なバッチシステム３ｂのジョブを暇なバッチシステム３ａに投入する。
【選択図】 図１

Description

本発明は、グリッド上のバッチシステムによってジョブの分散管理を行うグリッド計算システムに適用されるジョブ管理装置、ジョブ管理プログラム、及びジョブ管理方法に関するものである。

従来より、グリッド計算において構成されるバッチシステムをコンピュータツーコンピュータ（以下、Ｐ２Ｐという）に基づく形で連携させ、耐故障性、拡張性などを実現させる分散管理システムが知られている。この分散管理システムは、Ｐ２Ｐに基づくグリッド上のバッチシステムによって実現される。このような分散管理システムにおいて、大量のジョブを実行するバッチシステムでは、主に、センタ装置で集中的に管理されている計算機群を対象にジョブの投入が効率的に行われている。このとき、ジョブの投入端末は、ジョブが必要とするＣＰＵアーキテクチャやメモリ量などのジョブ情報を入力として与え、その投入端末が属するバッチシステムの動くサーバが管理している全資源の中から適切な資源を割り当ててジョブを実行している。このようなバッチシステムの動作により、バッチシステム内の計算機を設定する手間をかけることなく、ユーザ端末（つまり、ジョブの投入依頼端末）は容易にジョブの投入依頼を行うことができる。

また、近年、１つのコンピュータを中心にしてジョブを分散するグリッド計算という環境が出現しているため、広域に亘って分散配置された計算機資源にジョブを投入することが可能になっている。このような分散環境でバッチシステムを構築するときには従来のバッチシステムの技術を拡張する手法が用いられている（例えば、非特許文献１及び非特許文献２参照）。また、グリッドコンピューティングシステムにおいて、ワークステーションの活動状況が低いときはグリッド・ワークロードを割り当て、ワークステーションの活動状況が高いときはグリッド・ワークロードを割り当てないようにして、ジョブの分散化を図った技術も開示されている（例えば、特許文献１参照）。さらに、グリッドコンピューティングシステムにおいて、Ｐ２Ｐの通信を使用して資源利用コンピュータと資源提供コンピュータとを相互通信する技術も開示されている（例えば、特許文献２参照）。すなわち、特許文献１や特許文献２の技術によれば、グリッドコンピューティングシステムの資源割り当てを行うサーバを分散させ、計算機資源が開いているサーバを見つけたら自発的にそのサーバにジョブ情報を流してジョブの投入を依頼することができる。このようにしてサーバを連携させることにより、グリット上のバッチシステムをＰ２Ｐによって実現することができる。
特開２００４−３８９７２号公報 特開２００４−２０６２７３号公報

しかしながら、従来のバッチシステムでは、一つのサーバが全ジョブと全計算機資源を管理し、各ジョブに対して適切な計算機資源を割り当ててそれぞれのジョブを実行している。つまり、従来のバッチシステムでは、サーバの負荷を軽減させたり耐故障性を向上させるためにサーバを分散することはあっても、論理的には、バッチシステム全体の系では１つのサーバとして捉えることができるため、サーバが停止すると、バッチシステム内の全体の計算機資源が使えなくなるなどの不具合を生じる。例えば、社内の計算機資源を利用するバッチシステムでＡ地域の工場内にサーバがあるときにＡ地域で停電が発生すると、Ｂ地域やＣ地域といった他の地域の計算機資源は動いているにも関わらず、Ａ地域のサーバは他の地域のサーバに対してジョブを投入できなくなる事態が生じる。つまり、グリッド計算の分野に適用すると、ある地区が停電で計算機資源を動かせないときに、その地区でサーバが動いていた場合には他の全ての地域でジョブの実行が不可能になるなど、特定の地域での故障が全てのバッチシステムの停止に至ってしまう。

このようなことは、特にグリッド分散環境ということを考えると、センタ装置で全てのジョブを管理するのでなく、分散配置された計算機資源の利用を透過的に可能にしている状況では望ましくない。つまり、従来のバッチシステムでは、ユーザ端末から見ると多くの計算機資源にジョブを投入できるようになったという利点はあるものの、ジョブ投入の管理サーバが集中管理しているため、ユーザ端末が観測するバッチシステムとしては集中管理されたバッチシステムと何ら変わらない。さらに、ユーザ端末がジョブを実行させるためにはセンタ装置のサーバにアクセスする必要がある。つまり、ジョブをネットワーク的に近い計算機資源で実行する場合であっても、センタ装置のサーバを経由することを省くことはできない。そのため、全ての入力ファイルが一度にセンタ装置のサーバへ転送するなどの現象が発生して、無駄なネットワークトラフィックが生じるおそれがあると共に、通信の輻輳を生じさせるおそれもある。

さらには、従来のバッチシステムでは、拡張性の面で考えると扱うことができる計算機資源の個数にも問題が生じる。つまり、グリッド計算においては、使用することが可能な計算機資源の個数はセンタ装置に比べて非常に多いと考えられ、センタ装置で想定する個数より多くの計算機資源を扱える環境にする必要がある。言い換えれば、グリッド計算の分野では１つの組織が全ての計算機資源を管理しているわけではなく、使える計算機資源の個数が動的に定まるために、使用可能な計算機資源の個数をあらかじめ予見することができない。そのため、計算機資源の個数の拡張性は極めて重要である。しかし、従来のバッチシステムではこのような拡張性に十分に対応していない。

また、グリッド計算の特徴の１つである異なる組織の計算機資源を利用する場合には、計算機資源の詳細な仕様を隠したままジョブを実行させたいという要求がある。このような要求は、例えば、バッチシステムに接続されているユーザ端末にＯＳのバージョンを読み取られることにより、そのＯＳのセキュリティホールをつくような攻撃を受ける危険性をなくすためである。つまり、バッチシステムに接続されたサーバが全資源の情報を集めるようなバッチシステムの方式では、計算機資源の詳細な仕様を隠したまま所定のジョブを実行させるようなシステムを構築することはできない。

本発明は上記のような問題点に鑑みてなされたものであり、各々が独立したバッチシステム間でジョブの必要とするＣＰＵアーキテクチャやメモリ量等の情報や資源情報を共有させるように機能させることにより、理想的なグリッド分散環境を実現することができると共に、計算機資源の拡張性にも優れ、かつ個々の計算機の秘匿性を実現させることの可能なジョブ管理装置、ジョブ管理プログラム、及びジョブ管理方法を提供することを目的としている。

上述した課題を解決するため、本発明は、配下にある資源を用いてジョブを行うバッチシステムにおけるジョブ管理装置であって、自己の配下にない資源を管理する他のバッチシステムのジョブ管理装置から送信される当該他のバッチシステムにおける資源情報を受信する他システム資源情報受信部と、前記他システム資源情報受信部により取得された前記他のバッチシステムにおける資源情報に基づいて、自己のバッチシステムにおいて投入されたジョブを前記他のバッチシステムに移動して投入するジョブ移動投入部とを備えてなる。

さらに、自己の配下にある資源に関する情報を他のバッチシステムのジョブ管理装置に送信する自己システム資源情報送信部と、前記他のバッチシステムから送信されるジョブ移動投入要求に基づいて、前記他のバッチシステムにおいて投入されたジョブを自己の配下にある資源に移動して投入する他ジョブ受付投入部とを備えてなる。

ここで、前記資源情報には、資源におけるジョブに対する余剰能力に関する情報が含まれていることを特徴とする。また、前記他のバッチシステムには自己のバッチシステムにおけるジョブ管理装置から所定のホップ数で接続される範囲のバッチシステムが含まれることを特徴とする。

また、本発明は、配下にある資源を用いてジョブを行うバッチシステムにおけるジョブ管理装置のコンピュータにより実行されるジョブ管理プログラムであって、他のバッチシステムのジョブ管理装置から送信される当該他のバッチシステムにおける資源情報を受信する他システム資源情報受信ステップと、前記他システム資源情報受信ステップにより取得された前記他のバッチシステムにおける資源情報に基づいて、自己のバッチシステムにおいて投入されたジョブを前記他のバッチシステムに移動して投入するジョブ移動投入ステップとをコンピュータに実行させる。

さらに、このジョブ管理プログラムにおいて、自己の配下にある資源に関する情報を他のバッチシステムのジョブ管理装置に送信する自己システム資源情報送信ステップと、前記他のバッチシステムから送信されるジョブ移動投入要求に基づいて、前記他のバッチシステムにおいて投入されたジョブを自己の配下にある資源に移動して投入する他ジョブ受付投入ステップとをコンピュータに実行させる。
また、前記ジョブ移動投入ステップに先駆けて、自己のバッチシステムにおいて投入されたジョブを前記他のバッチシステムに移動して投入するために、前記他のバッチシステムのジョブ管理装置に資源の予約を行い、予約成立の場合に前記ジョブ移動投入ステップが行われる資源予約ステップをコンピュータに実行させる。

また、本発明は、配下にある資源を用いてジョブを行うバッチシステムにおけるジョブ管理装置であって、ジョブの必要とするCPUメモリ量といった情報（以下「ジョブ情報」と記述）を受信する他システムジョブ情報受信部と、前記他システムジョブ情報受信部により取得された前記他のバッチシステムにおけるジョブ情報に基づいて他のバッチシステムからジョブを取得を要求するジョブ移動要求送信部と、前記他のバッチシステムから送信されるジョブ移動投入要求に基づいて、前記他のバッチシステムにおいて投入されたジョブを自己の配下にある資源に移動して投入する他ジョブ受付投入部と備えている。

このジョブ管理装置において、自己に投入されたジョブのジョブ情報を他のバッチシステムのジョブ管理装置に送信する事故システムジョブ情報送信部と、前記他のバッチシステムから送信されるジョブ移動投入要求に基づいて、前記他のバッチシステムにおいて投入されたジョブを自己の配下にある資源に移動して投入する他ジョブ受付投入部とを備えている。

また、本発明は、配下にある資源を用いてジョブを行うバッチシステムにおけるジョブ管理装置のコンピュータにより実行されるジョブ管理プログラムであって、他のバッチシステムのジョブ管理装置から送信される当該他のバッチシステムにおけるジョブ情報を受信する他システムジョブ情報受信ステップと、他のバッチシステムのジョブ管理装置から送信される当該他のバッチシステムにおけるジョブ情報に基づいてジョブ取得要求を送信するジョブ取得要求送信システムと他のバッチシステムから送信されるジョブ移動投入要求に基づいて、前記他のバッチシステムにおいて投入されたジョブを自己の配下にある資源に移動して投入する他ジョブ受付投入ステップとをコンピュータに実行させる。

また、このジョブ管理プログラムにおいて、自己に投入されたジョブに関する情報を他のバッチシステムのジョブ管理装置に送信する自己システムジョブ情報送信ステップと、前記他のバッチシステムから送信されるジョブ取得要求に基づいて、自己のバッチシステムにおいて投入されたジョブを前記他のバッチシステムに移動して投入するジョブ移動投入ステップとをコンピュータに実行させる。
また、前記他ジョブ受付投入ステップにより、前記他のバッチシステムにおいて投入されたジョブを自己の配下にある資源に移動して実行する場合に、前記他のバッチシステムにおけるジョブ管理装置に、実行状態に関する情報を通知する実行状態通知ステップをコンピュータに実行させる。

また、本発明は、配下にある資源を用いてジョブを行うバッチシステムにおけるジョブ管理装置により実行されるジョブ管理方法であって、自己の配下にない資源を管理する他のバッチシステムのジョブ管理装置から送信される当該他のバッチシステムにおける資源情報を受信する他システム資源情報受信ステップと、前記他システム資源情報受信ステップにより取得された前記他のバッチシステムにおける資源情報に基づいて、自己のバッチシステムにおいて投入されたジョブを前記他のバッチシステムに移動して投入するジョブ移動投入ステップとを備える。

本発明によれば、各バッチシステムが独立して動作しているため、あるバッチシステムが動作しなくなった場合でも、他のバッチシステムの配下にある資源を有効に使用することができる。また、ジョブが必要とするＣＰＵアーキテクチャやメモリ量等の情報を他のバッチシステムに流し、受信側（つまり、情報を受け取った他のバッチシステム側）で資源情報に対応するジョブのマッチングを行っているので、各バッチシステムの負荷分散が可能になり、かつ、計算機資源の内容を開示することなくジョブを受け入れることが可能になる。

また、従来のバッチシステムが資源情報を収集する手法では、ジョブが大量に投入されているバッチシステムがジョブを処理するために負荷が高い上に、さらに、情報を集めて自己のバッチシステムでジョブを実行する計算機資源を決めなくてはならないために益々負荷が増加してしまう問題があった。しかし、本発明によるバッチシステムでは、負荷の軽いバッチシステムのジョブ実行先でジョブの割り当てを行うことができるため、負荷の重いバッチシステムが負荷に関する情報を要求されることにより、さらに負荷が重くなるというような不具合は発生しなくなる。

また、本発明によれば、計算機資源の拡張が容易になり、最初から管理する全体の計算機資源を把握しなくても、随時にバッチシステムを追加してそれをＰ２Ｐ的につなげて行けば計算機資源を任意に拡張することができる。

〈発明の概要〉
本発明は、各バッチシステムにおいて独立しているジョブ管理装置（サーバ）をＰ２Ｐにおけるピアとして分散し、それらのサーバを連携させてジョブ情報を共有化する。そして、ジョブ情報を相互のサーバで伝播させることによりジョブを実行させる計算機資源を決定する。これにより、負荷分散による負荷の軽減化、耐故障性の向上、ファイル転送量の軽減化、及び資源情報の隠蔽化を図ることができる。また、ジョブ情報の移動によるジョブ実効資源の決定機構により、系全体の負荷を軽減させることができる。

〈実施の形態〉
以下、本発明の実施の形態について図面を参照しつつ詳細に説明する。図１は、本発明の実施の形態に適用されるグリッド計算システムの構成図である。図１において、グリッド計算システム１は、複数のバッチシステム３ａ、３ｂ、…３ｎがネットワーク４に接続されてシステム連携された構成となっている。各バッチシステム３ａ、３ｂ、…３ｎは、それぞれ、配下にある計算機資源を用いてジョブを実行させるジョブ管理装置（サーバ）２ａ、２ｂ、…２ｎを備えて構成されている。また、バッチシステム３ａでは、ジョブを依頼するユーザ端末５ａ１…５ａｎとジョブを実行する計算機資源６ａ１…６ａｎとが接続され、バッチシステム３ｂでは、ジョブを依頼するユーザ端末５ｂ１…５ｂｎとジョブを実行する計算機資源６ｂ１…６ｂｎとが接続され、以下、同様にして、バッチシステム３ｎでは、ジョブを依頼するユーザ端末５ｎ１…５ｎｎとジョブを実行する計算機資源６ｎ１…６ｎｎとが接続されている。

各バッチシステム３ａ、３ｂ、…３ｎは、それらのジョブ管理装置２ａ，２ｂ，…２ｎそれぞれが自己の配下にジョブを実行する計算機資源を抱えている。そして、例えば、あるユーザ端末５ｂ１が自己の認識している１つのジョブ管理装置２ｂにジョブ実行依頼（投入）する。このとき、各バッチシステム３ａ、３ｂ、…３ｎは、相互にジョブ情報や計算機資源の資源情報をやりとりしており、ジョブ管理装置２ｂは空いている計算機資源を持っているバッチシステム（例えば、バッチシステム３ａ）にジョブを移動させてジョブを実行させる。

このとき、各々が独立したバッチシステム３ａ、３ｂ、…３ｎ（ジョブ管理装置２ａ，２ｂ，…２ｎ）の間で、ジョブが必要とするＣＰＵアーキテクチャやメモリ量などのジョブ情報や、各バッチシステム３ａ、３ｂ、…３ｎが保有する計算機資源の資源情報を共有している。そして、各バッチシステム３ａ、３ｂ、…３ｎの間におけるジョブ移動の選別を行うために、ジョブが必要とするＣＰＵアーキテクチャやメモリ量などの情報を相互に通知し合っている。

図２は、図１に示す各バッチシステム３ａ、３ｂ、…３ｎにおけるジョブ管理装置（サーバ）２が実現するソフトウェアの機能構成図である。各バッチシステム３ａ、３ｂ、…３ｎにおけるジョブ管理装置２の機能は、それぞれ、情報伝播制御機能１１とジョブ実行機能１２とによって構成されている。情報伝播制御機能１１は、送信情報の生成、ジョブ情報の受信、ジョブ情報の送信、資源情報の受信、及び資源情報の送信などを実現する。なお、資源情報とは計算機資源のＣＰＵアーキテクチャやメモリ量などの情報である。また、ジョブ情報とは、ジョブが必要とするＣＰＵアーキテクチャやメモリ量などの情報である。

ジョブ実行機能１２は、内部情報として、実行待ちジョブの集合、実行中のジョブの集合、及び資源情報の集合を保有している。また、ジョブ実行機能１２は、これらの保有情報に基づいてジョブ及び資源キューの操作、挿入、削除、取り出し、要素の参照、資源データの参照、及びジョブの移動などを実現する。すなわち、バッチシステムにおいては、情報伝播制御機能１１が、ジョブ実行機能１２の提出するメソッドであるキュー操作関数を使ってジョブ実行機能１２の内部情報を取り出し、自己の内部にある送信情報の生成メソッドを使って他のブローカ（ＧＲＭ）に送信するジョブや計算機資源の情報を生成する。

図３は、図２に示すジョブ管理装置の送受信機能部の構成を示すブロック図である。図３に示すように、ジョブ管理装置（送受信機能部）２（図１の２ａ〜２ｎ）は、他システム資源情報受信部２２、ジョブ移動投入部２３、自己システム資源情報送信部２４、他ジョブ受付投入部２５、他システムジョブ情報受信部２６、ジョブ移動要求送信部２７、他システムジョブ情報送信部２８を備えた構成となっている。

あるバッチシステム（例えば３ａ）におけるジョブ管理装置の他システム資源情報受信部２２は、自己の配下にない計算機資源（例えば、計算機資源６ｂ１…６ｂｎ）を管理する他のバッチシステム（例えば３ｂ）のジョブ管理装置２ｂから送信される当該他のバッチシステム（バッチシステム３ｂ）における資源情報（計算機資源６ｂ１…６ｂｎ）を受信する機能を有している。

あるバッチシステム（例えば、バッチシステム３ａ）におけるジョブ管理装置（例えば２ａ）のジョブ移動投入部２３は、他システム資源情報受信部２２によって取得された他のバッチシステム（例えば３ｂ）における資源情報に基づいて、自己のバッチシステム（３ａ）において投入されたジョブを他のバッチシステム（３ｂ）に移動して投入する機能を有している。

あるバッチシステム（例えば３ａ）におけるジョブ管理装置（例えば２ａ）の自己システム資源情報送信部２４は、自己の配下にある計算機資源（計算機資源６ａ１…６ａｎ）に関する情報を自己の配下にない計算機資源（例えば、計算機資源６ｂ１…６ｂｎ）を管理する他のバッチシステム（例えば３ｂ）のジョブ管理装置（例えば２ｂ）に送信する機能を有している。なお、計算機資源に関する情報には、実行中のジョブに対する資源の余剰能力、また実行中のジョブが無い場合は、その旨等、該情報によりそのバッチシステムが他のバッチシステムからジョブを移動投入することができるか否かの判断を行う情報が含まれる。

あるバッチシステム（例えば３ａ）におけるジョブ管理装置（例えば２ａ）の他ジョブ受付投入部２５は、他のバッチシステム（例えば３ｂ）から送信されるジョブの移動投入要求に基づいて、他のバッチシステム（３ｂ）において投入されたジョブを自己の配下にある計算機資源（計算機資源６ａ１…６ａｎ）に投入する機能を有している。

あるバッチシステム（例えば３ａ）におけるジョブ管理装置（例えば２ａ）の他システムジョブ情報受信部２６は、他のバッチシステム（例えば３ｂ）から送信されるジョブ情報を受信する機能を有している

あるバッチシステム（例えば３ａ）におけるジョブ管理装置（例えば２ａ）の
ジョブ移動要求送信部２７は、他のバッチシステム（例えば３ｂ）から送信されるジョブ情報に基づき、該当ジョブの自分の場所への移動要求を送信する機能を有している

あるバッチシステム例えば３ａ）におけるジョブ管理装置（例えば２ａ）の
他システムジョブ情報送信部２７は、自分に投入されたジョブ情報を他のバッチシステム（例えば３ｂ）に送信する機能を有している。

次に、図１、図２、及び図３を参照しながら、実施の形態の動作について説明する。本発明では、ジョブに計算機資源を割り当てるバッチシステム３ａ、３ｂ…３ｎが地理的に複数箇所に亘って分散して配置されている。ここで、理解を容易にするために、一例として、配下にある全ての計算機資源６ａ１…６ａｎがジョブを実行していないバッチシステム３ａを「暇なバッチシステム」と呼び、実行待ちのジョブがあるバッチシステム３ｂを「忙しいバッチシステム」と呼ぶことにする。

そして、暇なバッチシステム（バッチシステム３ａ）は、自己が暇であること示す情報（資源情報に含まれる）を他のバッチシステム（バッチシステム３ｂ…バッチシステム３ｎ）に広報する。また、他のバッチシステム（バッチシステム３ｂ…バッチシステム３ｎ）は任意のトポロジー（接続形態）でつながっているものとし、情報が伝わる範囲はポップ（ＰＯＰ）数で制限されるものとする。

今、バッチシステム３ｂにジョブが大量に投入されて忙しいバッチシステムとなり、自己の配下にある全ての計算機資源６ｂ１…６ｂｎでジョブの実行状態になったとき、暇なバッチシステム３ａにジョブ情報を送信する。ジョブ情報を受け取った暇なバッチシステム３ａはそのジョブを実行するのに適切な計算機資源が自己の配下にあった場合にジョブ情報を取得する。その後も忙しいバッチシステム３ｂは情報を送ったジョブが持って行かれて実行される限り、一定個数ずつその暇なバッチシステム３ａに対してジョブ情報を送り続ける。また、一定時間内にジョブが持っていかれない場合には、バッチシステム３ｂは、その暇なバッチシステム３ａにジョブを送信するのをやめ、他の暇なバッチシステム（例えば、バッチシステム３ｎ）から暇であるという情報が届くのを待って、前述と同じように、他の暇なバッチシステム（バッチシステム３ｎ）へジョブ情報の伝達を繰り返す。

すなわち、本実施の形態では、計算機資源の割り当てを行う独立したバッチシステムが複数個あるとき、ジョブが必要とするＣＰＵアーキテクチャやメモリ量等のＣＰＵ情報や資源情報をＰ２Ｐの形態で送受信する仕組みを構築している。なお、Ｐ２Ｐの形態とは、センタとなるサーバにＣＰＵ情報や資源情報を送ることなく、任意のバッチシステム間でＣＰＵ情報や資源情報を送受信する通信の形態である。

また、本発明では、計算機資源の割り当てを行うバッチシステムを分散化させ、それらのシステム間で計算機資源やジョブなどの情報を共有する。このとき、各システムは、独立してジョブの実行を行う独立モジュールと情報の共有を制御する共有モジュールとを備えている。情報の共有を制御する共有モジュールは情報の送受信などのライブラリを使って管理者が自身の制御ポリシーを記述する。したがって、あるシステムがダウンした場合でも、共有モジュールの機能によって、動作している他のシステムの管理下の計算機資源を使ってジョブの実行を継続することができる。

このとき、従来のバッチシステムでは、例えば、実行していない計算機資源を大量に持つバッチシステム３ａのジョブ管理装置２ａがジョブを探す場合、現在忙しいバッチシステム３ｂにも問い合わせるため、バッチシステム３ｂの処理量をさらに増大させてしまい、結果的に、バッチシステム３ｂの負荷がさらに増加してしまう。

本発明では、各バッチシステム（ジョブ管理装置）からジョブの混み状況を予め広報しているため、忙しいバッチシステムが他の忙しいバッチシステムに問い合わせを行う必要はなく、暇なバッチシステムを見出すことができ、もって、忙しいバッチシステムの負荷を増大させることはない。

また、バッチシステム３ｂからバッチシステム３ａへのジョブ情報の転送により、バッチシステム３ａは自己の資源情報を非開示のままバッチシステム３ｂからジョブを受け入れることもできる。さらに、バッチシステム３ｂは、自己が処理可能な負荷の量である限りは自己の内部でジョブを実効するためのコマンドとファイルの転送量を減らすことができる。

なお、ファイルには入力ファイルと出力ファイルがあり、入力ファイルとは、ジョブのコマンド（例えば、ａというバイナリに１“hoge”という引数を与えてジョブを実行するときには、ａ１“hoge”という文字列のコマンド）とプログラムが必要とするファイルである。また、出力ファイルとはジョブが出力するファイルである。

次に、シーケンス図を用いて、図１に示すグリッド計算システムにおける分散処理の流れを説明する。あらかじめ、シーケンス図に用いられる各種の矢印の意味について説明する。図４は、図１に示すグリッド計算システムのシーケンス図に用いられる各種の矢印の意味を示す図であり、図５は、図４に示す各種の矢印を使用した具体例を示す図である。図４に示すように、（ａ）の矢印は非同期メッセージの流れに用いられ、受信の完了を待たずに次の操作が可能な流れを意味する。（ｂ）の矢印は同期メッセージの流れに用いられ、受信の完了を待って次の操作を行う流れを意味する。（ｃ）の組合せ矢印は同期メッセージとその返信の流れを意味する。

したがって、図５に示すように、（ａ）のシーケンスは、２は１の受信完了前に送信が可能な状態を示している。（ｂ）のシーケンスは、４は３の受信完了後に初めて送信が可能な状態を示している。また、（ｃ）のシーケンスは、６は５の返信であって新たなメッセージではない状態を示している。

図６は、図１に示すグリッド計算システムにおける分散処理の流れを示す第１の形態のシーケンス図である。図６に示す第１の形態のシーケンス図は、計算機資源の資源情報を各バッチシステムのジョブ管理装置（サーバ）に渡しておいてジョブを送信する場合の流れを示している。なお、以下のシーケンス図では、各バッチシステムのジョブ管理装置をＧＲＭ（ブローカ）で表わしている。

図６において、計算機資源が資源情報をＧＲＭ２に伝達すると（Ｓ１）、その資源情報はＧＲＭ２からＧＲＭ１へ伝達される（Ｓ２）。このような環境下において、ユーザ端末がジョブを実行するためのコマンド及び入力ファイルをＧＲＭ１へ送信すると（Ｓ３）、ＧＲＭ１は、受信したコマンド及び入力ファイルに基づいて、ＧＲＭ２に対して資源予約を行い（Ｓ４）、ＧＲＭ２から予約成功通知を受け取る（Ｓ５）。これによって、ＧＲＭ１は、自己が受信したコマンド及び入力ファイルをＧＲＭ２へ送信する（Ｓ６）。

すると、ＧＲＭ２はそのコマンド及び入力ファイルを計算機資源へ送信してジョブを実行させる（Ｓ７）。そして、ＧＲＭ２は、計算機資源が実行中である旨を示す状態変化通知をＧＲＭ１へ送信する（Ｓ８）。さらに、ＧＲＭ２は、計算機資源からジョブの実行結果と出力ファイルを受け取って（Ｓ９）、これらの情報（つまり、実行結果と出力ファイル）をＧＲＭ１へ送信する（Ｓ１０）。さらに、ＧＲＭ１からジョブの依頼元であるユーザ端末に対して、計算機資源の実行結果と出力ファイルを送信する（Ｓ１１）。

図７は、図１に示すグリッド計算システムにおける分散処理の流れを示す第２の形態のシーケンス図である。図７に示す第２の形態のシーケンス図は、ジョブ情報をバッチシステムのジョブ管理装置に渡しておいてジョブを送信する場合の流れを示している。

図７において、あらかじめ、計算機資源が資源情報をＧＲＭ２に伝達しておく（Ｓ２１）。このような環境下において、ユーザ端末がジョブを実行させるためのコマンド及び入力ファイルをＧＲＭ１へ送信すると（Ｓ２２）、ＧＲＭ１は、受信したコマンド及び入力ファイルに基づくジョブ情報をＧＲＭ２へ送信する（Ｓ２３）。すると、ＧＲＭ２は、ＧＲＭ１に対してジョブの取得要求を行い（Ｓ２４）、ＧＲＭ１からユーザ端末の送信したコマンド及び入力ファイルを受け取る（Ｓ２５）。

ＧＲＭ２はそのコマンド及び入力ファイルを計算機資源へ送信してジョブを実行させる（Ｓ２６）。そして、ＧＲＭ２は、計算機資源が実行中である旨を示す状態変化通知をＧＲＭ１へ送信する（Ｓ２７）。さらに、ＧＲＭ２は、計算機資源からジョブの実行結果と出力ファイルを受け取って（Ｓ２８）、これらの情報（つまり、実行結果と出力ファイル）をＧＲＭ１へ送信する（Ｓ２９）。さらに、ＧＲＭ１からジョブの依頼元であるユーザ端末に対して、計算機資源の実行結果と出力ファイルを送信する（Ｓ３０）。

図８は、図１に示すグリッド計算システムにおける分散処理の流れを示す第３の形態のシーケンス図である。図８に示す第３の形態のシーケンス図は、ＧＲＭが３個存在する場合の分散処理の流れを示している。図８において、あらかじめ、計算機資源が資源情報をＧＲＭ２に伝達しておく（Ｓ３１）。このような環境下において、ユーザ端末がジョブを実行するためのコマンド及び入力ファイルをＧＲＭ１へ送信すると（Ｓ３２）、ＧＲＭ１は、受信したコマンド及び入力ファイルをＧＲＭ３へ送信する（Ｓ３３）。ここで、ＧＲＭ２がＧＲＭ３に対してジョブの取得要求を行うと（Ｓ３４）、ＧＲＭ３からＧＲＭ２に対してコマンド及び入力ファイルが送信される（Ｓ３５）。さらに、ＧＲＭ３からＧＲＭ１に対してジョブの位置情報が送信される（Ｓ３６）。

そして、ＧＲＭ２は受信したコマンド及び入力ファイルを計算機資源へ送信してジョブを実行させる（Ｓ３７）。さらに、ＧＲＭ２は、計算機資源が実行中である旨を示す状態変化通知をＧＲＭ１へ送信する（Ｓ３８）。そして、ＧＲＭ２は、計算機資源からジョブの実行結果と出力ファイルを受け取って（Ｓ３９）、これらの情報（つまり、実行結果と出力ファイル）をＧＲＭ１へ送信する（Ｓ４０）。さらに、ＧＲＭ１からジョブの依頼元であるユーザ端末に対して、計算機資源の実行結果と出力ファイルを送信する（Ｓ４１）。

図９は、図１に示すグリッド計算システムにおける分散処理の流れを示す第４の形態のシーケンス図である。図９に示す第４の形態のシーケンス図は、ジョブ依頼元のユーザ端末がジョブの実行中にジョブキャンセルを行う場合の分散処理の流れを示している。

図９において、計算機資源からＧＲＭ２へ資源情報が伝達されると（Ｓ６１）、ＧＲＭ２からＧＲＭ１へその資源情報が伝達される（Ｓ６２）。このような環境において、ユーザ端末がジョブを実行するためのコマンド及び入力ファイルをＧＲＭ１へ送信すると（Ｓ６３）、ＧＲＭ１は受信したコマンド及び入力ファイルをＧＲＭ２へ送信し（Ｓ６４）、さらに、このコマンド及び入力ファイルは計算機資源へ送信される（Ｓ６５）。そして、計算機資源でジョブが実行されると、ＧＲＭ２は、計算機資源が実行中である旨を示す状態変化通知をＧＲＭ１へ送信する（Ｓ６６）。

このとき、ジョブを依頼したユーザ端末がＧＲＭ１に対してジョブキャンセルを行うと（Ｓ６７）、そのジョブキャンセルはＧＲＭ１からＧＲＭ２へ送信され（Ｓ６８）、さらに、ＧＲＭ２から計算機資源へ送信される（Ｓ６９）。これによって、全てのＧＲＭ（ＧＲＭ１とＧＲＭ２）におけるジョブの実行がキャンセルされる。なお、シーケンス図には示していないが、全てのＧＲＭにおけるジョブの実行がキャンセルされた後に、計算機資源からＧＲＭ２（又は、ＧＲＭ１）に対して、これまでに実行されたジョブの実行結果及び出力ファイルを送信し、ＧＲＭ２（又は、ＧＲＭ１）からユーザ端末へこれらの情報（実行結果及び出力ファイル）を送信することもできる。

以上のように本発明の実施の形態では、計算機資源の割り当てを行う独立したバッチシステムが複数個あるとき、ジョブが必要とするＣＰＵアーキテクチャやメモリ量等のＣＰＵ情報や資源情報をＰ２Ｐの形態で各バッチシステムへ送受信するように構築されている。そして、既存のバッチシステムのジョブから計算機資源への割り当て部分に、他のバッチシステムの配下にあるジョブや資源情報が加えられるような形態になっている。これによって、他のバッチシステムの配下の計算機資源を使用することができるような環境になる。

このようにして、計算機資源の割り当てを行うジョブ管理装置（サーバ）を分散化させ、それらのジョブ管理装置の間で計算機資源やジョブなどの情報を共有化させている。したがって、あるジョブ管理装置がダウンした場合でも、動作している他のジョブ管理装置の管理下の計算機資源を使ってジョブの実行を継続することができる。

このとき、負荷を大量に持つ重負荷なジョブ管理装置が計算機資源の空いている軽負荷なジョブ管理装置を見つけたら、自発的に軽負荷なジョブ管理装置にジョブ情報を流して、軽負荷なジョブ管理装置にジョブを取得してもらうことにより、重負荷なジョブ管理装置の負荷を減らすことができる。また、重負荷なジョブ管理装置から軽負荷なジョブ管理装置へのジョブ情報の転送により、軽負荷なジョブ管理装置は自己の資源情報を非開示のまま重負荷なジョブ管理装置からジョブを受け入れることもできる。さらに、重負荷なジョブ管理装置は、自己が処理可能な負荷の量である限りは自己の内部でジョブを実行するために、ファイルの転送量を減らすことができる。

以上に詳述した本実施の形態において、図４〜図１０に示した各ステップをコンピュータに実行させるプログラムをジョブ管理プログラムとしてコンピュータにより読取り可能な記録媒体に記憶させることによって、ジョブ管理装置を構成するコンピュータに実行させることが可能となる。ここで、上記コンピュータにより読取り可能な記録媒体としては、ＣＤ−ＲＯＭやフレキシブルディスク、ＤＶＤディスク、光磁気ディスク、ＩＣカード等の可搬型記憶媒体や、コンピュータプログラムを保持するデータベース、或いは、他のコンピュータ並びにそのデータベースや、更に回線上の伝送媒体をも含むものである。

本発明によれば、計算機資源の内容を開示することなく負荷分散を行うことができると共に、計算機資源を任意に拡張することができるので、広範囲なグリッド計算システムに有効に利用することができる。

本発明に適用されるグリッド計算システムの構成図である。 図１に示す各バッチシステムにおけるジョブ管理装置のソフトウェアの機能構成図である。 図１に示すバッチシステムにおけるジョブ管理装置の送受信機能部の構成を示すブロック図である。 図１に示すグリッド計算システムのシーケンス図に用いられる各種の矢印の意味を示す図である。 図４に示す各種の矢印を使用した具体例を示す図である。 図１に示すグリッド計算システムにおける分散処理の流れを示す第１の形態のシーケンス図である。 図１に示すグリッド計算システムにおける分散処理の流れを示す第２の形態のシーケンス図である。 図１に示すグリッド計算システムにおける分散処理の流れを示す第３の形態のシーケンス図である。 図１に示すグリッド計算システムにおける分散処理の流れを示す第４の形態のシーケンス図である。

符号の説明

１ グリッド計算システム、２、２ａ、２ｂ、…２ｎ ジョブ管理装置、３ａ、３ｂ、…３ｎ バッチシステム、４ ネットワーク、５ａ１…５ａｎ、５ｂ１…５ｂｎ、…、５ｎ１…５ｎｎ ユーザ端末、６ａ１…６ａｎ、６ｂ１…６ｂｎ、…、６ｎ１…６ｎｎ 計算機資源、１１ 情報伝播制御機能、１２ ジョブ実行機能、２２ 他システム資源情報受信部、２３ ジョブ移動投入部、２４ 自己システム資源情報送信部、２５ 他ジョブ受付投入部、２６ 他システムジョブ情報受信部、２７ ジョブ移動要求送信部、２８ 自己システムジョブ情報送信部。

Claims (14)

1. 配下にある資源を用いてジョブを行うバッチシステムにおけるジョブ管理装置であって、
   自己の配下にない資源を管理する他のバッチシステムのジョブ管理装置から送信される当該他のバッチシステムにおける資源情報を受信する他システム資源情報受信部と、
   前記他システム資源情報受信部により取得された前記他のバッチシステムにおける資源情報に基づいて、自己のバッチシステムにおいて投入されたジョブを前記他のバッチシステムに移動して投入するジョブ移動投入部と、
   を備えてなるジョブ管理装置。
2. 請求項１に記載のジョブ管理装置において、
   自己の配下にある資源に関する情報を他のバッチシステムのジョブ管理装置に送信する自己システム資源情報送信部と、
   前記他のバッチシステムから送信されるジョブ移動投入要求に基づいて、前記他のバッチシステムにおいて投入されたジョブを自己の配下にある資源に移動して投入する他ジョブ受付投入部と、
   を備えてなるジョブ管理装置。
3. 請求項１又は請求項２に記載のジョブ管理装置において、
   前記資源情報には、資源におけるジョブに対する余剰能力に関する情報が含まれていることを特徴とするジョブ管理装置。
4. 請求項１乃至請求項３のいずれかに記載のジョブ管理装置において、
   前記他のバッチシステムには自己のバッチシステムにおけるジョブ管理装置から所定のホップ数で接続される範囲のバッチシステムが含まれることを特徴とするジョブ管理装置。
5. 配下にある資源を用いてジョブを行うバッチシステムにおけるジョブ管理装置のコンピュータにより実行されるジョブ管理プログラムであって、
   他のバッチシステムのジョブ管理装置から送信される当該他のバッチシステムにおける資源情報を受信する他システム資源情報受信ステップと、
   前記他システム資源情報受信ステップにより取得された前記他のバッチシステムにおける資源情報に基づいて、自己のバッチシステムにおいて投入されたジョブを前記他のバッチシステムに移動して投入するジョブ移動投入ステップと
   をコンピュータに実行させるジョブ管理プログラム。
6. 請求項５に記載のジョブ管理プログラムにおいて、
   自己の配下にある資源に関する情報を他のバッチシステムのジョブ管理装置に送信する自己システム資源情報送信ステップと、
   前記他のバッチシステムから送信されるジョブ移動投入要求に基づいて、前記他のバッチシステムにおいて投入されたジョブを自己の配下にある資源に移動して投入する他ジョブ受付投入ステップと
   をコンピュータに実行させるジョブ管理プログラム。
7. 請求項５又は請求項６に記載のジョブ管理プログラムにおいて、
   前記ジョブ移動投入ステップに先駆けて、自己のバッチシステムにおいて投入されたジョブを前記他のバッチシステムに移動して投入するために、前記他のバッチシステムのジョブ管理装置に資源の予約を行い、予約成立の場合に前記ジョブ移動投入ステップが行われる資源予約ステップをコンピュータに実行させるジョブ管理プログラム。
8. 配下にある資源を用いてジョブを行うバッチシステムにおけるジョブ管理装置であって、ジョブの必要とするCPUメモリ量といったジョブ情報を受信する他システムジョブ情報受信部と、
   前記他システムジョブ情報受信部により取得された前記他のバッチシステムにおける前記ジョブ情報に基づいて他のバッチシステムからジョブを取得を要求するジョブ移動要求送信部と、
   前記他のバッチシステムから送信されるジョブ移動投入要求に基づいて、前記他のバッチシステムにおいて投入されたジョブを自己の配下にある資源に移動して投入する他ジョブ受付投入部と
   備えているジョブ管理装置。
9. 請求項８のジョブ管理装置において、自己に投入されたジョブのジョブ情報を他のバッチシステムのジョブ管理装置に送信する事故システムジョブ情報送信部と、
   前記他のバッチシステムから送信されるジョブ移動投入要求に基づいて、前記他のバッチシステムにおいて投入されたジョブを自己の配下にある資源に移動して投入する他ジョブ受付投入部と
   を備えているジョブ管理装置。
10. 配下にある資源を用いてジョブを行うバッチシステムにおけるジョブ管理装置のコンピュータにより実行されるジョブ管理プログラムであって、
    他のバッチシステムのジョブ管理装置から送信される当該他のバッチシステムにおけるジョブ情報を受信する他システムジョブ情報受信ステップと、
    他のバッチシステムのジョブ管理装置から送信される当該他のバッチシステムにおけるジョブ情報に基づいてジョブ取得要求を送信するジョブ取得要求送信システムと
    他のバッチシステムから送信されるジョブ移動投入要求に基づいて、前記他のバッチシステムにおいて投入されたジョブを自己の配下にある資源に移動して投入する他ジョブ受付投入ステップと
    をコンピュータに実行させるジョブ管理プログラム。
11. 請求項１０に記載のジョブ管理プログラムにおいて、
    自己に投入されたジョブに関する情報を他のバッチシステムのジョブ管理装置に送信する自己システムジョブ情報送信ステップと、
    前記他のバッチシステムから送信されるジョブ取得要求に基づいて、自己のバッチシステムにおいて投入されたジョブを前記他のバッチシステムに移動して投入するジョブ移動投入ステップと
    をコンピュータに実行させるジョブ管理プログラム。
12. 請求項６又は請求項１０に記載のジョブ管理プログラムにおいて、
    前記他ジョブ受付投入ステップにより、前記他のバッチシステムにおいて投入されたジョブを自己の配下にある資源に移動して実行する場合に、前記他のバッチシステムにおけるジョブ管理装置に、実行状態に関する情報を通知する実行状態通知ステップをコンピュータに実行させるジョブ管理プログラム。
13. 請求項５乃至請求項１２のいずれかに記載のジョブ管理プログラムにおいて、
    前記資源情報には、資源におけるジョブに対する余剰能力に関する情報が含まれていることを特徴とするジョブ管理プログラム。
14. 配下にある資源を用いてジョブを行うバッチシステムにおけるジョブ管理装置により実行されるジョブ管理方法であって、
    自己の配下にない資源を管理する他のバッチシステムのジョブ管理装置から送信される当該他のバッチシステムにおける資源情報を受信する他システム資源情報受信ステップと、
    前記他システム資源情報受信ステップにより取得された前記他のバッチシステムにおける資源情報に基づいて、自己のバッチシステムにおいて投入されたジョブを前記他のバッチシステムに移動して投入するジョブ移動投入ステップと
    を備えるジョブ管理方法。

Images