(57)【要約】【課題】異なる性能のスイッチを含むネットワークのリソースを平準化できるネットワークリソース管理装置を提供する。【解決手段】ネットワーク内に配置された各スイッチのリソースを管理するネットワークリソース管理装置１００であって、各スイッチの使用率および各スイッチを流れるフローからその各スイッチの性能を推定する性能推定部１０と、各スイッチの第一の負荷を算出する第一負荷算出部２０と、算出された第一の負荷が予め定めた閾値よりも高いスイッチである対象スイッチが接続されるネットワークの構成を変更するための候補を決定する構成変更候補決定部３０と、候補として決定された変更後のネットワークの構成に基づいて、推定された性能での各スイッチの第二の負荷を算出する第二負荷算出部４０とを備えている。【選択図】図１
2018148382.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク内に配置された各スイッチのリソースを管理するネットワークリソース管理装置であって、
前記各スイッチの使用率および各スイッチを流れるフローから当該各スイッチの性能を推定する性能推定部と、
前記各スイッチの第一の負荷を算出する第一負荷算出部と、
算出された第一の負荷が予め定めた閾値よりも高いスイッチである対象スイッチが接続されるネットワークの構成を変更するための候補を決定する構成変更候補決定部と、
前記候補として決定された変更後のネットワークの構成に基づいて、推定された前記性能での各スイッチの第二の負荷を算出する第二負荷算出部とを備えた
ことを特徴とするネットワークリソース管理装置。
【請求項２】
各スイッチおよび当該スイッチに接続されるノードに優先度が定められ、
第一負荷算出部は、前記優先度が高いほど、第一の負荷を高く算出する
請求項１記載のネットワークリソース管理装置。
【請求項３】
構成変更候補決定部は、ネットワークの構成を変更する候補として、対象スイッチの下位全てのスイッチおよび当該対象スイッチの上位のスイッチを選択し、
第二負荷算出部は、選択されたネットワークの構成に基づいて算出された第二の負荷が予め定めた負荷を下回るか否か判断する
請求項１または請求項２記載のネットワークリソース管理装置。
【請求項４】
構成変更候補決定部は、第二負荷算出部が算出した各スイッチの第二の負荷が予め定めた負荷を下回る構成が存在しない場合、ネットワークの構成を変更する候補として、さらに上位のスイッチおよび当該スイッチ配下のスイッチを選択する
請求項３記載のネットワークリソース管理装置。
【請求項５】
第一負荷算出部は、管理情報ベースにより取得した負荷を、各スイッチの第一の負荷として使用する
請求項１から請求項４のうちのいずれか１項に記載のネットワークリソース管理装置。
【請求項６】
ネットワーク内に配置された各スイッチのリソースを管理するネットワークリソース管理方法であって、
前記各スイッチの使用率および各スイッチを流れるフローから当該各スイッチの性能を推定し、
前記各スイッチの第一の負荷を算出し、
算出された負荷が予め定めた閾値よりも高いスイッチである対象スイッチが接続されるネットワークの構成を変更するための候補を決定し、
前記候補として決定された変更後のネットワークの構成に基づいて、推定された前記性能での各スイッチの第二の負荷を算出する
ことを特徴とするネットワークリソース管理方法。
【請求項７】
各スイッチおよび当該スイッチに接続されるノードに優先度が定められ、
前記優先度が高いほど、第一の負荷を高く算出する
請求項６記載のネットワークリソース管理方法。
【請求項８】
ネットワーク内に配置された各スイッチのリソースを管理するコンピュータに適用されるネットワークリソース管理プログラムであって、
前記コンピュータに、
前記各スイッチの使用率および各スイッチを流れるフローから当該各スイッチの性能を推定する性能推定処理、
前記各スイッチの第一の負荷を算出する第一負荷算出処理、
算出された第一の負荷が予め定めた閾値よりも高いスイッチである対象スイッチが接続されるネットワークの構成を変更するための候補を決定する構成変更候補決定処理、および、
前記候補として決定された変更後のネットワークの構成に基づいて、推定された前記性能での各スイッチの第二の負荷を算出する第二負荷算出処理
を実行させるためのネットワークリソース管理プログラム。
【請求項９】
各スイッチおよび当該スイッチに接続されるノードに優先度が定められ、
コンピュータに、
第一負荷算出処理で、前記優先度が高いほど、第一の負荷を高く算出させる
請求項８記載のネットワークリソース管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のスイッチを含むネットワークのリソースを管理するネットワークリソース管理装置、ネットワークリソース管理方法およびネットワークリソース管理プログラムに関する。
【背景技術】
【０００２】
あるシステムにおいて、ハードウェアリソースの枯渇や、偏りの発生を回避することは困難である。そこで、通常、システム管理者がリソース状況を把握し、メンテナンス期間を設けて構成の変更やハードウェアリソースの増強などを行っている。
【０００３】
これに対し、仮想環境の場合、ＣＰＵ（Central Processing Unit ）やメモリのリソースに応じてＶＭ（Virtual Machine ）を移動させる技術が存在する。そのため、特定のＶＭが高負荷になっていたとしても、ある程度フレキシブルに構成を変更し、高負荷状態を解決することができる。
【０００４】
特許文献１には、仮想マシン間の通信品質を保証するように、各仮想マシンを物理サーバに配置する仮想マシン配置装置が記載されている。特許文献１に記載された仮想マシン配置装置は、各仮想マシン間の通信が通過するスイッチが扱う通信量の総和をスイッチごとに収集し、その総和がスイッチの通信容量を超過しないように、仮想マシンの配置先となる物理サーバを決定する。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１５−２２５５６０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
一方、ネットワークリソースに関しては、ＣＰＵやメモリリソースと異なり、ＶＭを動作させているＶＭＭ（Virtual Machine Monitor ）のリソースのみを監視してもリソースの枯渇を解決できないケースが多々存在する。ＣＰＵやメモリは、ＶＭＭに完全に依存するが、ネットワークリソースは、様々な機器を通る、いわば通路のようなものである。そのため、ある特定の機器に限定した局所的な判断を行っても、本当の原因になっているポイントがわからず、誤った判断を行ってしまうことがある。
【０００７】
そのため、ネットワーク全体を把握したうえでリソースの判断を行い、動的に設定の変更を行う必要がある。しかし、ネットワークを繋ぐスイッチの性能は一定ではない。そのため、スイッチのハードウェアリソースの使用率（すなわち、負荷率）を把握できても、ネットワークの構成を変更した場合に、どのようにリソースが配分されるか把握することは難しい。
【０００８】
例えば、あるシステムにおいて、ネットワークを管理するコアスイッチ、及びコアスイッチに接続されるエッジスイッチが存在し、エッジスイッチにはサービスを提供するサーバ及び業務用ＰＣ（Personal computer ）が接続されて動作している場面を想定する。ここで、サーバ及び業務用ＰＣは、ＦＡＴ−ＰＣ、またはＶＭとして存在しているとする。
【０００９】
一般に、スイッチの性能は同一ではなく、各スイッチの間には性能差が存在している。また、スイッチに接続されているサーバ、及び業務用ＰＣの数も一定ではない。さらに、スイッチを流れるトラフィック量も同一ではなく、偏りが存在する。
【００１０】
このため、ネットワーク全体のトラフィック量が全スイッチの収容能力を超えるほどではないが、局所的な観点では、特定のスイッチに負荷が偏ることにより、サービス及び業務に影響を及ぼすことがある。
【００１１】
このような状況が発生すると、サービス利用者もしくはネットワーク内のユーザからの通知、または、ネットワーク監視ソフトウェアなどの通知により、ネットワーク負荷の偏りが発生していることが認識される。この状況を解消するため、ネットワーク管理者は、手動でネットワークの構成を変える、または、ネットワークリソースを大量に使用している端末を別のスイッチに接続するなどの対処が必要になる。
【００１２】
この場合の問題点は、大きくわけて２つ存在する。１つ目は、ネットワーク構成の見直しに対する設計および評価が必要になるため、即時性が求められる緊急事態であっても対応が困難なことである。２つ目は、スイッチの構成の変更に必要なダウンタイムが発生するため、ユーザへの影響が発生することである。対応が特に困難なのは１つ目の問題点である。例えば、複雑なネットワーク構成の場合、局所的な視点での設定変更では問題を解決できない可能性が高い。
【００１３】
具体的には、ネットワークが大きくなればなるほど確認すべき範囲が増大し、複雑な設計が必要になる。例えば、あるスイッチの影響を把握するためには、エッジスイッチから上位のスイッチを辿り、そのスイッチに接続される下位のスイッチ及びその下位のスイッチを辿らなければならない、という現象が起こり得る。
【００１４】
全てのスイッチが同一機種であれば、単純にハードウェアリソースの使用率（負荷率）を確認して、ネットワーク構成を変更する、すなわち、負荷率を加算したり減算したりすれば、リソースの問題を解決できる。しかし、実際のネットワークでは、スイッチごとに性能の異なる場合がほとんどである。その場合、リソースの配分は、それぞれのスイッチの性能差を考慮して計算される必要があるため、問題を解決するためには、膨大な計算が必要になる。
【００１５】
現実的には、特定のサーバ及びそのサーバが接続されているエッジスイッチまたはそのエッジスイッチより上位のスイッチを１つ確認するのが精一杯と言える。そのため、例えば、エッジスイッチから上位のスイッチ、さらに上位のスイッチ、と範囲を広げながらネットワークの負荷率を計算して、ネットワーク構成をスポット的に変更するといった運用は行われていないのが実情である。
【００１６】
また、特許文献１に記載された仮想マシン配置装置は、各スイッチの通信容量を把握しておかなければならない。また、上述するように、ネットワーク上には異なる性能のスイッチが廃止されることが一般的である。そのため、特許文献１に記載されているように、通信容量を超過しないようにリソースを配分するだけでは、性能の異なる各スイッチのリソースを適切に配分することは困難である。そのため、作業負荷を低減し適切にリソースを配分するためには、自律的にネットワークリソースを平準化できることが好ましい。
【００１７】
そこで、本発明は、異なる性能のスイッチを含むネットワークのリソースを平準化できるネットワークリソース管理装置、ネットワークリソース管理方法およびネットワークリソース管理プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１８】
本発明によるネットワークリソース管理装置は、ネットワーク内に配置された各スイッチのリソースを管理するネットワークリソース管理装置であって、各スイッチの使用率および各スイッチを流れるフローからその各スイッチの性能を推定する性能推定部と、各スイッチの第一の負荷を算出する第一負荷算出部と、算出された第一の負荷が予め定めた閾値よりも高いスイッチである対象スイッチが接続されるネットワークの構成を変更するための候補を決定する構成変更候補決定部と、候補として決定された変更後のネットワークの構成に基づいて、推定された性能での各スイッチの第二の負荷を算出する第二負荷算出部とを備えたことを特徴とする。
【００１９】
本発明によるネットワークリソース管理方法は、ネットワーク内に配置された各スイッチのリソースを管理するネットワークリソース管理方法であって、各スイッチの使用率および各スイッチを流れるフローからその各スイッチの性能を推定し、各スイッチの第一の負荷を算出し、算出された負荷が予め定めた閾値よりも高いスイッチである対象スイッチが接続されるネットワークの構成を変更するための候補を決定し、候補として決定された変更後のネットワークの構成に基づいて、推定された性能での各スイッチの第二の負荷を算出することを特徴とする。
【００２０】
本発明によるネットワークリソース管理プログラムは、ネットワーク内に配置された各スイッチのリソースを管理するコンピュータに適用されるネットワークリソース管理プログラムであって、コンピュータに、各スイッチの使用率および各スイッチを流れるフローからその各スイッチの性能を推定する性能推定処理、各スイッチの第一の負荷を算出する第一負荷算出処理、算出された第一の負荷が予め定めた閾値よりも高いスイッチである対象スイッチが接続されるネットワークの構成を変更するための候補を決定する構成変更候補決定処理、および、候補として決定された変更後のネットワークの構成に基づいて、推定された性能での各スイッチの第二の負荷を算出する第二負荷算出処理を実行させることを特徴とする。
【発明の効果】
【００２１】
本発明によれば、異なる性能のスイッチを含むネットワークのリソースを平準化できる。
【図面の簡単な説明】
【００２２】
【図１】本発明によるネットワークリソース管理装置の一実施形態を示すブロック図である。
【図２】想定するネットワーク構成の例を示す説明図である。
【図３】リソース管理装置の動作例を示すフローチャートである。
【図４】ネットワークリソース管理装置を用いた管理方法の具体例を示す説明図である。
【図５】ネットワークリソース管理装置を用いた管理方法の具体例を示す説明図である。
【発明を実施するための形態】
【００２３】
以下、本発明の実施形態を図面を参照して説明する。本実施形態のネットワークリソース管理装置は、ネットワーク内に配置された各スイッチのリソースを管理する。なお、本実施形態で管理されるスイッチは、ＳＮＭＰ（Simple Network Management Protocol）を実装しており、かつ、ｓＦｌｏｗまたはＮｅｔＦｌｏｗといった、統計情報をフローとして送信できるプロトコルを実装しているものとする。
【００２４】
図１は、本発明によるネットワークリソース管理装置の一実施形態を示すブロック図である。本実施形態のネットワークリソース管理装置１００は、性能推定部１０と、第一負荷算出部２０と、構成変更候補決定部３０と、第二負荷算出部４０とを備えている。
【００２５】
また、図２は、本実施形態で想定するネットワーク構成の例を示す説明図である。図２に例示するネットワークには、基幹となる幾つかのコアスイッチと、コアスイッチに接続されたエッジスイッチ、及びエッジスイッチに接続されたＦＡＴ−ＰＣまたはＶＭが存在する。ＦＡＴ−ＰＣまたはＶＭは、様々な用途のものが混在しており、ネットワーク内のみと通信を行うものや、外部サーバへ接続するもの、またはサーバとして外部へ公開しているものも含まれる。以降、これらを総称してノードと呼ぶ。
【００２６】
ノード間には、暗黙的な優先度が存在している。例えば、自社製品の修正パッチを外部へ提供しているサーバなどは、他のノードよりも優先的にリソースを割り当てたいと考えられるため、高い優先度が設定される。ネットワーク内には、ネットワーク全体の監視を行うマネージャ（ＭＧＲ）が存在する。このＭＧＲが本実施形態のネットワークリソース管理装置１００に対応する。
【００２７】
ＭＧＲは、ネットワーク全体の負荷を監視し、ネットワーク負荷が発生しているエリアが存在する場合、本実施形態で示す処理に基づき、各スイッチをスコア付けして、評価および構成の変更を行う。なお、外部および外部と最も近いスイッチの間には、ファイアウォール（ＦＷ）が存在する。
【００２８】
図２に例示するスイッチ間の線および破線は、ネットワーク上の経路を示す。上位と下位のスイッチの間には物理的な配線が存在し、ネットワークの負荷に応じてフレキシブルにネットワークの経路を変更できる。ＭＧＲは、これらの物理的な配線の情報を定期的に取得し、内部的な情報として管理している。この情報は、ネットワークの構成を変更する候補を決定するための情報として利用される。
【００２９】
なお、このように、異なる性能のスイッチを含むネットワークのリソースを平準化するためには、まず、各スイッチの性能差を考慮する必要がある。すなわち、全てのスイッチが同一機種であれば、単純にＣＰＵ利用率やバックプレーンの使用率を取得することで、リソースを平準化することが可能である。
【００３０】
しかし、上述するように、システムの要求に応じてスイッチが選定されていることがほとんどである。また、構成変更や増設に伴ってスイッチを追加することがあるため、スイッチの性能が全て同じということは、現実的にはほぼありえない。そのため、スイッチの性能差を何らかの方法により把握する必要がある。しかし、例えば、スイッチの機種ごとにカタログスペックを確認して、性能差を実際の使用率から計算することは難しい。
【００３１】
そこで、本実施形態の性能推定部１０は、各スイッチの使用率および各スイッチを流れるフローから、各スイッチの性能を推定する。これにより、各スイッチの絶対的な性能が動的に算出される。スイッチの性能として、スイッチング容量（１秒当たり処理可能なデータ量）や、スイッチング能力（１秒当たり処理可能なフレーム数）が挙げられる。
【００３２】
各スイッチのＣＰＵ使用率や、スイッチ全体のトラフィック使用率は、管理情報ベース（ＭＩＢ：Management Information Base ）により取得できる。これは、ＭＩＢを実装しているスイッチであれば、外部から情報を取得することができるため、各スイッチに情報を取得するためのエージェントなどの配置は不要である。また、各スイッチに流れるフロー（トラフィックやフレーム数）は、ｓＦｌｏｗやｎｅｔｆｌｏｗといった、トラフィックを監視する技術を使用することにより取得できる。
【００３３】
そこで、性能推定部１０は、スイッチを流れるフローの量をスイッチの使用率で割ることにより、各スイッチの性能の限界値の概算を算出する。例えば、単位時間当たりに流れるトラフィックが１０Ｇｂｐｓ、スイッチのトラフィック使用率が２０％の場合、性能推定部１０は、そのスイッチの性能としてスイッチング容量の限界が、おおよそ５０Ｇｂｐｓと見積もることができる。同様に、性能推定部１０は、スイッチのスイッチング能力に関しても、単位時間当たりのＣＰＵ使用率およびスイッチを流れたフレーム数の総計により推定することができる。
【００３４】
例えば、ある時点でスイッチが処理した総フレーム数Ｆ１、ある時点からｔ経過した時点でスイッチが処理した総フレーム数Ｆ２のとき、期間ｔのＣＰＵ使用率の平均値は、以下の式１で算出できる。式１において、Ｔは期間ｔにＣＰＵ使用率を測定した回数であり、Ｃｐは、測定した時点のＣＰＵ使用率である。
【００３５】
【数１】
2018148382.tif 000003
【００３６】
また、この場合、このスイッチのスイッチング容量は、以下の式２で算出できる。
【００３７】
【数２】
2018148382.tif 000004
【００３８】
スイッチング能力についても、上記式１および式２と同様に算出できる。
【００３９】
第一負荷算出部２０は、各スイッチの負荷（第一の負荷）を算出する。第一負荷算出部２０は、取得したＣＰＵ使用率をそのまま各スイッチの負荷率としてもよい。ただし、実際の運用を考慮した場合、リソースの割り当てを単純にスイッチの負荷だけで判断できない場合も存在する。例えば、社内ネットワークを利用する業務ＰＣよりも、外部に公開しているパッチ配信サーバに対し優先的にネットワークリソースを割り当てたい場合などがこれに該当する。
【００４０】
そこで、優先的にリソースを割り当てるべき度合い（優先度）を示すパラメータをスイッチおよび端末に対してそれぞれ設定しておいてもよい。例えば、優先度としてスイッチに設定されるパラメータをα、端末に設定されるパラメータをβとし、各スイッチから取得された負荷率をγとする。このとき、第一負荷算出部２０は、各スイッチの優先度付き負荷率を、以下の式３で算出してもよい。なお、ｎは、端末の数である。式３に示すように、第一負荷算出部２０は、優先度が高いほど負荷を高く算出してもよい。このようにして、ネットワーク全体を考慮したリソース状況の分析が行われる。
【００４１】
【数３】
2018148382.tif 000005
【００４２】
構成変更候補決定部３０は、算出された負荷が予め定めた閾値よりも高いスイッチが接続されるネットワークの構成を変更する候補を決定する。構成変更候補決定部３０は、現在接続されているノードへの経路が確保可能な構成の候補一覧を自動で決定してもよい。また、構成変更候補決定部３０は、ユーザの指示に応じて、対象とするスイッチに接続されたネットワークの構成の候補を決定してもよい。
【００４３】
第二負荷算出部４０は、候補として決定された変更後のネットワークの構成に基づいて、推定された性能での各スイッチの負荷（第二の負荷）を算出する。すなわち、第二負荷算出部４０は、構成変更を行った場合のリソース状況の評価を行う。この評価に基づいて、構成の変更が実施される。
【００４４】
具体的には、第二負荷算出部４０は、性能推定部１０が推定した各スイッチの性能に基づいて、構成を変更した場合に流れるフローから、各スイッチの負荷率を算出する。例えば、構成の変更により、対象のスイッチにトラフィック（フレーム数）Ｆ３が発生するとする。この場合、第二負荷算出部４０は、リソース分配後の負荷率γを、例えば、以下に示す式４で算出する。
【００４５】
【数４】
2018148382.tif 000006
【００４６】
第二負荷算出部４０は、算出した負荷率γが、予め定めた負荷率を下回っているか否か判断してもよい。算出した負荷率γが予め定めた負荷率以上であれば、別の構成変更を検討することが可能である。
【００４７】
性能推定部１０と、第一負荷算出部２０と、構成変更候補決定部３０と、第二負荷算出部４０とは、プログラム（ネットワークリソース管理プログラム）に従って動作するコンピュータのＣＰＵによって実現される。例えば、プログラムは、ネットワークリソース管理装置の記憶部（図示せず）に記憶され、ＣＰＵは、そのプログラムを読み込み、プログラムに従って、性能推定部１０、第一負荷算出部２０、構成変更候補決定部３０および第二負荷算出部４０として動作してもよい。また、性能推定部１０と、第一負荷算出部２０と、構成変更候補決定部３０と、第二負荷算出部４０とは、それぞれが専用のハードウェアで実現されていてもよい。
【００４８】
次に、本実施形態のリソース管理装置の動作を説明する。図３は、本実施形態のリソース管理装置の動作例を示すフローチャートである。まず、ネットワーク上にＭＧＲ（すなわち、本実施形態のネットワークリソース管理装置１００）を配置する。さらに、優先的にリソースを割り当てたいノード（具体的には、端末、スイッチ）に予め優先度が設定され（ステップＳ１１）。優先度は、ネットワーク内に配置されたＭＧＲにより管理される。なお、優先度が全てフラットな（すなわち、優先度に偏りがない）ネットワークの場合、優先度を設定する工程は省略されても良い。
【００４９】
ＭＧＲ（例えば、性能推定部１０）は、定常的にノードの情報を収集する（ステップＳ１２）。ＭＧＲが収集する情報は、主にＣＰＵ使用率、トラフィック情報などである。なお、ＭＧＲは、その他指標になる値をさらに収集してもよい。各スイッチは、スイッチを通過したパケット数などの統計情報をフローとして定期的にＭＧＲに送信する。
【００５０】
ＭＧＲ（例えば、性能推定部１０）は、取得したこれらの情報を分析し、高負荷のノードが存在するか否か判断する（ステップＳ１３）。高負荷のノードが存在する場合（ステップＳ１３におけるＹｅｓ）、ＭＧＲ（例えば、第一負荷算出部２０）は、機種ごとの性能差を考慮した負荷率を計算する（ステップＳ１４）。一方、高負荷のノードが存在しない場合（ステップＳ１３におけるＮｏ）、ＭＧＲは、ノードの情報を収集する処理を繰り返す。
【００５１】
ＭＧＲ（例えば、構成変更候補決定部３０）は、構成変更可能な範囲で、リソース枯渇を解消するための候補を決定する。そして、ＭＧＲ（例えば、第二負荷算出部４０）は、決定された候補に従って、ネットワークの構成を変更した場合の負荷率を計算する（ステップＳ１５）。具体的には、ＭＧＲは、負荷が発生しているノードを中心に下位全てのスイッチ及び上位のスイッチを選択して負荷率を計算する。
【００５２】
ＭＧＲ（例えば、第二負荷算出部４０）は、候補内のパスの切り替えでリソース不足を解消できるか否か判断する（ステップＳ１６）。すべての候補を適用しても高負荷状態が解消できない場合、すなわち、候補内のパスの切り替えでリソース不足を解消できない場合（ステップＳ１６におけるＮｏ）、ＭＧＲは、さらに上位のスイッチが存在するか否か判断する（ステップＳ１７）。
【００５３】
さらに上位のスイッチが存在する場合（ステップＳ１７におけるＹｅｓ）、ＭＧＲ（例えば、第二負荷算出部４０）は、上位スイッチを選択して候補のエリアに含める（ステップＳ１８）。そして、リソース枯渇を解消するための候補の決定を行うステップＳ１５以降の処理を繰り返す。すなわち、ＭＧＲは、更に上位のスイッチ及びそのスイッチ配下に存在するスイッチを選択して負荷率を計算する。すなわち、この処理は、高負荷状態が解消されるまでエリアを拡大し繰り返されることになる。
【００５４】
一方、ステップＳ１６において、候補内のパスの切り替えでリソース不足を解消できる場合（ステップＳ１６におけるＹｅｓ）、ＭＧＲは、最適な候補が見つかったと判断し、ネットワークの経路の変更を実施することにより（ステップＳ１９）、ネットワーク高負荷状態を解消する。
【００５５】
次に、本実施形態の具体例を説明する。図４および図５は、本実施形態のネットワークリソース管理装置を用いた管理方法の具体例を示す説明図である。
【００５６】
図４に例示するように、外部へ最も近いスイッチ３０１（以下、ＳＷ１）と、ＳＷ１に接続されたスイッチ３１０（以下、スイッチＳＷ１０）およびスイッチ３１１（以下、スイッチＳＷ１１）が存在する。また、ＭＧＲ３００は、ＳＷ１に接続される。また、ＳＷ１０には、スイッチ３２０（以下、ＳＷ１００）およびスイッチ３２１（以下、ＳＷ１０１）が接続されている。一方、ＳＷ１０には、スイッチ３２２（以下、スイッチＳＷ１０２）が物理的には接続されているが、ＳＷ１０の設定により、経路は遮断されている。
【００５７】
ＳＷ１１には、ＳＷ１０２が接続されている。一方、ＳＷ１１には、ＳＷ１００およびＳＷ１０１が物理的には接続されているが、ＳＷ１１の設定により、経路は遮断されている。
【００５８】
ＳＷ１０１には、スイッチ３３０（以下、ＳＷ１００１）、スイッチ３３１（以下、ＳＷ１００２）および、スイッチ３３２（以下、ＳＷ１００３）が接続されている。また、ＳＷ１００１、ＳＷ１００２およびＳＷ１００３は、ＳＷ１００およびＳＷ１０２とそれぞれ物理的には接続されているが、各スイッチの設定により経路は遮断されている。
【００５９】
なお、ＳＷ１００およびＳＷ１０２に接続されている下位のＳＷは省略されている。ＳＷ１００１、ＳＷ１００２およびＳＷ１００３は、エッジスイッチになり、配下に複数のＦＡＴ−ＰＣ３４０またはＶＭ３４１が接続されている。
【００６０】
本具体例では、ＳＷ１０１のネットワーク負荷が９３％で、高負荷状態になっているとする。ＳＷ１０１の上位のＳＷ１０、並びに、下位のＳＷ１００１、ＳＷ１００２及び１００３は、ネットワーク負荷が全て６０％以下になっている。そのため、本具体例では、ＳＷ１０１配下の構成変更により、負荷状態を解消できると考えられる。
【００６１】
ＭＧＲ３００は、次に、ＳＷ１０１の下位のスイッチに、物理的に接続されている上位のスイッチを確認する。ＳＷ１００１、ＳＷ１００２およびＳＷ１００３には、ＳＷ１０１以外に、ＳＷ１００およびＳＷ１０２の２台のスイッチが物理的に接続されており、それぞれの負荷率は、６０％以下である。
【００６２】
ＳＷ１００の負荷率は６０％であり、ＳＷ１０２の負荷率は５０％になっている。そのため、一見するとＳＷ１０２への経路を増やすことが有効とも考えられる。しかし、実際には、ＳＷ１００とＳＷ１０２との間には性能差が存在する。
【００６３】
本具体例では、各スイッチは、図４の各スイッチに記載された「推定スイッチング容量」を性能として有しているとする。各スイッチの性能差を考慮すると、ＳＷ１０２よりも、ＳＷ１００の方がリソースの空きが大きいと言える。そこで、ＭＧＲ３００は、図５に例示するように、ＳＷ１０１配下のスイッチであるＳＷ１００３の経路をＳＷ１００へ変更する。その結果、ＳＷ１０１の負荷が低減し、ＳＷ１００、ＳＷ１０１およびＳＷ１０２の負荷が平準化されている。
【００６４】
仮に、ネットワーク負荷（使用率）のみで判断し、ＳＷ１００３の経路をＳＷ１０２に切り替えた場合、ＳＷ１０２の使用率は１００％になってしまうため、経路変更により、リソース配分が悪化してしまうことになる。しかし、本実施形態では、性能推定部１０が各スイッチの性能を推定し、推定された性能に基づいて、第二負荷算出部４０が適切に負荷率を算出する。そのため、異なる性能のスイッチを含むネットワークのリソースを平準化できる
【００６５】
以上のように、本実施形態では、性能推定部１０が、各スイッチの使用率および各スイッチを流れるフローから各スイッチの性能を推定し、第一負荷算出部２０が、各スイッチの第一の負荷を算出する。構成変更候補決定部３０が、算出された負荷が予め定めた閾値よりも高いスイッチが接続されるネットワークの構成を変更するための候補を決定し、第二負荷算出部４０が、候補として決定された変更後のネットワークの構成に基づいて、推定された性能での各スイッチの第二の負荷を算出する。よって、上述するように、異なる性能のスイッチを含むネットワークのリソースを平準化できる。
【００６６】
また、本実施形態のネットワークリソース管理装置１００を用いることで、性能が異なる様々なスイッチが存在するネットワークであっても、各スイッチの性能を意識することなく動的にネットワークの経路を変更し、ネットワーク負荷を平準化することができる。また、本実施形態のネットワークリソース管理装置１００は、ＳＮＭＰやｓＦｌｏｗ、ＮｅｔＦｌｏｗといった、スイッチに標準的に実装されている技術を利用できる。そのため、スイッチの機種を限定せず、広範な環境で動作させることが可能になる。
【００６７】
次に、本発明の概要を図１を参照して説明する。本発明によるネットワークリソース管理装置は、ネットワーク内に配置された各スイッチのリソースを管理するネットワークリソース管理装置１００であって、各スイッチの使用率および各スイッチを流れるフローからその各スイッチの性能を推定する性能推定部１０と、各スイッチの第一の負荷を算出する第一負荷算出部２０と、算出された第一の負荷が予め定めた閾値よりも高いスイッチである対象スイッチが接続されるネットワークの構成を変更するための候補を決定する構成変更候補決定部３０と、候補として決定された変更後のネットワークの構成に基づいて、推定された性能での各スイッチの第二の負荷を算出する第二負荷算出部４０とを備えている。
【００６８】
そのような構成により、異なる性能のスイッチを含むネットワークのリソースを平準化できる。
【００６９】
また、各スイッチおよびそのスイッチに接続されるノード（例えば、ＦＡＴ−ＰＣ、ＶＭ）に優先度が定められ、第一負荷算出部２０は、優先度が高いほど、第一の負荷を高く算出してもよい。
【００７０】
また、構成変更候補決定部３０は、ネットワークの構成を変更する候補として、対象スイッチの下位全てのスイッチおよびその対象スイッチの上位のスイッチを選択し、第二負荷算出部４０は、選択されたネットワークの構成に基づいて算出された第二の負荷が予め定めた負荷を下回るか否か判断してもよい。
【００７１】
さらに、構成変更候補決定部３０は、第二負荷算出部４０が算出した各スイッチの第二の負荷が予め定めた負荷を下回る構成が存在しない場合、ネットワークの構成を変更する候補として、さらに上位のスイッチおよびそのスイッチ配下のスイッチを選択してもよい。
【００７２】
また、第一負荷算出部２０は、管理情報ベース（ＭＩＢ）により取得した負荷を、各スイッチの第一の負荷として使用してもよい。
【符号の説明】
【００７３】
１０  性能推定部
２０  第一負荷算出部
３０  構成変更候補決定部
４０  第二負荷算出部
１００  ネットワークリソース管理装置
【図１】
2018148382.tif 000007
【図２】
2018148382.tif 000008
【図３】
2018148382.tif 000009
【図４】
2018148382.tif 000010
【図５】
2018148382.tif 000011