JP3784137B2

JP3784137B2 - Load balancing system

Info

Publication number: JP3784137B2
Application number: JP14632897A
Authority: JP
Inventors: 英樹山中
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 1997-06-04
Filing date: 1997-06-04
Publication date: 2006-06-07
Anticipated expiration: 2017-06-04
Also published as: JPH10334061A

Description

【０００１】
【発明の属する技術分野】
本発明は、イントラネット等のネットワーク上の通信負荷を自律的に分散することができる負荷分散システムに関する。
【０００２】
【従来の技術】
現在のＷＷＷでの通信の負荷分散は、各時点でのサーバの負荷ではなく、予めサーバ管理者が各サーバの負荷が最適になるように設定した各サーバの重みに基づいて、クライアント側がトランザクション、あるいは時間を単位に一方的に負荷を分散させることで成り立っている。
【０００３】
【発明が解決しようとする課題】
上記した確率的な方法では、サーバに掛かる負荷を前もって予測しなければならないだけでなく、長い時間間隔の平均として負荷を均衡させることが可能であるが、短い時間間隔では負荷の片寄りが起こってしまう。
計算機は、各時点での負荷が分散していなければ、コンテキスト・スイッチ、ページングなどを頻発し、この部分でオーバヘッドを発生させてしまい、トランザクションを効率よく実行できなくなってしまう。
また、サーバが何らかの故障でダウンしてしまうと、管理者が想定した負荷分散が行われず、負荷がサーバ間で偏在するだけでなく、ときには特定のサーバへの負荷が集中してサービス全体のレスポンスを著しく低下させてしまう。
【０００４】
一方、場合によっては、全てのクライアントを平等に扱うのではなく、優先しなければならないクライアントが存在する。このような場合、現在のＷＷＷ環境では、優先するクライアントのための専用サーバを用意しなければならない。
しかし、ＷＷＷのアクセスは一日を通して一定ではなく、混んでいる時間帯と空いている時間帯があるのが通常であり、混んでいる時間帯に特定のクライアントを優先できれば充分なのに、専用サーバを用意しなければならず、計算機を有効に利用できない。
【０００５】
さらに、現在のＷＷＷの環境の負荷分散の手法では、管理者が負荷の状況に応じて負荷分散のために新たなサーバ、故障から復旧したサーバを追加しても、直ぐにはクライアント全体に反映、通知する手段がないので、負荷分散が効果を表すまでに数十分から数時間のディレーが生じてしまう。
本発明は上記した事情に鑑みなされたものであって、その目的とするところは、マルチキャスト通信を使用して計算機間で負荷、優先、構成情報をリアルタイムで交換することにより、各サーバの負荷を均等に分散させることができる負荷分散システムを提供することである。
【０００６】
【課題を解決するための手段】
サーバからクライアントへの１対１通信を行った場合、クライアントの数に比例した莫大な通信量が必要であるが、１対ｎのマルチキャスト通信では、一定の数の通信量しか必要でない。
これを、インターネット（Internet) のように非常に大きなネットワークで実行すると、ほとんど使われない情報をネットワーク全体に通信することになってしまい、ネットワークのバンド幅を浪費することになる。しかしイントラネット(Intranet)などでは、社内で広く使われるサーバが集約化され集中管理されているので、上記マルチキャスト通信を用いても無駄な通信が少なくなる。
本発明は上記点に着目し、マルチキャスト通信手段を利用して、サーバの負荷状況をクライアントに伝達し、ネットワーク上のサーバの負荷を最適化する。
なお、本発明は、インターネット全体に適用するのは困難であるが、イントラネット、エクストラネット、インターネットの一部ではサーバ管理者の負担を軽減するともに、効率的な自律負荷分散が可能となる。
【０００７】
図１は本発明の原理構成図である。
本発明においては、同図に示すように、上記複数のクライアントの要求をサーバ側に転送する、上記クライアントのそれぞれに対応して設けられた複数のクライアント側負荷分散サーバ１ｂと、上記複数のサーバのそれぞれに一つずつ対応し、クライアント側からのリクエストをサーバに転送する複数のサーバ側負荷分散サーバ２ｂを設けて、上記クライアント側負荷分散サーバ１ｂおよび上記サーバ側負荷分散サーバ２ｂをマルチキャスト通信手段３で接続し、マルチキャスト通信手段３を用いて、上記クライアント側負荷分散サーバ１ｂおよび上記複数のサーバ側負荷分散サーバ２ｂの間で上記複数のサーバの負荷、優先度、データ構成情報をリアルタイムで交換する。
上記クライアント側負荷分散サーバ１ｂは、上記クライアント側負荷分散サーバ１ｂおよび上記複数のサーバ側負荷分散サーバ２ｂの間で交換される情報を用いて上記複数のサーバでの負荷が均等になるようクライアントからのリクエストを分散させて上記複数のサーバ側負荷分散サーバ２ｂの何れかに転送する。
【０００８】
本発明の請求項１〜３の発明においては、上記のようにマルチキャスト通信手段３を用いて、サーバの負荷・優先・構成情報を定期的あるいは適宜クライアントにフィードバックしており、クライアントは各時点で正確なサーバの負荷の状況やサーバの故障、新たなサーバの追加、故障したサーバの復旧等を知ることができるので、クライアントが短い時間間隔で各サーバに均等に負荷を分散させることができる。
さらに、サーバのサービス内容を含めた構成情報をクライアントに通知しているので、サーバのサービス内容を動的に変更することができる。
【０００９】
またさらに、サーバの故障、新たなサーバの追加、故障したサーバの復旧等を知ることができるので、故障したサーバは自動的にサービスから除かれ、また、新たに追加されたサーバ、故障から復旧したサーバは自動的にサービスに加えられる。
本発明のシステムは、既存のクライアント／サーバシステムに変更を加えずに、性能を自動的に最適化し、管理者の運用負担を低減化することができる。しかも、管理者が前もって綿密に負荷分散を計画し、常時負荷変動を監視する必要もない。
【００１０】
【発明の実施の形態】
図２は本発明の実施例のシステムの全体構成を示す図である。
同図において、１３、１４はＷＷＷ負荷分散サーバ（以下、負荷分散サーバという）であり、負荷分散サーバ１４、１３はそれぞれＨＴＴＰ（Hyper Text Transfer Protocol）ＷＷＷサーバ１５（以下、ＷＷＷサーバという）およびＨＴＴＰＰｒｏｘｙサーバ１２（以下、Ｐｒｏｘｙサーバという）のフロントエンド、バックエンドとして動作する。
負荷分散サーバ１３、１４はマルチキャスト、ネットワーク１６に接続されており、負荷分散サーバが起動されると、マルチキャスト通信により他の既に動作しているサーバの構成、負荷、優先情報を獲得し、これらの間に多重化された通信を可能とするコネクションを張る。
【００１１】
Ｐｒｏｘｙサーバ１２はＨＴＴＰクライアント１１からリクエストを受けると、リクエストを最も近くにある負荷分散サーバ１３へ転送する。負荷分散サーバ１３は、上記リクエストをＷＷＷサーバ１５の近くにある負荷分散サーバ１４へ多重化されたコネクションを使って中継する。
なお、複数のＷＷＷサーバにより負荷分散を行うときは、各ＷＷＷサーバに一つずつ負荷分散サーバ１４を割り当てておく（一対のＷＷＷサーバと負荷分散サーバを同じ計算機上で動作させてもよい）。
【００１２】
また、その際、負荷分散サーバ１３は複数のＷＷＷサーバ１５の負荷、優先度に基づき、所定のアルゴリズムによりリクエストを転送する負荷分散サーバを決定することにより負荷分散を行う。
リクエストを受けた負荷分散サーバ１４はＷＷＷサーバ１５へリクエストを転送し返事を受け取る。そして、リクエストが送られてきたパスを逆にたどって、返事をＰｒｏｘｙサーバ１２へ返す。
【００１３】
図３、図４はそれぞれ負荷分散サーバ１３、負荷分散サーバ１４の構成を示す図であり、図３、図４はＨＴＴＰ送受信器２１、多重化装置２３、送受信器２４の左右の位置が入れ代わった点を除き同一である。
図３、図４において、２１はＨＴＴＰ受信器、２２はＨＴＴＰスイッチ、２３は多重化装置、２４は送受信器である。また、２５は自サーバの負荷を検出する負荷検出器、２６は自サーバの負荷・優先・構成情報を格納するテーブルである。上記テーブル２６には、負荷検出器２５により検出される「自サーバの負荷状態（負荷情報）」、管理者制御インタフェースから設定される「自サーバの優先度を示す優先情報」および「自サーバのデータ構成を示す構成情報」が格納される。
【００１４】
これらの情報は、定期的にあるいは適宜マルチキャスト送受信器２８からマルチキャスト・ネットワーク１６を介して他の負荷分散サーバへ送られる。
２７は他サーバの負荷、優先、構成情報を格納したテーブルであり、負荷分散サーバが起動されると、他サーバのこれらの情報をマルチキャスト通信により獲得し、上記テーブル２７の情報を更新する。
【００１５】
図５、図６は本実施例の負荷分散サーバの処理を説明するフローチャートであり、同図により本実施例について説明する。
(1) 負荷分散サーバが起動されると、まず管理者制御であるかを判定し、管理者制御の場合には、自サーバの負荷・優先・構成情報を前記テーブル２７に設定する（図５のステップＳ１，Ｓ２）。
【００１６】
(2) 管理者制御でない場合には、マルチキャスト受信であるかを調べ、マルチキャスト受信の場合には、マルチキャスト・ネットワーク１６を介して他サーバの負荷・優先・構成情報を獲得し、他サーバの負荷・優先・構成情報テーブル２７を更新する（ステップＳ３，Ｓ４，Ｓ５）。
また、特定のサーバからのマルチキャスト受信が所定時間ないことなどにより故障したサーバを認識し、故障したサーバがあったとき、そのサーバのテーブル情報を変更する（ステップＳ６，Ｓ７）。
上記のように他のサーバが故障したとき、負荷分散サーバのテーブル情報が変更されるので、故障したサーバは自動的にサービスから取り除かれ、また、新たなサーバが追加されたり、故障していたサーバが復旧すると、それに応じて上記テーブル情報が変更されるため、新たに追加されたサーバ、故障から復旧したサーバが自動的にサービスに加えられる。
(3) マルチキャスト受信でない場合には、マルチキャスト送信であるかを調べ、マルチキャスト送信の場合には、自サーバの負荷・優先・構成情報テーブル２７の内容をダンプして、マルチキャスト・ネットワーク１６を介して他サーバへ送信する（ステップＳ８，Ｓ９，Ｓ１０）。
【００１７】
(4) マルチキャスト送信でない場合には、ＨＴＴＰ受信であるかを調べる。ＨＴＴＰ受信の場合には、ＨＴＴＰ送受信器２１で受信したリクエストをＨＴＴＰスイッチ２２へ転送し、他サーバの負荷・優先・構成情報テーブル２７を検索する（図６のステップＳ１１，Ｓ１２，Ｓ１３）。
そして、上記負荷・優先・構成情報に基づき、転送先の負荷分散サーバを設定する（ステップＳ１４）。
例えば、負荷を均等化する場合には、一番負荷の軽いサーバを検索し、そのサーバを転送先サーバとする。
以上のようにして転送先サーバが決まると、多重化装置２３により多重化し、リクエストを送受信器２４から負荷分散サーバへ送信する（ステップＳ１５，Ｓ１６）。
【００１８】
(5) ＨＴＴＰ受信でない場合には、多重化受信であるかを調べ、多重化受信の場合には、リクエストを多重化装置によりデマルチプレックスする。そして、負荷分散サーバ１４からリクエストを転送する場合には、リクエストの転送先を検索し、ＨＴＴＰ送信を行う。また、負荷分散サーバ１３からＰｒｏｘｙサーバへ返事を返すときには、ＨＴＴＰの返事の戻り先を検索し、ＨＴＴＰ送信を行う（ステップＳ１７，Ｓ１８，Ｓ１９，Ｓ２０）。
【００１９】
【発明の効果】
以上説明したように本発明においては、以下の効果を得ることができる。
（１）マルチキャスト通信手段を用いて、サーバの負荷・優先・構成情報を定期的あるいは適宜に交換しているので、短い時間間隔で各サーバに均等に負荷を分散させることができ、また、サーバのサービス内容を動的に変更することができる。
さらに、故障したサーバは自動的にサービスから除かれ、また、新たに追加されたサーバ、故障から復旧したサーバは自動的にサービスに加えられる。
【００２０】
特に、イントラネット等の企業内での通信は、インターネットの通信と比較して負荷の偏りが大きい。また、企業内部に限定されるため、サーバの数が少ない。このため、本発明のシステムをイントラネット等の企業内での通信に適用することにより、オーバヘッドとなる負荷・優先・構成情報のマルチキャスト通信を少なく保ったまま、サーバに掛かる負荷を制御して、負荷を最適に均衡化することができる。
（２）企業内の場合、特定のユーザに対するアクセス・レスポンスを優先しなければならない場合があるが、本発明によれば、新たに専用サーバを導入することなく、動的にユーザへのレスポンスを優先させることができる。
（３）既存のサーバ／クライアントシステムに大きな変更を加えることなく、性能を自動的に最適化することができ、管理者の運用負担を低減化することができる。また、性能に関わる詳しいチューニング技術を習得していない管理者でも、効率的な運用が可能となる。
【図面の簡単な説明】
【図１】本発明の原理構成図である。
【図２】本発明の実施例のシステムの全体構成図である。
【図３】負荷分散サーバの構成を示す図である。
【図４】負荷分散サーバの構成を示す図である。
【図５】負荷分散サーバの処理を示すフローチャート（１）である。
【図６】負荷分散サーバの処理を示すフローチャート（１）である。
【符号の説明】
１ａクライアント
２ａサーバ
１ｂ，２ｂ負荷分散サーバ
３マルチキャスト通信手段
１１クライアント
１２Ｐｒｏｘｙサーバ
１３，１４負荷分散サーバ
１５ＷＷＷサーバ
１６マルチキャスト・ネットワーク
２１ＨＴＴＰ送受信器
２２ＨＴＴＰスイッチ
２３多重化装置
２４送受信器
２５負荷検出器
２６自サーバの負荷・優先・構成情報テーブル
２７他サーバの負荷・優先・構成情報テーブル
２８マルチキャスト送受信器[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a load distribution system capable of autonomously distributing a communication load on a network such as an intranet.
[0002]
[Prior art]
The load distribution of communication on the current WWW is not a server load at each point of time, but the client side makes a transaction based on the weight of each server set in advance so that the load on each server is optimized. Alternatively, the load is unilaterally distributed in units of time.
[0003]
[Problems to be solved by the invention]
The probabilistic method described above not only has to predict the load on the server in advance, but it is also possible to balance the load as an average of long time intervals. End up.
If the load at each time point is not distributed, the computer frequently causes context switching, paging, etc., and overhead is generated at this portion, making it impossible to execute transactions efficiently.
Also, if a server goes down due to some failure, the load distribution assumed by the administrator is not performed, the load is not only unevenly distributed among servers, but sometimes the load on a specific server is concentrated and the response of the entire service Will be significantly reduced.
[0004]
On the other hand, in some cases, not all clients are treated equally, but there are clients that must be prioritized. In such a case, in the current WWW environment, a dedicated server for the priority client must be prepared.
However, WWW access is not constant throughout the day, and there are usually busy and free time zones. It is sufficient if a specific client can be given priority during busy hours. It must be prepared and the computer cannot be used effectively.
[0005]
Furthermore, in the current load balancing method of the WWW environment, even if the administrator adds a new server for load balancing or a server that has recovered from a failure according to the load status, it is immediately reflected in the entire client. Since there is no means to notify, a delay of several tens of minutes to several hours occurs until the load distribution is effective.
The present invention has been made in view of the above-described circumstances, and the object of the present invention is to exchange the load, priority, and configuration information between computers in real time by using multicast communication, thereby reducing the load on each server. to provide a load distribution system capable Rukoto it is evenly distributed.
[0006]
[Means for Solving the Problems]
When one-to-one communication from a server to a client is performed, an enormous amount of communication proportional to the number of clients is required, but in a one-to-n multicast communication, only a certain number of communication is necessary.
If this is performed on a very large network such as the Internet, information that is rarely used is communicated to the entire network, which wastes network bandwidth. However, in an intranet or the like, servers widely used in the company are centralized and centrally managed, so that unnecessary communication is reduced even if the multicast communication is used.
The present invention pays attention to the above points and uses multicast communication means to transmit the load status of the server to the client and optimize the load of the server on the network.
Although the present invention is difficult to apply to the entire Internet, the burden on the server administrator can be reduced and efficient autonomous load balancing can be achieved in some intranets, extranets, and the Internet.
[0007]
FIG. 1 is a principle configuration diagram of the present invention.
In the present invention, as shown in the figure, a plurality of client-side load balancing servers 1b provided corresponding to each of the clients for transferring requests of the plurality of clients to the server side, and the plurality of servers A plurality of server-side load distribution servers 2b for transferring requests from the client side to the server, and the client-side load distribution server 1b and the server-side load distribution server 2b are multicast communication means. 3, and the load, priority, and data configuration information of the plurality of servers are exchanged in real time between the client side load distribution server 1 b and the plurality of server side load distribution servers 2 b using the multicast communication means 3. To do.
The client-side load balancing server 1b uses the information exchanged between the client-side load balancing server 1b and the plurality of server-side load balancing servers 2b so that the load on the plurality of servers is equalized from the client. Are distributed and transferred to any one of the plurality of server-side load distribution servers 2b.
[0008]
In the first to third aspects of the present invention, the server load / priority / configuration information is fed back to the client periodically or appropriately using the multicast communication means 3 as described above. Since it is possible to know the exact server load status, server failure, addition of a new server, restoration of a failed server, etc., the client can evenly distribute the load to each server at short time intervals.
Furthermore, since the configuration information including the service contents of the server is notified to the client, the service contents of the server can be dynamically changed.
[0009]
Furthermore, because it is possible to know server failure, addition of new server, recovery of failed server, etc., the failed server is automatically removed from the service, and newly added server, recovery from failure The added server is automatically added to the service.
The system of the present invention can automatically optimize the performance without changing the existing client / server system and reduce the operation burden on the administrator. In addition, it is not necessary for the administrator to plan load distribution carefully in advance and constantly monitor load fluctuations.
[0010]
DETAILED DESCRIPTION OF THE INVENTION
FIG. 2 is a diagram showing the overall configuration of the system according to the embodiment of the present invention.
In the figure, 13 and 14 are WWW load distribution servers (hereinafter referred to as load distribution servers), and the load distribution servers 14 and 13 are respectively an HTTP (Hyper Text Transfer Protocol) WWW server 15 (hereinafter referred to as a WWW server) and an HTTP. It operates as a front end and a back end of the proxy server 12 (hereinafter referred to as a proxy server).
The load distribution servers 13 and 14 are connected to the multicast network 16, and when the load distribution server is activated, the configuration, load, and priority information of other already operating servers are acquired by multicast communication. Establish a connection that enables multiplexed communication between them.
[0011]
When the proxy server 12 receives a request from the HTTP client 11, the proxy server 12 transfers the request to the nearest load balancing server 13. The load distribution server 13 relays the request using the multiplexed connection to the load distribution server 14 near the WWW server 15.
When performing load distribution by a plurality of WWW servers, one load distribution server 14 is allocated to each WWW server (a pair of WWW servers and load distribution servers may be operated on the same computer).
[0012]
At that time, the load distribution server 13 performs load distribution by determining a load distribution server to which a request is transferred by a predetermined algorithm based on the loads and priorities of the plurality of WWW servers 15.
The load distribution server 14 that has received the request transfers the request to the WWW server 15 and receives a reply. Then, the path to which the request is sent is traced in the reverse direction, and a reply is returned to the proxy server 12.
[0013]
3 and 4 are diagrams showing configurations of the load distribution server 13 and the load distribution server 14, respectively. In FIGS. 3 and 4, the left and right positions of the HTTP transmitter / receiver 21, the multiplexer 23, and the transmitter / receiver 24 are interchanged. It is the same except for the point.
3 and 4, 21 is an HTTP receiver, 22 is an HTTP switch, 23 is a multiplexing device, and 24 is a transceiver. Reference numeral 25 denotes a load detector for detecting the load of the own server, and reference numeral 26 denotes a table for storing the load / priority / configuration information of the own server. In the table 26, “the load state of the own server (load information)” detected by the load detector 25, “priority information indicating the priority of the own server” set from the administrator control interface, and “the own server's priority” The “configuration information indicating the data configuration” is stored.
[0014]
These pieces of information are sent from the multicast transmitter / receiver 28 to other load distribution servers via the multicast network 16 periodically or appropriately.
A table 27 stores the load, priority, and configuration information of other servers. When the load distribution server is activated, the information of the other servers is acquired by multicast communication, and the information in the table 27 is updated.
[0015]
FIG. 5 and FIG. 6 are flowcharts for explaining the processing of the load distribution server according to the present embodiment. The present embodiment will be described with reference to FIG.
(1) When the load balancing server is activated, it is first determined whether it is administrator control, and in the case of administrator control, the load / priority / configuration information of the own server is set in the table 27 (FIG. 5). Steps S1, S2).
[0016]
(2) If it is not under the control of the administrator, it is checked whether it is multicast reception. If it is multicast reception, the load / priority / configuration information of the other server is obtained via the multicast network 16, and the load of the other server is obtained. Update the priority / configuration information table 27 (steps S3, S4, S5).
Further, the server that has failed due to the absence of multicast reception from a specific server for a predetermined time is recognized, and when there is a server that has failed, the table information of the server is changed (steps S6 and S7).
As described above, when another server fails, the load balancing server table information is changed, so the failed server is automatically removed from the service, and a new server is added or has failed. When the server recovers, the table information is changed accordingly. Therefore, the newly added server and the server recovered from the failure are automatically added to the service.
(3) If it is not multicast reception, it is checked whether it is multicast transmission. If multicast transmission, the contents of the load / priority / configuration information table 27 of its own server are dumped and sent via the multicast network 16 It transmits to other servers (steps S8, S9, S10).
[0017]
(4) If it is not multicast transmission, check if it is HTTP reception. In the case of HTTP reception, the request received by the HTTP transceiver 21 is transferred to the HTTP switch 22 and the load / priority / configuration information table 27 of the other server is searched (steps S11, S12, and S13 in FIG. 6).
Then, based on the load / priority / configuration information, a transfer destination load distribution server is set (step S14).
For example, in order to equalize the load, a server with the lightest load is searched and the server is set as a transfer destination server .
When the transfer destination server is determined as described above, it is multiplexed by the multiplexer 23 and the request is transmitted from the transmitter / receiver 24 to the load distribution server (steps S15 and S16).
[0018]
(5) If it is not HTTP reception, it is checked whether it is multiplexed reception. If it is multiplexed reception, the request is demultiplexed by the multiplexer. When a request is transferred from the load balancing server 14, the transfer destination of the request is searched and HTTP transmission is performed. When returning a reply from the load balancing server 13 to the proxy server, the return destination of the HTTP reply is retrieved and HTTP transmission is performed (steps S17, S18, S19, S20).
[0019]
【The invention's effect】
As described above, in the present invention, the following effects can be obtained.
(1) by using multicast communication means, since the replaced periodically or suitably load-priority-configuration information of the server, can be distributed evenly load on each server in a short time interval, also, Sa The service contents of the server can be changed dynamically.
Further, the failed server is automatically removed from the service, and the newly added server and the server recovered from the failure are automatically added to the service.
[0020]
In particular, communication in a company such as an intranet has a large load bias compared to communication on the Internet. Moreover, since it is limited to the inside of a company, the number of servers is small. For this reason, by applying the system of the present invention to communication within a company such as an intranet, the load applied to the server is controlled while maintaining a small amount of overhead, priority and configuration information multicast communication. Can be optimally balanced.
(2) In the case of an in-house company, priority may be given to access and response to a specific user. However, according to the present invention, a response to the user can be dynamically sent without newly introducing a dedicated server. Can be prioritized.
(3) The performance can be automatically optimized without greatly changing the existing server / client system, and the operational burden on the administrator can be reduced. In addition, even an administrator who has not acquired detailed tuning techniques related to performance can operate efficiently.
[Brief description of the drawings]
FIG. 1 is a principle configuration diagram of the present invention.
FIG. 2 is an overall configuration diagram of a system according to an embodiment of this invention.
FIG. 3 is a diagram illustrating a configuration of a load distribution server.
FIG. 4 is a diagram illustrating a configuration of a load distribution server.
FIG. 5 is a flowchart (1) showing processing of the load balancing server.
FIG. 6 is a flowchart (1) showing processing of the load balancing server.
[Explanation of symbols]
DESCRIPTION OF SYMBOLS 1a Client 2a Server 1b, 2b Load distribution server 3 Multicast communication means 11 Client 12 Proxy server 13, 14 Load distribution server 15 WWW server 16 Multicast network 21 HTTP transmitter / receiver 22 HTTP switch 23 Multiplexer 24 Transmitter / receiver 25 Load detector 26 Load / priority / configuration information table of own server 27 Load / priority / configuration information table of other server 28 Multicast transceiver

Claims

A plurality of client-side load balancing servers provided corresponding to each of the clients, wherein requests from the plurality of clients are transferred to a server side between a plurality of clients and a plurality of servers connected to the network; and A plurality of server-side load distribution servers that correspond to each of the plurality of servers and transfer requests from the client side to the server are provided, and the client-side load distribution server and the server-side load distribution server are multicast communication means. Connect with
Using the multicast communication means, the load, priority, and data configuration information of the plurality of servers are exchanged in real time between the client side load distribution server and the plurality of server side load distribution servers,
The client-side load balancing server sends requests from clients so that the load on the plurality of servers is equalized using information exchanged between the client-side load balancing server and the plurality of server-side load balancing servers. A load distribution system that distributes and transfers to any one of the plurality of server-side load distribution servers.

2. The load distribution system according to claim 1, wherein the failed server is recognized from the load, priority, and data configuration information of another server exchanged in real time, and the failed server is automatically removed from the service.

3. The load distribution according to claim 1, wherein a new server or a server recovered from a failure is automatically added to the service according to the load, priority, and data configuration information of another server exchanged in real time. system.