特許第5827678号(P5827678)IP Force 特許公報掲載プロジェクト 2015.5.11 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ インターナショナル・ビジネス・マシーンズ・コーポレーションの特許一覧
特許5827678仮想コンテナのシステムにおけるリソース容量評価のための方法および装置
<>
  • 特許5827678-仮想コンテナのシステムにおけるリソース容量評価のための方法および装置 図000002
  • 特許5827678-仮想コンテナのシステムにおけるリソース容量評価のための方法および装置 図000003
  • 特許5827678-仮想コンテナのシステムにおけるリソース容量評価のための方法および装置 図000004
  • 特許5827678-仮想コンテナのシステムにおけるリソース容量評価のための方法および装置 図000005
  • 特許5827678-仮想コンテナのシステムにおけるリソース容量評価のための方法および装置 図000006
  • 特許5827678-仮想コンテナのシステムにおけるリソース容量評価のための方法および装置 図000007
  • 特許5827678-仮想コンテナのシステムにおけるリソース容量評価のための方法および装置 図000008
  • 特許5827678-仮想コンテナのシステムにおけるリソース容量評価のための方法および装置 図000009
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】5827678
(24)【登録日】2015年10月23日
(45)【発行日】2015年12月2日
(54)【発明の名称】仮想コンテナのシステムにおけるリソース容量評価のための方法および装置
(51)【国際特許分類】
   G06F 9/50 20060101AFI20151112BHJP
   G06F 9/46 20060101ALI20151112BHJP
【FI】
   G06F9/46 462A
   G06F9/46 350
【請求項の数】18
【全頁数】17
(21)【出願番号】特願2013-502556(P2013-502556)
(86)(22)【出願日】2010年11月12日
(65)【公表番号】特表2013-524340(P2013-524340A)
(43)【公表日】2013年6月17日
(86)【国際出願番号】US2010056435
(87)【国際公開番号】WO2011123153
(87)【国際公開日】20111006
【審査請求日】2013年8月5日
(31)【優先権主張番号】12/751,089
(32)【優先日】2010年3月31日
(33)【優先権主張国】US
【前置審査】
(73)【特許権者】
【識別番号】390009531
【氏名又は名称】インターナショナル・ビジネス・マシーンズ・コーポレーション
【氏名又は名称原語表記】INTERNATIONAL BUSINESS MACHINES CORPORATION
(74)【代理人】
【識別番号】100108501
【弁理士】
【氏名又は名称】上野 剛史
(74)【代理人】
【識別番号】100112690
【弁理士】
【氏名又は名称】太佐 種一
(72)【発明者】
【氏名】ベネデッティ、ファビオ
(72)【発明者】
【氏名】ボブロフ、ノーマン
(72)【発明者】
【氏名】フォン、リアナ、リヨウ
(72)【発明者】
【氏名】リウ、ヤンビン
(72)【発明者】
【氏名】シーラム、シーサラミ、アール.
【審査官】 田中 幸雄
(56)【参考文献】
【文献】 特開2003−330734(JP,A)
【文献】 特開2007−272263(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 9/50
G06F 9/46
(57)【特許請求の範囲】
【請求項1】
仮想マシンがコンテナを構成し、より大きなコンテナの総容量を求めて競合している複数のコンテナのうちの少なくとも1つのコンテナが実行しているジョブのリソースの量に空き容量FCを加えた容量(J+FC)として定義される潜在容量を計算する方法であって、前記方法は、プロセッサが、コンピュータ・プログラム命令を実行することにより、コンピュータが、
前記競合している複数のコンテナそれぞれによる現在の利用量を取得するステップと、
前記競合している複数のコンテナそれぞれに関して、対応する前記コンテナが権限を有するリソースに関する割振りにおける潜在容量を等しくする利用量である平衡容量を計算するステップと、
前記総容量、および前記現在の利用量の1つ以上と、対応する前記平衡容量の1つ以上との比較、および前記競合している複数のコンテナそれぞれのリソース重みに基づき、前記複数のコンテナをリソース利用が前記平衡容量を超えている第1のグループと、それ以外の第2のグループに分け、前記第1のグループのメンバからリソース利用の容量を減らす事により、前記第1のグループについて前記潜在容量を計算するステップと、
実行する方法。
【請求項2】
前記取得するステップは、前記複数のコンテナそれぞれの最小容量を取得するステップをさらに含む、請求項1に記載の方法。
【請求項3】
前記最小容量を上回る容量は、前記リソース重みに従って配分される、請求項2に記載の方法。
【請求項4】
前記取得するステップは、最大容量を取得するステップをさらに含む、請求項1に記載の方法。
【請求項5】
第2のより大きな親コンテナ内に複数の前記より大きなコンテナをさらに含む、請求項1に記載の方法。
【請求項6】
前記複数のコンテナのセットが変更されると、前記潜在容量を再算出するステップをさらに含む、請求項1に記載の方法。
【請求項7】
前記潜在容量は、作業の割り当てのために用いられ、前記作業は、空き容量に基づき割り当てられており、各作業要素の前記割り当ての後に、前記潜在容量を再算出するステップをさらに含む、請求項1に記載の方法。
【請求項8】
前記総容量と、低利用の前記第1のグループ内のメンバの容量の合計との差として、前記過剰利用の前記第2のグループの前記潜在容量を計算するステップをさらに含む、請求項7に記載の方法。
【請求項9】
前記第1のグループのうち、閾値を下回る利用量を有するメンバを、前記低利用の第2のグループに移動するステップをさらに含む、請求項8に記載の方法。
【請求項10】
仮想マシンがコンテナを構成し、より大きなコンテナの総容量を求めて競合している複数のコンテナのうちの少なくとも1つのコンテナが実行しているジョブのリソースの量に空き容量FCを加えた容量(J+FC)として定義される潜在容量を計算する装置であって、前記装置は、
メモリと、
前記メモリに結合された少なくとも1つのプロセッサと、
を含み、前記プロセッサは、
前記競合している複数のコンテナそれぞれによる現在の利用量を取得し、
前記競合している複数のコンテナそれぞれに関して、対応する前記コンテナが権限を有するリソースに関する割振りにおける潜在容量を等しくする利用量である平衡容量を計算し、
前記総容量、および前記現在の利用量の1つ以上と、対応する前記平衡容量の1つ以上との比較、および前記競合している複数のコンテナそれぞれのリソース重みに基づき、前記複数のコンテナをリソース利用が前記平衡容量を超えている第1のグループと、それ以外の第2のグループに分け、前記第1のグループのメンバからリソース利用の容量を減らす事により、前記第1のグループについて前記潜在容量を計算するよう動作する、装置。
【請求項11】
前記プロセッサはさらに、前記複数のコンテナそれぞれの最小容量を取得するよう構成されている、請求項10に記載の装置。
【請求項12】
前記最小容量を上回る容量は、前記リソース重みに従って配分される、請求項11に記載の装置。
【請求項13】
第2のより大きな親コンテナ内に複数の前記より大きなコンテナをさらに含む、請求項10に記載の装置。
【請求項14】
前記プロセッサはさらに、前記複数のコンテナのセットが変更されると、前記潜在容量を再算出するよう構成されている、請求項10に記載の装置。
【請求項15】
前記プロセッサはさらに、前記潜在容量を作業の割り当てのために用い、前記作業は、空き容量に基づき割り当てられており、各作業要素の前記割り当ての後に、前記潜在容量を再算出するよう構成されている、請求項10に記載の装置。
【請求項16】
前記過剰利用な第1のグループは、全体的な平衡容量を超える利用量を有するコンテナを含み、前記第1のグループの前記潜在容量は、前記総容量と、低利用の第2のグループ内のメンバの容量の合計との差として計算される、請求項13に記載の装置。
【請求項17】
前記プロセッサはさらに、前記第1のグループのうち、閾値を下回る利用量を有するメンバを、前記第2のグループに移動するよう構成されている、請求項16に記載の装置。
【請求項18】
仮想マシンがコンテナを構成し、より大きなコンテナの総容量を求めて競合している複数のコンテナのうちの少なくとも1つのコンテナが実行しているジョブのリソースの量に空き容量FCを加えた容量(J+FC)として定義される潜在容量を計算する方法を、コンピュータが実行するためのプログラムであって、前記プログラムは、コンピュータに対し、
前記競合している複数のコンテナそれぞれによる現在の利用量を取得するステップと、
前記競合している複数のコンテナそれぞれに関して、対応する前記コンテナが権限を有するリソースに関する割振りにおける潜在容量を等しくする利用量である平衡容量を計算するステップと、
前記総容量、および前記現在の利用量の1つ以上と、対応する前記平衡容量の1つ以上との比較、および前記競合している複数のコンテナそれぞれのリソース重みに基づき、前記複数のコンテナをリソース利用が前記平衡容量を超えている第1のグループと、それ以外の第2のグループに分け、前記第1のグループのメンバからリソース利用の容量を減らす事により、前記第1のグループについて前記潜在容量を計算するステップと、
を実行させる、プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、全般的に、電気、電子およびコンピュータ技術に関し、特に、仮想化をサポートするプラットフォームのリソースの動的な容量に関する。
【背景技術】
【0002】
コンピュータ・リソースが共有される場合、スケジューラが、利用可能な1つ以上のプロセッサまたは他のリソースにプロセスを割り当てる。典型的には、スケジューラは、ジョブの要件と、リソース(単数または複数)の能力および容量とを適合させることによって、バッチ・ジョブなどの作業(work)を割り当てる。従来、ジョブは、現在の利用量(utilization)および固定の容量に基づき、物理リソースに直接割り当てられていた。しかし最近は、基礎をなすリソースの抽象化をそれぞれ提供する1つ以上のリソース・コンテナ(「仮想マシン」と呼ばれることが多い)を介して物理リソースが公開される。共有される物理リソースには、例えば、処理用コア、ストレージ・システムおよびネットワーク通信リソースが含まれ得る。
【発明の概要】
【発明が解決しようとする課題】
【0003】
マルチコンテナ環境では、典型的にはコンテナ・マネージャの監視下で、様々なコンテナが、プロセッサ・サイクルなどの固定の物理リソースを共有し、それを求めて競合する。典型的には、コンテナ・マネージャは、ルールまたはポリシのセットに従って物理リソースをコンテナに割り当てる。リソースをめぐるコンテナ間の競合は、スケジューリング問題にいっそう大きな複雑性を付加する。コンテナのリソース容量の評価は、あらゆるスケジューリング・プロセスにおいて重要なステップである。さらに、コンテナは、作業の実行中に追加、削除、中断されること、またはオンライン状態にされることもある。これらのアクションを計画し、既存のコンテナおよびジョブに対する影響を推定することも、重要なアクティビティである。しかし、マルチコンテナ環境では、リソース容量を評価することは困難である。
【0004】
したがって、仮想コンテナのシステムにおいてリソース容量を評価する方法および装置に対するニーズが存在する。物理容量を共有するすべての仮想コンテナにわたって動的なリソース容量を評価する方法および装置に対して、さらなるニーズが存在する。
【課題を解決するための手段】
【0005】
概して、仮想マシンなどの複数のコンテナ間に伸縮性(elasticity)および競合があるシステムにおいて、潜在リソース容量を評価する(例えばジョブ割り当てのために)方法および装置が提供される。本発明の一側面によれば、より大きなコンテナの総容量を求めて競合している複数のコンテナのうちの少なくとも1つのコンテナに関して動的な潜在容量が判断される。競合している複数のコンテナそれぞれによる現在の利用量が取得され、競合しているコンテナそれぞれに関して平衡容量(equilibrium capacity)が判断される。平衡容量は、対応するコンテナが権限を有する容量を示す。総容量、および現在の利用量の1つ以上と、対応する平衡容量の1つ以上との比較、および競合している複数のコンテナそれぞれの相対的なリソース重み(resource weight)に基づき、動的な潜在容量が判断される。
【0006】
本発明の別の側面によれば、動的な潜在容量は、複数のコンテナのセットが変更された場合に、または各作業要素の割り当ての後に、任意選択で再算出(recalculate)される。判断された動的な潜在容量は、例えば、複数の親コンテナ間のコンテナ・マイグレーション(container migration)または作業の割り当てのために用いることが可能である。
【0007】
例示的な一実施形態では、この複数のコンテナは、少なくとも2つのグループに分けられる。過剰利用グループ(overutilized group)は、全体的な(global)平衡容量を超える利用量を有するコンテナを含み、低利用グループ(underutilized group)は、全体的な平衡容量を下回る利用量を有するコンテナを含む。過剰利用グループの動的な潜在容量は、総容量と、低利用グループ内のメンバ(member)の容量の合計との差として計算可能である。過剰利用グループのうち、閾値を下回る利用量を有するメンバは、低利用グループに移動される。
【0008】
以下の詳細な説明および図面を参照することで、本発明、ならびに本発明のさらなる特徴および利点のより完全な理解が得られる。
【図面の簡単な説明】
【0009】
図1】例示的な従来のジョブ・スケジューラの概要を提供する。
図2】別の例示的な従来のジョブ・スケジューラの概要を提供する。
図3】例示的な2つのコンテナの、様々なタイプのコンテナ容量を示す。
図4】コンテンション(contention)状態にある例示的な2つのコンテナに対するリソースの割り振りを示す。
図5】本発明の特徴を取り入れた潜在容量評価プロセスの実施形態の例示的な擬似コードを示す。
図6】3つのコンテナの例示的なセットに対するリソースの割り振りの例を提供する。
図7】本発明による、空き容量を評価する装置の概略ブロック図である。
図8】本発明の1つ以上の側面もしくは要素またはその両方を実装するのに有用となり得るコンピュータ・システムを示す。
【発明を実施するための形態】
【0010】
本発明は、複数のコンテナ(例えば仮想マシン)間に伸縮性および競合があるシステムにおいて、潜在リソース容量を評価する(例えばジョブ割り当てのために)方法および装置を提供する。図1は、例示的な従来のジョブ・スケジューラ100の概要を提供する。図1に示されているように、ジョブ・キュー110に記憶されている1つ以上のジョブが、ジョブ・スケジューラ120によって処理され、与えられたジョブそれぞれが、物理的な計算プラットフォーム150などの利用可能な1つ以上の物理リソースに割り当てられる。物理リソース150は、例えば、処理用コア、ストレージ・システムおよびネットワーク通信リソースを含み得る。前述のように、スケジューラ120は、ジョブの要件と、リソース150の能力および容量とを適合させることによって、ジョブを割り当てる。
【0011】
図1に示されているように、物理リソース150は、基礎をなすリソース150の抽象化をそれぞれ提供する1つ以上のリソース・コンテナ130を介して公開される。典型的には、例示的なコンテナ130は、これらの基礎をなす物理リソース150を、コンテナ・マネージャ140の監視下で共有する。多くの場合、コンテナ130は、基礎をなすリソース150を求めて競合し合う。
【0012】
図1のジョブ・スケジューラ100は、単一のレイヤのコンテナ130を用いる。図2は、別の例示的な従来のジョブ・スケジューラ200の概要を提供する。図2に示されているように、コンテナ230−1などの特定のコンテナが、1つ以上のさらなるコンテナ210−1〜210−Nおよび1つ以上のコンテナ・マネージャ220をホストすることができる。
【0013】
本発明は、マルチコンテナ環境では、様々なコンテナ130、230が固定のプラットフォーム・リソース150、250を共有し、それを求めて競合するということを認識したものである。コンテナ130、230のリソース容量の評価は、スケジューラ120によって実行されるスケジューリング・プロセスの重要なステップである。
【0014】
本発明の一側面によれば、複数のコンテナ130、230を有するシステムに関して、潜在リソース容量が評価される。図3は、例示的な2つのコンテナA、Bの、様々なタイプのコンテナ容量を示す。図3に示されているように、固定のサイズを有する親コンテナ320(またはプラットフォーム)が、総物理容量を提供する。総物理容量は、コンテナAおよびBに動的に割り振られる。コンテナA上で実行されている例示的なジョブがある。コンテナA上で実行されている例示的なジョブは、利用量Jを有する。
【0015】
例示的な2つのコンテナA、Bはそれぞれ、潜在容量(PC:potential capacity)を有する。例えば、コンテナAは、潜在容量PCを有する。本願明細書で使用される、潜在容量は、各コンテナが現在利用してもよい量に対応する(例えば、利用可能な最大容量)。潜在容量は、システムの状態、およびコンテンション中にマネージャがどのようにリソースを配分するかによって決まる。図3に示されているように、コンテナA上で実行されているジョブは、リソースの量Jを消費する。
【0016】
例示的な2つのコンテナA、Bは、空き容量(FC:free capacity)を有する。例えば、コンテナAは、空き容量FCを有する。本願明細書で使用される、空き容量とは、潜在容量を限度とした、各コンテナ内に残っているリソースである(例えば、新たな作業に利用可能な容量)。したがって、コンテナの潜在容量は、以下のように表すことができる。
PC=J+FC
【0017】
したがって、空き容量は、潜在容量および利用量から算出可能である。なお、システムの状態によっては、すべてのコンテナの潜在容量の合計が、基礎をなすプラットフォームの物理容量を超えることがあり得る。概して、各コンテナA、Bの潜在容量は、物理容量、コンテナ属性、状態およびすべてのコンテナにわたる利用量から計算される。
【0018】
各コンテナの空き容量は、ジョブ・スケジューリング・アルゴリズムにおける重要なパラメータであることが多い。例えば、従来の典型的なスケジューリング方法は、最大の空き容量を備えるプラットフォームに各ジョブを割り当てる。こうして、スケジューリングは、基本的なロード・バランシングを提供して、利用可能なマシン間にジョブを分配する。物理リソースに関するスケジューリングの従来の状況では、プラットフォームの空き容量は、利用量モニタから直接入手できる。一方、競合しているコンテナに関するスケジューリングの場合、コンテナ・マネージャ140、240によって実装されるルールおよびポリシによって空き容量が決まるため、空き容量は、現在のシステム状態(例えば、すべてのコンテナにおけるリソースの利用量)から取得することはできない。
【0019】
仮想コンテナの潜在容量の算出
前述のように、本発明は、複数のコンテナ130、230を有するシステムにおいて潜在容量を評価する方法および装置を提供する。本発明の一側面によれば、現在のシステム状態を所与とし、コンテナ・マネージャ140がコンテナ130、230間の要求を調停する(arbitrate)のに用いるルールを使用して、各コンテナ130、230に関して潜在リソース容量が評価される。続いて、この潜在容量が、ジョブ割り当てアルゴリズムにおいて適用され、実行する各ジョブまたはジョブ要素のコンテナが選ばれる。コンテナ130、230の潜在容量を評価する例示的なアルゴリズムについては、図5に関連して以下でさらに説明する。
【0020】
予測されるリソース消費
各ジョブがコンテナ130、230に割り振られるとき、システム状態が変化するが、これは、次のジョブをスケジューリングするときに考慮されなければならない。これは例えば、ジョブのグループが同時にスケジュールされ、次のジョブを割り当てる前に各ジョブ配置の影響を推定する時間が十分にない場合、問題となり得る。
【0021】
実行中に各ジョブが消費する所与のリソースの量は、平均して既知であることもある。したがって、ジョブがコンテナに割り振られた後、平均リソース消費を使用して、コンテナの空き使用量が調節されることが可能である。例示的な一実施形態では、平均リソース消費が利用可能でない場合、例えば、そのタイプのジョブの、最近のリソース消費の平均に基づいて、予測が行われることが可能である。
【0022】
ジョブによるリソース消費は、変動することが多い。したがって、別の変形では、潜在容量および空き容量は、システム上のジョブおよび競合するジョブの統計的使用量に従って割り当てられる。例えば、90%の確率で空き容量が0.8の値以下であると仮定するなどである。
【0023】
さらに別の変形では、平均リソース消費が利用可能でない場合、例えば、平衡点容量(equilibrium point capacity)に基づき、既定の量が用いられることが可能である。
【0024】
本発明の別の側面によれば、各コンテナ130、230の潜在リソース容量は、リソース・コンテンションを調停する特定のコンテナ・モデルに基づき評価される。本願明細書で使用される、「平衡リソース」という用語は、すべてのコンテナからの完全なコンテンションという限界状態で各コンテナに割り振られるリソースを示す。平衡点は、完全なコンテンションの下で重要な側面である。さらに、完全または部分的なコンテンションの状況でどのようにしてコンテナ間に公平にリソースが分配されるかを定義するコンテナ属性のセットに基づいて空き容量を計算するために、図5に関連して下記でさらに説明される例示的なアルゴリズムに、平衡点が用いられる。
【0025】
競合するコンテナに対するリソースの割り振り
図4は、コンテンション状態にある例示的な2つのコンテナ1、2に対するリソースの割り振りを示す。図4では、利用量u、uが、単一(例えば、u+u=1)の総容量を求めて競合している各コンテナ1、2の各軸上に示されている。第1の線410は、利用量uが水平軸に沿って増加するときの、利用量uの潜在容量を示す。同様に、第2の線420は、利用量uに対し対応する潜在容量を示す。各コンテナ1、2には、対応する最大利用量lmtがある。さらに図4に示されているように、各コンテナ1、2には、対応する予約された利用量resがある。さらに図4に示されているように、各コンテナ1、2には、対応する潜在容量cがある。
【0026】
2つの潜在容量の交点c(c=c)が、平衡点430であり、完全なコンテンションのもとではシステム状態がここに収束する。言い換えれば、平衡点430では、両コンテナ1、2が、そのそれぞれのリソースの平衡点430を超えて使用しようとする。平衡点430は、各コンテナの利用量がその平衡点を上回るかまたは下回るかによって、システムの状態を区分するのに有用である。
【0027】
概して、コンテナ1は、最大利用量lmtから開始する。コンテナ2が利用量を得るにつれて、両コンテナは、平衡点430へと移動する。後述のように、平衡点430は、スペースを4つの領域に分ける。
【0028】
潜在容量評価プロセス
図5は、本発明の特徴を取り入れた潜在容量評価プロセス500の実施形態の例示的な擬似コードを示す。概して、例示的な潜在容量評価プロセス500は、コンテナ130、230の潜在容量を評価する。図5に示されているように、現在のコンテナを示すインデックスidx、プラットフォームの総物理容量pCap、各コンテナiの現在の利用量を示す配列(array)u、各コンテナiの予約(最小)容量を示す配列res、各コンテナiの最大容量(maximum capacity)を示す配列lmt、および各コンテナiの重みまたは相対的シェアを示す配列wが、ステップ1の間に例示的な潜在容量評価プロセス500に渡される。
【0029】
ステップ2の間に、コンテナ属性と、割り当てられたシェアに従った、コンテナ最小量より上の配分容量とに基づき、平衡容量(c)が各コンテナに関して計算される。現在のコンテナの利用量変数uidxが、ステップ3の間に初期化される(例えば無限大に)。
【0030】
潜在容量評価プロセス500は、現在のメンバの潜在動的容量cidxを、以下のように算出する。例示的な実施形態では、潜在容量評価プロセス500は、ステップ4の間に、メンバ・コンテナを2つのグループに分ける。第1のグループworkGは、割り当てられた全体的な平衡容量を利用量が超えるメンバならびに現在のメンバから成る。第2のグループunchgGは、残りのメンバから成る。例示的な実施形態では、容量が、第1のグループの1つ以上のメンバから減らされる(このメンバは権限を有するよりも多く使用しているため)。
【0031】
ステップ4〜9のループに入り、1つのグループからもう一方のグループへ移動するメンバがなくなるまで(ステップ9において検出される)繰り返される。ステップ6の間に、第1のグループに関して潜在容量が再計算され、第2のグループの潜在容量は保持される。こうして、総容量pCapと、第2の(低利用)グループ内のメンバの容量の合計との差として、第1の(過剰利用)グループの利用可能な容量(平衡容量に関連して)が計算される。
【0032】
ステップ7および8の間、増分グループincGが用いられ、メンバの平衡容量(すなわち、コンテナがどれだけの容量に対し権限を有するか)よりも利用量が小さい過剰利用グループのメンバを、低利用グループに移動させる(現在のメンバ以外)。
【0033】
ステップ10の間に、現在のメンバがまだ過剰利用グループにあると判断されれば、ステップ11の間に、現在のメンバの潜在容量が、コンテナ属性に基づき返され、容量がシェアに従って配分される。
【0034】
一方、ステップ10の間に、現在のメンバが過剰利用グループにないと判断されれば、現在のメンバの潜在容量が、ステップ13の間に返される。潜在容量評価プロセス500については、図6の例に関連してさらに後述される。
【0035】
図6は、3つのコンテナ(仮想マシン)VM(virtual machine:仮想マシン)1〜VM3の例示的なセットに関して、平衡、潜在および空き容量がどのように評価されるかの例600を提供する。図6に示されているように、各コンテナVM1〜VM3の予約量、シェアおよび現在の利用量が、最初の3つのレコード610、620、630に示されている。上述の通り、シェアは、コンテンション状態でリソース(単数または複数)を配分するために使用される、各コンテナの相対的な重みである。
【0036】
レコード640は、潜在容量評価プロセス500の6行目の間に判断される、3つすべてのコンテナVM1〜VM3の平衡容量の算出に対応する。これは、各コンテナVM1〜VM3が、それぞれできる限り多くのリソースを取得しようとする場合に与えられるものである平衡容量cをもたらす。ここでは、単一の総物理容量があり、各コンテナに0.3の予約量がある。したがって、コンテナの重みに比例して共有するのは、残り0.1である。したがって、平衡状態にある各コンテナは、その予約量の0.3に加えて、0.1のうちのそのシェアを与えられる。
【0037】
例えば、コンテナVM2は、6の総シェアのうち、2のシェアを割り当てられている。したがって、コンテナVM2の平衡容量は、レコード640において、コンテナVM2の最小予約量(0.3)と、総予約量の後(すなわち、単一の総物理容量から、すべてのコンテナに割り当てられている総予約量(コンテナ毎に0.3)を減じたもの)の残りの物理容量の比例配分(割り当てられたシェアに基づく)分とを合計することによって計算される。
【0038】
図5に関連して上述したように、平衡容量は、1つのグループからもう一方のグループへ移動するメンバがなくなるまで、ループ内でステップ6において計算される。コンテナVM1に関しては、コンテナVM2およびVM3両方の現在の利用量(レコード630)が、判断された平衡容量を下回る(したがってコンテナVM2およびVM3の容量がコンテナVM1に再割り当てされることはできない)ため、レコード640に示されている初期の算出の後、平衡容量の算出は完了する。例えば、0.3という、コンテナVM2のレコード630における現在の利用量は、コンテナVM2に関してレコード640に示されている、0.333という対応する判断された平衡容量を下回る。
【0039】
コンテナVM2に関して、平衡容量の算出が、レコード650に示されているように、潜在容量評価プロセス500におけるループの第2の反復中に継続する。コンテナVM3の現在の利用量(レコード630)は、レコード640内の、コンテナVM3の判断された平衡容量を下回るため、コンテナVM3の容量は、コンテナVM2に再割り当てされることはできない。したがって、コンテナVM3は、コンテナVM2の平衡容量を計算するとき、レコード650における考慮対象から除外される。したがって、コンテナVM3の現在の利用量は、利用可能な物理容量から除外され、レコード650内には、コンテナVM1およびVM2間に割り振られる0.75の有効物理容量が残る。コンテナVM1の現在の利用量はその平衡容量を超えているため、コンテナVM2は、コンテナVM1と競合する権限を有する。その結果として、コンテナVM1およびVM2は、それらの0.3の予約量と、VM3の0.25の現在の利用量とを超える分のリソースを求めて競合する。
【0040】
レコード650に示されているように、コンテナVM2の平衡容量は、コンテナVM2の最小予約量(0.3)と、総予約量の後(すなわち、考慮されるコンテナVM1およびVM2が利用可能な0.75の総物理容量から、考慮されるコンテナVM1およびVM2に割り当てられている総予約量(コンテナ毎に0.3)を減じたもの)の残りの物理容量の比例配分(考慮されるコンテナVM1およびVM2の割り当てられたシェアに基づく)分とを合計することによって計算される。レコード650の結果は、コンテナVM2内のジョブが、プラットフォーム・リソースの0.4を取得できる可能性があるということである。結果として生じるコンテナVM2の潜在容量が、レコード670に記載されている。
【0041】
同様に、コンテナVM3に関して、平衡容量の算出が、レコード660に示されているように、ループのもう1つの反復中に継続する。コンテナVM2の現在の利用量(レコード630)は、レコード640内の、コンテナVM2の判断された平衡容量を下回るため、コンテナVM2の容量は、コンテナVM3に再割り当てされることはできない。したがって、コンテナVM2は、コンテナVM3の平衡容量を計算するとき、レコード660における考慮対象から除外される。したがって、コンテナVM2の現在の利用量は、利用可能な物理容量から除外され、レコード660内に、コンテナVM1およびVM3間に割り振られる0.7の有効物理容量が残る。レコード660に示されているように、コンテナVM3の平衡容量は、コンテナVM3の最小予約量(0.3)と、総予約量の後(すなわち、考慮されるコンテナVM1およびVM3が利用可能な0.7の総物理容量から、考慮されるコンテナVM1およびVM3に割り当てられている総予約量(コンテナ毎に0.3)を減じたもの)の残りの物理容量の比例配分(考慮されるコンテナVM1およびVM3の割り当てられたシェアに基づく)分とを合計することによって計算される。コンテナVM3は、0.3の予約容量を保証されている。したがって、共有される有効量(utility)は、0.1(1−0.3−0.3−0.3)である。この結果、VM3に関しては0.375の潜在容量となる。
【0042】
各コンテナVM1〜VM3の潜在容量および空き容量が、レコード670、680に示されている。
【0043】
図7は、本発明による、空き容量を評価する装置700の概略ブロック図である。図7に示されているように、空き容量評価ブロック740が、ブロック730から利用量の測定結果を、データ・ストア750からコンテナ情報(属性およびポリシなど)を取得する。これらの値は、例えば、図5の潜在容量評価プロセス500によって、リソース720をキュー710内のリクエストに基づき割り振るために処理される。
【0044】
例示的なシステムおよび製造品の詳細
当業者であれば当然のことであるが、本発明の側面は、システム、方法またはコンピュータ・プログラム製品として具現化され得る。したがって、本発明の側面は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態(ファームウェア、常駐ソフトウェア、マイクロコードなどを含む)、または本願明細書においてすべて概して「回路」、「モジュール」もしくは「システム」と呼ばれ得る、ソフトウェアおよびハードウェアの側面を兼ね備えた実施形態の形態をとってもよい。さらに、本発明の側面は、コンピュータ可読プログラム・コードが具現化された1つ以上のコンピュータ可読媒体(単数または複数)において具現化された、コンピュータ・プログラム製品の形態をとることもできる。
【0045】
本発明の1つ以上の実施形態またはその要素は、メモリと、メモリに結合され例示的な方法ステップを実行するよう動作する少なくとも1つのプロセッサとを含む装置の形態で実装可能である。
【0046】
1つ以上の実施形態が、汎用コンピュータまたはワークステーション上で実行されているソフトウェアを使用することができる。図8は、本発明の1つ以上の側面もしくは要素またはその両方を実装するのに有用となり得るコンピュータ・システム800を示す。図8に関連して、そのような実装は、例えばプロセッサ802、メモリ804、ならびに例えばディスプレイ806およびキーボード808により構成される入出力インターフェイスを用いてもよいであろう。本願明細書で使用される「プロセッサ」という用語は、例えば、CPU(central processing unit:中央処理ユニット)もしくはその他の形態の処理回路またはその両方を含むものなどの、任意の処理デバイスを含むものとする。さらに、「プロセッサ」という用語は、2つ以上の個別のプロセッサを指すこともある。「メモリ」という用語は、例えば、RAM(random access memory:ランダム・アクセス・メモリ)、ROM(read only memory:読み取り専用メモリ)、固定メモリ・デバイス(例えばハード・ドライブ)、取り外し可能メモリ・デバイス(例えばディスケット)、フラッシュ・メモリおよび同様のものなど、プロセッサまたはCPUに関連するメモリを含むものとする。さらに、本願明細書で使用される「入出力インターフェイス」という語句は、例えば、処理ユニットにデータを入力する1つ以上のメカニズム(例えばマウス)、および処理ユニットと関連する結果を提供する1つ以上のメカニズム(例えばプリンタ)を含むものとする。プロセッサ802、メモリ804、ならびにディスプレイ806およびキーボード808などの入出力インターフェイスは、例えばデータ処理ユニット812の一部としてのバス810によって、相互接続可能である。例えばバス810による適切な相互接続は、コンピュータ・ネットワークとインターフェイス接続するために提供され得るネットワーク・カードなどのネットワーク・インターフェイス814に対しても、媒体818とインターフェイス接続するために提供され得るディスケットまたはCD−ROM(compact disc read−only memory:コンパクト・ディスク読み取り専用メモリ)ドライブなどの媒体インターフェイス816に対しても、提供されることが可能である。
【0047】
アナログ・ビデオ・フィードなどのアナログ入力を受信して、それをデジタル化するよう、アナログ・デジタル変換器(単数または複数)820が提供されてもよい。そのような変換器(単数または複数)は、システム・バス810と相互接続されてもよい。
【0048】
したがって、本願明細書に記載される、本発明の方法を実行するための命令またはコードを含むコンピュータ・ソフトウェアは、関連するメモリ・デバイス(例えば、ROM、固定または取り外し可能メモリ)の1つ以上に記憶され、利用の準備ができると、一部または全部が(例えばRAMに)ロードされて、CPUにより実装されてもよい。そのようなソフトウェアは、ファームウェア、常駐ソフトウェア、マイクロコードおよび同様のものを含むことができると考えられるが、これらに限定はされない。
【0049】
プログラム・コードの記憶もしくは実行またはその両方に適したデータ処理システムは、システム・バス810を介してメモリ要素804に直接または間接的に結合された少なくとも1つのプロセッサ802を含む。メモリ要素は、プログラム・コードを実際に実装する間に用いられるローカル・メモリ、大容量ストレージ、および実装中にコードが大容量ストレージから読み出されなければならない回数を減らすために少なくとも一部のプログラム・コードの一時的なストレージとなるキャッシュ・メモリを含むことができる。
【0050】
入出力、すなわちI/Oデバイス(限定はされないが、キーボード808、ディスプレイ806、ポインティング・デバイスおよび同様のものを含む)は、直接(バス810などによって)または介在するI/Oコントローラ(明確にするために省略)を介して、システムに結合可能である。
【0051】
ネットワーク・インターフェイス814などのネットワーク・アダプタもシステムに結合されて、データ処理システムが、他のデータ処理システムまたはリモート・プリンタまたはストレージ・デバイスに、介在するプライベートまたはパブリック・ネットワークを介して結合された状態となることを可能にしてもよい。モデム、ケーブル・モデムおよびイーサネット(R)・カードが、現在利用可能なタイプのネットワーク・アダプタのごく一部である。
【0052】
特許請求の範囲を含め、本願明細書で使用される「サーバ」は、サーバ・プログラムを実行する物理データ処理システム(例えば、図8に示されているシステム812)を含む。当然のことながら、そのような物理サーバは、ディスプレイおよびキーボードを含んでも含まなくてもよい。
【0053】
前述のように、本発明の側面は、コンピュータ可読プログラム・コードが具現化された1つ以上のコンピュータ可読媒体(単数または複数)において具現化された、コンピュータ・プログラム製品の形態をとることもできる。1つ以上のコンピュータ可読媒体(単数または複数)の任意の組み合わせが利用され得る。コンピュータ可読媒体は、コンピュータ可読信号媒体またはコンピュータ可読ストレージ媒体とされ得る。コンピュータ可読ストレージ媒体は、例えば、限定はされないが、電子、磁気、光学、電磁気、赤外線もしくは半導体のシステム、装置もしくはデバイス、または前述のものの任意の適切な組み合わせとすることもできる。媒体ブロック818は、非限定的な例である。コンピュータ可読ストレージ媒体のより具体的な例(包括的でないリスト)には、1つ以上のワイヤを有する電気的接続、ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ(RAM)、読み取り専用メモリ(ROM)、消去可能プログラム可能読み取り専用メモリ(EPROM(erasable programmable read−only memory)またはフラッシュ・メモリ)、光ファイバ、ポータブル・コンパクト・ディスク読み取り専用メモリ(CD−ROM)、光学式ストレージ・デバイス、磁気ストレージ・デバイスまたは前述のものの任意の適切な組み合わせが含まれるであろう。この文書の文脈では、コンピュータ可読ストレージ媒体は、命令実行システム、装置もしくはデバイスによって、またはそれに関連して使用されるプログラムを含むことまたは記憶することができる任意の有形の媒体であればよい。
【0054】
コンピュータ可読信号媒体は、例えば、ベースバンドに、または搬送波の一部として、コンピュータ可読プログラム・コードが具現化された伝搬データ信号を含み得る。そのような伝搬信号は、電磁気、光学またはその任意の適切な組み合わせを含むがこれらに限定はされない、様々な形態のいずれかをとってよい。コンピュータ可読信号媒体は、コンピュータ可読ストレージ媒体ではなく、命令実行システム、装置もしくはデバイスによって、またはそれに関連して使用されるプログラムを伝達、伝搬または搬送することができる、任意のコンピュータ可読媒体としてよい。
【0055】
コンピュータ可読媒体上に具現化されたプログラム・コードは、無線、有線、光ファイバ・ケーブル、RFなど、または前述のものの任意の適切な組み合わせを含むがこれらに限定はされない任意の適切な媒体を使用して送られてもよい。
【0056】
本発明の側面の動作を実行するコンピュータ・プログラム・コードは、Java(R)、Smalltalk(R)、C++または同様のものなどのオブジェクト指向プログラミング言語、および「C」プログラミング言語もしくは同様のプログラミング言語などの従来の手続きプログラミング言語を含む、1つ以上のプログラミング言語の任意の組み合わせで書かれていてよい。プログラム・コードは、スタンド・アロン・ソフトウェア・パッケージとして、完全にユーザのコンピュータ上で実行されることも、部分的にユーザのコンピュータ上で実行されることも、または部分的にユーザのコンピュータ上で、かつ部分的にリモート・コンピュータ上で実行されることも、または完全にリモート・コンピュータもしくはサーバ上で実行されることもできる。後者のシナリオでは、ローカル・エリア・ネットワーク(LAN:local area network)もしくは広域ネットワーク(WAN:wide area network)を含む任意の種類のネットワークを介してリモート・コンピュータがユーザのコンピュータに接続されてもよく、または(例えば、インターネット・サービス・プロバイダを使用しインターネットを介して)外部コンピュータに接続されてもよい。
【0057】
本発明の側面について、本発明の実施形態による方法、装置(システム)およびコンピュータ・プログラム製品のフローチャート図もしくはブロック図またはその両方を参照して以下に記載する。当然のことながら、フローチャート図もしくはブロック図またはその両方の各ブロック、およびフローチャート図もしくはブロック図またはその両方の複数ブロックの組み合わせは、コンピュータ・プログラム命令により実装可能である。マシンを生じるよう、こうしたコンピュータ・プログラム命令が、汎用コンピュータ、専用コンピュータまたはその他のプログラム可能データ処理装置のプロセッサに提供されて、この命令が、コンピュータまたはその他のプログラム可能データ処理装置のプロセッサにより実行されて、フローチャートもしくはブロック図またはその両方のブロックもしくは複数ブロックにおいて指定された機能/動作を実装する手段を作り出すようにすることもできる。
【0058】
さらに、特定の形で機能するようコンピュータ、その他のプログラム可能データ処理装置またはその他のデバイスに指示することができるこうしたコンピュータ・プログラム命令は、コンピュータ可読媒体に記憶されて、コンピュータ可読媒体に記憶されたこの命令が、フローチャートもしくはブロック図またはその両方のブロックもしくは複数ブロックにおいて指定された機能/動作を実装する命令を含む製造品を生じるようにすることもできる。
【0059】
さらに、コンピュータ・プログラム命令は、コンピュータ、その他のプログラム可能データ処理装置またはその他のデバイスにロードされて、コンピュータ、その他のプログラム可能装置またはその他のデバイス上で一連の動作ステップが実行されるようにしてコンピュータで実装されるプロセスを生じさせ、コンピュータまたはその他のプログラム可能装置上で実行される命令が、フローチャートもしくはブロック図またはその両方のブロックもしくは複数ブロックにおいて指定された機能/動作を実装するためのプロセスを提供するようにすることもできる。
【0060】
各図面のフローチャートおよびブロック図は、本発明の様々な実施形態によるシステム、方法およびコンピュータ・プログラム製品の考えられる実装のアーキテクチャ、機能性および動作を示す。この関連で、フローチャートまたはブロック図内の各ブロックは、指定の論理機能(単数または複数)を実装する1つ以上の実行可能命令を含むモジュール、セグメントまたはコードの一部を表すこともできる。なお、さらに、いくつかの代わりの実装では、ブロック内に示されている機能が、図面に示されているのとは異なる順序で生じてもよい。例えば、関連する機能性次第で、連続して示されている2つのブロックが実際には事実上同時に実行されてもよく、または各ブロックが逆順で実行されることがあってもよい。なお、さらに、ブロック図もしくはフローチャート図またはその両方の各ブロック、およびブロック図もしくはフローチャート図またはその両方の複数ブロックの組み合わせは、指定の機能もしくは動作を実行する専用ハードウェア・ベース・システム、または専用ハードウェアおよびコンピュータ命令の組み合わせにより実装することができる。
【0061】
本願明細書に記載された方法ステップは、例えば、本願明細書に記載されたように、当該ステップを実行するようプログラムされた汎用コンピュータ、または当該ステップを実行するハードウェアに関係し得る。さらに、例えばデータ・ストリームの取得およびストリームの符号化を含む、本願明細書に記載された方法ステップはさらに、データ・ストリームが取得されるカメラまたはマイクロホンなどの物理センサに関係してもよい。
【0062】
なお、本願明細書に記載された方法はいずれも、コンピュータ可読ストレージ媒体上に具現化された別個のソフトウェア・モジュールを含むシステムを提供する追加のステップを含むことができる。その結果、方法ステップは、1つ以上のハードウェア・プロセッサ802上で実行されるシステムの別個のソフトウェア・モジュールもしくはサブ・モジュールまたはその両方を使用して、上記のように実行されることが可能である。場合によっては、本願明細書に記載された機能の1つ以上を実装するために、専用ハードウェアが用いられてもよい。さらに、コンピュータ・プログラム製品は、この別個のソフトウェア・モジュールを備えるシステムの提供を含め、本願明細書に記載された1つ以上の方法ステップを実行するために実装されるようになっているコードを備えるコンピュータ可読ストレージ媒体を含むことができる。
【0063】
いずれにせよ、当然のことながら、本願明細書で示されたコンポーネントは、例えば、特定用途向け集積回路(ASIC:application specific integrated circuit)、機能回路、関連したメモリを備え適切にプログラムされた1つ以上の汎用デジタル・コンピュータおよび同様のものなど、様々な形態のハードウェア、ソフトウェアまたはその組み合わせにおいて実装され得る。本願明細書で提供された本発明の教示を所与として、当業者は、本発明のコンポーネントの他の実装を考えることができるであろう。
【0064】
本願明細書で使用される専門用語は、特定の実施形態について記載するためのものでしかなく、本発明の限定となることは目的としていない。本願明細書で使用される、単数形「a」、「an」および「the」は、文脈によりそうでないことが明確に示されていない限り、複数形も含むものとする。さらに、当然のことながら、「含む」もしくは「含んでいる」またはその両方の用語は、本明細書で使用される場合、記載された特徴、完全体、ステップ、動作、要素もしくはコンポーネント、またはそのいずれかの組み合わせの存在を指定するが、1つ以上の他の特徴、完全体、ステップ、動作、要素、コンポーネントもしくはそのグループ、またはそのいずれかの組み合わせの存在または追加を除外するものではない。
【0065】
以下の特許請求の範囲のミーンズまたはステップ・プラス・ファンクション構成要素すべての対応する構造、材料、動作および等価物は、明確に請求されている他の請求される構成要素とともに機能を実行する任意の構造、材料または動作を含むものとする。本発明の記載は、例示および説明のために示されたものであるが、包括的であることも、開示された形態の発明に限定されることも目的としていない。当業者には、本発明の範囲および意図から逸脱することのない、多数の変更および変形が明らかであろう。実施形態は、本発明の原理および実際の応用をもっともよく説明するよう、さらに当業者が、意図される特定の用途に適する様々な変更を用いた様々な実施形態に関して本発明を理解できるように選ばれ、記載された。
図1
図2
図3
図4
図5
図6
図7
図8