JP4532423B2 - サーバシステム - Google Patents

Description

本発明は、複数サーバを含む情報システムにおけるジョブ管理技術に関する。

サーバ間に共用できるアレイディスク装置（以下、共用ディスク）上にデータを配置した形態のシステムがある。このようなシステムでは、複数のサーバが、それぞれのサーバで実行される業務（以下、ジョブ）で使用される情報を共用ディスクによって共有する。

図１にそのような従来のシステム構成の例を示す。従来のシステムでは、図１のように、例えば、サーバＡで実行されるジョブは当該データを共用ディスクに書き出す。一方、サーバＢで実行されるジョブは、当該データを共用ディスクから読み込む。従来は、このような依存関係のあるジョブの実行順をルール（スケジュール）として設定し、運用している。

しかし、このようなシステムは、ジョブで使用されるデータのみに着目し、ジョブの制御については着目していない。また、複数のサーバで業務運用を行う場合には、各サーバにジョブのスケジュール情報が配備され、各サーバでジョブが運用されると共に、すべてのサーバのジョブスケジュールを一括管理する管理サーバが用意されていた。そして、管理サーバが、他のサーバのジョブを集中的にスケジュールしていた。このような形態では、ジョブを一括管理するサーバが停止すると、データを互いに授受し、連携するサーバ間でジョブのスケジュールを実施できず、業務の運用に支障をきたすことがあった。

このように、ジョブのスケジュール情報をある特定のサーバに一括管理する技術は従来から存在する（Systemwalker（登録商標）など）。これにより、複数のサーバで運用されるバッチ（業務）が構築されていた。しかし、ジョブのスケジュール情報を一括管理するサーバが何らかの理由で停止すると、複数のサーバで連携して運用する業務は停止していた。

また、ジョブのスケジュール情報は、管理サーバだけでなく、ジョブを実行するサーバにも存在することがある。このため、システムのバックアップ／リストアなどの保守では、これらすべてのサーバに存在するジョブのスケジュール情報をバックアップ／リストアする必要があった。
特公平７−１０１４０７号公報 特開昭５５−０３７６２６号公報 特許第３５１６０４９号号公報 特開２００１−２８２５５１号公報

本発明の目的は、複数サーバが連携するシステムにおいて、ジョブのスケジュール管理の信頼性およびシステムの安定性を向上させることにある。

本発明は前記課題を解決するために、以下の手段を採用した。すなわち、本発明は、第１サーバまたは第２サーバとして機能するサーバを含む複数のサーバと前記複数のサーバに共用される共用記憶装置とを備え、前記共用記憶装置は、ジョブの実行要求を登録してジョブの実行順序を制御するとともにジョブの実行を完了するまで前記ジョブの状態を記
憶するジョブキュー記憶部と、ジョブの実行を要求する要求サーバごとに設けられ、ジョブの実行要求の前記ジョブキュー記憶部への登録を依頼する、そのような登録依頼情報が書き込まれるジョブキュー登録依頼記憶部と、ジョブを実行する実行サーバごとに設けられ、前記実行サーバと前記実行サーバに割り当てられたジョブの実行要求との関係を記憶するジョブ割り当て記憶部と、を有し、前記第１サーバは、前記ジョブキュー登録依頼記憶部に書き込まれた登録依頼情報にしたがってジョブの実行要求を前記ジョブキュー記憶部に登録するジョブキュー登録処理部を有し、前記第２サーバは、前記ジョブキュー記憶部に登録されたジョブの実行要求を前記実行サーバに割り当てて、前記実行サーバと前記実行サーバに割り当てられたジョブの実行要求との関係を前記ジョブ割り当て記憶部に書き込む割り当て処理部を有し、前記実行サーバは、当該実行サーバに対して設けられたジョブ割り当て記憶部からジョブの実行要求を取得して割り当てられたジョブを実行する実行部を有する、サーバシステムである。

本発明によれば、共用記憶装置は、ジョブの実行要求を登録してジョブの実行順序を制御するとともにジョブの実行を完了するまで前記ジョブの状態を記憶し、第１サーバは、前記ジョブキュー登録依頼記憶部に書き込まれた登録依頼情報にしたがってジョブの実行要求を前記ジョブキュー記憶部に登録し、第２サーバは、前記ジョブキュー記憶部に登録されたジョブの実行要求を前記実行サーバに割り当て、実行サーバは、割り当てられたジョブを実行する。したがって、共用記憶装置を介して、複数のサーバ実行されるジョブを複数のサーバによって管理するとともに、複数のサーバでジョブを実行することができる。

また、本発明は、コンピュータその他の装置、機械等が上記いずれかの処理を実行する方法であってもよい。また、本発明は、コンピュータその他の装置、機械等に、上記いずれかの処理を実行させるコンピュータ実行可能なプログラムであってもよい。また、本発明は、そのようなプログラムをコンピュータその他の装置、機械等が読み取り可能な記録媒体に記録したものでもよい。

本発明によれば、複数サーバが連携するシステムにおいて、ジョブのスケジュール管理の信頼性およびシステムの安定性を向上することができる。

以下、図面を参照して本発明を実施するための最良の形態（以下、実施形態という）に係る情報システムについて説明する。以下の実施形態の構成は例示であり、本発明は実施形態の構成に限定されない。

＜発明の骨子＞
本情報システムは、複数のサーバと複数のサーバに共用される共用ディスクを有する。この情報システムでは、共用ディスク上にジョブのキュー情報（以下、ジョブキューともいう）が配置される。各々のサーバには、ジョブをスケジュールする（キュー情報にジョブを登録する）機能とジョブを実行する機能とが設けられる。ジョブをスケジュールする機能を各々のサーバで行うことで、特定のサーバにジョブをスケジュールする機能を集中させず、共用ディスクを中心とした分散系のジョブが実行される。

ジョブをスケジュールする機能は、ジョブの登録を依頼する登録依頼機能と、その依頼にしたがって、ジョブをキュー情報として登録するスケジュール管理機能に分かれる。複数のサーバが、登録依頼機能を有する。これらの複数のサーバから選択される単一のサーバ（スケジュール管理サーバという）がスケジュール管理機能を担当する。ただし、スケジュール管理機能を担当するスケジュール管理サーバが不測の事態により停止したと判断
される場合、所定の優先順位にしたがって、スケジュール管理サーバに代わってスケジュール管理機能を実行するサーバが決定される。

同様に、ジョブを実行する機能は、ジョブを実行する実行機能と、実行機能に対して実行すべきジョブを指定する実行管理機能に分かれる。複数のサーバが、実行機能を有する。これらの複数のサーバから選択される単一のサーバ（実行管理サーバという）が実行管理機能を担当する。ただし、実行管理機能を担当する実行管理サーバが不測の事態により停止したと判断される場合、所定の優先順位にしたがって、実行管理サーバに代わって実行管理機能を実行するサーバが決定される。

複数のサーバ間でどのような順に管理機能を担当するかを決定する優先度に関する情報は、共用ディスクに格納される。このようなスケジュール管理サーバに代わって管理機能を実行することができる複数のサーバは、他のサーバが持つ優先度を調べる。そして、各サーバは、自装置が持つ優先度と他サーバが持つ優先度とを比べて、自装置がジョブスケジュールを担当するか否かを判断する機能とを持つ。

各サーバは、自装置がジョブスケジューリングを担当すると判断すると、共用ディスクに格納されているスケジュールを参照して、スケジュール管理機能、すなわち、ジョブのスケジューリングを実行する。

＜システム構成＞
図２に、本情報システムのシステム構成を示す。図２のように、本情報システムは、複数のサーバ１−１から１−５等と、前記複数のサーバ１−１から１−５等に共用される共用ディスク２とを有する。以下、本実施形態で、これらのサーバ１−１から１−５等を総称する場合には、単にサーバ１という。

本情報システムでは、各サーバには、異なるＯＳ（オペレーティングシステム）を搭載することができる。各サーバは、搭載するＯＳごとにグループ分けされる。図２の例では、ＯＳ−Ａ ｇｒｐというグループには、ＯＳ−Ａを搭載した１台のサーバ１−１が所属している。

また、ＯＳ−Ｂ ｇｒｐというグループには、ＯＳ−Ｂを搭載したサーバ１−２、１−３が所属している。ただし、ＯＳ−Ｂ ｇｒｐというグループ中には、さらに、細分化されたＯＳ−Ｂ−ＤＢ ｇｒｐというグループが含まれている。ＯＳ−Ｂ−ＤＢ ｇｒｐは、ＯＳ−Ｂの制御下で、データベース機能を提供するグループであり、サーバ１−３が所属している。一方、ＯＳ−Ｂ−ＤＢ ｇｒｐ以外のＯＳ−Ｂ ｇｒｐグループは、データベース機能を有しないグループであり、サーバ１−２が所属している。このような細分化されたグループは、ＯＳ−Ｃ ｇｒｐとＯＳ−Ｃ−ＤＢ ｇｒｐについても同様である。

なお、ＯＳ−ＡからＯＳ−Ｃには、例えば、汎用大型計算機のＯＳ、Ｌｉｎｕｘのような無償公開されたＯＳ、Ｗｉｎｄｏｗｓ（登録商標）のような商用ＯＳ、その他ベンダーごとに異なる仕様で開発されたＯＳが含まれる。このようなＯＳによるグループ分けは、実行依頼されたジョブを各サーバに割り当てるときの条件（サーバ属性ともいう）として判断される。ジョブには、通常、特定のＯＳで機能するアプリケーションプログラムが指定されるからである。

また、図２のように、いずれかのサーバは、いずれかのサーバ属性の実行機能を有している。実行機能とは、ジョブを実行する機能である。また、サーバ１−１、１−２、および１−４は、スケジュール機能を有している。スケジュール機能は、ジョブスケジューラ製品からの実行依頼を受信し、あるいは、オペレータからのジョブの実行依頼を受け付け
、実行依頼を情報システムに要求する機能である。

さらに、本情報システムでは、スケジュール機能を有するサーバ（本発明の要求サーバに相当）のうち、いずれか１台がスケジュール管理機能を実行する。以下、スケジュール管理機能を実行しているサーバをスケジュール管理サーバ（本発明の第１サーバに相当）という。スケジュール管理サーバは、実行依頼を要求する他のサーバからの要求によるジョブの実行要求をジョブキューに登録する。

同様に、実行機能を有するサーバ（本発明の実行サーバに相当）のうち、いずれか１台が実行管理機能を実行する。以下、実行管理機能を実行しているサーバを実行管理サーバ（本発明の第２サーバに相当）という。実行管理サーバは、ジョブキューに登録されたジョブの情報にしたがって、該当するＯＳグループのサーバに、実行すべきジョブを指定する。

共用ディスクは、本情報システムを構成する複数のサーバからアクセスできる。複数サーバが共用ディスクにアクセスするためのインターフェースとしては、様々なものが提案されており、その構成は周知であるので、説明は省略する。そのようなインターフェースの例としては、ＦＣ−ＳＣＳＩ（Fibre Channel−Small Computer System Interface ）
を挙げることができる。

図３に、スケジュール管理サーバと、実行管理サーバと、それら以外の他のサーバと、共用ディスクとの関係を示す。図３の例では、サーバ１−１がスケジュール管理サーバとして機能し、サーバ１−５が実行管理サーバとして機能し、サーバ１−２がジョブの実行依頼をするスケジュール機能を有し、サーバ１−５が実行機能を有していると仮定している。また、共用ディスク２には、ジョブキュー等の管理情報を格納するジョブキュー区画が設けられている。

図４に、ジョブキュー区画の構造を示す。ジョブキュー区画は、ジョブキューを格納するジョブキュー情報域、ジョブキューへの登録依頼を格納するジョブキュー登録依頼情報域、実行すべきジョブのジョブキューからの取り出しを依頼するジョブキュー取り出し依頼情報域、スケジュール管理機能を実行することができる複数サーバ間の優先度を管理するスケジュール機能制御域、および実行管理機能を実行することができる複数サーバ間の優先度を格納する実行機能制御域を有している。

ここで、図３に基づいて、ジョブの実行依頼、ジョブキューへの登録、およびジョブキューに登録されたジョブのサーバへの割り当ての概要を説明する。例えば、スケジュール機能を有するサーバ１−２、１−３等は、ジョブスケジューラ製品からの実行依頼を受信し、あるいは、オペレータからのジョブの実行依頼を受け付け、ジョブの実行依頼を共用ディスクに書き込む。書き込み先は、ジョブキュー区画のジョブキュー登録依頼情報域である。

スケジュール管理機能を実行するサーバ１−１（現在のスケジュール管理サーバ）は、ジョブキュー登録依頼情報域を監視している。そして、ジョブキュー登録依頼情報域にジョブの実行依頼が書き込まれており、かつ、ジョブキュー情報域に空きエントリがある場合、サーバ１−１は、そのジョブの実行依頼を基にジョブ実行要求をジョブキュー情報域に登録する。

一方、実行管理機能を実行するサーバ１−５（現在の実行管理サーバ）は、ジョブキュー情報域を監視している。そして、ジョブキュー情報域に実行待ち（未実行）のジョブがあり、かつ、実行機能を有するサーバ１−２等で、そのジョブで指定されたＯＳグループ
に所属するものが、ジョブの取り出し要求をしている場合、サーバ１−５は、該当するジョブをそのサーバ１−２等に引き渡す。このようにして、ジョブの内容を引き渡されたサーバ１−２等がそれぞれのジョブを実行する。なお、ジョブの取り出し要求は、実行機能を有するそれぞれのサーバによりジョブキュー区画のジョブキュー取出し依頼情報域に書き込まれている。

さらに、スケジュール機能を有するサーバ１−２等は、現在スケジュール管理機能を実行しているサーバ１−１を監視している。そして、サーバ１−１等が不測の事態によって停止していると推定される場合、スケジュール機能制御域の優先度にしたがって、サーバ１−２等のうち最も優先度の高いものがスケジュール管理機能を実行するようになる。このとき、サーバ１−１は、スケジュール管理機能を実行する役割から開放される。

同様に、実行機能を有するサーバ１−２等は、現在実行管理機能を実行しているサーバ１−５を監視している。そして、サーバ１−５等が不測の事態によって停止していると推定される場合、実行機能制御域の優先度にしたがって、サーバ１−２等のうちの最も優先度の高いものが実行管理機能を実行するようになる。このとき、サーバ１−５は、実行管理機能を実行する役割から開放される。

＜ジョブキュー区画のデータ構造＞
図５から図９の図面に基づいて、ジョブキュー区画のデータ構造を説明する。図５は、ジョブスケジュールを格納するジョブキュー情報域（本発明のジョブキュー記憶部に相当）のデータ構造を示す図である。図５の表で、最上部の行は、ジョブキュー情報域に登録されるレコードの項目を示している。したがって、図５の表で第２行目以下が、具体的なジョブスケジュールを示すレコードである。

図５のように、ジョブキュー情報域の各レコードは、格納日時、ジョブキュー内管理情報、ジョブ名、実行依頼されたサーバ、実行可能なサーバ属性、実行しているサーバ、ジョブのステータス、その他の情報を有している。

格納日時は、スケジュール管理機能を有するスケジュール管理サーバによって、ジョブキュー登録依頼情報域の情報を基にジョブキュー情報域に登録された日時である。

ジョブキュー内管理情報は、ジョブキュー情報域での通し番号である。ジョブキュー情報域の各ジョブのレコードは、ジョブキュー内管理情報によって一意に識別される。

ジョブ名は、ジョブの名称である。ジョブ名は、ジョブキュー情報域の内容を表示するときに、ユーザに認識しやすくするための名称である。通常は、ジョブで実行されるコマンド名、プログラム名等を含んだ名称である。その場合、ジョブの実行依頼をジョブキュー登録依頼情報域に書き込むサーバ１−２等が所定の手順でジョブ名を決定するようにしてもよい。また、例えば、スケジュール管理機能を実行するスケジュール管理サーバが所定の手順でジョブ名を決定するようにしてもよい。

実行依頼されたサーバとは、実行管理機能を有する実行管理サーバによってそのジョブが割り当てられたサーバ１−４等である。実行可能なサーバ属性とは、ジョブの実行依頼で指定された実行条件（サーバ属性）であり、例えば、ＯＳのグループの指定である。実行しているサーバとは、そのジョブを現在実行しているサーバのコンピュータ名である。

ジョブのステータスは、例えば、実行中、実行待ち等である。なお、ジョブのステータスとは別に、スケジュール機能（スケジュール管理サーバ）または実行機能（実行管理サーバ）がジョブキューの処理中に異常終了した場合に備えて、スケジュール機能または実
行機能のステータス情報を格納する領域を共用ディスクに設けてもよい。

その他の情報とは、例えば、実行の優先順位、実行開始時間の指定などである。

図６に、登録依頼情報域（本発明のジョブキュー登録依頼記憶部に相当）のデータ構造を示す。登録依頼情報域は、スケジュール機能を有するサーバ１−２等ごとに、領域が分割されている。図６の例では、sｅｒｖｅｒ０１登録依頼情報域から、ｓｅｒｖｅｒ ｂ
登録依頼情報域まで、合計ｂ個の領域（ｓｅｒｖｅｒ ｘ（ｘ＝１，．．．，ｂ）に対応する領域）が設けられている。

図６では、ｓｅｒｖｅｒ ｘの領域が詳細に例示されている。図６のように、登録依頼情報域の１つの領域（例えば、ｓｅｒｖｅｒ ｘ 用の領域）は、複数個のジョブ格納域
（図６の場合、合計ｃ個の領域）に区分されている。ここで、ｃ個は、スケジュール機能を有する１つのサーバであるｓｅｒｖｅｒ ｘが依頼可能なジョブ数の限界（ジョブがジョブキュー情報域に登録される前に登録依頼を格納可能な容量の限界）である。

１つのジョブ格納域は、管理ステータス、ジョブ名、実行可能なサーバ属性、およびその他の情報を有している。

ここで、管理ステータスには、以下の情報が格納される。
・ジョブ格納域が未使用（ジョブのジョブキュー情報域への移動済みも含む）；
これは、ジョブ格納域が空き状態であることを示している。
・ジョブのジョブキュー情報域への登録依頼済み；
これは、ジョブ格納域が使用中であり、ジョブキュー情報域への登録を待っていることを示している。

なお、管理ステータスとして、スケジュール機能（スケジュール管理サーバ）がジョブキュー情報域の処理中に異常終了した場合に備えて、スケジュール機能のステータスを示す情報を格納するようにしてもよい。

ジョブ名は、ジョブキュー情報域に登録されるジョブ名である。例えば、ユーザから指定されるパラメータによってジョブ名を設定してもよい。また、ユーザがジョブ名を指定しなかった場合、スケジュール機能を有するサーバ１−２等がデフォルトの名称を設定してもよい。また、ジョブで実行されるプログラムの名称等に基づき、スケジュール機能を有するサーバ１−２等が所定の手順でジョブ名を決定するようにしてもよい。

実行可能なサーバ属性は、そのジョブを実行するために必要なサーバ１−５等の条件である。例えば、ＯＳグループが指定される。その他の情報は、例えば、実行の優先順位、実行開始時間の指定などである。ジョブ名、実行可能なサーバ属性、およびその他の情報は、ジョブキュー情報域の登録内容としてそのまま引き継がれる。

図７に、スケジュール機能制御域（本発明の第１サーバ管理情報記憶部に相当）のデータ構造の例を示す。図７の表で、最上部の行は、スケジュール機能制御域に登録されるレコードの項目を示している。したがって、図７の表で第２行目以下が、具体的なスケジュール機能制御域のレコードである。スケジュール機能制御域のレコードは、スケジュール機能を有するサーバの数だけ設けられ（図７では、ｂ個）、各レコードがそれぞれのサーバに対応している。スケジュール機能制御域は、スケジュール機能を有するサーバの中で、現在スケジュール管理機能を実行するスケジュール管理サーバが停止したときに、スケジュール管理サーバに代わってスケジュール管理機能を実行するサーバを決定するための情報を有する。

図７のように、スケジュール機能制御域の各レコードは、処理優先順位、サーバ名、状態、スケジュール処理日時を有している。処理優先順位とは、各レコードで指定されているサーバ１−１等が、スケジュール管理機能を実行するときの優先度を示す。ここでは、優先度１が、最も優先度が高いとする。現在管理機能を実行しているスケジュール管理サーバが停止したと推定される場合に、そのスケジュール管理サーバ以外のサーバで、最も処理優先順位の高いサーバがスケジュール管理サーバとなる。

サーバ名は、各レコードで管理されるサーバのコンピュータ名である。状態とは、各サーバの動作状態を示している。例えば、動作中を示すａｃｔｉｖｅまたは停止中を示すｓｔｏｐが設定される。スケジュール処理日時は、スケジュール管理機能を実行するサーバが定期的に書き込む日時である。

スケジュール機能を有するサーバ１−２等で、スケジュール管理サーバ以外のものは、このスケジュール日時の欄を監視している。そして、スケジュール管理サーバ以外のサーバ１−２等が、所定時間以上、スケジュール日時の欄の値に変化がない場合に、スケジュール管理機能を有するサーバが不測の原因で動作を停止したと推定する。

その場合には、スケジュール機能を有するサーバ１−２等のうち、状態がａｃｔｉｖｅのもので、処理優先順位が最高のものがスケジュール管理サーバとなる。なお、本情報システムでは、現在スケジュール管理機能を実行しているサーバよりも処理優先順位の高いサーバで状態がａｃｔｉｖｅであるものが存在しても、直ちに、現在のスケジュール管理サーバに代わってスケジュール管理機能を実行することをしない。すなわち、スケジュール管理サーバが他のサーバに交代するのは、そのスケジュール管理サーバが停止したときか、または、オペレータ操作によって強制的に、スケジュール管理サーバが切り替えられた場合だけである。

処理優先順位は、スケジュール管理サーバが停止した場合に、他のサーバがスケジュール管理機能を確実に引き継ぐ可能性を極力高める（管理機能が停止する可能性を極力低減する）ためであり、サーバ間の優先順位調整自体が目的ではないからである。

図８に、実行機能制御域（本発明の第２サーバ管理情報記憶部に相当）のデータ構造の例を示す。実行機能制御域のレコードは、実行機能を有するサーバの数だけ設けられ（図８では、ｄ個）、各レコードがそれぞれのサーバに対応している。実行機能制御域は、実行機能を有するサーバの中で、現在実行管理機能を実行する実行管理サーバが停止したときに、その実行管理サーバに代わって次に実行管理機能を実行するサーバを決定するための情報を有する。

図８のように、実行機能制御域のレコードの構成は、スケジュール機能制御域のレコードと同様である。すなわち、優先順位によって選択されるサーバが実行管理機能を有すること以外は、実行機能制御域の役割は、スケジュール機能制御域と同様だからである。

図９に、ジョブキュー取出し依頼情報域のデータ構造の例を示す。ジョブキュー取出し依頼情報域は、実行機能を有するサーバ１−２等ごとに、領域が分割されている。図６の例では、sｅｒｖｅｒ０１取出し依頼情報域から、ｓｅｒｖｅｒ ｄ取出し依頼情報域ま
で、合計ｄ個の領域（ｓｅｒｖｅｒ ｚ（ｚ＝１，．．．，ｄ）に対応する領域）が設けられている。

図９では、ｓｅｒｖｅｒ ｚの領域が詳細に例示されている。図９のように、登録依頼情報域の１つの領域（例えば、ｓｅｒｖｅｒ ｚ 用の領域）は、取出し依頼格納情報域
１００と、取出し依頼結果域１０１（本発明のジョブ割り当て記憶部に相当）を含む。

取出し依頼格納情報域１００は、実行機能を有するそれぞれのサーバ１−２等により書き込まれる。取出し依頼格納情報域１００は、グループ名と取出し依頼ジョブ数を含む。グループ名とは、その取出し依頼情報域で管理されるサーバ属性（サーバが搭載したＯＳのグループ）である。グループ名によって当該サーバがどの種類のサーバ属性を有するかが判別される。

取出し依頼ジョブ数とは、当該サーバが実行管理サーバに対して、ジョブキュー情報域からのジョブの取り出しを依頼するジョブ数である。取出し依頼ジョブ数は、当該サーバが現在どの程度までジョブを受け入れ可能かを示す情報である。この取出し依頼ジョブ数は、当該サーバの負荷に基づいて決定してもよい。

また、取出し依頼結果域１０１には、ジョブキュー情報域のジョブのうち、実行機能を有するサーバに割り当てられたジョブが格納される。すなわち、実行管理機能を有する実行管理サーバ（例えば、サーバ１−５）は、ジョブキュー情報域の状況と、取出し依頼格納情報域１００とを照合する。そして、実行管理サーバは、取出し依頼格納情報域１００のグループ名（サーバ属性）に合致するジョブを取出し依頼結果域１０１に書き込む。

図９のように、取出し依頼結果域１０１は、取り出したジョブ数と、複数個の取出し依頼結果格納域（図６の場合、合計ｅ個の領域）に区分されている。ここで、ｅ個は、実行機能を有する１つのサーバであるｓｅｒｖｅｒ ｘに対して１回に割り当て可能なジョブ数の限界（ジョブが実行完了する前に割り当て可能なジョブ数）である。

さらに、それぞれの取出し依頼結果格納域には、取り出したジョブのジョブキュー情報域内での格納場所を示す情報が書き込まれる。

＜処理フロー＞
図１０から図１７の図面に基づいて本情報システムの処理フローを説明する。これらの処理は、それぞれの機能を有するサーバ上のコンピュータプログラムとして実現される。図１０は、スケジュール機能起動時のスケジュール管理機能を担当する優先順位の決定方法を示すフローチャートである。この処理では、スケジュール管理機能を有するスケジュール管理サーバ（このサーバを最高位のスケジュール機能を実行するサーバともいう）が決定される。ここでは、サーバ１−１がスケジュール機能を起動した場合を例に説明する。

まず、サーバ１−１のスケジュール機能が起動されると、サーバ１−１は、共用ディスク２のスケジュール機能制御域を参照する。そして、サーバ１−１は、スケジュール機能制御域を参照し、自身のスケジュール機能がリストに存在するかを確認する。すなわち、サーバ１−１は、自サーバに対応するエントリがスケジュール機能制御域に定義されているか否かを判定する（Ｓ１）。

自サーバに対応するエントリがスケジュール機能制御域に定義されていない場合、サーバ１−１は、スケジュール機能を停止する（Ｓ２）。以降、サーバ１−１は、スケジュール機能を実行しない。

一方、自サーバに対応するエントリがスケジュール機能制御域に定義されている場合、サーバ１−１は、自サーバの処理優先順位を取得する。そして、サーバ１−１は、スケジュール機能制御域内の自身のスケジュール機能の状態をａｃｔｉｖｅに変更する（Ｓ３）。

次に、サーバ１−１は、スケジュール機能制御域内で、スケジュール処理日時を設定している他のスケジュール機能（他サーバ）を検索する（Ｓ４）。

そして、サーバ１−１は、スケジュール処理日時を設定しているスケジュール機能（他サーバ）が存在するか否かを判定する（Ｓ５）。スケジュール処理日時を設定しているスケジュール機能（他サーバ）が存在する場合には、サーバ１は、そのまま処理を終了する。

一方、スケジュール処理日時を設定しているスケジュール機能（他サーバ）が存在しない場合には、サーバ１−１は、スケジュール機能制御域内で、自スケジュール機能より処理優先順位が高く、状態がａｃｔｉｖｅである他スケジュール機能（他サーバ）を検索する（Ｓ６）。

そして、サーバ１−１は、自スケジュール機能より処理優先順位が高く、状態がａｃｔｉｖｅである他スケジュール機能（他サーバ）が存在するか否かを判定する（Ｓ７）。自スケジュール機能より処理優先順位が高く、状態がａｃｔｉｖｅである他スケジュール機能（他サーバ）が存在する場合には、サーバ１−１は、そのまま処理を終了する。

一方、自スケジュール機能より処理優先順位が高く、状態がａｃｔｉｖｅである他スケジュール機能（他サーバ）が存在しない場合には、サーバ１−１は、スケジュール機能制御域内の自身のスケジュール機能のスケジュール処理日時を設定する（Ｓ８）。これにより、当該サーバ１−１がスケジュール管理サーバ（すなわち、最高位のスケジュール機能）として動作するようになる。

図１１は、実行機能起動時の処理優先順位の決定方法を示すフローチャートである。この処理では、実行管理機能を実行する実行管理サーバ（このサーバを最高位の実行機能を実行するサーバともいう）が決定される。ここでは、サーバ１−５が実行機能を起動した場合を例に説明する。

まず、サーバ１−５の実行機能が起動されると、サーバ１−５は、共用ディスク２の実行機能制御域を参照する。そして、サーバ１−５は、実行機能制御域を参照し、自身の実行機能がリストに存在するかを確認する。すなわち、サーバ１−５は、自サーバに対応するエントリが実行機能制御域に定義されているか否かを判定する（Ｓ１１）。

自サーバに対応するエントリが実行機能制御域に定義されていない場合、サーバ１−５は、実行機能を停止する（Ｓ１２）。

一方、自サーバに対応するエントリが実行機能制御域に定義されている場合、サーバ１−５は、自サーバの処理優先順位を取得する。そして、サーバ１−５は、実行機能制御域内の自身の実行機能の状態をａｃｔｉｖｅに変更する（Ｓ１３）。

次に、サーバ１−５は、実行機能制御域内で、実行処理日時を設定している実行機能（他サーバ）を検索する（Ｓ１４）。

そして、サーバ１−５は、実行処理日時を設定している実行機能（他サーバ）が存在するか否かを判定する（Ｓ１５）。実行処理日時を設定している実行機能（他サーバ）が存在する場合には、サーバ１−５は、そのまま処理を終了する。

一方、実行処理日時を設定している実行機能（他サーバ）が存在しない場合には、サー
バ１−５は、実行機能制御域内で、自身の実行機能より処理優先順位が高く、状態がａｃｔｉｖｅである他実行機能（他サーバ）を検索する（Ｓ１６）。

そして、サーバ１−５は、自身の実行機能より処理優先順位が高く、状態がａｃｔｉｖｅである他の実行機能（他サーバ）が存在するか否かを判定する（Ｓ１７）。自身の実行機能より処理優先順位が高く、状態がａｃｔｉｖｅである他の実行機能（他サーバ）が存在する場合には、サーバ１−５は、そのまま処理を終了する。

一方、自身の実行機能より処理優先順位が高く、状態がａｃｔｉｖｅである他実行機能（他サーバ）が存在しない場合には、サーバ１−５は、実行機能制御域内の自身の実行機能の実行処理日時を設定する（Ｓ１８）。これにより、当該サーバ１−５が実行管理サーバ（すなわち、最高位の実行機能）として動作するようになる。

図１２に、一般のスケジュール機能を実行するサーバ１−２の処理フローを示す（ここでは、サーバ１−２が一般のスケジュール機能を実行すると仮定する）。ここで、一般のスケジュール機能とは、ジョブ登録依頼機能をいう。すなわち、スケジュール管理サーバの機能（最高位のスケジュール機能）以外のスケジュール機能をいう。

この処理では、一般のスケジュール機能を実行するサーバ１−２は、定期的に自サーバ用の登録依頼情報域のジョブ情報の空きを確認する（Ｓ２１）。そして、ジョブ情報の空きが存在する場合には（Ｓ２２でＹＥＳの場合）、サーバ１−２は、例えば、ジョブスケジューラ製品からジョブの実行依頼を受け取る（Ｓ２３）。ただし、サーバ１−２は、オペレータの操作によるジョブの実行依頼を受け取ってもよい。

そして、サーバ１−２は、自サーバ用の登録依頼情報域に実行依頼を受けたジョブ情報を書き込む。このとき、サーバ１−２は、ジョブのステータスを登録依頼待ちにする（Ｓ２４）。

図１３に、スケジュール管理サーバのスケジュール管理機能（最高位のスケジュール機能）の処理フローを示す。以下、サーバ１−１がスケジュール管理機能を実行すると仮定する。

この処理では、まず、サーバ１−１は、起動直後にジョブキュー情報域に書き込まれている最後のジョブ情報の場所を把握する（Ｓ３１）。

次に、サーバ１−１は、ジョブキュー情報域内の空き状況を把握する（Ｓ３２）。

次に、サーバ１は、定期的にジョブキュー登録依頼情報域内の自サーバ／他サーバ用の登録依頼情報域にジョブの実行依頼が書き込まれることを監視する。すなわち、ステータスが登録依頼待ちのジョブの出現を監視する（Ｓ３３）。

そして、サーバ１−１は、スケジュール機能制御域内の自身のスケジュール機能のスケジュール処理日時を最新時刻で更新する（Ｓ３４）。次に、サーバ１−１は、ジョブの実行依頼が書き込まれたか否かを判定する（Ｓ３５）。ジョブの実行依頼が書き込まれていない場合、サーバ１−１は、制御をＳ３３に戻す。

ジョブの実行依頼が書き込まれている場合、サーバ１−１は、ジョブキュー登録依頼情報域内の自サーバ／他サーバ用の登録依頼情報域に書き込まれたジョブの実行依頼を読み出す。さらに、サーバ１−１は、登録依頼情報域の当該レコードのジョブのステータスを未使用にする（Ｓ３６）。

次に、サーバ１−１は、空いているジョブキュー情報域にジョブの実行要求を書き込む。さらに、サーバ１−１は、ジョブキュー情報域の当該レコードのジョブのステータスを実行待ちにする（Ｓ３７）。

図１４に、一般の実行機能を実行するサーバ１−４の処理フローを示す（ここでは、サーバ１−４が一般の実行機能を実行すると仮定する）。ここで、一般の実行機能とは、ジョブキュー情報域のジョブを割り当てられ、そのジョブを実行する機能をいう。すなわち、実行管理サーバの機能（最高位の実行機能）以外の実行機能をいう。

この処理では、一般の実行機能を実行するサーバ１−４は、自サーバが所属するグループに対して、グループ内での最大同時実行可能ジョブ数と、現在実行中のジョブ数との差を把握する（Ｓ４１）。

次に、サーバ１−４は、ジョブキュー取出し依頼格納情報域１００内の自サーバの取出し依頼格納情報域１００に、取り出して欲しいグループ名とジョブ数を設定する（Ｓ４２）。このジョブ数は、例えば、上記最大同時実行可能ジョブ数と、現在実行中のジョブ数との差である。また、その差を所定の係数で補正したものであってもよい。

そして、サーバ１−４は、実行管理サーバ（最高位の実行機能）によってジョブキュー取出し依頼情報域内の自サーバの取出し依頼結果域１０１に情報が書き込まれるのを定期的に監視する（Ｓ４３）。

そして、サーバ１−４は、ジョブキュー取出し依頼情報域内の自サーバの取出し依頼結果域１０１から、自サーバに割り当てられたジョブ（ジョブキュー情報域内のジョブ格納場所を示す情報）を取得する（Ｓ４４）。

そして、自サーバの取出し依頼結果域１０１にジョブ格納場所を示す情報が存在しない場合（Ｓ４５でＮＯの場合）、サーバ１−４は、制御をＳ４１に戻す。

一方、自サーバの取出し依頼結果域１０１にジョブ格納場所を示す情報が存在した場合（Ｓ４５でＹＥＳの場合）、サーバ１−４は、ジョブ格納場所を示す情報を元に、ジョブキュー情報域からジョブ情報を取得し、ジョブを実行する。このとき、サーバ１−４は、ジョブのステータスを実行中にする（Ｓ４６）。

そして、サーバ１−４は、ジョブが終了後、ジョブキュー情報域からジョブ情報を削除する（Ｓ４７）。

図１５に、実行管理サーバの機能（最高位のスケジュール機能）の処理フローを示す。以下、サーバ１−５が実行管理機能を実行すると仮定する。

この処理では、まず、サーバ１−５は、定期的にジョブキュー取出し依頼情報域内の、各サーバの取出し依頼格納情報域１００に情報が書き込まれるのを監視する（Ｓ５１）。

次に、サーバ１−５は、実行機能制御域内の自実行機能の実行処理日時を最新時刻で更新する（Ｓ５２）。

そして、サーバ１−５は、自サーバ／他サーバ用の取出し依頼情報域に情報が書き込まれたか否かを判定する（Ｓ５３）。取出し依頼情報域に情報が書き込まれていない場合、サーバ１−５は、制御をＳ５１に戻す。

一方、取出し依頼情報域に情報が書き込まれた場合、サーバ１−５は、各サーバの取出し依頼情報域から取り出し依頼されているグループ名とジョブ数を取得する（Ｓ５４）。

そして、サーバ１−５は、取得したグループ名とジョブ数を元に、ジョブキュー情報域から該当するジョブの実行要求を検索する。さらに、サーバ１−５は、検索されたジョブの実行要求のジョブ情報域内での格納位置を各サーバの取出し依頼情報域内の取出し依頼結果域１０１に書き込む（Ｓ５５）。

図１６に、スケジュール管理サーバ（最高位のスケジュール機能）が停止した場合に、次のスケジュール管理サーバの順位を決定する処理フローを示す。以下、サーバ１（一般のスケジュール機能を有するサーバの総称）が図１６の処理を実行すると仮定する。

この処理では、サーバ１は、定期的にスケジュール管理サーバ（最高位のスケジュール機能）のスケジュール処理日時の最新時刻を監視する（Ｓ６１）。

そして、サーバ１は、所定時間内の更新が行われているか否かを判定する（Ｓ６２）（なお、スケジュール処理日時が空白になっている場合には、サーバ１は、スケジュール管理サーバ（最高位のスケジュール機能）が他のサーバに交代したと見なし、スケジュール処理日時が書き込まれたスケジュール機能制御域のエントリを検索する）。

所定時間内の更新が行われている場合には、サーバ１は、制御をＳ７１に戻す。一方、所定時間内の更新が行われていない場合には、サーバ１は、状態がａｃｔｉｖｅであるスケジュール機能のうち、自スケジュール機能の順位をスケジュール機能制御域から取得する（Ｓ６３）。

そして、サーバ１は、自スケジュール機能の順位が最高位(以前の最高位は除く)か否かを判定する（Ｓ６４）。自スケジュール機能の順位が最高位でない場合、サーバ１は、制御をＳ７１に戻す。

一方、自スケジュール機能の順位が最高位である場合、サーバ１は、自スケジュール機能のスケジュール処理日時に最新の日時を格納する（Ｓ６５）。これにより、サーバ１は、スケジュール管理サーバ（最高位のスケジュール機能）となる。

さらに、サーバ１は、必要であれば以前のスケジュール管理サーバ（最高位のスケジュール機能）のスケジュール処理日時を空白にしてもよい。また、サーバ１は、以前のスケジュール管理サーバの状態（図７に示したスケジュール機能制御域に含まれている）をａｃｔｉｖｅからｓｔｏｐに変更してもよい（Ｓ６６）。

図１７に、実行管理サーバ（最高位の実行機能）が停止した場合に、次の実行管理サーバを決定する処理フローを示す。以下、サーバ１（一般の実行機能を有するサーバの総称）が図１７の処理を実行すると仮定する。

この処理では、サーバ１は、定期的に実行管理サーバ（最高位の実行機能）の実行処理日時の最新時刻を監視する（Ｓ７１）。

そして、サーバ１は、所定時間内の更新が行われているか否かを判定する（Ｓ７２）（なお、実行処理日時が空白になっている場合には、サーバ１は、実行管理サーバ（最高位の実行機能）が他のサーバに交代したと見なし、実行処理日時が書き込まれた実行機能制御域のエントリを検索する）。

所定時間内の更新が行われている場合には、サーバ１は、制御をＳ７１に戻す。一方、所定時間内の更新が行われていない場合には、サーバ１は、状態がａｃｔｉｖｅである実行機能のうち、自身の実行機能の順位を実行機能制御域から取得する（Ｓ７３）。

そして、サーバ１は、自身の実行機能の順位が最高位(以前の最高位は除く)か否かを判定する（Ｓ７４）。自身の実行機能の順位が最高位でない場合、サーバ１は、制御をＳ７１に戻す。

一方、自身の実行機能の順位が最高位である場合、サーバ１は、自身の実行機能の実行処理日時に最新の日時を格納する（Ｓ７５）。これにより、サーバ１は、実行管理サーバ（最高位の実行機能）となる。

さらに、サーバ１は、必要であれば以前の実行管理サーバ（最高位の実行機能）の実行処理日時を空白にしてもよい。また、サーバ１は、以前の実行管理サーバの状態（図８に示した実行機能制御域内に含まれている）をａｃｔｉｖｅからｓｔｏｐに変更してもよい（Ｓ７６）。

以上述べたように、本実施形態の情報システムによれば、複数のサーバで実行されるジョブを共用ディスクのジョブキュー区画を用いて管理することができる。その場合に、ジョブキュー情報域への登録を依頼する一般のスケジュール機能を複数のサーバに実行させる一方、そのようなジョブをジョブキュー情報域に登録する機能をスケジュール管理サーバ（最高位のスケジュール機能）に限定して、矛盾のないジョブの管理ができる。また、ジョブの実行を要求するスケジュール機能は、一般のスケジュール機能を有するサーバに分散させ、複数のサーバからジョブの実行要求ができる。

さらに、スケジュール管理サーバによるスケジュール処理日時の更新を監視することで、スケジュール管理サーバの不測の停止を推定することができる。そして、スケジュール管理サーバが停止したと推定される場合には、スケジュール機能制御域に設定されたサーバ間の優先順位にしたがって、次のスケジュール管理サーバ（最高位のスケジュール機能）を決定できる。したがって、本情報システムは、複数サーバによってバックアップ可能な体制にて、単一のサーバによってジョブの登録を管理することができる。このため、スケジュール管理サーバが停止しても、スケジュール管理処理が停止する事態を極力回避できる。

同様に、本実施形態の情報システムによれば、ジョブキュー情報域に登録されたジョブを複数のサーバに実行させる一方、そのようなジョブをサーバに割り当てる機能を実行管理サーバ（最高位の実行機能）に限定して、矛盾のない実行管理ができる。また、ジョブを実行する実行機能は、一般の実行機能を有するサーバに分散させ、複数のサーバに負荷分散できる。

さらに、実行管理サーバによる実行処理日時の更新を監視することで、実行管理サーバの不測の停止を推定することができる。そして、実行管理サーバが停止したと推定される場合には、実行機能制御域に設定されたサーバ間の優先順位にしたがって、次の実行管理サーバ（最高位の実行機能）を決定できる。したがって、本情報システムは、複数サーバによってバックアップ可能な体制にて、単一のサーバによってジョブの実行を管理することができる。このため、実行管理サーバが停止しても、実行管理処理が停止する事態を極力回避できる。

＜コンピュータ読み取り可能な記録媒体＞
コンピュータその他の機械、装置（以下、コンピュータ等）に上記いずれかの機能を実現させるプログラムをコンピュータ等が読み取り可能な記録媒体に記録することができる。そして、コンピュータ等に、この記録媒体のプログラムを読み込ませて実行させることにより、その機能を提供させることができる。

ここで、コンピュータ等が読み取り可能な記録媒体とは、データやプログラム等の情報を電気的、磁気的、光学的、機械的、または化学的作用によって蓄積し、コンピュータ等から読み取ることができる記録媒体をいう。このような記録媒体のうちコンピュータ等から取り外し可能なものとしては、例えばフレキシブルディスク、光磁気ディスク、CD-ROM、CD-R/W、DVD、DAT、８mmテープ、メモリカード等がある。

また、コンピュータ等に固定された記録媒体としてハードディスクやＲＯＭ（リードオンリーメモリ）等がある。

＜その他＞
さらに、本実施の形態は以下の発明を開示する。また、以下の各発明（以下付記と呼ぶ）のいずれかに含まれる構成要素を他の付記の構成要素と組み合わせてもよい。
（付記１）
第１サーバまたは第２サーバとして機能するサーバを含む複数のサーバと前記複数のサーバに共用される共用記憶装置とを備え、
前記共用記憶装置は、
ジョブの実行要求を登録してジョブの実行順序を制御するとともにジョブの実行を完了するまで前記ジョブの状態を記憶するジョブキュー記憶部と、
ジョブの実行を要求する要求サーバごとに設けられ、ジョブの実行要求の前記ジョブキュー記憶部への登録を依頼する、そのような登録依頼情報が書き込まれるジョブキュー登録依頼記憶部と、
ジョブを実行する実行サーバごとに設けられ、前記実行サーバと前記実行サーバに割り当てられたジョブの実行要求との関係を記憶するジョブ割り当て記憶部と、を有し、
前記第１サーバは、前記ジョブキュー登録依頼記憶部に書き込まれた登録依頼情報にしたがってジョブの実行要求を前記ジョブキュー記憶部に登録するジョブキュー登録処理部を有し、
前記第２サーバは、前記ジョブキュー記憶部に登録されたジョブの実行要求を前記実行サーバに割り当てて、前記実行サーバと前記実行サーバに割り当てられたジョブの実行要求との関係を前記ジョブ割り当て記憶部に書き込む割り当て処理部を有し、
前記実行サーバは、当該実行サーバに対して設けられたジョブ割り当て記憶部からジョブの実行要求を取得して割り当てられたジョブを実行する実行部を有する、サーバシステム。（１）
（付記２）
前記共用記憶装置は、前記複数のサーバのうち、少なくとも２以上のサーバについて前記第１サーバとなって機能するための優先度情報と現在第１サーバとして機能していることを示す情報とを含む第１サーバ管理情報を前記サーバごとに記憶する第１サーバ管理情報記憶部をさらに有し、
前記少なくとも２以上のサーバは、前記優先度情報にしたがって第１サーバとして機能する付記１に記載のサーバシステム。（２）
（付記３）
前記第１サーバ管理情報記憶部に記憶された複数のサーバで、前記第１サーバとして機能しているサーバ以外のサーバは、前記第１サーバとして機能するサーバの稼働状態を監視し、前記第１サーバとして機能するサーバが停止したと推定されたときに、前記第１サーバとして機能するサーバを除外したサーバの中から前記優先度情報にしたがって決定されるサーバが前記第１サーバとして機能する付記２に記載のサーバシステム。（３）
（付記４）
前記共用記憶装置は、前記複数のサーバのうち、少なくとも２以上のサーバについて前記第２サーバとなって機能するための優先度情報と現在第２サーバとして機能していることを示す情報とを含む第２サーバ管理情報を前記サーバごとに記憶する第２サーバ管理情報記憶部をさらに有し、
前記少なくとも２以上のサーバは、前記優先度情報にしたがって第２サーバとして機能する付記１から３のいずれかに記載のサーバシステム。
（付記５）
前記第２サーバ管理情報記憶部に記憶された複数のサーバで、前記第２サーバとして機能しているサーバ以外のサーバは、前記第２サーバとして機能するサーバの稼働状態を監視し、前記第２サーバとして機能するサーバが停止したと推定されたときに、前記第２サーバとして機能するサーバを除外したサーバの中から前記優先度情報にしたがって決定されるサーバが前記第２サーバとして機能する付記４に記載のサーバシステム。
（付記６）
第１サーバまたは第２サーバとして機能するサーバを含む複数のサーバと前記複数のサーバに共用される共用記憶装置とを備えるサーバシステムが実行する情報処理方法であり、
前記共用記憶装置は、
ジョブの実行要求を登録してジョブの実行順序を制御するとともにジョブの実行を完了するまで前記ジョブの状態を記憶するジョブキュー記憶部と、
ジョブの実行を要求する要求サーバごとに設けられ、ジョブの実行要求の前記ジョブキュー記憶部への登録を依頼する、そのような登録依頼情報が書き込まれるジョブキュー登録依頼記憶部と、
ジョブを実行する実行サーバごとに設けられ、前記実行サーバと前記実行サーバに割り当てられたジョブの実行要求との関係を記憶するジョブ割り当て記憶部と、を有し、
前記第１サーバは、前記ジョブキュー登録依頼記憶部に書き込まれた登録依頼情報にしたがってジョブの実行要求を前記ジョブキュー記憶部に登録するジョブキュー登録処理ステップを実行し、
前記第２サーバは、前記ジョブキュー記憶部に登録されたジョブの実行要求を前記実行サーバに割り当てて、前記実行サーバと前記実行サーバに割り当てられたジョブの実行要求との関係を前記ジョブ割り当て記憶部に書き込む割り当て処理ステップを実行し、
前記実行サーバは、当該実行サーバに対して設けられたジョブ割り当て記憶部からジョブの実行要求を取得して割り当てられたジョブを実行する、情報処理方法。（４）
（付記７）
前記共用記憶装置は、前記複数のサーバのうち、少なくとも２以上のサーバについて前記第１サーバとなって機能するための優先度情報と現在第１サーバとして機能していることを示す情報とを含む第１サーバ管理情報を前記サーバごとに記憶する第１サーバ管理情報記憶部をさらに有し、
前記少なくとも２以上のサーバは、前記優先度情報にしたがって第１サーバとして機能する付記６に記載の情報処理方法。
（付記８）
前記第１サーバ管理情報記憶部に記憶された複数のサーバで、前記第１サーバとして機能しているサーバ以外のサーバは、前記第１サーバとして機能するサーバの稼働状態を監視し、前記第１サーバとして機能するサーバが停止したと推定されたときに、前記第１サーバとして機能するサーバを除外したサーバの中から前記優先度情報にしたがって決定されるサーバが前記第１サーバとして機能する付記７に記載の情報処理方法。
（付記９）
複数のサーバと前記複数のサーバに共用される共用記憶装置とを備えるサーバシステムにおいてそれぞれのサーバを第１サーバまたは第２サーバを含むいずれかのサーバとして機能させるコンピュータ実行可能プログラムであり、
前記共用記憶装置は、
ジョブの実行要求を登録してジョブの実行順序を制御するとともにジョブの実行を完了するまで前記ジョブの状態を記憶するジョブキュー記憶部と、
ジョブの実行を要求する要求サーバごとに設けられ、ジョブの実行要求の前記ジョブキュー記憶部への登録を依頼する、そのような登録依頼情報が書き込まれるジョブキュー登録依頼記憶部と、
ジョブを実行する実行サーバごとに設けられ、前記実行サーバと前記実行サーバに割り当てられたジョブの実行要求との関係を記憶するジョブ割り当て記憶部と、を有し、
前記第１サーバに、前記ジョブキュー登録依頼記憶部に書き込まれた登録依頼情報にしたがってジョブの実行要求を前記ジョブキュー記憶部に登録するジョブキュー登録処理ステップを実行させ、
前記第２サーバに、前記ジョブキュー記憶部に登録されたジョブの実行要求を前記実行サーバに割り当てて、前記実行サーバと前記実行サーバに割り当てられたジョブの実行要求との関係を前記ジョブ割り当て記憶部に書き込む割り当て処理ステップを実行させ、
前記実行サーバに、当該実行サーバに対して設けられたジョブ割り当て記憶部からジョブの実行要求を取得して割り当てられたジョブを実行させる、コンピュータ実行可能なプログラム。（５）
（付記１０）
前記共用記憶装置は、前記複数のサーバのうち、少なくとも２以上のサーバについて前記第１サーバとなって機能するための優先度情報と現在第１サーバとして機能していることを示す情報とを含む第１サーバ管理情報を前記サーバごとに記憶する第１サーバ管理情報記憶部をさらに有し、
前記少なくとも２以上のサーバに、前記優先度情報にしたがって第１サーバとして機能させる付記９に記載のコンピュータ実行可能なプログラム。
（付記１１）
前記第１サーバ管理情報記憶部に記憶された複数のサーバで、前記第１サーバとして機能しているサーバ以外のサーバに、前記第１サーバとして機能するサーバの稼働状態を監視させ、前記第１サーバとして機能するサーバが停止したと推定されたときに、前記第１サーバとして機能するサーバを除外したサーバの中から前記優先度情報にしたがって決定されるサーバに前記第１サーバとして機能させる付記１０に記載のコンピュータ実行可能なプログラム。

従来のシステム構成の例を示す図である。 本発明の一実施形態に係る情報システムのシステム構成を示す図である。 スケジュール管理サーバと、実行管理サーバと、それら以外の他のサーバと、共用ディスクとの関係を示す図である。 ジョブキュー区画の構造を示す図である。 ジョブスケジュールを格納するジョブキュー情報域のデータ構造を示す図である。 登録依頼情報域のデータ構造を示す図である。 スケジュール機能制御域のデータ構造の例を示す図である。 実行機能制御域のデータ構造の例を示す図である。 ジョブキュー取出し依頼情報域のデータ構造の例を示す図である。 スケジュール機能起動時のスケジュール管理機能実行の優先順位の決定方法を示すフローチャートである。 実行機能起動時の処理優先順位の決定方法を示すフローチャートである。 一般のスケジュール機能を実行するサーバ１−２の処理フローを示す図である。 スケジュール管理サーバのスケジュール管理機能（最高位のスケジュール機能）の処理フローを示す図である。 一般の実行機能を実行するサーバ１−４の処理フローを示す図である。 実行管理サーバの機能（最高位のスケジュール機能）の処理フローを示す図である。 スケジュール管理サーバ（最高位のスケジュール機能）が停止した場合に、次のスケジュール管理サーバの順位の決定フローを示す図である。 実行管理サーバ（最高位の実行機能）が停止した場合に、次の実行管理サーバの決定フローを示す図である。

符号の説明

１（１−１、１−２、１−３、１−４、１−５） サーバ
２ 共用ディスク

Claims (5)

1. 各々が第１サーバとして動作可能でありいずれか一つが第１サーバとして動作する複数の要求サーバと、各々が第２サーバとして動作可能でありいずれか一つが第２サーバとして動作する複数の実行サーバとを含む複数のサーバと前記複数のサーバに共用される共用記憶装置とを備え、
   前記共用記憶装置は、
   ジョブの実行要求を登録してジョブの実行順序を制御するとともにジョブの実行を完了するまで前記ジョブの状態を記憶するジョブキュー記憶部と、
   ジョブの実行を要求する前記要求サーバごとに設けられ、ジョブの実行要求の前記ジョブキュー記憶部への登録を依頼する、そのような登録依頼情報が書き込まれるジョブキュー登録依頼記憶部と、
   ジョブを実行する前記実行サーバごとに設けられ、前記実行サーバと前記実行サーバに割り当てられたジョブの実行要求との関係を記憶するジョブ割り当て記憶部と、を有し、
   前記各要求サーバは、ジョブの実行要求を受信し、該実行要求に関する登録依頼情報を要求サーバごとに設けられたジョブキュー登録依頼記憶部に格納し、
   前記複数の要求サーバのうち第１サーバとして動作するいずれか一つの要求サーバは、前記ジョブキュー登録依頼記憶部に書き込まれた登録依頼情報にしたがってジョブの実行要求を前記ジョブキュー記憶部に登録し、
   前記各実行サーバは、当該実行サーバに対して設けられたジョブ割り当て記憶部からジョブの実行要求を取得して割り当てられたジョブをそれぞれ実行し、
   前記複数の実行サーバのうち第２サーバとして動作するいずれか一つの実行サーバは、前記ジョブキュー記憶部に登録されたジョブの実行要求を前記実行サーバに割り当てて、前記実行サーバと前記実行サーバに割り当てられたジョブの実行要求との関係を前記ジョブ割り当て記憶部に書き込む割り当て処理をする、
   サーバシステム。
2. 前記共用記憶装置は、前記複数の要求サーバのうち、少なくとも２以上の要求サーバについて前記第１サーバとなって動作するための優先度情報と現在第１サーバとして動作していることを示す情報とを含む第１サーバ管理情報を前記要求サーバごとに記憶する第１サーバ管理情報記憶部をさらに有し、
   前記少なくとも２以上の要求サーバは、前記優先度情報にしたがって第１サーバとして動作する請求項１に記載のサーバシステム。
3. 前記第１サーバ管理情報記憶部に記憶された複数の要求サーバで、前記第１サーバとして動作している要求サーバ以外の要求サーバは、前記第１サーバとして動作する要求サーバの稼働状態を監視し、前記第１サーバとして動作する要求サーバが停止したと推定されたときに、前記第１サーバとして動作する要求サーバを除外した要求サーバの中から前記優先度情報にしたがって決定される要求サーバが前記第１サーバとして動作する請求項２
   に記載のサーバシステム。
4. 各々が第１サーバとして動作可能でありいずれか一つが第１サーバとして動作する複数の要求サーバと、各々が第２サーバとして動作可能でありいずれか一つが第２サーバとして動作する複数の実行サーバとを含む複数のサーバと前記複数のサーバに共用される共用記憶装置とを備えるサーバシステムが実行する情報処理方法であり、
   前記共用記憶装置は、
   ジョブの実行要求を登録してジョブの実行順序を制御するとともにジョブの実行を完了するまで前記ジョブの状態を記憶するジョブキュー記憶部と、
   ジョブの実行を要求する前記要求サーバごとに設けられ、ジョブの実行要求の前記ジョブキュー記憶部への登録を依頼する、そのような登録依頼情報が書き込まれるジョブキュー登録依頼記憶部と、
   ジョブを実行する前記実行サーバごとに設けられ、前記実行サーバと前記実行サーバに割り当てられたジョブの実行要求との関係を記憶するジョブ割り当て記憶部と、を有し、
   前記各要求サーバは、ジョブの実行要求を受信し、該実行要求に関する登録依頼情報を要求サーバごとに設けられたジョブキュー登録依頼記憶部に格納し、
   前記複数の要求サーバのうち第1サーバとして動作するいずれか一つの要求サーバは、
   前記ジョブキュー登録依頼記憶部に書き込まれた登録依頼情報にしたがってジョブの実行要求を前記ジョブキュー記憶部に登録するジョブキュー登録処理ステップを実行し、
   前記各実行サーバは、当該実行サーバに対して設けられたジョブ割り当て記憶部からジョブの実行要求を取得して割り当てられたジョブをそれぞれ実行し、
   前記複数の実行サーバのうち第２サーバとして動作するいずれか一つの実行サーバは、前記ジョブキュー記憶部に登録されたジョブの実行要求を前記実行サーバに割り当てて、前記実行サーバと前記実行サーバに割り当てられたジョブの実行要求との関係を前記ジョブ割り当て記憶部に書き込む割り当て処理ステップを実行する、情報処理方法。
5. 各々が第１サーバとして動作可能でありいずれか一つが第１サーバとして動作する要求サーバと、各々が第２サーバとして動作可能でありいずれか一つが第２サーバとして動作する実行サーバとを含む複数のサーバと前記複数のサーバに共用される共用記憶装置とを備えるサーバシステムにおいて前記複数の要求サーバのいずれか一つを第１サーバとして、前記複数の実行サーバのいずれか一つを第２サーバとして動作させるコンピュータ実行可能プログラムであり、
   前記共用記憶装置は、
   ジョブの実行要求を登録してジョブの実行順序を制御するとともにジョブの実行を完了するまで前記ジョブの状態を記憶するジョブキュー記憶部と、
   ジョブの実行を要求する前記要求サーバごとに設けられ、ジョブの実行要求の前記ジョブキュー記憶部への登録を依頼する、そのような登録依頼情報が書き込まれるジョブキュー登録依頼記憶部と、
   ジョブを実行する前記実行サーバごとに設けられ、前記実行サーバと前記実行サーバに割り当てられたジョブの実行要求との関係を記憶するジョブ割り当て記憶部と、を有し、
   前記各要求サーバに、ジョブの実行要求を受信し、該実行要求に関する登録依頼情報を要求サーバごとに設けられたジョブキュー登録依頼記憶部に格納するステップを実行させ
   、
   前記複数の要求サーバのうち第1サーバとして動作するいずれか一つの要求サーバに、
   前記ジョブキュー登録依頼記憶部に書き込まれた登録依頼情報にしたがってジョブの実行要求を前記ジョブキュー記憶部に登録するジョブキュー登録処理ステップを実行させ、
   前記各実行サーバに、当該実行サーバに対して設けられたジョブ割り当て記憶部からジョブの実行要求を取得して割り当てられたジョブをそれぞれ実行させ、
   前記複数の実行サーバのうち第２サーバとして動作するいずれか一つの実行サーバに、前記ジョブキュー記憶部に登録されたジョブの実行要求を前記実行サーバに割り当てて、前記実行サーバと前記実行サーバに割り当てられたジョブの実行要求との関係を前記ジョブ割り当て記憶部に書き込む割り当て処理ステップを実行させる、コンピュータ実行可能なプログラム。

Images