(57)【要約】      （修正有）【課題】グリッドおよびバッチ・コンピューティング・システムにおけるジョブの改善された監視およびコントロールのための解決法を提供すること。【解決手段】ワークロード・バランシングならびにジョブの開始および完了のみを担う集中サーバのバッチ・マネージャを提供し、すべての他のコマンドおよびステータス情報は、複数のサブミッタのシステムと、それらの各ワークロードを処理する複数のクライアント・システムの間で直接通信される。コンピューティング・システムおよび通信プロセスは、イベントドリブンのピア・ツー・ピア通信をサブミッタのシステムとクライアント・システムの間で利用し、より詳細なステータスおよびコントロール情報を、集中サーバをオーバーロードさせることなく渡すことができるようにし、ポーリングを回避することによって、結果のより即時のフィードバックも提供する。【選択図】図３
2005004740.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータ・システムであって、
集中サーバ（１）、ならびに、リクエストを受信およびディスパッチするためのバッチまたはグリッド・コンピューティング・システムの全体のコントロールを提供するために、アプリケーション・プロセスと組み合わせて利用されるサブミッタ・アプリケーションを含み、
前記アプリケーション・プロセスは、ディスパッチされたリクエストを処理するクライアントが通信を、前記通信が前記集中サーバを通過することなく、元のリクエストを提出するそのクライアントに戻すように直接渡すことが同時にできるようにする、
コンピュータ・システム。
【請求項２】
コンピュータ・システム・アプリケーションであって、
通信のためのプロセスを含み、
前記プロセスは、リクエストを集中サーバ（１）へ、未知のセットの処理クライアント（５〜９）において処理するために提出するクライアント（２）が、命令を、前記集中サーバを通じて前記処理クライアントに分散されたリクエストに埋め込み、前記処理クライアントに、どのようにかつどこで前記提出クライアントに接続するかについて命令することができるようにする、
コンピュータ・システム・アプリケーション。
【請求項３】
提出クライアント（２）におけるユーザ・インターフェース方法であって、
提出クライアント・サブミッタにユーザ・インターフェースを提示し、ならびに、同時に複数の処理クライアント（５〜９）からの入力の要約を受信し、かつユーザ・インターフェース上に表示するステップを含み、
その間に、コマンドを前記処理クライアントの１つまたは複数に同時に送信するステップを可能にする、
ユーザ・インターフェース方法。
【請求項４】
選択された個別の処理クライアント（５）におけるジョブ・ステップ（３５）との通信の追加の詳細を表示する、追加の情報ウィンドウの表示を可能にするステップをさらに含む、請求項３に記載のユーザ・インターフェース方法。
【請求項５】
前記ユーザ・インターフェースによる、処理クライアント（５〜９）から受信された通信の解釈を可能にし、結果を要約して前記サブミッタに、選択された重要な結果を、前記処理クライアントから通信されるとすぐ即時に提示するステップ、または、他の処理クライアントから受信された通信の結果として、いくつかの処理クライアントに、それらの継続されたオペレーションを変更するためのコマンドを自動的に送信するステップをさらに含む、請求項３に記載のユーザ・インターフェース方法。
【請求項６】
提出クライアントにおけるユーザ・インターフェース方法であって、
提出クライアント・サブミッタにユーザ・インターフェースを提示し、ならびに、同時に複数の処理クライアント（５〜９）からの入力の要約を受信し、かつユーザ・インターフェース上に表示するステップを含み、
その間に、コマンドを前記処理クライアントの１つまたは複数に同時に送信するステップを可能にし、さらに、提出クライアント・サブミッタ上に存在することができるユーザ・インターフェース・プロセス（２９）の１つまたは複数の異なるインスタンスが、すでに使用中の好ましい通信ポートおよびそれにより別のインスタンスの存在を検出できるようにし、前記検出から別の使用可能な通信ポートを選択できるようにし、また、例えばメイン・ウィンドウおよびすべてのサブウィンドウの色など、前記追加のインスタンスの可視の特徴を変更できるようにして、前記サブミッタが、開示された監視システムおよび関連付けられたジョブ・ステップ（３５、３８）のあるインスタンスに属するウィンドウを、他のインスタンスに属するウィンドウから区別するようにするステップを含む、
ユーザ・インターフェース方法。
【請求項７】
提出クライアントにおいて、そのＩＤがあらかじめ知られていない処理クライアント（５〜９）から新しい接続を受信するために、接続プロセス（３０）をさらに含む、請求項１に記載のコンピュータ・システム。
【請求項８】
コンピュータ・システムであって、
集中サーバ（１）、ならびに、リクエストを受信およびディスパッチするためのバッチまたはグリッド・コンピューティング・システムの全体のコントロールを提供するために、アプリケーション・プロセスと組み合わせて利用されるサブミッタ・アプリケーションを含み、前記アプリケーション・プロセスは、ディスパッチされたリクエストを処理するクライアントが同時にコンピューティング・システムと通信を渡すことができるようにし、また、初期ジョブ開始メッセージについては集中サーバを通過し、かつ他の接続についてはクライアントの間で直接渡して、前記クライアントが互いを肯定的に識別して前記コンピューティング・システム内の他のクライアントからの通信を排除可能にすることができる、鍵のシステムを含む、
コンピュータ・システム。
【請求項９】
コンピュータ・システム通信方法であって、
提出クライアントにおいてジョブ・ステップ毎に、関連付けられた処理クライアント（５）からの入力を受信し、前記関連付けられた処理クライアントからの前記入力に、前記処理クライアントによって実行された１つのジョブ・ステップ（３５）に特有の識別情報によりタグ付けし、前記入力をタグ付け後にユーザ・インターフェース・プロセス（２９）へ、前記特定の処理クライアントおよび前記タグ付けされた入力の１つのジョブ・ステップ（３５）に関連付けられた入力としての表示のために戻すステップを含む、
コンピュータ・システム通信方法。
【請求項１０】
コンピュータ・システム通信方法であって、処理クライアント（５）において確立されたコマンド・プロセス（３３）によって実行される、
ユーザ・インターフェース・プロセス（２９）からのコマンドを提出クライアントにおいて受信するステップと、
前記ユーザ・インターフェース・プロセスから前記提出クライアントにおいて受信された前記コマンドを、パイプラインを介して前記処理クライアントにおけるバッチ・ジョブ・ステップ（３５）に転送するステップと
を含む、コンピュータ・システム通信方法。
【請求項１１】
コンピュータ・システム通信方法であって、処理クライアント（５）において確立されたレスポンス・プロセス（３４）によって実行される、
バッチ・ジョブ・ステップ（３５）からの結果を前記処理クライアントにおいて受信するステップと、
前記受信された結果を、通信リンクを介して提出クライアントに表示および解析のために即時に転送するステップと
を含む、コンピュータ・システム通信方法。
【請求項１２】
情報ハンドリング・システムであって、
複数の処理クライアント（５〜９）に結合され、双方向パイプ（４０、４１）を提供するコンピューティング・システムと、
同時に処理クライアント（５）におけるバッチ・ジョブ・ステップ（３５）からの出力を受信し、入力を前記処理クライアントにおける前記バッチ・ジョブ・ステップに送信するための通信プロセス（３１）と
を含む、情報ハンドリング・システム。
【請求項１３】
情報ハンドリング・システムであって、
通信リンクを介して、処理クライアント（５〜９）および提出クライアント（２〜４）として動作する複数のクライアントに結合され、双方向パイプ（４０、４１）を提供するコンピューティング・システムと、
同時に処理クライアント（５）におけるバッチ・ジョブ・ステップ（３５）からの出力を受信し、入力を前記処理クライアントにおける前記バッチ・ジョブ・ステップに送信するための通信プロセス・アプリケーションとを含み、
通信プロセス（３１）において、提出クライアントは処理クライアントにおける処理ステップの完了を、前記処理クライアントとの通信リンクの終了の検出によって検出する、
情報ハンドリング・システム。
【請求項１４】
情報ハンドリング・システムであって、
集中サーバ（１）および通信アプリケーションを有するコンピューティング・システムを含み、
集中バッチ・マネージャは、ワークロード・バランシングならびにジョブの開始および完了を担い、その間に他のコマンドおよびステータス情報が、複数のサブミッタのシステムと、それらの各ワークロードを処理中である前記コンピューティング・システムの複数のクライアント・システムの間で直接通信される、
情報ハンドリング・システム。
【請求項１５】
イベントドリブンのピア・ツー・ピア通信を前記サブミッタのシステムとクライアント・システムの間で利用し、前記通信プロセスは、詳細なステータスおよびコントロール情報を、前記集中サーバをオーバーロードさせることなく、かつポーリングすることなく、渡すことを可能にする、請求項１４に記載の情報ハンドリング・システム。
【請求項１６】
多数のプロセス・スレッドが、前記集中サーバに結合されたサブミッタ・システムおよびクライアント・バッチ・システムにおいて使用され、ユーザ・インターフェースは結果を統合し、サブミッタに表示し、コマンドを、クライアント・バッチ・システム上で実行するプロセスに送信できるようにする、請求項１５に記載の情報ハンドリング・システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、並列処理、バッチ処理およびグリッド・コンピューティングの分野に関し、詳細には、バッチ・ジョブのサブミッタがバッチ・ジョブと、それらの実行中に対話する必要のあるアプリケーションに関する。開示する実施態様は、ジョブの発信側と、これらのジョブを処理するクライアント・システムの間の改善された通信およびフィードバックを提供し、サブミッタがリアル・タイムのフィードバックをジョブの進行において受信できるようにし、リアル・タイムのコマンドを送信して前記ジョブの継続されたオペレーションを変更できるようにする。本発明は詳細には、バッチ・ジョブのサブミッタがバッチ・ジョブと、それらの実行中に対話する必要のあるアプリケーションを対象とする。
【０００２】
商標：ＩＢＭ（登録商標）は、米国ニューヨーク州アーモンクのインターナショナル・ビジネス・マシーンズ・コーポレーションの登録商標である。他の名称は、インターナショナル・ビジネス・マシーンズ・コーポレーションまたは他の会社の登録商標または製品名である。
【背景技術】
【０００３】
バッチ処理および並列処理システムは長年に渡って存在している。これらは通常、単一のジョブを処理のために、多数の独立ジョブのために、あるいは、より大きいジョブのサブステップを含む可能性のある関連ジョブのセットのために、提出するのに使用することができる。ＩＢＭの LoadLevelerはこのようなシステムの一例であり、グリッド・コンピューティングは、LoadLeveler により提供されたものに基づいて構築され、より多様な環境内で使用するための柔軟性およびセキュリティによりこれを拡張する、新しい分野である。
【０００４】
並列処理システムの通常の実施態様により、多数のクライアントがそれぞれ多数のジョブ・ステップを提出して、クライアントのプールの間で処理のために分散させることができる。これは通常、集中サーバにすべてのこのようなリクエストを受信させ、これらの優先順位を付けさせ、クライアント・システムのプールに処理のために分散させることによって実施される。集中サーバは、クライアントの間のワークロード・バランシング、ジョブを開始および維持するために必要なクライアント・システムへのコマンド、ならびに、アクティビティの監視、およびサブミッタへの、各クライアントにおけるジョブ・ステップの完了などのステータスの通知を担う。
【０００５】
これらの通常のアプリケーションでは、ジョブ・ステップがクライアント・システムにおいて処理のために開始された後、すべての通信は集中サーバを通過しなければならず、ジョブ・ステップの完了前のサブミッタとの通信、または、ジョブ・ステップからサブミッタへの結果のフィードバックはほとんどない。これは、いくつかの実際的な制限から生じる。集中サーバは多数のジョブ・ステップを多数のサブミッタについて同時に処理することができ、また、集中サーバは通常、特定のアプリケーションに合わせてカスタマイズされていない汎用サーバであるという事実により、集中サーバは、各処理クライアントにおける各ジョブ・ステップの特定のアクションおよび要件をリアル・タイムで扱う能力または容量を有していない。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
開示する本発明では、以前にバッチ・ジョブのディスパッチおよび管理のために使用されたような集中サーバが修正されずに、従来技術のように残る。しかし、本発明の好ましい実施形態は、ジョブの発信側と、これらのジョブを処理するクライアント・システムの間の、改善された通信およびフィードバックを提供し、サブミッタがリアル・タイムのフィードバックをジョブの進行において受信できるようにし、リアル・タイムのコマンドを送信して前記ジョブの継続されたオペレーションを変更する。
【課題を解決するための手段】
【０００７】
本発明の好ましい実施形態によれば、バッチ・ジョブ・アプリケーションのサブミッタ・アプリケーションがバッチ・ジョブと、それらの実行中に対話することができる。本発明では、ソフトウェア・レイヤが各サブミッタのシステムで、およびジョブ・ステップが処理される各バッチ・クライアントで追加される。これらの追加のソフトウェア・レイヤはパイプラインおよび通信プロトコル（ＴＣＰ／ＩＰソケットなど）を利用して、サブミッタのシステムと、各処理クライアント上の各ジョブ・ステップの間の直接通信を可能にする。これらの追加のソフトウェア・レイヤは、ジョブ・サブミッタ・アプリケーションのコントロール下にあり、必要であれば、サブミッタのワークロードの特定の要件をサポートするために、集中バッチ・マネージャを修正することなく、修正することができる。これらの追加のソフトウェア・レイヤはピア・ツー・ピア通信をサブミッタのシステムと各バッチ処理クライアントの間で利用し、サブミッタのクライアント・システムと各処理クライアントの間で、集中バッチ・マネージャを通じて通信チャネルを使用することなく、通信を直接可能にする。
【０００８】
これらおよび他の改良を、以下の詳細な説明で示す。本発明を利点および特徴と共によりよく理解するために、明細書および図面を参照されたい。
【０００９】
この詳細な説明では、本発明の好ましい実施形態を、利点および特徴と共に、例として図面を参照して説明する。
【発明を実施するための最良の形態】
【００１０】
図１は、ワークロードを複数のサブミッタから多数のクライアントへ、処理のために分散するための典型的なシステムを例示する。通常、集中サーバ１があり、これに対してすべてのリクエストが行われ、これからすべてのクライアントがリクエストを処理するために受信する。クライアントはしばしば、サブミッタまたはプロセッサになることができ、ある役割から他の役割へと切り替わることができ、あるいは、同時にサブミッタおよびプロセッサとしての役割を果たすこともできる。図示の例では、クライアント２、３および４はサブミッタとして機能し、クライアント５、６、７、８および９は処理サービスを提供するようになる。図示の通信構造は、リンク１０、１１、１２、１３、１４、１５、１６および１７からなり、クライアントによって、集中サーバ１との通信のために使用される。これらの通信リンクは、サブミッタ２、３および４によって処理サービスについてのリクエストを行うために、集中サーバ１が処理リクエストをクライアント５、６、７、８および９にディスパッチするために、また、集中サーバがすべてのクライアントのステータスおよび進行を監視するために利用される。集中サーバ１はまた、あるフィードバックを提出クライアント２、３および４に提供することもでき、これは例えば、処理の完了の通知、および、共有ファイル・ストレージ・システムなど別のメカニズムを介して戻されない場合に、最終結果を戻すことである。この通信構造は、本発明では変更されずに残り、これらの役割を果たし続け、集中サーバ１は、クライアントの間のワークロード・バランシングの重要な役割を果たし続ける。
【００１１】
図２は、本発明によって、クライアントの間の通信のために開かれた追加の通信パスを例示する（これらの通信パスは、図１におけるパスに追加するものであるが、明確にするために別々に示す）。これらの通信パスはクライアントによって確立され、図１に示す集中サーバ１による参加はない。図示の例では、クライアント２が処理サービスについてのリクエストを行っていること、および、このリクエストがサーバ１によって、クライアント５および６において実行されるように割り当てられていることを仮定する。さらに、クライアント３が処理サービスについてのリクエストを行っていること、および、このリクエストがサーバ１によって、クライアント７および８において実行されるように割り当てられていることを仮定する。さらに、クライアント４が処理サービスについてのリクエストを行っていること、および、このリクエストがサーバ１によって、クライアント９において実行されるように割り当てられていることを仮定する。
【００１２】
前記リクエストが処理のために分散されるとき、図２に示す通信パスがクライアントによって確立される。通信パス１８および１９が、図のようにクライアント２とクライアント５の間で開かれる。通信パス２０および２１が、図のようにクライアント２とクライアント６の間で開かれる。同様に、通信パス２２、２３、２４、２５、２６および２７が、残りの提出クライアントと処理クライアントの間で、図のように、前述のジョブ・ステップ分散に対応して開かれる。
【００１３】
図３は、図の上部に位置する提出クライアント２と、図の下部に位置する処理クライアント５および６の間の通信を、より詳細に例示する。この図は、個々のソフトウェア・プロセス・スレッドを示し、これらは共に、本発明の対象である通信サービスを提供する。
【００１４】
マルチステップ・バッチ・ジョブを提出するため、リクエストがクライアント２によってバッチ・サーバ１に提出される。このリクエストを、図４に示すものなど、コントロール・ファイルの形式にすることができる。このコントロール・ファイルは、従来技術のシステムの典型的なものである。この例のコントロール・ファイルは、２つの処理クライアントを必要とする２ステップ・ジョブを指定するが、いかなる数のジョブ・ステップをも指定することができる。２つの処理クライアントは通常、２つの例のステップを並列に（同時に）処理することが予想される。行１ないし１１は、第１のジョブ・ステップについてのコントロール情報およびパラメータであり、行１２ないし２２は、第２のジョブ・ステップについてのコントロール情報およびパラメータである。
【００１５】
本発明によって企図される監視およびコントロールを達成するため、クライアント２によるバッチ・サーバ１へのリクエストが、処理クライアントに実際のバッチ・ジョブ・ステップの前に監視プロセスを開始させるように、修正される。これは、図４のコントロール・ファイルを、図５のように修正することによって達成される。このファイルは行６および１７で２つのジョブ・ステップについて修正され、修正部分は、例示のために太字のフォントで強調されている。コントロール・ファイルのこれらの行で指定された引数は、これらのジョブを、処理クライアント５および６においてそれぞれ実行されるように指定する。クライアント５はこの変更によって、監視プロセス「ｌｌｓｉｍ」を実行するように命令され、この行の残りはこのプログラムへの引数を含む。これらの引数には、以下が含まれる。
【００１６】
１）監視プロセスの名前４６は、ここでは「ｌｌｓｉｍ」であり、処理クライアントにおいて使用可能にされなければならないプログラムである。
【００１７】
２）サブミッタのシステム（クライアント２）のネットワーク名（ホスト名）４７は、この例ではｃｌｉｅｎｔ２．ｃｏｍと仮定される。
【００１８】
３）サブミッタのシステム（クライアント２）のコンタクト・ポートの数字４８は、バッチ・ジョブ・ステップから通信を受信するために使用され、この場合、この実施形態の好ましいＴＣＰ／ＩＰポートは４９１６３である。
【００１９】
４）処理クライアントによって、それらによるサブミッタのシステムへのアクセスの受け入れを認証するために使用されるオプションの秘密セキュリティ鍵４９を、この例ではｋｅｙ０で示す。これは、ランダムな方法を含む様々な方法によって生成することができ、それぞれの新しいジョブ提出は異なる鍵を使用する。この鍵は、集中ホスト１によって処理クライアント５および６に渡され、提出クライアント２に戻るアクセスのために使用される。これにより、提出クライアント２が、それが開始したこれらのジョブのみから入力を受け入れることが保証される。
【００２０】
５）元の引数は、この例では「ｐｓｉｍ」（バッチ・ジョブ・ステップのプログラム名）により開始し、このプログラムについての引数が続く。
【００２１】
図５に示す、必要とされた修正がクライアント２において、リクエストを集中サーバ１に提出する前に行われる。
【００２２】
ジョブ提出プロセスを開始するため、クライアント２におけるサブミッタはプログラムを呼び出し、このプログラムは、処理クライアント（この例では、これらはクライアント５および６になるが、これらのクライアントのＩＤはまだサブミッタに知られていない）からの通信を受け入れるための準備をして、修正されたジョブ・リクエストを集中サーバ１へ処理のために提出するようになる。本発明では、サブミッタがプログラム「ｌｌｓｉｍ」を呼び出し、引数として、図４に示すコントロール・ファイルの名前を供給する。プログラム「ｌｌｓｉｍ」は、処理クライアントにおける監視プロセスとなるものと同じプログラムであり、それがサブミッタのシステム（この例ではクライアント２）上で実行中であるか、または処理クライアント（この例ではクライアント５または６）上で実行中であるかを判断することができ、また、その実行環境に適切な処置を取ることができる。このプログラムはこれを、プログラムに供給された引数を検査することによって判断する。代替実施態様は、異なるプログラムをサブミッタのシステムおよび処理クライアントにおいて使用することができる。
【００２３】
クライアント２におけるサブミッタによって開始されるとき、監視プログラム「ｌｌｓｉｍ」は以下のステップを実行し、図３に示すプロセスを開始する。
【００２４】
１）プログラムは、それが作成するすべての子プロセスのプロセスＩＤを保持するためのテーブルを準備して、メイン・プロセスが終了されるときにすべての前記プロセスを終了し、いかなる実行中のゾンビ・プロセスをも残すことを回避できるようにする。各子プロセスはテーブルに、それが以下のステップにおいて作成されるときに、入れられるようになる。このプログラムはまた、「キル」、「終了」、および類似のイベントにフックして、メイン・プログラムが終了されるときは常にこのテーブル内のプロセスを終了する。
【００２５】
２）プログラムは、それがサブミッタのシステム上で実行中であることを、プログラム引数の検査によって判断し、サブミッタのシステムのためのパスに続く。
【００２６】
３）プログラム（初期プロセス２８）は子プロセス２９をフォークし、親は終了する。子は新しいメイン・プロセスとして引き継ぐ（このステップはオプションであるが、いくつかのオペレーティング・システムにおいて、これはこのプロセスをバックグランド・プロセスにし、ユーザをコマンド・プロンプトに戻す）。新たに作成されたプロセス２９は、ユーザとのすべての対話を処理する。
【００２７】
４）ユーザ・インターフェース・プロセス２９は、空いている通信ポートを探索し、選択されたポートを開いて、接続サブプロセス３０および通信サブプロセス３１、３２、ならびに、作成することができる任意の追加の通信サブプロセスからの接続をリスンする。開かれたポートは、図３のユーザ・インターフェース・プロセス２９における３９である。好ましいポートが使用中である場合（プログラムの別のインスタンスがすでに実行中である場合に可能）、別のポートが選択され、ユーザ・インターフェース・ウィンドウのバックグラウンドの色が変更されて、このインスタンスが他のインスタンスから区別されるようになる。
【００２８】
５）次いで、ユーザ・インターフェース・プロセス２９は、バッチ・マシンからの接続を受け入れるために子プロセス３０をフォークし、それぞれがそれ自体の実行パスを継続する。これらの２つのプロセス（独立プロセス・スレッド）は、接続をそれら自体の間で通信リンク３９において確立し、場合によっては、サブプロセスが作成される前に生成され、かつ、通信が受け入れられるためにフォーク・プロセスの一部として新しい各サブ・プロセスと共有される秘密鍵の使用を必要とする。
【００２９】
６）通信リンク３９が確立された後、ユーザ・インターフェース・プロセス２９は、ユーザと通信してコマンドを受信し、結果を表示するための準備をする。好ましい実施形態では、このインターフェースはグラフィカル・ユーザ・インターフェースからなるが、他の方法もまた利用することができる。このプロセスは、グラフィカル・インターフェースからのユーザ入力、および、同じくサブミッタのシステム上で実行中の他のプロセスからのＴＣＰ／ＩＰ接続からのデータを受信することができる。グラフィカル・ユーザ・インターフェースが終了されるとき、クライアント２におけるすべてのサブプロセスがキルされ、監視プロセスがサブミッタのシステム２において完了する。これは、すべての処理ステップが処理クライアント５および６において完了する前または後に、行うことができる。早く終了された場合、処理クライアントへの接続を再確立するための準備は行われない。
【００３０】
７）接続プロセス３０は別の通信ポートを、バッチ・クライアントからの接続を受信するために開く。これは別のポート番号になり、ユーザ・インターフェース・プロセス２９によって作成されたものとは別個であり、これが、新しい接続を処理クライアントから受信するために使用されるようになる。このポートを、図３の接続プロセス３０の下に示す（ただ１つのポートしかなく、図示の２つの接続は両方とも同じポートに接続する）。
【００３１】
８）接続プロセス３０はことのき、図４に示すバッチ・コントロール・ファイルを読み取り、これを図５のように修正し、集中サーバ１へ処理のために提出する。この修正には、監視プロセスの名前（このプログラム自体の名前「ｌｌｓｉｍ」）、そこにおいてそれが実行中であるホスト名（この例では、ｃｌｉｅｎｔ２．ｃｏｍ）、前のステップで開かれた通信ポート番号を挿入することが含まれ、また、処理クライアントが、アクセスを得て結果をユーザ・インターフェース・プロセスに戻すために提示しなければならない、秘密鍵または類似のセキュリティ・デバイスも含まれる可能性がある。
【００３２】
９）接続プロセス３０は、提出されたばかりのジョブについての選択された情報を、ユーザ・インターフェース・プロセス２９に戻すように送信する。ユーザ・インターフェース・プロセスはこの情報を使用して、開始された処理ステップの数を表示し、また、コマンド・ファイルが提出されたとき、ユーザが集中サーバを介して処理をキャンセルすることを望む場合に、戻されるジョブ名について、キャンセル・コマンドが集中サーバ１に送信されるようにすることができる。
【００３３】
１０）集中サーバ１は処理クライアントを選択し、処理ステップを、選択されたクライアント５および６にディスパッチする。
【００３４】
１１）接続プロセス３０は、処理クライアントからの新しい接続を待機する。新しい接続が受信されるたびに、接続プロセス３０は別の子プロセスをフォークして、新しい接続を処理する。
【００３５】
１２）各処理クライアント、例えば５において、集中サーバ１は、コントロール・ファイルで指定されたプログラムを開始し、この場合は監視プロセス「ｌｌｓｉｍ」が、図３のプロセス３４として開始する。このプロセスは最初に、それが処理クライアント上で実行中であることを、それが受信する引数の検査によって判断し、適切な実行パスに続く。取られる最初のステップは、それを介して提出クライアント２と通信するための通信ポートを開くことである。この接続は、先に図５の行６または１７に追加され、かつ、処理クライアント５が集中サーバ１によって開始されるときにプログラム引数として監視プロセス「ｌｌｓｉｍ」に供給される、ホスト名およびポート番号に対して行われる。初期接続は、レスポンス・プロセス３４から接続プロセス３０へ、通信リンク１８を介して行われる。実施態様に応じて、秘密鍵が図５の修正において挿入された場合、接続プロセス３０は、この秘密鍵が送信されて接続を妥当性検査することを必要とする場合がある。接続を安全にするための追加のステップもまたオプションで行うことができ、これはリンクの暗号化の確立などである。
【００３６】
１３）接続プロセス３０への最初の処理クライアント接続はフォークを引き起こし、結果として通信プロセス３１の作成を生じる。次の接続は結果として通信プロセス３２の作成を生じ、追加の処理ステップがある場合、それぞれについての追加の類似の通信プロセスを生じる。接続プロセス３０は、新しい接続を受け入れ、これらの新しい通信プロセスを開始するためにのみ存在する。加えて、作成された各通信プロセスについて、一意のＩＤ（好ましい実施形態では、新たに作成されたプロセスＩＤ）が、接続プロセス３０によってユーザ・インターフェース・プロセス２９へ戻すように、通信リンク３９を介して送信される。このＩＤは、通信プロセス３１、３２などからの将来の各接続において使用されて、どの処理クライアントからメッセージが出ているかが識別され、これらのメッセージを正しい処理クライアントに帰することができるようになる。
【００３７】
１４）接続プロセス３０内のフォークにより、レスポンス・プロセス３４からの通信が子プロセス（通信プロセス）の方へ進み、処理クライアント５からのすべての将来の通信が通信プロセス３１によって受信されるようになる。通信リンク１８は、処理クライアント５におけるバッチ・ジョブ・ステップ３５が完了するまで、レスポンス・プロセス３４と通信プロセス３１の間で開いて接続されたまま残る。
【００３８】
１５）この時点で、レスポンス・プロセス３４は初期の自己識別メッセージを通信プロセス３１に送信し、これがユーザに、初期コンタクト・メッセージとして転送および表示されるようになる。通信プロセス３１がこのメッセージを受信するとき、このメッセージを、通信リンク４４を介して転送する（それが接続プロセス３０からフォークされたときにそれが継承したリンク３９のコピーであり、３９、４４および４５として示すリンクは、ユーザ・インターフェース・プロセス２９内の同じ受信ポートに接続する）。ユーザ・インターフェース２９が、どのクライアントからこのメッセージが来るのかを判断することができるように、通信プロセス３１はそのＩＤ（好ましい実施形態ではプロセスＩＤ）をメッセージにアタッチし、また、プロセス２９および３０によって確立された場合、プロセス３０から継承された秘密鍵を含むことが必要とされる可能性もある。ユーザ・インターフェース２９へ通信プロセス３１によって転送されるすべての将来のメッセージもまた、この同じＩＤによりタグ付けされるようになる。ユーザ・インターフェース・プロセス２９は、このＩＤによって識別されるような特定の処理クライアント・ステップに帰する、受信されたメッセージを表示する。
【００３９】
１６）次いで、通信プロセス３１は、それ自体およびそのユーザ・インターフェース・プロセスを識別するために必要な情報を、レスポンス・プロセス３４に送信する。これらは提出クライアント２の識別を含む場合があり、これはそのホスト名または秘密鍵などであり、これが後に使用されて、ユーザ・インターフェース２９からのコマンドがコマンド・プロセス３３によって受け入れられて処理される前に妥当性検査される。この情報が使用されて、処理クライアント５が、元のサブミッタ以外のいかなるクライアントからのコマンドをも受け入れないようにされる。レスポンス・プロセス３４はこの情報を保存して、それが作成されるときにコマンド・プロセス３３に渡されるようにする。
【００４０】
１７）通信プロセス３１は、レスポンス・プロセス３４から受信されたいかなるメッセージをもユーザ・インターフェース・プロセス２９へ転送する。通信リンクが処理クライアント側から閉じられる場合、通信プロセス３１はこれをユーザ・インターフェース・プロセス２９へ戻すようにレポートし、ユーザ・インターフェース・プロセス２９はこの情報を使用してユーザに、処理ステップが完了したことを通知する。この通信リンクのドロップの検出により、この趣旨のメッセージが処理クライアントから受信されない場合でも、ユーザに、処理ステップが完了したことを通知することが可能である（これは、処理クライアント上のジョブが失敗する場合、有用な指示となる場合がある）。
【００４１】
１８）レスポンス・プロセス３４はその残りの引数を使用して（接続プロセス３０によって追加され、図５に示した情報を、集中サーバ１に提出する前に除去した後）、最初に図４の処理ステップとして指定されたジョブを開始する。ジョブを開始するための手順を次のステップで説明する。
【００４２】
１９）レスポンス・プロセス３４はバッチ・ジョブ３５を開始し、入力（通常はＳＴＤＩＮ）および出力（通常はＳＴＤＯＵＴ）は双方向パイプ（双方向通信を受け入れるもの）に接続されて、バッチ・ジョブへの入力およびそれからの出力がパイプを通じてレスポンス・プロセス３４に向けて送られるようにする。双方向パイプの入力は、図３ではリンク４０として表され、出力はリンク４１として表される。
【００４３】
２０）１つのプロセスは２つのソース（通信リンク１９を介したユーザ・インターフェース・プロセス２９、および、パイプ４１を介したバッチ・ジョブ３５の出力）からの入力を容易に処理することができないので、レスポンス・プロセス３４は別のコマンド・プロセス３３をフォークして、１つの通信パスを処理する。
【００４４】
２１）コマンド・プロセス３３は、それを介してコマンドをユーザ・インターフェース・プロセス２９から受信するための新しい通信ポートを開く。次いで、コマンド・プロセス３３は、この新しいポートを記述するコンタクト情報を、先に確立された通信リンク１８を介して、通信プロセス３１およびリンク４４を通じて、ユーザ・インターフェース・プロセス２９に送信する（コマンド・プロセス３３は、それがレスポンス・プロセス３４からフォークされるときにリンク１８の接続のコピーを継承し、この接続を一度だけ使用して、それが通信リンク１９を介したユーザ・インターフェース・プロセス２９からの入力のリスニングを開始する前にこのコンタクト情報を送信する）。コマンド・プロセス３３から送信されたコンタクト情報には、処理クライアントのホスト名、接続ポート番号、および、リンク１９において受信されたコマンドを妥当性検査するために使用されるオプションの秘密鍵が含まれる。この情報は、ユーザがコマンドを、処理クライアント５において実行するジョブ・ステップ３５に送信することを選択する場合、ユーザ・インターフェース２９によって使用される。ユーザ・インターフェース・プロセス２９は、コマンドを送信する必要があるときにのみ、接続１９を完成させることができ、各コマンドが送信された後に接続を閉じ、別のコマンドが送信されなければならない場合、この接続を再び開くことができる。ユーザ・インターフェース・プロセス２９およびコマンド・プロセス３３はまたオプションで、リンク１９を介した通信を暗号化するように選択することもできる。コマンド・プロセス３３は、ユーザからのコマンドを、通信リンク１９を介して処理し、これらを、パイプ接続４０を介してバッチ・ジョブ３５に転送する。
【００４５】
２２）レスポンス・プロセス３４はバッチ・ジョブ３５からの、パイプ接続４１を介して受信された出力を処理し、この出力を通信プロセス３１へ、通信リンク１８を介して転送する。
【００４６】
２３）レスポンス・プロセス３４は、バッチ・プロセス３５が完了してパイプ接続を閉じているときを検出する。これが起こるとき、レスポンス・プロセス３４はコマンド・プロセス３３を終了し、次いでそれ自体を終了し、これは通信プロセス３１および集中サーバ１によって、バッチ・ステップの完了として見なされるようになる。
【００４７】
２４）ステップ１２ないし２３が各ジョブ・ステップについて繰り返され、それぞれについての一意のプロセスが作成される。通信プロセス３２およびコマンド・プロセス３６、レスポンス・プロセス３７、ならびにバッチ・ジョブ３８（リンク４２および４３はリンク４０および４１に対応する）は、第２のジョブ・ステップについて作成されたプロセスを表す。追加のジョブ・ステップは、追加の類似のプロセスを作成するようになる（図示せず）。
【００４８】
ユーザ・インターフェース・プロセス２９は適切なユーザ・インターフェースを提供して、双方向対話をサブミッタと各ジョブ・ステップの間で、前記ステップを監視およびコントロールするために可能にする。このインターフェースは、図６、７、８および９に示すものに類似した形式における多数のグラフィカル・インターフェース・ウィンドウからなる可能性がある。
【００４９】
図６は、ユーザ・インターフェース・プロセス２９によって表示されたメイン監視プロセス・ウィンドウの可能な実施態様を例示する。このインターフェースはキャンセル・ボタン５０を含み、これは唯一設けられた、集中サーバ１と通信する機能である。このボタンは、すべてのジョブ処理ステップを、集中サーバ１がこの目的のために使用可能にするコマンドを利用して、キャンセルするための手段を提供する。すべての残りのユーザ・インターフェース・コントロールは、提出クライアント２と処理クライアント５および６の間（または、提出クライアント３と処理クライアント７および８の間など）の直接ピア・ツー・ピア接続（通信リンク１８、１９、２０、２１、２２、２３、２４、２５、２６および２７）を通じて提供およびサービスされる。
【００５０】
図６のメイン・ユーザ・インターフェースは、コマンド・テキスト・エントリ・ウィンドウ５１を含み、これはユーザが、通信リンク、例えば１９または２１を介して、コマンド・プロセス、例えば３３または３６に送信されるコマンドを入力するためのものであり、コマンド・プロセスからコマンドが、パイプ接続、例えば４０または４２を介して、バッチ・ジョブ３５または３８に転送される。このコマンドは、すべてに送信ボタン５２が押されるとき、すべてのアクティブなジョブ・ステップ３５および３８、ならびにありとあらゆる追加のステップに送信され、あるいは、個別のジョブ・ステップに対応する送信ボタン５９が押されるとき、１つの個別のジョブ・ステップに送信される。
【００５１】
図６のメイン・ユーザ・インターフェースはまた、各ジョブ・ステップに対応するステータスの行も表示する。表示された情報には、処理クライアント名５４、そのクライアント上で実行するジョブ・ステップ名５５、ジョブ・ステップからの最終メッセージの時間５６、ジョブ・ステップからの最終メッセージ５７（ジョブ・ステップからパイプ接続４１または４３を介して、レスポンス・プロセス３４または３７を通じて、通信リンク１８または２０を介して、通信プロセス３１または３２を通じて、通信リンク４４または４５を介して、ユーザ・インターフェース・プロセス２９へ受信される出力の最終行であり、ユーザ・インターフェース・プロセス２９で表示される）、および現在の接続または完了サマリ・ステータス６０が含まれる可能性がある。
【００５２】
加えて、図６の各ジョブ・ステップはボタン５８を含み、これにより、ジョブ・ステップについての追加の情報を表示させることができる。このボタンを押すことにより、ユーザ・インターフェース・プロセス２９に追加のウィンドウを開かせる。この追加のウィンドウの可能な実施態様を図７に示す。
【００５３】
図７のジョブ詳細ウィンドウは、コマンド・テキスト・エントリ・ウィンドウ６１および対応する送信ボタン６２を含む。これらは、コマンドをこの１つのジョブ・ステップに送信する機能であり、メイン・ユーザ・インターフェース内のコマンド・ウィンドウ５１および送信ボタン５９と同じ機能を実行する。このジョブ詳細ウィンドウの主な機能は、メイン・ユーザ・インターフェース内で表示された最新の１行５７ではなく、ジョブ・ステップ６４からのすべての出力の完全表示を提供することである。
【００５４】
ユーザ・インターフェース・プロセス２９は、特定のアプリケーションに合わせてカスタマイズされた追加の機能を有することができる。これらの追加の機能を、ジョブ・ステップ全体の完了の前に、ジョブ・ステップの中間結果が戻されるときにこれらを認識し、これらに反応することにすることができる。このようなカスタマイズされた機能には、成功もしくは失敗、または他の特性を認識およびレポートすること、および、ステータスが知られるとすぐにユーザのために更新されるように保つことを含むことができる。ある状態は、結果としてユーザへの即時アラートを、追加の表示ウィンドウおよびアラート音を介して生じることができ、これは図８に示すジョブ失敗指示ウィンドウなどであり、あるいは結果として、コマンドをいくつかのジョブ・ステップに、他のジョブ・ステップによってレポートされた状態の結果として送信するなど、自動アクションを生じることができる。すべてのジョブ・ステップの終りに、ユーザ・インターフェース・プロセス２９は追加の情報ウィンドウを開き、アラート音を出してユーザに完了を通知することができる。このようなウィンドウの一例を図９に示す。
【００５５】
メイン・ユーザ・インターフェース・ウィンドウは終了ボタン５３を有し、これは、すべてのウィンドウ（図６、７、８および９に示すウィンドウなど）を閉じ、提出クライアント２における３０、３１および３２などのすべてのサブプロセスを閉じ、最後に、ユーザ・インターフェース・プロセス２９を終了して、提出クライアント２におけるすべての監視機能を終了する。サブウィンドウ（図７、８および９に示すものなど）は、閉じるボタンを有し、これは例えば６３、６５および６６であり、いかなるプロセスを終了することも、いかなる他のウィンドウを閉じることもなく、サブウィンドウのみを閉じる。
【００５６】
メイン・インターフェース・ウィンドウおよび提出クライアント２におけるプロセスを終了することで、処理クライアント５もしくは６、または類似のものにおいて実行中のいかなるプロセスも終了されないが、これが起こる場合、３３、３４、３６および３７を含むコマンドおよびレスポンス・プロセスはもはや提出クライアント２と通信できなくなる。コマンドおよびレスポンス・プロセス３３、３４、３６および３７は提出クライアント２への通信リンクのドロップを許容し、追加の出力を提出クライアント２に戻すことなくバッチ・ジョブ・ステップ・プロセス３５および３８が完了を継続できるようにするべきである。
【００５７】
開示されたコンピューティング・システムおよびアプリケーションは、グリッドおよびバッチ・コンピューティング・システムにおけるジョブの改善された監視およびコントロールのための解決法を提供することは理解されよう。大部分のグリッド・コンピューティング・システムでは、集中マネージャ、通常は単一のサーバが、多数のサブミッタからのリクエストを受信し、優先順位を付け、多数の処理クライアント・システムにおいて処理を開始する。この従来の方法では、集中サーバは、複数のサブミッタのシステムとのすべての通信、および、クライアント・システム上で実行する複数のジョブを管理し、これには、コマンドをクライアント・システムに転送すること、および、結果をサブミッタに戻すように配布することが含まれる。集中サーバを通じたこの通信の集中は必然的に、可能な通信の、特に、個々のクライアント・システムにおけるバッチ・プロセスの進行の詳細なステータスの、範囲および広さを制限し、そうでない場合は、集中サーバを過度な通信トラフィックによりオーバーロードさせる可能性がある。開示した方法では、集中バッチ・マネージャは、ワークロード・バランシングならびにジョブの開始および完了のみを担い、すべての他のコマンドおよびステータス情報は、複数のサブミッタのシステムと、それらの各ワークロードを処理する複数のクライアント・システムの間で直接通信される。この増大した量のフィードバックは、非常に多数の処理クライアントが１つの提出クライアントにレポートするアプリケーションには適切ではない場合があり、これは、このフィードバックもまた提出クライアントをオーバーロードさせる可能性があるからであるが、即時フィードバックが監視、デバッグ、またはプロセス修正のために必要とされる状況では、この方法は、通常のサーバ中心の分散処理システムを介して可能であるよりも多くのコントロールを提供する。開示した実施態様は、イベントドリブンのピア・ツー・ピア通信をサブミッタのシステムとクライアント・システムの間で利用し、より詳細なステータスおよびコントロール情報を、集中サーバをオーバーロードさせることなく渡すことができるようにし、ポーリングを回避することによって、結果のより即時のフィードバックも提供する。開示したシステムは、多数のプロセス・スレッドをサブミッタのシステムおよびクライアント・システムにおいて利用し、また、ユーザ・インターフェースが結果を統合し、サブミッタに結果を表示して、コマンドを、クライアント・バッチ・システム上で実行中のプロセスに送信できるようにすることを提供する。
【００５８】
本発明の好ましい実施形態を説明したが、現在および将来において、以下の特許請求の範囲の範囲内に入る様々な改善および改良を行うことができることは、当業者には理解されよう。これらの特許請求の範囲は、最初に説明した本発明のための適切な保護を維持するように解釈されるべきである。
【図面の簡単な説明】
【００５９】
【図１】集中サーバと、集中サーバのクライアントと見なすことができる提出システムおよび処理システムの間の接続を例示する図である。
【図２】提出クライアントと処理クライアントの間の直接ピア・ツー・ピア接続を例示する図である。
【図３】提出および処理クライアント上に追加されて直接通信を可能にする、ソフトウェア・レイヤ（独立プロセス・スレッド）を例示する図である。
【図４】マルチステップ・ジョブを提出するための、修正されていないジョブ・コントロール・ファイルを例示する図である。
【図５】マルチステップ・ジョブの各ステップについての追加の通信プロセスの呼び出しを挿入するように修正された、ジョブ・コントロール・ファイルを例示する図である。
【図６】典型的なメイン・ユーザ・インターフェース・ウィンドウを例示する図である。
【図７】ある個別のジョブ・ステップの進行のより詳細を表示するための、ユーザ・インターフェース・サブウィンドウを例示する図である。
【図８】サブミッタに失敗したジョブ・ステップを即時に通知するための、アラート・ウィンドウを例示する図である。
【図９】サブミッタにすべてのジョブ・ステップの完了を通知するため、および、結果の簡潔な要約を提供するための、アラート・ウィンドウを例示する図である。
【符号の説明】
【００６０】
１  集中サーバ
２  提出クライアント
３  提出クライアント
４  提出クライアント
５  処理クライアント
６  処理クライアント
７  処理クライアント
８  処理クライアント
９  処理クライアント
２９  ユーザ・インターフェース・プロセス
３０  接続プロセス
３１  通信プロセス
３２  通信プロセス
３３  コマンド・プロセス
３６  コマンド・プロセス
３４  レスポンス・プロセス
３７  レスポンス・プロセス
３５  バッチ・ジョブ
３８  バッチ・ジョブ
４０  パイプ接続
４１  パイプ接続
４２  パイプ接続
４３  パイプ接続
【図１】
2005004740.tif 000003
【図２】
2005004740.tif 000004
【図３】
2005004740.tif 000005
【図４】
2005004740.tif 000006
【図５】
2005004740.tif 000007
【図６】
2005004740.tif 000008
【図７】
2005004740.tif 000009
【図８】
2005004740.tif 000010
【図９】
2005004740.tif 000011