(57)【要約】【課題】プロビジョニングデータ処理システムにおいてリソースを識別、予約、および論理的にプロビジョニングする方法、システム、およびプログラム【解決手段】データ処理システムでリソースを論理的にプロビジョニングする方法、システム、およびコンピュータプログラムを開示する。プロビジョニング環境でプロビジョニングさせるべき一又は複数のリソースの要求を受信する。要求されるリソースは複数の異なる利用可能なタイプのリソースでよい。要求されるタイプのリソースの特定のインスタンスを、異なるタイプの未割り当ての利用可能なリソースのグループから選択する。選択されたリソースは、この要求を履行するため、予約済みとして示され、もはや未割当でも利用可能でもなくなる。選択されたリソースは、プロビジョニング環境における選択されたリソースインスタンス間の論理的な関係を確立することによって論理的にプロビジョニングされる。【選択図】図５
2007520814.tif 000002
【特許請求の範囲】
【請求項１】
データ処理システムにおいてリソースを論理的にプロビジョニングする方法であって、前記方法が、
プロビジョニング環境で複数のリソースのうちの１つについての要求を受信するステップであって、前記複数のリソースのうちの前記１つが複数の異なるタイプのリソースのうちの１つであるものと、
前記複数のリソースのうちの前記１つの特定のインスタンスを、前記複数の異なるタイプのリソースのうちの未割り当ての利用可能なリソースのグループから選択するステップと、
前期選択した特定のインスタンスと他のリソースとの論理的な関係を確立することによって、前記要求を履行するために前記選択した特定のインスタンスを論理的にプロビジョニングするステップと
を有することを特徴とする方法。
【請求項２】
前記選択した特定のインスタンスが使用するために必要な前記複数のリソースのうちの他のものを識別するステップをさらに有することを特徴とする請求項１に記載の方法。
【請求項３】
前記他のものの各々の特定のインスタンスを、前記選択した特定のインスタンスが使用するために必要な前記複数の異なるタイプのリソースのうちの未割り当ての利用可能なリソースのグループから選択するステップと、
前記他のものの各々の間に論理的な関係を確立することによって、要求を履行するために前記他のものの各々について前記選択した特定のインスタンスを論理的にプロビジョニングするステップと
をさらに有することを特徴とする請求項１に記載の方法。
【請求項４】
前記選択した特定のインスタンスが予約される過程にあることを示すステップであって、前記選択した特定のインスタンスが予約される過程にあるとして示された後は選択に利用できないものをさらに有することを特徴とする請求項１に記載の方法。
【請求項５】
前記未割り当ての利用可能なリソースのグループが、前記複数のリソースのうちの他のものと予め割り当てられた論理的対応関係を含まないステップをさらに有することを特徴とする請求項１に記載の方法。
【請求項６】
状態変数を前記複数のリソースの各々に対応付けるステップと、
前記状態変数を利用して前記複数のリソースの各々が選択に利用可能かどうかを示すステップと
をさらに有することを特徴とする請求項１に記載の方法。
【請求項７】
状態変数を前記複数のリソースの各々に対応付けるステップと、
前記状態変数を利用して、前記複数のリソースの各々が共有されているかどうかを示すステップと
をさらに有することを特徴とする請求項１に記載の方法。
【請求項８】
状態変数を前記複数のリソースの各々に対応付けるステップと、
前記状態変数を利用して、前記複数のリソースの各々が予約されているかどうかを示すステップであって、予約済みのリソースが前記プロビジョニング環境と確立された論理的な関係をもつものと
をさらに有することを特徴とする請求項１に記載の方法。
【請求項９】
前記プロビジョニング環境のトポロジーを作成するステップであって、前記トポロジーが前記複数の異なるタイプのリソースのレイアウトを含むものと、
前記レイアウトが、前記複数の異なるタイプのリソース間の関係を定義するステップと
をさらに有することを特徴とする請求項１に記載の方法。
【請求項１０】
前記レイアウトが定義する前記関係を利用して、前記選択した特定のインスタンスが使用するために必要な前記複数のリソースのうちの他のものを識別するステップをさらに有することを特徴とする請求項９に記載の方法。
【請求項１１】
前記特定のインスタンスに対応付けることになる前記複数のリソースの他のものを判定するステップをさらに有することを特徴とする請求項１０に記載の方法。
【請求項１２】
前記複数のリソースの中から、前記特定のインスタンスに依存する他のものを判定するステップをさらに有することを特徴とする請求項１０に記載の方法。
【請求項１３】
データ処理システムにおいてリソースを論理的にプロビジョニングするシステムであって、
前記システムに内蔵されて、プロビジョニング環境で複数のリソースのうちの１つについての要求を受信するためのコードを実行するＣＰＵであって、前記複数のリソースのうちの前記１つが複数の異なるタイプのリソースのうちの１つであるものと、
前記システムに内蔵されて、前記複数の異なるタイプのリソースの未割り当ての利用可能なリソースのグループから、前記複数のリソースの前記１つの特定のインスタンスを選択するためのコードを実行するＣＰＵと、
前記システムに内蔵されて、前記選択した特定のインスタンスと他のリソースとの論理的な関係を確立することによって、前記要求を履行するために前記選択した特定のインスタンスを追加して前記選択した特定のインスタンスを論理的にプロビジョニングするためのコードを実行するＣＰＵと
を有することを特徴とするシステム。
【請求項１４】
前記システムに内蔵されて、前記複数のリソースの中から、前記選択した特定のインスタンスが使用するために必要な他のものを識別するためのコードを実行するＣＰＵをさらに有することを特徴とする請求項１３に記載のシステム。
【請求項１５】
前記システムに内蔵されて、前記複数の異なるタイプのリソースのうち、前記選択した特定のインスタンスが使用するために必要な未割り当ての利用可能なリソースのグループから、前記他のものの各々について特定のインスタンスを選択するためのコードを実行するＣＰＵと、
前記システムに内蔵されて、前記他のものの各々の間の論理的な関係を確立することによって、要求を履行するために前記他のものの各々について前記選択した特定のインスタンスを論理的にプロビジョニングするためのコードを実行するＣＰＵと
をさらに有することを特徴とする請求項１３に記載のシステム。
【請求項１６】
前記選択した特定のインスタンスが予約される過程にあることを示す状態変数であって、前記選択した特定のインスタンスが、予約される過程にあると示された後は選択のために利用できないものをさらに有することを特徴とする請求項１３に記載のシステム。
【請求項１７】
前記未割り当ての利用可能なリソースのグループが前記複数のリソースの他のどの１つとも予め割り当てられた論理的対応関係を含まないことをさらに特徴とする請求項１３に記載のシステム。
【請求項１８】
前記複数のリソースの各々に対応付ける状態変数であって、
前記状態変数を利用して前記複数のリソースの各々が選択に利用可能かどうかを示すためのものをさらに有することを特徴とする請求項１３に記載のシステム。
【請求項１９】
前記複数のリソースの各々に対応する状態変数であって、
前記状態変数を利用して前記複数のリソースの各々が共有されているかどうかを示すためのものをさらに有することを特徴とする請求項１３に記載のシステム。
【請求項２０】
前記複数のリソースの各々に対応する状態変数であって、
前記状態変数を利用して前記複数のリソースの各々が予約されているかどうかを示すためのものであり、予約済みリソースが前記プロビジョニング環境と確立された論理的な関係をもつことをさらに特徴とする請求項１３に記載のシステム。
【請求項２１】
前記プロビジョニング環境のために作成されるトポロジーであって、前記複数の異なるタイプのリソースのレイアウトを含み、
前記レイアウトが前記複数の異なるタイプのリソース間の関係を定めるもの
をさらに有することを特徴とする請求項１３に記載のシステム。
【請求項２２】
前記レイアウトが定義する前記関係を利用して、前記複数のリソースのうち、前記選択した特定のインスタンスが使用するために必要な他のものを識別することをさらに特徴とする請求項２１に記載のシステム。
【請求項２３】
前記システムに内蔵されて、前記複数のリソースのうち前記特定のインスタンスに対応する他のものを判定するためのコードを実行するＣＰＵをさらに有することを特徴とする請求項２２に記載のシステム。
【請求項２４】
前記システムに内蔵されて、前記複数のリソースのうち前記特定のインスタンスに依存する他のものを判定するためのコードを実行するＣＰＵを有することを特徴とする請求項２２に記載のシステム。
【請求項２５】
リソースを論理的にプロビジョニングするデータ処理システムのコンピュータプログラムで、前記プログラムが、
プロビジョニング環境で複数のリソースのうちの１つについての要求を受け取る命令手段であって、前記複数のリソースのうちの１つが複数の異なるタイプのリソースのうちの１つであるものと、
前記複数の異なるタイプのリソースのうち未割り当てで利用可能なリソースのグループから、前記複数のリソースのうちの前記１つの特定のインスタンスを選択する命令手段と、
前記選択した特定のインスタンスと他のリソースとの論理的な関係を確立することによって、要求を履行するために前記選択した特定のインスタンスを追加して前記選択した特定のインスタンスを論理的にプロビジョニングする命令手段と
を有することを特徴とするプログラム。
【請求項２６】
前記複数のリソースの中から、前記選択した特定のインスタンスが使用するために必要な他のものを識別する命令手段をさらに有することを特徴とする請求項２５に記載のプログラム。
【請求項２７】
前記選択した特定のインスタンスが使用するために必要な前記複数の異なるタイプのリソースのうち未割り当てで利用可能なリソースのグループから、前記他のもののそれぞれについて特定のインスタンスを選択する命令手段と、
前記他のものの各々と前記プロビジョニング環境との論理的な関係を確立することによって要求を履行するために、前記他のものの各々について前記選択した特定のインスタンスを追加して、前記他のものの各々について前記選択した特定のインスタンスを論理的にプロビジョニングする命令手段と
をさらに有することを特徴とする請求項２５に記載のプログラム。
【請求項２８】
前記選択した特定のインスタンスを予約される過程にあることを示す命令手段であって、前記選択した特定のインスタンスが予約される過程にあると示された後は選択に利用できないものをさらに有することを特徴とする請求項２５に記載のプログラム。
【請求項２９】
前記未割当で利用可能なリソースのグループが、前記複数のリソースのうちの他のどの１つとも予め割り当てられた論理的対応関係を含まないことをさらに特徴とする請求項２５に記載のプログラム。
【請求項３０】
状態変数を前記複数のリソースの各々に対応付ける命令手段と、
前記状態変数を利用して、前記複数のリソースの各々が選択に利用可能かどうかを示す命令手段と
をさらに有することを特徴とする請求項２５に記載のプログラム。
【請求項３１】
状態変数を前記複数のリソースの各々と対応付ける命令手段と、
前記状態変数を利用して、前記複数のリソースの各々が共有されているかどうかを示す命令手段と
をさらに有することを特徴とする請求項２５に記載のプログラム。
【請求項３２】
状態変数を前記複数のリソースの各々に対応付ける命令手段と、
前記状態変数を利用して、前記複数のリソースの各々が予約されているかどうかを示す命令手段であって、予約済みリソースが前記プロビジョニング環境と確立された論理的な関係をもつもの
をさらに有することを特徴とする請求項２５に記載のプログラム。
【請求項３３】
前記プロビジョニング環境のトポロジーを作成する命令手段であって、前記トポロジーが前記複数の異なるタイプのリソースのレイアウトを含み、
前記レイアウトが前記複数の異なるタイプのリソース間の関係を定義するもの
をさらに有することを特徴とする請求項２５に記載のプログラム。
【請求項３４】
前記レイアウトが定義する前記関係を利用して、前記選択した特定のインスタンスが使用するために必要な前記複数のリソースのうち他のものを識別する命令手段をさらに有することを特徴とする請求項３３に記載のプログラム。
【請求項３５】
前記特定のインスタンスに対応付ける前記複数のリソースのうち他のものを判定する命令手段をさらに有することを特徴とする請求項３４に記載のプログラム。
【請求項３６】
前記特定のインスタンスに依存する前記複数のリソースのうち他のものを判定する命令手段を有することを特徴とする請求項３４に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的にリソースプロビジョニングおよび自動プロビジョニングシステムに関係し、具体的には該システムにおいて特定のリソースを識別、予約、および論理的にプロビジョニングする方法、システム、およびプログラムに関係する。
【背景技術】
【０００２】
リソースプロビジョニングシステムは比較的新種のシステムである。これらのシステムはユーザーが予め選択したコンピューティングリソースの構成を可能にする。コンピュータリソースには、サーバー、ファイヤウォール、ソフトウェアが含まれる。ユーザーがプロビジョニングするべきあるリソースを選択してしまえば、プロビジョニングシステムが選択されたリソースのある構成を支援する。例えば、１つのネットワークインターフェースを有するサーバーをある特定の仮想ローカルエリアネットワーク（ＶＬＡＮ）に配置することにする場合、プロビジョニングシステムはＶＬＡＮを１セットのスイッチ上に構成し、サーバーを接続するスイッチポートをＶＬＡＮ内に構成する助けをする。しかし、既存のシステムでは利用可能なリソースを動的かつ自動的に識別し、リソースを予約し、さらにリソース要求を満たすためにリソース間の新たな関係を確立する方法を提供できていない。
【０００３】
リソースをプロビジョニングするプロセスは非常に複雑であり、多くの様々な次元で異なりうる。各リソースの種類によってプロビジョニングプロセスが異なる。例えば、コンピュータのサーバーを構成するプロセスは、ネットワークの記憶装置やソフトウェアを構成するプロセスとは異なる。同種のリソースであっても、多くのバリエーションが存在することもある。例えば、ソフトウェア構成をサポートするプロビジョニングプロセスは、ソフトウェアパッケージが異なればかなり異なる。
【０００４】
プロビジョニングシステムでは、リソースを多数のリソースタイプに分割できる。これには、サーバー、ＶＬＡＮ、ＩＰアドレス、およびソフトウェアが含まれるが、それだけに限定されない。リソースインスタンスはリソースタイプによって分類できる。例えば、サーバーは１つのタイプのリソースである。製造番号が１２３４５６のこの特定のサーバーは特定の個別のサーバーであり、本明細書においてサーバーの「インスタンス」又は「特定の」サーバーと呼ぶ。本明細書において、「リソース」という用語はリソースインスタンスを意味すると理解するべきである。
【０００５】
また、リソースのタイプは数セットのリソースタイプの属性によって細分できる。例えば、サーバーのタイプは、サーバーの型番によって互いに素の部分集合に分割できる。ある部分集合のリソースタイプはそのタイプとサブタイプによって、すなわちあるセットのリソースの属性の記述によって記述できる。リソース要求はあるタイプ又はサブタイプのリソースインスタンスの要求として表現される。
【０００６】
リソースのタイプ又はサブタイプに分類することに加えて、リソースインスタンスは同じタイプ又は異なるタイプの他のリソースインスタンスと予め定められた関係をもつこともできる。例えば、すでにネットワークにワイヤ接続されているサーバーの場合、サーバーインスタンスのネットワークインターフェースコネクタはスイッチインスタンスのスイッチポートインスタンスと物理的な関係をもつ。別の例は、ＶＬＡＮインスタンスとサブネット（すなわち、ＩＰアドレスインスタンスのセット）との関係であろう。リソースインスタンスは、上記第１例で述べたように、物理的に接続される場合互いに物理的に関係しているため、又は上記第２例で述べたように、特定の不変の関係を定義することによって論理的に接続されるため、この予め定められた関係が存在する。
【０００７】
現在、ほとんどのプロビジョニングシステムは、リソース間の関係でリソースを識別および予約することよりも、リソースのプロビジョニングメカニズムに重点を置いている。例えば、１つのネットワークインターフェースを有するサーバーを特定のＶＬＡＮに配置しようとする場合、リソースプロビジョニングメカニズムはＶＬＡＮを１セットのスイッチ上に構成して、サーバーを接続するスイッチポートをＶＬＡＮ内にあるように構成する方法を提供する。プロビジョニング要求を履行するために、このようなシステムはサーバープールという考えを利用する。あるプール内のサーバーは特定のファイヤウォールインスタンス、ＩＰアドレスインスタンス、ＶＬＡＮインスタンスなどの特定のリソースインスタンスとすでに対応関係をもっている。これらサーバーが、例えばグラフィカル・ユーザー・インターフェース（ＧＵＩ）により、アドミニストレータが割り当てるこれらのリソースインスタンスとすでに物理的に接続されているからである。これらのシステムのいずれも、プロビジョニング要求に利用する複数の関係リソースインスタンスを動的に識別又は予約するプログラム能力を提供していない。
【０００８】
前述のリソースプロビジョニングメカニズムを利用して、必要なユーザー環境を作成又は修正するために行うべき変更は、既存のリソース表現間に対応関係を作ることによって記録される。リソース表現間に論理的な対応関係を作るプロセスを論理的プロビジョニングという。例えば、プロビジョニング要求が、ある特定のタイプのソフトウェアがサーバーにインストールされるべきことを示している場合、そのソフトウェアリソースはそのサーバーに論理的に対応付けられなければならない。別の例では、予約済みＩＰアドレスを予約済みサーバーのネットワークインターフェースに対応付けるであろう。論理的プロビジョニングは何を行うべきかを示し、後に物理的リソースへの変更を推進するために使える。ここでも、既存のシステムは論理的にリソースをプロビジョニングするメカニズムを提供していない。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
そのため、プロビジョニングデータ処理システムにおいて、特定のリソースインスタンスを動的に識別し、予約し、論理的にプロビジョニングする方法、システム、およびコンピュータプログラムが必要となる。
【課題を解決するための手段】
【００１０】
プロビジョニングデータ処理システムにおいて、特定のプロビジョニング要求を履行するための特定のリソースインスタンスを識別し、その要求を履行するために必要な数の特定のリソースを選択するように特定のリソースの選択を制御し、選択した特定のリソース間で新たな対応関係を作って識別したリソースを論理的にプロビジョニングする方法、システム、およびコンピュータプログラムを開示する。
【００１１】
１セットのリソースの要求を受信する。要求される各リソースは利用可能な複数の異なるタイプのリソースのうちの１つである。特定のリソースタイプの選択は、他のリソースタイプの選択を暗に含み、又は他のリソースタイプの選択を必要とすることがある。例えば、サーバーの選択はある数のネットワークインターフェースの選択を暗に含み、負荷分散装置の選択は一又は複数のＶＬＡＮの選択を必要とすることがある。暗に含意されるおよび必要とされるリソースは、設定される又は要求されるリソースに追加される。要求される各タイプのリソースの特定のインスタンスは、利用可能な未割り当てのリソースのグループから選択される。選択されたリソースは、この要求や他の要求を履行するために予約されていると指示されて、そのためもはや未割り当てや利用可能ではなくなる。さらに選択されたリソースは、選択されたリソースインスタンス間の論理的な関係を確立することによって論理的にプロビジョニングされる。
【００１２】
本発明の上記並びに追加の目的、特徴および利点は、以下詳細に記載する説明で明らかになるであろう。
【発明を実施するための最良の形態】
【００１３】
本発明の好適な実施例とその利点は図面を参照することによってよりよく理解され、添付する図面の一致する同じ部分には同じ番号を使用している。
【００１４】
本発明は、特定のプロビジョニング要求を履行するために使用する特別なリソースインスタンスを識別し、それを予約し、予約したリソースインスタンス間に新たな関係を割り当てることによってそれを論理的にプロビジョニングするために使える一般的な方法を提供する。本発明は、リソースのグループからリソースの特定のインスタンスを選択する動的かつ自動的な方法、システム、およびプログラムを提供し、選択したリソースインスタンスは、現在、ユーザー要求を履行し、さらに選択したリソースインスタンスと選択したリソースインスタンスをサポートするのに必要な他のリソースタイプのリソースインスタンスとの関係を確立するために予約されている過程にあることを示す。例えば、サーバーを選択した場合、適切なＩＰアドレス、ＶＬＡＮ、負荷分散装置、およびファイヤウォールはサーバーの接続性を提供するために必要な他のリソースである。
【００１５】
異なるタイプのリソース間のいくつかの関係は予め定義される。これらの関係は、あらゆる他のタイプの支援リソースも選択されて、要求される特定のセットのリソースインスタンスと合わせてユーザーに要求される環境に追加されることを保証するために自動的かつ動的に使用される。
【００１６】
所定のプロビジョニング環境の所定の関係の定義のセットを使用して、複数のリソース要求を履行し、そのプロビジョニング環境で特定の方法でリソースを論理的にプロビジョニングできる。異なるプロビジョニング環境では一般に、異なる関係の定義を必要とする。その環境が異なる関係を定義し、論理的なプロビジョニングプロセスが異なるものになるからである。例えば、保護されたプロビジョニング環境は対応関係としてＶＬＡＮとファイヤウォールのリソースを有するが、保護されていないプロビジョニング環境ではこれらのいずれかがないかもしれない。
【００１７】
プロビジョニング環境に異なるリソースタイプ、またそのため関係が追加される場合、すなわち、プロビジョニング環境が変化する場合、あるいは論理的なプロビジョニングステップが変化する場合、新たな関係の定義が用いられなければならない。本特許で定義されるプロセスでは、リソースを選択、予約、論理的にプロビジョニングできる包括的なプロセスへのインプットとしてリソース関係を使用する。
【００１８】
本発明の好適な実施例では、各リソースインスタンスを少なくとも２つの状態変数に対応付ける。第１の状態変数はリソースインスタンスが共有されるかどうかを識別する。第２の状態変数は、リソースインスタンスの現在の状態を示す。第２の状態変数に定義される状態には、「利用可能」、「予約中」、「予約済み」が含まれる。これらの解釈は以下のとおりである。
利用可能―リソースインスタンスを自由に使える。使用されていない。
予約中−リソースインスタンスは自由に使えない。要求を履行するために選択されており、論理的にプロビジョニングされる過程にある。
予約済み−リソースインスタンスは自由に使えない。所有者に割り当てられており、論理的にプロビジョニング済みである。
これらリソースの状態を実施するメカニズムは、本発明の方法に含まれる。
【００１９】
図１は、本発明を実施できるデータ処理システムのネットワークの絵図を示す。ネットワークデータ処理システム１００は、本発明を実施できるコンピュータのネットワークである。ネットワークデータ処理システム１００は、ネットワークデータ処理システム１００内で互いに接続される様々な機器やコンピュータ間の通信リンクを提供するのに用いる媒体であるネットワーク１０２を内蔵する。ネットワーク１０２は、ワイヤ、ワイヤレス通信リンク、又は光ファイバーケーブルなどの接続を含んでもよい。
【００２０】
図示する例では、データベースサーバー１０４をネットワーク１０２に接続し、記憶装置１０６へのアクセスを提供する。ウエブサーバー１０８と料金請求サーバー１１０もネットワーク１０２に接続する。サーバーグループ１２２をルーター／ファイヤウォール１２０を介してネットワークに接続する。データベースサーバー１０４、ウエブサーバー１０８、料金請求サーバー１１０、およびサーバーグループ１２２は、ネットワークデータ処理システム１００のリソースの例である。事実、ルーター自体、ファイヤウォール、およびその他ハードウェアやソフトウェアのエレメントも、ネットワークデータ処理システム１００の一部であるリソースの例である。これらリソースはプロビジョニングシステムで配置、構成されうるエンティティでもある。
【００２１】
自動プロビジョニングシステムに含まれるコンピューティングリソースは異なるタイプやサブタイプに分類でき、タイプの細分性の程度は様々に異なる。各タイプは、そのリソースに共通の１セットの属性や仕様に対応付けられる。例えば、リソースのタイプはサーバーハードウェア、ネットワークハードウェア、記憶装置ハードウェア、オペレーティングシステムソフトウェア、データベースミドルウェアソフトウェア、アプリケーションソフトウェア、モニタリングソフトウェアに分類できよう。リソースのタイプはさらにサブタイプに分割できる。サーバータイプのリソースサブタイプの例は、ＩＢＭ  ｐシリーズサーバーやＳｕｎ  Ｓｐａｒｃサーバーなどがある。リソースタイプのインスタンスは、リソースエンティティであり、これはそのリソースのサブタイプによって分類される。
【００２２】
さらに、クライアント１１２、１１４、１１６がネットワーク１０２に接続される。これらクライアントとは、例えばパーソナルコンピュータやネットワークコンピュータであろう。図示する例では、データベースサーバー１０４が、ブートファイル、オペレーティングシステムイメージ、アプリケーションなどのデータをクライアント１１２、１１４、１１６に提供する。クライアント１１２、１１４、１１６はサーバー１０４のクライアントである。ネットワークデータ処理システム１００は、図示していない追加のサーバー、クライアント、およびその他の機器を含んでもよい。
【００２３】
具体的には、アドミニストレータクライアント１１６は、プロビジョニングアドミニストレータがネットワークデータ処理システム１００のリソースを定義しプロビジョニングするために使うクライアントである。
【００２４】
図１は例示を目的とし、本発明のアーキテクチャ上の制限を意図しているわけではない。
【００２５】
図２は、すべてのリソースが初期の構成で構成される場合において、要求が出される前のプロビジョニング環境のリソースを示すブロック図である。例えば、サーバーはすべて構築／待機  ＶＬＡＮに待機させられ、初期の「利用可能な」状態になっている。図示する他のリソースは何らかの適した初期構成で物理的かつ論理的に接続されるように構成される。図２および図３から図４では、リソースのセットは保護された２層プロビジョニング環境２００を表す。図では、ＶＬＡＮは「パイプ」を使って示されている。各々にそのタイプのＶＬＡＮに有効と考えられる範囲の数字が付されている。図２では、これらは各ＶＬＡＮのサブタイプの利用可能なＶＬＡＮの範囲を表す。図２および図３から図４では、ＶＬＡＮの一部は「利用可能」以外の状態になっていてもよい。ナンバリングは表記上の便宜のためのものであり、このアーキテクチャの必須の特徴ではないことに注意する。短いパイプ（図では番号を振っていない）は「コミュニティ」ＶＬＡＮである。コミュニティＶＬＡＮとは、あるスイッチハードウェアによってサポートされるＶＬＡＮの特殊タイプである。
【００２６】
プロビジョニング環境２００は、ウエブサーバー又はデータサーバー（図３から図４では２０２および２０４で示す）のいずれかとして使用できる待機（すなわち、利用可能な）サーバー２４０を内蔵する。各サーバーは、図２および図３から図４では図示していない２枚のネットワークインターフェースカード（ＮＩＣ）を含む。各ＮＩＣは図２および図３から図４では図示していないスイッチポートに接続される。さらに、各ＶＬＡＮはそれに割り当てられる多数のＩＰアドレスを有する。ＩＰアドレスは図２および図３から図４では図示していない。他のリソースをすべて図示しているわけではない。
【００２７】
環境外部からのトラフィックは、インターネット２０６から公衆インターネットセグメントＶＬＡＮ２１４を通過する。それからフロントエンドファイヤウォール２１６を通過して、ファイヤウォール／負荷分散装置セグメント２１８に向かう。そこから、負荷分散装置２２０を通過してプライマリウエブフロントエンドクロスバーＶＬＡＮ２２２とコミュニティウエブフロントエンドクロスバー２２４に向かう。図には示していないが、プライマリ２２２とコミュニティ２２４ウエブフロントエンドクロスバーＶＬＡＮは、それぞれ（１００〜２９９）などの有効かつ固有の番号の集合をもつことができる。この例示的なプロビジョニング環境ではすべてのトラフィックが負荷分散装置を物理的に通過するが、これはすべてのトラフィックが負荷分散されることを意味しているわけではない。ウエブサーバーの部分集合全体を負荷分散することは任意である。
【００２８】
図３および図４は、多数の要求を行って、本発明に従いリソースをプロビジョニングした後の１セットのリソースを図示するブロック図である。図３および図４に示すように、サーバーをプロビジョニングし終えたら、コミュニティウエブフロントエンドクロスバー２２４からのトラフィックはウエブサーバー２０２に届く。ウエブサーバー２０２からデータサーバー２０４へのトラフィックは、コミュニティウエブバックエンドクロスバーＶＬＡＮ２２６からプライマリウエブバックエンドクロスバーＶＬＡＮ２２８を通って、バックエンドファイヤウォール２３０に、さらにプライマリデータクロスバーＶＬＡＮ２３２とコミュニティデータクロスバーＶＬＡＮ２３４に向かう。最終的にはデータサーバーに２０４に届く。
【００２９】
プロビジョニング要求は、要求を履行するために必要な様々な量の異なるリソースのタイプを識別する。しかし、ユーザーは自分のアプリケーションが利用できるリソースしか知らず、プロビジョニング環境全体の詳しい知識がない場合があるため、ユーザーの要求が必要なすべてのリソースのリストを含むことは望ましいわけでも実行可能なわけでもない。例えば、ユーザー要求によりサーバーが必要な場合、他のリソースも必要である。これには、サーバーがもっているかもしれないＮＩＣ、ＮＩＣに接続されるスイッチポート、これらのスイッチポートを追加するべきＶＬＡＮを含むが、それだけに限定されない。また、論理的プロビジョニングの一部として、リソース間の関係を確立する。例えば、スイッチポートとＶＬＡＮとの関係を確立して、選択したサーバーを適切なネットワーク環境に追加する。
【００３０】
この好適な実施例は、プロビジョニング環境のリソース間の関係を識別するプロセスを説明するために、図２および図３から図４の例としてのプロビジョニング環境を使う。これには確立された関係と、論理的プロビジョニングの一部として確立される予定の関係の両方を含む。さらに、これらの関係は、リソースの要求を満たすために利用可能なリソースインスタンスの識別、その予約、および論理的にプロビジョニングするために利用できる一般的なプロセスへのインプットとして使用される。
【００３１】
図５は、本発明によるプロビジョニング環境でリソースタイプを識別してその関係を定義するステップを図示する高次のフローチャートを示す。プロセスは図示するようにブロック３００から始まり、その後、図２および図３から図４にあるようなプロビジョニング環境を定義するステップを示すブロック３０２に移る。次に、ブロック３０４は、定義したプロビジョニング環境のリソースのタイプとサブタイプを識別するステップを図示する。例えば、図３から図４を参照すると、次のものが前述した一般リソースのタイプである。つまり、ＩＰアドレス、ＶＬＡＮ、負荷分散装置、ファイヤウォール、サーバー、ネットワークインターフェースカード、スイッチポートである。これら一般リソースのタイプはさらに細かいサブタイプに分割できる。例えば、図３から図４に示される各一般リソースのタイプのサブタイプは次のものである。
【表１】
2007520814.tif 000003
【００３２】
さらに、ブロック３０６は特定のプロビジョニング環境の関係を表すリソースのサブタイプ間の「依存」関係を定義するステップを表す。例えば、経験豊富なネットワーク構築者は、図３から図４に示されるような特定のトポロジーを制作するかもしれないが、これはネットワークの様々なリソースのタイプのレイアウトであり、これらのリソースのタイプは互いに物理的かつ論理的に接続される。「依存」関係はこれらの定義された関係を記述する。
【００３３】
「依存」関係は推移的である。例えば、リソースのタイプＡがリソースのタイプＢに依存し、リソースのタイプＢがリソースのタイプＣに依存すると、リソースのタイプＡはリソースのタイプＣに依存する。
【００３４】
例えば、以下のものは、図３から図４のプロビジョニング環境によって表される「依存」関係の例である。
【表２】
2007520814.tif 000004
【００３５】
さらにプロセスはブロック３０８に進み、「依存」関係を使って定義したリソースのサブタイプを特定の順序でリストアップする。「依存」関係に一致する有効なトポロジカル順序が受け入れられる。
【００３６】
図示するプロビジョニング環境の例で受け入れられる順序の一つは、次のとおりである。
（様々な）サーバーの仕様
インターネットフィードＶＬＡＮ
フロントエンドファイヤウォール
ファイヤウォール／負荷分散装置ＶＬＡＮ
仮想ＩＰアドレス
負荷分散装置
プライマリウエブフロントエンドクロスバー
ウエブフロントエンドＩＰアドレス
コミュニティウエブフロントエンドクロスバーＶＬＡＮ
バックエンドファイヤウォール
プライマリウエブバックエンドクロスバー
ウエブバックエンドＩＰアドレス
コミュニティウエブバックエンドクロスバーＶＬＡＮ
プライマリデータフロントエンドクロスバー
データフロントエンドＩＰアドレス
コミュニティデータフロントエンドクロスバーＶＬＡＮ
フロントエンドＮＩＣ
バックエンドＮＩＣ
スイッチポート
【００３７】
その後、ブロック３１０は、論理的なプロビジョニングの結果として確立されるべき論理的な関係を表すリソース間の「対応」関係を示す。例えば、図２および図３から図４のプロビジョニング環境では、プロビジョニングプロセスの一部は、同じ顧客に割り当てられる他のサーバーと通信できるようにサーバーを構成することになる。このプロセスの１ステップは、１セットのＩＰアドレスをサーバーに割り当てる、すなわち、サーバーのＮＩＣに割り当てることである。以下に示す１列目のリソースのサブタイプは、２列目のリソースのサブタイプに対応付けることになる。「対応」関係は反射的である。すなわち、リソースのサブタイプＡがリソースのサブタイプＢと「対応」すれば、リソースのサブタイプＢはリソースのサブタイプＡと「対応」する。
【００３８】
議論中の例によると、「対応」関係は以下のように定義される。
【表３】
2007520814.tif 000005
図６は、本発明によるプロビジョニング環境でリソース要求に従いリソースを識別、予約、および論理的にプロビジョニングするステップを示す高次のフローチャートを図示する。図示するようにプロセスはブロック４００から始まり、その後受信した要求を示すブロック４０２に移る。リソース要求は１セットのリソースのタイプと予約されるべき各々の量を含む。リソースインスタンスがすでに前もって予約されている場合、要求はこの要求を満たすために使う以前に予約済みのリソースのリストも含んでもよい。さらに詳しくは、予約されるべきリソースの所要リストは、要求されるリソースのタイプのそれぞれについてのリソースのサブタイプと、量を含めて一致させるべき属性と値のリストを識別する。例えば、リソース要求は、サーバーの各グループについて、サーバーのサブタイプ、グループ内のサーバーの数、特定の仮想ＩＰアドレスが要求されるかどうか、すなわちグループを負荷分散するべきかどうか、それがウエブサーバーかデータサーバーかなどサーバーが果たす役割を規定する、予約されるべきサーバーグループのリストを含んでもよい。
【００３９】
リソース要求の非常に単純な例は、１つの仮想ＩＰアドレスとサーバーの空きグループの要求である。この例は本発明を詳しく説明するために以下で採用する。
【００４０】
さらにプロセスはブロック４０６に移り、要求される各リソースのサブタイプと「対応」させるべきリソースのサブタイプを識別するステップを示す。これらの新たに識別されるリソースのサブタイプは、要求されるリソースのサブタイプのリストに追加される。このプロセスを「対応」リソースのサブタイプがすべて識別されるまで繰り返す。この増強は次の理由のために行う。リソースのサブタイプＡがリソースサブタイプＢに対応付けることになるならば、対応が完了される論理的なプロビジョニングのステップを完了するために、ＡとＢ両方のサブタイプのインスタンスが必要である。新たに追加した各リソースのサブタイプのリソースインスタンスの必要な数は、要求されるリソースの元の数によって決めることができる。
【００４１】
さらに、例に従い、仮想ＩＰアドレスを負荷分散装置とサーバーグループに対応付けることとする。こうして、識別されたリソースのサブタイプのリストは１つの仮想ＩＰアドレス、１つの負荷分散装置、１つのサーバーグループのリストを含む。さらに「対応」関係をそれ以上繰り返しても、追加サブタイプはリストに追加されない。
【００４２】
次に、ブロック４０８は、識別したリソースのサブタイプのリストに含まれるリソースの各サブタイプに「依存」するリソースのサブタイプを識別するステップを示す。このプロセスも、「依存」リソースのサブタイプがすべて識別されるまで繰り返す。この場合、新たに識別されたリソースのサブタイプを次の理由で追加する。リソースのサブタイプＡが別のリソースのサブタイプＢに依存する場合、サブタイプＡのリソースインスタンスを選択するにはサブタイプＢのどのリソースインスタンスが識別されたかを知る必要がある。
【００４３】
例では、仮想ＩＰアドレスはファイヤウォール／負荷分散装置セグメントＶＬＡＮに依存し、負荷分散装置はファイヤウォール／負荷分散装置セグメントＶＬＡＮに依存し、ファイヤウォール／負荷分散装置セグメントＶＬＡＮはフロントエンドファイヤウォールに依存し、フロントエンドファイヤウォールは公衆インターネットセグメントＶＬＡＮに依存する。このリストは、まず仮想ＩＰアドレスがファイヤウォール／負荷分散装置セグメントＶＬＡＮに依存することと、負荷分散装置がファイヤウォール／負荷分散装置セグメントＶＬＡＮに依存することを見つけ出して作成した。次のパス中に、ファイヤウォール／負荷分散装置セグメントＶＬＡＮがフロントエンドファイヤウォールに依存することが分かった。「依存」関係の次のパス中に、フロントエンドファイやウォールが公衆インターネットセグメントＶＬＡＮに依存することが分かった。このように、リストは１つの仮想ＩＰアドレス、１つの負荷分散装置、１つのサーバーグループ、１つのファイヤウォール／負荷分散装置セグメントＶＬＡＮ、１つのフロントエンドファイヤウォール、１つの公衆インターネットセグメントＶＬＡＮを含む。
【００４４】
次のブロック４１０は、この要求に対して十分なリソースインスタンスがすでに予約されているリストからリソースのサブタイプを外すステップを示す。このニーズを満たすリソースのサブタイプがすでに予約されている場合、さらにもう１つ予約する必要はない。以前に予約されていたリソースインスタンスのリストがリソース要求の一部であることを思い出していただきたい。例では、すでに予約されているリソースインスタンスはないので、リソースのサブタイプを外す必要はない。
【００４５】
さらにプロセスはブロック４１２に移って、要求を満たすために利用可能なリソースの一致するセットを識別するために、「Ｓｅｌｅｃｔ（）」と呼ばれるプロセスを呼び出すステップを示す。Ｓｅｌｅｃｔ（）はＲ、Ｉ、およびＮの３つの入力パラメータをとり、Ｉ’という１つの出力パラメータを返す。Ｒは、ブロック４０６、４０８、４１０のステップで増補する必要なリソースのサブタイプのセットを表す。Ｉは要求を満たすために以前に予約していて利用可能なリソースインスタンスのセットである。Ｎは、各リソースのサブタイプの必要なリソースインスタンスの数を識別する数の集合である。一般的に、Ｎ［ｒ］は要求されるサブタイプｒのリソースインスタンスの数を表す。Ｒの場合のように、このセットは入力要求とステップ４０６、４０８および４１０の処理から導かれる。出力Ｉ’は、リソース要求を満たすと識別されたリソースインスタンスのセットを表す。一致するリソースのセットが識別できなければ、ブロック４１２はリソースインスタンスの入力セットを返す。すなわち、ＩはＩ’に等しい。
【００４６】
次に、ブロック４１４は、入力パラメータＩの値が出力パラメータＩ’の値と等しいかどうかを点検して、一致するリソースインスタンスのセットが識別されたかどうかを判定するステップを示す。もし等しければ、識別された適切なリソースインスタンスはなく、プロセスは失敗を報告するステップを示すブロック４１６に移る。それからブロック４２２で終了する。対して、一致するリソースインスタンスのリストが識別されたら（Ｉ’が間違いなくＩを含む）、プロセスは、プロビジョニング環境で選択されたリソースインスタンスを論理的にプロビジョニングするステップを示すブロック４１８に進む。すなわち、「対応」関係に従って、選択されたインスタンス間に論理的な対応関係が作成される。その後、ブロック４２０は「予約済み」として「共有」されない選択された各リソースの状態ビットを設定するステップを示す。「共有」リソースは、複数の選択に利用可能で、そのため予約済みに設定されない。それからプロセスはブロック４２２で示すように終了する。
【００４７】
図７は、特定の顧客の要求を満たすために一致するリソースのセットを識別するプロセスを示す擬似コードである。すなわち、ブロック４１２で使用する「Ｓｅｌｅｃｔ（）」プロシージャの実施である。ライン５００はプロセス（「Ｓｅｌｅｃｔ（）」）の名前とその入出力パラメータを示す。Ｓｅｌｅｃｔ（）はＲ、Ｉ、Ｎの３つの入力パラメータをとり、リソースインスタンスのセットである１つの出力パラメータを返す。Ｒは必要なリソースのタイプのセットを表す。Ｉは要求を満たすために以前に識別したリソースインスタンスのセットである。Ｎは、各リソースのサブタイプの必要なリソースインスタンスの数を識別する数の集合である。一般に、Ｎ［ｒ］は必要なサブタイプｒのリソースインスタンスの数を表す。出力はリソース要求を満たすために識別されるリソースインスタンスのセットである。一致するリソースのセットが識別できなければ、Ｓｅｌｅｃｔ（）はリソースインスタンスの入力セットを返す。
【００４８】
プロセスはライン５０１から始まり、必要なすべてのリソースのサブタイプのセット（すなわち、Ｒ）から、（依存関係に従い）最小のリソースのサブタイプを選択する。リソースのサブタイプは、他のリソースのサブタイプに一切依存していなければ、最小である。このために３０８で識別するトポロジカル分類を利用できる。トポロジカル順序でＲのうち最も小さい（最初の）エレメントが最小となる。最小のリソースのサブタイプｒを選択してしまえば、プロセスはライン５０２に進んで、タイプｒのＮ［ｒ］利用可能なリソースインスタンスのすべてのセットを識別する。さらに、リソースインスタンスのセットは次の条件を満たすべきである。セットのすべてのリソースインスタンスｓについて、ｒがリソースのサブタイプｒ&Acirc;に依存している場合、（Ｉの中で）すでに選択されたサブタイプｒ’であるリソースインスタンスｔが存在するため、ｔはサブタイプｒ&Acirc;であり、ｓはｔに依存する。すなわち、サブタイプの依存性は選択したインスタンスの中で反映されなければならない。サブタイプｒのリソースインスタンスを選択する場合、上記ｒ&Acirc;のようにｒが依存するすべてのサブタイプのインスタンスは、リソースのサブタイプが識別されたトポロジカル順序（最小のタイプ１）で選ばれているため、すでに選択されている。その結果、サブタイプｒのリソースを選択する場合、インスタンスが依存する他のサブタイプの選択したインスタンスを両立させることが可能である。この好適な実施例で説明したリソースのサブタイプの場合、以下の項目が正確ならインスタンスを選択できる。
１．サーバーインスタンスを選択するのに必須の条件
ａ．「利用可能」と設定される状態ビットがある
ｂ．要求されるサーバーのサブタイプと一致する
２．インターネットフィードＶＬＡＮインスタンスを選択するのに必須の条件
ａ．「利用可能」と設定される状態ビットがある
ｂ．十分な数のフロントエンドファイヤウォールＶＬＡＮが利用可能である
３．フロントエンドファイヤウォールＶＬＡＮインスタンスを選択するのに必須の条件
ａ．「利用可能」と設定される状態ビットがある
ｂ．十分な数のファイヤウォール／負荷分散装置セグメントＶＬＡＮが利用可能である
４．ファイヤウォール／負荷分散装置セグメントＶＬＡＮインスタンスを選択するのに必須の条件
ａ．「利用可能」と設定される状態ビットがある
ｂ．十分な数の仮想ＩＰアドレスが利用可能である
ｃ．十分な数の負荷分散装置インスタンスが利用可能である
５．仮想ＩＰアドレスインスタンスを選択するのに必須の条件
ａ．「利用可能」と設定される状態ビットがある
６．負荷分散装置インスタンスを選択するのに必須の条件
ａ．「利用可能」と設定される状態ビットがある
ｂ．十分な数のプライマリウエブフロントエンドクロスバーＶＬＡＮが利用可能である
７．プライマリウエブフロントエンドクロスバーＶＬＡＮインスタンスを選択するのに必須の条件
ａ．「利用可能」と設定される状態ビットがある
ｂ．十分な数のウエブフロントエンドＩＰアドレスが利用可能である
ｃ．十分な数のコミュニティウエブフロントエンドクロスバーＶＬＡＮインスタンスが利用可能である
８．ウエブフロントエンドＩＰアドレスインスタンスを選択するのに必須の条件
ａ．「利用可能」と設定される状態ビットがある
９．コミュニティウエブフロントエンドクロスバーＶＬＡＮインスタンスを選択するのに必須の条件
ａ．「利用可能」と設定される状態ビットがある
１０．バックエンドファイヤウォールインスタンスを選択するのに必須の条件
ａ．「利用可能」と設定される状態ビットがある
ｂ．十分な数のプライマリウエブバックエンドクロスバーＶＬＡＮインスタンスが利用可能である
ｃ．十分な数のプライマリデータフロントエンドクロスバーＶＬＡＮインスタンスが利用可能である
１１．プライマリウエブバックエンドクロスバーＶＬＡＮインスタンスを選択するのに必須の条件
ａ．「利用可能」と設定される状態ビットがある
ｂ．十分な数のコミュニティウエブバックエンドクロスバーＶＬＡＮインスタンスが利用可能である
ｃ．十分な数のウエブバックエンドＩＰアドレスが利用可能である
１２．コミュニティウエブバックエンドクロスバーＶＬＡＮインスタンスを選択するのに必須の条件
ａ．「利用可能」と設定される状態ビットがある
１３．ウエブバックエンドＩＰアドレスインスタンスを選択するのに必須の条件
ａ．「利用可能」と設定される状態ビットがある
１４．プライマリデータフロントエンドクロスバーＶＬＡＮインスタンスを選択するためには、十分な数のコミュニティデータフロントエンドクロスバーＶＬＡＮインスタンスと十分な数のデータフロントエンドＩＰアドレスが利用可能であることが必須である。
１５．プライマリデータフロントエンドクロスバーＶＬＡＮインスタンスを選択するのに必須の条件
ａ．「利用可能」と設定される状態ビットがある
ｂ．十分な数のコミュニティデータフロントエンドクロスバーＶＬＡＮインスタンスが利用可能である
ｃ．十分な数のデータフロントエンドＩＰアドレスが利用可能である
１６．コミュニティデータフロントエンドクロスバーＶＬＡＮインスタンスを選択するのに必須の条件
ａ．「利用可能」と設定される状態ビットがある
１７．データフロントエンドＩＰアドレスインスタンスを選択するのに必須の条件
ａ．「利用可能」と設定される状態ビットがある
【００４９】
さらにプロセスはライン５０３から５１１の間をループし、選択したサブタイプｒのリソースのセットが、必要な他のサブタイプのリソースインスタンスの適切な選択を可能に摺るかどうかを点検する。これはまず、ライン５０４で「共有」されていない選択したリソースの状態を「予約中」に設定して行う。このためにサブプロシージャ「ｓｅｔ＿ａｌｌ＿ｓｔａｔｅｓ（）」を利用する。ｓｅｔ＿ａｌｌ＿ｓｔａｔｅｓ（）は次の３つの入力パラメータをとる。状態を変更するべきリソースインスタンスのセットと、各リソースインスタンスの予想される現在の状態と、各リソースインスタンスの望ましい最終状態である。ｓｅｔ＿ａｌｌ＿ｓｔａｔｅｓ（）は、共有していない各リソースインスタンスの状態を望ましい最終状態に設定できたら真に、そうでなければ偽に設定するブール値を返す。状態をこのように設定して、Ｓｅｌｅｃｔ（）の他の独立した呼び出しが同じリソースインスタンスのセットを予約しないようにする。ただし、リソースインスタンスの状態を「予約中」に設定する前に、すでに「予約中」と設定したかもしれないＳｅｌｅｃｔ（）へのもう１つ独立した呼び出しも同じリソースインスタンスの一部と考えることも可能である。そのため、ｓｅｔ＿ａｌｌ＿ｓｔａｔｅｓ（）の呼び出しは、状態が予想される初期状態にまだあることを点検し、原子的でなければならない。すなわち、状態の点検と設定は、見かけ上一回の途切れのない操作として実行されなければならない。排他制御などの原子的動作を実施するあらゆるメカニズムを利用できる。
【００５０】
プロセスはライン５０５に進み、ｓｅｔ＿ａｌｌ＿ｓｔａｔｅｓ（）の呼び出しの成否を点検する。呼び出しが成功したら、プロセスはライン５０６に進み、残りのリソースのタイプのリソースを識別しようと試みる。すなわち、Ｓｅｌｅｃｔ（）は第１引数をリソースタイプの入力セットからたった今選択したリソースタイプを引いた数値（すなわち、Ｒ−｛ｒ｝）に設定して、再帰的に呼び出される。第２引数は、選択したリソースインスタンスの入力セットに、たった今選択したタイプｒのリソースインスタンスのセットを足して設定される。最後に、第３引数は同じにできる。ライン５０７で、Ｓｅｌｅｃｔ（）への呼び出しの出力を評価する。識別したリソースインスタンスのセットが変更されていれば、一致するリソースインスタンスのセットが識別されたことになる。Ｓｅｌｅｃｔ（）プロシージャへの最初の入力セット、現在の呼び出しで選択したサブタイプｒのインスタンス、Ｓｅｌｅｃｔ（）への再帰的な呼び出しで返したセットの全体のセットが、ライン５０８で呼び出しの出力として返される。この場合、処理が終了する。再帰的なＳｅｌｅｃｔ（）の呼び出しでリソースインスタンスが識別できなければ、処理はライン５０９のｅｌｓｅ句に進み、共有されていないサブタイプｒのリソースインスタンスの状態を「利用可能」にリセットする。ライン５０５で始まった条件付きのステートメントが終了し、処理はライン５１１に進む。ライン５１１はループの終了である。そのため、サブタイプｒのリソースインスタンスの考えられるすべてのセットが点検されていなければ、処理はライン５０２で続けられる。すべてを点検し終えたら、処理はライン５１２に進み、選択したリソースインスタンスの当初の（入力）リストを返す。すなわち、要求される他のサブタイプの残りのリソースインスタンスの選択を排除しないサブタイプｒの追加のリソースインスタンスは、見つけられない。
【００５１】
本発明を完全に機能するデータ処理システムにおいて説明してきたが、当業者には本発明のプロセスは、命令をコンピュータ読取可能媒体の形態や、分散を実行するのに実際に使用する特定のタイプの信号伝達媒体に関係なく本発明を同様に適用できる様々な形態で分散できることは十分理解されることに留意するのが重要である。コンピュータ読取可能媒体の例は、フロッピーディスク、ハードディスクドライブ、ＲＡＭ、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭなどの記録型の媒体、デジタルおよびアナログ通信リンク、ワイヤード又はワイヤレス通信リンクなど、例えば無線周波数や光波伝送などの伝送形態を利用する伝送型の媒体が含まれる。コンピュータ読取可能媒体は、特定のデータ処理システムで実際に使用するときにはデコードされるコード化したフォーマットの形態をとってもよい。
【００５２】
本発明の明細を例示および説明の目的で提示してきたが、網羅したものでも、本発明を開示した形態に制限するつもりもない。当業者には多くの変更や変型が明らかであろう。選んで説明してきた実施例は、発明の原理、実用的な応用を最適に説明し、当業者が企図される特定の用途に適した様々な変更と合わせて、様々な実施例について発明を理解できるようにするためのものである。
【図面の簡単な説明】
【００５３】
発明に特徴的と考えられる新規な特徴を添付の請求項に記載する。しかし、発明自体並びにその好適な使用態様、別の目的や利点は、添付の図面と合わせて、上記の詳細な例示的な実施例の説明を参照すると最もよく分かるであろう。
【図１】本発明により本発明が実施できるデータ処理システムのブロック図である。
【図２】本発明によりサーバーのすべてを待機させているが、他のリソースは互いに構成されている場合に、プロビジョニング要求を行う前にプロビジョニング環境にある１セットのリソースを図示するブロック図である。
【図３】本発明により多数のプロビジョニング要求を行い、リソースをプロビジョニングした後の１セットのリソースを図示するブロック図である。
【図４】本発明により多数のプロビジョニング要求を行い、リソースをプロビジョニングした後の１セットのリソースを図示するブロック図である。
【図５】本発明によりプロビジョニング環境を実施するために、リソースタイプを識別し、その関係を定義するステップを図示する高次のフローチャートを示す。
【図６】本発明によりプロビジョニング環境のリソース要求に従い、リソースを識別し、予約し、論理的にプロビジョニングするステップを示す高次のフローチャートを図示する。
【図７】本発明によりプロビジョニング環境のリソースを識別するプロセスを詳細に示す。
【図１】
2007520814.tif 000006
【図２】
2007520814.tif 000007
【図３】
2007520814.tif 000008
【図４】
2007520814.tif 000009
【図５】
2007520814.tif 000010
【図６】
2007520814.tif 000011
【図７】
2007520814.tif 000012
【国際調査報告】
2007520814.tif 000013
2007520814.tif 000014
2007520814.tif 000015