JP2015005149A - クラウドプリントにおけるプリントサーバ障害時のリカバリ方法 - Google Patents

Abstract

【課題】印刷システムにおけるサーバの負荷を分散し、実行中の印刷ジョブを確実に実行できるプリントサーバ障害時のリカバリ方法を提供する。【解決手段】プリントサーバは、監視サーバから、他のプリントサーバの障害通知を受けた際に、その情報をリカバリ情報として、ＤＢサーバに保存する。そうすることで、リカバリ処理中のプリントサーバに障害が発生した場合でも、リカバリ途中の処理が、第三のプリントサーバによって引き継がれ、クラウドプリントサービスとしてのジョブ実行は継続することができる。【選択図】図１

Description

本発明は、インターネット上に展開される印刷システムにおけるサーバの負荷分散と、可用性の高いサービスの実現方法、及びプログラムに関する。

近年、クラウドサービスとしてインターネット上にサービスを公開するビジネス展開がされてきている。その中で、プリントサーバもインターネット上のプリントサービスとして機能を提供することが求められている。大規模なデータセンター上にプリントサーバを配置し、クラウドサービスとしてプリントサービスを提供することで、顧客ごとのハードウェアの管理が不要となる。また、サーバの負荷に応じてリソースを追加するようなことも容易に行えるといった様々なメリットがある。

クラウドサービスとしてインターネット上に展開するプリントサービスでも、大量のユーザが一つのサービスを利用し、大量のプリンタが接続される。そのため、データを保持するDBサーバと、複数の仮想サーバを用意し、冗長構成をとることで、大量のリクエスト負荷を分散するとともに、一部のサーバに障害が発生した際でもサービスを継続できる可用性の高めることが求められる。

しかし、クラウドプリントサービスでは、パフォーマンスを保ちながら、印刷ジョブの追跡や、プリンタ毎のジョブ順序制御等の信頼性を高めるために、一つのプリントサーバが実行中のジョブまたは、プリンタを担当する期間が存在する。この期間中、あるプリンタを担当する第一のプリントサーバに障害が発生した場合、そのプリンタで実行中の印刷ジョブについては、印刷が失敗してしまう。さらに、障害の発生した第一のプリントサーバがプリンタを専門に担当していた場合には、ユーザが印刷を再実行した場合でも、同じプリンタでは処理ができない状態に陥ってしまう可能性もある。この場合、第一のプリントサーバのバックアップ等から復旧するまで、第一のプリントサーバが担当の処理をリカバリできず、サービスとしての可用性が低くなってしまう。

そのため、このような問題を解決する手段として、複数のサーバを代替関係で定義し、互いにデータを持ち合うことで、第一のサーバに障害が発生した場合でも必要なデータを取得し、サービスの提供を実行するシステムが提案されている（特許文献１)。

特開２０１１−６１６２６号公報

先行技術の方法では、予め代替関係となるサーバ、ノードを定義しておき、一方に障害があった場合に第二のサーバがリカバリを行う。しかし、第二のサーバ、ノードが代替して処理を実行している最中に、第二のサーバ、ノードで障害が発生した場合、代替中の処理は実行されなくなってしまう。クラウドサービスでは、多くのユーザが同時に利用するため、より可用性の高く信頼できるサービスが求められる。本発明では、クラウドプリントサービスでの可用性を高め、実行中の印刷ジョブを確実に実行させることが目的である。

プリントサーバ（１０１〜１０３）、ＤＢサーバ（１０４）、監視サーバ（１０５）、プリンタ（１０６〜１０９）からなる印刷システムにおいて、
プリントサーバ（１０１〜１０３）は、監視サーバ（１０５）から、他のプリントサーバ（１０１〜１０３）の障害通知を受けた場合に、リカバリ対象プリントサーバの情報と、リカバリ担当プリントサーバとを含むリカバリ情報をDBサーバに保存する手段と、
プリントサーバ（１０１〜１０３）は、リカバリ処理開始時に、ＤＢサーバ上のリカバリ情報を参照し、リカバリ対象のアプリサーバが担当するＤＢデータを検出して処理を引き継ぐ手段と、
プリントサーバ（１０１〜１０３）は、ＤＢサーバ（１０４）上のリカバリ情報に含まれるリカバリ対象のプリントサーバが担当のＤＢデータが検出できない(存在しない)場合に、リカバリ情報からリカバリ対象のアプリサーバの情報を削除する手段と、
を有することを特徴とする印刷システム。

本発明では、リカバリ情報をＤＢサーバ上に保持し、全プリントサーバで共有することで、リカバリの対象のプリントサーバと、それを担当するプリントサーバを管理する。そうすることで、障害が発生した第一のプリントサーバが担当する印刷ジョブを第二のプリントサーバでリカバリできる。さらに、リカバリ処理を実行中の第二のプリントサーバに障害が発生した場合でも第三のプリントサーバによってすべての印刷ジョブを継続して実行することができる。

ネットワーク構成を示すブロック図 プリントサーバ、ＤＢサーバ、監視サーバ、プリンタのハードウェア構成図 プリントサーバ、ＤＢサーバ、監視サーバ、プリンタのモジュール構成図 プリントサーバ、ＤＢサーバ、監視サーバ、プリンタのソフトウェア構成図 印刷システムで管理する情報の構成図 実施例１におけるプリンタ、プリントサーバ、監視サーバの動作フロー

以下、本発明を実施するための最良の形態について図面を用いて説明する。

［実施例１］
図１は、本発明の実施の形態に係る印刷システムの全体構成を示す図である。

図１において、プリントサーバ１０１〜１０３、ＤＢサーバ１０４、監視サーバ１０５、プリンタ１０６〜１０９は、ネットワーク１１０〜１１１を介して接続されている。図において、プリンタ１０６〜１０９は、複数台接続されていることを仮定している。ネットワーク１１０〜１１１は、例えば、インターネット等のＬＡＮ、ＷＡＮ、電話回線、専用デジタル回線、ＡＴＭやフレームリレー回線、ケーブルテレビ回線、データ放送用無線回線等のいずれである。またこれらの組み合わせにより実現される、いわゆる通信ネットワークである。

ネットワーク１１０〜１１１は、データの送受信が可能であればよい。そして、プリントサーバ１０１〜１０３から、ＤＢサーバ１０４、監視サーバ１０５への通信手段、プリンタ１０６〜１０９からプリントサーバ１０１〜１０３への通信手段は異なっていてもよい。プリントサーバ１０１〜１０３は、プリンタ１０６〜１０９からの印刷要求に基づいて、ＤＢサーバ１０４上のデータを参照し、印刷データを生成し、返す。この際、プリンタ１０６〜１０９からの印刷要求は、ロードバランサ（負荷分散装置）を経由し、プリントサーバ１０１〜１０３の中の一つのプリントサーバに送られ、処理される。

ＤＢサーバ１０４は、プリンタ情報や印刷ジョブ情報、リカバリ情報、印刷データ等を保持し、プリントサーバ１０１〜１０３からの要求に対してその情報を返す。監視サーバ１０５は、監視対象サービス情報としてプリントサーバ１０１〜１０３の情報を管理し、プリントサーバ１０１〜１０３の稼働状況をモニタリングする。監視サーバ１０５は、プリントサーバ１０１〜１０３のいずれかに異常が発生したことを検知すると、異常が発生していない一つ以上のプリントサーバ１０１〜１０３へリカバリ処理の実行を指示する。

図２は、本発明の実施形態に係る印刷システムのプリントサーバ１０〜１０３、ＤＢサーバ１０４、監視サーバ１０５、プリンタ１０６〜１０９のハードウェア構成図である。

図２において、２０２は装置全体の制御を行うＣＰＵであり、ハードディスク（ＨＤＤ）２０５に格納されているアプリケーションプログラム、ＯＳ等を実行し、ＲＡＭ２０３にプログラムの実行に必要な情報、ファイル等を一時的に格納する制御を行う。２０４は記憶手段としてのＲＯＭであり、内部には、基本Ｉ／Ｏプログラム等のプログラム、印刷処理の際に使用する印刷データ、プリンタ情報等の各種データを記憶する。２０３は一時記憶手段としてのＲＡＭであり、ＣＰＵ２０２の主メモリ、ワークエリア等として機能する。

２０５は外部記憶手段の一つであり、大容量メモリとして機能するハードディスク（ＨＤＤ）である。プリントサーバプログラム、ＤＢサーバプログラム、監視サーバプログラム、ＯＳ、関連プログラム等を格納している。２０６は表示手段であるディスプレイであり、キーボード２０７から入力したコマンドや、プリンタのステータス等を表示したりするものである。２０８は外部装置Ｉ／Ｆであり、プリンタ、ＵＳＢ機器、周辺機器を接続するためのＩ／Ｆである。２０７は指示入力手段であるキーボードである。

２０１はシステムバスであり、印刷システムのプリントサーバ、ＤＢサーバ、監視サーバ内におけるデータの流れを司るものである。２０９はネットワークインタフェースカード（ＮＩＣ）であり、該インタフェース２０９、ネットワーク１１０〜１１１を介して外部装置とのデータのやり取りを行う。なお、上記コンピュータの構成はその一例であり、図２の構成例に限定されるものではない。例えば、データやプログラムの格納先は、その特徴に応じてＲＯＭ、ＲＡＭ、ＨＤＤなどで変更することも可能である。

また、２０９はプリンタ１０５〜１０８のコントローラであり、プリンタの制御系を司る機器である。２１０は装置全体の制御を行うＣＰＵであり、システムバス２１８に接続される各種デバイスとのアクセスを統括的に制御する。この制御は、ROM２１２に記憶された制御プログラム等あるいはディスクコントローラ(DKC２１６)を介して接続された外部メモリ２２３に記憶された制御プログラムやリソースデータ(資源情報)等に基づく。２１１はＣＰＵ２１０の主メモリ、ワークエリア等として機能するRAMで、図示しない増設ポートに接続されるオプションRAMによりメモリ容量を拡張することができるように構成されている。

２１３は大容量メモリとして機能する外部記憶手段であり、プルプリントアプリケーションプログラム及び関係プログラム等を格納している。２２１は操作パネル（操作部）でプルプリントの操作を行うユーザインタフェースやプルプリント切り替えボタンが配置される。また、プリンタ１０６〜１０９の動作モード等の設定やプリンタ１０６〜１０９の動作状況の表示、複写指定等の操作を行うためのボタンおよび液晶パネルやＬＥＤ２１４等の表示部も配置される。２１９は、ネットワークインタフェースカード（ＮＩＣ）であり、該インタフェース２１９を介して外部装置とのデータのやり取りを行う。

なお、本図で示したプリントエンジン２２０は既知の印刷技術を利用するものであり、好適な実施系として例えば電子写真方式(レーザービーム方式)やインクジェット方式、昇華方(熱転写)方式等が挙げられる。２１５のラスタコントローラは、ＰＤＬ言語・ＰＤＦ言語である印刷データを画像データに変換するコントローラである。２１７の機器Ｉ／Ｆは、ＵＳＢ等で接続可能な外部機器との接続Ｉ／Ｆである。

図３は、本発明の実施形態に係る印刷システムのシステム構成図である。

プリントサーバ１０４には、印刷ジョブやプリンタ情報を管理する印刷管理サービス３０１がある。このサービスは、他サービス、または他プログラムから投入される文書データ等を印刷データとしてＤＢサーバ１０４のＤＢ管理サービス３０４を通してストレージ３０５に管理する。印刷データのデータフォーマットは、ＰＤＬまたは、ＰＤＦ等の形式である。また、印刷管理サービス３０１は、プリンタ１０６〜１０９について、後述のプリンタ情報の管理も行う。

Ｗｅｂサービス３０２は、プリンタ１０６〜１０９のプルプリントアプリケーション３０７からの印刷ジョブ取得リクエストに対し印刷データを返し、また、印刷処理におけるジョブのステータスを受け取る。サービス監視エージェント３０３は、印刷管理サービスの状態を監視し、その状態を定期的に監視サーバ１０５のサービス監視サービス３０６に通知する。また、印刷管理サービス３０１、Ｗｅｂサービス３０２はそれぞれ独立したプログラムであり、それぞれ別々の情報処理装置に配置することが可能である。

これらのプログラムはそれぞれネットワークに繋がった情報処理装置に配置し、それぞれのプログラム間で通信を行う。またこれらのプログラムを同情報処理装置に配置することも可能である。

ＤＢサーバ１０４には、ＤＢ管理サービスがあり、印刷管理サービス３０１からの要求に従い、ストレージ３０５からデータの読み書きを行う。ストレージ３０５はＤＢサーバ１０４の情報処理装置に内蔵するＨＤＤまたは、外部接続しているＨＤＤ、または、ネットワークストレージ等の記憶装置である。

監視サーバ１０５には、サービス監視サービス３０６があり、予め登録されている各監視対象サービスについて、後述の監視対象サービス情報を管理する。さらに、監視対象サービス情報の変化をきっかけとして、プリントリカバリ処理の実行をプリントサーバ１０１〜１０３のサービス監視エージェント３０３に指示する。

プリンタ１０６〜１０９には、プルプリントアプリケーション３０７があり、ユーザからの印刷操作に従って、プリントサーバ１０１〜１０３のＷｅｂサービス３０２へ印刷要求を行い、取得した印刷データの印刷を実行する。

図４は、本発明の実施形態に係る印刷システムのソフトウェア構成図である。

プリントサーバ１０１〜１０３に位置する印刷管理サービス３０１の印刷ジョブ管理部４０１は、ＤＢサーバ１０４のＤＢ管理サービス３０４を通して、ストレージ３０５で保持している、印刷データの情報を含む印刷ジョブ情報を管理する。印刷ジョブ管理部４０１は、Ｗｅｂサービス３０２からジョブ情報及び、印刷データの取得リクエストを受け取ると、ＤＢ管理サービス３０４のリクエスト受付部４０８に要求を送り、指定のジョブ情報及び、印刷データを取得し、Ｗｅｂサービス３０２に渡す。印刷管理サービス３０１のプリンタ管理部４０２では、ＤＢ管理サービス３０４のリクエスト受付部４０８を通して後述図５のプリンタ情報を管理する。

さらに、プリンタ管理部４０２は、サービス監視エージェント３０３からリカバリ処理の実行指示を受けた場合、ＤＢ管理サービス３０４を通して、ストレージ３０５上に保持される後述図５のリカバリ情報を参照、更新する。

Ｗｅｂサービス３０２は、印刷データ取得部４０３、リクエスト受付部４０４からなる。印刷データ取得部４０３は、印刷ジョブ取得リクエストをリクエスト受付部４０４が受けると、前述の印刷管理サービス３０１から印刷データを取得し、返す。Ｗｅｂサービス３０２のリクエスト受付部４０４は、プリンタ１０６〜１０９のプルプリントアプリケーション３０７からの印刷データ取得リクエストや、印刷ジョブのステータスを受ける。

リクエスト受付部４０４は、印刷データ取得リクエストを受け付けると、リクエストに含まれる情報を基に、印刷ジョブ管理部４０１にジョブ情報を取得する。また、リクエスト受付部４０４は、印刷ジョブのステータスを受けると、そのステータスをプリンタ管理部４０２に通知する。

サービス監視エージェント３０３は、リカバリ処理実行部４０５と、サービス状態通知部４０６からなる。リカバリ処理実行部４０５は、監視サーバ１０５からのリカバリ実行指示を受け、印刷管理サービス３０１へ、リカバリ処理の実行を指示する。サービス状態通知部４０６は、定期的に印刷管理サービス３０１の稼働状態を確認し、その状態を監視サーバ１０５へ通知する。

ＤＢサーバのＤＢ管理サービス３０４は、ＤＢデータ読み書き部４０７と、リクエスト受付部４０８からなる。ＤＢデータ読み書き部は、リクエスト受付部４０８が受け付けたＤＢ読み書き要求に基づいて、実際にストレージへの読み書きを実行する。また、ＤＢ読み書き部４０７は、一つのデータに対して複数の読み書き要求があった場合の、排他制御等も行う。

監視サーバ１０５のサービス監視サービス３０６は、サービス状態通知受付部４０９と、リカバリ実行指示部４１０と、監視対象サーバ管理部４１１からなる。サービス状態通知受付部４０９は、サービス監視エージェント３０３からサービスの稼働状態の通知を受け付ける。リカバリ実行指示部４１０は、サービス監視エージェント３０３へ、リカバリ処理の実行を指示する。監視対象サーバ管理部４１１は、監視対象となるプリントサーバ１０１〜１０３の情報を管理し、サービス状態通知受付部４０９が受信したサービス稼働状況を基に、後述図５の監視対象サービス情報を管理する。さらに、監視対象サーバ管理部４１１は、サービスの稼働状況の変化をきっかけとして、リカバリ実行指示部４１０にリカバリ処理の実行を指示させる。

プリンタ１０６〜１０９のプルプリントアプリケーション３０７は、Ｗｅｂサービス送信部４１２、プルプリントコントローラ４１３、印刷データ送信部４１４からなる。Ｗｅｂサービス送信部４１２は、Ｗｅｂサービス３０２へ印刷ジョブ取得リクエストまたは、印刷ステータスの通知を行う。ユーザから印刷実行指示を受けると、Ｗｅｂサービス送信部４１２を通してＷｅｂサービス３０３から印刷データを取得し、印刷データ送信部４１４に送る。印刷データ送信部４１４は、コントローラ２０９に印刷データを送信する。

また、Ｗｅｂサービス送信部４１２は、コントローラ２０９から受け取った印刷ジョブのステータスをＷｅｂサービス３０２に通知する。プルプリントコントローラ４１３は、プルプリントアプリケーション３０４全体の動作管理を行うものであり、各部への動作指示等は、このコントローラ経由で行う。

図６は、本発明の実施形態に係る印刷システムで管理される情報の例である。

印刷ジョブ情報５０１は、ストレージ３０５に保持され、印刷ジョブ管理部４０１で管理される、印刷指示を受け、印刷実行中のジョブに関する情報である。印刷ジョブ情報には、実行ユーザＩＤ、実行ジョブを識別するためのジョブＩＤ、印刷ステータス、プリンタ識別情報等が含まれる。

プリンタ情報５０２は、ストレージ３０５に保持され、プリンタ管理部４０２で管理される、プリントサーバ１０１〜１０３で管理するプリンタ１０６〜１０９の複数のプリンタ情報である。プリンタ識別情報、プリンタ名、ステータス等が含まれる。プリンタ識別情報は、各プリンタをユニークに識別する情報であり、ＩＰアドレスや、ＭＡＣアドレスや、ＵＲＩ等である。ステータスは、プリンタのステータスであり、用紙切れ、ジャム、カバーオープン、トナーなし、排紙ビンフル、ハードディスクフル、その他エラー、ウォーミングアップ中、キャリブレーション中、初期化中、オフライン、スリープ中、印刷中、印刷可能、状態不明等のステータスがある。

監視対象サービス情報５０３は、監視サーバ１０５上に保持され、監視サーバ管理部４１１で管理される、プリントサーバ１０１〜１０３の稼働状態に関する情報である。監視対象サービス情報５０３には、プリントサーバ識別情報、サービスステータス、前回ステータス、ＩＰ、ステータス更新日時等を含む。プリントサーバ識別情報は、プリントサーバ１０１〜１０３夫々を識別できる情報であり、ＩＰアドレスや、ホスト名等である。サービスステータスは、印刷管理サービス３０１の状態を示すもので、前回更新時のステータスは、前回ステータスとして保持される。ＩＰは、プリントサーバ１０１〜１０３へリカバリ処理の実行を指示する際に用いられるものであり、ＩＰアドレスに限らず、ＭＡＣアドレスや、その他ネットワーク上で識別可能な値でもよい。

リカバリ情報５０４は、ストレージ３０５に保持され、プリントサーバ１０１〜１０３で管理される、リカバリ対象や、リカバリ中のプリントサーバ１０１〜１０３の情報である。リカバリ対象プリントサービス識別子は、障害が発生し、リカバリ対象となるプリントサーバ１０１〜１０３の識別子である。また、リカバリ担当プリントサービス識別子は、障害が発生したプリントサーバ１０１〜１０３の担当ジョブをリカバリ実行しているプリントサーバ１０１〜１０３のプリントサーバ識別子である。プリントサーバ１０１〜１０３は、この情報を参照することで、互いにリカバリ処理の実行状況を確認することができる。

図６は、プリンタ１０６〜１０９の印刷データ取得を行う際の動作フローと、その際にプリントサーバ１０１〜１０３で障害が発生した場合の、プリントサーバ１０１〜１０３、監視サーバ１０５の動作フローである。

プルプリントアプリケーション３０７において、ユーザのオペレーションから印刷の指示を受け付けると、その情報を基に、印刷データ取得を開始する。Ｓ６０１では、印刷指示の情報を基に、Ｗｅｂサービス送信部４１２からプリントサーバ１０１〜１０３へ印刷データ取得リクエストを送信する。Ｓ６０２で、印刷データ取得リクエストの返信として返ってきた印刷データを受信し、Ｓ６０３で印刷データ送信部４１４からコントローラ２０９に印刷データを送信することで印刷を実行する。

Ｓ６０４では、Ｓ６０２で受信した印刷データから、全印刷データの受信が完了しているかを確認し、完了していない場合には、Ｓ６０１で、未取得の印刷データの取得リクエストを送信する。Ｓ６０４で全データの取得が完了していると判断した場合は、Ｓ６０５で、印刷結果をＷｅｂサービス送信部４１２からプリントサーバ１０１〜１０３へ送信し、処理を終了する。

プリントサーバ１０１〜１０３においては、プルプリントアプリケーション３０７からリクエストを受け付けた際には、担当の印刷管理サービスへのリクエスト振り分けを行う。まず、Ｓ６１１で、リクエスト受付部４０４で、リクエストを受け付ける。Ｓ６１２では、リクエスト情報を基に、ＤＢ管理サービス３０４に問い合わせて、プリンタ情報５０２からリクエスト元のプリンタ１０６〜１０９の担当プリントサービス１０１〜１０３を確認する。そして、Ｓ６１３で、担当の印刷管理サービス３０１へ印刷ジョブの処理を依頼する。

印刷データ取得リクエストを割り振られたプリントサーバ１０１〜１０３は、印刷データ取得処理を開始する。Ｓ６２１で、印刷データ取得リクエストを受け付けると、印刷ジョブ管理部４０１は、リクエスト情報を基に、ＤＢ管理サービス３０４を通して印刷ジョブ情報５０１を参照し、ストレージ３０５上に保持されている印刷データを取得し、Ｗｅｂサービス３０２に返す。Ｗｅｂサービスは、印刷管理サービス３０１から取得した印刷データを、リクエスト元のプリンタ１０６〜１０９に送信する。

印刷結果通知リクエストを割り振られたプリントサーバ１０１〜１０３は、印刷結果更新処理を開始する。Ｓ６３１で印刷結果を受信すると、リクエスト情報を基に、印刷ジョブ管理部４０１にて、印刷ジョブ情報５０１を更新する。これにより、プリントサーバ１０１〜１０３上でジョブの実行状況が管理される。

サービス状態監視は、監視サーバ１０５上で、実行される動作フローである。ます、Ｓ６４１で、サービス状態通知受付部４０９が、サービス状態通知部４０６から、プリントサーバ識別情報を含むサービスの稼働状態情報を受信する。次に、Ｓ６４２では、監視対象サービス管理部４１１が、Ｓ６４１で受け取った情報を基に、監視対象サービス情報５０３を更新する。Ｓ６４３では、更新された監視対象サービス情報５０３を確認し、Ｓ６４４で、前回ステータスと、サービスステータスを比較する。

Ｓ６４４の比較の結果、サービスのステータスが、正常から障害状態に変化した場合、Ｓ６４５にて、対象のサービス識別情報を含むリカバリ指示を、正常なプリントサービス１０１〜１０３の監視リカバリ処理実行部４０５に送信する。このサービス状態監視の処理は、各プリントサーバ１０１〜１０３のサービス監視エージェント３０３からサービス状態の通知を受信した際に実行される。

リカバリ実行指示を受信したプリントサーバ１０１〜１０３は、リカバリ処理を実行する。まず、Ｓ６５１で、リカバリ処理実行部４０５がリカバリ対象のサービス情報を含むリカバリ実行指示を受信し、印刷管理サービス３０１に通知する。印刷管理サービス３０１は、Ｓ６５２で、ＤＢ管理サービス３０４を通して、リカバリ情報５０４を参照する。Ｓ６５３では、リカバリ情報５０４において、リカバリ対象サービスの情報が、リカバリ対象サービス識別子に既に存在しているかチェックする。Ｓ６５３で既に存在している場合は、他のサーバがリカバリ処理を実行開始済みであるため、何もせず処理を終了する。

Ｓ６５３で存在しない場合は、Ｓ６５４において、リカバリ対象サービス識別子に、リカバリ実行指示に含まれる対象サービスの識別子を、リカバリ担当サービス識別子に自身のサービス識別子をリカバリ情報へ登録する。

次に、Ｓ６５５で、リカバリ情報５０４のリカバリ担当サービス識別子が、リカバリ対象サービスの情報であるものを検索する。検索の結果、該当するリカバリ情報５０４については、Ｓ６５６で、リカバリ担当サービス識別子を自身のサービス識別子に書き換え、更新する。この更新により、障害が発生した、リカバリ対象となっているサービスが担当していたリカバリ処理を、引き継ぐことができる。Ｓ６５７では、リカバリ情報５０４から自身のサービス識別子と、リカバリ担当サービス識別子が一致するものを検索する。そして、該当のリカバリ対象サービス識別子をもつプリンタ情報５０２の担当サービス識別子を自身のサービス識別子書き換える。

これにより、リカバリ対象サービスの担当していたプリンタ情報５０２が、リカバリ担当サービスに引き継がれることとなる。Ｓ６５７ですべてのプリンタ情報５０３の更新に成功すると、最後に、Ｓ６５７でリカバリ情報５０４から、リカバリ担当サービス識別子が自身のサービス識別子と一致するものを削除する。

１０１〜１０３ プリントサーバ
１０４ ＤＢサーバ
１０５ 監視サーバ
１０６〜１０９ プリンタ
１１０〜１１１ ネットワーク

Claims (1)

1. プリントサーバ（１０１〜１０３）、ＤＢサーバ（１０４）、監視サーバ（１０５）、プリンタ（１０６〜１０９）からなる印刷システムにおいて、
   プリントサーバ（１０１〜１０３）は、監視サーバ（１０５）から、他のプリントサーバ（１０１〜１０３）の障害通知を受けた場合に、リカバリ対象プリントサーバの情報と、リカバリ担当プリントサーバとを含むリカバリ情報をDBサーバに保存する手段と、
   プリントサーバ（１０１〜１０３）は、リカバリ処理開始時に、ＤＢサーバ上のリカバリ情報を参照し、リカバリ対象のアプリサーバが担当するＤＢデータを検出して処理を引き継ぐ手段と、
   プリントサーバ（１０１〜１０３）は、ＤＢサーバ（１０４）上のリカバリ情報に含まれるリカバリ対象のプリントサーバが担当のＤＢデータが検出できない(存在しない)場合に、リカバリ情報からリカバリ対象のアプリサーバの情報を削除する手段と、
   を有することを特徴とする印刷システム。