(57)【要約】【課題】本発明はマネージャ−エージェント型情報収集アプリケーションのロードバランス方法及び装置に関し、輻輳が発生した場合でも確実にＮＥのデータ収集が既定の時刻及び周期で行なえるようなマネージャ−エージェント型情報収集アプリケーションのロードバランス方法及び装置を提供することを目的としている。【解決手段】複数のＩＰネットワーク装置ＮＥが保持している複数のトラフィック情報を収集する、それぞれが分散して配置されたサーバ１０内のエージェント１１，１２と、エージェント１１，１２を一意に識別するエージェント番号とエージェントが収集する項目を一意に識別する収集項目番号を対応付けているエージェント収集項目対応テーブル２５と、一意に識別できる収集項目の名称，ＩＰネットワーク装置側情報の参照点・データ型・収集周期を定義している収集項目テーブル２６と、を有して構成する。【選択図】      図２
2004274289.tif 000002
【特許請求の範囲】
【請求項１】
ＩＰネットワークのトラフィック情報を各ＩＰネットワーク装置から収集するマネージャ−エージェント型のアプリケーションにおいて、ポリシーに基づき収集項目数，収集周期，データ処理能力から各エージェントの収集対象範囲を動的に変更させ（ステップ１）、
各エージェントは前記変更された収集対象範囲に基づいてデータを収集する（ステップ２）
ことを特徴とするマネージャ−エージェント型情報収集アプリケーションのロードバランス方法。
【請求項２】
複数のＩＰネットワーク装置を管理する複数のハードウェアで構成されるネットワーク管理システムであって、ＳＬＡ（Ｓｅｒｖｉｃｅ  Ｌｅｖｅｌ  Ａｇｒｅｅｍｅｎｔ）及びそれに基づくサービス品質情報開示、かつまたネットワーク運用状況の把握に利用されるトラフィック情報を複数のＩＰネットワーク装置から収集するマネージャ−エージェント型のアプリケーションにおいて、
複数のＩＰネットワーク装置が保持している複数のトラフィック情報を収集する、それぞれが分散して配置されたサーバ内のエージェントと、
エージェントを一意に識別するエージェント番号とエージェントが収集する項目を一意に識別する収集項目番号を対応付けているエージェント収集項目対応テーブルと、
一意に識別できる収集項目の名称，ＩＰネットワーク装置側情報の参照点・データ型・収集周期を定義している収集項目テーブルと、
を有することを特徴とするマネージャ−エージェント型情報収集アプリケーションのロードバランス装置。
【請求項３】
システムのハード的かつ又はソフト的な監視デバイスから出力されるサーバの処理性能情報を監視して、各サーバの輻輳発生及び輻輳からの復旧を検出する輻輳検出器と、
各エージェントを一意に識別するエージェント番号と、サーバを一意に識別するサーバ番号を対応付けているエージェント／サーバ対応テーブルと、
収集項目とエージェントの対応を輻輳状況により再編成するための様式を定義する収集ポリシー定義テーブルと、
前記輻輳検出器の通知により、収集ポリシー定義テーブルから輻輳状況に適合するポリシーを取得し、収集項目とエージェントの対応を再編成する収集項目編成演算器と、
を更に有することを特徴とする請求項２記載のマネージャ−エージェント型情報収集アプリケーションのロードバランス装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はマネージャ−エージェント型情報収集アプリケーションのロードバランス方法及び装置に関し、更に詳しくはＩＰネットワークを構成するルータ、ブリッジ、コンピュータ装置等の複数のネットワーク装置（ＮＥ：ＮｅｔｗｏｒｋＥｌｅｍｅｎｔ：ネットワークサービスを実現する機能を持つ装置のこと）を管理するためのネットワーク管理システムにおけるマネージャ−エージェント型のデータ収集アプリケーションのロードバランス方法及び装置に関する。代表的なデータ収集機能の例としては、ルータが処理したＩＰパケットの入出力パケット数、パケットロス数、廃棄パケット数の定期収集等が考えられる。
【０００２】
ネットワーク管理システムの一部プロセスの輻輳に対して、データ収集機能の維持はネットワーク管理業務だけでなく、ＳＬＡに基づく顧客へのネットワークサービス品質情報開示にも関わる、ネットワーク管理システムに期待される課題の一つであるが、本発明はこのような輻輳時のデータ収集維持に関するものである。
【０００３】
図１１は、本発明の利用分野の説明図である。図において、１はＮＥであり、複数のＮＥが互いに接続しあって、ＩＰネットワーク２〜４を構成している。５はＮＥ１と接続され、ネットワークの監視を行なうネットワーク管理システムである。ネットワーク管理システム５は、ネットワーク情報をネットワーク管理者６に送信する。そして、該ネットワーク管理者６は、ネットワーク監視と品質確認を行なう。また、ネットワーク管理システム５は、営業・コールセンタ７にもネットワーク情報を送信する。営業・コールセンタ７では、ＳＬＡ情報（サービス品質情報）として顧客８に提示する。
【０００４】
【従来の技術】
この種のネットワーク監視システムとしては、集中管理・制御型ネットワークの負荷制御に関し、集中管理・制御装置の過負荷状態の発生要因に応じて過負荷制御を効率的に行なう技術がある（例えば、特許文献１参照）。
【０００５】
また、複数のマネージャノードと、複数のネットワーク資源を管理するエージェントノードから構成されるネットワーク管理システムにおいて、ネットワークの負荷に応じて管理トラフィック発生の頻度を自動的に最適化する技術がある（例えば特許文献２参照）。
【０００６】
ネットワーク管理システムは、複数のハードウェア（サーバと呼ぶ）から構成されており、その処理単位（プロセスと呼ぶ）は近年の分散オブジェクト環境（若しくはＣＯＲＢＡ（Ｃｏｍｍｏｎ  Ｏｂｊｅｃｔ  Ｒｅｑｕｅｓｔ  Ｂｒｏｋｅｒ  Ａｒｃｈｉｔｅｃｔｕｒｅ）と呼ぶ）等の既存技術により、任意に起動されるサーバを変更することができる。
【０００７】
上記ＩＰネットワークサービスを実現するＮＥ群が、ネットワーク上で稼働している状態で、データ収集アプリケーションを含むネットワーク管理システムは、
▲１▼ＳＬＡに基づく顧客に対するサービス品質情報開示に含まれるネットワークサービス品質保証、
▲２▼ネットワーク保守、ネットワーク障害検知、ネットワーク料金計算、設備投資予測、
等の観点から、ＮＥが保持するネットワーク性能情報を定期的に収集し、保存しておく機能が要求される。この時、ＩＰネットワークを構成するＮＥが保持するネットワーク性能情報とは、一般的にＳＮＭＰ（Ｓｉｍｐｌｅ  ＮｅｔｗｏｒｋＭａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ）通信による取得・設定可能なＭＩＢ（Ｍａｎａｇｅｍｅｎｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂａｓｅ）に保持されているのが通常である。また、ＮＥはＭＩＢに保持しているネットワーク性能情報を随時更新している場合が多く、時間経過により加算される数値情報の場合にはＭＩＢが収容する最大値を超えた場合、情報は再び０から開始されるのが通常である。このため、データ収集アプリケーションは、各収集項目の利用目的毎に固有の収集周期によりデータ収集を行なう必要がある。
【０００８】
【特許文献１】
特開平９−８９０７号公報（第４頁、第５頁、図１）
【特許文献２】
特開平９−２７０７９４号公報（第４頁、図１）
【０００９】
【発明が解決しようとする課題】
しかしながら、以下の点において、このデータ収集が乱される場合がある。
▲１▼あるサーバに配置されたエージェントで、サーバが含む他の管理処理で輻輳が発生することで、そのエージェントに割り当てられるサーバの処理時間が少なくなり、ひいてはエージェントの収集処理に時間がかかってしまい、既定の収集周期でデータ収集が完了できず、既定の時刻に対する実際の収集時刻の遅延かつ又は収集データの欠落が起こる場合がある。
▲２▼あるサーバに配置されたエージェントで、サーバが含む他の管理処理で発生した輻輳状態は復旧したものの、収集周期の遅延により、実際の収集時刻と既定の収集時刻との間にずれが生じ、周期は同じであるが収集項目登録時とは異なる時刻に収集するようになる場合がある。
【００１０】
図１２は多量の故障情報を一度に受信した場合の動作説明図である。図１１と同一のものは、同一の符号を付して示す。図において、１はＮＥである。１０はＩＰネットワーク２〜４の状態を監視するサーバである。サーバ１０において、１１，１２はＮＥ１の状態を収集する収集エージェント、１３はＮＥ１の故障状態を管理する故障管理機能部、１４はネットワーク制御機能部である。１３、１４は一般的なネットワーク管理システムが保持する機能を指しており、同一サーバ内に配置される別機能であってもよい。１５は収集情報を記憶するために、サーバ１０内に設けられたデータベースである。該データベース１５の情報は、オペレータ１６，１７により必要に応じて読み出される。
【００１１】
このように構成されたシステムにおいて、収集エージェント１１，１２はＮＥ１に対して定期的に状態を収集する。そして、これら収集エージェント１１，１２から収集されたデータは、サーバ１０内のデータベース１５に記憶される。ここで、ＮＥ１から故障管理機能部１３の処理能力を超える大量の故障情報が同時に通知された場合、サーバ１０に輻輳が発生する。
【００１２】
サーバ１０に輻輳が発生すると、収集エージェント１２は既定周期かつ既定時刻でデータ収集を完遂不能な状況に陥ることになる。この結果、収集エージェント１２は既定周期かつ既定時刻にデータベース１５にデータを登録することができなくなり、データベース１５上にデータ欠落が発生する。
【００１３】
図１３は正常な場合と輻輳時におけるデータ収集のタイミングを示す図である。（ａ）は正常な場合のデータ収集タイミングを、（ｂ）は輻輳時のデータ収集タイミングをそれぞれ示す。収集項目はＡ〜Ｃまでであるものとする。周期Ｔａは収集項目Ａの収集周期を、周期Ｔｂは収集項目Ｂの収集周期を、周期Ｔｃは収集項目Ｃの収集周期をそれぞれ示す。周期のスタートは、一致する場合としない場合とがある。
【００１４】
（ｂ）は輻輳時の場合の収集タイミングを示す。図に示す時刻ｔ１で輻輳が発生したものとする。輻輳中は、既定の周期ではデータ収集できない。また、輻輳回復後１回目のデータ収集以後、既定周期での収集が再開するが、収集時刻について正常な場合との間にずれが生じる。
【００１５】
本発明はこのような課題を解決するものであって、輻輳が発生した場合でも確実にＮＥからデータ収集が既定の時刻及び周期で行なえるようなマネージャ−エージェント型情報収集アプリケーションのロードバランス方法及び装置を提供することを目的としている。
【００１６】
【課題を解決するための手段】
（１）請求項１記載の発明は、以下の通りである。図１は本発明方法の原理を示すフローチャートである。本発明は、ＩＰネットワークのトラフィック情報を各ＩＰネットワーク装置から収集するマネージャ−エージェント型のアプリケーションにおいて、ポリシーに基づき収集項目数，収集周期，データ処理能力から各エージェントの収集対象範囲を動的に変更させ（ステップ１）、各エージェントは前記変更された収集対象範囲に基づいてデータを収集する（ステップ２）ことを特徴とする。
【００１７】
ここで、ポリシーとは、ある条件に対して実行すべき行動かつ又は行動のために必要なパラメータを定義したものであって、ポリシーの適用主体もしくは適用主体を取り巻く環境が、前記の条件に適合した場合に、適用主体はその条件に対する行動かつ又は行動のために必要なパラメータを取得し、自身の行動を変化させるものである。
【００１８】
従って、輻輳状況をポリシー条件とし、エージェントの収集対象範囲の拡縮を行動として定義することで、輻輳が発生した場合でも確実にＮＥからデータ収集を行なうことができる。
（２）請求項２記載の発明は、以下の通りである。図２は本発明の原理ブロック図である。図１２と同一のものは、同一の符号を付して示す。図において、２０はサーバ１０を含むネットワーク管理システムである。サーバ１０はそれぞれが分散して配置されている。サーバ１０において、１１，１２はＮＥからデータを一定周期で取り込む収集エージェント、１３はＮＥ網の故障状態を管理する故障管理機能部、１４はネットワーク制御機能部である。
【００１９】
１３，１４は一般的なネットワーク管理システムが保持する機能を示しており、同一サーバ内に配置される別機能であってもよい。１５は収集情報を記憶するために、サーバ１０内に設けられたデータベースである。１６，１７はデータベース１５に蓄積されたデータを利用するオペレータである。
【００２０】
ネットワーク管理システム２０において、２５はエージェントを一意に識別するエージェント番号とエージェントが収集する項目を一意に識別する収集項目番号を対応付けて記憶しているエージェント収集項目対応テーブル、２６は一意に識別できる収集項目の名称、ＩＰネットワーク装置（ＮＥ）側情報の参照点・データ型・収集周期・開始時刻・運用状態等を定義している収集項目テーブルである。
【００２１】
ここで、エージェント収集項目対応テーブル２５と収集項目テーブル２６は、任意のサーバ１０の中に設けてもよいし、新たなサーバを追加して、その中に設置してもよい。
【００２２】
エージェント収集項目対応テーブル２５と収集項目テーブル２６を設けることにより、エージェントはエージェント番号から収集項目内容を取得することができ、収集項目内容に従って、データ収集を行なうことができる。
（３）請求項３記載の発明は、システムのハード的かつ又はソフト的な監視デバイスから出力されるサーバの処理性能情報を監視して、各サーバの輻輳発生及び輻輳からの復旧を検出する輻輳検出器２２と、各エージェントを一意に識別するエージェント番号と、サーバを一意に識別するサーバ番号を対応付けているエージェント／サーバ対応テーブル２１と、収集項目とエージェントの対応を輻輳状況により再編成するための様式を定義する収集ポリシー定義テーブル２４と、前記輻輳検出器２２の通知により、収集ポリシー定義テーブルから輻輳状況に適合するポリシーを取得し、収集項目とエージェントの対応を再編成する収集項目編成演算器２３と、を更に有することを特徴とする。本発明の実施の形態例を図３に示す。
【００２３】
このように構成すれば、ポリシーに基づき、収集項目数、収集周期、データ処理能力から各エージェントの収集対象範囲を動的に変更することができるので、輻輳が発生した場合でも確実にＮＥからデータ収集が既定の時刻及び周期で行なえるようなマネージャ−エージェント型情報収集アプリケーションを提供することができる。
【００２４】
本発明によれば、エージェントが配置されているサーバが輻輳状態に陥った場合でも、そのエージェントに割り当てられている収集項目をポリシーに基づき、他のサーバのエージェントに割り当てることで、各収集項目の既定の収集時刻及び収集周期を維持できるため、システムが輻輳状況においても収集周期の遅延やデータ欠落、輻輳復旧後の収集時刻のずれを防止することが可能となる。
【００２５】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態例を詳細に説明する。
【００２６】
先ず、図３に示す構成について更に説明する。図に示すシステムは、複数のＩＰネットワーク装置（ＮＥ）１を管理するネットワーク管理機能を提供する複数の処理（ネットワーク管理機能処理）を収容する複数のハードウェア（サーバ）１０で構成されるネットワーク管理システムを構成している。
【００２７】
このネットワーク管理システムには、データ収集機能として任意のサーバ１０にエージェント１１，１２を配置し、各エージェント１１，１２はＮＥ１に対して既定の収集項目を既定の時刻及び周期でデータ収集している。この時、エージェント１１，１２は自分が収集すべき収集項目をエージェント収集項目対応テーブル２５から自分のエージェント番号に対応する収集項目番号を参照することで取得する。
【００２８】
図４はエージェント収集項目対応テーブル２５の構成例を示す図である。エージェント収集項目対応テーブル２５は、エージェントを一意に識別するエージェント番号に対して、収集項目を一意に識別する収集項目番号の一覧により構成されているテーブルである。図に示すように、エージェント番号とそのエージェント番号に対応する収集項目番号の一覧より構成されていることが分かる。
【００２９】
また、各収集項目のＮＥ１側の参照点、データ型、及び収集の周期は、収集項目テーブル２６から収集項目番号に対応する収集項目内容を参照することで取得する。ここで、収集項目テーブル２６は、収集項目を一意に識別する収集項目番号に対して、収集項目の名称、ＮＥ側参照点（ＮＥのＩＰアドレス及びＭＩＢ−ＯＩＤ等のＮＥ側データの所在を示す情報）、データ型、収集開始時刻、収集周期、運用状態（運用中、休止等）を１つの単位として保持するテーブルである。図５は収集項目テーブル２６の構成例を示す図である。図に示すように、収集項目番号に対応する収集項目内容があり、収集項目内容は、名前、ＮＥ側参照点、データ型、開始時刻、周期、運用状態等から構成されている。
【００３０】
このように構成すれば、エージェント収集項目対応テーブル２５と収集項目テーブル２６を設けることにより、エージェント番号から収集項目内容を取得することができ、収集項目内容に従って、データ収集を行なうことができる。
【００３１】
本発明は、図３に示す通り更に任意のサーバ１０上に、システムのハード的かつ又はソフト的な監視デバイスから出力されるサーバの処理性能情報を監視して、各サーバの輻輳発生及び輻輳からの復旧を検出する輻輳検出器２２と、各エージェントを一意に識別するエージェント番号とサーバを一意に識別するサーバ番号を対応付けているエージェント／サーバ対応テーブル２１、収集項目とエージェントの対応を輻輳状況により再編成するための様式を定義する収集ポリシー定義テーブル２４、輻輳検出器２２の通知により収集ポリシー定義テーブル２４から輻輳状況に適合するポリシーを取得し、収集項目とエージェントの対応を再編成する収集項目編成演算器２３が設けられている。
【００３２】
図６はエージェント／サーバ対応テーブル２１の構成例を示す図である。図に示すように、サーバ番号とサーバ番号に対応するエージェント番号とにより構成されている。
【００３３】
図７は本発明装置の動作を示すフローチャートで、輻輳検出器２２と、収集項目編成演算器２３の動作を示している。フローの各処理は以下の通りである。
（Ｓ１）輻輳検出
輻輳検出器２２はサーバ１０の性能情報を監視する監視デバイス２７の出力を定期的かつ又は割り込みで受信する。
（Ｓ２）輻輳判定
輻輳検出器２２は、監視デバイス２７の出力からサーバの輻輳度を算出して輻輳の有無を判定する。この時、輻輳度は、各監視デバイス２７の出力値に対して１つ又は複数の段階的なしきい値を設け、これらしきい値を超える毎に輻輳度を強化していき、逆にしきい値を下回った場合には輻輳度を弱めていくことで算出してもよい。又は、各監視デバイス２７の出力値ｘに対して任意の数式ｆ（ｘ）を割り当て、監視デバイス２７の出力値ｘをｆ（ｘ）に適用した結果の値を輻輳度としてもよい。
（Ｓ１０）輻輳状況の検出
ステップＳ２で判定した輻輳度に基づいて輻輳状況を判断する。定常時又は輻輳度が変わらない場合又は輻輳度が下降している場合にはステップＳ１に戻る。輻輳を検出した場合又は輻輳度が上昇した場合には、以下のシーケンスに進む。
（Ｓ３）輻輳対象取得
輻輳検出器２２は、輻輳しているサーバ番号を元に、エージェント／サーバ対応テーブル２１から輻輳しているサーバ１０に配置されているエージェント番号を取得する。更に、収集項目編成演算器２３に対して、輻輳度とエージェント番号を含む輻輳通知を行なう。ここまでは、輻輳検出器２２の動作である。
（Ｓ４）収集項目取得
収集項目編成演算器２３は、輻輳検出器２２から通知されたエージェント番号を元にエージェント収集項目対応テーブル２５を参照し、該当する輻輳しているサーバのエージェントに割り当てられている収集項目番号を取得する。
（Ｓ５）ポリシー取得・演算
収集項目編成演算器２３は、輻輳度と収集項目番号の数として自明である収集項目数を元に収集ポリシー定義テーブル２４を参照し、適合するポリシーを取得する。図８は収集ポリシー定義テーブルの構成例を示す図である。図に示すように、ポリシー条件とこれに対応する処理方式とで構成されている。処理方式は、割り当て方式と付帯属性から構成されている。
【００３４】
ポリシー条件とは、処理を決定するために必要となる情報である。以下にポリシー条件を列挙する。
ａ）輻輳度、且つ又は輻輳の進行度合い（急激であるか、ゆるやかであるか）
ｂ）収集項目数、且つ又は長・中・短期間等の段階付けられた収集周期に対するそれぞれの収集項目数（短周期の収集項目が多い、長周期の収集項目が多い等）
ｃ）優先度：複数のポリシー条件に適合する場合の採用優先度等が考えられる。処理方式及び付帯属性とは、各エージェントに割り当てる収集項目の配分方式及び配分するために必要なパラメータである。例えば、
ｄ）１つの既定のエージェントに全ての収集項目を配分する方式。この時、１つのエージェントは自分のエージェント番号を付帯属性とすることができる。
ｅ）既定の複数のエージェントに対してある配分方式により収集項目を配分する方式。この時、複数のエージェントはエージェント番号を付帯属性として指定することができ、配分方式も付帯属性とすることができる。
ｆ）１つの任意のエージェントに全ての収集項目を配分する方式。この時、任意のエージェントを選択する条件としては、例えば
▲１▼各エージェントに割り当て可能な収集項目数Ｔｎと、そのエージェントに現在割り当てられている収集項目数Ｃｎの差を許容可能な追加割り当て項目数Ａｎとして、輻輳エージェントに割り当てられている収集項目数Ｃｃａと以下の関係を満たすエージェントを算出する。
【００３５】
Ｔｎ＝Ｃｎ＋Ａｎ          （１）
Ａｎ＞Ｃｃａ            （２）
▲２▼各エージェントに割り当て可能な収集作業量Ｔｗと、そのエージェントに現在割り当てられている収集項目数Ｃｎ及びある収集項目Ｃｉとその周期Ｔｃｉの演算の和から、許容できる追加割り当て収集作業量Ａｗを算出し、輻輳エージェントに割り当てられている収集作業量Ｃａｗと以下の関係を満たすエージェントを算出する。
【００３６】
【数１】
2004274289.tif 000003
【００３７】
ここで、ｆ（Ｃｉ，Ｔｃｉ）は任意の演算式である。
【００３８】
Ａｗ＞Ｃａｗ                      （４）
これらの演算式は付帯属性とすることができる。
ｇ）任意の複数のエージェントに対してある配分式により収集項目を配分する方式。この時、任意の複数のエージェントを選択する条件としては、例えばｆ）の（２）式や（４）式を満たすｎ個のエージェントに対してＣｃａ／ｎや、Ｃａｗ／ｎをそれぞれ均等配分する方式が考えられるし、任意の配分式を用いることも可能である。
ｈ）上記ａ）〜ｇ）配分方式が満足されない場合（他エージェントに配分しても未割り当ての収集項目が残ってしまう場合）でも、未割り当てとする収集項目の処理方式を付帯属性とすることも可能である。未割り当ての収集項目の処理方式としては、例えば、
▲１▼最も単純な方式として、収集時刻が遅い収集項目は、未割り当て収集項目として輻輳しているサーバのエージェントが引き続き収集を行なうようにすることが考えられる。
▲２▼収集周期が長い収集項目は、未割り当て収集項目として輻輳しているサーバのエージェントが引き続き収集を行なうようにすることが考えられる。
▲３▼収集周期が長く、次回の収集時刻が遅い収集項目を未割り当て収集項目とする。未割り当ての収集項目は、輻輳しているサーバのエージェントが引き続き収集を行なうようにすることが考えられる（▲１▼と▲２▼の組み合わせである）。
▲４▼収集項目に優先度（重要度）属性を付加して、優先度の低い収集項目は未割り当て収集項目として輻輳エージェントが引き続き収集を行なうようにすることが考えられる。
▲５▼上記▲１▼と▲４▼、▲２▼と▲４▼、▲３▼と▲４▼の組み合わせ等が考えられる。
（Ｓ６）再編成（新しいエージェント収集項目対応テーブル作成）
ポリシーを輻輳しているサーバのエージェントに割り当てられている収集項目に適用した結果、輻輳・非輻輳サーバの各エージェントに対する新しい収集項目の割り当てを元に、エージェント収集項目対応テーブル２５を更新する。なお、ポリシーが収集項目内容も対象とする場合には、収集項目テーブル２６の内容も取得する。
【００３９】
輻輳復旧後の処理は、復旧しても収集項目のエージェントの割り当てを変更しなくてもよいし、輻輳前の割り当てに切り戻すこともできる。これらもポリシーに定義するか、システムで暗黙的にいずれかを指定しておくことが可能である。
【００４０】
輻輳前の割り当てに切り戻す場合の動作フローを図６のＳ１１以下に示す。切り戻しのために、エージェント収集項目対応テーブル２５には、収集項目番号に対して輻輳時の割り当て元だったエージェントのエージェント番号（元エージェント番号と呼ぶ）を追加する。図９は追加したエージェント収集項目対応テーブル２５の構成例を示す図である。図４に示すエージェント収集項目対応テーブル２５の構成と比較して、元エージェント番号が記載されている点が異なる。この元エージェント番号を元に、切り戻すことができる。
（Ｓ１１）対応表復元
収集項目編成演算器２３は、エージェント収集項目対応テーブル２５を参照しし、元エージェント番号が関連付けられている収集項目番号を取得する。
（Ｓ１２）再編成
収集項目編成演算器２３は、取り出した収集項目を輻輳が復旧したサーバのエージェントに割り当てるよう、エージェント収集項目対応テーブル２５の割り当て先エージェントのテーブルから収集項目を削除し、該当エージェント番号に対応付けられているテーブルに収集項目を追加する。
【００４１】
次に、実施例について説明する。本実施例では、図３に示すような構成をとり、収集ポリシー定義テーブル２４には、図１０に示すポリシーが定義されているものとする。図１０には、ポリシー条件に対する各処理方式が具体的に示されている。各機能は、以下の状態及び情報を保持しているものとする。
・輻輳検出器２２
輻輳検出には、ＣＰＵ使用率を検出する監視デバイス２７の出力を取得して、輻輳判定にはＣＰＵ使用率を使用し、この値が４０％を超えた場合には輻輳と判定するものとする。従って、ここでは輻輳度はＣＰＵ使用率とする。
・エージェントは１１，１２とし、ネットワーク管理システム内に２つのエージェントが配置されており、各エージェント番号は１，２とする。また、エージェント１１にはｍ個の収集項目、エージェント１２にはｎ個の収集項目が割り当てられているとする。
・エージェント／サーバ対応テーブル２１には、以下の２つのレコードを保持している。
【００４２】
サーバＡ：エージェント１
サーバＢ：エージェント２
以上のような状態において、エージェント１１が配置されているサーバＡで輻輳が発生し、ＣＰＵ監視デバイス２７の出力は、ＣＰＵ使用率が７０％である場合について考える。
【００４３】
輻輳検出器２２は、ＣＰＵ監視デバイス２７の出方から、ＣＰＵ使用率が７０％となっていることを検出する。輻輳判定では、ＣＰＵ使用率が４０％を超えているため、輻輳検出器２２は、サーバＡが輻輳状態であると判断する。輻輳検出器２２は、エージェント／サーバ対応テーブル２１に対してサーバＡをキーとしてエージェント番号１を取得する。
【００４４】
これにより、サーバＡにエージェント番号１のエージェントが配置されていることが判明したので、輻輳検出器２２は、収集項目編成演算器２３に輻輳度７０％とエージェント番号１を付属した輻輳発生を通知する。
【００４５】
収集項目編成演算器２３は、輻輳度７０％と輻輳エージェント番号１を受信したので、輻輳エージェント番号１をキーに、エージェント収集項目対応テーブル２５から収集項目番号一覧を取得する。その収集項目数はｍである。
【００４６】
次に、収集ポリシー定義テーブル２４から輻輳度７０％の条件を満たすポリシーを取得する。この場合、輻輳度７０％はポリシー条件を満たすので、以下の処理方式を取得することになる。
【００４７】
割り当て方式：任意の１つのエージェントに一括割り当て
付帯属性：Ｔｎ＝Ｃｎ＋Ａｎ，ＡＮ＞Ｃｃａを満たすエージェントに割り当てる。
【００４８】
付帯属性：未割り当ての収集項目の処理方式は、長周期項目を優先的に残す。
【００４９】
付帯属性１の式により輻輳していないエージェント１２に適用するが、この時仮にエージェント１２のＡｎがＡｎ＞Ｃｃａを満たしている場合には、エージェント１１の収集項目数ｍの全てをエージェント１２に割り当てることになる。エージェント１２の収集項目割り当て後の収集項目数をｎ’とするとｎ’＝ｍ＋ｎとなる。もし、Ａｎ＞Ｃｃａを満たしていない場合には、付帯属性２により、エージェント１２のＣｎがＴｎ＝Ｃｎとなるまで、収集項目ｍ中の短周期の収集項目を割り当て、余った収集周期の長い収集項目はエージェント１１にそのまま割り当てる。
【００５０】
以上による割り当てにより、エージェント収集項目対応テーブル２５を更新することで処理が終了する。
【００５１】
このように、本発明によれば、ポリシーに基づき、収集項目数、収集周期、データ処理能力から各エージェントの収集対象範囲を動的に変更することができるので、輻輳が発生した場合でも確実にＮＥのデータ収集が既定の時刻及び周期で行なえるようなマネージャ−エージェント型情報収集アプリケーションを提供することができる。
【００５２】
【発明の効果】
以上説明したように、本発明によれば、以下の効果が得られる。
（１）請求項１記載の発明によれば、ポリシーに基づき、収集項目数，収集周期，データ処理能力から各エージェントの収集対象範囲を動的に変更させるようにしたので、輻輳が発生した場合でも確実にＮＥのデータ収集を行なうことができる。
（２）請求項２記載の発明によれば、エージェント収集項目対応テーブル２５と収集項目テーブル２６を設けることにより、エージェント番号から収集項目内容を取得することができ、収集項目内容に従って、データ収集を行なうことができる。
（３）請求項３記載の発明によれば、ポリシーに基づき、収集項目数、収集周期、データ処理能力から各エージェントの収集対象範囲を動的に変更することができるので、輻輳が発生した場合でも確実にＮＥのデータ収集が既定の時刻及び周期で行なえるようなマネージャ−エージェント型情報収集アプリケーションを提供することができる。
【００５３】
このように、本発明によれば、輻輳が発生した場合でも確実にＮＥのデータ収集が既定の時刻及び周期で行なえるようなマネージャ−エージェント型情報収集アプリケーションのロードバランス方法及び装置を提供することができる。
【図面の簡単な説明】
【図１】本発明方法の原理を示すフローチャートである。
【図２】本発明の原理ブロック図である。
【図３】本発明の実施の形態例を示すブロック図である。
【図４】エージェント収集項目対応テーブルの構成例を示す図である。
【図５】収集項目テーブルの構成例を示す図である。
【図６】エージェント／サーバ対応テーブルの構成例を示す図である。
【図７】本発明装置の動作を示すフローチャートである。
【図８】収集ポリシー定義テーブルの構成例を示す図である。
【図９】追加したエージェント収集項目対応テーブルの構成例を示す図である。
【図１０】収集ポリシー定義テーブルの具体的な構成例を示す図である。
【図１１】本発明の利用分野の説明図である。
【図１２】多量の故障情報を一度に受信した場合の動作説明図である。
【図１３】正常な場合と輻輳時におけるデータ収集のタイミングを示す図である。
【符号の説明】
１  ＩＰネットワーク装置（ＮＥ）
２〜４  ＩＰネットワーク
１０  サーバ
１１，１２  収集エージェント
１３  故障管理機能部
１４  ネットワーク制御機能部
１５  データベース
１６，１７  オペレータ
２０  ネットワーク管理システム
２１  エージェント／サーバ対応テーブル
２２  輻輳検出器
２３  収集項目編成演算器
２４  収集ポリシー定義テーブル
２５  エージェント収集項目対応テーブル
２６  収集項目テーブル
【図１】
2004274289.tif 000004
【図２】
2004274289.tif 000005
【図３】
2004274289.tif 000006
【図４】
2004274289.tif 000007
【図５】
2004274289.tif 000008
【図６】
2004274289.tif 000009
【図７】
2004274289.tif 000010
【図８】
2004274289.tif 000011
【図９】
2004274289.tif 000012
【図１０】
2004274289.tif 000013
【図１１】
2004274289.tif 000014
【図１２】
2004274289.tif 000015
【図１３】
2004274289.tif 000016