JP2010191663A - ネットワーク管理システム - Google Patents

Abstract

【課題】サーバと協働してネットワーク機器を管理するクライアント端末が増えた場合、簡単な構成ではネットワーク機器情報のリアルタイム性が損なわれる。
【解決手段】ネットワークを管理するサーバ１はネットワーク機器情報を保持している。ネットワーク機器でエラー等が発生し機器の状態が変わった場合には、サーバに状態変化通知がネットワーク機器から送信される。サーバは状態変化通知を受けると、ネットワーク機器情報を更新し、また、サーバと協調してネットワークを管理するクライアントに対しネットワーク機器の状態変化通知を送信する。この場合、ネットワーク機器からの通知の発生頻度と通知内容の優先度によってサーバからクライアントへの通知処理を通知の態様を変える。
【選択図】図２

Description

本発明は、ネットワーク管理システムに関し、特に、ネットワーク管理サーバ（以下、「サーバ」と記す）と複数台のクライアントでネットワーク機器を管理するネットワーク管理システムに関する。

従来、ネットワーク管理システムでは、管理すべきネットワーク機器のエラー情報等の状態変化通知はサーバへ通知され、サーバにおいて一元管理していた。しかし、管理台数などが多くなってくるに従い、サーバやネットワークの負荷が重くなる問題が出てきた。

ネットワーク機器情報が多くなりネットワークの負荷が重くなった場合に、ネットワーク機器内部にネットワーク機器情報を保存する方法（特許文献1）や、サーバとネットワーク機器間で保持する方法（特許文献２）が知られている。しかし、これらの技術は、ネットワーク機器とサーバ間の処理に対応するものであり、サーバと協働してネットワーク機器を管理するクライアント端末が増えた場合に対応するものではない。更に、ネットワーク機器情報は、ネットワーク機器やサーバとネットワーク機器間で一時的に保持されるため、サーバへ直ちに届かないのでリアルタイム性が損なわれ、サーバが正しく情報を判断できない場合が想定される。

また、ネットワーク上のサービスを利用するクライアント端末が増えた場合に対応する技術であるが、サーバの提供サービス性能や通信性能の監視を行い、サーバ等における障害や性能低下の程度情報を取得し、より応答性の高い代替サービスへ切り替える方法（特許文献３）も公知である。しかし、この技術も、サーバと協働してネットワーク機器を管理するクライアント端末が増えた場合に対応するものではない。更に、代替サービス提供サーバが必要であるし、これを使用した場合には、サーバ１台で集中管理できないための時間ロスが予想され、必要な情報がクライアントへ適時に届かないという問題もある。

特開2008-198041号公報 特開2001-223694号公報 特開2004-171495号公報

解決しようとする問題点は、サーバと協働してネットワーク機器を管理するクライアント端末が増えた場合、簡単な構成ではネットワーク機器情報のリアルタイム性が損なわれるという点である。

本発明は、サーバと協働してネットワーク機器を管理するクライアント端末が増えた場合、簡単な構成でネットワーク機器情報のリアルタイム性を確保するため、ネットワーク機器からの状態変化通知の発生頻度と優先度を元にサーバとクライアント間の情報の送信経路を切り替えることを最も主要な特徴とする。

本発明のネットワーク管理システムは、ネットワーク機器からの状態変化通知が増えてサーバの処理負荷が高いと判断した場合に、クライアントへの転送処理を一部クライアントに処理を移すため、サーバ側の処理を軽減できるという利点がある。但し、サーバの処理負荷が低くても、優先度の高い状態変化通知であれば、サーバから直接に全クライアントへ状態変化通知を送信する扱いとすることにより、サーバとクライアント間で同期をとることができる。

本発明が適用されるネットワーク管理システムの一例を示すブロック図である。 本発明の一実施例としてのサーバを示すブロック図である。 状態変化通知の情報の第１の流れを表す図である。 状態変化通知の情報の第２の流れを表す図である。 状態変化通知の送信方法判定処理を示すフローチャートである。 状態変化通知の転送機能を有するクライアント内のブロック図である。 状態変化通知と優先度の例を表示する図である。 状態変化通知の発生頻度と優先度の第１の組み合わせによる送信方法を表示する図である。 状態変化通知の発生頻度と優先度の第２の組み合わせによる送信方法を表示する図である。

ネットワークを管理するサーバはネットワーク機器情報を保持している。ネットワーク機器でエラー等が発生し機器の状態が変わった場合には、サーバに状態変化通知がネットワーク機器から送信される。サーバは状態変化通知を受けると、ネットワーク機器情報を更新し、また、サーバと協働してネットワークを管理するクライアントに対し必要に応じてネットワーク機器の状態変化通知を送信する。クライアントが複数台ある場合は、管理処理を同様に行うために全クライアントに通知が届く必要がある。

本発明は、ネットワーク機器からの通知の発生頻度と通知内容の優先度によってサーバからクライアントへの通知処理を通知の態様を変えることにより、ネットワーク機器とサーバとクライアント間でネットワーク機器情報の同期性を損なわずにサーバの負荷を軽減するという目的を簡単な構成で実現した。

図１は、本発明が適用されるネットワーク管理システムの一例を示す。このネットワーク管理システムは、SNMP(Simple Network Management Protcol)などのプロトコルを使用し、サーバ101にマネージャ111、ネットワーク機器105,106,107にエージェント115,116,117を有し、マネージャ111とエージェント115,116,117との間で相互に通信しながらネットワーク104の管理を行っている。

ネットワーク機器105,106,107には、エージェント115,116,117が取得したネットワーク機器状態を保持している管理情報ベース（MIB）125,126,127を有し、サーバ101も管理情報ベース125,126,127と同内容のネットワーク機器情報121を一時保存している。このようにして、管理情報ベース125,126,127を元に、サーバ101とネットワーク機器105,106,107はネットワーク機器状態を共有している。

ネットワーク機器の管理ため、サーバ101側のネットワーク機器情報121と、ネットワーク機器105,106,107側の管理情報ベース125,126,127の内容は同じ状態を維持する必要がある。そのため、マネージャ111からエージェント115,116,117に対し情報取得や設定を要求するRequestを出し、その応答としてResponseがエージェント115,116,117からマネージャ111へ送出されて情報伝達がされている。また、エージェント115,116,117がエラーを検出した場合などには、自発的に状態変化通知としてサーバ101に対してTrapが送信される。Request-Responseの制御はサーバ101主体で動作しており、Trapはネットワーク機器105,106,107主体で送信されている。

ところで、管理対象となるネットワーク機器が多くなり、また、ネットワーク管理を複数の拠点で行うなどの必要性が出てきた場合は、各拠点に管理用のクライアント102,103を設置してサーバ101と接続したネットワーク管理システムを構築する。この場合、主体的にはサーバ101がネットワークを管理し、その一部管理機能であるマネージャ112,113とネットワーク機器情報121の内の一部の情報であるネットワーク機器情報122,123をクライアント102,103に持たせる。サーバ101がネットワーク機器情報121を更新する場合には、必要に応じてクライアント102,103に更新情報を送信し、ネットワーク機器情報122,123も更新される。

ネットワーク機器が増加するのに伴い、管理情報量も増えてサーバとクライアント間の情報量が増大し、また、管理用クライアントの接続台数が増えてきて、その制御もサーバ101の負荷になってくる。特に、Trapによる状態変化通知の制御は、管理するネットワーク機器が増えてデータ量が増大してくると、１つのTrapに対しサーバ101からクライアントの接続台数分の送信が必要となりサーバ101の処理負荷となってくる。

そこで、ネットワーク機器とサーバとクライアントの間のネットワーク機器情報の同期性をなるべく損なわずにサーバの負荷を軽減する方法として本発明を提案したものである。特に、サーバと協働してネットワークを管理するクライアント台数が増えてきた場合のサーバ負荷を簡単な構成により軽減することを眼目とする。

図２は、本発明の一実施例としてのサーバ１を示している。このブロック図は、図１におけるマネージャ111の詳細を示している。また、図面の煩雑化を回避するために、ネットワーク機器およびクライアントは１つだけ示している。ネットワーク機器３から状態変化通知が出されると、サーバ１内の機器情報受信部11で受信し、ネットワーク機器情報121（図２では図示省略）の更新などを行う。

サーバ負荷計測部12は、機器情報受信部11から状態変化通知が発生したことを通知され、単位時間当たりの状態変化通知の発生頻度を計測し、これをサーバ１の負荷状態とする。サーバ負荷計測部12は、タイマ機能を内蔵し単位時間当たり（たとえば件／秒）の状態変化通知をカウントし続ける。計測されたカウントは、閾値を超えるような場合は高負荷状態と判断される。例えば、１０件／秒を閾値とすると、１２件／秒の状態変化通知が来た場合には高負荷状態と判断され、７件／秒の場合は低負荷状態と判断する。この閾値はサーバ１のCPU性能などの処理能力などによって決定する。

情報優先度判定部13は、機器情報受信部11から状態変化通知の種別を受け、その内容に従って、ネットワーク機器３で発生している状態の重要度を判定し、処理優先度を決定する。クライアント送信方法判定部14は、サーバ１の負荷状態と処理優先度を元にクライアント２に対する転送有無を決定する。機器情報送信部15は、送信指示情報を状態変化通知に付加した機器情報を作成し、クライアント送信方法判定部14に従って送信する。送信は、転送無なら全クライアントに対して（図３）、転送有ならクライアント１台のみに対して（図４）行なう。

図３は状態変化通知の流れを表しており、サーバ１の負荷が軽いときや、優先度の高い状態変化通知が発生したときのものになる。ネットワーク機器3-1，3-2で状態変化通知が発生した場合、通知を受けたサーバ１から全てのクライアント2-1,2-2,2-3へ直接に状態変化通知を送信している。

これに対し、図４はサーバ１の負荷が重く、且つ優先度の低い状態変化通知が発生したときの状態変化通知の流れを表している。ネットワーク機器3-1，3-2で状態変化通知が発生した場合、通知を受けたサーバ１はクライアント3-1に対して、状態変化通知と他のクライアントへ状態変化通知を転送する指示とを行う。クライアント3-1はサーバ１の指示により状態変化通知を他のクライアント2-2,2-3に転送する。

図５はクライアント送信方法判定部14における判定の手順を示すフローチャートである。サーバ１の負荷状態を判定し（図５のステップＳ１）、負荷が軽いようであれば全クライアント2-1,2-2,2-3に対しサーバ１から情報を送信（図３）すると決定する（ステップＳ２）。負荷が重い場合は情報の優先度を判定する（ステップＳ３）。その結果、優先度が高い場合は全クライアント2-1,2-2,2-3に対しサーバ１から情報を送信（図３）すると決定する（ステップＳ２）。一方、優先度が低い場合はクライアント2-1に対しのみ情報を通知し、他のクライアント2-2,2-3へは転送（図４）と決定する（ステップＳ４）。この決定を元に、機器情報送信部15は、クライアント送信方法判定部14で決定したクライアントへの転送情報を状態変化通知に付加した機器情報を作成し、送信方法判定部14での決定に従って、全クライアント2-1,2-2,2-3またはクライアント2-1のみに機器情報を送信する。

図６は、クライアント2-1の詳細を示すブロック図である。図６において、クライアント2-1は、他のクライアント2-2,2-3の通知先アドレス25を保持しておく。通知先アドレス25は、サーバ１から登録することで、システム構成の変更時にも対応できる。ネットワーク通信制御部21は、サーバ１から送信されてくる状態変化通知をネットワーク機器情報管理部22へ送る。ネットワーク情報管理部22は、状態変化通知に従って、ネットワーク機器の状態を記憶しているネットワーク機器情報24（図１の122,123と同じ）を更新する。

また、ネットワーク情報管理部22は、状態変化通知に付加されている転送情報に従い、他クライアント2-2,2-3へ通知する必要がある場合は、クライアント制御部23へ状態変化通知を受け渡す。クライアント送信制御部23は他クライアントの通知先アドレス25を元に状態変化通知の転送処理を行って、その結果をネットワーク通信制御部21に伝える。ネットワーク通信制御部21は通知先アドレス25として登録されている全てのクライアント2-2,2-3に対して状態変化通知の転送を行う。

図７は、状態変化通知の具体例を優先度別に表示する。例えば、ネットワーク接続状況で分類すると、図７で分類されるようにネットワークの接続不良が起こっている状況を優先度が高いと判断し、ネットワークが接続を続けている状況は優先度が低いと判断することができる。このような状態変化通知の種類で優先度を決定するようにテーブル化しておけば、情報優先度判定部13は、このテーブルによって優先度を判定することができる。図８は、頻度と優先度を２段階に分けた送信方法の判定をまとめて表示する。図８に表示するＡとＢの判定がクライアント送信方法判定部14において行なわれる。

以上詳述したように、サーバ１が受信する機器情報を元にクライアント２へ送信する機器情報を適切に制御することで、サーバ１の処理負荷を軽減することが可能になる。

実施例１では発生頻度及び優先度を２段階に分けているが、発生頻度や優先度に関しさらに多段階に分けて送信方法の判定を行うことも考えられる。多段階に分けて判断することで、より適切にサーバ負荷を軽減することができる。頻度と優先度を３段階に分けて送信方法を判定する場合の例が図９になる。

また、実施例１と実施例２では、クライアント１台に対し、他のクライアントへの状態変化通知の転送を指示しているがクライアントをグループ分けし、クライアント複数台に対し転送指示することも考えられる。多段階に分けた発生頻度と優先度を元にクライアントのグループ分けをフレキシブルに制御することもできる。

１ サーバ
２ クライアント
３ ネットワーク機器
11 機器情報受信部
12 サーバ負荷計測部
13 情報優先度判別部
14 クライアント送信方法判定部
15 機器情報送信部
21 ネットワーク通信制御部
22 ネットワーク機器情報管理部
23 クライアント送信制御部
24 ネットワーク機器情報
25 通知先アドレス
2-1〜2-3 クライアント
3-1〜3-2 ネットワーク機器
101 サーバ
102,103 クライアント
104 ネットワーク
105〜107 ネットワーク機器
111〜113 マネージャ
115〜117 エージェント
121〜123 ネットワーク機器情報
125〜127 管理情報ベース

Claims (5)

1. サーバの制御の下に前記サーバと協働してネットワーク機器を管理する複数のクライアントを設け、
   前記サーバは、前記ネットワーク機器から各機器の状態を示すネットワーク機器状態情報を受信した場合に、その発生頻度と優先度を元に、前記ネットワーク機器状態情報を全クライアントに直接送信するか、または一部クライアントにのみ送信し他のクライアントへの転送を指示するかを判断することを特徴とするネットワーク管理システム。
2. サーバの制御の下に前記サーバと複数のクライアントが協働してネットワーク機器を管理するネットワーク管理システムにおいて、
   前記サーバは、ネットワーク機器情報を保持しており、
   前記ネットワーク機器から状態変化通知を受信し前記ネットワーク機器情報の更新を行う機器情報受信部と、
   前記機器情報受信部から状態変化通知が発生したことを通知されると、単位時間当たりの状態変化通知の発生頻度を計測るサーバ負荷計測部と、
   機器情報受信部から状態変化通知の種別を受け、その内容に従って当該ネットワーク機器で発生している状態の重要度を判定し、処理優先度を決定する情報優先度判定部と、
   前記発生頻度と前記処理優先度を元に一部のクライアントに対する転送有無を決定するクライアント送信方法判定部と、
   前記転送無なら全クライアントへ前記状態変化通知を送信し、また前記転送有なら該転送情報を前記状態変化通知に付加した機器情報を作成し前記一部のクライアントへ送信する機器情報送信部を有することを特徴とするネットワーク管理システム。
3. 前記発生頻度と優先度をそれぞれ高低の２段階に分け、前記クライアント送信方法判定部は、前記発生頻度が低の場合または前記処理優先度が高の場合に転送無と判断し、前記発生頻度が高で且つ前記処理優先度が低の場合に転送有と判断することを特徴とする請求項２に記載のネットワーク管理システム。
4. 前記発生頻度と優先度をそれぞれ高中低の３段階に分け、前記クライアント送信方法判定部は、前記発生頻度が低の場合または前記処理優先度が高の場合または前記発生頻度が中で且つ前記処理優先度が高か中の場合に転送無と判断し、前記発生頻度が高で且つ前記処理優先度が中か低の場合または前記発生頻度が中で且つ前記処理優先度が低の場合に転送有と判断することを特徴とする請求項２に記載のネットワーク管理システム。
5. 前記一部のクライアントは、前記ネットワーク機器情報と他のクライアントの通知先アドレスを保持しており、
   前記サーバから送信されてくる状態変化通知を受信し、また前記転送情報に従い前記他のクライアントへ送信するネットワーク通信制御部と、
   前記他のクライアントの通知先アドレスを元に状態変化通知の転送処理を行って前記ネットワーク通信制御部にクライアント送信制御部と、
   前記ネットワーク通信制御部からの状態変化通知に従って前記ネットワーク機器情報を更新し、また前記転送情報に従い前記クライアント送信制御部へ状態変化通知を受け渡すネットワーク情報管理部を有することを特徴とする請求項２〜４に記載のネットワーク管理システム。

Images