(57)【要約】  分散処理管理装置において、サーバ３は、一定期間ごとに各ノードのＣＰＵ使用率などのリソース状況を管理するために、ノードテーブル５、ジョブ管理テーブル６、およびジョブクラステーブル７を有する。ジョブの投入後にＣＰＵ等の稼働率が高くなり、投入ジョブの実行速度が落ちた場合は、各テーブルを参照して、現用のノード２ａから他のノード２ｂへジョブの再投入を行う。これによって、グリッド計算機環境において、全体のＴＡＴを改善することができると共に計算機資源の有効な利用が可能となる。【特許請求の範囲】
【請求項１】
複数のノードに接続されることができ、各ノードにジョブを投入することができると共に該ジョブの実行管理を行うことができる分散処理管理装置であって、
第１ジョブを投入した第１ノードの第１リソース関連情報を取得する第１リソース関連情報取得部と、
前記第１ジョブを投入していない第２ノードの第２リソース関連情報を取得する第２リソース関連情報取得部と、
前記第１リソース関連情報取得部により取得された第１リソース関連情報と、前記第２リソース関連情報取得部により取得された第２リソース関連情報とに基づいて、前記第１ノードに投入した前記第１ジョブを前記第２ノードに投入するか否かについての判断を行うジョブ再投入判断部と
を備えてなる分散処理管理装置。
【請求項２】
請求項１に記載の分散処理管理装置において、
前記ジョブ再投入判断部は、前記第１ジョブの投入を肯定する判断において、前記第１リソース関連情報に基づいて、前記第１ノードの前記第１ジョブの実行に対するＣＰＵ使用率が所定の閾値を下回る場合を判断することを特徴とする分散処理管理装置。
【請求項３】
請求項１に記載の分散処理管理装置において、
前記ジョブ再投入判断部は、前記第１ジョブの投入を肯定する判断において、前記第１リソース関連情報に基づいて、前記第１ノードの前記第１ジョブの進捗率が再投入限界値を越えていない場合を判断することを特徴とする分散処理管理装置。
【請求項４】
請求項１に記載の分散処理管理装置において、
前記ジョブ再投入判断部は、前記第１ジョブの投入の判断において、前記第２リソース関連情報に基づいて、前記第１ジョブの実行に要求される所定の性能を有するノードであって、投入された第２ジョブを実行していない空きノードである第２ノードの有無を判断することを特徴とする分散処理管理装置。
【請求項５】
請求項１に記載の分散処理管理装置において、
前記ジョブ再投入判断部は、前記第１ジョブの投入の判断において、前記第２リソース関連情報に基づいて、該第２ノードで実行されている第２ジョブをキャンセルして第１ジョブを投入するための所定の条件を判断することを特徴とする分散処理管理装置。
【請求項６】
請求項５に記載の分散処理管理装置において、
前記所定の条件についての判断は、前記第２リソース関連情報に基づいて、前記第１ジョブの実行に要求される所定の性能を有するノードであって、投入された第２ジョブを実行していない空きノードである第２ノードがないと判断した場合に行われることを特徴とする分散処理管理装置。
【請求項７】
請求項５に記載の分散処理管理装置において、
前記所定の条件として、前記第２ジョブに与えられた優先度が前記第１ジョブに与えられた優先度より低い場合、前記第２ジョブの前記第２ノードにおける進捗率が所定のキャンセル限界値よりも低い場合、前記第２ノードが前記第１ジョブの実行に要求される所定の性能を満たす場合のうち、少なくともいずれか一つを条件とすることを特徴とする分散処理管理装置。
【請求項８】
複数のノードにおける各ノードにジョブを投入するとともに該ジョブの実行管理を行う分散処理管理方法であって、
第１ジョブを投入した第１ノードの第１リソース関連情報を取得する第１リソース関連情報取得ステップと、
前記第１ジョブを投入していない第２ノードの第２リソース関連情報を取得する第２リソース関連情報取得ステップと、
前記第１リソース関連情報取得ステップにより取得された前記第１リソース関連情報と、前記第２リソース関連情報取得ステップにより取得された前記第２リソース関連情報とに基づいて、前記第１ノードに投入した前記第１ジョブを前記第２ノードに投入するか否かについての判断を行うジョブ再投入判断ステップと
を備えてなる分散処理管理方法。
【請求項９】
請求項８に記載の分散処理管理方法において、
前記ジョブ再投入判断ステップは、前記第１ジョブの投入を肯定する判断において、前記第１リソース関連情報に基づいて、前記第１ノードの前記第１ジョブの実行に対するＣＰＵ使用率が所定の閾値を下回る場合を判断することを特徴とする分散処理管理方法。
【請求項１０】
請求項８に記載の分散処理管理方法において、
前記ジョブ再投入判断ステップは、前記第１ジョブの投入を肯定する判断において、前記第１リソース関連情報に基づいて、前記第１ノードの前記第１ジョブの進捗率が再投入限界値を越えていない場合を判断することを特徴とする分散処理管理方法。
【請求項１１】
請求項８に記載の分散処理管理方法において、
前記ジョブ再投入判断ステップは、前記第１ジョブの投入の判断において、前記第２リソース関連情報に基づいて、前記第１ジョブの実行に要求される所定の性能を有するノードであって、投入された第２ジョブを実行していない空きノードである第２ノードの有無を判断することを特徴とする分散処理管理方法。
【請求項１２】
請求項８に記載の分散処理管理方法において、
前記ジョブ再投入判断ステップは、前記第１ジョブの投入の判断において、前記第２リソース関連情報に基づいて、該第２ノードで実行されている第２ジョブをキャンセルして第１ジョブを投入するための所定の条件を判断することを特徴とする分散処理管理方法。
【請求項１３】
請求項１２に記載の分散処理管理方法において、
前記所定の条件として、前記第２ジョブに与えられた優先度が前記第１ジョブに与えられた優先度より低い場合、前記第２ジョブの前記第２ノードにおける進捗率が所定のキャンセル限界値よりも低い場合、前記第２ノードが前記第１ジョブの実行に要求される所定の性能を満たす場合のうち、少なくともいずれか一つに該当することを条件とすることを特徴とする分散処理管理方法。
【請求項１４】
複数のノードにおける各ノードにジョブを投入するとともに該ジョブの実行管理を行うことをコンピュータに実行させる分散処理管理プログラムであって、
第１ジョブを投入した第１ノードの第１リソース関連情報を取得する第１リソース関連情報取得ステップと、
前記第１ジョブを投入していない第２ノードの第２リソース関連情報を取得する第２リソース関連情報取得ステップと、
前記第１リソース関連情報取得ステップにより取得された前記第１リソース関連情報と、前記第２リソース関連情報取得ステップにより取得された前記第２リソース関連情報とに基づいて、前記第１ノードに投入した前記第１ジョブを前記第２ノードに投入するか否かについての判断を行うジョブ再投入判断ステップと
をコンピュータに実行させる分散処理管理プログラム。
【請求項１５】
請求項１４に記載の分散処理管理プログラムにおいて、
前記ジョブ再投入判断ステップは、前記第１ジョブの投入を肯定する判断において、前記第１リソース関連情報に基づいて、前記第１ノードの前記第１ジョブの実行に対するＣＰＵ使用率が所定の閾値を下回る場合を判断することを特徴とする分散処理管理プログラム。
【請求項１６】
請求項１４に記載の分散処理管理プログラムにおいて、
前記ジョブ再投入判断ステップは、前記第１ジョブの投入を肯定する判断において、前記第１リソース関連情報に基づいて、前記第１ノードの前記第１ジョブの進捗率が再投入限界値を越えていない場合を判断することを特徴とする分散処理管理プログラム。
【請求項１７】
請求項１４に記載の分散処理管理プログラムにおいて、
前記ジョブ再投入判断ステップは、前記第１ジョブの投入の判断において、前記第２リソース関連情報に基づいて、前記第１ジョブの実行に要求される所定の性能を有するノードであって、投入された第２ジョブを実行していない空きノードである第２ノードの有無を判断することを特徴とする分散処理管理プログラム。
【請求項１８】
請求項１４に記載の分散処理管理プログラムにおいて、
前記ジョブ再投入判断ステップは、前記第１ジョブの投入の判断において、前記第２リソース関連情報に基づいて、該第２ノードで実行されている第２ジョブをキャンセルして第１ジョブを投入するための所定の条件を判断することを特徴とする分散処理管理プログラム。
【請求項１９】
請求項１８に記載の分散処理管理プログラムにおいて、
前記所定の条件についての判断は、前記第２リソース関連情報に基づいて、前記第１ジョブの実行に要求される所定の性能を有するノードであって、投入された第２ジョブを実行していない空きノードである第２ノードがないと判断した場合に行われることを特徴とする分散処理管理プログラム。
【請求項２０】
請求項１８に記載の分散処理管理プログラムにおいて、
前記所定の条件として、前記第２ジョブに与えられた優先度が前記第１ジョブに与えられた優先度より低い場合、前記第２ジョブの前記第２ノードにおける進捗率が所定のキャンセル限界値よりも低い場合、前記第２ノードが前記第１ジョブの実行に要求される所定の性能を満たす場合のうち、少なくともいずれか一つに該当することを条件とすることを特徴とする分散処理管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、分散コンピューティングシステムにおいてジョブの投入制御およびジョブの実行制御を行う分散処理管理装置、分散処理管理方法、および分散処理管理プログラムに関するものである。
【背景技術】
【０００２】
従来より、複数のノードとそれらを管理するサーバを持った分散処理コンピューティングシステムでは、分散処理用プログラムをネットワークで接続されたノードに投入して各ノードで計算させた結果を回収している。分散処理用プログラムを投入する方法としては、空きノードを順番に選択して依頼する方法が用いられているが、近年では、家庭用／事務所用ＰＣ（Personal Computer：パソコン）を利用するケースもあり、その余剰なリソース能力を利用する場合は、ＰＣで実行する家庭用・事務処理プログラムに影響を与えないようにするために、分散処理用プログラムを最低優先度で実行させるようにしている。あるいは、リソースが他で利用されていないときのみ分散処理用プログラムを実行するように制御されている。そのため、分散処理用プログラムの投入時には、リソースの稼働率等のリソース利用率が低いＰＣを選択するなどして、分散処理用プログラムの実行の効率化を図っている。【０００３】
しかし、リソースの稼働率などの指標は一定期間ごとに求められるため、分散処理用プログラムの投入時の稼働率指標が古い場合もあり、必ずしも効果的には分散処理が運用されない。また、分散処理用プログラムの投入時の負荷が低くても投入された後に負荷が上昇すると分散処理用プログラムの実行に対応することができない。特に、家庭用／事務所用ＰＣの場合はリソース稼動率の変動が大きいため、投入された分散処理用プログラムの実行が負荷を重くすることもしばしばであり、結果的に、処理時間が長くなってしまうケースもある。【０００４】
そこで、このような不具合に対応するために、分散処理用プログラムの実行ノード側で負荷が上昇すると別のノードに分散処理用プログラムを再投入するようにサーバに通知するような仕組みを備えた分散処理コンピューティングシステムが知られている。図２０は、従来の分散処理コンピューティングシステムにおけるサーバ側と実行ノード側の処理の流れを示すフローチャートである。図２０に示すように、従来の分散処理コンピューティングシステムにおける分散処理用プログラムの再投入では、サーバ側は、一定期間ごとにＣＰＵリソース状況の収集（Ｓ２１１）とノードごとのリソース状況の管理（Ｓ２１２）とを行っている。【０００５】
また、サーバ側のジョブ管理とノード側におけるジョブ実行の処理の流れでは、ジョブ管理を行うサーバ側は、ジョブ実行依頼および再投入依頼を行うと（Ｓ２２１）、ノードのリソース状況の調査を行い（Ｓ２２２）、稼働率の低いノードを選択して（Ｓ２２３）、そのノードに対してジョブを投入する（Ｓ２２４）。一方、ジョブを実行するノード側は、サーバ側から投入されたジョブを実行し（Ｓ２２５）、ＣＰＵのリソースの閾値を超えていないか否かを判断して（Ｓ２２６）、ＣＰＵのリソースの閾値を超えていなければ（Ｓ２２６，Ｎｏ）、そのままジョブを実行するが（Ｓ２２５）、もしＣＰＵのリソースの閾値を超えていれば（Ｓ２２６，Ｙｅｓ）、他のノードへの切り替えをサーバに依頼して（Ｓ２２７）、先にジョブを投入したノードに対してはジョブの依頼をキャンセルする（Ｓ２２８）。【０００６】
ところが、通常はノードの負荷は動的に変化するため、ある時点でＣＰＵのリソースの閾値を超えていてもノードを切り替えることが必ずしも効率的な結果となるわけでもない。図２１は、従来の分散処理コンピューティングシステムにおけるノードの切り替え実行状況の一例を示す概念図である。図２１において、時刻ｔ０でノードＡにジョブが投入されたとき、時刻ｔ１でノードＡの負荷が上昇するとノードＢにジョブが再投入される。ノードＡの負荷が上昇しなければ時刻ｔ２でノードＡによるジョブの実行が終了される（Ｓ２３１）。また、負荷の上昇が瞬間的であってノードＢへの再投入がなければ時刻ｔ３でノードＡによるジョブの実行が終了される（Ｓ２３２）。一方、時刻ｔ１でノードＡの負荷が上昇してノードＢにジョブが再投入された場合は、ノードＢによる再投入ジョブは時刻ｔ４で終了する。また、ノードＡによる負荷上昇が長期間に亘りノードＢへの再投入がなければ、ノードＡによるジョブの終了は時刻ｔ５にまで延長される（Ｓ２３３）。つまり、ノードＡからノードＢへのジョブの切り替えによってジョブの処理が大幅に効率化されるのはステップＳ２３３の場合のみである。【０００７】
なお、本発明の関連ある従来技術としては、例えば、下記に示す特許文献１などが知られている。この技術は、ユーザ端末からの要求に応じたアプリケーションの実行を複数のノードによって効率的に行うものである。
【特許文献１】特開２００４−２８７８８９号公報（段落番号００４４〜００７５、および図５〜図７参照）
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかしながら、複数の情報処理をサーバで受け付け、複数のノードへ処理を投入する分散計算機環境では、各処理が効率よく実行されるように、サーバが、処理を実行するノードの能力や計算負荷状況に応じたスケジューリング管理を行っている。このとき、実行処理ノードの能力を１００％使用できる環境や、一定の処理能力が保証される場合などにおいては、サーバの管理は比較的容易である。また、各実行ノードの処理資源（例えば、ＣＰＵ能力やメモリ容量）に応じた処理を受け持たせることで、システム全体の能力を無駄なく利用して、各情報処理の投入から完了までの時間（以下、ターンアラウンドタイム：ＴＡＴという）を最小化することができる。【０００９】
ところが、ユーザが事務用ＰＣなどに利用しているノードの空き時間を利用したグリッド計算機環境の場合には、参加ノードの増減や計算能力の多様性はもとより、ユーザの使用状態による処理能力の増減が激しく、計算リソースが一定であるようなスケジューリングではＴＡＴを小さく保つことができない。このために、あるノードへ投入されたジョブの処理が、ノード側ユーザのアプリケーション使用開始に伴って遅延した場合は、別のノードへジョブの処理を再度投入して実行する管理方法も行われている。このような管理方法の場合には、ジョブの再処理の際に、今までのジョブの処理の途中結果を保存して別ノード上でジョブ実行中断点からジョブの処理を行う場合と、ジョブの処理を最初から実行する場合との２通りの処理方法がある。【００１０】
しかし、これらの処理方法では、先にジョブの処理を依頼したノード側の方でユーザの計算負荷が減少して、後に追加したノードよりも先に処理が終えられる可能性があり、二重（または三重以上）にジョブの再投入を実行したことがＴＡＴの改善にかならずしも役立つとは言えない。また、多重にジョブの処理をした分だけ、ジョブの処理を最初から実行する場合ではそれまでの計算処理は無駄となる。また、システム全体としての計算能力を減じてしまう欠点もある。【００１１】
さらに、Ａノードのジョブ処理の中断点からＢノードでジョブの再実行を行う方法では、ジョブの中断−再実行を繰り返す処理を常に行うため、ジョブを中断しなかった場合でも計算負荷が大きくなるなどの不具合が生じる。ジョブの実行中断点からジョブの処理を行う場合と、ジョブの処理を最初から実行する場合のいずれの処理方法の場合も、依頼処理数に十分な数のノードが登録されていない状況においては、むやみに二重（多重）にジョブの処理を行うことは、結果的にシステム全体の処理量が増え、サーバにそれまでに依頼されていた処理の完了時間がその分だけ遅延することになる。その結果、分散コンピューティングシステム全体としてのＴＡＴが悪化してしまう。したがって、グリッド計算機環境のように、処理ノードの負荷変動が大きい場合の分散処理においても、ＴＡＴを最小化しつつ、さらに、全体の計算資源を有効に活用することができるサーバでの処理管理方式が求められている。【００１２】
本発明は上述した問題点を解決するためになされたものであり、ＴＡＴを最小化して全体の計算資源を有効に活用することができる分散処理管理装置、分散処理管理方法、分散処理管理プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１３】
上述した課題を解決するため、本発明の分散処理管理装置は、複数のノードに接続されることができ、各ノードにジョブを投入することができると共にそのジョブの実行管理を行うことができる分散処理管理装置であって、第１ジョブを投入した第１ノードの第１リソース関連情報を取得する第１リソース関連情報取得部と、第１ジョブを投入していない第２ノードの第２リソース関連情報を取得する第２リソース関連情報取得部と、第１リソース関連情報取得部により取得された第１リソース関連情報と、第２リソース関連情報取得部により取得された第２リソース関連情報とに基づいて、第１ノードに投入した第１ジョブを第２ノードに投入するか否かについての判断を行うジョブ再投入判断部とを備えている。【００１４】
ここで、ジョブ再投入判断部は、第１ジョブの投入を肯定する判断において、第１リソース関連情報に基づいて、第１ノードの第１ジョブの実行に対するＣＰＵ使用率が所定の閾値を下回る場合を判断することを特徴とする。【００１５】
また、ジョブ再投入判断部は、第１ジョブの投入を肯定する判断において、第１リソース関連情報に基づいて、第１ノードの第１ジョブの進捗率が再投入限界値を越えていない場合を判断することを特徴とする。【００１６】
また、ジョブ再投入判断部は、第１ジョブの投入の判断において、第２リソース関連情報に基づいて、第１ジョブの実行に要求される所定の性能を有するノードであって、投入された第２ジョブを実行していない空きノードである第２ノードの有無を判断することを特徴とする。【００１７】
また、ジョブ再投入判断部は、第１ジョブの投入の判断において、第２リソース関連情報に基づいて、第２ノードで実行されている第２ジョブをキャンセルして第１ジョブを投入するための所定の条件を判断することを特徴とする。【００１８】
また、所定の条件についての判断は、第２リソース関連情報に基づいて、第１ジョブの実行に要求される所定の性能を有するノードであって、投入された第２ジョブを実行していない空きノードである第２ノードがないと判断した場合に行われることを特徴とする。【００１９】
また、所定の条件として、第２ジョブに与えられた優先度が第１ジョブに与えられた優先度より低い場合、第２ジョブの第２ノードにおける進捗率が所定のキャンセル限界値よりも低い場合、第２ノードが第１ジョブの実行に要求される所定の性能を満たす場合のうち、少なくともいずれか一つを条件とすることを特徴とする。【００２０】
また、本発明の分散処理管理方法は、複数のノードにおける各ノードにジョブを投入するとともにそのジョブの実行管理を行う分散処理管理方法であって、第１ジョブを投入した第１ノードの第１リソース関連情報を取得する第１リソース関連情報取得ステップと、第１ジョブを投入していない第２ノードの第２リソース関連情報を取得する第２リソース関連情報取得ステップと、第１リソース関連情報取得ステップにより取得された第１リソース関連情報と、第２リソース関連情報取得ステップにより取得された第２リソース関連情報とに基づいて、第１ノードに投入した第１ジョブを第２ノードに投入するか否かについての判断を行うジョブ再投入判断ステップとを備えている。【００２１】
ここで、前記ジョブ再投入判断ステップは、第１ジョブの投入を肯定する判断において、第１リソース関連情報に基づいて、第１ノードの第１ジョブの実行に対するＣＰＵ使用率が所定の閾値を下回る場合を判断することを特徴とする。【００２２】
また、前記ジョブ再投入判断ステップは、第１ジョブの投入を肯定する判断において、第１リソース関連情報に基づいて、第１ノードの第１ジョブの進捗率が再投入限界値を越えていない場合を判断することを特徴とする。【００２３】
また、前記ジョブ再投入判断ステップは、第１ジョブの投入の判断において、第２リソース関連情報に基づいて、第１ジョブの実行に要求される所定の性能を有するノードであって、投入された第２ジョブを実行していない空きノードである第２ノードの有無を判断することを特徴とする。【００２４】
また、前記ジョブ再投入判断ステップは、第１ジョブの投入の判断において、第２リソース関連情報に基づいて、第２ノードで実行されている第２ジョブをキャンセルして第１ジョブを投入するための所定の条件を判断することを特徴とする。【００２５】
また、所定の条件として、第２ジョブに与えられた優先度が第１ジョブに与えられた優先度より低い場合、第２ジョブの第２ノードにおける進捗率が所定のキャンセル限界値よりも低い場合、第２ノードが第１ジョブの実行に要求される所定の性能を満たす場合のうち、少なくともいずれか一つに該当することを条件とすることを特徴とする。【００２６】
また、本発明は、複数のノードにおける各ノードにジョブを投入するとともにそのジョブの実行管理を行うことをコンピュータに実行させる分散処理管理プログラムであって、第１ジョブを投入した第１ノードの第１リソース関連情報を取得する第１リソース関連情報取得ステップと、第１ジョブを投入していない第２ノードの第２リソース関連情報を取得する第２リソース関連情報取得ステップと、第１リソース関連情報取得ステップにより取得された第１リソース関連情報と、第２リソース関連情報取得ステップにより取得された第２リソース関連情報とに基づいて、第１ノードに投入した第１ジョブを第２ノードに投入するか否かについての判断を行うジョブ再投入判断ステップとをコンピュータに実行させる。
【図面の簡単な説明】
【００２７】
【図１】本発明の実施の形態における分散処理管理装置（サーバ）がノードに対して行うリソースの収集の流れを示すフローチャートである。
【図２】本発明の実施の形態における分散処理管理装置が行うジョブ投入の流れを示すフローチャートである。
【図３】本発明の実施の形態におけるジョブの再投入判断の流れを示すシーケンスである。
【図４】本発明の実施の形態におけるジョブ完了によるジョブキャンセルの処理の流れを示すフローチャートとシーケンスである。
【図５】本発明の実施の形態における分散処理管理システムの全体構成を示す構成図である。
【図６】本発明の実施の形態における分散処理管理装置（サーバ）が備えるノードテーブルの項目の一例を示す図である。
【図７】図６に示す能力値および閾値のテーブルを示す図である。
【図８】本発明の実施の形態における分散処理管理装置に適用されるノードテーブルの一例を示す図である。
【図９】本発明の実施の形態における分散処理管理装置（サーバ）が備えるジョブ管理テーブルの項目の一例を示す図である。
【図１０】本発明の実施の形態における分散処理管理装置（サーバ）に適用されるジョブ管理テーブルの一例を示す図である。
【図１１】本発明の実施の形態における分散処理管理装置（サーバ）が備えるジョブクラステーブルの項目の一例を示す図である。
【図１２】本発明の実施の形態における分散処理管理装置に適用されるジョブクラステーブルの一例を示す図である。
【図１３】本発明の実施の形態におけるジョブ投入の流れを示すフローチャートである。
【図１４】本発明の実施の形態における分散処理管理装置（サーバ）におけるノード情報の取得の流れ其の１を示すフローチャートである。
【図１５】本発明の実施の形態における分散処理管理装置（サーバ）におけるノード情報の取得の流れ其の２を示すフローチャートである。
【図１６】本発明の実施の形態における分散処理管理装置（サーバ）が行うジョブの再投入判断の流れを示すフローチャートである。
【図１７】本発明の実施の形態における分散処理管理装置（サーバ）が行う多重実行処理の流れを示すフローチャートである。
【図１８】本発明の実施の形態においてノード側からのジョブキャンセル処理の流れを示すフローチャートである。
【図１９】本発明の実施の形態における分散処理管理装置（サーバ）側からの終了およびジョブキャンセル処理の流れを示すフローチャートである。
【図２０】従来の分散処理コンピューティングシステムにおけるサーバ側と実行ノード側の処理の流れを示すフローチャートである。
【図２１】従来の分散処理コンピューティングシステムにおけるノードの切り替え実行状況の一例を示す概念図である。
【発明を実施するための最良の形態】
【００２８】
以下、本発明の実施の形態について図面を参照しつつ詳細に説明する。【００２９】
《発明の概要》
本発明の分散処理管理装置は、ジョブの実行ノードに投入ジョブの監視機能を設ける。そして、監視機能による投入ジョブの監視においては、実行ノードのリソース使用率(つまり、投入ジョブが使用するリソースや処理実行ノード全体でのリソースの使用率)を規定された時間ごとにサーバ側へ通知する。また、サーバは、通知された投入ジョブのリソースが設定閾値を下回った場合は、別の空きノードに対して再度ジョブを投入し（このようなジョブの投入をジョブ再投入という）、先に終了したジョブ結果を採用して、これまで実行中のジョブをキャンセルする機能を設ける。【００３０】
また、上記のジョブ再投入に関しては、以下に示すパラメータからなる実行ポリシーをジョブクラス(または、優先度)に対して設定する。すなわち、（１）ジョブ再投入回数(投入多重度)の限界値、（２）ジョブ終了予測に基づく判定有無、（３）後発処理が追いつくまでの限界値、の３項目の実行ポリシーをジョブクラス(または、優先度)に対して設定する。さらに、本発明の分散処理管理装置は、アプリケーションからＯＳなどのソフトウエアを利用するためのＡＰＩ（Application Programming Interface）を提供し、ジョブ側からの進捗状況を設定できるようにすることにより、ジョブの終了予測ができるようにする。【００３１】
図１は、本発明の分散処理管理装置において、サーバがノードに対して行うリソースの収集の流れを示すフローチャートである。図１に示すように、各ノードは、ジョブの実行中であれば、あらかじめ規定された時間を待って（Ｓ１）、ジョブが実行中であるか否かを判断し（Ｓ２）、ジョブが実行中であれば（Ｓ２、Ｙｅｓ）、ジョブを割り当てたＣＰＵの使用率平均値をサーバに通知し（Ｓ３）、ジョブが実行中でなければ（Ｓ２、Ｎｏ）、ジョブの割り当てが可能なＣＰＵ（ローカルＣＰＵ）の使用率平均値をサーバに通知する（Ｓ４）。このようにして、サーバは各ＣＰＵのリソース状況を収集する（Ｓ５）。【００３２】
すなわち、本発明の分散処理管理装置においては、各ノードは、ジョブの実行中であればあらかじめ規定された時間毎に処理ジョブに割り当てられたＣＰＵの使用率をサーバに対して通知し、ジョブの未実行状態であればローカルＣＰＵの使用率をサーバに対して通知する。これによって、サーバは通知されたＣＰＵの使用率状況を収集する。【００３３】
図２は、本発明の分散処理管理装置において、サーバが行うジョブ投入の流れを示すフローチャートである。図２に示すように、処理実行中のノードがあらかじめ規定された時間を待って（Ｓ１１）、ジョブの割り当てが可能なＣＰＵの使用率平均値をサーバに通知すると（Ｓ１２）、サーバはＣＰＵのリソース状況を収集して（Ｓ１３）、ポリシーの読み込みを行う（Ｓ１４）。【００３４】
このとき、サーバが読み込むポリシーは、ノード情報（つまり、ノード名、ＣＰＵアイドル平均値、性能、再投入閾値）、ジョブクラス情報（つまり、クラス名、最大多重値、優先順位）、およびジョブ管理情報（つまり、ジョブ名、投入先計算機名、進捗度、ジョブクラス）などである。【００３５】
次に、サーバは、収集したＣＰＵリソース状況でジョブの再実行が可能か否かを判断し（Ｓ１５）、ジョブの再実行が不可能であれば（Ｓ１５、Ｎｏ）、ステップＳ１３に戻って前述の処理を繰り返すが、収集したＣＰＵリソース状況でジョブの再実行が可能であれば（Ｓ１５、Ｙｅｓ）、ジョブを投入するマシン（ＰＣ）を決定し（Ｓ１６）、そのマシン（ＰＣ）に対してジョブを再投入する（Ｓ１７）。このような操作によってＣＰＵリソース状況に応じて別のノードへジョブを再投入することができる（Ｓ１８）。【００３６】
つまり、サーバは、ノードにジョブを投入した後、実行ノードからＣＰＵ情報とジョブ実行状況を収集すると共に、実行ノードごとのＣＰＵ割当閾値と、ジョブごとの再投入閾値（限界値）と、ジョブ投入の最大多重値とを設定したポリシーを読み込む。【００３７】
そして、一定時間ごとに収集するＣＰＵのジョブ実行状況が閾値以下であって、かつジョブ再投入の閾値（限界値）以下であり、さらに最大多重値以下であるならば、次のルールにしたがって他ノードにジョブを再投入する。【００３８】
（１）空きノードがある場合は、ジョブの未実行ノードにジョブを投入する。
（２）空きノードがない場合は、サーバが管理するノード全てでジョブが実行中の場合は、ジョブポリシーで規定されたジョブ再投入閾値（限界値）以下の既実行中のジョブの中で、最も実行状況が低い既実行中のジョブをキャンセルし、該当するマシンに再投入すべきジョブを投入する。また、キャンセルされたジョブはサーバによるジョブキューの先頭に戻される。【００３９】
もし、実行中のノードからの報告により、ジョブ進捗状況がジョブ再投入閾値（限界値）を超えている場合は、閾値以下であり、かつ最大多重度以下であってもサーバはそのノードにジョブを再投入しない。図３は、本発明の分散処理管理装置において、ジョブの再投入判断の流れを示すシーケンスである。図３において、サーバが実行計算機Ａに対してジョブの実行を行うと（Ｓ２１）、実行計算機Ａからサーバに対して一定時間ごとにジョブの実行状況が通知される（Ｓ２２）。このようにして、実行計算機Ａはジョブの進捗度状況をサーバに報告し、サーバはジョブの進捗度状況とポリシーに定義された値とを比較する（Ｓ２３）。このとき、ジョブの進捗度状況が指定された値以上の進捗度であるならば、サーバは別の実行計算機に対してジョブの投入は行わない。【００４０】
図４は、本発明の分散処理管理装置において、ジョブ完了によるジョブキャンセルの処理の流れを示すフローチャート（図４（Ａ））とシーケンス（図４（Ｂ））である。図４（Ａ）に示すジョブ完了によるキャンセルフローでは、サーバがジョブ結果を収集すると（Ｓ３１）、他の計算機のジョブをキャンセルする（Ｓ３２）。つまり、図４（Ｂ）のシーケンスに示すように、サーバが実行計算機Ａに対してジョブ実行を行うと（Ｓ３３）、実行計算機Ａからサーバに対して定期的にジョブの進捗度状況が通知される（Ｓ３４）。さらに、サーバが実行計算機Ｂに対してジョブ実行を行うと（Ｓ３５）、実行計算機Ｂからサーバに対して定期的にジョブの進捗度状況が通知される（Ｓ３６）。そして、実行計算機Ｂのジョブが終了すると実行計算機Ａのジョブはキャンセルされる（Ｓ３７）。このようにして実行計算機Ａと実行計算機Ｂに多重投入されたジョブのいずれかが終了した場合は、サーバは残りのジョブをキャンセルする。【００４１】
《実施の形態》
以下、本発明における分散処理管理装置の具体的な実施の形態について説明する。図５は、本発明の実施の形態における分散処理管理装置システムの全体構成を示す構成図である。図５に示すように、実施の形態の分散処理管理監視システムは、複数のジョブ投入端末１ａ，１ｂと、複数のノード２ａ，２ｂと、分散処理管理装置をなすサーバ３とがネットワーク４を介して接続されている。【００４２】
複数のジョブ投入端末１ａ，１ｂは、それぞれ、ジョブ依頼・結果取得機能１１ａ，１１ｂを備えている。複数のノード２ａ，２ｂは、それぞれ、ジョブ実行機能１２ａ，１２ｂとノード情報通知機能１３ａ，１３ｂを備えている。サーバ３は、ジョブ受付機能３ａ、第１ノード情報取得機能（第１リソース関連情報取得部）３ｂ１、第２ノード情報取得機能（第２リソース関連情報取得部）３ｂ２、ジョブ割り当て機能３ｃ、ジョブ実行管理機能３ｄ、ジョブ多重実行管理機能３ｅ、およびジョブ再投入判断機能（ジョブ再投入判断部）３ｆを備えている。また、サーバ３にはノードテーブル５とジョブ管理テーブル６とジョブクラステーブル７が接続されている。【００４３】
ジョブ投入端末１ａ，１ｂは、システム利用者がジョブを投入するためのＰＣなどの入出力端末であって多数個存在する。これらのジョブ投入端末１ａ，１ｂは、サーバ３に対してジョブの実行を依頼し、その出力結果を取得する機能を有する。【００４４】
ノード２ａ，２ｂは、ジョブを実行するための計算機であって多数個存在し、それぞれ、ジョブ実行機能１２ａ，１２ｂとノード情報通知機能１３ａ，１３ｂの２つの機能を備えている。ジョブ実行機能１２ａ，１２ｂは、サーバ３から入力ファイルと実行プログラムを受け取って、それを対応するノード２ａ，２ｂで実行し、その出力結果をサーバ３に返す機能を備えている。また、ジョブ実行機能１２ａ，１２ｂには、ジョブをノード２ａ，２ｂまたはサーバ３からの命令によってキャンセルする機能も含まれる。なお、ジョブのキャンセル機能の詳細な説明は後述する。また、ノード情報通知機能１３ａ，１３ｂは、サーバ３に対してノード２ａ，２ｂの各種情報（つまり、ノード名、マシンス仕様、ＣＰＵ使用時間、ジョブ実行時間など）を通知する機能を備えている。なお、各種情報の通知機能の詳細な説明は後述する。【００４５】
サーバ３は分散処理管理装置全体を管理するための計算機であり、３つのテーブルと６つの機能を備えている。ジョブ受付機能３ａは、ジョブ投入端末１ａ，１ｂからジョブ実行依頼を受付けてジョブキューに格納する機能である。第１ノード情報取得機能（第１リソース関連情報取得部）３ｂ１は、ノード２ａから通知されたノード情報を取得し、ノードテーブル５を作成・更新する機能を備えている。第２ノード情報取得機能（第２リソース関連情報取得部）３ｂ２は、ノード２ｂから通知されたノード情報を取得し、ノードテーブル５を作成・更新する機能を備えている。【００４６】
ジョブ割り当て機能３ｃは、ジョブキューからジョブを取り出し、そのジョブ条件(例えば、ＯＳ種別やノード性能など)に合致し、かつジョブが実行されていないノード２ａ，２ｂをノードテーブル５から選択し、ジョブをノード２ａ，２ｂに割り当る機能を備えている。【００４７】
ジョブ実行管理機能３ｄは、割り当てられたジョブをノード２ａ，２ｂで実行するための管理機能であり、ジョブ管理テーブル６を作成および更新し、ジョブ実行処理(つまり、ノード２ａ，２ｂに対して入力ファイルと実行ファイルを送り、そのジョブ実行を命令して、ジョブ完了後に出力結果を受け取る処理)を行う機能を備えている。なお、ジョブキャンセル時の処理もジョブ実行管理機能３ｄに含まれる。ジョブ多重実行管理機能３ｅは、ジョブ管理テーブル６を参照し、ジョブを再投入した方がジョブ実行時間を短縮できるときにジョブの多重実行を行うための管理機能である。ジョブ再投入判断機能３ｆは、リソース情報に基づいて、例えばノード２ａに投入したジョブをノード２ｂに投入するか否かを判断する機能を備えている。なお、それぞれの機能の詳細については後述する。【００４８】
次に、サーバ３が備えるノードテーブル５、ジョブ管理テーブル６、およびジョブクラステーブル７のテーブル仕様についてそれぞれ詳細に説明する。【００４９】
〈ノードテーブル仕様〉
図６は、サーバ３が備えるノードテーブルの項目の一例を示す図である。図６に示すノードテーブルの項目に基づいて図５に示すノード２ａ，２ｂの管理が行われる。また、図７は図６に示す能力値および閾値のテーブルを示す図である。【００５０】
図６のノードテーブルの項目において、「ノード名」の項目には、いわゆるノードの名称が記録される。「ＣＰＵ平均使用率」の項目には、ジョブに割り当てられたＣＰＵの使用率の平均値が記録される。「ローカルＣＰＵ使用率」の項目には、ノードのローカルＣＰＵ使用率(１００−ＩＤＬＥ)が記録される。「能力値」の項目には、ＣＰＵ性能等のマシン仕様が相対的に数値化されて記録される。すなわち、「能力値」は図７に示すような性能に比例した値が設定され、「閾値」には「能力値」を反映した値が設定される。「状況」の項目には、ジョブの実行待ち、およびジョブの実行中などのマシン状況が記録される。図８は、本発明の分散処理管理装置に適用されるノードテーブルの一例を示す図である。この例では、ノード名がＮ１，Ｎ２，Ｎ３の３つのノードについてのノードテーブルが示されている。【００５１】
〈ジョブ管理テーブル仕様〉
図９は、サーバ３が備えるジョブ管理テーブルの項目の一例を示す図である。つまり、ジョブ管理テーブルはノードに投入するジョブの管理を行う。したがって、ジョブ管理テーブルにはジョブクラスに定義された多重度に合わせたテーブルが予め用意されていて、ジョブが多重実行される度にジョブ管理テーブルにジョブ情報が登録される。言い換えれば、多重度分のジョブ管理テーブルが確保されている。【００５２】
図９に示すジョブ管理テーブルの項目において、ジョブ名の項目にはジョブの名称が記録され、実行ノード名の項目には実行ノードの名称が記録され、クラス名の項目にはジョブクラス名が記録される。さらに、実行時間の項目には、対応するジョブの実行時間が記録され、進捗率の項目には対応するジョブの進捗率が記録される。図１０は、本発明の分散処理管理装置に適用されるジョブ管理テーブルの一例を示す図である。この例では、ノード名がＪ１およびＪ２の２つのノードについてのジョブ管理テーブルが示されている。【００５３】
〈ジョブクラステーブル仕様〉
図１１は、サーバ３が備えるジョブクラステーブルの項目の一例を示す図である。つまり、ジョブクラステーブルには投入するジョブのポリシーが登録される。図１１に示すジョブクラステーブルの項目において、クラス名の項目にはジョブのクラス名が記録され、優先順位の項目にはジョブの優先度が記録され、多重度の項目にはジョブの最大多重度が記録される。また、再投入限界値の項目には、ジョブの再投入における実行時間の閾値が記録される。したがって、この閾値を超えた場合にはジョブの再投入は行われないようにする。さらに、キャンセル限界値の項目にはジョブの切り替えの際の閾値が記録される。したがって、この閾値を超えた場合は優先度によるジョブの切り替えは行われないようにする。図１２は、本発明の分散処理管理装置に適用されるジョブクラステーブルの一例を示す図である。この例では、ジョブのクラス名がＡおよびＢの２つのジョブクラス名についてのジョブクラステーブルが示されている。【００５４】
次に、ノードへのジョブ投入の流れについて説明する。図１３は、本発明の分散処理管理装置におけるジョブ投入の流れを示すフローチャートである。図１３において、まずジョブが再投入されたか否かが判断され（Ｓ４１）、ジョブが再投入されていなければ（Ｓ４１、Ｎｏ）、図１０に示すようなジョブ管理テーブルにデータを作成し（Ｓ４２）、初期化処理を行った後に（Ｓ４３）、所望のノードに投入したジョブの実行を行う（Ｓ４４）。一方、ステップＳ４１でジョブが再投入されていれば（Ｓ４１、Ｙｅｓ）、図１０に示すジョブ管理テーブルにおける該当データの更新を行い（Ｓ４５）、所望のノードに投入したジョブの実行を行う（Ｓ４４）。このようにして、ジョブの投入を完了する。【００５５】
すなわち、ジョブの投入に当たっては、図１０に示すジョブ管理テーブルにジョブデータを登録する。また、ジョブの再投入を行う場合はジョブ管理テーブルに対して先に作られているテーブルの更新を行う。【００５６】
次に、ノード情報の取得について説明する。
〈ノード情報の取得１〉
図１４は、図５に示すサーバにおけるノード情報の取得の流れ其の１を示すフローチャートである。図１４のフローチャートにおいては、ノード側によるノード情報の通知１の処理と、サーバ側によるノード情報の取得１の処理が示されている。まず、ノード側が、ノード名およびマシンの仕様をノード開局通知としてサーバ側へ送信すると（Ｓ５１）、サーバ側は、ノード開局通知として、ノード名およびマシンの仕様の取得処理を行う（Ｓ５２）。さらに、サーバ側は、図８に示すようなノードテーブル内に既に登録済みのノード名があるか否かを判断する（Ｓ５３）。【００５７】
ここで、ノードテーブル内に登録済みのノード名がなければ（Ｓ５３、Ｎｏ）、ステップＳ５２に戻って、サーバ側は、ノード名およびマシンの仕様の取得処理を行うが、ノードテーブル内に既に登録済みのノード名があれば（Ｓ５３、Ｙｅｓ）、マシンの仕様から能力値を算出し（Ｓ５４）、図８に示すノードテーブルにノード名と能力値を登録する（Ｓ５５）。さらに、サーバ側は、図８に示すノードテーブルのＣＰＵ平均使用率、ローカルＣＰＵ使用率、および状況を初期化して閾値をクリアする（Ｓ５６）。【００５８】
つまり、ノードとなる計算機（ＰＣ）の電源投入時、または、ノード側の分散処理制御プログラムの開始時（つまり、ジョブ受付の開始時）において、図１４に示すようなノード情報の取得を行う。【００５９】
〈ノード情報の取得２〉
図１５は、図５に示す分散処理管理システムにおけるノード情報の取得の流れ其の２を示すフローチャートである。図１５のフローチャートにおいては、ノード側によるノード情報の取得２の処理と、サーバ側によるノード情報の取得２の処理が示されている。【００６０】
図１５において、ノード側は、ノード名、ローカルＣＰＵ使用時間、ＣＰＵ平均使用時間、および現在の進捗率をノード情報通知としてサーバ側へ送信する（Ｓ６１）。ノード側は、このようなノード情報を一定の時間間隔ごとにサーバ側へ通知する（Ｓ６２）。【００６１】
一方、サーバ側は、ノード側からノード情報の通知を受けると、ノード名に対応したＣＰＵ平均使用時間、ローカルＣＰＵ使用時間、および進捗率についてのノード情報取得処理を行い（Ｓ６３）、平均ＣＰＵ使用率およびローカルＣＰＵ使用率を算出して図８に示すようなノードテーブルの更新を行う（Ｓ６４）。さらに、サーバ側は、ジョブ実行時間の累積値と予想終了時間から現在の進捗率を算出する（Ｓ６５）。そして、ノードテーブルにおける進捗率の更新を行い（Ｓ６６）、ステップＳ６３に戻って前述の処理を繰り返す。【００６２】
なお、ＣＰＵ平均使用率とは、ＣＰＵ平均使用時間の過去一定期間の累積値を過去一定期間の総時間で割った値である。つまり、ＣＰＵ平均使用率とは、投入ジョブがあるノードのＣＰＵを使用している平均使用率である。また、ローカルＣＰＵ使用率とは、ローカルＣＰＵ使用時間の過去一定期間の累積値を過去一定期間の総時間で割った値である。つまり、ローカルＣＰＵ使用率とは、ローカルＣＰＵがジョブに使用されている平均使用率である。【００６３】
すなわち、図１５に示すノード情報の取得其の２の処理においては、ノード計算機でノード側の分散処理制御プログラムが動作している間は、常に一定間隔で処理状況がサーバへ伝達される。したがって、サーバ側はノード側からの情報に基づいてノードテーブルのＣＰＵ平均使用率やローカルＣＰＵ使用率を計算して進捗率を更新する。なお、ノード側の進捗率はサーバ側からジョブを依頼されていない場合はゼロである。【００６４】
次に、図５に示す分散処理管理装置（サーバ）が行うジョブの再投入判断について説明する。図１６は、ジョブの再投入判断の流れを示すフローチャートである。図１６において、サーバがジョブの再投入判断を行うとき、まず、図８に示すようなノードターブルから現在投入しているノードの次のノードにおけるレコード読み込む（Ｓ７１）。そして、読み込んでいるレコードが最終レコードであるか否かを判断し（Ｓ７２）、最終レコードである場合は（Ｓ７２、Ｙｅｓ）、あらかじめ設定された規定時間（例えば、１分間）処理を停止し（Ｓ７３）、ステップＳ７１に戻って、ノードテーブルから現在投入しているノードの次のノードにおけるレコード読み込み、前述のステップＳ７１以降の処理を繰り返す。【００６５】
また、ステップＳ７２で、読み込んだレコードが最終レコードでなければ（Ｓ７２、Ｎｏ）、現在のジョブ状況は実行中であるか否かを判断し（Ｓ７４）、ジョブを実行中であれば（Ｓ７４、Ｙｅｓ）、ＣＰＵ平均使用率は所定の閾値より小さいか否かを判断し（Ｓ７５）、ＣＰＵ平均使用率が所定の閾値より小さければ（Ｓ７５、Ｙｅｓ）、ジョブの多重投入処理を開始し（Ｓ７６）、ステップＳ７１に戻って前述の処理を繰り返す。なお、ステップＳ７４でジョブ状況がジョブの実行中でない場合（Ｓ７４、Ｎｏ）、およびステップＳ７５でＣＰＵ平均使用率が所定の閾値より大きい場合（Ｓ７５、Ｎｏ）についても、ステップＳ７１に戻って前述の処理を繰り返す。【００６６】
つまり、図１６に示すサーバによるジョブの再投入の判断では、サーバは図１０に示すジョブ管理テーブルの先頭からレコードを読み込み、読み込んだレコードがジョブ実行中のレコードであるならば、ＣＰＵ平均使用率が所定の閾値より小さいか否かを調べ、ＣＰＵ平均使用率＜閾値であるならば多重処理を開始する。また、ＣＰＵ平均使用率＜閾値が成立しない場合は次のレコードを調べる。このようにして最終レコードまで処理が完了したら、規定時間（例えば、１分間）処理を中断して先頭のレコードから再び処理を開始する。【００６７】
次に、サーバが行う多重実行処理の流れについて説明する。図１７は、分散処理管理装置（サーバ）が行う多重実行処理の流れを示すフローチャートである。図１７に示す多重実行処理の流れでは、多重実行処理の開始時点において対象となるノードテーブルは既知となっているものとする。【００６８】
図１７において、まず、サーバは、ノード名をキーにして図１０に示すようなジョブ管理テーブルを検索する（Ｓ８１）。次に、検索結果のジョブ管理テーブルのクラス名をキーにして、ジョブクラスを検索するための図１２に示すようなジョブクラステーブルから、ジョブの優先順位、多重度、再投入限界値を求める（Ｓ８２）。【００６９】
次に、ジョブの多重度分だけ、図１０に示すジョブ管理テーブルの各ジョブ情報から以下の４項目について計算を行う。なお、必要に応じて図８のノードテーブルを検索する。すなわち、ステップＳ８３において、サーバはジョブ管理テーブルに対して次の４項目の計算を行う。
（１）予測最短処理時間＝Ｍｉｎ（実行時間×（１００−進捗率）／進捗率）
（２）平均全体処理量＝Ａｖｅ（ノード処理能力×ＣＰＵ平均使用率×（予測最短処理時間＋実行時間））
（３）最大進捗率＝Ｍａｘ（進捗率）
（４）最小要求性能＝Ｍｉｎ（平均全体処理量／予測最短処理時間）【００７０】
なお、（４）項の最小要求性能とは、最短と予想された予測最短処理時間よりも早く処理を完了するために必要となる最小の性能要求のことであって、能力値×ＣＰＵ平均使用率を単位とする。【００７１】
次に、具体的な数値に基づいて上記の４項について計算を行ってみる。例えば、能力値＝０．８、ＣＰＵ平均使用率＝６０％、処理時間＝４時間、進捗率＝４０％の場合は、
（１）予測最短処理時間＝４[時間]×(１００−４０)／４０＝６[時間]
（２）平均全体処理量＝０．８×６０[%]×(６＋４)＝４８０
（３）最大進捗率＝４０[%]
（４）最小要求性能＝４８０／６＝８０【００７２】
つまり、能力値＝１．０、ローカルＣＰＵ使用率＝２０％以下（つまり、空きが８０％以上）のノードが上記の値に該当する。なお、複数ジョブが投入されていれば、（１）の予測最短処理時間は最小値を求め、（２）の全体処理量は平均値を求め、（３）の進捗率は最大値を求める。【００７３】
再び図１７のフローチャートに戻って、ステップＳ８３で計算した最大進捗率と図１２に示すようなジョブクラステーブルの再投入限界値とを比較し、最大進捗率が再投入限界値より小さくない場合は（最大進捗率＜再投入限界値でない場合）は（Ｓ８４、Ｎｏ）、多重投入を行わずに多重実行処理を終了とする。【００７４】
また、最大進捗率が再投入限界値より小さい場合においても（Ｓ８４、Ｙｅｓ）、多重度の空き(すなわち、ジョブ管理テーブルの空き)を判定し、ジョブクラステーブルの多重度を超えてしまう場合には（Ｓ８５、Ｎｏ）、多重投入を行わずに多重実行処理を終了する。【００７５】
一方、ステップＳ８５で、多重度(ジョブ管理テーブルの空き)を判定した結果、ジョブクラステーブルの多重度を超えない場合には（Ｓ８５、Ｙｅｓ）、最小要求性能＜能力値×（１００−ローカルＣＰＵ使用率）となるような空き実行ノードを要求(もしくは検索)する（Ｓ８６）。【００７６】
次に、検索結果で該当する空きノードがあるか否かを判定し（Ｓ８７）、条件に合う空きノードが無い場合は（Ｓ８７、Ｎｏ）、自ジョブ管理テーブル以外のジョブ管理テーブルに対して、以下の３つの条件全てを満足するジョブを検索する。なお、必要に応じて、ノードテーブルやジョブクラステーブルも検索する（Ｓ８８）。【００７７】
すなわち、ジョブ管理テーブルの検索処理においては、
（１）現在実行中のジョブより優先度の低いジョブ
（２）ジョブ進捗率がキャンセル限界値より低いジョブ
（３）実行ノードの能力値×ＣＰＵ平均使用率が最小要求性能を上回るジョブ
の３つの条件全てを満足するジョブを検索する。【００７８】
次に、上記３つの条件全てを満足する該当ジョブがあるか否かを判定し（Ｓ８９）、該当ジョブがなければ（Ｓ８９、Ｎｏ）、多重投入を行わずに多重実行処理を終了する。一方、上記３つの条件全てを満足する該当ジョブがあれば（Ｓ８９、Ｙｅｓ）、該当ジョブをキャンセルする（Ｓ９０）。【００７９】
また、ステップＳ８７の判定で条件に合う空きノードがある場合、または、ステップＳ９０で条件に合うノードが見つかった場合は、ジョブ管理テーブルの空き部分と実行依頼するノードテーブルおよび多重実行のジョブクラステーブルを通知して、ジョブの投入を行うか、またはジョブの投入を依頼する（Ｓ９１）。【００８０】
次に、分散処理管理装置（サーバ）が行うジョブキャンセルの処理の流れについて説明する。【００８１】
〈ノード側からのジョブキャンセル処理〉
図１８は、図５に示す分散処理管理システムにおいてノード側からのジョブキャンセル処理の流れを示すフローチャートである。ノード側のキャンセル要求の処理においては、ノード名およびジョブ名を付加してサーバ側へキャンセル要求の通知を行う（Ｓ１０１）。ノード側は、サーバ側に対してこのようキャンセルの通知を一定の時間間隔ごとに行う（Ｓ１０２）。【００８２】
一方、サーバ側のキャンセル受付処理においては、サーバ側はノード側からのキャンセル要求を受付けると、キャンセル情報の取得処理を行い（Ｓ１０３）、ノードテーブルのＣＰＵ平均使用時間（使用率）、ローカルＣＰＵ使用時間（使用率）、進捗率、および状況をクリアする（Ｓ１０４）。さらに、ジョブ管理テーブルからノード名、ジョブ名に対応するデータを削除する（Ｓ１０５）。但し、多重ジョブが投入されているノードでキャンセルが要求された場合は、ジョブ管理テーブルから削除するのは、キャンセルが要求されたノードで実行されていたジョブのみであって、他のノードで実行されている多重ジョブは削除されない。【００８３】
つまり、ノード側からのジョブキャンセル処理においては、ノードは本来のユーザの都合で分散処理プログラムを停止してユーザの占有使用状態に戻すことができる。このとき実行していた分散処理プログラムはキャンセルされる。また、サーバ側ではキャンセル要求を受けてノードテーブル、ジョブ管理テーブルから対応するノード情報とジョブ情報を消去する。なお、ノード側の一定時間のＷＡＩＴ処理はサーバのキャンセル処理を確実に行うための待ち時間である。しかし、サーバ側がキャンセル要求に対してキャンセル完了の応答を返す場合は、一定時間ＷＡＩＴ処理は不用である。【００８４】
〈サーバ側からの終了およびジョブキャンセル処理〉
図１９は、図５に示す分散処理管理システムにおいてサーバ側からの終了およびジョブキャンセル処理の流れを示すフローチャートである。図１９において、ノード側のジョブ終了ノードは、サーバ側に対してジョブ終了通知および結果転送を行うとき、まず、ジョブ終了でノード名、実行終了ジョブ名、および終了状況を終了メッセージとしてサーバ側へ送出する（Ｓ１１１）。【００８５】
すると、サーバ側の終了・キャンセル処理では、ノード側からノード名、ジョブ名、および実行状態の取得処理を行い（Ｓ１１２）、ジョブは正常に終了したか否かを判断する（Ｓ１１３）。ここで、サーバ側がジョブは正常に終了したと判断すれば（Ｓ１１３、Ｙｅｓ）、さらに、多重処理のジョブがあるか否かを判断する（Ｓ１１４）。ここで、多重処理のジョブがなければ（Ｓ１１４、Ｎｏ）、結果情報の取得処理を行い（Ｓ１１５）、多重処理のジョブがあれば（Ｓ１１４、Ｙｅｓ）、同一ジョブ名の他のノードへキャンセル要求を送出した後に（Ｓ１１６）、結果情報の取得処理を行う（Ｓ１１５）。【００８６】
そして、サーバは、ノードテーブルに対応するノードのＣＰＵ平均使用時間（使用率）、ローカルＣＰＵ使用時間（使用率）、進捗率、および状況をクリアする（Ｓ１１７）。さらに、ジョブ管理テーブルからノード名、ジョブ名の対応するノード情報を削除する（Ｓ１１８）。なお、ステップＳ１１３で、サーバ側がジョブは正常に終了していないと判断すれば（Ｓ１１３、Ｎｏ）、サーバは、直接、ノードテーブルに対応するノードのＣＰＵ平均使用時間（使用率）、ローカルＣＰＵ使用時間（使用率）、進捗率、および状況をクリアし（Ｓ１１７）。さらに、ジョブ管理テーブルからノード名およびジョブ名に対応するノード情報を削除する（Ｓ１１８）。【００８７】
一方、ノード側の終了ノードは、ステップＳ１１３で、サーバがジョブは正常に終了していないと判断した場合（Ｓ１１３、Ｎｏでキャンセルの場合）、およびサーバがジョブは正常に終了したと判断した場合（Ｓ１１３、Ｙｅｓで転送要求を行った場合）は、サーバから該当する応答要求を受け取る（Ｓ１１９）。【００８８】
そして、ノード側は、サーバ側から取得した応答要求がキャンセル要求であるか否かを判断し（Ｓ１２０）、応答要求がキャンセル要求ではない場合は（Ｓ１２０、Ｎｏ）、サーバ側に対して結果情報の転送処理を行い（Ｓ１２１）、ジョブの終了処理を行う（Ｓ１２２）。また、応答要求がキャンセル要求である場合は（Ｓ１２０、Ｙｅｓ）、直ちに、ジョブの終了処理を行う（Ｓ１２２）。【００８９】
また、ノード側における多重実行でジョブ未終了ノードは、サーバからのキャンセル受付処理において、ステップＳ１１６で同一ジョブ名の他のノードへキャンセル要求を送出したときに（Ｓ１１６）、サーバからキャンセル要求を受け、サーバからの応答処理を行う（Ｓ１２３）。そして、ノード側は、サーバから取得した応答要求がキャンセル要求であるか否かを判断し（Ｓ１２４）、応答要求がキャンセル要求ではない場合は（Ｓ１２４、Ｎｏ）、サーバ側に対して結果情報の転送処理を行い（Ｓ１２５）、ジョブの終了処理を行う（Ｓ１２６）。また、また、応答要求がキャンセル要求である場合は（Ｓ１２４、Ｙｅｓ）、直ちに、ジョブの終了処理を行う（Ｓ１２６）。【００９０】
すなわち、サーバ側からの終了およびキャンセル処理においては、ジョブが終了した場合は、ノードはサーバ側へ終了の情報を通知する。また、サーバは、そのジョブが多重実行されていないかを確認して、終了したジョブのデータをノードから収集（ハーベスト）する。一方、多重実行のジョブを処理している場合は、サーバは、他のノードを停止（ジョブキャンセル）させる。さらに、サーバ側の都合でジョブをキャンセルする場合も、同様にして、同じジョブ名を持つ多重実行ジョブは同時にキャンセルされ、その多重ジョブを実行していたノードも同時に開放される。【００９１】
また、サーバが多重ジョブを投入するために優先度の低いジョブが投入されているノードをキャンセルする場合も、サーバからのキャンセルに対して、ノードはサーバからのキャンセル受付の処理を行い、自ノードを開放する。【００９２】
以上に説明した本発明の実施の形態において、適宜説明された各フローチャートの動作をコンピュータに実行させる分散処理管理プログラムとして、コンピュータにより読取り可能な記録媒体に記憶させることによって、分散処理管理装置を構成するコンピュータに分散処理管理方法を実行させることが可能となる。なお、本発明において、上記コンピュータにより読取り可能な記録媒体は、ＣＤ−ＲＯＭやフレキシブルディスク、ＤＶＤディスク、光磁気ディスク、ＩＣカード等の可搬型記憶媒体や、コンピュータプログラムを保持するデータベース、或いは、他のコンピュータ並びにそのデータベースや、更に回線上の伝送媒体をも含むものである。
【産業上の利用可能性】
【００９３】
以上説明したように、本発明によれば、グリッド計算機環境のような個々の実行処理計算機の処理能力が著しく異なり、また、時間的にも激しく変化する分散処理環境においても、各処理の実行から完了までの時間（ＴＡＴ）を最小化でき、かつ、資源量や処理の進行度によって、管理者が分散環境の特性を考慮して二重（多重）実行の方針を決定できる。そのため、全体のＴＡＴを改善すると共に計算機資源の有効な利用が可能となる。
【図１】
2006100752.tif 000002
【図２】
2006100752.tif 000003
【図３】
2006100752.tif 000004
【図４】
2006100752.tif 000005
【図５】
2006100752.tif 000006
【図６】
2006100752.tif 000007
【図７】
2006100752.tif 000008
【図８】
2006100752.tif 000009
【図９】
2006100752.tif 000010
【図１０】
2006100752.tif 000011
【図１１】
2006100752.tif 000012
【図１２】
2006100752.tif 000013
【図１３】
2006100752.tif 000014
【図１４】
2006100752.tif 000015
【図１５】
2006100752.tif 000016
【図１６】
2006100752.tif 000017
【図１７】
2006100752.tif 000018
【図１８】
2006100752.tif 000019
【図１９】
2006100752.tif 000020
【図２０】
2006100752.tif 000021
【図２１】
2006100752.tif 000022
【手続補正書】
【提出日】平成19年6月27日(2007.6.27)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
複数のノードに接続されることができ、各ノードにジョブを投入することができると共に該ジョブの実行管理を行うことができる分散処理管理装置であって、
第１ジョブを投入した第１ノードの第１リソース関連情報を取得する第１リソース関連情報取得部と、
前記第１ジョブを投入していない第２ノードの第２リソース関連情報を取得する第２リソース関連情報取得部と、
前記第１リソース関連情報取得部により取得された第１リソース関連情報と、前記第２リソース関連情報取得部により取得された第２リソース関連情報とに基づいて、前記第１ノードに投入した前記第１ジョブを前記第２ノードに投入するか否かについての判断を行うジョブ再投入判断部と
を備えてなる分散処理管理装置。
【請求項２】
請求項１に記載の分散処理管理装置において、
前記ジョブ再投入判断部は、前記第１ジョブの投入を肯定する判断において、前記第１リソース関連情報に基づいて、前記第１ノードの前記第１ジョブの実行に対するＣＰＵ使用率が所定の閾値を下回る場合を判断することを特徴とする分散処理管理装置。
【請求項３】
複数のノードにおける各ノードにジョブを投入するとともに該ジョブの実行管理を行う分散処理管理方法であって、
第１ジョブを投入した第１ノードの第１リソース関連情報を取得する第１リソース関連情報取得ステップと、
前記第１ジョブを投入していない第２ノードの第２リソース関連情報を取得する第２リソース関連情報取得ステップと、
前記第１リソース関連情報取得ステップにより取得された前記第１リソース関連情報と、前記第２リソース関連情報取得ステップにより取得された前記第２リソース関連情報とに基づいて、前記第１ノードに投入した前記第１ジョブを前記第２ノードに投入するか否かについての判断を行うジョブ再投入判断ステップと
を備えてなる分散処理管理方法。
【請求項４】
複数のノードにおける各ノードにジョブを投入するとともに該ジョブの実行管理を行うことをコンピュータに実行させる分散処理管理プログラムであって、
第１ジョブを投入した第１ノードの第１リソース関連情報を取得する第１リソース関連情報取得ステップと、
前記第１ジョブを投入していない第２ノードの第２リソース関連情報を取得する第２リソース関連情報取得ステップと、
前記第１リソース関連情報取得ステップにより取得された前記第１リソース関連情報と、前記第２リソース関連情報取得ステップにより取得された前記第２リソース関連情報とに基づいて、前記第１ノードに投入した前記第１ジョブを前記第２ノードに投入するか否かについての判断を行うジョブ再投入判断ステップと
をコンピュータに実行させる分散処理管理プログラム。
【請求項５】
請求項４に記載の分散処理管理プログラムにおいて、
前記ジョブ再投入判断ステップは、前記第１ジョブの投入を肯定する判断において、前記第１リソース関連情報に基づいて、前記第１ノードの前記第１ジョブの実行に対するＣＰＵ使用率が所定の閾値を下回る場合を判断することを特徴とする分散処理管理プログラム。
【国際調査報告】
2006100752.tif 000023
2006100752.tif 000024
2006100752.tif 000025
2006100752.tif 000026