以下、本発明を実施するための最良の形態を図面を参照して説明する。
実施の形態1.
図1は、本発明の第1の実施の形態を示すブロック図である。第1の実施の形態における障害復旧システムは、エージェント装置20と、マネージャ装置30とを備える。エージェント装置20は、復旧対象装置(図1に示すサービス実行手段10)の動作状態を検出するとともに、マネージャ装置30が決定した復旧処理コマンドを復旧対象装置に対して実行する。マネージャ装置30は、エージェント装置20が検出した復旧対象装置の動作状態に基づいて復旧処理コマンドを決定する。マネージャ装置30とエージェント装置20は、通信ネットワーク(図示せず。)によって接続される。図1では、マネージャ装置30とエージェント装置20を1台ずつ図示しているが、マネージャ装置30に対して複数台のエージェント装置20が接続されていてもよい。
エージェント装置20は、動作状態検出手段1と、コマンド実行手段5とを備える。また、エージェント装置20は、サービス実行手段10に接続される。
サービス実行手段10は、Webサービスや業務サービスといった情報通信サービスを提供する情報処理システムである。サービス実行手段10は、1台の情報処理装置からなる構成であってもよいし、複数台の情報処理装置が接続されたネットワークシステムであってもよい。また、図1では、エージェント装置20がサービス実行手段10を含んでいるように図示しているが、エージェント装置20とサービス実行手段10とが通信ネットワークを介して接続される構成であってもよい。
動作状態検出手段1は、サービス実行手段10の動作状態を検出し、対処方法検索手段3に出力(送信)する。検出する動作状態には、サービス実行手段10の起動/停止状態、アプリケーションプログラムの起動/停止状態、アプリケーションプログラムのエラー状態、CPU状態、メモリ状態、ディスク状態など各種の状態がある。サービス実行手段10の動作状態を検出する方法としては、サービス実行手段10にSNMP(Simple Network Management Protocol )エージェントを常駐させ、動作状態検出手段1が定期的にSNMPリクエストをSNMPエージェントへ送信することによって検出する方法や、サービス実行手段10にSNMPトラップの設定を行い、SNMPトラップイベントが発生したときにそのイベント(動作状態)を受信する方法など、任意の方法を使用することができる。
コマンド実行手段5は、マネージャ装置30(具体的には、後述する対話制御手段4)から復旧処理コマンドの情報を受信し、サービス実行手段10上でその復旧処理コマンドを実行する。
マネージャ装置30は、ルール蓄積手段2と、対処方法検索手段3と、対話制御手段4と、ユーザ指定ルール蓄積手段6と、共通条件制御手段7とを備える。
ルール蓄積手段2は、障害対処ルールを蓄積する記憶装置である。既に説明したように、障害対処ルールは、障害が発生したと判定するための条件式と、その条件式を満足する状態を検出したときにサービス実行手段10に対して実行する復旧処理コマンドの情報とを含む。条件式としては、障害が発生したとみなされるサービス実行手段10の状態または障害発生の前兆とみなされるサービス実行手段10の状態が記述される。条件式として記述される状態の具体例として、例えば、サービス実行手段10として使用される情報処理装置の処理負荷、メモリ使用量、エラー発生状況等が挙げられる。以下の説明では、説明を簡単にするために、条件式に記述される状態を、「状態A」、「状態B」等のように記号で示して説明する。復旧処理コマンドは、条件式が満たされる状態となったときに、障害からの復旧または障害の回避のために使われるコマンドである。
本発明においても、既に説明した場合と同様に、条件式を複数の状態のAND(論理積)によって表してもよい。図22等に示す場合と同様に、ここでは、論理積を“&”記号によって表すこととする。すなわち、「状態A&状態B」という条件式は、「状態Aおよび状態Bが共に真である(状態Aおよび状態Bがともに検出されている)」ことを意味し、その条件式が満たされたときに、その条件式に対応する復旧処理コマンドを実行することを意味する。なお、複数の状態の論理和を用いて条件式を記述することも可能である。しかし、そのような条件式を含む障害対処ルールは、実質的に複数の障害対処ルールを含んでいるので、論理和を用いない複数の障害対処ルールに分けることができる。例えば、「状態Aまたは状態Bが発生しているならば対処手順Aを実行する。」という障害対処ルールは、「状態Aが発生しているならば対処手順Aを実行する。」、「状態Bが発生しているならば対処手順Aを実行する。」という論理和を用いない2つの障害対処ルールに分けられる。本発明では、ルール蓄積手段2は、論理和を用いずに条件式が記述された障害対処ルールを記憶しているものとする。また、本実施の形態では、ある状態が発生していないこと(ある状態の否定)を、図23等に示す場合と同様に“NOT”で示すことにする。
対処方法検索手段3は、動作状態検出手段1によって検出されたサービス実行手段10の動作状態の情報を動作状態検出手段1から受信する。そして、対処方法検索手段3は、条件式がその動作状態に合致している障害対処ルールをルール蓄積手段2から検索し、その障害対処ルール中の復旧処理コマンドの情報を対話制御手段4に出力する。
対話制御手段4は、例えば、ディスプレイ装置や入力デバイス(例えば、キーボード等)を備え、対処方法検索手段3の出力情報が示す復旧処理コマンドを実行するか否かを、ユーザ(例えば、サービス実行手段10および障害復旧システムの管理者)との対話により決定する。すなわち、対話制御手段4は、その復旧処理コマンドを実行するか否かの決定を促すGUIをディスプレイ装置(図示せず。)に表示し、実行する旨の指示が入力された場合、復旧処理コマンドを実行することを決定し、その復旧処理コマンドを示す情報をコマンド実行手段5に出力(送信)する。
また、対話制御手段4は、ユーザが作成したルールを入力し、ユーザ指定ルール蓄積手段6に記憶させる。ユーザが作成するルールも、障害対処ルールと同様の形式で記述され、条件式および復旧処理コマンドの情報を対応付けた形式になっている。ユーザが作成したルールは、ユーザ指定ルール蓄積手段6に記憶され、そのルールに基づいて、ルール蓄積手段2に記憶される障害対策ルールが生成される。従って、ルール蓄積手段2が記憶する障害対処ルールは、ユーザが作成したルールそのものではない。そこで、ユーザが作成したルールを、ユーザ指定ルールと記し、ルール蓄積手段2が記憶する障害対処ルールと区別する。対話制御手段4は、ユーザの操作に応じて、ユーザ指定ルール蓄積手段6に新たなユーザ指定ルールを追加記憶させたり、既にユーザ指定ルール蓄積手段6が記憶しているユーザ指定ルールを編集したりする。また、対話制御手段4は、ユーザの操作に応じて、ユーザ指定ルール蓄積手段6が記憶しているユーザ指定ルールの削除も行う。
ユーザ指定ルール蓄積手段6は、ユーザ指定ルールを記憶する。ユーザ指定ルールは、ユーザが作成したルールそのものである。従って、図22(b)で説明したような、実際にはユーザの意図に反する復旧処理コマンドの情報を導出してしまうようなルールになっている可能性が高い。
共通条件制御手段7は、ユーザ指定ルール蓄積手段6に新たなユーザ指定ルールが記憶された場合(新たにユーザ指定ルールが追加された場合や、ユーザ指定ルールの編集が行われた場合)、ルール蓄積手段2が記憶している障害対処ルール全体を消去する。そして、共通条件制御手段7は、ユーザ指定ルール蓄積手段6に記憶されているユーザ指定ルールに基づいて、矛盾のない障害対処ルールの集合を作成し、その障害対処ルールの集合をルール蓄積手段2に記憶させる。ユーザ指定ルールに基づいて障害対処ルールを作成する処理については後述する。なお、ここで「矛盾のない」とは、複数の障害対処ルールの条件式が同時に成立してしまうことがないことを意味する。
動作状態検出手段1およびコマンド実行手段5は、例えば、コンピュータと障害復旧プログラムによって実現することができる。この障害復旧プログラムは、コンピュータ(エージェント装置20)の立ち上げ時等にコンピュータに読み取られ、コンピュータが障害復旧プログラムに従って動作することにより、コンピュータが動作状態検出手段1およびコマンド実行手段5として機能する。障害復旧プログラムは、エージェント装置20が備える磁気ディスクや半導体メモリ等のコンピュータ可読記録媒体に予め記録される。
対処方法検索手段3、対話制御手段4、および共通条件制御手段7も、例えば、コンピュータと障害復旧プログラムによって実現することができる。この障害復旧プログラムは、コンピュータ(マネージャ装置30)の立ち上げ時等にコンピュータに読み取られ、コンピュータが障害復旧プログラムに従って動作することにより、コンピュータが対処方法検索手段3、対話制御手段4、および共通条件制御手段7として機能する。障害復旧プログラムは、マネージャ装置30が備える磁気ディスクや半導体メモリ等のコンピュータ可読記録媒体に予め記録される。また、ルール蓄積手段2およびユーザ指定ルール蓄積手段6は、例えば、マネージャ装置30が備える記憶装置によって実現される。
また、動作状態検出手段1、コマンド実行手段5、対処方法検索手段3、対話制御手段4、および共通条件制御手段7をそれぞれハードウェア装置として実現してもよい。
次に、動作について説明する。
図2は、ユーザ指定ルールが修正されたときにおけるマネージャ装置30(主に共通条件制御手段7)による処理経過の例を示すフローチャートである。また、図3は、ユーザ指定ルールに基づく矛盾解消の具体例を示す説明図である。本例では、ユーザ指定ルール蓄積手段6には、初期状態として、図3に示すユーザ指定ルール501が記憶されているものとする。
まず、対話制御手段4は、ユーザの操作に応じて、ユーザ指定ルール蓄積手段6内のユーザ指定ルールに対して追加や変更等を行う(ステップS211)。ここでは、対話制御手段4は、ユーザの操作に応じて、図3に示すユーザ指定ルール502をユーザ指定ルール蓄積手段6に追加記憶させる。この結果、ユーザ指定ルール蓄積手段6は、ユーザ指定ルール501,502を記憶する。
ユーザ指定ルール蓄積手段6が記憶するユーザ指定ルールが変更されると、共通条件制御手段7は、ユーザ指定ルール蓄積手段6が記憶するユーザ指定ルールのうち、条件式に共通部分を有するユーザ指定ルールの有無を判定する(ステップS212)。ステップS212において、条件式に共通部分を有するユーザ指定ルールがないと判定した場合(ステップS212におけるNo)、共通条件制御手段7は、ユーザ指定ルール蓄積手段6が記憶しているユーザ指定ルールを障害対処ルールとしてルール蓄積手段2に記憶させる(ステップS214)。このとき、共通条件制御手段7は、ステップS212においてNoと判定した後、ルール蓄積手段2の記憶内容(障害対処ルール)を全て削除してからステップS214の処理を実行する。
一方、ステップS212において、条件式に共通部分を有するユーザ指定ルールがあると判定した場合(ステップS212におけるYes)、共通条件制御手段7は、そのユーザ指定ルールを収集して、そのユーザ指定ルール間に矛盾がなくなるように、収集したユーザ指定ルールの条件式を変更する(ステップS213)。そして、共通条件制御手段7は、条件式を変更したユーザ指定ルールを障害対処ルールとしてルール蓄積手段2に記憶させる(ステップS214)。なお、このとき、条件式に他のユーザ指定ルールとの共通部分がないユーザ指定ルールが存在していた場合、共通条件制御手段7は、そのユーザ指定ルールについては、そのまま障害対処ルールとしてルール蓄積手段2に記憶させる。
図4は、ステップS213の処理(ユーザ指定ルール間に矛盾がなくなるように、ユーザ指定ルールの条件式を変更することによって障害対処ルールを作成する処理)の処理経過の一例を示すフローチャートである。共通条件制御手段7は、まず、ルール蓄積手段2に記憶された障害対処ルールを全て削除する(ステップS301)。次に、共通条件制御手段7は、ユーザ指定ルール蓄積手段6が記憶するユーザ指定ルールのうち、条件式に共通部分を有するユーザ指定ルールを収集する(ステップS302)。
共通条件制御手段7は、ステップS302で収集したユーザ指定ルールから、条件式の変更検証対象ルールを1つずつ選択する。以下、条件式の変更検証対象となるルールを第1ルールと記す。また、共通条件制御手段7は、第1ルールの条件式を変更するか否かを、他のユーザ指定ルールの条件式と比較しながら決定していく。この他のユーザ指定ルールを第2ルールと記す。第2ルールも1つずつ順次選択される。
共通条件制御手段7は、ステップS302の後、収集したユーザ指定ルールのうち、第1ルール(条件式の変更検証対象となるルール)として選択されていないユーザ指定ルールがあるか否かを判定する(ステップS303)。第1ルールとして選択されていないユーザ指定ルールがなければ(ステップS303におけるNo)、ステップS213(図2参照。)の処理を終了する。収集したユーザ指定ルール中に未だ第1ルールとして選択されていないユーザ指定ルールがあれば、そのユーザ指定ルールの中から1つを選択して第1ルールとする(ステップS304)。ステップS302で収集されたユーザ指定ルールのうち、ステップS304で選択された第1ルール以外の全ユーザ指定ルールが順次第2ルールとして選択される。
共通条件制御手段7は、ステップS304の後、ステップS302で収集されたユーザ指定ルールであって、ステップS304で選択された第1ルール以外のユーザ指定ルールの中に、第2ルールとして選択されていないユーザ指定ルールがあるか否かを判定する(ステップS305)。第2ルールとして選択されていないユーザ指定ルールがなければ(ステップS305におけるNo)、ステップS303に移行し、ステップS303以降の処理を繰り返す。第2ルールとして選択されていないユーザ指定ルールがあれば(ステップS305におけるYes)、そのユーザ指定ルールの中から1つを選択して第2ルールとする(ステップS306)。
共通条件制御手段7は、第1ルールと第2ルールとが同時に成立し得るか否かを判定する(ステップS307)。ステップS307では、任意の状態Pについて、第1ルールと第2ルールのいずれかの条件式に「状態Pになっていること」が条件として記述され、他方の条件式に「状態Pになっていないこと」が条件として記述されているならば、第1ルールと第2ルールとが同時に成立し得ないと判定すればよい。また、そうでなければ、第1ルールと第2ルールとが同時に成立し得ると判定すればよい。例えば、一方の条件式に「・・・&状態P&・・・」と記述され、他方の条件式に「・・・&(NOT状態P)&・・・」と記述されていれば、共通条件制御手段7は、第1ルールと第2ルールとが同時に成立し得ないと判定する。第1ルールと第2ルールとが同時に成立し得ないと判定した場合(ステップS307におけるNo)、ステップS305に移行し、ステップS305以降の処理を繰り返す。
また、第1ルールと第2ルールとが同時に成立し得ると判定した場合(ステップS307におけるYes)、共通条件制御手段7は、第2ルールの条件式内の共通部分以外の条件を抽出し、その否定を第1ルールの条件式に追加する(ステップS308)。このとき、共通条件制御手段7は、第1ルールの条件式に記述されていた条件式と、第2ルールから抽出した条件の否定とを“&”で結べばよい。すなわち、第1ルールの条件式に記述されていた条件式と、第2ルールから抽出した条件の否定との論理積を、第1ルールの新たな条件式とすればよい。
共通条件制御手段7が、第2ルールの条件式内の共通部分以外の条件を抽出し、その否定を第1ルールの条件式に追加する(ステップS308)ことによって、第1ルールと第2ルールとは同時に成立し得ない(第1ルールの条件式と第2ルールの条件式とが同時に満たされ得ない)ことになる。このように複数のルールが同時に成立しないことを、各ルールが「一意に識別される」と表現することがある。
共通部分を有するユーザ指定ルールのグループが複数存在した場合、それらの各グループについて、図4に示すステップS301以降の処理を行えばよい。そして、各グループについて、ステップS301以降の処理が終了した後、ステップS214に移行すればよい。
なお、図2および図4の処理を行ったとしても、共通条件制御手段7は、ユーザ指定ルール蓄積手段6に記憶されているユーザ指定ルール自体については書き換えない。共通条件制御手段7は、ステップS302で収集したユーザ指定ルールをバッファ等(図示せず。)に記憶させ、そのバッファ等において条件式の変更などを行う。従って、ステップS211以降、ユーザ指定ルール蓄積手段6に記憶されているユーザ指定ルールの内容は変わらない。ただし、ユーザの操作に応じて、再度ステップS211の処理が行われれば、当然に、ユーザ指定ルール蓄積手段6に記憶されているユーザ指定ルールの内容は変更される。
図3に示すユーザ指定ルールを用いて、以上の処理を説明する。ユーザ指定ルール502が追加された(ステップS211)後、共通条件制御手段7は、ユーザ指定ルール蓄積手段6が記憶するユーザ指定ルールのうち、条件式に共通部分を有するユーザ指定ルールの有無を判定する(ステップS212)。図3に示すユーザ指定ルール501,502を参照すると、条件式において“状態A & 状態B”の部分が共通する(ステップS212におけるYes)。
その結果、共通条件制御手段7は、ステップS213の処理を開始する。具体的には、まず、ルール蓄積手段2の記憶内容を削除する(ステップS301)。そして、共通条件制御手段7は、ユーザ指定ルール蓄積手段6から、条件式に共通部分(本例では、“状態A & 状態B”)を有するユーザ指定ルール501,502を収集する。この時点で、ユーザ指定ルール501,502は、いずれも第1ルールとして選択されていない。よって、ステップS303の判定後、ステップS304に移行する。ステップS304では、共通条件制御手段7は、第1ルールとして未だ選択されていないユーザ指定ルール501,502の中から1つを選択する(ここでは、ユーザ指定ルール501を選択するものとする。)。この時点で、ユーザ指定ルール502は第2ルールとして選択されていない。よって、ステップS305の判定後、ステップS306に移行する。ステップS306では、共通条件制御手段7は、ユーザ指定ルール502を第2ルールとして選択する。
次に、共通条件制御手段7は、第1ルールと第2ルールとが同時に成立し得るか否かを判定する(ステップS307)。第1ルール(ここでは、ユーザ指定ルール501)および第2ルール(ここでは、ユーザ指定ルール502)との間には、いずれかの条件式に「状態Pになっていること」が条件として記述され、他方の条件式に「状態Pになっていないこと」が条件として記述されているという関係は成立していない(状態Pは、任意の障害発生状態)。そのため、第1ルールと第2ルールとが同時に成立し得ると判定し、ステップS308に移行する。ステップS308では、共通条件制御手段7は、第2ルールの条件式内の共通部分以外の条件を抽出する。共通部分は“状態A & 状態B”であるので、それ以外の条件である“状態C”を第2ルールから抽出する。そして、共通条件制御手段7は、その否定である“(NOT状態C)”と、第1ルールの条件式に記述されていた条件式“状態A & 状態B”とを“&”で結び、第1ルールの条件式を“状態A & 状態B & (NOT状態C)”とする。この変更後のユーザ指定ルールを、図3では、ユーザ指定ルール501aとして示している。これまでユーザ指定ルールとして501と記していたユーザ指定ルールを、以降、ユーザ指定ルール501aと記す。
続いて、ステップS305に移行したときには、第2ルールとして選択されていないユーザ指定ルールは存在していない(なお、第1ルールとして選択されているユーザ指定ルールは、第2ルールとして選択されない。)。よって、ステップS303に移行する。このとき、図3に示すユーザ指定ルール502は、未だ第1ルールとして選択されていない。よって、ステップS303からステップS304に移行し、共通条件制御手段7は、ユーザ指定ルール502を第1ルールとして選択する。この時点で、ユーザ指定ルール501aは第2ルールとして選択されていない。よって、ステップS305の判定後、ステップS306に移行する。ステップS306では、共通条件制御手段7は、ユーザ指定ルール501a(図3参照。)を第2ルールとして選択する。
次に、共通条件制御手段7は、第1ルールと第2ルールとが同時に成立し得るか否かを判定する(ステップS307)。第1ルール(ここでは、ユーザ指定ルール502)および第2ルール(ここでは、ユーザ指定ルール501a)を参照すると、一方の条件式には、“状態C”が記述され、他方の条件式には“(NOT状態C)”が記述されている。よって、共通条件制御手段7は、第1ルールと第2ルールとが同時に成立し得ないと判定し(ステップS307におけるNo)、ステップS305に移行する。
続いて、ステップS305に移行したときには、第2ルールとして選択されていないユーザ指定ルールは存在していない。よって、ステップS303に移行する。この時点で、第1ルールとして選択されていないユーザ指定ルールは存在しないので(ステップS303におけるNo)、処理(図2に示すステップS213の処理)を終了する。この結果、本例では、ユーザ指定ルール502は変更されない。ステップS213に続く、ステップS214(図2参照。)では、共通条件制御手段7は、図3に示すユーザ指定ルール501a,502を、障害対処ルールとしてルール蓄積手段2に記憶させる。
ユーザが作成したユーザ指定ルール501,502は、矛盾する状態(条件式が同時に成立してしまうことがある状態)であったが、図2および図4に示す処理を実行することにより、ユーザ指定ルール501,502という集合は、ユーザ指定ルール501a,502(図3参照。)という集合に修正され、ユーザ指定ルール501a,502が障害対処ルールとしてルール蓄積手段2に記憶される。よって、ユーザが、自身の作成したユーザ指定ルールに対する検証を行わなくても、矛盾のない障害対処ルールを作成することができ、ユーザの負担を軽減することができる。
図3では、条件式に共通部分を有するユーザ指定ルールが2つある場合を示したが、そのようなユーザルールが3つ以上ある場合でも、図2および図4に示す処理により、矛盾のない障害対処ルールを作成することができる。図5は、条件式に共通部分を有するユーザ指定ルールが3つある場合における矛盾解消の具体例を示す説明図である。ステップS301までの処理は、既に説明した場合と同様である。ステップS302では、共通条件制御手段7は、図5に示すユーザ指定ルール501〜503を収集する。
続く処理(ステップS304)で、ユーザ指定ルール501を第1ルールとして選択したとする。また、ステップS306で、ユーザ指定ルール502を第2ルールとして選択したとする。ステップS307では、共通条件制御手段7は、第1ルールと第2ルールとが同時に成立し得るか否かを判定する。このとき、第1ルール(ここでは、ユーザ指定ルール501)および第2ルール(ここでは、ユーザ指定ルール502)との間には、いずれかの条件式に「状態Pになっていること」が条件として記述され、他方の条件式に「状態Pになっていないこと」が条件として記述されているという関係は成立していない。よって、第1ルールと第2ルールとが同時に成立し得ると判定し、ステップS308に移行する。ステップS308では、共通条件制御手段7は、第2ルールの条件式内の共通部分以外の条件を抽出する。共通部分は“状態A & 状態B”であるので、それ以外の条件である“状態C”を第2ルールから抽出する。そして、共通条件制御手段7は、その否定である“(NOT状態C)”と、第1ルールの条件式に記述されていた条件式“状態A & 状態B”とを“&”で結び、第1ルールの条件式を“状態A & 状態B & (NOT状態C)”とする。その後のステップS306で、ユーザ指定ルール503を第2ルールとして選択したとする。この場合も、ステップS307において、共通条件制御手段7は、第1ルールの条件式“状態A & 状態B & (NOT状態C)”と、第2ルールの条件式“状態A & 状態B & 状態D”とを参照し、第1ルールと第2ルールとが同時に成立し得ると判定する。そして、ステップS308では、共通条件制御手段7は、第2ルールの条件式内の共通部分以外の条件を抽出する。共通部分は“状態A & 状態B”であるので、それ以外の条件である“状態D”を第2ルールから抽出する。そして、共通条件制御手段7は、その否定である“(NOT状態D)”と、第1ルールの条件式に記述されていた条件式“状態A & 状態B & (NOT状態C)”とを“&”で結び、第1ルールの条件式を“状態A & 状態B & (NOT状態C) & (NOT状態D)”とする。この変更後のユーザ指定ルールを、図5では、ユーザ指定ルール501bとして示している。これまでユーザ指定ルールとして501と記していたユーザ指定ルールを、以降、ユーザ指定ルール501bと記す。
次に、ユーザ指定ルール502を第1ルールとして選択したとする。また、ステップS306で、ユーザ指定ルール501bを第2ルールとして選択したとする。すると、第1ルールの条件式の中には“状態C”が記述され、第2ルールの条件式には“(NOT状態C)”が記述されている。よって、共通条件制御手段7は、第1ルールと第2ルールとが同時に成立し得ないと判定し、ステップS305に移行する。次に、共通条件制御手段7は、ユーザ指定ルール503を第2ルールとして選択する。このとき、第1ルール(ここでは、ユーザ指定ルール502)および第2ルール(ここでは、ユーザ指定ルール503)との間には、いずれかの条件式に「状態Pになっていること」が条件として記述され、他方の条件式に「状態Pになっていないこと」が条件として記述されているという関係は成立していない(状態Pは、任意の障害発生状態)。よって、第1ルールと第2ルールとが同時に成立し得ると判定し、ステップS308に移行する。ステップS308では、共通条件制御手段7は、第2ルールの条件式内の共通部分以外の条件を抽出する。共通部分は“状態A & 状態B”であるので、それ以外の条件である“状態D”を第2ルールから抽出する。そして、共通条件制御手段7は、その否定である“(NOT状態D)”と、第1ルールの条件式に記述されていた条件式“状態A & 状態B & 状態C”とを“&”で結び、第1ルールの条件式を“状態A & 状態B & 状態C & (NOT状態D)”とする。この変更後のユーザ指定ルールを、図5では、ユーザ指定ルール502bとして示している。これまでユーザ指定ルールとして502と記していたユーザ指定ルールを、以降、ユーザ指定ルール502bと記す。
次に、ユーザ指定ルール503を第1ルールとして選択したとする。また、ステップS306で、ユーザ指定ルール501bを第2ルールとして選択したとする。すると、第1ルールの条件式の中には“状態D”が記述され、第2ルールの条件式には“(NOT状態D)”が記述されている。よって、共通条件制御手段7は、第1ルールと第2ルールとが同時に成立し得ないと判定し、ステップS305に移行する。次に、共通条件制御手段7は、ユーザ指定ルール502bを第2ルールとして選択したとする。この場合も、第1ルールの条件式の中には“状態D”が記述され、第2ルールの条件式には“(NOT状態D)”が記述されている。よって、共通条件制御手段7は、第1ルールと第2ルールとが同時に成立し得ないと判定し、ステップS305に移行する。従って、ユーザ指定ルール503の条件式は変更されない。共通条件制御手段7は、収集した3つのユーザ指定ルールをそれぞれ第1ルールとして選択したので、次にステップS303に移行したときにはNoと判定し、ステップS213(図2参照。)の処理を終了する。そして、ステップ214において、図5に示すユーザ指定ルール501b,502b,503を障害対処ルールとしてルール蓄積手段2に記憶させる。
障害復旧システムは、サービス実行手段10の状態を検出し、その状態と、以上のようにルール蓄積手段2に記憶された障害対処ルールとに基づいて復旧処理コマンドを決定し、サービス実行手段10に対し、その復旧処理コマンドを実行する。図6は、サービス実行手段10の状態検出から、復旧処理コマンド実行までの処理経過を示すフローチャートである。
動作状態検出手段1は、サービス実行手段10の動作状態を検出し、通信ネットワークを介して対処方法検索手段3に動作状態の情報を送信する(ステップS201)。対処方法検索手段3は、動作状態検出手段1から現在の動作状態の情報を受信し、ルール蓄積手段2に蓄積されている各障害対処ルールの中に、条件式が満たされている障害対処ルールがあるか否かを判定する(ステップS202)。サービス実行手段10の動作状態によっていずれの障害対処ルールの条件式も満たされていない場合(ステップS202におけるNo)、障害が発生していないものとしてステップS201に移行し、ステップS201移行の処理を繰り返す。
サービス実行手段10の動作状態によって条件式が満たされる障害対処ルールが存在する場合には(ステップS202におけるYes)、対処方法検索手段3は、障害発生とみなして、その障害対処ルールに含まれる復旧処理コマンドの情報を抽出し、その情報を対話制御手段4に出力する。対話制御手段4は、GUIによって、その復旧処理コマンドの情報を出力し、その復旧処理コマンドを実行するか否かの決定をユーザ(管理者)に促す(ステップS203)。復旧処理コマンドを実行しない旨が管理者によって入力された場合、ステップS201に移行し、ステップS201以降の処理を繰り返す。なお、ユーザに適切な判断を行わせるために、GUIと併せて、サービス実行手段10の動作状態や、その動作状態によって満たされた条件式の情報等を表示出力してもよい。また、特定の復旧処理コマンドについては、管理者に問い合わせることなく自動的に実行してよいという設定を対話制御手段4に対して施しておいてもよい。この場合、対話制御手段4は、その特定の復旧処理コマンドの情報が入力されると、その復旧処理コマンドを実行するか否かの決定を促すGUIを表示することなく、その特定の復旧処理コマンドの情報をコマンド実行手段5に送信する。
復旧処理コマンドを実行する旨が管理者によって入力された場合(ステップS203におけるYes)、対話制御手段4は、その復旧処理コマンドの情報をコマンド実行手段5に送信し、コマンド実行手段5はサービス実行手段10上でその復旧処理コマンドを実行する(ステップS204)。
例えば、図3に示すルール501a,502が障害対処ルールとしてルール蓄積手段2に記憶されているとする。この場合、動作状態検出手段1によって、状態A,B,Cのいずれもが発生している場合、障害対処ルール502の条件式が満たされる。従って、対処方法検索手段3は、障害対処ルール502における復旧処理コマンドの情報である「対処手順B」を対話制御手段4に出力する。対話制御手段4は、GUIによって「対処手順B」の実行可否の決定を管理者に促し、実行する旨の指示が入力されると、「対処手順B」という情報をコマンド実行手段5に送信する。そして、コマンド実行手段5は、対処手順Bを実行する。その結果、状態A,B,Cがいずれも発生してしまっているという障害が復旧または回避されることになる。
本実施の形態によれば、ユーザ指定ルールの修正(追加や変更等)の結果、条件式に共通部分を有するユーザ指定ルールが存在した場合、共通条件制御手段7が、ステップS301以降の処理を行い、矛盾がなくなるようにユーザ指定ルールの条件式を修正する。そして、共通条件制御手段7が、修正後のユーザ指定ルールを障害対処ルールとしてルール蓄積手段2に記憶させる。従って、ユーザ(管理者)にとって、自らが作成したユーザ指定ルールに対する無矛盾性検証、ユーザ指定ルールの変更等の負担が大幅に軽減される。
また、管理者は自らが意図したユーザ指定ルールを作成すれば、そのユーザ指定ルールに基づく矛盾のない障害対処ルールが作成される。そして、障害復旧システムが図6に示す処理を実行する際には、障害対処ルールが作成されていればよく、管理者が障害対処ルールの全てを理解している必要はない。よって、管理者の負担が軽減される。障害対処ルールは、ステップS308で条件が新たに追加されている場合があるので、必ずしも管理者にとって理解しやすい記述とはなっていない。例えば、図5に示す例では、条件式に“(NOT状態C) & (NOT状態D)”が追加されているが、この追加条件は、管理者自身が記述したものではない。このような条件追加が多く行われた障害対処ルールを管理者が参照しても、本来何を目的としたルールであったのかを理解することが困難となる。しかし、上記のように、管理者はそのような障害対処ルールを理解する必要がないので、負担が軽減される。
また、共通条件制御手段7は、ステップS302で収集したユーザ指定ルールをバッファ等(図示せず。)に記憶させ、そのバッファ等においてユーザ指定ルールを行う。よって、ユーザ指定ルール蓄積手段6には、管理者によって入力されたユーザ指定ルールが変更されることなく記憶されている。対話制御手段4は、ユーザ指定ルール蓄積手段6に記憶されたユーザ指定ルールを管理者に提示する。この結果、管理者に、管理者自身が入力した理解容易なユーザ指定ルールを提示することになる。従って、管理者は、そのような理解容易なユーザ指定ルールを参照して、新たなユーザ指定ルールの追加やユーザ指定ルールの変更を効率よく行える。
また、本発明では、条件式が満たされた障害対処ルールが存在した場合、対処方法検索手段3が、その条件式に対応する復旧処理コマンドの情報を出力し、その情報は対話制御手段4を介して、コマンド実行手段5に送信される。コマンド実行手段5は、受信した情報が示す復旧処理コマンドをサービス実行手段10に対して実行する。従って、サービス実行手段10における障害復旧や障害回避を迅速に行うことができる。
実施の形態2.
本発明の第2の実施の形態における障害復旧システムの構成は、図1に例示する構成と同様であり、図1を用いて第2の実施の形態について説明する。ただし、第2の実施の形態では、共通条件制御手段7は、第1の実施の形態における動作に加え、さらに他の動作も行う。
サービス実行手段10の状態検出から、復旧処理コマンド実行までの処理経過は、第1の実施の形態(図6参照。)と同様である。
また、第2の実施の形態では、ユーザ指定ルールにおける復旧処理コマンドには、対処コマンドおよび準備コマンドが含まれているものとする。すなわち、対話制御手段4が、ユーザ(管理者)の操作に応じてユーザ指定ルールを入力する場合、その個々のユーザ指定ルールには、復旧処理コマンドの情報として対処コマンドおよび準備コマンドの情報がそれぞれ含まれているものとする。対処コマンドは、サービス実行手段10を障害から復旧させたり、障害発生を回避させたりするためのコマンドである。準備コマンドは、対処コマンド実行の準備を行うためのコマンドである。
準備コマンドによる事前準備の例として、データのバックアップ、コマンドのダウンロード、切替用情報処理装置に対する準備等が挙げられる。切替用情報処理装置に対する準備の例として、例えば、サービス実行手段10が、障害発生時に用いられる切替用情報処理装置を含む複数の情報処理装置によって構成されるシステムである場合おける、切替用情報処理装置に対するソフトウェアインストール等が挙げられる。対処コマンドによる対処の例としては、サービス実行手段10の設定変更や、切替用情報処理装置への切り替え等が挙げられる。切替用情報処理装置への切り替えとは、障害が発生した情報処理装置ではなく切替用情報処理装置にデータが流れるようにサービス実行手段10内のデータ転送経路を切り替えることである。
準備コマンドの特徴として、実行時間が比較的長いことが挙げられる。また、サービス実行手段10に対して準備コマンドを実行したとしても、サービス実行手段10を準備コマンド実行前の状態に戻すことができるという特徴がある。一方、対処コマンドの特徴として、対処コマンド実行後にサービス実行手段10が情報通信サービスを提供した場合、サービス実行手段10を対処コマンド実行前の状態に戻すことができないということが挙げられる。例えば、対処コマンドを実行したことにより、サービス実行手段10の設定が変更され、その後、サービス実行手段10が情報通信サービスを提供したとする。すると、情報通信サービスを提供に伴い、変更後の設定に基づいた新たなデータが生成されることになる。このとき、サービス実行手段10の設定自体は元の設定に戻すことができるが、その状態では、新たに生成されたデータに対する処理を行うことができない。このように設定を戻したとしても、設定変更後に生成されたデータが既に発生した状態になっているため、サービス実行手段10を対処コマンド実行前の状態に戻すことができない。よって、対処コマンドは、サービス実行手段10に対して不可逆な変更を加えるコマンドであると言える。
ユーザ自身が作成したユーザ指定ルールにおける復旧処理コマンドの情報には、対処コマンドおよび準備コマンドの両方の情報が含まれているが、ルール蓄積手段2が記憶する復旧処理コマンドでは、対処コマンドと準備コマンドのうちのいずれか一方のみの情報が含まれていてもよい。また、復旧処理コマンドでは、対処コマンドと準備コマンドの両方の情報が含まれていてもよい。
共通条件制御手段7は、第1の実施の形態と同様に、ユーザ指定ルールの矛盾を解消して、ユーザ指定ルールが一意に識別されるようにする処理(図4に示すステップS301〜S308の処理)を実行する。本実施の形態では、共通条件制御手段7は、さらに以下の処理を行う。すなわち、一意に識別できるように条件式が変更されたユーザ指定ルールと、変更前のユーザ指定ルールとを比較し、変更されているユーザ指定ルールを特定する。そして、共通条件制御手段7は、その変更されたユーザ指定ルールの変更前の条件式を条件式とし、変更前の復旧処理コマンドに含まれる準備コマンドのみを復旧処理コマンドとする新たな障害対処ルールを作成する。また、共通条件制御手段7は、変更されたユーザ指定ルールにおいて復旧処理コマンドとして含まれている準備コマンドの情報を削除し、対処コマンドが残るように、さらにユーザ指定コマンドを変更する。共通条件制御手段7は、以上の処理を行ったユーザ指定コマンドおよび新たに作成した障害対処ルールを、障害対処ルールとしてルール蓄積手段2に記憶させる。
以下、第2の実施の形態の動作について説明する。図7は、ユーザ指定ルールが修正されたときにおけるマネージャ装置30(主に共通条件制御手段7)による処理経過の例を示すフローチャートである。また、図8は、ユーザ指定ルールに基づく障害対処ルール生成過程の具体例を示す説明図である。
まず、対話制御手段4は、ユーザの操作に応じて、ユーザ指定ルール蓄積手段6内のユーザ指定ルールに対して追加や変更等を行う(ステップS221)。ここでは、元々図8(a)に示すユーザ指定ルール601が記憶されていて、ステップS221において、対話制御手段4がユーザの操作に応じてユーザ指定ルール602を追加したものとする。ステップS221の結果、ユーザ指定ルール蓄積手段6には、ユーザ指定ルール601,602が記憶されている。本実施の形態では、ユーザ指定ルールにおける復旧処理コマンドの情報には、対処コマンドおよび準備コマンドの両方の情報が含まれる。図8(a)に示す例では、ユーザ指定ルール601は、「準備A(準備コマンド)」および「対処A(対処コマンド)」の情報を含んでいる。同様に、ユーザ指定ルール602は、「準備B(準備コマンド)」および「対処B(対処コマンド)」の情報を含んでいる
ユーザ指定ルール蓄積手段6が記憶するユーザ指定ルールが変更されると、共通条件制御手段7は、ユーザ指定ルール蓄積手段6が記憶するユーザ指定ルールのうち、条件式に共通部分を有するユーザ指定ルールの有無を判定する(ステップS222)。この処理は、第1の実施の形態におけるステップS212の処理と同様である。また、ステップS222において、条件式に共通部分を有するユーザ指定ルールがないと判定した場合(ステップS222におけるNo)、共通条件制御手段7は、ユーザ指定ルール蓄積手段6が記憶しているユーザ指定ルールを障害対処ルールとしてルール蓄積手段2に記憶させる(ステップS225)。ステップS222においてNoと判定し、ステップS225に移行する際の共通条件制御手段7の動作は、第1の実施の形態で、ステップS212の次にステップS214に移行する動作と同様である。
一方、ステップS222において、条件式に共通部分を有するユーザ指定ルールがあると判定した場合(ステップS222におけるYes)、共通条件制御手段7は、そのユーザ指定ルールを収集して、そのユーザ指定ルール間に矛盾がなくなるように、収集したユーザ指定ルールの条件式を変更する(ステップS223)。ステップS223の処理は、第1の実施の形態におけるステップS213の処理と同様である。より詳細には、ステップS223の処理として、第1の実施の形態で示したステップS301〜S308(図4参照。)と同様の処理を実行すればよい。ステップS223の結果、図8(a)に示すユーザ指定ルール601,602から、図8(b)に示すユーザ指定ルール601a,602aが生成される。
ステップS223の後、共通条件制御手段7は、復旧処理コマンドの情報として準備コマンドのみを含む障害対処ルールの作成や、対処コマンドのみを含むようにユーザ指定ルールを変更する処理を実行する(ステップS224)。そして、共通条件制御手段7は、ステップS224の結果得られた各ルール(ユーザ指定ルールや新たに作成した障害対処ルール)を、障害対処ルールとしてルール蓄積手段2に記憶させる(ステップS225)。なお、このとき、条件式に他のユーザ指定ルールとの共通部分がないユーザ指定ルールが存在していた場合、共通条件制御手段7は、そのユーザ指定ルールについては、そのまま障害対処ルールとしてルール蓄積手段2に記憶させる。
図9は、ステップS224の処理(復旧処理コマンドの情報として準備コマンドのみを含む障害対処ルールの作成や、対処コマンドのみを含むようにユーザ指定ルールを変更する処理)の処理経過の一例を示す説明図である。ステップS223の処理により、図8(b)に例示するような一意に識別されるユーザ指定ルールを導出した後、共通条件制御手段7は、ステップS223の矛盾解消処理において条件式が変更されたユーザ指定ルールから準備コマンドの情報を削除する(ステップS321)。
ステップS321の後、共通条件制御手段7は、ステップS223の処理において条件式が変更されたユーザ指定ルールにおける元の(変更前の)ユーザ指定ルールを抽出する(ステップS322)。ユーザ指定ルール蓄積手段6には、ユーザによって作成されたユーザ指定ルールがそのまま記憶されているので、共通条件制御手段7は、ユーザ指定ルール蓄積手段6から変更前のユーザ指定ルールを読み込めばよい。
ステップS322の後、共通条件制御手段7は、ステップS322で抽出したユーザ指定ルール(条件式が変更されたユーザ指定ルールにおける元のユーザ指定ルール)の条件式と同一の条件式を有し、復旧処理コマンドの情報として、ステップS322で抽出したユーザ指定ルールに含まれる準備コマンドの情報を有する障害対処ルールを作成する(ステップS323)。
共通部分を有するユーザ指定ルールのグループが複数存在した場合、それらの各グループについて、図9に示すステップS321以降の処理を行えばよい。そして、各グループについて、ステップS321以降の処理が終了した後、ステップS225に移行すればよい。
図8を用いて、以上の処理を説明する。共通条件制御手段7は、ユーザ自身が作成したユーザ指定ルール601,602に基づいて、ステップS223の処理(より具体的には図4に示すステップS301〜S308の処理)を実行することにより、ユーザ指定ルール601a,602a(図8(b)参照。)を作成する。この作成過程は、第1の実施の形態において図3を用いて説明した場合と同様である。なお、図8(c)は、図9に示すステップS321〜S323の処理の後における各ルールを示す。
ユーザ指定ルール601a,602a作成後、共通条件制御手段7は、ステップS223の処理において条件式が変更されたユーザ指定ルールから準備コマンドの情報を削除する(ステップS321)。図8(b)に示すユーザ指定ルール601aは、図8(a)に示す条件式を変更し、“(NOT状態C)”をいう条件を追加して作成されている。従って、共通条件制御手段7は、ユーザ指定ルール601aから準備コマンドである「準備A」の情報を削除する。この結果を、図8(c)においてユーザ指定ルール601bとして示している。また、図8(b)に示すユーザ指定ルール602aは、元のユーザ指定ルール602と同一であり、変更されていない。従って、共通条件制御手段7は、ユーザ指定ルール602aからは準備コマンドの情報を削除しない。よって、図8(c)にユーザ指定ルール601bとして示しているように、復旧処理コマンドの情報として「準備B」が残される。
続く、ステップS322において、共通条件制御手段7は、ステップS223の処理において条件式が変更されたユーザ指定ルールにおける元の(変更前の)ユーザ指定ルールを抽出する。本例では、条件式が変更されたユーザ指定ルール601aの元のユーザ指定ルール601をユーザ指定ルール蓄積手段6から抽出すればよい。ユーザ指定ルール602aに関しては条件式が変更されていないので、その元のユーザ指定ルール602を抽出する必要はない。
次のステップS323では、共通条件制御手段7は、抽出したユーザ指定ルール601の条件式と同一の条件式“状態A & 状態B”を有し、復旧処理コマンドの情報として、抽出したユーザ指定ルール601に含まれる準備コマンドの情報(「準備A」)を有する障害対処ルールを作成する。図8(c)では、この障害対処ルールを、障害対処ルール603bとして示している。
以上の処理の結果、図8(c)に示すルール601b、602b、603bが生成される。共通条件制御手段7は、これらのルール601b、602b、603bを障害対処ルールとしてルール蓄積手段2に記憶させる(図7に示すステップS225)。
図8(b)に示すユーザ指定ルール601a,602aを障害対処ルールとした場合、「対処B」の実行タイミングは、「状態Aかつ状態Bかつ状態C」が検出された時点である。これは、ユーザ自身が作成したユーザ指定ルール602において規定されている「対処B」の実行タイミングと同一である。一方、「対処A」の実行タイミングは、「状態Aおよび状態Bであることが検出され、かつ状態Cでないこと」が検出された時点である。このタイミングは、ユーザ自身が作成したユーザ指定ルール601において規定されている「対処A」の実行タイミングよりも遅れる。状態Cが発生していないことを判定する分だけ条件式の判定時間がかかるためのである。
第2の実施の形態によれば、図8(a),(b)に示すユーザ指定ルールを用いてステップS224(より具体的には図9に示すステップS321〜S323)を行い、図8(c)に例示するルール601b,602b,603cを生成する。そして、このルール群を障害対処ルールとする。この場合、「状態Aかつ状態B」が検出された時点で、「準備A」が実行される。その後、状態Cが発生しているか否かが判定された時に、「準備B、対処B」または「対処A」が選択的に実行される。「準備A」の実行タイミングは、ユーザ自身が作成したユーザ指定ルール601において規定されている「準備A、対処A」の実行タイミングと同一である。従って、第2の実施の形態によれば、比較的実行時間のかかる「準備A」の実行タイミングを、ユーザ自身が作成したユーザ指定ルールにおいて規定されている実行タイミングにあわせることができ、対処の実行の遅れを緩和することができる。
図8では、ステップS221(図7参照。)後において、条件式に共通部分を有するユーザ指定ルールが2つある場合を示したが、そのようなユーザルールが3つ以上ある場合でも、同様に処理を行う。以下、ステップS221(図7参照。)後において、条件式に共通部分を有するユーザ指定ルールが3つである場合を例に説明する。図10は、ユーザ指定ルールに基づく障害対処ルール生成過程の具体例を示す説明図である。図10(a)は、ステップS221後におけるユーザ指定ルールを表し、図10(b)は、ステップS223の矛盾解消処理後のユーザ指定ルールを表す。図10(a)に示すユーザ指定ルール611〜613に基づいて、図10(b)に示すユーザ指定ルール611a〜613aを導出する処理は、図5を用いて説明した場合と同様である。
図10(b)に示すユーザ指定ルール611a〜613aの作成後、共通条件制御手段7は、ステップS223で条件式が変更されたユーザ指定ルールから準備コマンドの情報を削除する(ステップS321)。図10(b)に示すユーザ指定ルール611aは、図10(a)に示す条件式を変更し、“(NOT状態C) & (NOT状態D)”という条件を追加して作成されている。従って、共通条件制御手段7は、ユーザ指定ルール611aから「準備A」の情報を削除する。この結果を図10(c)においてユーザ指定ルール611bとして示している。同様に、共通条件制御手段7は、ユーザ指定ルール612aから「準備B」の情報を削除する。この結果を図10(c)においてユーザ指定ルール612bとして示している。また、図10(b)に示すユーザ指定ルール613aは、元のユーザ指定ルール613と同一であり、変更されていない。従って、共通条件制御手段7は、ユーザ指定ルール613aからは準備コマンドの情報を削除しない。よって、図10(c)にユーザ指定ルール613bとして示しているように、復旧処理コマンドの情報として「準備C」が残される。
続く、ステップS322において、共通条件制御手段7は、ステップS223の処理で条件式が変更されたユーザ指定ルールにおける元の(変更前の)ユーザ指定ルールを抽出する。本例では、条件式が変更されたユーザ指定ルール611a,612aの元のユーザ指定ルール611,612をユーザ指定ルール蓄積手段6から抽出すればよい。ユーザ指定ルール613aに関しては条件式が変更されていないので、その元のユーザ指定ルール613を抽出する必要はない。
次のステップS323では、共通条件制御手段7は、抽出したユーザ指定ルール611の条件式と同一の条件式“状態A & 状態B”を有し、復旧処理コマンドの情報として、抽出したユーザ指定ルール611に含まれる準備コマンドの情報(「準備A」)を有する障害対処ルールを作成する。図10(c)では、この障害対処ルールを、障害対処ルール614bとして示している。同様に、共通条件制御手段7は、抽出したユーザ指定ルール612の条件式と同一の条件式“状態A & 状態B & 状態C”を有し、復旧処理コマンドの情報として、抽出したユーザ指定ルール612に含まれる準備コマンドの情報(「準備B」)を有する障害対処ルールを作成する。図10(c)では、この障害対処ルールを、障害対処ルール615bとして示している。
以上の処理の後、共通条件制御手段7は、図10(c)に示す各ルールを障害対処ルールとしてルール蓄積手段2に記憶させる。
第2の実施の形態によれば、共通条件制御手段7が、ユーザ指定ルールの矛盾を解消した後、ステップS224(より具体的には図9に示すステップS321〜S323)の処理を行う。従って、ユーザが作成したユーザ指定ルールが規定するタイミングで準備コマンドを実行して対処コマンドの実行の遅れを緩和することができる。
次に、第2の実施の形態の変形例について説明する。図8(c)に示すような障害対処ルールを作成した場合、状態A,B,Cを全て検知した場合には、「準備A」を実行し、「準備B、対処B」も実行することになる。この場合、「準備A」と「準備B」の実行が何らかの競合を引き起こし、サービス実行手段10に好ましくない動作を行わせる場合が発生する場合もある。また、図8(b)に例示するユーザ指定ルール(ステップS223後のユーザ指定ルール)を障害対処ルールとして使用した場合であっても、「対処A」の遅れが問題にならない場合もある。そこで、まず、ステップS223の矛盾解消処理の結果得られるユーザ指定ルールを障害対処ルールとしてルール蓄積手段2に記憶させてもよい。そして、ステップS223の矛盾解消処理において条件式に変更を加えたルールにおける対処コマンドの実行に失敗したときに、復旧処理コマンドの情報として準備コマンドのみを含む障害対処ルールの作成等(図7に示すステップS224に相当する処理)を実行してもよい。
図11は、上記の変形例におけるマネージャ装置30(主に共通条件制御手段7)による処理経過の例を示すフローチャートである。図7に示す処理と同様の処理に関しては、図7と同様の符号を付して、詳細な説明を省略する。本変形例では、図11に示すように、矛盾解消処理(ステップS223)の結果得られるユーザ指定ルールを障害対処ルールとして記憶する(ステップS225)。すなわち、ステップS225では、図8(b)や図10(b)に例示するルールを障害対処ルールとしてルール蓄積手段に蓄積する。
その後、矛盾解消処理(ステップS223)において条件式が変更されたルールにおける準備コマンドおよび対処コマンドを、対処方法検索手段3が検索し、対話制御手段4がその準備コマンドおよび対処コマンドの情報をコマンド実行手段5に送信して、その準備コマンドおよび対処コマンドが実行されたとする。動作状態検出手段1は、対処コマンド実行後の動作状態を検出して、その動作状態の情報を対処方法検索手段3に送信する。対処方法検索手段3は、その動作状態の情報と、各障害対処ルールの条件式とを照合して、障害が発生している状態か否かを判定する。障害が発生している状態であれば、対処コマンドの実行が遅れ、対処コマンドの実行に失敗したことになる。障害が発生していなければ、対処コマンドの実行タイミングが、ユーザ自身が作成したユーザ指定ルールにおいて規定されているタイミングより遅れても、対処コマンドの実行に成功したことになる。対処方法検索手段3は、このように、対処コマンドの実行に成功したか否かを判定する(ステップS226)。ステップS226で、対処コマンドの実行に成功したと判定した場合には、ステップS221に移行し、ステップS221以降の処理を繰り返せばよい。
一方、ステップS226で、対処コマンドの実行に失敗したとする(ステップS226におけるNo)。この場合、共通条件制御手段7は、ステップS227の処理として以下の処理を実行する。共通条件制御手段7は、ルール蓄積手段2に記憶させた障害対処ルールのうち、ステップS223の矛盾解消処理において条件式に変更が加えられていたルールから、準備コマンドの情報を削除する。例えば、ステップS223,S225の処理の結果、図8(b)に示す各ルール601a,602aが障害対処ルールとしてルール蓄積手段2に記憶されていたとする。この例では、ステップS223の矛盾解消処理において条件式に変更が加えられていたルールは、ルール601aである。従って、共通条件制御手段7は、障害対処ルールとしてルール蓄積手段2に記憶されたルール601から準備コマンドの情報である「準備A」を削除し、図8(c)に示すルール601bになるように障害対処ルールを書き換える。
また、復旧処理コマンドの情報として準備コマンドのみを含む障害対処ルールを作成し、その障害対処ルールをルール蓄積手段2に追加記憶させる。この障害対処ルール作成処理は、図9に示すステップS322,323と同様に行えばよい。すなわち、共通条件制御手段7は、ステップS223の処理において条件式が変更されたユーザ指定ルールにおける元の(変更前の)ユーザ指定ルールを抽出する。そして、共通条件制御手段7は、その抽出したユーザ指定ルールの条件式と同一の条件式を有し、復旧処理コマンドの情報として、抽出したユーザ指定ルールに含まれる準備コマンドの情報を有する障害対処ルールを作成すればよい。以上の処理を、ステップS227の処理として行い、その後ステップS221に移行する。
以上のような変形例によれば、準備コマンド同士の競合により、サービス実行手段10に好ましくない動作を行わせることを防止できる。
また、第2の実施の形態の他の変形例は、図9に示す処理において、ステップS323の後、競合する準備コマンドが同時に実行されることがある場合に、準備コマンドの前に、競合する準備コマンドの実行を取り消す取消コマンドの情報を付加する形態である。なお、準備コマンドの実行を取り消すとは、その準備コマンド実行前の状態に戻すことである。
図12は、本変形例におけるステップS224の処理(復旧処理コマンドの情報として準備コマンドのみを含む障害対処ルールの作成や、対処コマンドのみを含むようにユーザ指定ルールを変更する処理)の処理経過の一例を示す説明図である。図9に示す処理と同様の処理については、図9と同一の符号を付して説明を省略する。
ステップS323の後、共通条件制御手段7は、ステップS323によって得られた各ルールのうち、準備コマンドが競合するルールが存在するか否かを判定する(ステップS324)。ステップS324において、共通条件制御手段7は、まず、準備コマンドの情報を含むルールであって、同時に成立し得るルールを選択する。ここで同時に成立し得ることは、あるルールの条件式では「状態Pになっていること」が条件として記述され、他のルールの条件式では「状態Pになっていないこと」が条件として記述されていることに基づいて判定すればよい(状態Pは、任意の障害発生状態)。そして、共通条件制御手段7は、選択した各ルールの準備コマンドが競合するか否かを判定すればよい。なお、競合する準備コマンドの情報は、例えば、マネージャ装置が備える記憶装置(図示せず。)に予め記憶させておけばよい。
準備コマンドの情報を含むルールであって、同時に成立し得るルールを選択し、そのルールの準備コマンドが競合するものでなければ(ステップS324におけるNo)、処理を終了する。
準備コマンドが競合する場合(ステップS324におけるYes)、共通条件制御手段7は、準備コマンドが競合するルールに、準備コマンドの実行を取り消す取消コマンドの情報を追加する(ステップS325)。具体的には、共通条件制御手段7は、対処コマンドの情報を含むルールの準備コマンドの情報の前に、その準備コマンドと競合する準備コマンドの取消コマンドの情報を追加する。その後、共通条件制御手段7は、以上の処理の結果得られるルールを障害対処ルールとしてルール蓄積手段2に記憶させる(図7に示すステップS225)。なお、共通部分を有するユーザ指定ルールのグループが複数存在した場合、それらの各グループについて、図12に示すステップS321以降の処理を行えばよい。そして、各グループについて、ステップS321以降の処理が終了した後、ステップS225に移行すればよい。
例えば、ステップS323の結果、図8(c)に示すルール601b,602b,603bが生成されていたとする。ステップS323の後、共通条件制御手段7は、準備コマンドの情報を含むルールであって、同時に成立し得るルールを選択する。本例では、共通条件制御手段7は、図8(c)に示すルール602b,603bを選択する。そして、共通条件制御手段7は、選択したルールの準備コマンドが競合するか否かを判定する(ステップS324)。ここでは、ルール602bにおける「準備B」とルール603bにおける「準備A」とが競合するか否かを判定する。
「準備B」と「準備A」とが競合しなければ、処理を終了する。「準備B」と「準備A」とが競合する場合には、共通条件制御手段7は、対処コマンドの情報を含むルール602bの準備コマンド「準備B」の情報の前に、その準備コマンドと競合する準備コマンド「準備A」の取消コマンド「取消A」の情報を追加する。この結果得られるルール群の例を図13に示す。対処コマンドの情報を含むルール602bの準備コマンドの前に取消コマンド「取消A」を追加したルールを、図13では、ルール602cとして示している。
なお、図11に示すステップS227において、図12に示すステップS321〜S325の処理を実行してもよい。
また、図7に示すフローチャートでは、ステップS222においてYesと判定した場合、矛盾解消処理(ステップS223)を実行する。第2の実施の形態の他の変形例として、共通条件制御手段7が、ステップS222においてYesと判定した場合、条件式に共通部分を有する各ユーザ指定ルールを、準備コマンドの情報を有するユーザ指定ルールと、対処コマンドの情報を有するユーザ指定ルールに分離し、その後、ステップS223の処理を実行し、ステップS225に移行してもよい。
本変形例では、ステップS222においてYesと判定した場合、共通条件制御手段7は、例えば、図8(a)に例示するユーザ指定ルール601を、条件式が“状態A & 状態B”であり、「準備A」の情報を含むルールと、条件式が“状態A & 状態B”であり、「準備B」の情報を含むルールとに分離する。同様に、図8(a)に例示するユーザ指定ルール602についても分離する。そして、ステップS223の処理を実行し、ステップS225に移行する。
実施の形態3.
図14は、本発明の第3の実施の形態を示すブロック図である。第1の実施の形態や第2の実施の形態と同様の構成部については、図1と同一の符号を付し、説明を省略する。ただし、第2の実施の形態では、共通条件制御手段7は、第2の実施の形態における動作に加え、さらに他の動作も行う。また、本実施の形態では、エージェント装置20は、検出要素制御手段8を備える。
本実施の形態では、第2の実施の形態と同様に、ユーザ自身が作成したユーザ指定ルールにおける復旧処理コマンドの情報には、対処コマンドおよび準備コマンドの両方の情報が含まれる。また、ユーザ指定ルールに基づいて作成される復旧処理コマンドには、準備コマンドや対処コマンドの他に、検出コマンドが含まれる場合がある。検出コマンドは、サービス実行手段10の動作状態の検出を動作状態検出手段1に変更させるためのコマンドである。例えば、動作状態検出手段1が、サービス実行手段10に「状態C」が発生しているか否かを検出していないとする。この場合、検出要素制御手段8が、検出コマンド(ここでは「検出C」とする。)を受け取ると、検出要素制御手段8が動作状態検出手段1に対し「状態C」が発生しているか否かの検出を指示する。動作状態検出手段1は、この指示に応じて「状態C」が発生しているか否かの検出を開始し、その検出結果を対処方法検索手段3に出力する。
共通条件制御手段7は、複数のユーザ指定ルールの条件式の共通部分を条件式とし、その複数のユーザ指定ルールの共通部分以外に記述された状態が発生しているか否かを検出するための検出コマンドの情報を含む障害対処ルールを作成する。
また、共通条件制御手段7は、第1の実施の形態や第2の実施の形態と同様に、ユーザ指定ルールの矛盾を解消して、ユーザ指定ルールが一意に識別されるようにする処理(図4に示すステップS301〜S308の処理)を実行する。ただし、共通条件制御手段7は、対処コマンドの情報を含むユーザ指定ルールを対象として、上記の矛盾解消処理を行う。従って、検出コマンドの情報を含んでいるが対処コマンドの情報を含んでいないルール等は、矛盾解消処理の対象外となる。
また、共通条件制御手段7は、第2の実施の形態におけるステップS224(より具体的には図9に示すステップS321〜S323)と同様の処理を行い、ユーザ指定ルールから準備コマンドを削除したり、準備コマンドを含む新たな障害対処ルールを作成したりする。
また、共通条件制御手段7は、導出した各ルールを障害対処ルールとしてルール蓄積手段2に記憶させる前に、条件式が同一であるルールを1つにまとめる処理を行う。
対処方法検索手段3が、検出コマンドの情報を対話制御手段4に出力し、対話制御手段4もその検出コマンドの情報をコマンド実行手段5に出力したとする。コマンド実行手段5は、検出コマンドの情報を受信した場合には、その情報が示す検出コマンドを検出要素制御手段8に出力する。検出要素制御手段8は、コマンド実行手段5から検出コマンドを受け取ると、その検出コマンドに応じて、動作状態検出手段1に検出する動作を変更させる。例えば、動作状態検出手段1に新たな動作状態の検出を行わせる。
検出要素制御手段8は、例えば、動作状態検出手段1等と同様に、コンピュータと障害復旧プログラムによって実現することができる。また、検出要素制御手段8をハードウェア装置によって実現してもよい。
以下、第3の実施の形態の動作について説明する。図15は、ユーザ指定ルールが修正されたときにおけるマネージャ装置30(主に共通条件制御手段7)による処理経過の例を示すフローチャートである。図7に示す処理と同様の処理については、図7と同様の符号を付して説明を省略する。
ステップS222において、条件式に共通部分を有するユーザ指定ルールがあると判定した場合(ステップS222におけるYes)、共通条件制御手段7は、共通部分を条件式とし、検出コマンドを含む障害対処ルールを作成する(ステップS222a)。図16は、この検出コマンドを含む障害対処ルール作成処理(ステップS222a)の処理経過の例を示すフローチャートである。共通条件制御手段7は、検出コマンドを含む障害対処ルールを作成する際、まず、ユーザ指定ルール蓄積手段6が記憶するユーザ指定ルールのうち、条件式に共通部分を有するユーザ指定ルールを収集する(ステップS341)。次に、共通条件制御手段7は、収集したユーザ指定ルールの条件式の共通部分を条件式とし、その各ユーザ指定ルールの条件式の共通部分以外に記述された状態が発生しているか否かを検出するための検出コマンドの情報を含む障害対処ルールを作成する(ステップS342)。以上の処理によって、ステップS222aの処理を終了する。なお、共通部分を有するユーザ指定ルールのグループが複数存在した場合、それらの各グループについて、ステップS342の処理を実行すればよい。
ステップS222aの後、共通条件制御手段7は、各ユーザ指定ルール間に矛盾がなくなるように、収集したユーザ指定ルールの条件式を変更する(ステップS223)。この処理は、第2の実施の形態におけるステップS223(図7参照。)と同様である。すなわち、図4に示すステップS301〜S308と同様の処理を実行すればよい。ただし、ユーザ指定ルールの収集処理(図4に示すステップS302)に相当する処理は、図16に示すステップS341で実行しているので、ステップS302の処理は省略してよい。また、本実施の形態では、共通条件制御手段7は、条件式に共通部分を有するユーザ指定ルールであって、対処コマンドの情報を含むユーザ指定ルールを対象として、ステップS223の矛盾解消処理を行う。上記のステップS222aで作成されたルールには、対処コマンドの情報は含まれないので、ステップS222aで作成されたルールの条件式が、ステップS223で変更されることはない。
ステップS223の後、共通条件制御手段7は、復旧処理コマンドの情報として準備コマンドのみを含む障害対処ルールの作成や、対処コマンドのみを含むようにユーザ指定ルールを変更する処理を実行する(ステップS224)。この処理は、第2の実施の形態におけるステップS224(図7参照。)と同様である。すなわち、図9に示すステップS321〜S323と同様の処理を実行すればよい。ただし、共通条件制御手段7は、ステップS222aで作成した検出コマンドの情報を含む障害対処ルールに対しては、何ら処理を行わない。従って、ステップS222aで作成されたルールの条件式が、ステップS224で変更されることはない。
続いて、共通条件制御手段7は、ステップS224の結果得られた各ルールと、ステップS222aで作成した障害対処ルールのうち、条件式が同一のものがあれば、そのルールを1つのルールにまとめる(ステップS224a)。例えば、条件式が“状態A & 状態B”であり、「検出C」という検出コマンドの情報を含むルールと、条件式が“状態A & 状態B”であり、「準備A」という準備コマンドの情報を含むルールとが存在したとする。この場合、共通条件制御手段7は、この2つのルールをまとめて、条件式が“状態A & 状態B”であり、「検出C、準備A」を含むルールを作成する。
ステップS224aにおいてまとめられるルールをまとめた後、各ルールを、障害対処ルールとしてルール蓄積手段2に記憶させる(ステップS225)。なお、このとき、条件式に他のユーザ指定ルールとの共通部分がないユーザ指定ルールが存在していた場合、共通条件制御手段7は、そのユーザ指定ルールについては、そのまま障害対処ルールとしてルール蓄積手段2に記憶させる。
図17および図18を用いて、以上の処理を説明する。図17および図18は、ユーザ指定ルールに基づく障害対処ルール生成過程の具体例を示す説明図である。ユーザ指定ルール蓄積手段6は、初期状態において、図17(a)に示すユーザ指定ルールを記憶しているとする。そして、ステップS221において、対話制御手段4が、ユーザの操作に応じて、図17(b)に示すユーザ指定ルール702を追加したとする。すると、ステップS222aにおいて、共通条件制御手段7は、ユーザ指定ルール701,702を収集する。そして、共通条件制御手段7は、その2つのユーザ指定ルール701,702の条件式の共通部分である“状態A & 状態B”を条件式とし、ユーザ指定ルール701,702の条件式の共通部分以外に記述された状態(本例では状態C)が発生しているか否かを検出するための検出コマンド(「検出C」とする。)の情報を含む障害対処ルールを作成する。図17(c)では、このルールを障害対処ルール751として示している。
次のステップS223では、共通条件制御手段7は、図17(c)に示すユーザ指定ルール701,702に基づいて、図18(a)に示すユーザ指定ルール701a,702aを導出する。この導出過程は、図8(a)に示すユーザ指定ルールから図8(b)に示すユーザ指定ルールを導出する過程と同様である。なお、障害対処ルール751には対処コマンドの情報が含まれないので、ステップS223の処理対象とされない。
次のステップS224では、共通条件制御手段7は、図18(a)に示すユーザ指定ルール701a,702aに基づいて、図18(b)に示すルール701b,702b,703bを導出する。この導出過程は、図8(b)に示すユーザ指定ルールから、図8(c)に示す各ルールを導出する過程と同様である。なお、ステップS224において、共通条件制御手段7は、検出コマンドの情報を含む障害対処ルール751に対しては、何ら処理を行わない。
次の、ステップS224aでは、共通条件制御手段7は、ステップS224で得られた各ルール701b,702b,703bと、ステップS222aで作成した障害対処ルール751のうち、条件式が同一のものがあれば、そのルールを1つにまとめる。本例では、図18(b)に示す障害対処ルール751,703bの条件式が同一であるので、この2つのルールをまとめ、図18(c)に示す障害対処ルール752を生成する。その後、共通条件制御手段7は、図18(c)に示す各ルールを障害対処ルールとして、ルール蓄積手段2に記憶させる。
他の具体例について説明する。図19および図20も、ユーザ指定ルールに基づく障害対処ルール生成過程の具体例を示す説明図である。ステップS221の後、ユーザ指定ルール蓄積手段6に、図19(a)に示すユーザ指定ルール801,802が記憶されているとする。すると、ステップS222aにおいて、共通条件制御手段7は、ユーザ指定ルール801,802を収集する。そして、共通条件制御手段7は、その2つのユーザ指定ルール801,802の条件式の共通部分である“状態A & 状態B”を条件式とし、ユーザ指定ルール801,802の条件式の共通部分以外に記述された状態(本例では状態C、状態D)が発生しているか否かを検出するための各検出コマンドの情報を含む障害対処ルールを作成する。ここでは、状態Cが発生しているか否かを検出するための検出コマンドを「検出C」、状態Dが発生しているか否かを検出するための検出コマンドを「検出D」とする。図19(b)では、このルールを障害対処ルール851として示している。
次のステップS223では、共通条件制御手段7は、図19(b)に示すユーザ指定ルール801,802に基づいて、図20(a)に示すユーザ指定ルール801a,802aを導出する。なお、障害対処ルール851には対処コマンドの情報が含まれないので、ステップS223の処理対象とされない。
次のステップS224では、共通条件制御手段7は、図20(a)に示すユーザ指定ルール801a,802aに基づいて、図20(b)に示すルール801b,802b,803bを導出する。なお、ステップS224において、共通条件制御手段7は、検出コマンドの情報を含む障害対処ルール751に対しては、何ら処理を行わない。
ステップS224aでは、共通条件制御手段7は、ステップS224で得られた各ルール801b,802b,803bと、ステップS222aで作成した障害対処ルール851のうち、条件式が同一のものがあれば、そのルールを1つにまとめる。本例では、条件式が同一となるものがないので、ルールをまとめることはない。続いて、共通条件制御手段7は、図20(b)に示す各ルールを障害対処ルールとして、ルール蓄積手段2に記憶させる。
なお、図17に示す具体例では、初期状態として“状態A & 状態B”を条件式とするユーザ指定ルール701が記憶され、続いて、その条件式“状態A & 状態B”を包含する条件式“状態A & 状態B & 状態C”を有するユーザ指定ルール702が追加された場合を示している。一方、図19(a)に示すユーザ指定ルール801,802では、一方の条件式が他方の条件式を包含しているわけではない。
既に記憶されているユーザ指定ルールの条件式を包含する条件式を有するユーザ指定ルールを追加した場合、元々記憶されていたユーザ指定ルールの条件式全体が、条件式の共通部分となる。例えば、図17に示す例では、元々記憶されていたユーザ指定ルール701の条件式全体(“状態A & 状態B”)が、追加されたユーザ指定ルール702の条件式との共通部分になっている。
ユーザ(管理者)が、新たにユーザ指定ルールを追加する場合、既にユーザ指定ルール蓄積手段6に記憶されているユーザ指定ルールの条件式を包含する条件式を有するユーザ指定ルールを追加することが多いと考えられる。従って、元々記憶されていたユーザ指定ルールの条件式全体が、条件式の共通部分となることが多いと考えられる。
あるユーザ指定ルールの条件式全体が、複数のユーザ指定ルールの条件式の共通部分となる場合、図15に示すステップS222aにおいて、以下のような処理を行ってもよい。共通条件制御手段7は、ユーザ指定ルール蓄積手段6が記憶するユーザ指定ルールのうち、条件式に共通部分を有するユーザ指定ルールを収集する。このユーザ指定ルールの中には、条件式全体が、各ユーザ指定ルールの条件式の共通部分となっているユーザ指定ルールが存在する。このユーザ指定ルールをKとし、ユーザ指定ルールKの条件式をJとする。Jは、条件式の共通部分でもある。共通条件制御手段7は、Jを条件式とし、各ユーザ指定ルールの条件式のうちJ以外の部分に記述された状態が発生しているか否かを検出するための検出コマンドの情報を含む障害対処ルールを作成する。さらに、共通条件制御手段7は、作成した障害対処ルールに対し、ユーザ指定ルールKに含まれる準備コマンドの情報も付加する。この結果、検出コマンドおよび準備コマンドの情報を有する障害対処ルールが作成される。また、共通条件制御手段7は、ユーザ指定ルールKから準備コマンドの情報を削除する。共通条件制御手段7は、以上の処理をステップS222aとして行う。
この後、ステップS223に移行するが、ステップS223終了後は、ステップS224,S224aの処理を行わずに、ステップS225に移行する。
図21を用いて、以上の処理の具体例を説明する。図21は、ユーザ指定ルールに基づく障害対処ルール生成過程の具体例を示す説明図である。ユーザ指定ルール蓄積手段6は、初期状態において、図21(a)に示すユーザ指定ルール901を記憶していて、その後、図21(a)に示すユーザ指定ルール902が追加記憶されたとする。本例では、ユーザ指定ルール901の条件式全体が、複数のユーザ指定ルール901,902の条件式の共通部分となる。従って、ユーザ指定ルール901が、上記の説明におけるユーザ指定ルールKとなり、その条件式“状態A & 状態B”が上記の説明におけるJに相当する。
共通条件制御手段7は、ステップS222aにおいて、図21(a)に示すユーザ指定ルール901,902を収集する。そして、共通条件制御手段7は、ユーザ指定ルール901の条件式J(すなわち、“状態A & 状態B”)を条件式とし、各各ユーザ指定ルールの条件式のうちJ以外の部分に記述された状態(本例では状態C)が発生しているか否かを検出するための検出コマンド(「検出C」とする。)の情報を含む障害対処ルールを作成する。さらに、共通条件制御手段7は、ユーザ指定ルール901に含まれる準備コマンドの情報(準備A)を、その障害対処ルールに付加する。この結果得られるルールを、図21(b)において障害対処ルール951として示している。
また、共通条件制御手段7は、ユーザ指定ルール901(ユーザ指定ルールK)から準備コマンドの情報を削除する。この結果得られるルールを、図21(b)において障害対処ルール901aとして示している。図21(b)は、ステップS222a終了後の各ルールの状態を示している。なお、図21(b)に示すユーザ指定ルール902aは、図21(a)に示すユーザ指定ルール901と同一である。
次のステップS223では、共通条件制御手段7は、図21(b)に示すユーザ指定ルール901a,902aに基づいて、図21(c)に示すユーザ指定ルール901b,902bを導出する。なお、障害対処ルール951には対処コマンドの情報が含まれないので、ステップS223の処理対象とされない。
本例では、ステップS224,S224aの処理を行わない。よって、ステップS223の結果得られた各ルール(図21(c)参照。)を障害対処ルールとしてルール蓄積手段2に記憶させる。
次に、本実施の形態における障害復旧動作の例について説明する。本実施の形態における障害復旧動作は、図6に示す動作と同様である。ただし、ステップS203において、復旧処理コマンドを実行する旨が入力され、対話制御手段4は、その復旧処理コマンドの情報をコマンド実行手段5に送信するときに、復旧処理コマンドの情報として検出コマンドの情報が含まれていたとする。この場合、対話制御手段4は、検出コマンドを含む復旧処理コマンドの情報を送信し、コマンド実行手段5は、その情報を受信する。コマンド実行手段5は、受信した情報が示す復旧処理コマンドのうち、準備コマンド、対処コマンドについては、第1の実施の形態と同様に、サービス実行手段10上でそれらのコマンドを実行する(ステップS204)。ただし、コマンド実行手段5は、検出コマンドについては、ステップS204で検出要素制御手段8に出力する。
検出要素制御手段8は、コマンド実行手段5が出力する検出コマンドに応じて、動作状態検出手段1に動作状態検出手段1に検出する動作状態を変更させる。すると、動作状態検出手段1は、新たにサービス実行手段10の動作状態を検出し、その動作状態の情報を対処方法検索手段3に送信する(ステップS201)。以降、同様の動作を繰り返す。
以下に、具体例を示す。図21(c)に示すルール901b,902b,951が障害対処ルールとして、ルール蓄積手段2に記憶されているものとする。
動作状態検出手段1は、サービス実行手段10の動作状態として「状態Aかつ状態B」を検出すると、その動作状態の情報を対処方法検索手段3に送信する(ステップS201)。対処方法検索手段3は、その動作状態の情報を受信し、ルール蓄積手段2に蓄積されている各障害対処ルールの中に、条件式が満たされている障害対処ルールがあるか否かを判定する(ステップS202)。本例では、図21(c)に示す障害対処ルール951の条件式が満たされる(ステップS202におけるYes)。そこで、対処方法検索手段3は、障害対処ルール951に含まれる「検出C、準備A」という復旧処理コマンドの情報を、対話制御手段4に出力する。対話制御手段4は、「検出C、準備A」を実行する旨の指示をユーザから受けると(ステップS203におけるYes)、「検出C、準備A」という情報をコマンド実行手段5に送信する。コマンド実行手段5は、サービス実行手段10上で「準備A」を実行するとともに、検出コマンドである「検出C」を検出要素制御手段8に出力する(ステップ204)。
検出要素制御手段8は、この検出コマンド「検出C」を受け取り、動作状態検出手段1に状態検出方法の変更を指示する。本例では、「検出C」を受け取った場合は、動作状態検出手段1に対して、新たに「状態C」が発生しているか否かを検出するようにに指示するものとする。動作状態検出手段1は、この指示に応じて「状態C」が生じているか否かの検出を開始し、その検出結果を対処方法検索手段3に送信する(ステップ201)。このとき、対処方法検索手段3は、既に「状態Aかつ状態B」が生じていることを認識している。従って、「状態C」の真偽によって、対処方法検索手段3は、図21(c)に示す障害対処ルール901b,902bのいずれの条件式が満たされているかを判定する(ステップS202)。そして、条件式が満たされている方の障害対処ルールに含まれる復旧処理コマンドの情報(「対処A」または「準備B、対処B」)を出力する。対話制御手段4は、その復旧処理コマンドを実行するか否かの決定をユーザに促し、復旧処理コマンドを実行する旨の指示を受けたならば(ステップS203におけるYes)、復旧処理コマンドの情報をコマンド実行手段5に送信する。コマンド実行手段5は、受信した情報が示す復旧処理コマンド(ここでは「対処A」または「準備B、対処B」)をサービス実行手段10上で実行する(ステップS204)。
このように本実施の形態によれば、第1、第2の実施の形態で説明した条件式の修正に加えて、動作状態検出手段1が検出対象とする動作状態を変更することができる。例えば、図21に示すユーザ指定ルール902が追加される前では、動作状態検出手段1は、「状態A」が生じているか否かおよび「状態B」が生じているか否かを検出していればよかった。新たに図21に示すユーザ指定ルール902の追加に伴い、仮に障害対処ルール901b,902bだけがルール蓄積手段2に追加されると、「状態C」が発生しているか否かについても検出しなければならないため、エージェント装置20の処理負荷が大きくなる。このように、障害対処ルールの数が増加すると、検出すべき要素の種類も増加し、障害復旧システムの処理負荷が大きくなり、その結果、サービス実行手段10の効率低下を引き起こす場合がある。本実施の形態では、共通条件制御手段7が、ユーザ指定ルールの条件式の共通部分を条件式とし、その各ユーザ指定ルールの条件式の共通部分以外に記述された状態が発生しているか否かを検出するための検出コマンドの情報を含む障害対処ルールを作成する。従って、常時監視する動作状態は、条件式の共通部分に記述された動作状態のみとすることができる。そして、各条件式の共通部分に相当する条件が満たされたときに、対処方法検索手段3が、各条件式の共通部分を条件式とする障害対処ルールに含まれる検出コマンドの情報を出力し、その検出コマンドに応じた動作状態の検出が開始される。このように、常時監視する動作状態を、条件式の共通部分に記述された動作状態のみとすることができるので、障害復旧システム(特にエージェント装置20)の監視負荷を大幅に低減することができる。
また、上記の第3の実施の形態の説明では、ステップS202(図6参照。)において、対処方法検索手段3が、ルール蓄積手段2に蓄積されている各障害対処ルールの中に、条件式が満たされている障害対処ルールがあるか否かを判定するものとして説明した。対処方法検索手段3は、条件式が満たされているか否かを判定する際、ルール蓄積手段2に記憶されている障害対処ルールの一部を判定の対象外とし、条件式が満たされた障害対処ルールが生じたときに、条件式が満たされているか否かの判定対象となる障害対処ルールを増加していってもよい。具体的には、対処方法検索手段3は、検出コマンドの情報が復旧処理コマンドの情報として含まれている障害対処ルールが存在する場合、その検出コマンドによって検出が開始される動作状態を条件式に含む障害対処ルールを、条件式が満たされているか否かの判定対象から外していてもよい。そして、検出コマンドの情報が復旧処理コマンドの情報として含まれている障害対処ルールの条件式が満たされた後、その検出コマンドによって検出が開始される動作状態を条件式に含む障害対処ルールを、条件式が満たされているか否かの判定対象に含めてもよい。
例えば、図21(c)に示す3つの障害対処ルール901b,902b,951が、ルール蓄積手段2に記憶されているとする。この場合、検出コマンドの情報「検出C」が含まれている障害対処ルール951が存在する。従って、対処方法検索手段3は、当初、「検出C」によって検出が開始される動作状態(本例では、“状態C”、“NOT状態C”)を条件式に含む障害対処ルール901b,902bを、条件式が満たされているか否かの判定対象から外していてもよい。このとき、対処方法検索手段3は、図21(c)に示す全ての障害対処ルールについて、条件式が満たされているか否かを判定する必要がないので、対処方法検索手段3の処理負荷は軽減される。
その後、「検出C」という情報を含む障害対処ルール951の条件式が満たされた後、対処方法検索手段3は、その検出コマンドによって検出が開始される動作状態(“状態C”、“NOT状態C”)を条件式に含む障害対処ルール901b,902bを、条件式が満たされているか否かの判定対象に含める。
このように、条件式が満たされているか否かの判定対象外となる障害対処ルールを定めておき、条件式が満たされた障害対処ルールが生じたときに、条件式が満たされているか否かの判定対象となる障害対処ルールを増加させることにより、当初は、条件式が満たされているか否かの判定対象となる障害対処ルールの数を抑えることができ、対処方法検索手段3の処理負荷を抑えることができる。
また、上記の説明では、コマンド実行手段5が検出コマンドの情報を受信して検出要素制御手段8に対して検出コマンドを出力することにより、検出要素制御手段8が、動作状態検出手段1に、検出コマンドに応じた動作状態が発生しているか否かの検出開始を指示する場合を示した。すなわち、検出コマンドが、その検出コマンドに応じた動作状態の検出開始のトリガとなるものとして説明した。検出コマンドの情報を含む障害対処ルールの条件式が満たされている間は、対処方法検索手段1から、対処制御手段4、コマンド実行手段5、検出要素制御手段8を介して、動作状態検出手段1に検出クエリを出力し続けてもよい。そして、動作状態検出手段1は、検出クエリが出力され続けている間、その検出クエリに応じた動作状態が発生しているか否かを検出する構成であってもよい。ただし、対話制御手段4が、検出クエリを出力しない旨の指示を受けた場合には、対話制御手段4は、検出クエリの出力を停止する。
また、検出コマンドの情報の含む障害対処ルールの条件式が満たされなくなった時には、対処方法検索手段3は、その検出コマンドに応じて開始された動作状態の検出を中止させる中止コマンドの情報を出力してもよい。対話制御手段4は、他のコマンドの情報と同様に、中止コマンドの情報をコマンド実行手段に送信する。コマンド実行手段5は、中止コマンドの情報を受信した場合、その中止コマンドを検出要素制御手段8に出力する。検出要素制御手段8は、中止コマンドを受けると、その中止コマンドに対応する動作状態の検出中止を動作状態検出手段1に指示する。動作状態検出手段1は、この指示に応じて、動作状態が発生しているか否かの検出を中止する。
例えば、状態Aおよび状態Bが真となり、図21(c)に示す障害対処ルール951に基づいて、対処方法検索手段3が、「検出C、準備A」という情報を出力したとする。その結果、動作状態検出手段1は、「状態C」が発生しているか否かの検出を開始する。その後、状態Aおよび状態Bのいずれかが偽(発生していない状態)となり、障害対処ルール951の条件式が満たされなくなったとする。このとき、対処方法検索手段3は、「状態C」が発生しているか否かの検出を中止させる中止コマンドの情報を対話制御手段4に出力する。対話制御手段4は、他のコマンドの情報と同様に、この中止コマンドの情報をコマンド実行手段5に送信する。コマンド実行手段5は、この情報を受信すると、「状態C」が発生しているか否かの検出を中止させる中止コマンドを検出要素制御手段8に出力する。すると、検出要素制御手段8は、「状態C」が発生しているか否かの検出の中止を動作状態検出手段1に出力し、動作状態検出手段1は、「状態C」が発生しているか否かの検出を中止する。
検出クエリを出力したり、中止コマンドを出力したりする場合であっても、第3の実施の形態と同様の効果を得ることができる。
なお、上記の各実施の形態では、マネージャ装置30とエージェント装置20とを備える構成として説明したが、マネージャ装置30とエージェント装置20とを一体化した装置として、障害復旧システムを実現してもよい。