(57)【要約】【課題】通信ネットワークに係る障害の検知精度を高く保つと共にコストの抑制を図る。【解決手段】ＩＰネットワークシステムにおける所定事象ごとに状況の変化を検知する状況変化把握部１１−１〜ｎと、所定事象ごとに状況を把握するための所定通信手順を実行する通信試行部１３と、状況変化把握部１１−１〜ｎで検知された変化ありの所定事象に対応する所定通信手順の試行を通信試行部１３に指示する試行選択部１２とを備える。【選択図】図２
2011155364.tif 000002
【特許請求の範囲】
【請求項１】
ＩＰネットワークシステムにおける所定事象ごとに状況の変化を検知する状況変化把握部と、
前記所定事象ごとに状況を把握するための所定通信手順を実行する通信試行部と、
前記状況変化把握部で検知された変化ありの所定事象に対応する前記所定通信手順の試行を前記通信試行部に指示する試行選択部と、
を備えたことを特徴とする障害検知装置。
【請求項２】
前記状況変化把握部は、ＩＰネットワークシステムの特定のリンクにおけるネットワーク輻輳を検知し、
前記通信試行部は、該リンクにおいて正常にＩＰ通信が行えるかを試行する、
ことを特徴とする請求項１に記載の障害検知装置。
【請求項３】
前記状況変化把握部は、ＩＰネットワークシステムに接続する特定のシグナリングサーバに対する一端末当たりの単位時間当たりシグナリングパケット送信に関する状況の変化を検知することを特徴とする請求項１に記載の障害検知装置。
【請求項４】
前記通信試行部は、前記特定のシグナリングサーバに対してシグナリングプロトコル通信手順を実行し、該シグナリングサーバの動作状況を確認することを特徴とする請求項３に記載の障害検知装置。
【請求項５】
前記通信試行部は、前記特定のシグナリングサーバの動作を記録したログを当該シグナリングサーバから取得し、該シグナリングサーバの動作状況を確認することを特徴とする請求項３に記載の障害検知装置。
【請求項６】
前記状況変化把握部は、ＩＰネットワークシステムに接続する特定のサーバに対する接続回数分布または接続間隔分布の変化を検知し、
前記通信試行部は、該サーバに対して通信可能かを確認する通信手順を試行する、
ことを特徴とする請求項１に記載の障害検知装置。
【請求項７】
前記状況変化把握部は、前記ＩＰネットワークシステムに接続するＴＣＰを用いた特定のサーバに対する端末の単位時間当たりの接続回数分布または接続間隔分布の変化を検知し、
前記通信試行部は、該サーバに対して通信可能かを確認するＴＣＰ通信手順を試行する、
ことを特徴とする請求項１に記載の障害検知装置。
【請求項８】
前記状況変化把握部は、前記ＩＰネットワークシステムに接続する特定のＷｅｂサーバの８０番ＴＣＰポートに対する端末の単位時間当たり接続回数の変化を検知し、
前記通信試行部は、前記特定のＷｅｂサーバに対してＨＴＴＰ通信手順を実行し、該Ｗｅｂサーバの動作状況を確認する、
ことを特徴とする請求項１に記載の障害検知装置。
【請求項９】
前記状況変化把握部は、前記ＩＰネットワークシステムに接続する特定のＤＮＳサーバに対する一端末当たりの単位時間当たりＱｕｅｒｙ送信回数の変化を検知し、
前記通信試行部は、前記特定のＤＮＳサーバに対してＱｕｅｒｙ送信通信手順を実行し、該ＤＮＳサーバの動作状況を確認する、
ことを特徴とする請求項１に記載の障害検知装置。
【請求項１０】
前記状況変化把握部は、「Ｍｏｂｉｌｅ  ＩＰ（ＭＩＰ）」の状況の変化を把握し、
前記通信試行部は、特定の「Ｈｏｍｅ  Ａｇｅｎｔ（ＨＡ）」に対してＭＩＰ通信手順を実行し、該ＨＡの動作状況を確認する、
ことを特徴とする請求項１に記載の障害検知装置。
【請求項１１】
前記状況変化把握部は、特定のＲＡＤＩＵＳ（Ｒｅｍｏｔｅ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｄｉａｌ  Ｉｎ  Ｕｓｅｒ  Ｓｅｒｖｉｃｅ）サーバの状況の変化を把握し、
前記通信試行部は、前記特定のＲＡＤＩＵＳサーバに対してＲＡＤＩＵＳ通信手順を実行し、該ＲＡＤＩＵＳサーバの動作状況を確認する、
ことを特徴とする請求項１に記載の障害検知装置。
【請求項１２】
ＩＰネットワークシステムに接続する特定のサーバ又は通信ノードにおける所定事象の状況の変化を検知する状況変化把握部と、
前記特定のサーバ又は通信ノードの動作状況を測定する動作状況監視システムに対して測定間隔を通知する測定間隔通知部と、
前記状況変化把握部で検知された状況の変化に応じて前記測定間隔を選択する測定間隔選択部と、
を備えたことを特徴とする監視制御装置。
【請求項１３】
前記測定間隔選択部は、前記状況変化把握部で検知された状況が異常な状況である場合に測定間隔を短くし、前記状況変化把握部で検知された状況が正常な状況である場合に測定間隔を長くする、
ことを特徴とする請求項１２に記載の監視制御装置。
【請求項１４】
ＩＰネットワークシステムにおける所定事象ごとに状況の変化を検知するステップと、
前記所定事象ごとに状況を把握するための所定通信手順の中から、前記検知された変化ありの所定事象に対応する所定通信手順の試行を選択するステップと、
前記選択された所定通信手順を実行するステップと、
をコンピュータに実行させるためのコンピュータプログラム。
【請求項１５】
ＩＰネットワークシステムに接続する特定のサーバ又は通信ノードにおける所定事象の状況の変化を検知するステップと、
前記検知された状況の変化に応じて、前記特定のサーバ又は通信ノードの動作状況を測定する動作状況監視システムにおける測定間隔を選択するステップと、
前記特定のサーバ又は通信ノードの動作状況を測定する動作状況監視システムに対して、前記選択された測定間隔を通知するステップと、
をコンピュータに実行させるためのコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信ネットワークに係る障害検知装置、監視制御装置およびコンピュータプログラムに関する。
【背景技術】
【０００２】
ＩＰ（Internet Protocol）ネットワークシステムを対象にした障害検知技術として、例えば、以下に示すような従来技術が知られている。
（１）特定のシグナリングパケットをキャプチャして解析することにより単位時間当たり呼接続回数ごとにユーザ数の割合を測定し、そのユーザ数の割合の変化に基づいて障害の有無を判定する（例えば特許文献１参照）。
（２）ＩＰパケットをキャプチャして解析することにより通信ノード別の送受パケット数又はサービスの種類別のアクセス回数を算出し、その算出値が規定値を越えた場合に障害ありと判定する。
（３）ＳＮＭＰ（例えば非特許文献１参照）等を用いて通信ノード又はアプリケーションサーバから動作状況（例えば、使用帯域、メモリ使用量、ＣＰＵ負荷など）を取得し、その動作状況が規定レベルを超えた場合に障害ありと判定する。
（４）通信ノードに蓄積されるログを取得して解析し、エラー回数が規定値を越えた場合に障害ありと判定する。
【０００３】
一方、例えば非特許文献２に記載の従来技術では、実際の通信手順の全部又は一部を試行することにより、通信ノードの動作状況を把握している。例えば、特定のＷｅｂサーバからホームページを取得する手順を実行し、その取得が失敗した場合に障害ありと判定する。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００９−０６５２７７号公報
【非特許文献】
【０００５】
【非特許文献１】“ＳＮＭＰ（Simple Network Management Protocol）”、IETF RFC1157
【非特許文献２】“Ｎａｇｉｏｓ”、インターネット＜ＵＲＬ：http://www.nagios.org＞
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかし、上述した従来技術（１）〜（４）では、把握した状況又は状況の変化が全て障害に起因するとは限らないことから誤判定を起こしやすい恐れがある。一方、非特許文献２に記載の従来技術では、実際の通信手順を実行することから、高い精度で障害を検知することが期待できる。しかしながら、通信事業者が提供するような大規模なＩＰネットワークシステムでは、障害検知対象箇所が多く、全ての障害検知対象箇所に対して定常的に実際の通信手順を実行することは、設備やトラヒックなどのコスト面において現実的ではない。
【０００７】
本発明は、このような事情を考慮してなされたもので、通信ネットワークに係る障害の検知精度を高く保つと共にコストの抑制を図ることのできる障害検知装置、監視制御装置およびコンピュータプログラムを提供することを課題とする。
【課題を解決するための手段】
【０００８】
上記の課題を解決するために、本発明に係る障害検知装置は、ＩＰネットワークシステムにおける所定事象ごとに状況の変化を検知する状況変化把握部と、前記所定事象ごとに状況を把握するための所定通信手順を実行する通信試行部と、前記状況変化把握部で検知された変化ありの所定事象に対応する前記所定通信手順の試行を前記通信試行部に指示する試行選択部と、を備えたことを特徴とする。
【０００９】
本発明に係る障害検知装置において、前記状況変化把握部は、ＩＰネットワークシステムの特定のリンクにおけるネットワーク輻輳を検知し、前記通信試行部は、該リンクにおいて正常にＩＰ通信が行えるかを試行することを特徴とする。
【００１０】
本発明に係る障害検知装置において、前記状況変化把握部は、ＩＰネットワークシステムに接続する特定のシグナリングサーバに対する一端末当たりの単位時間当たりシグナリングパケット送信に関する状況の変化を検知することを特徴とする。
【００１１】
本発明に係る障害検知装置において、前記通信試行部は、前記特定のシグナリングサーバに対してシグナリングプロトコル通信手順を実行し、該シグナリングサーバの動作状況を確認することを特徴とする。
【００１２】
本発明に係る障害検知装置において、前記通信試行部は、前記特定のシグナリングサーバの動作を記録したログを当該シグナリングサーバから取得し、該シグナリングサーバの動作状況を確認することを特徴とする。
【００１３】
本発明に係る障害検知装置において、前記状況変化把握部は、ＩＰネットワークシステムに接続する特定のサーバに対する接続回数分布または接続間隔分布の変化を検知し、前記通信試行部は、該サーバに対して通信可能かを確認する通信手順を試行することを特徴とする。
【００１４】
本発明に係る障害検知装置において、前記状況変化把握部は、前記ＩＰネットワークシステムに接続するＴＣＰを用いた特定のサーバに対する端末の単位時間当たりの接続回数分布または接続間隔分布の変化を検知し、前記通信試行部は、該サーバに対して通信可能かを確認するＴＣＰ通信手順を試行することを特徴とする。
【００１５】
本発明に係る障害検知装置において、前記状況変化把握部は、前記ＩＰネットワークシステムに接続する特定のＷｅｂサーバの８０番ＴＣＰポートに対する端末の単位時間当たり接続回数の変化を検知し、前記通信試行部は、前記特定のＷｅｂサーバに対してＨＴＴＰ通信手順を実行し、該Ｗｅｂサーバの動作状況を確認することを特徴とする。
【００１６】
本発明に係る障害検知装置において、前記状況変化把握部は、前記ＩＰネットワークシステムに接続する特定のＤＮＳサーバに対する一端末当たりの単位時間当たりＱｕｅｒｙ送信回数の変化を検知し、前記通信試行部は、前記特定のＤＮＳサーバに対してＱｕｅｒｙ送信通信手順を実行し、該ＤＮＳサーバの動作状況を確認することを特徴とする。
【００１７】
本発明に係る障害検知装置において、前記状況変化把握部は、「Ｍｏｂｉｌｅ  ＩＰ（ＭＩＰ）」の状況の変化を把握し、前記通信試行部は、特定の「Ｈｏｍｅ  Ａｇｅｎｔ（ＨＡ）」に対してＭＩＰ通信手順を実行し、該ＨＡの動作状況を確認することを特徴とする。
【００１８】
本発明に係る障害検知装置において、前記状況変化把握部は、特定のＲＡＤＩＵＳ（Ｒｅｍｏｔｅ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｄｉａｌ  Ｉｎ  Ｕｓｅｒ  Ｓｅｒｖｉｃｅ）サーバの状況の変化を把握し、前記通信試行部は、前記特定のＲＡＤＩＵＳサーバに対してＲＡＤＩＵＳ通信手順を実行し、該ＲＡＤＩＵＳサーバの動作状況を確認することを特徴とする。
【００１９】
本発明に係る監視制御装置は、ＩＰネットワークシステムに接続する特定のサーバ又は通信ノードにおける所定事象の状況の変化を検知する状況変化把握部と、前記特定のサーバ又は通信ノードの動作状況を測定する動作状況監視システムに対して測定間隔を通知する測定間隔通知部と、前記状況変化把握部で検知された状況の変化に応じて前記測定間隔を選択する測定間隔選択部と、を備えたことを特徴とする。
【００２０】
本発明に係る監視制御装置において、前記測定間隔選択部は、前記状況変化把握部で検知された状況が異常な状況である場合に測定間隔を短くし、前記状況変化把握部で検知された状況が正常な状況である場合に測定間隔を長くすることを特徴とする。
【００２１】
本発明に係るコンピュータプログラムは、ＩＰネットワークシステムにおける所定事象ごとに状況の変化を検知するステップと、前記所定事象ごとに状況を把握するための所定通信手順の中から、前記検知された変化ありの所定事象に対応する所定通信手順の試行を選択するステップと、前記選択された所定通信手順を実行するステップと、をコンピュータに実行させるためのコンピュータプログラムであることを特徴とする。
これにより、前述の障害検知装置がコンピュータを利用して実現できるようになる。
【００２２】
本発明に係るコンピュータプログラムは、ＩＰネットワークシステムに接続する特定のサーバ又は通信ノードにおける所定事象の状況の変化を検知するステップと、前記検知された状況の変化に応じて、前記特定のサーバ又は通信ノードの動作状況を測定する動作状況監視システムにおける測定間隔を選択するステップと、前記特定のサーバ又は通信ノードの動作状況を測定する動作状況監視システムに対して、前記選択された測定間隔を通知するステップと、をコンピュータに実行させるためのコンピュータプログラムであることを特徴とする。
これにより、前述の監視制御装置がコンピュータを利用して実現できるようになる。
【発明の効果】
【００２３】
本発明によれば、通信ネットワークに係る障害の検知精度を高く保つと共にコストの抑制を図ることができるという効果が得られる。
【図面の簡単な説明】
【００２４】
【図１】本発明の第１実施形態に係る通信ネットワークシステムの概略構成図である。
【図２】本発明の第１実施形態に係る障害検知装置１の構成を示すブロック図である。
【図３】図２に示す障害検知装置１に係る障害検知処理の実施例１である。
【図４】図２に示す障害検知装置１に係る障害検知処理の実施例２である。
【図５】本発明の第２実施形態に係る通信ネットワークシステムの概略構成図である。
【図６】本発明の第２実施形態に係る監視制御装置５の構成を示すブロック図である。
【図７】図６に示す監視制御装置５に係る監視制御処理の実施例である。
【発明を実施するための形態】
【００２５】
以下、図面を参照し、本発明の実施形態について順次説明する。
【００２６】
［第１実施形態］
図１は、本発明の第１実施形態に係る通信ネットワークシステムの概略構成図である。図１において、本実施形態に係る障害検知装置１はＩＰネットワーク２に接続されている。サーバ３−Ａ，ＢはＩＰネットワーク２に接続されている。ＩＰネットワーク２は通信ノード４を有する。
【００２７】
障害検知装置１は、ＩＰネットワーク２における状況の変化が発生した場合に、その状況変化に応じて適切な通信試行を行う。この通信試行の結果から、状況変化が障害に起因するものであるか否かを判定することができる。
【００２８】
図１を参照して、第１実施形態に係る通信ネットワークシステムにおける障害検知処理の全体手順を説明する。ステップＳＰ１では、障害検知装置１が、特定のサーバ３−Ａ，Ｂ及び特定の通信ノード４の各各における所定事象の状況の変化を把握する。ステップＳＰ２では、障害検知装置１が、状況の変化が発生した場合に、把握した状況の変化に応じて通信試行を選択する。ステップＳＰ３では、障害検知装置１が、選択した通信試行を行う。これにより、障害発生の有無を確認する。
【００２９】
図２は、本発明の第１実施形態に係る障害検知装置１の構成を示すブロック図である。図２において、障害検知装置１は、状況変化把握部１１−１〜ｎ、試行選択部１２及び通信試行部１３を有する。
【００３０】
状況変化把握部１１−１〜ｎは、ＩＰネットワークシステムにおける所定事象ごとに状況の変化を検知する。図１の例では、状況変化把握部１１−１〜ｎは、特定のサーバ３−Ａ，Ｂ及び特定の通信ノード４の各々における所定事象の状況の変化を検知する。
【００３１】
試行選択部１２は、状況変化把握部１１−１〜ｎで検知された変化ありの所定事象に対応する所定通信手順の試行を通信試行部１３に指示する。具体的には、各状況変化把握部１１−１〜ｎで検知する所定事象に各々対応する所定通信手順を通信試行部１３に予め設定ファイル等に定義しておく。通信試行部１３は、該定義に従って、状況変化把握部１１−１〜ｎで検知された変化ありの所定事象に対応する所定通信手順を選択し、選択した所定通信手順を通信試行部１３に通知する。
【００３２】
通信試行部１３は、状況変化把握部１１−１〜ｎで状況の変化を検知する所定事象ごとに、状況を把握するための所定通信手順を実行する。図１の例では、特定のサーバ３−Ａ，Ｂ及び特定の通信ノード４の各々における所定事象の状況を把握するための所定通信手順を実行する。但し、通信試行部１３は、試行選択部１２から通知された所定通信手順のみを試行する。この所定通信手順の試行の結果から、該当する所定事象の状況の変化が障害に起因するものであるか否かを判定することができる。これにより、障害の検知精度を高く保つことに寄与することが可能となる。又、実際に行われる通信手順は、状況変化把握部１１−１〜ｎによる状況の変化ありの検知結果に基づいて試行選択部１２で選択された通信手順のみに限定される。従って、全ての障害検知対象箇所に対して定常的に実際の通信手順を実行する必要がないので、設備やトラヒックなどのコストを抑制することができる。
【００３３】
次に、本発明の第１実施形態に係る障害検知処理の実施例を説明する。
【実施例１】
【００３４】
図３は、図２に示す障害検知装置１に係る障害検知処理の実施例１である。本実施例１では、図２の障害検知装置１において、３つの状況変化把握部１１−１，２，３を有する。以下、図３に示す障害検知処理手順を参照して実施例１を説明する。
【００３５】
状況変化把握部１１−１は、ＳＮＭＰを用いて、特定の通信ノード又はサーバからネットワーク帯域の状況を取得する（ステップＳ１−１）。図１の例では、特定のサーバ３−Ａ，Ｂ及び特定の通信ノード４から各ネットワーク帯域の状況を取得する。なお、取得する対象の通信ノード又はサーバは、単数でも複数でもよい。また、状況変化の判断は、取得する単位ごと単独で行ってもよく、又は、取得する単位を複数組み合わせて行ってもよい。
【００３６】
状況変化把握部１１−２は、特定のサーバの８０番ＴＣＰ（Transmission Control Protocol）ポートに対する端末の単位時間当たり接続回数分布を取得する（ステップＳ１−２）。図１の例では、特定のサーバ３−Ａ，Ｂの各８０番ＴＣＰポートに対する端末の単位時間当たり接続回数分布を取得する。なお、取得する対象のサーバは、単数でも複数でもよい。また、状況変化の判断は、取得する単位ごと単独で行ってもよく、又は、取得する単位を複数組み合わせて行ってもよい。
【００３７】
状況変化把握部１１−３は、特定のＤＮＳ（Domain Name System）サーバに対する一端末当たりの単位時間当たりＱｕｅｒｙ送信回数分布を取得する（ステップＳ１−３）。図１の例では、サーバ３−ＡがＤＮＳサーバであるとすると、特定のＤＮＳサーバ３−Ａに対する一端末当たりの単位時間当たりＱｕｅｒｙ送信回数分布を取得する。なお、取得する対象のＤＮＳサーバは、単数でも複数でもよい。また、状況変化の判断は、取得する単位ごと単独で行ってもよく、又は、取得する単位を複数組み合わせて行ってもよい。
【００３８】
次いで、状況変化把握部１１−１，２，３は、状況変化発生時に、試行選択部１２へ状況変化を通知する（ステップＳ２）。状況変化把握部１１−１は、ネットワーク帯域の状況に変化ありの場合に、その状況変化を試行選択部１２へ通知する。状況変化把握部１１−２は、接続回数分布に変化ありの場合に、その状況変化を試行選択部１２へ通知する。状況変化把握部１１−３は、Ｑｕｅｒｙ送信回数分布に変化ありの場合に、その状況変化を試行選択部１２へ通知する。
【００３９】
次いで、試行選択部１２は、状況変化把握部１１−１，２，３から通知された状況変化の種類に応じて、定義された通信手順の中から試行する通信手順を選択する（ステップＳ３）。本実施例１では、次の定義１−Ａ，Ｂ，Ｃを予め設定しておく。
【００４０】
定義１−Ａ：状況変化がネットワーク輻輳である場合に試行する通信手順は、ｐｉｎｇによる疎通確認である。
定義１−Ｂ：状況変化がＴＣＰベースのサーバ（ＨＴＴＰ（HyperText Transfer Protocol）サーバ等）でのユーザ接続回数が多い方に分布したである場合に試行する通信手順は、ＴＣＰ・スリーウェイ（３ｗａｙ）・ハンドシェイク（ｈａｎｄｓｈａｋｅ）によるＴＣＰポート疎通確認である。
定義１−Ｃ：状況変化がＤＮＳサーバへのユーザからの単位時間当たりＱｕｅｒｙ送信回数が多い方に分布したである場合に試行する通信手順は、ＤＮＳ・Ｑｕｅｒｙ送信によるＤＮＳサーバの動作確認である。
【００４１】
試行選択部１２は、状況変化把握部１１−１から通知された状況変化がネットワーク輻輳である場合には、上記定義１−Ａにより、試行する通信手順としてｐｉｎｇによる疎通確認を選択し、通信試行部１３へ通知する。これにより、通信試行部１３は、特定の通信ノード又はサーバに対してｐｉｎｇによる疎通確認を実施する（ステップＳ４−１）。図１の例では、特定のサーバ３−Ａ，Ｂ又は特定の通信ノード４のうちネットワーク輻輳が検知されたものに対してｐｉｎｇによる疎通確認を実施する。
【００４２】
試行選択部１２は、状況変化把握部１１−２から通知された状況変化がＴＣＰベースのサーバでのユーザ接続回数が多い方に分布したである場合には、上記定義１−Ｂにより、試行する通信手順としてＴＣＰ・スリーウェイ・ハンドシェイクによるＴＣＰポート疎通確認を選択し、通信試行部１３へ通知する。これにより、通信試行部１３は、特定のサーバに対してＴＣＰ・スリーウェイ・ハンドシェイクによるＴＣＰポート疎通確認を実施する（ステップＳ４−２）。図１の例では、特定のサーバ３−Ａ，Ｂのうちユーザ接続回数が多い方に分布したものに対してＴＣＰ・スリーウェイ・ハンドシェイクによるＴＣＰポート疎通確認を実施する。
【００４３】
試行選択部１２は、状況変化把握部１１−３から通知された状況変化がＤＮＳサーバへのユーザからの単位時間当たりＱｕｅｒｙ送信回数が多い方に分布したである場合には、上記定義１−Ｃにより、ＤＮＳ・Ｑｕｅｒｙ送信によるＤＮＳサーバの動作確認を選択し、通信試行部１３へ通知する。これにより、通信試行部１３は、特定のＤＮＳサーバに対してＤＮＳ・Ｑｕｅｒｙ送信によるＤＮＳサーバの動作確認を実施する（ステップＳ４−３）。図１の例では、サーバ３−ＡがＤＮＳサーバであり、該ＤＮＳサーバ３−Ａへのユーザからの単位時間当たりＱｕｅｒｙ送信回数が多い方に分布したとすると、特定のＤＮＳサーバ３−Ａに対してＤＮＳ・Ｑｕｅｒｙ送信によるＤＮＳサーバの動作確認を実施する。
【００４４】
なお、ＴＣＰ通信であること及びＤＮＳサーバへの通信であることは、状況変化把握部で把握するが、この状況把握の方法としてはパケットキャプチャによるＩＰパケット解析があり、この解析によって簡単に把握することが可能である。
【００４５】
また、本実施例１における通信試行部が行う試行方法は、あらかじめ定義されていればよく、上記定義１−Ａ，Ｂ，Ｃに限定されない。例えば、ステップＳ４−１において、正常に通信することができる状況であるかを確認する方法の他の例としては、特定のサーバからファイルをダウンロードしてファイルダウンロードにおけるスループットを測定し、このスループット測定値に基づいて状況を判定することが挙げられる。
【００４６】
また、本実施例１に係る状況変化把握部については、特許文献１に記載の技術、その他の状況変化把握技術を利用することができる。
【実施例２】
【００４７】
図４は、図２に示す障害検知装置１に係る障害検知処理の実施例２である。本実施例２では、図２の障害検知装置１において、３つの状況変化把握部１１−１，２，３を有する。以下、図４に示す障害検知処理手順を参照して実施例２を説明する。
【００４８】
状況変化把握部１１−１は、特定のＳＩＰサーバに対する一端末当たりの単位時間当たりＩｎｖｉｔｅパケット送信回数分布を取得する（ステップＳ１１−１）。なお、取得対象のＳＩＰサーバは、単数でも複数でもよい。また、状況変化の判断は、取得する単位ごと単独で行ってもよく、又は、取得する単位を複数組み合わせて行ってもよい。
【００４９】
状況変化把握部１１−２は、特定のＷｅｂサーバの８０番ＴＣＰポートに対する端末の単位時間当たり接続回数分布を取得する（ステップＳ１１−２）。なお、取得対象のＷｅｂサーバは、単数でも複数でもよい。また、状況変化の判断は、取得する単位ごと単独で行ってもよく、又は、取得する単位を複数組み合わせて行ってもよい。
【００５０】
状況変化把握部１１−３は、特定のＤＮＳサーバに対する一端末当たりの単位時間当たりＱｕｅｒｙ送信回数分布を取得する（ステップＳ１１−３）。なお、取得対象のＤＮＳサーバは、単数でも複数でもよい。また、状況変化の判断は、取得する単位ごと単独で行ってもよく、又は、取得する単位を複数組み合わせて行ってもよい。
【００５１】
次いで、状況変化把握部１１−１，２，３は、状況変化発生時に、試行選択部１２へ状況変化を通知する（ステップＳ１２）。状況変化把握部１１−１は、Ｉｎｖｉｔｅパケット送信回数分布に変化ありの場合に、その状況変化を試行選択部１２へ通知する。状況変化把握部１１−２は、接続回数分布に変化ありの場合に、その状況変化を試行選択部１２へ通知する。状況変化把握部１１−３は、Ｑｕｅｒｙ送信回数分布に変化ありの場合に、その状況変化を試行選択部１２へ通知する。
【００５２】
次いで、試行選択部１２は、状況変化把握部１１−１，２，３から通知された状況変化の対象に応じて、定義された通信手順の中から試行する通信手順を選択する（ステップＳ１３）。本実施例２では、次の定義２−Ａ，Ｂ，Ｃを予め設定しておく。
【００５３】
定義２−Ａ：状況変化の対象がＳＩＰサーバである場合に試行する通信手順は、ＳＩＰによるＳＩＰサーバの動作確認である。
定義２−Ｂ：状況変化の対象がＷｅｂサーバである場合に試行する通信手順は、ＨＴＴＰによるＷｅｂサーバの動作確認である。
定義２−Ｃ：状況変化の対象がＤＮＳサーバである場合に試行する通信手順は、ＤＮＳ・Ｑｕｅｒｙ送信によるＤＮＳサーバの動作確認である。
【００５４】
試行選択部１２は、状況変化把握部１１−１から状況変化が通知された場合には、上記定義２−Ａにより、試行する通信手順としてＳＩＰによるＳＩＰサーバの動作確認を選択し、通信試行部１３へ通知する。これにより、通信試行部１３は、特定のＳＩＰサーバに対してＳＩＰ通信手順を実行し、該ＳＩＰサーバの動作状況を確認する（ステップＳ１４−１）。
【００５５】
試行選択部１２は、状況変化把握部１１−２から状況変化が通知された場合には、上記定義２−Ｂにより、試行する通信手順としてＨＴＴＰによるＷｅｂサーバの動作確認を選択し、通信試行部１３へ通知する。これにより、通信試行部１３は、特定のＷｅｂサーバに対してＨＴＴＰ通信手順を実行し、該Ｗｅｂサーバの動作状況を確認する（ステップＳ１４−２）。
【００５６】
試行選択部１２は、状況変化把握部１１−３から状況変化が通知された場合には、上記定義２−Ｃにより、試行する通信手順としてＤＮＳ・Ｑｕｅｒｙ送信によるＤＮＳサーバの動作確認を選択し、通信試行部１３へ通知する。これにより、通信試行部１３は、特定のＤＮＳサーバに対してＱｕｅｒｙ送信通信手順を実行し、該ＤＮＳサーバの動作状況を確認する（ステップＳ１４−３）。
【００５７】
なお、本実施例２における通信試行部が行う試行方法は、あらかじめ定義されていればよく、上記定義２−Ａ，Ｂ，Ｃに限定されない。例えば、ステップＳ１４−１において、ＳＩＰサーバの動作を確認する方法の他の例としては、当該ＳＩＰサーバの動作を記録したログを当該ＳＩＰサーバから取得して確認することが挙げられる。
【００５８】
また、本実施例２では、シグナリング用のサーバ（シグナリングサーバ）としてＳＩＰサーバに適用したが、これに限定されず、通信の際のシグナリングで接続するサーバに広く適用することができる。
【００５９】
また、本実施例２に係る状況変化把握部については、特許文献１に記載の技術、その他の状況変化把握技術を利用することができる。例えば、状況変化把握部は、特定のサーバに接続する回数の分布についての変化を把握することが挙げられる。又は、状況変化把握部は、特定のサーバに接続する間隔の分布についての変化を把握することが挙げられる。又は、状況変化把握部は、特定のサーバに接続する回数の分布についての変化と特定のサーバに接続する間隔の分布についての変化との両方を把握することが挙げられる。
【００６０】
また、特許文献１に記載の技術を利用して、「Ｍｏｂｉｌｅ  ＩＰ（ＭＩＰ）」の障害を検知するようにしてもよい。例えば、状況変化把握部がＭＩＰの状況の変化を把握し、通信試行部が特定の「Ｈｏｍｅ  Ａｇｅｎｔ（ＨＡ）」に対してＭＩＰ通信手順を実行して該ＨＡの動作状況を確認することが挙げられる。
【００６１】
また、特許文献１に記載の技術を利用して、ＲＡＤＩＵＳ（Ｒｅｍｏｔｅ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｄｉａｌ  Ｉｎ  Ｕｓｅｒ  Ｓｅｒｖｉｃｅ）サーバの障害を検知するようにしてもよい。例えば、状況変化把握部がＲＡＤＩＵＳサーバの状況の変化を把握し、通信試行部が特定のＲＡＤＩＵＳサーバに対しＲＡＤＩＵＳ通信手順を実行して該ＲＡＤＩＵＳサーバの動作状況を確認することが挙げられる。
【００６２】
［第２実施形態］
図５は、本発明の第２実施形態に係る通信ネットワークシステムの概略構成図である。図５において、本実施形態に係る監視制御装置５はＩＰネットワーク２に接続されている。サーバ３−Ａ，Ｂ及び動作状況監視システム６はＩＰネットワーク２に接続されている。なお、サーバ３−Ａ，Ｂの種類としては、例えばＷｅｂサーバ、ＤＮＳサーバ、データベースサーバなど、ＩＰネットワークに接続されるサーバであればよい。
【００６３】
動作状況監視システム６は、定期的に実際の通信手順の全部又は一部を試行することにより、サーバ３−Ａ，Ｂの動作状況を監視している。動作状況監視システム６としては、例えば非特許文献２に記載される。
【００６４】
監視制御装置５は、ＩＰネットワーク２における状況の変化に応じて、動作状況監視システム６に対し、実際の通信手順を試行する間隔（測定間隔）を指示する。これにより、動作状況監視システム６の測定間隔を自動的に調整し、実際の通信手順を用いた精度の高い障害検知を行うと共に設備やトラヒックなどのコストの抑制を図る。
【００６５】
まず、図５を参照して、第２実施形態に係る通信ネットワークシステムにおける障害検知処理の全体手順を説明する。ステップＳ２１−１では、動作状況監視システム６が、設定された測定間隔で実際の通信手順を試行し、サーバ３−Ａ，Ｂの動作状況を確認する。ステップＳ２２では、監視制御装置５が、サーバ３−Ａ，Ｂにおける所定事象の状況の変化を把握する。ステップＳ２３では、監視制御装置５が、把握した状況の変化に応じて測定間隔を選択し、動作状況監視システム６へ通知する。これにより、動作状況監視システム６が、監視制御装置５から通知された測定間隔に、測定間隔の設定を変更する。
【００６６】
図６は、本発明の第２実施形態に係る監視制御装置５の構成を示すブロック図である。図６において、監視制御装置５は、状況変化把握部５１−１〜ｎ、測定間隔選択部５２及び測定間隔通知部５３を有する。
【００６７】
状況変化把握部５１−１〜ｎは、ＩＰネットワークシステムに接続する特定のサーバ又は通信ノードにおける所定事象の状況の変化を検知する。図５の例では、状況変化把握部５１−１〜ｎは、特定のサーバ３−Ａ，Ｂの各々における所定事象の状況の変化を検知する。
【００６８】
測定間隔選択部５２は、状況変化把握部５１−１〜ｎで検知された状況の変化に応じて測定間隔を選択する。測定間隔通知部５３は、特定のサーバ又は通信ノードの動作状況を測定する動作状況監視システムに対して測定間隔を通知する。図５の例では、特定のサーバ３−Ａ，Ｂの動作状況を測定する動作状況監視システム６に対して測定間隔を通知する。
【００６９】
図７は、図６に示す監視制御装置５に係る監視制御処理の実施例である。本実施例では、図６の監視制御装置５において、２つの状況変化把握部５１−１，２を有する。以下、図７に示す監視制御処理手順を参照して実施例を説明する。なお、本実施例では、図５において、サーバ３−ＡがＷｅｂサーバ（以下、ＷｅｂサーバＡと称する）であり、サーバ３−ＢがＤＮＳサーバ（以下、ＤＮＳサーバＢと称する）であるとする。又、動作状況監視システム６は、ＷｅｂサーバＡ及びＤＮＳサーバＢの動作状況を測定するものとする。
【００７０】
状況変化把握部５１−１は、ＷｅｂサーバＡの８０番ＴＣＰポートに対する端末の単位時間当たり接続回数分布を取得する（ステップＳ３１−１）。状況変化把握部５１−２は、ＤＮＳサーバＢに対する一端末当たりの単位時間当たりＱｕｅｒｙ送信回数分布を取得する（ステップＳ３１−２）。
【００７１】
次いで、状況変化把握部５１−１，２は、状況変化発生時に、測定間隔選択部５２へ状況変化を通知する（ステップＳ３２）。状況変化把握部５１−１は、接続回数分布に変化ありの場合に、その状況変化を測定間隔選択部５２へ通知する。状況変化把握部５１−２は、Ｑｕｅｒｙ送信回数分布に変化ありの場合に、その状況変化を測定間隔選択部５２へ通知する。
【００７２】
次いで、測定間隔選択部５２は、状況変化把握部５１−１，２から通知された状況変化の種類に応じて、所定の規則に従い、測定間隔を選択する（ステップＳ３３）。本実施例では、次の規則３−Ａ，Ｂを予め設定しておく。
【００７３】
規則３−Ａ：以前よりも端末接続回数又はＱｕｅｒｙ送信回数が多い方に分布した場合には、状況に問題が発生した（異常な状況である）と判断し、測定間隔を短くする。但し、測定間隔の下限が設定されている場合は、測定間隔の下限を最短間隔とする。
規則３−Ｂ：以前よりも端末接続回数又はＱｕｅｒｙ送信回数が少ない方に分布した場合には、状況に問題がない（正常な状況である）と判断し、測定間隔を長くする。但し、測定間隔の上限が設定されている場合は、測定間隔の上限を最長間隔とする。
【００７４】
測定間隔選択部５２は、状況変化把握部５１−１から通知された状況変化が、以前よりも端末接続回数が多い方に分布したである場合には、上記規則３−Ａにより、ＷｅｂサーバＡの測定間隔として以前よりも短い測定間隔を選択し、測定間隔通知部５３へ通知する（ステップＳ３４−１）。これにより、測定間隔通知部５３は、測定間隔選択部５２から通知されたＷｅｂサーバＡの測定間隔を動作状況監視システム６へ通知する。
【００７５】
測定間隔選択部５２は、状況変化把握部５１−２から通知された状況変化が、以前よりもＱｕｅｒｙ送信回数が多い方に分布したである場合には、上記規則３−Ａにより、ＤＮＳサーバＢの測定間隔として以前よりも短い測定間隔を選択し、測定間隔通知部５３へ通知する（ステップＳ３４−１）。これにより、測定間隔通知部５３は、測定間隔選択部５２から通知されたＤＮＳサーバＢの測定間隔を動作状況監視システム６へ通知する。
【００７６】
測定間隔選択部５２は、状況変化把握部５１−１から通知された状況変化が、以前よりも端末接続回数が少ない方に分布したである場合には、上記規則３−Ｂにより、ＷｅｂサーバＡの測定間隔として以前よりも長い測定間隔を選択し、測定間隔通知部５３へ通知する（ステップＳ３４−２）。これにより、測定間隔通知部５３は、測定間隔選択部５２から通知されたＷｅｂサーバＡの測定間隔を動作状況監視システム６へ通知する。
【００７７】
測定間隔選択部５２は、状況変化把握部５１−２から通知された状況変化が、以前よりもＱｕｅｒｙ送信回数が少ない方に分布したである場合には、上記規則３−Ｂにより、ＤＮＳサーバＢの測定間隔として以前よりも長い測定間隔を選択し、測定間隔通知部５３へ通知する（ステップＳ３４−２）。これにより、測定間隔通知部５３は、測定間隔選択部５２から通知されたＤＮＳサーバＢの測定間隔を動作状況監視システム６へ通知する。
【００７８】
なお、測定間隔の選択方法としては、例えば、一定の時間単位で増減させる方法と異なる時間単位で増減させる方法とが挙げられる。異なる時間単位で増減させる方法としては、例えば、測定間隔を短縮する方向と伸長する方向とで時間単位を異なるようにする方法がある。又、測定間隔の初期値を定めておき、測定間隔の初期値の近くでは比較的短い時間単位を使用し、測定間隔の初期値からある程度離れたところからは比較的長い時間単位を使用する方法がある。
【００７９】
又、測定間隔の初期値よりも短くなった測定間隔については、状況変化把握部から状況変化が通知されなくなったら、徐々に初期値に戻すようにしてもよい。
【００８０】
上述した第２実施形態によれば、状況変化が多発するような状況に対し、測定間隔が次第に短くなり、当該サーバに対する監視が強化されることになる。これにより、障害発生を検知するまでに要する時間を短縮することが可能になる。
【００８１】
なお、第２実施形態においても、上述の第１実施形態と同様に、特許文献１に記載の技術、その他の状況変化把握技術を利用することができる。
【００８２】
上述した実施形態によれば、従来、状況の変化だけでは障害の誤検知となっていた事象に対して実際の通信手順を試行することにより、障害の検知精度を上げる効果が得られる。又、実際の通信手順の試行は状況の変化に応じて行うので、設備やトラヒックなどのコストを抑制する効果が得られる。
【００８３】
又、本実施形態によれば、以下の効果が得られる。
（１）従来、大規模ＩＰネットワークの場合、多数のサーヒスを同時に監視する必要がある。そのためには、通信手順を試行するための装置の設置や通信試行プログラムを多数動作させ得る必要があるため、コストや通信試行のためのプログラムが発生する負荷の問題が生じていた。これらの問題に対して、本発明は非常に有効な解決手段を提供することができる。
【００８４】
（２）従来、ＩＰネットワークにおける状況の変化が発生した要因がわかりにくく、その状況の変化が実際にＩＰ通信やサービス提供に影響を及ぼしているのかを把握しにくいという問題があった。例えば、ユーザの試行回数が多い方に分布したとして、これが単にユーザが同時に多数のデータを取ろうとして試行回数が多いのか（すなわち、通信状況としては問題がない）、サーバに障害が発生していることによりユーザが再接続しようとして試行回数が多いのかを判定することができないという問題が生じていた。又、サーバなどが使用しているネットワーク帯域の増加が発生した場合、これがＩＰ通信やサービス提供に影響を及ぼしているのか、それとも単なる一時的な増加であり問題ないのかを判定することが難しいという問題が生じていた。これらの問題に対して、本発明は非常に有効な解決手段を提供することができる。
【００８５】
以上、本発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、本発明の要旨を逸脱しない範囲の設計変更等も含まれる。
例えば、図３、図４又は図７に示す各ステップを実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより、障害検知処理又は監視制御処理を行ってもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものであってもよい。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、フラッシュメモリ等の書き込み可能な不揮発性メモリ、ＤＶＤ（Digital Versatile Disk）等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。
【００８６】
さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（例えばＤＲＡＭ（Dynamic Random Access Memory））のように、一定時間プログラムを保持しているものも含むものとする。
また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。
また、上記プログラムは、前述した機能の一部を実現するためのものであっても良い。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であっても良い。
【符号の説明】
【００８７】
１…障害検知装置、１１−１〜ｎ，５１−１〜ｎ…状況変化把握部、１２…試行選択部、１３…通信試行部、５２…測定間隔選択部、５３…測定間隔通知部
【図１】
2011155364.tif 000003
【図２】
2011155364.tif 000004
【図３】
2011155364.tif 000005
【図４】
2011155364.tif 000006
【図５】
2011155364.tif 000007
【図６】
2011155364.tif 000008
【図７】
2011155364.tif 000009