WO2006100752A1

WO2006100752A1 - 分散処理管理装置、分散処理管理方法、分散処理管理プログラム

Info

Publication number: WO2006100752A1
Application number: PCT/JP2005/005129
Authority: WO
Inventors: Ichiro Goto; Tomonori Yamashita; Kazuhiro Matsuzaki; Kuniyasu Hase; Hiroshi Noguchi
Original assignee: Fujitsu Limited
Priority date: 2005-03-22
Filing date: 2005-03-22
Publication date: 2006-09-28
Also published as: EP1862904A4; JPWO2006100752A1; EP1862904A1; US20080016508A1

Abstract

　分散処理管理装置において、サーバ３は、一定期間ごとに各ノードのＣＰＵ使用率などのリソース状況を管理するために、ノードテーブル５、ジョブ管理テーブル６、およびジョブクラステーブル７を有する。ジョブの投入後にＣＰＵ等の稼働率が高くなり、投入ジョブの実行速度が落ちた場合は、各テーブルを参照して、現用のノード２ａから他のノード２ｂへジョブの再投入を行う。これによって、グリッド計算機環境において、全体のＴＡＴを改善することができると共に計算機資源の有効な利用が可能となる。

Description

明細書

分散処理管理装置、分散処理管理方法、分散処理管理プログラム技術分野

[0001] 本発明は、分散コンピューティングシステムにおいてジョブの投入制御およびジョブの実行制御を行う分散処理管理装置、分散処理管理方法、および分散処理管理プログラムに関するものである。

背景技術

[0002] 従来より、複数のノードとそれらを管理するサーバを持った分散処理コンビユーティングシステムでは、分散処理用プログラムをネットワークで接続されたノードに投入して各ノードで計算させた結果を回収している。分散処理用プログラムを投入する方法としては、空きノードを順番に選択して依頼する方法が用いられている力近年では、家庭用/事務所用 PC (Personal Computer :パソコン）を利用するケースもあり、その余剰なリソース能力を利用する場合は、 PCで実行する家庭用'事務処理プロダラムに影響を与えないようにするために、分散処理用プログラムを最低優先度で実行させるようにしてレ、る。あるいは、リソースが他で利用されていないときのみ分散処理用プログラムを実行するように制御されている。そのため、分散処理用プログラムの投入時には、リソースの稼働率等のリソース利用率が低い PCを選択するなどして、分散処理用プログラムの実行の効率化を図っている。

[0003] しかし、リソースの稼働率などの指標は一定期間ごとに求められるため、分散処理用プログラムの投入時の稼働率指標が古い場合もあり、必ずしも効果的には分散処理が運用されない。また、分散処理用プログラムの投入時の負荷が低くても投入された後に負荷が上昇すると分散処理用プログラムの実行に対応することができない。特に、家庭用 Z事務所用 PCの場合はリソース稼動率の変動が大きいため、投入された分散処理用プログラムの実行が負荷を重くすることもしばしばであり、結果的に、処理時間が長くなつてしまうケースもある。

[0004] そこで、このような不具合に対応するために、分散処理用プログラムの実行ノード側で負荷が上昇すると別のノードに分散処理用プログラムを再投入するようにサーバに通知するような仕組みを備えた分散処理コンピューティングシステムが知られている。図 20は、従来の分散処理コンピューティングシステムにおけるサーバ側と実行ノード側の処理の流れを示すフローチャートである。図 20に示すように、従来の分散処理コンピューティングシステムにおける分散処理用プログラムの再投入では、サーバ側は、一定期間ごとに CPUリソース状況の収集（S211)とノードごとのリソース状況の管理 (S212)とを行ってレヽる。

[0005] また、サーバ側のジョブ管理とノード側におけるジョブ実行の処理の流れでは、ジョブ管理を行うサーバ側は、ジョブ実行依頼および再投入依頼を行うと（S221)、ノードのリソース状況の調查を行い（S222)、稼働率の低いノードを選択して（S223)、そのノードに対してジョブを投入する（S224)。一方、ジョブを実行するノード側は、サーバ側から投入されたジョブを実行し（S225)、 CPUのリソースの閾値を超えていないか否かを判断して（S226)、 CPUのリソースの閾値を超えていなければ（S226, N o)、そのままジョブを実行するが（S225)、もし CPUのリソースの閾値を超えていれば（S226, Yes)、他のノードへの切り替えをサーバに依頼して（S227)、先にジョブを投入したノードに対してはジョブの依頼をキャンセルする（S228)。

[0006] ところが、通常はノードの負荷は動的に変化するため、ある時点で CPUのリソースの閾値を超えていてもノードを切り替えることが必ずしも効率的な結果となるわけでもなレ、。図 21は、従来の分散処理コンピューティングシステムにおけるノードの切り替え実行状況の一例を示す概念図である。図 21において、時刻 tOでノード Aにジョブが投入されたとき、時刻 tlでノード Aの負荷が上昇するとノード Bにジョブが再投入される。ノード Aの負荷が上昇しなければ時刻 t2でノード Aによるジョブの実行が終了される（S231)。また、負荷の上昇が瞬間的であってノード Bへの再投入がなければ時刻 t3でノード Aによるジョブの実行が終了される（S232)。一方、時刻 tlでノード Aの負荷が上昇してノード Bにジョブが再投入された場合は、ノード Bによる再投入ジョブは時刻 t4で終了する。また、ノード Aによる負荷上昇が長期間に亘りノード Bへの再投入がなければ、ノード Aによるジョブの終了は時刻 t5にまで延長される（S233)。つまり、ノード Aからノード Bへのジョブの切り替えによってジョブの処理が大幅に効率化されるのはステップ S233の場合のみである。 [0007] なお、本発明の関連ある従来技術としては、例えば、下記に示す特許文献 1などが知られている。この技術は、ユーザ端末からの要求に応じたアプリケーションの実行を複数のノードによって効率的に行うものである。

特許文献 1 :特開 2004— 287889号公報（段落番号 0044— 0075、および図 5 図 7参照）

発明の開示

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

[0008] し力しながら、複数の情報処理をサーバで受け付け、複数のノードへ処理を投入する分散計算機環境では、各処理が効率よく実行されるように、サーバが、処理を実行するノードの能力や計算負荷状況に応じたスケジューリング管理を行っている。このとき、実行処理ノードの能力を 100%使用できる環境や、一定の処理能力が保証される場合などにおいては、サーバの管理は比較的容易である。また、各実行ノードの処理資源 (例えば、 CPU能力やメモリ容量）に応じた処理を受け持たせることで、システム全体の能力を無駄なく利用して、各情報処理の投入から完了までの時間（以下、ターンアラウンドタイム： TATとレ、う）を最小化することができる。

[0009] ところ力ユーザが事務用 PCなどに利用しているノードの空き時間を利用したグリツド計算機環境の場合には、参加ノードの増減や計算能力の多様性はもとより、ユーザの使用状態による処理能力の増減が激しぐ計算リソースが一定であるようなスケジュ一リングでは TATを小さく保つことができない。このために、あるノードへ投入されたジョブの処理力ノード側ユーザのアプリケーション使用開始に伴って遅延した場合は、別のノードへジョブの処理を再度投入して実行する管理方法も行われている。このような管理方法の場合には、ジョブの再処理の際に、今までのジョブの処理の途中結果を保存して別ノード上でジョブ実行中断点からジョブの処理を行う場合と、ジョブの処理を最初から実行する場合との 2通りの処理方法がある。

[0010] し力し、これらの処理方法では、先にジョブの処理を依頼したノード側の方でユーザの計算負荷が減少して、後に追加したノードよりも先に処理が終えられる可能性があり、二重（または三重以上）にジョブの再投入を実行したことが TATの改善にかならずしも役立つとは言えなレ、。また、多重にジョブの処理をした分だけ、ジョブの処理を最初から実行する場合ではそれまでの計算処理は無駄となる。また、システム全体としての計算能力を減じてしまう欠点もある。

[0011] さらに、 Aノードのジョブ処理の中断点力ら Bノードでジョブの再実行を行う方法では、ジョブの中断一再実行を繰り返す処理を常に行うため、ジョブを中断しなかった場合でも計算負荷が大きくなるなどの不具合が生じる。ジョブの実行中断点からジョブの処理を行う場合と、ジョブの処理を最初から実行する場合のレ、ずれの処理方法の場合も、依頼処理数に十分な数のノードが登録されていない状況においては、むやみに二重（多重）にジョブの処理を行うことは、結果的にシステム全体の処理量が増え、サーバにそれまでに依頼されていた処理の完了時間がその分だけ遅延することになる。その結果、分散コンピューティングシステム全体としての TATが悪化してしまう。したがって、グリッド計算機環境のように、処理ノードの負荷変動が大きい場合の分散処理においても、 TATを最小化しつつ、さらに、全体の計算資源を有効に活用することができるサーバでの処理管理方式が求められている。

[0012] 本発明は上述した問題点を解決するためになされたものであり、 TATを最小化して全体の計算資源を有効に活用することができる分散処理管理装置、分散処理管理方法、分散処理管理プログラムを提供することを目的とする。

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

[0013] 上述した課題を解決するため、本発明の分散処理管理装置は、複数のノードに接続されること力 Sでき、各ノードにジョブを投入することができると共にそのジョブの実行管理を行うことができる分散処理管理装置であって、第 1ジョブを投入した第 1ノードの第 1リソース関連情報を取得する第 1リソース関連情報取得部と、第 1ジョブを投入していない第 2ノードの第 2リソース関連情報を取得する第 2リソース関連情報取得部と、第 1リソース関連情報取得部により取得された第 1リソース関連情報と、第 2リソース関連情報取得部により取得された第 2リソース関連情報とに基づいて、第 1ノードに投入した第 1ジョブを第 2ノードに投入するか否かについての判断を行うジョブ再投入判断部とを備えている。

[0014] ここで、ジョブ再投入判断部は、第 1ジョブの投入を肯定する判断において、第 1リソース関連情報に基づいて、第 1ノードの第 1ジョブの実行に対する CPU使用率が所定の閾値を下回る場合を判断することを特徴とする。

[0015] また、ジョブ再投入判断部は、第 1ジョブの投入を肯定する判断において、第 1リソース関連情報に基づいて、第 1ノードの第 1ジョブの進涉率が再投入限界値を越えてレ、ない場合を判断することを特徴とする。

[0016] また、ジョブ再投入判断部は、第 1ジョブの投入の判断において、第 2リソース関連情報に基づいて、第 1ジョブの実行に要求される所定の性能を有するノードであって、投入された第 2ジョブを実行していない空きノードである第 2ノードの有無を判断することを特徴とする。

[0017] また、ジョブ再投入判断部は、第 1ジョブの投入の判断において、第 2リソース関連情報に基づいて、第 2ノードで実行されている第 2ジョブをキャンセルして第 1ジョブを投入するための所定の条件を判断することを特徴とする。

[0018] また、所定の条件についての判断は、第 2リソース関連情報に基づいて、第 1ジョブの実行に要求される所定の性能を有するノードであって、投入された第 2ジョブを実行していない空きノードである第 2ノードがないと判断した場合に行われることを特徴とする。

[0019] また、所定の条件として、第 2ジョブに与えられた優先度が第 1ジョブに与えられた優先度より低い場合、第 2ジョブの第 2ノードにおける進涉率が所定のキャンセル限界値よりも低い場合、第 2ノードが第 1ジョブの実行に要求される所定の性能を満たす場合のうち、少なくともいずれか一つを条件とすることを特徴とする。

[0020] また、本発明の分散処理管理方法は、複数のノードにおける各ノードにジョブを投入するとともにそのジョブの実行管理を行う分散処理管理方法であって、第 1ジョブを投入した第 1ノードの第 1リソース関連情報を取得する第 1リソース関連情報取得ステップと、第 1ジョブを投入していない第 2ノードの第 2リソース関連情報を取得する第 2 リソース関連情報取得ステップと、第 1リソース関連情報取得ステップにより取得された第 1リソース関連情報と、第 2リソース関連情報取得ステップにより取得された第 2リソース関連情報とに基づいて、第 1ノードに投入した第 1ジョブを第 2ノードに投入するか否かにっレ、ての判断を行うジョブ再投入判断ステップとを備えてレ、る。

[0021] ここで、前記ジョブ再投入判断ステップは、第 1ジョブの投入を肯定する判断において、第 1リソース関連情報に基づいて、第 1ノードの第 1ジョブの実行に対する CPU使用率が所定の閾値を下回る場合を判断することを特徴とする。

[0022] また、前記ジョブ再投入判断ステップは、第 1ジョブの投入を肯定する判断において、第 1リソース関連情報に基づいて、第 1ノードの第 1ジョブの進渉率が再投入限界値を越えてレ、なレ、場合を判断することを特徴とする。

[0023] また、前記ジョブ再投入判断ステップは、第 1ジョブの投入の判断において、第 2リソース関連情報に基づいて、第 1ジョブの実行に要求される所定の性能を有するノードであって、投入された第 2ジョブを実行していない空きノードである第 2ノードの有無を判断することを特徴とする。

[0024] また、前記ジョブ再投入判断ステップは、第 1ジョブの投入の判断において、第 2リソース関連情報に基づレ、て、第 2ノードで実行されてレ、る第 2ジョブをキャンセルして第 1ジョブを投入するための所定の条件を判断することを特徴とする。

[0025] また、所定の条件として、第 2ジョブに与えられた優先度が第 1ジョブに与えられた優先度より低い場合、第 2ジョブの第 2ノードにおける進涉率が所定のキャンセル限界値よりも低い場合、第 2ノードが第 1ジョブの実行に要求される所定の性能を満たす場合のうち、少なくともいずれか一つに該当することを条件とすることを特徴とする

[0026] また、本発明は、複数のノードにおける各ノードにジョブを投入するとともにそのジョブの実行管理を行うことをコンピュータに実行させる分散処理管理プログラムであつて、第 1ジョブを投入した第 1ノードの第 1リソース関連情報を取得する第 1リソース関連情報取得ステップと、第 1ジョブを投入していない第 2ノードの第 2リソース関連情報を取得する第 2リソース関連情報取得ステップと、第 1リソース関連情報取得ステップにより取得された第 1リソース関連情報と、第 2リソース関連情報取得ステップにより取得された第 2リソース関連情報とに基づいて、第 1ノードに投入した第 1ジョブを第 2ノードに投入するか否かについての判断を行うジョブ再投入判断ステップとをコンビュータに実行させる。

図面の簡単な説明

[0027] [図 1]本発明の実施の形態における分散処理管理装置 (サーバ）がノードに対して行うリソースの収集の流れを示すフローチャートである。

園 2]本発明の実施の形態における分散処理管理装置が行うジョブ投入の流れを示すフローチャートである。

園 3]本発明の実施の形態におけるジョブの再投入判断の流れを示すシーケンスである。

[図 4]本発明の実施の形態におけるジョブ完了によるジョブキャンセルの処理の流れを示すフローチャートとシーケンスである。

園 5]本発明の実施の形態における分散処理管理システムの全体構成を示す構成図である。

園 6]本発明の実施の形態における分散処理管理装置 (サーバ）が備えるノードテーブルの項目の一例を示す図である。

園 7]図 6に示す能力値および閾値のテーブルを示す図である。

園 8]本発明の実施の形態における分散処理管理装置に適用されるノードテーブルの一例を示す図である。

園 9]本発明の実施の形態における分散処理管理装置 (サーノが備えるジョブ管理テーブルの項目の一例を示す図である。

園 10]本発明の実施の形態における分散処理管理装置 (サーノに適用されるジョブ管理テーブルの一例を示す図である。

園 11]本発明の実施の形態における分散処理管理装置 (サーバ）が備えるジョブクラステーブルの項目の一例を示す図である。

園 12]本発明の実施の形態における分散処理管理装置に適用されるジョブクラステ一ブルの一例を示す図である。

園 13]本発明の実施の形態におけるジョブ投入の流れを示すフローチャートである。園 14]本発明の実施の形態における分散処理管理装置 (サーノにおけるノード情報の取得の流れ其の 1を示すフローチャートである。

園 15]本発明の実施の形態における分散処理管理装置 (サーノにおけるノード情報の取得の流れ其の 2を示すフローチャートである。

園 16]本発明の実施の形態における分散処理管理装置 (サーバ）が行うジョブの再投入判断の流れを示すフローチャートである。

[図 17]本発明の実施の形態における分散処理管理装置 (サーノが行う多重実行処理の流れを示すフローチャートである。

[図 18]本発明の実施の形態においてノード側からのジョブキャンセル処理の流れを示すフローチャートである。

[図 19]本発明の実施の形態における分散処理管理装置 (サーバ）側からの終了およびジョブキャンセル処理の流れを示すフローチャートである。

[図 20]従来の分散処理コンピューティングシステムにおけるサーバ側と実行ノード側の処理の流れを示すフローチャートである。

[図 21]従来の分散処理コンピューティングシステムにおけるノードの切り替え実行状況の一例を示す概念図である。

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

[0028] 以下、本発明の実施の形態について図面を参照しつつ詳細に説明する。

[0029] 《発明の概要》

本発明の分散処理管理装置は、ジョブの実行ノードに投入ジョブの監視機能を設ける。そして、監視機能による投入ジョブの監視においては、実行ノードのリソース使用率 (つまり、投入ジョブが使用するリソースや処理実行ノード全体でのリソースの使用率)を規定された時間ごとにサーバ側へ通知する。また、サーバは、通知された投入ジョブのリソースが設定閾値を下回った場合は、別の空きノードに対して再度ジョブを投入し (このようなジョブの投入をジョブ再投入という）、先に終了したジョブ結果を採用して、これまで実行中のジョブをキャンセルする機能を設ける。

[0030] また、上記のジョブ再投入に関しては、以下に示すパラメータからなる実行ポリシーをジョブクラスほたは、優先度)に対して設定する。すなわち、（1)ジョブ再投入回数（投入多重度)の限界値、（2)ジョブ終了予測に基づく判定有無、（3)後発処理が追いつくまでの限界値、の 3項目の実行ポリシーをジョブクラスほたは、優先度)に対して設定する。さらに、本発明の分散処理管理装置は、アプリケーションから OSなどのソフトウェアを利用するための API (Application Programming Interface)を提供し、ジョブ側からの進涉状況を設定できるようにすることにより、ジョブの終了予測ができるようにする。

[0031] 図 1は、本発明の分散処理管理装置において、サーバがノードに対して行うリソースの収集の流れを示すフローチャートである。図 1に示すように、各ノードは、ジョブの実行中であれば、あらかじめ規定された時間を待って（S1)、ジョブが実行中であるか否かを判断し（S2)、ジョブが実行中であれば（S2、 Yes)、ジョブを割り当てた CP Uの使用率平均値をサーバに通知し（S3)、ジョブが実行中でなければ（S2、 No)、ジョブの割り当てが可能な CPU (ローカル CPU)の使用率平均値をサーバに通知する（S4)。このようにして、サーバは各 CPUのリソース状況を収集する（S5)。

[0032] すなわち、本発明の分散処理管理装置においては、各ノードは、ジョブの実行中であればあらかじめ規定された時間毎に処理ジョブに割り当てられた CPUの使用率をサーバに対して通知し、ジョブの未実行状態であればローカル CPUの使用率をサーバに対して通知する。これによつて、サーバは通知された CPUの使用率状況を収集する。

[0033] 図 2は、本発明の分散処理管理装置において、サーバが行うジョブ投入の流れを示すフローチャートである。図 2に示すように、処理実行中のノードがあらかじめ規定された時間を待って（S11)、ジョブの割り当てが可能な CPUの使用率平均値をサーバに通知すると（S12)、サーバは CPUのリソース状況を収集して（S13)、ポリシーの読み込みを行う（S14)。

[0034] このとき、サーバが読み込むポリシーは、ノード情報（つまり、ノード名、 CPUアイドル平均値、性能、再投入閾値）、ジョブクラス情報 (つまり、クラス名、最大多重値、優先順位）、およびジョブ管理情報 (つまり、ジョブ名、投入先計算機名、進涉度、ジョブクラス）などである。

[0035] 次に、サーバは、収集した CPUリソース状況でジョブの再実行が可能か否かを判断し（S15)、ジョブの再実行が不可能であれば（S15、 No)、ステップ S13に戻って前述の処理を繰り返すが、収集した CPUリソース状況でジョブの再実行が可能であれば（S15、 Yes)、ジョブを投入するマシン（PC)を決定し（S16)、そのマシン（PC) に対してジョブを再投入する（SI 7)。このような操作によって CPUリソース状況に応じて別のノードへジョブを再投入することができる（S 18)。 [0036] つまり、サーバは、ノードにジョブを投入した後、実行ノードから CPU情報とジョブ実行状況を収集すると共に、実行ノードごとの CPU割当閾値と、ジョブごとの再投入閾値（限界値）と、ジョブ投入の最大多重値とを設定したポリシーを読み込む。

[0037] そして、一定時間ごとに収集する CPUのジョブ実行状況が閾値以下であって、かつジョブ再投入の閾値（限界値）以下であり、さらに最大多重値以下であるならば、次のルールにしたがって他ノードにジョブを再投入する。

[0038] (1)空きノードがある場合は、ジョブの未実行ノードにジョブを投入する。

(2)空きノードがない場合は、サーバが管理するノード全てでジョブが実行中の場合は、ジョブポリシーで規定されたジョブ再投入閾値（限界値）以下の既実行中のジョブの中で、最も実行状況が低い既実行中のジョブをキャンセルし、該当するマシンに再投入すべきジョブを投入する。また、キャンセルされたジョブはサーバによるジョブキユーの先頭に戻される。

[0039] もし、実行中のノードからの報告により、ジョブ進涉状況がジョブ再投入閾値（限界値）を超えている場合は、閾値以下であり、かつ最大多重度以下であってもサーバはそのノードにジョブを再投入しない。図 3は、本発明の分散処理管理装置において、ジョブの再投入判断の流れを示すシーケンスである。図 3において、サーバが実行計算機 Aに対してジョブの実行を行うと（S21)、実行計算機 Aからサーバに対して一定時間ごとにジョブの実行状況が通知される（S22)。このようにして、実行計算機 Aはジョブの進涉度状況をサーバに報告し、サーバはジョブの進涉度状況とポリシーに定義された値とを比較する（S23)。このとき、ジョブの進涉度状況が指定された値以上の進涉度であるならば、サーバは別の実行計算機に対してジョブの投入は行わない

[0040] 図 4は、本発明の分散処理管理装置において、ジョブ完了によるジョブキャンセルの処理の流れを示すフローチャート（図 4 (A) )とシーケンス（図 4 (B) )である。図 4 (A )に示すジョブ完了によるキャンセルフローでは、サーバがジョブ結果を収集すると（S 31)、他の計算機のジョブをキャンセルする（S32)。つまり、図 4 (B)のシーケンスに示すように、サーバが実行計算機 Aに対してジョブ実行を行うと（S33)、実行計算機 Aからサーバに対して定期的にジョブの進渉度状況が通知される（S34)。さらに、サーバが実行計算機 Bに対してジョブ実行を行うと（S35)、実行計算機 Bからサーバに対して定期的にジョブの進涉度状況が通知される（S36)。そして、実行計算機 Bのジヨブが終了すると実行計算機 Aのジョブはキャンセルされる（S37)。このようにして実行計算機 Aと実行計算機 Bに多重投入されたジョブのいずれかが終了した場合は、

[0041] 《実施の形態》

以下、本発明における分散処理管理装置の具体的な実施の形態について説明する。図 5は、本発明の実施の形態における分散処理管理装置システムの全体構成を示す構成図である。図 5に示すように、実施の形態の分散処理管理監視システムは、複数のジョブ投入端末 la, lbと、複数のノード 2a， 2bと、分散処理管理装置をなすサーバ 3とがネットワーク 4を介して接続されてレ、る。

[0042] 複数のジョブ投入端末 la， lbは、それぞれ、ジョブ依頼'結果取得機能 11 a， l ib を備えている。複数のノード 2a, 2bは、それぞれ、ジョブ実行機能 12a, 12bとノード情報通知機能 13a, 13bを備えている。サーバ 3は、ジョブ受付機能 3a、第 1ノード情報取得機能 (第 1リソース関連情報取得部） 3bl、第 2ノード情報取得機能 (第 2リソース関連情報取得部） 3b2、ジョブ割り当て機能 3c、ジョブ実行管理機能 3d、ジョブ多重実行管理機能 3e、およびジョブ再投入判断機能 (ジョブ再投入判断部） 3fを備えている。また、サーバ 3にはノードテーブル 5とジョブ管理テーブル 6とジョブクラステ一ブル 7が接続されている。

[0043] ジョブ投入端末 la, lbは、システム利用者がジョブを投入するための PCなどの入出力端末であって多数個存在する。これらのジョブ投入端末 la, lbは、サーバ 3に対してジョブの実行を依頼し、その出力結果を取得する機能を有する。

[0044] ノード 2a, 2bは、ジョブを実行するための計算機であって多数個存在し、それぞれ、ジョブ実行機能 12a, 12bとノード情報通知機能 13a, 13bの 2つの機能を備えている。ジョブ実行機能 12a， 12bは、サーバ 3から入力ファイルと実行プログラムを受け取って、それを対応するノード 2a， 2bで実行し、その出力結果をサーバ 3に返す機能を備えている。また、ジョブ実行機能 12a， 12bには、ジョブをノード 2a， 2bまたはサーバ 3からの命令によってキャンセルする機能も含まれる。なお、ジョブのキャンセノレ機能の詳細な説明は後述する。また、ノード情報通知機能 13a, 13bは、サーバ 3 に対してノード 2a, 2bの各種情報（つまり、ノード名、マシンス仕様、 CPU使用時間、ジョブ実行時間など）を通知する機能を備えている。なお、各種情報の通知機能の詳細な説明は後述する。

[0045] サーバ 3は分散処理管理装置全体を管理するための計算機であり、 3つのテープルと 6つの機能を備えている。ジョブ受付機能 3aは、ジョブ投入端末 la, lbからジョブ実行依頼を受付けてジョブキューに格納する機能である。第 1ノード情報取得機能 (第 1リソース関連情報取得部） 3blは、ノード 2aから通知されたノード情報を取得し、ノードテーブル 5を作成 ·更新する機能を備えている。第 2ノード情報取得機能 (第 2リソース関連情報取得部） 3b2は、ノード 2bから通知されたノード情報を取得し、ノードテーブル 5を作成 ·更新する機能を備えてレ、る。

[0046] ジョブ割り当て機能 3cは、ジョブキューからジョブを取り出し、そのジョブ条件 (例えば、 OS種別やノード性能など)に合致し、かつジョブが実行されていないノード 2a, 2 bをノードテーブル 5から選択し、ジョブをノード 2a, 2bに割り当る機能を備えている。

[0047] ジョブ実行管理機能 3dは、割り当てられたジョブをノード 2a, 2bで実行するための管理機能であり、ジョブ管理テーブル 6を作成および更新し、ジョブ実行処理 (つまり、ノード 2a, 2bに対して入力ファイルと実行ファイルを送り、そのジョブ実行を命令して、ジョブ完了後に出力結果を受け取る処理)を行う機能を備えている。なお、ジョブキャンセル時の処理もジョブ実行管理機能 3dに含まれる。ジョブ多重実行管理機能 3eは、ジョブ管理テーブル 6を参照し、ジョブを再投入した方がジョブ実行時間を短縮できるときにジョブの多重実行を行うための管理機能である。ジョブ再投入判断機能 3fは、リソース情報に基づいて、例えばノード 2aに投入したジョブをノード 2bに投入するか否かを判断する機能を備えている。なお、それぞれの機能の詳細については後述する。

[0048] 次に、サーバ 3が備えるノードテーブル 5、ジョブ管理テーブル 6、およびジョブクラステーブル 7のテーブル仕様についてそれぞれ詳細に説明する。

[0049] 〈ノードテーブル仕様〉

図 6は、サーバ 3が備えるノードテーブルの項目の一例を示す図である。図 6に示すノードテーブルの項目に基づいて図 5に示すノード 2a, 2bの管理が行われる。また、図 7は図 6に示す能力値および閾値のテーブルを示す図である。

[0050] 図 6のノードテーブルの項目において、「ノード名」の項目には、いわゆるノードの名称が記録される。「CPU平均使用率」の項目には、ジョブに割り当てられた CPUの使用率の平均値が記録される。「ローカル CPU使用率」の項目には、ノードのローカル CPU使用率 (100— IDLE)が記録される。「能力値」の項目には、 CPひ性能等のマシン仕様が相対的に数値化されて記録される。すなわち、「能力値」は図 7に示すような性能に比例した値が設定され、「閾値」には「能力値」を反映した値が設定される。「状況」の項目には、ジョブの実行待ち、およびジョブの実行中などのマシン状況が記録される。図 8は、本発明の分散処理管理装置に適用されるノードテーブルの一例を示す図である。この例では、ノード名が Nl , N2, N3の 3つのノードについてのノードテーブルが示されている。

[0051] 〈ジョブ管理テーブル仕様〉

図 9は、サーバ 3が備えるジョブ管理テーブルの項目の一例を示す図である。つまり、ジョブ管理テーブルはノードに投入するジョブの管理を行う。したがって、ジョブ管理テーブルにはジョブクラスに定義された多重度に合わせたテーブルが予め用意されていて、ジョブが多重実行される度にジョブ管理テーブルにジョブ情報が登録される。言い換えれば、多重度分のジョブ管理テーブルが確保されている。

[0052] 図 9に示すジョブ管理テーブルの項目において、ジョブ名の項目にはジョブの名称が記録され、実行ノード名の項目には実行ノードの名称が記録され、クラス名の項目にはジョブクラス名が記録される。さらに、実行時間の項目には、対応するジョブの実行時間が記録され、進渉率の項目には対応するジョブの進渉率が記録される。図 10 は、本発明の分散処理管理装置に適用されるジョブ管理テーブルの一例を示す図である。この例では、ノード名力および J2の 2つのノードについてのジョブ管理テーブルが示されている。

[0053] 〈ジョブクラステーブル仕様〉

図 11は、サーバ 3が備えるジョブクラステーブルの項目の一例を示す図である。つまり、ジョブクラステーブルには投入するジョブのポリシーが登録される。図 11に示すジョブクラステーブルの項目において、クラス名の項目にはジョブのクラス名が記録され、優先順位の項目にはジョブの優先度が記録され、多重度の項目にはジョブの最大多重度が記録される。また、再投入限界値の項目には、ジョブの再投入における実行時間の閾値が記録される。したがって、この閾値を超えた場合にはジョブの再投入は行われないようにする。さらに、キャンセル限界値の項目にはジョブの切り替えの際の閾値が記録される。したがって、この閾値を超えた場合は優先度によるジョブの切り替えは行われないようにする。図 12は、本発明の分散処理管理装置に適用されるジョブクラステーブルの一例を示す図である。この例では、ジョブのクラス名が Aおよび Bの 2つのジョブクラス名についてのジョブクラステーブルが示されている。

[0054] 次に、ノードへのジョブ投入の流れについて説明する。図 13は、本発明の分散処理管理装置におけるジョブ投入の流れを示すフローチャートである。図 13において、まずジョブが再投入されたか否かが判断され (S41)、ジョブが再投入されていなければ（S41、 No)、図 10に示すようなジョブ管理テーブルにデータを作成し（S42)、初期化処理を行った後に（S43)、所望のノードに投入したジョブの実行を行う（S44)。一方、ステップ S41でジョブが再投入されていれば（S41、 Yes) ,図 10に示すジョブ管理テーブルにおける該当データの更新を行い（S45)、所望のノードに投入したジヨブの実行を行う（S44)。このようにして、ジョブの投入を完了する。

[0055] すなわち、ジョブの投入に当たっては、図 10に示すジョブ管理テーブルにジョブデータを登録する。また、ジョブの再投入を行う場合はジョブ管理テーブルに対して先に作られているテーブルの更新を行う。

[0056] 次に、ノード情報の取得について説明する。

〈ノード情報の取得 1〉

図 14は、図 5に示すサーバにおけるノード情報の取得の流れ其の 1を示すフローチャートである。図 14のフローチャートにおいては、ノード側によるノード情報の通知 1の処理と、サーバ側によるノード情報の取得 1の処理が示されている。まず、ノード側が、ノード名およびマシンの仕様をノード開局通知としてサーバ側へ送信すると（S 51)、サーバ側は、ノード開局通知として、ノード名およびマシンの仕様の取得処理を行う（S52)。さらに、サーバ側は、図 8に示すようなノードテーブル内に既に登録済みのノード名があるか否かを判断する（S53)。

[0057] ここで、ノードテーブル内に登録済みのノード名がなければ（S53、 No)、ステップ S 52に戻って、サーバ側は、ノード名およびマシンの仕様の取得処理を行うが、ノードテーブル内に既に登録済みのノード名があれば（S53、 Yes)、マシンの仕様から能力値を算出し (S54)、図 8に示すノードテーブルにノード名と能力値を登録する（S5 5)。さらに、サーバ側は、図 8に示すノードテーブルの CPU平均使用率、ローカル C PU使用率、および状況を初期化して閾値をクリアする（S56)。

[0058] つまり、ノードとなる計算機 (PC)の電源投入時、または、ノード側の分散処理制御プログラムの開始時（つまり、ジョブ受付の開始時）において、図 14に示すようなノード情報の取得を行う。

[0059] 〈ノード情報の取得 2〉

図 15は、図 5に示す分散処理管理システムにおけるノード情報の取得の流れ其の 2を示すフローチャートである。図 15のフローチャートにおいては、ノード側によるノード情報の取得 2の処理と、サーバ側によるノード情報の取得 2の処理が示されている

[0060] 図 15において、ノード側は、ノード名、ローカル CPU使用時間、 CPU平均使用時間、および現在の進涉率をノード情報通知としてサーバ側へ送信する（S61)。ノード側は、このようなノード情報を一定の時間間隔ごとにサーバ側へ通知する（S62)。

[0061] 一方、サーバ側は、ノード側からノード情報の通知を受けると、ノード名に対応した CPU平均使用時間、ローカル CPU使用時間、および進涉率についてのノード情報取得処理を行い（S63)、平均 CPU使用率およびローカル CPU使用率を算出して図 8に示すようなノードテーブルの更新を行う（S64)。さらに、サーバ側は、ジョブ実行時間の累積値と予想終了時間から現在の進渉率を算出する（S65)。そして、ノードテーブルにおける進渉率の更新を行い（S66)、ステップ S63に戻って前述の処理を繰り返す。

[0062] なお、 CPU平均使用率とは、 CPU平均使用時間の過去一定期間の累積値を過去一定期間の総時間で割った値である。つまり、 CPU平均使用率とは、投入ジョブがあるノードの CPUを使用している平均使用率である。また、ローカル CPU使用率とは、ローカル CPU使用時間の過去一定期間の累積値を過去一定期間の総時間で割つた値である。つまり、ローカル CPU使用率とは、ローカル CPUがジョブに使用されている平均使用率である。

[0063] すなわち、図 15に示すノード情報の取得其の 2の処理においては、ノード計算機でノード側の分散処理制御プログラムが動作している間は、常に一定間隔で処理状況がサーバへ伝達される。したがって、サーバ側はノード側からの情報に基づいてノードテーブルの CPU平均使用率やローカル CPU使用率を計算して進渉率を更新する

。なお、ノード側の進渉率はサーバ側からジョブを依頼されていない場合はゼロである。

[0064] 次に、図 5に示す分散処理管理装置（サーバ）が行うジョブの再投入判断について説明する。図 16は、ジョブの再投入判断の流れを示すフローチャートである。図 16において、サーバがジョブの再投入判断を行うとき、まず、図 8に示すようなノードターブノレから現在投入しているノードの次のノードにおけるレコード読み込む（S71)。そして、読み込んでいるレコードが最終レコードであるか否かを判断し（S72)、最終レコードである場合は（S72、 Yes)、あらかじめ設定された規定時間（例えば、 1分間）処理を停止し（S73)、ステップ S71に戻って、ノードテーブルから現在投入しているノードの次のノードにおけるレコード読み込み、前述のステップ S71以降の処理を繰り返す。

[0065] また、ステップ S72で、読み込んだレコードが最終レコードでなければ（S72、 No)、現在のジョブ状況は実行中であるか否かを判断し（S74)、ジョブを実行中であれば（ S74、 Yes)、 CPU平均使用率は所定の閾値より小さいか否かを判断し（S75)、 CP U平均使用率が所定の閾値より小さければ（S75、 Yes)、ジョブの多重投入処理を開始し（S76)、ステップ S71に戻って前述の処理を繰り返す。なお、ステップ S74でジョブ状況がジョブの実行中でない場合（S74、 No)、およびステップ S75で CPU平均使用率が所定の閾値より大きい場合（S75、 No)についても、ステップ S71に戻つて前述の処理を繰り返す。

[0066] つまり、図 16に示すサーバによるジョブの再投入の判断では、サーバは図 10に示すジョブ管理テーブルの先頭からレコードを読み込み、読み込んだレコードがジョブ実行中のレコードであるならば、 CPU平均使用率が所定の閾値より小さいか否かを調べ、 CPU平均使用率く閾値であるならば多重処理を開始する。また、 CPU平均使用率く閾値が成立しない場合は次のレコードを調べる。このようにして最終レコードまで処理が完了したら、規定時間（例えば、 1分間）処理を中断して先頭のレコードから再び処理を開始する。

[0067] 次に、サーバが行う多重実行処理の流れについて説明する。図 17は、分散処理管理装置（サーバ）が行う多重実行処理の流れを示すフローチャートである。図 17に示す多重実行処理の流れでは、多重実行処理の開始時点において対象となるノードテープノレは既知となってレヽるものとする。

[0068] 図 17において、まず、サーバは、ノード名をキーにして図 10に示すようなジョブ管理テーブルを検索する（S81)。次に、検索結果のジョブ管理テーブルのクラス名をキ一にして、ジョブクラスを検索するための図 12に示すようなジョブクラステーブルから、ジョブの優先順位、多重度、再投入限界値を求める（S82)。

[0069] 次に、ジョブの多重度分だけ、図 10に示すジョブ管理テーブルの各ジョブ情報から以下の 4項目について計算を行う。なお、必要に応じて図 8のノードテーブルを検索する。すなわち、ステップ S83において、サーバはジョブ管理テーブルに対して次の 4項目の計算を行う。

(1)予測最短処理時間 = Min (実行時間 X (100 -進涉率) /進涉率）

(2)平均全体処理量 = Ave (ノード処理能力 X CPU平均使用率 X (予測最短処理時間 +実行時間））

(3)最大進涉率 = Max (進涉率）

(4)最小要求性能 = Min (平均全体処理量/予測最短処理時間）

[0070] なお、（4)項の最小要求性能とは、最短と予想された予測最短処理時間よりも早く処理を完了するために必要となる最小の性能要求のことであって、能力値 X CPU平均使用率を単位とする。

[0071] 次に、具体的な数値に基づいて上記の 4項について計算を行ってみる。例えば、能力値 =0. 8、 CPU平均使用率 = 60%、処理時間 =4時間、進渉率 = 40%の場合は、 ( 1 )予測最短処理時間 = 4 [時間] X (100-40)/40 = 6 [時間]

(2)平均全体処理量 =0· 8 X 60[%] X (6 + 4) = 480

(3)最大進涉率 =40[%]

(4)最小要求性能 = 480/6 = 80

[0072] つまり、能力値 = 1. 0、ローカル CPU使用率 = 20%以下（つまり、空きが 80%以上）のノードが上記の値に該当する。なお、複数ジョブが投入されていれば、（1)の予測最短処理時間は最小値を求め、（2)の全体処理量は平均値を求め、（3)の進渉率は最大値を求める。

[0073] 再び図 17のフローチャートに戻って、ステップ S83で計算した最大進渉率と図 12 に示すようなジョブクラステーブルの再投入限界値とを比較し、最大進渉率が再投入限界値より小さくない場合は (最大進渉率く再投入限界値でない場合)は (S84、 No )、多重投入を行わずに多重実行処理を終了とする。

[0074] また、最大進涉率が再投入限界値より小さい場合においても（S84、 Yes)、多重度の空き (すなわち、ジョブ管理テーブルの空き)を判定し、ジョブクラステーブルの多重度を超えてしまう場合には（S85、 No)、多重投入を行わずに多重実行処理を終了する。

[0075] 一方、ステップ S85で、多重度 (ジョブ管理テーブルの空き)を判定した結果、ジョブクラステーブルの多重度を超えない場合には（S85、 Yes)、最小要求性能 <能力値 X (100—ローカル CPU使用率）となるような空き実行ノードを要求 (もしくは検索)する (S86)。

[0076] 次に、検索結果で該当する空きノードがあるか否かを判定し (S87)、条件に合う空きノードが無い場合は（S87、 No)、自ジョブ管理テーブル以外のジョブ管理テープルに対して、以下の 3つの条件全てを満足するジョブを検索する。なお、必要に応じて、ノードテーブルやジョブクラステーブルも検索する（S88)。

[0077] すなわち、ジョブ管理テーブルの検索処理においては、

(1)現在実行中のジョブより優先度の低いジョブ

(2)ジョブ進渉率がキャンセル限界値より低いジョブ

(3)実行ノードの能力値 X CPU平均使用率が最小要求性能を上回るジョブの 3つの条件全てを満足するジョブを検索する。

[0078] 次に、上記 3つの条件全てを満足する該当ジョブがあるか否かを判定し（S89)、該当ジョブがなければ（S89、 No)、多重投入を行わずに多重実行処理を終了する。一方、上記 3つの条件全てを満足する該当ジョブがあれば（S89、 Yes)、該当ジョブをキャンセルする（S90)。

[0079] また、ステップ S87の判定で条件に合う空きノードがある場合、または、ステップ S9 0で条件に合うノードが見つかった場合は、ジョブ管理テーブルの空き部分と実行依頼するノードテーブルおよび多重実行のジョブクラステーブルを通知して、ジョブの投入を行うか、またはジョブの投入を依頼する（S91)。

[0080] 次に、分散処理管理装置（サーバ）が行うジョブキャンセルの処理の流れにっレ、て説明する。

[0081] 〈ノード側からのジョブキャンセル処理〉

図 18は、図 5に示す分散処理管理システムにおいてノード側からのジョブキャンセノレ処理の流れを示すフローチャートである。ノード側のキャンセル要求の処理にぉレ、ては、ノード名およびジョブ名を付加してサーバ側へキャンセル要求の通知を行う（S 101)。ノード側は、サーバ側に対してこのようキャンセルの通知を一定の時間間隔ごとに行う（S102)。

[0082] 一方、サーバ側のキャンセル受付処理においては、サーバ側はノード側からのキヤンセル要求を受付けると、キャンセル情報の取得処理を行い（S103)、ノードテープルの CPU平均使用時間（使用率）、ローカル CPU使用時間（使用率）、進涉率、および状況をクリアする（S104)。さらに、ジョブ管理テーブルからノード名、ジョブ名に対応するデータを削除する（S105)。但し、多重ジョブが投入されているノードでキャンセルが要求された場合は、ジョブ管理テーブルから削除するのは、キャンセルが要求されたノードで実行されていたジョブのみであって、他のノードで実行されている多重ジョブは削除されない。

[0083] つまり、ノード側からのジョブキャンセル処理においては、ノードは本来のユーザの都合で分散処理プログラムを停止してユーザの占有使用状態に戻すことができる。このとき実行していた分散処理プログラムはキャンセルされる。また、サーバ側ではキヤンセル要求を受けてノードテーブル、ジョブ管理テーブルから対応するノード情報とジョブ情報を消去する。なお、ノード側の一定時間の WAIT処理はサーバのキャンセル処理を確実に行うための待ち時間である。し力し、サーバ側がキャンセル要求に対してキャンセル完了の応答を返す場合は、一定時間 WAIT処理は不用である。

[0084] 〈サーバ側からの終了およびジョブキャンセル処理〉

図 19は、図 5に示す分散処理管理システムにおいてサーバ側からの終了およびジヨブキャンセル処理の流れを示すフローチャートである。図 19において、ノード側のジョブ終了ノードは、サーバ側に対してジョブ終了通知および結果転送を行うとき、まず、ジョブ終了でノード名、実行終了ジョブ名、および終了状況を終了メッセージとしてサーバ側へ送出する（S 111)。

[0085] すると、サーバ側の終了 'キャンセル処理では、ノード側からノード名、ジョブ名、および実行状態の取得処理を行い（S112)、ジョブは正常に終了したか否力、を判断する（S113)。ここで、サーバ側がジョブは正常に終了したと判断すれば（S113、 Yes) 、さらに、多重処理のジョブがあるか否かを判断する（SI 14)。ここで、多重処理のジヨブがなければ（S 114、 No)、結果情報の取得処理を行い（S 115)、多重処理のジヨブがあれば（S 114、 Yes) ,同一ジョブ名の他のノードへキャンセル要求を送出した後に（S 116)、結果情報の取得処理を行う（S 115)。

[0086] そして、サーバは、ノードテーブルに対応するノードの CPU平均使用時間（使用率 )、ローカル CPU使用時間（使用率）、進涉率、および状況をクリアする（S117)。さらに、ジョブ管理テーブルからノード名、ジョブ名の対応するノード情報を削除する（S1 18)。なお、ステップ S113で、サーバ側がジョブは正常に終了していないと判断すれば（S113、 No)、サーバは、直接、ノードテーブルに対応するノードの CPU平均使用時間（使用率）、ローカル CPU使用時間（使用率）、進渉率、および状況をクリアし (S 117)。さらに、ジョブ管理テーブルからノード名およびジョブ名に対応するノード情報を削除する（S118)。

[0087] 一方、ノード側の終了ノードは、ステップ S113で、サーバがジョブは正常に終了していないと判断した場合（S 113、 Noでキャンセルの場合）、およびサーバがジョブは正常に終了したと判断した場合（S113、 Yesで転送要求を行った場合）は、サーバ力該当する応答要求を受け取る（S119)。

[0088] そして、ノード側は、サーバ側から取得した応答要求がキャンセル要求であるか否力を判断し（S120)、応答要求がキャンセル要求ではない場合は（S120、 No)、サーバ側に対して結果情報の転送処理を行い（SI 21)、ジョブの終了処理を行う（S12 2)。また、応答要求がキャンセル要求である場合は（S 120、 Yes)、直ちに、ジョブの終了処理を行う（S122)。

[0089] また、ノード側における多重実行でジョブ未終了ノードは、サーバからのキャンセル受付処理において、ステップ S 116で同一ジョブ名の他のノードへキャンセル要求を送出したときに（S116)、サーバからキャンセル要求を受け、サーバからの応答処理を行う（S123)。そして、ノード側は、サーバから取得した応答要求がキャンセル要求であるか否かを判断し（S 124)、応答要求がキャンセル要求ではなレ、場合は（S 124 、 No)、サーバ側に対して結果情報の転送処理を行い（S125)、ジョブの終了処理を行う（S 126)。また、また、応答要求がキャンセル要求である場合は（S 124、 Yes) 、直ちに、ジョブの終了処理を行う（S 126)。

[0090] すなわち、サーバ側からの終了およびキャンセル処理においては、ジョブが終了した場合は、ノードはサーバ側へ終了の情報を通知する。また、サーバは、そのジョブが多重実行されていないかを確認して、終了したジョブのデータをノードから収集 (ノヽ一べスト）する。一方、多重実行のジョブを処理している場合は、サーバは、他のノードを停止（ジョブキャンセル）させる。さらに、サーバ側の都合でジョブをキャンセルする場合も、同様にして、同じジョブ名を持つ多重実行ジョブは同時にキャンセルされ、その多重ジョブを実行していたノードも同時に開放される。

[0091] また、サーバが多重ジョブを投入するために優先度の低いジョブが投入されているノードをキャンセルする場合も、サーバ力ものキャンセルに対して、ノードはサーバからのキャンセル受付の処理を行レ、、自ノードを開放する。

[0092] 以上に説明した本発明の実施の形態において、適宜説明された各フローチャートの動作をコンピュータに実行させる分散処理管理プログラムとして、コンピュータにより読取り可能な記録媒体に記憶させることによって、分散処理管理装置を構成するコンピュータに分散処理管理方法を実行させることが可能となる。なお、本発明において、上記コンピュータにより読取り可能な記録媒体は、 CD—ROMやフレキシブルデイスク、 DVDディスク、光磁気ディスク、 ICカード等の可搬型記憶媒体や、コンビユータプログラムを保持するデータベース、或いは、他のコンピュータ並びにそのデータベースや、更に回線上の伝送媒体をも含むものである。

産業上の利用可能性

以上説明したように、本発明によれば、グリッド計算機環境のような個々の実行処理計算機の処理能力が著しく異なり、また、時間的にも激しく変化する分散処理環境においても、各処理の実行から完了までの時間（TAT)を最小化でき、かつ、資源量や処理の進行度によって、管理者が分散環境の特性を考慮して二重 (多重)実行の方針を決定できる。そのため、全体の TATを改善すると共に計算機資源の有効な利用が可能となる。

Claims

請求の範囲

[1] 複数のノードに接続されることができ、各ノードにジョブを投入することができると共に該ジョブの実行管理を行うことができる分散処理管理装置であって、

第 1ジョブを投入した第 1ノードの第 1リソース関連情報を取得する第 1リソース関連情報取得部と、

前記第 1ジョブを投入していない第 2ノードの第 2リソース関連情報を取得する第 2リソース関連情報取得部と、

前記第 1リソース関連情報取得部により取得された第 1リソース関連情報と、前記第 2リソース関連情報取得部により取得された第 2リソース関連情報とに基づいて、前記第 1ノードに投入した前記第 1ジョブを前記第 2ノードに投入するか否かについての判断を行うジョブ再投入判断部と

を備えてなる分散処理管理装置。

[2] 請求項 1に記載の分散処理管理装置にぉレ、て、

前記ジョブ再投入判断部は、前記第 1ジョブの投入を肯定する判断において、前記第 1リソース関連情報に基づいて、前記第 1ノードの前記第 1ジョブの実行に対する C PU使用率が所定の閾値を下回る場合を判断することを特徴とする分散処理管理装置。

[3] 請求項 1に記載の分散処理管理装置にぉレ、て、

前記ジョブ再投入判断部は、前記第 1ジョブの投入を肯定する判断において、前記第 1リソース関連情報に基づいて、前記第 1ノードの前記第 1ジョブの進渉率が再投入限界値を越えてレ、なレ、場合を判断することを特徴とする分散処理管理装置。

[4] 請求項 1に記載の分散処理管理装置にぉレ、て、

前記ジョブ再投入判断部は、前記第 1ジョブの投入の判断において、前記第 2リソース関連情報に基づいて、前記第 1ジョブの実行に要求される所定の性能を有するノードであって、投入された第 2ジョブを実行していない空きノードである第 2ノードの有無を判断することを特徴とする分散処理管理装置。

[5] 請求項 1に記載の分散処理管理装置にぉレ、て、

前記ジョブ再投入判断部は、前記第 1ジョブの投入の判断において、前記第 2リソース関連情報に基づレ、て、該第 2ノードで実行されてレ、る第 2ジョブをキャンセルして第 1ジョブを投入するための所定の条件を判断することを特徴とする分散処理管理装置。

[6] 請求項 5に記載の分散処理管理装置において、

前記所定の条件についての判断は、前記第 2リソース関連情報に基づいて、前記第 1ジョブの実行に要求される所定の性能を有するノードであって、投入された第 2ジヨブを実行してレ、なレ、空きノードである第 2ノードがないと判断した場合に行われることを特徴とする分散処理管理装置。

[7] 請求項 5に記載の分散処理管理装置において、

前記所定の条件として、前記第 2ジョブに与えられた優先度が前記第 1ジョブに与えられた優先度より低い場合、前記第 2ジョブの前記第 2ノードにおける進渉率が所定のキャンセル限界値よりも低い場合、前記第 2ノードが前記第 1ジョブの実行に要求される所定の性能を満たす場合のうち、少なくともいずれか一つを条件とすることを特徴とする分散処理管理装置。

[8] 複数のノードにおける各ノードにジョブを投入するとともに該ジョブの実行管理を行う分散処理管理方法であって、

第 1ジョブを投入した第 1ノードの第 1リソース関連情報を取得する第 1リソース関連情報取得ステップと、

前記第 1ジョブを投入していない第 2ノードの第 2リソース関連情報を取得する第 2リソース関連情報取得ステップと、

前記第 1リソース関連情報取得ステップにより取得された前記第 1リソース関連情報と、前記第 2リソース関連情報取得ステップにより取得された前記第 2リソース関連情報とに基づいて、前記第 1ノードに投入した前記第 1ジョブを前記第 2ノードに投入するか否かについての判断を行うジョブ再投入判断ステップと

を備えてなる分散処理管理方法。

[9] 請求項 8に記載の分散処理管理方法において、

前記ジョブ再投入判断ステップは、前記第 1ジョブの投入を肯定する判断において、前記第 1リソース関連情報に基づいて、前記第 1ノードの前記第 1ジョブの実行に対する CPU使用率が所定の閾値を下回る場合を判断することを特徴とする分散処理管理方法。

[10] 請求項 8に記載の分散処理管理方法において、

前記ジョブ再投入判断ステップは、前記第 1ジョブの投入を肯定する判断において、前記第 1リソース関連情報に基づいて、前記第 1ノードの前記第 1ジョブの進渉率が再投入限界値を越えてレ、なレ、場合を判断することを特徴とする分散処理管理方法。

[11] 請求項 8に記載の分散処理管理方法において、

前記ジョブ再投入判断ステップは、前記第 1ジョブの投入の判断において、前記第 2リソース関連情報に基づいて、前記第 1ジョブの実行に要求される所定の性能を有するノードであって、投入された第 2ジョブを実行していない空きノードである第 2ノードの有無を判断することを特徴とする分散処理管理方法。

[12] 請求項 8に記載の分散処理管理方法において、

前記ジョブ再投入判断ステップは、前記第 1ジョブの投入の判断において、前記第 2リソース関連情報に基づレ、て、該第 2ノードで実行されてレ、る第 2ジョブをキャンセルして第 1ジョブを投入するための所定の条件を判断することを特徴とする分散処理管理方法。

[13] 請求項 12に記載の分散処理管理方法において、

前記所定の条件として、前記第 2ジョブに与えられた優先度が前記第 1ジョブに与えられた優先度より低い場合、前記第 2ジョブの前記第 2ノードにおける進涉率が所定のキャンセル限界値よりも低い場合、前記第 2ノードが前記第 1ジョブの実行に要求される所定の性能を満たす場合のうち、少なくともいずれか一つに該当することを条件とすることを特徴とする分散処理管理方法。

[14] 複数のノードにおける各ノードにジョブを投入するとともに該ジョブの実行管理を行うことをコンピュータに実行させる分散処理管理プログラムであって、

前記第 1ジョブを投入していない第 2ノードの第 2リソース関連情報を取得する第 2リソース関連情報取得ステップと、前記第 1リソース関連情報取得ステップにより取得された前記第 1リソース関連情報と、前記第 2リソース関連情報取得ステップにより取得された前記第 2リソース関連情報とに基づいて、前記第 1ノードに投入した前記第 1ジョブを前記第 2ノードに投入するか否かについての判断を行うジョブ再投入判断ステップと

をコンピュータに実行させる分散処理管理プログラム。

[15] 請求項 14に記載の分散処理管理プログラムにおレ、て、

前記ジョブ再投入判断ステップは、前記第 1ジョブの投入を肯定する判断において、前記第 1リソース関連情報に基づいて、前記第 1ノードの前記第 1ジョブの実行に対する CPU使用率が所定の閾値を下回る場合を判断することを特徴とする分散処理管理プログラム。

[16] 請求項 14に記載の分散処理管理プログラムにおレ、て、

前記ジョブ再投入判断ステップは、前記第 1ジョブの投入を肯定する判断において、前記第 1リソース関連情報に基づいて、前記第 1ノードの前記第 1ジョブの進涉率が再投入限界値を越えてレ、なレ、場合を判断することを特徴とする分散処理管理プログラム。

[17] 請求項 14に記載の分散処理管理プログラムにおレ、て、

前記ジョブ再投入判断ステップは、前記第 1ジョブの投入の判断において、前記第 2リソース関連情報に基づいて、前記第 1ジョブの実行に要求される所定の性能を有するノードであって、投入された第 2ジョブを実行していない空きノードである第 2ノードの有無を判断することを特徴とする分散処理管理プログラム。

[18] 請求項 14に記載の分散処理管理プログラムにおレ、て、

前記ジョブ再投入判断ステップは、前記第 1ジョブの投入の判断において、前記第 2リソース関連情報に基づレ、て、該第 2ノードで実行されてレ、る第 2ジョブをキャンセルして第 1ジョブを投入するための所定の条件を判断することを特徴とする分散処理管理プログラム。

[19] 請求項 18に記載の分散処理管理プログラムにおいて、

前記所定の条件についての判断は、前記第 2リソース関連情報に基づいて、前記第 1ジョブの実行に要求される所定の性能を有するノードであって、投入された第 2ジヨブを実行してレ、なレ、空きノードである第 2ノードがないと判断した場合に行われることを特徴とする分散処理管理プログラム。

請求項 18に記載の分散処理管理プログラムにおいて、

前記所定の条件として、前記第 2ジョブに与えられた優先度が前記第 1ジョブに与えられた優先度より低い場合、前記第 2ジョブの前記第 2ノードにおける進渉率が所定のキャンセル限界値よりも低い場合、前記第 2ノードが前記第 1ジョブの実行に要求される所定の性能を満たす場合のうち、少なくともいずれか一つに該当することを条件とすることを特徴とする分散処理管理プログラム。