JP4533251B2 - 情報処理システムおよびジョブ割り当て方法 - Google Patents

Description

本発明は、情報処理システム、及び該システムにおけるジョブの割り当て方法に関し、より詳細には、ジョブの分散処理を依頼する管理ノードと、依頼された分散処理を実行して管理ノードに処理結果を送信する処理ノードとを含み、ネットワークを介して接続された複数の情報処理装置間で、グリッドコンピューティングによって負荷分散処理を可能とする情報処理システムのジョブの割り当てに関するものである。

近年、ネットワークで接続された複数のコンピュータを一つのシステムのように利用可能とする、グリッドコンピューティング（Grid computing：以下、単に「グリッド」とも称する）が注目されており、様々な分野への適用が試みられている。

図１は、グリッドコンピューティングのアーキテクチャを説明する図である。グリッドには数種類あるが、ここで説明するのはデスクトップグリッドと呼ばれる、デスクトップＰＣなどのＣＰＵの空き時間を利用してジョブを実行するタイプのものである。

図１においてクライアント（Client）１０は、ユーザが要求としてジョブを投入する機器であり、投入されたジョブはタスクマネージャ（Task Manager：以下、ＴＭと略す）２０に渡され、ＴＭ２０はダイナミックジョブスケジューラ（Dynamic Job Scheduler：以下、ＤＪＳと略す）３０にその内容を伝える。

ＤＪＳ３０は、それぞれがブローカ（Broker）４１１とリソースマネージャ（Resource Manager：以下、ＲＭと略す）４１２とを含みリソースとして認識される、複数のホスト機器４１〜４３全体のリソース管理をしており、ジョブを分析して最適なリソースのブローカ４１１を選択してＴＭ２０に通知する。なお、ここでリソースとは利用可能なＣＰＵの空き状態のことを言っている。

ブローカ４１１は、ＲＭ４１２が取得したリソースの情報をＤＪＳ３０に登録し、ＴＭ２０からの要求に応じて最適なリソースにジョブを投入し、ジョブが終了したときにＴＭ２０にジョブの完了を通知する。

ＴＭ２０は、ＤＪＳ３０が選択した最適なブローカ４１１にジョブを投入し、以後そのジョブの進行状況をモニタリングし、完了通知をブローカ４１１から受信するとクライアント１０にその結果を通知する。またリソースに変化や異常が発生したとき（例えば、故障や他のジョブを受け付けた等）、ＲＭ４１２はブローカ４１１に通知する。

このような仕組みで、通常は利用されていないＣＰＵなどのリソースにジョブを配分し、ユーザが意識することなしに複数の機器での分散処理を可能にすることで、デスクトップグリッドコンピューティングが実現されている。

続いてこの技術を画像処理装置のＰＤＬ処理に適用した場合の構成の説明を図２にて行う。図１の説明ではグリッドを構成するそれぞれのモジュールが別個のものとして扱われたが、印刷装置に適用する場合、複数のモジュールが１つの機器の中に存在することが一般的になる。

図２は、グリッドコンピューティングをプリンタのＰＤＬ処理（ページ記述言語のラスターイメージへの展開処理）に適用する場合の構成を示す図である。図１に示した例ではグリッドを構成するそれぞれのモジュールが別個のものとして扱われたが、複合機（ＭＦＰ）やプリンタ等の画像形成装置に適用する場合、複数のモジュールが１つの機器の中に存在する構成が一般的である。

図２の構成では、ユーザは印刷指示等のジョブをクライアントＰＣ１１０から投入し、投入されたジョブはＴＭ及びＤＪＳ機能を有するプリンタ等の画像形成装置１２０によって分析され、それぞれがブローカ及びＲＭを有するＰＣ１（１４１）、ＰＣ２（１４２）、ＰＣ３（１４３）の３台のＰＣのリソースを用いてグリッドコンピューティングによる分散処理が行なわれる。

すなわち、図示した構成では、画像形成装置１２０が、グリッドコンピューティングにおけるホストとしての機能も有している。もちろん、画像形成装置１２０以外の他のＰＣがホストとしての機能を有していてもよい。

クライアントＰＣ１１０からＰＤＬの印刷ジョブが投入されると、ジョブは画像形成装置１２０のＴＭ及びＤＪＳを経由して１４１〜１４３の各ＰＣのリソースに適宜分散される。またこの時、ＰＤＬのイメージ展開処理用のアプリケーションプログラムも同時に画像形成装置１２０から各ＰＣに送信されるようにする。

それぞれのＰＣでＰＤＬを展開して形成されたイメージは、画像形成装置１２０によって収集されまとめた状態で最終的に出力される。

なお、この分散処理の対象となるホスト（リソース）の数には特に制限はなく３台以上であってもよいし、ジョブが投入されるクライアントＰＣ１１０のリソースや画像形成装置１２０のリソースを分散処理の対象にしても良い。
ＩＢＭプロフェッショナル論文、「グリッド・コンピューティングの商用システムへの適用性」、インターネット、＜ＵＲＬ：http://www-6.ibm.com/jp/provision/no36/pdf/36_ppr1.pdf＞

上記のようなグリッドコンピューティングの技術を用いてコンピュータのＣＰＵパワーを集め、高速処理を実現する研究が行われているが、この技術の組み込み機器への適用はあまり行われていない。

このようにＣＰＵパワーを集めて分散処理を行う場合、ジョブの分散処理を依頼する管理ノードと、依頼された分散処理のデータを受信して処理を施し、結果を返信する１台以上の処理ノードとからシステムが構成される。

通常は、複数の処理ノードで得られる処理結果は全て正しいことを前提にシステムが構築されている。組み込み機器でないＰＣ等のコンピュータリソースを用いる場合は、ＣＰＵやＯＳが同等である場合が多いため、どの処理ノードから得られる処理結果も同等となることが多い。

しかしながら、組み込み機器として、例えばＭＦＰのリソース（例えばＣＰＵパワーや画像処理用ＡＳＩＣ）を利用した分散処理システムにおいては、様々な種類のＭＦＰが混在した環境が想定され、機種毎に使用されているＣＰＵや画像処理ＡＳＩＣなどのハードウエアリソースが異なる場合が考えられる。

また、ハードウエアリソースに限らず、ソフトウェアについても、数値演算ライブラリや画像処理演算モジュールなどのバージョンが異なる場合が考えられる。

上述したように様々な種類の複数のＭＦＰを用いて分散処理を行う場合、処理ノードによって、処理結果が異なることが起こりうるため、分散処理結果の信頼性が低下するという問題が生じる。

例えば、ＰＤＬ処理を分散処理する場合を考える。ページ毎、オブジェクト毎に処理を分割して依頼した時に、色処理の解像度などが他の処理ノードと異なる処理ノードが存在すると、該処理ノードが処理したページだけ色味が違ってしまったり、ページ内の該処理ノードが処理したオブジェクトだけが他のオブジェクトと異なる色味になってしまう場合が生じ、処理結果の画質が低下してしまい、分散処理システムの信頼性が低下してしまう。

また、機種やソフトウェア、ハードウェアのバージョンが違っていても、共通のプラットフォームで設計されている場合があり、機種が異なっても同等な処理結果が得られるケースや、分散処理したい処理に関しては、処理結果に影響を与えない程度の違いであるケースも考えられるため、単純に機種名やソフトウェア、ハードウェアのバージョンに基づいて、処理結果が異なるかどうかを判断することは困難である。そのため、これらの情報に基づいて分散処理の依頼先の処理ノードを選択すると、分散処理の対象となる処理ノードの数が少なくなり、分散処理システムとしての効率が悪くなるという別の問題が生じる。

また、コンピュータのＣＰＵパワーを利用した分散処理システムにおいても、各処理ノードのうち、情報の改竄やデータの劣化が行われる処理ノードがあると、分散処理システムの信頼性が低下するという問題が生じる。

本発明は以上のような状況に鑑みてなされたものであり、情報処理システムで分散処理を行う場合に、分散処理の対象とする処理ノードを適切に選択して分散処理システムの信頼性並びに効率を向上させることを目的とする。

上述の１以上の問題を解決するため本発明の情報処理システムは以下の構成を備える。すなわち、ジョブの分散処理を依頼する管理ノードと、各々が依頼された分散処理を実行して前記管理ノードに処理結果を送信する複数の処理ノードとを含む情報処理システムにおいて、前記管理ノードは、ジョブの種類が互いに異なる第１及び第２のテスト処理に対する処理結果を前記複数の処理ノードの各々から受信し、該複数の処理ノードの各々の状態情報としてジョブの種類毎に管理し、該状態情報に基づいて、前記複数の処理ノードの内、前記第１のテスト処理の処理結果が同じ１以上の処理ノード同士を１つのグループとし、前記第２のテスト処理の処理結果が同じ１以上の処理ノード同士を１つのグループとする、グループ化手段と、要求ジョブを分散処理する際に、該要求ジョブのジョブの種類と前記第１のテスト処理のジョブの種類とが同じである場合は、前記第１のテスト処理の結果に基づきグループ化されたグループの内、相対的に処理ノードを多く含むグループに対し前記要求ジョブのジョブ処理を依頼し、該要求ジョブのジョブの種類と前記第２のテスト処理のジョブの種類とが同じである場合は、前記第２のテスト処理の結果に基づきグループ化されたグループの内、相対的に処理ノードを多く含むグループに対し前記要求ジョブのジョブ処理を依頼する、依頼手段と、を有する。

上述の１以上の問題を解決するため本発明のジョブ割り当て方法は以下の構成を備える。すなわち、ジョブの分散処理を依頼する管理ノードと、各々が依頼された分散処理を実行して前記管理ノードに処理結果を送信する複数の処理ノードを含む情報処理システムにおけるジョブ割り当て方法であって、前記管理ノードが有するグループ化手段が、ジョブの種類が互いに異なる第１及び第２のテスト処理に対する処理結果を前記複数の処理ノードの各々から受信し、該複数の処理ノードの各々の状態情報としてジョブの種類毎に管理し、該状態情報に基づいて、前記複数の処理ノードの内、前記第１のテスト処理の処理結果が同じ１以上の処理ノード同士を１つのグループとし、前記第２のテスト処理の処理結果が同じ１以上の処理ノード同士を１つのグループとする、グループ化工程と、前記管理ノードが有する依頼手段が、要求ジョブを分散処理する際に、該要求ジョブのジョブの種類と前記第１のテスト処理のジョブの種類とが同じである場合は、前記第１のテスト処理の結果に基づきグループ化されたグループの内、相対的に処理ノードを多く含むグループに対し前記要求ジョブのジョブ処理を依頼し、該要求ジョブのジョブの種類と前記第２のテスト処理のジョブの種類とが同じである場合は、前記第２のテスト処理の結果に基づきグループ化されたグループの内、相対的に処理ノードを多く含むグループに対し前記要求ジョブのジョブ処理を依頼する、依頼工程と、を有する。

本発明によれば、テスト処理の処理結果から、所望する結果が得られる処理ノードとそうでない処理ノードとを識別することが可能となり、所望する結果が得られる処理ノードのグループを選択して分散処理を依頼することができる。

従って、分散処理の対象とする処理ノードが適切に選択されるので、所望する結果が得られない処理ノードに分散処理を依頼することが防止され、分散処理システムの信頼性並びに効率を向上させることができる。

以下に、添付図面を参照して、本発明の好適な実施の形態を例示的に詳しく説明する。ただし、以下の実施形態に記載されている構成要素はあくまで例示であり、本発明の範囲をそれらのみに限定する趣旨のものではない。

＜第１の実施の形態＞
第１の実施形態は、複数台の画像処理装置でグリッドコンピューティングシステムを構成するものである。該システムを構成する各画像処理装置は、相互通信可能なインターフェースを介して互いに接続されている。

本実施形態のシステムでは、グリッドコンピューティングにおいて、１台の画像処理装置が分散処理を依頼する管理ノードとして動作し、他の画像処理装置は分散処理を受信して処理を施して結果を返す処理ノードとして動作する。すなわち、管理ノードとして動作する１台の画像処理装置には、ＴＭ及びＤＪＳがインストールされており、分散処理の対象となる処理ノードとして動作する他の画像処理装置には、ブローカ及びＲＭがインストールされている。

（画像形成装置のハード構成）
図３は、本発明に係るグリッドコンピューティング（以下、単に「グリッド」とも称する）を構成する画像処理装置の実施形態としての画像形成装置の一例の外観を示す図である。本実施形態の画像形成装置は、スキャナ機能、複写機能、及び印刷機能を有する複合機（ＭＦＰ）であり、ネットワークプリンタとも呼ばれる。

画像入力デバイスであるスキャナ２０１は、原稿となる紙上の画像を照明し、ＣＣＤラインセンサ（図示せず）を走査することによって、ラスターイメージデータを生成する。

ユーザが、原稿用紙を原稿フィーダ２０４のトレイ２０３にセットして、操作部２０２において読み取り動作の開始を指示すると、画像形成装置のコントローラＣＰＵがスキャナ２０１に指示を与え、フィーダ２０３は原稿用紙を１枚ずつフィードし、スキャナ２０１は原稿画像の読み取り動作を行う。

操作部２０２はコピー動作時の設定指示や状態表示や、各種動作設定の指定をするためのユーザインタフェースであり、タッチパネル型の操作パネルを備えている。

画像出力デバイスであるプリンタエンジン１０３は、ラスターイメージデータを用紙上に印刷する部分である。その方式は感光体ドラムや感光体ベルトを用いた電子写真方式、微小ノズルアレイからインクを吐出して用紙上に直接画像を印字するインクジェット方式等があるが、どの方式でも構わない。なお、プリント動作は、コントローラＣＰＵからの指示によって起動される。

プリンタエンジン１０３は、異なる用紙サイズまたは異なる用紙向きを選択できるように複数の給紙段を持ち、それに対応した用紙カセット２０６、２０７、２０８を備えている。また、排紙トレイ２０５は、印字し終わった用紙を受けるものである。

図４は、本実施形態の画像形成装置の制御構成を示すブロック図である。プリンタコントローラ１０２は、画像入力デバイスであるスキャナ２０１や画像出力デバイスであるプリンタエンジン１０３と接続し、一方ではクライアントＩ／Ｆ３０８経由で、クライアントとの間で印刷データや画像情報やデバイス情報の入出力をする。

ＣＰＵ３０１は、システム全体を制御するコントローラである。ＲＡＭ３０２は、ＣＰＵ３０１が動作するために使用するシステムワークメモリである。また、ＲＡＭ３０２は、画像データを一時記憶するための画像メモリでもある。ＲＯＭ３０３は、ブートＲＯＭであり、システムのブートプログラムが格納されている。ＨＤＤ３０４は、ハードディスクドライブで、システムソフトウェア、画像データを格納する。

操作部Ｉ／Ｆ３０６は、操作部（ＵＩ）２０２との間のインターフェースを司り、操作部２０２に表示する画像データを操作部２０２に対して出力する。また、使用者が操作部２０２を介して入力した情報を、ＣＰＵ３０１に伝える役割を果たす。また操作部２０２からの入力された動作モードなどの環境設定情報は不揮発性のメモリであるNVRAM３１６に記憶される。

クライアントＩ／Ｆ３０８は、各クライアントに対して情報の入出力を行う。以上のデバイスがシステムバス３０７上に配置される。

イメージバスインターフェース（Image Bus Ｉ／Ｆ）３０５は、システムバス３０７と画像データを高速で転送する画像バス３０９とを接続し、データ構造を変換するバスブリッジである。

画像バス３０９には以下のデバイスが配置される。ラスターイメージプロセッサ（ＲＩＰ）３１０は、ネットワークから送信されて来たＰＤＬコードをビットマップイメージに展開する。デバイスＩ／Ｆ部３１１は、画像入出力デバイスであるスキャナ２０１やプリンタエンジン１０３とプリンタコントローラ１０２とを接続し、画像データの同期系／非同期系の変換を行う。

スキャナ画像処理部３１２は、入力画像データに対し補正、加工、編集を行う。プリンタ画像処理部３１３は、プリント出力画像データに対して、プリンタの補正、解像度変換等を行う。画像回転部３１４は画像データの回転を行う。画像圧縮部３１５は、多値画像データに対してはＪＰＥＧ圧縮伸張処理を行い、２値画像データに対してはＪＢＩＧ、ＭＭＲ、ＭＨ等の圧縮伸張処理を行う。

以上のような構成の本実施形態の画像形成装置は、クライアントインターフェース（例えば、Ethernet（登録商標）等の相互通信可能なネットワークインターフェース）３０８を介して互いに接続され、グリッドコンピューティングによる負荷分散処理を行なうコンピュータシステムとして動作する。

（処理ノードの選択方法）
第１の実施形態のコンピュータシステムは、以上のような構成の画像処理装置で構成されており、グリッドコンピューティングを利用して負荷分散処理を依頼する管理ノードは、処理ノード状態データベースに予め登録されている他の画像処理装置の情報や状態に基づいて、負荷分散処理の対象とする処理ノードを選択する。

図５は、本実施形態の構成と処理の順序を概略的に示すブロック図である。図中、５０１は管理ノード、５０２ａ〜ｄは４つの処理ノード１〜４をそれぞれ表している。また、５０３は処理ノードデータベース（ＤＢ）であり、５０３ａ及び５０３ｂは、各状態における処理ノード状態データベース５０３に格納された情報の例を表している。

この処理ノード状態ＤＢは、本実施形態ではグリッドを構成する画像処理装置のいずれか１つに設けられているが、別途独立したコンピュータ装置内に設けられていても良い。

本実施形態では、図中（１）〜（４）で示した処理フローに従って、処理ノード状態ＤＢ５０３の情報に基づいた処理ノードの選択処理が実行される。

（１）管理ノード５０１は、処理ノード状態ＤＢ５０３の各処理ノードが使用可能な状態であるか否かの情報（状態情報とも呼ぶ）を管理する。すなわち、ジョブを依頼する前及び処理結果を受信した後に各処理ノードの状態情報を処理ノード状態ＤＢ５０３に書き込む。５０３ａは、システムのセットアップ後ジョブを依頼する前の処理ノード５０１ａ〜ｄの状態情報の例を示している。処理ノード１〜４の状態情報は全て「未確認」となっている。

管理ノード５０１は、予め用意してある処理結果が既知のテスト用の処理を、状態情報が「未確認」となっている処理ノード５０１ａ〜ｄそれぞれに依頼する。ここでは通常の分散処理とは異なり、テストをするためであるため、各処理ノードに送られるテスト用の処理は全て同一の処理である。この場合には４つの処理ノード全てにテスト処理を依頼することになる。このテスト処理は、例えば、処理単位となるデータを含むもので、各処理ノードで短時間に処理できる程度のものであり、負荷を増大させるものではない。

該テスト処理に対しては、負荷分散処理の対象とするか否かの判断基準となる処理結果（以下、単に「基準」とも呼ぶ）も用意しておく。例えば、管理ノード５０１で予めテスト処理を実行して得られた結果をこの基準として用いても良い。

（２）各処理ノード５０２ａ〜ｄは、テスト用の処理を受け取ると処理を施し、処理結果を管理ノード５０１に送信する。

（３）管理ノード５０１は、各処理ノードからの処理結果を受信した後、それぞれを基準と比較し、同じ処理結果を返してきた処理ノードの状態情報を「使用可」に、基準と異なる処理結果を返してきた処理ノードの状態情報を「使用不可」となるように、処理ノード状態ＤＢ５０３の内容を更新する。

本例では、処理ノード３から受信した処理結果が基準と異なっており、処理ノード１、２、４から受信した処理結果は基準と同じであると想定する。この場合、処理ノード状態ＤＢ５０３の状態情報を５０３ｂに示すように、処理ノード３の状態情報を「使用不可」に、その他の処理ノードの状態情報を「使用可」に変更する。

（４）管理ノード５０１は、グリッドによってジョブを分散処理する際に、処理ノード状態ＤＢ５０３を参照し、状態情報が「使用可」となっている処理ノード（５０２ａ、５０２ｂ、５０２ｄ）を選択して、分散処理を依頼する。

具体的な例を挙げて説明する。処理ノード１、２、３は、機種ＡのＭＦＰであり、処理ノード４は、機種ＢのＭＦＰであったとする。依頼する処理の種類は色処理であり、各処理ノードには色処理用のソフトウェアがそれぞれ実装されていることとする。処理ノード３のＭＦＰは機種Ａであるが、導入時期が処理ノード１及び２のＭＦＰに比べ早かったため、色処理ソフトウェアのバージョンがＣであり、処理ノード１、２、４のＭＦＰは、実装されている色処理ソフトウェアのバージョンがＤであったとする。処理ノード４のＭＦＰは、機種Ｂであり、その他の処理ノードと機種が異なる。

このような場合、ＭＦＰの構成としては、ハードウエアリソース、ソフトウエアリソースとも機種だけに依存せず、共通設計（プラットフォーム）として異なる機種にも同じリソースが導入されている場合も多く考えられる。また、機種が同じであっても、マイナーチェンジ等で、ソフトウェアのバージョンが異なる場合があり、ソフトウェアのバージョンＵＰを行っているか否かによっても処理結果が変わってしまう場合もある。あるいは、ソフトウェアやハードウェアのバージョンが違っていても、依頼するジョブの内容によっては処理結果が同じとなる場合も考えられる。このように機種名やソフトウエアリソース、ハードウエアリソースのバージョン等の情報だけでは、処理結果が同じとなるかどうかを判断できないケースが多々考えられる。

本実施形態では、依頼するジョブと同様な処理を含むテスト処理を各処理ノードで実行させ、その処理結果が基準となる処理結果と同じであった処理ノードを選択することにより、処理結果に対する信頼性を向上させている。更に、実際には分散処理の対象としても問題ない処理ノードを、機種名やリソースの情報に基づいて処理対象から除外することが防止されるので、分散処理システムの効率を向上させることが可能となる。

上記の例では、処理ノード３は、使用する色処理のソフトウェアのバージョンが違うために処理結果が他の処理ノードと異なるため、分散処理の対象から除外される。このため、分散処理によって得られる結果の信頼性が向上している。

機種名だけに基づいて分散処理の対象となる処理ノードを選択する場合では、処理ノード４が分散処理の対象から除外されてしまうが、本実施形態ではこのようなことを防ぐことが可能となっている。例えば、３ページある色変換ジョブを分散処理する場合、機種名に基づいて処理ノードを選択すると、処理ノード１〜３に各ページの色変換処理を依頼することとなるが、この場合、処理ノード３によって処理されたページだけ色味が異なってしまう。これに対して本実施形態では、処理ノード３は分散処理の対象から除外され、代わりに処理ノード４が分散処理の対象となるため、３ページとも同じ色味のページとなる。

なお、本実施形態に係るグリッドの構成としては、上述のように管理ノードとなる画像処理装置が所定の１台だけであってもよいし、各画像処理装置が、分散処理を依頼する管理ノードとしても動作可能であり、かつ分散処理を受信して処理を施して結果を返す処理ノードとしても動作可能で、システム全体の状態に応じて動的に管理ノードが切り替わるような構成であってもよい。

また、上記実施形態においては、テスト処理の結果が基準となる処理結果と同じである処理ノードを、分散処理の対象とするが、分散処理を行うジョブの種類や内容（ジョブに含まれる処理）、あるいは分散処理を依頼するユーザによって、基準となる処理結果との同一性をそれほど要求されない場合もある。

このような場合には、例えば、基準となる処理結果との誤差やずれが所定範囲内、あるいは処理結果の精度や仕様が基準となる処理結果以上である処理ノードの状態情報を「使用可」として、分散処理の対象として選択するようにすればよい。

＜第２の実施の形態＞
以下、本発明に係る第２の実施形態について説明する。第２の実施形態も第１の実施形態と同様な複数の画像形成装置で構成されるコンピュータシステムであり、以下では上記第１の実施形態と同様な部分については説明を省略し、第２の実施形態の特徴的な部分を中心に説明する。

本実施形態のシステムでは、グリッドコンピューティングにおいて、１台の画像処理装置が分散処理を依頼する管理ノード及び分散処理を実行する処理ノードとして動作し、他の画像処理装置は分散処理を実行する処理ノードとして動作する。すなわち、管理ノード及び処理ノードとして動作する１台の画像処理装置には、ＴＭ及びＤＪＳ並びにブローカ及びＲＭがインストールされており、処理ノードとして動作する他の画像処理装置には、ブローカ及びＲＭがインストールされている。

図６は、本実施形態の構成と処理の順序を図５と同様に示すブロック図である。図中６０１は、管理ノードであると同時に分散処理の対象となる処理ノードも兼ね、処理ノード５とも呼ばれる。６０２ａ〜ｄは、処理ノード１、２、３、４をそれぞれを表している。６０３は処理ノードデータベース（ＤＢ）であり、６０３ａ及び６０３ｂは、各状態における処理ノード状態データベース６０３に格納された情報の例を表している。

第１の実施形態と本実施形態とで大きく異なる点としては、本実施形態では、各処理ノードに実行させるテスト用の処理として、結果が未知である処理を用い、各処理ノードから受信した処理結果の比較に基づいて、分散処理の対象とする処理ノードを選択する点である。

本実施形態では、図中（１）〜（４）で示した処理フローに従って、処理ノード状態ＤＢ６０３の情報に基づいた処理ノードの選択処理が実行される。

（１）管理ノード６０１は、処理ノード状態ＤＢ６０３の各処理ノードの状態情報を管理する。すなわち、ジョブを依頼する前及び処理結果を受信した後に、各処理ノードの状態情報を書き込む。６０３ａは、システムのセットアップ後ジョブを依頼する前の処理ノード１〜５の状態情報の例を示している。処理ノード１〜５の状態情報は全て「未確認」となっている。

管理ノード６０１は、予め用意してある処理結果が未知のテスト用の処理を、状態情報が「未確認」となっている処理ノード１〜５のそれぞれに依頼する。ここでは通常の分散処理依頼とは異なり、テストをするためであるため、各処理ノードに送られるテスト用の処理は全て同一の処理である。本実施形態では管理ノード６０１自体も処理ノードを兼ねるので、処理ノード５を加えた５つの処理ノード全てに処理を依頼することになる。

（２）各処理ノード１〜５は、テスト用の処理を受け取ると処理を施し、処理結果を該管理ノード６０１に送信する。

（３）管理ノード６０１は、各処理ノードからの処理結果を受信した後、各処理ノードから送信された処理結果同士を比較し、同じ処理結果を返してきた処理ノードについて、同じステータスを処理ノード状態ＤＢ６０３の状態情報に書き込む。

本例では、処理ノード１、２、４から受信した処理結果が同じ（第１の処理結果）であり、処理ノード３および４から受信した処理結果が同じ（第２の処理結果）であると想定する。この場合、処理ノード１、２、４の状態情報として「処理Ａ」を、処理ノード３及び５の状態情報として「処理Ｂ」を書き込んで処理ノード状態ＤＢを更新する。

（４）管理ノード６０１は、グリッドによってジョブを分散処理する際に、処理ノード状態ＤＢ６０３を参照し、同じ処理結果となった処理ノードの数が多いグループを分散処理の対象として選択し、投入されたジョブの分散処理を依頼する。

本例では、６０３ｂに示すように、状態情報が「処理Ａ」の処理ノードが３台、状態情報が「処理Ｂ」の処理ノードが２台である。よって、本例では、状態情報が「処理Ａ」の処理ノード１、２、４を分散処理の対象として選択し、分散処理を依頼することになる。ここで、処理ノード５はジョブを投入する管理ノード６０１自身でもあるが、この状態情報は「処理Ｂ」であるため、分散処理の対象として選択されない。これは分散処理の対象となる処理ノードの数が多いグループを選択することにより、分散処理の効率を向上させるためである。

ただし、管理ノード６０１自身も処理を行う方が都合のよいケースも考えられるため、単純に処理ノードの数が多いグループを選択するだけではなく、例えば、処理の内容に応じて、管理ノードと状態情報が同じ処理ノードのグループを分散処理の対象として選択するようにしてもよい。ここで重要なのは、処理結果が同じとなる処理ノードを分散処理の対象として選択するということである。

以上説明したように本実施形態によれば、結果が未知のテスト用の処理を各処理ノードに実行させ、同じ処理結果となった処理ノードが識別できるように処理ノード状態ＤＢに状態情報を書き込み、分散処理の対象としてテスト処理の結果が同じであった処理ノードのグループを選択することで、分散処理システムの信頼性並びに効率を向上させることができる。

＜第３の実施の形態＞
以下、本発明に係る第３の実施形態について説明する。第３の実施形態も第１及び第２の実施形態と同様な複数の画像形成装置で構成されるコンピュータシステムであり、以下では上記第１及び第２の実施形態と同様な部分については説明を省略し、第３の実施形態の特徴的な部分を中心に説明する。

本実施形態のシステムも第２の実施形態と同様に、グリッドコンピューティングにおいて、１台の画像処理装置が分散処理を依頼する管理ノード及び分散処理を実行する処理ノードとして動作し、他の画像処理装置は分散処理を実行する処理ノードとして動作する。

図７は、本実施形態の構成と処理の順序を図５及び図６と同様に示すブロック図である。図中７０１は、管理ノードであると同時に分散処理の対象となる処理ノードも兼ね、処理ノード５とも呼ばれる。７０２ａ〜ｄは、処理ノード１、２、３、４をそれぞれを表している。７０３は処理ノードデータベース（ＤＢ）であり、７０３ａ、７０３ｂ及び７０３ｃは、各状態における処理ノード状態データベース６０３に格納された情報の例を表している。

第１及び第２の実施形態と異なる特徴としては、処理ノード状態ＤＢ７０３が、状態情報として処理の種類に対応した複数の状態情報を格納している点である。以下の説明では、２つの状態情報を有する場合を例にあげて説明するが、状態情報の数は２つ以上であっても構わないし、後から、状態情報を追加するようにしてもよい。

本実施形態で用いるテスト用の処理としては、第１の実施形態のように処理結果が既知であってもよいし、第２の実施形態のように処理結果が未知であっても構わないが、以下の説明では、処理結果が未知である場合を例として説明する。

本実施形態では、図中（１）〜（７）で示した処理フローに従って、処理ノード状態ＤＢ７０３の情報に基づいた処理ノードの選択処理が実行される。

（１）管理ノード７０１は、処理ノード状態ＤＢ７０３の各処理ノードの状態情報をジョブの種類毎に管理する。すなわち、分散処理を行うジョブの種類が複数ある場合、各種類に対応したテスト処理を各処理ノードに実行させ、夫々のテスト処理の結果に基づいて状態情報を書き込む。以下の例では、処理ノード状態ＤＢ７０３が、ＰＤＬ用の色処理に対応したテスト処理である処理１と、コピー用の画像処理に対応したテスト処理である処理２とに対応した２種類の状態情報を有する場合について説明する。

７０３ａは、システムのセットアップ後ジョブを依頼する前の処理ノード１〜５の状態情報の例を示している。処理ノード１〜５の状態情報は処理１及び処理２の両方について全て「未確認」となっている。

管理ノード７０１は、予め用意してある処理結果が未知のテスト用の処理１を、対応する状態情報が「未確認」となっている処理ノード１〜５のそれぞれに依頼する。ここでは通常の分散処理依頼とは異なり、テストをするためであるため、各処理ノードに送られるテスト用の処理１は全て同一の処理である。本実施形態では管理ノード７０１自体も処理ノードを兼ねるので、処理ノード５を加えた５つの処理ノード全てに処理を依頼することになる。

（２）各処理ノード１〜５は、テスト用の処理１を受け取ると処理を施し、処理結果を管理ノード７０１に送信する。

（３）管理ノード７０１は、各処理ノードからの処理結果を受信した後、各処理ノードから送信された処理１の処理結果同士を比較し、同じ処理結果を返してきた処理ノードについて、同じステータスを処理ノード状態ＤＢ７０３の処理１に対応した状態１の欄の状態情報に書き込む。

本例では、処理ノード１、２、４から受信した処理結果が同じ（第１の処理結果）であり、処理ノード３および４から受信した処理結果が同じ（第２の処理結果）であると想定する。この場合、処理ノード１、２、４の状態１の状態情報として「処理Ａ」を、処理ノード３及び５の状態１の状態情報として「処理Ｂ」を書き込んで処理ノード状態ＤＢを更新する。このようにして状態１の欄が更新された状態を７０３ｂに示す。

（４）次に、管理ノード７０１は、状態２の状態情報の欄が「未確認」となっている処理ノードに対して、予め用意してある処理結果が未知のテスト用の処理２を処理ノード１〜５のそれぞれに依頼する。ここでも通常の分散処理依頼とは異なり、テストをするためであるため、各処理ノードに送られるテスト用の処理は全て同一の処理である。本実施形態では管理ノード７０１が処理ノード５も兼ねるので、処理ノード５を加えた５つの処理ノード全てに処理２を依頼をすることになる。

（５）各処理ノードは、テスト用の処理２を受け取ると処理を施し、処理結果を管理ノード７０１に送信する。

（６）管理ノード７０１は、各処理ノードからの処理結果を受信した後、各処理ノードから送信された処理１の処理結果同士を比較し、同じ処理結果を返してきた処理ノードについて、同じステータスを処理ノード状態ＤＢ７０３の処理２に対応した状態２の欄の状態情報に書き込む。

本例では、処理ノード１、２、５から受信した処理結果が同じ（第１の処理結果）であり、処理ノード３及び４から受信した処理結果がそれぞれ異なっている（それぞれ第２のの処理結果及び第３の処理結果）と想定する。この場合、処理ノード状態ＤＢの状態２の欄の処理ノード１、２、５に対応する部分に「処理Ａ」を、処理ノード３に対応する部分に「処理Ｂ」を、処理ノード４に対応する部分に「処理Ｃ」を書き込んで処理ノード状態ＤＢ７０３を更新する。このようにして状態２の欄が更新された状態を７０３ｃに示す。

なお、ここで状態２の欄に書き込む「処理Ａ」、「処理Ｂ」、「処理Ｃ」は、あくまでも状態２に対しての処理結果を識別するための表現（符号）であり、状態１の欄の状態情報である、「処理Ａ」、「処理Ｂ」とは異なるものであることに注意されたい。

（７）管理ノード７０１は、グリッドによってジョブを分散処理する際に、処理ノード状態ＤＢ６０３を参照し、そのジョブと同様なテスト処理に関して同じ処理結果となった処理ノードの数が多いグループを分散処理の対象として選択し、投入されたジョブの分散処理を依頼する。

例えば、ジョブが処理１と同様なＰＤＬ用の色処理であるとき、処理速度（効率）を優先させる場合には、処理ノード１、２、４にジョブを分散させて処理を依頼する。また、管理ノードと同じ処理結果を所望する場合には、処理ノード５、３にジョブを分散させて処理を依頼してもよい。

一方、ジョブが処理２と同様なコピー用の画像処理であるときには、処理結果が同じ処理ノード１、２、５にジョブを分散させて処理を依頼する。この場合、他の処理ノードを処理結果が異なる処理ノード３、４を除外して分散処理を依頼することにより、処理結果に信頼性を持たせることができる。

以上説明したように本実施形態によれば、複数の異なる処理に対応したテストを各処理ノードに実行させ、処理ノード状態ＤＢにもそれぞれのテストの結果に基づいた状態情報を格納するようにしたため、分散処理を行うジョブの種類に応じて適切な処理ノードを選択することができるため、分散処理システムの信頼性並びに効率を向上させることが可能となる。

＜変形例１＞
上記第１から第３の実施形態では、実際に分散処理を依頼するジョブとは別個にテスト処理を各処理ノードに依頼するものであるが、分散処理を依頼するジョブの中にテスト処理を含めるようにしてもよい。

この場合、システム内の全ての処理ノードが分散処理の対象となるが、得られた処理結果を採用するか否かは、テスト処理の結果に基づいて決定される。同時にテスト処理の結果に対応した状態情報は処理ノード状態ＤＢに格納される。処理結果を採用しないと決定された処理ノードに依頼された処理は、処理結果を採用すると決定された別の処理ノードに再度依頼されるように構成する。

なお、このようなシステム内の全ての処理ノードを対象とした分散処理は、全てのジョブについて実行するのではなく、所定期間が経過する度に行われるようにしても良い。

このようにすると、処理ノード状態ＤＢの状態情報を更新した後に、処理ノードに対して状態情報が異なるような作業、例えばソフトウェアやファームウェアのバージョンアップが行われた場合においても、分散処理システムの信頼性並びに効率を向上させることが可能となる。

＜変形例２＞
上記第１から第３の実施形態では、テスト処理の結果に基づいて処理ノード状態ＤＢの状態情報を書き込んだ後には、状態情報をに応じてジョブの分散処理の対象となる処理ノードを選択する。

上記の実施形態では、状態情報の更新について特に説明していないが、処理ノードに対して状態情報が異なるような作業、例えばソフトウェアやファームウェアのバージョンアップが行われた場合には、状態情報の更新が必要となる。

このような状態情報の更新は、例えば、所定期間毎に上記実施形態のテスト処理を自動的に行うようにすればよい。

このようにすると、例えばソフトウェアやファームウェアのバージョンアップが行われた場合においても、実際のジョブの依頼時の負荷を増やさずに、分散処理システムの信頼性並びに効率を向上させることが可能となる。

＜他の実施形態＞
以上述べた実施形態では、グリッド用の制御プログラムを画像形成装置にもたせた構成を例にあげて説明したが、グリッド構成する要素はそれぞれ独立させてサーバや他のＰＣに持たせた構成としても良い。

また、上記の実施形態はグリッドコンピューティング技術を使った例であるが、例えばＭＦＰへＬＡＮ経由で接続したＰＣからのサービスソフトの実施や、ファームウェアのダウンロードなど、他の機器から依頼された処理をバックグランドで実行する場合など、ネットワークで接続された他の装置から依頼された処理を実行可能に構成された装置であれば、本発明は同様に適用できる。

本発明は、複数の機器から構成されるグリッドコンピューティングシステム（グリッド網）に適用しても良いし、また、グリッド網を構成する一つの機器に適用しても良い。

なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラム（本実施形態では図５から図７に示す処理フローに対応したプログラム）を、システム或いは装置に直接或いは遠隔から供給し、そのシステム或いは装置のコンピュータが該供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。その場合、プログラムの機能を有していれば、形態は、プログラムである必要はない。

従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明のクレームでは、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。

その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。

プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などがある。

その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、該ホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明の範囲に含まれるものである。

また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。

また、コンピュータ（情報処理装置）が、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現され得る。

さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現される。

グリッドコンピューティングの基本的構成を示す図である。 グリッドコンピューティングをプリンタのＰＤＬ処理に適用する場合の例を示す図である。 本発明に係る画像形成装置の概観を示す図である。 図３の画像形成装置の制御構成を示すブロック図である。 第１の実施形態の構成と処理の順序を概略的に示すブロック図である。 第２の実施形態の構成と処理の順序を概略的に示すブロック図である。 第３の実施形態の構成と処理の順序を概略的に示すブロック図である。

Claims (6)

1. ジョブの分散処理を依頼する管理ノードと、各々が依頼された分散処理を実行して前記管理ノードに処理結果を送信する複数の処理ノードとを含む情報処理システムであって、
   前記管理ノードは、
   ジョブの種類が互いに異なる第１及び第２のテスト処理に対する処理結果を前記複数の処理ノードの各々から受信し、該複数の処理ノードの各々の状態情報としてジョブの種類毎に管理し、該状態情報に基づいて、前記複数の処理ノードの内、前記第１のテスト処理の処理結果が同じ１以上の処理ノード同士を１つのグループとし、前記第２のテスト処理の処理結果が同じ１以上の処理ノード同士を１つのグループとする、グループ化手段と、
   要求ジョブを分散処理する際に、該要求ジョブのジョブの種類と前記第１のテスト処理のジョブの種類とが同じである場合は、前記第１のテスト処理の結果に基づきグループ化されたグループの内、相対的に処理ノードを多く含むグループに対し前記要求ジョブのジョブ処理を依頼し、該要求ジョブのジョブの種類と前記第２のテスト処理のジョブの種類とが同じである場合は、前記第２のテスト処理の結果に基づきグループ化されたグループの内、相対的に処理ノードを多く含むグループに対し前記要求ジョブのジョブ処理を依頼する、依頼手段と、
   を有することを特徴とする情報処理システム。
2. 前記管理ノードは、前記処理ノードの機能を併せて有しており、
   前記グループ化手段は、前記複数の処理ノードの各々から受信した前記第１及び第２のテスト処理に対する処理結果と、前記管理ノード自身が処理した前記第１及び第２のテスト処理に対する処理結果とに基づいて、前記管理ノード及び前記複数の処理ノードの内、前記第１のテスト処理の処理結果が同じ１以上の処理ノード同士を１つのグループとし、前記第２のテスト処理の処理結果が同じ１以上の処理ノード同士を１つのグループとすることを特徴とする請求項１に記載の情報処理システム。
3. 前記依頼手段は、処理速度を優先する場合は、ノードを最も多く含むグループに対しジョブ処理を依頼し、前記管理ノードにおける分散処理の処理結果と同じ処理結果を所望する場合は、前記管理ノードにおけるテスト処理の処理結果と同じ処理結果であるグループに対し分散処理を依頼することを特徴とする請求項２に記載の情報処理システム。
4. 前記グループ化手段は、実行している分散処理ソフトウェアのバージョンの同じ処理ノードが同一のグループに含まれるように前記複数の処理ノードをグループ化することを特徴とする請求項１乃至３のいずれか１項に記載の情報処理システム。
5. 前記管理ノードおよび前記複数の処理ノードは情報処理装置がソフトウェアを実行することにより実現されることを特徴とする請求項１乃至４の何れか１項に記載の情報処理システム。
6. ジョブの分散処理を依頼する管理ノードと、各々が依頼された分散処理を実行して前記管理ノードに処理結果を送信する複数の処理ノードを含む情報処理システムにおけるジョブ割り当て方法であって、
   前記管理ノードが有するグループ化手段が、ジョブの種類が互いに異なる第１及び第２のテスト処理に対する処理結果を前記複数の処理ノードの各々から受信し、該複数の処理ノードの各々の状態情報としてジョブの種類毎に管理し、該状態情報に基づいて、前記複数の処理ノードの内、前記第１のテスト処理の処理結果が同じ１以上の処理ノード同士を１つのグループとし、前記第２のテスト処理の処理結果が同じ１以上の処理ノード同士を１つのグループとする、グループ化工程と、
   前記管理ノードが有する依頼手段が、要求ジョブを分散処理する際に、該要求ジョブのジョブの種類と前記第１のテスト処理のジョブの種類とが同じである場合は、前記第１のテスト処理の結果に基づきグループ化されたグループの内、相対的に処理ノードを多く含むグループに対し前記要求ジョブのジョブ処理を依頼し、該要求ジョブのジョブの種類と前記第２のテスト処理のジョブの種類とが同じである場合は、前記第２のテスト処理の結果に基づきグループ化されたグループの内、相対的に処理ノードを多く含むグループに対し前記要求ジョブのジョブ処理を依頼する、依頼工程と、
   を有することを特徴とするジョブ割り当て方法。

Images