(57)【特許請求の範囲】
【請求項１】
グリッド・コンピューティング環境を管理するためのシステムであって、
ジョブ部分を処理する、前記グリッド・コンピューティング環境の各リソースをモニターするための手段と、
対応するモニター対象の各リソースを識別するデータと前記ジョブ部分の特性とを含む、前記モニター手段によってモニターされた各リソースからのパフォーマンス・データを定期的に記憶するための内容アドレス記憶手段と、
処理済みパフォーマンス・データを生成するために、前記内容アドレス記憶手段によって記憶されたパフォーマンス・データを前記特性に基づいて検索し処理するための手段と、
前記処理済みパフォーマンス・データに基づいて前記グリッド・コンピューティング環境を管理するための手段と、
を含むシステム。
【請求項２】
前記グリッド・コンピューティング環境を管理するための手段が、コスト見積もり、ハードウェア／ソフトウェア要件の決定、ＲＦＰ処理、グリッド内プロセスの決定、グリッド・エレメント財務データの分析、および履歴トレンド分析のうちの少なくとも１つを含む、それぞれのグリッド環境管理機能を実行するための複数のモジュールを含む、請求項１に記載のシステム。
【請求項３】
前記グリッド・コンピューティング環境を管理するための手段が、グリッド環境管理機能を実行するためのモジュールを含む、請求項１に記載のシステム。
【請求項４】
前記データを検索し処理するための手段が、課金および統計管理モジュールを含む、請求項１に記載のシステム。
【請求項５】
グリッド・ワークロード・エージェントをさらに含み、前記課金および統計管理モジュールが前記処理済みパフォーマンス・データを前記グリッド・ワークロード・エージェントに提供する、請求項４に記載のシステム。
【請求項６】
前記グリッド・ワークロード・エージェントに関連する機能を実行するために前記グリッド・ワークロード・エージェントに関連する機能モジュールをさらに含み、
前記課金および統計管理モジュールが前記処理済みパフォーマンス・データを前記機能モジュールに提供する、請求項５に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、グリッド・コンピューティング環境に関する。より詳細には、本発明は、グリッド・コンピューティング環境で使用可能なリソースのパフォーマンスを効果的に使用し、予測するためのグリッド・リソース使用状況のパフォーマンス・ベースの管理に関する。
【背景技術】
【０００２】
データ・プロセッサ間の通信リンクが、通信または一部のデータ・プロセッサ上でのみ使用可能なリソースを共用するために設けられることがある。後者の場合、リソースを有するデータ・プロセッサは一般にサーバと呼ばれ、リソースをリクエストするデータ・プロセッサは一般にクライアントと呼ばれる。ローカル・エリア・ネットワーク（ＬＡＮ：local area network）、広域ネットワーク（ＷＡＮ：wide area network）、その他のネットワーク内の仮想ネットワーク、インターネットのようなネットワーク配置において多くのデータ・プロセッサ間で通信を行うことができる。
【０００３】
リソースの共用がより普及し、高性能なものになるにつれて、所与のデータ・プロセッサから離れた位置でデータ処理を実行することが一般的になっている。潜在的な利益（gain）を予測し、定量的見積もりを行うことは困難であったが、応答時間およびプロセッサの使用状況に関する効率および改善は、リソースの共用によって達成することができる。また、単一のデータ・プロセッサの計算能力を増加させていわゆるスーパコンピュータを構築するより、複数の接続されたデータ・プロセッサによりデータ処理を分散することによって計算能力を増加させる方が、多くの場合、より有利であることも分かっている。さらに、リモート・データ処理がずっと一般的なものになっている環境では、サーバ・システムのサイズ、速度、および計算能力は継続的に増加し続け、クラスタ化、マルチサーバ共用データ（シスプレックス（sysplex））およびグリッド環境、エンタープライズ・システムなど、複数のサーバをグループ化する複数の方法が開発されている。複数のサーバのクラスタその他の配置では、増加し続ける着信リクエストを管理するためにサーバが指定され、他のサーバはクライアントからそれぞれのリクエストの分散された一部を処理するために並列に動作する。典型的には、サーバおよびサーバ・グループは、アプリケーションを実行するための分散ホスティング環境を提供するために、ＵＮＩＸ（商標）やその亜種などの特定のプラットフォーム上で動作する。各ネットワーク・プラットフォームは、様々な機能ならびに種々の実装形態、セマンティック動作（semantic behavior）、およびアプリケーション・プログラミング・インターフェース（ＡＰＩ：applicationprogramming interface）を提供することができる。
【０００４】
しかし、複数のデータ・プロセッサを単に相互接続しても、効率または応答速度の増加が保証されるわけではない。ベストの状況における実行能力は制限されてしまっているのである。種々のリソースはセキュリティ、メンバシップなどを処理するための同様の機能を有する場合もある。逆に、リソースが同じ管理システムの対象にならない場合、コラボレーション、データ共用、サイクル分割、その他のサーバ間対話を可能な範囲で増加することができる１つの分散リソースとして複数のサーバおよびサーバ・グループを編成することにより、効率および応答速度についてある程度の改善が達成されてきた。たとえば、ある会社のサーバ・クラスタを管理する管理システムは、典型的には、同じネットワーク上にあり得るデスクトップ・パーソナル・コンピュータ上で使用可能なリソースを管理の対象とせず、また、ある会社内の異なる管理グループは、異なる管理システムを実施する複数のサーバ・グループを有することができる。
【０００５】
異なるセキュリティ・ポリシーを有し、異なるプラットフォーム上で動作する別々の管理システムによって発生する問題に対処するため、異種および分散リソースの最大限の共用および協調的な使用をサポートするようなグリッド環境を実現する、オープン・スタンダードを使用したいわゆるグリッド技術が開発された。異なるセキュリティおよびアクセス・ポリシーと管理システムを有する異なる編成によって異なるシステム（おそらく、それは分散システムであろう）が運用される場合、システムが選択したリソースがジョブ・リクエストを処理するために編成されると、グリッド環境内に仮想編成が作成される。
【０００６】
しかし、グリッド技術は、異なる管理システムおよび異なる標準を有する複数のリソース・グループ間のすべての通信問題を解決するわけではない。たとえば、各システム・グループのパフォーマンスをモニターするために現在配置されているツールおよびシステムは、特定のリソースのハードウェア・タイプに応じてリソースをグループ化し、ハードウェア・レベルでパフォーマンスをモニターするという点で制限されている。また、このようにしてリソースをグループ化した結果として、このようなモニター・ツールおよびシステムは、ハードウェア・リソース上に実装されたプロトコルの使用に制限され、したがって、典型的には、異なるグループまたは異なる管理システムあるいはその両方のモニター・ツールおよびシステム同士の直接通信をサポートしない。したがって、任意の時間にグリッド活動をモニターすることでさえ困難なことである（ただし、特許文献１には、グリッド制御機能を実行するためにそこからのデータが様々なモジュールに供給されるグリッド活動データベースを維持し、それにデータを追加するために、グリッド・ワークロード・エージェントを使用して、指定されたモニター・ルールまたは適応可能に生成されたモニター・ルールによりグリッド・モジュールに照会するという解決策が示されている）。まして、１つのデータ処理ジョブの一部を割り振ることや、価格設定、ハードウェアおよびソフトウェア要件定義の改良、提案要求（ＲＦＰ：request for proposal）処理の正確さおよびパフォーマンスの強化（たとえば、サービス・レベル・アグリーメントの遵守および達成の改善に至るランタイム見積もりの改善）、前のパフォーマンス統計および現在のパフォーマンス見積もりに基づいてリソース割当ての効率を改善するかあるいはグリッド・エレメントの財務分析またはコンピューティング業界トレンドをサポートすることによるグリッド内処理効率の増強など、商用グリッド・コンピューティング動作のその他の必要な活動をサポートすることも困難なことである。このような目的のための堅固な業界ツールであって、オンデマンド・グリッド・コンピューティング環境の要件に対処できるものは、現在、存在していない。
【０００７】
現在の技術水準では、グリッド・コンピューティングは、単一編成（single organization）のコンピューティング環境で実施されているものとほぼ同じ方法を使用して管理されている。すなわち、情報技術（ＩＴ）のマネージメント（管理職）やスタッフは、一般に、潜在的なインバウンド・ジョブを論じ、それぞれの蓄積した専門知識（これは、極めて変じやすいものであり、しかも多くの場合、経験的データを伴わない可能性があるものである）からのベストの見積もりに基づいて、コンピューティング・リソース要件および関連コスト（一般に、より精度・粒度が高いかまたは特定の価格設定モデルをサポートするためのメカニズムが存在しないので、固定毎時コストである）を作成する。パフォーマンス・データはグリッド上で収集することができるが、複数の関連ジョブまたは評価のために他のジョブと相関させた同様の特性を有する複数のジョブからのジョブ・データがなければ、このようなパフォーマンス・データは、正確なジョブ・ランタイムおよび価格設定の見積もりを作成するときに有用なものとならない。
【０００８】
たとえば、従来型のコンピューティング環境では、ＤＢ２（商標）などの単一アプリケーションは、１つの特定のノードまたはノード・セット上で実行することができる。パフォーマンス・モニターは、このようなノードから定期的にデータをサンプリングし、ピーク・ワークロード・トレンドなどの事実を決定することができる。しかし、グリッド環境では、１つのノードがいくつかの異なるアプリケーションを実行することができ、そのそれぞれが任意の期間にジョブの一部を処理することができる。よって、グリッド全体に関する包括的なデータがない場合、任意のノードのハードウェアに関する単純な生のパフォーマンス・データは特定の特性を有する特定のジョブに関して無意味である。また、たとえ収集可能であっても、複数のノードに関するデータは評価中の着信ジョブ（incoming job）と相関させることができない。というのは、任意の期間の各ノードのパフォーマンスは、各ノードのハードウェア上で実行される多様な要件および特性を有する複数のジョブに関連する可能性があるからである。
【０００９】
問題は、オンデマンド・コンピューティングの動的な性質によって複雑になっている。現在の従来型パフォーマンス・データ収集ツールは、多くの場合、トレンド分析に基づいてワークロードを平滑化できるようなトレンド作成以上のものを可能にすることはほとんどない。たとえば、クライアントのＤＢ２データベース（サーバ）ノードは、定期的に繰り返すある期間中は一貫して過負荷（overworked）になり、他の期間中は一貫して過少負荷（underworked）になる場合、いくつかのバッチ処理ジョブを前者の期間から後者の期間に移動することができる。このスタイルのモニターおよび平滑化は、それらが実行される割当て済み静的リソース上のアプリケーション・パフォーマンスの平滑化を対象とすることが分かる。しかし、オンデマンド・コンピューティングでは、このスタイルのモニターおよび平滑化は十分ではない。というのは、動的な性質を有するオンデマンド・コンピューティングでは、多種多様なジョブおよびアプリケーションが任意の時間に任意のグリッド・ノード上で実行可能であるからである。たとえば、オンデマンド・グリッド環境で、ある特定の時間にＡＩＸ（商標）ベースのＤＢ２データベース・ジョブ・セッションに参加していたグリッド・ノードは、その直後にＬＩＮＵＸ（商標）のコンパイラ・ジョブを実行する可能性がある。グリッド環境内でリソース使用状況についてこのような急激な変化が発生する見込みがある場合、従来型のツールおよび平滑化分析スタイルは不十分であり、潜在的に関連するジョブ特性を有する複数のジョブについてパフォーマンス・データを収集することができず、まして、そのようなパフォーマンス・データを相関させて分析することはできない。
【００１０】
ジョブの所与の一部を実行可能であるが、所与の時間に使用可能ではない可能性があること、使用可能であるときに所与のジョブの所与の一部について異なるパフォーマンスを示す可能性のある複数のリソースをグリッドが含まれ得ることが、問題をさらに複雑にしている。たとえば、ジョブの所与の一部はＤＢ２を実行するＡＩＸ（商標）またはＬＩＮＵＸ（商標）上で実行することができるが、現行のパフォーマンス・モニター・ツールは、そのジョブのその一部が履歴上、ＡＩＸ（商標）ノード・グループよりＬＩＮＵＸ（商標）ノード・グループの方が（または逆の場合も同様）より高速かつより低コストで実行されていたことを明らかにすることができない。したがって、より効率の良いＬＩＮＵＸ（商標）（またはＡＩＸ（商標））のリソースが所与の実行時間にリクエストされたジョブまたはＲＦＰに対する応答に使用可能ではない可能性がある場合、現行のパフォーマンス・モニター・ツールは、価格設定などを正確に決定するためのメカニズムを提供しない。そのため、同様のジョブのためのリソース選択をグリッド内のＬＩＮＵＸ（商標）（またはＡＩＸ（商標））リソースに偏らせるには、ＩＴマネージメントやスタッフの専門知識または直観によるほかない。
【００１１】
要約すると、２以上の異なるリソースが所与のジョブの特定の一部に使用できる可能性があるときに、最も効果的にそれを実行することができるリソースにジョブの一部を割り振り、そのリソースがそのジョブまたはジョブ一部を処理するのに要すると思われる時間を見積もることができれば有利であろう。しかし、現在の技術水準では、最も効率の良いリソースの可用性の確率を考慮すること、または特定の特性を有するジョブの一部に関するランタイムで実際に使用できる可能性のある任意のリソースの効率に関する高精度の情報を提供することができるツールは存在しない。
【特許文献１】米国特許出願公開２００６−０１５０１５８号
【特許文献２】米国特許出願公開２００６−０１４９６５２号
【特許文献３】米国特許出願公開２００６−０１４９７１４号
【特許文献４】米国特許出願公開２００６−００５９４９２号
【特許文献５】米国特許出願公開２００６−０００５１８１号
【発明の開示】
【発明が解決しようとする課題】
【００１２】
したがって、本発明の目的の１つは、コンピューティング・グリッド全体およびその使用可能なリソースについて、より正確で効率の良い管理を可能にする包括的な履歴統計をモニターし、評価し、アーカイブし、関連グリッド・モジュールに公表するためのシステムおよび方法を提供することにある。
【００１３】
本発明の他の目的は、同様の特性または要件を有し得る異なるジョブに関する履歴データに基づいて個々にサブミットされた各アプリケーションまたはジョブについて最も効率の良いグリッド・リソースの選択を可能にするリソース使用状況の平滑化ならびに将来を考慮した正確な見積もり、評価、および分析をするために、グリッド・コンピューティング環境の全域でノードからのジョブ・パフォーマンス・データを収集し、相関させるためのツールを提供することにある。
【００１４】
本発明の他の目的は、インバウンド・ジョブ・コストの作成または見積もりを改善し、インバウンド・グリッド・ジョブに関するハードウェアおよびソフトウェア・プラットフォーム要件定義を改善し、グリッドに関するＲＦＰの生成のパフォーマンスおよび正確さを向上し、統計的な学習によりグリッド内の効率を改善し、グリッド・エレメントの財務分析用のプラットフォームを提供し、コンピューティング業界トレンド分析のためのプラットフォームを提供するために、データ収集、記憶、および検索をできるようにすることにある。
【００１５】
本発明のさらに他の目的は、上記の諸機能を実行するためのグリッド・モジュールを実現し、それをサポートすることにある。
【課題を解決するための手段】
【００１６】
本発明の上記その他の目的を達成するために、グリッド・コンピューティング環境の各リソースを使用して、データ処理リクエストによるジョブの一部を実行するステップと、各リソースのパフォーマンスおよびジョブの一部の特性に対応する、ジョブの一部を実行する各リソースからのデータ・レコードを定期的に記憶するステップと、そこに記憶されたデータに従って選択済みデータ・レコードを検索するステップと、処理済みパフォーマンス・データを履歴パフォーマンス統計として生成するために、検索されたデータを処理するステップとを含む、グリッド・コンピューティング環境を管理する方法が提供される。
【００１７】
本発明の他の態様によれば、データ処理リクエストの一部を処理する、グリッド・コンピューティング環境の各リソースをモニターするための手段（arrangement）と、対応するモニター対象のそれぞれのリソースを識別するデータとジョブの一部の特性とを含む、モニター対象のリソースからのパフォーマンス・データを定期的に記憶するための内容アドレス記憶装置（content-addressablestorage）と、処理済みパフォーマンス・データを生成するために、このような特性に基づいて、データを検索し処理するための手段と、処理済みパフォーマンス・データに基づいてグリッド・コンピューティング環境を管理するための手段（好ましくはモジュールとして実現される）を含む、グリッド・コンピューティング環境を管理するためのシステムが提供される。
【００１８】
上記その他の目的、態様、および利点は、添付図面に関連して本発明の好ましい一実施形態に関する以下の詳細な説明からより十分に理解されるであろう。
【発明を実施するための最良の形態】
【００１９】
次に添付図面、詳細には図１を参照すると、本発明によるグリッド環境と課金（accounting）および統計管理システム１００からなるシステム・アーキテクチャ全体のブロック図が示されている。当業者であれば、特許文献１の図２および図５のそれぞれに対して図１、図２、および図３の一部が類似していることを理解し、これらの図を比較することによって、本発明によって提供される特許文献１の発明の諸機能に対する改善ならびに追加の機構および機能について正当な評価をすることができるであろう。より具体的には、上記の特許文献１に詳述されている通り、グリッド環境１１０は、グリッド管理システム１２０と仮想リソース１３０とを含む。しかし、本発明のグリッド管理システム１２０は、以下により詳細に論じるように、課金および統計管理システムを含むことによって、実質的に追加の機能を提供する。すなわち、本発明を含む任意のグリッド環境が特許文献１の諸機能のうちのいくつかを提供することができ、その諸機能が本発明を含むことによって大幅に改善できることは好ましいことである。
【００２０】
グリッド環境は、ネットワークその他の配置によりクライアント・システム１０によってアクセス可能であるが、その詳細は本発明の実施にとって重要なものではない。クライアント・システム１０からの通信はグリッド管理システム１２０へのものとして描写されている。グリッド管理システム１２０はプロセッサおよびアプリケーション１４０の割当て（allocation）を管理する。次に、アプリケーション１４０は様々なアクセス可能リソース１５０を使用し、クエリ（query、照会）に対する応答と、クライアント・システムのリクエストに応答するその他の機能を管理する。
【００２１】
本発明の実施形態は、特許文献１に詳述されたグリッド環境１１０に加えて、様々なリソース１５０からデータ・ウェアハウス（複数も可）１６０へのパフォーマンス報告を可能にする。データ・ウェアハウス１６０は、単一のパフォーマンス・データ・リポジトリにするか、または所与のグリッド環境に対する本発明の特定の応用例に最も良く対処できるように分割および／または分散することができる。これは、いわゆる「ミドルウェア」などの任意の既知のネットワーク通信技術により実装することができ、本発明の実施はその詳細に依存しない。クエリに関する最大限の柔軟性と、たとえば、前に実行されたジョブまたは現在実行中のジョブの一部に対する着信ジョブの一部の最適一致（optimal matching）を可能にするために、そこに含まれる任意の特定のデータを基礎としてレコードにアクセスできるようにメモリ１７０ａ、１７０ｂのある種の内容アドレサビリティ（content addressability）を提供することを除いて、データ・ウェアハウスの実装例は同様に本発明の実施にとって重要ではない。データ・ウェアハウスが分割または分散される場合、その一部（同じ（たとえば、二重）分析プロセスおよびアルゴリズム１８０ａ、１８０ｂを含まない可能性がある）は、好ましくはモジュールとして実装されるものであり、可能なクエリのうちのすべてまたは少なくとも最大数を達成できるように相互作用することが許可されるはずであり、そのクエリは特定のアプリケーションおよびリソースに対するすべてのリソースのパフォーマンスに関して任意の複雑さのものになる可能性がある。データ・ウェアハウスの分割または分散が行われる場合、グリッドがどのように複数のセキュリティ・ドメインにわたって分散しているかに基づいてこのように実行することが好ましい。
【００２２】
同じく特許文献１に詳述され、図２（特許文献１の図５に対応する）に例示されている通り、グリッド管理システム１２０は１以上のワークロード・エージェント（複数も可）１２５を含む。このワークロード・エージェントは、好ましくはモジュールとして実施され、リソースの割当て、グリッドの管理、市販のグリッド・サービスに関する価格設定、販売および課金などの様々な所望の機能を実行するために他のモジュールと通信する。好ましい機能を実行するための例示的なモジュールの一般的なアーキテクチャは図２に概略的に示されており、その一部については、既に公開された特許文献２乃至５において詳細に論じられている。
【００２３】
より一般的には、モジュールまたはサブシステムは、ワークロード管理、ソフトウェア／ハードウェア・カタログ管理、課金／請求、価格設定計算、割引管理など、グリッド環境内で具体的な機能を実行するためのグリッド管理システム内のアーキテクチャ・コンポーネントである。たとえば、価格設定計算モジュールは、特定のリソースにおいてグリッド・インフラストラクチャまたは環境内のジョブまたはジョブの一部を実行するための価格を決定する。各モジュールまたはサブシステムは、意図された機能を提供するための方法またはアルゴリズムを実行し、その機能を実行するための「エンジン」としての性質の点で重視される可能性がある。各モジュールまたはサブシステムは、好ましくは、ソフトウェア「オブジェクト」（オブジェクト指向プログラミングにおける意味である）として実施されるが、特殊目的プロセッサというハードウェアにするか、またはハードウェアとソフトウェアの組み合わせにすることもできる。
【００２４】
図３に例示されている通り、本発明の実施形態は、好ましくは、リソースの使用状況に関するリソース割当ておよび課金とは別個に、特定のリソースによる特定のジョブまたはジョブの一部のパフォーマンスに関して課金、統計、および履歴トレンド管理を実行するために配置されたモジュールまたはサブシステムとしても実施され、リソース割当ておよび課金という機能は本発明の使用によって大幅に改良することができる。より具体的には、データ・ウェアハウス１６０内には、好ましくは上記で定義されたモジュールとして、課金、統計、および履歴トレンド管理サブシステム１８０が設けられている。課金および統計管理モジュール１８０は、上述の通り記憶するために個々のグリッド・リソースまたはグリッド・リソース・グループ１５０からのパフォーマンス・データの取得を管理し、大容量記憶装置１７０から、それと通信している複数のグリッド・プロセスおよびアルゴリズム１８５のそれぞれへのデータの転送を管理する。さらに、点線部分を含む図１および図３の１９０に概略的に描写されている通り、課金および統計モジュール１８０は、単独でまたは好ましくはグリッド・ワークロード・エージェント１２５と協力して、前述のグリッド・ワークロード・エージェント１２５に関連するグリッド管理システム・モジュールに対するそれぞれのモジュール１８５による処理の結果の通信を管理する。これらの通信のルーティングは本発明の実施にとって重要ではないが、データの配布が管理されるグリッド・ワークロード・エージェントによるルーティングが好ましい。
【００２５】
課金および統計管理モジュール１８０に関連するモジュール１８５によって実行される特定のプロセスおよびアルゴリズムならびにその詳細は、本発明の実施にとって重要ではない。しかし、特許文献１に開示されている通り、グリッド・ワークロード・エージェント１２５に関連するモジュールを補完し、微細（fine-grained）レベルの具体的なジョブの一部および具体的なリソースで取得された処理済みデータを転送するためのメカニズムを提供するように、いくつかのプロセスおよびアルゴリズムが選択されることが好ましい。このことは、リソース・グループ（またはリソース・グループ全般から区別できない可能性のあるリソース・グループの一部）上で実行されたジョブまたはジョブの一部のグループをひとまとめにして反映できるデータに関する動作とは区別されるものである。たとえば、コスト見積もりモジュール、ハードウェア／ソフトウェア要件モジュール、およびグリッド内プロセス・モジュールによって処理されたパフォーマンス・データは微細データの分析を可能にする。そして、そうすることによって、グリッド管理システム１２０内のグリッド・リソース割当てモジュール、グリッド・マネージャ・モジュール、グリッド価格設定モジュール、ジョブ・ランタイム見積もりモジュール、およびグリッド割引モジュールのパフォーマンスを確かに改良することができる。また、トレンド分析モジュールは、より具体的にジョブの一部に整合され詳細に定義されたクエリに応答して微細データを供給することによって、上述の通り、グリッド・リソースの割当ておよびワークロードの平滑化も強化することができるが、特殊目的機能のためにＲＦＰ生成処理などのその他のモジュールを設けることができ、グリッド・エレメント財務分析は、リソース追加および／またはアップグレードの効果の決定または投影を含む、キャパシティ管理およびそれに関する入力に有用である可能性がある。
【００２６】
次に図４を参照して、本発明によって実行される動作の関係について論じることにする。なお、フローチャートの様相がいくつか含まれている可能性があっても、図４は厳密なフローチャートになるよう意図されているわけではないことを理解されたい。例示されている動作を通るいくつかのパスは、少なくとも以下に示す好ましいハイレベル機能（図３に例示されているモジュールに対応する）をサポートするようにパフォーマンス・データが収集され、記憶され、検索されることを保証するために、実質的に並列にしかも再帰的な手法で実行することができる。
１）インバウンド・ジョブ・コスト作成または見積もりの改良
２）インバウンド・グリッド・ジョブに関するハードウェアおよびソフトウェア・プラットフォーム要件定義の改良
３）グリッドＲＦＰ処理のパフォーマンスおよび正確さの強化
４）統計的学習によるグリッド内処理の改善
５）グリッド・エレメントの財務分析のためのプラットフォームの提供
６）コンピューティング業界トレンド分析のためのプラットフォームの提供
【００２７】
本発明の好ましい動作モードで実行される初期動作は、２０２に示されている通り、グリッド管理システム１２０がグリッド（たとえば、個々のアプリケーション環境ならびにそれぞれの接続リソース）１４０のプロセッサおよびアプリケーションに問い合わせて、現在実行中のジョブおよびスケジュールされたジョブを決定することである。このステップは、効率の悪いグリッド管理によってパフォーマンス・データが偏らないようにグリッドの継続的管理（on-going management）を適切に処理できることと、継続的にグリッドから使用可能なものになっている所望のパフォーマンス・データが認識され収集されることを保証するために重要である。現在実行中のジョブおよびスケジュールされたジョブならびにそのそれぞれの一部が識別されると、２０４に示されている通り、個々のアプリケーション環境１４０の現在の瞬間動作のパフォーマンス「スナップショット」が定期的に撮られ記憶される。このステップは、ジョブの完了時または所定の数のスナップショット後にスナップショット・データをアーカイブするためにステップ２２６と相互作用し、リアルタイムでまたは定期的に同じグリッド上または他のグリッド上の他の関連管理サブシステムにデータを転送するためにステップ２２２と相互作用する。
【００２８】
しかし、上記で列挙された例示的なハイレベル機能のほとんどは主に着信ジョブのグリッド動作に対する効果および／またはそのジョブがどのように実行されるかに関する現行グリッド状態の効果の投影（projection）と、どのくらいの時間を要するかという見積もりに関連するので、本発明によるパフォーマンス・データ収集プロセスは、２０６に示されている通り、新しい着信グリッド・コンピューティング・ジョブの入力およびスケジューリングを続ける。その後、２０８に示されている通り、グリッド管理システムは、更新が行われたことをワークロード・エージェント（複数も可）１２５に通知する。応答として、ワークロード・エージェント（複数も可）および／または課金および統計管理モジュール１８０は、２１０に示されている通り、着信ジョブの特性または着信ジョブのそれぞれの一部の特性の組み合わせに対応するジョブ・パフォーマンス・データを収集する。
【００２９】
次に、２１２に示されている通り、新しいジョブまたは着信ジョブあるいはその一部がアプリケーション固有のものであるかどうかが判断される。アプリケーション固有のものである場合、２１６に示されている通り、ジョブまたはそのそれぞれの一部を実行するための適切なアプリケーション環境１４０に問い合わせるか、または現行ワークロード統計について現行スナップショットが読み取られる。アプリケーション固有のものではない場合、一般に、グリッド環境を構成するすべてのアプリケーション環境１４０にわたって本質的に同じ動作が実行される。いずれの場合も、グリッドに対するジョブ・サブミッションの影響を見積もるために予測分析２１８が実行され、予測パフォーマンス番号および関連の予定表が生成されて報告され（２２０）、他の接続グリッド管理サブシステムまたはモジュールに送信され（２２２）、記憶される（２２４）。そして、その結果、ジョブ影響予測の改良をサポートするために、決定され定量化された後で、実際のジョブ影響と予測データを比較することができ、または逆に、特にグリッド・アーキテクチャおよびその他のありそうな同時グリッド処理に関して所与の履歴パフォーマンス統計内にジョブ・ランタイムを実行できる見込みを予測する。この場合も、２２６で、ジョブ完了時にまたは定期的に、結果の予測データがアーカイブされ、同時実パフォーマンス・データは２０４で収集され、上述の通り、アーカイブされる。
【００３０】
上述のステップ２２２は、予測データと、２０４で収集されたデータを、２３０に示されている通り、実質的にリアルタイムで関連サブシステムに提供する。これらのサブシステムは、２２６から得られるアーカイブ・データにもアクセスすることができる。これらのサブシステムまたはモジュールは、リソース割当て、グリッド管理、グリッド処理割引決定、アイドル・リソース時間の売却、価格設定分析および決定を含むがこれらに限定されない、それぞれのタイプの分析および制御機能を実行する。これらの機能は、上記のように、任意のその他のパフォーマンス・データまたはパラメータあるいはその論理（たとえば、ブール）結合に基づいて任意のパフォーマンス・データまたはパラメータを検索するために非常に柔軟に定義され、任意に複雑なものにすることができるクエリに応答するためにデータ・ウェアハウス１６０およびそこに設けられた内容アドレス・メモリの機能によって実行される特定の分析に関して非常に柔軟なものにすることができる。
【００３１】
次に図５を参照すると、クエリ深度（query depth）を増すことによるパフォーマンス予測の改善が描写されている。この場合、データの行数またはライン数をカウントするのに要する時間がパフォーマンスの標識として使用されている。異なるジョブとおそらく異なるアプリケーション環境からのパフォーマンス・データに関する２つのサンプルという低クエリ深度の場合、小規模外挿（extrapolation）のために、結果的に４５秒で４０００行がカウントされるという予測すなわち１．１２５ミリ秒／行という予測が行われる。しかし、６通りの履歴パフォーマンス統計の場合、正確さおよび信頼性を増して、より大規模な外挿を行うことができる。このような分析が、たとえば、特定のプラットフォームによるソートを含む場合、所与のジョブまたはその一部について最も効率の良いプラットフォームを容易に決定することができる。同様に、適度なクエリ深度は、特定のまたは履歴的にありそうな同時グリッド処理および／またはグリッド・アーキテクチャの環境内の所与の履歴パフォーマンス統計内に所与のジョブまたはジョブの一部のランタイムを完了できる見込みを予測するための基礎を提供することができる。上記で論じたように柔軟で任意に複雑なクエリ（照会）を行う能力により、すべての着信ジョブを迅速に分析することもできる。そして、各一部のパフォーマンスの見積もり（任意に微細な細分性を有する）は、特に、ジョブ価格設定の正確さの改善、ＲＦＰ作成、最も効率がよい使用可能なリソースの選択の改善、およびリクエストされたジョブに必要なグリッド・リソースの必要量の見積もりのために、前のジョブから前に収集したデータと一致させることができる。
【００３２】
クエリ深度は、潜在的に、図５の単純な例のように特定のパフォーマンス基準については非常に急速に増加することが分かるであろう。たとえば、図５の高クエリ深度の列の最初の２つの項目は、低クエリ深度の列の２つだけの項目と同じであることに留意されたい。また、どちらの項目も、高クエリ深度データから見積もられたパフォーマンス時間よりかなり遅いパフォーマンスを示すとともに、行スキャン数が増えるほど時間が長くなる傾向を示すことにも留意されたい。したがって、クエリ深度が高くてもこのようなデータ項目によってパフォーマンス見積もりがいくらか偏る可能性がある。また、この例のため、クエリは単に集合ＤＢ２行スキャン時間（aggregate DB2 row scan time）を含むすべてのパフォーマンス・データに関するものであったと想定される。
【００３３】
しかし、各ジョブの追加の基準および特性に関連するパフォーマンス・データを収集すると、非常に具体的で任意に複雑なクエリを実行することができ、任意に小さな着信ジョブの一部の特性およびハードウェア／ソフトウェア要件を収集した実際のパフォーマンス・データと非常に厳密に一致させることができる。そうすることによって、最初の２つの項目のうちの一方または両方がより複雑で詳細なクエリで廃棄される可能性があるが、依然として相当なクエリ深度が維持され、データが蓄積される。そして、そのデータはより詳細で複雑なクエリでは比較的遅い速度で検出されるであろう。それにもかかわらず、着信ジョブの一部と前に実行されたジョブの一部との特性の一致の厳密さが改善されると、ジョブ・パフォーマンスの予測の正確さが増し、大規模外挿を行わなければならない場合でも信頼性のレベルが上がるが、予測処理で考慮されるデータの量が低減されると応答時間が削減され、異なるリソースを使用する処理に関する分析の比較が可能になる。したがって、ランタイムの偶然性（run time contingency）に対する信頼性および対処も改善された収益性マージン（profitability margin）を維持するように、そのリソースについて、より効果的に割当ておよび価格設定を行うことができる。
【００３４】
したがって、上記を考慮すると、本発明は、効率が改善されたグリッド管理をサポートして、包括的統計をモニターし、アーカイブし、関連グリッド・モジュールに公表するための包括的システムおよび方法を提供することが分かる。また、本発明は、特にグリッド活動およびパフォーマンス、ＲＦＰおよびリソース使用状況、グリッド・エレメントの財務分析、トレンド分析などに対するインバウンド・ジョブの影響に関する履歴データに基づいて特定のリソースに関するリクエストの平滑化および効率の良い割当てをより正確かつ効果的にサポートするために、グリッド環境全域でそれぞれのノードによって実行された個々のジョブの一部に対応するジョブ・パフォーマンス統計を収集し、任意で相関させるためのツールを提供する。
【００３５】
以上、１つの好ましい実施形態に関して本発明を説明してきたが、当業者であれば、特許請求の範囲の精神および範囲内の変更を行っても本発明を実施できることを理解するであろう。
【図面の簡単な説明】
【００３６】
【図１】本発明の実施形態によるパフォーマンス報告のためのグリッド・システム・アーキテクチャのブロック図の概要である。
【図２】複数のグリッド・モジュールを有する図１のグリッド管理システム内のグリッド・ワークロード・エージェントの相互作用を例示する図である。
【図３】本発明の実施形態による課金および統計管理モジュールと複数の課金および統計モジュールとの相互作用と、図２のそれに関連するワークロード・エージェントおよびモジュールによる相互作用とを例示する図である。
【図４】分析ツールなどを提供する様々なモジュールとの相互作用およびそのモジュールの相互作用を含む、本発明の実施形態の動作を例示するフローチャート類似の図である。
【図５】パフォーマンス・データの異なる深さについて、本発明の実施形態によりジョブの一部を分析する動作を例示する図である。
【符号の説明】
【００３７】
１０：クライアント・システム
１００：課金および統計管理システム
１１０：グリッド環境
１２０：グリッド管理システム
１３０：仮想リソース
１４０：アプリケーション
１５０：リソース
１６０：データ・ウェアハウス
１７０ａ：メモリ
１７０ｂ：メモリ
１８０ａ：分析プロセスおよびアルゴリズム
１８０ｂ：分析プロセスおよびアルゴリズム
１８５：グリッド判断
【図１】
0005782212.tif 000002
【図２】
0005782212.tif 000003
【図３】
0005782212.tif 000004
【図４】
0005782212.tif 000005
【図５】
0005782212.tif 000006