(57)【要約】【課題】動的にプロセッサを割当直すことによりマルチプロセッサシステムを容易にかつ効率的に運用できるようにすること。【解決手段】管理プロセス２は、ジョブクラスタＩＤ生成器１１にジョブクラスタＩＤ要求を出し、新しいジョブクラスタＩＤを得る。次に、管理プロセス２は、ジョブスケジューラ１に対して、ジョブクラスタＩＤを伝えて、利用したいプロセッサ数を要求する。プロセッサ要求は、許可されるか、許可されないかであり、許可されれば割り当てプロセッサが、管理プロセス２に通知される。管理プロセス２はジョブスケジューラ１から割り当てプロセッサのリストを受け取り、実行管理装置６はプロセッサにジョブを割り当て、実行をさせる。上記実行管理を行う手段として、管理プロセス２が並列タスク実行プログラムを兼ねたり、タスク振り分け機能を持つプログラムまたはハードウェアを設けてもよい。【選択図】          図１
2004192400.tif 000002
【特許請求の範囲】
【請求項１】
マルチプロセッサシステムにおけるジョブスケジューリング方法であって、
管理プロセスからの要求に対して、ＩＤを生成し、
管理プロセスから上記ＩＤを指定して利用したいプロセッサ数の要求があったとき、
予め定めた管理ポリシーと、予め指定された利用可能プロセッサに基づき、上記ＩＤを単位としてプロセサを割り当てる
ことを特徴とするジョブスケジューリング方法。
【請求項２】
マルチプロセッサシステムにおけるジョブスケジューリング装置であって、
管理プロセスからの要求に対して、ＩＤを生成するＩＤ生成手段と、
管理プロセスから上記ＩＤを指定して利用したいプロセッサ数の要求があったとき、予め定めた管理ポリシーと、予め指定された利用可能プロセッサに基づき、上記ＩＤを単位としてプロセサを割り当てるプロセッサ割当手段とを備えた
ことを特徴とするジョブスケジューリング装置。
【請求項３】
マルチプロセッサシステムにおけるジョブスケジューリング装置であって、
管理プロセスからの要求に対して、ＩＤを生成するＩＤ生成手段と、
管理プロセスから上記ＩＤを指定して利用したいプロセッサ数の要求があったとき、予め定めた管理ポリシーと、予め指定された利用可能プロセッサに基づき、上記ＩＤを単位としてプロセサを割り当てるプロセッサ割当手段と、
管理プロセスから投入されたジョブの実行を管理する実行管理手段を備えた
ことを特徴するジョブスケジューリング装置。
【請求項４】
上記プロセッサ割当手段は、複数回の割り当てを受け付けるかを許可または不許可とする手段を備えた
ことを特徴とする請求項２または請求項３のジョブスケジューリング装置。
【請求項５】
マルチプロセッサシステムにおけるジョブスケジューリングプログラムであって、
上記プログラムは、管理プロセスからの要求に対して、ジョブクラスタＩＤを生成して、ジョブクラスタＩＤを割り当てる処理と、
管理プロセスからジョブクラスタＩＤを指定して利用したいプロセッサ数の要求があったとき、予め定めた管理ポリシーと、予め指定された利用可能プロセッサに基づき、ジョブクラスタを単位としてプロセサを割り当てる処理をコンピュータに実行させる
ことを特徴とするジョブスケジューリングプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、マルチプロセッサ装置において、ユーザが実行することを指示したジョブをスケージューリングする方法および装置に関し、特に、ユーザが指示した複数のジョブに強い関連性があり、それらをまとめてスケジューリングすることで、管理者がジョブの管理を容易に行えるようにしたジョブスケジューリング方法および装置に関するものである。
【０００２】
【従来の技術】
従来から、例えば図６に示すようなジョブのスケジューリング方式が知られている（例えば非特許文献１，非特許文献２，非特許文献３参照）。
図６に記載のものは、ジョブとプロセッサの実行状況を管理するバッチジョブ管理システム１０１を設けてジョブスケジューリングを行うものであり、管理者１０２があらかじめ複数のキューを用意し、各キューが使用すべきプロセッサ数、一つのジョブに許可された実行時間等を設定し、バッチ処理システム１０１に指示を行う。
ユーザ１０３は、適当なキューを選んでジョブを投入する。
バッチ処理システム１０１は、キューに投入されたジョブと、マルチプロセッサ装置１０４のプロセッサの実行状況を管理している。すでに、プロセッサの割当が済んだ実行中のジョブに関しては、実行時間など管理者が設定した制限を監視しており、もしも制限を超過した場合は、ジョブの実行を強制終了する。
また、ジョブが制限以内に実行終了したかどうかを監視する。もしも、ジョブを実行していないプロセッサが見つかれば、それに未実行のジョブを割り当て、実行をさせる。もしも未実行のジョブが何も無ければ、次のジョブが来るまでプロセッサはアイドル状態とされる。
キューの設定が適切であれば、アイドル状態のプロセッサを少ないようにすることが出来る。
例えば、短時間で終るジョブのために数個のプロセスを割り当て、長時間かかるジョブのために残りの全てのプロセスを割り当てる等の設定を行うことが出来る。
非特許文献１には上記のようなジョブスケジューリング方式の機能の特徴が、非特許文献２にはその概要が、非特許文献３にはジョブスケジューラについて記載されている。
【０００３】
また、キューの設定を自動的に設定する方法も提案されている。例えば特許文献１には、投入されたジョブの状況により、ジョブクラスとジョブ割り当て単位の対応を動的に設定し直すことを可能とし、システムの利用形態に則した適切なジョブスケジューリングによる資源の有効利用、システム性能に向上を図った「ジョブスケジューリング方式」が開示されている。
特許文献１に記載のものは、各キュー内のジョブ数や、累積ジョブ数等に応じてキューに割り当てるべきプロセッサを動的に変化させることが出来るようにしたものである。
【０００４】
さらにキューでの設定だけでは不十分な場合として、ユーザ毎あるいは部署毎にジョブの優先度を決めて、優先度の等しいジョブはジョブ投入の順序にかかわらず、ジョブを実行したい場合がある。このような場合に設定を行うためのツールとして、スケジューラがある。
従来のスケジューラの例としては、非特許文献４，５に記載のもの（以下SunGrid/EEという）や、非特許文献６，７，８，９に記載のもの（以下mauiスケジューラという）がある。
【０００５】
いずれのスケジューラでもさまざまな機能があるが、その中に、fair share（均等割り当て) 機能がある。この機能を用いることで、ユーザ毎、グループ毎などの基準で均等にジョブを選択し、実行させることが出来る。
上記SunGrid/EEについては、非特許文献４に概要が、非特許文献５にその詳細な説明がある。
これによると、SunGrid/EEは、ticketと呼ばれる仮想的な計算資源の使用権と管理者が設定したticketの分配方法を用いて、スケジューリングを行う。
ticketの分配方法は、部署毎、グループ毎、ユーザ毎等にticketを割り振る際に、どのような比率で割り振るかを決める。ticketは計算機の利用を希望する、すなわちジョブを投入している部署、グループ、ユーザのみに分配される。
例えば、部署Ａと部署Ｂと部署Ｃが１: ３: ６の割合で割り振られ、各部署内では全てのユーザが均等に割り振られると設定されている場合に、部署ＡのユーザＸ、部署ＣのユーザＹ、ユーザＺがジョブを投入すると、まずticket（総量はかりに７００とする) がジョブを投入している部署Ａと部署Ｃに割り振られる。この結果、部署Ａは１００、部署Ｂは６００のticketを受け取る。ユーザＸは部署Ａのticketを全て割り振られ、ユーザＹ、Ｚは部署Ｂのticketを均等に割り振られるため、ユーザＸ，Ｙ，Ｚはそれぞれ、１００，３００，３００のticketを受け取る。ticketは更に各ユーザが投入したジョブに割り振られ、ジョブ当たりのticketの多いジョブから順に実行される。
このようにして、ユーザ毎、グループ毎等の基準で均等にジョブを選択し、実行することが出来る。
【０００６】
また、前記Mauiスケジューラについては、非特許文献６に概要が、非特許文献７にユーザマニュアルが、非特許文献８，９には管理マニュアルがある（特に、非特許文献８の６．３章、FairShare(PP.67-73) 、非特許文献９の３．３章Scheduling Interation and Job Flow,PP.24-28 参照）。これによると、Mauiスケジューラは、過去の計算資源の利用量を計算し、その計算量がユーザ、グループ等に割り当てられるべき計算量よりも多ければ、キューに残っていてその後で実行すべきジョブ優先度を下げる。
SunGrid/EEがユーザ、グループ、部署等を階層的に構成してticketを分配するのと異なり、ユーザ、グループなどに関して、それぞれ独立に計算量を集計し、集計した計算量とユーザ、グループ等の使うべき計算量とを比較して優先度を決定する。
これにより、ユーザ単位、あるいはグループ単位などに関して単純に分配比率を決定できる場合に簡潔に管理を行うことが出来る。
【０００７】
【特許文献１】
特開平９−１０１９０２号公報
【非特許文献１】
"Product Features", 〔2002/11/05検索〕、インターネット＜ＵＲＬ： http://www.openpbs.com/features.html ＞
【非特許文献２】
"PBS Technical Overview"〔2002/11/05検索〕、インターネット＜ＵＲＬ： http://www.openpbs.com/overview.html ＞
【非特許文献３】
"The Job Scheduler" 〔2002/11/05検索〕、インターネット＜ＵＲＬ： http://www.openpbs.com/scheduler.html＞
【非特許文献４】
"Sun[tm] ONE Grid Engine, Enterprise Edition",2002年,Sun Microsystems 社〔2002/9/30 検索] 、インターネット＜ＵＲＬ： http://www.sun.com/software/gridware/sgeee53 ＞
【非特許文献５】
"Sun[tm] ONE Grid Engine, Enterprise Edition White Paper How Sun[tm]Grid Engine,Enterprise Edition 5.3 Works",2002年,Sun Microsystems 社〔2002/9/30 検索] 、インターネット＜ＵＲＬ： http://www.sun.com/software/gridware/sgeee53/wp-sgeee/wp-sgeee.pdf ＞
【非特許文献６】
"Maui Overview",2002年,Supercluster Research and Development Group, 〔2002/11/05検索〕、インターネット＜ＵＲＬ： http://www.supercluster.org/documentation/maui/mauioverview.html ＞
【非特許文献７】
"Maui Users Manual",2002年,Supercluster Research and Development Group, 〔2002/11/05検索〕、インターネット＜ＵＲＬ： http://www.supercluster.org/documentation/maui/mauiusers.html＞
【非特許文献８】
"6.3 FairShare(pp.67-73)"2002 年,Supercluster Research and DevelopmentGroup, 〔2002/11/05検索〕、インターネット＜ＵＲＬ： http://www.supercluster.org/documentation/maui/mauiusers.html＞
【非特許文献９】
"3.3 Scheduling Iterations and Job Flow(pp.24-28)"2002年,Supercluster Research and Development Group, 〔2002/11/05検索〕、インターネット＜ＵＲＬ： http://www.supercluster.org/documentation/maui/mauiusers.html＞
【０００８】
【発明が解決しようとする課題】
しかしながら、従来のバッチジョブ管理システムでは、キューの設定は管理者の手作業で行うものであって、各キューに割り当てるべきプロセッサの数を、管理者があらかじめ予測するのは困難であった。また一度うまく設定できたとしても、ユーザのジョブ投入状況によって設定変更する必要がある。
キューに割り当てられるプロセッサの数が不適当であれば、他のキューにジョブがあるにもかかわらず、アイドル状態のプロセッサが生じ、非効率的な運用となる。
前記特許文献１に記載の「ジョブスケジューリング方式」では、各キュー内のジョブ数や、累積ジョブ数等に応じてキューに割り当てるべきプロセッサを動的に変化させることが出来るが、どのようなキューが必要か、またそこに課すべき実行時間などの制約はやはり管理者があらかじめ設定する必要がある。
【０００９】
更に、従来のバッチジョブ管理システムでは、ジョブ投入時に必要となる計算量が判明していたため、必要となるプロセッサ数はバッチジョブ管理システムがあらかじめ計算して与えることが出来た。しかし、ＷＷＷサーバをこのようなマルチプロセッサシステム上で稼働させて運用する場合のように、外部からの要求により、必要な処理量が動的に変化する場合には、従来のバッチジョブ管理システムではこのような状況に対応することが出来ないという問題点もあった。
更に、単純なバッチジョブ管理システムでは、キュー内のジョブはどのユーザが投入したものであるか特に区別しなかったため、一人のユーザが極めて大量のジョブを投入することで、他のユーザのジョブがあるにもかかわらず、ほとんど全てのプロセッサを専有することが可能であった。
【００１０】
スケジューラを設定することで、この問題には部分的に対処できる。前記Sun-Grid/EE では、ticketと呼ばれる計算資源の利用権をジョブ数で割ってジョブの優先度を決めるが、単純なバッチジョブ管理システムと逆に、ジョブ数が極端に多い場合には利用権が多いにもかかわらずジョブが処理されないと言う問題点があり、Mauiスケジューラと同様の過去の計算使用量に基づくticket割当を併用して、この問題を緩和するという複雑な運用を行う必要がある。
また、Mauiスケジューラでは、ユーザ毎、グループ毎の計算量を計算し、その他の優先度パラメータとともに重みつき総和を計算するため、非常に複雑な優先度管理が必要となり、管理が難しい。さらに、部署の内部でユーザに計算量を割り振るような優先度は記述できないと言う問題点を持っている。
【００１１】
本発明は上記事情に鑑みなされたものであって、キューを用いず、動的にプロセッサを割当直すことにより、マルチプロセッサシステムを容易にかつ、効率的に運用できるようにすることを第１の目的とする。
また本発明はユーザが動的に利用したいプロセッサ数を変更したい場合に、管理者の設定した範囲内でプロセッサ数の割当を変更することを可能にすることを第２の目的とする。
また本発明はユーザがいかに多くのジョブを投入しても他のユーザのジョブの実行が阻害されず、かつ、管理者が容易にユーザ、グループ等の単位での利用率を設定できるようにすることを第３の目的とする。
【００１２】
【課題を解決するための手段】
図１に本発明のシステムの基本構成を示す。同図に示すように、本発明においては、ジョブスケジューラ１の内部にジョブクラスタＩＤ生成器１１とプロセッサ割当器１２が設けられている。
ジョブクラスタＩＤ生成器１１はＩＤ要求が来る度に新しいＩＤを生成し、返す。プロセッサ割当器１２は、あらかじめ管理者３が決めた管理ポリシーと、あらかじめ指定された利用可能プロセッサに基づき、プロセッサ要求を出来るだけ満たすよう利用可能プロセッサを求める。なお、管理ポリシーや利用可能プロセッサは、状況に応じてジョブスケジューラ１を利用中も変更可能である。
図１において、ユーザ４は本発明のジョブスケジューリングを利用するにあたり、管理プロセス２を一つ作成する。
管理プロセス２は、まず、ジョブクラスタＩＤ生成器１１にジョブクラスタＩＤ要求を出し、新しいジョブクラスタＩＤを得る。
ここで、ジョブクラスタＩＤとは、ユーザが指定したジョブ群またはサーバ群に対して生成されるＩＤであり、例えば、ユーザが強い関連性のあると考えるジョブ群についてＩＤをそれぞれ要求することにより、各ジョブ群にジョブクラスタＩＤが割り当てられる。なお、一人のユーザに対して複数のジョブクラスタＩＤを発行することもできるし、また、複数のユーザでジョブクラスタＩＤを共有することもできる。
【００１３】
次に、管理プロセス２は、ジョブスケジューラ１に対して、ジョブクラスタＩＤを伝えて、利用したいプロセッサ数を要求する。可能な要求方法はプロセッサ割当器１２が解決できる範囲でどのような形式でも良く、例えば、要求は具体的なプロセス数で行われる他、プロセッサを利用する際に支払っても良い金額とともに行ったり、単純に利用可能な範囲で出来るだけ多くとして行うことが出来る。
プロセッサ要求は、許可されるか、許可されないかであり、許可されれば何らかの時点で割り当てプロセッサが、管理プロセス２に通知される。割り当てプロセッサは状況に応じて何度も通知されることがある。割り当てプロセッサは状況によっては一つも無い場合があり得る。また、状況によっては、一度許可された要求が拒否されることがある。
管理プロセス２はジョブスケジューラ１から割り当てプロセッサのリストを受け取り、それを元にユーザがマルチプロセッサ装置５で実行したいプログラムの実行を行う。
【００１４】
プログラムの実行を行わせる実行管理装置としては、以下のような様々な方式が考えられる。
(i) 図１に示すように、前記図６に示したバッチジョブ管理システムと同様の実行管理装置６を用いる。
実行管理装置として、前記図６に示したのと同様のバッチジョブ管理システムを用い、図１に示すように、利用可能ノード（プロセッサ）をジョブキュー６１に割り当て、管理プロセス２はジョブをキューに投入するという方式が考えられる。
この場合、ジョブスケジューラ１のプロセッサ割り当て器１２から随時送られて来るプロセッサ割り当て結果は、管理プロセス２が受け取ってから実行管理装置６に転送する他、直接実行管理装置が受け取るようにできる。
(ii)管理プロセスが並列タスク実行プログラムを兼ねる。
別の例としては、後述する図２に示すように、管理プロセス２が並列タスク実行プログラムを兼ねていて、割り当てられたプロセッサ上でタスク処理プログラムを起動し、タスクをそれらのタスク処理プログラムに振り分けて実行する事も考えられる。この場合、実行管理装置は仮想的な存在であり、管理プロセス２がその役割を兼ねていると考えられる。
(iii) タスクをそれらのタスク処理プログラムに振り分ける別のプログラムまたはハードウェアを設ける。
また、別の例としては、後述する図３に示すように、割り当てられたプロセッサ上でタスク処理プログラムを起動するが、タスクをそれらのタスク処理プログラムに振り分ける別のプログラムまたはハードウェア（以下タスク振り分け手段という）を設け、管理プロセス２は上記タスク振り分け手段に対して、振り分け先を通知するように実行することも考えられる。この場合、実行管理装置は仮想的な存在であり、管理プロセスがその役割を兼ねていると考えられる。
なお、この場合、上記タスク振り分け手段は、外からのタスク振り分け要求を受け付けることもできる。
【００１５】
以上のように、本発明においては、管理プロセスからの要求に対して、ジョブクラスタＩＤを生成し、管理プロセスからジョブクラスタＩＤを指定して、利用したいプロセッサ数の要求があったとき、プロセッサ割当手段により、予め定めた管理ポリシーと、予め指定された利用可能プロセッサに基づき、上記ジョブクラスタＩＤを単位として利用可能プロセサ中からプロセッサを割り当てる。
また、上記プロセッサ割当手段は、ジョブクラスタＩＤ、プロセッサ数、割り当て希望時刻、専有時間数等を指定してプロセッサの要求があったとき、この要求に応じて、上記ジョブクラスタＩＤを単位として利用可能プロセサ中からプロセッサを割り当てることができる。また、複数回の割り当て要求に対して許可／不許可とすることもできる。
さらに、前記SUNGrid/EEのticket計算方式と同じ方法を用い、上記プロセッサ割当手段が、部署、グループ毎、ユーザ毎に均等にプロセッサを割り当てるように構成することもできる。
【００１６】
この結果、管理者があらかじめキューを設定して各キューにプロセサを割り当てる必要が無くなる。また一切キューを用いないので、どのようなキューが必要かを管理者があらかじめ設定する必要もない。
従来キューの設定を行っていたのは、短時間のジョブと長時間のジョブが同じキューに並ぶと、平均待ち時間が長くなってしまう問題点を解決するためであった。本発明では、キューはそれぞれの管理プロセス（ジョブクラスタＩＤ) に対して存在するため、平均待ち時間が長くなってしまう問題点は元から存在しない。
そして、例えば、短時間ジョブ用のキューのためにプロセサを予約しておく必要が無いため、短時間のジョブが存在しないときには全てのプロセサを用いて容易にかつ効率良く運用することが出来る。
したがって、キューを用いず、動的にプロセッサを割当直すことにより、マルチプロセッサシステムを容易にかつ、効率的に運用することができ、前記第１の課題を達成することが出来る。
また、本発明では、複数回プロセサ要求を出すことが許可されうる。このため、ＷＷＷサーバのように外部からの要求により、必要な処理量が動的に増減するような場合においても、処理量が増えるにつれて、要求するプロセサ数を増やすことができる。プロセサ割当手段は、要求が来る度にプロセサの割当をし直し、より優先度の低い（あるいは、別の時刻に計算しても支障の無い) ジョブクラスタＩＤに割り当てられたプロセサを、処理量が増えたジョブクラスタＩＤに割り当て直すことができる。これにより、動的に処理量が変化する場合にも対処することが出来る
したがって、管理者の設定した範囲内でプロセッサ数の割当を変更することを可能にすることができ、前記第２の課題を達成することが出来る。
さらに、本発明では、管理者が管理ポリシーを記述することで、ユーザ毎あるいはグループ毎にまとめて、プロセサ数を均等に割り振るよう指示することが出来る。
また、前記SunGrid/EEのticketと同じ計算を行い、予め定められたticketの割り当てに応じて、部署、グループ、ユーザ、ジョブクラスタＩＤ等にプロセッサの割り当てを行うことで、グループからユーザへの再割り振り等、前記Mauiスケジューラで難しかった割り振り方法も容易に行える。
さらに、前記SunGrid/EEで問題となっていたジョブへのticketの割り振りの問題も無くなるため、ジョブ数が極端に多くても少なくても同じ数のプロセサを使うことが出来る。
このため大量のジョブの投入、あるいはジョブクラスタの作成を行っても、利用可能なプロセサ数は、他のユーザ／グループの利用可能なプロセサ数と均等あるいは管理者が指示した比率となるようにすることが出来る。
したがって、ユーザがいかに多くのジョブを投入しても他のユーザのジョブの実行が阻害されず、かつ、管理者が容易にユーザ、グループ等の単位での利用率を設定することができ、前記第３の課題を達成することが出来る。
【００１７】
【発明の実施の形態】
図１は本発明の第１の実施例のシステムの構成を示す図であり、同図は前記図６に示したバッチジョブ管理システムと同様の実行管理装置６によりプログラムの実行を行う場合の構成を示している。
同図において、１はジョブスケジューラであり、管理プロセスからの要求に応じてジョブクラスタＩＤを生成するジョブクラスタＩＤ生成器１１と、管理者３が設定する管理ポリシーに基づき、ジョブクラスタＩＤ単位でプロセッサを割り当てるプロセッサ割当器１２が設けられている。また、ジョブスケジューラ１には、各ジョブクラスタＩＤに関しての情報を管理するプロセッサ割当ＤＢ１３が設けられている。
２は管理プロセスであり、ジョブクラスタＩＤ生成器１１に対してジョブクラスタＩＤ要求を行うとともに、ジョブスケジューラ１に対して、ジョブクラスタＩＤを伝えて、利用したいプロセッサ数を要求し、割り当てが許可されたとき、実行管理装置６に割り当て結果を転送する。また、管理プロセス２は、ジョブクラスタＩＤ等の環境変数ＪＣＩＤを保存する領域を有する。
３は前記した管理ポリシーを定める管理者、４はユーザ、５は複数のプロセッサから構成されるマルチプロセッサ装置である。
６は従来のバッチジョブ管理システムと同様の実行管理装置であり、前記したように、ジョブキュー６１に投入されたジョブと、マルチプロセッサ装置５のプロセッサの実行状況を管理しており、実行していないプロセッサに未実行のジョブを割り当て実行をさせる。
なお、前記ジョブスケジューラ１と上記実行管理装置６で本発明のジョブスケジューリング装置を構成する。
【００１８】
図１に示したプロセッサ割当器１２は以下のようにしてプロセッサの割り当てを行う。
プロセッサ割当器１２は、プロセッサの割り当てが必要になる度に呼び出される。より具体的には、以下のような際に呼び出される。
・管理ポリシーが変更になった。
・利用可能プロセッサが増加／減少した。
・いずれかの管理プロセスからプロセッサ要求が起きた。あるいは要求内容が変更された。
・管理プロセスが無くなった。すなわち要求されるプロセッサが減少した。
割当を行う単位はジョブクラスタＩＤ単位とし、一つのジョブクラスタＩＤに一式のプロセッサを割り当てる。
割り当てが行われると、割り当て結果は各ジョブクラスタＩＤに通知する。通知の出力先は、ジョブクラスタＩＤを伝えて要求を行った管理プロセス２または、管理プロセス２が指定したプロセスやファイルである。
【００１９】
プロセッサ割当器１２は、管理者３が記述する管理ポリシーによって動作を変える。さまざまな管理ポリシーが考えられるが、具体的には例えば以下のようなポリシーが考えられる。
(i) あるジョブクラスタＩＤから、一定数のプロセッサを一定の時間専有する要求が来た場合それを許可するべきかどうか。
判断は例えば、ユーザ名、ユーザの属するグループ、ユーザの支払いアカウントなどに基づいて行われる。判断は、また、専有を希望するプロセッサ数や専有を希望する時間数にも基づいて行われる。
(ii)あるジョブクラスタＩＤから、一定数のプロセッサを一定の時刻から一定時間専有する要求が来た場合それを許可するべきかどうか。
判断は例えば、ユーザ名、ユーザの属するグループ、ユーザの支払いアカウントなどに基づいて行われる。判断は、また、専有を希望するプロセッサ数や専有を希望する時間数、専有を希望する時刻にも基づいて行われる。
(iii) あるジョブクラスタＩＤから、複数回プロセッサ要求を増減させて要求する場合、複数回のプロセッサ要求を許可すべきかどうか。
判断は例えば、ユーザ名、ユーザの属するグループ、ユーザの支払いアカウントなどに基づいて行われる。また、複数回の要求を行うことが許可されたとしても、それぞれの要求で判断は、また、各プロセッサ要求の際のプロセッサ数の上限や、変更頻度、要求回数にも基づいて行われる。
【００２０】
(iv)あるジョブクラスタＩＤから、均等に出来るだけ多くのプロセッサを要求して来た場合、同じ要求を行うジョブクラスタＩＤにはそれぞれ同じ数のプロセッサを均等に割り当てるべきか、あるいは、より優先的に割り当てるべきか。
判断は例えば、ユーザ名、ユーザの属するグループ、ユーザの支払いアカウントなどに基づいて行われる。
また、均等に割り当てる際の単位をどうすべきか。例えば、全てのジョブクラスタを平等に扱うべきか、あるいは、一人のユーザが発行した複数のジョブクラスタ全体に割り当てられるプロセッサ数と他のユーザが発行した複数のジョブクラスタ全体に割り当てられるプロセッサ数が均等になるべきか、あるいは、各ユーザが属するグループ単位で均等になるべきかなど。
均等割り当ての場合、この割当単位と比率に基づいて前記SUNGrid/EEのticket計算方式と同じ方法でプロセッサの割当比率を計算し、残っているプロセッサ数を比例配分することができる。
例えば、部署、グループ、ユーザ、ジョブクラスタＩＤにticketを割り当て、均等割り当て要求があると、前記SUNGrid/EEと同様に、部署、グループ、ユーザ、ジョブクラスタＩＤに予め定められたticketの割り当てに応じてプロセッサを割り当てる。
(v) プロセッサ数が足りない場合どのジョブクラスタＩＤの要求を拒否すべきかどうか。
判断は例えば、ユーザ名、ユーザの属するグループ、ユーザの支払いアカウントなどに基づいて行われる。判断は、また、要求がどのように行われたか（プロセッサ数／時間指定の専有、プロセッサ数／時間／時刻指定の専有、複数回要求可能な要求、均等の要求) に基づいても行われる。
【００２１】
これらの管理ポリシーが設定された状態で、プロセッサ割当器１２は以下のようにプロセッサの割当を行う。
(i) 許可のない要求を除外する。もしもあるジョブクラスタＩＤをもつ管理プロセスから、複数回の要求が行われて、それが許可されなかった場合は、前回同じジョブクラスタＩＤで行われた要求内容を使う。
すなわち、複数回要求を認めていないジョブクラスタＩＤから要求があったときは、前回と同様に要求を認めない。
(ii)プロセッサ数／時間／時刻指定の要求を割り当てる。
(iii) プロセッサ数／時間指定の要求を割り当てる。
(iv)複数回の要求を行うことが出来るジョブクラスタＩＤの要求を割り当てる。
(v) 残ったプロセッサを均等に割り当てる。割当の単位は管理ポリシーの記述に従う。
(vi)もしもいずれかの時刻で、要求のあったプロセッサ数の合計が利用可能プロセッサ数よりも多い場合には、適当なジョブクラスタＩＤの許可を取り消す。いずれのジョブクラスタＩＤを取り消すべきかは管理ポリシーの記述に従う。
【００２２】
図２は本発明の第２の実施例のシステムの構成を示す図であり、同図は前記した管理プロセス２が並列タスク実行プログラムを兼ねる場合を示しており、管理プロセス２に、並列タスク処理を行う並列タスク実行手段２１が設けられている。この場合、前記したように実行管理装置は仮想的な存在である。
並列タスク実行手段２１は、割り当てられたプロセッサ上でタスク処理プログラムを起動し、タスクをそれらのタスク処理プログラムに振り分けて実行させる。
その他の構成は、図１に示したものと同様であり、管理プロセス２は、ジョブクラスタＩＤ生成器１１にジョブクラスタＩＤ要求を出し、新しいジョブクラスタＩＤを得る。次に、管理プロセス２は、ジョブスケジューラ１に対して、ジョブクラスタＩＤを伝えて、利用したいプロセッサ数を要求する。
プロセッサ要求が許可されると、管理プロセス２はジョブスケジューラ１から割り当てプロセッサのリストを受け取り、並列タスク実行手段２１は、割り当てられたプロセッサ上でタスク処理プログラムを起動し、ユーザがマルチプロセッサ装置５で実行したいプログラムの実行を行う。
【００２３】
図３は本発明の第３の実施例のシステムの構成を示す図であり、同図は、前記した、タスクを振り分ける別のプログラムまたはハードウェアを設ける場合を示しており、同図に示すようにタスク振り分け手段７が設けられている。この場合も、前記したように実行管理装置は仮想的な存在である。
タスク振り分け手段７は、管理プロセス２からタスク振り分け先が通知されると、割り当てられたプロセッサ上でタスク処理プログラムを起動する。また、タスク振り分け手段７は、外からの要求を受け付けることもできる。
その他の構成は、図１に示したものと同様であり、管理プロセス２は、ジョブクラスタＩＤ生成器１１にジョブクラスタＩＤ要求を出し、新しいジョブクラスタＩＤを得る。次に、管理プロセス２は、ジョブスケジューラ１に対して、ジョブクラスタＩＤを伝えて、利用したいプロセッサ数を要求する。
プロセッサ要求が許可されると、管理プロセス２はジョブスケジューラ１から割り当てプロセッサのリストを受け取り、タスク振り分け手段７に通知する。タスク振り分け手段７は、割り当てられたプロセッサ上でタスク処理プログラムを起動する。
【００２４】
以下、ＵＮＩＸ上で本実施例のジョブスケジューリングを行う場合について説明する。
（１）ジョブスケジューラ１と管理プロセス２との情報伝達手段
管理プロセス２からジョブスケジューラ１への情報伝達はジョブクラスタＩＤの獲得、プロセッサ要求およびジョブクラスタの終了である。また、ジョブスケジューラ１から管理プロセス２への情報伝達は、要求の拒否の通知、あるいは、プロセッサ割り当て結果である。後者は非同期的に通信が起きる。
そこで、以下のような３種のコマンドを用意する。
・jobclusterコマンド
% jobcluster  管理プロセスコマンド文字列
jobclusterコマンドはジョブクラスタＩＤをまず取得し、それを環境変数ＪＣＩＤにいれた後、管理プロセスコマンド文字列に従って管理プロセスをexecシステムコールを用いて起動する。execシステムコールを用いるためjobclusterプロセスはそのまま管理プロセスになる。
【００２５】
・ jcrequestコマンド
% jcrequest [-e通知コマンド｜ -f 通知ファイル｜ -s 通知プロセス]
リクエストファイル
jcrequest コマンドは環境変数ＪＣＩＤを参照してジョブクラスタＩＤを入手する。そして、リクエストファイルにかかれたプロセッサ要求を解釈する。もしもプロセッサ要求が管理ポリシーに違反していて拒否された場合は、エラーメッセージを出力して、終了状態が０以外となる。
もしもポリシーに違反していなければ、オプションで指定された手段で結果が通知される。通知は割当プロセッサが変更される度に行われる。
もしも、-eオプションを指定していれば、その引数の通知コマンドの標準入力にプロセッサ名の一覧が入力される。
もしも、-fオプションを指定していれば、その引数の通知ファイルにプロセッサ名の一覧が書き出される。
もしも、-sオプションを指定していれば、標準出力にプロセッサ名の一覧と空行が書き出された後、引数の通知プロセスにSIGHUPシグナルが送られる。この場合、別のプロセスから後述のjcend コマンドを投入するまで、jcrequest コマンドは終了しない。
もしも何のオプションも指定していなければ、その要求に起因するプロセッサ割当の結果であるプロセッサ名の一覧のみを標準出力に書き出し、終了する。このコマンドでは以後の通知は行われない。
【００２６】
・jcend コマンド
% jcend
jcend コマンドは環境変数ＪＣＩＤを参照してジョブクラスタＩＤを入手する。そして、そのジョブクラスタＩＤへ割り当てられたプロセッサを全て開放し、他のジョブクラスタＩＤに割り当て直す。必要であれば、jcrequest コマンドを正常終了させる。
【００２７】
（２）管理プロセスの起動
管理プロセス２は最初にジョブクラスタＩＤを取る必要がある。そこで、前述のjobclusterコマンドを用いてジョブクラスタＩＤを取ってから管理プロセス２を起動する。
管理プロセス２は、必要に応じてプロセッサ要求をjcrequest コマンドで要求する。そして、通知があるたびに割当プロセッサで適切な実行が行えるようにする。
もしも管理プロセスが正常終了する際にはjcend コマンドを実行する。管理プロセスは用途毎により詳細な作業内容が異なるので、それぞれ列挙する。
【００２８】
（３）ジョブクラスタＩＤ生成
ＩＤを作成するために排他制御を行う。ＩＤはバッチキュー名として用いられるようにするため、アルファベット＋数値のような形式を取る。ＩＤは再利用せず、単調に数値を大きくしてＩＤを生成する。
【００２９】
（３）プロセッサ割り当て
jcrequest コマンドは前記したように、管理ポリシーのチェックとプロセッサ割当を行う。
管理ポリシーのチェックでプロセッサ要求が拒否されなかった場合は、要求内容をプロセッサ割当ＤＢに保存した後、以下に説明する、内部でプロセッサ割り当てを行うjcresched コマンドを呼び出す。保存を行う際に、ＤＢを排他的に操作するためにロックを用いる。
jcresched コマンドは、プロセッサの割り当てが必要になる度に呼び出され、より具体的には、以下のような際に呼び出される。
(i) 管理ポリシーが変更になった。
(ii)利用可能プロセッサが増加／減少した。
(iii) いずれかの管理プロセスからプロセッサ要求が起きた。あるいは要求内容が変更された。
(iv)管理プロセスが無くなった。すなわち要求されるプロセッサが減少した。
【００３０】
・jcresched コマンド
% jcresched
jcresched コマンドは前記プロセッサ割当ＤＢ１３、管理ポリシー、利用可能プロセッサリスト（ファイル) を参照して、プロセッサ割当を行う。引数は無い。また、jcresched コマンドは、プロセッサ割当ＤＢ１３を排他的に操作するためにロックを用いる。これにより同時に二つ以上のjcresched コマンドが実行されることを防ぐ。
プロセッサ割当ＤＢ１３は、前記したようにジョブスケジューラ１に設けられ、少なくとも以下の４項目を含み、各ジョブクラスタＩＤに関しての情報を管理する。
・ジョブクラスタＩＤ
・プロセッサ要求
・以前の割当結果
・通知手段（複数あるかも知れない)
【００３１】
そして、ジョブスケジューラ１のプロセッサプロセッサ割当器１２は、前記したように、以下のようにプロセッサの割当を行う。
(i) プロセッサ数／時間／時刻指定の要求を割り当てる。
(ii)プロセッサ数／時間指定の要求を割り当てる。
(iii) 複数回の要求を行うことが出来るジョブクラスタＩＤの要求を割り当てる。
(iv)残ったプロセッサを均等に割り当てる。割当の単位はポリシーの記述に従う。
(v) もしもいずれかの時刻で、要求のあったプロセッサ数の合計が利用可能プロセッサ数よりも少ない場合には、適当なジョブクラスタＩＤの許可を取り消す。もしも、均等に割り当てるジョブクラスタＩＤの場合は、割り当てプロセッサにどのプロセッサも割り当てない。いずれのジョブクラスタＩＤを取り消すべきかは管理ポリシーの記述に従う。
そして、各ジョブクラスタＩＤに関する割り当て結果をそのジョブクラスタの通知手段に通知する。通知方法はjcrequest コマンドで説明した通りである。
【００３２】
（４）ジョブを投入する管理プロセスの作業
従来のバッチジョブを投入する作業を本発明で利用する場合、この管理プロセスが必要となる。この管理プロセスは、図１に示した実行管理装置６と連係を行って作業をする。
図４に、ジョブを投入する際の処理の流れを示す。
まず、jobclusterコマンドによりジョブクラスタＩＤを取得し、それを環境変数ＪＣＩＤにいれた後、管理プロセスコマンド文字列に従って管理プロセス２を起動し、ジョブクラスタＩＤと同名のキューを実行管理装置６上で作成する（図４の(1) ）。ジョブクラスタＩＤは環境変数ＪＣＩＤを用いる。
次に、jcrequest -eコマンドを用いて、キューに割り当てられたプロセッサを変更するコマンド“qresched $JCID”をジョブスケジューラ１に登録する。qreschedコマンドは引数のＪＣＩＤをキュー名として、標準入力を割り当てプロセッサとして解釈し、キューに割り当てるプロセッサを変更する。jcresched コマンドはプロセッサ割当ＤＢ、管理ポリシー、利用可能プロセッサリスト（ファイル) を参照して、プロセッサ割当を行う。（図４の(2) ）。
その後で、通常のジョブの投入を行う（図４の(3) ) 。ジョブの投入に当たってキュー名としてジョブクラスタＩＤを用いる。これにより、実行管理装置６はキューを取り出して、実行ノード群にジョブを割り当て実行させる（図４の(4) ）。
また、非同期にプロセッサ割り当てが変更される場合には、上記と同様に、jcrequest -eコマンドを用いて、キューに割り当てられたプロセッサを変更するコマンド“qresched $JCID”をジョブスケジューラ１に登録する。qreschedコマンドは引数のJCIDをキュー名として、標準入力を割り当てプロセッサとして解釈し、キューに割り当てるプロセッサを変更する。jcresched コマンドはプロセッサ割当を行う（図４の(5) ）。その際、全てのＪＣＩＤにも割り当て結果が通知される。
そして、全ての投入したジョブが終了したかどうかを待ち合わせて、全て終了した後に、jcend コマンドを投入する（図４の（6)）。また、キューを廃棄してユーザに終了を通知する。
キューの作成やキューに割り当てるプロセッサの変更は、図１の実行管理装置６と連係を行うことで実現でき、例えばPBS ではqmgrコマンドを呼び出すことで実現できる。また、ジョブの投入にはqsubコマンド、ジョブの監視にはqstat コマンドを用いて実現できる。
（５）動的にプロセッサ数を変更する管理プロセスの作業
ＷＥＢサーバや、検索サーバなど外部のクライアントからのタスクを処理するようなプログラムを実行する際には、以下のような管理プロセスが有用である。
図５に、動的にプロセッサ数を変更する場合の処理の流れを示す。
まず、サーバ管理者は、起動引数として管理コマンド名を通知して、jobclusterコマンドによりジョブクラスタＩＤを取得する（図５の(1) ) 。
次に、jcrequest -eコマンドを用いて、キューに割り当てられたプロセッサを変更するコマンド“resched $JCID ”をジョブスケジューラに登録する。resched コマンドは引数のＪＣＩＤをキュー名として、標準入力を割り当てプロセッサとして解釈し、サーバを起動するプロセッサを変更する。jcresched コマンドはプロセッサ割当を行う。（図５の(2) ）。
そして、もしも既に動いているサーバのあるプロセッサがその割り当てプロセッサに含まれていなければ、そのサーバを終了させる。また、もしもまだサーバの動いていないプロセッサがその割り当てプロセッサに含まれていれば、そのプロセッサでサーバを起動させる（図５の(3) ）。
その後で、タスクの振り分け（割り当て）を行う。タスクは、割り当てプロセッサのいずれかに割り振り、得られた結果はタスクを投入したクライアントに返すようにする（図５の(4) ）。もしも別のタスク振り分け機構または振り分け装置を利用する場合は、resched コマンドは上記に述べたサーバの起動／終了の他に、振り分け先をその機構または装置に通知する作業を行う。
また、高負荷検出によるプロセッサ要求や、低負荷検出によるプロセッサの放棄がある場合には、前記したように、jcrequest -eコマンドを用いて、キューに割り当てられたプロセッサを変更するコマンド“resched $JCID ”をジョブスケジューラに登録し、サーバを起動するプロセッサを変更する（図５の(5) ）。
そして、前記したようにサーバを起動させ、タスクの割り当てを行う（図５の(6) ）。
また、このような管理プロセスは通常自分から終了することは無いので、ユーザが外部から管理プロセスの終了を指示した際のみ終了する。終了する際には、前記したように、jcend コマンドを実行する（図５の(7) ）。
（６）実行日時を予約する管理プロセスの作業
前記図４に示したジョブを投入する管理プロセスと全く同じ管理プロセスで実施できる。
唯一の相違点は、jcrequest コマンドでの要求プロセッサの要求内容として時刻／専有時間／専有プロセッサ数を指定してプロセッサを要求する点だけである。
【００３３】
（付記１）  マルチプロセッサシステムにおけるジョブスケジューリング方法であって、
管理プロセスからの要求に対して、ＩＤを生成し、
管理プロセスから上記ＩＤを指定して利用したいプロセッサ数の要求があったとき、
予め定めた管理ポリシーと、予め指定された利用可能プロセッサに基づき、上記ＩＤを単位としてプロセサを割り当てる
ことを特徴とするジョブスケジューリング方法。
（付記２）  マルチプロセッサシステムにおけるジョブスケジューリング装置であって、
管理プロセスからの要求に対して、ＩＤを生成するＩＤ生成手段と、
管理プロセスから上記ＩＤを指定して利用したいプロセッサ数の要求があったとき、予め定めた管理ポリシーと、予め指定された利用可能プロセッサに基づき、上記ＩＤを単位としてプロセサを割り当てるプロセッサ割当手段とを備えた
ことを特徴とするジョブスケジューリング装置。
（付記３）  マルチプロセッサシステムにおけるジョブスケジューリング装置であって、
管理プロセスからの要求に対して、ＩＤを生成するＩＤ生成手段と、
管理プロセスから上記ＩＤを指定して利用したいプロセッサ数の要求があったとき、予め定めた管理ポリシーと、予め指定された利用可能プロセッサに基づき、上記ＩＤを単位としてプロセサを割り当てるプロセッサ割当手段と、
管理プロセスから投入されたジョブの実行を管理する実行管理手段を備えた
ことを特徴するジョブスケジューリング装置。
（付記４）  上記実行管理手段は、管理プロセスからジョブが投入されたとき、マルチプロセッサシステムのプロセッサをジョブキューに割り当て、
管理プロセスは、上記キューにジョブを投入する
ことを特徴とする付記３のジョブスケジューリング装置。
（付記５）  上記実行管理手段は、管理プロセスからジョブが投入されたとき、割り当てられたプロセッサ上でタクス処理プログラムを起動し、タスクをそれらのタクス処理プログラムに振り分けて実行させる
ことを特徴とする付記３のジョブスケジューリング装置。
（付記６）  タスクをタスク処理プログラムに振り分ける振り分け手段を備え、上記実行管理手段は、割り当てられたプロセッサ上でタクス処理プログラムを起動し、
上記管理プロセスは、上記振り分け手段に対して、振り分け先を通知する
ことを特徴とする付記３のジョブスケジューリング装置。
（付記７）  上記管理プロセスは、上記ＩＤと、プロセッサ数と、割り当て希望時刻と、専有時間数を指定してプロセッサの割当手段に要求を出力し、
プロセッサ割当手段は、上記要求に応じて、予め定めた管理ポリシーと、予め指定された利用可能プロセッサに基づき、上記ＩＤを単位としてプロセサを割り当てる
ことを特徴とする付記２，３，４，５または付記６のジョブスケジューリング装置。
（付記８）  上記管理プロセスは、ジョブクラスタＩＤと、プロセッサ数と、専有時間数を指定してプロセッサの割当手段に要求を出力し、
プロセッサ割当手段は、上記要求に応じて、予め定めた管理ポリシーと、予め指定された利用可能プロセッサに基づき、上記ＩＤを単位としてプロセサを割り当てる
ことを特徴とする付記２，３，４，５または付記６のジョブスケジューリング装置。
（付記９）  上記プロセッサ割当手段は、複数回の割り当てを受け付けるかを許可または不許可とする手段を備えた
ことを特徴とする付記２，３，４，５，６，７または付記８のジョブスケジューリング装置。
（付記１０）  上記プロセッサ割当手段は、部署毎、グループ毎、ユーザ毎に、均等にプロセッサを割当てる
ことを特徴とする付記２，３，４，５，６，７，８または付記９のジョブスケジューリング装置。
（付記１１）  マルチプロセッサシステムにおけるジョブスケジューリングプログラムであって、
上記プログラムは、管理プロセスからの要求に対して、ジョブクラスタＩＤを生成して、ジョブクラスタＩＤを割り当てる処理と、
管理プロセスからジョブクラスタＩＤを指定して利用したいプロセッサ数の要求があったとき、予め定めた管理ポリシーと、予め指定された利用可能プロセッサに基づき、ジョブクラスタを単位としてプロセサを割り当てる処理をコンピュータに実行させる
ことを特徴とするジョブスケジューリングプログラム。
【０００３４】
【発明の効果】
以上説明したように本発明によれば以下の効果を得ることができる。
（１）ジョブクラスタＩＤを単位として、プロセサ割当手段が利用可能プロセサ中からプロセサを割り当てるようにしているので、管理者があらかじめキューを設定して各キューにプロセサを割り当てる必要が無くなる。
そして、例えば、短時間ジョブ用のキューのためにプロセサを予約しておく必要が無いため、短時間のジョブが存在しないときには全てのプロセサを用いて効率良く運用することが出来る。
（２）複数回プロセサ要求を出すことが許可されうる。このため、ＷＷＷサーバのように外部からの要求により、必要な処理量が動的に増減するような場合においても、処理量が増えるにつれて、要求するプロセサ数を増やすことができる。プロセサ割り当て器は、要求が来る度にプロセサの割当をしなおし、より優先度の低い（あるいは、別の時刻に計算しても支障の無い) ジョブクラスタＩＤに割り当てられたプロセサを、処理量が増えたジョブクラスタＩＤに割り当て直すことができる。これにより、動的に処理量が変化する場合にも対処することが出来る。
（３）管理者が管理ポリシーを記述することで、ユーザ毎あるいはグループ毎にまとめて、プロセサ数を均等に割り振るよう指示することが出来る。
このため大量のジョブの投入、あるいはジョブクラスタの作成を行っても、利用可能なプロセサ数は、他のユーザの利用可能なプロセサ数と均等あるいは管理者が指示した比率となるようにすることが出来る。
【図面の簡単な説明】
【図１】本発明の第１の実施例のシステムの構成を示す図である。
【図２】本発明の第２の実施例のシステムの構成を示す図である。
【図３】本発明の第３の実施例のシステムの構成を示す図である。
【図４】本発明の実施例のジョブを投入する管理プロセスの動作を説明するシーケンス図である。
【図５】本発明の実施例の動的にプロセッサ数を変更する管理プロセスの動作を説明するシーケンス図である。
【図６】従来のバッチジョブ管理システムによるスケジューリングを説明する図である。
【符号の説明】
１    ジョブスケジューラ
１１  ジョブクラスタＩＤ生成器
１２  プロセッサ割当器
１３  プロセッサ割当ＤＢ
２    管理プロセス
２１  並列タスク実行手段
３    管理者
４    ユーザ
５    マルチプロセッサ装置
６    実行管理装置
７    タスク振り分け手段
【図１】
2004192400.tif 000003
【図２】
2004192400.tif 000004
【図３】
2004192400.tif 000005
【図４】
2004192400.tif 000006
【図５】
2004192400.tif 000007
【図６】
2004192400.tif 000008