ネットワーク障害検出プログラム、ネットワーク障害検出装置、およびネットワーク障害検出方法
【課題】アクセス先の障害と上流ネットワークの障害とを自動的に切り分けること。
【解決手段】各端末Ｓｉは、あらかじめ設定された上流ネットワーク１０３のキャリア１０１により、インターネット１００に接続可能である。ネットワーク障害検出装置１１１は端末ＳｉおよびサーバＤｊ間のトラフィックを監視する。上流ネットワーク１０３は、インターネットプロバイダなどのキャリア１０１，１０２からなる。ネットワーク障害検出装置１１１がキャリア１０１の障害発生を検出することで、端末ＳｉをサーバＤｊに接続させるキャリア１０１の障害とサーバＤｊの障害とを切り分ける。ネットワーク障害検出装置１１１は、上流ネットワーク１０３との接続を変更するなどの対処をネットワーク管理装置１１２に指示する。これにより、下流ネットワーク１１０をインターネット１００に接続させるキャリアがキャリア１０１からキャリア１０２に切り替わる。
【解決手段】各端末Ｓｉは、あらかじめ設定された上流ネットワーク１０３のキャリア１０１により、インターネット１００に接続可能である。ネットワーク障害検出装置１１１は端末ＳｉおよびサーバＤｊ間のトラフィックを監視する。上流ネットワーク１０３は、インターネットプロバイダなどのキャリア１０１，１０２からなる。ネットワーク障害検出装置１１１がキャリア１０１の障害発生を検出することで、端末ＳｉをサーバＤｊに接続させるキャリア１０１の障害とサーバＤｊの障害とを切り分ける。ネットワーク障害検出装置１１１は、上流ネットワーク１０３との接続を変更するなどの対処をネットワーク管理装置１１２に指示する。これにより、下流ネットワーク１１０をインターネット１００に接続させるキャリアがキャリア１０１からキャリア１０２に切り替わる。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、各アクセス元とそれぞれのアクセス先とを接続させるネットワークの障害を検出するネットワーク障害検出プログラム、ネットワーク障害検出装置、およびネットワーク障害検出方法に関する。
【背景技術】
【０００２】
従来からネットワーク障害を検出するシステムが開示されている（たとえば、下記特許文献１を参照。）。この特許文献１では、汎用コンピュータと端末装置との間に物理的に２本の通信回線を設けたオンラインシステムに対し、回線障害時に自動的に回線の切り替えをおこなう技術である。
【０００３】
【特許文献１】特開平７−８４９１２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、上述した特許文献１では、オンラインシステムを構成する汎用コンピュータは１台に固定されているため、不特定多数のアクセス元（端末装置）から不特定多数のアクセス先に接続するネットワークの障害を検出することができないという問題があった。
【０００５】
このようなネットワークは、不特定多数のアクセス元を下流ネットワークとした場合に、上流ネットワークと呼ばれ、下流ネットワークの端末装置をＷｅｂサーバなどのアクセス先に接続させるキャリア（インターネットサービスプロバイダ）である。この上流ネットワークに障害が発生したことを検知する場合、大別すると、上流ネットワーク側の管理者（一個人だけでなく管理組織という意味も含む。以下同様）からの通知による方法と、自ネットワーク内で独自に調査する方法に分けられる。
【０００６】
上流ネットワークからは一般的に障害発生が通知されるものであるが、実際には形式的な通知となっているケースもある。また障害の内容によっては、ネットワークの管理者自身が障害の発生に気がつかない場合もある。このような障害はサイレント障害と呼ばれ、通知はおこなわれない。それらの結果として通知を受ける下流ネットワーク側では、通知はあまり期待できない状況がある。
【０００７】
したがって、上流ネットワークからの通知によらない自主的な調査による検知手段が重要であるが、それらには、外部サーバとの接続可否の確認（ハートビート方式）、ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）によるトラフィック流量の監視、キャプチャによるアクセス状況の取得などがある。いずれも常時状況を把握しておき、状況が通常時と変化したら障害と判断する。
【０００８】
しかしながら、上述したハートビート方式では、ハートビート先となるアクセス先がダウンしたにもかかわらず、そのアクセス先のＷｅｂサーバの障害と判断せず、上流ネットワーク障害であると誤検出してしまうという問題があった。
【０００９】
また、ＳＮＭＰによるトラフィック流量の監視やキャプチャによるアクセス状況の取得では、通信先が偏りを持っていた場合に、その特定サーバでの障害に起因するトラフィックの変化を上流ネットワーク障害であると誤検出してしまうという問題があった。
【００１０】
このように、上述した従来技術では、上流ネットワークからの通知がなければ、アクセス先となるサーバの障害と上流ネットワークの障害とを区別することができないという問題があった。
【００１１】
この発明は、上述した従来技術による問題点を解消するため、アクセス先となるサーバの障害と上流ネットワークの障害とを自動的に切り分けることにより、障害に応じた復旧対策を円滑におこなうことができるネットワーク障害検出プログラム、ネットワーク障害検出装置、およびネットワーク障害検出方法を提供することを目的とする。
【課題を解決するための手段】
【００１２】
上述した課題を解決し、目的を達成するため、このネットワーク障害検出プログラム、ネットワーク障害検出装置、およびネットワーク障害検出方法は、各アクセス元からそれぞれのアクセス先へのリクエストパケットと当該リクエストパケットに対するレスポンスパケットとを取得し、その取得結果に基づいて、前記アクセス先へのアクセス成否を判定し、現在までの前記各アクセス先のアクセス総数およびアクセス成立回数を、判定されたアクセス成否に基づいて更新し、更新された場合、当該更新後における前記各アクセス先のアクセス総数およびアクセス成立回数に基づいて、前記アクセス先へのアクセス可否を判定し、その判定結果に基づいて、前記各アクセス元と前記アクセス先とを接続させるネットワークに障害が発生したか否かを判定し、その判定結果を出力することを要件とする。
【００１３】
このネットワーク障害検出プログラム、ネットワーク障害検出装置、およびネットワーク障害検出方法によれば、各アクセス元とアクセス先とを接続させるネットワークの障害と、アクセス先の障害とを切り分けることができる。したがって、信頼性の高い障害検出結果を報知することができる。
【００１４】
また、前記アクセス不可と判定されたアクセス先の数が所定数以上である場合、前記ネットワークに障害が発生したと判定することとしてもよい。
【００１５】
このネットワーク障害検出プログラム、ネットワーク障害検出装置、およびネットワーク障害検出方法によれば、複数のアクセス先が同時に障害発生する可能性よりも、単一のネットワークに障害が発生する可能性が高いという性質を利用することで、ネットワークの障害とアクセス先の障害とを切り分けることができる。
【００１６】
また、前記アクセス先の総数と前記アクセス可と判定されたアクセス先の数とに基づいて、前記全アクセス先のうちアクセス可となるアクセス先の存在確率を算出し、その存在確率が所定確率以下である場合、前記ネットワークに障害が発生したと判定することとしてもよい。
【００１７】
このネットワーク障害検出プログラム、ネットワーク障害検出装置、およびネットワーク障害検出方法によれば、所定確率以下の場合、ネットワーク障害と判定し、所定確率より大きい場合、アクセス先に障害が発生していると判定する。なお、算出された存在確率が１００％の場合は、いずれの障害も発生していないことがわかる。
【００１８】
また、所定時間の経過を検出し、経過が検出された場合、前記所定時間前の時点以前における前記各アクセス先のアクセス総数およびアクセス成立回数を消去することにより、現在までの前記各アクセス先のアクセス総数およびアクセス成立回数を更新することとしてもよい。
【００１９】
このネットワーク障害検出プログラム、ネットワーク障害検出装置、およびネットワーク障害検出方法によれば、ネットワークの障害とアクセス先の障害との切り分けをリアルタイムで実現することができる。
【発明の効果】
【００２０】
このネットワーク障害検出プログラム、ネットワーク障害検出装置、およびネットワーク障害検出方法によれば、アクセス先となるサーバの障害と上流ネットワークの障害とを自動的に切り分けることにより、障害に応じた復旧対策を円滑におこなうことができるという効果を奏する。
【発明を実施するための最良の形態】
【００２１】
以下に添付図面を参照して、このネットワーク障害検出プログラム、ネットワーク障害検出装置、およびネットワーク障害検出方法の好適な実施の形態を詳細に説明する。まず、実施の形態の全体構成について説明する。なお、本実施の形態では、アクセス元を端末、アクセス先をサーバとして説明する。そして、端末をサーバに接続させる上流ネットワークの障害とサーバとの障害を切り分ける。
【００２２】
（システム構成）
図１は、実施の形態にかかるネットワーク障害検出システムのシステム構成を示す説明図である。図１において、下流ネットワーク１１０は、アクセス元となる多数の端末Ｓ１〜Ｓｎとネットワーク障害検出装置１１１とネットワーク管理装置１１２とから構成される。下流ネットワーク１１０としては、たとえば、企業網が挙げられる。各端末Ｓｉ（ｉ＝１〜ｎ）は、あらかじめ設定された上流ネットワーク１０３の特定のキャリア１０１により、インターネット１００に接続可能である。ネットワーク障害検出装置１１１は、端末ＳｉおよびサーバＤｊ（ｊ＝１〜ｍ）間のトラフィックを監視する。ネットワーク管理装置１１２は、ルータなど上流ネットワーク１０３とのパケットを中継する装置である。
【００２３】
上流ネットワーク１０３は、インターネットプロバイダなどのキャリア１０１，１０２からなる。本例では、下流ネットワーク１１０をインターネット１００に接続させるキャリアをキャリア１０１とする。ネットワーク障害検出装置１１１においてキャリア１０１の障害発生が検出されると、上流ネットワーク１０３との接続を変更するなどの対処をネットワーク管理装置１１２に指示する。これにより、下流ネットワーク１１０をインターネット１００に接続させるキャリアがキャリア１０１からキャリア１０２に切り替わる。また、インターネット上には、端末Ｓｉと通信するＷｅｂサーバなどの不特定多数のサーバＤ１〜Ｄｍが存在する。ｍは、端末Ｓｉのアクセス先としてあらたに指定されるとその都度追加されるため増加する値であり、固定数ではない。
【００２４】
（コンピュータのハードウェア構成）
つぎに、実施の形態にかかるコンピュータ（ネットワーク障害検出装置１１１、ネットワーク管理装置１１２、端末Ｓｉ、サーバＤｊ、キャリア１０１，１０２内のコンピュータ）のハードウェア構成について説明する。
【００２５】
図２は、実施の形態にかかるコンピュータのハードウェア構成を示す説明図である。図２において、ネットワーク障害検出装置１１１は、コンピュータ本体２１０と、入力装置２２０と、出力装置２３０と、から構成されており、不図示のルータやモデムを介して各種ネットワーク２４０に接続可能である。
【００２６】
コンピュータ本体２１０は、ＣＰＵ，メモリ，インターフェースを有する。ＣＰＵは、ネットワーク障害検出装置１１１の全体の制御を司る。メモリは、ＲＯＭ，ＲＡＭ，ＨＤ，光ディスク２１１，フラッシュメモリなどの記憶領域から構成される。記憶領域はＣＰＵのワークエリアとして使用される。
【００２７】
また、記憶領域には各種プログラムが格納されており、ＣＰＵからの命令に応じてロードされる。ＨＤおよび光ディスク２１１はディスクドライブによりデータのリード／ライトが制御される。また、光ディスク２１１およびフラッシュメモリはコンピュータ本体２１０に対し着脱自在である。インターフェースは、入力装置２２０からの入力、出力装置２３０への出力、ネットワーク２４０に対する送受信の制御をおこなう。
【００２８】
また、入力装置２２０としては、キーボード２２１、マウス２２２、スキャナ２２３などがある。キーボード２２１は、文字、数字、各種指示などの入力のためのキーを備え、データの入力をおこなう。また、タッチパネル式であってもよい。マウス２２２は、カーソルの移動や範囲選択、あるいはウィンドウの移動やサイズの変更などをおこなう。スキャナ２２３は、画像を光学的に読み取る。読み取られた画像は画像データとして取り込まれ、コンピュータ本体２１０内の記憶領域に格納される。なお、スキャナ２２３にＯＣＲ機能を持たせてもよい。
【００２９】
また、出力装置２３０としては、ディスプレイ２３１、スピーカ２３２、プリンタ２３３などがある。ディスプレイ２３１は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。スピーカ２３２は、効果音や読み上げ音などの音声を出力する。また、プリンタ２３３は、画像データや文書データを印刷する。
【００３０】
（データ構造およびデータベース）
つぎに、実施の形態にかかるネットワーク障害検出装置１１１において利用されるデータのデータ構造およびデータベースについて説明する。図３は、リクエストパケットのデータ構造を示す説明図である。リクエストパケット３００は、端末ＳｉからサーバＤｊに対して送信されるパケットである。リクエストパケット３００は、ヘッダとして送信元アドレス３０１および宛先アドレス３０２とリクエストデータ３０３とを有する。送信元アドレス３０１は、アクセス元である端末ＳｉのＩＰアドレスである。宛先アドレス３０２は、アクセス先であるサーバＤｊのＩＰアドレスである。
【００３１】
図４は、レスポンスパケットのデータ構造を示す説明図である。レスポンスパケット４００は、端末Ｓｉからのリクエストパケット３００を受信したサーバＤｊからその端末Ｓｉに対して送信されるパケットである。レスポンスパケット４００は、ヘッダとして送信元アドレス４０１および宛先アドレス４０２とレスポンスデータ４０３とを有する。送信元アドレス４０１は、アクセス先となったサーバＤｊのＩＰアドレスである。宛先アドレス４０２は、アクセス元である端末ＳｉのＩＰアドレスである。
【００３２】
図５は、アクセス成否情報のデータ構造を示す説明図である。アクセス成否情報５００は、リクエストパケット３００に対するレスポンスパケット４００の取得の成否を示す情報である。アクセス成否情報５００は、リクエスト単位で生成される。アクセス成否情報５００には、アクセス先情報５０１とアクセス成否フラグ５０２が記述されている。アクセス先情報５０１とは、アクセス先であるサーバＤｊを特定する情報であり、たとえば、ＩＰアドレスが記述される。
【００３３】
アクセス成否フラグ５０２は、アクセス先とのアクセスの成否を特定する情報であり、アクセス成否フラグ５０２の値が１のときはアクセス成立、すなわち、時間内にアクセス先（サーバＤｊ）からのレスポンスパケット４００が端末Ｓｉに受信されたことを示す。アクセス成否フラグ５０２の値が０のときはアクセス不成立、すなわち、時間内にアクセス先（サーバＤｊ）からのレスポンスパケット４００が端末Ｓｉに受信されなかったことを示す。
【００３４】
図６は、アクセス成否ＤＢの記憶内容を示す説明図である。アクセス成否ＤＢ６００は、アクセス先別のアクセス成功率が記憶されている。アクセス成功率は、アクセス先ごとに、アクセス成立回数を分子、アクセス総数を分母としたときの値である。アクセス成立回数およびアクセス総数は、図５に示したアクセス成否情報５００により更新される。具体的には、アクセス成否フラグ５０２の値が１である場合、そのアクセス先のアクセス成効率の分子および分母を１加算する。一方、アクセス成否フラグ５０２の値が０である場合、そのアクセス先のアクセス成効率の分母のみを１加算する。
【００３５】
たとえば、（Ａ）の状態から、アクセス先：サーバＤ１、アクセス成否フラグ：１のアクセス成否情報５００を受け付けると、（Ｂ）に示したように、（Ａ）に示したアクセス先：サーバＤ１のアクセス成効率“７／１０”から“８／１１”に更新される。（Ｂ）の状態から、アクセス先：サーバＤ２、アクセス成否フラグ：０のアクセス成否情報５００を受け付けると、（Ｃ）に示したように、（Ｂ）に示したアクセス先：サーバＤ２のアクセス成効率“４／２０”から“４／２１”に更新される。
【００３６】
図７は、アクセス可否ＤＢの記憶内容を示す説明図である。アクセス可否ＤＢ７００は、アクセス先（サーバＤｊ）ごとに、アクセス可否情報を記憶する。アクセス可否情報とは、そのアクセス先にアクセスが可能か否かを示す情報である。アクセス可否情報は、たとえば、「可」、「不可」、「判定不可」の３種類用意されている。アクセス可否情報は、図６に示したアクセス成否ＤＢ６００のアクセス成立回数（アクセス成効率の分子の値）やアクセス成効率により決定される。
【００３７】
（ネットワーク障害検出装置１１１の機能的構成）
図８は、ネットワーク障害検出装置１１１の機能的構成を示すブロック図である。図８において、ネットワーク障害検出装置１１１は、取得部８０１と、アクセス成否判定部８０２と、更新部８０３と、アクセス可否判定部８０４と、障害判定部８０５と、算出部８０６と、出力部８０７と、を備えている。これら各機能８０１〜８０７は、ネットワーク障害検出装置１１１の記憶部に記憶された当該機能８０１〜８０７に関するプログラムをＣＰＵに実行させることにより、または、入出力Ｉ／Ｆにより、当該機能を実現することができる。
【００３８】
また、各機能８０１〜８０７からの出力データは上記記憶部に保持される。また、図８中矢印で示した接続先の機能は、接続元の機能からの出力データを記憶領域から読み込んで、当該機能に関するプログラムをＣＰＵに実行させるものとする。
【００３９】
取得部８０１は、各アクセス元からそれぞれのアクセス先へのリクエストパケット３００と当該リクエストパケット３００に対するレスポンスパケット４００とを取得する機能を有する。具体的には、たとえば、端末Ｓｉから送信されるリクエストパケット３００をキャプチャするとともに、サーバＤｊからのレスポンスパケット４００をキャプチャする。
【００４０】
アクセス成否判定部８０２は、取得部８０１による取得結果に基づいて、アクセス先へのアクセス成否を判定する機能を有する。具体的には、たとえば、あるリクエストパケット３００をキャプチャした場合、そのリクエストパケット３００の送信元アドレス３０１を宛先アドレス４０２とし、宛先アドレス３０２を送信元アドレス４０１とするレスポンスパケット４００が、所定時間以内にキャプチャされたか否かを判断する。
【００４１】
所定時間以内にキャプチャされた場合、アクセス成立と判定し、されなかった場合、アクセス不成立と判定する。アクセス成立と判定された場合、アクセス成否フラグ：１のアクセス成否情報５００を更新部８０３に出力する。一方、アクセス不成立と判定された場合、アクセス成否フラグ：０のアクセス成否情報５００を更新部８０３に出力する。
【００４２】
更新部８０３は、現在までの各アクセス先のアクセス総数およびアクセス成立回数を、アクセス成否判定部８０２によって判定されたアクセス成否に基づいて更新する機能を有する。具体的には、たとえば、アクセス成否判定部８０２から出力されるアクセス成否情報５００により、更新対象となるアクセス先のエントリを特定し、図７で説明したとおり、アクセス成否フラグ５０２の値に応じてアクセス成効率を更新する。
【００４３】
アクセス可否判定部８０４は、更新部８０３によって更新された場合、当該更新後における各アクセス先のアクセス総数およびアクセス成立回数に基づいて、アクセス先へのアクセス可否を判定する機能を有する。具体的には、たとえば、アクセス成効率のしきい値を設定しておき、アクセス先（サーバＤｊ）ごとにそのアクセス成効率がしきい値以上であれば、そのアクセス先には今後もアクセス可能と判定され、しきい値未満であれば、それ以降はアクセス不可と判定される。
【００４４】
たとえば、しきい値が６０％である場合、図６の（Ａ）の状態では、サーバＤ１のアクセス成効率は“７／１０”であるため、アクセス可となる。一方、サーバＤ２やサーバＤｎは、しきい値である６０％を下回るため、アクセス不可と判定される。なお、アクセス総数（アクセス成効率の分母）が所定数以下である場合、判定対象とするにはアクセス総数が少なすぎるため、判定対象外としてもよい。たとえば、この所定数を６とした場合、サーバＤｎは判定対象外とする。このアクセス判定の可否により、アクセス可否ＤＢ７００は更新される。
【００４５】
障害判定部８０５は、アクセス可否判定部８０４によって判定された判定結果に基づいて、各アクセス元とアクセス先とを接続させるネットワークに障害が発生したか否かを判定する機能を有する。具体的には、たとえば、端末ＳｉとサーバＤｊとを接続させる上流ネットワーク１０３のキャリアに障害が発生したか否かを判定する。より具体的には、アクセス可否判定部８０４によってアクセス不可と判定されたアクセス先の数が所定数以上である場合、上流ネットワーク１０３内のキャリアに障害が発生したと判定する。
【００４６】
障害判定には２つの手法がある。１つはアクセス不可となったアクセス先の数を計数する手法である。障害判定部８０５は、障害判定しきい値を持ち、アクセス不可となったアクセス先の数がこのしきい値以上となった場合には上流ネットワーク１０３での障害発生と判定する。複数のアクセス先での障害が同時に発生することは少ないためである。ここでしきい値は２以上の値を設定する。
【００４７】
なお、２だけでなく任意の値を設定可能とする。これは、可能性は低いが同時に複数のサーバ障害が発生した際に、上流ネットワーク１０３障害と誤判定すること（過敏に判定してしまうこと）を避けるためである。このときのしきい値の設定内容はネットワーク管理者の判断による。アクセス先の傾向などによりその障害発生率は異なるため、柔軟に設定できる余地を残す。
【００４８】
もう１つの判定手法は、アクセス全体におけるアクセス可のサーバＤｊの存在確率を用いて判定する方法である。この存在確率は、算出部８０６で算出される。算出部８０６は、アクセス先の総数とアクセス可と判定されたアクセス先の数とに基づいて、全アクセス先のうちアクセス可となるアクセス先の存在確率を算出する機能を有する。すなわち、存在確率は、アクセス可否ＤＢ７００を参照し、サーバＤｊの総数ｎ（アクセス可否判定部８０４で判定対象外とされたアクセス先は除く）を分母とし、アクセス可であるサーバＤｊの数を分子とした値である。
【００４９】
この存在確率がそのしきい値以下であれば上流ネットワーク１０３での障害発生と判定する。逆にしきい値を上回っている場合には特定のサーバにて障害が発生していることになる。また、ここですべてのアクセス先がアクセス可でありアクセス可否率が１００％であった場合には、上流ネットワーク１０３の障害も特定サーバ障害も発生していないことになる。アクセス可のサーバＤｊの数がある程度を超えるとサーバ障害が同時に複数箇所で発生している状況になることもあり得るため、上記一つめの判定手法では過敏に障害発生と判定してしまう可能性が出てくる。
【００５０】
一方、すべてのサーバＤｊがアクセス不可となったときに障害発生という判定ルールにしてしまうと、上流ネットワーク１０３の障害または上流ネットワーク１０３との接続部分での障害しか判定できないことになり、サイレント障害の特徴である部分的に障害が発生している状況に対応できない。そこでこの存在確率による判定を用いる。このときのしきい値として設定する値はネットワーク管理者の判断による。たとえば、複数のサーバＤｊで障害が発生することは考えられるが、全体の４０％以上で障害が発生することは考えにくい、という場合にはしきい値を４０％に設定する。
【００５１】
また、出力部８０７は、障害判定部８０５によって判定された判定結果を出力する機能を有する。具体的には、たとえば、ネットワーク管理装置１１２に出力する。出力される判定結果は、少なくとも上流ネットワーク１０３障害ありとする判定結果でよい。これにより、下流ネットワーク１１０をインターネット１００に接続させるキャリアがキャリア１０１からキャリア１０２に切り替わる。
【００５２】
（ネットワーク障害検出処理手順）
図９は、ネットワーク障害検出処理手順を示すフローチャートである。まず、取得部８０１により、リクエストパケット３００が取得されるまで待ち受ける（ステップＳ９０１：Ｎｏ）。取得された場合（ステップＳ９０１：Ｙｅｓ）、アクセス成否判定部８０２により、アクセス成否判定処理を実行する（ステップＳ９０２）。そして、更新部８０３により更新処理を実行し（ステップＳ９０３）、更新後のアクセス成否ＤＢ６００を参照することで、アクセス可否判定部８０４によりアクセス可否判定処理を実行する（ステップＳ９０４）。そして、障害判定部８０５により障害判定処理を実行し（ステップＳ９０５）、その判定結果を出力する。このあと、ステップＳ９０１に戻って、一連の処理（ステップＳ９０１〜ステップＳ９０５）を繰り返す。
【００５３】
図１０は、図９に示したアクセス成否判定処理の詳細な処理手順を示すフローチャートである。図１０において、ステップＳ９０１で取得されたリクエストパケット３００に対するレスポンスパケット４００が取得されたか否かを判断する（ステップＳ１００１）。取得されていない場合（ステップＳ１００１：Ｎｏ）、所定時間経過したか否かを判断する（ステップＳ１００２）。所定時間経過していない場合（ステップＳ１００２：Ｎｏ）、ステップＳ１００１に戻る。
【００５４】
一方、所定時間経過した場合（ステップＳ１００２：Ｙｅｓ）、アクセス成否情報５００（アクセス成否フラグ：０）を生成する（ステップＳ１００３）。そして、ステップＳ９０３に移行する。一方、ステップＳ１００１において、レスポンスパケット４００が取得された場合（ステップＳ１００１：Ｙｅｓ）、アクセス成否情報５００（アクセス成否フラグ：１）を生成する（ステップＳ１００４）。そして、ステップＳ９０３に移行する。これにより、所定時間以内にリクエストパケット３００とそのレスポンスパケット４００をキャプチャした場合に、そのアクセス先となるサーバＤｊへのアクセスが成立したこととなる。
【００５５】
図１１は、図９に示した更新処理の詳細な処理手順を示すフローチャートである。図１１において、アクセス成否情報５００が生成されるのを待ち受け（ステップＳ１１０１：Ｎｏ）、アクセス成否情報５００が生成された場合（ステップＳ１１０１：Ｙｅｓ）、そのアクセス先が新規であるか否かを判断する（ステップＳ１１０２）。具体的には、すでにアクセス成否ＤＢ６００のエントリとして登録されているアクセス先と一致するか否かを判断する。
【００５６】
新規（不一致）である場合（ステップＳ１１０２：Ｙｅｓ）、そのアクセス先を新規登録する（ステップＳ１１０３）。この場合、アクセス成否情報５００のアクセス成否フラグ５０２が１であれば、アクセス成効率は“１／１”となり、アクセス成否情報５００のアクセス成否フラグ５０２が０であれば、アクセス成効率は“０／１”となる。このあと、ステップＳ９０５に移行する。
【００５７】
一方、アクセス先が新規でない（一致）場合（ステップＳ１１０２：Ｎｏ）、アクセス先のアクセス成効率を更新する（ステップＳ１１０４）。この場合、アクセス成否情報５００のアクセス成否フラグ５０２が１であれば、アクセス成効率の分子および分母ともに１加算され、アクセス成否情報５００のアクセス成否フラグ５０２が０であれば、アクセス成効率の分母のみ１加算される。このあと、ステップＳ９０４に移行する。
【００５８】
図１２は、図９に示したアクセス可否判定処理の詳細な処理手順を示すフローチャートである。図１２において、アクセス成効率が更新されたアクセス総数（アクセス成効率の分母）が所定数以下であるか否かを判断する（ステップＳ１２０１）。所定数以下である場合（ステップＳ１２０１：Ｙｅｓ）、アクセス総数が少なすぎるため、ステップＳ９０５に移行する。
【００５９】
一方、アクセス総数が所定数以下でない場合（ステップＳ１２０１：Ｎｏ）、更新後のアクセス成効率がしきい値以上であるか否かを判断する（ステップＳ１２０２）。しきい値以上でない場合（ステップＳ１２０２：Ｎｏ）、ステップＳ９０５に移行する。一方、しきい値以上である場合（ステップＳ１２０２：Ｙｅｓ）、アクセス可否ＤＢ７００のアクセス可否情報を“不可”から“可”に更新し（ステップＳ１２０３）、ステップＳ９０５に移行する。
【００６０】
図１３は、図９に示した障害判定処理の詳細な処理手順を示すフローチャートである。図１３は、アクセス不可のアクセス先の数により上流ネットワーク１０３の障害判定をおこなう例である。まず、アクセス可否ＤＢ７００を参照して、アクセス不可であるアクセス先の数を計数する（ステップＳ１３０１）。つぎに、その計数値が所定数以上であるか否かを判断する（ステップＳ１３０２）。所定数以上でない場合（ステップＳ１３０２：Ｎｏ）、ステップＳ９０６に移行する。一方、所定数以上である場合（ステップＳ１３０２：Ｙｅｓ）、上流ネットワーク１０３の障害発生との判定結果をネットワーク管理装置１１２に出力する（ステップＳ１３０３）。
【００６１】
図１４は、図９に示した障害判定処理の詳細な処理手順を示すフローチャートである。図１４は、アクセス可の存在確率により上流ネットワーク１０３の障害判定をおこなう例である。まず、アクセス可否ＤＢ７００を参照して、算出部８０６により、アクセス可であるアクセス先の存在確率を算出する（ステップＳ１４０１）。
【００６２】
つぎに、その存在確率がしきい値以下であるか否かを判断する（ステップＳ１４０２）。しきい値以下でない場合（ステップＳ１４０２：Ｎｏ）、ステップＳ９０６に移行する。一方、しきい値以下である場合（ステップＳ１４０２：Ｙｅｓ）、上流ネットワーク１０３の障害発生との判定結果をネットワーク管理装置１１２に出力する（ステップＳ１４０３）。
【００６３】
このように、本実施の形態によれば、サイレント障害を自動検出することで、上流ネットワーク１０３障害とサーバ障害とを切り分けることができる。これにより、ある下流ネットワーク１１０において、上流ネットワーク１０３に障害が発生したときにそれを検知し、上流経路をキャリア１０１からバックアップ回線であるキャリア１０２に素早く切り替えるというニーズにこたえることができる。したがって、障害に応じた復旧対策を円滑におこなうことができる。
【００６４】
なお、上述した実施の形態では、アクセス成否ＤＢ６００のエントリにはアクセス先のアクセス成効率を記憶する構成としたが、アクセス成効率をサマリとして記憶するとともに、アクセス成否情報５００をアクセス先ごとに関連付けて保持しておくこととしてもよい。
【００６５】
図１５は、アクセス成否ＤＢ６００の他の例を示す説明図である。図１５において、アクセス先のエントリには、アクセス先ごとに生成されたアクセス成否情報５００が保持されている。アクセス成否情報５００にはタイムスタンプがあり、時系列順に書き込まれている。図１５に示した例では、手前側にあるアクセス成否情報５００ほど過去の情報であり、最も奥に位置するアクセス成否情報５００が最新の情報を意味している。
【００６６】
このアクセス成否情報５００は、所定時間（図１０のステップＳ１００２とは異なる。）が経過すると、古いアクセス成否情報５００から削除される。削除の手法としては、所定時間以前に書き込まれたアクセス成否情報５００を削除してもよく、最も古いアクセス成否情報５００を削除することとしてもよい。
【００６７】
図１６は、ネットワーク障害検出装置１１１の他の機能的構成を示すブロック図である。図１６において、図８に示した構成と同一構成には同一符号を付し、その説明を省略する。図１６において、検出部１６００は、所定時間の経過を検出する機能を有する。すなわち、タイマとして機能する。所定時間の経過が検出されると、更新部８０３は、その所定時間前の時点以前における各サーバＤｊのアクセス総数およびアクセス成立回数を消去する。
【００６８】
たとえば、図１５において、（Ａ）の状態から所定時間前の時点以前におけるアクセス成否情報５００を削除する。そして、残されたアクセス成否情報５００でアクセス成効率を計算すると、（Ｂ）の状態となる。なお、このアクセス成否情報５００の削除により、アクセス成否情報５００の保持数が０となった場合、そのアクセス先のエントリは削除され、アクセス先の総数が減少する。
【００６９】
図１７は、タイムアウト処理手順を示すフローチャートである。図１７において、検出部１６００により所定時間が経過するまで待ち受ける（ステップＳ１７０１：Ｎｏ）、所定時間が経過した場合（ステップＳ１７０１：Ｙｅｓ）、該当するアクセス成否情報５００を削除する（ステップＳ１７０２）。そして、ステップＳ１７０１に戻る。
【００７０】
図１８は、更新処理の他の詳細な処理手順を示すフローチャートである。図１８において、まず、アクセス成否情報５００が生成されていない場合（ステップＳ１８０１：Ｎｏ）、図１７に示したタイムアウト処理があったか否かを判断する（ステップＳ１８０２）。タイムアウト処理がない場合（ステップＳ１８０２：Ｎｏ）、ステップＳ１８０１に戻る。一方、タイムアウト処理があった場合（ステップＳ１８０２：Ｙｅｓ）、アクセス先のアクセス成効率を更新する（ステップＳ１８０３）。このあと、ステップＳ９０４に移行する。
【００７１】
一方、ステップＳ１８０１において、アクセス成否情報５００が生成された場合（ステップＳ１８０１：Ｙｅｓ）、そのアクセス先が新規であるか否かを判断する（ステップＳ１８０４）。具体的には、すでにアクセス成否ＤＢ６００のエントリとして登録されているアクセス先と一致するか否かを判断する。
【００７２】
新規（不一致）である場合（ステップＳ１８０４：Ｙｅｓ）、そのアクセス先を新規登録する（ステップＳ１８０５）。この場合、アクセス成否情報５００のアクセス成否フラグ５０２が１であれば、アクセス成効率は“１／１”となり、アクセス成否情報５００のアクセス成否フラグ５０２が０であれば、アクセス成効率は“０／１”となる。このあと、ステップＳ９０５に移行する。
【００７３】
一方、アクセス先が新規でない（一致）場合（ステップＳ１８０４：Ｎｏ）、アクセス先のアクセス成効率を更新する（ステップＳ１８０６）。この場合、アクセス成否情報５００のアクセス成否フラグ５０２が１であれば、アクセス成効率の分子および分母ともに１加算され、アクセス成否情報５００のアクセス成否フラグ５０２が０であれば、アクセス成効率の分母のみ１加算される。このあと、ステップＳ１９０４に移行する。
【００７４】
図１９は、アクセス可否判定処理の他の詳細な処理手順を示すフローチャートである。図１９において、ステップＳ１８０３においてアクセス成効率が更新されたアクセス総数（アクセス成効率の分母）が所定数以下であるか否かを判断する（ステップＳ１９０１）。所定数以下である場合（ステップＳ１９０１：Ｙｅｓ）、アクセス総数が少なすぎるため、ステップＳ９０５に移行する。
【００７５】
一方、所定数以下でない場合（ステップＳ１９０１：Ｎｏ）、更新後のアクセス成功率がしきい値以上であるか否かを判断する（ステップＳ１９０２）。しきい値以上でない場合（ステップＳ１９０２：Ｎｏ）、ステップＳ９０５に移行する。一方、しきい値以上である場合（ステップＳ１９０２：Ｙｅｓ）、アクセス可否ＤＢ７００のアクセス可否情報を“不可”から“可”に更新し（ステップＳ１９０３）、ステップＳ９０５に移行する。
【００７６】
また、ステップＳ１８０６においてアクセス成効率が更新された場合、アクセス成効率が更新されたアクセス総数（アクセス成効率の分母）が所定数以下であるか否かを判断する（ステップＳ１９０４）。所定数以下である場合（ステップＳ１９０４：Ｙｅｓ）、アクセス総数が少なすぎるため、ステップＳ９０５に移行する。
【００７７】
一方、アクセス総数が所定数以下でない場合（ステップＳ１９０４：Ｎｏ）、更新後のアクセス成効率がしきい値以上であるか否かを判断する（ステップＳ１９０５）。しきい値以上でない場合（ステップＳ１９０５：Ｎｏ）、ステップＳ９０５に移行する。一方、しきい値以上である場合（ステップＳ１９０５：Ｙｅｓ）、アクセス可否ＤＢ７００のアクセス可否情報を“不可”から“可”に更新する（ステップＳ１９０６）。そして、このときのアクセス成否情報５００を、アクセス成否ＤＢ６００におけるそのアクセス先のエントリに追加して（ステップＳ１９０７）、ステップＳ９０５に移行する。
【００７８】
このように、タイムアウト処理を利用することで、アクセス成否情報５００が蓄積され続けることで障害検出の精度低下を防ぐことができ、より実効性の高い障害検出をおこなうことができる。
【００７９】
以上説明したように、本実施の形態によれば、アクセス先となるサーバの障害と上流ネットワーク１０３の障害とを自動的に切り分けることにより、障害に応じた復旧対策を円滑におこなうことができるという効果を奏する。
【００８０】
なお、本実施の形態で説明したネットワーク障害検出方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。このプログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。またこのプログラムは、インターネット１００等のネットワークを介して配布することが可能な媒体であってもよい。
【００８１】
また、本実施の形態で説明したネットワーク障害検出装置１１１は、スタンダードセルやストラクチャードＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）などの特定用途向けＩＣ（以下、単に「ＡＳＩＣ」と称す。）やＦＰＧＡなどのＰＬＤ（Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｄｅｖｉｃｅ）によっても実現することができる。具体的には、たとえば、上述したネットワーク障害検出装置１１１の機能８０１〜８０７をＨＤＬ記述によって機能定義し、そのＨＤＬ記述を論理合成してＡＳＩＣやＰＬＤに与えることにより、ネットワーク障害検出装置１１１を製造することができる。
【産業上の利用可能性】
【００８２】
以上のように、ネットワーク障害検出プログラム、ネットワーク障害検出装置、およびネットワーク障害検出方法は、情報をパケットに格納して転送するパケットネットワークに有用である。
【図面の簡単な説明】
【００８３】
【図１】実施の形態にかかるネットワーク障害検出システムのシステム構成を示す説明図である。
【図２】実施の形態にかかるコンピュータのハードウェア構成を示す説明図である。
【図３】リクエストパケットのデータ構造を示す説明図である。
【図４】レスポンスパケットのデータ構造を示す説明図である。
【図５】アクセス成否情報のデータ構造を示す説明図である。
【図６】アクセス成否ＤＢの記憶内容を示す説明図である。
【図７】アクセス可否ＤＢの記憶内容を示す説明図である。
【図８】ネットワーク障害検出装置の機能的構成を示すブロック図である。
【図９】ネットワーク障害検出処理手順を示すフローチャートである。
【図１０】図９に示したアクセス成否判定処理の詳細な処理手順を示すフローチャートである。
【図１１】図９に示した更新処理の詳細な処理手順を示すフローチャートである。
【図１２】図９に示したアクセス可否判定処理の詳細な処理手順を示すフローチャートである。
【図１３】図９に示した障害判定処理の詳細な処理手順を示すフローチャートである。
【図１４】図９に示した障害判定処理の詳細な処理手順を示すフローチャートである。
【図１５】アクセス成否ＤＢの他の例を示す説明図である。
【図１６】ネットワーク障害検出装置の他の機能的構成を示すブロック図である。
【図１７】タイムアウト処理手順を示すフローチャートである。
【図１８】更新処理の他の詳細な処理手順を示すフローチャートである。
【図１９】アクセス可否判定処理の他の詳細な処理手順を示すフローチャートである。
【符号の説明】
【００８４】
１００ インターネット
１０１，１０２ キャリア
１０３ 上流ネットワーク
１１０ 下流ネットワーク
１１１ ネットワーク障害検出装置
１１２ ネットワーク管理装置
３００ リクエストパケット
４００ レスポンスパケット
５００ アクセス成否情報
５０２ アクセス成否フラグ
６００ アクセス成否ＤＢ
７００ アクセス可否ＤＢ
８０１ 取得部
８０２ アクセス成否判定部
８０３ 更新部
８０４ アクセス可否判定部
８０５ 障害判定部
８０６ 算出部
８０７ 出力部
１６００ 検出部
Ｄｊ サーバ
Ｓｉ 端末
【技術分野】
【０００１】
この発明は、各アクセス元とそれぞれのアクセス先とを接続させるネットワークの障害を検出するネットワーク障害検出プログラム、ネットワーク障害検出装置、およびネットワーク障害検出方法に関する。
【背景技術】
【０００２】
従来からネットワーク障害を検出するシステムが開示されている（たとえば、下記特許文献１を参照。）。この特許文献１では、汎用コンピュータと端末装置との間に物理的に２本の通信回線を設けたオンラインシステムに対し、回線障害時に自動的に回線の切り替えをおこなう技術である。
【０００３】
【特許文献１】特開平７−８４９１２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、上述した特許文献１では、オンラインシステムを構成する汎用コンピュータは１台に固定されているため、不特定多数のアクセス元（端末装置）から不特定多数のアクセス先に接続するネットワークの障害を検出することができないという問題があった。
【０００５】
このようなネットワークは、不特定多数のアクセス元を下流ネットワークとした場合に、上流ネットワークと呼ばれ、下流ネットワークの端末装置をＷｅｂサーバなどのアクセス先に接続させるキャリア（インターネットサービスプロバイダ）である。この上流ネットワークに障害が発生したことを検知する場合、大別すると、上流ネットワーク側の管理者（一個人だけでなく管理組織という意味も含む。以下同様）からの通知による方法と、自ネットワーク内で独自に調査する方法に分けられる。
【０００６】
上流ネットワークからは一般的に障害発生が通知されるものであるが、実際には形式的な通知となっているケースもある。また障害の内容によっては、ネットワークの管理者自身が障害の発生に気がつかない場合もある。このような障害はサイレント障害と呼ばれ、通知はおこなわれない。それらの結果として通知を受ける下流ネットワーク側では、通知はあまり期待できない状況がある。
【０００７】
したがって、上流ネットワークからの通知によらない自主的な調査による検知手段が重要であるが、それらには、外部サーバとの接続可否の確認（ハートビート方式）、ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）によるトラフィック流量の監視、キャプチャによるアクセス状況の取得などがある。いずれも常時状況を把握しておき、状況が通常時と変化したら障害と判断する。
【０００８】
しかしながら、上述したハートビート方式では、ハートビート先となるアクセス先がダウンしたにもかかわらず、そのアクセス先のＷｅｂサーバの障害と判断せず、上流ネットワーク障害であると誤検出してしまうという問題があった。
【０００９】
また、ＳＮＭＰによるトラフィック流量の監視やキャプチャによるアクセス状況の取得では、通信先が偏りを持っていた場合に、その特定サーバでの障害に起因するトラフィックの変化を上流ネットワーク障害であると誤検出してしまうという問題があった。
【００１０】
このように、上述した従来技術では、上流ネットワークからの通知がなければ、アクセス先となるサーバの障害と上流ネットワークの障害とを区別することができないという問題があった。
【００１１】
この発明は、上述した従来技術による問題点を解消するため、アクセス先となるサーバの障害と上流ネットワークの障害とを自動的に切り分けることにより、障害に応じた復旧対策を円滑におこなうことができるネットワーク障害検出プログラム、ネットワーク障害検出装置、およびネットワーク障害検出方法を提供することを目的とする。
【課題を解決するための手段】
【００１２】
上述した課題を解決し、目的を達成するため、このネットワーク障害検出プログラム、ネットワーク障害検出装置、およびネットワーク障害検出方法は、各アクセス元からそれぞれのアクセス先へのリクエストパケットと当該リクエストパケットに対するレスポンスパケットとを取得し、その取得結果に基づいて、前記アクセス先へのアクセス成否を判定し、現在までの前記各アクセス先のアクセス総数およびアクセス成立回数を、判定されたアクセス成否に基づいて更新し、更新された場合、当該更新後における前記各アクセス先のアクセス総数およびアクセス成立回数に基づいて、前記アクセス先へのアクセス可否を判定し、その判定結果に基づいて、前記各アクセス元と前記アクセス先とを接続させるネットワークに障害が発生したか否かを判定し、その判定結果を出力することを要件とする。
【００１３】
このネットワーク障害検出プログラム、ネットワーク障害検出装置、およびネットワーク障害検出方法によれば、各アクセス元とアクセス先とを接続させるネットワークの障害と、アクセス先の障害とを切り分けることができる。したがって、信頼性の高い障害検出結果を報知することができる。
【００１４】
また、前記アクセス不可と判定されたアクセス先の数が所定数以上である場合、前記ネットワークに障害が発生したと判定することとしてもよい。
【００１５】
このネットワーク障害検出プログラム、ネットワーク障害検出装置、およびネットワーク障害検出方法によれば、複数のアクセス先が同時に障害発生する可能性よりも、単一のネットワークに障害が発生する可能性が高いという性質を利用することで、ネットワークの障害とアクセス先の障害とを切り分けることができる。
【００１６】
また、前記アクセス先の総数と前記アクセス可と判定されたアクセス先の数とに基づいて、前記全アクセス先のうちアクセス可となるアクセス先の存在確率を算出し、その存在確率が所定確率以下である場合、前記ネットワークに障害が発生したと判定することとしてもよい。
【００１７】
このネットワーク障害検出プログラム、ネットワーク障害検出装置、およびネットワーク障害検出方法によれば、所定確率以下の場合、ネットワーク障害と判定し、所定確率より大きい場合、アクセス先に障害が発生していると判定する。なお、算出された存在確率が１００％の場合は、いずれの障害も発生していないことがわかる。
【００１８】
また、所定時間の経過を検出し、経過が検出された場合、前記所定時間前の時点以前における前記各アクセス先のアクセス総数およびアクセス成立回数を消去することにより、現在までの前記各アクセス先のアクセス総数およびアクセス成立回数を更新することとしてもよい。
【００１９】
このネットワーク障害検出プログラム、ネットワーク障害検出装置、およびネットワーク障害検出方法によれば、ネットワークの障害とアクセス先の障害との切り分けをリアルタイムで実現することができる。
【発明の効果】
【００２０】
このネットワーク障害検出プログラム、ネットワーク障害検出装置、およびネットワーク障害検出方法によれば、アクセス先となるサーバの障害と上流ネットワークの障害とを自動的に切り分けることにより、障害に応じた復旧対策を円滑におこなうことができるという効果を奏する。
【発明を実施するための最良の形態】
【００２１】
以下に添付図面を参照して、このネットワーク障害検出プログラム、ネットワーク障害検出装置、およびネットワーク障害検出方法の好適な実施の形態を詳細に説明する。まず、実施の形態の全体構成について説明する。なお、本実施の形態では、アクセス元を端末、アクセス先をサーバとして説明する。そして、端末をサーバに接続させる上流ネットワークの障害とサーバとの障害を切り分ける。
【００２２】
（システム構成）
図１は、実施の形態にかかるネットワーク障害検出システムのシステム構成を示す説明図である。図１において、下流ネットワーク１１０は、アクセス元となる多数の端末Ｓ１〜Ｓｎとネットワーク障害検出装置１１１とネットワーク管理装置１１２とから構成される。下流ネットワーク１１０としては、たとえば、企業網が挙げられる。各端末Ｓｉ（ｉ＝１〜ｎ）は、あらかじめ設定された上流ネットワーク１０３の特定のキャリア１０１により、インターネット１００に接続可能である。ネットワーク障害検出装置１１１は、端末ＳｉおよびサーバＤｊ（ｊ＝１〜ｍ）間のトラフィックを監視する。ネットワーク管理装置１１２は、ルータなど上流ネットワーク１０３とのパケットを中継する装置である。
【００２３】
上流ネットワーク１０３は、インターネットプロバイダなどのキャリア１０１，１０２からなる。本例では、下流ネットワーク１１０をインターネット１００に接続させるキャリアをキャリア１０１とする。ネットワーク障害検出装置１１１においてキャリア１０１の障害発生が検出されると、上流ネットワーク１０３との接続を変更するなどの対処をネットワーク管理装置１１２に指示する。これにより、下流ネットワーク１１０をインターネット１００に接続させるキャリアがキャリア１０１からキャリア１０２に切り替わる。また、インターネット上には、端末Ｓｉと通信するＷｅｂサーバなどの不特定多数のサーバＤ１〜Ｄｍが存在する。ｍは、端末Ｓｉのアクセス先としてあらたに指定されるとその都度追加されるため増加する値であり、固定数ではない。
【００２４】
（コンピュータのハードウェア構成）
つぎに、実施の形態にかかるコンピュータ（ネットワーク障害検出装置１１１、ネットワーク管理装置１１２、端末Ｓｉ、サーバＤｊ、キャリア１０１，１０２内のコンピュータ）のハードウェア構成について説明する。
【００２５】
図２は、実施の形態にかかるコンピュータのハードウェア構成を示す説明図である。図２において、ネットワーク障害検出装置１１１は、コンピュータ本体２１０と、入力装置２２０と、出力装置２３０と、から構成されており、不図示のルータやモデムを介して各種ネットワーク２４０に接続可能である。
【００２６】
コンピュータ本体２１０は、ＣＰＵ，メモリ，インターフェースを有する。ＣＰＵは、ネットワーク障害検出装置１１１の全体の制御を司る。メモリは、ＲＯＭ，ＲＡＭ，ＨＤ，光ディスク２１１，フラッシュメモリなどの記憶領域から構成される。記憶領域はＣＰＵのワークエリアとして使用される。
【００２７】
また、記憶領域には各種プログラムが格納されており、ＣＰＵからの命令に応じてロードされる。ＨＤおよび光ディスク２１１はディスクドライブによりデータのリード／ライトが制御される。また、光ディスク２１１およびフラッシュメモリはコンピュータ本体２１０に対し着脱自在である。インターフェースは、入力装置２２０からの入力、出力装置２３０への出力、ネットワーク２４０に対する送受信の制御をおこなう。
【００２８】
また、入力装置２２０としては、キーボード２２１、マウス２２２、スキャナ２２３などがある。キーボード２２１は、文字、数字、各種指示などの入力のためのキーを備え、データの入力をおこなう。また、タッチパネル式であってもよい。マウス２２２は、カーソルの移動や範囲選択、あるいはウィンドウの移動やサイズの変更などをおこなう。スキャナ２２３は、画像を光学的に読み取る。読み取られた画像は画像データとして取り込まれ、コンピュータ本体２１０内の記憶領域に格納される。なお、スキャナ２２３にＯＣＲ機能を持たせてもよい。
【００２９】
また、出力装置２３０としては、ディスプレイ２３１、スピーカ２３２、プリンタ２３３などがある。ディスプレイ２３１は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。スピーカ２３２は、効果音や読み上げ音などの音声を出力する。また、プリンタ２３３は、画像データや文書データを印刷する。
【００３０】
（データ構造およびデータベース）
つぎに、実施の形態にかかるネットワーク障害検出装置１１１において利用されるデータのデータ構造およびデータベースについて説明する。図３は、リクエストパケットのデータ構造を示す説明図である。リクエストパケット３００は、端末ＳｉからサーバＤｊに対して送信されるパケットである。リクエストパケット３００は、ヘッダとして送信元アドレス３０１および宛先アドレス３０２とリクエストデータ３０３とを有する。送信元アドレス３０１は、アクセス元である端末ＳｉのＩＰアドレスである。宛先アドレス３０２は、アクセス先であるサーバＤｊのＩＰアドレスである。
【００３１】
図４は、レスポンスパケットのデータ構造を示す説明図である。レスポンスパケット４００は、端末Ｓｉからのリクエストパケット３００を受信したサーバＤｊからその端末Ｓｉに対して送信されるパケットである。レスポンスパケット４００は、ヘッダとして送信元アドレス４０１および宛先アドレス４０２とレスポンスデータ４０３とを有する。送信元アドレス４０１は、アクセス先となったサーバＤｊのＩＰアドレスである。宛先アドレス４０２は、アクセス元である端末ＳｉのＩＰアドレスである。
【００３２】
図５は、アクセス成否情報のデータ構造を示す説明図である。アクセス成否情報５００は、リクエストパケット３００に対するレスポンスパケット４００の取得の成否を示す情報である。アクセス成否情報５００は、リクエスト単位で生成される。アクセス成否情報５００には、アクセス先情報５０１とアクセス成否フラグ５０２が記述されている。アクセス先情報５０１とは、アクセス先であるサーバＤｊを特定する情報であり、たとえば、ＩＰアドレスが記述される。
【００３３】
アクセス成否フラグ５０２は、アクセス先とのアクセスの成否を特定する情報であり、アクセス成否フラグ５０２の値が１のときはアクセス成立、すなわち、時間内にアクセス先（サーバＤｊ）からのレスポンスパケット４００が端末Ｓｉに受信されたことを示す。アクセス成否フラグ５０２の値が０のときはアクセス不成立、すなわち、時間内にアクセス先（サーバＤｊ）からのレスポンスパケット４００が端末Ｓｉに受信されなかったことを示す。
【００３４】
図６は、アクセス成否ＤＢの記憶内容を示す説明図である。アクセス成否ＤＢ６００は、アクセス先別のアクセス成功率が記憶されている。アクセス成功率は、アクセス先ごとに、アクセス成立回数を分子、アクセス総数を分母としたときの値である。アクセス成立回数およびアクセス総数は、図５に示したアクセス成否情報５００により更新される。具体的には、アクセス成否フラグ５０２の値が１である場合、そのアクセス先のアクセス成効率の分子および分母を１加算する。一方、アクセス成否フラグ５０２の値が０である場合、そのアクセス先のアクセス成効率の分母のみを１加算する。
【００３５】
たとえば、（Ａ）の状態から、アクセス先：サーバＤ１、アクセス成否フラグ：１のアクセス成否情報５００を受け付けると、（Ｂ）に示したように、（Ａ）に示したアクセス先：サーバＤ１のアクセス成効率“７／１０”から“８／１１”に更新される。（Ｂ）の状態から、アクセス先：サーバＤ２、アクセス成否フラグ：０のアクセス成否情報５００を受け付けると、（Ｃ）に示したように、（Ｂ）に示したアクセス先：サーバＤ２のアクセス成効率“４／２０”から“４／２１”に更新される。
【００３６】
図７は、アクセス可否ＤＢの記憶内容を示す説明図である。アクセス可否ＤＢ７００は、アクセス先（サーバＤｊ）ごとに、アクセス可否情報を記憶する。アクセス可否情報とは、そのアクセス先にアクセスが可能か否かを示す情報である。アクセス可否情報は、たとえば、「可」、「不可」、「判定不可」の３種類用意されている。アクセス可否情報は、図６に示したアクセス成否ＤＢ６００のアクセス成立回数（アクセス成効率の分子の値）やアクセス成効率により決定される。
【００３７】
（ネットワーク障害検出装置１１１の機能的構成）
図８は、ネットワーク障害検出装置１１１の機能的構成を示すブロック図である。図８において、ネットワーク障害検出装置１１１は、取得部８０１と、アクセス成否判定部８０２と、更新部８０３と、アクセス可否判定部８０４と、障害判定部８０５と、算出部８０６と、出力部８０７と、を備えている。これら各機能８０１〜８０７は、ネットワーク障害検出装置１１１の記憶部に記憶された当該機能８０１〜８０７に関するプログラムをＣＰＵに実行させることにより、または、入出力Ｉ／Ｆにより、当該機能を実現することができる。
【００３８】
また、各機能８０１〜８０７からの出力データは上記記憶部に保持される。また、図８中矢印で示した接続先の機能は、接続元の機能からの出力データを記憶領域から読み込んで、当該機能に関するプログラムをＣＰＵに実行させるものとする。
【００３９】
取得部８０１は、各アクセス元からそれぞれのアクセス先へのリクエストパケット３００と当該リクエストパケット３００に対するレスポンスパケット４００とを取得する機能を有する。具体的には、たとえば、端末Ｓｉから送信されるリクエストパケット３００をキャプチャするとともに、サーバＤｊからのレスポンスパケット４００をキャプチャする。
【００４０】
アクセス成否判定部８０２は、取得部８０１による取得結果に基づいて、アクセス先へのアクセス成否を判定する機能を有する。具体的には、たとえば、あるリクエストパケット３００をキャプチャした場合、そのリクエストパケット３００の送信元アドレス３０１を宛先アドレス４０２とし、宛先アドレス３０２を送信元アドレス４０１とするレスポンスパケット４００が、所定時間以内にキャプチャされたか否かを判断する。
【００４１】
所定時間以内にキャプチャされた場合、アクセス成立と判定し、されなかった場合、アクセス不成立と判定する。アクセス成立と判定された場合、アクセス成否フラグ：１のアクセス成否情報５００を更新部８０３に出力する。一方、アクセス不成立と判定された場合、アクセス成否フラグ：０のアクセス成否情報５００を更新部８０３に出力する。
【００４２】
更新部８０３は、現在までの各アクセス先のアクセス総数およびアクセス成立回数を、アクセス成否判定部８０２によって判定されたアクセス成否に基づいて更新する機能を有する。具体的には、たとえば、アクセス成否判定部８０２から出力されるアクセス成否情報５００により、更新対象となるアクセス先のエントリを特定し、図７で説明したとおり、アクセス成否フラグ５０２の値に応じてアクセス成効率を更新する。
【００４３】
アクセス可否判定部８０４は、更新部８０３によって更新された場合、当該更新後における各アクセス先のアクセス総数およびアクセス成立回数に基づいて、アクセス先へのアクセス可否を判定する機能を有する。具体的には、たとえば、アクセス成効率のしきい値を設定しておき、アクセス先（サーバＤｊ）ごとにそのアクセス成効率がしきい値以上であれば、そのアクセス先には今後もアクセス可能と判定され、しきい値未満であれば、それ以降はアクセス不可と判定される。
【００４４】
たとえば、しきい値が６０％である場合、図６の（Ａ）の状態では、サーバＤ１のアクセス成効率は“７／１０”であるため、アクセス可となる。一方、サーバＤ２やサーバＤｎは、しきい値である６０％を下回るため、アクセス不可と判定される。なお、アクセス総数（アクセス成効率の分母）が所定数以下である場合、判定対象とするにはアクセス総数が少なすぎるため、判定対象外としてもよい。たとえば、この所定数を６とした場合、サーバＤｎは判定対象外とする。このアクセス判定の可否により、アクセス可否ＤＢ７００は更新される。
【００４５】
障害判定部８０５は、アクセス可否判定部８０４によって判定された判定結果に基づいて、各アクセス元とアクセス先とを接続させるネットワークに障害が発生したか否かを判定する機能を有する。具体的には、たとえば、端末ＳｉとサーバＤｊとを接続させる上流ネットワーク１０３のキャリアに障害が発生したか否かを判定する。より具体的には、アクセス可否判定部８０４によってアクセス不可と判定されたアクセス先の数が所定数以上である場合、上流ネットワーク１０３内のキャリアに障害が発生したと判定する。
【００４６】
障害判定には２つの手法がある。１つはアクセス不可となったアクセス先の数を計数する手法である。障害判定部８０５は、障害判定しきい値を持ち、アクセス不可となったアクセス先の数がこのしきい値以上となった場合には上流ネットワーク１０３での障害発生と判定する。複数のアクセス先での障害が同時に発生することは少ないためである。ここでしきい値は２以上の値を設定する。
【００４７】
なお、２だけでなく任意の値を設定可能とする。これは、可能性は低いが同時に複数のサーバ障害が発生した際に、上流ネットワーク１０３障害と誤判定すること（過敏に判定してしまうこと）を避けるためである。このときのしきい値の設定内容はネットワーク管理者の判断による。アクセス先の傾向などによりその障害発生率は異なるため、柔軟に設定できる余地を残す。
【００４８】
もう１つの判定手法は、アクセス全体におけるアクセス可のサーバＤｊの存在確率を用いて判定する方法である。この存在確率は、算出部８０６で算出される。算出部８０６は、アクセス先の総数とアクセス可と判定されたアクセス先の数とに基づいて、全アクセス先のうちアクセス可となるアクセス先の存在確率を算出する機能を有する。すなわち、存在確率は、アクセス可否ＤＢ７００を参照し、サーバＤｊの総数ｎ（アクセス可否判定部８０４で判定対象外とされたアクセス先は除く）を分母とし、アクセス可であるサーバＤｊの数を分子とした値である。
【００４９】
この存在確率がそのしきい値以下であれば上流ネットワーク１０３での障害発生と判定する。逆にしきい値を上回っている場合には特定のサーバにて障害が発生していることになる。また、ここですべてのアクセス先がアクセス可でありアクセス可否率が１００％であった場合には、上流ネットワーク１０３の障害も特定サーバ障害も発生していないことになる。アクセス可のサーバＤｊの数がある程度を超えるとサーバ障害が同時に複数箇所で発生している状況になることもあり得るため、上記一つめの判定手法では過敏に障害発生と判定してしまう可能性が出てくる。
【００５０】
一方、すべてのサーバＤｊがアクセス不可となったときに障害発生という判定ルールにしてしまうと、上流ネットワーク１０３の障害または上流ネットワーク１０３との接続部分での障害しか判定できないことになり、サイレント障害の特徴である部分的に障害が発生している状況に対応できない。そこでこの存在確率による判定を用いる。このときのしきい値として設定する値はネットワーク管理者の判断による。たとえば、複数のサーバＤｊで障害が発生することは考えられるが、全体の４０％以上で障害が発生することは考えにくい、という場合にはしきい値を４０％に設定する。
【００５１】
また、出力部８０７は、障害判定部８０５によって判定された判定結果を出力する機能を有する。具体的には、たとえば、ネットワーク管理装置１１２に出力する。出力される判定結果は、少なくとも上流ネットワーク１０３障害ありとする判定結果でよい。これにより、下流ネットワーク１１０をインターネット１００に接続させるキャリアがキャリア１０１からキャリア１０２に切り替わる。
【００５２】
（ネットワーク障害検出処理手順）
図９は、ネットワーク障害検出処理手順を示すフローチャートである。まず、取得部８０１により、リクエストパケット３００が取得されるまで待ち受ける（ステップＳ９０１：Ｎｏ）。取得された場合（ステップＳ９０１：Ｙｅｓ）、アクセス成否判定部８０２により、アクセス成否判定処理を実行する（ステップＳ９０２）。そして、更新部８０３により更新処理を実行し（ステップＳ９０３）、更新後のアクセス成否ＤＢ６００を参照することで、アクセス可否判定部８０４によりアクセス可否判定処理を実行する（ステップＳ９０４）。そして、障害判定部８０５により障害判定処理を実行し（ステップＳ９０５）、その判定結果を出力する。このあと、ステップＳ９０１に戻って、一連の処理（ステップＳ９０１〜ステップＳ９０５）を繰り返す。
【００５３】
図１０は、図９に示したアクセス成否判定処理の詳細な処理手順を示すフローチャートである。図１０において、ステップＳ９０１で取得されたリクエストパケット３００に対するレスポンスパケット４００が取得されたか否かを判断する（ステップＳ１００１）。取得されていない場合（ステップＳ１００１：Ｎｏ）、所定時間経過したか否かを判断する（ステップＳ１００２）。所定時間経過していない場合（ステップＳ１００２：Ｎｏ）、ステップＳ１００１に戻る。
【００５４】
一方、所定時間経過した場合（ステップＳ１００２：Ｙｅｓ）、アクセス成否情報５００（アクセス成否フラグ：０）を生成する（ステップＳ１００３）。そして、ステップＳ９０３に移行する。一方、ステップＳ１００１において、レスポンスパケット４００が取得された場合（ステップＳ１００１：Ｙｅｓ）、アクセス成否情報５００（アクセス成否フラグ：１）を生成する（ステップＳ１００４）。そして、ステップＳ９０３に移行する。これにより、所定時間以内にリクエストパケット３００とそのレスポンスパケット４００をキャプチャした場合に、そのアクセス先となるサーバＤｊへのアクセスが成立したこととなる。
【００５５】
図１１は、図９に示した更新処理の詳細な処理手順を示すフローチャートである。図１１において、アクセス成否情報５００が生成されるのを待ち受け（ステップＳ１１０１：Ｎｏ）、アクセス成否情報５００が生成された場合（ステップＳ１１０１：Ｙｅｓ）、そのアクセス先が新規であるか否かを判断する（ステップＳ１１０２）。具体的には、すでにアクセス成否ＤＢ６００のエントリとして登録されているアクセス先と一致するか否かを判断する。
【００５６】
新規（不一致）である場合（ステップＳ１１０２：Ｙｅｓ）、そのアクセス先を新規登録する（ステップＳ１１０３）。この場合、アクセス成否情報５００のアクセス成否フラグ５０２が１であれば、アクセス成効率は“１／１”となり、アクセス成否情報５００のアクセス成否フラグ５０２が０であれば、アクセス成効率は“０／１”となる。このあと、ステップＳ９０５に移行する。
【００５７】
一方、アクセス先が新規でない（一致）場合（ステップＳ１１０２：Ｎｏ）、アクセス先のアクセス成効率を更新する（ステップＳ１１０４）。この場合、アクセス成否情報５００のアクセス成否フラグ５０２が１であれば、アクセス成効率の分子および分母ともに１加算され、アクセス成否情報５００のアクセス成否フラグ５０２が０であれば、アクセス成効率の分母のみ１加算される。このあと、ステップＳ９０４に移行する。
【００５８】
図１２は、図９に示したアクセス可否判定処理の詳細な処理手順を示すフローチャートである。図１２において、アクセス成効率が更新されたアクセス総数（アクセス成効率の分母）が所定数以下であるか否かを判断する（ステップＳ１２０１）。所定数以下である場合（ステップＳ１２０１：Ｙｅｓ）、アクセス総数が少なすぎるため、ステップＳ９０５に移行する。
【００５９】
一方、アクセス総数が所定数以下でない場合（ステップＳ１２０１：Ｎｏ）、更新後のアクセス成効率がしきい値以上であるか否かを判断する（ステップＳ１２０２）。しきい値以上でない場合（ステップＳ１２０２：Ｎｏ）、ステップＳ９０５に移行する。一方、しきい値以上である場合（ステップＳ１２０２：Ｙｅｓ）、アクセス可否ＤＢ７００のアクセス可否情報を“不可”から“可”に更新し（ステップＳ１２０３）、ステップＳ９０５に移行する。
【００６０】
図１３は、図９に示した障害判定処理の詳細な処理手順を示すフローチャートである。図１３は、アクセス不可のアクセス先の数により上流ネットワーク１０３の障害判定をおこなう例である。まず、アクセス可否ＤＢ７００を参照して、アクセス不可であるアクセス先の数を計数する（ステップＳ１３０１）。つぎに、その計数値が所定数以上であるか否かを判断する（ステップＳ１３０２）。所定数以上でない場合（ステップＳ１３０２：Ｎｏ）、ステップＳ９０６に移行する。一方、所定数以上である場合（ステップＳ１３０２：Ｙｅｓ）、上流ネットワーク１０３の障害発生との判定結果をネットワーク管理装置１１２に出力する（ステップＳ１３０３）。
【００６１】
図１４は、図９に示した障害判定処理の詳細な処理手順を示すフローチャートである。図１４は、アクセス可の存在確率により上流ネットワーク１０３の障害判定をおこなう例である。まず、アクセス可否ＤＢ７００を参照して、算出部８０６により、アクセス可であるアクセス先の存在確率を算出する（ステップＳ１４０１）。
【００６２】
つぎに、その存在確率がしきい値以下であるか否かを判断する（ステップＳ１４０２）。しきい値以下でない場合（ステップＳ１４０２：Ｎｏ）、ステップＳ９０６に移行する。一方、しきい値以下である場合（ステップＳ１４０２：Ｙｅｓ）、上流ネットワーク１０３の障害発生との判定結果をネットワーク管理装置１１２に出力する（ステップＳ１４０３）。
【００６３】
このように、本実施の形態によれば、サイレント障害を自動検出することで、上流ネットワーク１０３障害とサーバ障害とを切り分けることができる。これにより、ある下流ネットワーク１１０において、上流ネットワーク１０３に障害が発生したときにそれを検知し、上流経路をキャリア１０１からバックアップ回線であるキャリア１０２に素早く切り替えるというニーズにこたえることができる。したがって、障害に応じた復旧対策を円滑におこなうことができる。
【００６４】
なお、上述した実施の形態では、アクセス成否ＤＢ６００のエントリにはアクセス先のアクセス成効率を記憶する構成としたが、アクセス成効率をサマリとして記憶するとともに、アクセス成否情報５００をアクセス先ごとに関連付けて保持しておくこととしてもよい。
【００６５】
図１５は、アクセス成否ＤＢ６００の他の例を示す説明図である。図１５において、アクセス先のエントリには、アクセス先ごとに生成されたアクセス成否情報５００が保持されている。アクセス成否情報５００にはタイムスタンプがあり、時系列順に書き込まれている。図１５に示した例では、手前側にあるアクセス成否情報５００ほど過去の情報であり、最も奥に位置するアクセス成否情報５００が最新の情報を意味している。
【００６６】
このアクセス成否情報５００は、所定時間（図１０のステップＳ１００２とは異なる。）が経過すると、古いアクセス成否情報５００から削除される。削除の手法としては、所定時間以前に書き込まれたアクセス成否情報５００を削除してもよく、最も古いアクセス成否情報５００を削除することとしてもよい。
【００６７】
図１６は、ネットワーク障害検出装置１１１の他の機能的構成を示すブロック図である。図１６において、図８に示した構成と同一構成には同一符号を付し、その説明を省略する。図１６において、検出部１６００は、所定時間の経過を検出する機能を有する。すなわち、タイマとして機能する。所定時間の経過が検出されると、更新部８０３は、その所定時間前の時点以前における各サーバＤｊのアクセス総数およびアクセス成立回数を消去する。
【００６８】
たとえば、図１５において、（Ａ）の状態から所定時間前の時点以前におけるアクセス成否情報５００を削除する。そして、残されたアクセス成否情報５００でアクセス成効率を計算すると、（Ｂ）の状態となる。なお、このアクセス成否情報５００の削除により、アクセス成否情報５００の保持数が０となった場合、そのアクセス先のエントリは削除され、アクセス先の総数が減少する。
【００６９】
図１７は、タイムアウト処理手順を示すフローチャートである。図１７において、検出部１６００により所定時間が経過するまで待ち受ける（ステップＳ１７０１：Ｎｏ）、所定時間が経過した場合（ステップＳ１７０１：Ｙｅｓ）、該当するアクセス成否情報５００を削除する（ステップＳ１７０２）。そして、ステップＳ１７０１に戻る。
【００７０】
図１８は、更新処理の他の詳細な処理手順を示すフローチャートである。図１８において、まず、アクセス成否情報５００が生成されていない場合（ステップＳ１８０１：Ｎｏ）、図１７に示したタイムアウト処理があったか否かを判断する（ステップＳ１８０２）。タイムアウト処理がない場合（ステップＳ１８０２：Ｎｏ）、ステップＳ１８０１に戻る。一方、タイムアウト処理があった場合（ステップＳ１８０２：Ｙｅｓ）、アクセス先のアクセス成効率を更新する（ステップＳ１８０３）。このあと、ステップＳ９０４に移行する。
【００７１】
一方、ステップＳ１８０１において、アクセス成否情報５００が生成された場合（ステップＳ１８０１：Ｙｅｓ）、そのアクセス先が新規であるか否かを判断する（ステップＳ１８０４）。具体的には、すでにアクセス成否ＤＢ６００のエントリとして登録されているアクセス先と一致するか否かを判断する。
【００７２】
新規（不一致）である場合（ステップＳ１８０４：Ｙｅｓ）、そのアクセス先を新規登録する（ステップＳ１８０５）。この場合、アクセス成否情報５００のアクセス成否フラグ５０２が１であれば、アクセス成効率は“１／１”となり、アクセス成否情報５００のアクセス成否フラグ５０２が０であれば、アクセス成効率は“０／１”となる。このあと、ステップＳ９０５に移行する。
【００７３】
一方、アクセス先が新規でない（一致）場合（ステップＳ１８０４：Ｎｏ）、アクセス先のアクセス成効率を更新する（ステップＳ１８０６）。この場合、アクセス成否情報５００のアクセス成否フラグ５０２が１であれば、アクセス成効率の分子および分母ともに１加算され、アクセス成否情報５００のアクセス成否フラグ５０２が０であれば、アクセス成効率の分母のみ１加算される。このあと、ステップＳ１９０４に移行する。
【００７４】
図１９は、アクセス可否判定処理の他の詳細な処理手順を示すフローチャートである。図１９において、ステップＳ１８０３においてアクセス成効率が更新されたアクセス総数（アクセス成効率の分母）が所定数以下であるか否かを判断する（ステップＳ１９０１）。所定数以下である場合（ステップＳ１９０１：Ｙｅｓ）、アクセス総数が少なすぎるため、ステップＳ９０５に移行する。
【００７５】
一方、所定数以下でない場合（ステップＳ１９０１：Ｎｏ）、更新後のアクセス成功率がしきい値以上であるか否かを判断する（ステップＳ１９０２）。しきい値以上でない場合（ステップＳ１９０２：Ｎｏ）、ステップＳ９０５に移行する。一方、しきい値以上である場合（ステップＳ１９０２：Ｙｅｓ）、アクセス可否ＤＢ７００のアクセス可否情報を“不可”から“可”に更新し（ステップＳ１９０３）、ステップＳ９０５に移行する。
【００７６】
また、ステップＳ１８０６においてアクセス成効率が更新された場合、アクセス成効率が更新されたアクセス総数（アクセス成効率の分母）が所定数以下であるか否かを判断する（ステップＳ１９０４）。所定数以下である場合（ステップＳ１９０４：Ｙｅｓ）、アクセス総数が少なすぎるため、ステップＳ９０５に移行する。
【００７７】
一方、アクセス総数が所定数以下でない場合（ステップＳ１９０４：Ｎｏ）、更新後のアクセス成効率がしきい値以上であるか否かを判断する（ステップＳ１９０５）。しきい値以上でない場合（ステップＳ１９０５：Ｎｏ）、ステップＳ９０５に移行する。一方、しきい値以上である場合（ステップＳ１９０５：Ｙｅｓ）、アクセス可否ＤＢ７００のアクセス可否情報を“不可”から“可”に更新する（ステップＳ１９０６）。そして、このときのアクセス成否情報５００を、アクセス成否ＤＢ６００におけるそのアクセス先のエントリに追加して（ステップＳ１９０７）、ステップＳ９０５に移行する。
【００７８】
このように、タイムアウト処理を利用することで、アクセス成否情報５００が蓄積され続けることで障害検出の精度低下を防ぐことができ、より実効性の高い障害検出をおこなうことができる。
【００７９】
以上説明したように、本実施の形態によれば、アクセス先となるサーバの障害と上流ネットワーク１０３の障害とを自動的に切り分けることにより、障害に応じた復旧対策を円滑におこなうことができるという効果を奏する。
【００８０】
なお、本実施の形態で説明したネットワーク障害検出方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。このプログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。またこのプログラムは、インターネット１００等のネットワークを介して配布することが可能な媒体であってもよい。
【００８１】
また、本実施の形態で説明したネットワーク障害検出装置１１１は、スタンダードセルやストラクチャードＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）などの特定用途向けＩＣ（以下、単に「ＡＳＩＣ」と称す。）やＦＰＧＡなどのＰＬＤ（Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｄｅｖｉｃｅ）によっても実現することができる。具体的には、たとえば、上述したネットワーク障害検出装置１１１の機能８０１〜８０７をＨＤＬ記述によって機能定義し、そのＨＤＬ記述を論理合成してＡＳＩＣやＰＬＤに与えることにより、ネットワーク障害検出装置１１１を製造することができる。
【産業上の利用可能性】
【００８２】
以上のように、ネットワーク障害検出プログラム、ネットワーク障害検出装置、およびネットワーク障害検出方法は、情報をパケットに格納して転送するパケットネットワークに有用である。
【図面の簡単な説明】
【００８３】
【図１】実施の形態にかかるネットワーク障害検出システムのシステム構成を示す説明図である。
【図２】実施の形態にかかるコンピュータのハードウェア構成を示す説明図である。
【図３】リクエストパケットのデータ構造を示す説明図である。
【図４】レスポンスパケットのデータ構造を示す説明図である。
【図５】アクセス成否情報のデータ構造を示す説明図である。
【図６】アクセス成否ＤＢの記憶内容を示す説明図である。
【図７】アクセス可否ＤＢの記憶内容を示す説明図である。
【図８】ネットワーク障害検出装置の機能的構成を示すブロック図である。
【図９】ネットワーク障害検出処理手順を示すフローチャートである。
【図１０】図９に示したアクセス成否判定処理の詳細な処理手順を示すフローチャートである。
【図１１】図９に示した更新処理の詳細な処理手順を示すフローチャートである。
【図１２】図９に示したアクセス可否判定処理の詳細な処理手順を示すフローチャートである。
【図１３】図９に示した障害判定処理の詳細な処理手順を示すフローチャートである。
【図１４】図９に示した障害判定処理の詳細な処理手順を示すフローチャートである。
【図１５】アクセス成否ＤＢの他の例を示す説明図である。
【図１６】ネットワーク障害検出装置の他の機能的構成を示すブロック図である。
【図１７】タイムアウト処理手順を示すフローチャートである。
【図１８】更新処理の他の詳細な処理手順を示すフローチャートである。
【図１９】アクセス可否判定処理の他の詳細な処理手順を示すフローチャートである。
【符号の説明】
【００８４】
１００ インターネット
１０１，１０２ キャリア
１０３ 上流ネットワーク
１１０ 下流ネットワーク
１１１ ネットワーク障害検出装置
１１２ ネットワーク管理装置
３００ リクエストパケット
４００ レスポンスパケット
５００ アクセス成否情報
５０２ アクセス成否フラグ
６００ アクセス成否ＤＢ
７００ アクセス可否ＤＢ
８０１ 取得部
８０２ アクセス成否判定部
８０３ 更新部
８０４ アクセス可否判定部
８０５ 障害判定部
８０６ 算出部
８０７ 出力部
１６００ 検出部
Ｄｊ サーバ
Ｓｉ 端末
【特許請求の範囲】
【請求項１】
コンピュータを、
各アクセス元からそれぞれのアクセス先へのリクエストパケットと当該リクエストパケットに対するレスポンスパケットとを取得する取得手段、
前記取得手段による取得結果に基づいて、前記アクセス先へのアクセス成否を判定するアクセス成否判定手段、
現在までの前記各アクセス先のアクセス総数およびアクセス成立回数を、前記アクセス成否判定手段によって判定されたアクセス成否に基づいて更新する更新手段、
前記更新手段によって更新された場合、当該更新後における前記各アクセス先のアクセス総数およびアクセス成立回数に基づいて、前記アクセス先へのアクセス可否を判定するアクセス可否判定手段、
前記アクセス可否判定手段によって判定された判定結果に基づいて、前記各アクセス元と前記アクセス先とを接続させるネットワークに障害が発生したか否かを判定する障害判定手段、
前記障害判定手段によって判定された判定結果を出力する出力手段、
として機能させることを特徴とするネットワーク障害検出プログラム。
【請求項２】
前記障害判定手段は、
前記アクセス可否判定手段によって前記アクセス不可と判定されたアクセス先の数が所定数以上である場合、前記ネットワークに障害が発生したと判定することを特徴とする請求項１に記載のネットワーク障害検出プログラム。
【請求項３】
前記コンピュータを、
前記アクセス先の総数と前記アクセス可と判定されたアクセス先の数とに基づいて、前記全アクセス先のうちアクセス可となるアクセス先の存在確率を算出する算出手段として機能させ、
前記障害判定手段は、
前記算出手段によって算出された存在確率が所定確率以下である場合、前記ネットワークに障害が発生したと判定することを特徴とする請求項１に記載のネットワーク障害検出プログラム。
【請求項４】
前記コンピュータを、
所定時間の経過を検出する検出手段として機能させ、
前記更新手段は、
前記検出手段によって検出された場合、前記所定時間前の時点以前における前記各アクセス先のアクセス総数およびアクセス成立回数を消去することにより、現在までの前記各アクセス先のアクセス総数およびアクセス成立回数を更新することを特徴とする請求項１〜３のいずれか一つに記載のネットワーク障害検出プログラム。
【請求項５】
各アクセス元からそれぞれのアクセス先へのリクエストパケットと当該リクエストパケットに対するレスポンスパケットとを取得する取得手段と、
前記取得手段による取得結果に基づいて、前記アクセス先へのアクセス成否を判定するアクセス成否判定手段と、
現在までの前記各アクセス先のアクセス総数およびアクセス成立回数を、前記アクセス成否判定手段によって判定されたアクセス成否に基づいて更新する更新手段と、
前記更新手段によって更新された場合、当該更新後における前記各アクセス先のアクセス総数およびアクセス成立回数に基づいて、前記アクセス先へのアクセス可否を判定するアクセス可否判定手段と、
前記アクセス可否判定手段によって判定された判定結果に基づいて、前記各アクセス元と前記アクセス先とを接続させるネットワークに障害が発生したか否かを判定する障害判定手段と、
前記障害判定手段によって判定された判定結果を出力する出力手段と、
を備えることを特徴とするネットワーク障害検出装置。
【請求項６】
各アクセス元からそれぞれのアクセス先へのリクエストパケットと当該リクエストパケットに対するレスポンスパケットとを取得する取得工程と、
前記取得工程による取得結果に基づいて、前記アクセス先へのアクセス成否を判定するアクセス成否判定工程と、
現在までの前記各アクセス先のアクセス総数およびアクセス成立回数を、前記アクセス成否判定工程によって判定されたアクセス成否に基づいて更新する更新工程と、
前記更新工程によって更新された場合、当該更新後における前記各アクセス先のアクセス総数およびアクセス成立回数に基づいて、前記アクセス先へのアクセス可否を判定するアクセス可否判定工程と、
前記アクセス可否判定工程によって判定された判定結果に基づいて、前記各アクセス元と前記アクセス先とを接続させるネットワークに障害が発生したか否かを判定する障害判定工程と、
前記障害判定工程によって判定された判定結果を出力する出力工程と、
を含んだことを特徴とするネットワーク障害検出方法。
【請求項１】
コンピュータを、
各アクセス元からそれぞれのアクセス先へのリクエストパケットと当該リクエストパケットに対するレスポンスパケットとを取得する取得手段、
前記取得手段による取得結果に基づいて、前記アクセス先へのアクセス成否を判定するアクセス成否判定手段、
現在までの前記各アクセス先のアクセス総数およびアクセス成立回数を、前記アクセス成否判定手段によって判定されたアクセス成否に基づいて更新する更新手段、
前記更新手段によって更新された場合、当該更新後における前記各アクセス先のアクセス総数およびアクセス成立回数に基づいて、前記アクセス先へのアクセス可否を判定するアクセス可否判定手段、
前記アクセス可否判定手段によって判定された判定結果に基づいて、前記各アクセス元と前記アクセス先とを接続させるネットワークに障害が発生したか否かを判定する障害判定手段、
前記障害判定手段によって判定された判定結果を出力する出力手段、
として機能させることを特徴とするネットワーク障害検出プログラム。
【請求項２】
前記障害判定手段は、
前記アクセス可否判定手段によって前記アクセス不可と判定されたアクセス先の数が所定数以上である場合、前記ネットワークに障害が発生したと判定することを特徴とする請求項１に記載のネットワーク障害検出プログラム。
【請求項３】
前記コンピュータを、
前記アクセス先の総数と前記アクセス可と判定されたアクセス先の数とに基づいて、前記全アクセス先のうちアクセス可となるアクセス先の存在確率を算出する算出手段として機能させ、
前記障害判定手段は、
前記算出手段によって算出された存在確率が所定確率以下である場合、前記ネットワークに障害が発生したと判定することを特徴とする請求項１に記載のネットワーク障害検出プログラム。
【請求項４】
前記コンピュータを、
所定時間の経過を検出する検出手段として機能させ、
前記更新手段は、
前記検出手段によって検出された場合、前記所定時間前の時点以前における前記各アクセス先のアクセス総数およびアクセス成立回数を消去することにより、現在までの前記各アクセス先のアクセス総数およびアクセス成立回数を更新することを特徴とする請求項１〜３のいずれか一つに記載のネットワーク障害検出プログラム。
【請求項５】
各アクセス元からそれぞれのアクセス先へのリクエストパケットと当該リクエストパケットに対するレスポンスパケットとを取得する取得手段と、
前記取得手段による取得結果に基づいて、前記アクセス先へのアクセス成否を判定するアクセス成否判定手段と、
現在までの前記各アクセス先のアクセス総数およびアクセス成立回数を、前記アクセス成否判定手段によって判定されたアクセス成否に基づいて更新する更新手段と、
前記更新手段によって更新された場合、当該更新後における前記各アクセス先のアクセス総数およびアクセス成立回数に基づいて、前記アクセス先へのアクセス可否を判定するアクセス可否判定手段と、
前記アクセス可否判定手段によって判定された判定結果に基づいて、前記各アクセス元と前記アクセス先とを接続させるネットワークに障害が発生したか否かを判定する障害判定手段と、
前記障害判定手段によって判定された判定結果を出力する出力手段と、
を備えることを特徴とするネットワーク障害検出装置。
【請求項６】
各アクセス元からそれぞれのアクセス先へのリクエストパケットと当該リクエストパケットに対するレスポンスパケットとを取得する取得工程と、
前記取得工程による取得結果に基づいて、前記アクセス先へのアクセス成否を判定するアクセス成否判定工程と、
現在までの前記各アクセス先のアクセス総数およびアクセス成立回数を、前記アクセス成否判定工程によって判定されたアクセス成否に基づいて更新する更新工程と、
前記更新工程によって更新された場合、当該更新後における前記各アクセス先のアクセス総数およびアクセス成立回数に基づいて、前記アクセス先へのアクセス可否を判定するアクセス可否判定工程と、
前記アクセス可否判定工程によって判定された判定結果に基づいて、前記各アクセス元と前記アクセス先とを接続させるネットワークに障害が発生したか否かを判定する障害判定工程と、
前記障害判定工程によって判定された判定結果を出力する出力工程と、
を含んだことを特徴とするネットワーク障害検出方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【公開番号】特開２００９−１７１００９（Ｐ２００９−１７１００９Ａ）
【公開日】平成２１年７月３０日（２００９．７．３０）
【国際特許分類】
【出願番号】特願２００８−４２００（Ｐ２００８−４２００）
【出願日】平成２０年１月１１日（２００８．１．１１）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成２１年７月３０日（２００９．７．３０）
【国際特許分類】
【出願日】平成２０年１月１１日（２００８．１．１１）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]