JP2014517950A

JP2014517950A - 改良した要求−能力定義によるリソース消費

Info

Publication number: JP2014517950A
Application number: JP2014504049A
Authority: JP
Inventors: パータサラシー，スリバッサン; サンヴィ，アシュビンクマール; フィニガン，ジェームズ; ヴィンバーグ，アンダース
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2011-04-06
Filing date: 2012-04-06
Publication date: 2014-07-24
Also published as: EP2695064A2; CN103460192A; WO2012139061A2; US20120260259A1; WO2012139061A3; EP2695064A4; KR20140010428A

Abstract

リソースの消費および割り当てに、改良した要求−能力定義を採用する。業務要求は、ホストされるコンテンツに関して指定することができ、業務要求およびリソース能力に基づいて、そのコンテンツにリソースを割り当てるか否か、そしてどのように割り当てるかについて判断を行うことができる。また、リソース能力についての情報を提供しつつも、基礎となるリソースの詳細を隠すために、能力プロファイルも使用することができる。
【選択図】図１

Description

従来技術

[0001] 仮想マシン技術は、とりわけ、物理リソースの利用拡大、および機敏なマシン(machine)のプロビジョニングを促進する。従前では、ソフトウェア・アプリケーションは、それが実行する物理サーバーに緊密に結び付けられていた。仮想マシン技術は、ソフトウェア・アプリケーション間および物理ハードウェア間に抽象層を設け、例えば、１つの物理サーバー（別名、ホスト）における複数の仮想マシンのプロビジョニングを可能にする。その結果、作業負荷を１つに纏めて物理資産利用を改善し、必要に応じて、マシンを迅速に配備し、そして使用を中止することができる。

[0002] 仮想マシン（ＶＭ）は、とりわけ、仮想ハード・ディスク（ＶＨＤ）を利用して物理コンピューターをエミュレートする１つのソフトウェアである。ＶＨＤは、仮想マシンのための物理ハード・ディスク類似品である。したがって、ＶＨＤは、ファイルおよびフォルダーのような、データーおよび構造エレメントに対して同様の表現を含むことができる。オペレーティング・システム（ＯＳ）（別名、ゲスト・オペレーティング・システム）をＶＨＤにインストールすることができる。更に、１つ以上のアプリケーションをＶＨＤにインストールすることができ、ＯＳはこれら１つ以上のアプリケーションの実行を、仮想マシンに対してサポートすることができる。

[0003] ホスト・マシンにＶＭを置くには、他のＶＭからの競合を考えて、そのＶＭにリソースを割り当てなければならない。配置(placement)の主要な目標は、動作するために必須のリソースをＶＭに確実に設けることである。一実現例では、スロット割り当て(slot allocation)、つまり、ＶＭが消費するリソースの平均量を決定し、ホスト容量を分割して、固定数のスロットを決定する。次いで、各ＶＭを、実際のリソース使用には関係なく、１つのスロットに置く。あるいは、一層計算集約的な手法を採用することができ、実際のリソース要求量をＶＭに供給し、配置のために使用する。このような表球は、複数の中央演算装置（ＣＰＵ）、ある量のメモリー、および接続の必要性（例えば、ネットワークＩ／Ｏ、記憶Ｉ／Ｏ）を含む。取得されたリソース要求量は、その後、必要なハードウェア・リソースを自動的に割り当てるために使用される。

[0004] 以下に、開示する主題の形態の一部の基礎的な理解が得られるようにするために、簡略化した摘要を紹介する。この摘要は、広範な全体像ではない。これは、主要な／必須のエレメントを特定することも、特許請求する主題の範囲を明確に定めることも意図していない。その唯一の目的は、後に紹介する更に詳細な説明の序説として、一部の概念を簡略化した形態で紹介することである。

[0005] 端的に述べると、本開示は、概して、改良要求−能力定義(enhanced requirement-capability definition)によって計算リソースの消費および割り当てを容易にすることに関する。コンテンツには、上位／抽象業務要求(business requirement)を関連付けることができる。リソース割り当ては、このような業務要求およびリソース能力(resource capability)の関数として実行することができる。加えて、能力プロファイル(capability profile)を供給して、割り当てに先だって、業務要求の指定を補助し、その有効性判断を可能にすることができる。更に、業務要求を、プロバイダーに依存しない請求(provider-independent claims)にマッピングすることができる。

[0006] 以上の目的および関連する目的の遂行のために、本明細書では以下の説明および添付図面と関連付けて、特許請求する主題のある種の例示的な形態について説明する。これらの形態は、主題を実施することができる種々の方法を示し、その全てが、特許請求する主題の範囲内に該当することと意図している。他の利点および新規な特徴も、以下の詳細な説明を図面と関連付けて検討することによって明白になるであろう。

図１は、リソース消費および割り当てを容易にするシステムのブロック図である。図２は、１つ以上の能力プロファイルを含む、リソース消費および割り当てを容易にするシステムのブロック図である。図３は、請求を採用する、リソース消費および割り当てを容易にするシステムのブロック図である。図４は、リソース割り当て方法のフロー・チャート図である。図５は、リソース消費方法のフロー・チャートである。図６は、本開示の形態に適した動作環境を示す模式ブロック図である。

[0013] 以下の詳細は、総じて、改良要求および能力定義に基づくリソース消費および割り当てを対象とする。従来、消費および割り当ては、中央演算装置の数、メモリー量、およびネットワーク入力／出力を含む、ハードウェア要求および能力の下位表現に基づいていた。ここでは、要求および能力の定義を拡大して、業務要求のような、もっと高いレベル／抽象概念でリソースの消費および割り当てを管理することを可能にする。とりわけ、このような技術は、ハードウェア購入モデルから遠ざかり消費モデルに向かう移動を可能にする。それを促進するために、能力プロファイルも採用して、基礎にあるリソースの詳細を隠しつつもリソース能力についての情報を提供することができる。加えて、要求(requirement)を請求(claim)として取り込み、プロバイダーとは関係なく、言い換えると、例えば、特定の管理エンティティおよび／またはサポートするインフラストラクチャーとは関係なく、リソースを割り当てること、および割り当て直すことを可能にすることができる。

[0014] これより本開示の種々の形態について、添付図面を参照しながら更に詳細に説明する。図面では、同様の番号は全体にわたって同様のまたは対応するエレメントを指す。しかしながら、図面およびそれに関する詳細な説明は、特許請求する主題を、開示される特定の形態に限定することを意図するのではないことは言うまでもない。逆に、その意図は、特許請求する主題の主旨および範囲に該当する全ての変更、均等、および代替を包含することである。

[0015] 最初に図１を参照すると、リソース消費および割り当てを容易にするシステム１００が示されている。システム１００は、垂直線によって２つの別々の側、即ち、コンシューマー１１０と通信可能に結合されているプロバイダー１２０とに分割されている。コンシューマー１１０は、外部ホスティングのためにコンテンツ１３０を供給する。プロバイダー１２０は、コンテンツ１３０をホストするために使用することができる複数の計算リソース１５０（別名、リソース１５０）（例えば、物理および仮想コンピューター・システム・コンポーネント）を管理する。一実施形態によれば、プロバイダー１２０はホスティング・サービスに対応することができ、コンシューマー１１０はホスティング・サービスを使用することを望むエンティティ（例えば、個人、組織．．．）に対応することができる。勿論、コンシューマー１１０がホスティング・サービスに対応して、とりわけ、サービスをホストする他のプロバイダー１２０から追加のリソースを求めることもできる。

[0016] コンシューマー１１０によって供給されたコンテンツ１３は、とりわけ、データー、コンピューター・プログラム、またはサービスを含むことができる。一例として、そして限定ではなく、コンテンツ１３０は、仮想マシン（ＶＭ）（仮想化ホストをシークする）、データーベース管理システム（サーバー・ホストをシークする）、またはウェブ・サイト（ウェブ・サーバー・ホストを望む）とすることができる。更に、コンテンツ１３０は、１組の１つ以上の要求(requirement)１３２を含むことができ、言い換えると、プログラマーまたはアドミニストレーターのようなコンシューマー・エンティティによって供給される業務要求を含むことができる。この業務要求は、ホスティング(hosting)に関して含有および／または除外制約を指定する。従来の制約とは異なり、要求１３２は、特定のハードウェア・インフラストラクチャーの低レベルの詳細（例えば、ＣＰＵの数、メモリー量．．．）に関するのではなく、上位において所望のリソースの必要性(need)に関する詳細を指定することを可能にする。別の言い方をすると、要求１３２は、基礎となるハードウェアの具体的細目を扱わない抽象的要求であることができる。

[0017] 一例として、要求１３２は、とりわけ、接続性(connectivity)、分離、消費レベル、または障害範囲(fault domain)に関する上位／抽象的制約を指定することができる。接続性要求は、例えば、２つ以上のアプリケーションが１つのネットワークを介して通信するか否かというような、接続性の関係に関連することができる。分離要求は、物理システムに関する、ホストされたコンテンツの別離(separation)または分離(isolation)に関係する。例えば、分離要求は、コンテンツ１３０を競合のコンテンツとは異なる物理ハードウェアに格納することを指定することができる。更に、コンテンツの一部を、他の部分から分離し、例えば、誤りの復元を容易にすることもできる。消費は、リソース消費の容認可能なレベルに関係することができる。リソース１５０は容易にスケーリングすることができるので、コンテンツ１３０が設定されたリソース量を消費するように制約を設けることができる。障害範囲は、利用可能性に関する。例えば、「Ｎ」個よりも多いサーバーまたはラック・ルータが、種々のイベントのために一度に故障する。この概念は、共有インフラストラクチャー、または地理(geographies)にも拡大することができる。特定のセキュリティ・レベルまたはファイアウオールに対するサポートを、とりわけ、含む複数の他の要求例１３２がある。

[0018] 更に、要求１３２は、リソース・スタックの種々のレイヤー、または階層(tier)を対象にすることができる。物理記憶メカニズム（例えば、フラッシュ）の上に、例えば、種々のホスト・サーバーがある。計算ファブリック(compute fabric)は、ホスト・サーバーの上に存在することができ、これらのホスト・サーバーを含む計算リソースの集合体を構成する。更に、次のレイヤーは、私有クラウドのような、計算ファブリック上の抽象であることができる。同様に、複数の私有クラウドおよび公開クラウドがあることができ、例えば、プロバイダー・インフラストラクチャー、またはリソース・スタックの一部をなす。スタックの詳細には関係なく、要求１３２を１つ以上のレイヤーに関して指定することができる。例えば、要求は、リソースを特定のクラウドまたはファブリックに配置することを指定することができる。

[0019] 更にまた、要求１３２は階層的であることができる。したがって、要求１３２は、例えば、他の特定のコンシューマーと共有されていないクラウドにリソースを配置し、このクラウドを含む計算ファブリックを特定の地理的エリア（例えば、米国）に配置し、そして使用される基礎となるストレージをフラッシュにすることを指定することができる。一実施形態では、このような階層的要求は、例えば、拡張可能マークアップ言語（ＸＭＬ）等における、名称値対(name-value pairs)のレイヤーとして指定することができる。勿論、当業者には認められようが、種々の他のフォーマットも採用することができる。

[0020] そして更にまた、要求１３２はハード要求またはソフト要求とすることもできる。ハード要求とは、満足しなければならない要求である。対照的に、ソフト表球は、要求が満たされるとよいことを意味する。ハード要求に違反すると、例えば、障害が広がる(deploy)結果となる可能性がある。ソフト要件の違反は、その結果警告が出される可能性がある。言い換えると、ソフト要求はハード要求よりも厳格でなく柔軟である。

[0021] また、要求は、値の要求または範囲の要求のいずれかにすることができる。値の要求とは、特定の値（例えば、ＣＰＵの数）によって満たされる要求である。範囲の要求は、ある範囲の状況が要求を満たすことを可能にする。例えば、ホスト記憶容量が、厳格な数値ではなく、ある範囲内に入ることを要求することができる。ハードおよびソフト要求と同様、値の要求の方が範囲の要求よりも厳格である。

[0022] 追加の要求がプロバイダー１２０に対して存在することができる。更に具体的には、コンシューマーとプロバイダーとの間におけるサービス・レベル同意１６０が、プロバイダー要求１６２を供給することができる。例えば、サービス・レベル同意（ＳＬＡ）１６０、およびサービス・レベル要求１６０の条件を取り込む(capture)関連要求１６２が、限定ではなく、特定のリソースの使用または除外、および／またはリソースの範囲（例えば、リソース・キャップ(resource cap)）というような種々の要求または制約を指定することができる。言い換えると、プロバイダー要求１６２は、特定のコンシューマーまたは組織に対して許容可能な１組のリソースを定めることができ、コンシューマー要求１３２は更にその１組内においてリソースを制限することができる。

[0023] また、プロバイダー１２０はリソース割り当てコンポーネント１４０も含む。リソース割り当てコンポーネント１４０は、コンシューマー要求１３２、プロバイダー要求１６２、およびリソース１５０の能力１５２の関数として、コンテンツ１３０にリソース１５０を割り当てるように構成されている。更に特定すると、リソース割り当てコンポーネント１４０は、コンシューマー要求１３２およびプロバイダー要求１６２を能力１５２と比較することができる。ここで、能力１５２は現在利用可能でありサポートされているリソースを特定する（例えば、現在利用されているリソースに関する利用可能な容量）。１組の要求全体を能力１５２によって満たすことができる場合、リソース割り当てコンポーネント１４０はリソース１５０をコンテンツ１３０に割り当てることができる。続いて、例えば、リソース１５０によってコンテンツ１３０をホストすることができる。一方、１組の要求全体を、能力に基づいて満たすことができない場合、リソース割り当てコンポーネント１４０はリソースの要求を拒絶することができる。

[0024] 注意を図２に移すと、リソースの消費および和割り当てを容易にするシステム２００が示されている。図１のシステム１００と同様に、システム２００は、コンテンツ１３０および関連する要求１３２を含むコンシューマー１１０と、サービス・レベル同意１６０、関連する要求１６２、リソース割り当てコンポーネント１４０、ならびにリソース１５０および能力１５２を含むプロバイダー１２０とを含む。端的に言うと、リソース割り当てコンポーネント１４０は、コンシューマー要求１３２、プロバイダー要求１６２、および利用可能な能力１５２の関数としてリソースをコンテンツ１３０に提供することができる。加えて、システム２００は１つ以上の能力プロファイル２１０も含む。

[0025] １つ以上の能力プロファイル２１０は、コンシューマー１１０が使用することを許可されている能力の組を特定する。一般に、プロバイダー１２０にとって、基礎となるリソース１５０の細目をコンシューマーに露出することは、インフラストラクチャーを容易に変更させることを含む多数の理由のために望ましくないと思われる。しかしながら、リソース１５０によって何が可能とされるのかについての指示をコンシューマー１１０に与えるのは、望ましいことでもある。実際、コンシューマー１１０とプロバイダー１２０との間て取り決められるサービス・レベル同意に基づいて、異なる割当量を設定することができる。１つ以上の能力プロファイル２１０は、プロバイダー１２０の基礎となるリソース１５０、またはインフラストラクチャーーに関する詳細を暴露することなく、サポートされている機能についての情報を提供する。更に特定すると、１つ以上の能力プロファイル２１０は、具体的な構成を提示し、これに対して、コンシューマー要求１３２を指定することができる。例えば、能力プロファイルは、とりわけ、ＣＰＵの範囲を特定することができ、更に可用性が高い仮想マシンが利用可能か否か特定することができる。コンシューマーは、これら特定の構成から選択することができ、またはこの範囲内の任意の数のＣＰＵを選択し、可用性の高いＶＭを使用することができ、またはそうしないことができる。本質的に、個人は特性のリストを見渡し(go down)、コンテンツ１３０が使用する能力を要求１３２として提示することができる。

[0026] 更に、コンテンツ１３０に関連する１３２は、能力プロファイルに対してその有効性を判断することができる。更に具体的には、コンシューマー有効性判断コンポーネント２２０は、リンクされているまたはそれ以外で関連付けられている能力プロファイルに対して、要求１３２の有効性を判断するように構成することができる。コンシューマー有効性判断コンポーネント２２０が、要求１３２が有効であると判断した場合、または言い換えると、リンクされている能力プロファイルと矛盾がないと判断した場合、プロバイダー１２０が必要なリソースを供給する高い信頼度で、リソースの要求を行うことができる。しかしながら、コンシューマー有効性判断コンポーネント２２０が、リンクされている能力プロファイルを考慮して、要求１３２が無効であると判断した場合、例えば、要求１３２の変更を可能にするために、そのことを示すメッセージを与えることができる。

[0027] プロバイダー有効性判断コンポーネント２３０は、プロバイダー１２０のためであることを除いて、コンシューマー有効性判断コンポーネント２２０と同じ機能を実行するように構成することができる。プロバイダー有効性判断コンポーネント２３０は、したがって、無効な要求に対して、有効性判断のもう１つのレイヤーを設けることができ、またはコンシューマー有効性判断コンポーネント２２０に置き換わることができる。加えてまたは代わりに、プロバイダー有効性判断コンポーネント２３０は、リソース割り当てコンポーネント１４０の処理に先立って、特定のコンテンツに対応する能力プロファイルに対して、プロバイダー側の業務要求１６２の有効性を判断することができる。

[0028] 図３は、リソースの消費および割り当てを容易にするシステム３００を示す。図２および図３のシステム１００および２００に関してそれぞれ先に説明した機能に加えて、システム３００は、コンシューマー・マップ・コンポーネント３２０およびプロバイダー・マップ・コンポーネント３５０を含む。コンシューマー・マップ・コンポーネント３２０は、コンシューマー要求１３２をプロバイダー不依存請求３３０にマッピングするように構成されている。同様に、プロバイダー・マップ・コンポーネント３５０は、プロバイダー要求１６２を請求３６０にマッピングするように構成されている。請求は、制限を表現する、プロバイダーに依存しないやり方、または標準的なやり方である。例えば、種々のコンシューマーおよびプロバイダーが異なる会社、組織等から一緒に来るというシナリオを考える。少なくともインフラストラクチャーの詳細および相互作用する様式に関して、プロバイダーの違いに縛られる。何らかの標準がないと、プロバイダーおよび関連するインフラストラクチャーを跨ぐ有効な通信は、不可能でないにしても、困難である。その促進のために、マップ・コンポーネントは、制限を特定の標準的方式および／または１組のタグ（例えば、コンテンツ・メタデーター・タグ）にマッピングするように構成することができる。

[0029] プロバイダー１２０のリソース割り当てコンポーネント１４０は、特定のコンテンツに関連する請求を抽出し、この請求をリソース１５０に関する制約として精度高く解釈することができる。一形態によれば、能力は、例えば、タグを含む同様の請求フォーマットで表現し、要求および能力の一致を容易にすることができる。あるいは、リソース割り当てコンポーネント１４０は、例えば、サブコンポーネント（図示せず）を介して、請求をローカルに理解可能なフォーマットに変換することができる。実現例の詳細には関係なく、特定のコンテンツに関連する制限を、異なるプロバイダー、インフラストラクチャー、業務、組織等の間で伝達し理解することができる。

[0030] 更に、タグ付け(tagging)または機能的に等価な方式が、構造および関係の理解を助け、最終的にリソースの割り当てを改善することができる。例えば、機密データーを含まないが、機密データーを含む他のコンテンツと相互作用するコンテンツについて考える。コンテンツにしかるべきタグが付けられている場合、リソース割り当てコンポーネント１４０は、機密データーを保護するメカニズムが採用されているはずであると判断または推論することができる。

[0031] 前述のシステム、アーキテクチャー、環境等は、様々なコンポーネント間における相互作用に関して説明した。このようなシステムおよびコンポーネントは、本明細書において指定したコンポーネントまたはサブコンポーネント、これら指定したコンポーネントまたはサブコンポーネントの一部、および／または追加のコンポーネントを含むことができることは認められてしかるべきである。また、サブコンポーネントは、親コンポーネント内に含まれるのではなく、他のコンポーネントに通信可能に結合されたコンポーネントとして実現することもできる。更にまた、１つ以上のコンポーネントおよび／またはサブコンポーネントを組み合わせて１つのコンポーネントにして、複合機能を設けることもできる。システム、コンポーネント、および／またはサブコンポーネント間の通信は、プッシュ・モデルおよび／またはプル・モデルのいずれかにしたがって遂行することができる。また、コンポーネントは、簡潔さのために本明細書において特定的に説明しなかったが当業者には知られている１つ以上の他のコンポーネントと相互作用することもできる。

[0032] 更に、以上で開示したシステムおよび以下の方法の種々の部分は、人工知能、マシン・ラーニング、あるいは知識または規則ベースのコンポーネント、サブコンポーネント、プロセス、手段、方法、またはメカニズム（例えば、サポート・ベクター・マシン(support vector machine)、ニューラル・ネットワーク、エキスパート・システム、ベイズの信念ネットワーク、ファジー論理、データー・フュージョン・エンジン(data fusion engine)、クラシファイヤー(classifier)．．．）を含むこと、または構成することができる。このようなコンポーネントは、とりわけ、それらによって実行するある種のメカニズムまたはプロセスを自動化して、システムおよび方法の一部を一層適応的に、そして効率的でインテリジェントにすることができる。一例としてそして限定ではなく、リソース割り当てコンポーネント１４０は、このようなメカニズムを採用して、不完全な情報から、特定のコンテンツおよび関連する要求をサポートするためにリソースを割り当てることができるか否か、そしてどのリソースを割り当てるか推論することができる。

[0033] 以上で説明したシステム例に関して、開示する主題にしたがって実現することができる方法は、図４および図５のフロー・チャートを参照すると一層良く認められよう。簡素さおよび説明の目的に限って、一連のブロックとして方法を示し説明するが、特許請求する主題は、これらのブロックの順序に限定されないことは言うまでもないことであり、認められよう。何故なら、一部のブロックは異なる順序で現れること、および／または本明細書において図示および説明するもの以外の他のブロックと同時に現れてもよいからである。更に、図示するブロックの全てが、以下で説明する方法を実現するために必要とされない場合もある。

[0034] 図４を参照すると、リソース割り当て方法４００が示されている。参照番号４１０において、１つ以上の上位要求、または業務要求を取得する。例えば、ノード間における特定の接続性を指定する抽象要求を受けることができる。番号４２０において、現在利用可能なインフラストラクチャーに対応するリソース能力を取得する。参照番号４３０において、リソース能力が１つ以上の要求を満たすことができるか否か判定を行う。できない場合（「ＮＯ」）、方法４００は不成功に終わり、単純に終了することができる。一方、能力が１つ以上の要求を満たすことができる場合（「ＹＥＳ」）、方法４００は番号４４０に進み、要求に関連するコンテンツにリソースを割り当てる。

[0035] 一実施形態によれば、要求および能力を請求として表すことができる。この場合、請求はプロバイダーには依存しない。言い換えると、請求は特定のプロバイダーの基礎となるハードウェアの詳細を取り除くだけでなく、プロバイダー（例えば、管理エンティティ、ベンダー．．．）および関連するインフラストラクチャー間の差も取り除く。その結果、統合リソース・モデルが容易にできる。それ以外では、方法４００は同様に動作することができる。例えば、コンテンツおよびリソースに関連する請求を比較して、コンテンツをホストすることに成功できるリソースが利用可能か否か判断することができる。そうである場合、リソースを割り当て、そうでない場合、リソースを割り当てない。

[0036] 図５は、リソース消費方法５００のフロー・チャート図である。参照番号５１０において、１つ以上の業務要求について、例えば、関連する能力プロファイルに対して有効性を判断することができる。言い換えると、１つ以上の業務要求がプロファイルにおいて提供される１組の能力によってサポートされること、またはそれと矛盾がないことを判断することができる。番号５２０において、有効性を判断された業務要求（１つまたは複数）を、インフラストラクチャーに依存しない請求（１つまたは複数）にマッピングする。番号４３０において、この請求（１つまたは複数）と共に、コンテンツをホストする要求を、リソース・プロバイダーに送る。その後、プロバイダー／ホスト・リソース（図示せず）によって請求を満たすことができる場合、コンテンツをホストすることができる。

[0037] 本明細書において使用する場合、「コンポーネント」および「システム」という用語、ならびにその形態(form)は、ハードウェア、ハードウェアおよびソフトウェアの組み合わせ、ソフトウェア、実行中のソフトウェアのいずれかであるコンピューター関連エンティティを指すことを意図している。例えば、コンポーネントは、プロセッサーにおいて実行するプロセス、プロセッサー、オブジェクト、インスタンス、エクゼキュータブル、実行のスレッド、プログラム、および／またはコンピューターであってもよいが、これらに限定されるのではない。一例として、コンピューターにおいて実行するアプリケーションおよびそのコンピューターは双方とも、コンポーネントであることができる。１つ以上のコンポーネントが１つのプロセス内部に存在することもでき、および／または実行のスレッドおよびコンポーネントを１つのコンピューターに配置すること、および／または２つ以上のコンピューター間で分散することもできる。

[0038] 「一例の」という単語またはその種々の形態は、本明細書では、一例(example)、実例(instance)、または例示(illustration)としての役割を果たすことを意味するために使用されている。本明細書において「一例」として記載される形態または設計はいずれも、他の形態または設計よりも好ましいとも有利であるとも、必ずしも解釈されるのではない。更に、例は明確さおよび理解の目的に限って示されるのであり、特許請求する主題や本開示の関連部分を限定または制限することは全く意味しない。尚、様々な範囲の無数の追加の例または代わりの例も提示することはできたが、簡潔さの目的のために省略したことは認められてしかるべきである。

[0039] 本明細書において使用する場合、「推論」または「推論する」という用語は、一般に、システム、環境、および／またはユーザーの状態を、イベントおよび／またはデーターを介して取り込んだ１組の観察から推測(reasoning)または推論するプロセスを指す。推論は、特定のコンテキストまたは動作を識別するために使用することができ、あるいは、例えば、状態に対して確率分布を生成することができる。推論は確率論的であることができる。即ち、対象となる状態に対する確率分布の計算は、データーおよびイベントの考慮に基づく。また、推論は、１組のイベントおよび／またはデーターからより高いレベルのイベントを構成するために使用する技法を指すこともできる。このような推論の結果、イベントが時間的に密接に相関付けられているか否かに関係なく、そしてイベントおよびデーターが１つのイベントおよびデーター・ソースから来たのかまたは複数のイベントおよびデーター・ソースから来たのかには関係なく、１組の観察されたイベントおよび／または格納されたデーターから、新たなイベントまたは動作の構築が行われる。種々の分類方式および／またはシステム（例えば、サポート・ベクトル・マシン、ニューラル・ネットワーク、エキスパート・システム、ベイズの信念ネットワーク、ファジー論理、データー・フュージョン・エンジン．．．）を、特許請求する主題と関連する自動動作および／または推論動作の実行に加えて採用することができる。

[0040] 更に、「含む」(includes)、「含む」(contains)、「有する」(has) 、「有している」(having)という用語、またはその異形が詳細な説明または特許請求の範囲において用いられている限りにおいて、このような単語は、「含む」(comprising)という用語が請求項において移行性単語として採用されるときに「含む」(comprising)を解釈するのと同様に、内包的であることを意図している。

[0041] 特許請求する主題についての背景を示すために、図６および以下の説明は、本主題の種々の形態を実現することができる適した環境の端的で総合的な説明を行うことを意図している。しかしながら、この適した環境は一例に過ぎず、使用範囲や機能に関して何の限定も示唆することは意図していない。

[0042] 以上で説明したシステムおよび方法は、１つ以上のコンピューターにおいて実行するプログラムのコンピューター実行可能命令という一般的なコンテキストで説明することができるが、他のプログラム・モジュール等と組み合わせて形態を実現することもできることは、当業者には認められよう。一般に、プログラム・モジュールは、とりわけ、ルーチン、プログラム、オブジェクト、コンポーネント、特定のタスクを実行するおよび／または特定の抽象データー・タイプを実装するデーター構造を含む。更に、以上のシステムおよび方法は、種々のコンピューター・システム構成で実施できることも、当業者には認められよう。そのコンピューター・システム構成には、単一プロセッサー、マルチプロセッサーまたはマルチコア・プロセッサー・コンピューター・システム、マルチ計算デバイス、メインフレーム・コンピューター、更にはパーソナル・コンピューター、ハンドヘルド計算デバイス（例えば、パーソナル・ディジタル・アシスタント（ＰＤＡ）、電話機、腕時計．．．）、マイクロプロセッサー・ベースのあるいはプログラマブルなコンシューマー用または工業用電子機器等が含まれる。また、形態は分散型計算環境でも実施することができ、その場合、通信ネットワークを介してリンクされている遠隔処理デバイスによって、タスクが実行される。しかしながら、特許請求する主題の形態は、全てではないにしろその一部は、スタンド・アロン・コンピューターにおいて実施することができる。分散型計算環境では、プログラム・モジュールは、ローカルおよびリモート・メモリー記憶デバイスの内一方または双方に配置することができる。

[0043] 図６を参照すると、汎用コンピューターまたは計算デバイスの一例６１０（例えば、デスクトップ、ラップトップ、サーバー、ハンドヘルド、プログラマブルなコンシューマー用または工業用電子機器、セット・トップ・ボックス、ゲーム・システム．．．）が示されている。コンピューター６１０は、１つ以上のプロセッサー６２０、メモリー６３０、システム・バス６４０、大容量ストレージ６５０、および１つ以上のインターフェース・コンポーネント６７０を含む。システム・バス６４０は、少なくとも以上のシステム・コンポーネントを通信可能に結合する。しかしながら、コンピューター６１０は、その最も簡素な形態では、メモリー６３０に結合された１つ以上のプロセッサー６２０を含むことができ、このプロセッサー６２０が、メモリー６３０に格納されている種々のコンピューター実行可能動作、命令、および／またはコンポーネントを実行することは認められてしかるべきである。

[0044] プロセッサー（１つまたは複数）６２０は、汎用プロセッサー、ディジタル信号プロセッサー（ＤＳＰ）、特定用途集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（ＦＧＰＡ）または他のプログラマブル論理デバイス、ディスクリート・ゲートまたはトランジスタ・ロジック、ディスクリート・ハードウェア・コンポーネント、あるいは本明細書において記載した機能を実行するように設計されたその任意の組み合わせによって実現することができる。汎用プロセッサーは、マイクロプロセッサーとすればよいが、代わりに、プロセッサーは任意のプロセッサー、コントローラ、マイクロコントローラ、または状態機械であってもよい。また、プロセッサー（１つまたは複数）６２０は、計算デバイスの組み合わせ、例えば、ＤＳＰとマイクロプロセッサーとの組み合わせ、複数のマイクロプロセッサー、マルチコア・プロセッサー、ＤＳＰコアと結び付けた１つ以上のマイクロプロセッサー、または任意の他のこのような構成として実現することもできる。

[0045] コンピューター６１０は、種々のコンピューター読み取り可能媒体を含む、またはこれらと相互作用して、特許請求する主題の１つ以上の形態を実現するためにコンピューター６１０の制御をし易くすることができる。コンピューター読み取り可能媒体は、コンピューター６１０によってアクセスすることができる入手可能な媒体であればいずれでも可能であり、揮発性および不揮発性媒体、ならびにリムーバブルおよび非リムーバブル媒体を含む。一例として、そして限定ではなく、コンピューター読み取り可能媒体は、コンピューター記憶媒体および通信媒体を含むことができる。

[0046] コンピューター記憶媒体は、揮発性および不揮発性、リムーバブルおよび非リムーバブル媒体を含み、コンピューター読み取り可能命令、データー構造、プログラム・モジュール、または他のデーターというような情報の格納のために、任意の方法または技術で実現される。コンピューター記憶媒体は、限定ではなく、メモリー・デバイス（例えば、ランダム・アクセス・メモリー（ＲＡＭ）、リード・オンリー・メモリー（ＲＯＭ）、電気的消去可能プログラマブル・リード・オンリー・メモリー（ＥＥＰＲＯＭ）．．．）、磁気記憶デバイス（例えば、ハード・ディスク、フロッピ・ディスク、カセット、テープ、．．．）、光ディスク（例えば、コンパクト・ディスク（ＣＤ）、ディジタル・バーサタイル・ディスク（ＤＶＤ）．．．）、およびソリッド・ステート・デバイス（例えば、ソリッド・ステート・ドライブ（ＳＳＤ）、フラッシュ・メモリー・デバイス（例えば、カード、スティック、キー・ドライブ．．．）．．．）、または所望の情報を格納するために使用することができコンピューター６１０によってアクセスすることができる任意の他の媒体を含む。

[0047] 通信媒体は、通例、コンピューター読み取り可能命令、データー構造、プログラム・モジュール、または他のデーターを、搬送波のような変調データー信号または他の伝達メカニズム内に具体化し、任意の情報配信媒体を含む。「変調データー信号」という用語は、その特性の１つ以上が、当該信号内部に情報をエンコードするようなやり方で設定または変化させられている信号を意味する。一例として、そして限定ではなく、通信媒体は、有線ネットワークまたは直接有線接続のような有線媒体と、音響、ＲＦ、赤外線、およびその他のワイヤレス媒体というようなワイヤレス媒体とを含む。以上の内いずれの組み合わせも、コンピューター読み取り可能媒体の範囲に含まれる。

[0048] メモリー６３０および大容量ストレージ６５０は、コンピューター読み取り可能記憶媒体の例である。計算デバイスの正確な構成およびタイプに依存して、メモリー６３０は、揮発性（例えば、ＲＡＭ）、不揮発性（例えば、ＲＯＭ、フラッシュ・メモリー．．．）、またはこれら２つの何らかの組み合わせとすることができる。一例として、基本入力／出力システム（ＢＩＯＳ）は、起動中等において、コンピューター６１０内部におけるエレメント間で情報を伝えるための基本ルーチンを含み、不揮発性メモリーに格納することができる。一方、揮発性メモリーは、とりわけ、プロセッサー（１つまたは複数）６２０による処理を促進するために、外部キャッシュ・メモリーとして機能することができる。

[0049] 大容量ストレージ６５０は、リムーバブル／非リムーバブル、揮発性／不揮発性コンピューター記憶媒体を含み、メモリー６３０に対して相対的に大量のデーターを格納する。例えば、大容量ストレージ６５０は、磁気または光ディスク・ドライブ、フロッピー（登録商標）・ディスク・ドライブ、フラッシュ・メモリー、ソリッド・ステート・ドライブ、またはメモリー・スティックというような１つ以上のデバイスを含むが、これらに限定されるのではない。

[0050] メモリー６３０および大容量ストレージ６５０は、オペレーティング・システム６６０、１つ以上のアプリケーション６６２、１つ以上のプログラム・モジュール６６４、およびデーター６６６を含む、またはこれらをその内部に格納することができる。オペレーティング・システム６６０は、コンピューター６１０のリソースを制御し割り当てるように機能する。アプリケーション６６２は、システムおよびアプリケーション・ソフトウェアの一方または双方を含み、１つ以上の動作を実行するために、メモリー６３０および／または大容量ストレージ６５０に格納されているプログラム・モジュール６６４およびデーター６６６を使用して、オペレーティング・システム６６０によるリソースの管理を利用することができる。したがって、アプリケーション６６２は、それによって提供されるロジックにしたがって、汎用コンピューター６１０を特殊装置に変えることができる。

[0051] 特許請求する主題の全部または一部は、コンピューターを制御して開示した機能を実現するためのソフトウェア、ファームウェア、ハードウェア、またはその任意の組み合わせを生成する標準的なプログラミングおよび／または設計技法を使用して実現することができる。一例として、そして限定ではなく、リソース割り当てコンポーネント１４０、またはその一部は、アプリケーション６６２の一部を形成することができ、メモリーおよび／または大容量ストレージ６５０に格納されている１つ以上のモジュール６６４およびデーター６６６を含むことができる。その機能は、１つ以上のプロセッサー６２０によって実行されるときに、実現することができる。

[0052] 特定の一実施形態によれば、プロセッサー（１つまたは複数）６２０は、１つの集積回路基板上にハードウェアおよびソフトウェアの双方を含む、言い換えると、統合したチップ上システム（ＳＯＣ）または同様のアーキテクチャーに対応することができる。ここでは、プロセッサー（１つまたは複数）６２０は、とりわけ、プロセッサー（１つまたは複数）６２０と少なくとも同様な１つ以上のプロセッサー、およびメモリー６３０を含むことができる。従来のプロセッサーは、最少量のハードウェアおよびソフトウェアを含み、外部ハードウェアおよびソフトウェアに大きく頼っていた。対照的に、プロセッサーのＳＯＣ実現例は一層強力である。何故なら、外部ハードウェアおよびソフトウェアにはできるだけ頼らずまたは全く頼らずに、特定の機能を可能にするハードウェアおよびソフトウェアをその内部に埋め込んでいるからである。例えば、リソース割り当てコンポーネント１４０および／または関連する機能は、ＳＯＣアーキテクチャーにおけるハードウェア内に埋め込むことができる。

[0053] また、コンピューター６１０は、１つ以上のインターフェース・コンポーネント６７０も含む。インターフェース・コンポーネント６７０は、システム・バス６４０と通信可能に結合され、コンピューター６１０との相互作用を容易にする。一例として、インターフェース・コンポーネント６７０は、ポート（例えば、シリアル、パラレル、ＰＣＭＣＩＡ、ＵＳＢ、ＦｉｒｅＷｉｒｅ．．．）、またはインターフェース・カード（例えば、サウンド、音声．．．）等とすることができる。一実現例では、インターフェース・コンポーネント６７０は、ユーザー入力／出力インターフェースとして具体化することができ、ユーザーがコマンドおよび情報をコンピューター６１０に、１つ以上の入力デバイス（例えば、マウスのようなポインティング・デバイス、トラックボール、スタイラス、タッチ・パッド、キーボード、マイクロフォン、ジョイスティック、ゲーム・パッド、衛星ディッシュ、スキャナー、カメラ、他のコンピューター．．．）を介して入力することを可能にする。他の実現例では、インターフェース・コンポーネント６７０は、とりわけ、出力をディスプレイ（例えば、ＣＲＴ、ＬＣＤ、プラズマ．．．）、スピーカー、プリンター、および／または他のコンピューターに供給する出力周辺インターフェースとして具体化することができる。更にまた、インターフェース・コンポーネント６７０は、ネットワーク・インターフェースとして具体化することができ、有線またはワイヤレス通信リンクを介してというようにして、他の計算デバイス（図示せず）との通信を可能にする。

[0054] 以上で説明したことは、特許請求する主題の形態例を含む。勿論、特許請求する主題について説明する目的で、コンポーネントまたは方法の着想可能なあらゆる組み合わせを記載することは不可能であるが、開示した主題には多くの他の組み合わせや並び替え(permutation)が可能であることは、当業者には認めることができよう。したがって、開示した主題は、添付した請求項の主旨および範囲に該当するこのような変形、変更、および異形を全て包含することを意図している。

Claims

リソース割り当て方法であって、
次の動作を実行するために、メモリーに格納されたコンピューター実行可能命令を実行するように構成された少なくとも１つのプロセッサーを使用するステップを含み、
前記次の動作が、前記コンテンツの１つ以上の業務要求および１つ以上の計算リソースの１つ以上の能力の関数として、コンテンツをホストするために前記１つ以上の計算リソースを割り当てることである、リソース割り当て方法。
請求項１記載の方法であって、コンシューマーとプロバイダーとの間におけるサービス・レベル同意（ＳＬＡ）の関数として、前記１つ以上の計算資源を割り当てるステップを含む、方法。
請求項１記載の方法であって、更に、１つ以上のプロバイダー不依存請求に関して指定される前記１つ以上の業務要求をコンシューマーから取得するステップを含む、方法。
請求項１記載の方法であって、更に、前記１つ以上の業務要求について、能力プロファイルに対して有効性を判断するステップを含む、方法。
請求項１記載の方法であって、更に、前記１つ以上のプロバイダー要求を１つ以上のプロバイダー不依存請求にマッピングするステップを含む、方法。
リソースの割り当てを容易にするシステムであって、
メモリーに結合されたプロセッサーであって、前記メモリーに格納された次のコンピューター実行可能コンポーネントを実行するように構成された、プロセッサーと、
１つ以上の業務要求と１つ以上のリソース能力との関数として、コンテンツをホストするためにリソースを割り当てるように構成された第１コンポーネントと、
を含む、システム。
請求項６記載のシステムにおいて、前記１つ以上の業務要求が、能力プロファイルと関連付けて指定される、システム。
請求項７記載のシステムであって、更に、前記１つ以上の業務要求について、前記能力プロファイルに対してその有効性を判断するように構成された第２コンポーネントを含む、システム。
請求項６記載のシステムにおいて、前記１つ以上の業務要求が、１つ以上のプロバイダー不依存請求にマッピングされる、システム。
請求項６記載のシステムにおいて、前記１つ以上の業務要求の内１つが、特定のリソース階層に関して指定される、システム。