JP2013164750A

JP2013164750A - ジョブ実行管理システム

Info

Publication number: JP2013164750A
Application number: JP2012027805A
Authority: JP
Inventors: Goshi Anabuki; 豪士穴吹
Original assignee: Nomura Research Institute Ltd
Current assignee: Nomura Research Institute Ltd
Priority date: 2012-02-10
Filing date: 2012-02-10
Publication date: 2013-08-22

Abstract

【課題】ジョブの処理フローを自動生成する技術の実現。
【解決手段】複数のサーバと管理サーバを備えたジョブ実行管理システム10。管理サーバ12は、各ジョブの実行に必要なリソース量、各ジョブの処理時間、前提ジョブ、時限を格納しておくジョブ情報記憶部42と、ジョブ情報記憶部42を参照し、複数のジョブを実行順に整列させた処理フローを生成する処理フロー生成部30と、各ジョブを各サーバの実行スケジュールに割り当てた割当予定情報を生成し、これに従って、各ジョブの実行を各サーバに指令するジョブ割当部32を備える。
【選択図】図２

Description

この発明は、実行対象ジョブの属性情報に基づいて、各ジョブの処理順序及び処理サーバを自動的に特定すると共に、当該サーバにジョブの実行を指令する技術に関する。

情報処理の分野では、以前から複数のサーバを並列化し、業務に必要なジョブを分散処理することが行われている（非特許文献１参照）。
また近年では、サーバコンピュータを物理的に複数台導入する代わりに、単一のサーバを相互に独立した複数のサーバとして利用できるようにする仮想化技術が、コスト削減や省エネルギ、リソースの有効活用に資するものとして、注目されている（非特許文献２参照）。

具体的には、仮想化環境を実現するためのプログラムを物理サーバに導入し、この仮想化プログラムの機能に基づいて複数のOSをサーバにセットアップすると、各OS（以下「仮想OS」と称する）に対してサーバのCPUやメモリ、I/Oといったリソースが割り振られる。
この結果、各仮想OSは相互に独立したOSとして機能することとなり、それぞれに別個のアプリケーションプログラムを導入することで、恰も複数台のサーバを物理的に導入したのと同様の使い勝手を実現することが可能となる。
日立、バッチジョブ分散処理ソフト販売／複数サーバの並列処理で高速化インターネットURL：http://japan.zdnet.com/business-application/analysis/20420798/ 検索日：２０１１年１１月７日５分で分かる！サーバ仮想化のメリットインターネットURL：http://www.atmarkit.co.jp/ad/hp/vse0701/vse01.html 検索日：２０１１年１１月７日

物理サーバあるいは仮想サーバの別を問わず、複数のサーバ間でジョブを並列処理することにより、全体のジョブの終了時刻を早められることは当然であり、またジョブの細分化が進むほど並列処理を効率よく進められることも以前から認識されていた。
しかしながら、これまではジョブの処理フローを設計したり、個々のジョブの実行を各サーバに割り当てたりすることを人間の手で行っていたため、ジョブをあまり細かく分割すると、ジョブ間の関係が複雑となり、処理フローの設計やサーバへの割当が困難となる。
このため、実際にはジョブの細分化、ひいては処理の高速化に一定の限界が存在していた。

この発明は、このような現状に鑑みて案出されたものであり、ジョブの処理フローを自動生成できると共に、この処理フローに含まれる各ジョブの実行を複数のサーバに割り当てることを可能とする技術の提供を目的としている。

上記の目的を達成するため、請求項１に記載したジョブ実行管理システムは、ジョブを処理するための複数のサーバと、各サーバと接続された管理サーバとを備えたジョブ実行管理システムであって、上記管理サーバは、実行対象となる複数のジョブ毎に、各ジョブの処理時間と、前提ジョブが存在する場合にはその前提ジョブの特定情報と、時限が存在する場合には当該時限付ジョブの時限を格納しておくジョブ情報記憶手段と、上記ジョブ情報記憶手段を参照し、複数のジョブを実行順に整列させた処理フローを生成する処理フロー生成手段と、少なくとも上記処理フローで規定された各ジョブの処理の順番及び時限付ジョブの時限に従い、上記ジョブ情報記憶部に格納された各ジョブについて、処理サーバと投入時刻を特定した割当予定情報を生成すると共に、この割当予定情報に従って、各ジョブの実行を各サーバに指令するジョブ割当手段とを備え、上記処理フロー生成手段は、(1) 上記ジョブ情報記憶手段を参照し、時限が設定されている時限付ジョブを抽出する処理と、(2) 当該時限付ジョブに前提ジョブが設定されている場合には、当該前提ジョブを時限付ジョブの前に配置させる処理と、(3) 上記前提ジョブに他の前提ジョブが設定されている場合には、他の前提ジョブを当該前提ジョブの前に配置させる処理を実行し、さらに(3)の処理を、前提ジョブの存しない先頭ジョブに到達するまで繰り返すことにより、上記の処理フローを生成することを特徴としている。

また、請求項２に記載したジョブ実行管理システムは、請求項１のシステムであって、さらに、上記ジョブ記憶手段には各ジョブの実行に必要な特定種類のリソースの量を示す要求リソース量が格納されており、上記管理サーバは、各サーバが保有する特定種類のリソースの量である保有リソース量を格納しておくリソース配分情報記憶手段と、各サーバの現在の余裕リソース量を算出すると共に、各ジョブの要求リソース量と処理時間を参照することにより、各サーバの将来の余裕リソース量を所定の時間間隔毎に算出するリソース利用状況算出手段とを備え、上記ジョブ割当手段は、各ジョブの要求リソース量と、処理時間と、各サーバの現在及び将来の余裕リソース量を参照することにより、各ジョブの処理サーバ及び投入時刻を特定することを特徴としている。

請求項３に記載したジョブ実行管理システムは、請求項２のシステムであって、さらに、上記の実行対象ジョブが、上記処理フローに属するジョブと、当該処理フローに属さないフリーのジョブとに分かれる場合において、上記ジョブ割当手段は、上記処理フローに含まれる各ジョブの処理を優先して各サーバの余裕のある時間帯に割り当て、その後にフリーのジョブを各サーバの余裕のある時間帯に割り当てることを特徴としている。
上記「余裕のある時間帯」とは、各サーバにおいて当該ジョブの要求リソース量以上の余裕リソース量を確保できる時間帯を意味している（以下同様）。

請求項４に記載したジョブ実行管理システムは、請求項３のシステムであって、フリーのジョブのすべてについて各サーバの余裕のある時間帯を割り当てることができない場合に、上記ジョブ割当手段は、フリーのジョブの少なくとも一部についてはサーバへの割当を見合わせることを特徴としている。

請求項５に記載したジョブ実行管理システムは、請求項２〜４のシステムであって、さらに上記ジョブ割当手段は、上記処理フロー生成手段によって生成された処理フローが複数存在し、各処理フローに属する時限付ジョブの完了予定時刻から時限までの余裕時間に所定範囲以上の差が存在する場合に、少なくとも一の処理フローに属するジョブの少なくとも一部を同一サーバまたは他のサーバにおける余裕のある時間帯に再配置することにより、上記余裕時間の差を所定範囲内に縮める時間調整を実行することを特徴としている。

請求項６に記載したジョブ実行管理システムは、請求項２〜５のシステムであって、さらに上記ジョブ割当手段は、各サーバから送信されたジョブの実行結果に基づいて、予定よりも完了が遅れているジョブが存在するものと判定した場合には、当該ジョブの後ろの時間帯に配置された上記処理フローを構成するジョブを、他のサーバの余裕のある時間帯に配置させた割当予定情報を再生成し、以後はこの割当予定情報に従って各ジョブの実行を各サーバに指令することを特徴としている。

請求項７に記載したジョブ実行管理システムは、請求項２〜６のシステムであって、さらに、上記複数のサーバが、少なくとも一つの物理サーバ上に構築された仮想化環境に複数のOSを導入することによって形成された仮想サーバよりなり、上記管理サーバが、上記物理サーバが保有する特定種類のリソースの量である保有リソース量と、この物理サーバの保有リソース量の中から上記の各仮想サーバに割り当てた割当リソース量を登録しておくリソース配分情報記憶手段を備え、上記リソース利用状況算出手段が、算出した各仮想サーバの現在の余裕リソース量の中で、上記物理サーバの現在の余裕リソース量を超えているものがある場合には、当該仮想サーバの余裕リソース量を物理サーバの余裕リソース量まで減殺する処理を実行することを特徴としている。

請求項１に記載のジョブ実行管理システムによれば、各ジョブについて処理時間と、必要な前提ジョブ及び必要な時限さえ設定しておけば、後は処理フロー生成手段によって自動的に処理フローが生成されると共に、ジョブ割当手段によって各ジョブが複数のサーバに対して自動的に割り当てられる仕組みを備えているため、ジョブの実行順序の設定の労力が大幅に軽減される。この結果、ジョブのより一層の細分化が可能となる。

請求項２に記載のジョブ実行管理システムの場合、各サーバの現在及び将来の余裕リソース量と各ジョブの要求リソース量を勘案して、各ジョブの処理サーバが特定される仕組みを備えているため、処理フローに含まれる各ジョブを最適なサーバに割り当てることが可能となり、処理の効率化を実現できる。

請求項３に記載のジョブ実行管理システムの場合、処理フローを構成するジョブをフリーのジョブに優先して各サーバに割り当てる仕組みを備えているため、時限付ジョブをより早く完了させることが可能となる。

請求項４に記載のジョブ実行管理システムの場合、時限に関係しないフリーのジョブの実行を見合わせることで、時限に関係する重要なジョブの確実な実行を担保することが可能となる。

請求項５に記載のジョブ実行管理システムによれば、各処理フローの時限までの余裕時間を一定の範囲内に収めることが可能となる。

請求項６に記載のジョブ実行管理システムの場合、一旦、割当予定情報が生成され、これに従ってジョブの実行が各サーバに指令された後であっても、実際の処理状況を勘案して割当予定情報を柔軟に修正する機能を備えているため、特定のサーバについて障害等が発生したとしても、時限付のジョブを時限内に完了させることが可能となる。

請求項７に記載のジョブ実行管理システムによれば、複数のサーバを仮想サーバによって構成した場合において、各仮想サーバの現在の余裕リソース量を算出した結果、物理サーバの余裕リソース量を上回る余裕リソース量の仮想サーバがあるときには、これを物理サーバの余裕リソース量まで減殺する補正が施される仕組みを備えている。このため、各仮想サーバに物理サーバの物理的なリソース量を超えてリソースを配分した場合であっても、各仮想サーバにおいて物理的なリソース量を超えた状態でジョブが実行されることを有効に回避することが可能となる。

図１は、この発明に係るジョブ実行管理システム10の全体構成を示すものであり、管理サーバ12と、第１の物理サーバ14と、第２の物理サーバ16を備えている。
管理サーバ12と第１の物理サーバ14間、及び管理サーバ12と第２の物理サーバ16間は、通信ネットワークを介して接続されている。
物理サーバの数は２つに限定されるものではなく、３つ以上の物理サーバを管理サーバ12に接続することも当然に可能である。

第１の物理サーバ14には、OS（以下「物理OS-A」）がセットアップされており、この物理OS-A上にエージェントプログラム（以下「物理エージェント18」）がインストールされている。
また、この物理エージェント18によって、物理OS-A上には３つの仮想OS（仮想OS-A1、仮想OS-A2、仮想OS-A3）が起動されている。この結果、物理サーバ14上には、仮想OS-A1、仮想OS-A2、仮想OS-A3に対応した３つの仮想サーバが存在している。

第２の物理サーバ16にも、OS（以下「物理OS-B」）がセットアップされており、この物理OS-B上にも物理エージェント18がインストールされている。
また、この物理エージェント18によって、物理OS-B上には３つの仮想OS（仮想OS-B1、仮想OS-B2、仮想OS-B3）が起動されている。この結果、第２の物理サーバ16上には、仮想OS-B1、仮想OS-B2、仮想OS-B3に対応した３つの仮想サーバが存在している。

仮想OSの数は３に限定されるものではなく、物理エージェント18は物理サーバ上に４以上の仮想OSを起動させることも当然に可能である。
各仮想OSは、物理OSと同様、OSとしての基本機能を発揮するものであるが、物理OSと仮想OSとは必ずしも同種のOSである必要はない。
また、各仮想OSには、仮想OS用のエージェントプログラム（以下「仮想エージェント22」）がそれぞれインストールされている。
さらに、各仮想OS上には、業務処理を実行するために必要な各種アプリケーションプログラムがインストールされている（図示省略）。

管理サーバ12は、仮想エージェント22に対して必要なジョブの実行を個別に指令することができる。
また、物理エージェント18や各仮想エージェント22は、管理サーバ12に対して、各種リソースの利用状況（利用リソース量／実測値）や処理の結果等のデータを随時通知する。

図２は、管理サーバ12の機能構成を示すブロック図であり、処理フロー生成部30と、リソース利用状況算出部31と、ジョブ割当部32と、実行結果受信部34と、ジョブ割当情報記憶部38と、リソース配分情報記憶部40と、ジョブ情報記憶部42とを備えている。

上記処理フロー生成部30、リソース利用状況算出部31、ジョブ割当部32及び実行結果受信部34は、管理サーバ12のCPUが、専用のアプリケーションプログラムに従って必要な処理を実行することにより、実現される。
また、上記ジョブ割当情報記憶部38、リソース配分情報記憶部40及びジョブ情報記憶部42は、管理サーバ12の外部記憶装置内に設けられている。

リソース配分情報記憶部40には、図３に示すように、各物理サーバが保有しているリソースの各仮想サーバに対する配分情報が予め規定されている。
例えば、物理OS-AのCPUリソースの利用可能量を、所定の指標OSのCPUリソースとの対比で1000と表現した場合に、配下の仮想OS-A1、仮想OS-A2、仮想OS-A3に対して、それぞれ400ずつ割り当てられている。
また、物理OS-BのCPUリソースの利用可能量を、上記指標OSとの対比で1200とした場合に、配下の仮想OS-B及び仮想OS-B2に対して500が割り当てられると共に、仮想OS-B3に対して400が割り当てられている。
「CPUリソース」とは、例えば単位時間当たりの処理能力を意味している。

CPU以外のメモリ及びI/Oについても同様に、物理OSが保有しているリソースが配下の各仮想OSにそれぞれ割り当てられている。
この場合も、各リソースは上記指標OSの保有リソースを1000とした場合に、それとの対比で求められたスコアが各物理サーバの保有リソースとして表現されると共に、各仮想サーバへの配分リソース量として表現されている。
「メモリリソース」とは、物理サーバのメモリの容量を意味している。
また「I/Oリソース」とは、例えば物理サーバのディスクのI/Oスピードを意味している。

各仮想サーバが、各自に割り当てられた各種リソースを同時に最大限まで使い切る状況は希であるため、上記のように物理サーバの保有リソース量よりもトータルで大きくなるリソース量が、予め各仮想サーバに割り当てられている。この結果、資源の有効活用や処理の効率化が実現される。

ジョブ情報記憶部42には、実行対象ジョブの属性等が格納されている。
図４は、ジョブ情報記憶部42に格納されたデータの一例を示すものであり、各ジョブ毎に前提ジョブ、実行可能サーバ、CPU、メモリ、I/O、最大処理時間、平均処理時間、実行状況、時限のデータ項目が設定されている。

ここで「前提ジョブ」とは、当該ジョブの実行に先立って完了していなければならないジョブを特定するデータ項目である。
また「時限」とは、当該ジョブが完了すべき時間的な限界（デッドライン）を意味している。

また「実行可能サーバ」とは、当該ジョブを実行するためのアプリケーションプログラムがインストールされている仮想サーバを意味している。
例えば、JOB-Xには実行可能サーバとして仮想OS-A1、仮想OS-A2、仮想OS-A3、仮想OS-B1、仮想OS-B2、仮想OS-B3が規定されている。

また、各実行可能サーバ毎に、CPU、メモリ、I/Oの各リソースに関する要求リソース量と、最大処理時間、平均処理時間が格納されている。
例えば、JOB-Xを仮想OS-A1の仮想サーバで実行する場合には、CPU：100、メモリ：100、I/O：100のリソースを要し、最大処理時間：200秒、平均処理時間：100秒であるのに対し、同じJOB-Xを仮想OS-B2の仮想サーバで実行する場合には、CPU：150、メモリ：150、I/O：150のリソースを要し、最大処理時間：300秒、平均処理時間：150秒であることが規定されている。
これらのデータは、過去の実績に基づいて設定される。この際、特定の仮想サーバにおける実績から、他の仮想サーバでの利用リソースを推定してもよい。

「実行状況」は、当該ジョブの実行状況を表す値（「実行中」、「正常終了」、「異常終了」、「実行待ち」）が格納されるデータ項目である。
このデータ項目の値は、実行結果受信部34及びジョブ割当部32によって随時更新される。すなわち、最初は各ジョブに「実行待ち」のステータスが設定されているが、ジョブ割当部32が所定の仮想サーバにジョブを割り当てた時点で、ジョブ割当部32によって「実行中」のステータスが設定される。

そして、仮想OSの仮想エージェント22から実行結果（「正常終了」または「異常終了」）が送信された時点で、実行結果受信部34が当該実行結果に対応したステータスを設定する。
図５は、仮想エージェント22から送信された実行結果データを示しており、受信日時、ジョブ名、サーバ名、実行結果のデータ項目を少なくとも備えている。

ジョブ情報のデータ項目は上記に限定されるものではなく、例えば、CPUやメモリ、I/Oの各要求リソース量についても、最大値と平均値とに分けて細かく設定しておくことができる。
またリソースの種類として、CPU、メモリ、I/Oの他に、ネットワークリソース（ネットワークの利用状況）等を加えることもできる。

ジョブ割当情報記憶部38には、ジョブ割当部32によって関連付けられた各ジョブと仮想サーバとの対応関係が格納される。
図６は、ジョブ割当情報記憶部38に格納されたジョブ割当情報を示しており、投入日時、ジョブ名、サーバ名のデータ項目を少なくとも備えている。

つぎに、図７のフローチャートに従い、処理フローの生成に係る処理手順を説明する。
まず、ジョブ情報記憶部42内に図８(a)に示すジョブ情報が格納されている場合に、処理フロー生成部30は「6:00」の時限が設定されたJOB-5を取り出す（Ｓ10）。
なお、説明を簡略化するため、ここではメモリ及びI/Oの要求リソース量については記載を省略してある。また、各ジョブのCPUの要求リソース量についても、実行可能サーバ別に異なるものではなく、全ての実行可能サーバについて共通であるものとして論を進める。

つぎに、処理フロー生成部30はジョブ情報記憶部42を参照し、上記時限付ジョブであるJOB-5に前提ジョブが登録されているか否かをチェックする（Ｓ12）。
そして、JOB-5にJOB-3及びJOB-4の前提ジョブがあることを認識した処理フロー生成部30は、このJOB-3及びJOB-4をJOB-5の前に並列配置させる（Ｓ14）。

つぎに、処理フロー生成部30はジョブ情報記憶部42を参照し、JOB-3及びJOB-4に前提ジョブが登録されているか否かをチェックする（Ｓ16）。
そして、JOB-3及びJOB-4にJOB-1の前提ジョブがあることを認識した処理フロー生成部30は、このJOB-1をJOB-3及びJOB-4の前に配置させる（Ｓ18）。

つぎに、処理フロー生成部30はジョブ情報記憶部42を参照し、JOB-1に前提ジョブが登録されているか否かをチェックする（Ｓ20）。
そして、JOB-1が前提ジョブを有さない先頭ジョブであることを認識した処理フロー生成部30は、図８(b)に示すように、抽出した一連のジョブ名と、各ジョブ間の前後関係（処理順序）からなる処理フロー情報を生成し、ジョブ割当部32に渡す（Ｓ22）。
また、JOB-0及びJOB-2については、何れも他のジョブとは関連性を有さないフリーなジョブと認定され、その旨の情報（フリージョブ情報）がジョブ割当部32に出力される。

図示は省略したが、ジョブ情報記憶部42内に複数の期限付ジョブが存在している場合、処理フロー生成部30は上記の処理を繰り返し、複数の処理フローを生成する。

つぎに、図９のフローチャートに従い、ジョブの割当て及び実行に係る処理手順を説明する。
まず、リソース利用状況算出部31により、リソース利用状況データが生成され、メモリ上に格納される（Ｓ30）。
図１０は、リソース利用状況データの一例を示すものであり、物理OS及びその配下の仮想OS毎に、時間、CPU（total）、CPU（used）、CPU（capa）、メモリ（total）、メモリ（used）、メモリ（capa）、I/O（total）、I/O（used）、I/O（capa）のデータ項目が少なくとも設定されている。

「時間」のデータ項目には、時間経過を示す値が設定されている。すなわち、時間が「０」は現時点を表しており、「＋１」は１分後を、また「＋２」は２分後を表している。
ただし、時間間隔は１分単位に限られるものではなく、例えば「＋１＝５分後」、「＋２＝１０分後」、「＋３＝１５分後」のように、５分単位とすることもできる。

CPU（total）のデータ項目には、物理サーバの場合であれば当該物理サーバのCPUリソースの総計値（保有リソース量）が記述され、仮想サーバの場合であれば当該仮想サーバに配分されたリソースの値（割当リソース量）が記述される。このCPU（total）の値は、リソース配分情報記憶部40から取得される。

また、CPU（used）のデータ項目には、各サーバにおいて現に利用されているCPUリソースの量（現在の利用リソース量）、あるいは将来利用されるCPUリソースの量（将来の利用リソース量）を示す数値が記述される。
すなわち、時間「０」のCPU（used）に関しては、物理エージェント18や仮想エージェント22から送信された利用リソース量の実測値が充填される。
これに対し、時間「＋１」や「＋２」等のCPU（used）に関しては、リソース利用状況算出部30が、ジョブ割当情報記憶部38に格納された割当て済みの各ジョブについて、ジョブ情報記憶部42に格納されたそれぞれの要求リソース量及び平均処理時間を適用することによって算出した将来における推定値が充填される。例えば、現時点においてある仮想サーバに要求リソース量が「100」のジョブが３つ割り当てられており、その結果、時間「０」のCPU（used）が300となっていたとしても、その中の１つのジョブが時間「＋２」までに終了するということであれば、「＋２」のCPU（used）として「200」が充填される。

CPU（capa）のデータ項目には、各サーバにおけるCPUリソースの余裕量（余裕リソース量）を示す数値が記述される。
このCPU（capa）は、物理OSについては単純に「CPU（total）−CPU（used）」によって求められる。仮想OSのCPU（capa）についても、基本的には「CPU（total）−CPU（used）」によって求められるが、これは暫定的な値であり、物理OSのCPU（capa）との兼ね合いで、補正が施される場合がある。

例えば、図１１(a)に示すように、ある時間帯における物理OS-AのCPU（capa）が300であり、仮想OS-A1のCPU（capa）が200、仮想OS-A2のCPU（capa）が100、仮想OS-A3のCPU（capa）が200であった場合、各仮想OSのCPU（capa）は何れも物理OS-AのCPU（capa）を下回っているため、補正なしでそれぞれのCPU（capa）と認定される。

これに対し、図１１(b)に示すように、仮想OS-A3のCPU（total）が400であり、CPU（used）が50であった場合、「CPU（total）−CPU（used）」によって求められるCPU（capa）は350となるが、これは物理OS-A1のCPU（capa）を50ほど上回ってしまうため、300に減殺する補正が施される。

メモリ及びI/Oに係る各データ項目についても、上記したCPUに係るデータ項目の説明が当てはまる。
すなわち、メモリ（total）のデータ項目には、物理サーバの場合であれば当該物理サーバのメモリの総計値（保有リソース量）が記述され、仮想サーバの場合であれば当該仮想サーバに割り当てられたメモリの配分値（割当リソース量）が記述される。このメモリ（total）の値は、リソース配分情報記憶部40から取得される。

また、メモリ（used）のデータ項目には、各サーバにおいて現に利用されているメモリの量（現在の利用リソース量／実測値）、あるいは将来利用されるメモリのリソース量（将来の利用リソース量／推定値）を示す数値が記述される。

また、メモリ（capa）のデータ項目には、各サーバにおけるメモリの余裕量（余裕リソース量）を示す数値が記述される。
このメモリ（capa）は、基本的には「メモリ（total）−メモリ（used）」によって求められるが、仮想OSのメモリ（capa）については、物理OSのメモリ（capa）を上限とするというルールが適用されるため、これを超える分については減殺される。

I/O（total）のデータ項目には、物理サーバの場合であれば当該物理サーバのI/Oリソースの総計値（保有リソース量）が記述され、仮想サーバの場合であれば当該仮想サーバに配分されたI/Oリソースの値（割当リソース量）が記述される。このI/O（total）の値は、リソース配分情報記憶部40から取得される。

また、I/O（used）のデータ項目には、各サーバにおいて現に利用されているI/Oリソースの量（現在の利用リソース量／実測値）、あるいは将来利用されるI/Oのリソース量（将来の利用リソース量／推定値）を示す数値が記述される。

さらに、I/O（capa）のデータ項目には、各サーバにおけるI/Oリソースの余裕量（余裕リソース量）を示す数値が記述される。
このI/O（capa）も、基本的には「I/O（total）−I/O（used）」によって求められるが、仮想OSのI/O（capa）については、物理OSのI/O（capa）を上限とするというルールが適用されるため、これを超える分については減殺される。

つぎに、ジョブ割当部32が上記の処理フロー情報及びリソース利用状況データを参照することにより、ジョブ割当予定情報を生成する（Ｓ32）。
このためにジョブ割当部32は、図１２(a)に示すように、まず、何れか一の仮想サーバ（図においては仮想OS-A1）の実行スケジュールに対して、処理フローに含まれる全ジョブを順番通りに配列させる。この際、処理フローにおいてJOB-1の後で分岐するJOB-3及びJOB-4については、実行スケジュール上の同一時間帯に、並列配置される。
ここで「実行スケジュール」とは、当該仮想サーバにおける処理の時間軸（時系列）を意味している。

図１２(a)において、仮想OS-A1の存在を示すブロックは、その高さで当該仮想サーバのCPU(capa)を表している。
また、各ジョブの存在を示すブロックは、その横幅で平均処理時間の長短を表現すると共に、高さでCPUの要求リソース量の多寡を表現している。
なお、仮想サーバのCPU(capa)は、時間の経過によって変化し得ることは上記の通りであるが、ここでは説明の便宜上、CPU(capa)が400を一定時間キープするケースを想定している。

図より明らかなように、処理フローに含まれる各ジョブを実行スケジュール上に処理フローのまま並べていくと、JOB-5は時限である「6:00」の５分前に処理が完了することがわかる。
ただし、実行スケジュール上の10〜15分の時間帯においては、JOB-3とJOB-4の要求リソース量の和が仮想OS-A1の余裕リソース量を超えているため、ジョブ割当部32は、何れか一方のジョブ（例えばJOB-4）を他の仮想サーバ（例えば仮想OS-A2）への振り分け対象と認定する。

以上を踏まえた上で、図１２(b)に示すように、ジョブ割当部32は最終的なジョブの実行計画を導出する。
ここでは、仮想OS-A1にJOB-1、JOB-3及びJOB-5が順番に割り当てられると共に、仮想OS-A2にJOB-2、JOB-4及びJOB-0が割り当てられている。

JOB-4については、JOB-1が完了していることが処理開始の前提条件となるため、JOB-4は仮想OS-A1においてJOB-1が完了するタイミング（基準時点０から10分後の時点）で仮想OS-A2に投入される。
この例では、フリーのJOB-2が仮想OS-A2の実行スケジュールの先頭（０の時点）に配置されているが、JOB-2をJOB-5の後ろに割り当てることもできる。

つぎにジョブ割当部32は、上記のジョブの実行計画を反映させたジョブの割当予定情報を生成する。
図１３はその一例を示すものであり、各割当予定情報は、ジョブ名と、サーバ名と、投入時点のデータ項目を少なくとも備えている。投入時点の代わりに、処理開始時刻（5:45分や6:00等）でジョブの処理開始時期を指定することもできる。

ジョブ割当部32は、上記ジョブの割当予定情報に従って、対応の仮想サーバの仮想エージェント22に対応ジョブの実行を指令する（Ｓ34）と同時に、ジョブ割当情報記憶部38にジョブ割当情報を格納していく（Ｓ36）。
そして、仮想サーバからジョブの実行結果データが送信されると（Ｓ38）、これに基づき実行結果受信部34がジョブ情報の「実行状況」を更新する（Ｓ40）。

必要なジョブの全てが実行されるまでの間、リソース利用状況算出部30によってリソース利用状況データが更新され（Ｓ44）、Ｓ32〜Ｓ40の処理が繰り返される（Ｓ42）。
このリソース利用状況データは、各リソースの余裕リソース量（capa）を最新のものにするため、少なくともジョブの実行開始時（投入時）とジョブの実行完了時に更新される。また、この更新に際し、各サーバにおける利用リソース量（used）が測定される。

ジョブ割当部32は定期的にジョブ情報記憶部42に格納された各ジョブの実行状況をチェックし、各ジョブの処理が予定よりも遅れている場合には、ジョブの割当予定情報を適宜修正する。
例えば、図１３の割当予定情報に基づき、仮想OS-A2にJOB-2の実行を指令したところ、何らかの理由で当該ジョブの完了（正常終了）が予定時刻（５分時点）よりも遅れている場合、ジョブ割当部32は仮想OS-A2に遅延の可能性を認定し、後続のJOB-4を他の仮想サーバ（例えば仮想OSA-3）に割当てることが該当する。
JOB-4はJOB-5の前提ジョブであり、その遅延は時限の超過に繋がることから、JOB-4の確実な実行を担保する必要性が生じるためである。

なお、処理フロー生成部30によって２つの処理フローが生成された場合において、ジョブ割当部32が各処理フローについて別個独立にジョブの割当予定情報を生成した結果、一方の処理フローの時限付ジョブが時限の60分前に完了予定であり、他方の処理フローの時限付ジョブが時限のぎりぎり５分前に完了予定となるようなケースも想定される。

このような場合にジョブ割当部32は、時間的余裕の少ない処理フローに属するジョブの処理を優先するように各処理フローの割当予定情報を生成し直すことにより、両処理フローの余裕時間（完了予定時刻と時限との間の時間間隔）の差を予め設定された範囲内（例えば10分以内）に近づける時間調整を行うこともできる。
具体的には、処理を早めたい処理フローに属する各ジョブを各仮想サーバの比較的早い時間帯に配置させると共に、処理を遅くしたい処理フローに属する各ジョブを各仮想サーバの比較的遅い時間帯に配置させることが該当する。

図１４は他の割当予定情報の生成例を示すものであり、まず図１４(a)のジョブ情報がジョブ情報記憶部42内に格納されている場合に、上記と同様の手順に従い、図１４(b)の処理フローが生成される。
図示の通り、この処理フロー自体は図８(b)の処理フローと等しいが、各ジョブの属性が異なるため、図１４(c)に示すように、各仮想サーバへの割当てに差異が生じる。

まず、JOB-0のCPUリソース要求量が「100」と比較的少ないため、仮想OS-A1の０〜10分の時間帯に、JOB-1と並行する形で配置されている。
同様に、JOB-2のCPUリソース要求量も「100」と比較的少ないため、仮想OS-A2の０〜５分の時間帯に配置されている。

ここで、フリーなジョブであるJOB-0を敢えてJOB-1と同じ時間帯に同じ仮想OS-A1に配置させた理由は、ジョブ全体の完了時間をできるだけ早めるためである。
これに対し、時限付ジョブの完了時間を可能な限り早めることを優先する場合には、当然ながらJOB-0はJOB-5の後か、JOB-4の後に配置されることになる。
このようなジョブ割当部32の処理内容は、予め設定されたポリシーの切り替えによって制御される（以下同様）。

図１５は他の割当予定情報の生成例を示すものであり、まず図１５(a)のジョブ情報がジョブ情報記憶部42内に格納されている場合に、上記と同様の手順に従い、図１５(b)の処理フローが生成される。
図示の通り、この処理フロー自体は図８(b)及び図１４(b)の処理フローと等しいが、各ジョブの属性が異なるため、図１５(c)に示すように、仮想サーバへの割当てに差異が生じる。

まず、JOB-0のCPUリソース要求量が「100」と比較的少ないため、図１４(c)の場合と同様、仮想OS-A1の０〜10分の時間帯に配置することも考えられる。しかしながら、JOB-4のCPUリソース要求量が「400」と比較的多く、また仮想OS-A1は仮想OS-A2と同じ物理サーバ14上に設けられているため、５分以降の時間帯において物理サーバ上のリソースが不足する可能性が生じる。
このため、処理の効率性を考慮して、JOB-0は仮想OS-A2の10〜20分の時間帯に配置されている。

従来は、各ジョブの処理フローを専門のスタッフが策定することが前提であり、あまりジョブの粒度を細かくすると処理フローの設計やサーバへの割当が煩雑化するという問題が生じるため、リソースの有効利用に資することはわかっていても、ジョブの細分化はあまり進まなかった。
これに対し、このシステム10によれば上記のように、ジョブの属性として「要求リソース量」、「平均処理時間」及び必要な「先行ジョブ」と「時限」を登録さえしておけば、後は処理フロー生成部30が自動的に処理フローを生成し、ジョブ割当部32が各ジョブを各仮想サーバにおける時間帯毎の余裕リソース量を見計らって最適な仮想サーバに割り当てる処理を実行してくれるため、個々のジョブを可能な限り細分化しても、人間の手に負えなくなるという問題を回避することができる。

ジョブの細分化を行うに際しては、例えば各ジョブのリソース利用量（実績値）を時間単位で算出し、時間帯によってリソース利用量に大きな変動が生じている場合には、該当の時間帯に行われている処理を別のジョブとして切り出すという手法が利用できる。

上記においては、説明を単純化するためCPUリソースに基づいて各ジョブの割当予定情報を生成する例を説明したが、メモリやI/Oのリソースに基づいて割当予定情報を生成することもできるし、全リソースの合計値や平均値に基づいて割当予定情報を生成することもできる。

各仮想サーバにジョブを割り当てる際に、当該仮想サーバの余裕リソース量のぎりぎりまでジョブを割り当てるのではなく、処理の効率性を確保するために、予め決められたマージンを残して割り当てるように運用することもできる。
例えば、「ジョブの割当ては、各仮想サーバの余裕リソース量の90％までとする」というポリシーが設定されており、仮想OS-A1の余裕リソース量が400であった場合、ジョブ割当部32は仮想OS-A1に対して、各ジョブの要求リソース量の合計値が360を超えるような複数のジョブを、同一時間帯に重複配置することができなくなる。

上記においては、ジョブをそれぞれの平均処理時間に基づいて仮想サーバに割り当てる例を説明したが、時限付ジョブの時限内完了を最優先するために、最大処理時間に基づいて割り当てるようにしてもよい。

この発明は、上記のように仮想サーバ間におけるジョブの割当てに限定されるものではなく、複数の物理サーバ間におけるジョブの割当て、あるいは物理サーバ及び仮想サーバ間におけるジョブの割当てに際しても適用することが可能である。

この発明に係るジョブ実行管理システムの全体構成を示す模式図である。管理サーバの機能構成を示すブロック図である。リソース配分情報の一例を示す図である。ジョブ情報の一例を示す図である。実行結果データの一例を示す図である。ジョブ割当情報の一例を示す図である。処理フローの生成に係る処理手順を示すフローチャートである。処理フローの生成過程を示す図である。ジョブの割当て及び実行に係る処理手順を示すフローチャートである。リソース利用状況データの一例を示す図である。物理サーバのCPU（capa）と仮想サーバのCPU（capa）との関係を示す図である。ジョブの割当予定情報生成の過程を示す図である。ジョブの割当予定情報の一例を示す図である。ジョブの割当予定情報生成に係る他の例を示す図である。ジョブの割当予定情報生成に係る他の例を示す図である。

10 ジョブ実行管理システム
12 管理サーバ
14 第１の物理サーバ
16 第２の物理サーバ
18 物理エージェント
22 仮想エージェント
30 処理フロー生成部
31 リソース利用状況算出部
32 ジョブ割当部
34 実行結果受信部
38 ジョブ割当情報記憶部
40 リソース配分情報記憶部
42 ジョブ情報記憶部

Claims

ジョブを処理するための複数のサーバと、各サーバと接続された管理サーバとを備えたジョブ実行管理システムであって、
上記管理サーバは、
実行対象となる複数のジョブ毎に、各ジョブの処理時間と、前提ジョブが存在する場合にはその前提ジョブの特定情報と、時限が存在する場合には当該時限付ジョブの時限を格納しておくジョブ情報記憶手段と、
上記ジョブ情報記憶手段を参照し、複数のジョブを実行順に整列させた処理フローを生成する処理フロー生成手段と、
少なくとも上記処理フローで規定された各ジョブの処理の順番及び時限付ジョブの時限に従い、上記ジョブ情報記憶部に格納された各ジョブについて、処理サーバと投入時刻を特定した割当予定情報を生成すると共に、この割当予定情報に従って、各ジョブの実行を各サーバに指令するジョブ割当手段とを備え、
上記処理フロー生成手段は、
(1) 上記ジョブ情報記憶手段を参照し、時限が設定されている時限付ジョブを抽出する処理と、
(2) 当該時限付ジョブに前提ジョブが設定されている場合には、当該前提ジョブを時限付ジョブの前に配置させる処理と、
(3) 上記前提ジョブに他の前提ジョブが設定されている場合には、他の前提ジョブを当該前提ジョブの前に配置させる処理を実行し、
さらに(3)の処理を、前提ジョブの存しない先頭ジョブに到達するまで繰り返すことにより、上記の処理フローを生成することを特徴とするジョブ実行管理システム。
上記ジョブ記憶手段には、各ジョブの実行に必要な特定種類のリソースの量を示す要求リソース量が格納されており、
上記管理サーバは、各サーバが保有する特定種類のリソースの量である保有リソース量を格納しておくリソース配分情報記憶手段と、
各サーバの現在の余裕リソース量を算出すると共に、各ジョブの要求リソース量と処理時間を参照することにより、各サーバの将来の余裕リソース量を所定の時間間隔毎に算出するリソース利用状況算出手段とを備え、
上記ジョブ割当手段は、各ジョブの要求リソース量と、処理時間と、各サーバの現在及び将来の余裕リソース量を参照することにより、各ジョブの処理サーバ及び投入時刻を特定することを特徴とする請求項１に記載のジョブ実行管理システム。
上記の実行対象ジョブが、上記処理フローに属するジョブと、当該処理フローに属さないフリーのジョブとに分かれる場合において、
上記ジョブ割当手段は、上記処理フローに含まれる各ジョブの処理を優先して各サーバの余裕のある時間帯に割り当て、その後にフリーのジョブを各サーバの余裕のある時間帯に割り当てることを特徴とする請求項２に記載のジョブ実行管理システム。
請求項３に記載のジョブ実行管理システムにおいて、フリーのジョブのすべてについて各サーバの余裕のある時間帯を割り当てることができない場合に、上記ジョブ割当手段は、フリーのジョブの少なくとも一部についてはサーバへの割当を見合わせることを特徴とするジョブ実行管理システム。
上記ジョブ割当手段は、上記処理フロー生成手段によって生成された処理フローが複数存在し、各処理フローに属する時限付ジョブの完了予定時刻から時限までの余裕時間に所定範囲以上の差が存在する場合に、少なくとも一の処理フローに属するジョブの少なくとも一部を同一サーバまたは他のサーバにおける余裕のある時間帯に再配置することにより、上記余裕時間の差を所定範囲内に縮める時間調整を実行することを特徴とする請求項２〜４の何れかに記載のジョブ実行管理システム。
上記ジョブ割当手段は、各サーバから送信されたジョブの実行結果に基づいて、予定よりも完了が遅れているジョブが存在するものと判定した場合には、当該ジョブの後ろの時間帯に配置された上記処理フローを構成するジョブを、他のサーバの余裕のある時間帯に配置させた割当予定情報を再生成し、以後はこの割当予定情報に従って各ジョブの実行を各サーバに指令することを特徴とする請求項２〜５の何れかに記載のジョブ実行管理システム。
上記複数のサーバは、少なくとも一つの物理サーバ上に構築された仮想化環境に複数のOSを導入することによって形成された仮想サーバよりなり、
上記管理サーバは、上記物理サーバが保有する特定種類のリソースの量である保有リソース量と、この物理サーバの保有リソース量の中から上記の各仮想サーバに割り当てた割当リソース量を登録しておくリソース配分情報記憶手段を備え、
上記リソース利用状況算出手段は、算出した仮想サーバの現在の余裕リソース量の中で、上記物理サーバの現在の余裕リソース量を超えているものがある場合には、当該仮想サーバの余裕リソース量を物理サーバの余裕リソース量まで減殺する処理を実行することを特徴とする請求項２〜６の何れかに記載のジョブ実行管理システム。