JP5018133B2 - ジョブ管理装置、クラスタシステム、およびジョブ管理プログラム - Google Patents

Description

本発明は複数の計算ノードにジョブの実行を指示するジョブ管理装置、そのジョブ管理装置でジョブを管理するクラスタシステム、およびジョブ管理装置の機能をコンピュータに実行させるためのジョブ管理プログラムに関し、特に機能停止に対する高信頼化を図ったジョブ管理装置、およびそのジョブ管理装置でジョブを管理するクラスタシステム、および機能停止に対する高信頼化を図ったジョブ管理プログラムに関する。

高度な科学技術系の計算を行う場合、複数のコンピュータを１つに束ねて、１つの計算機システムとして運用する。以下、このような計算機システムを「クラスタシステム」と呼び、計算機システムを構成するコンピュータを「ノード」と呼ぶ。利用者は他のコンピュータを用い、クラスタシステムに対して計算依頼を入力する。以下、このような計算依頼に基づいて実行される処理を「ジョブ」と呼ぶ。なお、ジョブには、複数のノードで並列に実行させる「並列ジョブ」と、単一のノード上の１つのプロセスで実行させる「逐次ジョブ」とがある。

ジョブを受け取ったクラスタシステムでは、入力されたジョブを、１台または複数台のノードで実行させる必要がある。そのため、ジョブのノードへの割り振りや、各ノードでのジョブの実行状況を管理するためのノードが用意される。以下、このノードを管理ノードと呼び、管理ノード以外のノードを計算ノードと呼ぶ。

クラスタシステムでは、計算ノードの割り当てや計算ノードへの実況状況を管理ノードが把握している。そのため、管理ノードがダウン（障害などによる機能停止）してしまうと、ジョブの割り当てや実況状況の把握が出来なくなるという問題がある。

ここで、管理ノードのダウンを想定した高信頼化機能がない場合、管理ノードがダウンするとジョブが存在していたという情報までも失われてしまう。このとき、クラスタシステムへのジョブの再投入が必要となる。また、ジョブを再投入する前に計算ノードで稼働中のジョブを終了させる必要がある。ところが、高信頼化機能が無いとどのようなジョブが依頼されていたのかを知る術がない。そのため、すべての計算ノードの再起動が必要となる。

そこで、高信頼化技術が利用される。従来の高信頼化技術では、ジョブの状態をジョブデータベース（ＤＢ）上にファイルで保存しておく。ジョブＤＢは、ハードディスクに構築される。そして、管理ノードがダウンしたときは、管理ノードの起動時にジョブＤＢからジョブ状態が記録されたファイルを読み込むことで、処理中のジョブを認識する。

ところで、ジョブの状態には２段階の状態がある。すなわち、他のコンピュータからの依頼状態（ジョブ投入状態）と、計算ノードに割り当てて実行させているジョブの状態（ジョブ実行状態）である。

ジョブＤＢにジョブ投入状態のみを管理していた場合、管理ノードがダウンした後も、実行しなければならないジョブは認識できる。そのため、使用者からのジョブの再投入は不要である。ただし、各ジョブがどの様な状況で実行されているのかが不明である。そのため、計算ノードで実行しているジョブを一端終了させ、最初から実行させる必要がある。

このように、ジョブを最初から実行したのでは、システムの運用効率が低下してしまう。しかも、科学技術計算では、計算に長時間を要するジョブも存在し、そのようなジョブを最初から実行し直すのは非効率である。

そこで、ジョブＤＢにジョブ投入状態とジョブ実行状態とをハードディスク上のファイルで管理することが行われる。この場合、管理ノードがダウンした後も、ジョブ投入状態に加えてジョブ実行状態を認識できる。そのため、ジョブを再投入する必要がないと共に、計算ノードで実行中のジョブをそのまま継続できる。

これにより、管理ノードがダウンしても、ジョブを最初から実行し直す必要はなくなる。ただし、ジョブの実行状態を保存するには、情報反映の遅延という課題が残る。
すなわち、通常のＯＳ（オペレーティングシステム）ではファイルへ情報を書き込んでも、システムの高速化のためにメモリ上で書き込むのみである。そして、その後の所定のタイミングで更新されたファイルの内容がディスクに書き込まれる。このように、即座にディスクへは反映されないため、情報反映に常に遅延が発生する。その結果、ジョブの実行状態が最新状態とならず、高信頼化の妨げになってしまう。

なお、書き込み処理の遅延対策として、メモリ上でのファイル書き込みと同時にディスクへ情報反映を即座に実施することが考えられる。ただし、この場合、メモリへの書き込みよりハードディスクへの書き込みが遥かに低速なため、システム処理の遅延につながってしまう。

そこで、ジョブＤＢを用いずに高信頼化する技術が考えられている。たとえば、管理ノードが保有するジョブの実行状態や環境設定を、計算ノードにも配置しておく。そして、管理ノードがダウンした場合、計算ノードの１つが管理ノードに昇格する。そして、管理ノードを兼ねることとなった計算ノードが、他の計算ノードから実行状態や環境設定を収集し、管理ノードの機能を実行する（たとえば、特許文献１参照）。
特開平６−９６０４１号公報

しかし、特許文献１に示した高信頼化技術においても、以下のような問題がある。
（１）並列ジョブへの対応が考慮されていない。
並列ジョブでは、複数の計算ノードが連携してジョブを実行する必要がある。そのために、並列ジョブを実行する複数の計算ノードの１つがジョブマスタとなり、ジョブの実行状況の詳細を管理する。どの計算ノードがジョブマスタなのかといった並列ジョブ特有の情報を復旧できるようにしないと、並列ジョブに対しては対応が難しい。

（２）ジョブのすべての情報を計算ノード側で保存する必要がある。
ジョブの実行に必要な情報はすべて計算ノード側で保存する必要があり、場合によっては、膨大な情報を転送しなければならない場合がある。

（３）２重ダウンに対応できない。
管理ノードと同時に一部の計算ノードが停止してしまうと、停止した計算ノードで実行されていたジョブの存在が無くなってしまう事になる。ジョブの存在自体が無くなってしまうと、該当するジョブをシステム外部から再投入する必要が生じる。そのため、システム外部で、投入したジョブが失われていないかどうかを確認する必要が生じる。すなわち、システム外部で、投入したジョブが存続しているか否かを管理しない限り、失われたジョブを再生することができず、クラスタシステムの信頼性が損なわれていた。

（４）すべての計算ノードへアクセスが必要である。
情報を集めるために、すべての計算ノードへアクセスする必要があり、通信処理が非効率である。特に、科学技術計算に用いるシステムでは、ノード数が増加傾向にあり、すべての計算ノードの管理情報を１つの計算ノードに転送するには、膨大な量のデータ転送が発生する。

（５）計算ノードがダウンした場合の再実行ができない。
計算ノードだけで情報を保護しようとしているため、計算ノードがダウンしてしまうと、実行していたジョブの再実行をすることもできない。

これらの問題のうち、少しでも多くの問題を解決することで、クラスタシステムを高信頼化させながら、処理効率の低下を防ぐことができる。
本発明はこのような点に鑑みてなされたものであり、効率的な処理によって管理ノードの高信頼化を図ることができるジョブ管理装置、クラスタシステム、およびジョブ管理プログラムを提供することを目的とする。

本発明では上記課題を解決するために、図１に示すようなクラスタシステムが提供される。このクラスタシステムは、管理ノード１、ストレージデバイス２、および複数の計算ノード３，４で構成され、ジョブ投入装置５から投入されたジョブ実行依頼に応じてジョブを実行する。なお、管理ノード１は、複数の計算ノードにジョブの実行を指示するジョブ管理装置として機能する。

管理ノード１は、ジョブＤＢ１ａ、ジョブ実行依頼受付手段１ｂ、ジョブ実行指示手段１ｃ、およびジョブＤＢ再構築手段１ｄを有する。ジョブＤＢ１ａは、メインメモリ内に設けられ、ジョブ毎のジョブ情報を記憶する。ジョブ実行依頼受付手段１ｂは、ジョブ実行依頼が入力されると、ジョブ実行依頼の内容、依頼されたジョブのジョブＩＤ、およびジョブ実行依頼の投入元の識別情報を含むジョブ投入情報２ａ，１ａａをストレージデバイス２とジョブＤＢ１ａとに格納する。ジョブ実行指示手段１ｃは、ジョブ実行依頼受付手段１ｂが受け付けたジョブ実行依頼の割り当て先となる１台以上の計算ノードをジョブ被配置計算ノードに決定し、ジョブ被配置計算ノードに対してジョブの実行に使用すべき資源を示す実行資源情報３ａａ，３ａｂ，４ａａを付加したジョブ実行指示を送信し、ジョブＩＤに対応付けて、ジョブ被配置計算ノードの一覧を含むジョブ配置情報１ａｂとジョブ被配置計算ノードそれぞれの実行資源情報１ａｃ，１ａｄとをジョブＤＢ１ａに格納し、ジョブＩＤに対応付けてジョブ配置情報２ｂをストレージデバイス２に格納する。ジョブＤＢ再構築手段１ｄは、再起動処理によってジョブＤＢ１ａの内容が失われた場合、ストレージデバイス２からジョブ投入情報２ａとジョブ配置情報２ｂとを収集し、ジョブ被配置計算ノードから実行資源情報３ａａ，３ａｂを収集し、ジョブＤＢ１ａ内にジョブ情報を再構築する。

このようなクラスタシステムによれば、ジョブ投入装置５からジョブ実行依頼が入力されると、ジョブ実行依頼受付手段１ｂによりジョブ実行依頼の内容、依頼されたジョブのジョブＩＤ、およびジョブ実行依頼の投入元の識別情報を含むジョブ投入情報２ａ，１ａａがストレージデバイス２とジョブＤＢ１ａとに格納される。次に、ジョブ実行指示手段１ｃにより、ジョブ実行依頼受付手段１ｂが受け付けたジョブ実行依頼の割り当て先となる１台以上の計算ノードがジョブ被配置計算ノードに決定され、ジョブ被配置計算ノードに対してジョブの実行に使用すべき資源を示す実行資源情報３ａａ，３ａｂ，４ａａを付加したジョブ実行指示が送信される。また、ジョブ実行指示手段１ｃにより、ジョブＩＤに対応付けて、ジョブ被配置計算ノードの一覧を含むジョブ配置情報１ａｂとジョブ被配置計算ノードそれぞれの実行資源情報１ａｃ，１ａｄとがジョブＤＢ１ａに格納され、ジョブＩＤに対応付けてジョブ配置情報２ｂがストレージデバイス２に格納される。そして、再起動処理によってジョブＤＢ１ａの内容が失われた場合、ジョブＤＢ再構築手段１ｄにより、ストレージデバイス２からジョブ投入情報２ａとジョブ配置情報２ｂとが収集され、ジョブ被配置計算ノードから実行資源情報３ａａ，３ａｂが収集され、ジョブＤＢ１ａ内にジョブ情報が再構築される。

本発明では、ジョブ投入情報とジョブ配置情報とをストレージデバイスに格納しておき、実行資源情報を計算ノードに渡しておくようにしたため、再起動処理によりジョブＤＢの内容が失われても、それらの情報を収集することでジョブ情報の再構築が可能となる。

以下、本発明の実施の形態を図面を参照して説明する。
図１は、発明の概要を示す図である。図１に示すクラスタシステムは、管理ノード１、ストレージデバイス２、および複数の計算ノード３，４で構成され、ジョブ投入装置５から投入されたジョブ実行依頼に応じてジョブを実行する。

ストレージデバイス２は、管理ノード１に接続されており、ジョブＩＤに対応付けられたジョブ投入情報２ａとジョブ配置情報２ｂとを記憶する。たとえば、ジョブ投入情報２ａとジョブ配置情報２ｂとは、それぞれが１つのファイルとしてストレージデバイス２に格納される。

計算ノード３，４は、管理ノード１からのジョブ実行指示に従って、ジョブを実行する。なお、実行指示で示されたジョブが並列ジョブ６であれば、２台の計算ノード３，４が協働してその並列ジョブ６を実行する。並列ジョブ６を実行する場合、一方の計算ノード（図１の例では計算ノード３）がジョブマスタノードとして機能し、他方の計算ノード（図１の例では計算ノード４）がジョブスレーブノードとして機能する。

また、計算ノード３，４は、それぞれのメインメモリ内にジョブＤＢ３ａ，４ａを有している。そして、計算ノード３は、管理ノード１から渡された実行資源情報３ａａ，３ａｂを、ジョブＤＢ３ａ内に記憶する。このとき、ジョブマスタノードである計算ノード３には、計算ノード３自身の実行資源情報３ａａに加え、ジョブスレーブノードである計算ノード４の実行資源情報３ａｂも同時に渡される。同様に、計算ノード４は、管理ノード１から渡された実行資源情報４ａａを、ジョブＤＢ４ａ内に記憶する。この際、ジョブスレーブノードである計算ノード４に渡されるのは、計算ノード４自身の実行資源情報４ａａである。

そして、管理ノード１から実行資源情報の収集依頼を受け取ると、各計算ノード３，４は、ジョブＤＢ３ａ，４ａ内の実行資源情報を管理ノード１に送信する。この際、並列ジョブ６のジョブマスタノードである計算ノード３は、並列ジョブ６を実行するすべての計算ノードに関する実行資源情報３ａａ，３ａｂを管理ノード１に送信する。一方、並列ジョブ６のジョブスレーブノードである計算ノード４は、実行資源情報の収集依頼を無視し、実行資源情報の送信を行わない。

管理ノード１は、ジョブＤＢ１ａ、ジョブ実行依頼受付手段１ｂ、ジョブ実行指示手段１ｃ、およびジョブＤＢ再構築手段１ｄを有する。
ジョブＤＢ１ａは、メインメモリ内に設けられ、ジョブ毎のジョブ情報を記憶する。ジョブ情報は、ジョブ投入情報１ａａ、ジョブ配置情報１ａｂ、およびジョブを実行する計算ノードにおいてジョブの実行に使用する資源を示す実行資源情報１ａｃ，１ａｄが含まれる。

ジョブ実行依頼受付手段１ｂは、ジョブ投入装置５からジョブ実行依頼が入力されると、ジョブ実行依頼の内容、依頼されたジョブのジョブＩＤ、およびジョブ実行依頼の投入元の識別情報を含むジョブ投入情報２ａ，１ａａをストレージデバイス２とジョブＤＢ１ａとに格納する。

ジョブ実行指示手段１ｃは、ジョブ実行依頼受付手段１ｂが受け付けたジョブ実行依頼の割り当て先となる１台以上の計算ノードをジョブ被配置計算ノードに決定する。なお、依頼されたジョブが並列ジョブであれば、複数の計算ノードがジョブ被配置計算ノードとして決定される。その後、ジョブ実行指示手段１ｃは、ジョブ被配置計算ノードに対してジョブの実行に使用すべき資源を示す実行資源情報３ａａ，３ａｂ，４ａａを付加したジョブ実行指示を送信する。また、ジョブ実行指示手段１ｃは、ジョブＩＤに対応付けて、ジョブ被配置計算ノードの一覧を含むジョブ配置情報１ａｂとジョブ被配置計算ノードそれぞれの実行資源情報１ａｃ，１ａｄとをジョブＤＢ１ａに格納する。さらに、ジョブ実行指示手段１ｃは、ジョブＩＤに対応付けてジョブ配置情報２ｂをストレージデバイス２に格納する。

ジョブＤＢ再構築手段１ｄは、再起動処理によってジョブＤＢ１ａの内容が失われた場合、ストレージデバイス２からジョブ投入情報２ａとジョブ配置情報２ｂとを収集する。さらに、ジョブＤＢ再構築手段１ｄは、ジョブ被配置計算ノードから実行資源情報３ａａ，３ａｂを収集する。そして、ジョブＤＢ再構築手段１ｄは、収集したジョブ投入情報２ａ、ジョブ配置情報２ｂ、および実行資源情報３ａａ，３ａｂによってジョブＤＢ１ａ内にジョブ情報を再構築する。

このようなクラスタシステムによれば、ジョブ投入装置５からジョブ実行依頼が入力されると、ジョブ実行依頼受付手段１ｂにより、ジョブ実行依頼の内容、依頼されたジョブのジョブＩＤ、およびジョブ実行依頼の投入元の識別情報を含むジョブ投入情報２ａ，１ａａがストレージデバイス２とジョブＤＢ１ａとに格納される。

次に、ジョブ実行指示手段１ｃにより、ジョブ実行依頼受付手段１ｂが受け付けたジョブ実行依頼の割り当て先となる１台以上の計算ノードがジョブ被配置計算ノードに決定され、ジョブ被配置計算ノードに対してジョブの実行に使用すべき資源を示す実行資源情報３ａａ，３ａｂ，４ａａを付加したジョブ実行指示が送信される。また、ジョブ実行指示手段１ｃにより、ジョブＩＤに対応付けて、ジョブ被配置計算ノードの一覧を含むジョブ配置情報１ａｂとジョブ被配置計算ノードそれぞれの実行資源情報１ａｃ，１ａｄとがジョブＤＢ１ａに格納され、ジョブＩＤに対応付けてジョブ配置情報２ｂがストレージデバイス２に格納される。

その後、管理ノード１に障害が発生すると、管理ノード１の再起動処理が行われる。管理ノード１が再起動されると、ジョブＤＢ１ａの内容が失われる。すると、ジョブＤＢ再構築手段１ｄにより、ストレージデバイス２からジョブ投入情報２ａとジョブ配置情報２ｂとが収集され、ジョブ配置情報２ｂに示されたジョブ被配置計算ノードから実行資源情報３ａａ，３ａｂが収集され、ジョブＤＢ１ａ内にジョブ情報が再構築される。

このようにして、管理ノード１の高信頼化を効率的な処理によって実現できる。すなわち、ジョブ投入情報２ａとジョブ配置情報２ｂとは、管理ノード１に接続されたストレージデバイス２に記憶される。ジョブ投入情報２ａとジョブ配置情報２ｂとの書き込みは、ジョブ実行依頼を受け付けたときと、計算ノード３，４へのジョブ実行指示を送信したときに行えばよい。しかも、実行資源情報を含めてストレージデバイス２に格納する場合に比べて、書き込むべき情報の量が少ない。そのため、ストレージデバイス２への書き込み遅延を最小限に抑えることができる。

さらに、実行資源情報の複製が計算ノード３，４で管理される。その結果、管理ノード１がダウンしたときに、実行資源情報を計算ノード３，４から収集できる。
ところで、本発明を特許文献１記載の発明（特開平６−９６０４１号公報）と比較したとき、本発明では一部の情報をストレージデバイス２に格納している点が大きく異なる。すなわち、本発明に係るクラスタシステムは、並列ジョブにも適用可能な構成となっている。並列ジョブに適用するには、並列ジョブがどの計算ノードに割り当てたのかを認識している必要がある。特許文献１の請求項３を参照すると、システム上で共有されるデータに関しては、複写が各計算機に配置される。すると、管理ノードがダウンした際に、その情報を収集する際に、膨大な量の無駄が生じることとなる。最近のクラスタシステムでは、数百台あるいはそれ以上のノードが接続されることがある。それらのノードすべてから共有の情報を収集したのでは、通信の混雑を招き管理ノードの運用再開を遅延させる原因となる。

本発明では、ジョブ投入情報２ａやジョブ配置情報２ｂといった情報（計算ノード固有はなくシステム管理上共有すべき情報）は、ストレージデバイス２に保存しているため、情報収集の際の通信負荷が軽減される。しかも、ストレージデバイス２に保存する情報を最小限の情報量に抑えているため、情報の書き込み遅延による信頼性低下も抑えられる。

なお、ストレージデバイス２に記憶されるジョブ投入情報２ａやジョブ配置情報２ｂは、ジョブの投入・終了に必要なデータである。これらの情報は実行中には不要である。すなわち、これらの情報を計算ノードに持たせなくても、ジョブの実行に悪影響はない。しかも、これらの情報をメインメモリに記憶させずに済むことで、メモリ資源の有効活用も図れる。

また、ジョブ投入情報２ａとジョブ配置情報２ｂとをストレージデバイス２に格納するため、管理ノードと計算ノードが同時に停止しても、ジョブの存在自体を忘れることがなくなるというさらなる効果を有する。すなわち、ジョブ投入装置５からのジョブ実行依頼を再度入力しなくても、ジョブを最初から実行することが可能である。

さらに、本発明では、並列ジョブのジョブマスタノードに対してジョブスレーブノードの分も含めて実行資源情報を渡す。そして、管理ノード１を再起動した場合には、ジョブマスタノードからのみ実行資源情報を収集する。これにより、情報収集の際のデータ通信回数を削減することができる。

すなわち、並列ジョブの場合、複数の計算ノードに跨った情報を管理する必要がある。そのための簡単な方法は、ジョブ全体の情報を関連する全計算ノードに送ることである。しかし、管理ノード１が再立ち上げしてきた場合には、全部の計算ノードから情報を収集するのでは、非効率である。そのため、本発明ではジョブ内の複数の計算ノードからジョブマスタノードを決めておき、ジョブの実行に必要な情報を１つにまとめておく。これにより、高信頼化処理時にはジョブマスタノードのみから情報を取得して、管理ノード１のジョブＤＢ１ａの再構築が可能となる。その結果、情報収集の際の通信回数を削減することができる。

しかも、管理ノード１がダウンした場合、一刻も早い管理ノード１の復旧が望まれる。そのため、通信回数を削減することによる管理ノード１の復旧の迅速化は、高信頼化処理にとって非常に重要である。

次に、本実施の形態の詳細を説明する。
［第１の実施の形態］
図２は、本実施の形態のクラスタシステム構成例を示す図である。本実施の形態に係るクラスタシステムは、１台の管理ノード１００と複数の計算ノード２００，３００，４００，５００，６００で構成されている。

管理ノード１００は、クラスタシステムに対して依頼されたジョブを管理する。ジョブの実行依頼は、管理ノード１００にネットワーク２２を介して接続されたジョブ投入装置３０から送られる。また、管理ノード１００は、ストレージデバイス１１０を有している。ストレージデバイス１１０は、依頼されたジョブの内容を記憶する記憶装置である。ストレージデバイス１１０としては、ハードディスク装置などの不揮発性の記憶媒体が使用される。

ジョブ投入装置３０は、クラスタシステムの利用者がジョブの投入に使用するコンピュータである。
複数の計算ノード２００，３００，４００，５００，６００は、ネットワーク２１を介して互いに接続されていると共に、管理ノード１００に接続されている。計算ノード２００，３００，４００，５００，６００は、管理ノード１００によって割り当てられたジョブを実行する。

本実施の形態では、管理ノード１００と計算ノード２００，３００，４００，５００，６００とは、それぞれマルチプロセッサのコンピュータである。
図３は、本実施の形態に用いる管理ノードのハードウェア構成例を示す図である。管理ノード１００は、複数のＣＰＵ（Central Processing Unit）１０１ａ，１０１ｂ，・・・によって装置全体が制御されている。ＣＰＵ１０１，１０１ｂ，・・・には、バス１０９を介してＲＡＭ（Random Access Memory）１０２、ハードディスクドライブ（ＨＤＤ:Hard Disk Drive）１０３、グラフィック処理装置１０４、入力インタフェース１０５、複数の通信インタフェース１０６，１０７、およびストレージデバイスインタフェース１０８が接続されている。

ＲＡＭ１０２には、メインメモリとして使用され、ＣＰＵ１０１ａ，１０１ｂ，・・・に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０２には、ＣＰＵ１０１ａ，１０１ｂ，・・・による処理に必要な各種データが格納される。ＨＤＤ１０３には、ＯＳやアプリケーションプログラムが格納される。

グラフィック処理装置１０４には、モニタ１１が接続されている。グラフィック処理装置１０４は、ＣＰＵ１０１ａ，１０１ｂ，・・・からの命令に従って、画像をモニタ１１の画面に表示させる。入力インタフェース１０５には、キーボード１２とマウス１３とが接続されている。入力インタフェース１０５は、キーボード１２やマウス１３から送られてくる信号を、バス１０９を介してＣＰＵ１０１ａ，１０１ｂ，・・・に送信する。

通信インタフェース１０６は、ネットワーク２１に接続されている。通信インタフェース１０６は、ネットワーク２１を介して、計算ノードとの間でデータの送受信を行う。
通信インタフェース１０７は、ネットワーク２２に接続されている。通信インタフェース１０７は、ネットワーク２２を介して、ジョブ投入装置３０との間でデータの送受信を行う。

ストレージデバイスインタフェース１０８は、ストレージデバイス１１０に対するデータの書き込みや、ストレージデバイス１１０からのデータの読み出しを行うための通信インタフェースである。

以上のようなハードウェア構成によって、管理ノード１００はジョブの管理に必要な機能を実現することができる。なお、図３には管理ノード１００のハードウェア構成例を示したが、計算ノード２００，３００，４００，５００，６００やジョブ投入装置３０も同様のハードウェアで実現することができる。

図４は、クラスタシステムの機能を示すブロック図である。管理ノード１００は、ジョブ実行依頼受付部１２１、ジョブ実行指示部１２２、ジョブＤＢ再構築部１２３、およびジョブＤＢ１３０を有している。

ジョブ実行依頼受付部１２１は、ジョブ投入装置３０からのジョブ実行依頼を受け付ける。ジョブ実行依頼には、ジョブの実行に使用するプログラムの指定や、そのプログラムに引き渡すパラメータなどが含まれる。また、ジョブ実行依頼受付部１２１は、受け付けたジョブ実行依頼をジョブ実行指示部１２２に渡すと共に、ジョブ実行依頼の内容を示すジョブ投入情報をジョブＤＢ１３０とストレージデバイス１１０とに格納する。

ジョブ実行指示部１２２は、起動している計算ノード２００，３００，４００，５００，６００のリストを有しており、ジョブ実行依頼に応じたジョブの割り振りを行う。すなわち、ジョブ実行指示部は、ジョブ実行依頼受付部１２１からジョブ実行依頼に応じて、ジョブ実行指示を計算ノードに対して出力する。

なお、ジョブ実行依頼には、実行すべきジョブが並列ジョブなのか逐次ジョブなのかを示す情報が含まれている。また、並列ジョブであれば、並列数（実行に必要な計算ノードの数）がジョブ実行依頼に含まれる。依頼されたジョブが並列ジョブであれば、ジョブ実行指示部１２２は、並列数に応じた数の計算ノードを依頼先として決定する。また、依頼されたジョブが逐次ジョブであれば、ジョブ実行指示部１２２は、１台の計算ノードを依頼先として決定する。そして、ジョブ実行指示部１２２は、依頼先の計算ノードに対して、ジョブ実行指示を出力する。

並列ジョブのジョブ実行指示を出す場合、ジョブ実行指示部１２２は、依頼先の計算ノードの１つをジョブマスタに指定し、ジョブマスタ以外の計算ノードをジョブスレーブに指定する。ジョブマスタの計算ノード（ジョブマスタノード）にジョブ実行指示を出す場合、ジョブ実行指示部１２２は、ジョブマスタノードに対して並列ジョブの依頼先となるすべての計算ノードに関する実行資源情報を渡す。実行資源情報は、ジョブの実行に際して使用すべき資源（使用すべきＣＰＵやメモリ容量など）に関する情報である。また、ジョブスレーブの計算ノード（ジョブスレーブノード）にジョブ実行指示を出す場合、ジョブ実行指示部１２２は、ジョブスレーブノードに対して、ジョブスレーブノード自身に関する実行資源情報を渡す。

さらに、ジョブ実行指示部１２２は、ジョブ実行依頼に応じたジョブ実行指示をどの計算ノードに出したのかを示すジョブ配置情報を、ストレージデバイス１１０に格納する。また、ジョブ実行指示部１２２は、ジョブ実行指示を計算ノードに対して出力した場合、ジョブ配置情報と実行資源情報とを、ジョブＤＢ１３０に格納する。

なお、ジョブ実行指示部１２２は、管理ノード１００の再起動が行われると、起動している計算ノードのリストを再構築する。具体的には、ジョブ実行指示部１２２は、ネットワーク２１を介してノード組み込み依頼をすべての計算ノード２００，３００，４００，５００，６００宛に送信する（たとえば、ブロードキャスト送信を行う）。ジョブ実行指示部１２２は、組み込み依頼に対する応答を返した計算ノードを、起動しているものと認識する。そして、ジョブ実行指示部１２２は、起動している計算ノードのリストを作成する。

また、ジョブ実行指示部１２２は、計算ノード２００，３００，・・・からの要求を受け付け、その要求に応じた処理を行う。さらに、計算ノード２００，３００，・・・においてジョブが終了すると、処理結果を受け取る。受け取った処理結果は、ジョブ実行依頼受付部１２１を介して、対応するジョブのジョブ実行依頼を出力したジョブ投入装置３０に送信される。そのとき、ジョブ実行指示部１２２は、ストレージデバイス１１０の中から、終了したジョブに対応するジョブデータを削除すると共に、終了したジョブのジョブ情報をジョブＤＢ１３０から削除する。

ジョブＤＢ再構築部１２３は、ジョブＤＢ１３０の内容が失われた場合に、ジョブＤＢ１３０の再構築を行う。具体的には、ジョブＤＢ再構築部１２３は、管理ノード１００が再起動された際に、ストレージデバイス１１０からジョブ投入情報とジョブ配置情報とを取得する。さらに、ジョブＤＢ再構築部１２３は、起動されている計算ノードのうち、逐次ジョブを実行している計算ノードと、並列ジョブにおけるジョブマスタノードとから実行資源情報を取得する。そして、ジョブＤＢ再構築部１２３は、実行資源情報をジョブＤＢ１３０に格納する。

計算ノード２００は、ジョブ制御部２１１，計算ノード内ジョブＤＢ２２０を有している。ジョブ制御部２１１は、ジョブ実行指示部１２２からのジョブ実行指示に応じて並列ジョブ実行プロセス２１２を起動する。具体的には、ジョブ実行指示において、ジョブを実行するためのプログラムや必要なパラメータや実行資源情報が指定される。

ジョブ制御部２１１は、指定されたプログラムの実行をＯＳに指示する。その際、ジョブ制御部２１１は、実行資源情報において指定された資源の利用をＯＳに指示する。これにより、ＯＳは、指定されたＣＰＵ上にプロセスを生成し、そのプロセスにジョブ用のプログラムを実行させる。指定されたプログラムが並列ジョブ用のプログラムであれば、起動されたプロセスが並列ジョブ実行プロセス２１２として機能する。なお、指定されたプログラムが逐次ジョブ用のプログラムであれば、起動されたプロセスは、逐次ジョブとして機能することとなる。

また、ジョブ制御部２１１は、ジョブ実行指示で指定された実行資源情報を、計算ノード内ジョブＤＢ２２０に格納する。なお、計算ノード２００がジョブマスタノードとして機能する場合、ジョブスレーブノードの実行資源情報も併せて計算ノード内ジョブＤＢ２２０に格納する。

ジョブの処理が終了した場合、ジョブ制御部２１１は、ジョブの処理結果をジョブ実行指示部１２２に渡す。その際、ジョブ制御部２１１は、終了したジョブの実行資源情報を計算ノード内ジョブＤＢ２２０から削除する。

なお、ジョブ制御部２１１は、管理ノード１００からノード組み込み依頼を受け取った場合、ノード情報を応答する。ノード情報とは、クラスタ内で計算ノード２００を一意に識別するための識別情報や、実装している資源（ＣＰＵ数やメモリ容量）の情報である。

さらに、ジョブ制御部２１１は、管理ノード１００から実行資源収集依頼を受け取ると、自分が並列ジョブのジョブマスタノードとして機能しているか、あるいは逐次ジョブを実行しているかを判断する。ジョブマスタノードとして機能している場合、ジョブ制御部２１１は、計算ノード内ジョブＤＢ２２０内のすべての実行資源情報を管理ノード１００に送信する。また、逐次ジョブを実行している場合、ジョブ制御部２１１は、実行中の逐次ジョブの実行資源情報を管理ノード１００に送信する。

計算ノード内ジョブＤＢ２２０は、計算ノード２００で実行しているジョブの実行資源情報を記憶する。たとえば、計算ノード２００のメインメモリ（ＲＡＭ）内の一部の記憶領域が、計算ノード内ジョブＤＢ２２０として使用される。

計算ノード３００も、計算ノード２００と同様に、ジョブ制御部３１１、計算ノード内ジョブＤＢ３２０を有しており、並列ジョブのジョブ実行指示を受けた場合、並列ジョブ実行プロセス３１２が起動される。計算ノード３００内の各要素は、計算ノード２００の同名の要素と同じ機能を有している。

ここで、計算ノード２００と計算ノード３００とに対して、１つのジョブ実行依頼に基づく並列ジョブの実行指示が出された場合、計算ノード２００の並列ジョブ実行プロセス２１２と計算ノード３００の並列ジョブ実行プロセス３１２とは、互いに連携して処理を実行する。たとえば、並列ジョブ実行プロセス３１２の演算結果が並列ジョブ実行プロセス２１２に渡され、並列ジョブ実行プロセス２１２は受け取った演算結果を利用して別の演算を行う。

なお、図示していない計算ノード４００，５００，６００も、計算ノード２００，３００と同様の機能を有している。
次に、ジョブＤＢ１３０の内容について詳細に説明する。

図５は、ジョブＤＢのデータ構造例を示す図である。ジョブＤＢ１３０には、投入されたジョブごとのジョブ情報１３０ａ，１３０ｂ，・・・が格納されている。ジョブ情報１３０ａには、ジョブ投入情報１３１、ジョブ配置情報１３２、実行資源情報１３３が含まれている。

ジョブ投入情報１３１は、ジョブ実行依頼で示されるジョブの内容を示す情報である。たとえば、ジョブ投入情報１３１には、ジョブ投入マシン、投入ユーザ、投入ディレクトリ、投入オプション、ジョブＩＤ（Job ID）などの情報が含まれる。

ジョブ投入マシンは、ジョブ実行依頼を出力した装置（図４の例ではジョブ投入装置３０）を一意に識別するための識別情報である。ジョブ投入マシンの情報を参照することで、ジョブの処理結果を送信すべき装置を判断することができる。投入ユーザは、ジョブを投入したユーザを一意に識別するための情報である。投入ディレクトリは、ジョブの処理結果の格納場所（ディレクトリ）を示す情報である。ジョブＩＤは、投入されたジョブを一意に識別するための識別情報である。ジョブＩＤは、ジョブ実行依頼が入力された際に、ジョブ実行依頼受付部１２１によって付与される。

ジョブ配置情報１３２は、計算ノードにジョブの実行指示が出されたときにジョブ実行指示部１２２によって作成される情報である。ジョブ配置情報１３２には、ジョブＩＤ、ノードＩＤ（Node ID）一覧などの情報が含まれる。ジョブＩＤは、ジョブの識別情報であり、ジョブ投入情報１３１と同じジョブＩＤが設定される。ノードＩＤ一覧は、ジョブの実行指示を出した計算ノードの識別情報である。並列ジョブであれば、複数のノードＩＤがノードＩＤ一覧に設定される。逐次ジョブであれば、１つのノードＩＤがノードＩＤ一覧に設定される。また、並列ジョブの場合、ノードＩＤ一覧内の１つのノードＩＤに、ジョブマスタであることを示すフラグが設定される。

実行資源情報１３３は、計算ノードにジョブの実行指示が出されたときにジョブ実行指示部１２２によって作成される情報である。実行資源情報１３３には、ジョブＩＤ、実行可能経過時間制限値、実行可能ＣＰＵ時間制限値などに加え、ジョブ実行指示先のノードごとのノード別実行資源情報１３３ａ，１３３ｂ，１３３ｃが含まれている。

実行資源情報１３３のジョブＩＤは、ジョブ投入情報１３１のジョブＩＤと同じである。実行可能経過時間制限値は、ジョブの実行にかかる時間の制限値である。ジョブの実行が開始されてから実行可能経過時間制限値で示された時間を経過してもジョブが終了しない場合、該当ジョブはジョブ実行指示部１２２によって強制的に終了させられる。実行可能ＣＰＵ時間制限値は、ジョブの実行に使用可能なＣＰＵの占有時間の制限値である。実行を指示したジョブによる各ノードでのＣＰＵの占有時間の合計が実行可能ＣＰＵ時間制限値を超えた場合、該当ジョブはジョブ実行指示部１２２によって強制的に終了させられる。

ノード別実行資源情報１３３ａ，１３３ｂ，１３３ｃには、ノードＩＤ、ジョブＩＤ、使用可能ＣＰＵ数、使用可能メモリ量などの情報や、各ノード内のＣＰＵごとのＣＰＵ情報が含まれている。

ノードＩＤは、ジョブ実行指示が出された計算ノードの識別情報である。ノード別実行資源情報１３３ａ，１３３ｂ，１３３ｃのジョブＩＤは、ジョブ投入情報１３１のジョブＩＤと同じである。

使用可能ＣＰＵ数は、ノードＩＤで示された計算ノードにおいて使用可なＣＰＵの数である。なお、図５には示していないが、計算ノードが搭載しているＣＰＵ数、使用しているＣＰＵ数、ジョブの実行のために予約されているＣＰＵ数などの情報がノード別実行資源情報１３３ａ，１３３ｂ，１３３ｃに含まれる。

使用可能メモリ量は、ノードＩＤで示された計算ノードにおいて使用可なメインメモリ（ＲＡＭ）の記憶容量である。なお、図５には示していないが、計算ノードが搭載している全メモリ容量、使用量（ジョブの実行に使用されている記憶容量）、予約量（ジョブの実行のために予約されている記憶容量）などの情報がノード別実行資源情報１３３ａ，１３３ｂ，１３３ｃに含まれる。

ＣＰＵ情報には、ＣＰＵＩＤなどの情報が含まれる。ＣＰＵＩＤは、計算ノードに実装されているＣＰＵの識別情報である。なお、図５には示していないが、ＣＰＵが使用されているのか未使用なのかを示すフラグが、各ＣＰＵ情報に含まれる。

なお、ジョブＤＢ１３０内の各ジョブ情報１３０ａ，１３０ｂ，・・・は、対応するジョブの処理が終了すると、ジョブ実行指示部１２２によって削除される。
このように、ジョブＤＢ１３０には、クラスタシステムにおけるジョブの管理に必要な情報が格納されている。このジョブＤＢ１３０に格納された情報の一部が、ハードディスク上に設けられたストレージデバイス１１０に格納される。

図６は、ストレージデバイスのデータ構造例を示す図である。ストレージデバイス１１０には、投入されたジョブ（ジョブ実行依頼によって依頼されたジョブ）ごとのジョブデータ１１１，１１２，・・・が格納されている。

ジョブデータ１１１には、ジョブ投入情報１１１ａとジョブ配置情報１１１ｂとが格納されている。ジョブ投入情報１１１ａ内容は、ジョブＤＢ１３０内のジョブ投入情報１３１と同じである。ジョブ配置情報１１１ｂの内容は、ジョブＤＢ１３０内のジョブ配置情報１３２と同じである。

すなわち、ジョブＤＢ１３０内に新たにジョブ投入情報１３１が登録される際には、同期してストレージデバイス１１０内にジョブ投入情報１１１ａが格納される。同様に、ジョブＤＢ１３０内に新たにジョブ配置情報１３２が登録される際には、同期してストレージデバイス１１０内にジョブ配置情報１１１ｂが格納される。

次に、計算ノード２００，３００，４００，５００，６００に設けられた計算ノード内ジョブＤＢのデータ構造例について説明する。計算ノード内ジョブＤＢの内容は、該当する計算ノードがジョブマスタノードであるのか、ジョブスレーブノードであるのかによって異なる。そこで、計算ノード２００がジョブマスタノードとして機能し、計算ノード３００がジョブスレーブノードとして機能している場合を想定し、それぞれの計算ノード２００，３００の計算ノード内ジョブＤＢ２２０，３２０のデータ構造を説明する。

図７は、ジョブマスタノードの計算ノード内ジョブＤＢのデータ構造例を示す図である。ジョブマスタノードの計算ノード内ジョブＤＢ２２０には、ジョブマスタノードで実行されている並列ジョブの実行資源情報２２１が格納されている。実行資源情報２２１には、並列ジョブが割り当てられた各計算ノードのノード別実行資源情報２２１ａ，２２１ｂ，２２１ｃが含まれている。実行資源情報２２１の内容は、管理ノード１００のジョブＤＢ１３０に格納された実行資源情報１３３と同じである。すなわち、ジョブＤＢ１３０内に新たに実行資源情報１３３が登録される際には、同期して計算ノード２００の計算ノード内ジョブＤＢ２２０に実行資源情報２２１が格納される。

図８は、ジョブスレーブノードの計算ノード内ジョブＤＢのデータ構造例を示す図である。ジョブスレーブノードの計算ノード内ジョブＤＢ３２０には、ジョブスレーブノードで実行されている並列ジョブのノード別実行資源情報３２１が格納されている。実行資源情報３２１の内容は、管理ノード１００のジョブＤＢ１３０に格納されたノード別実行資源情報１３３ａ，１３３ｂ，１３３ｃ内の計算ノード３００に対応するノード別実行資源情報と同じである。すなわち、ジョブＤＢ１３０内に計算ノード３００のノード別実行資源情報が登録される際には、同期して計算ノード３００の計算ノード内ジョブＤＢ３２０に実行資源情報３２１が格納される。

以上のような構成のクラスタシステムにおいて、高信頼性のジョブ管理が行われる。以下、ジョブ管理の処理内容を詳細に説明する。
図９は、ジョブの実行例を示す図である。図９の例では、クラスタシステムにおいて、２つの並列ジョブ３１，３２が実行されている。

並列ジョブ３１は、３台の計算ノード２００，３００，４００に割り当てられている。すなわち、３台の計算ノード２００，３００，４００それぞれの並列ジョブ実行用のプロセスが互いに連携して、並列ジョブ３１の処理を実行している。並列ジョブ３１の実行に際し、計算ノード２００がジョブマスタノードとして機能しており、計算ノード３００，４００がジョブスレーブノードとして機能している。なお、並列ジョブ３１のジョブＩＤは「JobID#0」である。

並列ジョブ３２は、２台の計算ノード５００，６００に割り当てられている。すなわち、２台の計算ノード５００，６００それぞれの並列ジョブ実行用のプロセスが互いに連携して、並列ジョブ３２の処理を実行している。並列ジョブ３２の実行に際し、計算ノード５００がジョブマスタノードとして機能しており、計算ノード６００がジョブスレーブノードとして機能している。なお、並列ジョブ３２のジョブＩＤは「JobID#1」である。

この場合、管理ノード１００のジョブＤＢ１３０には、並列ジョブ３１に対応するジョブ情報１３０ａと、並列ジョブ３２に対応するジョブ情報１３０ｂとが格納される。ジョブ情報１３０ａは、ジョブＩＤ「JobID#0」が設定されることで、並列ジョブ３１と関連付けられている。同様に、ジョブ情報１３０ｂは、ジョブＩＤ「JobID#1」が設定されることで、並列ジョブ３２と関連付けられている。

ジョブ情報１３０ａには、３台の計算ノード２００，３００，４００それぞれに対応するノード別実行資源情報１３３ａ，１３３ｂ，１３３ｃが含まれている。また、ジョブ情報１３０ｂには、２台の計算ノード５００，６００それぞれに対応するノード別実行資源情報１３３ｄ，１３３ｅが含まれている。

並列ジョブ３１のジョブマスタノードである計算ノード２００の計算ノード内ジョブＤＢ２２０には、計算ノード２００自身のノード別実行資源情報２２１ａに加え、ジョブスレーブノードである計算ノード３００，４００のノード別実行資源情報２２１ｂ，２２１ｃが格納されている。各ノード別実行資源情報２２１ａ，２２１ｂ，２２１ｃは、対応する計算ノード２００，３００，４００のノードＩＤが設定されている。そのノードＩＤによって、どの計算ノードに対応するノード別実行資源情報なのかが一意に識別される。

並列ジョブ３１のジョブスレーブノードである計算ノード３００の計算ノード内ジョブＤＢ３２０には、計算ノード３００自身のノード別実行資源情報３２１が格納されている。同様に、並列ジョブ３１のジョブスレーブノードである計算ノード４００の計算ノード内ジョブＤＢ４２０には、計算ノード４００自身のノード別実行資源情報４２１が格納されている。

並列ジョブ３２のジョブマスタノードである計算ノード５００の計算ノード内ジョブＤＢ５２０には、計算ノード５００自身のノード別実行資源情報５２１ａに加え、ジョブスレーブノードである計算ノード６００のノード別実行資源情報５２１ｂが格納されている。各ノード別実行資源情報５２１ａ，５２１ｂは、対応する計算ノード５００，６００のノードＩＤが設定されている。そのノードＩＤによって、どの計算ノードに対応するノード別実行資源情報なのかが一意に識別される。

並列ジョブ３２のジョブスレーブノードである計算ノード６００の計算ノード内ジョブＤＢ６２０には、計算ノード６００自身のノード別実行資源情報６２１が格納されている。

このような状況下で管理ノード１００が機能停止に陥った（ダウンした）場合を考える。
図１０は、管理ノードダウン時の状態を示す図である。管理ノード１００がダウンすると、管理ノード１００のジョブＤＢ１３０内に格納されていたジョブ情報１３０ａ，１３０ｂは失われる。ただし、この場合でも計算ノード２００，３００，４００，５００，６００では、並列ジョブ３１，３２が継続して実行される。

計算ノード２００，３００，４００，５００，６００から管理ノード１００へ出力するべき要求が発生した場合、その要求は管理ノード１００が復旧するまでの間一時停止（ペンディング）の状態となる。たとえば、ジョブが終了したことを示す終了通知も、管理ノード１００が復旧するまでペンディングとなる。

図１１は、管理ノード再起動後の状態を示す図である。管理ノード１００の障害が復旧し再起動すると、管理ノード１００は、ストレージデバイス１１０とジョブマスターノードとして機能する計算ノード２００，５００から情報を収集し、ジョブＤＢ１３０を再構築する。

具体的には、２つの並列ジョブ３１、３２それぞれのジョブ投入情報１１１ａ，１１２ａとジョブ配置情報１１１ｂ，１１２ｂとがストレージデバイス１１０から収集される。また、並列ジョブ３１を実行している各計算ノード２００，３００，４００それぞれのノード別実行資源情報２２１ａ，２２１ｂ，２２１ｃが、並列ジョブ３１のジョブマスタノードである計算ノード２００から収集される。さらに、並列ジョブ３２を実行している各計算ノード５００，６００それぞれのノード別実行資源情報５２１ａ，５２１ｂが、並列ジョブ３２のジョブマスタノードである計算ノード５００から収集される。

管理ノード１００では、収集した情報をジョブＩＤに基づいて同一ジョブに関する情報を纏め、ジョブ情報１３０ａ，１３０ｂを再構築する。管理ノード１００がダウンしてから再起動、およびジョブ情報１３０ａ，１３０ｂを行うまでの間、各並列ジョブ３１，３２は継続して実行される。

次に、第１の実施の形態における処理手順を具体的に説明する。
図１２は、並列ジョブを実行するまでの処理手順を示すシーケンス図である。以下、図１２に示す処理をステップ番号に沿って説明する。なお、以下の説明では、並列ジョブのジョブ実行依頼に応じて、２台の計算ノード２００，３００にジョブを実行させるものとする。

［ステップＳ１１］管理ノード１００のジョブ実行依頼受付部１２１は、ジョブ投入装置３０からのジョブ実行依頼を受け付ける。ジョブ実行依頼受付部１２１は、受け付けたジョブ実行依頼をジョブ実行指示部１２２に渡す。また、ジョブ実行依頼受付部１２１は、ジョブ実行依頼に応じたジョブ情報１３０ａをジョブＤＢ１３０内に生成する。そして、ジョブ実行依頼受付部１２１は、ジョブ実行依頼に基づいてジョブ投入情報１３１を作成し、ジョブＤＢ１３０のジョブ情報１３０ａに格納すると共に、ストレージデバイス１１０にファイル形式で格納する。

［ステップＳ１２］ジョブ実行指示部１１２は、ジョブ実行依頼に応じたジョブの割り当て先となる計算ノードを決定する。具体的には、ジョブの実行に必要な数の計算ノードが空き状態（ジョブを実行していない状態）になるのを待ち、空きになった計算ノードを割り当て先として決定する。なお、必要な数の計算ノードが空き状態となるまで、ジョブ実行指示は待ち状態となる（実行待ちキューにキューイングされる）。

このとき、ジョブ実行指示部１１２によって実行資源情報１３３が作成される。実行資源情報１３３では、ジョブを実行するために使用する資源が指定される。たとえば、使用すべきＣＰＵのＣＰＵＩＤなどである。ジョブ実行指示部１１２は、作成した実行資源情報１３３をジョブＤＢ１３０に格納する。

［ステップＳ１３］ジョブ実行指示部１１２は、ジョブ実行依頼に応じて決定されたジョブの割り当て先の計算ノードにジョブ実行依頼を送信する。この際、ジョブ実行指示部１１２は、計算ノード２００をジョブマスタノードとして選択する。

そして、ジョブ実行指示部１１２は、計算ノード２００に対して、ジョブ実行依頼においてジョブマスタであることを指定すると共に、計算ノード２００，３００それぞれのノード別実行資源情報を含む実行資源情報１３３を送信する。また、ジョブ実行指示部１１２は、計算ノード３００に対して、ジョブ実行依頼においてジョブスレーブであることを指定すると共に、計算ノード３００のノード別実行資源情報を送信する。

この際、ジョブ実行指示部１１２は、ジョブ配置情報１３２を生成し、ジョブ配置情報１３２をジョブＤＢ１３０に格納すると共に、ストレージデバイス１１０にファイル形式で格納する。このジョブ配置情報１３２には、計算ノード２００，３００でジョブが実行されていること、および計算ノード２００がジョブマスタノードであることが示されている。

［ステップＳ１４］ジョブ実行依頼を受け取った計算ノード２００では、ジョブ制御部２１１がジョブ実行依頼を受信する。そして、ジョブ制御部２１１は、ジョブ実行依頼と共に送られた実行資源情報を、計算ノード内ジョブＤＢ２２０に格納する。

［ステップＳ１５］ジョブ実行依頼を受け取った計算ノード３００では、ジョブ制御部３１１がジョブ実行依頼を受信する。そして、ジョブ制御部３１１は、ジョブ実行依頼と共に送られたノード別実行資源情報を、計算ノード内ジョブＤＢ３２０に格納する。

［ステップＳ１６］計算ノード２００のジョブ制御部２１１は、ジョブ実行依頼に応じた並列ジョブ実行プロセス２１２を起動し、ジョブを実行させる。
［ステップＳ１７］計算ノード３００のジョブ制御部３１１は、ジョブ実行依頼に応じた並列ジョブ実行プロセス３１２を起動し、ジョブを実行させる。以後、計算ノード２００の並列ジョブ実行プロセス２１２と計算ノード３００の並列ジョブ実行プロセス３１２とが連携して、処理を実行する。

このようにして並列ジョブを実行しているときに、管理ノード１００がダウンすると、管理ノードの復旧処理が行われる。
図１３は、管理ノードの復旧処理手順を示すシーケンス図である。以下、図１３に示す処理をステップ番号に沿って説明する。この例は、２台の計算ノード２００，３００で並列ジョブを実行中に、管理ノード１００がダウンしたときの復旧処理を示している。

［ステップＳ２１］管理ノード１００がダウンした後も、計算ノード２００の並列ジョブ実行プロセス２１２は処理を継続する。
［ステップＳ２２］同様に、計算ノード３００の並列ジョブ実行プロセス３１２は処理を継続する。

［ステップＳ２３］計算ノード２００の並列ジョブ実行プロセス２１２において管理ノード１００への要求が発生すると、並列ジョブ実行プロセス２１２はエラー処理とはせずにその要求を待ち合わせ状態とする。待ち合わせの間、計算ノード２００では、処理開始からの経過時間やＣＰＵ使用時間のカウンタを停止させる。クラスタシステムによる計算サービスを提供している場合、経過時間やＣＰＵ使用時間によって請求金額が異なる場合がある。システム障害によって要求の待ち合わせを行っている間、そのような計測時間のカウンタと停止することで、公正な料金換算を行うことができる。

［ステップＳ２４］計算ノード３００の並列ジョブ実行プロセス３１２において管理ノード１００への要求が発生すると、並列ジョブ実行プロセス３１２はエラー処理とはせずにその要求を待ち合わせ状態とする。待ち合わせの間、計算ノード２００では、処理開始からの経過時間やＣＰＵ使用時間のカウンタを停止させる。

なお、並列ジョブ実行プロセス２１２，３１２の実行途中で管理ノード１００への要求が不要な場合、処理が最後まで実行され、ジョブマスタノードの並列ジョブ実行プロセス２１２から管理ノード１００への結果通知処理が待ち合わせ状態となる。ジョブの処理結果には、演算結果に加えて、所要時間やＣＰＵ使用時間が含まれる。

［ステップＳ２５］管理ノード１００の障害の原因が取り除かれると、管理ノード１００が起動される。
［ステップＳ２６］起動された管理ノード１００では、ジョブ実行指示部１２２が計算ノード２００，３００に対してノード組み込み依頼を送信する。ノード組み込み依頼は、クラスタを構成する計算ノードとして機能することを要求するメッセージである。

［ステップＳ２７］計算ノード２００のジョブ制御部２１１は、管理ノード１００からのノード組み込み依頼を受信する。
［ステップＳ２８］計算ノード３００のジョブ制御部３１１は、管理ノード１００からのノード組み込み依頼を受信する。

［ステップＳ２９］計算ノード２００のジョブ制御部２１１は、管理ノード１００に対してノード情報を通知する。このノード情報には、計算ノード２００のノードＩＤや、計算ノード２００が有する資源情報（ハードウェア資源とソフトウェア資源）が含まれる。

［ステップＳ３０］計算ノード３００のジョブ制御部３１１は、管理ノード１００に対してノード情報を通知する。このノード情報には、計算ノード３００のノードＩＤや、計算ノード３００が有する資源情報（ハードウェア資源とソフトウェア資源）が含まれる。

［ステップＳ３１］ジョブ実行指示部１２２は、ノード情報を受信する。
［ステップＳ３２］ジョブ実行指示部１２２は、起動中の計算ノード情報を構築する。具体的には、ジョブ実行指示部１２２は、起動している計算ノードのリストを作成し、その計算ノードのノードＩＤに対応付けて資源情報を管理する。

［ステップＳ３３］ジョブＤＢ再構築部１２３は、実行資源情報収集依頼を計算ノード２００，３００に送信する。
［ステップＳ３４］計算ノード２００のジョブ制御部２１１は、実行資源情報収集依頼を受信する。

［ステップＳ３５］計算ノード３００のジョブ制御部３１１は、実行資源情報収集依頼を受信する。
［ステップＳ３６］計算ノード２００のジョブ制御部２１１は、実行資源情報を管理ノード１００に通知する。具体的には、ジョブ制御部２１１は、計算ノード内ジョブＤＢ２２０から実行資源情報２２１を取得する。この実行資源情報２２１には、計算ノード２００自身のノード別実行資源情報に加え、並列ジョブのジョブスレーブノードとなる計算ノード３００のノード別実行資源情報も含まれている。そして、ジョブ制御部２１１によって実行資源情報２２１が管理ノード１００に送信される。

このとき、計算ノード３００は、自身がジョブスレーブノードであるため、実行資源情報の送信は行わない。すなわち、管理ノード１００から送られた実行資源収集依頼は、計算ノード３００のジョブ制御部３１１において無視される。これにより、実行資源情報の収集のために、余計なデータ転送が発生せずに済む。

［ステップＳ３７］管理ノード１００のジョブＤＢ再構築部１２３は、ジョブマスタノードとして機能する計算ノード２００から送られた実行資源情報を受信する。
［ステップＳ３８］ジョブＤＢ再構築部１２３は、ジョブＤＢ１３０を再構築する。すなわち、ストレージデバイス１１０からジョブ投入情報１３１とジョブ配置情報１３２を取得して、ジョブ毎のジョブ情報１３０ａを作成する。そして、ジョブＤＢ再構築部１２３は、作成したジョブ情報１３０ａに対して、計算ノード２００から取得した実行資源情報１３３を登録する。

［ステップＳ３９］ジョブＤＢ再構築部１２３は、ジョブの継続か可能か否かを判断する。具体的には、ジョブＤＢ再構築部１２３は、ジョブ投入情報１３１に基づいて、どのようなジョブ実行依頼を受け付けているのかを認識する。さらに、ジョブＤＢ再構築部１２３は、ジョブ配置情報１３２に基づいて、ジョブがどの計算ノードに割り当てられたのかを認識する。そして、ジョブ配置情報１３２は、ステップＳ３２で構築されたノード情報に基づいて、割り当て先の計算ノードがすべて動作していること、およびジョブマスタノードから割り当て先の計算ノードに関する実行資源情報が送られたことを確認する。これらの確認が正しく行われれば、ジョブ配置情報１３２は、ジョブを継続可能と判断する。

［ステップＳ４０］ジョブの継続可能と判断した場合、ジョブ配置情報１３２は、ジョブ運用再開を、並列ジョブを実行している各計算ノード２００，３００に通知する。
［ステップＳ４１］計算ノード２００のジョブ制御部２１１は、ジョブ運用再開の通知を受けて、管理ノード１００との間の通信を再開する。すなわち、待ち合わせ状態の要求がある場合、その要求が管理ノード１００に送られる。また、ジョブが終了している場合、処理結果が管理ノード１００に送られる。

［ステップＳ４２］計算ノード３００のジョブ制御部３１１は、ジョブ運用再開の通知を受けて、管理ノード１００との間の通信を再開する。
このようにして、管理ノード１００がダウンした場合にも、計算ノード２００，３００に対して並列ジョブをそのまま継続して実行させることができる。なお、管理ノード１００への要求が発生した場合には待ち合わせとなるが、管理ノード１００を再起動させた後にその状態から処理を続行できる。その結果、並列ジョブを最初から実行し直す必要が無くなり、処理の効率化が図れる。

次に、管理ノード１００と一部の計算ノードとが同時にダウンした場合の処理について説明する。
図１４は、管理ノードとジョブマスタノードとが同時にダウンした状態を示す図である。このように、管理ノード１００とジョブマスタノードとして機能する計算ノード２００とが同時にダウンすると、並列ジョブ３１の一部の処理が実行できなくなり、並列ジョブ３１を継続して実行することはできない。

図１５は、管理ノードとジョブマスタノードとの再起動後の状態を示す図である。管理ノード１００とジョブマスタとして機能する計算ノード２００との障害を修復し、再起動した直後は、管理ノード１００のジョブＤＢ１３０と計算ノード２００の計算ノード内ジョブＤＢ２２０とは、空の状態である。

管理ノード１００では、ストレージデバイス１１０と、他の計算ノード２００，３００，４００とから情報収集を行う。すると、ストレージデバイス１１０からジョブ投入情報１１１ａとジョブ配置情報１１１ｂとを取得し、ジョブ情報１３０ａ内にジョブ投入情報１３１とジョブ配置情報１３２とを再構築できる。しかし、ジョブマスタノードとして機能する計算ノード２００の計算ノード内ジョブＤＢ２２０内のデータが失われているため、並列ジョブ３１に関する実行資源情報は取得できない。そこで、管理ノード１００は、実行中の並列ジョブ３１の刈り取り（並列ジョブを強制的に停止させること）を行う。

図１６は、刈り取り依頼の状況を示す図である。管理ノード１００では、ジョブ配置情報１３２と、取得した実行資源情報とを比較することにより、投入されている並列ジョブ３１の実行継続が不可能であることを認識する。そこで、ジョブスレーブノードとして機能している計算ノード３００，４００に対して並列ジョブ３１の刈り取り依頼を送信する。計算ノード３００，４００では、刈り取り依頼に応じて、並列ジョブ３１の刈り取りを行う。

図１７は、刈り取り後の状態を示す図である。並列ジョブ３１の刈り取りが行われたことにより、計算ノード３００，４００で実行されていた並列ジョブ３１のプロセスが停止する。また、計算ノード３００，４００の計算ノード内ジョブＤＢ３２０，４２０の内容も削除される。その後、管理ノード１００からジョブ再実行依頼が出される。

図１８は、ジョブ再実行依頼の状況を示す図である。管理ノード１００では、ジョブ投入情報１３１とジョブ配置情報１３２とに基づいて、投入すべきジョブの内容と、割り当て先である計算ノード２００，３００，４００とを認識する。そして、管理ノード１００は、ジョブＤＢ１３０内のジョブ情報１３０ａを再構築し、計算ノード２００，３００，４００に対して、ジョブ再実行依頼が送信される。このジョブ再実行依頼には、ノード別実行資源情報が含まれる。ジョブマスタノードとして機能する計算ノード２００には、すべての実効資源情報が送信される。ジョブスレーブノードとして機能する計算ノード３００，４００には、それぞれ計算ノード３００，４００自身のノード別実効資源情報３２１，４２１が送信される。

各計算ノード２００，３００，４００では、受け取った実効資源情報に基づいてそれぞれのジョブＤＢ２２０，３２０，４２０を再構築し、並列ジョブ３１の実行を開始する。
以上のようにして、管理ノード１００とジョブマスタノードとして機能する計算ノード２００とが同時にダウンしても、クラスタシステム内の処理でジョブの再実行が可能である。すなわち、ジョブ投入装置３０から依頼されたジョブを紛失せずに再度実行可能である。ただし、並列ジョブ３１の処理は、最初からやり直すこととなる。

図１９は、管理ノードとジョブスレーブノードとが同時にダウンした状態を示す図である。このように、管理ノード１００とジョブスレーブノードとして機能する計算ノード４００とが同時にダウンすると、並列ジョブ３１の一部の処理が実行できなくなり、並列ジョブ３１を継続して実行することはできない。

図２０は、管理ノードとジョブスレーブノードとの再起動後の状態を示す図である。管理ノード１００とジョブスレーブノードとして機能する計算ノード４００との障害を修復し、再起動した直後は、管理ノード１００のジョブＤＢ１３０と計算ノード４００の計算ノード内ジョブＤＢ４２０とは、空の状態である。

管理ノード１００では、ストレージデバイス１１０と、他の計算ノード２００，３００，４００とから情報収集を行う。すると、ストレージデバイス１１０からジョブ投入情報１１１ａとジョブ配置情報１１１ｂとを取得できると共に、ジョブマスタノードとして機能する計算ノード２００から実効資源情報を取得できる。その結果、ジョブＤＢ１３０内のジョブ情報１３０ａが再構築される。しかし、ジョブスレーブノードとして機能する計算ノード４００が再起動され、それまでの処理内容が失われているため、並列ジョブ３１を実行することはできない。そこで、管理ノード１００は、実行中の並列ジョブ３１の刈り取り（並列ジョブを強制的に停止させること）を行う。

図２１は、刈り取り依頼の状況を示す図である。管理ノード１００では、ジョブ配置情報１３２で示されたジョブ割り当て先の各計算ノード２００，３００，４００の状態を確認する。このとき、再起動された直後の計算ノード４００は、非アクティブの状態を示す。これにより、管理ノード１００は、既に実行を依頼している並列ジョブ３１の続行が不可能であることを認識する。そこで、管理ノード１００は、計算ノード２００，３００に対して並列ジョブ３１の刈り取り依頼を送信する。計算ノード２００，３００では、刈り取り依頼に応じて、並列ジョブ３１の刈り取りを行う。

図２２は、刈り取り後の状態を示す図である。並列ジョブ３１の刈り取りが行われたことにより、計算ノード２００，３００で実行されていた並列ジョブ３１のプロセスが停止する。また、計算ノード２００，３００の計算ノード内ジョブＤＢ２２０，３２０の内容も削除される。その後、管理ノード１００からジョブ再実行依頼が出される。再実行依頼状況は、図１８に示した通りである。

このように、管理ノード１００とジョブスレーブノードとして機能する計算ノード４００とが同時にダウンした場合にも、クラスタシステム内の処理によってジョブの再実行が可能である。

図２３は、すべてのノードが同時にダウンした状況を示す図である。このように、すべてのノードが一度にダウンすると、並列ジョブ３１が失われると共に、実効資源情報も消失する。

図２４は、管理ノードとジョブマスタノードとの再起動後の状態を示す図である。管理ノード１００とジョブスレーブノードとして機能する計算ノード３００との障害を修復し、再起動した直後は、管理ノード１００のジョブＤＢ１３０と計算ノード２００，３００，４００の計算ノード内ジョブＤＢ２２０，３２０，４２０とは、空の状態である。

管理ノード１００では、ストレージデバイス１１０と、他の計算ノード２００，３００，４００とから情報収集を行う。すると、ストレージデバイス１１０からジョブ投入情報１１１ａとジョブ配置情報１１１ｂとを取得し、ジョブ情報１３０ａ内にジョブ投入情報１３１とジョブ配置情報１３２とを再構築できる。しかし、ジョブマスタノードとして機能する計算ノード２００の計算ノード内ジョブＤＢ２２０内のデータが失われているため、並列ジョブ３１に関する実行資源情報は取得できない。

そこで、管理ノード１００では、ジョブ配置情報１３２で示されたジョブ割り当て先の各計算ノード２００，３００，４００の状態を確認する。このとき、再起動された直後の計算ノード２００，３００，４００は、非アクティブの状態を示す。これにより、管理ノード１００は、既に実行を依頼している並列ジョブ３１が既に存在しないことを認識する。

並列ジョブ３１が存在しないため刈り取りの必要はない。そこで、管理ノード１００からジョブ再実行依頼が出される。再実行依頼状況は、図１８に示した通りである。
図２５は、管理ノードと計算ノードとが同時にダウンした場合の復旧処理手順を示すシーケンス図である。以下、図２５に示す処理をステップ番号に沿って説明する。この例は、２台の計算ノード２００，３００で並列ジョブを実行中に、管理ノード１００と計算ノード２００とがダウンしたときの復旧処理を示している。

［ステップＳ５１］管理ノード１００がダウンした後も、計算ノード３００の並列ジョブ実行プロセス３１２は処理を継続する。
［ステップＳ５２］計算ノード３００の並列ジョブ実行プロセス３１２において管理ノード１００への要求が発生すると、並列ジョブ実行プロセス３１２はエラー処理とはせずにその要求を待ち合わせ状態とする。

［ステップＳ５３］管理ノード１００の障害の原因が取り除かれると、管理ノード１００が起動される。
［ステップＳ５４］計算ノード２００の障害の原因が取り除かれると、計算ノード２００が起動される。

［ステップＳ５５］起動された管理ノード１００では、ジョブ実行指示部１２２が計算ノード２００，３００に対してノード組み込み依頼を送信する。ノード組み込み依頼は、クラスタを構成する計算ノードとして機能することを要求するメッセージである。

［ステップＳ５６］計算ノード２００のジョブ制御部２１１は、管理ノード１００からのノード組み込み依頼を受信する。
［ステップＳ５７］計算ノード３００のジョブ制御部３１１は、管理ノード１００からのノード組み込み依頼を受信する。

［ステップＳ５８］計算ノード２００のジョブ制御部２１１は、管理ノード１００に対してノード情報を通知する。このノード情報には、計算ノード２００のノードＩＤや、計算ノード２００が有する資源情報（ハードウェア資源とソフトウェア資源）が含まれる。また、計算ノード２００は再起動直後であり、クラスタシステムに参加していないため、ジョブ制御部２１１は、非アクティブであることを示す情報をノード情報に含める。

［ステップＳ５９］計算ノード３００のジョブ制御部３１１は、管理ノード１００に対してノード情報を通知する。このノード情報には、計算ノード３００のノードＩＤや、計算ノード３００が有する資源情報（ハードウェア資源とソフトウェア資源）が含まれる。

［ステップＳ６０］ジョブ実行指示部１２２は、ノード情報を受信する。
［ステップＳ６１］ジョブ実行指示部１２２は、起動中の計算ノード情報を構築する。具体的には、ジョブ実行指示部１２２は、起動している計算ノードのリストを作成し、その計算ノードのノードＩＤに対応付けて資源情報を管理する。

［ステップＳ６２］ジョブＤＢ再構築部１２３は、実行資源情報収集依頼を計算ノード２００，３００に送信する。
［ステップＳ６３］計算ノード２００のジョブ制御部２１１は、実行資源情報収集依頼を受信する。

［ステップＳ６４］計算ノード３００のジョブ制御部３１１は、実行資源情報収集依頼を受信する。
［ステップＳ６５］計算ノード２００のジョブ制御部２１１は、実行資源情報を管理ノード１００に通知する。具体的には、ジョブ制御部２１１は、計算ノード内ジョブＤＢ２２０から実行資源情報を取得を試みる。しかし、計算ノード内ジョブＤＢ２２０内は空があるため、ジョブ制御部２１１は内容が空情報を実行資源情報として管理ノード１００に送信する。

［ステップＳ６６］管理ノード１００のジョブＤＢ再構築部１２３は、ジョブマスタノードとして機能する計算ノード２００から送られた実行資源情報（空の情報）を受信する。

［ステップＳ６７］ジョブＤＢ再構築部１２３は、ジョブＤＢ１３０を再構築する。すなわち、ストレージデバイス１１０からジョブ投入情報１３１とジョブ配置情報１３２を取得して、ジョブ毎のジョブ情報１３０ａを作成する。なお、計算ノード２００からは空の実行資源情報しか取得できていないため、実効資源情報については再構築できない。

［ステップＳ６８］ジョブＤＢ再構築部１２３は、ジョブの継続か可能か否かを判断する。この例では、計算ノード２００が非アクティブであることが判っており、且つ実効資源情報再構築が出来ていないため、ジョブの継続は不可能と判断される。

［ステップＳ６９］ジョブの継続不可能と判断した場合、ジョブＤＢ再構築部１２３は、計算ノード３００に対してジョブＩＤを指定してジョブ刈り取り指示を行う。このとき、ジョブＩＤは、ジョブ投入情報１３１を参照して判断される。なお、計算ノード２００は非アクティブであることが分かっている、計算ノード２００に対するジョブ刈り取り指示は行われない。

［ステップＳ７０］計算ノード３００のジョブ制御部３１１は、ジョブ刈り取り指示に応じた並列ジョブ実行プロセス３１２を停止する。また、ジョブ制御部３１１は、計算ノード内ジョブＤＢ３２０に格納されていたノード別実行資源情報を削除する。

［ステップＳ７１］管理ノード１００のジョブ実行指示部１２２は、ジョブ投入情報１３１と計算ノード２００，３００から取得したノード情報に基づいて実行資源情報１３３を作成する。そして、ジョブ実行指示部１２２は、ジョブ配置情報１３２を参照してジョブの割り当て先を認識し、計算ノード２００，３００に対してジョブ実行依頼を送信する。

［ステップＳ７２］ジョブ実行依頼を受け取った計算ノード２００では、ジョブ制御部２１１がジョブ実行依頼を受信する。そして、ジョブ制御部２１１は、ジョブ実行依頼と共に送られた実行資源情報を、計算ノード内ジョブＤＢ２２０に格納する。

［ステップＳ７３］ジョブ実行依頼を受け取った計算ノード３００では、ジョブ制御部３１１がジョブ実行依頼を受信する。そして、ジョブ制御部３１１は、ジョブ実行依頼と共に送られたノード別実行資源情報を、計算ノード内ジョブＤＢ３２０に格納する。

［ステップＳ７４］計算ノード２００のジョブ制御部２１１は、ジョブ実行依頼に応じた並列ジョブ実行プロセス２１２を起動し、ジョブを実行させる。
［ステップＳ７５］計算ノード３００のジョブ制御部３１１は、ジョブ実行依頼に応じた並列ジョブ実行プロセス３１２を起動し、ジョブを実行させる。以後、計算ノード２００の並列ジョブ実行プロセス２１２と計算ノード３００の並列ジョブ実行プロセス３１２とが連携して、処理を実行する。

以上のようにして、管理ノード１００がダウンしても並列ジョブを継続して実行させることが可能となる。その結果、管理ノード１００がダウンしたことによる処理の遅延を最小限に抑えることができる。

また、管理ノード１００と計算ノードとが同時にダウンした場合であっても、並列ジョブを自動的に再実行させることができる。すなわち、計算ノードの障害により並列ジョブが中止されても、ジョブ投入装置３０から改めてジョブ実行依頼を入力する必要がない。その結果、システムの管理者の負荷を軽減することができる。

［第２の実施の形態］
次に、第２の実施の形態について説明する。第２の実施の形態は、複数の管理ノードを有するクラスタシステムにおいて、効率的な障害復旧を可能としたものである。すなわち、第１の実施の形態では管理ノードが１台しかないため、管理ノードを再起動してからジョブＤＢの再構築を行っていた。そのため、管理ノードの障害を取り除き再起動するまでの時間、計算ノードからの要求の待ち合わせが発生していた。

そこで、第２の実施の形態では、運用系の管理ノードの他に待機系の管理ノードを用意する。そして、運用系の管理ノードがダウンした場合、迅速に待機系の管理ノードが運用系に切り替わりジョブＤＢを再構築する。その結果、計算ノードからの要求の待ち合わせの発生を最小限に抑えることができる。

図２６は、第２の実施の形態に係るクラスタシステムのシステム構成図である。第２の実施の形態は、第１の実施の形態に管理ノード７００を追加したものである。そこで、管理ノード７００以外の要素には、第１の実施の形態と同じ符号を付し、説明を省略する。

管理ノード７００は、ネットワーク２１を介して他の管理ノード１００や計算ノード３００，４００に接続されている。管理ノード７００は、管理ノード１００と同様の機能を備えている。ただし、管理ノード１００が正常に運用されている間は、管理ノード７００はジョブ管理に関する処理を行わない。そのため、管理ノード７００内のジョブＤＢ７３０は空の状態である。

障害が発生する前は管理ノード１００が運用系としてジョブを管理している。そのため、計算ノード２００，３００に投入されている並列ジョブ３３に関するジョブ情報１３０ｂがジョブＤＢ１３０に格納されている。ジョブ情報１３０ｂ内には、並列ジョブ３３に対応するジョブ投入情報１３１ａとジョブ配置情報１３２ａが格納されている。さらに、ジョブ情報１３０ｂには、並列ジョブ３３を実行している各計算ノード２００，３００のノード別実行資源情報１３３ｄ，１３３ｅが格納されている。

また、ストレージデバイス１１０は、２台の管理ノード１００，７００それぞれに接続されている。そして、ジョブデータ記憶部１１０内には、並列ジョブ３３に対応するジョブデータ１１３が格納されている。ジョブデータ１１３には、ジョブ投入情報１１３ａとジョブ配置情報１１３ｂとが含まれる。

このようなシステムにおいて、管理ノード７００は、運用系の管理ノード１００が正常に動作していることを監視している。そして、運用系の管理ノード１００がダウンすると、待機系の管理ノード７００がジョブの管理機能を引き継ぐ。

図２７は、運用系の管理ノードがダウンした状態を示す図である。運用系の管理ノード１００がダウンすると、計算ノード２００，３００における並列ジョブ３３の処理は続行されるが、管理ノード１００への要求が発生すると、その要求の待ち合わせ状態となる。

待機系の管理ノード７００は、運用系の管理ノード１００が正常に動作していることを所定のタイミングで監視している。たとえば、管理ノード７００は、定期的に運用系の管理ノード１００に対して動作確認要求を送信する。管理ノード７００は、管理ノード１００から動作確認応答が返されれば、正常に動作していると判断する。そして、管理ノード７００は、運用系の管理ノード１００がダウンしたことを検出すると、ジョブの管理機能を引き継ぐ。

図２８は、運用系の切り換え状況を示す図である。運用系の管理ノード１００がダウンしたことを検出した管理ノード７００は、ストレージデバイス１１０とジョブマスタノードである計算ノード２００とから情報を収集する。具体的には、ストレージデバイス１１０からジョブ投入情報１１３ａとジョブ配置情報１１３ｂとを収集し、計算ノード２００から実効資源情報（ノード別事項資源情報２２１ｄ，２２１ｅを含む）を収集する。そして、管理ノード７００は、収集した情報に基づいてジョブＤＢ７３０内にジョブ情報７３０ａを構築する。ジョブ情報７３０ａには、ジョブ投入情報７３１、ジョブ配置情報７３２、計算ノード２００に対応するノード別実効資源情報７３３ａ、および計算ノード３００に対応するノード別実行資源情報７３３ｂが含まれる。

ジョブＤＢ７３０内にジョブ情報７３０ａを構築した管理ノード７００は、運用系としてジョブを管理する。すなわち、運用系となった管理ノード７００では、図１３および図２５に示した再起動後に行われる管理ノード１００の処理と同様の処理を実行する。これにより、計算ノード２００，３００は、管理ノード７００が運用系になったことを認識し、管理ノード７００に対して各種要求や処理結果を送信するようになる。具体的には、図１３のステップＳ２６に示すノード組み込み依頼によって、管理ノード７００が運用系に昇格したことを計算ノード２００，３００が認識する。なお、管理ノード７００が待機系から運用系に昇格するまでの間、計算ノード２００，３００は、並列ジョブ３３の処理を続行することができる。

このように、管理ノードを二重化することで、運用系の管理ノード１００がダウンした場合、管理ノード７００によって迅速に運用を再開することができる。
なお、上記の例では、待機系の管理ノード７００を個別に用意しているが、計算ノードの中の１台を待機系の管理ノードとして使用することもできる。その場合、運用系の管理ノードがダウンすると、管理ノードとしての機能を有する計算ノードが、管理ノードとしての処理を実行する。ダウンした管理ノードが再起動したら、その管理ノードを運用系とすることで、元の状態に戻すことができる。これにより、計算ノード内に管理ノードとしての機能を併存させる期間を最小限に抑えることができる。

なお、上記の処理機能は、コンピュータによって実現することができる。その場合、管理ノードや計算ノードが有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記録装置には、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープなどがある。光ディスクには、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ（Random Access Memory）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。光磁気記録媒体には、ＭＯ（Magneto-Optical disk）などがある。

プログラムを流通させる場合には、たとえば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

プログラムを実行するコンピュータは、たとえば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送される毎に、逐次、受け取ったプログラムに従った処理を実行することもできる。

なお、本発明は、上述の実施の形態にのみ限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変更を加えることができる。
以上説明した実施の形態の主な技術的特徴は、以下の付記の通りである。

（付記１） 複数の計算ノードにジョブの実行を指示すると共に、ストレージデバイスが接続されたジョブ管理装置において、
メインメモリ内に設けられ、ジョブ毎のジョブ情報を記憶するジョブＤＢと、
ジョブ実行依頼が入力されると、前記ジョブ実行依頼の内容、依頼されたジョブのジョブＩＤ、および前記ジョブ実行依頼の投入元の識別情報を含むジョブ投入情報を前記ストレージデバイスと前記ジョブＤＢとに格納するジョブ実行依頼受付手段と、
前記ジョブ実行依頼受付手段が受け付けた前記ジョブ実行依頼の割り当て先となる１台以上の前記計算ノードをジョブ被配置計算ノードに決定し、前記ジョブ被配置計算ノードに対して前記ジョブの実行に使用すべき資源を示す実行資源情報を付加したジョブ実行指示を送信し、前記ジョブＩＤに対応付けて、前記ジョブ被配置計算ノードの一覧を含むジョブ配置情報と前記ジョブ被配置計算ノードそれぞれの前記実行資源情報とを前記ジョブＤＢに格納し、前記ジョブＩＤに対応付けて前記ジョブ配置情報を前記ストレージデバイスに格納するジョブ実行指示手段と、
再起動処理によって前記ジョブＤＢの内容が失われた場合、前記ストレージデバイスから前記ジョブ投入情報と前記ジョブ配置情報とを収集し、前記ジョブ被配置計算ノードから前記実行資源情報を収集し、前記ジョブＤＢ内に前記ジョブ情報を再構築するジョブＤＢ再構築手段と、
を有することを特徴とするジョブ管理装置。

（付記２） 前記ジョブ実行指示手段は、前記ジョブ被配置計算ノードの中の１台をジョブマスタノード、前記ジョブマスタノード以外の前記計算ノードをジョブスレーブノードとし、前記ジョブマスタノードに対してすべての前記ジョブ被配置計算ノードの前記実行資源情報を付加したジョブ実行指示を送信し、前記ジョブスレーブノードに対して前記ジョブスレーブノード自身の実行資源情報を付加したジョブ実行指示を送信し、
前記ジョブＤＢ再構築手段は、再起動処理によって前記ジョブＤＢの内容が失われた場合、前記ストレージデバイスから前記ジョブ投入情報と前記ジョブ配置情報とを収集し、前記ジョブマスタノードから前記ジョブ被配置計算ノードすべての実行資源情報を収集し、前記ジョブＤＢ内に前記ジョブ情報を再構築することを特徴とする付記１記載のジョブ管理装置。

（付記３） 前記ジョブ実行指示手段は、再起動処理が行われた場合、複数の前記計算ノードに対してノード組み込み依頼を送信し、前記ノード組み込み依頼に応じて前記計算ノードから通知されるノード情報を取得し、前記ジョブ配置情報に含まれるすべての前記ジョブ被配置計算ノードから前記ノード情報を取得できたか否かにより、前記ジョブを続行できるかどうかを判断し、続行できる場合、ジョブ運用再開を前記ジョブ被配置計算ノードに対して送信し、続行できない場合、前記ジョブ被配置計算ノードに対してジョブの中止を指示すると共に、前記ジョブ被配置計算ノードに対して前記ジョブ被配置計算ノード自身の前記実行資源情報を付加した前記ジョブ実行指示を送信することを特徴とする付記１記載のジョブ管理装置。

（付記４） 投入されたジョブを実行するクラスタシステムにおいて、
ストレージデバイスと、
複数の計算ノードと、
メインメモリ内に設けられ、ジョブ毎のジョブ情報を記憶するジョブＤＢと、ジョブ実行依頼が入力されると、前記ジョブ実行依頼の内容、依頼されたジョブのジョブＩＤ、および前記ジョブ実行依頼の投入元の識別情報を含むジョブ投入情報を前記ストレージデバイスと前記ジョブＤＢとに格納するジョブ実行依頼受付手段と、前記ジョブ実行依頼受付手段が受け付けた前記ジョブ実行依頼の割り当て先となる１台以上の前記計算ノードをジョブ被配置計算ノードに決定し、前記ジョブ被配置計算ノードに対して前記ジョブの実行に使用すべき資源を示す実行資源情報を付加したジョブ実行指示を送信し、前記ジョブＩＤに対応付けて、前記ジョブ被配置計算ノードの一覧を含むジョブ配置情報と前記ジョブ被配置計算ノードそれぞれの前記実行資源情報とを前記ジョブＤＢに格納し、前記ジョブＩＤに対応付けて前記ジョブ配置情報を前記ストレージデバイスに格納するジョブ実行指示手段と、再起動処理によって前記ジョブＤＢの内容が失われた場合、前記ストレージデバイスから前記ジョブ投入情報と前記ジョブ配置情報とを収集し、前記ジョブ被配置計算ノードから前記実行資源情報を収集し、前記ジョブＤＢ内に前記ジョブ情報を再構築するジョブＤＢ再構築手段と、を具備する管理ノードと、
を有することを特徴とするクラスタシステム。

（付記５） 前記管理ノードの前記ジョブ実行指示手段は、前記ジョブ被配置計算ノードの中の１台をジョブマスタノード、前記ジョブマスタノード以外の前記計算ノードをジョブスレーブノードとし、前記ジョブマスタノードに対してすべての前記ジョブ被配置計算ノードの前記実行資源情報を付加したジョブ実行指示を送信し、前記ジョブスレーブノードに対して前記ジョブスレーブノード自身の実行資源情報を付加したジョブ実行指示を送信し、
前記管理ノードの前記ジョブＤＢ管理手段は、再起動処理によって前記ジョブＤＢの内容が失われた場合、前記ストレージデバイスから前記ジョブ投入情報と前記ジョブ配置情報とを収集し、前記ジョブマスタノードから前記ジョブ被配置計算ノードすべての実行資源情報を収集し、前記ジョブＤＢ内に前記ジョブ情報を再構築することを特徴とする付記４記載のクラスタシステム。

（付記６） 前記管理ノードのジョブＤＢ管理手段は、前記ジョブマスタノードに送信する前記ジョブ実行指示に対して、ジョブマスタとして機能することを示す情報を付加し、前記ジョブ被配置計算ノードから前記実行資源情報を収集する場合、実行資源情報収集依頼を前記ジョブ被配置計算ノードそれぞれに送信し、
前記計算ノードは、ジョブマスタとして指定される場合のみ、実行資源情報収集依頼に応答して前記計算ノードに対して前記実行資源情報を送信することを特徴とする付記５記載のクラスタシステム。

（付記７） 投入されたジョブを実行するクラスタシステムにおいて、
ストレージデバイスと、
複数の計算ノードと、
メインメモリ内に設けられ、ジョブ毎のジョブ情報を記憶する第１のジョブＤＢと、ジョブ実行依頼が入力されると、前記ジョブ実行依頼の内容、依頼されたジョブのジョブＩＤ、および前記ジョブ実行依頼の投入元の識別情報を含むジョブ投入情報を前記ストレージデバイスと前記第１のジョブＤＢとに格納するジョブ実行依頼受付手段と、前記ジョブ実行依頼受付手段が受け付けた前記ジョブ実行依頼の割り当て先となる１台以上の前記計算ノードをジョブ被配置計算ノードに決定し、前記ジョブ被配置計算ノードに対して前記ジョブの実行に使用すべき資源を示す実行資源情報を付加したジョブ実行指示を送信し、前記ジョブＩＤに対応付けて、前記ジョブ被配置計算ノードの一覧を含むジョブ配置情報と前記ジョブ被配置計算ノードそれぞれの前記実行資源情報とを前記第１のジョブＤＢに格納し、前記ジョブＩＤに対応付けて前記ジョブ配置情報を前記ストレージデバイスに格納する第１のジョブ実行指示手段と、を具備する第１の管理ノードと、
メインメモリ内に設けられ、ジョブ毎のジョブ情報を記憶する第２のジョブＤＢと、前記第１の管理ノードの機能が停止したことを検出した場合、前記ストレージデバイスから前記ジョブ投入情報と前記ジョブ配置情報とを収集し、前記ジョブ被配置計算ノードから前記実行資源情報を収集し、前記第２のジョブＤＢ内に前記ジョブ情報を構築するジョブＤＢ再構築手段と、前記第１の管理ノードの機能が停止したことを検出した場合、複数の前記計算ノードに対してノード組み込み依頼を送信する第２のジョブ実行指示手段と、を具備する第２の管理ノードと、
を有することを特徴とするクラスタシステム。

（付記８） 前記第２の管理ノードの前記第２のジョブ実行指示手段は、前記ノード組み込み依頼に応じて前記計算ノードから通知されるノード情報を取得し、前記ジョブ配置情報に含まれるすべての前記ジョブ被配置計算ノードから前記ノード情報を取得できたか否かにより、前記ジョブを続行できるかどうかを判断し、続行できない場合、前記ジョブ被配置計算ノードに対してジョブの中止を指示し、前記ジョブ被配置計算ノードに対して前記ジョブ被配置計算ノード自身の前記実行資源情報を付加した前記ジョブ実行指示を送信することを特徴とする付記７記載のクラスタシステム。

（付記９） 複数の計算ノードにジョブの実行を指示すると共に、ストレージデバイスが接続されたジョブ管理プログラムにおいて、
コンピュータを、
メインメモリ内に設けられ、ジョブ毎のジョブ情報を記憶するジョブＤＢ、
ジョブ実行依頼が入力されると、前記ジョブ実行依頼の内容、依頼されたジョブのジョブＩＤ、および前記ジョブ実行依頼の投入元の識別情報を含むジョブ投入情報を前記ストレージデバイスと前記ジョブＤＢとに格納するジョブ実行依頼受付手段、
前記ジョブ実行依頼受付手段が受け付けた前記ジョブ実行依頼の割り当て先となる１台以上の前記計算ノードをジョブ被配置計算ノードに決定し、前記ジョブ被配置計算ノードに対して前記ジョブの実行に使用すべき資源を示す実行資源情報を付加したジョブ実行指示を送信し、前記ジョブＩＤに対応付けて、前記ジョブ被配置計算ノードの一覧を含むジョブ配置情報と前記ジョブ被配置計算ノードそれぞれの前記実行資源情報とを前記ジョブＤＢに格納し、前記ジョブＩＤに対応付けて前記ジョブ配置情報を前記ストレージデバイスに格納するジョブ実行指示手段、
再起動処理によって前記ジョブＤＢの内容が失われた場合、前記ストレージデバイスから前記ジョブ投入情報と前記ジョブ配置情報とを収集し、前記ジョブ被配置計算ノードから前記実行資源情報を収集し、前記ジョブＤＢ内に前記ジョブ情報を再構築するジョブＤＢ再構築手段、
として機能させることを特徴とするジョブ管理プログラム。

発明の概要を示す図である。 本実施の形態のクラスタシステム構成例を示す図である。 本実施の形態に用いる管理ノードのハードウェア構成例を示す図である。 クラスタシステムの機能を示すブロック図である。 ジョブＤＢのデータ構造例を示す図である。 ストレージデバイスのデータ構造例を示す図である。 ジョブマスタノードの計算ノード内ジョブＤＢのデータ構造例を示す図である。 ジョブスレーブノードの計算ノード内ジョブＤＢのデータ構造例を示す図である。 ジョブの実行例を示す図である。 管理ノードダウン時の状態を示す図である。 管理ノード再起動後の状態を示す図である。 並列ジョブを実行するまでの処理手順を示すシーケンス図である。 管理ノードの復旧処理手順を示すシーケンス図である。 管理ノードとジョブマスタノードとが同時にダウンした状態を示す図である。 管理ノードとジョブマスタノードとの再起動後の状態を示す図である。 刈り取り依頼の状況を示す図である。 刈り取り後の状態を示す図である。 ジョブ再実行依頼の状況を示す図である。 管理ノードとジョブスレーブノードとが同時にダウンした状態を示す図である。 管理ノードとジョブマスタノードとの再起動後の状態を示す図である。 刈り取り依頼の状況を示す図である。 刈り取り後の状態を示す図である。 すべてのノードが同時にダウンした状況を示す図である。 管理ノードとジョブマスタノードとの再起動後の状態を示す図である。 管理ノードと計算ノードとが同時にダウンした場合の復旧処理手順を示すシーケンス図である。 第２の実施の形態に係るクラスタシステムのシステム構成図である。 運用系の管理ノードがダウンした状態を示す図である。 運用系の切り換え状況を示す図である。

符号の説明

１ 管理ノード
１ａ，３ａ，４ａ ジョブＤＢ
１ａａ，２ａ ジョブ投入情報
１ａｂ，２ｂ ジョブ配置情報
１ａｃ，１ａｄ，３ａａ，３ａｂ，４ａａ 実行資源情報
１ｂ ジョブ実行依頼受付手段
１ｃ ジョブ実行指示手段
１ｄ ジョブＤＢ再構築手段
２ ストレージデバイス
３，４ 計算ノード
５ ジョブ投入装置
６ 並列ジョブ

Claims (6)

1. 複数の計算ノードにジョブの実行を指示すると共に、ストレージデバイスが接続されたジョブ管理装置において、
   メインメモリ内に設けられ、ジョブ毎のジョブ情報を記憶するジョブＤＢと、
   ジョブ実行依頼が入力されると、前記ジョブ実行依頼の内容、依頼されたジョブのジョブＩＤ、および前記ジョブ実行依頼の投入元の識別情報を含むジョブ投入情報を前記ストレージデバイスと前記ジョブＤＢとに格納するジョブ実行依頼受付手段と、
   前記ジョブ実行依頼受付手段が受け付けた前記ジョブ実行依頼の割り当て先となる１台以上の前記計算ノードをジョブ被配置計算ノードに決定し、前記ジョブ被配置計算ノードに対して前記ジョブの実行に使用すべき資源を示す実行資源情報を付加したジョブ実行指示を送信し、前記ジョブＩＤに対応付けて、前記ジョブ被配置計算ノードの一覧を含むジョブ配置情報と前記ジョブ被配置計算ノードそれぞれの前記実行資源情報とを前記ジョブＤＢに格納し、前記ジョブＩＤに対応付けて前記ジョブ配置情報を前記ストレージデバイスに格納するジョブ実行指示手段と、
   再起動処理によって前記ジョブＤＢの内容が失われた場合、前記ストレージデバイスから前記ジョブ投入情報と前記ジョブ配置情報とを収集し、前記ジョブ被配置計算ノードから前記実行資源情報を収集し、前記ジョブＤＢ内に前記ジョブ情報を再構築するジョブＤＢ再構築手段と、
   を有することを特徴とするジョブ管理装置。
2. 前記ジョブ実行指示手段は、前記ジョブ被配置計算ノードの中の１台をジョブマスタノード、前記ジョブマスタノード以外の前記計算ノードをジョブスレーブノードとし、前記ジョブマスタノードに対してすべての前記ジョブ被配置計算ノードの前記実行資源情報を付加したジョブ実行指示を送信し、前記ジョブスレーブノードに対して前記ジョブスレーブノード自身の実行資源情報を付加したジョブ実行指示を送信し、
   前記ジョブＤＢ再構築手段は、再起動処理によって前記ジョブＤＢの内容が失われた場合、前記ストレージデバイスから前記ジョブ投入情報と前記ジョブ配置情報とを収集し、前記ジョブマスタノードから前記ジョブ被配置計算ノードすべての実行資源情報を収集し、前記ジョブＤＢ内に前記ジョブ情報を再構築することを特徴とする請求項１記載のジョブ管理装置。
3. 前記ジョブ実行指示手段は、再起動処理が行われた場合、複数の前記計算ノードに対してノード組み込み依頼を送信し、前記ノード組み込み依頼に応じて前記計算ノードから通知されるノード情報を取得し、前記ジョブ配置情報に含まれるすべての前記ジョブ被配置計算ノードから前記ノード情報を取得できたか否かにより、前記ジョブを続行できるかどうかを判断し、続行できる場合、ジョブ運用再開を前記ジョブ被配置計算ノードに対して送信し、続行できない場合、前記ジョブ被配置計算ノードに対してジョブの中止を指示すると共に、前記ジョブ被配置計算ノードに対して前記ジョブ被配置計算ノード自身の前記実行資源情報を付加した前記ジョブ実行指示を送信することを特徴とする請求項１記載のジョブ管理装置。
4. 投入されたジョブを実行するクラスタシステムにおいて、
   ストレージデバイスと、
   複数の計算ノードと、
   メインメモリ内に設けられ、ジョブ毎のジョブ情報を記憶するジョブＤＢと、ジョブ実行依頼が入力されると、前記ジョブ実行依頼の内容、依頼されたジョブのジョブＩＤ、および前記ジョブ実行依頼の投入元の識別情報を含むジョブ投入情報を前記ストレージデバイスと前記ジョブＤＢとに格納するジョブ実行依頼受付手段と、前記ジョブ実行依頼受付手段が受け付けた前記ジョブ実行依頼の割り当て先となる１台以上の前記計算ノードをジョブ被配置計算ノードに決定し、前記ジョブ被配置計算ノードに対して前記ジョブの実行に使用すべき資源を示す実行資源情報を付加したジョブ実行指示を送信し、前記ジョブＩＤに対応付けて、前記ジョブ被配置計算ノードの一覧を含むジョブ配置情報と前記ジョブ被配置計算ノードそれぞれの前記実行資源情報とを前記ジョブＤＢに格納し、前記ジョブＩＤに対応付けて前記ジョブ配置情報を前記ストレージデバイスに格納するジョブ実行指示手段と、再起動処理によって前記ジョブＤＢの内容が失われた場合、前記ストレージデバイスから前記ジョブ投入情報と前記ジョブ配置情報とを収集し、前記ジョブ被配置計算ノードから前記実行資源情報を収集し、前記ジョブＤＢ内に前記ジョブ情報を再構築するジョブＤＢ再構築手段と、を具備する管理ノードと、
   を有することを特徴とするクラスタシステム。
5. 投入されたジョブを実行するクラスタシステムにおいて、
   ストレージデバイスと、
   複数の計算ノードと、
   メインメモリ内に設けられ、ジョブ毎のジョブ情報を記憶する第１のジョブＤＢと、ジョブ実行依頼が入力されると、前記ジョブ実行依頼の内容、依頼されたジョブのジョブＩＤ、および前記ジョブ実行依頼の投入元の識別情報を含むジョブ投入情報を前記ストレージデバイスと前記第１のジョブＤＢとに格納するジョブ実行依頼受付手段と、前記ジョブ実行依頼受付手段が受け付けた前記ジョブ実行依頼の割り当て先となる１台以上の前記計算ノードをジョブ被配置計算ノードに決定し、前記ジョブ被配置計算ノードに対して前記ジョブの実行に使用すべき資源を示す実行資源情報を付加したジョブ実行指示を送信し、前記ジョブＩＤに対応付けて、前記ジョブ被配置計算ノードの一覧を含むジョブ配置情報と前記ジョブ被配置計算ノードそれぞれの前記実行資源情報とを前記第１のジョブＤＢに格納し、前記ジョブＩＤに対応付けて前記ジョブ配置情報を前記ストレージデバイスに格納する第１のジョブ実行指示手段と、を具備する第１の管理ノードと、
   メインメモリ内に設けられ、ジョブ毎のジョブ情報を記憶する第２のジョブＤＢと、前記第１の管理ノードの機能が停止したことを検出した場合、前記ストレージデバイスから前記ジョブ投入情報と前記ジョブ配置情報とを収集し、前記ジョブ被配置計算ノードから前記実行資源情報を収集し、前記第２のジョブＤＢ内に前記ジョブ情報を構築するジョブＤＢ再構築手段と、前記第１の管理ノードの機能が停止したことを検出した場合、複数の前記計算ノードに対してノード組み込み依頼を送信する第２のジョブ実行指示手段と、を具備する第２の管理ノードと、
   を有することを特徴とするクラスタシステム。
6. 複数の計算ノードにジョブの実行を指示すると共に、ストレージデバイスが接続された
   コンピュータを、
   メインメモリ内に設けられ、ジョブ毎のジョブ情報を記憶するジョブＤＢ、
   ジョブ実行依頼が入力されると、前記ジョブ実行依頼の内容、依頼されたジョブのジョブＩＤ、および前記ジョブ実行依頼の投入元の識別情報を含むジョブ投入情報を前記ストレージデバイスと前記ジョブＤＢとに格納するジョブ実行依頼受付手段、
   前記ジョブ実行依頼受付手段が受け付けた前記ジョブ実行依頼の割り当て先となる１台以上の前記計算ノードをジョブ被配置計算ノードに決定し、前記ジョブ被配置計算ノードに対して前記ジョブの実行に使用すべき資源を示す実行資源情報を付加したジョブ実行指示を送信し、前記ジョブＩＤに対応付けて、前記ジョブ被配置計算ノードの一覧を含むジョブ配置情報と前記ジョブ被配置計算ノードそれぞれの前記実行資源情報とを前記ジョブＤＢに格納し、前記ジョブＩＤに対応付けて前記ジョブ配置情報を前記ストレージデバイスに格納するジョブ実行指示手段、
   再起動処理によって前記ジョブＤＢの内容が失われた場合、前記ストレージデバイスから前記ジョブ投入情報と前記ジョブ配置情報とを収集し、前記ジョブ被配置計算ノードから前記実行資源情報を収集し、前記ジョブＤＢ内に前記ジョブ情報を再構築するジョブＤＢ再構築手段、
   として機能させることを特徴とするジョブ管理プログラム。

Images