JP2005266917A - 分散資源獲得システム、分散資源獲得方法および分散資源獲得用プログラム - Google Patents

Abstract

【課題】
分散アプリケーションの実行のために必要な資源を動的に獲得する場合、資源獲得に伴う構成変更の実行の可否が構成変更の実行時に判明するため、構成変更の失敗による時間的損失と資源利用効率の低下が発生する問題を解消するシステムの提供。
【解決手段】
構成変更の準備段階において、獲得する対象の資源を確定するとともに、獲得対象の資源に対する構成変更の可否を判断し、構成変更の実行可否を判断するために、資源情報データベース（ＤＢ）３６に対して、構成変更操作の実行順序と同じ順序で更新を行う。資源情報ＤＢの更新の際に、その時点での資源情報ＤＢの内容を基に実行可否を判断する。準備段階が終了した後で、構成変更の実行段階に移り、資源情報ＤＢの更新内容を実際の資源に対して適用する。
【選択図】
図１

Description

本発明は、計算機資源獲得システム、計算機資源獲得方法および計算機資源獲得用プログラムに関し、特に、計算機資源の獲得に伴って計算機資源の構成を変更することができる計算機資源獲得システム、計算機資源獲得方法および計算機資源獲得用プログラムに関する。

はじめに、本明細書で使用する用語を定義しておく。

「計算機資源（computational resource）」とは、計算機システムにおいて、管理の対象となる資源をいう。具体例として、コンピュータ、スイッチやルータなどのネットワーク機器、ストレージ装置が挙げられる。以下では、「計算機資源」は、単に「資源」とも略記される。

「管理ドメイン(administrative domain)」とは、計算機システムの一部分であって、単一の管理ポリシに基づいて管理される一部分をいう。管理ドメインの具体例は、単一の企業や学校内の計算機システムや、単一のデータセンターである。計算機システム全体が単一の管理ドメインに属する場合と、複数の管理ドメインにより計算機システムが構成される場合がある。

「資源の獲得(resource acquisition)」とは、資源利用者(resource user)が資源提供者(resource provider)から特定の資源の利用権を得ることをいう。資源利用者が獲得した資源は、最終的に解放して資源提供者に返却する必要がある。

「資源の提供(resource provisioning)」は、資源提供者が資源利用者に特定の資源の利用権を与えることをいう。

「資源の構成(resource configuration)」とは、単一の資源についての静的または動的な性質と、資源間の包含関係および接続関係を指す。資源の静的な性質の例として、コンピュータ資源の機種やルータ資源の最大スループットが挙げられる。資源の動的な性質の例として、プロセッサ（ＣＰＵ）資源の使用率やメモリ資源の使用量が挙げられる。資源間の包含関係の例は、コンピュータ資源に、ＣＰＵ資源およびメモリ資源が含まれるというものである。資源間の接続関係の例は、スイッチ資源に複数のコンピュータ資源が接続されているというものである。資源の構成に関する情報を「構成情報(configuration information)」と呼ぶ。

「構成変更操作(reconfiguration operation)」は、資源の獲得(resource acquisition)、または解放のために、単一の資源の構成を変更する操作を指す。構成変更操作の具体例としては、
・資源の利用権（資源の提供先である資源利用者）の変更、
・コンピュータ資源上でのプログラムの起動および停止、
・ルータ資源における特定の資源利用者に対する保証帯域の増加および減少
等がある。

従来の分散資源獲得システムの一例が、後記非特許文献１に記載されている。図２２に示すように、この従来の分散資源獲得システムは、クライアント（Client、１）と、ブローカ（Broker、７）と、情報サービス（Information Service、８）と、ＧＲＡＭ（Globus Resource Allocation Manager、９）と、を備えて構成されている。さらに、ＧＲＡＭは、内部に、ゲートキーパ(Gatekeeper、９１)と、ジョブ・マネージャ(Job Manager、９２)と、ローカル・リソースマネージャ（Local Resource Manager、９３）と、ＧＲＡＭレポータ（GRAM Reporter、９４）を備える。ここで、ジョブ・マネージャはゲートキーパにより動的に起動される。また、単一のＧＲＡＭは、異なる種類の資源に対応した複数種類のローカル・リソースマネージャを備える。

このような構成を有する従来の分散資源獲得システムは次のように動作する。

最初に、分散資源獲得システムの利用者がクライアント（１）に対して獲得する資源の条件を入力する。

次に、クライアント（１）は、ブローカ（７）に対して、条件を満たす資源を探すことを要求する。

次に、ブローカ（７）は、情報サービス（８）に対して資源の情報を問い合わせ、クライアントから指定された条件を満たす資源の情報を取得した後、その中から割り当てる資源を選択し、選択した資源の情報をクライアントに通知する。

ここで、情報システムが保有する資源の情報は、ＧＲＡＭレポータ（９４）が定期的に情報システムに通知するものである。

次に、クライアント（１）は、１つまたは複数のＧＲＡＭ（９）に対して、ブローカ（７）によって選択された資源を対象としてジョブを実行することを要求する。ここで、ジョブとしてアプリケーションプログラムの起動やネットワーク帯域保証などの構成変更を指定することによって、資源を獲得することができる。

ゲートキーパ（９１）は、クライアント（１）からＧＲＡＭ（９）に対して投入したジョブを受け取り、ジョブマネージャ（９２）を新規に起動する。ジョブ・マネージャ（９２）は、ジョブの操作対象である資源の種類に適合するローカル・リソースマネージャ（９３）にジョブを渡す。最後に、ローカル・リソースマネージャ（９３）が資源にジョブを渡し、ジョブの実行を開始する。

カール・ツァイコウスキ他著「ア リソース マネジメント アーキテクチャ フォー メタコンピューティング システムズ」プロシーディング 第４回ワークショップ オン ジョブ スケジューリング ストラテジーズ フォー パラレル プロセッシング、ｐｐ．６２−８２、１９９８年(Carl Czajkowski et al,. "A Resource Management Architecture for Metacomputing Systems,"Proc. 4th IPPS/SPDP Workshop on Job Scheduling Strategies for Parallel Processing, pp. 62-82, 1998.

図２２を参照して説明した上記従来の分散資源獲得システムは、下記記載の問題点を有している。

第１の問題点は、実行順序に制約のある構成変更操作群を実行する際に、事前に実行の可否を確認できないことである。

その理由は、ある構成変更操作が可能であるか否かは、当該構成変更操作を実行する時点における計算機システムの状態に依存するためである。このため、ある構成変更操作の実行の可否を判断するためには、対象の構成変更操作群の中の先行するすべての操作を実行しなければならない。この結果、１つの構成変更操作の実行に失敗すると、構成変更操作群全体の処理を取り消すために、実行済みの構成変更操作の逆操作(rollbackまたはcompensation)を行う必要が生じる。多数の構成変更操作を逆操作する場合や、長時間を要する構成変更操作を逆操作する場合、資源利用者と資源提供者の双方に時間的損失が生じることになる。

第２の問題点は、獲得対象の資源が複数あり、それらの資源の選択について複数の管理ドメインにまたがる依存関係がある場合に、計算機システムの規模が大きくなるに従って資源選択の際の負荷が大きくなることである。

その理由は、獲得する資源を選択するために、計算機システム全体についての資源の情報を必要とするためである。複数の管理ドメインにまたがる依存関係がない場合には、各管理ドメインに設置する資源管理機構（図２２におけるＧＲＡＭ）が資源を選択しても問題はないが、複数の管理ドメインにまたがる依存関係がある場合には、従来の技術では集中的な資源選択機構（図２２におけるブローカ）のみによって資源を選択する必要がある。ここで、資源の選択についての依存関係とは、ある種類の資源の選択結果によって、別の種類の資源の選択肢が制限を受けることを指す。資源の選択に関する依存関係の一例は、サーバ資源の選択と、サーバ間を接続するネットワーク経路の選択である。

したがって、本発明の主たる目的は、資源獲得に伴う構成変更操作が複数あり、かつそれらの実行順序に関して制約がある場合、獲得対象の資源が複数の管理ドメインにまたがる場合に、構成変更の実行前に、実行の可否を判断可能たらしめる分散資源獲得システムと方法並びにコンピュータプログラムを提供することにある。

本発明の他の目的は、獲得対象の資源が複数あり、それらの選択について複数の管理ドメインにまたがる依存関係がある場合に、資源を選択する際の処理を負荷分散することが可能な分散資源獲得システムを提供することにある。

本願で開示される発明は、構成変更を、準備段階と実行段階の２段階に分割することと、準備段階と実行段階の両方を、構成変更ワークフローに基づいて、処理することによって、課題を解決する。

本発明の１つのアスペクト（側面）に係るシステムは、好ましくは、計算機資源の構成変更に際して、構成変更操作が実行可能であるか否かを、前記計算機資源の情報を参照して、検証する構成変更操作検証手段と、前記構成変更操作検証手段で検証済みの前記構成変更操作を、前記計算機資源に適用する構成変更操作実行手段と、を備えている。

本発明に係るシステムにおいては、前記計算機資源のそれぞれについて前記計算機資源の現在の状態と更新情報を記憶する記憶部を備え、前記構成変更操作検証手段は、前記構成変更操作の対象となる前記計算機資源について、前記記憶部に記憶されている現在の状態と更新情報の内容に基づき、前記構成変更操作の実行可能性を検証する、構成としてもよい。

本発明に係るシステムにおいては、前記構成変更操作検証手段は、前記構成変更操作の実行が可能であると検証されたとき、前記記憶部の更新情報を前記構成変更操作に対応した情報で更新する、構成としてもよい。

本発明に係るシステムにおいては、前記構成変更操作実行手段は、前記構成変更操作の実行にあたり、前記計算機資源に関して前記記憶部に記憶されている更新情報を、前記計算機資源に適用し、前記計算機資源に対応する前記記憶部の現在の状態を、前記構成変更実行後の状態に設定する、構成としてもよい。

本発明の他のアスペクトに係る分散資源獲得システムは、計算機システム内に、１つまたは複数設置するスーパースケジューラ（図１の２）と、各管理ドメインに１つずつ設置するリソースマネージャ（図１の３）からなる。なお、括弧内の図面の参照番号は、あくまで理解を容易とするために付したものであり、発明を制限するためのものと解釈されるべきものでないことは勿論である。

スーパースケジューラは、利用者から資源獲得の要求を受け付ける機能と、１つまたは複数のリソースマネージャに対して資源の獲得を要求する機能を持つ。

リソースマネージャは、単一の管理ドメインに属するすべての資源についての情報を持つとともに、それらの資源の構成を変更する機能を持つ。

本発明の分散資源獲得システムでは、利用者がクライアント（図１の１）を通して、スーパースケジューラに対して資源獲得要求を投入すると、スーパースケジューラは、要求の種類に適合した構成変更ワークフローを生成する。ここで、「構成変更ワークフロー」は、利用者が要求した資源あるいは資源の集合を獲得する際に、必要な構成変更操作の集合と、その間の依存関係を表現する有向非循環グラフ（ＤＡＧ）である。構成変更ワークフローは、資源選択に関する依存関係（すなわち、ある種類の資源を選択した場合に、別の種類の資源の選択肢が制限される）と、構成変更の実行順序に関する依存関係（ある構成変更操作を実行するためには、別の構成変更操作の実行が完了していなければならない）の両方を満たす形で、あらかじめ人手で作成しておく。

スーパースケジューラは、構成変更ワークフローが表現する依存関係に従って、１つまたは複数のリソースマネージャに対して、構成変更の準備を要求する。この段階を「準備段階」と呼ぶ。準備段階では、獲得対象の資源の選択と、リソースマネージャが備える資源情報データベース（図１の３６、以下資源情報ＤＢ）の更新を行うが、資源の構成そのものは更新しない。

構成変更ワークフローの全要素について、準備が完了すると、実行段階に移る。実行段階では、スーパースケジューラでの準備段階と同じ順序で各リソースマネージャに対して、構成変更の実行を要求する。この要求を受け取ったリソースマネージャは、資源情報ＤＢに対する更新内容を実際の資源に対して適用する。

リソースマネージャは、資源情報ＤＢの更新の際に、アクセス権チェックを含む実行可能性の検証を行う。この検証の際に、資源についての現在の状態だけでなく、検証済みの他の構成変更操作の結果も、利用する。このことによって、検証結果と、実際の実行結果との不一致を避けることができる。

準備段階における資源の選択は、スーパースケジューラと、リソースマネージャによって、階層的に行う。すなわち、スーパースケジューラは、どの管理ドメインから資源を取得するかを決定し、リソースマネージャは、単一の管理ドメインの中から提供する資源を決定する。ただし、複数の管理ドメインにまたがる資源（例えば管理ドメイン間を接続するネットワーク）の選択の場合には、スーパースケジューラが、個別の資源を直接決定する。

構成変更ワークフローに基づく階層的な資源選択を行うことにより、資源選択に関する依存関係が解決され、かつ、資源選択に関する負荷を分散することができる。

本発明の分散資源獲得システムでは、構成変更について、準備段階と実行段階とを分離し、準備段階では、資源情報ＤＢの内容のみを更新することにより、構成変更を実行する前に、構成変更の実行可能性を検証することができる。

さらに、検証済みの構成変更操作の結果を、資源情報ＤＢに反映させることと、構成変更ワークフローを用いての構成変更操作の順序を、検証と実行の間で一致させることにより、単純なアクセス権限チェックを用いた検証に比べて、検証結果と実際の実行結果に相違が生じる可能性を減少させることができる。

かかる構成により、本発明の主たる目的を達成することができる。

また、本発明の分散資源獲得システムでは、資源の選択を、スーパースケジューラと、リソースマネージャとの間で階層的に行うことにより、資源選択の負荷が単一の箇所に集中することを避けることができる。

さらに、資源の選択を、構成変更ワークフローに従って段階的に行うことにより、選択の際に、単一の管理ドメイン内のみの資源情報を必要とする資源と、複数の管理ドメインにまたがる資源情報を必要とする資源とを混在して獲得する場合でも、前者の資源については、階層的に資源を獲得することが可能である。かかる構成により、本発明の第２の目的を達成することができる。

本発明によれば、資源獲得に伴う構成変更操作の平均所要時間を短縮することができる。

その理由は、本発明においては、構成変更準備と、構成変更実行と、を分離することにより、実際に資源の構成を変更する前に、構成変更の失敗が判別できるように構成したためである。

本発明によれば、複数の管理ドメインから資源を選択する際の所要時間を短縮することができる。

その理由は、本発明においては、構成変更ワークフローに基づいた、段階的な資源の選択を行うとともに、管理ドメインをまたがる依存関係のない資源選択については、階層的に資源選択を行うために、資源選択の際の負荷を、複数のリソースマネージャに分散できるためである。

次に、発明を実施するための最良の形態について図面を参照して詳細に説明する。

＜システム全体の構成＞
図１は、本発明の第１の実施の形態の分散資源獲得システムの構成を示す図である。図１を参照すると、本発明の第１の実施の形態に係る分散資源獲得システムは、クライアント（１）と、スーパースケジューラ（２）と、リソースマネージャ（３）と、資源（４）とを備えており、これらの各要素は、ネットワーク（６）を介して相互接続される。

ここで、クライアント（１）およびスーパースケジューラ（２）は、システム内にそれぞれ１台または複数台設置することができ、ネットワーク（６）に接続する限り、任意の位置に設置することができる。

各リソースマネージャ（３）および資源（４）は、いずれか１つの管理ドメイン（５）に所属する。リソースマネージャ（３）は、各管理ドメイン（５）にちょうど１つ設置される。

ネットワーク（６）は、広域ネットワーク（Wide Area Network、WAN）、ローカルエリアネットワーク（Local Area Network、LAN）、あるいはそれらの任意の組合せである。

以下では、図１の構成要素のうち、スーパースケジューラ（２）およびリソースマネージャ（３）の内部構成を説明する。

＜スーパースケジューラの構成＞
図２を参照すると、スーパースケジューラ（２）は、通信手段（２１）、ワークフロー生成手段（２２）、ワークフロー更新手段（２３）、ワークフロー実行手段（２４）、ワークフローテンプレート記憶部（２５）、資源情報データベース（２６、以下、「資源情報ＤＢ」という）を備える。以下に、これらの各部の動作の概略を述べる。

スーパースケジューラ（２）の通信手段（２１）は、外部エンティティとの通信を扱う。「外部エンティティ」とは、ネットワーク（図１の６）を介してスーパースケジューラと接続する構成要素を指す。

通信手段（２１）が持つ役割の１つは、スーパースケジューラ内の他の手段が発行するメッセージを、メッセージ中に送信先として指定される外部エンティティに送信することである。

通信手段（２１）のもう１つの役割は、外部エンティティから、メッセージが到着したときに、そのメッセージを、スーパースケジューラ内の適切な構成要素に転送する。到着する可能性のあるメッセージには、以下の種類がある。

・資源獲得要求：資源獲得要求は、クライアントが資源の獲得を要求するメッセージである。通信手段は、資源獲得要求をワークフロー生成手段（図２の２２）に転送する。

・準備完了通知／準備失敗通知：これらのメッセージは、リソースマネージャへの構成変更準備要求に対応して、構成変更準備のそれぞれ完了／失敗を通知するメッセージである。

・実行完了通知／実行失敗通知：これらのメッセージは、リソースマネージャへの構成変更実行要求に対応して、構成変更実行のそれぞれ完了／失敗を通知するメッセージである。

・取消完了通知／取消失敗通知：これらのメッセージは、リソースマネージャへの構成変更取消要求に対応して、構成変更キャンセルのそれぞれ完了／失敗を通知するメッセージである。

上記のメッセージのうち、転送先を明記していないものについては、対応する要求を発行した手段に対して転送する。例えば、ワークフロー更新手段（図２の２３）が、通信手段を介して、構成変更準備要求をリソースマネージャに送信した後に、該リソースマネージャから、準備完了通知が送られてきた場合に、通信手段は、その準備完了通知をワークフロー更新手段に転送する。

ワークフロー生成手段（２２）は、ワークフローテンプレート記憶部（２５）に格納されたテンプレートを基に、「初期段階の構成変更ワークフロー」を生成する。

「ワークフローテンプレート」とは、クライアントから送られる資源獲得要求に含まれる資源の数量などの条件をセットすることによって、構成変更ワークフローになるデータを指す。

「初期段階のワークフロー」とは、ワークフロー中のすべての構成変更操作について、操作対象の資源が確定していない（未確定状態である）ワークフローを指す。

ワークフロー更新手段（２３）は、ワークフロー生成手段（２２）が生成した構成変更ワークフローを順次更新して、「確定した構成変更ワークフロー」を出力する。

「確定した構成変更ワークフロー」とは、ワークフロー中のすべての要素について操作対象の資源が確定している（確定状態である）ワークフローを指す。

構成変更ワークフローの更新は、リソースマネージャに対する構成変更準備要求の送信と、その結果の受信を伴う。

ワークフロー実行手段（２４）は、ワークフロー更新手段（２３）の出力である確定したワークフローを取り出し、その各要素である構成変更操作を順に実行する。構成変更操作の実行のために、リソースマネージャに対する構成変更実行要求の送信を伴う。

ワークフローテンプレート記憶部（２５）は、複数の資源獲得のパターンに対応したワークフローテンプレートを記憶する。

資源情報ＤＢ（２６）は、スーパースケジューラが資源獲得の対象とする資源の情報を記憶する。この情報は、ワークフロー更新手段（２３）によるワークフロー更新の際に、構成変更準備要求の送り先のリソースマネージャを決定するために用いる。

図１、図２および図３には図示されないが、スーパースケジューラの資源情報ＤＢ（２６）の内容を更新するために、定期的に、各リソースマネージャの資源情報ＤＢ（図３の３６）の内容を収集する。

＜リソースマネージャの構成＞
図３を参照すると、リソースマネージャ（３）は、通信手段（３１）、資源選択手段（３２）、構成変更操作検証手段（３３）、構成変更操作取消手段（３４）、構成変更操作実行手段（３５）、資源情報データベース（３６、「以下資源情報ＤＢ」という）、構成変更操作記憶部（３７）を備える。以下に、これらの各部の動作の概略を述べる。

リソースマネージャの通信手段（３１）は、リソースマネージャ（３）内の各手段と外部エンティティとの間の通信を仲介する。外部エンティティからリソースマネージャにメッセージが到着すると、通信手段（３１）は、当該メッセージを、リソースマネージャ内の適切な手段に転送する。通信手段（３１）は、内部にメッセージキュー(message queue)を備え、複数の要求が同時にした際のキューイングの機能を持つ。また、リソースマネージャ内のいずれかの手段が、通信手段（３１）にメッセージを渡すと、通信手段（３１）は、そのメッセージ中に指定された送信先にメッセージを送信する。

資源選択手段（３２）は、スーパースケジューラから送られた構成変更準備要求中に、指定された条件を満たす資源を選択するとともに、選択した資源を対象とする、構成変更操作列（「物理構成変更操作列」ともいう）を生成する。本明細書では、物理構成変更操作列を、資源を対象とする、具現化された物理的な構成変更操作列（例えばルータのスイッチの設定シーケンス）を指示するために用いているが、資源を対象とする構成変更操作列と読み替えてもよい。

構成変更操作検証手段（３３）は、資源選択手段（３２）によって生成された物理構成変更操作列の実行可能性を検証し、検証に成功した物理構成変更操作列を、構成変更操作記憶部（３７）に格納する。

構成変更操作実行手段（３５）は、構成変更操作記憶部（３７）に格納されている物理構成変更操作列を、実際の資源に対して適用する。ここで実行する物理構成変更操作列は、構成変更操作検証手段（３３）による検証が完了したものである。物理構成変更操作列の実行は、資源情報ＤＢ（３６）に格納されている資源の「現状態」の更新、および「更新情報」（「準備状態」ともいう）の消去を伴う。

構成変更操作取消手段（３４）は、過去にリソースマネージャが受け取った構成変更準備要求の結果を削除する処理を行う。

資源情報ＤＢ（３６）は、リソースマネージャの管理下にあるすべての資源について、現在の状態（現状態）および将来の構成変更の内容（更新情報）を記憶する。これらの情報は、構成変更準備段階における資源の選択と構成変更操作の検証のために用いる。

資源情報ＤＢの実現方法の一例は、資源の名前と現状態、および更新情報をレコードとするデータベースである。

構成変更操作記憶部（３７）は、検証が完了した構成変更操作と、その展開結果である物理構成変更操作列の対を記憶する。この対は、構成変更操作のＩＤを指定することで取得することができる。構成変更操作記憶部の実現方法の一例は、構成変更操作のＩＤをキーとし、構成変更操作および物理構成変更操作列の内容をレコードとするデータベースである。

次に、本実施の形態の全体の動作について詳細に説明する。最初に、構成要素間の相互作用を中心として全体の大まかな動作手順を説明した後、各構成要素の詳細な動作手順を説明する。

＜全体の動作手順＞
まず、図４を参照して、本実施の形態における各構成要素の動作および相互作用の概要を説明する。図４には、２つのリソースマネージャ（３）が図示されているが、２つに限定されるものでないことは勿論である。

まず、クライアント（１）がスーパースケジューラ（２）に対して資源の獲得を要求する（ステップＳ１）。

以降のステップＳ２からステップＳ５を構成変更準備段階と呼ぶ。

クライアント（１）からの資源獲得要求を受け取ったスーパースケジューラ（２）は、構成変更準備要求の送信先であるリソースマネージャおよび構成変更準備要求の内容を決定する（ステップＳ２）。構成変更準備要求は、送信先のリソースマネージャが管理する資源を対象とする構成変更準備を要求するメッセージである。

次に、スーパースケジューラ（２）は、ステップＳ２で作成した構成変更準備要求を、ステップＳ２で決定した送信先のリソースマネージャに対して送信する（ステップＳ３）。

ステップＳ３の構成変更準備要求を受け取ったリソースマネージャは、構成変更準備要求に含まれる条件を満たす資源の中から提供する資源の候補を選択し、それらの候補を対象とする構成変更操作列の実行可能性を検証する（ステップＳ４）。実行可能性の検証は、リソースマネージャが備える資源情報ＤＢ（図３の３６）に対する更新情報（準備状態）の追加を伴う。

次に、リソースマネージャは、ステップＳ４で選択された資源の識別子（以下、「リソースＩＤ」と呼ぶ）を含む準備完了通知をＳ３の送信元であるスーパースケジューラ２に送る（ステップＳ５）。

図４では、ステップＳ２からＳ５までは、１回しか存在しないが、実際には、ステップＳ２からステップＳ５を、複数回繰り返す場合がある。以下では、１回のステップＳ２からＳ５までの処理を、「構成変更準備パス」と呼ぶ。例えば、サーバ資源の集合とネットワーク資源の集合を獲得する場合に、１回目の構成変更準備パスで、サーバ資源を獲得し、２回目の構成変更準備パスで、ネットワーク資源を獲得することがありうる。

ステップＳ１で要求されたすべての資源について、実行可能性の検証が完了すると、次のステップＳ６に進む。以降のステップＳ６からＳ９を「構成変更実行段階」と呼ぶ。

ステップＳ６では、スーパースケジューラは、構成変更準備段階で確定した構成変更操作のうち、実行の対象となるものを選択し、各リソースマネージャに対して送信するための構成変更実行要求を作成する。あるリソースマネージャに対して送信する構成変更要求は、そのリソースマネージャが管理する資源を対象とする構成変更操作のみを含むように作成する。また、構成変更操作の間には実行順序に制約がある場合、その制約を満たすように構成変更操作を選択する。

次に、スーパースケジューラは、ステップＳ６で作成した構成変更実行要求を各リソースマネージャに送る（ステップＳ７）。

ステップＳ７の構成変更実行要求を受け取ったリソースマネージャは、その要求に含まれる構成変更操作の内容を実際の資源に対して適用する（ステップＳ８）。構成変更操作の実行は、ステップＳ４で追加した更新情報（準備状態）の消去と、現状態の更新を伴う。

ステップＳ８の実行が完了したリソースマネージャは、ステップＳ６のスーパースケジューラに対して実行完了通知を送る（ステップＳ９）。

図４に示す例では、ステップＳ６からＳ９までは１回しか行っていないが、実際にはステップＳ６からＳ９を複数回繰り返す場合がある。以下では、１回のステップＳ６からＳ９までの処理を「構成変更実行パス」と呼ぶ。前述のサーバ資源とネットワーク資源の例では、１回目の構成変更実行パスでサーバ資源の構成変更を実行し、２回目の構成変更実行パスでネットワーク資源の構成変更を実行することがありうる。なお、構成変更準備パスで対象となる構成変更操作の集合と、構成変更実行パスで対象となる構成変更操作の集合は一対一に対応するとは限らない。

ステップＳ１で要求されたすべての資源について構成変更の実行が完了すると、Ｓ１におけるスーパースケジューラは、ステップＳ１におけるクライアントに完了通知を送り、処理が完了する（ステップＳ１０）。

上記の動作手順は、典型的な場合であり、例外的な状況において、上記の動作手順とは異なる動作をする場合もある。

次に、スーパースケジューラ（図２）およびリソースマネージャ（図３）のそれぞれについて、構成変更準備段階および構成変更実行段階における詳細な動作手順を説明する。

＜構成変更準備段階におけるスーパースケジューラの動作＞
クライアント（図１の１）が送信した資源獲得要求が、スーパースケジューラ（図１の２）に到着すると、スーパースケジューラの各手段は、以下の動作を順に行う。

＜要求受信処理＞：
通信手段（図２の２１）が資源獲得要求を受信し、その要求をワークフロー生成手段（図２の２２）に転送する。この処理は、図４に示した全体の動作手順におけるステップＳ１に相当する。

＜ワークフロー生成処理＞：
ワークフロー生成手段（図２の２２）が、資源獲得要求に指定された資源を獲得するための初期の構成変更ワークフローを生成する。この処理は、図４におけるステップＳ２に相当する。

＜ワークフロー更新処理＞：
ワークフロー更新手段（図２の２３）が、構成変更ワークフローの内容を段階的に更新し、その内容を確定させる。この処理は、図４におけるステップＳ３からステップＳ５に相当する。

以下では、上記手順のうちワークフロー生成処理およびワークフロー更新処理について詳細な動作手順を示す。

＜ワークフロー生成手段の動作＞
まず、図５を参照して、ワークフロー生成手段（図２の２２）によるワークフロー生成処理の手順を説明する。

最初に、ワークフローテンプレート記憶部（図２の２５）を参照して、受け取った資源獲得要求に該当するワークフローテンプレートを取得する（ステップＳ２２１）。ここで、ワークフローテンプレートとは、構成変更ワークフローの元となるデータ構造であり、ワークフローテンプレートにサーバ台数やネットワーク帯域などの資源量をセットすることで初期の構成変更ワークフローを生成することができる。

ワークフロー生成手段（２２）は、ワークフローテンプレート記憶部（２５）に対して資源獲得要求に含まれるアプリケーション種別を指定することで、そのアプリケーションに対応したワークフローテンプレートを取得する。

ここで、ワークフローテンプレートの取得に成功した場合には、ステップＳ２２２に進む。

一方、ワークフローテンプレートの取得に失敗した場合、資源獲得要求を送信したクライアントに対して資源獲得の失敗を通知し、処理を終了する（ステップＳ２２４）。

ステップＳ２２１におけるワークフローテンプレート取得に成功した場合、ステップＳ２２１で取得したワークフローテンプレートに、資源獲得要求に含まれる資源数量をセットする（ステップＳ２２２）。ステップＳ２２２の出力は、初期状態の構成変更ワークフローであり、ワークフロー更新処理の対象となる。

ここでの処理は、構成変更ワークフロー中のすべての構成変更操作の状態を未確定状態に初期化することを伴う。未確定状態の構成変更操作は、その操作についてリソースマネージャによる構成変更準備が完了していないことを意味する。

最後に、ワークフロー更新手段（図２の２３）に通知して、ステップＳ２２２の出力である構成変更ワークフローを対象とするワークフロー更新処理を開始する（ステップＳ２２３）。

＜ワークフロー更新手段の動作＞
次に、図６を参照して、構成変更準備段階におけるワークフロー更新手段（図２の２３）の動作を説明する。ワークフロー更新手段では、ワークフロー生成手段（図２の２２）で作成した構成変更ワークフローを処理対象とする。

まず、構成変更ワークフローに含まれる構成変更操作の集合のうち、処理対象となる構成変更操作の集合を選択する（ステップＳ２３１）。ここで選択する構成変更操作は、未確定状態の操作のうち、すべての依存する構成変更操作が確定状態であるものである（依存する構成変更操作がないものを含む）。

図２３を用いて、ここでの選択方法を具体的に説明する。図２３（Ａ）の状態では、すべての要素が未確定状態である。したがって、依存する要素のない（入って来る矢印のない）要素である構成変更操作１、２、３、４が選択結果となる。図２３（Ｂ）の状態では、構成変更操作５、６、７、８が未確定状態であり、そのうち構成変更操作５、６については、それぞれが依存する構成変更操作（１、２）、（３、４）が確定状態になっている。したがって、選択結果は、構成変更操作５、６となる。

次に、ステップＳ２３１で選択した構成変更操作を構成要素とする構成変更準備要求を作成する（ステップＳ２３２）。構成変更準備要求は以下の情報からなる。

・要求送信先のリソースマネージャのアドレス（具体例は、ホスト名、ＵＲＬ(Uniform Resource Locator)）
・１つ以上の構成変更操作

構成変更操作の対象である資源が属する管理ドメインがすでに確定している場合、その管理ドメインに属するリソースマネージャを送信先とする構成変更要求を作成する。さらに、同一の管理ドメイン内の資源を操作対象とする構成変更操作が複数ある場合、それらを同一の構成変更準備要求の構成要素とする。

一方、構成変更操作の対象とする管理ドメインが確定していない場合、全管理ドメインの中から、１つまたは複数の管理ドメインを選択し、それらの管理ドメイン内のリソースマネージャを送信先とする構成変更準備要求を作成する。ここで、複数の管理ドメインを選択する場合、同一内容の構成変更操作が複数の構成変更準備要求に含まれることになる。

管理ドメインの選択方法には、いくつかの選択肢がある。１つの方法は、スーパースケジューラがアドレスを知っているすべての管理ドメインを選択するというものである。別の方法は、資源情報ＤＢ（図２の２６）を参照して、各管理ドメインにスコアをつけ、最もスコアの高い１つまたは複数の管理ドメインを選択するというものである。スコアをつける方法の例として、構成変更操作中の条件を満たす資源が多いほど高いスコアをつける方法や、資源の利用料金が安いほど高いスコアをつける方法がある。

後述するように、以前に送った構成変更準備要求について失敗通知が到着した場合に、ステップＳ２３２による構成変更準備要求の作成を再度行う状況が発生する。この場合、以前の構成変更準備に失敗した構成変更操作と同一の構成変更操作を、新しい構成変更準備要求に含めることはできない。他の構成変更操作への置き換えが不可能な場合にはステップＳ２３２の処理に失敗し、ステップＳ２３７に移る。

ステップＳ２３２において、構成変更準備要求の作成に成功した場合、その要求を通信手段（図２の２１）を介してリソースマネージャに送る（ステップＳ２３３）。ステップＳ２３２で複数の構成変更要求を作成した場合、複数のリソースマネージャに対して並行に要求を送る。

次に、ステップＳ２３３で送信したすべての構成変更準備要求について、応答（準備完了通知または失敗通知）が到着するのを待つ（ステップＳ２３４）。

すべての構成変更準備要求について準備完了通知が到着すると、ステップＳ２３５に進む。

一方、失敗通知が１つでも到着した場合、ステップＳ２３２に戻り、失敗した構成変更操作の内容を変更する。

また、タイムアウトを設定し、構成変更準備要求を送信してから所定の時間が経過すると失敗とみなして、ステップＳ２３２に戻ることにしても良い。

ステップＳ２３２において、同一の構成変更操作を複数の構成変更準備要求に含めた場合、本来必要な資源よりも多くの資源について構成変更準備がなされる場合がある。その場合、何らかのスコア付けに従って実際に獲得する資源を決定し、それ以外の資源を対象とする構成変更操作をキャンセルする。スコア付けの方法の例は、資源の性能あるいは利用料金を基準とするものである。構成変更操作をキャンセルするために、その操作の送り先であるリソースマネージャに対して、構成変更操作取消要求を送る。

次に、処理対象の構成変更ワークフローを構成する構成変更操作のうち、未確定状態の構成変更操作があるか否かを調べる（ステップＳ２３５）。

すべての構成変更操作が完了状態である場合には、ステップＳ２３６に進む。そうでない場合にはステップＳ２３１に戻り、他の構成変更操作について構成変更準備を行う。

ステップＳ２３６では、ワークフロー実行手段（図２の２４）に対して、処理対象の構成変更ワークフローについて構成変更準備が完了したことを通知し、処理を終了する。

ステップＳ２３７では、構成変更準備が不可能になった場合の終了処理として、処理対象の構成変更ワークフローに含まれる構成変更操作のうち、送信済みのすべての構成変更準備要求についてキャンセル処理を行う。キャンセル処理は、キャンセルの対象である構成変更準備要求の送信先であるリソースマネージャに対して構成変更取消要求を送ることによって行う。

次に、処理対象の構成変更ワークフローに対応する資源獲得要求を送信したクライアントに対して、資源獲得の失敗を通知する（ステップＳ２３８）。

＜構成変更準備段階におけるリソースマネージャの動作＞
スーパースケジューラが送信した構成変更準備要求がリソースマネージャに到着すると、リソースマネージャの各手段は以下の動作を順に行う。

＜構成変更準備要求受信処理＞：
通信手段（図３の３１）が構成変更準備要求を受信し、その要求を資源選択手段（図３の３２）に転送する。この処理は、図４に示した全体の動作手順におけるステップＳ３に相当する。

＜資源選択処理＞：
資源選択手段（図３の３２）が、構成変更準備要求に指定された条件を満たす資源を選択するとともに、その資源を対象とする構成変更操作に対応する、物理構成変更操作列を生成する。構成変更操作に対して、資源に対して行われる具現化された構成変更操作列を「物理構成変更操作列」という。

＜検証処理＞：
構成変更操作検証手段（図３の３３）が、資源選択処理において生成した物理構成変更操作を資源情報ＤＢ（図３の３６）に対して適用し、その結果をスーパースケジューラに通知する。資源選択処理と検証処理（結果の通知を除く）は、図４におけるステップＳ４に相当し、検証処理における結果の通知は図４におけるステップＳ５に相当する。

構成変更準備段階では、リソースマネージャは、構成変更準備要求のほかに構成変更取消要求を受け取る場合がある。スーパースケジューラが送信した構成変更取消要求がリソースマネージャに到着すると、リソースマネージャの各手段は以下の動作を順に行う。なお、この動作手順は、図４には示されていない。

＜構成変更準備要求受信処理＞：
通信手段（図３の３１）が構成変更準備要求を受信し、その要求を構成変更操作取消手段（図３の３４）に転送する。

＜取消処理＞：
構成変更操作取消手段（図３の３４）は、構成変更取消要求中に指定される構成変更準備要求を削除する。

以下では、リソースマネージャにおける資源選択手段、構成変更操作検証手段、構成変更操作取消手段の各手段について動作手順を説明する。これらの各手段は、上で示した資源選択処理、検証処理、取消処理をそれぞれ行う。

＜資源選択手段の動作＞
以下に、図８を参照して、構成変更準備段階における資源選択手段（図３の３２）の動作を説明する。以下の動作手順は、構成変更準備要求中の単一の構成変更操作を処理対象とする。単一の構成変更準備要求に複数の構成変更操作が含まれる場合、それらの各操作について、以下の動作手順を適用する。

まず、資源情報ＤＢ（図３の３６）を検索して、処理対象の構成変更操作で指定される条件を満たす資源のリストを取得する（ステップＳ３２１）。

後述するように、構成変更操作検証手段（図３の３３）による検証処理が失敗した場合、資源選択手段によって代替の資源を選択する処理を行う。その場合には、本ステップで取得するリストから前回の選択結果を除外する。

次に、ステップＳ３２１で取得したリスト中の各資源について、スコアを付与する（ステップＳ３２２）。最も単純なスコアの付け方は、資源に固有の名称や番号を用いる方法である。それ以外に、ＣＰＵ性能やメモリ容量、平均応答時間などの任意の基準を用いることができる。

次に、ステップＳ３２２で付与したスコアの順に、構成変更操作中に指定された数量の資源を選択する（ステップＳ３２３）。ここで、選択可能な資源の数量が構成変更操作中に指定された数量を下回る場合、資源選択処理は失敗し、ステップＳ３２６に移る。それ以外の場合、次のステップＳ３２４に進む。

なお、構成変更操作中に指定される資源の条件がリソースＩＤのような直接的な資源の指定である場合、ステップＳ３２２およびＳ３２３における選択を省略して、単に資源指定に該当する資源の有無を確かめる。その場合、該当する資源がない場合には資源選択処理に失敗し、ステップＳ３２６に移る。

ステップＳ３２６では、処理対象の構成変更準備要求の送信者（通常スーパースケジューラ）に対して資源選択の失敗を通知し、処理を終了する。

ステップＳ３２４では、ステップＳ３２３で選択した各資源について、構成変更操作に対応する物理構成変更操作列を生成する。物理構成変更操作列とは、リソースマネージャが管理する各資源について直接適用可能な操作である物理構成変更操作を要素とするリストである。ステップＳ３２４の入力である構成変更操作を物理構成変更操作列に変換する方法は、管理ドメインの方針に依存する。最も簡単な方法は、ステップＳ３２３の出力である構成変更操作を唯一の要素とするリストを物理構成変更操作列とするものである。一方、単一の構成変更操作を複数の物理構成変更操作に変換することもできる。その利点は、資源提供者が資源の物理的な構成を外部に対して隠蔽することができることと、スーパースケジューラによる資源選択の負荷を軽減できることである。

最後に、構成変更操作検証部に対して、ステップＳ３２４で作成した各物理構成変更操作列を対象として検証処理を行うことを通知し、処理を終了する（ステップＳ３２５）。

＜構成変更操作検証手段の動作＞
次に、図９を参照して、構成変更準備段階における構成変更操作検証手段（図３の３３）の動作を説明する。以下の動作手順は、単一の物理構成変更操作列を対象とする検証処理を行う手順である。複数の物理構成変更操作列について検証を行う場合、それらの各操作列について同じ動作手順を適用する。

まず、処理対象の物理構成変更操作列のうち、まだ検証処理を行っていない最初の要素を取り出す（ステップＳ３３１）。

次に、ステップＳ３３１で取り出した物理構成変更操作を、資源情報ＤＢ（図３の３６）に適用する（ステップＳ３３２）。すなわち、資源情報ＤＢ中の操作対象の資源について、その操作を実際の資源に適用した後の状態を更新情報に追加する。その際、実際の構成変更の際と同等のアクセス権チェックを行う。

アクセス権チェックの方法の一例は、操作対象の資源についてのアクセスコントロールリスト(access control list)に資源利用者のＩＤが含まれているか否かを確認するというものである。

アクセス権チェックの別の例は、操作対象の資源以外の特定の資源の状態が、あらかじめ資源提供者が決めた制約を満たしていることを確認するという方法がある。より具体的には、バックエンドサーバに対してフロントエンドサーバを追加するという操作について、その操作を要求するユーザのＩＤと、追加対象のフロントエンドサーバの利用権を持つユーザのＩＤとが一致しているという制約を設けることができる。この例のように、資源の状態を用いてアクセス権チェックを行う場合、資源情報ＤＢ中の現状態だけでなく更新情報も参照する。

その理由は、現状態を参照しただけでは実際の構成変更を実行した際の資源の状態が判断できないためである。

ステップＳ３３２における資源情報ＤＢの更新に成功すると、ステップＳ３３３に進む。もしも、何らかのエラーが発生した場合、検証処理は失敗し、ステップＳ３３６に移る。

ステップＳ３３６では、資源選択手段（図３の３２）に対して代替の資源を検索することを通知し、処理を終了する。この場合、資源選択手段は、再度、図８のステップＳ３２１以降の処理を実行し、代替の資源がある場合には、図９のステップＳ３３１以降の検証処理を再度行う。

ステップＳ３３３では、まだ検証処理を行っていない物理構成変更操作があるか否かを調べ、もしある場合にはステップＳ３３１に戻る。処理対象の物理構成変更操作列中のすべての要素について検証処理が終わると、ステップＳ３３４に進む。

ステップＳ３３４では、処理対象の物理構成変更操作列と、それに対応する構成変更操作の対を構成変更操作記憶手段（図３の３７）に格納する。

最後に、構成変更準備要求の送信者であるスーパースケジューラに対して、処理対象の構成変更操作についての構成変更準備の完了（準備完了通知）を通知する（ステップＳ３３５）。

＜構成変更操作取消手段の動作＞
次に、図１０を参照して、構成変更準備段階における構成変更操作取消手段（図３の３４）の動作を説明する。以下の動作手順では、構成変更操作取消要求中に指定される構成変更をキャンセル対象とする。

まず、通信手段（図３の３１）が備えるメッセージキューから、処理対象の構成変更操作を要素とする構成変更準備要求を検索する（ステップＳ３４１）。該当する構成変更操作がある場合にはステップＳ３４５に移り、ない場合にはステップＳ３４２に進む。

なお、通信手段がメッセージキューを備えない構成も可能であり、その場合にはＳ３４１では何もせずにＳ３４２に進む。

ステップＳ３４５では、通信手段中のメッセージキューから、キャンセル対象の構成変更操作を要素とする構成変更準備要求を削除し、ステップＳ３４６に進む。

ステップＳ３４２では、構成変更操作記憶部（図３の３７）から、キャンセル対象の構成変更操作に対応する物理構成変更操作列を検索する。物理構成変更操作列の取得に成功した場合にはステップＳ３４３に進み、該当する物理構成変更操作列がない場合にはステップＳ３４６に移る。

ステップＳ３４３では、ステップＳ３４２で取得した物理構成変更操作列の各要素の対象である資源について、資源情報ＤＢ（図３の３６）中の更新内容を消去する。

この処理は、構成変更操作検証手段におけるステップＳ３３２（図９）の逆操作に相当する。

次に、構成変更操作記憶部（図３の３７）から、キャンセル対象の構成変更操作と、ステップＳ３４２で取得した物理構成変更操作列の対を削除する（ステップＳ３４４）。この処理は、構成変更操作検証手段におけるステップＳ３３４（図９）の逆操作に相当する。

最後に、ステップＳ３４６で、構成変更操作取消要求の送信者に対して結果を通知する。

ステップＳ３４２において物理構成変更操作列の取得に失敗した場合には、通知の内容は失敗である。それ以外の場合には、通知の内容は成功である。

＜構成変更実行段階におけるスーパースケジューラの動作＞
構成変更準備が完了すると、スーパースケジューラはワークフロー実行手段（図２の２４）を用いて、構成変更ワークフロー中の構成変更操作を順に実行する。

以下に、図７を参照して、スーパースケジューラのワークフロー実行手段の動作を説明する。

ステップＳ２４１からステップＳ２４４では、処理対象の構成変更ワークフローの要素である構成変更操作を実行する。構成変更ワークフローで表現される依存関係を満たす順序で構成変更操作を実行するために、Ｓ２４１からＳ２４４までの処理を複数回繰り返す場合がある。

まず、ステップＳ２４１で、処理対象の構成変更ワークフローから実行の対象とする構成変更操作の集合を取得する。ここで、実行の対象となる構成変更操作は、確定状態（リソースマネージャによる準備は完了しているが、まだ実行されていない状態）である構成変更操作のうち、依存する構成変更操作が１つもないか、依存するすべての構成変更操作が完了状態であるかのいずれかの条件を満たす操作である。この条件は、ワークフロー更新手段（図２の２３）における処理対象の構成変更操作を選択する際の条件と同等のものである。

次に、リソースマネージャに対して、ステップＳ２４１で選択した構成変更操作の実行を要求する（ステップＳ２４２）。ここで、要求の送り先であるリソースマネージャが属する管理ドメインと、構成変更操作の対象である資源が属する管理ドメインが一致するように送信先のリソースマネージャを選択する。このステップにおける処理対象の構成変更操作が複数あり、かつその対象の資源が複数の管理ドメインにまたがる場合、複数のリソースマネージャに対する構成変更実行要求の送信を行う。

次に、ステップＳ２４２において送信した構成変更実行要求の応答を待つ（ステップＳ２４３）。Ｓ２４２で複数のリソースマネージャに対して要求を送った場合、そのすべてについて応答が到着するまで待つ。送信したすべての要求について成功の応答が得られた場合、次のステップＳ２４４に進む。もし、１つ以上の要求について失敗の応答が得られた場合、ステップＳ２４６に移る。

ステップＳ２４６では、失敗した構成変更操作について代替の資源を選択するための処理を行う。具体的には、失敗した構成変更操作とそれに依存するすべての構成変更操作を未確定状態に戻した後、構成変更ワークフロー更新手段（図２の２３）に通知し、再度構成変更ワークフローを更新する。完了状態の構成変更操作を未確定状態に変更する処理は、その操作に対する逆操作（例えば、サーバ資源の獲得に対する逆操作はサーバ資源の解放）の実行をリソースマネージャに要求することを伴う。構成変更ワークフローの更新に成功すると、再度ステップＳ２４１以降の処理を繰り返す。

ステップＳ２４４では、処理対象の構成変更ワークフローのうち、完了状態でない要素があるか否かを調べる。もし、該当する構成変更操作があれば、ステップＳ２４１に戻り、他の構成変更操作を実行する。すべての構成変更操作が完了していれば、ステップＳ２４５に進む。

ステップＳ２４５では、資源獲得要求の送信者であるクライアントに対して資源獲得処理の完了を通知し、処理を終了する。

＜構成変更実行段階におけるリソースマネージャの動作＞
リソースマネージャがスーパースケジューラから構成変更実行要求を受け取ると、通信手段（図３の３１）は、その要求を構成変更操作実行手段（図３の３５）に転送する。構成変更操作実行手段は、要求中に指定された構成変更操作に対応する物理構成変更操作列を取り出し、その対象の資源に対して順に構成変更の実行を指示する。

以下に、図１１を参照して、構成変更操作実行手段（図３の３５）の動作を説明する。

まず、構成変更操作記憶部（図３の３７）を参照して、構成変更実行要求で指定された構成変更操作に対応する物理構成変更操作列を取得する（ステップＳ３５１）。ここで取得する物理構成変更操作列は、構成変更操作検証手段（図３の３３）が格納したものである（図９のステップＳ３３５）。

次のステップＳ３５２からステップＳ３５５では、ステップＳ３５１で取得した物理構成変更操作列を１つずつ順に取り出し、実行する。

ステップＳ３５２で取り出した単独の物理構成変更操作を、ステップＳ３５３で実行する。

このステップでは、構成変更を実行するために、通信手段（図３の３１）を通して操作対象の資源に対する構成変更のメッセージの送信を行う。その際、資源の種類に応じたプロトコルを用いる。具体例としては、ＳＮＭＰ(Simple Network Management Protocol)やＴＥＬＮＥＴプロトコルが挙げられる。

ステップＳ３５３における資源の構成変更に成功した場合、資源情報ＤＢ（図３の３６）における操作対象の資源について、現状態を構成変更実行後の状態に置き換え、更新情報からその操作の内容を削除する（ステップＳ３５４）。さらに、まだ残りの物理構成変更操作がある場合には、ステップＳ３５２に戻って次の物理構成変更操作を実行する（ステップＳ３５５）。

一方、すべての物理構成変更操作が完了すると、ステップＳ３５７に移る。

ステップＳ３５３で構成変更の実行に失敗した場合、ステップＳ３５１で取り出した物理構成変更操作列のうち、実行済みの各操作について逆操作（ロールバック）を実行し、物理構成変更操作列を実行する前の状態に戻す（ステップＳ３５６）。資源情報ＤＢ中の情報についても、物理構成変更操作列を実行する前の状態に戻す。この処理が完了すると、ステップＳ３５７に進む。

ステップＳ３５７では、ステップＳ３５１で取り出した物理構成変更操作列を構成変更操作記憶部から削除する。

最後に、構成変更実行要求の発行者であるスーパースケジューラに対して結果を通知する（ステップＳ３５８）。ステップＳ３５１で取り出した物理構成変更操作列中のすべての操作の実行に成功した場合には結果は成功（実行完了通知）であり、それ以外の場合には結果は失敗（実行失敗通知）である。

次に、本発明を実施した具体例に即して説明する。

本発明の第１の実施例は、World Wide Web（ＷＷＷ）サーバと、そのバックエンドで動作するアプリケーションサーバの組み合わせで動作するＷＷＷアプリケーションに、本発明の資源獲得システムを適用したものである。この種のＷＷＷアプリケーションは、インターネット上でのショッピングサービスや企業間の電子商取引などの分野で典型的に用いられる。

図１２を参照すると、第１の実施例である分散計算機システムは、クライアント（１）と、スーパースケジューラ（２）と、リソースマネージャ（３）と、複数のサーバ装置（４Ａ−１、２、３、…）と、負荷分散装置（４Ｂ）からなる。これらのすべての構成要素は同一の管理ドメインに属する。

ここで、クライアント、スーパースケジューラ、リソースマネージャ、サーバ装置は、プログラム制御で動作するコンピュータである。ただし、スーパースケジューラとリソースマネージャは、同一のコンピュータ上で動作する異なるプログラムとして動作する。

なお、クライアント（１）は、資源獲得システムに対するクライアントであって、ＷＷＷアプリケーションに対するクライアント（以下では、ＨＴＴＰクライアントと称する）ではない。ＨＴＴＰクライアントは、図１２には含まれない。

各サーバ装置（４Ａ）は、ＷＷＷサーバ用のプログラム（例えばApache Software Foundationにより配布されているApache HTTP Server）とアプリケーションサーバ用のプログラム(例えばApache Software Foundationにより配布されているTomcat)を含む複数のプログラムを動作させることができる。ＷＷＷサーバは、ＨＴＴＰクライアントにより要求された処理を実行するために、アプリケーションサーバを呼び出す場合がある。各ＷＷＷサーバは、接続先のアプリケーションサーバのアドレスを記憶しており、各アプリケーションは、接続元のＷＷＷサーバを記憶する。各サーバ装置は、リソースマネージャ（３）からのメッセージに従って、各プログラムの起動または停止、および接続先サーバに関する情報の登録を行うためのエージェントプログラムを備える。

負荷分散装置（４Ｂ）は、ＨＴＴＰクライアントからのＷＷＷサーバに対する接続要求を、複数のＷＷＷサーバに振り分ける装置である。この負荷分散装置は、リソースマネージャ（３）からのメッセージに従って、振り分け先のＷＷＷサーバを、追加または削除するためのエージェントプログラムを備える。このエージェントプログラムは、負荷分散装置とは別のコンピュータ上で動作していても良い。

クライアント（１）は、キーボードなどの入力装置とディスプレイなどの出力装置を備えるコンピュータであり、空き状態にある資源をＷＷＷアプリケーションに割り当てることをスーパースケジューラに要求する役割を持つ。図１２中のクライアント（１）のほかに、図１２中の資源（４Ａ、４Ｂ）の獲得を要求する他のクライアントが存在していても良い。

以下では、本実施例において、ＷＷＷアプリケーションに、ＷＷＷサーバとアプリケーションサーバの組を追加する際の具体的な手順を述べる。ここでは、追加するＷＷＷサーバは、追加するアプリケーションサーバを接続先とする。また、ＷＷＷサーバの追加に伴い、負荷分散装置に対して、追加したＷＷＷサーバのアドレスを通知する必要がある。

まず、システム管理者がクライアント（１）の入力装置を介して、必要な資源の情報を入力する。この入力には、以下の情報が含まれる。

・ＷＷＷアプリケーションに追加するＷＷＷサーバの台数
・ＷＷＷアプリケーションに追加するアプリケーションサーバの台数

上記の情報を入力されたクライアント（１）は、その内容を資源獲得要求として、スーパースケジューラに送信する（図４におけるステップＳ１）。ネットワーク（６）を通して資源獲得要求を送信するためのプロトコルとしてSOAP(Simple Object Access Protocol)などを用いることができ、クライアントが備えるプログラムは、JAX-RPC(Java（登録商標） API for XML-Based RPC)などのＡＰＩを通して要求を送信することができる。

以下では、追加するＷＷＷサーバの台数とアプリケーションサーバの台数をそれぞれ５台、１台であると仮定する。

資源獲得要求を受け取ったスーパースケジューラは、ワークフロー生成手段（図２の２２）を用いて、初期の構成変更ワークフローを生成する。

図１３と図１４は、それぞれ、「ＷＷＷサーバ追加」に関するワークフローテンプレートと、それを基にした、ワークフロー生成手段２２による出力の例である。これらの図では、構成変更ワークフローを構成する各構成変更操作と、それらの操作の間の依存関係を表記している。例えば、構成変更操作３は、構成変更操作１と構成変更操作２に依存している。

図１３と図１４の相違点は、図１３のワークフローテンプレートでは、獲得する資源の数量が未確定であるのに対して、図１４の構成変更ワークフローでは、資源の数量が確定していることである。

図１４の段階では、獲得する資源についての条件や数量は確定しているが、追加する資源の具体的な名称あるいはアドレスは決定していない。図１４では、未確定の資源を、<HOST1>のように不等号で囲む形で表現している。

次に、スーパースケジューラのワークフロー更新手段（図２の２３）に制御が移り、リソースマネージャに対する構成変更準備要求の送信と、それに対応する準備完了通知の受信を通して、構成変更ワークフローの内容を確定させる。本実施例では、スーパースケジューラとリソースマネージャは、同一コンピュータ上で動作するので、構成変更準備要求を送る手段としては、Java（登録商標）言語における通常のメソッド呼び出しやＣ言語における関数呼び出しを用いることができる。

初期状態の構成変更ワークフローの内容が、図１４であるとき、ワークフロー更新手段は合計３回の構成変更準備要求を発行する。以下に、ワークフロー更新手段が発行する構成変更準備要求の内容の具体例を示す。

１回目の構成変更準備要求では、依存する構成変更操作を持たない構成変更操作１、２が構成変更準備要求の対象となる。この時点では、操作対象の資源は確定していないので、操作対象の資源を、抽象的な条件によって指定する。

１回目の構成変更準備要求に含まれる構成変更操作１の内容は、以下の通りである。

・対象の資源：特定の利用者に提供されていないサーバ機器５台
・操作の内容：対象の資源上でＷＷＷサーバプログラムを起動する。

１回目の構成変更準備要求に含まれる構成変更操作２の内容は、以下の通りである。

・対象の資源：特定の利用者に提供されていないサーバ機器１台
・操作の内容：対象の資源上でアプリケーションＷＷＷサーバプログラムを起動する。

この要求に対して、リソースマネージャは、条件を満たす資源を選択し、構成変更準備の処理を行う。その結果、構成変更操作１に対して、server12, server14, server15, server18, server22（これらは具体的なサーバ名を示す）の５つのサーバ機器を選択し、構成変更操作２に対して、server05のサーバ機器を選択したと仮定する。リソースマネージャは、構成変更準備要求に対応する準備通知に、これらの資源名を含める。

２回目の構成変更準備要求は、構成変更操作３、４を処理対象とする。これらの構成変更操作は、構成変更操作１、２に依存しており、構成変更操作１、２についての準備完了通知が到着した時点で構成変更準備要求の発行が可能になる。

２回目の構成変更準備要求に含まれる構成変更操作３の内容は、以下の通りである。

・対象の資源：server12, server14, server15, server18, server22
・操作の内容：対象の資源上で動作するＷＷＷサーバに対して、server04上で動作するアプリケーションサーバの情報を登録する。

２回目の構成変更準備要求に含まれる構成変更操作４の内容は、以下の通りである。

・対象の資源：server04
・操作の内容：対象の資源上で動作するアプリケーションサーバに対して、server12、server14、server15、server18、server22上で動作するＷＷＷサーバの情報を登録する。

３回目の構成変更準備要求では、構成変更操作５を処理対象とする。構成変更操作５の発行は、それが依存する構成変更操作３、４についての準備完了通知が到着した時点で可能になる。

３回目の構成変更準備要求に含まれる構成変更操作５の内容は以下の通りである。

・対象の資源：ＷＷＷサーバの負荷分散装置
・操作の内容：振り分け先のＷＷＷサーバの情報にserver12,server14,server15,server18,server22を追加する。

スーパースケジューラのワークフロー更新手段による３回の構成変更準備要求送信の結果、確定する構成変更ワークフローの内容の具体例を、図１５に示す。図１４と比較すると、すべての資源の指定が具体的な指定になっていることと、すべての構成変更操作が確定した状態になっている点で異なる。

構成変更ワークフローの内容が確定すると、スーパースケジューラ内の制御は、ワークフロー実行手段（図２の２４）に移り、構成変更操作の実行を開始する。構成変更実行要求の対象となる構成変更操作は、構成変更準備要求と同様に３回に分けて行う。

１回目では、図１５における構成変更操作１、２が対象となる。２回目では、構成変更操作３、４が対処となる。３回目では、構成変更操作５が対象となる。

構成変更準備および構成変更実行の段階において、リソースマネージャが備える資源情報ＤＢの内容の変化を図１６に示す。図１６中の「更新情報」において、[]内に対応する構成変更操作の番号を表記している。更新情報に、構成変更操作の番号（または何らかの識別子）を含めることは、準備済みの構成変更操作をキャンセルするために必要である。「[２]アプリケーションサーバ」は、対応する構成変更操作の番号が２であることを表している。

なお、図１６では、接続先のアプリケーションサーバの情報など、一部の情報を省略している。

図１６（Ａ）は、スーパースケジューラが１回目の構成変更準備要求を発行する直前の状態である。この段階では、構成変更の対象となる資源のどれも空き状態であり、準備が完了した構成変更操作はない。

図１６（Ｂ）は、図１５の構成変更ワークフローにおける全構成変更操作について構成変更準備が完了した直後の状態である。この段階では、構成変更操作の対象となる資源について、資源情報ＤＢ中の更新情報を追加した後ではあるが、実際の資源の構成には影響を与えていない。

図１６（Ｂ）の時点では、リソースマネージャが、図１６（Ｂ）に含まれる資源を対象とした他の構成変更準備要求を受け取ると、要求の実行に失敗する。

図１６（Ｃ）は、図１５の構成変更ワークフローにおける全構成変更操作について、構成変更の実行が完了した直後の状態である。この段階では、図１６（Ｂ）における更新情報の内容が、実際の資源の状態に反映されており、更新情報の内容は空となる。

上記の動作の結果、ＷＷＷサーバとアプリケーションサーバの起動と必要な情報の登録について、構成変更の実行と同じ順序で構成変更準備を実行することで、構成変更の実行時に失敗する事態を防ぐことができる。

本発明の第２の実施例は、複数の電子会議サーバと、その間のネットワークから構成される電子会議アプリケーションに、本発明の資源獲得システムを適用するものである。電子会議サーバは、独立して管理される２つの管理ドメインに分かれる。３つ以上の管理ドメインが存在する場合についても、本実施例の構成を、容易に拡張することが可能である。

図１７を参照すると、本実施例の電子会議システムは、クライアント（１）と、スーパースケジューラ（２）と、リソースマネージャ（３−１、３−２）と、電子会議サーバ（４Ｃ−１、４Ｃ−２）、帯域制御装置（４Ｄ−１、４Ｄ−２）、ネットワーク（６）を備える。このうち、リソースマネージャ３−１、電子会議サーバ４Ｃ−１、帯域制御装置４Ｄ−１は、管理ドメイン１（５−１）を構成する。また、リソースマネージャ３−２、電子会議サーバ４Ｃ−２、帯域制御装置４Ｄ−２は、管理ドメイン２（５−２）を構成する。ここで、クライアント（１）は資源獲得システムに対するクライアントであって、電子会議システムに対するクライアント（以下では、「利用者端末」と呼ぶ）とは異なる。なお、利用者端末は図１７には含まれない。

本実施例の電子会議システムは、利用者端末が、複数の電子会議サーバのどれか（利用者端末が属する管理ドメイン内にある電子会議サーバが望ましい）に接続し、電子会議サーバ間での転送を経て、他の利用者端末に映像を相互に送るものである。動作中の電子会議システムに、電子会議サーバを追加したり、新たに電子会議サービスを開始するためには、空きサーバを、電子会議サービスに割り当てるとともに、電子会議サーバ間のネットワーク（図１７の６）上の保証帯域を獲得する必要がある。ネットワークの保証帯域を獲得するためには、リソースマネージャ（３−１、３−２）を通して、帯域制御装置４Ｄ−１および４Ｄ−２を対象とした帯域獲得操作を実行する必要がある。

ここでは、管理ドメイン１、２からそれぞれ２台、３台の電子会議サーバを獲得し、それらの間のネットワーク帯域を、１００Mbps（メガビット／秒）獲得するというシナリオについて、具体的な動作内容を説明する。

まず、クライアント（１）がスーパースケジューラ（２）に対して、資源獲得要求を送る。第１の実施例と同様に、資源獲得要求を送るプロトコルには、ＨＴＴＰやＳＯＡＰなどが使用できる。資源獲得要求には以下の情報が含まれる。

・追加する電子会議サーバの台数：本シナリオでは管理ドメイン１に２台、管理ドメイン２に３台
・獲得する保証帯域：本シナリオでは100Mbps

次に、資源獲得要求を受け取ったスーパースケジューラが構成変更ワークフローを作成する。

ワークフロー生成手段（図２の２２）による構成変更ワークフローの生成の処理は第１の実施例と同様である。

図１８は、電子会議サーバの追加に関するワークフローテンプレートの内容である。図１８のワークフローテンプレートを基に、ワークフロー生成手段が出力する構成変更ワークフローの内容を図１９に示す。

第１の実施例と同様に、図１９では、確定していない資源を、<HOST1>のように不等号で囲む形で表現している。

次に、スーパースケジューラのワークフロー更新手段（図２の２３）により、構成変更準備要求の発行と、構成変更ワークフローの更新処理を行う。

初期の構成変更ワークフローの内容が図１９である場合、１回目に発行する構成変更準備要求では、構成変更操作１、２が対象となる。ただし、構成変更操作１と構成変更操作２では操作対象の資源が属する管理ドメインが異なるため、これらの構成変更操作は異なる構成変更準備要求とする。スーパースケジューラとリソースマネージャの間の通信には、ＨＴＴＰやＳＯＡＰなどのプロトコルを用いることができる。

１回目に発行する構成変更準備要求のうち、管理ドメイン１のリソースマネージャ（図１７の３−１）に送信するものは、構成変更操作１を要素とする。その内容は、以下の通りである。

・対象の資源：管理ドメイン１に属するサーバ機器のうち、空き状態であるもの２台
・操作の内容：対象の資源を電子会議サービスに割り当てる。

１回目に発行する構成変更準備要求のうち、管理ドメイン２のリソースマネージャ（図１７の３−２）に送信するものは、構成変更操作２を要素とする。その内容は、以下の通りである。

・対象の資源：管理ドメイン２に属するサーバ機器のうち、空き状態であるもの３台
・操作の内容：対象の資源を電子会議サービスに割り当てる。

スーパースケジューラのワークフロー更新手段は、上記の２つの構成変更準備要求に対応する準備完了通知が届いた後で、図１９の構成変更操作３、４を対象とする構成変更準備要求を送信する。構成変更操作１、２についての準備完了通知には、割り当てる電子会議サーバの名前が含まれるので、ここで送信する構成変更準備要求には具体的なサーバ名が入る。ここでは、<HOST1>から<HOST5>に、それぞれserver104, server107, server205, server206, server209という具体的なサーバ名が対応すると仮定する。１回目の構成変更準備要求の送信と同様に、構成変更操作３と４は異なるリソースマネージャを送信先とする個別の構成変更準備要求として送信する必要がある。

２回目に発行する構成変更準備要求のうち、管理ドメイン１のリソースマネージャに送信するものは、構成変更操作３を要素とする。その内容は、以下の通りである。

・対象の資源：帯域制御装置４Ｄ−１
・操作の内容：対象の資源から、資源server104, server107, server205, server206, server209間のネットワーク帯域100Mbpsを獲得する。

２回目に発行する構成変更準備要求のうち、管理ドメイン２のリソースマネージャに送信するものは、構成変更操作４を要素とする。その内容は以下の通りである。

・対象の資源：帯域制御装置４Ｄ−２
・操作の内容：対象の資源から、資源server104, server107, server205, server206, server209間のネットワーク帯域100Mbpsを獲得する。

ワークフロー更新手段が２回目に送信した構成変更準備要求についての準備完了通知を受け取ると、構成変更ワークフローの内容が確定し、構成変更の実行段階に移る。確定した構成変更ワークフローの内容を図２０に示す。

構成変更の実行段階では、第１の実施例と同様に、図２０に示した依存関係を満たす順序で構成変更操作を実行する。

構成変更準備および構成変更実行の段階において、リソースマネージャが備える資源情報ＤＢの内容の変化を図２１に示す。図１６と同様に、更新情報には対応する構成変更操作の番号を[]内に表記している。なお、図２１では、帯域制御装置に登録した電子会議サーバの情報など、一部の情報を省略している。

前記第１の実施例における資源情報ＤＢの内容（図１６）と図２１を比較すると、管理ドメインが２つになっているために、管理ドメインごとに個別に資源情報を管理しているという点で異なる。

また、前記第１の実施例では扱わなかった帯域制御装置が加わっている。本実施例では、帯域制御装置についての残りの保証帯域を帯域制御装置についてのエントリに含める。

また、更新情報には、構成変更準備の結果として提供が確定した保証帯域の大きさを含める。

構成変更準備の段階で、構成変更操作で獲得する保証帯域の大きさが、残り保証帯域（現在の残り保証帯域と更新情報中の保証帯域の合計）を下回ると、構成変更操作の検証に失敗する。ここで、図２１（Ｃ２）では、帯域制御装置４Ｄ−２について、残り保証帯域の値が０になっており、この状態では新たな帯域の確保はできない。

上記の動作の結果、電子会議サーバの追加と帯域制御装置について、構成変更の実行と同じ順序で構成変更の準備を行うことで、構成変更の実行時に失敗する事態を防ぐことができる。

以上本発明を上記実施例に即して説明したが、本発明は上記実施例の構成にのみ限定されるものでなく、本発明の範囲内で当業者であればなし得るであろう各種変形、修正を含むことは勿論である。

本発明によれば、ユーザ端末からの接続数に応じて、動的に、サーバの構成を変更するWorld Wide Webシステムのようなテクニックに適用することができる。また、電子会議の開催のために必要な、サーバ資源やネットワーク資源等を、動的に獲得する電子会議システムのような用途にも適用することができる。

本発明の第１の実施の形態のシステム構成を示す図である。 本発明の第１の実施の形態におけるスーパースケジューラ２の構成を示す図である。 本発明の第１の実施の形態におけるリソースマネージャ３の構成を示す図である。 本発明の第１の実施の形態における全体の動作を示すシーケンス図である。 本発明の第１の実施の形態におけるワークフロー生成手段２２の動作を示すフローチャートである。 本発明の第１の実施の形態におけるワークフロー更新手段２３の動作を示すフローチャートである。 本発明の第１の実施の形態におけるワークフロー実行手段２４の動作を示すフローチャートである。 本発明の第１の実施の形態における資源選択手段３２の動作を示すフローチャートである。 本発明の第１の実施の形態における構成変更操作検証手段３３の動作を示すフローチャートである。 本発明の第１の実施の形態における構成変更操作取消手段３４の動作を示すフローチャートである。 本発明の第１の実施の形態における構成変更操作実行手段３５の動作を示すフローチャートである。 本発明の第１の実施例のシステム構成を示す図である。 本発明の第１の実施例におけるワークフローテンプレートの内容を示す図である。 本発明の第１の実施例におけるワークフロー生成手段２２の出力である構成変更ワークフローの内容を示す図である。 本発明の第１の実施例におけるワークフロー更新手段２３の出力である構成変更ワークフローの内容を示す図である。 本発明の第１の実施例における資源情報データベース３６の内容を示す図である。 本発明の第２の実施例のシステム構成を示す図である。 本発明の第２の実施例におけるワークフローテンプレートの内容を示す図である。 本発明の第２の実施例におけるワークフロー生成手段２２の出力である構成変更ワークフローの内容を示す図である。 本発明の第２の実施例におけるワークフロー更新手段２３の出力である構成変更ワークフローの内容を示す図である。 本発明の第２の実施例における資源情報データベース３６の内容を示す図である。 従来の分散資源管理方式に基づく資源獲得システムの構成を示す図である。 構成変更ワークフローの更新手順を説明するための図である。

符号の説明

１ クライアント
２ スーパースケジューラ
３ リソースマネージャ
４ 計算機資源（資源；リソース）
４Ａ サーバ装置
４Ｂ 負荷分散装置
４Ｃ 電子会議サーバ
４Ｄ 帯域制御装置
５ 管理ドメイン
６ ネットワーク
７ ブローカ
８ 情報サービス
９ ＧＲＡＭ
２１ 通信手段
２２ ワークフロー生成手段
２３ ワークフロー更新手段
２４ ワークフロー実行手段
２５ ワークフローテンプレート記憶部
２６ 資源情報データベース
３１ 通信手段
３２ 資源選択手段
３３ 構成変更操作検証手段
３４ 構成変更操作取消手段
３５ 構成変更操作実行手段
３６ 資源情報データベース
３７ 構成変更操作記憶部
９１ ゲートキーパ
９２ ジョブマネージャ
９３ ローカルリソースマネージャ
９４ ＧＲＡＭレポータ

Claims (37)

1. 計算機資源の構成変更に際して、前記構成変更の操作（「構成変更操作」という）の実行可能性を、前記計算機資源の情報を参照して、検証する構成変更操作検証手段と、
   前記構成変更操作検証手段で検証済みの前記構成変更操作を、前記計算機資源に適用する構成変更操作実行手段と、
   を備えている、ことを特徴とする分散資源獲得システム。
2. 前記計算機資源のそれぞれについて前記計算機資源の現在の状態と更新情報を記憶する記憶部を備え、
   前記構成変更操作検証手段は、前記構成変更操作の対象となる前記計算機資源について、前記記憶部に記憶されている現在の状態と更新情報の内容に基づき、前記構成変更操作の実行可能性を検証する、ことを特徴とする請求項１記載の分散資源獲得システム。
3. 前記構成変更操作検証手段は、前記構成変更操作の実行が可能であると検証されたとき、前記記憶部の更新情報を前記構成変更操作に対応した情報で更新する、ことを特徴とする請求項１記載の分散資源獲得システム。
4. 前記構成変更操作実行手段は、前記構成変更操作の実行にあたり、前記計算機資源に関して前記記憶部に記憶されている更新情報を、前記計算機資源に適用し、前記計算機資源に対応する前記記憶部の現在の状態を、前記構成変更実行後の状態に設定する、ことを特徴とする請求項３記載の分散資源獲得システム。
5. 計算機資源の構成変更に際して、前記構成変更の操作（「構成変更操作」という）が実行可能であるか否かを、前記計算機資源の情報を参照して検証する構成変更操作検証手段と、
   前記構成変更操作検証手段で検証済みの前記構成変更操作を、前記計算機資源に適用する構成変更操作実行手段と、
   計算機資源の状態として、現在の状態と更新情報を少なくとも記憶保持する資源情報データベースと、を備え、
   前記構成変更操作検証手段が、前記資源情報データベースの情報のうち更新情報を更新し、
   前記構成変更操作実行手段が、前記資源情報データベースの更新内容を、前記計算機資源に対して適用する、ことを特徴とする分散資源獲得システム。
6. 資源の種別および数量に関して与えられた条件に基づいて、資源を選択し、前記選択された資源を対象とする構成変更操作の集合を生成する資源選択手段をさらに備えている、ことを特徴とする請求項１又は５に記載の分散資源獲得システム。
7. 分散システムの管理ドメインに対応して配設され、配下の計算機資源の管理を行うリソースマネージャ装置が、
   前記分散システムを構成する計算機とネットワークを介して通信する通信手段と、
   計算機資源の種別および数量に関して与えられた条件に基づいて、資源を選択し、前記選択された資源を対象とする構成変更操作の集合を生成する資源選択手段と、
   前記計算機資源の構成変更に際して、構成変更の操作（「構成変更操作」という）の実行可能性を検証する構成変更操作検証手段と、
   検証済みの構成変更操作の集合を計算機資源に適用する構成変更操作実行手段と、
   前記計算機資源の現状態と更新情報を少なくとも記憶保持する資源情報データベースと、
   を備え、
   前記資源選択手段は、前記計算機資源の構成変更に際して与えられる構成変更準備要求中で指定された条件を満たす資源を選択するとともに、選択した資源を対象とする構成変更操作列を生成し、
   前記構成変更操作検証手段は、前記資源選択手段によって生成された前記構成変更操作列の実行可能性を検証し、検証に成功した構成変更操作列を構成変更操作記憶部に格納し、
   前記構成変更操作実行手段は、前記構成変更操作記憶部に格納されている構成変更操作列を、実際の資源に対して適用し、
   前記構成変更操作記憶部に格納されている構成変更操作列は、前記構成変更操作検証手段による検証が完了したものであり、
   前記構成変更操作実行手段による前記構成変更操作列の実行は、前記資源情報データベースに格納されている資源の現状態の更新と、及び、前記資源の対応する更新情報の消去を含む、ことを特徴とするリソースマネージャ装置。
8. 計算機資源の構成変更の操作（「構成変更操作」という）の間の依存関係を表現する構成変更ワークフローを生成するワークフロー生成手段と、
   前記構成変更ワークフロー中の、各構成変更操作に関して構成変更ワークフローの内容を確定させるワークフロー更新手段と、
   前記構成変更ワークフロー中の確定した構成変更操作について依存関係を満たす順序で前記構成変更操作実行手段を用いることで、構成変更を実行するワークフロー実行手段と、
   を備えている、ことを特徴とする分散資源獲得システム。
9. 計算機資源の種別および数量に関して与えられた条件に基づいて、資源を選択し、前記選択された資源を対象とする構成変更操作の集合を生成する資源選択手段と、
   計算機資源の構成変更に際して、構成変更の操作（「構成変更操作」という）の実行可能性を検証する構成変更操作準備手段と、
   検証済みの構成変更操作の集合を前記計算機資源に適用する構成変更操作実行手段と、
   前記構成変更操作の間の依存関係を表現する構成変更ワークフローを生成するワークフロー生成手段と、
   前記構成変更ワークフロー中の各構成変更操作に関して、前記資源選択手段を用いることで、構成変更ワークフローの内容を確定させるワークフロー更新手段と、
   構成変更ワークフロー中の確定した構成変更操作について、依存関係を満たす順序で前記構成変更操作実行手段を用いることで構成変更を実行するワークフロー実行手段と、 を備えている、ことを特徴とする分散資源獲得システム。
10. 分散システムの複数の管理ドメインに対応して配設され、前記分散システムを構成する計算機とネットワークを介しての通信を行う通信手段と、
    複数の資源獲得のパターンに対応したワークフローテンプレートを記憶するワークフローテンプレート記憶部と、
    資源獲得の対象とする資源の情報を記憶する資源情報データベースと、
    前記ワークフローテンプレート記憶部に格納されたテンプレートを基にワークフロー中の構成変更操作について操作対象の資源が未確定状態である構成変更ワークフローを生成するワークフロー生成手段と、
    前記ワークフロー生成手段が生成した構成変更ワークフローを順次更新して、ワークフロー中のすべての要素について、操作対象の資源が確定している構成変更ワークフローを出力し、前記資源情報データベースを参照して、ワークフロー更新の際に、構成変更準備要求の送り先のリソースマネージャを決定するワークフロー更新手段と、
    前記ワークフロー更新手段から出力される、操作対象の資源が確定している構成変更ワークフローを受け、構成変更操作を実行し、その際、前記構成変更操作の実行のために、前記リソースマネージャに対する構成変更実行要求の送信を行うワークフロー実行手段と、
    を備えている、ことを特徴とするスケジューラ装置。
11. 配下の計算機資源を管理する、少なくとも１つのリソースマネージャと、
    少なくとも１つのスーパースケジューラと、
    を備え、
    前記リソースマネージャは、管理ドメインに対応させて配設され、
    前記スーパースケジューラは、１つ又は複数の管理ドメインにまたがって配設され、
    前記リソースマネージャは、計算機資源の構成変更に際して、構成変更の操作（「構成変更操作」という）の実行可能性を検証する構成変更操作準備手段と、
    前記構成変更操作準備手段で検証済みの前記構成変更操作の集合を計算機資源に適用する構成変更操作実行手段と、
    を備え、
    前記スーパースケジューラは、前記構成変更操作の間の依存関係を表現する構成変更ワークフローを生成するワークフロー生成手段と、
    構成変更ワークフロー中の各構成変更操作に関して前記資源選択手段を用いることで、構成変更ワークフローの内容を確定させるワークフロー更新手段と、
    構成変更ワークフロー中の確定した構成変更操作について、依存関係を満たす順序で前記構成変更操作実行手段を用いることで、構成変更を実行するワークフロー実行手段と、
    を備えている、ことを特徴とする分散資源獲得システム。
12. （Ａ１）計算機資源の構成変更に際して、前記構成変更の操作（「構成変更操作」という）の実行可能性を、前記計算機資源の情報を参照して検証するステップと、
    （Ａ２）検証済みの前記構成変更操作を、前記計算機資源に適用するステップと、
    を含む、ことを特徴とする分散資源獲得方法。
13. 前記計算機資源のそれぞれについて前記計算機資源の現在の状態と更新情報を記憶部で記憶管理し、
    前記ステップ（Ａ１）では、前記構成変更操作の対象となる前記計算機資源について、前記記憶部に記憶されている現在の状態と更新情報の内容に基づき、前記構成変更操作の実行可能性を検証する、ことを特徴とする請求項１２に記載の分散資源獲得方法。
14. 前記構成変更操作の実行が可能であると検証されたとき、前記記憶部の更新情報を前記構成変更操作に対応した情報で更新するステップを含む、ことを特徴とする請求項１３に記載の分散資源獲得方法。
15. 前記構成変更操作の実行にあたり、前記計算機資源に関して前記記憶部に記憶されている更新情報を、前記計算機資源に適用し、前記計算機資源に対応する前記記憶部の現在の状態を、前記構成変更実行後の状態に設定するステップを含む、ことを特徴とする請求項１４記載の分散資源獲得方法。
16. （Ａ３）資源の種別および数量に関して与えられた条件に基づいて資源を選択するステップと、
    （Ａ４）前記資源を対象とする構成変更操作の集合を生成するステップと、
    （Ａ５）前記構成変更操作について実行可能性を検証して、構成変更を実行するステップと、
    を含む、ことを特徴とする請求項１２に記載の分散資源獲得方法。
17. （Ｂ１）構成変更ワークフローを生成するステップと、
    （Ｂ２）前記構成変更ワークフローの各要素について資源の選択および実行可能の検証を行うステップと、
    （Ｂ３）前記構成変更ワークフローで記述される依存関係に従って構成変更の操作を実行するステップと、
    を含む、ことを特徴とする分散資源獲得方法。
18. 分散システムを構成するコンピュータに、
    （Ａ１）計算機資源の構成変更に際して、記憶部に記憶されている前記計算機資源を参照して、構成変更の操作（「構成変更操作」という）の実行可能性を検証する処理と、
    （Ａ２）検証済みの前記構成変更操作を前記計算機資源に適用することによって、構成変更を実行する処理と、
    を実行させるプログラム。
19. 請求項１８に記載のプログラムにおいて、
    前記処理（Ａ１）において、計算機資源の現状態と更新情報を格納する資源情報データベースの前記更新情報を更新する処理と、
    前記処理（Ａ２）において、前記資源情報データベース中の更新情報を、計算機資源に適用することで、構成変更を実行する処理を、前記コンピュータに実行させるプログラム。
20. 請求項１８に記載のプログラムにおいて、
    （Ａ３）資源の種別および数量に関して与えられた条件に基づいて資源を選択する処理と、
    （Ａ４）前記資源を対象とする構成変更操作の集合を生成する処理と、
    （Ａ５）前記構成変更操作について実行可能性を検証して、構成変更を実行する処理と、
    を前記コンピュータに実行させるプログラム。
21. 請求項１８又は１９に記載のプログラムにおいて、
    （Ｂ１）構成変更ワークフローを生成する処理と、
    （Ｂ２）前記構成変更ワークフローの各要素について資源の選択および実行可能の検証を行う処理と、
    （Ｂ３）前記構成変更ワークフローで記述される依存関係に従って構成変更操作を実行する処理と、
    を、前記コンピュータに実行させるプログラム。
22. 計算機システム内に１つまたは複数設置され、クライアント装置から資源獲得の要求を受け付け、１つまたは複数のリソースマネージャに対して資源の獲得を要求するスーパースケジューラと、
    管理ドメインに１つずつ設置され、前記管理ドメインに属する資源の情報を具備するとともに、前記資源の構成を変更するリソースマネージャと、
    を備え、
    資源の獲得要求を受け取った前記スーパースケジューラは、前記リソースマネージャが管理する資源を対象とする構成変更準備の要求の送信先であるリソースマネージャおよび構成変更準備要求の内容を決定して構成変更準備要求を送信先のリソースマネージャに対して送信し、
    前記構成変更準備要求を受け取った前記リソースマネージャは、前記構成変更準備要求に含まれる条件を満たす資源の中から提供する資源の候補を選択し、前記候補を対象とする構成変更操作列の実行可能性を検証し、
    前記リソースマネージャは、選択された資源の識別子情報を含む準備完了通知を、前記スーパースケジューラに送る、ことを特徴とする分散システム。
23. 計算機システム内に１つまたは複数設置され、クライアントから資源獲得の要求を受け付ける機能と、１つまたは複数のリソースマネージャに対して資源の獲得を要求する機能を備えたスーパースケジューラと、
    管理ドメインに１つずつ設置され、前記管理ドメインに属する資源の情報を具備するとともに、前記資源の構成を変更する機能を備えたリソースマネージャを備えた分散システムの資源獲得方法であって、
    （Ａ１）クライアントから、資源の獲得要求を受け取った前記スーパースケジューラは、前記リソースマネージャが管理する資源を対象とする構成変更準備を要求する構成変更準備要求の送信先である、リソースマネージャおよび構成変更準備要求の内容を決定するステップと、
    （Ａ２）前記スーパースケジューラが、前記構成変更準備要求を、決定した送信先のリソースマネージャに対して送信するステップと、
    （Ａ３）前記構成変更準備要求を受け取った前記リソースマネージャは、前記構成変更準備要求に含まれる条件を満たす資源の中から提供する資源の候補を選択し、前記候補を対象とする構成変更操作列の実行可能性を検証するステップと、
    （Ａ４）前記リソースマネージャは、選択された資源の識別子情報を含む準備完了通知を前記スーパースケジューラに送るステップと、
    を含む、ことを特徴とする分散資源獲得方法。
24. （Ａ５）前記要求されたすべての資源について、前記リソースマネージャでの実行可能性の検証が完了すると、前記スーパースケジューラは、構成変更準備段階で確定した構成変更操作のうち、実行の対象となるものを選択し、前記リソースマネージャに対して送信するための構成変更実行要求を作成するステップと、
    （Ａ６）前記スーパースケジューラは、作成した構成変更実行要求を前記リソースマネージャに送るステップと、
    （Ａ７）前記スーパースケジューラから、構成変更実行要求を受け取った前記リソースマネージャは、前記構成変更実行要求に含まれる構成変更操作の内容を実際の資源に対して適用するステップと、
    （Ａ８）構成変更操作の実行が完了した前記リソースマネージャは、前記スーパースケジューラに対して実行完了通知を送るステップと、
    を含む、ことを特徴とする請求項２３に記載の分散資源獲得方法。
25. （Ｂ１）前記スーパースケジューラは、前記クライアントからの資源獲得要求を受信し、資源獲得要求に指定された資源を獲得するための初期の構成変更ワークフローを生成するステップと、
    （Ｂ２）前記スーパースケジューラは、構成変更ワークフローの内容を更新し、その内容を確定させるステップと、
    を含む、ことを特徴とする請求項２３又は２４に記載の分散資源獲得方法。
26. 前記スーパースケジューラによる前記ステップ（Ｂ１）が、
    （Ｂ１０）構成変更ワークフローの元となるデータ構造からなるワークフローテンプレートを記憶する記憶部を参照して、受け取った資源獲得要求に該当するワークフローテンプレートを取得するステップと、
    （Ｂ１１）取得した前記ワークフローテンプレートに、前記資源獲得要求に含まれる資源量をセットし、初期状態の構成変更ワークフローを出力するステップと、
    （Ｂ１２）前記構成変更ワークフローに含まれる構成変更操作の集合のうち、処理対象となる構成変更操作の集合を選択するステップと、
    （Ｂ１３）前記選択した構成変更操作を構成要素とする構成変更準備要求を作成して前記リソースマネージャに送るステップと、
    （Ｂ１４）処理対象の構成変更ワークフローを構成する構成変更操作のうち、未確定状態の構成変更操作があるか否かを調べ、すべての構成変更操作が完了状態である場合には、次のステップ（Ｂ１５）に進み、それ以外の場合には前記ステップ（Ｂ１２）に戻り、他の構成変更操作について構成変更準備を行うステップと、
    （Ｂ１５）処理対象の構成変更ワークフローについて構成変更準備が完了したことを前記ステップ（Ｂ２）に通知するステップと、
    を含む、ことを特徴とする請求項２５に記載の分散資源獲得方法。
27. 前記スーパースケジューラは、
    （Ｂ１６）構成変更準備が不可能になった場合の終了処理として、処理対象の構成変更ワークフローに含まれる構成変更操作のうち、送信済みのすべての構成変更準備要求についてキャンセル処理を行うステップと、
    （Ｂ１７）処理対象の構成変更ワークフローに対応する資源獲得要求を送信したクライアントに対して、資源獲得の失敗を通知するステップと、
    を含む、ことを特徴とする請求項２６に記載の分散資源獲得方法。
28. 前記スーパースケジューラによる前記ステップ（Ｂ２）が、
    （Ｂ２０）処理対象の構成変更ワークフローから実行の対象とする構成変更操作の集合を取得するステップと、
    （Ｂ２１）前記リソースマネージャに対して、選択した構成変更操作の実行を要求するステップと、
    （Ｂ２２）送信した構成変更実行要求の応答を待ち、構成変更実行要求の実行に成功した場合、処理対象の構成変更ワークフローのうち、完了状態でない要素があるかどうかを調べ、該当する構成変更操作があれば、前記ステップ（Ｂ２０）に戻り、他の構成変更操作を実行し、すべての構成変更操作が完了していれば、資源獲得要求の送信者であるクライアントに対して資源獲得処理の完了を通知するステップと、
    （Ｂ２３）失敗した構成変更操作について代替の資源を選択するための処理として、失敗した構成変更操作と、前記構成変更操作に依存する構成変更操作を未確定状態に戻した後、構成変更を前記ステップ（Ｂ１）に通知し、再度構成変更ワークフローを更新するステップと、
    を含む、ことを特徴とする請求項２５に記載の分散資源獲得方法。
29. （Ｃ１）前記リソースマネージャが、計算機資源の情報として現在の状態と更新情報を格納する資源情報データベースを参照して、処理対象の構成変更操作で指定される条件を満たす資源のリストを取得するステップと、
    （Ｃ２）前記リソースマネージャが、取得したリスト中の各資源について、スコアを付与するステップと、
    （Ｃ３）前記リソースマネージャが、付与したスコアの順に、構成変更操作中に指定された数量の資源を選択し、選択可能な資源の数量が構成変更操作中に指定された数量を下回る場合、処理対象の構成変更準備要求の送信もとであるスーパースケジューラに対して資源選択の失敗を通知するステップと、
    （Ｃ４）前記リソースマネージャが、選択した各資源について構成変更操作列を生成するステップと、
    （Ｃ５）前記リソースマネージャが、作成した各構成変更操作列を対象として、検証処理を行うことを通知するステップと、
    を含む、ことを特徴とする請求項２３に記載の分散資源獲得方法。
30. （Ｃ６）前記リソースマネージャは、構成変更準備段階における構成変更操作検証にあたり、処理対象の構成変更操作列のうち、検証が未処理の要素を取り出すステップと、
    （Ｃ７）前記リソースマネージャが、取り出した構成変更操作を、前記資源情報データベースに適用し、その際、前記資源情報データベース中の操作対象の資源について、前記操作を実際の資源に適用した後の状態を、更新情報に追加し、実際の構成変更の際と同等のアクセス権チェックを行うステップと、
    （Ｃ８）前記リソースマネージャが、前記資源情報データベースの更新に成功すると、検証が未処理の構成変更操作がある場合、処理対象の構成変更操作列と、対応する構成変更操作の対を、構成変更操作記憶部に格納するステップと、
    （Ｃ９）前記リソースマネージャが、構成変更準備要求の送信者である前記スーパースケジューラに対して、処理対象の構成変更操作についての構成変更準備の準備完了通知を通知するステップと、
    （Ｃ１０）前記リソースマネージャは、前記資源情報データベースの更新で何らかのエラーが発生した場合、資源選択処理に代替の資源を検索することを通知するステップと、
    を含む、ことを特徴とする請求項２９に記載の分散資源獲得方法。
31. （Ｃ２０）前記リソースマネージャは、構成変更準備段階における、構成変更操作を取消すにあたり、メッセージキューから、処理対象の構成変更操作を要素とする構成変更準備要求を検索するステップと、
    （Ｃ２１）該当する構成変更操作がある場合には、通信部中のメッセージキューから、キャンセル対象の構成変更操作を要素とする構成変更準備要求を削除して、要求発行者に結果を通知するステップと、
    （Ｃ２２）該当する構成変更操作がない場合には、前記構成変更操作記憶部から、キャンセル対象の構成変更操作を検索するステップと、
    （Ｃ２３）前記構成変更操作の取得に成功した場合には、取得した構成変更操作の各要素の対象である資源について、前記資源情報データベース中の更新内容を消去するステップと、
    （Ｃ２４）前記構成変更操作記憶部から、キャンセル対象の構成変更操作と、取得した構成変更操作の対を削除するステップと、
    （Ｃ２５）該当する構成変更操作がない場合には、構成変更操作取消要求の送信者に対して結果を通知するステップと、
    を含む、ことを特徴とする請求項２９に記載の分散資源獲得方法。
32. （Ｃ３０）前記リソースマネージャが前記スーパースケジューラから構成変更実行要求を受け取り、構成変更操作実行処理は、要求中の指定に対応する構成変更操作列を取り出し、構成変更操作対象の資源に対して順に、構成変更の実行を指示するステップと、
    （Ｃ３１）構成変更操作記憶部を参照して、構成変更実行要求の指定に対応する構成変更操作列を取得するステップと、
    （Ｃ３２）取得した構成変更操作列を取り出して実行するステップと、
    （Ｃ３３）資源の構成変更に成功した場合、前記資源情報データベースにおける操作対象の資源について、現状態を構成変更実行後の状態に置き換え、更新情報からその操作の内容を削除するステップと、
    （Ｃ３４）残りの構成変更操作がある場合には、ステップ（Ｃ３２）に戻って、次の構成変更操作を実行し、すべての構成変更操作が完了すると、ステップ（Ｃ３７）に移り、
    （Ｃ３５）構成変更の実行に失敗した場合、前記ステップ（Ｃ３２）で取り出した構成変更操作列のうち、実行済みの各操作について逆操作を実行し、構成変更操作列を実行する前の状態に戻し、前記資源情報データベース中の情報についても、構成変更操作列を実行する前の状態に戻し、ステップ（Ｃ３６）に進むステップと、
    （Ｃ３６）前記ステップ（Ｃ３１）で取り出した構成変更操作列を構成変更操作記憶部から削除するステップと、
    （Ｃ３７）構成変更実行要求の発行者である前記スーパースケジューラに対して結果を通知するステップと、
    を含む、ことを特徴とする請求項２９に記載の分散資源獲得方法。
33. 分散システムを構成する管理ドメインに対応して配設され、配下の計算機資源の管理を行い、計算機資源の状態を記憶保持する資源情報データベースを有するリソースマネージャ装置を構成するコンピュータに、
    前記分散システムを構成する計算機とネットワークを介して通信する通信処理と、
    計算機資源の種別および数量に関して与えられた条件に基づいて、資源を選択し、前記選択された資源を対象とする構成変更操作の集合を生成する資源選択処理と、
    計算機資源の構成変更に際して、前記資源情報データベースに記憶されている前記計算機資源の情報を参照して、構成変更操作の実行可能性を検証する構成変更操作検証処理と、
    検証済みの構成変更操作の集合を計算機資源に適用する構成変更操作実行処理と、
    を実行させるプログラムであって、
    前記資源選択処理は、計算機資源の構成変更に際して与えられる構成変更準備要求中に、指定された条件を満たす資源を選択するとともに、選択した資源を対象とする構成変更操作列を生成し、
    前記構成変更操作検証処理は、前記資源選択処理によって生成された構成変更操作列の実行可能性を検証し、検証に成功した構成変更操作列を、構成変更操作記憶部に格納し、
    前記構成変更操作実行処理は、前記構成変更操作記憶部に格納されている構成変更操作列を、実際の資源に対して適用し、前記構成変更操作記憶部に格納されている構成変更操作列は、前記構成変更操作検証処理による検証が完了したものであり、
    前記構成変更操作実行処理による前記構成変更操作列の実行は、前記資源情報データベースに格納されている計算機資源の現在の状態の更新、及び、計算機資源に対応する更新情報の消去を含む、プログラム。
34. 分散システムを構成する複数の管理ドメインに対応して配設され、前記分散システムを構成する計算機とネットワークを介しての通信を行う通信部と、複数の資源獲得のパターンに対応したワークフローテンプレートを記憶するワークフローテンプレート記憶部と、資源獲得の対象とする資源の情報を記憶する資源情報データベースを備えたスーパースケジューラ装置を構成するコンピュータに、
    前記ワークフローテンプレート記憶部に格納されたテンプレートを基に、ワークフロー中の構成変更操作について操作対象の資源が未確定状態である構成変更ワークフローを生成するワークフロー生成処理と、
    前記ワークフロー生成処理で生成された構成変更ワークフローを順次更新して、ワークフロー中のすべての要素について操作対象の資源が確定している構成変更ワークフローを出力し、前記資源情報データベースを参照して、ワークフロー更新の際に、構成変更準備要求の送り先のリソースマネージャを決定するワークフロー更新処理と、
    前記ワークフロー更新処理から出力される、操作対象の資源が確定している構成変更ワークフローを受け、構成変更操作を実行し、その際、構成変更操作の実行のために、前記リソースマネージャに対する構成変更実行要求の送信を行うワークフロー実行処理と、
    を実行させるプログラム。
35. 複数の計算機が接続されてなる分散システムの構成変更方法において、
    構成変更要求を受けた際に該構成変更要求を解析し、構成変更対象の計算機資源を確定するステップと、
    記憶部に記憶されている計算機資源の資源情報を参照して、前記構成変更の実行可能性の検証を行うステップと、
    前記構成変更が実行可能である場合、前記記憶部に記憶されている計算機資源の資源情報のうち更新情報の欄を、実行が検証された前記構成変更の情報で更新するステップと、
    を含む、ことを特徴とする構成変更方法。
36. 前記構成変更の実行にあたり、前記記憶部に記憶されている前記計算機資源の資源情報のうちの更新情報の欄の情報を、前記計算機資源の現在の状態に設定する、ことを特徴とする請求項３５に記載の構成変更方法。
37. 複数の計算機が接続されてなる分散システムの構成変更方法において、
    構成変更の準備段階において、獲得する対象の計算機資源を確定するステップと、
    資源情報を格納した資源情報データベースに対して、構成変更操作の実行順序と同じ順序で更新を行うステップと、
    前記資源情報データベースの更新の際に、前記資源情報データベースの内容を基に構成変更の実行可否を判断するステップと、
    前記準備段階が終了した後で、構成変更の実行段階に移り、前記資源情報データベースの更新内容を実際の資源に対して適用するステップと、
    を含む、ことを特徴とする構成変更方法。

Images