JP6718844B2 - 輻輳制御装置及び輻輳制御方法 - Google Patents

Description

本発明は、仮想化構成のサーバにおいて輻輳を制御する技術に関する。

従来、音声通信サーバは１つのハードウェア上で１つのアプリケーションを動作させて構成していた。この構成における輻輳制御では、ハードウェア性能の限界値に基づいてＣＰＵ使用率の上限値を設定しておき、ＣＰＵ使用率が上限値に到達または近づいた際、新規呼を受け付けずに破棄する。

仮想化技術の浸透により、１つのハードウェア上で複数のアプリケーションを動作させる傾向にある。非特許文献１には、仮想化構成の呼処理サーバにおける輻輳制御技術が記載されている。非特許文献１の輻輳制御では、ハードウェアのＣＰＵ使用率がしきい値に達すると、仮想サーバそれぞれのＣＰＵ使用率に基づいて新規呼の受信量の度合いを調整する。これにより、仮想サーバ間でＣＰＵ使用率の均衡をとりつつ、リソースを有効活用することができる。

丸山、外６名、「呼処理サーバ仮想化構成における輻輳制御技術」、２０１６年ソサイエティ大会講演論文集、一般社団法人電子情報通信学会、２０１６年、Ｂ−６−２５

非特許文献１の輻輳制御では、各仮想サーバの受信する新規呼の数がいずれも増加する状況においては、仮想サーバ間のリソースの均衡利用とリソースの有効活用を達成することができた。

しかしながら、一部の仮想サーバの受信する新規呼の数が増加しない状況、及び各仮想サーバの受信する新規呼の数がいずれも減少する状況においては、非特許文献１の輻輳制御では、ハードウェア性能を十分に利用できず、不要なトラヒック破棄が生じるという問題があった。

本発明は、上記に鑑みてなされたものであり、仮想化構成のサーバにおいて、リソースをより有効に利用し、不要なトラヒック破棄を抑制することを目的とする。

第１の本発明に係る輻輳制御装置は、仮想化構成で動作する複数の仮想サーバの輻輳を制御する輻輳制御装置であって、前記複数の仮想サーバが動作する物理サーバのリソース使用量と前記複数の仮想サーバそれぞれのリソース使用量を取得する取得手段と、前記物理サーバのリソース使用量が第１しきい値に達し、かつ、前記複数の仮想サーバそれぞれのリソース使用量のいずれもが第２しきい値に達した場合、前記複数の仮想サーバそれぞれのリソース使用量に基づいて前記複数の仮想サーバそれぞれが受信する新規呼の数を規制する規制手段と、を有することを特徴とする。

上記輻輳制御装置において、前記規制手段は、前記物理サーバのリソース使用量又は前記複数の仮想サーバの受信する新規呼の数が所定の増加傾向以上の場合に前記新規呼の数を規制することを特徴とする。

第２の本発明に係る輻輳制御方法は、仮想化構成で動作する複数の仮想サーバの輻輳を制御する輻輳制御方法であって、前記複数の仮想サーバが動作する物理サーバのリソース使用量と前記複数の仮想サーバそれぞれのリソース使用量を取得するステップと、前記物理サーバのリソース使用量が第１しきい値に達し、かつ、前記複数の仮想サーバそれぞれのリソース使用量のいずれもが第２しきい値に達した場合、前記複数の仮想サーバそれぞれのリソース使用量に基づいて前記複数の仮想サーバそれぞれが受信する新規呼の数を規制するステップと、を有することを特徴とする。

上記輻輳制御方法において、前記規制するステップは、前記物理サーバのリソース使用量又は前記複数の仮想サーバの受信する新規呼の数が所定の増加傾向以上の場合に前記新規呼の数を規制することを特徴とする。

本発明によれば、仮想化構成のサーバにおいて、リソースをより有効に利用し、不要なトラヒック破棄を抑制することができる。

本実施形態の輻輳制御装置の構成を示す機能ブロック図である。 物理サーバ、仮想サーバのＣＰＵ使用率の変化を示すグラフである。 物理サーバのＣＰＵ使用率の変化の例を示すグラフである。 本実施形態の輻輳制御装置の輻輳制御開始の判定処理の流れを示すフローチャートである。 第１のケースにおいて仮想サーバに入力されるトラヒック量の変化を示す図である。 第１のケースを従来方法で輻輳制御した場合のシミュレーション結果を示す図である。 第１のケースを本実施形態の方法で輻輳制御した場合のシミュレーション結果を示す図である。 第２のケースにおいて仮想サーバに入力されるトラヒック量の変化を示す図である。 第２のケースを従来方法で輻輳制御した場合のシミュレーション結果を示す図である。 第２のケースを本実施形態の方法で輻輳制御した場合のシミュレーション結果を示す図である。

以下、本発明の実施の形態について図面を用いて説明する。

図１は、本実施形態の輻輳制御装置の構成を示す機能ブロック図である。図１に示す輻輳制御装置１は、仮想化部１１、取得部１２、及び規制部１３を備える。

仮想化部１１は、仮想化技術を用いて、１つのハードウェア（物理サーバ）のリソースを共有して複数の仮想サーバＡ，Ｂを動作させる。本実施形態の仮想サーバＡ，Ｂは、新規呼を受信して所定の呼処理を実行する呼処理サーバである。なお、図１では仮想サーバＡ，Ｂの２つのみを図示しているが、仮想化部１１上で動作する仮想サーバＡ，Ｂの数を２台に限定するものではない。

取得部１２は、仮想化部１１の使用するリソース（ＣＰＵ、メモリなど）の使用量・使用率（以下、リソース使用量又はＣＰＵ使用率と呼ぶ）と仮想サーバＡ，Ｂそれぞれのリソース使用量を取得する。仮想化部１１のリソース使用量は、仮想サーバＡ，Ｂそれぞれのリソース使用量を合計して求めてもよい。

取得部１２は、仮想化部１１のリソース使用量の増減傾向を求める。なお、仮想サーバＡ，Ｂで処理する新規呼の量が増加すれば仮想化部１１のリソース使用量も増加するので、取得部１２は、仮想サーバＡ，Ｂが受信する新規呼の量を取得し、新規呼の増減傾向を求めてもよい。

規制部１３は、仮想化部１１のリソース使用量が制御開始しきい値に達し、仮想サーバＡ，Ｂのリソース使用量のそれぞれが仮想サーバのしきい値に達し、かつ、仮想化部１１のリソース使用量の増加傾向が所定以上の場合、仮想サーバＡ，Ｂそれぞれのリソース使用量に基づいて新規呼の受信を規制する輻輳制御を開始する。つまり、仮想化部１１、仮想サーバＡ，Ｂのいずれかのリソース使用量が所定のしきい値に達していない場合は、規制部１３は輻輳制御を開始しない。また、仮想化部１１のリソース使用量の増加傾向が所定以上でない場合は、規制部１３は輻輳制御を開始しない。

また、規制部１３は、仮想化部１１のリソース使用量がハードウェアしきい値に達した場合、全ての仮想サーバＡ，Ｂで新規呼を受け付けない輻輳制御を開始する。

なお、制御開始しきい値は、仮想サーバのしきい値より高く設定し、ハードウェアしきい値は、制御開始しきい値より高く、仮想化部１１の性能限界より低く設定する。仮想サーバのしきい値は、仮想サーバＡ，Ｂで共通にしてもよいし、仮想サーバＡ，Ｂごとに違う値を設定してもよい。

ここで、リソース使用量に基づく輻輳制御の開始判定について説明する。

図２は、物理サーバ（仮想化部１１）、仮想サーバＡ，ＢのＣＰＵ使用率の変化を示すグラフである。図２には、物理サーバのＣＰＵ使用率に対する制御開始しきい値と、仮想サーバＡ，ＢのＣＰＵ使用率に対する仮想サーバのしきい値を図示している。

図２の例では、時刻ｔ１において仮想サーバＢのＣＰＵ使用率が仮想サーバのしきい値を超え、時刻ｔ２において物理サーバのＣＰＵ使用率が制御開始しきい値を超えている。時刻ｔ２では、物理サーバのＣＰＵ使用率が制御開始しきい値を超えているが、仮想サーバＡのＣＰＵ使用率は仮想サーバのしきい値を超えていないので、規制部１３は、輻輳制御を開始しない。時刻ｔ３において仮想サーバＡのＣＰＵ使用率が仮想サーバのしきい値を超え、物理サーバ、仮想サーバＡ，ＢのＣＰＵ使用率のいずれもが所定のしきい値を超えているので、時刻ｔ３から輻輳制御を開始する。

続いて、リソース使用量の増減傾向の判定について説明する。

本実施形態では、リソース使用量の増減傾向の判定について、瞬間変動を考慮して、設定時間内のリソース使用量の和とその前の時間のリソース使用量の和で比較する。

図３は、物理サーバのＣＰＵ使用率の変化の例を示すグラフである。図３の例では、Δｔ３，Δｔ４，Δｔ５，Δｔ６のそれぞれの時刻におけるＣＰＵ使用率が４，４，１，７であった。

設定時間間隔を３、増加傾向の判定しきい値を２０％増として、Δｔ７時の増減傾向の判定について説明する。Δｔ４〜Δｔ６までの時間内のＣＰＵ使用率の和は４＋１＋７＝１２である。その前のΔｔ３〜Δｔ５までの時間内のＣＰＵ使用率の和は４＋４＋１＝９である。それぞれの和を比較すると、１２÷９＝１．３となり、２０％増の判定しきい値を超えた増加傾向であると判定される。

なお、新規呼の受信数の増減傾向を判定する場合も同様に適用できる。

次に、本実施形態の輻輳制御装置の動作について説明する。

図４は、本実施形態の輻輳制御装置の輻輳制御開始の判定処理の流れを示すフローチャートである。

規制部１３は、仮想化部１１のＣＰＵ使用率がハードウェアしきい値に達したか否か判定する（ステップＳ１１）。

仮想化部１１のＣＰＵ使用率がハードウェアしきい値に達してした場合（ステップＳ１１のＹＥＳ）、規制部１３は、全ての仮想サーバＡ，Ｂで新規呼の受信を受け付けない輻輳制御を開始する（ステップＳ１２）。

仮想化部１１のＣＰＵ使用率がハードウェアしきい値に達していない場合（ステップＳ１１のＮＯ）、規制部１３は、仮想化部１１のＣＰＵ使用率が制御開始しきい値に達したか否か、仮想サーバＡ，ＢのＣＰＵ使用率の全てが仮想サーバのしきい値に達したか否か、及び仮想化部１１のＣＰＵ使用率が所定の増加傾向であるか否かを判定する（ステップＳ１３〜Ｓ１５）。

ステップＳ１３〜Ｓ１５のいずれかの条件を満たさない場合（ステップＳ１３〜Ｓ１５のＮＯ）、規制部１３は輻輳制御を行わない。

ステップＳ１３〜Ｓ１５の全ての条件を満たす場合、規制部１３は、仮想サーバＡ，Ｂ間でＣＰＵ使用率の均衡がとれるように輻輳制御を開始する（ステップＳ１６）。

仮想サーバＡ，Ｂ間でＣＰＵ使用率の均衡がとれる輻輳制御は、例えば、以下の方法で行う。時刻Δｔ０において、仮想サーバＡと仮想サーバＢのＣＰＵ使用率がそれぞれＭ₀，Ｎ₀であったとする。時刻Δｔ１時に仮想サーバＡで受信した新規呼の数がａ₁、仮想サーバＢで受信した新規呼の数がｂ₁のとき、仮想サーバＡが処理する新規呼の数は、ｂ₁×Ｎ₀／Ｍ₀（ただしａ₁以下の値）とし、仮想サーバＢが処理する新規呼の数は、ａ₁×Ｍ₀／Ｎ₀（ただしｂ₁以下の値）とする。処理できない新規呼は破棄する。次の時刻Δｔ２では、時刻Δｔ１時の仮想サーバＡ，ＢのＣＰＵ使用率Ｍ₁，Ｎ₁を用い、時刻Δｔ２時に受信する新規呼の数ａ₂，ｂ₂に基づいて、仮想サーバＡ，Ｂで処理する新規呼の数を決定する。

輻輳制御を開始した後、仮想化部１１のＣＰＵ使用率がハードウェアしきい値を下回った場合は、ステップＳ１２の新規呼を受け付けない輻輳制御を停止する。

ステップＳ１３〜Ｓ１５のいずれかの条件を満たさなくなった場合は、ステップＳ１６の仮想サーバＡ，Ｂ間でＣＰＵ使用率の均衡をとる輻輳制御を停止する。

次に、本実施形態で改善した、従来方法ではハードウェア性能を十分に利用できない２つのケースについて説明する。

下記の考えに基づき、従来方法と本実施形態のＣＰＵ使用率のシミュレーションを行った。

・ＣＰＵ使用率は処理トラヒック量に比例して増加
・処理トラヒック量は一定の割合で減少

例えば、Δｔ０時の処理トラヒック量が１００で、Δｔ１時の入力トラヒック量が３０であり、各時間における処理トラヒック量の減少率が１０％であったとする。このとき、Δｔ１時のＣＰＵ使用率は１００×（１−０．１）＋３０＝１２０で計算する。

第１のケースは、仮想サーバＡは入力トラヒック量が増減せず、仮想サーバＢは入力トラヒック量が増加するケースである。

図５は、第１のケースにおいて仮想サーバＡ，Ｂに入力されるトラヒック量の変化を示している。横軸は時間、縦軸は入力トラヒック量である。

図６に、第１のケースを従来方法で輻輳制御した場合のシミュレーション結果を示す。横軸に時間、縦軸にＣＰＵ使用率をとり、仮想サーバＡ，ＢのＣＰＵ使用率と物理サーバのＣＰＵ使用率の変化を示している。

図６に示すように、従来方法では、物理サーバのＣＰＵ使用率が制御開始しきい値に達すると、仮想サーバＡ，Ｂ間でＣＰＵ使用率の均衡をとる輻輳制御が開始する。そのため、物理サーバのＣＰＵ使用率が制御開始しきい値付近で推移してしまい、物理サーバに余力のある場合であっても、輻輳制御により新規呼を破棄している。

図７に、第１のケースを本実施形態の方法で輻輳制御した場合のシミュレーション結果を示す。横軸に時間、縦軸にＣＰＵ使用率をとり、仮想サーバＡ，ＢのＣＰＵ使用率と物理サーバのＣＰＵ使用率の変化を示している。

図７に示すように、本実施形態では、物理サーバのＣＰＵ使用率が制御開始しきい値に達しても、仮想サーバＡ，ＢのいずれかのＣＰＵ使用率が仮想サーバのしきい値に達していない場合は、仮想サーバＡ，Ｂ間でＣＰＵ使用率の均衡をとる輻輳制御は開始しない。仮想サーバＡへの入力トラヒック量は増加しないので、仮想サーバＡのＣＰＵ使用率は仮想サーバのしきい値に達しない。仮想サーバＢのＣＰＵ使用率が増加することで、物理サーバのＣＰＵ使用率がハードウェアしきい値に達すると、全ての仮想サーバＡ，Ｂで新規呼を受け付けない輻輳制御が開始する。

第１のケースでは、本実施形態の輻輳制御により物理サーバのＣＰＵ使用率はハードウェアしきい値近辺で推移し、本実施形態は従来方法よりもリソースが有効利用されることがわかる。

第２のケースは、仮想サーバＡ，Ｂ両方の入力トラヒック量が減少するケースである。

図８は、第２のケースにおいて仮想サーバＡ，Ｂに入力されるトラヒック量の変化を示している。横軸は時間、縦軸は入力トラヒック量である。

図９に、第２のケースを従来方法で輻輳制御した場合のシミュレーション結果を示す。横軸に時間、縦軸にＣＰＵ使用率をとり、仮想サーバＡ，ＢのＣＰＵ使用率と物理サーバのＣＰＵ使用率の変化を示している。

図９に示すように、従来方法では、物理サーバのＣＰＵ使用率が制御開始しきい値に達すると、仮想サーバＡ，Ｂ間でＣＰＵ使用率の均衡をとる輻輳制御が開始する。そのため、物理サーバのＣＰＵ使用率が制御開始しきい値を超えている間は、入力トラヒック量が減少傾向であっても輻輳制御されて、新規呼を破棄する。

図１０に、第２のケースを本実施形態の方法で輻輳制御した場合のシミュレーション結果を示す。横軸に時間、縦軸にＣＰＵ使用率をとり、仮想サーバＡ，ＢのＣＰＵ使用率と物理サーバのＣＰＵ使用率の変化を示している。

図１０に示すように、本実施形態では、物理サーバ及び仮想サーバＡ，ＢのＣＰＵ使用率が所定のしきい値に達していても、入力トラヒック量が減少傾向であるので、仮想サーバＡ，Ｂ間でＣＰＵ使用率の均衡をとる輻輳制御を開始しない。物理サーバのＣＰＵ使用率が制御開始しきい値を超えても輻輳制御しないので新規呼は破棄されない。入力トラヒック量は減少傾向であるので、輻輳制御しなくても、仮想サーバＡ，Ｂで処理すべき処理トラヒック量が減り、ＣＰＵ使用率も減少する。

第２のケースでは、本実施形態は、入力トラヒック量が減少傾向であるときは輻輳制御しないので、本実施形態は従来方法よりもリソースが有効利用されることがわかる。

以上説明したように、本実施形態によれば、仮想化部１１のＣＰＵ使用率が制御開始しきい値に達し、仮想サーバＡ，ＢそれぞれのＣＰＵ使用率のいずれもが仮想サーバのしきい値に達した場合に、仮想サーバＡ，Ｂ間でＣＰＵ使用率の均衡がとれるように輻輳制御を開始することにより、仮想サーバＡ，Ｂのいずれかの入力トラヒック量が少ない場合は輻輳制御を開始しないので、リソースを有効利用することができ、不要なトラヒック破棄を抑制できる。

本実施形態によれば、仮想化部１１のＣＰＵ使用率が所定の増加傾向以上の場合に輻輳制御を開始することで、仮想サーバＡ，Ｂの入力トラヒック量が減少する状況では輻輳制御を開始しないので、リソースを有効利用することができ、不要なトラヒック破棄を抑制できる

１…輻輳制御装置
１１…仮想化部
１２…取得部
１３…規制部

Claims (4)

1. 仮想化構成で動作する複数の仮想サーバの輻輳を制御する輻輳制御装置であって、
   前記複数の仮想サーバが動作する物理サーバのリソース使用量と前記複数の仮想サーバそれぞれのリソース使用量を取得する取得手段と、
   前記物理サーバのリソース使用量が第１しきい値に達し、かつ、前記複数の仮想サーバそれぞれのリソース使用量のいずれもが第２しきい値に達した場合、前記複数の仮想サーバそれぞれのリソース使用量に基づいて前記複数の仮想サーバそれぞれが受信する新規呼の数を規制する規制手段と、
   を有することを特徴とする輻輳制御装置。
2. 前記規制手段は、前記物理サーバのリソース使用量又は前記複数の仮想サーバの受信する新規呼の数が所定の増加傾向以上の場合に前記新規呼の数を規制することを特徴とする請求項１に記載の輻輳制御装置。
3. 仮想化構成で動作する複数の仮想サーバの輻輳を制御する輻輳制御方法であって、
   前記複数の仮想サーバが動作する物理サーバのリソース使用量と前記複数の仮想サーバそれぞれのリソース使用量を取得するステップと、
   前記物理サーバのリソース使用量が第１しきい値に達し、かつ、前記複数の仮想サーバそれぞれのリソース使用量のいずれもが第２しきい値に達した場合、前記複数の仮想サーバそれぞれのリソース使用量に基づいて前記複数の仮想サーバそれぞれが受信する新規呼の数を規制するステップと、
   を有することを特徴とする輻輳制御方法。
4. 前記規制するステップは、前記物理サーバのリソース使用量又は前記複数の仮想サーバの受信する新規呼の数が所定の増加傾向以上の場合に前記新規呼の数を規制することを特徴とする請求項３に記載の輻輳制御方法。

Images