(57)【要約】【課題】負荷の増大により応答フレームのレスポンスが遅延しているサーバがあるような場合に、応答の遅延を原因として遅延を増大させるといった不都合を解消させることのできる変負荷分散装置を得ること。【解決手段】負荷分散装置２０１は第１のサーバ１０１１と第２のサーバ１０１２にヘルスチェックフレームを送出し、これに対する応答時間がしきい値以上になるまではそれぞれの応答時間の間隔で次のヘルスチェックフレームを送出する（図で２秒または３秒の間隔）。しきい値以上（図で７秒）となった場合にはそれに比例した時間を追加して次のヘルスチェックフレームを送出する。クライアント端末１０６とこれらのサーバ１０１１、１０１２の通信はこの応答間隔に応じて割り当てられ、しきい値を超えたサーバは対象外となる。【選択図】　　　　図３
2004062246.tif 000002
【特許請求の範囲】
【請求項１】
クライアント端末からの通信要求に基づいてこの通信要求の対象となる複数のサーバのいずれとその通信を行わせるかを選択する通信先サーバ選択手段と、
この通信先サーバ選択手段の選択の対象となる前記複数のサーバに対してヘルスチェックを行うためのヘルスチェックフレームを順次送信してそれに対する応答時間を個別に測定する応答時間測定手段と、
この応答時間測定手段の測定したサーバごとの応答時間だけそれぞれ間隔を置いてこれらのサーバに対して次のヘルスチェックフレームを送信する送信間隔制御手段と、
この送信間隔制御手段によるヘルスチェックフレームの送信間隔を前記通信先サーバ選択手段のサーバの選択に反映させるサーバ選択反映手段
とを具備することを特徴とする負荷分散装置。
【請求項２】
クライアント端末からの通信要求に基づいてこの通信要求の対象となる複数のサーバのいずれとその通信を行わせるかを選択する通信先サーバ選択手段と、
この通信先サーバ選択手段の選択の対象となる前記複数のサーバに対してヘルスチェックを行うためのヘルスチェックフレームを順次送信してそれに対する応答時間が通常の基準を超える値としての所定のしきい値以上であるか否かをサーバごとに個別に比較するしきい値比較手段と、
このしきい値比較手段が応答時間をしきい値未満とするサーバに対して直前のヘルスチェックフレームの送信から今回の応答時間だけ時間を置いてヘルスチェックフレームを送信する第１のヘルスチェックフレーム送信手段と、
前記しきい値比較手段が応答時間をしきい値以上とするサーバに対して直前のヘルスチェックフレームの送信から今回の応答時間よりも長く、かつ今回の応答時間に比例した時間を追加した時間を置いてヘルスチェックフレームを送信する第２のヘルスチェックフレーム送信手段
とを具備することを特徴とする負荷分散装置。
【請求項３】
前記しきい値比較手段の比較によって所定のしきい値以上であると判別されたサーバを前記通信先サーバ選択手段の選択の対象外とする通信先サーバ選択手段選択対象制御手段を具備することを特徴とする請求項２記載の負荷分散装置。
【請求項４】
前記通信先サーバ選択手段は、ヘルスチェックフレームを送信する送信間隔が短いサーバほど前記クライアント端末と多くの回数接続させる通信先サーバ選択手段選択回数制御手段を具備することを特徴とする請求項１または請求項２記載の負荷分散装置。
【請求項５】
前記通信先サーバ選択手段は、ヘルスチェックフレームを送信する送信間隔が短いサーバほど前記クライアント端末と多くの時間接続させる通信先サーバ選択手段選択時間制御手段を具備することを特徴とする請求項１または請求項２記載の負荷分散装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はクライアント端末と複数のサーバの中の１つとを選択的に接続する負荷分散装置に係わり、特にサーバの負荷を分散するような接続を行うようにした負荷分散装置に関する。
【０００２】
【従来の技術】
インターネットが急激に普及しており、これと共に、高速な通信回線や冗長性および拡張性のあるネットワークの構築が求められている。このような背景の下で、負荷分散装置あるいはロードバランス装置といった装置が注目を集めている。
【０００３】
図５は、負荷分散装置の備えられた通信システムの概要を表わしたものである。複数のサーバ１０１Ａ、……１０１Ｍは、負荷分散装置１０２を介してインターネット網１０３に接続されている。サーバ１０１Ａ、……１０１Ｍと負荷分散装置１０２の間には第１の伝送路１０４が配置され、負荷分散装置１０２とインターネット網１０３の間には第２の伝送路１０５が配置されている。インターネット網１０３にはインターネットを閲覧するための複数のクライアント端末１０６１、……１０６Ｎが接続されている。負荷分散装置１０２は、各クライアント端末１０６１、……１０６Ｎとサーバファーム間のコネクションを、負荷の低いサーバ（たとえば第Ａのサーバ１０１Ａ）に割り当てることで、サーバ１０１Ａ、……１０１Ｍ間の負荷分散を実現している。
【０００４】
このような従来の負荷分散装置１０２では、定期的に各サーバ１０１Ａ、……１０１Ｍに状態監視用のヘルスチェックフレームを送信し、応答があったもののみを負荷分散の対象としていた。ヘルスチェックはサーバ１０１Ａ、……１０１Ｍのいずれかにダウンが生じた場合にこれを瞬時に検出して、これに代わるアクティブなものに負荷を切り替えるという役割を持っている。１０１Ａ、……１０１Ｍの中で応答のなかったものはダウンしている可能性があるので、これに負荷を掛けないようにするためである。
【０００５】
図６は、従来の負荷分散装置の構成の一例を示したものである。この負荷分散装置１０２は、第１の伝送路１０４側に第１の受信ドライバ１１１およびその受信したデータを格納する第１の受信メモリ１１２と、第１の送信ドライバ１１３およびこれに送信するデータを供給する第１の送信メモリ１１４を配置している。また、第２の伝送路１０５側に第２の受信ドライバ１１５およびその受信したデータを格納する第２の受信メモリ１１６と、第２の送信ドライバ１１７およびこれに送信するデータを供給する第２の送信メモリ１１８を配置している。第１の受信メモリ１１２、第１の送信メモリ１１４、第２の受信メモリ１１６および第２の送信メモリ１１８は、この負荷分散装置１０２の分散処理についての制御を行う分散処理部１１９に接続されている。分散処理部１１９には、ヘルスチェックを実行するためのヘルスチェック実行部１２１と、図５に示したサーバ１０１Ａ、……１０１Ｍの状態を記憶するサーバ状態テーブル１２２も接続されている。
【０００６】
このような従来の負荷分散装置１０２では、ヘルスチェック実行部１２１がヘルスチェックを行うための図示しないヘルスチェックフレームを第１の送信メモリ１１４に格納しておく。そして、第１の送信ドライバ１１３を使用して第１の伝送路１０４を介して所定の間隔でサーバ１０１Ａ、……１０１Ｍ（図５）に対してヘルスチェックフレームを送信する。ヘルスチェックフレームを受信したそれぞれのサーバ１０１Ａ、……１０１Ｍはこれに対して応答を行うようになっている。応答が行われると、第１の受信ドライバ１１１がこれを受信して第１の受信メモリ１１２に応答状況を格納することになる。
【０００７】
分散処理部１１９はそれぞれのサーバ１０１Ａ、……１０１Ｍの応答状況をチェックして、予め指定した回数にわたってヘルスチェックフレームに対して応答が返って来ないサーバ１０１が存在するかどうかを判別するようになっている。このようなサーバ１０１が存在した場合には、そのサーバ（以下、サーバ１０１Ｘが問題があるものとする。）に何らかの問題が発生しているものとして、サーバ状態テーブル１２２にそのサーバ１０１Ｘが選択対象外であると書き込むようにしている。
【０００８】
ところで、分散処理部１１９は、図５に示した各クライアント端末１０６１、……１０６Ｎからの要求を第２の受信ドライバ１１５で受信して第２の受信メモリ１１６に格納する。分散処理部１１９はサーバ状態テーブル１２２を見て、複数のサーバ１０１Ａ、……１０１Ｍから最適なものを選択して、クライアント端末１０６１、……１０６Ｎの各要求と対応付けて第１の送信メモリ１１４に格納する。そして、第１の送信ドライバ１１３を使用して第１の伝送路１０４からサーバ１０１Ａ、……１０１Ｍのうちの対応するものにこれらの要求を送信することになる。このサーバ１０１Ａ、……１０１Ｍの選択時に、先に説明した選択対象外のサーバ１０１Ｘは選択対象から除かれることは当然である。
【０００９】
ところで、分散処理部１１９がサーバ１０１の選択を行う際には、コネクションの最小のものを選択する手法と、これとは無関係に単純に順番通りサーバ１０１を選択する手法とがある。
【００１０】
図７は、図６に示したサーバ状態テーブルの構成の一例を示したものである。サーバ状態テーブル１２２は、サーバファーム名１３１、サーバ名１３２、ポート番号１３３およびサーバ状態１３４の各項目から構成されている。ここでサーバファームとは複数のサーバが集まった論理グループをいう。サーバファームは仮想ＩＰ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）アドレスで論理的に区別されており、各サーバが持っている実ＩＰアドレスと区別される。たとえば第１のファームはポート番号が８０番の第Ａのサーバ１０１Ａと第Ｂのサーバ１０１Ｂおよび第Ｃのサーバ１０１Ｃとで構成され、第２のファームはポート番号が４４３番の第Ａのサーバ１０１Ａで構成されている。この図７で鍵括弧“［　］”は、ダウンしたサーバであることを示しており、この図では第１のファームの第Ｃのサーバ１０１Ｃがダウンしたサーバとして示されている。
【００１１】
ところで、サーバ状態テーブル１２２に対するエントリは、サーバ名１３２とポート番号１３３の組であるサービス単位で行われる。サーバ状態１３４には、最新のヘルスチェックの結果が格納されている。このサーバ状態テーブル１２２で“Ｕｐ”と記したものはそのサーバ１０１についてヘルスチェックフレームに対する応答としての応答フレームの受信があったものであり、“Ｄｏｗｎ”と記したものは応答フレームの受信がなく、そのサーバ１０１がダウンした状態であることを示している。
【００１２】
【発明が解決しようとする課題】
ところで、従来の負荷分散装置１０２では各サーバ１０１Ａ、……１０１Ｍの状態を監視するために使用されるヘルスチェックフレームに対して応答が大幅に遅延してしまうことがある。このような場合に、負荷分散装置１０２側ではそのサーバ１０１が正常に動作しているにも係わらず、ダウンしたと誤認することがあった。また、応答までの時間の設定の仕方によってはサーバ１０１が正常であったとしてもサーバ状態テーブル１２２には“Ｕｐ”と記されたり“Ｄｏｗｎ”と記されることが頻繁に繰り返される事態が発生する場合があった。
【００１３】
その原因として、近年、ウェブサーバが業務アプリケーション処理を行うことが一般的になったことを挙げることができる。ウェブサーバが業務アプリケーション処理を行うことで、この処理に多くのリソースを配分することになる。これにより、サーバ１０１からの状態監視用のヘルスチェックフレームへの応答が大幅に遅延する現象が見られている。
【００１４】
そこで、特開平０８−２２３１９１号公報では、ヘルスチェックフレームに対する応答が予め定めた応答待ち時間よりも短いか長いかをチェックして、これに応じて応答待ち時間を順次短く、あるいは順次長く変更するようにしている。この提案によれば、前回の応答までの時間を見て次のヘルスチェックフレームに対する応答待ち時間を調整している。したがって、前回の応答時間よりも今回の応答時間が更に長くなるような場合には、その応答フレームを受信する前に次のヘルスチェックフレームがすでに送出されているといった事態が発生することになる。これにより、該当のサーバ１０１は負荷が掛かっている状態で更にヘルスチェックフレームを受信してこれに応答を出す必要があり、ますます負荷が増大するといった問題があった。
【００１５】
そこで本発明の目的は、負荷の増大により応答フレームのレスポンスが遅延しているサーバがあるような場合に、応答の遅延を原因として更にこのサーバに負荷を掛けて遅延を増大させるといった不都合を解消させることのできる変負荷分散装置を提供することにある。
【００１６】
【課題を解決するための手段】
請求項１記載の発明では、（イ）クライアント端末からの通信要求に基づいてこの通信要求の対象となる複数のサーバのいずれとその通信を行わせるかを選択する通信先サーバ選択手段と、（ロ）この通信先サーバ選択手段の選択の対象となる前記した複数のサーバに対してヘルスチェックを行うためのヘルスチェックフレームを順次送信してそれに対する応答時間を個別に測定する応答時間測定手段と、（ハ）この応答時間測定手段の測定したサーバごとの応答時間だけそれぞれ間隔を置いてこれらのサーバに対して次のヘルスチェックフレームを送信する送信間隔制御手段と、（ニ）この送信間隔制御手段によるヘルスチェックフレームの送信間隔を通信先サーバ選択手段のサーバの選択に反映させるサーバ選択反映手段とを負荷分散装置に具備させる。
【００１７】
すなわち請求項１記載の発明では、通信先サーバ選択手段が、クライアント端末からの通信要求に基づいてこの通信要求の対象となる複数のサーバのいずれとその通信を行わせるかを選択するようにして負荷の分散を行うようになっている。このために応答時間測定手段は、通信先サーバ選択手段の選択の対象となる前記した複数のサーバに対してヘルスチェックを行うためのヘルスチェックフレームを順次送信してそれに対する応答時間を個別に測定するようにしている。そして送信間隔制御手段が、このときのそれぞれのサーバの応答時間だけそれぞれ間隔を置いてこれらのサーバに対して次のヘルスチェックフレームを送信するようにしている。これにより、負荷が掛かっていてヘルスチェックフレームに対する応答が遅延するようなサーバに対しては、ヘルスチェックフレーム自体の送信間隔を長く設定することで、このヘルスチェックフレームの処理に要する負荷を軽減させ、これにより更にこのサーバに負荷を掛けて遅延を増大させるといった不都合を解消させている。
【００１８】
請求項２記載の発明では、（イ）クライアント端末からの通信要求に基づいてこの通信要求の対象となる複数のサーバのいずれとその通信を行わせるかを選択する通信先サーバ選択手段と、（ロ）この通信先サーバ選択手段の選択の対象となる前記した複数のサーバに対してヘルスチェックを行うためのヘルスチェックフレームを順次送信してそれに対する応答時間が通常の基準を超える値としての所定のしきい値以上であるか否かをサーバごとに個別に比較するしきい値比較手段と、（ハ）このしきい値比較手段が応答時間をしきい値未満とするサーバに対して直前のヘルスチェックフレームの送信から今回の応答時間だけ時間を置いてヘルスチェックフレームを送信する第１のヘルスチェックフレーム送信手段と、（ニ）しきい値比較手段が応答時間をしきい値以上とするサーバに対して直前のヘルスチェックフレームの送信から今回の応答時間よりも長く、かつ今回の応答時間に比例した時間を追加した時間を置いてヘルスチェックフレームを送信する第２のヘルスチェックフレーム送信手段とを負荷分散装置に具備させる。
【００１９】
すなわち請求項２記載の発明では、通信先サーバ選択手段が、クライアント端末からの通信要求に基づいてこの通信要求の対象となる複数のサーバのいずれとその通信を行わせるかを選択するようにして負荷の分散を行うようになっている。このためにしきい値比較手段は、通信先サーバ選択手段の選択の対象となる前記した複数のサーバに対してヘルスチェックを行うためのヘルスチェックフレームを順次送信してそれに対する応答時間が通常の基準を超える値としての所定のしきい値以上であるか否かをサーバごとに個別に比較するようにしている。そして、この比較結果から通常の応答時間の範囲内で応答しているサーバに対しては、請求項１記載の発明と同様に、そのサーバについて直前のヘルスチェックフレームの送信から今回の応答時間だけ時間を置いてヘルスチェックフレームを送信するようにし、それぞれのサーバの負荷を調整している。また、通常の応答時間の範囲内で応答していないサーバ、すなわちしきい値比較手段が応答時間をしきい値以上とするサーバに対しては、直前のヘルスチェックフレームの送信から今回の応答時間よりも長く、かつ今回の応答時間に比例した時間を追加した時間を置いてヘルスチェックフレームを送信するようにしている。たとえば５秒までの応答時間が通常の範囲内と考えられるサーバで８秒の応答時間を要した場合には、第１のヘルスチェックフレーム送信手段がこれを処理するとすれば同じ８秒の間隔でヘルスチェックフレームを送信しその範囲内で送信間隔が延びることになるが、第２のヘルスチェックフレーム送信手段の場合には更に８秒あるいはこれをたとえば１．５倍した１２秒の時間を追加した全体として１６秒（８秒＋８秒）あるいは２０秒（８秒＋１２秒）の間隔で先のヘルスチェックフレームの送信から次のヘルスチェックフレームの送信を行うことになる。このようにすることで、負荷が非常に掛かっているサーバに対してヘルスチェックフレームの処理の負担を極力減少させることができる。
【００２０】
請求項３記載の発明では、請求項２記載の負荷分散装置が、しきい値比較手段の比較によって所定のしきい値以上であると判別されたサーバを通信先サーバ選択手段の選択の対象外とする通信先サーバ選択手段選択対象制御手段を具備することを特徴としている。
【００２１】
すなわち請求項３記載の発明では、所定のしきい値以上に応答時間を要するサーバを通信先サーバ選択手段の選択の対象外とすることで、そのサーバの負荷を軽減している。
【００２２】
請求項４記載の発明では、請求項１または請求項２記載の負荷分散装置で、通信先サーバ選択手段は、ヘルスチェックフレームを送信する送信間隔が短いサーバほどクライアント端末と多くの回数接続させる通信先サーバ選択手段選択回数制御手段を具備することを特徴としている。
【００２３】
すなわち請求項４記載の発明では、応答時間を基にしてヘルスチェックフレームの送信間隔を変更することに着目して送信間隔が短いサーバほど現状での負荷が小さいと判別しクライアント端末と多くの回数接続させるようにしている。これにより、結果的には各サーバの負荷を均等化することができる。
【００２４】
請求項５記載の発明では、請求項１または請求項２記載の負荷分散装置で、通信先サーバ選択手段は、ヘルスチェックフレームを送信する送信間隔が短いサーバほどクライアント端末と多くの時間接続させる通信先サーバ選択手段選択時間制御手段を具備することを特徴とすることを特徴としている。
【００２５】
すなわち請求項５記載の発明では、応答時間を基にしてヘルスチェックフレームの送信間隔を変更することに着目して送信間隔が短いサーバほど現状での負荷が小さいと判別しクライアント端末と多くの時間接続させるようにしている。これにより、結果的には各サーバの負荷を均等化することができる。
【００２６】
【発明の実施の形態】
【００２７】
【実施例】
以下実施例につき本発明を詳細に説明する。
【００２８】
図１は、本発明の一実施例における負荷分散装置を表わしたものである。本実施例の負荷分散装置２０１の使用される通信ネットワークの構成は先の図５に示したものと同じである。そこで、図５と同一部分には同一の符号を付すことにし、また図５に示した負荷分散装置１０２を本実施例では負荷分散装置２０１と適宜読み替えて使用することにする。
【００２９】
本実施例の負荷分散装置２０１でも、第１の伝送路１０４側にフレームの受信を行う第１の受信ドライバ１１１およびその受信したデータを格納する第１の受信メモリ１１２と、第１の送信ドライバ１１３およびこれに送信のためのフレームを供給する第１の送信メモリ１１４を配置している。また、第２の伝送路１０５側に、フレームの受信を行う第２の受信ドライバ１１５およびその受信したデータを格納する第２の受信メモリ１１６と、第２の送信ドライバ１１７およびこれに送信のためのフレームを供給する第２の送信メモリ１１８を配置している。第１の送信ドライバ１１３はフレームを第１の伝送路１０４に送信し、第２の送信ドライバ１１７はフレームを第２の伝送路１０５に送信することになる。
【００３０】
第１の受信メモリ１１２、第１の送信メモリ１１４、第２の受信メモリ１１６および第２の送信メモリ１１８は、この負荷分散装置２０１の分散処理についての制御を行う分散処理部２０２に接続されている。分散処理部２０２には、ヘルスチェックを実行するためのヘルスチェック実行部２０３と、図５に示したサーバ１０１１、……１０１Ｍのレスポンス（応答）までの時間としてのレスポンス間隔を記憶するサーバ状態テーブル２０４も接続されている。また、本実施例ではヘルスチェック実行部２０３とサーバ状態テーブル２０４の双方に各サーバ１０１１、……１０１Ｍのレスポンスを監視するためのレスポンス監視部２０５が接続されている。
【００３１】
このような本実施例の負荷分散装置２０１では、図６に示した従来の負荷分散装置１０２と異なりサーバ状態テーブル２０４に前回のレスポンス間隔を記憶しておき、このレスポンス間隔を応答時間として設定するようにしている。レスポンス監視部２０５はサーバ状態テーブル２０４を参照して、レスポンスが特に遅くない通常の場合にレスポンス間隔だけ間隔を置いて、サーバ１０１１、……１０１Ｍの中から負荷分散対象とされたものにヘルスチェックフレームを送信するようになっている。
【００３２】
図２は、本実施例で使用されるサーバ状態テーブルの内容の一例を示したものである。サーバ状態テーブル２０４は、サーバファーム名２３１、サーバ名２３２、ポート番号２３３、応答時間２３４、しきい値２３５、ヘルスチェックフレームの送信時刻２３６およびヘルスチェックフレームの送信開始時刻２３７の各項目によって構成されている。応答時間２３４（以下応答時間ＴＲという。）とは、そのサーバに対してヘルスチェックフレームを送信してから応答が返ってくるまでの時間であり、通常の場合には同一のサーバに対するヘルスチェックフレームの送信間隔にほぼ等しい。しきい値２３５（以下、しきい値ＴＨという。）はその時間が通常の範囲内のものであるかどうかを判別するためのものである。送信時刻２３６（以下、送信時刻ｔ１という。）とはヘルスチェックフレームを実際に送信した時刻ｔ１である。これに対して送信開始時刻２３７（以下、送信開始時刻ｔ３という。）とは送信を開始させる時刻である。送信開始時刻ｔ３は応答時間ＴＲがしきい値ＴＨ以上となる場合、すなわちそのサーバ１０１の負荷が大きいような場合に設定されるものである。
【００３３】
本実施例では第Ａのサーバ１０１Ａが第１のファームと第２のファームに属している。このように１つのサーバが複数のファームに属する場合があるので、ヘルスチェックフレームの送信制御および次に説明する応答フレームのチェックの制御については、これらサーバおよびファームの組み合わせについてサーバ状態テーブル２０４の左端に便宜的に示した連番“１、２、……”を基にして、第１のサーバ１０１１、第２のサーバ１０１２、……というように記述して説明を行うことにする。
【００３４】
図３は、本実施例のヘルスチェックについての制御と各クライアントとサーバの間の実通信の関係の一例を表わしたものである。ここでは説明を簡単にするために第１のサーバ１０１１と第２のサーバ１０１２の２つのサーバについての制御のみを示すことにする。また、クライアントについては図５に示した各クライアント端末１０６１、……１０６Ｎを特に区別せずに、単純にクライアント端末１０６として示すことにする。この図で実線はクライアント端末１０６と第１のサーバ１０１１または第２のサーバ１０１２の間の実通信を表わし、一点鎖線はヘルスチェックフレームとその応答を示している。
【００３５】
時刻ｔ１１に負荷分散装置２０１が第１のサーバ１０１１に対してヘルスチェックフレームを送信したとする。第１のサーバ１０１１がこれに対して２秒経過後の時刻ｔ１２に応答フレームを返送したとすると、応答時間ＴＲは２秒となる。そこで負荷分散装置２０１はこの応答時間ＴＲを図２に示したサーバ状態テーブル２０４の該当箇所に上書きする。また、ヘルスチェックフレームを送信した時刻ｔ１１から２秒経過した後の比較的早い時刻ｔ１３に負荷分散装置２０１が再度第１のサーバ１０１１に対してヘルスチェックフレームを送信する。ところが、これに対する応答時間ＴＲは７秒であり、サーバ状態テーブル２０４に設定したしきい値の５秒よりも長い。そこで、この応答フレームを負荷分散装置２０１が受信した時刻ｔ１４から更に７秒経過した時刻ｔ１５に、負荷分散装置２０１は第１のサーバ１０１１に対してヘルスチェックフレームを送信することになる。このようにヘルスチェックフレームに対する第１のサーバ１０１１の応答が特別に遅いときには、ヘルスチェックフレームの送信間隔を延ばして、これを受信する第１のサーバ１０１１のヘルスチェックフレームに対する処理の負担の軽減を図るようにしている。
【００３６】
これに対して、負荷分散装置２０１と第２のサーバ１０１２の関係について見てみると、図３に示す最初の段階で３秒間の応答時間ＴＲで応答フレームが負荷分散装置２０１に返送されている。そこで、負荷分散装置２０１はこの時刻ｔ２１から比較的早い時刻ｔ２２にヘルスチェックフレームを第２のサーバ１０１２に対して送出する。これに対する第２のサーバ１０１２の応答時間ＴＲが２秒間であったとすると、その受信時刻ｔ２３から比較的早い時刻ｔ２４（時刻ｔ２２から２秒経過後の比較的早い時刻）に負荷分散装置２０１は第２のサーバ１０１２に対してヘルスチェックフレームを送信する。第２のサーバ１０１２に対しては以下同様にしてほぼ２秒間隔でヘルスチェックフレームの送信が行われていく。
【００３７】
以上のような状況で、クライアント端末１０６とこれら第１および第２のサーバ１０１１、１０１２の本来の通信（実通信）について見てみる。時刻ｔ１１と時刻ｔ１２の間の時刻ｔ３１にクライアント端末１０６からアクセスがあったとすると、負荷分散装置２０１はこの状態で応答時間ＴＲがしきい値ＴＨを超えていないいずれかのサーバを選択して、アクセスを仲介する。ここでは負荷分散装置２０１は第１のサーバ１０１１を選択する。すなわち負荷分散装置２０１は第１のサーバ１０１１に対してクライアント端末１０６からの信号を送出し、これから返答があったときこれをクライアント端末１０６に戻す。時刻ｔ３２にクライアント端末１０６から他のアクセスがあった場合、負荷分散装置２０１は第１および第２のサーバ１０１１、１０１２のいずれも選択することができる。この例の場合、負荷分散装置２０１は第２のサーバ１０１２を選択し、これから返答があったときこれをクライアント端末１０６に戻している。
【００３８】
一方、時刻ｔ１４以降では第１のサーバ１０１１の応答時間ＴＲがしきい値ＴＨを超えており、その負荷が増大している。そこで、たとえば時刻ｔ１４以降の時刻ｔ３３にクライアント端末１０６から更に他のアクセスがあった場合、負荷分散装置２０１は第１のサーバ１０１１を選択対象から外して第２のサーバ１０１２とクライアント端末１０６との間で実通信を行わせる。時刻ｔ３４におけるクライアント端末１０６のアクセスについても同様である。
【００３９】
図４は、図３に示した制御を可能とする負荷分散装置の処理の流れを示したものである。負荷分散装置２０１内のレスポンス監視部２０５（図１）はサーバ１０１（図５）からヘルスチェックフレームに対する応答フレームが受信されるかの判別（ステップＳ３０１）と、サーバ状態テーブル２０４（図２）に送信開始時刻ｔ３が書き込まれている場合にそれらのいずれかが現在時刻に到達したかの判別（ステップＳ３０２）を行う。ヘルスチェックフレームに対する応答フレームを受信した場合には（ステップＳ３０１：Ｙ）、応答を返したサーバ１０１のヘルスチェックフレームの送信時刻ｔ１を読み出す（ステップＳ３０３）。そして、現在時刻ｔ２から送信時刻ｔ１を差し引いて得られた応答時間ＴＲを算出する（ステップＳ３０４）。そして応答時間ＴＲを図２に示すサーバ状態テーブル２０４に上書きする（ステップＳ３０５）。
【００４０】
このときレスポンス監視部２０５は応答時間ＴＲがしきい値ＴＨ以上であるかどうかをチェックする（ステップＳ３０６）。たとえば図３に示した時刻ｔ１１に送出したヘルスチェックフレームに対する応答フレームの場合には応答時間ＴＲが２秒である。このような場合には（ステップＳ３０６：Ｎ）、遅滞なくそのサーバ（この例の場合には第１のサーバ１０１１）に対して次のヘルスチェックフレームを送信する（ステップＳ３０７）。これは、応答がしきい値ＴＨ未満なので、この例の場合の第１のサーバ１０１１の負荷が比較的少なく、かつ正常に動作していると判別されるからである。この場合、レスポンス監視部２０５は送信したヘルスチェックフレームについての送信時刻ｔ１をサーバ状態テーブル２０４の該当する箇所に上書きして、これを最新のデータに更新する（ステップＳ３０８）。
【００４１】
一方、たとえば図３の時刻ｔ１３に送出したヘルスチェックフレームに対する応答フレームのように応答時間ＴＲがしきい値ＴＨとしての５秒以上であったような場合（この例では応答時間ＴＲが７秒）（ステップＳ３０６：Ｙ）、送信開始時刻ｔ３をサーバ状態テーブル２０４の該当する箇所に書き込む（ステップＳ３０９）。この場合の送信開始時刻ｔ３は現在時刻ｔ２に応答時間ＴＲ（この例では応答時間ＴＲが７秒）を加えた時刻である。
【００４２】
このようにして送信開始時刻ｔ３がサーバ状態テーブル２０４に書き込まれた場合（図２の送信開始時刻ｂ４等）には、その時刻が到来した時点で（ステップＳ３０２：Ｙ）、ヘルスチェック実行部２０３が該当するサーバ１０１にその時点でヘルスチェックフレームを送信する（ステップＳ３１０）。この例の場合には、図３に示す時刻ｔ１３から７秒経過した後の時刻ｔ１４に第１のサーバ１０１１に対してヘルスチェックフレームが送信されることになる。ヘルスチェックフレームの送信が行われたら、再送信の誤動作を防止するためにその送信開始時刻ｔ３を示すデータがサーバ状態テーブル２０４から削除される（ステップＳ３１１）。そして、ステップＳ３０８に進んで、送信したヘルスチェックフレームについての送信時刻ｔ１がサーバ状態テーブル２０４の該当する箇所に上書きされる。以上の処理が繰り返されることで、各サーバの負荷に応じたヘルスチェックフレームの送信制御が行われることになる。
【００４３】
発明の変形可能性
【００４４】
以上説明した実施例ではサーバ状態テーブル２０４に応答時間ＴＲを書き込んだ。しかしながら、通常の場合、ヘルスチェックフレームに対する応答フレームが返送されてきた時点で次のヘルスチェックフレームの送信を開始する制御が行われる。したがって、サーバ状態テーブル２０４に応答時間ＴＲを書き込むことは省略することができる。ただし、実施例では応答時間ＴＲがしきい値ＴＨ以上の場合に関してのみ、現時点から更に応答時間ＴＲを経過した後の時間を送信開始時間ｔ３としてサーバ状態テーブル２０４に格納しておくことにしている。したがって、この例のような場合にのみ応答時間ＴＲを用いて送信開始時間ｔ３を設定するようにすればよい。
【００４５】
また、実施例ではヘルスチェックフレームの送信から応答フレームの受信までの時間がしきい値ＴＨ以上の場合には、応答フレームの受信から応答時間ＴＲを加えた時刻を送信開始時刻ｔ３として設定できるようにしたが、この例のように１倍の応答時間ＴＲを加えるだけでなく、１．５倍あるいは２倍等の他の倍率を設定してもよいことは当然である。
【００４６】
更に実施例では各サーバが必ず応答フレームを返送する場合を説明したが、一部のサーバが何らかの障害を起こしてヘルスチェックフレームに対して長期間応答できない場合がある。この場合には、応答時間ＴＲが先のしきい値ＴＨよりも長さの長い第２のしきい値を超えるかどうかを更に判別させ、超えた場合にはそのサーバに障害が発生しているとして、たとえば１時間といった所定時間の間、そのサーバへのヘルスチェックフレームの送信を禁じるようにしてもよい。これにより障害を発生させたサーバのために応答フレームの返送までの時間を長時間監視する手間を省くことができる。
【００４７】
また、実施例では特に具体的に説明しなかったが、ヘルスチェックフレームに対する各サーバの応答フレームの返送までの応答時間ＴＲを基にしてそれぞれのサーバとクライアント端末の接続の割合を動的に変化させることが可能である。このような割合の制御としては、応答時間ＴＲが短いサーバほどクライアント端末と多くの回数接続させるようにすることや、応答時間ＴＲが短いサーバほどクライアント端末と多くの時間接続させることが有効である。もちろん、各サーバの処理能力を考慮したり、クライアント端末の要求の優先度を配慮することも場合により重要である。
【００４８】
【発明の効果】
以上説明したように請求項１記載の発明によれば、送信間隔制御手段が、ヘルスチェックフレームに対するそれぞれのサーバの応答時間だけ間隔を置いてこれらのサーバに対する次のヘルスチェックフレームを送信するようにしている。これにより、負荷の掛かった状態のサーバに対しては、ヘルスチェックフレームの処理に要する負荷を軽減させることができる。しかも、各サーバのヘルスチェックフレームに対する応答時間を個別に把握するので、クライアント端末とこれらのサーバの接続制御をきめ細かく行うことができ、負荷の分散の効果を高めることができる。
【００４９】
請求項２記載の発明によれば、請求項１記載の発明と同様の効果を得ることができるだけでなく、しきい値比較手段が応答時間をしきい値以上とするサーバに対して直前のヘルスチェックフレームの送信から今回の応答時間よりも長く、かつ今回の応答時間に比例した時間を追加した時間を置いてヘルスチェックフレームを送信する第２のヘルスチェックフレーム送信手段を備えたので、過負荷のサーバに対してヘルスチェックフレームの送信間隔を重点的に増長させることができる。また、しきい値比較手段の比較結果をサーバの選択に反映させることで実通信に対するサーバの負荷も軽減させることが可能になる。
【００５０】
更に請求項３記載の発明によれば、所定のしきい値以上に応答時間を要するサーバを通信先サーバ選択手段の選択の対象外とすることで、ヘルスチェックフレームに対する応答処理の軽減と併せてそのサーバの負荷を効果的に軽減することができる。
【００５１】
また、請求項４または請求項５記載の発明によれば、各サーバの負荷の均等化を一層図ることができる。
【図面の簡単な説明】
【図１】本発明の一実施例における負荷分散装置の概要を表わしたブロック図である。
【図２】本実施例で使用されるサーバ状態テーブルの内容の一例を示した説明図である。
【図３】本実施例のヘルスチェックについての制御と各クライアントとサーバの間の実通信の関係の一例を表わしたタイミング図である。
【図４】図３に示した制御を可能とする負荷分散装置の処理の流れを示した流れ図である。
【図５】負荷分散装置の備えられた通信システムの概要を表わしたシステム構成図である。
【図６】従来の負荷分散装置の構成の一例を示したブロック図である。
【図７】図６に示したサーバ状態テーブルの構成の一例を示した説明図である。
【符号の説明】
１０１　サーバ
１０４　第１の伝送路（サーバ側の伝送路）
１０５　第２の伝送路（クライアント端末側の伝送路）
１０６　クライアント端末
２０１　負荷分散装置
２０２　分散処理部
２０３　ヘルスチェック実行部
２０４　サーバ状態テーブル
２０５　レスポンス監視部
【図１】
2004062246.tif 000003
【図２】
2004062246.tif 000004
【図３】
2004062246.tif 000005
【図４】
2004062246.tif 000006
【図５】
2004062246.tif 000007
【図６】
2004062246.tif 000008
【図７】
2004062246.tif 000009