JP2000020428A

JP2000020428A - ネットワーク管理システム

Info

Publication number: JP2000020428A
Application number: JP10191772A
Authority: JP
Inventors: Yoshinori Takenami; 佳則武並
Original assignee: Sumitomo Electric Industries Ltd
Current assignee: Sumitomo Electric Industries Ltd
Priority date: 1998-07-07
Filing date: 1998-07-07
Publication date: 2000-01-21

Abstract

(57)【要約】【課題】分散環境で効果的に問題の特定を行うことが
できるネットワーク管理システム（ＮＭＳ）を提供する
こと。【解決手段】ネットワーク管理システムは、ワーカＮ
ＭＳ７２、７４、７６と、ワーカＮＭＳの各々と接続さ
れたマスタＮＭＳ７０とを含む。各ワーカＮＭＳおよび
マスタＮＭＳ７０は、相互に交信するためのＮＭＳイン
タフェース部と、管理対象のドメインの構成情報データ
および障害情報データを取得するネットワークインタフ
ェース部と、管理対象オブジェクトモデル、イベント伝
播モデル、構成情報データ、問題イベントリスト、およ
び他ドメインから伝播する症状イベント情報に基づき、
自己のドメインでの症状イベントと、ネットワーク全体
での問題との間の部分相関マトリクスを生成して送信す
る構成管理部とを含む。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ネットワーク上の
障害を管理するネットワーク管理システムに関し、特
に、ネットワーク上で観測されるさまざまな複数の障害
の症状から障害の根本原因を特定する機能を有するネッ
トワーク管理システムに関する。

【０００２】

【従来の技術】コンピュータによる通信ネットワークの
大規模化が進んでいる。通信ネットワークが大規模化す
るに従って、ネットワーク上に発生する障害の及ぼす影
響も大規模かつ深刻なものとなりつつある。そのためネ
ットワーク管理をいかに効率よく行なうか、が非常に重
要である。以下、本明細書上で使用されるネットワーク
管理に関する用語について定義をする。

【０００３】「イベント」とは、ネットワークにおいて
発生する例外的な状態のことをいう。「イベント」とい
う概念はハードウェアやソフトウェアの故障、停止、性
能のボトルネック、ネットワークの構成の不整合、設計
不十分による意図せざる結果、コンピュータウィルス等
の悪意による被害などを含む。

【０００４】「症状」とは、観測可能なイベントのこと
をいう。「症状イベント」と同じである。たとえば「あ
る宛先Ａに対して常に通信に時間がかかり再送信が必要
となる」、「ある宛先Ｂに対していつも文字化けが生ず
る」、「ある宛先Ｃに対していつも受信確認が返ってこ
ない」などの事象をいう。同じ意味で「Symptom 」とい
う語も使用する。

【０００５】「問題」とは、障害の根本原因のことをい
う。必ずしも観測可能ではない。たとえば通信装置の送
信機破損、通信ケーブルの断線、通信回線の容量不足な
どが例である。「問題イベント」は「問題」と同じ意味
である。同じ意味で「プロブレム」(Problem) という語
も使用する。

【０００６】「オブジェクト」とは、概念や抽象または
対象となる問題に対して明確な境界と意味とを持つ何も
のか、のことをいう。「オブジェクトインスタンス」と
は、後述するあるオブジェクトクラスに属するある特定
の１つのオブジェクトのことをいう。単に「インスタン
ス」ともいう。「オブジェクトクラス」とは、同様の性
質（属性）、共通の振る舞い（操作）、他のオブジェク
トとの共通の関係、および共通の意味を持つオブジェク
トのグループをいう。「クラス」はオブジェクトクラス
と同じである。「サブクラス」とは、あるクラスの下位
クラスとして、そのクラスに包含されるクラスのことを
いう。「属性」とは、クラスに属する各オブジェクトに
よって保持されるデータをいう。

【０００７】「オブジェクト図」とは、オブジェクト、
クラス、それらの間の関係のモデル化のための、形式的
な図式記法をいう。「クラス図」とは、多くの可能なイ
ンスタンスを記述するためのスキーマ、パターン、テン
プレートなどである。「リポジトリ」とは、必要な情報
を集約して一覧表的な形式で記憶した記憶部を言う。集
約一覧表メモリとでも呼ぶべきものである。「イベント
リポジトリ」とは、実際に発生した症状パターンを記憶
する記憶部をいう。「オブジェクトリポジトリ」とは、
ネットワークの構成モデルのリポジトリのことをいう。

【０００８】ネットワークのあるリソースにおける１つ
の問題イベントは、関係する複数のリソースの多くの症
状イベントを引き起こし得る。問題の中には、観測可能
なイベントであるものもあるが、一般には必ずしも観測
可能ではない。そのため複数の症状から障害の根本原因
である問題を特定する必要がある。したがって、ネット
ワーク管理者は、根本原因の問題を特定するために、観
測される種々の症状イベントを問題と相関させることが
できなければならない。

【０００９】しかし、ネットワークが大規模になると、
観測される症状イベントの数も膨大になる。またどの問
題がどの症状を引き起こすかという「因果関係」とでも
言うべきものも複雑になってくるために、オペレータが
手作業で障害の根本原因の問題を特定することはほとん
ど不可能となる。

【００１０】このようなネットワーク上で観測される膨
大な障害の症状イベントから根本原因の問題を正確にか
つ高速に特定するための従来技術手法として、１９９６
年６月１８日発行の米国特許第５，５２８，５１６号
（「Apparatus and Method forEvent Correlation and
Problem Reporting（イベント相関および問題報告装置
および方法）」）が提案されている。

【００１１】この従来技術は次の２つの技術に分けるこ
とができる。（１）管理対象ネットワークのモデリング技術（２）イベント相関技術前者の「管理対象ネットワークのモデリング技術」と
は、実際のネットワーク上で発生する問題イベントおよ
び症状イベントをいかに正確に効率よくモデル化するか
ということに関する。後者のイベント相関技術とは、主
として、観測される膨大な症状イベントからいかに高速
に根本原因である問題を特定するか、ということに関す
る。本発明は（２）のイベント相関技術に関連する。そ
のため以下では（１）の管理対象ネットワークのモデリ
ング技術については、本願発明の理解の上で必要な最小
限の説明にとどめる。なお以下の説明は、障害に関する
イベントに限定して行なうが、イベントの種類はどのよ
うなものであってもよく、本発明は障害に関するイベン
トのみに制約されるものではない。

【００１２】この従来技術で提案されている「管理対象
ネットワークのモデリング技術」について以下に簡単に
説明する。まず、ルータおよびハブなどのネットワーク
機器と、パーソナルコンピュータおよびワークステーシ
ョンなどのコンピュータと、これらを接続するネットワ
ークそのものと、コンピュータ等の上で実行されるソフ
トウェア等とからなるすべてのものを管理対象オブジェ
クトManagedObject （ＭＯ）としてモデル化する。そし
て、管理対象オブジェクト間の「関係」を重要視し、ネ
ットワーク上で発生する問題イベントおよび症状イベン
トは、管理対象オブジェクト間に設定された関係に沿っ
て「伝播」するものとしてイベントの伝播をモデル化す
る。

【００１３】上述の従来技術では、このような管理対象
オブジェクトのモデル化およびイベント伝播のモデル化
の静的な側面を抽象化し、モデル化を効率的に行なうた
めにオブジェクト指向の概念を導入している。すなわち
種々の管理対象オブジェクトをクラスとしてモデル化す
る。そしてクラス間の関係を定義する。さらにあるイベ
ントは、クラス間の関係に沿って伝播するものとしてモ
デル化される。オブジェクト指向技術については種々の
教科書があるのでそれらを参照されたい。

【００１４】まず、管理対象オブジェクトクラスのモデ
ル化について説明する。図１１に、上述の従来技術で提
案されている管理対象オブジェクトモデル（クラス階
層）を示す。図１１および他の図面において、管理対象
オブジェクトモデルについてはＯＭＴ記法を用いて記
す。図１１を参照して、各ボックスはオブジェクトクラ
スを示す。オブジェクトクラスの各ボックスは２つのボ
ックスに分割されている。上部のボックスに記載されて
いるのはオブジェクトクラス名であり、下部のボックス
に記載されているのはそのクラスのオブジェクトが持つ
べき属性である。各クラス間には関係が設定され、各関
係はクラス間に引かれた線で示されている。各線の近傍
には、その関係の名称が記載されている。

【００１５】図１１に示されるモデルは、ManagedObjec
t クラス110 と、Element クラス112 と、Layer クラス
114 と、Group クラス116 と、Resourceクラス118 と、
PhysicalService クラス120 と、LogicalServiceクラス
122 と、Nodeクラス124 と、Linkクラス126 と、Manage
r クラス128 とを含む。Manager クラス128 がネットワ
ーク管理システムのクラスである。

【００１６】これらクラス間に設定される関係は、その
関係により結びつけられる２つのクラスのいずれから見
るかによって名称が変わる。たとえばManager クラス12
8 とResourceクラス118 との関係は、Manager クラス12
8 から見ればManages 、Resourceクラス118 から見れば
Managed-byとなる。またたとえばNodeクラス124 とLink
クラス126 との間の関係208 は一方から見ればConnecte
d-via 、他方から見ればConnected-toである。またたと
えばElement クラス112 から出て同じクラス内に戻る関
係206 （Layered-overとUnderlying）のように、同一ク
ラス内のオブジェクト間に定められる関係もある。

【００１７】こうして定められたクラスシステムにもと
づいて、管理対象のネットワークをモデル化する。すな
わち、ネットワーク内の管理対象オブジェクトをあるク
ラスの一つのインスタンスとして抽象化し、そのインス
タンスが属するクラスと、他のインスタンスが属するク
ラスとの間に設定された関係にしたがってイベントがこ
れらインスタンス（管理対象オブジェクト）を伝播して
いくものとしてネットワークをモデル化する。さらに、
こうしてモデル化されたネットワークに基づき、問題
と、症状との間の相関を予め特定する。

【００１８】まず、管理対象オブジェクトクラスのモデ
ル化について説明する。今、実際のネットワークの例と
して図１２に示されるネットワークを考える。このネッ
トワークは、互いにブリッジ140 によって結合された２
つのイーサネットワーク134およびイーサネットワーク1
36 を含む。一方のイーサネットワーク134 にはホス
ト130 が、他方のイーサネットワーク136 にはホスト13
2 がそれぞれ接続されているものとする。以下の例では
ホスト130 にネットワーク管理システム(NMS)が搭載さ
れているものとして考える。

【００１９】図１２に示されるネットワークを上述した
考え方を用いてモデル化するために次のようにする。図
１３を参照して、各ボックスはオブジェクトクラス（ま
たはサブクラス）を示す。オブジェクトクラスの各ボッ
クスは２つのボックスに分割されている。上部のボック
スに記載されているのはオブジェクトクラス名であり、
下部のボックスに記載されているのはそのクラスのオブ
ジェクトが持つべき属性である。各クラス間には関係が
設定され、各関係はクラス間に引かれた線で示されてい
る。各線の近傍には、その関係の名称が記載されてい
る。なお図１３において、管理対象オブジェクトモデル
についてはＯＭＴ記法を用いて記す。

【００２０】図１３に示されるように、Nodeクラス124
の下に３つのサブクラスTcpNode クラス154 、IpNodeク
ラス156 およびEtherNode クラス158 を定義する。さら
にLinkクラス126 のサブクラスとしてTcpLink クラス16
0 、IpLinkクラス162 、EtherLink クラス164 およびMa
cBridgeLink クラス166 を定義する。なお、各クラスに
はそのクラス特有の属性を定義する必要がある。たとえ
ばIpNodeクラスにはIP(Internet Protocol) アドレス属
性を定義するなど、である。しかし、本発明には属性の
定義は関係しないので、ここでは属性についての詳細な
説明は行わない。

【００２１】これらクラス間に設定される関係は、その
関係により結びつけられる２つのクラスのいずれから見
るかによって名称が変わる。たとえばNodeクラス124 と
Linkクラス126 との間の関係208 は一方から見ればConn
ected-via 、他方から見ればConnected-toである。また
図１３には示していないが、同一クラス内のオブジェク
ト間に定められる関係もあり得る。

【００２２】図１３に示されるクラスを用いて、図１２
に示すネットワーク例をインスタンス間の関係図として
表現することができる。こうした図は、オブジェクト指
向技術では「インスタンス図」と呼ばれる。

【００２３】図１４を参照して、ホスト130 には、それ
ぞれManager クラス、TcpNode クラス、IpNodeクラスお
よびEtherNode クラスのインスタンスであるインスタン
ス170 、172 、174 および176 が含まれる。一方ホスト
132 には、TcpNode クラス、IpNodeクラスおよびEtherN
ode クラスのインスタンスであるインスタンス182 、18
4 および186 が含まれる。インスタンス172 および182
はTcpLink クラスのインスタンス200 によって結合され
る。インスタンス174 および184 はIpLinkのインスタン
スであるインスタンス202 によって結合される。

【００２４】ブリッジ140 は、EtherNode クラス、MacB
ridgeNode クラスおよびEtherNodeクラスのインスタン
スであるインスタンス190 、192 および194 を含んでい
る。インスタンス176 および190 はEtherLink クラスの
インスタンスであるインスタンス196 により結合され
る。インスタンス194 および186 は同じくEtherLink ク
ラスのインスタンス198 により結合される。インスタン
ス190 、192 、194 、196 および198 はそれぞれインス
タンス202 と結合されている。

【００２５】このようにしてモデル化された管理対象オ
ブジェクトに対して、症状イベントの伝播ルールが予め
準備される。この伝播ルールは、障害の根本原因の問題
イベントが障害の症状イベントに伝播し、その症状イベ
ントが別の症状イベントに伝播するという関係をルール
化したものである。この伝播ルールの集合を伝播モデル
と呼ぶ。伝播モデルの例を以下に示す。

【００２６】・EtherLink がDownすれば、 Connected-t
o 関係に従ってEtherNode がDownする。

【００２７】・EtherNode がDownすれば、Underlying関
係に沿ってIpNodeがDownする。・EtherNode がDownすれば、Connected-via 関係に沿っ
てMacBridgeLink がCannotBridgingである。

【００２８】・IpNodeがDownすれば、Underlying関係に
沿ってTcpNode がDisconnectする。・TcpNode がDisconnectすれば、Connected-via 関係に
沿ってTcpLink がNotResponding である。

【００２９】・TcpLink がNotResponding であると、Co
nnected-to関係に沿ってそれに接続されるTcpNode がDi
sconnectである。

【００３０】上記したルールにおいて、Down、Disconne
ctおよびNotResponding が障害の問題イベントおよび／
または症状イベントである。イベントの中には問題イベ
ントでかつ症状イベントであるものもあるし、どちらで
もないものもある。このような伝播モデル（ルール）を
図式化して図１５に示す。図１５において、上記したイ
ベントは、管理対象オブジェクトのクラス間に定義され
ている関係に沿って伝播するという、イベント伝播のモ
デル化がなされている。図１５に示される各クラス154
、156 、158 、160 、164 および166 の間では、それ
ぞれの関係210 、212 、214 、216 、218 および220 と
いう関係（順不同）があり、上記したルールに従ってそ
れらの関係に沿ってイベントが伝播する。

【００３１】図１５に示されるイベント伝播モデルが想
定されている場合に、図１２に示され図１４にモデル化
されているネットワークでイベントがどのように伝播す
るかを以下に示す。ここでは障害の根本原因の問題とし
てEtherLink1がDown（これを「ケース１」と称する）と
EtherLink2がDown（これを「ケース２」と称する）の場
合を考える。この場合、イベント伝播モデルに従って観
測されると記載される症状イベントは図１６の表１に示
されるようになる。

【００３２】これらの表において、最も左側の列の各欄
には症状イベントが、第１行目の各欄には問題イベント
が、それぞれ記載されている。ある問題イベントの列と
ある症状イベントの行との交わる欄には、その問題イベ
ント（原因）が発生したときに、当該症状イベントが発
生するか否かを示す。この場合症状イベントが生ずる場
合に「１」を記入するものとする。たとえばEtherLink1
がDownが発生したときにはEcpNode1.Disconnect が生じ
るが、EtherNode2.Down は生じない。なお各インスタン
ス名は図１４に記載のものを用いる。

【００３３】各ケースについて該当の列を縦に見ていく
と、「１」および「空白（０）」を連ねたものが得られ
る。これを当該問題イベントに対する症状イベント群の
コードと称する。たとえば表１（図１６) のケース１で
は症状イベント群のコードは「１１０１１０１１０１」
である。未記入（空白）の箇所は０としてある。

【００３４】図１６に示される表１からわかるように、
問題イベントが異なると、観測される症状イベント群の
コードが異なる。したがって実際にネットワーク管理シ
ステム（NMS ）により観測および収集される症状イベン
ト群と、図１６の表１に示される症状イベント群とを比
較することにより、障害の根本原因の問題を特定するこ
とが可能となる。このように、各問題と症状イベントと
の相関関係を表したものをＰＳマトリクスまたは問題と
症状イベント群との相関マトリクスと呼ぶ。実際にはこ
の比較は、得られた症状イベント群と、ＰＳマトリクス
の症状イベント群との間に定義される「距離」（または
類似の尺度）を計算し、最も距離の小さい問題（または
最も類似の尺度の大きな問題）を特定することにより行
なわれる。

【００３５】一般に、管理対象ネットワークが巨大とな
り、管理対象オブジェクト数が増えると、それに伴って
問題イベント数および症状イベント数が膨大な数とな
る。そのためＰＳマトリクスは巨大なマトリクスとな
る。すると、メモリの都合などによって１台のネットワ
ーク管理システムでは巨大なネットワークを集中管理す
ることが困難となり、複数のネットワーク管理システム
で管理対象ネットワークを分散管理する必要が生じる。

【００３６】従来技術では、分散環境でのイベント相関
を以下のようにして解決しようとしている。すなわち、
あるドメインのモデルを考えるときには、他のドメイン
については、当該他のドメインを代表する特別な管理対
象オブジェクトとして表現する。そして各ドメインごと
にＰＳマトリクスを生成してドメインごとに個別にイベ
ント相関を行う。従来技術に関する文献では、enterpri
seドメインとrouterドメインとが設けられ、enterprise
ドメインの観点からは routerドメインはrouter backb
one オブジェクトを表すものとして、Linkの特別な場合
としてモデル化している。そして、一方のドメインでの
イベントが他方のドメインでのイベントの症状イベント
である可能性があるので、そのイベントを症状イベント
として他方のドメインに通知し、当該他のドメインが、
通知された症状イベントをも考慮してＰＳマトリクスを
用いてイベント相関を行う。各ドメインでのＰＳマトリ
クスの形式の例を図１７に示す。

【００３７】

【発明が解決しようとする課題】このようにある問題イ
ベントに対して生ずる症状イベントを予めパターン化し
ておけば、実際に障害が生じたときの症状パターンとこ
のパターンとを比較するという比較的単純な作業により
障害の根本原因の問題を特定することができる。したが
って、この従来の技術により障害の根本原因の問題の特
定が非常に容易になるかと思われる。しかしこの従来の
技術には次のような問題点がある。

【００３８】上記した従来技術のようなＰＳマトリクス
を用いる方法では、ドメイン間の管理対象オブジェクト
（境界管理対象オブジェクト）でイベント伝播が集約さ
れる。そのため、複数個のドメインにまたがるクロスド
メイン全体としては正確なイベント相関ができない可能
性がある。また、境界管理対象オブジェクトを、分散環
境を考慮した特別な管理対象オブジェクトとしてモデル
化する必要がある。さらに、個々のドメインでＰＳマト
リクスを形成して個々のドメインで生ずるイベントと問
題との相関付けを行うため、あるドメインでの症状イベ
ントと、他のドメインでの問題イベントとの間の関連付
けをするための情報が基本的に欠落するという問題があ
る。

【００３９】それゆえに本願発明の目的は、分散環境で
効果的に問題の特定を行うことができるネットワーク管
理システムを提供することである。

【００４０】本願発明の他の目的は、分散環境で効果的
に問題の特定を行うためのＰＳマトリクスを作成するこ
とができるネットワーク管理システムを提供することで
ある。

【００４１】本願発明の他の目的は、分散環境で効果的
に問題の特定を行うためのＰＳマトリクスを用いてクロ
スドメインでの問題特定を行うことができるネットワー
ク管理システムを提供することである。

【００４２】

【課題を解決するための手段】請求項１に記載の発明に
かかるネットワーク管理システムは、自己の属するネッ
トワークにおける問題を特定する際に参照される問題と
症状パターンとの相関マトリクスを分散管理するための
ネットワーク管理システムである。このシステムは、他
のネットワーク管理システムと交信するための関係シス
テム交信手段と、管理対象のドメインの構成情報データ
および障害情報データを取得するためのデータ取得手段
と、管理対象オブジェクトモデルと、オブジェクトクラ
ス間に定義されたイベントの伝播モデルと、データ取得
手段により取得された構成情報データと、自己の管理す
るドメインでの管理の対象となる問題イベントリスト
と、関係システム交信手段を介して他ネットワーク管理
システムから与えられる、他ドメインから伝播する症状
イベント情報とに基づき、自己の管理するドメインでの
症状イベントと、ネットワーク全体での管理の対象とな
る問題イベントとの間の部分相関マトリクスを生成する
ための部分相関マトリクス生成手段と、部分相関マトリ
クス生成手段によるマトリクス生成の過程で、他ドメイ
ンに伝播する症状イベントを検出し、当該症状イベント
の原因となる問題イベントの識別子とともに、当該他ド
メインを管理する他ネットワーク管理システムに対して
関係システム交信手段を介して相関マトリクス生成継続
要求を送信するための手段とを含む。

【００４３】症状イベントのドメイン間での伝播を問題
イベントの識別子とともに各ネットワーク管理システム
の間で交信するので、各ネットワーク管理システムで
は、自己の管理するドメインでの症状イベントと、ネッ
トワーク全体での管理の対象となる問題イベントとの間
の部分相関マトリクスを生成することができる。この部
分相関マトリクスには、従来と異なり問題イベントと症
状イベントとのドメインが異なったときの情報の欠落が
ない。したがって、この部分相関マトリクスを用いて、
従来の方式よりも正確な問題の推定を行うことができ
る。

【００４４】請求項２に記載の発明にかかるネットワー
ク管理システムは、請求項１に記載の発明の構成に加え
て、さらに、データ取得手段により取得される、自己の
管理するドメイン内で生じる症状イベントパターンと、
部分相関マトリクスとの比較に基づいて、ネットワーク
上で発生した問題イベントを特定し、所定の送信先に対
して通知するための手段を含む。

【００４５】各ネットワーク管理システムでの部分相関
マトリクスによる問題の特定の結果を所定の送信先に送
信することにより、当該送信先では、複数個のドメイン
からの問題の特定結果を参照することができ、これらの
うちから最も可能性の高い問題を根本原因として特定す
ることができる。

【００４６】請求項３に記載の発明にかかるネットワー
ク管理システムは、所定のネットワーク内で生ずる症状
イベントから、ネットワーク障害の原因を推定するため
のネットワーク管理システムであって、複数個のワーカ
ネットワーク管理システムと、これら複数個のワーカネ
ットワーク管理システムの各々と接続されたマスタネッ
トワーク管理システムとを含む。各ワーカネットワーク
管理システムは、マスタネットワーク管理システムと交
信するための交信手段と、管理対象のドメインの構成情
報データおよび障害情報データを取得するためのデータ
取得手段と、管理対象オブジェクトモデルと、オブジェ
クトクラス間に定義されたイベントの伝播モデルと、デ
ータ取得手段により取得された構成情報データと、自己
の管理するドメインでの管理の対象となる問題イベント
リストと、交信手段を介してマスタネットワーク管理シ
ステムから与えられる、他ドメインから伝播する症状イ
ベント情報とに基づき、自己の管理するドメインでの症
状イベントと、ネットワーク全体での管理の対象となる
問題イベントとの間の部分相関マトリクスを生成するた
めの部分相関マトリクス生成手段と、部分相関マトリク
ス生成手段によるマトリクス生成の過程で、他ドメイン
に伝播する症状イベントを検出し、当該症状イベントの
原因となる問題イベントの識別子と、当該他ドメインを
管理するワーカネットワーク管理システムの識別子とを
含む相関マトリクス生成継続要求を、関係システム交信
手段を介してマスタネットワーク管理システムに対して
送信するための手段とを含む。マスタネットワーク管理
システムは、各ワーカネットワーク管理手段からの相関
マトリクス生成継続要求を、識別子により特定されるワ
ーカネットワーク管理システムに送信するための手段を
含む。

【００４７】症状イベントのドメイン間での伝播をマス
タネットワーク管理システムを介して各ワーカネットワ
ーク管理システムの間で交信するので、各ワーカネット
ワーク管理システムでは、自己の管理するドメインでの
症状イベントと、ネットワーク全体での管理の対象とな
る問題イベントとの間の部分相関マトリクスを生成する
ことができる。この部分相関マトリクスには、従来と異
なり問題イベントと症状イベントとのドメインが異なっ
たときの情報の欠落がない。したがって、この部分相関
マトリクスを用いて、従来の方式よりも正確な問題の推
定を行うことができる。

【００４８】請求項４に記載の発明にかかるネットワー
ク管理システムは、請求項３に記載のシステムであっ
て、各ワーカネットワーク管理システムは、部分相関マ
トリクス生成手段による部分相関マトリクスの生成の完
了に応答して終了通知をマスタネットワーク管理システ
ムに送信するための手段をさらに含む。マスタネットワ
ーク管理手段は、全てのワーカネットワーク管理システ
ムから終了通知を受信したことに応答して、各ワーカネ
ットワーク管理システムに対して相関処理の開始を指令
するための手段をさらに含む。各ワーカネットワーク管
理システムは、この指令に応答して、自己の管理するド
メイン内で生じる症状イベントパターンと、部分相関マ
トリクスとの比較を行う処理を開始し、自己の管理する
ドメイン内で発生した可能性の高い問題イベントを特定
し、マスタネットワーク管理システムに対して通知する
ための手段をさらに含む。そしてマスタネットワーク管
理システムは、各ワーカネットワーク管理システムから
の、発生した可能性の高い問題イベントについての通知
に基づいてネットワークの障害の可能な根本原因を特定
するための手段をさらに含む。

【００４９】各ワーカネットワーク管理システムでの部
分相関マトリクスによる問題の特定の結果をマスタネッ
トワーク管理システムに送信することにより、マスタネ
ットワーク管理システムでは、複数個のドメインからの
問題の特定結果を参照することができ、これらのうちか
ら最も可能性の高い問題を根本原因として特定すること
ができる。

【００５０】請求項５に記載の発明にかかるネットワー
ク管理システムは、所定のネットワーク内で生ずる症状
イベントから、ネットワーク障害の原因を推定するため
のネットワーク管理システムであって、複数個のワーカ
ネットワーク管理システムと、これら複数個のワーカネ
ットワーク管理システムの各々と接続されたマスタネッ
トワーク管理システムとを含む。各ワーカネットワーク
管理システムは、マスタネットワーク管理システムと交
信するための交信手段と、管理対象のドメインの構成情
報データおよび障害情報データを取得するためのデータ
取得手段とを含む。マスタネットワーク管理システム
は、各ワーカネットワーク管理手段からネットワークの
管理対象オブジェクト識別名と、管理対象オブジェクト
クラス名と、管理対象オブジェクト間の接続関係情報と
を取得して、ネットワークにおける問題イベントと症状
イベントとの相関マトリクスを生成するための手段と、
当該相関マトリクスを各ワーカネットワーク管理システ
ムごとに、各ワーカネットワーク管理システムが管理す
るドメインでの発生が想定される症状イベントに基づい
て分割した部分相関マトリクスを当該ワーカネットワー
ク管理システムに送信するための手段とを含む。各ワー
カネットワーク管理システムは前記部分相関マトリクス
を保持するための手段と、自己の管理するドメインの症
状イベントパターンと部分相関マトリクスとを比較する
ことにより、ネットワーク内の障害の原因である可能性
の高い問題イベントを特定してマスタネットワーク管理
システムに通知するための手段とを含む。マスタネット
ワーク管理システムは、各ワーカネットワーク管理シス
テムからの、発生した可能性の高い問題イベントについ
ての通知に基づいてネットワークの障害の可能な根本原
因を特定するための手段をさらに含む。

【００５１】請求項５に記載の発明によれば、管理対象
のネットワーク全体での相関マトリクスをマスタネット
ワークで生成し、これを分割した部分相関マトリクスを
各ワーカネットワーク管理システムに送信する。この部
分相関マトリクスには、従来と異なり問題イベントと症
状イベントとのドメインが異なったときの情報の欠落が
ない。したがって、この部分相関マトリクスを用いて、
各ワーカネットワーク管理システムで問題の特定を行う
際に、従来の方式よりも正確な問題の推定を行うことが
できる。

【００５２】

【発明の実施の形態】上記した問題点の原因は、各ドメ
インでＰＳマトリクスを生成し、個別に問題イベント特
定のための処理をすることにある。本願発明は、この従
来技術の問題点を解決するために、クロスドメイン全体
として１つのＰＳマトリクスを生成し、クロスドメイン
全体として根本の原因である問題イベントを特定するた
めに、データを分散管理し、処理を分散させることとし
た。なお「クロスドメイン」とは、以下に述べるように
ネットワーク全体を複数のドメインに分けた場合の、複
数ドメインにわたる領域のことをいう。また以下の説明
でも、「ＭＯ」とは管理対象オブジェクトモデルのこと
を指す。

【００５３】こうした処理を行うための枠組みを、本願
発明では以下のようにして実現した。まず、イベント相
関処理について考えると、イベント相関処理は以下の二
つの処理に分けることができる。

【００５４】（１）ＰＳマトリクスの生成（２）観測SymptomSet相関処理 SymptomSetとは、実際に観測されるSymptom の集合であ
って、SymptomSet[S11', S12', ..., S1n1', S21', S2
2', ..., S2n2', S31', S32', ..., S3n3' ] のように
表現することとする。相関処理では、入力SymptomSetと
ＰＳマトリクスの各列との距離を求めて、その距離が最
小となる問題P を特定する。

【００５５】＜第１の実施の形態＞［システム構成］図１を参照して、本願発明に係るネッ
トワーク管理システムで用いるＰＳマトリクス９０は、
図１７に示される従来のものと異なり、全体として一つ
のＰＳマトリクス９０として管理される。このＰＳマト
リクス９０を、全体としてＰＳマトリクス９０を構成す
るようにデータを分散させて管理する。以下の実施の形
態のシステムではＰＳマトリクス９０を横方向の部分マ
トリクス９２、９４、９６に分割して、別々のドメイン
で管理する。なお、本実施の形態のシステムでは管理対
象ネットワークは図１にも示されるように３つのドメイ
ンＡ、Ｂ、Ｃに分割されるものとする。図１に示すＰＳ
マトリクス９０では、従来技術では欠落していた領域
［Ａ２］，［Ａ３］，［Ｂ１］，［Ｂ３］，［Ｃ１］，
［Ｃ２］の部分の情報も相関処理で利用することができ
る。なお、ドメイン数が３に限定されないことはもちろ
んである。

【００５６】ＰＳマトリクス９０を分散管理するために
は、ＰＳマトリクス９０を図１における縦方向に分割す
ることも考えられる。ただし、横方向に分割すると、各
ドメインを管理するNMS において貯えられた入力症状イ
ベントの集合を、他のドメインのNMS に移動させる必要
がないのでより好ましい。

【００５７】図２を参照して、本実施の形態のシステム
では、上述した分散処理を実現するためにマスタ・ワー
カ・モデルを採用した。すなわち、本ネットワーク管理
システムは、第１のドメイン７８を管理するためのワー
カＮＭＳ７２と、第２のドメイン８０を管理するための
ワーカＮＭＳ７４と、第３のドメイン８２を管理するた
めのワーカＮＭＳ７６と、これらワーカＮＭＳ７２、７
４、７６を統括するマスタＮＭＳ７０とを含む。

【００５８】マスタＮＭＳ７０のカバーする対象ドメイ
ンは、（１）統合ドメイン（２）イベント相関に関係する複数のドメインの集合（３）イベント相関に関係のない管理対象オブジェク
トを予め除外できる場合は、管理対象オブジェクトのク
ラス名、ある属性の値の関係（等しい／大小）などの条
件によりそれらの管理対象オブジェクトを除いて絞り込
んだクロスドメインのドメインなどが考えられる。

【００５９】各ワーカＮＭＳ７２，７４，７６は、図１
に示す部分マトリクス９２、９４、９６をそれぞれ管理
する。これら部分マトリクス９２、９４、９６の作成方
法については後述する。

【００６０】図３を参照して、本願発明マスタＮＭＳ７
０、ワーカＮＭＳ７２、７４、７６などを構成するネッ
トワーク管理システム２０は、管理対象ネットワーク２
２に接続され、SNMP（Simple Network Management Prot
ocol）等のネットワーク管理プロトコルを用いて管理対
象装置のMIB （Management Information Base ）等のデ
ータを取得したり、ポーリングしたり、管理対象装置か
らのTrapイベントを受信したりするためのネットワーク
管理インターフェイス部２４と、管理対象オブジェクト
モデルと、これに関連したイベント伝播モデルとを保持
する機能と、これらモデルとネットワークの構成情報と
に基づき管理対象オブジェクト構成情報を構築する機能
と、自己の保持する管理対象オブジェクトモデルと、伝
播モデルと、管理対象オブジェクトとを用いてＰＳマト
リクスを構築するための構成管理部３０と、構成管理部
３０により構築された管理対象オブジェクト構成情報を
保持するための管理対象オブジェクトリポジトリ３２
と、構成情報データおよび障害情報データをイベントと
して保持するためのイベントリポジトリ２８と、ネット
ワーク管理インターフェイス部２４から構成情報データ
および障害情報データを受取り、イベントリポジトリ２
８に保持させるためのイベントデータベース部２６と、
構成管理部３０からＰＳマトリクスを受取って保持し、
イベントデータベース部２６から障害の症状イベントの
集合を受けて、ＰＳマトリクスと、実際に観測される症
状イベントの集合とを比較し距離計算をして、障害の根
本原因の問題を推論するための障害管理部３４と、障害
管理部３４から障害の根本原因の問題の推論結果を示す
情報を受け、ユーザに提示するためのユーザインターフ
ェイス部３６と、マスタＮＭＳとワーカＮＭＳ間で要求
や通知などを行うための関係ＮＭＳインターフェイス部
３８とを含む。

【００６１】マスタＮＭＳ７０、ワーカＮＭＳ７２、７
４、７６などによるＰＳマトリクスの生成およびイベン
ト相関の処理については後述する。

【００６２】図３に示されるネットワーク管理システム
は、実際にはパーソナルコンピュータまたはワークステ
ーションなど、コンピュータ上で実行されるソフトウェ
アにより実現される。図４に、ネットワーク管理システ
ムを実現するコンピュータの外観を示す。図４を参照し
てこのコンピュータは、ＣＤ−ＲＯＭ（Compact DiscRe
ad-Only Memory ）ドライブ５０およびＦＤ（Flexible
Disk ）ドライブ５２を備えたコンピュータ本体４０
と、ディスプレイ４２と、プリンタ４４と、キーボード
４６と、マウス４８とを含む。

【００６３】図５に、このコンピュータの構成をブロッ
ク図形式で示す。図５に示されるようにこのネットワー
ク管理システム２０を構成するコンピュータ本体４０
は、ＣＤ−ＲＯＭドライブ５０およびＦＤドライブ５２
に加えて、それぞれバス６６に接続されたＣＰＵ（Ce
ntral Processing Unit ）５６と、ＲＯＭ（Read Onl
y Memory) ５８と、ＲＡＭ（Random Access Memory）
６０と、ハードディスク５４とを含んでいる。ＣＤ−Ｒ
ＯＭドライブ５０にはＣＤ−ＲＯＭ６２が装着される。
ＦＤドライブ５２にはＦＤ６４が装着される。

【００６４】既に述べたようにこのネットワーク管理シ
ステムは、コンピュータハードウェアと、ＣＰＵ５６に
より実行されるソフトウェアとにより実現される。一般
的にこうしたソフトウェアは、ＣＤ−ＲＯＭ６２、ＦＤ
６４などの記憶媒体に格納されて流通し、ＣＤ−ＲＯＭ
ドライブ５０またはＦＤドライブ５２などにより記憶媒
体から読取られてハードディスク５４に一旦格納され
る。さらにハードディスク５４からＲＡＭ６０に読出さ
れてＣＰＵ５６により実行される。図４および図５に示
したコンピュータのハードウェア自体は一般的なもので
ある。したがって、本発明の最も本質的な部分はＣＤ−
ＲＯＭ６２、ＦＤ６４、ハードディスク５４などの記憶
媒体に記憶されたソフトウェアである。

【００６５】なお図４および図５に示したコンピュータ
自体の動作は周知であるので、ここではその詳細な説明
は繰返さない。

【００６６】［システムの動作］以下、図１〜図５に示
す本願発明の実施の形態に係るネットワーク管理システ
ム２０の動作について、さらに図６〜図９をも参照して
説明する。ネットワーク管理インターフェイス部２４
は、SNMP等のネットワーク管理プロトコルを用いて、管
理対象装置のMIB 等のデータを取得したりポーリングし
たりする。またネットワーク管理インターフェイス部２
４は、管理対象装置からのTrapイベントを受信する。ネ
ットワーク管理インターフェイス部２４はさらに、管理
対象装置から取得したデータのうち構成情報に関するデ
ータは構成管理部３０に、障害情報に関するデータはイ
ベントデータベース部２６に、それぞれ適当な形式に変
換して送る。

【００６７】構成管理部３０は、図１１および図１３に
示すような管理対象オブジェクトモデルと、これに関連
した図１５に示したようなイベント伝播モデルとを保持
する。なおこれらモデルは、図５に示すハードディスク
５４内のファイル（図示せず）から読込むこともできる
し、ユーザインターフェイス部３６を介してユーザが入
力することも可能である。

【００６８】構成管理部３０はさらに、ネットワーク管
理インターフェイス部２４から図１２に示されるネット
ワーク例のような構成情報データを受取り、管理対象オ
ブジェクトモデルに基づいて図１４に示されるような管
理対象オブジェクト構成情報を構築する。この管理対象
オブジェクト構成情報は管理対象オブジェクトリポジト
リ３２に保持される。

【００６９】構成管理部３０はまた、自己の保持する管
理対象オブジェクトモデル、イベント伝播モデル、およ
び管理対象オブジェクトリポジトリ３２の管理対象オブ
ジェクト構成情報を用いて、図１に示すようなＰＳマト
リクス９０を生成し、障害管理部３４に通知する。ワー
カＮＭＳでは、マスタＮＭＳから関係ＮＭＳインターフ
ェイス部３８を通じて問題イベントリストが通知され
る。なお、問題イベントの指定はイベント伝播モデル記
述時にも可能であるし、ユーザインターフェイス部３６
からユーザが症状イベントパターンマトリクスの生成を
要求する際に、イベント伝播モデルを参照しながら指定
することも可能である。

【００７０】イベントデータベース部２６は、構成情報
データおよび障害情報データをイベントとしてネットワ
ーク管理インターフェイス部２４から受けて、それらを
イベントリポジトリ２８に保持する。イベントデータベ
ース部２６はこれらイベントの中で、障害情報に関する
データ、特に障害の症状イベントを障害管理部３４に通
知する。

【００７１】障害管理部３４は、構成管理部３０からＰ
Ｓマトリクスを受け取り保持する。障害管理部３４はま
た、イベントデータベース部２６から障害の症状イベン
トの集合（前述した、実際に観測される症状イベントパ
ターン）を受取る。障害管理部３４は、構成管理部３０
から受取ったＰＳマトリクスと、イベントデータベース
部２６から受取った実際に観測された症状イベントパタ
ーンとを比較して、障害の根本原因の問題の候補を特定
する。特定された問題の候補はユーザインターフェイス
部３６に通知される。

【００７２】ユーザインターフェイス部３６は、図４お
よび図５に示されるディスプレイ４２などによりこの障
害の根本原因の問題の候補をユーザに提示する。このと
き、計算された相違度が最も小さい障害原因のみを提示
してもよいし、相違度の小さいものから順に予め定めら
れた個数だけ候補として提示するようにしてもよい。複
数個提示する場合には、伝播モデルが完全でない場合、
または観測した症状イベントにノイズ（発生するはずの
症状イベントが観測されなかったり、関係のない症状イ
ベントが観測されたりすること）が含まれる場合でも、
候補リストの中に正しい解が含まれる可能性が高くな
る。またこのリストの提示を受けて利用者が実際に候補
としてあげられたネットワーク機器を調べることによ
り、最終的に原因を特定することが容易になる。

【００７３】または、あるしきい値を設けておき、その
しきい値よりも小さな相違度を有する障害原因を表示す
るようにしてもよい。この方法は、経験的に、相違度が
ある値以下の障害原因の中に真の障害原因が含まれる可
能性が高いということが分かっている場合に、それらを
全て利用者に通知するので、利用者は効率的に障害原因
を探ることができて有利である。

【００７４】［ＰＳマトリクスの作成処理］ＰＳマトリ
クス９０の作成は以下のようにして行われる。なお、Ｐ
Ｓマトリクス９０は、前述のように横方向の部分マトリ
クス９２、９４、９６に分割される。このように分割さ
れた部分マトリクス９２、９４、９６はそれぞれワーカ
ＮＭＳ７２、７４、７６が保持する。これは、イベント
相関処理のために各ＮＭＳで貯えられた入力SymptomSet
をＮＭＳ間で移動させる必要がなく、そのまま処理でき
るからである。

【００７５】［マスタＮＭＳ７０での処理］図６を参照
して、まずマスタＮＭＳ７０で、利用者がサブスクライ
ブしたいProblem リストを設定する。「サブスクライ
ブ」とは、ある問題について通知を要求することをい
う。マスタＮＭＳ７０はそのProblem リストを各ドメイ
ンごとに分類し、ワーカＮＭＳ７２、７４、７６に通知
する（２５０）。ワーカＮＭＳ７２、７４、７６は後述
するように各々、この通知をトリガーとしてＰＳマトリ
クスの作成を開始する。ＰＳマトリクスワーカＮＭＳ７
２、７４、７６はそれぞれ、図１に示した部分マトリク
ス９２、９４、９６の作成を担当する。その処理の詳細
については後述する。

【００７６】例えばワーカＮＭＳ７４は、第１のドメイ
ン７８のProblem リスト[P11, P12,..., P1m1] の各々
の問題に対して、まず第１のドメイン７８のトポロジー
情報（管理対象オブジェクト構成情報）およびイベント
伝播モデルを用いて図１のマトリクスの［Ａ１］の部分
を生成していく。

【００７７】ワーカＮＭＳ７２はさらに、境界ＭＯのSy
mptom に到達すると、マスタＮＭＳ７０に対してＰＳマ
トリクス生成係属要求（境界ＭＯを管理する他ＮＭＳ
名、ProblemID 、境界ＭＯ名、Symptom 名）を送信す
る。ここで、ProblemID とは、ＭＯ名＋Problem 名で一
意に特定されるProblem 識別子である。同様に、Sympto
mID は、ＭＯ名＋Symptom 名で一意に特定されるSympto
m 識別子である。ＭＯ名はドメイン内で一意になるよう
に、構成管理部３０で管理されており、ＭＯ名からその
管理対象オブジェクトのクラス（ＭＯクラス）を識別で
きる。ＭＯクラスが特定できると、イベント伝播モデル
すなわち各Symptom のイベント伝播が分かるものとす
る。

【００７８】再び図６を参照して、マスタＮＭＳ７０
は、この要求があるかないかを判定し（２５２）、ある
場合にはこれに応答して、境界ＭＯを管理する他ＮＭＳ
に対してＰＳマトリクス生成継続要求（ProblemID 、境
界ＭＯ名、Symptom 名）を送信する（２５４）。

【００７９】ワーカＮＭＳ７４、７６ではそれぞれ、こ
の要求メッセージをトリガーとして、自分の担当するド
メインのトポロジー情報を用いて図１の［Ｂ１］、［Ｃ
１］を埋めていく。ワーカＮＭＳ７２は逆に、他のワー
カＮＭＳ７４、７６のProblem からスタートして、自己
のドメインのトポロジー情報を用いて図１の［Ａ２］、
［Ａ３］を埋めていく。こうした処理をワーカＮＭＳ７
２、７４、７６の間で相互に行うことにより図１のＰＳ
マトリクス９０を構成する部分マトリクス９２、９４、
９６がそれぞれ形成される。

【００８０】ワーカＮＭＳ７２、７４、７６はそれぞ
れ、あるProblem についてＰＳマトリクスの生成処理を
進める。この場合、そのProblem は各自の担当するドメ
インのProblem とは限らない。ワーカＮＭＳ７２、７
４、７６は、あるProblem に対する全てのイベント伝播
が終了し末端のSymptom まで到達すると、次のProblem
の処理に移る。処理すべき全てのProblem のＰＳマトリ
クス生成が終了すると、マスタＮＭＳ７０に対して自己
の担当分のＰＳマトリクス生成が終了したことを通知す
る。ワーカＮＭＳ７２、７４、７６は、一度自己のＰＳ
マトリクス生成が終了しても、ＰＳマトリクス生成継続
要求を受信すると、またＰＳマトリクス生成処理を開始
し、終了すると前述したのと同様にマスタＮＭＳ７０に
対して自己の担当分のＰＳマトリクス生成が終了したこ
とを通知する。

【００８１】マスタＮＭＳ７０は、Problem リストを通
知した後または最後に生成継続要求を送信した後に全て
のワーカＮＭＳからＰＳマトリクス生成の終了通知を受
信すると、ＰＳマトリクス生成処理が完了したものと判
断し（２５６）、観測SymptomSet相関処理の開始を全て
のＮＭＳに対して要求する。

【００８２】具体的に図７を参照して上述の動作を説明
すると、まずマスタＮＭＳ７０に対して、利用者がサブ
スクライブを希望するProblem リストを設定する（３０
０）。これに応答してマスタＮＭＳ７０が各ワーカＮＭ
Ｓに対してProblem リストを通知する（３０２）。各ワ
ーカＮＭＳがこれに対してＰＳマトリクス生成処理を開
始する。

【００８３】図７に示す例では、まず第１のワーカＮＭ
Ｓ７２がＰＳマトリクス生成処理を終了し終了通知をマ
スタＮＭＳ７０に対して送信する（３０４）。続いてワ
ーカＮＭＳ７４がワーカＮＭＳ７６に対するＰＳマトリ
クス生成継続要求をマスタＮＭＳ７０に対して送信（３
０６）した後終了通知を送信する（３０８）。マスタＮ
ＭＳ７０はこのＰＳマトリクス生成継続要求３０６に応
答してワーカＮＭＳ７６に対してＰＳマトリクス生成継
続要求を送信する（３１０）。ワーカＮＭＳ７６はＰＳ
マトリクスの生成処理の実行を継続するが、ワーカＮＭ
Ｓ７４に対するＰＳマトリクス生成継続要求３１２をマ
スタＮＭＳ７０に対して送信した後、終了通知を送信す
る（３１４）。マスタＮＭＳ７０はこのＰＳマトリクス
生成継続要求３１２に応答してワーカＮＭＳ７４に対し
てＰＳマトリクス生成継続要求３１６を送信し、ワーカ
ＮＭＳ７４はこの要求に応答して、一旦終了したＰＳマ
トリクス生成処理を再開し、処理が終了すると終了通知
３１８をマスタＮＭＳ７０に対して送信する。こうし
て、マスタＮＭＳ７０は全てのワーカＮＭＳから終了通
知を受取るとＰＳマトリクスの生成処理が完了したと判
断し（３２０）、次の観測SymptomSet相関処理を開始す
る。

【００８４】［ワーカＮＭＳでのＰＳマトリクス作成処
理］各ワーカＮＭＳでのＰＳマトリクス作成処理につい
て図８を参照して説明する。まず、マスタＮＭＳ７０か
らのProblem リスト通知またはＰＳマトリクス生成継続
要求を受信すると、未処理Problem キューにProblemDat
a としてProblem リストを入れる（２６０）。各Proble
mData は情報としてProblemID と、境界ＭＯのＭＯ名で
あるInitialMO と、Symptom 名の初期値であるInitialS
ymptomと持つ。ProblemID は、前述のとおりＭＯ名とPr
oblem 名とからなる。

【００８５】続いて、未処理Problem キューが空か否か
を判定する（２６２）。空であれば処理終了である。空
でなければ未処理Problem キューからひとつだけProble
mData を取出し、SymptomData として未処理Symptom キ
ューに入れる（２６４）。SymptomData は情報としてPr
oblemID とSymptom ID（ＭＯ名とSymptom 名）とを持
つ。この処理ではProblemData のProblemID をSymptomD
ata のProblemID に代入する。またProblemData のInit
ialMO をSymptomID のＭＯ名に代入する。ProblemData
のInitialSymptomをSymptomID のSymptom 名に代入す
る。

【００８６】未処理Symptom キューが空か否かを判定す
る（２６６）。空であれば制御はステップ２６２に戻
る。空でなければ、未処理Symptom キューから１つだけ
SymptomData を取出す（２６８）。このSymptomData に
対して、そのＭＯと接続関係のあるＭＯが存在し、かつ
そのＭＯのクラスにSymptomData のSymptom からのイベ
ント伝播が定義されているか否かを判定する（２７
０）。定義されていなければ制御はステップ２６６に戻
る。

【００８７】定義されていれば、新しいSymptomData を
以下のようにして生成する（２７２）。すなわち、ＭＯ
名にはその接続関係のあるＭＯ名を、Symptom 名にはイ
ベント伝播先のSymptom を、それぞれ代入する。こうし
て生成されたSymptomData を未処理symptom キューに入
れる。また、ＰＳマトリクスの（ProblemID, SymptomI
D）に対応する欄に「１」を設定する。

【００８８】次に、SymptomData のＭＯが境界ＭＯか否
かについての判定を行い（２７４）、境界ＭＯであれば
マスタＮＭＳ７０に対してＰＳマトリクス生成継続要求
を送信して（２７６）制御をステップ２７０に戻す。境
界ＭＯでなけえれば何もせず制御をステップ２７０に戻
す。

【００８９】こうした処理によって、各ワーカＮＭＳで
は各自の担当する部分ＰＳマトリクスが生成される。

【００９０】［観測SymptomSet相関処理］この処理は非
常に簡単である。前述のとおりマスタワーカモデルで処
理する。入力SymptomSet[S11', S12', ..., S1n1', S2
1', S22', ..., S2n2', S31', S32', ..., S3n3' ]
は、以下のようにわけられる。

【００９１】・入力SymptomSet1[S11', S12', ..., S1n1'] ・入力SymptomSet2[S21', S22', ..., S2n2'] ・入力SymptomSet3[S31', S32', ..., S3n3'] これらはもともとワーカＮＭＳ７２、７４、７６で分散
管理されている。

【００９２】そして各ワーカＮＭＳは、自己の保持する
部分ＰＳマトリクスと自己に入力されるSmptomSet とを
用いて相関値（例えば距離）を計算する。たとえばワー
カＮＭＳ７２は、自己の保持する部分マトリクス９２
と、自己に入力されるSmptomSet1とを用いて相関値を計
算する。そして、全てのProblem （または上位の候補の
Problem のみ）の相関値をマスタＮＭＳに通知する。

【００９３】マスタＮＭＳ７０は、全てのワーカＮＭＳ
から結果を受取ると、各Problem ごとに相関値（距離）
を集計して最大相関値（最小距離）を持つProblem を求
める。または、上位のいくつかのProblem を候補として
選ぶ。または、所定のしきい値をこえる相関値（または
所定のしきい値より小さな距離）を持つProblem を候補
として選ぶ。

【００９４】この処理におけるマスタＮＭＳ７０と各ワ
ーカＮＭＳ７２、７４、７６との間のインタラクション
の例について図９を参照して説明する。まず、ＰＳマト
リクスの生成処理が完了すると（３２０）、マスタＮＭ
Ｓ７０は各ワーカＮＭＳ７２、７４、７６に対して観測
SymptomSet相関処理の開始要求を送信する（２８０）。
各ワーカＮＭＳ７４、７６、７８からは、処理が終了次
第順次終了通知がマスタＮＭＳ７０に対して送信されて
くる（２８２、２８４、２８６）。全ての終了通知を受
信すると、マスタＮＭＳ７０は前述した集計処理を行
い、候補のProblem を求めてユーザインターフェイス部
３６に与える（２８８）。

【００９５】こうして、分散環境での観測SymptomSet相
関処理を効率良く行うことができる。この場合、従来の
ように一箇所でＰＳマトリクスを保持する方式ではな
いので、リソースの制限に対してもＰＳマトリクスを分
散保持することで対応できるという効果がある。また、
従来のように各ドメイン別に個別にＰＳマトリクスを生
成保持して観測SymptomSet相関処理を行う場合と比較し
て欠落する情報が少なく、ネットワークが大規模になっ
ても正確な問題特定を行うことができるという効果があ
る。

【００９６】なお、この実施の形態のシステムでは、Ｐ
Ｓマトリクスの生成から各ワーカＮＭＳで分散して行っ
ている。しかし本発明はこうした方式に限定されるわけ
ではなく、ＰＳマトリクスの生成はリソースに余裕のあ
るマスタＮＭＳで行い、出来上がったＰＳマトリクスを
分割してそれぞれの部分相関マトリクスを各ワーカＮＭ
Ｓに送信するようにしてもよい。特にこの方式は、特
に、ＰＳマトリクス生成のための各ＮＭＳ間のインタラ
クションが多くなる場合であって、かつＰＳマトリクス
がそれほど大きくない場合に効果的である。なお、境界
ＭＯの数が多くなければインタラクションはそれほど発
生しないと思われる。

【００９７】一箇所でＰＳマトリクスを生成する場合に
は、必要な情報は以下のとおりである。

【００９８】・イベント伝播モデル（簡単のため、クロ
スドメインで共通とする。）・クロスドメインのトポロジー情報・サブスクライブするProblem リストこの場合には、ネットワークが大きくなるとトポロジー
情報が膨大になる可能性があるが、ＰＳマトリクス生成
に真に必要な最小限のトポロジー情報のみに絞り込めば
情報量をかなり削減することが可能である。具体的に
は、moName（ＭＯの名称）、moClassName （ＭＯのクラ
ス名）、relationship（関係：関係名と接続ＭＯ名）リ
スト程度で十分であり、構成管理の属性等は不要であ
る。

【００９９】＜第２の実施の形態＞なお、図１０に示す
ように、ネットワーク管理システム２０を、既存のネ
ットワーク管理システム１１０を介して管理対象ネット
ワーク２２に接続してもよい。

【０１００】以上、本願発明にかかるネットワーク管理
システムを実施の形態に基づいて説明してきたが、本願
発明はこれら実施の形態のシステムに限定されるわけで
はない。本願発明の権利範囲は、特許請求の範囲の各請
求項の記載によって定められるべきである。本願明細書
に開示された実施の形態の各構成要素と均等の構成要素
を用いたものも本願発明の権利範囲に含まれる。

【図面の簡単な説明】

【図１】図１は、本願発明で用いられるＰＳマトリクス
の例を示す図である。

【図２】図２は、本願発明を実施するためのマスタ・ワ
ーカ・モデルを示す図である。

【図３】図３は、本願発明の一実施の形態に係るネット
ワーク管理システムのブロック図である。

【図４】図４は、本願発明に係るネットワーク管理シス
テムを実現するためのコンピュータの外観図である。

【図５】図５は、図４に示されるコンピュータのブロッ
ク図である。

【図６】図６は、本願発明の一実施の形態のネットワー
ク管理システムのマスタＮＭＳ７０で行われる処理のフ
ローチャートである。

【図７】図７は、ＰＳマトリクス生成処理におけるマス
タＮＭＳおよびワーカＮＭＳ間のインタラクションを示
す図である。

【図８】図８は、本願発明の一実施の形態のネットワー
ク管理システムの各ワーカＮＭＳで行われるＰＳマトリ
クス作成処理のフローチャートである。

【図９】図９は、観測SymptomSet相関処理におけるマス
タＮＭＳおよびワーカＮＭＳ間のインタラクションを示
す図である。

【図１０】図１０は、本願発明の他の実施の形態にかか
るネットワーク管理システムを示すブロック図である。

【図１１】ネットワーク管理に使用される管理対象オブ
ジェクトモデルのクラス図である。

【図１２】図１２は、簡単なネットワークを模式的に示
す図である。

【図１３】図１３は、図１２に示されるネットワークの
管理対象オブジェクトモデルのクラス図である。

【図１４】図１４は、図１２に示されるネットワークの
管理対象オブジェクトを示すインスタンス図である。

【図１５】図１５は、ネットワーク管理で用いられるイ
ベント伝播モデルのクラス図である。

【図１６】図１６は、従来の症状イベント伝播モデルに
基づく症状イベントパターンを表形式で示す図である。

【図１７】図１７は、従来技術の分散環境での、各ドメ
インで使用されるＰＳマトリクスを示す図である。

【符号の説明】

２０ネットワーク管理システム２２管理対象ネットワーク２４ネットワーク管理インタフェース部２６イベントデータベース部２８イベントリポジトリ３0 構成管理部３２管理対象オブジェクトリポジトリ３４障害管理部３６ユーザインタフェース部

フロントページの続き (51)Int.Cl.⁷ 識別記号ＦＩテーマコート゛(参考）Ｈ０４Ｌ 29/14 Ｆターム(参考） 5B045 BB47 JJ02 JJ08 JJ09 JJ14 5B089 AA03 AA16 AC03 CC15 DD02 EA10 5K030 GA12 LE01 MA01 MB20 MD00 5K033 AA06 BA04 DA01 EA04 EA07 EC00 5K035 AA03 AA07 DD01 JJ01 JJ03

Claims

【特許請求の範囲】

【請求項１】自己の属するネットワークにおける問題
を特定する際に参照される問題と症状パターンとの相関
マトリクスを分散管理するためのネットワーク管理シス
テムであって、他のネットワーク管理システムと交信するための関係シ
ステム交信手段と、管理対象のドメインの構成情報データおよび障害情報デ
ータを取得するためのデータ取得手段と、管理対象オブジェクトモデルと、オブジェクトクラス間
に定義されたイベントの伝播モデルと、前記データ取得
手段により取得された構成情報データと、自己の管理す
るドメインでの管理の対象となる問題イベントリスト
と、前記関係システム交信手段を介して他ネットワーク
管理システムから与えられる、他ドメインから伝播する
症状イベント情報とに基づき、自己の管理するドメイン
での症状イベントと、ネットワーク全体での管理の対象
となる問題イベントとの間の部分相関マトリクスを生成
するための部分相関マトリクス生成手段と、前記部分相関マトリクス生成手段によるマトリクス生成
の過程で、他ドメインに伝播する症状イベントを検出
し、当該症状イベントの原因となる問題イベントの識別
子とともに、当該他ドメインを管理する他ネットワーク
管理システムに対して前記関係システム交信手段を介し
て相関マトリクス生成継続要求を送信するための手段と
を含む、ネットワーク管理システム。
【請求項２】さらに、前記データ取得手段により取得
される、自己の管理するドメイン内で生じる症状イベン
トパターンと、前記部分相関マトリクスとの比較に基づ
いて、ネットワーク上で発生した問題イベントを特定
し、所定の送信先に対して通知するための手段を含む、
請求項１に記載のネットワーク管理システム。
【請求項３】所定のネットワーク内で生ずる症状イベ
ントから、ネットワーク障害の原因を推定するためのネ
ットワーク管理システムであって、複数個のワーカネットワーク管理システムと、前記複数個のワーカネットワーク管理システムの各々と
接続されたマスタネットワーク管理システムとを含み、各前記ワーカネットワーク管理システムは、前記マスタネットワーク管理システムと交信するための
交信手段と、管理対象のドメインの構成情報データおよび障害情報デ
ータを取得するためのデータ取得手段と、管理対象オブジェクトモデルと、オブジェクトクラス間
に定義されたイベントの伝播モデルと、前記データ取得
手段により取得された構成情報データと、自己の管理す
るドメインでの管理の対象となる問題イベントリスト
と、前記交信手段を介して前記マスタネットワーク管理
システムから与えられる、他ドメインから伝播する症状
イベント情報とに基づき、自己の管理するドメインでの
症状イベントと、ネットワーク全体での管理の対象とな
る問題イベントとの間の部分相関マトリクスを生成する
ための部分相関マトリクス生成手段と、前記部分相関マトリクス生成手段によるマトリクス生成
の過程で、他ドメインに伝播する症状イベントを検出
し、当該症状イベントの原因となる問題イベントの識別
子と、当該他ドメインを管理するワーカネットワーク管
理システムの識別子とを含む相関マトリクス生成継続要
求を、前記関係システム交信手段を介して前記マスタネ
ットワーク管理システムに対して送信するための手段と
を含み、前記マスタネットワーク管理システムは、各前記ワーカネットワーク管理手段からの相関マトリク
ス生成継続要求を、識別子により特定されるワーカネッ
トワーク管理システムに送信するための手段を含む、ネ
ットワーク管理システム。
【請求項４】各前記ワーカネットワーク管理システム
は、前記部分相関マトリクス生成手段による部分相関マ
トリクスの生成の完了に応答して終了通知を前記マスタ
ネットワーク管理システムに送信するための手段をさら
に含み、前記マスタネットワーク管理手段は、全ての前記ワーカ
ネットワーク管理システムから終了通知を受信したこと
に応答して、各前記ワーカネットワーク管理システムに
対して相関処理の開始を指令するための手段をさらに含
み、各前記ワーカネットワーク管理システムは、前記指令に
応答して、自己の管理するドメイン内で生じる症状イベ
ントパターンと、前記部分相関マトリクスとの比較を行
う処理を開始し、自己の管理するドメイン内で発生した
可能性の高い問題イベントを特定し、前記マスタネット
ワーク管理システムに対して通知するための手段をさら
に含み、前記マスタネットワーク管理システムは、各前記ワーカ
ネットワーク管理システムからの、発生した可能性の高
い問題イベントについての通知に基づいて前記ネットワ
ークの障害の可能な根本原因を特定するための手段をさ
らに含む、請求項３に記載のネットワーク管理システ
ム。
【請求項５】所定のネットワーク内で生ずる症状イベ
ントから、ネットワーク障害の原因を推定するためのネ
ットワーク管理システムであって、複数個のワーカネットワーク管理システムと、前記複数個のワーカネットワーク管理システムの各々と
接続されたマスタネットワーク管理システムとを含み、各前記ワーカネットワーク管理システムは、前記マスタネットワーク管理システムと交信するための
交信手段と、管理対象のドメインの構成情報データおよび障害情報デ
ータを取得するためのデータ取得手段とを含み、前記マスタネットワーク管理システムは、各前記ワーカネットワーク管理手段からネットワークの
管理対象オブジェクト識別名と、管理対象オブジェクト
クラス名と、管理対象オブジェクト間の接続関係情報と
を取得して、ネットワークにおける問題イベントと症状
イベントとの相関マトリクスを生成するための手段と、前記相関マトリクスを各前記ワーカネットワーク管理シ
ステムごとに、各前記ワーカネットワーク管理システム
が管理するドメインでの発生が想定される症状イベント
に基づいて分割した部分相関マトリクスを当該ワーカネ
ットワーク管理システムに送信するための手段とを含
み、各前記ワーカネットワーク管理システムは前記部分相関
マトリクスを保持するための手段と、自己の管理するドメインの症状イベントパターンと前記
部分相関マトリクスとを比較することにより、ネットワ
ーク内の障害の原因である可能性の高い問題イベントを
特定して前記マスタネットワーク管理システムに通知す
るための手段とを含み、前記マスタネットワーク管理システムは、各前記ワーカ
ネットワーク管理システムからの、発生した可能性の高
い問題イベントについての通知に基づいて前記ネットワ
ークの障害の可能な根本原因を特定するための手段をさ
らに含むネットワーク管理システム。