JP2023183342A - ジョブスケジューラおよびジョブスケジューリング方法 - Google Patents

Abstract

【課題】ジョブを効率的に実行するためのノード数を決定すること。【解決手段】ログインノードは、パラメータ（Ｎnode、ｔcmpt、ｔcomm、ｐabn、αabn、ｔbench）の指定に基づいて、性能モデルＭを作成する。ログインノードは、性能モデルＭを用いて、Ｅ［Ｃ］を最小化するＮspareを決定する。例えば、Ｎnodeを「Ｎnode＝３」とし、Ｎspareが「Ｎspare＝１」に決定されたとする。この場合、管理用ノードは、ＮspareとＮnodeとを合計した４つ分のノード１１０１～１１０４にジョブを割り当てる。ノード１１０１は、ノード１１０１～１１０４それぞれにベンチマークを実行させる。ノード１１０１は、「Ｎnode＝３」から、ベンチマーク時間が短いほうから３つ分のノード１１０１，１１０２，１１０４を選択し、ノード１１０１，１１０２，１１０４にアプリを実行させる。【選択図】図１１

Description

本発明は、ジョブスケジューラおよびジョブスケジューリング方法に関する。

従来、多数の高性能計算機を含むクラスタ型のスーパーコンピュータがある。クラスタ型のスーパーコンピュータでは、例えば、ジョブスケジューラにより、ユーザから投入された計算ジョブを空きノードに割り当てて、アプリケーションの計算を行う。スーパーコンピュータは、例えば、気象予測、宇宙開発、遺伝子解析などの大規模で高度な科学技術計算に利用される。

先行技術としては、パフォーマンス管理とアプリケーション配置管理のタスクを動的に調整するためのものがある。また、各プロセッサユニットの動作テストの結果、正常に動作すると確認されたプロセッサユニットに対して、データ処理プログラムを各プロセッサユニットに分配して、かつ、分割されたデータを各プロセッサユニットに割り当てる技術がある。

また、数量モデルに性能仕様情報を順次代入して、プールサーバごとにスループットを算出し、スループット変化分よりも大きく、かつ最も近い値を示すスループットに対応するプールサーバを選択して構成変更制御を実行するよう指示する技術がある。また、アプリケーションを並列実行するノードの故障の可能性を予測し、故障の可能性が閾値を超えた計算ノードを、次のスケジュールされたチェックポイントにおいて、予備の計算ノードに移行させる技術がある。また、ＨＰＣ（Ｈｉｇｈ Ｐｅｒｆｏｒｍａｎｃｅ Ｃｏｍｐｕｔｉｎｇ）環境におけるジョブ管理を行うための技術がある。

特表２００８－５１５１０６号公報 特開平１０－１６２１３０号公報 国際公開第２００７／０３４８２６号 米国特許出願公開第２０１０／０２２３３７９号明細書 米国特許出願公開第２０２０／０００４６４８号明細書 米国特許出願公開第２０１８／０１２１２５３号明細書

しかしながら、従来技術では、スーパーコンピュータ内のノードにシステム側が検出できないような異常が発生すると、ジョブに異常ノードが割り当てられて、アプリケーションの計算性能が低下する場合がある。例えば、冗長なノード数でジョブを投入することで、計算性能の低下を抑えることも考えられるが、ノード数が多すぎると、スーパーコンピュータの利用効率の低下や利用料金の増大を招くという問題がある。また、ノード数が少なすぎると、依然として計算性能が低下するという問題がある。

一つの側面では、本発明は、ジョブを効率的に実行するためのノード数を決定することを目的とする。

１つの実施態様では、システム内の１以上のノードによりジョブを実行するにあたり、前記ジョブの実行にかかるアプリケーションの使用ノード数と、前記システム内のノードの異常発生確率と、前記システム内の異常ノードの正常ノードに対する処理時間の比率と、前記ジョブ内で前記アプリケーションの前に実行されるベンチマークの実行にかかるベンチマーク時間との指定を受け付け、受け付けた前記指定に基づいて、前記ジョブの実行にかかる実行時間の期待値、前記使用ノード数および前記ジョブにおける予備ノード数から、前記ジョブの実行にかかるリソース消費量の期待値を出力する性能モデルを作成し、作成した前記性能モデルを用いて、前記リソース消費量の期待値を最小化する前記予備ノード数を決定する、ジョブスケジューラが提供される。

本発明の一側面によれば、ジョブを効率的に実行するためのノード数を決定することができるという効果を奏する。

図１は、実施の形態にかかるジョブスケジューリング方法の一実施例を示す説明図である。 図２は、ジョブスケジューリングシステム２００のシステム構成例を示す説明図である。 図３は、ネットワークトポロジーの一例を示す説明図である。 図４は、ログインノード２０１等のハードウェア構成例を示すブロック図である。 図５は、ログインノード２０１の機能的構成例を示すブロック図である。 図６は、Ｅ［Ｃ］の算出例を示す説明図である。 図７は、ノードＮｉの機能的構成例を示すブロック図である。 図８は、ベンチマーク実行時間テーブル８００の記憶内容の一例を示す説明図である。 図９は、ジョブスケジューリングシステム２００の動作例を示す説明図である。 図１０は、ノード間の接続例を示す説明図である。 図１１は、ジョブの実行例を示す説明図である。 図１２は、ログインノード２０１のジョブ投入処理手順の一例を示すフローチャート（その１）である。 図１３は、ログインノード２０１のジョブ投入処理手順の一例を示すフローチャート（その２）である。 図１４は、ＥＣ算出処理の具体的処理手順の一例を示すフローチャートである。 図１５は、ノードＮｉのジョブ実行制御処理手順の一例を示すフローチャートである。 図１６Ａは、各ノードのベンチマーク時間の具体例を示す説明図（その１）である。 図１６Ｂは、各ノードのベンチマーク時間の具体例を示す説明図（その２）である。 図１７は、Ｅ［Ｃ］の予測例を示す説明図である。

以下に図面を参照して、本発明にかかるジョブスケジューラおよびジョブスケジューリング方法の実施の形態を詳細に説明する。

（実施の形態）
図１は、実施の形態にかかるジョブスケジューリング方法の一実施例を示す説明図である。図１において、情報処理装置１０１は、システム内の１以上のノードによりジョブを実行するにあたり、予備ノード数を決定するコンピュータである。システムは、相互に通信可能な複数のノードを含む。システムは、例えば、クラスタ型のスーパーコンピュータ（スパコン）である。

ノードは、通信機能を有し、各種処理を実行可能なコンピュータである。ノードは、例えば、物理サーバであってもよく、仮想マシンであってもよい。ジョブは、コンピュータにおける処理作業の単位であり、例えば、ユーザによって指定される計算単位である。ジョブ内で実行される処理は、例えば、ユーザ依存の処理である。

例えば、ジョブ内で実行される処理は、ＭＰＩ（Ｍｅｓｓａｇｅ Ｐａｓｓｉｎｇ Ｉｎｔｅｒｆａｃｅ）などによって並列化されたプログラム（アプリケーション）により全ノードが協調して計算を行うことが多い。並列化されたプログラムでは、ノードごとの計算とノード同士の通信が行われる。

例えば、深層学習では、ｃｏｌｌｅｃｔｉｖｅ通信（パラメータの同期）とノードごとの計算（ｆｏｒｗａｒｄ，ｂａｃｋｗａｒｄ計算）が交互に行われる。また、流体解析では、ｃｏｌｌｅｃｔｉｖｅ通信・Ｐ２Ｐ通信（ＣＧ法の内積・疎行列ベクトル積）とノードごとの計算が交互に行われる。

予備ノードは、ジョブを実行するにあたり、余分に準備されるノードである。予備ノード数は、ジョブの実行にかかるアプリケーションに使用されるノード数よりも多い数のノードを準備する場合の冗長分のノード数である。

ここで、ジョブスケジューラは、ユーザが指定した計算単位（ジョブ）をスケジューリングして、スパコンなどのノードに割り当てるソフトウェアである。各ジョブは、例えば、計算内容、使用ノード数、最大使用時間（ｗａｌｌ－ｔｉｍｅ）の情報を持つ。通常、ユーザは、特定のノードを選択して使用することはできない。

一般的なジョブスケジューラでは、例えば、先にキューに投入されたジョブが先に実行される。例えば、各ジョブＡ，Ｂ，Ｃが、「ジョブＡ→ジョブＢ→ジョブＣ」の順にキューに投入されたとする。また、スパコンの合計ノード数を「８ノード」とする。また、ジョブＡの使用ノード数を「３」とし、ジョブＢの使用ノード数を「４」とし、ジョブＣの使用ノード数を「４」とする。

この場合、ジョブＡがジョブＣよりも先にキューに投入されたため、遊休ノードを発生させてでも、ジョブＣよりもジョブＡが優先される。例えば、ノード１～８のうち、ノード１～３がジョブＡに割り当てられ、ノード４～７がジョブＢに割り当てられると、ノード８が遊休ノードとなる。なお、１～８は、ノードＩＤに相当する。

この結果、連続しないノードＩＤのノードがジョブに割り当てられる場合がある。例えば、ジョブＢが実行中にジョブＡの実行が完了してジョブＣを実行可能となった場合、ノード１～３，８にジョブＣが割り当てられる。ノード１～３とノード８は、ノードＩＤが連続しないノードである。

また、各ジョブに割り当てられたノードは、例えば、ジョブの計算終了時またはｗａｌｌ－ｔｉｍｅ超過時に直ちに解放される。例えば、ジョブＡのｗａｌｌ－ｔｉｍｅを「１時間」とした場合に、ジョブＡの計算が４５分で完了すると、ジョブＡに割り当てられたノード１～３が、ｗａｌｌ－ｔｉｍｅ（１時間）を待たずに解放されて、次のジョブに割り当てられる。また、ジョブＣのｗａｌｌ－ｔｉｍｅを「１時間」とした場合、ジョブＣの計算が１時間で完了していなくても、ジョブＣに割り当てられたノード１～３，８が、ｗａｌｌ－ｔｉｍｅ（１時間）超過時に解放される。

また、一般的なジョブスケジューラでは、ｂａｃｋｆｉｌｌと呼ばれる仕組みにより、遊休ノードについてはキューの追い越しが容認される場合がある。例えば、ジョブＣの後にジョブＤが投入されたとする。ジョブＤの使用ノード数を「１」とする。この場合、ノード１～８のうち、ノード１～３がジョブＡに割り当てられ、ノード４～７がジョブＢに割り当てられ、さらに、ジョブＣよりも後に投入されたジョブＤにノード８が割り当てられる。ｂａｃｋｆｉｌｌにより、遊休ノードを減らし、スパコン全体の利用効率を向上させることができる。

ここで、スパコンのノードは、ハードウェア異常やプロセス（ソフトウェア）異常が発生することがある。このような異常をシステム側によって検出しきれない場合、ユーザに異常ノードが割り当てられて、アプリケーションの計算性能が低下する場合がある。例えば、異常ノードを含むノード群にジョブが割り当てられると、異常ノードに律速されて計算性能が低下し、ひいては、スパコンの利用効率の低下やユーザの利用料金の増大につながる。

アプリケーションの性能低下の要因となりえる異常としては、以前にノードで実行されたジョブの影響により発生する異常がある。例えば、前ジョブで生成されたプロセスやローカルファイルがシステムにより消去または初期化されず、異常が発生することがある。また、前ジョブで性能に影響する設定（例えば、クロック周波数など）が変更されたにもかかわらず、システムにより復元されず、異常が発生することがある。

また、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）レベルで動作しているプロセスやデーモンの異常やバグにより発生する異常がある。また、プロセッサの消費電力特性に差異があるために使用されるクロック周波数が異なるなどのハードウェアの個体差により発生する異常がある。

また、ノード間のネットワーク（インターコネクト）が他のジョブと共有されており、他ジョブの通信によって待ち時間が発生する場合がある。また、単一のノードを論理的に複数のジョブで共有する機能を有するスパコンにおいては、プロセッサやメモリなどのハードウェアについて、他ジョブと競合する場合がある。

このような異常は、ユーザがジョブを投入して結果を確認することで、はじめて発見されることが多いが、ユーザ側では原因の特定が困難である。例えば、アプリケーションの実行時間は実行前に明らかになっていないことがあり、性能低下の原因が特定のノードに起因するものなのかを判定すること自体が難しい。

また、ｗａｌｌ－ｔｉｍｅを超過してアプリケーションが強制終了される場合、処理結果を確認するためのログをアプリケーションが出力する前に強制終了されると、ユーザ側で性能低下の原因を特定することが難しい。また、管理者側はユーザが実行するアプリケーションには関知しないことが多いため、ユーザと管理者側との協議によって解決することが難しい。

また、問題の性質上、多数のノードを使用するジョブで性能低下が生じる可能性が高いため、そのノードの中から原因となるノードを絞り込む作業が発生する。しかし、ノードを絞り込む作業には、多くの時間や負荷がかかる。また、一般的なジョブスケジューラでは、ユーザ側で特定のノードを指定してジョブを投入することができない。このため、ユーザ側で原因と思われるノードを厳密に固定して検証を行うことができない。

また、一般的なジョブスケジューラでは、ｂａｃｋｆｉｌｌの仕組みにより、例えば、ｗａｌｌ－ｔｉｍｅ超過時にジョブを再投入または異常発見時に手動で再投入するようにした場合、再度原因となる異常ノードが割り当てられる可能性がある。このため、ジョブの再投入は、問題の解決方法にはならない。

このため、最初に冗長なノード数でジョブを投入し、そのノードの中から処理が遅いノードを排除してアプリケーションの計算を行うことで、計算性能の低下を抑えることが考えられる。しかしながら、ノード数が多すぎると、利用効率の低下や利用料金の増大を招くという問題がある。一方、ノード数が少なすぎると、依然として計算性能が低下するという問題がある。

そこで、本実施の形態では、異常ノードの発生を考慮して冗長なノード数でジョブを投入するにあたり、ジョブを効率的に実行するためのノード数を決定するジョブスケジューリング方法について説明する。ここで、情報処理装置１０１の処理例（下記（１）～（３）の処理に対応）について説明する。

（１）情報処理装置１０１は、システム内の１以上のノードによりジョブを実行するにあたり、パラメータ１１０の指定を受け付ける。パラメータ１１０の指定は、例えば、ジョブを投入するユーザによって行われる。パラメータ１１０は、ジョブの実行にかかるアプリケーションの使用ノード数を含む。使用ノード数は、１以上の値であり、例えば、アプリケーションの性質や計算速度などを考慮して決定される。

また、パラメータ１１０は、システム内のノードの異常発生確率を含む。異常発生確率は、システム内の全ノードで共通の値であり、０以上１以下の値である。システムは、例えば、複数のノード（高性能計算機）を含むスーパーコンピュータである。また、パラメータ１１０は、システム内の異常ノードの正常ノードに対する処理時間の比率を含む。

異常ノードは、アプリケーションの性能低下の要因となりえる異常が発生しているノードである。正常ノードは、異常ノード以外の非異常ノードである。処理時間は、例えば、アプリケーションにおける計算にかかる処理時間や、ベンチマークの実行にかかる処理時間である。処理時間の比率は、例えば、正常ノードの処理時間に対する異常ノードの処理時間の増加率によって表される、１より大きい値である。

また、パラメータ１１０は、ベンチマークの実行にかかるベンチマーク時間を含む。ベンチマークは、ジョブ内でアプリケーションの前に実行されるノードの性能評価用のソフトウェアである。ベンチマークは、冗長なノード数でジョブに割り当てたノード群の中から排除するノードを判定するために実行される。

また、パラメータ１１０には、例えば、アプリケーションの実行時間のうち異常ノードによる性能低下の影響を受ける第１の処理時間と、異常ノードによる性能低下の影響を受けない第２の処理時間とが含まれていてもよい。第１の処理時間は、例えば、アプリケーションにおける各ノードの計算にかかる計算時間である。第２の処理時間は、例えば、アプリケーションにおけるノード間の通信にかかる通信時間である。

ただし、第１の処理時間および第２の処理時間は、システム側で指定される値であってもよい。例えば、情報処理装置１０１は、第１の処理時間をジョブのｗａｌｌ－ｔｉｍｅ等から定まる値とし、第２の処理時間を固定値（例えば、０）としてもよい。

（２）情報処理装置１０１は、受け付けたパラメータ１１０の指定に基づいて、性能モデル１２０を作成する。性能モデル１２０は、ジョブの実行にかかる実行時間の期待値、使用ノード数およびジョブにおける予備ノード数から、ジョブの実行にかかるリソース消費量の期待値を出力するモデルである。

リソース消費量は、冗長なノード数でジョブを投入した際に消費されるシステムのリソース量を表すものである。リソース消費量は、予備ノードとベンチマークの分、ジョブ実行時のノード数やノードの使用時間が増加することを考慮したコストに相当する。

具体的には、例えば、情報処理装置１０１は、受け付けたパラメータ１１０の指定に基づいて、所定のモデル式（例えば、後述する第１モデル式、第２モデル式、第３モデル式、第４モデル式および第５モデル式）から性能モデル１２０を作成する。性能モデル１２０を作成する具体的な処理例については、図５を用いて後述する。

（３）情報処理装置１０１は、作成した性能モデル１２０を用いて、ジョブの実行にかかるリソース消費量の期待値を最小化する予備ノード数を決定する。具体的には、例えば、情報処理装置１０１は、性能モデル１２０を用いて、予備ノード数を０からアプリケーションの使用ノード数まで順に変化させながら、リソース消費量の期待値Ｃを算出する。

そして、情報処理装置１０１は、算出したリソース消費量の期待値Ｃのうち最小値に対応する予備ノード数を、リソース消費量の期待値を最小化する予備ノード数に決定してもよい。決定された予備ノード数は、冗長なノード数でジョブを投入する際の冗長分のノード数として用いられる。

このように、情報処理装置１０１によれば、異常ノードの発生を考慮して冗長なノード数でジョブを投入するにあたり、ジョブの実行にかかるリソース消費量の期待値Ｃを最小化する予備ノード数を探索して、ジョブを効率的に実行するためのノード数を決定することができる。これにより、情報処理装置１０１は、ジョブの実行にかかるリソース消費量の期待値を最小化する予備ノード数を指定して、ジョブを投入することができる。

（ジョブスケジューリングシステム２００のシステム構成例）
つぎに、図１に示した情報処理装置１０１を含むジョブスケジューリングシステム２００のシステム構成例について説明する。ここでは、図１に示した情報処理装置１０１を、ジョブスケジューリングシステム２００内のログインノード２０１に適用した場合を例に挙げて説明する。ジョブスケジューリングシステム２００は、例えば、流体解析、構造解析、電磁界解析などのジョブを実行するためのスーパーコンピュータに適用される。

図２は、ジョブスケジューリングシステム２００のシステム構成例を示す説明図である。図２において、ジョブスケジューリングシステム２００は、ログインノード２０１と、管理用ノード２０２と、クライアント端末２０３と、ストレージサーバ２０４と、計算ノードＮ１～Ｎｎ（ｎ：２以上の自然数）と、を含む。ジョブスケジューリングシステム２００において、ログインノード２０１、管理用ノード２０２、クライアント端末２０３、ストレージサーバ２０４および計算ノードＮ１～Ｎｎは、有線または無線のネットワーク２１０を介して接続される。ネットワーク２１０は、例えば、インターネット、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）などである。

以下の説明では、計算ノードＮ１～Ｎｎのうちの任意の計算ノードを「計算ノードＮｉ」と表記する場合がある（ｉ＝１，２，…，ｎ）。また、計算ノードを単に「ノード」と表記する場合がある。

ここで、ログインノード２０１は、ユーザが直接操作可能なコンピュータである。ログインノード２０１は、例えば、後述の図９に示すような投入スクリプトＰ１を実行する。投入スクリプトＰ１は、ジョブを投入するための情報処理プログラムである。ログインノード２０１は、例えば、サーバである。

管理用ノード２０２は、ジョブスケジューリングシステム２００を運用するためのコンピュータである。管理用ノード２０２は、例えば、後述の図９に示すようなジョブスケジューラＰ２を実行する。ジョブスケジューラＰ２は、ジョブスケジューリングのためのプログラムである。管理用ノード２０２は、例えば、サーバである。

クライアント端末２０３は、ジョブスケジューリングシステム２００のユーザが使用するコンピュータである。例えば、ユーザは、クライアント端末２０３からログインノード２０１を操作することにより、ジョブの投入などを行う。クライアント端末２０３は、例えば、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）、タブレットＰＣなどである。

ストレージサーバ２０４は、ファイルシステムＦＳを有し、各種ノード２０１，２０２，Ｎ１～Ｎｎが実行する各種プログラムの本体（実行形式ファイル）やデータを記憶するコンピュータである。各種ノード２０１，２０２，Ｎ１～Ｎｎは、例えば、ストレージサーバ２０４のファイルシステムＦＳにアクセスして、各種プログラムの情報を取得する。

計算ノードＮ１～Ｎｎは、ジョブの割当先となるコンピュータである。ジョブが割り当てられたノード群のうちのいずれか１つのノードＮｉでは、後述の図９に示すようなジョブスクリプトＰ３が実行される。ジョブスクリプトＰ３は、ジョブの実行にかかるアプリケーションを実行するための情報処理プログラムである。各計算ノードＮ１～Ｎｎは、例えば、サーバである。

ジョブスケジューリングシステム２００において、例えば、計算ノード同士や、ログインノード２０１、管理用ノード２０２およびストレージサーバ２０４は、図３に示すようなネットワークトポロジー（通信アーキテクチャ）のインターコネクトで通信可能である。ジョブスケジューリングシステム２００内のインターコネクトの具体例としては、例えば、ファットツリー（Ｆａｔ Ｔｒｅｅ）型のネットワークが挙げられる。

なお、ここではログインノード２０１と管理用ノード２０２と計算ノードＮｉとを別体に設けることにしたが、これに限らない。例えば、ログインノード２０１、管理用ノード２０２および計算ノードＮｉは、１台のコンピュータにより実現されてもよい。また、ログインノード２０１は、管理用ノード２０２により実現されてもよい。また、管理用ノード２０２は、計算ノードＮｉにより実現されてもよい。また、投入スクリプトＰ１は、例えば、ジョブスケジューラＰ２の１機能として実現してもよい。また、ジョブスクリプトＰ３は、例えば、ジョブスケジューラＰ２の１機能として実現してもよい。

（ネットワークトポロジー）
ここで、図３を用いて、ジョブスケジューリングシステム２００内のインターコネクトのネットワークトポロジーについて説明する。

図３は、ネットワークトポロジーの一例を示す説明図である。図３において、ノード３０１～３０８は、図２に示した計算ノードＮ１～Ｎｎの一例である。ノード３０１～３０８は、スイッチ３１１～３１３（ネットワークデバイス）を介して接続されている。ここでは、ツリー状のネットワーク構造の上流側の経路が冗長化されている。これにより、ノード３０１～３０８は、非連続の物理的配置にあるノード間においても高性能な通信が可能である。

（ログインノード２０１等のハードウェア構成例）
つぎに、図２に示したログインノード２０１、管理用ノード２０２、ストレージサーバ２０４および計算ノードＮ１～Ｎｎのハードウェア構成例について説明する。ここでは、ログインノード２０１、管理用ノード２０２、ストレージサーバ２０４および計算ノードＮ１～Ｎｎを「ログインノード２０１等」と表記する。

図４は、ログインノード２０１等のハードウェア構成例を示すブロック図である。図４において、ログインノード２０１等は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）４０１と、メモリ４０２と、ディスクドライブ４０３と、ディスク４０４と、通信Ｉ／Ｆ（Ｉｎｔｅｒｆａｃｅ）４０５と、可搬型記録媒体Ｉ／Ｆ４０６と、可搬型記録媒体４０７と、を有する。また、各構成部は、バス４００によってそれぞれ接続される。

ここで、ＣＰＵ４０１は、ログインノード２０１等の全体の制御を司る。ＣＰＵ４０１は、複数のコアを有していてもよい。メモリ４０２は、例えば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）およびフラッシュＲＯＭなどを有する。具体的には、例えば、フラッシュＲＯＭがＯＳのプログラムを記憶し、ＲＯＭがアプリケーションプログラムを記憶し、ＲＡＭがＣＰＵ４０１のワークエリアとして使用される。メモリ４０２に記憶されるプログラムは、ＣＰＵ４０１にロードされることで、コーディングされている処理をＣＰＵ４０１に実行させる。

ディスクドライブ４０３は、ＣＰＵ４０１の制御に従ってディスク４０４に対するデータのリード／ライトを制御する。ディスク４０４は、ディスクドライブ４０３の制御で書き込まれたデータを記憶する。ディスク４０４としては、例えば、磁気ディスク、光ディスクなどが挙げられる。

通信Ｉ／Ｆ４０５は、通信回線を通じてネットワーク２１０に接続され、ネットワーク２１０を介して外部のコンピュータに接続される。そして、通信Ｉ／Ｆ４０５は、ネットワーク２１０と装置内部とのインターフェースを司り、外部のコンピュータからのデータの入出力を制御する。通信Ｉ／Ｆ４０５には、例えば、モデムやＬＡＮアダプタなどを採用することができる。

可搬型記録媒体Ｉ／Ｆ４０６は、ＣＰＵ４０１の制御に従って可搬型記録媒体４０７に対するデータのリード／ライトを制御する。可搬型記録媒体４０７は、可搬型記録媒体Ｉ／Ｆ４０６の制御で書き込まれたデータを記憶する。可搬型記録媒体４０７としては、例えば、ＣＤ（Ｃｏｍｐａｃｔ Ｄｉｓｃ）－ＲＯＭ、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）メモリなどが挙げられる。

なお、ログインノード２０１等は、上述した構成部のほかに、例えば、入力装置、ディスプレイなどを有することにしてもよい。また、ログインノード２０１等は、上述した構成部のうち、例えば、可搬型記録媒体Ｉ／Ｆ４０６、可搬型記録媒体４０７を有さないことにしてもよい。また、図２に示したクライアント端末２０３についても、ログインノード２０１等と同様のハードウェア構成により実現することができる。ただし、クライアント端末２０３は、上述した構成部のほかに、例えば、入力装置、ディスプレイなどを有する。

（ログインノード２０１の機能的構成例）
つぎに、ログインノード２０１の機能的構成例について説明する。

図５は、ログインノード２０１の機能的構成例を示すブロック図である。図５において、ログインノード２０１は、受付部５０１と、作成部５０２と、決定部５０３と、投入部５０４と、を含む。受付部５０１～投入部５０４は制御部５００となる機能であり、具体的には、例えば、図４に示したログインノード２０１のメモリ４０２、ディスク４０４、可搬型記録媒体４０７などの記憶装置に記憶されたプログラム（後述の図９に示すような投入スクリプトＰ１）をＣＰＵ４０１に実行させることにより、または、通信Ｉ／Ｆ４０５により、その機能を実現する。各機能部の処理結果は、例えば、ログインノード２０１のメモリ４０２、ディスク４０４などの記憶装置に記憶される。

受付部５０１は、ジョブスケジューリングシステム２００内の１以上のノードによりジョブを実行するにあたり、パラメータの指定を受け付ける。パラメータは、例えば、Ｎ_node、ｐ_abn、α_abn、ｔ_benchを含む。ここで、Ｎ_nodeは、ジョブの実行にかかるアプリケーションの使用ノード数を表す。Ｎ_nodeは、例えば、ユーザがアプリケーションの性質や計算速度などを考慮して決定する。

以下の説明では、ジョブの実行にかかるアプリケーションを単に「アプリ」と表記する場合がある。

ｐ_abnは、ジョブスケジューリングシステム２００内のノードの異常発生確率を表す。ｐ_abnは、ジョブスケジューリングシステム２００の全ノードで共通の値であり、０以上１以下の値である。各ノードは、ｐ_abnで異常であり、かつ、ジョブ実行中は状態が変化しないと仮定する。

α_abnは、ジョブスケジューリングシステム２００内の異常ノードの正常ノードに対する処理時間の比率（増加率）を表す係数（異常ノード計算時間係数）である。α_abnは、１より大きい値である。異常ノードは、計算時間（ｔ_bench，ｔ_cmpt）がα_abn倍されると仮定する。例えば、異常ノードは、正常ノードに比べて、ｔ_benchがα_abn倍増加する。

ｔ_benchは、ベンチマークの実行にかかるベンチマーク時間を表す。ベンチマークは、ジョブ内でアプリの前に実行されるノードの性能評価用のソフトウェアである。ベンチマークとしては、例えば、ＬＩＮＰＡＣＫ等の計算律速となる軽量なソフトウェアが使用される。

ここでは、全ノードでベンチマークを実行した場合に、全ノードにおけるベンチマーク時間を降順にソートすると、異常ノードが最上位になると仮定する。この際、異常ノード数が、ジョブにおける予備ノード数以下であれば、異常ノードをアプリの実行から排除できる。一方、異常ノード数が予備ノード数より大きい場合は、異常ノードをアプリの実行から排除できない。

また、パラメータは、例えば、ｔ_cmpt、ｔ_commを含むものであってもよい。ｔ_cmptは、アプリにおける各ノードの計算にかかる計算時間である（ただし、ｔ_cmpt＞０）。ｔ_cmptは、アプリの実行時間のうち異常ノードによる性能低下の影響を受ける第１の処理時間の一例である。

ｔ_commは、アプリにおけるノード間の通信にかかる通信時間である（ただし、ｔ_comm≧０）。ｔ_commは、アプリの実行時間のうち異常ノードによる性能低下の影響を受けない第２の処理時間の一例である。ｔ_cmpt，ｔ_commは、例えば、ユーザがアプリケーションの性質や計算速度などを考慮して決定する。

なお、アプリの中には、Ｉ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）などの計算と通信の両方に当てはまらない時間が支配的なものがある。この場合、ｔ_cmptをアプリの実行時間のうち異常ノードによる性能低下の影響を受ける第１の処理時間として値を指定し、ｔ_commを異常ノードによる性能低下の影響を受けない第２の処理時間として値を指定してもよい。

具体的には、例えば、受付部５０１は、図２に示したクライアント端末２０３からジョブの投入依頼を受信することにより、ジョブの投入依頼に含まれるパラメータの指定を受け付けることにしてもよい。ジョブの実行依頼には、例えば、上述したパラメータのほかに、ジョブの計算内容や最大使用時間（ｗａｌｌ－ｔｉｍｅ）などの情報が含まれる。

作成部５０２は、受け付けたパラメータの指定に基づいて、性能モデルＭを作成する。性能モデルＭは、Ｅ［Ｔ_total］およびＮ_totalから、Ｅ［Ｃ］を出力するモデル式を含む。Ｅ［Ｔ_total］は、Ｔ_totalの期待値を表す。Ｔ_totalは、ジョブ時間を表す。ジョブ時間は、ジョブの実行にかかる実行時間である。

Ｎ_totalは、ジョブの実行にかかる全ノード数を表す。Ｎ_totalは、Ｎ_nodeとＮ_spareとを合計した数である（ただし、Ｎ_totalは１以上最大ノード数以下の整数）。Ｎ_nodeは、ジョブの実行にかかるアプリの使用ノード数を表す（ただし、Ｎ_nodeは１以上最大ノード数以下の整数）。Ｎ_spareは、ジョブにおける予備ノード数を表す（ただし、Ｎ_spareは１以上最大ノード数以下の整数）。

Ｅ［Ｃ］は、ノード時間（コスト）の期待値を表す。ノード時間は、ジョブの実行にかかるリソース消費量を表す指標であり、例えば、ジョブの実行にかかる（ノード数）と（ノードの使用時間）とを乗算した値（例えば、後述の図１１に示す点線枠１１１０の面積に相当）に相当する。図１に示した性能モデル１２０は、例えば、性能モデルＭに対応する。

具体的には、例えば、作成部５０２は、Ｎ_totalとＮ_abnとに基づいて、ジョブ内に異常ノードが存在する確率（存在確率）を表す第１モデル式を作成する。ここで、Ｎ_totalは、下記式（１）によって表される。

Ｎ_total＝Ｎ_node＋Ｎ_spare ・・・（１）

また、Ｎ_abnは、ジョブ内の異常ノード数を表す。Ｎ_abnは、例えば、Ｎ_totalとｐ_abnとを用いて、下記式（２）のように表すことができる。ただし、Ｂ（ｎ，ｐ）は、試行回数ｎ、確率ｐの二項分布を表す。また、～は、確率分布に従うことを意味する。

Ｎ_abn～Ｂ（Ｎ_total，ｐ_abn） ・・・（２）

そして、作成部５０２は、上記式（１）および（２）を用いて、下記式（３）のような第１モデル式を作成することができる。ただし、Ｐ［Ｎ_abn＞０］は、ジョブ内に異常ノードが存在する確率である（Ｐ［Ｎ_abn＞０］∈［０，１］）。下記式（３）中の指数部分の「Ｎｔｏｔａｌ」は「Ｎ_total」を表す。

Ｐ［Ｎ_abn＞０］＝１－（１－ｐ_abn）^Ntotal ・・・（３）

また、作成部５０２は、Ｐ［Ｎ_abn＞０］とα_abnとｔ_benchとに基づいて、ジョブにおけるベンチマークの実行にかかるベンチマーク時間を表す第２モデル式を作成する。第２モデル式は、例えば、下記式（４）および（５）によって表すことができる。

ただし、Ｔ_benchは、ジョブにおけるベンチマークの実行にかかるベンチマーク時間である。Ｐ［Ｔ_bench＝α_abn・ｔ_bench］は、Ｔ_benchが「Ｔ_bench＝α_abn・ｔ_bench」となる確率を表す。Ｐ［Ｔ_bench＝ｔ_bench］は、Ｔ_benchが「Ｔ_bench＝ｔ_bench」となる確率を表す。異常ノードが１つでも存在する場合は「Ｔ_bench＝α_abn・ｔ_bench」となり、それ以外の場合は「Ｔ_bench＝ｔ_bench」となる。

Ｐ［Ｔ_bench＝α_abn・ｔ_bench］＝Ｐ［Ｎ_abn＞０］ ・・・（４）
Ｐ［Ｔ_bench＝ｔ_bench］＝１－Ｐ［Ｎ_abn＞０］ ・・・（５）

また、作成部５０２は、Ｎ_nodeとＮ_spareとｐ_abnとに基づいて、アプリの実行から異常ノードを排除できる確率（排除確率）を表す第３モデル式を作成する。第３モデル式は、例えば、下記式（６）によって表すことができる。ただし、Ｐ［Ｎ_abn≦Ｎ_spare］は、アプリの実行から異常ノードを排除できる確率である（Ｐ［Ｎ_abn≦Ｎ_spare］∈［０，１］）。Ｎ_totalは、上記式（１）によって表される。

また、作成部５０２は、ｔ_cmptとｔ_commとα_abnとＰ［Ｎ_abn≦Ｎ_spare］とに基づいて、ジョブにおけるアプリ時間を表す第４モデル式を作成する。アプリ時間は、アプリの実行にかかる実行時間である。第４モデル式は、例えば、下記式（７）および（８）によって表すことができる。

ただし、Ｔ_appは、ジョブにおけるアプリ時間である（Ｔ_app＞０）。Ｐ［Ｔ_app＝α_abn・ｔ_cmpt＋ｔ_comm］は、Ｔ_appが「Ｔ_app＝α_abn・ｔ_cmpt＋ｔ_comm」となる確率を表す。Ｐ［Ｔ_app＝ｔ_cmpt＋ｔ_comm］は、Ｔ_appが「Ｔ_app＝ｔ_cmpt＋ｔ_comm」となる確率を表す。異常ノード数が予備ノード数を超えた場合は「Ｔ_app＝α_abn・ｔ_cmpt＋ｔ_comm」となり、それ以外の場合は「Ｔ_app＝ｔ_cmpt＋ｔ_comm」となる。

Ｐ［Ｔ_app＝α_abn・ｔ_cmpt＋ｔ_comm］＝１－Ｐ［Ｎ_abn≦Ｎ_spare］・・・（７）
Ｐ［Ｔ_app＝ｔ_cmpt＋ｔ_comm］＝Ｐ［Ｎ_abn≦Ｎ_spare］・・・（８）

また、作成部５０２は、ジョブにおけるベンチマーク時間とジョブにおけるアプリ時間とに基づいて、ジョブ時間の期待値を表す第５モデル式を作成する。ジョブ時間は、ジョブの実行にかかる実行時間である。ジョブ時間は、ジョブにおけるベンチマーク時間とジョブにおけるアプリ時間とを合わせた時間であり、下記式（９）によって表される。ただし、Ｔ_totalは、ジョブ時間である。

Ｔ_total＝Ｔ_bench＋Ｔ_app ・・・（９）

より具体的には、例えば、作成部５０２は、上記式（４）、（５）、（７）、（８）および（９）から、下記式（１０）のような第５モデル式を作成することができる。ただし、Ｅ［Ｔ_total］は、ジョブ時間の期待値である（＞０）。Ｅ［Ｔ_bench］は、ジョブにおけるベンチマーク時間の期待値である。Ｅ［Ｔ_app］は、ジョブにおけるアプリ時間の期待値である。

そして、作成部５０２は、作成した第５モデル式およびＮ_totalに基づいて、性能モデルＭを作成する。Ｎ_totalは、上記式（１）によって表される。性能モデルＭは、例えば、下記式（１１）によって表すことができる。ただし、Ｅ［Ｃ］は、ノード時間（コスト）の期待値である（Ｃ＞０）。

Ｅ［Ｃ］＝Ｎ_total・Ｅ［Ｔ_total］ ・・・（１１）

なお、本手法を使用しない場合（後述するＡｓ－ｉｓに対応）のノード時間の期待値は、「ｔ_bench＝０，Ｎ_spare＝０」とした場合のＥ［Ｃ］と等価である（ベンチマークの実行を行わず、予備ノードを使用しないため）。この場合、Ｔ_benchは「Ｔ_bench＝０」、Ｔ_totalは「Ｔ_total＝Ｔ_app」となる。

決定部５０３は、作成された性能モデルＭを用いて、Ｅ［Ｃ］を最小化するＮ_spare（予備ノード数）を決定する。具体的には、例えば、決定部５０３は、性能モデルＭを用いて、Ｎ_spareを０からＮ_nodeまで順に変化させながら、Ｅ［Ｃ］を算出する。そして、決定部５０３は、算出したＥ［Ｃ］のうちの最小値に対応するＮ_spareを、Ｅ［Ｃ］を最小化するＮ_spareに決定してもよい。

また、決定部５０３は、０からＮ_nodeまでのうちの奇数または偶数のみに限定してＮ_spareを変化させながら、Ｅ［Ｃ］を算出してもよい。また、決定部５０３は、０からＮ_nodeまで所定数間隔でＮ_spareを変化させながら、Ｅ［Ｃ］を算出してもよい。所定数間隔は、任意に設定可能である。これにより、Ｎ_spareの決定にかかる計算量を抑えることができる。

ここで、図６を用いて、Ｅ［Ｃ］の算出例について説明する。ここでは、ｔ_cmpt＝１０、ｔ_comm＝５、Ｎ_node＝１００、ｐ_abn＝０．００５、α_abn＝１０、ｔ_bench＝０．１とする。また、倍精度浮動小数点数型を用いて数値計算を行うとする。

図６は、Ｅ［Ｃ］の算出例を示す説明図である。図６において、折れ線グラフ６０１は、Ｎ_spareを１から１０まで順に変化させて算出されたＥ［Ｃ］の変化を示す。ただし、図６中、右縦軸は、Ｅ［Ｃ］を示す。横軸は、Ｎ_spareを示す。また、Ａｓ－ｉｓは、本手法を使用しない場合のＥ［Ｃ］を示す。

また、棒グラフ６０２は、Ｎ_spareを１から１０まで順に変化させて算出されたＥ［Ｔ_total］の変化を示す。ただし、図６中、左縦軸は、Ｅ［Ｔ_total］を示す。横軸は、Ｎ_spareを示す。また、Ａｓ－ｉｓは、本手法を使用しない場合のＥ［Ｔ_total］を示す。

折れ線グラフ６０１では、「Ｎ_spare＝３」のときに最小値「Ｅ［Ｃ］＝１６７１」をとる。この最小値はＡｓ－ｉｓの０．３３倍であり、本手法を適用しない場合に比べてコストが削減されていることがわかる。折れ線グラフ６０１および棒グラフ６０２によれば、Ｎ_spareが３未満の場合、冗長ノード数が少なくなるものの、異常ノードを排除しきれずＥ［Ｔ_total］（ジョブ時間の期待値）が増えることがわかる。

また、Ｎ_spareが４以上の場合、Ｅ［Ｔ_total］は最適値をとり続けるものの、ノード数が増えて、Ｅ［Ｃ］（ノード時間の期待値）が徐々に増えていくことがわかる。この場合、決定部５０３は、「Ｎ_spare＝３」を、Ｅ［Ｃ］を最小化するＮ_spare（予備ノード数）に決定する。

図５の説明に戻り、投入部５０４は、決定されたＮ_spare（予備ノード数）を指定して、ジョブを投入する。具体的には、例えば、投入部５０４は、図２に示した管理用ノード２０２に対して、Ｎ_node（アプリの使用ノード数）およびＮ_spare（予備ノード数）を指定して、ジョブを投入する。

この結果、管理用ノード２０２において、例えば、キューにジョブが投入される。そして、管理用ノード２０２は、例えば、後述の図９に示すようなジョブスケジューラＰ２により、キューからジョブを取り出して、ノードＮ１～Ｎｎのうちの利用可能なノード群にジョブを割り当てる。ノード群は、Ｎ_node（アプリの使用ノード数）とＮ_spare（予備ノード数）とを合計した数分のノード群である。

なお、上述したログインノード２０１の機能部（例えば、受付部５０１～投入部５０４）は、管理用ノード２０２またはノードＮｉにより実現してもよい。また、ログインノード２０１が、管理用ノード２０２の機能（例えば、ジョブスケジューラＰ２）やノードＮｉの機能（例えば、ジョブスクリプトＰ３）を有することにしてもよい。例えば、ログインノード２０１が管理用ノード２０２の機能を有する場合、投入部５０４が、決定したＮ_spareとＮ_nodeとを合計した数（Ｎ_total）分のノード群にジョブを割り当てることにしてもよい。

（性能モデルＭの補足）
ここで、性能モデルＭの補足について説明する。

上述した説明では、指定されるパラメータにｔ_cmpt，ｔ_commが含まれていてもよいとしたが、ジョブの実行前にｔ_cmpt，ｔ_commの一方または両方が明らかになっていない場合がある。また、アプリの実行時間は明らかになっているもののｔ_cmptとｔ_commとの比率が分かっていない場合がある。

このため、パラメータとしてユーザがｔ_cmpt，ｔ_commを指定できない場合がある。この場合、作成部５０２は、例えば、ｔ_cmptを、アプリの実行時間、または、ジョブの最大使用時間（ｗａｌｌ－ｔｉｍｅ）の定数倍としてもよい。定数は、１未満の値である。また、作成部５０２は、例えば、ｔ_commを０としてもよい。

一般的な並列計算アプリでは、計算性能が大幅に低下した状況下では計算律速になり、「α_abn・ｔ_cmpt≫ｔ_comm」と予想されるためである。なお、アプリの実行時間は、例えば、ジョブの投入依頼に含まれていてもよく、また、システム側でアプリと対応付けて記憶されていてもよい。ジョブの最大使用時間（ｗａｌｌ－ｔｉｍｅ）は、例えば、ジョブの投入依頼に含まれる。

また、ｐ_abnおよびα_abnは、例えば、ユーザが、システム側によって公開される統計情報から算出してもよく、ジョブスケジューリングシステム２００に対して適当なベンチマークジョブを実行して得られた結果から推定してもよい。

また、一般的に、ノードの故障率は、いわゆる故障率曲線（バスタブ曲線）のような経過をたどる。このため、ノードの故障間隔・異常間隔は、確率的な挙動となる。しかし、本実施の形態では、「あるノードがジョブに割り当てられた瞬間に異常が発生している確率」に着目するため、これを単一の値「ｐ_abn」で表現しても一般性を損なわない。

例えば、下記式（１２）および（１３）のように、各ノードの故障間隔ｔ_flt（システムにより検出され復帰されるような事象が発生する間隔）と異常間隔ｔ_abn（性能低下の原因となるが、システムに検出されない事象が発生する間隔）が指数分布に従うと仮定する。ただし、λ_abn＜λ_fltとする。

ｔ_flt～Ｅｘｐ（λ_flt） ・・・（１２）
ｔ_abn～Ｅｘｐ（λ_abn） ・・・（１３）

この仮定の下で、あるノードを確保したときに異常が発生している確率ｐ_abn__expは、下記式（１４）によって表される。ただし、ｆ（ｘ｜λ），Ｆ（ｘ｜λ）は、それぞれ指数分布Ｅｘｐ（λ）の密度関数、分布関数を示す。

「λ_flt→∞」のとき、「（ノードの稼働時間）→∞」となり、異常が必ず発生しているため、「ｐ_{abn_exp}→１」となる。また、「λ_abn→∞」のとき、異常が発生しなくなるため、「ｐ_{abn_exp}→０」となる。同様に、故障間隔や異常間隔の分布がシステム全体の稼働時間に対して、不変かつノードごとに同等であれば、ｐ_abnは、単一の値として表現できる。

なお、故障間隔や異常間隔の分布がノードごとに同等でない、例えば、故障や異常が極端に多いようなノードが存在する場合が考えられる。このような場合、ジョブスケジューリングシステム２００のような同一構成のノードが多数存在するシステムでは、復帰の際に部品の交換等でその原因が取り除かれることが予想される。このため、一般にはこのような事象は発生しないと予想される。

（ノードＮｉの機能的構成例）
つぎに、ノードＮｉの機能的構成例について説明する。ノードＮｉは、ノードＮ１～Ｎｎのうちのいずれか１つのノード（計算ノード）である。

図７は、ノードＮｉの機能的構成例を示すブロック図である。図７において、ノードＮｉは、第１の実行部７０１と、選択部７０２と、第２の実行部７０３と、を含む。第１の実行部７０１～第２の実行部７０３は制御部７００となる機能であり、具体的には、例えば、図４に示したノードＮｉのメモリ４０２、ディスク４０４、可搬型記録媒体４０７などの記憶装置に記憶されたプログラム（後述の図９に示すようなジョブスクリプトＰ３）をＣＰＵ４０１に実行させることにより、または、通信Ｉ／Ｆ４０５により、その機能を実現する。各機能部の処理結果は、例えば、ノードＮｉのメモリ４０２、ディスク４０４などの記憶装置に記憶される。

第１の実行部７０１は、Ｎ_total分のノード群にジョブが割り当てられた結果、ノード群それぞれにベンチマークを実行させる。Ｎ_totalは、例えば、ログインノード２０１によって決定されたＮ_spareと、ユーザによって指定されたＮ_nodeとを合計した数である。

ベンチマークは、ジョブ内でアプリの前に実行されるノードの性能評価用のソフトウェア（例えば、ＬＩＮＰＡＣＫ）である。具体的には、例えば、第１の実行部７０１は、各種ＭＰＩライブラリに付属するｍｐｉｒｕｎコマンドを用いて、ノード群（自ノードを含む）それぞれにベンチマークの実行を依頼する。

以下の説明では、ジョブが割り当てられたノード群を「ノード群Ｎ［１］～Ｎ［ｍ］」と表記する場合がある（ｍは、２以上の自然数）。

また、第１の実行部７０１は、ノード群Ｎ［１］～Ｎ［ｍ］それぞれのベンチマーク実行時間を収集する。ベンチマーク実行時間は、ノードにおけるベンチマークの実行に要した時間である。具体的には、例えば、第１の実行部７０１は、ｍｐｉｒｕｎの標準出力から、ノード群Ｎ［１］～Ｎ［ｍ］それぞれのベンチマーク実行時間を収集する。ただし、ｍｐｉｒｕｎの標準出力にノードごとの時間が出力されるようにベンチマークの内容を調整する。

また、図２に示したファイルシステムＦＳ上の独自のパスにノードごとのベンチマークのログが出力されることにしてもよい。この場合、第１の実行部７０１は、例えば、ファイルシステムＦＳから、ノード群Ｎ［１］～Ｎ［ｍ］それぞれのベンチマーク実行時間を収集してもよい。

収集されたベンチマーク実行時間は、例えば、図８に示すようなベンチマーク実行時間テーブル８００に記憶される。ベンチマーク実行時間テーブル８００は、例えば、ノードＮｉのメモリ４０２、ディスク４０４などの記憶装置により実現される。

図８は、ベンチマーク実行時間テーブル８００の記憶内容の一例を示す説明図である。図８において、ベンチマーク実行時間テーブル８００は、ノードＩＤおよびベンチマーク実行時間のフィールドを有し、各フィールドに情報を設定することで、ベンチマーク実行時間情報８００－１～８００－ｍをレコードとして記憶する。

ここで、ノードＩＤは、ノード群Ｎ［１］～Ｎ［ｍ］に含まれるノードを一意に識別する識別子である。ベンチマーク実行時間は、ノードＩＤにより識別されるノードのベンチマーク実行時間である。例えば、ベンチマーク実行時間情報８００－１は、ノード群Ｎ［１］のベンチマーク時間ｔ１を示す。

選択部７０２は、収集されたベンチマーク実行時間とＮ_nodeとに基づいて、ジョブの実行にかかるアプリを実行するノードを選択する。具体的には、例えば、選択部７０２は、図８に示したベンチマーク実行時間テーブル８００を参照して、ノード群Ｎ［１］～Ｎ［ｍ］のうち、ベンチマーク実行時間が短いほうからＮ_node数分のノードを選択する。

第２の実行部７０３は、選択されたノードにアプリを実行させる。具体的には、例えば、第２の実行部７０３は、選択されたＮ_node数分のノードそれぞれのノードＩＤをホスト名として、ホスト名を列挙したｈｏｓｔｆｉｌｅを作成する。そして、第２の実行部７０３は、アプリ実行の際に、作成したｈｏｓｔｆｉｌｅ上のＮ_node行を引数により指定する。

これにより、第２の実行部７０３は、ノード群Ｎ［１］～Ｎ［ｍ］のうち、選択されたＮ_node数分のノードにジョブを実行させることができる。

なお、上述したノードＮｉの機能部（例えば、第１の実行部７０１～第２の実行部７０３）は、ログインノード２０１または管理用ノード２０２により実現してもよい。また、ノードＮｉが、ログインノード２０１の機能（例えば、投入スクリプトＰ１）や管理用ノード２０２の機能（例えば、ジョブスケジューラＰ２）を有することにしてもよい。

（ジョブスケジューリングシステム２００の動作例）
つぎに、ジョブスケジューリングシステム２００の動作例について説明する。

図９は、ジョブスケジューリングシステム２００の動作例を示す説明図である。図９において、ジョブスケジューリングシステム２００内のログインノード２０１、管理用ノード２０２、ノードＮ１～ＮｎおよびファイルシステムＦＳが示されている。ここでは、ノードＮ１～ＮｎのうちのノードＮ１がジョブスクリプトＰ３を実行する場合を想定する。

まず、ログインノード２０１は、投入スクリプトＰ１により、ユーザＵからパラメータ９００の指定を受け付ける。ユーザＵは、投入スクリプトＰ１を操作してジョブの実行を依頼するユーザであり、図２に示したクライアント端末２０３に対応する。パラメータ９００は、Ｎ_node、ｔ_cmpt、ｔ_comm、ｔ_bench、ｐ_abn、α_abnを含む。

そして、ログインノード２０１は、投入スクリプトＰ１により、パラメータ９００の指定に基づいて、性能モデルＭを作成する。つぎに、ログインノード２０１は、投入スクリプトＰ１により、性能モデルＭを用いて、Ｅ［Ｃ］を最小化するＮ_spareを決定する。そして、ログインノード２０１は、投入スクリプトＰ１により、管理用ノード２０２に対して、Ｎ_nodeおよびＮ_spareを指定して、ジョブを投入する。

管理用ノード２０２は、ジョブスケジューラＰ２により、投入されたジョブを、ノードＮ１～Ｎｎのうちの利用可能なノード群に割り当てて、ジョブスクリプトＰ３を実行する。ファイルシステムＦＳ内のジョブスクリプトＰ３の本体にアクセスするためのパスは、例えば、投入スクリプトＰ１から指定される。また、ジョブスクリプトＰ３が持つ全情報は、例えば、ジョブスケジューラＰ２経由で投入スクリプトＰ１から渡される。

なお、ジョブ・ノードのリストなどのスケジューリングを行うための情報は、例えば、ジョブスケジューラＰ２が保持している。また、ノードＮ１～Ｎｎから利用可能なノード群を特定する処理については、既存のいかなる技術を用いることにしてもよい。例えば、ジョブスケジューラＰ２は、ジョブが未割り当てのノードを特定してもよいし、ＣＰＵ使用率等に余裕があるノードを特定してもよい。

ノードＮ１は、ジョブスクリプトＰ３により、ジョブが割り当てられたノード群それぞれにベンチマークを実行させて、アプリ実行に使用するノードのノードリスト９０１を作成する。そして、ノードＮ１は、ジョブスクリプトＰ３により、ノードリスト９０１を用いて、Ｎ_node数分のノードを選択してアプリを実行する。アプリやベンチマークの実行に必要な情報（アプリやベンチマークの実行形式のパス、引数など）は、例えば、ジョブスケジューラＰ２経由で投入スクリプトＰ１からジョブスクリプトＰ３に渡される。

ここで、図１０を用いて、アプリを実行するノード間の接続例について説明する。

図１０は、ノード間の接続例を示す説明図である。図１０において、ノードＮ１，Ｎ２，Ｎ３，Ｎ４は、ジョブの実行のために確保されたノード群Ｎ［１］～Ｎ［ｍ］の一例である。ノードＮ１，Ｎ３，Ｎ４は、アプリを実行するノードとして選択されたＮ_node数分のノードの一例である。

ノードＮ１は、ジョブスクリプトＰ３により、ノードＮ１，Ｎ３，Ｎ４に対してアプリの実行を依頼する。各ノードＮ１，Ｎ３，Ｎ４へのアプリの実行依頼は、例えば、ＭＰＩライブラリにより実装されているコマンド（ｍｐｉｅｘｅｃまたはｍｐｉｒｕｎ）によって実現される。

また、アプリによって行われるノード間の通信は、例えば、スイッチ１００１を介して行われる（図１０では、スイッチ１００１によるツリー構造を想定）。これにより、ジョブスケジューリングシステム２００では、非連続の物理的配置にあるノード間においても高性能な通信が可能である。

（ジョブの実行例）
つぎに、図１１を用いて、ジョブの実行例について説明する。

図１１は、ジョブの実行例を示す説明図である。ログインノード２０１は、パラメータ（Ｎ_node、ｔ_cmpt、ｔ_comm、ｐ_abn、α_abn、ｔ_bench）の指定に基づいて、性能モデルＭを作成する。ログインノード２０１は、性能モデルＭを用いて、Ｅ［Ｃ］を最小化するＮ_spareを決定する。ここでは、Ｎ_nodeを「Ｎ_node＝３」とし、Ｎ_spareが「Ｎ_spare＝１」に決定された場合を想定する。この場合、管理用ノード２０２は、Ｎ_spareとＮ_nodeとを合計した４つのノードにジョブを割り当てる。

図１１において、ノード１１０１～１１０４は、ノードＮ１～Ｎｎに含まれるノードであり、ジョブの実行のために確保されたノード群Ｎ［１］～Ｎ［ｍ］の一例である。ここでは、ノード１１０１を、ジョブスクリプトＰ３（例えば、図９参照）を実行するノードＮｉとする。

図１１中、「ベンチ」は、各ノード１１０１～１１０４のベンチマークの実行時間を示す。また、「収集」は、各ノード１１０１～１１０４のベンチマーク実行時間の収集にかかる時間である。ただし、ベンチマーク実行時間の収集にかかる時間は、無視できるほど小さいと仮定する。また、「計算」は、アプリにおける計算時間を示す。ｔ_cmptは、アプリ全体の計算時間の合計に相当する。「通信」は、アプリにおけるノード間の通信時間を示す。ｔ_commは、アプリ全体の通信時間の合計に相当する。

ノード１１０１は、ノード１１０１～１１０４それぞれにベンチマークを実行させる。そして、ノード１１０１は、ノード１１０１～１１０４それぞれのベンチマーク実行時間を収集する。ここでは、ノード１１０３で異常が発生しており、ノード１１０３のベンチマーク実行時間がノード１１０１，１１０２，１１０４に比べて長くなっている。

ノード１１０１は、「Ｎ_node＝３」に基づいて、アプリを実行するノードとして、ベンチマーク時間が短いほうから３つ分のノード１１０１，１１０２，１１０４を選択する。ここでは、異常ノード数「１」がＮ_spare以下のため、ノード１１０３を異常ノードとして排除することができる。

そして、ノード１１０１は、選択したノード１１０１，１１０２，１１０４にアプリを実行させる。これにより、ノード１１０１は、ジョブの実行にかかるアプリが異常ノードで実行されて計算性能が低下するのを防ぐことができる。ノード時間は、（ノード数：４）×（使用時間：Ｔｘ）となる（図１１中の点線枠１１１０の面積に相当）。

（ログインノード２０１のジョブ投入処理手順）
つぎに、ログインノード２０１のジョブ投入処理手順について説明する。ジョブ投入処理は、例えば、ジョブスケジューリング処理の一部に相当する。

図１２および図１３は、ログインノード２０１のジョブ投入処理手順の一例を示すフローチャートである。図１２のフローチャートにおいて、まず、ログインノード２０１は、クライアント端末２０３から、ジョブの投入依頼を受け付けたか否かを判断する（ステップＳ１２０１）。

ジョブの投入依頼には、例えば、パラメータ（Ｎ_node、ｔ_cmpt、ｔ_comm、ｐ_abn、α_abn、ｔ_bench）の指定、ジョブの計算内容、最大使用時間（ｗａｌｌ－ｔｉｍｅ）などの情報が含まれる。ここで、ログインノード２０１は、ジョブの投入依頼を受け付けるのを待つ（ステップＳ１２０１：Ｎｏ）。

ログインノード２０１は、ジョブの投入依頼を受け付けた場合（ステップＳ１２０１：Ｙｅｓ）、Ｎ_spareを「Ｎ_spare＝０」とし（ステップＳ１２０２）、Ｅ［Ｃ］を算出するＥＣ算出処理を実行する（ステップＳ１２０３）。ＥＣ算出処理の具体的な処理手順については、図１４を用いて後述する。

そして、ログインノード２０１は、Ｅ_{C_best}を、ステップＳ１２０３において算出されたＥ［Ｃ］とし（ステップＳ１２０４）、Ｎ_{spare_best}を「Ｎ_{spare_best}＝０」とする（ステップＳ１２０５）。つぎに、ログインノード２０１は、ｉを「ｉ＝１」とする（ステップＳ１２０６）。

そして、ログインノード２０１は、Ｎ_spareを「Ｎ_spare＝ｉ」として（ステップＳ１２０７）、ジョブの投入依頼に含まれるパラメータの指定に基づいて、ＥＣ算出処理を実行する（ステップＳ１２０８）。ＥＣ算出処理の具体的な処理手順については、図１４を用いて後述する。

つぎに、ログインノード２０１は、ステップＳ１２０８において算出されたＥ［Ｃ］が、Ｅ_{C_best}より小さいか否かを判断する（ステップＳ１２０９）。ここで、Ｅ［Ｃ］がＥ_{C_best}より小さい場合（ステップＳ１２０９：Ｙｅｓ）、ログインノード２０１は、Ｅ_{C_best}を、ステップＳ１２０８において算出されたＥ［Ｃ］とする（ステップＳ１２１０）。

そして、ログインノード２０１は、Ｎ_{spare_best}を「Ｎ_{spare_best}＝ｉ」として（ステップＳ１２１１）、図１３に示すステップＳ１３０１に移行する。また、ステップＳ１２０９において、Ｅ［Ｃ］がＥ_{C_best}以上の場合には（ステップＳ１２０９：Ｎｏ）、ログインノード２０１は、図１３に示すステップＳ１３０１に移行する。

図１３のフローチャートにおいて、まず、ログインノード２０１は、ｉをインクリメントして（ステップＳ１３０１）、ｉがＮ_nodeより大きいか否かを判断する（ステップＳ１３０２）。ここで、ｉがＮ_node以下の場合（ステップＳ１３０２：Ｎｏ）、ログインノード２０１は、ステップＳ１２０７に移行する。

一方、ｉがＮ_nodeより大きい場合は（ステップＳ１３０２：Ｙｅｓ）、ログインノード２０１は、Ｎ_spareを「Ｎ_spare＝Ｎ_{spare_best}」とする（ステップＳ１３０３）。そして、ログインノード２０１は、Ｎ_spareを指定して、ジョブを投入し（ステップＳ１３０４）、本フローチャートによる一連の処理を終了する。

これにより、ログインノード２０１は、ノード時間（コスト）の期待値を最小化する予備ノード数を指定して、ジョブを投入することができる。

つぎに、図１２に示したステップＳ１２０３，Ｓ１２０８のＥＣ算出処理の具体的な処理手順について説明する。

図１４は、ＥＣ算出処理の具体的処理手順の一例を示すフローチャートである。図１４のフローチャートにおいて、まず、ログインノード２０１は、Ｎ_nodeとＮ_spareとに基づいて、上記式（１）を作成する（ステップＳ１４０１）。そして、ログインノード２０１は、Ｎ_totalとＮ_abnとに基づいて、上記式（１）および（２）から上記式（３）を作成する（ステップＳ１４０２）。

つぎに、ログインノード２０１は、ｓを「ｓ＝０」とし（ステップＳ１４０３）、ｉを「ｉ＝０」とする（ステップＳ１４０４）。そして、ログインノード２０１は、Ｎ_totalとｐ_abnとに基づいて、下記式（１５）からｓを算出する（ステップＳ１４０５）。下記式（１５）は、上記式（６）に対応する。

つぎに、ログインノード２０１は、ｉをインクリメントして（ステップＳ１４０６）、ｉがＮ_spareより大きいか否かを判断する（ステップＳ１４０７）。ここで、ｉがＮ_spare以下の場合（ステップＳ１４０７：Ｎｏ）、ログインノード２０１は、ステップＳ１４０５に戻る。

一方、ｉがＮ_spareより大きい場合（ステップＳ１４０７：Ｙｅｓ）、ログインノード２０１は、［Ｎ_abn≦Ｎ_spare］を「Ｐ［Ｎ_abn≦Ｎ_spare］＝ｓ」とする（ステップＳ１４０８）。つぎに、ログインノード２０１は、上記式（１０）を用いて、Ｅ［Ｔ_total］を算出する（ステップＳ１４０９）。

具体的には、例えば、ログインノード２０１は、Ｐ［Ｎ_abn＞０］とα_abnとｔ_benchとに基づいて、上記式（４）および（５）を作成する。また、ログインノード２０１は、ｔ_cmptとｔ_commとα_abnとＰ［Ｎ_abn≦Ｎ_spare］とに基づいて、上記式（７）および（８）を作成する。そして、ログインノード２０１は、上記式（４）、（５）、（７）、（８）および（９）から上記式（１０）を作成し、Ｅ［Ｔ_total］を算出する。

そして、ログインノード２０１は、算出したＥ［Ｔ_total］を用いて、上記式（１１）からＥ［Ｃ］を算出して（ステップＳ１４１０）、ＥＣ算出処理を呼び出したステップに戻る。

これにより、ログインノード２０１は、ノード時間（コスト）の期待値を算出することができる。

（ノードＮｉのジョブ実行制御処理手順）
つぎに、ノードＮｉのジョブ実行制御処理手順について説明する。ノードＮｉは、ノード群Ｎ［１］～Ｎ［ｍ］のうちのジョブスクリプトＰ３を有するノードである。ジョブ実行制御処理は、例えば、ジョブスケジューリング処理の一部に相当する。

図１５は、ノードＮｉのジョブ実行制御処理手順の一例を示すフローチャートである。図１５のフローチャートにおいて、まず、ノードＮｉは、ジョブが割り当てられたノード群Ｎ［１］～Ｎ［ｍ］の各ノードにベンチマークを実行させる（ステップＳ１５０１）。

つぎに、ノードＮｉは、各ノードのベンチマーク実行時間を収集する（ステップＳ１５０２）。そして、ノードＮｉは、収集した各ノードのベンチマーク実行時間が昇順となるように、ノード群Ｎ［１］～Ｎ［ｍ］それぞれのノードＩＤをソートする（ステップＳ１５０３）。

つぎに、ノードＮｉは、ソート後のノードＩＤを参照して、ベンチマーク実行時間が短いほうからＮ_node数分のノードを選択する（ステップＳ１５０４）。そして、ノードＮｉは、選択したＮ_node数分のノードでアプリを実行して（ステップＳ１５０５）、本フローチャートによる一連の処理を終了する。

これにより、ノードＮｉは、ユーザに異常ノードが割り当てられてアプリの計算性能が低下するのを抑えて、ノード時間の増大を抑制することができる。

（Ｅ［Ｃ］の削減例）
つぎに、本手法を適用した場合のＥ［Ｃ］の削減例について説明する。まず、図１６Ａおよび図１６Ｂを用いて、パラメータとして指定されるｐ_abn、α_abn、ｔ_benchの算出例について説明する。

図１６Ａおよび図１６Ｂは、各ノードのベンチマーク時間の具体例を示す説明図である。図１６Ａにおいて、棒グラフ１６０１（９６本の棒グラフ）は、ノードＮ１～Ｎｎのうちの９６ノードでジョブＡを実行した場合の各ノードのベンチマーク時間を降順にソートして表す。棒グラフ１６０１によれば、先頭の２ノードが異常ノードといえる。

図１６Ｂにおいて、棒グラフ１６０２（９６本の棒グラフ）は、ノードＮ１～Ｎｎのうちの９６ノードでジョブＢを実行した場合の各ノードのベンチマーク時間を降順にソートして表す。棒グラフ１６０２によれば、先頭の３ノードが異常ノードといえる。

ｔ_benchは、例えば、非異常ノードのベンチマーク時間の平均値から算出することができる。ここでは、ｔ_benchは、「ｔ_bench＝０．０１６７［ｓ］」となる。また、α_abnは、例えば、異常ノード、非異常ノードそれぞれのベンチマーク時間の平均値の比から算出することができる。ここでは、α_abnは、「α_abn＝３．５３」となる。また、ｐ_abnは、例えば、最尤推定により算出することができる。ここでは、ｐ_abnは、「ｐ_abn＝｛（２＋３）／２｝／９６＝０．０２６」となる。

つぎに、Ｅ［Ｃ］の予測例について説明する。ここでは、Ｎ_node＝１００として、計算負荷の異なる３つのケース「（ｔ_cmpt，ｔ_comm）＝（１００秒，０秒），（５０秒，５０秒），（１０秒，９０秒）」について、上記式（１１）からノード時間の期待値（Ｅ［Ｃ］）を予測した場合を例に挙げて説明する。

図１７は、Ｅ［Ｃ］の予測例を示す説明図である。図１７において、折れ線グラフ１７０１は、「（ｔ_cmpt，ｔ_comm）＝（１００秒，０秒）」として、Ｎ_spareを１から１５まで順に変化させた場合のＥ［Ｃ］の変化を示す。ただし、図１７中、縦軸は、Ｅ［Ｃ］を示す。横軸は、Ｎ_spareを示す。また、Ａｓ－ｉｓは、本手法を使用しない場合のＥ［Ｃ］を示す。

折れ線グラフ１７０２は、「（ｔ_cmpt，ｔ_comm）＝（５０秒，５０秒）」として、Ｎ_spareを１から１５まで順に変化させた場合のＥ［Ｃ］の変化を示す。折れ線グラフ１７０３は、「（ｔ_cmpt，ｔ_comm）＝（１０秒，９０秒）」として、Ｎ_spareを１から１５まで順に変化させた場合のＥ［Ｃ］の変化を示す。

折れ線グラフ１７０１では、Ｎ_spareが「Ｎ_spare＝８」のときにＥ［Ｃ］が最小となり、Ａｓ－ｉｓのＥ［Ｃ］よりも（１／３．１）倍程度にＥ［Ｃ］を削減できると推定される。なお、最適値「Ｎ_spare＝８」は、１０８ノードを確保して８ノードを除外すれば、ほぼ異常ノードを排除でき、ノード時間の期待値が最小値をとることを意味する。

折れ線グラフ１７０２では、Ｎ_spareが「Ｎ_spare＝７」のときにＥ［Ｃ］が最小となり、Ａｓ－ｉｓのＥ［Ｃ］よりも（１／２）倍程度にＥ［Ｃ］を削減できると推定される。折れ線グラフ１７０３では、Ｎ_spareが「Ｎ_spare＝５」のときにＥ［Ｃ］が最小となり、Ａｓ－ｉｓのＥ［Ｃ］よりも（１／１．２）倍程度にＥ［Ｃ］を削減できると推定される。

なお、上述した説明では、ユーザが投入するジョブの中でベンチマークを実行する場合を例に挙げて説明したが、これに限らない。例えば、ベンチマークの実行から異常ノードの除外までの操作を、ジョブスケジューリングシステム２００の管理者側で行うことにしてもよい。

この場合、例えば、１つのジョブに対して多数のノードが割り当てられる際に、管理者側（例えば、管理用ノード２０２）でユーザのアプリが実行される前に、ベンチマークの実行から異常ノードの除外までの操作を行う。そして、管理者側から異常ノードが排除されたノードのリストをユーザのアプリに引き渡すことで、アプリの性能低下の抑止やノードの利用効率の向上が期待される。

また、管理者側（例えば、管理用ノード２０２）で上記操作を行う場合、例えば、管理用ノード２０２は、各ノードのベンチマーク実行時間の収集時に、ある指標を用いて異常ノードの検出を行うことにしてもよい。管理用ノード２０２は、例えば、異常ノードが多数検出された場合、ジョブスケジューリングシステム２００から異常ノードを除外してもよい。異常ノードの除外が困難な場合、管理者側からユーザに対して通知するなどして、ユーザが不利益を被らないような仕組みを設けてもよい。また、管理用ノード２０２は、例えば、各ノードのベンチマーク実行時間から、性能モデルＭのパラメータのうちのアプリに対して不変なもの（ｐ_abn、α_abn、ｔ_benchなど）を算出してもよい。

また、物理的なノード配置が通信性能に比較的強く影響するメッシュやトーラス型のトポロジーを採用したスパコンについては、ユーザ側で異常ノードを除外すると配置が不連続になり、特定のノード間の通信レイテンシが増加する可能性がある。しかし、上述したようなシステムレベルでの異常ノードの除外を、高次元メッシュ・トポロジーを持つスパコンに対して適用する場合、例えば、通常の障害ノードの除外と同様の手法で、ネットワーク上で連続したノード群をユーザ側に提供することができる。

以上説明したように、実施の形態にかかるジョブスケジューリングシステム２００のログインノード２０１によれば、ジョブを実行するにあたり、パラメータの指定を受け付けることができる。パラメータは、例えば、Ｎ_node、ｐ_abn、α_abn、ｔ_benchを含む。また、ログインノード２０１によれば、受け付けたパラメータの指定に基づいて、Ｅ［Ｔ_total］およびＮ_totalからＥ［Ｃ］を出力する性能モデルＭを作成することができる。そして、ログインノード２０１によれば、作成した性能モデルＭを用いて、Ｅ［Ｃ］を最小化するＮ_spare（予備ノード数）を決定することができる。

これにより、ログインノード２０１は、異常ノードの発生を考慮して冗長なノード数でジョブを投入するにあたり、ノード時間（コスト）の期待値を最小化する予備ノード数を探索して、ジョブを効率的に実行するためのノード数を決定することができる。例えば、ログインノード２０１は、ノード時間（コスト）の期待値を最小化する予備ノード数を指定して、ジョブを投入することができる。

また、ログインノード２０１によれば、第１の処理時間、第２の処理時間を含むパラメータの指定を受け付けることができる。第１の処理時間は、アプリの実行時間のうち、異常ノードによる性能低下の影響を受ける処理時間である。第２の処理時間は、アプリの実行時間のうち、異常ノードによる性能低下の影響を受けない処理時間である。

これにより、ログインノード２０１は、アプリの実行時間として、異常ノードによる性能低下の影響を受ける処理時間と、異常ノードによる性能低下の影響を受けない処理時間とを考慮して、性能モデルＭを作成することができる。このため、ログインノード２０１は、アプリの特性を考慮して、Ｅ［Ｃ］を精度よく予測することができる。

また、ログインノード２０１によれば、ｔ_cmpt、ｔ_commを含むパラメータの指定を受け付けることができる。ｔ_cmptは、第１の処理時間の一例である。ｔ_commは、第２の処理時間の一例である。

これにより、ログインノード２０１は、ジョブ内で実行されるアプリの計算を全ノードが協調して行う場合に、アプリによって決まるパラメータとして、アプリにおける各ノードの計算時間とアプリにおけるノード間の通信時間とを任意に指定することができる。このため、ログインノード２０１は、アプリの特性を考慮した性能モデルＭを作成することができ、Ｅ［Ｃ］の予測精度を向上させることができる。

また、ログインノード２０１によれば、Ｎ_nodeとＮ_spareとｐ_abnとに基づいて、ジョブ内に異常ノードが存在する存在確率（Ｐ［Ｎ_abn＞０］）を表す第１モデル式を作成し、第１モデル式とα_abnとｔ_benchに基づいて、ジョブにおけるベンチマーク時間（Ｐ［Ｔ_bench＝α_abn・ｔ_bench］、Ｐ［Ｔ_bench＝ｔ_bench］）を表す第２モデル式を作成することができる。

これにより、ログインノード２０１は、ジョブ内に異常ノードが存在する存在確率を考慮して、ジョブにおけるベンチマーク時間を予測することができる。

また、ログインノード２０１によれば、Ｎ_nodeとＮ_spareとｐ_abnとに基づいて、アプリの実行から異常ノードを排除できる排除確率（Ｐ［Ｎ_abn≦Ｎ_spare］）を表す第３モデル式を作成することができる。そして、ログインノード２０１によれば、ｔ_cmptとｔ_commとα_abnと第３モデル式とに基づいて、ジョブにおけるアプリ時間（Ｐ［Ｔ_app＝α_abn・ｔ_cmpt＋ｔ_comm］、Ｐ［Ｔ_app＝ｔ_cmpt＋ｔ_comm］）を表す第４モデル式を作成することができる。

これによりログインノード２０１は、アプリの実行から異常ノードを排除できる排除確率を考慮して、ジョブにおけるアプリ時間を予測することができる。

また、ログインノード２０１によれば、第２モデル式と第４モデル式とに基づいて、ジョブ時間の期待値（Ｅ［Ｔ_total］）を表す第５モデル式を作成し、第５モデル式、Ｎ_nodeおよびＮ_spareに基づいて、性能モデルＭを作成することができる。

これにより、ログインノード２０１は、ジョブ時間の期待値を精度よく予測可能となり、ノード時間の予測精度を向上させることができる。

また、実施の形態にかかるジョブスケジューリングシステム２００のノードＮｉによれば、Ｎ_total分のノード群Ｎ［１］～Ｎ［ｍ］にジョブが割り当てられた結果、ノード群それぞれにベンチマークを実行させることができる。Ｎ_totalは、例えば、ログインノード２０１によって決定されたＮ_spareと、ユーザによって指定されたＮ_nodeとを合計した数である。そして、ノードＮｉによれば、ノード群Ｎ［１］～Ｎ［ｍ］のうち、ベンチマーク実行時間が短いほうからＮ_node分のノードにアプリを実行させることができる。

これにより、ノードＮｉは、ノード群Ｎ［１］～Ｎ［ｍ］の中から、ベンチマークの実行にかかる時間が遅いノードを排除してアプリを実行させることができる。このため、ノードＮｉは、ユーザに異常ノードが割り当てられてアプリの計算性能が低下するのを抑えて、ノード時間の増大を抑制することができる。

これらのことから、実施の形態にかかるジョブスケジューリングシステム２００によれば、ジョブやハードウェア環境に手を加えることなく、異常ノードを除外してもノード時間の増大を抑制可能な最小のノード数を決定することができ、ジョブを効率的に実行することが可能となる。

なお、本実施の形態で説明したスケジューリング方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本スケジューラは、ハードディスク、フレキシブルディスク、ＣＤ－ＲＯＭ、ＤＶＤ、ＵＳＢメモリ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また、本スケジューラは、インターネット等のネットワークを介して配布してもよい。

上述した実施の形態に関し、さらに以下の付記を開示する。

（付記１）システム内の１以上のノードによりジョブを実行するにあたり、前記ジョブの実行にかかるアプリケーションの使用ノード数と、前記システム内のノードの異常発生確率と、前記システム内の異常ノードの正常ノードに対する処理時間の比率と、前記ジョブ内で前記アプリケーションの前に実行されるベンチマークの実行にかかるベンチマーク時間との指定を受け付け、
受け付けた前記指定に基づいて、前記ジョブの実行にかかる実行時間の期待値、前記使用ノード数および前記ジョブにおける予備ノード数から、前記ジョブの実行にかかるリソース消費量の期待値を出力する性能モデルを作成し、
作成した前記性能モデルを用いて、前記リソース消費量の期待値を最小化する前記予備ノード数を決定する、
処理をコンピュータに実行させることを特徴とするジョブスケジューラ。

（付記２）前記指定は、前記アプリケーションの実行時間のうち前記異常ノードによる性能低下の影響を受ける第１の処理時間と、前記異常ノードによる性能低下の影響を受けない第２の処理時間との指定を含む、ことを特徴とする付記１に記載のジョブスケジューラ。

（付記３）前記第１の処理時間は、前記アプリケーションにおける各ノードの計算にかかる計算時間であり、
前記第２の処理時間は、前記アプリケーションにおけるノード間の通信にかかる通信時間である、
ことを特徴とする付記２に記載のジョブスケジューラ。

（付記４）決定した前記予備ノード数と前記使用ノード数とを合計した数分のノード群に前記ジョブを割り当てられた結果、前記ノード群それぞれに前記ベンチマークを実行させ、
前記ノード群のうち、前記ベンチマークの実行に要した処理時間が短いほうから前記使用ノード数分のノードに前記アプリケーションを実行させる、
処理を前記コンピュータに実行させることを特徴とする付記１～３のいずれか一つに記載のジョブスケジューラ。

（付記５）前記作成する処理は、
前記使用ノード数と前記予備ノード数と前記異常発生確率とに基づいて、前記ジョブ内に異常ノードが存在する存在確率を表す第１モデル式を作成し、
前記第１モデル式と前記比率と前記ベンチマーク時間に基づいて、前記ジョブにおけるベンチマーク時間を表す第２モデル式を作成し、
前記使用ノード数と前記予備ノード数と前記異常発生確率とに基づいて、前記アプリケーションの実行から前記異常ノードを排除できる排除確率を表す第３モデル式を作成し、
前記第１の処理時間と前記第２の処理時間と前記比率と前記第３モデル式とに基づいて、前記ジョブにおけるアプリケーション時間を表す第４モデル式を作成し、
前記第２モデル式と前記第４モデル式とに基づいて、前記ジョブの実行にかかる実行時間の期待値を表す第５モデル式を作成し、
作成した前記第５モデル式、前記使用ノード数および前記予備ノード数に基づいて、前記性能モデルを作成する、
ことを特徴とする付記２～４のいずれか一つに記載のジョブスケジューラ。

（付記６）システム内の１以上のノードによりジョブを実行するにあたり、前記ジョブの実行にかかるアプリケーションの使用ノード数と、前記システム内のノードの異常発生確率と、前記システム内の異常ノードの正常ノードに対する処理時間の比率と、前記ジョブ内で前記アプリケーションの前に実行されるベンチマークの実行にかかるベンチマーク時間との指定を受け付け、
受け付けた前記指定に基づいて、前記ジョブの実行にかかる実行時間の期待値、前記使用ノード数および前記ジョブにおける予備ノード数から、前記ジョブの実行にかかるリソース消費量の期待値を出力する性能モデルを作成し、
作成した前記性能モデルを用いて、前記リソース消費量の期待値を最小化する前記予備ノード数を決定する、
処理をコンピュータが実行することを特徴とするジョブスケジューリング方法。

（付記７）システム内の１以上のノードによりジョブを実行するにあたり、前記ジョブの実行にかかるアプリケーションの使用ノード数と、前記システム内のノードの異常発生確率と、前記システム内の異常ノードの正常ノードに対する処理時間の比率と、前記ジョブ内で前記アプリケーションの前に実行されるベンチマークの実行にかかるベンチマーク時間との指定を受け付ける受付部と、
前記受付部によって受け付けた前記指定に基づいて、前記ジョブの実行にかかる実行時間の期待値、前記使用ノード数および前記ジョブにおける予備ノード数から、前記ジョブの実行にかかるリソース消費量の期待値を出力する性能モデルを作成する作成部と、
前記作成部によって作成された前記性能モデルを用いて、前記リソース消費量の期待値を最小化する前記予備ノード数を決定する決定部と、
前記決定部によって決定された前記予備ノード数と前記使用ノード数とを合計した数分のノード群に前記ジョブを割り当てられた結果、前記ノード群それぞれに前記ベンチマークを実行させる第１の実行部と、
前記ノード群のうち、前記ベンチマークの実行に要した処理時間が短いほうから前記使用ノード数分のノードに前記アプリケーションを実行させる第２の実行部と、
を含むことを特徴とするジョブスケジューリングシステム。

１０１ 情報処理装置
１１０，９００ パラメータ
１２０，Ｍ 性能モデル
２００ ジョブスケジューリングシステム
２０１ ログインノード
２０２ 管理用ノード
２０３ クライアント端末
２０４ ストレージサーバ
２１０ ネットワーク
３０１，３０２，３０３，３０４，３０５，３０６，３０７，３０８，１１０１，１１０２，１１０３，１１０４，Ｎ１～Ｎｎ，Ｎｉ ノード
３１１，３１２，３１３，１００１ スイッチ
４００ バス
４０１ ＣＰＵ
４０２ メモリ
４０３ ディスクドライブ
４０４ ディスク
４０５ 通信Ｉ／Ｆ
４０６ 可搬型記録媒体Ｉ／Ｆ
４０７ 可搬型記録媒体
５００，７００ 制御部
５０１ 受付部
５０２ 作成部
５０３ 決定部
５０４ 投入部
７０１ 第１の実行部
７０２ 選択部
７０３ 第２の実行部
８００ ベンチマーク実行時間テーブル
９０１ ノードリスト

Claims (5)

1. システム内の１以上のノードによりジョブを実行するにあたり、前記ジョブの実行にかかるアプリケーションの使用ノード数と、前記システム内のノードの異常発生確率と、前記システム内の異常ノードの正常ノードに対する処理時間の比率と、前記ジョブ内で前記アプリケーションの前に実行されるベンチマークの実行にかかるベンチマーク時間との指定を受け付け、
   受け付けた前記指定に基づいて、前記ジョブの実行にかかる実行時間の期待値、前記使用ノード数および前記ジョブにおける予備ノード数から、前記ジョブの実行にかかるリソース消費量の期待値を出力する性能モデルを作成し、
   作成した前記性能モデルを用いて、前記リソース消費量の期待値を最小化する前記予備ノード数を決定する、
   処理をコンピュータに実行させることを特徴とするジョブスケジューラ。
2. 前記指定は、前記アプリケーションの実行時間のうち前記異常ノードによる性能低下の影響を受ける第１の処理時間と、前記異常ノードによる性能低下の影響を受けない第２の処理時間との指定を含む、ことを特徴とする請求項１に記載のジョブスケジューラ。
3. 前記第１の処理時間は、前記アプリケーションにおける各ノードの計算にかかる計算時間であり、
   前記第２の処理時間は、前記アプリケーションにおけるノード間の通信にかかる通信時間である、
   ことを特徴とする請求項２に記載のジョブスケジューラ。
4. 決定した前記予備ノード数と前記使用ノード数とを合計した数分のノード群に前記ジョブを割り当てられた結果、前記ノード群それぞれに前記ベンチマークを実行させ、
   前記ノード群のうち、前記ベンチマークの実行に要した処理時間が短いほうから前記使用ノード数分のノードに前記アプリケーションを実行させる、
   処理を前記コンピュータに実行させることを特徴とする請求項１に記載のジョブスケジューラ。
5. システム内の１以上のノードによりジョブを実行するにあたり、前記ジョブの実行にかかるアプリケーションの使用ノード数と、前記システム内のノードの異常発生確率と、前記システム内の異常ノードの正常ノードに対する処理時間の比率と、前記ジョブ内で前記アプリケーションの前に実行されるベンチマークの実行にかかるベンチマーク時間との指定を受け付け、
   受け付けた前記指定に基づいて、前記ジョブの実行にかかる実行時間の期待値、前記使用ノード数および前記ジョブにおける予備ノード数から、前記ジョブの実行にかかるリソース消費量の期待値を出力する性能モデルを作成し、
   作成した前記性能モデルを用いて、前記リソース消費量の期待値を最小化する前記予備ノード数を決定する、
   処理をコンピュータが実行することを特徴とするジョブスケジューリング方法。

Images