(58)【調査した分野】(Int.Cl.,DB名)
要求パラメータを用いた計算式である要求条件式と、その要求条件式を満たすときに起動される要求アクションとを対応付ける要求コンフィグの入力を受け付け、入力された前記要求コンフィグをコンフィグ管理部に記憶する要求入力部と、
前記要求パラメータとして指定されたデバイスの計測情報、または、1つ以上の前記デバイスを収容するサーバの計測情報を取得し、その取得した計測情報を計測管理データベースに記憶する計測情報処理部と、
前記計測管理データベースの計測情報が前記要求条件式を満たすか否かを判定し、前記要求条件式を満たすと判定したときに、対応する前記要求アクションを起動する計測制御部と、
起動された前記要求アクションに従った設定情報を前記デバイスまたは前記サーバに設定する装置設定部とを有することを特徴とする
ネットワーク管理装置。
【発明の概要】
【発明が解決しようとする課題】
【0008】
図20は、計測対象ネットワークが大規模化したときの構成図である。このような大規模ネットワークの場合、多くのデバイスDが地理的に分散しているので、遠方のデバイスDからのデータがコレクタ93に届くまで遅延することもある。
このような場合、デバイスDからコレクタ93までの遅延時間を改善するように、保守者はコントローラを操作して、デバイスDの接続先となるコレクタ93を変更する操作を行う。
【0009】
一方、別の保守者は、コントローラ91からデータベース92へクエリを送信してから、その応答までにかかる時間であるTAT(Turn Around Time)を短縮することを最優先にすることも考えられる。
このように、保守者ごとに重視するパラメータは様々であるので、コントローラ91が可視化した計測情報を把握し、どのように計測対象ネットワークを改善していくかを判断し、デバイスDにどのような制御コマンドを発行するかという具体的なネットワーク管理作業は、保守者ごとに手作業で行われていた。しかし、計測対象ネットワークが大規模化することに伴い、このネットワーク管理作業の負担が大きくなっていた。
【0010】
非特許文献1や特許文献1などの従来の技術では、各デバイスDからコントローラ91までの計測情報の収集についての記載はあるが、その後の集められた計測情報をもとにして具体的にどのようなネットワーク管理作業を行うかという情報活用面は論じられていない。
【0011】
そこで、本発明は、ユーザが重視するパラメータに即した柔軟性の高いネットワーク管理を実現することを、主な課題とする。
【課題を解決するための手段】
【0012】
前記課題を解決するために、本発明のネットワーク管理装置は、以下の特徴を有する。
本発明は、要求パラメータを用いた計算式である要求条件式と、その要求条件式を満たすときに起動される要求アクションとを対応付ける要求コンフィグの入力を受け付け、入力された前記要求コンフィグをコンフィグ管理部に記憶する要求入力部と、
前記要求パラメータとして指定されたデバイスの計測情報、または、1つ以上の前記デバイスを収容するサーバの計測情報を取得し、その取得した計測情報を計測管理データベースに記憶する計測情報処理部と、
前記計測管理データベースの計測情報が前記要求条件式を満たすか否かを判定し、前記要求条件式を満たすと判定したときに、対応する前記要求アクションを起動する計測制御部と、
起動された前記要求アクションに従った設定情報を前記デバイスまたは前記サーバに設定する装置設定部とを有することを特徴とする。
【0013】
これにより、要求パラメータである計測情報が要求条件式を満たす監視プロセスにより、要求アクションに従った設定情報が自動的にデバイスまたはサーバに設定される。よって、ユーザが重視する要求パラメータに即した柔軟性の高いネットワーク管理を実現することができる。
【0014】
本発明は、前記計測制御部が、前記要求アクションとして、前記サーバ間での負荷の平準化を行う平準化部を有しており、
前記要求入力部が、前記要求パラメータとして指定された計測情報が第1閾値を超過するときに、前記平準化部を呼び出す旨の前記要求コンフィグを前記コンフィグ管理部に記憶することを特徴とする。
【0015】
これにより、保守者が手作業でサーバ間での負荷の平準化を行う必要がなくなり、最新の計測情報と要求コンフィグとに応じて自動的に平準化処理が起動する。
【0016】
本発明は、前記計測制御部が、前記要求アクションとして、新たな前記サーバの増設に対応するスケールアウト部を有しており、
前記要求入力部が、前記平準化部による負荷の平準化を行った後でも前記要求パラメータとして指定された計測情報が前記第1閾値を超過するときに、前記スケールアウト部を呼び出す旨の前記要求コンフィグを前記コンフィグ管理部に記憶することを特徴とする。
【0017】
これにより、保守者が手作業でスケールアウトを設定する必要がなくなり、最新の計測情報と要求コンフィグとに応じて自動的にスケールアウト処理が起動する。
【0018】
本発明は、前記計測制御部が、前記要求アクションとして、既存の前記サーバの減設に対応するスケールイン部を有しており、
前記要求入力部が、前記要求パラメータとして指定された計測情報が第2閾値を下回るときに、前記スケールイン部を呼び出す旨の前記要求コンフィグを前記コンフィグ管理部に記憶することを特徴とする。
【0019】
これにより、保守者が手作業でスケールインを設定する必要がなくなり、最新の計測情報と要求コンフィグとに応じて自動的にスケールイン処理が起動する。
【発明の効果】
【0020】
本発明によれば、ユーザが重視するパラメータに即した柔軟性の高いネットワーク管理を実現することができる。
【発明を実施するための形態】
【0022】
以下、本発明の一実施形態について、図面を参照して詳細に説明する。
【0023】
図1は、計測管理システムの構成図である。計測管理システムは、コントローラ(ネットワーク管理装置)1と、そのコントローラ1が管理するネットワークシステムとで構成される。管理対象となるネットワークシステムは、データベース2とコレクタ3とを備えるサーバ4と、ネットワーク機器であるデバイス5とで構成される。以下、個々のデバイス5には、「D1」などのデバイスIDが割り当てられているものとする。
図1のデータベース2と、コレクタ3と、サーバ4と、デバイス5とは、それぞれ、
図19のデータベース92と、コレクタ93と、サーバ94と、デバイスDと同じ機能を有する。また、データベース2と、コレクタ3と、サーバ4と、デバイス5とに対して、それぞれ、データベースIDと、コレクタIDと、サーバIDと、デバイスIDとが識別子として割り当てられる。
【0024】
コントローラ1は、CPU(Central Processing Unit)と、メモリと、ハードディスク、不揮発メモリ、SSD(solid state drive)などで例示される記憶手段(記憶部)と、ネットワークインタフェースとを有するコンピュータとして構成される。
このコンピュータは、CPUが、メモリ上に読み込んだプログラム(アプリケーションや、その略のアプリとも呼ばれる)を実行することにより、各処理部により構成される制御部(制御手段)を動作させる。
【0025】
コントローラ1は、計測情報入出力部11と、要求入出力部(要求入力部)12と、計測情報処理部13と、計測管理データベース14と、計測制御部15と、装置設定部16と、コンフィグ管理部17とを有する。
計測情報入出力部11は、サーバ4から計測情報の入力を受け、その計測情報を計測情報処理部13に通知する。また、計測情報入出力部11は、計測制御部15からの指示に従い、サーバ4に対して計測情報の転送先を指定する信号を出力する。
要求入出力部12は、保守者からの要求を受け、その要求を要求コンフィグとしてコンフィグ管理部17に書き出す。
【0026】
図2は、コンフィグ管理部17が管理する要求コンフィグの一例を示すテーブルである。
要求コンフィグは、要求条件式と要求アクションとの組み合わせが、1組以上優先順序づけられた設定情報である。
要求条件式は、要求パラメータの計測結果が予め設定された閾値を超えたか否かを判定する式である。または、要求条件式として、要求パラメータ以外の追加パラメータも含めた任意のロジックを定義してもよい。
要求パラメータは、保守者が監視対象として重視するパラメータである。なお、要求パラメータの種別だけでなく、その要求パラメータごとの監視周期を指定してもよい。要求アクションは、要求条件式を満たしたとき(閾値を超えたと判定されたとき)に、実行される計測制御部15のアクション(処理)である。
【0027】
例えば、
図2のコンフィグ管理部17では、平準化、スケールアウト、スケールインの順に、3つの要求アクションがそれぞれの要求条件式に対応付けて登録されている。以下の(1)〜(3)の順に、各要求アクションが起動する。
(1)要求条件式「要求パラメータA>第1閾値」を満たしたときに、平準化の要求アクションが起動する。
(2)要求条件式「平準化の要求アクションが失敗」を満たしたときに、スケールアウトの要求アクションが起動する。
(3)要求条件式「要求パラメータA<第2閾値」を満たしたときに、スケールインの要求アクションが起動する。
【0028】
図1に戻り、本実施形態では、要求アクションを実行する処理部の一例として、平準化部15aと、スケールアウト部15bと、スケールイン部15cとをそれぞれ計測制御部15に備える。
また、要求入出力部12は、要求条件式を満たしたときに、その要求条件式に対応する要求アクションを保守者に通知し(レコメンドし)、保守者からのレコメンドへの了解を受けたときに、要求アクションを実行してもよい。
【0029】
例えば、コントローラ1とデータベース2との間のTAT(Turn Around Time)を要求パラメータとして、要求条件式としてTATが所定閾値以上となるときに、平準化部15aを呼び出す要求コンフィグを用いることで、コントローラ1は、欠落なくネットワーク情報が得られる。
または、サーバ4の使用リソース量を要求パラメータとして、要求条件式として使用リソース量が所定閾値以上となるときにスケールアウト部15bを呼び出す一方で、使用リソース量が所定閾値以下となるときにスケールイン部15cを呼び出す要求コンフィグを用いることで、必要最低限のリソースで情報収集が可能となる。
【0030】
計測情報処理部13は、計測情報入出力部11を介して、サーバ4から受信した計測情報を加工して、その加工結果を計測管理データベース14に書き出す。加工処理は、例えば、計測情報のフォーマット統一化処理や、計測情報(デバイス5のIFカウンタ情報など)から要求パラメータ(トラヒック量など)の計算処理である。
計測管理データベース14は、管理対象となるネットワークシステムのトポロジ情報(デバイス5とサーバ4との接続関係)に加え、ネットワークシステムの各装置についての要求パラメータの計測結果を「属性」として保持する。そのため、要求入出力部12は、保守者から入力されたトポロジ情報を、計測管理データベース14に登録しておく。
【0031】
計測制御部15は、計測管理データベース14に登録された各装置について、コンフィグ管理部17から読み出した要求パラメータを監視する。そして、監視結果の要求パラメータが要求条件式を満たしたとき、計測制御部15は、対応する要求アクションの種別に応じた処理部(平準化部15aと、スケールアウト部15bと、スケールイン部15c)を呼び出す。この呼び出しにより、装置設定部16は、CLI(Command Line Interface)やNetconfなどの各種設定ツールを介して、デバイス5やサーバ4にネットワーク制御を実行することで、要求パラメータの改善を試みる。
なお、この3種類の処理部は、計測制御部15から呼び出すだけでなく、個々を独立に要求入出力部12を介して保守者から直接操作可能としてもよい。これにより、監視プロセス外からのリソース制御を可能とする。
【0032】
図3は、計測管理システムの管理対象となるネットワークシステムの構成図である。
1台のコントローラ1が管理するネットワークシステムは、3台のデータベース2(2a〜2c)と、4台のコレクタ3(3a〜3d)とを備える3台のサーバ4(4a〜4c)が、10台のデバイス5(D1〜D10)からそれぞれ計測情報を収集する。
コントローラ1と3台のデータベース2(2a〜2c)それぞれとの間のTATは、
図3に示したとおりである。
【0033】
図4は、
図3のネットワークシステムを対象とした計測管理データベース14の構成図である。
計測管理データベース14には、
図3のネットワークシステムのトポロジ情報が、レコード内の対応付けとして記載されている。例えば、データベース2aと、コレクタ3aと、デバイス5(D1,D2)とを収容するサーバ4aの情報が、計測管理データベース14の第1行に登録されている。なお、装置ごとの識別子として、IDと併せて、装置のアドレス情報(A:Address)と、装置のポート番号(P:Port)とを「:」で区切った列を、「A:P」として計測管理データベース14に設けている。
さらに、計測管理データベース14には、データベース2ごとの属性と、コレクタ3ごとの属性と、デバイス5ごとの属性も要求パラメータとして格納される。
【0034】
図5は、コントローラ1の初期設定処理を示すフローチャートである。
S101として、要求入出力部12は、要求パラメータと、要求条件式と、要求アクションとを対応付けた要求コンフィグの入力を受け付け、その要求コンフィグをコンフィグ管理部17に登録する。
S102として、計測情報入出力部11は、コンフィグ管理部17から要求コンフィグを読み込み、要求コンフィグの順序に従って1つずつ選択するループを開始する。
S103として、計測情報入出力部11は、データベース2にSQLなどを用いて問い合わせることで、ループで選択中の要求コンフィグの要求パラメータに関する情報を取得する。
S104として、計測情報処理部13は、S103で取得した情報からフォーマット統一化処理などにより計測情報を生成する。
S105として、計測情報処理部13は、S104で生成した計測情報を、計測管理データベース14の属性として格納する。
S106として、計測情報入出力部11は、S102からの要求コンフィグのループを終了する。
【0035】
図6は、コントローラ1によるネットワークシステムの監視処理を示すフローチャートである。
S111として、要求入出力部12は、S101で入力された要求コンフィグをコンフィグ管理部17から読み込む。
S112として、計測制御部15は、S111で読み込んだ要求コンフィグについて、所定の監視周期にて監視プロセスを動作させるループを開始する。
S113として、計測制御部15は、ループ中の要求コンフィグの要求パラメータ(S105で格納された計測管理データベース14の属性)が要求コンフィグの要求条件式を満たすか否かを判定する。S113でYesならS114に進み、NoならS115に進む。
S114として、計測制御部15は、要求条件式を満たした要求コンフィグについて、対応する要求アクションを実行する。
S115として、計測制御部15は、S112からの要求コンフィグのループを終了する。
【0036】
以下、
図7〜
図10を参照して、平準化部15aの詳細を説明する。
図7は、サーバ4間の平準化の概要を示す説明図である。
平準化の前では、2台のコレクタ3が存在するにもかかわらず、コレクタ3aだけに2台のデバイス5(D1,D2)が収容されており、負荷が偏っている。
そして、平準化部15aによる宛先変更指示を契機に、デバイス5(D2)の収容先をコレクタ3aからコレクタ3bに変更する。これにより、2台のコレクタ3それぞれに1台ずつのデバイス5が収容される状態となり、負荷が平準化された。このように、装置割当の平準化は特に、TATの平準化やトラヒック量の平準化に寄与する。
【0037】
図8は、デバイス5とコレクタ3との間の応答時間(Time)を、平準化により改善する処理を示す説明図である。
図9は、
図8の平準化による改善効果を示す計測管理データベース14の構成図である。
まず、コンフィグ管理部17には、要求条件式「Time≧3」→要求アクション「平準化」という要求コンフィグが登録されているとする。
【0038】
第1段階(
図9では、計測管理データベース14a1)では、4台のデバイス5(D1〜D4)とコレクタ3との間の応答時間が、順に、2,5,1,2となっており、要求条件式の閾値=3を超過するデバイス5(D2)が存在する。Timeの計測方法は、例えば、デバイス5とコレクタ3との間でpingを実行する方法がある。
【0039】
第2段階(
図9では、計測管理データベース14a2)では、デバイス5(D2)の収容先がコレクタ3bからコレクタ3aに変更されたことで、デバイス5(D2)のTimeが2に改善した。なお、「Timeが最低となるようなサーバ4を選択」という平準化ポリシが平準化部15aに設定されていることで、コレクタ3aを含むサーバ4aが平準化ポリシに適合する平準化先サーバとして選択された。これにより、全てのデバイス5が要求条件式「Time≧3」に抵触しない平準化された安定状態となる。
【0040】
図10は、平準化部15aによる平準化処理を示すフローチャートである。
S201として、平準化部15aは、要求条件式を満たした(閾値を超過した)サーバIDのリストを抽出する。
S202として、平準化部15aは、S201のリストに含まれるサーバIDの平準化元サーバを順に選択するループを開始する。
S203として、平準化部15aは、平準化元サーバに対する平準化先サーバの候補を抽出する。候補選定アルゴリズムは、例えば、装置ID順などである。
S204として、平準化部15aは、S203の候補から所定の基準により、平準化先サーバを選択する。所定の基準とは、例えば、要求パラメータが要求条件式の閾値から最も遠いサーバなどである。
S205として、平準化部15aは、平準化元サーバから平準化先サーバにデバイス5の収容先を変更(再割り当て)する。
【0041】
S206として、平準化部15aは、平準化先サーバの要求パラメータを計測する。
S207として、平準化部15aは、S206の計測結果が要求条件式の閾値を超過しているか否かを判定する。S207でYesならS208に進み、NoならS209に進む。
S208として、平準化部15aは、平準化先サーバなしと判断し、異常終了する。
S209として、平準化部15aは、平準化元サーバの要求パラメータを計測する。
S210として、平準化部15aは、S209の計測結果が要求条件式の閾値を超過しているか否かを判定する。つまり、平準化元サーバの要求パラメータが改善されているか否かがS207で判定される。S210でYesならS204に戻り、NoならS211のループを抜けて、正常に終了する。
S211として、平準化部15aは、S202からの平準化元サーバのループを終了する。
なお、平準化部15aは、要求パラメータの計測処理(S206,S209)だけでなく、要求条件式の判断に必要な追加の情報計測も適宜行ってもよい。
【0042】
以下、
図11〜
図14を参照して、スケールアウト部15bの詳細を説明する。
図11は、サーバ4のスケールアウト(増設)の概要を示す説明図である。
コントローラ1は要求パラメータが要求条件式を満たすときに、データベース2b、コレクタ3b、または、サーバ4bの増設を保守者に通知(レコメンド)する。保守者からの指示(レコメンドに同意)を受けたコントローラ1は、スケールアウト部15bを呼び出すことで、既存のサーバ4aに対して新たに増設されたサーバ4bを活用する。
例えば、2台のデバイス5(D1,D2)を収容するサーバ4aの負荷が高くなってしまった場合、コントローラ1は、新たにスケールアウトされたサーバ4bに1台のデバイス5(D2)を再割当(平準化)することで、負荷分散する。このように、スケールアウト部15bは、どのサーバ4にも平準化できないほどサーバ4のリソースが枯渇しているときなどに呼び出される。
【0043】
図12は、データベース2aとコントローラ1との間のTATを、スケールアウトにより改善する処理を示す説明図である。
なお、TATの計測処理はデータベース2aへSQLのクエリを投入する際に、オプション指定などで起動される。そのTATの計測結果は計測情報処理部13を介して、計測管理データベース14へ格納される。
まず、コンフィグ管理部17には、以下の要求コンフィグが登録されているとする。
(第1優先順序)=要求条件式「TAT≧0.8」→要求アクション「平準化」
(第2優先順序)=要求条件式「平準化結果=false」→要求アクション「スケールアウト」
つまり、TATが0.8以上のデータベース2aを対象に平準化を行い、その平準化が失敗したときには、スケールアウトを行うという2段階の要求コンフィグがコンフィグ管理部17に登録される。要求パラメータ=TATであり、このTATの計測結果が計測管理データベース14に属性として登録される。
【0044】
まず、(第1優先順序)により、TATが1であるデータベース2aが平準化元サーバとして選択されるが、その平準化先サーバが存在しない(
図10のS208)場合を想定する。このとき、(第2優先順序)により、スケールアウト部15bが呼び出される。スケールアウト部15bは、新たに増設されたサーバ4b(データベース2b、コレクタ3b)を認識する。
そして、平準化部15aは、再度の(第1優先順序)により、TAT≧0.8であったコレクタ3aが収容していたデバイス5(D1)をコレクタ3bに変更することで、データベース2aの負荷を緩和する。これにより、データベース2aのTATが閾値未満(0.7)に改善し、かつ、データベース2bのTATも閾値未満(0.3)となる。
【0045】
図13は、
図12のスケールアウトによる改善効果を示す計測管理データベース14の構成図である。
第1段階(計測管理データベース14b1)では、
図5の初期設定処理を終え、
図6の監視処理を開始した状態である。計測制御部15は、要求条件式を満たす(閾値0.8を超過する)データベース2(ID=1)を発見する(S113,Yes)が、その平準化先サーバが存在しない。
第2段階(計測管理データベース14b2)では、スケールアウト部15bがデータベース2(ID=2)の増設を検知した状態である。増設直後ではTATは未測定のため、TATの属性値には「null(未測定)」が格納される。
第3段階(計測管理データベース14b3)では、平準化部15aがデバイス5(ID=D1)の再割当を行った状態である。
第4段階(計測管理データベース14b4)では、計測情報処理部13が2台のデータベース2からそれぞれTATの再計測結果を受信し、計測管理データベース14の属性を更新した状態である。これにより、データベース2aのTATが閾値未満(0.7)に改善し、かつ、データベース2bのTATも閾値未満(0.3)となる。
【0046】
図14は、スケールアウト部15bによるスケールアウト処理を示すフローチャートである。
S301として、スケールアウト部15bが保守者から手動で起動されたか否かを判定する。S114で計測制御部15が要求アクションからスケールアウト部15bを起動した場合には、S301でNoとなる。S301でYesならS303に進み、NoならS302に進む。
S302として、要求入出力部12は、要求コンフィグに従い、サーバ4の増設をレコメンドする旨を保守者に通知する。
S303として、要求入出力部12は、保守者からサーバ4の増設完了が入力されたか否かを判定する。S303でYesならS304に進み、NoならS303を繰り返す。
S304として、スケールアウト部15bは、S303で入力された新規のサーバ4に関する情報(トポロジ情報、計測情報など)を、計測管理データベース14に書き出す。これにより、計測制御部15は、要求コンフィグに従った要求パラメータの監視処理を再開する。
【0047】
以下、
図15〜
図18を参照して、スケールイン部15cの詳細を説明する。
図15は、サーバ4のスケールイン(減設)の概要を示す説明図である。スケールイン部15cは、2台のサーバ4がともに1台のデバイス5しか収容しておらず、負荷に余裕があることをもとに、1台のサーバ4を減設する旨のレコメンドを保守者に通知する。
スケールイン部15cは、保守者からの指示(レコメンドへの同意)を得て、サーバ4bを縮退させ、サーバ4aに統合する旨のスケールインを実行する。そのため、まず、サーバ4bが収容するデバイス5(D2)をサーバ4aに変更する(宛先変更指示)。そして、サーバ4bが収容するデバイス5がなくなった時点で、計測制御部15は、サーバ4bに関する情報を計測管理データベース14から削除する。さらに、保守者は、サーバ4bを減設する。
これにより、1台のサーバ4aが2台のデバイス5(D1,D2)を収容することで、サーバ4の余剰リソースを削除した効率的な構成に遷移することができる。
【0048】
図16は、コレクタ3が故障したときに、スケールイン(減設)によりフェイルオーバ対応する処理を示す説明図である。
第1段階として、コレクタ3aに故障が発生したとする。このとき、コレクタ3aは4台のデバイス5(D1〜D4)を収容し、コレクタ3bは4台のデバイス5(D5〜D8)を収容していた。
第2段階として、スケールイン部15cは、要求入出力部12を介して得た保守者からの手動指示に従い、コレクタ3aとデータベース2aとを計測管理データベース14から削除する。これにより、4台のデバイス5(D1〜D4)は、収容先が一時的になくなることで、平準化部15aを起動する。
【0049】
図17は、
図16に続き、フェイルオーバ対応する処理を示す説明図である。
第3段階として、平準化部15aは、4台のデバイス5(D1〜D4)の新たな収容先(平準化先サーバ)を検索する。ここで、例えばサーバ4が収容するデバイス5の数を平準化するポリシに従い、サーバ4bが平準化先サーバとして選択される。サーバ4bには8台のデバイス5(D1〜D8)が収容され、それぞれ稼働を再開した。
第4段階として、保守者は、手動にてサーバ4aを撤去する。
【0050】
図18は、スケールイン部15cによるスケールイン処理を示すフローチャートである。
S401として、スケールイン部15cが保守者から手動で起動されたか否かを判定する。S114で計測制御部15が要求アクションからスケールイン部15cを起動した場合には、S401でNoとなる。S401でYesならS403に進み、NoならS402に進む。
S402として、要求入出力部12は、要求コンフィグに従い、サーバ4の減設をレコメンドする旨を保守者に通知する。
S403として、要求入出力部12は、保守者からサーバ4の減設要求が入力されたか否かを判定する。なお、減設要求には、減設対象のサーバID(平準化元サーバ)に加えて、新たな収容先(平準化先サーバ)を選択するときのポリシも併せて含まれている。S403でYesならS404に進み、NoならS403を繰り返す。
S404として、平準化部15aは、S403で入力されたポリシに従って、装置割当を平準化する(
図10を呼び出す)。
S405として、スケールイン部15cは、S403で入力された減設要求に関する情報(平準化元サーバ→平準化先サーバへのトポロジ情報の変更や、平準化元サーバの削除など)を、計測管理データベース14に書き出す。
【0051】
以上説明した本実施形態では、コントローラ1によるネットワーク計測管理技術を説明した。コントローラ1は、コンフィグ管理部17にて保守者から入力された要求コンフィグを管理し、要求コンフィグに記載の要求パラメータを監視した結果を計測管理データベース14の属性として書き出すことで、各種リソース(データベース2、コレクタ3、デバイス5)を管理する。
そして、計測管理データベース14の属性が要求条件式を満たしたときに、要求アクションを起動させる。要求アクションとして、平準化部15a、スケールアウト部15b、および、スケールイン部15cをそれぞれ実行させることで、要求パラメータの改善を可能とする。この要求パラメータは、保守者から要求入出力部12を介して適宜設定できるので、各保守者が重視する要求パラメータに対して柔軟に対応できる。
【0052】
なお、本実施形態においては、コントローラ1が管理するネットワークシステムとして、
図3に示すような3台のデータベース2と、4台のコレクタ3と、10台のデバイス5とに限定されず、任意の台数のリソースを扱ってもよい。
また、本実施形態においては、一般的なコンピュータのハードウェア資源を、コントローラ1の各手段として動作させるプログラムによって実現することができる。そして、このプログラムは、通信回線を介して配布したり、CD−ROM等の記録媒体に記録して配布したりすることも可能である。