特許 6074430 クラウド選択のための調整エンジン

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6074430

(24)【登録日】2017年1月13日

(45)【発行日】2017年2月1日

(54)【発明の名称】クラウド選択のための調整エンジン

(51)【国際特許分類】

   G06F 9/50 20060101AFI20170123BHJP

   G06F 9/46 20060101ALI20170123BHJP

【ＦＩ】

   G06F9/46 465C

   G06F9/46 350

【請求項の数】15

【全頁数】27

(21)【出願番号】特願2014-530708(P2014-530708)

(86)(22)【出願日】2012年9月10日

(65)【公表番号】特表2014-530415(P2014-530415A)

(43)【公表日】2014年11月17日

(86)【国際出願番号】US2012054344

(87)【国際公開番号】WO2013039793

(87)【国際公開日】20130321

【審査請求日】2015年9月9日

(31)【優先権主張番号】13/230,487

(32)【優先日】2011年9月12日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】314015767

【氏名又は名称】マイクロソフト テクノロジー ライセンシング，エルエルシー

(74)【代理人】

【識別番号】100140109

【弁理士】

【氏名又は名称】小野 新次郎

(74)【代理人】

【識別番号】100075270

【弁理士】

【氏名又は名称】小林 泰

(74)【代理人】

【識別番号】100101373

【弁理士】

【氏名又は名称】竹内 茂雄

(74)【代理人】

【識別番号】100118902

【弁理士】

【氏名又は名称】山本 修

(74)【代理人】

【識別番号】100153028

【弁理士】

【氏名又は名称】上田 忠

(74)【代理人】

【識別番号】100120112

【弁理士】

【氏名又は名称】中西 基晴

(74)【代理人】

【識別番号】100196508

【弁理士】

【氏名又は名称】松尾 淳一

(74)【代理人】

【識別番号】100147991

【弁理士】

【氏名又は名称】鳥居 健一

(74)【代理人】

【識別番号】100119781

【弁理士】

【氏名又は名称】中村 彰吾

(74)【代理人】

【識別番号】100162846

【弁理士】

【氏名又は名称】大牧 綾子

(74)【代理人】

【識別番号】100173565

【弁理士】

【氏名又は名称】末松 亮太

(74)【代理人】

【識別番号】100138759

【弁理士】

【氏名又は名称】大房 直樹

(72)【発明者】

【氏名】バトルーニ，マーワン

(72)【発明者】

【氏名】アシュカー，シェイディ・エヌ

【審査官】 田中 幸雄

(56)【参考文献】

【文献】 特開２０１１−１２９１１７（ＪＰ，Ａ）

【文献】 特開２０１１−１８１６７（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ９／５０

Ｇ０６Ｆ ９／４６

(57)【特許請求の範囲】

【請求項1】

コンピュータ実行可能命令が具現化された１または複数のコンピュータ・メモリー・デバイスであって、前記コンピュータ実行可能命令は、実行されると、クライアントから供給された判断基準に基づいて候補コンピュータ・ネットワークに作業負荷を割り当てるための方法を実施し、前記方法は、
前記クライアントから計算リソースに対する要求を受け取るステップであって、前記要求は、前記クライアントが調整エンジンと相互作用するための仲介として役割を果たす１または複数のインターフェースを備えた抽象化レイヤーを介して受け取られ、前記抽象化レイヤーは、前記調整エンジンへの前記要求を、クライアントの好みを表すクライアント優先プロパティを指定するプログラム的に定義された判断基準として定義して通信することを容易にする、ステップと、
前記要求に関連する前記判断基準を前記調整エンジンにおいて受け取るステップであって、前記判断基準は、候補コンピュータ・ネットワークに対する前記クライアント優先プロパティを指定する、ステップと、
前記調整エンジンを利用して、複数の候補コンピュータ・ネットワークに対応する抽象化されたプロパティのメトリックに関して前記判断基準の分析を実施するステップであって、前記判断基準の分析を実施するステップは、
（ａ）メトリック・データーベースにおいて前記メトリックにアクセスするステップであって、前記抽象化されたプロパティのメトリックは、前記調整エンジンに関連するエージェントを用いて特定され、前記エージェントは、前記複数の候補コンピュータ・ネットワークの前記メトリックを動的に収集する、ステップと、
（ｂ）前記クライアント優先プロパティの判断基準を前記複数の候補コンピュータ・ネットワークの前記抽象化されたプロパティのメトリックと比較するステップであって、前記比較は、前記複数の候補コンピュータ・ネットワークについての抽象化されたプロパティの正規化メトリックを含むマニフェストに少なくとも部分的に基づき、前記正規化メトリックは、前記複数の候補コンピュータ・ネットワークを比較することを容易にする、ステップと、
を含む、ステップと、
前記正規化メトリックの比較に部分的に基づいて、前記複数の候補コンピュータ・ネットワークから、前記判断基準を満たすメトリックを明示する少なくとも１つのコンピュータ・ネットワークを絞り込むステップと、
前記少なくとも１つの絞り込まれたコンピュータ・ネットワークとの相互作用を開始するステップと、
を含む、コンピュータ・メモリー・デバイス。

【請求項2】

前記要求は、前記複数の候補コンピュータ・ネットワークにおいて利用可能な仮想機械上でアプリケーションを実行するための命令を含み、前記アプリケーションは、前記クライアントのアカウントに関連する、請求項１に記載のコンピュータ・メモリー・デバイス。

【請求項3】

前記要求は、前記複数の候補コンピュータ・ネットワークにおいて利用可能な記憶位置にデーターを維持するための命令を含み、前記データーは、前記クライアントのアカウントに関連する、請求項１に記載のコンピュータ・メモリー・デバイス。

【請求項4】

前記判断基準は、セキュリティ、可用性、コスト、スケーラビリティ、または地理的冗長性のうちの少なくとも１つに関する前記複数の候補コンピュータ・ネットワークの特定の属性を定義する、請求項１に記載のコンピュータ・メモリー・デバイス。

【請求項5】

前記メトリック・データーベースにおいて更新メトリックにアクセスするステップであって、前記更新メトリックは、メトリックを更新するために前記複数の候補コンピュータ・ネットワークから情報を動的に収集する前記調整エンジンのエージェントを用いて特定される、ステップと、
前記クライアント優先プロパティの判断基準を前記複数の候補コンピュータ・ネットワークの前記更新メトリックと比較するステップと、
前記比較に基づいて、前記少なくとも１つの絞り込まれたネットワークを、前記複数の候補コンピュータ・ネットワークからの、前記判断基準を満たす更新メトリックを明示する少なくとも１つの第２の絞り込まれたネットワークに動的に変更するステップと、
を更に含む、請求項１に記載のコンピュータ・メモリー・デバイス。

【請求項6】

前記複数の候補コンピュータ・ネットワークは、私有企業ネットワークおよび少なくとも１つのパブリック・クラウド計算ネットワークを含み、前記方法は、更に、前記調整エンジンを利用して、前記私有企業ネットワークおよび前記少なくとも１つの絞り込まれたコンピュータ・ネットワークに跨がる前記クライアントのアカウントの使用を管理するステップを含む、請求項１に記載のコンピュータ・メモリー・デバイス。

【請求項7】

前記調整エンジンを利用して前記私有企業ネットワークおよび前記少なくとも１つの絞り込まれたコンピュータ・ネットワークに跨がる前記クライアントのアカウントの使用を管理するステップは、前記少なくとも１つの絞り込まれたネットワーク上にプロビジョニングされた仮想機械上で実行するアプリケーションを監視するステップを含む、請求項６に記載のコンピュータ・メモリー・デバイス。

【請求項8】

前記調整エンジンを利用して前記私有企業ネットワークおよび前記少なくとも１つの絞り込まれたコンピュータ・ネットワークに跨がる前記クライアントのアカウントの使用を管理するステップは、前記少なくとも１つの絞り込まれたネットワーク上にプロビジョニングされた記憶位置に維持されるデーターを追跡するステップを含む、請求項６に記載のコンピュータ・メモリー・デバイス。

【請求項9】

前記方法は、更に、前記調整エンジンを利用して、前記要求を満たすために前記計算リソースを前記少なくとも１つの絞り込まれたコンピュータ・ネットワーク上にプロビジョニングするステップを含む、請求項６に記載のコンピュータ・メモリー・デバイス。

【請求項10】

前記調整エンジンを利用して前記私有企業ネットワークおよび前記少なくとも１つの絞り込まれたコンピュータ・ネットワークに跨がる前記クライアントのアカウントの使用を管理するステップは、前記少なくとも１つの絞り込まれたコンピュータ・ネットワークと他のパブリック・クラウド計算ネットワークとの間において使用の負荷均衡を行うステップを含む、請求項６に記載のコンピュータ・メモリー・デバイス。

【請求項11】

前記分析するプロセスは、更に、
ルール・データーベースからのルールにアクセスするステップであって、前記ルールは、前記絞り込まれたコンピュータ・ネットワークを選択するための追加の条件を含む、ステップと、
前記判断基準と前記メトリックとの比較の成果に影響を及ぼすように前記ルールを適用するステップと、
を含む、請求項１に記載のコンピュータ・メモリー・デバイス。

【請求項12】

私有企業ネットワークの外部にある１または複数のパブリック計算ネットワークに作業負荷を分散するためのコンピュータ化方法であって、
前記私有企業ネットワークのユーザーから発行された、前記１または複数のパブリック計算ネットワーク上にホストされたアカウント情報を更新する要求を受け取るステップであって、前記要求は、調整エンジンにおいて受け取られ、前記調整エンジンは、１又は複数のパブリック計算ネットワークからターゲット・計算ネットワークを動的にプロビジョニングして前記私有企業ネットワークの作業負荷を前記ターゲット・計算ネットワークに分散および負荷均衡する、ステップと、
前記調整エンジンを用いて、前記１または複数のパブリック計算ネットワークからターゲット・計算ネットワークを特定するステップであって、前記ターゲット・計算ネットワークは、前記アカウント情報をホストすることを責務とし、前記調整エンジンは、ターゲット・計算ネットワークのプロビジョニングを最適化するためにフィードバック・メカニズムの確立ルールまたは修正ルールを参照し、前記確立ルールおよび修正ルールは、前記フィードバック・メカニズムが前記調整エンジンの判断を評価することに基づく、ステップと、
前記要求から１または複数のコマンドを抽出するステップであって、前記１または複数のコマンドは、前記更新を実施するための命令を部分的に表す、ステップと、
前記１または複数のコマンドを、外部ソースと相互作用するときに前記ターゲット・計算ネットワークによって遵守されるルール言語に沿ったフォーマットに変換するステップと、
前記アカウント情報に対する更新を実施するよう指定された、前記ターゲット・計算ネットワークに関連した計算リソースへの前記１または複数の変換コマンドの分散を開始するステップと、
を含むコンピュータ化方法。

【請求項13】

前記ターゲット・計算ネットワーク上に前記アカウント情報を確立すると、数ある中でも前記１または複数のパブリック計算ネットワーク内における前記アカウント情報の少なくとも１つの位置を表すトークンをアドミニストレーターに公開するステップであって、前記調整エンジンは、前記トークンを前記少なくとも１つの位置に対応するものとして利用し、その結果、前記１または複数のコマンドが、前記少なくとも１つの位置に対して変換される、ステップを更に含む、請求項１２に記載のコンピュータ化方法。

【請求項14】

前記ターゲット・計算ネットワークを動的にプロビジョニングするステップは、更に、
（ａ）前記私有企業ネットワークに関連したアドミニストレーターによって供給される条件を調べるためにルール・データー・ストアにアクセスするステップであって、前記条件は、外部クラウド計算ネットワークを具現化するに当たって前記アドミニストレーターが有益と見なす判断基準を表す、ステップと、
（ｂ）前記アカウント情報をホストするための候補として指定された前記１または複数のパブリック・計算ネットワークの品質を記述するメトリックを調べるためにメトリック・データー・ストアにアクセスするステップと、
（ｃ）前記条件を考慮して前記メトリックの分析の関数として前記ターゲット・計算ネットワークを選択するステップと、
を含む、請求項１２に記載のコンピュータ化方法。

【請求項15】

１または複数のパブリック・クラウドのプロパティを監視し、前記プロパティに基づいてアカウント情報をホストするのに適したパブリック・クラウドを選択する方法を実施するためのコンピュータ・システムであって、前記コンピュータ・システムは、コンピュータ・メモリー・デバイスに結合された処理ユニットを備え、前記コンピュータ・メモリー・デバイスは、前記処理ユニットによって実行可能な複数のコンピュータ・ソフトウェア・コンポーネントを格納し、前記コンピュータ・ソフトウェア・コンポーネントは、
プライベート・クラウドに関連するアドミニストレーターによって供給される条件を存続させるルール・データー・ストアであって、前記条件は、外部クラウド計算ネットワークを具現化するに当たって前記アドミニストレーターが有益と見なす判断基準を表す、ルール・データー・ストアと、
前記アカウント情報をホストするための候補として指定された前記１または複数のパブリック・クラウドの品質を記述する前記プロパティを受け入れて維持するメトリック・データー・ストアと、
前記１または複数のパブリック・クラウドから前記プロパティを定期的かつ動的に収集し、前記収集したプロパティを前記メトリック・データー・ストアに報告するようにプログラミングされた１または複数のエージェントであって、前記１または複数のエージェントは、前記１または複数のパブリック・クラウドとどのようにインターフェースするかに関するパラメータによってインスタンス化される、１または複数のエージェントと、
パブリック・クラウドから計算リソースを要求しパブリック・クラウドにおいて変換されたプライベート・クラウドのコマンドを実施するプライベート・クラウド間の仲介として動作する抽象化レイヤーの１または複数のインターフェースを利用して、前記１または複数のパブリック・クラウドのうちのどれを、前記アカウント情報をホストするためのターゲット・クラウドとして選択すべきかを決定する調整エンジンであって、前記変換されたプライベート・クラウドのコマンドは、前記ターゲット・クラウド上の前記アカウント情報を表すトークンに少なくとも部分的に基づいて変換される、調整エンジンと、
を備える、コンピュータ・システム。

【発明の詳細な説明】

【背景技術】

【0001】

[0001] 一般に、クラウド・サービスのプロバイダーは、個人または会社が、アプリケーションの実行および／またはデーターの格納というような、アカウント情報を管理するときに補助するためにパブリック・クラウド計算ネットワーク（１つまたは複数）を提供する。例えば、パブリック・クラウド計算ネットワーク（「公衆回線」）は、私有企業ネットワークのアドミニストレーターが彼らのアカウント情報をホストするために採用することもでき、アドミニストレーターは通例公衆回線を選択する役割を担う。今日、アドミニストレーターは彼らのアカウント情報を存続させるために、やみくもに公衆回線を選択することを強いられる。何故なら、クラウド・サービスのプロパティは容易に発見できないか、または完全にアクセス不能であるからである。したがって、アドミニストレーターは、通常では、選択した公衆回線が、彼らの好みに最も良く整合するクラウド・サービスを提供するか否か確認することができない。

【発明の概要】

【0002】

[0002] 一旦公衆回線が選択されたなら、アドミニストレーターはこの選択した公衆回線と相互作用する手段を確立しなければならない。多くの場合、相互作用する手段を確立することは、労働集約的なプロセスであり、アドミニストレーターは、選択した公衆回線に合わせてインターフェース言語を学習しようとする。一旦確立されたなら、相互作用する手段は、選択された公衆回線に対する通信をそのインターフェース言語に、その場限りで手作業で変換するために用いられる。このため、アドミニストレーターには、公衆回線への流出(overflowing)に内在する複雑さを回避するために、彼らの私有企業ネットワークを拡大しようとする動機が生ずる。この慣例は、動的に変動する計算リソースに対する需要に取り組むには非効率的であり不経済である。

【0003】

[0003] 本明細書において詳しく論ずるが、本発明の実施形態は、アドミニストレーターによって指定される１組の判断基準を満たすパブリック・クラウド（１つまたは複数）を自動的に選択し、この選択されたパブリック・クラウド（１つまたは複数）との簡素な相互作用を促進する技術を紹介する。

【0004】

[0004] この摘要は、詳細な説明において以下で更に説明する概念から選択したものを、簡略化した形態で紹介するために設けられている。この摘要は、特許請求する主題の主要な特徴や必須の特徴を特定することを意図するのではなく、特許請求する主題の範囲を判断するときに補助として用いられることを意図するのでもない。

【0005】

[0005] 本発明の実施形態は、プライベート・クラウド計算ネットワーク（「プライベート・ネットワーク」）と少なくとも１つのパブリック・クラウド計算ネットワーク（「パブリック・クラウド」）との間における相互作用を総合的に記述する情報を抽象化するためのシステム、方法、およびコンピュータ読み取り可能媒体に関する。この「抽象化」は、一般に、埋め込まれたデーター(mined data)の集合体を表し、プライベート・クラウドに関連するアカウント情報に影響を及ぼす判断を行うときに拠り所とされる。通例、プライベート・クラウドのアドミニストレーターが、パブリック・クラウドの毎日の動作の低レベルな詳細を追跡するまたは分析するというような業務を実行する必要なく、抽象化を実行するために、調整エンジン(coordination engine)が提供される。即ち、調整エンジンは、パブリック・クラウドのプロパティを理解し、これらのプロパティに基づいて最適なパブリック・クラウドをインテリジェントに選択することからアドミニストレーターを軽減する役割を果たす。

【0006】

[0006] 加えて、調整エンジンは、選択されたパブリック・クラウドを他のパブリック・クラウドで自動的に更新するように設計される。一例では、更新は、抽象化内部で変更を通知するときに呼び出され、基礎的な変化をプライベート・クラウドのプロパティに反映する。他の例では、更新は、アドミニストレーターが判断基準に対する変更に提出するときに呼び出され、アドミニストレーターに好ましいクラウド・サービス属性を指定する。したがって、調整エンジンのインテリジェントな選択は、部分的に、パブリック・クラウドのプロパティ、アドミニストレーターが生成する判断基準、またはその組み合わせに基づくことができる。これは、これらのプライベート・クラウドによって明示されるプロパティを実現しこれらのプロパティに対する変更に手作業で作用する(act on)ために、場当たり的にパブリック・クラウドのプロバイダーに個別にそして頻繁に問い合わせることをアドミニストレーターに強制するのとは対照的である。

【0007】

[0007] 本発明の他の実施形態は、背景において実行するアプリケーション・プログラミング・インターフェース（ＡＰＩ）を紹介する。このＡＰＩは、プライベート・クラウドと選択されたパブリック・クラウドとの間において進行中のトランザクションを監視し促進する。通例、このＡＰＩは、選択されたパブリック・クラウドによって強制される(imposed)ルール言語（ＲＬ：rules language)にアクセスし、クラウド間で通信を移行させる(translate)ときにこのルール言語を適用することができる。つまり、このＡＰＩは、選択されたパブリック・クラウドに関するアカウント情報に対するコマンドを送り変換するプロセスを、アドミニストレーターに透過的にする。

【0008】

[0008] 一例として、アドミニストレーターは金融機関の銀行情報(banking information)の責任者(curator)であることができる。この場合、アドミニストレーターは、プライベート・クラウドを選択するときに最も重要な判断基準がセキュリティであることを指定することができる。この判断基準を調整エンジンに提出すると、ハッキングに対して高レベルの保護を行使するパブリック・クラウドを、銀行情報をホストするために選択することができる。通例、調整エンジンは、それぞれのパブリック・クラウドのプロパティを、提出された判断基準と比較するために、選択を行うときに１組のパブリック・クラウドの抽象化を見直す(review)。

【0009】

[0009] 他の例では、アドミニストレーターは、オンライン買い物フォーラムの在庫情報の責任者であってもよい。この場合、アドミニストレーターは、プライベート・クラウドを選択するときに最も重要な判断基準がコストであることを指定することができる。この判断基準を調整エンジンに提出すると、在庫情報をホストするために、使用に対して相対的に最低料金が期待できるパブリック・クラウドを選択することができる。一旦パブリック・クラウドが選択されたなら、調整エンジンは、オンライン買い物フォーラムから、選択されたパブリック・クラウドのルール言語と対応するフォーマットに自動的にコマンドをパッケージング(packaging)し始めるために、前述のＡＰＩをトリガーすることができる。更に、調整エンジンは、オンライン買い物フォーラムによって提出された判断基準が、この時点ではセキュリティーの方がコストよりも重要である(paramount)ことを示す場合、この第２例において選択されたパブリック・クラウドから、第１例（直前の章）において選択されたパブリック・クラウドに使用をシフトするように構成される。

【0010】

[0010] ２つの異なるタイプの判断基準（コストおよびセキュリティ）がアドミニストレーターによって指定されることがある場合について説明したが、アドミニストレーターの選好を伝えパブリック・クラウドを選択するときに補助となるのであれば、他のタイプの適した判断基準も使用でき、本発明の実施形態はここに説明した判断基準に限定されないことは言うまでもない。例えば、以下の判断基準の内１つ以上が、パブリック・クラウドの選択を導くために使用されるものとして完成する(completed)。即ち、非稼働時間を短縮する計算リソースの可用性、スケーラビリティ（例えば、プライベート・クラウドはパブリック・クラウドと同じレベルのスケーラビリティを提供することができない）、ホストされたアカウント情報を用いるものに物理的に近接してクラウド・サービスを提供する地理的冗長性(geo−redundancy)、そして一部のパブリック・クラウドでないと利用できない独特な特徴である。

【0011】

[0011] 本発明の実施形態について、添付図面を参照しながら、以下に詳しく説明する。

【図面の簡単な説明】

【0012】

【図1】図１は、本発明の実施形態を実現するときの使用に適した計算環境例のブロック図である。

【図2】図２は、本発明の実施形態を実現するときの使用に適した分散型計算環境を示すブロック図であり、この分散型計算環境は、パブリック・クラウドを選択し、この選択したパブリック・クラウドとの通信を管理するように構成される。

【図3】図３は、本発明の一実施形態にしたがって、パブリックおよび／またはプライベート・クラウドから抽象化されたプロパティをリストに纏めるマニフェストの模式図例である。

【図4】図４は、本発明の一実施形態にしたがって、パブリックおよび／またはプライベート・クラウド（１つまたは複数）の選択を導くために、アドミニストレーターによって提出された条件をリストに纏めたマニフェストの模式図例である。

【図5】図５は、本発明の一実施形態にしたがって、パブリックおよび／またはプライベート・クラウド（１つまたは複数）の選択を容易にするために採用される分散型計算環境を示すブロック図である。

【図6】図６は、本発明の一実施形態にしたがって、パブリックおよび／またはプライベート・クラウド（１つまたは複数）の間における相互作用を促進するために採用される分散型計算環境を示すブロック図である。

【図7】図７は、本発明の一実施形態にしたがって、作業負荷を１つ以上の候補計算ネットワークに、クライアントから提供された判断基準に基づいて割り当てる方法全体を示す流れ図である。

【図8】図８は、本発明の一実施形態にしたがって、私有企業ネットワーク外部にある１つ以上のパブリック計算ネットワークに作業負荷を分散させる方法全体を示す流れ図である。

【発明を実施するための形態】

【0013】

[0020] 本発明の実施形態の主題について、法的要件を満たすために本明細書では特定性をもって説明する。しかしながら、説明自体が本特許の範囲を限定することは意図していない。逆に、本発明者は、特許請求する主題は他の方法で具体化されて、本文書において記載されるステップとは異なるステップまたはステップの組み合わせを、他の現在および今後の技術と共に含むのでもよいと考えている。また、本特許文書の開示は、「混成クラウド・コーディネータ」(Hybrid Cloud Coordinator)という句のように、著作権保護の対象になる素材を含むことも注記してしかるべきである。著作権所有者は、特許文書または特許開示が米国特許商標庁の特許包袋または記録に現れる限りは、何人によるその複製にも異議を唱えないが、それ以外では、全ての著作権を留保する。以下の告知が本文書の部分に適用されることとする。著作権２０１１年。

【0014】

[0021] 総じて、本発明の実施形態は、プライベートおよびパブリック双方の多数のクラウド計算ネットワークにまたがってプロビジョニングおよび管理サービスを実行する技術を提供する。例えば、本技術は、目標条件（例えば、高いセキュリティ、高性能、低コスト、高い冗長性、またはロバストなバックアップ）を指定するユーザー提出条件に基づいて、種々の利用可能なクラウド計算ネットワークを絞り込むように機能することができる。以下で更に詳しく説明するが、ユーザーが出した条件に関してパブリック・クラウド計算ネットワーク（「パブリック・クラウド」）の選択を最適化しつつ、同時に選択されたパブリック・クラウド上に置かれたアカウント情報に対して負荷均衡およびデーター管理タスクを実行するために、調整エンジン、または「混成クラウド・コーディネータ」(Hybrid Cloud Coordinator)を採用することができる。

【0015】

[0022] 本明細書において用いる場合、「調整エンジン」という句は、１つの場所に存在するいずれかの特定のソフトウェアに限定されることを意味するのではなく、一般に、シームレスな方法で双方のクラウド提供物（パブリックおよびプライベート）の使用を管理し均衡を取ることができる、インテリジェントなソフトウェア・コンポーネントを指す。調整エンジンは、独立したエンティティから単体サービスとして提供されるのでもよい。または、調整エンジンがクラウド・サービス・プロバイダーからソリューション(solution)の一部として提供されるのでもよい。一実施形態例では、調整エンジンは、少なくとも３つの相補的機能を実行する。（ａ）クラウド間に跨がるアカウントのプロビジョニング、（ｂ）今後の分析および最適化のためのプロビジョニングの結果／履歴の追跡、ならびに（ｃ）クラウドから抽象化されたプロパティを考慮した、クライアントによって提供される条件に基づく判断の管理。

【0016】

[0023] 一例として、ある組織がそれ自体のプライベート・クラウド計算ネットワーク（「プライベート・クラウド」）を実行しつつ、同時に外部のクラウド・サービス（例えば、パブリック・クラウドまたは他のプライベート・クラウド）を拠り所にするのでもよい。この例では、調整エンジンは、多数のクラウドにまたがって使用を分散、最適化、均質化、および負荷均衡化するのに有効であろう。即ち、調整エンジンは、プライベート・クラウドとパブリック・クラウド（１つまたは複数）との間においてデーターの流れを移行させて管理する仲介として機能することができる。

【0017】

[0024] 通例、仲介として動作するとき、調整エンジンは、プライベート・クラウドのアドミニストレーターに対して透過的になるように動作する。あるいは、サービスを選択するためのリソースとして動作するとき、調整エンジンは、種々のプロバイダーによって提供されるサービスの比較を可視化する。したがって、一旦アドミニストレーターが、調整エンジンによって前もってサービス（１つまたは複数）を選択したなら、調整エンジンは、どのプライベート・クラウドに絞り込むべきかについてのアドミニストレーターの監視がなくても、データーを分散し、変更し、引き出すために自動的に選択を使用することができる。したがって、プライベート・クラウド（１つまたは複数）上においてリソースを使用する要求は、抽象的に、即ち、一定の外部記憶位置の具体性なく、与えられてもよい。つまり、調整エンジンは、パブリック・クラウドがクライアントの目標に適しているときはいつでも、クライアントの通常動作を乱すことなく、このパブリック・クラウド（１つまたは複数）の能力を利用するのを補助する。

【0018】

[0025] 一例として、調整エンジンは、アドミニストレーターによって、クライアントのプライベート・クラウドについての機密情報を収容しつつ、機密性が低い情報を第三者のパブリック・クラウドに格納するサービスをプロビジョニングするように構成することもできる。つまり、調整エンジンは、格納用に区別された(earmark)データーの機密性を解釈し、クライアントには透過的な機密性に基づいて、このデーターをしかるべき位置に送ることができる。このように、調整エンジンは、異なる特性（例えば、攻撃に対して強く高価であることに対して、安定であり安価である）を有する種々のパブリックおよびプライベート・クラウドに跨がるサービスへのアクセスを提供し、これらの特性に基づいてインテリジェントにしかるべきクラウド（１つまたは複数）に絞り込み、作業負荷を分散することができる。

【0019】

[0026] したがって、一態様では、本発明の実施形態は、コンピュータ実行可能命令が具体化された１つ以上のコンピュータ読み取り可能媒体に関する。これらのコンピュータ実行可能命令を実行すると、クライアントから与えられる判断基準に基づいて作業負荷を１つ以上の候補コンピュータ・ネットワークに割り当てる方法を実行する。最初に、この方法は、計算リソースを求める要求をクライアントから受け、この要求に関連する判断基準を受けるステップを含む。通例、この判断基準は、候補コンピュータ・ネットワーク（１つまたは複数）についてのクライアントが優先するプロパティを指定する。メトリックに関する判断基準の分析を実行するために調整エンジンが採用される。一実施形態例では、分析するプロセスは、以下のステップを実行することを含む。メトリック・データーベースにおいて前述のメトリックにアクセスするステップであって、候補コンピュータ・ネットワーク（１つまたは複数）からメトリックが掘り出される、ステップと、判断基準をメトリックとそれぞれ比較するステップ。この比較に基づいて、部分的に、候補コンピュータ・ネットワーク（１つまたは複数）から少なくとも１つのコンピュータ・ネットワークが絞り込まれる。一般に、絞り込まれたコンピュータ・ネットワークは、判断基準を満たすメトリックを明示する。ある後の時点において、この絞り込まれたコンピュータ・ネットワークとの相互作用が開始される。

【0020】

[0027] 他の態様では、本発明の実施形態は、私有企業ネットワークに対して外部にある１つ以上のパブリック計算ネットワークに作業負荷を分散するコンピュータ化方法を関する。この方法は、パブリック計算ネットワーク（１つまたは複数）上にホストされるアカウント情報を更新するために私有企業ネットワークのユーザーから発行される要求を受けるステップと、アカウント情報をホストする責務があるターゲット・ネットワークを、パブリック計算ネットワーク（１つまたは複数）から識別するステップとを含む。実例では、１つ以上のコマンドを要求から抽出することができる。一例として、コマンド（１つまたは複数）は、部分的に、更新を実施する命令を表す。コマンドは、外部ソースと相互作用するときにターゲット・ネットワークによって遵守されるルール言語に沿った(consistent)フォーマットに変換することができる。更に、変換されたコマンドは、ターゲット・ネットワークに関連する計算リソースに分散することができる。これらの計算リソースは、アカウント情報に対する更新を実施するように設計される。

【0021】

[0028] 更に他の態様では、本発明の実施形態は、１つ以上のパブリック・クラウドのプロパティを監視し、これらのプロパティに基づいて、アカウント情報をホストするのに適したパブリック・クラウドを選択する方法を実行するコンピュータ・システムに関する。概略的に、このコンピュータ・システムはコンピュータ記憶媒体に結合された処理ユニットを含み、このコンピュータ記憶媒体は、処理ユニットによって実行可能な複数のコンピュータ・ソフトウェア・コンポーネントを格納する。最初に、コンピュータ・ソフトウェア・コンポーネントは、ルール・データー・ストアと、メトリック・データー・ストアと、エージェント（１つまたは複数）と、調整エンジンと、フィードバック・メカニズムとを含む。ルール・データー・ストアは、プライベート・クラウドに関連するアドミニストレーターによって供給される条件を存続させるように設計される。以下で更に詳しく説明するが、これらの条件は、アドミニストレーターが外部クラウド計算ネットワークを具体化するのに価値があると見なす判断基準（例えば、コスト、セキュリティ、データーの永続性等）を露出する。メトリック・データー・ストアは、アカウント情報をホストするための候補に指定されたパブリック・クラウドの品質を記述するプロパティを受け入れて維持するように動作する。これらのクラウドは、調整エンジンによって自動的に指定されても、アドミニストレーターによって手作業で選択されてもよい。

【0022】

[0029] エージェント（１つまたは複数）は、候補パブリック・クラウド（１つまたは複数）をクロールする(crawl)ことによってプロパティを動的に収集し、収集したプロパティをメトリック・データー・ストアに報告するようにプログラミングされる。エージェントの一例には、候補パブリック・クラウド（１つまたは複数）からの予想使用料金を引き出すようにプログラミングされた価格設定エージェント(pricing agent)が含まれる。実施形態では、調整エンジンは、アカウント情報をホストするためのターゲット・クラウドとして、候補パブリック・クラウド（１つまたは複数）からどれを選択するか決定するように構成される。一例では、この決定プロセスは種々のステップを含む。これらのステップには、条件を調べるためにルール・データー・ストアにアクセスするステップ、プロパティを調べるためにメトリック・データー・ストアにアクセスするステップ、条件に関するプロパティの分析の関数としてターゲット・クラウドを選択するステップ、およびアカウント情報の少なくとも一部をホストするために計算リソースを割り当てる要求をターゲット・クラウドに送るステップが含まれるが、がこれらに限定されるのではない。フィードバック・メカニズムには、ユーザーのアプリケーションを実行する間またはユーザーのデーターを格納する動作の間、ターゲット・クラウドが選択されることに付随する条件を満たすか否かにについての、アクセスするための調整エンジンの判断を評価する役割が任される。

【0023】

[0030] これよりクラウド計算ネットワークの一般的な態様について、以下の数章において説明する。通例、本明細書において使用する場合、「プライベート・クラウド」という句は、アドミニストレーターによって運営されるプライベート・クラウド計算ネットワークを表すことを意図しており、一方「ターゲット・クラウド」という句は、クラウド・サービス・プロバイダーによって運営される少なくとも１つのパブリック・クラウド計算ネットワークを表す。通例、クラウド計算ネットワークは、分散型でデーターを格納する、またはサービス・アプリケーションを実行するように作用する(act)。例えば、クラウド計算ネットワークは、ユーザーのサービス・アプリケーションの１つ以上の部分を実行するために割り当てられるノード（例えば、計算デバイス、処理ユニット、またはサーバ・ラックにおけるブレード(blade)）を含むことができる。１つよりも多い別個のサービス・アプリケーションがノードによってサポートされているとき、これらのノードは、仮想機械に区分することができる。仮想機械は、それぞれ、各サービス・アプリケーションに特定的なリソースおよび／またはオペレーティング・システムをサポートする個別化された計算環境において、別個のサービス・アプリケーションを同時に実行する。

【0024】

[0031] 更に、各サービス・アプリケーションが機能部分に分割され、各機能部分が別個の仮想機械上で実行できるようにしてもよい。一般に、「ロール」(role)は、サービス・アプリケーションの機能部分のテンプレート記述を与える。役割は、その役割を実現するコンピュータ・コード、その役割によって要求されるホスト環境内における条件、その役割に適用される構成設定値、および他の役割、エレメント等との通信のためのエンドポイントの役割の設定を示すことによって記述される。一例では、役割の構成設定値は、役割の全てのインスタンスによって共有される集合設定値、または役割の各インスタンスに特定の個別設定値とを含むことができる。一実施形態例では、役割は各々サービス・アプリケーションのコンポーネントの特定のクラスを表す。通例、サービス・モデルは、１つ以上の役割の各々のインスタンスをどれだけデーター・センターに置くべきかについて概説し(delineate)、インスタンスの各々は、特定のクラスのコンポーネント、または役割の複製である。言い換えると、各役割は、コンポーネントの各クラスのインスタンスの集合体を表し、サービス・アプリケーションは、その機能を実行するためにあらゆる数のクラスのコンポーネントでも有することができる。

【0025】

[0032] 実施形態では、どの属性または１組の属性をサービス・アプリケーションの役割のインスタンスから送り出す(convey)べきか判断するために、サービス・モデルが採用される。本明細書において利用する場合、「サービス・モデル」という句は、限定することは意図しておらず、一般に、データー・センター内においてサービス・アプリケーションのインスタンスを確立し維持することに関する情報を含むあらゆる通信のことを言う。一般に、サービス・モデルとは、サービス・アプリケーションのコンポーネント・プログラムを管理するための命令を与えるインターフェース青写真(interface blueprint)である。サービス・モデルは、分散型動作環境全体にわたる分散位置への配備(deployment)のときに、配備されるコンポーネント・プログラム間における動作(activities)を調整する際にファブリック・コントローラーを導くように作用する。一例では、サービス・モデルは、サービス・アプリケーションのどの役割を確立すべきかについての記述を含み、またはデーター・センターにおいて役割の各々のインスタンスをどのようにインストールし作動させるかについての記述を含む。即ち、サービス・モデルは、サービス・アプリケーションのためにどの役割を実行すべきかについての明確な表現(articulation)、およびその役割のインスタンスをクラウド計算ネットワークを通じてインストールすべき場合の条件として役立つ。

【0026】

[0033] 以上、種々の異なるタイプのクラウド構成について説明したが、クラウド計算ネットワークの他の適した構造も使用できること、そして本発明の実施形態は、本明細書において説明する仮想機械に跨がる分散型サービス・アプリケーションに限定されるのではないことは言うまでもないことであり、当業者には認められてしかるべきである。本発明の実施形態の全体像について端的に説明したので、本発明の実施形態を実現するのに適した動作環境例について以下に説明する。
動作環境
[0034] 最初に特に図１を参照すると、本発明の実施形態を実現する動作環境例が示されており、全体的に計算デバイス１００と名付けられている。計算デバイス１００は、適した計算環境の一例に過ぎず、本発明の使用範囲や機能に関して何ら限定を示唆する意図はない。また、計算デバイス１００が、図示されるコンポーネントのいずれの１つまたは組み合わせに関しても何らかの依存性や要件を有するように解釈してはならない。

【0027】

[0035] 本発明は、コンピューター・コードまたは機械使用可能命令という一般的なコンテキストで説明することができ、コンピューター、あるいはパーソナル・データー・アシスタントまたは他のハンドヘルド・デバイスというような他の機械によって実行されるプログラム・モジュールのような、コンピューター実行可能命令を含む。一般に、プログラム・モジュールは、ルーチン、プログラム、オブジェクト、モジュール、データー構造等を含み、特定のタスクを実行するコード、または特定の抽象データー型を実装するコードを指す。本発明は、ハンドヘルド・デバイス、消費者用電子機器、汎用コンピューター、更に特殊な計算デバイス等を含む、種々のシステム構成で実施することができる。また、本発明は、分散型計算環境において実施することもでき、この場合、タスクは、通信ネットワークを通じてリンクされるリモート処理デバイスによって実行される。

【0028】

[0036] 引き続き図１を参照すると、計算デバイス１００は、以下のデバイスを直接または間接的に結合するバス１００を含む。メモリー１１２、１つ以上のプロセッサー１１４、１つ以上のプレゼンテーション・コンポーネント１１６、入力／出力（Ｉ／Ｏ）ポート１１８、Ｉ／Ｏコンポーネント１２０、および例示の電源１２２。バス１１０は、１つ以上のバス（アドレス・バス、データー・バス、またはその組み合わせ）であってもよいものを代表する。図１の種々のブロックは、明確さのために線で示されるが、実際には、種々のコンポーネントの境界分けはそれ程明確ではなく、例えて言えば、線は、更に正確にすると、灰色および曖昧になるであろう。例えば、ディスプレイ・デバイスのようなプレゼンテーション・コンポーネントをＩ／Ｏコンポーネントであると見なす者もいると考えられる。また、プロセッサーはメモリーを有する。本発明者は、このようなことは技術の本質であると認識しており、図１の図は、本発明の１つ以上の実施形態と共に用いることができる計算デバイス例を例示するに過ぎないことを繰り返しておく。「ワークステーション」、「サーバー」、「ラップトップ」、「ハンドヘルド・デバイス」等の間に区別は行わない。何故なら、これらは全て図１に範囲に入ると考えられ、「計算デバイス」を指すからである。

【0029】

[0037] 計算デバイス１００は、通例、種々のコンピューター読み取り可能媒体を含む。コンピュータ読み取り可能媒体は、計算デバイス１００によってアクセスすることができるあらゆる利用可能な媒体とすることができ、揮発性および不揮発性、リムーバブルおよび非リムーバブル双方の媒体を含む。一例として、そして限定ではなく、コンピューター読み取り可能媒体は、コンピューター記憶媒体および通信媒体を含むことができる。コンピューター記憶媒体は、揮発性および不揮発性双方のリムーバブルおよび非リムーバブル媒体を含み、コンピューター読み取り可能命令、データー構造、プログラム・モジュール、またはその他のデーターというような情報の格納のためのいずれかの方法または技術によって実現される。コンピューター記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリーまたはその他のメモリー技術、ＣＤ−ＲＯＭ、ディジタル・バーサタイル・ディスク（ＤＶＤ）またはその他の光ディスク・ストレージ、磁気カセット、磁気テープ、磁気ディスク・ストレージまたはその他の磁気記憶デバイス、または他のあらゆる媒体を含むが、これらに限定されるのではない。これらは、所望の情報を格納するために用いることができ、計算デバイス１００によってアクセスすることができる。通信媒体は、通例、コンピューター読み取り可能命令、データー構造、プログラム・モジュール、またはその他のデーターを、搬送波のような変調データー信号または他の伝達メカニズムにおいて具体化し、あらゆる情報配信媒体を含む。「変調データー信号」という用語は、信号内に情報をエンコードするようなやり方で、その特性の内１つ以上が設定または変更されている信号を意味する。一例として、そして限定ではなく、通信媒体は、有線ネットワークまたは直接有線接続のような有線媒体と、音響、ＲＦ、赤外線、またはその他のワイヤレス媒体のようなワイヤレス媒体とを含む。以上の内のいずれの組み合わせも、コンピューター読み取り可能媒体の範囲内に含まれてしかるべきである。

【0030】

[0038] メモリー１１２は、揮発性および／または不揮発性メモリーの形態としたコンピューター記憶媒体を含む。メモリーは、リムーバブル、非リムーバブル、またはその組み合わせであってもよい。ハードウェア・デバイスの例には、ソリッド・ステート・メモリー、ハード・ドライブ、光ディスク・ドライブ等が含まれる。計算デバイス１００は、１つ以上のプロセッサーを含む。このプロセッサーは、メモリー１１２またはＩ／Ｏコンポーネント１２０のような種々のエンティティからデーターを読み出す。プレゼンテーション・コンポーネント（１つまたは複数）１１６は、データー指示をユーザーまたは他のデバイスに提示する。プレゼンテーション・コンポーネントの例には、ディスプレイ・デバイス、スピーカー、印刷コンポーネント、振動コンポーネント等が含まれる。

【0031】

[0039] Ｉ／Ｏポート１１８は、計算デバイス１１０を、Ｉ／Ｏコンポーネント１２０を含む他のデバイスに論理的に結合することを可能にする。Ｉ／Ｏコンポーネント１２０の一部は内蔵されていてもよい。コンポーネントの例には、マイクロフォン、ジョイスティック、ゲーム・パッド、衛星ディッシュ、スキャナー、プリンター、ワイヤレス・デバイス等が含まれる。
実現用システム
[0040] 本発明の実施形態によって導入される技術は、プライベートおよびパブリック双方の、多数のクラウドに跨がってサービス（例えば、アプリケーションおよびデーター）をプロビジョニングし管理するためにある。また、この技術はセキュリティ、性能、コスト、冗長性、およびバックアップというような、クライアントによって供給される判断基準（例えば、構成方針および目標状態）に基づいて、種々の利用可能なクラウドから最適な絞り込み(targeting)を決定する場合にも役立つ。この技術を実現するシステム例について、これより図２を参照しながら論ずる。一般に、この技術は、クライアント２０５、プライベート・クラウド２１０、および１つ以上のパブリック・クラウド２５０間でインターフェースするために調整エンジン２３０を採用する。一例では、インターフェースするには、多数のクラウドに跨がって提供されるサービスを記述する情報（例えば、メトリック）を抽象化することを伴う。ここで、一部のクラウドは冗長性をもって構成され（強さおよび安定性が高められて提供される）、一方他のクラウドは費用が安く済む（提供する機構が少ない）場合もある。一旦情報が抽象化され分析されると、どのクラウドに絞り込むか決定するために、調整はこの情報をクライアント２０５に公開することができる。または、調整は、クライアントによって入力された所望の機構を、抽象化された情報と比較して、自動的に、最も当てはまるクラウド（１つまたは複数）に絞り込むこともできる。

【0032】

[0041] 他の場合では、インターフェースするには、クライアント２０５が手作業でデーターを、絞り込まれたクラウド（１つまたは複数）によって読み取り可能になるように変換する必要なく、作業負荷を絞り込まれたクラウド（１つまたは複数）にインテリジェントに分散する（例えば、抽象化された情報に基づいて）ことを伴う。即ち、調整エンジン２３０は、絞り込まれたクラウド（１つまたは複数）におけるサービスとの簡素な相互作用を促進する。一例として、この相互作用は、調整エンジン２３０によって実行され、調整エンジン２３０はクライアント２０５またはプライベート・クラウド２１０からの通信を、絞り込まれたクラウド（１つまたは複数）によって使用されるそれぞれの言語に変換する(translate)。

【0033】

[0042] これより図２に移ると、本発明の実施形態を実現するときの使用に適した分散型計算環境２００を示すブロック図が図示されている。分散型計算環境２００は、プライベート・クラウド２１０に関連するクライアント２０５、プライベート・クラウド２１０内にある抽象化レイヤー２２０、種々のコンポーネント間でインターフェースする調整エンジン２３０、フィードバック・メカニズム２３５、種々のコンポーネントをホストする主クラウド(subject cloud)２４０、パブリック・クラウド２５０のグループ、価格設定エージェント２６０、セキュリティ・エージェント２６５、ルール・データーベース（ＤＢ）２７０、性能エージェント２７５、およびメトリックＤＢ２８０を含む。尚、図２に示すクラウド２１０、２４０、および２５０は、作業負荷（例えば、データーおよび／またはサービス・アプリケーション）に対処するのに適した計算ネットワークの一例に過ぎず、本発明の実施形態の使用範囲や機能に関して何らかの限定を示唆することも全く意図していないことは言うまでもないことであり、当業者には認められよう。また、クラウド２１０、２４０、および２５０が、いずれか１つのリソース、リソースの組み合わせ（例えば、ＤＢ２７０および２８０）、そしてリソースにアクセスするための１組のＡＰＩ（例えば、調整エンジン２３０）に関しても何らかの依存性や要件を有するように解釈してはならない。更に、図２の種々のブロックは、明確化のために線で示されるが、実際には、種々のコンポーネントの境界分けはそれ程明確ではなく、例えて言えば、線は、更に正確にするならば、灰色および曖昧になるであろう。

【0034】

[0043] 主クラウド２４０は、あらゆるクラウド計算ネットワーク（例えば、プライベート・クラウド２１０の拡張、または絞り込みが検討されるパブリック・クラウド２５０の内の１つ）を代表し、調整エンジン２３０に通信可能に結合される種々のリソースを含むことができる。これらのリソースの一部には、フィードバック・メカニズム２３５、価格設定エージェント２６０、セキュリティー・エージェント２６５、および性能エージェント２７５が含まれる。これらは、主クラウド２４０を介して相互接続されるソフトウェア・コンポーネント、プログラム、またはアプリ(app)を表す。主クラウド２４０は、これらのリソースを、ノードまたはこれらのノード内部にある仮想機械というような、有形計算エレメント上にホストする。したがって、これらのリソースは、個別の自蔵品目(self−contained item)とは異なり、種々の物理的計算エレメントに跨がって分散可能に配置することができる。加えて、主クラウド２４０は、プライベート・クラウド２１０およびパブリック・クラウド２５０というような、他のクラウド計算ネットワーク上におけるサービス（例えば、抽象レイヤー２２０）にリソースを接続するチャネルを通じた通信を容易にする。一例として、通信チャネルは、限定ではなく、１つ以上のローカル・エリア・ネットワーク（ＬＡＮ）、および／またはワイド・エリア・ネットワーク（ＷＡＮ）を含むことができる。このようなネットワーク接続環境は、事務所、企業規模のコンピュータ・ネットワーク、イントラネット、およびインターネットでは極普通である。したがって、ネットワークについてはここではこれ以上説明しない。

【0035】

[0044] これより、ＤＢ２７０および２８０の構成例について論ずる。最初に、ＤＢ２７０および２８０は、主クラウド２４０の内部または外部に存在するデーター・ストアを表し、異なるタイプのデーターをホストするようにプログラミングされる。例えば、ルール・データーベース２７０は、プライベート・クラウド２１０と関連するアドミニストレーター（例えば、クライアント２０５）によって与えられる条件を存続させるようにプログラミングすることができ、ここで「条件」とは、外部クラウド計算ネットワークを具体化することに価値があるとアドミニストレーターが見なす判断基準を表す。つまり、動作において、条件は、ホストされるアプリケーションまたはデーターを最良にサポートするパブリック・クラウド２５０の１つ以上の機構をアドミニストレーターが識別するのに役立つ。更に、条件は、調整エンジン２３０が、ルールＤＢ２７０にアクセスするときに、最も適したパブリックおよび／またはプライベート・クラウド（１つまたは複数）を選択し、作業負荷を受けるために絞り込まれるクラウドとして指定するのに役立つ。他の実施形態では、メトリックＤＢ２８０は、アカウント情報をホストする候補に指定されたパブリック・クラウド２５０の品質を記述するプロパティ（例えば、抽象化された情報）を受け入れて維持するようにプログラミングされる。

【0036】

[0045] 図５を参照して以下で論ずるように、ＤＢ２７０および２８０は、概略的に、クラウド抽象化メトリックをクライアント供給判断基準と比較する分析手順に関連する情報を格納するように構成される。種々の実施形態では、このような情報は、限定ではなく、条件、判断基準、抽象化された情報、メトリック、ならびにクラウド２１０、２４０、および２５０の他のプロパティを含むことができる。加えて、ＤＢ２７０および２８０は、格納されている情報に適したアクセスができるように、検索可能に構成することもできる。例えば、ルールＤＢ２７０は、図４に示す条件、判断基準、およびその他の情報を求める検索ができるとよく、一方メトリックＤＢ２８０は、図３に示すメトリック、クラウドのプロパティ、およびその他の情報を求める検索ができるとよい。尚、ＤＢ２７０および２８０に格納される情報は、構成変更可能(configurable)であるとよく、調整エンジン２３０によって実行される機能に関連する情報であればいずれでも含むことができることは言うまでもなく、当業者には理解されよう。このような情報の内容および分量は、本発明の実施形態の範囲を限定することは全く意図していない。更に、１つの独立したコンポーネントとして図示されているが、ＤＢ２７０および２８０は、実際には、複数のデーター・ストア、例えば、データーベース・クラスターであってもよく、その一部が主クラウド２４０、他のクラウド２１０および２５０、他の外部計算デバイス（図示せず）、および／またはその任意の組み合わせに存在することができる。

【0037】

[0046] これより、図３を参照して、メトリックＤＢ２８０に格納される１組の情報例について論ずる。概して言うと、図３は、本発明の一実施形態にしたがって、パブリックおよび／またはプライベート・クラウドから抽象化されたプロパティをリストに纏めたマニフェスト３００の模式図例を示す。これらのプロパティは、メトリックＤＢ２８０のマニフェスト３００内においてエントリーとして格納することができる。図示のように、マニフェスト３００内における第１エントリーは、データーを格納することを目的とするサービスによって運営されるクラウド計算ネットワークにおけるストレージ型リソース（例えば、Amazon）を記述する。このストレージ・サービスに対する可用性スコア（９９．９％）は、ルールＤＢ２７０における条件に関して図２の調整エンジン２３０が判断するために用いられる１つのメトリックを表す。一例では、可用性スコアは、ストレージ・サービスが、切断や障害オフラインがなく利用可能であることを期待される時間の割合を表す。性能スコア（１２３．４５６）は、計算容量（例えば、ＧＢ／ｓまたはＣＰＵ）が所望の判断基準として指定されるときに、しかるべきサービスを選択するために用いられる。価格設定方式（ＧＢ当たり０．０２ドル）は、一般に、クライアントのデーターを離れて維持するために計算容量を割り当てるときにストレージ・サービスによって課金される料金である。
[0047] 更に、マニフェスト内における第２エントリーは、アプリケーションをホストすることを目的とするサービス（例えば、Windows Azure）によって運営されるクラウド計算ネットワークにおけるホスティング型リソース(host−type resource)を記述する。通例、アプリケーションは、ホスティング・サービス内部におけるノード上で実行する仮想機械の間で分散される。ストレージ・サービスと比較すると、ホスティング・サービスの方が高い可用性スコアを有すると評価され、これはクライアントによるアクセス可能性が一層高いことに対応する。また、第２エントリーのホスティング・サービスは、ストレージ・サービスよりも高い性能スコアを有し、こちらの方が処理速度が速いことに対応する。最後に、ホスティング・サービスの価格設定方式（毎時０．１５ドル）は、ストレージ・サービスの方式とは異なってフォーマットされる。メトリックＤＢ２８０は、ストレージ・サービスとホスティング・サービスとの間で比較ができるようにするために、別個の価格設定方式を正規化された方式に変換するように構成される。

【0038】

[0048] 尚、クラウド・サービスの他のプロパティも抽象化してマニフェスト３００に格納できることは認められてしかるべきである。例えば、ホスティング・サービスによって用いられる仮想機械の特性は、通例アプリケーションおよびオペレーティング・システムのプロパティに基づくが、ホスティング・サービスが適正にクライアントのアプリケーションの機能に対処することを保証するために、マニフェスト内に記述することもできる。アドミニストレーターから与えられる判断基準は、この判断基準をエントリーと比較することによって、クラウドを選択するために用いられる。

【0039】

[0049] これより図４に移ると、本発明の一実施形態による、パブリックおよび／またはプライベート・クラウド（１つまたは複数）の選択を導くためにアドミニストレーターによって提出される条件または判断基準をリストに纏めたマニフェスト４００の模式図例が示されている。通例、マニフェスト４００は、図２のルールＤＢ２７０によって維持される。図示のように、マニフェスト４００は、２つのエントリーを含む。即ち、データー・ストレージに関する判断基準を記述する第１エントリー、およびリモート仮想機械上におけるアプリケーションのホスティングに関する判断基準を記述する第２エントリーである。具体的には、クライアントは既に第１エントリーに第１重要度の判断基準を指定しており、これは価格（例えば、価格≦ＧＢ当たり０．１０ドル）にしたがって、ストレージ・サービスの選択を決定する(govern)。一方、クライアントは第２エントリーに第２重要度の判断基準を指定しており、これはダウンタイムが少ないことにしたがって（例えば、可用性＞９９．９９％）アプリケーションをホストするための仮想機械の選択を決定する。このように、クライアントは、パブリック・クラウド２５０において利用可能な異なるタイプのリソースに関して、重要度が異なる判断基準を選択することができる。

【0040】

[0050] 動作において、例えば、調整エンジン２３０は、図３のマニフェスト３００におけるメトリックに関して、図４のマニフェスト４００における判断基準の分析を実行することができる。この分析の結果、調整エンジンは、オフサイト・リソースの使用が求められるときに使用することを目標にして、しかるべきクラウドを選択することができる。図示のように、プライベート・クラウド・データーに対する追加の外部ストレージが調整エンジンによって求められるとき、クライアントは、価格設定判断基準がＧＢ当たり０．１０ドル未満であることを既に指定している。このメトリックは、Amazonクラウド計算ネットワークが、それよりも高いＧＢ当たり０．２０ドルの料金を課金し、したがって、データー・ストレージをサポートするための候補としては見なされないことを示す。しかしながら、仮想機械に対する追加の外部処理容量が調整エンジンによって求められるとき、クライアントは可用性判断基準が９９，９９％よりも高いことを指定している。このメトリックは、Windows Azureクラウド計算ネットワークが９９，９９９％の可用性を提示しており、したがってアプリケーションをホストする候補として考慮されることを示す。

【0041】

[0051] マニフェストの種々の異なる構成、およびその中のエントリーのタイプについて説明したが、クラウド識別(identity)とそれらのそれぞれのメトリックおよび判断基準との間のマッピングを維持するのに適した他のタイプのフォーマットも使用してもよいこと、そして本発明の実施形態は、本明細書において説明したマニフェスト３００および４００の設計例には限定されないことは言うまでもなく、認められてしかるべきである。例えば、メトリックおよび判断基準は、１つのデーター・ストア内において共通インデックスに格納してもよい。

【0042】

[0052] 実施形態では、ルール言語(rules language)が調整エンジン２３０によって採用され、調整エンジンが、メトリックに一致する判断基準にどのように重み付けするか定義する。重み付けの処理（例えば、変化する重要性を個々の判断基準に添付する）が、図２のプライベート・クラウド２１０にリソースをプロビジョニングするためにどのパブリック・クラウド（例えば、クラウドＩ２５１、クラウドＩＩ２５２、および／またはクラウドＩＩＩ２５３）に絞り込むかについての判断を決定する。一例では、ルール言語は、メトリックを考慮して判断基準の分析を行うときに、調整エンジンによって用いられるルールを定義する際にも補助することができる。例えば、ルールは、どの判断基準が絶対的であり（ホスティングの候補であることを考慮するために、クラウドのメトリックと一致しなければならない）、どの判断基準が任意であるか（クラウドにとって望ましい属性であるが考慮からは除外される）決定することができる。

【0043】

[0053] 場合によっては、ルールが調整エンジン２３０によって自動的に設定される。例えば、調整エンジン２３０は、現在政治的紛争で苦しめられている国に位置するあらゆるクラウドを考慮から除外するルールを確立することもできる。これらの自動的に設定されるルールは、通例、性質上支配的(overarching)であり、クライアントまたは他のユーザーによって入力されるルールを無視する。一例として、ネットワーク接続環境において動作するようにクライアントのアプリケーションが書かれ、クライアントが高レベルのセキュリティを強調するルール（アクセス制限を強制する）を手作業で設定したが、調整エンジン２３０は、クラウド・プロトコルとの遵守を確認するために第三者によってクライアントのアプリケーションのステータスを監視することを見込む(allow for)ルールを自動的に設定した場合、調整エンジンのルールを優先して対立が解決される。

【0044】

[0054] 他の場合では、ルールはクライアントによって手作業で設定されてもよい。例えば、クライアントが１つのメトリックを絶対的であると特定し、他の指定されたメトリックは任意であるとするルールを確立することもできる。一例では、クライアントが金融機関を表す場合、機密であるアカウント情報のセキュリティを強化した絶対ルールを手作業で設定することができ、これによって、アカウント情報にアクセスすることを許可され検証されたカストマーでなければ、アカウント情報は見れないことを規定する。他の例では、クライアントが機器製造業者を表す場合、データーへのアクセスの信頼性が手作業で設定されてもよいという絶対ルールを確立し、これによって、種々の時点において種々のユーザーに一貫して容易にデーターが利用可能であることを規定する。つまり、ルールは、クライアントが判断基準に重み付けおよび／または格付けして階層にする（例えば、セキュリティまたは信頼性に対する強調）ことを可能にしつつ、更にクライアントがルールを絶対的または単に任意と指定することも可能にする。その結果、ルールは、一旦設定されると、データーおよび／またはアプリケーションが判断基準を考慮してどのように管理されようとしているのか決定する。

【0045】

[0055] ルールの種々の異なる構成、およびそれらの判断基準に対する影響の様子について説明したが、判断基準に重要性を割り当てるのに適した他のタイプのユーザーまたはシステム既定方式を用いてもよいこと、そして本発明の実施形態は、絶対的であるとして格付け、重み付け、設定する、および任意であるとして設定するルール例には限定されないことは言うまでもなく、認められてしかるべきである。例えば、クライアントのアプリケーションに、仮想機械を選択する判断基準に影響を及ぼす１組のルールを添付することができ、一方クラウド内において記憶位置を選択する判断基準に影響を及ぼす他の１組のルールをクライアントのデーターに添付することもできる。

【0046】

[0056] 図２に戻って、プライベート・クラウド２１０上に存在する抽象化レイヤー２２０（例えば、ソフトウェア開発キット）についてこれより論ずる。図示のように、抽象化レイヤー２２０は、総じて仲介として役割を果たすために設けられる種々のインターフェースを含む。クライアント２０５は、この仲介を通じて、主クラウド２４０上に存在する調整エンジン２３０と相互作用することができる。主クラウド２４０は、プライベート・クラウド２１０と関連付けられても、付けられなくてもよい。これらの種々のインターフェースは、以下のものを含むが、これらに限定されるのではない。ルール・インターフェース２２１、リソース管理インターフェース２２２、および判断基準インターフェース２２３。

【0047】

[0057] 一例では、ルール・インターフェース２２１および判断基準インターフェース２２３は、調整エンジン２３０が候補クラウドを選択するときに遵守するために、カストマーがルールおよび判断基準をそれぞれプログラミングによって定義することを可能にする。その結果、クライアント２０５が指定した条件／望ましい条件と一致するクラウドが選択され、このクラウド上にリソースをプロビジョニングすることになる。インターフェース２２１および２２３の動作については、図５に示すクラウドの選択を容易にする方法を参照しながら、以下で更に詳しく論ずる。他の例では、リソース管理インターフェス２２２は、クライアント２０５が、コマンドの詳細な変換を行ったり外部データー・センターのプロトコルを学習することなく、パブリック・クラウド２５０から選択されたターゲット・クラウドと透過的に対話処理することを可能にするメカニズムとして動作する。したがって、抽象化レイヤー２２０内におけるリソース管理インターフェース２２２は、パブリック・クラウド２５０によって使用されるプロトコルのライブラリーとして機能し、更に加えて、そのライブラリーを用いてクライアントのコマンドをしかるべき言語およびフォーマットに自動的に変換する変換器として機能する。このように、リソース管理インターフェース２２２は、実際のクラウド実施態様について特定の知識を何ら持たなくても、外部ファイル記憶容量の増減というような、抽象化命令を受け入れることができる。

【0048】

[0058] 以上で端的に述べたように、エージェント２６０、２６５、および２７５には、調整エンジン２３０にアクセス可能なメトリック（例えば、図３のマニフェスト３００のエントリー）を更新するために、メトリックＤＢ２８０に供給される情報を周期的に投稿する役割が任される。一例では、メトリックはパブリック・クラウド２５１〜２５３から個々に抽出される。他の例では、メトリックは、他のソースをクライアントのデーターおよび／またはアプリケーション（１つまたは複数）をホストするための候補として考慮するために、主クラウド２４０、プライベート・クラウド２１０等のような、他のソースから掘り出される(mine)のでもよい。エージェント２６０、２６５、および２７５によってクロールされる正確なソースは、クライアント２０５によって手作業で、またはシステムによって自動的に確定されるのでもよい。自動的にクロールされるソースを確定する一実施形態では、ソースから収集された情報の位置および識別(identity)を運ぶ(drive)するためにデーターベース方式を生成することができる。

【0049】

[0059] 一般に、エージェントには別個の役割が割り当てられ、その役割は、相互に排他的な情報を収集しメトリックＤＢ２８０に提出することを含む。例えば、価格設定エージェント２６０には、異なるソースから価格設定情報を動的に収集する役割が割り当てることができる。特定的な例では、価格設定エージェント２６０は、種々のオンライン位置（例えば、ＵＲＬアドレス）に向けられ、オンライン位置にナビゲートすることによってクラウドから到達した価格設定情報を引き出すように、プログラミングによって構成することができる。図示のように、価格設定エージェント２６０は、３つのオンライン位置に向けられ、これらのオンライン位置は、パブリック・クラウドＩ２５１、パブリック・クラウドＩＩ２５２、およびパブリック・クラウドＩＩＩ２５３にそれぞれ対応する。価格設定エージェント２６０には、パブリック・クラウド２５１〜２５３とどのようにインターフェースするか決定するパラメータがインスタンス化されてもよい。更に、価格設定エージェント２６０は、パブリック・クラウド２５１〜２５３にいつ接触するかを決定するパラメータによってインスタンス化されてもよい。例えば、価格設定エージェント２６０は、既定の間隔で、候補クラウドに指定されたパブリック・クラウド２５１〜２５３から特定の情報を収集するようにプログラミングされるのでもよい。実施形態では、調整エンジン２３０は、価格設定エージェント２６０のパラメータをインスタンス化し管理する責務を負い、一方、クライアント２０５は、例えば、ルールＤＢ２７０内における１つ以上のルールに合わせるために、価格設定エージェント２６０の構成設定値を変更することを許可される(enabled)ことが多い。

【0050】

[0060] 一旦収集されると、価格設定エージェント２６０によって収集された価格設定情報は、返送されてメトリックＤＢ２８０に報告される。この価格設定情報は、決定を下すときに考慮すべき最新のデーターを調整エンジン２３０に供給するために、メトリックＤＢ２８０のレコードを更新するために用いられる。古くなった価格設定情報は、最新データーによって置き換えられるときに、メトリックＤＢ２８０から投棄されればよい。更に、メトリックＤＢ２８０は、調整エンジン２３０にとって使いやすくなるように、価格設定情報を分類し選別する(filter)ように構成されてもよい。

【0051】

[0061] 価格設定エージェント２６０は、パブリック・クラウド２５１〜２５３から価格設定情報（例えば、使用に対して予測される料金）を引き出すようにプログラミングされ、これについて詳細に説明したが、本発明の実施形態は、パブリック・クラウド２５０と相互作用し（直接またはＡＰＩを通じて連絡を取る）、クラウドを評価するのに有用と見なすことができる種々の他の情報を収集する、種々の他のエージェントも想定する。価格設定エージェント２６０と同様、他のエージェントも、パブリック・クラウド２５１〜２５３をクロールし収集した情報をメトリックＤＢ２８０に報告することによって、パブリック・クラウド２５１〜２５３から情報（例えば、プロパティ、属性、特性等）を動的に収集するようにプログラミングされるのでもよい。一例では、これらのエージェントには、パブリック・クラウド２５１〜２５３によってそれぞれ強制されるセキュリティ・レベルを測定するようにプログラミングされるセキュリティ・エージェント２６５、および／またはパブリック・クラウド２５１〜２５３それぞれによる可用性サポートのレベルを測定するようにプログラミングされる性能エージェント２７５が含まれる。

【0052】

[0062] エージェント２６０、２６５、および２７５に対して種々の具体的なデーター収集レート（例えば、毎分１０スキャン）を概説した(delineate)が、本発明の実施形態は、エージェント２６０、２６５、および２７５によってクロールされるクラウドから情報を収集するための時間的基準については、いずれの形式でも考慮することは認められそして理解されてしかるべきである。例えば、クライアント２０５と抽象化レイヤー２２０とのある種の相互作用によって、調整エンジン２３０に、メトリックＤＢ２８０を更新することをエージェント２６０、２６５、および２７５に要求させるのでもよい。

【0053】

[0063] 更に、調整エンジン２３０をホストする同じクラウドである主クラウド２４０について概説したが、エージェント２６０、２６５、および２７５はいずれのプライベートまたはパブリック・クラウド上に配置されてもよい。例えば、エージェント２６０、２６５、および２７５が余りに多くのリソースを消費し始めた場合、これらをパブリック・クラウド２５０の１つ以上に移動させてもよい。

【0054】

[0064] フィードバック・メカニズム２３５は、概略的に、ターゲット・クラウドが、使用のために選択されることに付随してクライアント２０５によって指定される判断基準を満たすか否かについての、アクセスするための調整エンジン２３０の決定を評価するように構成される。実施形態では、フィードバック・メカニズム２３５によって行われる評価は、以下のような種々のステップを含む。調整エンジン２３０の過去の決定を見直す、性能を改善するためにこれらの決定の影響を自己評価する、および自己評価の成果をルールＤＢ２７０に適用する。したがって、フィードバック・メカニズム２３５は、期待通りに信頼性が高い判断基準から疑わしい判断基準を選別するために、ルールを自動的に確立または修正する。このように、フィードバック・メカニズム２３５は、望まれる結果を実際に達成するために、判断基準を重み付けし直し、永続的に不正確であるとしてパブリック・クラウド２５１〜２５３から引き出された情報を無視するために、ルールを改変することができる。
調整エンジン
[0065] 調整エンジン２３０は、全体的に、（パブリックおよびプライベート）双方のクラウド提供の使用をシームレスな方法で管理し均衡を取ることができるインテリジェント・ソフトウェア・コンポーネントを表す。実施形態では、調整エンジン２３０は、プライベート・クラウドのソリューションの一部として提供される（プライベート・クラウド２１０におけるアプライアンス内の機構としてインストールされる）のでもよく、または図２に示すように、主クラウド２４０内に、クライアント２０５から離れて配置されるのでもよい。更に、調整エンジン２３０は、分割されても、２つ以上のデーター・センター上に再生されてもよい。動作において、調整エンジン２３０は２つの相補的な機能をシームレスに実行する。即ち、メトリックを考慮してクライアント２０５によって供給されるルールに基づく決定を下し、今後の分析および最適化のために結果／履歴を追跡しつつ（例えば、フィードバック・メカニズム２３５を利用する）クラウド２１０、２４０、および／または２５０に跨がってアカウントをプロビジョニングする。

【0055】

[0066] 第１の機能に関して、調整エンジン２３０は、パブリック・クラウド２５０の内どれを候補クラウドとして考慮するか決定し、これらの候補クラウドの内１つ以上を、クライアントのアカウント情報をホストするターゲット・クラウドとして選択するように設計されるとよい。実施形態では、パブリック・クラウド２５０の内、どれを候補クラウドとして考慮すべきか決定するプロセスは、ルールＤＢ２７０にアクセスして、ルールを考慮して判断基準を調べ、メトリックＤＢ２８０にアクセスしてメトリック（例えば、パブリック・クラウド２５０に対して個別なプロパティ）を調べることを含む。通例、調べる場合、データーベースの功利的な発見を促進するためにデーターベースにしたがって情報が編成されたＤＢ２７０および２８０にアクセスし、ＤＢ２７０および２８０からしかるべき情報を引き出すことを含む。実施形態では、パブリック・クラウド２５０からターゲット・クラウドを選択するプロセスは、引き出した情報と、ルールにしたがって重み付け／修正された判断基準との比較の関数としてターゲット・クラウドを選択することを含み、絞り込まれたクラウドは、判断基準を実質的に満たすメトリックを明示する。ターゲット・クラウドを選択するときに、調整エンジン２３０は、更に、絞り込まれたクラウドとの相互作用を開始し、クライアントのアカウントの少なくとも一部をホストするために計算リソースを割り当てる要求をターゲット・クラウドに送るように構成されてもよい。

【0056】

[0067] 先に示した第２関数に関して、調整エンジン２３０は、絞り込まれたクラウド（１つまたは複数）におけるクライアントの動作(activities)を管理することができる。一例では、クライアントの動作を管理するこのやり方により、クライアント２０５は要求内においてコマンドを供給することが可能になる。この要求は、プライベート・クラウド２１０のクラウド・ベース・プラットフォーム（例えば、クラウド２４０および２５０）との意図した相互作用を概略的に記述する要約情報で構成される。これらの要求は、クライアント２０５がシステムの日々の動作の低レベルな詳細を追跡および／または分析することなく、発行し実行することができる。このため、調整エンジン２３０は、各ＡＰＩの実施態様を理解することをクライアント２０５から解放する。各ＡＰＩは、リソース管理インターフェース２２２を介した、プライベート・クラウド２１０とクラウド計算プラットフォームとの間で進行中のトランザクションを監視する。言い換えると、クライアント２０５はどこに新たなデーターをアドレスすべきか、そしてどこに古いデーターが格納されているかについて事前の知識を有する必要がない。代わりに、クライアント２０５は、クラウドに特定しないリソース使用要求を生成する責務だけを果たせば良く、この要求は抽象的に形成されるコマンドを含む。また、実施形態では、調整エンジン２３０は、その目標に相応しいときにはいつでも、パブリック・クラウド２５０のパワーを利用するときに、プライベート・クラウド２１０の通常動作を乱すことなく、クライアント２０５を補助する。

【0057】

[0068] クライアント２０５がコマンドを抽象的なフォーマットで供給することを可能にするプロセスを呼び出すことを超えて、調整エンジン２３０は、任意に、クライアントのアカウントに影響を及ぼす判断を行うときに、コマンドを適用するインテリジェントな決定を背景で行う。これらのインテリジェントな決定は、通常、ルールに基づき、そのルールに対する手作業および／または自動的な修正に基づいて構成変更可能にすることもできる。例えば、調整エンジン２３０が、パブリック・クラウド２５０の内どれが要求を最良に満たすか判断するために、到来するクライアント要求を動的にアドレシングするときに、異なるメトリックを繰り返し使用することを、ルールが指令することもできる。

【0058】

[0069] これより、調整エンジン２３０の一使用例について論ずる。クライアント２０５が会社であり、バックアップソリューションを販売する業務を行うと仮定し、更にこの会社のストレージの使用が非常に多くしかも予測不可能であると仮定すると、この会社はパブリック・クラウドの柔軟性を利用することから利益が得られそうである。最初に、この会社は、プライベート・クラウド２１０に対してローカルなアプリケーションにおいて、調整エンジン２３０をセットアップする（setup)。または、この会社が調整エンジン２３０をホストしている他のクラウドのサービスを取得するのでもよい。

【0059】

[0070] 一旦調整エンジン２３０へのアクセスが得られたなら、この会社は、抽象化レイヤー２２０のルール・インターフェース２２１および判断基準インターフェース２２３を通じて、ルールおよび判断基準をそれぞれ設定することによって、調整エンジン２３０を構成することができる。判断基準を設定するとき、この会社は最も低い価格を第一に選択することができる。調整エンジン２３０は、候補クラウド（例えば、この会社が使用したいことを確認したクラウド）に指定されているパブリック・クラウド２５０についての現在の価格を把握している。更に、この会社は、プライベート・クラウド２１０を候補クラウドの１つとして考慮させるために、プライベート・クラウド２１０を実行するための動作コスト（即ち、保守コスト）を提出することができる。

【0060】

[0071] 後のある時点において、この会社は、新たに生成されるデーターのために所要のＧＢ量のストレージを求める要求を発行することができる。調整エンジン２３０は、この要求の発行時に、最も費用が少ない候補クラウドを発見しようとする。一旦費用が最も少ない候補クラウドが発見されたなら、これがターゲット・クラウドに指定され、要求内において伝えられたこの会社のデーター・ストレージ要件を満たすためにプロビジョニングされる。更に、実施形態では、調整エンジンは、ターゲット・クラウド上に置かれたストレージ・アカウントを表すトークンを戻すことができる。この会社は、ストレージ・アカウント内にあるデーターに影響を及ぼすリード／ライト・コマンドを発行するとき、このトークンを用いて、抽象化レイヤー２２０を通じて、ストレージ・アカウントをコールすることができる。調整エンジンは、このトークンを用いてターゲット・クラウドを特定し、リード／ライト・コマンドをターゲット・クラウドのネーティブなコマンドに変換する。したがって、要求内におけるターゲット・クラウドを特定し、要求内に埋め込まれた命令を変換するというこの会社の責務は、調整エンジン２３０によって引き継がれる。

【0061】

[0072] この分散型計算環境２００は、本発明の態様を実行するために実現することができる適した環境の一例に過ぎず、本発明の使用範囲や機能に関して何ら限定を示唆する意図はない。また、計算デバイス２００が、図示されるコンポーネント２２０、２３０、２３５、２６０、２６５、２７０、２７５、および２８０のいずれの１つまたは組み合わせに関しても何らかの依存性や要件を有するように解釈してはならない。実施形態の中には、コンポーネント２２０、２３０、２３５、２６０、２６５、２７０、２７５、および２８０の内１つ以上が、単体デバイスとして実装されてもよい場合もある。他の実施形態では、コンポーネント２２０、２３０、２３５、２６０、２６５、２７０、２７５、および２８０の内１つ以上が、クラウド２１０、２４０、または２５０の内１つ以上に直接統合されてもよい場合もある。尚、図２に示すコンポーネント２２０、２３０、２３５、２６０、２６５、２７０、２７５、および２８０は、性質および個数については例示であり、限定と解釈してはならないことは、当業者には言うまでもないであろう。

【0062】

[0073] したがって、本発明の実施形態の範囲内で所望の機能を達成するには、いかなる数のコンポーネントでも採用してもよい。図２の種々のコンポーネントは、明確さのために線で示されるが、実際には、種々のコンポーネントの境界分けはそれ程明確ではなく、例えて言えば、線は、更に正確にするならば、灰色および曖昧になるであろう。更に、図２の一部のコンポーネントは１つずつのブロックとして図示されているが、これらの描写はその性質および個数については例示であり、限定と解釈してはならない（例えば、プライベート・クラウドは１つしか示されていないが、もっと多くのプライベート・クラウドを調整エンジン（１つまたは複数）２３０）に通信可能に結合することもできる）。
クラウドの選択を容易にする方法
[0074] これより図５に移ると、本発明の一実施形態にしたがって、パブリックおよび／またはプライベート・クラウド（１つまたは複数）の選択を容易にするために採用される分散型計算環境５００を図示するブロック図が示されている。図示のように、計算環境５００は、図２の計算環境２００の態様を含み、同様の参照番号は実質的に同様なコンポーネントを表す。更に、計算環境５００は図７の流れ図のコンテキストで論じられ、この流れ図は、本発明の一実施形態にしたがってアドミニストレーター５１０から供給される判断基準に基づいて、作業負荷を１つ以上の候補計算ネットワークに割り当てる方法全体７００を示す。本明細書では、「ステップ」および「ブロック」という用語が、採用した方法の異なるエレメントを暗示するために以下で用いられるが、個々のステップの順序が明示的に記載されている場合を除いて(unless and except)、これらの用語が、本明細書において開示される種々のステップ間で何らかの特定の順序を暗示するように解釈してはならない。

【0063】

[0075] 最初に、アドミニストレーター５１０（クライアントのＩＴ部署の従業員）が、企業のプライベート・クラウド２１０がアプリケーションの使用において大量の増加を生じたため、仮想機械を供給するホスティング・サービスに要求を行うことを通知するというのでもよい。アドミニストレーター５１０は、ブロック７１０で示すように、リソースの要求５３０を抽象化レイヤー２２０を通じて調整エンジン２３０に発行することができる。一例では、要求５３０は、６ヶ月のプロジェクトの間１００テラバイトの計算リソースを求めることができる。

【0064】

[0076] ブロック７２０に示すように、アドミニストレーター５１０は、更に、この要求内において、ルール・インターフェース２２１および判断基準インターフェース２２３を通じて、ルール５２０および判断基準５２５をそれぞれ供給することができる。判断基準５２５を供給する一例では、アドミニストレーター５１０が抽象化レイヤー２２０と協働する相互作用アプリケーションにアクセスするのでもよく、このアプリケーションがＧＵＩをレンダリングし、このＧＵＩ内において、アドミニストレーターが計算容量の要求に判断基準５２５を添えて、提出することができる。通例、判断基準５２５は、最適なパブリック・クラウドのクライアントが優先するプロパティを指定する。一例として、添付判断基準５２５は、低い価格設定が最も重要であることを示し、一方高セキュリティおよび高性能要件というような他の判断基準５２５は、望ましいが任意である。

【0065】

[0077] 要求５３０を調整エンジン２３０に伝達するとき、調整エンジン２３０は、ブロック７３０に示すように、メトリックＤＢ２８０におけるメトリックに関して、判断基準５２５の分析を実行することができる。一実施形態例では、この分析プロセスは、以下のステップを実行することを含む。メトリックＤＢ２８０においてメトリックにアクセスする（ブロック７４０参照）、および判断基準５２５をメトリックと比較する（ブロック７５０参照）。実施形態では、調整エンジン２３０は、ルールＤＢ２７０からのルール５２０を判断基準メトリック５２５に適用することによって、メトリックを考慮することができる。ブロック７６０に示すように、部分的にこの比較に基づいて、候補クラウドの内少なくとも１つのクラウドに絞り込む。一般に、絞り込まれたコンピュータ・ネットワークは、判断基準５２５を満たすメトリックを明示する。

【0066】

[0078] 後のある時点において、ブロック７７０に示すように、絞り込まれたコンピュータ・ネットワークとの相互作用を開始する。この相互作用は、要求を満たすターゲット・クラウド上にアカウントをプロビジョニングするのでもよい。アカウントをプロビジョニングするとき、調整エンジン２３０はＵＲＬ、ＡＰＩ、および／またはトークンを信任状と共にアドミニストレーター５１０に戻すことができ、アドミニストレーター５１０がアカウントとインターフェースするために言語変換メカニズムを作成することなく、ターゲット・クラウド上のアカウントに対するリードおよびライトが可能になる（即ち、認証アクセス）。したがって、調整エンジン２３０は必ずしもターゲット・クラウドの識別をアドミニストレーター５１０に示す訳ではない。動作において、トークンは、プライベート・クラウド２１０に割り当てられたターゲット・クラウド内にある仮想機械のＩＰまたはＭＡＣアドレスのリスト、および仮想機械にアクセスするのに必要な信任状を表す。このトークンを用いると、アドミニストレーターは、割り当てられた仮想機械に離れてログインし、役割のインスタンスをイネーブルするおよび／または追加のリソースをインストールすることによって、これらをセットアップし続けることを許可される(enable)。更に、アドミニストレーター５１０がもはやターゲット・クラウドに割り当てられた仮想マシンを使用しないとき、サービスの取り消しを要求しこれらに課金が生じ続けるのを停止させるために、このトークンを用いることができる。

【0067】

[0079] 先に論じた判断基準の例５２５における多様性から、あらゆる態様において各アドミニストレーター５１０に理想的な特定のクラウド構成はないことは明らかである。また、１つのクラウド構成が、各アドミニストレーター５１０が要求する機構を明示することもなく、異なるエリア毎に異なるクラウド構成が優れる。つまり、調整エンジン２３０は、通例、このクラウドのリソースを使用するかについて最適な判断を行うために多くのパブリック・クラウド・パラメータを追跡するようにプログラミングされる。以下に最適化の事例を挙げる。

【0068】

[0080] 調整エンジン２３０は、エッジ・シナリオ(edge scenario)に対して最適化することができる。サービス・プロバイダーが１組の候補クラウドＸ、Ｙ、およびＺを運営すると仮定する。候補クラウドＸに関連するサービス・プロバイダーが、エッジ・キャッシング(edge caching)およびコンテンツ配信についてはクラスで最良であると判定された場合、アドミニストレーター５１０からの要求は、候補クラウドＹまたはＺではなく、候補クラウドＸに導かれる。本明細書において用いる場合、「エッジ・キャッシング」という句は、ユーザーの主要グループの近傍内にコンテンツを維持することを言う（例えば、日本におけるカストマーは、より早くプレーすることができるように、ロサンゼルスではなく、東京近くでメディアのコピーを望む）。

【0069】

[0081] 調整エンジン２３０は、価格設定のシナリオに対して最適化することができる。候補クラウドＸのサービス・プロバイダーが１ドル／ＧＢを課金し、一方候補クラウドＹおよびＺに関連するサービス・プロバイダーは同じ信頼性で０．５０ドル／ＧＢを課金すると仮定する。価格設定のシナリオの下では、調整エンジン２３０は、格納要求を、候補クラウドＸの代わりに、候補クラウドＹまたはＺに導くことができる。一方、図２の価格設定エージェント２６０は、候補クラウドＸ、Ｙ、およびＺの種々の価格設定方式に関して、調整エンジン２３０を最新に保つための自動サービスとして動作することができる。

【0070】

[0082] 更に、価格設定のシナリオは、候補クラウドＹおよびＺ（例えば、図２のパブリック・クラウド２５０）を使用する方が費用効率的である場合、プライベート・クラウド２１０の一部を使用しなくてもよいように、ルール５２０の中に挙動をプログラミングすることもできる。つまり、内部に格納することが指定された機密情報の突然の増大に反応するために、パブリック・クラウド（１つまたは複数）を利用してプライベート・クラウド２１０上の空間を割り当てることもできる。このように、プライベート・クラウド２１０は、監視される他のいずれのクラウドとも全く同様に、調整エンジン２３０によって候補であると考慮される。

【0071】

[0083] 調整エンジン２３０は、バックアップのシナリオに対して最適化することができる。アドミニストレーター５１０が、ルール５２０内において、信頼性高く重要なデーターをバックアップすることに、組織がプレミアムを付けることを示すと仮定する。更に、ルール５２０は、データー損失に対して最大限の保証を提供するために、候補クラウドＸ、Ｙ、およびＺの内２つ以上にデーターを冗長的に格納することも指定する。このバックアップのシナリオでは、調整エンジン２３０の決定は、複数のクラウドにおける冗長性に対して最適化することができる。

【0072】

[0084] 調整エンジン２３０は、信頼性のシナリオに対して最適化することができる。信頼性のシナリオでは、調整エンジン２３０は、候補クラウドＹではなく候補クラウドＸを選出するというような、それが行った種々の選択の信頼性履歴を追跡することができる。次いで、調整エンジン２３０は信頼性履歴を分析して、性能、信頼性等というような、候補クラウドＸおよびＹから抽出されたメトリックにおけるあらゆる変化を検出することができる。この分析を用いて、調整エンジン２３０は、アドミニストレーターのデーターを扱うときに、候補クラウドＸおよびＹの実際の信頼性や性能に基づいて、一層高く信頼性を最適化するために、その今後の判断を調節することができる。

【0073】

[0085] 調整エンジン２３０は、小売店のシナリオに対して最適化することができる。アドミニストレーター５１０がビジネス・モデルによって導かれ、会社の販売が、他のパブリック・クラウドと組み合わせたプライベート・クラウド２１０上にホストする外部カストマーによって部分的に行われる場合。一般に、会社の第三者のカストマーは、判断基準５２５があるレベルのセキュリティおよび信頼性を満たさない限り、彼／彼女のデーターがどこにホストされるかの詳細には関わらない。したがって、小売店のシナリオでは、会社は、調整エンジン２３０をブローカーとして機能するために採用し、大きな収益を得るために、価格競争および監視ボリューム(monitoring volume)の間他のパブリック・クラウドに便乗する(piggyback off)ことができる。通例、この種の会社であれば、その業務を遂行するのに役立てるために、この調整エンジン２３０のソフトウェアの使用許諾契約を結ぶであろう。
クラウド間の相互作用を容易にする方法
[0086] 図６を参照すると、本発明の一実施形態にしたがって、パブリックおよび／またはプライベート・クラウド（１つまたは複数）間の相互作用を容易にするために採用される分散型計算環境６００を図示するブロック図が示されている。図示のように、計算環境６００は、図２の計算環境２００の態様を含み、同様の参照番号は実質的に同様なコンポーネントを表す。更に、計算環境６００は、図８の流れ図のコンテキストで論じられるが、この流れ図は、本発明の一実施形態にしたがって、私有企業ネットワークの外部にある１つ以上のパブリック計算ネットワークに作業負荷を分散する方法全体８００を示す。

【0074】

[0087] 最初に、方法８００は、私有企業ネットワーク、またはプライベート・クラウド２１０のユーザー６１０から発行された、パブリック計算ネットワーク（１つまたは複数）上にホストされたアカウント情報を更新する要求６２０を受けるステップ（ブロック８１０参照）と、アカウント情報をホストする責務を果たすパブリック計算ネットワーク（１つまたは複数）２５０から目標ネットワークを特定するステップ（ブロック８２０参照）とを含む。場合によっては、ブロック８３０に示すように、１つ以上のコマンドが要求６２０から抽出されてもよい。一例として、このコマンド（１つまたは複数）は、部分的に、更新を実施する命令を表す。ブロック８４０に示すように、このコマンドは、外部ソースと相互作用するときにターゲット・ネットワークによって遵守されるルール言語と一致するフォーマットに変換することができる。更に、ブロック８５０に示すように、変換されたコマンド６３０を、ターゲット・ネットワークに関連する計算リソースに分散することができる。これらのリソースは、アカウント情報に対する更新を実施するように指定される。

【0075】

[0088] 以上、特定の実施形態に関係付けて本発明の実施形態について説明したが、これはあらゆる観点において限定的ではなく例示的であることを意図している。本発明の実施形態が関連する技術の当業者には、本発明の範囲から逸脱しない代替実施形態も明白であろう。

【0076】

[0089] 以上の説明から、本発明は、先に明記した全ての目的(ends and objects)を、本システムおよび方法にとって自明であり固有である他の利点と共に、達成するのに非常に適していることが分かるであろう。尚、ある種の特徴およびサブコンビネーションは有益であり、他の特徴およびサブコンビネーションを参照しなくても採用できることは言うまでもない。これは、請求項の範囲によって想定されていることであり、その範囲に含まれることとする。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】