JP2015005041A - 情報処理システム、ソフトウェア更新方法およびプログラム - Google Patents

Abstract

【課題】ソフトウェア更新を行うための情報処理システム等を提供する。
【解決手段】情報処理システムは、複数の演算処理装置と、出力処理を行う１以上の出力装置とを含む。複数の演算処理装置としては、複数の処理実行装置１５０，１７０に対しソフトウェアの更新を指令する更新指令手段１１８と、管理対象として登録するよう要求してきた処理実行装置１５０，１７０を管理する管理手段１２２と、管理対象として登録された処理実行装置を用いた並列処理を制御する並列処理制御手段１２４とを含む管理装置１１０が含まれる。さらに、管理装置からの指令に応答してソフトウェアの更新を実行する更新処理手段１５６，１７６と、管理装置に対し管理対象として登録するよう求める要求を行う登録要求手段１５８，１７８と、出力処理のための処理を実行する処理手段１６０，１７６とを含む処理実行装置１５０，１７０が含まれる。
【選択図】図２

Description

本発明は、ソフトウェア更新に関し、より詳細には、ソフトウェア更新を行うための情報処理システム、ソフトウェア更新方法およびプログラムに関する。

従来、複数のコンピューティング・ノード（プロセッサおよびメモリなどを含み構成される。）でＲＩＰ処理を並列に実行し、並列して処理された処理結果に基づいてプリンタから高速に印刷出力を行う、印刷システムが知られている。このような印刷システムとしては、複数のスレーブノードの全体制御を行うマスタノードと、該マスタノードからの指示に応答して各種処理を実行する各々のスレーブノードとを含み構成されたマスタ−スレーブ方式のものが知られている。

近年、ソフトウェアや機器に対する多機能化の要求に伴い、アプリケーション・プログラム、ファームウェアなどのソフトウェアが複雑化し、不具合の修正や新たな機能の追加などのソフトウェア更新が頻繁に行われている（特許文献１：特許第５０８０３１８号公報）。上述した並列処理を行う印刷システムにおいても、ファームウェアなどのソフトウェア更新が行われるところ、かかる場合には、整合性を維持した状態で複数のノードに適切に更新を適用する必要がある。

従来、情報処理システムのソフトウェア更新に関して、種々の技術が知られている。例えば、特許第４０５４８０２号公報（特許文献２）は、マルチＣＰＵ構成の情報処理システムにおけるプログラム更新方法を開示する。特許文献２の従来技術では、データ処理装置が、プログラム更新用データを受信し、受信されたプログラム更新用データのヘッダを復号及び認証してプログラムの供給先のＣＰＵを特定し、特定されたＣＰＵに暗号化されたプログラムを供給する。各サブＣＰＵへのプログラム更新ファイルの提供およびプログラム更新の開始指示は、コントローラＣＰＵが主導となって行っている。そして、各サブＣＰＵを識別するＣＰＵ番号が、起動時の設定としてコントローラＣＰＵに対し事前に静的に設定される。

しかしながら、上述した従来技術では、すべてのサブＣＰＵのプログラム更新の完了を待ってシステムが再開される。つまり、システムの再開がすべてのサブＣＰＵの更新完了を前提としているため、プログラム更新中にいずれかのサブＣＰＵが故障した場合には、システムの自動復旧ができず、システムが再開できなくなるという点で充分なものではなかった。この場合、復旧不能な故障が発生したサブＣＰＵを管理者が手動で交換するまで、システムの再開は遅延させられる。

本発明は、上記従来技術における不充分な点に鑑みてなされたものであり、本発明は、複数の演算処理装置を含み構成される情報処理システムにおいて、複数の演算処理装置に対するソフトウェア更新中にいずれかの演算処理装置に障害が発生したとしても、復旧されない演算処理装置を除外してシステムを再始動させることができる、情報処理システム、ソフトウェア更新方法およびプログラムを提供することを目的とする。

本発明は、上記課題を解決するために、複数の演算処理装置と、この複数の演算処理装置で行われた処理結果に基づいて出力処理を行う１以上の出力装置とを含む情報処理システムであって、下記特徴を有する情報処理システムを提供する。本情報処理システムにおいて、上記複数の演算処理装置としては、複数の処理実行装置に対しソフトウェアの更新を指令する更新指令手段と、管理対象として登録するよう要求してきた処理実行装置を管理する管理手段と、管理対象として登録された処理実行装置を用いた並列処理を制御する並列処理制御手段とを含む管理装置が含まれる。上記複数の演算処理装置としては、さらに、上記管理装置からの指令に応答してソフトウェアの更新を実行する更新処理手段と、上記管理装置に対し管理対象として登録するよう求める要求を行う登録要求手段と、出力処理のための処理を実行する処理手段とをそれぞれが含む複数の処理実行装置が含まれる。

上記構成によれば、複数の演算処理装置を含み構成される情報処理システムにおいて、複数の演算処理装置に対するソフトウェア更新中にいずれかの演算処理装置に障害が発生したとしても、復旧されない演算処理装置を除外してシステムを再始動させることができる。

本実施形態による連続帳票印刷システムの全体構成図。 本実施形態による連続帳票印刷システムの機能ブロック図。 本実施形態において各スレーブノードの版情報を管理する版管理テーブルのデータ構造を例示する図。 本実施形態によるヘッドノードが実行する、ファームウェア更新の全体制御を示すフローチャート。 本実施形態によるスレーブノードが実行する、各スレーブノード側のファームウェア更新処理を示すフローチャート。 本実施形態において、スレーブノードに更新中なんら問題が生じない場合のヘッドノードおよびスレーブノードの動作を示すシーケンス図。 本実施形態において、スレーブノード２で故障が生じた場合のＲＩＰサーバのヘッドノードおよびスレーブノードの動作を示すシーケンス図。 本実施形態において、スレーブノード２の更新完了前に電源断が発生した場合のＲＩＰサーバのヘッドノードおよびスレーブノードの動作を示すシーケンス図。 本実施形態によるＲＩＰサーバのハードウェア構成図。

以下、本発明の実施形態について説明するが、本実施形態は、以下に説明する実施形態に限定されるものではない。なお、以下、複数の演算処理装置（管理装置および処理実行装置（画像処理装置および終端処理装置を含む。）を含む。）と、１以上の出力装置とを含む情報処理システムについて、複数のコンピューティング・ノード（ヘッドノードおよびスレーブノード（計算ノードおよび終端ノードを含む。）を含む。）と、複数のプリンタとを含む連続帳票印刷システムを一例として参照しながら説明する。

図１は、本実施形態による連続帳票印刷システム１００の全体構成を示す図である。図１に示す連続帳票印刷システム１００は、ネットワーク１０２に接続されるＲＩＰ（Raster Image Processer）サーバ１０４と、このＲＩＰサーバ１０４に接続される２台のプリンタ１９０−１，１９０−２とを含み構成される。ＲＩＰサーバ１０４は、ＲＩＰ処理と、プリンタ制御とを実行するサーバであり、２台のプリンタ１９０−１，１９０−２は、それぞれ、ＲＩＰサーバ１０４で行われた処理結果に基づき印刷出力を実行する。

上記ネットワーク１０２は、特に限定されるものではないが、イーサネット（登録商標）などのＬＡＮ（Local Area Network）であり、ネットワーク１０２に接続されたユーザ端末からのジョブをＲＩＰサーバ１０４に伝達する。

ＲＩＰサーバ１０４は、ユーザ端末からネットワーク１０２を介してジョブを受信し、受信したジョブに基づくＲＩＰ処理を実施し、２台のプリンタ１９０−１，１９０−２を制御して印刷出力させる。このように、ＲＩＰサーバ１０４は、２台のプリンタ１９０−１，１９０−２と、ネットワーク１０２とに接続されている。なお、以下、ジョブは、ネットワーク１０２を介してＲＩＰサーバ１０４に伝達されるものとして説明するが、特に限定されるものではない。例えば、ＲＩＰサーバ１０４に接続されたフラッシュメモリや、ＲＩＰサーバ１０４が備えるストレージから読み出されてもよい。

図１に示す２台のプリンタ１９０−１，１９０−２は、それぞれ、ロール紙などの転写部材に対し印刷出力を実行する連続帳票プリンタとして構成されている。プリンタ１９０は、それぞれ、インクジェット方式、電子写真方式などの印刷方式のプリンタヘッドを備える。特に限定されるものではないが、説明する実施形態では、一方のプリンタ１９０−１は、転写部材の表面の印刷出力を担当し、他方のプリンタ１９０−２は、裏面の印刷出力を担当している。２台のプリンタ１９０−１，１９０−２で使用される転写部材は、繋がっており、第１プリンタ１９０−１で表面が印刷された後、第２プリンタ１９０−２で裏面が印刷される。これにより、両面に画像が形成された印刷物が得られる。プリンタ１９０−１およびプリンタ１９０−２は、それ自身で印刷制御を行っておらず、ＲＩＰサーバ１０４によって制御されている。

図１に示すＲＩＰサーバ１０４は、複数のコンピューティング・ノードを含み構成されている。より詳細には、ＲＩＰサーバ１０４は、ヘッドノード１１０と、複数の計算ノード１５０−１〜１５０−１２と、２個の終端ノード１７０−１，１７０−２とを含む。なお、図１には、１２個の計算ノードが示されているが、システムに組み込むことができる計算ノードの数に特に制限はない。また、図１には、デュアル・エンジン・デュプレックス構成が示されており、２台のプリンタに対応させて２個の終端ノードが示されている。しかしながら、プリンタの台数および終端ノードの個数は、特に限定されるものではなく、終端ノードの個数は、典型的には、プリンタの台数と等しくすることができる。

ヘッドノード１１０は、プロセッサ、メモリおよびストレージを含む汎用コンピュータとして構成することができる。計算ノード１５０および終端ノード１７０も、同様に、プロセッサおよびメモリを含む汎用コンピュータとして構成することができる。典型的には、ヘッドノード１１０、計算ノード１５０および終端ノード１７０は、それぞれ、サーバブレードにより構成され、これらのサーバブレードが、エンクロージャ（筐体）のブレードベイに装着されて、上記ＲＩＰサーバ１０４が構成されている。ヘッドノード１１０、計算ノード１５０および終端ノード１７０は、例えば、イーサネット（登録商標）のクロスバー・スイッチで接続されている。

ヘッドノード１１０は、計算ノード１５０および終端ノード１７０を制御するマスタノードであり、これに対し、計算ノード１５０および終端ノード１７０は、マスタのヘッドノード１１０の制御の下で動作するスレーブノードである。

ヘッドノード１１０は、受信したジョブを分割して、分割されたジョブ・チャンクを計算ノード１５０に割り当てる。ジョブは、説明する実施形態では、ページ毎に分割され、ジョブ・チャンクは、全体のジョブを構成するページ単位のジョブをいうものとする。計算ノード１５０は、それぞれ、割り当てられたジョブ・チャンクに基づきページ毎のＲＩＰを並列に実行し、ＲＩＰ済み画像データを生成する。計算ノード１５０は、ＲＩＰの後、ヘッドノード１１０の制御の下、ＲＩＰ済み画像データを終端ノード１７０へ送信する。

なお、説明する実施形態では、複数の計算ノード１５０によりページ毎に並列にＲＩＰが行われるものとして説明するが、ＲＩＰ演算の分割方法は特に限定されるものではない。他の実施形態では、各ページについて、さらに、ＲＩＰ演算を構成するインタープリット、レンダリング、スクリーニング、各種補正処理などを別々の計算ノードでさらに並列処理されるように構成されてもよい。

終端ノード１７０は、ヘッドノード１１０の制御の下、計算ノード１５０からＲＩＰ済み画像データを受信する。終端ノード１７０は、それぞれ、ファイバチャネルなどを介して、対応するプリンタ１９０と接続されており、ヘッドノード１１０の制御の下、さらに、この対応するプリンタ１９０にＲＩＰ済み画像データを転送する。説明する実施形態では、終端ノード１７０は、対応付けられるプリンタ１９０との接続を集約している。

プリンタ１９０−１，１９０−２は、それぞれ、対応する終端ノード１７０−１，終端ノード１７０−２からＲＩＰ済み画像データを受信し、受信したデータに基づいて印刷出力を行う。なお、説明する実施形態において、プリンタ１９０−１，１９０−２は、計算ノード１５０−１〜１５０−１２との依存関係を有しておらず、計算ノード１５０−１〜１５０−１２のいずれで異常が生じた場合でも、影響を受けないように構成されている。

以下、図２を参照しながら、本実施形態による連続帳票印刷システム１００の機能構成について説明する。図２は、本実施形態による連続帳票印刷システム１００の機能ブロック図である。図２には、ヘッドノード１１０上の機能手段と、計算ノード１５０上の機能手段と、終端ノード１７０上の機能手段とが示されている。なお、これら各機能手段は、プロセッサが、ファームウェアなどのプログラムを読み出し、メモリ上に展開することにより、各ノード上で実現される。説明する実施形態は、このファームウェアのプログラムが、後述する更新対象となる。

まず、ファームウェア更新処理について説明する前に、連続帳票印刷システム１００における並列ＲＩＰに基づく印刷出力処理について概略を説明する。

図２に示すように、ヘッドノード１１０は、送信部１１２と、受信部１１４と、ノード管理部１２２と、並列ＲＩＰ制御部１２４とを含み構成される。計算ノード１５０は、送信部１５２と、受信部１５４と、登録要求発行部１５８と、ＲＩＰ処理部１６０とを含み構成される。終端ノード１７０は、送信部１７２と、受信部１７４と、登録要求発行部１７８と、転送処理部１８０とを含み構成される。

上述した送信部１１２，１５２，１７２および受信部１１４、１５４，１７４は、それぞれのノード１１０，１５０，１７０上で、他のノードやネットワーク１０２上のユーザ端末など外部装置とのネットワーク通信を行うための機能手段である。

ヘッドノード１１０の並列ＲＩＰ制御部１２４は、上述した複数のスレーブノード１５０−１〜１５０−１２，１７０−１，１７０−２を組み込んだ並列ＲＩＰ演算に基づく印刷出力処理を制御する並列処理制御手段である。計算ノード１５０各々のＲＩＰ処理部１６０は、ヘッドノード１１０の並列ＲＩＰ制御部１２４の制御の下、割り振られたジョブ・チャンクに基づきＲＩＰ演算を実行する印刷出力処理のための画像処理手段である。終端ノード１７０各々の転送処理部１８０は、ヘッドノード１１０の並列ＲＩＰ制御部１２４の制御の下、対応付けられるプリンタ１９０に対し、受信したＲＩＰ済み画像データを転送する印刷出力処理のための転送処理手段である。

ノード管理部１２２は、並列ＲＩＰ制御部１２４が並列ＲＩＰ演算に組み込むスレーブノード１５０，１７０を管理する。各スレーブノード１５０，１７０には、ノード識別子が割り振られており、ノード管理部１２２は、スレーブノードを特定するノード識別子をリストにして管理している。なお、説明する実施形態では、並列ＲＩＰ演算に組み込むスレーブノードは、ヘッドノード１１０側で静的に管理されてはおらず、スレーブノード側からの管理対象としての登録するよう求める要求（以下、管理対象登録要求と参照する。）を受けて、ヘッドノード１１０が動的に管理する。計算ノード１５０および終端ノード１７０の登録要求発行部１５８，１７８は、起動した後等のタイミングで、ヘッドノード１１０に対し、自身のノード識別子を付した管理対象登録要求を発行する。

図２に示すように、並列ＲＩＰ制御部１２４は、より詳細には、分割部１２６と、面付け部１２８と、割り当て部１３０と、ページ順序制御部１３２と、計算ノード制御部１３４と、終端ノード制御部１３６と、プリンタ制御部１３８とを含む。

並列ＲＩＰ制御部１２４は、ネットワーク１０２を介してユーザ端末からページ記述言語（ＰＤＬ：Page Description Language）のジョブを受信し、処理を開始する。分割部１２６は、受信したジョブが、ページ単位に分割されているかを判断し、分割されていない場合には、ジョブをページ毎のジョブ・チャンクに分割し、準備する。分割部１２６は、特に限定されるものではないが、対応しているページ記述言語毎に設けられてもよい。ジョブは、典型的には、ＰＤＦ（Portable Document Format）、ＰｏｓｔＳｃｔｉｐｔ、ＩＰＤＳ（Intelligent Printer Data Stream）などのフォーマットで記述される。

面付け部１２８は、ジョブに設定されている面付けの設定情報に基づいて、ページ分割されたジョブ・チャンクの画像が、出力転写部材の表面および裏面のいずれの出力セルに配置されるか面付けを決定する。割り当て部１３０は、ページ順序制御部１３２は、面付け結果を受けて、ジョブ・チャンクの処理順番を決定する。割り当て部１３０は、決定された処理順番に従って、計算ノード１５０−１〜１５０−１２のうちから、所定のジョブ・チャンクのＲＩＰ演算を実施させる計算ノードを割り当てる。

計算ノード制御部１３４は、計算ノード１５０を制御する制御手段であり、計算ノード１５０−１〜１５０−１２に対し、ＲＩＰ開始指令するとともに、計算ノード１５０−１〜１５０−１２からＲＩＰ終了通知を受け付ける。計算ノード１５０のＲＩＰ処理部１６０は、ヘッドノード１１０からジョブ・チャンクを受信し、ＲＩＰ開始指令に応答して、割り振られたジョブ・チャンクに基づきＲＩＰ演算を実行し、ＲＩＰ完了後、ＲＩＰ終了通知を返答する。ＲＩＰ演算によりラスタイメージが生成される。

計算ノード制御部１３４は、さらに、ＲＩＰ演算を完了させた計算ノード１５０−１〜１５０−１２に対し、適切な終端ノード１７０−１または終端ノード１７０−２へのＲＩＰ済み画像データの送信開始要求を発行する。並列ＲＩＰ制御部１２４は、計算ノード１５０−１〜１５０−１２のＲＩＰ進捗状況と、終端ノード１７０−１，１７０−２からそれぞれ対応するプリンタ１９０−１，１９０−２へのＲＩＰ済み画像データの送信進捗状況とを管理している。送信開始要求の発行の際は、これらの状況が判断される。計算ノード制御部１３４は、計算ノード１５０−１〜１５０−１２からＲＩＰ済み画像データの送信完了通知を受け付ける。計算ノード１５０のＲＩＰ処理部１６０は、送信開始要求の指令に応答して、ＲＩＰ済み画像データを所定の終端ノード１７０に送出し、送信が完了した後、送信完了通知を返答する。

終端ノード１７０の転送処理部１８０は、計算ノード１５０から、ＲＩＰ済み画像データ受信し、これを対応するプリンタ１９０に転送する。終端ノード制御部１３６は、終端ノード１７０を制御する制御手段であり、終端ノード１７０−１，１７０−２それぞれからプリンタ１９０−１，１９０−２への画像送信完了通知を受け付ける。終端ノード制御部１３６は、終端ノード１７０−１，１７０−２から印刷完了通知を受け付ける。終端ノード１７０は、対応するプリンタ１９０が印刷出力を完了させると、印刷完了通知を受信し、ヘッドノード１１０に印刷完了通知を行う。

プリンタ制御部１３８は、プリンタ１９０を制御する制御手段であり、計算ノード１５０のＲＩＰ進捗状況、終端ノード１７０のデータ転送の進捗状況などに基づいて、プリンタ１９０の動作を制御する。プリンタ制御部１３８は、プリンタ１９０のＪＡＭなどのエラーを管理する。

引き続き、本実施形態によるＲＩＰサーバ１０４におけるファームウェア更新処理について説明する。図２を参照すると、マスタとなるヘッドノード１１０は、さらに、ファームウェア格納部１１６と、更新制御部１１８と、更新処理部１２０とを含み構成される。スレーブとなる計算ノード１５０および終端ノード１７０は、さらに、更新処理部１５６，１７６を含み構成される。

ヘッドノード１１０のファームウェア格納部１１６は、ＲＩＰサーバ１０４全体のファームウェア更新ファイルを格納する。ファームウェア更新ファイルは、例えばネットワーク１０２を介してヘッドノード１１０へ提供される。あるいは、ＣＤ−ＲＯＭ（Compact Disk Read Only Memory）やＤＶＤなどの光学メディアやフラッシュメモリなどのリムーバブル・メディアを経由してヘッドノードへ提供されてもよい。ファームウェア格納部１１６は、ヘッドノード１１０の電源が切断されても記憶を維持できる不揮発な記憶領域により提供される。また、ここで管理されるファームウェア更新ファイルには、ヘッドノード１１０と、計算ノード１５０−１〜１５０−１２と、終端ノード１７０−１と、終端ノード１７０−２とに対するそれぞれの更新ファイルが含まれる。

更新制御部１１８は、計算ノード１５０−１〜１５０−１２および終端ノード１７０−１，１７０−２に対し、それぞれのためのファームウェア更新ファイルを送信するとともに、ファームウェア更新処理の開始を指令する。更新制御部１１８は、計算ノード１５０−１〜１５０−１２と、終端ノード１７０−１，１７０−２との全てに対しファームウェア更新処理の開始を指令した後、更新処理部１２０に対し、自分自身のファームウェア更新処理の開始を指令する。

上述した各ノードの更新処理部１２０，１５６，１７６は、それぞれのノード１１０，１５０，１７０上で、自身のファームウェアの更新処理を実行する処理手段である。更新処理部１２０は、ヘッドノード用のファームウェア更新ファイルを読み出し、自身のファームウェアの更新処理を実行する。計算ノード１５０および終端ノード１７０の更新処理部１５６，１７６は、ヘッドノード１１０から、ファームウェア更新処理の開始の指令を受け付けるとともに、自身用のファームウェア更新ファイルを受信する。更新処理部１５６，１７６は、ヘッドノード１１０からの指令に応答して、各スレーブノード１５０−１〜１５０−１２，１７０−１，１７０−２のそれぞれで個別にファームウェア更新処理を実行する。

各ノード１１０，１５０，１７０の更新処理では、典型的には、その処理過程において、一旦、各ノードの再起動が行われる。このとき、ヘッドノード１１０のノード管理部１２２が管理している管理対象のスレーブノードのノード識別子は、一旦クリアされることになる。

計算ノード１５０および終端ノード１７０の登録要求発行部１５８，１７８は、それぞれ、ファームウェア更新処理が完了し、正常に再起動した後、ヘッドノード１１０に対し、自身のノード識別子を付して管理対象登録要求を発行する。好適な実施形態では、自身のファームウェアの版情報（バージョンやタイムスタンプなど）を付して管理対象登録要求を発行することができる。なお、登録要求発行部１５８，１７８は、ファームウェアにより実現される。したがって、計算ノード１５０および終端ノード１７０用のファームウェアは、起動した後、ヘッドノード１１０へ管理対象登録要求を行うようコードされ、ＲＩＰ処理部１６０または転送処理部１８０として機能させるためのコードを含むといえる。

ノード管理部１２２は、自身のファームウェアの更新が完了し、正常に再起動した後、所定の制限時間、管理対象登録要求を受け付ける。ノード管理部１２２は、この所定の制限時間内に管理対象登録要求を送信してきた計算ノード１５０および終端ノード１７０のみを、ヘッドノード１１０の管理対象として動的に管理する。ノード管理部１２２は、制限時間が経過した後、これまで管理対象登録要求を受け付けたスレーブノードだけでシステムを再開させる。これにより、並列ＲＩＰ制御部１２４は、並列ＲＩＰに基づく印刷出力処理を実行可能とする。なお、上述した制限時間は、事前にシステム設定などとして設定することができる。

好適な実施形態では、更新制御部１１８は、更新指令を行ったスレーブノード１５０，１７０のファームウェア更新ファイルの版情報を管理している。図３は、各スレーブノードの版情報を管理する版管理テーブルのデータ構造を例示する図である。図３に示すように、版管理テーブルは、更新指令を行ったスレーブノードを識別するノード識別子と、そのスレーブノードの種類と、更新指令を行った際のファームウェアの版情報とを対応付けている。

更新制御部１１８は、管理対象登録要求が受信された際、ノード管理部１２２が要求元ノードの登録を行う前に、管理テーブルの該当ノード識別子に対応付けられる版情報と、管理対象登録要求に付された版情報とを比較し、整合しているか否かを確認する。ここで、更新制御部１１８が管理しているスレーブノードの版情報と、受信した版情報とに相違があれば、バージョン不整合であると判断される。その場合は、更新制御部１１８は、好適には、不整合が生じているスレーブノードに対し、最新のファームウェア更新ファイルを再送信し、ファームウェア更新の再試行を指令する。更新制御部１１８は、本実施形態における更新指令手段、確認手段および再試行手段を構成する。

以下、図４および図５を参照しながら、ＲＩＰサーバ１０４のファームウェア更新において、ヘッドノード１１０およびスレーブノード１５０，１７０が実行する処理について、より詳細に説明する。図４は、本実施形態によるヘッドノード１１０が実行する、ファームウェア更新の全体制御を示すフローチャートである。

図４に示す制御は、管理者から更新指示が行われるなど更新処理を開始する契機となるイベントが発生したことに応答して、ステップＳ１００から開始される。ステップＳ１０１では、ヘッドノード１１０は、ネットワーク１０２から受信し、またはメディアから読み出し、ファームウェア更新ファイルをファームウェア格納部１１６に準備する。ステップＳ１０２では、ヘッドノード１１０は、管理対象としてリストされたすべてのスレーブノード１５０，１７０に対し、ファームウェア更新開始指令を発行する。

ステップＳ１０３では、ヘッドノード１１０は、自身のファームウェア更新処理を開始する。ステップＳ１０４で、更新処理が完了すると（ＹＥＳ）、ステップＳ１０５へ制御が分岐される。ヘッドノード１１０は、ステップＳ１０５で、一旦自身をシャットダウンし、ステップＳ１０６で、再起動する。

ヘッドノード１１０は、再起動した後、ステップＳ１０７では、事前定義された制限時間が経過したか否かを判定する。ステップＳ１０７で、未だ制限時間が経過していないと判定された場合（ＮＯ）は、ステップＳ１０８へ制御が進められる。ステップＳ１０８では、ヘッドノード１１０は、いずれかのスレーブノードからの管理対象登録要求を受信したか否かを判定する。ステップＳ１０８で、いずれからも未だ要求を受信していないと判定された場合（ＮＯ）は、ステップＳ１０７へ制御をループさせ、管理対象登録要求を待ち受ける。

一方、ステップＳ１０８で、いずれかから管理対象登録要求を受信したと判定された場合（ＹＥＳ）は、ステップＳ１０９へ制御が分岐される。ステップＳ１０９では、ヘッドノード１１０は、管理対象登録要求に付されたノード識別子および版情報を取得し、取得したノード識別子に対応する版管理テーブルの版情報と、取得した版情報とを比較し、バージョンが整合しているか否かを判定する。

ステップＳ１０９で、バージョンが整合していると判定された場合（ＹＥＳ）は、ステップＳ１１０へ制御が分岐される。ステップＳ１１０では、ヘッドノード１１０は、管理対象登録要求に付された要求元ノードのノード識別子を管理対象のリストに登録する。ステップＳ１１１では、ヘッドノード１１０は、要求元のスレーブノードに対し、管理対象登録要求に対する肯定的な応答を行い、ステップＳ１０７へ制御をループさせる。一方、ステップＳ１０９で、バージョンが不整合であると判定された場合（ＮＯ）は、ステップＳ１１２へ制御が分岐される。ステップＳ１１２では、ヘッドノード１１０は、要求元のスレーブノードに対し、否定的な応答とともに、ファームウェア更新の再試行を指令し、ステップＳ１０７へ制御をループさせる。以降、制限時間が経過するまで、ステップＳ１０７〜ステップＳ１１２で示した処理が繰り返される。

再びステップＳ１０７を参照すると、ステップＳ１０７で、制限時間が経過したと判定された場合（ＹＥＳ）は、ステップＳ１１３へ制御が分岐される。ステップＳ１１３では、ヘッドノード１１０は、現時点で登録されたスレーブノードでのみでシステムを再開させる。これにより、ヘッドノード１１０は、並列ＲＩＰに基づく印刷出力処理が可能な状態となる。

図５は、本実施形態によるスレーブノードが実行する、各スレーブノード側のファームウェア更新処理を示すフローチャートである。なお、図５に示す処理は、計算ノード１５０および終端ノード１７０の両方が実行し得る処理である。

図５に示す処理は、ヘッドノード１１０からの更新指令を受信したことに応答して、ステップＳ２００から開始される。ステップＳ２０１では、スレーブノード１５０，１７０は、ヘッドノード１１０から、またはヘッドノード１１０により指定された保存場所（例えばＵＲＬで指定される。）から、自身のファームウェア更新ファイルを取得し、更新の準備を行う。ステップＳ２０２では、スレーブノード１５０，１７０は、自身のファームウェア更新処理を開始する。ステップＳ２０３で、更新処理が完了すると（ＹＥＳ）、ステップＳ２０４へ処理が分岐される。ヘッドノード１１０は、ステップＳ２０４で、シャットダウンし、ステップＳ２０５で、再起動する。

スレーブノード１５０，１７０は、再起動した後、ステップＳ２０６で、自身の初期化を行い、ステップＳ２０７で、ヘッドノード１１０に対し、管理対象登録要求を発行する。ステップＳ２０８では、スレーブノード１５０、１７０は、管理対象登録要求に対する応答を待ち受ける。ステップＳ２０８で、応答があれば、ステップＳ２０９へ処理が分岐される。

ステップＳ２０９では、スレーブノード１５０，１７０は、ファームウェア更新の再試行が求められているか否かを判定する。ステップＳ２０９で、肯定的な応答であり、再試行が求められていないと判定された場合（ＮＯ）は、ステップＳ２１０へ処理が分岐される。ステップＳ２１０では、スレーブノード１５０，１７０は、ヘッドノード１１０の制御の下、並列ＲＩＰに基づく印刷出力における自身が担当する処理（ＲＩＰまたは転送処理）が実行可能な状態となる。以降、新たなジョブがキューから取り出された段階で、計算ノード１５０は、ヘッドノード１１０から割り当てられたジョブ・チャンクに基づきＲＩＰ演算を実行する。終端ノード１７０は、対応付けられるプリンタ１９０に対しＲＩＰ済みデータを転送する処理を実行する。

一方、ステップＳ２０９で、否定的な応答を受け、ファームウェア更新の再試行が求められていると判定された場合（ＹＥＳ）は、ステップＳ２０１へ再びループさせて、ファームウェア更新を再び繰り返す。また、ステップＳ２０８で、管理対象登録要求に対する応答がないと判定された場合（ＮＯ）は、ステップＳ２１１へ分岐させる。ステップＳ２１１では、スレーブノード１５０，１７０は、応答がタイムアウトしたか否かを判定する。

ステップＳ２１１で、タイムアウトしていないと判定された場合（ＮＯ）は、ステップＳ２０７へ処理をループさせる。これは、スレーブノード１５０，１７０の再起動よりもヘッドノード１１０の再起動が遅れた場合に対応するものである。一方、ステップＳ２１１で、タイムアウトしたと判定された場合（ＹＥＳ）は、何らかの障害が起こっている可能性があるため、ステップＳ２１２で、例えば、待機状態に移行するか、あるいはシャットダウンを行う。

以下、図６〜図８に示す具体的なケースを参照しながら、ＲＩＰサーバ１０４のファームウェア更新における各ノードの動作を説明する。図６は、スレーブノードに更新中なんら問題が生じない場合のヘッドノードおよびスレーブノードの動作を示すシーケンス図である。なお、図６には、スレーブノード１およびスレーブノード２を代表して示すが、スレーブノードの数は特に限定されるものではなく、また、これらは、計算ノード１５０および終端ノード１７０のいずれであってもよい。また、ヘッドノード１１０の開始時点のファームウェアの版は、バージョン１．０（ver.1.0-mb）であり、スレーブノードの版も、バージョン１．０（ver.1.0-sb）であるとする。

図６に示す処理は、更新の契機となるイベントが発生したことに応答してステップＳ３０１から開始される。ステップＳ３０２では、ヘッドノード１１０は、ファームウェアの更新準備を行い、全ノードのファームウェア更新ファイルの版情報を保存する。ここでは、マスタおよびスレーブ共に、バージョン２．０（ver.2.0-sb、ver.2.0-sb）に更新されるものとする。ステップＳ３０３およびＳ３０４では、ヘッドノード１１０は、管理しているノード識別子を取り出し、このノード識別子を用いて、スレーブノード１およびスレーブノード２に対し、更新開始指令を発行する。同時に、スレーブノード１およびスレーブノード２に対し、バージョン２．０のファームウェア更新ファイル（ver.2.0-sb）を送信する。

ステップＳ３０５では、ヘッドノード１１０は、自身の更新処理を実行する。自身のファームウェア更新処理が終了すると、ヘッドノード１１０は、管理しているノードのノード識別子をリストからクリアする。ステップＳ３０６では、ヘッドノード１１０は、全スレーブノードに対して送信した更新開始指令に対する結果を待たず、シャットダウンする。

ヘッドノード１１０側の更新処理に並行して、スレーブノード１は、ステップＳ３０７で、受信したバージョン２．０のファームウェア更新ファイル（ver.2.0-sb）を用いて、自身の更新処理を実行し、ステップＳ３０８で、シャットダウンする。同様に、スレーブノード２も、ステップＳ３０９で、自身の更新処理を実行し、ステップＳ３１０で、シャットダウンする。

ここで、ステップＳ３１１で、スレーブノード１が、ステップＳ３０８でのシャットダウン後に、新しいバージョン２．０（ver.2.0-sb）に更新された状態で、起動したとする。ステップＳ３１２では、スレーブノード１は、自身をヘッドノード１１０の管理対象として登録してもらうために、自身を識別するノード識別子とファームウェアの版情報（ver.2.00-sb）とを付して、ヘッドノード１１０に対し管理対象登録要求を送信する。しかしながら、ここでは、ヘッドノード１１０が未だ起動していないため、応答が返却されない。スレーブノード１は、管理対象登録要求に対する応答が返ってくるまで、管理対象登録要求を定期的に行っており、ステップＳ３１３では、さらに、ヘッドノード１１０に対し管理対象登録要求を送信するが、ここでも、応答が返却されない。

ステップＳ３１４では、スレーブノード２が、ステップＳ３１０でのシャットダウン後に、新しいバージョン２．０（ver.2.0-sb）に更新された状態で起動する。ステップＳ３１５では、スレーブノード２は、スレーブノード１と同様に、管理対象登録要求を送信する。ここでも、ヘッドノード１１０が未だ起動していないため応答は返却されない。

時が経過し、ステップＳ３１６で、ヘッドノード１１０が、ステップＳ３０６でのシャットダウン後に、新しいバージョン２．０（ver.2.0-mb）の状態で起動したとする。起動後、ヘッドノード１１０は、管理対象登録要求を受け付け可能な状態となる。ヘッドノード１１０は、管理対象登録依頼受け付けが可能な一定の制限時間を保持しており、起動後から時間経過の計測を開始する。

ステップＳ３１７で、スレーブノード１がヘッドノード１１０に管理対象登録要求を送信すると、ステップＳ３１８では、ヘッドノード１１０は、バージョンの整合性を検証する。ここでは、スレーブノード１からの管理対象登録要求と共に送られたスレーブノード１のファームウェアの版情（ver.2.00-sb）と、管理している版情報（ver.2.00-sb）とが比較され、ここでは、バージョンが整合していると判定される。ステップＳ３１９では、ヘッドノード１１０は、管理対象登録要求と共に受け取ったスレーブノード１のノード識別子をノード管理部１２２の管理対象リストに記録し、肯定的な管理対象登録応答をスレーブノード１に送信する。ステップＳ３２０では、スレーブノード１は、ヘッドノード１１０からの肯定的な管理対象登録応答を受けて、処理を実行可能な状態に移行する。

スレーブノード２についても同様であり、ステップＳ３２１で、スレーブノード２が管理対象登録要求をヘッドノード１１０に送信すると、ステップＳ３２２では、ヘッドノード１１０は、バージョンの整合性を検証する。ここでは、整合していると判定されるものとする。ステップＳ３２３では、ヘッドノード１１０は、スレーブノード２のノード識別子を管理対象リストに記録し、スレーブノード２に肯定的な管理対象登録応答を送信する。ステップＳ３２４では、スレーブノード２は、ヘッドノード１１０からの肯定的な応答を受けて、処理を実行可能な状態に移行する。

ヘッドノード１１０は、ステップＳ３２５で、制限時間が経過したことを検出すると、ステップＳ３２６で、システムを始動させる。これにより、並列ＲＩＰに基づく印刷出力処理が可能な状態となる。ヘッドノード１１０は、システム再開以後、スレーブノードから管理対象登録要求を受信しても、要求を却下する。

上述したシーケンスにより、ＲＩＰサーバ１０４全体のファームウェアが新しいものに更新され、最新の状態にシステムが維持されるとともに、登録を要求してきたスレーブノードのみを組み込んで、並列ＲＩＰに基づく印刷出力処理が実行可能となる。

図７は、スレーブノード２で故障が生じた場合のＲＩＰサーバ１０４のヘッドノードおよびスレーブノードの動作を示すシーケンス図である。なお、スレーブノード１で故障した場合も、同様なシーケンスとなる。図７に示す処理は、更新の契機となるイベントが発生したことに応答してステップＳ４０１から開始される。なお、ステップＳ４０２〜ステップＳ４１３までの処理は、図６に示したステップＳ３０２〜ステップＳ３１３までの処理と同じであるので、以下、ステップＳ４１４以降について説明する。

ここで、ステップＳ４１４で、スレーブノード２の起動時において復旧不可能な故障が何らかの原因で生じたとする。ヘッドノード１１０は、ステップＳ４１５で起動し、ステップＳ４１６〜ステップＳ４１９で示した処理により、スレーブノード１を管理対象として登録する。しかしながら、スレーブノード２は、復旧しておらず、管理対象登録要求を発行できないので、そのまま、ステップＳ４２０で、制限時間が経過したことが検出されることになる。

制限時間が経過したことを検出すると、ヘッドノード１１０は、復旧しなかったスレーブノード２を管理対象として登録しないまま、ステップＳ４２１で、システムを始動させる。ヘッドノード１１０は、システム再開以後、スレーブノード２を含め他のスレーブノードから管理対象登録要求を受信しても、要求を却下する。

上記シーケンスでは、制限時間が経過した時点で、スレーブノード２の管理登録要求が受信されていないため、スレーブノード２は管理対象とはならない。しかしながら、この場合でも、特別なシーケンスは発生せずに、システム自体は、フォールトトレラントに再開されることになる。そして、スレーブノード２が除かれた状態でスレーブノードが組み込まれた並列ＲＩＰに基づく印刷出力処理が実行可能となる。

図８は、スレーブノード２の更新完了前に電源断が発生した場合のＲＩＰサーバ１０４のヘッドノードおよびスレーブノードの動作を示すシーケンス図である。図８に示す処理は、更新の契機となるイベントが発生したことに応答して、ステップＳ５０１から開始される。なお、ステップＳ５０２〜ステップＳ５０８までの処理は、図６に示したステップＳ３０２〜ステップＳ３０８までの処理と同じであるので、以下、ステップＳ５０９以降について説明する。

ここで、ステップＳ５０９で、ヘッドノード１１０およびスレーブノード１の更新処理が成功裡に完了した後、かつ、スレーブノード２が更新処理を完了させる前に、何らかの原因でシステム全体に電源断が生じたとする。ヘッドノード１１０は、ステップＳ５１０で起動し、スレーブノード１も、ステップＳ５１１で起動する。そして、ステップＳ５１２〜ステップＳ５１５で示した処理により、ヘッドノード１１０は、スレーブノード１を管理対象として登録し、スレーブノード１は、処理を実行可能な状態に移行する。

ステップＳ５１６で、スレーブノード２が起動するが、ここでは、更新処理が完了せずに電源断してしまったため、従前のバージョン１．０（ver.1.0-sb）の状態で起動することになる。ステップＳ５１７では、スレーブノード２が、ヘッドノード１１０に管理対象登録要求を送信し、ステップＳ５１８では、ヘッドノード１１０が、バージョンの整合性を検証する。ここでは、スレーブノード２が従前のバージョンのまま起動しているので、管理対象登録要求と共に送られたスレーブノード２のファームウェアの版情（ver.1.00-sb）と、管理している版情報（ver.2.00-sb）とは一致しない。ステップＳ５１９では、ヘッドノード１１０は、スレーブノード２に対し、否定的な応答を送信するとともに、ファームウェア更新の再試行を指令する。

再試行の指令を受けて、スレーブノード２は、ステップＳ５２０で、更新処理を再度実行し、ステップＳ５２１で、シャットダウンする。ステップＳ５２２では、スレーブノード２が、新しいバージョン２．０（ver.2.0-sb）に更新された状態で起動する。ステップＳ５２３では、スレーブノード２は、新しい版情報を付して管理対象登録要求を送信し、ステップＳ５２４およびステップＳ５２６で示した処理により、ヘッドノード１１０は、スレーブノード２を管理対象として登録する。これにより、スレーブノード２は、処理を実行可能な状態に移行する。以降、ステップＳ５２７で、制限時間が経過したことが検出されると、ヘッドノード１１０は、システムを始動させる。

上述したシーケンスでは、管理対象登録時に必ずスレーブノードの版情報が検証される。このため、スレーブノードが自身の更新処理を完了させる前に電源断に陥ってしまっても、バージョンが不整合なスレーブノードが組み込まれてしまったままでシステムが再開されてしまうことを防止することが可能となる。

以下、図９を参照しながら、ＲＩＰサーバ１０４のハードウェア構成について説明する。図９に示すＲＩＰサーバ１０４は、いわゆるブレード・サーバとして構成されている。エンクロージャ２００には、その内部に設けられたブレードベイに、ホットプラグに対応したコネクタを介して、複数のサーバブレード２１０−１〜２１０−ｎが装着されている。エンクロージャ２００は、イーサネット（登録商標）やファイバチャネルなどの入出力ポート２０２と、スイッチ・モジュール２０４と、電源ユニット２０６とを含む。

サーバブレード２１０は、それぞれ、１以上のプロセッサ２１２と、メモリ２１４と、必要に応じてＨＤＤ２１６と、必要に応じてファイバチャネルなどの拡張ボード２１８と、ネットワークインタフェース２２０とを含む。なお、各ブレードの構成は、必ずしも同一である必要はない。サーバブレード２１０同士は、スイッチ・モジュール２０４のイーサネット（登録商標）スイッチなどを介して相互に接続されてもよい。

各サーバブレード２１０上で動作するノード（ヘッドノード１１０、計算ノード１５０および終端ノード１７０を含む。）は、自身のＨＤＤ２１６あるいは、共用のＨＤＤからファームウェアを読み出し、メモリ２１４上に展開することにより、上述した各機能手段を実現する。なお、図９に示すサーバブレード２１０は、２ノード構成を例示する。

上述した実施形態では、スレーブノード１５０，１７０が主導となって、ヘッドノードにおける管理対象が決定される。スレーブノードが復旧不可能となった場合は、そのスレーブノードから管理対象登録要求が発行されないので、管理対象とされない。このため、ヘッドノード１１０は、ファームウェア更新後に動作可能なスレーブノードの数が変動しても、その動作可能なノードだけでシステムを再開させることができるようになる。

さらに、上述した実施形態では、スレーブノードが、プリンタ１９０に依存しない計算ノード１５０と、プリンタ１９０との接続を集約する終端ノード１７０とに種類が分けられている。計算ノードがプリンタと接続されると、計算ノードのソフトウェア更新がプリンタへの接続に影響を与える可能性がある。これに対して、上述した実施形態では、プリンタ１９０との接続を終端ノード１７０にまとめており、計算ノード１５０とプリンタ１９０との依存度を下げており、計算ノード１５０のソフトウェア更新中のプリンタ１９０への影響を軽減している。このため、全てのスレーブノードの故障に影響を受けるのではなく、終端ノードの故障のみに影響を受ける形で影響範囲を抑えつつ、計算ノード１５０の故障にかかわらずシステムを再開させることができるようになる。

また、好ましい実施形態では、スレーブノードを管理対象として登録する際に、ファームウェアのバージョンが検証される。この検証において、差異が発生した場合は、ヘッドノード１１０の主導で、そのスレーブノードのファームウェア更新が再試行される。このため、電源断などにより、スレーブノードにおいて、ファームウェアのバージョンに差異が生じていた場合も、かかるバージョンの差異を解消した上でシステムを再開することが可能となる。

上記構成により、連続帳票印刷システム１００は、ＲＩＰサーバ１０４におけるファームウェア更新中のブレード等の故障時に、ユーザの手を介することなく、フォールトトレラントにシステムを再開することができるようになる。さらに、好ましい実施形態では、ファームウェア更新中の電源断により、スレーブノードのファームウェアのバージョンに差異が発生した場合でも、ユーザの手を介することなく、バージョン差異を解消し、システムを再開できる。

以上説明したように本実施形態によれば、複数の演算処理装置を含み構成される情報処理システムにおいて、複数の演算処理装置に対するソフトウェア更新中にいずれかの演算処理装置に障害が発生したとしても、復旧されない演算処理装置を除外してシステムを再始動させることができる、情報処理システム、ソフトウェア更新方法およびプログラムを提供することができる。

なお、上記機能部は、アセンブラ、Ｃ、Ｃ＋＋、Ｃ＃、Ｊａｖａ（登録商標）などのレガシープログラミング言語やオブジェクト指向プログラミング言語などで記述されたコンピュータ実行可能なプログラムにより実現でき、ＲＯＭ、ＥＥＰＲＯＭ、ＥＰＲＯＭ、フラッシュメモリ、フレキシブルディスク、ＣＤ−ＲＯＭ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＷ、ブルーレイディスク、ＳＤカード、ＭＯなど装置可読な記録媒体に格納して、あるいは電気通信回線を通じて頒布することができる。

これまで本発明の実施形態について説明してきたが、本発明の実施形態は上述した実施形態に限定されるものではなく、他の実施形態、追加、変更、削除など、当業者が想到することができる範囲内で変更することができ、いずれの態様においても本発明の作用・効果を奏する限り、本発明の範囲に含まれるものである。

１００…連続帳票印刷システム、１０２…ネットワーク、１０４…ＲＩＰサーバ、１１０…ヘッドノード、１１２…送信部、１１４…受信部、１１６…ファームウェア格納部、１１８…更新制御部、１２０…更新処理部、１２２…ノード管理部、１２４…並列ＲＩＰ制御部、１２６…分割部、１２８…面付け部、１３０…割り当て部、１３２…ページ順序制御部、１３４…計算ノード制御部、１３６…終端ノード制御部、１３８…プリンタ制御部、１５０…計算ノード、１５２…送信部、１５４…受信部、１５６…更新処理部、１５８…登録要求発行部、１６０…ＲＩＰ処理部、１７０…終端ノード、１７２…送信部、１７４…受信部、１７６…更新処理部、１７８…登録要求発行部、１８０…転送処理部、１９０…プリンタ、２００…エンクロージャ、２０２…入出力ポート、２０４…スイッチ・モジュール、２０６…電源ユニット、２１０…サーバブレード、２１２…プロセッサ、２１４…メモリ、２１６…ＨＤＤ、２１８…拡張ボード、２２０…ネットワークインタフェース

特許第５０８０３１８号公報 特許第４０５４８０２号公報

Claims (10)

1. 複数の演算処理装置と、前記複数の演算処理装置で行われた処理結果に基づいて出力処理を行う１以上の出力装置とを含む情報処理システムであって、
   前記複数の演算処理装置は、
   複数の処理実行装置に対しソフトウェアの更新を指令する更新指令手段と、管理対象として登録するよう要求してきた処理実行装置を管理する管理手段と、管理対象として登録された処理実行装置を用いた並列処理を制御する並列処理制御手段とを含む管理装置と、
   前記管理装置からの指令に応答してソフトウェアの更新を実行する更新処理手段と、前記管理装置に対し管理対象として登録するよう求める要求を行う登録要求手段と、出力処理のための処理を実行する処理手段とをそれぞれが含む前記複数の処理実行装置と
   を含む、情報処理システム。
2. 前記複数の処理実行装置は、
   それぞれが、前記１以上の出力装置いずれとも依存関係を有しておらず、前記処理手段として、前記管理装置から割り当てられたデータに基づき画像処理を実行する画像処理手段を含む複数の画像処理装置と、
   それぞれが、対応付けられる出力装置との接続を集約しており、前記処理手段として、前記対応付けられる出力装置に対する画像処理済みデータの転送処理を実行する転送処理手段を含む１以上の終端処理装置と
   を含む、請求項１に記載の情報処理システム。
3. 前記更新指令手段は、更新処理を開始する契機となるイベントに応答して、前記ソフトウェアの更新を指令することを特徴とし、前記管理手段は、前記処理実行装置から送られてきた前記要求に応答して、要求元の処理実行装置を管理対象として登録することを特徴とする、請求項１または２に記載の情報処理システム。
4. 前記管理装置は、前記管理手段が前記要求元の処理実行装置を登録する前に、前記要求元の処理実行装置のソフトウェアの版情報を確認する確認手段と、版に不整合がある場合に、前記要求元の処理実行装置に対し再度のソフトウェアの更新を指令する再試行手段とをさらに含む、請求項３に記載の情報処理システム。
5. 前記管理手段は、前記管理対象として登録するよう求める要求を、事前定義された制限時間内に送付してきた処理実行装置を管理対象として登録し、前記並列処理制御手段は、前記制限時間の経過後に並列処理を実行可能とする、請求項１〜４のいずれか１項に記載の情報処理システム。
6. 前記管理装置の並列処理制御手段は、要求されたジョブを構成する複数のジョブ・チャンクを準備する手段と、
   前記ジョブの内容に応じて、転写部材に対する面付けを決定する手段と、
   前記複数のジョブ・チャンクの各々を前記複数の画像処理装置各々に割り当てる手段と
   をさらに含み、
   前記画像処理装置の画像処理手段は、それぞれ、割り当てられたジョブ・チャンクに基づき、ラスタイメージを生成する処理を実行し、
   前記終端処理装置の転送処理手段は、それぞれ、対応する出力装置で出力すべきラスタイメージを受け取り、該対応する出力装置に送信する処理を実行し、
   前記出力装置は、受信したラスタイメージに基づき印刷出力する、請求項２に記載の情報処理システム。
7. 複数の演算処理装置と、前記複数の演算処理装置で行われた処理結果に基づいて出力処理を行う１以上の出力装置とを含む情報処理システムにおけるソフトウェア更新方法であって、
   前記複数の演算処理装置のうちの管理装置が、前記複数の演算処理装置のうちの処理実行装置に対しソフトウェアの更新を指令するステップと、
   前記処理実行装置が、前記管理装置からの指令に応答してソフトウェアの更新を実行するステップと、
   ソフトウェアの更新を完了させた処理実行装置が、前記管理装置に対し管理対象として登録するよう求める要求を行うステップと、
   前記管理装置が、管理対象として登録するよう要求してきた要求元の処理実行装置を管理対象として登録するステップと、
   前記管理装置が、前記管理対象として登録された処理実行装置を用いた並列処理を実行可能とするステップと
   を含む、ソフトウェア更新方法。
8. 前記並列処理を実行可能とするステップの後、さらに、
   前記処理実行装置のうちの、前記１以上の出力装置いずれとも依存関係を有していない画像処理装置が、前記管理装置から割り当てられたデータに基づき画像処理を実行するステップと、
   前記処理実行装置のうちの、対応付けられる出力装置との接続を集約している終端処理装置が、前記対応付けられる出力装置に対する画像処理済みデータの転送処理を実行するステップと
   を含む、請求項７に記載のソフトウェア更新方法。
9. 複数の演算処理装置と、前記複数の演算処理装置で行われた処理結果に基づいて出力処理を行う１以上の出力装置とを含む情報処理システムにおける、管理装置として動作する演算処理装置を実現するためのプログラムであって、コンピュータを、
   複数の処理実行装置に対しソフトウェアの更新を指令する更新指令手段、
   管理対象として登録するよう要求してきた処理実行装置を管理する管理手段、および
   管理対象として登録された処理実行装置を用いて並列処理の実行を制御する並列処理制御手段
   として機能させるためのプログラムであり、前記ソフトウェアは、前記処理実行装置が起動した後、当該管理装置へ管理対象として登録するよう求める要求を行うようコードされている、プログラム。
10. 前記ソフトウェアは、
    前記処理実行装置上で動作して、該処理実行装置を、前記管理装置からの指令に応答して、割り当てられたデータに基づき画像処理を実行する画像処理手段、または、対応付けられる出力装置に対する画像処理済みデータの転送処理を実行する転送処理手段として機能させるためのコードを含む、請求項９に記載のプログラム。