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

障害影響範囲の推論装置、障害原因の推論装置、障害影響範囲の推論方法、障害原因の推論方法、及びプログラム Download PDF

Info

Publication number
JP7032251B2
JP7032251B2 JP2018123350A JP2018123350A JP7032251B2 JP 7032251 B2 JP7032251 B2 JP 7032251B2 JP 2018123350 A JP2018123350 A JP 2018123350A JP 2018123350 A JP2018123350 A JP 2018123350A JP 7032251 B2 JP7032251 B2 JP 7032251B2
Authority
JP
Japan
Prior art keywords
failure
state
cause
dependency
elements
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2018123350A
Other languages
English (en)
Other versions
JP2020005138A (ja
Inventor
修 鎌谷
修 明石
高弘 山口
文男 寺岡
啓 三上
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nippon Telegraph and Telephone Corp
Keio University
Original Assignee
Nippon Telegraph and Telephone Corp
Keio University
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nippon Telegraph and Telephone Corp, Keio University filed Critical Nippon Telegraph and Telephone Corp
Priority to JP2018123350A priority Critical patent/JP7032251B2/ja
Publication of JP2020005138A publication Critical patent/JP2020005138A/ja
Application granted granted Critical
Publication of JP7032251B2 publication Critical patent/JP7032251B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)

Description

本開示は、ネットワークオントロジを利用した障害影響範囲と障害原因の推論手法に関する。
サーバやネットワークの仮想化技術によりネットワーク構成が複雑化している。大規模で動的なシステムではネットワーク管理者がシステム全体を正確に把握することが難しく、障害の原因や影響範囲を突き止めるコストが増大している。その結果、障害原因推論の自動化への需要が高まっている。
非特許文献1は、オントロジによってモデル化したITシステム構成に対して汎用解析ルールを適用し、障害の根本原因を推論する。1つの汎用解析ルールは条件部と結論部からなる。条件部で指定する条件には、IT装置とその装置を構成するリソースの種別、そのリソースから生成されるイベント種別を指定する。結論部には、解析の結果として装置種別とそのリソースの種別、そのリソースから生成されるイベントの種別を記述する。このように定義することにより、汎用解析ルールはトポロジに対して条件を記述でき、また障害イベントの共起条件を記述できる。
非特許文献2は、システム構成要素間の異常情報の伝搬の仕方をオントロジで表現している。この手法では依存関係を導出するルールと状態伝搬に関するルールという2種類のルールを使用する。影響範囲推論の場合、原因となる構成要素から順にルールを展開し、状態を伝搬させていくことで影響を受ける構成要素を見つけることができる。障害原因推論の場合、すべての依存関係や状態伝搬ルールを展開し、システム内を異常状態が伝播するすべての経路を計算する。その上で現在発生している障害状態を含む経路のみを抽出することで、原因候補の構成要素を列挙することができる。
特許5845133号
工藤裕, 森村知弘, 菅内公徳, 増石哲也, 薦田憲久. 障害原因解析のためのルール構築方法と解析実行方式. 電気学会論文誌C, Vol. 132, No. 10, pp. 1689-1697, 2012. H. Dihowski, O. Holub, and J. Rojcek. Knowledge-Based Fault Propagation in Building Automation System. In Proceedings of 2016 International Confernece on Systems Informatics, Modelling and Simulation (SIMS), pp. 124-132, June 2016. 三上啓, 川口慎司, 大島涼太, 島松健太, 近藤賢郎, 鎌谷修, 明石修, 金子晋丈, 寺岡文男. ネットワークオントロジBonsaiを利用したネットワーク管理手法に関する一検討. 信学技報IN2016-86), January 2017. 川口慎司,「KANVAS: ネットワーク知識の活用に向けたオントロジを利用したオープンな情報共有基盤」,慶應義塾大学大学院理工学研究科開放環境科学専攻 修士論文,2016年3月.
非特許文献1の方式は、障害原因推論のみを対象としており、障害影響範囲推論を考慮していない。非特許文献2の方式は、障害原因推論と障害影響範囲推論が実現されているが、そのためにはすべてのルールをシステム構成にあわせてあらかじめ展開しておく必要がある。このため、非特許文献2の方式には、解析対象のシステムが大規模化及び複雑化すると、構成要素数や推論ルール数が増加するため、あらかじめ障害伝搬経路を計算しておくことが困難という第1の課題があった。
また、いずれの文献の方式も障害原因推論が可能であるが、示された原因候補を人手によって検証する必要があり、障害原因の絞り込みが困難という第2の課題があった。
そこで、本発明は、上記第1の課題を解決するために、解析対象のシステムが大規模化及び複雑化しても全ての障害伝搬経路を予め計算することを不要とできる障害影響範囲の推論装置、障害原因の推論装置、障害影響範囲の推論方法、障害原因の推論方法、及びプログラムを提供することを目的とする。
また、本発明は、上記第2の課題を解決するために、障害原因の自動的な絞り込みが可能である障害原因の推論装置、障害原因の推論方法、及びプログラムを提供することも目的とする。
上記目的を達成するために、本発明に係る障害影響範囲の推論装置及びその方法は、ネットワーク構成情報に応じた依存関係ルールと状態伝搬ルールを展開して保持しておくこととした。
具体的には、本発明に係る障害影響範囲の推論装置は、
ネットワークを構成する複数の要素のうち、互いの状態が依存し合う関係にある2つの要素の依存関係を記載した依存関係ルール、及び前記2つの要素の間で伝搬する状態の内容を記載した状態伝搬ルールが設定される設定手段と、
前記ネットワークの構成についての情報を収集し、前記ネットワークの構成に応じた前記依存関係ルールを抽出して保管する保管手段と、
前記要素についての故障情報が入力されたときに、保管されている前記依存関係ルールから状態に影響がある前記要素を選び出し、選び出された前記要素に基づいて前記状態伝搬ルールを検出し、前記故障情報で影響を受ける前記要素の範囲を推定する範囲推定手段と、
を備える。
また、本発明に係る障害影響範囲の推論方法は、
ネットワークを構成する複数の要素のうち、互いの状態が依存し合う関係にある2つの要素の依存関係を記載した依存関係ルール、及び前記2つの要素の間で伝搬する状態の内容を記載した状態伝搬ルールを設定する設定手順と、
前記ネットワークの構成についての情報を収集し、前記ネットワークの構成に応じた前記依存関係ルールを抽出して保管する保管手順と、
前記要素についての故障情報が入力されたときに、保管されている前記依存関係ルールから状態に影響がある前記要素を選び出し、選び出された前記要素に基づいて前記状態伝搬ルールを検出し、前記故障情報で影響を受ける前記要素の範囲を推定する範囲推定手順と、
を行う。
本発明に係る障害影響範囲の推論装置は、推定した前記要素の範囲のうち、ネットワークのサービスに関する影響を入力された前記故障情報の応答とする故障情報応答手段をさらに備えてもよい。
一方、本発明に係る障害原因の推論装置は、
ネットワークを構成する複数の要素のうち、互いの状態が依存し合う関係にある2つの要素の依存関係を記載した依存関係ルール、及び前記2つの要素の間で伝搬する状態の内容を記載した状態伝搬ルールが設定される設定手段と、
前記ネットワークの構成についての情報を収集し、前記ネットワークの構成に応じた前記依存関係ルールを抽出して保管する保管手段と、
前記ネットワークについての障害状況が入力されたときに、保管されている前記依存関係ルールから前記障害状況に関連する1又は複数の前記要素を選び出すとともに、選び出された前記要素が取り得る1又は複数の状態を検索し、選び出された前記要素と検索した前記状態に基づいて前記状態伝搬ルールを検出し、前記障害状況の原因となる前記要素と該要素の状態のリストを推定する原因推定を行う原因推定手段と、
を備える。
また、本発明に係る障害原因の推論方法は、
ネットワークを構成する複数の要素のうち、互いの状態が依存し合う関係にある2つの要素の依存関係を記載した依存関係ルール、及び前記2つの要素の間で伝搬する状態の内容を記載した状態伝搬ルールを設定する設定手順と、
前記ネットワークの構成についての情報を収集し、前記ネットワークの構成に応じた前記依存関係ルールを抽出して保管する保管手順と、
前記ネットワークについての障害状況が入力されたときに、保管されている前記依存関係ルールから前記障害状況に関連する1又は複数の前記要素を選び出すとともに、選び出された前記要素が取り得る1又は複数の状態を検索し、選び出された前記要素と検索した前記状態に基づいて前記状態伝搬ルールを検出し、前記障害状況の原因となる前記要素と該要素の状態のリストを推定する原因推定手順と、
を行う。
本障害影響範囲の推論手法及び本障害原因の推論手法は、対象のネットワークの構造を定期的に収集し、その構造の変化に応じた依存関係ルールと状態伝搬ルールのみを展開して保持している。このため、全ての障害伝搬経路を予め計算することが不要である。従って、本発明は、解析対象のシステムが大規模化及び複雑化しても全ての障害伝搬経路を予め計算することを不要とできる障害影響範囲の推論装置、障害原因の推論装置、障害影響範囲の推論方法、及び障害原因の推論方法を提供することができる。
本発明に係る障害原因の推論装置は、前記原因推定手段に前記障害状況に類似する他の障害状況を仮定して前記原因推定を行わせ、前記他の障害状況の原因となる前記要素と該要素の状態の他のリストを推定し、前記リストと前記他のリストに共通する項目を前記リストから除外した結果を、入力された前記障害状況の応答とする障害状況応答手段をさらに備えてもよい。
本障害原因の推論装置は、仮定の障害状況に基づいて原因推定を行い、現状の原因推定と比較を行うことで障害原因を自動的に絞り込むこととした。従って、本発明は、障害原因の自動的な絞り込みが可能である障害原因の推論装置、及び障害原因の推論方法を提供することができる。
本発明に係るプログラムは、前記障害影響範囲の推論装置、あるいは前記障害原因の推論装置としてコンピュータを機能させるためのプログラムである。本発明に係る障害影響範囲の推論装置及び障害原因の推論装置はコンピュータとプログラムによっても実現でき、プログラムを記録媒体に記録することも、ネットワークを通して提供することも可能である。
本発明は、解析対象のシステムが大規模化及び複雑化しても全ての障害伝搬経路を予め計算することを不要とできる障害影響範囲の推論装置、障害原因の推論装置、障害影響範囲の推論方法、障害原因の推論方法、及びプログラムを提供することができる。
また、本発明は、障害原因の自動的な絞り込みが可能である障害原因の推論装置、障害原因の推論方法、及びプログラムを提供することもできる。
本発明に係る障害影響範囲の推論装置及び障害原因の推論装置を説明するブロック図である。 ネットワークオントロジBonsaiの全体構造を説明する構成図である。 ネットワークの例をIPレベルで説明する図である。 IPネットワーク構成を説明するインスタンス図である。 ネットワークの例を物理レベルで説明する図である。 物理ネットワーク構成を説明するインスタンス図である。 ネットワークサービス構成を説明するインスタンス図である。 スイッチ3の物理ネットワーク構成におけるインスタンス表現を説明する図である。 スイッチ3の上流インタフェースの物理ネットワーク構成におけるインスタンス表現を説明する図である。 ルータ3とスイッチ3間のリンクの物理ネットワーク構成におけるインスタンス表現を説明する図である。 スイッチ3とホスト2間のリンクの物理ネットワーク構成におけるインスタンス表現を説明する図である。 ルータ3とスイッチ3間のリンクの論理ネットワーク構成におけるインスタンス表現を説明する図である。 IPネットワーク構成におけるサブネット3のインスタンス表現を説明する図である。 ホスト2からWebサーバへの通信経路のインスタンス表現を説明する図である。 ホスト3のIPネットワーク構成におけるインスタンス表現を説明する図である。 ホスト3のIPネットワーク構成におけるインスタンス表現を説明する図である。 ネットワークサービス構成におけるWEBサービスのインスタンス表現を説明する図である。 依存関係ルール1(PhysicalNode -> PhysicalInterface)を説明する図である。 依存関係ルール2(PhysicalInterface -> PhysicalLink)を説明する図である。 依存関係ルール3(PhysicalLink -> LogicalLink)を説明する図である。 依存関係ルール4(LogicalLink -> IPSubnet)を説明する図である。 依存関係ルール5(IPSubnet -> IPPath)を説明する図である。 依存関係ルール6(IPPath -> NetworkService)を説明する図である。 状態伝搬ルール1(PhysicalNode -> PhysicalInterface)を説明する図である。 状態伝搬ルール2(PhysicalInterface -> PhysicalLink)を説明する図である。 状態伝搬ルール3(PhysicalLink -> LogicalLink)を説明する図である。 状態伝搬ルール4(LogicalLink -> IPSubnet)を説明する図である。 状態伝搬ルール5 (IPSubnet -> IPPath)を説明する図である。 状態伝搬ルール6(IPPath -> NetworkService)を説明する図である。 依存関係ルール適用後のスイッチ3の物理ネットワーク構成におけるインスタンス表現を説明する図である。 依存関係ルール適用後のスイッチ3の上流インタフェースの物理ネットワーク構成におけるインスタンス表現を説明する図である。 依存関係ルール適用後のルータ3とスイッチ3間のリンクの物理ネットワーク構成におけるインスタンス表現を説明する図である。 依存関係ルール適用後のルータ3とスイッチ3間のリンクの論理ネットワーク構成におけるインスタンス表現を説明する図である。 依存関係ルール適用後のIPネットワーク構成におけるサブネット3のインスタンス表現を説明する図である。 依存関係ルール適用後のホスト2からWebサーバへの通信経路のインスタンス表現を説明する図である。 本発明に係る障害影響範囲の推論方法を説明する図である。 影響範囲推論ルールを説明する図である。 本発明に係る障害原因の推論方法を説明する図である。 原因推論ルール(1)を説明する図である。 原因推論ルール(2-1)を説明する図である。 原因推論ルール(2-2)を説明する図である。 原因推論ルール(3)を説明する図である。 本発明に係る障害原因の推論方法で使用するFaultNodeクラスの例を説明する図である。 本発明に係る障害原因の推論方法における原因絞り込みの例を説明する図である。 本発明に係る障害原因の推論方法における原因絞り込み手順を説明する図である。 フォルトツリーの絞込ルールを説明する図である。 KANVASアーキテクチャの全体像の一例を示す。 KIGの内部構造の一例を示す。 IPネットワーク構成の一例を示す。 物理ネットワーク構成の一例を示す。 ネットワーク構成検出方法のフローチャートの一例を示す。 ステップS102終了後に得られたネットワーク構成の一例を示す。 ステップS103終了後に得られたネットワーク構成の一例を示す。 ステップS104終了後に得られたネットワーク構成の一例を示す。 ステップS105終了後に得られたネットワーク構成の一例を示す。 ステップS106終了後に得られたネットワーク構成の一例を示す。
添付の図面を参照して本発明の実施形態を説明する。以下に説明する実施形態は本発明の実施例であり、本発明は、以下の実施形態に制限されるものではない。なお、本明細書及び図面において符号が同じ構成要素は、相互に同一のものを示すものとする。
本実施形態の推論装置は、
ネットワークを構成する複数の要素のうち、互いの状態が依存し合う関係にある2つの要素の依存関係を記載した依存関係ルール、及び前記2つの要素の間で伝搬する状態の内容を記載した状態伝搬ルールが設定される設定手段と、
前記ネットワークの構成についての情報を収集し、前記ネットワークの構成に応じた前記依存関係ルールを抽出して保管する保管手段と、
前記要素についての故障情報が入力されたときに、保管されている前記依存関係ルールから状態に影響がある前記要素を選び出し、選び出された前記要素に基づいて前記状態伝搬ルールを検出し、前記故障情報で影響を受ける前記要素の範囲を推定する範囲推定手段、又は/及び
前記ネットワークについての障害状況が入力されたときに、保管されている前記依存関係ルールから前記障害状況に関連する1又は複数の前記要素を選び出すとともに、選び出された前記要素が取り得る1又は複数の状態を検索し、選び出された前記要素と検索した前記状態に基づいて前記状態伝搬ルールを検出し、前記障害状況の原因となる前記要素と該要素の状態のリストを推定する原因推定を行う原因推定手段と、
を備えることを特徴とする。
なお、上記の「要素」とは、ネットワークを構成するノード、インターフェース、リンク、経路、サブネット、サービス等を意味する。
1.モジュール構成
図1に本推論装置のブロック図を示す。ネットワーク構成情報収集モジュール11はネットワークの構成情報を自動的に収集し、これをネットワークオントロジBonsaiに基づくインスタンス表現に変換してネットワーク構成情報RDF(Resource Description Framework)ストレージに格納する。なお、ネットワーク構成情報収集モジュール11の具体例は後述する。
BonsaiはRDFとOWL(Web Ontology Language)に基づくドメインオントロジである(非特許文献3)。Bonsaiによるネットワーク構成オントロジの全体像を図2に示す。Bonsaiは5階層、6カテゴリから構成される。第1階層は物理ネットワーク構成、第2階層は論理ネットワーク構成、第3階層はIPネットワーク構成、第4層はオーバレイネットワーク構成、第5階層にはネットワークサービス構成と運用ネットワーク構成を定義する。ネットワーク構成情報収集モジュール11は、ネットワーク構成の変化を検出するたびにネットワーク構成情報をネットワーク構成情報RDFストレージ21に格納する。
ルール入力モジュール25は、システム管理者が定義した依存関係ルールと状態伝搬ルールをSPIN(SPARQL Inferencing Notation)形式に変換し、SPIN依存関係ルールストレージ22とSPIN状態伝搬ルールストレージ24に格納する。
SPIN推論エンジン12はネットワーク構成情報RDFストレージ21に格納された情報の変更を検出すると、ネットワーク構成情報にSPIN依存関係ルールを適用し、その結果を依存関係ルール展開ストレージ23に格納する。
入出力モジュール26はシステム利用者からの障害情報を受け取ったり、推論結果をユーザに返すためのインタフェースとなるモジュールである。障害情報には以下の2種類がある。1つはネットワークにおける障害箇所を指定した情報である(障害指定情報)。たとえば「ネットワークスイッチ1が故障した」などの情報である。もう1つは障害状況を記述した情報である(障害状況情報)。たとえば「ホスト1からwebサーバが閲覧不能」などの情報である。
影響範囲推論モジュール13は、入出力モジュール26から障害指定情報を受け取ると、障害指定情報をBonsaiに基づく表現形式に変換して依存関係ルール展開ストレージ23に問い合わせることで、障害により影響を受ける範囲を推論する。その際、依存関係ルールを一時的に適用した結果を一時的依存関係ルール展開ストレージ27に蓄える。
障害原因推論モジュール14は、入出力モジュール26から障害状況情報を受け取ると、依存関係ルール展開ストレージ23に問合せて障害状況からの依存関係を逆にたどることで障害の原因を推論し、木構造による障害原因候補を得る。その際、状態伝搬ルールを一時的に適用した結果を一時的状態伝搬ストレージ28に蓄える。
前記設定手段は、SPIN推論エンジン12、ルール入力モジュール25、SPIN依存関係ルールストレージ22、及びSPIN状態伝搬ルールストレージ24に相当する。前記保管手段は、ネットワーク構成情報収集モジュール11、SPIN推論エンジン12、ネットワーク構成情報RDFストレージ21、及び依存関係ルール展開ストレージ23に相当する。前記範囲推定手段は、SPIN推論エンジン12、影響範囲推論モジュール13、入出力モジュール26、依存関係ルール展開ストレージ23、及び一時的依存関係ルール展開ストレージ27に相当する。前記原因推定手段は、SPIN推論エンジン12、障害原因推論モジュール14、依存関係ルール展開ストレージ23、及び一時的状態伝搬ストレージ28に相当する。
本実施形態の推論装置は、前記原因推定手段に前記障害状況に類似する他の障害状況を仮定して前記原因推定を行わせ、前記他の障害状況の原因となる前記要素と該要素の状態の他のリストを推定し、前記リストと前記他のリストに共通する項目を前記リストから除外した結果を、入力された前記障害状況の応答とする障害状況応答手段をさらに備える。
前記障害状況応答手段は、障害原因絞込モジュール15であり、複数の障害状況情報から推論した複数の障害原因候補から障害原因を絞り込む。
2.ネットワーク構成例
図3に本明細書で例として用いるネットワークのIPレベルの構成を示す。図4にこのネットワークのIPネットワーク構成をBonsaiに基づくインスタンスとして表した図を示す。図5にこのネットワークの物理レベルの構成を示す。図6にこのネットワークの物理ネットワーク構成をBonsaiに基づくインスタンスとして表した図を示す。図7にホスト3上で動作するwebサーバ1のネットワークサービス構成をBonsaiに基づくインスタンスとして表した図を示す。論理ネットワーク構成、オーバレイネットワーク構成および運用ネットワーク構成に関するインスタンス図は省略する。
図8にスイッチ3の物理ネットワーク構成におけるインスタンス表現を示す。このインスタンスの名称はswitch3_pである。図9にスイッチ3の上流インタフェースの物理ネットワーク構成におけるインスタンス表現を示す。このインスタンスの名称はif_s3_u_pである。図10にルータ3とスイッチ3間のリンクの物理ネットワークにおけるインスタンス表現を示す。このインスタンスの名称はlink_r3s3_pである。図11にスイッチ3とホスト2間のリンクの物理ネットワークにおけるインスタンス表現を示す。このインスタンスの名称はlink_s3h2_pである。図12にルータ3とスイッチ3間のリンクの論理ネットワークにおけるインスタンス表現を示す。このインスタンスの名称はlink_r3s3_lである。図13にIPサブネット3のIPネットワーク構成におけるインスタンス表現を示す。このインスタンスの名称はsubnet3_iである。図14にホスト2とwebサーバ1間のIP経路のIPネットワーク構成におけるインスタンス表現を示す。このインスタンスの名称はpath_h2w1_iである。図15にホスト3のIPネットワーク構成におけるインスタンス表現を示す。このインスタンスの名称はhost3_iである。図16にホスト3のサービスネットワーク構成におけるインスタンス表現を示す。このインスタンスの名称はhost3_sである。図17にwebサーバ1のサービスネットワーク構成におけるインスタンス表現を示す。このインスタンスの名称はweb1_sである。
3.依存関係ルールと状態伝搬ルール
依存関係ルールは、互いの状態に影響を及ぼす(依存関係にある)2つの要素を記載したものである。例えば、図18に示すSPIN依存関係ルールは、物理インタフェースが物理ノードに接続している場合、物理ノードの状態が物理インタフェースの状態に影響を与えることを示している。図19に示すSPIN依存関係ルールは、物理リンクが物理インタフェースに接続している場合、物理インタフェースの状態が物理リンクの状態に影響を与えることを示している。図20に示すSPIN依存関係ルールは、論理リンクが物理リンク上で動作している場合、物理リンクの状態が論理リンクの状態に影響を与えることを示している。図21に示すSPIN依存関係ルールは、IPサブネットが論理リンク上で動作している場合、論理リンクの状態がIPサブネットの状態に影響を与えることを示している。図22に示すSPIN依存関係ルールは、IP経路がIPサブネットにより構成されている場合、IPサブネットの状態がIP経路の状態に影響を与えることを示している。図23に示すSPIN依存関係ルールは、サービスがIP経路の端点となる論理ノード上で動作している場合、IP経路の状態がサービスの状態に影響を与えることを示している。
状態伝搬ルールは、依存関係ルールに記載された2つの要素間で影響する具体的な状態内容を記載したものである。例えば、図24に示すSPIN状態伝搬ルールは、物理ノードが“NodeDown”という状態を持ち、この物理ノードと物理インタフェース間に依存関係がある場合、物理インタフェースには“IfDown”という状態が伝搬することを示している。図25に示すSPIN状態伝搬ルールは、物理インタフェースが“IfDown”という状態を持ち、この物理インタフェースと物理リンク間に依存関係がある場合、物理リンクには“LinkDown”という状態が伝搬することを示している。図26に示すSPIN状態伝搬ルールは、物理リンクが“LinkDown”という状態を持ち、この物理リンクと論理リンク間に依存関係がある場合、論理リンクには“LinkDown”という状態が伝搬することを示している。図27に示すSPIN状態伝搬ルールは、論理リンクが“LiknDown”という状態を持ち、この論理リンクとIPサブネット間に依存関係がある場合、IPサブネットには“NetDown”という状態が伝搬することを示している。図28に示すSPIN状態伝搬ルールは、IPサブネットが“NetDown”という状態を持ち、このIPサブネットとIP経路間に依存関係がある場合、IP経路には“Unreachable”という状態が伝搬することを示している。図29に示すSPIN状態伝搬ルールは、IP経路が“Unreachable”という状態を持ち、このIP経路とネットワークサービス間に依存関係がある場合、ネットワークサービスには“Unavailable”という状態が伝搬することを示している。
4.依存関係のルール展開
図1に示す本推論装置において、SPIN依存関係ストレージにはすでに図18から図23に示したSPIN依存関係ルールが格納されているとする。このとき、図8から図17に示したネットワーク構成情報がネットワーク構成情報RDFストレージ21に入力されたとする。するとSPIN推論エンジン12は入力されたネットワーク構成情報にSPIN依存関係ルールを適用し、その結果を依存関係ルール展開ストレージ23に格納する。図8に示すインスタンス表現は、図18に示すSPIN依存関係ルールと図9に示すインスタンス表現により、図30のように書き換えられる。この例では7行目と8行目が元のインスタンス表現に追加されている。図9に示すインスタンス表現は、図19に示すSPIN依存関係ルールおよび図10と図11に示すインスタンス表現により、図31のように書き換えられる。この例では7行目が元のインスタンス表現に追加されている。図10に示すインスタンス表現は、図20に示すSPIN依存関係ルールと図12に示すインスタンスにより、図32のように書き換えられる。この例では7行目が元のインスタンス表現に追加されている。図12に示すインスタンス表現は、図21に示すSPIN依存関係ルールと図13に示すインスタンス表現により、図33のように書き換えられる。この例では8行目が元のインスタンス表現に追加されている。図13に示すインスタンス表現は、図22に示すSPIN依存関係ルールと図14に示すインスタンス表現により、図34のように書き換えられる。この例では9行目が元のインスタンス表現に追加されている。図14に示すインスタンス表現は、図23に示すSPIN依存関係ルールと図17に示すインスタンス表現により、図35のように書き換えられる。この例では7行目が元のインスタンス表現に追加されている。
ネットワーク構成情報に変化がない限り、本推論装置はここまでの処理を完了した段階でシステム利用者からの入力待ちとなる。
5.影響範囲推論
本推論装置の範囲推定手段が行う動作について説明する。スイッチ3が故障した場合のネットワークサービスレベルでの影響範囲推論の手順を図36に示す。その際に使用する影響範囲推論ルールを図37に示す。
(ステップ1)入出力モジュール25は「スイッチ3が故障した場合のネットワークサービスレベルの障害範囲」という要求を影響範囲推論モジュール13に送信する。
(ステップ2)影響範囲推論モジュール13はこの情報を「switch3_p - hasState -“NodeDown”」という 障害情報トリプルに変換し、依存関係ルール展開ストレージ23に送信する。
(ステップ3)依存関係ルール展開ストレージ23は一時的依存関係ルール展開ストレージ27にオントロジ更新を送信する。
(ステップ4)一時的依存関係ルール展開ストレージ27はオントロジ更新通知をSPIN推論エンジン12に送信する。
(ステップ5)SPIN推論エンジン12は追加された障害情報トリプルに基づきSPIN状態伝搬ルールを展開し、その結果として得られたトリプルを一時的依存関係ルール展開ストレージ27に追加する。SPIN推論エンジン12が追加するトリプルは以下のとおりである。
・if_s3_u_p - hasState -“IfDown”
・link_r3s2_p - hasState -“LinkDown”
・link_r3s2_l - hasState -“LinkDown”
・subnet3_i - hasState -“NetDown”
・path_h2h3 - hasState -“Unreachable”
・web1_s - hasState -“Unavailable”
(ステップ6)一時的依存関係ルール展開ストレージ27はトリプル追加通知を影響範囲推論モジュール13に送信する。
(ステップ7)影響範囲推論モジュール13は、SPIN推論エンジン12によるトリプル追加によって状態に変更があったインスタンスを得るため、状態変更インスタンス要求を一時的依存関係ルール展開ストレージ27に送信する。
(ステップ8)一時的依存関係ルール展開ストレージ27は状態に変更があったインスタンスを影響範囲推論モジュール13に送信する。状態に変更があったインスタンスは以下のとおりである。
・switch3_p - hasState -“NodeDown”
・if_s3_u_p - hasState -“IfDown”
・link_r3s2_p - hasState -“LinkDown”
・link_r3s2_l - hasState -“LinkDown”
・subnet3_i - hasState -“NetDown”
・path_h3h2 - hasState -“Unreachable”
・web1_s - hasState -“Unavailable”
(ステップ9)影響範囲推論モジュール13はステップ2で追加されたトリプルを消去するため、リセット要求を一時的依存関係ルール展開ストレージ27に送信する。
(ステップ10)一時的依存関係ルール展開ストレージ27はステップ2で追加されたトリプルを消去し、リセット応答を影響範囲推論モジュール13に送信する。
(ステップ11)この結果、ネットワークサービスレベルでの影響は「web1_s - hasState -“Unavailable”」であるので、影響範囲推論モジュール13は入出力モジュール26に「web1閲覧不能」という応答を返す。
6.障害原因推論
本推論装置の原因推定手段が行う動作について説明する。ホスト2からweb1が閲覧不能である場合の障害原因推論の手順を図38に示す。このとき使用する障害推論ルールを図39から図42に示す。またこのルールで使用するFaultNodeクラスを図43に示す。
(ステップ1)入出力モジュール25は「ホスト2からweb1が閲覧不能」という情報を障害原因推論モジュール14に送信する。
(ステップ2)障害原因推論モジュール14は、web1_sの状態に依存関係をもつインスタンスを検索するため、「? - has CausalRelationship - web1_s」という依存インスタンス要求を依存関係ルール展開ストレージ23に送信する。
(ステップ3)依存関係ルール展開ストレージ23は依存インスタンス応答として「host3_i - hasCausalRelationship - web1_s」を障害原因推論モジュール14に送信する。
(ステップ4)障害原因推論モジュール14は、host3_iが取り得る状態を得るため「host3_i - possibleStates - ?」という状態候補要求を依存関係ルール展開ストレージ23に送信する。
(ステップ5)依存関係ルール展開ストレージ23は、ネットワーク構成情報RDFストレージ21が保管する、図15に示すhost3_iのインスタンス表現に基づき、host3_iが取り得る状態として“NodeDown”を状態候補応答として障害原因推論モジュール14に送信する。
(ステップ6)障害原因推論モジュール14は、host3_iが“NodeDown”という状態になったとき、web1_sが“Unavailable”という状態になるかを確認するため、「host3_i - hasState -“NodeDown”」というトリプルを仮定トリプルとして依存関係ルール展開ストレージ23に送信する。
(ステップ7)依存関係ルール展開ストレージ23は仮定トリプルを追加し、SPIN推論エンジン12にオントロジ更新通知を送信する。
(ステップ8)SPIN推論エンジン12は追加されたトリプルに対してSPIN状態伝搬ルールを適用し、「web1_s - hasState -“Unavailable”というトリプルを得るので、これを一時的状態伝搬ストレージに追加する。
(ステップ9)一時的状態伝搬ストレージは障害原因推論モジュール14にトリプル追加通知を送信する。
(ステップ10)障害原因推論モジュール14は状態更新があったインスタンスを得るため、「? - hasState - ?」を状態更新インスタンス要求として一時的状態伝搬ストレージに送信する。
(ステップ11)一時的状態伝搬ストレージは、状態変更があったインスタンスとして以下を障害原因推論モジュール14に送信する。
・host3_i - hasState -“NodeDown”
・web1_s - hasState -“Unavailable”
(ステップ12)この結果、「host3_i - hasState -“NodeDown”」から「web1_s - hasState -“Unavailable”」に遷移可能であることが分かるため、障害原因推論モジュール14は「host3_i - hasState -“NodeDown”」が「web1_s - hasState -“Unavailable”」の原因候補であることを知る。次に障害原因推論モジュール14は、ステップ6で追加した仮定トリプルを取り消すため、リセット要求を一時的状態伝搬ストレージに送信する。
(ステップ13)一時的状態伝搬ストレージ28はステップ6からステップ8で更新した内容を消去し、リセット応答を障害原因推論モジュール14に送信する。ステップ5で複数の状態候補が返ってきた場合、それぞれの状態についてステップ6からステップ13を繰り返す。また、ステップ3で複数の依存インスタンスが返ってきた場合、それぞれのインスタンスについてステップ4からステップ13を繰り返す。以上の処理の結果、原因候補のインスタンスが確定する。この例では「host3_i - hasState -“NodeDown”」である。次に障害原因推論モジュール14は確定した原因候補インスタンス「host3_i - hasState -“NodeDown”」の原因を得るため、ステップ2に戻り、「? - hasCausalRelationship - host3_i」を依存インスタンス要求として依存関係ルール展開ストレージ23に送信する。以降、原因候補インスタンスが得られなくなるまで上記の手順を再帰的に繰り返す。
(ステップ14)以上の結果、影響範囲推論モジュール13は図44-(b)に示すフォルトツリーを得るので、これを入出力モジュール26に送信する。
上記の手順では、まずステップ2~3にて入力された障害状況と直接依存関係のあるインスタンスを得る。次に、ステップ4~13において上記で得られた各インスタンスから依存関係のあるインスタンスを次々とたどっていく。ステップ4~13の内部では、まずステップ4~5においてインスタンスが取り得る状態を得る。次に、ステップ6~11において上記で得られた各状態から入力された障害状況へ遷移できるかを調べる。この過程において、ステップ8において状態伝搬ルールが展開され、ステップ12~13において展開結果を削除する。以上のように、入力された障害情報と依存関係のあるインスタンスとその状態についてのみ状態伝搬ルールを展開し、その結果を調べた後に直ちに展開結果を削除する。これにより実行時のメモリ消費量を抑えている。
7.原因の絞込
本推論装置の障害状況応答手段が行う動作について説明する。ホスト2からweb1が閲覧不能であることが分かったと同時に、ホスト1からはweb1の閲覧が可能であることが分かったとする。このような情報を利用した障害原因絞り込みの手順を図45に示す。その際に使用する絞り込みルールを図46に示す。
(ステップ1)入出力モジュール26は「host2からweb1が閲覧不能」という情報を原因推論モジュールに送信する。
(ステップ2)障害原因推論モジュール14は図38に示した手順でhost2からweb1が閲覧不能である原因候補を得る。
(ステップ3)結果として障害原因推論モジュール14は図44-(b)のフォルトツリーを得る。
(ステップ4)障害原因推論モジュール14はhost2のフォルトツリーを入出力モジュール26に送信する。
(ステップ5)次に入出力モジュール26は「host1からweb1が閲覧不能」という情報を原因推論モジュールに送信する。
(ステップ6)障害原因推論モジュール14は図38に示した手順でhost1からweb1が閲覧不能である原因候補を得る。
(ステップ7)結果として障害原因推論モジュール14は図44-(a)のフォルトツリーを得る。
(ステップ8)障害原因推論モジュール14はhost1のフォルトツリーを入出力モジュール26に送信する。
(ステップ9)入出力モジュール26はhost2のフォルトツリー(障害状態)とhost1のフォルトツリー(正常状態)とともに原因絞込要求を原因絞込モジュールに送信する。
(ステップ10)原因推論モジュールは障害状態のフォルトツリーと正常状態のフォルトツリーにより、以下のようにして原因を絞り込む。図44-(a)と(b)を比較すると、下線を付した行が両方に現れている。実際にはホスト1からweb1は閲覧可能であるので、ホスト1のフォルトツリーに現れているインスタンスは正常に動作している。したがって、下線を付した行はホスト2のフォルトツリーから削除することができる。その結果、図44-(c)の結果を得ることができる。太字で示した行は物理レベルでの障害原因候補を示す。原因絞込モジュールは結果を障害原因推論モジュール14に送信する。
(ステップ11)障害原因推論モジュール14は絞込後のhost2のフォルトツリーを入出力モジュール26に送信する。
[ネットワーク構成情報収集モジュールの動作例]
ネットワーク構成情報収集モジュール11としては、例えば非特許文献4等に記載される、KANVASアーキテクチャを備えるKANVASシステムが例示できる。図47に、KANVASシステムの構成例を示す。KANVASシステムは、情報収集装置として機能するKANVAS Information Collector(KIC)30、ストレージサーバ装置として機能するKANVAS Storage Server(KSS)20、アクセスサーバ装置として機能するKANVAS Access Server(KAS)10、及びKANVAS Instance Generator(KIG)50という4つの主要なモジュールを備える。
KAS10は、管理者42及びユーザ43といったエンドノードの使用可能なアプリケーションである。
KSS20は論理的にはAS(Autonomous System:統一された管理ポリシによって運用されているネットワークの範囲)ネットワーク44に1つ存在する。負荷分散のため物理的には複数のノードに存在してもよいが、論理的には1つであるとする。KAS10とKIC30はASネットワーク44の規模により、ASネットワーク44内に1つ設置される場合もあれば、負荷分散のため複数設置される場合もある。
KIC30は、ASネットワーク44から経路情報や機器情報などのさまざまなネットワーク情報を集める。例えば、経路情報はRFC2328で規定されるOSPF(Open Shortest Path First)やRFC4271で規定されるBGP-4(Border Gateway Protocol 4)などのプロトコルに参加して収集する。また、機器情報や統計情報は、RFC3416で規定されるSNMP(Simple Network Management Protocol)やRFC6241で規定されるNETCONFによって各機器にアクセスして収集する。ネットワークのフロー情報は、RFC3176で規定されるsFlowやRFC3954で規定されるNetFlowを利用して収集する。障害情報は、CLINEX(特許文献1)などを利用して収集する。そして得られた情報をネットワークオントロジBonsaiのインスタンスとして表現し、知識ベース(ネットワーク構成情報RDFストレージ21)に格納する。
KIG50は、ASネットワーク44に接続した機器で動作し、指定された対象範囲(たとえば企業内ネットワーク)のネットワーク構成を自動的に収集してネットワーク構成を検出し、KSS20のデータベース(ネットワーク構成情報RDFストレージ21)に格納する。
図48にKIGの内部構造を示す。KIG50は、APIモジュール51と、記憶情報取得部として機能するKSSインタフェースモジュール52と、コントローラモジュール53と、追加情報取得部として機能するMIB(Management information base)取得モジュール54及びサービス判定モジュール55と、ネットワーク構成検出部として機能するインスタンス生成モジュール56と、を備える。KIG50は、コンピュータにプログラムを実行させることで、KIG50に備わる各機能部を実現させたものであってもよい。
APIモジュール51はユーザ43やアプリケーション41がKIG50にアクセスするためのインタフェースを提供する。KSSインタフェースモジュール52は、KIG50がKSS20のデータベースに蓄えられている情報を得たり、KIG50が検出したネットワーク構成の情報をKSS20のデータベースに蓄える処理を行う。これにより、KSSインタフェースモジュール52はASA3のネットワーク情報が格納されたデータベースから取得することができる。
KSSインタフェースモジュール52は、KSS20の任意のデータベースから情報を取得する。例えば、図47では、KSS20のデータベースの一例として、RDF(Resource Description Framework)で記述されたデータを保存するRDFデータベース(ネットワーク構成情報RDFストレージ21)と時系列データを保存する時系列データベースの2種類のデータベースが備わる例を示す。この場合、KSSインタフェースモジュール52は、RDFデータベース及び時系列データベースのうちのいずれのデータベースから情報を取得してもよい。
コントローラモジュール53はKIG50の動作を制御する。MIB(Management information base)取得モジュール54はネットワーク機器にSNMPでアクセスし、RFC1213およびRFC3418で規定される各種のMIB(Management Information Base)を取得する。サービス判定モジュール55はネットワーク機器にアクセスし、サービスが動作しているかを判定する。インスタンス生成モジュール56は、MIB取得モジュール54やサービス判定モジュール55が得た情報を基に、対象範囲のネットワーク構成をBonsaiのインスタンスとして表現し、KSS20に格納する。
以下に、例を用いてKIGの動作を示す。図49にIPサブネットの観点でみたASネットワークの例を示す。このASネットワークは5台のルータ(ルータ#1からルータ#5)と6つのIPサブネット(サブネット#1からサブネット#6)から構成されている。
サブネット#1にはサーバマシン、HTTPサーバ(Webサーバ)、SMTPサーバ(メールサーバ)、DNSサーバ、KSS20、KIG50が接続している。また、ルータ#5ではDHCPサーバが動作している。各ルータ間では経路制御プロトコルとしてOSPFが動作しているものとする。KIC30はOSPFのLSDB(Link State Database)を収集し、KSS20に格納しているものとする。
図50に上記ASネットワークの物理構成を示す。すべてのサブネットはスイッチ(スイッチSW#1からスイッチSW#5)を介した構成となっている。このうち、サブネット#4と#5はスイッチSW#4を共有したVLAN(Virtual LAN)で構成されている。
サブネット#1にはサーバマシン、HTTPサーバ、SMTPサーバ、DNSサーバ、KSS20、KIG50が接続するが、HTTPサーバとSMTPサーバは仮想マシンであり、サーバマシン上で動作している。サブネット#6にはWi-Fiのアクセスポイント#1が設置され、ホスト#7がWi-Fiで接続している。各スイッチやアクセスポイント#1ではIEEE 802.1ABで規定されるLLDP(Link Layer Discovery Protocol)が動作しているとする。
ユーザまたはアプリケーションが、KIG50のAPIモジュール51を介してネットワーク構成のインスタンス生成モジュール56を起動したとする。ネットワーク構成を検出する対象範囲は、ネットワークプリフィクス等で指定されるものとする。この例では、サブネット#1から#6を含むネットワークプリフィクスが指定されたものとする。
図51に、本実施形態に係るネットワーク構成検出方法のフローチャートを示す。本実施形態に係るネットワーク構成検出方法は、KIG50が、記憶情報取得手順(S101)と、追加情報取得手順(S102~S107)と、ネットワーク構成検出手順(S108~S109)を順に実行する。
ステップS101.IPネットワーク構成情報の取得(1):対象範囲に存在するルータによるIPネットワーク構成情報の取得。
図50の例では、KIG50のコントローラモジュール53は、KSSインタフェースモジュール52を介してKSS20にアクセスし、対象範囲のネットワーク構成に関する情報をデータベースから取得する。KSS20のデータベースに対象範囲のLSDBが格納されている場合、コントローラモジュール53は、ルータ#1から#5のIPアドレスが記載されたLSDBを得る。これにより、KIG50は、ルータ#1から#5のIPノード(図2に示す符号C3)を知ることができる。
ステップS102.IPネットワーク構成情報の取得(2):対象範囲に存在するルータのインタフェース情報およびルータ間関係情報の取得。
図50の例では、次にKIG50のコントローラモジュール53はMIB取得モジュール54を介してルータ#1から#5にSNMPで問合せ、各ルータが持つインタフェースの情報(インタフェースの種類、IPアドレス、ネットマスクなど)を得る。たとえば、MIBで定義されているIfType,ipAdEntAddr,ipAdEntNetMaskなどのオブジェクトを参照する。これにより、KIG50は、ルータ#1から#5のIPサブネットC1、IPインタフェースC2及びIPネットワーク構成C4を得ることができる。
すなわち、図52に示すような、以下の情報を得る。
・サブネット#1には、ルータ#1,ルータ#2,ルータ#3が接続している。
・サブネット#2には、ルータ#2,ルータ#4,ルータ#5が接続している。
・サブネット#3には、ルータ#3が接続している。
・サブネット#4には、ルータ#4が接続している。
・サブネット#5には、ルータ#4が接続している。
・サブネット#6には、ルータ#5が接続している。
ステップS103.IPネットワーク構成情報の取得(3):対象範囲に存在するルータ以外のLayer-3機器情報の取得。
図50の例では、KIG50のコントローラモジュール53はMIB取得モジュール54を介してルータ#1から#5にSNMPで問合せ、各サブネットに接続する機器のIPアドレスとMACアドレスの対応表を得る。たとえば、MIBで定義されているipNetToMediaTableなどのオブジェクトを参照する。これにより、KIG50は、各装置のIPノードC3、論理ノードD3、物理ノードE3を得ることができる。
すなわち、図53に示すような、以下の情報を得る。
・サブネット#1には、ルータ#1、#2、#3、KIG50、KSS20以外に5台の機器が接続している。
・サブネット#2には、ルータ#2、#4、#5以外に2台の機器が接続している.
・サブネット#3には、ルータ#3以外に2台の機器が接続している。
・サブネット#4には、ルータ#4以外に2台の機器が接続している。
・サブネット#5には、ルータ#4以外に2台の機器が接続している。
・サブネット#6には、ルータ#5以外に4台の機器が接続している。
ステップS104.物理/論理ネットワーク構成情報の取得(1):対象範囲に存在するLayer-2機器情報の取得。
図50の例では、KIG50のコントローラモジュール53は、MIB取得モジュール54を介してSNMPで各ルータに問合せ、LLDPの情報を得る。たとえばLLDP-MIBで定義されているlldpRemTableなどのオブジェクトを参照する。また、スイッチのようにLayer-2機器でもIPアドレスを持つものは、その値も得る。これにより、KIG50は、接続機器として機能する物理ノードE3を得ることができる。
すなわち、図54に示すような、以下の情報を得る。
・サブネット#1には、スイッチSW#1が接続している。
・サブネット#2には、スイッチSW#2が接続している。
・サブネット#3には、スイッチSW#3が接続している。
・サブネット#4には、スイッチSW#4-1が接続している。
・サブネット#5には、スイッチSW#4-2が接続している。
・サブネット#6には、スイッチSW#5とアクセスポイント#1が接続している。
ステップS105.物理/論理ネットワーク構成情報の取得(2):対象範囲に存在するLayer-3機器とLayer-2機器間の関係情報の取得。
コントローラモジュール53は、対象範囲における経路を制御するネットワーク機器から、各ネットワーク機器が制御する下流ネットワークの情報を取得し、これを用いて前記対象範囲の論理ネットワーク構成を特定する。図50の例では、KIG50のコントローラモジュール53は、MIB取得モジュール54を介してスイッチSW#1からSW#5とアクセスポイント#1にSNMPで問合せ、各スイッチやアクセスポイント#1に接続する機器のMACアドレスを得る。たとえば、MIBで定義されているdot1dTpPortTableなどのオブジェクトを参照する。この結果とステップS103で得たMACアドレスを突き合わせることで、KIG50は、論理ノードD3、論理インタフェースD2、論理リンクD1、論理ネットワーク構成D4、物理インタフェースE2、物理リンクE1、物理ネットワーク構成E4を得ることができる。
すなわち、図55に示すような、以下の情報を得る。
・スイッチSW#1にはルータ#1、ルータ#2、ルータ#3、KSS20、KIG50、ホスト#1-1、ホスト#1-2、ホスト#1-3、ホスト#1-4が接続している。
・スイッチSW#2にはルータ#2、ルータ#4、ルータ#5、ホスト#2が接続している。
・スイッチSW#4-1とスイッチSW#4-2は、物理的には1台のスイッチ(スイッチSW#4)である。
・サブネット#4とサブネット#5はVLANであり、スイッチSW#4を共有している。
・スイッチSW#4にはルータ#4、ホスト#4、ホスト#5が接続している。
・スイッチSW#5にはホスト#6とアクセスポイント#1が接続している。
・アクセスポイント#1にはホスト#7が接続している。
ステップS106.論理ネットワーク構成情報と物理ネットワーク構成情報の識別。
図50の例では、KIG50のコントローラモジュール53はMIB取得モジュール54を介して各ホストにSNMPで問合せ、仮想マシン環境を実現するハイパバイザが動作しているか、また動作している場合、どのような仮想マシンが動作しているかを得る。たとえば、RFC7666で規定されるMIBで定義されているvmMIBなどのオブジェクトを利用する。この結果、KIG50は、ホスト#1-1上でホスト#1-2とホスト#1-3が仮想マシン(VM)として動作していることを知る。すなわち、図56に示すような情報を得る。
ステップS107.ネットワークサービス構成情報の取得。
図50の例では、KIG50のコントローラモジュール53は、サービス判定モジュール55を介して、コントローラモジュール53は、対象範囲に含まれる各端末すなわち各ホストにアクセスし、対象範囲に含まれるネットワークサービス構成B3を特定する。アクセスは、例えば、ルータ#1から#5、ホスト#1-1から#7における、ネットワークサーバに対応するポートへのアクセスである。アクセスするポートはサービスに応じたポートであり、たとえば、HTTPサーバは80番ポート、SMTPサーバは25番ポート、DNSサーバは53番ポート、DHCPサーバは67番ポートとなる。具体的には、HTTPサーバやSMTPサーバのようにTCP(Transmission Control Protocol)を使用する場合は、対応するポート番号を指定してTCPコネクションの確立を試みる。
TCPコネクションが確立された場合、対応するサーバが動作していると判断する。ICMP(Internet Control Message Protocol) port unreachableが返されたり、TCPコネクション確立が失敗したりする場合は、対応するサーバが動作していないと判断する。
DNSサーバやDHCPサーバのようにUDP(User Datagram Protocol)を使用する場合は、対応するポート番号にUDPセグメントを送信する。ICMP port unreachableやエラーを示すセグメントが返された場合は、対応するサーバは動作していないと判断する。それ以外の場合は,対応するサーバが動作していると判断する。
この結果、ホスト#1-2でHTTPサーバが動作し、ホスト#1-3でSMTPサーバが動作し、ホスト#1-4でDNSサーバが動作し、ルータ#5でDHCPサーバが動作することを知る。これにより、KIG50はネットワークサービスBにおけるサービスエンティティB2、ネットワークサービスB1及びネットワークサービス構成B3を得ることができる。すなわち、図56に示すような物理構成の情報を得る。
ステップS102~S107により、KSSインタフェースモジュール52の取得した情報を用いて対象範囲に含まれる機器を特定し、特定した機器から、対象範囲のネットワーク構成のうちのKSSインタフェースモジュール52の取得できなかった情報を取得することができる。
ステップS108.
KIG50のコントローラモジュール53は、得られたネットワーク構成の情報をインスタンス生成モジュール56に渡す。インスタンス生成モジュール56は、対象範囲のネットワーク構成を予め定められた形式で表しインスタンスを生成する。
ステップS109.
KIG50のコントローラモジュール53は、KSSインタフェースモジュール52を介して得られたインスタンス表現をKSS20に送信する。
[発明によって生じる効果]
・データモデルとしてネットワークオントロジBonsaiを用いることで障害影響範囲推論と障害原因推論の両方を可能とした。
・障害影響範囲推論においては、ネットワーク構成が決定した時点で依存関係ルールを展開するため、実行時に依存関係ルールを展開する必要がない。そのため、実行時のメモリ消費量が抑えられ、高速に実行できる。
・障害原因推論においては、依存関係にないインスタンスや症状に関係しない状態伝搬に関しては解析ルールを展開しないことで全探索を避け、大規模なシステムにも適用可能とした。
・障害原因推論において、複数の観測情報を用いた原因の絞り込みが可能である。
[発明趣旨]
・障害の影響範囲推論において、ネットワーク構成情報にあらかじめ依存関係ルールを展開して保持しておくこと。
・障害原因推論において、依存関係にないインスタンスや症状に関係しない状態伝搬には解析ルールを展開しないこと。
・障害原因推論において、複数の観測情報を用いた原因の絞り込みが可能であること。
10:KANVAS Access Server(KAS)
11:ネットワーク構成情報収集モジュール
12:SPIN推論エンジン
13:影響範囲推論モジュール
14:障害原因推論モジュール
15:障害原因絞込モジュール
20:KANVAS Storage Server(KSS)
21:ネットワーク構成情報RDFストレージ
22:SPIN依存関係ルールストレージ
23:依存関係ルール展開ストレージ
24:SPIN状態伝搬ルールストレージ
25:ルール入力モジュール
26:入出力モジュール
27:一時的依存関係ルール展開ストレージ
30:KANVAS Information Collector(KIC)
44:ネットワーク
50:KANVAS Instance Generator(KIG)
51:APIモジュール
52:KSSインタフェースモジュール
53:コントローラモジュール
54:MIB取得モジュール
55:サービス判定モジュール
56:インスタンス生成モジュール

Claims (8)

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

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2018123350A JP7032251B2 (ja) 2018-06-28 2018-06-28 障害影響範囲の推論装置、障害原因の推論装置、障害影響範囲の推論方法、障害原因の推論方法、及びプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2018123350A JP7032251B2 (ja) 2018-06-28 2018-06-28 障害影響範囲の推論装置、障害原因の推論装置、障害影響範囲の推論方法、障害原因の推論方法、及びプログラム

Publications (2)

Publication Number Publication Date
JP2020005138A JP2020005138A (ja) 2020-01-09
JP7032251B2 true JP7032251B2 (ja) 2022-03-08

Family

ID=69100563

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018123350A Active JP7032251B2 (ja) 2018-06-28 2018-06-28 障害影響範囲の推論装置、障害原因の推論装置、障害影響範囲の推論方法、障害原因の推論方法、及びプログラム

Country Status (1)

Country Link
JP (1) JP7032251B2 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022079920A1 (ja) * 2020-10-16 2022-04-21 日本電信電話株式会社 推論装置、推論方法及び推論プログラム
WO2022079921A1 (ja) * 2020-10-16 2022-04-21 日本電信電話株式会社 検出装置、検出方法及び検出プログラム
CN114422338B (zh) * 2022-03-29 2022-08-26 浙江网商银行股份有限公司 故障影响分析方法以及装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000069003A (ja) 1998-08-21 2000-03-03 Nippon Telegr & Teleph Corp <Ntt> マルチレイヤネットワーク故障影響範囲推定方法及びその装置
JP2011145773A (ja) 2010-01-12 2011-07-28 Fujitsu Ltd ネットワーク管理支援システム、ネットワーク管理支援装置、ネットワーク管理支援方法およびプログラム

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2921502B2 (ja) * 1996-08-19 1999-07-19 日本電気株式会社 順序回路の故障箇所推定方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000069003A (ja) 1998-08-21 2000-03-03 Nippon Telegr & Teleph Corp <Ntt> マルチレイヤネットワーク故障影響範囲推定方法及びその装置
JP2011145773A (ja) 2010-01-12 2011-07-28 Fujitsu Ltd ネットワーク管理支援システム、ネットワーク管理支援装置、ネットワーク管理支援方法およびプログラム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
鎌谷修 ほか,ネットワークオントロジによる障害影響範囲推論手法の検討,電子情報通信学会 2018年通信ソサイエティ大会 講演論文集2,2018年08月28日,p. 264

Also Published As

Publication number Publication date
JP2020005138A (ja) 2020-01-09

Similar Documents

Publication Publication Date Title
JP7108674B2 (ja) 故障根本原因決定方法及び装置並びにコンピュータ記憶媒体
JP5237034B2 (ja) イベント情報取得外のit装置を対象とする根本原因解析方法、装置、プログラム。
US11411803B2 (en) Associating network policy objects with specific faults corresponding to fault localizations in large-scale network deployment
CN110785964B (zh) 网络中第3层桥接域子网的验证
JP2019536331A (ja) 対話型ネットワーク分析プラットフォームのためのシステムおよび方法
CN110754065B (zh) 网络的逻辑级和硬件级之间的网络验证
JP7032251B2 (ja) 障害影響範囲の推論装置、障害原因の推論装置、障害影響範囲の推論方法、障害原因の推論方法、及びプログラム
US20060256733A1 (en) Methods and devices for discovering the topology of large multi-subnet LANs
CN110785965A (zh) 网络中使用虚拟路由转发容器的第3层的验证
US20200228395A1 (en) Fault localization in large-scale network policy deployment
EP3827555A1 (en) Synthesis of models for networks using automated boolean learning
CN111034123A (zh) 网络中第1层接口的验证
US10873509B2 (en) Check-pointing ACI network state and re-execution from a check-pointed state
CN110741602A (zh) 响应于网络意图形式对等性失败的事件生成
CN113347059B (zh) 基于固定探针位置的带内网络遥测最优探测路径规划方法
Pantuza et al. Network management through graphs in software defined networks
CN109639488A (zh) 一种多外网分流加速方法及系统
US9319271B2 (en) Management device and management method
Andreev et al. An algorithm for building an enterprise network topology using widespread data sources
US20200382399A1 (en) Trace routing in virtual networks
Zhou et al. Discovery algorithm for network topology based on SNMP
WO2007061404A2 (en) Network topology mapper
Peng et al. Analysis and research of network topology discovery method
JP6824843B2 (ja) ネットワーク構成検出装置、ネットワーク構成検出システム、ネットワーク構成検出方法及びネットワーク構成検出プログラム
Andreev et al. Network Topology Discovery: a Problem of Incomplete Data Improvement

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20180629

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20201029

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20210831

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20210907

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20211101

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20220222

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20220224

R150 Certificate of patent or registration of utility model

Ref document number: 7032251

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150