(57)【要約】【課題】現在アクティブかつ使用可能なグリッド・ハードウェアが、インバウンド・グリッド・ジョブが必要とするソフトウェア環境を含んでいない場合、その必要なソフトウェア環境を自動化された様式で構築するためのメカニズムを提供すること。【解決手段】グリッド・コンピューティング・システム内のコンピューティング環境は、必要なハードウェアのアクティブ化、オペレーティング・システム、アプリケーション・プログラム、およびソフトウェア・ドライバの提供を含み、グリッド・リソース・アロケータからの特定のジョブ・リソース要件に応答して動的に構築される。最適には、特定ジョブのためのコンピューティング環境を構築するのに先立ってコスト／収益の分析が実行され、環境の構築およびジョブの実行によって運用目標に合致しない場合、ジョブ売却プロセスが開始される。【選択図】  図３
2008502967.tif 000002
【特許請求の範囲】
【請求項１】
グリッド・リソース・アロケータからジョブ環境要件セットを受け取るための入力であって、前記ジョブ環境要件はグリッド・コンピューティング環境内でジョブを実行するために必要な１つまたは複数のパラメータを示し、前記パラメータはオペレーティング・システム、アプリケーション・プログラム、およびソフトウェア・ドライバのグループから選択された１つまたは複数の基準を含む、入力と、
現在ジョブ・コンピューティング環境内に構成されていない１つまたは複数の必要なリソースが使用可能であるかどうかを判定するために、グリッド・カタログおよびストレージ・サブシステムにアクセスするためのカタログ・クエリアであって、前記カタログは、使用可能なオペレーティング・システム用のインストール・イメージ、アプリケーション・プログラム用のインストール・プログラム、およびソフトウェア・ドライバ用のインストール・プログラムの、１つまたは複数のインデックスを含む、カタログ・クエリアと、
前記グリッド・コンピューティング環境内で好適な使用可能ハードウェア・プラットフォームを選択するように、前記カタログから１つまたは複数のインデックスを受け取るように、および、前記ジョブ環境要件に合致するコンピューティング環境を作成するために、前記ハードウェア・プラットフォーム上で１つまたは複数のソフトウェア・インストール・オペレーションを実行するように、構成された環境ビルダと、
を有する、グリッド・コンピューティング環境内でコンピューティング環境を動的に構築するための論理デバイス。
【請求項２】
必要なコンピューティング環境がある動作目的および規則に合致するかどうかを判定し、合致しない場合は、前記環境ビルダが前記コンピューティング環境を構築しないように構成された、構築ケース・エバリュエータをさらに有する、請求項１に記載の論理デバイス。
【請求項３】
前記エバリュエータが、リソース活動化料金を評価するように、コンピューティング環境が構築された場合に発生する合計料金を計算するように、および、前記合計料金と収益目標とを比較するように構成される、請求項２に記載の論理デバイス。
【請求項４】
前記エバリュエータが、ハードウェア・リソース、ハードウェア保守コスト、およびライセンス交付料金の活動化のための、料金グループから選択されたリソース活動化料金を評価するように構成される、請求項３に記載の論理デバイス。
【請求項５】
さらに前記エバリュエータが、前記合計料金と前記収益目標との比較が所定の目標に合致しないとの判定に応答して、ジョブの売却プロセスを開始するように構成される、請求項３に記載の論理デバイス。
【請求項６】
前記カタログが、オペレーティング・システムおよび１つまたは複数のアプリケーション・プログラムを含むバンドル用に組み合わされたインストール・イメージをさらに有する、請求項１に記載の論理デバイス。
【請求項７】
前記パラメータがオペレーティング・システム用の保守レベル要件をさらに有する、請求項１に記載の論理デバイス。
【請求項８】
前記パラメータがオペレーティング・システム用の更新レベル要件をさらに有する、請求項１に記載の論理デバイス。
【請求項９】
グリッド・リソース・アロケータからジョブ環境要件セットを受け取るステップであって、前記ジョブ環境要件はグリッド・コンピューティング環境内でジョブを実行するために必要な１つまたは複数のパラメータを示し、前記パラメータはオペレーティング・システム、アプリケーション・プログラム、およびソフトウェア・ドライバのグループから選択された、１つまたは複数の基準を含む、受け取るステップと、
現在ジョブ・コンピューティング環境内に構成されていない１つまたは複数の必要なリソースが使用可能であるかどうかを判定するために、グリッド・カタログおよびストレージ・サブシステムにアクセスするステップであって、前記カタログは、使用可能なオペレーティング・システム用のインストール・イメージ、アプリケーション・プログラム用のインストール・プログラム、およびソフトウェア・ドライバ用のインストール・プログラムの、１つまたは複数のインデックスを含む、アクセスするステップと、
前記グリッド・コンピューティング環境内で好適な使用可能ハードウェア・プラットフォームを選択するステップと、
前記カタログから１つまたは複数のインデックスを受け取るステップと、
前記ジョブ環境要件に合致するコンピューティング環境を作成するために、前記選択されたハードウェア・プラットフォーム上で１つまたは複数のソフトウェア・インストール・オペレーションを実行するステップと、
を有する、グリッド・コンピューティング環境内でコンピューティング環境を動的に構築するための方法。
【請求項１０】
必要なコンピューティング環境がある動作目的および規則に合致するかどうかを判定するステップと、合致しない場合は、前記インストール・オペレーションを防止するステップとをさらに有する、請求項９に記載の方法。
【請求項１１】
必要なコンピューティング環境が動作目的および規則に合致するかどうかを判定する前記ステップが、リソース活動化料金を評価するステップと、コンピューティング環境が構築された場合に発生する合計料金を計算するステップと、前記合計料金と収益目標とを比較するステップとをさらに有する、請求項１０に記載の方法。
【請求項１２】
リソース活動化料金を評価する前記ステップが、ハードウェア・リソース、ハードウェア保守コスト、およびライセンス交付料金の活動化のための料金グループから選択されたリソース活動化料金を評価するステップを有する、請求項１１に記載の方法。
【請求項１３】
前記合計料金と前記収益目標との比較が所定の目標に合致しないとの判定に応答して、ジョブの売却プロセスを開始するステップをさらに有する、請求項１１に記載の方法。
【請求項１４】
前記グリッド・カタログから１つまたは複数のインデックスを受け取る前記ステップが、オペレーティング・システムおよび１つまたは複数のアプリケーション・プログラムを含むバンドル用に組み合わされたインストール・イメージの少なくとも１つのインデックスを受け取るステップを有する、請求項９に記載の方法。
【請求項１５】
ジョブ環境要件セットを受け取る前記ステップが、オペレーティング・システムの保守レベル要件パラメータを受け取るステップを有する、請求項９に記載の方法。
【請求項１６】
ジョブ環境要件セットを受け取る前記ステップが、オペレーティング・システムの更新レベル要件パラメータを受け取るステップを有する、請求項９に記載の方法。
【請求項１７】
請求項９に記載の方法の各ステップをコンピュータに実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、グリッド・ベースのコンピューティングの分野に関する。特に本発明は、グリッド・コンピューティング環境内でのリソースの管理および割り振りに関する。
【背景技術】
【０００２】
１９９０年代、様々なシステム間での通信の標準化がインターネットの急増を推進した。このリソース共有の概念に基づく最新の進化的な技術が、グリッド・コンピューティングである。
【０００３】
グリッド・コンピューティングは、システムおよびリソースの集まりを利用してサービス品質を送達する、新興技術である。これは、仮想自己管理型コンピュータを作成することによる、最良の状態での分散コンピューティングであり、そのための処理は、異なる組み合わせのリソースを共有する相互接続された異機種システムの集まりによって処理される。簡単に言えば、グリッド・コンピューティングとは、コンピュータをまとめて働かせること、ならびに、ビジネスすなわちグリッド参加者が使用可能なリソースを最適化できるようにすることに関する。
【０００４】
グリッド・コンピューティングに対する枠組みは、大規模なリソース共有であり、これは複数の管理ドメイン内に存在し、通常は、通信メディアを介してまとめて接続され、１つまたは複数の要求されたジョブを同時に実行するように編成された、高度並列処理されるアプリケーションを含む。各グリッド・リソースの特徴には、処理速度、記憶容量、ライセンス交付権限、および使用可能なアプリケーションのタイプが含まれるが、これらに限定されるものではない。
【０００５】
グリッド・コンピューティングのアーキテクチャは、基本仕様であるＯｐｅｎ  Ｇｒｉｄ  Ｓｅｒｖｉｃｅｓ  Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ（「ＯＧＳＩ」）を含むＯｐｅｎ  Ｇｒｉｄ  Ｓｅｒｖｉｃｅｓ  Ａｒｃｈｉｔｅｃｔｕｒｅ（「ＯＧＳＡ」）に定義されている。
【０００６】
すべてのサイズのコンピューティング・ジョブ、特に企業プロセスなどの大規模なジョブを処理するためにグリッド・コンピューティングを使用することには、いくつかの利点がある。第１に、グリッド上で十分利用されていないリソースを活用する。たとえば、金融サービス会社が、株式取引のトランザクションで３０分間に５０％の上昇に突然遭遇した場合、従来のシステム・プロセスを使用している会社は、ネットワーク・トラフィック、潜在的な応答、および完了時間の増加、処理におけるボトルネック、ならびに、その制限されたかまたは固定された計算および通信リソースによるリソース上での過負荷、に直面することになるであろう。
【０００７】
しかしながら同様の状況において、グリッド・コンピューティングは、変化するビジネス・ニーズに合わせて動的に調整し、未使用のリソースのネットワークを使用して株式トランザクションの増加に即時に応答することができる。たとえば、グリッド・コンピューティング・システムは、トランザクションを処理するために４台の十分利用されていないマシン上で既存の株式取引アプリケーションを実行し、従来のコンピューティング・アーキテクチャに比べて４倍の速さで結果を送達することができる。したがって、グリッド・コンピューティングは、リソース利用においてより良いバランスを提供し、大量の並列処理ＣＰＵ容量の潜在性を実行可能にする。
【０００８】
第２にグリッド・コンピューティングは、その標準により、様々なベンダおよびオペレータからの多くのリソースおよび組織間でのコラボレーションを実行可能化かつ簡略化する。たとえばゲノム研究の会社では、様々なコンピュータ・タイプ、オペレーティング・システム、およびプログラミング言語によってジョブを処理しながら、グリッド・コンピューティングを使用して、大量のデータの処理、浄化、クロス集計、および比較を行うことができる。ファイルまたはデータベースを多くのシステムに行き渡らせることにより、市場における競争でその会社を優位に立たせるような高速処理につながるストライピング技術を使用して、データ転送率を向上させることができる。
【０００９】
第３にグリッド・コンピューティングは、追加の機器、ソフトウェア、サービス、ライセンス、およびその他にまで延在する、共有機能を提供する。これらの仮想リソースは、異機種のグリッド参加者間に均一の相互運用性を提供する。各グリッド・リソースは、ある種の特徴、機能、および制限を有することができる。たとえば、特定のデータ・マイニング・ジョブは、ＤＢ２サーバ上では実行可能であるが、Ｏｒａｃｌｅサーバ上で処理するような互換性はない場合がある。したがってグリッド・コンピューティング・アーキテクチャは、特有の各ジョブを処理できるリソースを選択する。
【００１０】
インターナショナル・ビジネス・マシンズ（「ＩＢＭ」）は、グリッド・コンピューティング・システムの定義およびインプリメンテーションの先駆者である。ＩＢＭアーキテクチャによれば、サービス・レベル・アグリーメント（「ＳＬＡ」）は、グリッドによって処理される計算ジョブに関する受け入れ可能な実行パラメータを指示する、クライアント主導の基準セットを指定する契約である。ＳＬＡパラメータは、実行および応答時間、結果の正確さ、ジョブ・コスト、ならびにストレージおよびネットワーク要件などの、メトリクスから成るものとすることができる。通常、ジョブが完了すると、実際の完了と比較するために非同期プロセスが実行され、これは手動であることが多い。言い換えれば、会社はＳＬＡを使用して、発生した経費および取得した貸方勘定などのすべての会計細目が、仲介協定に合致していることを確認する。実行依頼側クライアントとグリッド・サービス・プロバイダとの間の関係は、買い手（クライアント）と売り手（グリッド・ベンダ）との間のそれである。
【００１１】
グリッドおよびオンデマンド・コンピューティングを成功させるためには、グリッド関係のプロセスを最大限に自動化する必要が生じる。グリッド・コンピューティングが比較的新しい新興の分野であるという事実から、多くのプロセスがまだ自動化の対象とみなされていないため、効率の悪い手動の対話が必要である。
【００１２】
ＩＢＭのグリッド・コンピューティング・アーキテクチャは、新しいジョブの受信に動的に応答して、グリッドまたはオンデマンド・コンピューティング・システムにおいてジョブを実行するのに必要な、特定のハードウェアおよびソフトウェア環境を割り振りおよび実行可能にするために、自動化された効率の良いメカニズムを提供する。しかしながら、場合によっては、グリッド内のジョブ負荷およびジョブ要件に応じて、新しく実行依頼されたジョブを処理するための適切なリソースが利用できない可能性がある。利用できないのは、ジョブを処理することが可能なハードウェアおよびソフトウェアがすでに他のジョブに割り振られているという事実、または、現在グリッド内にジョブを処理できる様式で構成されているハードウェアおよびソフトウェアがないという事実、あるいはその両方の理由から生じている可能性がある。
【発明の開示】
【発明が解決しようとする課題】
【００１３】
したがって当分野では、現在アクティブかつ使用可能なグリッド・ハードウェアが、インバウンド・グリッド・ジョブが必要とするソフトウェア環境を含んでいない場合、その必要なソフトウェア環境を自動化された様式で構築するためのメカニズムが求められている。
【課題を解決するための手段】
【００１４】
関連するソフトウェアは、基本オペレーティング・システム、特定のデバイス・ドライバ、アプリケーション・ソフトウェア、および他のコンポーネントを含むことができる。適切なソフトウェア環境の構築は、当分野での必要性に従って、新しいハードウェア上での新しいソフトウェア環境の完全な構築、必要な環境を完全にするために他の既存ノードと統合するためのノードの補足セットの構築、または、単なる既存のアクティブ・ノード上での必要なアプリケーションの構築を含むことができる。
【００１５】
本発明を使用することにより、コンピューティング・グリッドはより高度なリソース・ロード・バランシングを提供することができる。比較的アイドル状態のマシンは、予期せぬピーク・ジョブを受け取る可能性があるか、または、グリッドが完全に利用されている場合、要求されたジョブの数をより良く実行するために優先順位が割り当てられる可能性がある。ＩＢＭ  ＧＭＳなどのグリッド管理システム（「ＧＭＳ」）スケジューラと共に、本発明者等の動的アプリケーション環境ビルダ（「ＤＡＥＢ」）を使用することによって、コンピューティング・グリッドは、リソースを仲介するための優れたインフラストラクチャを提供することができる。
【００１６】
一般的に言えば、ジョブが実行のために本発明者等の計算グリッド内に流れ込むと、自動化された効率の良いメカニズムが、ジョブの実行に必要な特定のハードウェアおよびソフトウェア環境を割り振りおよび実行可能にする。加えて、現在のアクティブなグリッド・ハードウェアが、インバウンド・グリッド・ジョブが必要とするソフトウェア環境を含んでいない場合、本発明のプロセスは、その必要なソフトウェア環境を自動化された様式で構築する。その構築が必要とし、提供するソフトウェア・リソースは、基本オペレーティング・システム、１つまたは複数の特定のデバイス・ドライバ、１つまたは複数のアプリケーション・ソフトウェア・プログラム、および他のコンポーネントを含むことができる。
【００１７】
適切なソフトウェア環境の構築は、新しいハードウェア上での新しいソフトウェア環境の完全な構築、必要な環境を完全にするために他の既存ノードと統合するためのノードの補足セットの構築、または、単なる既存のアクティブ・ノード上での必要なアプリケーションの構築を含むことができる。
【００１８】
第１の態様から見ると、本発明は、グリッド・リソース・アロケータからジョブ環境要件セットを受け取るための入力であって、当該ジョブ環境要件はグリッド・コンピューティング環境内でジョブを実行するために必要な１つまたは複数のパラメータを示し、当該パラメータはオペレーティング・システム、アプリケーション・プログラム、およびソフトウェア・ドライバのグループから選択された、１つまたは複数の基準を含む、入力と、現在ジョブ・コンピューティング環境内に構成されていない１つまたは複数の必要なリソースが使用可能であるかどうかを判定するために、グリッド・カタログおよびストレージ・サブシステムにアクセスするためのカタログ・クエリア（ｑｕｅｒｉｅｒ）であって、当該カタログは、使用可能なオペレーティング・システム用のインストール・イメージ、アプリケーション・プログラム用のインストール・プログラム、およびソフトウェア・ドライバ用のインストール・プログラムの、１つまたは複数のインデックスを含む、カタログ・クエリアと、当該グリッド・コンピューティング環境内で好適な使用可能ハードウェア・プラットフォームを選択するように、当該カタログから１つまたは複数のインデックスを受け取るように、および、当該ジョブ環境要件に合致するコンピューティング環境を作成するために、当該ハードウェア・プラットフォーム上で１つまたは複数のソフトウェア・インストール・オペレーションを実行するように、構成された環境ビルダと、を有する、グリッド・コンピューティング環境内でコンピューティング環境を動的に構築するための論理デバイスを提供する。
【００１９】
好ましくは、本発明は、必要なコンピューティング環境がある動作目的および規則に合致するかどうかを判定し、合致しない場合は、当該環境ビルダが当該コンピューティング環境を構築しないように構成された、構築ケース・エバリュエータをさらに有する、論理デバイスを提供する。
【００２０】
好ましくは、本発明は、当該エバリュエータが、リソース活動化料金を評価するように、コンピューティング環境が構築された場合に発生する合計料金を計算するように、および、当該合計料金と収益目標とを比較するように構成される、論理デバイスを提供する。
【００２１】
好ましくは、本発明は、当該エバリュエータが、ハードウェア・リソース、ハードウェア保守コスト、およびライセンス交付料金の活動化のための、料金グループから選択されたリソース活動化料金を評価するように構成される、論理デバイスを提供する。
【００２２】
好ましくは、本発明は、さらに当該エバリュエータが、当該合計料金と当該収益目標との比較が所定の目標に合致しないとの判定に応答して、ジョブの売却プロセスを開始するように構成される、論理デバイスを提供する。
【００２３】
好ましくは、本発明は、さらに当該カタログが、オペレーティング・システムおよび１つまたは複数のアプリケーション・プログラムを含むバンドル用に組み合わされたインストール・イメージを有する、論理デバイスを提供する。
【００２４】
好ましくは、本発明は、さらに当該パラメータがオペレーティング・システム用の保守レベル要件を有する、論理デバイスを提供する。
【００２５】
好ましくは、本発明は、さらに当該パラメータがオペレーティング・システム用の更新レベル要件を有する、論理デバイスを備える。
【００２６】
第２の態様から見ると、本発明は、グリッド・リソース・アロケータからジョブ環境要件セットを受け取るステップであって、当該ジョブ環境要件はグリッド・コンピューティング環境内でジョブを実行するために必要な１つまたは複数のパラメータを示し、当該パラメータはオペレーティング・システム、アプリケーション・プログラム、およびソフトウェア・ドライバのグループから選択された、１つまたは複数の基準を含む、受け取るステップと、現在ジョブ・コンピューティング環境内に構成されていない１つまたは複数の必要なリソースが使用可能であるかどうかを判定するために、グリッド・カタログおよびストレージ・サブシステムにアクセスするステップであって、当該カタログは、オペレーティング・システム用の使用可能なインストール・イメージ、アプリケーション・プログラム用のインストール・プログラム、およびソフトウェア・ドライバ用のインストール・プログラムの、１つまたは複数のインデックスを含む、アクセスするステップと、当該グリッド・コンピューティング環境内で好適な使用可能ハードウェア・プラットフォームを選択するステップと、当該カタログから１つまたは複数のインデックスを受け取るステップと、当該ジョブ環境要件に合致するコンピューティング環境を作成するために、当該選択されたハードウェア・プラットフォーム上で１つまたは複数のソフトウェア・インストール・オペレーションを実行するステップと、を有する、グリッド・コンピューティング環境内でコンピューティング環境を動的に構築するための方法を提供する。
【００２７】
好ましくは、本発明は、必要なコンピューティング環境がある動作目的および規則に合致するかどうかを判定するステップと、合致しない場合は、当該インストール・オペレーションを防止するステップとをさらに有する、方法を提供する。
【００２８】
好ましくは、本発明は、必要なコンピューティング環境が動作目的および規則に合致するかどうかを判定する当該ステップが、リソース活動化料金を評価するステップと、コンピューティング環境が構築された場合に発生する合計料金を計算するステップと、当該合計料金と収益目標とを比較するステップとをさらに有する、方法を提供する。
【００２９】
好ましくは、本発明は、リソース活動化料金を評価する当該ステップが、ハードウェア・リソース、ハードウェア保守コスト、およびライセンス交付料金の活動化のための料金グループから選択されたリソース活動化料金を評価するステップを有する、方法を提供する。
【００３０】
好ましくは、本発明は、当該合計料金と当該収益目標との比較が所定の目標に合致しないとの判定に応答して、ジョブの売却プロセスを開始するステップをさらに有する、方法を提供する。
【００３１】
好ましくは、本発明は、当該グリッド・カタログから１つまたは複数のインデックスを受け取る当該ステップが、オペレーティング・システムおよび１つまたは複数のアプリケーション・プログラムを含むバンドル用に組み合わされたインストール・イメージの少なくとも１つのインデックスを受け取るステップを有する、方法を提供する。
【００３２】
好ましくは、本発明は、ジョブ環境要件セットを受け取る当該ステップが、オペレーティング・システムの保守レベル要件パラメータを受け取るステップを有する、方法を提供する。
【００３３】
好ましくは、本発明は、ジョブ環境要件セットを受け取る当該ステップが、オペレーティング・システムの更新レベル要件パラメータを受け取るステップを有する、方法を提供する。
【００３４】
第３の態様から見ると、本発明は、デジタル・コンピュータの内部メモリにロード可能なコンピュータ・プログラム製品を提供するものであって、当該製品がコンピュータ上で実行される場合、前述のように本発明を実施するための実行用のソフトウェア・コード部分を有する。
【００３５】
次に、本発明の諸実施形態について、単なる例として添付の図面を参照しながら詳細に説明する。
【発明を実施するための最良の形態】
【００３６】
本発明は、好ましくはグリッド・コンピューティング・アーキテクチャと共に実現される。したがって、本発明の細部の提示に先立ち、第１にいくつかの定義を確立し、グリッド・コンピューティング概念のいくつかの一般論について考察することが有用であろう。
【００３７】
グリッド・コンピューティングの基本
以下の定義が、本開示全体にわたって採用される。
ａ）「グリッド」とは、ごくわずかなマシンから、潜在的に全世界に広がる階層として編成されたマシン・グループにいたる、サーバ、プロセッサ、ストレージ・システム、および通信メディアなどの、コンピューティング・リソースの集まりを意味するものとする。
ｂ）「ジョブ」とは、使用可能かつ選択されたリソースを使用して処理されることになる、クライアントが開始する所望な要求されたタスクを意味するものとする。
ｃ）「リソース」とは、アプリケーション・プログラム、ハードウェア、ソフトウェア・ライセンス、ストレージ、および関連コンポーネントなどの、ジョブを完了させる際に使用するグリッド内で使用可能な任意のシステム、ハードウェア、またはソフトウェア・モジュールを意味するものとする。
ｄ）コンピューティング環境、または略して「環境」とは、ジョブを処理または実行するために使用される、プロセス、メモリ、ディスク・スペース、オペレーティング・システム、および１つまたは複数のアプリケーション・プログラムなどの、ハードウェアおよびソフトウェア・リソースのセットを意味するものとする。
ｅ）「ＳＬＡ」とは、具体的にはＩＢＭサービス・レベル・アグリーメントを指すものとし、一般的には、処理の正確さ、結果のフォーマット、完了までの処理時間、およびジョブ処理のコストを含むが、これらに限定されることのない、グリッド上でのジョブ処理に関するクライアント主導基準の任意の文書化されたセットを指すものとする。
【００３８】
前述のように、ＩＢＭは、オープン・グリッド・コンピューティング向けのシステム、アーキテクチャ、インターフェース、および標準の開発の先駆者である。グリッド・コンピューティングは、コンピューティング分野において比較的新しいものであるため、ここではまず、グリッド・コンピューティングの概念および論理プロセスの概要について説明する。一般的なグリッド・コンピューティングに関する追加情報は、ＩＢＭ、いくつかの他のグリッド・コンピューティング供給業者および開発者、増え続ける大学、ならびに、オープン・グリッド・コンピューティング環境（「ＯＧＣＥ」）協会などの適切な標準団体から、公的に入手可能である。以下のグリッド・コンピューティングについての説明では、ＩＢＭベースのグリッド環境においてのみならず、他のベンダからのシステムおよびコンポーネントからなるグリッド・環境においても同様に、本発明を等しく良好にインプリメントする際に使用可能な、汎用モデルおよび一般的な用語を使用する。
【００３９】
図５を見ると、グリッド・コンピューティング（５０）の新しいコンピューティング・パラダイムが高い水準で示されている。クライアント・コンピュータを使用するＦＢＩアナリストなどのクライアント（５３）は、計算ジョブまたはタスク、予想されるテロリストの異機関間リストをグリッドによって実行するように要求する。このジョブは、通信ネットワーク（５１）を介してグリッド管理システム（「ＧＭＳ」）に実行依頼され、ここで、クライアント・ジョブ基準（たとえば、応答時間、コスト、正確さなど）ならびに、サーバ機能、リソース可用性、ストレージ機能、およびコストなどの、リソース特徴に基づいて、どのグリッド・ベンダ（５４）を使用するかを選択する。
【００４０】
ＧＭＳが、ジョブの割り当て先となる（またはジョブが分割されることになる）特定のベンダ（３８、３９、３００）を決定すると、サーバ１（３８）などの選択されたグリッド・リソースに要求が送信される。次にサーバ１（３８）は、必要に応じてこのジョブを処理し、そのジョブ結果を通信ネットワーク（５１）を介して要求側クライアント（５３）に戻す。
【００４１】
図３は、より低いレベルでグリッド・コンピューティングがどのように機能するかをより詳細に示す図（３０）である。ジョブ（３２）がクライアント・アプリケーション（３１）によってグリッドに実行依頼された場合、そのジョブ（３２）はグリッド・インバウンド・ジョブ・キュー（３３）内に受け取られ、ここで１つまたは複数のグリッド・リソースへの割り当てを待つ。
【００４２】
ジョブ／グリッド・スケジューラ（「ＪＧＳ」）（３４）は、インバウンド・ジョブ・キュー（３３）からそれぞれの保留ジョブを取り出し、ジョブに関する処理要件を決定するために１つまたは複数のＳＬＡ（３０５）に照らして処理要件を検証し、その後、ジョブ（３２）の処理をどのサーバ（２８、２９、３００）に割り当てるかを選択する。この図では、サーバ２（３９）が選択されているため、ジョブ（３２）は、サーバが使用可能になった時点で（適切な処理帯域幅がすでに使用可能な場合は即時）処理されるように、サーバ２のジョブ・キュー（３６）に転送される。いくつかのサーバがそれらのジョブ・キューをインテリジェント様式で処理可能であり、これによってジョブは、以前に受け取られた優先順位の低いジョブよりも早く先に処理できるようにする優先順位指定を有することができる。
【００４３】
最終的に、割り当てられたサーバはジョブを完了し、その結果（３０１）をジョブ結果マネージャ（「ＪＲＭ」）（３０２）に戻す。ＪＲＭはジョブの完了およびクライアント・アプリケーション（３１）への結果の送達を検証し（３０３）、必要に応じて請求および送り状機能を達成するためにジョブ完了記録を生成する（３０４）ことができる。
【００４４】
次に、図４を参照すると、リソース選択プロセス（４０）の詳細が示されている。各グリッド・リソース（３８、３９、３００）は、その可用性または「アイドルのパーセント」（４１、４２、および４３）をジョブ／グリッド・スケジューラ（３４）にリアルタイムで報告することができる。加えて、グリッド・リソースの特徴および機能のセット（４４）が静的に、動的に、またはその両方でコンパイルされ、これはＪＧＳ（３４）も使用可能である。いくつかのサーバ特徴は、ハードウェア特徴（たとえば、インストール済みメモリ、通信プロトコル、またはライセンス）などのように静的な場合があり、他の特徴は、あるアプリケーション・プログラムに使用可能なライセンスの数（たとえば、ＰＤＦ生成プログラム、ビデオ圧縮プログラム）などのように、事実上、より動的な場合がある。加えて、好ましくは、ＪＧＳ（３４）はジョブ結果マネージャ（３０２）からの完了統計（４５）も使用可能である。
【００４５】
グリッド・リソースに関するこれらの要因を考慮することにより、またＳＬＡクライアント要件と組み合わせることにより、ＪＧＳは各ジョブを割り当てる１つまたは複数の適切なグリッド・リソースを選択することができる。たとえば、即時処理が必要な優先順位の高いジョブの場合、ＪＧＳは、即時使用可能であり最大のメモリおよび処理帯域幅を提供するリソースを選択することができる。コストに依存するが急を要するものではない他のジョブの場合、ＪＧＳは、そのリソースで処理するためのキューの現在の深さはそれほど考慮せず、最も安価なリソースを選択することができる。
【００４６】
本発明を実現するために好適なコンピューティング・プラットフォーム
本発明は、使用可能な一実施形態において、パーソナル・コンピュータ、ウェブ・サーバ、およびウェブ・ブラウザなどの良く知られたコンピューティング・プラットフォームによって実行するための、ＩＢＭのグリッド・コンピューティング製品などのソフトウェア製品の一機能または追加として実現される。
【００４７】
携帯情報端末（「ＰＤＡ」）、ウェブ対応無線電話、および他のタイプの個人情報管理（「ＰＩＭ」）デバイスなどの、ポータブルおよびハンドヘルド・デバイスでさえ、そのコンピューティング能力、メモリおよびストレージ、ならびに通信機能が時と共に着実に向上しているため、これらデバイスの一部に向けたソフトウェアでも本発明を実現することが可能である。
【００４８】
したがって、ハイエンド・ウェブまたは企業サーバ・プラットフォームから、パーソナル・コンピュータ、ポータブルＰＤＡ、またはウェブ対応無線電話にまでわたる、コンピューティング・プラットフォームの汎用アーキテクチャについて再検討することが有用である。
【００４９】
次に図６を見ると、通常は、ランダム・アクセス・メモリ（「ＲＡＭ」）（７４）および読み取り専用メモリ（「ＲＯＭ」）（７５）に関連付けられたマイクロプロセッサ（７２）からなる、中央処理ユニット（７１）（「ＣＰＵ」）を含む、汎用アーキテクチャが提示されている。ＣＰＵ（７１）は、しばしばキャッシュ・メモリ（７３）およびプログラム可能フラッシュＲＯＭ（７６）も備える。マイクロプロセッサ（７２）と様々なタイプのＣＰＵメモリとの間のインターフェース（７７）は、しばしば「ローカル・バス」と呼ばれるが、より汎用的または業界標準のバスとすることもできる。
【００５０】
多くのコンピューティング・プラットフォームは、ハード・ディスク・ドライブ（「ＨＤＤ」）、フロッピィ・ディスク・ドライブ、コンパクト・ディスク・ドライブ（ＣＤ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ、ＤＶＤ−Ｒなど）、ならびに専有ディスクおよびテープ・ドライブ（たとえば、Ｉｏｍｅｇａ  Ｚｉｐ（商標）およびＪａｚ（商標）、Ａｄｄｏｎｉｃｓ  ＳｕｐｅｒＤｉｓｋ（商標）など）などの、１つまたは複数のストレージ・ドライブ（７９）も備える。加えて、コンピュータ・ネットワークを介していくつかのストレージ・ドライブにもアクセス可能である。
【００５１】
多くのコンピューティング・プラットフォームは、コンピューティング・プラットフォームの所期の機能により、１つまたは複数の通信インターフェース（７１０）を備える。たとえばパーソナル・コンピュータは、しばしば高速シリアル・ポート（ＲＳ−２３２、ＲＳ−４２２など）、拡張パラレル・ポート（「ＥＰＰ」）、および１つまたは複数のユニバーサル・シリアル・バス（「ＵＳＢ」）ポートを備える。コンピューティング・プラットフォームは、イーサネット・カードなどのローカル・エリア・ネットワーク（「ＬＡＮ」）インターフェース、および高性能シリアル・バスＩＥＥＥ−１３９４などの他の高速インターフェースも備えることができる。
【００５２】
無線電話および無線ネットワーク化ＰＤＡなどのコンピューティング・プラットフォームは、アンテナとの無線周波数（「ＲＦ」）インターフェースも備えることができる。場合によっては、コンピューティング・プラットフォームはＩｎｆｒａｒｅｄ  Ｄａｔａ  Ａｒｒａｎｇｅｍｅｎｔ（「ＩｒＤＡ」）インターフェースも備えることができる。
【００５３】
コンピューティング・プラットフォームには、しばしば、サウンド・カード、メモリ・ボード、およびグラフィックス・アクセラレータなどの他のハードウェアを追加するための、業界標準アーキテクチャ（「ＩＳＡ」）、拡張業界標準アーキテクチャ（「ＥＩＳＡ」）、Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ（「ＰＣＩ」）、または専有インターフェース・スロットなどの、１つまたは複数の内部拡張スロット（７１１）が装備される。
【００５４】
加えて、ラップトップ・コンピュータおよびＰＤＡなどの多くのユニットは、ＰＣＭＣＩＡカード、ＳｍａｒｔＭｅｄｉａカード、ならびに、取り外し可能ハード・ドライブ、ＣＤドライブ、およびフロッピィ・ドライブなどの様々な専有モジュールなどの、ハードウェア拡張デバイスを、ユーザが容易にインストールおよび除去できるようにするために、１つまたは複数の外部拡張スロット（７１２）を備える。
【００５５】
ストレージ・ドライブ（７９）、通信インターフェース（７１０）、内部拡張スロット（７１１）、および外部拡張スロット（７１２）は、しばしば、ＩＳＡ、ＥＩＳＡ、またはＰＣＩなどの標準または業界のオープン・バス・アーキテクチャ（７８）を介して、ＣＰＵ（７１）と相互接続される。多くの場合、バス（７８）は専有設計である可能性がある。
【００５６】
コンピューティング・プラットフォームは、通常、キーボードまたはキーパッド（７１６）、およびマウスまたはポインタ・デバイス（７１７）、あるいはタッチスクリーン・ディスプレイ（７１８）、またはそれらすべてなどの、１つまたは複数のユーザ入力デバイスを備える。パーソナル・コンピュータの場合、しばしば、マウス、あるいはトラック・ボールまたはＴｒａｃｋＰｏｉｎｔ（商標）などのポインタ・デバイスと共にフルサイズのキーボードを備える。ウェブ対応無線電話の場合、１つまたは複数の特定機能キーを備えた単純なキーパッドを備える。ＰＤＡの場合、通常は、しばしば手書き文字認識機能を備えたタッチ・スクリーン（７１８）を備える。
【００５７】
加えて、コンピューティング・プラットフォームは、ウェブ対応無線電話のマイクロフォンまたはパーソナル・コンピュータのマイクロフォンなどの、マイクロフォン（７１９）も備える。このマイクロフォンは、単にオーディオおよび音声信号をレポートするために使用することが可能であり、また、音声認識機能を使用してウェブ・サイトの音声ナビゲーションまたは自動ダイヤルの電話番号などのユーザの選択を入力するためにも使用可能である。
【００５８】
多くのコンピューティング・プラットフォームは、スチル・デジタル・カメラまたはフル・モーション・ビデオ・デジタル・カメラなどの、カメラ・デバイス（７００）も備える。
【００５９】
ほとんどのコンピューティング・プラットフォームは、ディスプレイ（７１３）などの１つまたは複数のユーザ出力デバイスも備える。ディスプレイ（７１３）は、陰極線管（「ＣＲＴ」）、薄膜トランジスタ（「ＴＦＴ」）アレイ、あるいは発光ダイオード（「ＬＥＤ」）または液晶ディスプレイ（「ＬＣＤ」）インジケータの単純なセットを含む、多くの形を取ることができる。
【００６０】
コンピューティング・プラットフォームには、しばしば１つまたは複数のスピーカ（７１４）あるいは報知器（ａｎｎｕｎｃｉａｔｏｒ）（７１５）またはその両方も関連付けられる。無線電話のスピーカまたはパーソナル・コンピュータのスピーカなどのスピーカ（７１４）を使用して、オーディオおよび音楽を再生することができる。報知器（７１５）は、ＰＤＡおよびＰＩＭなどのある種のデバイスで一般的に見られる、単純なビープ音発生器またはブザーの形を取ることができる。
【００６１】
これらのユーザ入力および出力デバイスは、専有バス構造あるいはインターフェースまたはその両方を介して、ＣＰＵ（７１）と直接相互接続する（７８’、７８”）ことができるか、あるいは、ＩＳＡ、ＥＩＳＡ、ＰＣＩなどの１つまたは複数の業界のオープン・バスを介して相互接続することができる。コンピューティング・プラットフォームは、コンピューティング・プラットフォームの所望の機能をインプリメントするための１つまたは複数のソフトウェアおよびファームウェア（７０１）プログラムも備える。
【００６２】
次に図７を見ると、この範囲のコンピューティング・プラットフォーム上のソフトウェアおよびファームウェア（７０１）の汎用編成の詳細が示されている。コンピューティング・プラットフォーム上に、ワード・プロセッサ、スプレッドシート、連絡先管理ユーティリティ、アドレス・ブック、カレンダ、電子メール・クライアント、プレゼンテーション、金融、および簿記プログラムなどの、１つまたは複数のオペレーティング・システム（「ＯＳ」）固有のアプリケーション・プログラム（８２３）を備えることができる。
【００６３】
加えて、Ｊａｖａ（商標）スクリプトおよびプログラムなどの、ＯＳ固有のプラットフォーム特有インタープリタ（８２５）によって解釈しなければならない、１つまたは複数の「ポータブル」またはデバイス独立プログラム（８２４）を備えることができる。
【００６４】
コンピューティング・プラットフォームは、ブラウザ・プラグイン（８２７）などのブラウザへの１つまたは複数の拡張も含むことが可能な、ウェブ・ブラウザまたはマイクロ・ブラウザ（８２６）の形も備える。
【００６５】
コンピューティング・デバイスは、しばしば、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（商標）、ＵＮＩＸ、ＩＢＭ  ＯＳ／２（商標）、ＬＩＮＵＸ、ＭＡＣ  ＯＳ（商標）、または他のプラットフォーム特有のオペレーティング・システムなどの、オペレーティング・システム（８２０）を備える。ＰＤＡおよび無線電話などの小型のデバイスは、リアルタイム・オペレーティング・システム（「ＲＴＯＳ」）またはパーム・コンピューティングのＰａｌｍＯＳ（商標）などの、他の形のオペレーティング・システムを装備することができる。
【００６６】
オペレーティング・システム（８２０）およびプログラムが、コンピューティング・プラットフォームを備えた特有のハードウェア機能とのインターフェースおよび制御を実行できるようにするために、基本入力および出力機能（「ＢＩＯＳ」）およびハードウェア・デバイス・ドライバのセット（８２１）がしばしば備えられる。
【００６７】
加えて、多くのコンピューティング・プラットフォームは、一般に、マイクロ・コントローラまたはハード・ドライブ、通信プロセッサ、ネットワーク・インターフェース・カード、あるいはサウンドまたはグラフィック・カードなどの、周辺デバイスの一部としてのオンボードまたは「組み込み」マイクロプロセッサによって実行される、１つまたは複数の組み込みファームウェア・プログラム（８２２）も備える。
【００６８】
したがって、図６および図７は、パーソナル・コンピュータ、ＰＤＡ、ＰＩＭ、ウェブ対応電話、およびＷｅｂＴＶ（商標）ユニットなどの他のアプライアンスを含むがこれらに限定されない、多種多彩なコンピューティング・プラットフォームの様々なハードウェア・コンポーネント、ソフトウェアおよびファームウェア・プログラムを、一般的な意味で記載している。当業者であれば、本明細書に記載された方法およびプロセスが、本発明の趣旨および範囲から逸脱することなく、部分的または全体的にハードウェア機能として別の方法で実現可能であることを、容易に理解できるであろう。
【００６９】
ＩＢＭ（商標）およびＴｉｖｏｌｉ（商標）からの他のグリッド製品
本発明が関係するが、それに比べて本発明がかなりの性能および機能上の利点を提供する、以前から使用可能な製品が２つある。
【００７０】
１．アプリケーション環境との間でのリソースの静的な構築、配置、構成、および再利用（ｒｅｃｌａｉｍｉｎｇ）を管理する、ＴｉｖｏｌｉのＴｈｉｎｋ  Ｄｙｎａｍｉｃ（別名は、ＩＢＭ  Ｔｉｖｏｌｉ  Ｐｒｏｖｉｓｉｏｎｉｎｇ  ＭａｎａｇｅｒおよびＩＢＭ  Ｔｉｖｏｌｉ  Ｉｎｔｅｌｌｉｇｅｎｔ  Ｏｒｃｈｅｓｔｒａｔｏｒ）Ｐｒｏｖｉｓｉｏｎｉｎｇ  Ｍａｎａｇｅｒ。これは、ｎ層のアプリケーション環境を配置および増補するために「ベスト・プラクティス」を自動化するワークフローの構築を可能にし、ネットワーク、サーバ、ストレージ、ミドルウェア、およびアプリケーション・サービスに、すぐに使用可能な自動化されたプロビジョニングを提供するものである。
【００７１】
２．ＷｅｂＳｐｈｅｒｅ（商標）リソース（たとえば、ソフトウェア・コンポーネントおよびリソース）のプールを可能にし、企業の動的ニーズにアプリケーションを即時に対応させる、ＩＢＭ  Ｗｅｂｓｐｈｅｒｅ（商標）Ｓｅｒｖｅｒ  Ａｌｌｏｃａｔｉｏｎ  Ｗｏｒｋｌｏａｄ  Ｍａｎａｇｅｒ。このオファリングは、ＷｅｂＳｐｈｅｒｅソフトウェア環境に関してそれらのリソースの使用率を上げるために、作業負荷を平均化し、リソースを割り振るように設計された。しかしながら、この手法は静的割り振りメカニズムを採用した。
【００７２】
その中核となる概念には、本発明との何らかの類似性があるが、これらの他のＩＢＭおよびＴｉｖｏｌｉ製品は、動的環境の構築／ジョブの委譲、およびジョブの拒否の基準に関してリモート割り振りマネージャおよび外部グリッド・システムと共同する、協定価格選択に基づくリソース割り振りにおける拡張アルゴリズム面に基づいた本方法とは異なる。本発明者等の新しいＤＡＥＢアルゴリズム手法および他のシステム・コンポーネントとの共同は、前述の製品のそれよりも高度である。
【００７３】
本発明に関して、いくつかの諸実施形態では、ジョブ要件およびリソース使用率基準に基づくきめの細かいリソース割り振りのために、これらまたは他の同様の製品を利用することが可能である。
【００７４】
動的アプリケーション環境ビルダ
グリッド動的構築サブシステムを効率良く機能させるために、本発明者等のＤＡＥＢサブシステムは、グリッド内の、好ましくはインターナショナル・ビジネス・マシンズ（「ＩＢＭ」）によって定義および提供されるコンピューティング・グリッド・アーキテクチャ内の、他の論理モジュールと通信する。図１は、本発明者等のグリッド内関係（１０）を示す図であり、これについては、以下のパラグラフで詳細に論じる。
ａ）グリッド割り振りまたは管理システム（１１）
ｂ）グリッド・マネージャ（１３）
ｃ）グリッド・カタログおよびストレージ・サブシステム（１５）
ｄ）グリッド仮想ノード・グルーパ（１４）
ｅ）本発明の主題である、本発明者等の新しいグリッド動的環境ビルダ（１２）
【００７５】
当業者であれば、この高水準機能編成が、本発明が採用可能な唯一の実施形態でないことを理解されよう。別の方法として、本発明は他のオンデマンド・コンピューティング・アーキテクチャおよびグリッド・アーキテクチャで採用可能である。
【００７６】
前述のように、ＩＢＭグリッド製品は、着信するグリッド・ジョブに応答して方法およびシステムを提供し、それらによって当該ジョブを実行するために必要なリソースが識別され、自動化様式でインバウンド・ジョブに提供される。グリッド・コンピューティングが成長を続け、増加の一途をたどるオンデマンド・サービスに関するクライアントのニーズに合わせようとするならば、この種のプロセス自動化は不可欠である。
【００７７】
さらに対処しなければならない関連問題は、インバウンド・グリッド・ジョブが必要とするソフトウェア環境が現在使用できない場合、グリッド・ベンダがその状況をいかに管理するか、ということである。必要な環境は、グリッド・サービス・プロバイダにとって既知の、提供済みの環境であるが、現在はグリッド環境内のいずれにも存在していないか、または他のジョブが使用中の環境であるが、割り振り超過であり、いかなる新しいジョブも使用できないものである可能性がある。
【００７８】
本発明は、必要なソフトウェア環境を動的に構築することができるため、割り振りサブシステムが必要なリソースをインバウンド・ジョブに提供することが可能な、自動化グリッド・サブシステムを提供することによって、この問題に対処する。当分野の機能は、オプションで既存のグリッド・スケジューリング／管理サブシステムに組み込まれるが、好ましい実施形態によれば、グリッド管理およびリソース割り振りサブシステムと通信する別の論理モジュールとして実現される。
【００７９】
本発明者等の動的アプリケーション環境構築サブシステムの一目的は、インバウンド・グリッド・ジョブ要件が現在アクティブなグリッド環境の機能を上回る場合、以下のサービスを実行することである。
１．環境の構築が必要な場合、リソース割り振りサブシステムからデータを受け入れる。
２．必要なソフトウェア・リソースの可用性を判定するために、グリッド・カタログおよびストレージ・サブシステムを照会する。
３．リソースの可用性を割り振りサブシステムに送る。
４．グリッド・マネージャおよび割り振りサブシステムを使用して、提案されたジョブに関する環境構築の望ましさを評価する。
５．ジョブの拒否を決定するか、あるいは、関連する環境の構築を決定する。
６．必要であれば、必要なＯＳをグリッド・カタログおよびストレージ・サブシステムに要求する。
７．必要であれば、必要なＯＳをノード上にネットワーク・インストールする。
８．必要であれば、必要なアプリケーションをグリッド・カタログおよびストレージ・サブシステムに要求する。
９．必要であれば、必要なアプリケーションをノード上にネットワーク・インストールする。
１０．構築が完了した旨をグリッド割り振りサブシステムに通知する。
【００８０】
現在アクティブなリソースがインバウンド・グリッド・ジョブのニーズに十分合致しない場合、本発明を使用してジョブ要件を満たすために新しいグリッド・リソースを動的に構築することができる。本発明の好ましい実施形態は、ＩＢＭの仮想ＲＦＰサブシステムと協働することになり、これによって、完全に自動化されたグリッド管理システムを提供するために、グリッド内サブシステム通信を使用してそれぞれのジョブ処理サブシステムに必要なデータが提供される。
【００８１】
図２を見ると、グリッド・コンピューティング・アーキテクチャ内にコンピューティング環境を動的に構築するための、本発明者等の論理プロセス（２０）が示されている。第１に、環境要件データ（２１）がリソース割り振りサブシステムから受け取られる（２２）。
【００８２】
グリッド・コンピューティング環境内のリソース割り振りサブシステムは、グリッド・スケジューラを介したインバウンド・グリッド・ジョブのためのローカル・グリッド・リソースの識別、割り振り、および準備の責務を負う。現在アクティブなグリッド・リソースが１つまたは複数のインバウンド・グリッド・ジョブの要件に十分合致しない場合、割り振りサブシステムは動的構築サブシステムに警告し、現在のリソース可用性に関して、ジョブ実行のための追加の必要なリソースを含む、割り振りサブシステム内で機能の一部としてすでに集められている関連データを渡す。
【００８３】
状況によっては、いくつかのインバウンド・グリッド・ジョブに関して現在アクティブな好適な環境がなく、環境全体をオンデマンドで構築しなければならない可能性があるが、他のケースでは、必要な環境の大部分が整っており、動的構築サブシステムは必要な環境を完了するために十分な追加リソースを作成することになる。
【００８４】
この時点で、グリッド・リソース割り振りサブシステムは、現在実行中のグリッド環境内でどの必要なリソースが現在使用可能であるかをすでに決定している。全ジョブ要件および何が現在使用可能であるかに基づいて、環境の構築を完了するためにどの追加リソースが必要であるかが推定される。グリッド・アロケータも、非アクティブなローカル・ハードウェア・リソースを、または仮想ノードのグループ化によって非アクティブなリモート・ハードウェア・リソースを追加することにより、残りのハードウェア要件に合致できるか否かをすでに決定している。
【００８５】
次に、グリッド動的構築プロセスは、必要なソフトウェア・プラットフォームを備えたハードウェア・リソースをアクティブ化するために必要なソフトウェア・リソースが使用可能であるか否かを判定するために、グリッド・カタログおよびストレージ・サブシステム（１５）に照会する（２３）。
【００８６】
アクティブなハードウェア・リソースが、ローカルに、またはノードのグループ化によってリモートに使用可能であった場合、割り振りサブシステムは単にそれらのリソースを環境に追加するだけでよく、ソフトウェアの構築がそれらリソースのうちのいずれかで必要であれば、動的構築モジュールに接触するだけでよいことに留意されたい。
【００８７】
アクティブまたは非アクティブなリソースが、ノードのグループ化によってリモート・グリッドから取得された場合、ローカル・グリッドの動的構築モジュールはリモート・リソースの構築を制御できるか、または、当該リソースのアクティブ化を開始するため、ならびに、ジョブ要件に合致させるために必要なオペレーティング・システムおよびアプリケーションをこれらのリソース上にインストールするために、リモート・グリッド動的構築サブシステムに構築を要求することができる。
【００８８】
他のグリッド・ベンダへのジョブの売却を含むすべての可能な手段（ａｖｅｎｕｅ）を介して、必要な環境を構築するためにリソースが使用できない場合、そのジョブは拒否され（２７）、ジョブが実行不可能である旨がクライアントに通知される。他方で、新しい環境を構築するためにリソースが使用可能であると判定された場合、その環境の構築が望ましいと決定される（２５）。
【００８９】
必要な環境を構築するためにリソースが使用可能であると判定されると、次のステップで、当面、そのジョブにとって必要な環境を構築することに経済的意味があるか否かが判定される（２６）。非アクティブなリソースを使用することにはコストがかかり、様々なハードウェア・リソースのアクティブ化のための料金、アクティブ化されたハードウェアのためのハードウェア保守コスト、オペレーティング・システムおよびアプリケーションのためのライセンス交付料金などが含まれる可能性がある。一例として、所与のジョブを実行するためにグリッド・ベンダによって得られる利益が＄１，０００であると推定され、必要な環境を構築するための推定コストが＄１，１００である場合、このジョブは拒否するように決定される確率が高い。このように決定された場合、コストおよび収益あるいは他の関連基準、またはそれらすべてを計算することによって、ジョブを実行するための環境を構築することが望ましくないと決定された場合、インバウンド・ジョブは拒否され（２７）、グリッド・アロケータに通知されることになる。
【００９０】
他方で、このジョブを受け入れる旨の業務上の理由が存在すると判定された場合、動的構築モジュールは必要な環境の構築を開始するように進行する。ハードウェアのアクティブ化が必要な場合、第１のステップは必要なハードウェア・リソースをアクティブ化することである。このアクティブ化を実施するために必要な実際の手順はプラットフォームによって異なるが、以下のようにいくつかの考慮すべき点が挙げられる。
ａ）非アクティブ・ハードウェアの動的な電源投入またはＩＰＬ
ｂ）新しいハードウェア区画の動的な作成
ｃ）動的なアクティブ化
【００９１】
当分野では、非アクティブなハードウェア・リソースをアクティブ化することが可能な、様々なツール、アプリケーション、およびコマンドが良く知られている。動的構築モジュールが、ハードウェアのアクティブ化、および必要なコンポーネント向けに必要なソフトウェアのインストールにのみ関与することにも留意されたい。これらのタスクが完了すると、必要なリソースがアクティブかつ使用可能になったこと、ならびに、前述のようなカスタマイズおよび環境への組み込みに関与するものと想定されることが、割り振りサブシステムに通知される（２４）。
【００９２】
グリッド・カタログおよびストレージ・サブシステム（１５）は、包括的なソフトウェア・リポジトリであり、このリポジトリ内のすべてのソフトウェアは、仮想ＲＦＰプロセス時に使用される標準指定を介してカタログ化およびインデックス付けされる。この時点で動的構築プロセスは、所望のオペレーティング・システム（「ＯＳ」）イメージを、カタログおよびストレージ・サブシステム（１５）に要求する（２８）。一例として、保守レベル１のＩＢＭのＡＴＸ（商標）第５．１版のインストール可能イメージを、オペレーティング・システムＡ１７−１として指定することができる。この識別子に基づいて、カタログおよびストレージ・サブシステムは、必要なＯＳイメージの正確な位置を示す動的構築サブシステムへのポインタを提供する。
【００９３】
必要なインストールＯＳイメージの位置を動的構築プロセス（２０）が認識すると、動的構築プロセスは、必要なノード上へのオペレーティング・システムのインストールを開始する（２８）。しかしながら、ソフトウェア・リソースの自動化インストールに関しては複数の方法が存在し、例を挙げると、以下のステップを使用して、ＡＩＸ（商標）を備えたＩＢＭ  ｐＳｅｒｉｅｓ（商標）サーバをネットワーク・インストールすることができる。以下の順番は一例であり、実際のコマンドおよび構文はオペレーティング・システムのタイプおよびレベルによって異なる可能性があることに留意されたい。
ａ）インストール・サーバがインストール・イメージを使用できるようにする（これは、代替ブート・デバイス、ＮＩＭ、ＰＳＳＰ、ＧＰＦＳ、ＮＦＳなどの方法を単一でまたは組み合わせて使用することで、実施可能である）
ｂ）インストール・クライアントおよび必要なソフトウェア・リソースをインストール・サーバに定義する（様々なインストール・サーバおよび技法が使用可能である）
ｃ）クライアント・ネットワーク・アダプタをインストールされるノード内の「ネットワーク・ブート」モードに構成する
ｄ）クライアントとサーバとの間の「ｂｏｏｔｐ」通信を開始する（クライアントのリブートまたはサーバのｐｉｎｇがこれを実行することができる）
ｅ）ＯＳイメージをノードにネットワーク・インストールする
【００９４】
いくつかの状況では、インストール済みの保守レベルを上回る追加のオペレーティング・システムの保守が必要な可能性がある。前述と同様の方法を使用して、緊急の修正およびパッチの別々のインストールが必要な可能性もある。
【００９５】
次に、任意の必要なアプリケーション・プログラムあるいはドライバまたはその両方が、構築中のノード上に配置およびインストールされる。このプロセスは、オペレーティング・システムのインストールについて説明したばかりのプロセスとほぼ同一であるが、グリッド・カタログおよびストレージ・サブシステム（１５）に対する要求（２００）が、必要なアプリケーション・ソフトウェアあるいはドライバまたはその両方に関する固有の識別子に基づいて実行されるという点は例外である。その後、アプリケーションあるいはドライバまたはその両方の位置が識別され、動的構築モジュールはインストール・プロセスに進む。
【００９６】
代替実施形態では、オペレーティング・システムおよびアプリケーション・ソフトウェアの一般に普及した組み合わせが、単一のインストール・イメージに一括されているため、ＯＳネットワーク・インストール・ステップのみでよい。１つまたは複数のアプリケーションがオペレーション・システムと一括され、その他は別々にインストールされる、ハイブリッド・インストール・ソリューションを使用することも可能である。
【００９７】
１つまたは複数のアプリケーションあるいは１つまたは複数のドライバ、またはその両方をインストールするために従うプロセスは、オペレーティング・システムのネットワーク・インストールについて説明したプロセスと同様であるが、アプリケーション・ソフトウェアをインストールするためには一般に様々なツールおよびプロセスが必要であるという点は例外である。たとえば、イメージからオペレーティング・システムをインストールする場合、すべてのソフトウェアは、使用されるイメージ内に格納されたのとまったく同様にファイル・システム内にインストールされる。しかしながら、アプリケーション・ソフトウェアの場合、いくつかのアプリケーション・インストール・ツールはデフォルトのインストール・ポイントを提供するが、多くは明示的に作成または定義しなければならない。
【００９８】
一例として、ＩＢＭソフトウェアをＡＩＸ  ＯＳ上にインストールする場合、ｉｎｓｔａｌｌｐコマンドが使用され、デフォルトのインストール・ファイルシステムは「／ｕｓｒ」である。他方で、Ｏｒａｃｌｅ（商標）のデータベース・アプリケーションをＩＢＭ  ＡＩＸ（商標）のＯＳ上にインストールする場合、ファイル・システム「／ｏｒａｃｌｅ／ｈｏｍｅ」を作成し、データベース・ソフトウェア・ソースを取り付け、バイナリ・ソースからオペレーティング・システム・インストール・スクリプトを実行する必要がある。これらの「インストール規則」は、好ましくは固有のソフトウェア識別子に結び付けられ、動的構築モジュールによって直接テーブル内に格納するか、またはソース・ソフトウェアと共にカタログおよびストレージ・サブシステム内に格納することができる。いずれの場合も、動的構築モジュールは、好ましくはアプリケーション・ソフトウェアをインストールするために必要なツールのアクセスおよびコマンドの実行に関与する。
【００９９】
最終的に、オペレーティング・システム、任意の必要な保守パッチおよびアップグレード、ならびにアプリケーション・ソフトウェアを含む、構築プロセスが完了する（２０１）と、動的構築モジュールは、必要なリソースが現在アクティブかつ使用可能である旨をグリッド割り振りサブシステムに通知する（２４）。この時点で割り振りサブシステムは、動的構築サブシステムから制御を戻し、実行のためにジョブを引き続いて割り当てるために、グリッドへの新しいリソースの統合を完了する。
【０１００】
当業者であれば、前述の例および実施形態の細部が本発明を例示するために提供されたものであること、ならびに、実施形態のある種の変形が本発明の趣旨および範囲を逸脱することなく作成可能であることを理解されよう。したがって、本発明の範囲は添付の特許請求の範囲によって決定されるものとする。
【図面の簡単な説明】
【０１０１】
【図１】本発明とグリッド・コンピューティング環境のプロセスとの間のグリッド内関係を示す高水準図である。
【図２】本発明の論理プロセスを示す図である。
【図３】一般にグリッド・コンピューティング機能がどのように実施されるかについての詳細を示す図である。
【図４】グリッド・リソースを選択するための機能を示す図である。
【図５】一般的なグリッド・コンピューティングを示す高水準図である。
【図６】使用可能な一実施形態に従って本発明をインプリメントするために好適な、汎用コンピューティング・プラットフォームを示す図である。
【図７】図６のプラットフォームのソフトウェア編成をより詳細に示す図である。
【図１】
2008502967.tif 000003
【図２】
2008502967.tif 000004
【図３】
2008502967.tif 000005
【図４】
2008502967.tif 000006
【図５】
2008502967.tif 000007
【図６】
2008502967.tif 000008
【図７】
2008502967.tif 000009
【国際調査報告】
2008502967.tif 000010
2008502967.tif 000011
2008502967.tif 000012