以下、本発明によるリソース管理システム、リソース管理サーバ、ネットワーク装置、リソース管理方法およびリソース管理プログラムの好適な実施形態について添付図を参照して説明する。なお、以下の説明においては、本発明によるリソース管理システム、リソース管理サーバ、ネットワーク装置およびリソース管理方法について説明するが、かかるリソース管理方法をコンピュータにより実行可能なリソース管理プログラムとして実施するようにしても良いし、あるいは、リソース管理プログラムをコンピュータにより読み取り可能な記録媒体に記録するようにしても良いことは言うまでもない。
(本発明の特徴)
本発明の実施形態の説明に先立って、本発明の特徴についてその概要をまず説明する。本発明は、ネットワーク全体のリソースの管理を行うリソース管理サーバにおいて、管理対象のネットワーク装置がリソース不足になった場合に、リソース管理サーバのリソース管理Manager(リソース管理マネジャ)が実施すべきアクション(処理実施内容)を、管理対象の各ネットワーク装置のリソース管理Agent(リソース管理エージェント)それぞれからリソース管理Manager(リソース管理マネジャ)へあらかじめ事前登録しておくことにより、リソース管理サーバ側から、管理対象のネットワーク装置の運用状況を考慮した適切なリソース割当とアクションの実施とを可能にしていることを主要な特徴としている。
つまり、本発明は、管理対象のネットワーク装置がリソース不足に陥った時に、当該ネットワーク装置側が希望するアクション(処理実施内容)をリソース管理サーバのリソース管理Manager(リソース管理マネジャ)に事前登録しておくことにより、実際にリソース不足が発生した際に、当該リソース不足を解消させるための最適なアクション(処理実施内容)を速やかに、滞りなく実施することができ、リソースの最適割当を迅速に行うことができるようになっている。
また、本発明は、他のネットワーク装置のリソース使用状況、つまり、管理ネットワーク全体のリソース使用状況をも考慮して、リソース管理サーバのリソース管理Manager(リソース管理マネジャ)が実施すべきアクション(処理実施内容)を判断することができるように、ネットワーク全体の各ネットワーク装置からの希望アクション(希望実施内容)を、各ネットワーク装置のリソース状態とともにプロファイルとしてあらかじめ設定し、リソース不足に陥ったネットワーク装置側が事前登録したアクション(処理内容)を実施することが適切か否かを判断することができる処理シーケンスを採用している。
さらに、本発明は、リソース管理サーバのリソース管理Manager(リソース管理マネジャ)に対してアクセスしてきたネットワーク装置が管理対象のネットワーク装置として適切であるか否かを認証する仕組みを採用しており、不正なネットワーク装置によってリソース管理への悪影響を防止するようにしている。例えば、不正なネットワーク装置が、リソース管理サーバが管理対象としている他のいずれかのネットワーク装置をシャットダウンさせるようなコマンドの実行を事前登録しておいて、リソース不足を示すアラーム発生通知をリソース管理サーバのリソース管理Manager(リソース管理マネジャ)に送信してくるようなことがあると、事前登録されているアクション(他のいずれかのネットワーク装置をシャットダウンさせる処理内容)が実施されてしまって、ネットワークのリソース管理を適切に実施することができなくなるので、リソース不足時のアクションを事前登録するネットワーク装置が管理対象のネットワーク装置として適切であるか否かを認証するようにしている。
(本発明の実施形態)
次に、本発明の実施形態について図を参照しながら詳細に説明する。本発明の実施形態は、図1に示すように、ネットワーク全体のリソースを管理するリソース管理サーバと、リソースの管理対象となる呼処理装置や無線制御装置やルータやハブ等のネットワーク装置と、リソース管理サーバと各ネットワーク装置との間を接続する管理ネットワークと、からなるリソース管理システムに関するものであり、前述したように、管理対象のネットワーク装置がリソース不足になった場合に、ネットワーク全体の運用状況を考慮して、リソース管理サーバ側から適切なリソース割当とアクションの実施とを可能にしている。図1は、本発明によるリソース管理システムのシステム構成の一例を示すシステム構成図である。
図1に示すリソース管理システムは、ネットワーク全体のリソースを管理するリソース管理サーバ1100、リソースの管理対象となる1ないし複数のネットワーク装置に相当する装置A1 1010,…,装置An 10n0、および、SNMP(Simple Network Management Protocol)プロトコルを用いた管理ネットワークであるネットワーク1200によって構成されている。
図1において、装置A1 1010ないし装置An 10n0は、それぞれ、リソース管理サーバ1100に対して、ネットワーク1200を介して、あらかじめ定めた周期やリソースの使用状況に変化が発生する都度、自装置のリソース状況を通知している。リソース管理サーバ1100は、装置A1 1010ないし装置An 10n0それぞれのリソース使用状況を、ネットワーク1200を介して受信して、ネットワーク1200全体のリソースの使用状況をプロファイルとして保持して管理している。
次に、図1のリソース管理システムにおける装置A1 1010ないし装置An 10n0およびリソース管理サーバ1100のリソース管理に関する部位について、その一例を、図2を用いて説明する。図2は、図1のリソース管理システムにおけるリソース管理サーバ1100および各ネットワーク装置すなわち装置A1 1010,…,装置An 10n0の装置構成の一例を説明するための説明図であり、装置A1 1010ないし装置An 10n0とリソース管理サーバ1100とにおける各リソース管理用の機能部と、装置A1 1010ないし装置An 10n0とリソース管理サーバ1100との間のインタフェースについて示している。
なお、図2には、図1のリソース管理サーバ1100、装置A1 1010,…,装置An 10n0を、それぞれ、リソース管理サーバ2100、装置A1 2010,…,装置An 20n0と、千番台の符号を図番号に対応する形で変更して示している。また、以下の各図面においても、同様に、符号を図番号に対応する形で変更している。
図2において、装置A1 2010のリソース管理Agent(リソース管理エージェント)2011ないし装置An 20n0のリソース管理Agent(リソース管理エージェント)20n1は、それぞれ、自装置のリソース状況を保持している。また、装置A1 2010のリソース管理Agent(リソース管理エージェント)2011ないし装置An 20n0のリソース管理Agent(リソース管理エージェント)20n1は、それぞれ、自装置において使用することが可能なリソース量を判別するためのリソース閾値をあらかじめ設定している。
装置A2 2010のリソース管理Agent(リソース管理エージェント)2011ないし装置An 20n0のリソース管理Agent(リソース管理エージェント)20n1は、それぞれに設定した該リソース閾値に基づいて、リソース不足を検知した際に、それぞれ、インタフェースR11ないしインタフェースRn1を経由して、図1に示したネットワーク1200を介して、リソース管理サーバ2100のリソース管理Manager(リソース管理マネジャ)2101に対してアラーム発生通知を行い、あらかじめ事前登録しておいた希望アクション(希望実施内容)の実施を要求する。
リソース管理サーバ2100のリソース管理Manager(リソース管理マネジャ)2101は、装置A1 2010のリソース管理Agent(リソース管理エージェント)2011ないし装置An 20n0のリソース管理Agent(リソース管理エージェント)20n1からアラーム発生通知を受け取ると、アラーム発生通知に応じた処理(リソースの再割当処理等)を実施して、実施結果を示す応答(アラーム発生応答)を、アラーム発生通知元の装置A1 2010のリソース管理Agent(リソース管理エージェント)2011ないし装置An 20n0のリソース管理Agent(リソース管理エージェント)20n1に対して、それぞれ、インタフェースR12ないしインタフェースRn2を経由して、図1に示したネットワーク1200を介して返送する。
装置A1 2010のリソース管理Agent(リソース管理エージェント)2011ないし装置An 20n0のリソース管理Agent(リソース管理エージェント)20n1は、リソース管理サーバ2100のリソース管理Manager(リソース管理マネジャ)2101からの応答(アラーム発生応答)を受け取ると、該応答を正常に受信した旨を示す応答ACKを生成して、それぞれ、インタフェースACK1ないしインタフェースACKnを経由して、図1に示したネットワーク1200を介して、リソース管理サーバ 2100のリソース管理Manager(リソース管理マネジャ)2101に対して返送する。
次に、図1のリソース管理システムにおけるリソース管理サーバ1100のリソース管理に関する部位と管理対象のネットワーク装置である装置A1 1010ないし装置An 10n0との間のさらに詳細なインタフェースについて、その一例を、図3を用いて説明する。図3は、図1のリソース管理システムにおけるリソース管理サーバ1100と各ネットワーク装置すなわち装置A1 1010,…,装置An 10n0との間のリソース管理に関するインタフェースの一例を説明するための説明図であり、装置A1 1010ないし装置An 10n0のうち、第m番目と第n番目の装置を取り出して、リソース管理サーバ1100のリソース管理用の機能部と、管理対象のネットワーク装置である装置Am 10m0、装置An 10n0との間のリソース管理に関する全インタフェースについて示している。
なお、図3においても、前述したように、図1のリソース管理サーバ1100、装置Am 10m0、装置An 10n0を、それぞれ、リソース管理サーバ3100、装置Am 30m0、装置An 30n0と、千番台の符号を図番号に対応する形で変更して示している。また、図2のリソース管理サーバ2100のリソース管理Manager(リソース管理マネジャ)2101についても、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101と、千番台の符号を図番号に対応する形で変更している。
さらに、図2の装置A1 2010のリソース管理Agent(リソース管理エージェント)2011、装置An 20n0のリソース管理Agent(リソース管理エージェント)20n1についても、それぞれ、装置Am 30m0のリソース管理Agent(リソース管理エージェント)30m1、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1と、千番台の符号を図番号に対応する形で変更して示している。
図3においても、図2の場合と同様、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101は、装置Am 30m0のリソース管理Agent(リソース管理エージェント)30m1、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1からアラーム発生通知を受け取ると、アラーム発生通知に応じた処理(リソースの割当処理)を実施して、実施結果を示す応答(アラーム発生応答)を、アラーム発生通知元の装置Am 30m0のリソース管理Agent(リソース管理エージェント)30m1、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1に対して送信している。
また、装置Am 30m0のリソース管理Agent(リソース管理エージェント)30m1、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1は、図2の場合と同様、それぞれ、自装置のリソース状況を保持している。さらに、装置Am 30m0のリソース管理Agent(リソース管理エージェント)30m1、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1は、それぞれ、自装置において使用することが可能なリソース量を判別するためのリソース閾値をあらかじめ設定し、該リソース閾値に基づいて、リソース不足を検知した際に、それぞれ、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101に対してアラーム発生通知の送信を行っている。
図3に示すように、リソース管理サーバ3100は、リソース管理Manager(リソース管理マネジャ)3101に、管理対象の各ネットワーク装置である装置Am 30m0、装置An 30n0ごとに、それぞれのリソース管理に関する情報(希望アクション(希望する処理実施内容)、処理開始時刻、処理実施履歴、リソース状況等)を登録保持しているデータベースとしてプロファイル3104を所持している他、アクセスしてくる各ネットワーク装置例えば装置Am 30m0、装置An 30n0の認証を行う認証管理3102、リソース管理に関するアプリ処理を実行するアプリケーションX 3103の各機能部を有している。また、装置Am 30m0、装置An 30n0にも、それぞれ、リソース管理に関するアプリ処理を実行するアプリケーションAm 30m2、アプリケーションAn 30n2、の機能部を有している。
図3に示す各機能部および各機能部間のインタフェースに関する説明を、次の表1に示している。
装置An 30n0、装置Am 30m0は、いずれも、前述したように、リソース管理サーバ3100のリソース管理対象となるネットワーク装置であり、図3においては、装置An 30n0にリソース不足が発生して、装置An 30n0からリソース管理サーバ3100に対してアラーム発生通知を送信した場合に、ネットワーク全体のリソース配分を最適化するために、リソース管理サーバ3100のアプリケーションX 3103が、アラーム発生通知元とは異なる他のネットワーク装置の装置Am 30m0に対してアクションを指示する場合がある例も説明することとする。
表1に示すように、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1、装置Am 30m0のリソース管理Agent(リソース管理エージェント)30m1は、いずれも、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101との間のネゴシエーションを行い、自装置内のリソースを管理するアプリケーションであり、使用するリソースが使用可能な限界値としてあらかじめ設定されたリソース閾値を超えた場合に、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101に対して、事前に登録された希望アクション(希望実施内容)を実施することを要求するアラーム発生通知を送信する。
装置An 30n0のアプリケーションAn 30n2は、使用するリソースがリソース閾値を超えた場合にリソース管理Agent(リソース管理エージェント)30n1にてアラーム発生通知をリソース管理サーバ3100に送信した結果として、リソース管理サーバ3100のアプリケーションX 3103からの要求に基づいて実施されるリソース管理関連のアプリケーションであり、装置An 30n0に常駐しており、アプリケーションX 3103からの要求に応じて、いつでも実行することが可能である。
これに対して、装置Am 30m0のアプリケーションAm 30m2は、リソース管理サーバ3100のアプリケーションX 3103からのアラーム処理要求があった場合に、該アラーム処理要求に該当する処理内容を実行して、処理結果をアラーム処理要求元のリソース管理サーバ3100のアプリケーションX 3103に対して返送するリソース管理関連のアプリケーションであり、装置Am 30m0に常駐しており、アプリケーションX 3103からのアラーム処理要求に応じて、いつでも実行することが可能である。
リソース管理サーバ3100は、図3においては、リソースの管理対象のネットワーク装置である装置An 30n0のリソース使用状況を監視する監視サーバであり、装置An 30n0のリソースがリソース閾値を超えた場合に装置An 30n0から送信されてくるアラーム発生通知に応じて、当該リソース管理サーバ3100にあらかじめ設定登録されている希望アクション(希望実施内容)を実施するようにアプリケーションX 3103に対して指示する。
また、アラーム発生通知を送信してきた装置An 30n0がリソース管理対象のネットワーク装置であるか否かを認証する動作を実施して、リソース管理サーバ3100への不適当なネットワーク装置からの不正接続を防止する機能も有している。つまり、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101は、リソースの管理対象のネットワーク装置である装置An 30n0の装置起動時に送信されてくる希望アクション(希望実施内容)の事前登録要求を受け取った際に、要求元の装置An 30n0の認証を行うために、認証管理3102に対して認証要求を行う。また、リソース管理Manager(リソース管理マネジャ)3101は、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1がリソース閾値を超えたことを検知した際に送信してくるアラーム発生通知を受け取った際に、事前に設定登録された希望アクション(希望実施内容)に基づいて適切な判断を行い、必要に応じてアプリケーションX 3103に対してアラーム処理要求を出力する。
なお、リソース管理Manager(リソース管理マネジャ)3101は、リソースの管理対象のネットワーク装置であるすべての装置(図3の場合、装置An 30n0、装置Am 30m0の2つのネットワーク装置を示している)のリソース管理Agent(リソース管理エージェント)30i1(i=1,2,…,m,…n)に関するプロファイル3104を備えており、必要に応じて、プロファイル3104に保持されている各ネットワーク装置のデータを参照することが可能である。
ここで、プロファイル3104は、管理対象の各ネットワーク装置の希望アクション(希望実施内容:リソース不足発生時にリソース管理サーバ3100側で実施して欲しい処理内容)を、各ネットワーク装置のリソース状態とともに事前登録しているものであり、リソース管理Agent(リソース管理エージェント)30i1(i=1,2,…,m,…n)を有するすべてのネットワーク装置(図3の場合、装置An 30n0、装置Am 30m0の2つのネットワーク装置)それぞれが希望する処理実施内容や実施開始時刻等に関する希望アクション情報をリソース状態とともに設定しているデータベースである。リソース管理Manager(リソース管理マネジャ)3101は、必要に応じて、プロファイル3104のデータ(例えばアラーム発生通知の送信元の装置An 30n0のデータ)を参照して、希望するアクション(処理実施内容)を決定して実施する。
リソース管理サーバ3100の認証管理3102は、リソース管理Manager(リソース管理マネジャ)3101からの要求があった装置An 30n0が、管理対象のネットワーク装置として管理すべきネットワーク装置であるか否かを認証する処理を実施する。
リソース管理サーバ3100のアプリケーションX 3103は、リソース管理Manager(リソース管理マネジャ)3101からアラーム処理要求を受け取った場合、つまり、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1からアラーム発生通知を受け取ったリソース管理Manager(リソース管理マネジャ)3101がアプリケーションX 3103による処理が必要であると判断した場合、アラーム発生通知の送信元の装置An 30n0のアプリケーションAn 30n2、または、該送信元とは異なる他のネットワーク装置例えば装置Am 30m0のアプリケーションAm 30m2に対して、事前に設定登録されているアクション(処理内容)の実行を要求するアラーム処理要求を送信する。
ここで、アプリケーションX 3103は、特定のアプリケーションを意味しているものではなく、アラーム発生通知の内容とプロファイル3104に設定されているデータとを参照した結果による判断結果に基づいてリソース管理Manager(リソース管理マネジャ)3101によって選択されて指示されたアプリケーションのことである。
また、インタフェースRnj(j=1,2,7,8,9,10,11,12)、ACKn、ACKmは、異なる装置間で通信するためのインタフェースであり、インタフェースRn3,4,5,6は、リソース管理サーバ3100内の機能部間で通信するためのAPI(Application Program Interface)である。
より詳細には、インタフェースRn1は、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1がリソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101に対してアラーム発生通知を送信するためのインタフェースであり、インタフェースRn2は、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101からアラーム発生通知の送信元の装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1に対してアクションの実施結果を示す処理応答(アラーム発生応答)を送信するためのインタフェースである。
また、インタフェースRn3は、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101から認証管理3102に対して認証要求を送信するためのAPIであり、インタフェースRn4は、リソース管理サーバ3100の認証管理3102からリソース管理Manager(リソース管理マネジャ)3101に対して認証結果を送信するためのAPIである。
また、インタフェースRn5は、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101からアプリケーションX 3103に対して指定したアプリ実行要求を送信するためのAPIであり、インタフェースRn6は、リソース管理サーバ3100のアプリケーションX 3103からリソース管理Manager(リソース管理マネジャ)3101に対してアプリ実行結果を送信するためのAPIである。
また、インタフェースRn7は、リソース管理サーバ3100のアプリケーションX 3103からアラーム発生通知の送信元の装置An 30n0のアプリケーションAn 30n2に対してアラーム処理要求を送信するためのインタフェースであり、インタフェースRn8は、アラーム処理要求の送信先の装置An 30n0のアプリケーションAn 30n2からリソース管理サーバ3100のアプリケーションX 3103に対して処理結果を示す応答を送信するためのインタフェースである。
また、インタフェースRn9は、リソース管理サーバ3100のアプリケーションX 3103からアラーム発生通知の送信元とは異なる装置Am 30m0のアプリケーションAm 30m2に対してアラーム処理要求を送信するためのインタフェースであり、インタフェースRn10は、アラーム処理要求の送信先の装置Am 30m0のアプリケーションAm 30m2からリソース管理サーバ3100のアプリケーションX 3103に対して処理結果を示す応答を送信するためのインタフェースである。
また、インタフェースRn11は、装置Am 30m0のリソース管理Agent(リソース管理エージェント)30m1がリソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101に対してアラーム発生通知を送信するためのインタフェースであり、インタフェースRn12は、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101からアラーム発生通知の送信元の装置Am 30m0のリソース管理Agent(リソース管理エージェント)30m1に対してアクションの実施結果を示す処理応答(アラーム発生応答)を送信するためのインタフェースである。
また、インタフェースACKnは、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1がリソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101に対して処理応答を正常に受け取った旨を示す応答ACKを送信するためのインタフェースであり、インタフェースACKmは、装置Am 30m0のリソース管理Agent(リソース管理エージェント)30m1がリソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101に対して処理応答を正常に受け取った旨を示す応答ACKを送信するためのインタフェースである。
次に、図3のリソース管理システムに示したリソース管理サーバ3100と管理対象のネットワーク装置である装置An 30n0との間の通信シーケンスについて、装置An 30n0から事前に設定登録する希望実施内容すなわち希望アクションの登録および希望実施内容すなわり希望アクションの削除を行う際のシーケンスの一例を、図4を用いて説明する。
図4は、図3のリソース管理システムにおける希望アクション(希望実施内容)の事前登録シーケンスおよび希望アクション(希望実施内容)の削除シーケンスの一例を示すシーケンスチャートであり、管理対象のネットワーク装置の装置A1 3010ないし装置An 30n0のうち、いずれかのネットワーク装置例えば第n番目の装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1からのリソース管理サーバ3100に対する事前登録要求があった際に、希望アクション(希望実施内容)を事前に設定登録し、かつ、事前登録削除要求に応じて、設定登録していた希望アクション(希望実施内容)を削除する場合のシーケンスについて示している。
装置An 30n0は、収容する端末数の変化やネットワークのリソース変動等に伴って、使用するリソースがあらかじめ設定したリソース閾値を超えた場合に、リソース管理サーバ3100に対してアラーム発生通知を送信することによって、あらかじめ事前に設定登録している希望アクション(希望実施内容)の実施を要求する。ここで、実施してもらいたい希望アクション(希望実施内容)とは、例えば、装置An 30n0を利用する端末数が増加したために、装置An 30n0の使用可能なリソース量を増加させるようなリソースの再配分を実施してもらうことを要求したり、あるいは、新たな装置Am 30m0に増加した一部または全ての端末を収容させるために、装置Am 30m0の閉塞状態を解除することを要求したりする場合を意味している。以下においては、図4のシーケンスで示す一連の処理を「事前登録・削除処理」と称することにする。
図4のシーケンスチャートにおいて、まず、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1は、装置起動時に、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101に対して、図7に示すフォーマットからなる事前登録・削除要求パケットを送信する(シーケンスS4001)。
図7は、図3のリソース管理システムにおいてネットワーク装置の装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1からリソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101に対して送信される事前登録・削除要求パケットのフォーマットの一例を示すテーブルである。
ここで、図7に示す事前登録・削除要求パケットは、UDP(User Datagram protocol)パケット上のペイロードとして扱われ、リソース閾値を超えた場合にアラーム発生通知をリソース管理サーバ3100に送信することによって、リソース管理サーバ3100側で実施して欲しい希望アクション(希望実施内容)をリソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101に事前登録するために用いられ、また、事前登録されている希望アクション(希望実施内容)に関する情報を削除するために用いられる。
具体的には、図7に示す事前登録・削除要求パケットは、バージョン、ヘッダ長、パケット長、タイプ、要求数、シーケンス番号、承認キー、予約の各情報からなるヘッダ情報に引き続くデータ領域に、実施して欲しい希望アクション(希望実施内容)に関する情報として、希望優先度、指示対象名、実施回数、仮登録番号、開始時刻、希望実施内容を1組の希望アクションとし、必要に応じて、優先度を付して、希望アクション1,…,希望アクションjと複数組纏めて収容することができる。
図7に示す事前登録・削除要求パケットに設定されるそれぞれの情報の意味は、次の表2に示す通りである。なお、表2には、後述する図8の事前登録・削除応答パケット、図9の事前登録・削除応答ACKパケット、図10のアラーム発生通知パケット、図11のアラーム発生応答パケット、図12のアラーム発生応答ACKパケットに設定される情報の意味についても併せて説明しているので、後述する該当の箇所においても、表2をそれぞれ参照されたい。
表2に示すように、図7に示す事前登録・削除要求パケットのヘッダ情報内のバージョンフィールドは、当該パケットフォーマットタイプのバージョンを示す情報であり、送信元のネットワーク装置の装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1と送信先のリソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101との双方で同じ方式のパケットフォーマットを用いて通信を行うために設定している。また、事前登録・削除要求パケットのヘッダ情報内のヘッダ長フィールドは、事前登録・削除要求パケットのヘッダ情報の長さ(バイト数)を示している。図7に示す事前登録・削除要求パケットの場合は12バイトである。
また、事前登録・削除要求パケットのヘッダ情報内のパケット長フィールドは、データ領域に収容している希望アクション1、…、希望アクションjの合計のメッセージサイズを設定し、ヘッダ情報内のタイプフィールドは、当該事前登録・削除要求パケットの種別を示し、事前登録要求であるか事前登録内容の削除要求であるかを設定する。
また、事前登録・削除要求パケットのヘッダ情報内の要求数フィールドは、希望アクション(希望実施内容)の個数(図7に示す例では、j個)を設定し、事前登録・削除要求パケットのヘッダ情報内のシーケンス番号フィールドは、イベントが発生する都度、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1からリソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101へ送信したパケットの送信順を示す番号を設定する。
また、事前登録・削除要求パケットのヘッダ情報内の承認キーフィールドには、事前登録要求時には、'0'が設定され、事前登録した希望アクション(希望実施内容)の削除要求時には、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101において事前登録要求時に要求元の装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1が承認されることによって付与されていた承認キーが設定される。なお、ヘッダ情報内の予約フィールドは、現在使用されていないダミー領域である。
また、事前登録・削除要求パケットのデータ領域内の希望優先度フィールドは、複数の希望アクション(希望実施内容)を事前登録しようとする場合にそれぞれの希望アクションの優先順位を設定する。なお、複数の希望アクションに同一値の優先度が付されていた場合には、ヘッダ情報側に近い希望アクションほど優先して処理が実施されることにする。ただし、該希望優先度については、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101側で、必要に応じて、優先順を変更することが可能である。
また、事前登録・削除要求パケットのデータ領域内において希望アクションごとに設定される指示対象名フィールドは、リソース管理サーバ3100のアプリケーションX 3103から、複数のネットワーク装置すなわち装置A1 3010,…,装置An 30n0のうち、設定したネットワーク装置例えば装置AiのアプリケーションAiに対して、アラーム処理要求を送信して、希望アクション(希望実施内容)を実施してもらうことを示している。また、事前登録・削除要求パケットのデータ領域内において希望アクションごとに設定される実施回数フィールドは、希望アクション(希望実施内容)を実施する回数を設定する。
また、事前登録・削除要求パケットのデータ領域内において希望アクションごとに設定される仮登録番号フィールドは、事前登録要求元の装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1側において、実施を希望する処理実施内容すなわち希望アクション(希望実施内容)を管理するために使用されるユニークな仮の登録番号を設定する。該仮登録番号は、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101において本登録キーが発行完了されて、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101から通知されてくるまでの一時的なキーとして扱われる。
なお、事前登録・削除要求パケットとして、事前登録された希望アクション(希望実施内容)を削除することを要求する場合には、既に、本登録キーが付与された状態にあるので、仮登録番号の代わりに、本登録キーを用いる。また、削除要求の場合には、事前登録・削除要求パケットのデータ領域内において希望アクションごとに設定される実施回数、開始時刻、希望実施内容の各フィールドを省略することも可能である。また、すべての希望アクション(希望実施内容)を削除する場合には、場合によっては、ヘッダ情報のみからなる事前登録・削除要求パケットを用いるようにしても良い。
また、事前登録・削除要求パケットのデータ領域内において希望アクションごとに設定される開始時刻フィールドは、希望アクション(希望実施内容)をいつ実施するかというエポックタイムを指定する時刻情報を設定する。即時に実施することを指定する場合には、開始時刻を例えば'all0'に設定する。
また、事前登録・削除要求パケットのデータ領域内において希望アクションごとに設定される希望実施内容フィールドは、リソース閾値を超えるリソース不足が発生した際に、または、リソース閾値以下に低下してリソース不足から回復した際に、リソース管理サーバ3100側において、さらに、必要に応じて、アプリケーションX 3103を駆動することにより、実施してもらいたい処理内容を設定する。リソース管理サーバ3100やアプリケーションX 3103が指定された処理内容を実施する開始タイミングは、事前登録・削除要求パケットの開始時刻フィールドによって指定されている。なお、希望実施内容フィールドに設定する希望アクション(希望実施内容)の情報量が、一定のデータサイズ例えば4バイトに収まらない場合には、希望実施内容フィールドを任意の長さに拡張することも可能である。
なお、以下の説明においては、ヘッダ情報に含まれるタイプには、事前登録を要求するパケットである旨の表示が設定され、要求数には、前述のように、事前登録を要求する希望アクションの個数が設定されているものとする。
リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101は、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1から事前登録・削除要求パケットを受け取ると、該事前登録・削除要求パケットの送信元の装置An 30n0が、管理対象のネットワーク装置であるか否かを判別するために、認証管理3102に対して認証要求を行う(シーケンスS4002)。かかる動作は、前述したように、装置An 30n0がリソース管理に該当していない不正なネットワーク装置であった場合に、ネットワーク全体に悪影響を及ぼし兼ねないので、かかる事態の発生を未然に防止するためである。
なお、認証管理3102に対する該認証要求には、認証の対象となるネットワーク装置を一意に特定することができる情報であって、かつ、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101が確実に把握することができるネットワーク装置識別情報が付されている。例えば、事前登録・削除要求パケットの送信元を示す装置An 30n0のIPアドレスやMACアドレス等が付されている。
認証要求を受け取った認証管理3102においては、該認証要求に付されているネットワーク装置識別情報例えばIPアドレスやMACアドレス等に基づいて、該認証要求の対象となっているネットワーク装置の装置An 30n0がリソース管理の対象装置であるか否かを判別することにより、装置An 30n0の認証処理を行う。なお、認証管理3102における認証方法はかかる場合に限るものではなく、他の認証の仕組みを用いるようにしても良い。
認証管理3102は、装置An 30n0の認証処理を終了すると、リソース管理の対象装置であるか否かを判別した認証結果を、認証要求の送信元のリソース管理Manager(リソース管理マネジャ)3101に対して認証応答として返送する(シーケンスS4003)。
リソース管理Manager(リソース管理マネジャ)3101は、認証管理3102から認証応答として装置An 30n0の認証結果を受け取り、該認証結果がNGであった場合には、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1から受け取った事前登録・削除要求パケットに含まれている全ての希望アクションの事前登録を拒否する。一方、該認証結果がOKであった場合には、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1から受け取った事前登録・削除要求パケットに含まれている全ての希望アクションすなわち希望アクション1,…,希望アクションjを事前登録するとともに、それぞれの希望アクションごとに、それぞれの希望アクションを一意に特定するための本登録キーを発行する。
さらに、リソース管理Manager(リソース管理マネジャ)3101は、認証結果がNGであった場合には、事前登録要求を受け付けられない旨を示すNG応答として、図8に示す事前登録応答パケットのヘッダ情報内の承認キーを"all0"に設定して、事前登録要求の送信元の装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1に対して送信する(シーケンスS4004)。
一方、認証結果がOKであった場合には、事前登録要求を受け付けた旨を示すOK応答として、事前登録・削除要求パケットに含まれているそれぞれの希望アクションを一意に特定する本登録キーを付与した図8に示す事前登録応答パケットを作成するとともに、ヘッダ情報内の承認キーを、装置An 30n0をリソース管理対象のネットワーク装置として承認したことを示す"all0"以外の有意な一意の値に設定して、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1に対して送信する(シーケンスS4004)。
図8は、図3のリソース管理システムにおいてリソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101から事前登録・削除要求元のネットワーク装置すなわち装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1に対して送信される事前登録・削除応答パケットのフォーマットの一例を示すテーブルである。
ここで、図8に示す事前登録・削除応答パケットも、事前登録・削除要求パケットと同様、UDP(User Datagram protocol)パケット上のペイロードとして扱われ、事前登録・削除要求パケットの送信元の装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1に送信することによって、事前登録・削除要求パケットによって要求された希望アクション(希望実施内容)を事前登録したか否かを通知するために用いられる。
具体的には、図8に示す事前登録・削除応答パケットは、ヘッダ情報に関しては、要求数に関する情報を設定する領域が要求受付数に関する情報を設定する領域に変更した以外は、事前登録・削除要求パケットと同様であり、バージョン、ヘッダ長、パケット長、タイプ、シーケンス番号、承認キー、予約の各情報からなり、該ヘッダ情報に引き続くデータ領域には、事前登録・削除要求パケットに含まれていた仮登録番号ごとに、仮登録結果および希望するアクション(処理内容)を一意に特定する本登録キーを1組の希望アクション応答とし、受け取った事前登録・削除要求パケットに応じて、希望アクション1応答,…,希望アクションj応答と複数組纏めて収容することができる。なお、ヘッダ情報に含まれるタイプには、事前登録・削除の応答を返送するパケットである旨を示す表示が設定される。
つまり、前述の表2に示すように、事前登録・削除応答パケットのヘッダ情報内の要求受付数フィールドには、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1から受け取った事前登録・削除要求パケットの希望実施内容フィールドにて指定されている希望アクション(希望実施内容)のうち、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101において正当な処理要求であると認識して、事前登録された希望アクション(希望実施内容)の個数が設定される。
また、事前登録・削除応答パケットのデータ領域内において希望アクション応答ごとに設定される仮登録結果フィールドは、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1からの各希望アクション(希望実施内容)ごとの事前登録結果(事前登録されたか否かを示す情報)を設定する。事前登録・削除応答パケットのデータ領域内において希望アクション応答ごとに設定される本登録キーフィールドは、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101において事前登録した希望アクション(希望実施内容)ごとに発行した本登録キーを設定する。
事前登録・削除応答パケットの残りの各フィールドすなわちバージョン、ヘッダ長、パケット長、タイプ、シーケンス番号、承認キー、仮登録番号の各フィールドに関しては、図7に示した事前登録・削除要求パケットにおける各フィールドと同じである。ただし、承認キーフィールドには、事前登録要求元の装置An 30n0がリソース管理対象のネットワーク装置として承認され、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101において事前登録・削除要求パケットに含まれている希望アクション(希望実施内容)の少なくとも1つ以上を事前登録した際に発行された'all0'以外の有意な一意の値である承認キーが設定される。
また、シーケンス番号フィールドには、イベントが発生する都度、図7に示した事前登録・削除要求パケットの場合とは逆方向に、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101から装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1へ送信したパケットの送信順を示す番号が設定される。
図4のシーケンスチャートに戻って、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1は、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101から事前登録・削除応答パケットを受け取ると、該事前登録・削除応答パケットのヘッダ情報に含まれている承認キーを参照して、'all0'以外の有意な一意の値が設定されているか否かを判別する。承認キーが'all0'であった場合には、当該装置An 30n0が、リソース管理サーバ3100のリソース管理対象のネットワーク装置ではないと認定されて、事前登録が拒絶されたことを示している。
一方、承認キーが'all0'以外の有意な一意の値であった場合には、先に送信した事前登録・削除要求パケットに含まれている希望アクション(希望実施内容)の事前登録要求が受け付けられたものとして、事前登録・削除応答パケットを正常に受け取ったことを示す応答ACKを、図9に示す事前登録・削除応答ACKパケットとして、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101に対して送信する(シーケンスS4005)。
なお、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1においては、以降、データ領域に仮登録番号ごとに対応付けて設定されている本登録キーを用いて、実施を希望する希望実施内容すなわち希望アクション(処理内容)を管理することになる。
図9は、図3のリソース管理システムにおいて事前登録・削除応答パケットを受け取ったネットワーク装置すなわち装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1からリソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101に対して送信される事前登録・削除応答ACKパケットのフォーマットの一例を示すテーブルである。
ここで、図9に示す事前登録・削除応答ACKパケットも、事前登録・削除要求パケットと同様、UDP(User Datagram protocol)パケット上のペイロードとして扱われ、事前登録・削除応答パケットの送信元のリソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101に送信することによって、事前登録・削除応答パケットを正常に受け取った旨を通知するために用いられる。
具体的には、図9に示す事前登録・削除応答ACKパケットは、ヘッダ情報のみからなり、ヘッダ情報にはバージョン、ヘッダ長、パケット長、タイプ、承認応答結果、シーケンス番号、承認キー、予約が含まれている。なお、ヘッダ情報に含まれるタイプには、事前登録・削除応答パケットを正常に受け取った旨を示す応答ACKパケットである旨を示す表示が設定される。
つまり、前述の表2に示すように、事前登録・削除応答ACKパケットのヘッダ情報内の承認応答結果フィールドは、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1においても、事前登録・削除要求パケットの希望実施内容フィールドにて指定した希望アクション(希望実施内容)のうちリソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101において事前登録された希望アクション(希望実施内容)を正しく認識することができたか否かを示す情報を設定する。なお、複数存在している予約フィールドは、いずれも、現在使用されていないダミーの領域を示している。
事前登録・削除応答パケットの残りの各フィールドすなわちバージョン、ヘッダ長、パケット長、タイプ、シーケンス番号、承認キーの各フィールドに関しては、図7に示した事前登録・削除要求パケットにおける各フィールドと同じである。ただし、承認キーフィールドには、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101において事前登録・削除要求パケットを受け付けて、事前登録・削除要求パケットに含まれている希望アクション(希望実施内容)の少なくとも1つ以上を事前登録した際に発行された'all0'以外の有意な一意の値である承認キーが設定される。
以上の図4のシーケンスチャートに関する説明は、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1からの事前登録・削除要求パケットとして、リソース閾値を超えてリソース不足が発生したことを示すアラーム発生通知をリソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101に対して送信した際に実施してもらいたい希望アクション(希望実施内容)を事前登録することを要求している場合について説明したが、事前登録されている希望アクション(希望実施内容)を削除することを要求する場合についても、全く同様のシーケンスで実施される。
ただし、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1からの事前登録・削除要求パケットとして、事前登録されている希望アクション(希望実施内容)の削除を要求する場合には、ヘッダ情報に含まれるタイプには、事前登録の削除を要求するパケットである旨の表示が設定され、要求数には、事前登録の削除を要求する希望アクションの個数が設定される。
また、削除要求を行う場合には、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1においても、各希望アクション(各希望実施内容)を一意に特定するための識別番号として、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101が発行した本登録キーが既に用いられているので、事前登録の要求時においてデータ領域の希望実施内容ごとに設定されていた仮登録番号の代わりに、本登録キーが設定される。
なお、図4に示すような事前登録・削除処理においては、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1から送信されてくる事前登録・削除要求パケットを受け取ったとしても、アプリケーション実行の予約に関する情報は無効であり、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101から、アプリケーションX 3103に対してアプリケーション実行の予約等を事前に行うことはない。
アプリケーションX 3103の実行を予約する場合は、あくまでも、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1において、使用するリソースがリソース閾値を超えてリソース不足が発生したりあるいはリソース閾値以下に低下してリソース不足から回復したりして、アラーム発生通知をリソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101に送信してきた場合のみに限られる。
次に、図3のリソース管理システムに示したリソース管理サーバ3100と管理対象のネットワーク装置である装置An 30n0との間の通信シーケンスについて、装置An 30n0において使用するリソースがリソース閾値を超えてリソース不足が発生したりあるいは該リソース閾値以下に低下してリソース不足から回復したりして、事前に設定登録している希望実施内容すなわち希望アクションの実施を要求するアラーム発生通知を、アラーム発生通知パケットとして、装置An 30n0からリソース管理サーバ3100に対して送信する際のシーケンスの一例を、図5を用いて説明する。
図5は、図3のリソース管理システムにおけるアラーム処理要求発生時の処理シーケンスの一例を示すシーケンスチャートであり、管理対象のネットワーク装置の装置A1 3010ないし装置An 30n0のうち、いずれかのネットワーク装置例えば第n番目の装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1からリソース管理サーバ3100に対してアラーム発生通知が送信されて、事前に設定登録されていた希望アクション(希望実施内容)を実施する際の処理シーケンスの一例を示している。すなわち、アラーム発生通知を受け取ったリソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101が、事前登録された希望アクション(希望実施内容)とアラーム発生通知内容とに基づいて、実施すべきアクションを決定した結果として、アプリケーションX 3103を駆動して、アラーム発生通知の送信元の装置An 30n0のアプリケーションAn 30n2に対して、アラーム処理要求を送信することによって、装置An 30n0のMIB(Management Information Base)情報を収集して輻輳状態を判別し、リソース状態の再配分を行う場合のシーケンス例について示している。以下においては、図5のシーケンスで示す一連の処理を「アラーム処理1」と称することにする。
図5のシーケンスチャートにおいて、まず、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1は、使用しようとするネットワークのリソースがあらかじめ設定しているリソース閾値を超えたか、あるいは、該リソース閾値を超えた状態から該リソース閾値以下にまで低下してリソース不足から回復したりしたことを検知すると、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101に対して、アラーム処理要求を行うためのアラーム発生通知として、図10に示すフォーマットからなるアラーム発生通知パケットを送信する(シーケンスS5001)。
図10は、図3のリソース管理システムにおいてアラーム発生元のネットワーク装置すなわち装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1からリソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101に対して送信されるアラーム発生通知パケットのフォーマットの一例を示すテーブルである。
ここで、図10に示すアラーム発生通知パケットも、事前登録・削除要求パケットと同様、UDP(User Datagram protocol)パケット上のペイロードとして扱われ、アラーム発生元の装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1からリソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101に送信することによって、事前登録しておいた希望アクション(希望実施内容)のいずれかを実施することを要求するために用いられる。
具体的には、図10に示すアラーム発生通知パケットは、ヘッダ情報に関しては、要求数に関する情報を設定する領域を予約領域に変更した以外は、事前登録・削除要求パケットと同様であり、バージョン、ヘッダ長、パケット長、タイプ、シーケンス番号、承認キー、予約の各情報からなり、該ヘッダ情報に引き続くデータ領域には、本登録キー、閾値種別、予約からなるアラーム内容が設定される。なお、ヘッダ情報に含まれるタイプには、アラーム発生を通知するパケットである旨を示す表示が設定され、アラーム内容の閾値種別には、リソース閾値を超えたかまたは該リソース閾値以下に低下してリソース不足から回復したかを示す情報が設定されている。
つまり、前述の表2に示すように、アラーム発生通知パケットのヘッダ情報内のシーケンス番号フィールドは、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1において、アラームが発生する都度、インクリメントされる番号であり、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1からリソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101へ送信したパケットの送信順を示している。該シーケンス番号は、装置An 30n0に発生したアラームをリソース管理サーバ3100に通知した状況を管理するための識別番号として使用される。
また、アラーム発生通知パケットのデータ領域にあるアラーム内容内の閾値種別フィールドは、前述したように、装置An 30n0の使用リソースがリソース閾値を超えてリソース不足が発生した場合かまたは該リソース閾値以下に低下してリソース不足から回復した場合かを示している。
アラーム発生通知パケットの残りの各フィールドすなわちバージョン、ヘッダ長、パケット長、タイプ、承認キー、本登録キーの各フィールドに関しては、図7に示した事前登録・削除要求パケットにおける各フィールドと同じである。ただし、承認キーフィールドには、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101において既に発行されている承認キーが設定される。
図5のシーケンスチャートに戻って、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101は、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1からアラーム発生通知パケットを受け取ると、図4の事前登録・削除処理の場合と同様、該アラーム発生通知パケットの送信元の装置An 30n0が、管理対象のネットワーク装置であるか否かを判別するために、認証管理3102に対して認証要求を行う(シーケンスS5002)。
認証要求を受け取った認証管理3102においては、図4の事前登録・削除処理の場合と同様、該認証要求に付されているネットワーク装置識別情報例えばIPアドレスやMACアドレス等に基づいて、該認証要求の対象となっているネットワーク装置の装置An 30n0がリソース管理の対象装置であるか否かを判別することにより、装置An 30n0の認証処理を行う。なお、認証管理3102における認証方法はかかる場合に限るものではなく、他の認証の仕組みを用いるようにしても良い。
認証管理3102は、装置An 30n0の認証処理を終了すると、図4の事前登録・削除処理の場合と同様、リソース管理の対象装置であるか否かを判別した認証結果を、認証要求の送信元のリソース管理Manager(リソース管理マネジャ)3101に対して認証応答として返送する(シーケンスS5003)。
リソース管理Manager(リソース管理マネジャ)3101は、認証管理3102からの認証応答として、装置An 30n0の認証結果を受け取り、該認証結果がNGであった場合には、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1から受け取ったアラーム発生通知パケットにて要求されているアクションの実施を拒否する。
一方、該認証結果がOKであった場合には、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1から受け取ったアラーム発生通知パケットに含まれている本登録キーおよび閾値種別に基づいて、事前登録されている希望アクション(希望実施内容)を参照して、実施すべきアクション(処理内容)を決定する。決定されたアクション(処理内容)が、例えば、アプリケーションX 3103を駆動して、輻輳状態を判別するためにアラーム発生通知の送信元の装置An 30n0のアプリケーションAn 30n2にアラーム処理要求を送信することによって、装置An 30n0のMIB(Management Information Base)情報を収集する処理を行う場合には、リソース管理Manager(リソース管理マネジャ)3101は、アプリケーションX 3103を駆動して、アラーム処理要求として、決定したアクション(処理内容)にしたがった処理の実施を要求する(シーケンスS5004)。
駆動されたアプリケーションX 3103は、リソース管理Manager(リソース管理マネジャ)3101からのアラーム処理要求に応じた動作、例えば、アラーム発生通知の送信元の装置An 30n0にアラーム処理要求を送信することによって、装置An 30n0のアプリケーションAn 30n2のSNMP(Simple Network Management Protocol) MIB(Management Information Base)情報を収集する動作を起動する。この動作が起動されると、アプリケーションX 3103は、事前登録された希望アクション(希望実施内容)の中から決定した希望アクション(希望実施内容)にしたがったアラーム処理要求として、例えば、アラーム発生通知の送信元の装置An 30n0のアプリケーションAn 30n2に対して、SNMP MIB情報の収集を指示するアラーム処理要求を送信する(シーケンスS5005)。
装置An 30n0のアプリケーションAn 30n2は、決定した事前登録の希望アクション(希望実施内容)にしたがったアラーム処理要求例えばSNMP MIB情報の収集を指示するアラーム処理要求をリソース管理サーバ3100のアプリケーションX 3103から受け取ると、事前登録の希望アクション(希望実施内容)にしたがった処理例えばSNMP MIB情報の収集処理を実施して、事前登録の希望アクション(希望実施内容)の実施結果例えばSNMP MIB情報の収集結果を、リソース管理サーバ3100のアプリケーションX 3103に対して返送する(シーケンスS5006)。
リソース管理サーバ3100のアプリケーションX 3103は、アラーム処理要求に応じて、装置An 30n0のアプリケーションAn 30n2から返送されてきた事前登録の希望アクション(希望実施内容)の実施結果例えばSNMP MIB情報の収集結果を受け取ると、受け取った実施結果例えばSNMP MIB情報の収集結果を保持するとともに、該SNMP MIB情報の収集結果に基づくリソースの再配分を行い、決定した事前登録の希望アクション(希望実施内容)の実施が成功したか否かを、当該アプリケーションX 3103から、アラーム処理要求に対する応答として、アラーム処理要求元のリソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101に対して返送する(シーケンスS5007)。
リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101は、アプリケーションX 3103からアラーム処理要求に対する応答を受け取ると、該応答を実行結果として含む図11に示すフォーマットからなるアラーム発生応答パケットを作成して、アラーム発生通知パケットの送信元の装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1に対して送信する(シーケンスS5008)。
なお、アプリケーションX 3103における何らかの処理が失敗した場合には、アプリケーションX 3103は、アラーム処理要求元のリソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101に対して処理を失敗した旨を示す応答を返送する。かくのごとく、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101が、アプリケーションX 3103における処理が失敗した旨の応答を受け取った場合には、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1に対するアラーム発生応答パケットの送信動作を抑止して、応答待ちタイムアウトによる装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1からのアラーム発生通知パケットの再送信を促すようにしても良い。
図11は、図3のリソース管理システムにおいてリソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101からアラーム発生通知パケットの送信元のネットワーク装置すなわち装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1に対して送信されるアラーム発生応答パケットのフォーマットの一例を示すテーブルである。
ここで、図11に示すアラーム発生応答パケットも、事前登録・削除要求パケットと同様、UDP(User Datagram protocol)パケット上のペイロードとして扱われ、アラーム発生通知パケットの送信元の装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1に送信することによって、アラーム発生通知パケットによって要求された希望アクション(希望実施内容)の実施に成功したか否かを通知するために用いられる。
具体的には、図11に示すアラーム発生応答パケットは、ヘッダ情報に関しては、要求数に関する情報を設定する領域を予約領域に変更した以外は、事前登録・削除要求パケットと同様であり、バージョン、ヘッダ長、パケット長、タイプ、シーケンス番号、承認キー、予約の各情報からなり、該ヘッダ情報に引き続くデータ領域には、本登録キー、実行結果、閾値種別、強制削除フラグからなるアラーム応答内容が設定される。なお、ヘッダ情報に含まれるタイプには、アラーム発生通知に対する応答を返送するパケットである旨を示す表示が設定される。
つまり、前述の表2に示すように、アラーム発生応答パケットのヘッダ情報内のシーケンス番号フィールドには、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101において、イベントが発生する都度、図10に示したアラーム発生通知パケットの場合と同様、インクリメントされる番号であり、図10に示したアラーム発生通知パケットの場合とは逆方向に、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101から装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1へ送信したパケットの送信順を示している。
また、アラーム発生応答パケットのデータ領域にあるアラーム応答内容内の閾値種別フィールドには、図10に示したアラーム発生通知パケットにより送信されてきた閾値種別がそのまま設定され、装置An 30n0の使用リソースがリソース閾値を超えてリソース不足が発生した場合かまたは該リソース閾値以下に低下してリソース不足から回復した場合かを示している。
また、アラーム発生応答パケットのデータ領域にあるアラーム応答内容内の実行結果フィールドには、アラーム発生通知パケットにより要求された希望アクション(希望実施内容)の処理例えばSNMP MIB情報の収集処理が成功し、リソースの再配分に成功したか否かを示す実行結果が設定され、本実施例においては、アプリケーションX 3103により駆動された装置An 30n0のアプリケーションAn 30n2の実施が成功したか否かを示す情報が設定される。なお、該実行結果として、アプリケーションX 3103により駆動された装置An 30n0のアプリケーションAn 30n2の実施結果を示す処理詳細例えばSNMP MIB情報の収集結果やリソース再配分処理結果を含むようにしても良い。
また、アラーム発生応答パケットのデータ領域にあるアラーム応答内容内の強制削除フラグフィールドには、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101が、ネットワーク全体の各ネットワーク装置からの希望アクション(希望実施内容)やリソース状態を保持しているプロファイル3104に設定されているデータの参照結果として、アプリケーションX 3103に対するアラーム処理要求は不適当であると判定して、アプリケーションX 3103に対して希望アクション(希望実施内容)の実施を要求するアラーム処理要求を行わなかった場合には、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1に対して事前登録されている当該希望アクション(希望実施内容)の強制的な削除を指示するための強制削除フラグが設定される。該強制削除フラグが設定されているアラーム発生応答パケットを受け取った装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1は、必ず、当該希望アクション(希望実施内容)の削除を実施しなければならない。なお、プロファイル3104に設定されているデータの詳細については後述する。
アラーム発生応答パケットの残りの各フィールドすなわちバージョン、ヘッダ長、パケット長、タイプ、承認キー、本登録キーの各フィールドに関しては、図7に示した事前登録・削除要求パケットにおける各フィールドと同じである。ただし、承認キーフィールドには、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101において既に発行されている承認キーが設定される。
図5のシーケンスチャートに戻って、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1は、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101からアラーム発生応答パケットを受け取ると、該アラーム発生応答パケットのデータ領域にあるアラーム応答内容内の実行結果フィールドを確認し、実施要求していた希望アクション(希望実施内容)の実施が成功したか否かを確認する。希望アクション(希望実施内容)の実施が成功していた場合には、使用するリソースの割当状況に変化が生じているものと看做すことができるが、実施が失敗していた場合には、さらに、データ領域にあるアラーム応答内容内の強制削除フラグフィールドを参照して強制削除フラグが設定されているか否かを確認する。
強制削除フラグが設定されていた場合には、前述したように、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1は、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101に対して、事前登録・削除要求パケットを送信して、事前登録していた希望アクション(希望実施内容)を削除しなければならない。
かくのごとき事前登録の希望アクション(希望実施内容)の強制的な削除処理を実行する目的は、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101側において、実施が失敗になってしまうようなアラーム処理要求をアプリケーションX 3103に対していつまでも送信し続けることがないように、該希望アクション(希望実施内容)の実施を要求するアラーム発生通知パケットを、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1から送信する動作を抑止するためである。つまり、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1からリソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101に対して、何回も繰り返して、実施することが出来ない希望アクション(希望実施内容)の実施を要求するアラーム発生通知パケットが送信されることによる輻輳を防止するためである。
受け取ったアラーム発生応答パケットの処理を終了すると、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1は、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101からのアラーム発生応答パケットを正常に受け取ったことを示すアラーム発生応答ACKを、図12に示すアラーム発生応答ACKパケットとして、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101に対して送信する(シーケンスS5009)。
図12は、図3のリソース管理システムにおいてアラーム発生応答パケットを受け取ったネットワーク装置すなわち装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1からリソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101に対して送信されるアラーム発生応答ACKパケットのフォーマットの一例を示すテーブルである。
ここで、図12に示すアラーム発生応答ACKパケットも、事前登録・削除要求パケットと同様、UDP(User Datagram protocol)パケット上のペイロードとして扱われ、アラーム発生応答パケットの送信元のリソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101に送信することによって、アラーム発生応答パケットを正常に受け取った旨を通知するために用いられる。
具体的には、図12に示すアラーム発生応答ACKパケットは、ヘッダ情報に関しては、要求数に関する情報を設定する領域を予約領域に変更した以外は、事前登録・削除要求パケットと同様であり、バージョン、ヘッダ長、パケット長、タイプ、シーケンス番号、承認キー、予約の各情報からなり、該ヘッダ情報に引き続くデータ領域には、本登録キー、応答結果、閾値種別、強制削除結果、予約からなるアラームACKが設定される。なお、ヘッダ情報に含まれるタイプには、アラーム発生応答パケットを正常に受け取った旨を示すアラーム発生応答ACKパケットである旨を示す表示が設定される。
つまり、前述の表2に示すように、アラーム発生応答ACKパケットのヘッダ情報内のシーケンス番号フィールドは、図10に示したアラーム発生通知パケットの場合と同様、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1において、イベントが発生する都度、インクリメントされる番号であり、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1からリソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101へ送信したパケットの送信順を示している。
また、アラーム発生応答ACKパケットのデータ領域にあるアラーム応答内容内の閾値種別フィールドには、図10に示したアラーム発生通知パケットにより送信した閾値種別がそのまま設定され、装置An 30n0の使用リソースがリソース閾値を超えてリソース不足が発生した場合かまたは該リソース閾値以下に低下してリソース不足から回復した場合かを示している。
また、アラーム発生応答ACKパケットのデータ領域にあるアラームACK内の応答結果フィールドには、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1においても、アラーム発生応答パケットのアラーム応答内容、すなわち、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101において実施された処理内容を正しく認識することができたか否かを示す情報が設定される。
また、アラーム発生応答ACKパケットのデータ領域にあるアラームACK内の強制削除結果フィールドには、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101からの指示通りに、事前登録した希望アクション(希望実施内容)を強制削除することができたか否かを示す情報が設定される。なお、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101からのアラーム発生応答パケットに強制削除フラグが設定されていなかった場合には、アラームACK内の強制削除結果フィールドには無効なデータが設定された状態になっている。
アラーム発生応答ACKパケットの残りの各フィールドすなわちバージョン、ヘッダ長、パケット長、タイプ、承認キーの各フィールドに関しては、図7に示した事前登録・削除要求パケットにおける各フィールドと同じである。ただし、承認キーフィールドには、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101において既に発行されている承認キーが設定される。
なお、図5のシーケンスS5008において、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1から、アラーム発生通知パケットを送信した後、あらかじめ定めた時間閾値を経過しても、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101からアラーム発生応答パケットを受信することができなかった場合には、応答待ちタイムアウトが発生したものとして、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1は、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101に対してアラーム発生通知パケットを再度送信する動作を行うようにしても良い。
次に、図3のリソース管理システムに示したリソース管理サーバ3100と管理対象のネットワーク装置である装置An 30n0との間の通信シーケンスについて、装置An 30n0において使用するリソースがリソース閾値を超えたりあるいは該リソース閾値以下に低下してリソース不足から回復したりして、事前に設定登録している希望実施内容すなわち希望アクションの実施を要求するアラーム発生通知を、アラーム発生通知パケットとして、装置An 30n0からリソース管理サーバ3100に対して送信する際のシーケンスについて、図5とは異なる例を、図6を用いて説明する。
図6は、図3のリソース管理システムにおけるアラーム処理要求発生時の処理シーケンスの図5とは異なる例を示すシーケンスチャートであり、管理対象のネットワーク装置の装置A1 3010ないし装置An 30n0のうち、いずれかのネットワーク装置例えば第n番目の装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1からリソース管理サーバ3100に対してアラーム処理要求が送信されて、事前に設定登録されていた希望アクション(希望実施内容)を実施する際の処理シーケンスの他の例を示している。すなわち、アラーム発生通知を受け取ったリソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101が、事前登録された希望アクション(希望実施内容)とアラーム発生通知内容とに基づいて、実施すべきアクションを決定した結果として、アプリケーションX 3103を駆動して、アラーム発生通知の送信元の装置An 30n0とは異なる他のネットワーク装置例えば装置Am 30m0のアプリケーションAm 30m2に対してアラーム処理要求を送信することによって、アプリケーションAm 30m2を駆動して、装置Am 30m0の閉塞状態を解除させる装置Am 30m0側のコマンドを実施する場合のシーケンス例について示している。以下においては、図6のシーケンスで示す一連の処理を「アラーム処理2」と称することにする。
図6のシーケンスチャートにおいて、シーケンスS6001〜S6003までのシーケンスおよびシーケンスS6007〜S6009までのシーケンスは、それぞれ、図5のシーケンスチャートS5001〜S5003までのシーケンスおよびシーケンスS5007〜S5009までのシーケンスと全く同様であるので、ここでの重複する説明は省略する。
図6のシーケンスS6004において、リソース管理Manager(リソース管理マネジャ)3101は、シーケンスS6003において認証管理3102から認証応答として返送されてきた装置An 30n0の認証結果を受け取ると、該認証結果がNGであった場合には、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1から受け取ったアラーム発生通知パケットにて要求されているアクションの実施を拒否する。
一方、該認証結果がOKであった場合には、装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1から受け取ったアラーム発生通知パケットに含まれている本登録キーおよび閾値種別に基づいて、事前登録されている希望アクション(希望実施内容)を参照して、実施すべきアクション(処理内容)を決定する。
決定されたアクション(処理内容)が、例えば、アプリケーションX 3103を駆動して、図5のシーケンスS5004の場合とは異なり、アラーム発生通知の送信元の装置An 30n0のアプリケーションAn 30n2の輻輳状態を解決するために、アラーム発生通知の送信元の装置An 30n0のアプリケーションAn 30n2とは異なる他のネットワーク装置例えば装置Am 30m0のアプリケーションAm 30m2のTelnetサーバに対してリソース管理サーバ3100のTelnetクライアントが接続を要求して、CLI(Command Line Interface)を用いて装置Am 30m0側のコマンドを実施するアラーム処理要求であった場合には、リソース管理Manager(リソース管理マネジャ)3101は、アプリケーションX 3103を駆動して、アラーム処理要求として、決定したアクション(処理内容)にしたがった処理の実施を要求する(シーケンスS6004)。
駆動されたアプリケーションX 3103は、リソース管理Manager(リソース管理マネジャ)3101からのアラーム処理要求に応じた動作、例えば、アラーム発生通知の送信元の装置An 30n0とは異なる他のネットワーク装置例えば装置Am 30m0のアプリケーションAm 30m2のTelnetサーバに対してリソース管理サーバ3100のアプリケーションX 3103のTelnetクライアントが接続を要求して、CLI(Command Line Interface)のコマンドラインインタフェースを用いて、装置Am 30m0側のコマンドを実施する動作、を起動する。
この動作が起動されると、アプリケーションX 3103は、事前登録された希望アクション(希望実施内容)の中から決定した希望アクション(希望実施内容)にしたがった実施処理結果として、例えば、装置Am 30m0のアプリケーションAm 30m2のTelnetサーバに対してリソース管理サーバ3100のTelnetクライアントが接続を要求して、CLI(Command Line Interface)のコマンドラインインタフェースを用いて、装置Am 30m0側のコマンドを実施するというアラーム処理要求を送信する(シーケンスS6005)。
装置Am 30m0のアプリケーションAm 30m2は、決定した事前登録の希望アクション(希望実施内容)にしたがったアラーム処理要求例えばCLI(Command Line Interface)を用いて装置Am 30m0側のコマンドを実施するというアラーム処理要求をリソース管理サーバ3100のアプリケーションX 3103から受け取ると、事前登録の希望アクション(希望実施内容)にしたがった処理例えばリソース管理サーバ3100のTelnetクライアントからのCLI(Command Line Interface)を用いた要求に該当する装置Am 30m0側のコマンドをTelnetサーバとして実施して(例えば、装置Am 30m0の閉塞状態を解除して)、事前登録の希望アクション(希望実施内容)の実施結果例えばコマンドの実行結果を、リソース管理サーバ3100のアプリケーションX 3103に対して返送する(シーケンスS6006)。
かくのごとく、輻輳状態に陥ってアラーム発生通知の送信元となっていた装置An 30n0とは異なる他のネットワーク装置例えば装置Am 30m0のアプリケーションAm 30m2においてコマンドを実行することによって、例えば、装置Am 30m0の閉塞状態を解除して、アラーム処理要求元の装置An 30n0側の負荷の一部を分担することが可能になる。
次に、図5のシーケンスS5005において、アラーム発生応答パケットの強制削除フラグを設定するか否かを判別するために、つまり、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101がアプリケーションX 3103への実施要求が適当か否かを判定して、該判定結果に基づいてアプリケーションX 3103に対して希望アクション(希望実施内容)の実施を要求するか否かを判別するために、参照されるプロファイル3104のデータについて、次の表3を用いて詳細に説明する。
表3に示すプロファイル3104は、前述のように、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101内に保持されているネットワーク全体のリソース管理に関するデータベースであり、ネットワークを構成する各ネットワーク装置から事前登録されている希望アクション(希望実施内容)を実施履歴や各ネットワーク装置のリソース状態とともに保持している。つまり、プロファイル3104は、表3に示すように、承認キー301、承認先IPアドレス/プレフィックス302、本登録キー303、希望優先度304、指示対象名305、実施回数306、開始時刻307、希望実施内容308、登録完了時刻309、現在の状態310を少なくとも有して構成されている。さらに、本登録キーごとにそれぞれのアクション(処理内容)の実施履歴として、項番311、実施結果312、開始時刻313、完了時刻314を有して構成されている。
表3に示すプロファイル3104の設定例においては、承認キー301、承認先IPアドレス/プレフィックス302および希望実施内容308に示すように、承認先IPアドレス/プレフィックス302が'A,B,C,D/P'のネットワーク装置の装置An 30n0からの事前登録処理により、承認キー301が'3fe9105a'として登録された2つの希望実施内容(本登録キー303が'00000001'および'00000002'の2つ)が設定され、承認先IPアドレス/プレフィックス302が'W,X,Y,Z/P'のネットワーク装置の装置Am 30m0からの事前登録処理により、承認キー301が'3fe9105b'として登録された2つの希望実施内容(本登録キー303が'00000003'および'00000004'の2つ)が設定されている例が示されている。
ここで、表3に示すプロファイル3104の承認キー301、本登録キー303、希望優先度304、指示対象名305、実施回数306、開始時刻307、希望実施内容308、実施結果312のそれぞれのデータについては、図7の事前登録・削除要求パケット、図8の事前登録・削除応答パケット、図9の事前登録・削除応答ACKパケット、図10のアラーム発生通知パケット、図11のアラーム発生応答パケット、および、図12のアラーム発生応答ACKパケットの内容が反映される。
また、表3に示すプロファイル3104の承認先IPアドレス/プレフィックス302、および、登録完了時刻309については、図4の事前登録・削除処理のシーケンス処理中において、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101が認識することにより設定することができる。
また、表3に示すプロファイル3104の現在の状態310、および、実施履歴の項番311については、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101による監視結果として決定して設定することができる。
また、表3に示すプロファイル3104の実施履歴の開始時刻313、および、完了時刻314については、図5のアラーム処理1のシーケンスにおけるシーケンスS5004(アプリケーションX 3103へのアラーム処理要求を行うシーケンス)、および、シーケンスS5007(アプリケーションX 3103から実施結果を受け取るシーケンス)や、あるいは、図6のアラーム処理2のシーケンスにおけるシーケンスS6004(アプリケーションX 3103へのアラーム処理要求を行うシーケンス)、および、シーケンスS6007(アプリケーションX 3103から実施結果を受け取るシーケンス)によって、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101が認識して設定することができる。
ここで、現在の状態310は、本登録キーごとに'待ち'、'実行中'、'完了'、'失敗'の4つの状態が存在する。'完了'の後は、'待ち'の状態に遷移する。'待ち'の後は、'実行中'の状態に遷移する。'失敗'の後は、'待ち'の状態に遷移するか、あるいは、強制削除によって、当該本登録キー自体が削除される。表3に示す例においては、本登録キー'00000004'の場合が、現在の状態310に示すように、'失敗'の状態になっている。
かくのごとく、現在の状態310が'失敗'の状態にある場合に、次の状態として'待ち'の状態に遷移するか、あるいは、強制削除するかは、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101において適宜判別される。例えば、当該本登録キーで特定される希望アクション(希望実施内容)の実施回数があらかじめ定めた回数閾値に達するまでは、'待ち'の状態に移行し、実施回数が該回数閾値以上に及んで何回も'失敗'を繰り返している場合には、当該本登録キーで特定される希望アクション(希望実施内容)は、強制的に削除することにしても良い。
なお、プロファイル3104から希望アクション(希望実施内容)のデータの削除を行う場合には、図4の事前登録・削除処理のシーケンスにしたがって、当該本登録キーの希望アクション(希望実施内容)を事前登録したネットワーク装置例えば装置An 30n0のリソース管理Agent(リソース管理エージェント)30n1との間で、希望アクション(希望実施内容)の削除処理を実施することになるが、当該本登録キーを主キーとしてプロファイル3104のデータを参照して削除することが可能である。
また、表3に示すプロファイル3104の実施結果312には、'成功'、'失敗'、および、'実行中'の3つの結果が存在する。実施結果312が'実行中'の場合には、現在の状態310も'実行中'の状態にあり、実施結果312が'失敗'の場合には、現在の状態310も'失敗'かまたは'待ち'の状態になり、実施結果312が'成功'の場合には、現在の状態310は'完了'かまたは'待ち'の状態になる。
以上のように、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101は、プロファイル3104としてネットワークを構成する各ネットワーク装置に関する各種のデータを保持しているので、送信先IPアドレスの払い出しや希望アクション(希望実施内容)の実行優先度付けを適宜行うことが可能である。
このようにして、本実施形態においては、各ネットワーク装置例えば例えば装置An 30n0から、リソース不足時に実施してもらいたい希望アクション(希望実施内容)をリソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101側に事前登録し、かつ、実際にリソース不足が発生した際に、事前登録した希望アクション(希望実施内容)の実施を要求するアラーム発生通知をネットワーク装置側からリソース管理サーバ3100に対して送信し、リソース管理サーバ3100のリソース管理Manager(リソース管理マネジャ)3101側において、事前登録された希望アクション(希望実施内容)の実施の可否判断をプロファイル3104に基づいて行っている。
したがって、従来技術におけるSNMP Trapメッセージ(トラップメッセージ)などとは異なり、アラームの発生をリソース管理サーバ3100に対して通報するだけではなく、アラーム発生通知に基づいて、事前登録の希望アクション(希望実施内用)としてあらかじめ登録された処理を実施させることができ、多数のネットワーク装置のリソース管理とアクション処理の管理とを一元化することができる。
(実施形態の具体的構成例)
以上に説明した本発明に係るリソース管理システムのシステム構成について、例えば、ネットワーク装置として呼処理装置を対象とした場合の構成例を、図13に示す。図13は、本発明に係るリソース管理システムの具体的なシステム構成の一例を示すシステム構成図であり、呼処理ネットワークにおけるシステム構成例を示しており、図1の場合とは異なり、ネットワーク装置として呼処理装置を対象とし、該呼処理装置が呼処理の制御対象とするユーザ端末装置とネットワークを介して接続されている様子を示している。
図3のシステム構成において、呼処理装置A1 13010,呼処理装置A2 13020,呼処理装置A3 13030は、図3におけるネットワーク装置例えば装置An 30n0と同様、それぞれ、リソース管理Agent(リソース管理エージェント)を備えており、管理ネットワーク13200を介して、リソース管理Manager(リソース管理マネジャ)を備えているリソース管理サーバ13100と通信を行うことによって、リソースの管理を行っている。
また、呼処理装置A1 13010,呼処理装置A2 13020は、それぞれ、呼処理の制御対象となるユーザ端末群13001,ユーザ端末群13002とネットワーク13300を介して接続されている。ここで、現時点においては、ユーザ端末群13001,ユーザ端末群13002の端末数が、それぞれ、既に、呼処理装置A1 13010,呼処理装置A2 13020それぞれに収容可能な端末数の最大限界値近くの端末数に達しているものと仮定する。一方、呼処理装置A3 13030は、管理ネットワーク13200およびネットワーク13300に接続されてオンライン状態になっているものの、呼処理の制御対象となるユーザ端末が存在していなく、VLAN(Virtual Local Area Network)機能を閉塞している状態になっているものと仮定する。
また、呼処理装置A1 13010,呼処理装置A2 13020は、それぞれ、図4の事前登録・削除要求処理のシーケンスにしたがって、リソース管理サーバ13100のリソース管理Manager(リソース管理マネジャ)に対して、収容端末数が収容可能端末数を超える場合には、収容端末数が少ない呼処理装置に呼処理を実施してもらいたいという希望アクション(希望実施内容)を事前登録しているものと仮定する。
具体的には、収容端末数が収容可能端末数を超える場合には、図6に示したアラーム処理2のシーケンスにおいて説明したように、リソース管理サーバ13100側のTelnetクライアントから収容端末数が少ない呼処理装置側のTelnetサーバへTelnet接続して、CLI(Command Line Interface)によるコマンドを実行させることによって、CLI上から割り出した呼処理装置のVLAN機能の閉塞状態を解除させて、呼処理を実行できるようにしたり、あるいは、リソース確保のために必要とする装置設定を行うようなコマンドを投入したりすることを要求する希望アクション(希望実施内容)が事前登録されている。
また、リソース管理サーバ13100のリソース管理Manager(リソース管理マネジャ)は、呼処理装置A1 13010,呼処理装置A2 13020,呼処理装置A3 13030の希望アクション(希望実施内容)を、図7に示した事前登録・削除要求パケットによって受け取って、表3に示したようなプロファイルとして保持して管理している。
(実施形態の具体的構成例の動作の説明)
次に、図13に示した具体的なシステム構成例における動作の一例を、図13を用いてさらに説明する。
図13のシステム構成例において、前述したように、ユーザ端末群13001,ユーザ端末群13002の端末数が、それぞれ、呼処理装置A1 13010,呼処理装置A2 13020それぞれの収容可能端末数の最大限界値近くの端末数に既に達している状態にある。
かかる状態において、さらに、新しいユーザ端末群13003に対して呼処理サービスを提供し始めた場合、例えば、呼処理装置A1 13010によって新しいユーザ端末群13003に対する呼処理を実施しようとした場合には、呼処理装置A1 13010のリソースがあらかじめ定めたリソース閾値を超えてしまうため、呼処理装置A1 13010のリソース管理Agent(リソース管理エージェント)は、図10に示したようなアラーム発生通知パケットをリソース管理サーバ13100のリソース管理Manager(リソース管理マネジャ)に対して送信して、事前登録されている希望アクション(希望処理要求)の実施を要求する。すなわち、収容可能端末数を超えるユーザ端末の呼処理を収容端末数が少ない呼処理装置によって実行することを要求する。
リソース管理サーバ13100のリソース管理Manager(リソース管理マネジャ)側においては、呼処理装置A1 13010のリソース管理Agent(リソース管理エージェント)からのアラーム発生通知パケットを受け取ると、呼処理装置A1 13010,呼処理装置A2 13020,呼処理装置A3 13030に関するプロファイルのデータを参照して、収容端末数が最も少ない呼処理装置が、呼処理装置A3 13030であることを判別する。
その結果、リソース管理サーバ13100のリソース管理Manager(リソース管理マネジャ)は、図6に示したアラーム処理2のシーケンスにしたがって、シーケンスS6004において、例えば、アプリケーションXのTelnetクライアントからのTelnet通信によって、収容端末数が最も少ない呼処理装置A3 13030のVLAN機能の閉塞状態を解除させて、呼処理を実施できるようにし、新しいユーザ端末群13003に対して呼処理サービスを提供することができる状態に設定する。
以上のように、各呼処理装置からの事前登録要求に基づいてそれぞれの希望アクション(希望実施内容)をプロファイルとして事前登録することによって、該プロファイルに基づいてリソース管理を行うことを可能にし、適切な収容端末数の割当を自動的に行うことが可能になる。
(本実施形態の効果の説明)
以上に詳細に説明したように、本実施形態においては、以下に記載するような効果を奏することができる。
第1の効果は、管理対象のネットワーク装置がリソース不足に陥った際に実施を希望するアクション(処理実施内容)をリソース管理サーバ側にあらかじめ事前登録しているので、速やかに、必要なリソースを確保することができることである。
第2の効果は、リソース管理サーバのリソース管理Manager(リソース管理マネジャ)は、リソース不足に陥ったネットワーク装置以外の他のネットワーク装置のリソース使用状況をも考慮して、つまり、ネットワーク全体のリソース使用状況を考慮して、実施すべきアクション(処理実施内容)を判断することができるように、ネットワーク全体の各ネットワーク装置に関するリソース管理用の情報をプロファイルとして設定して保持しているので、リソース不足に陥ったネットワーク装置から事前登録されている希望アクション(希望処理実施内容)を実行することが適切であるか否かを確実に判断することができ、ネットワーク全体として最適なリソース割当を行うことができることである。
第3の効果は、ネットワークのリソースを管理するリソース管理サーバは、管理対象のネットワーク装置であるか否かを認証する仕組みを採用しているので、不正なネットワーク装置からのアクセスを確実に抑止して、不正なネットワーク装置によるリソース管理への悪影響を確実に防止することができることである。
(本発明の他の実施形態)
次に、本発明の他の実施形態として、リソース管理システムの基本的構成は、前述した実施形態の場合と同様であるが、多階層のリソース管理を実現する場合の構成例について図14を用いて説明する。図14は、本発明によるリソース管理システムのシステム構成の図1とは異なる例を示すシステム構成図であり、ネットワーク全体のリソースを管理するリソース管理サーバが、多階層化(図14の例においては2階層化)されて構成されている例を示している。つまり、本実施形態においては、多階層のリソース管理を実現するために、図14に示すように、リソース管理Agent(リソース管理エージェント)とリソース管理Manager(リソース管理マネジャ)とを併せ持つリソース管理サーバを設置している。
図14のシステム構成に示すように、最上位のリソース管理サーバC 14100の配下に、下位層のリソース管理サーバA 14210とリソース管理サーバB 14310とが分散配置されており、最上位のリソース管理サーバC 14100は、下位層のリソース管理サーバA 14210とリソース管理サーバB 14310とのリソースを管理する。また、リソース管理サーバC 14100とリソース管理サーバA 14210およびリソース管理サーバB 14310との間は、管理ネットワークC 14410を介して接続される。
最上位のリソース管理サーバC 14100は、下位層のリソース管理サーバA 14210とリソース管理サーバB 14310とのリソースを管理するために、前述の図3に示したリソース管理サーバ3100の場合と同様、リソース管理Manager(リソース管理マネジャ)14101を備えている。一方、下位層のリソース管理サーバA 14210は、リソース管理Agent(リソース管理エージェント)14211とリソース管理Manager(リソース管理マネジャ)14201との双方を備え、同様に、リソース管理サーバB 14310も、リソース管理Agent(リソース管理エージェント)14311とリソース管理Manager(リソース管理マネジャ)14301との双方を備えている。
下位層のリソース管理サーバA 14210のリソース管理Manager(リソース管理マネジャ)14201は、管理ネットワークA 14420を介して、管理対象のネットワーク装置として、装置A1 14500と装置A2 14600とを対象にしてリソース管理を実施する。このため、装置A1 14500と装置A2 14600とには、前述の図3に示した装置An 30n0の場合と同様、それぞれ、リソース管理Agent(リソース管理エージェント)14510とリソース管理Agent(リソース管理エージェント)14610とを備えている。
同様に、下位層のリソース管理サーバB 14700のリソース管理Manager(リソース管理マネジャ)14301は、管理ネットワークB 14430を介して、装置B1 14700と装置B2 14800を対象にしてリソース管理を実施する。このため、装置B1 14700と装置B2 14800とには、前述の図3に示した装置An 30n0の場合と同様、それぞれ、リソース管理Agent(リソース管理エージェント)14710とリソース管理Agent(リソース管理エージェント)14810とを備えている。
つまり、最上位のリソース管理サーバC 14100の管理ドメインは、リソース管理サーバA 14210のリソース管理Agent(リソース管理エージェント)14211とリソース管理サーバB 14310のリソース管理Agent(リソース管理エージェント)14311となる。
下位層のリソース管理サーバA 14210の管理ドメインは、装置A1 14500のリソース管理Agent(リソース管理エージェント)14510と装置A2 14600のリソース管理Agent(リソース管理エージェント)14610となり、下位層のリソース管理サーバB 14310の管理ドメインは、装置B1 14700のリソース管理Agent(リソース管理エージェント)14710と装置B2 14800のリソース管理Agent(リソース管理エージェント)14810となる。
かくのごとく、多階層のネットワークトポロジーにおけるリソース管理を行う場合、ネットワーク全体のリソースを管理するリソース管理サーバを多階層(図14に示す例では2階層)に分散配置した構成とし、最上位のリソース管理サーバ以外の各階層のリソース管理サーバについては、リソース管理Agent(リソース管理エージェント)とリソース管理Manager(リソース管理マネジャ)との双方を具備することにより、多階層のネットワークトポロジーにおいても、それぞれの階層ごとのリソース管理を迅速かつ確実に実施することが可能になる。
以上、本発明の好適な実施形態の構成を説明した。しかし、かかる実施形態は、本発明の単なる例示に過ぎず、何ら本発明を限定するものではないことに留意されたい。本発明の要旨を逸脱することなく、特定用途に応じて種々の変形変更が可能であることが、当業者には容易に理解できよう。