JP2000059362A - ネットワーク障害管理システム - Google Patents

Abstract

(57)【要約】 【目的】 監視装置の位置が制約されず、かつネットワ
ークへの負荷が小さな、全ての管理作業者に必要な障害
情報を確実に伝えることが可能なネットワーク障害管理
システムを提供する。 【解決手段】 少なくとも１つの監視代理サーバと、ネ
ットワークセグメントの各々に少なくとも１つの移動エ
ージェント管理装置と、を有し、監視代理サーバは監視
装置及び移動エージェント管理装置の間においてトラッ
プの受渡しを行い、移動エージェント管理装置は管理サ
ーバからのトラップの受取り及びトラップに関する移動
エージェントの発行及び受取りを行う。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はネットワーク障害管
理システム、特に、ネットワーク資源が発行するトラッ
プを管理するネットワーク障害管理システムに関する。

【０００２】

【従来の技術】近年、ネットワークの複雑化、大規模化
が著しく進展しており、これに伴い、ネットワーク管理
の重要性が高まっている。特に、安定で効率的なネット
ワークの実現のために、ネットワーク障害の迅速で正確
な検出が不可欠である。このようなネットワーク障害の
検出方法として、例えば森工氏等による「大規模ネット
ワークにおける分類、切り分け方式を用いた障害検出シ
ステムの構築」と題する文献（信学技報Ｖｏｌ．９６
Ｎｏ．９７ ＩＮ９６−２７、５７−６４頁、電子情報
通信学会、１９９６年）に開示のものがある。かかる文
献には、おもにネットワーク上を流れるパケットの状態
の監視に使用する、ＲＭＯＮ−ＭＩＢ（Remote Monitor
ing - Management Information Base）を実装した機器
をネットワーク上に配置し、ネットワークトラフィック
を分類するための分類データベースを設け、パケットを
フィルタリングすることで重要な障害を監視する方法が
開示されている。

【０００３】しかしながら、上述したような方法では、
機器に実装されたＲＭＯＮ−ＭＩＢをベースとして監視
するため、ＲＭＯＮ−ＭＩＢを実装した機器をネットワ
ーク上のどこに配置するかで障害検出が左右されるとい
う問題があった。また、ネットワーク上を流れるパケッ
トについて障害の監視を行っているので、例えばネット
ワーク上のある機器のメモリなど、機器の内部状態の異
常による障害は検出が難しいという問題点があった。

【０００４】更に、分類データベースの更新及び参照は
ネットワーク上の多数の個所から管理作業者が分類デー
タベースにアクセスして実行することになり、一人の管
理作業者がネットワーク全体を集中的に管理するか、あ
るいは複数の管理作業者が分類データベースを更新し合
うことになり、管理作業者間で調整が必要になるという
問題点があった。更に、分類データベースは集中的にア
クセスされるので分類データベースを置いた個所は管理
のためのトラフィックが増大するという問題点があっ
た。

【０００５】

【発明が解決しようとする課題】本発明はかかる点に鑑
みてなされたものであり、その目的とするところは、監
視装置を配置する位置が制約されず全ての管理作業者に
確実にトラップを伝えることが可能なネットワーク障害
管理システムを提供することにある。また、ネットワー
クへの負荷が小さく、必要な障害情報を管理作業者に確
実に伝えることが可能なネットワーク障害管理システム
を提供することにある。

【０００６】

【課題を解決するための手段】本発明によれば、各々が
複数の情報装置及び複数の情報装置が発するトラップを
管理する少なくとも１つの管理サーバを含む複数のネッ
トワークセグメントからなるネットワークと、ネットワ
ークの障害監視を行う監視装置と、を有するネットワー
ク障害管理システムであって、少なくとも１つの監視代
理サーバと、ネットワークセグメントの各々に少なくと
も１つの移動エージェント管理装置と、を有し、監視代
理サーバは監視装置及び前記移動エージェント管理装置
の間において前記トラップの受渡しを行い、移動エージ
ェント管理装置は管理サーバからの前記トラップの受取
り及びトラップに関する移動エージェントの発行及び受
取りを行うことを特徴としている。

【０００７】

【実施の形態】以下に、本発明によるネットワーク障害
管理システムを図面を参照しつつ詳細に説明する。図１
は、本発明の第１の実施例である分散型ネットワーク障
害管理システムを有するネットワークのブロック図であ
る。

【０００８】ネットワーク全体は、複数のセグメントか
らなり、セグメント単位で分散的に動作する分散オブジ
ェクト環境を構成している。各ネットワークセグメント
３，５，７は、ネットワークで接続された計算機、プリ
ンタ、ルータ等の情報機器を有している。セグメント内
の各情報機器には、ＣＰＵやインタフェース、メモリな
どのネットワーク資源が実装されている。

【０００９】第１セグメント３は、計算機、ルータ、プ
リンタなどの情報機器１１に存在するネットワーク資源
１３を管理する資源管理部１５と、資源管理部１５から
発行されるトラップ（障害情報を担う通知情報片）をセ
グメント３内で受取り、また、セグメント３内の資源管
理部１５を管理する資源管理サーバ１７と、移動エージ
ェントの発行／受取、資源管理サーバからのトラップの
受取りを行う移動エージェント管理部１９と、を有して
いる。

【００１０】同様に、第２セグメント５は、ネットワー
ク資源２３を管理する資源管理部２５と、資源管理部２
５から発行されるトラップをセグメント５内で受取り、
また、セグメント５の資源管理部２５を管理する資源管
理サーバ２７と、移動エージェントの発行／受取、資源
管理サーバからのトラップの受取りを行う移動エージェ
ント管理部２９と、を有し、第３セグメント７は、ネッ
トワーク資源３３を管理する資源管理部３５と、資源管
理部３５から発行されるトラップをセグメント７内で受
取り、また、セグメント７内の資源管理部３５を管理す
る資源管理サーバ３７と、移動エージェントの発行／受
取、資源管理サーバからのトラップの受取りを行う移動
エージェント管理部３９と、を有している。

【００１１】このネットワークは、第１セグメント３の
移動エージェント管理部１９に接続された監視代理サー
バ（以下代理サーバと称する）４１を有している。更
に、このネットワークには、代理サーバ４１に接続され
ネットワーク資源の監視及び操作等の管理作業を行うた
めの監視装置（以下マネージャと称する）４５が含ま
れ、管理作業者はこのマネージャ４５を介して管理作業
を行うことができる。代理サーバ４１は、第１セグメン
ト３の移動エージェント管理部１９及びマネージャ４５
に接続された計算機上で稼動し、マネージャ４５と移動
エージェント管理部１９の間でトラップの受渡しを行
う。

【００１２】図２は、このネットワークの物理的な構成
を示している。図２において、第１〜３セグメント３，
５，７はルータあるいはゲートウェイ５１，５２，５３
によって互いに接続されている。各セグメント上には計
算機、プリンタなどが接続されている。ネットワーク資
源はＣＰＵやインタフェース、メモリなど各機器に実装
されている資源であり、これらの資源を管理する資源管
理部は計算機、ルータ、プリンタなどの機器上で動作し
ている。

【００１３】第１セグメント３の計算機５５ａには、マ
ネージャ４５と代理サーバ４１が置かれ、計算機５５ｃ
には移動エージェント管理部１９及び資源管理サーバ１
７が置かれている。第２セグメント５の計算機５６ｂに
は、移動エージェント管理部２９及び資源管理サーバ２
７が置かれている。また、第３セグメント７の計算機５
７ｃには、移動エージェント管理部３９及び資源管理サ
ーバ３７が置かれている。

【００１４】資源管理部から発行されたトラップをその
セグメント内で受取る資源管理サーバは少なくとも１つ
のセグメントに１つ設けられる。セグメント内の機器が
多く１つでは効率が悪い場合などには、同一セグメント
内に複数の資源管理サーバを設けてもよい。機器が発行
したトラップを資源管理サーバの次に受取る移動エージ
ェント管理部は各セグメントに少なくとも１つ設けられ
る。

【００１５】機器が発行したトラップを適当なマネージ
ャに伝える代理サーバはネットワーク全体に１つ以上設
けられる。例えば、図２には第２セグメント５の計算機
５６ｂに代理サーバを更に設けた場合を示している。最
終的なトラップの受取をするネットワーク監視装置であ
るマネージャはネットワーク全体のいずれかの場所に設
けられる。ネットワーク全体に於けるマネージャ数に制
限は無く、例えば、図２には第３セグメント７の計算機
５７ａに更に設けた場合を示している。

【００１６】次に、図３のフローチャートを参照しつ
つ、図１に示した第１の実施例のネットワーク障害管理
システムの動作について説明する。まず、資源管理部
は、機器に実装されているネットワーク資源の内部状態
が異常になった時、あるいはあらかじめ設定されている
閾値を超えた時にトラップを発行する（ステップＳ１
１）。トラップは各セグメントに１つ以上用意されてい
る資源管理サーバが受取り、同一セグメント内の移動エ
ージェント管理部に送付する（ステップＳ１２）。

【００１７】次に、トラップを受取った（ステップＳ１
３）移動エージェント管理部は、マネージャにこのトラ
ップを取り次ぎ可能な代理サーバがセグメント内に存在
するか否かを判別し（ステップＳ１４）、セグメント内
にトラップ取り次ぎ可能な代理サーバがある場合はトラ
ップを代理サーバに登録する（ステップＳ１５）。トラ
ップをマネージャに取り次ぎ可能な代理サーバがセグメ
ント内に無い場合は移動エージェント管理部において移
動エージェントを生成し、生成した移動エージェントを
他セグメントの移動エージェント管理部へ送付する（ス
テップＳ１６）。移動エージェントはトラップを持って
移動し、移動先の移動エージェント管理部では同様にし
て、トラップ取り次ぎ可能な代理サーバがセグメント内
に存在するか否かを判別し、存在する場合はトラップを
代理サーバに登録する。

【００１８】代理サーバはトラップを受取り（ステップ
Ｓ１７）、トラップ取り次ぎの該当マネージャが存在す
る否かを判別し（ステップＳ１８）、該当マネージャが
存在する場合、そのマネージャにトラップ情報を到着し
たことを通知する（ステップＳ１９）。尚、トラップ情
報を受取りたいマネージャはあらかじめ、代理サーバに
トラップ受取りの意志を登録しておく。登録情報は代理
サーバ間で共通となるよう、一定時間間隔で代理サーバ
間で情報の授受を行う。代理サーバでは登録されている
情報からトラップを取り次ぐ該当マネージャ存在の有無
を調べる。

【００１９】ステップＳ１８において、該当マネージャ
が一次的に存在しない場合（ステップＳ２０）は、トラ
ップを代理サーバが保存し、該当マネージャが現れた時
にトラップを通知する。他セグメントの代理サーバにト
ラップ受取りが登録されている場合（ステップＳ２１）
は、セグメント内に代理サーバが無かった場合と同様に
して移動エージェントを生成して、別の移動エージェン
ト管理部に移動させる（ステップＳ１６）。

【００２０】ステップＳ２１において、トラップ取り次
ぎ可能なマネージャが他セグメントの代理サーバを含む
代理サーバに登録されていない場合は、代理サーバにト
ラップ情報の通知を行った移動エージェント管理部に取
り次ぎ不可の情報を通知する（ステップＳ２２）。以上
のステップによりトラップの処理を終了する。

【００２１】以上説明したように、第１の実施例によれ
ば、ネットワーク内に代理サーバを設けて、トラップを
受取りたいマネージャをあらかじめ代理サーバに登録し
ておくことによりトラップは分散的に管理され、しか
も、もれなく伝えられるため、ネットワーク全体にマネ
ージャを１つしか有しない場合であっても、管理者がネ
ットワーク全体の構成や発生しうるトラップを把握して
いなくても管理することが可能となる。

【００２２】また、ネットワーク全体をセグメントに分
けて各セグメントに資源管理サーバを設け、資源管理部
が発行するトラップをセグメント内で一時受取り、セグ
メント内の移動エージェント管理部でトラップをフィル
タリングした結果がマネージャに伝わるという分散的な
管理形態を採用しているので、不要なトラップがセグメ
ントを超えた先まで伝えられることが無く、ネットワー
クへの負荷を低減することが可能となった。

【００２３】また、マネージャはトラップ受取りの意志
を代理サーバに登録するので、監視用の専用機器を置く
位置の制約を無くすことが可能となった。更に、代理サ
ーバに登録できるマネージャの数に制限は無いので物理
的にセグメントが離れている場合など、必要に応じてマ
ネージャを複数設けることも可能であり、全てのマネー
ジャに確実にトラップを伝えることが可能であると同時
に、マネージャ間での調整の必要が無くなった。

【００２４】代理サーバに登録しているマネージャがト
ラップ発生時に存在しなくても代理サーバが一時的に受
取り、該当マネージャが現れた時に通知するので、管理
者が常時トラップを監視する必要が無くなった。図４は
本発明の第２の実施例である分散型ネットワーク障害管
理システムのブロック図である。第１〜３セグメント
３，５，７内の移動エージェント管理部、資源管理サー
バ、資源管理部、資源の構成は第１の実施例の場合と同
様である。

【００２５】第２の実施例が第１の実施例と異なる点
は、トラップ情報のフィルタリングを行うための資源デ
ータベース（ＤＢ）６０をネットワーク全体で１つ設け
ていることである。図４は、資源ＤＢ６０を第１セグメ
ント内に設けた場合を示している。まず、本実施例にお
ける各セグメント３，５，７の移動エージェント管理部
１９，２９，３９の基本的な動作を以下に説明する。

【００２６】資源ＤＢ６０への問い合わせは、資源ＤＢ
６０が存在するセグメント（図４の場合では第１セグメ
ント）の移動エージェント管理部１９が行う。資源ＤＢ
６０に直接問い合わせができる移動エージェント管理部
はネットワーク全体で１つであるが、資源ＤＢ６０及び
移動エージェント管理部の位置は任意である。また、資
源ＤＢとは別セグメントの代理サーバにトラップ受取情
報が登録されている。

【００２７】従って、例えば図４において、資源管理サ
ーバからトラップを受取った移動エージェント管理部が
第１セグメントの移動エージェント管理部１９の場合、
すなわち、資源ＤＢ６０と同一セグメント内の移動エー
ジェント管理部である場合は、直接その移動エージェン
ト管理部１９が資源ＤＢ６０に問い合わせる。資源ＤＢ
と別セグメントで同一セグメントに代理サーバが無い移
動エージェント管理部がトラップを受取った場合、例え
ば図４において第２セグメントの移動エージェント管理
部２９の場合、移動エージェントにトラップ情報を持た
せて他セグメントへ移動させる。

【００２８】資源ＤＢと別セグメントで同一セグメント
に代理サーバがいて、この代理サーバにトラップ受取り
が登録されている状況で移動エージェント管理部がトラ
ップを受取った場合、例えば図４において第３セグメン
トの移動エージェント管理部３９の場合、資源ＤＢ６０
と同一セグメントの移動エージェント管理部１９に移動
エージェントを発行してトラップのフィルタリングに関
する情報を調べ、再び移動エージェントを発行した移動
エージェント管理部３９に情報を持ち帰る。

【００２９】資源ＤＢ６０から得られたトラップのフィ
ルタリング情報により、代理サーバにトラップ到着の登
録を行う／行わない、を決定する。資源ＤＢ６０上のフ
ィルタリング情報の変更は管理者がマネージャにより行
う。マネージャは代理サーバにフィルタリング情報変更
を登録すると、代理サーバは同一セグメント上の移動エ
ージェント管理部に通知する。通知を受けた移動エージ
ェント管理部は同一セグメント内に資源ＤＢがある場合
は資源ＤＢの情報を更新する。同一セグメントに資源Ｄ
Ｂが無い場合は移動エージェントにフィルタリング情報
変更依頼を持たせて、資源ＤＢが存在するセグメントの
移動エージェント管理部へ移動させる。

【００３０】次に、図５のフローチャートを参照しつ
つ、本発明による第２の実施例のネットワーク障害管理
システムの動作を説明する。図４に示したデータベース
を用いたトラップ・フィルタリングの動作手順を含んで
いる。第１の実施例の動作の場合と同様、機器に実装さ
れているネットワーク資源の内部状態が異常になった
時、あるいは、あらかじめ設定されている閾値を超えた
時に資源管理サーバはトラップを発行する（ステップＳ
３１）。

【００３１】トラップは各セグメントに１つ以上用意さ
れている資源管理サーバが受取り、同一セグメント内の
移動エージェント管理部に送付する（ステップＳ３
２）。尚、資源管理サーバはトラップの受取り以外にも
一定間隔でセグメント内の資源管理部の位置を調べて資
源管理サーバ内で管理している。移動エージェント管理
部は、トラップを受取り（ステップＳ３３）、受取った
トラップをフィルタリングするための資源ＤＢがセグメ
ント内に存在するか否かを判別し（ステップＳ３４）、
セグメント内に資源ＤＢが存在する場合はその資源ＤＢ
へ問い合わせを行う。資源ＤＢへの問い合わせにより、
必要に応じてトラップのフィルタリングを行う（ステッ
プＳ３５）。

【００３２】ステップＳ３４において、セグメント内に
資源ＤＢが存在しない場合は移動エージェントを生成
し、移動エージェントにトラップ情報を持たせて、資源
ＤＢと同一セグメントの移動エージェント管理部へ移動
させる（ステップＳ３６）。ステップ３５におけるフィ
ルタリングの結果、代理サーバへ登録の必要があるか否
かを判別し（ステップＳ３７）、必要があると判断した
場合は代理サーバへ登録する（ステップＳ３８）。フィ
ルタリングの結果、代理サーバへ登録の必要が無いと判
断した場合（ステップＳ３７）は処理を終了する。

【００３３】次に、代理サーバはトラップを受取り（ス
テップＳ３９）、登録されている情報からトラップを取
り次ぐ該当マネージャが存在するか否かを判別し（ステ
ップＳ４０）、該当マネージャが存在する場合、そのマ
ネージャにトラップ情報を到着したことを通知する（ス
テップＳ４１）。他代理サーバにトラップ受取りの意志
を登録しているマネージャが存在する場合はそのマネー
ジャにも通知する。

【００３４】ステップＳ４０において、該当マネージャ
が一次的に存在しない場合（ステップＳ４２）は、トラ
ップを代理サーバが保存し、該当マネージャが現れた時
にトラップを通知する。他セグメントの代理サーバにト
ラップ受取りが登録されている場合（ステップＳ４３）
は、セグメント内に代理サーバが無かった場合と同様に
して移動エージェントを生成して、別の移動エージェン
ト管理部に移動させる（ステップＳ３６）。

【００３５】ステップＳ４３において、トラップ取り次
ぎ可能なマネージャが他セグメントの代理サーバを含む
代理サーバに登録されていない場合は、代理サーバにト
ラップ情報の通知を行った移動エージェント管理部に取
り次ぎ不可の情報を通知する（ステップＳ４４）。以上
のステップによりトラップの処理を終了する。

【００３６】以上詳細に説明したように第２の実施例に
よれば、ネットワーク全体で１つの資源ＤＢを設け、資
源ＤＢの更新／参照は移動エージェントが資源ＤＢのあ
る移動エージェント管理部まで移動して実行するので、
移動エージェント間で同期／合意をとるだけで資源ＤＢ
の更新／参照を安全に、また、統一的に実行することが
可能である。また、分散的に行われるトラップのフィル
タリングをセグメントの位置によらずに同一の処理を施
すことが可能となった。

【００３７】セグメント内に資源ＤＢが存在しない場合
は、そのセグメント内の移動エージェント管理部がトラ
ップ情報を持たせた移動エージェントを発行して他セグ
メントの資源ＤＢへ問い合わせるので、ネットワーク上
を移動する情報量を小さくすることが可能となり、ネッ
トワークへの負荷を低減することが可能となった。トラ
ップ情報は資源ＤＢに記録されている情報をもとに各セ
グメントで分散的にフィルタリングされ、マネージャに
無駄な通知を行わないので、管理者の管理作業に関わる
負荷の低減、通知に必要なネットワークへの負荷の低減
が可能となった。

【００３８】

【発明の効果】上記したことから明らかなように、本発
明によれば、ネットワークをセグメントに分割してトラ
ップを分散的に管理し、監視代理サーバに管理作業者を
登録することにより、管理作業者がどこにいても確実に
トラップを伝えることが可能なネットワーク障害管理シ
ステムを実現できる。また、トラップをフィルタリング
することにより、ネットワークへの負荷が小さく、必要
な障害情報を管理作業者に確実に伝えることが可能なネ
ットワーク障害管理システムを実現できる。

【図面の簡単な説明】

【図１】本発明の第１の実施例である分散型ネットワー
ク障害管理システムのブロック図である。

【図２】図１におけるネットワークの物理的な構成を示
す図である。

【図３】本発明による第１の実施例のネットワーク障害
管理システムの動作を説明するフローチャートである。

【図４】本発明の第２の実施例である分散型ネットワー
ク障害管理システムのブロック図である。

【図５】本発明による第２の実施例のネットワーク障害
管理システムの動作を説明するフローチャートである。

【主要部分の符号の説明】

３，５，７ セグメント １１，２１，３１ 情報機器 １３，２３，３３ ネットワーク資源 １５，２５，３５ 資源管理部 １７，２７，３７ 資源管理サーバ １９，２９，３９ 移動エージェント管理部 ４１ 代理サーバ ４５ マネージャ ５１，５２，５３ ルータ

Claims (2)

【特許請求の範囲】
1. 【請求項１】 各々が複数の情報装置及び前記複数の情
   報装置が発するトラップ（障害情報片）を管理する少な
   くとも１つの管理サーバを含む複数のネットワークセグ
   メントからなるネットワークと、前記ネットワークの障
   害監視を行う監視装置と、を有するネットワーク障害管
   理システムであって、 少なくとも１つの監視代理サーバと、 前記ネットワークセグメントの各々に少なくとも１つの
   移動エージェント管理装置と、を有し、 前記監視代理サーバは、前記監視装置及び前記移動エー
   ジェント管理装置の間において前記トラップの受渡しを
   行い、 前記移動エージェント管理装置は、前記管理サーバから
   の前記トラップの受取り、及び前記トラップに関する移
   動エージェントの発行及び受取りを行うことを特徴とす
   るネットワーク障害管理システム。
2. 【請求項２】 前記ネットワークセグメントのうち少な
   くとも１つにデータベース装置を有することを特徴とす
   る請求項１記載のネットワーク障害管理システム。