(57)【要約】  本発明は、コンピューティング・ユーティリティにおいてリソースを自動的にプロビジョニングおよび管理するためのシステム、方法、および装置を提供する。その自動化手順は、リソース別のプロビジョニングおよび管理タスクをコンポーネントにカプセル化して再使用することができるようにするリソース・モデルに基づく。これらのコンポーネントを組み立てて、さらに複雑な構成として、最終的にはコンピューティング・サービスとする。本発明は、高レベルの仕様が与えられたリソースのセットからコンピューティング・サービスを構築するための方法を提供する。一旦構築されると、サービスは、管理機能を提供するコンポーネントを含み、これにより、リソースの基礎となるセットの修正が可能となる。
2007526557.tif 000002
【特許請求の範囲】
【請求項１】
コンピューティング・ユーティリティにおいて少なくとも１つのコンピューティング環境をプロビジョニングするための方法であって、
各前記少なくとも１つのコンピューティング環境の記述であって、前記プロビジョニングを実行する第１のサービスの呼び出しを指示し、かつ複合リソース定義である前記記述を使用するステップと、
前記プロビジョニングを実行するために前記第１のサービスを呼び出すステップとを含む、方法。
【請求項２】
前記第１のサービスは、プロビジョニング・リソース・サービスであって、前記方法は、前記第１のサービスが各前記少なくとも１つのコンピュータ環境を管理するための管理リソース・サービスを使用可能にするステップをさらに含む、請求項１に記載の方法。
【請求項３】
ベース・リソースの各型および複合リソースの各型に関連した少なくとも１つのプロビジョニング・リソース・サービスがある、請求項２に記載の方法。
【請求項４】
前記プロビジョニング・リソース・サービスは、複数のプロビジョニング・インスタンスを提供する、請求項２に記載の方法。
【請求項５】
前記呼び出しステップは、
前記少なくとも１つのコンピューティング環境を満足する少なくとも１つのプランを取得するステップと、
特定のプランを選択するステップと、
前記特定のプランに対応するベース・リソースを前記コンピューティング・ユーティリティに対して要求するステップと、
前記特定のプランに対応する前記ベース・リソースが取得されるまで、前記選択ステップおよび前記要求ステップを繰り返すステップと、
前記ベース・リソースを前記コンピューティング環境のインスタンスに構成するステップとを含む、請求項２に記載の方法。
【請求項６】
前記ベース・リソースは、
リソースがプロビジョンされるであろう指定時間と、
リソースの使用可能期間と、
リソース別の選択基準とを備える要求基準群から取得される要求基準を満足する、請求項５に記載の方法。
【請求項７】
前記プロビジョニング・リソース・サービスは、プロビジョニング・リソース・サービスの群からなり、プロビジョニング・リソース・サービスの前記群の各要素は、前記複合リソース記述内のリソースの特定の型に関連付けられている、請求項２に記載の方法。
【請求項８】
前記呼び出しステップは、前記複合リソース記述に従って前記群の各要素を帰納的に使用することによって、前記コンピューティング環境についての前記プロビジョニング・リソース・サービスを使用するステップをさらに含む、請求項７に記載の方法。
【請求項９】
各ベース・リソースは、ベース・リソース・インスタンスを有し、各ベース・リソース・インスタンスに関連した少なくとも１つの管理リソース・サービスがある、請求項２に記載の方法。
【請求項１０】
各複合リソースは、複合リソース・インスタンスを有し、各複合リソース・インスタンスに関連した少なくとも１つの管理リソース・サービスがある、請求項２に記載の方法。
【請求項１１】
前記管理リソース・サービスは、管理リソース・サービスの群からなり、管理リソース・サービスの前記群の各要素は、前記複合リソース記述内のリソースの特定の型に関連付けられている、請求項２に記載の方法。
【請求項１２】
前記プロビジョニング・リソース・サービスは、プロビジョニング・リソース・サービスの群からなり、プロビジョニング・リソース・サービスの前記群の各要素は、前記複合リソース記述内のリソースの特定の型に関連付けられており、
前記呼び出しステップは、前記複合リソース記述に従って前記群の各要素を帰納的に使用することによって、前記コンピューティング環境についての前記プロビジョニング・リソース・サービスを使用するステップをさらに含み、
前記少なくとも１つのプランの前記取得ステップは、副リソース毎に少なくとも１つのプランを帰納的に取得して、結果を組み合わせるステップを含み、
前記ベース・リソースの前記コンピューティング環境のインスタンスへの前記構成ステップは、各副リソースに対応するベース・リソースを帰納的に構成して、結果を構成するステップを含む、請求項５に記載の方法。
【請求項１３】
前記取得ステップは、取得された前記プランを制限する少なくとも１つの条件を指定するステップをさらに含む、請求項５に記載の方法。
【請求項１４】
前記プランの前記選択ステップは、
コストと、
性能と、
満たされた選択数と、
これらの選択基準の任意の組み合わせとを備える選択基準群から取得される選択基準を満足する、請求項５に記載の方法。
【請求項１５】
ベース・リソースに対する予約を割り当てられたベース・リソースに変換するステップをさらに含む、請求項５に記載の方法。
【請求項１６】
前記取得ステップは、
前記コンピューティング環境の前記記述の変更と、
ベース・リソース型のセットの変更と、
複合リソース型のセットの変更と、
これらの変更の任意の組み合わせとを備える反復基準群から取得される反復基準に従って繰り返される、請求項５に記載の方法。
【請求項１７】
前記選択および要求ステップは、
前記選択基準の変更と、
リソースの使用可能性の変更と、
リソースの予約ステータスの変更と、
前記少なくとも１つのプランの変更と、
これらの変更の任意の組み合わせとを備える反復基準群から取得される反復基準に従って繰り返される、請求項５に記載の方法。
【請求項１８】
前記反復および変換ステップを、前記ベース・リソースが取得されるまで繰り返すステップをさらに含む、請求項１５に記載の方法。
【請求項１９】
前記取得、選択、要求、および構成ステップは、少なくとも１つの管理リソース・サービスによって少なくとも１回呼び出されて、リソースを前記コンピューティング環境に追加する、請求項５に記載の方法。
【請求項２０】
コンピューティング・ユーティリティにおいて少なくとも１つのコンピューティング環境のプロビジョニングを生じさせるためのコンピュータ読み取り可能なプログラム・コード手段を内部に実施するコンピュータ使用可能な媒体を備える製品であって、前記製品内の前記コンピュータ読み取り可能なプログラム・コード手段は、コンピュータに対して請求項１の前記ステップを生じさせるコンピュータ読み取り可能なプログラム・コード手段を備える、製品。
【請求項２１】
機械によって読み取り可能で、コンピューティング・ユーティリティにおいて少なくとも１つのコンピューティング環境をプロビジョニングするための方法ステップを行うために前記機械によって実行可能な命令プログラムを明確に実施するプログラム記憶装置であって、前記方法ステップは、請求項１の前記ステップを含む、プログラム記憶装置。
【請求項２２】
ベース・リソース型をオペレーティング・コンピューティング・ユーテリティに追加するステップを含む方法であって、前記追加ステップは、
ベース・リソース・ライブラリ・サービスを提供して、前記ベース・リソース型の任意のインスタンスを表すステップと、
前記ベース・リソース型の任意のインスタンスを前記ベース・リソース・ライブラリ・サービスに追加するステップと、
前記ベース・リソース型についてのプロビジョニング・リソース・サービスの実施を開発するステップと、
前記プロビジョニング・リソース・サービスを起動するステップと、
前記ベース・リソース型についての管理リソース・サービスの実施を作成するステップとを含む、方法。
【請求項２３】
任意の複合リソース型の任意のプロビジョニング・リソース・サービスを更新して、前記ベース・リソース型についての前記プロビジョニング・リソース・サービスを使用するステップと、
任意の複合リソース型の任意の管理リソース・サービスを更新して、前記ベース・リソース型についての前記管理リソース・サービスを使用するステップとをさらに含む、請求項２２に記載の方法。
【請求項２４】
ベース・リソース型の前記追加ステップは、サービス・プロバイダによって実行されて、前記サービス・プロバイダの少なくとも１人の顧客に対するサービス提供を増加させる、請求項２２に記載の方法。
【請求項２５】
複合リソース型をオペレーティング・コンピューティング・ユーテリティに追加するステップを含む方法であって、前記追加ステップは、
前記複合リソース型の副リソースについてのプロビジョニング・リソース・サービスを使用する、前記複合リソース型についてのプロビジョニング・リソース・サービスの実施を作成するステップと、
前記プロビジョニング・リソース・サービスを起動するステップと、
前記複合リソース型の副リソースについての管理リソース・サービスを使用する、前記複合リソース型についての管理リソースサービスの実施を作成するステップとを含む、方法。
【請求項２６】
複合リソース型の任意のプロビジョニング・リソース・サービスを更新して、前記複合リソース型についての前記プロビジョニング・リソース・サービスを使用するステップと、
複合リソース型の任意の管理リソース・サービスを更新して、前記複合リソース型についての前記管理リソース・サービスを使用するステップとをさらに含む、請求項２５に記載の方法。
【請求項２７】
複合リソース型の前記追加ステップは、サービス・プロバイダによって実行されて、前記サービス・プロバイダの少なくとも１人の顧客に対するサービス提供を増加させる、請求項２５に記載の方法。
【請求項２８】
コンピューティング環境についての少なくとも１つの第３者ワークロード管理システムをコンピューティング・ユーティリティに適応させるための方法であって、前記適応ステップは、
前記少なくとも１つの第３者ワークロード管理システムの状態を解釈する管理リソース・サービスを開発するステップと、
前記コンピューティング環境を備えるベース・リソースのセットを前記少なくとも１つの第３者ワークロード管理システムの状態によって示された通りに修正するステップとを含む、方法。
【請求項２９】
前記少なくとも１つのコンピューティング環境の少なくとも１つのコンピューティング環境から、前記少なくとも１つのベース・リソースから少なくとも１つのベース・リソースを返すためのイベントを受信するステップと、
前記少なくとも１つのコンピューティング環境の少なくとも１つのコンピューティング環境から前記少なくとも１つのベース・リソースを構成解除するステップと、
前記少なくとも１つのベース・リソースを前記コンピューティング・ユーティリティへ返すステップと
前記少なくとも１つのベース・リソースを他のコンピューティング環境へ割り当てるために使用可能にするステップとをさらに含む、請求項２に記載の方法。
【請求項３０】
単一のコンピューティング環境内にリソース型のすべてのインスタンスについての１つの管理リソース・サービスがある、請求項９に記載の方法。
【請求項３１】
前記記述は、前記複合リソース定義に対する少なくとも１つの条件をさらに備える、請求項１に記載の方法。
【請求項３２】
前記少なくとも１つのコンピューティング環境の少なくとも１つに対する顧客要求を受信するステップをさらに含む、請求項１に記載の方法。
【請求項３３】
前記複合リソース定義は、リソースの帰納的な組み合わせであり、前記組み合わせは、
少なくとも１つのベース・リソースと、
少なくとも１つの他の複合リソースと、
ベース・リソースと複合リソースとの任意の組み合わせからなる組み合わせの群から取得される組み合わせである、請求項１に記載の方法。
【請求項３４】
前記管理リソース・サービスは、管理リソース・サービスの前記群の特定の要素が使用可能な少なくとも１つの動作を使用し、前記動作は、管理リソース・サービスの前記群の少なくとも１つの要素によって実行され、前記少なくとも１つの動作は、
前記コンピューティング環境からの監視データに基づいて、少なくとも１つの数的指標を送付することと、
前記コンピューティング環境からの監視データに基づいて、少なくとも１つのイベントを送付することと、
前記コンピューティング環境の状態を修正することと、
少なくとも１つの特定の数的指標に応答して、少なくとも１つの特定の動作を呼び出して前記コンピューティング環境を修正することと、
少なくとも１つの特定のイベントに応答して、少なくとも１つの特定の動作を呼び出して前記コンピューティング環境を修正することとを備える動作の群から取得される、請求項１１に記載の方法。
【請求項３５】
ベース・リソース型のオペレーティング・コンピューティング・ユーテリティへの追加を生じさせるためのコンピュータ読み取り可能なプログラム・コード手段を内部に実施するコンピュータ使用可能な媒体を備える製品であって、前記製品内の前記コンピュータ読み取り可能なプログラム・コード手段は、コンピュータに対して請求項１の前記ステップを生じさせるコンピュータ読み取り可能なプログラム・コード手段を備える、製品。
【請求項３６】
コンピューティング・ユーティリティにおいて少なくとも１つのコンピューティング環境をプロビジョンするための装置であって、
各前記少なくとも１つのコンピューティング環境の記述であって、前記プロビジョニングを実行する第１のサービスの呼び出しを指示し、かつ複合リソース定義である前記記述を使用するための第１のプロセッサ・モジュールと、
前記プロビジョニングを実行するために前記第１のサービスを呼び出すための第２のプロセッサ・モジュールとを備える、装置。
【請求項３７】
前記第２のプロセッサ・モジュールは、各前記少なくとも１つのコンピューティング環境を管理するための管理リソース・サービスを使用可能にする、請求項３６に記載の装置。
【請求項３８】
コンピューティング・ユーティリティにおいて少なくとも１つのコンピューティング環境のプロビジョニングを生じさせるためのコンピュータ読み取り可能なプログラム・コード手段を内部に実施するコンピュータ使用可能な媒体を備えるコンピュータ・プログラム製品であって、前記コンピュータ・プログラム製品内の前記コンピュータ読み取り可能なプログラム・コード手段は、コンピュータに対して請求項３６の前記機能を生じさせるコンピュータ読み取り可能なプログラム・コード手段を備える、コンピュータ・プログラム製品。
【請求項３９】
機械によって読み取り可能で、ベース・リソース型をオペレーティング・コンピューティング・ユーティリティに追加するための方法ステップを行うために前記機械によって実行可能な命令プログラムを明確に実施するプログラム記憶装置であって、前記方法ステップは、請求項１の前記ステップを含む、プログラム記憶装置。
【請求項４０】
複合リソース型のオペレーティング・コンピューティング・ユーテリティへの追加を生じさせるためのコンピュータ読み取り可能なプログラム・コード手段を内部に実施するコンピュータ使用可能な媒体を備える製品であって、前記製品内の前記コンピュータ読み取り可能なプログラム・コード手段は、コンピュータに対して請求項１の前記ステップを生じさせるコンピュータ読み取り可能なプログラム・コード手段を備える、製品。
【請求項４１】
機械によって読み取り可能で、複合リソース型をオペレーティング・コンピューティング・ユーティリティに追加するための方法ステップを行うために前記機械によって実行可能な命令プログラムを明確に実施するプログラム記憶装置であって、前記方法ステップは、請求項１の前記ステップを含む、プログラム記憶装置。
【請求項４２】
コンピューティング環境を、リソースのセットを構築するためのプランに変換して、前記コンピューティング環境を提供するための複数のプロビジョニング・リソース・サービスを備える装置であって、前記コンピューティング環境は、複合リソース定義として表される、装置。
【請求項４３】
前記複数のプロビジョニング・リソース・サービスは、前記プランに従って前記リソースを前記コンピューティング環境に構築するためのものであって、前記少なくとも１つのプロビジョニング・リソース・サービスは、前記コンピューティング環境を管理するために管理リソース・サービスを使用可能にする、請求項４２に記載の装置。
【請求項４４】
複合リソース定義として表されるコンピューティング環境の記述を取得するステップと、
コンピューティング環境の記述を、リソースのセットを構築するためのプランに変換して、前記コンピューティング環境を提供するステップとを含む、方法。
【請求項４５】
前記プランに従って前記リソースを前記コンピューティング環境に構築するステップと、
管理リソース・サービスを使用可能にして、コンピューティング環境を管理するステップとをさらに含む、請求項４４に記載の方法。
【請求項４６】
コンピューティング環境の記述を取得するためのコンピュータ読み取り可能なプログラム・コード手段を内部に実施するコンピュータ使用可能な媒体を備える製品であって、前記製品内の前記コンピュータ読み取り可能なプログラム・コード手段は、コンピュータに対して請求項４４の前記ステップを生じさせるコンピュータ読み取り可能なプログラム・コード手段を備える、製品。
【請求項４７】
機械によって読み取り可能で、コンピューティング環境の記述を取得するための方法ステップを行うために前記機械によって実行可能な命令プログラムを明確に実施するプログラム記憶装置であって、前記方法ステップは、請求項４４の前記ステップを含む、プログラム記憶装置。
【請求項４８】
コンピューティング環境についての少なくとも１つの第３者ワークロード管理システムのコンピューティング・ユーティリティに対する適応を生じさせるためのコンピュータ読み取り可能なプログラム・コード手段を内部に実施するコンピュータ使用可能な媒体を備える製品であって、前記製品内の前記コンピュータ読み取り可能なプログラム・コード手段は、コンピュータに対して請求項２８の前記ステップを生じさせるコンピュータ読み取り可能なプログラム・コード手段を備える、製品。
【請求項４９】
機械によって読み取り可能で、コンピューティング環境についての少なくとも１つの第３者ワークロード管理システムをコンピューティング・ユーティリティに適応させるための方法ステップを行うために前記機械によって実行可能な命令プログラムを明確に実施するプログラム記憶装置であって、前記方法ステップは、請求項２８の前記ステップを含む、プログラム記憶装置。
【請求項５０】
プランの開発を生じさせるためのコンピュータ読み取り可能なプログラム・コード手段を内部に実施するコンピュータ使用可能な媒体を備えるコンピュータ・プログラム製品であって、前記コンピュータ・プログラム製品内の前記コンピュータ読み取り可能なプログラム・コード手段は、コンピュータに対して請求項４２の前記ステップを生じさせるコンピュータ読み取り可能なプログラム・コード手段を備える、コンピュータ・プログラム製品。
【請求項５１】
副リソースのインスタンスを作成および管理するために、副リソースのプロビジョンおよび管理リソース・サービスを使用する複合リソースのプロビジョンおよび管理リソース・サービスをさらに備える、請求項１に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本願は、整理番号ＹＯＲ９２００３０５８７ＰＣＴ１の出願「コンピューティング・ユーティリティのための階層的リソース管理」、および同日付けの整理番号ＹＯＲ９２００３０５８９ＵＳ１の出願「コンピューティング・ユーティリティ・システムにおけるアービトレーションのための装置」を相互参照し、あらゆる目的のためにその全体を参照によって本明細書に含めるものとする。
【０００２】
本発明は、コンピューティング・ユーティリティにおけるリソースのプロビジョニングおよび管理に向けられており、コンピューティング・ユーティリティは、当該リソースを使用してコンピューティング・サービスを顧客に提供する。特定的には、本発明は、コンピューティング・ユーティリティのためのコンピューティング環境のコンポーネント化された自動プロビジョニングおよび管理に向けられている。
【背景技術】
【０００３】
ホスト・センタは、複数の顧客に対してコンピューティング・サービスを提供する。各顧客には、その必要に応じるために、サーバなどのサービス・プロバイダのインフラストラクチャ・リソースのサブセットが割り当てられている。顧客の要求は経時変化し、特に、リソースに対するピーク要求は、平均的な要求を桁違いに凌ぐことがある。ピーク要求を満たすためのリソースを単純に割り当てると、リソースが充分に活用されないままとなる。顧客の必要に応じてインフラストラクチャ・リソースを動的に再構築するには、管理要員による迅速な対処が必要となり、稼動コストが上昇して適切なサービスを提供することができない恐れがある。ホスト・センタについての問題は、インフラストラクチャ・リソースおよびスタッフが効率的かつ費用効果のあるやり方で使用されるように顧客の要求の変化にどのように迅速に応じるかということである。コンピューティング・ユーティリティは、共有されたインフラストラクチャに対する１つ以上のコンピューティング・サービスの作成および管理を自動化することによって、この問題に対処しようとしている。
【０００４】
コンピューティング・ユーティリティにおける従来の研究は、提供されるサービスの型、使用されるリソース、および動作の自動化の程度によって様々である。自動化された動作は広範に渡り、サービスの作成、顧客へのサービスの分配、サービスを提供するために使用されたリソースのセットの修正、ならびに新規のリソース・インスタンスおよび型をホスト・センタおよびそのサービスに組み込むことを含む。
【０００５】
あるシステムは、ウェブ・サイトのフロント・エンド・サーバのプロビジョニングを、サーバ負荷および応答時間などの数的指標に基づいて自動化した。そのシステムは、サーバおよびネットワーク・トポロジを自動的に見つけたコンポーネントを含んでいた。別のシステムは、事前に構成されたサーバをサーバ負荷などの数的指標に基づいて互いに異なる層に自動的に割り当てることが可能な様々な複数の層のウェブ・サイトを提供した。また別のシステムも、サーバ負荷に応じてサーバ・リソースを割り当てたが、リソースを各顧客へ割り当てる値と、これらのリソースを使用するコストとを、エネルギー・コストを重視してモデル化した。さらに最近の研究には、メモリおよびストレージなどの他のリソース型の割り当て、および汎用サーバの割り当てが含まれる。
【０００６】
複数の層のアプリケーションを様々なリソースからなる物理的なインフラストラクチャ上へ提供することを目的とする工業製品の数が増加している。これらは、提供されるリソースの種類（例えば、サーバおよびストレージ）、サポートされる特定のオペレーティング・システムおよびミドルウェア、ネットワーク・インフラストラクチャの前提および特徴（例えば、ネットワークの分離がＶＬＡＮを介して行われるかどうか）、サポートを監視するレベル（例えば、リソースの使用、障害検出、ＳＬＡ、閾値ベースの警告）、リソースの発見に対するサポート、一旦配置されたサービス・リソースの修正に対するサポート、（例えば、ＳＬＡによってトリガされて）修正が自動的に生じうるかどうか、および既存のホスト・センタ・インフラストラクチャに合致するように製品をカスタマイズできるかまたはカスタマイズしなければならないかなど、数多くの点で互いに異なっている。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
アプリケーション層において、分配されたアプリケーションの配置および管理を自動化するための研究がなされている。アプリケーションは、互いに関連する再使用可能なコンポーネントの集まりとして記述され、リソースまたはサブシステムを表わしてもよい。アプリケーションの記述には、例えば、コンポーネントが正しいシーケンスで開始されることを保証するための依存情報が含まれる。これは、オペレーティング・システムをサーバにインストールするなどの低レベルのリソース構成タスクには使用されず、さらに高いレベルのアプリケーション専用の構成に使用される。
【０００８】
プロビジョニングとは、所望のコンピューティング・サービスを提供して顧客によって使用するために、インフラストラクチャ・リソースのセットを割り当てて、これらを構成する処理を指す。プロビジョニングは、タスクの複雑なセットであって、タスクには、ネットワーク装置を構成すること、オペレーティング・システムおよびアプリケーション・ソフトウェアをインストールすること、ソフトウェア・ライセンスを取得すること、モニタをインストールすること、および、ユーザ・アカウントを作成することによって顧客アクセスを可能とすることが含まれる。
【０００９】
プロビジョニングは、これらのタスクのための手順またはスクリプトをコード化することによって自動化される。製品によっては、これらの手順を作成および選択する助けとなるためのＧＵＩインターフェースを提供するものもある。例えば、ドラッグ・アンド・ドロップ・インターフェースを使用して、開発すべきアプリケーション環境のためのリソースの「仮想配線」を指定してもよい。仮想配線は、環境の層構造、ファイアウォールのための規則、および、どのオペレーション・システムをサーバにインストールするかを含むことができる。配線図は、テンプレート記述として取り込まれる。この記述は、環境を作成および削除するために使用され、コンピューティング環境からリソースを追加または除去するために修正されてもよい。
【００１０】
あるシステムにおいては、手順のコード化は、サービス別ベースで行われる。リソース種類、接続性、またはサービス要件の変更には、これらの手順を再度実施することが必要となる場合がある。これらが臨時的なやり方または単独で実施されると、最良の実施または動作制約を系統的に実現するのが難しくなる場合がある。よって、従来技術を改良するシステムを提供することが望ましい。
【課題を解決するための手段】
【００１１】
本発明は、コンピューティング・ユーティリティにおいてリソースを自動的にプロビジョニングおよび管理するための方法および装置を提供する。その自動化手順は、リソース別のプロビジョニングおよび管理タスクをコンポーネントにカプセル化して再使用することができるようにするリソース・モデルに基づく。これらのコンポーネントを組み立てて、さらに複雑な構成として、最終的にはコンピューティング・サービスとする。また、本発明は、高レベルの仕様が与えられたリソースのセットからコンピューティング・サービスを構築するための方法を提供する。一旦構築されると、サービスは、管理機能を提供するコンポーネントを含み、これにより、リソースの基礎となるセットの修正が可能となる。
【００１２】
一実施形態例において、本発明は、コンピューティング・ユーティリティにおいて少なくとも１つのコンピューティング環境をプロビジョニングするための方法を提供する。本方法は、各前記少なくとも１つのコンピューティング環境の記述であって、前記プロビジョニングを実行する第１のサービスの呼び出しを指示し、かつ複合リソース定義である前記記述を使用するステップと、前記プロビジョニングを実行するために前記第１のサービスを呼び出すステップとを含む。
【００１３】
一実施形態例において、本発明は、ベース・リソース型をオペレーティング・コンピューティング・ユーティリティに追加するための方法を提供する。追加ステップは、ベース・リソース・ライブラリ・サービスを提供して、前記ベース・リソース型の任意のインスタンスを表すステップと、前記ベース・リソース型の任意のインスタンスをベース・リソース・ライブラリ・サービスに追加するステップと、前記ベース・リソース型についてのプロビジョニング・リソース・サービスの実施を開発するステップと、前記プロビジョニング・リソース・サービスを起動するステップと、前記ベース・リソース型についての管理リソース・サービスの実施を作成するステップとを含む。
【００１４】
ある実施形態においては、方法は、任意の複合リソース型の任意のプロビジョニング・リソース・サービスを更新して、前記ベース・リソース型についての前記プロビジョニング・リソース・サービスを使用するステップと、任意の複合リソース型の任意の管理リソース・サービスを更新して、前記ベース・リソース型についての前記プロビジョニング・リソース・サービスを使用するステップとをさらに含む。
【００１５】
さらなる一実施形態例において、本発明は、コンピューティング環境についての少なくとも１つの第３者ワークロード管理システムをコンピューティング・ユーティリティに適応させるための方法を提供する。適応ステップは、前記少なくとも１つの第３者ワークロード管理システムの状態を解釈する管理リソース・サービスを開発するステップと、前記コンピューティング環境を備えるベース・リソースのセットを前記少なくとも１つの第３者ワークロード管理システムの状態によって示された通りに修正するステップとを含む。
【００１６】
さらなる一実施形態例において、本発明は、高レベルの仕様が与えられたリソースのセットからコンピューティング・サービスを構築するための方法を提供する。よって、本発明は、コンピューティング・ユーティリティの一要素でもある。
【００１７】
さらなる一実施形態例において、本発明は、コンピューティング・ユーティリティにおいて少なくとも１つのコンピューティング環境をプロビジョニングするための装置を提供する。本装置は、各前記少なくとも１つのコンピューティング環境の記述であって、前記プロビジョニングを実行する第１のサービスの呼び出しを指示し、かつ複合リソース定義である前記記述を使用するための第１のプロセッサ・モジュールと、前記プロビジョニングを実行するために前記第１のサービスを呼び出すための第２のプロセッサ・モジュールとを備える。
【００１８】
上記および他の目的、局面、および利点は、図面を参照して、本発明の有利な実施形態の詳細な説明からさらによく理解されるだろう。
【発明を実施するための最良の形態】
【００１９】
用語の定義
コンピューティング環境とは、顧客に提供されるコンピューティング・サービスのことである。これは、サーバ、オペレーティング・システム、およびミドルウェアなどのハードウェアおよびソフトウェア・リソースを含む。本発明においては、コンピューティング環境に割り当てられるリソースは、その割り当て期間中、当該コンピューティング環境専用となるものとしている。
【００２０】
サービス・プロバイダは、複数のコンピューティング環境に対してサービスを提供するものとする。サービス・プロバイダは、コンピューティング・サービスをそのコンピューティング環境に対して提供するために割り当てられるようなリソースのセットを供給する。
【００２１】
ベース・リソースとは、アトミックなリソースであって、すなわち、他のリソースに分解できないリソースのことである。ベース・リソースの一例は、サーバまたはソフトウェア・ライセンスである。サービス・プロバイダが細分化したくない任意のリソースは、ベース・リソースとして取り扱うことができる。ベース・リソースを追加、除去、または修正すると、システムの全体的な容量が変化する。ベース・リソースの数および型の両方が経時変化するものとする。ベース・リソースの概念は、サービス・プロバイダに固有である。
【００２２】
複合リソースは、特定の機能を実行するために他のリソースから構築される。複合リソースは、それに関連する従属物のセットを有してもよい。複合リソースの一例は、ウェブ・サイトである。これは、いくつかのフロント・エンド・サーバと、バック・エンド・サーバと、ロード・バランサと、サーバのためのＩＰアドレスのセットと、ウェブ・サーバ・ソフトウェアと、データベース・ソフトウェアと、ソフトウェアに関連するライセンスとからなってもよい。複合リソースの機能を実施するために使用されるベース・リソースのセットは経時変化してもよいが、すべての複合リソースがこの特性を有していなくてもよい。場合によっては、複合リソース内のリソースは、副リソースと称される。リソースは、即時または将来のいずれかの割り当てのためにコンピューティング環境によって要求されてもよい。将来のリソース割り当ての約束は、予約という。
【００２３】
本発明は、以下に列挙する特徴を有する環境におけるコンピューティング・ユーティリティにおいてリソースを自動的にプロビジョニングおよび管理するための方法、システム、および装置を提供する。合わせて、これらの特徴は、これまで研究された環境を概括するものである。
【００２４】
本発明は、コンピューティング・ユーティリティにおいてリソースを自動的にプロビジョニングおよび管理するための方法および装置を提供する。その自動化手順は、リソース別のプロビジョニングおよび管理タスクをコンポーネントにカプセル化して再使用することができるようにするリソース・モデルに基づく。これらのコンポーネントを組み立てて、さらに複雑な構成として、最終的にはコンピューティング・サービスとする。また、本発明は、高レベルの仕様が与えられたリソースのセットからコンピューティング・サービスを構築するための方法を提供する。一旦構築されると、サービスは、管理機能を提供するコンポーネントを含み、これにより、リソースの基礎となるセットの修正が可能となる。
【００２５】
方法の一例は、高レベルの仕様が与えられたリソースのセットからコンピューティング・サービスを構築することを提供する。以下に列挙する特徴の少なくとも１つを有する環境において動作するのが、オペレーティング・ユーティリティのコンポーネントである。合わせて、これらの特徴は、これまで研究された環境を概括するものである。
【００２６】
第１に、リソースは、異種の組み合わせで顧客に割り当てられてもよく、相互依存であってもよく、経時変化してもよい。
【００２７】
第２に、各顧客に提供されるコンピューティング環境の型は互いに異なってもよい。例えば、ある顧客にはウェブ・サイト用のリソースが提供され、他の顧客には科学的コンピューティング・クラスタ用のリソースが提供されてもよい。よって、リソース型、量、依存性、および割り当てパターンは、顧客の間で様々なものとなる。
【００２８】
第３に、サービス・プロバイダのインフラストラクチャにおけるリソースからコンピューティング環境を構築する方法は複数ありうる。顧客は、特定のブランドのコンピュータなどといった、所定のコンピューティング環境の特定のバリエーションに対する好みまたは必要性がある場合がある。
【００２９】
第４に、リソース・インフラストラクチャは、サービス・プロバイダ間で異なる。さらに、所定のサービス・プロバイダについて、インフラストラクチャは経時変化する。これらのバリエーションは、物理的なインフラストラクチャに対して更新または追加が行われたこと、他のプロバイダのサービスを受けること、またはアイドル時または一日の所定の時間において付加的なリソースが取り込まれたことの結果でありうる。
【００３０】
最後に、リソースは、事前に割り当てまたは予約されてもよい。
【００３１】
本発明が使用されるシステムは、ネットワークを介して相互接続された複数のコンピューティング・リソースを有する分散型コンピュータ・システムである。ホストまたはデータ・センタにおいて見られるようなそのようなシステムの図を図１に示す。物理的なインフラストラクチャにおけるコンピューティング・リソースは、プロセッサ１０１と、ストレージ１０３と、ファイアウォール１０５と、ソフトウェア１０７とを含む。ソフトウェアは、オペレーティング・システム、ミドルウェア、またはアプリケーションであってもよい。図１において、使用可能なソフトウェアは、ビジネス・プロセス、ビジネス・アプリケーション、またはサービスに事前構成されている。ハードウェア・リソースは、すべてのこれらのリソースを相互接続する線の格子で示されるようなネットワーク１０９によって接続される。このネットワークは、１つまたは複数の層に構成されてもよく、各層は、ルータまたはファイアウォールによって分離されている。ソフトウェア・リソースが、管理インフラストラクチャによって物理リソースに割り当てられる。この環境において、リソースのサブセットが管理インフラストラクチャに割り当てられる。図１において、これらのリソース１１１，１１３，および１１５は、それを囲む点線によって示されている。管理インフラストラクチャに割り当てられたリソースは、本発明で説明される管理ソフトウェアを実行する。このソフトウェアは、残りのリソースを管理する。管理インフラストラクチャのために使用されるリソースは、ホストとされる環境の顧客に対して割り当てられない。残りのリソースが、必要に応じて顧客に割り当てられる。クライアント１１７がそのリソースにインターネット１１９を介して接続することによって主にサービスを受けることになることが予期されている。しかしながら、クライアントは、管理リソースへの直接接続を介するなどの何らかの手段でそのリソースに接続すれば、サービスを受けることができる。
【００３２】
図２は、本発明が一コンポーネントであるコンピューティング・ユーティリティの高レベル図を示す。コンポーネントの３つの層がある。下部層２０１は、ベース・リソースを表す。各ベース・リソース型は、ベース・リソース・ライブラリ・サービス（ＢＲＬＳ）と呼ばれる当該ベース・リソース型のインスタンスの予約および割り当てを提供するサービスを有する。本発明は、ベース・リソースの数および型の両方が経時変化するものとする。図２は、４つのベース・リソース型およびそのＢＲＬＳを示す。すなわち、ＤＢ２（ＩＢＭ社の登録商標）ソフトウェア・ライセンス２０３、ｚＳｅｒｉｅｓ（ＩＢＭ社の登録商標）論理区画２０５、ｘＳｅｒｉｅｓ（ＩＢＭ社の登録商標）サーバ・ハードウェア２０７、およびＡＩＸ（ＩＢＭ社の登録商標）ライセンス２０９である。ＢＲＬＳは、カタログ化、チェック・アウト（割り当て）、チェック・イン（割り当て解除）、および予約などの情報を提供する。各コンピューティング環境は、プロビジョンおよび管理リソース・サービス（ＰＭＲＳ）と呼ばれる、リソースをプロビジョンおよび管理するために呼び出されるサービスを有する。図２において、上部層２１１は、コンピューティング環境およびそのＰＭＲＳを示す。図２は、コンピューティング環境の３つの例を示す。すなわち、ＤＢ２（ＩＢＭ社の登録商標）環境２１３、リナックス（Ｌｉｎｕｘ）環境２１５、およびウェブ・サイト環境２１７である。中間層においては、ベース・リソース分配サービス（ＢＲＤＳ）２１９が、ベース・リソースを様々なコンピューティング環境に渡ってどのように分配するかを決定する。ＢＲＤＳは、どのリソースのセットがどのコンピューティング環境に対して使用可能かを特定して、リソースに制限がある場合にビジネス・ポリシーに基づいて自動的にこれらのリソースを再分配する。
【００３３】
コンピューティング環境のために組み立てられたリソースは、複合リソースとしてモデル化される。モデルは、その構成リソースの観点から複合リソースの構成を定義する。本発明の対象であるプロビジョンおよび管理リソース・サービス（ＰＭＲＳ）と呼ばれるサービスのセットが、複合リソースをプロビジョンおよび管理する。各リソース型は、当該型のリソースをどのように作成するか、および当該型のリソースのインスタンスをどのように管理するかについての情報をカプセル化するＰＭＲＳを有する。リソースを管理することは、容量を追加またはリソース・インスタンスから容量を除去するような行為を含んでもよい。よって、図３に示すように、ＰＭＲＳ２５１は、２つの部分からなる。すなわち、複合リソースのインスタンスを作成するプロビジョニング・リソース・サービス（ＰＲＳ）２５３と、複合リソースのインスタンスを管理する管理リソース・サービス（ＭＲＳ）２５５である。リソース型毎に１つのＰＲＳがあり、リソース型の各インスタンス毎に１つのＭＲＳがある。
【００３４】
複合リソースは、他の複合リソースを使用して組み立てられてもよい。例えば、ウェブ・サイト複合リソース・インスタンスは、ロード・バランサと、フロント・エンド・サーバのグループからなってもよい。フロント・エンド・サーバは、複合リソースであって、サーバ、オペレーティング・システム、およびウェブ・サーバ・ソフトウェアからなってもよい。このため、ＰＭＲＳは、コンピューティング環境における複合リソースの構成を表す包含階層内に構成されることができる。図４は、ウェブ・サイト複合リソース・インスタンスの一例である。ツリー内の各ノードは、基本または複合リソースのいずれかを表す。ツリー３０１のルートは、ウェブ・サイト複合リソースである。これは、基本リソースであるロード・バランサ・リソース３０３と、ウェブ・サーバ・グループ複合リソース３０５とを含む。そして、ウェブ・サーバ・リソースは、サーバ・リソース３０７を含む。
【００３５】
複合リソースのＰＭＲＳは、副リソースのＰＭＲＳを使用して、副リソースのインスタンスを作成および管理してもよい。この取り組みにより、リソース・プロビジョニングおよび管理をリソース型毎ベースでカプセル化することができる。複合リソース用のＰＭＲＳは、複合体の副リソース間の相互依存性についての情報のみを組み込み及び反映していればよい。なぜならば、副リソースの内部情報は、サブリソースのＰＭＲＳ内にカプセル化されているからである。
【００３６】
図５は、ウェブ・サイト複合リソース・インスタンス３０１に対応するＭＲＳ階層を示す。各ＭＲＳは、単一のリソース・インスタンスを管理する役割を担う。よって、ウェブ・サイトＭＲＳ４０１は、すべてのウェブ・サイトを管理する役割を担うのに対して、ウェブ・サーバＭＲＳ４０３は、ウェブ・サーバ３０９を管理する役割を担う。あるＭＲＳのボックスから他のボックスへの矢印は、前者が後者を使用してその機能を行うことを示す。よって、ウェブ・サイトＭＲＳ４０１は、ウェブ・サイトの性能上の問題の根本的な原因を決定するために、ロード・バランサ４０５および様々なウェブ・サーバＭＲＳ４０７によって提供された情報を使用してもよく、そしてまた、ウェブ・サーバＭＲＳは、サーバ４０９を使用してもよい。ウェブ・サイトＭＲＳ４０１は、いくつかの構成リソースに対して補正的な構成アクションを行うために、副リソースのＭＲＳをさらに使用してもよい。この処理は、さらに後述する。
【００３７】
図６は、図４のウェブ・サイト複合リソース・インスタンスに対応するＰＲＳ階層を示す。この図のＰＲＳは、対応する型からリソースのすべてのインスタンスを作成する役割を担う。よって、階層のルートは、コンピューティング・ユーティリティにおいてウェブ・サイト複合リソース・インスタンスを作成する役割を担うウェブ・サイトＰＲＳ５０１である。ウェブ・サーバＰＲＳ５０３は、コンピューティング・ユーティリティにおけるすべてのウェブ・サーバ・インスタンスを作成するなどの役割を担う。ＭＲＳ階層の場合のように、あるＰＲＳのボックスから他のボックスへの矢印は、前者が後者を使用してその機能を行うことを示す。よって、ウェブ・サイトＰＲＳ５０１は、ウェブ・サイト・リソースを構築するために、ウェブ・サーバＰＲＳ５０３およびロード・バランサＰＲＳ５０５の両方を使用する。ウェブ・サーバまたはロード・バランサをどのように構築するかを知る必要はなく、この情報は、使用する対応ＰＲＳ内にカプセル化されている。ウェブ・サイトがウェブ・サーバおよびロード・バランサからなることと、作成した後にともに動作させるためにどのようにそれらを構成するかのみを知っていればよい。この処理は、さらに後述する。
【００３８】
図４、図５、および図６は、機能的構成をシステムのプロビジョニングおよび管理に適用する概念を示す。よって、ＰＲＳおよびＭＲＳは、さらに複雑なリソースを構築するための汎用の構築ブロックとしての役割を果たす。新規の複合リソースのためのＰＲＳまたはＭＲＳの実施者は、どの副リソースを作成および管理するにも論理を再実施する必要はない。実施者は、増加分を実施するだけでよく、協働して任意の単一のリソースが行う機能よりも高い機能を行うためにどのようにリソースを作成および管理できるかを実施すればよい。
【００３９】
プロビジョン・リソース・サービス
ＰＲＳは、複合リソース型のインスタンスを作成する。複合リソースの作成には２つの局面を実施する。すなわち、プランニング局面と、構築局面である。ＰＲＳにおいて、計画局面は、リアライザと呼ばれるコンポーネントによって実施される。リアライザは、リソースの要旨の記述を、リソースを作成するのに必要なベース・リソースの可能な組み合わせと対応する複合リソース構造とを記述するスキーマにマッピングする。実質的には、複合リソースを構築するためのプランを供給する。リソースを作成するやり方は１つ以上ある場合もあるので、リアライザは、複数のプランを供給できる。リアライザは、リソース型を考慮するが、プランを提供する際には、特定の型のインスタンスの使用可能性は考慮しない。リアライザは、副リソースのＰＢＳ内のリアライザを使用してプランを作成してもよい。
【００４０】
第２のコンポーネントであるビルダは、必要なベース・リソースのためのリソース・ハンドルとプランとが与えられたリソース・インスタンスを構築する。複合リソースのインスタンスを作成することは、マルチ・ステージであってもよく、各ステージにおいて、副リソースのプロビジョニング・サービスのビルダ・サービスを呼び出すことによって、副リソースから付加的にリソースが構築されて、その後、お互いに対して構築される。リソース・インスタンスの作成は、それを管理するためのＭＲＳのインスタンス化を含む。同一の論理に従って、複合リソースを作成する過程において、ＭＲＳのセットがインスタンス化されて、複合リソースおよびその副リソースを協同的に管理する。
【００４１】
リアライザ
リアライザは、コンピューティング・ユーティリティにおいて使用可能なベースおよび複合リソースから特定の型のリソースを構築するための可能性をカプセル化する。リソースを構築するための１つ以上の代替プランを供給してもよい。この場合、供給する選択肢のセットを制限するために使用することができるある設定を公開してもよい。実現体（Ｒｅａｌｉｚａｔｉｏｎ）とは、互いに異なる選択肢を符号化する構造である。実現体は、グラフまたは二分決定グラフのような数多くの構造で表現できる。複雑な構造の実現体の数は大きいことが予想されうるので、表現は小さくなければならない。
【００４２】
ウェブ・サイト・リソースの実現体の例を図７に示す。子を有する図内のノードは、２つの型がある。すなわち、黒で示されるＡＮＤノードと、白で示されるＯＲノードである。ＡＮＤノードは、親によって表現されるリソースを構築するのに当該ノードのすべての子が必要であることを意味する。ＯＲノードは、親によって表現されるリソースを構築するのにその子のいずれかを使用することを意味する。ウェブ・サイト・グラフ６０１のルート・ノードは、ＯＲノードであって、２層の選択肢６０３と３層の選択肢６０５とを表す。２層ノード６０３は、ロード・バランサ６０７と、ウェブ・サーバ６０９とからなるＡＮＤノードである。３層ノード６０５は、ロード・バランサ６１１と、フロント・エンド・ウェブ・サーバ６１３と、バック・エンド・ウェブ・サーバ６１５とからなるＡＮＤノードである。ロード・バランサ・ノード６０７および６１１は、ベース・リソースであり、出力端を有しない。２層のウェブ・サーバ・ノード６０９は、ＯＲノードであって、サーバ・ノード６１７という選択肢１つしか有しない。サーバ・ノード６１７は、アパッチ・ウェブ・サーバ６１９と、ＷＡＳウェブ・サーバ６２１という選択肢を表すＯＲノードである。３層のフロント・エンド・ウェブ・サーバ・ノード６１３は、２層のウェブ・サーバ・ノード６０９と構成が同一である。アパッチ・サーバ・ノード６１９は、ｉＳｅｒｉｅｓ（商標）６２３、ｘＳｅｒｉｅｓ（ＩＢＭ社の登録商標）６２５、およびｐＳｅｒｉｅｓ（ＩＢＭ社の登録商標）６２７という３つのＩＢＭアーキテクチャのサーバを表すＯＲノードである。ＷＡＳウェブ・サーバ６２１は、ｉＳｅｒｉｅｓ（商標）６２９、ｘＳｅｒｉｅｓ（ＩＢＭ社の登録商標）６３１、ｐＳｅｒｉｅｓ（ＩＢＭ社の登録商標）６３３、およびｚＳｅｒｉｅｓ（ＩＢＭ社の登録商標）６３５という４つのＩＢＭアーキテクチャのサーバを表すＯＲノードである。これらのサーバは、ＤＢ２（ＩＢＭ社の登録商標）ノード６３７と同様に、ベース・リソースである。
【００４３】
リソース型用のリアライザは、供給する選択肢のセットを制限することができるある属性の設定をすることができてもよい。これらの設定は、上述のｒｅａｌｉｚｅ（）関数の実現体別のパラメータの一部として指定される。図８に示すＡＮＤ−ＯＲグラフ表示において、属性７０１は、ＯＲノードについて選択される子孫の値に対する条件を指定する。グラフは枝刈りされて（ｐｒｕｎｅｄ）、属性内の条件を満たさない子孫を除去する。図８は、「ウェブ・サイトは２層である」属性に対応する予想実現体を示す。設定されると、この属性は、「ウェブ・サイト」ＯＲノード６０１におけるグラフを枝刈りする。結果生じた実現体は、ノード６０３をルートとする、実線の輪郭線で示す副ツリーである。
【００４４】
さらに複雑な例を図９に示す。属性「サーバはアパッチである」８０１は、実現体におけるどの「サーバ」ＯＲノードも、サーバ・ノード６１７の子孫のように、直系の子孫として「アパッチ」ノードを有しなければならないことを指定する。ノード６２１のような「サーバ」ＯＲノードの他の子孫は、枝刈りされる。ノード８０７のように、初期の実現体における「サーバ」ノードの直系の子孫として「アパッチ」ノードが指定されていない場合には、「サーバ」ノード全体が枝刈りされる。枝刈りされた「サーバ」ノードがＯＲノードの唯一の直系の子孫である場合、またはＡＮＤノードの直系の子孫のいずれかである場合には、このノードは枝刈りされる。これは、ノード６１５およびその他ノード６０５も帰納的に枝刈りされるような場合である。この処理の適用の結果、ノード６０３をルートとする２層の実現体である実現体が生じる。実現体は、実線屋汁で示す。ノード６１９の子孫はいずれも、許容される選択肢である。
【００４５】
複数の属性を実現体の仕様の一部として指定してもよい。図１０は、複数の属性９０１を有する実現体の仕様を示す。結果生じた実現体は、サーバ型がｚＳｅｒｉｅｓ（ＩＢＭ社の登録商標）９０９上でＷＡＳサーバ９０７として実現されたフロント・エンド・サーバ９０５を有する３層のウェブ・サイト６０５である。同様に、ＷＡＳサーバ９１１として実現されたバック・エンド・ウェブ・サーバも、ｚＳｅｒｉｅｓ（ＩＢＭ社の登録商標）９１３で実現される。この実現体を、実線矢印で示す。
【００４６】
上述の枝刈りアルゴリズムは、略式で以下のように記述することができる。
【００４７】
Ｐｒｕｎｅ＿ｏｎｅ（Ｓ，Ｒ）：
属性Ｓ＝［ＮＯＤＥ＿ＮＡＭＥは、ＣＯＮＤＩＴＩＯＮである（ｉｓ）］および、
ノードのセットＮＯＤＥＳを有する実現体Ｒについて、
【００４８】
【数１】
2007526557.tif 000003
【００４９】
Ｐｒｕｎｅ＿ａｌｌ（ＬＳ，Ｒ）：
属性リストＬＳ＝Ｌ１，Ｌ２，…，Ｌｎおよび、
実現体Ｒについて、
【００５０】
【数２】
2007526557.tif 000004
【００５１】
なお、これらの例は、すべてのＯＲノード属性を実現要求内で指定できるようにするリアライザに基づく。リアライザは、すべての選択を公開する必要はない。「インテルでないサーバ」などのように、選択のセットを単一の選択肢としてグルーピングしてもよい。
【００５２】
なお、さらに複雑な属性を定義および使用してもよいこと。例えば、「である（ｉｓ）」の代わりにキーワード「を含む（ｃｏｎｔａｉｎｓ）」を使用して、ノードの直系の子孫だけでなくノードがルートとする副ツリー内のノード上で属性を指定することができる。このような場合も扱えるようにするために、枝刈りアルゴリズムを単純明快なやり方で変更することもできる。一例として、図１０に示す実現体の結果を再び考える。同一の実現体の結果は、「ウェブ・サイトは２層である」および「サーバはｚを含む」という２つの属性のみの実現体の仕様に対応する。サーバはＷＡＳでなければならないと指定されてはいないが、アパッチの可能性９１５は枝刈りされる。なぜなら、それがルートとなる副ツリーは「ｚ」リソースを含んでいないからである。
【００５３】
リアライザの動作
複合リソースは、ベースまたは他の複合リソースを使用して組み立てられてもよいので、リアライザは、副リソースのリアライザを呼び出す。図１１は、ウェブ・サーバとサーバという、２つの副リソースを使用するウェブ・サイトの例を示す。ウェブ・サーバ・リアライザは、縞模様のノード１００１，１００３，および１００５をルートとする副グラフを供給する。このリアライザは、フロント・エンドまたはバック・エンド・ウェブ・サーバ型を供給できる。ノード１００５は、ノード１００１および１００３よりも濃い色なのは、両方ともＡＮＤノードであり、副リソースノードだからである。サーバ・リアライザは、ノード１００７のような点模様のノードをルートとする副グラフを供給する。サーバ・リアライザは、互換性のあるオペレーティング・システムを有する互いに異なるＩＢＭサーバ・アーキテクチャのサーバを供給できる。なお、この例において、アパッチ・ウェブ・サーバ・リアライザは、ｉＳｅｒｉｅｓ（商標）、ｘＳｅｒｉｅｓ（ＩＢＭ社の登録商標），またはｐＳｅｒｉｅｓ（ＩＢＭ社の登録商標）サーバ型を有するサーバ・リアライザ１００７のみを呼び出す。ｚＳｅｒｉｅｓ（ＩＢＭ社の登録商標）オプションは、アパッチについてはグラフに示されていない。
【００５４】
図１２は、実現体を生成する処理を示す。ウェブ・サイトＰＲＳ５０１は、「２層」という属性を持つ実現体の仕様を有するＲｅａｌｉｚｅ要求１１０３を受信する。ウェブ・サイト・リアライザ５０１は、ウェブ・サーバ・リアライザ５０３をＲｅａｌｉｚｅ要求１１０７で呼び出す。そして、ウェブ・サーバ・リアライザ５０３は、サーバ・リアライザ５０７をＲｅａｌｉｚｅ要求１１１１および１１１３で２度呼び出す。要求１１１１および１１１３の結果は、応答１１１９および１１２１によって返される実現体Ｒ１  １１１５およびＲ２  １１１７である。ウェブ・サーバ・リアライザは、Ｒ１およびＲ２を使用して実現体Ｒ３  １１２３を構築し、これを要求１１０７に対する返答としての応答１１２５で返す。最後に、ウェブ・サイト・リアライザは、Ｒ３を使用して実現体Ｒ４  １１２７を構築し、これを最初の要求１１０３からの応答１１２９で返す。
【００５５】
実現体は、複合リソースが構築されるよりも前に取得されてもよく、長期間保持されてもよい。実現体が再生成されなければならない状況には、要件の変更、およびシステムにおいて使用可能なベースまたは複合リソース型の変更が含まれる。なお、実現体は、リソースの使用可能性に依存しない。したがって、リソースの使用可能性が変更されても、実現体の再生成は要求されない。
【００５６】
リソース選択
実現体が一旦取得されると、単一の選択肢に対応するリソースを割り当てなければならない。実現体は、複数の選択肢を記述できるので、ランク付け機構を使用して、いくつかの数的指標に従って選択肢を順序付けすることができる。例えば、実現体内の残りの選択肢について、満たされた選択数の観点から順序付けされることもできよう。他のランク付けの数的指標を使うこともできよう。その後、選択肢が順に選択されて、ベース・リソースが特定の選択肢について要求される。リソース要求が成功すると、ツリーは、ベース・リソースのリソース識別子（例えば、予約チケットまたはリソース・ハンドル）で注記がなされる。ベース・リソースが一旦取得されると、ビルダが呼び出されてリソースを構築する。リソースの使用可能性が変更されると（例えば、システムによって予約が取り消されると）、ソースの選択肢のセットを確保するために実現体を使用することができる。
【００５７】
ビルダ
ビルダは、入力として、実現体と、リソースを組み立てるためのベース・リソースのセットとを受信する。リソース型を構築するために必要な手順は、ビルダ内に符号化される。これらの手順は、リソースの依存性および動作の適切な順序付けの詳細をカプセル化する。実現体は、ベース・リソースに対応する選択肢で注記がなされる。ビルダは、ツリーを縦に横断して、指示通りのノードにおける副リソースのビルダを呼び出して、それらを副リソースに対応する実現体のツリーに供給する。
【００５８】
図１３は、複合リソースを構築する処理を示す。処理はステップ１２０１で開始し、複合リソースについてのＰＢＳのｒｅａｌｉｚｅ関数が、ｒｅａｌｉｚａｔｉｏｎ−ｓｐｅｃ内の属性設定として供給された要件がもしあれば、それと共に呼び出される。次にステップ１２０３において、実現体は、ランク付けされて、ランクに従って順序付けされる。選択肢に対する好みがあれば、このステップにおいて対処される。その後、処理は、ステップ１２０５において第１の実現体から始めて、実現体によって実施された選択肢を順に検査する。ステップ１２０７において、ベース・リソースのセットが当該実現体について取得され、ステップ１２０９において、リソース要求が当該セットについて発行される。ステップ１２１１において、要求の結果が検査される。要求が成功すると、フローはステップ１２１７へ進み、実現体は、現在の選択肢と、そのために確保されたベース・リソースのセットのリソースＩＤとで注記がなされる。その後、ステップ１２１９において、ＰＲＳのｂｕｉｌｄ関数が呼び出される。ステップ１２１１において要求が成功しない場合には、フローはステップ１２１３へと進み、試行されてもよい別の実現体があるかどうかを判断する。別の実現体がある場合には、リスト上の次の実現体がステップ１２１５において選択され、処理はステップ１２０７へと続く。選択肢が残っていない場合には、フローはステップ１２２１へと進み、複合リソースの構築は失敗に終わる。
【００５９】
事前予約をサポートするシステムにおいて、返されるリソース識別子は、リソースに対する予約を表わしてもよい。その場合に、予約に関連するリソースを要求するために、別のステップが必要となる。このステップが生じるまでにはかなりの期間がある場合があり、この期間中の他の行為の結果、このステップが最終的に失敗する場合がある。例えば、リソースの障害または予約のオーバー・ブッキングなどの理由により、予約開始時に使用可能でないこともある。リソースを要求する最初の試みが成功しない場合に、他の選択肢を試行でき、ベース・リソースの他のセットで回復が可能であってもよい。事前予約をサポートするシステムにおいて複合リソースを構築する処理を図１４に示す。処理はステップ１３０１で開始し、複合リソースについてのＰＲＳのｒｅａｌｉｚｅ関数が、ｒｅａｌｉｚａｔｉｏｎ−ｓｐｅｃ内の属性設定として供給された要件がもしあれば、それと共に呼び出される。次にステップ１３０３において、実現体は、ランク付けされて、ランクに従って順序付けされる。その後、処理は、ステップ１３０５において第１の実現体から始めて、実現体によって実施された選択肢を順に検査する。ステップ１３０７において、ベース・リソースのセットが当該実現体について取得され、ステップ１３０９において、リソース要求が当該セットについて発行される。ステップ１３１１において、要求の結果が検査される。要求が成功すると、フローはステップ１３１７へ進み、実現体は、現在の選択肢と、そのために確保されたベース・リソースのセットのリソースＩＤとで注記がなされる。ステップ１３１８において構築時間が到来すると、ステップ１３１８において、処理は、予約に関連したリソースを要求するよう試みる。構築時間は、所望の開始時間にリソースが使用可能であるように、リソースを構築するのに十分な時間を見越しておく。ステップ１３２１においてすべてのリソースを取得すると、フローはステップ１３２３へ進み、ＰＲＳのｂｕｉｌｄ関数が呼び出される。ステップ１３２１においてすべてのリソースを取得していない場合には、制御はステップ１３０５へ戻り、第１の実現体から処理が繰り返される。ステップ１３１１においてリソース要求が成功しない場合には、フローはステップ１３１３へ進み、試行されてもよい別の実現体があるかどうかを判断する。別の実現体がある場合には、リスト上の次の実現体がステップ１３１５において選択され、処理はステップ１３０７へと続く。選択肢が残っていない場合には、フローはステップ１３２５へと進み、複合リソースの構築は失敗に終わる。
【００６０】
プロビジョニング動作
Ｒｅａｌｉｚｅ（ｎ，ｒｅａｌｉｚａｔｉｏｎ−ｓｐｅｃ）−＞ｒｅａｌｉｚａｔｉｏｎ［］
この要求は、ＰＭＲＳによって表わされる型のリソースを構築するためのプランを作成するために発行される。
入力：
ｎは、所望の実現体の最大数
ｒｅａｌｉｚａｉｔｏｎ−ｓｐｅｃは、このリアライザの作用を受ける属性に対する設定
これらの属性制御は、リソース内にありうるバリエーションを表わす。これらの設定は、供給される実現体を決定する。指定されていない属性設定は、付加的な自由度を表わす。
出力：
Ｒｅａｌｉｚａｔｉｏｎ［］。実現体を表わす構成（リスト、ツリーなど）。各実現体は、それ（「ショッピング・リスト」）に必要とされているベース・リソースおよびその構造を含むスキーマを含む。
【００６１】
Ｂｕｉｌｄ（ｂａｓｅ−ｒｅｓｏｕｒｃｅ−ｈａｎｄｌｅｓ，ｒ）−＞ｒｅｓｏｕｒｃｅ−ｈａｎｄｌｅ
このインターフェースは、ｂａｓｅ−ｒｅｓｏｕｒｃｅ−ｈａｎｄｌｅｓに示されたベース・リソースからの、ＰＭＲＳによって表される型のリソースの構築を要求するために使用される。
入力：
ｂａｓｅ−ｒｅｓｏｕｒｃｅ−ｈａｎｄｌｅｓ［］は、実現体におけるベース・リソースについてのリスト・ハンドルである
実現体は、複合リソースの構成を記述するために使用されるリアライザによって予め提供される。
出力：
ｒｅｓｏｕｒｃｅ−ｈａｎｄｌｅは、新たに構築されたリソースに対すルハンドルである。
失敗時には、これは、「無効（ｎｕｌｌ）」ハンドルに設定される
【００６２】
Ｕｎｂｕｉｌｄ（ｃｏｍｐｏｓｉｔｅ−ｒｅｓｏｕｒｃｅ−ｈａｎｄｌｅｓ）−＞ｒｅｓｏｕｒｃｅ−ｈａｎｄｌｅ［］
このインターフェースは、複合リソースを、それを構築するのに使用されたベース・リソースのセットに分解するために使用される。リソースがＢＲＤＳへ返されることになる場合に使用される。
入力：
ｃｏｍｐｏｓｉｔｅ−ｒｅｓｏｕｒｃｅ−ｈａｎｄｌｅｓは、複合リソースのハンドルである。
出力：
ｒｅｓｏｕｒｃｅ−ｈａｎｄｌｅ［］は、ベース・リソースのハンドルのアレイである。
【００６３】
管理リソース・サービス
上述のように、あるリソース型（複合またはベース）についてのＭＲＳは、当該リソースの動作の情報をカプセル化する。ＭＲＳは、リソースが対応のＰＲＳによって作成される場合に、当該リソース用にインスタンス化される。ＭＲＳインスタンスへの参照がＰＲＳに対するｂｕｉｌｄ動作から返される。
【００６４】
複合リソース型用のＭＳＲは、複合リソースの管理において、副リソースのＭＲＳを使用できることを思い出して欲しい。この構成を、図５のウェブ・サイト・コンピューティング環境に関する図１５に示す。リソースが割り当てられた各コンピューティング環境は、１つの指定されたルートＭＲＳを有する。図１５のルートＭＲＳは、ウェブ・サイトＭＲＳ４０１である。他のすべてのＭＲＳインスタンスは、このルートＭＲＳの下に関連付けられている。ルートＭＲＳだけが、ＢＲＤＳ２１９と通信する。ルートＭＲＳは、システムの性能および健全性のような要素を考慮したシステムの情報に基づいてい、リソース管理要求１４０５を生成する。これらの要求は、ルートＭＲＳに対応するコンピューティング環境によって使用されるベース・リソースのセットを修正してもよい。ＭＲＳは、相互参照出願である、整理番号ＹＯＲ９２００３０５８７ＰＣＴ１の「コンピューティング・ユーティリティのための階層的リソース管理」に記載されたＢＲＤＳリソース管理インターフェースに記述された動作を実施しなければならない。さらに低レベルのＭＲＳは、階層を通じてルートＭＲＳへと伝搬されることになる、さらに多くの容量に対する内部要求を生成できるだけである。なお、所定のリソース型用のＭＲＳは、あるコンピューティング環境においてはルートＭＲＳであるが、他のコンピューティング環境ではそうでない場合がある。
【００６５】
ＭＲＳを構成するには、上位レベル・インターフェースが、ウェブ・サーバＭＲＳ４９３と、ウェブ・サイトＭＲＳ４０１との間などのＢＲＤＳと下位レベルのＭＲＳとの間で要求を受信および伝搬するように、リソース管理インターフェースを各レベルにおいて複製する。中間ＭＲＳは、要求を適宜フィルタリングしてもよい。例えば、ウェブ・サイトＭＲＳ４０１は、ＢＲＤＳに対してリソースを要求する代わりに既存のリソースを再構築することによって、下位レベルのＭＲＳに対してリソース要求に応答するように選択してもよい。この構成の背後には、高レベルのＭＲＳは、要求副リソースと、他のリソースとの間の相互依存を含む複合体全体についての情報に基づいて、より高度な決定ができるという推論がある。
【００６６】
整理番号ＹＯＲ９２００２０２０１ＵＳ１の出願「サービス時間保証のための適応アドミッション制御およびリソース管理のためのシステムおよび方法」に記載されているｅＷＬＭなどの第３者ワークロード管理システムも、図１６に示すようなＰＷＲＳにおいてあらわすことができる。２つのコンピューティング環境１５０１および１５０３は、サーバ１５０５のようなリソースと、ワークロード管理ソフトウェア１５０７とを使用して、サーバに対するワークロードを管理する。ワークロード管理ソフトウェアは、ＰＭＲＳ１５０９のＰＲＳ部分によって、コンピューティング環境のための複合リソースに構成および構築される。ＰＭＲＳ１５０９のＭＲＳ部分は、ワークロード管理ソフトウェアと対話することができるアダプタとして機能する。
【００６７】
ＭＲＳの内部構成
ＭＲＳによって適用される機能および動作インターフェースは、リソース固有である。広範な機能が可能である。一般的に、ＭＲＳ内に含まれる機能のすべては、構成、動作、および保守を含むリソースの管理に関連付けられている。例えば、ＭＲＳは、イベントまたは他の数的指標をシステム内の他のソースから収集すること、平滑化および集約のような何らかの機能を適用すること、リソースの動作状態を説明する数的指標イベントを生成することを含む監視が可能であってもよい。どの数的指標またはイベントがＭＲＳによって作成および消費されるかを示すために、汎用インターフェースが提供されてもよい。ＭＲＳ内に集められた数的指標は、課金システムまたは他のＭＲＳなどのシステムの他の部分に報告されてもよい。機能の他の型は、構成であって、構成パラメータを取得および設定し、振舞いを最適化するためにリソース状態を変更するために、一般的な動作が提供されてもよい。機能の第３の型は、管理リソースの状態を説明する数的指標またはイベントを受信して、もしあればどのような行為を取るかを判断して、リソースが必要なレベルで（例えば、ＳＬＡにおいて指定されたように）動作し続けるようにすることによる自己管理能力を提供する。このように開始することができる動作には実施的に２つのものがあり、それは、リソースまたはその副リソースを適切な構築動作を使用して再構築することによってリソースの動作状態を変更すること、および、リソースまたは副リソースの容量を変更することである。副リソースの構成の変更は、そのＭＲＳを通じて行うことができる。リソースの容量の変更は、さらに込み入った処理である。容量の増加は、ＳＬＡを満たすことができなかったこと、または何らかの予想される将来の負荷修正が理由で、要求されることがあろう。要求された新規のリソースを当該要求上で指定しなければならないか、または障害がどこにあり、この障害を軽減するのに必要であろうリソース（または構成）が何であるかを判断するための分析を行わなければならない。これが一旦行われると、リアライザ・サービスを使用して、基本リソースのショッピング・リストを取得し、要求をＢＲＤＳへ送ってリソースを取得する。リソースが一旦取得されると、ビルダがリソース・ハンドルと共に呼び出される。容量の低下もＳＬＡによって生じる場合があり、既存のリソースが返されることになるので、実現ステップは必要ないだろう。
【００６８】
新規のリソースまたはサービスを組み込むための処理および手法
本発明の利点の一つは、新規のリソース型およびサービスが導入される動的なシステムに対処するための装置の機能である。図１７は、新規のベース・リソースが導入された場合に続く処理を示す。処理はステップ１６０１で開始し、導入すべきリソースがベース・リソースかどうかについての判断がなされる。リソースがベース・リソースである場合、フローはステップ１６１３へ進み、新規のベース・リソース型用のＢＲＬＳが提供される必要がある。ＢＲＬＳは、その後ステップ１６１５において起動され、ステップ１６１７において、ＢＲＬＳの管理インターフェースを介して使用可能なリソース・インスタンスに関する情報で更新される（相互参照出願ＹＯＲ９２００３０５８７ＰＣＴ１を参照）。次にステップ１６１９において、ＰＲＳの実施が新規リソースに提供されなければならない。新規のＰＲＳは、ステップ１６２１において起動される。なぜならば、システム内のリソース型毎に単一のＰＲＳがなければならないからである。ステップ１６２３において、ＭＲＳの実施が新規リソースに提供されなければならない。最後に、ステップ１６１１において、新規リソースに影響を及ぼしたいコンポーネントがあれば、その論理が更新される必要がある。このステップにより、既存のサービスは、新規に定義されたリソースを利用することができる。新規リソースが既存のサービスに組み込まれた状況、およびこの組み込みが自動化される度合いは、サービス・プロバイダまたは導入ポリシーの問題である。更新する必要のあるコンポーネントの例は、新規のベース・リソースを使用して表しているリソースがわかった複合リソースのＰＲＳおよびＭＲＳである。例えば、新規の型のマシン（ｘＳｅｒｉｅｓ（ＩＢＭ社の登録商標）サーバなど）を導入すると、新規のマシン型を使用する可能性を含む実現体を提供するために、ウェブ・サーバＰＲＳを更新する必要がある場合がある。特に、ＰＲＳのリアライザ機能と、ｂｕｉｌｄ関数とを、更新する必要がある場合がある。システムの他の部分は変更しなくてよい。
【００６９】
複合リソースについて、処理はステップ１６０３に続き、複合リソースのありうる構成をモデル化する。これは、副リソースのリストであって、副リソースが相互に関連しているか、および、特に、副リソースがどのように構成されて協働するかを示す。その結果がステップ１６０５であって、リアライザおよびビルダ機能を、既存のリソースのＰＲＳをその論理の一部として使用する新規の複合リソース用のＰＲＳ内で実施して、複合リソースを実現および構築する。ステップ１６０７において、新規のＰＲＳが起動される。次にステップ１６０９において、既存の副リソースのＭＲＳをその論理の一部として使用する新規の複合リソースに対して、ＭＲＳの実施が提供されて、複合リソースを管理する。処理は、ステップ１６１１において、新規の複合リソースを利用するために、既存のより高度な複合リソースを必要に応じて更新することで完了する。例えば、ウェブ・サイト複合リソースは、新規のセキュア・ウェブ・サーバ複合リソースを利用するために更新されてもよい（以前は単純なウェブ・サーバ複合リソースのみが使用可能だったと仮定）。
【００７０】
新規のサービス型を組み込み及びサポートする処理は、サービスとしての複合リソースを複合リソースにモデル化する処理と同様である。これらの処理により、サービス・プロバイダまたはコンピューティング・ユーティリティの動作に関わる他のエージェントが、顧客に提供されるサービスを増加することができる。なお、新規サービスの実施者は、コンピューティング・ユーティリティのサービス・プロバイダまたはオペレータとは別であってもよく、リソースの新規の実施は、パッケージ化された更新としてサービス・プロバイダに提供されてもよく、サービス・プロバイダは、その後、これらをインストールして新規のリソースを追加する。この場合のサービス・プロバイダは、顧客または顧客の組織の外部または内部のいずれかのエンティティを表わしてもよいだろう。後者の例は、社内のＩＴ部署である。サービスを一般に公開するなどの、内部的に使用される複合リソースに対して必要とされる以上のサービスにとって必要であるかもしれない他のステップは、本発明の範囲外である。
【００７１】
使用例
プロビジョンおよび管理リソースのコンポーネント化された動作を示すために、２つの使用例が図面に示されている。第１の使用例は、図１８において、サーバのセットからなるコンピューティング環境を示す。このセットは、複合リソースとしてモデル化され、底では、ＰＲＳ１７０１と、ＭＲＳ１７０３とが存在する。ＭＲＳ１７０３は、コンピューティング環境用に指定されたルートＭＲＳである。各それぞれのサーバは、ＰＲＳ１７０５によってリソースとしてモデル化される。当該セットにはＭＲＳ１７０７によって例示されるような３つのサーバがある。サーバ・セットＭＲＳは、グループの容量を増加させなければならないことを示す監視データ１７０９を受信する。ＭＲＳ１７０３は、サーバを追加することを決定し、実現要求１７１３をサーバＰＲＳ１７０５へ発行して、リソース・リストＢと、新たなサーバを構築するプランとを取得する。図ではＢのみを示す。その後、リソース要求１７１５をＢＲＤＳ２１９へ発行して、リソースを取得する。この場合、事前予約はなく、ＢＲＤＳは、リソース・ハンドルを返す。ＭＲＳ１７０３は、その後、リソース・ハンドルで要求１７１９を介してサーバＰＲＳ１７０５のビルダを呼び出す。新規のサーバＭＲＳ１７２１がインスタンス化される。構築要求が完了すると、ＭＲＳ１７０３は、その状態を新規のサーバのリソース・ハンドルで更新してもよく、新規のサーバを当該セットに追加する必要のある構成を付加的に行ってもよい。
【００７２】
図１９に示す第２の使用例は、ウェブ・サイトに対する容量の増加という形式での、さらに複雑なリソース構造を示す。ルートＭＲＳは、ウェブ・サイトＭＲＳ４０１である。ここでも、ウェブ・サイトの容量を増加しなければならないことを示す監視データ１８０３が、ルートＭＲＳに到達する。ＭＲＳ４０１は、ウェブ・サーバを追加することを決定し、実現要求１８０７をウェブ・サーバＰＲＳ５０３へ発行する。そして、ウェブ・サーバＭＲＳは、サーバＰＲＳ５０７の実現動作１８１１を呼び出す。ベース・リソースのリストが取得され、上記の使用例と同様に、ＢＲＤＳ２１９へ要求１８１５が発行される。リソース・ハンドルが返されて、構築要求１８１９および１８２１を介してコンポーネント・リソースのビルダへ渡される。サーバおよびウェブ・サーバ・ビルダは、新規のサーバおよびウェブ・サーバ・インスタンスをそれぞれ表すために、ＭＲＳ１８２５および１８２７をインスタンス化する。最後に、ルートＭＲＳ４０１は、ロード・バランサに対するそのＭＲＳ４０５を通じた構築要求１８３１を介して、新規のサーバを構築して、新規のサーバをウェブ・サイトの一部として含める。
【００７３】
よって、本発明は、コンピューティング・ユーティリティにおいて１つ以上のコンピューティング環境をプロビジョニングするための方法を含み、本方法は、各１つ以上のコンピューティング環境の記述であって、プロビジョニングを実行する第１のサービスの呼び出しを指示し、かつ複合リソース定義である記述を使用するステップと、プロビジョニングを実行するために第１のサービスを呼び出すステップとを含む。
【００７４】
本方法の実施形態によっては、コンピューティング環境の記述の変更、ベースまたは複合リソース型のセットの変更、またはこれらの変更の任意の組み合わせがある場合には、プランまた実現体を取得するステップが繰り返される。
【００７５】
本方法の実施形態によっては、選択基準の変更、リソースの使用可能性の変更、リソースの予約ステータスの変更、プランの変更、またはこれらの変更の任意の組み合わせがある場合には、プランを選択してそれに関連するリソースを要求するステップが繰り返される。
【００７６】
本発明のさらなる実施形態において、プロビジョニング・リソース・サービスおよび管理リソース・サービスをリソース型およびインスタンスにマッピングすることは、性能、使用可能性、およびセキュリティなどの考慮事項に基づいて様々であってもよい。例えば、複数のプロビジョニング・リソース・サービスを使用して、性能をさらによくするためにリソース型のインスタンスを供給してもよい。当該型を入力として受理する単一のプロビジョニング・リソース・サービスをすべてのリソース型について使用してもよい。単一の管理リソース・サービスが、あるリソース型のすべてのインスタンスを管理してもよい。代わりに、互いに異なるコンピューティング環境のコンポーネント間で分離が必要な場合は、単一の管理リソース・サービスが、あるコンピューティング環境内のあるリソース型の複数のインスタンスを管理してもよい。さらに、プロビジョニングおよび管理リソース・サービスを２つのコンポーネントに仕切ることも、様々でありうる。例えば、単一のサービスまたはサービスの集合体として実現することもできる。最後に、プロビジョニング・リソース・サービスおよび管理リソース・サービスは、それら自体、単一のサービスまたはサービスの集合体として実現されてもよい。例えば、プロビジョニング・リソース・サービスのビルダおよびリアライザ機能は、別個のサービスとしてインスタンス化されることもできよう。そのような数多くのバリエーションが可能なこと、および、これらの実施形態は例示に過ぎず、本発明を限定するものではないことを、当業者は理解するだろう。
【００７７】
また、本発明は、コンピューティング環境を、リソースのセットを構築するためのプランに変換して、前記コンピューティング環境を提供するためのプロビジョニング・リソース・サービスのセットを備える装置であって、コンピューティング環境は、複合リソース定義として表される。本装置の実施形態によっては、プロビジョニング・リソース・サービスのセットは、プランに従ってリソースをコンピューティング環境に構築するためのものであって、１つ以上のプロビジョニング・リソース・サービスは、前記コンピューティング環境を管理するために管理リソース・サービスを使用可能にする。
【００７８】
また、本発明は、複合リソース定義として表されるコンピューティング環境の記述を取得し、コンピューティング環境の記述を、リソースのセットを構築するためのプランに変換して、コンピューティング環境を提供する方法を含む。本装置の実施形態によっては、プランに従ってリソースをコンピューティング環境に構築し、管理リソース・サービスを使用可能にして、コンピューティング環境を管理する。
【００７９】
本発明について説明した変更態様は、各特定の応用にとって望ましい任意の組み合わせにおいて実現可能である。よって、本明細書に記載された特定の限定または実施形態の拡張あるいはその両方は、ある特定の応用には特に利点があるかもしれないが、すべての応用にとって使用される必要はない。また、本発明の１つ以上の概念を含む方法、システム、または装置あるいはそのすべてにおいて、限定がすべて実施される必要はない。
【００８０】
本発明は、ハードウェア、ソフトウェア、またはハードウェアおよびソフトウェアの組み合わせで実現できる。本発明に係る視覚化ツールは、１つのコンピュータ・システムにおいて一元的なやり方で、または、互いに異なる要素が、相互接続されたコンピュータ・システムに渡って分散されるような分散的なやり方で、実現できる。どのような種類のコンピュータ・システム、または本明細書に記載の方法または機能あるいはその両方を実行するために適応された他の装置も好適である。ハードウェアおよびソフトウェアの典型的な組み合わせは、汎用コンピュータ・システムであって、ロードおよび実行されると本明細書に記載の方法を実行するようにコンピュータ・システムを制御するコンピュータ・プログラムを有するものが挙げられよう。本発明は、本明細書に記載の方法の実施を可能にするすべての特徴を備えており、コンピュータ・システムにロードされるとこれらの方法を実行するコンピュータ・プログラム製品に組み込むこともできる。
【００８１】
本件のコンピュータ・プログラム手段またはコンピュータ・プログラムは、情報処理能力を有するシステムに対して特定の機能を直接もしくは他の言語、符号、または異なる物質形式の複製に変換後のいずれかに実行させるように意図された命令のセットの、任意の言語、符号、または表記での任意の表示を含む。
【００８２】
よって、本発明は、上述の機能を生じさせるためのコンピュータ読み取り可能なプログラム・コード手段を内部に実施するコンピュータ使用可能な媒体を備える製品を含む。製品内のコンピュータ読み取り可能なプログラム・コード手段は、コンピュータに対して本発明の方法のステップを生じさせるコンピュータ読み取り可能なプログラム・コード手段を備える。同様に、本発明は、上述の機能を生じさせるためのコンピュータ読み取り可能なプログラム・コード手段を内部に実施するコンピュータ使用可能な媒体を備えるコンピュータ・プログラム製品として実施されてもよい。コンピュータ・プログラム製品内のコンピュータ読み取り可能なプログラム・コード手段は、コンピュータに対して本発明の１つ以上の機能を生じさせるコンピュータ読み取り可能なプログラム・コード手段を備える。さらに、本発明は、機械によって読み取り可能で、本発明の１つ以上の機能を生じさせるための方法ステップを行うために機械によって実行可能な命令プログラムを明確に実施するプログラム記憶装置として実施されてもよい。
【００８３】
なお、以上は、本発明のより適切な目的および実施形態のいくつかを概説したものである。本発明は、多くの適用のために使用されてもよい。よって、特定の仕組みおよび方法について説明したが、本発明の意図および概念は、他の仕組みおよび方法にも好適かつ適用可能である。開示された実施形態に対する修正が、本発明の精神および範囲から逸脱することなく生じうることは、当業者にとって明確であろう。説明した実施形態は、本発明のより顕著な特徴および応用のいくつかを単に例示にするに過ぎないと解釈されるべきである。開示された発明を違うやり方で適用するか、または当業者に周知のやり方で本発明を修正することによって、利益となる他の結果を得ることができる。
【図面の簡単な説明】
【００８４】
【図１】本発明が使用されるであろうシステムであるホスト・センタを示す。
【図２】本発明に係るＰＭＲＳがコンポーネントの１つであるコンピューティング・ユーティリティ構造の一例を示す。
【図３】本発明に係るＰＭＲＳの内部構成の一例を示す。
【図４】ウェブ・サイトについての複合リソース・インスタンスを示す。
【図５】本発明に係る図２の複合リソース・インスタンスに対応するＭＲＳ階層構造を示す。
【図６】本発明に係る図２の複合リソース・インスタンスに対応するＰＲＳ階層構造を示す。
【図７】本発明に係るウェブ・サイト複合リソースについての実現体を示す。
【図８】本発明に係る層属性によって枝刈りされたウェブ・サイト実現体を示す。
【図９】本発明に係るサーバ属性によって枝刈りされたウェブ・サイト実現体を示す。
【図１０】本発明に係る層、サーバ、およびＷＡＳ属性によって枝刈りされたウェブ・サイト実現体を示す。
【図１１】本発明に係る、各コンポーネントがＰＲＳおよびＭＲＳ構造に対応するウェブ・サイト実現体およびそのコンポーネントを示す。
【図１２】本発明に係るウェブ・サイト実現体の構築に関わるリアライザの動作の一例を示す。
【図１３】本発明に係る複合リソースを構築するために使用される処理を示す。
【図１４】本発明に係る高度予約を有するシステム内の複合リソースを構築するために使用される処理を示す。
【図１５】本発明に係るＢＲＤＳとのＰＭＲＳの対話の例を示す。
【図１６】本発明に係る第３者ワークロード管理システムとのＭＲＳの対話の例を示す。
【図１７】本発明に係る新規のベースまたは複合リソース型をシステムに追加するやり方の一例を示す。
【図１８】本発明に係るロード・イベントに基づくリナックス・サーバ・グループ・サービスにリナックス・サーバを追加することを説明する使用事例である。
【図１９】本発明に係るロード・イベントに基づくウェブ・サイト・サービスにウェブ・サーバを追加することを説明にする使用事例である。
【図１】
2007526557.tif 000005
【図２】
2007526557.tif 000006
【図３】
2007526557.tif 000007
【図４】
2007526557.tif 000008
【図５】
2007526557.tif 000009
【図６】
2007526557.tif 000010
【図７】
2007526557.tif 000011
【図８】
2007526557.tif 000012
【図９】
2007526557.tif 000013
【図１０】
2007526557.tif 000014
【図１１】
2007526557.tif 000015
【図１２】
2007526557.tif 000016
【図１３】
2007526557.tif 000017
【図１４】
2007526557.tif 000018
【図１５】
2007526557.tif 000019
【図１６】
2007526557.tif 000020
【図１７】
2007526557.tif 000021
【図１８】
2007526557.tif 000022
【図１９】
2007526557.tif 000023
【手続補正書】
【提出日】平成19年1月29日(2007.1.29)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
コンピューティング・ユーティリティにおいて少なくとも１つのコンピューティング環境をプロビジョニングするための方法であって、
各前記少なくとも１つのコンピューティング環境の記述であって、前記プロビジョニングを実行する第１のサービスの呼び出しを指示し、かつ複合リソース定義である前記記述を使用するステップと、
前記プロビジョニングを実行するために前記第１のサービスを呼び出すステップとを含む、方法。
【請求項２】
前記第１のサービスは、プロビジョニング・リソース・サービスであって、前記方法は、前記第１のサービスが各前記少なくとも１つのコンピュータ環境を管理するための管理リソース・サービスを使用可能にするステップをさらに含む、請求項１に記載の方法。
【請求項３】
ベース・リソースの各型および複合リソースの各型に関連した少なくとも１つのプロビジョニング・リソース・サービスがある、請求項２に記載の方法。
【請求項４】
前記プロビジョニング・リソース・サービスは、複数のプロビジョニング・インスタンスを提供する、請求項２に記載の方法。
【請求項５】
前記呼び出しステップは、
前記少なくとも１つのコンピューティング環境を満足する少なくとも１つのプランを取得するステップと、
特定のプランを選択するステップと、
前記特定のプランに対応するベース・リソースを前記コンピューティング・ユーティリティに対して要求するステップと、
前記特定のプランに対応する前記ベース・リソースが取得されるまで、前記選択ステップおよび前記要求ステップを繰り返すステップと、
前記ベース・リソースを前記コンピューティング環境のインスタンスに構成するステップとを含む、請求項２に記載の方法。
【請求項６】
前記ベース・リソースは、
リソースがプロビジョンされるであろう指定時間と、
リソースの使用可能期間と、
リソース別の選択基準とを備える要求基準群から取得される要求基準を満足する、請求項５に記載の方法。
【請求項７】
前記プロビジョニング・リソース・サービスは、プロビジョニング・リソース・サービスの群からなり、プロビジョニング・リソース・サービスの前記群の各要素は、前記複合リソース記述内のリソースの特定の型に関連付けられている、請求項２に記載の方法。
【請求項８】
前記呼び出しステップは、前記複合リソース記述に従って前記群の各要素を帰納的に使用することによって、前記コンピューティング環境についての前記プロビジョニング・リソース・サービスを使用するステップをさらに含む、請求項７に記載の方法。
【請求項９】
各ベース・リソースは、ベース・リソース・インスタンスを有し、各ベース・リソース・インスタンスに関連した少なくとも１つの管理リソース・サービスがある、請求項２に記載の方法。
【請求項１０】
前記管理リソース・サービスは、管理リソース・サービスの群からなり、管理リソース・サービスの前記群の各要素は、前記複合リソース記述内のリソースの特定の型に関連付けられている、請求項２に記載の方法。
【請求項１１】
前記プロビジョニング・リソース・サービスは、プロビジョニング・リソース・サービスの群からなり、プロビジョニング・リソース・サービスの前記群の各要素は、前記複合リソース記述内のリソースの特定の型に関連付けられており、
前記呼び出しステップは、前記複合リソース記述に従って前記群の各要素を帰納的に使用することによって、前記コンピューティング環境についての前記プロビジョニング・リソース・サービスを使用するステップをさらに含み、
前記少なくとも１つのプランの前記取得ステップは、副リソース毎に少なくとも１つのプランを帰納的に取得して、結果を組み合わせるステップを含み、
前記ベース・リソースの前記コンピューティング環境のインスタンスへの前記構成ステップは、各副リソースに対応するベース・リソースを帰納的に構成して、結果を構成するステップを含む、請求項５に記載の方法。
【請求項１２】
前記取得ステップは、取得された前記プランを制限する少なくとも１つの条件を指定するステップをさらに含む、請求項５に記載の方法。
【請求項１３】
前記プランの前記選択ステップは、
コストと、
性能と、
満たされた選択数と、
これらの選択基準の任意の組み合わせとを備える選択基準群から取得される選択基準を満足する、請求項５に記載の方法。
【請求項１４】
ベース・リソースに対する予約を割り当てられたベース・リソースに変換するステップをさらに含む、請求項５に記載の方法。
【請求項１５】
前記取得ステップは、
前記コンピューティング環境の前記記述の変更と、
ベース・リソース型のセットの変更と、
複合リソース型のセットの変更と、
これらの変更の任意の組み合わせとを備える反復基準群から取得される反復基準に従って繰り返される、請求項５に記載の方法。
【請求項１６】
前記選択および要求ステップは、
前記選択基準の変更と、
リソースの使用可能性の変更と、
リソースの予約ステータスの変更と、
前記少なくとも１つのプランの変更と、
これらの変更の任意の組み合わせとを備える反復基準群から取得される反復基準に従って繰り返される、請求項５に記載の方法。
【請求項１７】
前記反復および変換ステップを、前記ベース・リソースが取得されるまで繰り返すステップをさらに含む、請求項１５に記載の方法。
【請求項１８】
前記取得、選択、要求、および構成ステップは、少なくとも１つの管理リソース・サービスによって少なくとも１回呼び出されて、リソースを前記コンピューティング環境に追加する、請求項５に記載の方法。
【請求項１９】
ベース・リソース型をオペレーティング・コンピューティング・ユーテリティに追加するステップを含む方法であって、前記追加ステップは、
ベース・リソース・ライブラリ・サービスを提供して、前記ベース・リソース型の任意のインスタンスを表すステップと、
前記ベース・リソース型の任意のインスタンスを前記ベース・リソース・ライブラリ・サービスに追加するステップと、
前記ベース・リソース型についてのプロビジョニング・リソース・サービスの実施を開発するステップと、
前記プロビジョニング・リソース・サービスを起動するステップと、
前記ベース・リソース型についての管理リソース・サービスの実施を作成するステップとを含む、方法。
【請求項２０】
任意の複合リソース型の任意のプロビジョニング・リソース・サービスを更新して、前記ベース・リソース型についての前記プロビジョニング・リソース・サービスを使用するステップと、
任意の複合リソース型の任意の管理リソース・サービスを更新して、前記ベース・リソース型についての前記管理リソース・サービスを使用するステップとをさらに含む、請求項２２に記載の方法。
【請求項２１】
ベース・リソース型の前記追加ステップは、サービス・プロバイダによって実行されて、前記サービス・プロバイダの少なくとも１人の顧客に対するサービス提供を増加させる、請求項２２に記載の方法。
【請求項２２】
複合リソース型をオペレーティング・コンピューティング・ユーテリティに追加するステップを含む方法であって、前記追加ステップは、
前記複合リソース型の副リソースについてのプロビジョニング・リソース・サービスを使用する、前記複合リソース型についてのプロビジョニング・リソース・サービスの実施を作成するステップと、
前記プロビジョニング・リソース・サービスを起動するステップと、
前記複合リソース型の副リソースについての管理リソース・サービスを使用する、前記複合リソース型についての管理リソースサービスの実施を作成するステップとを含む、方法。
【請求項２３】
複合リソース型の任意のプロビジョニング・リソース・サービスを更新して、前記複合リソース型についての前記プロビジョニング・リソース・サービスを使用するステップと、
複合リソース型の任意の管理リソース・サービスを更新して、前記複合リソース型についての前記管理リソース・サービスを使用するステップとをさらに含む、請求項２５に記載の方法。
【請求項２４】
コンピューティング環境についての少なくとも１つの第３者ワークロード管理システムをコンピューティング・ユーティリティに適応させるための方法であって、前記適応ステップは、
前記少なくとも１つの第３者ワークロード管理システムの状態を解釈する管理リソース・サービスを開発するステップと、
前記コンピューティング環境を備えるベース・リソースのセットを前記少なくとも１つの第３者ワークロード管理システムの状態によって示された通りに修正するステップとを含む、方法。
【請求項２５】
前記少なくとも１つのコンピューティング環境の少なくとも１つのコンピューティング環境から、前記少なくとも１つのベース・リソースから少なくとも１つのベース・リソースを返すためのイベントを受信するステップと、
前記少なくとも１つのコンピューティング環境の少なくとも１つのコンピューティング環境から前記少なくとも１つのベース・リソースを構成解除するステップと、
前記少なくとも１つのベース・リソースを前記コンピューティング・ユーティリティへ返すステップと
前記少なくとも１つのベース・リソースを他のコンピューティング環境へ割り当てるために使用可能にするステップとをさらに含む、請求項２に記載の方法。
【請求項２６】
単一のコンピューティング環境内にリソース型のすべてのインスタンスについての１つの管理リソース・サービスがある、請求項９に記載の方法。
【請求項２７】
前記少なくとも１つのコンピューティング環境の少なくとも１つに対する顧客要求を受信するステップをさらに含む、請求項１に記載の方法。
【請求項２８】
前記複合リソース定義は、リソースの帰納的な組み合わせであり、前記組み合わせは、
少なくとも１つのベース・リソースと、
少なくとも１つの他の複合リソースと、
ベース・リソースと複合リソースとの任意の組み合わせからなる組み合わせの群から取得される組み合わせである、請求項１に記載の方法。
【請求項２９】
前記管理リソース・サービスは、管理リソース・サービスの前記群の特定の要素が使用可能な少なくとも１つの動作を使用し、前記動作は、管理リソース・サービスの前記群の少なくとも１つの要素によって実行され、前記少なくとも１つの動作は、
前記コンピューティング環境からの監視データに基づいて、少なくとも１つの数的指標を送付することと、
前記コンピューティング環境からの監視データに基づいて、少なくとも１つのイベントを送付することと、
前記コンピューティング環境の状態を修正することと、
少なくとも１つの特定の数的指標に応答して、少なくとも１つの特定の動作を呼び出して前記コンピューティング環境を修正することと、
少なくとも１つの特定のイベントに応答して、少なくとも１つの特定の動作を呼び出して前記コンピューティング環境を修正することとを備える動作の群から取得される、請求項１１に記載の方法。
【請求項３０】
請求項１−２９のいずれかに記載の方法の各ステップをコンピュータに実行させるためのコンピュータプログラム
【請求項３１】
コンピューティング・ユーティリティにおいて少なくとも１つのコンピューティング環境をプロビジョンするための装置であって、
各前記少なくとも１つのコンピューティング環境の記述であって、前記プロビジョニングを実行する第１のサービスの呼び出しを指示し、かつ複合リソース定義である前記記述を使用するための第１のプロセッサ・モジュールと、
前記プロビジョニングを実行するために前記第１のサービスを呼び出すための第２のプロセッサ・モジュールとを備える、装置。