JP2015534696A - クラウド内に地理的分散型のアプリケーションを自動的に配備する方法および装置 - Google Patents

Abstract

様々な例示の実施形態は、下記のこと、すなわち、要求するデバイスからアプリケーションの構成要素を確立する要求を受信すること、アプリケーションについて少なくとも１つのセグメントを定義し、この少なくとも１つのセグメントの第１のセグメントについて少なくとも１つの制約を定義する、アプリケーションに関連するポリシーファイルを識別すること、構成要素の確立について第１のセグメントを選択すること、少なくとも１つの制約に整合する位置であって、構成要素の確立についての位置を選択すること、および、この選択された位置で構成要素を確立すること、のうち１つまたは複数を含む方法および関連するネットワークノードに関する。

Description

本明細書において開示される様々な例示的実施形態は、一般に、クラウドコンピューティングに関する。

今日、クラウドオペレータの多くはいくつかの大規模なデータセンターを用いてクラウドサービスをホストし、比較的集中型のオペレーションを提供する。このようなシステムでは、要求側はクラウドコントローラに１つまたは複数のリソースの使用を要求することができ、そして次に、要求側によって使用するために、クラウドコントローラは要求されたリソースをデータセンターから割り当てることができる。しかしながら、この集中型のオペレーションは、たとえば厳格な遅延または信頼性の要求を有するような様々なタイプのアプリケーションをホストするには十分に適切でない場合がある。

一方、分散型データセンターのアーキテクチャは、地理的に分散され得る、多数のより小規模なデータセンターを設置する。これらのデータセンターは、インターネットまたはキャリアネットワークなどのネットワークを介して、１つまたは複数のクラウドコントローラの制御下にあってよい。このような分散型システムの下では、集中型クラウドが提供し得るよりも、地理的またはネットワーク距離の観点から様々な顧客により近いクラウドアプリケーションを提供することによって、ネットワーク伝搬遅延の影響は減少され得る。

様々な例示的実施形態の概要は、以下に示される。下記の概要においては、簡略化および省略されるものもあるが、これは様々な例示的実施形態のいくつかの態様を強調および紹介することを意図するものであって、本発明の範囲を限定するものではない。当業者が本発明の概念を構想および使用できるようにするのに適した好ましい例示的実施形態は、後節において詳述される。

本明細書において記述される様々な実施形態は、クラウド内にアプリケーションの構成要素を確立するクラウドコントローラによって実行される方法に関し、この方法は、要求するデバイスから構成要素を確立する要求を受信すること、アプリケーションについて少なくとも１つのセグメントを定義し、この少なくとも１つのセグメントの第１のセグメントについて少なくとも１つの制約を定義する、アプリケーションに関連するポリシーファイルを識別すること、構成要素の確立について第１のセグメントを選択すること、少なくとも１つの制約に整合する位置であって、構成要素の確立についての位置を選択すること、および、この選択された位置で構成要素を確立することを含む。

本明細書において記述される様々な実施形態は、クラウド内にアプリケーションの構成要素を確立するクラウドコントローラに関し、このクラウドコントローラは、データストレージと、このデータストレージと通信するプロセッサとを含み、このプロセッサは、要求するデバイスから構成要素を確立する要求を受信し、アプリケーションについて少なくとも１つのセグメントを定義し、かつ、この少なくとも１つのセグメントの第１のセグメントについて少なくとも１つの制約を定義するポリシーファイルであって、データストレージに格納されアプリケーションに関連するポリシーファイルを識別し、構成要素の確立について第１のセグメントを選択し、少なくとも１つの制約に整合する位置であって、構成要素の確立についての位置を選択し、および、この選択された位置で構成要素を確立するように構成される。

本明細書において記述される様々な実施形態は、クラウド内にアプリケーションの構成要素を確立するクラウドコントローラによって実行するための命令で符号化される、非一時的な機械可読記憶媒体に関し、この媒体は、要求するデバイスから構成要素を確立する要求を受信する命令と、アプリケーションについて少なくとも１つのセグメントを定義し、この少なくとも１つのセグメントの第１のセグメントについて少なくとも１つの制約を定義するポリシーファイルであって、アプリケーションに関連するポリシーファイルを識別する命令と、構成要素の確立について第１のセグメントを選択する命令と、少なくとも１つの制約に整合する位置であって、構成要素の確立についての位置を選択する命令と、この選択された位置で構成要素を確立する命令とを含む。

少なくとも１つの制約が、第１のセグメントに属する構成要素について制約を指定する個々のセグメント制約を含む、様々な実施形態が記述される。

少なくとも１つの制約が、第１のセグメントに属する少なくとも２つの構成要素間の制約を指定するセグメント内制約を含む、様々な実施形態が記述される。

少なくとも１つの制約が、第１のセグメントに属する少なくとも１つの構成要素と少なくとも１つのセグメントの第２のセグメントに属する少なくとも１つの構成要素の間の制約を指定するセグメント間制約を含む、様々な実施形態が記述される。

様々な実施形態は、要求するデバイスにラベルと共に構成要素の確立を通知すること、要求するデバイスからラベルを含むスケール要求を受信すること、第１のセグメントをラベルと関連するものとして識別すること、および第１のセグメントに対してスケーリングオペレーションを実行することをさらに含む。

様々な実施形態は、第１のセグメントを識別した後、ポリシーファイルから第１のセグメントについて少なくとも１つの制約を識別すること、および、少なくとも１つの制約に整合する位置であって、スケーリングオペレーションに関する位置を選択することをさらに含み、スケーリングオペレーションを実行することは、この選択された位置でスケーリングオペレーションを実行することを含む。

様々な実施形態は、要求するデバイスからアプリケーションについて追加の構成要素を確立する要求を受信すること、追加の構成要素の確立のために少なくともセグメントの第２のセグメントを選択すること、この第２のセグメント内における追加の構成要素の確立のための位置を選択すること、およびこの選択された位置で追加の構成要素を確立することをさらに含む。

第２のセグメントを選択することが、少なくともセグメントのポリシーファイルの定義および第１のセグメント内における構成要素の確立を反映するシステム状態情報に基づいて、追加の構成要素の確立のために第２のセグメントを選択することを含む、様々な実施形態が記述される。

本明細書において記述される様々な実施形態は、クラウド内にアプリケーションを確立するためのクラウドコントローラによって実行される方法に関し、この方法は、ユーザからアプリケーションについて複数の構成要素を定義するレシピファイルを受信すること、ユーザからアプリケーションについて複数のセグメントを定義するポリシーファイルを受信すること、および、複数のセグメントに従ってアプリケーションが分散されるように構成要素が確立される、クラウド内に複数の構成要素を確立することを含む。

本明細書において記述される様々な実施形態は、クラウド内にアプリケーションを確立するクラウドコントローラに関し、このクラウドコントローラは、データストレージと、このデータストレージと通信するプロセッサとを含み、このプロセッサは、ユーザからアプリケーションについて複数の構成要素を定義するレシピファイルを受信し、ユーザからアプリケーションについて複数のセグメントを定義するポリシーファイルを受信し、および、クラウド内に、複数のセグメントに従ってアプリケーションが分散されるよう確立される複数の構成要素を確立するように構成される。

本明細書において記述される様々な実施形態は、クラウド内にアプリケーションを確立するクラウドコントローラによって実行するための命令で符号化される、機械可読記憶媒体に関し、この媒体は、ユーザからアプリケーションについて複数の構成要素を定義するレシピファイルを受信するための命令と、ユーザからアプリケーションについて複数のセグメントを定義するポリシーファイルを受信するための命令と、複数のセグメントに従ってアプリケーションが分散されるように構成要素が確立される、クラウド内に複数の構成要素を確立する命令とを含む。

ポリシーファイルが複数のセグメントの第１のセグメントに対して少なくとも１つの制約をさらに定義し、複数のセグメントに従ってアプリケーションが分散されるように複数の構成要素を確立することが、第１のセグメントに第１の構成要素を割り当てること、および少なくとも１つの制約に整合する位置において第１の構成要素を確立することを含む、様々な実施形態が記述される。

少なくとも１つの制約が第１のセグメントに割り当てられた構成要素が確立される地理的地域を指定し、少なくとも１つの制約に整合する位置において第１の構成要素を確立することが、その地理的地域内に構成要素を確立することを含む、様々な実施形態が記述される。

少なくとも１つの制約が第１のセグメントに割り当てられた構成要素間のアフィニティを指定し、少なくとも１つの制約に整合する位置において第１の構成要素を確立することが、第１のセグメントに割り当てられた少なくとも１つの他の構成要素に近くなるように選択された位置で第１の構成要素を確立することを含む、様々な実施形態が記述される。

少なくとも１つの制約が、第１のセグメントと複数のセグメントの第２のセグメント間のアンチアフィニティを指定し、少なくとも１つの制約に整合する位置において第１の構成要素を確立することが、第２のセグメントに割り当てられた少なくとも１つの他の構成要素から遠くなるように選択された位置で第１の構成要素を確立することを含む、様々な実施形態が記述される。

ポリシーファイルが、複数の構成要素の第１の構成要素および複数のセグメントの第１のセグメントに関連する第１の割合と、第１の構成要素および複数のセグメントの第２のセグメントに関連する第２の割合とを指定する、様々な実施形態が記述される。

複数のセグメントに従ってアプリケーションが分散されるように複数の構成要素を確立することが、第１のセグメント内に第１の数の第１の構成要素を確立すること、および、第２のセグメント内に第２の数の第１の構成要素を確立することを含み、第１の数および第２の数が第１の割合および第２の割合に基づいて選択される、様々な実施形態が記述される。

様々な実施形態は、アプリケーションマネジャーにレシピファイルを転送すること、クラウドコントローラでポリシーファイルを格納すること、および、アプリケーションマネジャーから構成要素を確立する要求を受信することをさらに含み、複数の構成要素を確立することは、受信された要求および格納されたポリシーファイルに基づいて構成要素を確立することを含む。

様々な例示的実施形態をより理解するために、添付の図面を参照する。

クラウドリソースを提供する例示のネットワークを示す図である。 例示のセグメント化されたアプリケーションを示す図である。 例示のクラウドコントローラを示す図である。 クラウド内にアプリケーションを確立する例示の方法を示す図である。 クラウド内のアプリケーションをスケールする例示の方法を示す図である。

理解を容易にするため、実質的に同一もしくは類似の構造または実質的に同一もしくは類似の機能を備える要素を示すために、同じ参照番号が用いられている。

記述および図面は、本発明の原理を示す。したがって、当業者であれば、本明細書において明確に記述または図示されないものであっても、本発明の原理を実施し、本発明の範囲に含まれる様々な構成を案出できるであろうことが理解されよう。さらに、本明細書において説明されるすべての例は、主に、本発明の原理および当技術を促進させるために発明者（複数可）によって与えられた概念を読み手が理解するのを助ける教育上の目的のみであることが明確に意図され、また、このように特に説明される例および条件に限定されないものとして解釈される。加えて、本明細書において用いられる「または」という用語は、別段の指示（たとえば、「さもなければ」、または「または別法では」など）が無い限り非排他的な「または」を意味する。また、１つまたは複数の他の実施形態と組み合わされて新たな実施形態を形成する実施形態もあり得るため、本明細書において記述される様々な実施形態は必ずしも相互に排他的である必要はない。

様々な方法は、ユーザが分散型のクラウドアプリケーション用に配備されることになる構成要素を定義することを可能にし得るが、このような方法は、ユーザがどこに構成要素が確立されるかについて指定するか、そうでなければこれに影響を与えることをさらに可能にするものではない。このことから、ユーザは、顧客ベースの知識および他の情報に基づいてボトルネックを減少させるためにクラウドの分散型の特質を利用する権限を与えられることはできない。したがって、クラウドの中でアプリケーションがどのように分散されるかに対する影響力をユーザに与えつつ、分散型のクラウドアプリケーションを自動的に配備することができるシステムの必要性が存在する。

前述によると、本明細書において記述される様々な実施形態は、ユーザが、クラウドアプリケーションが分散される複数の「セグメント」を指定できるようにする。ユーザはまた、これらの各セグメントの構成要素が存在する地理的位置、および各セグメントに属するアプリケーションの構成要素を指定することができる。このように、アプリケーションの一部を形成する各構成要素が地理的にどこに配置されるかに対する影響力がユーザに与えられる。様々な、さらなる特徴および実施の詳細は、図に関連して、以下でより詳細に記述される。

図面を参照すると、同様の番号が同様の構成要素またはステップを意味し、様々な例示的実施形態の広範囲の態様が開示される。

図１は、クラウドリソースを提供する例示のクラウドアーキテクチャ１００を示す。このクラウドアーキテクチャ１００は、ネットワーク化されたクラウドアーキテクチャを実施することができ、クライアントデバイス１１０と、ネットワーク１１５と、クラウドコントローラ１２０と、データセンター１３０、１４０および１５０と、アプリケーションマネジャー１６０とを含んでよい。

クライアントデバイス１１０は、１つまたは複数のクラウドリソースを利用するように構成された任意のデバイスであってよい。様々な実施形態において、クライアントデバイス１１０は、デスクトップコンピュータ、ラップトップ、タブレット、モバイルデバイス、サーバまたはブレードであってよい。クライアントデバイス１１０は、ネットワーク１１５を介して、クラウドコントローラ１２０などの他のデバイスと通信することができる。クライアントデバイス１１０は、クラウドコントローラ１２０に１つまたは複数のクラウドリソースの要求を送信することができる。たとえば、クライアントデバイス１１０は、１つまたは複数の仮想マシン（ＶＭｓ）、一群の仮想マシン（ＶＭｓ）、ストレージデバイスまたはメモリの使用を要求することができる。クラウドリソースのさらなるタイプは明らかになるだろう。クライアントデバイス１１０は、分散型のクラウドアプリケーションの配備をクラウドコントローラ１２０に要求するユーザのデバイスを表すことができ、または、クライアントデバイス１１０は、リソース１３１、１３２、１３３、１４４、１５５、１６６と直接通信することによってこのような分散型のクラウドアプリケーションの１つまたは複数の構成要素の使用を要求するユーザのような顧客を表すことができる。複数の追加のクライアントデバイス（図示せず）がネットワーク１１５と通信することができ、また、このような追加のクライアントデバイスは追加のユーザおよび顧客に属してよいことは明らかであろう。

ネットワーク１１５は、例示のクラウドアーキテクチャ１００の様々なデバイス間での通信を可能にすることができるデバイスまたは伝送媒体の任意のネットワークであってよい。たとえば、ネットワーク１１５は、様々な宛先に対するデータパケットを交換およびルーティングするように構成された多数のデバイスを含んでよい。様々な実施形態において、ネットワーク１１５はインターネット、または１つまたは複数のキャリアネットワークを含んでよい。

クラウドコントローラ１２０は、ネットワーク化されたクラウドのオペレーションを制御するように構成されたデバイスであってよい。図３に関連してより詳細に後述されるように、クラウドコントローラ１２０は、ストレージデバイス、メモリ、または１つまたは複数のプロセッサなどの様々なハードウェアを含んでよい。本明細書において用いられる「プロセッサ」という用語は、マイクロプロセッサ、フィールドプログラマブルゲートアレイ（ＦＰＧＡｓ）、特定用途向け集積回路（ＡＳＩＣｓ）、および他の類似の処理デバイスなど様々なデバイスを包含することが理解されよう。様々な実施形態において、クラウドコントローラ１２０は、たとえば、サーバ、ブレード、パーソナルコンピュータ、ラップトップ、タブレットまたはモバイルデバイスを含んでよい。このようないくつかの実施形態では、クラウドコントローラ１２０は、たとえば、クラウドデバイス１３１、１３２、１３３によって提供されるハードウェアリソースなどのクラウドリソースを利用する仮想マシンであってよい。クラウドコントローラ１２０は、データセンター１３０のようなデータセンター、または他の場所に存在してよい。クラウドコントローラ１２０は、クラウドリソース割当の管理を含む様々なクラウド管理機能を実行することができる。このため、クラウドコントローラ１２０は、クライアントデバイス１１０のようなクライアントデバイスから、クラウドアプリケーションの確立の要求を受信することができる。このような要求を受信すると、クライアントデバイスによって使用するために、クラウドコントローラ１２０は、クラウドデバイス１３１、１３２、１３３、１４４、１５５、１５６の１つまたは複数から要求されたリソースを割り当てることができる。様々な実施形態において、例示のクラウドアーキテクチャ１００は、複数のクラウドコントローラ（図示せず）を含んでよい。複数のクラウドコントローラのオペレーションを調整する様々な技術は明らかであろう。

データセンター１３０、１４０、１５０はそれぞれ、クラウドリソースを提供する１つまたは複数のデバイスを支援する位置であってよい。たとえば、データセンター１３０はクラウドデバイス１３１、１３２、１３３をホストすることができ、データセンター１４０はクラウドデバイス１４４をホストすることができ、データセンター１５０はクラウドデバイス１５５、１５６をホストすることができる。データセンター１３０、１４０、１５０は地理的に分散されてよく、または、クライアントデバイス１１０から異なるネットワーク距離に位置していてもよい。たとえば、クライアントデバイス１１０はワシントンＤ．Ｃ．に位置し、データセンター１４０はシカゴに位置し、データセンター１５０はパリに位置し、データセンター１３０は東京に位置していてもよい。この例によれば、クライアントデバイス１１０はデータセンター１４０と通信する場合、データセンター１３０と通信する場合よりも短いネットワーク待ち時間を経験するかもしれない。クラウドアーキテクチャ１００は、多数のさらなるデータセンター（図示せず）を含んでよく、また、各データセンターは任意の数のクラウドデバイスを含んでよいことは明らかであろう。

各クラウドデバイス１３１、１３２、１３３、１４４、１５５、１５６は、クライアントデバイスによって使用するためのクラウドリソースを提供するように構成されたデバイスであってよい。様々な実施形態において、各クラウドデバイス１３１、１３２、１３３、１４４、１５５、１５６は、デスクトップコンピュータ、ラップトップ、タブレット、モバイルデバイス、サーバまたはブレードであってよい。このため、クラウドデバイス１３１、１３２、１３３、１４４、１５５、１５６は、たとえば、ストレージデバイス、メモリ、または１つまたは複数のプロセッサなどの様々なハードウェアを含んでよい。クラウドデバイス１３１、１３２、１３３、１４４、１５５、１５６は、クライアントデバイス１１０のようなクライアントデバイスによって使用するための処理、ストレージ、メモリ、仮想マシン（ＶＭｓ）、または一群の仮想マシン（ＶＭｓ）を提供するように構成されてよい。

様々な実施形態において、図１に示される実施形態のように、クラウドコントローラ１２０はアプリケーションマネジャー１６０とインターフェースで接続して、要求に応じてクラウドアプリケーションを配備し、その後、スケールすることができる。アプリケーションマネジャー１６０は、たとえば、デスクトップコンピュータ、ラップトップ、タブレット、モバイルデバイス、サーバまたはブレードであってよく、仮想マシンを含んでもよい。アプリケーションマネジャー１６０は、クライアント１１０またはクラウドコントローラ１２０から「レシピファイル」を受信することができる。本明細書において用いられる「レシピファイル」という用語は、アプリケーションについて配備されることになる構成要素のあらゆる定義を意味することが理解されよう。さらに、「ファイル」という用語は、従来知られているようなファイルだけではなく、このような定義を保持するのに適した任意の他のストレージ構造も意味することが理解されよう。たとえば、レシピファイルは、アプリケーションがフロントエンドウェブサーバごとにデータベースサーバおよびフロントエンドウェブサーバを含むことを指定することができる。レシピファイルによって定義されることになる様々な代替のアプリケーションは明らかであろう。レシピファイルを受信すると、アプリケーションマネジャー１６０はレシピファイルを解釈し、次いで、クラウドコントローラ１２０がレシピファイルで定義されたアプリケーションを構成する構成要素を確立するよう要求することができる。その後、アプリケーションマネジャー１６０は、顧客のトラフィックによって様々な構成要素にかけられる負荷を監視し、クラウドコントローラ１２０に過負荷である構成要素をスケールアップし、または、十分に利用されていない構成要素をスケールダウンするよう要求することができる。たとえば、アプリケーションマネジャー１６０はアプリケーションに属するフロントエンドウェブサーバが過負荷であることを判定し、次いで、クラウドコントローラ１２０に追加のフロントエンドウェブサーバを確立することによってスケールアップするよう要求することができる。たとえば、クラッシュした、または機能しない仮想マシン（ＶＭｓ）に対処し、続いて、クラッシュした、または機能しない仮想マシン（ＶＭ）に予め存在する構成要素を再配備するなどの、アプリケーションマネジャー１６０に関する様々な他の機能は明らかであろう。

確立またはスケールする要求を受信すると、クラウドコントローラ１２０は、ユーザから提供された「ポリシーファイル」を用いて、要求されたオペレーションに適した位置を決定することができる。本明細書において用いられる「ポリシーファイル」という用語は、アプリケーションにおける構成要素の配置に対する制約またはセグメント化のあらゆる定義を意味することが理解されよう。たとえば、ポリシーファイルは、フロントエンドサーバの６０％は米国内に位置する第１のセグメントに配置されるべきであり、一方、フロントエンドサーバの４０％は欧州内に位置する第２のセグメントに配置されるべきであると指定することができる。以下でより詳細に記述されるように、ポリシーファイルはまた、構成要素の配置に対する様々なセグメント内制約およびセグメント間制約を定義することができる。構成要素を確立またはスケールするとき、クラウドコントローラ１２０は、ポリシーファイルで定義された様々な制約に整合する位置を選択することができる。

図２は、例示のセグメント化されたアプリケーション２００を示す。このセグメント化されたアプリケーション２００は、たとえば、図１に示すクラウドアーキテクチャ１００などのクラウドアーキテクチャで実施され得る。図示の通り、例示のアプリケーションは、５つのウェブサーバ２１４、２１６、２２４、２２６、２２８、および５つのデータベースサーバ２１２、２２２、２３２、２３４、２３６を含んでよい。図示の通り、様々な構成要素２１２、２１４、２１６、２２２、２２４、２２６、２２８、２３２、２３４、２３６は直接相互に接続されていなくてもよく、その代わりに、たとえばインターネットなどの媒介デバイスの１つまたは複数のネットワークを介して通信可能であることが理解されよう。さらに、構成要素２１２、２１４、２１６、２２２、２２４、２２６、２２８、２３２、２３４、２３６は、異なる機能を実行する、クラウドアーキテクチャ内に配備された様々な仮想マシンを表すことができる。様々な構成要素は、ユーザから提供されたポリシーファイルによって指定された通りに、３つのセグメント２１０、２２０、２３０の間で分散され得る。ポリシーファイルは、たとえば拡張マークアップ言語（ＸＭＬ）、スクリプト言語、プロプライエタリなポリシーファイルマークアップ言語、または、セグメントおよび制約を定義するのに有用な任意の他の言語など、様々な形式で定義され得る。このようなポリシーファイルは、たとえば以下の通り読める。

理解される通り、例のポリシーファイルは３つのセグメントを定義する：セグメント１ ２１０、セグメント２ ２２０およびセグメント３ ２３０である。例のポリシーファイルはまた、セグメント２１０、２２０、２３０間のアプリケーションの構成要素の分散を定義する。たとえば、ポリシーファイルは、データベースサーバの２０パーセントおよびウェブサーバの４０パーセントがセグメント１に割り当てられるべきであると指定する。このため、５つのデータベースサーバと５つのウェブサーバを分散する場合、クラウドコントローラ１２０は、１つのデータベースサーバ２１２と、２つのウェブサーバ２１４および２１６とをセグメント１に割り当てることができる。セグメントごとに指定される数、パーセンテージまたは他の割合は、常に正確に達成できるものでなくてよく、その場合、クラウドコントローラ１２０は、単にポリシーファイルで指定された分散を近似する割当分散を選択してよいということが理解されよう。たとえば、６つのウェブサーバが確立されることになる場合、クラウドコントローラ１２０は、追加のウェブサーバ（図示せず）を、５０−５０−０で分散するためにセグメント１ ２１０に配置してもよいし、または、３３−６７−０で分散するためにセグメント２ ２２０に配置してもよい。

３つのセグメント２１０、２２０、２３０を定義するとき、例のポリシーファイルはまた、３つのセグメント２１０、２２０、２３０それぞれに個々のセグメント制約を指定する。具体的には、「＜ｇｅｏｇｒａｐｈｙ＞」タグ内では、ポリシーファイルは、各セグメント２１０、２２０、２３０に割り当てられる構成要素が確立されることになる国または他の地理的地域を指定する。たとえば、ポリシーファイルは、セグメント１ ２１０は、欧州内に確立されることになると指定する。このように、クラウドコントローラは、パリに位置するデータセンター１５０および欧州内に位置する任意の他のデータセンター（図示せず）の中にセグメント１ ２１０に割り当てられた構成要素２１２、２１４、２１６を確立することができる。地理的制約に加えて、個々のセグメント制約が他のタイプの制約を指定し得ることが理解されよう。たとえば、個々のセグメント制約は、構成要素がＬｉｎｕｘ（登録商標）マシンに配置されることになること、または、選択されたマシンがそこで作動する仮想マシン（ＶＭｓ）を管理する特定のハイパーバイザを使用することを指定し得る。

ポリシーファイルはまた、個々のセグメント制約に加えて、他の２つのタイプの制約を指定することができる：セグメント内制約およびセグメント間制約である。セグメント内制約は、同一のセグメント内の他の構成要素との関係で構成要素がどこに配置されるかに対する制約であり得、「＜ｓｅｇｍｅｎｔ＞」タグ内にある「＜ａｆｆｉｎｉｔｙＲｕｌｅｓ＞」タグの内部で定義され得る。示されている通り、制約は、各構成要素が他のノードに関する制約に拘束される、ＮＯＤＥ（ノード）レベル制約の点から定義され得、または、１つのグループ（たとえばウェブサーバ）に属する構成要素が他のグループ（たとえばデータベースサーバ）に属する構成要素に関する制約に拘束される、ＺＯＮＥ（ゾーン）レベル制約の点から定義され得る。例示の制約はまた、制約のタイプが「ＡＦＦＩＮＩＴＹ（アフィニティ）」タイプであるか「ＡＮＴＩ＿ＡＦＦＩＮＩＴＹ（アンチアフィニティ）」タイプであるかを指定する。ＡＦＦＩＮＩＴＹ（アフィニティ）タイプの制約の場合、クラウドコントローラ１２０は、セグメント内の他の構成要素の比較的近くに構成要素を配置しようとする。このような制約は、たとえば相互に通信するデバイス間での遅延を減少させるのに有用である。近さの概念は、地理的距離（たとえばマイル）、ネットワーク距離（たとえばホップ）、支援するデータセンターの共有性、または待ち時間の点から定義されることが理解されよう。反対に、ＡＮＴＩ＿ＡＦＦＩＮＩＴＹ（アンチアフィニティ）タイプの制約の場合、クラウドコントローラ１２０は、セグメント内の他の構成要素から比較的遠くに構成要素を配置しようとする。このような制約は、たとえば、地理的地域においてカバレッジを広げ、または、プライマリ構成要素に影響を与えた電源障害などの事象の範囲外にある可能性がより高い冗長要素を提供するのに有用である。一例として、ポリシーファイルはセグメント１ ２１０についてＺＯＮＥ（ゾーン）レベルのアフィニティ制約を指定する。この制約を守るとき、クラウドコントローラ１２０は、他の制約を維持しつつ、可能な限りデータベースサーバ２１２の近くにウェブサーバ２１４、２１６を確立しようとする。可能であれば、クラウドコントローラ１２０は、データベースサーバ２１２を支援するデータセンターと同一のデータセンター内にウェブサーバ２１４、２１６を確立してもよい。

セグメント間制約は、異なるセグメントに割り当てられた構成要素間で実行され得、「＜ｉｎｔｅｒＳｅｇｍｅｎｔＣｏｎｓｔｒａｉｎｓ＞」タグ内にある「＜ｃｏｎｓｔｒａｉｎｔ＞」タグの内部で定義され得る。セグメント間制約は、「＜ｓｅｇｍｅｎｔｓ＞」タグ内の制約の影響を受けるセグメントを定義し、「＜ａｆｆｉｎｉｔｙＲｕｌｅｓ＞」タグ内の制約タイプを指定することができる。たとえば、ポリシーファイルは、セグメント１ ２１０とセグメント２ ２２０の間にＮＯＤＥ（ノード）レベルのアンチアフィニティ制約が存在することを指定することができる。アプリケーション２００を確立するとき、クラウドコントローラ１２０は、セグメント２ ２２０に割り当てられた構成要素２２２、２２４、２２６、２２８をセグメント１ ２１０に割り当てられた構成要素２１２、２１４、２１６から比較的遠くに配置することによって、この制約を守ることができる。場合によっては、個々のセグメント制約が、このようなセグメント間制約を既に引き受けていてもよい。たとえばこの場合、セグメント１ ２１０は欧州内に位置し、セグメント２ ２２０は米国内に位置するというポリシーファイルの指定は、構成要素が互いに十分遠くにあることを、場合により確実にする。様々な実施形態において、クラウドコントローラ１２０は、たとえば東欧および米国西部に位置するデータセンターに構成要素を確立することによって、構成要素がより遠くに離れることをさらに確実にし得る。

アフィニティ制約およびアンチアフィニティ制約を指定する様々な代替の方法が存在し得ることが理解されよう。たとえば、代替のポリシーファイルは、アフィニティ制約に関して最大の構成要素間距離を、また、アンチアフィニティ制約に関して最小の構成要素間距離を指定してよい。様々な代替の実施は明らかであろう。さらに、アフィニティタイプおよびアンチアフィニティタイプの制約以外の代替の制約が使用されてもよい。たとえば、セグメント内制約またはセグメント間制約は、セグメントの構成要素が特定のクラウド標準またはハイパーバイザを使用することを指定することができる。

図３は、例示のクラウドコントローラ３００を示す。この例示のクラウドコントローラ３００は、例示のクラウドアーキテクチャ１００のクラウドコントローラ１２０に対応し得る。クラウドコントローラ３００は、プロセッサ３１０、データストレージ３２０、および入出力（Ｉ／Ｏ）インターフェース３３０を含んでよい。

プロセッサ３１０は、クラウドコントローラ３００のオペレーションを制御し、システムバスを介してデータストレージ３２０および入出力（Ｉ／Ｏ）インターフェース３３０と協働することができる。本明細書において用いられる「プロセッサ」という用語は、マイクロプロセッサ、フィールドプログラマブルゲートアレイ（ＦＰＧＡｓ）、特定用途向け集積回路（ＡＳＩＣｓ）、および他の類似の処理デバイスなど様々なデバイスを包含することが理解されよう。

データストレージ３２０は、クラウド内でリソースを管理するのに有用な様々なプログラムなどのプログラムデータを格納することができる。たとえば、データストレージ３２０は、たとえば図４および図５に関連して後述されるような１つまたは複数の方法を実行するクラウド管理命令３２２を格納することができる。このクラウド管理命令３２２は、１つまたは複数のアプリケーションマネジャーと協働し、様々なデータセンター、ハイパーバイザまたは仮想マシンのオペレーションを調整するのに有用なさらなる命令または方法を含んでよい。

データストレージはまた、以前の割当３２４の記録を格納することができる。たとえば、クラウドコントローラ３００が確立しセグメントに割り当てる各構成要素について、クラウドコントローラは割当３２４中の記録を格納することができる。このように、関連するポリシーファイルによって指定された割合が守られることを確実にするために新たな構成要素を準備する場合、クラウドコントローラ３００は、以前の割当３２４を参照することができる。様々な代替の実施形態において、クラウドコントローラ３００は、以前の割当としてのシステム状態情報を格納することよりもむしろ、様々なデータセンターに問い合わせを行うことによってシステム状態情報を取得することができる。図４および図５に関連してより詳細に後述されるように、さらに、適切なセグメントについて将来スケーリング要求が実行され得るように、クラウドコントローラ３２４は、各割当３２４と共に構成要素またはセグメントを識別するラベルを格納することができる。

様々な実施形態において、クラウドコントローラ３００はまた、将来の使用のためにユーザから受信したレシピファイル３２６およびポリシーファイル３２８を格納することができる。様々な代替の実施形態において、クラウドコントローラ３００は、これらのファイル３２６および３２８の１つまたは複数を、格納することなく単にアプリケーションマネジャーに渡してもよい。

入出力（Ｉ／Ｏ）インターフェース３３０は、プロセッサ３１０と協働して１つまたは複数の通信チャネルを通じた通信を支援することができる。たとえば、入出力（Ｉ／Ｏ）インターフェース３３０は、キーボードおよびモニターなどのユーザインターフェース、および／または、１つまたは複数のイーサネット（登録商標）ポートなどのネットワークインターフェースを含んでよい。

いくつかの実施形態において、プロセッサ３１０はプロセッサ／ＣＰＵコアなどのリソースを含むことができ、入出力（Ｉ／Ｏ）インターフェース３３０は任意の適当なネットワークインターフェースを含むことができ、または、データストレージ３２０はメモリまたはストレージデバイスを含むことができる。さらに、クラウドコントローラ３００は任意の適当な物理的ハードウェア構成であってよく、たとえば、１つまたは複数のサーバ、プロセッサ、メモリ、ネットワークインターフェースまたはストレージデバイスなどの構成要素からなるブレードなどである。これらの実施形態のいくつかでは、クラウドコントローラ３００は互いに遠く離れたクラウドネットワークリソースを含んでよい。

いくつかの実施形態において、クラウドコントローラ３００は１つまたは複数の仮想マシンを含むことができる。これらの実施形態のいくつかでは、仮想マシンは、異なる物理的マシンからの構成要素を含むことができ、または、地理的に分散されていてもよい。たとえば、データストレージ３２０およびプロセッサ３１０は、２つの異なる物理的マシンに存在することができる。

いくつかの実施形態において、クラウドコントローラ３００は、方法４００、５００を実行するようにプログラム化された汎用コンピュータであってよい。

プロセッサ実行可能なプログラムがプロセッサ３１０に実装されると、プログラムコードセグメントはプロセッサと組み合わさって、特定の論理回路に類似して動作する固有のデバイスを提供する。

たとえばプログラムおよび論理がデータストレージに格納され、また、メモリが伝達的にプロセッサに接続される実施形態に関して本明細書において図示および記述されるが、これらの情報は任意の他の適当な方法（たとえば、任意の適当な数のメモリ、ストレージまたはデータベースを使用すること）に格納され得ることを理解されたい。すなわち、任意の適当な構成のデバイスに伝達的に接続される任意の適当な構成のメモリ、ストレージまたはデータベースを使用すること、メモリ（複数可）、ストレージ（複数可）、または、内部データベースまたは外部データベース（複数可）の任意の適当な組合せに情報を格納すること、または、任意の適当な数のアクセス可能な外部メモリ、ストレージまたはデータベースを使用することである。このため、本明細書において用いられるデータストレージという用語は、メモリ（複数可）、ストレージ（複数可）およびデータベース（複数可）のすべての適当な組合せを包含するよう意図されている。

図４は、クラウド内にアプリケーションを確立する例示の方法４００を示す。方法４００は、たとえば、クラウドコントローラ１２０またはクラウドコントローラ３００などのクラウドコントローラによって実行され得る。

方法４００は、ステップ４０５で開始し、クラウドコントローラ１２０がユーザからレシピファイルを受信するステップ４１０に進むことができる。レシピファイルは、ユーザが確立されることを望むクラウドアプリケーションを定義することができる。次にステップ４１５において、クラウドコントローラ１２０はユーザからポリシーファイルを受信する。このポリシーファイルは、ステップ４１０で受信されたレシピファイルで定義された、アプリケーションを確立およびスケールするときに用いられる多数のセグメントおよび構成要素の配置に対する制約を定義することができる。クラウドコントローラ１２０は、たとえば、ユーザがファイルをアップロードする、ユーザがクラウドコントローラ提供のＧＵＩでファイルを生成する、ユーザがクラウドコントローラ１２０またはアプリケーションマネジャー１６０に存在するファイルを選択する、または、ユーザがＵＲＬによるなど他の場所に格納されたファイルを識別するなど、複数の方法でファイルを受信し得ることが理解されよう。

次にステップ４２０において、クラウドコントローラ１２０は、アプリケーションマネジャー１６０にレシピファイルを転送することができる。アプリケーションマネジャー１６０は、次に、要求に応じてどの構成要素が確立されるべきか、または後に、アプリケーションを確立およびスケールすることが終了されるべきかを調整する役割を担うことができる。レシピファイルに基づいて、アプリケーションマネジャー１６０は１つまたは複数の構成要素を確立する要求を送信することができ、この要求は、ステップ４２５においてクラウドコントローラ１２０が受信することができる。アプリケーションマネジャー１６０は、構成要素について複数の要求を含む単一のメッセージを送信し、または要求ごとに１つのメッセージを送信することができる。

ステップ４２５において要求を受信した後、クラウドコントローラ１２０は、ポリシーファイルに基づいて確立されることになる新たな構成要素についてセグメントを選択することができる。様々な実施形態において、クラウドコントローラ１２０はポリシーファイルを参照して、定義された各セグメント間で要求されたタイプの構成要素の指定された分割を決定することができる。次に、要求されたタイプのいくつの構成要素が各セグメントに割り当てられているかにも基づいて、クラウドコントローラ１２０は新たな構成要素についてセグメントを選択することができる。たとえば、セグメント１とセグメント２の間で５０−５０の分割のウェブサーバをポリシーファイルが定義し、かつ、セグメント１で確立されているウェブサーバがただ一つの場合、クラウドコントローラ１２０は、分割が２つのセグメント間で５０−５０となるように新たなウェブサーバをセグメント２に割り当てることができる。

次にステップ４３５において、クラウドコントローラ１２０は、ポリシーファイルを参照することによって選択されたセグメントについてあらゆる制約を識別することができる。前述の通り、制約は、個々のセグメント制約、セグメント内制約およびセグメント間制約を含んでよい。関連する制約を識別した後、ステップ４４０において、クラウドコントローラ１２０は新たな構成要素の配置について識別された制約に整合する位置を選択する。たとえば、セグメントが「米国」の個々のセグメント制約および欧州内の別のセグメントに関するアンチアフィニティのセグメント間制約を有する場合、クラウドコントローラ１２０は、ニューヨーク市のデータセンターを越えてサンディエゴまたはシアトルに位置するデータセンターに新たな構成要素を配置するよう選択することができる。位置を選択した後、クラウドコントローラ１２０は、ハイパーバイザまたは他の構成要素に新たな構成要素を確立するよう命令するメッセージを選択されたデータセンターに送信することによって、新たな構成要素を確立することができる。一旦構成要素が確立されると、クラウドコントローラ１２０は、新たな構成要素に関する情報と共に、アプリケーションマネジャー１６０に確立の通知を返すことができる。たとえば、アプリケーションマネジャー１６０が構成要素の負荷または性能を監視し、かつ適切なスケーリングの判断を行うことができるように、クラウドコントローラ１２０は新たな構成要素の名称または位置を提供することができる。クラウドコントローラ１２０はまた、クラウドコントローラ１２０が将来割り当てられるセグメントを識別するのに有用なラベルを提供することができる。ラベルは、セグメントを名付ける別個のラベルであってよく、または、たとえば構成要素の名称などアプリケーションマネジャー１６０に既に提供された値に組み込まれてもよい。図５に関連してより詳細に後述されるように、アプリケーションマネジャー１６０は、ラベルを格納し、このラベルをスケーリング要求と共に返送するように構成され得る。

構成要素の確立を通知した後、ステップ４５５において、クラウドコントローラ１２０は、確立すべき追加の構成要素がまだ残っているかを判断することができる。たとえば、クラウドコントローラ１２０は、アプリケーションマネジャー１６０から既に受信したメッセージが追加の要求を含むか、または、クラウドコントローラ１２０が追加の要求を伝達する追加のメッセージのために一定期間待つことができるかについて判断することができる。確立すべき追加の構成要素がまだ残っている場合、方法４００はループしてステップ４２５に戻る。そうでなければ、方法４００はステップ４６０に進み停止してよい。

図５は、クラウド内のアプリケーションをスケールする例示の方法５００を示す。方法５００は、たとえば、クラウドコントローラ１２０またはクラウドコントローラ３００などのクラウドコントローラによって実行され得る。

方法５００は、ステップ５０５で開始し、クラウドコントローラ１２０がアプリケーションマネジャー１６０からスケール要求を受信するステップ５１０に進むことができる。このスケール要求は、１つまたは複数の新たな構成要素を確立する要求、または１つまたは複数の構成要素を終了させる要求を含むことができる。確立または終了させるこの要求は、スケールされるよう要求された１つまたは複数の存在する構成要素を識別することができ、または、スケールされることになる構成要素が初めに確立されたときに、方法４００のステップ４５０においてアプリケーションマネジャー１６０に送信されたラベルを単に含むことができる。ステップ５１５において、クラウドコントローラは受信した要求からこのラベルを抽出し、次にステップ５２０において、このラベルが対応するセグメントを識別する。そうすることによって、クラウドコントローラ１２０は、スケールされることになる構成要素が初めに割り当てられたセグメントを識別することができる。

関連するセグメントを識別した後、クラウドコントローラ５２５は、スケールされることになるアプリケーションに対応するポリシーファイルに基づいてセグメントについてあらゆる関連する制約を識別することができる。このステップ５２５は、方法４００のステップ４３５に類似してよい。次にステップ５３０において、クラウドコントローラ１２０は、識別された制約に整合するスケーリングオペレーションに関する位置を選択することができる。スケーリングオペレーションが新たな構成要素の確立を含む場合、クラウドコントローラ１２０は、制約に整合する確立について位置を選択することができる。このような確立は、ポリシーファイルよって定義された１つまたは複数の構成要素の分散を乱してよいということが理解されよう。たとえば、ポリシーファイルが、２つのセグメントの間でウェブサーバの５０−５０の分散を定義し、かつ、第１のセグメントが唯一現存するウェブサーバを含む場合、アプリケーションマネジャーは具体的にセグメント１をスケールされることになるセグメントとして識別したため、クラウドコントローラ１２０は、たとえこのことが５０−５０により近い分散をもたらさないとしても第１のセグメントに新たなウェブサーバを確立することができる。このような方法で、クラウドコントローラ１２０は、負荷の増大に直面されている場所で新たな構成要素が確立され、それゆえ、新たに確立された構成要素が増大する負荷の要求に応えることに対してもたらす効果が高まることを確実にすることができる。

スケーリングオペレーションが構成要素の終了を含む場合、ステップ５３０において、構成要素の除去がセグメント内に残存する構成要素に制約を違反させないように、クラウドコントローラは既に存在する構成要素の位置を選択することができる。たとえば、２つの他のウェブサーバの間に配置されたウェブサーバを除去することが、２つの残存するウェブサーバの間に距離を生じさせて、アフィニティのセグメント内制約を違反する場合、クラウドサーバ１２０は、代わりに終了されることになる別の構成要素を見つけようとする。スケールアップするのと同様に、クラウドコントローラ１２０は、ポリシーファイルによって定義された構成要素の分散が維持されないように、アプリケーションをスケールダウンすることができる。たとえば、アプリケーションマネジャー１６０が米国セグメントのウェブサーバがスケールダウンされることを要求する場合、たとえそうすることがポリシーファイルで指定された５０−５０の分散を乱すことになるとしても、クラウドコントローラ１２０は米国セグメント（したがって、米国に配置されそうなセグメント）に割り当てられたウェブサーバを除去しようとする。そうすることによって、クラウドコントローラ１２０は、過少利用に直面していない地域からリソースが除去されないよう確実にすることができ、そのかわり、すべての確立されたリソースがローカル要求に遅れをとらないようにする必要があり得る。

次にステップ５３５において、クラウドコントローラ１２０は、選択された位置でスケーリングオペレーションを実行する。たとえば、クラウドコントローラ１２０は、新たな構成要素を確立し、または存在する構成要素を終了させることができる。次にステップ５４０において、クラウドコントローラ１２０は、アプリケーションマネジャーにスケーリングオペレーションを通知する。スケーリングオペレーションが追加の構成要素を確立することを含む場合、ステップ５４０はステップ４５０に類似してよい。このため、クラウドコントローラ１２０は、将来のスケーリングオペレーションで使用するために、セグメントを識別するラベルをアプリケーションマネジャー１６０に送信することができる。そして、方法５００はステップ５４５に進み停止してよい。

上記によれば、様々な実施形態は、ユーザが分散型のクラウドアプリケーションの配備を要求し、また、アプリケーションの構成要素がどこに配置されるかに影響を与えることができるようにする。ポリシーファイルを受信し利用するクラウドコントローラ１２０を備えることによって、ユーザは、分散型のクラウドアプリケーションをセグメントに分割し、定義されたセグメントごとに様々な配置の制約を定義する柔軟性を与えられる。さらに、アプリケーションマネジャーにセグメントを識別するラベルを提供することによって、将来のスケーリングオペレーションはこれらの制約を考慮して実行され得る。前述したことを考慮すると、本明細書において記述される方法およびシステムの様々なさらなる利点は明らかであろう。

上記の記述から、本発明の様々な例示的実施形態がハードウェアまたはファームウェアで実施され得ることは明らかである。さらに、様々な例示的実施形態は、機械可読記憶媒体上に記憶される命令として実施され得、この命令は、少なくとも１つのプロセッサによって読取りおよび実行されて、本明細書において詳細に記述されるオペレーションを実行し得る。機械可読記憶媒体はパーソナルコンピュータ、ラップトップコンピュータ、サーバ、または他のコンピューティングデバイスなどの、機械によって読み取ることができる形式の情報を記憶するための任意の機構を含んでよい。したがって、有形かつ非一時的な機械可読記憶媒体は、読取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク記憶媒体、光学記憶媒体、フラッシュメモリデバイス、および類似の記憶媒体を含んでよい。

本明細書におけるあらゆるブロック図は、本発明の原理を実施する例証となる回路の概念図を表すということが、当業者には理解されよう。同様に、フローチャート、フロー図、状態遷移図、擬似コードなどは、機械可読媒体中に実質的に表現され得、また、コンピュータまたはプロセッサが明確に示されているか否かに関わらず、コンピュータまたはプロセッサによって実質的に実行され得る様々な処理を表すということが理解されよう。

様々な例示的実施形態について、特定の例示的態様を特に参照して詳細に記述してきたが、本発明は他の実施形態が可能であり、また、その詳細は様々な明白な点において修正形態が可能であることを理解されたい。当業者には容易に明らかとなるように、本発明の精神および範囲内で、変形形態および修正形態がもたらされ得る。したがって、上記の開示、記述および図は例証のみを目的とし、決して本発明を限定するものではなく、本発明は特許請求の範囲によってのみ定められる。

Claims (15)

1. クラウド内にアプリケーションの構成要素を確立するためのクラウドコントローラによって実行される方法であって、
   要求するデバイスから構成要素を確立する要求を受信するステップ（４２５）と、
   アプリケーションについて少なくとも１つのセグメントを定義し、少なくとも１つのセグメントの第１のセグメントについて少なくとも１つの制約を定義する、アプリケーションに関連するポリシーファイルを識別するステップと、
   構成要素の確立について第１のセグメントを選択するステップ（４３０）と、
   少なくとも１つの制約に整合する位置であって、構成要素の確立についての位置を選択するステップ（４４０）と、
   選択された位置で構成要素を確立するステップ（４４５）とを含む、方法。
2. 少なくとも１つの制約が、第１のセグメントに属する構成要素について制約を指定する個々のセグメント制約を含む、請求項１に記載の方法。
3. 少なくとも１つの制約が、第１のセグメントに属する少なくとも２つの構成要素間の制約を指定するセグメント内制約を含む、請求項１から２のいずれか一項に記載の方法。
4. 少なくとも１つの制約が、第１のセグメントに属する少なくとも１つの構成要素と少なくとも１つのセグメントの第２のセグメントに属する少なくとも１つの構成要素の間の制約を指定するセグメント間制約を含む、請求項１から３のいずれか一項に記載の方法。
5. 方法が、
   要求するデバイスにラベルと共に構成要素の確立を通知するステップ（４５０）と、
   要求するデバイスからラベルを含むスケール要求を受信するステップ（５１０）と、
   第１のセグメントをラベルに関連するものとして識別するステップ（５２０）と、
   第１のセグメントに対してスケーリングオペレーションを実行するステップ（５３５）とをさらに含む、請求項１から４のいずれか一項に記載の方法。
6. 方法が、第１のセグメントを識別した後、
   ポリシーファイルから第１のセグメントについて少なくとも１つの制約を識別するステップ（５２５）と、
   少なくとも１つの制約に整合する位置であって、スケーリングオペレーションに関する位置を選択するステップ（５３０）とをさらに含み、
   スケーリングオペレーションを実行するステップ（５３５）が、選択された位置でスケーリングオペレーションを実行することを含む、請求項５に記載の方法。
7. 方法が、
   要求するデバイスからアプリケーションについて追加の構成要素を確立する要求を受信するステップ（４２５）と、
   追加の構成要素の確立のために少なくとも１つのセグメントの第２のセグメントを選択するステップ（４３０）と、
   第２のセグメント内における追加の構成要素の確立のための位置を選択するステップ（４４０）と、
   選択された位置で追加の構成要素を確立するステップ（４４５）とをさらに含む、請求項１から６のいずれか一項に記載の方法。
8. 第２のセグメントを選択するステップ（４３０）が、少なくとも１つのセグメントのポリシーファイルの定義および第１のセグメント内における構成要素の確立を反映するシステム状態情報に基づいて、追加の構成要素の確立のための第２のセグメントを選択することを含む、請求項７に記載の方法。
9. クラウド内にアプリケーションの構成要素を確立するためのクラウドコントローラであって、
   データストレージ（３２０）と、
   データストレージと通信するプロセッサ（３１０）とを含み、プロセッサが、
   要求するデバイスから構成要素を確立する要求を受信し（４２５）、
   アプリケーションについて少なくとも１つのセグメントを定義し、少なくとも１つのセグメントの第１のセグメントについて少なくとも１つの制約を定義するポリシーファイルであって、データストレージに格納されアプリケーションに関連するポリシーファイルを識別し、
   構成要素の確立について第１のセグメントを選択し（４３０）、
   少なくとも１つの制約に整合する位置であって、構成要素の確立についての位置を選択し（４４０）、および、
   選択された位置で構成要素を確立する（４４５）ように構成される、クラウドコントローラ。
10. 少なくとも１つの制約が、第１のセグメントに属する個々の構成要素について制約を指定する個々のセグメント制約を含む、請求項９に記載のクラウドコントローラ。
11. 少なくとも１つの制約が、第１のセグメントに属する少なくとも２つの構成要素間の制約を指定するセグメント内制約を含む、請求項９から１０のいずれか一項に記載のクラウドコントローラ。
12. 少なくとも１つの制約が、第１のセグメントに属する少なくとも１つの構成要素と少なくとも１つのセグメントの第２のセグメントに属する少なくとも１つの構成要素の間の制約を指定するセグメント間制約を含む、請求項９から１１のいずれか一項に記載のクラウドコントローラ。
13. プロセッサ（３１０）が、
    要求するデバイスにラベルと共に構成要素の確立を通知し（４５０）、
    要求するデバイスからラベルを含むスケール要求を受信し（５１０）、
    第１のセグメントをラベルに関連するものとして識別し（５２０）、および、
    第１のセグメントに対してスケーリングオペレーションを実行する（５３５）ようにさらに構成される、請求項９から１２のいずれか一項に記載のクラウドコントローラ。
14. プロセッサ（３１０）が、第１のセグメントを識別した後、
    ポリシーファイルから第１のセグメントについて少なくとも１つの制約を識別し（５２５）、および、
    少なくとも１つの制約に整合する位置であって、スケーリングオペレーションに関する位置を選択する（５３０）ようにさらに構成され、
    スケーリングオペレーションを実行するステップ（５３５）において、プロセッサ（３１０）が選択された位置でスケーリングオペレーションを実行するように構成される、請求項１３に記載のクラウドコントローラ。
15. プロセッサ（３１０）が、
    要求するデバイスからアプリケーションについて追加の構成要素を確立する要求を受信し（４２５）、
    追加の構成要素の確立のために少なくとも１つのセグメントの第２のセグメントを選択し（４３０）、
    第２のセグメント内における追加の構成要素の確立のための位置を選択し（４４０）、および、
    選択された位置で追加の構成要素を確立する（４４５）ようにさらに構成され、
    第２のセグメントを選択するステップ（４３０）において、プロセッサ（３１０）が、少なくとも１つのセグメントのポリシーファイルの定義および第１のセグメント内における構成要素の確立を反映するシステム状態情報に基づいて、追加の構成要素の確立のための第２のセグメントを選択するように構成される、請求項９から１４のいずれか一項に記載のクラウドコントローラ。

Images