(57)【特許請求の範囲】
【請求項１】
それぞれ特定の業務処理を行う複数のセンターサーバーと運用サーバーとを配備したセンターサーバー群と、
前記センターサーバー群に通信回線を介して接続された複数の分散サーバーと、
前記各分散サーバーに通信回線を介して接続された多数のクライアントＰＣとからなる大規模クライアントサーバーシステムにおいて、
前記分散サーバーは、
所定の時間間隔でセンターサーバーにアクセスして各センターサーバーの稼働状態の情報を取得し、前記クライアントＰＣから処理要求があったときに、処理すべきセンターサーバーが負荷超過の状態になっていれば直ちにその旨を処理要求したクライアントＰＣへ回答するセンターサーバー稼働状態確認部と、
前記クライアントＰＣから前記センターサーバーへの処理要求を中継する中継プロセスに対し、起動中の中継プロセス数と稼働中の中継プロセス数の情報を取得し、起動中の中継プロセスがすべて稼働中であるときは、新たなクライアントＰＣからの処理要求に対してその分散サーバーの中継プロセスが負荷超過の状態にあることを直ちに回答し、起動中の中継プロセス数と稼働中の中継プロセス数の比率が所定のしきい値を超えているときは、新たなクライアントＰＣからの処理要求に対して前記センターサーバー群と前記分散サーバー間の通信回線が負荷超過の状態にあることを直ちに回答する中継プロセス部と、
を有していることを特徴とする大規模クライアントサーバーシステム。
【請求項２】
前記センターサーバー群の運用サーバーは、
各センターサーバーに所定の時間間隔でアクセスし、各センターサーバーの稼働状態の情報を取得するセンターサーバー稼働状態監視部と、
前記分散サーバーに所定の時間間隔でアクセスし、各分散サーバーの稼働状態の情報を取得する分散サーバー中継プロセス稼働状態監視部と、
前記センターサーバー稼働状態監視部が取得したセンターサーバーの稼働状態情報と、前記分散サーバー中継プロセス稼働状態監視部が取得した各分散サーバーの稼働状態情報とを比較検討し、所定の分散サーバーの中継プロセスを起動あるいは終了させる中継プロセス起動／終了部と、を備えていることを特徴とする請求項１に記載の大規模クライアントサーバーシステム。
【請求項３】
前記センターサーバー群の各センターサーバーは、前記運用サーバーの情報により、処理すべき業務の種類を切換可能な業務処理部を有していることを特徴とする請求項１に記載の大規模クライアントサーバーシステム。
【請求項４】
前記クライアントＰＣとセンターサーバー群の間に、直接接続された通信回線を別途有していることを特徴とする請求項２または３に記載の大規模クライアントサーバーシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、クライアントＰＣ（端末）の台数が数千台ないし数万台に上る大規模なクライアントサーバーシステムにおいて、通信回線を含むシステム全体の負荷を制御することにより、システムの特定部分が負荷超過の状態になることを防止し、処理要求に対する迅速な回答が得られるようにした大規模クライアントサーバーシステムに関する。
【０００２】
【従来の技術】
従来、大規模なデータ処理を行うシステムは、ホストコンピュータと、そのホストコンピュータに接続された多数の端末からなる集中処理システムが大多数であった。このホストコンピュータを有する従来の集中処理システムでは、ユーザーは端末から処理要求を入力し、ホストコンピュータに処理させ、その処理結果をユーザー指定の端末に送り返すようにしていた。
【０００３】
これに対して、最近ではパーソナルコンピュータ等の小型コンピュータの性能や通信技術、設備が著しく向上し、かつ、小型コンピュータ（以下パーソナルコンピュータを例に説明する）が広く普及したことにより、身近な情報処理にもパーソナルコンピュータを使用したい要求が高まった。
【０００４】
上記要求に応えて、ホストコンピュータとその端末からなる集中処理システムに替えてクライアントサーバーシステムを使用することが試みられている。
【０００５】
クライアントサーバーシステムは、要求に応じて所定の処理を行うサーバー（複数でもよい）と、そのサーバーに処理を要求するクライアントＰＣと、これらのクライアントＰＣとサーバーを接続する通信回線とならなっている。
【０００６】
このクライアントサーバーシステムは、柔軟性に富み、システムに対する要求に応じてネットワーク状あるいはツリー状など任意のネットワークに構成される。
【０００７】
ここで、ホストコンピュータを有する集中処理システムに代わる大規模クライアントサーバーシステムの構成を図５に示す。
【０００８】
図５は、ホストコンピュータを有する集中処理システムに代わる処理システムをクライアントサーバーシステムによって構成した大規模クライアントサーバーシステムである。
【０００９】
この大規模クライアントサーバーシステム２０では、従来のホストコンピュータに代わるセンターサーバー群２１を有している。このセンターサーバー群２１は、種々の業務を処理する複数のセンターサーバー群２１Ａ  ，２１Ｂ  ，２１Ｃ  ，２１Ｄ  ，…を有している。
【００１０】
また、この大規模クライアントサーバーシステム２０では、センターサーバー群２１と地理的に離れた複数の場所に分散サーバーＩ，ＩＩ，ＩＩＩ  ，…を備えている。
【００１１】
分散サーバーＩ，ＩＩ，ＩＩＩ  ，…は、たとえば企業における支店のように、それぞれ独立の情報処理と、本店と情報交換を必要とする情報処理とを行う情報処理拠点に配置されたものである。
【００１２】
センターサーバー群２１と分散サーバーＩ，ＩＩ，ＩＩＩ  ，…は、外部通信回線２２によって接続されている。なお、外部通信回線２２は、図５のように別々の通信回線である場合と、統合された通信回線である場合とがある。
【００１３】
各分散サーバーＩ，ＩＩ，ＩＩＩ  ，…には、多数のクライアントＰＣ▲１▼，▲２▼，…が内部通信回線２３によって接続されている。
【００１４】
この大規模クライアントサーバーシステム２０において、ユーザーはクライアントＰＣ▲１▼，▲２▼，…をパーソナルコンピューターとして使用する一方、集中的に処理すべき業務については、分散サーバーＩ，ＩＩ，ＩＩＩ  ，…を介してセンターサーバー群２１へ処理を要求し、その処理結果をまた分散サーバーＩ，ＩＩ，ＩＩＩ  ，…を介して入手していた。
【００１５】
分散サーバーＩ，ＩＩ，ＩＩＩ  ，…は、分散サーバーとしての独自の処理を行うほか、クライアントＰＣ▲１▼，▲２▼，…からの処理要求をセンターサーバー群２１へ中継する。
【００１６】
【発明が解決しようとする課題】
しかしながら、上記従来のクライアントサーバーシステムでは、システム全体を効率よく使用することが困難であった。
【００１７】
また、従来のクライアントサーバーシステムでは、クライアントＰＣからの処理要求が、長い時間あるいは長い通信回線を経て、はじめてその処理の可否が判明するという問題があった。
【００１８】
さらに、クライアントサーバーシステムは通常、本来の業務のための処理と電子掲示板や電子メール等の単なる私的な情報交換のための処理とを同一システム上で行っているが、従来のクライアントサーバーシステムでは、特定の処理のための処理能力／容量を拡大あるいは縮小することができなかった。
【００１９】
これらの問題を図５を用いて説明する。
すでに説明したように、大規模クライアントサーバーシステムは、大きくクライアントＰＣ▲１▼，▲２▼，…、内部通信回線２３、分散サーバーＩ，ＩＩ，ＩＩＩ  ，…、外部通信回線２２、センターサーバー群２１に分けられる。
【００２０】
従来のクライアントサーバーシステムは、システム全体の負荷バランスを制御しておらず、クライアントＰＣ▲１▼，▲２▼，…、内部通信回線２３、分散サーバーＩ，ＩＩ，ＩＩＩ  ，…、外部通信回線２２、センターサーバー群２１のいずれが、システムのボトルネック（システム全体で全体の処理量の制限となっている構成部分をいう）となっているかが把握できなかった。
【００２１】
このため、システム全体の処理効率が低くなり、また、適当なハードウェアの投資をしなかったり、逆に無駄なハードウェアの投資に行ったりすることがあった。
【００２２】
たとえば、外部通信回線２２の容量がボトルネックになっているシステムに対して、外部通信回線２２を拡張せずにセンターサーバー群２１のみを拡張増設することがあった。この場合には、外部通信回線２２の容量が不足するため、結局増設したセンターサーバーが無駄になってしまうことがあった。
【００２３】
このように、大規模クライアントサーバーシステムの効率的な利用という面では、クライアントＰＣ▲１▼，▲２▼，…、内部通信回線２３、分散サーバーＩ，ＩＩ，ＩＩＩ  ，…、外部通信回線２２、センターサーバー群２１のそれぞれの負荷を把握し、そのいずれを増設すればシステム全体にとって最も効果的であるかを判断することが不可欠である。
【００２４】
これに対して、従来のクライアントサーバーシステムでは、これをいわゆる勘に頼って判断していたので、必ずしも最も効率のよいシステムを構築することができなかった。
【００２５】
次に、大規模クライアントサーバーシステムにおいて、クライアントＰＣからの処理要求に対する処理の可否の回答の遅さの問題について説明する。
【００２６】
従来の大規模クライアントサーバーシステムでは、システムのどの部分で処理が停滞しているかを把握することができなかった。このため、クライアントＰＣからの処理要求は、センターサーバー２１Ａ  ，２１Ｂ  ，２１Ｃ  ，…までの通信経路を順次“待ちの行列”に入り込むことになる。
【００２７】
たとえば、センターサーバー群２１は十分処理能力を余らせているのにも拘わらず外部通信回線２２がオーバーフローしている場合は、クライアントＰＣ▲１▼，▲２▼，…からの処理要求は、分散サーバーＩ，ＩＩ，ＩＩＩ  ，…の発信の“待ちの行列”に入り込み、発信の順番を待たなければならなかった。
【００２８】
この場合、ユーザーはその状況を知ることができず、次善の措置を講じることなく、処理要求に対する処理結果を待たなければならなかった。
【００２９】
また、たとえばセンターサーバー２１Ａ  ，２１Ｂ  ，２１Ｃ  ，…が処理不能になっているような場合は、クライアントＰＣ▲１▼，▲２▼，…からの処理要求は、長い通信経路を通って最終目的地であるセンターサーバー２１Ａ  ，２１Ｂ  ，２１Ｃ  ，…に到達してはじめてセンターサーバー２１Ａ  ，２１Ｂ  ，２１Ｃ  ，…が処理不能である旨の回答をもらうことになる。
【００３０】
このように、処理要求に対する処理可否の回答を迅速に得られない問題は、クライアントＰＣが数千台以上の大規模なクライアントサーバーシステムになると、問題が著しく深刻化する。
【００３１】
大規模クライアントサーバーシステムでは、各クライアントＰＣのユーザーは、システムの混雑の状況を知らずに、次々と処理要求を発することになり、これによって連鎖的な負荷超過を生じ、事実上システムの処理が不能になることも考えられる。
【００３２】
次に、従来のクライアントサーバーシステムでは、時期によって大きく増減する業務処理のための能力／容量を確実に確保しておくができなかった問題について説明する。
【００３３】
クライアントサーバーシステムは通常、本来の業務のためのデータ処理（例えば、売上げ、在庫の集計等がある）と、電子掲示板等の単なる私的な情報交換のための処理とを同一システムで行っている。
【００３４】
ところが、業務のためのデータ処理は、たとえば予算の締切の時期のように処理要求が著しく増大することがある。これに対して、情報交換のための処理の要求は、その時期においても概ね一定である。この結果、予算の締切時期に業務処理のための処理能力が私的な情報交換の処理に圧迫され、重要な業務のための処理に支障が生じることがあった。
【００３５】
このような場合には、業務のための処理能力／容量を優先的に確保し、一時的に私的な情報交換のための処理能力を制限することが合理的である。しかし、従来の大規模クライアントサーバーシステムでは、このような制御を行うことができなかった。
【００３６】
以上のような従来の技術の課題に鑑み、本発明が解決しようとする課題は、システム全体として均等に負荷がかかるようにし、かつ、処理の可否を迅速に回答することができ、さらに特定の処理のための処理能力／容量を拡大あるいは縮小することができる大規模クライアントサーバーシステムを提供することにある。
【００３７】
【課題を解決するための手段】
本願請求項１に係る大規模クライアントサーバーシステムは、
それぞれ特定の業務処理を行う複数のセンターサーバーと運用サーバーとを配備したセンターサーバー群と、
前記センターサーバー群に通信回線を介して接続された複数の分散サーバーと、
前記各分散サーバーに通信回線を介して接続された多数のクライアントＰＣとからなる大規模クライアントサーバーシステムにおいて、
前記分散サーバーは、
所定の時間間隔でセンターサーバーにアクセスして各センターサーバーの稼働状態の情報を取得し、前記クライアントＰＣから処理要求があったときに、処理すべきセンターサーバーが負荷超過の状態になっていれば直ちにその旨を処理要求したクライアントＰＣへ回答するセンターサーバー稼働状態確認部と、
前記クライアントＰＣから前記センターサーバーへの処理要求を中継する中継プロセスに対し、起動中の中継プロセス数と稼働中の中継プロセス数の情報を取得し、起動中の中継プロセスがすべて稼働中であるときは、新たなクライアントＰＣからの処理要求に対してその分散サーバーの中継プロセスが負荷超過の状態にあることを直ちに回答し、起動中の中継プロセス数と稼働中の中継プロセス数の比率が所定のしきい値を超えているときは、新たなクライアントＰＣからの処理要求に対して前記センターサーバー群と前記分散サーバー間の通信回線が負荷超過の状態にあることを直ちに回答する中継プロセス部と、
を有していることを特徴とするものである。
【００４０】
本願請求項２に係る大規模クライアントサーバーシステムは、上記請求項１のクライアントサーバーシステムにおいて、
前記センターサーバー群の運用サーバーは、
各センターサーバーに所定の時間間隔でアクセスし、各センターサーバーの稼働状態の情報を取得するセンターサーバー稼働状態監視部と、
前記分散サーバーに所定の時間間隔でアクセスし、各分散サーバーの稼働状態の情報を取得する分散サーバー中継プロセス稼働状態監視部と、
前記センターサーバー稼働状態監視部が取得したセンターサーバーの稼働状態情報と、前記分散サーバー中継プロセス稼働状態監視部が取得した各分散サーバーの稼働状態情報とを比較検討し、所定の分散サーバーの中継プロセスを起動あるいは終了させる中継プロセス起動／終了部と、を備えていることを特徴とするものである。
【００４１】
本願請求項３に係る大規模クライアントサーバーシステムは、上記請求項１のクライアントサーバーシステムにおいて、
前記センターサーバー群の各センターサーバーは、前記運用サーバーの情報により、処理すべき業務の種類を切換可能な業務処理部を有していることを特徴とするものである。
【００４２】
本願請求項４に係る大規模クライアントサーバーシステムは、上記請求項２または３のクライアントサーバーシステムにおいて、
前記クライアントＰＣとセンターサーバー群の間に、直接接続された通信回線を別途有していることを特徴とするものである。
【００４３】
【発明の実施の形態】
次に、本発明による負荷制御を行う大規模クライアントサーバーシステムの実施形態について添付の図面を用いて以下に説明する。
【００４４】
図１は、本発明の大規模クライアントサーバーシステムの一実施形態によるハードウェアの構成とその処理の流れを示したものである。この図１を用いて、最初に本発明による大規模クライアントサーバーシステムのハードウェアの構成について説明する。
図１に示すように、本実施形態の大規模クライアントサーバーシステム１は、センターサーバー群２と、外部通信回線３と、分散サーバー４と、内部通信回線５と、クライアントＰＣ６とからなる。
【００４５】
センターサーバー群２は、それぞれ所定の処理を行うセンターサーバーＡ，Ｂ，Ｃ，…と運用サーバーＭを、所定の場所（コンピュータセンター等）に集中的に配置したものである。
【００４６】
分散サーバー４は、センターサーバー群２から空間的に離れた複数の情報処理拠点（たとえば企業における支店等である）にそれぞれ配置されたサーバーである。図１の例では所定の情報処理拠点に配置された分散サーバーＩのみを示している。
【００４７】
クライアントＰＣ６は、それぞれの情報処理拠点の分散サーバーに接続された小型コンピュータである。図１の例では分散サーバーＩに接続された３台のクライアントＰＣ▲１▼，▲２▼，▲３▼のみを示しているが、実際にはこのクライアントＰＣの数は非常に大きなものである。
【００４８】
分散サーバー４とクライアントＰＣ６とを接続する通信回線は、各情報処理拠点における内部通信回線５という。また、各分散サーバーＩ，ＩＩ，…とセンターサーバー群２とを接続する通信回線は外部通信回線３という。
【００４９】
クライアントＰＣ▲１▼，▲２▼，▲３▼，…は、小型コンピュータとしての情報処理を行う処理部（図示せず）と、所定の業務処理を要求する業務要求部▲１▼ａ，▲２▼ａ，▲３▼ａ，…と、現在のシステムの処理状態を確認する処理状態確認部▲１▼ｂ，▲２▼ｂ，▲３▼ｂ，…とを有している。
【００５０】
分散サーバーＩ，ＩＩ，…（以下分散サーバーＩについてのみ説明する）は、図示しない分散サーバーとしての業務処理部のほか、中継プロセス部７と、センターサーバー稼働状態確認部８と、中継プロセス起動処理部９と、宛先振分テーブル１０と、中継プロセス稼働状態テーブル１１とを有している。
【００５１】
中継プロセス部７は、クライアントＰＣ▲１▼，▲２▼，▲３▼，…からの処理要求（以下業務要求という）をセンターサーバー群２へ受送信する手段である。
【００５２】
中継プロセス部７は、中継するため出入口を有する所定数の処理手段（これを中継プロセスという）を有している。
【００５３】
中継プロセスは、所定の業務処理要求をセンターサーバー群２へ送信し、その処理結果が受信するまで稼働状態にある。
【００５４】
本発明の中継プロセス部７において注目すべき点は、中継プロセスを必要に応じて開閉（起動／終了）することができることである。起動された中継プロセスは、通常は待機状態にあるが、処理要求を割り当てられると稼働状態になる。
【００５５】
センターサーバー稼働状態確認部８は、定期的にセンターサーバー群２にアクセスし、センターサーバー群２の各センターサーバーＡ，Ｂ，Ｃ，…の稼働状態を確認して所定のファイルに登録／更新する。
【００５６】
中継プロセス起動処理部９は、運用サーバーＭからの命令により、中継プロセス部７の中継プロセスを所定数起動しまたは終了する。
【００５７】
宛先振分テーブル１０は、業務コードをキーとして、処理要求と、各処理要求の処理を行うセンターサーバーＡ，Ｂ，Ｃ，…とを対照させて登録している。
【００５８】
中継プロセス稼働状態テーブル１１は、中継プロセス部７の中継プロセスの稼働状態を定期的に登録／更新している。
【００５９】
センターサーバーＡ，Ｂ，Ｃ，…は、それぞれ業務Ａ，Ｂ，Ｃ，…を処理する業務Ａ処理部Ａ１  ，業務Ｂ処理部Ｂ１  ，業務Ｃ処理部Ｃ１  ，…と、各センターサーバーＡ，Ｂ，Ｃ，…の稼働状態を記録したセンターサーバー稼働状態テーブルＡ２  ，Ｂ２  ，Ｃ２  ，…とを有している。
【００６０】
なお、センターサーバーＡ，Ｂ，Ｃ，…の処理する業務Ａ，Ｂ，Ｃ，…は切り換え可能に構成されている。
【００６１】
運用サーバーＭは、分散サーバー中継プロセス稼働状態監視部１２と、センターサーバー稼働状態監視部１３と、中継プロセス起動／終了部１４とを有している。
【００６２】
分散サーバー中継プロセス稼働状態監視部１２は、各分散サーバーＩ，ＩＩ，…の中継プロセス稼働状態テーブル１１へ定期的にアクセスし、各分散サーバーＩ，ＩＩ，…の中継プロセス部７の所定時間ごとの稼働率等の稼働状態を把握する。
【００６３】
センターサーバー稼働状態監視部１３は、各センターサーバーＡ，Ｂ，Ｃ，…のセンターサーバー稼働状態テーブルＡ２  ，Ｂ２  ，Ｃ２  ，…へ定期的にアクセスし、各センターサーバーＡ，Ｂ，Ｃ，…の稼働状態の情報を取得し、各センターサーバーＡ，Ｂ，Ｃ，…の稼働率や、各センターサーバーＡ，Ｂ，Ｃ，…へ処理を要求する分散サーバーＩ，ＩＩ，…の頻度を含む稼働状態の統計的な数値を算出する。
【００６４】
中継プロセス起動／終了部１４は、上記分散サーバー中継プロセス稼働状態監視部１２とセンターサーバー稼働状態監視部１３の数値の検討結果により、所定の分散サーバーＩ，ＩＩ，…の中継プロセス起動処理部９へ中継プロセスの起動／終了を命令する。
【００６５】
次に、上記構成の大規模クライアントサーバーシステム１の処理の流れについて説明する。
この大規模クライアントサーバーシステム１では、各クライアントＰＣ▲１▼，▲２▼，▲３▼，…は、小型コンピュータとして所定の処理を行うほか、分散サーバーＩあるいはセンターサーバー群２へ所定の業務処理を要求する。
【００６６】
分散サーバーＩは、分散サーバーとして独自にデータ処理を行うほか、クライアントＰＣ▲１▼，▲２▼，▲３▼，…からの処理要求をセンターサーバー群２へ中継する。このとき、分散サーバーＩは、外部通信回線３の負荷の状況と、センターサーバー群２の負荷の状況とを把握し、必要に応じてシステムへの新たな負荷を制限し、クライアントＰＣ６へ現在のシステムの負荷状況をフィードバックする。
【００６７】
この分散サーバーＩにおけるシステムの負荷状況のフィードバックと負荷制御の流れを図２に示し、図１と併せて説明する。
【００６８】
分散サーバーは、クライアントＰＣへ現在のシステムの負荷状況を直ちに回答できるようにするために、定期的にセンターサーバーへアクセスし、センターサーバーの稼働状態を把握する（ステップＳ１００，図２）。
【００６９】
このセンターサーバーの稼働状態確認は、分散サーバーＩ，ＩＩ，…のセンターサーバー稼働状態確認部８が、一定の時間間隔でセンターサーバー群２へ稼働状態の問い合わせをし、各センターサーバーＡ，Ｂ，Ｃ，…の稼働状態の回答を所定のファイルに記録・更新することによって行う（図１参照）。
【００７０】
上記分散サーバーに対して、クライアントＰＣ▲１▼，▲２▼，▲３▼，…の処理要求は不定期に発生する（ステップＳ１１０，図２）。
【００７１】
クライアントＰＣ▲１▼，▲２▼，▲３▼，…から処理要求が送られてきた場合には、分散サーバーは、その処理要求のあった業務を処理するセンターサーバーの稼働状態を確認する（ステップＳ１２０，図２）。
【００７２】
このセンターサーバーの稼働状態確認は具体的には以下にように行う。
たとえばクライアントＰＣ▲１▼の処理要求は、分散サーバーＩのセンターサーバー稼働状態確認部８へ最初に送られる。分散サーバーＩのセンターサーバー稼働状態確認部８は、処理要求のあった業務の業務コードから、宛先振分テーブル１０を参照してその業務を処理すべきセンターサーバーＡ，Ｂ，Ｃ，…を特定する。次に特定されたセンターサーバーＡ，Ｂ，Ｃ，…の最新の稼働状態を、センターサーバーの稼働状態を記録したファイルから取得する（図１参照）。
【００７３】
上記センターサーバーの稼働状態の情報により、センターサーバー稼働状態確認部８はセンターサーバーの処理が混雑しているか否かを判断する。
【００７４】
センターサーバーが混雑していると判断した場合はセンターサーバー稼働状態確認部８は、センターサーバーの処理が混雑である旨をクライアントＰＣへ回答し（ステップＳ１３０）、原則として処理要求を拒絶する。なお、ここでユーザーに指示を求め、処理要求をセンターサーバーへ送信する待ち状態にすることもできる。
【００７５】
センターサーバーが混雑していないと判断した場合、センターサーバー稼働状態確認部８は、クライアントＰＣの処理要求を中継プロセス部７へ渡し、中継プロセス部７により、外部通信回線３の混雑状態を確認する（ステップＳ１４０，図２）。なお、ここで、中継プロセス部７がすでに負荷超過の状態、すなわち、起動している中継プロセスがすべて稼働中の場合は、中継プロセスの処理がが混雑してことをクライアントＰＣへ回答する。
【００７６】
外部通信回線３の混雑状態の判断は、起動されている中継プロセスと稼働状態にある中継プロセス数の比率、あるいは、送信待ちの状態にある処理要求の数によって判断される。
【００７７】
送信待ち状態のある処理要求の数が所定のしきい値を超える場合には、外部通信回線３が混雑している旨をクライアントＰＣへ回答し（ステップＳ１５０，図２）、原則として処理要求を拒絶する。なおここで、前記センターサーバーが混雑している場合と同様に、処理要求を待ち状態にすることも可能である。
【００７８】
外部通信回線３混雑していないと判断した場合は、中継プロセス部７は、宛先振分テーブル１０を参照して処理要求の業務コードから処理すべきセンターサーバーＡ，Ｂ，Ｃ，…を特定し、特定されたセンターサーバーＡ，Ｂ，Ｃ，…へ処理要求を送る（ステップＳ１６０，図１および図２参照）。
【００７９】
これにより、処理要求のあった業務は所定のセンターサーバーＡ，Ｂ，Ｃ，…によって処理され（ステップＳ１７０）、処理結果は中継プロセス部７を介して要求元のクライアントＰＣ▲１▼，▲２▼，▲３▼，…へ返送される（ステップＳ１７０，図１及び図２参照）。
【００８０】
上記制御により、ユーザーは、クライアントＰＣ▲１▼，▲２▼，▲３▼，…へ所定の業務の処理要求を入力すると、直ちにセンターサーバーＡ，Ｂ，Ｃ，…の混雑状態や外部通信回線３や分散サーバーＩの混雑状態を知ることができる（ステップＳ１３０，Ｓ１５０）。
【００８１】
これにより、実際に混雑しているシステム部分の待ち行列に処理要求が入り込む前に、大規模クライアントサーバーシステム１への新たな負荷の増加を制限することができる。
【００８２】
また、ユーザーとしては、処理要求に対して直ちに処理の可否の回答を得られ、緊急の処理要求に対して次善の手段を講じることができる。
【００８３】
次に、本実施形態の大規模クライアントサーバーシステム１が用意している緊急の処理要求に対する手段について説明する。
【００８４】
本実施形態の大規模クライアントサーバーシステム１は、分散サーバー４を迂回する通信回線を用意している。このことを図１を用いて説明する。
図１においてクライアントＰＣ▲２▼が発した処理要求が、センターサーバー稼働状態確認部８により、外部通信回線３が混雑しているとの回答を得たとする。
【００８５】
この場合、ユーザーは、センターサーバー群２が処理能力を余らせているのにも拘わらず、外部通信回線３の混雑によって処理要求を送れないということを知ることができるので、緊急処理を要するときは、直接接続された通信回線１５によってセンターサーバーＣへ処理要求を送ることができる。
【００８６】
このように、直接接続された通信回線１５を用意している大規模クライアントサーバーシステム１によれば、外部通信回線３が混雑している場合に、ユーザーはそのことを直ちに知ることができ、また、処理要求を直接センターサーバー群２へ送ることができる。これによって、重要な業務については他の業務に優先して処理することができる。
【００８７】
次に、本発明による大規模クライアントサーバーシステムのセンターサーバー群２における負荷制御について以下に説明する。
【００８８】
図３は、本発明のセンターサーバー群２における負荷制御の流れを示している。このセンターサーバー群２における負荷制御の方法を図１と併せて説明する。
【００８９】
本発明のセンターサーバー群２における負荷制御は、センターサーバー群２における負荷と、各分散サーバーＩ，ＩＩ，…における負荷とを把握して、均等に負荷を配分することによって行う。
【００９０】
センターサーバー群２の各センターサーバーＡ，Ｂ，Ｃ，…における負荷を把握するために、各センターサーバーＡ，Ｂ，Ｃ，…は、その稼働状態をセンターサーバー稼働状態テーブルＡ２  ，Ｂ２  ，Ｃ２  ，…にそれぞれ登録・更新する（ステップＳ２００）。このセンターサーバー稼働状態テーブルＡ２  ，Ｂ２  ，Ｃ２  ，…に登録する情報は、各センターサーバーＡ，Ｂ，Ｃ，…の実際の稼働時間のほか、処理の要求元の分散サーバーＩ，ＩＩ，…等に関する情報を登録する。
【００９１】
上記センターサーバー稼働状態テーブルＡ２  ，Ｂ２  ，Ｃ２  ，…に対し、運用サーバーＭは、そのセンターサーバー稼働状態監視部１３により、所定の時間間隔ごとにアクセスし、その稼働状態の情報を取得する。
【００９２】
さらに、運用サーバーＭは、取得したセンターサーバー稼働状態テーブルＡ２  ，Ｂ２  ，Ｃ２  ，…の情報から、各センターサーバーＡ，Ｂ，Ｃ，…ごとに分散サーバーＩ，ＩＩ，…の処理要求の頻度、単位時間当たりの稼働時間（稼働率）を算出してそれぞれの稼働状態を把握する（ステップＳ２１０）。
【００９３】
一方、各分散サーバーＩ，ＩＩ，…における負荷を把握するために、各分散サーバーＩ，ＩＩ，…は、起動されている中継プロセス、稼働中の中継プロセス、処理業務の種類等を中継プロセス稼働状態テーブル１１に登録・更新する（ステップ２２０）。
【００９４】
この中継プロセス稼働状態テーブル１１に対して運用サーバーＭは、分散サーバー中継プロセス稼働状態監視部１２により、所定の時間間隔ごとにアクセスして各分散サーバーＩ，ＩＩ，…の稼働状態の情報を取得する。
【００９５】
さらに、運用サーバーＭは、取得した中継プロセス稼働状態テーブル１１の情報から、中継プロセスの稼働率、中継する業務種類等を算出して各分散サーバーＩ，ＩＩ，…の稼働状態を把握する（ステップＳ２３０）。
【００９６】
次に、運用サーバーＭは、必要な時に上記センターサーバーＡ，Ｂ，Ｃ，…の稼働状態と、分散サーバーＩ，ＩＩ，…の稼働状態を比較検討する。この比較検討により、以下の点が明らかになる。
【００９７】
（１）  センターサーバーＡ，Ｂ，Ｃ，…の稼働率の分布状態
（２）  分散サーバーＩ，ＩＩ，…の処理要求頻度の分布状態
（３）  各分散サーバーＩ，ＩＩ，…の中継プロセスの稼働率
（４）  各分散サーバーＩ，ＩＩ，…の処理業務の種類の分布状態
上記の諸情報の分析により、システム全体のボトルネックになっている部分、たとえば、センターサーバー群２全体、あるいは特定のセンターサーバーＡ，Ｂ，Ｃ，…、あるいは外部通信回線３、あるいは特定の分散サーバーＩ，ＩＩ，…を特定することができる。これにより、必要に応じて、以下の負荷のバランス制御を行うことができる。
【００９８】
たとえば、特定のセンターサーバーＡ，Ｂ，Ｃ，…が負荷超過になっている場合は、他のセンターサーバーの処理業務を一時的にその負荷超過のセンターサーバーの処理業務に切り換えることができる（ステップＳ２５０）。
【００９９】
これにより、その負荷超過となっている業務Ａ，Ｂ，Ｃの処理能力／容量を増大させることができる。また、逆に負荷が低いセンターサーバーＡ，Ｂ，Ｃ，…に対しては、処理台数を減らすことによって負荷を増加させることができる。このようにセンターサーバーの負荷を制御することにより、センターサーバー群２の負荷超過による処理の渋滞を解消することができる。
【０１００】
また、たとえば、特定の分散サーバーＩ，ＩＩ，…の中継プロセスが負荷超過の状態になっている場合は、運用サーバーＭがその分散サーバーＩ，ＩＩ，…に対して、所定数の中継プロセスを起動する命令を発する（ステップＳ２６０）。
【０１０１】
上記中継プロセスの起動命令を受けた運用サーバーＭの中継プロセス起動処理部９は、所定数の中継プロセスを起動させ（ステップＳ２７０）、負荷に見合った数の中継プロセスとする。
【０１０２】
また、外部通信回線３の容量が不足している場合は、使用頻度の低い分散サーバーの中継プロセスを終了させることもできる（ステップＳ２６０，Ｓ２７０）。
【０１０３】
このように、分散サーバーＩ，ＩＩ，…の中継プロセスの数を増減させることにより、処理が集中している分散サーバーＩ，ＩＩ，…における処理の渋滞を解消することができる。
【０１０４】
また、上記負荷制御を行うことにより、大規模クライアントサーバーシステムの恒常的に負荷超過になっている構成部分を把握することができるので、システム全体の処理能力／容量の改善に対して適切な対策を講じることができる。
【０１０５】
最後に、決算期等の業務処理が集中する場合の負荷制御について以下に説明する。
【０１０６】
図４は、特定の業務処理が集中する時期に、重要な業務処理を他の処理に優先させて処理能力／容量を確保しておく方法を示している。
【０１０７】
図４において、ステップＳ３００〜Ｓ３４０は、図３のステップＳ２００〜Ｓ２４０と全く同一の処理であるので、ここでの重複する説明を省く。
【０１０８】
決算期等において特徴的なのは、所定の業務処理を必ず確保しなければならないことである。そこで、ステップＳ３４０で、センターサーバー群２と分散サーバー４の負荷バランスを検討する作業において、他の業務に優先させるべき所定の業務処理に必要なセンターサーバーの台数を予測し算出する（ステップＳ３５０）。
【０１０９】
次に、その処理業務のバランスとなるように、センターサーバーＡ，Ｂ，Ｃ，…の処理業務の切換えを行う（ステップＳ３６０）。
【０１１０】
次に、分散サーバーＩ，ＩＩ，…間で処理要求のばらつきがあるので、センターサーバーＡ，Ｂ，Ｃ，…の処理業務に見合った中継プロセスの数を決定する（ステップＳ３７０）。
【０１１１】
これ以降は、上記決定した各分散サーバーＩ，ＩＩ，…の中継プロセスの数となるように各分散サーバーＩ，ＩＩ，…の中継プロセスを起動あるいは終了させる（ステップＳ３８０〜Ｓ３９０）。この中継プロセスを起動あるいは終了の制御は、図３において説明した制御と同一なので、説明を省略する。
【０１１２】
以上のような制御を行うことにより、決算期等のおいては、重要な処理業務（例えば、売上げ、在庫の集計等）のための処理能力／容量が確保され、重要でない情報処理（例えば、私的な電子メール等）のための処理能力／容量が縮小される。これによって、決算期等の情報処理が集中する時期に、重要な業務が処理できない不都合を防止することができる。
【０１１３】
【発明の効果】
以上の説明から明らかなように、本発明による大規模クライアントサーバーシステムによれば、運用サーバーによって、各センターサーバーの負荷の分布状態と、分散サーバーの負荷の分布状態とを検出し、センターサーバーの処理業務の切換、あるいは所定の分散サーバーの中継プロセスの起動または終了等の負荷制御を行えるので、所定の構成部分が負荷超過状態になってシステム全体の処理能力が制限されることを防止でき、すべてのハードウェア資源の利用効率が極めて高い大規模クライアントサーバーシステムを得ることができる。
【０１１４】
また、本発明の大規模クライアントサーバーシステムによれば、分散サーバーにおいて、中継プロセスが負荷超過である場合、および外部通信回線が負荷超過である場合に、新たなクライアントからの処理要求に対して直ちにその旨を回答することができる。また、センターサーバーの稼働状態を分散サーバーが常に監視し、負荷超過のセンターサーバーに対して処理要求があった場合には直ちにその旨を回答することができる。
【０１１５】
これにより、本発明の大規模クライアントサーバーシステムのユーザーは、処理要求に対する処理の可否の回答を直ちに得られる。この場合に、センターサーバーとクライアントＰＣとを直接接続した通信回線を介して緊急処理を要する業務を直接センターサーバーへ送ることができる。
【０１１６】
また、本発明の大規模クライアントサーバーシステムによれば、センターサーバーの処理業務を切り換え、所定の処理業務の処理能力／容量を拡大あるいは縮小することができるので、決算期等の業務処理の要求が集中する時期に、業務処理のための処理能力／容量を確保し、私的な情報交換等の処理能力／容量を制限することにより、業務処理に支障を来さずに合理的な処理を行うことができる。
【図面の簡単な説明】
【図１】本発明による大規模クライアントサーバーシステムのシステム構成とその処理の流れを示したブロック図。
【図２】分散サーバーにおける負荷制御の流れを示したフローチャート。
【図３】運用サーバーにおけるシステム全体の負荷バランス制御の流れを示したフローチャート。
【図４】決算期等に所定の処理業務のための処理能力／容量を優先的に確保する制御の流れを示したフローチャート。
【図５】従来のクライアントサーバーシステムの構成を示したブロック図。
【符号の説明】
１  大規模クライアントサーバーシステム
２  センターサーバー群
３  外部通信回線
４  分散サーバー
５  内部通信回線
６  クライアントＰＣ
７  中継プロセス部
８  センターサーバー稼働状態確認部
９  中継プロセス起動処理部
１０  宛先振分テーブル
１１  中継プロセス稼働状態テーブル
１２  分散サーバー中継プロセス稼働状態監視部
１３  センターサーバー稼働状態監視部
１４  中継プロセス起動／終了部
１５  直接接続された通信回線
▲１▼  クライアントＰＣ
▲２▼  クライアントＰＣ
▲３▼  クライアントＰＣ
▲１▼ａ  業務要求部
▲２▼ａ  業務要求部
▲３▼ａ  業務要求部
▲１▼ｂ  処理状態確認部
▲２▼ｂ  処理状態確認部
▲３▼ｂ  処理状態確認部
Ａ  センターサーバー
Ｂ  センターサーバー
Ｃ  センターサーバー
Ａ１    業務Ａ処理部
Ｂ１    業務Ｂ処理部
Ｃ１    業務Ｃ処理部
Ａ２    センターサーバー稼働状態テーブル
Ｂ２    センターサーバー稼働状態テーブル
Ｃ２    センターサーバー稼働状態テーブル
Ｉ  分散サーバー
Ｍ  運用サーバー
【図１】
0003573386.tif 000002
【図２】
0003573386.tif 000003
【図３】
0003573386.tif 000004
【図４】
0003573386.tif 000005
【図５】
0003573386.tif 000006