WO2012147176A1

WO2012147176A1 - プログラム、情報処理装置、および監視方法

Info

Publication number: WO2012147176A1
Application number: PCT/JP2011/060253
Authority: WO
Inventors: 浩平木田; 弘和菅沼
Original assignee: 富士通株式会社
Priority date: 2011-04-27
Filing date: 2011-04-27
Publication date: 2012-11-01
Also published as: US20140032173A1; JPWO2012147176A1

Abstract

　動作監視における障害判断の信頼性を向上させる。　計時手段（１ｂ）は、ネットワークを介して接続された被監視装置（２）からの所定の情報の受信待ち時間を計測する。問い合わせ手段（１ｃ）は、受信待ちの制限時間を過ぎても所定の情報を受信できない場合、被監視装置（２）を監視している監視装置（３）に、被監視装置（２）の動作状況を問い合わせる。判断手段（１ｄ）は、監視装置（３）からの応答に示される被監視装置（２）の動作状態に基づいて被監視装置（２）の障害か、被監視装置（２）との間のネットワーク障害かを判断する。

Description

プログラム、情報処理装置、および監視方法

　本発明は、他の装置の動作を監視するプログラム、情報処理装置、および監視方法に関する。

　監視装置から、監視対象となる装置（被監視装置）が正常に動作しているか否かを定期的に監視する場合がある。被監視装置が正常に動作していることの確認手段としてはポーリングによる応答の有無の監視や、定期的に出力されるハートビートの検知による監視などがある。

　一般には、監視装置においてポーリングに対する被監視装置からの応答のタイムアウト、あるいはハードビートの途絶などが発生すると、被監視装置が故障していると判断される。ところが、被監視装置からの応答のタイムアウトやハードビートの途絶は、故障以外の理由でも発生する。例えば、被監視装置の時計をＮＴＰ（Network Time Protocol）サーバに同期させる場合、被監視装置の再起動が行われる。このとき被監視装置の再起動が完了するまで、被監視装置はポーリングへの応答を返すことができない。このような場合にまで、被監視装置を故障と判定してしまうと、動作監視の信頼性が低下してしまう。

　動作監視の信頼性を向上させる技術として、例えば、監視対象の装置の機能が一時的に停止する場合、監視対象の装置から監視装置へ、予め監視を抑止させる情報を通知する技術がある。この場合、監視対象装置は、自らの電源ＯＮ／ＯＦＦの情報を通報センター装置に通知する。通報センター装置は、その通知により監視の開始／解除を行う。これにより監視対象装置の稼働状況をより正確に判断することが可能となる。

特開２００５－３０９６４３号公報

　しかし、従来の技術では、被監視装置との間のネットワークの接続障害が発生している場合においても、監視装置において被監視装置の障害と判断してしまい、動作監視の信頼性が低下していた。

　１つの側面では、本発明は、動作監視における障害判断の信頼性を向上させることができるプログラム、情報処理装置、および監視方法を提供することを目的とする。

　上記課題を解決するために、コンピュータに、以下の処理を実行させるプログラムが提供される。まずコンピュータは、ネットワークを介して接続された被監視装置からの所定の情報の受信待ち時間を計測する。次にコンピュータは、受信待ちの制限時間を過ぎても所定の情報を受信できない場合、被監視装置を監視している監視装置に、被監視装置の動作状況を問い合わせる。そしてコンピュータは、監視装置からの応答に示される被監視装置の動作状態に基づいて被監視装置の障害か、被監視装置との間のネットワーク障害かを判断する。

　また上記プログラムを実行するコンピュータと同様の機能を有する情報処理装置が提供される。さらに上記プログラムに基づいてコンピュータが実行する処理と同様の処理を行う動作監視方法が提供される。

　動作監視における障害判断の信頼性が向上する。
　本発明の上記および他の目的、特徴および利点は本発明の例として好ましい実施の形態を表す添付の図面と関連した以下の説明により明らかになるであろう。

第１の実施の形態に係る装置の機能構成例を示す図である。第１の実施の形態の第１の例の処理手順を示すシーケンス図である。第１の実施の形態の第２の例の処理手順を示すシーケンス図である。第１の実施の形態の第３の例の処理手順を示すシーケンス図である。第２の実施の形態のシステム構成例を示す図である。コンソール部のハードウェアの一構成例を示す図である。監視および制御の装置間の関係を示すブロック図である。各装置の機能の一例を示すブロック図である。監視ステータス記憶部のデータ構造の一例を示す図である。エラーログ記憶部のデータ構造の一例を示す図である。ＨＬＣコマンドフレームの形式を示す図である。ＨＬＣレスポンスフレームの形式を示す図である。動作監視の処理手順の第１の例を示すシーケンス図である。動作監視の処理手順の第２の例を示すシーケンス図である。定期監視におけるタイムアウト発生時のエラーログの一例を示す図である。動作監視の処理手順の第３の例を示すシーケンス図である。ネットワーク再接続失敗時のエラーログの一例を示す図である。動作監視の処理手順の第４の例を示すシーケンス図である。再起動失敗時のエラーログの一例を示す図である。動作監視の処理手順の第５の例を示すシーケンス図である。ＨＬＣ通信エラーのエラーログの一例を示す図である。能動的な定期監視の処理手順を示すフローチャートである。受動的な定期監視の処理手順を示すフローチャートである。定期監視抑止管理処理の手順の一例を示す第１の図である。定期監視抑止管理処理の手順の一例を示す第２の図である。

　以下、本実施の形態について図面を参照して説明する。なお各実施の形態は、矛盾のない範囲で複数の実施の形態を組み合わせて実施することができる。
　〔第１の実施の形態〕
　図１は、第１の実施の形態に係る装置の機能構成例を示す図である。第１の実施の形態では、情報処理装置１は、ネットワークで接続された被監視装置２の動作監視を行う。また監視装置３も、ネットワークを介して被監視装置２の動作監視を行う。

　情報処理装置１は、監視手段１ａ、計時手段１ｂ、問い合わせ手段１ｃ、判断手段１ｄ、接続手段１ｅ、および記憶装置１ｆを有する。
　監視手段１ａは、被監視装置２が正常に動作しているか否かの定期的な監視を行う。例えば監視手段１ａは、被監視装置２に対して動作確認の定期的なポーリングを行い、所定の制限時間以内に応答を受信すれば、被監視装置２が動作していると判断する。また監視手段１ａは、被監視装置２に対するポーリングに対して、所定の制限時間を経過しても応答を受信できなければ、被監視装置２が故障していると判断する。

　なお監視手段１ａは、例えば被監視装置２から定期監視抑止指示を受信した場合、被監視装置２の定期監視を抑止することができる。監視手段１ａは、例えば定期監視を抑止すると、定期監視の抑止解除指示が入力されるまで、被監視装置２の定期監視を行わない。

　計時手段１ｂは、ネットワークを介して接続された被監視装置からの所定の情報の受信待ち時間を計測する。例えば計時手段１ｂは、監視手段１ａが定期監視抑止指示を受信してから、定期監視抑止解除指示の受信待ち時間を計時する。

　問い合わせ手段１ｃは、受信待ちの制限時間を過ぎても所定の情報を受信できない場合、被監視装置２を監視している監視装置３に、被監視装置２の動作状況を問い合わせる。例えば問い合わせ手段１ｃは、定期監視の抑止解除待ちの制限時間を過ぎても定期監視抑止解除指示を受信できない場合、監視装置３に問い合わせを行う。

　判断手段１ｄは、監視装置３からの応答に示される被監視装置２の動作状態に基づいて被監視装置２の障害か、被監視装置２との間のネットワーク障害かを判断する。例えば判断手段１ｄは、監視装置３から、被監視装置２が正常に動作している旨の応答を受け取った場合、被監視装置２との間のネットワーク障害と判断する。また判断手段１ｄは、監視装置３から、被監視装置２に異常がある旨の応答を受け取った場合、被監視装置２の障害と判断する。

　また判断手段１ｄは、ネットワーク障害と判断した場合には、接続手段１ｅに被監視装置２との間のネットワーク接続の試行を依頼することもできる。その場合、判断手段１ｄは、接続手段１ｅが被監視装置２とのネットワーク接続に失敗した場合に、被監視装置２との間のネットワーク障害との判断を確定する。判断手段１ｄは、接続手段１ｅが被監視装置２とのネットワーク接続に成功した場合、被監視装置２との間のネットワーク障害との判断を取り消す。

　判断手段１ｄは、被監視装置２またはネットワークに障害があると判断した場合、例えば、判断結果を記憶装置１ｆに登録する。
　接続手段１ｅは、被監視装置２と通信可能とするためのネットワーク接続を行う。例えば接続手段１ｅは、判断手段１ｄからの要求に応じて、被監視装置２との間のネットワーク接続を試行する。接続手段１ｅは、ネットワーク接続に成功したか否かを、判断手段１ｄに通知する。

　なお、監視手段１ａ、計時手段１ｂ、問い合わせ手段１ｃ、判断手段１ｄ、および接続手段１ｅは、情報処理装置１が有するＣＰＵ（Central Processing Unit）により実現することができる。また、記憶装置１ｆは、情報処理装置１が有するＲＡＭ（Random Access Memory）やハードディスクドライブ（ＨＤＤ:Hard Disk Drive）などにより実現することができる。

　また、図１に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。
　記憶装置１ｆは、判断手段１ｄによる判断結果を記憶する。

　次に、第１の実施の形態のシステムにおいて、情報処理装置１による障害箇所の判断処理例について説明する。以下の例では、情報処理装置１が被監視装置２の定期監視を行っているものとする。また被監視装置２は、再起動する際に、情報処理装置１に定期監視抑止指示を送信することで、再起動を実行している間の情報処理装置１での障害検知を抑止する。ただし、情報処理装置１は、定期監視抑止指示の受信から所定の抑止解除待ち制限時間を経過しても、被監視装置２から定期監視抑止解除指示を受信できない場合、障害を検知する。

　図２は、第１の実施の形態の第１の例の処理手順を示すシーケンス図である。以下、図２に示す処理をステップ番号に沿って説明する。
　［ステップＳ１］被監視装置２は、再起動を行う場合、まず情報処理装置１に定期監視抑止指示を送信する。

　［ステップＳ２］被監視装置２は、再起動を開始する。
　［ステップＳ３］情報処理装置１の監視手段１ａは、定期監視抑止指示に応じて、被監視装置２の定期監視を抑止する。また計時手段１ｂは、定期監視抑止指示を受信してからの時間の計測を開始する。

　［ステップＳ４］被監視装置２は、再起動が完了する。図２の例では、被監視装置２から情報処理装置１への定期監視抑止解除指示が送信できないものとする。
　［ステップＳ５］情報処理装置１の計時手段１ｂは、定期監視抑止解除指示を受信することなく、定期監視抑止指示を受信してから抑止解除待ち制限時間が経過したことを検出する。すると、問い合わせ手段１ｃは、監視装置３に対して、被監視装置２の動作状態の問い合わせを行う。

　このように問い合わせ手段１ｃが、監視装置３に被監視装置２の動作状態を問い合わせることで、被監視装置２が正常に動作しているか否かを、より正確に判断可能となる。すなわち、監視装置３は、情報処理装置１と被監視装置２との間の通信経路とは別の通信経路によって被監視装置２に接続されている。そのため、情報処理装置１と被監視装置２との間で通信が途絶しても、被監視装置２が正常に動作していれば、監視装置３と被監視装置２との間では正常に通信できる可能性がある。

　［ステップＳ６］監視装置３は、情報処理装置１からの問い合わせに応じて、被監視装置２の状態を情報処理装置１に応答する。図２の例では、被監視装置２が正常に動作している旨の応答が情報処理装置１に送信されたものとする。

　［ステップＳ７］情報処理装置１の問い合わせ手段１ｃは、監視装置３からの応答を受信すると、応答の内容を判断手段１ｄに通知する。判断手段１ｄは、被監視装置２が正常に動作していることを認識すると、ネットワーク障害が発生したと判断する。この場合、判断手段１ｄは、接続手段１ｅに被監視装置２とのネットワーク接続を依頼する。すると接続手段１ｅが、被監視装置２との間のネットワーク接続処理を実行する。

　図２の例では、接続手段１ｅによるネットワーク接続に失敗するものとする。
　［ステップＳ８］接続手段１ｅは、ネットワーク接続に失敗したことを、判断手段１ｄに通知する。そして判断手段１ｄは、被監視装置２は正常に動作しているものの、ネットワーク接続ができないことから、被監視装置２との間のネットワーク障害が発生したものと判断する。そこで判断手段１ｄは、ネットワーク障害が発生したことを示す情報を、記憶装置１ｆに格納する。

　次に、情報処理装置１からのネットワーク接続に成功した場合の処理について説明する。
　図３は、第１の実施の形態の第２の例の処理手順を示すシーケンス図である。以下、図３に示す処理をステップ番号に沿って説明する。なお図３において、図２と同様の処理については図２と同じステップ番号を付与し、説明を省略する。

　図３の例では、ステップＳ７で行ったネットワーク接続に成功する。
　［ステップＳ１１］接続手段１ｅは、ネットワーク接続に成功したことを、判断手段１ｄに通知する。判断手段１ｄは、定期監視抑止解除指示は受信できていないものの、ネットワーク接続が成功したことから、被監視装置２が正常に再起動されており、ネットワークを介した通信も可能であると認識する。そこで判断手段１ｄは、被監視装置２が正常に動作しているため、記憶装置１ｆへの障害などの情報の登録は行わない。

　この場合、監視手段１ａは、定期監視の抑止を解除し、被監視装置２の定期監視を再開することができる。
　次に、被監視装置２の再起動が失敗した場合の処理について説明する。

　図４は、第１の実施の形態の第３の例の処理手順を示すシーケンス図である。以下、図４に示す処理をステップ番号に沿って説明する。なお図４において、図２と同様の処理については図２と同じステップ番号を付与し、説明を省略する。

　［ステップＳ２１］監視装置３は、情報処理装置１からの問い合わせに応じて、被監視装置２の状態を情報処理装置１に応答する。図４の例では、被監視装置２に異常がある旨の応答が情報処理装置１に送信される。

　［ステップＳ２２］情報処理装置１の問い合わせ手段１ｃは、監視装置３からの応答を受信すると、応答の内容を判断手段１ｄに通知する。判断手段１ｄは、被監視装置２に異常があることを認識すると、被監視装置２に障害がある旨の情報を記憶装置１ｆに登録する。

　このように、第１の実施の形態では、被監視装置２を、情報処理装置１と監視装置３との二者で監視する。そして、情報処理装置１において被監視装置２との間の通信が途絶えても、監視装置３と被監視装置２との間で正常に通信ができていれば、被監視装置２の動作は正常であると判断する。これにより、被監視装置２との間の通信の途絶が、被監視装置２の障害によるものか、ネットワーク障害によるものかを、正確に判断することができる。

　しかも、第１の実施の形態では、被監視装置２が正常に動作しているにも拘わらず、情報処理装置１が被監視装置２からの所定の情報を受信できない場合、情報処理装置１から被監視装置２へのネットワーク接続を試みる。ネットワークの接続に成功すれば、ネットワークの障害の情報出力を行わない。これにより、過度なエラー検出を抑止することができる。

　被監視装置２が正常に動作しているか否かの判定の正確性が向上することで、保守作業や障害解析作業の工数が削減される。さらに、過度なエラーの検出を抑止できることで、保守の作業者は、多数のエラーの中から対処が必要なエラーを見つけ出す労力を削減することができ、作業効率が向上する。

　〔第２の実施の形態〕
　次に第２の実施の形態について説明する。第２の実施の形態は、マルチクラスタシステムを管理する装置において、内部装置間の動作監視を行うものである。マルチクラスタとは、複数のクラスタを統合して１つのシステムとしたものである。

　図５は、第２の実施の形態のシステム構成例を示す図である。第２の実施の形態では、マルチクラスタ３００を管理するハードウェア制御統合装置Ａが設けられている。マルチクラスタ３００は、大型のサーバ３１０、共有メモリ装置３２０、およびＩ／Ｏ装置３３０を有する。サーバ３１０は、例えば複数のクラスタを含むシステムである。共有メモリ装置３２０は、サーバ３１０を構成する各クラスタで共有可能なメモリである。Ｉ／Ｏ装置３３０は、サーバ３１０に対する情報の入力および出力を行う装置である。

　ハードウェア制御統合装置Ａは、コンソール部１００と管理部２００とを有する。コンソール部１００は、ユーザインターフェースを制御する。管理部２００は、マルチクラスタ３００とコンソール部１００とを管理する。管理部２００は、マルチクラスタ３００のサーバ３１０、共有メモリ装置３２０、およびＩ／Ｏ装置３３０それぞれに、例えば電源制御インタフェース（Ｉ／Ｆ）によって接続されている。管理部２００は、電源制御Ｉ／Ｆを介して、マルチクラスタ３００内の装置の電源を制御することができる。また管理部２００は、コンソール部１００との間で複数のＬＡＮ（Local Area Network）Ｉ／Ｆで接続されている。

　管理部２００は、サーバ２１０、電源制御Ｉ／Ｆ延長装置２２１、接点出力Ｉ／Ｆ変換装置２２２、無停電電源装置（ＵＰＳ：Uninterruptible Power Supply）２２３などを有している。電源制御Ｉ／Ｆ延長装置２２１は、マルチクラスタ３００と接続する電源制御Ｉ／Ｆの延長を可能とする装置である。接点出力Ｉ／Ｆ変換装置２２２は、マルチクラスタ３００の接点出力のＩ／Ｆの変換を行う装置である。ＵＰＳ２２３は、入力電源が遮断されても一定時間、ハードウェア制御統合装置Ａやマルチクラスタ３００に電力を供給する装置である。

　サーバ２１０は、管理部制御部２１１と管理部内サーバ監視部２１２とを有する。なお管理部制御部２１１と管理部内サーバ監視部２１２とは、それぞれが別個のモジュール上に設けられており、例えばＬＡＮで接続されている。

　管理部制御部２１１は、管理部２００全体を制御する。管理部制御部２１１は、例えば、管理部２００のＯＳ（Operating System）上で動作する制御プログラムを、管理部制御部２１１内のＣＰＵが実行することで実現される。管理部内サーバ監視部２１２は、サーバ２１０内のハードウェアなどの動作監視を行う。例えば管理部内サーバ監視部２１２は、サーバ２１０自身のＣＰＵ・メモリ・ハードディスク装置（ＨＤＤ）などの状態、ファンの回転数、および装置内の温度等の監視を行う。

　管理部内サーバ監視部２１２は、例えば、管理部内サーバ監視部２１２内のＣＰＵが制御プログラムを実行することで実現される。管理部内サーバ監視部２１２に対する指示は、例えばコンソール部１００を介したコマンド入力によって行うことができる。また管理部内サーバ監視部２１２へのコマンド入力は、コンソール部１００のコマンドラインからだけでなく、例えばネットワークを介して接続された端末装置のＷｅｂブラウザから行うこともできる。ネットワーク経由で管理部内サーバ監視部２１２にコマンド入力を行う場合、端末装置と管理部内サーバ監視部２１２との間の通信は、ＳＳＨ（Secure SHell）、ＳＳＬ（Secure Socket Layer）などの暗号通信技術で保護され、セキュリティが確保される。

　図６は、コンソール部のハードウェアの一構成例を示す図である。コンソール部１００は、ＣＰＵ１０１によって装置全体が制御されている。ＣＰＵ１０１には、バス１０９を介してＲＡＭ１０２と複数の周辺機器が接続されている。

　ＲＡＭ１０２は、コンソール部１００の主記憶装置として使用される。ＲＡＭ１０２には、ＣＰＵ１０１に実行させるＯＳのプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０２には、ＣＰＵ１０１による処理に必要な各種データが格納される。

　バス１０９に接続されている周辺機器としては、ＨＤＤ１０３、グラフィック処理装置１０４、入力インタフェース１０５、光学ドライブ装置１０６、および通信インタフェース１０７，１０８がある。

　ＨＤＤ１０３は、内蔵したディスクに対して、磁気的にデータの書き込みおよび読み出しを行う。ＨＤＤ１０３は、コンソール部１００の二次記憶装置として使用される。ＨＤＤ１０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。なお、二次記憶装置としては、フラッシュメモリなどの半導体記憶装置を使用することもできる。

　グラフィック処理装置１０４には、モニタ１１が接続されている。グラフィック処理装置１０４は、ＣＰＵ１０１からの命令に従って、画像をモニタ１１の画面に表示させる。モニタ１１としては、ＣＲＴ（Cathode Ray Tube）を用いた表示装置や液晶表示装置などがある。

　入力インタフェース１０５には、キーボード１２とマウス１３とが接続されている。入力インタフェース１０５は、キーボード１２やマウス１３から送られてくる信号をＣＰＵ１０１に送信する。なお、マウス１３は、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、タッチパネル、タブレット、タッチパッド、トラックボールなどがある。

　光学ドライブ装置１０６は、レーザ光などを利用して、光ディスク１４に記録されたデータの読み取りを行う。光ディスク１４は、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスク１４には、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ－ＲＡＭ、ＣＤ－ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ－Ｒ（Recordable）／ＲＷ（ReWritable）などがある。

　通信インタフェース１０７は、ＬＡＮによって管理部制御部２１１に接続されている。通信インタフェース１０７は、管理部制御部２１１との間でデータの送受信を行う。
　通信インタフェース１０８は、ＬＡＮによって管理部内サーバ監視部２１２に接続されている。通信インタフェース１０８は、管理部内サーバ監視部２１２との間でデータの送受信を行う。

　以上のようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。なお、管理部制御部２１１や管理部内サーバ監視部２１２も、それぞれコンソール部１００と同様のハードウェア構成で実現することができる。ただし、管理部制御部２１１や管理部内サーバ監視部２１２には、モニタなどの表示装置や、キーボード、マウスなどの入力装置は、接続されていなくてもよい。

　また第１の実施の形態に示した各情報処理装置１、被監視装置２、および監視装置３も、図６に示したコンピュータと同様のハードウェアにより実現することができる。
　第２の実施の形態では、コンソール部１００、管理部制御部２１１、および管理部内サーバ監視部２１２は、個別のモジュール上に構成されている。またコンソール部１００、管理部制御部２１１、および管理部内サーバ監視部２１２の三者が、それぞれ自己以外の二者に対する定期監視を行う。定期監視では、例えば監視対象の装置（被監視装置）が正常に動作しているか否かの監視が、ＬＡＮ経由で行われる。このようなＬＡＮを介した動作監視は、例えばＬＡＮパス監視と呼ばれる。

　図７は、監視および制御の装置間の関係を示すブロック図である。図７において、装置間の監視関係を実線の矢印で示している。実線の矢印の元が、監視を行う装置であり、実線の矢印の先が被監視装置である。また図７において、装置間の制御関係を点線の矢印で示している。点線の矢印の元が制御を行う装置であり、点線の矢印の先が制御対象の装置である。

　コンソール部１００は、管理部制御部２１１と管理部内サーバ監視部２１２との動作を、ＬＡＮ経由で監視している。またコンソール部１００は、管理部制御部２１１と管理部内サーバ監視部２１２とを、ＬＡＮ経由で制御する。

　管理部制御部２１１は、コンソール部１００と管理部内サーバ監視部２１２との動作を、ＬＡＮ経由で監視している。また管理部制御部２１１は、コンソール部１００と管理部内サーバ監視部２１２とを、ＬＡＮ経由で制御する。

　管理部内サーバ監視部２１２は、コンソール部１００と管理部制御部２１１との動作を、ＬＡＮ経由で監視している。また管理部内サーバ監視部２１２は、コンソール部１００と管理部制御部２１１とを、ＬＡＮ経由で制御する。

　このように、コンソール部１００、管理部制御部２１１、および管理部内サーバ監視部２１２は、互いに定期的な動作監視を行っていると共に、他の装置を制御することができる。第２の実施の形態では、各装置間の制御機能を用いて、動作監視の信頼性を向上させる。

　例えばコンソール部１００、管理部制御部２１１、および管理部内サーバ監視部２１２は、装置間の制御機能を用いて、それぞれ自己以外の二者に対し、再起動指示、および再起動の際の定期監視抑止指示を通知することができる。

　また、コンソール部１００、管理部制御部２１１、および管理部内サーバ監視部２１２は、いずれかの通信経路でネットワークの接続障害を検出すると、ネットワークの再接続処理を試みる。

　第２の実施の形態では、コンソール部１００、管理部制御部２１１、および管理部内サーバ監視部２１２のうちの１つが再起動した場合の、相互監視例を説明する。装置の再起動は、例えばＮＴＰサーバに内部時計を同期させる場合などに行われる。例えば、管理部内サーバ監視部２１２の内部時計をＮＴＰサーバに同期させる際に、管理部内サーバ監視部２１２の再起動が行われる。管理部内サーバ監視部２１２の再起動は、例えば管理部制御部２１１からの指示に基づいて行われる。

　なお管理部制御部２１１は、管理部内サーバ監視部２１２に再起動指示を通知する際に、管理部内サーバ監視部２１２のＬＡＮパス監視エラーを検出しないよう、自身に対してＬＡＮパス監視エラー検出の抑止を行う。ただし、コンソール部１００は管理部内サーバ監視部２１２が再起動することを想定していない。そのためコンソール部１００による管理部内サーバ監視部２１２の監視を、何らかの手段で抑止しないと、管理部内サーバ監視部２１２に再起動指示が行われた際に、コンソール部１００においてＬＡＮパス監視エラーを検出する可能性がある。そこで第２の実施の形態では、管理部内サーバ監視部２１２は、再起動を実行する際に、再起動を指示した装置（管理部制御部２１１）以外の監視装置（コンソール部１００）に対して、定期監視抑止指示を送信する。これにより、管理部内サーバ監視部２１２の再起動時に、コンソール部１００においてエラーが検出されることを抑止できる。

　次に、動作監視に基づく障害箇所判定に用いられる各装置の機能について説明する。
　図８は、各装置の機能の一例を示すブロック図である。コンソール部１００は、定期監視部１１０、監視ステータス記憶部１２０、監視ステータス制御部１３０、ネットワーク接続部１４０、およびエラーログ記憶部１５０を有する。

　定期監視部１１０は、管理部制御部２１１と管理部内サーバ監視部２１２との定期監視を行う。例えば定期監視部１１０は、管理部制御部２１１と管理部内サーバ監視部２１２とのそれぞれに対して、定期的に定期監視メッセージを送信する。定期監視メッセージの送信先の装置（被監視装置）から応答が返された場合、定期監視部１１０は、被監視装置が正常に動作していると判断する。また定期監視部１１０は、被監視装置から所定の定期監視待ち時間を経過しても応答が帰ってこない場合、被監視装置が正常に動作していないと判断する。定期監視によって被監視装置が正常に動作していないと判断した場合、定期監視部１１０は、被監視装置のエラーログを、エラーログ記憶部１５０に格納する。

　なお管理部制御部２１１または管理部内サーバ監視部２１２からコンソール部１００への定期監視メッセージは、定期監視部１１０が受信し、定期監視部１１０がその定期監視メッセージの送信元に対して応答を返す。

　また定期監視部１１０は、管理部制御部２１１または管理部内サーバ監視部２１２から定期監視抑止指示が入力された場合、その定期監視抑止指示の送信元に対する定期監視を一時的に停止する。定期監視部１１０は、定期監視を停止している装置から定期監視解除指示が入力されると、その装置への定期監視を再開する。なお定期監視部１１０は、定期監視を停止した装置から、所定の抑止解除待ち制限時間を経過しても定期監視抑止解除指示が入力されない場合には、その装置を確認対象装置とする。定期監視部１１０は、確認対象装置の情報を監視ステータス制御部１３０に通知する。

　さらに定期監視部１１０は、定期監視によって認識した被監視装置の状態を、監視ステータスとして監視ステータス記憶部１２０に格納する。監視ステータスでは、例えば「監視中」、「監視抑止中」、「応答受信済み」、および「監視タイムアウト」の状態が示される。「監視中」は、定期監視を実行していることを示す状態である。「監視抑止中」は、定期監視の抑止中であることを示す状態である。「応答受信済み」は、定期監視のコマンドに対する正常応答を受信したことを示す状態である。「監視タイムアウト」は、定期監視のコマンドに対する応答が受信できずにタイムアウトしたことを示す状態である。

　また定期監視部１１０は、他の装置の定期監視部２１１ａ，２１２ａと連携し、各装置の監視ステータス記憶部１２０，２１１ｂ，２１２ｂの同期処理を定期的に行う。同期処理は、監視ステータス記憶部１２０，２１１ｂ，２１２ｂの内容を同一にする処理である。

　監視ステータス記憶部１２０は、監視ステータスを記憶する。例えばＲＡＭ１０２またはＨＤＤ１０３の記憶領域の一部が、監視ステータス記憶部１２０として使用される。
　監視ステータス制御部１３０は、管理部制御部２１１または管理部内サーバ監視部２１２との間で、監視ステータス情報の送受信を行う。例えば監視ステータス制御部１３０は、定期監視部１１０から確認対象装置の情報を取得すると、確認対象装置を監視している装置に、確認対象装置に関する監視ステータス要求を送信する。そして監視ステータス制御部１３０は、監視ステータス要求に対して応答で示された監視ステータスに基づいて、確認対象装置の障害の有無を判断する。例えば監視ステータス制御部１３０は、確認対象装置に対する監視においてタイムアウトが発生したことを示す監視ステータスを取得した場合、確認対象装置に障害が発生したものと判断する。確認対象装置に障害が発生したと判断した場合、監視ステータス制御部１３０は、障害に関する情報をエラーログ記憶部１５０に格納する。また監視ステータス制御部１３０は、確認対象装置に対する監視において、正常に動作していることを示す監視ステータスを取得した場合、確認対象装置との間のネットワークに障害が発生したものと判断する。確認対象装置との間のネットワークに障害が発生したと判断した場合、監視ステータス制御部１３０は、ネットワーク接続部１４０に対して、確認対象装置へのネットワーク接続を要求する。

　ネットワーク接続部１４０は、管理部制御部２１１または管理部内サーバ監視部２１２との間のネットワーク接続を行う。ネットワーク接続は、例えば管理部制御部２１１および管理部内サーバ監視部２１２それぞれとの間で、コネクションを確立する処理である。例えば、ネットワーク接続部１４０は、監視ステータス制御部１３０からの要求に応じて、確認対象装置に対するネットワーク接続を行う。またネットワーク接続部１４０は、例えばコンソール部１００が起動された場合、起動後に管理部制御部２１１および管理部内サーバ監視部２１２とネットワーク接続を行う。ネットワーク接続部１４０は、確認対象装置に対するネットワーク接続に失敗した場合、ネットワーク障害のエラーログをエラーログ記憶部１５０に格納する。

　エラーログ記憶部１５０は、エラーログを記憶する。例えばＲＡＭ１０２またはＨＤＤ１０３の記憶領域の一部がエラーログ記憶部１５０として使用される。
　管理部制御部２１１は、定期監視部２１１ａ、監視ステータス記憶部２１１ｂ、監視ステータス制御部２１１ｃ、ネットワーク接続部２１１ｄ、エラーログ記憶部２１１ｅ、および再起動指示部２１１ｆを有する。定期監視部２１１ａ、監視ステータス記憶部２１１ｂ、監視ステータス制御部２１１ｃ、ネットワーク接続部２１１ｄ、およびエラーログ記憶部２１１ｅは、コンソール部１００の同名の要素と同じ機能を有する。再起動指示部２１１ｆは、管理部内サーバ監視部２１２に対して再起動を指示する。

　管理部内サーバ監視部２１２は、定期監視部２１２ａ、監視ステータス記憶部２１２ｂ、監視ステータス制御部２１２ｃ、ネットワーク接続部２１２ｄ、エラーログ記憶部２１２ｅ、および再起動部２１２ｆを有する。定期監視部２１２ａ、監視ステータス記憶部２１２ｂ、監視ステータス制御部２１２ｃ、ネットワーク接続部２１２ｄ、およびエラーログ記憶部２１２ｅは、コンソール部１００の同名の要素と同じ機能を有する。再起動部２１２ｆは、管理部制御部２１１からの再起動指示に応じて、管理部内サーバ監視部２１２の再起動処理を行う。

　なお、図８に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。またコンソール部１００、管理部制御部２１１、および管理部内サーバ監視部２１２は、動作監視に用いられる機能以外にも、図示していない様々な機能を有している。

　また、定期監視部１１０，２１１ａ，２１２ａは、図１に示した第１の実施の形態の監視手段１ａと計時手段１ｂとを包含する機能の一例である。監視ステータス制御部１３０，２１１ｃ，２１２ｃは、図１に示した第１の実施の形態の問い合わせ手段１ｃと判断手段１ｄとを包含する機能の一例である。ネットワーク接続部１４０，２１１ｄ，２１２ｄは、図１に示した第１の実施の形態の接続手段１ｅを包含する機能の一例である。エラーログ記憶部１５０，２１１ｅ，２１２ｅは、図１に示した第１の実施の形態の記憶装置１ｆを包含する機能の一例である。

　次に、監視ステータス記憶部１２０のデータ構造について説明する。
　図９は、監視ステータス記憶部のデータ構造の一例を示す図である。監視ステータス記憶部１２０には、複数の監視ステータス情報１２１，１２２，１２３，・・・，１２ｎがデータチェイン型のデータ構造で格納されている。

　監視ステータス情報１２１，１２２，１２３，・・・，１２ｎは、被監視モジュール情報、被監視モジュールの装置番号、被監視モジュールのステータス、データのロック情報、次のデータベースへのポインタを１セットとした情報である。被監視モジュール情報は、モジュールに実装されている被監視装置の名称などの識別情報である。被監視モジュールの装置番号は、モジュールに実装されている被監視装置の識別番号である。被監視モジュールのステータスは、モジュールに実装されている被監視装置の監視ステータスである。データのロック情報は、データの排他制御に用いる情報であり、データの更新を禁止しているか否かを示す情報である。定期監視部１１０は、データのロック情報を更新することにより、データ更新処理の競合を回避する。

　なお、管理部制御部２１１の監視ステータス記憶部２１１ｂと管理部内サーバ監視部２１２の監視ステータス記憶部２１２ｂとのデータ構造も、図９に示したコンソール部１００の監視ステータス記憶部１２０のデータ構造と同様である。各装置の監視ステータス記憶部１２０，２１１ｂ，２１２ｂは、同期処理によって同じ内容となるように制御される。

　次に、エラーログ記憶部１５０のデータ構造について説明する。
　図１０は、エラーログ記憶部のデータ構造の一例を示す図である。エラーログ記憶部１５０には、複数のエラーログ１５１，１５２，１５３，・・・が格納されている。エラーログ１５１，１５２，１５３，・・・には、日付、ステータス、被疑箇所、メッセージ、および詳細コードが含まれる。日付は、エラーログを取得した日時である。ステータスは、「エラー」、「警告」などの発生したイベントの種別である。被疑箇所は、エラーと判断された装置を示す情報である。メッセージは、エラーの種別を示す文字列である。詳細コード（Detail Code）は、エラーの発生に伴って取得した、エラーの解析に利用可能な情報である。

　なお詳細コードには監視装置と被監視装置それぞれの装置種別および装置番号が含まれている。従って、詳細コードを参照することで、どの装置間での監視においてエラーが発生したのか判別可能である。

　次に、各装置間で送受信される情報について説明する。第２の実施の形態では、例えばＨＬＣ（ハイレベルコマンド）を用いて通信を行うことができる。ＨＬＣは、ＨＬＣコマンドフレームと、ＨＬＣコマンドに対する応答の送信に使用するＨＬＣコマンドレスポンスフレームが一対になった形式である。

　図１１は、ＨＬＣコマンドフレームの形式を示す図である。コマンドフレーム２１は、「フレーム長さ」、「コマンドコード」、「送信元ノードアドレス」、「送信先ノードアドレス」、「ＲＵＮ－ＬＥＶＥＬ」、「コマンドシーケンス番号」、「制御フラグ」、「送信元拡張ノードアドレス」、「送信先拡張ノードアドレス」、「装置種別」、「装置番号」、「リザーブ」、および「パラメータ部」の各フィールド２１－１～２１－１３を有している。

　コマンドフレーム２１のうち、「パラメータ部」のフィールド２１－１３を除いた部分が、ヘッダ部である。またコマンドフレーム２１の全体のサイズは、最大で４０９６バイトである。

　「フレーム長さ」のフィールド２１－１には、コマンドフレーム２１のデータ長が、４バイトデータで設定される。なおコマンドフレーム２１のデータ長は、ヘッダ部も含むデータ長である。

　「コマンドコード」のフィールド２１－２には、ハイレベルコマンドの種別を示す、２バイトのコード（コマンドコード）が設定される。
　コマンドコードの０ビットは、コマンド／レスポンスビットであり、コマンドフレームとレスポンスフレームの区別を示す。例えばコマンドフレームであれば、コマンド／レスポンスビットに「０」が設定される。またレスポンスフレームであれば、コマンド／レスポンスビットに「１」が設定される。

　コマンドコードの１～７ビット（表現できる値の範囲は「0x00～0x7F」）は、分類コードである。分類コードは、ハイレベルコマンドの分類を示す。コマンドコードの８～１５ビット（表現できる値の範囲は「0x00～0xFF」）は、ハイレベルコマンドの機能を示す。分類コードと機能コードとの組み合わせにより、ハイレベルコマンドの内容が表される。例えば、「分類コード＋機能コード」が「0x4002」であれば、ヘルスチェック（定期監視）のコマンドである。「分類コード＋機能コード」が「0x4003」であれば、通信開始のコマンドである。「分類コード＋機能コード」が「0x4004」であれば、通信停止のコマンドである。「分類コード＋機能コード」が「0x4010」であれば、生存確認（監視ステータス要求）のコマンドである。

　「送信元ノードアドレス」のフィールド２１－３には、コマンドフレームを送信する装置（ノード）の２バイトのアドレス（ノードアドレス）が設定される。
　「送信先ノードアドレス」のフィールド２１－４には、コマンドフレームを受信する装置（ノード）の２バイトのアドレス（ノードアドレス）が設定される。

　「ＲＵＮ－ＬＥＶＥＬ」のフィールド２１－５には、複数のハイレベルコマンドがスタックされたときに、スタックから取り出す優先順位を示す、２バイトの値が設定される。
　「コマンドシーケンス番号」のフィールド２１－６には、コマンドフレームのシーケンス番号が、４バイトのデータで設定される。

　「制御フラグ」のフィールド２１－７には、拡張ノードアドレスが有効かどうかを示す、４バイトのフラグが設定される。
　「送信元拡張ノードアドレス」のフィールド２１－８には、コマンドフレームを送信する拡張ノードの４バイトのノードアドレスが設定される。

　「送信先拡張ノードアドレス」のフィールド２１－９には、コマンドフレームを受信する拡張ノードの４バイトのノードアドレスが設定される。
　「装置種別」のフィールド２１－１０には、監視ステータス要求により監視ステータスを確認する対象の装置（確認対象装置）の種別が、１バイトのデータで設定される。例えば、装置種別のフィールドの各ビットに対して、以下の装置が割り当てられる。
１）コンソール部１００（ｂｉｔ「０」）
２）管理部制御部２１１（ｂｉｔ「１」）
３）管理部内サーバ監視部２１２（ｂｉｔ「２」）
４）リザーブ（ｂｉｔ「３～７」）
　例えば値が「１」となったビットに割り当てられた装置が、確認対象装置である。

　「装置番号」のフィールド２１－１１には、「装置種別」のフィールド２１－１０で指定した確認対象装置の装置番号が、１バイトのデータで設定される。
　「リザーブ」のフィールド２１－１２は、予備の２バイトの領域である。

　「パラメータ部」のフィールド２１－１３は、各種パラメータが設定される。
　図１２は、ＨＬＣレスポンスフレームの形式を示す図である。レスポンスフレーム２２は、「フレーム長さ」、「コマンドコード」、「送信元ノードアドレス」、「送信先ノードアドレス」、「ＲＵＮ－ＬＥＶＥＬ」、「コマンドシーケンス番号」、「制御フラグ」、「送信元拡張ノードアドレス」、「送信先拡張ノードアドレス」、「ステータス」、「エラーコード」、および「パラメータ部」の各フィールド２２－１～２２－１２を有している。このうち「フレーム長さ」、「コマンドコード」、「送信元ノードアドレス」、「送信先ノードアドレス」、「ＲＵＮ－ＬＥＶＥＬ」、「コマンドシーケンス番号」、「制御フラグ」、「送信元拡張ノードアドレス」、および「送信先拡張ノードアドレス」のフィールド２２－１～２２－９には、コマンドフレーム２１の同名のフィールドと同種の情報が設定される。

　「ステータス」のフィールド２２－１０には、ハイレベルコマンドの実行終了時の状態を示す、２バイトの情報が設定される。正常時は、「ステータス」のフィールド２２－１０全ビットが「０」となる。そして、エラー内容に応じたビットに「１」が設定される。各ビットに対するエラー内容の割り当ては、以下の通りである。
１）未定義コマンド（ｂｉｔ「０」）
２）パラメータエラー（ｂｉｔ「１」）
３）実行条件エラー（ｂｉｔ「２」）
４）実行時エラー（ｂｉｔ「３」）
５）リザーブ（ｂｉｔ「４～７」）
　「エラーコード」のフィールド２２－１１には、ステータスが実行条件エラー、または実行時エラーのとき、その詳細情報が設定される。

　「パラ－メータ部」のフィールド２２－１２には、パラメータの１つとして、１バイトの監視ステータス２２－１３が設定される。監視ステータス２２－１３は、１バイトのデータのどのビットに「１」が設定されるかで、確認対象装置の状態を示す。監視ステータス２２－１３の各ビットには、以下の状態が割り当てられている。
１）監視中（ｂｉｔ「０」）：監視ステータス要求先の装置が、確認対象装置を監視中であることを示す。
２）監視抑止中（ｂｉｔ「１」）：要求先のモジュールが、確認対象装置の監視を抑止している。
３）（監視）応答受信済み（ｂｉｔ「２」）：要求先のモジュールが、監視対象モジュールから定期監視に対する応答を受けている。
４）監視タイムアウト（ｂｉｔ「３」）：要求先の装置が、確認対象装置の監視タイムアウトを検出している。
５）リザーブ（ｂｉｔ「４～７」）
　このようなＨＬＣを用いて装置間で通信を行い、互いの動作監視が行われる。

　次に、管理部制御部２１１からの指示によって管理部内サーバ監視部２１２の再起動を行う場合のコンソール部１００、管理部制御部２１１、および管理部内サーバ監視部２１２による動作監視処理について説明する。

　図１３は、動作監視の処理手順の第１の例を示すシーケンス図である。図１３に示す処理は、すべての装置および互いの通信が正常に動作している場合の処理手順の一例である。以下、図１３に示す処理をステップ番号に沿って説明する。

　［ステップＳ１０１］コンソール部１００の定期監視部１１０は、管理部内サーバ監視部２１２の定期監視を行う。例えば定期監視部１１０は、管理部内サーバ監視部２１２に対して定期監視のＨＬＣコマンドを送信する。

　このとき管理部内サーバ監視部２１２の定期監視部２１２ａは、コンソール部１００からの定期監視のＨＬＣコマンドを受信したことで、コンソール部１００が正常に動作していることを認識する。そして、定期監視部２１２ａは、コンソール部１００の状態に変更があれば、監視ステータス記憶部２１２ｂ内のコンソール部１００に対応する監視ステータス情報のステータスを更新する。

　［ステップＳ１０２］管理部内サーバ監視部２１２の定期監視部２１２ａは、コンソール部１００から送られた定期監視のＨＬＣコマンドに対して正常応答を返す。正常応答では、レスポンスフレーム２２のステータスのフィールド２２－１０のすべてのビットに０が設定される。

　コンソール部１００の定期監視部１１０は、管理部内サーバ監視部２１２からの正常応答を受信する。このとき、定期監視部１１０は、管理部内サーバ監視部２１２の状態に変更があれば、監視ステータス記憶部１２０内の管理部内サーバ監視部２１２に対応する監視ステータス情報のステータスを更新する。

　［ステップＳ１０３］コンソール部１００の定期監視部１１０は、管理部制御部２１１の定期監視を行う。例えば定期監視部１１０は、管理部制御部２１１に対して定期監視のＨＬＣコマンドを送信する。

　このとき管理部制御部２１１の定期監視部２１１ａは、コンソール部１００からの定期監視のＨＬＣコマンドを受信したことで、コンソール部１００が正常に動作していることを認識する。そして、定期監視部２１１ａは、コンソール部１００の状態に変更があれば、監視ステータス記憶部２１１ｂ内のコンソール部１００に対応する監視ステータス情報のステータスを更新する。

　［ステップＳ１０４］管理部制御部２１１の定期監視部２１１ａは、コンソール部１００から送られた定期監視のＨＬＣコマンドに対して正常応答を返す。このとき、定期監視部１１０は、管理部制御部２１１の状態に変更があれば、監視ステータス記憶部１２０内の管理部制御部２１１に対応する監視ステータス情報のステータスを更新する。

　［ステップＳ１０５］管理部制御部２１１の定期監視部２１１ａは、管理部内サーバ監視部２１２の定期監視を行う。例えば定期監視部２１１ａは、管理部内サーバ監視部２１２に対して定期監視のＨＬＣコマンドを送信する。

　このとき管理部内サーバ監視部２１２の定期監視部２１２ａは、管理部制御部２１１からの定期監視のＨＬＣコマンドを受信したことで、管理部制御部２１１が正常に動作していることを認識する。そして、定期監視部２１２ａは、管理部制御部２１１の状態に変更があれば、監視ステータス記憶部２１２ｂ内の管理部制御部２１１に対応する監視ステータス情報のステータスを更新する。

　［ステップＳ１０６］管理部内サーバ監視部２１２の定期監視部２１２ａは、管理部制御部２１１から送られた定期監視のＨＬＣコマンドに対して正常応答を返す。このとき、定期監視部２１１ａは、管理部内サーバ監視部２１２の状態に変更があれば、監視ステータス記憶部２１１ｂ内の管理部内サーバ監視部２１２に対応する監視ステータス情報のステータスを更新する。

　ステップＳ１０１～Ｓ１０６の処理が定期的に繰り返されることで、コンソール部１００、管理部制御部２１１、および管理部内サーバ監視部２１２が互いに他の装置の動作を監視できる。

　ここで、例えば管理部内サーバ監視部２１２の内部時計をＮＴＰサーバの時計に同期させるなどの理由で、管理部内サーバ監視部２１２の再起動が行われるものとする。例えば管理者がコンソール部１００に対して管理部内サーバ監視部２１２の再起動指示を入力すると、その再起動指示が管理部制御部２１１に渡される。そして管理部制御部２１１の制御により、以下の手順で管理部内サーバ監視部２１２の再起動処理が行われる。

　［ステップＳ１０７］管理部制御部２１１の再起動指示部２１１ｆは、管理部内サーバ監視部２１２に対して再起動指示を送信する。この際、再起動指示部２１１ｆは、定期監視部２１１ａに対して、管理部内サーバ監視部２１２の再起動の実施を通知する。その通知を受けた定期監視部２１１ａは、その後の所定期間の間、管理部内サーバ監視部２１２の定期監視に対して応答が無くてもエラーとは判定しない。

　［ステップＳ１０８］管理部内サーバ監視部２１２の再起動部２１２ｆは、管理部制御部２１１からの再起動指示を受信する。そして再起動部２１２ｆは、定期監視部２１２ａに対して、管理部制御部２１１からの指示に基づく再起動の実施を通知する。すると定期監視部２１２ａは、コンソール部１００に対して、定期監視抑止指示を送信する。

　［ステップＳ１０９］再起動部２１２ｆは、定期監視抑止指示が送信されたことを確認し、管理部内サーバ監視部２１２の再起動を開始する。再起動では、管理部内サーバ監視部２１２のすべての機能が一端停止し、メモリなどのデータを初期化後、各機能が起動される。

　［ステップＳ１１０］コンソール部１００の定期監視部１１０は、管理部内サーバ監視部２１２からの定期監視抑止指示に応じ、管理部内サーバ監視部２１２の定期監視を抑止する。定期監視を抑止した場合、例えば定期監視部１１０は、監視ステータス記憶部１２０内の管理部内サーバ監視部２１２に対応する監視ステータス情報のステータスを、「監視抑止中」に変更する。監視ステータス記憶部１２０に対する変更内容は、各装置の定期監視部１１０，２１１ａ，２１２ａ間の同期処理により、他の監視ステータス記憶部２１１ｂ，２１２ｂにも反映される。

　また定期監視部１１０は、管理部制御部２１１の定期監視は継続し、管理部制御部２１１に対して定期監視のＨＬＣコマンドを送信する。
　［ステップＳ１１１］管理部制御部２１１の定期監視部２１１ａは、コンソール部１００から送られた定期監視のＨＬＣコマンドに対して正常応答を返す。

　［ステップＳ１１２］管理部制御部２１１の定期監視部２１１ａは、管理部内サーバ監視部２１２の定期監視を行う。例えば定期監視部２１１ａは、管理部内サーバ監視部２１２に対して定期監視のＨＬＣコマンドを送信する。管理部内サーバ監視部２１２の再起動中は、管理部内サーバ監視部２１２に対する定期監視のＨＬＣコマンドに対する応答は返されない。

　ステップＳ１１３～ステップＳ１１５の処理は、それぞれステップＳ１１０～ステップＳ１１２の処理と同様である。以後、ステップＳ１１０～ステップＳ１１２と同様の処理が定期的に行われる。

　［ステップＳ１２１］管理部内サーバ監視部２１２の再起動が完了する。このときネットワーク接続部２１２ｄは、コンソール部１００とネットワーク接続を行う。ネットワーク接続は、ネットワークによる通信可能となるように設定を行うことである。またネットワーク接続部２１２ｄは、管理部制御部２１１とネットワーク接続を行う。これにより、管理部内サーバ監視部２１２は、コンソール部１００と管理部制御部２１１とのそれぞれと、ＨＬＣなどの通信を行うことが可能となる。

　［ステップＳ１２２］定期監視部２１２ａは、起動後に定期監視抑止解除指示をコンソール部１００に送信する。コンソール部１００の定期監視部１１０は、定期監視抑止解除指示を受信すると、管理部内サーバ監視部２１２の定期監視を再開する。

　定期監視を再開した場合、例えば定期監視部１１０は、監視ステータス記憶部１２０内の管理部内サーバ監視部２１２に対応する監視ステータス情報のステータスを、「監視中」に変更する。監視ステータス記憶部１２０に対する変更内容は、各装置の定期監視部１１０，２１１ａ，２１２ａ間の同期処理により、他の監視ステータス記憶部２１１ｂ，２１２ｂにも反映される。

　ステップＳ１２３～ステップＳ１２８の処理は、それぞれステップＳ１０１～ステップＳ１０６の処理と同様である。以後、ステップＳ１０１～ステップＳ１０６と同様の処理が定期的に行われる。

　このようにして、各装置が正常に動作している場合、管理部内サーバ監視部２１２の再起動を行っても、定期監視抑止などの処理により、エラーは検出されない。
　次に、管理部内サーバ監視部２１２の再起動が正常に完了したが、管理部内サーバ監視部２１２からのネットワーク接続に失敗した場合の動作監視処理について説明する。

　図１４は、動作監視の処理手順の第２の例を示すシーケンス図である。図１４に示す処理は、再起動後の管理部内サーバ監視部２１２によるコンソール部１００との間のネットワーク接続に失敗した場合の処理手順の一例である。

　この例では、管理部内サーバ監視部２１２は、再起動処理は完了しているものの、コンソール部１００との間のネットワーク接続に失敗している。そのため管理部内サーバ監視部２１２からコンソール部１００に対する定期監視抑止解除指示を、コンソール部１００は受信することができない。

　他方、管理部内サーバ監視部２１２は、再起動後の管理部制御部２１１との間のネットワーク接続には成功したものとする。
　なお図１４において、図１３の処理と同様の処理については図１３と同じステップ番号を付与し、説明を省略する。以下、図１４の処理のうち図１３と異なる処理をステップ番号に沿って説明する。

　［ステップＳ１３１］管理部制御部２１１の定期監視部２１１ａは、管理部内サーバ監視部２１２に定期監視のＨＬＣコマンドを送信することで、定期監視を行う。
　［ステップＳ１３２］管理部内サーバ監視部２１２の定期監視部２１２ａは、管理部制御部２１１から送られた定期監視のＨＬＣコマンドに対して正常応答を返す。

　正常応答を受信した定期監視部２１１ａは、監視ステータス記憶部２１１ｂ内の管理部内サーバ監視部２１２に対応する監視ステータス情報のステータスを、「応答受信済み」に変更する。

　［ステップＳ１３３］コンソール部１００の定期監視部１１０は、定期監視抑止解除指示を受信することなく、定期監視抑止指示の受信から所定の抑止解除待ち制限時間が経過したことを検出する。抑止解除待ち制限時間としては、例えば管理部内サーバ監視部２１２の再起動に要する時間に少しだけ長い時間を設定する。抑止解除待ち制限時間が経過したことを検出すると、定期監視部１１０は、監視ステータス制御部１３０に抑止待ち制限時間のタイムアウトを通知する。通知を受けた監視ステータス制御部１３０は、管理部制御部２１１に対して、管理部内サーバ監視部２１２を確認対象装置に指定した監視ステータス要求を送信する。

　［ステップＳ１３４］管理部制御部２１１の監視ステータス制御部２１１ｃは、監視ステータス要求を受信すると、監視ステータス記憶部２１１ｂ内の管理部内サーバ監視部２１２に対応する監視ステータス情報のステータスを取得する。そして監視ステータス制御部２１１ｃは、取得したステータスを監視ステータスとして含めた正常応答を、コンソール部１００に送信する。

　［ステップＳ１３５］コンソール部１００の監視ステータス制御部１３０は、管理部制御部２１１からの正常応答に含まれる監視ステータスに基づき、管理部内サーバ監視部２１２が正常に動作していることを認識する。このとき監視ステータス制御部１３０は、ネットワーク障害が発生したと仮判断する。そして監視ステータス制御部１３０は、ネットワーク接続部１４０に対して、管理部内サーバ監視部２１２とのネットワーク接続を依頼する。ネットワーク接続部１４０は、監視ステータス制御部１３０からの依頼に応じて、管理部内サーバ監視部２１２に対するネットワーク接続を試みる。この例では、ネットワーク接続が成功したものとする。

　［ステップＳ１３６］管理部内サーバ監視部２１２のネットワーク接続部２１２ｄは、コンソール部１００に対してネットワークが正常に接続されたことを示す正常応答を送信する。コンソール部１００のネットワーク接続部１４０は、ネットワーク接続が成功したことを監視ステータス制御部１３０に通知する。この通知を受けた監視ステータス制御部１３０は、ネットワーク障害が発生したとの仮判断を取り消す。そして監視ステータス制御部１３０は、定期監視部１１０に対して、管理部内サーバ監視部２１２と正常に通信可能であることを通知する。

　以後、定期監視部１１０は、管理部内サーバ監視部２１２の定期監視を再開する。定期監視再開時には、定期監視部１１０は、監視ステータス記憶部１２０内の管理部内サーバ監視部２１２に対応する管理ステータス情報のステータスを、「監視中」に変更する。このステータスは、定期監視に対する応答を受け取ると、さらに「応答受信済み」に変更される。

　このように、管理部内サーバ監視部２１２からのネットワーク接続に失敗しても、コンソール部１００からのネットワーク接続は可能な場合がある。
　例えば多重アクセス等によりネットワークに負荷がかかっているケースを想定する。この場合、ネットワークが一時的に接続できなくなることも想定され、定期監視部１１０で定期監視抑止解除指示のタイムアウトを検知する可能性がある。このとき、ネットワークに根本的な問題があるのか、負荷がかかったことによる一時的な事象なのか切り分けがつかないと、事象調査に作業工数を割くことになる。

　他方、ネットワークの一時的な接続障害の場合、ネットワーク接続の状況を変更するだけで、接続できる可能性がある。そこで第２の実施の形態では、一方の装置からのネットワーク接続が失敗しても、他方の装置からネットワーク接続を再度行う。これにより、ネットワークの負荷がかかった状態におけるネットワーク障害のエラー通知を軽減でき、障害解析を要する作業工数を削減することが可能となる。

　なお、定期監視中に管理部内サーバ監視部２１２からの応答が途絶える場合もある。その場合、以下の処理が行われる。
　［ステップＳ１３７］定期監視部１１０は、管理部内サーバ監視部２１２に定期監視のＨＬＣコマンドを送信することで、定期監視を行う。

　［ステップＳ１３８］定期監視部１１０は、定期監視の応答待ち制限時間がタイムアウトすると、定期監視エラーのエラーログを、エラーログ記憶部１５０に格納する。この際、定期監視部１１０は、例えば監視ステータス記憶部１２０内の管理部内サーバ監視部２１２に対応する監視ステータス情報のステータスを、「監視タイムアウト」に変更する。

　図１５は、定期監視におけるタイムアウト発生時のエラーログの一例を示す図である。定期監視でタイムアウトが発生した場合のエラーログ１５１には、ステータス（Status）として「Error」が設定されている。またメッセージ（Message）として、定期監視に失敗したことを示すメッセージ「Alive check error」が設定されている。

　次に、管理部内サーバ監視部２１２の再起動が正常に完了したが、管理部内サーバ監視部２１２からのネットワーク接続に失敗し、コンソール部１００からのネットワーク接続も失敗した場合の動作監視処理について説明する。

　図１６は、動作監視の処理手順の第３の例を示すシーケンス図である。図１６に示す処理は、再起動後の管理部内サーバ監視部２１２によるコンソール部１００との間のネットワーク接続に失敗し、かつコンソール部１００による管理部内サーバ監視部２１２との間のネットワーク接続にも失敗した場合の処理手順の一例である。

　なお図１６において、図１４の処理と同様の処理については図１４と同じステップ番号を付与し、説明を省略する。図１６の処理のうち図１４と異なる処理は、ステップＳ１３９のみである。

　［ステップＳ１３９］コンソール部１００から管理部内サーバ監視部２１２へのネットワーク接続に対し、管理部内サーバ監視部２１２から応答がない。そのため、ネットワーク接続部１４０は、ネットワーク接続に失敗したことを監視ステータス制御部１３０に通知する。すると監視ステータス制御部１３０は、ネットワーク障害が発生したとの判断を確定し、ネットワーク障害のエラーログをエラーログ記憶部１５０に格納する。すなわち、監視ステータス制御部１３０は、管理部制御部２１１から取得した監視ステータスにより管理部内サーバ監視部２１２が動作していることを確認しているため、ネットワークが接続できないのは、ネットワークの障害が原因であると判断する。そして監視ステータス制御部１３０は、ネットワーク障害のエラーログを格納する。

　図１７は、ネットワーク再接続失敗時のエラーログの一例を示す図である。ネットワーク再接続に失敗した場合のエラーログ１５２には、ステータス（Status）として「Error」が設定されている。またメッセージ（Message）として、ネットワークの接続に失敗したことを示すメッセージ「Network connect error」が設定されている。

　次に、管理部内サーバ監視部２１２が再起動に失敗した場合の動作監視処理について説明する。
　図１８は、動作監視の処理手順の第４の例を示すシーケンス図である。図１８に示す処理は、管理部内サーバ監視部２１２が再起動に失敗した場合の処理手順の一例である。

　なお図１８において、図１４の処理と同様の処理については図１４と同じステップ番号を付与し、説明を省略する。図１８の処理のうち図１４と異なる処理は、ステップＳ１４１以降である。

　［ステップＳ１４１］管理部内サーバ監視部２１２が再起動に失敗している。そのため、管理部内サーバ監視部２１２への再起動指示が出されてから再起動待ち制限時間が経過した後に、管理部制御部２１１の定期監視部２１１ａが定期監視を行っても応答を受信することができない。その結果、定期監視のタイムアウトが発生する。

　［ステップＳ１４２］定期監視部２１１ａは、再起動待ち制限時間の経過後に定期監視のタイムアウトが発生すると、再起動監視タイムアウトのエラーログを、エラーログ記憶部２１１ｅに格納する。また、定期監視部２１１ａは、監視ステータス記憶部２１１ｂ内の管理部内サーバ監視部２１２に対応する監視ステータス情報のステータスを、「監視タイムアウト」に変更する。

　［ステップＳ１４３］コンソール部１００の定期監視部１１０は、定期監視抑止解除指示を受信することなく、定期監視抑止指示の受信から所定の抑止解除待ち制限時間が経過したことを検出する。すると定期監視部１１０は、監視ステータス制御部１３０に抑止待ち制限時間のタイムアウトを通知する。通知を受けた監視ステータス制御部１３０は、管理部制御部２１１に対して、管理部内サーバ監視部２１２を確認対象装置に指定した監視ステータス要求を送信する。

　［ステップＳ１４４］管理部制御部２１１の監視ステータス制御部２１１ｃは、監視ステータス要求を受信すると、監視ステータス記憶部２１１ｂ内の管理部内サーバ監視部２１２に対応する監視ステータス情報のステータスを取得する。そして監視ステータス制御部２１１ｃは、取得したステータスを監視ステータスとして含めた正常応答を、コンソール部１００に送信する。この正常応答に含まれる監視ステータスは「監視タイムアウト」である。

　［ステップＳ１４５］コンソール部１００の監視ステータス制御部１３０は、管理部制御部２１１からの正常応答に含まれる監視ステータスに基づき、管理部内サーバ監視部２１２が正常に動作していないことを認識する。そこで、監視ステータス制御部１３０は、再起動監視タイムアウトのエラーログを、エラーログ記憶部１５０に登録する。

　図１９は、再起動失敗時のエラーログの一例を示す図である。再起動に失敗した場合のエラーログ１５３には、ステータス（Status）として「Error」が設定されている。またメッセージ（Message）として、再起動に失敗したことを示すメッセージ「Reboot Timeout」が設定されている。

　次に、監視ステータスの取得に失敗した場合の動作監視処理について説明する。
　図２０は、動作監視の処理手順の第５の例を示すシーケンス図である。図２０に示す処理は、監視ステータスの取得に失敗した場合の処理手順の一例である。

　なお図２０において、図１４の処理と同様の処理については図１４と同じステップ番号を付与し、説明を省略する。図２０の処理のうち図１４と異なる処理は、ステップＳ１５１以降である。

　［ステップＳ１５１］コンソール部１００の定期監視部１１０は、定期監視抑止解除指示を受信することなく、定期監視抑止指示の受信から所定の抑止解除待ち制限時間が経過したことを検出する。すると定期監視部１１０は、監視ステータス制御部１３０に抑止待ち制限時間のタイムアウトを通知する。通知を受けた監視ステータス制御部１３０は、管理部制御部２１１に対して、管理部内サーバ監視部２１２を確認対象装置に指定した監視ステータス要求を送信する。

　この例では、監視ステータス要求に対する応答が返されないものとする。
　［ステップＳ１５２］定期監視部１１０は、監視ステータス要求に対する応答待ち制限時間がタイムアウトしたことを確認し、ＨＣＬ通信エラーのエラーログをエラーログ記憶部１５０に登録する。

　図２１は、ＨＬＣ通信エラーのエラーログの一例を示す図である。ＨＬＣ通信エラーを検出した場合のエラーログ１５４には、ステータス（Status）として「Error」が設定されている。またメッセージ（Message）として、ＨＬＣの通信に失敗したことを示すメッセージ「HLC communication error」が設定されている。

　以上のように、定期監視の抑止解除待ち制限時間を経過しても定期監視抑止解除指示が入力されない場合でも、監視ステータスの取得状況、および取得した監視ステータスの内容によって、出力するエラーログが異なる。以下、定期監視からエラーログを出力するまでの個々の装置の処理手順について説明する。

　なお、定期監視処理は、ポーリングのような能動的な定期監視と、ハートビートのような受動的な定期監視とがある。能動的な定期監視では、定期監視コマンドを相手に送信し、その応答を受信することで動作していることを確認する。受動的な定期監視では、相手から送信された定期監視コマンドを定期的に受信できている間、相手の装置が動作していると認識する。例えば、図１３に示した例では、コンソール部１００は、管理部制御部２１１と管理部内サーバ監視部２１２を能動的に定期監視している。一方、管理部制御部２１１は、管理部内サーバ監視部２１２を能動的に定期監視し、コンソール部１００を受動的に定期監視している。また管理部内サーバ監視部２１２は、コンソール部１００と管理部制御部２１１とを受動的に定期監視している。

　そこで、能動的な定期監視と受動的な定期監視との処理を個別に説明する。
　図２２は、能動的な定期監視の処理手順を示すフローチャートである。以下、図２２に示す処理をステップ番号に沿って説明する。なお、以下の説明では、コンソール部１００が管理部内サーバ監視部２１２の定期監視を行う場合を想定する。

　［ステップＳ２０１］定期監視部１１０は、管理部内サーバ監視部２１２の定期監視が抑止中か否かを判断する。例えば定期監視部１１０は、監視ステータス記憶部１２０内の管理部内サーバ監視部２１２に対応する監視ステータス情報のステータスが「監視抑止中」であれば、定期監視が抑止中であると判断する。定期監視が抑止中であれば、定期監視部１１０はステップＳ２０１の処理を繰り返す。定期監視が抑止中でなければ、定期監視部１１０は、処理をステップＳ２０２に進める。

　［ステップＳ２０２］定期監視部１１０は、定期監視のＨＬＣコマンドを管理部内サーバ監視部２１２に送信する。
　［ステップＳ２０３］定期監視部１１０は、定期監視用のタイマを起動し、時間の計測を開始する。

　［ステップＳ２０４］定期監視部１１０は、管理部内サーバ監視部２１２から定期監視抑止指示を受信したか否かを判断する。定期監視部１１０は、定期監視抑止指示を受信した場合、処理をステップＳ２０６に進める。また定期監視部１１０は、定期監視抑止指示を受信していなければ、処理をステップＳ２０５に進める。

　［ステップＳ２０５］定期監視部１１０は、定期監視のＨＬＣコマンドに対する応答を受信したか否かを判断する。定期監視部１１０は、応答を受信した場合、処理をステップＳ２０６に進める。また定期監視部１１０は、応答を受信していなければ、処理をステップＳ２０８に進める。

　［ステップＳ２０６］定期監視部１１０は、定期監視用のタイマを停止し、タイマの値を「０」にリセットする。
　［ステップＳ２０７］定期監視部１１０は、一定時間待機する。その後、定期監視部１１０は、処理をステップＳ２０１に進める。

　［ステップＳ２０８］定期監視部１１０は、応答を受信していない場合、定期監視の応答待ち制限時間がタイムアウトしたか否かを判断する。例えば定期監視部１１０は、定期監視用のタイマの時間が、定期監視の応答待ち制限時間以上であれば、タイムアウトしたと判断する。タイムアウトした場合、定期監視部１１０は、処理をステップＳ２０９に進める。タイムアウトしていなければ、定期監視部１１０は、処理をステップＳ２０４に進める。

　［ステップＳ２０９］定期監視部１１０は、定期監視の応答待ち制限時間がタイムアウトした場合、定期監視エラーのエラーログをエラーログ記憶部１５０に格納する。その後、処理を終了する。

　次に受動的な定期監視について説明する。第２の実施の形態では、監視相手が出力する定期監視コマンドを、監視相手のハートビートとして取り扱う。
　図２３は、受動的な定期監視の処理手順を示すフローチャートである。以下、図２３に示す処理をステップ番号に沿って説明する。なお、以下の説明では、管理部制御部２１１がコンソール部１００の定期監視を行う場合を想定する。

　［ステップＳ２１１］定期監視部２１１ａは、コンソール部１００の定期監視が抑止中か否かを判断する。例えば定期監視部２１１ａは、監視ステータス記憶部２１１ｂ内のコンソール部１００に対応する監視ステータス情報のステータスが「監視抑止中」であれば、定期監視が抑止中であると判断する。定期監視が抑止中であれば、定期監視部２１１ａはステップＳ２１１の処理を繰り返す。定期監視が抑止中でなければ、定期監視部２１１ａは、処理をステップＳ２１２に進める。

　［ステップＳ２１２］定期監視部２１１ａは、定期監視用のタイマを起動し、時間の計測を開始する。
　［ステップＳ２１３］定期監視部２１１ａは、コンソール部１００から定期監視抑止指示を受信したか否かを判断する。定期監視部２１１ａは、定期監視抑止指示を受信した場合、処理をステップＳ２１６に進める。また定期監視部２１１ａは、定期監視抑止指示を受信していなければ、処理をステップＳ２１４に進める。

　［ステップＳ２１４］定期監視部２１１ａは、定期監視のＨＬＣコマンドを受信したか否かを判断する。定期監視部２１１ａは、ＨＬＣコマンドを受信した場合、処理をステップＳ２１５に進める。また定期監視部２１１ａは、ＨＬＣコマンドを受信していなければ、処理をステップＳ２１８に進める。

　［ステップＳ２１５］定期監視部２１１ａは、コンソール部１００に対して応答を送信する。
　［ステップＳ２１６］定期監視部２１１ａは、定期監視用のタイマを停止し、タイマの値を「０」にリセットする。

　［ステップＳ２１７］定期監視部２１１ａは、一定時間待機する。その後、定期監視部２１１ａは、処理をステップＳ２１１に進める。
　［ステップＳ２１８］定期監視部２１１ａは、定期監視のＨＬＣコマンドを受信していない場合、定期監視の待ち制限時間がタイムアウトしたか否かを判断する。例えば定期監視部２１１ａは、定期監視用のタイマの時間が、定期監視の待ち制限時間以上であれば、タイムアウトしたと判断する。タイムアウトした場合、定期監視部２１１ａは、処理をステップＳ２１９に進める。タイムアウトしていなければ、定期監視部２１１ａは、処理をステップＳ２１３に進める。

　［ステップＳ２１９］定期監視部２１１ａは、定期監視の待ち制限時間がタイムアウトした場合、定期監視エラーのエラーログをエラーログ記憶部２１１ｅに格納する。その後、処理を終了する。

　図２２、図２３に示したように、互いに相手方を監視する２つの装置があるとき、一方の装置が能動的に定期監視を行い、他方の装置が受動的に定期監視を行うことで、相互の定期監視に必要な通信量を削減することができる。

　次に、定期監視抑止指示が入力された場合の処理について、図２４、図２５を参照して説明する。なお以下の説明では、コンソール部１００が管理部内サーバ監視部２１２の定期監視を抑止する場合を想定する。

　図２４は、定期監視抑止管理処理の手順の一例を示す第１の図である。以下、図２４に示す処理をステップ番号に沿って説明する。以下の処理は、定期監視抑止指示を受信したときに開始される。

　［ステップＳ２２１］定期監視部１１０は、管理部内サーバ監視部２１２から定期監視抑止指示を受信すると、抑止解除待ち用のタイマを起動し、時間の計測を開始する。このとき定期監視部１１０は、例えば監視ステータス記憶部１２０内の管理部内サーバ監視部２１２に対応する管理ステータス情報のステータスを「監視抑止中」に変更する。

　［ステップＳ２２２］定期監視部１１０は、管理部内サーバ監視部２１２から定期監視抑止解除指示を受信したか否かを判断する。定期監視抑止解除指示を受信した場合、定期監視部１１０は、例えば監視ステータス記憶部１２０内の管理部内サーバ監視部２１２に対応する管理ステータス情報のステータスを「監視中」に変更し、処理を終了する。

　［ステップＳ２２３］定期監視部１１０は、抑止解除待ち制限時間がタイムアウトしたか否かを判断する。例えば定期監視部１１０は、抑止解除待ち用のタイマの時間が、所定の抑止解除待ち制限時間以上となった場合、タイムアウトしたと判断する。定期監視部１１０は、タイムアウトした場合、例えば監視ステータス制御部１３０に抑止解除待ち制限時間のタイムアウトを通知し、処理をステップＳ２２４に進める。また定期監視部１１０は、タイムアウトしていなければ、処理をステップＳ２２２に進める。

　［ステップＳ２２４］監視ステータス制御部１３０は、抑止解除待ち制限時間のタイムアウトの通知を受けると、監視ステータス要求を管理部制御部２１１に送信する。送信される監視ステータス要求では、管理部内サーバ監視部２１２が確認対象装置に指定されている。

　［ステップＳ２２５］監視ステータス制御部１３０は、監視ステータス用のタイマを起動し、時間の計測を開始する。その後、監視ステータス制御部１３０は、処理をステップＳ２２６（図２５参照）に進める。

　図２５は、定期監視抑止管理処理の手順の一例を示す第２の図である。以下、図２５に示す処理をステップ番号に沿って説明する。
　［ステップＳ２２６］監視ステータス制御部１３０は、監視ステータスの応答を受信したか否かを判断する。監視ステータス制御部１３０は、応答を受信した場合、処理をステップＳ２２９に進める。また監視ステータス制御部１３０は、応答を受信していない場合、処理をステップＳ２２７に進める。

　［ステップＳ２２７］監視ステータス制御部１３０は、監視ステータスの応答を受信していない場合、監視ステータスの応答待ち制限時間がタイムアウトしたか否かを判断する。例えば監視ステータス制御部１３０は、監視ステータス用のタイマの時間が、監視ステータスの応答待ち制限時間以上となった場合、タイムアウトしたと判断する。監視ステータス制御部１３０は、タイムアウトした場合、処理をステップＳ２２８に進める。また監視ステータス制御部１３０は、タイムアウトしていなければ、処理をステップＳ２２６に進める。

　［ステップＳ２２８］監視ステータス制御部１３０は、監視ステータスの応答待ち制限時間がタイムアウトすると、ＨＬＣ通信エラーのエラーログをエラーログ記憶部１５０に登録する。その後、監視ステータス制御部１３０は処理を終了する。

　［ステップＳ２２９］監視ステータス制御部１３０は、取得した監視ステータスが「監視中」または「応答受信済み」の少なくともいずれか一方か否かを判断する。監視ステータスが「監視中」または「応答受信済み」のいずれかであれば、監視ステータス制御部１３０は、処理をステップＳ２３０に進める。監視ステータスが「監視中」または「応答受信済み」のいずれでもなければ、監視ステータス制御部１３０は、処理をステップＳ２３３に進める。

　［ステップＳ２３０］監視ステータス制御部１３０は、管理部内サーバ監視部２１２に対して、ネットワークの接続を試行する。
　［ステップＳ２３１］監視ステータス制御部１３０は、管理部内サーバ監視部２１２からネットワーク接続が実行されたことを示す応答を受信したか否かを判断する。監視ステータス制御部１３０は、応答を受信した場合、処理を終了する。また監視ステータス制御部１３０は、応答を受信できなかった場合、処理をステップＳ２３２に進める。ここで応答を受信できなかった場合とは、例えばネットワーク接続を試行してから所定の制限時間を経過しても応答を受信できなかった場合である。

　［ステップＳ２３２］監視ステータス制御部１３０は、ネットワーク障害のエラーログを、エラーログ記憶部１５０に登録する。その後、処理が終了する。
　［ステップＳ２３３］監視ステータス制御部１３０は、取得した監視ステータスが「監視抑止中」または「監視タイムアウト」の少なくともいずれか一方か否かを判断する。監視ステータスが「監視抑止中」または「監視タイムアウト」のいずれかであれば、監視ステータス制御部１３０は、処理をステップＳ２３４に進める。監視ステータスが「監視抑止中」または「監視タイムアウト」のいずれでもなければ、監視ステータス制御部１３０は、処理を終了する。

　［ステップＳ２３４］監視ステータス制御部１３０は、再起動監視タイムアウトのエラーログを、エラーログ記憶部１５０に登録する。その後、監視ステータス制御部１３０は処理を終了する。

　以上のようにして、管理部内サーバ監視部２１２の動作監視の正確性を向上させることができる。例えば、コンソール部１００と管理部内サーバ監視部２１２との間のネットワーク障害が発生した場合に、管理部内サーバ監視部２１２が動作していないという誤ったエラー検出が抑止される。

　また管理部内サーバ監視部２１２の再起動後に、管理部内サーバ監視部２１２からコンソール部１００へのネットワーク接続に失敗しても、コンソール部１００から管理部内サーバ監視部２１２へのネットワーク接続は可能な場合がある。第２の実施の形態では、コンソール部１００において定期監視の抑止解除待ち制限時間がタイムアウトした場合、コンソール部１００から管理部内サーバ監視部２１２にネットワーク接続を試みる。ネットワーク接続に成功すれば、それ以降は、コンソール部１００と管理部内サーバ監視部２１２との間の通信は、正常に行うことができる。そのため、コンソール部１００からのネットワーク接続に成功した場合にはエラーとは扱わないことで、過剰なエラー検出が抑止される。

　〔その他の実施の形態〕
　第２の実施の形態では、管理部内サーバ監視部２１２を再起動する場合の例を示したが、コンソール部１００を再起動する場合や、管理部制御部２１１を再起動する場合にも、同様の処理を行うことができる。

　また、第２の実施の形態では、管理部内サーバ監視部２１２からの定期監視抑止解除指示がタイムアウトした場合に、管理部制御部２１１から監視ステータス情報を取得するが、他の情報のタイムアウト時にも同様の処理を行うことができる。例えばコンソール部１００による管理部内サーバ監視部２１２の定期監視の応答がタイムアウトした場合に、管理部制御部２１１から監視ステータス情報を取得するようにしてもよい。この場合、コンソール部１００は、取得した監視ステータス情報で、管理部内サーバ監視部２１２が正常に動作していることが示されていれば、コンソール部１００と管理部内サーバ監視部２１２との間のネットワーク障害が発生したものと判断する。またコンソール部１００は、取得した監視ステータス情報で、管理部内サーバ監視部２１２が正常に動作していないことが示されていれば、管理部内サーバ監視部２１２に障害が発生したものと判断する。

　また、管理部制御部２１１のように受動的な定期監視を行う装置では、例えばコンソール部１００からの定期監視コマンドの受信待ち制限時間がタイムアウトした場合に、管理部内サーバ監視部２１２から監視ステータス情報を取得するようにしてもよい。

　また第２の実施の形態は、相互監視を行う３つの装置による他の装置の監視例であるが、相互監視を行う装置数は、４つ以上であってもよい。その場合、例えば複数の装置を同時に再起動する場合もあり得る。このような場合、再起動されない２台の装置によって、再起動をした装置それぞれに対して、第２の実施の形態と同様の監視処理を行うことができる。

　また第２の実施の形態では、コンソール部１００は、管理部制御部２１１から取得した管理部内サーバ監視部２１２の監視ステータスが「監視中」や「応答受信済み」の正常状態を表しているときに、管理部内サーバ監視部２１２にネットワーク接続を行っている。このコンソール部１００によるネットワーク接続は、例えば、定期監視の抑止解除待ち制限時間のタイムアウト後、監視ステータス要求の送信前に実行することもできる。監視ステータス要求の送信前に管理部内サーバ監視部２１２へのネットワーク接続を行い、正常にネットワーク接続ができた場合、コンソール部１００は、管理部内サーバ監視部２１２が正常に動作していることを認識できる。そのため、監視ステータス要求の送信前に行ったネットワーク接続が正常に完了した場合、コンソール部１００は、管理部制御部２１１に監視ステータス要求を送信せずにすむ。

　なお、上記の各実施の形態に示した処理機能は、コンピュータによって実現することができる。その場合、情報処理装置１、コンソール部１００、管理部制御部２１１、および管理部内サーバ監視部２１２が有する機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記憶装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記憶装置には、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープなどがある。光ディスクには、ＤＶＤ、ＤＶＤ－ＲＡＭ、ＣＤ－ＲＯＭ／ＲＷなどがある。光磁気記録媒体には、ＭＯ（Magneto-Optical disc）などがある。

　プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ、ＣＤ－ＲＯＭなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

　プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。

　また、上記の処理機能の少なくとも一部を、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）などの電子回路で実現することもできる。

　上記については単に本発明の原理を示すものである。さらに、多数の変形、変更が当業者にとって可能であり、本発明は上記に示し、説明した正確な構成および応用例に限定されるものではなく、対応するすべての変形例および均等物は、添付の請求項およびその均等物による本発明の範囲とみなされる。

　１　情報処理装置
　１ａ　監視手段
　１ｂ　計時手段
　１ｃ　問い合わせ手段
　１ｄ　判断手段
　１ｅ　接続手段
　１ｆ　記憶装置
　２　被監視装置
　３　監視装置

Claims

　コンピュータに、
　ネットワークを介して接続された被監視装置からの所定の情報の受信待ち時間を計測し、
　受信待ちの制限時間を過ぎても前記所定の情報を受信できない場合、前記被監視装置を監視している監視装置に、前記被監視装置の動作状況を問い合わせ、
　前記監視装置からの応答に示される前記被監視装置の動作状態に基づいて前記被監視装置の障害か、前記被監視装置との間のネットワーク障害かを判断する、
　処理を実行させることを特徴とするプログラム。
　前記コンピュータに、さらに、
　前記被監視装置との間のネットワーク障害と判断された場合、前記被監視装置との間で前記ネットワークを介した通信接続を試行し、
　前記ネットワークを介した通信接続に成功した場合、前記被監視装置との間のネットワーク障害が発生したという判断を取り消す、
　処理を実行させることを特徴とする請求の範囲第１項記載のプログラム。
　前記所定の情報は、定期監視の抑止解除指示であり、
　前記コンピュータに、さらに、
　前記被監視装置が正常に動作しているか否かの定期的な監視を行い、
　前記被監視装置から定期監視の抑止指示を受信すると、前記被監視装置の定期的な監視を抑止すると共に、前記受信待ち時間の計測を開始し、
　前記抑止解除指示を受信すると、前記被監視装置の定期的な監視の抑止を解除する、
　処理を実行させることを特徴とする請求の範囲第１項記載のプログラム。
　前記コンピュータに、さらに、
　前記被監視装置との間のネットワーク障害と判断された場合、前記被監視装置との間で前記ネットワークを介した通信接続を試行し、
　前記ネットワークを介した通信接続に成功した場合、前記被監視装置の定期的な監視の抑止を解除する、
　処理を実行させることを特徴とする請求の範囲第３項記載のプログラム。
　前記コンピュータに、さらに、
　前記被監視装置の障害か、前記被監視装置との間のネットワーク障害かの判断結果を、記憶装置に格納する、
　処理を実行させることを特徴とする請求の範囲第１項乃至第４項のいずれかに記載のプログラム。
　前記コンピュータに、
　前記判断の際には、前記監視装置からの応答において前記被監視装置が異常であることが示されていた場合、前記被監視装置の障害と判断し、前記監視装置からの応答において前記被監視装置が正常であることが示されていた場合、前記被監視装置との間のネットワーク障害と判断する、
　処理を実行させることを特徴とする請求の範囲第１項乃至第５項のいずれかに記載のプログラム。
　ネットワークを介して接続された被監視装置からの所定の情報の受信待ち時間を計測する計時手段と、
　受信待ちの制限時間を過ぎても前記所定の情報を受信できない場合、前記被監視装置を監視している監視装置に、前記被監視装置の動作状況を問い合わせる問い合わせ手段と、
　前記監視装置からの応答に示される前記被監視装置の動作状態に基づいて前記被監視装置の障害か、前記被監視装置との間のネットワーク障害かを判断する判断手段と、
　を有することを特徴とする情報処理装置。
　ネットワークを介して接続された被監視装置からの所定の情報の受信待ち時間を計測し、
　受信待ちの制限時間を過ぎても前記所定の情報を受信できない場合、前記被監視装置を監視している監視装置に、前記被監視装置の動作状況を問い合わせ、
　前記監視装置からの応答に示される前記被監視装置の動作状態に基づいて前記被監視装置の障害か、前記被監視装置との間のネットワーク障害かを判断する、
　処理を実行させることを特徴とする監視方法。