探索装置、探索方法および探索プログラム
【課題】システムにおいて発生した異常の起点の候補を効率的に探索すること。
【解決手段】探索装置１は、第１の管理範囲で発生した異常について起点候補を探索する際に、探索先が第２の管理範囲に及ぶ場合には探索装置２にクエリを送信して第２の管理範囲内での異常起点の探索を依頼する。探索装置２は、クエリを受信して第２の管理範囲内で異常の起点候補を探索し、異常の起点候補をダミーの構成要素に置き換えて応答する。このため、探索装置１は、第２の管理範囲における構成要素の接続関係を把握することなく異常の起点候補を探索できる。
【解決手段】探索装置１は、第１の管理範囲で発生した異常について起点候補を探索する際に、探索先が第２の管理範囲に及ぶ場合には探索装置２にクエリを送信して第２の管理範囲内での異常起点の探索を依頼する。探索装置２は、クエリを受信して第２の管理範囲内で異常の起点候補を探索し、異常の起点候補をダミーの構成要素に置き換えて応答する。このため、探索装置１は、第２の管理範囲における構成要素の接続関係を把握することなく異常の起点候補を探索できる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、システムにおいて発生した異常の起点の候補を探索する探索装置、探索方法および探索プログラムに関する。
【背景技術】
【０００２】
互いに接続された複数の構成要素を含むネットワークシステムでは、構成要素に異常が発生すると、他の構成要素に異常が波及することがある。従って、ある構成要素についての異常が検出されたとしても、その異常の原因の根源（起点）は、その構成要素でなく別の構成要素であり得る。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開平２−２４４３３８号公報
【特許文献２】特開平６−３２４９０４号公報
【特許文献３】特開２００１−２２２４４２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、ネットワーク内の全ての構成要素の情報と、それらの因果関係の情報の全てが一元的に管理されていない場合に、異常の根源（起点）の探求を行うことは難しく、ネットワークの規模が大きくなるほどその問題は顕著となる。
【０００５】
１つの側面では、本発明は、システムに発生した異常の起点の候補を効率的に探索する探索装置、探索方法および探索プログラムを提供することを目的とする。
【０００６】
また、他の側面では、複数のシステムが存在する場合に、いずれのシステム側に異常の根源（起点）が存在するのかを評価可能とすることを目的とする。
【課題を解決するための手段】
【０００７】
第１の案では、探索装置、探索方法および探索プログラムは、ネットワークの構成要素のうち、第１の管理範囲に属する構成要素に発生した異常について、前記異常が発生した構成要素の接続関係を辿って前記異常の起点となった構成要素の候補を前記異常の起点候補として探索する。開示の装置、方法、プログラムは、辿った先の構成要素が第２の管理範囲に属する構成要素である場合に、前記第２の管理範囲における異常の起点候補を探索する装置に対して前記異常の起点候補の探索を依頼するクエリを発行し、探索結果とクエリに対する応答とに基づいて、異常の起点候補を評価する。
【０００８】
また、第２の案では、探索装置、探索方法および探索プログラムは、第１の管理範囲に属する構成要素における異常の起点候補を探索する装置から、第２の管理範囲に属する異常の起点候補の探索を依頼するクエリを受信した場合に、クエリに基づいて第２の管理範囲に属する構成要素の接続関係を辿って前記異常の起点候補を探索し、探索結果に基づいて前記異常の起点候補を評価する。開示の装置、方法、プログラムは、探索した異常の起点候補である構成要素をダミーの構成要素に置き換えて、ダミーの構成要素と評価結果とをクエリに対する応答として返す。
【発明の効果】
【０００９】
システムにおいて発生した異常の起点の候補を効率的に探索することができる。
【図面の簡単な説明】
【００１０】
【図１】図１は、実施例１にかかる探索装置を含むシステムの構成例である。
【図２】図２は、実施例２にかかる探索装置１３の構成図である。
【図３】図３は、探索装置間の接続についての説明図である。
【図４】図４は、複数のドメインにまたがるネットワークシステムの説明図である。
【図５】図５は、ドメインの仮想的な構成要素への置き換えについての説明図である。
【図６】図６は、異常の起点候補の評価に関する処理を説明するフローチャートである。
【図７】図７は、異常起点調査処理について説明するフローチャートである。
【図８】図８は、クエリを受信した探索装置の処理動作を説明するフローチャートである。
【図９】図９は、データの具体例の説明図である。
【図１０】図１０は、異常の起点候補の評価結果を表示する画面例についての説明図である。
【図１１】図１１は、異常の起点候補の探索の具体例についての説明図である。（その１）
【図１２】図１２は、異常の起点候補の探索の具体例についての説明図である。（その２）
【図１３】図１３は、異常の起点候補の探索の具体例についての説明図である。（その３）
【図１４】図１４は、異常の起点候補の探索の具体例についての説明図である。（その４）
【図１５】図１５は、コンピュータを探索装置として動作させる場合の説明図である。
【図１６】図１６は、３つの管理範囲を有するネットワークシステムについての説明図である。
【発明を実施するための形態】
【００１１】
以下に、本願の開示する探索装置、探索方法および探索プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例は開示の技術を限定するものではない。
【実施例１】
【００１２】
・実施例１の構成
図１は、実施例１にかかる探索装置を含むシステムの構成例である。図１に例示したシステムでは、構成要素Ｃ１１〜Ｃ１９がネットワークに含まれる。この例では、構成要素Ｃ１１〜Ｃ１９のうち、構成要素Ｃ１１〜Ｃ１５は第１の管理範囲１０に属し、構成要素Ｃ１６〜Ｃ１９は第２の管理範囲２０に属するものとする。なお、図示している構成要素以外の構成要素が更にネットワークに含まれてもよく、構成要素が１つの管理範囲に属すようにしたり、３以上の管理範囲に分けてもよい。
【００１３】
探索装置１は、第１の管理範囲１０に属する構成要素Ｃ１１〜Ｃ１５に発生した異常について、異常の起点となった構成要素の候補を異常の起点候補として探索し、評価する。
【００１４】
探索装置１は、探索部３、クエリ発行部４、評価部５を有する。探索部３は、第１の管理範囲１０に属する構成要素Ｃ１１〜Ｃ１５に発生した異常について、探索装置１が管理している構成要素間の接続情報に基づいて、異常が発生した構成要素の接続関係を辿ることで異常の起点候補を探索する。クエリ発行部４は、探索部３が辿った先の構成要素が第２の管理範囲２０に属する構成要素である場合に、探索装置２に対して異常の起点候補の探索を依頼するクエリを発行する。評価部５は、探索部３による探索結果とクエリ発行部４が発行したクエリに対する応答とに基づいて、異常の起点候補を評価する。
【００１５】
探索装置２は、探索部６、評価部７、クエリ処理部８を有する。クエリ処理部８は、探索装置１からクエリを受信する。探索部６は、装置２が管理している構成要素間接続情報と、受信したクエリとに基づいて第２の管理範囲２０に属する構成要素Ｃ１６〜１９の接続関係を辿って異常の起点候補を探索する。
【００１６】
そして、評価部７は、探索部６による探索結果に基づいて異常の起点候補を評価し、評価結果をクエリに対する応答として探索装置１に送信する。
【００１７】
・実施例１のまとめ
上述したように、探索装置１は、第１の管理範囲で発生した異常について起点候補を探索する際に、探索先が第２の管理範囲に及ぶ場合には探索装置２にクエリを送信して第２の管理範囲内での異常起点の探索を依頼する。
【００１８】
探索装置２は、クエリを受信して第２の管理範囲内で異常の起点候補を探索し、応答する。これによれば、探索装置１は、第２の管理範囲における構成要素及び構成要素間の接続関係についての詳細情報を管理していなくとも、異常の起点の探求を効率的に行うことができる。
【００１９】
なお、上述した実施例において、探索装置２のダミー処理部９が、探索部６が探索した異常の起点候補である構成要素をダミーの構成要素（第２の管理範囲における構成要素の固有の識別情報や、持続的な(persistent)な識別情報でない情報）に置き換え、ダミーの構成要素の情報と、そのダミーの構成要素についての評価結果をクエリ処理部８から応答として探索装置１に返すこともできる。なお、ダミーの構成要素の情報として、例えば、非持続的な(non-persistent)な、識別情報を用いることができる。ダミーの構成要素の情報は、非持続的な識別情報であるため、異常の起点を探索する処理を行った後に、更に別の異常の起点を探索する処理を行う際に、識別情報を変更してしまうこともできる。識別情報の変更の契機は、クエリにクエリ識別情報が含まれる場合、クエリ識別情報が変化したこと、所定時間経過したこと等とすることができる。
【００２０】
これによれば、探索装置１は、第２の管理範囲における構成要素、構成要素間の接続関係を把握しなくとも異常の起点候補を探索できる。言い換えれば、第２の管理範囲における構成要素、構成要素間の接続関係を第１の装置である探索装置１に対して秘匿しつつ探索装置１に異常の起点候補を探索させることができる。なお、探索装置１は、第１の管理範囲のエッジ部分の構成要素Ｃ１４に対応させて関連性識別子ｒ０１、構成要素Ｃ１５に対応させて関連性識別子ｒ０２を記憶しておき（ＣＭＤＢに登録することで記憶してもよい）、第２の装置である探索装置２は、ｒ０１に対応させて第２の管理範囲のエッジ部分の構成要素Ｃ１６、Ｃ１７を対応させて記憶し、また、ｒ０２に対応させて第２の管理範囲のエッジ部分の構成要素Ｃ１６を対応させて記憶しておくことで、探求先が第１の管理範囲内の構成要素Ｃ１４から第２の管理範囲側に及ぶ場合、クエリに識別情報ｒ０１を含めることで、Ｃ１５とＣ１６の間、Ｃ１５とＣ１７との間に接続関係があることを第１の装置及び第２の装置の双方ともが認識していなくとも、探求すべきパスを特定することができる。すなわち、クエリにｒ０１が含まれる場合、探索装置２は、構成要素Ｃ１６、Ｃ１７を経由する経路を辿って、異常の起点候補の探索を行うことができる。
【実施例２】
【００２１】
・実施例２の構成
図２は、実施例２にかかる探索装置１３の構成図である。図２に示した探索装置１３は、ユーザインタフェース３１、関連探索部３２、境界判定部３３、クエリ発行部３４、クエリ処理部３５、仮想構成管理部３６、評価部３７を有する。また、探索装置１３は、ＣＭＤＢ（Configuration Management Database）１１、障害ＤＢ（Database）１２およびＣＩ（Configuration Item）−ＶＣＩ（Virtual Configuration Item）対応表１４を参照可能である。なお、これらの、ＤＢ、対応表は記憶装置に記憶される。更に、探索装置１３は、図３に示したように他の探索装置２３と接続されている。
【００２２】
図３は、探索装置間の接続についての説明図であり、図４は、複数のドメインにまたがるネットワークシステムの説明図である。図４に示したネットワークシステムは、ネットワークｎｗ１１に物理マシンであるサーバｐｍ１１，１２が接続している。サーバｐｍ１１は仮想マシンプログラムを実行することで、仮想マシンＶＭ１１，１２として動作する。アプリケーションＡｐｐ１１は仮想マシンＶＭ１１上で動作する。同様に、アプリケーションＡｐｐ１２は仮想マシンＶＭ２上で動作する。
【００２３】
また、サーバｐｍ１２は仮想マシンプログラムを実行することで、仮想マシンＶＭ１３〜１５として動作する。アプリケーションＡｐｐ１３は仮想マシンＶＭ１３上で動作する。そして、アプリケーションＡｐｐ１４は仮想マシンＶＭ１４上で動作し、アプリケーションＡｐｐ１５は仮想マシンＶＭ１５上で動作する。同様に、ネットワークｎｗ１２に接続されたサーバｐｍ１３は仮想マシンプログラムを実行することで、仮想マシンＶＭ１６として動作する。アプリケーションＡｐｐ１６は仮想マシンＶＭ１６上で動作する。
【００２４】
また、アプリケーションＡｐｐ１３はアプリケーションＡｐｐ１５を利用しており、アプリケーションＡｐｐ１４はアプリケーションＡｐｐ１６を利用している。さらにアプリケーションＡｐｐ１２は、アプリケーションＡｐｐ１４を利用してサービスＳｖ１１を提供する。
【００２５】
このネットワークシステムでは、ネットワークｎｗ１１，１２、サーバｐｍ１１〜１３、仮想マシンＶＭ１１〜１６、アプリケーションＡｐｐ１１〜１６、サービスＳｖ１１が構成要素（ＣＩ:Configuration Item）として用いられている。また、構成要素間の接続関係が関連（relation）の例として用いられている。関連は、構成要素間の利用関係の方向を情報として含む。具体的には、利用される側の構成要素をソース、利用する側の構成要素をターゲットとし、例えば、ソースからターゲットに向けた方向を定める。構成情報に、システムの構成要素と関連についての情報を含めることができる。
【００２６】
図４に示したネットワークシステムの構成は、物理マシンであるサーバｐｍ１１〜１３が仮想マシンプログラムを実行することで仮想マシンＶＭ１１〜１６として動作し、仮想マシン上でＡｐｐ１１〜１６が動作し、サービスＳｖ１１が提供されるクラウド環境である。
【００２７】
この例では、クラウド環境の利用者は、仮想マシンＶＭ１１〜１６、アプリケーションＡｐｐ１１〜１６及びサービスＳＶ１を構成要素として認識しておらず、ネットワークｎｗ１１，１２やサーバｐｍ１１〜１３などの物理的な構成要素について知らないものとする。また、クラウド環境の提供者もネットワークｎｗ１１，１２やサーバｐｍ１１〜１３などの物理的な構成要素について情報を開示していないものとする。
【００２８】
この図４に示したネットワークシステムで異常が発生した場合、異常の起点がネットワークｎｗ１１，１２やサーバｐｍ１１〜１３などの物理的な構成要素であるならば、提供者側が管理している(管理責任がある)ことになる。一方、異常の起点がアプリケーションＡｐｐ１１〜１６、サービスＳｖ１１などの構成要素であるならば、利用者側が管理している（管理責任がある）ことになる。
【００２９】
このように、クラウド環境の利用者側は、アプリケーションＡｐｐ１１〜１６、サービスＳｖ１１の管理について責任があり、それらの詳細な構成情報を持ち、クラウド環境の提供者側はネットワークｎｗ１１，１２やサーバｐｍ１１〜１３の管理に責任があり、それらの詳細な構成情報を持つ。ネットワークの構成要素について管理する範囲をドメインという。図４に示した例では、第１ドメインが利用者側の管理範囲であり、第２ドメインが提供者側の管理範囲である。なお、ドメインの定義は、この例に限らず、システムの利用形態に応じて様々な変更が可能である。
【００３０】
第２ドメイン側の構成情報は第１ドメイン側に秘匿され、第１ドメイン側の構成情報は第２ドメイン側に秘匿されるようにしてもよい。そして、図３に示したように、第１ドメイン側システムに探索装置１３、第２ドメイン側システムに探索装置２３をそれぞれ設け、ドメインごとに異常の起点候補の評価、探索を行う。
【００３１】
第１ドメイン側のシステムに設けた探索装置１３は、ＣＭＤＢ１１、障害ＤＢ１２、ＣＩ−ＶＣＩ対応表１４を格納する各記憶装置と接続されており、格納された各種データにアクセスすることができる。ＣＭＤＢ１１は第１ドメインの構成情報を保持するデータベースであり、障害ＤＢ１２は、第１ドメインに属する構成要素に発生した各種の異常に関する情報を障害情報として格納するデータベースである。ＣＩ−ＶＣＩ対応表１４は、第２ドメイン側から異常の起点候補の探索を求められた場合に第２ドメインに応答するダミーの構成要素と第１ドメインの実際の構成要素との対応関係を示す表である。第２ドメイン側からダミーの構成要素を指定した問い合わせがあった際に、ＣＩ−ＶＣＩの対応表１４を用いることで、そのダミーの構成要素に対応する実際の構成要素を特定することができるため、特定した実際の構成要素が異常状態を脱したかどうか調査し、その調査結果を第２ドメイン側に送信することもできる。好ましくは、ダミーの構成要素は、クエリの識別情報と対応づけてＣＩ−ＶＣＩの対応表に登録され、異なるクエリに対する応答の際に、同じ構成要素について、ダミー情報を用いることもできる。
【００３２】
第２ドメイン側のシステムに設けた探索装置２３は、ＣＭＤＢ２１、障害ＤＢ２２、ＣＩ−ＶＣＩ対応表２４を記憶する各記憶装置と接続されており、格納された各種データにアクセスすることができる。ＣＭＤＢ２１は第２ドメインの構成情報を保持するデータベースであり、障害ＤＢ２２は、第２ドメインに属する構成要素に発生した各種異常を障害情報として格納するデータベースである。ＣＩ−ＶＣＩ対応表２４は、第１ドメイン側から異常の起点候補の探索を求められた場合に第１ドメインに応答するダミーの構成要素と第２ドメインの実際の構成要素との対応関係を示す表である。第１ドメイン側からダミーの構成要素を指定した問い合わせがあった際に、ＣＩ−ＶＣＩの対応表２４を用いることで、そのダミーの構成要素に対応する実際の構成要素を特定することができるため、特定した実際の構成要素が異常状態を脱したかどうか調査し、その調査結果を第１ドメイン側に送信することもできる。好ましくは、ダミーの構成要素は、クエリの識別情報と対応づけてＣＩ−ＶＣＩの対応表に登録され、異なるクエリに対する応答の際に、同じ構成要素について、ダミー情報を用いることもできる。
【００３３】
また、探索装置１３と探索装置２３とはネットワークを介して接続され、互いにクエリの送信と応答を行うことができる。探索装置１３と探索装置２３とは同一の構成を有することもできる。そこで、ここでは同一の構成を有するものとして、図２に示した探索装置１３の構成について説明を行い、探索装置２３についての説明は省略する。
【００３４】
図２に示したユーザインタフェース３１は、探索装置１３のユーザから異常の起点候補の評価の開始を指示する入力を受け付け、異常の起点候補の評価結果を出力する入出力処理部である。
【００３５】
関連探索部３２は、ＣＭＤＢ１１および障害ＤＢ１２を参照し、異常の起点候補を探索する。具体的には、関連探索部３２は、障害ＤＢ１２から異常が発生した構成要素を選択する。そして、選択した構成要素についてＣＭＤＢ１１を参照し、構成要素を設定された関連を逆方向に辿る。言い換えれば、関連探索部３２は、選択した構成要素をターゲットとする関連をソース側に辿る。関連探索部３２は、関連を辿った経路上に存在する構成要素のうち、異常が発生している最も上流の構成要素を異常の起点候補とする。
【００３６】
境界判定部３３は、関連探索部３２が辿った関連が、第１ドメインと第２ドメインの境界をまたぐ関連であるかを判定する。具体的には、第２ドメインは、図５に示したように一つの仮想的な構成要素、ダミーＣＩ（Ｄｃ１１）としてＣＭＤＢ１１に登録されている。境界判定部３３は、関連探索部３２が辿った関連のソースがダミーＣＩ（Ｄｃ１１）である場合に、第１ドメインと第２ドメインの境界をまたぐ関連であると判定する。
【００３７】
クエリ発行部３４は、境界判定部３３による判定の結果、関連探索部３２が辿った関連が境界をまたぐ関連である場合に、探索装置２３に対してクエリを発行する。なお、その際、仮想マシンＶＭ１１を辿った先がＤｃ１１である場合、ＶＭ１１とＤｃ１１との関連を示す識別情報を含めることが望ましい。
【００３８】
クエリ処理部３５は、探索装置２３からクエリに対する応答を受信し、評価部３７に渡す。
【００３９】
評価部３７は、関連探索部３２による異常の起点候補の探索結果と、クエリ処理部３５が取得したクエリ応答の内容に基づいて異常の起点候補を評価する。具体的には、評価部３７は、異常の起点候補として挙げられた構成要素の評点を求めて集計する。
例えば、評点の求め方として、
構成要素の評点＝自分の異常数 ＋ 関連の下流の構成要素の評点 （式１）
を利用してもよい。すなわち、異常が発生している構成要素で最も上流にあるものを起点候補とし、起点候補とその評点を集めて評価結果としても良い。そして、評点の高い構成要素ほど異常の起点である可能性が高いと評価する。評価部３７は、ユーザインタフェース３１を介して評価結果を出力する。
【００４０】
また、クエリ処理部３５は、探索装置２３からクエリを受信した場合には、関連探索部３２に対して異常の起点候補の探索を要求する。クエリ処理部３５は、探索装置２３からのクエリに基づいて関連探索部３２が探索した異常の起点候補について、評価部３７から評価を取得する。クエリ処理部３５は、関連探索部３２が探索した異常の起点候補をダミーの構成要素に置き換えて、ダミーの構成要素と評価結果を探索装置２３からのクエリに対する応答として返す。
【００４１】
仮想構成管理部３６は、第１ドメインの実際の構成要素とダミーの構成要素との関係を管理する処理部である。例えば、仮想構成管理部３６は、探索装置２３から受信したクエリの識別情報と、置き換え対象となる第１ドメインの構成要素に基づいてＣＩ−ＶＣＩ対応表１４を参照する。
【００４２】
クエリの識別情報と、置き換え対象となる第１ドメインの構成要素との組み合わせに対応するダミーの構成要素が登録されていれば、仮想構成管理部３６は、対応するダミーの構成要素をクエリ処理部３５に通知する。また、クエリの識別情報と、置き換え対象となる第１ドメインの構成要素との組み合わせに対応するダミーの構成要素が登録されていなければ、仮想構成管理部３６は、ダミーの構成要素を新規に登録する。具体的には、仮想構成管理部３６は、クエリの識別情報と、置き換え対象となる第１ドメインの構成要素との組み合わせに新しくダミーの構成要素を対応させ、ＣＩ−ＶＣＩ対応表１４に登録するとともに、クエリ処理部３５に通知する。なお、クエリ識別情報ごとにダミーの構成要素を登録し、ダミーの構成要素が登録されているか否かは、クエリの識別情報に対応する対応表を参照して判断することもできる。これによれば、クエリ識別情報ごとに、異なる対応関係を適用した対応表を適用することができるため、クエリに対する応答の累積により、構成要素間の関連性が開示されていくことを回避することができる。
【００４３】
このように、探索装置１３は、探索装置２３からのクエリに対してはダミーの構成要素を返すことで第１ドメインの構成を仮想化する。このため、探索装置１３は、第１ドメインの実際の構成を秘匿して仮想的な構成で異常の起点候補を探索装置２３に通知することができる。
【００４４】
同様に、探索装置２３も探索装置１３に対して第２ドメインの実際の構成を秘匿し、仮想的な構成でクエリに対する応答を行う。
【００４５】
したがって、第１ドメインと第２ドメインの構成を互いに知らせることなく、発生した異常の起点がどちら側にあるか、すなわち第１ドメインと第２ドメインのどちらに責任があるかを調査することもできる。
【００４６】
・処理動作の説明
図６は、異常の起点候補の評価に関する処理を説明するフローチャートである。図６に示したように、まず、ネットワークの状態を監視する装置が自ドメインの異常を検知する（Ｓ１０１）。異常を検知する装置は、探索装置であってもよいし、他の監視装置であっても良い。異常を検知した装置は、検知結果を自ドメインの障害ＤＢに登録する。
【００４７】
つぎに、探索装置が自ドメインの障害ＤＢを参照し、異常起点調査処理（Ｓ１０２）を行って、結果を集計し（Ｓ１０３）、出力する（Ｓ１０４）。
【００４８】
なお、異常検知（Ｓ１０１）は、随時行うことが望ましい。また、異常起点調査処理（Ｓ１０２）は、ユーザが指定したタイミングで行なっても良いし、定期的に実行しても良い。また、異常の検知と連動して実行することとしても良い。
【００４９】
図７は、異常起点調査処理（Ｓ１０２）について説明するフローチャートである。以降の処理は、探索装置１３が実行する場合を例として説明する。異常起点調査処理を開始した探索装置１３の関連探索部３２は、障害ＤＢ１２を参照し、異常を示した構成要素（ＣＩ）を一つ選択する（Ｓ２０１）。このとき、関連探索部３２は、異常を発生した構成要素の種別によって選択の優先順位をつける。具体的には、種別がサービスの構成要素に異常が発生していれば優先的に選択し、次に種別がアプリケーションの構成要素を優先的に選択し、同様に、仮想マシン、物理マシン、スイッチ、ルータの順に選択する。このように、構成要素の種別に基づいて選択を行なう事で、ネットワークシステム上で下流側に位置する可能性の高い構成要素から順に選択を行なうことができる。
【００５０】
関連探索部３２は、選択した構成要素から関連を逆方向に辿る（Ｓ２０２）。すなわち、異常を示した構成要素が異常を示すこととなった原因となる構成要素を探索する。境界判定部３３は、辿った先の構成要素が自ドメイン内の構成要素であるかを判定する（Ｓ２０３）。辿った先の構成要素が自ドメイン内の構成要素で無い場合（Ｓ２０３，Ｎｏ）、クエリ発行部３４がクエリを発行し（Ｓ２０４）、発行したクエリに対する応答をクエリ処理部３５が受信する（Ｓ２０５）。
【００５１】
辿った先の構成要素が自ドメイン内の構成要素である場合（Ｓ２０３，Ｙｅｓ）、関連探索部３２は、さらに関連を辿るかを判定する（Ｓ２０６）。さらに関連を辿るかどうかは、一例として選択した構成要素から辿った関連の数で決めればよい。辿った関連の数をホップ数といい、辿るべき関連の数の最大値を最大ホップ数という。例えば、最大ホップ数を３と定めた場合、選択した構成要素から３つまで関連を辿る。選択した構成要素をターゲットとする複数の関連がある場合や、辿った先の構成要素をターゲットとする関連が複数ある場合、それぞれの経路を辿る。また、エラーの種類や構成要素の種類に応じて重み付けを行なって関連を辿っても良い。
【００５２】
さらに関連を辿る場合（Ｓ２０６，Ｙｅｓ）、関連探索部３２は、ステップＳ２０２に戻り、辿った先の構成要素からさらに関連を辿る。そして、関連を辿らない場合（Ｓ２０６，Ｎｏ）、関連探索部３２は、障害ＤＢ１２に登録された全ての異常について調査を行なったかを判定する（Ｓ２０７）。この時、関連探索部３２は、他の構成要素から関連を辿ることで到達した構成要素の異常は調査済みとすることができる。
【００５３】
調査を行なっていない異常が残っている場合（Ｓ２０７，Ｎｏ）、関連探索部３２は、ステップＳ２０１に戻り、異常を示した構成要素をひとつ選択する。そして、障害ＤＢ１２に登録された全ての異常について調査を行なった場合（Ｓ２０７，Ｙｅｓ）に、探索装置１３は、異常起点調査処理を終了する。
【００５４】
図８は、クエリを受信した探索装置の処理動作を説明するフローチャートである。図８では、探索装置１３が他の探索装置からクエリを受信した場合を例に説明する。クエリ処理部３５は、クエリを受信する（Ｓ３０１）と、受信したクエリに基づいて関連探索部３２に異常の起点候補の探索を要求する。関連探索部３２は、クエリに示された識別情報（図９の関連ｒ０１参照）と異常に基づいて異常起点調査を行なう（Ｓ３０２）。評価部３７は、関連探索部３２による探索結果を集計し、評価する（Ｓ３０３）。クエリ処理部３５は、関連探索部３２による探索の結果として得られた起点候補を仮想構成管理部３６に渡す。仮想構成管理部３６は、起点候補についてダミーの構成要素の識別情報である仮想ＩＤを取得し、クエリ処理部３５に返す（Ｓ３０４）。
【００５５】
クエリ処理部３５は、仮想構成管理部３６から得られた仮想ＩＤと評価部３７による評価結果とを対応付け、クエリ応答としてクエリの送信元の探索装置に送信し（Ｓ３０５）、処理を終了する。なお、異常起点調査（Ｓ３０２）の詳細は、図７に示した処理と同様である。
【００５６】
・各種データの例
図９は、データの具体例の説明図である。図９に示したクエリＤ１は、クエリＩＤ、異常内容、時刻範囲、関連の項目を有する。図９の例では、クエリＩＤは１００、異常内容は応答時間停止、時刻範囲は2009/12/01 12:00:00〜2009/12/01 18:00:00、関連識別情報はｒ０１である。なお、送信元のドメインは、関連識別情報（ｒ０１）に基づいて、送信元のドメインの対応する構成要素を特定でき、送信先のドメインは、関連（ｒ０１）に基づいて、送信先ドメインの対応する構成要素を特定することができる。
【００５７】
すなわち、関連の項目は、クエリの送信元のドメインと送信先のドメインをまたぐ関連であり、クエリを受信した異常起点調査は、この関連のソースとなる構成要素から異常の起点候補を探索する。このように、クエリには送信元のドメインの構成を示す必要はなく、ドメインをまたぐ関連と異常に関する情報を含めばよい。このため、クエリを送信することで送信元のドメインの構成を送信先のドメインに対して秘匿しつつ異常の起点候補を探索することができる。
【００５８】
クエリ応答Ｄ２は、ＶＣＩと評点の項目を有する。ＶＣＩは、ダミーの構成要素のＩＤを示す項目であり、評点はダミーの構成要素の評価結果である。
【００５９】
外部ＣＩ情報Ｄ３は、構成情報ＤＢに登録される他のドメインの構成情報の具体例である。ＣＩ名としてはクラウドノードとして登録され、位置は自ドメインに対して外部のドメインであることを示している。
【００６０】
ＣＩ−ＶＣＩ対応表Ｄ４は、ＣＩ−ＶＣＩ対応表の一例であり、クエリＩＤに対して実際の構成要素であるＣＩのＩＤと仮想の構成要素であるＶＣＩのＩＤとを対応づけて保持している。図９の例では、クエリＩＤ１００に対してＣＩであるＳＷ２とＶＣＩであるＶ００１とを対応づけて保持している。また、クエリＩＤ１００に対してＣＩであるＰＭ２とＶＣＩであるＶ００２とを対応づけて保持している。さらに、クエリＩＤ１０１に対しては、ＣＩであるＳＷ２とＶＣＩであるＶ００３とを対応づけて保持している。
【００６１】
ＣＩ−ＶＣＩ対応表は、ＩＤが同一のクエリに対しては、同一の対応関係を使用する。一方で、クエリのＩＤが異なる場合には、異なる対応関係を使用して、同一のＣＩ（図９の例ではＳＷ２）に対して異なるＶＣＩを対応させる。このため、クエリのＩＤごとに仮想の構成が一意に定まるので、仮想の構成で異常の起点候補を正確に評価するとともに、複数のクエリによって実際の構成の推定を難しくすることができる。
【００６２】
評点表Ｄ５は、評価部による評価結果の具体例であり、ＣＩのＩＤに評点を対応づけた構成を有する。評点表Ｄ５では、Ｖ００１の評点が９、Ｖ００２の評点が３、ＳＷ２の評点が１である。したがって、評点表Ｄ５では、評点が最も高いＶ００１が異常の起点であることが推定される。このＶ００１は、他のドメインからのクエリ応答として得られた仮想の構成要素であるので、Ｖ００１が異常の起点であるならば、自ドメイン側を起点とした異常の発生ではないことが推定される。
【００６３】
図１０は、異常の起点候補の評価結果を表示する画面例についての説明図である。図１０に示した画面例Ｄ６，７は、「異常の起点である可能性が高いＣＩは以下の通りです。」というメッセージとともに、ＣＩのＩＤと責任元の情報を表示している。一例として、評点が上位２つの構成要素を異常の起点である可能性が高い構成要素とすればよい。
【００６４】
画面例Ｄ６は、Ａｐｐ２とＡｐｐ１を異常の起点である可能性が高いＣＩとして表示し、Ａｐｐ２とＡｐｐ１がともに自ドメインの管理範囲内であることを示している。画面例Ｄ７は、Ｖ００１とＶ００２を異常の起点である可能性が高いＣＩとして表示し、Ｖ００１とＶ００２がともに自ドメインの管理範囲外であることを示している。
【００６５】
・異常の起点候補探索の具体例
図１１〜１４は、異常の起点候補の探索の例についての説明図である。図１１に示したネットワークシステムでは、システム４１とシステム４２とが接続されている。システム４１は、ルータＲＴ１、スイッチＳＷ１、物理マシンＰＭ１、アプリケーションＡｐｐ１、サービスＳＶＣ１を有する。システム４２は、ルータＲＴ２、スイッチＳＷ２、物理マシンＰＭ２，３、仮想マシンＶＭ１〜３、アプリケーションＡｐｐ２〜４を有する。
【００６６】
ルータＲＴ１とルータＲＴ２とが接続され、システム４１，４２との間の通信が可能な状態となっている。スイッチＳＷ１，２は、同一システム内の物理マシンとルータとを接続する。アプリケーションＡｐｐ１は、物理マシンＰＭ１上で動作する。
【００６７】
仮想マシンＶＭ１，２は、物理マシンＰＭ２上で動作する。同様に、仮想マシンＶＭ３は、物理マシンＰＭ３上で動作する。そして、アプリケーションＡｐｐ２〜４は、それぞれ物理マシンＰＭ１〜３上で動作する。
【００６８】
サービスＳＶＣ１は、アプリケーションＡｐｐ１〜４を利用して提供されるサービスである。
【００６９】
図１１に示したネットワークシステムでは、ルータＲＴ１、スイッチＳＷ１、物理マシンＰＭ１、アプリケーションＡｐｐ１〜４、仮想マシンＶＭ１〜３、サービスＳＶＣ１が第１の管理範囲１０に含まれる。また、ルータＲＴ２、スイッチＳＷ２、物理マシンＰＭ２〜３が第２の管理範囲２０に含まれる。第１の管理範囲１０の構成情報はＣＭＤＢ１１が保持し、第１の管理範囲１０内で発生した異常に関する情報は障害ＤＢ１２が保持する。同様に、第２の管理範囲２０の構成情報はＣＭＤＢ２１が保持し、第２の管理範囲２０内で発生した異常に関する情報は障害ＤＢ２２が保持する。管理範囲の態様は、これに限らず、更に多くの管理範囲を形成してもよい。その際、障害ＤＢは、複数の管理範囲のそれぞれに設けてよい。
【００７０】
図１２は、第１の管理範囲１０のアプリケーションＡｐｐ２でアプリケーションの応答時間が悪化するエラーＥ１が発生した場合の説明図である。
【００７１】
アプリケーションの応答時間悪化の原因としては、例えば、Ｊａｖａ（登録商標）アプリケーションにおいてオブジェクトの解放漏れがあるため、巨大ＧＣ(Garbage Collection）が時々発生し、アプリケーションの応答時間が数十秒になった場合などがある。
【００７２】
Ａｐｐ２にエラーＥ１が発生すると、アプリケーションＡｐｐ２に依存するアプリケーションＡｐｐ１やサービスＳＶＣ１の応答時間も悪化し、エラーＥ１が発生する。これらの応答時間の悪化は、運用管理ソフトウェアにより、第１の管理範囲１０の管理者が予め定めた応答時間閾値を超えることで、異常として検出される。応答時間閾値は、一例として３秒などである。
【００７３】
図１２に示した例では、第１の管理範囲１０に発生したサービスＳＶＣ１、アプリケーションＡｐｐ１，２のエラーＥ１が障害ＤＢ１２に登録される。この３つのエラーから探索装置１３が異常の起点候補を評価する場合について説明する。
【００７４】
探索装置１３は、まず、サービスＳＶＣ１、アプリケーションＡｐｐ１，２のうち、構成要素の種別に基づいてサービスＳＶＣ１を選択する。探索装置１３は、選択したサービスＳＶＣ１を探索の開始点として関連を辿りながら、辿った経路上に存在する構成要素のうち、異常が発生している構成要素について、例えば式１で示したような計算方法で評点を算出する。
【００７５】
探索の開始点であるサービスＳＶＣ１は、自分自身の異常数が１で、関連の下流に位置する構成要素は存在しないため、式１に従って評点を求めると１＋０＝１となる。サービスＳＶＣ１から辿ることの出来る構成要素は、アプリケーションＡｐｐ１〜４である。
【００７６】
アプリケーションＡｐｐ１は、自分自身の異常数が１で、サービスＳＶＣ１が下流の構成要素として存在するため、求めたＳＶＣ１の評点１を加算して（１＋１）、合計評点２を得る。アプリケーションＡｐｐ１から辿ることの出来る構成要素は、物理マシンＰＭ１とアプリケーションＡｐｐ２である。物理マシンＰＭ１から辿ることのできる経路上には、スイッチＳＷ１とルータＲＴ１が存在するが、物理マシンＰＭ１、スイッチＳＷ１、ルータＲＴ１には異常が発生していないため、評点は求めない。
【００７７】
アプリケーションＡｐｐ２は、自分自身の異常数が１で、サービスＳＶＣ１とアプリケーションＡｐｐ１が下流の構成要素として存在する。このため、アプリケーションＡｐｐ２の評点は、自身の異常数１に、サービスＳＶＣ１の評点１とアプリケーションＡｐｐ１の評点２を加算して（１＋１＋２）、合計評点４を得る。アプリケーションＡｐｐ２から辿ることの出来る構成要素は、仮想マシンＶＭ１である。
【００７８】
仮想マシンＶＭ１は、異常が発生していないので評点は求めない。仮想マシンＶＭ１からさらに関連を辿ると、第２の管理範囲２０に至る。ここで、第２の管理範囲２０は、図１３に示したように探索装置１３からは１つの構成要素、クラウドノードＶＣ１として認識されている。探索装置１３は、辿った先がクラウドノードＶＣ１であることから、第２の管理範囲２０の異常の起点候補を探索する探索装置２３に対してクエリＱ１１を発行する。このクエリＱ１１は、仮想マシンＶＭ１とクラウドノードＶＣ１との間に設定された関連の情報と、探索の開始点の異常の情報を含む。また、クエリＱ１１に含まれる関連までのホップ数や、最大ホップを含んでも良い。
【００７９】
探索装置２３は、クエリを受けて第２の管理範囲２０内での異常の起点候補の探索を行なう。具体的には、クエリＱ１１に指定された仮想マシンＶＭ１との関連を開始点として関連を辿って異常の起点候補を探索する。図１２に示した例では、仮想マシンＶＭ１と物理マシンＰＭ２との関連がクエリＱ１１によって指定されているので、物理マシンＰＭ２から関連を辿ることとなる。しかし、第２の管理範囲２０内では異常が発生していないため、探索装置２３は、クエリＱ１１に対して起点候補無しの旨の応答を行う。
【００８０】
アプリケーションＡｐｐ３〜４は、サービスＳＶＣ１から辿ることが出来るが、異常が発生していないため評点は求めない。アプリケーションＡｐｐ３から辿ることの出来る構成要素は、仮想マシンＶＭ２であり、仮想マシンＶＭ２からさらに関連を辿ると、第２の管理範囲２０に対応するクラウドノードＶＣ１に至る。同様に、アプリケーションＡｐｐ４から辿ることの出来る構成要素は、仮想マシンＶＭ３であり、仮想マシンＶＭ３からさらに関連を辿ると、クラウドノードＶＣ１に至る。
【００８１】
探索装置１３は、仮想マシンＶＭ２，３から関連を辿ってクラウドノードＶＣ１に到達した場合にも探索装置２３に対してクエリＱ１１，１２を発行する。このクエリＱ１１，１２は、仮想マシンＶＭ２，３とクラウドノードＶＣ１との間に設定された関連の情報と、探索の開始点の異常の情報を含む。探索装置２３は、クエリＱ１１，１２を受けて第２の管理範囲２０内での異常の起点候補の探索を行い、第２の管理範囲２０内では異常が発生していないため、起点候補無しの旨の応答を行う。
【００８２】
このように、図１２に示した例において、サービスＳＶＣ１を開始点として探索を行なうと、アプリケーションＡｐｐ２が最も上流で異常が発生している構成要素であるので、アプリケーションＡｐｐ２（評点４）が異常の起点候補となる。
【００８３】
また、サービスＳＶＣ１を開始点として探索を行なう過程で、他に異常が発生した構成要素であるアプリケーションＡｐｐ１，２の評価を行なったので、アプリケーションＡｐｐ１，２を開始点とする探索は不要となる。このため、図１２に示した例では、探索装置１３はアプリケーションＡｐｐ２（評点４）を異常の起点候補とする。
【００８４】
図１２に示した例では、異常の起点候補は１つとなったが、異常の起点候補が複数となった場合には、探索装置１３は複数の起点候補を評点とともに出力する。例えば、複数の異常が同時に発生した場合や、実際の起点が１つであっても探索で候補を絞りきれない場合には複数の起点候補が出力されることとなる。なお、評点の算出は、異常の起点としての確からしさを数値化する他の手法を用いてもよい。また、異常が発生していない構成要素についても異常の起点候補として評点を与える手法を用いても良い。
【００８５】
図１４は、第２の管理範囲２０のスイッチＳＷ２で輻輳に起因する応答時間悪化のエラーＥ１が発生した場合の説明図である。
【００８６】
スイッチＳＷ２のようなＬ２（Ｌａｙｅｒ２）スイッチが輻輳を起こすと、アプリケーションＡｐｐ２，３など上位のアプリケーションでＩＰパケットが一部廃棄される。下位の仮想マシンＶＭ１，２のＴＣＰ層は、暫く待って（例えば３秒後、更に破棄されたらその６秒後など）、ＩＰパケットの再送（エラーＥ２）を行う。これにより、アプリケーションＡｐｐ１，２の応答時間も３秒、６秒といった長さになる。そして、アプリケーションＡｐｐ２に依存するアプリケーションＡｐｐ１やサービスＳＶＣ１の応答時間も悪化する（エラーＥ１）。
【００８７】
これらの応答時間の悪化は、運用管理ソフトウェアにより、管理者が予め定めた応答時間閾値(一例として３秒など)を超えることで、異常として検出される。また、スイッチＳＷ２、仮想マシンＶＭ１，２では、運用管理ソフトウェアの計測するＴＣＰ再送回数やパケット廃棄率が上昇することにより、異常として検出される。
【００８８】
図１４に示した例では、第１の管理範囲１０に発生したサービスＳＶＣ１、アプリケーションＡｐｐ１〜３のエラーＥ１と仮想マシンＶＭ１，２のエラーＥ２が障害ＤＢ１２に登録される。また、第２の管理範囲２０に発生したスイッチＳＷ２のエラーＥ１が障害ＤＢ２２に登録される。これら７つのエラーから探索装置１３，２３が異常の起点候補を評価する場合について説明する。
【００８９】
探索装置１３は、まず、第１の管理範囲１０で異常が発生したサービスＳＶＣ１、アプリケーションＡｐｐ１〜３、仮想マシンＶＭ１〜２のうち、構成要素の種別に基づいてサービスＳＶＣ１を選択する。探索装置１３は、選択したサービスＳＶＣ１を探索の開始点として関連を辿りながら、辿った経路上に存在する構成要素のうち、異常が発生している構成要素について、例えば式１で示したような計算方法で評点を算出する。
【００９０】
図１２の例と同様に、サービスＳＶＣ１の評点は１、アプリケーションＡｐｐ１の評点は２、アプリケーションＡｐｐ２の評点は４となる。アプリケーションＡｐｐ１から辿ることの出来る構成要素のうち、物理マシンＰＭ１、スイッチＳＷ１、ルータＲＴ１には異常が発生していないため、評点は求めないことについても図１２の例と同様である。
【００９１】
図１４に示した例では、アプリケーションＡｐｐ２から辿ることの出来る仮想マシンＶＭ１は、自分自身の異常数１にアプリケーションＡｐｐ２の評点が４を加算して（１＋４）合計評点５を得る。
【００９２】
アプリケーションＡｐｐ３は、自分自身の異常数が１で、サービスＳＶＣ１が下流の構成要素として存在する。このため、アプリケーションＡｐｐ２の評点は、自身の異常数１に、サービスＳＶＣ１の評点１を加算して（１＋１）、合計評点２を得る。アプリケーションＡｐｐ３から辿ることの出来る構成要素は、仮想マシンＶＭ２である。
【００９３】
仮想マシンＶＭ２は、自分自身の異常数１にアプリケーションＡｐｐ２の評点４を加算して（１＋２）合計評点３を得る。
【００９４】
仮想マシンＶＭ１からさらに関連を辿ると、第２の管理範囲２０に至る。ここで、第２の管理範囲２０は、図１２に示したように探索装置１３からは１つの構成要素、クラウドノードＶＣ１として認識されている。探索装置１３は、辿った先がクラウドノードＶＣ１であることから、第２の管理範囲２０の異常の起点候補を探索する探索装置２３に対してクエリＱ２１を発行する。このクエリＱ２１は、仮想マシンＶＭ１とクラウドノードＶＣ１との間に設定された関連の情報と、探索の開始点の異常の情報を含む。また、クエリに含まれる関連までのホップ数や、最大ホップを含んでも良い。
【００９５】
同様に、仮想マシンＶＭ２からさらに関連を辿ると、第２の管理範囲２０に対応するクラウドノードＶＣ１に至る。探索装置１３は、仮想マシンＶＭ２から関連を辿ってクラウドノードＶＣ１に到達した場合に探索装置２３に対してクエリＱ２２を発行する。このクエリＱ２２は、仮想マシンＶＭ２とクラウドノードＶＣ１との間に設定された関連の情報と、探索の開始点の異常の情報を含む。
【００９６】
アプリケーションＡｐｐ４は、サービスＳＶＣ１から辿ることが出来るが、異常が発生していないため評点は求めない。アプリケーションＡｐｐ４から辿ることの出来る構成要素は、仮想マシンＶＭ３であり、仮想マシンＶＭ３からさらに関連を辿ると、クラウドノードＶＣ１に至る。探索装置１３は、仮想マシンＶＭ３から関連を辿ってクラウドノードＶＣ１に到達した場合に探索装置２３に対してクエリＱ２３を発行する。このクエリＱ２３は、仮想マシンＶＭ３とクラウドノードＶＣ１との間に設定された関連の情報と、探索の開始点の異常の情報を含む。
【００９７】
探索装置１３が発行するクエリＱ２１〜２３は、開始点が同じ異常探索処理の中で発行されるクエリとして、クエリの識別情報は、同じ識別情報（例えば、クエリＩＤ１００）を使用することができる。
【００９８】
探索装置２３は、クエリＱ２１〜２３を受けて第２の管理範囲２０内での異常の起点候補の探索を行なう。具体的には、クエリＱ２１〜２３に指定された仮想マシンＶＭ１〜ＶＭ３との関連をそれぞれ開始点として関連を辿って異常の起点候補を探索する。クエリＱ２１は、仮想マシンＶＭ１と物理マシンＰＭ２との関連を指定している。クエリＱ２２は、仮想マシンＶＭ２と物理マシンＰＭ２との関連を指定している。クエリＱ２３は、仮想マシンＶＭ３と物理マシンＰＭ３との関連を指定している。
【００９９】
好ましくは、第１の管理範囲側では、仮想マシンＶＭ１〜３が第２の管理範囲のどの構成要素と接続されているか管理しておらず、ＶＭ１〜３と第２の管理範囲の何らかの構成要素との接続関係の識別情報（例えばｒ０１〜０３）との関係をＣＭＤＢに記憶しておき、クエリＱ２１〜２３には、この識別情報ｒ０１〜０３を含める。第２の管理範囲側では、物理マシンＰＭ２〜３が第１の管理範囲のどの構成要素と接続されているか管理しておらず、物理マシンＰＭ２と第１の管理範囲の何らかの構成要素との接続関係の識別情報（例えばｒ０１〜０３）との関係をＣＭＤＢに記憶しているため、クエリに含まれる識別情報ｒ０１〜０３に基づいて、物理マシンＰＭ２〜３を特定して、異常の起点の探索を行うことができる。
【０１００】
探索装置２３がクエリＱ２１に基づいて探索を開始し、関連をたどると、物理マシンＰＭ２、スイッチＳＷ２、ルータＲＴ２に至る。探索装置２３は、スイッチＳＷ２についてエラーＥ２が障害ＤＢ２２に登録されていることから、仮想マシンＶＭ１を開始点に発行されたクエリＱ２１について評点１を付し、スイッチＳＷ２をダミーの構成要素ＶＣ００１に置き換えてクエリＱ２１に対して応答する。
【０１０１】
探索装置２３がクエリＱ２２に基づいて探索を開始し、関連をたどると、物理マシンＰＭ２、スイッチＳＷ２、ルータＲＴ２に至る。探索装置２３は、スイッチＳＷ２についてエラーＥ２が障害ＤＢ２２に登録されていることから、仮想マシンＶＭ２を開始点に発行されたクエリＱ２２について評点１を付し、スイッチＳＷ２をダミーの構成要素ＶＣ００１に置き換えてクエリＱ２２に対して応答する。
【０１０２】
探索装置２３がクエリＱ２３に基づいて探索を開始し、関連をたどると、物理マシンＰＭ３、スイッチＳＷ２、ルータＲＴ２に至る。探索装置２３は、スイッチＳＷ２についてエラーＥ２が障害ＤＢ２２に登録されていることから、仮想マシンＶＭ３を開始点に発行されたクエリＱ２３について評点１を付し、スイッチＳＷ２をダミーの構成要素ＶＣ００１に置き換えてクエリＱ２３に対して応答する。
【０１０３】
探索装置２３は、クエリＱ２１〜２３に対する応答から、仮想マシンＶＭ〜３の上流に構成要素ＶＣ００１が存在し、構成要素ＶＣ００１の第２の管理範囲内での評点が１であることを認識する。そこで、探索装置２３は、構成要素ＶＣ００１の第２の管理範囲内での評点１に、下流側の評点を加算して構成要素ＶＣ００１とする。
【０１０４】
従って、構成要素ＶＣ００１の第２の管理範囲内での評点１に、仮想マシンＶＭ１の評点５、仮想マシンＶＭ２の評点３、仮想マシンＶＭ３の下流に位置するサービスＳＶＣ１の評点１を加算し（１＋５＋３＋１）、構成要素ＶＣ００１の合計評点は１０となる。
【０１０５】
このように、図１４に示した例において、サービスＳＶＣ１を開始点として探索を行なうと、ダミー構成要素ＶＣ００１が最も上流で異常が発生している構成要素であるので、ダミー構成要素ＶＣ００１（評点１０）が異常の起点候補となる。
【０１０６】
また、サービスＳＶＣ１を開始点として探索を行なう過程で、他に異常が発生した構成要素であるアプリケーションＡｐｐ１〜３、仮想マシンＶＭ１〜２の評価を行なったので、アプリケーションＡｐｐ１〜３、仮想マシンＶＭ１〜２を開始点とする探索は不要となる。このため、図１４に示した例では、探索装置１３はダミー構成要素ＶＣ００１（評点１０）を異常の起点候補とする。
【０１０７】
この結果は、ダミー構成要素ＶＣ００１が異常の起点である可能性が高いこと、すなわち異常の責任が第２の管理範囲側にある可能性が高いことを示している。
【０１０８】
図１４に示した例では、異常の起点候補は１つとなったが、異常の起点候補が複数となった場合には、探索装置１３は複数の起点候補を評点とともに出力する。例えば、複数の異常が同時に発生した場合や、実際の起点が１つであっても探索で候補を絞りきれない場合には複数の起点候補が出力されることとなる。なお、評点の算出は、異常の起点としての確からしさを数値化する他の手法を用いてもよい。また、異常が発生していない構成要素についても異常の起点候補として評点を与える手法を用いても良い。
【０１０９】
・プログラムによる実施
図１５は、コンピュータを探索装置として動作させる場合の説明図である。図１５に示したコンピュータ５０は、バス５１にＣＰＵ（Central Processing Unit）５２、ＲＯＭ（Read Only Memory）５３、ＲＡＭ（Random Access Memory）５４、ＮＩＣ（Network Interface Card）５５、ＨＤＤ（Hard Disk Drive）５６を接続した構成を有する。
【０１１０】
ＲＯＭ５３は、関連探索プログラム６１、評価プログラム６２、仮想構成管理プログラム６３、クエリ処理プログラム６４、境界判定プログラム６５、クエリ発行プログラム６６を保持する。タンジブル(tangible)な記録媒体の例としてＲＯＭ５３を例に挙げた、ＨＤＤや、ＲＡＭ、ＣＤＲＯＭ等の他のタンジブルなコンピュータ読み取り可能な記録媒体に各種プログラムを格納しておき、コンピュータに読み取らせることとしてもよい。なお、タンジブルな記憶媒体を遠隔地に配置し、コンピュータが、そのタンジブルな記憶媒体にアクセスすることでプログラムを取得して利用してもよい、また、その際、取得したプログラムをそのコンピュータ自身のタンジブルな記録媒体に格納して用いてもよい。
【０１１１】
ＣＰＵ５２は、関連探索プログラム６１を読み出して実行することで、関連探索部３２と同様の動作を関連探索プロセス７１として実現する。また、ＣＰＵ５２は、評価プログラム６２を読み出して実行することで、評価部３７と同様の動作を評価プロセス７２として実現する。ＣＰＵ５２は、仮想構成管理プログラム６３を読み出して実行することで、仮想構成管理部３６と同様の動作を仮想構成管理プロセス７３として実現する。ＣＰＵ５２は、クエリ処理プログラム６４を読み出して実行することで、クエリ処理部３５と同様の動作をクエリ処理プロセス７４として実現する。ＣＰＵ５２は、境界判定プログラム６５を読み出して実行することで、境界判定部３３と同様の動作を境界判定プロセス７５として実現する。ＣＰＵ５２は、クエリ発行プログラム６６を読み出して実行することで、クエリ発行部３４と同様の動作をクエリ発行プロセス７６として実現する。
【０１１２】
このようにＲＯＭ５３に保持した各種プログラムは、探索プログラムの一部として機能し、コンピュータ５０は、ＲＯＭ５３から各種プログラムを読み出して実行することで探索方法を実行する探索装置として動作する。
【０１１３】
・３以上のドメインを有する構成
これまでの説明では第１の管理範囲と第２の管理範囲を有するネットワークシステムを例示して説明を行なったが、３以上の管理範囲を有するネットワークシステムにおいても開示の技術は適用可能である。
【０１１４】
図１６は、３つの管理範囲を有するネットワークシステムについての説明図である。図１６に示した構成では、第２の管理範囲に対応する第２ドメイン側システム２０ａは、第１の管理範囲に対応する第１ドメイン側システム１０ａと第３の管理範囲に対応する第３ドメイン側システム１０ｂに接続されている。
【０１１５】
第２ドメイン側システム２０ａは、探索装置２３ａ、ＣＭＤＢ２１、障害ＤＢ２２、ＣＩ−ＶＣＩ対応表２４ａ，２４ｂを有する。また、探索装置２３ａは、第１ドメイン側システム１０ａと第３ドメイン側システム１０ｂがそれぞれ有する探索装置と接続されている。
【０１１６】
ＣＭＤＢ２１は、第２のドメインにおける構成要素の接続情報を保持する。障害ＤＢ２２は、第２ドメイン内で発生した障害の情報を保持する。ＣＩ−ＶＣＩ対応表２４ａは、第１ドメイン側システム１０ａからのクエリに応答する際に使用するダミーの構成要素と実際の構成要素との対応関係を保持する。ＣＩ−ＶＣＩ対応表２４ｂは、第３ドメイン側システム１０ｂからのクエリに応答する際に使用するダミーの構成要素と実際の構成要素との対応関係を保持する。
【０１１７】
このように、ドメインごとにＣＩ−ＶＣＩ対応表を個別に管理すると、同じクエリＩＤであっても同じ構成要素に対して異なるＶＣＩを設定することも可能となり、第２のドメインの構成が露呈することを抑制することができる。
【０１１８】
なお、ＣＩ−ＶＣＩ対応表が単一であっても、ドメイン毎に使用を許容するクエリＩＤの候補を別個として、クエリ応答の重ね合わせによる構成情報の推測を回避することができる。クエリＩＤを各ドメインで共用する場合、異なるドメインからの同じクエリＩＤを付したクエリの送信により、共通する構成要素について、共通したダミーの構成要素情報が応答として送信されてしまう。すると、異なるドメイン間で応答を重ね合わせることで、第２のドメインの構成が露呈していくこととなるが、ドメイン毎に使用を許容するクエリＩＤの候補を別個とすると、そのような事態を回避することができる。
【０１１９】
・実施例２のまとめ
上述してきたように、本実施例２にかかる探索装置、探索方法および探索プログラムは、システムに発生した異常の起点の候補を評価することができる。
【０１２０】
また、本実施例２にかかる探索装置は、他の探索装置からのクエリに対してはダミーの構成要素を返すことで自ドメインの構成を仮想化する。このため、探索装置は、自ドメインの実際の構成を秘匿して仮想的な構成で異常の起点候補を他の探索装置に通知することができる。したがって、各ドメインの構成を互いに知らせることなく異常の起点である構成要素を推定し、発生した異常の起点がどのドメインにあるかを調査することができる。
【０１２１】
なお、実施例に開示の装置、方法およびプログラムはあくまで一例であり、構成および動作を適宜変更して実施することができる。例えば、実施例２に開示した装置は、各処理部をネットワークシステム上に分散して配置し、探索システムとして実施することができる。
【符号の説明】
【０１２２】
１，２，１３，２３，２３ａ 探索装置
３，６ 探索部
４ クエリ発行部
５，７ 評価部
８ クエリ処理部
９ ダミー処理部
１０ａ 第１ドメイン側システム
１０ｂ 第３ドメイン側システム
１０，２０ 管理範囲
１１，２１ ＣＭＤＢ
１２，２２ 障害ＤＢ
１４，２４，２４ａ，２４ｂ ＣＩ−ＶＣＩ対応表
２０ａ 第２ドメイン側システム
３１ ユーザインタフェース
３２ 関連探索部
３３ 境界判定部
３４ クエリ発行部
３５ クエリ処理部
３６ 仮想構成管理部
３７ 評価部
４１，４２ システム
５０ コンピュータ
５１ バス
５２ ＣＰＵ
５３ ＲＯＭ
５４ ＲＡＭ
５５ ＮＩＣ
５６ ＨＤＤ
６１ 関連探索プログラム
６２ 評価プログラム
６３ 仮想構成管理プログラム
６４ クエリ処理プログラム
６５ 境界判定プログラム
６６ クエリ発行プログラム
７１ 関連探索プロセス
７２ 評価プロセス
７３ 仮想構成管理プロセス
７４ クエリ処理プロセス
７５ 境界判定プロセス
７６ クエリ発行プロセス
Ａｐｐ１〜４，１１〜１６ アプリケーション
Ｃ１１〜１６ 構成要素
ｎｗ１１，１２ ネットワーク
ＰＭ１〜３ 物理マシン
ｐｍ１１〜１３ サーバ
ＲＴ１，２ ルータ
Ｓｖ１１，ＳＶＣ１ サービス
ＳＷ１，２ スイッチ
ＶＣ１ クラウドノード
ＶＭ１〜３，ＶＭ１１〜１６ 仮想マシン
【技術分野】
【０００１】
本発明は、システムにおいて発生した異常の起点の候補を探索する探索装置、探索方法および探索プログラムに関する。
【背景技術】
【０００２】
互いに接続された複数の構成要素を含むネットワークシステムでは、構成要素に異常が発生すると、他の構成要素に異常が波及することがある。従って、ある構成要素についての異常が検出されたとしても、その異常の原因の根源（起点）は、その構成要素でなく別の構成要素であり得る。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開平２−２４４３３８号公報
【特許文献２】特開平６−３２４９０４号公報
【特許文献３】特開２００１−２２２４４２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、ネットワーク内の全ての構成要素の情報と、それらの因果関係の情報の全てが一元的に管理されていない場合に、異常の根源（起点）の探求を行うことは難しく、ネットワークの規模が大きくなるほどその問題は顕著となる。
【０００５】
１つの側面では、本発明は、システムに発生した異常の起点の候補を効率的に探索する探索装置、探索方法および探索プログラムを提供することを目的とする。
【０００６】
また、他の側面では、複数のシステムが存在する場合に、いずれのシステム側に異常の根源（起点）が存在するのかを評価可能とすることを目的とする。
【課題を解決するための手段】
【０００７】
第１の案では、探索装置、探索方法および探索プログラムは、ネットワークの構成要素のうち、第１の管理範囲に属する構成要素に発生した異常について、前記異常が発生した構成要素の接続関係を辿って前記異常の起点となった構成要素の候補を前記異常の起点候補として探索する。開示の装置、方法、プログラムは、辿った先の構成要素が第２の管理範囲に属する構成要素である場合に、前記第２の管理範囲における異常の起点候補を探索する装置に対して前記異常の起点候補の探索を依頼するクエリを発行し、探索結果とクエリに対する応答とに基づいて、異常の起点候補を評価する。
【０００８】
また、第２の案では、探索装置、探索方法および探索プログラムは、第１の管理範囲に属する構成要素における異常の起点候補を探索する装置から、第２の管理範囲に属する異常の起点候補の探索を依頼するクエリを受信した場合に、クエリに基づいて第２の管理範囲に属する構成要素の接続関係を辿って前記異常の起点候補を探索し、探索結果に基づいて前記異常の起点候補を評価する。開示の装置、方法、プログラムは、探索した異常の起点候補である構成要素をダミーの構成要素に置き換えて、ダミーの構成要素と評価結果とをクエリに対する応答として返す。
【発明の効果】
【０００９】
システムにおいて発生した異常の起点の候補を効率的に探索することができる。
【図面の簡単な説明】
【００１０】
【図１】図１は、実施例１にかかる探索装置を含むシステムの構成例である。
【図２】図２は、実施例２にかかる探索装置１３の構成図である。
【図３】図３は、探索装置間の接続についての説明図である。
【図４】図４は、複数のドメインにまたがるネットワークシステムの説明図である。
【図５】図５は、ドメインの仮想的な構成要素への置き換えについての説明図である。
【図６】図６は、異常の起点候補の評価に関する処理を説明するフローチャートである。
【図７】図７は、異常起点調査処理について説明するフローチャートである。
【図８】図８は、クエリを受信した探索装置の処理動作を説明するフローチャートである。
【図９】図９は、データの具体例の説明図である。
【図１０】図１０は、異常の起点候補の評価結果を表示する画面例についての説明図である。
【図１１】図１１は、異常の起点候補の探索の具体例についての説明図である。（その１）
【図１２】図１２は、異常の起点候補の探索の具体例についての説明図である。（その２）
【図１３】図１３は、異常の起点候補の探索の具体例についての説明図である。（その３）
【図１４】図１４は、異常の起点候補の探索の具体例についての説明図である。（その４）
【図１５】図１５は、コンピュータを探索装置として動作させる場合の説明図である。
【図１６】図１６は、３つの管理範囲を有するネットワークシステムについての説明図である。
【発明を実施するための形態】
【００１１】
以下に、本願の開示する探索装置、探索方法および探索プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例は開示の技術を限定するものではない。
【実施例１】
【００１２】
・実施例１の構成
図１は、実施例１にかかる探索装置を含むシステムの構成例である。図１に例示したシステムでは、構成要素Ｃ１１〜Ｃ１９がネットワークに含まれる。この例では、構成要素Ｃ１１〜Ｃ１９のうち、構成要素Ｃ１１〜Ｃ１５は第１の管理範囲１０に属し、構成要素Ｃ１６〜Ｃ１９は第２の管理範囲２０に属するものとする。なお、図示している構成要素以外の構成要素が更にネットワークに含まれてもよく、構成要素が１つの管理範囲に属すようにしたり、３以上の管理範囲に分けてもよい。
【００１３】
探索装置１は、第１の管理範囲１０に属する構成要素Ｃ１１〜Ｃ１５に発生した異常について、異常の起点となった構成要素の候補を異常の起点候補として探索し、評価する。
【００１４】
探索装置１は、探索部３、クエリ発行部４、評価部５を有する。探索部３は、第１の管理範囲１０に属する構成要素Ｃ１１〜Ｃ１５に発生した異常について、探索装置１が管理している構成要素間の接続情報に基づいて、異常が発生した構成要素の接続関係を辿ることで異常の起点候補を探索する。クエリ発行部４は、探索部３が辿った先の構成要素が第２の管理範囲２０に属する構成要素である場合に、探索装置２に対して異常の起点候補の探索を依頼するクエリを発行する。評価部５は、探索部３による探索結果とクエリ発行部４が発行したクエリに対する応答とに基づいて、異常の起点候補を評価する。
【００１５】
探索装置２は、探索部６、評価部７、クエリ処理部８を有する。クエリ処理部８は、探索装置１からクエリを受信する。探索部６は、装置２が管理している構成要素間接続情報と、受信したクエリとに基づいて第２の管理範囲２０に属する構成要素Ｃ１６〜１９の接続関係を辿って異常の起点候補を探索する。
【００１６】
そして、評価部７は、探索部６による探索結果に基づいて異常の起点候補を評価し、評価結果をクエリに対する応答として探索装置１に送信する。
【００１７】
・実施例１のまとめ
上述したように、探索装置１は、第１の管理範囲で発生した異常について起点候補を探索する際に、探索先が第２の管理範囲に及ぶ場合には探索装置２にクエリを送信して第２の管理範囲内での異常起点の探索を依頼する。
【００１８】
探索装置２は、クエリを受信して第２の管理範囲内で異常の起点候補を探索し、応答する。これによれば、探索装置１は、第２の管理範囲における構成要素及び構成要素間の接続関係についての詳細情報を管理していなくとも、異常の起点の探求を効率的に行うことができる。
【００１９】
なお、上述した実施例において、探索装置２のダミー処理部９が、探索部６が探索した異常の起点候補である構成要素をダミーの構成要素（第２の管理範囲における構成要素の固有の識別情報や、持続的な(persistent)な識別情報でない情報）に置き換え、ダミーの構成要素の情報と、そのダミーの構成要素についての評価結果をクエリ処理部８から応答として探索装置１に返すこともできる。なお、ダミーの構成要素の情報として、例えば、非持続的な(non-persistent)な、識別情報を用いることができる。ダミーの構成要素の情報は、非持続的な識別情報であるため、異常の起点を探索する処理を行った後に、更に別の異常の起点を探索する処理を行う際に、識別情報を変更してしまうこともできる。識別情報の変更の契機は、クエリにクエリ識別情報が含まれる場合、クエリ識別情報が変化したこと、所定時間経過したこと等とすることができる。
【００２０】
これによれば、探索装置１は、第２の管理範囲における構成要素、構成要素間の接続関係を把握しなくとも異常の起点候補を探索できる。言い換えれば、第２の管理範囲における構成要素、構成要素間の接続関係を第１の装置である探索装置１に対して秘匿しつつ探索装置１に異常の起点候補を探索させることができる。なお、探索装置１は、第１の管理範囲のエッジ部分の構成要素Ｃ１４に対応させて関連性識別子ｒ０１、構成要素Ｃ１５に対応させて関連性識別子ｒ０２を記憶しておき（ＣＭＤＢに登録することで記憶してもよい）、第２の装置である探索装置２は、ｒ０１に対応させて第２の管理範囲のエッジ部分の構成要素Ｃ１６、Ｃ１７を対応させて記憶し、また、ｒ０２に対応させて第２の管理範囲のエッジ部分の構成要素Ｃ１６を対応させて記憶しておくことで、探求先が第１の管理範囲内の構成要素Ｃ１４から第２の管理範囲側に及ぶ場合、クエリに識別情報ｒ０１を含めることで、Ｃ１５とＣ１６の間、Ｃ１５とＣ１７との間に接続関係があることを第１の装置及び第２の装置の双方ともが認識していなくとも、探求すべきパスを特定することができる。すなわち、クエリにｒ０１が含まれる場合、探索装置２は、構成要素Ｃ１６、Ｃ１７を経由する経路を辿って、異常の起点候補の探索を行うことができる。
【実施例２】
【００２１】
・実施例２の構成
図２は、実施例２にかかる探索装置１３の構成図である。図２に示した探索装置１３は、ユーザインタフェース３１、関連探索部３２、境界判定部３３、クエリ発行部３４、クエリ処理部３５、仮想構成管理部３６、評価部３７を有する。また、探索装置１３は、ＣＭＤＢ（Configuration Management Database）１１、障害ＤＢ（Database）１２およびＣＩ（Configuration Item）−ＶＣＩ（Virtual Configuration Item）対応表１４を参照可能である。なお、これらの、ＤＢ、対応表は記憶装置に記憶される。更に、探索装置１３は、図３に示したように他の探索装置２３と接続されている。
【００２２】
図３は、探索装置間の接続についての説明図であり、図４は、複数のドメインにまたがるネットワークシステムの説明図である。図４に示したネットワークシステムは、ネットワークｎｗ１１に物理マシンであるサーバｐｍ１１，１２が接続している。サーバｐｍ１１は仮想マシンプログラムを実行することで、仮想マシンＶＭ１１，１２として動作する。アプリケーションＡｐｐ１１は仮想マシンＶＭ１１上で動作する。同様に、アプリケーションＡｐｐ１２は仮想マシンＶＭ２上で動作する。
【００２３】
また、サーバｐｍ１２は仮想マシンプログラムを実行することで、仮想マシンＶＭ１３〜１５として動作する。アプリケーションＡｐｐ１３は仮想マシンＶＭ１３上で動作する。そして、アプリケーションＡｐｐ１４は仮想マシンＶＭ１４上で動作し、アプリケーションＡｐｐ１５は仮想マシンＶＭ１５上で動作する。同様に、ネットワークｎｗ１２に接続されたサーバｐｍ１３は仮想マシンプログラムを実行することで、仮想マシンＶＭ１６として動作する。アプリケーションＡｐｐ１６は仮想マシンＶＭ１６上で動作する。
【００２４】
また、アプリケーションＡｐｐ１３はアプリケーションＡｐｐ１５を利用しており、アプリケーションＡｐｐ１４はアプリケーションＡｐｐ１６を利用している。さらにアプリケーションＡｐｐ１２は、アプリケーションＡｐｐ１４を利用してサービスＳｖ１１を提供する。
【００２５】
このネットワークシステムでは、ネットワークｎｗ１１，１２、サーバｐｍ１１〜１３、仮想マシンＶＭ１１〜１６、アプリケーションＡｐｐ１１〜１６、サービスＳｖ１１が構成要素（ＣＩ:Configuration Item）として用いられている。また、構成要素間の接続関係が関連（relation）の例として用いられている。関連は、構成要素間の利用関係の方向を情報として含む。具体的には、利用される側の構成要素をソース、利用する側の構成要素をターゲットとし、例えば、ソースからターゲットに向けた方向を定める。構成情報に、システムの構成要素と関連についての情報を含めることができる。
【００２６】
図４に示したネットワークシステムの構成は、物理マシンであるサーバｐｍ１１〜１３が仮想マシンプログラムを実行することで仮想マシンＶＭ１１〜１６として動作し、仮想マシン上でＡｐｐ１１〜１６が動作し、サービスＳｖ１１が提供されるクラウド環境である。
【００２７】
この例では、クラウド環境の利用者は、仮想マシンＶＭ１１〜１６、アプリケーションＡｐｐ１１〜１６及びサービスＳＶ１を構成要素として認識しておらず、ネットワークｎｗ１１，１２やサーバｐｍ１１〜１３などの物理的な構成要素について知らないものとする。また、クラウド環境の提供者もネットワークｎｗ１１，１２やサーバｐｍ１１〜１３などの物理的な構成要素について情報を開示していないものとする。
【００２８】
この図４に示したネットワークシステムで異常が発生した場合、異常の起点がネットワークｎｗ１１，１２やサーバｐｍ１１〜１３などの物理的な構成要素であるならば、提供者側が管理している(管理責任がある)ことになる。一方、異常の起点がアプリケーションＡｐｐ１１〜１６、サービスＳｖ１１などの構成要素であるならば、利用者側が管理している（管理責任がある）ことになる。
【００２９】
このように、クラウド環境の利用者側は、アプリケーションＡｐｐ１１〜１６、サービスＳｖ１１の管理について責任があり、それらの詳細な構成情報を持ち、クラウド環境の提供者側はネットワークｎｗ１１，１２やサーバｐｍ１１〜１３の管理に責任があり、それらの詳細な構成情報を持つ。ネットワークの構成要素について管理する範囲をドメインという。図４に示した例では、第１ドメインが利用者側の管理範囲であり、第２ドメインが提供者側の管理範囲である。なお、ドメインの定義は、この例に限らず、システムの利用形態に応じて様々な変更が可能である。
【００３０】
第２ドメイン側の構成情報は第１ドメイン側に秘匿され、第１ドメイン側の構成情報は第２ドメイン側に秘匿されるようにしてもよい。そして、図３に示したように、第１ドメイン側システムに探索装置１３、第２ドメイン側システムに探索装置２３をそれぞれ設け、ドメインごとに異常の起点候補の評価、探索を行う。
【００３１】
第１ドメイン側のシステムに設けた探索装置１３は、ＣＭＤＢ１１、障害ＤＢ１２、ＣＩ−ＶＣＩ対応表１４を格納する各記憶装置と接続されており、格納された各種データにアクセスすることができる。ＣＭＤＢ１１は第１ドメインの構成情報を保持するデータベースであり、障害ＤＢ１２は、第１ドメインに属する構成要素に発生した各種の異常に関する情報を障害情報として格納するデータベースである。ＣＩ−ＶＣＩ対応表１４は、第２ドメイン側から異常の起点候補の探索を求められた場合に第２ドメインに応答するダミーの構成要素と第１ドメインの実際の構成要素との対応関係を示す表である。第２ドメイン側からダミーの構成要素を指定した問い合わせがあった際に、ＣＩ−ＶＣＩの対応表１４を用いることで、そのダミーの構成要素に対応する実際の構成要素を特定することができるため、特定した実際の構成要素が異常状態を脱したかどうか調査し、その調査結果を第２ドメイン側に送信することもできる。好ましくは、ダミーの構成要素は、クエリの識別情報と対応づけてＣＩ−ＶＣＩの対応表に登録され、異なるクエリに対する応答の際に、同じ構成要素について、ダミー情報を用いることもできる。
【００３２】
第２ドメイン側のシステムに設けた探索装置２３は、ＣＭＤＢ２１、障害ＤＢ２２、ＣＩ−ＶＣＩ対応表２４を記憶する各記憶装置と接続されており、格納された各種データにアクセスすることができる。ＣＭＤＢ２１は第２ドメインの構成情報を保持するデータベースであり、障害ＤＢ２２は、第２ドメインに属する構成要素に発生した各種異常を障害情報として格納するデータベースである。ＣＩ−ＶＣＩ対応表２４は、第１ドメイン側から異常の起点候補の探索を求められた場合に第１ドメインに応答するダミーの構成要素と第２ドメインの実際の構成要素との対応関係を示す表である。第１ドメイン側からダミーの構成要素を指定した問い合わせがあった際に、ＣＩ−ＶＣＩの対応表２４を用いることで、そのダミーの構成要素に対応する実際の構成要素を特定することができるため、特定した実際の構成要素が異常状態を脱したかどうか調査し、その調査結果を第１ドメイン側に送信することもできる。好ましくは、ダミーの構成要素は、クエリの識別情報と対応づけてＣＩ−ＶＣＩの対応表に登録され、異なるクエリに対する応答の際に、同じ構成要素について、ダミー情報を用いることもできる。
【００３３】
また、探索装置１３と探索装置２３とはネットワークを介して接続され、互いにクエリの送信と応答を行うことができる。探索装置１３と探索装置２３とは同一の構成を有することもできる。そこで、ここでは同一の構成を有するものとして、図２に示した探索装置１３の構成について説明を行い、探索装置２３についての説明は省略する。
【００３４】
図２に示したユーザインタフェース３１は、探索装置１３のユーザから異常の起点候補の評価の開始を指示する入力を受け付け、異常の起点候補の評価結果を出力する入出力処理部である。
【００３５】
関連探索部３２は、ＣＭＤＢ１１および障害ＤＢ１２を参照し、異常の起点候補を探索する。具体的には、関連探索部３２は、障害ＤＢ１２から異常が発生した構成要素を選択する。そして、選択した構成要素についてＣＭＤＢ１１を参照し、構成要素を設定された関連を逆方向に辿る。言い換えれば、関連探索部３２は、選択した構成要素をターゲットとする関連をソース側に辿る。関連探索部３２は、関連を辿った経路上に存在する構成要素のうち、異常が発生している最も上流の構成要素を異常の起点候補とする。
【００３６】
境界判定部３３は、関連探索部３２が辿った関連が、第１ドメインと第２ドメインの境界をまたぐ関連であるかを判定する。具体的には、第２ドメインは、図５に示したように一つの仮想的な構成要素、ダミーＣＩ（Ｄｃ１１）としてＣＭＤＢ１１に登録されている。境界判定部３３は、関連探索部３２が辿った関連のソースがダミーＣＩ（Ｄｃ１１）である場合に、第１ドメインと第２ドメインの境界をまたぐ関連であると判定する。
【００３７】
クエリ発行部３４は、境界判定部３３による判定の結果、関連探索部３２が辿った関連が境界をまたぐ関連である場合に、探索装置２３に対してクエリを発行する。なお、その際、仮想マシンＶＭ１１を辿った先がＤｃ１１である場合、ＶＭ１１とＤｃ１１との関連を示す識別情報を含めることが望ましい。
【００３８】
クエリ処理部３５は、探索装置２３からクエリに対する応答を受信し、評価部３７に渡す。
【００３９】
評価部３７は、関連探索部３２による異常の起点候補の探索結果と、クエリ処理部３５が取得したクエリ応答の内容に基づいて異常の起点候補を評価する。具体的には、評価部３７は、異常の起点候補として挙げられた構成要素の評点を求めて集計する。
例えば、評点の求め方として、
構成要素の評点＝自分の異常数 ＋ 関連の下流の構成要素の評点 （式１）
を利用してもよい。すなわち、異常が発生している構成要素で最も上流にあるものを起点候補とし、起点候補とその評点を集めて評価結果としても良い。そして、評点の高い構成要素ほど異常の起点である可能性が高いと評価する。評価部３７は、ユーザインタフェース３１を介して評価結果を出力する。
【００４０】
また、クエリ処理部３５は、探索装置２３からクエリを受信した場合には、関連探索部３２に対して異常の起点候補の探索を要求する。クエリ処理部３５は、探索装置２３からのクエリに基づいて関連探索部３２が探索した異常の起点候補について、評価部３７から評価を取得する。クエリ処理部３５は、関連探索部３２が探索した異常の起点候補をダミーの構成要素に置き換えて、ダミーの構成要素と評価結果を探索装置２３からのクエリに対する応答として返す。
【００４１】
仮想構成管理部３６は、第１ドメインの実際の構成要素とダミーの構成要素との関係を管理する処理部である。例えば、仮想構成管理部３６は、探索装置２３から受信したクエリの識別情報と、置き換え対象となる第１ドメインの構成要素に基づいてＣＩ−ＶＣＩ対応表１４を参照する。
【００４２】
クエリの識別情報と、置き換え対象となる第１ドメインの構成要素との組み合わせに対応するダミーの構成要素が登録されていれば、仮想構成管理部３６は、対応するダミーの構成要素をクエリ処理部３５に通知する。また、クエリの識別情報と、置き換え対象となる第１ドメインの構成要素との組み合わせに対応するダミーの構成要素が登録されていなければ、仮想構成管理部３６は、ダミーの構成要素を新規に登録する。具体的には、仮想構成管理部３６は、クエリの識別情報と、置き換え対象となる第１ドメインの構成要素との組み合わせに新しくダミーの構成要素を対応させ、ＣＩ−ＶＣＩ対応表１４に登録するとともに、クエリ処理部３５に通知する。なお、クエリ識別情報ごとにダミーの構成要素を登録し、ダミーの構成要素が登録されているか否かは、クエリの識別情報に対応する対応表を参照して判断することもできる。これによれば、クエリ識別情報ごとに、異なる対応関係を適用した対応表を適用することができるため、クエリに対する応答の累積により、構成要素間の関連性が開示されていくことを回避することができる。
【００４３】
このように、探索装置１３は、探索装置２３からのクエリに対してはダミーの構成要素を返すことで第１ドメインの構成を仮想化する。このため、探索装置１３は、第１ドメインの実際の構成を秘匿して仮想的な構成で異常の起点候補を探索装置２３に通知することができる。
【００４４】
同様に、探索装置２３も探索装置１３に対して第２ドメインの実際の構成を秘匿し、仮想的な構成でクエリに対する応答を行う。
【００４５】
したがって、第１ドメインと第２ドメインの構成を互いに知らせることなく、発生した異常の起点がどちら側にあるか、すなわち第１ドメインと第２ドメインのどちらに責任があるかを調査することもできる。
【００４６】
・処理動作の説明
図６は、異常の起点候補の評価に関する処理を説明するフローチャートである。図６に示したように、まず、ネットワークの状態を監視する装置が自ドメインの異常を検知する（Ｓ１０１）。異常を検知する装置は、探索装置であってもよいし、他の監視装置であっても良い。異常を検知した装置は、検知結果を自ドメインの障害ＤＢに登録する。
【００４７】
つぎに、探索装置が自ドメインの障害ＤＢを参照し、異常起点調査処理（Ｓ１０２）を行って、結果を集計し（Ｓ１０３）、出力する（Ｓ１０４）。
【００４８】
なお、異常検知（Ｓ１０１）は、随時行うことが望ましい。また、異常起点調査処理（Ｓ１０２）は、ユーザが指定したタイミングで行なっても良いし、定期的に実行しても良い。また、異常の検知と連動して実行することとしても良い。
【００４９】
図７は、異常起点調査処理（Ｓ１０２）について説明するフローチャートである。以降の処理は、探索装置１３が実行する場合を例として説明する。異常起点調査処理を開始した探索装置１３の関連探索部３２は、障害ＤＢ１２を参照し、異常を示した構成要素（ＣＩ）を一つ選択する（Ｓ２０１）。このとき、関連探索部３２は、異常を発生した構成要素の種別によって選択の優先順位をつける。具体的には、種別がサービスの構成要素に異常が発生していれば優先的に選択し、次に種別がアプリケーションの構成要素を優先的に選択し、同様に、仮想マシン、物理マシン、スイッチ、ルータの順に選択する。このように、構成要素の種別に基づいて選択を行なう事で、ネットワークシステム上で下流側に位置する可能性の高い構成要素から順に選択を行なうことができる。
【００５０】
関連探索部３２は、選択した構成要素から関連を逆方向に辿る（Ｓ２０２）。すなわち、異常を示した構成要素が異常を示すこととなった原因となる構成要素を探索する。境界判定部３３は、辿った先の構成要素が自ドメイン内の構成要素であるかを判定する（Ｓ２０３）。辿った先の構成要素が自ドメイン内の構成要素で無い場合（Ｓ２０３，Ｎｏ）、クエリ発行部３４がクエリを発行し（Ｓ２０４）、発行したクエリに対する応答をクエリ処理部３５が受信する（Ｓ２０５）。
【００５１】
辿った先の構成要素が自ドメイン内の構成要素である場合（Ｓ２０３，Ｙｅｓ）、関連探索部３２は、さらに関連を辿るかを判定する（Ｓ２０６）。さらに関連を辿るかどうかは、一例として選択した構成要素から辿った関連の数で決めればよい。辿った関連の数をホップ数といい、辿るべき関連の数の最大値を最大ホップ数という。例えば、最大ホップ数を３と定めた場合、選択した構成要素から３つまで関連を辿る。選択した構成要素をターゲットとする複数の関連がある場合や、辿った先の構成要素をターゲットとする関連が複数ある場合、それぞれの経路を辿る。また、エラーの種類や構成要素の種類に応じて重み付けを行なって関連を辿っても良い。
【００５２】
さらに関連を辿る場合（Ｓ２０６，Ｙｅｓ）、関連探索部３２は、ステップＳ２０２に戻り、辿った先の構成要素からさらに関連を辿る。そして、関連を辿らない場合（Ｓ２０６，Ｎｏ）、関連探索部３２は、障害ＤＢ１２に登録された全ての異常について調査を行なったかを判定する（Ｓ２０７）。この時、関連探索部３２は、他の構成要素から関連を辿ることで到達した構成要素の異常は調査済みとすることができる。
【００５３】
調査を行なっていない異常が残っている場合（Ｓ２０７，Ｎｏ）、関連探索部３２は、ステップＳ２０１に戻り、異常を示した構成要素をひとつ選択する。そして、障害ＤＢ１２に登録された全ての異常について調査を行なった場合（Ｓ２０７，Ｙｅｓ）に、探索装置１３は、異常起点調査処理を終了する。
【００５４】
図８は、クエリを受信した探索装置の処理動作を説明するフローチャートである。図８では、探索装置１３が他の探索装置からクエリを受信した場合を例に説明する。クエリ処理部３５は、クエリを受信する（Ｓ３０１）と、受信したクエリに基づいて関連探索部３２に異常の起点候補の探索を要求する。関連探索部３２は、クエリに示された識別情報（図９の関連ｒ０１参照）と異常に基づいて異常起点調査を行なう（Ｓ３０２）。評価部３７は、関連探索部３２による探索結果を集計し、評価する（Ｓ３０３）。クエリ処理部３５は、関連探索部３２による探索の結果として得られた起点候補を仮想構成管理部３６に渡す。仮想構成管理部３６は、起点候補についてダミーの構成要素の識別情報である仮想ＩＤを取得し、クエリ処理部３５に返す（Ｓ３０４）。
【００５５】
クエリ処理部３５は、仮想構成管理部３６から得られた仮想ＩＤと評価部３７による評価結果とを対応付け、クエリ応答としてクエリの送信元の探索装置に送信し（Ｓ３０５）、処理を終了する。なお、異常起点調査（Ｓ３０２）の詳細は、図７に示した処理と同様である。
【００５６】
・各種データの例
図９は、データの具体例の説明図である。図９に示したクエリＤ１は、クエリＩＤ、異常内容、時刻範囲、関連の項目を有する。図９の例では、クエリＩＤは１００、異常内容は応答時間停止、時刻範囲は2009/12/01 12:00:00〜2009/12/01 18:00:00、関連識別情報はｒ０１である。なお、送信元のドメインは、関連識別情報（ｒ０１）に基づいて、送信元のドメインの対応する構成要素を特定でき、送信先のドメインは、関連（ｒ０１）に基づいて、送信先ドメインの対応する構成要素を特定することができる。
【００５７】
すなわち、関連の項目は、クエリの送信元のドメインと送信先のドメインをまたぐ関連であり、クエリを受信した異常起点調査は、この関連のソースとなる構成要素から異常の起点候補を探索する。このように、クエリには送信元のドメインの構成を示す必要はなく、ドメインをまたぐ関連と異常に関する情報を含めばよい。このため、クエリを送信することで送信元のドメインの構成を送信先のドメインに対して秘匿しつつ異常の起点候補を探索することができる。
【００５８】
クエリ応答Ｄ２は、ＶＣＩと評点の項目を有する。ＶＣＩは、ダミーの構成要素のＩＤを示す項目であり、評点はダミーの構成要素の評価結果である。
【００５９】
外部ＣＩ情報Ｄ３は、構成情報ＤＢに登録される他のドメインの構成情報の具体例である。ＣＩ名としてはクラウドノードとして登録され、位置は自ドメインに対して外部のドメインであることを示している。
【００６０】
ＣＩ−ＶＣＩ対応表Ｄ４は、ＣＩ−ＶＣＩ対応表の一例であり、クエリＩＤに対して実際の構成要素であるＣＩのＩＤと仮想の構成要素であるＶＣＩのＩＤとを対応づけて保持している。図９の例では、クエリＩＤ１００に対してＣＩであるＳＷ２とＶＣＩであるＶ００１とを対応づけて保持している。また、クエリＩＤ１００に対してＣＩであるＰＭ２とＶＣＩであるＶ００２とを対応づけて保持している。さらに、クエリＩＤ１０１に対しては、ＣＩであるＳＷ２とＶＣＩであるＶ００３とを対応づけて保持している。
【００６１】
ＣＩ−ＶＣＩ対応表は、ＩＤが同一のクエリに対しては、同一の対応関係を使用する。一方で、クエリのＩＤが異なる場合には、異なる対応関係を使用して、同一のＣＩ（図９の例ではＳＷ２）に対して異なるＶＣＩを対応させる。このため、クエリのＩＤごとに仮想の構成が一意に定まるので、仮想の構成で異常の起点候補を正確に評価するとともに、複数のクエリによって実際の構成の推定を難しくすることができる。
【００６２】
評点表Ｄ５は、評価部による評価結果の具体例であり、ＣＩのＩＤに評点を対応づけた構成を有する。評点表Ｄ５では、Ｖ００１の評点が９、Ｖ００２の評点が３、ＳＷ２の評点が１である。したがって、評点表Ｄ５では、評点が最も高いＶ００１が異常の起点であることが推定される。このＶ００１は、他のドメインからのクエリ応答として得られた仮想の構成要素であるので、Ｖ００１が異常の起点であるならば、自ドメイン側を起点とした異常の発生ではないことが推定される。
【００６３】
図１０は、異常の起点候補の評価結果を表示する画面例についての説明図である。図１０に示した画面例Ｄ６，７は、「異常の起点である可能性が高いＣＩは以下の通りです。」というメッセージとともに、ＣＩのＩＤと責任元の情報を表示している。一例として、評点が上位２つの構成要素を異常の起点である可能性が高い構成要素とすればよい。
【００６４】
画面例Ｄ６は、Ａｐｐ２とＡｐｐ１を異常の起点である可能性が高いＣＩとして表示し、Ａｐｐ２とＡｐｐ１がともに自ドメインの管理範囲内であることを示している。画面例Ｄ７は、Ｖ００１とＶ００２を異常の起点である可能性が高いＣＩとして表示し、Ｖ００１とＶ００２がともに自ドメインの管理範囲外であることを示している。
【００６５】
・異常の起点候補探索の具体例
図１１〜１４は、異常の起点候補の探索の例についての説明図である。図１１に示したネットワークシステムでは、システム４１とシステム４２とが接続されている。システム４１は、ルータＲＴ１、スイッチＳＷ１、物理マシンＰＭ１、アプリケーションＡｐｐ１、サービスＳＶＣ１を有する。システム４２は、ルータＲＴ２、スイッチＳＷ２、物理マシンＰＭ２，３、仮想マシンＶＭ１〜３、アプリケーションＡｐｐ２〜４を有する。
【００６６】
ルータＲＴ１とルータＲＴ２とが接続され、システム４１，４２との間の通信が可能な状態となっている。スイッチＳＷ１，２は、同一システム内の物理マシンとルータとを接続する。アプリケーションＡｐｐ１は、物理マシンＰＭ１上で動作する。
【００６７】
仮想マシンＶＭ１，２は、物理マシンＰＭ２上で動作する。同様に、仮想マシンＶＭ３は、物理マシンＰＭ３上で動作する。そして、アプリケーションＡｐｐ２〜４は、それぞれ物理マシンＰＭ１〜３上で動作する。
【００６８】
サービスＳＶＣ１は、アプリケーションＡｐｐ１〜４を利用して提供されるサービスである。
【００６９】
図１１に示したネットワークシステムでは、ルータＲＴ１、スイッチＳＷ１、物理マシンＰＭ１、アプリケーションＡｐｐ１〜４、仮想マシンＶＭ１〜３、サービスＳＶＣ１が第１の管理範囲１０に含まれる。また、ルータＲＴ２、スイッチＳＷ２、物理マシンＰＭ２〜３が第２の管理範囲２０に含まれる。第１の管理範囲１０の構成情報はＣＭＤＢ１１が保持し、第１の管理範囲１０内で発生した異常に関する情報は障害ＤＢ１２が保持する。同様に、第２の管理範囲２０の構成情報はＣＭＤＢ２１が保持し、第２の管理範囲２０内で発生した異常に関する情報は障害ＤＢ２２が保持する。管理範囲の態様は、これに限らず、更に多くの管理範囲を形成してもよい。その際、障害ＤＢは、複数の管理範囲のそれぞれに設けてよい。
【００７０】
図１２は、第１の管理範囲１０のアプリケーションＡｐｐ２でアプリケーションの応答時間が悪化するエラーＥ１が発生した場合の説明図である。
【００７１】
アプリケーションの応答時間悪化の原因としては、例えば、Ｊａｖａ（登録商標）アプリケーションにおいてオブジェクトの解放漏れがあるため、巨大ＧＣ(Garbage Collection）が時々発生し、アプリケーションの応答時間が数十秒になった場合などがある。
【００７２】
Ａｐｐ２にエラーＥ１が発生すると、アプリケーションＡｐｐ２に依存するアプリケーションＡｐｐ１やサービスＳＶＣ１の応答時間も悪化し、エラーＥ１が発生する。これらの応答時間の悪化は、運用管理ソフトウェアにより、第１の管理範囲１０の管理者が予め定めた応答時間閾値を超えることで、異常として検出される。応答時間閾値は、一例として３秒などである。
【００７３】
図１２に示した例では、第１の管理範囲１０に発生したサービスＳＶＣ１、アプリケーションＡｐｐ１，２のエラーＥ１が障害ＤＢ１２に登録される。この３つのエラーから探索装置１３が異常の起点候補を評価する場合について説明する。
【００７４】
探索装置１３は、まず、サービスＳＶＣ１、アプリケーションＡｐｐ１，２のうち、構成要素の種別に基づいてサービスＳＶＣ１を選択する。探索装置１３は、選択したサービスＳＶＣ１を探索の開始点として関連を辿りながら、辿った経路上に存在する構成要素のうち、異常が発生している構成要素について、例えば式１で示したような計算方法で評点を算出する。
【００７５】
探索の開始点であるサービスＳＶＣ１は、自分自身の異常数が１で、関連の下流に位置する構成要素は存在しないため、式１に従って評点を求めると１＋０＝１となる。サービスＳＶＣ１から辿ることの出来る構成要素は、アプリケーションＡｐｐ１〜４である。
【００７６】
アプリケーションＡｐｐ１は、自分自身の異常数が１で、サービスＳＶＣ１が下流の構成要素として存在するため、求めたＳＶＣ１の評点１を加算して（１＋１）、合計評点２を得る。アプリケーションＡｐｐ１から辿ることの出来る構成要素は、物理マシンＰＭ１とアプリケーションＡｐｐ２である。物理マシンＰＭ１から辿ることのできる経路上には、スイッチＳＷ１とルータＲＴ１が存在するが、物理マシンＰＭ１、スイッチＳＷ１、ルータＲＴ１には異常が発生していないため、評点は求めない。
【００７７】
アプリケーションＡｐｐ２は、自分自身の異常数が１で、サービスＳＶＣ１とアプリケーションＡｐｐ１が下流の構成要素として存在する。このため、アプリケーションＡｐｐ２の評点は、自身の異常数１に、サービスＳＶＣ１の評点１とアプリケーションＡｐｐ１の評点２を加算して（１＋１＋２）、合計評点４を得る。アプリケーションＡｐｐ２から辿ることの出来る構成要素は、仮想マシンＶＭ１である。
【００７８】
仮想マシンＶＭ１は、異常が発生していないので評点は求めない。仮想マシンＶＭ１からさらに関連を辿ると、第２の管理範囲２０に至る。ここで、第２の管理範囲２０は、図１３に示したように探索装置１３からは１つの構成要素、クラウドノードＶＣ１として認識されている。探索装置１３は、辿った先がクラウドノードＶＣ１であることから、第２の管理範囲２０の異常の起点候補を探索する探索装置２３に対してクエリＱ１１を発行する。このクエリＱ１１は、仮想マシンＶＭ１とクラウドノードＶＣ１との間に設定された関連の情報と、探索の開始点の異常の情報を含む。また、クエリＱ１１に含まれる関連までのホップ数や、最大ホップを含んでも良い。
【００７９】
探索装置２３は、クエリを受けて第２の管理範囲２０内での異常の起点候補の探索を行なう。具体的には、クエリＱ１１に指定された仮想マシンＶＭ１との関連を開始点として関連を辿って異常の起点候補を探索する。図１２に示した例では、仮想マシンＶＭ１と物理マシンＰＭ２との関連がクエリＱ１１によって指定されているので、物理マシンＰＭ２から関連を辿ることとなる。しかし、第２の管理範囲２０内では異常が発生していないため、探索装置２３は、クエリＱ１１に対して起点候補無しの旨の応答を行う。
【００８０】
アプリケーションＡｐｐ３〜４は、サービスＳＶＣ１から辿ることが出来るが、異常が発生していないため評点は求めない。アプリケーションＡｐｐ３から辿ることの出来る構成要素は、仮想マシンＶＭ２であり、仮想マシンＶＭ２からさらに関連を辿ると、第２の管理範囲２０に対応するクラウドノードＶＣ１に至る。同様に、アプリケーションＡｐｐ４から辿ることの出来る構成要素は、仮想マシンＶＭ３であり、仮想マシンＶＭ３からさらに関連を辿ると、クラウドノードＶＣ１に至る。
【００８１】
探索装置１３は、仮想マシンＶＭ２，３から関連を辿ってクラウドノードＶＣ１に到達した場合にも探索装置２３に対してクエリＱ１１，１２を発行する。このクエリＱ１１，１２は、仮想マシンＶＭ２，３とクラウドノードＶＣ１との間に設定された関連の情報と、探索の開始点の異常の情報を含む。探索装置２３は、クエリＱ１１，１２を受けて第２の管理範囲２０内での異常の起点候補の探索を行い、第２の管理範囲２０内では異常が発生していないため、起点候補無しの旨の応答を行う。
【００８２】
このように、図１２に示した例において、サービスＳＶＣ１を開始点として探索を行なうと、アプリケーションＡｐｐ２が最も上流で異常が発生している構成要素であるので、アプリケーションＡｐｐ２（評点４）が異常の起点候補となる。
【００８３】
また、サービスＳＶＣ１を開始点として探索を行なう過程で、他に異常が発生した構成要素であるアプリケーションＡｐｐ１，２の評価を行なったので、アプリケーションＡｐｐ１，２を開始点とする探索は不要となる。このため、図１２に示した例では、探索装置１３はアプリケーションＡｐｐ２（評点４）を異常の起点候補とする。
【００８４】
図１２に示した例では、異常の起点候補は１つとなったが、異常の起点候補が複数となった場合には、探索装置１３は複数の起点候補を評点とともに出力する。例えば、複数の異常が同時に発生した場合や、実際の起点が１つであっても探索で候補を絞りきれない場合には複数の起点候補が出力されることとなる。なお、評点の算出は、異常の起点としての確からしさを数値化する他の手法を用いてもよい。また、異常が発生していない構成要素についても異常の起点候補として評点を与える手法を用いても良い。
【００８５】
図１４は、第２の管理範囲２０のスイッチＳＷ２で輻輳に起因する応答時間悪化のエラーＥ１が発生した場合の説明図である。
【００８６】
スイッチＳＷ２のようなＬ２（Ｌａｙｅｒ２）スイッチが輻輳を起こすと、アプリケーションＡｐｐ２，３など上位のアプリケーションでＩＰパケットが一部廃棄される。下位の仮想マシンＶＭ１，２のＴＣＰ層は、暫く待って（例えば３秒後、更に破棄されたらその６秒後など）、ＩＰパケットの再送（エラーＥ２）を行う。これにより、アプリケーションＡｐｐ１，２の応答時間も３秒、６秒といった長さになる。そして、アプリケーションＡｐｐ２に依存するアプリケーションＡｐｐ１やサービスＳＶＣ１の応答時間も悪化する（エラーＥ１）。
【００８７】
これらの応答時間の悪化は、運用管理ソフトウェアにより、管理者が予め定めた応答時間閾値(一例として３秒など)を超えることで、異常として検出される。また、スイッチＳＷ２、仮想マシンＶＭ１，２では、運用管理ソフトウェアの計測するＴＣＰ再送回数やパケット廃棄率が上昇することにより、異常として検出される。
【００８８】
図１４に示した例では、第１の管理範囲１０に発生したサービスＳＶＣ１、アプリケーションＡｐｐ１〜３のエラーＥ１と仮想マシンＶＭ１，２のエラーＥ２が障害ＤＢ１２に登録される。また、第２の管理範囲２０に発生したスイッチＳＷ２のエラーＥ１が障害ＤＢ２２に登録される。これら７つのエラーから探索装置１３，２３が異常の起点候補を評価する場合について説明する。
【００８９】
探索装置１３は、まず、第１の管理範囲１０で異常が発生したサービスＳＶＣ１、アプリケーションＡｐｐ１〜３、仮想マシンＶＭ１〜２のうち、構成要素の種別に基づいてサービスＳＶＣ１を選択する。探索装置１３は、選択したサービスＳＶＣ１を探索の開始点として関連を辿りながら、辿った経路上に存在する構成要素のうち、異常が発生している構成要素について、例えば式１で示したような計算方法で評点を算出する。
【００９０】
図１２の例と同様に、サービスＳＶＣ１の評点は１、アプリケーションＡｐｐ１の評点は２、アプリケーションＡｐｐ２の評点は４となる。アプリケーションＡｐｐ１から辿ることの出来る構成要素のうち、物理マシンＰＭ１、スイッチＳＷ１、ルータＲＴ１には異常が発生していないため、評点は求めないことについても図１２の例と同様である。
【００９１】
図１４に示した例では、アプリケーションＡｐｐ２から辿ることの出来る仮想マシンＶＭ１は、自分自身の異常数１にアプリケーションＡｐｐ２の評点が４を加算して（１＋４）合計評点５を得る。
【００９２】
アプリケーションＡｐｐ３は、自分自身の異常数が１で、サービスＳＶＣ１が下流の構成要素として存在する。このため、アプリケーションＡｐｐ２の評点は、自身の異常数１に、サービスＳＶＣ１の評点１を加算して（１＋１）、合計評点２を得る。アプリケーションＡｐｐ３から辿ることの出来る構成要素は、仮想マシンＶＭ２である。
【００９３】
仮想マシンＶＭ２は、自分自身の異常数１にアプリケーションＡｐｐ２の評点４を加算して（１＋２）合計評点３を得る。
【００９４】
仮想マシンＶＭ１からさらに関連を辿ると、第２の管理範囲２０に至る。ここで、第２の管理範囲２０は、図１２に示したように探索装置１３からは１つの構成要素、クラウドノードＶＣ１として認識されている。探索装置１３は、辿った先がクラウドノードＶＣ１であることから、第２の管理範囲２０の異常の起点候補を探索する探索装置２３に対してクエリＱ２１を発行する。このクエリＱ２１は、仮想マシンＶＭ１とクラウドノードＶＣ１との間に設定された関連の情報と、探索の開始点の異常の情報を含む。また、クエリに含まれる関連までのホップ数や、最大ホップを含んでも良い。
【００９５】
同様に、仮想マシンＶＭ２からさらに関連を辿ると、第２の管理範囲２０に対応するクラウドノードＶＣ１に至る。探索装置１３は、仮想マシンＶＭ２から関連を辿ってクラウドノードＶＣ１に到達した場合に探索装置２３に対してクエリＱ２２を発行する。このクエリＱ２２は、仮想マシンＶＭ２とクラウドノードＶＣ１との間に設定された関連の情報と、探索の開始点の異常の情報を含む。
【００９６】
アプリケーションＡｐｐ４は、サービスＳＶＣ１から辿ることが出来るが、異常が発生していないため評点は求めない。アプリケーションＡｐｐ４から辿ることの出来る構成要素は、仮想マシンＶＭ３であり、仮想マシンＶＭ３からさらに関連を辿ると、クラウドノードＶＣ１に至る。探索装置１３は、仮想マシンＶＭ３から関連を辿ってクラウドノードＶＣ１に到達した場合に探索装置２３に対してクエリＱ２３を発行する。このクエリＱ２３は、仮想マシンＶＭ３とクラウドノードＶＣ１との間に設定された関連の情報と、探索の開始点の異常の情報を含む。
【００９７】
探索装置１３が発行するクエリＱ２１〜２３は、開始点が同じ異常探索処理の中で発行されるクエリとして、クエリの識別情報は、同じ識別情報（例えば、クエリＩＤ１００）を使用することができる。
【００９８】
探索装置２３は、クエリＱ２１〜２３を受けて第２の管理範囲２０内での異常の起点候補の探索を行なう。具体的には、クエリＱ２１〜２３に指定された仮想マシンＶＭ１〜ＶＭ３との関連をそれぞれ開始点として関連を辿って異常の起点候補を探索する。クエリＱ２１は、仮想マシンＶＭ１と物理マシンＰＭ２との関連を指定している。クエリＱ２２は、仮想マシンＶＭ２と物理マシンＰＭ２との関連を指定している。クエリＱ２３は、仮想マシンＶＭ３と物理マシンＰＭ３との関連を指定している。
【００９９】
好ましくは、第１の管理範囲側では、仮想マシンＶＭ１〜３が第２の管理範囲のどの構成要素と接続されているか管理しておらず、ＶＭ１〜３と第２の管理範囲の何らかの構成要素との接続関係の識別情報（例えばｒ０１〜０３）との関係をＣＭＤＢに記憶しておき、クエリＱ２１〜２３には、この識別情報ｒ０１〜０３を含める。第２の管理範囲側では、物理マシンＰＭ２〜３が第１の管理範囲のどの構成要素と接続されているか管理しておらず、物理マシンＰＭ２と第１の管理範囲の何らかの構成要素との接続関係の識別情報（例えばｒ０１〜０３）との関係をＣＭＤＢに記憶しているため、クエリに含まれる識別情報ｒ０１〜０３に基づいて、物理マシンＰＭ２〜３を特定して、異常の起点の探索を行うことができる。
【０１００】
探索装置２３がクエリＱ２１に基づいて探索を開始し、関連をたどると、物理マシンＰＭ２、スイッチＳＷ２、ルータＲＴ２に至る。探索装置２３は、スイッチＳＷ２についてエラーＥ２が障害ＤＢ２２に登録されていることから、仮想マシンＶＭ１を開始点に発行されたクエリＱ２１について評点１を付し、スイッチＳＷ２をダミーの構成要素ＶＣ００１に置き換えてクエリＱ２１に対して応答する。
【０１０１】
探索装置２３がクエリＱ２２に基づいて探索を開始し、関連をたどると、物理マシンＰＭ２、スイッチＳＷ２、ルータＲＴ２に至る。探索装置２３は、スイッチＳＷ２についてエラーＥ２が障害ＤＢ２２に登録されていることから、仮想マシンＶＭ２を開始点に発行されたクエリＱ２２について評点１を付し、スイッチＳＷ２をダミーの構成要素ＶＣ００１に置き換えてクエリＱ２２に対して応答する。
【０１０２】
探索装置２３がクエリＱ２３に基づいて探索を開始し、関連をたどると、物理マシンＰＭ３、スイッチＳＷ２、ルータＲＴ２に至る。探索装置２３は、スイッチＳＷ２についてエラーＥ２が障害ＤＢ２２に登録されていることから、仮想マシンＶＭ３を開始点に発行されたクエリＱ２３について評点１を付し、スイッチＳＷ２をダミーの構成要素ＶＣ００１に置き換えてクエリＱ２３に対して応答する。
【０１０３】
探索装置２３は、クエリＱ２１〜２３に対する応答から、仮想マシンＶＭ〜３の上流に構成要素ＶＣ００１が存在し、構成要素ＶＣ００１の第２の管理範囲内での評点が１であることを認識する。そこで、探索装置２３は、構成要素ＶＣ００１の第２の管理範囲内での評点１に、下流側の評点を加算して構成要素ＶＣ００１とする。
【０１０４】
従って、構成要素ＶＣ００１の第２の管理範囲内での評点１に、仮想マシンＶＭ１の評点５、仮想マシンＶＭ２の評点３、仮想マシンＶＭ３の下流に位置するサービスＳＶＣ１の評点１を加算し（１＋５＋３＋１）、構成要素ＶＣ００１の合計評点は１０となる。
【０１０５】
このように、図１４に示した例において、サービスＳＶＣ１を開始点として探索を行なうと、ダミー構成要素ＶＣ００１が最も上流で異常が発生している構成要素であるので、ダミー構成要素ＶＣ００１（評点１０）が異常の起点候補となる。
【０１０６】
また、サービスＳＶＣ１を開始点として探索を行なう過程で、他に異常が発生した構成要素であるアプリケーションＡｐｐ１〜３、仮想マシンＶＭ１〜２の評価を行なったので、アプリケーションＡｐｐ１〜３、仮想マシンＶＭ１〜２を開始点とする探索は不要となる。このため、図１４に示した例では、探索装置１３はダミー構成要素ＶＣ００１（評点１０）を異常の起点候補とする。
【０１０７】
この結果は、ダミー構成要素ＶＣ００１が異常の起点である可能性が高いこと、すなわち異常の責任が第２の管理範囲側にある可能性が高いことを示している。
【０１０８】
図１４に示した例では、異常の起点候補は１つとなったが、異常の起点候補が複数となった場合には、探索装置１３は複数の起点候補を評点とともに出力する。例えば、複数の異常が同時に発生した場合や、実際の起点が１つであっても探索で候補を絞りきれない場合には複数の起点候補が出力されることとなる。なお、評点の算出は、異常の起点としての確からしさを数値化する他の手法を用いてもよい。また、異常が発生していない構成要素についても異常の起点候補として評点を与える手法を用いても良い。
【０１０９】
・プログラムによる実施
図１５は、コンピュータを探索装置として動作させる場合の説明図である。図１５に示したコンピュータ５０は、バス５１にＣＰＵ（Central Processing Unit）５２、ＲＯＭ（Read Only Memory）５３、ＲＡＭ（Random Access Memory）５４、ＮＩＣ（Network Interface Card）５５、ＨＤＤ（Hard Disk Drive）５６を接続した構成を有する。
【０１１０】
ＲＯＭ５３は、関連探索プログラム６１、評価プログラム６２、仮想構成管理プログラム６３、クエリ処理プログラム６４、境界判定プログラム６５、クエリ発行プログラム６６を保持する。タンジブル(tangible)な記録媒体の例としてＲＯＭ５３を例に挙げた、ＨＤＤや、ＲＡＭ、ＣＤＲＯＭ等の他のタンジブルなコンピュータ読み取り可能な記録媒体に各種プログラムを格納しておき、コンピュータに読み取らせることとしてもよい。なお、タンジブルな記憶媒体を遠隔地に配置し、コンピュータが、そのタンジブルな記憶媒体にアクセスすることでプログラムを取得して利用してもよい、また、その際、取得したプログラムをそのコンピュータ自身のタンジブルな記録媒体に格納して用いてもよい。
【０１１１】
ＣＰＵ５２は、関連探索プログラム６１を読み出して実行することで、関連探索部３２と同様の動作を関連探索プロセス７１として実現する。また、ＣＰＵ５２は、評価プログラム６２を読み出して実行することで、評価部３７と同様の動作を評価プロセス７２として実現する。ＣＰＵ５２は、仮想構成管理プログラム６３を読み出して実行することで、仮想構成管理部３６と同様の動作を仮想構成管理プロセス７３として実現する。ＣＰＵ５２は、クエリ処理プログラム６４を読み出して実行することで、クエリ処理部３５と同様の動作をクエリ処理プロセス７４として実現する。ＣＰＵ５２は、境界判定プログラム６５を読み出して実行することで、境界判定部３３と同様の動作を境界判定プロセス７５として実現する。ＣＰＵ５２は、クエリ発行プログラム６６を読み出して実行することで、クエリ発行部３４と同様の動作をクエリ発行プロセス７６として実現する。
【０１１２】
このようにＲＯＭ５３に保持した各種プログラムは、探索プログラムの一部として機能し、コンピュータ５０は、ＲＯＭ５３から各種プログラムを読み出して実行することで探索方法を実行する探索装置として動作する。
【０１１３】
・３以上のドメインを有する構成
これまでの説明では第１の管理範囲と第２の管理範囲を有するネットワークシステムを例示して説明を行なったが、３以上の管理範囲を有するネットワークシステムにおいても開示の技術は適用可能である。
【０１１４】
図１６は、３つの管理範囲を有するネットワークシステムについての説明図である。図１６に示した構成では、第２の管理範囲に対応する第２ドメイン側システム２０ａは、第１の管理範囲に対応する第１ドメイン側システム１０ａと第３の管理範囲に対応する第３ドメイン側システム１０ｂに接続されている。
【０１１５】
第２ドメイン側システム２０ａは、探索装置２３ａ、ＣＭＤＢ２１、障害ＤＢ２２、ＣＩ−ＶＣＩ対応表２４ａ，２４ｂを有する。また、探索装置２３ａは、第１ドメイン側システム１０ａと第３ドメイン側システム１０ｂがそれぞれ有する探索装置と接続されている。
【０１１６】
ＣＭＤＢ２１は、第２のドメインにおける構成要素の接続情報を保持する。障害ＤＢ２２は、第２ドメイン内で発生した障害の情報を保持する。ＣＩ−ＶＣＩ対応表２４ａは、第１ドメイン側システム１０ａからのクエリに応答する際に使用するダミーの構成要素と実際の構成要素との対応関係を保持する。ＣＩ−ＶＣＩ対応表２４ｂは、第３ドメイン側システム１０ｂからのクエリに応答する際に使用するダミーの構成要素と実際の構成要素との対応関係を保持する。
【０１１７】
このように、ドメインごとにＣＩ−ＶＣＩ対応表を個別に管理すると、同じクエリＩＤであっても同じ構成要素に対して異なるＶＣＩを設定することも可能となり、第２のドメインの構成が露呈することを抑制することができる。
【０１１８】
なお、ＣＩ−ＶＣＩ対応表が単一であっても、ドメイン毎に使用を許容するクエリＩＤの候補を別個として、クエリ応答の重ね合わせによる構成情報の推測を回避することができる。クエリＩＤを各ドメインで共用する場合、異なるドメインからの同じクエリＩＤを付したクエリの送信により、共通する構成要素について、共通したダミーの構成要素情報が応答として送信されてしまう。すると、異なるドメイン間で応答を重ね合わせることで、第２のドメインの構成が露呈していくこととなるが、ドメイン毎に使用を許容するクエリＩＤの候補を別個とすると、そのような事態を回避することができる。
【０１１９】
・実施例２のまとめ
上述してきたように、本実施例２にかかる探索装置、探索方法および探索プログラムは、システムに発生した異常の起点の候補を評価することができる。
【０１２０】
また、本実施例２にかかる探索装置は、他の探索装置からのクエリに対してはダミーの構成要素を返すことで自ドメインの構成を仮想化する。このため、探索装置は、自ドメインの実際の構成を秘匿して仮想的な構成で異常の起点候補を他の探索装置に通知することができる。したがって、各ドメインの構成を互いに知らせることなく異常の起点である構成要素を推定し、発生した異常の起点がどのドメインにあるかを調査することができる。
【０１２１】
なお、実施例に開示の装置、方法およびプログラムはあくまで一例であり、構成および動作を適宜変更して実施することができる。例えば、実施例２に開示した装置は、各処理部をネットワークシステム上に分散して配置し、探索システムとして実施することができる。
【符号の説明】
【０１２２】
１，２，１３，２３，２３ａ 探索装置
３，６ 探索部
４ クエリ発行部
５，７ 評価部
８ クエリ処理部
９ ダミー処理部
１０ａ 第１ドメイン側システム
１０ｂ 第３ドメイン側システム
１０，２０ 管理範囲
１１，２１ ＣＭＤＢ
１２，２２ 障害ＤＢ
１４，２４，２４ａ，２４ｂ ＣＩ−ＶＣＩ対応表
２０ａ 第２ドメイン側システム
３１ ユーザインタフェース
３２ 関連探索部
３３ 境界判定部
３４ クエリ発行部
３５ クエリ処理部
３６ 仮想構成管理部
３７ 評価部
４１，４２ システム
５０ コンピュータ
５１ バス
５２ ＣＰＵ
５３ ＲＯＭ
５４ ＲＡＭ
５５ ＮＩＣ
５６ ＨＤＤ
６１ 関連探索プログラム
６２ 評価プログラム
６３ 仮想構成管理プログラム
６４ クエリ処理プログラム
６５ 境界判定プログラム
６６ クエリ発行プログラム
７１ 関連探索プロセス
７２ 評価プロセス
７３ 仮想構成管理プロセス
７４ クエリ処理プロセス
７５ 境界判定プロセス
７６ クエリ発行プロセス
Ａｐｐ１〜４，１１〜１６ アプリケーション
Ｃ１１〜１６ 構成要素
ｎｗ１１，１２ ネットワーク
ＰＭ１〜３ 物理マシン
ｐｍ１１〜１３ サーバ
ＲＴ１，２ ルータ
Ｓｖ１１，ＳＶＣ１ サービス
ＳＷ１，２ スイッチ
ＶＣ１ クラウドノード
ＶＭ１〜３，ＶＭ１１〜１６ 仮想マシン
【特許請求の範囲】
【請求項１】
ネットワークの構成要素のうち、第１の管理範囲に属する構成要素に発生した異常について、前記異常が発生した構成要素の接続関係を辿って前記異常の起点となった構成要素の候補を前記異常の起点候補として探索する探索部と、
前記探索部が辿った先の構成要素が第２の管理範囲に属する構成要素である場合に、前記第２の管理範囲における異常の起点候補を探索する装置に対して前記異常の起点候補の探索を依頼するクエリを発行するクエリ発行部と、
前記探索部による探索結果と前記クエリに対する応答とに基づいて、前記異常の起点候補を評価する評価部と
を備えたことを特徴とする探索装置。
【請求項２】
ネットワークの構成要素のうち第１の管理範囲に属する構成要素における異常の起点候補を探索する装置から、第２の管理範囲に属する異常の起点候補の探索を依頼するクエリを受信するクエリ処理部と、
前記クエリに基づいて前記第２の管理範囲に属する構成要素の接続関係を辿って前記異常の起点となった構成要素の候補を前記異常の起点候補として探索する探索部と、
前記探索部による探索結果に基づいて前記異常の起点候補を評価する評価部と、
前記探索部が探索した前記異常の起点候補である構成要素をダミーの構成要素に置き換えるダミー処理部と
を備え、
前記クエリ処理部は、前記ダミーの構成要素と前記評価部による評価結果とを前記クエリに対する応答として返すことを特徴とする探索装置。
【請求項３】
前記クエリは、同一の異常について同一の識別情報を有し、前記ダミー処理部は、同一の識別情報を有するクエリに対して、前記異常の起点候補である構成要素を同一のダミーの構成要素に置き換えることを特徴とする請求項２に記載の探索装置。
【請求項４】
前記ダミー処理部は、前記第１の管理範囲からのクエリに応答する際に使用する異常の起点候補である構成要素とダミーの構成要素との対応関係と、第３の管理範囲からのクエリに応答する際に使用する異常の起点候補である構成要素とダミーの構成要素との対応関係とを個別に管理することを特徴とする請求項２または３に記載の探索装置。
【請求項５】
ネットワークの構成要素のうち、第１の管理範囲に属する構成要素に発生した異常について、前記異常が発生した構成要素の接続関係を辿って前記異常の起点となった構成要素の候補を前記異常の起点候補として探索する探索ステップと、
前記探索ステップが辿った先の構成要素が第２の管理範囲に属する構成要素である場合に、前記第２の管理範囲における異常の起点候補を探索する装置に対して前記異常の起点候補の探索を依頼するクエリを発行するクエリ発行ステップと、
前記探索ステップによる探索結果と前記クエリに対する応答とに基づいて、前記異常の起点候補を評価する評価ステップと
を含んだことを特徴とする探索方法。
【請求項６】
ネットワークの構成要素のうち第１の管理範囲に属する構成要素における異常の起点候補を探索する装置から、第２の管理範囲に属する異常の起点候補の探索を依頼するクエリを受信するステップと、
前記クエリに基づいて前記第２の管理範囲に属する構成要素の接続関係を辿って前記異常の起点となった構成要素の候補を前記異常の起点候補として探索する探索ステップと、
前記探索ステップによる探索結果に基づいて前記異常の起点候補を評価する評価ステップと、
前記探索ステップが探索した前記異常の起点候補である構成要素をダミーの構成要素に置き換えるステップと、
前記ダミーの構成要素と前記評価ステップによる評価結果とを前記クエリに対して応答として返すステップと、
を含んだことを特徴とする探索方法。
【請求項７】
ネットワークの構成要素のうち、第１の管理範囲に属する構成要素に発生した異常について、前記異常が発生した構成要素の接続関係を辿って前記異常の起点となった構成要素の候補を前記異常の起点候補として探索する探索手順と、
前記探索手順が辿った先の構成要素が第２の管理範囲に属する構成要素である場合に、前記第２の管理範囲における異常の起点候補を探索する装置に対して前記異常の起点候補の探索を依頼するクエリを発行するクエリ発行手順と、
前記探索手順による探索結果と前記クエリに対する応答とに基づいて、前記異常の起点候補を評価する評価手順と
をコンピュータに実行させることを特徴とする探索プログラム。
【請求項８】
ネットワークの構成要素のうち第１の管理範囲に属する構成要素における異常の起点候補を探索する装置から、第２の管理範囲に属する異常の起点候補の探索を依頼するクエリを受信する手順と、
前記クエリに基づいて前記第２の管理範囲に属する構成要素の接続関係を辿って前記異常の起点となった構成要素の候補を前記異常の起点候補として探索する探索手順と、
前記探索手順による探索結果に基づいて前記異常の起点候補を評価する評価手順と、
前記探索手順が探索した前記異常の起点候補である構成要素をダミーの構成要素に置き換える手順と、
前記ダミーの構成要素と前記評価手順による評価結果とを前記クエリに対する応答として返す手順と、
をコンピュータに実行させることを特徴とする探索プログラム。
【請求項１】
ネットワークの構成要素のうち、第１の管理範囲に属する構成要素に発生した異常について、前記異常が発生した構成要素の接続関係を辿って前記異常の起点となった構成要素の候補を前記異常の起点候補として探索する探索部と、
前記探索部が辿った先の構成要素が第２の管理範囲に属する構成要素である場合に、前記第２の管理範囲における異常の起点候補を探索する装置に対して前記異常の起点候補の探索を依頼するクエリを発行するクエリ発行部と、
前記探索部による探索結果と前記クエリに対する応答とに基づいて、前記異常の起点候補を評価する評価部と
を備えたことを特徴とする探索装置。
【請求項２】
ネットワークの構成要素のうち第１の管理範囲に属する構成要素における異常の起点候補を探索する装置から、第２の管理範囲に属する異常の起点候補の探索を依頼するクエリを受信するクエリ処理部と、
前記クエリに基づいて前記第２の管理範囲に属する構成要素の接続関係を辿って前記異常の起点となった構成要素の候補を前記異常の起点候補として探索する探索部と、
前記探索部による探索結果に基づいて前記異常の起点候補を評価する評価部と、
前記探索部が探索した前記異常の起点候補である構成要素をダミーの構成要素に置き換えるダミー処理部と
を備え、
前記クエリ処理部は、前記ダミーの構成要素と前記評価部による評価結果とを前記クエリに対する応答として返すことを特徴とする探索装置。
【請求項３】
前記クエリは、同一の異常について同一の識別情報を有し、前記ダミー処理部は、同一の識別情報を有するクエリに対して、前記異常の起点候補である構成要素を同一のダミーの構成要素に置き換えることを特徴とする請求項２に記載の探索装置。
【請求項４】
前記ダミー処理部は、前記第１の管理範囲からのクエリに応答する際に使用する異常の起点候補である構成要素とダミーの構成要素との対応関係と、第３の管理範囲からのクエリに応答する際に使用する異常の起点候補である構成要素とダミーの構成要素との対応関係とを個別に管理することを特徴とする請求項２または３に記載の探索装置。
【請求項５】
ネットワークの構成要素のうち、第１の管理範囲に属する構成要素に発生した異常について、前記異常が発生した構成要素の接続関係を辿って前記異常の起点となった構成要素の候補を前記異常の起点候補として探索する探索ステップと、
前記探索ステップが辿った先の構成要素が第２の管理範囲に属する構成要素である場合に、前記第２の管理範囲における異常の起点候補を探索する装置に対して前記異常の起点候補の探索を依頼するクエリを発行するクエリ発行ステップと、
前記探索ステップによる探索結果と前記クエリに対する応答とに基づいて、前記異常の起点候補を評価する評価ステップと
を含んだことを特徴とする探索方法。
【請求項６】
ネットワークの構成要素のうち第１の管理範囲に属する構成要素における異常の起点候補を探索する装置から、第２の管理範囲に属する異常の起点候補の探索を依頼するクエリを受信するステップと、
前記クエリに基づいて前記第２の管理範囲に属する構成要素の接続関係を辿って前記異常の起点となった構成要素の候補を前記異常の起点候補として探索する探索ステップと、
前記探索ステップによる探索結果に基づいて前記異常の起点候補を評価する評価ステップと、
前記探索ステップが探索した前記異常の起点候補である構成要素をダミーの構成要素に置き換えるステップと、
前記ダミーの構成要素と前記評価ステップによる評価結果とを前記クエリに対して応答として返すステップと、
を含んだことを特徴とする探索方法。
【請求項７】
ネットワークの構成要素のうち、第１の管理範囲に属する構成要素に発生した異常について、前記異常が発生した構成要素の接続関係を辿って前記異常の起点となった構成要素の候補を前記異常の起点候補として探索する探索手順と、
前記探索手順が辿った先の構成要素が第２の管理範囲に属する構成要素である場合に、前記第２の管理範囲における異常の起点候補を探索する装置に対して前記異常の起点候補の探索を依頼するクエリを発行するクエリ発行手順と、
前記探索手順による探索結果と前記クエリに対する応答とに基づいて、前記異常の起点候補を評価する評価手順と
をコンピュータに実行させることを特徴とする探索プログラム。
【請求項８】
ネットワークの構成要素のうち第１の管理範囲に属する構成要素における異常の起点候補を探索する装置から、第２の管理範囲に属する異常の起点候補の探索を依頼するクエリを受信する手順と、
前記クエリに基づいて前記第２の管理範囲に属する構成要素の接続関係を辿って前記異常の起点となった構成要素の候補を前記異常の起点候補として探索する探索手順と、
前記探索手順による探索結果に基づいて前記異常の起点候補を評価する評価手順と、
前記探索手順が探索した前記異常の起点候補である構成要素をダミーの構成要素に置き換える手順と、
前記ダミーの構成要素と前記評価手順による評価結果とを前記クエリに対する応答として返す手順と、
をコンピュータに実行させることを特徴とする探索プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【公開番号】特開２０１１−２５３２１２（Ｐ２０１１−２５３２１２Ａ）
【公開日】平成２３年１２月１５日（２０１１．１２．１５）
【国際特許分類】
【出願番号】特願２０１０−１２４５７７（Ｐ２０１０−１２４５７７）
【出願日】平成２２年５月３１日（２０１０．５．３１）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成２３年１２月１５日（２０１１．１２．１５）
【国際特許分類】
【出願日】平成２２年５月３１日（２０１０．５．３１）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]