JPH09218842A

JPH09218842A - ロードシェアシステム

Info

Publication number: JPH09218842A
Application number: JP8026351A
Authority: JP
Inventors: Katsutoshi Okanoya; 勝俊岡ノ谷; Susumu Matsumoto; 進松本; Kazuhiko Shoji; 和彦庄司; Yutaka Konishi; 豊小西; Akira Takahashi; 明高橋; Masamitsu Kimura; 雅充木村; Mitsuru Kusakawa; 充草川; Takahito Sakai; 隆人坂井
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 1996-02-14
Filing date: 1996-02-14
Publication date: 1997-08-19
Anticipated expiration: 2016-02-14
Also published as: JP3847364B2

Abstract

(57)【要約】【課題】運用効率を最適に保ち高い信頼性を有するロ
ードシェアシステムを通信媒体を介して構築する。【解決手段】状態管理手段６ａは、状態管理代理手段
２ｂ，３ｂ，４ｂとの間で通信媒体５を介した通信パス
を確立し、通信パスを用いて各サーバ２，３，４の状態
を示す管理情報を状態管理代理手段から受け取り、サー
バ２，３，４の状態を一括管理する。振り分け手段６ｂ
は、通信網７を介して接続されている利用者側装置８
ａ，８ｂ，８ｃからの要求を受信し、状態管理手段６ａ
が管理している情報に基づき要求の振り分け先を決定
し、要求をサーバ２，３，４に対する処理要求として通
信媒体５を介して送信する。運用操作手段６ｃは、業務
提供手段２ａ，３ａ，４ａに要求を振り分けるための複
数の条件の活性化又は非活性化の状態切り換えを行う。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は複数のプロセッサで
分散処理を行うロードシェアシステムに関し、特に通信
媒体を介して構築されたロードシェアシステムに関す
る。

【０００２】

【従来の技術】多数の利用者に様々な機能を提供する場
合、サーバが利用者に提供する業務を複数のプロセッサ
に分散させることができる。このような分散処理を行う
システムをロードシェアシステムと呼ぶ。このロードシ
ェアシステムをローカル・エリア・ネットワーク（ＬＡ
Ｎ）に接続された複数のサーバで構築することも行われ
ている。ここで業務とは、サーバがアプリケーションプ
ログラム（以後、単に「アプリケーション」と呼ぶ）を
実行することにより、利用者に代わってデータ処理を行
う際の処理単位をいう。

【０００３】従来のＬＡＮで構築されたロードシェアシ
ステムでは、複数のサーバ間の負荷の分散の割合は、予
めネットワーク上で定義付けられており実質的に固定で
ある。つまり、システムの負荷の分散を自由に制御する
ことはできない。

【０００４】従って、業務の運用を切り換えるには、サ
ーバ単位にアプリケーションを操作するか、あるいは各
サーバの持つネットワーク資源を操作していた。サーバ
のアプリケーションを操作する場合は、そのアプリケー
ションの起動・停止、及び受け付ける業務の数の変更等
の操作を行う。ネットワーク資源を操作する場合は、そ
の各サーバ上のネットワーク資源を個々に活性化あるい
は非活性化の操作を行う。

【０００５】一方、システムの利用者が業務の提供を受
けるには、複数のサーバの個々にアクセスする必要があ
る。個々のサーバにアクセスするには、それぞれのサー
バの通信アドレスや業務が設けられている構成などを利
用者側で認識していなければならない。

【０００６】

【発明が解決しようとする課題】しかし、従来のロード
シェアシステムでは負荷の分散を一括して制御できない
ため、システムの運用状況の変化に応じた負荷分散の制
御ができず、システムの運用効率の悪化や信頼性の低下
を招いていた。つまり、業務が１つのサーバに集中した
り、バッチ処理等の臨時業務が発生すると、利用者側で
のレスポンスが悪化する場合があった。また、アプリケ
ーションやサーバ自身に障害が発生すると、利用者から
の要求が拒否される場合があった。

【０００７】なお、システムの管理者が各サーバごとに
資源などを操作することにより負荷の配分を変更するこ
とは可能であったが、それには利用者がどのサーバのど
の業務に集中しているのかをその都度的確に判断しなけ
ればならない。運用中のサーバの負荷は常に変動するた
め、システムの管理者が常に的確な判断を行いロードシ
ェアシステムの負荷分散を最適化することは困難であ
る。

【０００８】一方、利用者にとっては、個々のサーバに
アクセスしなければならないため、利用者側の端末にお
いても複雑な通信環境の設定を行う必要があり、利用者
の負担が大きいという問題点があった。

【０００９】本発明はこのような点に鑑みてなされたも
のであり、運用効率を最適に保ち高い信頼性を有する、
ＬＡＮを介して構築されたロードシェアシステムを提供
することを目的とする。

【００１０】

【課題を解決するための手段】本発明では上記課題を解
決するために、複数のプロセッサで機能を分散させるロ
ードシェアシステムにおいて、通信媒体を介して送られ
た処理要求を処理する複数のサーバと、利用者側装置が
接続された通信網と前記通信媒体とに接続されており、
前記利用側装置から出力された要求を前記通信網を介し
て受信し、前記要求を前記サーバのいずれかに対する前
記処理要求として前記通信媒体を介して送信する通信制
御装置と、を有することを特徴とするロードシェアシス
テムが提供される。

【００１１】この構成によれば、利用者端末から送られ
た要求は、通信制御装置でいずれかのサーバへ振り分け
られる。従って、利用者側が個々のサーバの通信アドレ
スなどを認識している必要がない。

【００１２】また、本発明では、通信媒体を介して送ら
れた処理要求を実行する業務提供手段と、自己の動作状
態を管理する状態管理代理手段とを有する複数のサーバ
と、前記状態管理代理手段との間で前記通信媒体を介し
た通信パスを確立し、前記通信パスを用いて各前記サー
バの状態を示す管理情報を前記状態管理代理手段から受
け取り、前記サーバの状態を一括管理する状態管理手段
を有する通信制御装置と、を有することを特徴とするロ
ードシェアシステムが提供される。

【００１３】この構成によれば、各サーバの動作状況は
状態管理代理手段から状態管理手段に送られ、状態管理
手段で各サーバの動作状況が一括管理される。従って、
サーバの動作状態をタイムリに把握することができる。

【００１４】

【発明の実施の形態】以下、本発明の実施の形態を図面
に基づいて説明する。図１は本発明の原理構成図であ
る。サーバ２は、データベース（ＤＢ）１ａを有してい
る。サーバ３，４は、共用のデータベース１ｂを有して
いる。これら複数のサーバ２，３，４は、通信媒体５を
介して送られた処理要求を処理する業務提供手段２ａ，
３ａ，４ａと、自己の動作状態を管理する状態管理代理
手段２ｂ，３ｂ，４ｂとを有している。

【００１５】通信制御装置６において、状態管理手段６
ａは、状態管理代理手段２ｂ，３ｂ，４ｂとの間で通信
媒体５を介した通信パスを確立し、通信パスを用いて各
サーバ２，３，４の状態を示す管理情報を状態管理代理
手段から受け取り、サーバ２，３，４の状態を一括管理
する。振り分け手段６ｂは、通信網７を介して接続され
ている利用者側装置８ａ，８ｂ，８ｃからの要求を受信
し、状態管理手段６ａが管理している情報に基づき要求
の振り分け先を決定し、要求をサーバ２，３，４に対す
る処理要求として通信媒体５を介して送信する。運用操
作手段６ｃは、業務提供手段２ａ，３ａ，４ａに要求を
振り分けるための複数の条件の活性化又は非活性化の状
態切り換えを行う。

【００１６】このような構成において、各サーバ２，
３，４の動作状況は状態管理代理手段２ｂ，３ｂ，４ｂ
から状態管理手段６ａに送られ、状態管理手段６ａは各
サーバ２，３，４の動作状況を一括管理する。そして、
利用者側装置８ａ，８ｂ，８ｃから出力された要求は、
通信網７を介して通信制御装置６に送られる。通信制御
装置６内では、振り分け手段６ｂが現在活性状態となっ
ている条件に基づいて要求の振り分け先を決定し、出力
を受けた要求を、振り分け先として決定したサーバの業
務提供手段への処理要求として、該当するサーバへ送信
する。処理要求を受け取ったサーバの業務提供手段は、
処理要求の内容に従って、データベースを操作する。ま
た、各サーバ２，３，４の動作状況に変化が生じ、負荷
配分を変える必要が生じた場合には、運用操作手段６ｃ
が、振り分け比率等の振り分けの条件を操作する。

【００１７】このようにして、利用者はこのシステムが
複数のサーバによるロードシェアシステムであることを
意識せずにすむ。また、通信制御装置６は、状態管理代
理手段２ｂ，３ｂ，４ｂから各サーバ２，３，４内の状
態に関する情報を収集しているため、最適な負荷の分散
を行うことができる。さらに、運用操作手段６ｃが、振
り分け条件の活性化・非活性化の切り換えを行うことに
より、様々な状況の変化に対して直ぐに適切な対処をす
ることが可能となり、システムの負荷の配分を最適化す
ることができる。

【００１８】ところで、上記のロードシェアシステムを
実現するためのハードウェア構成として、通信制御装置
が１台の場合と複数台の場合とが考えられる。以下の説
明では、まず通信制御装置が１台の場合について説明
し、その後通信制御装置が複数台の場合について説明す
る。

【００１９】図２は本発明のロードシェアシステムの概
略構成を示すブロック図である。これは、通信制御装置
が１台の場合の構成である。この図には１つのローカル
エリアネットワーク（ＬＡＮ）４１と２つの通信媒体４
４，４５が示されている。ＬＡＮ４１には、複数のサー
バ１０，２０，３０と通信制御装置１００とが接続され
ている。サーバ１０にはデータベース（ＤＢ）４２が接
続されている。サーバ２０，３０は、データベース４３
を共有している。通信媒体４４には、通信制御装置１０
０と他の複数のシステム５１，５２とが接続されてい
る。各システム５１，５２には、端末６１，６２が接続
されている。通信媒体４５には、通信制御装置１００と
複数の端末６３，６４とが接続されている。

【００２０】サーバ１０，２０，３０のそれぞれには、
利用者に各種業務を提供するアプリケーション１１，２
１，３１、自己の動作状態を示すデータが格納された状
態管理テーブル１２，２２，３２、及び通信制御装置１
００へ自己の動作状態を報告する状態管理エージェント
１３，２３，３３が設けられている。

【００２１】通信制御装置１００はＬＡＮ４１と他の通
信媒体４４，４５との情報通信を制御する装置であり、
内部にネットワーク連携装置１００ａを有している。ネ
ットワーク連携装置１００ａは、振り分けプログラム１
１０と記憶装置１２０とを有している。振り分けプログ
ラム１１０は、状態管理エージェントから各サーバ１
０，２０，３０の状態を収集し一括管理する状態管理部
１１１、利用者からの要求をいずれかのサーバに振り分
ける振り分け処理部１１２、及び要求を振り分けるため
の条件の活性化・非活性化の切り換えを行う運用操作部
１１３から構成されている。また、記憶装置１２０内に
は各サーバの負荷状態を示す負荷分散情報１２１、各サ
ーバに振り分けられた要求の情報を示す状態管理テーブ
ル１２２、及び運用を切り換えるための複数の条件が格
納された運用テーブル１２３が格納されている。

【００２２】以上のような１台の通信制御装置で構成さ
れるロードシェアシステムは、大別して次の諸機能を備
えている。第１の機能は、通信制御装置１００とサーバ
１０，２０，３０とが一体となり、１つのサーバのよう
に振る舞う機能である。言い換えると、通信制御装置１
００が他のサーバ１０，２０，３０を隠蔽し、利用者か
らは１つのシステムとみえるようにする機能である。以
後、この機能を１システムビュ−と呼ぶ。

【００２３】第２の機能は、サーバ側に配置した状態管
理エージェント１３，２３，３３の働きにより、各サー
バ１０，２０，３０のアプリケーションの動作状況を通
信制御装置１００で一括管理する機能である。

【００２４】第３の機能は、上記第１の機能と第２の機
能とを併用した機能である。つまり、通信制御装置１０
０が一括管理している各サーバの管理情報に基づき、利
用者からの要求を適切なサーバへ振り分けることによ
り、負荷配分の最適化を図る機能である。

【００２５】第４の機能は、上記第１の機能を用いて要
求を振り分ける際に、振り分け先を決定するための条件
の活性化・非活性化を切り換えることにより、効率的な
負荷の分散を実現する機能である。

【００２６】第５の機能は、第４の機能を実行する際
に、第２の機能で管理している各サーバ１０，２０，３
０の負荷状態に応じて、動的に振り分け条件を切り換え
る機能である。

【００２７】まず、第１の機能である１システムビュー
について説明する。図３は１システムビューの機能を示
すブロック図である。なお、この図では、図２における
２つの通信媒体４４，４５を包括して通信媒体４６とし
ている。

【００２８】ここでは、端末６３、６４や、他のシステ
ム５１、５２からＤＢ４２，４３の更新処理の要求を出
力する場合を例にとり説明する。端末６３、６４やシス
テム５１、５２から要求７１，７２を出力する際には、
通信制御装置１００の通信アドレス（Ａ）を送信先とし
て指定して出力する。すると、その要求７１，７２は通
信媒体４６を介して通信制御装置１００に送られる。通
信制御装置１００では、振り分け処理部１１２が要求７
１，７２に含まれるロードシェアシステムとしての通信
アドレス（Ａ）をサーバ１０，２０，３０のいずれかの
通信アドレス（Ｂ），通信アドレス（Ｃ），通信アドレ
ス（Ｄ）に変換する。そして、通信アドレス変換後の要
求７３，７４，７５は、通信制御装置１００からＬＡＮ
４１を介していずれかのサーバに転送される。サーバ１
０，２０，３０内のアプリケーション１１，２１，３１
は、要求を受け取るとその要求内容に応じてＤＢ４２，
４３を操作する。

【００２９】このようにして、端末６３、６４や、他の
システム５１、５２からは、通信制御装置１００の通信
アドレス（Ａ）を指定して、アプリケーションの機能の
提供を受けることができる。つまり、利用者はサーバ１
０，２０，３０の存在を意識する必要がない。

【００３０】図４は利用者が認識しているネットワーク
網のイメージを示す図である。利用者は、通信媒体４６
には端末６３，６４、システム５１、５２及び共用ＤＢ
４２，４３を操作するアプリケーション１０１ａを有す
るサーバ１００ａが存在しているように認識している。
このサーバ１００ａは、実際にはサーバ１０，２０，３
０と通信制御装置１００との複合システムである。

【００３１】一方、通信制御装置１００では、通信アド
レス（Ａ）と各サーバ１０，２０，３０のそれぞれの通
信アドレス（Ｂ），通信アドレス（Ｃ），通信アドレス
（Ｄ）とを相互にリンクさせている。

【００３２】図５は通信制御装置１００内での通信アド
レスのリンク状態を示す図である。通信制御装置１００
の通信アドレス（Ａ）８１からサーバ１０の通信アドレ
ス（Ｂ）８２、サーバ２０の通信アドレス（Ｃ）８３、
サーバ３０の通信アドレス（Ｄ）８４の順でリンクが張
られている。また、通信アドレス（Ｂ）８２から通信ア
ドレス（Ａ）８１へ、通信アドレス（Ｃ）８３から通信
アドレス（Ａ）８１へ、通信アドレス（Ｄ）８４から通
信アドレス（Ａ）８１へ、それぞれリンクが張られてい
る。

【００３３】この状態で、振り分け処理部１１２は、利
用者の端末６３、６４やシステム５１，５２側からサー
バ１０，２０，３０側へ、あるいはサーバ１０，２０，
３０側から利用者の端末６３，６４やシステム５１，５
２側への通信アドレスの変換を行う。以下に、通信アド
レスの変換方式を示す。

【００３４】図６は通信アドレスの変換方式を示す図で
ある。このネットワーク網では、２つの通信アドレスが
ペアとなって伝送される。図中の左側は、通信制御装置
１００とサーバ１０，２０，３０との間で使用される通
信アドレスペア８５〜８７である。通信アドレスペア８
５〜８７は、各サーバ１０，２０，３０のそれぞれの通
信アドレス（Ｂ），通信アドレス（Ｃ），通信アドレス
（Ｄ）と利用者の端末の通信アドレス（ｘ）とのペアで
ある。一方、図中の右側は、通信制御装置１００と端末
６１〜６４との間で使用される通信アドレスペア８８で
ある。通信アドレスペア８８は、各通信制御装置１００
の通信アドレス（Ａ）と利用者の端末の通信アドレス
（ｘ）のペアである。

【００３５】通信制御装置１００内の振り分け処理部１
１２は、通信媒体４６を介して通信アドレスペア８８を
受け取ると、通信アドレスペア８８内の自己の通信アド
レス（Ａ）をサーバ１０，２０，３０のいずれかの通信
アドレスに変更する。そして、変更後の通信アドレスペ
アをＬＡＮ４１上に出力する。

【００３６】次に、第２の機能である、サーバ内のアプ
リケーションの状態を通信制御装置１００で一括管理す
る機能について説明する。図７は通信制御装置１００で
の一括管理機能の概略構成を示すブロック図である。こ
の機能を実現するために、通信制御装置１００側の状態
管理部１１１と各サーバ１０，２０，３０側の状態管理
エージェント１３，２３，３３との間でサーバの状態管
理用の通信パス９１，９２，９３を確立している。状態
管理部１１１は通信パス９１，９２，９３を使用して、
アプリケーション１１，２１，３１の状態要求を状態管
理エージェント１３，２３，３３へ送信する。状態管理
エージェント１３，２３，３３は状態取得要求を受信す
ると、アプリケーション１１，２１，３１の動作状況を
状態管理部１１１へ送信する。状態管理部１１１は、各
状態管理エージェント１３，２３，３３が応答したアプ
リケーション１１，２１，３１の動作状況を記憶装置１
２０で一括管理する。記憶装置１２０内では、各サーバ
の動作状況は負荷分散情報１２１と状態管理テーブル１
２２とに分けて管理される。以後、負荷分散情報１２１
と状態管理テーブル１２２とに運用情報を加えたものを
管理簿と呼ぶ。

【００３７】図８は状態管理を行う際の処理手順を示す
フローチャートである。これは、状態管理部１１１が実
行する処理である。〔Ｓ１〕状態管理エージェント１３，２３，３３との間
で状態管理用の通信パス９１，９２，９３を確立する。〔Ｓ２〕状態管理エージェント１３，２３，３３に対し
て状態要求を送信する。〔Ｓ３〕状態管理エージェント１３，２３，３３からサ
ーバ１０，２０，３０毎のアプリケーション１１，２
１，３１の状態を受信する。〔Ｓ４〕アプリケーション１１，２１，３１の状態が変
化した際に状態管理エージェント１３，２３，３３が出
力する状態変更情報を受信する。〔Ｓ５〕サーバ１０，２０，３０のアプリケーション１
１，２１，３１の状態を管理簿を用いて管理する。

【００３８】以下に、管理簿の内容について説明する。
図９は管理簿内の一例を示す図である。管理簿では、
「業務」、「運用情報」、「状態管理情報」、及び「負
荷分散情報」に分けて管理されている。

【００３９】「業務」は、ロードシェアシステムで実行
される処理の単位である。「運用情報」は、「業務」が
サービスの提供を行っている場合には「運用中」であ
り、サービスの提供を停止してる場合には「停止中（抑
止状態）」である。

【００４０】「状態管理情報」は、「通信先サーバ情
報」、「サーバ上のアプリケーションプログラム」、
「ＩＤ」、及び「状態」に別れている。「通信先サーバ
情報」は、後に続く情報がどのサーバの情報であるかを
示している。「サーバ上のアプリケーションプログラ
ム」は、サーバ内で業務を提供しているアプリケーショ
ンプログラムの名称を示している。「ＩＤ」は、サーバ
上のアプリケーション単位に割り振られた識別番号であ
る。「状態」は、アプリケーションが使用可能であるか
否かを示している。

【００４１】なお、「ＩＤ」の情報は、状態管理エージ
ェントとの間の状態に関する情報の交換の際に使用され
る。ネットワーク連携装置１００ａ内でエージェントか
らの状態を反映する際、「ＩＤ」を用いることにより資
源検索の高速化が図れる。

【００４２】「負荷分散情報」は、「振り分け数の情
報」と「比率情報」とに分かれている。「振り分け数の
情報」は、アプリケーションへ振り分けた利用者からの
要求の数を示している。「比率情報」は、当該業務に対
する全要求数の中の、各サーバに現在振り分けられてい
る要求の割合を示している。この数字から、アプリケー
ションの負荷の分散状況を知ることができる。

【００４３】図１０は状態管理処理の概念図である。こ
の図では、サーバ１０はアプリケーション１１，１４を
有しており、サーバ２０はアプリケーション２１，２４
を有している。なお、アプリケーション１１とアプリケ
ーション２１とは同じ業務を提供するアプリケーション
である。また、状態管理簿１２３の内容は、図９に示し
たものである。ここで、アプリケーション１１，１４，
２１は動作しているが、アプリケーション２４は停止し
ているものとする。

【００４４】このような条件で、通信制御装置１００内
の状態管理部１１１は、まずサーバ１０とサーバ２０と
に対する問い合わせ情報１０１、１０３を組み立て、そ
れを状態要求として出力する。サーバ１０，２０内のそ
れぞれの状態管理エージェント１３，２３は状態要求に
応答し、自己のサーバ内のアプリケーションの状態を示
す応答情報１０２、１０４を出力する。状態管理部１１
１は応答情報１０２、１０４を受けとり、その内容を管
理簿１２３に反映する。

【００４５】図１１は通信制御装置の状態要求の際のフ
ローチャートである。これは、通信制御装置１００内の
状態管理部１１１が実行する処理である。〔Ｓ１１〕管理状態を通信するための通信パスを各状態
管理エージェントとの間で確立する。〔Ｓ１２〕管理簿より状態管理情報の読み込みを行う。〔Ｓ１３〕サーバ単位に状態問い合わせ情報を組み立て
る。この時に、資源単位に「ＩＤ」が設定される。〔Ｓ１４〕サーバ内状態管理エージェントへの状態要求
を送信する。

【００４６】図１２は状態通知を受け取った通信制御装
置の処理手順を示すフローチャートである。これは、通
信制御装置１００内の状態管理部１１１が実行する処理
である。〔Ｓ２１〕状態管理エージェントからの状態通知を受信
する〔Ｓ２２〕受信した状態通知内のＩＤから、資源を特定
する。〔Ｓ２３〕特定した資源が使用可能であるのか、使用不
可能であるのかを判別する。使用可能であればステップ
Ｓ２４に進み、使用不可能であればステップＳ２５に進
む。〔Ｓ２４〕特定した資源が使用可能である旨を管理簿に
反映する。〔Ｓ２５〕特定した資源が使用不可能である旨を管理簿
に反映する。

【００４７】以上の図１１、図１２が通信制御装置で実
行される処理手順である。次に、各サーバ内における状
態管理エージェントで実行される処理手順を説明する。
図１３は通信制御装置からの要求により状態通知を出力
する際の状態管理エージェントの処理手順を示すフロー
チャートである。〔Ｓ３１〕通信制御装置との間の状態管理パスを確立す
る。〔Ｓ３２〕ネットワーク連携装置内の状態管理部から振
り分け資源の状態要求を受信する。〔Ｓ３３〕振り分け資源の状態確認及び状態遷移通知出
口を状態管理エージェント内に登録する。これで、振り
分け資源名とその状態を示す管理テーブルが作成され
る。ここで、状態遷移通知出口とは、サーバ内でアプリ
ケーションを管理しているプログラムから状態管理エー
ジェントへ資源の状態を通知するための情報伝達の受信
口である。この受信口（状態遷移通知出口）を状態管理
エージェントに登録しておくことにより、アプリケーシ
ョンの状態を状態管理エージェントが取得可能となる。〔Ｓ３４〕状態要求で指定された資源が使用可能状態
か、使用不可能状態かを判別する。使用可能状態であれ
ばステップＳ３５に進み、使用不可能状態であればステ
ップＳ３６に進む。〔Ｓ３５〕状態要求で指定された資源が使用可能である
旨を状態管理部に通知する。〔Ｓ３６〕状態要求で指定された資源が使用不可能であ
る旨を状態管理部に通知する。

【００４８】図１４は資源の状態の変化により状態通知
を出力する際の状態管理エージェントの処理手順を示す
フローチャートである。〔Ｓ４１〕振り分け資源（ロードシェアシステムで機能
を分散させるべき資源）の状態の変化を検出する。〔Ｓ４２〕状態遷移が発生し、状態遷移出口を起動す
る。〔Ｓ４３〕状態遷移の状況を状態管理部に通知する。〔Ｓ４４〕他の資源に状態の変化があるか否かを判断
し、状態が変化した資源があればステップＳ４１に進
み、状態が変化した資源がなければステップＳ４５に進
む。〔Ｓ４５〕状態管理パスを解放し、状態遷移通知出口を
削除する。

【００４９】以上のようにして、サーバ内のアプリケー
ションの状態を通信制御装置１００で一括管理すること
ができる。この方式では、管理簿内のＩＤにより管理対
象を特定し、サーバシステムに適した状態管理エージェ
ントを配置することにより、サーバシステムの種別に依
存せずに通信制御装置１００でアプリケーションを一括
管理することができる。例えば、サーバシステムが大型
のホスト計算機であっても、ＵＮＩＸのシステムであっ
てもよい。

【００５０】また、管理簿内のＩＤにより管理対象を特
定し、サーバシステムに適した状態管理エージェントを
配置することにより、アプリケーションの通信プロトコ
ルに依存せずに管理することができる。

【００５１】次に、第３の機能である、上記第１の機能
と第２の機能とを併用した機能について説明する。この
機能では、通信制御装置１００が一括管理している各サ
ーバの管理情報に基づき、利用者からの要求を適当なサ
ーバへ振り分けることにより、負荷配分の最適化を図
る。

【００５２】図１５は一括管理された管理情報に基づき
利用者からの要求を振り分ける処理の概念図である。図
において、状態管理エージェント１３，２３，３３と状
態管理部１１１との間には通信パス９４〜９６が確立さ
れている。これにより、各サーバ１０，２０，３０内の
アプリケーション１１，２１，３１の動作状態は、状態
管理部１１１で一括管理される。それらの状態管理情報
は記憶装置１２０内に管理簿として格納されている。

【００５３】そして、利用者の端末６１，６３，６４か
らＤＢ４２，４３に対する要求７６，７６ａが出力され
ると、その要求は通信媒体４６を介して振り分け処理部
１１２に入力される。振り分け処理部１１２は、状態管
理部１１１から各アプリケーション１１，２１，３１の
現在の状態の情報を取得し、その情報から各サーバへの
負荷が分散するように、要求を実行させるアプリケーシ
ョンを特定する。そして、特定したアプリケーションに
対して要求７７〜７９を出力する。要求を受け取ったア
プリケーションは、要求内容に従ってＤＢ４２，４３を
処理する。

【００５４】ここで、振り分け処理部１１２では、利用
者からの要求の一部を振り分けキーとし、振り分けキー
に対応付けた振り分け先候補とその所在を管理してお
く。図１６は振り分け処理のフローチャートである。な
お、ステップＳ５１〜ステップＳ５９までの処理は、振
り分け処理部が実行する。ステップＳ６０の処理はトラ
ンザクション処理であればアプリケーションが実行し、
コネクション処理であればアプリケーションと利用者の
端末とにより実行される。〔Ｓ５１〕ネットワーク利用者からのコネクション確立
要求、またはトランザクション開始要求を受信する。

【００５５】以下のステップは、サーバ側のコネクショ
ン確立処理、またはトランザクションの開始処理であ
る。〔Ｓ５２〕振り分けキー情報を取得する。〔Ｓ５３〕振り分け先サーバ候補の抽出をする。〔Ｓ５４〕振り分け先サーバ候補があるか否かを判断
し、振り分け先サーバ候補があればステップＳ５６へ進
み、振り分け先サーバ候補がなければステップＳ５５へ
進む。〔Ｓ５５〕振り分け先サーバ候補がない場合には、利用
者からの要求がコネクション振り分けなら確立失敗と
し、利用者からの要求がトランザクションの振り分けな
ら一定時間保留とし、時間経過後再度ステップＳ５４へ
進む。〔Ｓ５６〕振り分け先サーバ候補があれば、振り分け先
サーバを決定する。〔Ｓ５７〕サーバ側コネクションの確立、またはトラン
ザクションの振り分け処理を行う。〔Ｓ５８〕コネクション確立が成功したか否かを判断
し、成功であればステップ６０へ進み、失敗であればス
テップＳ５９へ進む。なお、要求がトランザクション処
理であればこのステップは実行せず、ステップＳ６０に
進む。〔Ｓ５９〕コネクション確立が失敗の場合には、振り分
け候補から失敗したサーバを除外し、ステップＳ５４に
進む。〔Ｓ６０〕コネクション確立が成功の場合には、データ
通信またはトランザクション処理を実行する。

【００５６】次に、振り分けキーの取得処理について詳
しく説明する。図１７は振り分けキーの取得処理を示す
図である。振り分け処理部１１２は状態管理部１１１を
有している。状態管理部１１１では、振り分けキーごと
に振り分け先候補とこの所在を管理している。

【００５７】利用者からの要求７５は、まず振り分け処
理部１１２に入力される。振り分け処理部１１２では、
要求の中から振り分けキー７５ａを抽出する。振り分け
キー７５ａは、状態管理部１１１に送られる。状態管理
部１１１は、振り分けキー７５ａに対応する振り分け先
候補とその所在に関する情報１１２ｂを抽出し、振り分
け処理部１１２へ渡す。振り分け処理部１１２は、情報
１１２ｂに基づき要求７５の振り分け先を決定する。

【００５８】なお、上記の例では要求の一部の文字列を
振り分けキーとしているが、その文字列を端末名と組み
合わせたり、ネットワーク利用者のデータや業務の名前
など、様々なものを振り分けキーとすることができる。

【００５９】以上のように、振り分けキーは利用者から
のコネクションの確立要求やトランザクション開始時に
受け付けた要求から抽出される。抽出する情報は通信プ
ロトコルや振り分けの種類に応じて以下のように設定し
ている。

【００６０】コネクション振り分けにおいて、通信プロ
トコルがＦＮＡ（富士通ネットワークアーキテクチャ）
の場合、宛て先（業務名）、通信元ネットワーク利用者
名である。具体的には、業務の論理的な名前＋端末名
（端末グループ）、業務の論理的な名前＋端末名＋端末
の属するシステムのアドレス、業務の論理的な名前＋端
末名＋端末の属するシステムのアドレス＋ユーザデータ
内の任意のデータ等である。

【００６１】コネクション振り分けにおいて、通信プロ
トコルがＯＳＩ（Open System Interconnection ）の場
合には、宛て先のアドレスと通信元のアドレスである。
具体的には、業務のＴ−ＳＡＰアドレスと通信元のＮＳ
ＡＰアドレス（ＯＳＩにおけるネットワーク層のアドレ
ス）である。

【００６２】ＴＣＰコネクション振り分けにおいて、通
信プロトコルがＴＣＰ／ＩＰの場合には、クライアント
が確立した通信制御装置上のポート番号、送信元ネット
ワーク利用者名である。

【００６３】トランザクションの振り分けの場合には、
トランザクション処理における業務名、トランザクショ
ン開始時のメッセージの内容である。なお、振り分けキ
ーとして選択するデータを、アクセス種別（排他、共
用、照会、更新等）と対応付けることで、システム全体
のトランザクション性能やＤＢアクセスでの負荷の分散
を図ることができる。

【００６４】ところで、キーとなる情報がサーバとの間
でのコネクションの確立要求に含まれていない場合、つ
まりトランスポート層よりも上位レベルの情報をキーと
する場合には、利用者の端末側からトランスポート層の
確立要求が送られただけでは、振り分け先を特定するこ
とができない。従って、従来のように端末とサーバのト
ランスポート層での接続を完了してから上位レベルの通
信を行うという手順を踏むことができない。そこで本発
明では、この問題を以下の方法で解決する。

【００６５】図１８は上位レベルの情報をキーとする場
合のコネクション手順を示す図である。図において、ま
ずネットワーク利用者の端末からトランスポート層の確
立要求が出力される。通信制御装置は端末との間のトラ
ンスポートコネクションのみを確立し、サーバとのコネ
クションは保留にする。次いで、端末から上位レベルの
確立要求が出力される。通信制御装置は、その要求から
キーを抽出し、振り分けるべきサーバを特定する。サー
バを特定したら、そのサーバとの間でトランスポート層
のコネクションと上位レベルのコネクションとを順次確
立する。最後に、端末との間の上位レベルのコネクショ
ンを確立する。以後は、端末とサーバ間でデータ転送が
行われる。

【００６６】このように、サーバとの間のトランスポー
ト層のコネクションの確立を一時的に保留することによ
り、上位レベルのデータに含まれる詳細な情報を基に振
り分け先を選択することができ、より信頼性の高い負荷
分散を行うことができる。

【００６７】次に、振り分け先サーバ候補の抽出処理の
詳細を説明する。図１９は振り分け先サーバ候補の抽出
される情報のリンク状態を示す図である。まず、振り分
け候補グループ５１０から振り分け候補（１）５２１に
繋がっている。さらに、振り分け候補（１）５２１から
振り分け候補（２）５２２へ繋がっている。以後、同様
に最後の振り分け候補（ｎ）５２３までが順に繋がって
いる。各振り分け候補５２１〜５２３には、業務情報５
３１〜５３３、パス情報５４１〜５４３、サーバ情報５
５１〜５５３が順に繋がっている。

【００６８】振り分けサーバを決定する際には、図１９
の振り分け候補の情報から、以下の全ての条件を満たす
ものを候補として選択する。第１に、振り分け情報が抑
止状態（停止状態）でないこと。第２に、カレントセシ
ョン数が最大振り分け数を超えていないこと。第３に、
パス情報が抑止状態（停止状態）でないこと。第４に、
業務状態が抑止状態（停止状態）でないこと。第５に、
業務内のアプリケーションの状態が非活性状態でないこ
と。

【００６９】図１９では、各種振り分け情報ごとに状態
情報を有している。例えば、抑止状態、アプリケーショ
ンの動作状態等である。このような状態情報を業務等の
情報にまで持たせたのは、情報ごとに対応する資源への
振り分けを抑止できるようにするためである。例えば、
特定の業務のみ振り分けを一時的に抑止可能としたり、
サーバ単位に振り分けを抑止可能とする。

【００７０】次に、選択された振り分け候補の中から
の、振り分け先サーバの決定方法を説明する。振り分け
候補の中から、以下に論理式に従って求めた分散比率の
最も少ないものを振り分け先と決定する。

【００７１】

【数１】｛（ＴＣ_n＋１）／Ｒ_n｝×１００・・・・・（１）ここで、ＴＣ_nはｎ番目の振り分け候補のサーバでの振
り分け済セション数であり、Ｒ_nはｎ番目の振り分け候
補のサーバ分散比率である。

【００７２】なお、式（１）の値が同じ振り分け候補の
サーバが複数存在した場合には、次のように取り扱う。
コネクションの振り分けの場合には、最後に振り分けを
行ったサーバの次のサーバに決定する。トランザクショ
ン振り分けの場合には、過去の振り分け実績（振り分け
たトランザクション数）が一番少ないサーバに決定す
る。これは、一時点で振り分けるセションやトランザク
ションが候補となるサーバ数よりも少なく、かつ、セシ
ョンは何度も確立解放を繰り返すような運用を行ったと
きに、すべてのサーバへの振り分けを可能とするためで
ある。特別な振り分けとして、同一のクライアントとサ
ーバ（またはサーバ内のアプリケーション）との間で複
数のセションが確立する運用では、上記のような論理に
よらず、１つ目のセションと同じサーバへの振り分けを
行うこともできる。なお、両者の選択は通信プロトコル
の違いにより実現するか、あるいは、予め定義してお
く。これによれば、同じクライアントとサーバとの間
で、複数の業務を同時に連携して行う場合に有効とな
る。

【００７３】また、トランザクションの振り分けにおい
て、振り分け候補が１つもない場合には、振り分けを保
留することができる。具体的には、振り分け候補が１つ
もないか、または、最大振り分け数を超えたものがある
場合には、トランザクション開始要求を一定の保留時間
だけ保留する。なお、保留するトランザクション開始要
求は、保留可能な要求数の範囲内でなければならない。
また、保留時間については、トランザクション要求毎に
保留時間の変更が可能である。

【００７４】これにより、瞬間的にトランザクション要
求が大量に発生した場合のサーバへの過負荷が防止でき
るとともに、ホットスタンバイ時のシステム切り換え時
にトランザクション要求を失敗させずにすむ。

【００７５】次に第４の機能である業務の運用を切り換
えることにより、サーバ間の効率的な負荷の分散を行う
機能について説明する。この機能を実行するには、図２
に示す振り分け処理部１１２に対して各種条件の定義を
入力する。この定義では、各サーバのアプリケーション
への振り分け条件をグループ化する。このグループ化に
より、複数の振り分け条件をまとめて管理することがで
きる。

【００７６】さらに、振り分け条件グループの定義に
「振り分け状態」を持たせる。そして、振り分け処理部
１１２は、振り分け先の決定に使用する振り分け条件グ
ループを「活性状態」に、振り分け先の決定に使用しな
い振り分け条件グループを「非活性状態」にすることに
より業務の振り分けを管理する。このとき、各振り分け
条件グループは業務の運用に対応している。

【００７７】図２０は振り分け処理部１１２に入力する
振り分け定義の例を示す図である。この例では、実資源
の定義として、サーバ１０，２０，３０をそれぞれ「サ
ーバＸ」、「サーバＹ」、「サーバＺ」と名付けてお
り、各サーバ１０，２０，３０内で業務を実行するアプ
リケーション１１，２１，３１を、それぞれ「業務プロ
グラムＡ（業務Ａ）」、「業務プログラムＢ（業務
Ｂ）」、「業務プログラムＢ（業務Ｂ）」と名付けてい
る。ここで、サーバ２０とサーバ３０とは同じ業務を提
供しており、ロードシェア形態をとっている。

【００７８】振り分けの定義において、「業務Ａ」は、
「振り分け条件グループＡ１（振り分け状態＝活性）」
と「振り分け条件グループＡ２（振り分け状態＝非活
性）」とに分かれている。「振り分け条件グループＡ
１」の振り分け条件は「振り分け条件Ａ１Ｘ（最大１０
０）」であり、「振り分け条件グループＡ２」の振り分
け条件は「振り分け条件Ａ２Ｘ（最大５０）」である。
「業務Ｂ」は、「振り分け条件グループＢ１（振り分け
状態＝活性）」と「振り分け条件グループＢ２（振り分
け状態＝非活性）」とに分かれている。「振り分け条件
グループＢ１」の振り分け条件は「振り分け条件Ｂ１Ｙ
（最大１００）」、「振り分け条件Ｂ１Ｚ（最大１０
０）」である。一方、「振り分け条件グループＢ２」の
振り分け条件は「振り分け条件Ｂ２Ｙ（最大５０）」、
「振り分け条件Ｂ２Ｚ（最大５０）」である。

【００７９】ここで、振り分け条件の最後のアルファベ
ットが業務を実行するサーバを示しており、「最大」と
はそのサーバへの振り分けが許される要求の最大数を示
している。

【００８０】振り分け処理部１１２は、振り分け状態が
活性である振り分け条件グループの定義を使用して振り
分け先のサーバを決定する。運用の切り換えは、活性状
態の振り分け条件グループを非活性状態とし、新しい運
用に使用すべき振り分け条件グループを活性状態とする
ことにより行う。

【００８１】図２１は図２０に示した振り分け定義によ
る運用の切り換え状況を示す図である。なお、運用の切
り換え状況を説明する図（図２１、図２４、図２６、図
２８、図３０、図３４）では、各サーバ１０，２０，３
０とアプリケーション１１，２１，３１とには、その時
の定義で与えられている名称を表記している。従って、
与えられている定義によって、図中のサーバ等の表記も
異なる。

【００８２】「振り分け条件グループＡ１」と「振り分
け条件グループＢ１」が活性状態の場合（図中、上側）
では、利用者の端末６３，６４等からの業務Ａの要求１
４０は全てサーバ１０に対する要求１４１となり、処理
できる最大の要求数は「１００」である。業務Ｂの要求
１５０は、サーバ２０とサーバ３０とに対する要求１５
１，１５２となり、サーバ２０，３０の処理できる最大
の要求数はそれぞれ「１００」ずつである。

【００８３】ここで運用を「振り分け条件グループＡ
２」と「振り分け条件グループＢ２」とを活性状態にす
ると（図中、下側）では、業務Ａの要求１４０ａは全て
サーバ１０に対する要求１４１ａとなり、処理できる最
大の要求数は「５０」である。業務Ｂの要求１５０ａ
は、サーバ２０とサーバ３０とに対する要求１５１ａ，
１５２ａとなり、サーバ２０，３０の処理できる最大の
要求数はそれぞれ「５０」ずつである。

【００８４】ところで、上記の説明では各振り分け条件
グループの状態（活性／非活性）を個々に切り換えるこ
とにより運用を切り換えているが、各分け条件グループ
を予め運用と対応づけておくことにより、運用の切り換
え制御を簡略化することができる。

【００８５】図２２は振り分け条件グループと運用とを
対応づけた場合の定義の例を示す図である。この例の定
義は、図２０に示したものと殆ど同じであるため、相違
点のみを説明する。図２０では各振り分け条件グループ
には振り分け状態が設定されていたが、図２２の各振り
分け条件グループには運用名が設定されている。この例
では、「振り分け条件グループＡ１」は「運用α」、
「振り分け条件グループＡ２」は「運用β」、「振り分
け条件グループＢ１」は「運用α」、「振り分け条件グ
ループＢ２」は「運用β」である。そして、図２２で追
加された項目として運用の振り分け状態の設定がある。
図では、「運用α」の振り分け状態が「活性」、「運用
β」の振り分け状態が「非活性」である。

【００８６】そして、振り分け制御部１１２は、運用の
振り分け状態を変更することにより運用の切り換えを行
うことができる。従って、個々の振り分けグループを管
理する必要がなく、切り換えの制御が簡略化される。

【００８７】さらに、振り分け条件グループの定義にユ
ーザの指定を追加し、ネットワークの利用者を指定する
こともできる。その場合、振り分け条件グループのユー
ザの指定には、ネットワーク利用者の端末名、ワイルド
カード（＊）、及び任意の端末群をグループ化したユー
ザグループに定義付けられた名前等を指定することがで
きる。なお、ワイルドカードは、全ての利用者を振り分
け可能であることを意味する。また、要求の一部をキー
として指定することにより、そのキーを有する要求を対
象とすることもできる。

【００８８】図２３はユーザの指定を追加した振り分け
定義を示す図である。この例では簡単のために２つのサ
ーバ１０，２０で説明する。実資源の定義として、サー
バ１０，２０をそれぞれ「サーバＸ」、「サーバＹ」と
し、各サーバ１０，２０内で業務を実行するアプリケー
ション１１，２１を、それぞれ「業務Ａ」、「業務Ｂ」
と定義している。

【００８９】振り分けの定義において、「業務Ａ」は、
「振り分け条件グループＡ１１（運用＝運用α、ユーザ
＝端末群１）」、「振り分け条件グループＡ１２（運用
＝運用α、ユーザ＝端末群２）」、及び「振り分け条件
グループＡ２（運用＝運用β、ユーザ＝＊）」に分かれ
ている。「振り分け条件グループＡ１１」の振り分け条
件は「振り分け条件Ａ１１Ｘ（最大５０）」であり、
「振り分け条件グループＡ１２」の振り分け条件は「振
り分け条件Ａ１２Ｘ（最大５０）」であり、「振り分け
条件グループＡ２」の振り分け条件は「振り分け条件Ａ
２Ｘ（最大５０）」である。

【００９０】「業務Ｂ」は、「振り分け条件グループＢ
１１（運用＝運用α、ユーザ＝端末群１）」、「振り分
け条件グループＢ１２（運用＝運用α、ユーザ＝端末群
２）」、「振り分け条件グループＢ２１（運用＝運用
β、ユーザ＝端末群１）」、「振り分け条件グループＢ
２２（運用＝運用β、ユーザ＝端末群２）」とに分かれ
ている。「振り分け条件グループＢ１１」の振り分け条
件は「振り分け条件Ｂ１１Ｙ（最大５０）」、「振り分
け条件グループＢ１２」の振り分け条件は「振り分け条
件Ｂ１２Ｙ（最大５０）」、「振り分け条件グループＢ
２１」の振り分け条件は「振り分け条件Ｂ２１Ｙ（最大
２５）」、「振り分け条件グループＢ２２」の振り分け
条件は「振り分け条件Ｂ２２Ｙ（最大２５）」である。

【００９１】図では、運用αの振り分け状態が活性であ
り、運用βの振り分け状態が非活性である。このような
定義が設定された状態で、振り分け処理部１１２は、利
用者からの要求に付加されるユーザ情報や要求内容と活
性状態の振り分け条件とを対比することにより、振り分
け先を決定する。そして、運用の振り分け状態を変更す
ることにより、運用を切り換えることができる。

【００９２】図２４はユーザの指定を追加した振り分け
定義による運用の切り換え状況を示す図である。ここ
で、端末６３，６４は第１の端末群１８１に含まれ、端
末６５，６６は第２の端末群１８２に含まれている。

【００９３】［運用α］の状態では、第１の端末群１８
１から業務Ａへの要求１６０は全てサーバ１０への要求
１６２となリ、最大の要求数は「５０」である。第１の
端末群１８１から業務Ｂへの要求１７０は全てサーバ２
０への要求１７２となリ、最大の要求数は「５０」であ
る。第２の端末群１８２から業務Ａへの要求１６１は全
てサーバ１０への要求１６３となリ、最大の要求数は
「５０」である。第２の端末群１８２から業務Ｂへの要
求１７１は全てサーバ２０への要求１７３となリ、最大
の要求数は「５０」である。

【００９４】ここで、運用が切り換えられ［運用β］に
なると、第１の端末群１８１から業務Ａへの要求１６０
ａと第２の端末群１８２から業務Ａへの要求１６１ａと
は、全てサーバ１０への要求１６４となる。そして、要
求１６４の最大の要求数は、双方の端末群からの総要求
数で換算して「５０」である。一方、第１の端末群１８
１から業務Ｂへの要求１７０ａは全てサーバ２０への要
求１７２ａとなり、最大の要求数は「２５」である。第
２の端末群１８２から業務Ｂへの要求１７１ａは全てサ
ーバ２０への要求１７３ａとなり、最大の要求数は「２
５」である。

【００９５】この図に示すようにユーザを指定した運用
の切り換えを行うことにより、利用者の利用頻度の地域
格差を考慮した運用の切り換えが可能となる。次に、第
５の機能である、第１の機能で管理している各サーバの
負荷状態に応じて、動的に振り分け条件を切り換える機
能について説明する。運用操作部１１３は、状態管理部
１１１が管理している各サーバの負荷状態等に応じて運
用の切り換えを行うこともできる。この場合、アプリケ
ーションの定義に「振り分け状態」の設定項目を設け
る。この「振り分け状態」は、対応するアプリケーショ
ンの振り分けが可能な場合には「活性」とし、振り分け
が不可能な場合には「非活性」とする。

【００９６】図２５はアプリケーションの状態の定義を
追加した振り分け定義を示す図である。この図では、実
資源の定義として、サーバ１０，２０，３０をそれぞれ
「サーバＸ」、「サーバＹ」、「サーバＺ」とし、各サ
ーバ１０，２０，３０内で業務を実行するアプリケーシ
ョン１１，２１，３１を、それぞれ「業務プログラムＡ
（業務Ａ）」、「業務プログラムＢ（業務Ｂ）」、「業
務プログラムＢ（業務Ｂ）」と定義している。さらに、
各アプリケーション１１，２１，３１には振り分け状態
が設定されており、図中では全て「活性」である。な
お、振り分けの定義は、図２２に示した例と同じであ
る。

【００９７】ロードシェア形態の業務で特定のサーバの
アプリケーションにトラブルが発生した場合、トラブル
が発生したサーバ内に配置された状態管理エージェント
から状態管理部１１１へアプリケーションに障害が発生
した旨が通知される。状態管理部１１１は、障害の発生
したアプリケーションの状態を「非活性」とする。

【００９８】図２６はロードシェア形態でのトラブル対
処の例を示す図である。図中のトラブル発生前の状態
（図中、上側）は、図２１の［運用α］の状態と同じで
ある。ただし、この図では、各サーバ１０，２０，３０
内に状態管理エージェント１３，２３，３３を図示して
いる。ここで、例えば、サーバ２０に障害が発生した場
合には、サーバ２０内の状態管理エージェント２３が、
通信制御装置１００内の状態管理部１１１にアプリケー
ション２１が使用できないことを通知する。状態管理部
１１１は、アプリケーション２１の状態を「非活性」と
する。これにより、利用者から業務Ｂへの要求がアプリ
ケーション２１へ振り分けられることはなくなる。

【００９９】トラブル発生後の状態（図中、下側）で
は、利用者から業務Ｂへの要求１５０は、全てサーバ３
０に対する要求１５２ａとなる。ここで、サーバ２０の
アプリケーション２１が復旧した場合には、サーバ２０
内の状態管理エージェント２３がアプリケーション２１
が復旧した旨を状態管理部１１１に通知する。状態管理
部１１１は、その通知を受けてアプリケーション２１の
振り分け状態を活性とする。これにより、アプリケーシ
ョン２１に対する要求の振り分けが再開される。

【０１００】このように、定義内に各アプリケーション
の振り分け状態を設定しておき、振り分け処理部１１２
は「活性」状態のアプリケーションの中から振り分け先
を選択することにより、アプリケーションのメンテナン
ス時にも利用者に対する業務の提供を停止させずにす
む。

【０１０１】次に、システム運用におけるサーバ障害発
生時の運用について説明する。この場合、サーバの定義
に「振り分け状態」を持たせ、振り分け可能な場合に
「活性状態」、振り分け不可能な場合に「非活性状態」
として管理する。

【０１０２】図２７はホットスタンバイ切り換えを実現
するための振り分け定義を示す図である。この例では、
１つのデータベースを共有しているサーバ２０，３０の
うち、サーバ２０を現用、サーバ３０を待機として運用
している。実資源の定義として、サーバ２０，３０をそ
れぞれ「サーバＸ」、「サーバＹ」とし、各サーバ２
０，３０内で業務を実行するアプリケーション２１，３
１をともに「業務Ａ」と定義している。

【０１０３】振り分けの定義において、「業務Ａ」は、
「振り分け条件グループＡ１（運用名＝運用α）」と
「振り分け条件グループＡ２（運用名＝運用β）」とに
分かれている。「振り分け条件グループＡ１」の振り分
け条件は「振り分け条件Ａ１Ｘ（最大１００）」と「振
り分け条件Ａ１Ｙ（最大１００）」とであり、「振り分
け条件グループＡ２」の振り分け条件は「振り分け条件
Ａ２Ｘ（最大５０）」と「振り分け条件Ａ２Ｙ（最大５
０）」とである。

【０１０４】現在、「運用α」が活性状態であり、「運
用β」が非活性状態である。図２８はホットスタンバイ
切り換えの状況を示す図である。２つのサーバ２０，３
０が共に正常に動作している状態（図中、上側）では、
端末６３，６４やシステム５１からの業務Ａの要求１４
２は、現用であるサーバ２０への要求１４３として振り
分けられている。この時、双方のサーバ２０，３０内の
状態管理エージェント２３，３３は、定期的に通信を行
う事により、互いに監視し合っている。従って、一方の
サーバがダウンすると、他方のサーバ内の状態管理エー
ジェントがそのことを検出する仕組みになっている。

【０１０５】この状態において、現用のサーバ２０にト
ラブルが発生すると、サーバ２０からの通信が滞ったこ
とをサーバ３０内の状態管理エージェント３３が検出
し、サーバ２０がダウンしたことを認識する。すると、
状態管理エージェント３３は通信制御装置１００の振り
分けプログラム１１０（その中の状態管理部１１１）と
の間の通信パスを利用して、サーバ２０がダウンした旨
を通信制御装置に通知する。通信制御装置１００の状態
管理部１１１がその通知を受け取ると、それに応じて、
運用操作部１１３がサーバ２０の振り分け状態を非活性
状態に変更する。続いて、サーバ３０の振り分け状態を
活性状態に変更する。これにより、待機サーバであった
サーバ３０が新たに現用サーバとなる。従って、振り分
け状態変更後（図中、下側）では、利用者の端末６３，
６４等から出力された要求が、全てサーバ３０への要求
１４４となる。

【０１０６】この方式を使用して、各サーバの振り分け
状態を順次操作することで、業務を停止せずにホットス
タンバイ運用のメンテナンスを行うことができる。次
に、業務の振り分け先の決定を、様々な要素を考慮して
行うこともできる。その決定のファクターとしては、例
えば、サーバ間の相対振り分け比率、アプリケーション
に対する最大振り分け数を指定する。

【０１０７】サーバ間の相対振り分け比率とは、ロード
シェア形態の各サーバ上のアプリケーション間の相対的
な振り分け比率である。アプリケーションに対する最大
振り分け数とは、アプリケーションがそのサーバで同時
に処理可能な要求数である。

【０１０８】ところで、振り分け処理部１１２は、利用
者からの要求が全アプリケーションの最大振り分け数の
合計を超えた場合に、いずれかのサーバのアプリケーシ
ョンが振り分け可能になるまで、待ち合わせ（保留）を
行う機能を有している。この際、要求を無制限に待ち合
わせると、通信制御装置が資源枯渇したり、ネットワー
ク利用者の端末がハングする事態が生じる。

【０１０９】そこで、振り分け条件グループに、業務の
最大処理数を超えた場合の処理を決定するためのファク
ターとして「要求の最大保留数」と「要求の最大保留時
間」を指定する。この指定により、待ち合わせの上限が
設定される。従って、待ち合わせが「要求の最大保留
数」と「要求の最大保留時間」とのいずれかを超えた場
合には、振り分け処理部１１２から利用者に対して処理
不能の旨の応答を返し、利用者からの要求を失敗させ
る。

【０１１０】上記の２つの指定（「要求の最大保留
数」，「要求の最大保留時間」）は、利用者からの要求
を受信した際に振り分け先を決定するために使用する情
報であり、運用中に変更操作を行っても利用者に悪影響
を及ぼさない。振り分け処理部１１２は、これらの２つ
の指定を動的に変更することにより、振り分け配分を最
適に保つことができる。

【０１１１】図２９は振り分け配分の動的な変更を行う
ための定義の例を示す図である。この例では、実資源の
定義として、サーバ２０，３０をそれぞれ「サーバ
Ｘ」、「サーバＹ」とし、各サーバ２０，３０内で業務
を実行するアプリケーション２１，３１を、共に「業務
Ａ」と定義している。この２つのサーバ２０，３０はロ
ードシェア形態をとっている。

【０１１２】振り分けの定義において、業務Ａには振り
分け条件グループＡ１（最大保留数＝５，最大保留時間
６０）が定義されている。振り分け条件グループＡ１に
は、２つの振り分け条件として、振り分け条件Ａ１Ｘ
（振り分け比率＝３，最大振り分け数＝１００）と振り
分け条件Ａ１Ｙ（振り分け比率＝３，最大振り分け数＝
１００）が設定されている。

【０１１３】さらに、変更内容が設定されており、その
内容は、振り分け条件Ａ１Ｙに対して、振り分け比率を
「３」→「１」、最大振り分け数を「１００」→「５
０」とするものである。

【０１１４】図３０は振り分け配分の動的な変更状況を
示す図である。通常動作時（図中、上側）は、利用者か
らの要求が、アプリケーション２１への要求１９０とア
プリケーション３１への要求１９１とに均等に割り振ら
れている。ここで、サーバ３０に臨時業務３５が発生す
ると（図中、下側）、アプリケーション３１への振り分
け比率が「１」になる。従って、アプリケーション２１
への要求１９０ａはアプリケーション３１への要求１９
１ａの３倍となる。

【０１１５】以上の説明が、図２に示したマルチサーバ
システムで行うことができる各種処理機能である。ここ
で、通信制御装置１００内の振り分けプログラム１１０
とサーバ内の状態管理エージェントの内部構成について
説明する。

【０１１６】図３１は振り分けプログラムと状態管理エ
ージェントの内部構成を示すブロック図である。サーバ
３０の状態管理エージェント３３は、他サーバ監視部３
３ａ、アプリケーション監視部３３ｂ、コマンド機能部
３３ｃ、及び通信制御機能部３３ｄを有している。他サ
ーバ監視部３３ａは、サーバ１０，２０内の他サーバ監
視部と通信を行っており、互いに正常に動作しているこ
とを確認し合っている。アプリケーション監視部３３ｂ
は、サーバ３０内の複数のアプリケーション３１，３１
ａの動作状況を監視している。コマンド制御部３３ｃ
は、操作端末３０ａからのコマンド入力に応じて、各種
命令を出力する。通信制御機能部３３ｄは、ＬＡＮ４１
を介した通信を制御する。

【０１１７】振り分けプログラム１１０は、図２に示し
た状態管理部１１１、振り分け処理部１１２、運用操作
部１１３に加え、通信制御部１１４とコマンド機能部１
１５とを有している。通信制御部１１４は、ＬＡＮ４１
を介した通信を制御する。コマンド機能部１１５は、操
作端末１０５からのコマンド入力に応じて、サーバに対
する状態要求等を出力する。また、操作端末１０５から
の入力により、運用切り換え命令を運用操作部１１３に
出力する。運用操作部１１３は運用切り換え命令に従っ
て、運用の切り換えを行う。

【０１１８】以上の説明が、１台の通信制御装置により
ロードシェアシステムを構成した場合である。以下に、
２台の通信制御装置によりロードシェアシステムを構成
した場合を説明する。まず、２台の通信制御装置で１シ
ステムビューを実現する場合を以下に示す。

【０１１９】図３２は２台の通信制御装置を有するマル
チサーバシステムを示す図である。このシステムには、
ロードシェア運用を行っている３台のサーバ２１０，２
２０，２３０と２台の通信制御装置２４０，２５０がＬ
ＡＮ２０２を介して接続されている。通信制御装置２４
０，２５０は、通信媒体２０３を介して他のシステム２
６０，２７０と接続されている。

【０１２０】サーバ２１０，２２０，２３０は、同じ業
務を行うアプリケーション２１１，２２１，２３１を有
しており、このアプリケーション２１１，２２１，２３
１によって１つのデータベース（ＤＢ）２０１を共有し
ている。また、各サーバ２１０，２２０，２３０は、そ
れぞれ異なるアドレスを有している。通信制御装置２４
０，２５０は、それぞれ振り分けプログラム２４１，２
５１を有している。また、通信制御装置２４０，２５０
は同じ通信アドレスを有している。サーバからサービス
を受けるシステム２６０，２７０は、それぞれアプリケ
ーション２６１，２７１を有している。

【０１２１】このような構成により、システム２６０内
で動作するアプリケーション２６１が、サーバ２１０，
２２０，２３０内のアプリケーション２１１，２２１，
２３１と振り分け機能を利用して通信する。

【０１２２】このような運用では、アプリケーション２
６１と通信制御装置との間に確立するコネクションは、
通信アドレスＮと通信アドレス（４）との通信アドレス
ペアのコネクション上に、複数の上位レベルのコネクシ
ョンを確立することができる。そのため、個々のコネク
ションを識別するための識別子が必要となる。

【０１２３】ここで、２台の通信制御装置２４０，２５
０がそれぞれ上位レベルのコネクションに「１０」を割
り振ったとする。すると、ネットワークの利用者である
通信相手のシステム２６０では、コネクションの確認が
できなくなる。

【０１２４】この問題を回避するために、通信制御装置
２４０，２５０のそれぞれが管理する上位の通信資源の
範囲を、定義等によって重複しないようにする。通信資
源を分割する方法としては、以下の３パターンが考えら
れる。

【０１２５】第１の方法は定義を用いる方法である。こ
れは、通信制御装置２４０，２５０での管理範囲をそれ
ぞれの通信制御単位に事前に定義することで分割管理を
実現する方法である。

【０１２６】例えば、トランスポート層のレファレンス
値は、通信時のＮＳＡＰアドレス単位に１〜６５５３５
までの値であるため、これを４分割して、その２つをそ
れぞれ通信制御装置２４０，２５０に定義する。残りの
２つのブロックは、将来の通信制御装置の増設用に未割
当とする。

【０１２７】第２の方法は管理プログラムによる方法で
ある。この方法では、上位レベルの資源の分割範囲を管
理するプログラムと、各通信制御装置内の通信制御プロ
グラムとで、動的に分割範囲を獲得または配分する。

【０１２８】図３３は管理プログラムによる通信資源の
分割の状況を示す図である。通信制御装置２４０は、資
源の分配管理プログラム２４２と通信制御・振り分けプ
ログラム２４３とを有している。通信制御装置２５０
は、通信制御・振り分けプログラム２５２を有してい
る。

【０１２９】各通信制御装置２４０，２５０内の通信制
御・振り分けプログラム２４３，２５２は、システム起
動時や上位レベルのコネクション確立時に振り分け処理
部から資源の分割範囲を入手する。図の例では、通信制
御・振り分けプログラム２４３には１〜１００が割り当
てられ、通信制御・振り分けプログラム２５２には５０
１〜６００が割り当てられている。

【０１３０】第３の方法はコネクション確立時に分配す
る方法である。この方法では、上位レベル（トランスポ
ート層）のコネクションの確立時に上位資源を管理する
プログラム（図３３における分配管理プログラム２４２
に該当する）から資源を獲得する。

【０１３１】以上のいずれかの方法で、分配管理を実現
することができる。また、通信制御装置を２台設けた場
合には、サーバの内の状態管理エージェントから各通信
制御装置へ状態の変化を通知する。図３４は通信制御装
置が２台ある場合のサーバからの通知による運用切り換
え状況を示す図である。図において、２台のサーバ３１
０，３２０と２台の通信制御装置３０１，３０２とは、
ＬＡＮを介して接続されている。通信制御装置３０１，
３０２には、それぞれ個別の通信媒体３４３，３４４を
介して、端末３６１〜３６４や他のシステム３５１，３
５２が接続されている。

【０１３２】サーバ３１０，３２０内には、アプリケー
ション（業務プログラムＡ）３１１，アプリケーション
（業務プログラムＢ）３２１と状態管理エージェント３
１２，３２２が設けられている。通信制御装置３０１，
３０２内には、振り分けプログラム３０１ａ，３０２ａ
が設けられている。

【０１３３】切り換え前の状態（図中、上側）では、通
信媒体３４３を介して送られてきた業務Ａ要求はサーバ
３１０へ、業務Ｂの要求はサーバ３２０へ送られる。そ
れらの最大は、共に１００である。同様に、通信媒体３
４４を介して送られてきた業務Ａ要求はサーバ３１０
へ、業務Ｂの要求はサーバ３２０へ送られる。それらの
最大は、共に１００である。

【０１３４】ここで、状態管理エージェント３１２から
業務プログラムＡの利用率低下などの情報が、各通信制
御装置３０１，３０２へ送られると、サーバ３１０へ送
られる要求の最大数が抑制される。図では（図中、下
側）、各通信制御装置３０１，３０２からの最大要求数
が５０に制限されている。

【０１３５】

【発明の効果】以上説明したように本発明では、利用者
端末から送られた要求を、通信制御装置がいずれかのサ
ーバへ振り分けるようにしたため、利用者側がサーバの
通信アドレスなどを認識している必要がなく、利用者に
とっては１台のサーバが全ての機能を提供できるように
認識でき（１システムビュー）利用者の負担が軽減する
とともに、各サーバ間の業務の負荷分散の制御が一括管
理できるようになる。

【０１３６】また、各サーバに配置した状態管理代理手
段が通信制御装置の状態管理手段へ、各サーバの状態を
通知するようにしたため、各サーバの動作状況が状態管
理手段で一括管理でき、サーバの動作状態をタイムリに
把握することができるとともに、各サーバの通信プロト
コルに依存せずに状態を管理することが可能となる。

【０１３７】さらに、各サーバ内へ要求を振り分けるた
めの条件を活性化・非活性化させることにより運用の切
り換えができるようにしたため、サーバ間の負荷の分散
を考慮した運用の切り換えが容易となる。

【０１３８】また、サーバの１つに障害が発生した場合
には、他のサーバが障害を検出し通信制御装置にその旨
を通知するようにしたため、サーバの障害を隠蔽するこ
とができる。従って、ユーザへのサービスを停止させず
にサーバの追加、削除が可能となり、システムのスケー
ラビリティに対応可能となる。

【図面の簡単な説明】

【図１】本発明の原理構成図である。

【図２】本発明のロードシェアシステムの概略構成を示
すブロック図である。

【図３】１システムビューの機能を示すブロック図であ
る。

【図４】利用者が認識しているネットワーク網のイメー
ジを示す図である。

【図５】通信制御装置内での通信アドレスのリンク状態
を示す図である。

【図６】通信アドレスの変換方式を示す図である。

【図７】通信制御装置での一括管理機能の概略構成を示
すブロック図である。

【図８】状態管理を行う際の処理手順を示すフローチャ
ートである。これは、状態管理部が実行する処理であ
る。

【図９】管理簿内の一例を示す図である。

【図１０】状態管理処理の概念図である。

【図１１】通信制御装置の状態要求の際のフローチャー
トである。

【図１２】状態通知を受け取った通信制御装置の処理手
順を示すフローチャートである。

【図１３】通信制御装置からの要求により状態通知を出
力する際の状態管理エージェントの処理手順を示すフロ
ーチャートである。

【図１４】資源の状態の変化により状態通知を出力する
際の状態管理エージェントの処理手順を示すフローチャ
ートである。

【図１５】一括管理された管理情報に基づき利用者から
の要求を振り分ける処理の概念図である。

【図１６】振り分け処理のフローチャートである。

【図１７】振り分けキーの取得処理を示す図である。

【図１８】上位レベルの情報をキーとする場合のコネク
ション手順を示す図である。

【図１９】振り分け先サーバ候補の抽出される情報のリ
ンク状態を示す図である。

【図２０】振り分け処理部に入力する振り分け定義の例
を示す図である。

【図２１】図２０に示した振り分け定義による運用の切
り換え状況を示す図である。

【図２２】振り分け条件グループと運用とを対応づけた
場合の定義の例を示す図である。

【図２３】ユーザの指定を追加した振り分け定義を示す
図である。

【図２４】ユーザの指定を追加した振り分け定義による
運用の切り換え状況を示す図である。

【図２５】アプリケーションの状態の定義を追加した振
り分け定義を示す図である。

【図２６】ロードシェア形態でのトラブル対処の例を示
す図である。

【図２７】ホットスタンバイ切り換えを実現するための
振り分け定義を示す図である。

【図２８】ホットスタンバイ切り換えの状況を示す図で
ある。

【図２９】振り分け配分の動的な変更を行うための定義
の例を示す図である。

【図３０】振り分け配分の動的な変更状況を示す図であ
る。

【図３１】振り分けプログラムと状態管理エージェント
の内部構成を示すブロック図である。

【図３２】２台の通信制御装置を有するマルチサーバシ
ステムを示す図である。

【図３３】管理プログラムによる通信資源の分割の状況
を示す図である。

【図３４】通信制御装置が２台ある場合のサーバからの
通知による運用切り換え状況をしめす図である。

【符号の説明】

１ａ，１ｂデータベース２，３，４サーバ２ａ，３ａ，４ａ業務提供手段２ｂ，３ｂ，４ｂ状態管理代理手段５通信媒体６通信制御装置６ａ状態管理手段６ｂ振り分け手段６ｃ運用操作手段７通信網８ａ，８ｂ，８ｃ利用者側装置１０，２０，３０サーバ４１ＬＡＮ４２，４３データベース４４，４５通信媒体５１，５２システム６１〜６４端末１００通信制御装置１１０振り分けプログラム１１１状態管理部１１２振り分け処理部１１３運用操作部

───────────────────────────────────────────────────── フロントページの続き (72)発明者庄司和彦神奈川県川崎市中原区上小田中1015番地富士通株式会社内 (72)発明者小西豊兵庫県神戸市中央区加納町２丁目１番15号株式会社神戸エンジニアリング内 (72)発明者高橋明神奈川県川崎市中原区上小田中1015番地富士通株式会社内 (72)発明者木村雅充神奈川県川崎市中原区上小田中1015番地富士通株式会社内 (72)発明者草川充兵庫県神戸市中央区加納町２丁目１番15号株式会社神戸エンジニアリング内 (72)発明者坂井隆人兵庫県神戸市中央区加納町２丁目１番15号株式会社神戸エンジニアリング内

Claims

【特許請求の範囲】

【請求項１】複数のプロセッサで機能を分散させるロ
ードシェアシステムにおいて、通信媒体を介して送られた処理要求を処理する複数のサ
ーバと、利用者側装置が接続された通信網と前記通信媒体とに接
続されており、前記利用者側装置から出力された要求を
前記通信網を介して受信し、前記要求を前記サーバのい
ずれかに対する前記処理要求として前記通信媒体を介し
て送信する通信制御装置と、を有することを特徴とするロードシェアシステム。
【請求項２】前記通信制御装置は、前記要求の送信先
アドレスを、自己のアドレスから前記サーバのいずれか
のアドレスへ変換することにより、前記処理要求を生成
することを特徴とする請求項１記載のロードシェアシス
テム。
【請求項３】前記通信制御装置は、同一の通信アドレ
スを有するものが複数台設けられていることを特徴とす
る請求項１記載のロードシェアシステム。
【請求項４】前記通信制御装置は、前記サーバに前記
要求を振り分けるための条件の活性化又は非活性化の状
態切り換えを行う運用操作手段と、活性状態にある前記
条件に従って前記要求の振り分け先を決定し、前記要求
を前記処理要求として前記通信媒体を介して送信する振
り分け手段とから構成されている、ことを特徴とする請求項１記載のロードシェアシステ
ム。
【請求項５】前記運用操作手段は、任意の運用と複数
の前記条件とを対応付け、前記運用の活性化又は非活性
化の切り換えによって、複数の前記条件の状態切り換え
を一括して行うことを特徴とする請求項４記載のロード
シェアシステム。
【請求項６】複数のプロセッサで機能を分散させるロ
ードシェアシステムにおいて、通信媒体を介して送られた処理要求を実行する業務提供
手段と、自己の動作状態を管理する状態管理代理手段と
を有する複数のサーバと、前記状態管理代理手段との間で前記通信媒体を介した通
信パスを確立し、前記通信パスを用いて前記サーバの状
態を示す管理情報を前記状態管理代理手段から受け取
り、前記サーバの状態を一括管理する状態管理手段を有
する通信制御装置と、を有することを特徴とするロードシェアシステム。
【請求項７】前記業務提供手段は、互いに共用のデー
タベースを管理していることを特徴とする請求項６記載
のロードシェアシステム。
【請求項８】前記通信制御装置は、通信網を介して接
続されている利用者側装置からの要求を受信し、前記状
態管理手段が管理している情報に基づき前記要求の振り
分け先を決定し、前記要求を前記サーバに対する前記処
理要求として前記通信媒体を介して送信する振り分け手
段をさらに有することを特徴とする請求項６記載のロー
ドシェアシステム。
【請求項９】前記状態管理代理手段は、前記状態管理
手段から状態監視要求を受けた際に、前記業務提供手段
の情報を前記状態管理手段へ通知することを特徴とする
請求項６記載のロードシェアシステム。
【請求項１０】前記状態管理代理手段は、前記業務提
供手段の状態が変化した場合に、前記業務提供手段の情
報を前記状態管理手段へ通知することを特徴とする請求
項６記載のロードシェアシステム。
【請求項１１】前記振り分け手段は、前記要求の送信
先アドレスを、自己のアドレスから前記サーバのいずれ
かのアドレスへ変換することにより、前記処理要求を生
成することを特徴とする請求項８記載のロードシェアシ
ステム。
【請求項１２】前記振り分け手段は、前記サーバ内の
前記業務提供手段を所定のキーに対応づけて管理してお
り、前記要求を受信すると、前記要求の内容から振り分
けキーを特定し、前記振り分けキーに対応する前記業務
提供手段を前記要求の振り分け先候補として選択する、
ことを特徴とする請求項８記載のロードシェアシステ
ム。
【請求項１３】前記振り分け手段は、前記状態管理手
段から各前記サーバの負荷状況を取得し、前記負荷状況
に応じて前記要求の振り分け先を決定する、ことを特徴
とする請求項８記載のロードシェアシステム。
【請求項１４】前記通信制御装置は、前記業務提供手
段に前記要求を振り分けるための複数の条件の活性化又
は非活性化の状態切り換えを行う運用操作手段をさらに
有し、前記振り分け手段は、活性状態にある前記条件に従って
前記要求の振り分け先を決定し、前記要求を前記処理要
求として前記通信媒体を介して送信する、ことを特徴とする請求項８記載のロードシェアシステ
ム。
【請求項１５】前記運用操作手段は、任意の運用と複
数の前記条件とを対応付け、前記運用の活性化又は非活
性化の切り換えによって、複数の前記条件の状態切り換
えを一括して行うことを特徴とする請求項１４記載のロ
ードシェアシステム。
【請求項１６】前記振り分け手段は、前記条件として
利用者分類情報が指定された前記業務提供手段に対して
は、前記利用者分類情報に合致する利用者からの前記要
求のみを振り分けることを特徴とする請求項１４記載の
ロードシェアシステム。
【請求項１７】前記運用操作手段は、前記状態管理手
段が前記状態管理代理手段から受け取った情報に応じ
て、前記条件の切り換えを行うことを特徴とする請求項
１４記載のロードシェアシステム。
【請求項１８】前記状態管理代理手段は、動作してい
ることを互いに確認し合っており、他の前記サーバが停
止したことを検出するとその旨を前記状態管理手段に通
知することを特徴とする請求項６記載のロードシェアシ
ステム。
【請求項１９】前記状態管理手段は、前記サーバを現
用サーバと待機サーバとに分けて管理しており、前記現
用サーバが停止した旨の通知を受け取ると前記現用サー
バの振り分け状態を非活性化し、前記待機サーバの振り
分け状態を活性化することを特徴とする請求項１８記載
のロードシェアシステム。