JP7032251B2 - 障害影響範囲の推論装置、障害原因の推論装置、障害影響範囲の推論方法、障害原因の推論方法、及びプログラム - Google Patents

Description

本開示は、ネットワークオントロジを利用した障害影響範囲と障害原因の推論手法に関する。

サーバやネットワークの仮想化技術によりネットワーク構成が複雑化している。大規模で動的なシステムではネットワーク管理者がシステム全体を正確に把握することが難しく、障害の原因や影響範囲を突き止めるコストが増大している。その結果、障害原因推論の自動化への需要が高まっている。

非特許文献１は、オントロジによってモデル化したＩＴシステム構成に対して汎用解析ルールを適用し、障害の根本原因を推論する。１つの汎用解析ルールは条件部と結論部からなる。条件部で指定する条件には、ＩＴ装置とその装置を構成するリソースの種別、そのリソースから生成されるイベント種別を指定する。結論部には、解析の結果として装置種別とそのリソースの種別、そのリソースから生成されるイベントの種別を記述する。このように定義することにより、汎用解析ルールはトポロジに対して条件を記述でき、また障害イベントの共起条件を記述できる。

非特許文献２は、システム構成要素間の異常情報の伝搬の仕方をオントロジで表現している。この手法では依存関係を導出するルールと状態伝搬に関するルールという２種類のルールを使用する。影響範囲推論の場合、原因となる構成要素から順にルールを展開し、状態を伝搬させていくことで影響を受ける構成要素を見つけることができる。障害原因推論の場合、すべての依存関係や状態伝搬ルールを展開し、システム内を異常状態が伝播するすべての経路を計算する。その上で現在発生している障害状態を含む経路のみを抽出することで、原因候補の構成要素を列挙することができる。

特許５８４５１３３号

工藤裕， 森村知弘， 菅内公徳， 増石哲也， 薦田憲久． 障害原因解析のためのルール構築方法と解析実行方式． 電気学会論文誌Ｃ， Ｖｏｌ． １３２， Ｎｏ． １０， ｐｐ． １６８９－１６９７， ２０１２． Ｈ． Ｄｉｈｏｗｓｋｉ， Ｏ． Ｈｏｌｕｂ， ａｎｄ Ｊ． Ｒｏｊｃｅｋ． Ｋｎｏｗｌｅｄｇｅ－Ｂａｓｅｄ Ｆａｕｌｔ Ｐｒｏｐａｇａｔｉｏｎ ｉｎ Ｂｕｉｌｄｉｎｇ Ａｕｔｏｍａｔｉｏｎ Ｓｙｓｔｅｍ． Ｉｎ Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ２０１６ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｎｅｃｅ ｏｎ Ｓｙｓｔｅｍｓ Ｉｎｆｏｒｍａｔｉｃｓ， Ｍｏｄｅｌｌｉｎｇ ａｎｄ Ｓｉｍｕｌａｔｉｏｎ （ＳＩＭＳ）， ｐｐ． １２４－１３２， Ｊｕｎｅ ２０１６． 三上啓， 川口慎司， 大島涼太， 島松健太， 近藤賢郎， 鎌谷修， 明石修， 金子晋丈， 寺岡文男． ネットワークオントロジＢｏｎｓａｉを利用したネットワーク管理手法に関する一検討． 信学技報ＩＮ２０１６－８６）， Ｊａｎｕａｒｙ ２０１７． 川口慎司，「ＫＡＮＶＡＳ： ネットワーク知識の活用に向けたオントロジを利用したオープンな情報共有基盤」，慶應義塾大学大学院理工学研究科開放環境科学専攻 修士論文，２０１６年３月．

非特許文献１の方式は、障害原因推論のみを対象としており、障害影響範囲推論を考慮していない。非特許文献２の方式は、障害原因推論と障害影響範囲推論が実現されているが、そのためにはすべてのルールをシステム構成にあわせてあらかじめ展開しておく必要がある。このため、非特許文献２の方式には、解析対象のシステムが大規模化及び複雑化すると、構成要素数や推論ルール数が増加するため、あらかじめ障害伝搬経路を計算しておくことが困難という第１の課題があった。

また、いずれの文献の方式も障害原因推論が可能であるが、示された原因候補を人手によって検証する必要があり、障害原因の絞り込みが困難という第２の課題があった。

そこで、本発明は、上記第１の課題を解決するために、解析対象のシステムが大規模化及び複雑化しても全ての障害伝搬経路を予め計算することを不要とできる障害影響範囲の推論装置、障害原因の推論装置、障害影響範囲の推論方法、障害原因の推論方法、及びプログラムを提供することを目的とする。
また、本発明は、上記第２の課題を解決するために、障害原因の自動的な絞り込みが可能である障害原因の推論装置、障害原因の推論方法、及びプログラムを提供することも目的とする。

上記目的を達成するために、本発明に係る障害影響範囲の推論装置及びその方法は、ネットワーク構成情報に応じた依存関係ルールと状態伝搬ルールを展開して保持しておくこととした。

具体的には、本発明に係る障害影響範囲の推論装置は、
ネットワークを構成する複数の要素のうち、互いの状態が依存し合う関係にある２つの要素の依存関係を記載した依存関係ルール、及び前記２つの要素の間で伝搬する状態の内容を記載した状態伝搬ルールが設定される設定手段と、
前記ネットワークの構成についての情報を収集し、前記ネットワークの構成に応じた前記依存関係ルールを抽出して保管する保管手段と、
前記要素についての故障情報が入力されたときに、保管されている前記依存関係ルールから状態に影響がある前記要素を選び出し、選び出された前記要素に基づいて前記状態伝搬ルールを検出し、前記故障情報で影響を受ける前記要素の範囲を推定する範囲推定手段と、
を備える。

また、本発明に係る障害影響範囲の推論方法は、
ネットワークを構成する複数の要素のうち、互いの状態が依存し合う関係にある２つの要素の依存関係を記載した依存関係ルール、及び前記２つの要素の間で伝搬する状態の内容を記載した状態伝搬ルールを設定する設定手順と、
前記ネットワークの構成についての情報を収集し、前記ネットワークの構成に応じた前記依存関係ルールを抽出して保管する保管手順と、
前記要素についての故障情報が入力されたときに、保管されている前記依存関係ルールから状態に影響がある前記要素を選び出し、選び出された前記要素に基づいて前記状態伝搬ルールを検出し、前記故障情報で影響を受ける前記要素の範囲を推定する範囲推定手順と、
を行う。

本発明に係る障害影響範囲の推論装置は、推定した前記要素の範囲のうち、ネットワークのサービスに関する影響を入力された前記故障情報の応答とする故障情報応答手段をさらに備えてもよい。

一方、本発明に係る障害原因の推論装置は、
ネットワークを構成する複数の要素のうち、互いの状態が依存し合う関係にある２つの要素の依存関係を記載した依存関係ルール、及び前記２つの要素の間で伝搬する状態の内容を記載した状態伝搬ルールが設定される設定手段と、
前記ネットワークの構成についての情報を収集し、前記ネットワークの構成に応じた前記依存関係ルールを抽出して保管する保管手段と、
前記ネットワークについての障害状況が入力されたときに、保管されている前記依存関係ルールから前記障害状況に関連する１又は複数の前記要素を選び出すとともに、選び出された前記要素が取り得る１又は複数の状態を検索し、選び出された前記要素と検索した前記状態に基づいて前記状態伝搬ルールを検出し、前記障害状況の原因となる前記要素と該要素の状態のリストを推定する原因推定を行う原因推定手段と、
を備える。

また、本発明に係る障害原因の推論方法は、
ネットワークを構成する複数の要素のうち、互いの状態が依存し合う関係にある２つの要素の依存関係を記載した依存関係ルール、及び前記２つの要素の間で伝搬する状態の内容を記載した状態伝搬ルールを設定する設定手順と、
前記ネットワークの構成についての情報を収集し、前記ネットワークの構成に応じた前記依存関係ルールを抽出して保管する保管手順と、
前記ネットワークについての障害状況が入力されたときに、保管されている前記依存関係ルールから前記障害状況に関連する１又は複数の前記要素を選び出すとともに、選び出された前記要素が取り得る１又は複数の状態を検索し、選び出された前記要素と検索した前記状態に基づいて前記状態伝搬ルールを検出し、前記障害状況の原因となる前記要素と該要素の状態のリストを推定する原因推定手順と、
を行う。

本障害影響範囲の推論手法及び本障害原因の推論手法は、対象のネットワークの構造を定期的に収集し、その構造の変化に応じた依存関係ルールと状態伝搬ルールのみを展開して保持している。このため、全ての障害伝搬経路を予め計算することが不要である。従って、本発明は、解析対象のシステムが大規模化及び複雑化しても全ての障害伝搬経路を予め計算することを不要とできる障害影響範囲の推論装置、障害原因の推論装置、障害影響範囲の推論方法、及び障害原因の推論方法を提供することができる。

本発明に係る障害原因の推論装置は、前記原因推定手段に前記障害状況に類似する他の障害状況を仮定して前記原因推定を行わせ、前記他の障害状況の原因となる前記要素と該要素の状態の他のリストを推定し、前記リストと前記他のリストに共通する項目を前記リストから除外した結果を、入力された前記障害状況の応答とする障害状況応答手段をさらに備えてもよい。

本障害原因の推論装置は、仮定の障害状況に基づいて原因推定を行い、現状の原因推定と比較を行うことで障害原因を自動的に絞り込むこととした。従って、本発明は、障害原因の自動的な絞り込みが可能である障害原因の推論装置、及び障害原因の推論方法を提供することができる。

本発明に係るプログラムは、前記障害影響範囲の推論装置、あるいは前記障害原因の推論装置としてコンピュータを機能させるためのプログラムである。本発明に係る障害影響範囲の推論装置及び障害原因の推論装置はコンピュータとプログラムによっても実現でき、プログラムを記録媒体に記録することも、ネットワークを通して提供することも可能である。

本発明は、解析対象のシステムが大規模化及び複雑化しても全ての障害伝搬経路を予め計算することを不要とできる障害影響範囲の推論装置、障害原因の推論装置、障害影響範囲の推論方法、障害原因の推論方法、及びプログラムを提供することができる。
また、本発明は、障害原因の自動的な絞り込みが可能である障害原因の推論装置、障害原因の推論方法、及びプログラムを提供することもできる。

本発明に係る障害影響範囲の推論装置及び障害原因の推論装置を説明するブロック図である。 ネットワークオントロジＢｏｎｓａｉの全体構造を説明する構成図である。 ネットワークの例をＩＰレベルで説明する図である。 ＩＰネットワーク構成を説明するインスタンス図である。 ネットワークの例を物理レベルで説明する図である。 物理ネットワーク構成を説明するインスタンス図である。 ネットワークサービス構成を説明するインスタンス図である。 スイッチ３の物理ネットワーク構成におけるインスタンス表現を説明する図である。 スイッチ３の上流インタフェースの物理ネットワーク構成におけるインスタンス表現を説明する図である。 ルータ３とスイッチ３間のリンクの物理ネットワーク構成におけるインスタンス表現を説明する図である。 スイッチ３とホスト２間のリンクの物理ネットワーク構成におけるインスタンス表現を説明する図である。 ルータ３とスイッチ３間のリンクの論理ネットワーク構成におけるインスタンス表現を説明する図である。 ＩＰネットワーク構成におけるサブネット３のインスタンス表現を説明する図である。 ホスト２からＷｅｂサーバへの通信経路のインスタンス表現を説明する図である。 ホスト３のＩＰネットワーク構成におけるインスタンス表現を説明する図である。 ホスト３のＩＰネットワーク構成におけるインスタンス表現を説明する図である。 ネットワークサービス構成におけるＷＥＢサービスのインスタンス表現を説明する図である。 依存関係ルール１（ＰｈｙｓｉｃａｌＮｏｄｅ －＞ ＰｈｙｓｉｃａｌＩｎｔｅｒｆａｃｅ）を説明する図である。 依存関係ルール２（ＰｈｙｓｉｃａｌＩｎｔｅｒｆａｃｅ －＞ ＰｈｙｓｉｃａｌＬｉｎｋ）を説明する図である。 依存関係ルール３（ＰｈｙｓｉｃａｌＬｉｎｋ －＞ ＬｏｇｉｃａｌＬｉｎｋ）を説明する図である。 依存関係ルール４（ＬｏｇｉｃａｌＬｉｎｋ －＞ ＩＰＳｕｂｎｅｔ）を説明する図である。 依存関係ルール５（ＩＰＳｕｂｎｅｔ －＞ ＩＰＰａｔｈ）を説明する図である。 依存関係ルール６（ＩＰＰａｔｈ －＞ ＮｅｔｗｏｒｋＳｅｒｖｉｃｅ）を説明する図である。 状態伝搬ルール１（ＰｈｙｓｉｃａｌＮｏｄｅ －＞ ＰｈｙｓｉｃａｌＩｎｔｅｒｆａｃｅ）を説明する図である。 状態伝搬ルール２（ＰｈｙｓｉｃａｌＩｎｔｅｒｆａｃｅ －＞ ＰｈｙｓｉｃａｌＬｉｎｋ）を説明する図である。 状態伝搬ルール３（ＰｈｙｓｉｃａｌＬｉｎｋ －＞ ＬｏｇｉｃａｌＬｉｎｋ）を説明する図である。 状態伝搬ルール４（ＬｏｇｉｃａｌＬｉｎｋ －＞ ＩＰＳｕｂｎｅｔ）を説明する図である。 状態伝搬ルール５ （ＩＰＳｕｂｎｅｔ －＞ ＩＰＰａｔｈ）を説明する図である。 状態伝搬ルール６（ＩＰＰａｔｈ －＞ ＮｅｔｗｏｒｋＳｅｒｖｉｃｅ）を説明する図である。 依存関係ルール適用後のスイッチ３の物理ネットワーク構成におけるインスタンス表現を説明する図である。 依存関係ルール適用後のスイッチ３の上流インタフェースの物理ネットワーク構成におけるインスタンス表現を説明する図である。 依存関係ルール適用後のルータ３とスイッチ３間のリンクの物理ネットワーク構成におけるインスタンス表現を説明する図である。 依存関係ルール適用後のルータ３とスイッチ３間のリンクの論理ネットワーク構成におけるインスタンス表現を説明する図である。 依存関係ルール適用後のＩＰネットワーク構成におけるサブネット３のインスタンス表現を説明する図である。 依存関係ルール適用後のホスト２からＷｅｂサーバへの通信経路のインスタンス表現を説明する図である。 本発明に係る障害影響範囲の推論方法を説明する図である。 影響範囲推論ルールを説明する図である。 本発明に係る障害原因の推論方法を説明する図である。 原因推論ルール（１）を説明する図である。 原因推論ルール（２－１）を説明する図である。 原因推論ルール（２－２）を説明する図である。 原因推論ルール（３）を説明する図である。 本発明に係る障害原因の推論方法で使用するＦａｕｌｔＮｏｄｅクラスの例を説明する図である。 本発明に係る障害原因の推論方法における原因絞り込みの例を説明する図である。 本発明に係る障害原因の推論方法における原因絞り込み手順を説明する図である。 フォルトツリーの絞込ルールを説明する図である。 ＫＡＮＶＡＳアーキテクチャの全体像の一例を示す。 ＫＩＧの内部構造の一例を示す。 ＩＰネットワーク構成の一例を示す。 物理ネットワーク構成の一例を示す。 ネットワーク構成検出方法のフローチャートの一例を示す。 ステップＳ１０２終了後に得られたネットワーク構成の一例を示す。 ステップＳ１０３終了後に得られたネットワーク構成の一例を示す。 ステップＳ１０４終了後に得られたネットワーク構成の一例を示す。 ステップＳ１０５終了後に得られたネットワーク構成の一例を示す。 ステップＳ１０６終了後に得られたネットワーク構成の一例を示す。

添付の図面を参照して本発明の実施形態を説明する。以下に説明する実施形態は本発明の実施例であり、本発明は、以下の実施形態に制限されるものではない。なお、本明細書及び図面において符号が同じ構成要素は、相互に同一のものを示すものとする。

本実施形態の推論装置は、
ネットワークを構成する複数の要素のうち、互いの状態が依存し合う関係にある２つの要素の依存関係を記載した依存関係ルール、及び前記２つの要素の間で伝搬する状態の内容を記載した状態伝搬ルールが設定される設定手段と、
前記ネットワークの構成についての情報を収集し、前記ネットワークの構成に応じた前記依存関係ルールを抽出して保管する保管手段と、
前記要素についての故障情報が入力されたときに、保管されている前記依存関係ルールから状態に影響がある前記要素を選び出し、選び出された前記要素に基づいて前記状態伝搬ルールを検出し、前記故障情報で影響を受ける前記要素の範囲を推定する範囲推定手段、又は／及び
前記ネットワークについての障害状況が入力されたときに、保管されている前記依存関係ルールから前記障害状況に関連する１又は複数の前記要素を選び出すとともに、選び出された前記要素が取り得る１又は複数の状態を検索し、選び出された前記要素と検索した前記状態に基づいて前記状態伝搬ルールを検出し、前記障害状況の原因となる前記要素と該要素の状態のリストを推定する原因推定を行う原因推定手段と、
を備えることを特徴とする。
なお、上記の「要素」とは、ネットワークを構成するノード、インターフェース、リンク、経路、サブネット、サービス等を意味する。

１．モジュール構成
図１に本推論装置のブロック図を示す。ネットワーク構成情報収集モジュール１１はネットワークの構成情報を自動的に収集し、これをネットワークオントロジＢｏｎｓａｉに基づくインスタンス表現に変換してネットワーク構成情報ＲＤＦ（Ｒｅｓｏｕｒｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｆｒａｍｅｗｏｒｋ）ストレージに格納する。なお、ネットワーク構成情報収集モジュール１１の具体例は後述する。

ＢｏｎｓａｉはＲＤＦとＯＷＬ（Ｗｅｂ Ｏｎｔｏｌｏｇｙ Ｌａｎｇｕａｇｅ）に基づくドメインオントロジである（非特許文献３）。Ｂｏｎｓａｉによるネットワーク構成オントロジの全体像を図２に示す。Ｂｏｎｓａｉは５階層、６カテゴリから構成される。第１階層は物理ネットワーク構成、第２階層は論理ネットワーク構成、第３階層はＩＰネットワーク構成、第４層はオーバレイネットワーク構成、第５階層にはネットワークサービス構成と運用ネットワーク構成を定義する。ネットワーク構成情報収集モジュール１１は、ネットワーク構成の変化を検出するたびにネットワーク構成情報をネットワーク構成情報ＲＤＦストレージ２１に格納する。

ルール入力モジュール２５は、システム管理者が定義した依存関係ルールと状態伝搬ルールをＳＰＩＮ（ＳＰＡＲＱＬ Ｉｎｆｅｒｅｎｃｉｎｇ Ｎｏｔａｔｉｏｎ）形式に変換し、ＳＰＩＮ依存関係ルールストレージ２２とＳＰＩＮ状態伝搬ルールストレージ２４に格納する。

ＳＰＩＮ推論エンジン１２はネットワーク構成情報ＲＤＦストレージ２１に格納された情報の変更を検出すると、ネットワーク構成情報にＳＰＩＮ依存関係ルールを適用し、その結果を依存関係ルール展開ストレージ２３に格納する。

入出力モジュール２６はシステム利用者からの障害情報を受け取ったり、推論結果をユーザに返すためのインタフェースとなるモジュールである。障害情報には以下の２種類がある。１つはネットワークにおける障害箇所を指定した情報である（障害指定情報）。たとえば「ネットワークスイッチ１が故障した」などの情報である。もう１つは障害状況を記述した情報である（障害状況情報）。たとえば「ホスト１からｗｅｂサーバが閲覧不能」などの情報である。

影響範囲推論モジュール１３は、入出力モジュール２６から障害指定情報を受け取ると、障害指定情報をＢｏｎｓａｉに基づく表現形式に変換して依存関係ルール展開ストレージ２３に問い合わせることで、障害により影響を受ける範囲を推論する。その際、依存関係ルールを一時的に適用した結果を一時的依存関係ルール展開ストレージ２７に蓄える。

障害原因推論モジュール１４は、入出力モジュール２６から障害状況情報を受け取ると、依存関係ルール展開ストレージ２３に問合せて障害状況からの依存関係を逆にたどることで障害の原因を推論し、木構造による障害原因候補を得る。その際、状態伝搬ルールを一時的に適用した結果を一時的状態伝搬ストレージ２８に蓄える。

前記設定手段は、ＳＰＩＮ推論エンジン１２、ルール入力モジュール２５、ＳＰＩＮ依存関係ルールストレージ２２、及びＳＰＩＮ状態伝搬ルールストレージ２４に相当する。前記保管手段は、ネットワーク構成情報収集モジュール１１、ＳＰＩＮ推論エンジン１２、ネットワーク構成情報ＲＤＦストレージ２１、及び依存関係ルール展開ストレージ２３に相当する。前記範囲推定手段は、ＳＰＩＮ推論エンジン１２、影響範囲推論モジュール１３、入出力モジュール２６、依存関係ルール展開ストレージ２３、及び一時的依存関係ルール展開ストレージ２７に相当する。前記原因推定手段は、ＳＰＩＮ推論エンジン１２、障害原因推論モジュール１４、依存関係ルール展開ストレージ２３、及び一時的状態伝搬ストレージ２８に相当する。

本実施形態の推論装置は、前記原因推定手段に前記障害状況に類似する他の障害状況を仮定して前記原因推定を行わせ、前記他の障害状況の原因となる前記要素と該要素の状態の他のリストを推定し、前記リストと前記他のリストに共通する項目を前記リストから除外した結果を、入力された前記障害状況の応答とする障害状況応答手段をさらに備える。
前記障害状況応答手段は、障害原因絞込モジュール１５であり、複数の障害状況情報から推論した複数の障害原因候補から障害原因を絞り込む。

２．ネットワーク構成例
図３に本明細書で例として用いるネットワークのＩＰレベルの構成を示す。図４にこのネットワークのＩＰネットワーク構成をＢｏｎｓａｉに基づくインスタンスとして表した図を示す。図５にこのネットワークの物理レベルの構成を示す。図６にこのネットワークの物理ネットワーク構成をＢｏｎｓａｉに基づくインスタンスとして表した図を示す。図７にホスト３上で動作するｗｅｂサーバ１のネットワークサービス構成をＢｏｎｓａｉに基づくインスタンスとして表した図を示す。論理ネットワーク構成、オーバレイネットワーク構成および運用ネットワーク構成に関するインスタンス図は省略する。

図８にスイッチ３の物理ネットワーク構成におけるインスタンス表現を示す。このインスタンスの名称はｓｗｉｔｃｈ３＿ｐである。図９にスイッチ３の上流インタフェースの物理ネットワーク構成におけるインスタンス表現を示す。このインスタンスの名称はｉｆ＿ｓ３＿ｕ＿ｐである。図１０にルータ３とスイッチ３間のリンクの物理ネットワークにおけるインスタンス表現を示す。このインスタンスの名称はｌｉｎｋ＿ｒ３ｓ３＿ｐである。図１１にスイッチ３とホスト２間のリンクの物理ネットワークにおけるインスタンス表現を示す。このインスタンスの名称はｌｉｎｋ＿ｓ３ｈ２＿ｐである。図１２にルータ３とスイッチ３間のリンクの論理ネットワークにおけるインスタンス表現を示す。このインスタンスの名称はｌｉｎｋ＿ｒ３ｓ３＿ｌである。図１３にＩＰサブネット３のＩＰネットワーク構成におけるインスタンス表現を示す。このインスタンスの名称はｓｕｂｎｅｔ３＿ｉである。図１４にホスト２とｗｅｂサーバ１間のＩＰ経路のＩＰネットワーク構成におけるインスタンス表現を示す。このインスタンスの名称はｐａｔｈ＿ｈ２ｗ１＿ｉである。図１５にホスト３のＩＰネットワーク構成におけるインスタンス表現を示す。このインスタンスの名称はｈｏｓｔ３＿ｉである。図１６にホスト３のサービスネットワーク構成におけるインスタンス表現を示す。このインスタンスの名称はｈｏｓｔ３＿ｓである。図１７にｗｅｂサーバ１のサービスネットワーク構成におけるインスタンス表現を示す。このインスタンスの名称はｗｅｂ１＿ｓである。

３．依存関係ルールと状態伝搬ルール
依存関係ルールは、互いの状態に影響を及ぼす（依存関係にある）２つの要素を記載したものである。例えば、図１８に示すＳＰＩＮ依存関係ルールは、物理インタフェースが物理ノードに接続している場合、物理ノードの状態が物理インタフェースの状態に影響を与えることを示している。図１９に示すＳＰＩＮ依存関係ルールは、物理リンクが物理インタフェースに接続している場合、物理インタフェースの状態が物理リンクの状態に影響を与えることを示している。図２０に示すＳＰＩＮ依存関係ルールは、論理リンクが物理リンク上で動作している場合、物理リンクの状態が論理リンクの状態に影響を与えることを示している。図２１に示すＳＰＩＮ依存関係ルールは、ＩＰサブネットが論理リンク上で動作している場合、論理リンクの状態がＩＰサブネットの状態に影響を与えることを示している。図２２に示すＳＰＩＮ依存関係ルールは、ＩＰ経路がＩＰサブネットにより構成されている場合、ＩＰサブネットの状態がＩＰ経路の状態に影響を与えることを示している。図２３に示すＳＰＩＮ依存関係ルールは、サービスがＩＰ経路の端点となる論理ノード上で動作している場合、ＩＰ経路の状態がサービスの状態に影響を与えることを示している。

状態伝搬ルールは、依存関係ルールに記載された２つの要素間で影響する具体的な状態内容を記載したものである。例えば、図２４に示すＳＰＩＮ状態伝搬ルールは、物理ノードが“ＮｏｄｅＤｏｗｎ”という状態を持ち、この物理ノードと物理インタフェース間に依存関係がある場合、物理インタフェースには“ＩｆＤｏｗｎ”という状態が伝搬することを示している。図２５に示すＳＰＩＮ状態伝搬ルールは、物理インタフェースが“ＩｆＤｏｗｎ”という状態を持ち、この物理インタフェースと物理リンク間に依存関係がある場合、物理リンクには“ＬｉｎｋＤｏｗｎ”という状態が伝搬することを示している。図２６に示すＳＰＩＮ状態伝搬ルールは、物理リンクが“ＬｉｎｋＤｏｗｎ”という状態を持ち、この物理リンクと論理リンク間に依存関係がある場合、論理リンクには“ＬｉｎｋＤｏｗｎ”という状態が伝搬することを示している。図２７に示すＳＰＩＮ状態伝搬ルールは、論理リンクが“ＬｉｋｎＤｏｗｎ”という状態を持ち、この論理リンクとＩＰサブネット間に依存関係がある場合、ＩＰサブネットには“ＮｅｔＤｏｗｎ”という状態が伝搬することを示している。図２８に示すＳＰＩＮ状態伝搬ルールは、ＩＰサブネットが“ＮｅｔＤｏｗｎ”という状態を持ち、このＩＰサブネットとＩＰ経路間に依存関係がある場合、ＩＰ経路には“Ｕｎｒｅａｃｈａｂｌｅ”という状態が伝搬することを示している。図２９に示すＳＰＩＮ状態伝搬ルールは、ＩＰ経路が“Ｕｎｒｅａｃｈａｂｌｅ”という状態を持ち、このＩＰ経路とネットワークサービス間に依存関係がある場合、ネットワークサービスには“Ｕｎａｖａｉｌａｂｌｅ”という状態が伝搬することを示している。

４．依存関係のルール展開
図１に示す本推論装置において、ＳＰＩＮ依存関係ストレージにはすでに図１８から図２３に示したＳＰＩＮ依存関係ルールが格納されているとする。このとき、図８から図１７に示したネットワーク構成情報がネットワーク構成情報ＲＤＦストレージ２１に入力されたとする。するとＳＰＩＮ推論エンジン１２は入力されたネットワーク構成情報にＳＰＩＮ依存関係ルールを適用し、その結果を依存関係ルール展開ストレージ２３に格納する。図８に示すインスタンス表現は、図１８に示すＳＰＩＮ依存関係ルールと図９に示すインスタンス表現により、図３０のように書き換えられる。この例では７行目と８行目が元のインスタンス表現に追加されている。図９に示すインスタンス表現は、図１９に示すＳＰＩＮ依存関係ルールおよび図１０と図１１に示すインスタンス表現により、図３１のように書き換えられる。この例では７行目が元のインスタンス表現に追加されている。図１０に示すインスタンス表現は、図２０に示すＳＰＩＮ依存関係ルールと図１２に示すインスタンスにより、図３２のように書き換えられる。この例では７行目が元のインスタンス表現に追加されている。図１２に示すインスタンス表現は、図２１に示すＳＰＩＮ依存関係ルールと図１３に示すインスタンス表現により、図３３のように書き換えられる。この例では８行目が元のインスタンス表現に追加されている。図１３に示すインスタンス表現は、図２２に示すＳＰＩＮ依存関係ルールと図１４に示すインスタンス表現により、図３４のように書き換えられる。この例では９行目が元のインスタンス表現に追加されている。図１４に示すインスタンス表現は、図２３に示すＳＰＩＮ依存関係ルールと図１７に示すインスタンス表現により、図３５のように書き換えられる。この例では７行目が元のインスタンス表現に追加されている。

ネットワーク構成情報に変化がない限り、本推論装置はここまでの処理を完了した段階でシステム利用者からの入力待ちとなる。

５．影響範囲推論
本推論装置の範囲推定手段が行う動作について説明する。スイッチ３が故障した場合のネットワークサービスレベルでの影響範囲推論の手順を図３６に示す。その際に使用する影響範囲推論ルールを図３７に示す。

（ステップ１）入出力モジュール２５は「スイッチ３が故障した場合のネットワークサービスレベルの障害範囲」という要求を影響範囲推論モジュール１３に送信する。
（ステップ２）影響範囲推論モジュール１３はこの情報を「ｓｗｉｔｃｈ３＿ｐ － ｈａｓＳｔａｔｅ －“ＮｏｄｅＤｏｗｎ”」という 障害情報トリプルに変換し、依存関係ルール展開ストレージ２３に送信する。
（ステップ３）依存関係ルール展開ストレージ２３は一時的依存関係ルール展開ストレージ２７にオントロジ更新を送信する。
（ステップ４）一時的依存関係ルール展開ストレージ２７はオントロジ更新通知をＳＰＩＮ推論エンジン１２に送信する。
（ステップ５）ＳＰＩＮ推論エンジン１２は追加された障害情報トリプルに基づきＳＰＩＮ状態伝搬ルールを展開し、その結果として得られたトリプルを一時的依存関係ルール展開ストレージ２７に追加する。ＳＰＩＮ推論エンジン１２が追加するトリプルは以下のとおりである。
・ｉｆ＿ｓ３＿ｕ＿ｐ － ｈａｓＳｔａｔｅ －“ＩｆＤｏｗｎ”
・ｌｉｎｋ＿ｒ３ｓ２＿ｐ － ｈａｓＳｔａｔｅ －“ＬｉｎｋＤｏｗｎ”
・ｌｉｎｋ＿ｒ３ｓ２＿ｌ － ｈａｓＳｔａｔｅ －“ＬｉｎｋＤｏｗｎ”
・ｓｕｂｎｅｔ３＿ｉ － ｈａｓＳｔａｔｅ －“ＮｅｔＤｏｗｎ”
・ｐａｔｈ＿ｈ２ｈ３ － ｈａｓＳｔａｔｅ －“Ｕｎｒｅａｃｈａｂｌｅ”
・ｗｅｂ１＿ｓ － ｈａｓＳｔａｔｅ －“Ｕｎａｖａｉｌａｂｌｅ”
（ステップ６）一時的依存関係ルール展開ストレージ２７はトリプル追加通知を影響範囲推論モジュール１３に送信する。
（ステップ７）影響範囲推論モジュール１３は、ＳＰＩＮ推論エンジン１２によるトリプル追加によって状態に変更があったインスタンスを得るため、状態変更インスタンス要求を一時的依存関係ルール展開ストレージ２７に送信する。
（ステップ８）一時的依存関係ルール展開ストレージ２７は状態に変更があったインスタンスを影響範囲推論モジュール１３に送信する。状態に変更があったインスタンスは以下のとおりである。
・ｓｗｉｔｃｈ３＿ｐ － ｈａｓＳｔａｔｅ －“ＮｏｄｅＤｏｗｎ”
・ｉｆ＿ｓ３＿ｕ＿ｐ － ｈａｓＳｔａｔｅ －“ＩｆＤｏｗｎ”
・ｌｉｎｋ＿ｒ３ｓ２＿ｐ － ｈａｓＳｔａｔｅ －“ＬｉｎｋＤｏｗｎ”
・ｌｉｎｋ＿ｒ３ｓ２＿ｌ － ｈａｓＳｔａｔｅ －“ＬｉｎｋＤｏｗｎ”
・ｓｕｂｎｅｔ３＿ｉ － ｈａｓＳｔａｔｅ －“ＮｅｔＤｏｗｎ”
・ｐａｔｈ＿ｈ３ｈ２ － ｈａｓＳｔａｔｅ －“Ｕｎｒｅａｃｈａｂｌｅ”
・ｗｅｂ１＿ｓ － ｈａｓＳｔａｔｅ －“Ｕｎａｖａｉｌａｂｌｅ”
（ステップ９）影響範囲推論モジュール１３はステップ２で追加されたトリプルを消去するため、リセット要求を一時的依存関係ルール展開ストレージ２７に送信する。
（ステップ１０）一時的依存関係ルール展開ストレージ２７はステップ２で追加されたトリプルを消去し、リセット応答を影響範囲推論モジュール１３に送信する。
（ステップ１１）この結果、ネットワークサービスレベルでの影響は「ｗｅｂ１＿ｓ － ｈａｓＳｔａｔｅ －“Ｕｎａｖａｉｌａｂｌｅ”」であるので、影響範囲推論モジュール１３は入出力モジュール２６に「ｗｅｂ１閲覧不能」という応答を返す。

６．障害原因推論
本推論装置の原因推定手段が行う動作について説明する。ホスト２からｗｅｂ１が閲覧不能である場合の障害原因推論の手順を図３８に示す。このとき使用する障害推論ルールを図３９から図４２に示す。またこのルールで使用するＦａｕｌｔＮｏｄｅクラスを図４３に示す。

（ステップ１）入出力モジュール２５は「ホスト２からｗｅｂ１が閲覧不能」という情報を障害原因推論モジュール１４に送信する。
（ステップ２）障害原因推論モジュール１４は、ｗｅｂ１＿ｓの状態に依存関係をもつインスタンスを検索するため、「？ － ｈａｓ ＣａｕｓａｌＲｅｌａｔｉｏｎｓｈｉｐ － ｗｅｂ１＿ｓ」という依存インスタンス要求を依存関係ルール展開ストレージ２３に送信する。
（ステップ３）依存関係ルール展開ストレージ２３は依存インスタンス応答として「ｈｏｓｔ３＿ｉ － ｈａｓＣａｕｓａｌＲｅｌａｔｉｏｎｓｈｉｐ － ｗｅｂ１＿ｓ」を障害原因推論モジュール１４に送信する。
（ステップ４）障害原因推論モジュール１４は、ｈｏｓｔ３＿ｉが取り得る状態を得るため「ｈｏｓｔ３＿ｉ － ｐｏｓｓｉｂｌｅＳｔａｔｅｓ － ？」という状態候補要求を依存関係ルール展開ストレージ２３に送信する。
（ステップ５）依存関係ルール展開ストレージ２３は、ネットワーク構成情報ＲＤＦストレージ２１が保管する、図１５に示すｈｏｓｔ３＿ｉのインスタンス表現に基づき、ｈｏｓｔ３＿ｉが取り得る状態として“ＮｏｄｅＤｏｗｎ”を状態候補応答として障害原因推論モジュール１４に送信する。
（ステップ６）障害原因推論モジュール１４は、ｈｏｓｔ３＿ｉが“ＮｏｄｅＤｏｗｎ”という状態になったとき、ｗｅｂ１＿ｓが“Ｕｎａｖａｉｌａｂｌｅ”という状態になるかを確認するため、「ｈｏｓｔ３＿ｉ － ｈａｓＳｔａｔｅ －“ＮｏｄｅＤｏｗｎ”」というトリプルを仮定トリプルとして依存関係ルール展開ストレージ２３に送信する。
（ステップ７）依存関係ルール展開ストレージ２３は仮定トリプルを追加し、ＳＰＩＮ推論エンジン１２にオントロジ更新通知を送信する。
（ステップ８）ＳＰＩＮ推論エンジン１２は追加されたトリプルに対してＳＰＩＮ状態伝搬ルールを適用し、「ｗｅｂ１＿ｓ － ｈａｓＳｔａｔｅ －“Ｕｎａｖａｉｌａｂｌｅ”というトリプルを得るので、これを一時的状態伝搬ストレージに追加する。
（ステップ９）一時的状態伝搬ストレージは障害原因推論モジュール１４にトリプル追加通知を送信する。
（ステップ１０）障害原因推論モジュール１４は状態更新があったインスタンスを得るため、「？ － ｈａｓＳｔａｔｅ － ？」を状態更新インスタンス要求として一時的状態伝搬ストレージに送信する。
（ステップ１１）一時的状態伝搬ストレージは、状態変更があったインスタンスとして以下を障害原因推論モジュール１４に送信する。
・ｈｏｓｔ３＿ｉ － ｈａｓＳｔａｔｅ －“ＮｏｄｅＤｏｗｎ”
・ｗｅｂ１＿ｓ － ｈａｓＳｔａｔｅ －“Ｕｎａｖａｉｌａｂｌｅ”
（ステップ１２）この結果、「ｈｏｓｔ３＿ｉ － ｈａｓＳｔａｔｅ －“ＮｏｄｅＤｏｗｎ”」から「ｗｅｂ１＿ｓ － ｈａｓＳｔａｔｅ －“Ｕｎａｖａｉｌａｂｌｅ”」に遷移可能であることが分かるため、障害原因推論モジュール１４は「ｈｏｓｔ３＿ｉ － ｈａｓＳｔａｔｅ －“ＮｏｄｅＤｏｗｎ”」が「ｗｅｂ１＿ｓ － ｈａｓＳｔａｔｅ －“Ｕｎａｖａｉｌａｂｌｅ”」の原因候補であることを知る。次に障害原因推論モジュール１４は、ステップ６で追加した仮定トリプルを取り消すため、リセット要求を一時的状態伝搬ストレージに送信する。
（ステップ１３）一時的状態伝搬ストレージ２８はステップ６からステップ８で更新した内容を消去し、リセット応答を障害原因推論モジュール１４に送信する。ステップ５で複数の状態候補が返ってきた場合、それぞれの状態についてステップ６からステップ１３を繰り返す。また、ステップ３で複数の依存インスタンスが返ってきた場合、それぞれのインスタンスについてステップ４からステップ１３を繰り返す。以上の処理の結果、原因候補のインスタンスが確定する。この例では「ｈｏｓｔ３＿ｉ － ｈａｓＳｔａｔｅ －“ＮｏｄｅＤｏｗｎ”」である。次に障害原因推論モジュール１４は確定した原因候補インスタンス「ｈｏｓｔ３＿ｉ － ｈａｓＳｔａｔｅ －“ＮｏｄｅＤｏｗｎ”」の原因を得るため、ステップ２に戻り、「？ － ｈａｓＣａｕｓａｌＲｅｌａｔｉｏｎｓｈｉｐ － ｈｏｓｔ３＿ｉ」を依存インスタンス要求として依存関係ルール展開ストレージ２３に送信する。以降、原因候補インスタンスが得られなくなるまで上記の手順を再帰的に繰り返す。
（ステップ１４）以上の結果、影響範囲推論モジュール１３は図４４－（ｂ）に示すフォルトツリーを得るので、これを入出力モジュール２６に送信する。

上記の手順では、まずステップ２～３にて入力された障害状況と直接依存関係のあるインスタンスを得る。次に、ステップ４～１３において上記で得られた各インスタンスから依存関係のあるインスタンスを次々とたどっていく。ステップ４～１３の内部では、まずステップ４～５においてインスタンスが取り得る状態を得る。次に、ステップ６～１１において上記で得られた各状態から入力された障害状況へ遷移できるかを調べる。この過程において、ステップ８において状態伝搬ルールが展開され、ステップ１２～１３において展開結果を削除する。以上のように、入力された障害情報と依存関係のあるインスタンスとその状態についてのみ状態伝搬ルールを展開し、その結果を調べた後に直ちに展開結果を削除する。これにより実行時のメモリ消費量を抑えている。

７．原因の絞込
本推論装置の障害状況応答手段が行う動作について説明する。ホスト２からｗｅｂ１が閲覧不能であることが分かったと同時に、ホスト１からはｗｅｂ１の閲覧が可能であることが分かったとする。このような情報を利用した障害原因絞り込みの手順を図４５に示す。その際に使用する絞り込みルールを図４６に示す。

（ステップ１）入出力モジュール２６は「ｈｏｓｔ２からｗｅｂ１が閲覧不能」という情報を原因推論モジュールに送信する。
（ステップ２）障害原因推論モジュール１４は図３８に示した手順でｈｏｓｔ２からｗｅｂ１が閲覧不能である原因候補を得る。
（ステップ３）結果として障害原因推論モジュール１４は図４４－（ｂ）のフォルトツリーを得る。
（ステップ４）障害原因推論モジュール１４はｈｏｓｔ２のフォルトツリーを入出力モジュール２６に送信する。
（ステップ５）次に入出力モジュール２６は「ｈｏｓｔ１からｗｅｂ１が閲覧不能」という情報を原因推論モジュールに送信する。
（ステップ６）障害原因推論モジュール１４は図３８に示した手順でｈｏｓｔ１からｗｅｂ１が閲覧不能である原因候補を得る。
（ステップ７）結果として障害原因推論モジュール１４は図４４－（ａ）のフォルトツリーを得る。
（ステップ８）障害原因推論モジュール１４はｈｏｓｔ１のフォルトツリーを入出力モジュール２６に送信する。
（ステップ９）入出力モジュール２６はｈｏｓｔ２のフォルトツリー（障害状態）とｈｏｓｔ１のフォルトツリー（正常状態）とともに原因絞込要求を原因絞込モジュールに送信する。
（ステップ１０）原因推論モジュールは障害状態のフォルトツリーと正常状態のフォルトツリーにより、以下のようにして原因を絞り込む。図４４－（ａ）と（ｂ）を比較すると、下線を付した行が両方に現れている。実際にはホスト１からｗｅｂ１は閲覧可能であるので、ホスト１のフォルトツリーに現れているインスタンスは正常に動作している。したがって、下線を付した行はホスト２のフォルトツリーから削除することができる。その結果、図４４－（ｃ）の結果を得ることができる。太字で示した行は物理レベルでの障害原因候補を示す。原因絞込モジュールは結果を障害原因推論モジュール１４に送信する。
（ステップ１１）障害原因推論モジュール１４は絞込後のｈｏｓｔ２のフォルトツリーを入出力モジュール２６に送信する。

［ネットワーク構成情報収集モジュールの動作例］
ネットワーク構成情報収集モジュール１１としては、例えば非特許文献４等に記載される、ＫＡＮＶＡＳアーキテクチャを備えるＫＡＮＶＡＳシステムが例示できる。図４７に、ＫＡＮＶＡＳシステムの構成例を示す。ＫＡＮＶＡＳシステムは、情報収集装置として機能するＫＡＮＶＡＳ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｏｌｌｅｃｔｏｒ（ＫＩＣ）３０、ストレージサーバ装置として機能するＫＡＮＶＡＳ Ｓｔｏｒａｇｅ Ｓｅｒｖｅｒ（ＫＳＳ）２０、アクセスサーバ装置として機能するＫＡＮＶＡＳ Ａｃｃｅｓｓ Ｓｅｒｖｅｒ（ＫＡＳ）１０、及びＫＡＮＶＡＳ Ｉｎｓｔａｎｃｅ Ｇｅｎｅｒａｔｏｒ（ＫＩＧ）５０という４つの主要なモジュールを備える。

ＫＡＳ１０は、管理者４２及びユーザ４３といったエンドノードの使用可能なアプリケーションである。
ＫＳＳ２０は論理的にはＡＳ（Ａｕｔｏｎｏｍｏｕｓ Ｓｙｓｔｅｍ：統一された管理ポリシによって運用されているネットワークの範囲）ネットワーク４４に１つ存在する。負荷分散のため物理的には複数のノードに存在してもよいが、論理的には１つであるとする。ＫＡＳ１０とＫＩＣ３０はＡＳネットワーク４４の規模により、ＡＳネットワーク４４内に１つ設置される場合もあれば、負荷分散のため複数設置される場合もある。

ＫＩＣ３０は、ＡＳネットワーク４４から経路情報や機器情報などのさまざまなネットワーク情報を集める。例えば、経路情報はＲＦＣ２３２８で規定されるＯＳＰＦ（Ｏｐｅｎ Ｓｈｏｒｔｅｓｔ Ｐａｔｈ Ｆｉｒｓｔ）やＲＦＣ４２７１で規定されるＢＧＰ－４（Ｂｏｒｄｅｒ Ｇａｔｅｗａｙ Ｐｒｏｔｏｃｏｌ ４）などのプロトコルに参加して収集する。また、機器情報や統計情報は、ＲＦＣ３４１６で規定されるＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）やＲＦＣ６２４１で規定されるＮＥＴＣＯＮＦによって各機器にアクセスして収集する。ネットワークのフロー情報は、ＲＦＣ３１７６で規定されるｓＦｌｏｗやＲＦＣ３９５４で規定されるＮｅｔＦｌｏｗを利用して収集する。障害情報は、ＣＬＩＮＥＸ（特許文献１）などを利用して収集する。そして得られた情報をネットワークオントロジＢｏｎｓａｉのインスタンスとして表現し、知識ベース（ネットワーク構成情報ＲＤＦストレージ２１）に格納する。

ＫＩＧ５０は、ＡＳネットワーク４４に接続した機器で動作し、指定された対象範囲（たとえば企業内ネットワーク）のネットワーク構成を自動的に収集してネットワーク構成を検出し、ＫＳＳ２０のデータベース（ネットワーク構成情報ＲＤＦストレージ２１）に格納する。

図４８にＫＩＧの内部構造を示す。ＫＩＧ５０は、ＡＰＩモジュール５１と、記憶情報取得部として機能するＫＳＳインタフェースモジュール５２と、コントローラモジュール５３と、追加情報取得部として機能するＭＩＢ（Ｍａｎａｇｅｍｅｎｔ ｉｎｆｏｒｍａｔｉｏｎ ｂａｓｅ）取得モジュール５４及びサービス判定モジュール５５と、ネットワーク構成検出部として機能するインスタンス生成モジュール５６と、を備える。ＫＩＧ５０は、コンピュータにプログラムを実行させることで、ＫＩＧ５０に備わる各機能部を実現させたものであってもよい。

ＡＰＩモジュール５１はユーザ４３やアプリケーション４１がＫＩＧ５０にアクセスするためのインタフェースを提供する。ＫＳＳインタフェースモジュール５２は、ＫＩＧ５０がＫＳＳ２０のデータベースに蓄えられている情報を得たり、ＫＩＧ５０が検出したネットワーク構成の情報をＫＳＳ２０のデータベースに蓄える処理を行う。これにより、ＫＳＳインタフェースモジュール５２はＡＳＡ３のネットワーク情報が格納されたデータベースから取得することができる。

ＫＳＳインタフェースモジュール５２は、ＫＳＳ２０の任意のデータベースから情報を取得する。例えば、図４７では、ＫＳＳ２０のデータベースの一例として、ＲＤＦ（Ｒｅｓｏｕｒｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｆｒａｍｅｗｏｒｋ）で記述されたデータを保存するＲＤＦデータベース（ネットワーク構成情報ＲＤＦストレージ２１）と時系列データを保存する時系列データベースの２種類のデータベースが備わる例を示す。この場合、ＫＳＳインタフェースモジュール５２は、ＲＤＦデータベース及び時系列データベースのうちのいずれのデータベースから情報を取得してもよい。

コントローラモジュール５３はＫＩＧ５０の動作を制御する。ＭＩＢ（Ｍａｎａｇｅｍｅｎｔ ｉｎｆｏｒｍａｔｉｏｎ ｂａｓｅ）取得モジュール５４はネットワーク機器にＳＮＭＰでアクセスし、ＲＦＣ１２１３およびＲＦＣ３４１８で規定される各種のＭＩＢ（Ｍａｎａｇｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｂａｓｅ）を取得する。サービス判定モジュール５５はネットワーク機器にアクセスし、サービスが動作しているかを判定する。インスタンス生成モジュール５６は、ＭＩＢ取得モジュール５４やサービス判定モジュール５５が得た情報を基に、対象範囲のネットワーク構成をＢｏｎｓａｉのインスタンスとして表現し、ＫＳＳ２０に格納する。

以下に、例を用いてＫＩＧの動作を示す。図４９にＩＰサブネットの観点でみたＡＳネットワークの例を示す。このＡＳネットワークは５台のルータ（ルータ＃１からルータ＃５）と６つのＩＰサブネット（サブネット＃１からサブネット＃６）から構成されている。

サブネット＃１にはサーバマシン、ＨＴＴＰサーバ（Ｗｅｂサーバ）、ＳＭＴＰサーバ（メールサーバ）、ＤＮＳサーバ、ＫＳＳ２０、ＫＩＧ５０が接続している。また、ルータ＃５ではＤＨＣＰサーバが動作している。各ルータ間では経路制御プロトコルとしてＯＳＰＦが動作しているものとする。ＫＩＣ３０はＯＳＰＦのＬＳＤＢ（Ｌｉｎｋ Ｓｔａｔｅ Ｄａｔａｂａｓｅ）を収集し、ＫＳＳ２０に格納しているものとする。

図５０に上記ＡＳネットワークの物理構成を示す。すべてのサブネットはスイッチ（スイッチＳＷ＃１からスイッチＳＷ＃５）を介した構成となっている。このうち、サブネット＃４と＃５はスイッチＳＷ＃４を共有したＶＬＡＮ（Ｖｉｒｔｕａｌ ＬＡＮ）で構成されている。

サブネット＃１にはサーバマシン、ＨＴＴＰサーバ、ＳＭＴＰサーバ、ＤＮＳサーバ、ＫＳＳ２０、ＫＩＧ５０が接続するが、ＨＴＴＰサーバとＳＭＴＰサーバは仮想マシンであり、サーバマシン上で動作している。サブネット＃６にはＷｉ－Ｆｉのアクセスポイント＃１が設置され、ホスト＃７がＷｉ－Ｆｉで接続している。各スイッチやアクセスポイント＃１ではＩＥＥＥ ８０２．１ＡＢで規定されるＬＬＤＰ（Ｌｉｎｋ Ｌａｙｅｒ Ｄｉｓｃｏｖｅｒｙ Ｐｒｏｔｏｃｏｌ）が動作しているとする。

ユーザまたはアプリケーションが、ＫＩＧ５０のＡＰＩモジュール５１を介してネットワーク構成のインスタンス生成モジュール５６を起動したとする。ネットワーク構成を検出する対象範囲は、ネットワークプリフィクス等で指定されるものとする。この例では、サブネット＃１から＃６を含むネットワークプリフィクスが指定されたものとする。

図５１に、本実施形態に係るネットワーク構成検出方法のフローチャートを示す。本実施形態に係るネットワーク構成検出方法は、ＫＩＧ５０が、記憶情報取得手順（Ｓ１０１）と、追加情報取得手順（Ｓ１０２～Ｓ１０７）と、ネットワーク構成検出手順（Ｓ１０８～Ｓ１０９）を順に実行する。

ステップＳ１０１．ＩＰネットワーク構成情報の取得（１）：対象範囲に存在するルータによるＩＰネットワーク構成情報の取得。
図５０の例では、ＫＩＧ５０のコントローラモジュール５３は、ＫＳＳインタフェースモジュール５２を介してＫＳＳ２０にアクセスし、対象範囲のネットワーク構成に関する情報をデータベースから取得する。ＫＳＳ２０のデータベースに対象範囲のＬＳＤＢが格納されている場合、コントローラモジュール５３は、ルータ＃１から＃５のＩＰアドレスが記載されたＬＳＤＢを得る。これにより、ＫＩＧ５０は、ルータ＃１から＃５のＩＰノード（図２に示す符号Ｃ３）を知ることができる。

ステップＳ１０２．ＩＰネットワーク構成情報の取得（２）：対象範囲に存在するルータのインタフェース情報およびルータ間関係情報の取得。
図５０の例では、次にＫＩＧ５０のコントローラモジュール５３はＭＩＢ取得モジュール５４を介してルータ＃１から＃５にＳＮＭＰで問合せ、各ルータが持つインタフェースの情報（インタフェースの種類、ＩＰアドレス、ネットマスクなど）を得る。たとえば、ＭＩＢで定義されているＩｆＴｙｐｅ，ｉｐＡｄＥｎｔＡｄｄｒ，ｉｐＡｄＥｎｔＮｅｔＭａｓｋなどのオブジェクトを参照する。これにより、ＫＩＧ５０は、ルータ＃１から＃５のＩＰサブネットＣ１、ＩＰインタフェースＣ２及びＩＰネットワーク構成Ｃ４を得ることができる。

すなわち、図５２に示すような、以下の情報を得る。
・サブネット＃１には、ルータ＃１，ルータ＃２，ルータ＃３が接続している。
・サブネット＃２には、ルータ＃２，ルータ＃４，ルータ＃５が接続している。
・サブネット＃３には、ルータ＃３が接続している。
・サブネット＃４には、ルータ＃４が接続している。
・サブネット＃５には、ルータ＃４が接続している。
・サブネット＃６には、ルータ＃５が接続している。

ステップＳ１０３．ＩＰネットワーク構成情報の取得（３）：対象範囲に存在するルータ以外のＬａｙｅｒ－３機器情報の取得。
図５０の例では、ＫＩＧ５０のコントローラモジュール５３はＭＩＢ取得モジュール５４を介してルータ＃１から＃５にＳＮＭＰで問合せ、各サブネットに接続する機器のＩＰアドレスとＭＡＣアドレスの対応表を得る。たとえば、ＭＩＢで定義されているｉｐＮｅｔＴｏＭｅｄｉａＴａｂｌｅなどのオブジェクトを参照する。これにより、ＫＩＧ５０は、各装置のＩＰノードＣ３、論理ノードＤ３、物理ノードＥ３を得ることができる。

すなわち、図５３に示すような、以下の情報を得る。
・サブネット＃１には、ルータ＃１、＃２、＃３、ＫＩＧ５０、ＫＳＳ２０以外に５台の機器が接続している。
・サブネット＃２には、ルータ＃２、＃４、＃５以外に２台の機器が接続している．
・サブネット＃３には、ルータ＃３以外に２台の機器が接続している。
・サブネット＃４には、ルータ＃４以外に２台の機器が接続している。
・サブネット＃５には、ルータ＃４以外に２台の機器が接続している。
・サブネット＃６には、ルータ＃５以外に４台の機器が接続している。

ステップＳ１０４．物理／論理ネットワーク構成情報の取得（１）：対象範囲に存在するＬａｙｅｒ－２機器情報の取得。
図５０の例では、ＫＩＧ５０のコントローラモジュール５３は、ＭＩＢ取得モジュール５４を介してＳＮＭＰで各ルータに問合せ、ＬＬＤＰの情報を得る。たとえばＬＬＤＰ－ＭＩＢで定義されているｌｌｄｐＲｅｍＴａｂｌｅなどのオブジェクトを参照する。また、スイッチのようにＬａｙｅｒ－２機器でもＩＰアドレスを持つものは、その値も得る。これにより、ＫＩＧ５０は、接続機器として機能する物理ノードＥ３を得ることができる。

すなわち、図５４に示すような、以下の情報を得る。
・サブネット＃１には、スイッチＳＷ＃１が接続している。
・サブネット＃２には、スイッチＳＷ＃２が接続している。
・サブネット＃３には、スイッチＳＷ＃３が接続している。
・サブネット＃４には、スイッチＳＷ＃４－１が接続している。
・サブネット＃５には、スイッチＳＷ＃４－２が接続している。
・サブネット＃６には、スイッチＳＷ＃５とアクセスポイント＃１が接続している。

ステップＳ１０５．物理／論理ネットワーク構成情報の取得（２）：対象範囲に存在するＬａｙｅｒ－３機器とＬａｙｅｒ－２機器間の関係情報の取得。
コントローラモジュール５３は、対象範囲における経路を制御するネットワーク機器から、各ネットワーク機器が制御する下流ネットワークの情報を取得し、これを用いて前記対象範囲の論理ネットワーク構成を特定する。図５０の例では、ＫＩＧ５０のコントローラモジュール５３は、ＭＩＢ取得モジュール５４を介してスイッチＳＷ＃１からＳＷ＃５とアクセスポイント＃１にＳＮＭＰで問合せ、各スイッチやアクセスポイント＃１に接続する機器のＭＡＣアドレスを得る。たとえば、ＭＩＢで定義されているｄｏｔ１ｄＴｐＰｏｒｔＴａｂｌｅなどのオブジェクトを参照する。この結果とステップＳ１０３で得たＭＡＣアドレスを突き合わせることで、ＫＩＧ５０は、論理ノードＤ３、論理インタフェースＤ２、論理リンクＤ１、論理ネットワーク構成Ｄ４、物理インタフェースＥ２、物理リンクＥ１、物理ネットワーク構成Ｅ４を得ることができる。

すなわち、図５５に示すような、以下の情報を得る。
・スイッチＳＷ＃１にはルータ＃１、ルータ＃２、ルータ＃３、ＫＳＳ２０、ＫＩＧ５０、ホスト＃１－１、ホスト＃１－２、ホスト＃１－３、ホスト＃１－４が接続している。
・スイッチＳＷ＃２にはルータ＃２、ルータ＃４、ルータ＃５、ホスト＃２が接続している。
・スイッチＳＷ＃４－１とスイッチＳＷ＃４－２は、物理的には１台のスイッチ（スイッチＳＷ＃４）である。
・サブネット＃４とサブネット＃５はＶＬＡＮであり、スイッチＳＷ＃４を共有している。
・スイッチＳＷ＃４にはルータ＃４、ホスト＃４、ホスト＃５が接続している。
・スイッチＳＷ＃５にはホスト＃６とアクセスポイント＃１が接続している。
・アクセスポイント＃１にはホスト＃７が接続している。

ステップＳ１０６．論理ネットワーク構成情報と物理ネットワーク構成情報の識別。
図５０の例では、ＫＩＧ５０のコントローラモジュール５３はＭＩＢ取得モジュール５４を介して各ホストにＳＮＭＰで問合せ、仮想マシン環境を実現するハイパバイザが動作しているか、また動作している場合、どのような仮想マシンが動作しているかを得る。たとえば、ＲＦＣ７６６６で規定されるＭＩＢで定義されているｖｍＭＩＢなどのオブジェクトを利用する。この結果、ＫＩＧ５０は、ホスト＃１－１上でホスト＃１－２とホスト＃１－３が仮想マシン（ＶＭ）として動作していることを知る。すなわち、図５６に示すような情報を得る。

ステップＳ１０７．ネットワークサービス構成情報の取得。
図５０の例では、ＫＩＧ５０のコントローラモジュール５３は、サービス判定モジュール５５を介して、コントローラモジュール５３は、対象範囲に含まれる各端末すなわち各ホストにアクセスし、対象範囲に含まれるネットワークサービス構成Ｂ３を特定する。アクセスは、例えば、ルータ＃１から＃５、ホスト＃１－１から＃７における、ネットワークサーバに対応するポートへのアクセスである。アクセスするポートはサービスに応じたポートであり、たとえば、ＨＴＴＰサーバは８０番ポート、ＳＭＴＰサーバは２５番ポート、ＤＮＳサーバは５３番ポート、ＤＨＣＰサーバは６７番ポートとなる。具体的には、ＨＴＴＰサーバやＳＭＴＰサーバのようにＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）を使用する場合は、対応するポート番号を指定してＴＣＰコネクションの確立を試みる。

ＴＣＰコネクションが確立された場合、対応するサーバが動作していると判断する。ＩＣＭＰ（Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ） ｐｏｒｔ ｕｎｒｅａｃｈａｂｌｅが返されたり、ＴＣＰコネクション確立が失敗したりする場合は、対応するサーバが動作していないと判断する。

ＤＮＳサーバやＤＨＣＰサーバのようにＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）を使用する場合は、対応するポート番号にＵＤＰセグメントを送信する。ＩＣＭＰ ｐｏｒｔ ｕｎｒｅａｃｈａｂｌｅやエラーを示すセグメントが返された場合は、対応するサーバは動作していないと判断する。それ以外の場合は，対応するサーバが動作していると判断する。

この結果、ホスト＃１－２でＨＴＴＰサーバが動作し、ホスト＃１－３でＳＭＴＰサーバが動作し、ホスト＃１－４でＤＮＳサーバが動作し、ルータ＃５でＤＨＣＰサーバが動作することを知る。これにより、ＫＩＧ５０はネットワークサービスＢにおけるサービスエンティティＢ２、ネットワークサービスＢ１及びネットワークサービス構成Ｂ３を得ることができる。すなわち、図５６に示すような物理構成の情報を得る。

ステップＳ１０２～Ｓ１０７により、ＫＳＳインタフェースモジュール５２の取得した情報を用いて対象範囲に含まれる機器を特定し、特定した機器から、対象範囲のネットワーク構成のうちのＫＳＳインタフェースモジュール５２の取得できなかった情報を取得することができる。

ステップＳ１０８．
ＫＩＧ５０のコントローラモジュール５３は、得られたネットワーク構成の情報をインスタンス生成モジュール５６に渡す。インスタンス生成モジュール５６は、対象範囲のネットワーク構成を予め定められた形式で表しインスタンスを生成する。

ステップＳ１０９．
ＫＩＧ５０のコントローラモジュール５３は、ＫＳＳインタフェースモジュール５２を介して得られたインスタンス表現をＫＳＳ２０に送信する。

［発明によって生じる効果］
・データモデルとしてネットワークオントロジＢｏｎｓａｉを用いることで障害影響範囲推論と障害原因推論の両方を可能とした。
・障害影響範囲推論においては、ネットワーク構成が決定した時点で依存関係ルールを展開するため、実行時に依存関係ルールを展開する必要がない。そのため、実行時のメモリ消費量が抑えられ、高速に実行できる。
・障害原因推論においては、依存関係にないインスタンスや症状に関係しない状態伝搬に関しては解析ルールを展開しないことで全探索を避け、大規模なシステムにも適用可能とした。
・障害原因推論において、複数の観測情報を用いた原因の絞り込みが可能である。

［発明趣旨］
・障害の影響範囲推論において、ネットワーク構成情報にあらかじめ依存関係ルールを展開して保持しておくこと。
・障害原因推論において、依存関係にないインスタンスや症状に関係しない状態伝搬には解析ルールを展開しないこと。
・障害原因推論において、複数の観測情報を用いた原因の絞り込みが可能であること。

１０：ＫＡＮＶＡＳ Ａｃｃｅｓｓ Ｓｅｒｖｅｒ（ＫＡＳ）
１１：ネットワーク構成情報収集モジュール
１２：ＳＰＩＮ推論エンジン
１３：影響範囲推論モジュール
１４：障害原因推論モジュール
１５：障害原因絞込モジュール
２０：ＫＡＮＶＡＳ Ｓｔｏｒａｇｅ Ｓｅｒｖｅｒ（ＫＳＳ）
２１：ネットワーク構成情報ＲＤＦストレージ
２２：ＳＰＩＮ依存関係ルールストレージ
２３：依存関係ルール展開ストレージ
２４：ＳＰＩＮ状態伝搬ルールストレージ
２５：ルール入力モジュール
２６：入出力モジュール
２７：一時的依存関係ルール展開ストレージ
３０：ＫＡＮＶＡＳ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｏｌｌｅｃｔｏｒ（ＫＩＣ）
４４：ネットワーク
５０：ＫＡＮＶＡＳ Ｉｎｓｔａｎｃｅ Ｇｅｎｅｒａｔｏｒ（ＫＩＧ）
５１：ＡＰＩモジュール
５２：ＫＳＳインタフェースモジュール
５３：コントローラモジュール
５４：ＭＩＢ取得モジュール
５５：サービス判定モジュール
５６：インスタンス生成モジュール

Claims (8)

1. ネットワークを構成する複数の要素のうち、互いの状態が依存し合う関係にある２つの要素の依存関係を記載した依存関係ルール、及び前記２つの要素の間で伝搬する状態の内容を記載した状態伝搬ルールが設定される設定手段と、
   前記ネットワークの構成についての情報を収集し、前記ネットワークの構成に応じた前記依存関係ルールを抽出して保管する保管手段と、
   前記要素についての故障情報が入力されたときに、保管されている前記依存関係ルールから状態に影響がある前記要素を選び出し、選び出された前記要素に基づいて前記状態伝搬ルールを検出し、前記故障情報で影響を受ける前記要素の範囲を推定する範囲推定手段と、
   を備えることを特徴とする障害影響範囲の推論装置。
2. 推定した前記要素の範囲のうち、ネットワークのサービスに関する影響を入力された前記故障情報の応答とする故障情報応答手段をさらに備えることを特徴とする請求項１に記載の障害影響範囲の推論装置。
3. ネットワークを構成する複数の要素のうち、互いの状態が依存し合う関係にある２つの要素の依存関係を記載した依存関係ルール、及び前記２つの要素の間で伝搬する状態の内容を記載した状態伝搬ルールが設定される設定手段と、
   前記ネットワークの構成についての情報を収集し、前記ネットワークの構成に応じた前記依存関係ルールを抽出して保管する保管手段と、
   前記ネットワークについての障害状況が入力されたときに、保管されている前記依存関係ルールから前記障害状況に関連する１又は複数の前記要素を選び出すとともに、選び出された前記要素が取り得る１又は複数の状態を検索し、選び出された前記要素と検索した前記状態に基づいて前記状態伝搬ルールを検出し、前記障害状況の原因となる前記要素と該要素の状態のリストを推定する原因推定を行う原因推定手段と、
   を備えることを特徴とする障害原因の推論装置。
4. 前記原因推定手段に前記障害状況に類似する他の障害状況を仮定して前記原因推定を行わせ、前記他の障害状況の原因となる前記要素と該要素の状態の他のリストを推定し、前記リストと前記他のリストに共通する項目を前記リストから除外した結果を、入力された前記障害状況の応答とする障害状況応答手段をさらに備えることを特徴とする請求項３に記載の障害原因の推論装置。
5. 障害影響範囲の推論装置が行う障害影響範囲の推論方法であって、
   ネットワークを構成する複数の要素のうち、互いの状態が依存し合う関係にある２つの要素の依存関係を記載した依存関係ルール、及び前記２つの要素の間で伝搬する状態の内容を記載した状態伝搬ルールを設定する設定手順と、
   前記ネットワークの構成についての情報を収集し、前記ネットワークの構成に応じた前記依存関係ルールを抽出して保管する保管手順と、
   前記要素についての故障情報が入力されたときに、保管されている前記依存関係ルールから状態に影響がある前記要素を選び出し、選び出された前記要素に基づいて前記状態伝搬ルールを検出し、前記故障情報で影響を受ける前記要素の範囲を推定する範囲推定手順と、
   を行うことを特徴とする障害影響範囲の推論方法。
6. 障害原因の推論装置が行う障害原因の推論方法であって、
   ネットワークを構成する複数の要素のうち、互いの状態が依存し合う関係にある２つの要素の依存関係を記載した依存関係ルール、及び前記２つの要素の間で伝搬する状態の内容を記載した状態伝搬ルールを設定する設定手順と、
   前記ネットワークの構成についての情報を収集し、前記ネットワークの構成に応じた前記依存関係ルールを抽出して保管する保管手順と、
   前記ネットワークについての障害状況が入力されたときに、保管されている前記依存関係ルールから前記障害状況に関連する１又は複数の前記要素を選び出すとともに、選び出された前記要素が取り得る１又は複数の状態を検索し、選び出された前記要素と検索した前記状態に基づいて前記状態伝搬ルールを検出し、前記障害状況の原因となる前記要素と該要素の状態のリストを推定する原因推定手順と、
   を行うことを特徴とする障害原因の推論方法。
7. 請求項１又は２に記載の障害影響範囲の推論装置としてコンピュータを機能させるためのプログラム。
8. 請求項３又は４に記載の障害原因の推論装置としてコンピュータを機能させるためのプログラム。

Images