JP3570300B2

JP3570300B2 - 障害管理方式および方法

Info

Publication number: JP3570300B2
Application number: JP18886899A
Authority: JP
Inventors: 圭吾中村
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 1999-07-02
Filing date: 1999-07-02
Publication date: 2004-09-29
Anticipated expiration: 2019-07-02
Also published as: JP2001024635A

Description

【０００１】
【発明の属する技術分野】
本発明は、通信ネットワークのネットワーク管理に関し、特にネットワーク管理プロトコルであるＳＮＭＰ（ＳｉｍｐｌｅＮｅｔｗｏｒｋｍａｎａｇｅｍｅｎｔＰｒｏｔｏｃｏｌ）を用いた障害管理方式および方法に関する。
【０００２】
【従来の技術】
従来のこの種の障害管理方式は、例えば、特開平９−１０１９３２号公報および特開平１０−３３４０１１号公報に記載されているように、ＳＮＭＰプロトコルを用いたネットワーク管理システムにおいて、エージェントの障害状態をマネージャに通知する場合、ＴＲＡＰメッセージを用いて行っている。このとき、ＴＲＡＰメッセージ抜けが生じた場合に、再度ＴＲＡＰメッセージを送信するという手順を取っている。
【０００３】
【発明が解決しようとする課題】
しかしながら、従来の障害管理方式は、ＳＮＭＰはＵＤＰ（ＵｓｅｒＤａｔａｇｒａｍＰｒｏｔｏｃｏｌ）を利用したコネクションレスのプロトコルのため、エージェントから通知されたＴＲＡＰメッセージが必ずしもマネージャに届くとは限らない。そのため、ＴＲＡＰメッセージが抜けないように再度送信する手順をとっているので、ネットワークの負荷が高いときにＴＲＡＰメッセージを送信すると、ネットワーク上に過度の負荷をかけると共に、最悪の場合にはＴＲＡＰメッセージ抜けが発生するいう問題点がある。
【０００４】
また、マネージャはＴＲＡＰメッセージが届かない場合を考慮して全監視項目の状態をＧｅｔＲｅｑｕｅｓｔメッセージまたはＧｅｔＮｅｘｔＲｅｑｕｅｓｔメッセージを利用して定期的にエージェントに対して獲得に行かなければ正しい状態を獲得できないという問題点がある。
【０００５】
また、定期的に全監視項目の状態の獲得を行う場合、最初の獲得から次の獲得までのポーリング時間を長くすると障害を認識できない状態が常に長くなってしまい、逆にポーリング時間を短くすると障害状態はすぐ認識できるがネットワークの負荷があがってしまいＴＲＡＰメッセージ漏れの可能性が増大してしまうという問題点がある。
【０００６】
本発明の目的は、上記問題点を鑑み、ＳＮＭＰプロトコルを用いたネットワーク管理システムにおいて、エージェントの状態の監視する手段としてＴＲＡＰメッセージを用いないでＧｅｔＲｅｑｕｅｓｔだけを用い、ネットワークに負荷をかけないようにしながらできるだけリアルタイムに監視状態を獲得する方式を提供することにある。
【００１０】
【課題を解決するための手段】
上記の目的を達成するために、本発明の障害管理方式は、ネットワークを構成するエージェントの内部に障害の状態を保存し、マネージャではＳＮＭＰプロトコルを用いて複数の前記エージェントの状態変化の確認を行い状態の変化があった場合に前記エージェント側から状態情報を取得することでネットワ−ク管理を行う障害管理方式において、前記マネージャが前記エージェントの状態変化の有無の確認要求を行う第１の要求手段と、前記マネージャが前記第１の要求手段で状態変化がない場合に一定時間たってから前記第１の要求手段を繰り返す繰り返し手段と、前記エージェントが状態変化を検出する毎にその状態変化の内容を履歴情報として記憶する記憶手段と、前記第１の要求手段による確認要求が前記エージェントにあると前記エージェントが前記記憶手段で記憶されている前記履歴情報を検索することにより状態変化の有無を前記マネージャに通知する第１の通知手段と、前記マネージャが前記第１の通知手段により前記状態変化を検出した場合に前記状態変化の内容の読出要求と新たな状態変化の確認要求とを前記エージェントに同時に行う第２の要求手段と、前記第２の要求手段による要求があると前記エージェントが前記記憶手段で記憶された履歴情報を検索することにより前記状態変化の内容と前記新たな状態変化の有無とを前記マネージャに通知する第２の通知手段とを有することを特徴としている。
【００１１】
更に、上記の障害処理方式において、前記第１および第２の要求手段は、ＧｅｔＲｅｑｕｅｓｔメッセージを使用して要求を行うことを特徴としている。
【００１２】
更に、上記の障害処理方式において、前記第１および第２の通知手段は、ＧｅｔＲｅｓｐｏｎｓｅメッセージを使用して通知することを特徴としている。
【００１３】
更に、上記の障害処理方式において、前記記憶手段は、前記状態変化の起こったオブジェクトＩＤ（監視対象項目識別番号）とその状態変化の内容とを発生した順に記憶していくことを特徴としている。
【００１４】
更に、上記の障害処理方式において、前記第１の通知手段は、前記記憶手段に記憶された一番古いオブジェクトＩＤを前記マネージャに通知することを特徴としている。
【００１５】
更に、上記の障害処理方式において、前記第２の要求手段は、前記第１の通知手段で通知のあったオブジェクトＩＤの状態変化の内容の読出要求を行うことを特徴としている。
【００１７】
また、本発明の障害処理方法は、ネットワークを構成するエージェントの内部に障害の状態を保存し、マネージャではＳＮＭＰプロトコルを用いて複数の前記エージェントの状態変化の確認を行い状態の変化があった場合に前記エージェント側から状態情報を取得することで障害のネットワ−ク管理を行う障害管理方法であって、前記エージェントはエージェント自身の状態変化を検出する毎に状態変化のあったオブジェクトＩＤ（監視対象項目識別番号）とその状態変化の内容とを検出順に格納エリアに格納し、前記マネージャは一定時間毎に前記エージェントの状態変化の有無の確認要求を行い、前記エージェントは前記マネージャから前記状態変化の有無の確認要求があった場合に前記格納エリアに格納されていれば状態変化の有を示す一番古い履歴のオブジェクトＩＤを，前記格納エリアに格納されていなければ状態変化のないことをそれぞれマネージャに通知し、前記マネージャは前記状態変化が有の場合に前記通知のあったオブジェクトＩＤの状態変化の内容の読出要求と新たな状態変化の有無の確認要求とを前記エージェントに行い、前記エージェントは前記マネージャから前記オブジェクトＩＤの状態変化の内容の読出要求と新たな状態変化の有無の確認要求とがあると前記オブジェクトＩＤの状態変化の内容と新たな状態変化の有無とを前記マネージャに通知することを特徴としている。
【００１８】
更に、上記の障害処理方法において、前記エージェントは前記マネージャに前記オブジェクトＩＤの状態変化の内容を通知すると前記格納エリアから通知した状態情報を消すことを特徴としている。
【００１９】
【発明の実施の形態】
次に、本発明の実施の形態について図面を参照して説明する。
図１を参照すると、本発明の実施の形態は、ＬＡＮまたはＷＡＮに接続されたネットワーク３と、ネットワーク３に接続されＳＮＭＰのマネージャ（ネットワークを管理する）である監視端末１と、ネットワーク３に接続されＳＮＭＰのエージェントである複数の被監視端末２とから構成される。
【００２０】
監視端末１はＳＮＭＰのインターフェース部であるＳＮＭＰマネージャ制御部１１と、ＳＮＭＰを用いて獲得した状態を解析する監視解析部１３と、解析した結果を表示する監視表示部１２とから構成される。
【００２１】
被監視端末２は、ＳＮＭＰを用いてマネージャと通信するＳＮＭＰエージェント制御部２１と、自装置における不具合等の監視を行っている監視処理部２２と、監視処理部２２で検出した監視状態を記憶している状態格納エリア２３から構成される。なお、状態格納エリア２３は図１に記載されていない被監視端末２内にある記憶部に割り付けられており、この状態格納エリア２３には、監視状態が検出される度に順々に格納されていく（履歴が取られる）。
【００２２】
被監視端末２の監視処理部２２は、被監視端末２で必要な監視項目をすべて処理しており、障害が発生または復旧した場合はその都度状態格納エリア２３に状態変化のあった項目のオブジェクトＩＤ［ＭＩＢ（ＭａｎａｇｅｍｅｎｔＩｎｆｏｒｍａｔｉｏｎＢａｓｅ：管理情報ベース）のオブジェクトＩＤに対応］およびその状態を記憶する。
【００２３】
また、被監視端末２の監視処理部２２は、被監視端末２自身の状態を監視している。この状態の監視対象項目は、項目Ａ、項目Ｂ、項目Ｃ、項目Ｄの４つあるとする。被監視端末２の監視処理部２２が監視対象項目に対する状態の変化を検出すると、検出した順に、オブジェクトＩＤ（各項目に付けられたＩＤ名：監視対象項目識別番号）と、そのときの状態の値（コードで管理）を状態格納エリア内に格納していく。なお、このときの監視処理部２２の状態変化の監視方法として、ポーリングで各項目を見に行く監視方法、および発生時の割込による監視方法があるが、どちらの場合も適用できる。
【００２４】
監視端末１と複数の被監視端末２との間でＳＮＭＰを用いたプロトコルで情報のやりとりが行われる。なお、ネットワーク管理のオペレーションで使用されるＳＮＭＰメッセージには、ＧｅｔＲｅｑｕｅｓｔメッセージ、ＧｅｔＮｅｘｔＲｅｑｕｅｓｔメッセージ、ＳｅｔＲｅｑｕｅｓｔメッセージ、ＧｅｔＲｅｑｕｅｓｔメッセージ、ＧｅｔＲｅｓｐｏｎｓメッセージ、ＴＲＡＰメッセージの５つがある。なお、以降の説明では、語尾のメッセージを略して使用する。
【００２５】
図２は、本発明で使用されるＧｅｔＲｅｑｕｅｓｔまたはＧｅｔＲｅｓｐｏｎｓｅ発行時におけるｖａｒｉａｂｌｅ−ｂｉｎｄｉｎｇｓフィールド（ＳＮＭＰメッセージのＵＤＰ形式で定義されたフィールドの一部で、オブジェクトＩＤとその値の対の配列として定義したフィールド）の内容を示した図である。
図２を参照すると、ＩＤ（オブジェクトＩＤ）と値とが対となり複数設定（例では、Ｖ１、Ｖ２、・・・）できるようなっている。ここで、ＧｅｔＲｅｑｕｅｓｔでは、マネージャがｖａｒｉａｂｌｅ−ｂｉｎｄｉｎｇｓフィールドで指定したオブジェクトの値を、エージェントがＧｅｔＲｅｓｐｏｎｓｅのｖａｒｉａｂｌｅ−ｂｉｎｄｉｎｇｓフィールドのオブジェクトの値に設定して応答する。
すなわち、本発明では、図１の監視端末１のＳＮＭＰマネージャ制御部２１および被監視端末２のＳＮＭＰエージェント制御部２１は、受信したＳＮＭＰメッセージを解析する場合は、図２のフィールド内容を読み出してメッセージの意味を識別することになる。
【００２６】
次に、図１〜図４を参照して本実施の形態の全体の動作について説明する。
今、図２で使用されるオブジェクトＩＤを説明の都合上、例えば、状態変化の確認を示す場合は「ＳＴ」、項目Ａは「ＳＡ」、項目Ｂは「ＳＢ」、項目Ｃは「ＳＣ」、項目Ｄは「ＳＤ」とする。
【００２７】
図３を参照すると、先ず、マネージャである監視端末１（以降、略してマネージャと呼ぶこともある）のＳＮＭＰマネージャ制御部１１は、状態変化があるかどうかをエージェントに対して図２のＶ１のＩＤに「ＳＴ」を、値に「ＮＵＬＬ」をそれぞれ設定してＧｅｔＲｅｑｕｅｓｔを発行して確認する（図３のシーケンスＧ１）。
すると、エージェントである被監視端末２（以降、略してエージェントと呼ぶこともある）のＳＮＭＰエージェント制御部２１は、シーケンスＧ１でＧｅｔＲｅｑｕｅｓｔを受けたときに、ＧｅｔＲｅｑｕｅｓｔを解析（図２のフィールドを検索）する。このとき、ＳＮＭＰエージェント制御部２１は、状態格納エリア２３には状態変化（履歴情報）が１つも格納されていないため、状態変化なしと認識し、状態確認の状態値として図２のＶ１のＩＤに「ＳＴ」を、値に「ＮＵＬＬ」をそれぞれ設定してＧｅｔＲｅｓｐｏｎｓｅでマネージャに返す（シーケンスＲ１）。
【００２８】
次に監視端末１のＳＮＭＰマネージャ制御部１１は、状態変化確認のＧｅｔＲｅｓｐｏｎｓｅにてＮＵＬＬが設定されている場合、状態変化がないと認識して、一定時間を置いてから再度状態変化を確認するため、図２のＶ１のＩＤに「ＳＴ」を、値に「ＮＵＬＬ」をそれぞれ設定してＧｅｔＲｅｑｕｅｓｔをエージェントに対して発行する（シーケンスＧ２）。このとき、状態変化確認のＧｅｔＲｅｓｐｏｎｓｅを受けてから、状態変化確認のＧｅｔＲｅｑｕｅｓｔを発行するまでの時間は任意の時間に変更可能とする。なお、監視端末１のＳＮＭＰマネージャ１１は、ＧｅｔＲｅｑｕｅｓｔ発行後、ＧｅｔＲｅｓｐｏｎｓｅが返ってくるまで他に処理を行わないため、この時間を０にしても問題ない。しかし、絶え間なくＧｅｔＲｅｑｕｅｓｔまたはＧｅｔＲｅｓｐｏｎｓｅが実行されてしまい、他のネットワークアプリケーションに影響を与える可能性があるため、時間の設定はネットワークの速度に応じて変更することが望ましい。
【００２９】
一方、マネージャがシーケンスＲ１のＧｅｔＲｅｓｐｏｎｓｅを受けてからシーケンスＧ２のＧｅｔＲｅｑｕｅｓｔを発行するまでに、エージェントにて項目Ａが障害になり、続いて項目Ｂが障害になったとする。すると、被監視端末２の監視処理部２２は、項目Ａおよび続いて発生した項目Ｂの障害を検出し、障害情報を状態格納エリア２３に格納（１つ目の履歴として「ＳＡ」とその障害値、２つ目の履歴として「ＳＢ」とその障害値を格納）する。
【００３０】
この後、被監視端末２のＳＮＭＰエージェント制御部２１は、マネージャから状態変化確認のＧｅｔＲｅｑｕｅｓｔ（シーケンスＧ２）を受信した場合にこのメッセージを解析し、状態格納エリア２３に状態変化が格納されているかを状態格納エリア２３を読み出すことにより確認する。この場合、ＳＮＭＰエージェント制御部２１は、古い情報から検索していく。従って、被監視端末２のＳＮＭＰエージェント制御部２１は、最初に発生した項目Ａの状態変化があったことをマネージャに通知するために状態変化確認のレスポンスとして図２のＶ１のＩＤに「ＳＴ」を、値に状態の変化のあった項目を示す「ＳＡ」をそれぞれ設定してＧｅｔＲｅｓｐｏｎｓｅを返す。（シーケンスＲ２）。
【００３１】
次に、監視端末１のＳＮＭＰマネージャ制御部１１は、シーケンスＲ２で受け取ったＧｅｔＲｅｓｐｏｎｓｅを解析することにより、項目Ａの状態変化があったことを認識できるので、項目Ａの状態獲得および状態変化が他にもないか確認するために状態変化確認のＧｅｔＲｅｑｕｅｓｔを発行する。すなわち、ＧｅｔＲｅｑｕｅｓｔには、図２のＶ１のＩＤに「ＳＡ」、値に「ＮＵＬＬ」を、Ｖ２のＩＤに「ＳＴ」、値に「ＮＵＬＬ」をそれぞれ設定されて発行される（シーケンスＧ３）。
すると、被監視端末２のＳＮＭＰエージェント制御部２１は、シーケンスＧ３で受け取ったＧｅｔＲｅｑｕｅｓｔを解析することにより、図２のＶ１およびＶ２の内容を検索することにより監視端末１から要求された処理を実行することになる。ＳＮＭＰエージェント制御部２１は、先ず最初に状態格納エリア２３から最初に格納されている項目Ａの状態を獲得してレスポンスの値に設定して、状態格納エリアの項目ＡのＭＩＢのオブジェクトＩＤおよび状態をクリアする（１履歴分消去する）。更に、状態格納エリア２３に他にも状態変化があるか確認する。この時点では、項目Ｂの障害の状態が格納されているので、状態変化確認のレスポンスには項目ＢのオブジェクトＩＤを設定してレスポンスを返す。すなわち、ＧｅｔＲｅｓｐｏｎｓｅには、図２のＶ１のＩＤに「ＳＡ」、値にその障害値を、Ｖ２のＩＤに「ＳＴ」、値に状態変化ありを示す値をそれぞれ設定されて発行される（シーケンスＲ３）。
【００３２】
次に監視端末１のＳＮＭＰマネージャ制御部１１は、シーケンスＲ３で受け取ったＧｅｔＲｅｓｐｏｎｓｅを解析する。このとき、ＳＮＭＰマネージャ制御部１１は、図２のＶ１の内容（ＳＡとその障害値）は、監視解析部１３に渡す。すると、監視解析部１３は、受け取った内容（項目Ａの障害値）を解析して監視表示部１２に表示する。
一方、ＳＮＭＰマネージャ制御部１１は、シーケンスＲ３で受信したＧｅｔＲｅｓｐｏｎｓｅの解析内容（図２のＶ２の内容）から項目Ｂの状態変化があったことを認識できるので、項目Ｂの状態獲得および状態変化が他にもないか確認するために状態変化確認のＧｅｔＲｅｑｕｅｓｔを発行する。すなわち、ＧｅｔＲｅｑｕｅｓｔには、図２のＶ１のＩＤに「ＳＢ」、値に「ＮＵＬＬ」を、Ｖ２のＩＤに「ＳＴ」、値に「ＮＵＬＬ」をそれぞれ設定されて発行される（シーケンスＧ４）。
すると、被監視端末２のＳＮＭＰエージェント制御部２１は、シーケンスＧ４で受け取ったＧｅｔＲｅｑｕｅｓｔを解析（図２のＶ１およびＶ２の内容を検索）することにより監視端末１から要求された処理を実行することになる。ＳＮＭＰエージェント制御部２１は、先ず最初に状態格納エリア２３の最初に格納されている項目Ｂの状態を獲得してレスポンスの値に設定して、状態格納エリアの項目ＢのＭＩＢのオブジェクトＩＤおよび状態をクリアする（１履歴分消去する）。この時点で状態格納エリア２３には何も格納されていないので、状態変化確認のレスポンスにはＮＵＬＬを設定してレスポンスを返す。すなわち、ＧｅｔＲｅｓｐｏｎｓｅには、図２のＶ１のＩＤに「ＳＢ」、値にその障害値を、Ｖ２のＩＤに「ＳＴ」、値に「ＮＵＬＬ」をそれぞれ設定されて発行される（シーケンスＲ４）。
【００３３】
次に、監視端末１のＳＮＭＰマネージャ制御部１１は、シーケンスＲ４で受け取ったＧｅｔＲｅｓｐｏｎｓｅを解析する。このとき、ＳＮＭＰマネージャ制御部１１は、図２のＶ１の内容（ＳＢとその障害値）は、監視解析部１３に渡す。すると、監視解析部１３は、受け取った内容（項目Ｂの障害値）を解析して監視表示部１２に表示する。
一方、ＳＮＭＰマネージャ制御部１１は、シーケンスＲ３で受信したＧｅｔＲｅｓｐｏｎｓｅの解析内容（図２のＶ２の内容）から、状態変化確認のレスポンスにはＮＵＬＬが入っているため、一定時間待ってから再度状態変化の確認のＧｅｔＲｅｑｕｅｓｔを発行する。すなわち、ＧｅｔＲｅｑｕｅｓｔには、図２のＶ１のＩＤに「ＳＴ」を、値に「ＮＵＬＬ」をそれぞれ設定されて発行される（シーケンスＧ５）。
【００３４】
なお、上記説明において、状態変化の有無の確認を行う手段として、上記と違う方法がある。すなわち、図１の図示していない記憶部に状態変化の有無を示す状態語（初期値は「０」）を設け、ＳＮＭＰエージェント制御部２１が、状態変化を検出し、状態格納エリア２３にその状態を格納する度に状態語を「＋１」し、１履歴消去する度に「−１」するようにしておく。ＳＮＭＰエージェント制御部２１は、ＧｅｔＲｅｑｕｅｓｔ（図２のフィールドに「ＳＴ」が設定されている場合）を受信した場合に、この状態語を読みにいくことで、即座に判別（ＳＮＭＰエージェント制御部２１が、状態語が「０」の場合は状態変化なし、状態語が「０」でなければ状態変化ありと判定する）できる。
【００３５】
また、上記説明において、監視端末１および被監視端末２はそれぞれ１対１の構成で説明したが、被監視端末２が複数存在していても構わない。すなわち、監視端末１のＳＮＭＰマネージャ制御部１１が複数の被監視装置２を監視する場合の一連のシーケンスをフローチャートにまとめたのが図４になる。
この場合、図１の監視端末１には、あらかじめ監視を行う複数の被監視端末２のネットワークアドレスを図１に記載されていないメモリの監視テーブルに設定しておく（ＳＮＭＰプロトコルでは、それぞれの端末に設定されたネットワークアドレスを指定することによりＳＮＭＰメッセージの送受信ができる）。すなわち、被監視端末２が複数ある場合、監視端末１のＳＮＭＰマネージャ制御部１１は、ＧｅｔＲｅｑｕｅｓｔにて状態変化の確認を行う場合（ステップＦ１）、ステップＦ１の処理を行うたびに順次確認する被監視端末２の対象を切り替えていくことで対応できる。例えば、被監視端末２が２台（Ａ、Ｂ）があったする。すると、監視端末１の監視テーブルには、被監視端末２Ａおよび被監視端末２Ｂのネットワークアドレスを監視順に設定されている。
【００３６】
図４を参照すると、監視端末１のＳＮＭＰマネージャ制御部１１は、システムが立ち上がると、監視テーブルに従って、送出先を決め、先ず被監視端末２Ａの状態変化の確認をＧｅｔＲｅｑｕｅｓｔで行う（ステップＦ１）。次に監視端末１のＳＮＭＰマネージャ制御部１１は、ＧｅｔＲｅｓｐｏｎｓｅの内容から状態の変化がないと判断した場合は、一定時間待って次の被監視端末である被監視端末２ＢにＧｅｔＲｅｑｕｅｓｔ（状態変化の確認）を発行する（ステップＦ２，Ｆ５，Ｆ１）。監視端末１のＳＮＭＰマネージャ制御部１１は、被監視端末２Ａアクセス時、ステップＦ２で状態変化を検出した場合は、ＧｅｔＲｅｑｕｅｓｔで被監視端末２Ａの状態の内容の獲得と状態の変化の確認を行う（ステップＦ３）。次に監視端末１のＳＮＭＰマネージャ制御部１１は、ＧｅｔＲｅｓｐｏｎｓｅによる被監視装置２Ａの状態の内容の獲得を行い、このとき新たな被監視端末２Ａの状態の変化がない場合は、一定時間待った後、監視テーブルから次の端末である被監視端末２ＢにＧｅｔＲｅｑｕｅｓｔ（状態の変化の確認）を発行する（ステップＦ４，Ｆ５，Ｆ１）。ステップＦ４で被監視装置２Ａの状態変化がある場合は、監視端末１のＳＮＭＰマネージャ制御部１１は、状態変化がなくなるまで、ステップＦ３とステップＦ４を繰り返す。このように被監視端末２Ｂでも状態の変化があった場合は、監視端末１のＳＮＭＰマネージャ制御部１１は、状態変化なしを検出するまで、被監視端末２ＢにもステップＦ１〜Ｆ４の動作を繰り返す。すなわち、被監視端末２が多数あっても、監視端末１のＳＮＭＰマネージャ制御部１１は、図４のフローチャートによる同じ動作を実行することができる。
【００３７】
なお、上記のステップＦ５の説明において、一定時間を待つという処理は、ＳＮＭＰマネージャ制御部１１が、図１に図示していないタイマにあらかじめ決められた値を設定して、タイマを起動し、タイムアウト割込によりステップＦ１の処理を実行するようにすればよい。
【００３８】
このような処理を行うことによって、ネットワークに一定以上の負荷をかけないようにして複数の被監視端末の監視を行うことが可能となる。この場合、タイマ値を図１に図示していないコンソールから変更できるようにしておけば、ネットワ−クの規模により変更できるため、負荷をかけないという点で望ましい。
【００３９】
以上説明したように、ＴＲＡＰを用いていないので、ＴＲＡＰ漏れを考慮する必要がなくなる。ＴＲＡＰによる状態変化の通知方式と比べると、エージェントから連続して状態変化が通知されネットワーク上の負荷が一時的に高くなることもなく、本発明によるマネージャは、ＧｅｔＲｅｓｐｏｎｓｅが返ってくるまで次のＧｅｔＲｅｑｕｅｓｔを一定時間の間発行しないようにしているため、マネージャ自身の処理できる速度以上にネットワークの負荷があがることはない。
【００４０】
また、常に全監視項目の状態の獲得を行うのではなく、状態変化のあったオブジェクトだけを獲得するので短い時間ですべての状態変化のあった項目の状態を獲得することができる。
【００４１】
従って、ネットワークに負荷をかけないようにしながらできるだけリアルタイムに監視状態を獲得することが可能となる。
【００４２】
【発明の効果】
本発明は、ＳＮＭＰを利用したネットワーク管理システムにおいて、ＳＮＭＰはＵＤＰを利用したコネクションレスのプロトコルであるため、ＴＲＡＰ漏れを考慮する必要があったが、本方式ではＴＲＡＰを全く使用しないのでＴＲＡＰ漏れを考慮する必要がないという効果がある。
【００４３】
更に、本発明は、ＧｅｔＲｅｑｕｅｓｔにより、状態変化の確認をしてから状態変化のあった項目だけ状態を獲得するようにしているため、常に全監視項目の状態獲得を行う必要がなく、監視項目分の状態をすべて獲得するまでの時間を短縮できるという効果がある、
更に、本発明は、ＴＲＡＰを用いていないため、マネージャからＧｅｔＲｅｑｕｅｓｔを発行してからエージェントからＧｅｔＲｅｓｐｏｎｓｅを受けるまで他のＳＮＭＰの処理に対する割り込みが一切発生しないため、ネットワーク上の負荷を削減できるという効果がある。
【００４４】
更に、本発明は、何も状態変化がない場合、次の状態変化の確認まで任意の時間を設定できるようにすることで最適なネットワークパフォーマンスを提供することができるという効果がある。
【図面の簡単な説明】
【図１】本発明の実施の形態を示すブロック図である。
【図２】ＳＮＭＰメッセージのＵＤＰ形式で定義されたフィールドの一部である。
【図３】図１の監視端末と被監視端末との間の動作を示すシーケンス図である。
【図４】図１の監視端末が複数の被監視端末の監視の動作を行うフロ−チャートである。
【符号の説明】
１監視端末
２被監視端末
３ネットワーク
１１ＳＮＭＰマネージャ制御部
１２監視表示部
１３監視解析部
２１ＳＮＭＰエージェント制御部
２２監視処理部
２３状態格納エリア

Claims

ネットワークを構成するエージェントの内部に障害の状態を保存し、マネージャではＳＮＭＰプロトコルを用いて複数の前記エージェントの状態変化の確認を行い状態の変化があった場合に前記エージェント側から状態情報を取得することでネットワ−ク管理を行う障害管理方式において、
前記マネージャが前記エージェントの状態変化の有無の確認要求を行う第１の要求手段と、
前記マネージャが前記第１の要求手段で状態変化がない場合に一定時間たってから前記第１の要求手段を繰り返す繰り返し手段と、
前記エージェントが状態変化を検出する毎にその状態変化の内容を履歴情報として記憶する記憶手段と、
前記第１の要求手段による確認要求が前記エージェントにあると前記エージェントが前記記憶手段で記憶されている前記履歴情報を検索することにより状態変化の有無を前記マネージャに通知する第１の通知手段と、
前記マネージャが前記第１の通知手段により前記状態変化を検出した場合に前記状態変化の内容の読出要求と新たな状態変化の確認要求とを前記エージェントに同時に行う第２の要求手段と、
前記第２の要求手段による要求があると前記エージェントが前記記憶手段で記憶された履歴情報を検索することにより前記状態変化の内容と前記新たな状態変化の有無とを前記マネージャに通知する第２の通知手段とを有することを特徴とする障害管理方式。
前記第１および第２の要求手段は、ＧｅｔＲｅｑｕｅｓｔメッセージを使用して要求を行うことを特徴とする請求項１記載の障害管理方式。
前記第１および第２の通知手段は、ＧｅｔＲｅｓｐｏｎｓｅメッセージを使用して通知することを特徴とする請求項１記載の障害管理方式。
前記記憶手段は、前記状態変化の起こったオブジェクトＩＤ（監視対象項目識別番号）とその状態変化の内容とを発生した順に記憶していくことを特徴とする請求項１記載の障害管理方式。
前記第１の通知手段は、前記記憶手段に記憶された一番古いオブジェクトＩＤを前記マネージャに通知することを特徴とする請求項１記載の障害管理方式。
前記第２の要求手段は、前記第１の通知手段で通知のあったオブジェクトＩＤの状態変化の内容の読出要求を行うことを特徴とする請求項１記載の障害管理方式。
ネットワークを構成するエージェントの内部に障害の状態を保存し、マネージャではＳＮＭＰプロトコルを用いて複数の前記エージェントの状態変化の確認を行い状態の変化があった場合に前記エージェント側から状態情報を取得することで障害のネットワ−ク管理を行う障害管理方法であって、
前記エージェントはエージェント自身の状態変化を検出する毎に状態変化のあったオブジェクトＩＤ（監視対象項目識別番号）とその状態変化の内容とを検出順に格納エリアに格納し、
前記マネージャは一定時間毎に前記エージェントの状態変化の有無の確認要求を行い、
前記エージェントは前記マネージャから前記状態変化の有無の確認要求があった場合に前記格納エリアに格納されていれば状態変化の有を示す一番古い履歴のオブジェクトＩＤを，前記格納エリアに格納されていなければ状態変化のないことをそれぞれマネージャに通知し、
前記マネージャは前記状態変化が有の場合に前記通知のあったオブジェクトＩＤの状態変化の内容の読出要求と新たな状態変化の有無の確認要求とを前記エージェントに行い、
前記エージェントは前記マネージャから前記オブジェクトＩＤの状態変化の内容の読出要求と新たな状態変化の有無の確認要求とがあると前記オブジェクトＩＤの状態変化の内容と新たな状態変化の有無とを前記マネージャに通知することを特徴とする障害管理方法。
前記エージェントは前記マネージャに前記オブジェクトＩＤの状態変化の内容を通知すると前記格納エリアから通知した状態情報を消すことを特徴とする請求項７記載の障害管理方法。