クラウド負荷分散

こんにちは、Habr！ 本日は、クラウドでの負荷分散の問題を提起するか、ホスト間の仮想マシンのライブマイグレーションに関する決定への新しいアプローチを議論したいと思います。クラウドコンピューティングの過負荷検出。」 本日、この記事の無料翻訳を公開しています。



クラウドコンピューティングの機能から抽象化すると、このアプローチは他のシステムの負荷分散の問題を解決するのに適用できます。 したがって、この記事が幅広い読者層にとって興味深いものになることを願っています。







クラウドコンピューティングの動的なワークロードは、過負荷または過負荷のホストから他のノードへの仮想マシンのライブマイグレーションを通じて制御し、エネルギーを節約し、サービスレベル契約（SLA）違反による損失を削減できます。 問題は、タイムリーなライブマイグレーションのために、将来のホスト輻輳の瞬間を正しく判断することです。

はじめに

クラウドコンピューティングは、リソースがサービスとして提供され、リースされ、リクエストに応じてネットワーク経由でユーザーが利用できるようにする有望なアプローチです。 広く使用されているクラウドコンピューティングビジネスモデルの1つは、Infrastructure as a Service（IaaS）です。 コンピューティングリソースは、消費されたリソースの料金を支払うユーザーに仮想マシン（以降VM）の形で提供されます。 XenやVMwareなどの仮想化ツールは、インフラストラクチャリソースを効率的に使用します。 仮想マシンにより、要件に応じてリソースを動的に割り当て、アプリケーションのパフォーマンスと電力消費を最適化できます。



リソースの動的な再割り当ての主な機会の1つは、仮想マシンのライブマイグレーションです。 クラウドプロバイダーは、混雑したホストから仮想マシンを移動し、特定のSLAでパフォーマンスを維持し、最小数のホストで動的に仮想マシンを統合して、低負荷でエネルギーを節約できます。 ライブマイグレーションとリアルタイムマイグレーションの決定を可能にするオンラインアルゴリズムを使用して、リソース割り当てをVM負荷に適合させ、SLAに沿ったVMパフォーマンスレベルを維持し、インフラストラクチャのエネルギー消費を削減することにより、クラウドリソースを効果的に管理できます。



ライブマイグレーションのコンテキストにおける重要な問題は、ホストの輻輳または負荷不足の状態の検出です。 最新のアプローチのほとんどは、リソースの使用を監視することに基づいており、実際の値または予測される次の値が所定のしきい値を超える場合、ノードは過負荷であると宣言されます。 ただし、ライブマイグレーションは、マイグレーションプロセス中のVMパフォーマンスの中断によって正当化される価格で提供されます。 既存のアプローチの問題は、リソース使用量の1つの測定値またはいくつかの将来の値によってホストの輻輳を検出すると、急いでの決定、ライブマイグレーションの不要なオーバーヘッド、およびVMの安定性の問題につながる可能性があることです。



より有望なのは、数ステップ先のリソース使用の予測に基づいたライブマイグレーションに関する意思決定アプローチです。 これにより、安定性が向上します。移行アクティビティが開始されるのは、負荷が複数の時間間隔で持続する場合だけでなく、クラウドプロバイダーがこれが発生する前に輻輳状態を予測できるためです。 一方、より遠い将来を予測すると、予測エラーと不確実性が増加しますが、長期予測のメリットは減少します。 もう1つの重要な問題は、SLA違反の可能性に対するペナルティが移行のオーバーヘッドを超える場合にのみ、ライブマイグレーションを実行する必要があるということです。



この記事では、予測の不確実性とライブマイグレーションのオーバーヘッドを考慮したリソース使用の長期予測に基づいて、ホストの輻輳または負荷不足を検出する新しいアプローチを紹介します。 次のことが行われました。

• クラウド内の仮想マシンのリソースの動的割り当てへの新しいアプローチが提示されます。 仮想マシンリソースのローカルおよびグローバル分散を組み合わせます。 ローカルリソース割り当てとは、現在の負荷に応じて仮想マシンの共有ホストリソースを割り当てることです。 グローバルリソース割り当ては、十分なVMパフォーマンスを確保するため、または電力を節約するためにホストの数を減らすために、ホストの過負荷または負荷不足の場合のライブマイグレーションと同等です。
  
  
  
  
• ノードの過負荷または過負荷を判断するために、リソース使用の長期予測に基づいた新しいアプローチが提案されています。 長期予測には、ガウス過程に基づいた教師による機械学習が使用されます。
  
  
  
  
• オンラインで過負荷を検出するときに長期予測の不確実性を考慮するために、核確率密度推定の方法を使用して予測誤差分布モデルが構築されます。
  
  
  
  
• 仮想マシンの移行のオーバーヘッドを考慮して、ユーティリティ関数に基づいて問題を解決する新しいアプローチが提案されています。 SLA違反に対するユーティリティの期待値（罰金）が移行の追加コストよりも大きい場合にのみ、ライブマイグレーションを開始します。

提案されたアプローチは、他のアプローチと実験的に比較されます。

• 短期予測に基づくアプローチ
• 不確実性を考慮せずに長期予測を行うアプローチ。
• 長期予測に基づくアプローチでは、予測の不確実性を考慮しますが、ライブマイグレーションのオーバーヘッドコストを考慮に入れる決定理論を使用しません。
• ローカル回帰法に基づいたアプローチで。

リソースマネージャーのアーキテクチャ

この作業は、複数の物理ノードで複数の仮想マシンが実行されるIaaSクラウド管理に焦点を当てています。 リソースマネージャとその主要コンポーネントの一般的なアーキテクチャを図1に示します。 1.各仮想マシンにはVMエージェントがあり、各時間間隔で仮想マシン上のリソースの分布を決定します。 各ホストには、すべてのVMエージェントのリソースの分配に関する決定を受け取り、最終的な割り当てを決定し、可能な競合を解決するホストエージェントがあります。 また、ノードの過負荷または過負荷を検出し、この情報をグローバルエージェントに渡します。 グローバルエージェントは、仮想マシンを過負荷または過負荷のホストからホストの統合に移動して、SLA違反の損失を減らし、物理ノードの数を減らすことにより、仮想マシンの移行の決定を開始します。 次のセクションでは、各リソースマネージャコンポーネントについて詳しく説明します。









図 1リソースマネージャーのアーキテクチャ

VMエージェント

仮想マシンエージェントは、独自の仮想マシンに分散する共有リソースを動的に定義することにより、ローカルリソース割り当ての決定を担当します。 配布の決定は、個別の時間間隔で行われ、各間隔で、次の時間間隔でのリソースの共有が決定されます。 この作業では、時間間隔を10秒に設定して、変化する負荷にすばやく適応します。 間隔は10秒未満に設定されていません。これは、長期予測では将来の予測のタイムステップ数が増加し、予測の精度が低下するためです。 より長い時間間隔を設定すると、負荷の変化に迅速に適応できないため、非効率性とSLA違反につながる可能性があります。 私たちの仕事はCPUの割り当てに焦点を当てていますが、原則として、このアプローチは他のリソースにも拡張できます。 プロセッサリソースを割り当てるには、最新の仮想化テクノロジのほとんどが提供するCPU CAP設定が使用されます。 CAPは、VMが使用できる最大CPUパワーであり、総容量の割合として、仮想マシン間で良好なパフォーマンス分離を提供します。



各VMに割り当てられたCPUの割合を推定するために、次の時間間隔のCPU使用率の値が最初に予測されます。 次に、予測CPU使用率にCPU電力の10％を加えた合計CPUリソースが計算されます。 CPU CAPを必要なCPU使用率よりも10％高く設定することにより、予測エラーを考慮し、パフォーマンスに関連するSLA違反の可能性を減らすことができます。 CPU使用率の次の値を予測するには、CPU使用率の以前の値の履歴に基づいて時系列予測手法を使用します。 特に、ガウス過程に基づく機械学習が使用されます。 リソースのローカル割り当ては1ステップ進むだけで済みますが、VMエージェントは輻輳を検出するためにいくつかのステップを予測します。

ホストエージェント

ホストエージェントの責任の1つは、アービターとして行動することです。 彼はすべての仮想マシンエージェントからプロセッサ要件を受け取り、それらの間の競合を解決して、すべての仮想マシンの最終的なCPU割り当てを決定します。 すべてのVMのCPU要件が合計CPUパワーを超えると、競合が発生する可能性があります。 競合がない場合、CPUの最終的な割り当ては、仮想マシンエージェントによって要求された割り当てと一致します。 競合がある場合、メインエージェントは次の式に従って最終的なCPU割り当てを計算します。



最終的なVMクォータ=（要求されたVM共有/すべてのVMによって要求されたリソースの合計）*合計CPUパワー



この作業の主な目的であるホストエージェントのもう1つの責任は、ホストが過負荷になっているか過負荷になっているかを判断することです。 この情報はグローバルエージェントに渡され、グローバルエージェントはライブマイグレーションを開始して、グローバル分散アルゴリズムに従って過負荷または過負荷のホストからVMを移動します。

輻輳検出

過負荷検出では、長期の時系列予測が使用されます。 この作業のコンテキストでは、これは将来の7つのタイムスロットの値を予測することを意味します。 将来の7つのタイムスロットの実際のCPU使用率と予測された合計CPU使用率が輻輳しきい値を超えると、ホストが過負荷であると宣言されます。 将来の時間間隔で予測される合計CPU使用率は、対応する時間間隔ですべてのVMによって予測されるCPU使用率の値を合計することで推定されます。 将来の7つの予測時間間隔の値は、ライブ移行の推定平均時間（約4時間間隔）よりも長くなるように選択されます。 この作業では、ライブマイグレーションの平均時間は既知であると見なされ、その値は、複数の実験中のすべてのライブVMマイグレーションの平均によって4時間間隔に等しいと推定されます。 実際のシナリオでは、この値は事前にはわかりませんが、経験に基づいて推定できます。 別のより微妙なアプローチは、現在のVMパラメーターに基づいてライブ移行時間を予測する方法を使用することです 。



この場合、ライブマイグレーションは輻輳時間を短縮しないため、ライブマイグレーション時間よりも短い輻輳に対してライブマイグレーションアクションを実行することは役に立ちません。 7時間間隔を超える値を使用することも、あまり長くは続かないが、ライブマイグレーションを使用して排除できる輻輳状態の省略につながる可能性があるため、あまり有用ではありません。 いくつかの予備実験では、将来の予測時間間隔の数を増やしても、アプローチの安定性と有効性が向上しないことが示されています。 輻輳のしきい値は、仮想マシンの数に基づいて動的に決定され、SLA違反のペナルティシステムに依存します。これについては、以下で詳細に説明します。

過負荷検出

また、ホストエージェントは、すべての仮想マシンを他のノードに積極的に移行し、ホストを切断して電力を節約することにより、ホストが動的な統合を適用するほどビジーではないと判断します。 また、長期CPU時系列予測も使用します。 将来の7時間間隔の実際のCPU使用率と予測された合計CPU使用率が過負荷しきい値を下回っている場合、ホストは過負荷と宣言されます。 繰り返しますが、7つのタイムスロットの値は、短期的な負荷不足状態をスキップするには十分ですが、統合の機会を逃すには大きすぎません。 しきい値は一定の値であり、この作業ではCPUパワーの10％に設定されていますが、管理者は統合の積極性に関する好みに応じて構成できます。

ホスト検出の統合

ライブマイグレーションについて決定するために、グローバルエージェントは、移行の宛先ホストとして使用するために過負荷になっていないホストを知る必要があります。 ホストは、将来の7時間間隔で実際および予測された合計CPU使用率が輻輳しきい値を下回る場合、統合として宣言されます。 任意の時間間隔の実際および予測の合計CPU使用率は、すべての既存の仮想マシンによる実際および予測のCPU使用率と、宛先ホストに転送される予定のVMの実際および予測のCPU使用率を合計することによって推定されます。 目標は、仮想マシンが再構成された後、統合ノードが過負荷にならないかどうかを確認することです。

長期予測の不確実性

長期的な予測には、誤った判断につながる可能性のある予測エラーが伴います。 長期予測の不確実性を考慮して、前述の検出メカニズムは、予測エラーの分布の確率モデルによって補完されます。



最初に、各予測区間における予測誤差の確率密度関数が推定されます。 予測誤差の確率分布は事前にわからないため、異なる負荷が異なる分布を持っている可能性があるため、密度関数を構築するにはノンパラメトリック法が必要です。 この作業では、 核の密度の核推定に基づいて確率密度関数を推定するためにノンパラメトリック法を使用します。 以前の予測エラーに基づいて、時間間隔ごとに予測エラーの確率密度関数を推定します。 この作業では、予測誤差の絶対値の確率密度関数が使用されます。 将来、7つの時間間隔が予測されるため、予測誤差の大きさのために7つの異なる確率密度関数がオンラインで作成されます。

確率的過負荷検出

予測エラーの確率密度関数に基づいて、予測される各時間間隔で、将来の合計CPU使用率が輻輳しきい値を超えるかどうかを推定できます。 これを行うには、アルゴリズム1を使用します。アルゴリズム1は、将来のCPUの使用が何らかの確率で輻輳しきい値を超えるかどうかに応じてtrueまたはfalseを返します。









最初に、アルゴリズムは、将来のCPU使用率が輻輳しきい値を超える可能性を検出します。 予測されたCPU使用率が輻輳しきい値よりも大きい場合、予測されたCPU使用率と輻輳しきい値の間でmax_errorと呼ばれる違いが検出されます。 オーバーロードのしきい値を超える将来のCPU使用率の場合、エラーモジュラス（つまり、予測値と将来の値の差）はmax_error未満でなければなりません。 予測エラーの分布の積分関数に基づいて、予測エラー（モジュロ）がmax_error未満である確率、つまり、将来のCPU使用率が過負荷しきい値を超える確率が見つかります。 将来のCPU使用率が輻輳のしきい値を超える可能性がありますが、予測エラーはmax_errorを超える可能性があります。 （1-probability）/ 2として与えられるこの確率は、計算された確率に追加されます。 最終的な確率（確率+ 1）/ 2を取得します。



予測されたCPU使用率が輻輳しきい値よりも低い場合、この場合、まず、将来のCPU使用率が輻輳しきい値よりも低くなる確率がわかります。 （1確率）として設定されます。 最後に、アルゴリズムはtrueまたはfalseを返します。



アルゴリズム1は、1つの予測時間間隔のみの過負荷状態を返します。 したがって、ホストの過負荷を宣言するには、実際のCPU使用率が輻輳しきい値を超えている必要があり、アルゴリズムは7つの予測時間間隔すべてに対してtrueを返す必要があります。



輻輳を検出するときに予測の不確実性を考慮する必要性の解釈は次のとおりです：CPU使用率の予測は、輻輳しきい値を超える値を生成する可能性がありますが、予測エラーを考慮に入れると、CPU負荷はしきい値を下回る可能性があります。 これは、しばらくの間、ホストが過負荷と見なされないことを意味し、アプローチの安定性が向上します。 これは、他のアプローチと比較して過負荷を検出する確率的アプローチのライブマイグレーションの数が少ないことで証明されています（詳細については、実験のセクションを参照してください）。 さらに、CPU使用率の予測が輻輳しきい値を下回ると、CPU負荷がしきい値より大きくなる可能性があり、予測エラーを考慮すると、ホストは過負荷と見なされます。



したがって、ホストは過負荷であるか、予測の不確実性に比例していないと見なすことができます。これは正しいアプローチであり、予測の不確実性を考慮しないアプローチと比較して良好な実験結果によって確認されます。



負荷の低いホストを特定するために、アルゴリズム3が提案されています。

最適決定理論に基づく過負荷検出

前述の機能強化により、ディスカバリプロセスでの長期予測の不確実性が考慮されますが、ライブマイグレーションに起因するオーバーヘッドは考慮されません。 このセクションでは、提示されたアプローチが最適な意思決定の理論に向けて発展しています。 その結果、ホストの輻輳によるSLA違反による損失が、仮想マシンのライブマイグレーションによる損失よりも大きい場合にのみ、ライブマイグレーションが開始されます。



解の理論を適用して、最適化する効用関数を決定する必要があります。 この調査では、ユーティリティ関数の値は、ホストSLA違反またはライブマイグレーションによるオーバーヘッドのペナルティです。 SLAは、クラウドプロバイダーとコンシューマーの間の合意であり、とりわけ、サービスの可用性（パフォーマンス）のレベルとその違反に対する罰金のシステムを決定します。 この作業では、SLA違反は、ホストによる合計CPU使用率が4つの連続した時間間隔で輻輳しきい値を超える状況として定義されます。 ホストSLA違反のペナルティは、連続する4つの時間間隔すべてでCPU使用率の合計が輻輳しきい値を超えたCPU電力の割合です。 罰金は、何らかの変換関数を使用してお金に変換できますが、ここではCPUパワーの割合です。



実行中の仮想マシンの各移行にはパフォーマンスの低下が伴うため、VMの各移行のペナルティはSLAで指定できます。 CPU容量の割合として表されるSLA違反ペナルティは、VMが移行を継続するすべての時間間隔のすべてのSLA違反ペナルティの合計として定義されます。



提案理論は、決定理論に基づいて、ホストSLA違反のペナルティ（ユーティリティ値）を最小限に抑え、ライブマイグレーションによるSLA違反のペナルティを考慮に入れます。 将来的には、SLA違反のペナルティの代わりに「ユーティリティ」という用語が使用されます。 最初に、将来のホスト輻輳状態の予想ユーティリティ値が評価されます。 期待されるユーティリティは、間隔4から間隔7までの4つの連続するすべての将来の時間間隔の期待されるユーティリティ値の合計によって決定されます。ユーティリティ関数は、時間間隔1ではなく時間間隔4から計算され、発生する前に過負荷状態を修正し、仮想マシンを移行してこの可能性を排除します平均4つの時間間隔がかかります。



CPUの将来の使用がわかっている場合、時間間隔の有用性は、CPUの将来の使用と輻輳しきい値との差です。 予測されるCPU使用量のみがわかっているため、1つの時間間隔のユーティリティの期待値は次のように計算できます。



最初に 、総CPU電力と輻輳しきい値との間のCPU使用率の間隔は、固定数のレベル（このペーパーでは5）に分割されます。



CPU負荷は、各レベルの過負荷しきい値（つまり、各レベルのユーティリティ値）を超えて計算されます。 このために、アルゴリズム4が使用されます。









アルゴリズム4では、間隔はCPU使用率が輻輳しきい値を超えている間隔、デルタは対応するレベルのCPU使用間隔の幅、レベルはレベル番号（0から4）、ユーティリティ値は見つかる、UsageLevelsはレベルの合計数、開始はロード中ですこのレベルの間隔の開始時のCPU。 アルゴリズムは、ユーティリティレベルの値として、レベル間隔の中央から取得したCPU使用率を返します。 可能なレベルごとにアルゴリズム4を実行して、そのユーティリティ値を見つけます。



次に、任意の時間間隔について、あるレベルのCPU負荷が実際にCPUを将来使用する可能性が計算されます。 このアルゴリズムを行います5。









開始とデルタはアルゴリズム4で計算されます。Pred_Utilは対応する時間間隔の合計予測CPU負荷、CumProbability（）は予測エラーが特定の値より小さい確率を決定するために使用される累積分布関数、probはCPU負荷が発生する確率ですこのレベルでは、実際の将来のCPU負荷になります。



計算は、数学的な期待値を計算するための式に似ています。 将来の各時間間隔で予想される効用は、すべてのCPU負荷レベルでの効用値の合計に、対応するレベルの確率を掛けて決定されます。 ホストの輻輳状態の予想される効用は、4日から始まる4つの連続した時間間隔の予想される効用の合計として与えられます。 ホストは過負荷であると宣言されており、ホストSLA違反の予想ペナルティである予想ユーティリティがライブマイグレーションによるSLA違反のペナルティより大きい場合、VM移行が必要です。



このソリューションは短期的なユーティリティ最適化に基づいており、長期的なユーティリティ値の累積を考慮していないことを強調する必要があります。これは、移行の決定に必要な値よりも少ない過負荷ユーティリティ値の合計の結果である可能性がありますが、時間の経過とともに多くの価値を蓄積する可能性があります



この問題を解決するために、輻輳状態のユーティリティ値が累積されます。これは、ライブマイグレーションによるSLA違反のペナルティよりも小さく、各時間間隔でチェックが実行されます。 ユーティリティの累積値がライブマイグレーションによるSLA違反のペナルティより大きい場合、この時間間隔に輻輳があるかどうかに関係なく、マイグレーションが実行されます。



過負荷ホストと宛先ホストは、前述のアプローチを使用して決定されますが、罰金を最小限に抑えることを目的とする最適な意思決定の理論を使用した近代化でも決定されます。

グローバルエージェント

グローバルエージェントは、SLA違反とエネルギー消費を削減するために、過負荷または過負荷のホストから他のノードへの仮想マシンのライブマイグレーションを使用して、プロバイダーリソースの配分を決定します。 ノードが将来的に過負荷または過負荷になった場合、ホストエージェントから通知を受信し、その価値がある場合はVM移行を実行します。



グローバルエージェントは、Power Aware Best Fit Decreasing（ PABFD ） アルゴリズムを使用して、次の調整でVMをホストします。 上記のアプローチは、オーバーロードまたはアンダーロードを検出するために使用されます。 最小移行時間（MMT）ポリシーは、仮想マシンの選択に使用されますが、変更後、ホストが移行後に過負荷状態を維持できる場合でも、各意思決定ラウンドで1つの仮想マシンのみが移行に選択されます。 これは、仮想マシンの同時仮想移行の数と関連コストを削減するために行われます。 統合プロセスでは、長期予測に基づいて提案されたアプローチで発見された負荷の少ないホストのみが考慮されます。 負荷の低いホストのリストから、平均CPU負荷が低いホストを最初に検討します。

仮想マシンのSLA違反

クラウドプロバイダーは、応答時間やスループットなど、さまざまなアプリケーションのパフォーマンスインジケーターに依存する仮想マシンの外部でパフォーマンスインジケーターを評価することが難しいため、仮想マシンの外部で簡単に測定できる全体的なSLA障害率を決定しました。 VMリソースの使用のみに基づいています。 より具体的には、これはVM SLA違反と呼ばれ、消費者の仮想マシンのパフォーマンスを混乱させることでクラウドプロバイダーにペナルティを与えます。 必要な仮想マシンリソースの使用が割り当てられたリソースの共有より少ない場合、コンシューマのVM内で実行されるアプリケーションのパフォーマンスは許容レベルです。



前の引数によれば、分散CPUシェアとVMのCPU負荷の差が4つの連続した時間間隔でCPU電力の5％未満である場合、VM SLA違反が存在します。



たとえば、仮想マシンに割り当てられたCPUシェアがCPUパワーの35％であり、実際のCPU使用率が4つの連続した時間間隔で30％を超える場合、VM SLA違反が発生します。 この定義の背後にある考え方は、必要なCPU負荷が割り当てられたCPUリソースに近づくと、アプリケーションのパフォーマンスが低下するということです。



VM SLA違反ペナルティは、実際のCPU負荷が、連続する4つの時間間隔すべてで、割り当てられたCPUの5％だけしきい値の差を超えるCPUの割合です。 SLA違反ペナルティはCPU負荷の割合として決定されますが、何らかの変換関数を使用して簡単にお金に変換できます。 したがって、グローバルエージェントの目標の1つは、実行中のVMを移行して十分な空きプロセッサパワーを提供することにより、SLA VM違反を減らすことです。 その結果、各VMには必要以上に5％以上のCPUリソースが必要です。



VM SLA違反メトリックを定義することにより、輻輳のしきい値を次のように決定できます。 仮想マシンの数に基づいて動的に計算されます。 Nをホスト上の仮想マシンの数として定義します。 輻輳のしきい値は、合計プロセッサ電力（100％）-N * 5％として計算されます。

実験

CloudSimシミュレータを使用して、大規模なクラウドインフラストラクチャで制御された再現可能な実験を実施しました。 これは、クラウドでのVMリソースとエネルギー消費の動的な割り当てをシミュレートできる有名なシミュレーターです。 CloudSimにいくつかの変更と拡張を行い、提案されたアプローチを統合し、リソースのローカル配布を目的とした仮想マシンのCPU CAPの構成のサポートを取得しました。



私たちの実験では、100の異種ホストを持つ仮想化されたデータセンターがモデル化されています。 2種類のホストがモデル化され、それぞれに2つのプロセッサコアがあります。 1つのホストには2100 MIPSのプロセッサコアがあり、もう1つのホストには2000 MIPSのコアがあり、両方とも8 GBのRAMがあります。 1つのホストはコンピューターモデルHpProLiantMl110G4 Xeon3040をシミュレートし、もう1つのホストはHpProLiantMl110G5 Xeon3075をシミュレートします。



シミュレーションの開始時に、各ホストで平均3台の仮想マシンが計画されます（合計で最大300台の仮想マシン）。 4種類の仮想マシンが使用され、各VMに1つのvCPUが必要です。 3種類の仮想マシンには最大1000 CPUのvCPU容量が必要ですが、別の種類のVMには500 MIPSが必要です。 2種類の仮想マシンには1740 MBのRAM、1つには870 MB、最後の1つには613 MBのRAMが必要です。 現実的なワークロードをテストするために、PlanetLabインフラストラクチャで実行されている実際の仮想マシンのCPU使用率に関するデータを使用します。 各VMは1つのアプリケーション（CloudSimの用語ではクラウド）を起動し、命令の総数として指定されたクラウドの長さは、実験が終了する前にクラウドコンピューティングが完了しないように十分な値に設定されます。 116 , — 10 .



, , , , . , =0 0,001 CPU PlanetLab . .



Java API WEKA . CPU 20 . , 5 CPU. 30 , .

実験結果

.

1. NO-Migrations (NOM) — CPU ( ).
2. , Short-Term Detection (SHT-D) , , CPU . , . , .
3. Long-Term Detection (LT-D) CPU 7 .
4. Long-Term Probabilistic Detection (LT-PD) CPU 7 , .
5. Long-Term Decision Theory Detection (LT-DTD) — LT-PD .
6. , Local Regression Detection (LR-D) , , . , , , .

:

• VM SLA (VM SLA violation — VSV ), , — VM. , VM SLA - . VM SLA - CPU .
• ( E ) , .
• VM (Number of VM live migrations — NM ) .
• SLA, , SLA . Utility :
  
  
  
  Utility =CVSV/NOM_CVSV+Energy/NOM_Energy
  
  
  
  CVSV — VSV VM , Energy — , NOM_CVSV — VSV NOM, NOM_Energy — NOM. NOM_CVSV NOM_Energy . , . — , Utility.
• , , SLA VM, ESV. :
  
  
  
  ESV =E∗CVSV
  
  
  
  E — , CVSV — VSV VM .

LOW HIGH, SLA - (migration penalties): mp = 2%, mp = 4% mp = 6% (MP2, MP4, MP6). CPU, . LOW HIGH CPU PlanetLab 8 14 . MP. ANOVA.



図 2 VM SLA ( VSV) , . , LT-DTD LT-PD, , VM SLA . , , LR-D , SHT-D, LT-D. , , . , SLA. , LT-DTD VM SLA , , . , LT-DTD VSV LT-D 27% LT-PD 12%. LT-D SHT-D , VM SLA.









.2 VSV,



SLA VM, . 3 VSV, , . -, , SLA VM, , . , , LT-DTD VSV . , VSV LT-DTD, . , VSV LT-D 40%, LT-DTD 59%. , , LR-D, LT-D NOM, , ANOVA. , , , SLA VM, .









.3 VSV



, , . 4 VSV , . , VM SLA, , VM SLA. , LT-DTD , VSV MP2 MP4. , LT-DTD .









.4 VSV



5 VM , . , LT-DTD 46 29% LT-D LT-PD . -, , , . , . , LR-D VM . , LR-D , , .









.5



6 , . , LT-DTD LT-D, . LT-DTD , , , VSV ( 3), . LT-D , , ANOVA.









.6



7 , , . , LT-DTD LT-PD . LT-DTD «» MP2 MP4, , . . , «» LT-PD, MP2 MP6, , , . , , LT-PD , LT-DTD, . , , . LT-PD LT-DTD, .









.7



. 8. , LT-PD, , , . LT-DTD , , .









.8 LT-PD LT-DTD



9 , . , LT-DTD . , 5 0,30% LT-D NOM, . LT-DTD , VM SLA , Utility. LR-D, LT-D SHT-D , LT-DTD, VM SLA, ESV Utility.









.9



図 10, , . , , . , .









図 10



, , , LT-DTD NOM. , LT-DTD , . , , , , VM SLA.



.11 , . ANOVA , . .









.11



, . 12 Utility . Utility — , , SLA VM. . , LT-DTD Utility . Utility 9,4% 4,3% LT-D LT-PD . , , LT-DTD , SLA, . , LR-D , SHT-D, , LT-D. , LR-D , LT-D SLA, 2 9.









.12



13 Utility . , Utility, , SLA VM. LT-DTD Utility .









.13



14 , Utility. , , Utility, VM SLA. , LT-DTD, , . , , MP2 MP4, ANOVA.









.14



ESV , Utility.









.15 ESV

おわりに

, , .



.



-, . , ( ). , , . .



-, CPU , , .



-, , - -. , . , - .



最後に、いくつかのリソース（CPU、RAM、I / Oなど）の分布とそれらの相互依存関係の長期予測の研究は、将来の作業にとって興味深い分野です。



コメントでリソースの割り当てについて議論することを皆に勧めます。