JP4728565B2 - 障害復旧装置および障害復旧方法ならびにプログラム - Google Patents

Description

本発明は、ＷＥＢサービスや業務サービスといった情報通信サービスを提供する情報処理装置に関し、特に、障害状態を検知して対処コマンドを実行する耐障害機能を有する障害復旧装置に関する。

通信網を介した情報提供や商品販売といった情報通信サービスは、時間や距離の制約をあまり受けずに業務効率化やきめ細かいユーザサービスを提供できることから、急速に利用範囲が拡大している。このような利用範囲の拡大に伴い、これらのサービスを提供するコンピュータが障害に陥った場合の影響も大きくなり、その耐障害性が大きな課題となっている。

第１の従来技術として、サービスを実行する装置の状態を検出して、予め決められた状態になった場合を障害とみなして自動的に対処コマンドを実行する障害復旧装置では、特定の障害を自動的に復旧または回避することが可能である。しかし、検知状態や対処コマンドが固定されているため、実際のサービス実行環境毎の特性の違いに対応できず、連続運用に伴って装置の状態が徐々に変化してしまう場合や、他の装置との組合せにより装置の状態が変化してしまう場合には、適切な対処が行われないという問題があった。また、このような状態の変化に対応するためには、頻繁に検出状態や対処コマンドを変更する必要があり、管理コストが増大するという問題があった。

第２の従来技術として、同じ検出状態に対する対処コマンドを複数用意し、予め決められた優先度順に順次対処コマンドを試行する障害復旧装置がある（例えば特許文献１参照）。この従来の障害復旧装置では、サービス実行環境毎の特性が違う場合でも、複数の対処コマンドを順次実行することで効果のある対処を行うことができる。しかし、対処コマンドの適用順序が固定されているため、最初から個々のサービス実行環境に適した対処が行われるわけではなく、何度か対処に失敗してから正しい対処が行われることになり、対処時間が増大するとともに、間違った対処を行ってしまうことで別の障害を引き起こす可能性があるという問題があった。また、このような問題を避けるためには、別の障害を引き起こす可能性のある対処コマンドを制限したり、個々のサービス実行環境毎に適切な優先度を設定する必要があり、障害に対する対処の幅が制限され、システムが大規模／複雑化するに従って管理コストが増大するという問題があった。

第３の従来技術として、復旧処理を行うオペレータの作業を支援するために、過去の障害の状況および対処法を記載したナレッジ情報をオペレータに提示する障害復旧装置がある（例えば特許文献２参照）、この従来の障害復旧装置では、障害時に検出された障害状態と過去の障害状態との類似度に応じて提示するナレッジ情報の優先度を変化させることによって、より適切な作業支援を行うことができる。しかし、検出された状態のみで優先度を制御するため、提示されたナレッジ情報が現在の症状に類似しているかどうかは判断できても、このナレッジ情報に従って実行された対処コマンドで障害が復旧するのかどうかは判断できず、復旧効率の向上が期待できないという問題があった。また、このような実行の成否をオペレータに入力させる機能を新たに有する従来の障害復旧装置では、対処コマンドの実行がオペレータの判断によって行われるため、提示された情報通りに実行されたのかどうかが検出できず、提示したナレッジ情報に記載されている対処コマンド自体の有効性を検証できないという問題があった。
特公平７−５４４７４号公報 特開２００２ー２５１２９５号公報

これらの従来の障害復旧装置では、以下の課題がある。

第１の課題として、第１の従来技術では、連続運用に伴って装置の状態が徐々に変化してしまう場合や、他の装置との組合せにより装置の状態が変化してしまう場合には、適切な対処が行われないという問題があった。また、頻繁に検出状態や対処コマンドを変更する必要があり、管理コストが増大するという問題があった。

第２の課題として、第２の従来技術では、何度か対処に失敗してから正しい対処が行われることによって対処時間が増大するとともに、間違った対処を行ってしまうことで別の障害を引き起こす可能性があるという問題があった。また、障害に対する対処の幅が制限され、システムが大規模／複雑化するに従って管理コストが増大するという問題があった。

第３の課題として、第３の従来技術では、検出された状態のみで優先度を制御するため、復旧効率の向上が期待できないという問題があった。また、対処コマンドの実行がオペレータの判断によって行われるため、提示したナレッジ情報に記載されている対処コマンド自体の有効性を検証できないという問題があった。

本発明は、これらの従来の課題を解決する障害復旧装置を提供することを目的とする。また本発明の別の目的は、管理コストを増大させることなく、対処時間を減少させ、広い範囲の障害に対してきめ細かな障害対策が可能な障害復旧装置を提供することにある。

本発明の第１の障害復旧装置は、サービス実行手段の動作状態を検出する動作状態検出手段と、前記サービス実行手段で障害が発生した場合の動作状態または障害の前兆と推測される動作状態を判定するための条件式とその動作状態になった場合に障害を復旧または回避するための対処コマンドとルール間の適用順序の優先度情報とを含む複数の障害対処ルールを蓄積するルール蓄積手段と、前記ルール蓄積手段から、前記動作状態検出手段で検出された前記サービス実行手段の現在の動作状態に合致する条件式を持つルールを取り出し、その優先度情報に応じて順次試行するとともに、前記現在の動作状態に合致した条件式の否定から前記対処コマンドを実行した後に変化すると予想される動作状態の変化情報を生成して状態レジスタに出力する対処方法検索手段と、前記状態レジスタに保持された動作状態の変化情報と前記動作状態検出手段の出力である前記対処コマンド実行後の前記サービス実行手段の動作状態を比較して、対処コマンドによる復旧または回避の成否を判定し、その結果に応じて前記優先度情報を修正する効果判定手段と、を含んで構成される。

本発明の第１の障害復旧方法は、ａ）動作状態検出手段が、サービス実行手段の動作状態を検出するステップ、ｂ）対処方法検索手段が、前記サービス実行手段で障害が発生した場合の動作状態または障害の前兆と推測される動作状態を判定するための条件式とその動作状態になった場合に障害を復旧または回避するための対処コマンドとルール間の適用順序の優先度情報とを含む複数の障害対処ルールを蓄積するルール蓄積手段から、前記動作状態検出手段で検出された前記サービス実行手段の現在の動作状態に合致する条件式を持つルールを取り出し、その優先度情報に応じて順次試行するとともに、前記現在の動作状態に合致した条件式の否定から前記対処コマンドを実行した後に変化すると予想される動作状態の変化情報を生成して状態レジスタに出力するステップ、ｃ）前記動作状態検出手段が、前記対処コマンド実行後の前記サービス実行手段の動作状態を検出するステップ、ｄ）効果判定手段が、前記状態レジスタに保持された動作状態の変化情報と前記動作状態検出手段の出力である前記対処コマンド実行後の前記サービス実行手段の動作状態を比較して、対処コマンドによる復旧または回避の成否を判定し、その結果に応じて前記優先度情報を修正するステップ、を含んで構成される。

本発明の第１の障害復旧装置および方法にあっては、対処方法検索手段によって対処方法が同じ条件式に対する複数の対処コマンドを優先度情報に応じて順次試行する。さらに、この対処コマンドを実行した後に変化すると予想される動作状態の変化情報を出力することで、効果判定手段が現在の動作状態がこの変化と合致しているか否かによって対処コマンドの成否を判定し、その成否に応じて優先度情報を修正する。これにより、個々のサービス実行環境に適した対処コマンドを探し出して実行することができるため、第１の課題を解決する。

また、成功した対処コマンドの優先度を上昇させることで、予め個々のサービス実行環境の特性に合わせた優先度を提供できない場合でも、障害への対処が継続されるに従って自動的に適切な優先度へと修正されるため、対処時間が短縮され、誤った対処によって別の障害を引き起こす確率を低下させることができる。さらに、与えられた対処コマンドに適切なものが含まれていれば、失敗によって優先度の低下した対処コマンドが実行される前に障害への対処が完了することになることから、サービス実行環境の特性によっては別の障害を引き起こす可能性の高い危険な対処コマンドを混在させた障害対処ルール群を用いた場合にも、悪影響を抑えた適切な障害対策が可能となり、第２の課題を解決する。

さらに、これらの優先度制御は、実際に実行された対処コマンドの成否を判定することによって行われるため、成功率の高い対処コマンドを優先的に実行することができる。また、自動実行によって検証されるため、オペレータの主観に依らず、ルールの有効性を統一した基準で正確に判定することが可能となり、第３の課題を解決する。

本発明の第１の障害復旧装置および方法では、対処方法検索手段によって対処方法が同じ条件式に対する複数の対処コマンドを優先度情報に応じて順次試行する。さらに、この対処コマンドを実行した後に変化すると予想される動作状態の変化情報を出力することで、効果判定手段が現在の動作状態がこの変化と合致しているか否かによって対処コマンドの成否を判定し、その成否に応じて優先度情報を修正する。これにより、個々のサービス実行環境に適した対処コマンドを探し出して実行することができる。また、成功した対処コマンドの優先度を上昇させることで、予め個々のサービス実行環境の特性に合わせた優先度を提供できない場合でも、障害への対処が継続されるに従って自動的に適切な優先度へと修正されるため、対処時間が短縮され、誤った対処によって別の障害を引き起こす確率を低下させるという効果がある。さらに、与えられた対処コマンドに適切なものが含まれていれば、失敗によって優先度の低下した対処コマンドが実行される前に障害への対処が完了することになることため、サービス実行環境の特性によっては別の障害を引き起こす可能性の高い危険な対処コマンドを混在させた障害対処ルール群を用いた場合にも、悪影響を抑えた適切な障害対策が可能となるという効果がある。

本発明の実施の形態を説明する前に、図１、図２、図３を用いて本発明の前提となる障害復旧装置について説明する。

図１を参照すると、本発明の前提となる障害復旧装置は、サービス実行手段１０に接続された動作状態検出手段１およびコマンド実行手段４と、ルール蓄積手段２と、これらに接続された対処方法検索手段３とを含んで構成される。

サービス実行手段１０は、ＷＥＢサービスや業務サービスといった情報通信サービスを提供する。ルール蓄積手段２は、障害対処ルールを蓄積する。図２に障害対処ルールの例を示す。障害対処ルールは、障害が発生した場合の動作状態または障害の前兆と推測される動作状態を判定するための条件式と、その動作状態になった場合に障害を復旧または回避するための対処コマンドと、同じ条件式に対する対処コマンドの適用順序を示す優先度で構成される。図２の番号１および２のルールは、サービス実行手段１０のメモリ残量の数値が２０以下となった状態を障害とみなすための条件式と、その状態で実行すべき対処コマンドとしてアプリケーション（ＡＰ）再起動コマンドおよびオペレーティングシステム（ＯＳ）再起動コマンドがそれぞれ優先度８０、５０として定義されている。同様に、番号３〜５のルールは、ＡＰの出力が異常の場合に、ＡＰ再起動、ＯＳ再起動、ディスク切り替えがそれぞれ優先度８０、４０、３０で定義されている。

図３は、図１の障害復旧装置における動作のフローチャートを示す。動作状態検出手段１は、サービス実行手段１０の動作状態を検出する（図３のステップ１０１）。動作状態は、障害対処ルールの条件式に沿った形で検出される。図２の例では、メモリ残量やＡＰ出力の正常／異常等が検出される。対処方法探索手段３は、動作状態検出手段１から現在の動作状態を受け取り、ルール蓄積手段２に蓄積されている障害対処ルールの条件式に合致するものがあるかどうかを探索する（ステップ１０２）。合致する条件式が無い場合は、障害が発生していないものとして、ステップ１０１に戻る。合致する条件があった場合は、障害発生とみなして対応する対処コマンド探索する。例えば、検出された動作状態のうち、メモリ残量が２０未満であった場合は、図２の番号１および番号２の条件式に合致するため、対処コマンドとしてＡＰ再起動とＯＳ再起動が候補となるが、ＡＰ再起動の優先度の方が高いため、対処コマンドとしてＡＰ再起動を選択して出力する。この対処コマンドをコマンド実行手段４が受け取り、サービス実行手段１０にその実行を指示することで、サービス実行環境上のアプリケーションが再起動される（ステップ１０３）。この後、ステップ１０１に戻って動作状態検出手段１が、対処コマンド実行後の動作状態を検出する。ここで、メモリ残量が２０未満のままであれば（ステップ１０２）、次の対処コマンドとしてＯＳ再起動が実行される（ステップ１０３）。メモリ残量が２０以上になっていれば、合致する条件式がなくなり、障害への対処が完了する。

このように、図１に示す障害復旧装置では、予め決められた条件で対処コマンドを自動的に実行するため、障害対処ルールに記述された障害に関してはサービス実行手段１０の障害を自動的に復旧または回避することができる。この場合、優先度として予め決められた順序で対処コマンドが実行されることになり、一般的に成功する可能性の高い対処コマンドに高い優先度をつけることで、対処の効率を制御することができる。しかし、対処コマンドのうちどれが有効であるかは、サービス実行手段１０のハードウェア構成や実行ソフトウェアの種類の他、提供するサービスの内容や、運用継続によって変化する内部状態にも依存するものであり、常に効率的な優先度を定義することは困難である。このため、例えば図２の例でＡＰ再起動が常に失敗するようなサービス実行手段１０では、ＯＳ再起動の実行前に常にＡＰ再起動が失敗するのを待つ必要があり、対処にかかる時間が増大してしまう。また、ＡＰ再起動が失敗する理由によっては別の障害を引き起こす場合があり、対処自体ができなくなる可能性もある。

次に、本発明の実施の形態について図面を参照して詳細に説明する。

（第１の実施の形態）
先ず、図４、図５、図６、図７を用いて、本発明の第１の実施の形態について説明する。

図４は、本発明の第１の実施の形態の構成を示すブロック図である。この実施の形態の障害復旧装置では、図１の構成に加えて、対処コマンドを実行した後に変化すると予想される動作状態の変化情報を保持する状態レジスタ５と、この動作状態の変化情報と動作状態検出手段１の出力である動作状態を比較して、対処コマンドによる復旧または回避の成否を判定し、その結果に応じて優先度を修正する効果判定手段６を新たに有する。また、対処方法検索手段３は、現在の状態値に合致した対処コマンドを出力する際に、その対処コマンドを実行した後に変化すると予想される動作状態の変化情報を出力する機能を新たに有する。

動作状態検出手段１、対処方法検索手段３、コマンド実行手段４および効果判定手段６の各機能手段は、例えばコンピュータと障害復旧プログラムとで実現することができる。障害復旧プログラムは、磁気ディスク等のコンピュータ可読記録媒体に記録されて提供され、コンピュータの立ち上げ時などにコンピュータに読み取られ、コンピュータの動作を制御することにより、そのコンピュータ上に動作状態検出手段１、対処方法検索手段３、コマンド実行手段４および効果判定手段６の各機能手段を実現する。また、ルール蓄積手段２および状態レジスタ５は、コンピュータに備わる主記憶や外部記憶装置で実現可能である。

図５は、図４に示した障害復旧装置の動作のフローチャートを示す。図６、図７は、本実施の形態における障害対処ルールの優先度の変化例を示した図である。まず、初期状態として図２のような優先度である場合を例に本実施の形態の動作を説明する。

動作状態検出手段１は、サービス実行手段１０の動作状態を検出する（図５のステップ２０１）。次に、効果判定手段６が状態レジスタ５を参照し、既に実行された対処コマンドがあるかどうかを判定する（ステップ２０２）。実行された対処コマンドが無い場合には効果判定手段６は何もしない。対処方法探索手段３は、動作状態検出手段１から現在の動作状態を受け取り、ルール蓄積手段２に蓄積されている障害対処ルールの条件式に合致するものがあるかどうかを探索する（ステップ２０５）。例えば、メモリ残量が２０未満であった場合、図２の番号１および番号２の条件式に合致し、優先度の高いＡＰ再起動が選択される。この時、対処方法探索手段３は対処コマンドの出力と同時に、この対処コマンドを実行した後に変化すると予想される動作状態の変化情報を状態レジスタにセットする。この場合、対処コマンドの実行によってルール内の条件式で示される障害状態が回避されること、つまり、動作状態の１つであるメモリ残量が条件式に示される閾値である２０を超えることが予想されることから、実行する対処コマンドと対処が成功した場合の条件として「メモリ残量が２０以上」という条件を状態レジスタ５にセットする（ステップ２０６）。対処コマンドは、コマンド実行手段４を介してサービス実行手段１０上で実行される（ステップ２０７）。

この後、ステップ２０１に戻って動作状態検出手段１が、対処コマンド実行後のサービス実行手段１０の動作状態を検出する。効果判定手段６は、対処コマンドが実行されていることを検知して（ステップ２０２）、現在の動作状態と状態レジスタ５の「メモリ残量が２０以上」という条件を比較して効果を判定し（ステップ２０３）、対応する番号１のルールの優先度を修正する（ステップ２０４）。図６のルール群３０１は、ＡＰ再起動による復旧に失敗し、ＯＳ再起動による復旧に成功した場合の変化を示す。図６では、優先度の修正方法の一例として、成功した場合に優先度を１０増やし、失敗した場合に１０減らす例を示す。この場合、ＡＰ再起動後のステップ２０３で条件が満たされない（メモリ残量が閾値である２０未満であり障害状態が継続している）ことを判定して、番号１の優先度を８０から１０減らした７０とする。続いて、ステップ２０５からステップ２０７を経てＯＳ再起動を実行し、その後のステップ２０３で条件が満たされた（メモリ残量が閾値である２０を超え障害状態が回避された）ことを判定して、番号２の優先度を５０から１０増やした６０とする。

同様に、図６のルール群３０２では、同じメモリ残量の障害が発生し、ＡＰ再起動、ＯＳ再起動共に復旧に失敗した場合の優先度の変化を示す。番号１のルールの優先度は、さらに１０減った６０になり、番号２の優先度は、１０減った５０に戻っている。この時点では、まだ番号１のルールの方が優先度が高いため、新たな障害が発生した場合は、ＡＰ再起動が先に実行されることになる。次に、再度同じ障害が発生し、ＡＰ再起動による復旧が失敗、ＯＳ再起動による復旧が成功した場合を図６のルール群３０３に示す。この場合、番号１のルールはさらに１０減った５０になり、番号２のルールは１０増えて６０となる。ここで、２回成功した番号２のルールの優先度は、３回とも失敗した番号１よりも高くなり、次回同じ障害が発生した場合は、ＯＳ再起動が先に実行されることになる。

図７は、同様にしてＡＰ出力異常の障害が発生した場合の優先度の変化を示す。ルール群３０４は、図６のルール群３０３の状態で、ＡＰ出力が異常であることを検出し、番号３、４、５のルールが順に実行された例を示す。この場合、番号３、４の対処コマンドであるＡＰ再起動、ＯＳ再起動は共に復旧に失敗したため、優先度が１０づつ減っており、番号５のディスク切り替えによる復旧に成功したため、優先度が１０増えている。この時点で、番号４と番号５の優先度は逆転しており、次に、同じＡＰ出力異常が発生した場合、まず番号３のルールが適用されＡＰ再起動が行われるが、ＡＰ再起動による復旧に失敗した場合は、ディスク切り替えが実行される。ディスク切り替えによる復旧に成功した場合には、ここで対処が完了するため、番号４のＯＳ再起動が実行されることはない。このようにして、番号３の優先度が１０減り、番号５の優先度が１０増えると、図７のルール３０５のようになる。次に同じ障害で、またディスク切り替えによる復旧に成功する場合を考えると、やはり、ＡＰ再起動が試されて、次にディスク切り替えによる復旧が成功する。その後は、ルール群３０６に示すように、ディスク切り替えの優先度が最も高くなるため、同じ障害に対してはディスク切り替えが最初に実行されることになり、これが成功した場合には、他の対処コマンドが実行されることはなくなるため、不要な処理によって別の障害が引き起こされることを防止できる。

以上述べたように、第１の実施の形態にかかる障害復旧装置では、対処コマンドによる復旧または回避の成否を判定し、その結果に応じて優先度を修正する効果判定手段６を有することにより、特性の異なるサービス実行手段１０に同じルール群を適用した場合にも効率的な運用が可能になるという効果を得ることができる。

例えば図６は、継続運用でメモリ残量が減るような障害にＡＰプログラムのバグによるメモリリークが原因であるものが多いため、ＡＰ再起動の優先度を高くしておくといった運用効率化の例である。しかし、サービス実行手段１０の特性によっては、通常は問題とならないＯＳのバグが何らかの状態で発現している場合もあり、このような状況では、ＡＰ再起動の優先度が高いことが運用効率の低下を招く可能性もある。本実施の形態では、前述した通り、実際のサービス実行手段１０の特性に応じて優先度が自動的に最適化されることから、同じルール群を適用していても個々のサービス実行手段１０に適した障害対策を実現することができる。図７は、ＡＰ出力の異常がディスクにより引き起こされるような例である。ＡＰ出力の異常がＡＰ再起動で復旧できていたサービス実行手段１０であっても、例えばディスク交換等の修理を行った後に特性が変わってしまうといったように、新たなルールを適用しなければ効率的な運用が出来ない場合がある。従来の障害復旧装置では、このような状況をオペレータが把握し、その都度ルールを修正する必要があったが、本実施の形態では、このような場合でも適切な優先度に修正されるため、管理コストを増大させることなく、対処時間を減少させ、広い範囲の障害に対して決め細かな障害対策を行うことができる。

尚、本実施の形態で例に挙げた動作状態や対処コマンドについては、この例に限定されるものではなく、本発明の構成に従ってサービス実行手段１０で検出できる動作状態や実行可能な対処コマンドであれば同様の効果が得られるものである。また、優先度の数値や計算方法についても、対処コマンドの実行結果に従った修正を行うものであれば、対処コマンドを効率的に実行することができる。

（第２の実施の形態）
本実施の形態では、第１の実施の形態で説明した構成および動作に加えて、図８を用いて複数の障害が同時に発生した場合の動作の例を示す。対処方法検索手段３は、第１の実施の形態の機能に加えて、同じ条件式を有するルール群から優先度に応じて対処コマンドを１つづつ選択して対処コマンド群を生成した後、その対処コマンド群に含まれる対処コマンドを優先度の高い順に試行する機能を有する。

図８のルール群３０７は、図７のルール群３０６の状態からＡＰ出力異常が発生して番号５のルールによる復旧が成功し優先度が７０となった例を示す。この状態で、メモリ残量不足とＡＰ出力異常が同時に発生した場合、番号１ないし５の条件式がすべて有効となり、対処コマンドとして最大の優先度を持つ番号５のルールが適用され、対処コマンドとしてディスク切り替えが実行される。ルール群３０８は、ディスク切り替えによる復旧が失敗した場合の例を示し、番号５の優先度が１０減っている。この場合、障害は継続しているため、次の対処コマンドを探索することになり、候補として優先度が６０である番号２と番号５のルールが挙げられる。ここで、番号順に対処コマンドを実行するとすると、番号２のルールが適用され、ＯＳ再起動が実行される。ルール群３０９は、ＯＳ再起動による復旧が成功した場合の例を示し、番号２の優先度が１０増加している。

一般に、複数の障害が発生している場合、ある障害が派生して別の障害が併発した後に状態が検出されることが多い。このような状態から復旧するためには、それらの障害の根本原因となる障害に対処することが必要となる。図８のルール群３０７において、ディスク切り替えはＡＰ出力異常特有の対処コマンドであり、複合障害の場合にこのような対処コマンドを選択することは最適とは言えず、このような対処コマンドを実行している間にさらに状態を悪化させることもあり得る。本実施の形態では、このような対処コマンドを実行して失敗した場合、ルール群３０８、ルール群３０９に示すように、失敗したルールの優先度が低下し、結果的に条件式の異なるＯＳ再起動が実行されることになる。この結果、同時発生する障害に対応する条件式を持つ複数のルールの間で、同時発生時に優先すべきルールの優先度が相対的に増加し、次回以降同じ障害が発生した場合に効果の高いルールが先に選択されることになる。

さらに、対処方法検索手段３は、異なる条件式に共通する対処コマンドが存在する場合には、共通する対処コマンドを優先的に試行する機能を有することができる。図９、図１０を用いてこの例の障害復旧装置の動作を説明する。

図１０のルール群３２０は、図８のルール群３０７に相当する状態を示す。この時、動作状態検出手段１がサービス実行手段１０の動作状態からメモリ残量不足とＡＰ出力異常の両方が発生していることを検出する（ステップ２１１）。対処方法検索手段３は、ルール群３２０に示す番号１ないし５のルールの条件式に合致していることを知り（ステップ２１５）、異なる条件式を持つルールのうち共通する対処コマンドを有するルールを探索する（ステップ２１６）。ルール群３２０では、番号１と２のルールは同じ条件式を持ち、対処コマンドはＡＰ再起動とＯＳ再起動となる。同様に、番号３ないし５のルールの対処コマンドはＡＰ再起動、ＯＳ再起動、ディスク切り替えとなる。番号１と２のルール群、番号３ないし５のルール群に共通する対処コマンドはＯＳ再起動であり、対処方法検索手段３は、「メモリ残量が２０以上」と「ＡＰ出力が正常」という状態を予測して状態レジスタをセットし（ステップ２１７）、ＯＳ再起動を実行する（ステップ２１８）。

この後、ステップ２１１の状態検出を経て対処コマンドの終了を検出すると（ステップ２１２）、効果が判定され（ステップ２１３）、ルールの優先度が修正される（ステップ２１４）。ルール群３２１は、メモリ残量とＡＰ出力の両方が改善された場合の例を示し、対処コマンドがＯＳ再起動である番号２と４のルールの優先度が上昇する。ルール群３２２は、メモリ残量のみが改善された場合の例を示し、番号２のルールの優先度は上昇するが、番号４のルールの優先度は低下する。この場合、ＡＰ出力異常は継続しているため、さらに次の対処コマンドとして番号３ないし５のルールから優先度の高い番号５のルールが選択され、ディスク切り替えが行われることになる。このように、対処方法検索手段３が同時に状態を改善できる対処コマンドを優先的に実行することにより、複数の障害が同時に発生した場合でも短時間で復旧できる確率が増加し、さらに、継続して次の対処を行うことで着実に状態を改善することができる。

以上述べたように、本実施の形態の障害復旧装置では、複数の障害が同時に発生した場合にも、対処コマンドの成否に応じて、関連するルールの優先度が適切に修正されるという効果を得ることができる。また、共通する対処コマンドが存在する場合には、共通する対処コマンドを優先的に試行することで、復旧時間を短縮しつつ着実に障害復旧できる。

（第３の実施の形態）
本実施の形態では、第１の実施の形態で説明した優先度に変えて、過去の対処コマンド実行の結果として得られた状態変数の変化量を表す実績値を用いてルールの探索を行う例を示す。図１１のルール群４００は、本発明の前提例における図２のルール群３００において優先度が実績値に、番号３、４、５の条件式が変数とその閾値で構成される「ＣＰＵ使用率が５０より大きい」に置き換わったものを示す。つまり、本実施の形態においては、ルール蓄積手段２に蓄積されている障害対処ルールの条件式は、１または複数の状態変数とその閾値を規定する条件式となっている。以下、対処実行前後の状態変数の値の変化を実績値とした場合を例に、図１２、図１３、図１４を用いて本実施の形態の動作を説明する。

図１３は、図１１のルール群４００の状態において、メモリ残量不足が発生した場合の実績値の変化を示す。動作状態検出手段１がサービス実行手段１０の動作状態からメモリ残量不足を検出すると（ステップ５０１）、対処方法検索手段３が番号１と２のルールが条件に合致することを知り（ステップ５０４）、現在のメモリ残量に各々のルールの実績値を加えて条件式を満たさなくなるルールを探索する（ステップ５０５）。図１１のルール群４００は、対処コマンドを実行した実績がない状態であり、実績値は不明であるため番号の小さいルールとして番号１を選択する。さらに、現在のメモリ量が１８であった場合、「現在のメモリ残量が１８」および対処が成功した場合の条件として「メモリ残量が２０以上」という条件をルール番号１と共に状態レジスタ５にセットし（ステップ５０６）、ＡＰ再起動を実行する（ステップ５０７）。その後、ステップ５０１を経て、効果判定手段６が対処コマンドの終了を検知し（ステップ５０２）、現在状態から実績値が算出される（ステップ５０３）。図１３のルール群４０１では、メモリ残量が１８から２５に増えた例であり、番号１のルールの実績値として７が設定される。この場合、メモリ残量が２５であれば条件式を満たさなくなるため（ステップ５０４）、障害復旧が成功したものとして次の障害状態検出に戻る（ステップ５０１）。

同様に、ルール群４０２は、新たにメモリ残量が１５となった場合を示す。ステップ５０５において、番号１のルールの実績値６と現在のメモリ量１５を加えると条件式を満たさなくなることを知り、番号１のルールが実行される。この後、メモリ残量が２１になったことを検知すると（ステップ５０１）、対処コマンド実行前後の差分から実績値が６に変更される。ルール群４０３は、さらにメモリ残量が１２となった場合を示す。この場合、ステップ５０５において番号１のルールの実績値である６では障害を回避できないことを判断し、実績値が不明な番号２のルールが選択され、ＯＳ再起動が実行される。この後、メモリ残量が５０になった場合、番号２のルールの実績値として３８が設定される。

同様に、図１４は、メモリ残量不足が何度か発生した例を示す。ルール群４０４は、メモリ残量が１８となった場合であり、番号１のルールの実績値である７で障害復旧できることから番号１のルールが実行され、実績値が修正される。さらに、ルール群４０５では、メモリ残量が８となった場合を示し、番号１と番号２のルールの実績値から、障害を回避できるルールとして番号２のルールが選択される。ルール群４０６では、メモリ残量が１５であり、番号１のルールが選択される。このように、対処コマンドを実行した結果によって変化するメモリの増加量を実績値として保持することにより、障害時に条件式の閾値からどれだけ離れているかに応じて適用するルールを変化させることができる。

尚、本実施の形態では、適用したルールの実績値のみを修正する例で説明したが、これに限定されるものではなく、同じ対処コマンドを持つルールの実績値を同時に修正することもできる。例えば、図１３では、番号１のルールを選択してＡＰ再起動を実行する場合に、コマンド実行前後のＣＰＵ使用量を検出することで、同じ対処コマンドを持つ番号３のルールの実績値を算出することができる。この場合、同じ対処コマンドを持つルールを探索する処理は増加するが、効率的な実績値の算出が可能となる。

以上説明したように、本実施の形態によれば、実際のサービス運用の結果に応じて対処方法検索手段が各々の対処コマンドの実績値を算出することにより、同じ条件式に合致するルールであっても効果のあるルールを優先的に選択することができ、復旧時間が短縮し確実性が向上する。

以上、単一の障害が発生した場合の動作を説明したが、複数の障害が同時に発生した場合には、対処方法検索手段３は、同じ条件式を有するルール群から実績値に応じて対処コマンドを１つづつ選択して対処コマンド群を生成した後、その対処コマンド群に含まれる対処コマンドを、例えば実績値の高い順に試行する。また、対処方法検索手段３は、異なる条件式に共通する対処コマンドが存在する場合には、共通する対処コマンドを優先的に試行する。

（第４の実施の形態）
本実施の形態は、第１の実施の形態で説明した優先度と第３の実施の形態で説明した実績値とを用いてルールの探索を行う例を示す。図１５のルール群６００は、第３の実施の形態における図１４のルール群４０６に優先度を追加したものを示す。図１６は本実施の形態の動作のフローチャートを示す。

第１の実施の形態と同様に、動作状態検出手段１はサービス実行手段１０の動作状態を検出し（ステップ７０１）、効果判定手段６は状態レジスタ５を参照し、既に実行された対処コマンドがあるかどうかを判定する（ステップ７０２）。実行された対処コマンドが無い場合には効果判定手段６は何もしない。対処方法探索手段３は、動作状態検出手段１から現在の動作状態を受け取り、ルール蓄積手段２に蓄積されている障害対処ルールの条件式に合致するものがあるかどうかを探索する（ステップ７０５）。

例えば、メモリ残量が１０であった場合、図１５の番号１および番号２の条件式に合致する。第１の実施の形態では、優先度の高い番号１のルールのＡＰ再起動を選択し、第３の実施の形態では、現在のメモリ残量１０に各々のルールの実績値を加えると条件式を満たさなくなるルールを選択した。これに対し本実施の形態では、優先度および実績値の双方を考慮し、より優先度が高く且つ条件式を満たさなくなる実績値を持つルールを選択する（ステップ７０６）。図１５の場合、番号１のルールは、その優先度は８０で、番号２のルールの優先度５０より高いが、実績値が８であるため、現在のメモリ残量１０に８を足してもメモリ残量２０未満の条件が依然として成立するため、第１候補から除外され、メモリ残量２０未満という条件を満たさなくなる実績値４０を持つ番号２のルールが選択される。他方、現在のメモリ残量が１５であった場合、番号１のルールが、より優先度が高く且つ条件式を満たさなくなる実績値を持つルールとして選択される。各ルールの優先度の修正は第１の実施の形態と同様に効果判定手段６で行われ、各ルールの実績値の算出は第３の実施の形態と同様に効果判定手段６で行われる（ステップ７０３、７０４）。

以上述べたように、第４の実施の形態にかかる障害復旧装置では、対処コマンドによる復旧または回避の成否を判定し、その結果に応じて優先度を修正することにより、特性の異なるサービス実行手段１０に同じルール群を適用した場合にも効率的な運用が可能となるという効果と、実際のサービス運用の結果に応じて対処方法検索手段３が各々の対処コマンドの実績値を算出することにより、同じ条件式に合致するルールであっても効果のあるルールを優先的に選択することができ、復旧時間が短縮し確実性が向上するという効果とを得ることができる。

以上、単一の障害が発生した場合の動作を説明したが、複数の障害が同時に発生した場合には、対処方法検索手段３は、同じ条件式を有するルール群から優先度および実績値に応じて対処コマンドを１つづつ選択して対処コマンド群を生成した後、その対処コマンド群に含まれる対処コマンドを、例えば優先度の高い順に試行する。また、対処方法検索手段３は、異なる条件式に共通する対処コマンドが存在する場合には、共通する対処コマンドを優先的に試行する。

本発明の前提となる障害復旧装置の構成例を示すブロック図である。 ルール蓄積手段に蓄積される障害対処ルールの一例を示す図である。 本発明の前提となる障害復旧装置の動作を示すフローチャートである。 本発明の第１の実施の形態の構成例を示すブロック図である。 本発明の第１の実施の形態の動作を示すフローチャートである。 本発明の第１の実施の形態における障害対処ルールにおける優先度の変化の一例を示す図である。 本発明の第１の実施の形態における障害対処ルールにおける優先度の変化の別の例を示す図である。 本発明の第２の実施の形態における障害対処ルールにおける優先度の変化の別の例を示す図である。 本発明の第２の実施の形態の動作を示すフローチャートである。 本発明の第２の実施の形態における障害対処ルールにおける優先度の変化の別の例を示す図である。 本発明の第３の実施の形態におけるルール蓄積手段に蓄積される障害対処ルールの例を示す図である。 本発明の第３の実施の形態の動作の例を示すフローチャートである。 本発明の第３の実施の形態の障害対処ルールにおける実績値の変化例を示す図である。 本発明の第３の実施の形態の障害対処ルールにおける実績値の別の変化例を示す図である。 本発明の第４の実施の形態におけるルール蓄積手段に蓄積される障害対処ルールの例を示す図である。 本発明の第４の実施の形態の動作の例を示すフローチャートである。

符号の説明

１ 動作状態検出手段
２ ルール蓄積手段
３ 対処方法検索手段
４ コマンド実行手段
５ 状態レジスタ
６ 効果判定手段
１０ サービス実行手段

Claims (3)

1. サービス実行手段の動作状態を検出する動作状態検出手段と、
   前記サービス実行手段で障害が発生した場合の動作状態または障害の前兆と推測される動作状態を判定するための条件式とその動作状態になった場合に障害を復旧または回避するための対処コマンドとルール間の適用順序の優先度情報とを含む複数の障害対処ルールを蓄積するルール蓄積手段と、
   前記ルール蓄積手段から、前記動作状態検出手段で検出された前記サービス実行手段の現在の動作状態に合致する条件式を持つルールを取り出し、その優先度情報に応じて順次試行するとともに、前記現在の動作状態に合致した条件式の否定から前記対処コマンドを実行した後に変化すると予想される動作状態の変化情報を生成して状態レジスタに出力する対処方法検索手段と、
   前記状態レジスタに保持された動作状態の変化情報と前記動作状態検出手段の出力である前記対処コマンド実行後の前記サービス実行手段の動作状態を比較して、対処コマンドによる復旧または回避の成否を判定し、その結果に応じて前記優先度情報を修正する効果判定手段と、
   を含むことを特徴とする障害復旧装置。
2. ａ）動作状態検出手段が、サービス実行手段の動作状態を検出するステップ
   ｂ）対処方法検索手段が、前記サービス実行手段で障害が発生した場合の動作状態または障害の前兆と推測される動作状態を判定するための条件式とその動作状態になった場合に障害を復旧または回避するための対処コマンドとルール間の適用順序の優先度情報とを含む複数の障害対処ルールを蓄積するルール蓄積手段から、前記動作状態検出手段で検出された前記サービス実行手段の現在の動作状態に合致する条件式を持つルールを取り出し、その優先度情報に応じて順次試行するとともに、前記現在の動作状態に合致した条件式の否定から前記対処コマンドを実行した後に変化すると予想される動作状態の変化情報を生成して状態レジスタに出力するステップ
   ｃ）前記動作状態検出手段が、前記対処コマンド実行後の前記サービス実行手段の動作状態を検出するステップ
   ｄ）効果判定手段が、前記状態レジスタに保持された動作状態の変化情報と前記動作状態検出手段の出力である前記対処コマンド実行後の前記サービス実行手段の動作状態を比較して、対処コマンドによる復旧または回避の成否を判定し、その結果に応じて前記優先度情報を修正するステップ
   を含むことを特徴とする障害復旧方法。
3. コンピュータを、サービス実行手段の動作状態を検出する動作状態検出手段、前記サービス実行手段で障害が発生した場合の動作状態または障害の前兆と推測される動作状態を判定するための条件式とその動作状態になった場合に障害を復旧または回避するための対処コマンドとルール間の適用順序の優先度情報とを含む複数の障害対処ルールを蓄積するルール蓄積手段から、前記動作状態検出手段で検出された前記サービス実行手段の現在の動作状態に合致する条件式を持つルールを取り出し、その優先度情報に応じて順次試行するとともに、前記現在の動作状態に合致した条件式の否定から前記対処コマンドを実行した後に変化すると予想される動作状態の変化情報を生成して状態レジスタに出力する対処方法検索手段、前記状態レジスタに保持された動作状態の変化情報と前記動作状態検出手段の出力である前記対処コマンド実行後の前記サービス実行手段の動作状態を比較して、対処コマンドによる復旧または回避の成否を判定し、その結果に応じて前記優先度情報を修正する効果判定手段、として機能させるプログラム。
   

Images