(57)【要約】【課題】複数のコンテナ間に伸縮性および競合があるシステムにおいて、潜在リソース容量を評価する方法および装置を提供する。【解決手段】より大きなコンテナの総容量を求めて競合している複数のコンテナのうちの少なくとも１つのコンテナに関して動的な潜在容量が判断される。競合している複数のコンテナそれぞれによる現在の利用量が取得され、競合しているコンテナそれぞれに関して平衡容量が判断される。平衡容量は、対応するコンテナが権限を有する容量を示す。総容量、および現在の利用量の１つ以上と、対応する平衡容量の１つ以上との比較、および競合している複数のコンテナそれぞれの相対的なリソース重みに基づき、動的な潜在容量が判断される。動的な潜在容量は、複数のコンテナのセットが変更された場合に、または各作業要素の割り当ての後に、任意選択で再算出される。【選択図】図７
2013524340.tif 000002
【特許請求の範囲】
【請求項１】
より大きなコンテナの総容量を求めて競合している複数のコンテナのうちの少なくとも１つのコンテナの、動的な潜在容量を判断する方法であって、前記方法は、
前記競合している複数のコンテナそれぞれによる現在の利用量を取得するステップと、
前記競合している複数のコンテナそれぞれに関して、対応する前記コンテナが権限を有する容量を示す平衡容量を判断するステップと、
前記総容量、および前記現在の利用量の１つ以上と、対応する前記平衡容量の１つ以上との比較、および前記競合している複数のコンテナそれぞれの相対的なリソース重みに基づき、前記動的な潜在容量を判断するステップと、
を含む方法。
【請求項２】
前記取得するステップは、前記複数のコンテナそれぞれの最小容量を取得するステップをさらに含む、請求項１に記載の方法。
【請求項３】
前記最小容量を上回る容量は、前記相対的な重みに従って配分される、請求項２に記載の方法。
【請求項４】
前記取得するステップは、最大容量を取得するステップをさらに含む、請求項１に記載の方法。
【請求項５】
第２のより大きな親コンテナ内に複数の前記より大きなコンテナをさらに含む、請求項１に記載の方法。
【請求項６】
前記複数のコンテナのセットが変更されると、前記動的な潜在容量を再算出するステップをさらに含む、請求項１に記載の方法。
【請求項７】
前記動的な潜在容量は、複数の親コンテナ間のコンテナ・マイグレーションのために用いられる、請求項１に記載の方法。
【請求項８】
前記動的な潜在容量は、作業の割り当てのために用いられる、請求項１に記載の方法。
【請求項９】
前記作業は、空き容量に基づき割り当てられる、請求項８に記載の方法。
【請求項１０】
各作業要素の前記割り当ての後に、前記動的な潜在容量を再算出するステップをさらに含む、請求項１に記載の方法。
【請求項１１】
前記方法は、前記複数のコンテナを少なくとも２つのグループに分けるステップをさらに含み、過剰利用グループは、全体的な平衡容量を超える利用量を有するコンテナを含む、請求項１に記載の方法。
【請求項１２】
前記総容量と、低利用グループ内のメンバの容量の合計との差として、前記過剰利用グループの前記動的な潜在容量を計算するステップをさらに含む、請求項１１に記載の方法。
【請求項１３】
前記過剰利用グループのうち、閾値を下回る利用量を有するメンバを、前記低利用グループに移動するステップをさらに含む、請求項１２に記載の方法。
【請求項１４】
より大きなコンテナの総容量を求めて競合している複数のコンテナのうちの少なくとも１つのコンテナの、動的な潜在容量を判断する装置であって、前記装置は、
メモリと、
前記メモリに結合された少なくとも１つのプロセッサと、
を含み、前記プロセッサは、
前記競合している複数のコンテナそれぞれによる現在の利用量を取得し、
前記競合している複数のコンテナそれぞれに関して、対応する前記コンテナが権限を有する容量を示す平衡容量を判断し、
前記総容量、および前記現在の利用量の１つ以上と、対応する前記平衡容量の１つ以上との比較、および前記競合している複数のコンテナそれぞれの相対的なリソース重みに基づき、前記動的な潜在容量を判断するよう動作する、装置。
【請求項１５】
前記プロセッサはさらに、前記複数のコンテナそれぞれの最小容量を取得するよう構成されている、請求項１４に記載の装置。
【請求項１６】
前記最小容量を上回る容量は、前記相対的な重みに従って配分される、請求項１５に記載の装置。
【請求項１７】
第２のより大きな親コンテナ内に複数の前記より大きなコンテナをさらに含む、請求項１４に記載の装置。
【請求項１８】
前記プロセッサはさらに、前記複数のコンテナのセットが変更されると、前記動的な潜在容量を再算出するよう構成されている、請求項１４に記載の装置。
【請求項１９】
前記動的な潜在容量は、複数の親コンテナ間のコンテナ・マイグレーションのために用いられる、請求項１４に記載の装置。
【請求項２０】
前記動的な潜在容量は、作業の割り当てのために用いられる、請求項１４に記載の装置。
【請求項２１】
前記作業は、空き容量に基づき割り当てられる、請求項２０に記載の装置。
【請求項２２】
前記プロセッサはさらに、各作業要素の前記割り当ての後に、前記動的な潜在容量を再算出するよう構成されている、請求項１４に記載の装置。
【請求項２３】
前記プロセッサはさらに、前記複数のコンテナを少なくとも２つのグループに分けるよう構成されており、過剰利用グループは、全体的な平衡容量を超える利用量を有するコンテナを含み、前記過剰利用グループの前記動的な潜在容量は、前記総容量と、低利用グループ内のメンバの容量の合計との差として計算される、請求項１４に記載の装置。
【請求項２４】
前記プロセッサはさらに、前記過剰利用グループのうち、閾値を下回る利用量を有するメンバを、前記低利用グループに移動するよう構成されている、請求項２３に記載の装置。
【請求項２５】
より大きなコンテナの総容量を求めて競合している複数のコンテナのうちの少なくとも１つのコンテナの、動的な潜在容量を判断する製造品であって、前記製造品は、１つ以上のプログラムを含むマシン可読ストレージ媒体を含み、前記１つ以上のプログラムは、実行されると、
前記競合している複数のコンテナそれぞれによる現在の利用量を取得するステップと、
前記競合している複数のコンテナそれぞれに関して、対応する前記コンテナが権限を有する容量を示す平衡容量を判断するステップと、
前記総容量、および前記現在の利用量の１つ以上と、対応する前記平衡容量の１つ以上との比較、および前記競合している複数のコンテナそれぞれの相対的なリソース重みに基づき、前記動的な潜在容量を判断するステップと、
を実装する、製造品。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、全般的に、電気、電子およびコンピュータ技術に関し、特に、仮想化をサポートするプラットフォームのリソースの動的な容量に関する。
【背景技術】
【０００２】
コンピュータ・リソースが共有される場合、スケジューラが、利用可能な１つ以上のプロセッサまたは他のリソースにプロセスを割り当てる。典型的には、スケジューラは、ジョブの要件と、リソース（単数または複数）の能力および容量とを適合させることによって、バッチ・ジョブなどの作業（ｗｏｒｋ）を割り当てる。従来、ジョブは、現在の利用量（ｕｔｉｌｉｚａｔｉｏｎ）および固定の容量に基づき、物理リソースに直接割り当てられていた。しかし最近は、基礎をなすリソースの抽象化をそれぞれ提供する１つ以上のリソース・コンテナ（「仮想マシン」と呼ばれることが多い）を介して物理リソースが公開される。共有される物理リソースには、例えば、処理用コア、ストレージ・システムおよびネットワーク通信リソースが含まれ得る。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
マルチコンテナ環境では、典型的にはコンテナ・マネージャの監視下で、様々なコンテナが、プロセッサ・サイクルなどの固定の物理リソースを共有し、それを求めて競合する。典型的には、コンテナ・マネージャは、ルールまたはポリシのセットに従って物理リソースをコンテナに割り当てる。リソースをめぐるコンテナ間の競合は、スケジューリング問題にいっそう大きな複雑性を付加する。コンテナのリソース容量の評価は、あらゆるスケジューリング・プロセスにおいて重要なステップである。さらに、コンテナは、作業の実行中に追加、削除、中断されること、またはオンライン状態にされることもある。これらのアクションを計画し、既存のコンテナおよびジョブに対する影響を推定することも、重要なアクティビティである。しかし、マルチコンテナ環境では、リソース容量を評価することは困難である。
【０００４】
したがって、仮想コンテナのシステムにおいてリソース容量を評価する方法および装置に対するニーズが存在する。物理容量を共有するすべての仮想コンテナにわたって動的なリソース容量を評価する方法および装置に対して、さらなるニーズが存在する。
【課題を解決するための手段】
【０００５】
概して、仮想マシンなどの複数のコンテナ間に伸縮性（ｅｌａｓｔｉｃｉｔｙ）および競合があるシステムにおいて、潜在リソース容量を評価する（例えばジョブ割り当てのために）方法および装置が提供される。本発明の一側面によれば、より大きなコンテナの総容量を求めて競合している複数のコンテナのうちの少なくとも１つのコンテナに関して動的な潜在容量が判断される。競合している複数のコンテナそれぞれによる現在の利用量が取得され、競合しているコンテナそれぞれに関して平衡容量（ｅｑｕｉｌｉｂｒｉｕｍ  ｃａｐａｃｉｔｙ）が判断される。平衡容量は、対応するコンテナが権限を有する容量を示す。総容量、および現在の利用量の１つ以上と、対応する平衡容量の１つ以上との比較、および競合している複数のコンテナそれぞれの相対的なリソース重み（ｒｅｓｏｕｒｃｅ  ｗｅｉｇｈｔ）に基づき、動的な潜在容量が判断される。
【０００６】
本発明の別の側面によれば、動的な潜在容量は、複数のコンテナのセットが変更された場合に、または各作業要素の割り当ての後に、任意選択で再算出（ｒｅｃａｌｃｕｌａｔｅ）される。判断された動的な潜在容量は、例えば、複数の親コンテナ間のコンテナ・マイグレーション（ｃｏｎｔａｉｎｅｒ  ｍｉｇｒａｔｉｏｎ）または作業の割り当てのために用いることが可能である。
【０００７】
例示的な一実施形態では、この複数のコンテナは、少なくとも２つのグループに分けられる。過剰利用グループ（ｏｖｅｒｕｔｉｌｉｚｅｄ  ｇｒｏｕｐ）は、全体的な（ｇｌｏｂａｌ）平衡容量を超える利用量を有するコンテナを含み、低利用グループ（ｕｎｄｅｒｕｔｉｌｉｚｅｄ  ｇｒｏｕｐ）は、全体的な平衡容量を下回る利用量を有するコンテナを含む。過剰利用グループの動的な潜在容量は、総容量と、低利用グループ内のメンバ（ｍｅｍｂｅｒ）の容量の合計との差として計算可能である。過剰利用グループのうち、閾値を下回る利用量を有するメンバは、低利用グループに移動される。
【０００８】
以下の詳細な説明および図面を参照することで、本発明、ならびに本発明のさらなる特徴および利点のより完全な理解が得られる。
【図面の簡単な説明】
【０００９】
【図１】例示的な従来のジョブ・スケジューラの概要を提供する。
【図２】別の例示的な従来のジョブ・スケジューラの概要を提供する。
【図３】例示的な２つのコンテナの、様々なタイプのコンテナ容量を示す。
【図４】コンテンション（ｃｏｎｔｅｎｔｉｏｎ）状態にある例示的な２つのコンテナに対するリソースの割り振りを示す。
【図５】本発明の特徴を取り入れた潜在容量評価プロセスの実施形態の例示的な擬似コードを示す。
【図６】３つのコンテナの例示的なセットに対するリソースの割り振りの例を提供する。
【図７】本発明による、空き容量を評価する装置の概略ブロック図である。
【図８】本発明の１つ以上の側面もしくは要素またはその両方を実装するのに有用となり得るコンピュータ・システムを示す。
【発明を実施するための形態】
【００１０】
本発明は、複数のコンテナ（例えば仮想マシン）間に伸縮性および競合があるシステムにおいて、潜在リソース容量を評価する（例えばジョブ割り当てのために）方法および装置を提供する。図１は、例示的な従来のジョブ・スケジューラ１００の概要を提供する。図１に示されているように、ジョブ・キュー１１０に記憶されている１つ以上のジョブが、ジョブ・スケジューラ１２０によって処理され、与えられたジョブそれぞれが、物理的な計算プラットフォーム１５０などの利用可能な１つ以上の物理リソースに割り当てられる。物理リソース１５０は、例えば、処理用コア、ストレージ・システムおよびネットワーク通信リソースを含み得る。前述のように、スケジューラ１２０は、ジョブの要件と、リソース１５０の能力および容量とを適合させることによって、ジョブを割り当てる。
【００１１】
図１に示されているように、物理リソース１５０は、基礎をなすリソース１５０の抽象化をそれぞれ提供する１つ以上のリソース・コンテナ１３０を介して公開される。典型的には、例示的なコンテナ１３０は、これらの基礎をなす物理リソース１５０を、コンテナ・マネージャ１４０の監視下で共有する。多くの場合、コンテナ１３０は、基礎をなすリソース１５０を求めて競合し合う。
【００１２】
図１のジョブ・スケジューラ１００は、単一のレイヤのコンテナ１３０を用いる。図２は、別の例示的な従来のジョブ・スケジューラ２００の概要を提供する。図２に示されているように、コンテナ２３０−１などの特定のコンテナが、１つ以上のさらなるコンテナ２１０−１〜２１０−Ｎおよび１つ以上のコンテナ・マネージャ２２０をホストすることができる。
【００１３】
本発明は、マルチコンテナ環境では、様々なコンテナ１３０、２３０が固定のプラットフォーム・リソース１５０、２５０を共有し、それを求めて競合するということを認識したものである。コンテナ１３０、２３０のリソース容量の評価は、スケジューラ１２０によって実行されるスケジューリング・プロセスの重要なステップである。
【００１４】
本発明の一側面によれば、複数のコンテナ１３０、２３０を有するシステムに関して、潜在リソース容量が評価される。図３は、例示的な２つのコンテナＡ、Ｂの、様々なタイプのコンテナ容量を示す。図３に示されているように、固定のサイズを有する親コンテナ３２０（またはプラットフォーム）が、総物理容量を提供する。総物理容量は、コンテナＡおよびＢに動的に割り振られる。コンテナＡ上で実行されている例示的なジョブがある。コンテナＡ上で実行されている例示的なジョブは、利用量ＪＡを有する。
【００１５】
例示的な２つのコンテナＡ、Ｂはそれぞれ、潜在容量（ＰＣ：ｐｏｔｅｎｔｉａｌ  ｃａｐａｃｉｔｙ）を有する。例えば、コンテナＡは、潜在容量ＰＣＡを有する。本願明細書で使用される、潜在容量は、各コンテナが現在利用してもよい量に対応する（例えば、利用可能な最大容量）。潜在容量は、システムの状態、およびコンテンション中にマネージャがどのようにリソースを配分するかによって決まる。図３に示されているように、コンテナＡ上で実行されているジョブは、リソースの量Ｊを消費する。
【００１６】
例示的な２つのコンテナＡ、Ｂは、空き容量（ＦＣ：ｆｒｅｅ  ｃａｐａｃｉｔｙ）を有する。例えば、コンテナＡは、空き容量ＦＣＡを有する。本願明細書で使用される、空き容量とは、潜在容量を限度とした、各コンテナ内に残っているリソースである（例えば、新たな作業に利用可能な容量）。したがって、コンテナの潜在容量は、以下のように表すことができる。
ＰＣ＝Ｊ＋ＦＣ
【００１７】
したがって、空き容量は、潜在容量および利用量から算出可能である。なお、システムの状態によっては、すべてのコンテナの潜在容量の合計が、基礎をなすプラットフォームの物理容量を超えることがあり得る。概して、各コンテナＡ、Ｂの潜在容量は、物理容量、コンテナ属性、状態およびすべてのコンテナにわたる利用量から計算される。
【００１８】
各コンテナの空き容量は、ジョブ・スケジューリング・アルゴリズムにおける重要なパラメータであることが多い。例えば、従来の典型的なスケジューリング方法は、最大の空き容量を備えるプラットフォームに各ジョブを割り当てる。こうして、スケジューリングは、基本的なロード・バランシングを提供して、利用可能なマシン間にジョブを分配する。物理リソースに関するスケジューリングの従来の状況では、プラットフォームの空き容量は、利用量モニタから直接入手できる。一方、競合しているコンテナに関するスケジューリングの場合、コンテナ・マネージャ１４０、２４０によって実装されるルールおよびポリシによって空き容量が決まるため、空き容量は、現在のシステム状態（例えば、すべてのコンテナにおけるリソースの利用量）から取得することはできない。
【００１９】
仮想コンテナの潜在容量の算出
前述のように、本発明は、複数のコンテナ１３０、２３０を有するシステムにおいて潜在容量を評価する方法および装置を提供する。本発明の一側面によれば、現在のシステム状態を所与とし、コンテナ・マネージャ１４０がコンテナ１３０、２３０間の要求を調停する（ａｒｂｉｔｒａｔｅ）のに用いるルールを使用して、各コンテナ１３０、２３０に関して潜在リソース容量が評価される。続いて、この潜在容量が、ジョブ割り当てアルゴリズムにおいて適用され、実行する各ジョブまたはジョブ要素のコンテナが選ばれる。コンテナ１３０、２３０の潜在容量を評価する例示的なアルゴリズムについては、図５に関連して以下でさらに説明する。
【００２０】
予測されるリソース消費
各ジョブがコンテナ１３０、２３０に割り振られるとき、システム状態が変化するが、これは、次のジョブをスケジューリングするときに考慮されなければならない。これは例えば、ジョブのグループが同時にスケジュールされ、次のジョブを割り当てる前に各ジョブ配置の影響を推定する時間が十分にない場合、問題となり得る。
【００２１】
実行中に各ジョブが消費する所与のリソースの量は、平均して既知であることもある。したがって、ジョブがコンテナに割り振られた後、平均リソース消費を使用して、コンテナの空き使用量が調節されることが可能である。例示的な一実施形態では、平均リソース消費が利用可能でない場合、例えば、そのタイプのジョブの、最近のリソース消費の平均に基づいて、予測が行われることが可能である。
【００２２】
ジョブによるリソース消費は、変動することが多い。したがって、別の変形では、潜在容量および空き容量は、システム上のジョブおよび競合するジョブの統計的使用量に従って割り当てられる。例えば、９０％の確率で空き容量が０．８の値以下であると仮定するなどである。
【００２３】
さらに別の変形では、平均リソース消費が利用可能でない場合、例えば、平衡点容量（ｅｑｕｉｌｉｂｒｉｕｍ  ｐｏｉｎｔ  ｃａｐａｃｉｔｙ）に基づき、既定の量が用いられることが可能である。
【００２４】
本発明の別の側面によれば、各コンテナ１３０、２３０の潜在リソース容量は、リソース・コンテンションを調停する特定のコンテナ・モデルに基づき評価される。本願明細書で使用される、「平衡リソース」という用語は、すべてのコンテナからの完全なコンテンションという限界状態で各コンテナに割り振られるリソースを示す。平衡点は、完全なコンテンションの下で重要な側面である。さらに、完全または部分的なコンテンションの状況でどのようにしてコンテナ間に公平にリソースが分配されるかを定義するコンテナ属性のセットに基づいて空き容量を計算するために、図５に関連して下記でさらに説明される例示的なアルゴリズムに、平衡点が用いられる。
【００２５】
競合するコンテナに対するリソースの割り振り
図４は、コンテンション状態にある例示的な２つのコンテナ１、２に対するリソースの割り振りを示す。図４では、利用量ｕ１、ｕ２が、単一（例えば、ｕ１＋ｕ２＝１）の総容量を求めて競合している各コンテナ１、２の各軸上に示されている。第１の線４１０は、利用量ｕ１が水平軸に沿って増加するときの、利用量ｕ２の潜在容量を示す。同様に、第２の線４２０は、利用量ｕ２に対し対応する潜在容量を示す。各コンテナ１、２には、対応する最大利用量ｌｍｔがある。さらに図４に示されているように、各コンテナ１、２には、対応する予約された利用量ｒｅｓがある。さらに図４に示されているように、各コンテナ１、２には、対応する潜在容量ｃｉがある。
【００２６】
２つの潜在容量の交点ｃｉ（ｃ１＝ｃ２）が、平衡点４３０であり、完全なコンテンションのもとではシステム状態がここに収束する。言い換えれば、平衡点４３０では、両コンテナ１、２が、そのそれぞれのリソースの平衡点４３０を超えて使用しようとする。平衡点４３０は、各コンテナの利用量がその平衡点を上回るかまたは下回るかによって、システムの状態を区分するのに有用である。
【００２７】
概して、コンテナ１は、最大利用量ｌｍｔ１から開始する。コンテナ２が利用量を得るにつれて、両コンテナは、平衡点４３０へと移動する。後述のように、平衡点４３０は、スペースを４つの領域に分ける。
【００２８】
潜在容量評価プロセス
図５は、本発明の特徴を取り入れた潜在容量評価プロセス５００の実施形態の例示的な擬似コードを示す。概して、例示的な潜在容量評価プロセス５００は、コンテナ１３０、２３０の潜在容量を評価する。図５に示されているように、現在のコンテナを示すインデックスｉｄｘ、プラットフォームの総物理容量ｐＣａｐ、各コンテナｉの現在の利用量を示す配列（ａｒｒａｙ）ｕｉ、各コンテナｉの予約（最小）容量を示す配列ｒｅｓｉ、各コンテナｉの最大容量（ｍａｘｉｍｕｍ  ｃａｐａｃｉｔｙ）を示す配列ｌｍｔｉ、および各コンテナｉの重みまたは相対的シェアを示す配列ｗｉが、ステップ１の間に例示的な潜在容量評価プロセス５００に渡される。
【００２９】
ステップ２の間に、コンテナ属性と、割り当てられたシェアに従った、コンテナ最小量より上の配分容量とに基づき、平衡容量（ｃｉｅ）が各コンテナに関して計算される。現在のコンテナの利用量変数ｕｉｄｘが、ステップ３の間に初期化される（例えば無限大に）。
【００３０】
潜在容量評価プロセス５００は、現在のメンバの潜在動的容量ｃｉｄｘを、以下のように算出する。例示的な実施形態では、潜在容量評価プロセス５００は、ステップ４の間に、メンバ・コンテナを２つのグループに分ける。第１のグループｗｏｒｋＧは、割り当てられた全体的な平衡容量を利用量が超えるメンバならびに現在のメンバから成る。第２のグループｕｎｃｈｇＧは、残りのメンバから成る。例示的な実施形態では、容量が、第１のグループの１つ以上のメンバから減らされる（このメンバは権限を有するよりも多く使用しているため）。
【００３１】
ステップ４〜９のループに入り、１つのグループからもう一方のグループへ移動するメンバがなくなるまで（ステップ９において検出される）繰り返される。ステップ６の間に、第１のグループに関して潜在容量が再計算され、第２のグループの潜在容量は保持される。こうして、総容量ｐＣａｐと、第２の（低利用）グループ内のメンバの容量の合計との差として、第１の（過剰利用）グループの利用可能な容量（平衡容量に関連して）が計算される。
【００３２】
ステップ７および８の間、増分グループｉｎｃＧが用いられ、メンバの平衡容量（すなわち、コンテナがどれだけの容量に対し権限を有するか）よりも利用量が小さい過剰利用グループのメンバを、低利用グループに移動させる（現在のメンバ以外）。
【００３３】
ステップ１０の間に、現在のメンバがまだ過剰利用グループにあると判断されれば、ステップ１１の間に、現在のメンバの潜在容量が、コンテナ属性に基づき返され、容量がシェアに従って配分される。
【００３４】
一方、ステップ１０の間に、現在のメンバが過剰利用グループにないと判断されれば、現在のメンバの潜在容量が、ステップ１３の間に返される。潜在容量評価プロセス５００については、図６の例に関連してさらに後述される。
【００３５】
図６は、３つのコンテナ（仮想マシン）ＶＭ（ｖｉｒｔｕａｌ  ｍａｃｈｉｎｅ：仮想マシン）１〜ＶＭ３の例示的なセットに関して、平衡、潜在および空き容量がどのように評価されるかの例６００を提供する。図６に示されているように、各コンテナＶＭ１〜ＶＭ３の予約量、シェアおよび現在の利用量が、最初の３つのレコード６１０、６２０、６３０に示されている。上述の通り、シェアは、コンテンション状態でリソース（単数または複数）を配分するために使用される、各コンテナの相対的な重みである。
【００３６】
レコード６４０は、潜在容量評価プロセス５００の６行目の間に判断される、３つすべてのコンテナＶＭ１〜ＶＭ３の平衡容量の算出に対応する。これは、各コンテナＶＭ１〜ＶＭ３が、それぞれできる限り多くのリソースを取得しようとする場合に与えられるものである平衡容量ｃｉｅをもたらす。ここでは、単一の総物理容量があり、各コンテナに０．３の予約量がある。したがって、コンテナの重みに比例して共有するのは、残り０．１である。したがって、平衡状態にある各コンテナは、その予約量の０．３に加えて、０．１のうちのそのシェアを与えられる。
【００３７】
例えば、コンテナＶＭ２は、６の総シェアのうち、２のシェアを割り当てられている。したがって、コンテナＶＭ２の平衡容量は、レコード６４０において、コンテナＶＭ２の最小予約量（０．３）と、総予約量の後（すなわち、単一の総物理容量から、すべてのコンテナに割り当てられている総予約量（コンテナ毎に０．３）を減じたもの）の残りの物理容量の比例配分（割り当てられたシェアに基づく）分とを合計することによって計算される。
【００３８】
図５に関連して上述したように、平衡容量は、１つのグループからもう一方のグループへ移動するメンバがなくなるまで、ループ内でステップ６において計算される。コンテナＶＭ１に関しては、コンテナＶＭ２およびＶＭ３両方の現在の利用量（レコード６３０）が、判断された平衡容量を下回る（したがってコンテナＶＭ２およびＶＭ３の容量がコンテナＶＭ１に再割り当てされることはできない）ため、レコード６４０に示されている初期の算出の後、平衡容量の算出は完了する。例えば、０．３という、コンテナＶＭ２のレコード６３０における現在の利用量は、コンテナＶＭ２に関してレコード６４０に示されている、０．３３３という対応する判断された平衡容量を下回る。
【００３９】
コンテナＶＭ２に関して、平衡容量の算出が、レコード６５０に示されているように、潜在容量評価プロセス５００におけるループの第２の反復中に継続する。コンテナＶＭ３の現在の利用量（レコード６３０）は、レコード６４０内の、コンテナＶＭ３の判断された平衡容量を下回るため、コンテナＶＭ３の容量は、コンテナＶＭ２に再割り当てされることはできない。したがって、コンテナＶＭ３は、コンテナＶＭ２の平衡容量を計算するとき、レコード６５０における考慮対象から除外される。したがって、コンテナＶＭ３の現在の利用量は、利用可能な物理容量から除外され、レコード６５０内には、コンテナＶＭ１およびＶＭ２間に割り振られる０．７５の有効物理容量が残る。コンテナＶＭ１の現在の利用量はその平衡容量を超えているため、コンテナＶＭ２は、コンテナＶＭ１と競合する権限を有する。その結果として、コンテナＶＭ１およびＶＭ２は、それらの０．３の予約量と、ＶＭ３の０．２５の現在の利用量とを超える分のリソースを求めて競合する。
【００４０】
レコード６５０に示されているように、コンテナＶＭ２の平衡容量は、コンテナＶＭ２の最小予約量（０．３）と、総予約量の後（すなわち、考慮されるコンテナＶＭ１およびＶＭ２が利用可能な０．７５の総物理容量から、考慮されるコンテナＶＭ１およびＶＭ２に割り当てられている総予約量（コンテナ毎に０．３）を減じたもの）の残りの物理容量の比例配分（考慮されるコンテナＶＭ１およびＶＭ２の割り当てられたシェアに基づく）分とを合計することによって計算される。レコード６５０の結果は、コンテナＶＭ２内のジョブが、プラットフォーム・リソースの０．４を取得できる可能性があるということである。結果として生じるコンテナＶＭ２の潜在容量が、レコード６７０に記載されている。
【００４１】
同様に、コンテナＶＭ３に関して、平衡容量の算出が、レコード６６０に示されているように、ループのもう１つの反復中に継続する。コンテナＶＭ２の現在の利用量（レコード６３０）は、レコード６４０内の、コンテナＶＭ２の判断された平衡容量を下回るため、コンテナＶＭ２の容量は、コンテナＶＭ３に再割り当てされることはできない。したがって、コンテナＶＭ２は、コンテナＶＭ３の平衡容量を計算するとき、レコード６６０における考慮対象から除外される。したがって、コンテナＶＭ２の現在の利用量は、利用可能な物理容量から除外され、レコード６６０内に、コンテナＶＭ１およびＶＭ３間に割り振られる０．７の有効物理容量が残る。レコード６６０に示されているように、コンテナＶＭ３の平衡容量は、コンテナＶＭ３の最小予約量（０．３）と、総予約量の後（すなわち、考慮されるコンテナＶＭ１およびＶＭ３が利用可能な０．７の総物理容量から、考慮されるコンテナＶＭ１およびＶＭ３に割り当てられている総予約量（コンテナ毎に０．３）を減じたもの）の残りの物理容量の比例配分（考慮されるコンテナＶＭ１およびＶＭ３の割り当てられたシェアに基づく）分とを合計することによって計算される。コンテナＶＭ３は、０．３の予約容量を保証されている。したがって、共有される有効量（ｕｔｉｌｉｔｙ）は、０．１（１−０．３−０．３−０．３）である。この結果、ＶＭ３に関しては０．３７５の潜在容量となる。
【００４２】
各コンテナＶＭ１〜ＶＭ３の潜在容量および空き容量が、レコード６７０、６８０に示されている。
【００４３】
図７は、本発明による、空き容量を評価する装置７００の概略ブロック図である。図７に示されているように、空き容量評価ブロック７４０が、ブロック７３０から利用量の測定結果を、データ・ストア７５０からコンテナ情報（属性およびポリシなど）を取得する。これらの値は、例えば、図５の潜在容量評価プロセス５００によって、リソース７２０をキュー７１０内のリクエストに基づき割り振るために処理される。
【００４４】
例示的なシステムおよび製造品の詳細
当業者であれば当然のことであるが、本発明の側面は、システム、方法またはコンピュータ・プログラム製品として具現化され得る。したがって、本発明の側面は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）、または本願明細書においてすべて概して「回路」、「モジュール」もしくは「システム」と呼ばれ得る、ソフトウェアおよびハードウェアの側面を兼ね備えた実施形態の形態をとってもよい。さらに、本発明の側面は、コンピュータ可読プログラム・コードが具現化された１つ以上のコンピュータ可読媒体（単数または複数）において具現化された、コンピュータ・プログラム製品の形態をとることもできる。
【００４５】
本発明の１つ以上の実施形態またはその要素は、メモリと、メモリに結合され例示的な方法ステップを実行するよう動作する少なくとも１つのプロセッサとを含む装置の形態で実装可能である。
【００４６】
１つ以上の実施形態が、汎用コンピュータまたはワークステーション上で実行されているソフトウェアを使用することができる。図８は、本発明の１つ以上の側面もしくは要素またはその両方を実装するのに有用となり得るコンピュータ・システム８００を示す。図８に関連して、そのような実装は、例えばプロセッサ８０２、メモリ８０４、ならびに例えばディスプレイ８０６およびキーボード８０８により構成される入出力インターフェイスを用いてもよいであろう。本願明細書で使用される「プロセッサ」という用語は、例えば、ＣＰＵ（ｃｅｎｔｒａｌ  ｐｒｏｃｅｓｓｉｎｇ  ｕｎｉｔ：中央処理ユニット）もしくはその他の形態の処理回路またはその両方を含むものなどの、任意の処理デバイスを含むものとする。さらに、「プロセッサ」という用語は、２つ以上の個別のプロセッサを指すこともある。「メモリ」という用語は、例えば、ＲＡＭ（ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｍｅｍｏｒｙ：ランダム・アクセス・メモリ）、ＲＯＭ（ｒｅａｄ  ｏｎｌｙ  ｍｅｍｏｒｙ：読み取り専用メモリ）、固定メモリ・デバイス（例えばハード・ドライブ）、取り外し可能メモリ・デバイス（例えばディスケット）、フラッシュ・メモリおよび同様のものなど、プロセッサまたはＣＰＵに関連するメモリを含むものとする。さらに、本願明細書で使用される「入出力インターフェイス」という語句は、例えば、処理ユニットにデータを入力する１つ以上のメカニズム（例えばマウス）、および処理ユニットと関連する結果を提供する１つ以上のメカニズム（例えばプリンタ）を含むものとする。プロセッサ８０２、メモリ８０４、ならびにディスプレイ８０６およびキーボード８０８などの入出力インターフェイスは、例えばデータ処理ユニット８１２の一部としてのバス８１０によって、相互接続可能である。例えばバス８１０による適切な相互接続は、コンピュータ・ネットワークとインターフェイス接続するために提供され得るネットワーク・カードなどのネットワーク・インターフェイス８１４に対しても、媒体８１８とインターフェイス接続するために提供され得るディスケットまたはＣＤ−ＲＯＭ（ｃｏｍｐａｃｔ  ｄｉｓｃ  ｒｅａｄ−ｏｎｌｙ  ｍｅｍｏｒｙ：コンパクト・ディスク読み取り専用メモリ）ドライブなどの媒体インターフェイス８１６に対しても、提供されることが可能である。
【００４７】
アナログ・ビデオ・フィードなどのアナログ入力を受信して、それをデジタル化するよう、アナログ・デジタル変換器（単数または複数）８２０が提供されてもよい。そのような変換器（単数または複数）は、システム・バス８１０と相互接続されてもよい。
【００４８】
したがって、本願明細書に記載される、本発明の方法を実行するための命令またはコードを含むコンピュータ・ソフトウェアは、関連するメモリ・デバイス（例えば、ＲＯＭ、固定または取り外し可能メモリ）の１つ以上に記憶され、利用の準備ができると、一部または全部が（例えばＲＡＭに）ロードされて、ＣＰＵにより実装されてもよい。そのようなソフトウェアは、ファームウェア、常駐ソフトウェア、マイクロコードおよび同様のものを含むことができると考えられるが、これらに限定はされない。
【００４９】
プログラム・コードの記憶もしくは実行またはその両方に適したデータ処理システムは、システム・バス８１０を介してメモリ要素８０４に直接または間接的に結合された少なくとも１つのプロセッサ８０２を含む。メモリ要素は、プログラム・コードを実際に実装する間に用いられるローカル・メモリ、大容量ストレージ、および実装中にコードが大容量ストレージから読み出されなければならない回数を減らすために少なくとも一部のプログラム・コードの一時的なストレージとなるキャッシュ・メモリを含むことができる。
【００５０】
入出力、すなわちＩ／Ｏデバイス（限定はされないが、キーボード８０８、ディスプレイ８０６、ポインティング・デバイスおよび同様のものを含む）は、直接（バス８１０などによって）または介在するＩ／Ｏコントローラ（明確にするために省略）を介して、システムに結合可能である。
【００５１】
ネットワーク・インターフェイス８１４などのネットワーク・アダプタもシステムに結合されて、データ処理システムが、他のデータ処理システムまたはリモート・プリンタまたはストレージ・デバイスに、介在するプライベートまたはパブリック・ネットワークを介して結合された状態となることを可能にしてもよい。モデム、ケーブル・モデムおよびイーサネット（Ｒ）・カードが、現在利用可能なタイプのネットワーク・アダプタのごく一部である。
【００５２】
特許請求の範囲を含め、本願明細書で使用される「サーバ」は、サーバ・プログラムを実行する物理データ処理システム（例えば、図８に示されているシステム８１２）を含む。当然のことながら、そのような物理サーバは、ディスプレイおよびキーボードを含んでも含まなくてもよい。
【００５３】
前述のように、本発明の側面は、コンピュータ可読プログラム・コードが具現化された１つ以上のコンピュータ可読媒体（単数または複数）において具現化された、コンピュータ・プログラム製品の形態をとることもできる。１つ以上のコンピュータ可読媒体（単数または複数）の任意の組み合わせが利用され得る。コンピュータ可読媒体は、コンピュータ可読信号媒体またはコンピュータ可読ストレージ媒体とされ得る。コンピュータ可読ストレージ媒体は、例えば、限定はされないが、電子、磁気、光学、電磁気、赤外線もしくは半導体のシステム、装置もしくはデバイス、または前述のものの任意の適切な組み合わせとすることもできる。媒体ブロック８１８は、非限定的な例である。コンピュータ可読ストレージ媒体のより具体的な例（包括的でないリスト）には、１つ以上のワイヤを有する電気的接続、ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、消去可能プログラム可能読み取り専用メモリ（ＥＰＲＯＭ（ｅｒａｓａｂｌｅ  ｐｒｏｇｒａｍｍａｂｌｅ  ｒｅａｄ−ｏｎｌｙ  ｍｅｍｏｒｙ）またはフラッシュ・メモリ）、光ファイバ、ポータブル・コンパクト・ディスク読み取り専用メモリ（ＣＤ−ＲＯＭ）、光学式ストレージ・デバイス、磁気ストレージ・デバイスまたは前述のものの任意の適切な組み合わせが含まれるであろう。この文書の文脈では、コンピュータ可読ストレージ媒体は、命令実行システム、装置もしくはデバイスによって、またはそれに関連して使用されるプログラムを含むことまたは記憶することができる任意の有形の媒体であればよい。
【００５４】
コンピュータ可読信号媒体は、例えば、ベースバンドに、または搬送波の一部として、コンピュータ可読プログラム・コードが具現化された伝搬データ信号を含み得る。そのような伝搬信号は、電磁気、光学またはその任意の適切な組み合わせを含むがこれらに限定はされない、様々な形態のいずれかをとってよい。コンピュータ可読信号媒体は、コンピュータ可読ストレージ媒体ではなく、命令実行システム、装置もしくはデバイスによって、またはそれに関連して使用されるプログラムを伝達、伝搬または搬送することができる、任意のコンピュータ可読媒体としてよい。
【００５５】
コンピュータ可読媒体上に具現化されたプログラム・コードは、無線、有線、光ファイバ・ケーブル、ＲＦなど、または前述のものの任意の適切な組み合わせを含むがこれらに限定はされない任意の適切な媒体を使用して送られてもよい。
【００５６】
本発明の側面の動作を実行するコンピュータ・プログラム・コードは、Ｊａｖａ（Ｒ）、Ｓｍａｌｌｔａｌｋ（Ｒ）、Ｃ＋＋または同様のものなどのオブジェクト指向プログラミング言語、および「Ｃ」プログラミング言語もしくは同様のプログラミング言語などの従来の手続きプログラミング言語を含む、１つ以上のプログラミング言語の任意の組み合わせで書かれていてよい。プログラム・コードは、スタンド・アロン・ソフトウェア・パッケージとして、完全にユーザのコンピュータ上で実行されることも、部分的にユーザのコンピュータ上で実行されることも、または部分的にユーザのコンピュータ上で、かつ部分的にリモート・コンピュータ上で実行されることも、または完全にリモート・コンピュータもしくはサーバ上で実行されることもできる。後者のシナリオでは、ローカル・エリア・ネットワーク（ＬＡＮ：ｌｏｃａｌ  ａｒｅａ  ｎｅｔｗｏｒｋ）もしくは広域ネットワーク（ＷＡＮ：ｗｉｄｅ  ａｒｅａ  ｎｅｔｗｏｒｋ）を含む任意の種類のネットワークを介してリモート・コンピュータがユーザのコンピュータに接続されてもよく、または（例えば、インターネット・サービス・プロバイダを使用しインターネットを介して）外部コンピュータに接続されてもよい。
【００５７】
本発明の側面について、本発明の実施形態による方法、装置（システム）およびコンピュータ・プログラム製品のフローチャート図もしくはブロック図またはその両方を参照して以下に記載する。当然のことながら、フローチャート図もしくはブロック図またはその両方の各ブロック、およびフローチャート図もしくはブロック図またはその両方の複数ブロックの組み合わせは、コンピュータ・プログラム命令により実装可能である。マシンを生じるよう、こうしたコンピュータ・プログラム命令が、汎用コンピュータ、専用コンピュータまたはその他のプログラム可能データ処理装置のプロセッサに提供されて、この命令が、コンピュータまたはその他のプログラム可能データ処理装置のプロセッサにより実行されて、フローチャートもしくはブロック図またはその両方のブロックもしくは複数ブロックにおいて指定された機能／動作を実装する手段を作り出すようにすることもできる。
【００５８】
さらに、特定の形で機能するようコンピュータ、その他のプログラム可能データ処理装置またはその他のデバイスに指示することができるこうしたコンピュータ・プログラム命令は、コンピュータ可読媒体に記憶されて、コンピュータ可読媒体に記憶されたこの命令が、フローチャートもしくはブロック図またはその両方のブロックもしくは複数ブロックにおいて指定された機能／動作を実装する命令を含む製造品を生じるようにすることもできる。
【００５９】
さらに、コンピュータ・プログラム命令は、コンピュータ、その他のプログラム可能データ処理装置またはその他のデバイスにロードされて、コンピュータ、その他のプログラム可能装置またはその他のデバイス上で一連の動作ステップが実行されるようにしてコンピュータで実装されるプロセスを生じさせ、コンピュータまたはその他のプログラム可能装置上で実行される命令が、フローチャートもしくはブロック図またはその両方のブロックもしくは複数ブロックにおいて指定された機能／動作を実装するためのプロセスを提供するようにすることもできる。
【００６０】
各図面のフローチャートおよびブロック図は、本発明の様々な実施形態によるシステム、方法およびコンピュータ・プログラム製品の考えられる実装のアーキテクチャ、機能性および動作を示す。この関連で、フローチャートまたはブロック図内の各ブロックは、指定の論理機能（単数または複数）を実装する１つ以上の実行可能命令を含むモジュール、セグメントまたはコードの一部を表すこともできる。なお、さらに、いくつかの代わりの実装では、ブロック内に示されている機能が、図面に示されているのとは異なる順序で生じてもよい。例えば、関連する機能性次第で、連続して示されている２つのブロックが実際には事実上同時に実行されてもよく、または各ブロックが逆順で実行されることがあってもよい。なお、さらに、ブロック図もしくはフローチャート図またはその両方の各ブロック、およびブロック図もしくはフローチャート図またはその両方の複数ブロックの組み合わせは、指定の機能もしくは動作を実行する専用ハードウェア・ベース・システム、または専用ハードウェアおよびコンピュータ命令の組み合わせにより実装することができる。
【００６１】
本願明細書に記載された方法ステップは、例えば、本願明細書に記載されたように、当該ステップを実行するようプログラムされた汎用コンピュータ、または当該ステップを実行するハードウェアに関係し得る。さらに、例えばデータ・ストリームの取得およびストリームの符号化を含む、本願明細書に記載された方法ステップはさらに、データ・ストリームが取得されるカメラまたはマイクロホンなどの物理センサに関係してもよい。
【００６２】
なお、本願明細書に記載された方法はいずれも、コンピュータ可読ストレージ媒体上に具現化された別個のソフトウェア・モジュールを含むシステムを提供する追加のステップを含むことができる。その結果、方法ステップは、１つ以上のハードウェア・プロセッサ８０２上で実行されるシステムの別個のソフトウェア・モジュールもしくはサブ・モジュールまたはその両方を使用して、上記のように実行されることが可能である。場合によっては、本願明細書に記載された機能の１つ以上を実装するために、専用ハードウェアが用いられてもよい。さらに、コンピュータ・プログラム製品は、この別個のソフトウェア・モジュールを備えるシステムの提供を含め、本願明細書に記載された１つ以上の方法ステップを実行するために実装されるようになっているコードを備えるコンピュータ可読ストレージ媒体を含むことができる。
【００６３】
いずれにせよ、当然のことながら、本願明細書で示されたコンポーネントは、例えば、特定用途向け集積回路（ＡＳＩＣ：ａｐｐｌｉｃａｔｉｏｎ  ｓｐｅｃｉｆｉｃ  ｉｎｔｅｇｒａｔｅｄ  ｃｉｒｃｕｉｔ）、機能回路、関連したメモリを備え適切にプログラムされた１つ以上の汎用デジタル・コンピュータおよび同様のものなど、様々な形態のハードウェア、ソフトウェアまたはその組み合わせにおいて実装され得る。本願明細書で提供された本発明の教示を所与として、当業者は、本発明のコンポーネントの他の実装を考えることができるであろう。
【００６４】
本願明細書で使用される専門用語は、特定の実施形態について記載するためのものでしかなく、本発明の限定となることは目的としていない。本願明細書で使用される、単数形「ａ」、「ａｎ」および「ｔｈｅ」は、文脈によりそうでないことが明確に示されていない限り、複数形も含むものとする。さらに、当然のことながら、「含む」もしくは「含んでいる」またはその両方の用語は、本明細書で使用される場合、記載された特徴、完全体、ステップ、動作、要素もしくはコンポーネント、またはそのいずれかの組み合わせの存在を指定するが、１つ以上の他の特徴、完全体、ステップ、動作、要素、コンポーネントもしくはそのグループ、またはそのいずれかの組み合わせの存在または追加を除外するものではない。
【００６５】
以下の特許請求の範囲のミーンズまたはステップ・プラス・ファンクション構成要素すべての対応する構造、材料、動作および等価物は、明確に請求されている他の請求される構成要素とともに機能を実行する任意の構造、材料または動作を含むものとする。本発明の記載は、例示および説明のために示されたものであるが、包括的であることも、開示された形態の発明に限定されることも目的としていない。当業者には、本発明の範囲および意図から逸脱することのない、多数の変更および変形が明らかであろう。実施形態は、本発明の原理および実際の応用をもっともよく説明するよう、さらに当業者が、意図される特定の用途に適する様々な変更を用いた様々な実施形態に関して本発明を理解できるように選ばれ、記載された。
【図１】
2013524340.tif 000003
【図２】
2013524340.tif 000004
【図３】
2013524340.tif 000005
【図４】
2013524340.tif 000006
【図５】
2013524340.tif 000007
【図６】
2013524340.tif 000008
【図７】
2013524340.tif 000009
【図８】
2013524340.tif 000010
【国際調査報告】
2013524340.tif 000011