JP2004287980A - 共有リソース障害検出システム及び方法 - Google Patents
共有リソース障害検出システム及び方法 Download PDFInfo
- Publication number
- JP2004287980A JP2004287980A JP2003080751A JP2003080751A JP2004287980A JP 2004287980 A JP2004287980 A JP 2004287980A JP 2003080751 A JP2003080751 A JP 2003080751A JP 2003080751 A JP2003080751 A JP 2003080751A JP 2004287980 A JP2004287980 A JP 2004287980A
- Authority
- JP
- Japan
- Prior art keywords
- monitoring
- shared resource
- failure
- shared
- agents
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Debugging And Monitoring (AREA)
Abstract
【課題】共有リソースの障害とパスの障害とを区別して検出できるようにする。
【解決手段】監視エージェント１２０−１〜１２０−３は、それぞれパス１４−１〜１４−３を介して共有装置１３−１を監視し、監視エージェント１２０−３〜１２０−５は、それぞれパス１４−４〜１４−６を介して共有装置１３−２を監視し、その監視結果を監視サーバ装置１１に通知する。監視サーバ装置１１内の監視結果収集部１１１ａは、この監視結果を領域１１２ｂに格納する。監視サーバ装置１１内の障害判別部１１１ｂは、領域１１２ａ中の共有装置−監視ジョブ関係情報に従い、障害検出の対象となる共有装置と関係する監視エージェントを全て特定し、領域１１２ｂに保持されている監視結果集合のうち、特定した監視エージェントの監視結果に従って、当該共有装置とパスの障害状態を判別する。
【選択図】 図１
【解決手段】監視エージェント１２０−１〜１２０−３は、それぞれパス１４−１〜１４−３を介して共有装置１３−１を監視し、監視エージェント１２０−３〜１２０−５は、それぞれパス１４−４〜１４−６を介して共有装置１３−２を監視し、その監視結果を監視サーバ装置１１に通知する。監視サーバ装置１１内の監視結果収集部１１１ａは、この監視結果を領域１１２ｂに格納する。監視サーバ装置１１内の障害判別部１１１ｂは、領域１１２ａ中の共有装置−監視ジョブ関係情報に従い、障害検出の対象となる共有装置と関係する監視エージェントを全て特定し、領域１１２ｂに保持されている監視結果集合のうち、特定した監視エージェントの監視結果に従って、当該共有装置とパスの障害状態を判別する。
【選択図】 図１
Description
【０００１】
【発明の属する技術分野】
本発明は、複数の装置から利用可能な共有リソースの障害を検出するための共有リソース障害検出システム及び方法に関する。
【０００２】
【従来の技術】
一般に、複数の装置から利用可能な共有リソース（共有装置）は、当該リソースの障害の検出という観点から２種類に分類される。第１の種類の共有リソースは、当該リソースに障害が発生した場合に、当該リソース自身がその障害を検出して他の装置に通知する機能を有する。これに対し、第２の種類の共有リソースは、当該リソースに障害が発生しても当該リソース自身がその障害を検出する機能を持たず、その障害を他の装置に通知することもできない。
【０００３】
一方、例えば特許文献１には、共有リソースの障害検出について記載されている。しかし、特許文献１には、上記第２の種類の共有リソースの障害を検出する際の問題については記載されていない。
【０００４】
【特許文献１】
特開２００１−３４４８８号公報（段落００２４、段落００２５、図３、図４）
【０００５】
【発明が解決しようとする課題】
上記第２の種類の共有リソースの障害を検出するには、当該共有リソースと当該共有リソースを監視する装置（監視装置）とをパス（例えば通信ケーブル）でつなぎ、このパスを介して監視装置が当該共有装置を監視する構成を適用することが考えられる。ここでは、監視装置は、パスを介して共有リソースに例えば定期的にアクセスし、当該リソースがリソースとしての機能を果たしているかを監視することにより、当該リソースの障害を検出することが可能である。このように、共有リソースの障害を当該共有リソースから教えてもらうことなく監視装置自身が検出することを、“共有リソースの障害を客観的に検出する”と表現する。
【０００６】
しかしながら上記した従来技術においては、監視装置が共有リソースの障害を客観的に検出したとしても、当該共有リソースに実際に障害が発生しているのか、監視装置と共有リソースとを結ぶパス（監視パス）に障害があって当該共有リソースとの間で通信が行えなかったために、結果として共有リソースに障害が発生したと判定されたのか、区別をつけることができない。即ち従来技術においては、共有リソースに障害が発生したのか、監視パスに障害が発生したのかを区別して検出することができなかった。
【０００７】
本発明は上記事情を考慮してなされたものでその目的は、共有リソースの障害とパスの障害とを区別して検出できる共有リソース障害検出システム及び方法を提供することにある。
【０００８】
【課題を解決するための手段】
本発明の１つの観点によれば、複数の装置から共有使用される少なくとも１つの共有リソースの障害を検出するための共有リソース障害検出システムが提供される。この共有リソース障害検出システムは、上記共有リソースをそれぞれ固有のパス経由で監視する複数の監視エージェントと、上記共有リソースと当該共有リソースと少なくとも１つのパスを介して接続される上記複数の監視エージェントとの対応関係を示す関係情報を保持する関係情報保持手段と、上記複数の監視エージェントの監視結果を収集する監視結果収集手段と、この監視結果収集手段により収集された監視結果の集合を保持する監視結果集合保持手段と、上記関係情報保持手段に保持されている関係情報に従って、障害検出の対象となる共有リソースと関係する監視エージェントを全て特定し、上記監視結果集合保持手段に保持されている監視結果集合のうち、特定した全ての監視エージェントの監視結果に従って、当該共有リソースと当該共有リソースにつながるパスの障害状態を判別する障害判別手段とを備えたことを特徴とする。
【０００９】
このような構成において、複数の監視エージェントが共有リソースをそれぞれ固有のパス経由で監視することにより得られる監視結果は、監視結果収集手段により収集されて監視結果集合保持手段に保持される。障害判別手段は、関係情報保持手段に保持されている関係情報に従って、障害検出の対象となる共有リソースと関係する監視エージェントを全て特定し、この特定した監視エージェントの監視結果に従って、当該共有リソースと当該共有リソースにつながるパスの障害状態を判別する。これにより、共有リソースの障害とパスの障害とを区別して検出できる。ここで、障害判別手段による上記処理が、監視結果集合保持手段に保持されている監視結果集合中の監視結果が更新される都度行われる構成とするとよい。また障害判別手段による障害状態の判別には、上記特定された全ての監視エージェントの監視結果がいずれも異常を表しているならば、対応する共有リソースの障害であり、一部の監視結果のみが異常を表しているならば、対応する共有リソースにつながるパスの障害であると判別される論理を適用するとよい。
【００１０】
また、上記少なくとも１つの共有リソースを含む複数の共有リソースがネットワークを構成する要素である場合に、上記複数の監視エージェントが、このネットワークに接続された所定の装置と通信をすることにより当該所定の装置に至る上記ネットワークの経路上の共有リソース及びパスを含む監視対象を監視する構成とすることも可能である。この構成においては、ネットワーク監視システムが構築できる。
【００１１】
また、上記関係情報が、上記ネットワークを構成する各共有リソースと当該共有リソースを監視対象として含む監視エージェントとの対応関係をトポロジーを含めてツリー構造で示すデータ構造を有し、上記障害判別手段が、このデータ構造の関係情報に従って、ルートにより近い共有リソースから順に障害検出の対象として選択し、その都度選択した共有リソースと関係する監視エージェントを全て特定する構成とするならば、共有リソースの障害検出が効率的に行える。特に、上記関係情報保持手段、監視結果収集手段、監視結果集合保持手段及び障害判別手段が、上記ネットワークを利用する複数のコンピュータを管理する統合システム管理サーバ装置に設けられる構成とすると共に、当該統合システム管理サーバ装置に、上記障害判別手段の障害判別結果を表す障害情報の通知を出力する障害通知手段を備えるとよい。ここで、障害情報通知は、上記統合システム管理サーバ装置の管理下にあるコンピュータは勿論、当該サーバ装置の管理下にないコンピュータにも出力可能である。また、上記障害情報通知を、上記サーバ装置のユーザインタフェースを介してユーザ（管理者）に出力することも可能である。この障害情報通知を用いて障害検出箇所を通知することにより、例えば上記サーバ装置により管理されているコンピュータの経路情報を操作できる。また、統合システム管理サーバ装置における処理と監視エージェントのプロセスを分離することにより、トポロジー的に分けてネットワーク監視が行え、サーバ装置側での負荷を軽減できる。なお、上記共有リソース障害検出システムに係る本発明は、上述の障害通知手段を備え、障害検出箇所の通知を出力する統合システム管理サーバに係る発明としても成立する。
【００１２】
次に上記関係情報保持手段、監視結果収集手段、監視結果集合保持手段及び障害判別手段が、クラスタシステムを構成する複数のコンピュータにまたがって構築されるクラスタマネージャに設けられると共に、上記複数の監視エージェントが、それぞれ同一の共有リソースを監視するように上記複数のコンピュータに分散して設けられる構成とし、更に上記クラスタマネージャが、コンピュータ毎に、上記障害判別手段を利用して、上記関係情報の示す最上位の階層の共有リソースの障害の有無の判別結果を取得し、当該判別結果をもとに当該コンピュータから他のコンピュータへのサービスの引き継ぎまたは当該コンピュータでのサービス提供の停止を実施するか否かを決定する状態決定手段を備えている構成とすることも可能である。
【００１３】
このような構成においては、障害が発生したコンピュータから他のコンピュータへのサービスの引き継ぎまたは当該コンピュータでのサービス提供の停止を実施するか否かを決定する状態決定処理が障害判別手段を利用してクラスタマネージャにより行われる。これにより、クラスタシステムの特徴である、当該システム内に或るコンピュータに障害が発生した場合のサービス引き継ぎまたはサービス提供防止が適切に行われ、連続的にサービスが移動する現象（連続フェイルオーバー）を防止できる。
【００１４】
【発明の実施の形態】
以下、本発明の実施の形態につき図面を参照して説明する。
【００１５】
［第１の実施形態］
図１は本発明の第１の実施形態に係る共有リソース障害検出システムの構成を示すブロック図である。図１のシステムは、監視サーバ装置１１と、複数台の監視エージェント装置、例えば５台の監視エージェント装置１２−１乃至１２−５とを備えている。
【００１６】
監視サーバ装置１１は監視エージェント装置１２−１乃至１２−５を利用して、少なくとも１台の共有装置、例えば２台の共有装置１３−１（＃１）及び１３−２（＃２）の障害を検出する。共有装置１３−１及び１３−２は複数の装置（図示せず）により共用される共有リソースである。共有装置１３−１及び１３−２には、それぞれ識別番号＃１及び＃２が割り当てられているものとする。
【００１７】
監視エージェント装置１２−１乃至１２−５は例えばカード上に構築され、１つの筐体に実装されているものとする。勿論、各監視エージェント装置１２−１乃至１２−５が、それぞれ独立した筐体に実装されるものであっても構わない。監視エージェント装置１２−１乃至１２−５は少なくとも１台の共有装置を監視する。ここでは、監視エージェント装置１２−１及び１２−２は共有装置１２−１を監視し、監視エージェント装置１２−３は共有装置１３−１及び１３−２を監視し、監視エージェント装置１２−４及び１２−５は共有装置１３−２を監視する。そのため、監視エージェント装置１２−１及び１２−２と共有装置１２−１とは、それぞれ監視用のパス（監視パス）１４−１及び１４−２により接続され、監視エージェント装置１２−３と共有装置１３−１及び１３−２とは、それぞれ監視用のパス１４−３及び１４−４により接続され、監視エージェント装置１２−４及び１２−５と共有装置１３−２とは、それぞれ監視用のパス１４−５及び１４−６により接続される。パス１４−１乃至１４−６は、例えば通信ケーブルである。
【００１８】
監視エージェント装置１２−１乃至１２−５上では、それぞれ監視エージェント１２０−１乃至１２０−５が動作する。監視エージェント１２０−１乃至１２０−５は、それぞれ少なくとも１つの監視ジョブを含む。監視ジョブとは、監視エージェントが監視を行う最小単位である。ここでは、各監視ジョブは、パスと当該パスに接続される共有装置を１セットとして監視対象にしている。図１の例では、監視エージェント１２０−１は、共有装置１３−１及びパス１４−１の組を監視対象とする監視ジョブ１２１（＃１）を含み、監視エージェント１２０−２は、共有装置１３−１及びパス１４−２の組を監視対象とする監視ジョブ１２２（＃２）を含む。監視エージェント１２０−３は、共有装置１３−１及びパス１４−３の組を監視対象とする監視ジョブ１２３−１（＃３−１）と、共有装置１３−２及びパス１４−４の組を監視対象とする監視ジョブ１２３−２（＃３−２）とを含む。監視エージェント１２０−４は、共有装置１３−２及びパス１４−５の組を監視対象とする監視ジョブ１２４を含み、監視エージェント１２０−５は、共有装置１３−２及びパス１４−６の組を監視対象とする監視ジョブ１２５を含む。各監視ジョブは、それぞれ対応する監視対象を定期的に監視し、監視結果を得る。このように、監視結果は、監視ジョブ単位に存在する。この監視ジョブ単位の監視結果は２種ある。１つは、監視対象に問題点が発見できなかった「正常」という状態を示す監視結果である。もう１つは、監視対象に問題点が発見された「異常」という状態を示す監視結果である。監視エージェント１２０−１乃至１２０−５は、当該エージェント内の全監視ジョブを定期的に監視して、当該監視ジョブにより得られた監視結果を監視サーバ装置１１に送信する。
【００１９】
監視サーバ装置１１は、監視サーバ１１１と、記憶装置１１２と、通信部１１３と、入力部１１４とを備えている。監視サーバ１１１は、監視サーバ装置１１上で動作して、共有装置１３−１及び１３−２の障害を検出する機能を有する。更に具体的に述べるならば、監視サーバ１１１は、監視エージェント１２０−１乃至１２０−５によって取得された監視結果の集合に基づき、共有装置１３−１もしくは１３−２、またはパス１４−１乃至１４−６のいずれに異常があるかを判別する機能を有する。
【００２０】
監視サーバ１１１は、監視結果収集部１１１ａ、障害判別部１１１ｂ及び設定部１１１ｃを含む。監視結果収集部１１１ａは、監視エージェント１２０−１乃至１２０−５から送信される監視結果を通信部１１３を介して受け取って収集する。障害判別部１１１ｂは、監視結果収集部１１１ａにより収集された監視結果の集合に基づいて、共有装置１３−１もしくは１３−２、またはパス１４−１乃至１４−６のいずれに異常があるかを判別する。設定部１１１ｃは、ユーザ（管理者）の操作による入力部１１４からの入力に従い、監視対象に含まれる共有装置と当該監視対象を監視する監視ジョブとの対応関係を示す情報（共有装置−監視ジョブ関係情報）を次に述べる共有装置−監視ジョブ関係情報領域１１２ａに設定する。
【００２１】
記憶装置１１２の記憶領域の一部は、共有装置−監視ジョブ関係情報領域１１２ａと監視結果集合記憶領域１１２ｂとに用いられる。共有装置−監視ジョブ関係情報領域１１２ａは、監視対象に含まれている共有装置と当該監視対象を監視する監視ジョブとの対応関係を表す共有装置−監視ジョブ関係情報を格納するのに用いられる。図２は共有装置−監視ジョブ関係情報領域１１２ａに格納される共有装置−監視ジョブ関係情報のデータ構造例を示す。ここでは、共有装置１３−１（＃１）は監視ジョブ１２１（＃１），１２２（＃２）及び１２３−１（＃３−１）によって監視され、共有装置１３−２（＃２）は監視ジョブ１２３−２（＃３−２），１２４（＃４）及び１２５（＃５）によって監視されることが示されている。監視結果集合記憶領域１１２ｂは、監視結果収集部１１１ａにより収集された監視結果の集合を格納するのに用いられる。図３は監視結果集合のデータ構造例を示す。
【００２２】
通信部１１３は外部装置との間でデータを送受信する。この通信部１１３で受信されるデータに、各監視エージェント１２０−１乃至１２０−５から送信される監視結果がある。入力部１１４はユーザ（管理者）の操作に応じてデータを入力する。
【００２３】
次に、図１のシステムにおける動作を、監視サーバ装置１１上の監視サーバ１１１の処理を中心に、図４のフローチャートを参照して説明する。まず、監視エージェント装置１２−１乃至１２−５上では、それぞれ監視エージェント１２０−１乃至１２０−５が動作している。また、監視エージェント１２０−１及び１２０−２上では、それぞれ監視ジョブ１２１（＃１）及び１２２（＃２）が動作して、パス１４−１及び１４−２を介して共有装置１３−１（＃１）を定期的に監視している。同様に、監視エージェント１２０−３上では、２つの監視ジョブ１２３−１（＃３−１）及び１２３−２（＃３−２）が並行して動作して、それぞれパス１４−３及び１４−４を介して共有装置１３−１（＃１）及び１３−２（＃２）を定期的に監視している。また、監視エージェント１２０−４及び１２０−５上では、それぞれ監視ジョブ１２４（＃４）及び１２５（＃５）が動作して、パス１４−５及び１４−６を介して共有装置１３−２（＃２）を定期的に監視している。但し、各監視ジョブは共有装置自体の障害は検出できず、当該共有装置を接続するパスと当該共有装置との組（監視対象）全体の障害として検出する。つまり各監視ジョブは、自身に固有の監視対象を定期的に監視し、その監視結果（監視対象の正常または異常）を取得する。
【００２４】
監視エージェント１２０−１乃至１２０−５は、当該エージェント上で動作する監視ジョブ＃ｉ（ここでは１つまたは２つの監視ジョブ）を定期的に監視して、当該監視ジョブ＃ｉで得られた監視結果を監視サーバ装置１１に送信する。この監視結果は監視サーバ装置１１内の通信部１１３で受信されて監視サーバ１１１内の監視結果収集部１１１ａに渡される。
【００２５】
監視結果収集部１１１ａは、監視ジョブ＃ｉで得られた監視結果を通信部１１３から受け取ると、記憶装置１１２の監視結果集合記憶領域１１２ｂにアクセスする。次に監視結果収集部１１１ａは、監視結果集合記憶領域１１２ｂに格納されている監視結果集合に含まれている、監視ジョブ＃ｉに対応する監視結果を、今回受け取った最新の監視結果に更新する。そして監視結果収集部１１１ａは、監視結果集合記憶領域１１２ｂの内容が更新されたことを監視サーバ１１１内の障害判別部１１１ｂに通知する。
【００２６】
障害判別部１１１ｂは監視結果収集部１１１ａからの更新通知に応じて起動され、まず共有装置を示す識別番号＃Ｎを初期値１に設定する（ステップＳ１，Ｓ２）。そして障害判別部１１１ｂは記憶装置１１２内の共有装置−監視ジョブ関係情報領域１１２ａを参照し、識別番号＃Ｎで指定される共有装置＃Ｎが存在するならば（ステップＳ３）、当該共有装置＃Ｎを監視している（つまり共有装置＃Ｎを監視対象として含む）全ての監視ジョブ＃ｊを特定する（ステップＳ４）。Ｎ＝１の場合、共有装置＃１（つまり共有装置１３−１）を監視している監視ジョブ＃ｊは、監視ジョブ＃１，＃２及び＃３−１（つまり監視ジョブ１２１，１２２及び１２３−１）の３台である。
【００２７】
次に障害判別部１１１ｂは記憶装置１１２内の監視結果集合記憶領域１１２ｂを参照し、特定した全ての監視ジョブ＃ｊの監視結果がいずれも「正常」であるか否かを判定する（ステップＳ５）。もし、１つでも「異常」を表す監視結果が含まれているならば、障害判別部１１１ｂは、特定した全ての監視ジョブ＃ｊの監視結果がいずれも「異常」であるかを判定する（ステップＳ６）。即ち障害判別部１１１ｂは、共有装置＃Ｎを監視している全ての監視ジョブ＃ｊの監視結果がいずれも「異常」であるかを判定する。ここでは、共有装置＃Ｎに対するパスが全て障害となることはないものとしている。
【００２８】
もし、共有装置＃Ｎを監視している全ての監視ジョブ＃ｊの監視結果がいずれも「異常」であるならば、障害判別部１１１ｂは当該共有装置＃Ｎに障害があると判定する。即ち障害判別部１１１ｂは、共有装置＃Ｎに障害が発生したことを検出する（ステップＳ７）。これに対し、共有装置＃Ｎを監視している全ての監視ジョブ＃ｊの監視結果のうちの一部だけが「異常」であるならば、障害判別部１１１ｂは共有装置＃Ｎには障害はなく、「異常」を表す監視結果を取得した監視ジョブの監視対象に含まれるパスに障害があると判定する。即ち障害判別部１１１ｂは、「異常」を表す監視結果を取得した監視ジョブの監視経路をなすパスに障害が発生したことを検出する（ステップＳ８）。このように障害判別部１１１ｂは、監視ジョブ＃ｊでは区別できない、当該監視ジョブ＃ｊの監視対象に含まれている共有装置とパスの障害を区別して検出することができる。
【００２９】
障害判別部１１１ｂは、ステップＳ５で全ての監視ジョブ＃ｊの監視結果がいずれも「正常」であると判定した場合は直ちに、「異常」を表す監視結果が含まれていると判定した場合には、ステップＳ７またはＳ８を実行した後に、識別番号＃Ｎを１インクリメントする（ステップＳ９）。そして、このインクリメント後の識別番号＃Ｎで指定される共有装置＃Ｎが存在するならば（ステップＳ３）、障害判別部１１１ｂは当該共有装置＃Ｎの障害を検出（判定）するために、ステップＳ４以降の処理を再度実行する。これに対し、インクリメント後の識別番号＃Ｎで指定される共有装置＃Ｎが存在しないならば、障害判別部１１１ｂは、監視結果集合の更新に伴う全ての共有装置の障害検出処理を終了したものと判断し、監視結果集合が再び更新されるのを待つ（ステップＳ１）。
【００３０】
［第２の実施形態］
次に、本発明の共有リソース障害検出システムを統合管理システムに適用した第２の実施形態について図面を参照して説明する。図５は本発明の第２の実施形態に係る統合管理システムの構成を示すブロック図である。図５のシステムは、統合システム管理サーバ装置２１と、複数台のコンピュータ、例えば７台のコンピュータ２２−０乃至２２−６と、監視対象となる共有リソースと接続されたコンピュータ（以下、対象コンピュータと称する）２３とを備えている。対象コンピュータ２３は、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）／ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ネットワークにおけるｐｉｎｇ（ｐａｃｋｅｔ ｉｎｔｅｒｎｅｔ ｇｒｏｐｅｒ）コマンドに対する応答を返す機能を有する。ｐｉｎｇは、ＴＣＰ／ＩＰネットワークにおいてネットワークの接続状態を検査するのに用いられるコマンドである。即ちｐｉｎｇは、ＩＰパケットが送信先のノードまで到達しているかを調べるために利用されるコマンドであり、ＩＣＭＰ（Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ）のエコー要求を使って実行される。
【００３１】
統合システム管理サーバ装置２１は、システム全体の管理の効率化、信頼性の向上化をさせるために置かれる中央集中型の管理装置である。統合システム管理サーバ装置２１はコンピュータ２２−０を含む複数のコンピュータを管理する。統合システム管理サーバ装置２１は、コンピュータ２２−１乃至２２−６を利用して、コンピュータ２２−０を含む複数のコンピュータ（端末）によって使用される少なくとも１台の共有リソース、例えば４台のハブ２４−１（＃１）乃至２４−４（＃４）により実現されるネットワークを監視するネットワーク監視システム（共有リソース障害検出システム）を構成する。統合システム管理サーバ装置２１によって検出された障害などの情報（例えば障害検出箇所の情報）は、当該サーバ装置２１のユーザ（例えば管理者）、当該サーバ装置２１によって管理されるコンピュータ、例えばコンピュータ２２−０、更にはそれ以外のコンピュータに提供される。このコンピュータ２２−０上では、通信アプリケーション（通信ＡＰＬ）２２０が、統合システム管理サーバ装置２１上の監視サーバ２１１及びコンピュータ２２−１乃至２２−６上の監視エージェント２２０−１乃至２００−６とは独立して動作し、ネットワーク監視システムにより監視されるネットワークを用いて他の装置と通信を行っている。コンピュータ２２−０は、統合システム管理サーバ装置２１内の障害通知部２１５から通信部２１３（図６参照）を介して通知される障害情報をもとに、可能な限り正常に通信が行えるよう経路情報を絶えず変更する。
【００３２】
ハブ２４−１乃至２４−４は、コンピュータ２２−０を含む複数の端末を相互に接続する集線装置である。ハブ２４−１乃至２４−４は、コンピュータ２２−０を含む複数の端末が接続されるネットワーク（ネットワーク環境）を構成する。ここでは、コンピュータ２２−０は、パス２５−１を介してハブ２４−１と接続され、当該ハブ２４−１からパス２５−２を介してハブ２４−４と接続されている。コンピュータ２２−０はまた、パス２５−３を介してハブ２４−２と接続され、当該ハブ２４−２からパス２５−４を介してハブ２４−３と接続されている。ハブ２４−３はパス２５−５を介してハブ２４−４と接続されている。このハブ２４−４には、パス２５−６を介して対象コンピュータ２３も接続されている。ハブ２４−１乃至２４−４には、それぞれ識別番号＃１乃至＃４が割り当てられているものとする。パス２５−１乃至２５−５は、例えば通信ケーブルである。
【００３３】
コンピュータ２２−１乃至２２−６上では、図１中の監視エージェント（１２０−１乃至１２０−４）に相当する監視エージェント２２０−１乃至２２０−６が動作する。監視エージェント２２０−１乃至２２０−６は、少なくとも１台の、共有リソースとしてのハブを監視する。ここでは、監視エージェント２２０−１及び２２０−２は、それぞれ監視ジョブ２２１−１及び２２１−２を有しており、当該監視ジョブ２２１−１及び２２１−２により、いずれもハブ２４−１（＃１）及びハブ２４−４（＃４）を介して対象コンピュータ２３に至る経路を監視する。監視エージェント２２０−３及び２２０−４は、それぞれ監視ジョブ２２１−３及び２２１−４を有しており、当該監視ジョブ２２１−３及び２２１−４により、いずれも、ハブ２４−２（＃２）、ハブ２４−３（＃３）及びハブ２４−４（＃４）を介して対象コンピュータ２３に至る経路を監視する。監視エージェント２２０−５は監視ジョブ２２１−５を有しており、当該監視ジョブ２２１−５により、ハブ２４−３（＃３）及びハブ２４−４（＃４）を介して対象コンピュータ２３に至る経路を監視する。監視エージェント２２０−６は監視ジョブ２２１−６を有しており、当該監視ジョブ２２１−６により、ハブ２４−４（＃４）を介して対象コンピュータ２３に至る経路を監視する。監視ジョブ２２１−１（＃１）乃至２２１−６（＃６）は、図１中の監視ジョブと同様に、監視エージェントが監視を行う最小単位であり、パスと当該パスに接続される共有リソース（ハブ）を１セットとして監視対象とする。
【００３４】
上記監視のため、監視エージェント２２０−１及び２２０−２が動作するコンピュータ２２−１及び２２−２とハブ２４−１とは、それぞれ監視用のパス（監視パス）２６−１及び２６−２により接続される。また、監視エージェント２２０−３及び２２０−４が動作するコンピュータ２２−３及び２２−４とハブ２４−２とは、それぞれ監視用のパス２６−３及び２６−４により接続される。また、監視エージェント２２０−５が動作するコンピュータ２２−５とハブ２４−３とは監視用のパス２６−５により接続され、監視エージェント２２０−６が動作するコンピュータ２２−６とハブ２４−４とは監視用のパス２６−６により接続される。パス２６−１乃至２６−６は、パス２５−１乃至２５−５と同様に通信ケーブルである。
【００３５】
図６は図５中の統合システム管理サーバ装置２１のブロック構成を示す。統合システム管理サーバ装置２１は、監視サーバ２１１と、記憶装置２１２と、通信部２１３と、入力部２１４と、障害通知部２１５とを備えている。監視サーバ２１１、記憶装置２１２、通信部２１３及び入力部２１４は、図１中の監視サーバ装置１１が有する監視サーバ１１１、記憶装置１１２、通信部１１３及び入力部１１４に相当する。障害通知部２１５は、次に述べる監視サーバ２１１内の障害判別部２１１ｂによる障害判別結果を示す障害情報（例えば障害検出箇所の情報）を、統合システム管理サーバ装置２１により管理されているコンピュータ、例えばコンピュータ２２−０に通信部２１３を介して通知すると共に、統合システム管理サーバ装置２１のユーザ（管理者）に表示画面等のユーザインタフェースを介して通知（提供）する。
【００３６】
監視サーバ２１１は、監視結果収集部２１１ａ、障害判別部２１１ｂ及び設定部２１１ｃを含む。監視結果収集部２１１ａは、監視エージェント２２０−１乃至２２０−６から送信される監視結果を通信部２１３を介して受け取って収集する。障害判別部２１１ｂは、監視結果収集部２１１ａにより収集された監視結果の集合に基づいて、ハブ２４−１，２４−２，２４−３もしくは２４−４、またはハブ以外の経路（ＮＩＣ、パスもしくはハブポート）のいずれに異常があるかを判別する。設定部２１１ｃは、ユーザ（管理者）の操作による入力部２１４からの入力に従い、監視対象に含まれるハブと当該監視対象を監視する監視ジョブとの対応関係を示す情報を、トポロジー（ネットワーク接続形態）を含めてツリー構造で次に述べるハブ−監視ジョブ関係情報領域２１２ａに設定する。
【００３７】
記憶装置２１２の記憶領域の一部は、ハブ−監視ジョブ関係情報領域２１２ａと監視結果集合記憶領域２１２ｂとに用いられる。ハブ−監視ジョブ関係情報領域２１２ａは、監視対象に含まれているハブと当該監視対象を監視する監視ジョブとの対応関係をトポロジーを含めてツリー構造で表すハブ−監視ジョブ関係情報を格納するのに用いられる。監視結果集合記憶領域２１２ｂは、監視結果収集部２１１ａにより収集された監視結果の集合を格納するのに用いられる。この監視結果集合のデータ構造は、監視ジョブの数を除き、図３と同様である。
【００３８】
図７はハブ−監視ジョブ関係情報領域２１２ａに格納されるハブ−監視ジョブ関係情報のデータ構造例を示す。図７の例では、ハブ２４−１（＃１）は、監視ジョブ２２１−１（＃１）及び２２１−２（＃２）によって監視され、ハブ２４−２（＃２）は、監視ジョブ２２１−３（＃３）及び２２１−４（＃４）によって監視されることが示されている。また、ハブ２４−３（＃３）はハブ２４−２（＃２）の上位階層に位置し、監視ジョブ２２１−３（＃３）及び２２１−４（＃４）、並びに監視ジョブ２２１−５（＃５）によって監視されることが示されている。また、ハブ２４−４（＃４）はハブ２４−１（＃１）及び２４−３（＃３）の上位階層に位置し、監視ジョブ２２１−１（＃１）及び２２１−２（＃２）、並びに監視ジョブ２２１−３（＃３）及び２２１−４（＃４）、並びに監視ジョブ２２１−５（＃５）、並びに監視ジョブ２２１−６（＃６）によって監視されることが示されている。
【００３９】
図８は、コンピュータとハブとがパス（通信ケーブル）により接続される接続形態の詳細を、コンピュータがコンピュータ２２−６で、ハブがハブ２４−６で、パスがパス２６−１である場合を例に示す。同図に示すように、コンピュータ２２−６はネットワークインタフェースカードＮＩＣ（図１中の監視サーバ装置１１の通信部１１３に相当）を有している。このネットワークインタフェースカードＮＩＣは、ハブ２４−６が有する複数のハブポートＰの１つとパス２６−６により接続されている。この接続形態は、他のコンピュータとハブとの間でも同様である。
【００４０】
次に、図のシステムにおける動作を、統合システム管理サーバ装置２１上の監視サーバ２１１の処理を中心に、図９のフローチャートを参照して説明する。まず、コンピュータ２２−１乃至２２−６上では、それぞれ監視エージェント２２０−１乃至２２０−６が動作している。また、監視エージェント２２０−１乃至２２０−６上では、それぞれ監視ジョブ２２１−１乃至２２１−６が定期的に動作して、それぞれパス２６−１乃至２６−６を介して、対象コンピュータ２３向けのｐｉｎｇコマンドを実行することにより、対応する監視対象を監視している。ここでは、監視ジョブ２２１−１乃至２２１−６の監視結果は２種ある。１つは、監視対象に問題点が発見できなかった「正常」という状態を示す監視結果である。具体的には、ｐｉｎｇコマンドの実行により当該監視ジョブ２２１−１乃至２２１−６から対象コンピュータ２３宛てに送信されたエコー要求のパケットに対する応答が予め定められた制限時間内に返ってきた場合の監視結果である。もう１つは、監視対象に問題点が発見された「異常」という状態を示す監視結果である。具体的には、上記「正常」を示す条件が成立しなかった場合であり、例えば上記エコー要求のパケットに対する応答が上記制限時間内に返ってこなかった場合の監視結果である。
【００４１】
監視エージェント２２０−１乃至２２０−６は、それぞれ監視ジョブ２２１−１乃至２２１−６を定期的に監視して、当該監視ジョブにより得られた監視結果を統合システム管理サーバ装置２１に送信する。この監視結果は統合システム管理サーバ装置２１内の通信部２１３で受信されて、監視サーバ２１１内の監視結果収集部２１１ａに渡される。
【００４２】
監視結果収集部２１１ａは、監視ジョブ＃ｉで得られた監視結果を受け取ると、記憶装置２１２の監視結果集合記憶領域２１２ｂに格納されている監視結果集合に含まれている、監視ジョブ＃ｉに対応する監視結果を、今回受け取った最新の監視結果に更新する。
【００４３】
監視サーバ２１１内の障害判別部２１１ｂは、監視結果収集部２１１ａにより、監視ジョブ＃ｉに対応する監視結果が更新されると（ステップＳ１１）、ハブ−監視ジョブ関係情報領域２１２ａに格納されているハブ−監視ジョブ関係情報を参照し、ルートに最も近いハブをハブＸとして選択する（ステップＳ１２）。ここでは、ハブＸとして、ハブ２４−４（＃４）が選択される。次に障害判別部２１１ｂは、ハブ−監視ジョブ関係情報に従い、当該ハブＸを監視対象として含む監視ジョブを全て特定する（ステップＳ１３）。ハブＸがハブ２４−４（＃４）の場合、当該ハブＸを監視対象として含む監視ジョブは監視ジョブ２２１−１（＃１）乃至２２１−６（＃６）である。
【００４４】
次に障害判別部２１１ｂは、ハブＸを監視対象として含む監視ジョブの監視結果が全て正常かを判定する（ステップＳ１４）。もし、ハブＸを監視する監視ジョブの監視結果が全て「正常」である場合、監視サーバ２１１は、ハブＸより下位に位置するハブが存在するならば、当該ハブＸは勿論、当該ハブＸより下位に位置するハブも全て「正常」であり、処理済みであるとする（ステップＳ１５ａ）。また監視サーバ２１１は、後述するステップＳ１５ｂも実行する。そして監視サーバ２１１は、上記ハブ−監視ジョブ関係情報を再び参照し、ハブＸの次にルートに近い未処理のハブがあるならば、そのハブを新たなハブＸとして選択する（ステップＳ１６，Ｓ１７）。続いて障害判別部２１１ｂは、新たなハブＸについて上記ステップＳ１３から始まる処理を実行する。
【００４５】
一方、ハブＸを監視する監視ジョブの監視結果の中に「異常」を表す監視結果が１つでもあるならば（ステップＳ１４）、障害判別部２１１ｂは、ハブＸを監視する監視ジョブの監視結果が全て「異常」であるかを判定する（ステップＳ１８）。もし、ハブＸを監視する監視ジョブの監視結果が全て「異常」であるならば、障害判別部２１１ｂは当該ハブＸに障害があると判定する。即ち障害判別部２１１ｂは、ハブＸに障害が発生したことを検出する（ステップＳ１９）。この場合、障害判別部２１１ｂは上記ハブ−監視ジョブ関係情報を再び参照し、ハブＸの次にルートに近い未処理のハブがあるならば、そのハブを新たなハブＸとして選択する（ステップＳ１６，Ｓ１７）。そして障害判別部２１１ｂは、新たなハブＸについて上記ステップＳ１３から始まる処理を実行する。
【００４６】
一方、ハブＸを監視する監視ジョブの監視結果の中に「正常」を表す監視結果が１つでもあるならば（ステップＳ１８）、障害判別部２１１ｂは、「異常」を検出した監視ジョブの監視対象に含まれているネットワークインタフェースカードＮＩＣまたはパス（通信ケーブル）またはハブポートＰ（ＮＩＣ／パス／Ｐ）の障害の可能性があると判断する。障害判別部２１１ｂは、この障害の可能性のあるＮＩＣ／パス／Ｐを、記憶装置２１２の所定領域に履歴として格納する（ステップＳ２０）。障害判別部２１１ｂは、その後のステップＳ１４で新たなハブＸを「正常」と判定した場合には、ステップＳ１５ｂにより、上記履歴の中から、当該ハブＸに至る経路上のＮＩＣ／パス／Ｐを削除する。したがって、最後に上記履歴に残ったＮＩＣ／パス／Ｐが、ハブ以外の検出された障害を示す。
【００４７】
障害判別部２１１ｂはステップＳ２０を実行すると、ハブＸの次にルートに近い未処理のハブがあるならば、そのハブを新たなハブＸとして選択して（ステップＳ１６，Ｓ１７）。上記ステップＳ１３から始まる処理を実行する。
【００４８】
以上に述べたように、監視サーバ２１１内の障害判別部２１１ｂは、監視結果集合中の監視結果が更新される毎に、ハブ−監視ジョブ関係情報に従って、未処理のハブが存在しなくなるまで上述の処理を繰り返す。
【００４９】
このように本実施形態においては、監視サーバ２１１と監視エージェント２２０−１乃至２２０−６のプロセスを分離することにより、トポロジー的に分けてネットワーク監視を行うことができ、監視サーバ２１１の負荷を軽減することができる。
【００５０】
また、本実施形態においては、ネットワークインタフェイスカードＮＩＣ・パス（通信ケーブル）・ハブポートＰ（ＮＩＣ／パス／Ｐ）の障害とハブ自体の障害とを区別して検出することができる。これにより、障害復旧時の調査範囲を絞ることができる。また本実施形態においては、監視サーバ２１１内の障害判別部２１１ｂにより検出されて、統合システム管理サーバ装置２１内の障害通知部２１５から通知される障害情報（ハブまたはＮＩＣ／パス／Ｐの障害を表す情報）に従って、他のコンピュータの経路情報を操作することで、ネットワークのパケット到着性を向上させることができる。
【００５１】
［第３の実施形態］
次に、本発明の共有リソース障害検出システムをクラスタシステムに適用した第３の実施形態について図面を参照して説明する。図１０は本発明の第３の実施形態に係るクラスタシステムの構成を示すブロック図である。図１０のシステムは、クラスタシステムの主要素である、複数台、例えば２台のコンピュータ３１−１（＃１）及び３１−２（＃２）と、クラスタ管理用の端末（クラスタ端末）３２とを備えている。コンピュータ３１−１及び３１−２上では、クラスタデーモン３１１−１（＃１）及び３１１−２（＃２）が動作している。このクラスタデーモン３１１−０及び３１１−１により、クラスタ制御を司る論理的な機構であるクラスタマネージャ３１２が実現される。つまり、クラスタマネージャ３１２の物理上のプロセスは、各コンピュータ３１−１及び３１−２上でそれぞれ動作するクラスタデーモン３１１−１及び３１１−２であり、当該デーモン３１１−１及び３１１−２が分散的に連携することで、クラスタマネージャ３１２が実現される。図１０では、クラスタマネージャ３１２の制御により、コンピュータ３１−１上でサービス３１３が実行されていることが示されている。このサービス３１３は、クラスタマネージャ３１２によって制御されているアプリケーションプロセスである。サービス３１３の実行は、クラスタマネージャ３１２により開始または停止される。またクラスタマネージャ３１２はクラスタ制御の際の意志決定機能を有しており、例えばコンピュータ３１−１でのサービス３１３の続行に問題がある障害を検出した際に、当該サービス３１３の実行を他のコンピュータ３１−２に切り替える制御、或いは当該サービス３１３の提供を取り止める制御を行う。
【００５２】
コンピュータ３１−１及び３１−２上では、図５中の監視エージェント２２０−１及び２２０−２に相当する監視エージェント３１４−１及び３１４−２が動作する。監視エージェント３１４−１及び３１４−２は、少なくとも１台の共有リソースを監視する。ここでは、監視エージェント３１４−１は監視ジョブ３１５−１（＃１）乃至３１５−４（＃４）を有し、監視エージェント３１４−２は監視ジョブ３１５−５（＃５）乃至３１５−８（＃８）を有している。監視ジョブ３１５−１（＃１）は、パス３３−１（＃１）−コントローラ３４−１（＃１）−共有ディスク装置３５を監視対象として監視し、監視ジョブ３１５−２（＃２）は、パス３３−２（＃１）−コントローラ３４−２（＃１）−共有ディスク装置３５を監視対象として監視する。コントローラ３４−１及び３４−２は、共有ディスク装置３５へのアクセスを制御する２重化コントローラである。監視ジョブ３１５−３（＃３）は、パス３３−３（＃３）−ハブ３６−１（＃１）−ルータ３７を監視対象として監視し、監視ジョブ３１５−４（＃４）は、パス３３−４（＃４）−ハブ３６−２（＃２）−ルータ３７を監視対象として監視する。同様に、監視ジョブ３１５−５（＃５）は、パス３３−５（＃５）−コントローラ３４−１（＃１）−共有ディスク装置３５を監視対象として監視し、監視ジョブ３１５−６（＃６）は、パス３３−６（＃６）−コントローラ３４−２（＃１）−共有ディスク装置３５を監視対象として監視する。監視ジョブ３１５−７（＃７）は、パス３３−７（＃７）−ハブ３６−１（＃１）−ルータ３７を監視対象として監視し、監視ジョブ３１５−８（＃８）は、パス３３−８（＃８）−ハブ３６−２（＃２）−ルータ３７を監視対象として監視する。
【００５３】
第３の実施形態の特徴は、クラスタマネージャ３１２が、例えば図６に示した構成を有する監視サーバ２１１に相当する監視サーバとしての機能も有している点にある。この監視サーバとしての機能の構成については、図１０では省略されている。必要があれば、図６を参照されたい。但し、本実施形態において、図６中のハブ−監視ジョブ関係情報領域２１２ａに相当する領域（共有リソース−監視ジョブ関係情報領域）に格納される情報は、上記第２の実施形態と異なる。本実施形態で適用される共有リソース−監視ジョブ関係情報のデータ構造例を図１１に示す。同図に示すように、本実施形態で適用される共有リソース−監視ジョブ関係情報は、監視対象に含まれている共有リソース（物理的な共有リソース）と当該監視対象を監視する監視ジョブとの対応関係をトポロジーを含めてツリー構造で表す物理共有リソース−監視ジョブ関係情報４１に加えて、サービスの実行に必要な「データ」及び「ネットワーク」と監視ジョブとの対応関係をツリー構造で表す論理共有リソース−監視ジョブ関係情報情報４２も含む。「データ」は、コンピュータ３１−１及び３１−２上のサービスが使用している共有ディスク装置３５内のデータであり、「ネットワーク」は、コンピュータ３１−１及び３１−２上のサービスが使用しているルータ３７並びにハブ３６−１及び３６−２により実現されるネットワークである。「データ」及び「ネットワーク」は、コントローラ３４−１及び３４−２、共有ディスク装置３５、ハブ３６−１及び３６−２並びにルータ３７で代表される物理的な共有リソースに対して、論理的な共有リソースであるといえる。
【００５４】
次に、図１０のシステムにおける動作を、コンピュータ３１−１上でサービス３１３が実行されている状態で、当該システム内のいずれかの箇所で障害が発生した場合に、この障害が影響しないコンピュータに当該サービス３１３を移すための状態決定処理を例に、図１２のフローチャートを参照して説明する。
【００５５】
コンピュータ３１−１上の監視エージェント３１４−１は、監視ジョブ３１５−１（＃１）乃至３１５−４（＃４）を定期的に監視して、当該監視ジョブにより得られた監視結果をクラスタマネージャ３１２に送信する。同様に、コンピュータ３１−２上の監視エージェント３１４−２は、監視ジョブ３１５−５（＃５）乃至３１５−８（＃８）を定期的に監視して、当該監視ジョブにより得られた監視結果をクラスタマネージャ３１２に送信する。クラスタマネージャ３１２（内の監視結果収集部）は、監視ジョブ＃ｉで得られた監視結果を受け取ると、監視結果集合記憶領域に格納されている監視結果集合に含まれている、監視ジョブ＃ｉに対応する監視結果を、今回受け取った最新の監視結果に更新する。
【００５６】
クラスタマネージャ３１２（内の障害判別部）は、監視ジョブ＃ｉに対応する監視結果が更新されると（ステップＳ２１）、クラスタシステムを構成するコンピュータを指定する識別番号＃Ｘを初期値１に設定する（ステップＳ２２）。もしコンピュータ＃Ｘ（つまりコンピュータ３１−Ｘ）が存在するならば（ステップＳ２３）、クラスタマネージャ３１２（内の障害判別部）は、コンピュータ＃Ｘ上で動作している全ての監視ジョブの監視結果を参照する（ステップＳ２４）。この例のように、識別番号＃Ｘが初期値１であるならば、クラスタマネージャ３１２は、コンピュータ３１−１（＃１）上で動作している全ての監視ジョブ３１５−１（＃１）乃至３１５−４（＃４）の監視結果を参照する。
【００５７】
次にクラスタマネージャ３１２は、監視ジョブ３１５−１（＃１）乃至３１５−４（＃４）の監視結果と論理共有リソース−監視ジョブ関係情報情報４２とから、コンピュータ３１−１（＃１）をルートとする論理的な共有リソースの中で、対応する全ての監視結果が「異常」を示している共有リソースが存在するか判定する（ステップＳ２５）。図１１の例では、コンピュータ３１−１（＃１）をルートとする論理的な共有リソースの中で、対応する全ての監視結果が「異常」を示している共有リソースは存在しない。この場合、クラスタマネージャ３１２は識別番号＃Ｘを１インクリメントし（ステップＳ２６）、しかる後にステップＳ２３に戻る。ここでは、インクリメント後の識別番号＃Ｘは２であり、コンピュータ３１−２（＃２）を示す。図１０のシステムにはコンピュータ３１−２（＃２）は存在する。そこでクラスタマネージャ３１２は、コンピュータ３１−２（＃２）上で動作している全ての監視ジョブ３１５−５（＃５）乃至３１５−８（＃８）の監視結果を参照する（ステップＳ２４）。
【００５８】
次にクラスタマネージャ３１２は、監視ジョブ３１５−５（＃５）乃至３１５−８（＃８）の監視結果と論理共有リソース−監視ジョブ関係情報情報４２とから、コンピュータ３１−２（＃２）をルートとする論理的な共有リソースの中で、対応する全ての監視結果が「異常」を示している共有リソースが存在するか判定する（ステップＳ２５）。図１１の例では、コンピュータ３１−２（＃２）をルートとする論理的な共有リソースのうちのデータ４３に関し、対応する監視ジョブ３１５−５（＃５）及び３１５−６（＃６）の監視結果が全て「異常」を示している。この場合、クラスタマネージャ３１２は、この論理的共有リソースであるデータ４３に障害が発生しており、したがってデータ４３の最上位層のコンピュータ３１−２（＃２）、つまりデータ４３のルートをなすコンピュータ３１−２（＃２）に障害が発生していると判断する。
【００５９】
次にクラスタマネージャ３１２は、コンピュータ３１−２（＃２）で実行されていたサービスの扱いを決定するために、ステップＳ２５で障害が検出されたデータ４３を司るルートの物理的な共有リソース、即ち共有ディスク装置３５の障害の有無を、前記第２の実施形態と同様の手法で判定する（ステップＳ２７）。図１１の例では、共有ディスク装置３５に障害は発生していない。この場合、クラスタマネージャ３１２は、図１のクラスタシステムが、障害時にサービスの引き継ぎを行うフェイルオーバー（Ｆａｉｌ ｏｖｅｒ）クラスタシステムであれば、コンピュータ３１−２（＃２）で実行されていたサービスの、他のコンピュータ、例えばコンピュータ３１−１（＃１）への引き継ぎを実施する（ステップＳ２８）。また、図１のクラスタシステムが、サービスを複数のコンピュータに振り分ける計算機クラスタシステムであれば、クラスタマネージャ３１２はコンピュータ３１−２（＃２）でのサービス提供を停止する。クラスタマネージャ３１２は、ステップＳ２８を実行すると識別番号＃Ｘを１インクリメントし（ステップＳ２６）、しかる後にステップＳ２３に戻る。
【００６０】
一方、ステップＳ２５で障害が検出された論理的な共有リソースに対応するルートの物理的な共有リソースに障害が発生している場合には（ステップＳ２７）、他のコンピュータ、例えばコンピュータ３１−１（＃１）にサービスを移したとしても、当該コンピュータ３１−１（＃１）の側で再び障害が検出されてしまう。つまり、連続的にサービスが移動する現象（連続フェイルオーバー）が発生してしまう。そこで、このような不具合（連続フェイルオーバーにより状態制御ができなくなる状態）を防ぐため、クラスタマネージャ３１２は、障害が検出された論理的な共有リソースに対応するルートの物理的な共有リソースに障害が発生している場合には、サービスを移動せず、そのままステップＳ２６を実行している。なお、論理的な共有リソースの障害として、ネットワークの障害が検出された場合には、当該ネットワークを司るルートの物理的な共有リソースである、ルータ３７の障害の有無を判定すればよい。また、図１２のフローチャートでは、物理的な共有リソースの障害検出は、物理共有リソース−監視ジョブ関係情報４１のルートをなす共有ディスク装置３５及びルータ３７だけを対象に行っている。しかし、前記第２の実施形態と同様に、パスの障害と共有リソースの障害を判別して障害復旧時の調査範囲を絞ることも可能である。
【００６１】
なお、本発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態に亘る構成要素を適宜組み合せてもよい。
【００６２】
【発明の効果】
以上詳述したように本発明によれば、複数の監視エージェントが共有リソースをそれぞれ固有のパス経由で監視することにより得られる監視結果を収集して監視結果集合保持手段に保持する一方、共有リソースと当該共有リソースとパスを介して接続される複数の監視エージェントとの対応関係を示す関係情報を関係情報手段に予め保持しておき、この関係情報に従って、障害検出の対象となる共有リソースと関係する監視エージェントを全て特定し、この特定した監視エージェントの監視結果に従って、当該共有リソースと当該共有リソースにつながるパスの障害状態を判別する構成としたので、共有リソースの障害とパスの障害とを区別して検出できる。
【図面の簡単な説明】
【図１】本発明の第１の実施形態に係る共有リソース障害検出システムの構成を示すブロック図。
【図２】図１中の共有装置−監視ジョブ関係情報領域１１２ａに格納される共有装置−監視ジョブ関係情報のデータ構造例を示す図。
【図３】図１中の監視結果集合記憶領域１１２ｂに格納される監視結果集合のデータ構造例を示す図。
【図４】上記第１の実施形態の動作を説明するためのフローチャート。
【図５】本発明の第２の実施形態に係る統合管理システムの構成を示すブロック図。
【図６】図５中の統合システム管理サーバ装置２１のブロック構成を示す図。
【図７】図５中のハブ−監視ジョブ関係情報領域２１２ａに格納されるハブ−監視ジョブ関係情報のデータ構造例を示す図。
【図８】コンピュータとハブとがパスにより接続される接続形態の詳細を示す図。
【図９】上記第２の実施形態の動作を説明するためのフローチャート。
【図１０】本発明の第３の実施形態に係るクラスタシステムの構成を示すブロック図。
【図１１】上記第３の実施形態で適用される共有リソース−監視ジョブ関係情報のデータ構造例を示す図。
【図１２】上記第３の実施形態の動作を説明するためのフローチャート。
【符号の説明】
１１…監視サーバ装置、１３−１，１３−２…共有装置（共有リソース）、１４−１〜１４−６，２５−１〜２５−６，２６−１〜２６−６，３３−１〜３３−８…パス、２１…統合システム管理サーバ装置、２４−１〜２４−４…ハブ（共有リソース）、２２−０〜２２−６，３１−１，３１−２…コンピュータ、３５…共有ディスク装置（共有リソース）、３７…ルータ（共有リソース）、１１１，２１１…監視サーバ、１１１ａ，２１１ａ…監視結果収集部、１１１ｂ，２１１ｂ…障害判別部、１１１ｃ，２１１ｃ…設定部、１１２ａ…共有装置−監視ジョブ関係情報領域、１１２ｂ，２１２ｂ…監視結果集合記憶領域、１２０−１〜１２０−５，２２０−１〜２２０−６，３１４−１，３１４−２…監視エージェント、１２１〜１２５，２２１−１〜２２１−６，３１５−１〜３１５−８…監視ジョブ、２１２ａ…ハブ−監視ジョブ関係情報領域、２１５…障害通知部、３１２…クラスタマネージャ。
【発明の属する技術分野】
本発明は、複数の装置から利用可能な共有リソースの障害を検出するための共有リソース障害検出システム及び方法に関する。
【０００２】
【従来の技術】
一般に、複数の装置から利用可能な共有リソース（共有装置）は、当該リソースの障害の検出という観点から２種類に分類される。第１の種類の共有リソースは、当該リソースに障害が発生した場合に、当該リソース自身がその障害を検出して他の装置に通知する機能を有する。これに対し、第２の種類の共有リソースは、当該リソースに障害が発生しても当該リソース自身がその障害を検出する機能を持たず、その障害を他の装置に通知することもできない。
【０００３】
一方、例えば特許文献１には、共有リソースの障害検出について記載されている。しかし、特許文献１には、上記第２の種類の共有リソースの障害を検出する際の問題については記載されていない。
【０００４】
【特許文献１】
特開２００１−３４４８８号公報（段落００２４、段落００２５、図３、図４）
【０００５】
【発明が解決しようとする課題】
上記第２の種類の共有リソースの障害を検出するには、当該共有リソースと当該共有リソースを監視する装置（監視装置）とをパス（例えば通信ケーブル）でつなぎ、このパスを介して監視装置が当該共有装置を監視する構成を適用することが考えられる。ここでは、監視装置は、パスを介して共有リソースに例えば定期的にアクセスし、当該リソースがリソースとしての機能を果たしているかを監視することにより、当該リソースの障害を検出することが可能である。このように、共有リソースの障害を当該共有リソースから教えてもらうことなく監視装置自身が検出することを、“共有リソースの障害を客観的に検出する”と表現する。
【０００６】
しかしながら上記した従来技術においては、監視装置が共有リソースの障害を客観的に検出したとしても、当該共有リソースに実際に障害が発生しているのか、監視装置と共有リソースとを結ぶパス（監視パス）に障害があって当該共有リソースとの間で通信が行えなかったために、結果として共有リソースに障害が発生したと判定されたのか、区別をつけることができない。即ち従来技術においては、共有リソースに障害が発生したのか、監視パスに障害が発生したのかを区別して検出することができなかった。
【０００７】
本発明は上記事情を考慮してなされたものでその目的は、共有リソースの障害とパスの障害とを区別して検出できる共有リソース障害検出システム及び方法を提供することにある。
【０００８】
【課題を解決するための手段】
本発明の１つの観点によれば、複数の装置から共有使用される少なくとも１つの共有リソースの障害を検出するための共有リソース障害検出システムが提供される。この共有リソース障害検出システムは、上記共有リソースをそれぞれ固有のパス経由で監視する複数の監視エージェントと、上記共有リソースと当該共有リソースと少なくとも１つのパスを介して接続される上記複数の監視エージェントとの対応関係を示す関係情報を保持する関係情報保持手段と、上記複数の監視エージェントの監視結果を収集する監視結果収集手段と、この監視結果収集手段により収集された監視結果の集合を保持する監視結果集合保持手段と、上記関係情報保持手段に保持されている関係情報に従って、障害検出の対象となる共有リソースと関係する監視エージェントを全て特定し、上記監視結果集合保持手段に保持されている監視結果集合のうち、特定した全ての監視エージェントの監視結果に従って、当該共有リソースと当該共有リソースにつながるパスの障害状態を判別する障害判別手段とを備えたことを特徴とする。
【０００９】
このような構成において、複数の監視エージェントが共有リソースをそれぞれ固有のパス経由で監視することにより得られる監視結果は、監視結果収集手段により収集されて監視結果集合保持手段に保持される。障害判別手段は、関係情報保持手段に保持されている関係情報に従って、障害検出の対象となる共有リソースと関係する監視エージェントを全て特定し、この特定した監視エージェントの監視結果に従って、当該共有リソースと当該共有リソースにつながるパスの障害状態を判別する。これにより、共有リソースの障害とパスの障害とを区別して検出できる。ここで、障害判別手段による上記処理が、監視結果集合保持手段に保持されている監視結果集合中の監視結果が更新される都度行われる構成とするとよい。また障害判別手段による障害状態の判別には、上記特定された全ての監視エージェントの監視結果がいずれも異常を表しているならば、対応する共有リソースの障害であり、一部の監視結果のみが異常を表しているならば、対応する共有リソースにつながるパスの障害であると判別される論理を適用するとよい。
【００１０】
また、上記少なくとも１つの共有リソースを含む複数の共有リソースがネットワークを構成する要素である場合に、上記複数の監視エージェントが、このネットワークに接続された所定の装置と通信をすることにより当該所定の装置に至る上記ネットワークの経路上の共有リソース及びパスを含む監視対象を監視する構成とすることも可能である。この構成においては、ネットワーク監視システムが構築できる。
【００１１】
また、上記関係情報が、上記ネットワークを構成する各共有リソースと当該共有リソースを監視対象として含む監視エージェントとの対応関係をトポロジーを含めてツリー構造で示すデータ構造を有し、上記障害判別手段が、このデータ構造の関係情報に従って、ルートにより近い共有リソースから順に障害検出の対象として選択し、その都度選択した共有リソースと関係する監視エージェントを全て特定する構成とするならば、共有リソースの障害検出が効率的に行える。特に、上記関係情報保持手段、監視結果収集手段、監視結果集合保持手段及び障害判別手段が、上記ネットワークを利用する複数のコンピュータを管理する統合システム管理サーバ装置に設けられる構成とすると共に、当該統合システム管理サーバ装置に、上記障害判別手段の障害判別結果を表す障害情報の通知を出力する障害通知手段を備えるとよい。ここで、障害情報通知は、上記統合システム管理サーバ装置の管理下にあるコンピュータは勿論、当該サーバ装置の管理下にないコンピュータにも出力可能である。また、上記障害情報通知を、上記サーバ装置のユーザインタフェースを介してユーザ（管理者）に出力することも可能である。この障害情報通知を用いて障害検出箇所を通知することにより、例えば上記サーバ装置により管理されているコンピュータの経路情報を操作できる。また、統合システム管理サーバ装置における処理と監視エージェントのプロセスを分離することにより、トポロジー的に分けてネットワーク監視が行え、サーバ装置側での負荷を軽減できる。なお、上記共有リソース障害検出システムに係る本発明は、上述の障害通知手段を備え、障害検出箇所の通知を出力する統合システム管理サーバに係る発明としても成立する。
【００１２】
次に上記関係情報保持手段、監視結果収集手段、監視結果集合保持手段及び障害判別手段が、クラスタシステムを構成する複数のコンピュータにまたがって構築されるクラスタマネージャに設けられると共に、上記複数の監視エージェントが、それぞれ同一の共有リソースを監視するように上記複数のコンピュータに分散して設けられる構成とし、更に上記クラスタマネージャが、コンピュータ毎に、上記障害判別手段を利用して、上記関係情報の示す最上位の階層の共有リソースの障害の有無の判別結果を取得し、当該判別結果をもとに当該コンピュータから他のコンピュータへのサービスの引き継ぎまたは当該コンピュータでのサービス提供の停止を実施するか否かを決定する状態決定手段を備えている構成とすることも可能である。
【００１３】
このような構成においては、障害が発生したコンピュータから他のコンピュータへのサービスの引き継ぎまたは当該コンピュータでのサービス提供の停止を実施するか否かを決定する状態決定処理が障害判別手段を利用してクラスタマネージャにより行われる。これにより、クラスタシステムの特徴である、当該システム内に或るコンピュータに障害が発生した場合のサービス引き継ぎまたはサービス提供防止が適切に行われ、連続的にサービスが移動する現象（連続フェイルオーバー）を防止できる。
【００１４】
【発明の実施の形態】
以下、本発明の実施の形態につき図面を参照して説明する。
【００１５】
［第１の実施形態］
図１は本発明の第１の実施形態に係る共有リソース障害検出システムの構成を示すブロック図である。図１のシステムは、監視サーバ装置１１と、複数台の監視エージェント装置、例えば５台の監視エージェント装置１２−１乃至１２−５とを備えている。
【００１６】
監視サーバ装置１１は監視エージェント装置１２−１乃至１２−５を利用して、少なくとも１台の共有装置、例えば２台の共有装置１３−１（＃１）及び１３−２（＃２）の障害を検出する。共有装置１３−１及び１３−２は複数の装置（図示せず）により共用される共有リソースである。共有装置１３−１及び１３−２には、それぞれ識別番号＃１及び＃２が割り当てられているものとする。
【００１７】
監視エージェント装置１２−１乃至１２−５は例えばカード上に構築され、１つの筐体に実装されているものとする。勿論、各監視エージェント装置１２−１乃至１２−５が、それぞれ独立した筐体に実装されるものであっても構わない。監視エージェント装置１２−１乃至１２−５は少なくとも１台の共有装置を監視する。ここでは、監視エージェント装置１２−１及び１２−２は共有装置１２−１を監視し、監視エージェント装置１２−３は共有装置１３−１及び１３−２を監視し、監視エージェント装置１２−４及び１２−５は共有装置１３−２を監視する。そのため、監視エージェント装置１２−１及び１２−２と共有装置１２−１とは、それぞれ監視用のパス（監視パス）１４−１及び１４−２により接続され、監視エージェント装置１２−３と共有装置１３−１及び１３−２とは、それぞれ監視用のパス１４−３及び１４−４により接続され、監視エージェント装置１２−４及び１２−５と共有装置１３−２とは、それぞれ監視用のパス１４−５及び１４−６により接続される。パス１４−１乃至１４−６は、例えば通信ケーブルである。
【００１８】
監視エージェント装置１２−１乃至１２−５上では、それぞれ監視エージェント１２０−１乃至１２０−５が動作する。監視エージェント１２０−１乃至１２０−５は、それぞれ少なくとも１つの監視ジョブを含む。監視ジョブとは、監視エージェントが監視を行う最小単位である。ここでは、各監視ジョブは、パスと当該パスに接続される共有装置を１セットとして監視対象にしている。図１の例では、監視エージェント１２０−１は、共有装置１３−１及びパス１４−１の組を監視対象とする監視ジョブ１２１（＃１）を含み、監視エージェント１２０−２は、共有装置１３−１及びパス１４−２の組を監視対象とする監視ジョブ１２２（＃２）を含む。監視エージェント１２０−３は、共有装置１３−１及びパス１４−３の組を監視対象とする監視ジョブ１２３−１（＃３−１）と、共有装置１３−２及びパス１４−４の組を監視対象とする監視ジョブ１２３−２（＃３−２）とを含む。監視エージェント１２０−４は、共有装置１３−２及びパス１４−５の組を監視対象とする監視ジョブ１２４を含み、監視エージェント１２０−５は、共有装置１３−２及びパス１４−６の組を監視対象とする監視ジョブ１２５を含む。各監視ジョブは、それぞれ対応する監視対象を定期的に監視し、監視結果を得る。このように、監視結果は、監視ジョブ単位に存在する。この監視ジョブ単位の監視結果は２種ある。１つは、監視対象に問題点が発見できなかった「正常」という状態を示す監視結果である。もう１つは、監視対象に問題点が発見された「異常」という状態を示す監視結果である。監視エージェント１２０−１乃至１２０−５は、当該エージェント内の全監視ジョブを定期的に監視して、当該監視ジョブにより得られた監視結果を監視サーバ装置１１に送信する。
【００１９】
監視サーバ装置１１は、監視サーバ１１１と、記憶装置１１２と、通信部１１３と、入力部１１４とを備えている。監視サーバ１１１は、監視サーバ装置１１上で動作して、共有装置１３−１及び１３−２の障害を検出する機能を有する。更に具体的に述べるならば、監視サーバ１１１は、監視エージェント１２０−１乃至１２０−５によって取得された監視結果の集合に基づき、共有装置１３−１もしくは１３−２、またはパス１４−１乃至１４−６のいずれに異常があるかを判別する機能を有する。
【００２０】
監視サーバ１１１は、監視結果収集部１１１ａ、障害判別部１１１ｂ及び設定部１１１ｃを含む。監視結果収集部１１１ａは、監視エージェント１２０−１乃至１２０−５から送信される監視結果を通信部１１３を介して受け取って収集する。障害判別部１１１ｂは、監視結果収集部１１１ａにより収集された監視結果の集合に基づいて、共有装置１３−１もしくは１３−２、またはパス１４−１乃至１４−６のいずれに異常があるかを判別する。設定部１１１ｃは、ユーザ（管理者）の操作による入力部１１４からの入力に従い、監視対象に含まれる共有装置と当該監視対象を監視する監視ジョブとの対応関係を示す情報（共有装置−監視ジョブ関係情報）を次に述べる共有装置−監視ジョブ関係情報領域１１２ａに設定する。
【００２１】
記憶装置１１２の記憶領域の一部は、共有装置−監視ジョブ関係情報領域１１２ａと監視結果集合記憶領域１１２ｂとに用いられる。共有装置−監視ジョブ関係情報領域１１２ａは、監視対象に含まれている共有装置と当該監視対象を監視する監視ジョブとの対応関係を表す共有装置−監視ジョブ関係情報を格納するのに用いられる。図２は共有装置−監視ジョブ関係情報領域１１２ａに格納される共有装置−監視ジョブ関係情報のデータ構造例を示す。ここでは、共有装置１３−１（＃１）は監視ジョブ１２１（＃１），１２２（＃２）及び１２３−１（＃３−１）によって監視され、共有装置１３−２（＃２）は監視ジョブ１２３−２（＃３−２），１２４（＃４）及び１２５（＃５）によって監視されることが示されている。監視結果集合記憶領域１１２ｂは、監視結果収集部１１１ａにより収集された監視結果の集合を格納するのに用いられる。図３は監視結果集合のデータ構造例を示す。
【００２２】
通信部１１３は外部装置との間でデータを送受信する。この通信部１１３で受信されるデータに、各監視エージェント１２０−１乃至１２０−５から送信される監視結果がある。入力部１１４はユーザ（管理者）の操作に応じてデータを入力する。
【００２３】
次に、図１のシステムにおける動作を、監視サーバ装置１１上の監視サーバ１１１の処理を中心に、図４のフローチャートを参照して説明する。まず、監視エージェント装置１２−１乃至１２−５上では、それぞれ監視エージェント１２０−１乃至１２０−５が動作している。また、監視エージェント１２０−１及び１２０−２上では、それぞれ監視ジョブ１２１（＃１）及び１２２（＃２）が動作して、パス１４−１及び１４−２を介して共有装置１３−１（＃１）を定期的に監視している。同様に、監視エージェント１２０−３上では、２つの監視ジョブ１２３−１（＃３−１）及び１２３−２（＃３−２）が並行して動作して、それぞれパス１４−３及び１４−４を介して共有装置１３−１（＃１）及び１３−２（＃２）を定期的に監視している。また、監視エージェント１２０−４及び１２０−５上では、それぞれ監視ジョブ１２４（＃４）及び１２５（＃５）が動作して、パス１４−５及び１４−６を介して共有装置１３−２（＃２）を定期的に監視している。但し、各監視ジョブは共有装置自体の障害は検出できず、当該共有装置を接続するパスと当該共有装置との組（監視対象）全体の障害として検出する。つまり各監視ジョブは、自身に固有の監視対象を定期的に監視し、その監視結果（監視対象の正常または異常）を取得する。
【００２４】
監視エージェント１２０−１乃至１２０−５は、当該エージェント上で動作する監視ジョブ＃ｉ（ここでは１つまたは２つの監視ジョブ）を定期的に監視して、当該監視ジョブ＃ｉで得られた監視結果を監視サーバ装置１１に送信する。この監視結果は監視サーバ装置１１内の通信部１１３で受信されて監視サーバ１１１内の監視結果収集部１１１ａに渡される。
【００２５】
監視結果収集部１１１ａは、監視ジョブ＃ｉで得られた監視結果を通信部１１３から受け取ると、記憶装置１１２の監視結果集合記憶領域１１２ｂにアクセスする。次に監視結果収集部１１１ａは、監視結果集合記憶領域１１２ｂに格納されている監視結果集合に含まれている、監視ジョブ＃ｉに対応する監視結果を、今回受け取った最新の監視結果に更新する。そして監視結果収集部１１１ａは、監視結果集合記憶領域１１２ｂの内容が更新されたことを監視サーバ１１１内の障害判別部１１１ｂに通知する。
【００２６】
障害判別部１１１ｂは監視結果収集部１１１ａからの更新通知に応じて起動され、まず共有装置を示す識別番号＃Ｎを初期値１に設定する（ステップＳ１，Ｓ２）。そして障害判別部１１１ｂは記憶装置１１２内の共有装置−監視ジョブ関係情報領域１１２ａを参照し、識別番号＃Ｎで指定される共有装置＃Ｎが存在するならば（ステップＳ３）、当該共有装置＃Ｎを監視している（つまり共有装置＃Ｎを監視対象として含む）全ての監視ジョブ＃ｊを特定する（ステップＳ４）。Ｎ＝１の場合、共有装置＃１（つまり共有装置１３−１）を監視している監視ジョブ＃ｊは、監視ジョブ＃１，＃２及び＃３−１（つまり監視ジョブ１２１，１２２及び１２３−１）の３台である。
【００２７】
次に障害判別部１１１ｂは記憶装置１１２内の監視結果集合記憶領域１１２ｂを参照し、特定した全ての監視ジョブ＃ｊの監視結果がいずれも「正常」であるか否かを判定する（ステップＳ５）。もし、１つでも「異常」を表す監視結果が含まれているならば、障害判別部１１１ｂは、特定した全ての監視ジョブ＃ｊの監視結果がいずれも「異常」であるかを判定する（ステップＳ６）。即ち障害判別部１１１ｂは、共有装置＃Ｎを監視している全ての監視ジョブ＃ｊの監視結果がいずれも「異常」であるかを判定する。ここでは、共有装置＃Ｎに対するパスが全て障害となることはないものとしている。
【００２８】
もし、共有装置＃Ｎを監視している全ての監視ジョブ＃ｊの監視結果がいずれも「異常」であるならば、障害判別部１１１ｂは当該共有装置＃Ｎに障害があると判定する。即ち障害判別部１１１ｂは、共有装置＃Ｎに障害が発生したことを検出する（ステップＳ７）。これに対し、共有装置＃Ｎを監視している全ての監視ジョブ＃ｊの監視結果のうちの一部だけが「異常」であるならば、障害判別部１１１ｂは共有装置＃Ｎには障害はなく、「異常」を表す監視結果を取得した監視ジョブの監視対象に含まれるパスに障害があると判定する。即ち障害判別部１１１ｂは、「異常」を表す監視結果を取得した監視ジョブの監視経路をなすパスに障害が発生したことを検出する（ステップＳ８）。このように障害判別部１１１ｂは、監視ジョブ＃ｊでは区別できない、当該監視ジョブ＃ｊの監視対象に含まれている共有装置とパスの障害を区別して検出することができる。
【００２９】
障害判別部１１１ｂは、ステップＳ５で全ての監視ジョブ＃ｊの監視結果がいずれも「正常」であると判定した場合は直ちに、「異常」を表す監視結果が含まれていると判定した場合には、ステップＳ７またはＳ８を実行した後に、識別番号＃Ｎを１インクリメントする（ステップＳ９）。そして、このインクリメント後の識別番号＃Ｎで指定される共有装置＃Ｎが存在するならば（ステップＳ３）、障害判別部１１１ｂは当該共有装置＃Ｎの障害を検出（判定）するために、ステップＳ４以降の処理を再度実行する。これに対し、インクリメント後の識別番号＃Ｎで指定される共有装置＃Ｎが存在しないならば、障害判別部１１１ｂは、監視結果集合の更新に伴う全ての共有装置の障害検出処理を終了したものと判断し、監視結果集合が再び更新されるのを待つ（ステップＳ１）。
【００３０】
［第２の実施形態］
次に、本発明の共有リソース障害検出システムを統合管理システムに適用した第２の実施形態について図面を参照して説明する。図５は本発明の第２の実施形態に係る統合管理システムの構成を示すブロック図である。図５のシステムは、統合システム管理サーバ装置２１と、複数台のコンピュータ、例えば７台のコンピュータ２２−０乃至２２−６と、監視対象となる共有リソースと接続されたコンピュータ（以下、対象コンピュータと称する）２３とを備えている。対象コンピュータ２３は、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）／ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ネットワークにおけるｐｉｎｇ（ｐａｃｋｅｔ ｉｎｔｅｒｎｅｔ ｇｒｏｐｅｒ）コマンドに対する応答を返す機能を有する。ｐｉｎｇは、ＴＣＰ／ＩＰネットワークにおいてネットワークの接続状態を検査するのに用いられるコマンドである。即ちｐｉｎｇは、ＩＰパケットが送信先のノードまで到達しているかを調べるために利用されるコマンドであり、ＩＣＭＰ（Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ）のエコー要求を使って実行される。
【００３１】
統合システム管理サーバ装置２１は、システム全体の管理の効率化、信頼性の向上化をさせるために置かれる中央集中型の管理装置である。統合システム管理サーバ装置２１はコンピュータ２２−０を含む複数のコンピュータを管理する。統合システム管理サーバ装置２１は、コンピュータ２２−１乃至２２−６を利用して、コンピュータ２２−０を含む複数のコンピュータ（端末）によって使用される少なくとも１台の共有リソース、例えば４台のハブ２４−１（＃１）乃至２４−４（＃４）により実現されるネットワークを監視するネットワーク監視システム（共有リソース障害検出システム）を構成する。統合システム管理サーバ装置２１によって検出された障害などの情報（例えば障害検出箇所の情報）は、当該サーバ装置２１のユーザ（例えば管理者）、当該サーバ装置２１によって管理されるコンピュータ、例えばコンピュータ２２−０、更にはそれ以外のコンピュータに提供される。このコンピュータ２２−０上では、通信アプリケーション（通信ＡＰＬ）２２０が、統合システム管理サーバ装置２１上の監視サーバ２１１及びコンピュータ２２−１乃至２２−６上の監視エージェント２２０−１乃至２００−６とは独立して動作し、ネットワーク監視システムにより監視されるネットワークを用いて他の装置と通信を行っている。コンピュータ２２−０は、統合システム管理サーバ装置２１内の障害通知部２１５から通信部２１３（図６参照）を介して通知される障害情報をもとに、可能な限り正常に通信が行えるよう経路情報を絶えず変更する。
【００３２】
ハブ２４−１乃至２４−４は、コンピュータ２２−０を含む複数の端末を相互に接続する集線装置である。ハブ２４−１乃至２４−４は、コンピュータ２２−０を含む複数の端末が接続されるネットワーク（ネットワーク環境）を構成する。ここでは、コンピュータ２２−０は、パス２５−１を介してハブ２４−１と接続され、当該ハブ２４−１からパス２５−２を介してハブ２４−４と接続されている。コンピュータ２２−０はまた、パス２５−３を介してハブ２４−２と接続され、当該ハブ２４−２からパス２５−４を介してハブ２４−３と接続されている。ハブ２４−３はパス２５−５を介してハブ２４−４と接続されている。このハブ２４−４には、パス２５−６を介して対象コンピュータ２３も接続されている。ハブ２４−１乃至２４−４には、それぞれ識別番号＃１乃至＃４が割り当てられているものとする。パス２５−１乃至２５−５は、例えば通信ケーブルである。
【００３３】
コンピュータ２２−１乃至２２−６上では、図１中の監視エージェント（１２０−１乃至１２０−４）に相当する監視エージェント２２０−１乃至２２０−６が動作する。監視エージェント２２０−１乃至２２０−６は、少なくとも１台の、共有リソースとしてのハブを監視する。ここでは、監視エージェント２２０−１及び２２０−２は、それぞれ監視ジョブ２２１−１及び２２１−２を有しており、当該監視ジョブ２２１−１及び２２１−２により、いずれもハブ２４−１（＃１）及びハブ２４−４（＃４）を介して対象コンピュータ２３に至る経路を監視する。監視エージェント２２０−３及び２２０−４は、それぞれ監視ジョブ２２１−３及び２２１−４を有しており、当該監視ジョブ２２１−３及び２２１−４により、いずれも、ハブ２４−２（＃２）、ハブ２４−３（＃３）及びハブ２４−４（＃４）を介して対象コンピュータ２３に至る経路を監視する。監視エージェント２２０−５は監視ジョブ２２１−５を有しており、当該監視ジョブ２２１−５により、ハブ２４−３（＃３）及びハブ２４−４（＃４）を介して対象コンピュータ２３に至る経路を監視する。監視エージェント２２０−６は監視ジョブ２２１−６を有しており、当該監視ジョブ２２１−６により、ハブ２４−４（＃４）を介して対象コンピュータ２３に至る経路を監視する。監視ジョブ２２１−１（＃１）乃至２２１−６（＃６）は、図１中の監視ジョブと同様に、監視エージェントが監視を行う最小単位であり、パスと当該パスに接続される共有リソース（ハブ）を１セットとして監視対象とする。
【００３４】
上記監視のため、監視エージェント２２０−１及び２２０−２が動作するコンピュータ２２−１及び２２−２とハブ２４−１とは、それぞれ監視用のパス（監視パス）２６−１及び２６−２により接続される。また、監視エージェント２２０−３及び２２０−４が動作するコンピュータ２２−３及び２２−４とハブ２４−２とは、それぞれ監視用のパス２６−３及び２６−４により接続される。また、監視エージェント２２０−５が動作するコンピュータ２２−５とハブ２４−３とは監視用のパス２６−５により接続され、監視エージェント２２０−６が動作するコンピュータ２２−６とハブ２４−４とは監視用のパス２６−６により接続される。パス２６−１乃至２６−６は、パス２５−１乃至２５−５と同様に通信ケーブルである。
【００３５】
図６は図５中の統合システム管理サーバ装置２１のブロック構成を示す。統合システム管理サーバ装置２１は、監視サーバ２１１と、記憶装置２１２と、通信部２１３と、入力部２１４と、障害通知部２１５とを備えている。監視サーバ２１１、記憶装置２１２、通信部２１３及び入力部２１４は、図１中の監視サーバ装置１１が有する監視サーバ１１１、記憶装置１１２、通信部１１３及び入力部１１４に相当する。障害通知部２１５は、次に述べる監視サーバ２１１内の障害判別部２１１ｂによる障害判別結果を示す障害情報（例えば障害検出箇所の情報）を、統合システム管理サーバ装置２１により管理されているコンピュータ、例えばコンピュータ２２−０に通信部２１３を介して通知すると共に、統合システム管理サーバ装置２１のユーザ（管理者）に表示画面等のユーザインタフェースを介して通知（提供）する。
【００３６】
監視サーバ２１１は、監視結果収集部２１１ａ、障害判別部２１１ｂ及び設定部２１１ｃを含む。監視結果収集部２１１ａは、監視エージェント２２０−１乃至２２０−６から送信される監視結果を通信部２１３を介して受け取って収集する。障害判別部２１１ｂは、監視結果収集部２１１ａにより収集された監視結果の集合に基づいて、ハブ２４−１，２４−２，２４−３もしくは２４−４、またはハブ以外の経路（ＮＩＣ、パスもしくはハブポート）のいずれに異常があるかを判別する。設定部２１１ｃは、ユーザ（管理者）の操作による入力部２１４からの入力に従い、監視対象に含まれるハブと当該監視対象を監視する監視ジョブとの対応関係を示す情報を、トポロジー（ネットワーク接続形態）を含めてツリー構造で次に述べるハブ−監視ジョブ関係情報領域２１２ａに設定する。
【００３７】
記憶装置２１２の記憶領域の一部は、ハブ−監視ジョブ関係情報領域２１２ａと監視結果集合記憶領域２１２ｂとに用いられる。ハブ−監視ジョブ関係情報領域２１２ａは、監視対象に含まれているハブと当該監視対象を監視する監視ジョブとの対応関係をトポロジーを含めてツリー構造で表すハブ−監視ジョブ関係情報を格納するのに用いられる。監視結果集合記憶領域２１２ｂは、監視結果収集部２１１ａにより収集された監視結果の集合を格納するのに用いられる。この監視結果集合のデータ構造は、監視ジョブの数を除き、図３と同様である。
【００３８】
図７はハブ−監視ジョブ関係情報領域２１２ａに格納されるハブ−監視ジョブ関係情報のデータ構造例を示す。図７の例では、ハブ２４−１（＃１）は、監視ジョブ２２１−１（＃１）及び２２１−２（＃２）によって監視され、ハブ２４−２（＃２）は、監視ジョブ２２１−３（＃３）及び２２１−４（＃４）によって監視されることが示されている。また、ハブ２４−３（＃３）はハブ２４−２（＃２）の上位階層に位置し、監視ジョブ２２１−３（＃３）及び２２１−４（＃４）、並びに監視ジョブ２２１−５（＃５）によって監視されることが示されている。また、ハブ２４−４（＃４）はハブ２４−１（＃１）及び２４−３（＃３）の上位階層に位置し、監視ジョブ２２１−１（＃１）及び２２１−２（＃２）、並びに監視ジョブ２２１−３（＃３）及び２２１−４（＃４）、並びに監視ジョブ２２１−５（＃５）、並びに監視ジョブ２２１−６（＃６）によって監視されることが示されている。
【００３９】
図８は、コンピュータとハブとがパス（通信ケーブル）により接続される接続形態の詳細を、コンピュータがコンピュータ２２−６で、ハブがハブ２４−６で、パスがパス２６−１である場合を例に示す。同図に示すように、コンピュータ２２−６はネットワークインタフェースカードＮＩＣ（図１中の監視サーバ装置１１の通信部１１３に相当）を有している。このネットワークインタフェースカードＮＩＣは、ハブ２４−６が有する複数のハブポートＰの１つとパス２６−６により接続されている。この接続形態は、他のコンピュータとハブとの間でも同様である。
【００４０】
次に、図のシステムにおける動作を、統合システム管理サーバ装置２１上の監視サーバ２１１の処理を中心に、図９のフローチャートを参照して説明する。まず、コンピュータ２２−１乃至２２−６上では、それぞれ監視エージェント２２０−１乃至２２０−６が動作している。また、監視エージェント２２０−１乃至２２０−６上では、それぞれ監視ジョブ２２１−１乃至２２１−６が定期的に動作して、それぞれパス２６−１乃至２６−６を介して、対象コンピュータ２３向けのｐｉｎｇコマンドを実行することにより、対応する監視対象を監視している。ここでは、監視ジョブ２２１−１乃至２２１−６の監視結果は２種ある。１つは、監視対象に問題点が発見できなかった「正常」という状態を示す監視結果である。具体的には、ｐｉｎｇコマンドの実行により当該監視ジョブ２２１−１乃至２２１−６から対象コンピュータ２３宛てに送信されたエコー要求のパケットに対する応答が予め定められた制限時間内に返ってきた場合の監視結果である。もう１つは、監視対象に問題点が発見された「異常」という状態を示す監視結果である。具体的には、上記「正常」を示す条件が成立しなかった場合であり、例えば上記エコー要求のパケットに対する応答が上記制限時間内に返ってこなかった場合の監視結果である。
【００４１】
監視エージェント２２０−１乃至２２０−６は、それぞれ監視ジョブ２２１−１乃至２２１−６を定期的に監視して、当該監視ジョブにより得られた監視結果を統合システム管理サーバ装置２１に送信する。この監視結果は統合システム管理サーバ装置２１内の通信部２１３で受信されて、監視サーバ２１１内の監視結果収集部２１１ａに渡される。
【００４２】
監視結果収集部２１１ａは、監視ジョブ＃ｉで得られた監視結果を受け取ると、記憶装置２１２の監視結果集合記憶領域２１２ｂに格納されている監視結果集合に含まれている、監視ジョブ＃ｉに対応する監視結果を、今回受け取った最新の監視結果に更新する。
【００４３】
監視サーバ２１１内の障害判別部２１１ｂは、監視結果収集部２１１ａにより、監視ジョブ＃ｉに対応する監視結果が更新されると（ステップＳ１１）、ハブ−監視ジョブ関係情報領域２１２ａに格納されているハブ−監視ジョブ関係情報を参照し、ルートに最も近いハブをハブＸとして選択する（ステップＳ１２）。ここでは、ハブＸとして、ハブ２４−４（＃４）が選択される。次に障害判別部２１１ｂは、ハブ−監視ジョブ関係情報に従い、当該ハブＸを監視対象として含む監視ジョブを全て特定する（ステップＳ１３）。ハブＸがハブ２４−４（＃４）の場合、当該ハブＸを監視対象として含む監視ジョブは監視ジョブ２２１−１（＃１）乃至２２１−６（＃６）である。
【００４４】
次に障害判別部２１１ｂは、ハブＸを監視対象として含む監視ジョブの監視結果が全て正常かを判定する（ステップＳ１４）。もし、ハブＸを監視する監視ジョブの監視結果が全て「正常」である場合、監視サーバ２１１は、ハブＸより下位に位置するハブが存在するならば、当該ハブＸは勿論、当該ハブＸより下位に位置するハブも全て「正常」であり、処理済みであるとする（ステップＳ１５ａ）。また監視サーバ２１１は、後述するステップＳ１５ｂも実行する。そして監視サーバ２１１は、上記ハブ−監視ジョブ関係情報を再び参照し、ハブＸの次にルートに近い未処理のハブがあるならば、そのハブを新たなハブＸとして選択する（ステップＳ１６，Ｓ１７）。続いて障害判別部２１１ｂは、新たなハブＸについて上記ステップＳ１３から始まる処理を実行する。
【００４５】
一方、ハブＸを監視する監視ジョブの監視結果の中に「異常」を表す監視結果が１つでもあるならば（ステップＳ１４）、障害判別部２１１ｂは、ハブＸを監視する監視ジョブの監視結果が全て「異常」であるかを判定する（ステップＳ１８）。もし、ハブＸを監視する監視ジョブの監視結果が全て「異常」であるならば、障害判別部２１１ｂは当該ハブＸに障害があると判定する。即ち障害判別部２１１ｂは、ハブＸに障害が発生したことを検出する（ステップＳ１９）。この場合、障害判別部２１１ｂは上記ハブ−監視ジョブ関係情報を再び参照し、ハブＸの次にルートに近い未処理のハブがあるならば、そのハブを新たなハブＸとして選択する（ステップＳ１６，Ｓ１７）。そして障害判別部２１１ｂは、新たなハブＸについて上記ステップＳ１３から始まる処理を実行する。
【００４６】
一方、ハブＸを監視する監視ジョブの監視結果の中に「正常」を表す監視結果が１つでもあるならば（ステップＳ１８）、障害判別部２１１ｂは、「異常」を検出した監視ジョブの監視対象に含まれているネットワークインタフェースカードＮＩＣまたはパス（通信ケーブル）またはハブポートＰ（ＮＩＣ／パス／Ｐ）の障害の可能性があると判断する。障害判別部２１１ｂは、この障害の可能性のあるＮＩＣ／パス／Ｐを、記憶装置２１２の所定領域に履歴として格納する（ステップＳ２０）。障害判別部２１１ｂは、その後のステップＳ１４で新たなハブＸを「正常」と判定した場合には、ステップＳ１５ｂにより、上記履歴の中から、当該ハブＸに至る経路上のＮＩＣ／パス／Ｐを削除する。したがって、最後に上記履歴に残ったＮＩＣ／パス／Ｐが、ハブ以外の検出された障害を示す。
【００４７】
障害判別部２１１ｂはステップＳ２０を実行すると、ハブＸの次にルートに近い未処理のハブがあるならば、そのハブを新たなハブＸとして選択して（ステップＳ１６，Ｓ１７）。上記ステップＳ１３から始まる処理を実行する。
【００４８】
以上に述べたように、監視サーバ２１１内の障害判別部２１１ｂは、監視結果集合中の監視結果が更新される毎に、ハブ−監視ジョブ関係情報に従って、未処理のハブが存在しなくなるまで上述の処理を繰り返す。
【００４９】
このように本実施形態においては、監視サーバ２１１と監視エージェント２２０−１乃至２２０−６のプロセスを分離することにより、トポロジー的に分けてネットワーク監視を行うことができ、監視サーバ２１１の負荷を軽減することができる。
【００５０】
また、本実施形態においては、ネットワークインタフェイスカードＮＩＣ・パス（通信ケーブル）・ハブポートＰ（ＮＩＣ／パス／Ｐ）の障害とハブ自体の障害とを区別して検出することができる。これにより、障害復旧時の調査範囲を絞ることができる。また本実施形態においては、監視サーバ２１１内の障害判別部２１１ｂにより検出されて、統合システム管理サーバ装置２１内の障害通知部２１５から通知される障害情報（ハブまたはＮＩＣ／パス／Ｐの障害を表す情報）に従って、他のコンピュータの経路情報を操作することで、ネットワークのパケット到着性を向上させることができる。
【００５１】
［第３の実施形態］
次に、本発明の共有リソース障害検出システムをクラスタシステムに適用した第３の実施形態について図面を参照して説明する。図１０は本発明の第３の実施形態に係るクラスタシステムの構成を示すブロック図である。図１０のシステムは、クラスタシステムの主要素である、複数台、例えば２台のコンピュータ３１−１（＃１）及び３１−２（＃２）と、クラスタ管理用の端末（クラスタ端末）３２とを備えている。コンピュータ３１−１及び３１−２上では、クラスタデーモン３１１−１（＃１）及び３１１−２（＃２）が動作している。このクラスタデーモン３１１−０及び３１１−１により、クラスタ制御を司る論理的な機構であるクラスタマネージャ３１２が実現される。つまり、クラスタマネージャ３１２の物理上のプロセスは、各コンピュータ３１−１及び３１−２上でそれぞれ動作するクラスタデーモン３１１−１及び３１１−２であり、当該デーモン３１１−１及び３１１−２が分散的に連携することで、クラスタマネージャ３１２が実現される。図１０では、クラスタマネージャ３１２の制御により、コンピュータ３１−１上でサービス３１３が実行されていることが示されている。このサービス３１３は、クラスタマネージャ３１２によって制御されているアプリケーションプロセスである。サービス３１３の実行は、クラスタマネージャ３１２により開始または停止される。またクラスタマネージャ３１２はクラスタ制御の際の意志決定機能を有しており、例えばコンピュータ３１−１でのサービス３１３の続行に問題がある障害を検出した際に、当該サービス３１３の実行を他のコンピュータ３１−２に切り替える制御、或いは当該サービス３１３の提供を取り止める制御を行う。
【００５２】
コンピュータ３１−１及び３１−２上では、図５中の監視エージェント２２０−１及び２２０−２に相当する監視エージェント３１４−１及び３１４−２が動作する。監視エージェント３１４−１及び３１４−２は、少なくとも１台の共有リソースを監視する。ここでは、監視エージェント３１４−１は監視ジョブ３１５−１（＃１）乃至３１５−４（＃４）を有し、監視エージェント３１４−２は監視ジョブ３１５−５（＃５）乃至３１５−８（＃８）を有している。監視ジョブ３１５−１（＃１）は、パス３３−１（＃１）−コントローラ３４−１（＃１）−共有ディスク装置３５を監視対象として監視し、監視ジョブ３１５−２（＃２）は、パス３３−２（＃１）−コントローラ３４−２（＃１）−共有ディスク装置３５を監視対象として監視する。コントローラ３４−１及び３４−２は、共有ディスク装置３５へのアクセスを制御する２重化コントローラである。監視ジョブ３１５−３（＃３）は、パス３３−３（＃３）−ハブ３６−１（＃１）−ルータ３７を監視対象として監視し、監視ジョブ３１５−４（＃４）は、パス３３−４（＃４）−ハブ３６−２（＃２）−ルータ３７を監視対象として監視する。同様に、監視ジョブ３１５−５（＃５）は、パス３３−５（＃５）−コントローラ３４−１（＃１）−共有ディスク装置３５を監視対象として監視し、監視ジョブ３１５−６（＃６）は、パス３３−６（＃６）−コントローラ３４−２（＃１）−共有ディスク装置３５を監視対象として監視する。監視ジョブ３１５−７（＃７）は、パス３３−７（＃７）−ハブ３６−１（＃１）−ルータ３７を監視対象として監視し、監視ジョブ３１５−８（＃８）は、パス３３−８（＃８）−ハブ３６−２（＃２）−ルータ３７を監視対象として監視する。
【００５３】
第３の実施形態の特徴は、クラスタマネージャ３１２が、例えば図６に示した構成を有する監視サーバ２１１に相当する監視サーバとしての機能も有している点にある。この監視サーバとしての機能の構成については、図１０では省略されている。必要があれば、図６を参照されたい。但し、本実施形態において、図６中のハブ−監視ジョブ関係情報領域２１２ａに相当する領域（共有リソース−監視ジョブ関係情報領域）に格納される情報は、上記第２の実施形態と異なる。本実施形態で適用される共有リソース−監視ジョブ関係情報のデータ構造例を図１１に示す。同図に示すように、本実施形態で適用される共有リソース−監視ジョブ関係情報は、監視対象に含まれている共有リソース（物理的な共有リソース）と当該監視対象を監視する監視ジョブとの対応関係をトポロジーを含めてツリー構造で表す物理共有リソース−監視ジョブ関係情報４１に加えて、サービスの実行に必要な「データ」及び「ネットワーク」と監視ジョブとの対応関係をツリー構造で表す論理共有リソース−監視ジョブ関係情報情報４２も含む。「データ」は、コンピュータ３１−１及び３１−２上のサービスが使用している共有ディスク装置３５内のデータであり、「ネットワーク」は、コンピュータ３１−１及び３１−２上のサービスが使用しているルータ３７並びにハブ３６−１及び３６−２により実現されるネットワークである。「データ」及び「ネットワーク」は、コントローラ３４−１及び３４−２、共有ディスク装置３５、ハブ３６−１及び３６−２並びにルータ３７で代表される物理的な共有リソースに対して、論理的な共有リソースであるといえる。
【００５４】
次に、図１０のシステムにおける動作を、コンピュータ３１−１上でサービス３１３が実行されている状態で、当該システム内のいずれかの箇所で障害が発生した場合に、この障害が影響しないコンピュータに当該サービス３１３を移すための状態決定処理を例に、図１２のフローチャートを参照して説明する。
【００５５】
コンピュータ３１−１上の監視エージェント３１４−１は、監視ジョブ３１５−１（＃１）乃至３１５−４（＃４）を定期的に監視して、当該監視ジョブにより得られた監視結果をクラスタマネージャ３１２に送信する。同様に、コンピュータ３１−２上の監視エージェント３１４−２は、監視ジョブ３１５−５（＃５）乃至３１５−８（＃８）を定期的に監視して、当該監視ジョブにより得られた監視結果をクラスタマネージャ３１２に送信する。クラスタマネージャ３１２（内の監視結果収集部）は、監視ジョブ＃ｉで得られた監視結果を受け取ると、監視結果集合記憶領域に格納されている監視結果集合に含まれている、監視ジョブ＃ｉに対応する監視結果を、今回受け取った最新の監視結果に更新する。
【００５６】
クラスタマネージャ３１２（内の障害判別部）は、監視ジョブ＃ｉに対応する監視結果が更新されると（ステップＳ２１）、クラスタシステムを構成するコンピュータを指定する識別番号＃Ｘを初期値１に設定する（ステップＳ２２）。もしコンピュータ＃Ｘ（つまりコンピュータ３１−Ｘ）が存在するならば（ステップＳ２３）、クラスタマネージャ３１２（内の障害判別部）は、コンピュータ＃Ｘ上で動作している全ての監視ジョブの監視結果を参照する（ステップＳ２４）。この例のように、識別番号＃Ｘが初期値１であるならば、クラスタマネージャ３１２は、コンピュータ３１−１（＃１）上で動作している全ての監視ジョブ３１５−１（＃１）乃至３１５−４（＃４）の監視結果を参照する。
【００５７】
次にクラスタマネージャ３１２は、監視ジョブ３１５−１（＃１）乃至３１５−４（＃４）の監視結果と論理共有リソース−監視ジョブ関係情報情報４２とから、コンピュータ３１−１（＃１）をルートとする論理的な共有リソースの中で、対応する全ての監視結果が「異常」を示している共有リソースが存在するか判定する（ステップＳ２５）。図１１の例では、コンピュータ３１−１（＃１）をルートとする論理的な共有リソースの中で、対応する全ての監視結果が「異常」を示している共有リソースは存在しない。この場合、クラスタマネージャ３１２は識別番号＃Ｘを１インクリメントし（ステップＳ２６）、しかる後にステップＳ２３に戻る。ここでは、インクリメント後の識別番号＃Ｘは２であり、コンピュータ３１−２（＃２）を示す。図１０のシステムにはコンピュータ３１−２（＃２）は存在する。そこでクラスタマネージャ３１２は、コンピュータ３１−２（＃２）上で動作している全ての監視ジョブ３１５−５（＃５）乃至３１５−８（＃８）の監視結果を参照する（ステップＳ２４）。
【００５８】
次にクラスタマネージャ３１２は、監視ジョブ３１５−５（＃５）乃至３１５−８（＃８）の監視結果と論理共有リソース−監視ジョブ関係情報情報４２とから、コンピュータ３１−２（＃２）をルートとする論理的な共有リソースの中で、対応する全ての監視結果が「異常」を示している共有リソースが存在するか判定する（ステップＳ２５）。図１１の例では、コンピュータ３１−２（＃２）をルートとする論理的な共有リソースのうちのデータ４３に関し、対応する監視ジョブ３１５−５（＃５）及び３１５−６（＃６）の監視結果が全て「異常」を示している。この場合、クラスタマネージャ３１２は、この論理的共有リソースであるデータ４３に障害が発生しており、したがってデータ４３の最上位層のコンピュータ３１−２（＃２）、つまりデータ４３のルートをなすコンピュータ３１−２（＃２）に障害が発生していると判断する。
【００５９】
次にクラスタマネージャ３１２は、コンピュータ３１−２（＃２）で実行されていたサービスの扱いを決定するために、ステップＳ２５で障害が検出されたデータ４３を司るルートの物理的な共有リソース、即ち共有ディスク装置３５の障害の有無を、前記第２の実施形態と同様の手法で判定する（ステップＳ２７）。図１１の例では、共有ディスク装置３５に障害は発生していない。この場合、クラスタマネージャ３１２は、図１のクラスタシステムが、障害時にサービスの引き継ぎを行うフェイルオーバー（Ｆａｉｌ ｏｖｅｒ）クラスタシステムであれば、コンピュータ３１−２（＃２）で実行されていたサービスの、他のコンピュータ、例えばコンピュータ３１−１（＃１）への引き継ぎを実施する（ステップＳ２８）。また、図１のクラスタシステムが、サービスを複数のコンピュータに振り分ける計算機クラスタシステムであれば、クラスタマネージャ３１２はコンピュータ３１−２（＃２）でのサービス提供を停止する。クラスタマネージャ３１２は、ステップＳ２８を実行すると識別番号＃Ｘを１インクリメントし（ステップＳ２６）、しかる後にステップＳ２３に戻る。
【００６０】
一方、ステップＳ２５で障害が検出された論理的な共有リソースに対応するルートの物理的な共有リソースに障害が発生している場合には（ステップＳ２７）、他のコンピュータ、例えばコンピュータ３１−１（＃１）にサービスを移したとしても、当該コンピュータ３１−１（＃１）の側で再び障害が検出されてしまう。つまり、連続的にサービスが移動する現象（連続フェイルオーバー）が発生してしまう。そこで、このような不具合（連続フェイルオーバーにより状態制御ができなくなる状態）を防ぐため、クラスタマネージャ３１２は、障害が検出された論理的な共有リソースに対応するルートの物理的な共有リソースに障害が発生している場合には、サービスを移動せず、そのままステップＳ２６を実行している。なお、論理的な共有リソースの障害として、ネットワークの障害が検出された場合には、当該ネットワークを司るルートの物理的な共有リソースである、ルータ３７の障害の有無を判定すればよい。また、図１２のフローチャートでは、物理的な共有リソースの障害検出は、物理共有リソース−監視ジョブ関係情報４１のルートをなす共有ディスク装置３５及びルータ３７だけを対象に行っている。しかし、前記第２の実施形態と同様に、パスの障害と共有リソースの障害を判別して障害復旧時の調査範囲を絞ることも可能である。
【００６１】
なお、本発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態に亘る構成要素を適宜組み合せてもよい。
【００６２】
【発明の効果】
以上詳述したように本発明によれば、複数の監視エージェントが共有リソースをそれぞれ固有のパス経由で監視することにより得られる監視結果を収集して監視結果集合保持手段に保持する一方、共有リソースと当該共有リソースとパスを介して接続される複数の監視エージェントとの対応関係を示す関係情報を関係情報手段に予め保持しておき、この関係情報に従って、障害検出の対象となる共有リソースと関係する監視エージェントを全て特定し、この特定した監視エージェントの監視結果に従って、当該共有リソースと当該共有リソースにつながるパスの障害状態を判別する構成としたので、共有リソースの障害とパスの障害とを区別して検出できる。
【図面の簡単な説明】
【図１】本発明の第１の実施形態に係る共有リソース障害検出システムの構成を示すブロック図。
【図２】図１中の共有装置−監視ジョブ関係情報領域１１２ａに格納される共有装置−監視ジョブ関係情報のデータ構造例を示す図。
【図３】図１中の監視結果集合記憶領域１１２ｂに格納される監視結果集合のデータ構造例を示す図。
【図４】上記第１の実施形態の動作を説明するためのフローチャート。
【図５】本発明の第２の実施形態に係る統合管理システムの構成を示すブロック図。
【図６】図５中の統合システム管理サーバ装置２１のブロック構成を示す図。
【図７】図５中のハブ−監視ジョブ関係情報領域２１２ａに格納されるハブ−監視ジョブ関係情報のデータ構造例を示す図。
【図８】コンピュータとハブとがパスにより接続される接続形態の詳細を示す図。
【図９】上記第２の実施形態の動作を説明するためのフローチャート。
【図１０】本発明の第３の実施形態に係るクラスタシステムの構成を示すブロック図。
【図１１】上記第３の実施形態で適用される共有リソース−監視ジョブ関係情報のデータ構造例を示す図。
【図１２】上記第３の実施形態の動作を説明するためのフローチャート。
【符号の説明】
１１…監視サーバ装置、１３−１，１３−２…共有装置（共有リソース）、１４−１〜１４−６，２５−１〜２５−６，２６−１〜２６−６，３３−１〜３３−８…パス、２１…統合システム管理サーバ装置、２４−１〜２４−４…ハブ（共有リソース）、２２−０〜２２−６，３１−１，３１−２…コンピュータ、３５…共有ディスク装置（共有リソース）、３７…ルータ（共有リソース）、１１１，２１１…監視サーバ、１１１ａ，２１１ａ…監視結果収集部、１１１ｂ，２１１ｂ…障害判別部、１１１ｃ，２１１ｃ…設定部、１１２ａ…共有装置−監視ジョブ関係情報領域、１１２ｂ，２１２ｂ…監視結果集合記憶領域、１２０−１〜１２０−５，２２０−１〜２２０−６，３１４−１，３１４−２…監視エージェント、１２１〜１２５，２２１−１〜２２１−６，３１５−１〜３１５−８…監視ジョブ、２１２ａ…ハブ−監視ジョブ関係情報領域、２１５…障害通知部、３１２…クラスタマネージャ。
Claims (8)
- 複数の装置から共有使用される少なくとも１つの共有リソースの障害を検出するための共有リソース障害検出システムにおいて、
前記共有リソースをそれぞれ固有のパス経由で監視する複数の監視エージェントと、
前記共有リソースと当該共有リソースと少なくとも１つのパスを介して接続される前記複数の監視エージェントとの対応関係を示す関係情報を保持する関係情報保持手段と、
前記複数の監視エージェントの監視結果を収集する監視結果収集手段と、
前記監視結果収集手段により収集された前記監視結果の集合を保持する監視結果集合保持手段と、
前記関係情報保持手段に保持されている前記関係情報に従って、障害検出の対象となる共有リソースと関係する監視エージェントを全て特定し、前記監視結果集合保持手段に保持されている前記監視結果集合のうち、特定した全ての監視エージェントの監視結果に従って、当該共有リソースと当該共有リソースにつながるパスの障害状態を判別する障害判別手段と
を具備することを特徴とする共有リソース障害検出システム。 - 前記障害判別手段は、前記特定した全ての監視エージェントの監視結果がいずれも異常を表している場合に対応する共有リソースの障害であると判別し、一部の監視結果のみが異常を表している場合に対応する共有リソースにつながるパスの障害であると判別することを特徴とする請求項１記載の共有リソース障害検出システム。
- 前記少なくとも１つの共有リソースを含む複数の共有リソースを用いてネットワークが構成されており、
前記複数の監視エージェントは、前記ネットワークに接続された所定の装置と通信をすることにより当該所定の装置に至る前記ネットワークの経路上の共有リソース及びパスを含む監視対象を監視する
ことを特徴とする請求項１記載の共有リソース障害検出システム。 - 前記関係情報保持手段に保持される前記関係情報は、前記ネットワークを構成する前記各共有リソースと当該共有リソースを監視対象として含む監視エージェントとの対応関係をトポロジーを含めてツリー構造で示すデータ構造を有しており、
前記障害判別手段は、前記関係情報保持手段に保持されている前記関係情報に従って、ルートにより近い共有リソースから順に障害検出の対象として選択し、その都度選択した共有リソースと関係する監視エージェントを全て特定することを特徴とする請求項３記載の共有リソース障害検出システム。 - 前記関係情報保持手段と、前記監視結果収集手段と、前記監視結果集合保持手段と、前記障害判別手段とが、前記ネットワークを利用する複数のコンピュータを管理する統合システム管理サーバ装置に設けられており、
前記統合システム管理サーバ装置は更に、前記障害判別手段の障害判別結果を表す障害情報の通知を出力する障害通知手段を備えていることを特徴とする請求項４記載の共有リソース障害検出システム。 - 前記関係情報保持手段と、前記監視結果収集手段と、前記監視結果集合保持手段と、前記障害判別手段とが、クラスタシステムを構成する複数のコンピュータにまたがって構築されるクラスタマネージャに設けられ、
前記複数の監視エージェントが、それぞれ同一の共有リソースを監視するように前記複数のコンピュータに分散して設けられており、
前記クラスタマネージャは、前記コンピュータ毎に、前記障害判別手段を利用して、前記関係情報保持手段に保持されている前記関係情報の示す最上位の階層の共有リソースの障害の有無の判別結果を取得し、当該判別結果をもとに当該コンピュータから他のコンピュータへのサービスの引き継ぎまたは当該コンピュータでのサービス提供の停止を実施するか否かを決定する状態決定手段を備えていることを特徴とする請求項４記載の共有リソース障害検出システム。 - 前記関係情報保持手段に保持される関係情報は、前記共有リソースを物理的共有リソースとして当該物理的共有リソースを監視対象として含む監視エージェントとの対応関係をツリー構造で示す第１の関係情報と、前記物理的共有リソースの利用を当該リソースの種別に応じてデータの利用とネットワークの利用とに分類し、当該データ及びネットワークを論理的共有リソースとして当該論理的共有リソースを監視対象として含む監視エージェントとの対応関係をツリー構造で示す第２の関係情報とから構成され、
前記障害判別手段は、前記関係情報保持手段に保持されている前記第２の関係情報に従って、前記コンピュータ毎に、対応する全ての前記監視エージェントの監視結果がいずれも異常を表す論理的共有リソースが存在するかを判定し、
前記状態決定手段は、前記監視結果がいずれも異常を表す論理的共有リソースが存在する場合、当該異常を表す論理的共有リソースに対応する、前記関係情報保持手段に保持されている前記第１の関係情報の示す最上位の階層の物理的共有リソースの障害の有無を、前記障害判別手段を利用して判別し、その判別結果に応じてサービスの引き継ぎまたはサービス停止とするか否かを決定することを特徴とする請求項６記載の共有リソース障害検出システム。 - 複数の装置から共有使用される少なくとも１つの共有リソースの障害を検出するための共有リソース障害検出方法において、
前記共有リソースを、独立に動作する複数の監視エージェントにより、それぞれ固有のパス経由で定期的に監視するステップと、
前記監視エージェントから当該監視エージェントの監視結果が送信された場合、当該送信された監視結果により、監視結果集合保持手段に保持されている前記複数の監視エージェントの監視結果の集合のうちの対応する監視結果を更新するステップと、
前記監視結果が更新される都度、関係情報保持手段に保持されている、前記共有リソースと当該共有リソースと少なくとも１つのパスを介して接続される前記複数の監視エージェントとの対応関係を示す関係情報前記関係情報に従って、障害検出の対象となる共有リソースと関係する監視エージェントを全て特定するステップと、
前記監視結果集合保持手段に保持されている前記監視結果集合のうち、前記特定された全ての監視エージェントの監視結果に従って、当該共有リソースと当該共有リソースにつながるパスの障害状態を判別するステップと
を具備することを特徴とする共有リソース障害検出方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003080751A JP2004287980A (ja) | 2003-03-24 | 2003-03-24 | 共有リソース障害検出システム及び方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003080751A JP2004287980A (ja) | 2003-03-24 | 2003-03-24 | 共有リソース障害検出システム及び方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004287980A true JP2004287980A (ja) | 2004-10-14 |
Family
ID=33294522
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003080751A Pending JP2004287980A (ja) | 2003-03-24 | 2003-03-24 | 共有リソース障害検出システム及び方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2004287980A (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007265243A (ja) * | 2006-03-29 | 2007-10-11 | Hitachi Ltd | 計算機システム及び論理パス切替方法 |
| JP2008158666A (ja) * | 2006-12-21 | 2008-07-10 | Nec Corp | ストレージデバイスのマルチパスシステム、その障害箇所特定方法及びプログラム |
-
2003
- 2003-03-24 JP JP2003080751A patent/JP2004287980A/ja active Pending
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007265243A (ja) * | 2006-03-29 | 2007-10-11 | Hitachi Ltd | 計算機システム及び論理パス切替方法 |
| US7992048B2 (en) | 2006-03-29 | 2011-08-02 | Hitachi, Ltd. | Computer system and method for performing failure detecting processing for a logical path |
| JP2008158666A (ja) * | 2006-12-21 | 2008-07-10 | Nec Corp | ストレージデバイスのマルチパスシステム、その障害箇所特定方法及びプログラム |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7225356B2 (en) | System for managing operational failure occurrences in processing devices | |
| US7234073B1 (en) | System and methods for failover management of manageable entity agents | |
| US7370223B2 (en) | System and method for managing clusters containing multiple nodes | |
| RU2375746C2 (ru) | Способ и устройство для обнаружения сетевых устройств | |
| EP1820291B1 (en) | A method, system and computer program product for coordinated monitoring and failure detection | |
| JP5033856B2 (ja) | ネットワーク構成の想定のための装置、システム | |
| JP3813776B2 (ja) | ネットワーク分散管理システム | |
| US10956832B2 (en) | Training a data center hardware instance network | |
| US7774642B1 (en) | Fault zones for interconnect fabrics | |
| JP2005512190A (ja) | ネットワーク化システムにおけるリソースの高可用性をもたらす実複合オブジェクト | |
| JP5577953B2 (ja) | 判定プログラム、検証装置及び検証方法 | |
| US9231779B2 (en) | Redundant automation system | |
| WO2006035040A1 (en) | Method and apparatus for determining impact of faults on network service | |
| JP6549959B2 (ja) | 障害切り分け方法および障害切り分けを行う管理サーバ | |
| JP2012085339A (ja) | 通信システム | |
| US8213439B2 (en) | Method and system for managing a network having an HSRP group | |
| JPH0314161A (ja) | プロセッサ監視処理方式 | |
| WO2019019915A1 (zh) | 一种调度方案配置方法和装置及其计算机可读存储介质和计算机设备 | |
| JP4344333B2 (ja) | パケット転送装置、パケット転送ネットワークシステムおよびパケット転送方法 | |
| JP2004287980A (ja) | 共有リソース障害検出システム及び方法 | |
| CN114124803B (zh) | 设备管理方法、装置、电子设备及存储介质 | |
| JP4238834B2 (ja) | ネットワーク管理システムおよびネットワーク管理プログラム | |
| CN109104333A (zh) | 基于git的分布式集群的同步方法和装置 | |
| US20230224243A1 (en) | Highly-Available Cluster Leader Election in a Distributed Routing System | |
| US11374849B1 (en) | High availability router switchover decision using monitoring and policies |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060214 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060417 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20061107 |