JP2005339111A - ジョブの実行制御方法、及びジョブの実行制御システム - Google Patents

Abstract

【課題】 障害の発生した物理ボリュームを含む全ての論理ボリュームへのアクセスを行う全てのジョブの実行を、少なくとも障害が回復するまでの間、抑止できるようにする。
【解決手段】 スケジュール管理部１５は、クライアント１に登録されている或るジョブが、どのタイミングで業務サーバ５によって実行されるか管理する。実行制御部１７は、実際に業務サーバ５との間でデータの授受を行う。業務サーバ５との間で授受するデータのデータ形式の管理、データ授受の相手先である業務サーバ５の宛て先管理、回線接続の制御、データ送／受信に係わる制御等を実行する。障害回復管理部１９は、管理サーバ３からストレージ装置７の論理ボリュームに生じた障害が回復した旨の通知があるまで待機する。管理サーバ３から上記障害回復の通知がくると、障害が回復した旨を障害情報テーブル２３に書き込む。
【選択図】 図１

Description

本発明は、複数の物理ボリュームを有し、各物理ボリュームが複数の論理ボリュームに夫々割り当てられて使用されるストレージ装置と、前記ストレージ装置に対し、ジョブの実行を指令する情報処理装置とを備えるジョブの実行制御方法、及びジョブの実行制御システムに関する。

従来、複数の計算機から構成される計算機システムにおいて、計算機障害時にジョブを再実行させる場合の、負荷分散機能を用いた効率的なジョブ再実行技術が提案されている。該ジョブ再実行技術では、障害の発生した計算機で実行中であったジョブを再実行させる際に、再実行を行う候補となる計算機の負荷情報と、被再実行ジョブが中断されるまでの間の実行状況の情報とから、被再実行ジョブを再実行させる計算機を判定することで効率的な実行と計算機障害の影響の早期解決とが実現される（例えば特許文献１参照）。

特開平11-353284号公報

ところで、ストレージ装置では、該ストレージ装置が備える複数の物理ボリュームを、複数の論理ボリュームに割り当てて使用することがある。そのようなときに、何れかの物理ボリュームに障害が発生すると、該ストレージ装置を使用するクライアント―サーバシステムのクライアントは、物理ボリュームに障害が発生したものと認識するのではなく、該物理ボリュームを含む論理ボリュームに障害が発生したものとしてしか認識できない場合がある。

そのような場合、障害が発生した物理ボリュームを含む論理ボリュームを使用するジョブの実行が失敗すると、クライアントは該ジョブの実行が失敗したことを認識できるから、該ジョブの実行を抑止することが可能である。しかし、上記障害が発生した物理ボリュームを含む別の論理ボリュームを使用する、実行待ちの状態にある別のジョブの実行についても、結果的に失敗してしまうにも拘らず、クライアントが該別の論理ボリュームに係わる障害を認識することができないため、上記実行待ちの状態にある別のジョブの実行を抑止する方法が無い。よって、失敗してしまうことになるジョブを無駄に実行してしまうという問題があった。

従って本発明の目的は、複数の物理ボリュームの各々が複数の論理ボリュームに夫々割り当てられて使用されるストレージ装置と、上記ストレージ装置に、ジョブの実行を指令する情報処理装置とを備えるシステムにおいて、障害の発生した物理ボリュームを含む全ての論理ボリュームへのアクセスを行う全てのジョブの実行を、少なくとも障害が回復するまでの間、抑止できるようにすることにある。

本発明の第１の観点に従うジョブの実行制御システムは、複数の物理ボリュームを有し、各物理ボリュームが複数の論理ボリュームに夫々割り当てられて使用されるストレージ装置と、上記ストレージ装置に対し、ジョブの実行を指令する情報処理装置とを備え、上記各論理ボリュームに障害が発生したかどうか検知する障害検知部と、上記情報処理装置から或るジョブの実行が指令されたことに起因して、上記障害検知部がそのジョブの実行に使用する論理ボリュームに障害が発生したことを検知した場合に、その論理ボリュームが含む物理ボリュームが割り当てられた別の論理ボリュームを検索する論理ボリューム検索部と、を有する。

本発明の第１の観点に係る好適に実施形態では、上記論理ボリューム検索部が検索した論理ボリュームを使用する別のジョブがあるかどうか検索するジョブ検索部と、上記ジョブ検索部が別のジョブを検索した場合に、その別のジョブの実行抑止を、上記情報処理装置に通知する実行抑止通知部と、を更に有する。

上記とは別の実施形態では、上記論理ボリュームに発生した障害が回復したかどうか検知する障害回復検知部と、上記障害回復検知部が上記論理ボリュームの障害回復を検知した場合に、上記別のジョブの実行抑止解除を上記情報処理装置に通知する実行抑止解除通知部と、を更に有する。

また、上記とは別の実施形態では、上記情報処理装置が、クライアント及びサーバを含み、上記ジョブ実行の指令が、クライアントからサーバを通じてストレージ装置へ送られる。

また、上記とは別の実施形態では、上記障害検知部、上記ジョブ検索部、及び上記実行抑止通知部は、何れもサーバに備えられる。

また、上記とは別の実施形態では、上記実行抑止通知部からの通知が、クライアントに送られる。

また、上記とは別の実施形態では、上記障害回復検知部、及び上記実行抑止解除通知部が、サーバに備えられる。

更に、上記とは別の実施形態では、上記実行抑止解除通知部からの通知が、クライアントに送られる。

本発明の第２の観点に従うジョブの実行制御方法は、複数の物理ボリュームを有し、各物理ボリュームが複数の論理ボリュームに夫々割り当てられて使用されるストレージ装置と、上記ストレージ装置に対し、ジョブの実行を指令する情報処理装置とを備え、上記各論理ボリュームに障害が発生したかどうか検知するステップと、上記情報処理装置から或るジョブの実行が指令されたことに起因して、上記障害検知のステップにおいて、そのジョブの実行に使用する論理ボリュームに障害が発生したことが検知された場合に、その論理ボリュームが含む物理ボリュームが割り当てられた別の論理ボリュームを検索するステップと、を有する。

本発明の第２の観点に係る好適に実施形態では、上記論理ボリューム検索のステップにおいて、検索された論理ボリュームを使用する別のジョブがあるかどうか検索するステップと、上記ジョブ検索のステップにおいて、別のジョブが検索された場合に、その別のジョブの実行抑止を、上記情報処理装置に通知するステップと、を更に有する。

上記とは別の実施形態では、上記論理ボリュームに発生した障害が回復したかどうか検知するステップと、上記障害回復検知のステップにおいて、上記論理ボリュームの障害回復が検知された場合に、上記別のジョブの実行抑止解除を上記情報処理装置に通知するステップと、を更に有する。

本発明によれば、複数の物理ボリュームの各々が複数の論理ボリュームに夫々割り当てられて使用されるストレージ装置と、上記ストレージ装置に、ジョブの実行を指令する情報処理装置とを備えるシステムにおいて、障害の発生した物理ボリュームを含む全ての論理ボリュームへのアクセスを行う全てのジョブの実行を、少なくとも障害が回復するまでの間、抑止できるようにすることにある。

以下、本発明の実施の形態を、図面により詳細に説明する。

図１は、本発明の一実施形態に係るジョブスケジュール方式が適用される情報処理システムの全体構成を示すブロック図である。

該情報処理システムは、図１に示すように、クライアントマシン（クライアント）１と、管理サーバ３と、業務サーバ５と、ストレージ装置７と、を備える。実際の情報処理システムでは、クライアントは、符号１で示した１台だけでなく多数存在している訳であるが、以下では、図示と説明の都合上、符号１で示した１台のクライアントのみを例にとる。クライアント１と管理サーバ３との間、クライアント１と業務サーバ５との間、管理サーバ３と業務サーバ５との間、及びクライアント１とストレージ装置７との間での情報の授受は、何れもＬＡＮ（Local Area Network）９を通じて行われる。また、管理サーバ３とストレージ装置７との間、及び業務サーバ５とストレージ装置７との間での情報の授受は、何れもＳＡＮ（Storage Area Network）１１を通じて行われる。

次に、各部の内部構成について詳述する。

クライアント１は、スケジュール登録部１３と、スケジュール管理部１５と、クライアント実行制御部（実行制御部）１７と、障害回復管理部１９と、ジョブ情報テーブル２１と、障害情報テーブル２３と、を備える。

スケジュール登録部１３は、ユーザが、或る処理を行うジョブのスケジュールを、クライアント１に登録するに際して用いられる。ここで、ジョブとは、ストレージ装置７内の物理ボリュームを論理ボリュームとして操作を行うための命令を、クライアント（１）からサーバ（業務サーバ５）に対して指示することをいう。また、スケジュールとは、ユーザがクライアント（１）に登録した幾つかのジョブについて、各々のジョブの実行指令を、クライアント（１）がサーバ（業務サーバ５）に対して出力するタイミングをいう。例えばクライアント１に登録済のジョブが、ａ、ｂ、ｃの３つで、ジョブａは指定時刻「何時何分」が、ジョブｂは即時が、ジョブｃはジョブｂの実行終了時点が、夫々実行指令の出力タイミングに設定されている場合、ジョブａ、ジョブｂ、ジョブｃのスケジュールは、夫々指定時刻「何時何分」、即時、ジョブｂの実行終了時点、ということになる。上記各ジョブａ、ｂ、ｃのスケジュールは、ユーザの所望に応じて自在に設定される。

スケジュール管理部１５は、クライアント１に登録されている或るジョブが、実際にどのタイミングでサーバ（業務サーバ５）によって実行されるかを管理している。

実行制御部１７は、スケジュール管理部１５から上記スケジュールに係わる通知を受けて、実際にＬＡＮ９を通じてサーバ（業務サーバ５）との間でデータの授受を行う。実行制御部１７は、ＬＡＮ９を通じてサーバ（業務サーバ５）との間で授受するデータのデータ形式（プロトコル）の管理や、データ授受の相手先であるサーバ（業務サーバ５）の宛て先管理や、回線（ＬＡＮ９）接続の制御や、データ送／受信に係わる制御等を実行する。

障害回復管理部１９は、ＬＡＮ９を通じてサーバ（管理サーバ３）から（ストレージ装置７の論理ボリュームに生じた）障害が回復した旨の通知があるまで待機状態を保持する。そして、ＬＡＮ９を通じてサーバ（管理サーバ３）から上記障害回復の通知がくると、障害回復管理部１９は、該通知を受付けて、障害が回復した旨を障害情報テーブル２３に書き込む。

ジョブ情報テーブル２１は、クライアント１が持っている（に登録されている）各ジョブの、スケジュール管理部１５によるスケジュール管理のために用いられるテーブルである。ジョブ情報テーブル２１は、クライアント１が持っている各々のジョブの属性（情報）や、各々のジョブの現在の処理状態や、命令内容等の諸情報を蓄積しているテーブルである。なお、ジョブ情報テーブル２１は、上記各々のジョブの状態遷移に応じて、そのデータ内容が、スケジュール管理部１５により変更される。ジョブ情報テーブルについては、後に詳述する。

障害情報テーブル２３は、ストレージ装置７内の、障害が発生した論理ボリュームの一覧を保持する。障害情報テーブル２３についても、後に詳述する。

管理サーバ３は、ストレージ装置７の構成情報や、ストレージ装置７内の論理ボリュームの障害の有無等を管理するためのサーバであり、管理サーバ３は、障害回復受付部２５と、障害回復管理部２７と、受付情報テーブル２９と、構成情報テーブル３１と、を備える。障害回復受付部２５は、クライアント１からＬＡＮ９を通じて、ストレージ装置７内の障害が発生した論理ボリュームについて、障害が回復したらクライアント１へ通知して欲しいとの要求が出されると、該要求を受付ける。

障害回復管理部２７は、障害回復受付部２５がクライアント１からの上記要求を受付けると、ＳＡＮ１１を通じて、ストレージ装置７の構成情報を、所定のタイミングでサンプリングする。障害回復管理部２７は、サンプリングした該構成情報をチェックすることにより、障害回復の通知をしなければならない論理ボリュームの状態をチェックする。そして、このチェックの結果、該論理ボリュームに生じた障害が回復していた場合には、障害回復管理部２７は、ＬＡＮ９を通じてクライアント１に対し、その旨を通知する。

受付情報テーブル２９は、ストレージ装置７内の、障害回復の通知を要求されている論理ボリュームを特定するための、各々の論理ボリュ−ムの識別情報や、障害回復の通知を要求している各々のクライアント（１）の宛て先情報等を保持する。受付情報テーブル２９についても、後に詳述する。

構成情報テーブル３１は、ストレージ装置７内の何れの論理ボリュームで障害が発生したかを、管理サーバ３がクライアント１に通知するために、使用されるテーブルである。即ち、構成情報テーブル３１は、ストレージ装置７内の、物理ボリュームが正常かそれとも障害が生じているか等の、各々の物理ボリュームの状態と、各々の物理ボリュームと、各々の論理ボリュームとの対応関係とを夫々示すテーブルである。因みに、構成情報テーブル３１において、論理ボリュームに対応する物理ボリュームが正常であれば、全て正常」であると判断される。構成情報テーブル３１は、ＳＡＮ１１を通じてストレージ装置７から管理サーバ３へ送信される。

業務サーバ５は、ＬＡＮ９を通じてクライアント１から送信されるジョブ実行の要求を受付け、該ジョブの実行の命令を、ＳＡＮ１１を通じてストレージ装置７に発行するためのサーバである。業務サーバ５は、業務サーバ実行制御部（実行制御部）３３と、構成情報テーブル３５と、を備える。

実行制御部３３は、クライアント１側の実行制御部１７と連携して、ジョブ実行のための必要な処理が行えるようになっている。実行制御部３３は、ＬＡＮ９を通じてクライアント１側の実行制御部１７から送信された命令を解析することにより、その解析結果に基づき、ＳＡＮ１１を通じてストレージ装置７に対し、ジョブ実行の指令を発する。

構成情報テーブル３５は、構成情報テーブル３１と全く同一のテーブルである。よって、構成情報テーブル３５の詳細については、その説明を省略する。構成情報テーブル３５は、ＬＡＮ９を通じて管理サーバ３から業務サーバ５へ送信される。

業務サーバ５において、実行制御部３３がジョブの失敗を認識した場合、構成情報テーブル３５を参照することにより、何れの論理ボリュームで障害が発生したかを把握して、障害が発生した論理ボリュームに係わる情報を、ＬＡＮ９を通じてクライアント１に通知する。

ストレージ装置７は、図１に示すように、複数の物理ボリューム（３７、３９、４１、４３）と、上記各物理ボリューム（３７、３９、４１、４３）の何れかが割り当てられて形成されている複数の論理ボリューム（４５、４７、４９）と、を備える。論理ボリューム４５には、物理ボリューム３７、３９、４１が、また、論理ボリューム４７には、物理ボリューム３９、４１、４３が、更に、論理ボリューム４９には、物理ボリューム４１，４３、・・・が、夫々割り当てられている。

実際のストレージ装置では、物理ボリュームは符号３７、３９、４１、４３で示した４個だけでなく多数存在しており、また、論理ボリュームについても、符号４５、４７、４９で示した３個だけでなく多数存在している訳であるが、以下では、図示と説明の都合上、符号３７〜４３で示した４個の物理ボリューム、及び符号４５〜４９で示した３個の論理ボリュームのみを例にとる。

勿論、ストレージ装置７は、上記物理ボリューム（３７、３９、４１、４３）や、上記論理ボリューム（４５、４７、４９）だけから構成されているものではなく、チャネルアダプタ、ディスクアダプタ、共有メモリ、キャッシュメモリ等をも備えているが、本実施形態では、これら各部については本発明の要旨と直接的な関連性はないので、図示及び詳細な説明を省略する。

図２は、図１に記載のクライアント１が備えるジョブ情報テーブル２１の一例を示す説明図である。

既述のように、ジョブ情報テーブル（２１）とは、クライアント（１）が持っている各々のジョブの属性（情報）や、各々のジョブの現在の処理状態や、命令内容等の諸情報を蓄積しているテーブルである。即ち、図２に示すように、ジョブ情報テーブル２１には、多数のジョブ名を記憶するためのジョブ名記憶領域５１と、各ジョブ毎に設けられた、各ジョブの状態を記憶するための状態記憶領域５３と、各ジョブ毎に設けられた、各ジョブに対して実行命令が発せられたことを記憶するための実行命令記憶領域５５と、各ジョブ毎に設けられた、各ジョブが使用するリソース名（論理ボリューム名）を記憶するためのリソース名記憶領域５７と、が備えられる。

ジョブ名記憶領域５１には、例えば図１で示したクライアント１が持っている複数のジョブである、ジョブ１、ジョブ２、ジョブ３、ジョブ４、ジョブ５、・・・が夫々記憶されている。状態記憶領域５３には、例えばジョブ１の状態として“未実行”が、ジョブ２の状態として“実行中”が、ジョブ３の状態として“障害回復待ち”が、ジョブ４の状態として“スケジュール待ち”が、ジョブ５の状態として“障害回復待ち”が、夫々記憶されている。実行命令記憶領域５５には、例えばジョブ１乃至ジョブ５について、“実行命令”が、夫々記憶されている。リソース名記憶領域５７には、例えばジョブ１について“論理ボリューム２”が、ジョブ２について“論理ボリューム１”が、ジョブ３について“論理ボリューム２”が、ジョブ４について“論理ボリューム１”が、ジョブ５について“論理ボリューム３”が、夫々記憶されている。

ジョブ情報テーブル２１のデータ内容は、上記各々のジョブ１乃至５の実際の状態の遷移に応じて、スケジュール管理部１５により変更される。

図３は、図１に記載のクライアント１が備える障害情報テーブル２３の一例を示す説明図である。

既述のように、障害情報テーブル２３とは、ストレージ装置７内の、障害が発生した論理ボリュームの一覧を保持するもので、本実施形態では、障害が発生したリソース名（論理ボリューム名）として、例えば論理ボリューム２、論理ボリューム３、・・・が記憶されている。なお、上記論理ボリューム２、３以外の論理ボリュームについて、新たに障害が発生した場合には、その障害が発生した論理ボリュームも、障害情報テーブル２３に書き込まれる。

図４は、図１に記載の管理サーバ３が備える受付情報テーブル２９の一例を示す説明図である。

既述のように、受付情報テーブル２９とは、ストレージ装置７内の、障害回復の通知を要求されている論理ボリュームを特定するための、各々の論理ボリュ−ムの識別情報や、障害回復の通知を要求している各々のクライアント（１）の宛て先情報等を保持するものである。受付情報テーブル２９は、障害回復の通知を要求されているリソース名（論理ボリューム名）を記憶するためのリソース名記憶領域６１と、障害回復の通知を要求しているクライアントを示す情報を記憶するためのクライアント情報記憶領域６３と、を備える。本実施形態では、リソース名記憶領域６１には、例えば論理ボリューム２、論理ボリューム３、・・・が記憶されている。クライアント情報記憶領域６３には、論理ボリューム２に対応するクライアント情報として、ＩＰアドレス１及びポート番号１と、ＩＰアドレス２及びポート番号２とが、論理ボリューム３に対応するクライアント情報として、ＩＰアドレス１及びポート番号１と、ＩＰアドレス３及びポート番号３と、ＩＰアドレス４及びポート番号４とが、夫々記憶されている。ＩＰアドレスとポート番号とにより、特定のクライアントが示される。なお、ポート番号とは、各クライアント（１）側の受信ポートのことを指す。

図５は、図１に記載の管理サーバ３が備える構成情報テーブル３１、及び図１に記載の業務サーバ５が備える構成情報テーブル３５の一例を示す説明図である。

既述のように、構成情報テーブル３１（３５）とは、ストレージ装置７内の何れの論理ボリュームで障害が発生したかを、管理サーバ３がクライアント１に通知するために、使用されるテーブルである。構成情報テーブル３１（３５）は、ストレージ装置７内の各物理ボリューム（１、２、３、４、・・・）を記憶するための物理ボリューム名記憶領域７１と、各物理ボリューム（１、２、３、４、・・・）毎に設けられた、各物理ボリューム（１、２、３、４、・・・）の状態を記憶するための状態記憶領域７３と、物理ボリューム名記憶領域７１に記憶されている各物理ボリューム（１、２、３、４、・・・）に夫々対応付けて設定された論理ボリューム名記憶領域７５と、を備える。

本実施形態では、物理ボリューム１は、論理ボリューム１に対応していて、状態が正常であることを示しており、物理ボリューム２は、論理ボリューム２、及び論理ボリューム３に対応していて、障害が発生していることを示している。また、物理ボリューム３は、論理ボリューム２、論理ボリューム３、及び論理ボリューム４に対応していて、状態が正常であることを示しており、物理ボリューム４は、論理ボリューム１、及び論理ボリューム３に対応していて、状態が正常であることを示している。

図６は、図１に記載の情報処理システムにおいて、クライアント１の実行制御部１７から業務サーバ５（の実行制御部３３）へ送信されるジョブ実行要求データの一例を示す説明図である。

ジョブ実行要求データは、図６に示すように、データ長１、データ識別子、データ長２、ジョブ名、データ長３、実行命令、データ長４、及び論理ボリューム名の各データを含む。データ長１は、該ジョブ実行要求データ全体のデータ量を表すデータである。データ識別子は、該ジョブ実行要求データ自体を、例えば別のジョブ実行要求データから識別するためのもので、固定長のデータである。データ長２は、データ長２自身のデータ量と、ジョブ名のデータ量との和を示している。ジョブ名には、（例えば、ジョブａ、ジョブｂ、ジョブｃ、・・・のように）ジョブを具体的に特定するためのデータが登録されている。データ長３は、データ長３自身のデータ量と、実行命令のデータ量との和を示している。実行命令には、業務サーバ５の実行制御部３３がストレージ装置７に対して発行する命令内容が登録されている。データ長４は、データ長４自身のデータ量と、上記ジョブの実行に係わる論理ボリューム名のデータ量との和を示している。

図７は、図１に記載の情報処理システムにおいて、業務サーバ５（の実行制御部３３）からクライアント１の実行制御部１７へ送信されるジョブ実行応答データの一例を示す説明図である。

ジョブ実行応答データは、図７（ａ）に示すように、障害情報が無い場合のジョブ実行応答データ（第１のジョブ実行応答データ）と、図７（ｂ）に示すように、障害情報が有る場合のジョブ実行応答データ（第２のジョブ実行応答データ）とに分類される。

第１のジョブ実行応答データは、図７（ａ）に示すように、データ長１、データ識別子、データ長２、ジョブ名、データ長３、及び実行結果の各データを含む。データ長１、データ識別子、データ長２、ジョブ名、データ長３については、図６におけると同様である。実行結果には、該ジョブの実行に係わる論理ボリュームに障害が発生していないので、『正常終了』が登録されている。

一方、第２のジョブ実行応答データは、図７（ｂ）に示すように、データ長１、データ識別子、データ長２、ジョブ名、データ長３、実行結果、データ長４、及び障害情報の各データを含む。データ長１、データ識別子、データ長２、ジョブ名、及びデータ長３については、図６、及び図７（ａ）におけると同様である。実行結果には、該ジョブの実行に係わる論理ボリュームに障害が発生しているので、例えば『異常終了』が登録されている。データ長４は、データ長４自身のデータ量と、障害情報のデータ量との和を示している。障害情報は、図７（ｂ）に示すように、データ長４１、論理ボリューム名、データ長４２、及び論理ボリューム名、・・・を含む。データ長４１は、データ長４１自身のデータ量と、障害が発生している論理ボリューム名のデータ量との和を示している。同様に、データ長４２も、データ長４２自身のデータ量と、障害が発生している論理ボリューム名のデータ量との和を示している。障害が発生している上記各論理ボリューム名は、例えば業務サーバ５の実行制御部３３によって書き込まれる。

図８は、図１に記載の情報処理システムにおいて、クライアント１の障害回復管理部１９から管理サーバ３（の障害回復受付部２５）へ送信される障害回復要求データの一例を示す説明図である。

障害回復要求データは、図８に示すように、データ長１、データ識別子、データ長２、論理ボリューム名、ＩＰアドレス、及びポート番号の各データを含む。データ長１、データ識別子、及びデータ長２については、図６、及び図７におけると同様である。論理ボリューム名には、障害回復の通知を要求されている、現に障害が発生している論理ボリューム名が登録されており、また、ＩＰアドレス、及びポート番号には、該論理ボリュームについて、障害回復の通知を要求している各々のクライアント（１）の宛て先情報であるＩＰアドレス情報と、ポート番号情報とがクライアント情報として、夫々登録されている。

図９は、図１に記載の情報処理システムにおいて、管理サーバ３（の障害回復管理部２７）からクライアント１の障害回復管理部１９へ送信される障害回復応答データの一例を示す説明図である。

障害回復応答データは、図９に示すように、データ長１、データ識別子、データ長２、及び論理ボリューム名の各データを含む。データ長１、データ識別子、及びデータ長２については、図６、図７、及び図８におけると同様である。論理ボリューム名には、障害が回復した論理ボリューム名が登録されている。

図１０は、図１に記載の情報処理システムにおいて、業務サーバ５の実行制御部３３から管理サーバ３（の障害回復管理部２７）へ送信される構成情報取得要求データの一例を示す説明図である。

構成情報取得要求データは、図１０に示すように、データ長１、及びデータ識別子の各データを含む。データ長１、及びデータ識別子についての詳細な説明は、省略する。

図１１は、図１に記載の情報処理システムにおいて、管理サーバ３（の障害回復管理部２７）から業務サーバ５の実行制御部３３へ送信される構成情報取得応答データの一例を示す説明図である。

構成情報取得応答データは、図１１に示すように、データ長１、データ識別子、データ長２、及び構成情報テーブルの各データを含む。データ長１、データ識別子、及びデータ長２についての詳細な説明は、省略する。構成情報テーブルには、ストレージ装置７から送信される、図５で示したような構成情報テーブル３１（３５）が登録されている。

図１２は、図１に記載の情報処理システムにおいて、主にクライアント１の実行制御部１７が行う処理動作を示すフローチャートである。

図１２において、まず、クライアント１の実行制御部１７は、業務サーバ５に対し、クライアント１が持つ特定のジョブに係わる、図６で示したようなジョブ実行要求データを送信する（ステップＳ１２１）。この処理動作が終了すると、図２で示したようなジョブ情報テーブル２１中の該ジョブに係わる“状態”が、スケジュール管理部１５によって『実行中』に変更される（ステップＳ１２２）。次に、業務サーバ５から図７で示したようなジョブ実行応答データが送信されると、実行制御部１７は、該ジョブ実行応答データを受信する。該ジョブの実行に係わる論理ボリュームに障害が発生していなければ、換言すれば、障害情報が『無』であれば、図７（ａ）で示したデータ構成のジョブ実行応答データが業務サーバ５から送信される。一方、該ジョブの実行に係わる論理ボリュームに障害が発生していれば、即ち、障害情報が『有』であれば、図７（ｂ）で示したデータ構成のジョブ実行応答データが業務サーバ５から送信される（ステップＳ１２３）。

次に、実行制御部１７は、上記受信したジョブ実行応答データをチェックすることにより、該ジョブ実行応答データ中の“実行結果”が『正常終了』かどうか判別する（ステップＳ１２４）。この判別の結果『正常終了』であれば（ステップＳ１２４でYES）、スケジュール管理部１５は、ジョブ情報テーブル２１中の該ジョブに係わる“状態”を、『正常終了』に変更し（ステップＳ１２５）、一連の処理動作が終了する。

一方、上記判別の結果が、『正常終了』でなければステップＳ１２４でNO）、実行制御部１７は、受信したジョブ実行応答データ中に、障害情報が有るかどうかチェックする（ステップＳ１２６）。このチェックの結果、上記ジョブ実行応答データ中に、障害情報が有ると判別すると（ステップＳ１２６でYES）、スケジュール管理部１５は、ジョブ情報テーブル２１中から、上記ジョブ以外に上記障害が発生した論理ボリュームを使用するジョブが他に有るかどうかを検索する（ステップＳ１２７）。この検索の結果、上記論理ボリュームを使用するジョブが別にあると判断した場合には（ステップＳ１２８でYES）、スケジュール管理部１５は、上記論理ボリュームを使用する別のジョブの“状態”が、『スケジュール待ち』かどうかチェックする（ステップＳ１２９）。このチェックの結果、『スケジュール待ち』であると判別すると（ステップＳ１２９でYES）、スケジュール管理部１５は、ジョブ情報テーブル２１中の上記別のジョブに係わる“状態”を、『障害回復待ち』に変更した後（ステップＳ１３０）、障害回復管理部１９を起動する（ステップＳ１３１）。これにより、障害回復管理部１９は、管理サーバ３から上記論理ボリュームに生じた障害が回復した旨の通知があるまで待機状態を保持し、管理サーバ３から上記障害回復の通知がきたときには、該通知を受付けて、障害が回復した旨を障害情報テーブル２３に書き込む処理を行うことになる。

実行制御部１７が、受信したジョブ実行応答データ中に、障害情報が無いと判別した場合には（ステップＳ１２６でNO）、直ちにステップＳ１３３で示す処理動作に移行する。また、上記ジョブ以外に上記障害が発生した論理ボリュームを使用するジョブがジョブ情報テーブル２１中から検索されなかった場合には（ステップＳ１２８でNO）、直ちにステップＳ１３２で示す処理動作に移行する。上記障害が発生した論理ボリュームを使用する別のジョブの“状態”が、『スケジュール待ち』でない場合にも（ステップＳ１２９でNO）、直ちにステップＳ１３２で示す処理動作に移行する。

次に、ステップＳ１２７乃至ステップＳ１３１で示す処理動作が、受信したジョブ実行応答データ中の障害有り（障害情報有）とされた全ての論理ボリュームについて実行されたかどうかチェックする（ステップＳ１３２）。このチェックの結果、障害有りとされた全ての論理ボリュームについて実行されてなければ（ステップＳ１３２でNO）、ステップＳ１２７で示した処理動作に復帰する。一方、上記チェックの結果、障害有りとされた全ての論理ボリュームについて実行されていれば（ステップＳ１３２でYES）、スケジュール管理部１５は、ジョブ情報テーブル２１中の上記別のジョブの“状態”が、『実行中』かどうかチェックする（ステップＳ１３３）。このチェックの結果、『実行中』であると判別した場合には（ステップＳ１３３でYES）、スケジュール管理部１５は、ジョブ情報テーブル２１中の上記別のジョブに係わる“状態”を、『異常終了』に変更する（ステップＳ１３４）。これにより、一連の処理動作が終了する。

上記チェックの結果、『実行中』でないと判別した場合には（ステップＳ１３３でNO）、それにより、一連の処理動作が終了する。

図１３は、図１に記載の情報処理システムにおいて、クライアント１の障害回復管理部１９が行う処理動作を示すフローチャートである。

図１２のフローチャートで説明したように、クライアント１の障害回復管理部１９は、ジョブ情報テーブル２１中の障害が発生した論理ボリュームを使用する別のジョブの“状態”が、スケジュール管理部１５によって『スケジュール待ち』から『障害回復待ち』に変更されたことに起因して起動状態になる。

即ち、図１３において、まず、障害回復管理部１９は、該当する論理ボリューム用レコード（行）（つまり、図１２のフローチャートで説明した別のジョブが使用する論理ボリューム用レコード）が、図３で示したような障害情報テーブル２３中に存在するかどうか検索する（ステップＳ１４１）。この検索の結果、上記論理ボリューム用レコードが存在してなければ（ステップＳ１４２でNO）、障害回復管理部１９は、上記論理ボリューム用レコードを、障害情報テーブル２３に追加登録する（ステップＳ１４３）。

次に、管理サーバ３に対し、図８で示したような障害回復要求データを送信し（ステップＳ１４４）、これにより、管理サーバ３から図９で示したような障害回復応答データが送信されてくると、該障害回復応答データを受信する（ステップＳ１４５）。スケジュール管理部１５は、ジョブ情報テーブル２１を参照して、上記別のジョブの“状態”が『障害回復待ち』かどうかチェックする（ステップＳ１４６）。このチェックの結果、上記別のジョブの“状態”が『障害回復待ち』であれば（ステップＳ１４６でYES）、障害回復管理部１９は、該当する論理ボリュームが現に使用されているかどうかチェックする（ステップＳ１４７）。そして、障害回復管理部１９が、該当する論理ボリュームが現に使用されていると判別した場合には（ステップＳ１４７でYES）、スケジュール管理部１５は、ジョブ情報テーブル２１中の上記別のジョブの“状態”を、『スケジュール待ち』に変更する（ステップＳ１４８）。

次に、ステップＳ１４６乃至ステップＳ１４８で示す処理動作が、ジョブ情報テーブル２１中の全部のレコード（論理ボリューム用レコード）について実行されたかどうかチェックする（ステップＳ１４９）。このチェックの結果、上記全部の論理ボリューム用レコードについて実行されてなければ（ステップＳ１４９でNO）、ステップＳ１４６で示した処理動作に復帰する。一方、上記チェックの結果、上記全部の論理ボリューム用レコードについて実行されていれば（ステップＳ１４９でYES）、障害情報管理部１９は、障害情報テーブル２３から該当する論理ボリューム用レコード（即ち、障害が発生していない、ジョブ実行のために現に使用されている論理ボリューム用レコード）を削除する処理を行う（ステップＳ１５０）。これにより、一連の処理動作が終了する。

上記検索の結果、上記論理ボリューム用レコードが存在していれば（ステップＳ１４２でYES）、直ちに一連の処理動作が終了する。また、上記別のジョブの“状態”が『障害回復待ち』でない場合（ステップＳ１４６でNO）や、障害回復管理部１９が、該当する論理ボリュームが現に使用されていないと判別した場合には（ステップＳ１４７でNO）、ステップＳ１４９で示した処理動作に移行する。

図１４は、図１に記載の情報処理システムにおいて、業務サーバ５の実行制御部３３が行う処理動作を示すフローチャートである。

図１４において、クライアント１から図６で示したようなジョブ実行要求データが送信されてくると、業務サーバ５の実行制御部３３は、該ジョブ実行要求データを受信し（ステップＳ１６１）、該ジョブ実行要求データに基づいてジョブを実行する（ステップＳ１６２）。即ち、実行制御部３３は、クライアント１側の実行制御部１７から送信された命令(ジョブ実行要求データ）を解析することにより、その解析結果に基づき、ストレージ装置７に対し、ジョブ実行の命令を発行する。

次に、実行制御部３３は、ストレージ装置７における上記ジョブの“実行結果”が『正常終了』かどうか判別する（ステップＳ１６３）。この判別の結果『正常終了』でなければ（ステップＳ１６３でNO）、実行制御部３３は、管理サーバ３に対し、管理サーバ３が持っている構成情報の提供を求めるべく、図１０で示したような構成情報取得要求データを送信する（ステップＳ１６４）。そして、この構成情報取得要求データを受信した管理サーバ３から図１１で示したような構成情報取得応答データが送信されてくると、実行制御部３３は、該構成情報取得応答データを受信する（ステップＳ１６５）。

次に、実行制御部３３は、上記受信した構成情報取得応答データ中から図５で示したような構成情報テーブル３１（３５）を参照することにより、ストレージ装置７を構成する物理ボリュームの何れかに障害が発生したかどうかチェックする（ステップＳ１６６）。このチェックの結果、物理ボリュームの何れかに障害が発生していることを判別すると（ステップＳ１６６でYES）、実行制御部３３は、該当する物理ボリューム（つまり、障害が発生している物理ボリューム）を使用する論理ボリューム名を、構成情報テーブル３１（３５）から検索し、該検索した論理ボリューム名を、図７（ｂ）で示したジョブ実行応答データ中の障害情報に追加登録する（ステップＳ１６７）。

次に、ステップＳ１６６、及びステップＳ１６７で示す処理動作が、構成情報テーブル３１（３５）中の全部のレコード（論理ボリューム用レコード）について実行されたかどうかチェックする（ステップＳ１６８）。このチェックの結果、上記全部の論理ボリューム用レコードについて実行されてなければ（ステップＳ１６８でNO）、ステップＳ１６６で示した処理動作に復帰する。一方、上記チェックの結果、上記全部の論理ボリューム用レコードについて実行されていれば（ステップＳ１６８でYES）、実行制御部３３は、ステップＳ１６７で生成したジョブ実行応答データを、クライアント１に対し送信して（ステップＳ１６９）、一連の処理動作が終了する。

上記構成情報テーブル３１（３５）を参照してチェックを行った結果、何れの物理ボリュームにも障害が発生していなければ（ステップＳ１６６でNO）、ステップＳ１６８で示した処理動作に移行する。また、ストレージ装置７における上記ジョブの“実行結果”が『正常終了』であれば（ステップＳ１６３でYES）、実行制御部３３は、図７（ａ）で示したようなジョブ実行応答データ中の“実行結果”に『正常終了』を追加登録したものを、ジョブ実行応答データとしてクライアント１に送信し（ステップＳ１６９）、一連の処理動作が終了する。

図１５は、図１に記載の情報処理システムにおいて、管理サーバ３の障害回復受付部２５が行う処理動作を示すフローチャートである。

図１５において、クライアント１から図８で示したような障害回復要求データが送信されてくると、管理サーバ３の障害回復受付部２５は、該障害回復要求データを受信する（ステップＳ１７１）。次に、障害回復受付部２５は、受付情報テーブル２９中に論理ボリューム用のレコードが有るか、それとも１個も無いかチェックする（ステップＳ１７２）。このチェックの結果、論理ボリューム用のレコードが有ると判別すると（ステップＳ１７２でYES）、障害回復受付部２５は、上記障害回復要求データ中に設定されている論理ボリューム用のレコードが、受付情報テーブル２９中に有るかどうかチェックする（ステップＳ１７３）。上記チェックの結果、上記論理ボリューム用のレコードが受付情報テーブル２９中にあれば（ステップＳ１７４でYES）、障害回復受付部２５は、受付情報テーブル２９中の上記論理ボリューム用のレコードに、上記論理ボリュームについて障害回復の通知を要求している各々のクライアント（１）の宛て先情報（ＩＰアドレス情報と、ポート番号情報）（即ち、クライアント情報）を追加登録する（ステップＳ１７５）。これにより、一連の処理動作が終了する。

受付情報テーブル２９をチェックした結果、上記論理ボリューム用のレコードが受付情報テーブル２９中になければ（ステップＳ１７４でNO）、障害回復受付部２５は、上記論理ボリューム用のレコード（上述したクライアント情報が含まれている）を、受付情報テーブル２９中に登録し（ステップＳ１７６）、一連の処理動作が終了する。

障害回復受付部２５が、受付情報テーブル２９をチェックした結果、論理ボリューム用のレコードが１個も無いことを判別すると（ステップＳ１７２でNO）、障害回復受付部２５は、クライアント１から受信した上記障害回復要求データに含まれる論理ボリューム名（論理ボリューム用のレコード）を、受付情報テーブル２９に登録する（ステップＳ１７７）。そして、障害回復管理部２７を起動した後（ステップＳ１７８）、一連の処理動作が終了する。

図１６は、図１に記載の情報処理システムにおいて、管理サーバ３の障害回復管理部２７が行う処理動作を示すフローチャートである。

既述のように、管理サーバ３の障害回復管理部２７は、障害回復受付部２５によって起動される。図１６において、障害回復管理部２７は、ストレージ装置７に対し、図５で示したような内容の構成情報の取得を要求する（ステップＳ１８１）。この要求に応じてストレージ装置７から構成情報が送信されてくると、障害回復管理部２７は、該構成情報を受信する。そして、障害回復受付部２５から通知された論理ボリュームが使用する物理ボリュームを、上記構成情報を利用して検索する（ステップＳ１８２）。次に、上記検索した物理ボリュームについて障害が発生しているかどうかチェックする（ステップＳ１８３）。このチェックの結果、上記検索した物理ボリュームに障害が発生していなければ（ステップＳ１８３でNO）、該物理ボリュームを使用する、受付情報テーブル２９中の論理ボリューム用のレコードに登録されている各々のクライアント（１）に対し、障害回復管理部２７は、図９で示したような障害回復応答データを夫々送信する（ステップＳ１８４）。次に、受付情報テーブル２９から上記論理ボリュームに係わる論理ボリューム用のレコードを削除する（ステップＳ１８５）。

次に、ステップＳ１８２乃至ステップＳ１８５で示す処理動作が、受付情報テーブル２９中の全部のレコード（論理ボリューム用レコード）について実行されたかどうかチェックする（ステップＳ１８６）。このチェックの結果、上記全部の論理ボリューム用レコードについて実行されてなければ（ステップＳ１８６でNO）、ステップＳ１８２で示した処理動作に復帰する。一方、上記チェックの結果、上記全部の論理ボリューム用レコードについて実行されていれば（ステップＳ１８６でYES）、障害回復管理部２７は、一定時間の待機状態を経てから（ステップＳ１８７）、受付情報テーブル２９中に論理ボリューム用のレコードが有るかどうかチェックする（ステップＳ１８８）。このチェックの結果、論理ボリューム用のレコードが有れば（ステップＳ１８８でYES）、ステップＳ１８１で示した処理動作に復帰する。一方、上記チェックの結果、受付情報テーブル２９中に論理ボリューム用のレコードが無ければ（ステップＳ１８８でNO）、一連の処理動作が終了する。

なお、上記検索した物理ボリュームに障害が発生していれば（ステップＳ１８３でYES）、直ちにステップＳ１８６で示した処理動作に移行する。

以上、本発明の好適な実施形態を説明したが、これは本発明の説明のための例示であって、本発明の範囲をこの実施形態にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実施することが可能である。

本発明の一実施形態に係るジョブスケジュール方式が適用される情報処理システムの全体構成を示すブロック図。 図１に記載したクライアントが備えるジョブ情報テーブルの一例を示す説明図。 図１に記載したクライアントが備える障害情報テーブルの一例を示す説明図。 図１に記載した管理サーバが備える受付情報テーブルの一例を示す説明図。 図１に記載した管理サーバが備える構成情報テーブル、及び図１に記載の業務サーバが備える構成情報テーブルの一例を示す説明図。 図１に記載した情報処理システムにおいて、クライアントの実行制御部から業務サーバ（の実行制御部）へ送信されるジョブ実行要求データの一例を示す説明図。 図１に記載した情報処理システムにおいて、業務サーバ（の実行制御部）からクライアントの実行制御部へ送信されるジョブ実行応答データの一例を示す説明図。 図１に記載した情報処理システムにおいて、クライアントの障害回復管理部から管理サーバ（の障害回復受付部）へ送信される障害回復要求データの一例を示す説明図。 図１に記載した情報処理システムにおいて、管理サーバ（の障害回復管理部）からクライアントの障害回復管理部へ送信される障害回復応答データの一例を示す説明図。 図１に記載した情報処理システムにおいて、業務サーバの実行制御部から管理サーバ（の障害回復管理部）へ送信される構成情報取得要求データの一例を示す説明図。 図１に記載した情報処理システムにおいて、管理サーバ（の障害回復管理部）から業務サーバの実行制御部へ送信される構成情報取得応答データの一例を示す説明図。 図１に記載した情報処理システムにおいて、主にクライアントの実行制御部が行う処理動作を示すフローチャート。 図１に記載した情報処理システムにおいて、クライアントの障害回復管理部が行う処理動作を示すフローチャート。 図１に記載した情報処理システムにおいて、業務サーバの実行制御部が行う処理動作を示すフローチャート。 図１に記載した情報処理システムにおいて、管理サーバの障害回復受付部が行う処理動作を示すフローチャート。 図１に記載した情報処理システムにおいて、管理サーバの障害回復管理部が行う処理動作を示すフローチャート。

符号の説明

１ クライアントマシン（クライアント）
３ 管理サーバ
５ 業務サーバ
７ ストレージ装置
９ ＬＡＮ（Local Area Network）
１１ ＳＡＮ（Storage Area Network）
１３ スケジュール登録部
１５ スケジュール管理部
１７、３３ 実行制御部
１９、２７ 障害回復管理部
２１ ジョブ情報テーブル
２３ 障害情報テーブル
２５ 障害回復受付部
２９ 受付情報テーブル
３１、３５ 構成情報テーブル
３７、３９、４１、４３ 物理ボリューム
４５、４７、４９ 論理ボリューム

Claims (11)

1. 複数の物理ボリュームを有し、各物理ボリュームが複数の論理ボリュームに夫々割り当てられて使用されるストレージ装置と、前記ストレージ装置に対し、ジョブの実行を指令する情報処理装置とを備え、
   前記各論理ボリュームに障害が発生したかどうか検知する障害検知部と、
   前記情報処理装置から或るジョブの実行が指令されたことに起因して、前記障害検知部が該ジョブの実行に使用する論理ボリュームに障害が発生したことを検知した場合に、該論理ボリュームが含む物理ボリュームが割り当てられた別の論理ボリュームを検索する論理ボリューム検索部と、
   を有するジョブの実行制御システム。
2. 請求項１記載のジョブの実行制御システムにおいて、
   前記論理ボリューム検索部が検索した論理ボリュームを使用する別のジョブがあるかどうか検索するジョブ検索部と、
   前記ジョブ検索部が別のジョブを検索した場合に、該別のジョブの実行抑止を、前記情報処理装置に通知する実行抑止通知部と、
   を更に有するジョブの実行制御システム。
3. 請求項１記載のジョブの実行制御システムにおいて、
   前記論理ボリュームに発生した障害が回復したかどうか検知する障害回復検知部と、
   前記障害回復検知部が前記論理ボリュームの障害回復を検知した場合に、前記別のジョブの実行抑止解除を前記情報処理装置に通知する実行抑止解除通知部と、
   を更に有するジョブの実行制御システム。
4. 請求項１記載のジョブの実行制御システムにおいて、
   前記情報処理装置が、クライアント及びサーバを含み、前記ジョブ実行の指令が、クライアントからサーバを通じてストレージ装置へ送られるジョブの実行制御システム。
5. 請求項４記載のジョブの実行制御システムにおいて、
   前記障害検知部、前記ジョブ検索部、及び前記実行抑止通知部は、何れもサーバに備えられるジョブの実行制御システム。
6. 請求項５記載のジョブの実行制御システムにおいて、
   前記実行抑止通知部からの通知が、クライアントに送られるジョブの実行制御システム。
7. 請求項４記載のジョブの実行制御システムにおいて、
   前記障害回復検知部、及び前記実行抑止解除通知部が、サーバに備えられるジョブの実行制御システム。
8. 請求項７記載のジョブの実行制御システムにおいて、
   前記実行抑止解除通知部からの通知が、クライアントに送られるジョブの実行制御システム。
9. 複数の物理ボリュームを有し、各物理ボリュームが複数の論理ボリュームに夫々割り当てられて使用されるストレージ装置と、前記ストレージ装置に対し、ジョブの実行を指令する情報処理装置とを備え、
   前記各論理ボリュームに障害が発生したかどうか検知するステップと、
   前記情報処理装置から或るジョブの実行が指令されたことに起因して、前記障害検知のステップにおいて、該ジョブの実行に使用する論理ボリュームに障害が発生したことが検知された場合に、該論理ボリュームが含む物理ボリュームが割り当てられた別の論理ボリュームを検索するステップと、
   を有するジョブの実行制御方法。
10. 請求項９記載のジョブの実行制御方法において、
    前記論理ボリューム検索のステップにおいて、検索された論理ボリュームを使用する別のジョブがあるかどうか検索するステップと、
    前記ジョブ検索のステップにおいて、別のジョブが検索された場合に、該別のジョブの実行抑止を、前記情報処理装置に通知するステップと、
    を更に有するジョブの実行制御方法。
11. 請求項９記載のジョブの実行制御方法において、
    前記論理ボリュームに発生した障害が回復したかどうか検知するステップと、
    前記障害回復検知のステップにおいて、前記論理ボリュームの障害回復が検知された場合に、前記別のジョブの実行抑止解除を前記情報処理装置に通知するステップと、
    を更に有するジョブの実行制御方法。

Images