図面 (/)

技術 グリッド・コンピューティング環境を管理するための方法、システムおよびプログラム

出願人 インターナショナル・ビジネス・マシーンズ・コーポレーション
発明者 ジェームス・ウィズリー・シーマンリック・アレン・ハミルトンIIジョシー・ジョセフクリストファー・ジェームス・ドーソン
出願日 2006年10月2日 (13年0ヶ月経過) 出願番号 2006-270476
公開日 2007年4月19日 (12年5ヶ月経過) 公開番号 2007-102789
状態 特許登録済
技術分野 マルチプログラミング
主要キーワード 接続グリッド 関連サブシステム パフォーマンス予測 モニター対象 グリッド処理 関連履歴 グリッド管 データ収集ツール
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2007年4月19日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (6)

課題

グリッドコンピューティング環境を管理するための方法およびシステムを提供する。

解決手段

パフォーマンス・データは、グリッド・コンピューティング環境内のリソースおよびリソース・グループから定期的に収集され、内容アドレス・データ・リポジトリに記憶され、特定のジョブまたはジョブ部分の詳細、使用される特定のリソース、グリッド・アーキテクチャアプリケーション環境、同時ジョブまたはジョブ部分などに関して任意に複雑な照会応答してそのデータ・リポジトリからそのパフォーマンス・データにアクセスすることができる。データ・リポジトリは、グリッド環境アーキテクチャ、セキュリティドメインなどに関して分散または分割することができる。各部分または区分は、課金および統計管理モジュールなどを含むモジュール方式実装するか、または特定の所望の分析または機能を実行するための計算エンジンにすることができる。

概要

背景

データ・プロセッサ間通信リンクが、通信または一部のデータ・プロセッサ上でのみ使用可能なリソース共用するために設けられることがある。後者の場合、リソースを有するデータ・プロセッサは一般にサーバと呼ばれ、リソースをリクエストするデータ・プロセッサは一般にクライアントと呼ばれる。ローカルエリアネットワーク(LAN:local area network)、広域ネットワークWAN:wide area network)、その他のネットワーク内の仮想ネットワークインターネットのようなネットワーク配置において多くのデータ・プロセッサ間で通信を行うことができる。

リソースの共用がより普及し、高性能なものになるにつれて、所与のデータ・プロセッサから離れた位置でデータ処理を実行することが一般的になっている。潜在的な利益(gain)を予測し、定量的見積もりを行うことは困難であったが、応答時間およびプロセッサの使用状況に関する効率および改善は、リソースの共用によって達成することができる。また、単一のデータ・プロセッサの計算能力を増加させていわゆるスーパコンピュータ構築するより、複数の接続されたデータ・プロセッサによりデータ処理を分散することによって計算能力を増加させる方が、多くの場合、より有利であることも分かっている。さらに、リモート・データ処理がずっと一般的なものになっている環境では、サーバ・システムのサイズ、速度、および計算能力は継続的に増加し続け、クラスタ化マルチサーバ共用データシスプレックス(sysplex))およびグリッド環境エンタープライズ・システムなど、複数のサーバをグループ化する複数の方法が開発されている。複数のサーバのクラスタその他の配置では、増加し続ける着信リクエストを管理するためにサーバが指定され、他のサーバはクライアントからそれぞれのリクエストの分散された一部を処理するために並列に動作する。典型的には、サーバおよびサーバ・グループは、アプリケーションを実行するための分散ホスティング環境を提供するために、UNIX(商標)やその亜種などの特定のプラットフォーム上で動作する。各ネットワーク・プラットフォームは、様々な機能ならびに種々の実装形態セマンティック動作(semantic behavior)、およびアプリケーション・プログラミングインターフェースAPI:applicationprogramming interface)を提供することができる。

しかし、複数のデータ・プロセッサを単に相互接続しても、効率または応答速度の増加が保証されるわけではない。ベストの状況における実行能力は制限されてしまっているのである。種々のリソースはセキュリティメンバシップなどを処理するための同様の機能を有する場合もある。逆に、リソースが同じ管理システムの対象にならない場合、コラボレーションデータ共用サイクル分割、その他のサーバ間対話を可能な範囲で増加することができる1つの分散リソースとして複数のサーバおよびサーバ・グループを編成することにより、効率および応答速度についてある程度の改善が達成されてきた。たとえば、ある会社のサーバ・クラスタを管理する管理システムは、典型的には、同じネットワーク上にあり得るデスクトップパーソナルコンピュータ上で使用可能なリソースを管理の対象とせず、また、ある会社内の異なる管理グループは、異なる管理システムを実施する複数のサーバ・グループを有することができる。

異なるセキュリティ・ポリシーを有し、異なるプラットフォーム上で動作する別々の管理システムによって発生する問題に対処するため、異種および分散リソースの最大限の共用および協調的な使用をサポートするようなグリッド環境を実現する、オープンスタンダードを使用したいわゆるグリッド技術が開発された。異なるセキュリティおよびアクセス・ポリシーと管理システムを有する異なる編成によって異なるシステム(おそらく、それは分散システムであろう)が運用される場合、システムが選択したリソースがジョブ・リクエストを処理するために編成されると、グリッド環境内仮想編成が作成される。

しかし、グリッド技術は、異なる管理システムおよび異なる標準を有する複数のリソース・グループ間のすべての通信問題を解決するわけではない。たとえば、各システム・グループのパフォーマンスモニターするために現在配置されているツールおよびシステムは、特定のリソースのハードウェア・タイプに応じてリソースをグループ化し、ハードウェア・レベルでパフォーマンスをモニターするという点で制限されている。また、このようにしてリソースをグループ化した結果として、このようなモニター・ツールおよびシステムは、ハードウェア・リソース上に実装されたプロトコルの使用に制限され、したがって、典型的には、異なるグループまたは異なる管理システムあるいはその両方のモニター・ツールおよびシステム同士直接通信をサポートしない。したがって、任意の時間にグリッド活動をモニターすることでさえ困難なことである(ただし、特許文献1には、グリッド制御機能を実行するためにそこからのデータが様々なモジュールに供給されるグリッド活動データベースを維持し、それにデータを追加するために、グリッド・ワークロードエージェントを使用して、指定されたモニター・ルールまたは適応可能に生成されたモニター・ルールによりグリッド・モジュールに照会するという解決策が示されている)。まして、1つのデータ処理ジョブの一部を割り振ることや、価格設定、ハードウェアおよびソフトウェア要件定義の改良、提案要求(RFP:request for proposal)処理の正確さおよびパフォーマンスの強化(たとえば、サービス・レベル・アグリーメント遵守および達成の改善に至るランタイム見積もりの改善)、前のパフォーマンス統計および現在のパフォーマンス見積もりに基づいてリソース割当ての効率を改善するかあるいはグリッド・エレメント財務分析またはコンピューティング業界トレンドをサポートすることによるグリッド内処理効率の増強など、商用グリッドコンピューティング動作のその他の必要な活動をサポートすることも困難なことである。このような目的のための堅固な業界ツールであって、オンデマンド・グリッド・コンピューティング環境要件に対処できるものは、現在、存在していない。

現在の技術水準では、グリッド・コンピューティングは、単一編成(single organization)のコンピューティング環境で実施されているものとほぼ同じ方法を使用して管理されている。すなわち、情報技術(IT)のマネージメント(管理職)やスタッフは、一般に、潜在的なインバウンド・ジョブを論じ、それぞれの蓄積した専門知識(これは、極めて変じやすいものであり、しかも多くの場合、経験的データを伴わない可能性があるものである)からのベストの見積もりに基づいて、コンピューティング・リソース要件および関連コスト(一般に、より精度・粒度が高いかまたは特定の価格設定モデルをサポートするためのメカニズムが存在しないので、固定毎時コストである)を作成する。パフォーマンス・データはグリッド上で収集することができるが、複数の関連ジョブまたは評価のために他のジョブと相関させた同様の特性を有する複数のジョブからのジョブ・データがなければ、このようなパフォーマンス・データは、正確なジョブ・ランタイムおよび価格設定の見積もりを作成するときに有用なものとならない。

たとえば、従来型のコンピューティング環境では、DB2(商標)などの単一アプリケーションは、1つの特定のノードまたはノード・セット上で実行することができる。パフォーマンス・モニターは、このようなノードから定期的にデータをサンプリングし、ピーク・ワークロード・トレンドなどの事実を決定することができる。しかし、グリッド環境では、1つのノードがいくつかの異なるアプリケーションを実行することができ、そのそれぞれが任意の期間にジョブの一部を処理することができる。よって、グリッド全体に関する包括的なデータがない場合、任意のノードのハードウェアに関する単純な生のパフォーマンス・データは特定の特性を有する特定のジョブに関して無意味である。また、たとえ収集可能であっても、複数のノードに関するデータは評価中の着信ジョブ(incoming job)と相関させることができない。というのは、任意の期間の各ノードのパフォーマンスは、各ノードのハードウェア上で実行される多様な要件および特性を有する複数のジョブに関連する可能性があるからである。

問題は、オンデマンド・コンピューティングの動的な性質によって複雑になっている。現在の従来型パフォーマンス・データ収集ツールは、多くの場合、トレンド分析に基づいてワークロードを平滑化できるようなトレンド作成以上のものを可能にすることはほとんどない。たとえば、クライアントのDB2データベース(サーバ)ノードは、定期的に繰り返すある期間中は一貫して過負荷(overworked)になり、他の期間中は一貫して過少負荷(underworked)になる場合、いくつかのバッチ処理ジョブを前者の期間から後者の期間に移動することができる。このスタイルのモニターおよび平滑化は、それらが実行される割当て済み静的リソース上のアプリケーション・パフォーマンスの平滑化を対象とすることが分かる。しかし、オンデマンド・コンピューティングでは、このスタイルのモニターおよび平滑化は十分ではない。というのは、動的な性質を有するオンデマンド・コンピューティングでは、多種多様なジョブおよびアプリケーションが任意の時間に任意のグリッド・ノード上で実行可能であるからである。たとえば、オンデマンド・グリッド環境で、ある特定の時間にAIX(商標)ベースのDB2データベース・ジョブ・セッションに参加していたグリッド・ノードは、その直後にLINUX(商標)のコンパイラ・ジョブを実行する可能性がある。グリッド環境内でリソース使用状況についてこのような急激な変化が発生する見込みがある場合、従来型のツールおよび平滑化分析スタイルは不十分であり、潜在的に関連するジョブ特性を有する複数のジョブについてパフォーマンス・データを収集することができず、まして、そのようなパフォーマンス・データを相関させて分析することはできない。

ジョブの所与の一部を実行可能であるが、所与の時間に使用可能ではない可能性があること、使用可能であるときに所与のジョブの所与の一部について異なるパフォーマンスを示す可能性のある複数のリソースをグリッドが含まれ得ることが、問題をさらに複雑にしている。たとえば、ジョブの所与の一部はDB2を実行するAIX(商標)またはLINUX(商標)上で実行することができるが、現行のパフォーマンス・モニター・ツールは、そのジョブのその一部が履歴上、AIX(商標)ノード・グループよりLINUX(商標)ノード・グループの方が(または逆の場合も同様)より高速かつより低コストで実行されていたことを明らかにすることができない。したがって、より効率の良いLINUX(商標)(またはAIX(商標))のリソースが所与の実行時間にリクエストされたジョブまたはRFPに対する応答に使用可能ではない可能性がある場合、現行のパフォーマンス・モニター・ツールは、価格設定などを正確に決定するためのメカニズムを提供しない。そのため、同様のジョブのためのリソース選択をグリッド内のLINUX(商標)(またはAIX(商標))リソースに偏らせるには、ITマネージメントやスタッフの専門知識または直観によるほかない。

要約すると、2以上の異なるリソースが所与のジョブの特定の一部に使用できる可能性があるときに、最も効果的にそれを実行することができるリソースにジョブの一部を割り振り、そのリソースがそのジョブまたはジョブ一部を処理するのに要すると思われる時間を見積もることができれば有利であろう。しかし、現在の技術水準では、最も効率の良いリソースの可用性の確率を考慮すること、または特定の特性を有するジョブの一部に関するランタイムで実際に使用できる可能性のある任意のリソースの効率に関する高精度の情報を提供することができるツールは存在しない。
米国特許出願公開2006−0150158号
米国特許出願公開2006−0149652号
米国特許出願公開2006−0149714号
米国特許出願公開2006−0059492号
米国特許出願公開2006−0005181号

概要

グリッド・コンピューティング環境を管理するための方法およびシステムを提供する。パフォーマンス・データは、グリッド・コンピューティング環境内のリソースおよびリソース・グループから定期的に収集され、内容アドレス・データ・リポジトリに記憶され、特定のジョブまたはジョブ部分の詳細、使用される特定のリソース、グリッド・アーキテクチャアプリケーション環境、同時ジョブまたはジョブ部分などに関して任意に複雑な照会に応答してそのデータ・リポジトリからそのパフォーマンス・データにアクセスすることができる。データ・リポジトリは、グリッド環境アーキテクチャ、セキュリティ・ドメインなどに関して分散または分割することができる。各部分または区分は、課金および統計管理モジュールなどを含むモジュール方式で実装するか、または特定の所望の分析または機能を実行するための計算エンジンにすることができる。

目的

したがって、本発明の目的の1つは、コンピューティング・グリッド全体およびその使用可能なリソースについて、より正確で効率の良い管理を可能にする包括的な履歴統計をモニターし、評価し、アーカイブし、関連グリッド・モジュールに公表するためのシステムおよび方法を提供することにある。

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

グリッドコンピューティング環境を管理する方法であって、前記グリッド・コンピューティング環境の各リソースを使用して、データ処理リクエストによるジョブの一部を実行するステップと、前記各リソースのパフォーマンスおよび前記ジョブの一部の特性に対応する、前記ジョブの一部を実行する各リソースからのデータ・レコードを定期的に記憶するステップと、前記データ・レコードに記憶されたデータに従って、選択済みデータ・レコードを検索するステップと、処理済みパフォーマンス・データを履歴パフォーマンス統計として生成するために、前記検索ステップで検索されたデータ・レコードを処理するステップと、を含む方法。

請求項2

前記処理済みパフォーマンス・データに基づいてジョブの一部の割当てを管理するステップをさらに含む、請求項1に記載の方法。

請求項3

履歴パフォーマンス分析に基づいて前記グリッド上のジョブ・ランタイム見積もるステップをさらに含む、請求項1に記載の方法。

請求項4

履歴パフォーマンス分析に基づいて提案要求を生成するステップをさらに含む、請求項1に記載の方法。

請求項5

関連履歴パフォーマンス統計内にジョブ・ランタイムを実行できる見込みを判断するステップをさらに含む、請求項3に記載の方法。

請求項6

データ・レコードを定期的に記憶する前記ステップが、データ・レコードをデータ・リポジトリに記憶することを含む、請求項1に記載の方法。

請求項7

前記データ・リポジトリを複数の分散データ・リポジトリに分割するステップをさらに含む、請求項6に記載の方法。

請求項8

前記データ・リポジトリを分割する前記ステップが、前記グリッド・コンピューティング環境が複数のセキュリティドメインにわたってどのように分散しているかに基づくものである、請求項7に記載の方法。

請求項9

データ処理リクエストの一部を実行する前記ステップが、前記データ処理リクエストの一部がアプリケーション固有のものであるかどうかを判断するステップを含む、請求項1に記載の方法。

請求項10

前記データ処理リクエストの一部がアプリケーション固有のものであるかどうかを判断する前記ステップの結果に基づいて、前記グリッドに問い合わせるかまたは前記グリッドのアプリケーション環境に問い合わせるステップをさらに含む、請求項9に記載の方法。

請求項11

グリッド・コンピューティング環境を管理するためのシステムであって、データ処理リクエストのジョブの一部を処理する、前記グリッド・コンピューティング環境の各リソースをモニターするための手段と、対応するモニター対象の各リソースを識別するデータと前記ジョブの一部の特性とを含む、前記モニター手段によってモニターされた各リソースからのパフォーマンス・データを定期的に記憶するための内容アドレス記憶手段と、処理済みパフォーマンス・データを生成するために、前記内容アドレス記憶手段によって記憶されたデータを前記特性に基づいて検索し処理するための手段と、前記処理済みパフォーマンス・データに基づいて前記グリッド・コンピューティング環境を管理するための手段と、を含むシステム。

請求項12

前記グリッド・コンピューティング環境を管理するための手段が、コスト見積もりハードウェアソフトウェア要件の決定、RFP処理、グリッド内プロセスの決定、グリッド・エレメント財務データ分析、および履歴トレンド分析のうちの少なくとも1つを含む、それぞれのグリッド環境管理機能を実行するための複数のモジュールを含む、請求項11に記載のシステム。

請求項13

前記グリッド・コンピューティング環境を管理するための手段が、グリッド環境管理機能を実行するためのモジュールを含む、請求項11に記載のシステム。

請求項14

前記データを検索し処理するための手段が、課金および統計管理モジュールを含む、請求項11に記載のシステム。

請求項15

グリッド・ワークロードエージェントをさらに含み、前記課金および統計管理モジュールが前記処理済みパフォーマンス・データを前記グリッド・ワークロード・エージェントに提供する、請求項14に記載のシステム。

請求項16

前記グリッド・ワークロード・エージェントに関連する機能を実行するために前記グリッド・ワークロード・エージェントに関連する機能モジュールをさらに含み、前記課金および統計管理モジュールが前記処理済みパフォーマンス・データを前記機能モジュールに提供する、請求項15に記載のシステム。

請求項17

グリッド・コンピューティング環境を管理するためのプログラムであって、コンピュータ・システムに、前記グリッド・コンピューティング環境の各リソースを使用して、データ処理リクエストによるジョブの一部を実行するステップと、前記各リソースのパフォーマンスおよび前記ジョブの一部の特性に対応する、前記ジョブの一部を実行する各リソースからのデータ・レコードを定期的に記憶するステップと、前記データ・レコードに記憶されたデータに従って、選択済みデータ・レコードを検索するステップと、処理済みパフォーマンス・データを履歴パフォーマンス統計として生成するために、前記検索ステップで検索されたデータ・レコードを処理するステップと、を実行させる、プログラム。

技術分野

0001

本発明は、一般に、グリッドコンピューティング環境に関する。より詳細には、本発明は、グリッド・コンピューティング環境で使用可能なリソースパフォーマンスを効果的に使用し、予測するためのグリッド・リソース使用状況のパフォーマンス・ベースの管理に関する。

背景技術

0002

データ・プロセッサ間通信リンクが、通信または一部のデータ・プロセッサ上でのみ使用可能なリソースを共用するために設けられることがある。後者の場合、リソースを有するデータ・プロセッサは一般にサーバと呼ばれ、リソースをリクエストするデータ・プロセッサは一般にクライアントと呼ばれる。ローカルエリアネットワーク(LAN:local area network)、広域ネットワークWAN:wide area network)、その他のネットワーク内の仮想ネットワークインターネットのようなネットワーク配置において多くのデータ・プロセッサ間で通信を行うことができる。

0003

リソースの共用がより普及し、高性能なものになるにつれて、所与のデータ・プロセッサから離れた位置でデータ処理を実行することが一般的になっている。潜在的な利益(gain)を予測し、定量的見積もりを行うことは困難であったが、応答時間およびプロセッサの使用状況に関する効率および改善は、リソースの共用によって達成することができる。また、単一のデータ・プロセッサの計算能力を増加させていわゆるスーパコンピュータ構築するより、複数の接続されたデータ・プロセッサによりデータ処理を分散することによって計算能力を増加させる方が、多くの場合、より有利であることも分かっている。さらに、リモート・データ処理がずっと一般的なものになっている環境では、サーバ・システムのサイズ、速度、および計算能力は継続的に増加し続け、クラスタ化マルチサーバ共用データシスプレックス(sysplex))およびグリッド環境エンタープライズ・システムなど、複数のサーバをグループ化する複数の方法が開発されている。複数のサーバのクラスタその他の配置では、増加し続ける着信リクエストを管理するためにサーバが指定され、他のサーバはクライアントからそれぞれのリクエストの分散された一部を処理するために並列に動作する。典型的には、サーバおよびサーバ・グループは、アプリケーションを実行するための分散ホスティング環境を提供するために、UNIX(商標)やその亜種などの特定のプラットフォーム上で動作する。各ネットワーク・プラットフォームは、様々な機能ならびに種々の実装形態セマンティック動作(semantic behavior)、およびアプリケーション・プログラミングインターフェースAPI:applicationprogramming interface)を提供することができる。

0004

しかし、複数のデータ・プロセッサを単に相互接続しても、効率または応答速度の増加が保証されるわけではない。ベストの状況における実行能力は制限されてしまっているのである。種々のリソースはセキュリティメンバシップなどを処理するための同様の機能を有する場合もある。逆に、リソースが同じ管理システムの対象にならない場合、コラボレーションデータ共用サイクル分割、その他のサーバ間対話を可能な範囲で増加することができる1つの分散リソースとして複数のサーバおよびサーバ・グループを編成することにより、効率および応答速度についてある程度の改善が達成されてきた。たとえば、ある会社のサーバ・クラスタを管理する管理システムは、典型的には、同じネットワーク上にあり得るデスクトップパーソナルコンピュータ上で使用可能なリソースを管理の対象とせず、また、ある会社内の異なる管理グループは、異なる管理システムを実施する複数のサーバ・グループを有することができる。

0005

異なるセキュリティ・ポリシーを有し、異なるプラットフォーム上で動作する別々の管理システムによって発生する問題に対処するため、異種および分散リソースの最大限の共用および協調的な使用をサポートするようなグリッド環境を実現する、オープンスタンダードを使用したいわゆるグリッド技術が開発された。異なるセキュリティおよびアクセス・ポリシーと管理システムを有する異なる編成によって異なるシステム(おそらく、それは分散システムであろう)が運用される場合、システムが選択したリソースがジョブ・リクエストを処理するために編成されると、グリッド環境内仮想編成が作成される。

0006

しかし、グリッド技術は、異なる管理システムおよび異なる標準を有する複数のリソース・グループ間のすべての通信問題を解決するわけではない。たとえば、各システム・グループのパフォーマンスをモニターするために現在配置されているツールおよびシステムは、特定のリソースのハードウェア・タイプに応じてリソースをグループ化し、ハードウェア・レベルでパフォーマンスをモニターするという点で制限されている。また、このようにしてリソースをグループ化した結果として、このようなモニター・ツールおよびシステムは、ハードウェア・リソース上に実装されたプロトコルの使用に制限され、したがって、典型的には、異なるグループまたは異なる管理システムあるいはその両方のモニター・ツールおよびシステム同士直接通信をサポートしない。したがって、任意の時間にグリッド活動をモニターすることでさえ困難なことである(ただし、特許文献1には、グリッド制御機能を実行するためにそこからのデータが様々なモジュールに供給されるグリッド活動データベースを維持し、それにデータを追加するために、グリッド・ワークロードエージェントを使用して、指定されたモニター・ルールまたは適応可能に生成されたモニター・ルールによりグリッド・モジュールに照会するという解決策が示されている)。まして、1つのデータ処理ジョブの一部を割り振ることや、価格設定、ハードウェアおよびソフトウェア要件定義の改良、提案要求(RFP:request for proposal)処理の正確さおよびパフォーマンスの強化(たとえば、サービス・レベル・アグリーメント遵守および達成の改善に至るランタイム見積もりの改善)、前のパフォーマンス統計および現在のパフォーマンス見積もりに基づいてリソース割当ての効率を改善するかあるいはグリッド・エレメント財務分析またはコンピューティング業界トレンドをサポートすることによるグリッド内処理効率の増強など、商用グリッドコンピューティング動作のその他の必要な活動をサポートすることも困難なことである。このような目的のための堅固な業界ツールであって、オンデマンド・グリッド・コンピューティング環境の要件に対処できるものは、現在、存在していない。

0007

現在の技術水準では、グリッド・コンピューティングは、単一編成(single organization)のコンピューティング環境で実施されているものとほぼ同じ方法を使用して管理されている。すなわち、情報技術(IT)のマネージメント(管理職)やスタッフは、一般に、潜在的なインバウンド・ジョブを論じ、それぞれの蓄積した専門知識(これは、極めて変じやすいものであり、しかも多くの場合、経験的データを伴わない可能性があるものである)からのベストの見積もりに基づいて、コンピューティング・リソース要件および関連コスト(一般に、より精度・粒度が高いかまたは特定の価格設定モデルをサポートするためのメカニズムが存在しないので、固定毎時コストである)を作成する。パフォーマンス・データはグリッド上で収集することができるが、複数の関連ジョブまたは評価のために他のジョブと相関させた同様の特性を有する複数のジョブからのジョブ・データがなければ、このようなパフォーマンス・データは、正確なジョブ・ランタイムおよび価格設定の見積もりを作成するときに有用なものとならない。

0008

たとえば、従来型のコンピューティング環境では、DB2(商標)などの単一アプリケーションは、1つの特定のノードまたはノード・セット上で実行することができる。パフォーマンス・モニターは、このようなノードから定期的にデータをサンプリングし、ピーク・ワークロード・トレンドなどの事実を決定することができる。しかし、グリッド環境では、1つのノードがいくつかの異なるアプリケーションを実行することができ、そのそれぞれが任意の期間にジョブの一部を処理することができる。よって、グリッド全体に関する包括的なデータがない場合、任意のノードのハードウェアに関する単純な生のパフォーマンス・データは特定の特性を有する特定のジョブに関して無意味である。また、たとえ収集可能であっても、複数のノードに関するデータは評価中の着信ジョブ(incoming job)と相関させることができない。というのは、任意の期間の各ノードのパフォーマンスは、各ノードのハードウェア上で実行される多様な要件および特性を有する複数のジョブに関連する可能性があるからである。

0009

問題は、オンデマンド・コンピューティングの動的な性質によって複雑になっている。現在の従来型パフォーマンス・データ収集ツールは、多くの場合、トレンド分析に基づいてワークロードを平滑化できるようなトレンド作成以上のものを可能にすることはほとんどない。たとえば、クライアントのDB2データベース(サーバ)ノードは、定期的に繰り返すある期間中は一貫して過負荷(overworked)になり、他の期間中は一貫して過少負荷(underworked)になる場合、いくつかのバッチ処理ジョブを前者の期間から後者の期間に移動することができる。このスタイルのモニターおよび平滑化は、それらが実行される割当て済み静的リソース上のアプリケーション・パフォーマンスの平滑化を対象とすることが分かる。しかし、オンデマンド・コンピューティングでは、このスタイルのモニターおよび平滑化は十分ではない。というのは、動的な性質を有するオンデマンド・コンピューティングでは、多種多様なジョブおよびアプリケーションが任意の時間に任意のグリッド・ノード上で実行可能であるからである。たとえば、オンデマンド・グリッド環境で、ある特定の時間にAIX(商標)ベースのDB2データベース・ジョブ・セッションに参加していたグリッド・ノードは、その直後にLINUX(商標)のコンパイラ・ジョブを実行する可能性がある。グリッド環境内でリソース使用状況についてこのような急激な変化が発生する見込みがある場合、従来型のツールおよび平滑化分析スタイルは不十分であり、潜在的に関連するジョブ特性を有する複数のジョブについてパフォーマンス・データを収集することができず、まして、そのようなパフォーマンス・データを相関させて分析することはできない。

0010

ジョブの所与の一部を実行可能であるが、所与の時間に使用可能ではない可能性があること、使用可能であるときに所与のジョブの所与の一部について異なるパフォーマンスを示す可能性のある複数のリソースをグリッドが含まれ得ることが、問題をさらに複雑にしている。たとえば、ジョブの所与の一部はDB2を実行するAIX(商標)またはLINUX(商標)上で実行することができるが、現行のパフォーマンス・モニター・ツールは、そのジョブのその一部が履歴上、AIX(商標)ノード・グループよりLINUX(商標)ノード・グループの方が(または逆の場合も同様)より高速かつより低コストで実行されていたことを明らかにすることができない。したがって、より効率の良いLINUX(商標)(またはAIX(商標))のリソースが所与の実行時間にリクエストされたジョブまたはRFPに対する応答に使用可能ではない可能性がある場合、現行のパフォーマンス・モニター・ツールは、価格設定などを正確に決定するためのメカニズムを提供しない。そのため、同様のジョブのためのリソース選択をグリッド内のLINUX(商標)(またはAIX(商標))リソースに偏らせるには、ITマネージメントやスタッフの専門知識または直観によるほかない。

0011

要約すると、2以上の異なるリソースが所与のジョブの特定の一部に使用できる可能性があるときに、最も効果的にそれを実行することができるリソースにジョブの一部を割り振り、そのリソースがそのジョブまたはジョブ一部を処理するのに要すると思われる時間を見積もることができれば有利であろう。しかし、現在の技術水準では、最も効率の良いリソースの可用性の確率を考慮すること、または特定の特性を有するジョブの一部に関するランタイムで実際に使用できる可能性のある任意のリソースの効率に関する高精度の情報を提供することができるツールは存在しない。
米国特許出願公開2006−0150158号
米国特許出願公開2006−0149652号
米国特許出願公開2006−0149714号
米国特許出願公開2006−0059492号
米国特許出願公開2006−0005181号

発明が解決しようとする課題

0012

したがって、本発明の目的の1つは、コンピューティング・グリッド全体およびその使用可能なリソースについて、より正確で効率の良い管理を可能にする包括的な履歴統計をモニターし、評価し、アーカイブし、関連グリッド・モジュールに公表するためのシステムおよび方法を提供することにある。

0013

本発明の他の目的は、同様の特性または要件を有し得る異なるジョブに関する履歴データに基づいて個々にサブミットされた各アプリケーションまたはジョブについて最も効率の良いグリッド・リソースの選択を可能にするリソース使用状況の平滑化ならびに将来を考慮した正確な見積もり、評価、および分析をするために、グリッド・コンピューティング環境の全域でノードからのジョブ・パフォーマンス・データを収集し、相関させるためのツールを提供することにある。

0014

本発明の他の目的は、インバウンド・ジョブ・コストの作成または見積もりを改善し、インバウンド・グリッド・ジョブに関するハードウェアおよびソフトウェア・プラットフォーム要件定義を改善し、グリッドに関するRFPの生成のパフォーマンスおよび正確さを向上し、統計的な学習によりグリッド内の効率を改善し、グリッド・エレメントの財務分析用のプラットフォームを提供し、コンピューティング業界トレンド分析のためのプラットフォームを提供するために、データ収集、記憶、および検索をできるようにすることにある。

0015

本発明のさらに他の目的は、上記の諸機能を実行するためのグリッド・モジュールを実現し、それをサポートすることにある。

課題を解決するための手段

0016

本発明の上記その他の目的を達成するために、グリッド・コンピューティング環境の各リソースを使用して、データ処理リクエストによるジョブの一部を実行するステップと、各リソースのパフォーマンスおよびジョブの一部の特性に対応する、ジョブの一部を実行する各リソースからのデータ・レコードを定期的に記憶するステップと、そこに記憶されたデータに従って選択済みデータ・レコードを検索するステップと、処理済みパフォーマンス・データを履歴パフォーマンス統計として生成するために、検索されたデータを処理するステップとを含む、グリッド・コンピューティング環境を管理する方法が提供される。

0017

本発明の他の態様によれば、データ処理リクエストの一部を処理する、グリッド・コンピューティング環境の各リソースをモニターするための手段(arrangement)と、対応するモニター対象のそれぞれのリソースを識別するデータとジョブの一部の特性とを含む、モニター対象のリソースからのパフォーマンス・データを定期的に記憶するための内容アドレス記憶装置(content-addressablestorage)と、処理済みパフォーマンス・データを生成するために、このような特性に基づいて、データを検索し処理するための手段と、処理済みパフォーマンス・データに基づいてグリッド・コンピューティング環境を管理するための手段(好ましくはモジュールとして実現される)を含む、グリッド・コンピューティング環境を管理するためのシステムが提供される。

0018

上記その他の目的、態様、および利点は、添付図面に関連して本発明の好ましい一実施形態に関する以下の詳細な説明からより十分に理解されるであろう。

発明を実施するための最良の形態

0019

次に添付図面、詳細には図1を参照すると、本発明によるグリッド環境と課金(accounting)および統計管理システム100からなるシステム・アーキテクチャ全体のブロック図が示されている。当業者であれば、特許文献1の図2および図5のそれぞれに対して図1図2、および図3の一部が類似していることを理解し、これらの図を比較することによって、本発明によって提供される特許文献1の発明の諸機能に対する改善ならびに追加の機構および機能について正当な評価をすることができるであろう。より具体的には、上記の特許文献1に詳述されている通り、グリッド環境110は、グリッド管理システム120と仮想リソース130とを含む。しかし、本発明のグリッド管理システム120は、以下により詳細に論じるように、課金および統計管理システムを含むことによって、実質的に追加の機能を提供する。すなわち、本発明を含む任意のグリッド環境が特許文献1の諸機能のうちのいくつかを提供することができ、その諸機能が本発明を含むことによって大幅に改善できることは好ましいことである。

0020

グリッド環境は、ネットワークその他の配置によりクライアント・システム10によってアクセス可能であるが、その詳細は本発明の実施にとって重要なものではない。クライアント・システム10からの通信はグリッド管理システム120へのものとして描写されている。グリッド管理システム120はプロセッサおよびアプリケーション140の割当て(allocation)を管理する。次に、アプリケーション140は様々なアクセス可能リソース150を使用し、クエリ(query、照会)に対する応答と、クライアント・システムのリクエストに応答するその他の機能を管理する。

0021

本発明の実施形態は、特許文献1に詳述されたグリッド環境110に加えて、様々なリソース150からデータ・ウェアハウス(複数も可)160へのパフォーマンス報告を可能にする。データ・ウェアハウス160は、単一のパフォーマンス・データ・リポジトリにするか、または所与のグリッド環境に対する本発明の特定の応用例に最も良く対処できるように分割および/または分散することができる。これは、いわゆる「ミドルウェア」などの任意の既知ネットワーク通信技術により実装することができ、本発明の実施はその詳細に依存しない。クエリに関する最大限の柔軟性と、たとえば、前に実行されたジョブまたは現在実行中のジョブの一部に対する着信ジョブの一部の最適一致(optimal matching)を可能にするために、そこに含まれる任意の特定のデータを基礎としてレコードにアクセスできるようにメモリ170a、170bのある種の内容アドサビティ(content addressability)を提供することを除いて、データ・ウェアハウスの実装例は同様に本発明の実施にとって重要ではない。データ・ウェアハウスが分割または分散される場合、その一部(同じ(たとえば、二重)分析プロセスおよびアルゴリズム180a、180bを含まない可能性がある)は、好ましくはモジュールとして実装されるものであり、可能なクエリのうちのすべてまたは少なくとも最大数を達成できるように相互作用することが許可されるはずであり、そのクエリは特定のアプリケーションおよびリソースに対するすべてのリソースのパフォーマンスに関して任意の複雑さのものになる可能性がある。データ・ウェアハウスの分割または分散が行われる場合、グリッドがどのように複数のセキュリティ・ドメインにわたって分散しているかに基づいてこのように実行することが好ましい。

0022

同じく特許文献1に詳述され、図2(特許文献1の図5に対応する)に例示されている通り、グリッド管理システム120は1以上のワークロード・エージェント(複数も可)125を含む。このワークロード・エージェントは、好ましくはモジュールとして実施され、リソースの割当て、グリッドの管理、市販のグリッド・サービスに関する価格設定、販売および課金などの様々な所望の機能を実行するために他のモジュールと通信する。好ましい機能を実行するための例示的なモジュールの一般的なアーキテクチャは図2に概略的に示されており、その一部については、既に公開された特許文献2乃至5において詳細に論じられている。

0023

より一般的には、モジュールまたはサブシステムは、ワークロード管理、ソフトウェア/ハードウェア・カタログ管理、課金/請求、価格設定計算、割引管理など、グリッド環境内で具体的な機能を実行するためのグリッド管理システム内のアーキテクチャ・コンポーネントである。たとえば、価格設定計算モジュールは、特定のリソースにおいてグリッド・インフラストラクチャまたは環境内のジョブまたはジョブの一部を実行するための価格を決定する。各モジュールまたはサブシステムは、意図された機能を提供するための方法またはアルゴリズムを実行し、その機能を実行するための「エンジン」としての性質の点で重視される可能性がある。各モジュールまたはサブシステムは、好ましくは、ソフトウェア「オブジェクト」(オブジェクト指向プログラミングにおける意味である)として実施されるが、特殊目的プロセッサというハードウェアにするか、またはハードウェアとソフトウェアの組み合わせにすることもできる。

0024

図3に例示されている通り、本発明の実施形態は、好ましくは、リソースの使用状況に関するリソース割当ておよび課金とは別個に、特定のリソースによる特定のジョブまたはジョブの一部のパフォーマンスに関して課金、統計、および履歴トレンド管理を実行するために配置されたモジュールまたはサブシステムとしても実施され、リソース割当ておよび課金という機能は本発明の使用によって大幅に改良することができる。より具体的には、データ・ウェアハウス160内には、好ましくは上記で定義されたモジュールとして、課金、統計、および履歴トレンド管理サブシステム180が設けられている。課金および統計管理モジュール180は、上述の通り記憶するために個々のグリッド・リソースまたはグリッド・リソース・グループ150からのパフォーマンス・データの取得を管理し、大容量記憶装置170から、それと通信している複数のグリッド・プロセスおよびアルゴリズム185のそれぞれへのデータの転送を管理する。さらに、点線部分を含む図1および図3の190に概略的に描写されている通り、課金および統計モジュール180は、単独でまたは好ましくはグリッド・ワークロード・エージェント125と協力して、前述のグリッド・ワークロード・エージェント125に関連するグリッド管理システム・モジュールに対するそれぞれのモジュール185による処理の結果の通信を管理する。これらの通信のルーティングは本発明の実施にとって重要ではないが、データの配布が管理されるグリッド・ワークロード・エージェントによるルーティングが好ましい。

0025

課金および統計管理モジュール180に関連するモジュール185によって実行される特定のプロセスおよびアルゴリズムならびにその詳細は、本発明の実施にとって重要ではない。しかし、特許文献1に開示されている通り、グリッド・ワークロード・エージェント125に関連するモジュールを補完し、微細(fine-grained)レベルの具体的なジョブの一部および具体的なリソースで取得された処理済みデータを転送するためのメカニズムを提供するように、いくつかのプロセスおよびアルゴリズムが選択されることが好ましい。このことは、リソース・グループ(またはリソース・グループ全般から区別できない可能性のあるリソース・グループの一部)上で実行されたジョブまたはジョブの一部のグループをひとまとめにして反映できるデータに関する動作とは区別されるものである。たとえば、コスト見積もりモジュール、ハードウェア/ソフトウェア要件モジュール、およびグリッド内プロセス・モジュールによって処理されたパフォーマンス・データは微細データの分析を可能にする。そして、そうすることによって、グリッド管理システム120内のグリッド・リソース割当てモジュール、グリッド・マネージャ・モジュール、グリッド価格設定モジュール、ジョブ・ランタイム見積もりモジュール、およびグリッド割引モジュールのパフォーマンスを確かに改良することができる。また、トレンド分析モジュールは、より具体的にジョブの一部に整合され詳細に定義されたクエリに応答して微細データを供給することによって、上述の通り、グリッド・リソースの割当ておよびワークロードの平滑化も強化することができるが、特殊目的機能のためにRFP生成処理などのその他のモジュールを設けることができ、グリッド・エレメント財務分析は、リソース追加および/またはアップグレードの効果の決定または投影を含む、キャパシティ管理およびそれに関する入力に有用である可能性がある。

0026

次に図4を参照して、本発明によって実行される動作の関係について論じることにする。なお、フローチャート様相がいくつか含まれている可能性があっても、図4は厳密なフローチャートになるよう意図されているわけではないことを理解されたい。例示されている動作を通るいくつかのパスは、少なくとも以下に示す好ましいハイレベル機能(図3に例示されているモジュールに対応する)をサポートするようにパフォーマンス・データが収集され、記憶され、検索されることを保証するために、実質的に並列にしかも再帰的な手法で実行することができる。
1)インバウンド・ジョブ・コスト作成または見積もりの改良
2)インバウンド・グリッド・ジョブに関するハードウェアおよびソフトウェア・プラットフォーム要件定義の改良
3)グリッドRFP処理のパフォーマンスおよび正確さの強化
4)統計的学習によるグリッド内処理の改善
5)グリッド・エレメントの財務分析のためのプラットフォームの提供
6)コンピューティング業界トレンド分析のためのプラットフォームの提供

0027

本発明の好ましい動作モードで実行される初期動作は、202に示されている通り、グリッド管理システム120がグリッド(たとえば、個々のアプリケーション環境ならびにそれぞれの接続リソース)140のプロセッサおよびアプリケーションに問い合わせて、現在実行中のジョブおよびスケジュールされたジョブを決定することである。このステップは、効率の悪いグリッド管理によってパフォーマンス・データが偏らないようにグリッドの継続的管理(on-going management)を適切に処理できることと、継続的にグリッドから使用可能なものになっている所望のパフォーマンス・データが認識され収集されることを保証するために重要である。現在実行中のジョブおよびスケジュールされたジョブならびにそのそれぞれの一部が識別されると、204に示されている通り、個々のアプリケーション環境140の現在の瞬間動作のパフォーマンス「スナップショット」が定期的に撮られ記憶される。このステップは、ジョブの完了時または所定の数のスナップショット後にスナップショット・データをアーカイブするためにステップ226と相互作用し、リアルタイムでまたは定期的に同じグリッド上または他のグリッド上の他の関連管理サブシステムにデータを転送するためにステップ222と相互作用する。

0028

しかし、上記で列挙された例示的なハイレベル機能のほとんどは主に着信ジョブのグリッド動作に対する効果および/またはそのジョブがどのように実行されるかに関する現行グリッド状態の効果の投影(projection)と、どのくらいの時間を要するかという見積もりに関連するので、本発明によるパフォーマンス・データ収集プロセスは、206に示されている通り、新しい着信グリッド・コンピューティング・ジョブの入力およびスケジューリングを続ける。その後、208に示されている通り、グリッド管理システムは、更新が行われたことをワークロード・エージェント(複数も可)125に通知する。応答として、ワークロード・エージェント(複数も可)および/または課金および統計管理モジュール180は、210に示されている通り、着信ジョブの特性または着信ジョブのそれぞれの一部の特性の組み合わせに対応するジョブ・パフォーマンス・データを収集する。

0029

次に、212に示されている通り、新しいジョブまたは着信ジョブあるいはその一部がアプリケーション固有のものであるかどうかが判断される。アプリケーション固有のものである場合、216に示されている通り、ジョブまたはそのそれぞれの一部を実行するための適切なアプリケーション環境140に問い合わせるか、または現行ワークロード統計について現行スナップショットが読み取られる。アプリケーション固有のものではない場合、一般に、グリッド環境を構成するすべてのアプリケーション環境140にわたって本質的に同じ動作が実行される。いずれの場合も、グリッドに対するジョブ・サブミッションの影響を見積もるために予測分析218が実行され、予測パフォーマンス番号および関連の予定表が生成されて報告され(220)、他の接続グリッド管理サブシステムまたはモジュールに送信され(222)、記憶される(224)。そして、その結果、ジョブ影響予測の改良をサポートするために、決定され定量化された後で、実際のジョブ影響と予測データを比較することができ、または逆に、特にグリッド・アーキテクチャおよびその他のありそうな同時グリッド処理に関して所与の履歴パフォーマンス統計内にジョブ・ランタイムを実行できる見込みを予測する。この場合も、226で、ジョブ完了時にまたは定期的に、結果の予測データがアーカイブされ、同時実パフォーマンス・データは204で収集され、上述の通り、アーカイブされる。

0030

上述のステップ222は、予測データと、204で収集されたデータを、230に示されている通り、実質的にリアルタイムで関連サブシステムに提供する。これらのサブシステムは、226から得られるアーカイブ・データにもアクセスすることができる。これらのサブシステムまたはモジュールは、リソース割当て、グリッド管理、グリッド処理割引決定、アイドル・リソース時間の売却、価格設定分析および決定を含むがこれらに限定されない、それぞれのタイプの分析および制御機能を実行する。これらの機能は、上記のように、任意のその他のパフォーマンス・データまたはパラメータあるいはその論理(たとえば、ブール)結合に基づいて任意のパフォーマンス・データまたはパラメータを検索するために非常に柔軟に定義され、任意に複雑なものにすることができるクエリに応答するためにデータ・ウェアハウス160およびそこに設けられた内容アドレス・メモリの機能によって実行される特定の分析に関して非常に柔軟なものにすることができる。

0031

次に図5を参照すると、クエリ深度(query depth)を増すことによるパフォーマンス予測の改善が描写されている。この場合、データの行数またはライン数カウントするのに要する時間がパフォーマンスの標識として使用されている。異なるジョブとおそらく異なるアプリケーション環境からのパフォーマンス・データに関する2つのサンプルという低クエリ深度の場合、小規模外挿(extrapolation)のために、結果的に45秒で4000行がカウントされるという予測すなわち1.125ミリ秒/行という予測が行われる。しかし、6通りの履歴パフォーマンス統計の場合、正確さおよび信頼性を増して、より大規模な外挿を行うことができる。このような分析が、たとえば、特定のプラットフォームによるソートを含む場合、所与のジョブまたはその一部について最も効率の良いプラットフォームを容易に決定することができる。同様に、適度なクエリ深度は、特定のまたは履歴的にありそうな同時グリッド処理および/またはグリッド・アーキテクチャの環境内の所与の履歴パフォーマンス統計内に所与のジョブまたはジョブの一部のランタイムを完了できる見込みを予測するための基礎を提供することができる。上記で論じたように柔軟で任意に複雑なクエリ(照会)を行う能力により、すべての着信ジョブを迅速に分析することもできる。そして、各一部のパフォーマンスの見積もり(任意に微細な細分性を有する)は、特に、ジョブ価格設定の正確さの改善、RFP作成、最も効率がよい使用可能なリソースの選択の改善、およびリクエストされたジョブに必要なグリッド・リソースの必要量の見積もりのために、前のジョブから前に収集したデータと一致させることができる。

0032

クエリ深度は、潜在的に、図5の単純な例のように特定のパフォーマンス基準については非常に急速に増加することが分かるであろう。たとえば、図5の高クエリ深度の列の最初の2つの項目は、低クエリ深度の列の2つだけの項目と同じであることに留意されたい。また、どちらの項目も、高クエリ深度データから見積もられたパフォーマンス時間よりかなり遅いパフォーマンスを示すとともに、行スキャン数が増えるほど時間が長くなる傾向を示すことにも留意されたい。したがって、クエリ深度が高くてもこのようなデータ項目によってパフォーマンス見積もりがいくらか偏る可能性がある。また、この例のため、クエリは単に集合DB2行スキャン時間(aggregate DB2 row scan time)を含むすべてのパフォーマンス・データに関するものであったと想定される。

0033

しかし、各ジョブの追加の基準および特性に関連するパフォーマンス・データを収集すると、非常に具体的で任意に複雑なクエリを実行することができ、任意に小さな着信ジョブの一部の特性およびハードウェア/ソフトウェア要件を収集した実際のパフォーマンス・データと非常に厳密に一致させることができる。そうすることによって、最初の2つの項目のうちの一方または両方がより複雑で詳細なクエリで廃棄される可能性があるが、依然として相当なクエリ深度が維持され、データが蓄積される。そして、そのデータはより詳細で複雑なクエリでは比較的遅い速度で検出されるであろう。それにもかかわらず、着信ジョブの一部と前に実行されたジョブの一部との特性の一致の厳密さが改善されると、ジョブ・パフォーマンスの予測の正確さが増し、大規模外挿を行わなければならない場合でも信頼性のレベルが上がるが、予測処理で考慮されるデータの量が低減されると応答時間が削減され、異なるリソースを使用する処理に関する分析の比較が可能になる。したがって、ランタイムの偶然性(run time contingency)に対する信頼性および対処も改善された収益性マージン(profitability margin)を維持するように、そのリソースについて、より効果的に割当ておよび価格設定を行うことができる。

0034

したがって、上記を考慮すると、本発明は、効率が改善されたグリッド管理をサポートして、包括的統計をモニターし、アーカイブし、関連グリッド・モジュールに公表するための包括的システムおよび方法を提供することが分かる。また、本発明は、特にグリッド活動およびパフォーマンス、RFPおよびリソース使用状況、グリッド・エレメントの財務分析、トレンド分析などに対するインバウンド・ジョブの影響に関する履歴データに基づいて特定のリソースに関するリクエストの平滑化および効率の良い割当てをより正確かつ効果的にサポートするために、グリッド環境全域でそれぞれのノードによって実行された個々のジョブの一部に対応するジョブ・パフォーマンス統計を収集し、任意で相関させるためのツールを提供する。

0035

以上、1つの好ましい実施形態に関して本発明を説明してきたが、当業者であれば、特許請求の範囲の精神および範囲内の変更を行っても本発明を実施できることを理解するであろう。

図面の簡単な説明

0036

本発明の実施形態によるパフォーマンス報告のためのグリッド・システム・アーキテクチャのブロック図の概要である。
複数のグリッド・モジュールを有する図1のグリッド管理システム内のグリッド・ワークロード・エージェントの相互作用を例示する図である。
本発明の実施形態による課金および統計管理モジュールと複数の課金および統計モジュールとの相互作用と、図2のそれに関連するワークロード・エージェントおよびモジュールによる相互作用とを例示する図である。
分析ツールなどを提供する様々なモジュールとの相互作用およびそのモジュールの相互作用を含む、本発明の実施形態の動作を例示するフローチャート類似の図である。
パフォーマンス・データの異なる深さについて、本発明の実施形態によりジョブの一部を分析する動作を例示する図である。

符号の説明

0037

10:クライアント・システム
100:課金および統計管理システム
110:グリッド環境
120:グリッド管理システム
130:仮想リソース
140:アプリケーション
150:リソース
160:データ・ウェアハウス
170a:メモリ
170b:メモリ
180a:分析プロセスおよびアルゴリズム
180b:分析プロセスおよびアルゴリズム
185:グリッド判断

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

該当するデータがありません

関連する公募課題

該当するデータがありません

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

  • 日本電気株式会社の「 情報処理装置」が 公開されました。( 2019/08/22)

    【課題】制御ノードと計算ノードとを有する情報処理装置において、計算ノードで動作する複数のプロセス間でメモリ共有の可否を制御する方法の実現が望まれていること。【解決手段】情報処理装置は、第1のメモリを有... 詳細

  • 株式会社東芝の「 クラウドシステム、クラウドサーバ、エッジサーバおよびユーザ装置」が 公開されました。( 2019/08/15)

    【課題】 クラウドおよびエッジの連携により提供されるサービスが運用上の環境変化の変化に脆弱であったこと。【解決手段】 実施形態に係わるクラウドシステムは、ネットワークを介して相互に通信可能なクラウ... 詳細

  • 富士通株式会社の「 性能調整プログラム、および性能調整方法」が 公開されました。( 2019/08/15)

    【課題】性能悪化要因の処理を特定できるようにする。【解決手段】管理装置10は、所定の処理性能による調整対象処理の実行機能である1または複数の単位機能5a,5bそれぞれを、1または複数のサーバのいずれか... 詳細

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

該当するデータがありません

この 技術と関連する公募課題

該当するデータがありません

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ