(57)【要約】【課題】準最適なグリッド環境内でアプリケーションの動作を維持する方法、システム、およびプログラムを提供する。【解決手段】アプリケーションプロファイルは複数の異機種のリソースプラットフォームに渡るアプリケーションの動作要件を表し、アプリケーションに準最適な条件が検出されたときアプリケーションによるリソースの使用を調整できるように、アプリケーションのモジュラー分割の優先順位を表す。アプリケーションはグリッド環境内の複数のリソースノードの中から少なくとも１つのリソースノードに実行依頼される。さらに、サービス可用性管理エージェントが少なくとも１つのリソースノードのパフォーマンス状態を監視する。サービス可用性管理エージェントはパフォーマンス状態を、アプリケーションプロファイルの少なくとも１つのリソースノードのプラットフォームに規定される動作要件と比較する。パフォーマンス状態が動作要件を満たさなければ、サービス可用性管理エージェントがアプリケーションプロファイルに従いアプリケーションによるリソースノードの使用を調整して、グリッド環境で準最適な条件が生じたときにもアプリケーションが動作し続けられるようにする。【選択図】図９
2007518169.tif 000002
【特許請求の範囲】
【請求項１】
準最適な最適とはいえないグリッド環境内でアプリケーションの動作を維持する方法が、
グリッド環境内の複数のリソースノードの中から少なくとも１つのリソースノードにアプリケーションを実行依頼するステップと、
前記少なくとも１つのリソースノードのパフォーマンス状態を監視するステップと、
前記パフォーマンス状態を、前記アプリケーションが前記少なくとも１つのリソースノードで動作しているときに規定される動作要件と比較するステップと、
前記動作要件を満たさない前記パフォーマンス状態に応答して、前記アプリケーションによる前記少なくとも１つのリソースノードの使用を調整し、グリッド環境で準最適な最適とはいえない条件が生じるときも前記アプリケーションを動作し続けられるように、前記アプリケーションによる前記少なくとも１つのリソースノードの使用を調整するステップ[MSOffice1]と
を含む方法。
【請求項２】
前記アプリケーションによる前記少なくとも１つのリソースノードの使用を調整するステップがさらに、
前記グリッド環境内の前記複数のリソースノードの中から、前記アプリケーションを少なくとも１つの他のリソースノードでが動作しているとき前記アプリケーションに規定される前記動作要件を満たす少なくとも１つの他のリソースノードを特定配置するステップと、
前記アプリケーションを前記グリッド環境内の前記少なくとも１つの他のリソースノードに再配置するステップと
を含む請求項１に記載の準最適なグリッド環境内でアプリケーションの動作を維持する方法。
【請求項３】
前記アプリケーションにより前記少なくとも１つのリソースノードの使用を調整するステップがさらに、
シャットダウンするべき前記アプリケーションの第１モジュールを識別するステップと、前記第１モジュールをシャットダウンするメッセージを前記少なくとも１つのリソースノードに送るステップと
を含む請求項１に記載の準最適なグリッド環境内でアプリケーションの動作を維持する方法。
【請求項４】
シャットダウンするべき前記アプリケーションの第１モジュールを識別するステップがさらに、
前記アプリケーションのアプリケーションプロファイルを探して前記第１モジュールを識別するステップを有し、
前記アプリケーションプロファイルが前記第１モジュールを定義して、前記第１モジュールを優先することを特徴とする請求項３に記載の準最適なグリッド環境内でアプリケーションの動作を維持する方法。
【請求項５】
さらに、前記アプリケーションが前記第１モジュールがなくても動作し続けることができるかどうかを判別するステップと、
前記アプリケーションが前記第１モジュールなしでは動作し続けられないとの判別に応答して、前記アプリケーションを要求するクライアントシステムに前記アプリケーションのエラーメッセージを返すステップと、
前記アプリケーションが前記第１モジュールなしで動作し続けられるという判別に応答して、前記第１モジュールをシャットダウンした後に前記パフォーマンス状態が前記動作要件を満たさない場合、次のモジュールをシャットダウンするよう識別するべきかどうかを判別するステップと
をさらに含む請求項３に記載の準最適なグリッド環境内でアプリケーションの動作を維持する方法。
【請求項６】
前記少なくとも１つのリソースノードが、前記動作要件を規定した少なくとも１つのプラットフォームで動作することを特徴とする請求項１に記載の準最適なグリッド環境内でアプリケーションの動作を維持する方法。
【請求項７】
さらに、前記アプリケーションのジョブ要求の受取りに応答して、前記アプリケーションのプロファイルにアクセスするステップをさらに有し、前記プロファイルが、前記複数のリソースノードが分散される複数のプラットフォームの前記アプリケーションについて、前記動作要件を規定することを特徴とする請求項１に記載の準最適なグリッド環境内でアプリケーションの動作を維持する方法。
【請求項８】
前記アプリケーションの前記プロファイルがさらに、前記アプリケーションの複数の属性のＸＭＬ表現と、前記複数のプラットフォームの各々で動作しているときの前記アプリケーションのパフォーマンス範囲とを有する請求項７に記載の準最適なグリッド環境内でアプリケーションの動作を維持する方法。
【請求項９】
さらに、前記アプリケーションのジョブ要求の受取りに応答して、前記アプリケーションのプロファイルにアクセスするステップをさらに有し、前記プロファイルが前記アプリケーションの少なくとも１つのモジュールと、前記少なくとも１つのリソースノードの使用が調整されるとき前記少なくとも１つのモジュールをシャットダウンするための優先順位とを規定することを特徴とする請求項１に記載の準最適なグリッド環境内でアプリケーションの動作を維持する方法。
【請求項１０】
前記アプリケーションの前記プロファイルがさらに、前記アプリケーションの複数の属性のＸＭＬ表現と、前記少なくとも１つのモジュールをシャットダウンするときに達成するべき前記アプリケーションのパフォーマンス範囲とを有する請求項９に記載の準最適なグリッド環境内でアプリケーションの動作を維持する方法。
【請求項１１】
前記アプリケーションが、前記グリッド環境内で動作する独立型アプリケーション、サービス、エージェントおよびコントローラの中の１つであることを特徴とする請求項１に記載のアプリケーションの動作を維持する方法。
【請求項１２】
準最適な最適とはいえないグリッド環境内でアプリケーションの動作を維持するシステムが、
グリッド環境内で制御可能な複数のリソースの中から少なくとも１つのリソースノードで動作するために、アプリケーションのルーティングを制御するグリッド管理コントローラと、
前記少なくとも１つのリソースノードのパフォーマンス状態を監視する監視手段と、前記パフォーマンス状態を、前記アプリケーションが前記少なくとも１つのリソースノードで動作しているときに規定される動作要件と比較する比較手段と、
前記パフォーマンス状態が前記動作要件を満たさないことに応答して、前記アプリケーションによる前記少なくとも１つのリソースノードの使用を調整する調整手段と
を含むシステム。
【請求項１３】
前記調整手段がさらに、
前記グリッド環境内の前記複数のリソースノードの中から、前記アプリケーションが少なくとも１つの他のリソースノードで動作しているときに前記アプリケーションに規定される前記動作要件を満たす少なくとも１つの他のリソースノードを配置特定する手段と、
前記グリッド環境内の前記少なくとも１つの他のリソースノードに前記アプリケーションを再配置リルートする手段とを含む請求項１２に記載の準最適なグリッド環境内でアプリケーションの動作を維持するシステム。
【請求項１４】
前記調整手段がさらに、
シャットダウンするべき前記アプリケーションの第１モジュールを識別する手段と、
前記第１モジュールをシャットダウンするメッセージを前記少なくとも１つのリソースノードに送る手段とを含む請求項１２に記載の準最適なグリッド環境内でアプリケーションの動作を維持するシステム。
【請求項１５】
シャットダウンするべき前記アプリケーションの第１モジュールを識別する前記手段がさらに、
前記アプリケーションプロファイルが前記第１モジュールを定義して、前記第１モジュールを優先する前記アプリケーションのアプリケーションプロファイルと、
前記第１モジュールを識別する前記アプリケーションプロファイルを探す手段とを含む請求項１４に記載の準最適なグリッド環境内でアプリケーションの動作を維持するシステム。
【請求項１６】
さらに、前記アプリケーションが前記第１モジュールなく動作し続けられるかどうかを判別する手段と、
前記アプリケーションが前記第１モジュールなく動作し続けられないという判別に応答して、前記アプリケーションのエラーメッセージを前記アプリケーションを要求するクライアントシステムに返す手段と、
前記アプリケーションが前記第１モジュールなく動作し続けられるという判別に応答して、前記第１モジュールのシャットダウン後に前記パフォーマンス状態が前記動作要件を満たさない場合、次のモジュールをシャットダウンするよう識別するべきかどうかを判別する手段と
をさらに含む請求項１４に記載の準最適なグリッド環境内でアプリケーションの動作を維持するシステム。
【請求項１７】
さらに、前記アプリケーションのジョブ要求を受け取ったことに応答して、前記アプリケーションのプロファイルにアクセスする手段をさらに有し、前記プロファイルが、前記複数のリソースノードが分散する複数のプラットフォームの前記アプリケーションについて前記動作要件を規定することを特徴とする請求項１２に記載の準最適なグリッド環境内でアプリケーションの動作を維持するシステム。
【請求項１８】
前記アプリケーションの前記プロファイルがさらに、前記アプリケーションの複数の属性のＸＭＬ表現と、前記複数のプラットフォームの各々で動作するときの前記アプリケーションのパフォーマンス範囲とを有する請求項１７に記載の準最適なグリッド環境内でアプリケーションの動作を維持するシステム。
【請求項１９】
さらに、前記アプリケーションへのジョブ要求を受け取ったことに応答して、前記アプリケーションのプロファイルにアクセスする手段をさらに有し、前記プロファイルが、前記少なくとも１つのリソースノードの前記使用を調整するとき、前記アプリケーションの少なくとも１つのモジュールと、前記少なくとも１つのモジュールをシャットダウンする優先順位とを規定することを特徴とする請求項１２に記載の準最適なグリッド環境内でアプリケーションの動作を維持するシステム。
【請求項２０】
前記アプリケーションの前記プロファイルがさらに、前記アプリケーションの複数の属性のＸＭＬ表現と、前記少なくともモジュールをシャットダウンするとき達成すべき前記アプリケーションのパフォーマンス範囲とを有する請求項１９に記載の準最適なグリッド環境内でアプリケーションの動作を維持するシステム。
【請求項２１】
前記アプリケーションが、前記グリッド環境内で動作する独立型アプリケーション、サービス、エージェント、およびコントローラの中の１つであることを特徴とする請求項１２に記載のアプリケーションの動作を維持するシステム。
【請求項２２】
実行されることで、コンピュータに請求項１から請求項１１のいずれか１つに記載の方法の各のステップを行わせるうようになされたコンピュータプログラムコード手段を有するコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的にグリッド環境に関係し、特にグリッド環境におけるアプリケーション動作の管理に関係する。さらに具体的には、本発明はグリッド環境でアプリケーションの動作要件を表すアプリケーションプロファイルに従いアプリケーションを再構成することによって、準最適な最適とはいえないグリッド環境内でアプリケーションの動作を維持することに関係する。
【背景技術】
【０００２】
２台のコンピュータシステムが初めて接続されてからというもの、接続した２台のコンピュータシステム間でデータ、リソース、およびその他の情報を転送する新たな方法が開発され続けている。典型的なネットワークアーキテクチャでは、２台のコンピュータを接続してデータをやり取りする場合、コンピュータシステムの一方を要求を送るクライアントと考え、他方を要求を処理して結果を送り返すサーバーと考える。要求を処理する速度を高めようと、サーバーシステムはサイズと速度が拡張し続けている。また、毎秒複数の要求が到着しているピーク期間を処理するために、サーバーシステムはグループとしてまとめて、グループ化したサーバー間で要求を分散することが多い。クラスタリング、複数のシステムによるデータ共用（シスプレックス）環境、エンタープライズシステムなど、サーバーをグループ化する多数の方法が開発されている。サーバーのクラスターの場合、典型的にはあるサーバーが入ってくる要求と出す応答の分散を管理するように指定される。他のサーバーは典型的には並列して動作し、クライアントから分散された要求を処理する。このため、クラスター内の複数のサーバーのうちの１つが、クライアントがサーバーのクラスターが要求を処理していることを検出しなくとも、クライアントの要求に対しサービスを提供できる。
【０００３】
典型的には、サーバー又はサーバーグループは、ユニックス（ユニックスは、オープングループの商標である）やユニックスのいくつかのバリエーションなどのあるネットワークプラットフォームで動作し、アプリケーションを実行するためのホスティング環境を提供する。各ネットワークプラットフォームは、データベースの統合、クラスター化サービス、セキュリティから、ワークロード管理や問題判別まで様々な機能を提供できる（ユニックスは、オープングループの商標である）。各ネットワークプラットフォームは典型的には、様々な実装、意味上の振る舞い、アプリケーションプログラミングインターフェース（ＡＰＩ）を提供する。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかし、処理力を拡張するためにサーバーをまとめるだけでは、ネットワークにおける応答時間の効率を高める方法としては限られたものである。このため、企業のネットワーク内で、単にサーバーをグループ化するだけでなく、段々とサーバーとサーバーシステムのグループを分散型リソースとして編成されるようになっている。企業ネットワーク内においても企業ネットワーク外においても、サーバーを連係し、サーバー間でデータを共有し、サイクルを共有し、その他インタラクションの形態を向上させる取り組みが増えている。また、必須でない要素をある企業ネットワークからサービスプロバイダーのネットワークにアウトソーシングする取り組みが増えている。さらに、同じ管理システムに服さないが、セキュリティ、ポリシー、支払、およびメンバーシップの問題に対応するリソース間で共有するリソースを調整する動きがある。例えば、個人のデスクトップにあるリソースは典型的には企業のサーバークラスターのリソースと同じ管理システムに服さない。企業ネットワーク内の様々な管理グループでさえも、別の管理システムを実装していることもある。
【０００５】
様々な領域に配置され、様々なネットワークプラットフォームで動作するサーバーやその他コンピューティングシステムから利用でき、それぞれ別の管理システムで制御されるリソースを様々なセキュリティプロトコルで分散化するのに伴い問題が生じてきたため、グリッド環境を動かすオープンスタンダードを使うグリッドテクノロジーの開発が進められている。グリッド環境は、動的で分散化された仮想組織において多様なリソースの共用かつ調和的な使用を支援する。仮想組織は、ポリシーや管理システムの異なる様々な組織が運営する地理的に分散されたシステムからのリソースの選択をまとめてジョブ要求を処理するときに、グリッド環境で作られる。
【０００６】
グリッド環境が単なる他の管理システムとは区別されるグリッド環境の重要な特質は、複数の多様なリソースの集合で維持されるサービスの品質である。グリッド環境は単にリソースを提供するだけにとどまらないことが好ましい。すなわち、グリッド環境は、応答時間、処理量、可用性、セキュリティ、複雑なユーザーの要求を満たす複数のリソースタイプの同時確保を始めとし、決められた水準のサービスをリソースに提供する。しかし、サービスの質を提供しようとする上で、グリッド環境の問題は、ネットワークシステムの現状が必ずしも最適なパフォーマンスを利用できないときに、どのようにパフォーマンスの要件を満たすかということである。
【０００７】
まず、ネットワークシステムの現状とは、典型的にはアプリケーションは特定の動作要件をもつ特定のプラットフォームで実行するように書き込まれることである。特に、アプリケーションの動作要件はその特定のプラットフォームで最適な条件の下に実行される測定値から規定されることが多い。このため、アプリケーションの振る舞いは、非ネイティブのプラットフォームやリソースで実行する場合大幅に異なる。そのため、複数の異機種のシステムを１つのグリッド環境で互いに繋げる場合、アプリケーションを非ネイティブのプラットフォームで実行しているときのサービスの質をどのように維持するかという問題がある。特に、現在のところ、ジョブを実行するのに利用できるリソースが時間間隔をおいて急激に変わる場合、グリッド環境で実行するための各アプリケーションの動作要件を表現する手段はない。
【０００８】
また、ネットワークシステムの現状とは、アプリケーションのモジュールが比較的静的なリソースプールをもつ特定のプラットフォームで実行するよう書き込まれる場合に典型的にアプリケーションに書き込まれることである。このため、比較的静的なリソースプールのために書き込まれるアプリケーションが最適とはいえない準最適な動作条件（準最適な動作環境、次善最適な動作環境）に遭遇すると、アプリケーション全体がシャットダウンする。
【０００９】
さらに、グリッド環境内では、アプリケーションはグリッドアーキテクチャの機能性のレベルが１つしかない。アプリケーションレベルに加えて、アプリケーションで実施する複数のレベルや種類のサービスが利用できる。アプリケーションのサービスの質を維持するための同じ問題が、これらサービスレイヤがグリッド環境内の複数の異機種のプラットフォームで実行する場合にも当てはまる。
【００１０】
そのため、前記事項に鑑みて、グリッド環境内でソフトウェアの機能性のレイヤを管理する方法、システム、およびプログラム、特にサービスの質を維持するためにアプリケーション又はサービス振る舞いを変更する方法、システム、およびプログラムが必要である。このために、グリッド環境で使用するためにアプリケーション又はサービスの動作要件を表現して、グリッド環境で最適とはいえない準最適なパフォーマンスが検出されるとき、アプリケーション又はサービスの動作振る舞いをアプリケーションの動作要件に基づいて再構成できるようにするための方法、システム、およびプログラムが必要である。
【課題を解決するための手段】
【００１１】
ある実施例において、グリッド環境内の複数のリソースノードの中から少なくとも１つのリソースノードにアプリケーションを実行依頼する。その後、サービス可用性管理エージェントが少なくとも１つのリソースノードのパフォーマンスの状態を監視する。サービス可用性管理エージェントはアプリケーションが少なくとも１つのリソースノードで動作しているときに規定される動作要件とパフォーマンスの状態を比較する。特に、少なくとも１つのリソースノードを配置するプラットフォームの動作要件が規定される。また、アプリケーションのプロファイルが、複数の種類のプラットフォームでのアプリケーションの動作要件を規定する。パフォーマンス状態が動作要件を満たさなければ、サービス可用性管理エージェントが少なくとも１つのリソースノードとグリッド環境の他のリソースノードのアプリケーションによる使用を調整して、グリッド環境で準最適な最適とはいえない条件が生じたときにアプリケーションが動作し続けられるようにする。
【００１２】
サービス可用性管理エージェントは、アプリケーションによるリソースの種類と使用量の両方を調整できる。まず、サービス可用性管理エージェントは、リソースノードを配置するプラットフォームの種類に合ったアプリケーションに規定される動作要件を満たす代替リソースノードを配置して、アプリケーションを代替リソースノードに再配置できる。次に、サービス可用性管理エージェントはアプリケーションプロファイルからアプリケーションの第１モジュールを識別して、少なくとも１つのリソースノードが第１モジュールをシャットダウンするための指示を送ることができる。特に、モジュールはアプリケーションを通して調和される独立処理ユニットである。モジュールをシャットダウンした後、サービス可用性管理エージェントはアプリケーションがまだ機能できるかどうかを判別し、アプリケーションがまだ機能できるなら、リソースノードを監視して、追加モジュールをシャットダウンする必要があるかどうかを判別する。
【００１３】
一般に、アプリケーションプロファイルの目的は、複数の異機種のリソースプラットフォームにおけるアプリケーションの動作要件を表現し、アプリケーションにとって準最適な最適とはいえない条件が検出されたらアプリケーションによるリソースの使用を調整できるように、アプリケーションのモジュラー分割の優先順位を表現することである。ある実施例では、アプリケーションプロファイルは、アプリケーションの属性と、様々なプラットフォームで動作するときおよびアプリケーションのモジュールをシャットダウンしたときのアプリケーションの動作範囲を指定するＸＭＬスキーマである。別の実施例では、アプリケーションプロファイルは他のプロトコルスキーマやデータファイルで実装できるであろう。
【発明を実施するための最良の形態】
【００１４】
ここで図面、特に図１を参照すると、グリッド環境で実施でき、本発明を実施できるコンピュータシステムのある実施例が描かれている。これから詳述するように、グリッド環境はリソースを提供するために管理される複数のコンピュータシステムを含む。さらに、これから詳述するように、本発明はグリッド環境内で管理される多数の様々なオペレーティングシステムで動作する多様なコンピュータシステム、モバイルシステム、および電子機器を含め、多様なコンピュータシステムで実行できる。
【００１５】
ある実施例では、コンピュータシステム１００は、バス１２２又はコンピュータシステム１００内で情報を通信するための他のデバイスと、情報を処理するためにバス１２２に連結されるプロセッサ１１２などの少なくとも１つの処理デバイスを含む。バス１２２は、ブリッジとアダプタで接続して、コンピュータシステム１００内で複数のバスコントローラで制御される低レイテンシおよびより高いレイテンシのパスを含むことが好ましい。サーバーシステムとして実施する場合、コンピュータシステム１００は典型的には、ネットワークサービス力を高めるように設計された複数のプロセッサを含む。
【００１６】
プロセッサ１１２はＩＢＭ社のＰｏｗｅｒＰＣプロセッサなどの汎用プロセッサでよく、通常の操作中、オペレーティングシステムおよび、ランダムアクセスメモリー（ＲＡＭ）１１４などの動的な記憶装置や読み出し専用メモリー（ＲＯＭ）１１６などの静的な記憶装置からアクセス可能なアプリケーションソフトウェアの制御下でデータを処理する（ＩＢＭおよびＰｏｗｅｒＰＣはインターナショナル・ビジネス・マシーンズ・コーポレーションの商標である）。オペレーティングシステムはユーザーにグラフィカルユーザーインターフェース（ＧＵＩ）を提供してもよい。好適な実施例では、アプリケーションソフトウェアは、プロセッサ１１２で実行するとき、図９（Ａ）および（Ｂ）、１０のフローチャートで表される動作や、本明細書で説明される他の動作を行うマシン実行可能な命令を内蔵する。代わりに、本発明のステップは、ステップを行うハードワイヤードロジックを内蔵する特殊なハードウェアコンポーネントや、又はプログラムされたコンピュータコンポーネントおよびカスタムハードウェアコンポーネントの組合せによって行えるであろう。
【００１７】
本発明は、本発明に従うプロセスを行うようにコンピュータシステム１００をプログラムするために使用するマシン実行可能な命令を記憶したマシン読取可能媒体に内蔵されるコンピュータプログラム製品として提供できる。本明細書で使用する「マシン読取可能媒体」という用語は、プロセッサ１１２やコンピュータシステム１００の他のコンポーネントに実行の命令を出すことに参加するあらゆる媒体を含む。このような媒体は多数の形態をとることがあり、これだけに限定されないが、不揮発性媒体、揮発性媒体、伝送媒体が含まれる。不揮発性媒体の一般的な形態には、例えば、フロッピーディスク（R)、フレキシブルディスク、ハードディスク、磁気テープ又はその他あらゆる磁気媒体、コンパクトディスクＲＯＭ（ＣＤ−ＲＯＭ）又はその他あらゆる光学媒体、穿孔カード又は穴の模様をもつその他あらゆる物理的な媒体、プログラム可能ＲＯＭ（ＰＲＯＭ）、消去可能ＰＲＯＭ（ＥＰＲＯＭ）、電気的に消去可能なＥＰＲＯＭ（ＥＥＰＲＯＭ）、フラッシュメモリー、その他あらゆるメモリーチップ又はカートリッジ、もしくはコンピュータシステム１００が読み込むことができ、かつ命令を記憶するのに適したその他あらゆる媒体を含む。本実施例では、不揮発性媒体の例は、コンピュータシステム１００の図示されるように内部コンポーネントである大容量記憶装置１１８であるが、外部デバイスによっても提供できることは理解されるであろう。揮発性媒体としてはＲＡＭ１１４などのダイナミックメモリーがある。伝送媒体としては、バス１２２を有するワイヤを含め、同軸ケーブル、銅線、又は光ファイバーがある。伝送媒体は、電波又は赤外線を使ったデータ通信中に発生するもののような音波又は光波の形態をとることもできる。
【００１８】
さらに、本発明はコンピュータプログラム製品としてダウンロードすることもでき、プログラム命令を仮想リソース１６０などのリモート仮想リソースから要求側のコンピュータシステム１００に、バス１２２に連結される通信インターフェース１３２へのネットワークリンク１３４（例、モデムやネットワーク接続）を介する搬送波又はその他伝播媒体で具現されるデータ信号によって転送できる。仮想リソース１６０は一又は複数のシステムからアクセス可能なリソースの仮想表現を含むことができ、複数のシステムはそれぞれ独立したプラットフォームで動作する個別のリソースの集合と考えられるが、グリッドマネージャーから仮想リソースとして調和できる。通信インターフェース１３２は、例えばローカルエリアネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、又はネットワーク１０２へのアクセスを提供するインターネットサービスプロバイダ（ＩＳＰ）に接続できるネットワークリンク１３４に連結する双方向データ通信を提供する。特に、ネットワークリンク１３４は、ネットワーク１０２などの一又は複数のネットワークにワイヤードおよび／又はワイヤレスのネットワーク通信を提供でき、それによってグリッド管理システム１５０が提供するように、仮想リソース１６０などの仮想リソースの使用がアクセス可能である。グリッド管理システム１５０はピアトゥピアネットワークを始めとする複数の種類のネットワークの一部でもよく、又はコンピュータシステム１００などの単一のコンピュータシステムの一部でもよい。
【００１９】
１例として、ネットワーク１０２は、トランスミッション・コントロール・プロトコル（ＴＣＰ）やインターネット・プロトコル（ＩＰ）などのある特定のプロトコルを使用して、互いに通信するネットワークおよびゲートウェイの世界的な集合体といえよう。ネットワーク１０２は、デジタルデータストリームを搬送する電気信号、電磁信号、又は光信号を使用する。様々なネットワークを経由する信号や、ネットワークリンク１３４上および通信インターフェース１３２を経由する信号は、デジタルデータをコンピュータシステム１００に搬送したりコンピュータシステム１００から搬送されたりするが、これは情報を移送する搬送波の例示的な形態である。他の種類のネットワーク、ネットワークの組合せ、ネットワークのインフラストラクチャーも実施できることは理解されるであろう。
【００２０】
サーバーシステムとして実施する場合、コンピュータシステム１００は典型的には、入出力コントローラに接続される複数のペリフェラル・コンポーネント・インターコネクト（ＰＣＩ）バスブリッジを介してアクセス可能な複数の通信インターフェースを含む。このように、コンピュータシステム１００は複数のネットワークコンピュータに接続を可能にする。
【００２１】
さらに、図示していないが、複数の周辺コンポーネントおよび内部／外部デバイスをコンピュータシステム１００に追加してもよく、バス１２２の複数のレベルの一つに連結される複数のコントローラ、アダプタ、拡張スロットに接続される。例えば、ディスプレイデバイス、オーディオデバイス、キーボード、又はカーソル制御デバイスを周辺コンポーネントとして追加できる。
【００２２】
当業者には、図１に描くハードウェアを変更できることは理解されるであろう。また、当業者には、図示する例が本発明に関するアーキテクチャ上の制限を暗示する意図はないことは理解されるであろう。
【００２３】
ここで図２を参照すると、ブロック図はグリッド環境内の一般的な種類のコンポーネントのある実施例を図示する。本例では、グリッド環境２４０のコンポーネントは、サーバークラスタ２２２、サーバー２２４、ワークステーションおよびディスクトップ２２６、データ記憶システム２２８、およびネットワーク２３０とインターフェースするグリッド管理システム１５０とインターフェースしているクライアントシステム２００を含む。図示する目的上、グリッド環境２４０内でコンポーネントを接続するネットワークの位置とネットワークの種類は描いていない。しかし、グリッド環境２４０内のコンポーネントは、互いに重なり合う複数の種類のネットワークで実施できるネットワークインフラストラクチャーアーキテクチャの頂点に存在できることは理解されるであろう。ネットワークインフラストラクチャは、複数の大規模なエンタープライズシステムからピアトゥピアシステム、１台のコンピュータシステムにまで及ぶ。また、グリッド環境２４０内のコンポーネントはグリッド環境内のコンポーネントの種類の単なる代表であることは理解されるであろう。グリッド環境は単に１台のコンピュータシステムに入れられることもあれば、複数のシステムに及ぶこともある。
【００２４】
グリッド環境２４０などのグリッド環境の主要な目標は、仮想リソース１６０として見える複数の個別のシステムのリソースの編成と引渡しである。クライアントシステム２００、サーバークラスター２２２、サーバー２２４、ワークステーションおよびディスクトップ２２６、データ記憶システム２２８、ネットワーク２３０、およびグリッド管理システムを生成するシステム１５０は異機種混在しており、独立した管理システムで地域的に分散しているが、グリッド環境システム１５０で使用可能にされるグリッドインフラストラクチャーにより情報、リソース、およびサービスを交換することが可能である。また、サービスクラスター２２２、サーバー２２４、ワークステーションおよびディスクトップ２２６、データ記憶システム２２８、およびネットワーク２３０は様々な国や大陸に地理的に分散しても、又は互いにローカルにアクセス可能であってもよい。
【００２５】
例では、クライアントシステム２００はグリッド管理システム１５０とインターフェースする。クライアントシステム２００は、グリッド管理システム１５０に要求を送るあらゆるコンピューティングシステムを表す。特に、クライアントシステム２００はジョブ要求およびジョブをグリッド管理システム１５０に送ることができる。また、本実施例では、クライアントシステム２００はある要求でグリッド環境２４０にアクセスするように描かれているが、別の実施例では、クライアントシステム２００はグリッド環境２４０内で動作してもよい。
【００２６】
仮想リソース１６０内のシステムを並列して描いているが、現実には、システムは、仮想リソース１６０内の一部のシステムをクライアントシステム２００に限定でき、一方他のシステムが外部ネットワークへのアクセスを必要とするシステムの階層の一部となる。さらに、仮想リソース１６０内に描かれるシステムはクライアントシステム２００内に物理的に入れてもよいことに留意することが大切である。
【００２７】
グリッド管理システム１５０のある機能は、クライアントシステム２００からのジョブ要求とジョブを要求し、仮想リソース１６０内の利用できるコンピューティングシステムで特定のリソースを使用するために、仮想リソース１６０のコンピューティングシステムの選択に各ジョブの配分を制御することである。しかし、クライアントシステム２００の視点からみて、仮想リソース１６０のどのコンピューティングシステムが実際に要求を行ったかを区別することなく、仮想リソース１６０は要求を処理して結果を戻す。
【００２８】
グリッド環境２４０を実施するために、グリッド管理システム１５０がグリッドサービスを容易にさせる。グリッドサービスは、オープン・グリッド・サービス・アーキテクチャ（ＯＧＳＡ）を含むが、それだけに限定されない複数のアーキテクチャに従って設計できる。特に、グリッド管理システム１５０は、コンピューティングシステムをグリッドサービスによるリソースの共有を特徴とする異機種のネットワーク環境にリンクすることによってグリッドを生成する管理環境をいう。
【００２９】
グリッド管理システム１５０で管理するとき、グリッド環境２４０は１種類のサービス又は複数の種類のサービスを提供できる。例えば、計算グリッド、スカベンジンググリッド、データグリッドは、グリッド環境が提供するサービスの種類の分類例である。計算グリッドは高性能のサーバーの計算リソースを管理できる。スカベンジンググリッドはディスクトップコンピュータシステムの使用していないＣＰＵリソースとデータ記憶リソースを集めることができる。データグリッドは、例えば複数の組織や企業にアクセス可能なデータ記憶リソースを管理できる。グリッド環境は１種類のグリッド分類に制限されないことは理解されるであろう。
【００３０】
ここで図３を参照すると、ブロック図はグリッド環境で実施できるアーキテクチャの１例を図示している。示すように、アーキテクチャ３００は複数の機能性の層を含む。これから詳述するように、本発明は、アーキテクチャ３００のように、図２に描かれるグリッド環境などのグリッド環境で実施するアーキテクチャの一又は複数の層で実施できるプロセスである。アーキテクチャ３００はグリッド環境で実施でき、かつ本発明を実施できるアーキテクチャのほんの１例にすぎないことに留意することが大切である。また、１つのグリッド環境内で複数のアーキテクチャを実施できることに留意することが大切である。
【００３１】
アーキテクチャ３００内で、まず、物理的および論理的なリソース層３３０がグリッドのシステムのリソースを編成する。物理的なリソースとは、サーバー、記憶媒体、およびネットワークを含むが、それだけに限定されない。論理的リソースは物理的な層を仮想化して、オペレーティングシステム、処理力、メモリー、Ｉ／Ｏ処理、ファイルシステム、データベースマネージャー、ディレクトリ、メモリーマネージャー、およびその他リソースなどの有用なリソースにまとめる。
【００３２】
次に、ウエブサービス層３２０がグリッドサービス３１０と物理的および論理的なリソース３３０とのインターフェースを提供する。ウエブサービス層３２０は、インターネットプロトコル（ＩＰ）や他のネットワークトランスポート層の頂点で実行するウエブサービスを記述するための言語（ＷＳＤＬ）、シンプル・オブジェクト・アクセス・プロトコル（ＳＯＡＰ）、拡張可能マークアップ言語（ＸＭＬ）を含むが、それだけに限定されないサービスインターフェースを実施する。また、オープン・グリッド・サービス・インフラストラクチャー（ＯＳＧＩ）規格３２２が、ウエブサービス３２０を拡張してグリッドのリソースをモデル化するのに必要なダイナミックかつ管理可能なウエブサービスの能力を備えることによって、現在のウエブサービス３２０の上に構築する。特に、ＯＧＳＩ規格３２２をウエブサービス３２０とともに実施することによって、ＯＧＳＡを使って設計されるグリッドサービス３１０は相互運用可能である。別の実施例では、ウエブサービス層３２０の上に、他のインフラストラクチャー又は追加のインフラストラクチャーを実装してもよい。
【００３３】
グリッドサービス層３１０は複数のサービスを含む。例えば、グリッドサービス層３１０はＯＧＳＡを使って設計するグリッドサービスを含むことができるので、グリッドサービスを生成するときに統一規格が実施される。代わりに、グリッドサービスは複数のアーキテクチャで設計してもよい。グリッドサービスを４つの主要機能にグループ化できる。しかし、他の機能もグリッドサービスで行えることは理解されるであろう。
【００３４】
まず、リソース管理サービス３０２が物理的および論理的なリソースの使用を管理する。リソースには、処理リソース、メモリーリソース、および記憶リソースが含まれるが、それだけに限定されない。これらリソースの管理には、ジョブ要求を受け取る、ジョブ要求をスケジューリングする、ジョブを分散する、ジョブの結果の検索を管理することを含む。リソース管理サービス３０２はリソース負荷を監視し、ジョブをグリッドのよりビジーでない部分に分散して、リソース負荷の釣り合いをとり、予想しない活動のピークを吸収するのが好ましい。特に、ユーザーは、リソース管理サービス３０２がジョブを分散してグリッド内で好適なパフォーマンスレベルを維持するように、好適なパフォーマンスレベルを指定できる。
【００３５】
次に、情報サービス３０４は情報転送およびグリッド内のコンピューティングシステム間の通信を管理する。複数の通信プロトコルを実施できるため、情報サービス３０４は複数の種類の通信プロトコルを利用して、複数のネットワークにおよぶ通信を管理するのが好ましい。
【００３６】
三番目に、データ管理サービス３０６はデータ転送とグリッド内の記憶を管理する。特に、データ管理サービス３０６は、データを要求するジョブが実行するグリッド内のノードにデータを移動できる。Ｇｒｉｄファイル転送プロトコル（ＧｒｉｄＦＴＰ）などのある特定の種類の転送プロトコルを実装できる。
【００３７】
最後に、セキュリティサービス３０８がグリッド内で動作するシステムの各々の接続層で、セキュリティ用のセキュリティプロトコルを適用する。セキュリティサービス３０８はオープンなセキュア・ソケット・レイヤ（ＳＳＬ）などのセキュリティプロトコルを実装して、セキュアな伝送を提供できる。また、セキュリティサービス３０８はシングルサインオンメカニズムを提供できるため、ユーザーが一旦認証されたら、ユーザーのグリッド内で行動を行うときプロキシ証明書を作成して使用できるようになる。
【００３８】
複数のサービスはグリッドコンピューティングシステムのいくつか重要な機能を提供するよう協働できる。第１の例では、計算タスクをグリッド内で分散する。データ管理サービス３０６が計算タスクをデータのパケットの個別のグリッドサービス要求に分割し、さらにそれをリソース管理サービス３０２で分散して管理する。その結果をデータ管理システム３０６で収集してまとめる。第２の例では、グリッドの複数のコンピューティングシステムに渡る記憶リソースを、データ管理サービス３０６が管理し、リソース管理サービス３０２が監視する１つの仮想データ記憶システムとみなす。
【００３９】
アプリケーション層３４０は、グリッドサービス層３１０で利用できる一又は複数のグリッドサービスを利用するアプリケーションを含む。有利なことに、アプリケーションはグリッドサービス層３１０とウエブサービス３２０を介して物理的および論理的なリソース３３０とインターフェースするため、複数の異機種システムが対話および相互運用できる。例として、アプリケーションはウエブサイト「ｗｗｗ．ｉｂｍ．ｃｏｍ」から入手できる。ウエブサイトはユーザーがカタログサーチエンジンや企業間取引サービスなどのサービスから選ぶジョブ要求を送るためのエントリーポイントを提供する。アプリケーションおよびグリッドサービスはグリッドアーキテクチャ３００の別の層の中に位置するが、アプリケーションという場合一般にアプリケーションを通して現れるグリッドサービスも網羅することに留意することが大切である。
【００４０】
ここで図４を参照すると、本発明の方法、システム、およびプログラムに従い、グリッド管理システムの視点からみたグリッド環境内で動作するシステムのブロック図が描かれている。図１に図示するように、コンピュータシステムは多くのハードウェアコンポーネントを含む。しかしグリッド環境の一部として、これらハードウェアコンポーネントはリソースとみなされる。例えば、システム４００はアプリケーションリソース４０２と、２つのＣＰＵリソース４０４および４０６と、メモリーリソース４０８と、記憶リソース４１０とを含む。システム４００のリソースはグリッド環境内で考えればリソースの種類の典型であるが、別の実施例では他の種類のリソースも提供できる。また、システム４００のリソースは物理的に１台のコンピュータシステム内に位置しても、又は例えばネットワークで接続する複数のコンピュータシステムに分散してもよい。
【００４１】
図２に描くグリッド管理システムの一部として、グリッドマネージャーおよびルーター（ＧＭ）４２４はシステム４００のリソースと要求を送るクライアントシステムとのインターフェースを提供する。
【００４２】
特に、ＧＭ４２４内のリソースモニター４２２はシステム４００で利用できるリソースそれぞれの稼動状態を監視する。ＧＭ４２４はグリッド環境内の他のグリッドマネージャーおよびルーターに状態レポートを送って、システム４００のリソースの可用性を示すことが好ましい。加えて、状態レポートはシステム４００のコンピュータハードウェア、オペレーティングシステム、およびリソースを記述できる。状態レポートは、例えば、システム４００がグリッド環境に参加又は退出したとき、閾値を検出したとき、所定の時間間隔になったとき、ハードウェアの故障やアプリケーション又はサービスの一部の欠落を含むが、それだけに限定されない特別な所定のイベントがあった場合に生成できる。
【００４３】
ここで図５を参照すると、図示は、本発明を実施できるグリッド環境の論理的なインフラストラクチャーのある実施例を表す。図２はグリッド環境の一般的なコンポーネントの例を表しているが、本図では、一般的なコンポーネントがグリッド環境内で論理的にどのようにみえるかの例をグリッド環境５４０に図示している。特に、グリッド管理システムの機能は、ＧＭ５０４、ＧＭ５１０、およびＧＭ５２０などの複数のＧＭに論理的に分散している。また、仮想リソースは、ＲＳ５０６、ＲＳ５０８、ＲＳ５１２、ＲＳ５１４、ＲＳ５２２、およびＲＳ５２４などの複数のリソース（ＲＳ）に論理的に分散する。リソースは物理的なリソースの直接的な表現ではなく、むしろ一又は複数の物理的なリソースや物理的なリソースのグループの論理的な表現であることに留意することが大切である。
【００４４】
例では、クライアントシステム２００がジョブ要求をＧＭ５０４に送る。ＧＭ５０４は、ジョブ要求に指定されるジョブを処理するのに利用できるリソースを探す。特に、ＧＭ５０４はＲＳ５０６およびＲＳ５０８がジョブ要求で指定されるジョブを処理できるかどうかを点検して、問合せを他のＧＭ、ＧＭ５１０やＧＭ５２０などに送ることができる。ＧＭ５１０および５２０はジョブ要求を処理するリソースの可用性についてのレポートを返す。
【００４５】
特に、ジョブ要求はグリッドサービスのためにある特定のアプリケーションから出される要求を含むことが好ましい。一般に、アプリケーションは自己充足的であるが、グリッドサービス層をあらわにする。ジョブ要求を処理するのに必要なリソースは、アクセスされるアプリケーションおよびサービスが指定したとおりに要求を処理するために必要なものである。
【００４６】
例示の目的上、ＲＳ５０６およびＲＳ５０８はローカルリソース、又はクライアントシステム２００からのジョブが実行依頼される同じ個別のリソース集合内のリソースと考えられる。以下の例では、ＲＳ５０６および５０８がクライアントシステム２００からのジョブのパフォーマンス要件を満たさない場合、同じ個別のリソース集合内の他のリソース、キャパシティオンデマンドリソース、内部グリッドからのリソース、および最終的には外部グリッドからのリソースを始めとして追加リソースを割り当てることができる。
【００４７】
さらに具体的には、例では、ＧＭ５１０、ＲＳ５１２、およびＲＳ５１４は、第１規定数のグリッドサービスを第１規定価格で提供する第１企業が運営するあるグリッドインフラストラクチャ「グリッドＡ」の一部である。また、ＧＭ５２０、ＲＳ５２２、およびＲＳ５２４は、第２規定数のグリッドサービスを第２規定価格で提供する第２企業が運営する別のグリッドインフラストラクチャ「グリッドＢ」の一部である。ＧＭ５０４がジョブ要求をＧＭ５１０およびＧＭ５２０に送ると、各ＧＭがジョブ要求を処理できるかどうかと要求を処理するための価格を報告するのが好ましい。クライアントシステム２００に関して、グリッドＡおよびＢは、クライアントシステム２００又は外部グリッドと同じエンタープライズシステム内で動作する内部グリッドでもよい。
【００４８】
リソースの可用性に関するレポートを受け取った後、ＧＭ５０４はジョブを処理するための選択肢を収集して、その選択肢をクライアントシステム２００に返す。それからクライアントシステム２００は好ましい選択肢を選んで、選んだ選択肢に従い処理させるジョブを送ることにする。ＧＭ５０４はクライアントシステム２００へのジョブの結果の返信を管理する。
【００４９】
クライアントシステム２００が選んだ選択肢で利用するリソースは、ジョブを処理する仮想組織となる。例えば、クライアントシステム２００がＧＭ５１０から戻った選択肢に基づいてジョブを処理する選択肢を選んだ場合、ジョブを処理するために、ＧＭ５０４、ＧＭ５１０、ＲＳ５１２、およびＲＳ５１４を含む仮想組織が形成されるであろう。
【００５０】
本発明の利点に従い、サービス可用性管理エージェント（ＳＡＭＡ）５３０はグリッド環境５４０内でアクセスできることが好ましい。ＳＡＭＡはグリッド環境５４０のグリッドリソース、ポリシー調整、アプリケーションプロファイル管理、解析処理、および問題のディスパッチを監視する機能を行う。ＳＡＭＡ５３０は、エラー管理を行いながら、その振る舞いを管理するダイナミックポリシーで制御してもよい。特に、アプリケーションおよびサービスを最小動作レベル又は全くサービスのないところまで落とす準最適な最適とはいえない条件が発生したら、グリッド環境５３０内でエラーが発生する。前記準最適な最適とはいえないパフォーマンスは、システム故障、ネットワークインフラストラクチャの障害又は過負荷になる、又はグリッド環境５４０内で発生するその他故障の結果として生じることがある。
【００５１】
特に、グリッド環境５４０内で準最適な最適とはいえない条件が検出される場合、ＳＡＭＡ５３０はアプリケーションおよびサービスを機能し続けられるようにグリッドリソースの利用を管理するのが好ましい。特に、ＳＡＭＡ５３０は、アプリケーション又はサービスを稼動し続けようとして、アプリケーション又はサービスに提供するリソースの種類と量を調整できる。例えば、ＳＡＭＡ５３０はアプリケーション又はサービスを新たなリソースノードの集合に移すことができる。加えて、例えば、ＳＡＭＡ５３０はリソースの利用を少なくするようにアプリケーションの動作振る舞いを再構成できる。
【００５２】
特に、ＳＡＭＡ５３０は１つのシステム内に組み込んでも、複数のシステムに分散してもよい。また、図３のグリッドアーキテクチャ３００内で、ＳＡＭＡ５３０は複数のレベルで実装できる。例えば、ＳＡＭＡ５３０は一部をウエブサービスとして、一部をリソース管理サービスとして実装してもよい。
【００５３】
ＳＡＭＡ５３０はアプリケーションとサービスの両方でグリッドリソースの利用を管理できるが、例示の目的上、アプリケーションのグリッドリソースの管理を説明することに留意することが大切である。また、ＳＡＭＡ５３０はグリッド環境５４０内で動作する他のコントローラおよびエージェントでグリッドリソースの利用を管理できることは理解されるであろう。
【００５４】
ここで図６を参照すると、本発明の方法、システム、およびプログラムに従うＳＡＭＡコントローラのある実施例のブロック図である。描かれるように、ＳＡＭＡ５３０は複数のコントローラとＳＡＭＡデータベース６１０を含む。
【００５５】
まず、リソースモニター６０６がグリッド環境のリソースのパフォーマンスと可用性を監視する。より具体的には、リソースモニター６０６は、例えば、リソースの利用、容量、処理量を監視できよう。
【００５６】
推論分析コントローラ６０４は好ましくは、グリッド環境で動作するシステムからメッセージを受信し、そのメッセージを構文解析して具体的な要求を判断する。特に、メッセージはジョブ要求を含めることができる。ジョブ要求は、グリッドから利用できるアプリケーションに発行されるある特定のサービス又は複数のサービスを呼び出せる。各アプリケーションはプロファイル６１２に記憶されるプロファイルをもつことが好ましい。例示の目的上、グリッドアプリケーションプロファイルデータベース６１２は、各アプリケーションのプロファイルのＸＭＬ表現であるドキュメントタイプの定義（ＤＴＤ）を含む。リソース利用を管理するプロファイルのアプリケーションの例としてアプリケーションによるリソースの利用を重点的に取り上げているが、サービスを始めとし、グリッドアーキテクチャ内のすべての機能性の層にプロファイルを指定できることに留意することが大切である。
【００５７】
アプリケーションプロファイルのスキーマの例を（表１）に図示する。例では、アプリケーションプロファイルに含まれるであろうアプリケーションの属性情報の種類のサンプルを図示する。特に、アプリケーションの名前、バージョン、明細、開発者の名前、所有者の名前、コードサイズを規定できる。次に、例では、アプリケーションの最小パフォーマンスと最大パフォーマンスの要件のサンプルを、グリッド環境内のアプリケーションを動作させるために利用できる各プラットフォームについて規定する。さらに、アプリケーションのモジュールとプラットフォームに基づき予想されるパフォーマンスを含む。モジュールの定義は、例えば、モジュール名、モジュールデータ、必要なリソースの量、優先順位を含めることができる。プラットフォームの定義は、例えば、プラットフォームの名前、プラットフォームのバージョンと明細、最大および最小のメモリーサイズ、対称型マルチプロセッサ（ＳＭＰ）システムにおける最大および最小のＣＰＵの要求事項、最大および最小のＣＰＵのクロック速度、オペレーティングの名前とバージョンを含めることができる。加えて、セキュリティの要件として、アプリケーションが動作するあらゆるプラットフォームについて、アプリケーションプロファイルはある特定の種類の所要プラットフォーム認定を規定でき、認定はプラットフォームが共通基準（ＣＣ）などのセキュリティ規格によりあるレベルの保証を受けていることを示す。アプリケーションプロファイルの本例はＸＭＬ表現であるが、他の種類のプロファイル表現も実施できることは理解されるであろう。スキーマ例はグリッド環境内のサービス、エージェント、およびその他コントローラにも適用できることは理解されるであろう。また、当業者には理解されるように、本発明の実施において、アプリケーションプロファイルに他の種類の情報を含むこともできよう。
【００５８】
プロファイル管理コントローラ６０２は、アプリケーションプロファイルの最大および最小の動作要件を現在の動作条件と比較して、グリッドが最適な条件で動作しているかを判断する。グリッドが最適な条件で実行していなければ、プロファイル管理コントローラ６０２がアプリケーションが別のリソースノード又は複数のノードで実行するようスケジューリングできるかどうかを判別するのが好ましい。特に、プロファイル管理コントローラ６０２は追加のリソースノードのプラットフォームを、アプリケーションプロファイルで規定されるアプリケーションのプラットフォームの要件と比較する。また、追加ノードが利用できない場合、プロファイル管理コントローラ６０２は、アプリケーションプロファイルに従い最小限の動作条件を維持しながら、アプリケーションのモジュールのレベル低下又はシャットダウンできるかどうかを判別する。特に、プロファイル管理コントローラ６０２はアプリケーションプロファイルを処理して、アプリケーションに識別されるモジュールを判別できる。ある例では、各モジュールにはリソースサイズの要件と除去又はシャットダウンする優先順位が割り当てられる。プロファイル管理コントローラ６０２は各モジュールの優先順位とリソースサイズの要件に従いモジュールをシャットダウンするのが好ましい。
【００５９】
代わりに、ＳＡＭＡ５３０で受け取るメッセージは、クライアントシステムがジョブを送る前にジョブ要求を処理するためのグリッド環境の可用性について状態要求を含めることができる。特に、サービス在庫データベース６１６はグリッドから利用できるアプリケーションおよびサービスの現状を維持する。サービス在庫データベース６１６はモジュールがシャットダウンされたときは必ず更新して、状態要求に対する応答をサービス在庫データベース６１６の状態に基づいて効率的に返せるようにするのが好ましい。
【００６０】
プロファイル管理コントローラ６０２がグリッドリソースの使用を調整する前に、推論分析コントローラ６０４がアプリケーションの要求又は監視された準最適な最適とはいえない条件をポリシーデータベース６１４のグリッドポリシーと比較できる。特に、グリッドポリシーはグリッド環境の全体的な動作要件を規定できる。また、グリッドポリシーは、プロファイル管理コントローラ６０２がグリッドリソースの使用を調整しているとき、ある特定のアプリケーションに利用できるリソースの種類と量を規定できる。
【００６１】
（表１）
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
<?xml version="1.0"encoding="UTF-8"?>
<!--
**************************************************************************
Application Profile DTD-Version1.0
**************************************************************************
+:One or more permitted
*:Zero or more permitted
?:Optional
**************************************************************************
-->
<!--Application Profile Definition-->
<!ELEMENT Application(ApplicationData,AppVital
Security+)>
<!-Application attributeinformation-->
<!ELEMENT ApplicationData>
<!ATTLIST ApplicationData
Name CDATA#REQUIRED
Version CDATA#REQUIRED
Description CDATA#REQUIRED
DeveloperName CDATA#REQUIRED
OwnerName CDATA#REQUIRED
codeSIZE CDATA#REQUIRED
>
<!ELEMENT AppVital(PruneModule*,Platform+)>
<!ATTLIST AppVital
minimalPerformance CDATA#REQUIRED
maximumPerformance CDATA#REQUIRED
<!-PruneModule Definition-->
<!ELEMENT PruneModuleEMPTY>
<!ATTLIST PruneModule
ModuleName CDATA#REQUIRED
ModuleData CDATA#REQUIRED
ResourceAmt CDATA#REQUIRED
PriorityNumber CDATA#REQUIRED>
<!-Platform supported Definition-->
<!ELEMENT Platform EMPTY>
<!ATTLIST Platform
Name CDATA#REQUIRED
Version CDATA#REQUIRED
Description CDATA#REQUIRED
MaxMemorySize CDATA#REQUIRED
MinMemorySize CDATA#REQUIRED
MaxCPU CDATA#REQUIRED
MinCPU CDATA#REQUIRED
MaxSpeed CDATA#REQUIRED
Min CDATA#REQUIRED
OSName CDATA#REQUIRED
OSVersion CDATA#REQUIRED
evalName CDATA#IMPLIED
evalProvider CDATA#IMPLIED
evalLevel CDATA#IMPLIED
evalDateIssuedCDATA#IMPLIED
>
<!-Security Information Definition-->
<!ELEMENT Security EMPTY>
<!ATTLIST Security
keyType(SYMMETRIC│ASYMMETRIC)CDATA#REQUIRED
algorithmName CDATA#REQUIRED
algorithmAttribute CDATA#IMPLIED
keyLength CDATA#REQUIRED
keyIdentifier CDATA#REQUIRED
keyUsage(Authentication│Encryption│Signature)
CDATA#REQUIRED
eExportable(TRUE│FALSE) CDATA#REQUIRED
certificateType(X509V1│X509V3│OTHER) CDATA#IMPLIED
certificateName CDATA#IMPLIED
certificateAttribute CDATA#IMPLIED
cSProviderType(Software│Hardware)
CDATA#REQUIRED
ssmName CDATA#IMPLIED
ssmVersion CDATA#IMPLIED
ssmExtName CDATA#IMPLIED
ssmExtVersion CDATA#IMPLIED
hsmName CDATA#IMPLIED
hsmVersion CDATA#IMPLIED
hsmFirmName CDATA#IMPLIED
hsmFirmVersion CDATA#IMPLIED
hsmExtName CDATA#IMPLIED
hsmExtVersion CDATA#IMPLIED
evalName CDATA#IMPLIED
evalProvider CDATA#IMPLIED
evalLevel CDATA#IMPLIED
evalDateIssued CDATA#IMPLIED
>
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
【００６２】
ここで図７を参照すると、本発明の方法、システム、およびプログラムに従い、アプリケーションをリルートすることによってリソースの使用を調整するある方法を図示するブロック図を示している。示されるように、アプリケーション７００は当初プラットフォーム７０６で動作するノードＡのリソースで実行される。アプリケーション７００がプラットフォーム７０６で実行するための動作要件は、アプリケーション７００のプロファイルで定義するのが好ましい。プラットフォーム７０６で実行するアプリケーション７００のパフォーマンスがプロファイルに従い準最適であるならば、ＳＡＭＡはアプリケーション７００の動作要件を満たすために利用できる他のリソースを探すことができる。例では、プラットフォーム７０８で実行しているノードＢが、アプリケーション７００のアプリケーションプロファイルによりプラットフォーム７０８に規定される動作要件を満たすために利用できる。アプリケーション７００に新しいノードが配置されたら、ＳＡＭＡはリソースノードＡからノードＢにアプリケーションを転送するようジョブルーターに指示して、ノードＢのパフォーマンスの監視を開始する。本例はあるプラットフォームのあるノードから別のプラットフォームの別のノードに移動するアプリケーションを参照して説明するが、アプリケーションはあるリソースノードから同じプラットフォーム内の別のリソースノードに移動しても、又はリソースノードのあるクラスターからリソースノードの別のクラスターに移動してもよいことがわかるだろう。
【００６３】
ここで図８を参照すると、本発明の方法、システム、およびプログラムに従い、アプリケーションの動作振る舞いを再構成することによりリソースの使用を調整する別の方法を図示するブロック図を示す。図示するように、アプリケーション７００は複数の独立した処理モジュールＡ〜Ｎを含む。モジュールＡ〜Ｎは１つのリソース又は複数のリソースで処理できる。また、１つのモジュールは、モジュールに必要なリソースのサイズによって、複数のリソースに渡って処理できる。
【００６４】
特に、アプリケーション７００のプロファイルでは、各モジュールについてシャットダウンの優先順位を規定するのが好ましい。例では、アプリケーション７００のモジュールＡ、Ｂ、およびＮを一又は複数のノードのグリッド環境で実行している。このグリッド環境はアプリケーション７００の準最適な最適とはいえないパフォーマンスを提供できるにすぎない。このため、ＳＡＭＡはアプリケーション７００のモジュールをシャットダウンして、アプリケーション７００の一部をアプリケーション全体をシャットダウンしなくても動作し続けられるかどうかを判別する。例では、モジュールＢに最も高いシャットダウンの優先順位を割り当てる。ＳＡＭＡは、このシャットダウンの優先順位の最も高いモジュールがモジュールをシャットダウンしなければならないほどリソースを使い果たしていることを判断できる。ＳＡＭＡはモジュールＢを実行しているノード又は複数のノードにモジュールをシャットダウンする命令を送ることができる。モジュールＢをシャットダウンした後もパフォーマンスが準最適な最適とはいえないままであれば、ＳＡＭＡは次のモジュールをシャットダウンする命令を送ることができる。
【００６５】
ここで図９（Ａ）および乃至（Ｂ）図１１をを参照すると、準最適な最適とはいえない条件で動作するグリッド環境内のアプリケーションによってグリッドリソースの使用を調整するプロセスおよびプログラムの高次の論理的なフローチャートを図示する。図示するように、プロセスはブロック９００で始まり、その後ブロック９０２に進む。ブロック９０２はジョブ要求が受け取られたかどうかの判別を表す。ジョブ要求が受け取られていなければ、プロセスはブロック９０２を繰り返す。ジョブ要求が受け取られれば、プロセスはブロック９０４に進む。ブロック９０４は、ジョブ要求を出したアプリケーションから呼び出される少なくとも１つのアプリケーションのアプリケーションプロファイルを検索するステップを表す。次に、ブロック９０５はアプリケーションプロファイルとグリッドポリシーに従いリソースをスケジューリングするステップを表す。その後、ブロック９０６は選んだグリッドリソースにジョブを実行依頼するステップを表し、プロセスはブロック９０７に進む。
【００６６】
ブロック９０７は、アプリケーションを実行するリソースのグリッドパフォーマンスを監視するステップを図示する。その後、ブロック９０８は、アプリケーションプロファイルと比べたときに、アプリケーションに準最適な最適とはいえない条件が検出されるかどうかの判別を表す。準最適な最適とはいえない条件が検出されなければ、プロセスはブロック９０７に戻る。準最適な最適とはいえない条件が検出されれば、プロセスはブロック９１０に進む。
【００６７】
ブロック９１０は、アプリケーションを実行しているある特定のプラットフォームのアプリケーションプロファイルからのアプリケーション動作要件を満たすように、アプリケーションを再配置する他のノードを探すステップを表す。次に、ブロック９１２は再配置ノードが利用できるかどうかの判別を表す。この判別はまず、グリッドポリシーに基づいて、アプリケーションにどのリソースが利用できるかどうかを判別する必要があろう。次に、利用できるリソースのうちのどれが、利用できるリソースを支持するプラットフォームに規定されるアプリケーションプロファイルの動作要件を満たすかの判別を行える。再配置ノードが利用できる場合、ブロック９２０はアプリケーションを再配置ノードに再配置するステップを表し、アプリケーションを呼び出しながらプロセスはブロック９０７に戻る。再配置ノードが利用できない場合、プロセスはブロック９１４に進む。ブロック９１４は、アプリケーションの第１優先順位のモジュールを判別するためにアプリケーションプロファイルを解析するステップを表す。次に、ブロック９１６はＳＡＭＡがモジュールをシャットダウンすべきかどうかの判別を表す。特に、ＳＡＭＡは、モジュールをシャットダウンすればアプリケーションの全体のパフォーマンスを高めるのに十分なリソースが自由に使えるかどうかを判別できる。加えて、グリッドポリシーと追加のアプリケーションプロファイル情報は、ＳＡＭＡがモジュールをシャットダウンすることにしたかどうかを制御できる。ＳＡＭＡがモジュールをシャットダウンしなければ、詳細に説明するようにプロセスはブロック９３２に進む。ＳＡＭＡがモジュールをシャットダウンすれば、プロセスはブロック９１８に進む。
【００６８】
ブロック９１８は、メッセージにアプリケーションを再構成する認証と許可が含まれる場合、アプリケーションを実行するノードにＸＭＬメッセージを送るステップを表す。他のトランザクションプロトコルも実装できることは理解されるであろう。次に、ブロック９２２はモジュールがシャットダウンされたという肯定応答を受け取ったかどうかの判別を表す。肯定応答が受け取られていなければ、プロセスはしばらくブロック９２２を繰り返す。肯定応答が受け取られれば、プロセスはブロック９２４に進む。ブロック９２４はリソースのパフォーマンスに基づきグリッドの状態を再評価するステップを表す。次に、ブロック９２６はアプリケーションを再構成するのに追加のステップが必要かどうかの判別を表す。特に、あるモジュールをシャットダウンした後に、アプリケーションが準最適な最適とはいえない条件で動作し続ける場合、アプリケーションは追加の再構成が必要であろう。追加のステップが必要な場合、詳述するようにプロセスはブロック９３２に進む。追加のステップが必要ない場合、プロセスはブロック９２８に進む。ブロック９２８はアプリケーションをレベルを落としたモジュールで実行させるステップを表す。次に、ブロック９３０はレベルを落として利用できるアプリケーションの在庫を更新するステップを表し、プロセスは終了する。
【００６９】
前述したように、プロセスはブロック９３２に進むことがある。ブロック９３２はアプリケーションがレベルが落ちた状態でもまだ機能できるかどうかの判別を表す。アプリケーションがすでに機能できなければ、プロセスはブロック９３６に進む。ブロック９３６は要求者にエラーメッセージを出して警告をするステップを表し、プロセスは終了する。代わりに、アプリケーションがまだ機能できれば、プロセスはブロック９３４に進む。ブロック９３４は、アプリケーションの次に優先順位の高いモジュールを判断するためにアプリケーションプロファイルを解析するステップを表し、プロセスはブロック９１６に進む。
【００７０】
ここで図１２を参照すると、グリッド環境で状態要求を処理するプロセスおよびプログラムの高次の論理的なフローチャートが示されている。図示されるように、プロセスはブロック１０００で始まり、その後ブロック１００２に進む。ブロック１００２はアプリケーションのリソースの十分性を予め判別する要求を受け取るステップを表す。次に、ブロック１００４はリソースの現在の十分性についてサービス在庫データベースを点検するステップを表す。モニター要求が潜在的に影響を受けるリソースに送られて、リソースの現在の可用性を判別できる。最終的に、ブロック１００６はリソースの十分性のＸＭＬ状態要求応答を返すステップを表し、プロセスは終了する。
【００７１】
本発明は好適な実施例を参照しながら具体的に図示し説明してきたが、当業者には本発明の精神および範囲を逸脱することなく、これの形態や細部に様々な変更を行えることは理解されるであろう。特に、本発明の説明は本発明がグリッドアプリケーション、サービス、エージェント、およびコントローラで動作する状況を重点的に取り上げているが、本発明は通常のウエブサービスにおいてや、一般的に分散型アーキテクチャにも適用できることに留意することが大切である。
【図面の簡単な説明】
【００７２】
本発明に特徴的と考えられる新規な特徴は、添付の請求項に記載する。しかし発明自体並びに好適な使用形態、その別の目的および利点は、以下の例示的な実施例の詳細な説明を参照して、添付の図面と合わせて読むと最善に理解できるであろう。
【００７３】
【図１】グリッド環境で実施でき、本発明を実施できるコンピュータシステムのある実施例を表す。
【図２】グリッド環境内の一般的な種類のコンポーネントのある実施例を図示するブロック図である。
【図３】グリッド環境で実施できるアーキテクチャの１例を表すブロック図である。
【図４】本発明の方法、システム、およびプログラムに従い表したグリッド管理システムからみたグリッド環境内で動作するシステムを表すブロック図である。
【図５】本発明を実施できるグリッド環境の論理的なインフラストラクチャーのある実施例を表す図示である。
【図６】本発明の方法、システム、およびプログラムに従うＳＡＭＡコントローラのある実施例を表すブロック図である。
【図７】本発明の方法、システム、およびプログラムに従いアプリケーションをリルートすることによってリソースの使用を調整するある方法を図示するブロック図である。
【図８】本発明の方法、システム、およびプログラムに従いアプリケーションの動作振る舞いを再構成することによってリソースの使用を調整する別の方法を図示するブロック図である。
【図９】（Ａ）および（Ｂ）は、グリッド環境内のアプリケーションが準最適な最適とはいえない条件で動作することによって、グリッドリソースの使用を調整するプロセスおよびプログラムの高次の論理的なフローチャートを表す。
【図１０】グリッド環境内のアプリケーションが最適とはいえない条件で動作することによって、グリッドリソースの使用を調整するプロセスおよびプログラムの高次の論理的なフローチャートを表す。
【図１１】グリッド環境内のアプリケーションが最適とはいえない条件で動作することによって、グリッドリソースの使用を調整するプロセスおよびプログラムの高次の論理的なフローチャートを表す。
【図１２】グリッド環境で状態要求を処理するプロセスおよびプログラムの高次の論理的なフローチャートを表す。
【図１】
2007518169.tif 000003
【図２】
2007518169.tif 000004
【図３】
2007518169.tif 000005
【図４】
2007518169.tif 000006
【図５】
2007518169.tif 000007
【図６】
2007518169.tif 000008
【図７】
2007518169.tif 000009
【図８】
2007518169.tif 000010
【図９】
2007518169.tif 000011
【図１０】
2007518169.tif 000012
【図１１】
2007518169.tif 000013
【図１２】
2007518169.tif 000014
【国際調査報告】
2007518169.tif 000015