JP3847364B2 - ロードシェアシステム - Google Patents
ロードシェアシステム Download PDFInfo
- Publication number
- JP3847364B2 JP3847364B2 JP02635196A JP2635196A JP3847364B2 JP 3847364 B2 JP3847364 B2 JP 3847364B2 JP 02635196 A JP02635196 A JP 02635196A JP 2635196 A JP2635196 A JP 2635196A JP 3847364 B2 JP3847364 B2 JP 3847364B2
- Authority
- JP
- Japan
- Prior art keywords
- distribution
- server
- state
- communication
- information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Computer And Data Communications (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は複数のプロセッサで分散処理を行うロードシェアシステムに関し、特に通信媒体を介して構築されたロードシェアシステムに関する。
【０００２】
【従来の技術】
多数の利用者に様々な機能を提供する場合、サーバが利用者に提供する業務を複数のプロセッサに分散させることができる。このような分散処理を行うシステムをロードシェアシステムと呼ぶ。このロードシェアシステムをローカル・エリア・ネットワーク（ＬＡＮ）に接続された複数のサーバで構築することも行われている。ここで業務とは、サーバがアプリケーションプログラム（以後、単に「アプリケーション」と呼ぶ）を実行することにより、利用者に代わってデータ処理を行う際の処理単位をいう。
【０００３】
従来のＬＡＮで構築されたロードシェアシステムでは、複数のサーバ間の負荷の分散の割合は、予めネットワーク上で定義付けられており実質的に固定である。つまり、システムの負荷の分散を自由に制御することはできない。
【０００４】
従って、業務の運用を切り換えるには、サーバ単位にアプリケーションを操作するか、あるいは各サーバの持つネットワーク資源を操作していた。サーバのアプリケーションを操作する場合は、そのアプリケーションの起動・停止、及び受け付ける業務の数の変更等の操作を行う。ネットワーク資源を操作する場合は、その各サーバ上のネットワーク資源を個々に活性化あるいは非活性化の操作を行う。
【０００５】
一方、システムの利用者が業務の提供を受けるには、複数のサーバの個々にアクセスする必要がある。個々のサーバにアクセスするには、それぞれのサーバの通信アドレスや業務が設けられている構成などを利用者側で認識していなければならない。
【０００６】
【発明が解決しようとする課題】
しかし、従来のロードシェアシステムでは負荷の分散を一括して制御できないため、システムの運用状況の変化に応じた負荷分散の制御ができず、システムの運用効率の悪化や信頼性の低下を招いていた。つまり、業務が１つのサーバに集中したり、バッチ処理等の臨時業務が発生すると、利用者側でのレスポンスが悪化する場合があった。また、アプリケーションやサーバ自身に障害が発生すると、利用者からの要求が拒否される場合があった。
【０００７】
なお、システムの管理者が各サーバごとに資源などを操作することにより負荷の配分を変更することは可能であったが、それには利用者がどのサーバのどの業務に集中しているのかをその都度的確に判断しなければならない。運用中のサーバの負荷は常に変動するため、システムの管理者が常に的確な判断を行いロードシェアシステムの負荷分散を最適化することは困難である。
【０００８】
一方、利用者にとっては、個々のサーバにアクセスしなければならないため、利用者側の端末においても複雑な通信環境の設定を行う必要があり、利用者の負担が大きいという問題点があった。
【０００９】
本発明はこのような点に鑑みてなされたものであり、運用効率を最適に保ち高い信頼性を有する、ＬＡＮを介して構築されたロードシェアシステムを提供することを目的とする。
【００１０】
【課題を解決するための手段】
本発明では上記課題を解決するために、通信媒体に接続された複数のサーバと、前記通信媒体及び該通信媒体とは異なる通信網との通信を行う通信制御装置とを有するロードシェアシステムであって、個々の前記サーバは、前記通信媒体を介して送られてきた処理要求に伴う業務を提供する業務提供手段と、前記業務提供手段の使用状態を基にした自己の負荷情報を、前記通信媒体を経由して前記通信制御装置へ送信する状態管理代理手段と、を有し、前記通信制御装置は、前記通信媒体を経由して送られてくる前記サーバからの負荷情報を基に、前記サーバの管理情報を管理する状態管理手段と、活性状態もしくは非活性状態にある複数の振り分け条件を有しており、前記通信網から前記通信制御装置の宛先通信アドレスを有する処理要求情報が到来した場合、該処理要求情報の宛先通信アドレスを、前記管理情報を基に活性状態にある前記振り分け条件にしたがって選択した前記サーバの通信アドレスに変換し、前記通信媒体を経由して送信する振り分け処理を行う振り分け手段と、前記振り分け手段が有する個々の前記振り分け条件に対し、活性化もしくは非活性化させる運用操作手段と、を有し、前記振り分け手段は、活性状態にある前記振り分け条件において所定の利用者分類情報が指定された前記業務提供手段に対しては、前記利用者分類情報に合致する利用者からの前記処理要求情報のみを振り分ける、ことを特徴とするロードシェアシステムが提供される。
【００１１】
この構成によれば、利用者端末から通信制御装置宛に送られた処理要求情報は、通信制御装置で処理要求情報の宛先通信アドレスを、管理情報を基に活性状態にある振り分け条件にしたがって選択したサーバの通信アドレスに変換し、通信媒体を経由して送信することにより、いずれかのサーバへ振り分けられる。従って、利用者側が個々のサーバの通信アドレスなどを認識している必要がないとともに、活性もしくは非活性を切り換えることによりサーバ間の効率的な負荷分散を行うことができる。また、活性状態にある振り分け条件において業務提供手段について利用者分類情報が指定されている場合、利用者分類情報に合致する利用者からの処理要求情報のみがその業務提供手段を有するサーバに振り分けられる。従って、利用者を指定した運用の切り換えを行うことにより、利用者の利用頻度の地域格差を考慮した運用の切り換えが可能となる。
【００１４】
【発明の実施の形態】
以下、本発明の実施の形態を図面に基づいて説明する。
図１は本発明の原理構成図である。サーバ２は、データベース（ＤＢ）１ａを有している。サーバ３，４は、共用のデータベース１ｂを有している。これら複数のサーバ２，３，４は、通信媒体５を介して送られた処理要求を処理する業務提供手段２ａ，３ａ，４ａと、自己の動作状態を管理する状態管理代理手段２ｂ，３ｂ，４ｂとを有している。
【００１５】
通信制御装置６において、状態管理手段６ａは、状態管理代理手段２ｂ，３ｂ，４ｂとの間で通信媒体５を介した通信パスを確立し、通信パスを用いて各サーバ２，３，４の状態を示す管理情報を状態管理代理手段から受け取り、サーバ２，３，４の状態を一括管理する。振り分け手段６ｂは、通信網７を介して接続されている利用者側装置８ａ，８ｂ，８ｃからの要求を受信し、状態管理手段６ａが管理している情報に基づき要求の振り分け先を決定し、要求をサーバ２，３，４に対する処理要求として通信媒体５を介して送信する。運用操作手段６ｃは、業務提供手段２ａ，３ａ，４ａに要求を振り分けるための複数の条件の活性化又は非活性化の状態切り換えを行う。
【００１６】
このような構成において、各サーバ２，３，４の動作状況は状態管理代理手段２ｂ，３ｂ，４ｂから状態管理手段６ａに送られ、状態管理手段６ａは各サーバ２，３，４の動作状況を一括管理する。そして、利用者側装置８ａ，８ｂ，８ｃから出力された要求は、通信網７を介して通信制御装置６に送られる。通信制御装置６内では、振り分け手段６ｂが現在活性状態となっている条件に基づいて要求の振り分け先を決定し、出力を受けた要求を、振り分け先として決定したサーバの業務提供手段への処理要求として、該当するサーバへ送信する。処理要求を受け取ったサーバの業務提供手段は、処理要求の内容に従って、データベースを操作する。また、各サーバ２，３，４の動作状況に変化が生じ、負荷配分を変える必要が生じた場合には、運用操作手段６ｃが、振り分け比率等の振り分けの条件を操作する。
【００１７】
このようにして、利用者はこのシステムが複数のサーバによるロードシェアシステムであることを意識せずにすむ。また、通信制御装置６は、状態管理代理手段２ｂ，３ｂ，４ｂから各サーバ２，３，４内の状態に関する情報を収集しているため、最適な負荷の分散を行うことができる。さらに、運用操作手段６ｃが、振り分け条件の活性化・非活性化の切り換えを行うことにより、様々な状況の変化に対して直ぐに適切な対処をすることが可能となり、システムの負荷の配分を最適化することができる。
【００１８】
ところで、上記のロードシェアシステムを実現するためのハードウェア構成として、通信制御装置が１台の場合と複数台の場合とが考えられる。以下の説明では、まず通信制御装置が１台の場合について説明し、その後通信制御装置が複数台の場合について説明する。
【００１９】
図２は本発明のロードシェアシステムの概略構成を示すブロック図である。これは、通信制御装置が１台の場合の構成である。この図には１つのローカルエリアネットワーク（ＬＡＮ）４１と２つの通信媒体４４，４５が示されている。ＬＡＮ４１には、複数のサーバ１０，２０，３０と通信制御装置１００とが接続されている。サーバ１０にはデータベース（ＤＢ）４２が接続されている。サーバ２０，３０は、データベース４３を共有している。通信媒体４４には、通信制御装置１００と他の複数のシステム５１，５２とが接続されている。各システム５１，５２には、端末６１，６２が接続されている。通信媒体４５には、通信制御装置１００と複数の端末６３，６４とが接続されている。
【００２０】
サーバ１０，２０，３０のそれぞれには、利用者に各種業務を提供するアプリケーション１１，２１，３１、自己の動作状態を示すデータが格納された状態管理テーブル１２，２２，３２、及び通信制御装置１００へ自己の動作状態を報告する状態管理エージェント１３，２３，３３が設けられている。
【００２１】
通信制御装置１００はＬＡＮ４１と他の通信媒体４４，４５との情報通信を制御する装置であり、内部にネットワーク連携装置１００ａを有している。ネットワーク連携装置１００ａは、振り分けプログラム１１０と記憶装置１２０とを有している。振り分けプログラム１１０は、状態管理エージェントから各サーバ１０，２０，３０の状態を収集し一括管理する状態管理部１１１、利用者からの要求をいずれかのサーバに振り分ける振り分け処理部１１２、及び要求を振り分けるための条件の活性化・非活性化の切り換えを行う運用操作部１１３から構成されている。また、記憶装置１２０内には各サーバの負荷状態を示す負荷分散情報１２１、各サーバに振り分けられた要求の情報を示す状態管理テーブル１２２、及び運用を切り換えるための複数の条件が格納された運用テーブル１２３が格納されている。
【００２２】
以上のような１台の通信制御装置で構成されるロードシェアシステムは、大別して次の諸機能を備えている。
第１の機能は、通信制御装置１００とサーバ１０，２０，３０とが一体となり、１つのサーバのように振る舞う機能である。言い換えると、通信制御装置１００が他のサーバ１０，２０，３０を隠蔽し、利用者からは１つのシステムとみえるようにする機能である。以後、この機能を１システムビューと呼ぶ。
【００２３】
第２の機能は、サーバ側に配置した状態管理エージェント１３，２３，３３の働きにより、各サーバ１０，２０，３０のアプリケーションの動作状況を通信制御装置１００で一括管理する機能である。
【００２４】
第３の機能は、上記第１の機能と第２の機能とを併用した機能である。つまり、通信制御装置１００が一括管理している各サーバの管理情報に基づき、利用者からの要求を適切なサーバへ振り分けることにより、負荷配分の最適化を図る機能である。
【００２５】
第４の機能は、上記第１の機能を用いて要求を振り分ける際に、振り分け先を決定するための条件の活性化・非活性化を切り換えることにより、効率的な負荷の分散を実現する機能である。
【００２６】
第５の機能は、第４の機能を実行する際に、第２の機能で管理している各サーバ１０，２０，３０の負荷状態に応じて、動的に振り分け条件を切り換える機能である。
【００２７】
まず、第１の機能である１システムビューについて説明する。図３は１システムビューの機能を示すブロック図である。なお、この図では、図２における２つの通信媒体４４，４５を包括して通信媒体４６としている。
【００２８】
ここでは、端末６３、６４や、他のシステム５１、５２からＤＢ４２，４３の更新処理の要求を出力する場合を例にとり説明する。端末６３、６４やシステム５１、５２から要求７１，７２を出力する際には、通信制御装置１００の通信アドレス（Ａ）を送信先として指定して出力する。すると、その要求７１，７２は通信媒体４６を介して通信制御装置１００に送られる。通信制御装置１００では、振り分け処理部１１２が要求７１，７２に含まれるロードシェアシステムとしての通信アドレス（Ａ）をサーバ１０，２０，３０のいずれかの通信アドレス（Ｂ），通信アドレス（Ｃ），通信アドレス（Ｄ）に変換する。そして、通信アドレス変換後の要求７３，７４，７５は、通信制御装置１００からＬＡＮ４１を介していずれかのサーバに転送される。サーバ１０，２０，３０内のアプリケーション１１，２１，３１は、要求を受け取るとその要求内容に応じてＤＢ４２，４３を操作する。
【００２９】
このようにして、端末６３、６４や、他のシステム５１、５２からは、通信制御装置１００の通信アドレス（Ａ）を指定して、アプリケーションの機能の提供を受けることができる。つまり、利用者はサーバ１０，２０，３０の存在を意識する必要がない。
【００３０】
図４は利用者が認識しているネットワーク網のイメージを示す図である。利用者は、通信媒体４６には端末６３，６４、システム５１、５２及び共用ＤＢ４２，４３を操作するアプリケーション１０１ａを有するサーバ１００ａが存在しているように認識している。このサーバ１００ａは、実際にはサーバ１０，２０，３０と通信制御装置１００との複合システムである。
【００３１】
一方、通信制御装置１００では、通信アドレス（Ａ）と各サーバ１０，２０，３０のそれぞれの通信アドレス（Ｂ），通信アドレス（Ｃ），通信アドレス（Ｄ）とを相互にリンクさせている。
【００３２】
図５は通信制御装置１００内での通信アドレスのリンク状態を示す図である。通信制御装置１００の通信アドレス（Ａ）８１からサーバ１０の通信アドレス（Ｂ）８２、サーバ２０の通信アドレス（Ｃ）８３、サーバ３０の通信アドレス（Ｄ）８４の順でリンクが張られている。また、通信アドレス（Ｂ）８２から通信アドレス（Ａ）８１へ、通信アドレス（Ｃ）８３から通信アドレス（Ａ）８１へ、通信アドレス（Ｄ）８４から通信アドレス（Ａ）８１へ、それぞれリンクが張られている。
【００３３】
この状態で、振り分け処理部１１２は、利用者の端末６３、６４やシステム５１，５２側からサーバ１０，２０，３０側へ、あるいはサーバ１０，２０，３０側から利用者の端末６３，６４やシステム５１，５２側への通信アドレスの変換を行う。以下に、通信アドレスの変換方式を示す。
【００３４】
図６は通信アドレスの変換方式を示す図である。このネットワーク網では、２つの通信アドレスがペアとなって伝送される。図中の左側は、通信制御装置１００とサーバ１０，２０，３０との間で使用される通信アドレスペア８５〜８７である。通信アドレスペア８５〜８７は、各サーバ１０，２０，３０のそれぞれの通信アドレス（Ｂ），通信アドレス（Ｃ），通信アドレス（Ｄ）と利用者の端末の通信アドレス（ｘ）とのペアである。一方、図中の右側は、通信制御装置１００と端末６１〜６４との間で使用される通信アドレスペア８８である。通信アドレスペア８８は、各通信制御装置１００の通信アドレス（Ａ）と利用者の端末の通信アドレス（ｘ）のペアである。
【００３５】
通信制御装置１００内の振り分け処理部１１２は、通信媒体４６を介して通信アドレスペア８８を受け取ると、通信アドレスペア８８内の自己の通信アドレス（Ａ）をサーバ１０，２０，３０のいずれかの通信アドレスに変更する。そして、変更後の通信アドレスペアをＬＡＮ４１上に出力する。
【００３６】
次に、第２の機能である、サーバ内のアプリケーションの状態を通信制御装置１００で一括管理する機能について説明する。図７は通信制御装置１００での一括管理機能の概略構成を示すブロック図である。この機能を実現するために、通信制御装置１００側の状態管理部１１１と各サーバ１０，２０，３０側の状態管理エージェント１３，２３，３３との間でサーバの状態管理用の通信パス９１，９２，９３を確立している。状態管理部１１１は通信パス９１，９２，９３を使用して、アプリケーション１１，２１，３１の状態要求を状態管理エージェント１３，２３，３３へ送信する。状態管理エージェント１３，２３，３３は状態取得要求を受信すると、アプリケーション１１，２１，３１の動作状況を状態管理部１１１へ送信する。状態管理部１１１は、各状態管理エージェント１３，２３，３３が応答したアプリケーション１１，２１，３１の動作状況を記憶装置１２０で一括管理する。記憶装置１２０内では、各サーバの動作状況は負荷分散情報１２１と状態管理テーブル１２２とに分けて管理される。以後、負荷分散情報１２１と状態管理テーブル１２２とに運用情報を加えたものを管理簿と呼ぶ。
【００３７】
図８は状態管理を行う際の処理手順を示すフローチャートである。これは、状態管理部１１１が実行する処理である。
〔Ｓ１〕状態管理エージェント１３，２３，３３との間で状態管理用の通信パス９１，９２，９３を確立する。
〔Ｓ２〕状態管理エージェント１３，２３，３３に対して状態要求を送信する。
〔Ｓ３〕状態管理エージェント１３，２３，３３からサーバ１０，２０，３０毎のアプリケーション１１，２１，３１の状態を受信する。
〔Ｓ４〕アプリケーション１１，２１，３１の状態が変化した際に状態管理エージェント１３，２３，３３が出力する状態変更情報を受信する。
〔Ｓ５〕サーバ１０，２０，３０のアプリケーション１１，２１，３１の状態を管理簿を用いて管理する。
【００３８】
以下に、管理簿の内容について説明する。図９は管理簿内の一例を示す図である。管理簿では、「業務」、「運用情報」、「状態管理情報」、及び「負荷分散情報」に分けて管理されている。
【００３９】
「業務」は、ロードシェアシステムで実行される処理の単位である。「運用情報」は、「業務」がサービスの提供を行っている場合には「運用中」であり、サービスの提供を停止している場合には「停止中（抑止状態）」である。
【００４０】
「状態管理情報」は、「通信先サーバ情報」、「サーバ上のアプリケーションプログラム」、「ＩＤ」、及び「状態」に別れている。「通信先サーバ情報」は、後に続く情報がどのサーバの情報であるかを示している。「サーバ上のアプリケーションプログラム」は、サーバ内で業務を提供しているアプリケーションプログラムの名称を示している。「ＩＤ」は、サーバ上のアプリケーション単位に割り振られた識別番号である。「状態」は、アプリケーションが使用可能であるか否かを示している。
【００４１】
なお、「ＩＤ」の情報は、状態管理エージェントとの間の状態に関する情報の交換の際に使用される。ネットワーク連携装置１００ａ内でエージェントからの状態を反映する際、「ＩＤ」を用いることにより資源検索の高速化が図れる。
【００４２】
「負荷分散情報」は、「振り分け数の情報」と「比率情報」とに分かれている。「振り分け数の情報」は、アプリケーションへ振り分けた利用者からの要求の数を示している。「比率情報」は、当該業務に対する全要求数の中の、各サーバに現在振り分けられている要求の割合を示している。この数字から、アプリケーションの負荷の分散状況を知ることができる。
【００４３】
図１０は状態管理処理の概念図である。この図では、サーバ１０はアプリケーション１１，１４を有しており、サーバ２０はアプリケーション２１，２４を有している。なお、アプリケーション１１とアプリケーション２１とは同じ業務を提供するアプリケーションである。また、状態管理簿１２３の内容は、図９に示したものである。ここで、アプリケーション１１，１４，２１は動作しているが、アプリケーション２４は停止しているものとする。
【００４４】
このような条件で、通信制御装置１００内の状態管理部１１１は、まずサーバ１０とサーバ２０とに対する問い合わせ情報１０１、１０３を組み立て、それを状態要求として出力する。サーバ１０，２０内のそれぞれの状態管理エージェント１３，２３は状態要求に応答し、自己のサーバ内のアプリケーションの状態を示す応答情報１０２、１０４を出力する。状態管理部１１１は応答情報１０２、１０４を受けとり、その内容を管理簿１２３に反映する。
【００４５】
図１１は通信制御装置の状態要求の際のフローチャートである。これは、通信制御装置１００内の状態管理部１１１が実行する処理である。
〔Ｓ１１〕管理状態を通信するための通信パスを各状態管理エージェントとの間で確立する。
〔Ｓ１２〕管理簿より状態管理情報の読み込みを行う。
〔Ｓ１３〕サーバ単位に状態問い合わせ情報を組み立てる。この時に、資源単位に「ＩＤ」が設定される。
〔Ｓ１４〕サーバ内状態管理エージェントへの状態要求を送信する。
【００４６】
図１２は状態通知を受け取った通信制御装置の処理手順を示すフローチャートである。これは、通信制御装置１００内の状態管理部１１１が実行する処理である。
〔Ｓ２１〕状態管理エージェントからの状態通知を受信する
〔Ｓ２２〕受信した状態通知内のＩＤから、資源を特定する。
〔Ｓ２３〕特定した資源が使用可能であるのか、使用不可能であるのかを判別する。使用可能であればステップＳ２４に進み、使用不可能であればステップＳ２５に進む。
〔Ｓ２４〕特定した資源が使用可能である旨を管理簿に反映する。
〔Ｓ２５〕特定した資源が使用不可能である旨を管理簿に反映する。
【００４７】
以上の図１１、図１２が通信制御装置で実行される処理手順である。次に、各サーバ内における状態管理エージェントで実行される処理手順を説明する。
図１３は通信制御装置からの要求により状態通知を出力する際の状態管理エージェントの処理手順を示すフローチャートである。
〔Ｓ３１〕通信制御装置との間の状態管理パスを確立する。
〔Ｓ３２〕ネットワーク連携装置内の状態管理部から振り分け資源の状態要求を受信する。
〔Ｓ３３〕振り分け資源の状態確認及び状態遷移通知出口を状態管理エージェント内に登録する。これで、振り分け資源名とその状態を示す管理テーブルが作成される。ここで、状態遷移通知出口とは、サーバ内でアプリケーションを管理しているプログラムから状態管理エージェントへ資源の状態を通知するための情報伝達の受信口である。この受信口（状態遷移通知出口）を状態管理エージェントに登録しておくことにより、アプリケーションの状態を状態管理エージェントが取得可能となる。
〔Ｓ３４〕状態要求で指定された資源が使用可能状態か、使用不可能状態かを判別する。使用可能状態であればステップＳ３５に進み、使用不可能状態であればステップＳ３６に進む。
〔Ｓ３５〕状態要求で指定された資源が使用可能である旨を状態管理部に通知する。
〔Ｓ３６〕状態要求で指定された資源が使用不可能である旨を状態管理部に通知する。
【００４８】
図１４は資源の状態の変化により状態通知を出力する際の状態管理エージェントの処理手順を示すフローチャートである。
〔Ｓ４１〕振り分け資源（ロードシェアシステムで機能を分散させるべき資源）の状態の変化を検出する。
〔Ｓ４２〕状態遷移が発生し、状態遷移出口を起動する。
〔Ｓ４３〕状態遷移の状況を状態管理部に通知する。
〔Ｓ４４〕他の資源に状態の変化があるか否かを判断し、状態が変化した資源があればステップＳ４１に進み、状態が変化した資源がなければステップＳ４５に進む。
〔Ｓ４５〕状態管理パスを解放し、状態遷移通知出口を削除する。
【００４９】
以上のようにして、サーバ内のアプリケーションの状態を通信制御装置１００で一括管理することができる。この方式では、管理簿内のＩＤにより管理対象を特定し、サーバシステムに適した状態管理エージェントを配置することにより、サーバシステムの種別に依存せずに通信制御装置１００でアプリケーションを一括管理することができる。例えば、サーバシステムが大型のホスト計算機であっても、ＵＮＩＸのシステムであってもよい。
【００５０】
また、管理簿内のＩＤにより管理対象を特定し、サーバシステムに適した状態管理エージェントを配置することにより、アプリケーションの通信プロトコルに依存せずに管理することができる。
【００５１】
次に、第３の機能である、上記第１の機能と第２の機能とを併用した機能について説明する。この機能では、通信制御装置１００が一括管理している各サーバの管理情報に基づき、利用者からの要求を適当なサーバへ振り分けることにより、負荷配分の最適化を図る。
【００５２】
図１５は一括管理された管理情報に基づき利用者からの要求を振り分ける処理の概念図である。図において、状態管理エージェント１３，２３，３３と状態管理部１１１との間には通信パス９４〜９６が確立されている。これにより、各サーバ１０，２０，３０内のアプリケーション１１，２１，３１の動作状態は、状態管理部１１１で一括管理される。それらの状態管理情報は記憶装置１２０内に管理簿として格納されている。
【００５３】
そして、利用者の端末６１，６３，６４からＤＢ４２，４３に対する要求７６，７６ａが出力されると、その要求は通信媒体４６を介して振り分け処理部１１２に入力される。振り分け処理部１１２は、状態管理部１１１から各アプリケーション１１，２１，３１の現在の状態の情報を取得し、その情報から各サーバへの負荷が分散するように、要求を実行させるアプリケーションを特定する。そして、特定したアプリケーションに対して要求７７〜７９を出力する。要求を受け取ったアプリケーションは、要求内容に従ってＤＢ４２，４３を処理する。
【００５４】
ここで、振り分け処理部１１２では、利用者からの要求の一部を振り分けキーとし、振り分けキーに対応付けた振り分け先候補とその所在を管理しておく。図１６は振り分け処理のフローチャートである。なお、ステップＳ５１〜ステップＳ５９までの処理は、振り分け処理部が実行する。ステップＳ６０の処理はトランザクション処理であればアプリケーションが実行し、コネクション処理であればアプリケーションと利用者の端末とにより実行される。
〔Ｓ５１〕ネットワーク利用者からのコネクション確立要求、またはトランザクション開始要求を受信する。
【００５５】
以下のステップは、サーバ側のコネクション確立処理、またはトランザクションの開始処理である。
〔Ｓ５２〕振り分けキー情報を取得する。
〔Ｓ５３〕振り分け先サーバ候補の抽出をする。
〔Ｓ５４〕振り分け先サーバ候補があるか否かを判断し、振り分け先サーバ候補があればステップＳ５６へ進み、振り分け先サーバ候補がなければステップＳ５５へ進む。
〔Ｓ５５〕振り分け先サーバ候補がない場合には、利用者からの要求がコネクション振り分けなら確立失敗とし、利用者からの要求がトランザクションの振り分けなら一定時間保留とし、時間経過後再度ステップＳ５４へ進む。
〔Ｓ５６〕振り分け先サーバ候補があれば、振り分け先サーバを決定する。
〔Ｓ５７〕サーバ側コネクションの確立、またはトランザクションの振り分け処理を行う。
〔Ｓ５８〕コネクション確立が成功したか否かを判断し、成功であればステップ６０へ進み、失敗であればステップＳ５９へ進む。なお、要求がトランザクション処理であればこのステップは実行せず、ステップＳ６０に進む。
〔Ｓ５９〕コネクション確立が失敗の場合には、振り分け候補から失敗したサーバを除外し、ステップＳ５４に進む。
〔Ｓ６０〕コネクション確立が成功の場合には、データ通信またはトランザクション処理を実行する。
【００５６】
次に、振り分けキーの取得処理について詳しく説明する。図１７は振り分けキーの取得処理を示す図である。振り分け処理部１１２は状態管理部１１１を有している。状態管理部１１１では、振り分けキーごとに振り分け先候補とこの所在を管理している。
【００５７】
利用者からの要求７５は、まず振り分け処理部１１２に入力される。振り分け処理部１１２では、要求の中から振り分けキー７５ａを抽出する。振り分けキー７５ａは、状態管理部１１１に送られる。状態管理部１１１は、振り分けキー７５ａに対応する振り分け先候補とその所在に関する情報１１２ｂを抽出し、振り分け処理部１１２へ渡す。振り分け処理部１１２は、情報１１２ｂに基づき要求７５の振り分け先を決定する。
【００５８】
なお、上記の例では要求の一部の文字列を振り分けキーとしているが、その文字列を端末名と組み合わせたり、ネットワーク利用者のデータや業務の名前など、様々なものを振り分けキーとすることができる。
【００５９】
以上のように、振り分けキーは利用者からのコネクションの確立要求やトランザクション開始時に受け付けた要求から抽出される。抽出する情報は通信プロトコルや振り分けの種類に応じて以下のように設定している。
【００６０】
コネクション振り分けにおいて、通信プロトコルがＦＮＡ（富士通ネットワークアーキテクチャ）の場合、宛て先（業務名）、通信元ネットワーク利用者名である。具体的には、業務の論理的な名前＋端末名（端末グループ）、業務の論理的な名前＋端末名＋端末の属するシステムのアドレス、業務の論理的な名前＋端末名＋端末の属するシステムのアドレス＋ユーザデータ内の任意のデータ等である。
【００６１】
コネクション振り分けにおいて、通信プロトコルがＯＳＩ（Open System Interconnection ）の場合には、宛て先のアドレスと通信元のアドレスである。具体的には、業務のＴ−ＳＡＰアドレスと通信元のＮＳＡＰアドレス（ＯＳＩにおけるネットワーク層のアドレス）である。
【００６２】
ＴＣＰコネクション振り分けにおいて、通信プロトコルがＴＣＰ／ＩＰの場合には、クライアントが確立した通信制御装置上のポート番号、送信元ネットワーク利用者名である。
【００６３】
トランザクションの振り分けの場合には、トランザクション処理における業務名、トランザクション開始時のメッセージの内容である。
なお、振り分けキーとして選択するデータを、アクセス種別（排他、共用、照会、更新等）と対応付けることで、システム全体のトランザクション性能やＤＢアクセスでの負荷の分散を図ることができる。
【００６４】
ところで、キーとなる情報がサーバとの間でのコネクションの確立要求に含まれていない場合、つまりトランスポート層よりも上位レベルの情報をキーとする場合には、利用者の端末側からトランスポート層の確立要求が送られただけでは、振り分け先を特定することができない。従って、従来のように端末とサーバのトランスポート層での接続を完了してから上位レベルの通信を行うという手順を踏むことができない。そこで本発明では、この問題を以下の方法で解決する。
【００６５】
図１８は上位レベルの情報をキーとする場合のコネクション手順を示す図である。図において、まずネットワーク利用者の端末からトランスポート層の確立要求が出力される。通信制御装置は端末との間のトランスポートコネクションのみを確立し、サーバとのコネクションは保留にする。次いで、端末から上位レベルの確立要求が出力される。通信制御装置は、その要求からキーを抽出し、振り分けるべきサーバを特定する。サーバを特定したら、そのサーバとの間でトランスポート層のコネクションと上位レベルのコネクションとを順次確立する。最後に、端末との間の上位レベルのコネクションを確立する。以後は、端末とサーバ間でデータ転送が行われる。
【００６６】
このように、サーバとの間のトランスポート層のコネクションの確立を一時的に保留することにより、上位レベルのデータに含まれる詳細な情報を基に振り分け先を選択することができ、より信頼性の高い負荷分散を行うことができる。
【００６７】
次に、振り分け先サーバ候補の抽出処理の詳細を説明する。図１９は振り分け先サーバ候補の抽出される情報のリンク状態を示す図である。まず、振り分け候補グループ５１０から振り分け候補（１）５２１に繋がっている。さらに、振り分け候補（１）５２１から振り分け候補（２）５２２へ繋がっている。以後、同様に最後の振り分け候補（ｎ）５２３までが順に繋がっている。各振り分け候補５２１〜５２３には、業務情報５３１〜５３３、パス情報５４１〜５４３、サーバ情報５５１〜５５３が順に繋がっている。
【００６８】
振り分けサーバを決定する際には、図１９の振り分け候補の情報から、以下の全ての条件を満たすものを候補として選択する。
第１に、振り分け情報が抑止状態（停止状態）でないこと。第２に、カレントセション数が最大振り分け数を超えていないこと。第３に、パス情報が抑止状態（停止状態）でないこと。第４に、業務状態が抑止状態（停止状態）でないこと。第５に、業務内のアプリケーションの状態が非活性状態でないこと。
【００６９】
図１９では、各種振り分け情報ごとに状態情報を有している。例えば、抑止状態、アプリケーションの動作状態等である。このような状態情報を業務等の情報にまで持たせたのは、情報ごとに対応する資源への振り分けを抑止できるようにするためである。例えば、特定の業務のみ振り分けを一時的に抑止可能としたり、サーバ単位に振り分けを抑止可能とする。
【００７０】
次に、選択された振り分け候補の中からの、振り分け先サーバの決定方法を説明する。振り分け候補の中から、以下に論理式に従って求めた分散比率の最も少ないものを振り分け先と決定する。
【００７１】
【数１】
｛（ＴＣn ＋１）／Ｒn ｝×１００ ・・・・・（１）
ここで、ＴＣn はｎ番目の振り分け候補のサーバでの振り分け済セション数であり、Ｒn はｎ番目の振り分け候補のサーバ分散比率である。
【００７２】
なお、式（１）の値が同じ振り分け候補のサーバが複数存在した場合には、次のように取り扱う。コネクションの振り分けの場合には、最後に振り分けを行ったサーバの次のサーバに決定する。トランザクション振り分けの場合には、過去の振り分け実績（振り分けたトランザクション数）が一番少ないサーバに決定する。これは、一時点で振り分けるセションやトランザクションが候補となるサーバ数よりも少なく、かつ、セションは何度も確立解放を繰り返すような運用を行ったときに、すべてのサーバへの振り分けを可能とするためである。
特別な振り分けとして、同一のクライアントとサーバ（またはサーバ内のアプリケーション）との間で複数のセションが確立する運用では、上記のような論理によらず、１つ目のセションと同じサーバへの振り分けを行うこともできる。なお、両者の選択は通信プロトコルの違いにより実現するか、あるいは、予め定義しておく。これによれば、同じクライアントとサーバとの間で、複数の業務を同時に連携して行う場合に有効となる。
【００７３】
また、トランザクションの振り分けにおいて、振り分け候補が１つもない場合には、振り分けを保留することができる。具体的には、振り分け候補が１つもないか、または、最大振り分け数を超えたものがある場合には、トランザクション開始要求を一定の保留時間だけ保留する。なお、保留するトランザクション開始要求は、保留可能な要求数の範囲内でなければならない。また、保留時間については、トランザクション要求毎に保留時間の変更が可能である。
【００７４】
これにより、瞬間的にトランザクション要求が大量に発生した場合のサーバへの過負荷が防止できるとともに、ホットスタンバイ時のシステム切り換え時にトランザクション要求を失敗させずにすむ。
【００７５】
次に第４の機能である業務の運用を切り換えることにより、サーバ間の効率的な負荷の分散を行う機能について説明する。この機能を実行するには、図２に示す振り分け処理部１１２に対して各種条件の定義を入力する。この定義では、各サーバのアプリケーションへの振り分け条件をグループ化する。このグループ化により、複数の振り分け条件をまとめて管理することができる。
【００７６】
さらに、振り分け条件グループの定義に「振り分け状態」を持たせる。そして、振り分け処理部１１２は、振り分け先の決定に使用する振り分け条件グループを「活性状態」に、振り分け先の決定に使用しない振り分け条件グループを「非活性状態」にすることにより業務の振り分けを管理する。このとき、各振り分け条件グループは業務の運用に対応している。
【００７７】
図２０は振り分け処理部１１２に入力する振り分け定義の例を示す図である。この例では、実資源の定義として、サーバ１０，２０，３０をそれぞれ「サーバＸ」、「サーバＹ」、「サーバＺ」と名付けており、各サーバ１０，２０，３０内で業務を実行するアプリケーション１１，２１，３１を、それぞれ「業務プログラムＡ（業務Ａ）」、「業務プログラムＢ（業務Ｂ）」、「業務プログラムＢ（業務Ｂ）」と名付けている。ここで、サーバ２０とサーバ３０とは同じ業務を提供しており、ロードシェア形態をとっている。
【００７８】
振り分けの定義において、「業務Ａ」は、「振り分け条件グループＡ１（振り分け状態＝活性）」と「振り分け条件グループＡ２（振り分け状態＝非活性）」とに分かれている。「振り分け条件グループＡ１」の振り分け条件は「振り分け条件Ａ１Ｘ（最大１００）」であり、「振り分け条件グループＡ２」の振り分け条件は「振り分け条件Ａ２Ｘ（最大５０）」である。「業務Ｂ」は、「振り分け条件グループＢ１（振り分け状態＝活性）」と「振り分け条件グループＢ２（振り分け状態＝非活性）」とに分かれている。「振り分け条件グループＢ１」の振り分け条件は「振り分け条件Ｂ１Ｙ（最大１００）」、「振り分け条件Ｂ１Ｚ（最大１００）」である。一方、「振り分け条件グループＢ２」の振り分け条件は「振り分け条件Ｂ２Ｙ（最大５０）」、「振り分け条件Ｂ２Ｚ（最大５０）」である。
【００７９】
ここで、振り分け条件の最後のアルファベットが業務を実行するサーバを示しており、「最大」とはそのサーバへの振り分けが許される要求の最大数を示している。
【００８０】
振り分け処理部１１２は、振り分け状態が活性である振り分け条件グループの定義を使用して振り分け先のサーバを決定する。運用の切り換えは、活性状態の振り分け条件グループを非活性状態とし、新しい運用に使用すべき振り分け条件グループを活性状態とすることにより行う。
【００８１】
図２１は図２０に示した振り分け定義による運用の切り換え状況を示す図である。なお、運用の切り換え状況を説明する図（図２１、図２４、図２６、図２８、図３０、図３４）では、各サーバ１０，２０，３０とアプリケーション１１，２１，３１とには、その時の定義で与えられている名称を表記している。従って、与えられている定義によって、図中のサーバ等の表記も異なる。
【００８２】
「振り分け条件グループＡ１」と「振り分け条件グループＢ１」が活性状態の場合（図中、上側）では、利用者の端末６３，６４等からの業務Ａの要求１４０は全てサーバ１０に対する要求１４１となり、処理できる最大の要求数は「１００」である。業務Ｂの要求１５０は、サーバ２０とサーバ３０とに対する要求１５１，１５２となり、サーバ２０，３０の処理できる最大の要求数はそれぞれ「１００」ずつである。
【００８３】
ここで運用を「振り分け条件グループＡ２」と「振り分け条件グループＢ２」とを活性状態にすると（図中、下側）では、業務Ａの要求１４０ａは全てサーバ１０に対する要求１４１ａとなり、処理できる最大の要求数は「５０」である。業務Ｂの要求１５０ａは、サーバ２０とサーバ３０とに対する要求１５１ａ，１５２ａとなり、サーバ２０，３０の処理できる最大の要求数はそれぞれ「５０」ずつである。
【００８４】
ところで、上記の説明では各振り分け条件グループの状態（活性／非活性）を個々に切り換えることにより運用を切り換えているが、各分け条件グループを予め運用と対応づけておくことにより、運用の切り換え制御を簡略化することができる。
【００８５】
図２２は振り分け条件グループと運用とを対応づけた場合の定義の例を示す図である。この例の定義は、図２０に示したものと殆ど同じであるため、相違点のみを説明する。図２０では各振り分け条件グループには振り分け状態が設定されていたが、図２２の各振り分け条件グループには運用名が設定されている。この例では、「振り分け条件グループＡ１」は「運用α」、「振り分け条件グループＡ２」は「運用β」、「振り分け条件グループＢ１」は「運用α」、「振り分け条件グループＢ２」は「運用β」である。そして、図２２で追加された項目として運用の振り分け状態の設定がある。図では、「運用α」の振り分け状態が「活性」、「運用β」の振り分け状態が「非活性」である。
【００８６】
そして、振り分け制御部１１２は、運用の振り分け状態を変更することにより運用の切り換えを行うことができる。従って、個々の振り分けグループを管理する必要がなく、切り換えの制御が簡略化される。
【００８７】
さらに、振り分け条件グループの定義にユーザの指定を追加し、ネットワークの利用者を指定することもできる。その場合、振り分け条件グループのユーザの指定には、ネットワーク利用者の端末名、ワイルドカード（＊）、及び任意の端末群をグループ化したユーザグループに定義付けられた名前等を指定することができる。なお、ワイルドカードは、全ての利用者を振り分け可能であることを意味する。また、要求の一部をキーとして指定することにより、そのキーを有する要求を対象とすることもできる。
【００８８】
図２３はユーザの指定を追加した振り分け定義を示す図である。この例では簡単のために２つのサーバ１０，２０で説明する。
実資源の定義として、サーバ１０，２０をそれぞれ「サーバＸ」、「サーバＹ」とし、各サーバ１０，２０内で業務を実行するアプリケーション１１，２１を、それぞれ「業務Ａ」、「業務Ｂ」と定義している。
【００８９】
振り分けの定義において、「業務Ａ」は、「振り分け条件グループＡ１１（運用＝運用α、ユーザ＝端末群１）」、「振り分け条件グループＡ１２（運用＝運用α、ユーザ＝端末群２）」、及び「振り分け条件グループＡ２（運用＝運用β、ユーザ＝＊）」に分かれている。「振り分け条件グループＡ１１」の振り分け条件は「振り分け条件Ａ１１Ｘ（最大５０）」であり、「振り分け条件グループＡ１２」の振り分け条件は「振り分け条件Ａ１２Ｘ（最大５０）」であり、「振り分け条件グループＡ２」の振り分け条件は「振り分け条件Ａ２Ｘ（最大５０）」である。
【００９０】
「業務Ｂ」は、「振り分け条件グループＢ１１（運用＝運用α、ユーザ＝端末群１）」、「振り分け条件グループＢ１２（運用＝運用α、ユーザ＝端末群２）」、「振り分け条件グループＢ２１（運用＝運用β、ユーザ＝端末群１）」、「振り分け条件グループＢ２２（運用＝運用β、ユーザ＝端末群２）」とに分かれている。「振り分け条件グループＢ１１」の振り分け条件は「振り分け条件Ｂ１１Ｙ（最大５０）」、「振り分け条件グループＢ１２」の振り分け条件は「振り分け条件Ｂ１２Ｙ（最大５０）」、「振り分け条件グループＢ２１」の振り分け条件は「振り分け条件Ｂ２１Ｙ（最大２５）」、「振り分け条件グループＢ２２」の振り分け条件は「振り分け条件Ｂ２２Ｙ（最大２５）」である。
【００９１】
図では、運用αの振り分け状態が活性であり、運用βの振り分け状態が非活性である。
このような定義が設定された状態で、振り分け処理部１１２は、利用者からの要求に付加されるユーザ情報や要求内容と活性状態の振り分け条件とを対比することにより、振り分け先を決定する。そして、運用の振り分け状態を変更することにより、運用を切り換えることができる。
【００９２】
図２４はユーザの指定を追加した振り分け定義による運用の切り換え状況を示す図である。ここで、端末６３，６４は第１の端末群１８１に含まれ、端末６５，６６は第２の端末群１８２に含まれている。
【００９３】
［運用α］の状態では、第１の端末群１８１から業務Ａへの要求１６０は全てサーバ１０への要求１６２となり、最大の要求数は「５０」である。第１の端末群１８１から業務Ｂへの要求１７０は全てサーバ２０への要求１７２となり、最大の要求数は「５０」である。第２の端末群１８２から業務Ａへの要求１６１は全てサーバ１０への要求１６３となり、最大の要求数は「５０」である。第２の端末群１８２から業務Ｂへの要求１７１は全てサーバ２０への要求１７３となり、最大の要求数は「５０」である。
【００９４】
ここで、運用が切り換えられ［運用β］になると、第１の端末群１８１から業務Ａへの要求１６０ａと第２の端末群１８２から業務Ａへの要求１６１ａとは、全てサーバ１０への要求１６４となる。そして、要求１６４の最大の要求数は、双方の端末群からの総要求数で換算して「５０」である。一方、第１の端末群１８１から業務Ｂへの要求１７０ａは全てサーバ２０への要求１７２ａとなり、最大の要求数は「２５」である。第２の端末群１８２から業務Ｂへの要求１７１ａは全てサーバ２０への要求１７３ａとなり、最大の要求数は「２５」である。
【００９５】
この図に示すようにユーザを指定した運用の切り換えを行うことにより、利用者の利用頻度の地域格差を考慮した運用の切り換えが可能となる。
次に、第５の機能である、第１の機能で管理している各サーバの負荷状態に応じて、動的に振り分け条件を切り換える機能について説明する。運用操作部１１３は、状態管理部１１１が管理している各サーバの負荷状態等に応じて運用の切り換えを行うこともできる。この場合、アプリケーションの定義に「振り分け状態」の設定項目を設ける。この「振り分け状態」は、対応するアプリケーションの振り分けが可能な場合には「活性」とし、振り分けが不可能な場合には「非活性」とする。
【００９６】
図２５はアプリケーションの状態の定義を追加した振り分け定義を示す図である。この図では、実資源の定義として、サーバ１０，２０，３０をそれぞれ「サーバＸ」、「サーバＹ」、「サーバＺ」とし、各サーバ１０，２０，３０内で業務を実行するアプリケーション１１，２１，３１を、それぞれ「業務プログラムＡ（業務Ａ）」、「業務プログラムＢ（業務Ｂ）」、「業務プログラムＢ（業務Ｂ）」と定義している。さらに、各アプリケーション１１，２１，３１には振り分け状態が設定されており、図中では全て「活性」である。なお、振り分けの定義は、図２２に示した例と同じである。
【００９７】
ロードシェア形態の業務で特定のサーバのアプリケーションにトラブルが発生した場合、トラブルが発生したサーバ内に配置された状態管理エージェントから状態管理部１１１へアプリケーションに障害が発生した旨が通知される。状態管理部１１１は、障害の発生したアプリケーションの状態を「非活性」とする。
【００９８】
図２６はロードシェア形態でのトラブル対処の例を示す図である。図中のトラブル発生前の状態（図中、上側）は、図２１の［運用α］の状態と同じである。ただし、この図では、各サーバ１０，２０，３０内に状態管理エージェント１３，２３，３３を図示している。ここで、例えば、サーバ２０に障害が発生した場合には、サーバ２０内の状態管理エージェント２３が、通信制御装置１００内の状態管理部１１１にアプリケーション２１が使用できないことを通知する。状態管理部１１１は、アプリケーション２１の状態を「非活性」とする。これにより、利用者から業務Ｂへの要求がアプリケーション２１へ振り分けられることはなくなる。
【００９９】
トラブル発生後の状態（図中、下側）では、利用者から業務Ｂへの要求１５０は、全てサーバ３０に対する要求１５２ａとなる。ここで、サーバ２０のアプリケーション２１が復旧した場合には、サーバ２０内の状態管理エージェント２３がアプリケーション２１が復旧した旨を状態管理部１１１に通知する。状態管理部１１１は、その通知を受けてアプリケーション２１の振り分け状態を活性とする。これにより、アプリケーション２１に対する要求の振り分けが再開される。
【０１００】
このように、定義内に各アプリケーションの振り分け状態を設定しておき、振り分け処理部１１２は「活性」状態のアプリケーションの中から振り分け先を選択することにより、アプリケーションのメンテナンス時にも利用者に対する業務の提供を停止させずにすむ。
【０１０１】
次に、システム運用におけるサーバ障害発生時の運用について説明する。この場合、サーバの定義に「振り分け状態」を持たせ、振り分け可能な場合に「活性状態」、振り分け不可能な場合に「非活性状態」として管理する。
【０１０２】
図２７はホットスタンバイ切り換えを実現するための振り分け定義を示す図である。この例では、１つのデータベースを共有しているサーバ２０，３０のうち、サーバ２０を現用、サーバ３０を待機として運用している。実資源の定義として、サーバ２０，３０をそれぞれ「サーバＸ」、「サーバＹ」とし、各サーバ２０，３０内で業務を実行するアプリケーション２１，３１をともに「業務Ａ」と定義している。
【０１０３】
振り分けの定義において、「業務Ａ」は、「振り分け条件グループＡ１（運用名＝運用α）」と「振り分け条件グループＡ２（運用名＝運用β）」とに分かれている。「振り分け条件グループＡ１」の振り分け条件は「振り分け条件Ａ１Ｘ（最大１００）」と「振り分け条件Ａ１Ｙ（最大１００）」とであり、「振り分け条件グループＡ２」の振り分け条件は「振り分け条件Ａ２Ｘ（最大５０）」と「振り分け条件Ａ２Ｙ（最大５０）」とである。
【０１０４】
現在、「運用α」が活性状態であり、「運用β」が非活性状態である。
図２８はホットスタンバイ切り換えの状況を示す図である。２つのサーバ２０，３０が共に正常に動作している状態（図中、上側）では、端末６３，６４やシステム５１からの業務Ａの要求１４２は、現用であるサーバ２０への要求１４３として振り分けられている。この時、双方のサーバ２０，３０内の状態管理エージェント２３，３３は、定期的に通信を行う事により、互いに監視し合っている。従って、一方のサーバがダウンすると、他方のサーバ内の状態管理エージェントがそのことを検出する仕組みになっている。
【０１０５】
この状態において、現用のサーバ２０にトラブルが発生すると、サーバ２０からの通信が滞ったことをサーバ３０内の状態管理エージェント３３が検出し、サーバ２０がダウンしたことを認識する。すると、状態管理エージェント３３は通信制御装置１００の振り分けプログラム１１０（その中の状態管理部１１１）との間の通信パスを利用して、サーバ２０がダウンした旨を通信制御装置に通知する。通信制御装置１００の状態管理部１１１がその通知を受け取ると、それに応じて、運用操作部１１３がサーバ２０の振り分け状態を非活性状態に変更する。続いて、サーバ３０の振り分け状態を活性状態に変更する。これにより、待機サーバであったサーバ３０が新たに現用サーバとなる。従って、振り分け状態変更後（図中、下側）では、利用者の端末６３，６４等から出力された要求が、全てサーバ３０への要求１４４となる。
【０１０６】
この方式を使用して、各サーバの振り分け状態を順次操作することで、業務を停止せずにホットスタンバイ運用のメンテナンスを行うことができる。
次に、業務の振り分け先の決定を、様々な要素を考慮して行うこともできる。その決定のファクターとしては、例えば、サーバ間の相対振り分け比率、アプリケーションに対する最大振り分け数を指定する。
【０１０７】
サーバ間の相対振り分け比率とは、ロードシェア形態の各サーバ上のアプリケーション間の相対的な振り分け比率である。アプリケーションに対する最大振り分け数とは、アプリケーションがそのサーバで同時に処理可能な要求数である。
【０１０８】
ところで、振り分け処理部１１２は、利用者からの要求が全アプリケーションの最大振り分け数の合計を超えた場合に、いずれかのサーバのアプリケーションが振り分け可能になるまで、待ち合わせ（保留）を行う機能を有している。この際、要求を無制限に待ち合わせると、通信制御装置が資源枯渇したり、ネットワーク利用者の端末がハングする事態が生じる。
【０１０９】
そこで、振り分け条件グループに、業務の最大処理数を超えた場合の処理を決定するためのファクターとして「要求の最大保留数」と「要求の最大保留時間」を指定する。この指定により、待ち合わせの上限が設定される。従って、待ち合わせが「要求の最大保留数」と「要求の最大保留時間」とのいずれかを超えた場合には、振り分け処理部１１２から利用者に対して処理不能の旨の応答を返し、利用者からの要求を失敗させる。
【０１１０】
上記の２つの指定（「要求の最大保留数」，「要求の最大保留時間」）は、利用者からの要求を受信した際に振り分け先を決定するために使用する情報であり、運用中に変更操作を行っても利用者に悪影響を及ぼさない。振り分け処理部１１２は、これらの２つの指定を動的に変更することにより、振り分け配分を最適に保つことができる。
【０１１１】
図２９は振り分け配分の動的な変更を行うための定義の例を示す図である。この例では、実資源の定義として、サーバ２０，３０をそれぞれ「サーバＸ」、「サーバＹ」とし、各サーバ２０，３０内で業務を実行するアプリケーション２１，３１を、共に「業務Ａ」と定義している。この２つのサーバ２０，３０はロードシェア形態をとっている。
【０１１２】
振り分けの定義において、業務Ａには振り分け条件グループＡ１（最大保留数＝５，最大保留時間６０）が定義されている。振り分け条件グループＡ１には、２つの振り分け条件として、振り分け条件Ａ１Ｘ（振り分け比率＝３，最大振り分け数＝１００）と振り分け条件Ａ１Ｙ（振り分け比率＝３，最大振り分け数＝１００）が設定されている。
【０１１３】
さらに、変更内容が設定されており、その内容は、振り分け条件Ａ１Ｙに対して、振り分け比率を「３」→「１」、最大振り分け数を「１００」→「５０」とするものである。
【０１１４】
図３０は振り分け配分の動的な変更状況を示す図である。通常動作時（図中、上側）は、利用者からの要求が、アプリケーション２１への要求１９０とアプリケーション３１への要求１９１とに均等に割り振られている。ここで、サーバ３０に臨時業務３５が発生すると（図中、下側）、アプリケーション３１への振り分け比率が「１」になる。従って、アプリケーション２１への要求１９０ａはアプリケーション３１への要求１９１ａの３倍となる。
【０１１５】
以上の説明が、図２に示したマルチサーバシステムで行うことができる各種処理機能である。ここで、通信制御装置１００内の振り分けプログラム１１０とサーバ内の状態管理エージェントの内部構成について説明する。
【０１１６】
図３１は振り分けプログラムと状態管理エージェントの内部構成を示すブロック図である。サーバ３０の状態管理エージェント３３は、他サーバ監視部３３ａ、アプリケーション監視部３３ｂ、コマンド機能部３３ｃ、及び通信制御機能部３３ｄを有している。他サーバ監視部３３ａは、サーバ１０，２０内の他サーバ監視部と通信を行っており、互いに正常に動作していることを確認し合っている。アプリケーション監視部３３ｂは、サーバ３０内の複数のアプリケーション３１，３１ａの動作状況を監視している。コマンド制御部３３ｃは、操作端末３０ａからのコマンド入力に応じて、各種命令を出力する。通信制御機能部３３ｄは、ＬＡＮ４１を介した通信を制御する。
【０１１７】
振り分けプログラム１１０は、図２に示した状態管理部１１１、振り分け処理部１１２、運用操作部１１３に加え、通信制御部１１４とコマンド機能部１１５とを有している。通信制御部１１４は、ＬＡＮ４１を介した通信を制御する。コマンド機能部１１５は、操作端末１０５からのコマンド入力に応じて、サーバに対する状態要求等を出力する。また、操作端末１０５からの入力により、運用切り換え命令を運用操作部１１３に出力する。運用操作部１１３は運用切り換え命令に従って、運用の切り換えを行う。
【０１１８】
以上の説明が、１台の通信制御装置によりロードシェアシステムを構成した場合である。以下に、２台の通信制御装置によりロードシェアシステムを構成した場合を説明する。まず、２台の通信制御装置で１システムビューを実現する場合を以下に示す。
【０１１９】
図３２は２台の通信制御装置を有するマルチサーバシステムを示す図である。このシステムには、ロードシェア運用を行っている３台のサーバ２１０，２２０，２３０と２台の通信制御装置２４０，２５０がＬＡＮ２０２を介して接続されている。通信制御装置２４０，２５０は、通信媒体２０３を介して他のシステム２６０，２７０と接続されている。
【０１２０】
サーバ２１０，２２０，２３０は、同じ業務を行うアプリケーション２１１，２２１，２３１を有しており、このアプリケーション２１１，２２１，２３１によって１つのデータベース（ＤＢ）２０１を共有している。また、各サーバ２１０，２２０，２３０は、それぞれ異なるアドレスを有している。通信制御装置２４０，２５０は、それぞれ振り分けプログラム２４１，２５１を有している。また、通信制御装置２４０，２５０は同じ通信アドレスを有している。サーバからサービスを受けるシステム２６０，２７０は、それぞれアプリケーション２６１，２７１を有している。
【０１２１】
このような構成により、システム２６０内で動作するアプリケーション２６１が、サーバ２１０，２２０，２３０内のアプリケーション２１１，２２１，２３１と振り分け機能を利用して通信する。
【０１２２】
このような運用では、アプリケーション２６１と通信制御装置との間に確立するコネクションは、通信アドレスＮと通信アドレス（４）との通信アドレスペアのコネクション上に、複数の上位レベルのコネクションを確立することができる。そのため、個々のコネクションを識別するための識別子が必要となる。
【０１２３】
ここで、２台の通信制御装置２４０，２５０がそれぞれ上位レベルのコネクションに「１０」を割り振ったとする。すると、ネットワークの利用者である通信相手のシステム２６０では、コネクションの確認ができなくなる。
【０１２４】
この問題を回避するために、通信制御装置２４０，２５０のそれぞれが管理する上位の通信資源の範囲を、定義等によって重複しないようにする。通信資源を分割する方法としては、以下の３パターンが考えられる。
【０１２５】
第１の方法は定義を用いる方法である。これは、通信制御装置２４０，２５０での管理範囲をそれぞれの通信制御単位に事前に定義することで分割管理を実現する方法である。
【０１２６】
例えば、トランスポート層のレファレンス値は、通信時のＮＳＡＰアドレス単位に１〜６５５３５までの値であるため、これを４分割して、その２つをそれぞれ通信制御装置２４０，２５０に定義する。残りの２つのブロックは、将来の通信制御装置の増設用に未割当とする。
【０１２７】
第２の方法は管理プログラムによる方法である。この方法では、上位レベルの資源の分割範囲を管理するプログラムと、各通信制御装置内の通信制御プログラムとで、動的に分割範囲を獲得または配分する。
【０１２８】
図３３は管理プログラムによる通信資源の分割の状況を示す図である。通信制御装置２４０は、資源の分配管理プログラム２４２と通信制御・振り分けプログラム２４３とを有している。通信制御装置２５０は、通信制御・振り分けプログラム２５２を有している。
【０１２９】
各通信制御装置２４０，２５０内の通信制御・振り分けプログラム２４３，２５２は、システム起動時や上位レベルのコネクション確立時に振り分け処理部から資源の分割範囲を入手する。図の例では、通信制御・振り分けプログラム２４３には１〜１００が割り当てられ、通信制御・振り分けプログラム２５２には５０１〜６００が割り当てられている。
【０１３０】
第３の方法はコネクション確立時に分配する方法である。この方法では、上位レベル（トランスポート層）のコネクションの確立時に上位資源を管理するプログラム（図３３における分配管理プログラム２４２に該当する）から資源を獲得する。
【０１３１】
以上のいずれかの方法で、分配管理を実現することができる。
また、通信制御装置を２台設けた場合には、サーバの内の状態管理エージェントから各通信制御装置へ状態の変化を通知する。図３４は通信制御装置が２台ある場合のサーバからの通知による運用切り換え状況を示す図である。図において、２台のサーバ３１０，３２０と２台の通信制御装置３０１，３０２とは、ＬＡＮを介して接続されている。通信制御装置３０１，３０２には、それぞれ個別の通信媒体３４３，３４４を介して、端末３６１〜３６４や他のシステム３５１，３５２が接続されている。
【０１３２】
サーバ３１０，３２０内には、アプリケーション（業務プログラムＡ）３１１，アプリケーション（業務プログラムＢ）３２１と状態管理エージェント３１２，３２２が設けられている。通信制御装置３０１，３０２内には、振り分けプログラム３０１ａ，３０２ａが設けられている。
【０１３３】
切り換え前の状態（図中、上側）では、通信媒体３４３を介して送られてきた業務Ａ要求はサーバ３１０へ、業務Ｂの要求はサーバ３２０へ送られる。それらの最大は、共に１００である。同様に、通信媒体３４４を介して送られてきた業務Ａ要求はサーバ３１０へ、業務Ｂの要求はサーバ３２０へ送られる。それらの最大は、共に１００である。
【０１３４】
ここで、状態管理エージェント３１２から業務プログラムＡの利用率低下などの情報が、各通信制御装置３０１，３０２へ送られると、サーバ３１０へ送られる要求の最大数が抑制される。図では（図中、下側）、各通信制御装置３０１，３０２からの最大要求数が５０に制限されている。
【０１３５】
【発明の効果】
以上説明したように本発明では、通信網から送られた処理要求情報を、通信制御装置が、サーバの負荷状態を示す管理情報に基づいて活性状態にある振り分け条件にしたがって選択されたサーバの通信アドレスに送り、いずれかのサーバへ振り分けるようにしたため、利用者側がサーバの通信アドレスなどを認識している必要がなく、利用者にとっては１台のサーバが全ての機能を提供できるように認識でき（１システムビュー）利用者の負担が軽減するとともに、各サーバ間の業務の負荷分散の制御が一括管理できるようになる。
【０１３６】
また、各サーバ内へ要求を振り分けるための条件を活性化・非活性化させることにより運用の切り換えができるようにしたため、サーバ間の負荷の分散を考慮した運用の切り換えが容易となる。
また、活性状態にある振り分け条件において業務提供手段について利用者分類情報が指定されている場合に、利用者分類情報に合致する利用者からの処理要求情報のみをその業務提供手段を有するサーバに振り分けるようにしたため、利用者を指定した運用の切り換えができ、利用者の利用頻度の地域格差を考慮した運用の切り換えが可能となる。
【０１３７】
特に、各サーバに配置した状態管理代理手段が通信制御装置の状態管理手段へ、各サーバの状態を通知するようにすることで、各サーバの動作状況が状態管理手段で一括管理でき、サーバの動作状態をタイムリに把握することができるとともに、各サーバの通信プロトコルに依存せずに状態を管理することが可能となる。
【０１３８】
また、サーバの１つに障害が発生した場合には、他のサーバが障害を検出し通信制御装置にその旨を通知するようにすることで、サーバの障害を隠蔽することができる。従って、ユーザへのサービスを停止させずにサーバの追加、削除が可能となり、システムのスケーラビリティに対応可能となる。
【図面の簡単な説明】
【図１】本発明の原理構成図である。
【図２】本発明のロードシェアシステムの概略構成を示すブロック図である。
【図３】１システムビューの機能を示すブロック図である。
【図４】利用者が認識しているネットワーク網のイメージを示す図である。
【図５】通信制御装置内での通信アドレスのリンク状態を示す図である。
【図６】通信アドレスの変換方式を示す図である。
【図７】通信制御装置での一括管理機能の概略構成を示すブロック図である。
【図８】状態管理を行う際の処理手順を示すフローチャートである。これは、状態管理部が実行する処理である。
【図９】管理簿内の一例を示す図である。
【図１０】状態管理処理の概念図である。
【図１１】通信制御装置の状態要求の際のフローチャートである。
【図１２】状態通知を受け取った通信制御装置の処理手順を示すフローチャートである。
【図１３】通信制御装置からの要求により状態通知を出力する際の状態管理エージェントの処理手順を示すフローチャートである。
【図１４】資源の状態の変化により状態通知を出力する際の状態管理エージェントの処理手順を示すフローチャートである。
【図１５】一括管理された管理情報に基づき利用者からの要求を振り分ける処理の概念図である。
【図１６】振り分け処理のフローチャートである。
【図１７】振り分けキーの取得処理を示す図である。
【図１８】上位レベルの情報をキーとする場合のコネクション手順を示す図である。
【図１９】振り分け先サーバ候補の抽出される情報のリンク状態を示す図である。
【図２０】振り分け処理部に入力する振り分け定義の例を示す図である。
【図２１】図２０に示した振り分け定義による運用の切り換え状況を示す図である。
【図２２】振り分け条件グループと運用とを対応づけた場合の定義の例を示す図である。
【図２３】ユーザの指定を追加した振り分け定義を示す図である。
【図２４】ユーザの指定を追加した振り分け定義による運用の切り換え状況を示す図である。
【図２５】アプリケーションの状態の定義を追加した振り分け定義を示す図である。
【図２６】ロードシェア形態でのトラブル対処の例を示す図である。
【図２７】ホットスタンバイ切り換えを実現するための振り分け定義を示す図である。
【図２８】ホットスタンバイ切り換えの状況を示す図である。
【図２９】振り分け配分の動的な変更を行うための定義の例を示す図である。
【図３０】振り分け配分の動的な変更状況を示す図である。
【図３１】振り分けプログラムと状態管理エージェントの内部構成を示すブロック図である。
【図３２】２台の通信制御装置を有するマルチサーバシステムを示す図である。
【図３３】管理プログラムによる通信資源の分割の状況を示す図である。
【図３４】通信制御装置が２台ある場合のサーバからの通知による運用切り換え状況をしめす図である。
【符号の説明】
１ａ，１ｂ データベース
２，３，４ サーバ
２ａ，３ａ，４ａ 業務提供手段
２ｂ，３ｂ，４ｂ 状態管理代理手段
５ 通信媒体
６ 通信制御装置
６ａ 状態管理手段
６ｂ 振り分け手段
６ｃ 運用操作手段
７ 通信網
８ａ，８ｂ，８ｃ 利用者側装置
１０，２０，３０ サーバ
４１ ＬＡＮ
４２，４３ データベース
４４，４５ 通信媒体
５１，５２ システム
６１〜６４ 端末
１００ 通信制御装置
１１０ 振り分けプログラム
１１１ 状態管理部
１１２ 振り分け処理部
１１３ 運用操作部
【発明の属する技術分野】
本発明は複数のプロセッサで分散処理を行うロードシェアシステムに関し、特に通信媒体を介して構築されたロードシェアシステムに関する。
【０００２】
【従来の技術】
多数の利用者に様々な機能を提供する場合、サーバが利用者に提供する業務を複数のプロセッサに分散させることができる。このような分散処理を行うシステムをロードシェアシステムと呼ぶ。このロードシェアシステムをローカル・エリア・ネットワーク（ＬＡＮ）に接続された複数のサーバで構築することも行われている。ここで業務とは、サーバがアプリケーションプログラム（以後、単に「アプリケーション」と呼ぶ）を実行することにより、利用者に代わってデータ処理を行う際の処理単位をいう。
【０００３】
従来のＬＡＮで構築されたロードシェアシステムでは、複数のサーバ間の負荷の分散の割合は、予めネットワーク上で定義付けられており実質的に固定である。つまり、システムの負荷の分散を自由に制御することはできない。
【０００４】
従って、業務の運用を切り換えるには、サーバ単位にアプリケーションを操作するか、あるいは各サーバの持つネットワーク資源を操作していた。サーバのアプリケーションを操作する場合は、そのアプリケーションの起動・停止、及び受け付ける業務の数の変更等の操作を行う。ネットワーク資源を操作する場合は、その各サーバ上のネットワーク資源を個々に活性化あるいは非活性化の操作を行う。
【０００５】
一方、システムの利用者が業務の提供を受けるには、複数のサーバの個々にアクセスする必要がある。個々のサーバにアクセスするには、それぞれのサーバの通信アドレスや業務が設けられている構成などを利用者側で認識していなければならない。
【０００６】
【発明が解決しようとする課題】
しかし、従来のロードシェアシステムでは負荷の分散を一括して制御できないため、システムの運用状況の変化に応じた負荷分散の制御ができず、システムの運用効率の悪化や信頼性の低下を招いていた。つまり、業務が１つのサーバに集中したり、バッチ処理等の臨時業務が発生すると、利用者側でのレスポンスが悪化する場合があった。また、アプリケーションやサーバ自身に障害が発生すると、利用者からの要求が拒否される場合があった。
【０００７】
なお、システムの管理者が各サーバごとに資源などを操作することにより負荷の配分を変更することは可能であったが、それには利用者がどのサーバのどの業務に集中しているのかをその都度的確に判断しなければならない。運用中のサーバの負荷は常に変動するため、システムの管理者が常に的確な判断を行いロードシェアシステムの負荷分散を最適化することは困難である。
【０００８】
一方、利用者にとっては、個々のサーバにアクセスしなければならないため、利用者側の端末においても複雑な通信環境の設定を行う必要があり、利用者の負担が大きいという問題点があった。
【０００９】
本発明はこのような点に鑑みてなされたものであり、運用効率を最適に保ち高い信頼性を有する、ＬＡＮを介して構築されたロードシェアシステムを提供することを目的とする。
【００１０】
【課題を解決するための手段】
本発明では上記課題を解決するために、通信媒体に接続された複数のサーバと、前記通信媒体及び該通信媒体とは異なる通信網との通信を行う通信制御装置とを有するロードシェアシステムであって、個々の前記サーバは、前記通信媒体を介して送られてきた処理要求に伴う業務を提供する業務提供手段と、前記業務提供手段の使用状態を基にした自己の負荷情報を、前記通信媒体を経由して前記通信制御装置へ送信する状態管理代理手段と、を有し、前記通信制御装置は、前記通信媒体を経由して送られてくる前記サーバからの負荷情報を基に、前記サーバの管理情報を管理する状態管理手段と、活性状態もしくは非活性状態にある複数の振り分け条件を有しており、前記通信網から前記通信制御装置の宛先通信アドレスを有する処理要求情報が到来した場合、該処理要求情報の宛先通信アドレスを、前記管理情報を基に活性状態にある前記振り分け条件にしたがって選択した前記サーバの通信アドレスに変換し、前記通信媒体を経由して送信する振り分け処理を行う振り分け手段と、前記振り分け手段が有する個々の前記振り分け条件に対し、活性化もしくは非活性化させる運用操作手段と、を有し、前記振り分け手段は、活性状態にある前記振り分け条件において所定の利用者分類情報が指定された前記業務提供手段に対しては、前記利用者分類情報に合致する利用者からの前記処理要求情報のみを振り分ける、ことを特徴とするロードシェアシステムが提供される。
【００１１】
この構成によれば、利用者端末から通信制御装置宛に送られた処理要求情報は、通信制御装置で処理要求情報の宛先通信アドレスを、管理情報を基に活性状態にある振り分け条件にしたがって選択したサーバの通信アドレスに変換し、通信媒体を経由して送信することにより、いずれかのサーバへ振り分けられる。従って、利用者側が個々のサーバの通信アドレスなどを認識している必要がないとともに、活性もしくは非活性を切り換えることによりサーバ間の効率的な負荷分散を行うことができる。また、活性状態にある振り分け条件において業務提供手段について利用者分類情報が指定されている場合、利用者分類情報に合致する利用者からの処理要求情報のみがその業務提供手段を有するサーバに振り分けられる。従って、利用者を指定した運用の切り換えを行うことにより、利用者の利用頻度の地域格差を考慮した運用の切り換えが可能となる。
【００１４】
【発明の実施の形態】
以下、本発明の実施の形態を図面に基づいて説明する。
図１は本発明の原理構成図である。サーバ２は、データベース（ＤＢ）１ａを有している。サーバ３，４は、共用のデータベース１ｂを有している。これら複数のサーバ２，３，４は、通信媒体５を介して送られた処理要求を処理する業務提供手段２ａ，３ａ，４ａと、自己の動作状態を管理する状態管理代理手段２ｂ，３ｂ，４ｂとを有している。
【００１５】
通信制御装置６において、状態管理手段６ａは、状態管理代理手段２ｂ，３ｂ，４ｂとの間で通信媒体５を介した通信パスを確立し、通信パスを用いて各サーバ２，３，４の状態を示す管理情報を状態管理代理手段から受け取り、サーバ２，３，４の状態を一括管理する。振り分け手段６ｂは、通信網７を介して接続されている利用者側装置８ａ，８ｂ，８ｃからの要求を受信し、状態管理手段６ａが管理している情報に基づき要求の振り分け先を決定し、要求をサーバ２，３，４に対する処理要求として通信媒体５を介して送信する。運用操作手段６ｃは、業務提供手段２ａ，３ａ，４ａに要求を振り分けるための複数の条件の活性化又は非活性化の状態切り換えを行う。
【００１６】
このような構成において、各サーバ２，３，４の動作状況は状態管理代理手段２ｂ，３ｂ，４ｂから状態管理手段６ａに送られ、状態管理手段６ａは各サーバ２，３，４の動作状況を一括管理する。そして、利用者側装置８ａ，８ｂ，８ｃから出力された要求は、通信網７を介して通信制御装置６に送られる。通信制御装置６内では、振り分け手段６ｂが現在活性状態となっている条件に基づいて要求の振り分け先を決定し、出力を受けた要求を、振り分け先として決定したサーバの業務提供手段への処理要求として、該当するサーバへ送信する。処理要求を受け取ったサーバの業務提供手段は、処理要求の内容に従って、データベースを操作する。また、各サーバ２，３，４の動作状況に変化が生じ、負荷配分を変える必要が生じた場合には、運用操作手段６ｃが、振り分け比率等の振り分けの条件を操作する。
【００１７】
このようにして、利用者はこのシステムが複数のサーバによるロードシェアシステムであることを意識せずにすむ。また、通信制御装置６は、状態管理代理手段２ｂ，３ｂ，４ｂから各サーバ２，３，４内の状態に関する情報を収集しているため、最適な負荷の分散を行うことができる。さらに、運用操作手段６ｃが、振り分け条件の活性化・非活性化の切り換えを行うことにより、様々な状況の変化に対して直ぐに適切な対処をすることが可能となり、システムの負荷の配分を最適化することができる。
【００１８】
ところで、上記のロードシェアシステムを実現するためのハードウェア構成として、通信制御装置が１台の場合と複数台の場合とが考えられる。以下の説明では、まず通信制御装置が１台の場合について説明し、その後通信制御装置が複数台の場合について説明する。
【００１９】
図２は本発明のロードシェアシステムの概略構成を示すブロック図である。これは、通信制御装置が１台の場合の構成である。この図には１つのローカルエリアネットワーク（ＬＡＮ）４１と２つの通信媒体４４，４５が示されている。ＬＡＮ４１には、複数のサーバ１０，２０，３０と通信制御装置１００とが接続されている。サーバ１０にはデータベース（ＤＢ）４２が接続されている。サーバ２０，３０は、データベース４３を共有している。通信媒体４４には、通信制御装置１００と他の複数のシステム５１，５２とが接続されている。各システム５１，５２には、端末６１，６２が接続されている。通信媒体４５には、通信制御装置１００と複数の端末６３，６４とが接続されている。
【００２０】
サーバ１０，２０，３０のそれぞれには、利用者に各種業務を提供するアプリケーション１１，２１，３１、自己の動作状態を示すデータが格納された状態管理テーブル１２，２２，３２、及び通信制御装置１００へ自己の動作状態を報告する状態管理エージェント１３，２３，３３が設けられている。
【００２１】
通信制御装置１００はＬＡＮ４１と他の通信媒体４４，４５との情報通信を制御する装置であり、内部にネットワーク連携装置１００ａを有している。ネットワーク連携装置１００ａは、振り分けプログラム１１０と記憶装置１２０とを有している。振り分けプログラム１１０は、状態管理エージェントから各サーバ１０，２０，３０の状態を収集し一括管理する状態管理部１１１、利用者からの要求をいずれかのサーバに振り分ける振り分け処理部１１２、及び要求を振り分けるための条件の活性化・非活性化の切り換えを行う運用操作部１１３から構成されている。また、記憶装置１２０内には各サーバの負荷状態を示す負荷分散情報１２１、各サーバに振り分けられた要求の情報を示す状態管理テーブル１２２、及び運用を切り換えるための複数の条件が格納された運用テーブル１２３が格納されている。
【００２２】
以上のような１台の通信制御装置で構成されるロードシェアシステムは、大別して次の諸機能を備えている。
第１の機能は、通信制御装置１００とサーバ１０，２０，３０とが一体となり、１つのサーバのように振る舞う機能である。言い換えると、通信制御装置１００が他のサーバ１０，２０，３０を隠蔽し、利用者からは１つのシステムとみえるようにする機能である。以後、この機能を１システムビューと呼ぶ。
【００２３】
第２の機能は、サーバ側に配置した状態管理エージェント１３，２３，３３の働きにより、各サーバ１０，２０，３０のアプリケーションの動作状況を通信制御装置１００で一括管理する機能である。
【００２４】
第３の機能は、上記第１の機能と第２の機能とを併用した機能である。つまり、通信制御装置１００が一括管理している各サーバの管理情報に基づき、利用者からの要求を適切なサーバへ振り分けることにより、負荷配分の最適化を図る機能である。
【００２５】
第４の機能は、上記第１の機能を用いて要求を振り分ける際に、振り分け先を決定するための条件の活性化・非活性化を切り換えることにより、効率的な負荷の分散を実現する機能である。
【００２６】
第５の機能は、第４の機能を実行する際に、第２の機能で管理している各サーバ１０，２０，３０の負荷状態に応じて、動的に振り分け条件を切り換える機能である。
【００２７】
まず、第１の機能である１システムビューについて説明する。図３は１システムビューの機能を示すブロック図である。なお、この図では、図２における２つの通信媒体４４，４５を包括して通信媒体４６としている。
【００２８】
ここでは、端末６３、６４や、他のシステム５１、５２からＤＢ４２，４３の更新処理の要求を出力する場合を例にとり説明する。端末６３、６４やシステム５１、５２から要求７１，７２を出力する際には、通信制御装置１００の通信アドレス（Ａ）を送信先として指定して出力する。すると、その要求７１，７２は通信媒体４６を介して通信制御装置１００に送られる。通信制御装置１００では、振り分け処理部１１２が要求７１，７２に含まれるロードシェアシステムとしての通信アドレス（Ａ）をサーバ１０，２０，３０のいずれかの通信アドレス（Ｂ），通信アドレス（Ｃ），通信アドレス（Ｄ）に変換する。そして、通信アドレス変換後の要求７３，７４，７５は、通信制御装置１００からＬＡＮ４１を介していずれかのサーバに転送される。サーバ１０，２０，３０内のアプリケーション１１，２１，３１は、要求を受け取るとその要求内容に応じてＤＢ４２，４３を操作する。
【００２９】
このようにして、端末６３、６４や、他のシステム５１、５２からは、通信制御装置１００の通信アドレス（Ａ）を指定して、アプリケーションの機能の提供を受けることができる。つまり、利用者はサーバ１０，２０，３０の存在を意識する必要がない。
【００３０】
図４は利用者が認識しているネットワーク網のイメージを示す図である。利用者は、通信媒体４６には端末６３，６４、システム５１、５２及び共用ＤＢ４２，４３を操作するアプリケーション１０１ａを有するサーバ１００ａが存在しているように認識している。このサーバ１００ａは、実際にはサーバ１０，２０，３０と通信制御装置１００との複合システムである。
【００３１】
一方、通信制御装置１００では、通信アドレス（Ａ）と各サーバ１０，２０，３０のそれぞれの通信アドレス（Ｂ），通信アドレス（Ｃ），通信アドレス（Ｄ）とを相互にリンクさせている。
【００３２】
図５は通信制御装置１００内での通信アドレスのリンク状態を示す図である。通信制御装置１００の通信アドレス（Ａ）８１からサーバ１０の通信アドレス（Ｂ）８２、サーバ２０の通信アドレス（Ｃ）８３、サーバ３０の通信アドレス（Ｄ）８４の順でリンクが張られている。また、通信アドレス（Ｂ）８２から通信アドレス（Ａ）８１へ、通信アドレス（Ｃ）８３から通信アドレス（Ａ）８１へ、通信アドレス（Ｄ）８４から通信アドレス（Ａ）８１へ、それぞれリンクが張られている。
【００３３】
この状態で、振り分け処理部１１２は、利用者の端末６３、６４やシステム５１，５２側からサーバ１０，２０，３０側へ、あるいはサーバ１０，２０，３０側から利用者の端末６３，６４やシステム５１，５２側への通信アドレスの変換を行う。以下に、通信アドレスの変換方式を示す。
【００３４】
図６は通信アドレスの変換方式を示す図である。このネットワーク網では、２つの通信アドレスがペアとなって伝送される。図中の左側は、通信制御装置１００とサーバ１０，２０，３０との間で使用される通信アドレスペア８５〜８７である。通信アドレスペア８５〜８７は、各サーバ１０，２０，３０のそれぞれの通信アドレス（Ｂ），通信アドレス（Ｃ），通信アドレス（Ｄ）と利用者の端末の通信アドレス（ｘ）とのペアである。一方、図中の右側は、通信制御装置１００と端末６１〜６４との間で使用される通信アドレスペア８８である。通信アドレスペア８８は、各通信制御装置１００の通信アドレス（Ａ）と利用者の端末の通信アドレス（ｘ）のペアである。
【００３５】
通信制御装置１００内の振り分け処理部１１２は、通信媒体４６を介して通信アドレスペア８８を受け取ると、通信アドレスペア８８内の自己の通信アドレス（Ａ）をサーバ１０，２０，３０のいずれかの通信アドレスに変更する。そして、変更後の通信アドレスペアをＬＡＮ４１上に出力する。
【００３６】
次に、第２の機能である、サーバ内のアプリケーションの状態を通信制御装置１００で一括管理する機能について説明する。図７は通信制御装置１００での一括管理機能の概略構成を示すブロック図である。この機能を実現するために、通信制御装置１００側の状態管理部１１１と各サーバ１０，２０，３０側の状態管理エージェント１３，２３，３３との間でサーバの状態管理用の通信パス９１，９２，９３を確立している。状態管理部１１１は通信パス９１，９２，９３を使用して、アプリケーション１１，２１，３１の状態要求を状態管理エージェント１３，２３，３３へ送信する。状態管理エージェント１３，２３，３３は状態取得要求を受信すると、アプリケーション１１，２１，３１の動作状況を状態管理部１１１へ送信する。状態管理部１１１は、各状態管理エージェント１３，２３，３３が応答したアプリケーション１１，２１，３１の動作状況を記憶装置１２０で一括管理する。記憶装置１２０内では、各サーバの動作状況は負荷分散情報１２１と状態管理テーブル１２２とに分けて管理される。以後、負荷分散情報１２１と状態管理テーブル１２２とに運用情報を加えたものを管理簿と呼ぶ。
【００３７】
図８は状態管理を行う際の処理手順を示すフローチャートである。これは、状態管理部１１１が実行する処理である。
〔Ｓ１〕状態管理エージェント１３，２３，３３との間で状態管理用の通信パス９１，９２，９３を確立する。
〔Ｓ２〕状態管理エージェント１３，２３，３３に対して状態要求を送信する。
〔Ｓ３〕状態管理エージェント１３，２３，３３からサーバ１０，２０，３０毎のアプリケーション１１，２１，３１の状態を受信する。
〔Ｓ４〕アプリケーション１１，２１，３１の状態が変化した際に状態管理エージェント１３，２３，３３が出力する状態変更情報を受信する。
〔Ｓ５〕サーバ１０，２０，３０のアプリケーション１１，２１，３１の状態を管理簿を用いて管理する。
【００３８】
以下に、管理簿の内容について説明する。図９は管理簿内の一例を示す図である。管理簿では、「業務」、「運用情報」、「状態管理情報」、及び「負荷分散情報」に分けて管理されている。
【００３９】
「業務」は、ロードシェアシステムで実行される処理の単位である。「運用情報」は、「業務」がサービスの提供を行っている場合には「運用中」であり、サービスの提供を停止している場合には「停止中（抑止状態）」である。
【００４０】
「状態管理情報」は、「通信先サーバ情報」、「サーバ上のアプリケーションプログラム」、「ＩＤ」、及び「状態」に別れている。「通信先サーバ情報」は、後に続く情報がどのサーバの情報であるかを示している。「サーバ上のアプリケーションプログラム」は、サーバ内で業務を提供しているアプリケーションプログラムの名称を示している。「ＩＤ」は、サーバ上のアプリケーション単位に割り振られた識別番号である。「状態」は、アプリケーションが使用可能であるか否かを示している。
【００４１】
なお、「ＩＤ」の情報は、状態管理エージェントとの間の状態に関する情報の交換の際に使用される。ネットワーク連携装置１００ａ内でエージェントからの状態を反映する際、「ＩＤ」を用いることにより資源検索の高速化が図れる。
【００４２】
「負荷分散情報」は、「振り分け数の情報」と「比率情報」とに分かれている。「振り分け数の情報」は、アプリケーションへ振り分けた利用者からの要求の数を示している。「比率情報」は、当該業務に対する全要求数の中の、各サーバに現在振り分けられている要求の割合を示している。この数字から、アプリケーションの負荷の分散状況を知ることができる。
【００４３】
図１０は状態管理処理の概念図である。この図では、サーバ１０はアプリケーション１１，１４を有しており、サーバ２０はアプリケーション２１，２４を有している。なお、アプリケーション１１とアプリケーション２１とは同じ業務を提供するアプリケーションである。また、状態管理簿１２３の内容は、図９に示したものである。ここで、アプリケーション１１，１４，２１は動作しているが、アプリケーション２４は停止しているものとする。
【００４４】
このような条件で、通信制御装置１００内の状態管理部１１１は、まずサーバ１０とサーバ２０とに対する問い合わせ情報１０１、１０３を組み立て、それを状態要求として出力する。サーバ１０，２０内のそれぞれの状態管理エージェント１３，２３は状態要求に応答し、自己のサーバ内のアプリケーションの状態を示す応答情報１０２、１０４を出力する。状態管理部１１１は応答情報１０２、１０４を受けとり、その内容を管理簿１２３に反映する。
【００４５】
図１１は通信制御装置の状態要求の際のフローチャートである。これは、通信制御装置１００内の状態管理部１１１が実行する処理である。
〔Ｓ１１〕管理状態を通信するための通信パスを各状態管理エージェントとの間で確立する。
〔Ｓ１２〕管理簿より状態管理情報の読み込みを行う。
〔Ｓ１３〕サーバ単位に状態問い合わせ情報を組み立てる。この時に、資源単位に「ＩＤ」が設定される。
〔Ｓ１４〕サーバ内状態管理エージェントへの状態要求を送信する。
【００４６】
図１２は状態通知を受け取った通信制御装置の処理手順を示すフローチャートである。これは、通信制御装置１００内の状態管理部１１１が実行する処理である。
〔Ｓ２１〕状態管理エージェントからの状態通知を受信する
〔Ｓ２２〕受信した状態通知内のＩＤから、資源を特定する。
〔Ｓ２３〕特定した資源が使用可能であるのか、使用不可能であるのかを判別する。使用可能であればステップＳ２４に進み、使用不可能であればステップＳ２５に進む。
〔Ｓ２４〕特定した資源が使用可能である旨を管理簿に反映する。
〔Ｓ２５〕特定した資源が使用不可能である旨を管理簿に反映する。
【００４７】
以上の図１１、図１２が通信制御装置で実行される処理手順である。次に、各サーバ内における状態管理エージェントで実行される処理手順を説明する。
図１３は通信制御装置からの要求により状態通知を出力する際の状態管理エージェントの処理手順を示すフローチャートである。
〔Ｓ３１〕通信制御装置との間の状態管理パスを確立する。
〔Ｓ３２〕ネットワーク連携装置内の状態管理部から振り分け資源の状態要求を受信する。
〔Ｓ３３〕振り分け資源の状態確認及び状態遷移通知出口を状態管理エージェント内に登録する。これで、振り分け資源名とその状態を示す管理テーブルが作成される。ここで、状態遷移通知出口とは、サーバ内でアプリケーションを管理しているプログラムから状態管理エージェントへ資源の状態を通知するための情報伝達の受信口である。この受信口（状態遷移通知出口）を状態管理エージェントに登録しておくことにより、アプリケーションの状態を状態管理エージェントが取得可能となる。
〔Ｓ３４〕状態要求で指定された資源が使用可能状態か、使用不可能状態かを判別する。使用可能状態であればステップＳ３５に進み、使用不可能状態であればステップＳ３６に進む。
〔Ｓ３５〕状態要求で指定された資源が使用可能である旨を状態管理部に通知する。
〔Ｓ３６〕状態要求で指定された資源が使用不可能である旨を状態管理部に通知する。
【００４８】
図１４は資源の状態の変化により状態通知を出力する際の状態管理エージェントの処理手順を示すフローチャートである。
〔Ｓ４１〕振り分け資源（ロードシェアシステムで機能を分散させるべき資源）の状態の変化を検出する。
〔Ｓ４２〕状態遷移が発生し、状態遷移出口を起動する。
〔Ｓ４３〕状態遷移の状況を状態管理部に通知する。
〔Ｓ４４〕他の資源に状態の変化があるか否かを判断し、状態が変化した資源があればステップＳ４１に進み、状態が変化した資源がなければステップＳ４５に進む。
〔Ｓ４５〕状態管理パスを解放し、状態遷移通知出口を削除する。
【００４９】
以上のようにして、サーバ内のアプリケーションの状態を通信制御装置１００で一括管理することができる。この方式では、管理簿内のＩＤにより管理対象を特定し、サーバシステムに適した状態管理エージェントを配置することにより、サーバシステムの種別に依存せずに通信制御装置１００でアプリケーションを一括管理することができる。例えば、サーバシステムが大型のホスト計算機であっても、ＵＮＩＸのシステムであってもよい。
【００５０】
また、管理簿内のＩＤにより管理対象を特定し、サーバシステムに適した状態管理エージェントを配置することにより、アプリケーションの通信プロトコルに依存せずに管理することができる。
【００５１】
次に、第３の機能である、上記第１の機能と第２の機能とを併用した機能について説明する。この機能では、通信制御装置１００が一括管理している各サーバの管理情報に基づき、利用者からの要求を適当なサーバへ振り分けることにより、負荷配分の最適化を図る。
【００５２】
図１５は一括管理された管理情報に基づき利用者からの要求を振り分ける処理の概念図である。図において、状態管理エージェント１３，２３，３３と状態管理部１１１との間には通信パス９４〜９６が確立されている。これにより、各サーバ１０，２０，３０内のアプリケーション１１，２１，３１の動作状態は、状態管理部１１１で一括管理される。それらの状態管理情報は記憶装置１２０内に管理簿として格納されている。
【００５３】
そして、利用者の端末６１，６３，６４からＤＢ４２，４３に対する要求７６，７６ａが出力されると、その要求は通信媒体４６を介して振り分け処理部１１２に入力される。振り分け処理部１１２は、状態管理部１１１から各アプリケーション１１，２１，３１の現在の状態の情報を取得し、その情報から各サーバへの負荷が分散するように、要求を実行させるアプリケーションを特定する。そして、特定したアプリケーションに対して要求７７〜７９を出力する。要求を受け取ったアプリケーションは、要求内容に従ってＤＢ４２，４３を処理する。
【００５４】
ここで、振り分け処理部１１２では、利用者からの要求の一部を振り分けキーとし、振り分けキーに対応付けた振り分け先候補とその所在を管理しておく。図１６は振り分け処理のフローチャートである。なお、ステップＳ５１〜ステップＳ５９までの処理は、振り分け処理部が実行する。ステップＳ６０の処理はトランザクション処理であればアプリケーションが実行し、コネクション処理であればアプリケーションと利用者の端末とにより実行される。
〔Ｓ５１〕ネットワーク利用者からのコネクション確立要求、またはトランザクション開始要求を受信する。
【００５５】
以下のステップは、サーバ側のコネクション確立処理、またはトランザクションの開始処理である。
〔Ｓ５２〕振り分けキー情報を取得する。
〔Ｓ５３〕振り分け先サーバ候補の抽出をする。
〔Ｓ５４〕振り分け先サーバ候補があるか否かを判断し、振り分け先サーバ候補があればステップＳ５６へ進み、振り分け先サーバ候補がなければステップＳ５５へ進む。
〔Ｓ５５〕振り分け先サーバ候補がない場合には、利用者からの要求がコネクション振り分けなら確立失敗とし、利用者からの要求がトランザクションの振り分けなら一定時間保留とし、時間経過後再度ステップＳ５４へ進む。
〔Ｓ５６〕振り分け先サーバ候補があれば、振り分け先サーバを決定する。
〔Ｓ５７〕サーバ側コネクションの確立、またはトランザクションの振り分け処理を行う。
〔Ｓ５８〕コネクション確立が成功したか否かを判断し、成功であればステップ６０へ進み、失敗であればステップＳ５９へ進む。なお、要求がトランザクション処理であればこのステップは実行せず、ステップＳ６０に進む。
〔Ｓ５９〕コネクション確立が失敗の場合には、振り分け候補から失敗したサーバを除外し、ステップＳ５４に進む。
〔Ｓ６０〕コネクション確立が成功の場合には、データ通信またはトランザクション処理を実行する。
【００５６】
次に、振り分けキーの取得処理について詳しく説明する。図１７は振り分けキーの取得処理を示す図である。振り分け処理部１１２は状態管理部１１１を有している。状態管理部１１１では、振り分けキーごとに振り分け先候補とこの所在を管理している。
【００５７】
利用者からの要求７５は、まず振り分け処理部１１２に入力される。振り分け処理部１１２では、要求の中から振り分けキー７５ａを抽出する。振り分けキー７５ａは、状態管理部１１１に送られる。状態管理部１１１は、振り分けキー７５ａに対応する振り分け先候補とその所在に関する情報１１２ｂを抽出し、振り分け処理部１１２へ渡す。振り分け処理部１１２は、情報１１２ｂに基づき要求７５の振り分け先を決定する。
【００５８】
なお、上記の例では要求の一部の文字列を振り分けキーとしているが、その文字列を端末名と組み合わせたり、ネットワーク利用者のデータや業務の名前など、様々なものを振り分けキーとすることができる。
【００５９】
以上のように、振り分けキーは利用者からのコネクションの確立要求やトランザクション開始時に受け付けた要求から抽出される。抽出する情報は通信プロトコルや振り分けの種類に応じて以下のように設定している。
【００６０】
コネクション振り分けにおいて、通信プロトコルがＦＮＡ（富士通ネットワークアーキテクチャ）の場合、宛て先（業務名）、通信元ネットワーク利用者名である。具体的には、業務の論理的な名前＋端末名（端末グループ）、業務の論理的な名前＋端末名＋端末の属するシステムのアドレス、業務の論理的な名前＋端末名＋端末の属するシステムのアドレス＋ユーザデータ内の任意のデータ等である。
【００６１】
コネクション振り分けにおいて、通信プロトコルがＯＳＩ（Open System Interconnection ）の場合には、宛て先のアドレスと通信元のアドレスである。具体的には、業務のＴ−ＳＡＰアドレスと通信元のＮＳＡＰアドレス（ＯＳＩにおけるネットワーク層のアドレス）である。
【００６２】
ＴＣＰコネクション振り分けにおいて、通信プロトコルがＴＣＰ／ＩＰの場合には、クライアントが確立した通信制御装置上のポート番号、送信元ネットワーク利用者名である。
【００６３】
トランザクションの振り分けの場合には、トランザクション処理における業務名、トランザクション開始時のメッセージの内容である。
なお、振り分けキーとして選択するデータを、アクセス種別（排他、共用、照会、更新等）と対応付けることで、システム全体のトランザクション性能やＤＢアクセスでの負荷の分散を図ることができる。
【００６４】
ところで、キーとなる情報がサーバとの間でのコネクションの確立要求に含まれていない場合、つまりトランスポート層よりも上位レベルの情報をキーとする場合には、利用者の端末側からトランスポート層の確立要求が送られただけでは、振り分け先を特定することができない。従って、従来のように端末とサーバのトランスポート層での接続を完了してから上位レベルの通信を行うという手順を踏むことができない。そこで本発明では、この問題を以下の方法で解決する。
【００６５】
図１８は上位レベルの情報をキーとする場合のコネクション手順を示す図である。図において、まずネットワーク利用者の端末からトランスポート層の確立要求が出力される。通信制御装置は端末との間のトランスポートコネクションのみを確立し、サーバとのコネクションは保留にする。次いで、端末から上位レベルの確立要求が出力される。通信制御装置は、その要求からキーを抽出し、振り分けるべきサーバを特定する。サーバを特定したら、そのサーバとの間でトランスポート層のコネクションと上位レベルのコネクションとを順次確立する。最後に、端末との間の上位レベルのコネクションを確立する。以後は、端末とサーバ間でデータ転送が行われる。
【００６６】
このように、サーバとの間のトランスポート層のコネクションの確立を一時的に保留することにより、上位レベルのデータに含まれる詳細な情報を基に振り分け先を選択することができ、より信頼性の高い負荷分散を行うことができる。
【００６７】
次に、振り分け先サーバ候補の抽出処理の詳細を説明する。図１９は振り分け先サーバ候補の抽出される情報のリンク状態を示す図である。まず、振り分け候補グループ５１０から振り分け候補（１）５２１に繋がっている。さらに、振り分け候補（１）５２１から振り分け候補（２）５２２へ繋がっている。以後、同様に最後の振り分け候補（ｎ）５２３までが順に繋がっている。各振り分け候補５２１〜５２３には、業務情報５３１〜５３３、パス情報５４１〜５４３、サーバ情報５５１〜５５３が順に繋がっている。
【００６８】
振り分けサーバを決定する際には、図１９の振り分け候補の情報から、以下の全ての条件を満たすものを候補として選択する。
第１に、振り分け情報が抑止状態（停止状態）でないこと。第２に、カレントセション数が最大振り分け数を超えていないこと。第３に、パス情報が抑止状態（停止状態）でないこと。第４に、業務状態が抑止状態（停止状態）でないこと。第５に、業務内のアプリケーションの状態が非活性状態でないこと。
【００６９】
図１９では、各種振り分け情報ごとに状態情報を有している。例えば、抑止状態、アプリケーションの動作状態等である。このような状態情報を業務等の情報にまで持たせたのは、情報ごとに対応する資源への振り分けを抑止できるようにするためである。例えば、特定の業務のみ振り分けを一時的に抑止可能としたり、サーバ単位に振り分けを抑止可能とする。
【００７０】
次に、選択された振り分け候補の中からの、振り分け先サーバの決定方法を説明する。振り分け候補の中から、以下に論理式に従って求めた分散比率の最も少ないものを振り分け先と決定する。
【００７１】
【数１】
｛（ＴＣn ＋１）／Ｒn ｝×１００ ・・・・・（１）
ここで、ＴＣn はｎ番目の振り分け候補のサーバでの振り分け済セション数であり、Ｒn はｎ番目の振り分け候補のサーバ分散比率である。
【００７２】
なお、式（１）の値が同じ振り分け候補のサーバが複数存在した場合には、次のように取り扱う。コネクションの振り分けの場合には、最後に振り分けを行ったサーバの次のサーバに決定する。トランザクション振り分けの場合には、過去の振り分け実績（振り分けたトランザクション数）が一番少ないサーバに決定する。これは、一時点で振り分けるセションやトランザクションが候補となるサーバ数よりも少なく、かつ、セションは何度も確立解放を繰り返すような運用を行ったときに、すべてのサーバへの振り分けを可能とするためである。
特別な振り分けとして、同一のクライアントとサーバ（またはサーバ内のアプリケーション）との間で複数のセションが確立する運用では、上記のような論理によらず、１つ目のセションと同じサーバへの振り分けを行うこともできる。なお、両者の選択は通信プロトコルの違いにより実現するか、あるいは、予め定義しておく。これによれば、同じクライアントとサーバとの間で、複数の業務を同時に連携して行う場合に有効となる。
【００７３】
また、トランザクションの振り分けにおいて、振り分け候補が１つもない場合には、振り分けを保留することができる。具体的には、振り分け候補が１つもないか、または、最大振り分け数を超えたものがある場合には、トランザクション開始要求を一定の保留時間だけ保留する。なお、保留するトランザクション開始要求は、保留可能な要求数の範囲内でなければならない。また、保留時間については、トランザクション要求毎に保留時間の変更が可能である。
【００７４】
これにより、瞬間的にトランザクション要求が大量に発生した場合のサーバへの過負荷が防止できるとともに、ホットスタンバイ時のシステム切り換え時にトランザクション要求を失敗させずにすむ。
【００７５】
次に第４の機能である業務の運用を切り換えることにより、サーバ間の効率的な負荷の分散を行う機能について説明する。この機能を実行するには、図２に示す振り分け処理部１１２に対して各種条件の定義を入力する。この定義では、各サーバのアプリケーションへの振り分け条件をグループ化する。このグループ化により、複数の振り分け条件をまとめて管理することができる。
【００７６】
さらに、振り分け条件グループの定義に「振り分け状態」を持たせる。そして、振り分け処理部１１２は、振り分け先の決定に使用する振り分け条件グループを「活性状態」に、振り分け先の決定に使用しない振り分け条件グループを「非活性状態」にすることにより業務の振り分けを管理する。このとき、各振り分け条件グループは業務の運用に対応している。
【００７７】
図２０は振り分け処理部１１２に入力する振り分け定義の例を示す図である。この例では、実資源の定義として、サーバ１０，２０，３０をそれぞれ「サーバＸ」、「サーバＹ」、「サーバＺ」と名付けており、各サーバ１０，２０，３０内で業務を実行するアプリケーション１１，２１，３１を、それぞれ「業務プログラムＡ（業務Ａ）」、「業務プログラムＢ（業務Ｂ）」、「業務プログラムＢ（業務Ｂ）」と名付けている。ここで、サーバ２０とサーバ３０とは同じ業務を提供しており、ロードシェア形態をとっている。
【００７８】
振り分けの定義において、「業務Ａ」は、「振り分け条件グループＡ１（振り分け状態＝活性）」と「振り分け条件グループＡ２（振り分け状態＝非活性）」とに分かれている。「振り分け条件グループＡ１」の振り分け条件は「振り分け条件Ａ１Ｘ（最大１００）」であり、「振り分け条件グループＡ２」の振り分け条件は「振り分け条件Ａ２Ｘ（最大５０）」である。「業務Ｂ」は、「振り分け条件グループＢ１（振り分け状態＝活性）」と「振り分け条件グループＢ２（振り分け状態＝非活性）」とに分かれている。「振り分け条件グループＢ１」の振り分け条件は「振り分け条件Ｂ１Ｙ（最大１００）」、「振り分け条件Ｂ１Ｚ（最大１００）」である。一方、「振り分け条件グループＢ２」の振り分け条件は「振り分け条件Ｂ２Ｙ（最大５０）」、「振り分け条件Ｂ２Ｚ（最大５０）」である。
【００７９】
ここで、振り分け条件の最後のアルファベットが業務を実行するサーバを示しており、「最大」とはそのサーバへの振り分けが許される要求の最大数を示している。
【００８０】
振り分け処理部１１２は、振り分け状態が活性である振り分け条件グループの定義を使用して振り分け先のサーバを決定する。運用の切り換えは、活性状態の振り分け条件グループを非活性状態とし、新しい運用に使用すべき振り分け条件グループを活性状態とすることにより行う。
【００８１】
図２１は図２０に示した振り分け定義による運用の切り換え状況を示す図である。なお、運用の切り換え状況を説明する図（図２１、図２４、図２６、図２８、図３０、図３４）では、各サーバ１０，２０，３０とアプリケーション１１，２１，３１とには、その時の定義で与えられている名称を表記している。従って、与えられている定義によって、図中のサーバ等の表記も異なる。
【００８２】
「振り分け条件グループＡ１」と「振り分け条件グループＢ１」が活性状態の場合（図中、上側）では、利用者の端末６３，６４等からの業務Ａの要求１４０は全てサーバ１０に対する要求１４１となり、処理できる最大の要求数は「１００」である。業務Ｂの要求１５０は、サーバ２０とサーバ３０とに対する要求１５１，１５２となり、サーバ２０，３０の処理できる最大の要求数はそれぞれ「１００」ずつである。
【００８３】
ここで運用を「振り分け条件グループＡ２」と「振り分け条件グループＢ２」とを活性状態にすると（図中、下側）では、業務Ａの要求１４０ａは全てサーバ１０に対する要求１４１ａとなり、処理できる最大の要求数は「５０」である。業務Ｂの要求１５０ａは、サーバ２０とサーバ３０とに対する要求１５１ａ，１５２ａとなり、サーバ２０，３０の処理できる最大の要求数はそれぞれ「５０」ずつである。
【００８４】
ところで、上記の説明では各振り分け条件グループの状態（活性／非活性）を個々に切り換えることにより運用を切り換えているが、各分け条件グループを予め運用と対応づけておくことにより、運用の切り換え制御を簡略化することができる。
【００８５】
図２２は振り分け条件グループと運用とを対応づけた場合の定義の例を示す図である。この例の定義は、図２０に示したものと殆ど同じであるため、相違点のみを説明する。図２０では各振り分け条件グループには振り分け状態が設定されていたが、図２２の各振り分け条件グループには運用名が設定されている。この例では、「振り分け条件グループＡ１」は「運用α」、「振り分け条件グループＡ２」は「運用β」、「振り分け条件グループＢ１」は「運用α」、「振り分け条件グループＢ２」は「運用β」である。そして、図２２で追加された項目として運用の振り分け状態の設定がある。図では、「運用α」の振り分け状態が「活性」、「運用β」の振り分け状態が「非活性」である。
【００８６】
そして、振り分け制御部１１２は、運用の振り分け状態を変更することにより運用の切り換えを行うことができる。従って、個々の振り分けグループを管理する必要がなく、切り換えの制御が簡略化される。
【００８７】
さらに、振り分け条件グループの定義にユーザの指定を追加し、ネットワークの利用者を指定することもできる。その場合、振り分け条件グループのユーザの指定には、ネットワーク利用者の端末名、ワイルドカード（＊）、及び任意の端末群をグループ化したユーザグループに定義付けられた名前等を指定することができる。なお、ワイルドカードは、全ての利用者を振り分け可能であることを意味する。また、要求の一部をキーとして指定することにより、そのキーを有する要求を対象とすることもできる。
【００８８】
図２３はユーザの指定を追加した振り分け定義を示す図である。この例では簡単のために２つのサーバ１０，２０で説明する。
実資源の定義として、サーバ１０，２０をそれぞれ「サーバＸ」、「サーバＹ」とし、各サーバ１０，２０内で業務を実行するアプリケーション１１，２１を、それぞれ「業務Ａ」、「業務Ｂ」と定義している。
【００８９】
振り分けの定義において、「業務Ａ」は、「振り分け条件グループＡ１１（運用＝運用α、ユーザ＝端末群１）」、「振り分け条件グループＡ１２（運用＝運用α、ユーザ＝端末群２）」、及び「振り分け条件グループＡ２（運用＝運用β、ユーザ＝＊）」に分かれている。「振り分け条件グループＡ１１」の振り分け条件は「振り分け条件Ａ１１Ｘ（最大５０）」であり、「振り分け条件グループＡ１２」の振り分け条件は「振り分け条件Ａ１２Ｘ（最大５０）」であり、「振り分け条件グループＡ２」の振り分け条件は「振り分け条件Ａ２Ｘ（最大５０）」である。
【００９０】
「業務Ｂ」は、「振り分け条件グループＢ１１（運用＝運用α、ユーザ＝端末群１）」、「振り分け条件グループＢ１２（運用＝運用α、ユーザ＝端末群２）」、「振り分け条件グループＢ２１（運用＝運用β、ユーザ＝端末群１）」、「振り分け条件グループＢ２２（運用＝運用β、ユーザ＝端末群２）」とに分かれている。「振り分け条件グループＢ１１」の振り分け条件は「振り分け条件Ｂ１１Ｙ（最大５０）」、「振り分け条件グループＢ１２」の振り分け条件は「振り分け条件Ｂ１２Ｙ（最大５０）」、「振り分け条件グループＢ２１」の振り分け条件は「振り分け条件Ｂ２１Ｙ（最大２５）」、「振り分け条件グループＢ２２」の振り分け条件は「振り分け条件Ｂ２２Ｙ（最大２５）」である。
【００９１】
図では、運用αの振り分け状態が活性であり、運用βの振り分け状態が非活性である。
このような定義が設定された状態で、振り分け処理部１１２は、利用者からの要求に付加されるユーザ情報や要求内容と活性状態の振り分け条件とを対比することにより、振り分け先を決定する。そして、運用の振り分け状態を変更することにより、運用を切り換えることができる。
【００９２】
図２４はユーザの指定を追加した振り分け定義による運用の切り換え状況を示す図である。ここで、端末６３，６４は第１の端末群１８１に含まれ、端末６５，６６は第２の端末群１８２に含まれている。
【００９３】
［運用α］の状態では、第１の端末群１８１から業務Ａへの要求１６０は全てサーバ１０への要求１６２となり、最大の要求数は「５０」である。第１の端末群１８１から業務Ｂへの要求１７０は全てサーバ２０への要求１７２となり、最大の要求数は「５０」である。第２の端末群１８２から業務Ａへの要求１６１は全てサーバ１０への要求１６３となり、最大の要求数は「５０」である。第２の端末群１８２から業務Ｂへの要求１７１は全てサーバ２０への要求１７３となり、最大の要求数は「５０」である。
【００９４】
ここで、運用が切り換えられ［運用β］になると、第１の端末群１８１から業務Ａへの要求１６０ａと第２の端末群１８２から業務Ａへの要求１６１ａとは、全てサーバ１０への要求１６４となる。そして、要求１６４の最大の要求数は、双方の端末群からの総要求数で換算して「５０」である。一方、第１の端末群１８１から業務Ｂへの要求１７０ａは全てサーバ２０への要求１７２ａとなり、最大の要求数は「２５」である。第２の端末群１８２から業務Ｂへの要求１７１ａは全てサーバ２０への要求１７３ａとなり、最大の要求数は「２５」である。
【００９５】
この図に示すようにユーザを指定した運用の切り換えを行うことにより、利用者の利用頻度の地域格差を考慮した運用の切り換えが可能となる。
次に、第５の機能である、第１の機能で管理している各サーバの負荷状態に応じて、動的に振り分け条件を切り換える機能について説明する。運用操作部１１３は、状態管理部１１１が管理している各サーバの負荷状態等に応じて運用の切り換えを行うこともできる。この場合、アプリケーションの定義に「振り分け状態」の設定項目を設ける。この「振り分け状態」は、対応するアプリケーションの振り分けが可能な場合には「活性」とし、振り分けが不可能な場合には「非活性」とする。
【００９６】
図２５はアプリケーションの状態の定義を追加した振り分け定義を示す図である。この図では、実資源の定義として、サーバ１０，２０，３０をそれぞれ「サーバＸ」、「サーバＹ」、「サーバＺ」とし、各サーバ１０，２０，３０内で業務を実行するアプリケーション１１，２１，３１を、それぞれ「業務プログラムＡ（業務Ａ）」、「業務プログラムＢ（業務Ｂ）」、「業務プログラムＢ（業務Ｂ）」と定義している。さらに、各アプリケーション１１，２１，３１には振り分け状態が設定されており、図中では全て「活性」である。なお、振り分けの定義は、図２２に示した例と同じである。
【００９７】
ロードシェア形態の業務で特定のサーバのアプリケーションにトラブルが発生した場合、トラブルが発生したサーバ内に配置された状態管理エージェントから状態管理部１１１へアプリケーションに障害が発生した旨が通知される。状態管理部１１１は、障害の発生したアプリケーションの状態を「非活性」とする。
【００９８】
図２６はロードシェア形態でのトラブル対処の例を示す図である。図中のトラブル発生前の状態（図中、上側）は、図２１の［運用α］の状態と同じである。ただし、この図では、各サーバ１０，２０，３０内に状態管理エージェント１３，２３，３３を図示している。ここで、例えば、サーバ２０に障害が発生した場合には、サーバ２０内の状態管理エージェント２３が、通信制御装置１００内の状態管理部１１１にアプリケーション２１が使用できないことを通知する。状態管理部１１１は、アプリケーション２１の状態を「非活性」とする。これにより、利用者から業務Ｂへの要求がアプリケーション２１へ振り分けられることはなくなる。
【００９９】
トラブル発生後の状態（図中、下側）では、利用者から業務Ｂへの要求１５０は、全てサーバ３０に対する要求１５２ａとなる。ここで、サーバ２０のアプリケーション２１が復旧した場合には、サーバ２０内の状態管理エージェント２３がアプリケーション２１が復旧した旨を状態管理部１１１に通知する。状態管理部１１１は、その通知を受けてアプリケーション２１の振り分け状態を活性とする。これにより、アプリケーション２１に対する要求の振り分けが再開される。
【０１００】
このように、定義内に各アプリケーションの振り分け状態を設定しておき、振り分け処理部１１２は「活性」状態のアプリケーションの中から振り分け先を選択することにより、アプリケーションのメンテナンス時にも利用者に対する業務の提供を停止させずにすむ。
【０１０１】
次に、システム運用におけるサーバ障害発生時の運用について説明する。この場合、サーバの定義に「振り分け状態」を持たせ、振り分け可能な場合に「活性状態」、振り分け不可能な場合に「非活性状態」として管理する。
【０１０２】
図２７はホットスタンバイ切り換えを実現するための振り分け定義を示す図である。この例では、１つのデータベースを共有しているサーバ２０，３０のうち、サーバ２０を現用、サーバ３０を待機として運用している。実資源の定義として、サーバ２０，３０をそれぞれ「サーバＸ」、「サーバＹ」とし、各サーバ２０，３０内で業務を実行するアプリケーション２１，３１をともに「業務Ａ」と定義している。
【０１０３】
振り分けの定義において、「業務Ａ」は、「振り分け条件グループＡ１（運用名＝運用α）」と「振り分け条件グループＡ２（運用名＝運用β）」とに分かれている。「振り分け条件グループＡ１」の振り分け条件は「振り分け条件Ａ１Ｘ（最大１００）」と「振り分け条件Ａ１Ｙ（最大１００）」とであり、「振り分け条件グループＡ２」の振り分け条件は「振り分け条件Ａ２Ｘ（最大５０）」と「振り分け条件Ａ２Ｙ（最大５０）」とである。
【０１０４】
現在、「運用α」が活性状態であり、「運用β」が非活性状態である。
図２８はホットスタンバイ切り換えの状況を示す図である。２つのサーバ２０，３０が共に正常に動作している状態（図中、上側）では、端末６３，６４やシステム５１からの業務Ａの要求１４２は、現用であるサーバ２０への要求１４３として振り分けられている。この時、双方のサーバ２０，３０内の状態管理エージェント２３，３３は、定期的に通信を行う事により、互いに監視し合っている。従って、一方のサーバがダウンすると、他方のサーバ内の状態管理エージェントがそのことを検出する仕組みになっている。
【０１０５】
この状態において、現用のサーバ２０にトラブルが発生すると、サーバ２０からの通信が滞ったことをサーバ３０内の状態管理エージェント３３が検出し、サーバ２０がダウンしたことを認識する。すると、状態管理エージェント３３は通信制御装置１００の振り分けプログラム１１０（その中の状態管理部１１１）との間の通信パスを利用して、サーバ２０がダウンした旨を通信制御装置に通知する。通信制御装置１００の状態管理部１１１がその通知を受け取ると、それに応じて、運用操作部１１３がサーバ２０の振り分け状態を非活性状態に変更する。続いて、サーバ３０の振り分け状態を活性状態に変更する。これにより、待機サーバであったサーバ３０が新たに現用サーバとなる。従って、振り分け状態変更後（図中、下側）では、利用者の端末６３，６４等から出力された要求が、全てサーバ３０への要求１４４となる。
【０１０６】
この方式を使用して、各サーバの振り分け状態を順次操作することで、業務を停止せずにホットスタンバイ運用のメンテナンスを行うことができる。
次に、業務の振り分け先の決定を、様々な要素を考慮して行うこともできる。その決定のファクターとしては、例えば、サーバ間の相対振り分け比率、アプリケーションに対する最大振り分け数を指定する。
【０１０７】
サーバ間の相対振り分け比率とは、ロードシェア形態の各サーバ上のアプリケーション間の相対的な振り分け比率である。アプリケーションに対する最大振り分け数とは、アプリケーションがそのサーバで同時に処理可能な要求数である。
【０１０８】
ところで、振り分け処理部１１２は、利用者からの要求が全アプリケーションの最大振り分け数の合計を超えた場合に、いずれかのサーバのアプリケーションが振り分け可能になるまで、待ち合わせ（保留）を行う機能を有している。この際、要求を無制限に待ち合わせると、通信制御装置が資源枯渇したり、ネットワーク利用者の端末がハングする事態が生じる。
【０１０９】
そこで、振り分け条件グループに、業務の最大処理数を超えた場合の処理を決定するためのファクターとして「要求の最大保留数」と「要求の最大保留時間」を指定する。この指定により、待ち合わせの上限が設定される。従って、待ち合わせが「要求の最大保留数」と「要求の最大保留時間」とのいずれかを超えた場合には、振り分け処理部１１２から利用者に対して処理不能の旨の応答を返し、利用者からの要求を失敗させる。
【０１１０】
上記の２つの指定（「要求の最大保留数」，「要求の最大保留時間」）は、利用者からの要求を受信した際に振り分け先を決定するために使用する情報であり、運用中に変更操作を行っても利用者に悪影響を及ぼさない。振り分け処理部１１２は、これらの２つの指定を動的に変更することにより、振り分け配分を最適に保つことができる。
【０１１１】
図２９は振り分け配分の動的な変更を行うための定義の例を示す図である。この例では、実資源の定義として、サーバ２０，３０をそれぞれ「サーバＸ」、「サーバＹ」とし、各サーバ２０，３０内で業務を実行するアプリケーション２１，３１を、共に「業務Ａ」と定義している。この２つのサーバ２０，３０はロードシェア形態をとっている。
【０１１２】
振り分けの定義において、業務Ａには振り分け条件グループＡ１（最大保留数＝５，最大保留時間６０）が定義されている。振り分け条件グループＡ１には、２つの振り分け条件として、振り分け条件Ａ１Ｘ（振り分け比率＝３，最大振り分け数＝１００）と振り分け条件Ａ１Ｙ（振り分け比率＝３，最大振り分け数＝１００）が設定されている。
【０１１３】
さらに、変更内容が設定されており、その内容は、振り分け条件Ａ１Ｙに対して、振り分け比率を「３」→「１」、最大振り分け数を「１００」→「５０」とするものである。
【０１１４】
図３０は振り分け配分の動的な変更状況を示す図である。通常動作時（図中、上側）は、利用者からの要求が、アプリケーション２１への要求１９０とアプリケーション３１への要求１９１とに均等に割り振られている。ここで、サーバ３０に臨時業務３５が発生すると（図中、下側）、アプリケーション３１への振り分け比率が「１」になる。従って、アプリケーション２１への要求１９０ａはアプリケーション３１への要求１９１ａの３倍となる。
【０１１５】
以上の説明が、図２に示したマルチサーバシステムで行うことができる各種処理機能である。ここで、通信制御装置１００内の振り分けプログラム１１０とサーバ内の状態管理エージェントの内部構成について説明する。
【０１１６】
図３１は振り分けプログラムと状態管理エージェントの内部構成を示すブロック図である。サーバ３０の状態管理エージェント３３は、他サーバ監視部３３ａ、アプリケーション監視部３３ｂ、コマンド機能部３３ｃ、及び通信制御機能部３３ｄを有している。他サーバ監視部３３ａは、サーバ１０，２０内の他サーバ監視部と通信を行っており、互いに正常に動作していることを確認し合っている。アプリケーション監視部３３ｂは、サーバ３０内の複数のアプリケーション３１，３１ａの動作状況を監視している。コマンド制御部３３ｃは、操作端末３０ａからのコマンド入力に応じて、各種命令を出力する。通信制御機能部３３ｄは、ＬＡＮ４１を介した通信を制御する。
【０１１７】
振り分けプログラム１１０は、図２に示した状態管理部１１１、振り分け処理部１１２、運用操作部１１３に加え、通信制御部１１４とコマンド機能部１１５とを有している。通信制御部１１４は、ＬＡＮ４１を介した通信を制御する。コマンド機能部１１５は、操作端末１０５からのコマンド入力に応じて、サーバに対する状態要求等を出力する。また、操作端末１０５からの入力により、運用切り換え命令を運用操作部１１３に出力する。運用操作部１１３は運用切り換え命令に従って、運用の切り換えを行う。
【０１１８】
以上の説明が、１台の通信制御装置によりロードシェアシステムを構成した場合である。以下に、２台の通信制御装置によりロードシェアシステムを構成した場合を説明する。まず、２台の通信制御装置で１システムビューを実現する場合を以下に示す。
【０１１９】
図３２は２台の通信制御装置を有するマルチサーバシステムを示す図である。このシステムには、ロードシェア運用を行っている３台のサーバ２１０，２２０，２３０と２台の通信制御装置２４０，２５０がＬＡＮ２０２を介して接続されている。通信制御装置２４０，２５０は、通信媒体２０３を介して他のシステム２６０，２７０と接続されている。
【０１２０】
サーバ２１０，２２０，２３０は、同じ業務を行うアプリケーション２１１，２２１，２３１を有しており、このアプリケーション２１１，２２１，２３１によって１つのデータベース（ＤＢ）２０１を共有している。また、各サーバ２１０，２２０，２３０は、それぞれ異なるアドレスを有している。通信制御装置２４０，２５０は、それぞれ振り分けプログラム２４１，２５１を有している。また、通信制御装置２４０，２５０は同じ通信アドレスを有している。サーバからサービスを受けるシステム２６０，２７０は、それぞれアプリケーション２６１，２７１を有している。
【０１２１】
このような構成により、システム２６０内で動作するアプリケーション２６１が、サーバ２１０，２２０，２３０内のアプリケーション２１１，２２１，２３１と振り分け機能を利用して通信する。
【０１２２】
このような運用では、アプリケーション２６１と通信制御装置との間に確立するコネクションは、通信アドレスＮと通信アドレス（４）との通信アドレスペアのコネクション上に、複数の上位レベルのコネクションを確立することができる。そのため、個々のコネクションを識別するための識別子が必要となる。
【０１２３】
ここで、２台の通信制御装置２４０，２５０がそれぞれ上位レベルのコネクションに「１０」を割り振ったとする。すると、ネットワークの利用者である通信相手のシステム２６０では、コネクションの確認ができなくなる。
【０１２４】
この問題を回避するために、通信制御装置２４０，２５０のそれぞれが管理する上位の通信資源の範囲を、定義等によって重複しないようにする。通信資源を分割する方法としては、以下の３パターンが考えられる。
【０１２５】
第１の方法は定義を用いる方法である。これは、通信制御装置２４０，２５０での管理範囲をそれぞれの通信制御単位に事前に定義することで分割管理を実現する方法である。
【０１２６】
例えば、トランスポート層のレファレンス値は、通信時のＮＳＡＰアドレス単位に１〜６５５３５までの値であるため、これを４分割して、その２つをそれぞれ通信制御装置２４０，２５０に定義する。残りの２つのブロックは、将来の通信制御装置の増設用に未割当とする。
【０１２７】
第２の方法は管理プログラムによる方法である。この方法では、上位レベルの資源の分割範囲を管理するプログラムと、各通信制御装置内の通信制御プログラムとで、動的に分割範囲を獲得または配分する。
【０１２８】
図３３は管理プログラムによる通信資源の分割の状況を示す図である。通信制御装置２４０は、資源の分配管理プログラム２４２と通信制御・振り分けプログラム２４３とを有している。通信制御装置２５０は、通信制御・振り分けプログラム２５２を有している。
【０１２９】
各通信制御装置２４０，２５０内の通信制御・振り分けプログラム２４３，２５２は、システム起動時や上位レベルのコネクション確立時に振り分け処理部から資源の分割範囲を入手する。図の例では、通信制御・振り分けプログラム２４３には１〜１００が割り当てられ、通信制御・振り分けプログラム２５２には５０１〜６００が割り当てられている。
【０１３０】
第３の方法はコネクション確立時に分配する方法である。この方法では、上位レベル（トランスポート層）のコネクションの確立時に上位資源を管理するプログラム（図３３における分配管理プログラム２４２に該当する）から資源を獲得する。
【０１３１】
以上のいずれかの方法で、分配管理を実現することができる。
また、通信制御装置を２台設けた場合には、サーバの内の状態管理エージェントから各通信制御装置へ状態の変化を通知する。図３４は通信制御装置が２台ある場合のサーバからの通知による運用切り換え状況を示す図である。図において、２台のサーバ３１０，３２０と２台の通信制御装置３０１，３０２とは、ＬＡＮを介して接続されている。通信制御装置３０１，３０２には、それぞれ個別の通信媒体３４３，３４４を介して、端末３６１〜３６４や他のシステム３５１，３５２が接続されている。
【０１３２】
サーバ３１０，３２０内には、アプリケーション（業務プログラムＡ）３１１，アプリケーション（業務プログラムＢ）３２１と状態管理エージェント３１２，３２２が設けられている。通信制御装置３０１，３０２内には、振り分けプログラム３０１ａ，３０２ａが設けられている。
【０１３３】
切り換え前の状態（図中、上側）では、通信媒体３４３を介して送られてきた業務Ａ要求はサーバ３１０へ、業務Ｂの要求はサーバ３２０へ送られる。それらの最大は、共に１００である。同様に、通信媒体３４４を介して送られてきた業務Ａ要求はサーバ３１０へ、業務Ｂの要求はサーバ３２０へ送られる。それらの最大は、共に１００である。
【０１３４】
ここで、状態管理エージェント３１２から業務プログラムＡの利用率低下などの情報が、各通信制御装置３０１，３０２へ送られると、サーバ３１０へ送られる要求の最大数が抑制される。図では（図中、下側）、各通信制御装置３０１，３０２からの最大要求数が５０に制限されている。
【０１３５】
【発明の効果】
以上説明したように本発明では、通信網から送られた処理要求情報を、通信制御装置が、サーバの負荷状態を示す管理情報に基づいて活性状態にある振り分け条件にしたがって選択されたサーバの通信アドレスに送り、いずれかのサーバへ振り分けるようにしたため、利用者側がサーバの通信アドレスなどを認識している必要がなく、利用者にとっては１台のサーバが全ての機能を提供できるように認識でき（１システムビュー）利用者の負担が軽減するとともに、各サーバ間の業務の負荷分散の制御が一括管理できるようになる。
【０１３６】
また、各サーバ内へ要求を振り分けるための条件を活性化・非活性化させることにより運用の切り換えができるようにしたため、サーバ間の負荷の分散を考慮した運用の切り換えが容易となる。
また、活性状態にある振り分け条件において業務提供手段について利用者分類情報が指定されている場合に、利用者分類情報に合致する利用者からの処理要求情報のみをその業務提供手段を有するサーバに振り分けるようにしたため、利用者を指定した運用の切り換えができ、利用者の利用頻度の地域格差を考慮した運用の切り換えが可能となる。
【０１３７】
特に、各サーバに配置した状態管理代理手段が通信制御装置の状態管理手段へ、各サーバの状態を通知するようにすることで、各サーバの動作状況が状態管理手段で一括管理でき、サーバの動作状態をタイムリに把握することができるとともに、各サーバの通信プロトコルに依存せずに状態を管理することが可能となる。
【０１３８】
また、サーバの１つに障害が発生した場合には、他のサーバが障害を検出し通信制御装置にその旨を通知するようにすることで、サーバの障害を隠蔽することができる。従って、ユーザへのサービスを停止させずにサーバの追加、削除が可能となり、システムのスケーラビリティに対応可能となる。
【図面の簡単な説明】
【図１】本発明の原理構成図である。
【図２】本発明のロードシェアシステムの概略構成を示すブロック図である。
【図３】１システムビューの機能を示すブロック図である。
【図４】利用者が認識しているネットワーク網のイメージを示す図である。
【図５】通信制御装置内での通信アドレスのリンク状態を示す図である。
【図６】通信アドレスの変換方式を示す図である。
【図７】通信制御装置での一括管理機能の概略構成を示すブロック図である。
【図８】状態管理を行う際の処理手順を示すフローチャートである。これは、状態管理部が実行する処理である。
【図９】管理簿内の一例を示す図である。
【図１０】状態管理処理の概念図である。
【図１１】通信制御装置の状態要求の際のフローチャートである。
【図１２】状態通知を受け取った通信制御装置の処理手順を示すフローチャートである。
【図１３】通信制御装置からの要求により状態通知を出力する際の状態管理エージェントの処理手順を示すフローチャートである。
【図１４】資源の状態の変化により状態通知を出力する際の状態管理エージェントの処理手順を示すフローチャートである。
【図１５】一括管理された管理情報に基づき利用者からの要求を振り分ける処理の概念図である。
【図１６】振り分け処理のフローチャートである。
【図１７】振り分けキーの取得処理を示す図である。
【図１８】上位レベルの情報をキーとする場合のコネクション手順を示す図である。
【図１９】振り分け先サーバ候補の抽出される情報のリンク状態を示す図である。
【図２０】振り分け処理部に入力する振り分け定義の例を示す図である。
【図２１】図２０に示した振り分け定義による運用の切り換え状況を示す図である。
【図２２】振り分け条件グループと運用とを対応づけた場合の定義の例を示す図である。
【図２３】ユーザの指定を追加した振り分け定義を示す図である。
【図２４】ユーザの指定を追加した振り分け定義による運用の切り換え状況を示す図である。
【図２５】アプリケーションの状態の定義を追加した振り分け定義を示す図である。
【図２６】ロードシェア形態でのトラブル対処の例を示す図である。
【図２７】ホットスタンバイ切り換えを実現するための振り分け定義を示す図である。
【図２８】ホットスタンバイ切り換えの状況を示す図である。
【図２９】振り分け配分の動的な変更を行うための定義の例を示す図である。
【図３０】振り分け配分の動的な変更状況を示す図である。
【図３１】振り分けプログラムと状態管理エージェントの内部構成を示すブロック図である。
【図３２】２台の通信制御装置を有するマルチサーバシステムを示す図である。
【図３３】管理プログラムによる通信資源の分割の状況を示す図である。
【図３４】通信制御装置が２台ある場合のサーバからの通知による運用切り換え状況をしめす図である。
【符号の説明】
１ａ，１ｂ データベース
２，３，４ サーバ
２ａ，３ａ，４ａ 業務提供手段
２ｂ，３ｂ，４ｂ 状態管理代理手段
５ 通信媒体
６ 通信制御装置
６ａ 状態管理手段
６ｂ 振り分け手段
６ｃ 運用操作手段
７ 通信網
８ａ，８ｂ，８ｃ 利用者側装置
１０，２０，３０ サーバ
４１ ＬＡＮ
４２，４３ データベース
４４，４５ 通信媒体
５１，５２ システム
６１〜６４ 端末
１００ 通信制御装置
１１０ 振り分けプログラム
１１１ 状態管理部
１１２ 振り分け処理部
１１３ 運用操作部
Claims (8)
- 通信媒体に接続された複数のサーバと、前記通信媒体及び該通信媒体とは異なる通信網との通信を行う通信制御装置とを有するロードシェアシステムであって、
個々の前記サーバは、
前記通信媒体を介して送られてきた処理要求に伴う業務を提供する業務提供手段と、
前記業務提供手段の使用状態を基にした自己の負荷情報を、前記通信媒体を経由して前記通信制御装置へ送信する状態管理代理手段と、
を有し、
前記通信制御装置は、
前記通信媒体を経由して送られてくる前記サーバからの負荷情報を基に、前記サーバの管理情報を管理する状態管理手段と、
活性状態もしくは非活性状態にある複数の振り分け条件を有しており、前記通信網から前記通信制御装置の宛先通信アドレスを有する処理要求情報が到来した場合、該処理要求情報の宛先通信アドレスを、前記管理情報を基に活性状態にある前記振り分け条件にしたがって選択した前記サーバの通信アドレスに変換し、前記通信媒体を経由して送信する振り分け処理を行う振り分け手段と、
前記振り分け手段が有する個々の前記振り分け条件に対し、活性化もしくは非活性化させる運用操作手段と、
を有し、
前記振り分け手段は、活性状態にある前記振り分け条件において所定の利用者分類情報が指定された前記業務提供手段に対しては、前記利用者分類情報に合致する利用者からの前記処理要求情報のみを振り分ける、
ことを特徴とするロードシェアシステム。 - 前記状態管理手段は、前記状態管理代理手段との間で前記通信媒体を介した通信パスを確立し、前記通信パスを用いて前記サーバの負荷情報を前記状態管理代理手段から受け取ることを特徴とする請求項１記載のロードシェアシステム。
- 前記状態管理手段は、前記通信媒体を介して前記サーバに対して状態監視要求情報を送信し、
前記状態管理代理手段は、前記状態管理手段から前記状態監視要求情報を受けた際に、前記状態管理手段へ負荷情報を送信する、
ことを特徴とする請求項１記載のロードシェアシステム。 - 前記状態管理代理手段は、前記業務提供手段の状態が変化した場合に、前記状態管理手段へ負荷情報を送信することを特徴とする請求項１記載のロードシェアシステム。
- 前記サーバの前記業務提供手段は、互いに共用のデータベースを管理していることを特徴とする請求項１記載のロードシェアシステム。
- 前記振り分け手段は、前記サーバ内の前記業務提供手段を所定のキーに対応づけて管理しており、前記処理要求情報が到来すると、前記処理要求情報の内容から振り分けキーを特定し、前記振り分けキーに対応する前記業務提供手段を前記処理要求情報の振り分け先候補として選択する、ことを特徴とする請求項１記載のロードシェアシステム。
- 前記状態管理代理手段は、動作していることを互いに確認し合っており、他の前記サーバが停止したことを検出するとその旨を前記状態管理手段に通知することを特徴とする請求項１記載のロードシェアシステム。
- 前記状態管理手段は、前記サーバを現用サーバと待機サーバとに分けて管理しており、前記現用サーバが停止した旨の通知を受け取ると前記現用サーバの振り分け状態を非活性化し、前記待機サーバの振り分け状態を活性化することを特徴とする請求項７記載のロードシェアシステム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP02635196A JP3847364B2 (ja) | 1996-02-14 | 1996-02-14 | ロードシェアシステム |
| US08/699,562 US6128657A (en) | 1996-02-14 | 1996-08-19 | Load sharing system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP02635196A JP3847364B2 (ja) | 1996-02-14 | 1996-02-14 | ロードシェアシステム |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2006201368A Division JP3974155B2 (ja) | 2006-07-24 | 2006-07-24 | 通信制御装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH09218842A JPH09218842A (ja) | 1997-08-19 |
| JP3847364B2 true JP3847364B2 (ja) | 2006-11-22 |
Family
ID=12191054
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP02635196A Expired - Fee Related JP3847364B2 (ja) | 1996-02-14 | 1996-02-14 | ロードシェアシステム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3847364B2 (ja) |
Families Citing this family (28)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3966598B2 (ja) * | 1998-03-04 | 2007-08-29 | 富士通株式会社 | サーバ選択システム |
| JP2000155736A (ja) * | 1998-11-24 | 2000-06-06 | Nec Corp | サービス要求の振り分け方法及びアドレス変換装置 |
| JP3690720B2 (ja) | 1999-09-14 | 2005-08-31 | インターナショナル・ビジネス・マシーンズ・コーポレーション | クライアントサーバーシステム、オブジェクトのプール方法および記憶媒体 |
| JP2001101149A (ja) * | 1999-09-30 | 2001-04-13 | Nec Corp | 分散並列型データ処理装置及び分散並列型データ処理プログラムを記録した記録媒体並びに分散並列型データ処理システム |
| JP2001117887A (ja) * | 1999-10-14 | 2001-04-27 | Nec Corp | 分散型アプリケーションサーバシステム，サービス方法および記録媒体 |
| JP2001117899A (ja) * | 1999-10-18 | 2001-04-27 | Nec Corp | マルチサーバシステム |
| JP2001236293A (ja) * | 2000-02-24 | 2001-08-31 | Nec Corp | サーバ負荷分散装置 |
| US7139805B2 (en) | 2000-05-30 | 2006-11-21 | Hewlett-Packard Development Company, L.P. | Scalable java servers for network server applications |
| JP4612961B2 (ja) * | 2001-03-14 | 2011-01-12 | 株式会社日本総合研究所 | 分散処理方法および分散処理システム |
| US6820126B2 (en) * | 2001-04-02 | 2004-11-16 | Motorola, Inc. | System for dynamic process assignment in a local area network and method therefor |
| US7237243B2 (en) * | 2001-06-11 | 2007-06-26 | Microsoft Corporation | Multiple device management method and system |
| JP3487430B2 (ja) * | 2001-07-16 | 2004-01-19 | 日本電気株式会社 | サーバアプリケーション多重化通信システム |
| JP3891273B2 (ja) * | 2002-03-05 | 2007-03-14 | 日本電気株式会社 | トランザクション処理の負荷分散方法およびそのシステム |
| JP4108486B2 (ja) | 2003-01-08 | 2008-06-25 | Ｎｅｃインフロンティア株式会社 | Ｉｐルータ、通信システム及びそれに用いる帯域設定方法並びにそのプログラム |
| US7636917B2 (en) * | 2003-06-30 | 2009-12-22 | Microsoft Corporation | Network load balancing with host status information |
| JP3952031B2 (ja) * | 2004-03-22 | 2007-08-01 | 日本電気株式会社 | 分散オブジェクトシステム及びサーバ |
| JP4555592B2 (ja) * | 2004-03-31 | 2010-10-06 | 富士通株式会社 | パケット処理システム |
| DE602005013763D1 (de) * | 2004-04-23 | 2009-05-20 | Panasonic Corp | Netzwerk-betriebsmittelverwaltungseinrichtung |
| JP4190455B2 (ja) | 2004-05-11 | 2008-12-03 | 富士通株式会社 | 負荷分散装置及びプログラム |
| WO2006004995A2 (en) * | 2004-06-30 | 2006-01-12 | Glenayre Electronics, Inc. | Load balancing in a distributed telecommunications platform |
| JP4558740B2 (ja) * | 2004-10-20 | 2010-10-06 | 富士通株式会社 | アプリケーション管理プログラム、アプリケーション管理方法、およびアプリケーション管理装置 |
| WO2006043322A1 (ja) * | 2004-10-20 | 2006-04-27 | Fujitsu Limited | サーバ管理プログラム、サーバ管理方法、およびサーバ管理装置 |
| US8607236B2 (en) | 2005-08-22 | 2013-12-10 | Ns Solutions Corporation | Information processing system |
| EP1793564A1 (en) * | 2005-11-30 | 2007-06-06 | Thomson Telecom Belgium | Device and method to detect applications running on a local network for automatically performing the network address translation |
| JP2007219637A (ja) * | 2006-02-14 | 2007-08-30 | Nippon Telegr & Teleph Corp <Ntt> | 負荷分散システムおよびそのプログラム |
| JP2007316837A (ja) * | 2006-05-24 | 2007-12-06 | Fujitsu Ltd | サーバシステム |
| WO2012042607A1 (ja) * | 2010-09-29 | 2012-04-05 | 株式会社トライテック | 分散コンピューティングシステム |
| JP5666620B2 (ja) * | 2010-12-07 | 2015-02-12 | 株式会社日立製作所 | ネットワークシステム、及びそのサービス品質制御方法 |
Family Cites Families (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2591334B2 (ja) * | 1990-11-16 | 1997-03-19 | 日本電気株式会社 | 相互スタンバイシステム |
| JPH05265954A (ja) * | 1992-03-19 | 1993-10-15 | Chugoku Nippon Denki Software Kk | コンピュータシステム |
| JPH05316116A (ja) * | 1992-05-14 | 1993-11-26 | Matsushita Electric Ind Co Ltd | サーバの予備系の一元管理装置 |
| JPH06161924A (ja) * | 1992-11-27 | 1994-06-10 | Hitachi Ltd | 負荷分散方法 |
| JP3003440B2 (ja) * | 1993-01-19 | 2000-01-31 | 株式会社日立製作所 | 負荷分散制御方法および分散処理システム |
| JPH06266643A (ja) * | 1993-03-17 | 1994-09-22 | Yokogawa Electric Corp | サーバプログラム管理方法 |
| JPH07121468A (ja) * | 1993-10-20 | 1995-05-12 | Fuji Xerox Co Ltd | サーバー選択装置 |
| JP3241911B2 (ja) * | 1993-12-13 | 2001-12-25 | 富士通株式会社 | ライブラリ装置を共用するデータ処理装置 |
| JPH07219787A (ja) * | 1994-01-28 | 1995-08-18 | Hitachi Ltd | 予測制御型並列分散処理方式、及びコンピュータシステム、並びにネットワークシステム |
-
1996
- 1996-02-14 JP JP02635196A patent/JP3847364B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH09218842A (ja) | 1997-08-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3847364B2 (ja) | ロードシェアシステム | |
| US6128657A (en) | Load sharing system | |
| US7089281B1 (en) | Load balancing in a dynamic session redirector | |
| US7039916B2 (en) | Data delivery system for adjusting assignment of connection requests to nodes based upon the tracked duration | |
| JP3573386B2 (ja) | 負荷制御を行う大規模クライアントサーバーシステム | |
| CN101242392B (zh) | 用于系列服务消息处理的方法、设备和系统 | |
| EP0706685B1 (en) | An integrated plant environment system having a PROGRAM-TO-PROGRAM COMMUNICATION SERVER and method | |
| CN108958920A (zh) | 一种分布式任务调度方法及系统 | |
| US8683025B2 (en) | Method for managing storage system | |
| JP2018504038A (ja) | ソフトウェア定義型データセンター、並びにそのためのサービスクラスタスケジューリング方法及びトラフィック監視方法 | |
| JP2000268012A (ja) | クライアントサーバシステムにおけるサーバ負荷の分散方法ならびに装置 | |
| JP2004519024A (ja) | 多数のノードを含むクラスタを管理するためのシステム及び方法 | |
| WO2004036344A2 (en) | System and method for the optimization of database | |
| CN110166524B (zh) | 数据中心的切换方法、装置、设备及存储介质 | |
| CN101237413B (zh) | 在转发和控制分离网络件架构下实现控制件高可用性的方法 | |
| CN109407980A (zh) | 基于Redis集群的数据存储系统 | |
| US20080086547A1 (en) | Method and system for reduced distributed event handling in a network environment | |
| CN105721553B (zh) | 一种自适应集群消息分发器 | |
| CN113709220B (zh) | 虚拟负载均衡器的高可用实现方法、系统及电子设备 | |
| JP3974155B2 (ja) | 通信制御装置 | |
| US5077730A (en) | Method of auditing primary and secondary node communication sessions | |
| JPH09293059A (ja) | 分散システム及びその運用管理方法 | |
| MXPA02006896A (es) | Metodo y aparato para proporcionar comunicaciones confiables en una red inteligente. | |
| US6535923B1 (en) | Method and system for defining an efficient and reliable meshing of CP-CP sessions in an advanced peer to peer network | |
| Pashkov et al. | On high availability distributed control plane for software-defined networks |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20030603 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060724 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060823 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090901 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100901 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100901 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110901 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120901 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |