JP2004206712A - トポロジ・アウェア・グリッド・サービス・スケジューラ・アーキテクチャ - Google Patents

トポロジ・アウェア・グリッド・サービス・スケジューラ・アーキテクチャ Download PDF

Info

Publication number
JP2004206712A
JP2004206712A JP2003421634A JP2003421634A JP2004206712A JP 2004206712 A JP2004206712 A JP 2004206712A JP 2003421634 A JP2003421634 A JP 2003421634A JP 2003421634 A JP2003421634 A JP 2003421634A JP 2004206712 A JP2004206712 A JP 2004206712A
Authority
JP
Japan
Prior art keywords
grid
scheduler
container
array
containers
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2003421634A
Other languages
English (en)
Inventor
James Robert Harold Challenger
ジェームス・ロバート・ハロルド・チャレンジャー
Marcos Novaes
マルコス・ノバエス
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Publication of JP2004206712A publication Critical patent/JP2004206712A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5072—Grid computing
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Stored Programmes (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

【課題】グリッド・サービス・スケジューラ・アーキテクチャを提供する。
【解決手段】ホストのコンピュータ・ネットワークにわたってクライアント要求を処理するシステム／方法を提供し、それには、ホスト内に持続的なコンテナを作成すること、コンテナ内にオブジェクトを作成すること、コンテナをグリッド・コンテナ配列にグループ化すること、単一グリッド・コンテナ配列内となるコンテナ内におけるオブジェクトを、グリッド・オブジェクト配列にグループ化すること、各グリッド・コンテナ配列用に１つのマイクロ・スケジューラを作成すること、クライアント要求のそれぞれを複数のタスクに分割すること、およびタスクのグループをマイクロ・スケジューラに割り当てることが含まれ、それにおいてはマイクロ・スケジューラが、個別のタスクをオブジェクトに割り当てる。
【選択図】 図２

Description

本発明は、概してコンピュータ・ネットワークにわたるプロセッシング要求に関し、より詳細に述べれば、グリッド・サービス・スケジューラを使用してクライアントの要求を多くのタスクに分割する改善されたシステムに関する。このシステムは、グリッド・オブジェクト配列内の複数のオブジェクトを介してタスクを実行するが、オブジェクトは、グリッド・コンテナ配列を構成するコンテナ内にあり、グリッド・コンテナ配列は、マイクロ・スケジューラによってコントロールされる。
グリッド・コンピューティングは、クラスタ・コンピューティングの論理環境であると言うことができる。以下は、グリッド・アーキテクチャの実装に関する評価基準としてグローバス（Ｇｌｏｂｕｓ）ツールキット（米国イリノイ州シカゴを居所とするアルゴンヌ国立研究所（Ａｒｇｏｎｎｅ Ｎａｔｉｏｎａｌ Ｌａｂｏｒａｔｏｒｙ）から入手可能）を使用してこの概念の吟味を行っている。グローバス（Ｇｌｏｂｕｓ）ツールキットの考察において指摘しておかなければならないことは、このテクノロジが非常に速いレートで進化しており、それぞれのリリースごとに非常に重要な差を有することである。特に、グローバス（Ｇｌｏｂｕｓ）３．０アーキテクチャには、それがオープン・グリッド・サービス・アーキテクチャ（Ｏｐｅｎ Ｇｒｉｄ Ｓｅｒｖｉｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ）（ＯＧＳＡ）標準に基づいているという事実に起因して、非常に大きな進歩がある。したがって、グローバス（Ｇｌｏｂｕｓ）について議論する場合には、議論の状況を設定するために正確なリリースを明示する必要がある。
一例として、オープン・グリッド・サービス・アーキテクチャの採用に先行するグローバス（Ｇｌｏｂｕｓ）２．０の実装について考える。グローバス（Ｇｌｏｂｕｓ）２．０アーキテクチャを考察すると、それがグリッドを『クラスタのクラスタ（ｃｌｕｓｔｅｒ ｏｆ ｃｌｕｓｔｅｒｓ）』として定義していることがすぐにわかる。この複合的な観点は、グローバス（Ｇｌｏｂｕｓ）プログラムの初期からの表現であり、グリッド・コンピューティングに使用されていた古い呼び方は『メタ‐コンピューティング』である。マルチ・クラスタ・アーキテクチャの複合的な性質を指している。『クラスタのクラスタ（ｃｌｕｓｔｅｒ ｏｆ ｃｌｕｓｔｅｒｓ）』の観点は、グローバス（Ｇｌｏｂｕｓ）プログラムの初期の目的と一貫性を持つ。すなわちそれは、単一のインフラストラクチャにおいて、地理的に分散した国立研究所内に配置されているいくつかのクラスタを統合することである。この観点はまた、グリッドのスケーラビリティを考慮したとき、多くの意味を有する。グリッドに対する個別のホストの追加は、まもなくマネージ不能なインフラストラクチャを招くことになり、分離してマネージされるグループにホストをグループ化することが１つの論理ステップになる。『クラスタのクラスタ（ｃｌｕｓｔｅｒ ｏｆ ｃｌｕｓｔｅｒｓ）』パラダイムは、２つの重ねられた階層構造を提供し、それがグリッドの管理を飛躍的に簡素化する。
しかしながら、『クラスタのクラスタ（ｃｌｕｓｔｅｒ ｏｆ ｃｌｕｓｔｅｒｓ）』パラダイムの二つの限界は、すぐに明らかになった。第１に、このスキームは本質的に２段であった。つまり、２段の階層構造しかサポートし得ず、より深い階層構造をサポートするためにはオリジナルのフレームワークに対する拡張が必要であった。第２の限界は、グリッド全体にわたるスケジューリングのための中心ファシリティがなかったことである；すなわち、メタ‐スケジューラが存在しなかった。それぞれの個別のクラスタは、そのクラスタ内のタスクをスケジュールする権限を有するクラスタ・スケジューラを伴って構成されたが、グリッド全体にわたるタスクをスケジュールするためにグリッド・スケジューラ（または、メタ‐スケジューラ）が必要なことは、すぐに明らかになった。この種のスケジューラの設計における主要な困難は、グローバス（Ｇｌｏｂｕｓ）ツールキット（バージョン２．０もしくはそれ以前）においては、グリッドの世界とクラスタ・スケジューリングの世界の間に不連続性が存在していることである。より詳細に述べれば、１つのクラスタ内およびクラスタ間のタスク・スケジューリングに、異なるスケジューリング・テクノロジならびにプロトコルが使用されていた。以下に述べる本発明は、グリッドならびにクラスタ・ドメインの両方に関する統一されたタスク・スケジューリング・ドメインを提案し、したがって本発明は、非常に深い階層構造グリッドをシームレスにサポートすることができる。
本発明は、ホストのコンピュータ・ネットワークにわたってクライアント要求を処理する方法を提供し、それには、ホスト内に持続的なコンテナを作成すること、コンテナ内にオブジェクトを作成すること、コンテナをグリッド・コンテナ配列にグループ化すること、単一グリッド・コンテナ配列内となるコンテナ内におけるオブジェクトを、グリッド・オブジェクト配列にグループ化すること、各グリッド・コンテナ配列用に１つのマイクロ・スケジューラを作成すること、クライアント要求のそれぞれを複数のタスクに分割すること、およびタスクのグループをマイクロ・スケジューラに割り当てることが含まれ、それにおいてはマイクロ・スケジューラが、個別のタスクをオブジェクトに割り当てる。本発明は、マイクロ・スケジューラに、そのマイクロ・スケジューラが完了したタスクのグループを返すときに追加のタスクのグループを割り当てる。またこの方法に、ゲートウェイを介してクライアント要求を複数のグリッド・サービス・スケジューラに渡すことが含められるようにもできる。
また本発明は、クライアント要求を処理するためのコンピュータ・システムを提供する。このシステムは、グリッド・コンテナ配列に接続されるグリッド・サービス・スケジューラを含む。各グリッド・コンテナ配列は、それぞれが異なるコンピュータ・ホスト内に常駐する持続的なコンテナ（たとえば、サービス・コンテナ）、およびマイクロ・スケジューラを含んでいる。各コンテナは、多くのオブジェクトを含む。単一のグリッド・コンテナ配列を構成するコンテナ内のオブジェクトは、グリッド・オブジェクト配列を構成する。グリッド・サービス・スケジューラは、トランスペアレントに、クライアント要求を複数のタスクに分割し、タスクのグループを各マイクロ・スケジューラに割り当てる。マイクロ・スケジューラのそれぞれは、グリッド・サービス・スケジューラから受け取ったタスクのグループからの個別のタスクを、それらに対応するグリッド・オブジェクト配列内のオブジェクトに割り当てる。
このシステムは、追加のレベルのスケジューラ階層構造およびゲートウェイを含むことが可能であり、それぞれは異なるグリッド・サービス・スケジューラに接続される。ポータルがゲートウェイに接続されるが、このポータルは、ゲートウェイに沿ってクライアント要求をグリッド・サービス・スケジューラに渡す。
各コンテナ配列は、ローカル・エリア・ネットワーク内に常駐し、その結果、グリッド・コンテナ配列内のオブジェクト間の通信が、ローカル通信を構成する。グリッド・サービス・スケジューラは、クライアント要求をトランスペアレントな方法に従って分割し、その結果、クライアントがそのクライアント要求の分割に気付くことはない。これらのコンテナは、持続的なサービス・コンテナであり、それらが使用されて、複数のクライアント要求に及ぶ時間期間にわたって複数のクライアントの複数のクライアント要求が処理される。
本発明のより良好な理解は、以下の図面を参照した好ましい実施態様の詳細な説明から得られるであろう。
すでに述べたが、１つのクラスタ内およびクラスタ間のタスク・スケジューリングに、異なるスケジューリング・テクノロジおよびプロトコルが使用されていた。本発明のトポロジ・アウェア・グリッド・サービス・スケジューラ（Ｔｏｐｏｌｏｇｙ Ａｗａｒｅ Ｇｒｉｄ Ｓｅｒｖｉｃｅｓ Ｓｃｈｅｄｕｌｅｒ）（ＴＡＧＳＳ）スケジューリング・アーキテクチャは、非常に深い階層構造グリッドをシームレスにサポートすることが可能なグリッドならびにクラスタ・ドメインの両方に関する統一されたタスク・スケジューリング・ドメインを提案する。
この開示は、グリッド用のメタ‐スケジューラの設計に関連付けされた課題を考察する。より詳細には、クラスタ環境とグリッド環境の差について論じ、さらに伝統的なクラスタ・スケジューリング・アーキテクチャがグリッド環境におけるメタ‐スケジューリングに適切でないことを論証する。このことは、サービス・ベースのアーキテクチャの導入が新しいグリッド・テクノロジを、伝統的なクラスタ・コンピューティングからさらに遠ざけることを考慮するとき、特に真となる。ここでは、これらの側面を論じつつ、サービス指向グリッド・アーキテクチャ用に設計されたトポロジ・アウェア・グリッド・サービス・スケジューラ（Ｔｏｐｏｌｏｇｙ Ａｗａｒｅ Ｇｒｉｄ Ｓｅｒｖｉｃｅｓ Ｓｃｈｅｄｕｌｅｒ）（ＴＡＧＳＳ）の発明的なアーキテクチャを紹介する。
このセクションにおいては、タスク・スケジューリング・インフラストラクチャの設計に影響を与えるクラスタ環境とグリッド環境の間における主な差を簡単に探る。トポロジの考察に関して言えば、第１の検討事項は、包括的なトポロジ・インフラストラクチャに関係する。通常、クラスタは一様なトポロジを有しており、言い換えるとコンピューティング・ホストは、一般に同一のタイプであり、多くの場合はまったく同一であり、大抵は共通ネットワークを介してすべてのホストに到達可能である。いくつかのケースにおいては、クラスタが高速ネットワークを備えていることがある。グリッドのリソースがワイド・エリア・ネットワークを介して到達可能となり得ることから、また各リソースが、ワイド・エリア・ネットワーク・リンクの特性に応じた程度の異なるサービスの品質を伴って到達可能となることから、明らかにこの環境は、平均的なグリッドとは異なる。ネットワーク速度における変化は、以下のセクションにおいて明らかになろうが、ＴＡＧＳＳの設計における主要な検討事項である。
サービス・スケジューリング対ジョブ・スケジューリングに関しては、ＯＧＳＡ標準において提案されているように、サービス・ベースのアーキテクチャへの最近の移行に関連してもう１つの重要な検討を行う必要がある。サービス・ベースのアーキテクチャは、ほとんどのクラスタ・スケジューリングによって使用されているジョブ・ベースのアーキテクチャと大きく異なる。一方、用語「ジョブ」によって意味されるところを慎重に定義する必要がある。ここでは、コンドル（Ｃｏｎｄｏｒ）（米国ウィスコンシン州マディソンを居所とするウィスコンシン‐マディソン大学（Ｕｎｉｖｅｒｓｉｔｙ ｏｆ Ｗｉｓｃｏｎｓｉｎ‐Ｍａｄｉｓｏｎ）から入手可能）、ＰＢＳ（米国カリフォルニア州マウンテンビューを居所とするベリディアン・システムズ（Ｖｅｒｉｄｉａｎ Ｓｙｓｔｅｍｓ）から入手可能）、ＬＳＦ（米国カリフォルニア州マーカムオンタリオを居所とするプラットフォーム・コンピューティング（Ｐｌａｔｆｏｒｍ Ｃｏｍｐｕｔｉｎｇ）から入手可能）、およびロード・レベラー（Ｌｏａｄ Ｌｅｖｅｌｅｒ）（米国アーモンクを居所とするインターナショナル・ビジネス・マシーンズ・コーポレーション（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ）から入手可能）といったクラスタ・コンピューティングに使用可能なほとんどのタスク・スケジューリング・ミドルウェアによって使用されてきたこの用語を使用する。これらのスケジューラのすべては、「ジョブ・スケジューラ」として知られている。次に、ジョブ・スケジューラとタスク・スケジューラの特性を比較する。
ジョブならびジョブ・スケジューリングに関しては、「ジョブ」が１ないしは複数のプロセスに関連付けされる。ジョブが「スケジュールされた」と言った場合には、１ないしは複数のプロセスがターゲット・ホスト内に作られたことを意味する。ジョブは、たとえば、コマンド行シンタクス、環境変数等のそのジョブが関連付けされるプロセスの作成に関連するパラメータに置き換えられて記述される。また、それが必要とする、ＣＰＵもしくはホストの数、ランタイム・ライブラリ等のリソースに従って記述される。ジョブのもう１つの興味ある側面は、データ通信モデル、すなわちジョブが入力および出力データとともに使用される方法である。入力データは、コマンド行内の引数および環境変数を使用して渡される；いずれの場合においても、サポートされている唯一のフォーマットは、テキストである。すなわち、入力データがテキスト文字列として渡されるが、当然のことながらそれは、入力データを完全に含むファイルを参照することができる。出力データも類似の方法で渡される；標準出力パイプから利用可能なテキスト出力となることもあるが、通常は出力データがファイルの形式になる。したがって、一般にはジョブが一連の入力ならびに出力ファイルと結合され、この理由から、ほとんどのクラスタ・スケジューラが、「ファイル・ステージング」関数を実装しており、それがジョブの実行に先行し、またジョブが出力ファイルのセットの取り出しを完了したことに応答して、ファイルをリモート・ホストに転送する。この定義は、「ジョブ」が「単一ワーク・ユニット」に関連付けされることを指定するが、それは、それが単一セットの入力パラメータを伴って（通常は単一のユーザに代わって）開始するプロセスからなること、および通常は出力が生成された後にジョブ・プロセスが実行を終了することによる。この理由から、ジョブに関連付けされるプロセスを「一過的」として記述することができる。ジョブの一過的特性は、そのプログラミング・モデルを「バッチ実行」に限定してきた。
サービス、サービス要求ならびに要求スケジューリングに関して言えば、「サービス」を一様に、より多くのプロセスの１つに関連付けすることができる。しかしながら、サービスに関連付けされるプロセスは、一般に「持続的」である。つまり、サービスは、与えられたタスクを実行した後においても実行を終了せず、むしろそれは、持続的な、「複数のワーク・ユニット」または「サービス要求」を実行することのできる、はるかにサーバに近いアプリケーションとなる。したがって「要求スケジューリング」アクティビティは、新しいプロセスの作成を伴わない。むしろ、「要求スケジューリング」は、何らかの管理ポリシーに従って複数のユーザから到来するサービス要求のキューイングからなり、その後、与えられた要求をより良好に実行することができる適切なサービス・インスタンスにその要求が「ルーティング」される。サービス・プロバイダの持続的性質は、「リアルタイム」プログラミング・モデルを可能にする。データ取り扱いの側面については、「サービス」が、ＷＳＤＬならびにＳＯＡＰ等の標準から導かれる、はるかに柔軟なインフラストラクチャを使用する。入力および出力パラメータは、いくつかのプロセッサ・アーキテクチャをサポートするポータブル・データ・オブジェクトとして記述することができる。
次に示す表は、上記の定義で論じた側面に従って「ジョブ」と「サービス要求」を比較したものである。
表１：ジョブおよびサービス要求の特徴
Figure 2004206712
タスク・スケジューリングの細分性の重要性に関して、ＴＡＧＳＳアーキテクチャの説明に進む前に、ジョブとは逆に、より細分化された要求を使用することの主要な利点について最後に付言しておく。サービス要求がはるかに小さいワーク・ユニットであることから、コンピューティング・タスクの一部分だけをアプリケーションがアウトソーシングすることを可能にする。さらにこれは、アプリケーションのコードならびにデータのほとんどを、単一のホストまたは組織内に含ませることを可能にする。この特徴は、小さいコード・セグメントだけをアウトソーシング組織に転送すればよく、また標準サービス・アウトソーシング（基本算術ルーチン等）の場合には、コードの転送がまったく必要ないことから、アプリケーション・コードがプロプラエタリな性質を有するアプリケーションにおいては重要な要件となる。この特徴の別の重要な用途は、アプリケーションが大量のデータを扱う場合である。多くの場合には、アプリケーションがデータをマニュアル操作し、アウトソーシングされるオペレーションを厳密に必要とするデータだけを送信することが可能になる。これは、多くのアプリケーションがプロプラエタリ・コードを開示することに関して鋭敏であることを前提とするのであれば重要な考慮事項である。またこれは、不可欠なデータの送信のみを必要とする場合に得られる効率に関しての重要な考慮事項でもある。図１は、多くの場合には単一の組織内において走り、小規模の並列化可能なタスクのアウトソーシングだけを行うアプリケーションとなるクラスタを示している。図１においては、オブジェクト１２８が使用されて特定のタスクが実行される。オブジェクト１２８は、クラスタ１２５内に含められている。２つの組織１２０、１２１は、クラスタ１２５を通じ、クラスタ・スケジューラ１３２およびグリッド・ゲートウェイ１３０を使用することによってデータを処理する。これに対して本発明は、多数の異なる組織内において無制限数のノードを使用するグリッドを提供する。クラスタとグリッド・コンピューティングの間における違い、特にトポロジおよびタスク・スケジューリングに関する相違について論じてきたが、これにより、本発明のトポロジ・アウェア・グリッド・サービス・スケジューラ（Ｔｏｐｏｌｏｇｙ Ａｗａｒｅ Ｇｒｉｄ Ｓｅｒｖｉｃｅｓ Ｓｃｈｅｄｕｌｅｒ）（ＴＡＧＳＳ）のアーキテクチャを議論するために必要な背景が確立された。
本発明は、サービス指向アーキテクチャを提供する。したがって、リアルタイム・スケジューリング・シナリオの議論から開始するが、最初の検討事項は、「リアルタイム・スケジューリング」によって何が意味されるかについて正確に定義することである。上記のセクションにおいては、バッチ実行とは逆に、サービス・プロバイダがリアルタイム・プログラミングを提供できると述べた。ここではこれらの用語を、いくつかの「クライアント・プロセス」の「通信」モデルに関連して定義する。
ジョブ要求またはサービス要求は、クライアント・プロセスを実行するいずれかのクライアントによって開始される。バッチ・プログラミング・モデルにおいては、ジョブ要求のポスティングの後にクライアント・プロセスが「終了」する。またバッチ・プログラミング・モデルにおいては、通常、ジョブとクライアント・プロセスの間にアクティブな通信チャンネルが存在しない。リアルタイム・プログラミング・モデルにおいては、クライアント・プロセスが持続的なサービス・プロバイダとインタラクションを行うことができる。リアルタイム・インタラクションは、サービス要求スケジューラの設計を考慮する上で極めて重要である。特に、リアルタイム・インタラクションは、サービスが「ステートフル」となることを可能にし、言い換えるとサービスが、所定のクライアントのインタラクションに関連するデータを保持できる。状態を扱う機能は、最近になってウェブ・サービス・テクノロジに追加され、それがＯＧＳＡにおける主要な設計ポイントになっている。
ステートフル・モデルの利点を論ずるため、それがプログラミング・モデルにもたらす利点について考察する。サービス・プロバイダにおいてアクティブ状態の維持が可能なことから、クライアント・プロセスは、入力として以前の要求の結果の参照を使用するサービス要求を作成することができる。ここではこの機能を「サーバ側キャッシング」と呼び、ＴＡＧＳＳアーキテクチャが、どのようにしてこの機能を実装しているかについて、ＴＡＧＳＳプログラミング・インターフェースを紹介しつつ論ずることにする。
ＴＡＧＳＳプログラミング・モデルを紹介するためには、ＴＡＧＳＳジャバ・プログラミング・インターフェースを引き合いに出すと有用である。また、Ｃ等のネイティブ言語における拘束もあるが、サービスとジャバ・オブジェクトの間における強い類似から、ジャバＡＰＩは、この議論にとって好ましい。実際に、自動化されたツールを使用してジャバ・オブジェクト定義をＷＳＤＬサービス記述にマップすることが可能である。このセクションにおいては、サービス・ベースの定義に関するフレームワークを開示する。
コンテナ・サービスについては、ＴＡＧＳＳアーキテクチャの目的の１つが、単純なリアルタイム・プログラミング・モデルの提供である。ジャバにおいては、オブジェクトがジャバ仮想マシン、またはＪＶＭと呼ばれるランタイム環境内において実行される。サービスの類比に関して言えば、サービスが「コンテナ」内において実行される。ＴＡＧＳＳアーキテクチャは、この類比に倣い、「コンテナ・サービス」を定義する。コンテナ・サービスは、「オブジェクト作成」および「オブジェクト・メソッド起動」に関連するサービスを提供する。これらのコンセプトは、サービス・インスタンスの作成、およびサービス要求の取り扱いに関連する。
本発明は、コンテナ・サービス・ファクトリを提供する。サービスを定義する主要な側面の１つは、その作成および破棄の行われる方法である。ＯＧＳＡにおいては、サービス・インスタンスが「ファクトリ・インターフェース」内に実装される仕様に従って作成される。グリッドに関するモデルのプログラミングの提案における主要な問題は、このインターフェースをどのように働かせるかということになる。クライアント・プロセスがサービス要求をポスティングするためには、それをサービス・プロバイダ・インスタンスと結び付ける必要がある。サービス作成のタスクが、更新後のリソース利用測度の観察に関連して行われなければならないことから、ＴＡＧＳＳアーキテクチャは、コンテナ・サービスの作成において主要な役割を演じる「リソース・モニタリング・サービス」を定義する。このリソース・モニタリング・サービスは、「スケジューラ・サービス」と命名されている。スケジューラ・サービスは、ノードのプール内におけるリソースの利用を継続的にモニタし、そのノードのプール内におけるコンテナ・サービスの作成をコントロールする。
スケジューラ・サービスが、コンテナ・サービスを直接作成することはない。ＴＡＧＳＳアーキテクチャにおいては、スケジューラ・サービスが、図２に示されている次のプロセス／システムによって実装される。中心プロセスであるＴＡＧＳＳスケジューラ２００は、ノードのプール２１０（または「最小スケジューリング・ドメイン」）内におけるリソース利用測度を収集し、この最小スケジューリング・ドメイン内におけるコンテナ・サービスに関するすべての要求を処理する。「ＴＡＧＳＳスケジューラ２００」が所定の最小スケジューリング・ドメインに関して処理するインスタンスは１つだけである。
ＴＡＧＳＳエージェント２０５は、周期的なリソース利用測定を行い、それらの測度を、その特定の最小スケジューリング・ドメインのＴＡＧＳＳスケジューラ２００に対してレポートする。またＴＡＧＳＳエージェント２０５は、コンテナ・サービスのファクトリ・インターフェースの実装を受け持つ。コンテナ・サービスは、所定のクライアントに割り当てられるようにしてもよく、またサービス・ポリシーの質に従って、いくつかのクライアントによって共有されるようにしてもよい。これらの２つの可能性については、後述のシナリオの中で説明する。
図２に、排他的コンテナ・サービスに結びつけるときに、クライアント要求に応答してオンデマンドでどのように排他的コンテナ・サービスが作られるかについてのメッセージ・フロー（１〜６）を例示した。図２に示されているように、クライアント・プロセス２１５は、まずＴＡＧＳＳスケジューラ２００に対して要求を送り、コンテナを獲得する（１）。続いてＴＡＧＳＳスケジューラ２００は、ＴＡＧＳＳエージェント２０５に対してインストラクションを送り、コンテナを作成する（２）。ＴＡＧＳＳエージェント２０５は、新しいコンテナ２２０を生み出すことによって応答する（３）。ＴＡＧＳＳエージェント２０５は、その後、ＴＡＧＳＳスケジューラ２００にコンテナ参照を返す（４）。一方、ＴＡＧＳＳスケジューラ２００は、このコンテナ参照をクライアント・プロセス２１５に返す（５）。それによりクライアント・プロセス２１５が新しいコンテナ２２０と結び付く（６）。ここで気付くことができるが、クライアント・プロセス２１５は、ＴＡＧＳＳスケジューラ２００、およびコンテナ・サービスのインスタンス２２０とだけ直接的な通信を行っており、ＴＡＧＳＳエージェント２０５とはそれを行っていない。ＴＡＧＳＳエージェント２０５の存在は、それらがスケジューラ・サービスの統合された一部であることから、クライアント・プロセス２１５に対してトランスペアレントになる。
共有コンテナ・サービスに対する結び付きに関して言えば、前述したように、クライアント・プロセスがコンテナを共有することも可能である。このアプローチは、各グリッド・ホスト２１０内において作り出されるコンテナの数が抑えられるという利点を有している。異なるランタイム実行優先度を有する共有コンテナを使用して異なるレベルのサービスの質を提供することが可能である。特定のコンテナに対するクライアントのマッピングは、その後、管理ポリシーまたはサービス・レベル合意（ＳＬＡ）に従ってなされる。しかしながら、共有コンテナの展開は、包括的なセキュリティ・インフラストラクチャを要求する。本発明は、ジャバ・サーブレット環境に使用されているものに類似のフレームワークを使用して、共有コンテナに関する適切なセキュリティを提供することができる。
次に示すプログラミング例は、コンテナ・サービス２２０に対するクライアント・プロセス２１５の結び付けを例証している。このＴＡＧＳＳ ＡＰＩの説明においては、この開示が与えた後の当業者であれば、共有および非共有コンテナの間の差を理解できることから、その区別が必要でないとしている。以下のコード・セグメントは、どのようにしてクライアントが単一のコンテナ・サービスに結び付くか（６）について例示している。図３に示されているように、スケジューラ・サービス２００は、「グリッド」オブジェクト（ｏｂｊ１〜ｏｂｊ８）を作成する。グリッド・オブジェクト（ｏｂｊ１〜ｏｂｊ８）が作成されると、クライアント・プロセス２１５が所定のスケジューラ・サービス２００に結び付けられる。ＴＡＧＳＳスケジューラ２００プロセスのネットワーク・アドレスおよびポート番号は、コンストラクタ引数として、グリッド・オブジェクト（ｏｂｊ１〜ｏｂｊ８）の作成時に渡される。オブジェクト（ｏｂｊ１〜ｏｂｊ８）が作成された後は、クライアント・プロセス２１５がそれを使用して、図２のＧｒｉｄ．ｇｅｔＣｏｎｔａｉｎｅｒ（）メソッド（１）を実行することによって多数のコンテナ・サービス３００〜３０１に結び付くことができる。
<コード・セグメント１：グリッド・プロバイダに対する接続>
Grid myGrid = newGrid("tagss_scheduler_hostname", tagss_scheduler_port);
GridContainer myContainer =myGridContainer.getContainer();
オブジェクト（ｏｂｊ１〜ｏｂｊ８）の作成について言えば、クライアント・プロセス２１５がコンテナ・サービス３００〜３０１に結び付くと、別のサービスを作成することが可能になる。ジャバＡＰＩ内においては、そのサービスがジャバ・オブジェクトによって表される。新しいオブジェクトの作成は、ＧｒｉｄＣｏｎｔａｉｎｅｒ．ｃｒｅａｔｅＯｂｊｅｃｔ（メソッド）を起動することによってなされる。このメソッドは、作成されるオブジェクトの完全な修飾名およびコンストラクタ・パラメータを必要とする。図３に示されているように、ＧｒｉｄＯｂｊｅｃｔＡｒｒａｙ（８）インストラクションは、ＴＡＧＳＳスケジューラ２００に対して８つのオブジェクトの作成を指示する。コンテナ３００および３０１のそれぞれの中に３つのオブジェクト（ｏｂｊ１〜ｏｂｊ３；ｏｂｊ４〜ｏｂｊ６）が作られ、２つのオブジェクト（ｏｂｊ７、ｏｂｊ８）がコンテナ３０２内に作られる。コンストラクタ・パラメータは、ジャバのＡｒｒａｙＬｉｓｔを使用してプログラミング環境から直接的に取得される。内部的にＴＡＧＳＳ ＡＰＩは、ＡｒｒａｙＬｉｓｔ内に渡されるオブジェクト・シーケンスを所定のメソッドの適切なコンストラクタに整合させるために、ジャバｒｅｆｌｅｃｔｉｏｎクラスを使用することになる。
<コード・セグメント２：グリッド・オブジェクトの作成>
//myObjectClass型のGridObjectを作成する。
//コンストラクタはシグニチャ（整数、倍精度、文字列）を有する；
Integer arg1 = new Integer(123);
Double arg2 = new Double(1.23);
String arg3 = "hello"
ArrayList args = new ArrayList();
args.add(arg1);
args.add(arg2);
args.add(arg3);
GridObject myObject =
myContainer.createObject("myObjectClass",args);
結果として得られるＧｒｉｄＯｂｊｅｃｔは、ユーザ定義クラス型にキャストすることができる。
ＧｒｉｄＯｂｊｅｃｔ内のメソッドの起動に関して言えば、ＧｒｉｄＯｂｊｅｃｔ内のメソッドの実行に必要なステップは、オブジェクトの作成におけるそれに類似である。メソッドの名前は、文字列として渡され、引数は、ＡｒｒａｙＬｉｓｔを使用して渡される。
<コード・セグメント３：グリッド・オブジェクトに関するメソッドの起動>
//myObjectがコード・セグメント2にあるとおりに作成されたと仮定
//シグニチャ（整数、倍精度、文字列）を有するメソッドの起動準備；
Integer arg1 = new Integer(123);
Double arg2 = new Double(1.23);
String arg3 = "hello"
ArrayList args = new ArrayList();
args.add(arg1);
args.add(arg2);
args.add(arg3);
MyReturnObjectClass myResult =(MyReturnObjectClass)
myObject.invoke("myMethod",args);
この場合においてもメソッドのシグニチャが、ジャバｒｅｆｌｅｃｔｉｏｎを使用する適切なメソッドに整合される。このメソッドの起動の結果は、新しいＧｒｉｄＯｂｊｅｃｔとして返される。戻り値は、メソッド起動の期待される型にキャストすることができる。現在のところ、返された結果に関してパラメータ変数を使用することはできない。
サーバ側キャッシングに関して言えば、ＴＡＧＳＳ ＡＰＩは、ＧｒｉｄＯｂｊｅｃｔ．ｉｎｖｏｋｅ（）メソッドのバリアントを提供し、それが、前述したサーバ側キャッシング機能を実装する。ＧｒｉｄＯｂｊｅｃｔ．ｉｎｖｏｋｅＫｅｅｐ（）は、メソッドの起動の結果に対する参照だけを返すが、結果自体は、メソッドが起動されたコンテナ内に保持される。これらの結果は、ＧｒｉｄＯｂｊｅｃｔ．ｇｅｔＶａｌｕｅ（）メソッドを使用して、その後において取り出すことができる。次に示す例は、クライアントとサービス・プロバイダの間において転送を必要とするデータの量を最小化するために、どのようにすればアプリケーションがＧｒｉｄＯｂｊｅｃｔ．ｉｎｖｏｋｅＫｅｅｐ（）に対する呼び出しを連結できるかについて示している。下の例においては、イメージ画質向上アプリケーションが３つのフィルタのシーケンスをイメージに適用し、最終結果だけを取り出している。中間結果はクライアント・プロセスにまったく返されず、中間結果の全ラウンドトリップが節約される。このテクニックは、イメージ処理等の大きなデータを操作するアプリケーションにとって重要になる。
<コード・セグメント４：グリッド・オブジェクト内における持続状態の使用>
//myObjectClass型のGridObjectを作成する。
//コンストラクタはシグニチャ（整数、倍精度、文字列）を有する；
Integer arg1 = new Integer(123);
Double arg2 = new Double(1.23);
String arg3 = "hello"
ArrayList args = new ArrayList();
args.add(arg1);
args.add(arg2);
args.add(arg3);
GridObject myObject =
myContainer.createObject("myObjectClass",args);
この場合においても、戻り値を任意のユーザ定義クラス型にキャストできることに注意が必要である。
より高いレベルの作成に関しては、上記の基本のプリミティブが、グリッド環境内における個別のオブジェクトを操作する非常に柔軟なインターフェースを提供する。しかしながら、ほとんどのグリッド・アプリケーションは、並列化可能なタスクを実行するために、より高いレベルの作成を要求する。ＴＡＧＳＳプログラミング・インターフェースは、並列オペレーション用により高いレベルのプリミティブのセットを提供する。一例とする実施態様においては、本発明が３つのより高いレベルのオペレーションを提供する：メッセージ・マルチキャスト、バリア強制メソッド起動、およびスキャッタ／ギャザのオペレーションである。これらの関数は、以下に説明するオブジェクト収集を操作するＴＡＧＳＳ内の追加のプリミティブによって提供される。
グリッド・コンテナ配列３０７は、コンテナ３００〜３０２の集合を表す。コンテナ配列は、コンテナと同一の関数セットを実装し、コンテナ配列内において起動されるメソッドは、コンテナ配列内の部分である各コンテナに対して適用される。コンテナ配列ファクトリ・インターフェースもまた、グリッド・オブジェクト（ｏｂｊ１〜ｏｂｊ８）によって表されるサービス・スケジューラによって実装される。コンテナ配列を作成するメソッドは、Ｇｒｉｄ．ｇｅｔＣｏｎｔａｉｎｅｒＡｒｒａｙ（）である。このメソッドは、希望のコンテナ数を示す整数を引数とする。返される実際のコンテナ数は、リソース不足の場合には、希望された数より少ないこともある。返される実際のコンテナ数は、ＧｒｉｄＣｏｎｔａｉｎｅｒＡｒｒａｙ．ｇｅｔＮｕｍｂｅｒＣｏｎｔａｉｎｅｒｓ（）を起動することによって獲得される。希望のコンテナ数の引数として値０（ゼロ）が渡された場合には、グリッド・スケジューラが、リソース利用状況に従って、かつクライアントの信用証明に従って利用可能な最大数のコンテナを返す。次に示す例は、ＣｏｎｔａｉｎｅｒＡｒｒａｙコンストラクタのシンタクスを例証している。
<コード・セグメント５：グリッド・コンテナ配列の作成>
GridContainerArray myContainerArray =Grid.getContainerArray(0);
int numberOfContainers =myContainerArray.getNumberContainers
すでに述べたように、グリッド・コンテナ配列３０７は、個別のコンテナに類似する機能セットを実装する。コンテナがグリッド・オブジェクト（ｏｂｊ１〜ｏｂｊ８）を作成するファクトリであるように、グリッド・コンテナ配列３０７は、グリッド・オブジェクト配列３０６の型のオブジェクトのファクトリである。グリッド・オブジェクト配列３０６を作成するメソッドは、ＧｒｉｄＣｏｎｔａｉｎｅｒＡｒｒａｙ．ｃｒｅａｔｅＯｂｊｅｃｔ（）である。このメソッドは、入力引数として、作成されることになるオブジェクト型の名前（クラス名）および起動されることになる各コンストラクタ呼び出しに関する引数を含むデータ構造を取る。引数リストは、同一のシグニチャを有していること、すなわち引数シーケンス内において同一の値を用いてインデクスされたそれぞれのオブジェクトが、同一のクラス型である必要がある。オブジェクト配列の作成用の引数リストの作成を容易にするために、ＴＡＧＳＳインターフェースは、ＧｒｉｄＤａｔａＳｅｔと呼ばれる補助データ構造を使用する。ＧｒｉｄＤａｔａＳｅｔは、マトリクスとしてビジュアル化可能であり、それにおいては、各行がオブジェクト配列内のコンストラクタまたはメソッドの起動に適用されることになる引数リストになる。したがって、ＧｒｉｄＤａｔａＳｅｔの各列は、同一データ型のオブジェクトを含んでいる必要がある。たとえば、次の例示は、シグニチャ「整数、倍精度、文字列」のコンストラクタを起動するためのＧｒｉｄＤａｔａＳｅｔを構築する方法を示している。
<コード・セグメント６：グリッド・データ・セットの作成>
//入力値がintArray、doubleArray、およびStringArray内にあると仮定する
GridDataSet myGridDataSet = newGridDataSet();
ArrayList singleRow = new ArrayList();
for( i = 0; i < inputSize; i++ )
{
singleRow.add(intArray[i]);
singleRow.add(doubleArray[i]);
singleRow.add(StringArray[i]);
myGridDataSet.addRow(singleRow);
singleRow.clear()
{
ここで注意する必要があるが、ＧｒｉｄＤａｔａＳｅｔ内の行の数がコンテナの数に等しくなる必要がないことは重要である。本発明は、コンテナの単なるサブセットとしてオブジェクトを構築し、図３に示されるように、１つのコンテナ内に複数のオブジェクト・インスタンスを作成することによって、コンテナの数より多いオブジェクトを作成する。より詳細に述べれば、図３は、３つのコンテナだけが利用可能な場合に、８つのオブジェクトを伴うＧｒｉｄＯｂｊｅｃｔＡｒｒａｙの作成を試みるクライアントを示している。クライアントは、それにもかかわらず利用可能なコンテナ内に複数のオブジェクトを作成することによって、８つのオブジェクトを伴うグリッド・オブジェクト配列３０６の作成に成功している。
オブジェクト配列３０６内においてメソッドを実行するとき、オブジェクト配列３０６は、コンテナ配列３０７に類似のセマンティクスを有している。オブジェクト配列３０６に指向されたメソッドの起動は、オブジェクト配列３０６の各オブジェクト・インスタンスにおけるメソッドの起動を結果としてもたらす。この複数のメソッドの起動の結果は、ＧｒｉｄＯｂｊｅｃｔＡｒｒａｙ内に返され、それにおいてはｉ番目の要素がＧｒｉｄＤａｔａＳｅｔのｉ番目の行を使用するメソッド起動の結果となる。次のコード・セグメントは、ＧｒｉｄＯｂｊｅｃｔＡｒｒａｙに関するメソッドの起動を例証している。
<コード・セグメント７：グリッド・オブジェクト配列に関するメソッドの起動>
//グリッド・オブジェクト配列を作成する
GridObjectArray myGridObjectArray =
GridContainerArray.createObject(myGridDataSet);
//inputSet内に入力データをロードしたものと仮定する
GridDataSet inputSet = loadDataSet();
//グリッド配列に関するメソッドを起動する
GridObject[] resultArray =
myGridObjectArray.invoke("methodName",inputSet, invokation_mode);
次に、引数ＴＡＧＳＳＩｎｖｏｃａｔｉｏｎＭｏｄｅを使用して指定される、グリッド・オブジェクト配列３０６内におけるメソッド起動の３つのモードを説明する。
最初のモードは、ＴＡＧＳＳ＿ＩＮＶＯＫＥ＿ＭＵＬＴＩＣＡＳＴである。この起動モデルは単一のパラメータ・リストを伴って使用され、残り２つのモードと異なりグリッド・データ・セットを伴わない。この起動モードでは、メソッドがグリッド・オブジェクト配列３０６のすべてのオブジェクト内において、単一のパラメータ・リスト内に含まれているまったく同一のパラメータのセットを伴って起動される。この起動モードが使用されて、同期メッセージがオブジェクトに送られる。
もう１つのモードは、ＴＡＧＳＳ＿ＩＮＶＯＫＥ＿ＥＡＣＨである。この起動モードは、ＧｒｉｄＤａｔａＳｅｔ内の各行が配列内の対応するオブジェクトに適用される必要があることを指定する。つまり、行０がオブジェクト０に適用され、行１がオブジェクト１に適用されるといった態様になる。このモードにおいては、ＧｒｉｄＤａｔａＳｅｔ内に指定されている行の数が配列内のオブジェクトの数と等しいか、それより小さくなる必要がある。このメソッド起動モードは、バリア強制メソッド起動用に使用される。
さらに別のモードは、ＴＡＧＳＳ＿ＩＮＶＯＫＥ＿ＡＮＹである。この起動モードは、ＧｒｉｄＤａｔａＳｅｔの行と、グリッド・オブジェクト配列３０６内のオブジェクトの間におけるマッピング要件を指定しない。このモードは、基礎をなすスケジューリング・インフラストラクチャに関する大きな柔軟性を提供する。たとえば、１０個のオブジェクトを伴うオブジェクト配列に、１，０００行のＧｒｉｄＤａｔａＳｅｔに関するメソッドの起動を指示することが可能である。いずれのオブジェクトがいずれの行に作用するかというマッピングについては、後述するように、ＴＡＧＳＳ内の基礎をなすスケジューリング・インフラストラクチャによってランタイム時に行われる。この起動方法は、スキャッタ／ギャザ・プログラミング・モデル内において使用される。上記の３つの起動モードは、ＴＡＧＳＳ内に次の３つの基本並列プログラミング・モデルを実装する：すなわち「メッセージ・マルチキャスト」、「バリア強制メソッド起動」および「スキャッタ／ギャザ」である。これら３つのプログラミング・モデルについては、以下に詳細を説明する。
メッセージ・マルチキャスト・モードは、単純に単一のメッセージをオブジェクトの集合に送るプログラミング・モデルである。ＴＡＧＳＳ ＡＰＩは、単一の引数リストを取り、かつそれをグリッド・オブジェクト配列３０６内のすべてのオブジェクトに適用するメソッド起動関数を提供することによって、このモデルをサポートしている。
<コード・セグメント８：メッセージ・マルチキャスト・プログラミング・モデルの使用>
GridObject[] result =myGridObjectArray.invoke("methodName", argList,TAGSS_INVOKE_MULTICAST);
バリア強制並列メソッド起動は、拘束された方法に従って複数のオブジェクトがデータに作用することを必要とするいくつかの並列プログラミング・メソッドを実装するために使用することが可能なプログラミング・モデルである。オブジェクト４００〜４０３の間における拘束されたオペレーションを図４に示す。この種の起動においては、オブジェクトがすべて、特定のメソッドを完了した後でなければ次のメソッドを起動することができず、言い換えると各メソッドの実行を同期させる暗示的なバリアが存在する。たとえば、次に示すコード・セグメントは、直前の計算の結果を、シフト繰り上げ態様で配列内の各オブジェクトにリダイレクトするパイプラインを実装しており、バリア同期を使用して、各メソッド起動前に結果が完成することを保証している。
<コード・セグメント９：シフト‐結果‐バリア・パターンの実装>
//バリア同期の例
//入力がすでにGridDataSet内にロードされていると仮定する
//結果を右にシフトするパイプラインを使用する3つのメソッドを起動する
GridObject[] result =myGridObjectArray.invoke("first_stage", inputDataSet,TAGSS_INVOKE_EACH);
//結果を右にシフトする
GridObjecttemp = result[result.size();
//最後の要素を順次ラップアラウンドする
for (i = 0;i < result.size()-1;i++)
result[i+1] = result[i];
result[0] = temp;
//ラップアラウンド
//第2ステージを呼び出す
GridObject result2 =myGridObjectArray.invoke("second_stage", inputDataSet,TAGSS_INVOKE_EACH);
たとえば、４つのオブジェクトに関して上記のコードを実行すると、図４に示されている通信パターンが設定される。
スキャッタ／ギャザ・モデルは、ＴＡＧＳＳ＿ＩＮＶＯＫＥ＿ＡＮＹ起動モデルが指定されたときに使用される。この場合においては、ランタイム条件に従ってＧｒｉｄＤａｔａＳｅｔの行がグリッド・オブジェクトに割り当てられる。行のマッピングは、メソッド起動を完成する各オブジェクトのケイパビリティに従ってなされる。ランタイム・スケジューリングは、図５に示されているように、ＴＡＧＳＳクライアント・スケジューラ（またはマイクロ・スケジューラ）５００と呼ばれる、クライアント・アプリケーションに代わってランタイム時に作成されるビルトイン・スケジューリング・エージェントによって行われる。
マイクロ・スケジューラ５００は、小規模のマルチ‐スレッド・オブジェクトであり、グリッド・コンテナ配列３０７が作成されるときに「暗示的に」組み込まれる。各グリッド・コンテナ配列３０７は、独自のＴＡＧＳＳクライアント・スケジューラ５００のインスタンスを有している。ＴＡＧＳＳマイクロ・スケジューラ５００は、グリッド・オブジェクト配列３０６内のオブジェクト（ｏｂｊ１〜ｏｂｊ８）の間に行を散乱させ、その後、オブジェクト（ｏｂｊ１〜ｏｂｊ８）によるタスクの完了時に新しい行をスケジュールする。つまり、図５に示されているように、クライアント・プロセス２１５が、データ・セットを用いてグリッド・オブジェクト配列３０６を起動する（１１）。ＴＡＧＳＳスケジューラ２００は、そのデータ・セットを用いて特定のメソッドを起動する（１２）。ＴＡＧＳＳマイクロ・スケジューラ５００が、各種のオブジェクト（ｏｂｊ１〜ｏｂｊ８）に対してデータ・セットの行を起動し（１３）、そのそれぞれが、行の１つに関する特定のタスクを実行する。オブジェクトによるタスクの完了時に、ＴＡＧＳＳマイクロ・スケジューラ５００が、グリッド・オブジェクトを返す（１４）。
ＴＡＧＳＳクライアント・スケジューラ・オブジェクトの配置は、全体的なＴＡＧＳＳアーキテクチャを考慮して行われ、かつグリッド・トポロジに従い、ＴＡＧＳＳマイクロ・スケジューラ５００が多数のネットワーク・トラフィックならびにＩ／Ｏプロセッシングを生成することを考慮して行われる。ＴＡＧＳＳクライアント・スケジューラ５００を走らせるコンテナ３００は、メッセージ・マルチキャストならびにスキャッタ／ギャザ・モデルの両方における中心座標点である。ＴＡＧＳＳマイクロ・スケジューラ５００は、オブジェクト配列３０６内のすべてのオブジェクト（ｏｂｊ１〜ｏｂｊ８）と通信し、一定してメソッド起動に関する入力データを渡すだけでなく、完了時には出力データを収集する。
これらの条件は、クライアント・プロセス２１５がＴＡＧＳＳマイクロ・スケジューラ５００の配置に関して充分な選択力を持たないことを示している。つまりグリッド内の通常の構成がクライアント・プロセス２１５をネットワークのフリンジに配置し、そのネットワークの中心よりはるかに低速なネットワークを介して接続されることからそのようになる。
ＴＡＧＳＳマイクロ・スケジューラ５００に関する最良ロケーションを選択するために、ＴＡＧＳＳアーキテクチャは、最良パフォーマンス（そのグリッド・コンテナ配列内のほかのコンテナと比較した場合）を提供することになるコンテナ内にＴＡＧＳＳマイクロ・スケジューラ５００を配置する。コンテナの選択は、コンテナ配列３０７が作成された時点において利用可能なパフォーマンス測定（たとえば、プロセッシング速度、入力／出力キャパシティおよびボリューム等）に従ってなされる。慣例によりＴＡＧＳＳスケジューラ・サービス２００は、サービスのクライアントの減少順でコンテナの順序設定（ランク付け）を行い、０（ゼロ）によりインデクスされたコンテナがグリッド内の最良パフォーマンス・コンテナになる。グリッド・コンテナ配列３０７が作成されるとき、ＴＡＧＳＳマイクロ・スケジューラ５００は、コンテナ０（ゼロ）内に作成される。
バッチ起動に関して言えば、ランタイム・スケジューリング・プロセスは、バッチ起動をサポートする。つまり、クライアントが大規模な並列要求のポスティング後に終了することを希望した場合には、ＴＡＧＳＳアーキテクチャが、ＧｒｉｄＯｂｊｅｃｔ．ｉｎｖｏｋｅＡｓｙｎｃ（）メソッドにより利用可能となる非同期起動オプションを実装することによってその機能を提供する。このメソッドは、ＧｒｉｄＯｂｊｅｃｔに対する持続的参照である要求参照のＧｒｉｄＢａｔｃｈを返す。クライアント・プロセスは、この参照を持続的ストレージ内に保存し、その後の時点においてＧｒｉｄＯｂｊｅｃｔを取り出すことができる。クライアント・プロセスは、メソッドＧｒｉｄＢａｔｃｈ．ｐｅｅｋ（）を使用してＧｒｉｄＢａｔｃｈの完了に関するクエリを行うことが可能であり、これは、ＧｒｉｄＢａｔｃｈが完了したときに「真」を返し、その時点においては、ＧｒｉｄＢａｔｃｈ．ｇｅｔＲｅｓｕｌｔ（）メソッドを起動することによって結果を取り出すことができる。この処理に関するコード例を次に示す。
<コード・セグメント１１：並列起動の同期のためのＷａｉｔ Ｃｏｎｄｉｔｉｏｎｓの使用>
//3つの大規模オペレーションを並列に実行し、その後すべてが完了するまで待機する
GridBatch batch1 =GridObjectArray1.invokeAsync("method1", dataSet1);
GridBatch batch2 =GridObjectArray2.invokeAsync("method2", dataSet2);
GridBatch batch3 =GridObjectArray3.invokeAsync("method3", dataSet3);
//バッチ1が完了したか否かをチェックする
Boolean isComplete = batch1.peek();
//バッチ1が完了するまで待機する
GridObject[] result = batch.waitOnComplete();
//バッチ2および3がともに完了するまで待機する
GridWaitCondition waitCondition = newGridWaitCondition(batch2);
waitCondition.add(batch3);
waitCondition.waitOnComplete();
本発明は、インタラクティブおよびオフラインのクライアント・プロセスの両方に適用することができる。前述したプログラミング・パラダイムは、インタラクティブ・クライアント・プロセスに限定されない。クライアント要求は、オフラインの提出も可能である。その場合、クライアント・プロセスを実行するコード自体がオフライン・ジョブ要求として送られる必要がある。クライアント・プロセスの実行は、その後、ジョブ・スケジューリング・パラダイムに従うことになる。クライアント・プロセスがスケジュールされ、起動された後は、そのスケジューリング・リソースを伴うリアルタイム・セッションが設定され、続いてスケジューリング・プロセスが、前述と同様にリアルタイムで作用する。
ＴＡＧＳＳアーキテクチャは、分散環境においても良好に作用する。最良のパフォーマンスのためには、類似した特徴を伴うノードが、単一のサービス・スケジューラによってコントロールされる「最小スケジューリング・ドメイン」内にグループ化される必要がある。最小スケジューリング・ドメインのサイズは、ＴＡＧＳＳマイクロ・スケジューラ５００を実行するノードのパフォーマンスに影響を与えることになる。
ＴＡＧＳＳアーキテクチャは、複数の最小スケジューリング・ドメインにわたってタスクを分散させる単純な方法を提供する。すでに述べたように、タスク・スケジューリングは、ＴＡＧＳＳマイクロ・スケジューラ５００、すなわち各グリッド・コンテナ配列３０７内の区別されたコンテナ内に作成される小規模のマルチ‐スレッド・オブジェクトによって行われる。最小スケジューリング・ドメインにわたってスケジュールを行うために、複数のグリッド・オブジェクト配列を使用して複合グリッド・オブジェクト配列３０６が構築される。その後、スケジューリング・タスクが、各グリッド・オブジェクト配列３０６内のＴＡＧＳＳクライアント・スケジューラの間において仕切られる。
この強力な特徴は、クライアント・プロセスにとってトランスペアレントである。ＴＡＧＳＳマイクロ・スケジューラ５００オブジェクトがＴＡＧＳＳインフラストラクチャによって暗示的に作成されたように、複数のオブジェクト間における作業負荷の分割についても、前述したオブジェクト作成およびメソッド起動のセマンティクスに従って暗示的に生じる。
複数オブジェクトの間にタスクを分散させるためにすべてのクライアント・アプリケーションが行わなければならないことは、複合グリッド・オブジェクトの構築だけである。これは、以下に示すようにメソッドＧｒｉｄ．ａｄｄ（）を使用することによって行われる。このメソッドは、グリッド・オブジェクトを、別のスケジューリング・ドメインのＴＡＧＳＳスケジューラ２００に結び付ける。たとえば、以下に示すコードならびに図６においては、『ゲートウェイ１』６００に結び付けられるグリッド・オブジェクト配列３０６が作成され、続いてそれがＧｒｉｄ．ａｄｄ（）メソッドを使用して『ゲートウェイ２』６０１に結び付けられる。第２のゲートウェイ６０１は、詳細を前述したグリッド・コンテナ配列３０７と実質的に類似のグリッド・コンテナ配列３０８に接続される。グリッド・コンテナ配列３０８は、異なるホスト２１１を使用し、かつコンテナ３０３〜３０５内のオブジェクトｏｂｊ９〜ｏｂｊ１６からなる、異なってはいるが類似のグリッド・オブジェクト配列３０７を含む。ホスト２１１は、ホスト２１０から地理的に分離することができる。しかしながら好ましくはホスト２１１を局部的なネットワーク内（たとえば、１つの組織内）に置き、ホスト２１０も同様に、それぞれの局部的なネットワーク内に置く。前述したように、各グリッド・コンテナ配列は、独自のＴＡＧＳＳマイクロ・スケジューラを必要とする。したがって、グリッド・コンテナ配列３０８は、ＴＡＧＳＳマイクロ・スケジューラ５０１を備える。グリッド・コンテナ配列３０７およびグリッド・コンテナ配列３０８は、複合グリッド・コンテナ配列６０８を構成し、それにはすべてのゲートウェイにおいて利用可能な最大数のコンテナが含まれる。図６は、グリッド・オブジェクト配列３０６およびグリッド・オブジェクト配列３０７から構成された、結果として得られる複合グリッド・オブジェクト配列６０７についても示している。複合グリッド・コンテナ配列６０８および複合グリッド・オブジェクト配列６０７は、実質的に異なるコンピューティング・ケイパビリティを有することもある複数のドメイン（たとえば、２１０および２１１）に及ぶ。ここで注意が必要であるが、複合グリッド・オブジェクト配列のセマンティクスまたはＡＰＩ内には差がなく、最小スケジューリング・ドメインを超えてそれが広がるという事実は、クライアント・プロセス２１５にとってトランスペアレントである。次に示すコーディング例は、０（ゼロ）個のコンテナを指定するメソッドＧｒｉｄ．ｇｅｔＣｏｎｔａｉｎｅｒＡｒｒａｙ（）を使用してグリッド・オブジェクト内のすべてのコンテナを求める要求を行う。
<コード・セグメント１２：複合グリッド・コンテナの使用>
//2つの異なるドメイン内のサービス・スケジューラに接続する
Grid grid1 = new Grid("gateway1",1234);
Grid1.add("gateway2", 1234);
//2つの異なるドメインからのコンテナを使用して大規模グリッド・コンテナ配列307を構築する
GridContainerArray bigContainerArray =grid1.getContainerArray(0);
//2つのドメインに及ぶオブジェクト配列を作成する
GridObjectArray bigObjectArray =
bigContainerArray.createObject("objectType", inputArgs);
//オブジェクト配列に関するメソッドを起動する
GridObjectArray bigResult =
bigObjectArray.invoke(methodName",methodArgs);
図６は、上記の例のマルチ・クラスタ環境において上記のコードを使用して作成されたオブジェクトを示している。図７は、ゲートウェイ６００、６０１の間の通信効率における補助を行うグリッド・ポータル７００を含んでいる。ここで注意する必要があるが、上記の例は２段スケジューリング階層構造を紹介している。サービス・スケジューラに対するプロキシとして作用し、複合グリッド・オブジェクト配列を構築する中間プロセスを採用する多段階層構造についても、本発明とともに利用可能である。たとえば図８は、グリッド・ポータルを含むアウトソーシング組織８００を示しており、複数のクライアント・プロセス２１５、２１６、複数のスケジューラ２００、２０１が、複数のグリッド・コンテナ配列３０７〜３０９にアクセスする別のグリッド・ポータル７００、７０２に接続されている。図８に示されているシステムにおいては、複合グリッド・コンテナ配列３０７〜３０９および複合グリッド・オブジェクト配列６０７が成長してアウトソーシング組織８００のコントロール下となるすべてのオブジェクトならびにコンテナを含む。
グリッド・ポータルは、いくつかの個別の最小サービス・ドメインからのコンテナを収めるように構成される。また、グリッド・ポータルがサービス・スケジューラ２００、２０１に対するトランスペアレントなプロキシであることから、本発明においては、任意数のグリッド・ポータルの連結が可能であり、その結果、深い階層構造がもたらされる。グリッド環境内においてどのようにＴＡＧＳＳアーキテクチャが展開されるかについての可能性のある構成はいくつか存在し、上記は、もっとも単純な構成の１つを示唆している。議論を単純化するために、ここで組織に関する２つの基本的な役割を考える：それをサービス・プロバイダまたはサービス・アウトソーサとすることができる。これにおける基本構成は、グリッド・ポータルが、インバウンドおよびアウトバウンドのサービス要求のすべてのフローを調整するべく構成されることを示唆する。これは、すべての要求を監査するインフラストラクチャを可能にする。アウトソーシング組織のグリッド・ポータルは、特定のグリッド証明書の下に実行され、それを伴ってサービス・プロバイダ組織のグリッド・ポータルからリソースを獲得する。
一実施態様においては、ＴＡＧＳＳプロセス：サービス・スケジューラ２００、２０１、およびグリッド・ポータル７００〜７０２が、システム管理者によって開始され、構成される。別の実装は、それらのプロセスを単一のクライアント（ユーザまたは組織）に代わってオンデマンドで開始する。たとえば図８においては、アウトソーシング組織が、ジョグ要求を（アプリケーション・コードとともに）、要求されたグリッド・ポータルならびにサービス・スケジューラを開始するアウトソーシング組織に対して提出することができる。このようにして、サービス・プロバイダ組織にＴＡＧＳＳアプリケーションがインストールされていない場合であってもアウトソーシング組織がリソースを獲得する。このアプローチを用いれば、まったく新しいＴＡＧＳＳプロセスのセットが単一のクライアント用に作成される。
ＴＡＧＳＳスケジューラは、前述したようにグローバス（Ｇｌｏｂｕｓ）２．０ツールキットを使用してグリッド環境内において展開することが可能である。グローバス（Ｇｌｏｂｕｓ）２．０ツールキットは、この開示の最初に述べたジョブ・ベースのアーキテクチャによって強く影響を受け、基本的にジョブ提出モデルのサポートしか行わない。しかしながら、前に述べたように、ジョブ提出モデルは、ＴＡＧＳＳソフトウエア・プロセスをジョブとして開始することができる。これらの『ジョブ』だけが『非常に長命』であり、一方それらは、いくつかのクライアントに代わってサービス要求のレベルにおいてタスクをスケジュールする。
言い換えると、本発明はクライアント要求を処理するためのコンピュータ・システムを提供する。このシステムは、グリッド・コンテナ配列に接続されるグリッド・サービス・スケジューラを含む。各グリッド・コンテナ配列は、それぞれが異なるコンピュータ・ホスト内に常駐する持続的なコンテナ（たとえば、サービス・コンテナ）、およびマイクロ・スケジューラを含んでいる。各コンテナは、多くのオブジェクトを含む。単一のグリッド・コンテナ配列を構成するコンテナ内のオブジェクトは、グリッド・オブジェクト配列を構成する。グリッド・サービス・スケジューラは、トランスペアレントに、クライアント要求を複数のタスクに分割し、タスクのグループを各マイクロ・スケジューラに割り当てる。マイクロ・スケジューラのそれぞれは、グリッド・サービス・スケジューラから受け取ったタスクのグループからの個別のタスクを、それらに対応するグリッド・オブジェクト配列内のオブジェクトに割り当てる。
このシステムは、追加のレベルのスケジューラ階層構造およびゲートウェイを含むことが可能であり、それぞれは異なるグリッド・サービス・スケジューラに接続される。ポータルがゲートウェイに接続され、このポータルが、ゲートウェイに沿ってクライアント要求をグリッド・サービス・スケジューラに渡す。
各コンテナ配列は、ローカル・エリア・ネットワーク内に常駐し、その結果、グリッド・コンテナ配列内のオブジェクト間の通信が、ローカル通信を構成する。グリッド・サービス・スケジューラは、クライアント要求をトランスペアレントな方法に従って分割し、その結果、クライアントがそのクライアント要求の分割に気付くことはない。これらのコンテナは、持続的なサービス・コンテナであり、それらが使用されて、複数のクライアント要求に及ぶ時間期間にわたって複数のクライアントの複数のクライアント要求が処理される。
また本発明は、ホストのコンピュータ・ネットワークにわたってクライアント要求を処理する方法を提供し、それには、ホスト内に持続的なコンテナを作成すること、コンテナ内にオブジェクトを作成すること、コンテナをグリッド・コンテナ配列にグループ化すること、単一グリッド・コンテナ配列内となるコンテナ内におけるオブジェクトを、グリッド・オブジェクト配列にグループ化すること、各グリッド・コンテナ配列用に１つのマイクロ・スケジューラを作成すること、クライアント要求のそれぞれを複数のタスクに分割すること、およびタスクのグループをマイクロ・スケジューラに割り当てることが含まれ、それにおいてマイクロ・スケジューラは、個別のタスクをオブジェクトに割り当てる。本発明は、マイクロ・スケジューラに、そのマイクロ・スケジューラが完了したタスクのグループを返すときに追加のタスクのグループを割り当てる。またこの方法に、ゲートウェイを介してクライアント要求を複数のグリッド・サービス・スケジューラに渡すことが含められるようにもできる。
このように上述の本発明は、グリッド・サービス・スケジューラを使用してクライアント要求を多くのタスクに分割する。このシステムは、前記タスクを、グリッド・オブジェクト配列内の複数のオブジェクトを介して実行するが、それらのオブジェクトは、１つのグリッド・コンテナ配列を構成するコンテナ内にあり、グリッド・コンテナ配列は、マイクロ・スケジューラによってコントロールされる。
本発明は、グリッドに関する要求レベル・スケジューリングの新しいアーキテクチャであるトポロジ・アウェア・グリッド・サービス・スケジューラ（Ｔｏｐｏｌｏｇｙ Ａｗａｒｅ Ｇｒｉｄ Ｓｅｒｖｉｃｅｓ Ｓｃｈｅｄｕｌｅｒ）（ＴＡＧＳＳ）を提供する。このアーキテクチャは、タスク・スケジューリング・インフラストラクチャが、多様なケイパビリティのコンピューティング・ホストならびにネットワークからなる多様なコンピューティング環境において動作するべく設計されることからトポロジ・アウェアである。この種の多様なコンピューティング環境は、グリッド・コンピューティングにおいては一般的であり、クラスタ・コンピューティングに通常に見られる一様な環境とは対照的である。つまり、クラスタ・コンピューティングにおいて使用されるスケジューリング・テクニックは、グリッド・コンピューティングに適していない。ＴＡＧＳＳのもう１つの重要な特徴は、それがサービス指向アーキテクチャを基礎としていることである。これは、クラスタ・スケジューリングがジョブ指向アーキテクチャを基礎としていることから、伝統的なクラスタ・スケジューリングと鋭く対立する。最近のオープン・グリッド・サービス・アーキテクチャ（Ｏｐｅｎ Ｇｒｉｄ Ｓｅｒｖｉｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ）（ＯＧＳＡ）の紹介は、グリッド・コンピューティングの世界にサービス・ベースのアーキテクチャをもたらし、またそれとともにグリッド内におけるサービス要求のスケジューリングのタスクに関連する新しい課題をもたらしている。この開示は、これらの課題を論じており、それらをＴＡＧＳＳアーキテクチャにおける特徴に関連付けしている。
以上、本発明を好ましい実施態様に関して説明してきたが、当業者であれば付随する特許請求の範囲内ならびにその精神の中における修正を伴って本発明の実施が可能であることを認識されよう。
２つの異なる組織によって共有されるアーキテクチャを示した概略図である。 オンデマンドでコンテナを作成することができる本発明の機能を例示した概略図である。 各種のコンテナ内においてグリッド・オブジェクトが作成されることを例示した概略図である。 各種のオブジェクト間におけるインタラクションを示した概略図である。 本発明がどのようにしてグリッド・オブジェクト配列内のオブジェクトにタスクを転送するかについて例示した概略図である。 複合グリッド・コンテナ内の複数のクライアント・スケジューラを例示した概略図である。 複合グリッド・コンテナ内の複数のクライアント・スケジューラを例示した概略図である。 グリッド・ポータルを使用する階層スケジューリングを例示した概略図である。 グリッド・ポータルを使用する階層スケジューリングを例示した概略図である。 グリッド内における本発明の展開を例示した概略図である。 グリッド内における本発明の展開を例示した概略図である。
符号の説明
１２０ 組織
１２１ 組織
１２５ クラスタ
１２８ オブジェクト
１３０ グリッド・ゲートウェイ
１３２ クラスタ・スケジューラ
２００ ＴＡＧＳＳスケジューラ、サービス・スケジューラ、スケジューラ、スケジューラ・サービス
２０１ サービス・スケジューラ、スケジューラ
２０５ ＴＡＧＳＳエージェント
２１０ グリッド・ホスト、ノードのプール、ホスト
２１１ ホスト、異なるホスト
２１５ クライアント・プロセス
２１６ クライアント・プロセス
２２０ コンテナ、コンテナ・サービス
３００ コンテナ、コンテナ・サービス
３０１ コンテナ、コンテナ・サービス
３０２ コンテナ
３０３ コンテナ
３０４ コンテナ
３０５ コンテナ
３０６ オブジェクト配列、グリッド・オブジェクト配列
３０７ グリッド・コンテナ配列、コンテナ配列
３０８ グリッド・コンテナ配列
３０９ グリッド・コンテナ配列
４００ オブジェクト
４０１ オブジェクト
４０２ オブジェクト
４０３ オブジェクト
５００ ＴＡＧＳＳクライアント・スケジューラ、ＴＡＧＳＳマイクロ・スケジューラ、マイクロ・スケジューラ
５０１ ＴＡＧＳＳマイクロ・スケジューラ、ＴＡＧＳＳクライアント・スケジューラ
６００ ゲートウェイ、ゲートウェイ１
６０１ ゲートウェイ、ゲートウェイ２、第２のゲートウェイ
６０２ ゲートウェイ３
６０７ 複合グリッド・オブジェクト配列
６０８ 複合グリッド・コンテナ配列
７００ グリッド・ポータル
７０１ グリッド・ポータル
７０２ グリッド・ポータル
８００ アウトソーシング組織

Claims (24)

  1. クライアント要求を処理するためのコンピュータ・システムであって、
    複数のグリッド・コンテナ配列に接続されるグリッド・サービス・スケジューラを有 し、それにおいて各グリッド・コンテナ配列は、
    それぞれのコンテナがコンピュータ・ホスト内に常駐する複数の持続的なコンテナ
    および、
    前記コンテナの１つ内における１つのマイクロ・スケジューラ
    を有し、それにおいて
    前記コンテナのそれぞれは、複数のオブジェクトを含むものとし、
    グリッド・コンテナ配列を構成するコンテナ内のオブジェクトは、グリッド・オブジ ェクト配列を構成するものとし、
    前記グリッド・サービス・スケジューラは、クライアント要求を複数のタスクに分割 し、かつ前記タスクのグループを各マイクロ・スケジューラに割り当てるものとし、 かつ、前記マイクロ・スケジューラのそれぞれは、前記グリッド・サービス・スケジ ューラから受け取ったタスクのグループからの個別のタスクを、対応するグリッド・ オブジェクト配列内のオブジェクトに割り当てるものとする、システム。
  2. さらに、複数のグリッド・サービス・スケジューラおよびゲートウェイを有し、それにおいて各ゲートウェイは、異なるグリッド・サービス・スケジューラに接続されるものとする、請求項１記載のシステム。
  3. さらに前記ゲートウェイに接続されるポータルを有し、それにおいて前記ポータルは、前記クライアント要求を前記ゲートウェイに沿って前記グリッド・サービス・スケジューラに渡すものとする、請求項２記載のシステム。
  4. 各コンテナ配列がローカル・エリア・ネットワーク内に常駐し、その結果、グリッド・コンテナ配列内のオブジェクト間の通信が、ローカル通信を構成するものとする、請求項１記載のシステム。
  5. 前記グリッド・サービス・スケジューラが、前記クライアント要求をトランスペアレントな方法に従って分割し、その結果、クライアントが前記クライアント要求の分割に気付くことがないものとする、請求項１記載のシステム。
  6. 前記コンテナがサービス・コンテナを構成し、それらが使用されて、複数のクライアント要求に及ぶ時間期間にわたって複数のクライアントからの複数のクライアント要求が処理されるものとする、請求項１記載のシステム。
  7. クライアント要求を処理するためのコンピュータ・システムであって、
    複数のグリッド・コンテナ配列に接続されるグリッド・サービス・スケジューラを有 し、それにおいて各グリッド・コンテナ配列は、
    それぞれのコンテナがコンピュータ・ホスト内に常駐する複数の持続的なコンテナ
    および、
    １つのマイクロ・スケジューラを有し、各グリッド・コンテナ配列内において、前記 マイクロ・スケジューラは、前記グリッド・コンテナ配列内のすべてのコンテナのうち のもっとも高いパフォーマンスを有するコンテナ内に位相的に配置されているものとし、それにおいて、
    前記コンテナのそれぞれは、複数のオブジェクトを含むものとし、
    グリッド・コンテナ配列を構成するコンテナ内のオブジェクトは、グリッド・オブジェクト配列を構成するものとし、
    前記グリッド・サービス・スケジューラは、クライアント要求を複数のタスクに分割し、かつ前記タスクのグループを各マイクロ・スケジューラに割り当てるものとし、かつ、前記マイクロ・スケジューラのそれぞれは、前記グリッド・サービス・スケジューラから受け取ったタスクのグループからの個別のタスクを、対応するグリッド・オブジェクト配列内のオブジェクトに割り当てるものとする、システム。
  8. さらに、それぞれが異なるグリッド・サービス・スケジューラに接続されるゲートウェイを有する、請求項７記載のシステム。
  9. さらに前記ゲートウェイに接続されるポータルを有し、それにおいて前記ポータルは、前記クライアント要求を前記ゲートウェイに沿って前記グリッド・サービス・スケジューラに渡すものとする、請求項８記載のシステム。
  10. 各コンテナ配列がローカル・エリア・ネットワーク内に常駐し、その結果、グリッド・コンテナ配列内のオブジェクト間の通信が、ローカル通信を構成するものとする、請求項７記載のシステム。
  11. 前記グリッド・サービス・スケジューラが、前記クライアント要求をトランスペアレントな方法に従って分割し、その結果、クライアントが前記クライアント要求の分割に気付くことがないものとする、請求項７記載のシステム。
  12. 前記コンテナが持続的なサービス・コンテナを構成し、それらが使用されて、複数のクライアント要求に及ぶ時間期間にわたって複数のクライアントの複数のクライアント要求が処理されるものとする、請求項７記載のシステム。
  13. ホストのコンピュータ・ネットワークにわたってクライアント要求を処理する方法であって、
    前記ホスト内に持続的なコンテナを作成し、
    前記コンテナ内にオブジェクトを作成し、
    前記コンテナをグリッド・コンテナ配列にグループ化し、
    単一グリッド・コンテナ配列内となるコンテナ内におけるオブジェクトを、グリッド・オブジェクト配列にグループ化し、
    各グリッド・コンテナ配列用に１つのマイクロ・スケジューラを作成し、
    前記要求のそれぞれを複数のタスクに分割し、
    かつ、
    前記タスクのグループを前記マイクロ・スケジューラに割り当て、それにおいては前記マイクロ・スケジューラが、個別のタスクを前記オブジェクトに割り当てるものとする方法。
  14. さらに、前記マイクロ・スケジューラに、前記マイクロ・スケジューラが完了したタスクのグループを返すときに追加のタスクのグループを割り当てることを含む、請求項１３記載の方法。
  15. さらに、ゲートウェイを介して前記クライアント要求を複数のグリッド・サービス・スケジューラに渡すことを含む、請求項１３記載の方法。
  16. 各コンテナ配列がローカル・エリア・ネットワーク内に常駐し、その結果、グリッド・コンテナ配列内のオブジェクト間の通信が、ローカル通信を構成するものとする、請求項１３記載の方法。
  17. 前記分割がトランスペアレントな方法に従って実行され、その結果、クライアントが前記クライアント要求の分割に気付くことがないものとする、請求項１３記載の方法。
  18. 前記コンテナがサービス・コンテナを構成し、それらが使用されて、複数のクライアント要求に及ぶ時間期間にわたって複数のクライアントの複数のクライアント要求が処理されるものとする、請求項１３記載の方法。
  19. ホストのコンピュータ・ネットワークにわたってクライアント要求を処理する方法であって、
    前記ホスト内に持続的なコンテナを作成し、
    前記コンテナ内にオブジェクトを作成し、
    前記コンテナをグリッド・コンテナ配列にグループ化し、
    単一グリッド・コンテナ配列内となるコンテナ内におけるオブジェクトを、グリッド・オブジェクト配列にグループ化し、
    各グリッド・コンテナ配列用に１つのマイクロ・スケジューラを作成し、
    前記マイクロ・スケジューラは、前記グリッド・コンテナ配列内のすべてのコンテナのうちのもっとも高いパフォーマンスを有するコンテナ内に位相的に配置されているものとし、
    前記要求のそれぞれを複数のタスクに分割し、
    かつ、
    前記タスクのグループを前記マイクロ・スケジューラに割り当て、それにおいては前記マイクロ・スケジューラが、個別のタスクを前記オブジェクトに割り当てるものとする方法。
  20. さらに、前記マイクロ・スケジューラに、前記マイクロ・スケジューラが完了したタスクのグループを返すときに追加のタスクのグループを割り当てることを含む、請求項１９記載の方法。
  21. さらに、ゲートウェイを介して前記クライアント要求を複数のグリッド・サービス・スケジューラに渡すことを含む、請求項１９記載の方法。
  22. 各コンテナ配列がローカル・エリア・ネットワーク内に常駐し、その結果、グリッド・コンテナ配列内のオブジェクト間の通信が、ローカル通信を構成するものとする、請求項１９記載の方法。
  23. 前記分割がトランスペアレントな方法に従って実行され、その結果、クライアントが前記クライアント要求の分割に気付くことがないものとする、請求項１９記載の方法。
  24. 前記コンテナが持続的なサービス・コンテナを構成し、それらが使用されて、複数のクライアント要求に及ぶ時間期間にわたって複数のクライアントの複数のクライアント要求が処理されるものとする、請求項１９記載の方法。
JP2003421634A 2002-12-23 2003-12-18 トポロジ・アウェア・グリッド・サービス・スケジューラ・アーキテクチャ Pending JP2004206712A (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US10/328,255 US7383550B2 (en) 2002-12-23 2002-12-23 Topology aware grid services scheduler architecture

Publications (1)

Publication Number Publication Date
JP2004206712A true JP2004206712A (ja) 2004-07-22

Family

ID=32594410

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2003421634A Pending JP2004206712A (ja) 2002-12-23 2003-12-18 トポロジ・アウェア・グリッド・サービス・スケジューラ・アーキテクチャ

Country Status (3)

Country Link
US (2) US7383550B2 (ja)
JP (1) JP2004206712A (ja)
CN (1) CN100576841C (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008527521A (ja) * 2005-01-12 2008-07-24 インターナショナル・ビジネス・マシーンズ・コーポレーション グリッド・ジョブに関するグリッド・プロバイダの選択を自動的に制御するための方法、システム、およびコンピュータ・プログラム
JP2010525484A (ja) * 2007-04-26 2010-07-22 インターナショナル・ビジネス・マシーンズ・コーポレーション 分散型、耐障害性、および高可用性を達成するための決定性コンピューティング・システム、方法、およびプログラム・ストレージ・デバイス（分散型、耐障害性、および高可用性のコンピューティング・システム）
US8584127B2 (en) 2008-03-10 2013-11-12 Fujitsu Limited Storage medium storing job management program, information processing apparatus, and job management method
JP2017076427A (ja) * 2012-11-02 2017-04-20 アマゾン・テクノロジーズ・インコーポレーテッド リソーススタック内のカスタムリソース

Families Citing this family (68)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7171470B2 (en) * 2003-02-20 2007-01-30 International Business Machines Corporation Grid service scheduling of related services using heuristics
US7461166B2 (en) * 2003-02-21 2008-12-02 International Business Machines Corporation Autonomic service routing using observed resource requirement for self-optimization
US20050050184A1 (en) * 2003-08-29 2005-03-03 International Business Machines Corporation Method, system, and storage medium for providing life-cycle management of grid services
US7404189B2 (en) * 2003-12-30 2008-07-22 International Business Machines Corporation Scheduler supporting web service invocation
US7406691B2 (en) 2004-01-13 2008-07-29 International Business Machines Corporation Minimizing complex decisions to allocate additional resources to a job submitted to a grid environment
US7562143B2 (en) 2004-01-13 2009-07-14 International Business Machines Corporation Managing escalating resource needs within a grid environment
US7552437B2 (en) 2004-01-14 2009-06-23 International Business Machines Corporation Maintaining application operations within a suboptimal grid environment
CA2831359A1 (en) 2004-03-13 2005-09-29 Adaptive Computing Enterprises, Inc. System and method of co-allocating a reservation spanning different compute resources types
US7890629B2 (en) * 2004-03-13 2011-02-15 Adaptive Computing Enterprises, Inc. System and method of providing reservation masks within a compute environment
US8782654B2 (en) 2004-03-13 2014-07-15 Adaptive Computing Enterprises, Inc. Co-allocating a reservation spanning different compute resources types
WO2005089246A2 (en) 2004-03-13 2005-09-29 Cluster Resources, Inc. System and method for providiing advanced reservations in a compute environment
US9558042B2 (en) 2004-03-13 2017-01-31 Iii Holdings 12, Llc System and method providing object messages in a compute environment
US7237062B2 (en) * 2004-04-02 2007-06-26 Seagate Technology Llc Storage media data structure system and method
US7596788B1 (en) * 2004-05-11 2009-09-29 Platform Computing Corporation Support of non-trivial scheduling policies along with topological properties
US7266547B2 (en) * 2004-06-10 2007-09-04 International Business Machines Corporation Query meaning determination through a grid service
US7861246B2 (en) * 2004-06-17 2010-12-28 Platform Computing Corporation Job-centric scheduling in a grid environment
US20070266388A1 (en) 2004-06-18 2007-11-15 Cluster Resources, Inc. System and method for providing advanced reservations in a compute environment
EP1622009A1 (en) * 2004-07-27 2006-02-01 Texas Instruments Incorporated JSM architecture and systems
US8176490B1 (en) 2004-08-20 2012-05-08 Adaptive Computing Enterprises, Inc. System and method of interfacing a workload manager and scheduler with an identity manager
US8171474B2 (en) * 2004-10-01 2012-05-01 Serguei Mankovski System and method for managing, scheduling, controlling and monitoring execution of jobs by a job scheduler utilizing a publish/subscription interface
US8271980B2 (en) 2004-11-08 2012-09-18 Adaptive Computing Enterprises, Inc. System and method of providing system jobs within a compute environment
JP2006155187A (ja) * 2004-11-29 2006-06-15 Sony Corp 情報処理システム、情報処理装置および方法、記録媒体、並びにプログラム。
US7568006B2 (en) * 2004-11-30 2009-07-28 International Business Machines Corporation e-Business on-demand for design automation tools
US7627655B2 (en) * 2004-12-13 2009-12-01 Sap Ag Increased performance of grid applications
US7590623B2 (en) 2005-01-06 2009-09-15 International Business Machines Corporation Automated management of software images for efficient resource node building within a grid environment
US7571120B2 (en) 2005-01-12 2009-08-04 International Business Machines Corporation Computer implemented method for estimating future grid job costs by classifying grid jobs and storing results of processing grid job microcosms
US7562035B2 (en) 2005-01-12 2009-07-14 International Business Machines Corporation Automating responses by grid providers to bid requests indicating criteria for a grid job
US8863143B2 (en) 2006-03-16 2014-10-14 Adaptive Computing Enterprises, Inc. System and method for managing a hybrid compute environment
US8631130B2 (en) 2005-03-16 2014-01-14 Adaptive Computing Enterprises, Inc. Reserving resources in an on-demand compute environment from a local compute environment
US7996455B2 (en) 2005-06-17 2011-08-09 Adaptive Computing Enterprises, Inc. System and method for providing dynamic roll-back reservations in time
US9231886B2 (en) 2005-03-16 2016-01-05 Adaptive Computing Enterprises, Inc. Simple integration of an on-demand compute environment
US7774457B1 (en) * 2005-03-25 2010-08-10 Hewlett-Packard Development Company, L.P. Resource evaluation for a batch job and an interactive session concurrently executed in a grid computing environment
US8468530B2 (en) * 2005-04-07 2013-06-18 International Business Machines Corporation Determining and describing available resources and capabilities to match jobs to endpoints
CA2603577A1 (en) 2005-04-07 2006-10-12 Cluster Resources, Inc. On-demand access to compute resources
US20070006070A1 (en) * 2005-06-30 2007-01-04 International Business Machines Corporation Joining units of work based on complexity metrics
US7707579B2 (en) * 2005-07-14 2010-04-27 International Business Machines Corporation Method and system for application profiling for purposes of defining resource requirements
CN100345111C (zh) * 2005-08-26 2007-10-24 南京邮电大学 一种用于网格计算的模型驱动方法
US7995474B2 (en) * 2005-09-13 2011-08-09 International Business Machines Corporation Grid network throttle and load collector
US8713179B2 (en) * 2005-10-04 2014-04-29 International Business Machines Corporation Grid computing accounting and statistics management system
US7853948B2 (en) * 2005-10-24 2010-12-14 International Business Machines Corporation Method and apparatus for scheduling grid jobs
US20070118839A1 (en) * 2005-10-24 2007-05-24 Viktors Berstis Method and apparatus for grid project modeling language
US7831971B2 (en) * 2005-10-24 2010-11-09 International Business Machines Corporation Method and apparatus for presenting a visualization of processor capacity and network availability based on a grid computing system simulation
US20070180451A1 (en) * 2005-12-30 2007-08-02 Ryan Michael J System and method for meta-scheduling
CN100377091C (zh) * 2006-03-16 2008-03-26 浙江大学 嵌入式操作系统分组硬实时任务调度的实现方法
US20070255833A1 (en) * 2006-04-27 2007-11-01 Infosys Technologies, Ltd. System and methods for managing resources in grid computing
US20080049254A1 (en) * 2006-08-24 2008-02-28 Thomas Phan Method and means for co-scheduling job assignments and data replication in wide-area distributed systems
US8255915B1 (en) * 2006-10-31 2012-08-28 Hewlett-Packard Development Company, L.P. Workload management for computer system with container hierarchy and workload-group policies
US8041773B2 (en) 2007-09-24 2011-10-18 The Research Foundation Of State University Of New York Automatic clustering for self-organizing grids
US8037122B2 (en) * 2008-09-19 2011-10-11 Oracle International Corporation Processing of service-oriented tasks within a grid computing environment
CN101420354B (zh) * 2008-11-26 2011-08-10 北京航空航天大学 面向广域网远程虚拟环境的组播扩展方法
US8266477B2 (en) 2009-01-09 2012-09-11 Ca, Inc. System and method for modifying execution of scripts for a job scheduler using deontic logic
US10877695B2 (en) 2009-10-30 2020-12-29 Iii Holdings 2, Llc Memcached server functionality in a cluster of data processing nodes
US11720290B2 (en) 2009-10-30 2023-08-08 Iii Holdings 2, Llc Memcached server functionality in a cluster of data processing nodes
CN101958808B (zh) * 2010-10-18 2012-05-23 华东交通大学 一种服务于多网格接入的集群任务调度管理器
US9307013B1 (en) * 2013-05-30 2016-04-05 Google Inc. Reducing batch completion time in a computer network with max-min fairness
WO2015101827A1 (en) * 2013-12-31 2015-07-09 Mosys, Inc. Integrated main memory and coprocessor with low latency
US9256467B1 (en) 2014-11-11 2016-02-09 Amazon Technologies, Inc. System for managing and scheduling containers
US10789080B2 (en) * 2015-07-17 2020-09-29 Microsoft Technology Licensing, Llc Multi-tier customizable portal deployment system
US9804895B2 (en) * 2015-08-28 2017-10-31 Vmware, Inc. Constrained placement in hierarchical randomized schedulers
US10133590B2 (en) 2015-09-29 2018-11-20 International Business Machines Corporation Container runtime support
US10261782B2 (en) 2015-12-18 2019-04-16 Amazon Technologies, Inc. Software container registry service
US10069869B2 (en) 2016-05-17 2018-09-04 Amazon Technologies, Inc. Versatile autoscaling
US10860373B2 (en) 2016-10-11 2020-12-08 Microsoft Technology Licensing, Llc Enhanced governance for asynchronous compute jobs
US10409642B1 (en) 2016-11-22 2019-09-10 Amazon Technologies, Inc. Customer resource monitoring for versatile scaling service scaling policy recommendations
US11669365B1 (en) 2019-08-26 2023-06-06 Amazon Technologies, Inc. Task pool for managed compute instances
CN111078356A (zh) * 2019-11-22 2020-04-28 北京达佳互联信息技术有限公司 Gpu集群资源控制系统、方法、装置、设备及存储介质
CN111049915B (zh) * 2019-12-17 2023-04-07 书行科技(北京)有限公司 一种容器云下消息队列代理系统及方法
CN111371678B (zh) * 2020-02-26 2021-12-31 北京天维信通科技有限公司 第三方服务运行方法和装置、网关设备及存储介质

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2743865B2 (ja) 1995-04-28 1998-04-22 日本電気株式会社 ジョブスケジューリング方式
US6345287B1 (en) * 1997-11-26 2002-02-05 International Business Machines Corporation Gang scheduling for resource allocation in a cluster computing environment
US6112225A (en) * 1998-03-30 2000-08-29 International Business Machines Corporation Task distribution processing system and the method for subscribing computers to perform computing tasks during idle time
US6571274B1 (en) * 1998-11-05 2003-05-27 Beas Systems, Inc. Clustered enterprise Java™ in a secure distributed processing system
US6701382B1 (en) * 1998-12-23 2004-03-02 Nortel Networks Limited Name service for transparent container objects
EP1107108A1 (en) 1999-12-09 2001-06-13 Hewlett-Packard Company, A Delaware Corporation System and method for managing the configuration of hierarchically networked data processing devices
US7143437B2 (en) 2001-01-12 2006-11-28 Siemens Medical Solutions Health Services Corporation System and user interface for managing user access to network compatible applications
US20030028275A1 (en) 2001-05-01 2003-02-06 Xerox Corporation Incremental distributed actuation for large assemblies of implementation units
US7650607B2 (en) * 2001-06-22 2010-01-19 Invensys Systems, Inc. Supervisory process control and manufacturing information system application having a layered architecture
US7093004B2 (en) * 2002-02-04 2006-08-15 Datasynapse, Inc. Using execution statistics to select tasks for redundant assignment in a distributed computing platform

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008527521A (ja) * 2005-01-12 2008-07-24 インターナショナル・ビジネス・マシーンズ・コーポレーション グリッド・ジョブに関するグリッド・プロバイダの選択を自動的に制御するための方法、システム、およびコンピュータ・プログラム
JP2010525484A (ja) * 2007-04-26 2010-07-22 インターナショナル・ビジネス・マシーンズ・コーポレーション 分散型、耐障害性、および高可用性を達成するための決定性コンピューティング・システム、方法、およびプログラム・ストレージ・デバイス（分散型、耐障害性、および高可用性のコンピューティング・システム）
US8584127B2 (en) 2008-03-10 2013-11-12 Fujitsu Limited Storage medium storing job management program, information processing apparatus, and job management method
JP2017076427A (ja) * 2012-11-02 2017-04-20 アマゾン・テクノロジーズ・インコーポレーテッド リソーススタック内のカスタムリソース

Also Published As

Publication number Publication date
US7383550B2 (en) 2008-06-03
US20080168451A1 (en) 2008-07-10
US8087023B2 (en) 2011-12-27
CN1516419A (zh) 2004-07-28
CN100576841C (zh) 2009-12-30
US20040123296A1 (en) 2004-06-24

Similar Documents

Publication Publication Date Title
JP2004206712A (ja) トポロジ・アウェア・グリッド・サービス・スケジューラ・アーキテクチャ
CA2502682C (en) Remote system administration using command line environment
Neuman et al. The Prospero resource manager: A scalable framework for processor allocation in distributed systems
Foster et al. Describing the Elephant: The Different Faces of IT as Service: Terms such as grid, on-demand, and service-oriented architecture are mired in confusion, but there is an overarching trend behind them all.
WO2003010659A1 (en) Computer processing and programming method using autonomous data handlers
US20020095525A1 (en) Computer processing and programming method using autonomous data handlers
Huang JISGA: A Jini-based service-oriented Grid architecture
Mann et al. DISCOVER: An environment for Web‐based interaction and steering of high‐performance scientific applications
Mohamed et al. MidCloud: an agent‐based middleware for effective utilization of replicated Cloud services
Morrison et al. Webcom-G: grid enabled metacomputing
Kaiser et al. A mobile agent approach to lightweight process workflow
Schnekenburger Load balancing in CORBA: A survey of concepts, patterns, and techniques
Neuman et al. Resource management for distributed parallel systems
Fabra et al. A framework for the flexible deployment of scientific workflows in grid environments
Ananthakrishnan et al. Establishing a high-performance and productive ecosystem for distributed execution of python functions using globus compute
US8561077B1 (en) Binder for a multi-threaded process to access an un-shareable resource
Tanaka et al. Resource manager for globus-based wide-area cluster computing
Kravtsov et al. Service-based Resource Brokering for Grid-Based Data Mining.
US20230419160A1 (en) 3-tier quantum computing execution model
Bilas Running Kubernetes Workloads on HPC
Liu et al. A software framework to support adaptive applications in distributed/parallel computing
Roy et al. A multi-agent framework for resource brokering of multiple concurrent jobs in grid environment
Teo et al. On grid programming and MATLAB* G
Chen et al. Multi-agent system-based hierarchy grid middleware
Vargas et al. Grand: Toward scalability in a grid environment

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20060131

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20060214

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20060512

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20060517

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20060814

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20061017