JP3885050B2

JP3885050B2 - ネットワーク管理方法

Info

Publication number: JP3885050B2
Application number: JP2003373403A
Authority: JP
Inventors: 重中金光
Original assignee: Kyocera Mita Corp
Current assignee: Kyocera Document Solutions Inc
Priority date: 2003-10-31
Filing date: 2003-10-31
Publication date: 2007-02-21
Anticipated expiration: 2023-10-31
Also published as: JP2005136904A

Description

本発明は、ネットワーク管理方法の技術分野に属する。

従来、ネットワークの監視を行うためのプロトコルとして、いわゆるＳＮＭＰ（Simple Network management Protocol）が用いられている。このＳＮＭＰは、前記ネットワークを構成する管理ステーション及び管理対象ノードそれぞれを管理するために利用され、前者においてはＳＮＭＰマネジャとして機能し、後者においてはＳＮＭＰエージェントとして機能する。このうちＳＮＭＰエージェントの管理用データは、いわゆるＭＩＢ（Management Information Base）という名で標準化されている。

ＭＩＢは、ホストやルータ、アクセス・サーバなどのネットワーク機器上の仮想的な被管理オブジェクトからなる集合体である。ここ被管理オブジェクトは、システム名や入出力トラフィック、経路表（ルーティング・テーブル）などのネットワーク機器上の設定や状態を示す変数として表現される。例えば、インターネット上のシステムの名前を示すＭＩＢ変数は“ｓｙｓＮａｍｅ”として定義され、その値（インスタンス）としてネットワーク機器のシステム名を表す文字列が格納される。また、ＭＩＢは、一般に前記被管理オブジェクトの複数から一つのエントリーが構成され、該エントリーの複数が各別に区分けされたテーブル構造をもっている。これら各エントリーにはインデックス番号が付される。例えば１００件のエントリーがある場合、そのそれぞれに１から１００までのインデックス番号が振られるなどというようである。これにより、被管理オブジェクトの高速操作が可能となる。

なお、インデックス番号としては通常は上述のような連続する値が用いられるが、一般的にはそのように限定されているわけではない。また、前記のテーブルのサイズには事実上制限が無く、インデックス番号を割り当てることができるならば、同時にいくつのエントリーでも保持することができる。

かかる構成を備えたネットワークにおいて、前記管理ステーションは、前述の被管理オブジェクトにアクセスすることによって、ネットワーク機器を管理する。そして、何らかのイベント（例えば、ユーザー操作、スケジューリングなど）の発生に応じて前記ＭＩＢを構成するエントリーを読み込み、一定の処理（例えば、表示処理など）を行うようになっている。

上述のようなＭＩＢに関する技術としては、例えば特許文献１（発明の名称「ネットワークオペレーションシステムにおけるＭＩＢ構成方法及びそのバックアップ方法」、あるいは特許文献２（発明の名称「ネットワーク管理情報検索方式」）等が開示されている。
特開平８−１８１７７２号公報特開平８−３２８９８３号公報

しかしながら、上述のＭＩＢに関連しては次のような問題点がある。すなわちまず、前述のネットワークは同一状態を恒常的に維持しつづけるわけではなく、当該ネットワークの運用中も前記エントリーの増減（即ち、インデックス番号の新規追加・削除）等が生じうるから、一般にＭＩＢの内容は時々刻々と変動することになる。このように、ＭＩＢの内容に変動が生じたときには、その変動がどこに生じたのか等の変動の内容を可能な限り早くに特定できるようになっていることが好ましい。

しかしながら、ＭＩＢにおいては、前述のようにインデックス番号の割り当てが可能である限りエントリーの数を増大させ続けることが可能であり、また前記の被管理オブジェクトもまた相当程度の数に至りうることから、結果的に、ＭＩＢとして展開される情報の全体的な量は莫大なものになりうる。そうすると、前記の変動がどこに生じたか等の変動内容の特定には比較的長い時間が必要となるおそれがある。また、アクセス量も莫大になるから、通信コストの抑制という観点からも問題があることになる。

この点、従来において、前記のようにエントリーの増減があったことを検出する増減カウンタが、ＭＩＢ上のオブジェクトとして備えられているものも知られている。しかし、この増減カウンタは、エントリーの数が増えた又は減ったという事実、すなわち「変動した」という事実を知らせるためのものに過ぎず、その変動の具体的内容がどのようであるかを知らせるものではなかった。したがって、このような増減カウンタを設けていたとしても、変動内容の特定を短時間に行いたい、あるいは通信コストを抑制したい等という要求には十分に応えることができない。

本発明は、上記問題点に鑑みてなされたものであり、エントリーの増加又は減少からなる変動の発生を検出するとともに、当該変動の内容をより迅速かつ低コストで特定しうるネットワーク管理方法を提供することを課題とする。

本発明のネットワーク管理方法は、上記課題を解決するため、少なくとも一つの管理コンソール及び少なくとも一つの被管理端末を含むネットワークをＳＮＭＰによって管理するネットワーク管理方法であって、前記被管理端末側において、複数の行エントリーが含まれている現在値エントリー部において前記行エントリーの追加又は削除を実施する変動工程と、当該変動工程に応じて前記追加又は前記削除の対象とされた行エントリーを特定するための固有情報を補助エントリー部に記録する工程とを含む。

本発明のネットワーク管理方法によれば、管理対象側において行エントリーの追加又は削除が発生すると、その変動の痕跡が現在値エントリー部に記録されるだけでなく、補助エントリー部にも記録されるようになっている。この場合、補助エントリー部における変動の痕跡の記録は、前述の追加又は削除の対象とされた行エントリーを特定するための固有情報の記録をもって行われる。したがって、行エントリーの変動が生じた場合、その変動がどのような内容をもつものであったのかは、前記固有情報を利用することにより好適に把握することが可能となる。この点、従来において変動内容の特定を行おうとすれば、本発明にいう「現在値エントリー部」に含まれるすべての行エントリーを管理コンソール側で改めて読み込むという処理が必要であったのとは大きく異なる（従来では、かかる処理を実行することによって、比較的長い処理時間と莫大な通信量とが必要であった。）。

以上のように、本発明によれば、前記の固有情報を利用することによって、前記変動の内容の把握をより迅速に且つ低コストで実現することができる。また、本発明によれば特に、補助エントリー部に記録されるのが、行エントリーに含まれる全情報ではなくて固有情報のみとすることが可能であるから、補助エントリー部内において保持すべき全体的なデータ量を相対的に減少させることができる。ただし、本発明においては、前記にいう固有情報に併せて、行エントリーに含まれる何らかの情報を、補助エントリー部に記録するような形態を採用してよいことは言うまでもない。

本発明のこのような作用及び効果その他の利得は次に説明する実施の形態から明らかにされる。

以下では、本発明の実施の形態について図を参照しつつ説明する。以下の実施形態は、本発明のネットワーク管理方法を液晶装置に適用したものである。

まず、本実施形態にかかるネットワーク管理方法に用いられて好適な構成例を、図１及び図２を参照して説明する。ここに図１は本実施形態のネットワーク管理方法を実施するにあたり利用される各概念の関係を示す構成図であり、図２はＭＩＢのテーブル構造の例を示す説明図である。

図１において、本実施形態のネットワーク管理方法を実施するにあたり利用される各概念は、大きく、現在値エントリー部ＣＥ、追加エントリーＡＥ部及び削除エントリー部ＲＥからなる（図１においては、それぞれ“ＣｕｒｒｅｎｔＥｎｔｒｙ”、“ＡｄｄｅｄＥｎｔｒｙ”及び“ＲｅｍｏｖｅｄＥｎｔｒｙ”と表されている。）。このうち現在値エントリー部ＣＥは、情報種目（後述の図２参照）についての現時点における値を記録する。また、追加エントリー部ＡＥは情報種目について新規に追加された値情報を記録し、削除エントリー部ＲＥは現在値エントリー部ＣＥから削除された値情報を記録する。これら現在値エントリー部ＣＥ、追加エントリーＡＥ部及び削除エントリーＲＥ部のそれぞれは、複数の行エントリー（図１においては“item”ないしは“Ｉｔｅｍ”と表現されている。）を持つ。なお、以下では、現在値エントリー部ＣＥに対応する行エントリーを特に呼称する場合には、これを「現在値エントリー」と呼び、同じく追加エントリー部ＡＥに対応する行エントリーを「追加エントリー」、削除エントリー部ＲＥに対応する行エントリーを「削除エントリー」とそれぞれ呼ぶことがある（それぞれ図１における符号“ＣＩ”、“ＡＩ”及び“ＲＩ”参照）。

図１におけるテーブルＴは、その内部で発生した追加・削除等行エントリーの変動イベントの発生回数を保持するカウンタを有している（図１においては“ｅｖｅｎｔＣｏｕｎｔ”と表されている。）。これは、前述の現在値エントリー部ＣＥ、追加エントリー部ＡＥ部及び削除エントリー部ＲＥにおいて発生する行エントリーの変動イベント（行エントリーの変動については後述する。）の発生回数を保持する。このカウンタは、追加・削除の別なく、発生した「変動」にとにかく対応するものであり、ＳＮＭＰエージェントの起動時から一意に増加する性質を有する。

前述の現在値エントリーＣＩ、追加エントリーＡＩ及び削除エントリーＲＩ間で、各種の情報を保持するための構造はそれぞれについて共通となっており、具体的には図２のようになっている。図２において、これら複数の行エントリーの各々にはインデックス番号１，２，３，…，ｎが付されている（以下、「行エントリー１，２，…，ｎ」等と記すことがある。）。また、複数の行エントリー１，２，…，ｎの各々は複数の情報種目からなっている。例えば行エントリー１は情報種目１（１），１（２），…，１（ｍ₁）からなり、行エントリー２は情報種目２（１），２（２），…，２（ｍ₂）からなる、などとなっている。ここに図２に示すｍ₁，ｍ₂，…，ｍ_pについては、ｍ₁＝ｍ₂＝…＝ｍ_p、あるいはｍ₁≠ｍ₂≠…≠ｍ_pであってもよく、さらにはｍ₁，ｍ₂，…，ｍ_pのうち一部は等しいが、その他は等しくないなどであってもよい。

そして、本実施形態においては特に、各行エントリー１，２，…，ｎにはシリアル番号Ｓ１，Ｓ２，…，Ｓｎが付されている。これらシリアル番号の各値は一意に単調増加する性質を有する。例えば、Ｓ１＜Ｓ２＜…＜ＳｎやＳｎ＜Ｓｎ―１＜…＜Ｓ１が成立するということである（これ以外にも、Ｓ１，Ｓ２，…，Ｓｎの各値が、その順番（１，２，…，ｎ）に関わらず、単調に増加する関係にあればよい。）。このシリアル番号は、新規の行エントリーが新たに追加される時点において当該行エントリーに対して付与される。例えば、前記のＳ１，Ｓ２，…，Ｓｎについて、Ｓ１＜Ｓ２＜…＜Ｓｎが成立するとして、ここに新しい行エントリーｎ＋１が加わるとするなら、この行エントリーｎ＋１のシリアル番号Ｓｎ＋１については、前述の単調増加という性質をみたすため、Ｓｎ＋１＞Ｓ１，Ｓ２，…，Ｓｎが成立することになる。

現在値エントリー部ＣＥ内の行エントリーは、通常のＭＩＢと同様、前述の共通構造の他に必要な値（インスタンス）を保持する。一方、削除エントリー部ＲＥ内及び追加エントリー部ＡＥ内の行エントリーは、具体的な値をもたず前述の共通構造のみを持つ。これにより、不要なデータをもたず、したがってそのサイズ（行エントリーサイズ）を削減する効果が得られる。ただし、これら削除エントリー部ＲＥ及び追加エントリー部ＡＥ内に配置されるべき各行エントリーは、それらに固有の値として、関連する現在値エントリーに付されたインデックス番号、あるいはシリアル番号の値を持つ（図１において、追加エントリーＡＩ及び削除エントリーＲＩの中に、 “ＣｕｒｒｎｅｔＩｔｅｍＲｅｆ”と表されていることが、その「値を持つ」ということに対応している。）。

また、現在値エントリー部ＣＥは、制御情報として、該現在値エントリー部ＣＥ内における行エントリーの行数、先頭行のシリアル番号及び最終行のシリアル番号を持つ（図１においてはそれぞれ“ｉｔｅｍＣｏｕｎｔ”、“ｂｅｉｎｇ”及び“ｅｎｄ”と表されている。）。さらに、削除エントリー部ＲＥ及び追加エントリー部ＡＥもまた、それぞれ、制御情報として、該削除エントリー部ＲＥ内及び該追加エントリー部ＡＥ内における行エントリーの数、先頭行のシリアル番号及び最終行のシリアル番号を持つ。

かかる構成は、例えば以下のように運用され、その結果次に記すような効果が得られることになる。以下では、これを図３から図６を参照しながら説明する。ここに図３は、初期状態における処理の流れを示すフローチャートであり、図４は、管理コンソールにおける監視処理の流れ、及び、その監視の結果変動を確認した場合における変動対応処理の流れを示すフローチャートである。また、図５は行エントリーの追加が発生した場合におけるＳＮＭＰエージェント側の処理の流れを示すフローチャートであり、図６は行エントリーの削除が発生した場合におけるＳＮＭＰエージェント側の処理の流れを示すフローチャートである。

まず、初期状態においては、図３に示すような処理が行われる。すなわち、内部情報を初期化した後（図３のステップＳ１００）、管理コンソールは前述のテーブルにアクセスして、現在値エントリー部ＣＥ内の行エントリーの全部を読み込む。すなわち、図２に示した各エントリー１，２，…，ｎ中の各情報種目１（１），１（２），…，１（ｍ₁）、２（１），２（２），…，２（ｍ₂）、…、ｎ（１），ｎ（２），…，ｎ（ｍ_p）のすべてについてアクセスし、これらを読み込むのである（図３のステップＳ１０１ないしステップＳ１０３）。

次に、管理コンソールは、読み込んだ行エントリー群の最初と最後のシリアル番号を保持しておく（図３のステップＳ１０４）。例えば、図２のような例の場合には、最初のシリアル番号として“Ｓ１”、最後のシリアル番号として“Ｓｎ”を保持する。なお、この値は、現在値エントリー部ＣＥのもつｂｅｇｉｎ値及びｅｎｄ値と同じ値となる。

また、初期状態においては、管理コンソールは、行エントリーの変動イベントの発生回数の値も保持しておく。さらに、管理コンソールは、追加エントリー部ＡＥ及び削除エントリー部ＲＥにおけるｉｔｅｍＣｏｕｎｔ値（すなわち、行エントリーの数）を保持しておく（図３のステップＳ１０５）とともに、それらににおけるｂｅｇｉｎ値、及びｅｎｄ値（すなわち、最初及び最後の行エントリーのシリアル番号）をも保存しておく。

このような初期状態を経た上で、管理コンソールは、図４に示すようにテーブルのｅｖｅｎｔＣｏｕｎｔの値を監視し、前述の初期状態における処理によって保持された値と異なる値を検出した場合、テーブルに変動が発生したと見なす（図４のステップＳ２０１；ＹＥＳ）。なお、変動が発生したかどうかは、ＳＮＭＰエージェントからのＴＲＡＰメッセージにより検出することも可能である。

そして、変動が発生したと判断される場合には、管理コンソールは、追加エントリー部ＡＥ及び削除エントリー部ＲＥからｉｔｅｍＣｏｕｎｔ値を取得するとともに（図４のステップＳ２０２）、その取得したｉｔｅｍＣｏｕｎｔ値と、図３のステップＳ１０５においてすでに得られている値とを比較することによって、当該変動の内容を把握することができる。そして、ここで把握された変動の内容に応じて、変動対応処理が行われる（以上、図４のステップＳ２０４）。ここに上述したような処理は、より具体的には次のように行われる。

第１に、テーブルへ行エントリーが追加された場合について説明する。まず、デバイス（ＳＮＭＰエージェント側の装置。以下同じ。）の内部状態遷移などにより、テーブルに行エントリーの追加が発生した場合には、ＳＮＭＰエージェント側において図５に示すような処理が行われる。すなわち、その新たな行エントリーは、現在値エントリー部ＣＥに追加されるとともに、該行エントリーには当該現在値エントリー部ＣＥの内部での位置を示す新たなインデックス番号とシリアル番号が付与される（図５のステップＳ３０１）。これにより、現在値エントリー部ＣＥが提供するｅｎｄ値は、この新たに追加された行エントリーのシリアル番号の値に更新される（図５のステップＳ３０２）。このとき、もし、追加が複数の行エントリーについて行われた場合には、このｅｎｄ値は最後に追加された行エントリーの持つシリアル番号となる。また、現在値エントリー部ＣＥのｉｔｅｍＣｏｕｎｔ値は、前述の行エントリーの追加により、その追加された行エントリーの数の分だけカウントアップされる（図５のステップＳ３０３）。

続いて、このようにして現在値エントリー部ＣＥに行エントリーが追加されたときには、該行エントリーに上述のように付与されたインデックス番号とシリアル番号とをもつ行エントリーが、追加エントリー部ＡＥにも追加される（図５のステップＳ３０４）。また、これにより、追加エントリー部ＡＥのｉｔｅｍＣｏｕｎｔ値が増加すると同時に、当該追加エントリー部ＡＥのｅｎｄ値と、場合により（後述の「再構築」に関する説明参照）、ｂｅｇｉｎ値が更新される（図５のステップＳ３０５）。

一方、管理コンソールは、前述の図４を参照して説明したような監視処理の結果、行エントリーの「追加」を検出することができる。これは、図４のステップＳ２０２において取得されるｉｔｅｍＣｏｕｎｔ値が、前述のように更新されている（図５のステップＳ３０４及びＳ３０５参照）ことにより、初期状態において保持していた当該値との間に差異をみつけることができるからである。そして、このようにして行エントリーの追加が検出されたら、その後更に、図４のステップＳ３１１以降に示すような処理が行われる。

まず、管理コンソールは現在値エントリー部ＣＥのｂｅｇｉｎ値を読み込むとともに（図４のステップＳ３１１）、この読み込んだｂｅｇｉｎ値に基づいて前回読み取った行エントリーリストの有効性を判断する（図４のステップＳ３１２）。ここで、ＳＮＭＰエージェント側で行エントリーの再構築が発生しない限り、ｂｅｇｉｎ値は追加処理によって変動しないため、この比較によって、再構築処理発生の有無を判断することができる。再構築処理が発生した場合には、管理コンソールは現時点における行エントリーのすべてを再取得する（図４のステップＳ３１３）。

続いて、管理コンソールは現在値エントリー部ＣＥのｅｎｄ値を読み込み、前回のｅｎｄ値からの増加量を算出する（図４のステップＳ３１４）。さらに、管理コンソールは、追加エントリー部ＡＥのｅｎｄ値を読み込み、前回読み取った時のｅｎｄ値から変移が生じていることを、それらの差である変移量を算出することにより確認する（図４のステップＳ３１５）。この変移量は、原則として前述のステップＳ３１４によって得られる増加量と一致するはずである（本質的に同じ変移（行エントリーの追加）に対応しているから。）。しかしながら、増加量と変移量とが一致しない場合もありえ、そのような判断がなされる場合には、テーブルの再構築が行われたものと判断し、追加エントリー部ＡＥ内の行エントリーすべてを処理対象とする（この点については図示されていないが、前述のステップＳ３１３参照）。なお、追加エントリー部ＡＥ内の再構築処理の発生は、前回保存したｂｅｇｉｎ値と現在のｂｅｇｉｎ値を比較することによっても検出することができる。

次に、管理コンソールは、前回の追加検索処理にて保存しておいたｉｔｅｍＣｏｕｎｔ値から、追加エントリー部ＡＥ内の前回の最終行エントリーを算出する（図４のステップＳ３１６）。そして、この前回の最終行エントリーから、前記の増加量ないしは変移量の分だけ行エントリーを読み出し、そのそれぞれのｉｔｅｍＣｏｕｎｔＲｅｆ値（図１参照）を確認するとともに、該ｉｔｅｍＣｏｕｎｔＲｅｆ値に基づいて現在値エントリー部ＣＥから該当する行エントリーを読み出す（図４のステップＳ３１７）。これは、追加された行エントリーが特定されながら読み出されていることを意味している。最後に、管理コンソールは、前記のように読み出された行エントリーを内部に保存し、また追加エントリー部ＡＥのｂｅｇｉｎ値、ｅｎｄ値及びｉｔｅｍＣｏｕｎｔ値などの必要な情報を保存する（以上、図４のステップＳ３１８）。

このような処理を実施することにより、次のような利点が得られる。第１に、変動部へのリンク情報が追加エントリー部ＡＥとしてコンパクトにまとめられていることから、例えば図１において現在値エントリー部ＣＥしか存在しない場合などという従来相当の構成例に比べて、行エントリーの追加が発生したことの特定が容易に可能となっている。また第２に、追加エントリー部ＡＥ内を検索する場合においても、そのすべてを読み込んでいくのではなく、前述でいうｉｔｅｍＣｏｕｎｔＲｅｆ値を効果的に利用することによって、前回使用分はスキップした上での読み込みを行うことができるから、作業時間の短縮化、更には通信量の低減化を図ることができる。さらに第３には、前述のように再構築処理が発生した場合にも、好適な対応が可能となっていることも有効である（図４のステップＳ３１２及びステップＳ３１３参照）。

続いて第２に、テーブルから行エントリーが削除された場合について説明する。まず、デバイスの内部状態遷移などにより、テーブルに行エントリーの削除が発生した場合には、ＳＮＭＰエージェント側において図６に示すような処理が行われる。すなわち、当該行エントリーは現在値エントリー部ＣＥから削除される（図６にステップＳ４０１）。なお、この際、インデックス値を再計算させる構成としてもよい。これにより、現在値エントリー部ＣＥの持つｉｔｅｍＣｏｕｎｔ値は減少方向に更新される（図６にステップＳ４０２）。次に、これに応じて、削除された行エントリーのシリアル番号が、削除エントリー部ＲＥの行エントリーとして追加される（図６にステップＳ４０３）。この時、行エントリーはシリアル番号によってソートされて追加される。また、その結果、削除エントリー部ＲＥのｉｔｅｍＣｏｕｎｔ値が増加する（図６にステップＳ４０４）。さらに、削除された行エントリーのシリアル値がすでにリスト中にあるｂｅｇｉｎ値よりも小さい場合にはｂｅｇｉｎ値が、ｅｎｄ値よりも大きい場合にはｅｎｄ値が更新される（図６にステップＳ４０５）。ちなみに、テーブルのｅｖｅｎｔＣｏｕｎｔは、前述の行エントリの削除に応じて増加する。また、現在値エントリー部ＣＥ及び削除エントリー部ＲＥに増減カウンタを設ける場合には、これらも前述の行エントリの削除に応じて増加する。

一方、管理コンソールは、前述の図４を参照して説明したような監視処理の結果、行エントリーの「削除」を検出することができる。これは、図４のステップＳ２０２において取得されるｉｔｅｍＣｏｕｎｔ値が、前述のように更新されている（図５のステップＳ４０４参照）ことにより、初期状態において保持していた当該値との間に差異をみつけることができるからである。そして、このようにして行エントリーの削除が検出されたら、その後さらに、図４のステップＳ４１１以降に示すような処理が行われる。

すなわち、管理コンソールは削除エントリー部ＲＥから削除された行エントリーのシリアル番号を取得する（図５のステップＳ４１１）。次に、管理コンソールは、このシリアル番号に基づいて、その内部で保存していた行エントリーのリストを更新する（図５のステップＳ４１２）。この作業は、より具体的には、当該管理コンソールがもっていた前記リストから、当該行エントリーを消し込むというイメージで捕らえられる。ここで、削除された行エントリーの特定が、シリアル番号の利用によって容易に行われていることに本実施形態の大きな特徴がある。なお、この際においては、現在値エントリー部ＣＥのもつｂｅｇｉｎ値、ｅｎｄ値及びｉｔｅｍＣｏｕｎｔ値を確認することで、削除されたと検出された行エントリーが、本当に削除されたものであるかどうかをより確実に確認することができる（いわば当該判断の検証が可能になるということである。）。

以上のような運用がなされることによって、本実施形態においては以下のような作用効果が得られることになる。すなわち、一般に、ＭＩＢにおいては、行エントリーの数が数百から数千個存在する可能性がある（図２でいえば、“ｎ”が数百から数千という値をとるということ。）。この場合、行エントリーの追加又は削除が発生するたびに、すべての行エントリーをＳＮＭＰエージェント側からすべて取得しなおさなければならないとすれば、それは非常に煩瑣で面倒なことになり、また通信量が莫大となってネットワークに過大な負荷をかけることになる。

しかるに、本実施形態では、行エントリーの追加又は削除が発生したとしても、上述のようにその変動の内容が正確に把握されることから、上述のような不具合を被るおそれがないのである。しかも、このような変動内容の把握は、いわゆる“ポーリング”によって状態変化を把握するタイプの管理コンソールでも、その利点を十分に享受することができる。

ちなみに、前述のような従来の不具合を回避するためには、いわゆる“ＴＲＡＰ”を応用する方法も考えられるが、一般的にデバイスから送出できるＴＲＡＰメッセージの宛先数は限られており、管理コンソールが比較的多く設置されているような環境では完全には追随できないことになる。この点からしても、本実施形態、さらには本発明の優位性は明らかである。

なお、前述において“ポーリング”とは一般に、通信システム全体を管理する装置あるいはプログラムが、他の装置あるいはプログラムに対して、通信をしたいかどうかの問い合わせメッセージを順番に送る処理をいう。ただし、ポーリングとは、広義には、前記の問い合わせメッセージを受けた他の装置あるいはプログラムから返答があれば送信権を与えて送信させる処理までも含む。また、“ＴＲＡＰ”とは、何らかの障害や状態変化などの事象、即ち一般にイベントが発生したかどうかの通知を行う処理をいう。

なお、上述の実施形態においては、以下に記すような削除エントリー部ＲＥのメンテナンス処理が実施されるような構成を併せ持っていてもよい。例えば第１には、何らかの外部操作、例えば特定のＭＩＢオブジェクト操作によって、削除エントリー部ＲＥの内容をリセットすることができる。ここでリセットとは全部削除を意味する。また第２に、あらかじめ設定された時間が経過することにより、削除エントリー部ＲＥの内容をリセットすることができる。あるいはまた第３に、行エントリーの保持はあらかじめ設定された容量分だけ行うとともに、その容量分を超える行エントリーを保持する必要が出てきた場合には、最も古くに登録された行エントリーから逐次削除していくこともできる。

さらには、上述したような削除エントリー部ＲＥのメンテナンス処理に関する設定は、外部操作、例えば特定ＭＩＢオブジェクトへの操作によって行わせることができる。また、上記で発生するリセット操作を通知するＴＲＡＰメッセージを送出することができる。

このように、削除エントリー部ＲＥ内のメンテナンス処理が実行されるようになっていれば、前述した本実施形態に係る作用効果をより効果的に享受することができる。というのも、仮に削除エントリー部ＲＥ内に保持される行エントリーの数が無制限とされているならば、その結果、通信量が増大し、処理時間の長大化がもたらされるおそれが生じるところ、前記のようなメンテナンス処理が実行されるようになっていれば、削除エントリー部ＲＥ内の行エントリーの数は常に適正に保持されることになり、かかる不具合について懸念する必要がなくなるからである。

本発明は、上述した実施形態に限られるものではなく、請求の範囲及び明細書全体から読み取れる発明の要旨、あるいは思想に反しない範囲で適宜変更可能であり、そのような変更を伴うネットワーク管理方法もまた、本発明の技術的範囲に含まれるものである。

本実施形態のネットワーク管理方法を実施するにあたり利用される各概念の関係を示す構成図である。ＭＩＢのテーブル構造の例を示す説明図である。初期状態における処理の流れを示すフローチャートである。管理コンソールにおける監視処理の流れ、及び、その監視の結果行エントリーにつき変動を確認した場合における変動対応処理の流れを示すフローチャートである。行エントリーの追加が発生した場合におけるＳＮＭＰエージェント側の処理の流れを示すフローチャートである。行エントリーの削除が発生した場合におけるＳＮＭＰエージェント側の処理の流れを示すフローチャートである。

符号の説明

ＣＥ…現在値エントリー部
ＡＥ…追加エントリー部
ＲＥ…削除エントリー部
Ｓ１，Ｓ２，…，Ｓｎ…シリアル番号

Claims

少なくとも一つの管理コンソール及び少なくとも一つの被管理端末を含むネットワークをＳＮＭＰによって管理するネットワーク管理方法であって、
前記被管理端末側において、
複数の行エントリーが含まれている現在値エントリー部において前記行エントリーの削除を実施する変動工程と、
当該変動工程に応じて前記削除の対象とされた行エントリーを特定するための固有情報を削除エントリー部に記録する工程と、
前記管理コンソール側において、
前記現在値エントリー部に含まれる行エントリーのリストを生成するリスト生成工程と、
前記削除に応じて前記固有情報を前記削除エントリー部に記録する工程と、
前記削除エントリー部に記録された固有情報に応じて前記行エントリーのリストを更新する工程と
を含むことを特徴とするネットワーク管理方法。
前記変動工程は、複数の行エントリーが含まれている現在値エントリー部において前記行エントリーの追加を実施するものであり、
前記被管理端末側において、
当該変動工程に応じて前記追加の対象とされた行エントリーを特定するための固有情報を追加エントリー部に記録する工程と、
前記管理コンソール側において、
前記追加エントリー部に記録されている固有情報によって特定される行エントリーのうち最終行の行エントリーを特定する工程と、
前記現在値エントリー部の中から、前記最終行の行エントリーを起点として前記最終行の行エントリーを特定する工程で特定された行エントリーを読み出す工程と
を更に含むことを特徴とする請求項１に記載のネットワーク管理方法。
少なくとも一つの管理コンソール及び少なくとも一つの被管理端末を含むネットワークをＳＮＭＰによって管理するネットワーク管理方法であって、
前記被管理端末側において、
複数の行エントリーが含まれている現在値エントリー部において前記行エントリーの追加を実施する変動工程と、
当該変動工程に応じて前記追加の対象とされた行エントリーを特定するための固有情報を追加エントリー部に記録する工程と、
前記管理コンソール側において、
追加エントリー部に記録されている固有情報によって特定される行エントリーのうち最終行の行エントリーを特定する工程と、
前記追加に応じて前記固有情報を前記追加エントリー部に記録する工程と、
前記現在値エントリー部の中から、前記最終行の行エントリーを起点として前記最終行の行エントリーを特定する工程で特定された行エントリーを読み出す工程と
を含むことを特徴とするネットワーク管理方法。
前記固有情報は、前記複数の行エントリーのそれぞれに一意に付与されるシリアル番号を含むことを特徴とする請求項１乃至３のいずれか一項に記載のネットワーク管理方法。