JP6834604B2 - ネットワークリソース管理装置、方法およびプログラム - Google Patents

ネットワークリソース管理装置、方法およびプログラム Download PDF

Info

Publication number
JP6834604B2
JP6834604B2 JP2017041235A JP2017041235A JP6834604B2 JP 6834604 B2 JP6834604 B2 JP 6834604B2 JP 2017041235 A JP2017041235 A JP 2017041235A JP 2017041235 A JP2017041235 A JP 2017041235A JP 6834604 B2 JP6834604 B2 JP 6834604B2
Authority
JP
Japan
Prior art keywords
switch
load
network
resource management
configuration
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2017041235A
Other languages
English (en)
Other versions
JP2018148382A (ja
Inventor
知秀 野田
知秀 野田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Corp
Original Assignee
NEC Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by NEC Corp filed Critical NEC Corp
Priority to JP2017041235A priority Critical patent/JP6834604B2/ja
Publication of JP2018148382A publication Critical patent/JP2018148382A/ja
Application granted granted Critical
Publication of JP6834604B2 publication Critical patent/JP6834604B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)

Description

本発明は、複数のスイッチを含むネットワークのリソースを管理するネットワークリソース管理装置、ネットワークリソース管理方法およびネットワークリソース管理プログラムに関する。
あるシステムにおいて、ハードウェアリソースの枯渇や、偏りの発生を回避することは困難である。そこで、通常、システム管理者がリソース状況を把握し、メンテナンス期間を設けて構成の変更やハードウェアリソースの増強などを行っている。
これに対し、仮想環境の場合、CPU(Central Processing Unit )やメモリのリソースに応じてVM(Virtual Machine )を移動させる技術が存在する。そのため、特定のVMが高負荷になっていたとしても、ある程度フレキシブルに構成を変更し、高負荷状態を解決することができる。
特許文献1には、仮想マシン間の通信品質を保証するように、各仮想マシンを物理サーバに配置する仮想マシン配置装置が記載されている。特許文献1に記載された仮想マシン配置装置は、各仮想マシン間の通信が通過するスイッチが扱う通信量の総和をスイッチごとに収集し、その総和がスイッチの通信容量を超過しないように、仮想マシンの配置先となる物理サーバを決定する。
特開2015−225560号公報
一方、ネットワークリソースに関しては、CPUやメモリリソースと異なり、VMを動作させているVMM(Virtual Machine Monitor )のリソースのみを監視してもリソースの枯渇を解決できないケースが多々存在する。CPUやメモリは、VMMに完全に依存するが、ネットワークリソースは、様々な機器を通る、いわば通路のようなものである。そのため、ある特定の機器に限定した局所的な判断を行っても、本当の原因になっているポイントがわからず、誤った判断を行ってしまうことがある。
そのため、ネットワーク全体を把握したうえでリソースの判断を行い、動的に設定の変更を行う必要がある。しかし、ネットワークを繋ぐスイッチの性能は一定ではない。そのため、スイッチのハードウェアリソースの使用率(すなわち、負荷率)を把握できても、ネットワークの構成を変更した場合に、どのようにリソースが配分されるか把握することは難しい。
例えば、あるシステムにおいて、ネットワークを管理するコアスイッチ、及びコアスイッチに接続されるエッジスイッチが存在し、エッジスイッチにはサービスを提供するサーバ及び業務用PC(Personal computer )が接続されて動作している場面を想定する。ここで、サーバ及び業務用PCは、FAT−PC、またはVMとして存在しているとする。
一般に、スイッチの性能は同一ではなく、各スイッチの間には性能差が存在している。また、スイッチに接続されているサーバ、及び業務用PCの数も一定ではない。さらに、スイッチを流れるトラフィック量も同一ではなく、偏りが存在する。
このため、ネットワーク全体のトラフィック量が全スイッチの収容能力を超えるほどではないが、局所的な観点では、特定のスイッチに負荷が偏ることにより、サービス及び業務に影響を及ぼすことがある。
このような状況が発生すると、サービス利用者もしくはネットワーク内のユーザからの通知、または、ネットワーク監視ソフトウェアなどの通知により、ネットワーク負荷の偏りが発生していることが認識される。この状況を解消するため、ネットワーク管理者は、手動でネットワークの構成を変える、または、ネットワークリソースを大量に使用している端末を別のスイッチに接続するなどの対処が必要になる。
この場合の問題点は、大きくわけて2つ存在する。1つ目は、ネットワーク構成の見直しに対する設計および評価が必要になるため、即時性が求められる緊急事態であっても対応が困難なことである。2つ目は、スイッチの構成の変更に必要なダウンタイムが発生するため、ユーザへの影響が発生することである。対応が特に困難なのは1つ目の問題点である。例えば、複雑なネットワーク構成の場合、局所的な視点での設定変更では問題を解決できない可能性が高い。
具体的には、ネットワークが大きくなればなるほど確認すべき範囲が増大し、複雑な設計が必要になる。例えば、あるスイッチの影響を把握するためには、エッジスイッチから上位のスイッチを辿り、そのスイッチに接続される下位のスイッチ及びその下位のスイッチを辿らなければならない、という現象が起こり得る。
全てのスイッチが同一機種であれば、単純にハードウェアリソースの使用率(負荷率)を確認して、ネットワーク構成を変更する、すなわち、負荷率を加算したり減算したりすれば、リソースの問題を解決できる。しかし、実際のネットワークでは、スイッチごとに性能の異なる場合がほとんどである。その場合、リソースの配分は、それぞれのスイッチの性能差を考慮して計算される必要があるため、問題を解決するためには、膨大な計算が必要になる。
現実的には、特定のサーバ及びそのサーバが接続されているエッジスイッチまたはそのエッジスイッチより上位のスイッチを1つ確認するのが精一杯と言える。そのため、例えば、エッジスイッチから上位のスイッチ、さらに上位のスイッチ、と範囲を広げながらネットワークの負荷率を計算して、ネットワーク構成をスポット的に変更するといった運用は行われていないのが実情である。
また、特許文献1に記載された仮想マシン配置装置は、各スイッチの通信容量を把握しておかなければならない。また、上述するように、ネットワーク上には異なる性能のスイッチが廃止されることが一般的である。そのため、特許文献1に記載されているように、通信容量を超過しないようにリソースを配分するだけでは、性能の異なる各スイッチのリソースを適切に配分することは困難である。そのため、作業負荷を低減し適切にリソースを配分するためには、自律的にネットワークリソースを平準化できることが好ましい。
そこで、本発明は、異なる性能のスイッチを含むネットワークのリソースを平準化できるネットワークリソース管理装置、ネットワークリソース管理方法およびネットワークリソース管理プログラムを提供することを目的とする。
本発明によるネットワークリソース管理装置は、ネットワーク内に配置された各スイッチのリソースを管理するネットワークリソース管理装置であって、各スイッチの使用率および各スイッチを流れるフローからその各スイッチの性能を推定する性能推定部と、各スイッチの第一の負荷を算出する第一負荷算出部と、算出された第一の負荷が予め定めた閾値よりも高いスイッチである対象スイッチが接続されるネットワークの構成を変更するための候補を決定する構成変更候補決定部と、候補として決定された変更後のネットワークの構成に基づいて、推定された性能での各スイッチの第二の負荷を算出する第二負荷算出部とを備えたことを特徴とする。
本発明によるネットワークリソース管理方法は、ネットワーク内に配置された各スイッチのリソースを管理するネットワークリソース管理方法であって、各スイッチの使用率および各スイッチを流れるフローからその各スイッチの性能を推定し、各スイッチの第一の負荷を算出し、算出された負荷が予め定めた閾値よりも高いスイッチである対象スイッチが接続されるネットワークの構成を変更するための候補を決定し、候補として決定された変更後のネットワークの構成に基づいて、推定された性能での各スイッチの第二の負荷を算出することを特徴とする。
本発明によるネットワークリソース管理プログラムは、ネットワーク内に配置された各スイッチのリソースを管理するコンピュータに適用されるネットワークリソース管理プログラムであって、コンピュータに、各スイッチの使用率および各スイッチを流れるフローからその各スイッチの性能を推定する性能推定処理、各スイッチの第一の負荷を算出する第一負荷算出処理、算出された第一の負荷が予め定めた閾値よりも高いスイッチである対象スイッチが接続されるネットワークの構成を変更するための候補を決定する構成変更候補決定処理、および、候補として決定された変更後のネットワークの構成に基づいて、推定された性能での各スイッチの第二の負荷を算出する第二負荷算出処理を実行させることを特徴とする。
本発明によれば、異なる性能のスイッチを含むネットワークのリソースを平準化できる。
本発明によるネットワークリソース管理装置の一実施形態を示すブロック図である。 想定するネットワーク構成の例を示す説明図である。 リソース管理装置の動作例を示すフローチャートである。 ネットワークリソース管理装置を用いた管理方法の具体例を示す説明図である。 ネットワークリソース管理装置を用いた管理方法の具体例を示す説明図である。
以下、本発明の実施形態を図面を参照して説明する。本実施形態のネットワークリソース管理装置は、ネットワーク内に配置された各スイッチのリソースを管理する。なお、本実施形態で管理されるスイッチは、SNMP(Simple Network Management Protocol)を実装しており、かつ、sFlowまたはNetFlowといった、統計情報をフローとして送信できるプロトコルを実装しているものとする。
図1は、本発明によるネットワークリソース管理装置の一実施形態を示すブロック図である。本実施形態のネットワークリソース管理装置100は、性能推定部10と、第一負荷算出部20と、構成変更候補決定部30と、第二負荷算出部40とを備えている。
また、図2は、本実施形態で想定するネットワーク構成の例を示す説明図である。図2に例示するネットワークには、基幹となる幾つかのコアスイッチと、コアスイッチに接続されたエッジスイッチ、及びエッジスイッチに接続されたFAT−PCまたはVMが存在する。FAT−PCまたはVMは、様々な用途のものが混在しており、ネットワーク内のみと通信を行うものや、外部サーバへ接続するもの、またはサーバとして外部へ公開しているものも含まれる。以降、これらを総称してノードと呼ぶ。
ノード間には、暗黙的な優先度が存在している。例えば、自社製品の修正パッチを外部へ提供しているサーバなどは、他のノードよりも優先的にリソースを割り当てたいと考えられるため、高い優先度が設定される。ネットワーク内には、ネットワーク全体の監視を行うマネージャ(MGR)が存在する。このMGRが本実施形態のネットワークリソース管理装置100に対応する。
MGRは、ネットワーク全体の負荷を監視し、ネットワーク負荷が発生しているエリアが存在する場合、本実施形態で示す処理に基づき、各スイッチをスコア付けして、評価および構成の変更を行う。なお、外部および外部と最も近いスイッチの間には、ファイアウォール(FW)が存在する。
図2に例示するスイッチ間の線および破線は、ネットワーク上の経路を示す。上位と下位のスイッチの間には物理的な配線が存在し、ネットワークの負荷に応じてフレキシブルにネットワークの経路を変更できる。MGRは、これらの物理的な配線の情報を定期的に取得し、内部的な情報として管理している。この情報は、ネットワークの構成を変更する候補を決定するための情報として利用される。
なお、このように、異なる性能のスイッチを含むネットワークのリソースを平準化するためには、まず、各スイッチの性能差を考慮する必要がある。すなわち、全てのスイッチが同一機種であれば、単純にCPU利用率やバックプレーンの使用率を取得することで、リソースを平準化することが可能である。
しかし、上述するように、システムの要求に応じてスイッチが選定されていることがほとんどである。また、構成変更や増設に伴ってスイッチを追加することがあるため、スイッチの性能が全て同じということは、現実的にはほぼありえない。そのため、スイッチの性能差を何らかの方法により把握する必要がある。しかし、例えば、スイッチの機種ごとにカタログスペックを確認して、性能差を実際の使用率から計算することは難しい。
そこで、本実施形態の性能推定部10は、各スイッチの使用率および各スイッチを流れるフローから、各スイッチの性能を推定する。これにより、各スイッチの絶対的な性能が動的に算出される。スイッチの性能として、スイッチング容量(1秒当たり処理可能なデータ量)や、スイッチング能力(1秒当たり処理可能なフレーム数)が挙げられる。
各スイッチのCPU使用率や、スイッチ全体のトラフィック使用率は、管理情報ベース(MIB:Management Information Base )により取得できる。これは、MIBを実装しているスイッチであれば、外部から情報を取得することができるため、各スイッチに情報を取得するためのエージェントなどの配置は不要である。また、各スイッチに流れるフロー(トラフィックやフレーム数)は、sFlowやnetflowといった、トラフィックを監視する技術を使用することにより取得できる。
そこで、性能推定部10は、スイッチを流れるフローの量をスイッチの使用率で割ることにより、各スイッチの性能の限界値の概算を算出する。例えば、単位時間当たりに流れるトラフィックが10Gbps、スイッチのトラフィック使用率が20%の場合、性能推定部10は、そのスイッチの性能としてスイッチング容量の限界が、おおよそ50Gbpsと見積もることができる。同様に、性能推定部10は、スイッチのスイッチング能力に関しても、単位時間当たりのCPU使用率およびスイッチを流れたフレーム数の総計により推定することができる。
例えば、ある時点でスイッチが処理した総フレーム数F、ある時点からt経過した時点でスイッチが処理した総フレーム数Fのとき、期間tのCPU使用率の平均値は、以下の式1で算出できる。式1において、Tは期間tにCPU使用率を測定した回数であり、Cは、測定した時点のCPU使用率である。
Figure 0006834604
また、この場合、このスイッチのスイッチング容量は、以下の式2で算出できる。
Figure 0006834604
スイッチング能力についても、上記式1および式2と同様に算出できる。
第一負荷算出部20は、各スイッチの負荷(第一の負荷)を算出する。第一負荷算出部20は、取得したCPU使用率をそのまま各スイッチの負荷率としてもよい。ただし、実際の運用を考慮した場合、リソースの割り当てを単純にスイッチの負荷だけで判断できない場合も存在する。例えば、社内ネットワークを利用する業務PCよりも、外部に公開しているパッチ配信サーバに対し優先的にネットワークリソースを割り当てたい場合などがこれに該当する。
そこで、優先的にリソースを割り当てるべき度合い(優先度)を示すパラメータをスイッチおよび端末に対してそれぞれ設定しておいてもよい。例えば、優先度としてスイッチに設定されるパラメータをα、端末に設定されるパラメータをβとし、各スイッチから取得された負荷率をγとする。このとき、第一負荷算出部20は、各スイッチの優先度付き負荷率を、以下の式3で算出してもよい。なお、nは、端末の数である。式3に示すように、第一負荷算出部20は、優先度が高いほど負荷を高く算出してもよい。このようにして、ネットワーク全体を考慮したリソース状況の分析が行われる。
Figure 0006834604
構成変更候補決定部30は、算出された負荷が予め定めた閾値よりも高いスイッチが接続されるネットワークの構成を変更する候補を決定する。構成変更候補決定部30は、現在接続されているノードへの経路が確保可能な構成の候補一覧を自動で決定してもよい。また、構成変更候補決定部30は、ユーザの指示に応じて、対象とするスイッチに接続されたネットワークの構成の候補を決定してもよい。
第二負荷算出部40は、候補として決定された変更後のネットワークの構成に基づいて、推定された性能での各スイッチの負荷(第二の負荷)を算出する。すなわち、第二負荷算出部40は、構成変更を行った場合のリソース状況の評価を行う。この評価に基づいて、構成の変更が実施される。
具体的には、第二負荷算出部40は、性能推定部10が推定した各スイッチの性能に基づいて、構成を変更した場合に流れるフローから、各スイッチの負荷率を算出する。例えば、構成の変更により、対象のスイッチにトラフィック(フレーム数)Fが発生するとする。この場合、第二負荷算出部40は、リソース分配後の負荷率γを、例えば、以下に示す式4で算出する。
Figure 0006834604
第二負荷算出部40は、算出した負荷率γが、予め定めた負荷率を下回っているか否か判断してもよい。算出した負荷率γが予め定めた負荷率以上であれば、別の構成変更を検討することが可能である。
性能推定部10と、第一負荷算出部20と、構成変更候補決定部30と、第二負荷算出部40とは、プログラム(ネットワークリソース管理プログラム)に従って動作するコンピュータのCPUによって実現される。例えば、プログラムは、ネットワークリソース管理装置の記憶部(図示せず)に記憶され、CPUは、そのプログラムを読み込み、プログラムに従って、性能推定部10、第一負荷算出部20、構成変更候補決定部30および第二負荷算出部40として動作してもよい。また、性能推定部10と、第一負荷算出部20と、構成変更候補決定部30と、第二負荷算出部40とは、それぞれが専用のハードウェアで実現されていてもよい。
次に、本実施形態のリソース管理装置の動作を説明する。図3は、本実施形態のリソース管理装置の動作例を示すフローチャートである。まず、ネットワーク上にMGR(すなわち、本実施形態のネットワークリソース管理装置100)を配置する。さらに、優先的にリソースを割り当てたいノード(具体的には、端末、スイッチ)に予め優先度が設定され(ステップS11)。優先度は、ネットワーク内に配置されたMGRにより管理される。なお、優先度が全てフラットな(すなわち、優先度に偏りがない)ネットワークの場合、優先度を設定する工程は省略されても良い。
MGR(例えば、性能推定部10)は、定常的にノードの情報を収集する(ステップS12)。MGRが収集する情報は、主にCPU使用率、トラフィック情報などである。なお、MGRは、その他指標になる値をさらに収集してもよい。各スイッチは、スイッチを通過したパケット数などの統計情報をフローとして定期的にMGRに送信する。
MGR(例えば、性能推定部10)は、取得したこれらの情報を分析し、高負荷のノードが存在するか否か判断する(ステップS13)。高負荷のノードが存在する場合(ステップS13におけるYes)、MGR(例えば、第一負荷算出部20)は、機種ごとの性能差を考慮した負荷率を計算する(ステップS14)。一方、高負荷のノードが存在しない場合(ステップS13におけるNo)、MGRは、ノードの情報を収集する処理を繰り返す。
MGR(例えば、構成変更候補決定部30)は、構成変更可能な範囲で、リソース枯渇を解消するための候補を決定する。そして、MGR(例えば、第二負荷算出部40)は、決定された候補に従って、ネットワークの構成を変更した場合の負荷率を計算する(ステップS15)。具体的には、MGRは、負荷が発生しているノードを中心に下位全てのスイッチ及び上位のスイッチを選択して負荷率を計算する。
MGR(例えば、第二負荷算出部40)は、候補内のパスの切り替えでリソース不足を解消できるか否か判断する(ステップS16)。すべての候補を適用しても高負荷状態が解消できない場合、すなわち、候補内のパスの切り替えでリソース不足を解消できない場合(ステップS16におけるNo)、MGRは、さらに上位のスイッチが存在するか否か判断する(ステップS17)。
さらに上位のスイッチが存在する場合(ステップS17におけるYes)、MGR(例えば、第二負荷算出部40)は、上位スイッチを選択して候補のエリアに含める(ステップS18)。そして、リソース枯渇を解消するための候補の決定を行うステップS15以降の処理を繰り返す。すなわち、MGRは、更に上位のスイッチ及びそのスイッチ配下に存在するスイッチを選択して負荷率を計算する。すなわち、この処理は、高負荷状態が解消されるまでエリアを拡大し繰り返されることになる。
一方、ステップS16において、候補内のパスの切り替えでリソース不足を解消できる場合(ステップS16におけるYes)、MGRは、最適な候補が見つかったと判断し、ネットワークの経路の変更を実施することにより(ステップS19)、ネットワーク高負荷状態を解消する。
次に、本実施形態の具体例を説明する。図4および図5は、本実施形態のネットワークリソース管理装置を用いた管理方法の具体例を示す説明図である。
図4に例示するように、外部へ最も近いスイッチ301(以下、SW1)と、SW1に接続されたスイッチ310(以下、スイッチSW10)およびスイッチ311(以下、スイッチSW11)が存在する。また、MGR300は、SW1に接続される。また、SW10には、スイッチ320(以下、SW100)およびスイッチ321(以下、SW101)が接続されている。一方、SW10には、スイッチ322(以下、スイッチSW102)が物理的には接続されているが、SW10の設定により、経路は遮断されている。
SW11には、SW102が接続されている。一方、SW11には、SW100およびSW101が物理的には接続されているが、SW11の設定により、経路は遮断されている。
SW101には、スイッチ330(以下、SW1001)、スイッチ331(以下、SW1002)および、スイッチ332(以下、SW1003)が接続されている。また、SW1001、SW1002およびSW1003は、SW100およびSW102とそれぞれ物理的には接続されているが、各スイッチの設定により経路は遮断されている。
なお、SW100およびSW102に接続されている下位のSWは省略されている。SW1001、SW1002およびSW1003は、エッジスイッチになり、配下に複数のFAT−PC340またはVM341が接続されている。
本具体例では、SW101のネットワーク負荷が93%で、高負荷状態になっているとする。SW101の上位のSW10、並びに、下位のSW1001、SW1002及び1003は、ネットワーク負荷が全て60%以下になっている。そのため、本具体例では、SW101配下の構成変更により、負荷状態を解消できると考えられる。
MGR300は、次に、SW101の下位のスイッチに、物理的に接続されている上位のスイッチを確認する。SW1001、SW1002およびSW1003には、SW101以外に、SW100およびSW102の2台のスイッチが物理的に接続されており、それぞれの負荷率は、60%以下である。
SW100の負荷率は60%であり、SW102の負荷率は50%になっている。そのため、一見するとSW102への経路を増やすことが有効とも考えられる。しかし、実際には、SW100とSW102との間には性能差が存在する。
本具体例では、各スイッチは、図4の各スイッチに記載された「推定スイッチング容量」を性能として有しているとする。各スイッチの性能差を考慮すると、SW102よりも、SW100の方がリソースの空きが大きいと言える。そこで、MGR300は、図5に例示するように、SW101配下のスイッチであるSW1003の経路をSW100へ変更する。その結果、SW101の負荷が低減し、SW100、SW101およびSW102の負荷が平準化されている。
仮に、ネットワーク負荷(使用率)のみで判断し、SW1003の経路をSW102に切り替えた場合、SW102の使用率は100%になってしまうため、経路変更により、リソース配分が悪化してしまうことになる。しかし、本実施形態では、性能推定部10が各スイッチの性能を推定し、推定された性能に基づいて、第二負荷算出部40が適切に負荷率を算出する。そのため、異なる性能のスイッチを含むネットワークのリソースを平準化できる
以上のように、本実施形態では、性能推定部10が、各スイッチの使用率および各スイッチを流れるフローから各スイッチの性能を推定し、第一負荷算出部20が、各スイッチの第一の負荷を算出する。構成変更候補決定部30が、算出された負荷が予め定めた閾値よりも高いスイッチが接続されるネットワークの構成を変更するための候補を決定し、第二負荷算出部40が、候補として決定された変更後のネットワークの構成に基づいて、推定された性能での各スイッチの第二の負荷を算出する。よって、上述するように、異なる性能のスイッチを含むネットワークのリソースを平準化できる。
また、本実施形態のネットワークリソース管理装置100を用いることで、性能が異なる様々なスイッチが存在するネットワークであっても、各スイッチの性能を意識することなく動的にネットワークの経路を変更し、ネットワーク負荷を平準化することができる。また、本実施形態のネットワークリソース管理装置100は、SNMPやsFlow、NetFlowといった、スイッチに標準的に実装されている技術を利用できる。そのため、スイッチの機種を限定せず、広範な環境で動作させることが可能になる。
次に、本発明の概要を図1を参照して説明する。本発明によるネットワークリソース管理装置は、ネットワーク内に配置された各スイッチのリソースを管理するネットワークリソース管理装置100であって、各スイッチの使用率および各スイッチを流れるフローからその各スイッチの性能を推定する性能推定部10と、各スイッチの第一の負荷を算出する第一負荷算出部20と、算出された第一の負荷が予め定めた閾値よりも高いスイッチである対象スイッチが接続されるネットワークの構成を変更するための候補を決定する構成変更候補決定部30と、候補として決定された変更後のネットワークの構成に基づいて、推定された性能での各スイッチの第二の負荷を算出する第二負荷算出部40とを備えている。
そのような構成により、異なる性能のスイッチを含むネットワークのリソースを平準化できる。
また、各スイッチおよびそのスイッチに接続されるノード(例えば、FAT−PC、VM)に優先度が定められ、第一負荷算出部20は、優先度が高いほど、第一の負荷を高く算出してもよい。
また、構成変更候補決定部30は、ネットワークの構成を変更する候補として、対象スイッチの下位全てのスイッチおよびその対象スイッチの上位のスイッチを選択し、第二負荷算出部40は、選択されたネットワークの構成に基づいて算出された第二の負荷が予め定めた負荷を下回るか否か判断してもよい。
さらに、構成変更候補決定部30は、第二負荷算出部40が算出した各スイッチの第二の負荷が予め定めた負荷を下回る構成が存在しない場合、ネットワークの構成を変更する候補として、さらに上位のスイッチおよびそのスイッチ配下のスイッチを選択してもよい。
また、第一負荷算出部20は、管理情報ベース(MIB)により取得した負荷を、各スイッチの第一の負荷として使用してもよい。
10 性能推定部
20 第一負荷算出部
30 構成変更候補決定部
40 第二負荷算出部
100 ネットワークリソース管理装置

Claims (9)

  1. ネットワーク内に配置された各スイッチのリソースを管理するネットワークリソース管理装置であって、
    前記各スイッチの使用率および各スイッチを流れるフローから当該各スイッチの性能を推定する性能推定部と、
    前記各スイッチの第一の負荷を算出する第一負荷算出部と、
    算出された第一の負荷が予め定めた閾値よりも高いスイッチである対象スイッチが接続されるネットワークの構成を変更するための候補を決定する構成変更候補決定部と、
    前記候補として決定された変更後のネットワークの構成に基づいて、推定された前記性能での各スイッチの第二の負荷を算出する第二負荷算出部とを備えた
    ことを特徴とするネットワークリソース管理装置。
  2. 各スイッチおよび当該スイッチに接続されるノードに優先度が定められ、
    第一負荷算出部は、前記優先度が高いほど、第一の負荷を高く算出する
    請求項1記載のネットワークリソース管理装置。
  3. 構成変更候補決定部は、ネットワークの構成を変更する候補として、対象スイッチの下位全てのスイッチおよび当該対象スイッチの上位のスイッチを選択し、
    第二負荷算出部は、選択されたネットワークの構成に基づいて算出された第二の負荷が予め定めた負荷を下回るか否か判断する
    請求項1または請求項2記載のネットワークリソース管理装置。
  4. 構成変更候補決定部は、第二負荷算出部が算出した各スイッチの第二の負荷が予め定めた負荷を下回る構成が存在しない場合、ネットワークの構成を変更する候補として、さらに上位のスイッチおよび当該スイッチ配下のスイッチを選択する
    請求項3記載のネットワークリソース管理装置。
  5. 第一負荷算出部は、管理情報ベースにより取得した負荷を、各スイッチの第一の負荷として使用する
    請求項1から請求項4のうちのいずれか1項に記載のネットワークリソース管理装置。
  6. ネットワーク内に配置された各スイッチのリソースを管理するネットワークリソース管理方法であって、
    前記各スイッチの使用率および各スイッチを流れるフローから当該各スイッチの性能を推定し、
    前記各スイッチの第一の負荷を算出し、
    算出された負荷が予め定めた閾値よりも高いスイッチである対象スイッチが接続されるネットワークの構成を変更するための候補を決定し、
    前記候補として決定された変更後のネットワークの構成に基づいて、推定された前記性能での各スイッチの第二の負荷を算出する
    ことを特徴とするネットワークリソース管理方法。
  7. 各スイッチおよび当該スイッチに接続されるノードに優先度が定められ、
    前記優先度が高いほど、第一の負荷を高く算出する
    請求項6記載のネットワークリソース管理方法。
  8. ネットワーク内に配置された各スイッチのリソースを管理するコンピュータに適用されるネットワークリソース管理プログラムであって、
    前記コンピュータに、
    前記各スイッチの使用率および各スイッチを流れるフローから当該各スイッチの性能を推定する性能推定処理、
    前記各スイッチの第一の負荷を算出する第一負荷算出処理、
    算出された第一の負荷が予め定めた閾値よりも高いスイッチである対象スイッチが接続されるネットワークの構成を変更するための候補を決定する構成変更候補決定処理、および、
    前記候補として決定された変更後のネットワークの構成に基づいて、推定された前記性能での各スイッチの第二の負荷を算出する第二負荷算出処理
    を実行させるためのネットワークリソース管理プログラム。
  9. 各スイッチおよび当該スイッチに接続されるノードに優先度が定められ、
    コンピュータに、
    第一負荷算出処理で、前記優先度が高いほど、第一の負荷を高く算出させる
    請求項8記載のネットワークリソース管理プログラム。
JP2017041235A 2017-03-06 2017-03-06 ネットワークリソース管理装置、方法およびプログラム Active JP6834604B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2017041235A JP6834604B2 (ja) 2017-03-06 2017-03-06 ネットワークリソース管理装置、方法およびプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2017041235A JP6834604B2 (ja) 2017-03-06 2017-03-06 ネットワークリソース管理装置、方法およびプログラム

Publications (2)

Publication Number Publication Date
JP2018148382A JP2018148382A (ja) 2018-09-20
JP6834604B2 true JP6834604B2 (ja) 2021-02-24

Family

ID=63591544

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017041235A Active JP6834604B2 (ja) 2017-03-06 2017-03-06 ネットワークリソース管理装置、方法およびプログラム

Country Status (1)

Country Link
JP (1) JP6834604B2 (ja)

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4648838B2 (ja) * 2006-01-16 2011-03-09 三菱電機株式会社 ネットワーク監視支援装置、ネットワーク監視支援方法およびネットワーク監視支援プログラム
JP2007208633A (ja) * 2006-02-01 2007-08-16 Mitsubishi Electric Corp ネットワーク設計装置、ネットワーク設計方法およびネットワーク設計プログラム
WO2012144987A1 (en) * 2011-04-19 2012-10-26 Hewlett-Packard Development Company, L.P. Computing a performance characteristic of a network device
JP6269115B2 (ja) * 2014-02-05 2018-01-31 富士通株式会社 管理装置、管理方法、および管理プログラム

Also Published As

Publication number Publication date
JP2018148382A (ja) 2018-09-20

Similar Documents

Publication Publication Date Title
US11677622B2 (en) Modifying resource allocation or policy responsive to control information from a virtual network function
Son et al. SLA-aware and energy-efficient dynamic overbooking in SDN-based cloud data centers
Yu et al. Stochastic load balancing for virtual resource management in datacenters
EP3053041B1 (en) Method, system, computer program and computer program product for monitoring data packet flows between virtual machines, vms, within a data centre
US8863138B2 (en) Application service performance in cloud computing
US10178011B2 (en) Network traffic management via network switch QoS parameters analysis
JP5954074B2 (ja) 情報処理方法、情報処理装置、及びプログラム。
WO2016134542A1 (zh) 虚拟机的迁移方法、装置及设备
KR20150132774A (ko) 애플리케이션에 따라 네트워크 자원을 할당하는 방법 및 장치
US20150263960A1 (en) Method and apparatus for cloud bursting and cloud balancing of instances across clouds
US20170214598A1 (en) Test device, network system, and test method
JP2013152553A (ja) リソース管理装置、リソース管理システム、リソース管理方法およびリソース管理プログラム
KR20170120335A (ko) 네트워크 기능 가상화 시스템 상의 컴퓨팅 리소스 관리 장치 및 방법
Maziku et al. Towards a network aware VM migration: Evaluating the cost of VM migration in cloud data centers
EP3384388A1 (en) Technique for optimizing the scaling of an application having a set of virtual machines
KR101448413B1 (ko) Atca-기반 장비에서 통신 트래픽을 스케줄링하기 위한 방법 및 장치
KR101256918B1 (ko) 클라우드 서비스의 확장성과 가용성을 향상시키는 방법 및 그 시스템
JP6834604B2 (ja) ネットワークリソース管理装置、方法およびプログラム
US20220004419A1 (en) Resource determination device, method, and program
JP2018519753A (ja) マルチテナント型データセンタにおけるvmからvmのトラフィック推定
EP2775400B1 (en) Ressource management system a method
JP6186287B2 (ja) システムの管理サーバ及び制御方法
Wang et al. Scheduling network function chains under sub-millisecond latency slos
WO2017071780A1 (en) Methods and systems of mapping virtual machine communication paths
KR101737468B1 (ko) 가상화 환경에서의 자원 관리 장치 및 방법

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20200204

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20201223

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20210105

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20210118

R150 Certificate of patent or registration of utility model

Ref document number: 6834604

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150