以下、図面を参照して、本発明の実施形態を説明する。
図1に、実施形態の印刷制御システムの一例を示す。図1に例示するシステムは、複数のサーバ100A,100B,・・・、データ記憶装置102、配置管理装置104、ロードバランサ106、及び複数の実プリンタ108,・・・を有する。
サーバ100A,100B,・・・(以下、区別の必要がない場合は「サーバ100」と総称)は、プログラムを実行可能なコンピュータである。ここでいうコンピュータは、物理的に存在する装置に限定されるものではなく、仮想マシンであってもよい。例えば、サーバ100は、クラウドコンピューティングサービス(以下単に「クラウド」と呼ぶ)が提供する仮想マシン(VM:Virtual Machine)であってもよい。以下では、サーバ100がクラウド上の仮想マシンである場合を代表例にとって説明する。ただし、本実施形態の仕組みは、サーバ100が物理的に実在する装置である場合にも適用可能である。
サーバ100は、ユーザ(クライアント)に対して印刷サービスを提供するプログラムを実行する。サーバ100A,100B、・・・がこのプログラムを実行することにより実現される装置を、図1では印刷サービス110A、110B、・・・(以下、区別の必要がない場合は「印刷サービス110」と総称)として示している。
図示の例では、印刷サービス110は、1以上の論理プリンタ112及び1以上の物理プリンタ114を生成し、動作させることが可能である。論理プリンタ112及び物理プリンタ114は、印刷システムの業界標準の1つであるDPA(Document Printing Application)(ISO/IEC 10175)に規定された仮想プリンタのオブジェクトである。これら2種類のプリンタ・オブジェクトにより印刷のための制御処理を分担する。大略的には、論理プリンタ112はユーザからの印刷指示の受付処理を行い、物理プリンタ114は、その印刷指示に応じた印刷のために実プリンタ108に印刷データを送信し印刷処理させる。実プリンタ108は受信した印刷データに基づき用紙等の媒体に対して実際に印刷処理を行う、物理的に実在するプリンタである。論理プリンタ112と物理プリンタ114の機能分担は、実施形態の制御にとって本質的なことではないので、これ以上の説明は省略する。なお、以下では、論理プリンタ112と物理プリンタ114の区別の必要がない場合は、それらを仮想プリンタと総称する。
物理プリンタ114は、1以上の実プリンタ108に対応づけられており、それら対応する1以上の実プリンタ108を制御して印刷処理を実現する。図示例では各物理プリンタ114はそれぞれ1つの実プリンタ108に対応づけられているが、これはあくまで一例にすぎない。
論理プリンタ112は、1以上の物理プリンタ114に対応づけられている。図1では、互いに対応する論理プリンタ112と物理プリンタ114との間を線で結ぶことで、その対応関係を示している。ここでいう「対応関係」は、一方が他方を制御又は管理するといった主従関係があることまでは要求しない(もちろんそのような主従関係がある実装形態も考え得る)。この「対応関係」は、論理プリンタ112が受け付けた印刷指示に応じた印刷処理をその論理プリンタ112と線でつながる物理プリンタ114が担当するという、同じ印刷指示についてのジョブを担当するという意味での対応関係である。なお、ここでいうジョブとは、印刷制御システム又はその各構成要素が、クライアントから受けた印刷指示に応じて行う処理のことである。
なお、印刷サービス110は、図1に示した論理プリンタ112及び物理プリンタ114の他に、論理プリンタ112及び物理プリンタ114による印刷制御処理を管理するための各種機能を有するが、これについては後で説明する。
データ記憶装置102は、サーバ100A,100B,・・・上の印刷サービス110A、110B、・・・によって共用される記憶装置である。各印刷サービス110(及び当該サービスが管理する論理プリンタ112,物理プリンタ114等のオブジェクト)は、クライアントからの印刷指示に応じた印刷を実現するために必要なデータをデータ記憶装置102に格納する。また各印刷サービス110は、データ記憶装置102に記憶されたデータを必要に応じて参照し、印刷を実現するための処理を実行する。
データ記憶装置102に記憶されるデータには、各論理プリンタ112や各物理プリンタ114を定義する定義情報(後述するプリンタテーブル)が含まれる。
また、データ記憶装置102に記憶されるデータには、論理プリンタ112や物理プリンタ114が実行しているジョブの処理情報が含まれる。ジョブの処理情報とは、論理プリンタ112又は物理プリンタ114が当該ジョブのための一連の処理の中で処理の対象とする情報、処理の途中又は最終の結果として出力する情報、及びそれら一連の処理の管理のための情報等の総称である。なお、一連の処理の途中の処理結果は、その一連の処理の中の後の処理での処理対象となる場合もある。
例えば、クライアントから印刷指示に付随して受け取った印刷データ(印刷すべき文書をPDL等で記述したデータ)は、ジョブにおける処理の対象となるデータであり、ジョブの処理情報に含まれる。なお、PDLとはPage Description Languageの略であり、ページ記述言語を意味する。PDF(Portable Document Format)もPDLの一種として用いられる。
また、印刷サービス110がPDLで記述された印刷データを解釈することにより生成される印刷可能データは、ジョブの一連の処理のうちの解釈処理の結果のデータであると共に、実プリンタ108での印刷処理の対象となるデータであり、ジョブの処理情報に含まれる。この印刷可能データは、実プリンタ108で印刷処理が可能なデータ形式であればよく、実プリンタ108で解釈可能なPDL形式のデータやラスター画像データ等のデータである。また、印刷サービス110がPDLの印刷データをいったん中間形式のデータに変換し、その中間形式データをラスター画像データに変換する方式を採用している場合、中間形式データもジョブの処理情報の一例である。なお、中間形式とは、印刷対象の文書をPDLとラスター画像の中間の粒度で表現するデータ形式であり、例えばディスプレイリストがその一例である。
また、クライアントから印刷指示に伴って受け取った印刷属性(印刷部数、用紙サイズ、片面印刷か両面印刷か、カラー印刷かモノクロ印刷か等)及びその印刷指示のためのジョブに付与した一意なジョブID(識別情報)等を含むジョブの管理情報も、データ記憶装置102に記憶される処理情報の一例である。
データ記憶装置102に記憶されるジョブの処理情報は、ジョブの進捗に合わせて更新されるようにしてもよい。データ記憶装置102内のジョブの処理情報の更新は、例えば、別のサーバ100へと移動(配置換え)されるために論理プリンタ112や物理プリンタ114等の仮想プリンタが停止される際に実行される。例えば、仮想プリンタが上位の管理装置(例えば配置管理装置104)からの命令に応じて停止する場合に、それまで実行していた処理の結果のデータ(例えば停止指示を受けた時点でPDLデータを中間形式データへ変換し終わっていればその中間形式のデータ)をデータ記憶装置102に格納する等である。
また、ジョブを構成する各処理が完了するごとに、完了した処理の処理結果を反映するようデータ記憶装置102内の当該ジョブの処理情報を更新するという方式も可能である。例えば、クライアントからPDLデータを受け付ける処理が完了した段階、PDLデータを中間形式データに変換する処理が完了した段階、及び中間形式データを(またはPDLデータを直接)印刷可能データに変換する処理が完了した段階等といった段階ごとに、データ記憶装置102に対してそれら各段階の処理結果のデータ(PDL、中間形式、ラスター画像その他の印刷可能データなど)を格納する等である。また、既に受付済みのジョブについての印刷属性の変更指示をクライアントから受け取った場合に、その指示に応じて、データ記憶装置102内の当該ジョブの管理情報を変更するようにしてもよい。
データ記憶装置102は、1つの例では、クラウド上のVM(仮想マシン)又は、クラウド上のストレージサービスとして実現される。また、データ記憶装置102は、物理的に実在する装置であってももちろんよい。データ記憶装置102としては、冗長化技術等により高い故障耐性を持つものを用いてもよい。
配置管理装置104は、各サーバ100に対する仮想プリンタ(すなわち論理プリンタ112及び物理プリンタ114)の配置を管理する。例えば、配置管理装置104は、各サーバ100の負荷状況を監視し、過負荷が懸念されるサーバ100を検知した場合に、そのサーバ100上で動作する仮想プリンタを、過負荷の懸念がない別のサーバ100に移動させる処理を行う(詳細は後述)。
また、配置管理装置104は、各仮想プリンタがどのサーバ100上に存在するかに関する問合せに応答する機能を有していてもよい。
配置管理装置104は、各サーバ100とは独立したVM(仮想マシン)上に構成してもよいし、それらサーバ100のいずれかに同居させてもよい。また、配置管理装置104は、物理的に実在する装置であってももちろんよい。
ロードバランサ106は、クライアントから本システムに対して到来する各種の要求を、本システム内の複数の印刷サービス110に振り分けることで、それら複数の印刷サービス110(ひいてはそれら印刷サービス110をホストするサーバ100)の間の負荷分散を実現する。ロードバランサ106が用いる振り分け方式には、特に限定はない。ラウンドロビン方式等の単純な方式を用いてもよいし、より高度な方式を用いてもよい。
例えば、クラウドサービスが提供する一般的なロードバランサは、クラウド上に実現される個別のアプリケーションシステム(本実施形態では、印刷制御システム)に依存しない振り分け方式を採用している。すなわち、そのような一般的なロードバランサは、アプリケーションシステムにおいてやりとりされる要求の中身を考慮せずに、ラウンドロビン等の単純な方式で振り分けを行う。例えば、クライアントから到来する印刷指示のデータは、その指示の宛先である論理プリンタ112を特定する情報を含んでいるが、そのような一般的なロードバランサは、印刷指示の中身である宛先の情報を見ず、その宛先情報とは無関係にその印刷指示の転送先を決定する。したがって、印刷サービス110(又はその中の論理プリンタ112等の要素)が受け取った要求が自分宛ではなく、他の印刷サービス110等に宛てたものである場合もある。自分宛でない要求を受け取った印刷サービス110は、配置管理装置104への問合せによりその要求の宛先が存在するサーバ100を特定し、特定したサーバ100に対してその要求を転送する。
次に、図2を参照して、本実施形態のシステムでの仮想プリンタの移動処理について説明する。
前述の通り、いずれかのサーバ100が過負荷になりそうになった場合、本実施形態では、配置管理装置104がその事態を検知し、過負荷になりそうなサーバ100上にある仮想プリンタ(論理プリンタ112又は物理プリンタ114)を別のサーバ100に移動させる。
図2の例において、サーバ100Aに過負荷の懸念が発生したとする。配置管理装置104は、各サーバ100の負荷を監視しており、この負荷監視によりその懸念の発生を検知すると、サーバ100Aの処理負荷を軽減するよう、仮想プリンタ群の再配置を計算する。再配置の計算方式は特に限定されない。仮想プリンタを移動させる処理は、再配置の計算にどのような方式を用いるかに依存しない。図2の例では、再配置の計算により、過負荷の懸念が生じたサーバ100A上の物理プリンタ114aを別のサーバ100Bに移動させるという再配置が決定されたものとする。
(1)この場合、配置管理装置104は、まずサーバ100A上の物理プリンタ114aに対して停止指示を送る。この停止指示には、物理プリンタ114aを特定する識別情報(プリンタ名又はプリンタID)が含まれる。(2)停止指示を受けた物理プリンタ114aは、現在実行中のジョブがあれば、そのジョブについてそれまでに完了した処理の結果の情報を、当該ジョブの処理情報としてデータ記憶装置102に格納(又はその処理結果を、データ記憶装置102内のそのジョブ処理情報に反映)する。(3)このデータ格納処理の後、物理プリンタ114aは停止し、それまで使用していたリソース(メモリ領域等)を解放する。なお、印刷サービス110がジョブ中の各処理が完了するごとに処理結果をデータ記憶装置102に格納又は反映していく構成の場合、停止指示を受けた際のデータ記憶装置102への処理情報の格納又は反映は省略してよい。停止指示の際に実行している処理段階の直前の処理段階までの処理結果がデータ記憶装置102に記憶されているので、それを参照することで停止の直前の処理の完了時点の状態から処理を再開できるからである。
(4)物理プリンタ114aへ停止指示を発した後(例えば、更に印刷サービス110A上の物理プリンタ114aの停止及びリソース解放を確認した後)、配置管理装置104は、物理プリンタ114aの移動先であるサーバ100B上の印刷サービス110Bに対し、物理プリンタ114aの起動を指示する。この指示には、物理プリンタ114aの識別情報が含まれる。印刷サービス110Bは、その起動指示に従い、その物理プリンタ114aの定義情報をデータ記憶装置102から取得し、取得した定義情報に従って物理プリンタ114aを実体化(すなわち物理プリンタ114aとして機能できる状態とすること)する。(5)実体化された物理プリンタ114aは、データ記憶装置102から、自分が停止前に実行していたジョブの処理情報(停止までの処理結果を反映したもの)を取得し、その処理情報を用いることで、停止前まで実行していたジョブの処理を続行する。なお、サーバ100A上の論理プリンタ112aは、物理プリンタ114aがサーバ100Bに移動した後、サーバ間での通信を介して、サーバ100B上の物理プリンタ114aに対して印刷実行を指示することができるので、物理プリンタ114a(及びそれに対応する実プリンタ108)を出力先とするジョブの受付を止める必要がない。
以上に説明したように、本実施形態のシステムでは、あるサーバ100A上の物理プリンタ114aがジョブを実行中でも、その物理プリンタ114aを別のサーバ100Bに移動させ、移動先でそのジョブを続行させることができる。
図2の例では、物理プリンタ114を移動させる場合を説明したが、論理プリンタ112をサーバ間で移動させる場合でも同様のことが可能である。
次に、図3を参照して、印刷サービス110及びデータ記憶装置102の内部構成の一例を説明する。
印刷サービス110は、論理プリンタ管理部1102、論理プリンタ112、物理プリンタ管理部1104、物理プリンタ114、ジョブ管理部1106、ジョブスケジューリング部1108、イベント通知部1110、サーバ間通信制御部1112、及びクライアント通信部1114を有する。
論理プリンタ管理部1102は、個々の論理プリンタ112の実体化処理、解放処理を行うと共に、それら論理プリンタ112を管理する。論理プリンタ管理部1102は、データ記憶装置102に記憶されている論理プリンタテーブル1021に従い、各サーバ100(印刷サービス110)上の各論理プリンタ112を管理する。
論理プリンタ管理部1102に実体化された各論理プリンタ112は、例えば、ジョブの受付処理を行う。すなわち、クライアントから送られてくる印刷指示は、宛先の論理プリンタ112の指定を含んでおり、宛先の論理プリンタ112は、その印刷指示を受け取り、その印刷指示に対応するジョブを生成する。ジョブの生成では、ジョブ管理部1106と協働して、そのジョブのIDや印刷属性などを含むジョブの管理情報を生成してデータ記憶装置102に格納し、その管理情報がこの印刷制御システム内(他の印刷サービスも含む)の様々な要素(当該論理プリンタ112自身や、関連する物理プリンタ114、ジョブ管理部1106等)から参照できるようにする。
物理プリンタ管理部1104は、個々の物理プリンタ114の実体化処理、解放処理を行うと共に、それら物理プリンタ114を管理する。物理プリンタ管理部1104はデータ記憶装置102に記憶されている物理プリンタテーブル1022に従い、各サーバ100上の各物理プリンタ114を管理する。
物理プリンタ管理部1104により実体化された各物理プリンタ114は、この例では、対応する実プリンタ108の状態の監視、その実プリンタ108の制御、印刷対象のPDLデータの中間データや印刷可能データへの変換、ジョブの状態管理等を行う。
ジョブ管理部1106は、ジョブIDを発行したり、クライアントからの更新指示に応じてジョブ管理情報を更新したり、削除指示に応じてジョブを削除したりする等、ジョブ全般に関する管理を行う。
ジョブスケジューリング部1108は、物理プリンタ114が印刷可能となった時に、データ記憶装置102内のジョブテーブル1026に登録されているジョブ群から、物理プリンタ114に対してジョブを割り当てる。物理プリンタ114にジョブを割り当てるのは、その物理プリンタ114が管理する実プリンタ108が次のジョブを印刷可能な状態であり、かつそのジョブが割り当て待ち状態である時である。
イベント通知部1110は、印刷サービス110の内部で発生したイベントを、サーバ間通信制御部1112を介して、他のサーバ100内の印刷サービス110に通知する。イベントの通知先とするサーバ100の範囲は、イベントの種類に応じて決まる。
サーバ間通信制御部1112は、サーバ100間、及び、サーバ100と配置管理装置104その他の情報処理装置との間、の通信(メッセージング)を制御する。
クライアント通信部1114は、クライアントからの各種指示、例えば印刷指示、印刷状態取得指示、サーバ制御指示等、をネットワーク経由で受け付け、プロトコル解析を行う。クライアントから受け付ける指示データは、LPR(Line PRinter daemon protocol)やIPP(Internet Printing Protocol)等の一般的な印刷プロトコルや、独自の管理プロトコルに従ったものでよい。クライアント通信部1114は、プロトコル解析の結果に従い、サーバ100(印刷サービス110)内の各要素に対して指示を割り当てる。
データ記憶装置102は、論理プリンタテーブル1021、物理プリンタテーブル1022、対応づけテーブル1023、サーバテーブル1024、配置テーブル1025、ジョブテーブル1026、及び印刷データ1027を記憶している。以下、図4〜図9を参照して、それら各テーブルの具体例を説明する。
論理プリンタテーブル1021は、印刷制御システム内の各論理プリンタ112の定義情報を保持する表である。図4に論理プリンタテーブル1021のデータ内容の一例を示す。図4に示すように、論理プリンタテーブル1021には、論理プリンタごとに、その論理プリンタのプリンタ名(識別情報)、アクセス制御情報、受付プロトコル、配置先サーバ、及び状態といった項目が登録される。項目「アクセス制御情報」は、その論理プリンタに対するユーザからのアクセスを制御するために用いる情報である。アクセス制御情報としては様々な形の情報を用いることができる。例えばその論理プリンタを利用可能なユーザやグループの識別情報(ID)のリスト(アクセス制御リスト)であってもよいし、その論理プリンタにアクセス可能なユーザを認証する認証方法(例えばパスワード認証)を規定する情報であってもよい。図示例では、アクセス制御情報として、論理プリンタを利用可能なグループのIDのリストが登録されている。項目「受付プロトコル」は、その論理プリンタが受け付け可能なプロトコルを示す情報である。なお、1つの論理プリンタが受付可能なプロトコルは1つに限られるものではなく、複数であってもよい。項目「配置先サーバ」は、その論理プリンタが現在配置されているサーバ100の識別情報である。項目「状態」は、その論理プリンタの状態を示す情報である。論理プリンタの状態には、例えば「Ready」(サーバ上に実体化された状態)、「Stand-by」(停止してリソースを解放した状態)がある。
物理プリンタテーブル1022は、印刷制御システム内の各物理プリンタ114の定義情報を保持する表である。図5に物理プリンタテーブル1022のデータ内容の一例を示す。図5に示すように、物理プリンタテーブル1022には、物理プリンタごとに、その物理プリンタのプリンタ名、実プリンタ、プロトコル、配置先サーバ、及び状態といった項目が登録される。項目「実プリンタ」は、その物理プリンタが管理している実プリンタ108を特定する情報である。図示例では、実プリンタ108を特定する情報として、その実プリンタ108のIPアドレスが用いられている。物理プリンタが複数の実プリンタ108を管理する場合、項目「実プリンタ」には、それら複数の実プリンタの情報が登録される。項目「プロトコル」は、その物理プリンタが受け付け可能なプロトコルを示す情報である。なお、1つの物理プリンタが受付可能なプロトコルは1つに限られるものではなく、複数であってもよい。項目「配置先サーバ」は、その物理プリンタが現在配置されているサーバ100の識別情報である。項目「状態」は、その物理プリンタの状態を示す情報である。物理プリンタの状態には、論理プリンタの場合と同様、「Ready」、「Stand-by」等がある。なお、物理プリンタの状態の種類と論理プリンタの状態の種類は、必ずしも同じでなくてよい。
対応づけテーブル1023は、論理プリンタ112と物理プリンタ114の対応関係の情報を保持する。対応付けテーブル1023のデータ内容の一例を図6に示す。図に例示した対応付けテーブル1023には、論理プリンタ112のプリンタ名(ID)に対応づけて、その論理プリンタ112に対応づけられた物理プリンタ114のリストが登録されている。論理プリンタ112と物理プリンタ114との対応関係は一対一対応に限らない。1つの論理プリンタ112に対して複数の物理プリンタ114が対応づけられる場合もあるし、その逆もある。ジョブスケジューリング部1108は、対応付けテーブル1023を参照し、論理プリンタ112が受け付けた印刷ジョブを、その論理プリンタ112に対応する物理プリンタ114に割り当てる。
サーバテーブル1024は、印刷制御システム内の利用可能なサーバ100の情報を管理するテーブルである。図7に示すように、サーバテーブル1024には、サーバ100毎に、そのサーバの識別情報(サーバID)、IPアドレス、状態、CPU性能、メインメモリ容量が登録されている。
IPアドレスの情報は、サーバ100間での通信を行う場合に利用される。IPアドレスは、そのサーバと通信するために用いられる情報の一例であり、同様の役割を果たす別の情報に代えてもよい。項目「状態」は、当該サーバの現在の状態を示す情報である。サーバの状態としては、例えば「稼働中」、「停止中」がある。CPU性能の項目は、当該サーバが有するCPUの性能(例えばクロック数、コア数)を示す。メインメモリ容量の項目は、当該サーバが持つメインメモリの容量を示す。CPU性能及びメインメモリ容量は、当該サーバの処理能力を表す指標値の一例である。配置管理装置104にて論理プリンタ112や物理プリンタ114の再配置が計算される際、これら処理能力の情報が利用される。CPU性能及びメインメモリ容量に代えて、サーバの処理能力を示す別の種類の情報を用いてもよい。例えばIaaS(Infrastructure as a Service)タイプのクラウドサービスが提供する仮想マシン(VM)をサーバ100として用いる場合、クラウドサービスが設定している仮想マシンの性能レベルの情報を用いることもできる。仮想マシンの性能レベルに応じて課金が設定されている場合には、性能レベルの情報は、印刷制御システムを構成するための仮想マシン群のコストを計算するのに用いたり、処理負荷の増減に応じてどの性能レベルの仮想マシンを追加又は削除(停止)するかを判定するのに用いたりすることもできる。
配置テーブル1025は、仮想プリンタ(論理プリンタ112及び物理プリンタ114)がどのサーバ100に配置されているかを管理するテーブルである。配置テーブル1025のデータ内容の一例を図8に示す。図に例示した配置テーブル1025には、プリンタタイプ、プリンタID及びサーバIDの項目がある。プリンタタイプは、当該仮想プリンタが論理プリンタ、物理プリンタのどちらのタイプであるかを示す。プリンタ名は、当該仮想プリンタの名前(ID)である。サーバIDは、当該仮想プリンタが配置されているサーバの識別情報である。配置テーブル1025は、後述する配置管理装置104によるサーバ配置の決定に従って更新される。なお、この配置テーブル1025の更新に合わせて、論理プリンタテーブル1021及び物理プリンタテーブル1022における配置先サーバの情報も更新される。
ジョブテーブル1026は、印刷指示に応じて生成されたジョブの管理情報を保持するテーブルである。図9に例示するジョブテーブル1026は、ジョブID、ジョブ名、状態、受付プリンタ、データパス、部数、ステープル、カラーの項目を含んでいる。
項目「ジョブID」は、ジョブ管理部1106により付与された当該ジョブの識別情報である。項目「ジョブ名」は、当該ジョブの名称であり、例えば印刷指示を発行したユーザやクライアントが付与したものである。
項目「状態」は、当該ジョブの状態を示す情報である。ジョブの状態には、例えば、「受付中」、「アサイン(割当)待ち」、「アサイン済み」、「処理中」、「処理済み」等がある。「受付中」は、論理プリンタ112が印刷指示を受け付けてから、受付処理(印刷指示に応じたジョブの管理情報をジョブテーブル1026に登録する処理)を完了するまでの状態である。「アサイン待ち」は、論理プリンタによる印刷指示の受付処理(ジョブの作成)が終わってから、そのジョブが物理プリンタ114に割り当てられるまでの間の状態である。「アサイン済み」は、ジョブが物理プリンタ114に割り当てられた後、物理プリンタ114によりそのジョブの処理が開始されるまでの状態である。「処理中」は、物理プリンタ114がそのジョブを処理している状態である。なお、この「処理中」の状態を、更に細分化してもよい。例えば、中間形式に変換中の状態、中間形式への変換が完了した後ラスター形式や実プリンタが解釈できるPDL形式の印刷可能データへ変換しつつ実プリンタ108にて印刷している状態、等に分割する等である。「処理済み」は、物理プリンタ114によるそのジョブの処理が完了した後の状態である。
ジョブテーブル1026の項目「データパス」は、当該ジョブの印刷データ1027の記憶装置102内での保存場所を示す情報である。図示例では項目「データパス」には、この印刷制御システムにおける印刷データの保存場所に対する相対パスが登録されている。例えば、この印刷制御システムにおける印刷データの保存場所が、データ記憶装置102内のディレクトリ「\\fileservere\c$datapath\」であるとする場合、「ジョブ1」の印刷データは「\\fileservere\c$datapath\0000001」に格納されている。
項目「部数」、「ステープル」、「カラー」は、当該ジョブに対する印刷部数、ステープル止めの有無、及びカラー/白黒のモードの指定値を示す。これらは、そのジョブに対して指定された印刷属性の一例として図示したものであり、他の印刷属性がジョブテーブル1026に登録されてももちろんよい。
データ記憶装置102に記憶される印刷データ1027は、例えば、クライアントから印刷指示と共に受け取ったPDLデータである。また、物理プリンタ114によるPDLデータの中間形式データや印刷可能データへの変換が行われる毎に、データ記憶装置102に記憶される印刷データ1027をその変換結果のデータ(中間形式又は印刷可能データ)に置き換えてもよい。また、このように置き換える代わりに、各段階の変換結果のデータをデータ記憶装置102に追加記憶してもよい。
以上、データ記憶装置102内に記憶される情報の例について説明した。印刷サービス110や配置管理装置104等のシステム構成要素は、データ記憶装置102及びその中の各情報の所在場所を示す情報(IPアドレスやURL等)を有しており、処理を進める際、必要に応じてデータ記憶装置102内の情報を参照したり、データ記憶装置102内の情報を更新したり、データ記憶装置102内に新規情報を登録したりする。
図3の例では、論理プリンタテーブル1021〜印刷データ1027のすべての情報が1つのデータ記憶装置102に記憶されているが、これは必須のことではない。それら各情報が印刷サービス110や配置管理装置104により共有されている形であれば、それら個々の情報がネットワーク又はクラウド内の別々の場所に格納されていてもよい。
次に、配置管理装置104の機能について説明する。配置管理装置104は、サーバ状態監視機能及び仮想プリンタ再配置機能を有する。なお、これら2つの機能が一体となっている必要は必ずしもなく、それら2つの機能を別々の装置として構成するようにしてもよい。
サーバ状態監視機能は、本システム内の各サーバ100の死活(稼働中か停止中か)や処理負荷状態を監視する機能である。配置管理装置104は、例えば定期的に通信パケットが届いているかを確認するpingコマンドを発行する等により、サーバテーブル1024(図7)に登録されている各サーバ100の稼働状態を監視し、サーバテーブル1024の「状態」項目を更新する。各サーバ100の状態監視のための手段には、pingに限らず、従来公知の様々な手法を用いることができる。例えば、各サーバ100のCPU使用率やメモリ使用率、ディスクIO(入出力)状況、ネットワークIO状況等の情報を取得し、これらから各サーバ100の負荷状況を判断してもよい。
この状態監視により、サーバ100の状態に特定の条件を満たす変化が生じたことを検知した場合、配置管理装置104(状態監視機能)は、仮想プリンタの再配置処理のトリガーを発生させる。このトリガー発生は、配置管理装置104が有するトリガーテーブル(図10参照)に従って行われる。
トリガーテーブルには、トリガーの種類毎に、そのID、トリガー名、トリガー条件、トリガー通知データの各項目を含む。ID、トリガー名は、それぞれそのトリガーの識別情報、名称である。トリガー条件は、そのトリガーを発生させるための条件である。トリガー通知データは、そのトリガーと共に通知するパラメータ情報である。例えば、トリガー名「VM負荷増」というトリガーは、VM(仮想マシンすなわちサーバ100)のCPU使用率が80%を越える状態が1分(「1min」)以上続いた場合に生成される。このトリガーには、そのVM(サーバ)のサーバIDがパラメータとして付随する。また、「VM状態変更」というトリガーは、VMの状態変更が発生した場合、すなわちそのVMが稼働中から停止中、又はその逆、に変化した場合に生成される。このトリガーには、そのVMのサーバIDと、変更後の状態(例えば前回の監視時は稼働中であったVMが今回の監視で停止中であることが分かった場合には「停止中」)がパラメータとして付随する。
図10に例示したトリガーはあくまで一例にすぎない。他のトリガーを用いてももちろんよい。
図11に、発行されたトリガーのデータ内容の例を示す。この例は、サーバIDが「サーバ1」であるVMが停止したことを検知した場合に生成されるトリガーを示す。このトリガーデータは、トリガー名「VM状態変更」を含むと共に、サーバID「サーバ1」及び状態「停止中」というパラメータを含む。なお、トリガーデータに含まれる項目「要求者」は、このトリガーの生成を要求した要求者(ユーザ、又はシステム中のいずれかの管理機能)を示す項目である。トリガーの発生は、(システム管理者等があらかじめ定めた)トリガー条件に応じて自動的に行われるので、この例では「要求者」の値は「Administrator」(管理者)となっている。
次に、配置管理装置104の再配置機能について説明する。再配置機能は、システムを構成するサーバ100群に対して仮想プリンタ群を再配置(すなわち配置の変更)する機能である。あるサーバ100上にある論理プリンタ112又は物理プリンタ114を別のサーバ100に移動させる処理は、この再配置機能により実行される。再配置機能は、配置ポリシー情報を参照して、仮想プリンタ群の再配置を行う。
配置ポリシー情報の一例であるポリシーテーブルを図12に例示する。ポリシーテーブルには、ポリシー毎に、そのポリシーのID、そのポリシーに対応するトリガーの名称及びトリガー条件、及びそのポリシーの内容が登録される。同じトリガーについては、ポリシーテーブルとトリガーテーブルとで同じトリガー名(及びトリガー条件)が用いられる。ポリシーは、仮想プリンタ群の再配置の方針を示す情報である。ポリシーテーブルは、印刷制御システム内のサーバ状態監視機能以外の要素が発するトリガーに対応するポリシー(例えば「論理プリンタ作成」、「物理プリンタ作成」、「プリンタ削除」も登録されている。
例えばID「1」に対応するポリシーは、システム管理者やユーザから配置管理装置104に対して論理プリンタ112の新規作成(すなわち新たな論理プリンタ112の追加)が指示された場合に用いられる。このポリシーでは、印刷制御システム内にある稼働中の各サーバ100(VM)が持つ論理プリンタ112の数ができるだけ「均等」になるよう、新たに追加された論理プリンタ112の配置先とするサーバ100を決める。例えば、各サーバ100の性能が同等である場合、配置されている論理プリンタ112の数が最も少ないサーバ100に対してその新たな論理プリンタ112を配置する。この配置決定の際、配置管理装置104は、配置テーブル1025を参照することで、稼働中の各サーバ100に配置されている論理プリンタ112の数を取得する。なお、論理プリンタ112の新規作成時には、システム管理者やユーザは、その論理プリンタ112に対応づける1以上の物理プリンタ114を指定する。サーバ100毎に性能が異なる場合には、各サーバ100の性能に例えば比例した数ずつ論理プリンタ112を配置することを、ポリシーにおける「均等」配置としてもよい。
ID「3」のポリシーは、システム管理者やユーザから特定の仮想プリンタ(論理又は物理)の削除を指示された場合のポリシーである。この場合、特別のポリシーはなく、指示通りに削除対象の仮想プリンタを削除する。
ID「4」のポリシーは、トリガー「VM負荷増」が発せられた場合に用いられる。このポリシーに従った再配置処理では、印刷制御システムに対して新たにVMを1つ追加する。そして、この新規追加されたVMを含む現在稼働中のすべてのVM群に対して、各VMが有する論理プリンタ112及び物理プリンタ114の数がそれぞれ(各VMの性能も考慮して)「均等」になるよう、論理プリンタ112群及び物理プリンタ114群をVM群に対して再配置する。具体的には、例えば、「均等」の条件に従って、新たに追加するVMに対して配置する論理プリンタ112及び物理プリンタ114のそれぞれの数を求める。そして、既に稼働中の他のVMのうち、有する論理プリンタ112又は物理プリンタ114の数が性能に比して多いVMから優先的に、そのVM上の論理プリンタ112又は物理プリンタ114を新たに追加したVMに移動させることで、その新たに追加したVMに配置された論理プリンタ112及び物理プリンタ114の数が、他のVMと「均等」になるようにする。
ID「5」の「VM負荷減」の場合のポリシーは、「VM負荷増」の場合とは逆に、稼働中のVMのうちの1つを停止させ、残ったVM群に対し、論理プリンタ112群及び物理プリンタ114群を「均等」に再配置する。具体的には、停止させたVMに配置されていた論理プリンタ112(又は物理プリンタ114)を、配置されている論理プリンタ112(又は物理プリンタ114)の数が性能に比して最も少ないVMから優先的に割り当てていくことで、残ったVMにおける論理プリンタ112(又は物理プリンタ114)が「均等」になるようにする。
図12に示したポリシーはあくまで一例にすぎない。他のポリシーも考えられる。
例えば、システム管理者が、特定のVMの処理負荷を低減させるなどの目的のために、そのVM上の仮想プリンタを別のVMに移動するよう明示的な指示を行う場合がある。このVM移動指示を受けた場合のポリシーとして、次のようなものが考えられる。すなわち、移動元のVM上から論理プリンタ112(又は物理プリンタ114)を1つ削除するために、その削除することになる論理プリンタ112(又は物理プリンタ114)を、例えばその移動元のVMを除く稼働中のVM群の中で論理プリンタ112(又は物理プリンタ114)の数が(性能に比して)最も少ないVMに再配置し、再配置が完了すると移動元のVM上から論理プリンタ112を削除する。
また、上述の例ではVMの負荷の増加及び減少に応じたトリガーはそれぞれ1つずつであったが、負荷の増加及び減少をそれぞれ複数の段階に分け、段階毎に異なるポリシーに従って仮想プリンタ群の再配置を行うようにしてもよい。例えばVMの負荷の増加に関して「低レベル増加」(例えばCPU使用率が70%の状態が1分以上続いた場合)と「高レベル増加」(例えばCPU使用率が80%の状態が1分以上続いた場合)の2段階のトリガーを設けた場合を考える。この場合、例えば、「高レベル増加」に対応する再配置のポリシーとしては、上記ID「4」のポリシーと同様新規VMを追加して「均等」再配置を行うというポリシーを用い、「低レベル増加」の場合には、負荷の「低レベル増加」を示したVM上の仮想プリンタを1つ別のVMに移動させるというポリシーを用いる。
また、VMが障害等により停止した場合、そのVMに配置されていた仮想プリンタを別のVMに移動させることが必要になる。この事態は、VMの停止を示す「VM状態変更」トリガー(図10参照)の発生により検知できる。この事態が生じた場合の再配置ポリシーは、例えば、残りの稼働中のVM上の論理プリンタ、物理プリンタの数ができるだけ「均等」になるようにそれら仮想プリンタを再配置するというポリシーでよい。より具体的には、例えば、停止したVMに配置されていた論理プリンタ及び物理プリンタを、稼働中のVMのうち性能に比して論理プリンタ及び物理プリンタの配置数が少ないものから順に移動させるようにすればよい。
次に、図13を参照して、サーバ間通信制御部1112が通知するコマンドやイベントの具体例を説明する。図13に示すコマンド/イベントテーブルには、通知するコマンド又はイベント毎に、その名称(「通知コマンド/イベント名」)、その通知に付随するパラメータの内容(「送信パラメータの内容」)、通知先サーバ、説明が登録される。項目「通知先サーバ」は、そのコマンド又はイベントの通知先とするサーバ100(VM)を特定する情報である。図示例では、この項目の値として「特定」と「全て」が例示されている。「特定」は、そのコマンド又はイベントに対応する特定の1つのサーバ100にのみそのコマンド又はイベントを通知することを示す。「対応する特定の1以上のサーバ」は、ユーザから指定される場合もあれば、コマンド又はイベント毎にあらかじめ定められている場合もある。また「全て」は、印刷制御システム上の全てのサーバ100に対して通知を送ることを示す。項目「説明」は、その項目の意味の説明である。
図13の例において、コマンド「CreateJob」は、クライアントから受け取った印刷指示に応じた新規のジョブの生成を指示するコマンドである。クライアントからの印刷指示は、宛先の論理プリンタ112を特定しているので、このコマンドの「通知先サーバ」は、その宛先論理プリンタ112を有する特定の1つのサーバ100である。また、このコマンドは、クライアントから指定された印刷属性と共に通知される。また、イベント「JobUpdated」は、ジョブの情報が更新された時にイベント通知部1110により発せられるイベントであり、このイベントは「全て」のサーバに対して通知(いわばブロードキャスト)される。
他のサーバ100のサーバ間通信制御部1112からの通知を受け取ったサーバ間通信制御部1112は、その通知を、自サーバ100内の対象要素(その通知の中で指定されている)に対して振り分ける。
次に、クライアントから印刷指示を受け付けた時の本実施形態の印刷制御システムの動作を説明する。
クライアントから本システム宛に送られてきた印刷指示は、ロードバランサ106により受け取られる。ロードバランサ106は、ラウンドロビン等のあらかじめ定められた方式で決めた振り分け先のサーバ100(印刷サービス110)に対してその印刷指示を転送する。
転送された印刷指示を受け取った印刷サービス110が行う処理手順の例を図14に示す。この手順では、まずクライアント通信部1114が、受け取った印刷指示をプロトコル解析して指示の内容を認識する(S10)。印刷指示の解析結果の一例を図15に示す。印刷指示は、コマンド名が「CreateJob」であり、その指示を発したユーザのID(「要求者」)、その指示の「宛先」の論理プリンタのID、印刷データ、及び印刷属性(図15では「カラー指定」、「コピー部数」を例示)等の項目を含んでいる。なお、印刷指示に含まれる「印刷データ」は、実体的なデータ(PDLデータ又はそれを符号化したバイナリデータ)であってもよいし、ネットワーク上に保存されているその実体的なデータを指し示すデータ識別子(例えばURL)であってもよい。
次にクライアント通信部1114は、S10のプロトコル解析の結果に従い、その印刷指示を、その印刷サービス110内のその指示に対応する要素に割り当てる。印刷指示(コマンド「CreateJob」)の場合、割り当て先は論理プリンタ管理部1102である。
割り当てられた印刷指示を受け取った論理プリンタ管理部1102は、その印刷指示の「宛先」の論理プリンタ112が自印刷サービス110内にあるかどうかを判定する(S12)。論理プリンタ管理部1102は、自らが生成した各論理プリンタ112のIDを管理しているので、このID群を参照することで、印刷指示の宛先の論理プリンタ112が自サービス内にあるかどうかを判定できる。S12の判定結果がYesの場合、論理プリンタ管理部1102は、その宛先の論理プリンタ112に対して印刷指示の解析結果を渡し、ジョブの作成を要求する(S14)。
ジョブ作成要求を受けた論理プリンタ112は、ジョブ管理部1106に対して新規のジョブIDの発行を依頼する。ジョブ管理部1106は、その依頼に応じて新規のジョブIDを発行する。その論理プリンタ112は、そのジョブIDを受け取り、印刷指示の解析結果が示す「要求者」、「宛先」、及び印刷属性の各項目(「コピー部数」など)を、そのジョブIDに対応付けてジョブテーブル1026に登録する(それぞれ同テーブルの「ユーザ」、「受付プリンタ」、「部数」、・・・の項目に設定される)。また、論理プリンタ112は、印刷指示に含まれる印刷データをデータ記憶装置102に格納し、その格納場所を示す「データパス」をジョブテーブル1026に登録する。なお、印刷指示内で印刷データがデータ識別子で指示されている場合には、論理プリンタ112は、そのデータ識別子を解決することで、ネットワーク上の印刷データの保存場所を特定し、その保存場所からその印刷データを取得してデータ記憶装置102に格納する。この場合、そのデータ識別子をジョブテーブル1026に記録しておいてもよい。
論理プリンタ112は、ジョブ作成(すなわちジョブテーブル1026へのジョブ情報の登録)が成功したか失敗したかを示す結果情報を、論理プリンタ管理部1102に返す。ジョブ作成が成功した場合は、結果情報にはそのジョブのジョブIDも組み込まれる。論理プリンタ管理部1102は、その結果情報を、要求の割り当て元であるクライアント通信部1114に返す。クライアント通信部1114は、割り当てた印刷指示に対して論理プリンタ管理部1102から応答が到来すると、その応答が「ジョブ作成成功」であるか否(「失敗」)であるかを判定する(S16)。判定結果が「成功」の場合、クライアント通信部1114は、印刷指示の受付完了を示す通知をクライアントに返す(S18)。この通知には、作成されたジョブのジョブIDが含まれる。判定結果が「失敗」の場合、クライアント通信部1114は、印刷指示の受付が失敗したことを示すエラー通知をクライアントに返す(S20)。
S12の判定結果がNoの場合、すなわち印刷指示の「宛先」の論理プリンタ112が自サービス内にない場合、論理プリンタ管理部1102は、その印刷指示の解析結果をサーバ間通信制御部1112に渡す。サーバ間通信制御部1112は、「宛先」の論理プリンタ112の配置先サーバを問い合わせる問合せを配置管理装置104に送る(S22)。その問合せには、その論理プリンタ112のIDが含まれる。配置管理装置104は、その論理プリンタ112の配置先のサーバ100のサーバIDを配置テーブル1025又は論理プリンタテーブル1021から求め、求めたサーバIDを問合せ元のサーバ間通信制御部1112に応答する。この応答を受け取ったサーバ間通信制御部1112は、そのサーバIDに対応するサーバ100に対して、印刷指示の解析結果を含むメッセージを転送する(S24)。ここで、転送先のサーバ100のアドレスは、配置管理装置104又はサーバ間通信制御部1112がサーバテーブル1024から求めればよい。
S24でサーバ間通信制御部1112が他サーバへと送信するメッセージの例を図16に示す。この例は、「サーバ2」内にある「論理プリンタ2」を宛先とする印刷指示がロードバランサ106により「サーバ1」に振り分けられた場合に、「サーバ1」から「サーバ2」に送信されるメッセージの一例である。このメッセージのうち「通知ID」は、メッセージに対して一意的に付与される識別情報である。「送信元」及び「送信先」は、それぞれ、このメッセージの送信元及び送信先のサーバのIDを示す。TTL(Time To Live)はこのメッセージの生存期間(この期間の経過後はこのメッセージは無効となる)を示す。これらの情報の後に、図15に示したのと同様の印刷指示の解析結果が続く。
このような印刷指示の転送メッセージを受け取ったサーバ100(図16の例では「サーバ2」)のサーバ間通信制御部1112は、受け取ったメッセージ内のコマンドが「CreateJob」であることを認識し、そのメッセージ中の印刷指示の解析結果の部分を自印刷サービス110内の論理プリンタ管理部1102に割り当てる。この場合、その印刷指示の宛先は自印刷サービス110内に存在するので、論理プリンタ管理部1102はその解析結果をその宛先の論理プリンタ112に渡し、新たなジョブの作成を要求する(S26)。その論理プリンタ112は、その要求に応じてジョブの作成処理を行う。論理プリンタ112は、ジョブ作成が成功したか失敗したかを示す結果情報(成功の場合はジョブIDを含む)を、論理プリンタ管理部1102に返す。論理プリンタ管理部1102は、その結果情報を、要求の割り当て元であるサーバ間通信制御部1112に返す。サーバ間通信制御部1112は、割り当てた印刷指示に対して論理プリンタ管理部1102から結果情報が到来すると、その結果情報を含むメッセージその印刷指示の転送元のサーバ100(図16の例では「サーバ1」)に返す。このとき「サーバ2」から「サーバ1」に返されるメッセージの例を図17に示す。図17の例では、メッセージには、通知ID、送信元、送信先、TTLの後に、コマンド名、処理結果が続く。図17の例はジョブ作成が「成功」した場合なので、メッセージには、そのジョブのジョブIDも含まれている。この結果情報を受け取った転送元のサーバ100(「サーバ1」)のサーバ間通信制御部1112は、その結果情報を当該サーバ100内の論理プリンタ管理部1102に返し、論理プリンタ管理部1102はその結果情報をクライアント通信部1114に返す。そして、この結果情報を受け取ったクライアント通信部1114が前述のS16からS20の処理を実行する。
以上では、クライアントから印刷指示を受けた場合の処理を説明したが、クライアントからの指示コマンドにはこのほかにもいくつかのものがある。これらコマンドには、論理プリンタ管理部1102に振り分けるコマンド(前述したジョブ作成:CreateJobの他に、論理プリンター属性更新:SetLogicalPrinterAttributes等)、物理プリンタ管理部1104に振り分けるコマンド(物理プリンタ属性更新:SetPhysicalPrinterAttributes等)、ジョブ管理部1106に振り分けるコマンド(ジョブキャンセル:CancelJob、ジョブ属性更新:SetJobAttributes)などがある。クライアント通信部1114は、クライアントから受け取った指示コマンドを、自印刷サービス110内の、対応する振り分け先の要素に振り分ける。
次に、本実施形態の印刷制御システムにおけるジョブスケジューリングの流れを説明する。新たなジョブを発行した印刷サービス110内のジョブ管理部1106は、イベント通知部1110に対しジョブ更新イベント(「JobUpdated」)の発生を依頼する。この依頼を受けたイベント通知部1110は、サーバ間通信制御部1112を通して全てのサーバ100のイベント通知部1110に対してジョブ更新イベントを通知する。この通知のデータ内容の一例を図18に示す。図18の例は、「サーバ2」のイベント通知部1110が発したジョブ更新イベント通知メッセージの例である。図13に例示したように、ジョブ更新イベント(「JobUpdated」)の場合の通知の宛先は「全て」のサーバなので、この通知メッセージの宛先は全サーバを表す「ALL」となっている。このメッセージで通知されるコマンド(イベント)は「JobUpdated」である。このメッセージには、コマンド「JobUpdated」のパラメータとして、ジョブの更新内容を示すコード(この場合は新規ジョブの発行)(図示省略)と、そのジョブのジョブIDとが更に含まれる。
各サーバ100上の印刷サービス110内のジョブスケジューリング部1108は、その印刷サービス110内のイベント通知部1110に対してジョブ更新イベント通知が到来するのを監視している。ジョブスケジューリング部1108は、ジョブ更新イベント通知の到来を検知すると、ジョブスケジューリング処理、すなわちその印刷サービス110内の物理プリンタ114に対して割当可能なジョブを探して割り当てる処理、を行う。
ジョブスケジューリング処理では、ジョブスケジューリング部1108は、自印刷サービス110内の物理プリンタ114のうち、次のジョブを受付可能な物理プリンタ114を特定する。「次のジョブを受付可能」な状態の定義はシステムの運用次第である。物理プリンタ114がジョブを実行していない場合のみを「次のジョブを受付可能」な状態としてもよいし、物理プリンタ114が持つキュー(待ち行列)内の処理待ちのジョブの数があらかじめ定めた数以下である場合を「次のジョブを受付可能」な状態としてもよい。各物理プリンタ114が「次のジョブを受付可能」か否かは、例えば、ジョブスケジューリング部1108から各物理プリンタ114へ問い合わせることで判定すればよい。またこの代わりに、各物理プリンタ114が自律的にジョブ更新イベント通知を検知し、この検知に応じてそれぞれ「次のジョブを受付可能」か否かを判定し、その判定結果をジョブスケジューリング部1108に通知するようにしてもよい。
また、ジョブスケジューリング部1108は、データ記憶装置102内のジョブテーブル1026に対して、自印刷サービス110内の「次のジョブを受付可能」な各物理プリンタ114に割当可能なジョブを問い合わせる。
図19に、ジョブスケジューリング部1108がデータ記憶装置102に対して送る問合せの一例を示す。図19の例は、SQLで記述した問合せの例であり、ジョブテーブル1026(図9参照)の中から、「受付プリンタ」が「論理プリンタA」であり、「状態」が「アサイン待ち」であるジョブのジョブID(「jobid」)を求める問合せを示している。新たに作成されたジョブは、ジョブ作成処理が完了した時点で「アサイン(割当)待ち」の状態になっているので、この「アサイン待ち」状態のジョブの中から、「次のジョブを受付可能」な物理プリンタ114に割当可能なジョブを探すわけである。「受付プリンタ」が「論理プリンタA」であるという絞り込み条件は、自印刷サービス110内の「次のジョブを受付可能」な物理プリンタ114に対応する論理プリンタ112(この場合は「論理プリンタA」)を対応付けテーブル1023(図6)から検索することにより作成される。
自印刷サービス110内に「次のジョブを受付可能」な物理プリンタ114が複数ある場合、ジョブスケジューリング部1108は、それら物理プリンタ114毎に同様の問合せを行えばよい。
データ記憶装置102は、ジョブスケジューリング部1108からの問合せに示される条件に合致するジョブをジョブテーブル1026から検索し、そのようなジョブが見つかれば、そのジョブのジョブIDをジョブスケジューリング部1108に返す。このとき、データ記憶装置102は、ジョブテーブル1026(図9参照)におけるそのジョブIDに対応する「状態」を「アサイン待ち」から「アサイン済み」へと更新する。なお、「アサイン済み」への状態更新をこの段階で行う代わりに、この後、例えばそのジョブIDの割当を受けた物理プリンタ114がジョブテーブル1026へ状態更新を指示した際に行ってもよい。
一方、問合せの条件に合致するジョブが見つからなければ、データ記憶装置102は、問合せに係るジョブが「ない」ことを示す応答をジョブスケジューリング部1108に返す。この例では物理プリンタ114へのジョブの割当は早い者勝ちなので、新たに作成されたジョブが既に他のサーバ100上の物理プリンタ114に割り当てられてしまった場合、「ない」という応答が返ってくることになる。
問合せに対してデータ記憶装置102から、割当可能なジョブIDが返されてきた場合、ジョブスケジューリング部1108は、そのジョブIDを、その問合せに対応する「次のジョブを受付可能」な物理プリンタ114、に対して割り当てる。すなわち、そのジョブIDをその物理プリンタ114に渡す。ジョブIDの割当を受けた物理プリンタ114は、ジョブテーブル1026からそのジョブIDに対応する印刷データや印刷属性を取得し(このときそのジョブIDの「状態」を「アサイン済み」に更新してもよい)、これら取得したデータを用いて印刷のための処理を実行する。例えば、取得した印刷データをラスター形式等の印刷可能データに変換し、変換結果の印刷可能データを印刷属性と対応づけて、対応する実プリンタ108に送り、印刷を実行させる。物理プリンタ114は、対応する実プリンタ108に対してジョブを発行してからそのジョブの全ページの印刷結果の排紙が完了するまで、SNMP(Simple Network Management Protocol)等のプロトコルを用いて実プリンタ108での印刷処理の実行状況を監視する。
データ記憶装置102から問合せに係るジョブが「ない」ことを示す応答を受けた場合、ジョブスケジューリング部1108は、次回のジョブ更新イベントまで待機する。
なお、ジョブ更新イベントの通知を検知した時点で自印刷サービス110内に「次のジョブを受付可能」な物理プリンタ114が存在しない場合、ジョブスケジューリング部1108は、上述のジョブスケジューリング処理を中止し、次回のジョブ更新イベントまで待機する。
次に、この印刷制御システムにおける仮想プリンタ(論理プリンタ、物理プリンタ)のサーバ間移動の流れを詳しく説明する。
仮想プリンタのサーバ間移動は、配置管理装置104による仮想プリンタの「再配置」の一つの態様である。再配置の計算の結果、あるサーバ100上のある仮想プリンタを別のサーバ100に移動させることを決定した場合、配置管理装置104は、その仮想プリンタの移動元のサーバ100に対してその仮想プリンタの停止を要求する停止要求コマンドを送り、その仮想プリンタの移動先のサーバ100に対してその仮想プリンタの実体化を要求する実体化要求コマンドを送る。
例えば、「サーバ1」内の「物理プリンタ2」を「サーバ2」に移動させる場合、配置管理装置104は、図20に例示する停止要求コマンドを「サーバ1」に送り、その後図21に例示する実体化要求コマンドを「サーバ2」に送る。以下、図20及び図21の例に沿って説明する。
図20の例において、物理プリンタ114の停止を要求する停止要求コマンドは「StandbyPhysicalPrinter」であり、停止の対象となる物理プリンタ114のIDが「宛先」パラメータとして示される。一方、図21に例示するように、物理プリンタ114の実体化(起動)を要求する実体化要求コマンドは「LoadPhysicalPrinter」であり、実体化の対象となる物理プリンタ114のIDが「宛先」パラメータとして示される。仮想プリンタの「移動」の際に対になって発せられる停止要求コマンド及び実体化要求コマンドの「宛先」は同じ値(図示例では「物理プリンタ2」)である。
配置管理装置104から図20の停止要求コマンドを受け取ったサーバ100(「サーバ1」)の印刷サービス110は、その停止要求コマンドを物理プリンタ管理部1104に割り当てる。物理プリンタ管理部1104は、その停止要求コマンドの「宛先」の物理プリンタ114(「物理プリンタ2」)がその時点でジョブを処理中であれば、その物理プリンタ114に対してその処理の停止を指示し、その時点でのそのジョブの途中の処理結果をデータ記憶装置102内のジョブテーブル1026及び印刷データ1027に反映するよう指示する。例えば、物理プリンタ114が、PDLの印刷データを中間形式データへ変換する処理を完了し、その中間形式データを印刷可能データに変換する処理を完了しない段階で停止要求コマンドを受けた場合、データ記憶装置102の当該ジョブのIDに対応する印刷データ1027をその中間形式データに置き換える(または、PDLデータに加えてその中間形式データをジョブIDに対応づけて格納する)。また、別の例として、ジョブの途中のページまで実プリンタ108で印刷済みである場合、その状態をジョブテーブル1026等に反映させることも可能である。例えば、物理プリンタ114がそのジョブの第kページ(kは正の整数)までの印刷可能データの生成を完了し、対応する実プリンタ108が第mページ(mはk以下の正の整数)までの印刷出力を完了している場合、そのジョブIDに対応する印刷データ1027に対して、第(k−m+1)ページから第kページの印刷可能データを追加すると共に、ジョブテーブル1026の当該ジョブIDに対応するエントリに、第kページまで印刷可能データの生成済み、第mページまで印刷出力済み、を表す途中経過情報を登録する。
このようにして処理途中の情報のデータ記憶装置102への格納が終わると、物理プリンタ管理部1104は、その物理プリンタ114(「物理プリンタ2」)を停止させ、それまでその物理プリンタ114が用いていたリソース(メモリ領域等)を解放する。このリソース解放の後、物理プリンタ管理部1104は、物理プリンタテーブル1022(図5参照)のその「物理プリンタ2」の「状態」を、(それまでの「Ready」から)「Stand-by」へと更新する。
配置管理装置104から図21の実体化(起動)要求コマンドを受け取ったサーバ100(「サーバ2」)の印刷サービス110は、その実体化要求コマンドを物理プリンタ管理部1104に割り当てる。物理プリンタ管理部1104は、その実体化要求コマンドの「宛先」の物理プリンタ114(「物理プリンタ2」)の情報を物理プリンタテーブル1022から取得し、その情報に従って、「サーバ2」内にその「物理プリンタ2」を実体化する。この実体化が成功すると、物理プリンタ管理部1104は、物理プリンタテーブル1022内のその「物理プリンタ2」の「状態」を、(それまでの「Stand-by」から)「Ready」へと更新し、「配置先サーバ」の値を(それまでの「サーバ1」から)「サーバ2」に変更する。
また、このようにして実体化要求コマンドの実行が成功した場合、物理プリンタ管理部1104は、配置管理装置104に対し、「成功」の旨を応答する。この応答を受け取った配置管理装置104は、データ記憶装置102内の配置テーブル1025における「物理プリンタ2」の配置先の「サーバID」を(それまでの「サーバ1」から)「サーバ2」に変更する。
以上のようにして「サーバ2」上に移動した「物理プリンタ2」は、ジョブスケジューリング部1108に対してジョブの割当を要求する。ジョブスケジューリング部1108は、その要求に応じて、その「物理プリンタ2」が受け入れ可能なジョブをジョブテーブル1026に問い合わせる。この問合せの結果、移動前にその「物理プリンタ2」が処理していたジョブが、再び移動後の「物理プリンタ2」に対して再び割り当てられることになる。この割当を受けた「物理プリンタ2」は、データ記憶装置102内のジョブテーブル1026等から、そのジョブの処理途中の情報を取得し、その情報を用いることで、移動前に処理を停止した段階からジョブ処理を再開する。
以上では、物理プリンタ114を移動させる場合を例にとって説明したが、論理プリンタ112を移動させる場合も同様の処理を行えばよい。
なお、再配置計算の結果移動すると決定された仮想プリンタがジョブを処理していない場合は、単に移動元のサーバ100上のその仮想プリンタを停止させ、リソースを解放させた上で、移動先のサーバ100上にその仮想プリンタを実体化すればよい。
以上の例では、配置管理装置104がサーバ100に対して移動対象の仮想プリンタの停止を指示し、その仮想プリンタの処理途中の情報をデータ記憶装置102に格納させた。しかし、サーバ100が障害等で停止した場合は、サーバ100に配置されている仮想プリンタは既に停止しており、その仮想プリンタの処理途中の情報をデータ記憶装置102に格納させることはできない。この場合でも、例えば仮想プリンタが、あらかじめ定めた当該仮想プリンタの行う処理の段階毎に、その段階の処理結果をデータ記憶装置102に反映させるようにすれば、データ記憶装置102は、サーバ100やその上で動作している仮想プリンタが障害等で停止した場合でも、その停止の前の最新の処理段階の処理結果がデータ記憶装置102に保持されていることになる。したがって、サーバ100の停止を検知した後でそのサーバ100上の仮想プリンタを他のサーバ100に移動させたとしても、移動した仮想プリンタは、その最新の処理段階の処理結果から処理を再開することができる。
以上の例では、仮想プリンタが論理プリンタ112と物理プリンタ114とに機能分割されていたが、それら両者の機能を併せ持つ仮想プリンタを用いる場合にも、上述の仮想プリンタのサーバ間移動処理方式は適用可能である。
以上に例示した印刷サービス110、データ記憶装置102及び配置管理装置104は、例えば、汎用のコンピュータに当該装置の各機能モジュールの処理を表すプログラムを実行させることにより実現してもよい。ここで言うコンピュータは、例えば、ハードウエアとして、CPU等のマイクロプロセッサ、ランダムアクセスメモリ(RAM)およびリードオンリメモリ(ROM)等のメモリ(一次記憶)、HDD(ハードディスクドライブ)やSSD(ソリッドステートドライブ)、フラッシュメモリ等の二次記憶を制御する二次記憶コントローラ、各種I/O(入出力)インタフェース、無線又は有線のネットワークとの接続のための制御を行うネットワークインタフェース等が、たとえばバスを介して接続された回路構成を有する。また、そのバスに対し、例えばI/Oインタフェース経由で、CDやDVD、ブルーレイディスクなどの可搬型ディスク記録媒体に対する読み取り及び/又は書き込みのためのディスクドライブ、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体に対する読み取り及び/又は書き込みのためのメモリリーダライタ、などが接続されてもよい。上に例示した各機能モジュールの処理内容が記述されたプログラムがCDやDVD等の記録媒体を経由して、又はネットワーク等の通信手段経由で、フラッシュメモリ等の二次記憶装置に保存され、コンピュータにインストールされる。二次記憶装置に記憶されたプログラムがRAMに読み出されCPU等のマイクロプロセッサにより実行されることにより、上に例示した機能モジュール群が実現される。また、コンピュータは、仮想マシンであってもよい。