JP4568289B2 - コンピューティング・ユーティリティ・システムにおけるアービトレーションのための装置 - Google Patents

Description

本発明は、整理番号ＹＯＲ９２００３０５８８ＰＣＴ１の出願「コンピューティング・ユーティリティのためのコンピューティング環境のコンポーネント化された自動プロビジョニングおよび管理」、および同日に共に出願された整理番号ＹＯＲ９２００３０５８９ＵＳ１の出願「コンピューティング・ユーティリティ・システムにおけるアービトレーションのための装置」を相互参照し、あらゆる目的のためにその全体を参照によって本明細書に含めるものとする。

本発明は、コンピューティング・ユーティリティにおけるリソースのプロビジョニングおよび管理に向けられており、コンピューティング・ユーティリティは、当該リソースを使用してコンピューティング・サービスを顧客に提供する。より特定的には、本発明は、コンピューティング・ユーティリティのための階層的リソース管理に向けられている。

ホストとされるセンタは、複数の顧客に対してコンピューティング・サービスを提供する。各顧客には、その必要に応じるために、サーバなどのサービス・プロバイダのインフラストラクチャ・リソースのサブ・セットが割り当てられている。顧客の要求は経時変化し、特に、リソースに対するピーク要求は、平均的な要求を桁違いに凌ぐことがある。ピーク要求を満たすためのリソースを単純に割り当てると、リソースが充分に活用されないままとなる。顧客の必要に応じてインフラストラクチャ・リソースを動的に再構築するには、管理要員による迅速な対処が必要となり、ハードウェアを移動させることが必要になることもあり、稼動コストが上昇して適切なサービスを提供することができない恐れがある。ホストとされるセンタについての問題は、インフラストラクチャ・リソースおよびスタッフが効率的かつ費用効果のあるやり方で使用されるように顧客の要求の変化にどのように迅速に応じるかということである。コンピューティング・ユーティリティは、共有された動的に割り当て可能なインフラストラクチャに対する複数のコンピューティング・サービスの作成および管理を自動化することによって、この問題に対処しようとしている。

コンピューティング・ユーティリティにおける従来の研究は、提供されるサービスの型、使用されるリソース、および動作の自動化の程度によって様々である。自動化された動作は広範に渡り、サービスの作成、顧客へのサービスの分配、サービスを提供するために使用されたリソースのセットの修正、ならびに新規のリソース・インスタンスおよび型をホストとされるセンタおよびそのサービスに組み込むことを含む。

従来のシステムは、ウェブ・サイトにおけるフロント・エンド・サーバのプロビジョニングを、サーバ負荷および応答時間などの数的指標に基づいて自動化した。そのシステムは、サーバおよびネットワーク・トポロジを自動的に見つけたコンポーネントを含んでいた。別のシステムは、事前に構成されたサーバをサーバ負荷などの数的指標に基づいて互いに異なる層に自動的に割り当てることが可能な様々な複数の層のウェブ・サイトを提供した。また別のシステムも、サーバ負荷に応じてサーバ・リソースを割り当てたが、リソースを各顧客へ割り当てる値と、これらのリソースを使用するコストとを、エネルギー・コストを重視してモデル化した。さらに最近の研究には、メモリおよびストレージなどの他のリソース型の割り当て、および汎用サーバの割り当てが含まれる。

アプリケーション層において、システムによっては、分配されたアプリケーションの配置および管理のための枠組みを有するものがある。アプリケーションは、互いに関連する再使用可能なコンポーネントの集まりとして記述され、リソースまたはサブ・システムを表わしてもよい。記述には、例えば、コンポーネントが正しいシーケンスで開始されることを保証するための依存情報が含まれる。一旦配置されると、アプリケーションは監視されてもよく、自動フェイルオーバまたは再開などのコンポーネントまたはリソース障害の場合にはアクションが指定されてもよい。そのようなシステムは、オペレーティング・システムをサーバにインストールするなどの低レベルのリソース構成タスクには使用されず、さらに高いレベルのアプリケーション専用の構成に使用される。

ヒューレット・パッカード社、シンクダイナミックス社、サン・マイクロシステムズ社、およびジャレバ社の製品など、複数の層のアプリケーションを様々なリソースからなる物理的なインフラストラクチャ上へ提供することを目的とする工業製品の数が増加している。これらは、提供されるリソースの種類（例えば、サーバおよびストレージ）、サポートされる特定のオペレーティング・システムおよびミドルウェア、ネットワーク・インフラストラクチャの前提および特徴（例えば、ネットワークの分離がＶＬＡＮを介して行われるかどうか）、サポートを監視するレベル（例えば、リソースの使用、障害検出、ＳＬＡ、閾値ベースの警告）、リソースの発見に対するサポート、一旦配置されたサービス・リソースの修正に対するサポート、（例えば、ＳＬＡによってトリガされて）修正が自動的に生じうるかどうか、および既存のホストとされたセンタのインフラストラクチャに合致するように製品をカスタマイズできるかまたはカスタマイズしなければならないかなど、数多くの点で互いに異なっている。

本発明は、サービス志向またはユーティリティ・コンピューティングを提供するために使用されるコンピューティング・インフラストラクチャの階層的なプロビジョニングおよび管理のための方法、装置、システム、およびアーキテクチャを提供する。これは、ホストとされる環境に有用である。これは、インフラストラクチャを有するサービス・プロバイダの顧客に提供されることが多い。これにより、コンピューティング環境に対するリソースの動的なプロビジョニングおよび割り当てが可能となる。

本発明の一局面は、以下の特徴を有する環境において動作するコンピュータ・ユーティリティの一要素を提供するものである。合わせて、これらの特徴は、これまで研究された環境を概括するものである。

本発明の他の局面は、コンピュータ・ユーティリティに対してリソースを自動的にプロビジョニングおよび管理するために提供されるものである。コンピューティング・ユーティリティは、企業、サービス・プロバイダ、または個人によって使用可能であろう。本発明により、顧客の群内においてリソースを共有でき、特定の顧客にリソースを限定することもできる。これにより、顧客は、そのクライアントに対して、管理されたリソースからなる１つ以上のサービスを提供することができる。管理されたリソースは、オン・デマンドで顧客またはドメインに割り当てられてもよい。これにより、リソースを階層的に管理することができる。

本発明に係る方法の実施形態の一例において、本方法は、エンティティに対して少なくとも１つのドメインの階層的な管理を提供するステップを有する。階層的な管理提供ステップは、少なくとも１つのドメインの階層的な表示を取得するステップであって、当該表示は、管理すべきコンピューティング環境のリストと、少なくとも１つのドメインについてのリソース・ライブラリからの少なくとも１つのリソースの取得を制御する少なくとも１つのポリシーと、少なくとも１つのドメイン内の任意のサブ・ドメインとを含む、ステップと、表示をインスタンス化するステップとを含む。

本発明に係るアーキテクチャの実施形態の一例において、コンピュータ・ユーティリティについての本アーキテクチャは、少なくとも１つのサービスを複数のクライアントに提供するための装置を備える。本装置は、リソースを少なくとも１つのサービスに割り当てるための、少なくとも１つのコレクタを有するベース・リソース分配サービスと、ベース・リソース分配サービスに結合されて、少なくとも１つのサービスについてリソースをプロビジョンおよび管理するための少なくとも１つのプロビジョンおよび管理リソース・サービスと、ベース・リソース分配サービスに結合されて、リソースの予約および割り当てを提供するための少なくとも１つのベース・リソース・ライブラリ・サービスとを備える。

上記およびさらなる局面、利点、および特徴は、以下の好適な実施形態の詳細な説明および添付の図面から、さらに明らかになるだろう。

本発明は、インフラストラクチャを所有するサービス・プロバイダの顧客にサービス志向またはユーティリティ・コンピューティングを提供するために使用されるコンピューティング・インフラストラクチャの階層的なプロビジョニングおよび管理のための方法、装置、システム、およびアーキテクチャを提供する。このように、ホストとされる環境は、他のホストとされる環境などからリソースを取得することができる。本発明は、アービトレーション、プロビジョニング、および管理を含んだコンピューティング・インフラストラクチャの階層的な管理のためのアーキテクチャを提供する。これにより、コンピューティング環境に対するリソースの動的なプロビジョニングおよび割り当てが可能となる。顧客は、そのドメイン内で複数のコンピューティング環境を有することができる。コンピューティング・ユーティリティは、そのリソースを複数の顧客ドメインに渡って共有し、ドメイン間およびドメイン内におけるリソースの使用に対してアービトレーションを行う。本発明により、リソースを、特定の顧客ドメインまたは特定のコンピューティング環境専用とすることができる。顧客は、ドメイン内のユーティリティからのリソースの使用を制御する取得および分配ポリシーを指定することができる。

本発明は、以下の特徴のうちの１つ以上を有する環境において一般的に動作するが、必ずしもそうではないコンピューティング・ユーティリィティの一要素である。合わせて、これらの特徴は、これまで研究された環境を概括するものである。

第１に、リソースは、異種の組み合わせで顧客に割り当てられてもよく、相互依存であってもよく、経時変化してもよい。

第２に、各顧客に提供されるサービスは互いに異なってもよい。例えば、ある顧客にはウェブ・サイト用のリソースが提供され、他の顧客には科学的コンピューティング・クラスタ用のリソースが提供されてもよい。よって、リソース型、量、依存性、および割り当てパターンは、顧客の間で様々なものとなる。

第３に、各顧客に提供されるサービスのレベルは異なってもよい。これは、顧客に対するリソース割り当ての量を評価することは、サービスの型およびレベルの両方を考慮することを意味する。

第４に、リソース・インフラストラクチャは、サービス・プロバイダ間で異なる。さらに、所定のサービス・プロバイダについて、インフラストラクチャは経時変化する。これらのバリエーションは、物理的なインフラストラクチャに対して更新または追加が行われたこと、他のプロバイダのサービスを受けること、またはアイドル時または一日の所定の時間において付加的なリソースが取り込まれたことの結果でありうる。

第５に、リソースは、事前に割り当てられてもよいし、予約されてもよい。インフラストラクチャ内にそれを満たすような現在使用可能な十分なリソースがない場合でも、割り当てに間に合うように追加のリソースが取得されるであろうという見込みに基づいて、予約が受理されてもよい。

第６に、顧客は、例えば部門などに割り当てを細分化してサービス・プロバイダに再分割を管理するようにさせることによって、組織内でリソースを共有したい場合がある。

第７に、顧客は、現在所有している、サービス・プロバイダによって管理されるべきリソースを供給したい場合があり（すなわち、顧客は、そのリソースの管理をサービス・プロバイダにアウトソーシングする）、このリソースは、その目的のためだけに使うことができる。この要請は、リソースをどこに割り当ててもよいかについて制約を課するものである。

第８に、顧客は、そのリソースの管理および動作を支配するポリシーを指定したい場合がある。これらのポリシーは、コンピューティング・ユーティリティによって実施されるべきものである。

最後に、互いに異なるサービス・プロバイダは、リソースを顧客に分配する際に、利益の最大化、使用可能性の最大化、または性能の最大化などのように、互いに異なる目的を意識している場合がある。

本発明は、コンピューティング・ユーティリティに対してリソースを自動的にプロビジョニングおよび管理するための装置の一部としても有用である。コンピューティング・ユーティリティは、企業、サービス・プロバイダ、または個人によって使用可能であろう。本発明により、顧客の群内においてリソースを共有でき、特定の顧客にリソースを限定することもできる。これにより、顧客は、そのクライアントに対して、管理されたリソースからなる１つ以上のサービスを提供することができる。管理されたリソースは、オン・デマンドで顧客またはドメインに割り当てられてもよい。これにより、リソースを階層的に管理することができる。

図１は、本発明が動作するホストとされる環境を示す。この環境は、プロセッサ１０１と、ストレージ１０３と、ファイアウォール１０５と、ソフトウェア１０７からなる。ソフトウェア１０７は、オペレーティング・システム、ミドルウェア、またはアプリケーションであってもよい。図１において、ソフトウェア１０７は、ビジネス・プロセス、ビジネス・アプリケーション、またはサービスによって表される。すべての利用可能なソフトウェアは、これらの要素に事前構成される。実際、要求に応じてハードウェアおよびソフトウェア・コンポーネントを新規または既存のサービスに動的に再構成するのが、本発明の目的である。この種の環境は、大企業内に存在することがあり、または、サービスのベースとしてＩＳＰまたはＡＳＰによって提供されることもある。詳細な説明に戻ると、ハードウェア・リソースは、すべてのこれらのリソースを相互接続する線１０９の格子で示されるようなネットワークによって接続される。このネットワークは、１つまたは複数の層に構成されてもよく、各層は、ルータ１０５またはファイアウォール１０５によって分離されている。ネットワーク内の層の構成は、静的であっても動的であってもよい。ネットワークが性的に構成されている場合には、人間（または機械的）介入なしにリソースをネットワーク内の層間で移動させることは不可能である。動的な構成であれば、リソースは、本発明において説明されているようなインフラストラクチャ、またはコンソールにおいて作業しているオペレータの制御の下、互いに異なる層間で移動が可能である。これは、仮想ＬＡＮなどの機構を使用することによって行うことができる。ソフトウェア・リソースは、制御インフラストラクチャによって物理リソースに割り当てられる。

この環境において、リソースのサブ・セットが管理インフラストラクチャ１１１，１１３，および１１５に割り当てられる。図１において、これらのリソースは、それを囲む点線によって示されている。管理インフラストラクチャに割り当てられたリソースは、本発明において説明されるリソース管理ソフトウェアを実行する。このソフトウェアは、残りのリソースを管理する。管理インフラストラクチャのために使用されるリソースは、ホストとされる環境の顧客に対して割り当てられない。管理されているリソースが、必要に応じて顧客１１７に割り当てられる。クライアント１１７がそのホストとされる環境にインターネット１１９を介して接続することによって主にサービスを受けることになることが予期されている。しかしながら、クライアント１１７は、ホストとされる環境に何らかの手段で接続されれば、サービスを受けることができる。例えば、管理されているリソースへ直接接続することもでき、管理されているリソースと同じネットワークに接続することもでき、管理されているリソースとＶＰＮ接続することもでき、または管理されているリソースを含むネットワークにＶＰＮ接続することもできる。クライアント１１７は、インフラストラクチャを知ることができず、ホストとされる環境から受信するアプリケーションまたはサービスを認識するだけである。

管理インフラストラクチャは、必要に応じて各サポートされたサービスに対してリソースを割り当てる。この必要性の決定は、ＳＬＡ、契約、またはホストとされる環境内で動作する権限をサービスに与えた他の合意に従った、サービスに対する要求によって行われる。サービスを提供したい個人または組織は、ホストとされる環境のプロバイダと合意を有することになる。図１に戻ると、プロセッサ１０１は、プロセッサを管理する一部として管理されるであろう、直接取り付けられたストレージを有してもよい。本図のストレージ１０３は、ネットワークに取り付けられることができるどのような形態のストレージ・サーバをも指す。プロセッサは、データベース・サーバまたはビデオ・サーバのような何らかの複雑な機能を表すこともできる。リソースが管理用にさらに小さな機能に分割される度合いは、インフラストラクチャの所有者に依存する。データベース・サーバなどの複雑なリソースがさらに小さなコンポーネントに分けることができる場合であっても、リソースの所有者は、管理インフラストラクチャ内においてどのように表されるかについて決定することになる。この特徴により、本発明は、ホストとされる環境にとってローカルでないリソースを使用することができる。本発明は、リソースが適切な性能と確実に相互関連していることを前提にしている。しかしながら、リソースを接続するネットワークは、論理接続を表す。ＶＰＮなどの、リソースに対して適切な程度のセキュリティ、性能、および制御を許容している任意のインフラストラクチャを使用して、ホストとされる環境にリソースを接続することができる。その結果、図１に示すようなホストとされる環境は、それ自体世界中に分配することができるだろう。本図におけるインターネットは、論理配置を表す。インターネットを使用して、ホストとされる環境に対してリソースを動的に追加することができる。

ドメインとは、サービスがプロビジョンされる顧客内の組織ユニットである組織は、その内部に、これもまたサービス・プロバイダを利用する複数のサブ・ドメイン、部門、ユニット、部署を有してもよい。サブ・ドメインもドメインであって、組織のドメインは、ツリーを形成する。組織は、接続されていないドメインの複数のツリーを有してもよい。本発明の目的のために、これらを複数の組織であると考える。ルート・ドメインは、組織にとって最上位のドメインまたはドメイン・ツリーのベースである。図２は、サービスが提供できる顧客内のドメインを示す。図２において、基本となる企業、すなわちルート・ドメインは、スミス・ファスナー社１２０であって、この会社の他の全ての部分は、スミス・ファスナーの細区分またはサブ・ドメインである。スミス・ファスナーは、調査１２１、財務１２２、ハードウェア１２３、およびマーケティング１２４という４つの主要部門を有する。ハードウェアおよびマーケティング部門は、付加的なユニット、すなわちサブ・ドメインを、それぞれの内部に有している。ハードウェアは、ボルト１２７、ねじ１２８、およびヒンジ１２９に分割される。マーケティングは、第１地域１２５および第２地域１２６という２つの地域を有する。第２地域は、北部１３０および南部１３１にさらに分割される。本発明の目的は、スミス・ファスナー社のような任意の会社の様々なドメイン、ユニット、または部門あるいはそれらすべてに対して、サービス・プロバイダがコンピューティング・サービスを提供することができるようにすることである。そして、任意のドメインまたはサブ・ドメインが、提供されるコンピューティング・サービスに加入してもよい。本発明は、プロビジョニングの目的のために、会社がドメイン・ツリーに構成できることを前提にしている。さらに、任意のツリーをサポートすることができる。後述するように、ドメイン・ツリーは、会社によって使用される様々なアプリケーション間のプロビジョニングの目的のために、リソースの共有を制御する。本発明は、リソース共有ツリーが企業構造に厳密にマッピングすることを必要としていない。任意のリソース共有ツリーを使用できる。例示の目的のために、スミス・ファスナー社１２０という組織の構成にマッピングするものを使用することとする。

組織内部において、各ドメイン、部門、またはユニットは、独自の従業員を有する。本発明は、会社内のどの人（会社のどの従業員）がコンピューティング・サービスを使用できるかについて限定していない。コンピューティング・サービスを使用する資格は、会社内部の管理ポリシーによって制御される。ユーザＩＤ、パスワード、および認証は、会社によって制御される。例えば、すべてのアプリケーションが通常認証および認証機構を必要とすることもでき、各アプリケーションが独自の認証を有することもでき、またその中間の組み合わせも可能である。アクセス制御のプロビジョニングは、ＰＭＲＳの一部である。コンピューティング・サービスの使用（アプリケーションをアクセスまたは使用することを許可されているユーザ）は、リソースをアプリケーションにプロビジョンするために使用される構成に依存しない。

この環境において、本発明を利用するための役割または責任を分割する方法は複数ある。そのような分割の１つでは、上述のホストとされる環境を所有するインフラストラクチャ・プロバイダがある。図１において、ホストとされる環境を使用する際に何らかのサービスを提供する１つ以上のサービス・プロバイダと、サービス・プロバイダの１人以上のクライアントとがある。サービス・プロバイダは、インフラストラクチャ・プロバイダの顧客でもあることに注意されたい。他のそのような分割では、会社（またはエンティティ）は、サービスのためのインフラストラクチャ・プロバイダと契約して、そのインフラストラクチャの管理をアウトソーシングしてもよい。この場合、会社は、本発明を利用して、自身内部に提供されたサービスを管理する。他のそのような分割では、インフラストラクチャ・プロバイダおよびサービス・プロバイダは、同一であることもできよう。さらに、提供されるサービスを開発するエンティティもある。これらは、独立ソフトウェア・ベンダ（ＩＳＶ）のような別個の場合もあるし、または上述した１つ以上のエンティティの一部である場合もある。何らかのインフラストラクチャ上で本発明によって管理されるサービスを提供したいエンティティは、当該サービスについての記述をインフラストラクチャに提供する。この記述は、抽象的である場合も具体的である場合もあり、サービスの組織と、提供されるべきサービスの表示と、サービスの運用を支配するポリシーとを含む。

図３は、コンピューティング・ユーティリティの高レベル図を示す。最上層は、コンピューティング環境と呼ばれる、プロビジョンされるサービスである。コンピューティング環境は、サーバ、オペレーティング・システム、アプリケーション、およびミドルウェアなどのハードウェアおよびソフトウェア・リソースを含む。各コンピューティング環境は、プロビジョンおよび管理リソース・サービス（ＰＭＲＳ）と呼ばれる、呼び出されてそのリソースをプロビジョンおよび管理するためのサービスを有する。ＰＭＲＳは、別個の発明である整理番号ＹＯＲ９２００３０５８８ＰＣＴ１の「コンピューティング・ユーティリティのためのコンピューティング環境のコンポーネント化された自動プロビジョニングおよび管理」に詳細に記載されている。最下層は、顧客に使用可能なホストとされるセンタのリソースを表す。ベース・リソースとは、アトミックなリソースであって、すなわち、他のリソースに分解できないリソースのことである。各ベース・リソース型は、ベース・リソース・ライブラリ・サービス（ＢＲＬＳ）と呼ばれる、当該リソース型のインスタンスの予約および割り当てを提供するサービスを有する。ベース・リソースの定義は、サービス・プロバイダ次第である。したがって、ＢＲＬＳは、ソフトウェア・ライセンスのような単純なリソース、または、ハードウェア・プラットフォーム上にインストールされて実行されるオペレーティング・システムのような複雑なリソースを提供することができる。ベース・リソースを追加、除去、または修正すると、システムの全体的な容量が変化する。本発明は、ベース・リソースの数および型の両方が経時変化するものとする。ベース・リソースは、ベース・リソース・ライブラリ・サービス（ＢＲＬＳ）２０１のセットによって表される。図３は、４つのベース・リソース型を示す。すなわち、ＤＢ２（ＩＢＭ社の登録商標）ライセンス２０３、ｚＳｅｒｉｅｓ（ＩＢＭ社の登録商標）論理区画（ＬＰＡＲ）２０５、ｘＳｅｒｉｅｓ（ＩＢＭ社の登録商標）サーバ２０７、およびＡＩＸ（ＩＢＭ社の登録商標）ライセンス２０９である。ＢＲＬＳは、カタログ化、チェック・アウト（割り当て）、チェック・イン（割り当て解除）、および予約などの動作を提供する。ＢＲＬＳ２０３，２０５，２０７，および２０９へのインターフェースを、図４を参照してさらに詳細に説明する。

複合リソースは、１つ以上の他のリソース（他の複合リソースを含む）から構築されて、指定された機能を実行する。複合リソースは、それに関連する従属物のセットを有してもよい。複合リソースの一例は、ウェブ・サイトである。これは、いくつかのフロント・エンド・サーバと、バック・エンド・サーバと、ロード・バランサと、サーバのためのＩＰアドレスのセットと、ウェブ・サーバ・ソフトウェアと、データベース・ソフトウェアと、ソフトウェアに関連するライセンスとからなってもよい。複合リソースの機能を実施するために使用されるベース・リソースのセットは経時変化してもよいが、すべての複合リソースがこの特性を有していなくてもよい。コンピューティング環境は、複合リソースの１つの型である。

各コンピューティング環境に関連するのは、プロビジョンおよび管理リソース・サービス（ＰＭＲＳ）と呼ばれる、サービスを提供するために使用されるリソースをプロビジョンおよび管理するソフトウェアである。複合リソースを含むすべての各リソース型は、当該型のリソースをどのように作成するか、およびリソースのインスタンスをどのように管理するかについての知識をカプセル化するＰＭＲＳを有する。プロビジョニングとは、リソースをコンピューティング環境へ割り当てて、サービス内での使用のために構成する行為を指す。プロビジョニング行為は、ベース・リソースを複合体に組み立てることと、ネットワーク装置を構成することと、オペレーティング・システム、アプリケーション・ソフトウェア、モニタ、およびユーザ・アカウントをインストールすることとを含む。リソースを管理することは、容量を追加またはリソース・インスタンスから容量を除去するような行為を含んでもよい。図３は、ＤＢ２（ＩＢＭ社の登録商標）２１３、リナックス（Ｌｉｎｕｘ）２１５、およびウェブ・サイト２１７というＰＭＲＳを示す。ＰＭＲＳは、整理番号ＹＯＲ９２００３０５８８ＰＣＴ１の「コンピューティング・ユーティリティのためのコンピューティング環境のコンポーネント化された自動プロビジョニングおよび管理」という発明に詳細に記載されている。

図３の中間層は、ベース・リソース分配サービス（ＢＲＤＳ）２１９である。その仕事は、各ドメインに対してサービス・プロバイダが現在有する合意に基づいて、サービス・プロバイダのリソースを効果的なやり方でそのドメインに対して割り当てることである。ドメインは、回想的に組織化されており、あるドメインは他のサブ・ドメインである。ＢＲＤＳは、どのリソースのセットがどのドメインに対して使用可能かを特定して、リソースに制限がある場合にビジネス・ポリシーに基づいて自動的にこれらのリソースを再分配する。これは、コンピューティング環境２１１（ＰＭＲＳ）およびリソース２０１（ＢＲＬＳ）と対話する。リソースは、コンピューティング環境に対して即座に割り当てられてもよいし、または将来的に割り当てられてもよい。将来のリソース割り当ての約束は、予約という。本発明は、コンピューティング環境に割り当てられたリソースは、その割り当て期間中は、当該コンピューティング環境専用のものとする。

ベース・リソース・ライブラリ・サービス
リソースは、プールに常駐し、プールは、型毎に定められてもよい。リソース・プールは、パブリックであっても、プライベートであってもよい。パブリック・リソース・プールは、どのドメインもそこからリソースを割り当ててもよいリソース・プールである。プライベート・リソース・プールは、顧客のドメインのサブ・セットに制限される。プライベート・プールは、リソースを顧客ドメインのサブ・セット専用とするために使用される。例えば、プライベート・プールは、一人の顧客のために複数のドメインで使用されるリソースを保持することもできよう。顧客が所有するがサービス・プロバイダにその管理をお願いしたいリソースについて、そのようなプールを使用してもよいだろう。各リソースは、それが生じたホーム・プールを有しており、これはパブリックであっても、プライベートであってもよい。ホーム・プールは、リソースが割り当てられるかまたは予約される場合に、変化しない。割り当てられていないリソースのグループは、フリー・プールと呼ばれる。

図４は、ベース・リソース・ライブラリ・サービス３１０（ＢＲＬＳ）の動作の一例を示す。システム内の各ベース・リソースは、ライブラリ、すなわちＢＲＬＳ３１０によって表され、これは、カタログ化、チェック・アウト（割り当て）、チェック・イン（割り当て解除）、および事前予約などの情報を提供する。ＢＲＬＳは、リソース型のインスタンスについてのホーム・プールとしての役割を果たし、これはパブリックであっても、プライベートであってもよい（パブリック・リソース・プールまたはプライベート・リソース・プールを表わしてもよい）。各ＢＲＬＳ３１０は、コレクタと関連付けられている。各ＢＲＬＳ３１０は、リソースを取得、予約、および返すためにシステムによって使用されるリソース動作３３０と、ＢＲＤＳ２１９にとって使用可能なリソースを管理するために使用されるカタログ動作３４０という２つの型のインターフェースを有する。提供されるリソース動作３３０は、Ｒｅｓｅｒｖｅ，ＣａｎｃｅｌＲｅｓｅｒｖａｔｏｎ，ＣｈｅｃｋＩｎ，ＣｈｅｃｋＯｕｔ，ＥｘｔｅｎｄＲｅｓｅｒｖａｔｉｏｎ，およびＱｕｅｒｙである。

Ｒｅｓｅｒｖｅ（ｎｕｍ−ｉｎｓｔａｎｃｅｓ，ｓｅｌｅｃｔｉｏｎ−ｓｐｅｃ，ｓｔａｒｔ ｔｉｍｅ，ｄｕｒａｔｉｏｎ）−＞ｒｅｓｅｒｖａｔｉｏｎ−ｉｄｓ
この要求は、顧客コンピューティング環境のためにＢＲＤＳ２１９によって発行されて、リソースを予約する。
入力：
ｎｕｍ−ｉｎｓｔａｎｃｅｓは、所望するインスタンスの数である。
ｓｅｌｅｃｔｉｏｎ−ｓｐｅｃは、ＢＲＬＳ３１０によってサポートされた所望の属性の仕様である。
ｓｔａｒｔ ｔｉｍｅ 指定されていなければ、どのようなインスタンスでもこの要求を満たすために使用されてもよい。
ｓｔａｒｔ ｔｉｍｅは、即時または事前予約用であってもよいだろう。
出力：
ｒｅｓｅｒｖａｔｉｏｎ−ｉｄｓ［］。当該要素は、リソース予約チケットであって、リソース・インスタンスにつき１つで、ｎｕｍ−ｉｎｓｔａｎｃｅｓまでである。これらは、予約時にインスタンスにマッピングする必要はない。言い換えれば、ライブラリは、そのリソースをオーバー・ブッキングしてもよい。

ＣｈｅｃｋＯｕｔ（ｒｅｓｅｒｖａｔｉｏｎ−ｉｄｓ）−＞ｒｅｓｏｕｒｃｅ−ｈａｎｄｌｅ
この要求は、顧客コンピューティング環境のためにＢＲＤＳ２１９によって発行されて、リソースを割り当てる。
入力：
Ｒｅｓｅｒｖｅによって発行されたｒｅｓｅｒｖａｔｉｏｎ−ｉｄｓ
出力：
ｒｅｓｏｕｒｃｅ−ｈａｎｄｌｅ。リソース・インスタンスの識別子である。リソースのインスタンスが提供できない場合には、特別の値に設定される。

ＣｈｅｃｋＩｎ（ｒｅｓｏｕｒｃｅ−ｈａｎｄｌｅ）
この要求は、顧客コンピューティング環境のためにＢＲＤＳ２１９によって発行されて、リソースを返す。
入力：
ＣｈｅｃｋＯｕｔによって発行されたｒｅｓｏｕｒｃｅ−ｈａｎｄｌｅ

ＥｘｔｅｎｄＲｅｓｅｒｖａｔｉｏｎ（ｒｅｓｏｕｃｅ−ｈａｎｄｌｅ，ｅｎｄ ｔｉｍｅ）
この要求は、顧客コンピューティング環境のためにＢＲＤＳ２１９によって発行されて、現在保持されたリソースについての予約を延長する。
入力：
ＣｈｅｃｋＯｕｔによって発行されたｒｅｓｏｕｒｃｅ−ｈａｎｄｌｅ
ｅｎｄ ｔｉｍｅ：リソースが返されるであろう時点
出力：
Ａｃｃｅｐｔ：リソース予約は延長できる。
Ｒｅｊｅｃｔ：リソースは返される。

Ｑｕｅｒｙ（ｓｅｌｅｃｔｉｏｎ−ｓｐｅｃ）−＞ａｖａｉｌａｂｉｌｉｔｙ−ｄａｔａ
この要求は、顧客コンピューティング環境のためにＢＲＤＳ２１９によって発行されて、リソースを返す。
入力：
ｓｅｌｅｃｔｉｏｎ−ｓｐｅｃは、ＢＲＬＳ３１０によってサポートされた所望の属性の仕様である。
これは、クエリの範囲を限定するために使用される。
これは、特定のインスタンスを参照するためにリソース・ハンドルを含んでもよい。
出力：
ａｖａｉｌａｂｉｌｉｔｙ−ｄａｔａ［］。当該要素は、インスタンスが予約用に使用可能であることを示す構成である。

ＣａｎｃｅｌＲｅｓｅｒｖａｔｉｏｎ（ｒｅｓｅｒｖａｔｉｏｎ−ｉｄ）
この要求は、顧客コンピューティング環境のためにＢＲＤＳ２１９によって発行されて、予約を取り消す。取り消しを受信後、リソースは、他のコンピューティング環境によって割り当ておよびチェック・アウトされるために使用可能である。
入力：
Ｒｅｓｅｒｖｅによって発行されたｒｅｓｅｒｖａｔｉｏｎ−ｉｄ

カタログ動作
カタログ動作３４０は、管理者３２０または他の管理機構に提供されて、ＢＲＬＳ３１０によって管理されるリソース・プールを修正する。また、リソース発見機構がこれらの動作を使用して、この処理を自動化することもできよう。提供される動作は、Ａｄｄ，Ｒｅｍｏｖｅ，Ｕｐｄａｔｅ，Ｑｕｅｒｙ，およびこれらの動作の任意の組み合わせを含む。

Ａｄｄ（ｒｅｓｏｕｒｃｅ−ｉｄｅｎｔｉｆｉｅｒ，ｉｎｓｔａｎｃｅ−ｄａｔａ）
この要求は、リソース・インスタンスをＢＲＬＳ３１０に追加するために発行される。
入力：
ｒｅｓｏｕｒｃｅ−ｉｄｅｎｔｉｆｉｅｒは、リソース識別子であって、上記ハンドルと同一であっても同一でなくてもよい。
ｉｎｓｔａｎｃｅ−ｄａｔａは、ｓｅｌｅｃｔｉｏｎ−ｓｐｅｃを介してリソースを選択するために使用できる属性値の集まりである。

Ｒｅｍｏｖｅ（ｒｅｓｏｕｒｃｅ−ｉｄｅｎｔｉｆｉｅｒ）
この要求は、ＢＲＬＳ３１０からリソース・インスタンスを除去するために発行される。
入力：
ｒｅｓｏｕｒｃｅ−ｉｄｅｎｔｉｆｉｅｒは、リソース識別子である。

Ｑｕｅｒｙ（ｓｅｌｅｃｔｉｏｎ−ｓｐｅｃ）−＞ｒｅｓｏｕｒｃｅ−ｉｄｅｎｔｉｆｉｅｒ［］
この要求は、ＢＲＬＳ３１０で登録されたリソース・インスタンスを検索するために使用される。
入力：
ｓｅｌｅｃｔｉｏｎ−ｓｐｅｃは、ＢＲＬＳ３１０によってサポートされた所望の属性の仕様である。
これは、クエリの範囲を限定するために使用される。
これは、リソース識別子を含んでもよい。
出力：
ｒｅｓｏｕｒｃｅ−ｉｄｅｎｔｉｆｉｅｒ［］は、ｓｅｌｅｃｔｉｏｎ−ｓｐｅｃを満足させるリソース識別子のリストである。

Ｑｕｅｒｙ（ｒｅｓｏｕｒｃｅ−ｉｄｅｎｔｉｆｉｅｒ）−＞ｉｎｓｔａｎｃｅ−ｄａｔａ
この要求は、ＢＲＬＳ３１０で登録されたリソース・インスタンスを検索するために使用される。
入力：
ｒｅｓｏｕｒｃｅ−ｉｄｅｎｔｉｆｉｅｒは、リソース識別子である。
出力：
ｉｎｓｔａｎｃｅ−ｄａｔａは、もしあれば、このインスタンスについて登録された属性値の集まりである。

Ｕｐｄａｔｅ（ｒｅｓｏｕｒｃｅ−ｉｄｅｎｔｉｆｉｅｒ，ｕｐｄａｔｅ−ｄａｔａ）−＞ｉｎｓｔａｎｃｅ−ｄａｔａ
この要求は、ＢＲＬＳ３１０で登録されたリソース・インスタンスを修正するために使用される。

入力：
ｒｅｓｏｕｒｃｅ−ｉｄｅｎｔｉｆｉｅｒは、リソース識別子である。
ｕｐｄａｔｅ−ｄａｔａは、リソースに適用されるべき、またはリソースに関して登録されるべき新規の情報である。
出力：
Ｉｎｓｔａｎｃｅ−ｄａｔａは、もしあれば、このインスタンスについて登録された属性値の集まりである。

ベース・リソース分配サービス
図５は、ベース・リソース分配サービス（ＢＲＤＳ）２１９のコンポーネントの一例を示す。ＢＲＤＳ２１９は、様々なコンピューティング環境に渡ってベース・リソースをどのように分配するかを決定する。ＢＲＤＳ２１９は、コレクタ４２０，４２２，４２４，４２６，４２８と、アービタ４３０という、２つの型のコンポーネントを含む。ドメインは、少なくとも１つのコレクタに関連付けられている。各コンピューティング環境において、上述のポリシーと、当該コンピューティング環境のために予約されたリソースのリストを含む１つのコレクタがある。

アービタ
アービタは、コンピューティング環境内でリソースをどのように分割するかについて決定する。これは、現在または将来の割り当て（予約）の両方で動作する。リソースは、コンピューティング環境に対して受動的に割り当てられても、能動的の割り当てられてもよい。アービタは、顧客のコンピューティング環境からの要求を満たすにはフリーのリソースが十分でない場合に、参照することができる。アービタを周期的に使用して、リソース割り当てを最適化することもできる。リソースに制約がある場合には、アービタは、コンピューティング環境からリソースを回収してもよい。アービタの動作についての詳細は、別個の発明である整理番号ＹＯＲ９２００３０５８９ＵＳ１の「コンピューティング・ユーティリティ・システムにおけるアービトレーションのための装置」にある。

コレクタ
コレクタは、１つ以上のコンピューティング環境に割り当てられたリソースのセットを表す。各コンピューティング環境のルート・ドメインは、関連コレクタを有する。コレクタは、例えば、組織内の部署を表すためにネストされてもよい。この構成により、コンピューティング環境のサブ・セット間のリソース共有が可能となり、実質的に、これらのドメインについてのコンピューティング・ユーティリティ・モデルを再現する。コンピューティング・ユーティリティは、複数の組織に対してリソースをプロビジョンでき、複数の組織に接続される（各組織のルート・ドメイン）コレクタを、ルート・コレクタと称する。図５は、２つのドメインを有する１つのルート・コレクタ４２０を示しており、それらドメインのうちの１つは２つのサブ・ドメインを有する。２つのメインドメインは、会社Ａおよび会社Ｂを表すＣｏｌ−Ａ ４２４およびＣｏｌ−Ｂ ４２２である。Ｃｏｌ−Ａ ４２４は、部署ＸおよびＹを表す２つのサブ・ドメインＣｏｌ−Ｘ ４２６およびＣｏｌ−Ｙ ４２８を有する。図５には、ＰＭＲＳ−Ｘ ４９６、ＰＭＲＳ−Ｙ ４９８、およびＰＭＲＳ−Ｂ ４９５という３つのＰＭＲＳが示されている。コレクタは、これらの各コンピューティング環境に関連付けられている。加えて、ＢＲＤＳ２１９は、コレクタ４２０も有する。

図５は、パブリックおよびプライベート・リソース・プールを示す。パブリックＢＲＬＳは、ＢＲＤＳ２１９内のルート・コレクタに関連付けられている。プライベートＢＲＬＳは、ＢＲＤＳ２１９内のルート・コレクタ以外のコレクタに関連付けられている。図５において、ＢＲＬＳ４８６，４８８，および４８２は、ルート・コレクタ４２０に関連付けられているのでパブリックであり、ＢＲＬＳ４８４は、ルート・コレクタ４２０ではないコレクタ４２４に関連付けられているプライベートである。

コレクタは、リソースをそのコレクションに追加またはそこから削除すること、およびコレクションの構成を変更することを行う状況を判断する顧客の取得ポリシーを実施する。コレクタの階層構造により、リソースを支配するローカルな（組織固有の）ポリシーを指定することができる。最も単純な取得ポリシー（すなわち、取得ポリシーなし）は、完全に要求主導である。すなわち、リソースは、要求およびリターン毎に、コレクタ階層を通じてＢＲＬＳ４８２（４８６，４８８）とＰＭＲＳ４９５との間で移動する。さらに複雑な取得ポリシーは、各コレクタにおけるサーバの最小数および最大数を指定してもよいだろう。これらの取得ポリシーは、要求フローをフィルタリングする。そのような取得ポリシーにより、コレクタは、そのドメインについての様々なフリー・プール（割り当てられたまたは予約されたリソースのキャッシュ）を維持でき、事実上、予測される要求に対してリソースを事前割当てができる。取得ポリシーについては、図９および１０の説明の際に説明する。

各ＢＲＬＳ４８２，４８４，４８６，４８８は、コレクタに関連付けられている。この関連付けにより、ＢＲＬＳによって表されるリソース・プールの共有範囲が定義される。例えば、ある組織がその部署のためにプライベート・リソース・プールを持ちたいと考えた場合、図５に示すような組織のコレクタ４２４に関連付けられたＢＲＬＳ４８４を有することになろう。リソースは、組織に関連付けられた（すなわち、組織のコレクタを先祖として有するコレクタに関連付けられた）顧客コンピューティング環境によってのみ、割り当てのために使用可能であろう

図６Ａは、サブ・ドメインである図２のスミス・ファスナー社のハードウェア１２３を示す。プロビジョニングの目的のために、ハードウェアには３つのアプリケーションＡｐｐ１ ４４０，Ａｐｐ２ ４５０，およびＡｐｐ３ ４６０が割り当てられている。この場合、すべての３つのアプリケーションは、リソースの同一のセットを共有することが許されている。図６Ｂは、コレクタ階層にマップをプロビジョニングするこの決定がどういうものかを示す。Ｃｏｌ１ ４７０は、ハードウェア１２３と関連付けられている。加えて、各アプリケーションは、ＰＭＲＳと、それに関連付けられたコレクタとを有する。Ａｐｐ１ ４４０は、Ｃｏｌ１ ４４１と、ＰＭＲＳ１ ４４２とを有し、Ａｐｐ２は、Ｃｏｌ２ ４５１と、ＰＭＲＳ２ ４５２とを有し、Ａｐｐ３は、Ｃｏｌ３ ４６１と、ＰＭＲＳ３ ４６２とを有する。本発明において、ＰＭＲＳは、最大１つのコレクタと関連付けられている。

図７は、複数のルート・コレクタ５１０および５２０を有するコンピューティング・ユーティリティの一例を示す。本発明は、１つのルート・コレクタを有するＢＲＤＳ２１９を説明する。当業者は、リソース・プールを論理的に分割して、各区画についてのＢＲＬＳを別個のルート・コレクタに関連付けることによって、本発明を拡張して複数のルートとすることができる。ルート・コレクタについてのＢＲＬＳは、同一のリソース型を関することができよう。図７は、２層のルート・コレクタ５１０および５２０を有するＢＲＤＳ２１９を示すことによってこの概念を示す。ルート・コレクタ５１０は、ＢＲＬＳ５３０および５３５を有する。ルート・コレクタ５２０は、ＢＲＬＳ５４０および５４５を有する。この場合、ＢＲＬＳ５３０は、ＢＲＬＳ５４０と同一のリソース型を管理している場合があろう。なお、代わりの実施において、同一型だが異なる関連付けのＢＲＬＳは、リソース・インスタンスの割り当ての基礎となる制約を有する単一のＢＲＬＳとして表すことができる。

図８は、コレクションおよびライブラリの一例である。各コンピューティング環境は、それに割り当てられるリソースのセットを有する。これらは、その対応するＰＭＲＳ６６０，６８０，および６９０においてのみ示され、コレクタまたはその先祖には示されていない。コレクタＣｏｌ−Ｙ６３２は、コンピューティング環境Ｙによって使用されるために割り当てられた「三角形」型の特別なリソースを有する。三角形のホーム・コレクションは、プライベート・ライブラリＢＲＬＳ−１ ６９０である。三角形は、ＰＭＲＳ Ｘ６６０およびＰＭＲＳ Ｙ ６８０にのみ割り当てることができる。コレクタＣｏｌ−Ａ６３０は、コンピューティング環境Ｃｏｌ−Ｘ６３３またはＣｏｌ−Ｙ６３３によって使用されるための「四角形」、「星」、および「円」型の特別なリソースを有する。これらは、それぞれ、対応する型のパブリックＢＲＬＳである６９２，６９４および６９６からのものである。これらのリソース・インスタンスは、コレクタＣｏｌ−Ｂ６２０による使用のために回収されることもできよう。図８のＢＲＬＳ６９０は、プライベートである。そのリソースは、コレクタ６３０，６３２，および６３３によって共有されている。図８において、ＢＲＬＳ６９２，６９４，および６９６は、パブリックである。

コンピューティング環境によってリソースが要求されると、ＢＲＤＳ２１９は３つの段階処理を踏む。第１の段階は、要求に応じた場合に、コンピューティング環境および、もしあればその中間祖先ノードについてのコレクタの取得ポリシーが満足されるかどうかを判断することである。ＢＲＤＳ２１９は、例えば、要求されたリソースが、サービス・プロバイダとの顧客の合意において規定されたものを超える場合には、要求を拒絶してもよい。よって、取得ポリシーは、この判断処理において考慮される制約のセットである。リソースを与えることができるとＢＲＤＳ２１９が判断した場合には、処理の第２段階は、要求を満たすであろうインスタンスの探索である。使用可能なインスタンスは、パブリックまたはプライベートＢＲＬＳ、もしくはコレクタ内で見つかる場合がある。どのインスタンスも使用可能でない場合は、分配ポリシーに従って、他のコンピューティング環境からインスタンスを再割り当てしてもよい。この要求がリソースのセットに対するものである場合には、ＢＲＤＳ２１９は、それに従ってその割り当てを調整する。要求が成功すれば、予約チケットのセットがＰＭＲＳへ返される。

ＢＲＤＳ２１９は、ＰＭＲＳからのリソース要求がない場合でも、コレクタの取得ポリシーを満足させるように試みることとなり、必要があればＢＲＬＳに対する要求を生成する。ＢＲＤＳ２１９が、取得ポリシーによるか、または明示的なリソース要求によるかを問わず、コレクタのために予約を行う。

コレクタおよびＢＲＤＳ２１９の説明に戻ると、予約開始時間が到来すると、ＢＲＤＳ２１９は、チケットをリソース・ハンドルに変換する。予約のリソース・ハンドルへの変換が失敗すると、予約は受け付けられない。チケットを保持するコレクタがＰＭＲＳに関連付けられている場合には、ＢＲＤＳ２１９は、ハンドルをコレクタに送付して、コレクタは、その後、ＰＭＲＳに提示する。図８において、コレクタ６３２が期限が到来した予約チケットを保持していた場合には、ＢＲＤＳはそれをリソース・ハンドルに変換して、コレクタ６３２へ返し、コレクタ６３２は、その後、リソース・ハンドルをＰＭＲＳ６８０へ渡すことになる。ＰＭＲＳ６８０は、その後、リソースをコンピューティング環境に構築することができる。そうでない場合には、予約を保持するコレクタは、ＰＭＲＳと関連付けられておらず、よって、ＢＲＤＳ２１９は、リソース・ハンドルをコレクタに送付する。図８において、以上のことが生じうるのは、コレクタ６３０が予約を保持していた場合である。

予約が期限切れになると、ＢＲＤＳ２１９は、それに関連付けられていたリソース・ハンドルを回収して、その貸主（ホーム・プールまたは中間コレクタ）へ返す。不変なのは、リソースは、それに対する予約がある場合にのみ（そして恐らくは、顧客がそれについて課金されている場合にのみ）、ホーム・プールからチェック・アウトされるか、または中間コレクタによって貸し出される。

予約を延長するためには、ＰＭＲＳ６６０は、既に使用しているリソースに関する選択仕様と共に要求をＢＲＤＳ２１９に発行する。ＢＲＤＳ２１９は、取得ポリシーおよび他の約束が許せば、ＢＲＬＳ（６９２，６９４，６９６、または６９０）と対話を行って、予約を延長する。すなわち、ＰＭＲＳ６６０は、ＢＲＬＳと直接通信するわけではない。

リソースがＰＭＲＳ６６０から返されると、その関連したコレクタの取得ポリシーは、それが親に返されるかを判断する。コレクタがリソースを保持する場合には、クライアントは、当該リソースについて構築を継続してもよい。リソースを保持する利点の１つとしては、要求に応じてより迅速に配置できるという点である。（例えば、リソースについての計測が既に構成されている）。リソースを返す場合には、その親の取得ポリシーは同様にチェックされる。リソースは、そのホーム・プール（ＢＲＬＳ）に関連付けられたコレクタには保持されていないので、その場合には、そのホーム・プールにチェック・インされる。例えば、ＢＲＬＳ６９０に関連付けられたリソースがコレクタＣｏｌ−Ａ６３０に返された場合には、コレクタに保持されるのではなく、ＢＲＬＳ６９０へ返されることになる。

なお、図８における６３０のようなコンピューティング環境のセットについてのリソース・プール（コレクタ階層における中間ノード）としての役割を果たすコレクタは、そのリソースを分配するために、ＢＲＬＳと同一の機能を必要とする。借りられたリソースを貸すのは、実質的にはライブラリである。このように、そのリソース・コレクションは、それに関連するＢＲＬＳとして表すことができる。コレクタとプライベートＢＲＬＳとの違いは、親またはコレクタ階層の他の部分による使用のためにリソースがコレクタから回収される場合があるという点である（リソースのホームＢＲＬＳがそれを許容する場合）。それに対して、プライベートＢＲＬＳ内のリソースは、関連コレクタおよびその子孫によってのみ使用できる。コレクタは、場合によっては、システムにおいて知られているすべてのリソース型の独自のコレクションを所有することができる。プライベートＢＲＬＳのように、コレクタのコレクションの実施は、そのリソース・インスタンスが割り当てられる基礎となる制約と共に、ホーム・プールからのリソースについての予約チケットを保持するコレクタの身元を有して、ＢＲＬＳの単一のセット内で達成できる。リソースが一旦コレクタまたはＰＭＲＳに割り当てられると、階層内のその位置は、リソースの属性となる。

図９は、要求の生成がＰＭＲＳによるか、またはコレクタの取得ポリシーの結果によるものかを問わず、リソース要求の際に取得ポリシーをチェックする処理の一例を示す。処理は、ボックス７１０で開始する。まず、７２０で要求がＰＭＲＳによって開始されたかどうかチェックする。そうであれば、７３０で、取得ポリシーのチェックがＰＭＲＳに関連付けられたコレクタで開始するように、現在のコレクションをＰＭＲＳに設定する。そうでなければ、７４０で、現在のコレクションの要求コレクタの親に設定する。これは、取得ポリシーがさらに多くのリソースを要求するコレクタによって要求が開始されたからである。次に、７５０で、ルート・コレクタにいるかどうかチェックする。ポリシーがルート・コレクタに至るまで満足されている場合には、リソースを取得でき、フローは、７８０で、使用可能なリソースを探索することを試みる手順へと進む。そうでなければ、７６０で、要求が現在のコレクションの取得ポリシーを違反しているかどうかチェックする。ポリシーが違反されているようであれば、７６５で、要求者がＰＭＲＳかどうかチェックする。そうであれば、７９５で、要求は拒否される。そうでなければ、取得ポリシーが違反されているようなコレクタまたはその子孫に対して既に割り当てられているリソースを使用して要求を満たすことが可能かもしれず、７９０で、取得ポリシーが違反されているようなコレクタがルートであるサブ・ツリーの一部で、アービトレーションが呼び出される。７６０のチェックに戻ると、現在のコレクションでポリシーが違反されていないようであれば、７７０で、現在のコレクションをたった今検査したコレクションの親に設定し、７５０でチェックを継続する。

図１０は、使用可能なリソースを探索する処理の一例である。処理は、ボックス８１０で開始する。まず、検索の開始点が決定される。ＰＭＲＳ８２０から要求が発していれば、検索のための開始コレクションは、ＰＭＲＳ８２７に関連付けられたコレクタである。そうでなければ、８２５で、要求が生じたコレクタの親とされる。リソース要求は、互いに異なる型のリソースのセットを指定することがあるので、８３０で、インスタンス毎のリソース型毎に１つの要素で、所望のリソースの記述リストが構築される。このリストを形成するには、リソース型毎に１つの要素として、同一の型の複数の要素は当該要素内で把握するなどといった、複数のやり方があることを、当業者は認識している。リストの各要素については、リソースに関して３つの選択肢がチェックされる。すなわち、コレクタに関連付けられたプライベートＢＲＬＳ、コレクタのコレクション、またはパブリックＢＲＬＳ（検索がルートに到達する場合）である。これらのチェックを各コレクタにおいて開始コレクタからルートまで繰り返す。これは、８４０で、最初に要求されたリソースＲＲを必要なリソースのリストから除去することによって行われる。ステップ８５０では、開始コレクションで開始する。８６０で、ＲＲ型の使用可能なリソースを有するＢＲＬＳがあるかどうかチェックする。その後、８６３で、コレクタがＲＲ型のリソースを有するかどうかをチェックする。有しない場合は、８６５で、処理がルート・コレクションにあるかどうかをチェックする。処理がルートにない場合は、８６７で、現在のコレクションの親へ移動して、８６０でチェックを継続する。ルートにあれば、要求されたすべてのリソースが使用可能なわけではないので、８７０でアービトレーションを使用して、リソースが使用可能かどうかを判断する。チェック８６０またはチェック８６３でリソースが見つかったら、８８０で、当該リソースについての情報が予約リストに追加される。次に、８９０で、要求されたすべてのリソースが探索されたかをチェックする。探索されていない場合には、８４０で、先頭の要素をリストからはずして、リソース探しを継続する。すべてのリソースが探索されたら、８９５で、探索されたリソースに対して予約要求が行われ、予約要求の結果は、使用可能なリソースの探索のための処理の終わりとして返される。

予約が失敗すると、範囲のルート・コレクタと共にアービトレーションが呼び出される。アービトレーションは、整理番号ＹＯＲ９２００３０５８９ＵＳ１の相互参照出願「コンピューティング・ユーティリティ・システムにおけるアービトレーションのための装置」の主題であり、本発明では、アービトレーションは「ブラック・ボックス」として扱う。アービトレーションが成功すると、リソースは予約され、チケットが要求者に返される。成功しなければ、要求は拒否される。アービトレーションが成功すると、他のドメインからリソースを回収しなければならない場合がある。コレクション・マネージャ、関連ライブラリおよび取得ポリシーによってかされる制約が、アービタに入力される。

ＢＲＤＳは、以下に列挙するリソース管理動作を提供する。

リソース管理動作
図１１は、ＢＲＤＳ２１９とＰＭＲＳ９２０との間の対話の一例を示す。ＢＲＤＳがＰＭＲＳに要求を行うための動作の１セット９３０と、ＰＭＲＳがＢＲＤＳに要求を行うための他のセット９４０とがある。リソースの割り当てには、５つの動作が関わる。すなわち、ＰＭＲＳは、９４０にあるように、リソースを要求、保持、または返し、ＢＲＤＳは、９３０にあるように、リソースを回収または提供する。ＰＭＲＳ９２０が追加のリソースが必要かまたは過剰なのでリソースを返す場合には、９４０のＲｅｑｕｅｓｔＲｅｓｏｕｒｃｅおよびＲｅｔｕｒｎＲｅｓｏｕｒｃｅインターフェースを使用する。ＰＭＲＳ９２０が最初の要求で指定された期間を超えてリソースを保持したい場合には、９４０のＲｅｔａｉｎＲｅｓｏｕｃｅを使用する。予め予約されたリソースが使用可能になった場合には、ＢＲＤＳ２１９は、９３０のＤｅｌｉｖｅｒＲｅｓｏｕｒｃｅインターフェースを使用して、リソースをＰＭＲＳ９２０に与える。回収リソース・インターフェース９３０は、ＰＭＲＳからリソースを除去する必要がある場合にはいつでも、ＢＲＤＳによって使用される。例えば、予め割り当てられていたリソースを取り消して、別のところへ再割り当てできるようにするという場合である。ＯｆｆｅｒＲｅｓｏｕｒｃｅインターフェース９３０は、ＰＭＲＳ９２０によって明示的には要求されてはいないがそのコンピューティング環境のポリシーで許容されている追加のリソースを使用可能にするために使用される。

ＲｅｑｕｅｓｔＲｅｓｏｕｒｃｅ（Ｒ，ｓｔａｒｔ−ｔｉｍｅ，ｄｕｒａｔｉｏｎ）
この要求は、顧客コンピューティング環境のためにＰＭＲＳ９２０によってＢＲＤＳ２１９へ発行されて、追加のリソースを要求する。ＢＲＤＳ２１９は、要求を拒絶することができる。
入力：
Ｒ［］は、構成のベクトルであって、リソース型毎に１つの要素である。各構成は、数多くの型のインスタンスおよびオプションの選択基準を含む。選択基準は、特定のインスタンスを指定するためのリソース・ハンドルを含んでもよい。
ｓｔａｒｔ ｔｉｍｅは、即時または事前予約用であってもよいだろう。
出力：
成功または失敗を示すリターン・コード
Ｒ’［］は、オプションのリターンである。失敗の場合に、使用可能なリソースを示すために設定されてもよい。Ｒ’の要素は、リソース・インスタンス毎に１つのリソース予約チケットであって、追加のリソースを取得するために引き換えられてもよい。
ｓｔａｒｔ ｔｉｍｅ’は、オプションのリターンである。失敗の場合に、使用可能なリソースを示すために設定されてもよい。設定されていれば、Ｒ’に適用し、そうでなければＲに適用する。

ＲｅｔｕｒｎＲｅｓｏｕｒｃｅ（Ｒ）
この要求は、顧客コンピューティング環境のためにＰＭＲＳ９２０によってＢＲＤＳ２１９へ発行されて、リソースを返す。ＢＲＤＳ２１９は、要求を受理する。
入力：
Ｒ［］は、返されるリソースについてのリソース識別子（ハンドルまたは予約チケット）のリストである。これらのリソースは、現在割り当てられているリソースまたは予約であってもよいだろう。
出力：
成功または失敗を示すリターン・コード。

Ｒｅｔａｉｎ Ｒｅｓｏｕｃｅ（Ｒ，ｅｎｄ ｔｉｍｅ）
この要求は、顧客コンピューティング環境のためにＰＭＲＳ９２０によってＢＲＤＳ２１９へ発行されて、先に付された時間とは異なる時間量分、リソースを保持する（リソースの予約を延長または修正する）。ＢＲＤＳ２１９は、要求を受理してもよいし、拒絶してもよい。
入力：
Ｒ［］は、保持されるリソースについてのリソース識別子（ハンドルまたは予約チケット）のリストである。これらのリソースは、現在割り当てられているリソースまたは予約であってもよいだろう。
ｅｎｄ ｔｉｍｅは、リスト内のリソースについて要求された新規の終了時間である。終了時間が未来でない場合には、要求は拒絶される。
出力：
成功または失敗を示すリターン・コード。

ＲｅｃｌａｉｍＲｅｓｏｕｒｃｅ（Ｒ）
この要求は、ＢＲＤＳ２１９によってＰＭＲＳ９２０へ発行されて、リソースのセットの割り当てまたは予約を取り消す。ＰＭＲＳ９２０は、リソースを解放する。
入力：
Ｒ［］は、構成のベクトルであって、リソース型毎に１つの要素である。各構成は、数多くの型のインスタンスおよびオプションの選択基準を含む。選択基準は、特定のインスタンスを指定するためのリソース・ハンドルまたは予約チケットを含んでもよい。コンピューティング環境は、当該基準に従って、回収すべきリソース・インスタンスを選択してもよい。
出力：
Ｒ’［］は、返されるリソースについてのリソース識別子（ハンドルまたは予約チケット）のリストである。Ｒ’は、回収されるリソースへの依存性のために無用となるであろうリソースを含むＲの拡張集合であってもよい。

ＯｆｆｅｒＲｅｓｏｕｒｃｅ（Ｒ，ｓｔａｒｔ−ｔｉｍｅ，ｄｕｒａｔｉｏｎ）
この要求は、ＢＲＤＳ２１９によってＰＭＲＳ９２０へ発行されて本コンピューティング環境のための追加のリソースの使用可能性を知らせる。ＰＭＲＳ９２０は、提供されたリソースを受理してもよいし、断ってもよい。リソースを受理するためには、ＰＭＲＳ９２０は、ＲｅｑｕｅｓｔＲｅｓｏｕｒｃ要求を発行する。
入力：
Ｒ［］は、使用可能な各リソース型のインスタンスの数を含むベクトルである。
ｓｔａｒｔ−ｔｉｍｅは、即時または事前予約用であってもよいだろう。
出力：
なし

ＤｅｌｉｖｅｒＲｅｓｏｕｒｃｅ（Ｒ）
この要求は、ＢＲＤＳ２１９によってＰＭＲＳ９２０へ発行されて、予め予約されたリソースがコンピューティング環境に対して割り当てられた旨を示す。
入力：
Ｒ［］は、タプルのリストであって、それぞれは、予約ＩＤと、対応のリソース・ハンドルとからなる。
出力：
なし

リソースを取得して顧客のコンピューティング環境へ分配するためには、ＢＲＤＳ２１９は、上述のＢＲＬＳ９１０，９１２，９１４，９１６の動作を呼び出す。

図１２は、通常動作中のＰＭＲＳ１０１０とＢＲＤＳ２１９との間の対話の一例を示す。図１２のＰＭＲＳは、リナックス・サーバのグループを表し、これらは可変サイズであってもよい。何らかのイベントによって、リナックス・サーバを表すＰＭＲＳ１０１が、ｘＳｅｒｉｅｓ（ＩＢＭ社の登録商標）リナックス・サーバおよび追加のＩＰアドレスのような追加のリソースが必要であることを認識する。ＲｅｑｕｅｓｔＲｅｓｏｕｃｅ１０１１を使用して、ＢＲＤＳ２１９に対してリソースを要求する。ＢＲＤＳ２１９は、図９および１０に記載の方法を使用して、リソースを割り当ておよび予約する。ＲｅｑｕｅｓｔＲｅｓｏｕｒｃｅ１０１１に応答して、予約チケットがＰＭＲＳ１０１０に返される。リソースが使用可能になると、ＰＭＲＳ１０１０は、ＤｅｌｉｖｅｒＲｅｓｏｕｒｃｅ１０１２を使用して通知される。ＰＭＲＳ１０１０内部での詳細な対話は、整理番号ＹＯＲ９２００３０５８８ＰＣＴ１の出願「コンピューティング・ユーティリティのためのコンピューティング環境のコンポーネント化された自動プロビジョニングおよび管理」に記載されている。

図１３は、新規の顧客（またはサービス）を既存のホスト・インフラストラクチャに追加する処理の一例を示す。この処理は、新規のリソースを既存のサービスに追加するのと同様である。本発明は、組織がサービス・プロバイダのサービスに加入して、さらに、組織内でのリソース共有のために、グループ内にコンピューティング環境を追加することができるようにする動作のセットがあることを前提としている。少なくとも、組織を追加するには、開始時間および合意期間ならびに取得および他のポリシーなどの、組織とサービス・プロバイダとの間の合意からの情報を供給する。具体的なコンピューティング環境については、コンピューティング環境型および設定も供給する。通常の動作中に、コンピューティング環境を制御するポリシーを、新規のポリシーの追加、既存のポリシーの除去、または既存のポリシーの更新によって修正できる。加えて、本発明は、合意が終了した場合に、ドメインおよび組織を除去するための動作があることを前提としている。新規のドメインを追加するには、クライアントは、ドメイン（サブ・ドメインを含む）の表示、ポリシー、およびドメインにプロビジョンされたコンピューティング環境のリストを明示する。

図１３において、コンピューティング環境型は、ウェブ・サイトである。ＢＲＤＳ２１９は、１つのルート・コレクタを有する。ネットワーク・ディスパッチャ・ライセンス用ＢＲＬＳ１１３０と、リナックス・サーバ（ハードウェアおよびソフトウェア）用ＢＲＬＳ１１３２、およびウェブスフィア（ＩＢＭ社の登録商標）用ＢＲＬＳ１１３４がある。新規の顧客要求１１０５が到達すると、新規のコレクション用のＰＭＲＳ１１８０が完全に動作するまで、ＢＲＤＳ２１９の新規顧客（ＮＣ）１１６０が、そのための新規のコレクタ１１５０（点線で示す）と、顧客情報用の配置ホルダとを作成する。新規の顧客要求１１０５は、インスタンス化されることになる正確な複合リソースを指定する。新規のコレクタを作成後、ＮＣ１１６０は、Ｒｅａｌｉｚｅ１１１１要求を正しい型のＰＭＲＳ１１８０へ送る。Ｒｅａｌｉｚｅは、ＢＲＤＳ２１９によって使用されて、新規のコンピューティング環境が要求された場合に既存のインフラストラクチャ上にリソースを構築するための予想されるプランのセットを得る。Ｒｅａｌｉｚｅは、整理番号ＹＯＲ９２００３０５８８ＰＣＴ１の別個の出願「コンピューティング・ユーティリティのためのコンピューティング環境のコンポーネント化された自動プロビジョニングおよび管理」に詳細に定義されている。Ｒｅａｌｉｚｅ１１１１要求の終わりに、ＢＲＤＳ２１９は、特定の型のコンピューティング環境を構築するのに使用可能なリソースの予想されるセットのリストを有する。これらのオプションすべては、ＮＣ１１６０オブジェクトに返されて、ＮＣ１１６０オブジェクトは、コレクタ１１５０をインスタンス化して、新規のインスタンスを管理し、コレクタ１１５０に対してリソースのための交渉を要求する。新規にインスタンス化されたコレクタ１１５０（ＢＲＤＳ）は、使用可能なリソースおよびポリシーに対してオプションを分析して、ライブラリＢＲＬＳ１１３０．１１３２，および１１３４とリソースについて交渉する。その後、すべてのリソースがポリシー内で取得できることを前提として、要求時間においてのサービスの構築がスケジュールされる。（リソースが取得できない場合には、新規の顧客１１０５要求は失敗に終わる）。リソース予約の開始時間が到来すると、ＢＲＤＳ２１９はリソースを取得して、リソース・ハンドルをＮＣ１１６０へ送り、ＮＣ１１６０は、Ｂｕｉｌｄ１１１２要求をＰＲＳ１１１０へ送る。供給されるポリシーの型の１つは、取得ポリシーであるが、他の必要なポリシーは、リソース型に固有であってもよく、この時に供給されることになろう。なお、ＰＭＲＳ１１８０は、ＰＲＳ１１０と、ＭＲＳ１１７０との論理的関連物である。ＰＭＲＳの詳細は、整理番号ＹＯＲ９２００３０５８８ＰＣＴ１の出願「コンピューティング・ユーティリティのためのコンピューティング環境のコンポーネント化された自動プロビジョニングおよび管理」に記載されている。Ｂｕｉｌｄ１１１２要求の結果、ＰＲＳ１１１０は、コンピューティング環境に関連付けられるようなＭＲＳ１１７０を作成する。この処理が完了すると、ＰＲＳ１１１０は、新規のＭＲＳ１１７０の識別子をＮＣ１１６０に返し、ＮＣ１１６０は、コレクタ１１５０を、コンピューティング環境についてのルートＭＲＳ１１７０の身元で更新する。

コレクタが一旦ハンドルを有すれば、図１３において点線によって示されるように、管理する新たなインスタンス化されたサービスに関連付けられる。代替実施形態例において、ＮＣにｂｕｉｌｄ１１１２要求をＰＲＳへ送らせる代わりに、ＮＣはＤｅｌｉｖｅｒＲｅｓｏｕｒｃｅ要求を送り、ＰＭＲＳは最初に送られるリソース要求はｂｕｉｌｄを示すことを理解してもよいだろう。

代替実施形態において、新規の顧客要求が到達した場合にＢＲＤＳが新規のコレクタをインスタンス化できるように、ＮＣの機能をコレクタに組み合わせることができる。新規のコレクタは、初期化の一部として、ＮＣに割り当てられたすべてのステップを経る。これらのステップの完了時に、ＮＣは完成し、サービスが動作可能となってもよい。ホストとされる環境が要求を満たす能力を持っていない場合もあり、その場合には、新規の顧客についての要求は拒絶されることになろう。先に示したように、このホストとされる環境は、何らかの他のホストとされる環境内にあるかもしれないリソースを取得および使用する能力がある。その結果、ホストとされる環境は、必要なリソースのすべてを有しては折らず、許容可能な条件のセットで、何らかの他のホストとされる環境からリソースを取得することができ、その後、新規の顧客に対する要求が拒絶されずに受理されることができる。他のホストとされる環境から取得したリソースは、本環境においてはまだＢＲＬＳとして表されることになる。ホストとされる環境が複数のホストとされる環境から来たＢＲＬＳを含む場合、取得ポリシーを内部リソースに対する外部リソースの使用を管理するために供給できるように、ＢＲＬＳの型が決められる。

図１４は、スミス・ファスナー社１２０のコンピューティング環境のセットのプロビジョニング目的のための分配の一例を示す。スミス・ファスナーは、どのサービスを組織内で使用したいか、および組織のどの部分が各サービスを保有（または加入）するかを決めなければならなかった。また、スミスは、リソースをそのドメインにどのように割り当てるか、およびどのような割り当ておよび分散ポリシーが各ドメイン用であるかを決めなければならなかった。このようなプロビジョニングの決定は、プロビジョンされたサービスをスミス・ファスナーのどの従業員が使用するようになるかということと交差するものである。ドメインおよびコンピューティング環境を作成する際の案内となる原則は、プロビジョンされる少なくとも１つのコンピューティング環境、確立される少なくとも２つのサブ・ドメイン、または少なくとも１つのコンピューティング環境と１つのサブ・ドメインがある場所にのみ、ドメインを挿入するということである。この原則により、サブ・ドメインが１つあるだけの長い列のドメインを回避することができる。スミス・ファスナー社１２０は、企業レベルアプリケーション１と、アプリケーション５という２つのアプリケーションをプロビジョンおよび制御する旨決定している。会計アプリケーションであるアプリケーション１２は、企業と、調査部１２１、財務部１２２、ハードウェア１２３、およびマーケティング１２４の各部で使用されることになっている。ハードウェア部は、各製品部門であるボルト１２７、ねじ１２８、およびヒンジ１２９が同一の工学設計アプリケーション９の独自のインスタンスを使用することを決定している。また、ヒンジ部門１２９は、２つの追加のアプリケーションであるアプリケーション１０およびアプリケーション１１を試しに使用している。マーケティングは、各第１地域１２５および第２地域１２６がマーケティング活動の管理のために同一のアプリケーションであるアプリケーション３の独自のインスタンスを使用することを決定している。マーケティングの第２地域１２６は、２つの別々の地域である北部１３０および南部１３１に分割されている。これらの各地域は、地域レベルでアプリケーション３に入力する情報を収集するために、アプリケーション４の独自のインスタンスを使用する。スミス・ファスナー１２０のリソース取得および分配ポリシーは、主要ドメインである調査１２１、財務１２２、ハードウェア１２３、およびマーケティング１２４がそれぞれタスクを達成するために必要なリソースを有することを保証している。加えて、マーケティング１２４および財務１２２は、４半期末および年度末間に、互いの再割り当ては認められないが、他の部署から再割り当てされたリソースを有することができる。しかしながら、他の部署が機能しなくなるほどの数多くのリソースを取ることは認められない。

これらすべての決定がコンピューティング環境を有するドメイン構造にマッピングされると、以下のようになる。ルート・ドメイン１２０は、Ａｐｐ０１ １５０と、Ａｐｐ１２ １５１と、Ａｐｐ０５ １５２という３つのアプリケーションを有する。また、ルート・ドメイン１２０は、調査１２１、財務１２２、ハードウェア１２３、およびマーケティング１２４という４つのサブ・ドメインを有する。調査１２１と財務１２２というサブ・ドメインは、それぞれ、１つのアプリケーションを使用する。この場合、それぞれ、同一のアプリケーションＡｐｐ１２ １５５およびＡｐｐ１２ １５６の別々のインスタンスを有する。本発明は、ユーザの観点から、ドメイン間でアプリケーションの単一のインスタンスの共有を禁止するものではない。例えば、図１４において、Ａｐｐ０１は、調査および財務の両方によって使用できると共に、ルート・ドメインによっても使用できる。しかしながら、プロビジョニング（およびプロビジョニングの管理）の観点から、アプリケーションの各インスタンスは、組織内において単一のプロビジョニング点を有する。図面の詳細な説明に戻る。ハードウェア・ドメイン１２３は、３つのサブ・ドメインと、それに関連する単一のアプリケーションとを有する。ハードウェア１２３のサブ・ドメインは、ボルト部門１２７、ねじ部門１２８、およびヒンジ部門１２９である。ハードウェアに関連したアプリケーションは、Ａｐｐ１２ １５７である。マーケティング・ドメイン１２４は、それに関連する２つのサブ・ドメインを有する。アプリケーションは、Ａｐｐ１２ １５３およびＡｐｐ０３ １５４であり、ドメインは、第１地域１２５および第２地域１２６である。これらの地域のそれぞれは、Ａｐｐ０３の独自のインスタンスを有する。第１地域１２５は、Ａｐｐ０３ １６１を使用し、第２地域１２６は、Ａｐｐ０３ １５８を使用する。第２地域１２６は、さらに北部１３０と南部１３１とに分割され、第２地域１２６の各サブ・ドメインは、Ａｐｐ０４の独自のコピーを有し、北部はＡｐｐ０４ １６３を、南部はＡｐｐ０４ １６２を使用する。

図１５は、図１４のコンピューティング環境およびドメイン構造から生じたコレクタ階層を示す。コレクタ階層を作成するには、ルート・ドメインから始めて、コレクタを挿入する。次に、ドメイン・ツリーのルート・ドメインを検査して、コンピューティング環境が１つしかないかどうかを調べ、もしそうならば、このコンピューティング環境についてのＰＭＲＳを挿入して終了する。そうでなければ、ルート・ドメインは、１つより多くのコンピューティング環境またはサブ・ドメインを有している。ルート・ドメインの各今ピューティング環境について、コレクタおよびＰＭＲＳを挿入する。残りのサブ・ドメインは、ドメイン処理リストに置く。このアルゴリズムを、ドメイン処理リストが空になるまで、ドメイン処理リスト上の各ドメインに適用する。基本的には、このアルゴリズムは、ドメインのルート・ドメインおよびコンピューティング環境ツリーで開始する第１の検索で使用される。このアルゴリズムが図１４に適用されると、コレクタ階層は図１５の結果となる。ＰＭＲＳの型が決められ、図１５において、ＰＭＲＳ名の末尾２桁は、その型を表しており、ＰＭＲＳ０１は、図１４のＡｐｐ０１のインスタンスを管理するＰＭＲＳである。図１５の詳細な説明に戻ると、コレクタＳＦＣ１３２０が挿入される。なぜならば、図１４のスミス・ファスナー社１２０は、１つより多くのアプリケーションを有しているからである。図１４において、スミス・ファスナー１２０は、３つのアプリケーションを有している。したがって、アプリケーション１，１２，５であって、コレクタＰＭＲＳ構造が挿入されていた。アプリケーション１に関しては、これはコレクタ１３５２およびＰＭＲＳ０１ １３７４であり、アプリケーション１２に関しては、これはコレクタ１３５１およびＰＭＲＳ０１２ １３７３であり、アプリケーション５に関しては、これはコレクタ１３５０およびＰＭＲＳ０５ １３７１である。次に、アルゴリズムをスミスのサブ・ドメインに適用する。なお、図１４のサブ・ドメインである調査１２１および財務１２２の鎖には１つのアプリケーションであるアプリケーション１２しかない。その結果、各サブ・ドメインについて、コレクタおよびＰＭＲＳ構造が階層に挿入される。図１４の調査１２１については、コレクタ１３２１およびＰＭＲＳ１２ １３７０が挿入され、図１４の財務１２２については、コレクタ１３２２およびＰＭＲＳ１２ １３７２が挿入される。図１４において、ハードウェア１２３およびマーケティング１２４は、複数のサブ・ドメインおよびアプリケーションを有する。次に、アルゴリズムを、ハードウェアおよびマーケティングのサブ・ドメインに適用する。ハードウェアについては、コレクタ１３２３が挿入され、マーケティングについては、コレクタ１３２４が挿入される。図１４において、ハードウェアは、ボルト１２７、ねじ１２８、およびヒンジ１２９という３つのサブ・ドメインと、それに関連するアプリケーション１２という１つのアプリケーションとを有する。よって、ＰＭＲＳコレクタ階層が、適用のためにコレクタ１３２３に追加される。図１４において、ハードウェア・ドメインのうちの２つであるボルト１２７およびねじ１２８は、それに関連する１つのアプリケーションしかない。図１５において、コレクタＰＭＲＳ構造が、これらのサブ・ドメインのそれぞれに関連付けられる。ボルトについては、コレクタ１３２７およびＰＭＲＳ０９ １３７６であり、ねじについては、コレクタ１３２８およびＰＭＲＳ０９ １３７７である。図１４において、ハードウェア１２３の第３の部門であるヒンジ１２９は、それに関連する３つのアプリケーションを有するので、図１５において、コレクタ１３２９が挿入される。図１４において、マーケティングは、２つのアプリケーションと、２つのサブ・ドメインとを有する。これらのアプリケーションは、Ａｐｐ１２ １５３およびＡｐｐ０３ １５４であり、サブ・ドメインは、第１地域１２５および第２地域１２６である。図１５において、コレクタＰＭＲＳ階層が各アプリケーションに挿入された。これらは、アプリケーション１２については、コレクタ１３５４およびＰＭＲＳ１２ １３７８であり、アプリケーション３については、コレクタ１３５５およびＰＭＲＳ１２ １３７９である。図１４において、１つのサブ・ドメインである北部１３０は、Ａｐｐ０４ １６３という、それに関連するアプリケーションを１つしか有していない。図１５において、コレクタＰＭＲＳ階層が挿入される。これは、コレクタ１３３０およびＰＭＲＳ１３８４である。図１４において、マーケティングの他方のサブ・ドメインである第２地域１２６は、１つのアプリケーションと、２つのサブ・ドメインとを有する。その結果、図１５において、コレクタであるコレクタ１３２６が挿入される。図１４のヒンジ１２９に戻ると、Ａｐｐ１１ １６４、Ａｐｐ０９ １６５、およびＡｐｐ１０ １６６という、それに関連する３つのアプリケーションを有する。図１５において、コレクタＰＭＲＳ階層が各アプリケーションに挿入される。これらは、アプリケーション１１については、コレクタ１３５６およびＰＭＲＳ１１ １３８１であり、アプリケーション９については、コレクタ１３５７およびＰＭＲＳ１１ １３８２であり、アプリケーション１０については、コレクタ１３５８およびＰＭＲＳ１１ １３８３である。最後に、図１４の第２地域１２６を検査する。これは、１つのアプリケーションＡｐｐ０３ １５８と、２つのサブ・ドメインを有する。図１４において、北部１３０および南部１３１という各サブ・ドメインは、アプリケーション４のインスタンスを有する。図１５において、ＰＭＲＳコレクタ階層であるコレクタ１３９およびＰＭＲＳ０３ １３８６をアプリケーション３に挿入する。サブ・ドメインに関しては、コレクタＰＭＲＳ階層をそれぞれに挿入した。なぜならば、１つしかアプリケーションがないからである。これは、北部については、コレクタ１３３０およびＰＭＲＳ０４ １３８４であり、南部については、コレクタ１３３１およびＰＭＲＳ０４ １３８５である。これで、コレクタ・コンピューティング環境階層の構築が完了し、本発明によってリソースの階層的な管理が提供するために使用されることになる。

コレクタ・ツリーは、顧客にサービスをプロビジョンする際に最大限の柔軟性が可能となるように設計されている。これにより、プライベートＢＲＬＳがツリー内の各コレクタに関係付けられることができる。各コレクタは、自身の取得および分配ポリシーを有することができる。これにより、会社は、この場合はスミス・ファスナーであるが、そのコンピューティング・リソースの分配をさらにきめ細かく制御することができるようになる。すべての取得および分配ポリシーが同一であり、すべてのリソースがパブリックＢＲＬＳに保持される場合には、このツリーは必要なく、平らなツリーで十分であろう。階層を使用することにより、組織内でのリソースの分配および使用に対してさらにきめ細かな制御が得られる。

本発明は、相互参照出願である「コンピューティング・ユーティリティのためのコンピューティング環境のコンポーネント化された自動プロビジョニングおよび管理」、および「コンピューティング・ユーティリティ・システムにおけるアービトレーションのための装置」に記載された発明と共に使用すると有用である。使用の一例は、これらの発明を組み合わせて、オン・デマンド・サービスを顧客の集合に提供することである。

本発明について説明した変更態様は、各特定の応用にとって望ましい任意の組み合わせにおいて実現可能である。よって、本明細書に記載された特定の限定または実施形態の拡張あるいはその両方は、ある特定の応用には特に利点があるかもしれないが、すべての応用にとって使用される必要はない。また、本発明の１つ以上の概念を含む方法、システム、または装置あるいはそのすべてにおいて、限定がすべて実施される必要はない。

本発明は、ハードウェア、ソフトウェア、またはハードウェアおよびソフトウェアの組み合わせで実現できる。本発明に係る視覚化ツールは、１つのコンピュータ・システムにおいて一元的なやり方で、または、互いに異なる要素が、相互接続されたコンピュータ・システムに渡って分散されるような分散的なやり方で、実現できる。どのような種類のコンピュータ・システム、または本明細書に記載の方法または機能あるいはその両方を実行するために適応された他の装置も好適である。ハードウェアおよびソフトウェアの典型的な組み合わせは、汎用コンピュータ・システムであって、ロードおよび実行されると本明細書に記載の方法を実行するようにコンピュータ・システムを制御するコンピュータ・プログラムを有するものが挙げられよう。本発明は、本明細書に記載の方法の実施を可能にするすべての特徴を備えており、コンピュータ・システムにロードされるとこれらの方法を実行するコンピュータ・プログラム製品に組み込むこともできる。

本件のコンピュータ・プログラム手段またはコンピュータ・プログラムは、情報処理能力を有するシステムに対して特定の機能を直接もしくは他の言語、符号、または異なる物質形式の複製に変換後のいずれかに実行させるように意図された命令のセットの、任意の言語、符号、または表記での任意の表示を含む。

よって、本発明は、上述の機能を生じさせるためのコンピュータ読み取り可能なプログラム・コード手段を内部に実施するコンピュータ使用可能な媒体を備える製品を含む。製品内のコンピュータ読み取り可能なプログラム・コード手段は、コンピュータに対して本発明の方法のステップを生じさせるコンピュータ読み取り可能なプログラム・コード手段を備える。同様に、本発明は、上述の機能を生じさせるためのコンピュータ読み取り可能なプログラム・コード手段を内部に実施するコンピュータ使用可能な媒体を備えるコンピュータ・プログラム製品として実施されてもよい。コンピュータ・プログラム製品内のコンピュータ読み取り可能なプログラム・コード手段は、コンピュータに対して本発明の１つ以上の機能を生じさせるコンピュータ読み取り可能なプログラム・コード手段を備える。さらに、本発明は、機械によって読み取り可能で、本発明の１つ以上の機能を生じさせるための方法ステップを行うために機械によって実行可能な命令プログラムを明確に実施するプログラム記憶装置として実施されてもよい。

なお、以上は、本発明のより適切な目的および実施形態のいくつかを概説したものである。本発明は、多くの適用のために使用されてもよい。よって、特定の仕組みおよび方法について説明したが、本発明の意図および概念は、他の仕組みおよび方法にも好適かつ適用可能である。開示された実施形態に対する修正が、本発明の精神および範囲から逸脱することなく生じうることは、当業者にとって明確であろう。説明した実施形態は、本発明のより顕著な特徴および応用のいくつかを単に例示にするに過ぎないと解釈されるべきである。開示された発明を違うやり方で適用するか、または当業者に周知のやり方で本発明を修正することによって、利益となる他の結果を得ることができる。

ホストとされる環境のコンポーネントを示す。 企業の構成の一例を示す。 本発明に係るコンピューティング・ユーティリティ・システムにおけるコンポーネントを示す。 本発明に係るコンピューティング・ユーティリティ管理におけるライブラリ・コンポーネントの動作を示す。 本発明に係るコンピューティング・ユーティリティ内のコレクタの階層を示す。 Ａは本発明に係る企業のユニットに割り当てられるアプリケーションを示す。Ｂは本発明に係るプロビジョニングのために図６Ａのアプリケーションはどのように構成できるかを示す。 本発明に係る複数のルート・コレクタを有するコンピューティング・ユーティリティを示す。 本発明に係る集まりへのリソース・プールの関連付けを示す。 本発明に係るコンピューティング・ユーティリティ内で取得ポリシーをどのようにチェックするかを示す。 コンピューティング・ユーティリティ内で使用可能なリソースをどのように見つけるかを示す。 本発明に係るコンピューティング・ユーティリティにおいてプロビジョンおよび管理リソース・サービス（ＰＭＲＳ）とベース・リソース分配サービス（ＢＲＤＳ）との間の対話を示す。 本発明に係るコンピューティング・ユーティリティの動作中にコレクタがどのように機能するかを示す。 本発明に係るコンピューティング・ユーティリティにどのように新規サービスを追加するかを示す。 本発明に係る企業内に置けるアプリケーション割り当てを示す。 本発明に係る、図１４の割り当てに関するコレクタの階層を示す。

Claims (22)

1. エンティティに対して少なくとも１つのドメインの階層的な管理を提供するためのプログラムであって、コンピュータに、
   前記少なくとも１つのドメインの階層的な表示を取得するステップであって、前記表示は、管理すべきコンピューティング環境のリストと、前記少なくとも１つのドメインについてのリソース・ライブラリからの少なくとも１つのリソースの取得を制御する少なくとも１つのポリシーと、前記少なくとも１つのドメイン内の任意のサブ・ドメインとを含む、ステップと、
   前記表示をインスタンス化するステップと
   を実行させるためのプログラム。
2. 前記コンピュータに、
   前記階層的な管理を提供する際に、コンピューティング環境の前記リストに必要なリソースを導出するステップと、
   前記リソースのセットのためのリソースを前記少なくとも１つのドメインに提供するステップとをさらに実行させるための、請求項１に記載のプログラム。
3. 前記コンピュータに、前記表示の前記少なくとも１つのポリシーを更新するステップをさらに実行させるための、請求項１に記載のプログラム。
4. 前記コンピュータに、ライブラリ・サービスを使用するステップをさらに実行させるための、請求項１に記載のプログラム。
5. 前記使用するステップは、コンピューティング環境の前記リストによって要求されたリソースのセットを予約するステップを含む、請求項４に記載のプログラム。
6. リソースの予約されたセットを取得して、リソースの前記セットからの少なくとも１つのリソースを使用するステップをさらに含む、請求項５に記載のプログラム。
7. ベース・リソースの量および型の両方が経時変化する、請求項４に記載のプログラム。
8. コンピューティング・ユーティリティに対して少なくとも１つのドメインの階層的な管理を提供するための手段を備える装置であって、階層的な管理を提供するための前記手段は、
   前記少なくとも１つのドメインの階層的な表示を取得するための手段であって、前記表示は、管理すべきコンピューティング環境のリストと、前記少なくとも１つのドメインについてのリソース・ライブラリからの少なくとも１つのリソースの取得を制御する少なくとも１つのポリシーと、前記少なくとも１つのドメイン内の任意のサブ・ドメインとを含む、手段と、
   前記表示をインスタンス化するための手段とを備える、装置。
9. エンティティの階層的な表示を作成するためのプログラムであって、コンピュータに、
   前記エンティティをドメインのドメイン・ツリーに組織化するステップであって、各ドメインは、前記エンティティ内の組織を表し、前記各ドメインは、コンピューティング・ユーティリティからコンピューティング環境とリソースとを取得する、ステップと、
   各ドメインに関連付けられたコンピューティング環境を決定するステップと、
   ドメイン毎に取得ポリシーと分配ポリシーとを決定するステップと、
   前記ドメイン・ツリーをコレクタ階層に変換するステップと、
   前記コレクタ階層をホストとされる環境のためのホストとされるルート・コレクタに接続するステップと
   を実行させるためのプログラム。
10. 前記コンピュータに、前記ホストとされる環境を使用して、少なくとも１つのコンピューティング環境と、少なくとも１つのリソースとを前記エンティティにプロビジョンするステップをさらに実行させるための、請求項９に記載のプログラム。
11. 前記接続するステップは、前記ホストとされる環境の複数の顧客のコレクタ階層を前記ホストとされるルート・コレクタに接続するステップを含む、請求項９に記載のプログラム。
12. 前記変換するステップは、
    前記コレクタ階層の階層ルート・コレクタとしてコレクタを挿入するステップと、
    前記ドメイン・ツリーの前記ルート・ドメインのコンピューティング環境の数と、前記ドメイン・ツリーのルート・ドメインのサブ・ドメインが存在するかどうかを判断するステップと、
    コンピューティング環境が１つだけであり、前記ドメイン・ツリーのルート・ドメインのサブ・ドメインが存在しない場合には、ＰＭＲＳを前記コレクタ階層に挿入して、前記変換するステップを中止し、そうでなければ、前記ドメイン・ツリーの前記ルート・ドメインのコンピューティング環境毎に、コレクタと、ＰＭＲＳとを前記コレクタ階層の前記ルート・コレクタに追加するステップと、
    コンピューティング環境を１つだけ有する前記ドメイン・ツリーの前記ルート・ドメインのサブ・ドメインを判断するステップと、
    コンピューティング環境を１つだけ有し、他のサブ・ドメインを有しない前記ドメイン・ツリーの前記ルート・ドメインのサブ・ドメイン毎に、ＰＭＲＳを前記コレクタ階層に挿入するステップと、
    コンピューティング環境を１つより多く有するか、または他のサブ・ドメインを有する前記ドメイン・ツリーの前記ルート・ドメインのサブ・ドメイン毎に、前記各サブ・ドメインをドメイン処理リストに載せるステップと、
    コレクタを挿入するステップと、あたかもルート・ドメインであるかのように前記ドメイン処理リスト上のドメイン毎にコンピューティング環境の数を判断するステップと、コンピューティング環境を１つだけ有する前記ドメイン・ツリーの前記ルート・ドメインのサブ・ドメインを判断するステップとを、前記ドメイン処理リストが空になるまで繰り返すステップとを含む、請求項９に記載のプログラム。
13. コンピュータ・ユーティリティにおける複数のドメインを表すために複数のコレクタを備える装置であって、各前記コレクタは、少なくとも１つの他のコレクタにリンクされており、各コレクタは、
    ドメイン毎の予約リソースを制御するためのコントローラと、
    任意のポリシーを解釈するためのポリシー・アドバイザと、
    コンピューティング環境のためのリソース取得を管理するためのリソース・マネージャとを有する、装置。
14. 前記装置は、少なくとも１つのベース・リソース・ライブラリ・サービスを備え、少なくとも１つのコレクタが、前記少なくとも１つのベース・リソース・ライブラリ・サービスに関連付けられ、前記ベース・リソース・ライブラリ・サービスは、リソース動作インターフェースと、カタログ・インターフェースとを有する、請求項１３に記載の装置。
15. 前記少なくとも１つのベース・リソース・ライブラリ・サービスは、少なくとも１つのドメインにライブラリ・サービスを提供するためのパブリック・ベース・リソース・ライブラリ・サービスを含み、前記ベース・リソース・ライブラリ・サービスは、リソース動作インターフェースと、カタログ・インターフェースとを有する、請求項１４に記載の装置。
16. 前記コンピュータに、
    リソースの特定の組み合わせに対する要求を行う要求コンピューティング環境の前記ポリシーの前記表示をチェックして、前記要求を満足することが、前記要求コンピューティング環境の前記ポリシー内であることを検証するステップと、
    任意のルートコレクタに到達するまで、要求コレクタのすべての親コレクタについてチェックするステップを繰り返すステップとをさらに実行させるための、請求項１に記載のプログラム。
17. 前記コンピュータに、
    前記ポリシーが任意のルート・コレクタまで満足されたかどうかを判断するステップと、
    前記ポリシーが満足されていれば、前記要求に応じ、そうでなければ前記要求を否定するステップとをさらに実行させるための、請求項１６に記載のプログラム。
18. 前記コンピュータに、
    リソースの特定の組み合わせに対する要求を行うステップと、
    リソースの前記組み合わせの検索を開始する開始コレクタを決定するステップと、
    リソースの前記組み合わせから、探索済みリソースである少なくとも１つのリソースを前記開始コレクタは有するかどうかをチェックするステップと、
    リソースの前記組み合わせから、探索済みリソースである少なくとも１つのリソースを含む少なくとも１つのライブラリがあるかどうかをチェックするステップと、
    各コレクタにおける前記チェックを開始コレクタから任意のルートコレクタへ繰り返すステップと、
    前記組み合わせのすべてのリソースが探索済みリソースである場合は、すべての探索済みリソースを予約し、そうでなければ要求を拒絶するステップとをさらに実行させるための、請求項１に記載のプログラム。
19. 前記コンピュータに、アービトレーションを呼び出して、リソースの前記組み合わせからのすべてのリソースを探索することを継続するステップをさらに実行させるための、請求項１８に記載のプログラム。
20. 前記コンピュータに、前記少なくとも１つのリソースを複数の顧客に提供されるサービスに組織化するステップをさらに実行させるための、請求項１に記載のプログラム。
21. 前記コンピュータに、ベース・リソースをライブラリ・サービスに割り当てるステップをさらに実行させるための、請求項１に記載のプログラム。
22. 前記コンピュータに、サービス詳細を満たすベース・リソースから複合リソースを構築するステップをさらに実行させるための、請求項２１に記載のプログラム。

Images