(57)【要約】  【課題】  リソース割り振り要求をオンデマンド環境で効率的に処理する技法を提供すること。  【解決手段】  ユーザがリソース割り振り要求マネージャにログインすると、入力されたリソース要件がリモートリソースマネージャに即座に送信されて、リソース要件を入力しているユーザにリアルタイムでフィードバックすることができる。したがって、ユーザは、このフィードバックに基づいてリソース要求を再構成または他の方法で変更して、全体のリソース割り振り要求を最適化することができる。これにより、コンピュータホストサービス等のサービスを提供する組織も、新しいリソース要求が事前に顧客と取り決めたサービスレベル契約を超えることになる場合に、事前にリソースを再割り振りすることが可能になり、それにより、データセンタ環境でのリソースプランニングが向上する。さらに、サービスレベル契約を超える新規のリソース要求についての動的フィードバックを使用して、固有のリソース状況に対応した新規のサービスレベル契約または一時的なサービス提供を展開することができる。【選択図】      図５
2008535113.tif 000002
【特許請求の範囲】
【請求項１】
リソースリクエスタおよびリソースプロバイダを有するデータ処理環境で複数のリソースにオンデマンドでアクセスする方法であって、
複数のリソース要求を指定するユーザ入力を受信することにより複合企業リソース要求を生成するステップと、
第１のリソース要求についての第１のユーザ入力を受信したことに応答して、前記第１のリソース要求を識別する信号を前記リソースプロバイダに送信するステップと、
前記リソースプロバイダが、前記第１のリソース要求を満たすためにリソースが利用可能であるか否かを判断するステップと、
前記リソースが利用可能な場合、前記リソースが利用可能なことを示す応答を前記リソースプロバイダから前記リソースリクエスタに提供し、前記応答は、前記複合企業リソース要求が生成されている間に前記リソースリクエスタに提供される、ステップと、
を有する方法。
【請求項２】
前記リソースが利用可能な場合、前記リソースプロバイダが前記リソースリクエスタによる使用に向けて前記リソースを確保するステップを有する、請求項１に記載の方法。
【請求項３】
前記リソースが利用可能ではない場合、前記リソースプロバイダが前記リソースをリリースするステップと、前記リソースが使用できないことを示す応答を前記リソースプロバイダから前記リソースリクエスタに提供するステップと、を有する、請求項１に記載の方法。
【請求項４】
前記ステップ（ｄ）は、前記リソースをその後の使用のために確保するステップをさらに有する、請求項１に記載の方法。
【請求項５】
前記複合企業リソース要求を生成するステップは、階層リソース要求テンプレートを前記指定された複数のリソース要求で埋めるステップを有する、請求項１に記載の方法。
【請求項６】
データ処理環境において複数のリソースにオンデマンドでアクセスするシステムであって、
複数のリソース要求を指定するユーザ入力を受信することにより複合企業リソース要求を生成し、第１のリソース要求についての第１のユーザ入力を受信したことに応答して、前記第１のリソース要求を識別する信号を送信するリソースリクエスタと、
前記信号を受信したことに応答して、前記第１のリソース要求を満たすためにリソースが利用可能であるか否かを判断するリソースプロバイダであって、前記リソースが利用可能な場合、前記リソースが利用可能なことを示す応答を提供し、前記応答は、前記リソースリクエスタが前記複合企業リソース要求を生成している間に前記リソースリクエスタに提供される、リソースプロバイダと、
を有するシステム。
【請求項７】
前記リソースが利用可能な場合、前記リソースは前記リソースプロバイダにより前記リソースリクエスタによる使用に向けて確保される、請求項６に記載のシステム。
【請求項８】
前記リソースが利用可能ではない場合、前記リソースは前記リソースプロバイダによりリリースされ、前記リソースが使用できないことを示す応答が前記リソースプロバイダにより前記リソースリクエスタに提供される、請求項６に記載のシステム。
【請求項９】
前記複合企業リソース要求は、前記指定された複数のリソース要求を有する階層リソース要求テンプレートを有する、請求項６に記載のシステム。
【請求項１０】
コンピュータシステムにロードされて実行されると、前記コンピュータシステムに請求項１乃至５のいずれか１項に記載の方法のステップを実行させるコンピュータプログラムコードを有するコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ処理システムでのリソース管理に関し、特に、リモートリソース充足に対する包括的なリソース要求を生成する際のリソース可用性のリアルタイム解析に関する。
【背景技術】
【０００２】
今日の競争の激しくグローバルな経済状況では、多くの企業が特定のオペレーションを他の企業または国々あるいはその両方にアウトソーシングする手段をとっている。このようなアウトソーシングを望むユーザ／顧客は、供給業者（委託業者）と協働して、アウトソーシングする作業を定義して管理しなければならない。
【０００３】
グリッドとは、ソフトウェアアプリケーションが、広範囲にわたるロケーションにある多種多様な組織により管理される命令、表示、計算リソース、および情報リソースを統合できる環境である。グリッドコンピューティングとは、様々なアーキテクチャに基づき、様々な管理ドメインに属する、様々な場所にあるリソースの共有に関するすべてである。コンピュータグリッドは、今日、研究者および企業が求める最も要求の厳しい科学的アプリケーションおよび工学的アプリケーションを実行可能なコンピューティングリソースの強力なツールを生み出す。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
上記アウトソーシング環境は、ユーザがリモートリソースの動的割り振りを要求するグリッドコンピューティングモデルを包含するように進化しつつある。しかし、今日の技術では、通常、かなり前、たとえば数日から数週間前に予約する必要がある。こういった状況では、保守レベルサービス契約が顧客と供給業者（委託業者）との間で取り交わされ、それにより、顧客は、顧客のローカルリソースが利用限度を超え、追加作業をオフサイトに出さなければならない期間等の過負荷状況を補償する際に特定のリソースにしかアクセスすることができない。しかし、現在のサービスレベル契約（ＳＬＡ）は通常、非常に静的である。供給業者がリソースのまとまり、たとえばファイアウォール、ネットワークパーティショニング等を適宜計画して設計するには、顧客は特定のリソースセットを要求し、そのタイプに合わないあらゆるリソース、さらにはセキュリティのような特定のサービスクラスへのアクセスが提供されない。顧客は、供給業者のファイアウォールの背後にある「開かれた環境」にアクセスすることができない。さらに、このような環境でのリソース要求は、多くの場合、まず最初に全体を解析しなければ、利用可能リソースプール、価格、およびこのようなリソースをいつ割り振るかについていかなる判断も行えない、要件（ハードウェア、ソフトウェア、ネットワーク等）のかなり複雑な説明である。このタイプのオンデマンド環境では、ＳＬＡをより一般化することができ、より多くのリソースオプションが利用できるようになる動的リソース要求システムを使用して、リソース割り振り要求をより効率的に処理することが望ましい。
【課題を解決するための手段】
【０００５】
本発明は、オンデマンドまたはリアルタイム環境でリソース割り振り要求を効率的に処理する方法、システム、およびプログラムを提供する。このような効率は、リモートリソースマネージャによりリソース要求の階層レベルを解析することのみならず、それに加えて、要求がユーザ／リクエスタから入力されたときにこのようなリモートリソースマネージャが要求を受信することにより実現される。ユーザがリソース割り振り要求マネージャにログインすると、入力された種々のリソース要件がリモートリソースマネージャに即座に送信されて、リソース要件を入力しているユーザに、可用性の欠如等の要求されたリソース（複数可）またはプラグイン要素（複数可）に関する任意の問題または懸案事項についてフィードバックすることができる。したがって、ユーザは、このフィードバックに基づいて種々のリソース要求を再構成または他の方法で変更して、全体のリソース割り振り要求を最適化することができる。これにより、コンピュータホストサービス等のサービスを提供する組織も、新しいリソース要求が事前に顧客と取り決めたサービスレベル契約を超えることになる場合に、事前にリソースを再割り振りすることが可能になり、それにより、データセンタ環境でのリソースプランニングが向上する。さらに、ＳＬＡを超える新規のリソース要求についての動的フィードバックを使用して、固有のリソース状況に対応した新規のＳＬＡまたは一時的なサービス提供を展開することができる。
【０００６】
上記を実現するために、リソース要求を生成することができる原子的リソースモデルの階層説明を提供する。システムとのユーザの対話に応答して、リソース要求をリモートリソースマネージャに対して生成する離散信号システムが提供される。動的で部分的に構築された要求を処理するために、プラグインがリモートリソースマネージャに提供される。ユーザがフィールドを削除またはデコミットした場合、信号が動的にリモートリソースマネージャに送信されてリソースがデコミットされる。
【０００７】
本発明の好ましい実施形態について、添付図面を参照して単なる例としてこれより説明する。
【発明を実施するための最良の形態】
【０００８】
これより図を参照すると、図１は、本発明ののこ増井実施形態を実施することができるデータ処理システムネットワークの絵画図を示す。ネットワークデータ処理システム１００は、本発明の好ましい実施形態を実施することができるコンピュータのグリッドネットワークである。ネットワークデータ処理システム１００は、ネットワークデータ処理システム１００内で共に接続された各種装置およびコンピュータ間に通信リンクを提供するための媒体であるネットワーク１０２を含む。ネットワーク１０２は、有無線通信リンクまたは光ファイバケーブル等の接続を含むことができる。
【０００９】
図示の例では、サーバ１０４が記憶装置１０６と共にネットワーク１０２に接続される。さらに、クライアント１０８、１１０、および１１２がネットワーク１０２に接続される。これらクライアント１０８、１１０、および１１２は、たとえば、パーソナルコンピュータまたはネットワークコンピュータであることができる。図示の例では、サーバ１０４は、オペレーティングシステムイメージ、アプリケーション、またはハードウェアリソースへのアクセス等のリソースをクライアント１０８〜１１２に提供する。クライアント１０８、１１０、および１１２はサーバ１０４に対するクライアントである。ネットワークデータ処理システム１００は、さらなるサーバ、クライアント、および図示していない他の装置をさらに含んでもよい。図示の例では、ネットワークデータ処理システム１００は、ネットワーク１０２が伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）プロトコルスイーツを使用して互いに通信するネットワークおよびゲートウェイの世界規模の集まりを表すインターネットである。インターネットの心臓部では、データおよびメッセージをルーティングする数千もの企業、政府、教育機関、および他のコンピュータシステムからなる主要ノードまたはホストコンピュータ間の高速データ通信回線バックボーンがある。もちろん、ネットワークデータ処理システム１００は、たとえば、イントラネット、ローカルエリアネットワーク（ＬＡＮ）、または広域ネットワーク（ＷＡＮ）等の複数の異なる種類のネットワークとして実施されてもよい。図１は例を目的とし、本発明の構造的な限定を目的とするものではない。
【００１０】
図２を参照すると、本発明の好ましい実施形態による、図１のサーバ１０４等のサーバとして実施することができるデータ処理システム１００のブロック図を示す。データ処理システム２００は、システムバス２０６に接続された複数のプロセッサ２０２および２０４を含む対称マルチプロセッサ（ＳＭＰ）システムであることができる。別法として、シングルプロセッサシステムを利用してもよい。システムバス２０６には、ローカルメモリ２０９へのインタフェースを提供するメモリコントローラ／キャッシュ２０８も接続される。Ｉ／Ｏバスブリッジ２１０がシステムバス２０６に接続され、Ｉ／Ｏバス２１２へのインタフェースを提供する。メモリコントローラ／キャッシュ２０８およびＩ／Ｏバスブリッジ２１０は、図示のように一体化することができる。
【００１１】
Ｉ／Ｏバス２１２に接続された周辺機器相互接続（ＰＣＩ）バスブリッジ２１４が、ＰＣＩローカルバス２１６へのインタフェースを提供する。複数のモデムをＰＣＩローカルバス２１６に接続することができる。典型的なＰＣＩバスの実施態様は、４つのＰＣＩ拡張スロットまたはアドインコネクタをサポートしている。図１のクライアント１０８〜１１２への通信リンクは、アドインボードを通してＰＣＩローカルバス２１６に接続されたモデム２１８およびネットワークアダプタ２２０を通して提供することができる。
【００１２】
追加のＰＣＩバスブリッジ２２２および２２４が追加のＰＣＩローカルバス２２６および２２８へのインタフェースを提供し、そこから追加のモデムまたはネットワークアダプタをサポートすることができる。このようにして、データ処理システム２００では、複数のネットワークコンピュータに接続することができる。メモリマップドグラフィックスアダプタ２３０およびハードディスク２３２も、直接または間接的に、図示のようにＩ／Ｏバス２１２に接続することができる。
【００１３】
図２に示すハードウェアが変更可能であることを当業者は理解しよう。たとえば、光ディスクドライブ等の他の周辺機器も、図示のハードウェアに加えて、またはこれに代えて使用することができる。図示の例は、本発明に関する構造的な制限を示すことを意図するものではない。
【００１４】
図２に示すデータ処理システムは、たとえば、Ａｄｖａｎｃｅｄ  Ｉｎｔｅｒａｃｔｉｖｅ  Ｅｘｅｃｕｔｉｖｅ（ＡＩＸ）（Ｒ）オペレーティングシステムまたはＬＩＮＵＸ（Ｒ）オペレーティングシステムを走らせている、ニューヨーク州アーモンク（Ａｒｍｏｎｋ）に所在のＩｎｔｅｒｎａｔｉｏｎａｌ  Ｂｕｓｉｎｅｓｓ  Ｍａｃｈｉｎｅｓ  Ｃｏｒｐｏｒａｔｉｏｎの製品であるＩＢＭ  ｅＳｅｒｖｅｒ（Ｒ）  ｐＳｅｒｉｅｓ（Ｒ）システムであることができる。
【００１５】
これより図３を参照して、本発明を実施することができるデータ処理システムを示すブロック図を示す。データ処理システム３００はクライアントコンピュータの例である。データ処理システム３００は、周辺機器相互接続（ＰＣＩ）ローカルバスアーキテクチャを利用する。図示の例ではＰＣＩバスを利用するが、ＡＧＰ（Ａｃｃｅｌｅｒａｔｅｄ  Ｇｒａｐｈｉｃｓ  Ｐｏｒｔ）およびＩＳＡ（Ｉｎｄｕｓｔｒｙ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ）等の他のバスアーキテクチャを使用することもできる。プロセッサ３０２およびメインメモリ３０４が、ＰＣＩブリッジ３０８を通してＰＣＩローカルバス３０６に接続される。ＰＣＩブリッジ３０８は、プロセッサ３０２のためのメモリコントローラとキャッシュメモリが一体化されたものを含むこともできる。ＰＣＩローカルバス３０６に、構成要素の直接相互接続を通して、またはアドインボードを通してさらに接続することができる。図示の例では、ローカルエリアネットワーク（ＬＡＮ）アダプタ３１０、ＳＣＳＩホストバスアダプタ３１２、および拡張バスインタフェース３１４が、構成要素の直接接続によりＰＣＩローカルバス３０６に接続される。これとは対照的に、オーディオアダプタ３１６、グラフィックスアダプタ３１８、およびオーディオ／ビデオアダプタ３１９が、拡張スロットに挿入されたアドインボードによりＰＣＩローカルバス３０６に接続される。拡張バスインタフェース３１４は、キーボード・マウスアダプタ３２０、モデム３２２、および追加のメモリ３２４に接続を提供する。小型コンピュータシステムインタフェース（ＳＣＳＩ）ホストバスアダプタ３１２が、ハードディスクドライブ３２６、テープドライブ３２８、およびＣＤ−ＲＯＭドライブ３３０に接続を提供する。典型的なＰＣＩローカルバス実施態様は３つまたは４つのＰＣＩ拡張スロットまたはアドインコネクタをサポートする。
【００１６】
オペレーティングシステムがプロセッサ３０２で実行され、図３のデータ処理システム３００内の各種構成要素を調整し、制御を提供するために使用される。オペレーティングシステムは、Ｍｉｃｒｏｓｏｆｔ（Ｒ）Ｃｏｒｐｏｒａｔｉｏｎから入手可能なＷｉｎｄｏｗｓ  ＸＰ（Ｒ）等の市販のオペレーティングシステムであることができる。Ｊａｖａ（Ｒ）等のオブジェクト指向プログラミングシステムをオペレーティングシステムと併せて実行することができ、データ処理システム３００で実行されているＪａｖａ（Ｒ）プログラムまたはアプリケーションからオペレーティングシステムに呼び出しを提供する。「Ｊａｖａ」はＳｕｎ  Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．の商標である。オペレーティングシステム、オブジェクト指向オペレーティングシステム、およびアプリケーションまたはプログラムへの命令は、ハードディスクドライブ３２６等の記憶装置に配置され、メインメモリ３０４にロードしてプロセッサ３０２により実行することができる。
【００１７】
図３のハードウェアが実施態様に応じて変更可能であることを当業者は理解しよう。フラッシュ読み取り専用メモリ（ＲＯＭ）、同等の不揮発性メモリ、または光ディスクドライブ等の他の内部ハードウェアまたは周辺機器を、図３に示すハードウェアに加えて、またはこれに代えて使用することができる。また、本発明のプロセスはマルチプロセッサデータ処理システムに適用することも可能である。
【００１８】
別の例として、データ処理システム３００は、ある種のネットワーク通信インタフェースに頼ることなく起動可能なように構成されたスタンドアロンシステムであってもよい。さらなる例として、データ処理システム３００は、ＲＯＭまたはフラッシュＲＯＭあるいはこの両方が構成されて、オペレーティングシステムファイルまたはユーザ生成データあるいはこの両方を記憶するための不揮発性メモリを提供する携帯情報端末（ＰＤＡ）装置であってもよい。
【００１９】
図３に示す例および上述した例は構造的な制限を示すものではない。たとえば、データ処理システム３００は、ＰＤＡの形態をとることに加えて、ノート型コンピュータまたはハンドヘルドコンピュータであってもよい。データ処理システム３００はキオスクまたはウェブアプライアンスであってもよい。
【００２０】
これより図４を参照して、本発明による分散コンピューティング環境においてリソースを要求するシステムを４００で示す。ユーザ要求が、図１に示すクライアント１０８等のクライアント装置の一部であるか、またはクライアント装置に取り付けることができる端末４０２を使用してユーザにより入力される。ユーザ要求は、ブロック４０４に示すような複数の異なる種類の要求のいずれであってもよく、ログイン要求、サーバまたは記憶装置等のシステムのシステムレベル要求、オペレーティングシステム（Ｏ／Ｓ）等のソフトウェアのシステムソフトウェア要求、マイクロコード（ユーコード（ｕｃｏｄｅ））またはデバイス／アダプタドライバ（複数可）、プロセッサ、ネットワーク、または記憶装置等のハードウェアのシステムハードウェア要求、アプリケーションミドルウェア要求、ジオグラフィ要求、セキュリティ要求、およびキャパシティ／パフォーマンス要求を含むことができる。ユーザ要求は、図１に示すネットワーク１０２等のネットワークとして実施することができるパス４０６を介して、図１に示すサーバ１０４等のサーバにより実施することができる要求ゲートウェイ４０８に送られる。要求ゲートウェイにおいて、スレッドがスレッドプール４１０から作成され、このスレッドが、要求ゲートウェイ４０８において、ユーザからの要求信号および許可／非許可リソース割り振り試行等の後続信号およびエラーを処理する有限状態マシン（ＦＳＭ）４１２を作成する。有限状態マシン４１２は、状態テーブル４１６と併せてエラー状況を含む異なる状態の要求を管理するプラグインワークフロー４１４を動的に作成する。有限状態マシンはリソースデータベース４１８を使用して、要求されたリソースが利用できるか否かを判断し、要求のすべての信号を受け取るまでリソースを一時的にコミットする。要求翻訳およびプロビジョニングエンジン４２２との調整へのプラグインは、有限状態マシンのランタイムエンジン４２４内で動的に実行される。これらプラグインは４２０で示され、プラグインライブラリの一部である。これらプラグインは、４２０に示すように、ログイン、システム要求（たとえば、サーバ、記憶装置）、システムソフトウェア要求（たとえば、オペレーティングシステム、マイクロコード、ドライバ）、システムハードウェア要求（たとえば、プロセッサ、ネットワーク、記憶装置）、アプリケーションミドルウェア要求、ジオグラフィ、セキュリティ、およびキャパシティ／パフォーマンス等の機能を提供することができる。エラーまたは利用不可信号を、ユーザ要求の状態に基づいて任意の時点で生成することができる。
【００２１】
これより図５を参照して、４０２等のユーザ端末と４０８等の要求ゲートウェイとの間での流れる典型的な一連の信号またはトランザクションを５００で示す。このシナリオでは、ユーザが複合企業リソース要求ファイルまたはモデルを生成しており、個々のリソース要求を入力し、このリソース要求はユーザ端末４０２で受け取られて、複合企業リソース要求テンプレート（図示せず）に統合される。多くの要求のうちの最初の要求を受け取ったことに応答して、第１のリソース要求が５０２において通知される。この信号により初期要求メッセージが生成され、５０４において要求ゲートウェイに送られる。この初期要求メッセージが５０６において要求ゲートウェイ４０８により受け取られ、肯定応答が要求ゲートウェイにより５０８において通知される。この信号により、要求肯定応答メッセージがネットワークを介して５１０において送られ、５１２においてユーザ端末で受け取られる。この初期リソース要求は、たとえばログインコマンドであることができる。次に、５１４で開始されるように、特定のｎ個のプラグインリソースが要求ゲートウェイに順次送られる。個々のリソースの順次送信は、複合企業テンプレートを使用する場合であっても行われる。個々のリソースの送信とクライアント複合企業テンプレートとの間でのこの相互作用の例が、ニューヨーク州アーモンク（Ａｒｍｏｎｋ）に所在のＩｎｔｅｒｎａｔｉｏｎａｌ  Ｂｕｓｉｎｅｓｓ  Ｍａｃｈｉｎｅｓ  Ｃｏｒｐｏｒａｔｉｏｎから入手可能なビジネスゲートウェイであるＩＢＭ  ＷｅｂＳｐｈｅｒｅ（Ｒ）アプリケーションサーバにより提供される。これらプラグイン要求のうちの最初の要求が５１６において送信され、要求ゲートウェイにより受信され、５１８において、図４の４２０に示すようなプラグインデータベース／ライブラリが照会または参照されて、このようなプラグインリソースの可用性が判断される。状態応答が５２０において要求ゲートウェイにより送信され、５２２においてネットワーク４０６を介して送信される。この応答の受信に応答して、ゲートウェイクライアント（図示していないが、さらに後述する）が次に、５２４において、最初のプラグイン要求と同様にして２〜ｎ番目のプラグイン要求に対する要求を順次通知し、要求ゲートウェイ４０８は、最初の要求と同じように５２６および５２８においてこれらを処理し、結果として肯定応答が５３０においてリクエスタに通知される。ゲートウェイクライアントは、ユーザ／リクエスタの代理として動作して、動的要求システムに統合し、受信応答をまとめ、適当な情報をユーザに提示する実行可能モジュール（ｅｘｅｃｕｔａｂｌｅ）である。このようなクライアント実行可能モジュールは、リクエスタマシンに常駐する、またはリクエスタマシンで実行される必要はないが、応答を処理し、情報をリクエスタに提示する際にリクエスタの代理として動作する必要がある。このようなクライアントの例は、Ｊａｖａ（Ｒ）アプレットである。代表的なプラグインリソースを図５の５９０で示す。
【００２２】
リソースプラグイン要求は要求ゲートウェイ４０８により受け取られ、要求されたリソースが利用可能であるか否かについて５３２で下された判断に応答して、利用可能な場合にはプラグインが５３４において提供され、または利用不可能な場合にはプラグイン予約要求が５４０においてリリースされる。利用可能な場合、信号が５４６において生成される（その後、リソース接続５５０および５４８を介して送信される応答メッセージに含めるため）。リソースが利用不可能であり、リリースされている場合、５４２においてリリースメッセージが送信され、５４４においてリソース要求がキャンセルされたことを示す警告メッセージがユーザ端末に生成される。この警告メッセージは、好都合なことに、リモートリソースマネージャからのリソース状態についての動的でリアルタイムのフィードバックを提供し、ユーザ／リクエスタが、このようなリソースプラグイン利用不可能性を考慮して各自の全体リソース要求パッケージを調整できるようにする。
【００２３】
すべてのリソース要求が処理されると、リソース接続が５４８、５５０、および５５２によって提供されて、要求されたリソースが提供される。リソースは、好ましい実施形態ではグリッドコンピュータ環境においてリモートに、このような要求されたリソースをアウトソースしているリクエスタ／顧客に提供される。アウトソースされたサービスまたはジョブが完了すると、ユーザ端末は５５４においてジョブ完了要求を通知し、要求完了メッセージが５５６において送信され、５５８において要求ゲートウェイにより受信される。ゲートウェイ４０８は５６０において肯定応答を通知し、肯定応答メッセージが５６２においてユーザ／リクエスタに送信され、５６４において受信される。ユーザ端末４０２ｄ得実行されているリソース割り振り要求マネージャアプリケーションが、５６４において受信したジョブ完了要求肯定応答信号に応答して、５６６においてリソースリリースメッセージを通知し、これが５６８においてネットワークを介して送信され、要求ゲートウェイが５７０において、この完了したジョブに関連する１−ｎ個のプラグインをリリースすることになる。要求ゲートウェイは、５７２においてリリースに対して肯定応答し、これが５７４においてユーザ端末に送信され、５７６において受信され、それによって現在のアウトソースジョブが終了する。
【００２４】
この動的リソース割り振り方式では、好都合なことに、コンピュータホストサービス等のサービスを提供する組織が、リソースを再割り振りしなければ顧客とのサービスレベル契約に違反することになる場合に、事前にこのようなリソースの再割り振りを行うことが可能であり、それによってデータセンタ環境でのリソースプラニングを向上させる。
【００２５】
上記データフローを容易にするために、いくつかのコンピュータシステムが最低の共通構築ブロックを有する原子的リソースモデルの階層的説明を提供する。たとえば、図６に示すように、クラスタ６０２がソフトウェア６０４およびハードウェア６０６を使用して構築されるシステムである。ソフトウェア６０４は、アプリケーション環境６０８、システム管理６１０、データ管理６１２、および作業負荷管理６１４を使用して構築される。データ管理６１２は、１つまたは複数のデータベース６１６および１つまたは複数のファイルシステム６１８を使用して構築される。ハードウェアは、サーバ（複数可）６２０、記憶装置６２２、およびネットワーク６２４で示すようなサーバ、ディスク、およびネットワークを使用して構築される。特定の容量を超えるディスクを定義することは恐らく難しいため、記憶装置６２２は原子的リソースとみなされる。別法として、ディスク記憶装置およびテープ記憶装置等の複数の異種類の記憶装置が提供された場合、記憶装置は、各自を原子的リソースであるとみなすことができるディスク記憶装置およびテープ記憶装置を含むようにより低いレベルにさらにモデリングすることができる。サーバ６２０およびネットワーク６２４についてはさらに詳細に説明することができる。サーバ６２０については、オペレーティングシステム６２６、Ｉ／Ｏ６２８、オンボードメモリ６３０、およびプロセッサ６３２を使用して説明することができる。ネットワークについては、スイッチ６３４および接続タイプ６３６により説明することができる。これらの各場合で、原子的リソース（たとえば、プロセッサ６３２、記憶装置６２２、データベース６１６、システム管理６１０）そして複合リソース（たとえば、ソフトウェア６０４およびハードウェア６０６）の階層を使用して、クラスタが定義される。複数のこのようなクラスタをさらに編成して、グリッドコンピューティング環境で使用するマルチクラスタ実施態様（図示せず）にすることができる。
【００２６】
さらに、この階層モデルは、要求されるリソース／システムで必要になり得る異なるイベントまたは応答を包含するように拡張することが可能である。たとえば、「アプリケーション「Ａ」の実行により多くの容量が必要」等の単一イベントをいくつかのより小さなイベント：（ｉ）「タイプＥのボックスがもっと必要である」、（ｉｉ）「スイッチプレーン３でより多くのネットワーク帯域が必要である」、（ｉｉｉ）同様の応答セットに対応する「サーバ９．２．９．３２上のアプリケーションＪをサスペンドしなければならない」、（ｉｖ）「システムマネージャがサーバ９．２．９．３２上のアプリケーションＪをサスペンド中である」、（ｖ）「スイッチ構成更新済み」、（ｖｉ）「サーバ９．２．９．３２でのＬｉｎｕｘ（Ｒ）カーネル再構築」に分けることができ、これらは全部で、集約応答「アプリケーションＡにより多くのシステムが割り振られて構築された」に対応する。こうして、リソース要求に対する複雑な応答を、システム内の基本構築ブロックに対する基本的または原子的な応答から構築される。
【００２７】
複合企業テンプレートの例を図４に見ることができる。この図では、テンプレートはクライアント側（４０４）に示され、ユーザがリソース要求の種々の部分を構築することによって構築されている。サーバまたはシステム側４０８では、複合企業がこの個々の要求を受信してから、有限状態マシンにより決定される適当なプラグインを使用してリソース要求を動的に組み立てることによって再構築される。好ましい実施形態では、複合企業テンプレートは、プラグイン実行前にサーバ側で全体的に組み立てられる必要はないが、プラグインにより行われたアクションの履歴トレースを使用して、サーバ側で複合企業テンプレートを再構築することができる。
【００２８】
したがって、オンデマンド環境でリソース割り振り要求を効率的に処理する改良された技術が提供される。このような効率は、リモートリソースマネージャによりリソース要求の階層レベルを解析することのみならず、それに加えて、要求がユーザ／リクエスタから入力されたときにこのようなリモートリソースマネージャが要求を受信することにより実現される。ユーザがリソース割り振り要求マネージャにログインすると、入力された種々のリソース要件がリモートリソースマネージャに即座に送信されて、リソース要件を入力しているユーザに、可用性の欠如等の要求されたリソース（複数可）に関する任意の問題または懸案事項についてフィードバックすることができる。したがって、ユーザは、このフィードバックに基づいて種々のリソース要求を再構成または他の方法で変更して、全体のリソース割り振り要求を最適化することができる。
【００２９】
本発明について十分に機能するデータ処理システムの文脈の中で説明したが、本発明のプロセスがコンピュータ可読媒体の命令の形態または種々の形態で配布が可能であり、本発明が配布の実行に実際に使用される信号搬送媒体の特定の種類に関係なく等しく適用されることを当業者が理解するであろうことに留意することが重要である。コンピュータ可読媒体の例としては、フレキシブルディスク、ハードディスクドライブ、ＲＡＭ、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ等の記録可能型媒体、ならびに伝送形態、たとえば無線周波および光波伝送等を使用したデジタル通信リンク、アナログ通信リンク、有無線通信リンク等の伝送型媒体が挙げられる。コンピュータ可読媒体は、特定のデータ処理システムで実際に使用するために復号化された符号化フォーマットの形態をとってもよい。
【００３０】
本発明の説明は例示および説明のために提示され、網羅的である、すなわち本発明を開示された形態に限定することを意図するものではない。当業者には多くの変更および変形が明らかであろう。実施形態は、本発明の原理、実際の適用を最良に説明し、意図する特定の用途に合うように種々の変更を伴った各種の実施形態に関して当業者が本発明を理解できるようにするために選択され説明されたものである。
【図面の簡単な説明】
【００３１】
【図１】本発明の好ましい実施形態による分散データ処理システムを示す図である。
【図２】本発明の好ましい実施形態によるサーバの例示的なブロック図である。
【図３】本発明の好ましい実施形態によるクライアントの例示的なブロック図である。
【図４】リソース要求・充足システムの例示的な全体構造である。
【図５】ユーザ／クライアント装置で実行されているリソースリクエスタアプリケーションとサーバで実行されているリモートリソースマネージャとの間の例示的なメッセージ交換である。
【図６】例示的な階層リソースモデルである。
【図１】
2008535113.tif 000003
【図２】
2008535113.tif 000004
【図３】
2008535113.tif 000005
【図４】
2008535113.tif 000006
【図５】
2008535113.tif 000007
【図６】
2008535113.tif 000008
【国際調査報告】
2008535113.tif 000009
2008535113.tif 000010
2008535113.tif 000011