(57)【要約】【課題】グリッドのように、ネットワークで結合された複数の計算機センタにおいて、適切なＪＯＢの負荷分散を実現する。【解決手段】ＪＯＢ要求の平均的な間隔とＪＯＢ実行時間の平均時間と要求されるレスポンスタイムから必要なサーバ数を決定する手段を設けることで、ネットワークの遅延がある環境でも、サーバ数が不足した際にネットワークで結合された遠方の計算機センタへ均等な負荷のＪＯＢを投入する。【効果】ネットワークの遅延が存在しても、遠方の計算機センタの負荷を観測しないために、正しい負荷分散が可能となる。【選択図】  図１
2004348192.tif 000002
【特許請求の範囲】
【請求項１】
複数のサーバをそれぞれ備えた複数の計算センタがネットワークを介して接続された計算機システムにおいて、第１の計算センタでのＪＯＢ要求の発生に対し該第１の計算センタから第２の計算センタへの当該ＪＯＢの投入を判断するＪＯＢ分配制御方法であって、
前記第１の計算センタと前記第２の計算センタとを含むシステムでの所望するＪＯＢレスポンスタイムを予め設定すること、
前記第１の計算センタでの平均的なＪＯＢ要求間隔と各サーバでのＪＯＢ平均処理時間を入力として前記所望するＪＯＢレスポンスタイムの達成に必要なサーバ数を算出し、前記第１のサーバについてのサーバ数の基準値と比較すること、
必要なサーバ数が前記サーバ数の基準値を越えたときに、前記第２の計算機センタへＪＯＢを投入することを特徴とするＪＯＢ分配制御方法。
【請求項２】
ネットワークによって複数の計算機センタが接続された計算機システムのＪＯＢ分配制御方法であって、
第１の計算機センタから第２の計算機センタにＪＯＢを投入する際に、
平均的なＪＯＢの要求間隔と、平均的なＪＯＢの実行時間と、所望するＪＯＢのレスポンスタイムとから、実行に必要なサーバ数を算出する手段を設け、
必要なサーバ数が第１の計算機センタにおいて予め定められた基準値を越えたときに、第２の計算機センタへＪＯＢを投入し、
第２の計算機センタは利用者の認証を行い、投入されたＪＯＢの実行時間に対して課金することを特徴とするＪＯＢ制御方法。
【請求項３】
ネットワークによって複数の計算機センタが接続された計算機システムにおいて、
第１の計算機センタから第２の計算機センタにＪＯＢを投入する際に、
平均的なＪＯＢの要求間隔と、平均的なＪＯＢの実行時間と、所望するＪＯＢのレスポンスタイムとから、実行に必要なサーバ数を算出する手段を設け、
必要なサーバ数が第１の計算機センタにおいて予め定められた基準値を越えたときに、第２の計算機センタへＪＯＢを投入し、
第２の計算機センタは第１のセンタから投入されるＪＯＢの平均的な投入間隔と、平均的なＪＯＢの実行時間と、所望するＪＯＢのレスポンスタイムとから、実行に必要なサーバ数を算出する手段を持ち、
必要なサーバ数が第２の計算機センタにおいて予め定められた基準値を越えたときに、第３の計算機センタへＪＯＢを投入することを特徴とするＪＯＢ制御方法。
【請求項４】
グリッド等のようにネットワークによって複数の計算機センタが接続された計算機システムにおいて、
第１の計算機センタから第２の計算機センタにＪＯＢを投入する際に、
平均的なＪＯＢの要求間隔と、平均的なＪＯＢの実行時間と、所望するＪＯＢのレスポンスタイムとから、実行に必要なサーバ数を算出する手段を設け、
必要なサーバ数が第１の計算機センタにおいて予め定められた基準値を越えたときに、第２の計算機センタへＪＯＢを投入し、
第２の計算機センタは第１の計算機センタから投入されたＪＯＢに対して利用料金の算出をする手段を設け、第２の計算機センタを利用した分の料金を第１の計算機センタへ請求することを特徴とする、計算機センタの課金方法。
【請求項５】
グリッド等のようにネットワークによって複数の計算機センタが接続された計算機システムにおいて、
第１の計算機センタから第２の計算機センタにＪＯＢを投入する際に、
平均的なＪＯＢの要求間隔と、平均的なＪＯＢの実行時間と、所望するＪＯＢのレスポンスタイムとから、実行に必要なサーバ数を算出する手段を設け、
必要なサーバ数が第１の計算機センタにおいて予め定められた基準値を越えたときに、第２の計算機センタへＪＯＢを投入し、
第２の計算機センタは第１の計算機センタと第２の計算機センタの利用比率を計算する手段を設け、第２の計算機センタの利用比率が予め設定された基準値を超えた場合に、計算機を第１の計算機センタへ販売することを特徴とする計算機販売方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は計算機を運用する計算機センタで、複数の計算機にＪＯＢ実行を分配する方法に関し、特にグリッドやインターネットのような広域ネットワークで接続された複数の計算機センタ間での連携を前提としたＪＯＢ制御ソフトウェア技術に係わる。
【０００２】
【従来の技術】
複数の計算機を所有する計算機センタでは、ＪＯＢを実行する際に各計算機の負荷がなるべく均等になるようにＪＯＢを分配する。この分配は負荷分散技術と呼ばれ、インターネットに接続された計算機センタであるデータセンタ向けの負荷分散装置により実現される。負荷分散装置の技術は例えば非特許文献１に示されているように、実行要求のあったＪＯＢを利用可能な計算機に均等に配分するラウンドロビン方式やＩＰハッシング方式が知られている。この方式はＪＯＢがほぼ同じ処理時間で終了することが想定される場合には、負荷分散方法として有効である。しかし、どれだけの処理時間要求があるのか不明なＪＯＢを取り扱う際には、各計算機の負荷を観測してＪＯＢを分散する必要がある。特許文献１にそのような技術が開示されており、ＪＯＢ実行中の計算機負荷を観測し、負荷の少ない計算機にＪＯＢを投入する。計算機がグリッドやインターネット等のネットワークにより広域に分散し接続され存在している場合には、ラウンドロビンあるいはＩＰハッシングにより、負荷分散すると、利用する可能性のある全ての計算機が均等に利用される。また、負荷を観測する方法では、ネットワークを介して計算機の負荷を問い合わせ、その負荷情報に基づいてＪＯＢの分配を制御する。
【特許文献１】
特開平５−２６５９５５号公報
【非特許文献１】
ｈｐｐｔ：／／ｏｎｌｉｎｅ．ｐｌａｔｈｏｍｅ．ｃｏ．ｊｐ／ｐｒｏｄｕｃｔｓ／ｃｌｉｋａｒｒａｙ／ｉｎｄｅｘ．ｐｈｔｍｌ
【０００３】
【発明が解決しようとする課題】
上述のように、ラウンドロビンやＩＰハッシングでは使用する可能性のある計算機全てが、ＪＯＢ分配の対象となる。ところが、ネットワークを介して複数の計算機センタが接続されている場合には、ＪＯＢの発生箇所に近い計算機センタと遠隔に位置する計算機センタの計算機とを使い分ける方が便利である。具体的には、ＪＯＢ実行の発生した計算センタにおいて計算機の処理能力に余裕がある限りはその計算機センタにてＪＯＢを実行し、余力が無い場合には遠隔のセンタにてＪＯＢを実行することが望ましい。ところが、ＪＯＢを均等に分配する方法では、ＪＯＢの実行要求が発生した計算機センタに余力が存在しても、遠隔の計算機センタにＪＯＢが分配されることが発生する。
【０００４】
この問題を回避するために負荷を観測する方法を採用したとしても、この方法ではグリッドやネットワークを介して負荷を観測するために、ネットワークの遅延時間が負荷の観測時間に含まれてしまい、計算機負荷の誤認識が発生する。つまり、遠隔のセンタにＪＯＢを投入する場合には、投入を決定してから実際にＪＯＢが実行されるまでの時間と、計算機の負荷を観測して遠隔センタから報告するのにそれぞれネットワークの時間がかかり、ＪＯＢが実行される直前に負荷を観測してしまい、軽負荷であると誤認識することがあり得る。このように、従来技術ではグリッド等によってネットワークを介し広域に分散して計算機が配置されていることが配慮されていない。
【０００５】
そこで、本発明の課題は、グリッドのようにネットワークで接続され広域に分散した計算機センタの計算機の負荷分散、ＪＯＢ分配に関して、ＪＯＢの発生した計算機センタに余力のある場合にはそのセンタでＪＯＢを実行し、遠隔の計算機センタを利用する場合においてもネットワークの遅延時間に影響されず、均等にＪＯＢを分配する方法を与えることにある。
【０００６】
【課題を解決するための手段】
上記の課題は次の手段により解決される。ＪＯＢ実行の要求が発生する計算機センタをローカルセンタ、ネットワークにより接続された遠隔の計算機センタをリモートセンタとする。所望のＪＯＢレスポンスタイムを事前に設定し、ＪＯＢ投入時間の平均値、ＪＯＢ実行時間の平均値を入力とし、先のレスポンスタイムを実現するために必要なサーバ数を決定する手段を有し、必要サーバ数がローカルセンタの基準値を越えたときに、リモートセンタへＪＯＢ実行することにより、計算機の負荷を実際に観測することに無しに適正なＪＯＢ分配を実現する。
【発明の実施の形態】
図１に本発明の１実施形態である計算機システムの動作フローを示す。また、図３にはその計算機システムの概略構成を示す。
【０００７】
図３においてローカルセンタ３００はＪＯＢ要求を発生する計算機センタであり、センタ内にはサーバ３１０ａおよび３１０ｂを所有している。このサーバ３１０ａまたは３１０ｂまたはその両方には後に詳述するようにＪＯＢ管理機構３１１がプログラムとして実装されており、本発明を実施するに必要なＪＯＢリクエストキュー、ＪＯＢリザルトキュー、ＪＯＢ要求観測、サーバ数決定などの機能を実現する。リモートセンタ３０１ａ、および３０１ｂはローカルセンタ３００とネットワーク３０３を介して接続された計算機センタであり、ローカルセンタ３００とリモートセンタ３０１ａ，  ３０１ｂは物理的に広域に分散して配備されていることを前提とする。リモートセンタ３０１ａにもローカルセンタ３００と同様に、サーバ３１０ｃ，  ３１０ｄが設置されており、ここでもいずれかのサーバ上のプログラムとしてＪＯＢ管理機構３１２ａが実現される。リモートセンタ３０１ａでは、ＪＯＢリザルトキューの他にサーバ負荷の観測手段やＪＯＢの課金管理の仕組みが実装される。リモートセンタ３０１ｂもリモートセンタ３０１ａと同じくサーバ３１０ｅ，  ３１０ｆを有しており、同じくＪＯＢ管理機構３１２ｂを具備している。  ＪＯＢ管理機構３１１、３１２ａあるいは３１２ｂによって実現される本発明のＪＯＢ制御方法を図１に戻り説明する。処理手順全体は初期パラメータ設定１００とＪＯＢ実行サービス１１０に大別され、初期パラメータ設定１００ではローカルセンタとリモートセンタとの通常用いるサーバ台数、ＪＯＢの要求があってからＪＯＢが終了する時間、すなわちＪＯＢレスポンスタイム等の標準的な値を設定する処理である。より具体的には、ＪＯＢ要求間隔の平均時間であるＪＯＢ標準間隔を設定し（１０１）、サーバ上でＪＯＢが実行開始し、終了するまでの標準時間であるＪＯＢ実行標準時間を設定する（１０２）。また、前述のＪＯＢレスポンスタイムをローカルセンタとリモートセンタからなる全システムの望ましい時間、つまり設計値として設定する（１０３）。以上の設定値から、後述するサーバ数計算方法によって、全システムで必要なサーバ数の標準値を決定する（１０４）。
【０００８】
以上、初期パラメータ設定処理１００によって、全システムの標準的な挙動に係る数値が決定され、次のＪＯＢ実行サービス１１０によってＪＯＢ要求が無くなるまでの、半永久的に継続する全システムの動作が定義される。まずローカルセンタにおいて、ＪＯＢ実行の要求が発生すると（１１１）、最も最近要求のあった時刻との差を計算し、ＪＯＢ間隔の平均時間を計算する（１１２）。図面には明記していないが、平均時間は次の二つの方法によって計算可能である。一つはＪＯＢ要求を観測する時間間隔を別途設定し、その間に発生したＪＯＢ要求の平均時間を計算するものである。この方法では、ＪＯＢ要求間隔に変化があった場合にその変化を迅速に摘出することが可能である。別法としては、ＪＯＢ要求間隔時間の総和を求め、ＪＯＢ要求数で割ることにより平均値を求めることができる。この方法は、容易に実現可能である反面、ＪＯＢ要求間隔に変化があっても検出しにくい欠点がある。
【０００９】
ＪＯＢ要求の間隔時間の平均値が計算できた時点で、先に述べた初期パラメータ設定１００の結果と合わせ、システム全体として設定されたＪＯＢレスポンスタイムとサーバ上でＪＯＢが実行される平均時間が揃うことになる。そこで、後述する理論式により、設定されたＪＯＢレスポンスタイムを実現するのに必要なサーバ数を計算する（１１３）。この必要サーバ数がローカルセンタに対して予め定めた基準値より大きい場合にのみ（１１４）、リモートセンタのサーバにＪＯＢを投入する（１１７）。リモートセンタでは、投入されたＪＯＢを実行し（１１８）、ＪＯＢの結果をローカルセンタへ返送する（１１９）。
【００１０】
必要サーバ数の判定（１１４）における基準値としては、ローカルセンタで利用可能なサーバ数を用いるのが基本である。この他にも、サーバ上で多重実行可能なＪＯＢの数を設定し、多重実行ＪＯＢ数とサーバ数との積を基準値とする方法等が可能である。なお、必要サーバ数がローカルセンタの基準値に収まる場合（１１４）はローカルセンタのサーバにＪＯＢが投入され（１１５）、ＪＯＢが実行される（１１６）。つまり、ローカルセンタとリモートセンタとから成る全システムに関して、所望のＪＯＢレスポンスタイムを実現するために、ローカルセンタのサーバで充分な限り、ローカルセンタにおいてＪＯＢを実行するのが本発明の本質的な部分である。この基本的処理は外部からセンタの運用に関して停止要求があるまで継続される（１２０）。
【００１１】
以上が本発明の骨子であるが、図２を用いてリモートセンタのＪＯＢ実行に関わる別の実施形態を述べる。図２のＪＯＢ実行サービス２１０においては、リモートセンタのサーバにＪＯＢが投入された後に、利用者の認証処理（２１２）を実施する。具体的には、リモートセンタのサーバにＪＯＢを投入する際に、ローカルセンタでＪＯＢを要求したユーザのＩＤ情報をＪＯＢと同時にリモートセンタに伝送する。ユーザのＩＤは例えばＵＮＩＸ（登録商標）オペレーティングシステムのパスワードファイルにて管理されるＩＤを用いることが可能である。また、本発明のように、計算センタ同士が自動的にＪＯＢをやり取りする場合においては、リモートセンタにおいて、ローカルセンタのユーザ全てを管理することは煩雑であることが懸念される。この場合には、利用認証２１２においてユーザＩＤの代わりにグループＩＤを代用することが可能である。グループＩＤも先に述べたＵＮＩＸ（登録商標）オペレーティングシステムのグループＩＤを使うことが可能である。このように、認証過程を設けることで、ユーザ、またはグループいった利用者単位にリモートセンタ利用に関する課金を行うことが出来る（２１４）。この図２に示した発明の実施形態では、上記に説明したリモートセンタへのＪＯＢ投入２１１、利用認証２１２、課金処理２１４以外は図１に示した実施形態の各処理と同様の動作となる。したがって、図２に示した実施形態では、ＪＯＢを実行しようとした場合に、ローカルセンタ内のサーバだけで所望のレスポンスタイムでＪＯＢが終了出来ない場合には費用が発生する。
【００１２】
次にもう一つの実施形態について図４のシステム構成図並びに図５のフローチャートを用いて説明する。図３ではＪＯＢ要求を発生するローカルセンタ３００が図１または図２に示した方法によって、サーバ数を決定し、リモートセンタ３０１ａまたは３０１ｂにＪＯＢを投入する。図４では、ＪＯＢ要求を発生するローカルセンタ４００に対して、ＪＯＢを投入された第１のリモートセンタ４０１がローカルセンタ４００と同様な方法で必要サーバ数を計算し、第２のリモートセンタ４０２へＪＯＢを投入するシステム構成を示している。この場合、第１のリモートセンタ４０１のＪＯＢ管理機構にはローカルセンタ４００のＪＯＢ管理機構４１０同様の仕組みが必要となる。具体的な第１リモートセンタにおけるＪＯＢ制御方法を図５に示す。初期パラメータ設定５１０はローカルセンタ４００と全く同一の処理内容となる。ここでのＪＯＢ標準間隔、ＪＯＢ実行標準時間、ＪＯＢレスポンスタイムはローカルセンタ４００の各設定値と同一であることが望ましいが、異なる値であっても発明の本質は変化しない。ＪＯＢ実行サービス５２０では、ローカルセンタで実施されるＪＯＢ制御と同様の処理が第１リモートセンタ４０１として実行される。すなわち、ローカルセンタからＪＯＢが投入される（５２１）と、そのＪＯＢ投入間隔の平均値を計算し（５２２）、初期パラメータ設定５１０で決定したＪＯＢ投入の標準時間間隔とサーバ上で実行される平均実行時間、および所望のＪＯＢレスポンスタイムから必要サーバ数を算出し、必要サーバ数が第１のリモートセンタの基準値を越えた場合にに（５２４）、第２のリモートセンタのサーバへＪＯＢを投入する。もし、必要サーバ数が第１のリモートセンタの基準値を下回る場合には第１のリモートセンタのサーバにＪＯＢを投入し（５３０）、ＪＯＢを実行する（５３１）。このように複数のリモートセンタが関与する場合には、課金管理は必須であり、第２リモートセンタでは第１リモートセンタから伝送されたユーザ情報に基づき利用者認証５２６を実施し、ＪＯＢ実行５２７後に課金処理５２８を行い、実行結果を第１リモートセンタへ返送する（５２９）。
【００１３】
次に図６を用いて図１や図３におけるＪＯＢ管理機構とサーバとの関係を詳細に説明する。サーバ３１０ａはローカルセンタに設置されたサーバであり、サーバ３１０ｃはリモートセンタに設置されたサーバである。それぞれのサーバには、プログラムを実行するｃＣＰＵ６１０ａ，６１０ｂとメモリ６１１ａ，６１１ｂおよびネットワークインターフェース６１９ａ，６１９ｂが具備されている。メモリ６１１ａ，６１１ｂはプログラム領域とデータ領域とに分割されており、図１に示したＪＯＢ管理機構はプログラム領域のクライアントＪＯＢ管理プログラム６１２（ローカルセンタ用）、サーバＪＯＢ管理プログラム６１３（リモートセンタ用）として格納されている。図１のローカルセンタのサーバにＪＯＢを投入する場合（１１５）、リモートセンタのサーバにＪＯＢを投入する場合（１１７）のいずれの場合においても、サーバ上で動作中のＪＯＢの数は動作ＪＯＢ数６１６ａ，６１６ｂとして管理されており、動作ＪＯＢ数が非零の場合またはある基準値を越えている場合には、ＪＯＢを即時実行できないとみなし、ＪＯＢをＪＯＢリクエストキュー６１４にＪＯＢを積み、後述するようなＪＯＢをキューから解放する条件が整うまでＪＯＢの実行を待つ。また、図１ＪＯＢ間隔時間平均値計算１１２では、過去に発生したＪＯＢ要求の時刻と、ＪＯＢ要求間隔の総和を記憶しておく必要があり、そのためにデータ領域には最新ＪＯＢ到着時刻６１８の領域が確保される。実行が終了したＪＯＢはまずリモートセンタのＪＯＢリザルトキュー６１５ｂに積まれ、ローカルセンタが結果を受け取れる状態になるとすぐにに転送される。図２の利用認証２１２ではリモートセンタを利用可能なユーザまたはグループの認証が必要であり、そのパスワードなどの認証に必要な情報がユーザリスト６１７として格納される。
【００１４】
上記したＪＯＢリクエストのキューも含めたＪＯＢ制御方法の詳細フローを図７に示す。ここで、ＪＯＢ実行サービス７１０においてリモートセンタのサーバにＪＯＢが投入された場合（７１１）、実行中のＪＯＢの数を動作ＪＯＢ数６１６ｂから取得し、この値がリモートセンタにおけるサーバ数を越えているか否かを判定する（７１２）。越えている場合には、即時実行不可能であるので、ＪＯＢをＪＯＢリクエストキュー６１４に積む（７１１ａ）。ローカルセンタのサーバにＪＯＢが投入される場合（７０９）も、リモートセンタの場合と同様に、実行中のＪＯＢの数を動作ＪＯＢ数６１６ａから取得し、この値がローカルセンタにおけるサーバ数を越えているかを判定し（７１３）、こえる場合にはＪＯＢをＪＯＢリクエストキュー６１４に積む（７１１ｂ）。
【００１５】
ＪＯＢリクエストキュー６１４からＪＯＢを取りだし、実行する時の動作を図８に示す。図７でＪＯＢキューイングとして示した処理では、常にＪＯＢリクエストキューが空でないか否かをチェックし（８００）、空でないときには、ＪＯＢが終了したサーバがある場合を検出し（８０１）、終了したＪＯＢがある場合にはキューからＪＯＢを取り出してサーバで実行する（８０２）。この処理はキューが空でない限り繰り返される。
【００１６】
ここまでの説明が本発明における基本的なＪＯＢ制御方法であり、次に図１に代表されるサーバ数１１３の処理方法を理論的背景および前提条件を含めて説明する。まず、ＪＯＢの要求はランダムに発生すると考える。これは、待ち行列理論で述べるランダム到着を意味する。また、ＪＯＢがサーバ上で実行される際の時間もランダムに変化すると考える。また、ＪＯＢがキューの中に存在する時間とサーバで実行されている時間の和をレスポンスタイムと定義する。さらに、サーバを待ち行列理論の処理窓口と考え、サーバ数つまり窓口の数をｓと定義する。以上のモデル化したイメージを図９に示す。ここでさらに、ＪＯＢの要求間隔の平均時間を１／λ、サーバで実行される実行されるＪＯＢの平均処理時間を１／μとし、キューの長さｎである確立をｐｎとすると、ｓ個の窓口を持つ待ち行列理論から次式が成立する。
【００１７】
【数１】
2004348192.tif 000003
【００１８】
ここで、ＪＯＢ要求と処理時間の比として  ａ＝λ／μ、および系の安定性の指標としてρ＝ａ／ｓ  を定義すると、（数１）の式（ａ）と式（ｂ）から次式が導かれる。
【００１９】
【数２】
2004348192.tif 000004
【００２０】
一方、ｎ≧ｓのときには、（数１）の式（ｃ）をｐｎの隣接項について再整理した次式が成り立つ。
【００２１】
【数３】
2004348192.tif 000005
【００２２】
さらに、ｎ＝ｓ  の境界条件から（数４）が成立しているため、（数５）が得られる。
【００２３】
【数４】
2004348192.tif 000006
【００２４】
【数５】
2004348192.tif 000007
【００２５】
なお、ｐ０についてはΣｐｎ＝１から下記のようになる。
【００２６】
【数６】
2004348192.tif 000008
【００２７】
以上からｐｎの完全解が得られ、これによりモデル化したローカルセンタとリモートセンタに関して、下記の諸指標を得ることができる。
ＪＯＢリクエストキューの長さＬｑ：
【００２８】
【数７】
2004348192.tif 000009
【００２９】
ＪＯＢリクエストキュー内での待ち時間Ｗｑ：
【００３０】
【数８】
2004348192.tif 000010
【００３１】
ＪＯＢのレスポンスタイムＷ：
【００３２】
【数９】
2004348192.tif 000011
【００３３】
ここまでの式の導出により、全システムの平衡状態においてＪＯＢのレスポンスタイムがＪＯＢの要求時間間隔１／λの関数として表現できたことになる。そこで、ＪＯＢの要求状況が変化しても一定のレスポンスタイムを保持するために必要な窓口数（サーバ数）をもとめることができる。
【００３４】
【数１０】
2004348192.tif 000012
【００３５】
この方程式は（ｐｏ）’＝０を仮定することによりｓに関して解くことができる。したがって、入力ＪＯＢの頻度変化に対してレスポンスタイムを不変とする為に必要なサーバ数ｓは次式によって与えられる。
【００３６】
【数１１】
2004348192.tif 000013
【００３７】
以上によって、図１の初期パラメータ設定１００によって設定されたＪＯＢレスポンスタイムを不変とするために必要なサーバ数を平均的なＪＯＢ要求間隔とＪＯＢの実行時間とから求めることができる。
【００３８】
最後に本発明を用いたビジネスの実施形態を図１０を用いて述べる。図中中央の２本の縦線はローカルセンタとリモートセンタにおける処理の時系列を表している。ローカルセンタでは、図２に示したように、標準的なレスポンスタイムを設定し（１０００）、標準的なＪＯＢ要求時間間隔を設定し（１００１）、標準的なＪＯＢ実行時間を設定する（１００２）ことで、ローカルセンタの標準的な値が設定される（１００３）。その後、ＪＯＢ要求の受付が開始してＪＯＢ要求がある毎に必要なサーバ数の決定がなされる（１００５）。次にサーバ数がローカルセンタサーバの基準値を越えた場合（１００６）にリモートセンタのサーバを利用する（１００７）。ここで、リモートセンタではユーザ毎あるいはローカルセンタ毎にリモートサーバの利用時間の合計を計算し（１００８）し、その総計に対して利用料金の請求を行う（１０１０）。これにより、ローカルセンタは利用料金を支払い（１００９）、リモートセンタは利益を得る（１０１１）。これにより、ローカルセンタに備えられた計算機資源の能力を越えたＪＯＢをリモートセンタの支援によって実行可能とすることができ、それにより、リモートセンタはビジネスを行うことが可能である。
【００３９】
図１１はビジネスの別の実施形態を示したものである。図において、リモートセンタはローカルセンタ、リモートセンタ双方の利用時間総計を計算し（１１０１）、その比率を明らかにする。このとき、リモートセンタの利用比率が予め定められた基準値よりも高い時に（１１０２）、リモートセンタはローカルセンタにサーバを販売する（１１０３）。これにより、ローカルセンタはサーバ料金として金銭をリモートセンタに支払い（１１０４）、リモートセンタは利益を得る（１１０５）ことができる。
【００４０】
【発明の効果】
本発明によれば、リモートセンタの負荷情報を観測せずにＪＯＢの割り当て、分配を決定するために、ローカルセンタのＪＯＢ処理能力を越えた場合にのみリモートセンタを利用することが可能であり、ネットワークに遅延時間が存在しても、負荷を観測せずにＪＯＢの分配を行うために、負荷の誤認識を回避したＪＯＢ分配が可能である。
【図面の簡単な説明】
【図１】本発明の１実施形態の動作を示すフローチャートである。
【図２】ＪＯＢ実行に課金処理が伴う別の実施形態の動作を示すフローチャートである。
【図３】図１の実施形態のシステム構成を示すブロック図である。
【図４】更に別の実施形態のシステム構成を示すブロック図である。
【図５】図４の実施形態の動作を示すフローチャートである。
【図６】図１の実施形態もしくは図２の実施形態のサーバ内の詳細な構成を示すブロック図である。
【図７】ＪＯＢキューイングの動作をも含めた実施形態の詳細動作を示すフローチャートである。
【図８】キューの制御方法を示すフローチャートである。
【図９】本発明の原理を示すための待ち行列モデルである。
【図１０】本発明によるビジネス形態を示すタイムシーケンス図である。
【図１１】本発明によるビジネス形態の変形例を示すタイムシーケンス図である。
【符号の説明】
１００：パラメータ設定段階
１１０：ＪＯＢ実行サービス段階
３００：ローカルセンタ
３０１ａ，３０１ｂ：リモートセンタ
３０３：ネットワーク
３１０ａ〜３１０ｆ：サーバ
３１１，３１２ａ，３１２ｂ：ＪＯＢ管理機構。
【図１】
2004348192.tif 000014
【図２】
2004348192.tif 000015
【図３】
2004348192.tif 000016
【図４】
2004348192.tif 000017
【図５】
2004348192.tif 000018
【図６】
2004348192.tif 000019
【図７】
2004348192.tif 000020
【図８】
2004348192.tif 000021
【図９】
2004348192.tif 000022
【図１０】
2004348192.tif 000023
【図１１】
2004348192.tif 000024