(57)【要約】【課題】仮想化構成のサーバにおいて、リソースをより有効に利用し、不要なトラヒック破棄を抑制する。【解決手段】仮想化部１１のＣＰＵ使用率が制御開始しきい値に達し、仮想サーバＡ，ＢそれぞれのＣＰＵ使用率のいずれもが仮想サーバのしきい値に達した場合に、仮想サーバＡ，Ｂ間でＣＰＵ使用率の均衡がとれるように輻輳制御を開始する。さらに、仮想化部１１のＣＰＵ使用率が所定の増加傾向以上の場合に輻輳制御を開始する。これにより、リソースを有効利用することができ、不要なトラヒック破棄を抑制できる。【選択図】図４
2019009709.tif 000002
【特許請求の範囲】
【請求項１】
仮想化構成で動作する複数の仮想サーバの輻輳を制御する輻輳制御装置であって、
前記複数の仮想サーバが動作する物理サーバのリソース使用量と前記複数の仮想サーバそれぞれのリソース使用量を取得する取得手段と、
前記物理サーバのリソース使用量が第１しきい値に達し、かつ、前記複数の仮想サーバそれぞれのリソース使用量のいずれもが第２しきい値に達した場合、前記複数の仮想サーバそれぞれのリソース使用量に基づいて前記複数の仮想サーバそれぞれが受信する新規呼の数を規制する規制手段と、
を有することを特徴とする輻輳制御装置。
【請求項２】
前記規制手段は、前記物理サーバのリソース使用量又は前記複数の仮想サーバの受信する新規呼の数が所定の増加傾向以上の場合に前記新規呼の数を規制することを特徴とする請求項１に記載の輻輳制御装置。
【請求項３】
仮想化構成で動作する複数の仮想サーバの輻輳を制御する輻輳制御方法であって、
前記複数の仮想サーバが動作する物理サーバのリソース使用量と前記複数の仮想サーバそれぞれのリソース使用量を取得するステップと、
前記物理サーバのリソース使用量が第１しきい値に達し、かつ、前記複数の仮想サーバそれぞれのリソース使用量のいずれもが第２しきい値に達した場合、前記複数の仮想サーバそれぞれのリソース使用量に基づいて前記複数の仮想サーバそれぞれが受信する新規呼の数を規制するステップと、
を有することを特徴とする輻輳制御方法。
【請求項４】
前記規制するステップは、前記物理サーバのリソース使用量又は前記複数の仮想サーバの受信する新規呼の数が所定の増加傾向以上の場合に前記新規呼の数を規制することを特徴とする請求項３に記載の輻輳制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、仮想化構成のサーバにおいて輻輳を制御する技術に関する。
【背景技術】
【０００２】
従来、音声通信サーバは１つのハードウェア上で１つのアプリケーションを動作させて構成していた。この構成における輻輳制御では、ハードウェア性能の限界値に基づいてＣＰＵ使用率の上限値を設定しておき、ＣＰＵ使用率が上限値に到達または近づいた際、新規呼を受け付けずに破棄する。
【０００３】
仮想化技術の浸透により、１つのハードウェア上で複数のアプリケーションを動作させる傾向にある。非特許文献１には、仮想化構成の呼処理サーバにおける輻輳制御技術が記載されている。非特許文献１の輻輳制御では、ハードウェアのＣＰＵ使用率がしきい値に達すると、仮想サーバそれぞれのＣＰＵ使用率に基づいて新規呼の受信量の度合いを調整する。これにより、仮想サーバ間でＣＰＵ使用率の均衡をとりつつ、リソースを有効活用することができる。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】丸山、外６名、「呼処理サーバ仮想化構成における輻輳制御技術」、２０１６年ソサイエティ大会講演論文集、一般社団法人電子情報通信学会、２０１６年、Ｂ−６−２５
【発明の概要】
【発明が解決しようとする課題】
【０００５】
非特許文献１の輻輳制御では、各仮想サーバの受信する新規呼の数がいずれも増加する状況においては、仮想サーバ間のリソースの均衡利用とリソースの有効活用を達成することができた。
【０００６】
しかしながら、一部の仮想サーバの受信する新規呼の数が増加しない状況、及び各仮想サーバの受信する新規呼の数がいずれも減少する状況においては、非特許文献１の輻輳制御では、ハードウェア性能を十分に利用できず、不要なトラヒック破棄が生じるという問題があった。
【０００７】
本発明は、上記に鑑みてなされたものであり、仮想化構成のサーバにおいて、リソースをより有効に利用し、不要なトラヒック破棄を抑制することを目的とする。
【課題を解決するための手段】
【０００８】
第１の本発明に係る輻輳制御装置は、仮想化構成で動作する複数の仮想サーバの輻輳を制御する輻輳制御装置であって、前記複数の仮想サーバが動作する物理サーバのリソース使用量と前記複数の仮想サーバそれぞれのリソース使用量を取得する取得手段と、前記物理サーバのリソース使用量が第１しきい値に達し、かつ、前記複数の仮想サーバそれぞれのリソース使用量のいずれもが第２しきい値に達した場合、前記複数の仮想サーバそれぞれのリソース使用量に基づいて前記複数の仮想サーバそれぞれが受信する新規呼の数を規制する規制手段と、を有することを特徴とする。
【０００９】
上記輻輳制御装置において、前記規制手段は、前記物理サーバのリソース使用量又は前記複数の仮想サーバの受信する新規呼の数が所定の増加傾向以上の場合に前記新規呼の数を規制することを特徴とする。
【００１０】
第２の本発明に係る輻輳制御方法は、仮想化構成で動作する複数の仮想サーバの輻輳を制御する輻輳制御方法であって、前記複数の仮想サーバが動作する物理サーバのリソース使用量と前記複数の仮想サーバそれぞれのリソース使用量を取得するステップと、前記物理サーバのリソース使用量が第１しきい値に達し、かつ、前記複数の仮想サーバそれぞれのリソース使用量のいずれもが第２しきい値に達した場合、前記複数の仮想サーバそれぞれのリソース使用量に基づいて前記複数の仮想サーバそれぞれが受信する新規呼の数を規制するステップと、を有することを特徴とする。
【００１１】
上記輻輳制御方法において、前記規制するステップは、前記物理サーバのリソース使用量又は前記複数の仮想サーバの受信する新規呼の数が所定の増加傾向以上の場合に前記新規呼の数を規制することを特徴とする。
【発明の効果】
【００１２】
本発明によれば、仮想化構成のサーバにおいて、リソースをより有効に利用し、不要なトラヒック破棄を抑制することができる。
【図面の簡単な説明】
【００１３】
【図１】本実施形態の輻輳制御装置の構成を示す機能ブロック図である。
【図２】物理サーバ、仮想サーバのＣＰＵ使用率の変化を示すグラフである。
【図３】物理サーバのＣＰＵ使用率の変化の例を示すグラフである。
【図４】本実施形態の輻輳制御装置の輻輳制御開始の判定処理の流れを示すフローチャートである。
【図５】第１のケースにおいて仮想サーバに入力されるトラヒック量の変化を示す図である。
【図６】第１のケースを従来方法で輻輳制御した場合のシミュレーション結果を示す図である。
【図７】第１のケースを本実施形態の方法で輻輳制御した場合のシミュレーション結果を示す図である。
【図８】第２のケースにおいて仮想サーバに入力されるトラヒック量の変化を示す図である。
【図９】第２のケースを従来方法で輻輳制御した場合のシミュレーション結果を示す図である。
【図１０】第２のケースを本実施形態の方法で輻輳制御した場合のシミュレーション結果を示す図である。
【発明を実施するための形態】
【００１４】
以下、本発明の実施の形態について図面を用いて説明する。
【００１５】
図１は、本実施形態の輻輳制御装置の構成を示す機能ブロック図である。図１に示す輻輳制御装置１は、仮想化部１１、取得部１２、及び規制部１３を備える。
【００１６】
仮想化部１１は、仮想化技術を用いて、１つのハードウェア（物理サーバ）のリソースを共有して複数の仮想サーバＡ，Ｂを動作させる。本実施形態の仮想サーバＡ，Ｂは、新規呼を受信して所定の呼処理を実行する呼処理サーバである。なお、図１では仮想サーバＡ，Ｂの２つのみを図示しているが、仮想化部１１上で動作する仮想サーバＡ，Ｂの数を２台に限定するものではない。
【００１７】
取得部１２は、仮想化部１１の使用するリソース（ＣＰＵ、メモリなど）の使用量・使用率（以下、リソース使用量又はＣＰＵ使用率と呼ぶ）と仮想サーバＡ，Ｂそれぞれのリソース使用量を取得する。仮想化部１１のリソース使用量は、仮想サーバＡ，Ｂそれぞれのリソース使用量を合計して求めてもよい。
【００１８】
取得部１２は、仮想化部１１のリソース使用量の増減傾向を求める。なお、仮想サーバＡ，Ｂで処理する新規呼の量が増加すれば仮想化部１１のリソース使用量も増加するので、取得部１２は、仮想サーバＡ，Ｂが受信する新規呼の量を取得し、新規呼の増減傾向を求めてもよい。
【００１９】
規制部１３は、仮想化部１１のリソース使用量が制御開始しきい値に達し、仮想サーバＡ，Ｂのリソース使用量のそれぞれが仮想サーバのしきい値に達し、かつ、仮想化部１１のリソース使用量の増加傾向が所定以上の場合、仮想サーバＡ，Ｂそれぞれのリソース使用量に基づいて新規呼の受信を規制する輻輳制御を開始する。つまり、仮想化部１１、仮想サーバＡ，Ｂのいずれかのリソース使用量が所定のしきい値に達していない場合は、規制部１３は輻輳制御を開始しない。また、仮想化部１１のリソース使用量の増加傾向が所定以上でない場合は、規制部１３は輻輳制御を開始しない。
【００２０】
また、規制部１３は、仮想化部１１のリソース使用量がハードウェアしきい値に達した場合、全ての仮想サーバＡ，Ｂで新規呼を受け付けない輻輳制御を開始する。
【００２１】
なお、制御開始しきい値は、仮想サーバのしきい値より高く設定し、ハードウェアしきい値は、制御開始しきい値より高く、仮想化部１１の性能限界より低く設定する。仮想サーバのしきい値は、仮想サーバＡ，Ｂで共通にしてもよいし、仮想サーバＡ，Ｂごとに違う値を設定してもよい。
【００２２】
ここで、リソース使用量に基づく輻輳制御の開始判定について説明する。
【００２３】
図２は、物理サーバ（仮想化部１１）、仮想サーバＡ，ＢのＣＰＵ使用率の変化を示すグラフである。図２には、物理サーバのＣＰＵ使用率に対する制御開始しきい値と、仮想サーバＡ，ＢのＣＰＵ使用率に対する仮想サーバのしきい値を図示している。
【００２４】
図２の例では、時刻ｔ１において仮想サーバＢのＣＰＵ使用率が仮想サーバのしきい値を超え、時刻ｔ２において物理サーバのＣＰＵ使用率が制御開始しきい値を超えている。時刻ｔ２では、物理サーバのＣＰＵ使用率が制御開始しきい値を超えているが、仮想サーバＡのＣＰＵ使用率は仮想サーバのしきい値を超えていないので、規制部１３は、輻輳制御を開始しない。時刻ｔ３において仮想サーバＡのＣＰＵ使用率が仮想サーバのしきい値を超え、物理サーバ、仮想サーバＡ，ＢのＣＰＵ使用率のいずれもが所定のしきい値を超えているので、時刻ｔ３から輻輳制御を開始する。
【００２５】
続いて、リソース使用量の増減傾向の判定について説明する。
【００２６】
本実施形態では、リソース使用量の増減傾向の判定について、瞬間変動を考慮して、設定時間内のリソース使用量の和とその前の時間のリソース使用量の和で比較する。
【００２７】
図３は、物理サーバのＣＰＵ使用率の変化の例を示すグラフである。図３の例では、Δｔ３，Δｔ４，Δｔ５，Δｔ６のそれぞれの時刻におけるＣＰＵ使用率が４，４，１，７であった。
【００２８】
設定時間間隔を３、増加傾向の判定しきい値を２０％増として、Δｔ７時の増減傾向の判定について説明する。Δｔ４〜Δｔ６までの時間内のＣＰＵ使用率の和は４＋１＋７＝１２である。その前のΔｔ３〜Δｔ５までの時間内のＣＰＵ使用率の和は４＋４＋１＝９である。それぞれの和を比較すると、１２÷９＝１．３となり、２０％増の判定しきい値を超えた増加傾向であると判定される。
【００２９】
なお、新規呼の受信数の増減傾向を判定する場合も同様に適用できる。
【００３０】
次に、本実施形態の輻輳制御装置の動作について説明する。
【００３１】
図４は、本実施形態の輻輳制御装置の輻輳制御開始の判定処理の流れを示すフローチャートである。
【００３２】
規制部１３は、仮想化部１１のＣＰＵ使用率がハードウェアしきい値に達したか否か判定する（ステップＳ１１）。
【００３３】
仮想化部１１のＣＰＵ使用率がハードウェアしきい値に達してした場合（ステップＳ１１のＹＥＳ）、規制部１３は、全ての仮想サーバＡ，Ｂで新規呼の受信を受け付けない輻輳制御を開始する（ステップＳ１２）。
【００３４】
仮想化部１１のＣＰＵ使用率がハードウェアしきい値に達していない場合（ステップＳ１１のＮＯ）、規制部１３は、仮想化部１１のＣＰＵ使用率が制御開始しきい値に達したか否か、仮想サーバＡ，ＢのＣＰＵ使用率の全てが仮想サーバのしきい値に達したか否か、及び仮想化部１１のＣＰＵ使用率が所定の増加傾向であるか否かを判定する（ステップＳ１３〜Ｓ１５）。
【００３５】
ステップＳ１３〜Ｓ１５のいずれかの条件を満たさない場合（ステップＳ１３〜Ｓ１５のＮＯ）、規制部１３は輻輳制御を行わない。
【００３６】
ステップＳ１３〜Ｓ１５の全ての条件を満たす場合、規制部１３は、仮想サーバＡ，Ｂ間でＣＰＵ使用率の均衡がとれるように輻輳制御を開始する（ステップＳ１６）。
【００３７】
仮想サーバＡ，Ｂ間でＣＰＵ使用率の均衡がとれる輻輳制御は、例えば、以下の方法で行う。時刻Δｔ０において、仮想サーバＡと仮想サーバＢのＣＰＵ使用率がそれぞれＭ0，Ｎ0であったとする。時刻Δｔ１時に仮想サーバＡで受信した新規呼の数がａ1、仮想サーバＢで受信した新規呼の数がｂ1のとき、仮想サーバＡが処理する新規呼の数は、ｂ1×Ｎ0／Ｍ0（ただしａ1以下の値）とし、仮想サーバＢが処理する新規呼の数は、ａ1×Ｍ0／Ｎ0（ただしｂ1以下の値）とする。処理できない新規呼は破棄する。次の時刻Δｔ２では、時刻Δｔ１時の仮想サーバＡ，ＢのＣＰＵ使用率Ｍ1，Ｎ1を用い、時刻Δｔ２時に受信する新規呼の数ａ2，ｂ2に基づいて、仮想サーバＡ，Ｂで処理する新規呼の数を決定する。
【００３８】
輻輳制御を開始した後、仮想化部１１のＣＰＵ使用率がハードウェアしきい値を下回った場合は、ステップＳ１２の新規呼を受け付けない輻輳制御を停止する。
【００３９】
ステップＳ１３〜Ｓ１５のいずれかの条件を満たさなくなった場合は、ステップＳ１６の仮想サーバＡ，Ｂ間でＣＰＵ使用率の均衡をとる輻輳制御を停止する。
【００４０】
次に、本実施形態で改善した、従来方法ではハードウェア性能を十分に利用できない２つのケースについて説明する。
【００４１】
下記の考えに基づき、従来方法と本実施形態のＣＰＵ使用率のシミュレーションを行った。
【００４２】
・ＣＰＵ使用率は処理トラヒック量に比例して増加
・処理トラヒック量は一定の割合で減少
【００４３】
例えば、Δｔ０時の処理トラヒック量が１００で、Δｔ１時の入力トラヒック量が３０であり、各時間における処理トラヒック量の減少率が１０％であったとする。このとき、Δｔ１時のＣＰＵ使用率は１００×（１−０．１）＋３０＝１２０で計算する。
【００４４】
第１のケースは、仮想サーバＡは入力トラヒック量が増減せず、仮想サーバＢは入力トラヒック量が増加するケースである。
【００４５】
図５は、第１のケースにおいて仮想サーバＡ，Ｂに入力されるトラヒック量の変化を示している。横軸は時間、縦軸は入力トラヒック量である。
【００４６】
図６に、第１のケースを従来方法で輻輳制御した場合のシミュレーション結果を示す。横軸に時間、縦軸にＣＰＵ使用率をとり、仮想サーバＡ，ＢのＣＰＵ使用率と物理サーバのＣＰＵ使用率の変化を示している。
【００４７】
図６に示すように、従来方法では、物理サーバのＣＰＵ使用率が制御開始しきい値に達すると、仮想サーバＡ，Ｂ間でＣＰＵ使用率の均衡をとる輻輳制御が開始する。そのため、物理サーバのＣＰＵ使用率が制御開始しきい値付近で推移してしまい、物理サーバに余力のある場合であっても、輻輳制御により新規呼を破棄している。
【００４８】
図７に、第１のケースを本実施形態の方法で輻輳制御した場合のシミュレーション結果を示す。横軸に時間、縦軸にＣＰＵ使用率をとり、仮想サーバＡ，ＢのＣＰＵ使用率と物理サーバのＣＰＵ使用率の変化を示している。
【００４９】
図７に示すように、本実施形態では、物理サーバのＣＰＵ使用率が制御開始しきい値に達しても、仮想サーバＡ，ＢのいずれかのＣＰＵ使用率が仮想サーバのしきい値に達していない場合は、仮想サーバＡ，Ｂ間でＣＰＵ使用率の均衡をとる輻輳制御は開始しない。仮想サーバＡへの入力トラヒック量は増加しないので、仮想サーバＡのＣＰＵ使用率は仮想サーバのしきい値に達しない。仮想サーバＢのＣＰＵ使用率が増加することで、物理サーバのＣＰＵ使用率がハードウェアしきい値に達すると、全ての仮想サーバＡ，Ｂで新規呼を受け付けない輻輳制御が開始する。
【００５０】
第１のケースでは、本実施形態の輻輳制御により物理サーバのＣＰＵ使用率はハードウェアしきい値近辺で推移し、本実施形態は従来方法よりもリソースが有効利用されることがわかる。
【００５１】
第２のケースは、仮想サーバＡ，Ｂ両方の入力トラヒック量が減少するケースである。
【００５２】
図８は、第２のケースにおいて仮想サーバＡ，Ｂに入力されるトラヒック量の変化を示している。横軸は時間、縦軸は入力トラヒック量である。
【００５３】
図９に、第２のケースを従来方法で輻輳制御した場合のシミュレーション結果を示す。横軸に時間、縦軸にＣＰＵ使用率をとり、仮想サーバＡ，ＢのＣＰＵ使用率と物理サーバのＣＰＵ使用率の変化を示している。
【００５４】
図９に示すように、従来方法では、物理サーバのＣＰＵ使用率が制御開始しきい値に達すると、仮想サーバＡ，Ｂ間でＣＰＵ使用率の均衡をとる輻輳制御が開始する。そのため、物理サーバのＣＰＵ使用率が制御開始しきい値を超えている間は、入力トラヒック量が減少傾向であっても輻輳制御されて、新規呼を破棄する。
【００５５】
図１０に、第２のケースを本実施形態の方法で輻輳制御した場合のシミュレーション結果を示す。横軸に時間、縦軸にＣＰＵ使用率をとり、仮想サーバＡ，ＢのＣＰＵ使用率と物理サーバのＣＰＵ使用率の変化を示している。
【００５６】
図１０に示すように、本実施形態では、物理サーバ及び仮想サーバＡ，ＢのＣＰＵ使用率が所定のしきい値に達していても、入力トラヒック量が減少傾向であるので、仮想サーバＡ，Ｂ間でＣＰＵ使用率の均衡をとる輻輳制御を開始しない。物理サーバのＣＰＵ使用率が制御開始しきい値を超えても輻輳制御しないので新規呼は破棄されない。入力トラヒック量は減少傾向であるので、輻輳制御しなくても、仮想サーバＡ，Ｂで処理すべき処理トラヒック量が減り、ＣＰＵ使用率も減少する。
【００５７】
第２のケースでは、本実施形態は、入力トラヒック量が減少傾向であるときは輻輳制御しないので、本実施形態は従来方法よりもリソースが有効利用されることがわかる。
【００５８】
以上説明したように、本実施形態によれば、仮想化部１１のＣＰＵ使用率が制御開始しきい値に達し、仮想サーバＡ，ＢそれぞれのＣＰＵ使用率のいずれもが仮想サーバのしきい値に達した場合に、仮想サーバＡ，Ｂ間でＣＰＵ使用率の均衡がとれるように輻輳制御を開始することにより、仮想サーバＡ，Ｂのいずれかの入力トラヒック量が少ない場合は輻輳制御を開始しないので、リソースを有効利用することができ、不要なトラヒック破棄を抑制できる。
【００５９】
本実施形態によれば、仮想化部１１のＣＰＵ使用率が所定の増加傾向以上の場合に輻輳制御を開始することで、仮想サーバＡ，Ｂの入力トラヒック量が減少する状況では輻輳制御を開始しないので、リソースを有効利用することができ、不要なトラヒック破棄を抑制できる
【符号の説明】
【００６０】
１…輻輳制御装置
１１…仮想化部
１２…取得部
１３…規制部
【図１】
2019009709.tif 000003
【図２】
2019009709.tif 000004
【図３】
2019009709.tif 000005
【図４】
2019009709.tif 000006
【図５】
2019009709.tif 000007
【図６】
2019009709.tif 000008
【図７】
2019009709.tif 000009
【図８】
2019009709.tif 000010
【図９】
2019009709.tif 000011
【図１０】
2019009709.tif 000012