JP2002342298A - クライアント・サーバ型情報処理システム及び並列ロード・バランス方式 - Google Patents

Abstract

(57)【要約】 【課題】 ロード・バランス機能をクライアントとサー
バに分散した情報処理システム及びクライアントとサー
バに分散したロード・バランス機能によって自律的にサ
ーバ間のロード・バランスをとる並列ロード・バランサ
方式を提供する。 【解決手段】 初期に指定されているサーバに対して
セッション確立要求を送信し、該初期に指定さているサ
ーバからの該セッション確立要求への応答に従ってタス
クを実行するサーバを選択するクライアント・ロード・
バランサを備えるクライアントと、該クライアント・ロ
ード・バランサからのセッション確立要求を受けた時に
複数のサーバのセッション数を比較して該セッション確
立要求への応答を該クライアント・ロード・バランサに
送信すると共にセッション数を管理するサーバ・ロード
・バランサを備えるサーバとによって構成する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、クライアント・サ
ーバ型の情報処理システム及び該クライアント・サーバ
型情報処理システムにおける並列ロード・バランス方式
に係り、特に、ロード・バランス機能をクライアントと
サーバに分散した情報処理システム及びクライアントと
サーバに分散したロード・バランス機能によって自律的
にサーバ間のロード・バランスをとる並列ロード・バラ
ンス方式に関する。

【０００２】近年、情報処理システムの高度化に伴い、
扱うデータや処理機能が複雑化しており、又、システム
利用者の増加に伴ってシステム規模が大規模化されてい
る。こうした状況の下、情報処理システムには、システ
ム利用者からは処理要求に対する応答性能の確保が求め
られ、システム管理者からは高い稼働率が求められてい
る。

【０００３】さて、情報処理システムには複数の形態が
あるが、小規模でも機能的に充実したパソコン又はワー
ク・ステーションが普及している現在ではクライアント
・サーバ型情報処理システムが主流となっている。

【０００４】クライアント・サーバ型の情報処理システ
ムにおいては、各々のクライアントが処理負荷の大きさ
から見て適切なサーバとセッションを確立して所期のタ
スクを実行する。従って、各々のサーバの処理負荷を認
識して複数のサーバ間で処理負荷を均等化することによ
って、情報処理システムの応答性能を確保し、高い稼働
率を確保するするためにロード・バランサが必要であ
る。

【０００５】そして、ロード・バランサの指示に従って
クライアントがサーバとのセッションを確立するのでロ
ード・バランサには高い信頼度が要求される。又、クラ
イアント・サーバ型情報処理システムの特徴はシステム
規模の拡張性にあるので、ロード・バランサの存在が情
報処理システムの拡張性を阻害しないことが肝要であ
る。

【０００６】

【従来の技術】図７は、従来のロード・バランサを適用
した情報処理システムの概念的構成である。

【０００７】図７において、１０１はクライアント、１
０２及び１０２ａはサーバ、１０３はロード・バラン
サ、１０４はネットワークである。尚、図７では単一の
クライアントのみを示しているが、実際の情報処理シス
テムではクライアントも複数存在する。

【０００８】図７の構成の特徴は、クライアント１０１
とサーバ１０２及び１０２ａにはロード・バランス機能
がインストールされておらず、ロード・バランサ１０３
が並列のサーバ１０２及び１０２ａにクライアント１０
１が必要とするタスクを振り分けることである。

【０００９】そして、ロード・バランサ１０３の信頼度
を向上させるために、ロード・バランサ１０３は同じロ
ード・バランス機能を有する運用系１０３−１と待機系
１０３−２を備え、常にロード・バランスのための情報
を運用系１０３−１と待機系１０３−２とで共有して処
理負荷のバランスをとっている。

【００１０】そのロード・バランスの手法には、 ロード・バランサがサーバの処理負荷情報を収集し
て処理負荷の軽いサーバにクライアントが必要とするタ
スクを振り分ける。

【００１１】 ラウンド・ロビン方式によって各サー
バに順にクライアントが要求するタスクを振り分ける。

【００１２】 上記を含めたロード・バランス処理の
結果であるサーバ毎のセッション数をロード・バランサ
が記憶しておき、記憶しているセッション数が少ないサ
ーバにクライアントが要求するタスクを振り分ける。な
どの方法がある。

【００１３】

【発明が解決しようとする課題】しかし、図７の構成に
は下記の問題がある。

【００１４】（１）ロード・バランサが運用系と待機系
を備えて信頼度を向上させているが、運用系と待機系の
双方の機能が停止した時には図７の構成の情報処理シス
テムはロード・バランス機能を失うことになる。

【００１５】（２）クライアントから一意に特定される
ロード・バランサは、クライアントからのセッション確
立要求による処理負荷が集中し、ロード・バランサの処
理能力によって情報処理システムの応答性能及び稼働率
が限定される。

【００１６】（３）実質的に、ロード・バランサの処理
能力の限界までしか情報処理システムの規模を拡張する
ことができない。表面的には、複数の並列なロード・バ
ランサを情報処理システムに収容すればよいかのように
見えるが、複数のロード・バランサの処理負荷を均等化
するロード・バランサが必要になり、情報処理システム
の構成が複雑化する。

【００１７】本発明は、かかる問題点に鑑み、ロード・
バランス機能をクライアントとサーバに分散したクライ
アント・サーバ型情報処理システム及び並列ロード・バ
ランス方式を提供することを目的とする。

【００１８】

【課題を解決するための手段】第一の発明は、予め指定
されている優先順位に従ってサーバに対してセッション
確立要求を送信し、該セッション確立要求を受けたサー
バからの該セッション確立要求への応答にある優先順位
に従ってタスクを実行するサーバを選択するクライアン
ト・ロード・バランサを備えるクライアントと、該クラ
イアント・ロード・バランサからのセッション確立要求
を受けた時に複数のサーバのセッション数を比較して該
セッション確立要求への応答としてセッション確立の優
先順位を該クライアント・ロード・バランサに送信する
と共にセッション数を管理するサーバ・ロード・バラン
サを備えるサーバとによって構成されるクライアント・
サーバ型情報処理システムである。

【００１９】第一の発明によれば、クライアントには初
期に指定されているサーバに対してセッション確立要求
を送信し、該初期に指定されているサーバからの該セッ
ション確立要求への応答に従ってタスクを実行するサー
バを選択するクライアント・ロード・バランサが備えら
れており、サーバには該クライアント・ロード・バラン
サからのセッション確立要求を受けた時に複数のサーバ
のセッション数を比較して該セッション確立要求への応
答を該クライアント・ロード・バランサに送信すると共
にセッション数を管理するサーバ・ロード・バランサが
備えられているので、複数のサーバの処理負荷の現状に
従ってクライアントが必要とするタスクを複数のサーバ
のいずれかに振り分けることができる。しかも、ロード
・バランス機能が分散されているので、情報処理システ
ムのロード・バランス機能の信頼度が向上され、情報処
理システムの拡張をロード・バランス機能が阻害するこ
とがない。

【００２０】第二の発明は、クライアントからのセッシ
ョン確立要求を受けたサーバが、複数のサーバからセッ
ション数を収集して比較してセッション数が少ない順に
サーバ接続優先順位を決定し、該サーバ接続優先順位を
セッション確立要求を発したクライアントに送信し、ク
ライアントは該サーバ接続優先順位に従ってタスクを実
行するサーバを選択する並列ロード・バランス方式であ
る。

【００２１】第二の発明によれば、クライアントからの
セッション確立要求を受けたサーバが、複数のサーバか
らセッション数を収集して比較してセッション数が少な
い順にサーバ接続優先順位を決定し、該サーバ接続優先
順位をセッション確立要求を発したクライアントに送信
し、クライアントは該サーバ接続優先順位に従ってタス
クを実行するサーバを選択するので、複数のサーバのう
ちで処理負荷が最小なサーバにクライアントが必要とす
るタスクを振り分けることができる。

【００２２】第三の発明は、第二の発明の並列ロード・
バランス方式において、上記セッション確立要求の送信
先のサーバが故障している場合には、クライアントは故
障しているサーバの情報を付加したセッション確立要求
を他のサーバに送信し、該故障しているサーバの情報を
付加したセッション確立要求を受けたサーバは該故障し
ているサーバを除いたサーバからセッション数を収集し
て比較してセッション数が少ない順にサーバ接続優先順
位を決定し、該サーバ接続優先順位をセッション確立要
求を発したクライアントに送信し、クライアントは該サ
ーバ接続優先順位に従ってタスクを実行するサーバを選
択する並列ロード・バランス方式である。

【００２３】第三の発明によれば、上記セッション確立
要求の送信先のサーバが故障している場合には、クライ
アントは故障しているサーバの情報を付加したセッショ
ン確立要求を他のサーバに送信し、該故障しているサー
バの情報を付加したセッション確立要求を受けたサーバ
は該故障しているサーバを除いたサーバからセッション
数を収集して比較してセッション数が少ない順にサーバ
接続優先順位を決定し、該サーバ接続優先順位をセッシ
ョン確立要求を発したクライアントに送信し、クライア
ントは該サーバ接続優先順位に従ってタスクを実行する
サーバを選択するので、サーバにおけるロード・バラン
スの処理付加を軽減できる。

【００２４】第四の発明は、クライアントからセッショ
ン確立要求を受けたサーバは、該セッション確立要求は
自己に対する接続要求であるか否か判定し、自己に対す
る接続要求である場合には直ちに該クライアントとの接
続を行ない、自己に対する接続要求ではない場合には第
二の発明又は第三の発明におけるセッション数の比較を
行なって上記サーバ接続優先順位を該クライアントに送
信する並列ロード・バランス方式である。

【００２５】第四の発明によれば、クライアントからセ
ッション確立要求を受けたサーバは、該セッション確立
要求は自己に対する接続要求であるか否か判定し、自己
に対する接続要求である場合には直ちに該クライアント
との接続を行ない、自己に対する接続要求ではない場合
には第二の発明又は第三の発明におけるセッション数の
比較を行なって上記サーバ接続優先順位を該クライアン
トに送信するので、自己に対する接続要求である場合に
はロード・バランスのための処理付加を軽減することが
できる。

【００２６】第五の発明は、複数のサーバは他のサーバ
のセッション数を格納し、クライアントからセッション
確立要求を受けた時には格納しているセッション数を比
較して、自己のセッション数が最小の場合には直ちに該
クライアントとの接続を行なうと共に新セッション数を
自己のサーバ記憶装置に格納し、自己のセッション数が
最小ではない場合には該クライアントにサーバ接続優先
順位を送信する並列ロード・バランス方式である。

【００２７】第五の発明によれば、複数のサーバは他の
サーバのセッション数を格納し、クライアントからセッ
ション確立要求を受けた時には格納しているセッション
数を比較して、自己のセッション数が最小の場合には直
ちに該クライアントとの接続を行なうと共に新セッショ
ン数自己のサーバ記憶装置に格納し、自己のセッション
数が最小ではない場合には該クライアントにサーバ接続
優先順位を送信するので、サーバが行なうセッション数
の比較のための処理負荷を大幅に軽減することができ
る。

【００２８】

【発明の実施の形態】以降、図面を用いて本発明の技術
を詳細に説明する。

【００２９】図１は、本発明のクライアント・サーバ型
情報処理システムの構成である。

【００３０】図１において、１はクライアントで、ロー
ド・バランス機能に関係する物として、クライアントロ
ード・バランサ１１、クライアント記憶装置１２及びサ
ーバとの通信を行なうクライアント通信装置１３を備え
ている。

【００３１】ここで、クライアント・ロード・バランサ
１１は、サーバにセッション確立要求を行なう接続装置
１１１及びクライアント記憶装置１２に情報を格納し、
クライアント記憶装置１２に格納した情報を参照するサ
ーバ情報管理装置１１２を備えている。

【００３２】又、クライアント記憶装置１２には、ネッ
トワーク３に収容されているサーバのＩＰアドレス、セ
ッションを確立しているサーバのＩＰアドレス、故障し
ているサーバのＩＰアドレス、サーバ接続優先順位など
が格納可能である。尚、サーバ接続優先順位はクライア
ント２又は２ａがセッション確立要求を行なう度毎にセ
ッション確立要求を受けたサーバによって更新されるも
のであるが、情報処理システムの起動時には人的又は自
動的にインストールされたサーバ接続優先順位が格納さ
れている。

【００３３】２及び２ａはサーバで、ロード・バランス
機能に関係する物として、サーバ・ロード・バランサ２
１、サーバ記憶装置２２、クライアント又は他のサーバ
との通信を行なうサーバ通信装置２３、セッション確立
装置２４及びセッション切断装置２５を備えている。即
ち、全てのサーバのロード・バランス機能は対等であ
る。これが「並列ロード・バランス方式」の所以であ
る。

【００３４】ここで、サーバ・ロード・バランサ２１
は、クライアント１からのセッション確立要求に対応し
て他のサーバとのセッション数の比較を行ない、必要に
応じてクライアント１からのセッション確立要求に対応
して自己が属するサーバとのセッション確立の制御を行
なうセッション数判定装置２１１、自己が属するサーバ
でセッションが確立した時に現在のセッション数をサー
バ記憶装置２２に格納するセッション確立記録装置２１
２及び自己が属するサーバでセッションが切断された時
に現在のセッション数をサーバ記憶装置２２に記録する
セッション切断記録装置２１３を備えている。

【００３５】又、サーバ記憶装置２２には、自己が属す
るサーバで確立しているセッション数、他のサーバのＩ
Ｐアドレスや、必要に応じて他のサーバのセッション数
などが格納可能である。

【００３６】更に、セッション確立装置２４は、セッシ
ョン確立要求をサーバ通信装置２３を介して受けて、セ
ッションを確立すべきサーバを決定する必要がある時に
はその旨セッション数比較装置２１１に依頼し、自己が
属するサーバでセッションを確立する場合にはセッショ
ンを確立すると共にセッション確立記録装置２１２にサ
ーバ記憶装置２２へのセッション数の更新を依頼する。

【００３７】尚、本質的には区別する必要はないが、理
解しやすくするために、クライアントがセッションを確
立すべきサーバの決定依頼する場合を「セッション確立
要求」といい、クライアントがサーバからの優先順位の
指定に基づいてセッションを確立依頼をする場合を「再
セッション確立要求」ということにする。

【００３８】即ち、セッション確立装置２４の機能の説
明で「セッションを確立すべきサーバを決定する必要が
ある場合」とは、クライアントからセッション確立要求
を受けた時のことであり、「自己が属するサーバでセッ
ションを確立する場合」とは再セッション確立要求を受
けた時のことである。

【００３９】更に、セッション切断装置２５は、クライ
アントからのセッション切断要求をサーバ通信装置２３
を介して受けて、セッションを切断すると共にセッショ
ン切断記録装置２１３にサーバ記憶装置２２へのセッシ
ョン数の更新を依頼する。

【００４０】３はクライアント１、サーバ２及びサーバ
２ａを収容するネットワークである。尚、ネットワーク
の形態は図１の如きリング型には限定されないが、リン
グ型ネットワーク以外はバス型ネットワークが好まし
い。何故なら、各サーバとクライアントをスター型ネッ
トワークで結ぶとネットワークが輻輳して、所謂ＷＡＮ
（Wide Area Network)においてはネットワークの構成が
実質的に不可能になるからである。

【００４１】図１の構成のおおまかな動作は次の通りで
ある。即ち、クライアント１は指定されている優先順位
に従ってサーバに対してセッション確立要求を送信し、
該セッション確立要求を受けたサーバからの該セッショ
ン確立要求への応答にある優先順位に従ってタスクを実
行するサーバに対して再セッション確立要求を送信して
セッションを確立し、サーバ２又はサーバ２ａはクライ
アント１からのセッション確立要求を受けた時に複数の
サーバからセッション数を収集し、収集したセッション
数を比較して該セッション確立要求への応答であるサー
バ接続優先順位を該クライアント１に送信し、再セッシ
ョン確立要求を受けたサーバはセッションを確立してセ
ッション数を管理する。

【００４２】上記クライアント・サーバ型情報処理シス
テムによれば、クライアントは初期に指定されているサ
ーバに対してセッション確立要求を送信し、該初期に指
定されているサーバからの該セッション確立要求への応
答に従ってタスクを実行するサーバを選択するクライア
ント・ロード・バランサが備えられており、サーバには
該クライアント・ロード・バランサからのセッション確
立要求を受けた時に並列のサーバのセッション数を比較
して該セッション確立要求への応答を該クライアント・
ロード・バランサに送信すると共にセッション数を管理
するサーバ・ロード・バランサが備えられているので、
複数のサーバの処理負荷の現状に従ってクライアントが
必要とするタスクを複数のサーバのいずれかに振り分け
ることができる。

【００４３】しかも、ロード・バランス機能が分散され
ているので、情報処理システムのロード・バランス機能
の信頼度が向上され、又、情報処理システムの拡張をロ
ード・バランス機能が阻害することがない。

【００４４】以降、図１の構成におけるロード・バラン
ス処理についてフローチャートを用いて詳細に説明す
る。

【００４５】図２は、セッション確立要求に対する処理
（その１）である。以降、図２の符号に沿って説明す
る。尚、図２以降のフローチャートにおいては、クライ
アントの動作に対する符号は「Ｃｎ（ｎは正の整数）」
と表現し、サーバの動作に対する符号は「Ｓｍ（ｍは正
の整数）」と表現して、クライアントの動作とサーバの
動作を理解しやすくする。

【００４６】Ｃ１．クライアント・ロード・バランサは
セッション確立要求に先立ってクライアント記憶装置に
格納されているセッション確立要求要求先のサーバの優
先順位であるサーバ接続優先順位を参照する。

【００４７】尚、サーバ接続優先順位はクライアントが
セッション確立要求を行なう度に当該セッション確立要
求を受けたサーバによって更新されるものであるが、ク
ライアント・サーバ型情報処理システムの起動時には人
的又は自動的にインストールされる。従って、クライア
ントロード・バランサは何時でもセッション確立要求に
先立ってクライアント記憶装置に格納されているサーバ
接続優先順位を参照することができる。

【００４８】Ｃ２．クライアント・ロード・バランサは
サーバ接続優先順位において最も優先順位が高いサーバ
に対してセッション確立要求を送信して、 Ｃ３．当該サーバからの応答を待機する。

【００４９】Ｓ１．サーバ接続優先順位に指定されてい
る最優先サーバはクライアントからのセッション確立要
求を受信する。

【００５０】Ｓ２．当該サーバのサーバ・ロード・バラ
ンサはサーバ記憶装置から自己が属するサーバの現状の
セッション数を参照し、 Ｓ３．当該サーバのサーバ・ロード・バランサはサーバ
記憶装置からネットワーク内の他のサーバの情報、例え
ばＩＰアドレスを参照する。

【００５１】Ｓ４．参照したＩＰアドレスに従って、他
のサーバに対して現状のセッション数の報告を求める。

【００５２】Ｓ５．全てのサーバに対してセッション数
を要求したか否か判定する。

【００５３】全てのサーバにセッション数を要求してい
ない場合（Ｎｏ）には、ステップＳ４及びステップＳ５
を繰り返す。

【００５４】Ｓ１０１．セッション数の報告を要求され
たサーバは、サーバ・ロード・バランサがセッション数
要求を受信する。

【００５５】Ｓ１０２．当該サーバ・ロード・バランサ
はサーバ記憶装置に格納されている、自己が属するサー
バの現状のセッション数を参照する。

【００５６】Ｓ１０３．セッション数要求を送信してき
たサーバに対して現状のセッション数を回答する。

【００５７】これで、セッション数要求を受信したサー
バは一連の処理を終了する。

【００５８】Ｓ６．セッション数要求を送信したサーバ
は、各々のサーバからの応答を受信する。

【００５９】尚、図２においては、ステップＳ５で全て
のサーバにセッション数要求を送信したと判定した場合
に各々のサーバからの応答を受信するとしているが、こ
れは、フローチャートの表現の簡略化のためであり、一
般的にはセッション数の要求を行なっている間にも応答
を受信することができる。これは、以降のフローチャー
トにおいても同様である。

【００６０】Ｓ７．全てのサーバからセッション数の応
答を受信したか否か判定する。

【００６１】全てのサーバから応答を受信していない場
合（Ｎｏ）には、ステップＳ６及びステップＳ７を繰り
返す。

【００６２】Ｓ８．ステップＳ７で、全てのサーバから
応答を受信したと判定した場合（Ｙｅｓ）には、サーバ
・ロード・バランサは自己が属するサーバのセッション
数も含めて全てのサーバのセッション数を比較する。

【００６３】Ｓ９．セッション数の多少に従って、セッ
ション確立要求を送信してきたクライアントに対するサ
ーバ接続優先順位を決定する。

【００６４】Ｓ１０．サーバ・ロード・バランサはセッ
ション確立要求を送信してきたクライアントに対してサ
ーバ接続優先順位を通知する。

【００６５】これで、セッション確立要求を受信したサ
ーバは処理を終了する。

【００６６】Ｃ４．サーバからの応答を待機していたク
ライアント・ロード・バランサはサーバからの応答を受
信する。

【００６７】Ｃ５．受信したサーバ接続優先順位を次に
セッション確立要求を送信する時の参照情報としてクラ
イアント記憶装置に格納する。

【００６８】Ｃ６．受信したサーバ接続優先順位におい
て最優先とされていたサーバに対して再セッション確立
要求を送信して、接続を要求する。

【００６９】これで、セッション確立要求を送信したク
ライアントは処理を終了する。

【００７０】セッション確立要求に対応して上記の処理
を行なうことにより、クライアントからのセッション確
立要求を受けたサーバが、複数のサーバからセッション
数を収集して比較してセッション数が少ない順にサーバ
接続優先順位を決定し、該サーバ接続優先順位をセッシ
ョン確立要求を発したクライアントに送信し、クライア
ントは該サーバ接続優先順位に従ってタスクを実行する
サーバを選択するので、複数のサーバのうちで処理負荷
が最小なサーバにクライアントが必要とするタスクを振
り分けることができる。

【００７１】図３は、セッション確立要求に対する処理
（その２）である。以降、図３の符号に沿って説明す
る。尚、図２による説明と類似の処理が多いが、図２と
異なる処理だけの説明では理解しにくいので、重複をい
とわず全てのステップについて説明する。これは、以降
全てのフローチャートにおいて同様である。

【００７２】Ｃ１１．クライアント・ロード・バランサ
はセッション確立要求に先立ってクライアント記憶装置
に格納されているセッション確立要求要求先のサーバの
優先順位であるサーバ接続優先順位を参照する。

【００７３】尚、サーバ接続優先順位はクライアントが
セッション確立要求を行なう度に当該セッション確立要
求を受けたサーバによって更新されるものであるが、ク
ライアント・サーバ型情報処理システムの起動時には人
的又は自動的にインストールされている。

【００７４】Ｃ１２．クライアント・ロード・バランサ
はサーバ接続優先順位において最も優先順位が高いサー
バに対してセッション確立要求を送信して、サーバから
の応答を待機する。

【００７５】Ｃ１３．所定時間サーバからの応答がない
場合には当該サーバが故障しているものと判定する。

【００７６】当該サーバが故障していない場合（Ｎｏ）
には後でサーバからの応答を受信できる。

【００７７】Ｃ１４．ステップＣ１３で、当該サーバが
故障していると判定した場合（Ｙｅｓ）には、ステップ
Ｃ１１で取得したサーバ接続優先順位を参照して次の優
先順位のサーバを選択する。

【００７８】Ｃ１５．先に故障していると判定したサー
バの情報、例えばＩＰアドレスを付して次の優先順位の
サーバに対してセッション確立要求を送信する。

【００７９】Ｃ１６．全てのサーバにセッション確立要
求を送信したか否か判定する。

【００８０】全てのサーバにセッション確立要求を送信
していない場合（Ｎｏ）には、ステップＣ１４にジャン
プして、サーバからの応答が得られるまでステップＣ１
４乃至ステップＣ１６の処理を繰り返す。

【００８１】全てのサーバにセッション確立要求を送信
した場合（Ｙｅｓ）には、全てのサーバにセッション確
立要求を送信したにもかかわらず応答がなかったので、
一連の処理を終了する。

【００８２】Ｓ２１．クライアントにおけるステップＣ
１４乃至ステップＣ１６の間に送信されたセッション確
立要求が特定のサーバで受信されたものとする。

【００８３】Ｓ２２．当該サーバのサーバ・ロード・バ
ランサはサーバ記憶装置によって自己が属するサーバの
現状のセッション数を参照する。

【００８４】Ｓ２３．当該サーバのサーバ・ロード・バ
ランサはサーバ記憶装置からネットワーク内の他のサー
バの情報、例えばＩＰアドレスを参照する。

【００８５】Ｓ２４．受信したセッション確立要求には
故障しているサーバの情報が付されているので、故障サ
ーバを除いてセッション数の報告求める対象サーバを決
定する。

【００８６】Ｓ２５．ＩＰアドレスに従って、対象サー
バに対して現状のセッション数の報告を求める。

【００８７】Ｓ２６．全ての対象サーバに対してセッシ
ョン数を要求したか否か判定する。

【００８８】全ての対象サーバにセッション数を要求し
ていない場合（Ｎｏ）にはステップＳ２５及びステップ
Ｓ２６を繰り返す。

【００８９】Ｓ１１１．セッション数の報告を要求され
たサーバは、サーバ・ロード・バランサがセッション数
要求を受信する。

【００９０】Ｓ１１２．当該サーバ・ロード・バランサ
はサーバ記憶装置に格納されている自己が属するサーバ
の現状のセッション数を参照する。

【００９１】Ｓ１１３．セッション数要求を送信してき
たサーバに対して現状のセッション数を回答する。

【００９２】これで、セッション数要求を受信したサー
バは一連の処理を終了する。

【００９３】Ｓ２７．セッション数要求を送信したサー
バは、各々のサーバからの応答を受信する。

【００９４】Ｓ２８．全てのサーバからセッション数の
応答を受信したか否か判定する。

【００９５】全てのサーバから応答を受信していない場
合（Ｎｏ）には、ステップＣ２７及びステップＳ２８を
繰り返す。

【００９６】Ｓ２９．ステップＳ２８で、全てのサーバ
から応答を受信したと判定した場合（Ｙｅｓ）には、サ
ーバ・ロード・バランサは自己が属するサーバのセッシ
ョン数も含めて全ての対象サーバのセッション数を比較
する。

【００９７】Ｓ３０．セッション数の多少に従って、セ
ッション確立要求を送信してきたクライアントに対する
サーバ接続優先順位を決定する。

【００９８】Ｓ３１．サーバ・ロード・バランサはセッ
ション確立要求を送信してきたクライアントに対してサ
ーバ接続優先順位を通知する。

【００９９】これで、セッション確立要求を受信したサ
ーバは処理を終了する。

【０１００】Ｃ１７．サーバからの応答を待機していた
クライアント・ロード・バランサはサーバからの応答を
受信する。

【０１０１】Ｃ１８．受信したサーバ接続優先順位を次
にセッション確立要求を送信する時の参照情報としてク
ライアント記憶装置に格納する。

【０１０２】Ｃ１９．受信したサーバ接続優先順位にお
いて最優先とされていたサーバに対して再セッション確
立要求を送信して、接続を要求する。

【０１０３】これで、セッション確立要求を送信したク
ライアントは処理を終了する。

【０１０４】上記処理によって、セッション確立要求の
送信先のサーバが故障している場合には、クライアント
は故障しているサーバの情報を付加したセッション確立
要求を他のサーバに送信し、該故障しているサーバの情
報を付加したセッション確立要求を受けたサーバは該故
障しているサーバを除いたサーバからセッション数を収
集して比較してセッション数が少ない順にサーバ接続優
先順位を決定し、該サーバ接続優先順位をセッション確
立要求を発したクライアントに送信し、クライアントは
該サーバ接続優先順位に従ってタスクを実行するサーバ
を選択するので、サーバにおけるロード・バランスの処
理負荷を軽減できる。

【０１０５】図４は、セッション確立要求に対する処理
（その３）である。以降、図４の符号に沿って説明す
る。尚、図２及び図３によってセッション確立要求時の
クライアントとサーバの関係を十分に説明しているの
で、ここではクライアントの処理は図示を省略してい
る。

【０１０６】Ｓ４１．クライアントからのセッション確
立要求又は再セッション確立要求を受信する。

【０１０７】セッションを確立すべきサーバを決定する
ためのセッション確立要求とセッションを確立すること
が決定された後の再セッション確立要求に搭載されてい
る情報は本質的には同じであるが、再セッション確立要
求においてはその旨のフラグが立っている。従って、該
フラグを参照すればセッション確立要求か再セッション
確立要求かを判別することができる。

【０１０８】Ｓ４２．ステップＳ４１で、セッション確
立要求又は再セッション確立要求を受信したサーバにお
いて、セッション確立装置は上記フラグを確認して受信
したのはセッション確立要求か再セッション確立要求か
を判別して、自己が属するサーバが接続先サーバである
か否かを判定する。

【０１０９】自己が属するサーバが接続先である場合
（Ｙｅｓ）、即ち、受信したのが再セッション確立要求
である場合にはステップＳ５２にジャンプする。

【０１１０】Ｓ４３．ステップＳ４２で、自己が属する
サーバが接続先でないと判定された場合（Ｎｏ）は、セ
ッション確立装置はサーバ・ロード・バランサにセッシ
ョンを確立すべきサーバの決定を依頼する。従って、サ
ーバ・ロード・バランサはサーバ記憶装置から自己が属
するサーバの現状のセッション数を参照し、 Ｓ４４．サーバ記憶装置からネットワーク内の他のサー
バの情報、例えばＩＰアドレスを参照する。

【０１１１】Ｓ４５．ＩＰアドレスに従って、他のサー
バに対して現状のセッション数の報告を求める。

【０１１２】Ｓ４６．全てのサーバに対してセッション
数を要求したか否か判定する。

【０１１３】全てのサーバにセッション数を要求してい
ない場合（Ｎｏ）にはステップＳ４５及びステップＳ４
６を繰り返す。

【０１１４】Ｓ１２１．セッション数の報告を要求され
たサーバは、サーバ・ロード・バランサがセッション数
要求を受信する。

【０１１５】Ｓ１２２．当該サーバ・ロード・バランサ
はサーバ記憶装置に格納されている自己が属するサーバ
の現状のセッション数を参照する。

【０１１６】Ｓ１２３．セッション数要求を送信してき
たサーバに対して現状のセッション数を回答する。

【０１１７】これで、セッション数要求を受信したサー
バは一連の処理を終了する。

【０１１８】Ｓ４７．セッション数要求を送信したサー
バは、各々のサーバからの応答を受信する。

【０１１９】Ｓ４８．全てのサーバからセッション数の
応答を受信したか否か判定する。

【０１２０】全てのサーバから応答を受信していない場
合（Ｎｏ）には、ステップＳ４７及びステップＳ４８を
繰り返す。

【０１２１】Ｓ４９．ステップＳ４８で、全てのサーバ
から応答を受信したと判定した場合（Ｙｅｓ）には、サ
ーバ・ロード・バランサは自己が属するサーバのセッシ
ョン数も含めて全てのサーバのセッション数を比較す
る。

【０１２２】Ｓ５０．セッション数の多少に従って、セ
ッション確立要求を送信してきたクライアントに対する
サーバ接続優先順位を決定する。

【０１２３】Ｓ５１．上記サーバ接続優先順位を参照し
て、自己が属するサーバが接続先になるか否かを判定す
る。

【０１２４】Ｓ５２．ステップＳ５１で、自己が属する
サーバが接続先であると判定した場合（Ｙｅｓ）と、ス
テップＳ４２で、自己が属するサーバが接続先であると
判定した場合（Ｙｅｓ）には、セッション確立装置が当
該クライアントとのセッションを確立する。

【０１２５】Ｓ５３．セッションが確立された後、サー
バ・ロード・バランサはサーバ記憶装置に新セッション
数を格納して、一連の処理を終了する。

【０１２６】Ｓ５４．一方、ステップＳ５１で、自己が
属するサーバが接続先でないと判定した場合（Ｎｏ）に
は、サーバ・ロード・バランサはセッション確立要求を
送信してきたクライアントに対してサーバ接続優先順位
を通知して、一連の処理を終了する。

【０１２７】ところで、ステップＳ４６、ステップＳ４
８では「全てのサーバ」としているが、セッション確立
要求に対する処理（その２）の如く「故障しているサー
バを除く全てのサーバ」としてもよい。

【０１２８】上記処理によって、クライアントからセッ
ション確立要求を受けたサーバは、該セッション確立要
求は自己に対する接続要求であるか否か判定し、自己に
対する接続要求である場合には直ちに該クライアントと
の接続を行ない、自己に対する接続要求ではない場合に
は第二の発明又は第三の発明におけるセッション数の比
較を行なって上記サーバ接続優先順位を該クライアント
に送信するので、自己に対する接続要求である場合には
ロード・バランスのための処理負荷を軽減することがで
きる。

【０１２９】図５は、セッション確立要求に対する処理
（その４）である。以降、図５の符号に沿って説明す
る。

【０１３０】ここで、セッション確立要求に対する処理
（その４）に対応するために、各サーバのサーバ・ロー
ド・バランサは他サーバにセッション数を適宜送信する
機能と他サーバからセッション数を受信する機能を備え
ている。

【０１３１】Ｓ６１．サーバ・ロード・バランサは他サ
ーバからセッション数情報を受信する。

【０１３２】Ｓ６２．受信したセッション数をサーバ記
憶装置に格納する。

【０１３３】Ｓ６３．クライアントからセッション確立
要求を受信する。

【０１３４】Ｓ６４．サーバ・ロード・バランサはサー
バ記憶装置に格納されている全サーバのセッション数を
参照して、Ｓ６５．セッション数を比較する。

【０１３５】Ｓ６６．自己が属するサーバのセッション
数が最小か否か判定する。

【０１３６】Ｓ６７．ステップＳ６６で、自己が属する
サーバのセッション数が最小であると判定した時には、
その旨セッション確立装置に通知し、セッション確立装
置はセッションを確立する。

【０１３７】Ｓ６８．サーバ・ロード・バランサはサー
バ記憶装置に新セッション数を格納する。

【０１３８】Ｓ６９．ステップＳ６６で、自己が属する
サーバのセッション数が最小でないと判定した場合（Ｎ
ｏ）には、サーバ・ロード・バランサはサーバ接続優先
順位をセッション確立要求を送信してきたクライアント
に送信する。

【０１３９】以上で一連の処理を終了する。

【０１４０】上記処理を行なうことにより、複数のサー
バは他のサーバのセッション数を格納し、クライアント
からセッション確立要求を受けた時には格納しているセ
ッション数を比較して、自己のセッション数が最少の場
合には直ちに該クライアントとの接続を行なうと共に新
セッション数を他のサーバに送信し、自己のセッション
数が最少ではない場合には該クライアントにサーバ接続
優先順位を送信するので、サーバが行なうセッション数
の比較のための処理負荷を大幅に軽減することができ
る。

【０１４１】図６は、セッション切断要求に対する処理
である。以降、図６の符号に沿って説明する。

【０１４２】Ｓ７１．セッション切断装置はクライアン
トからセッション切断要求を受信する。

【０１４３】Ｓ７２．セッション切断装置はサーバ・ロ
ード・バランサに新セッション数の格納を依頼し、依頼
を受けたサーバ・ロード・バランサはサーバ記憶装置に
新セッション数を格納する。

【０１４４】以上で一連の処理を終了する。

【０１４５】上記処理によって各サーバは最新のセッシ
ョン数を管理することができる。

【０１４６】（付記１） 初期に指定さているサーバに
対してセッション確立要求を送信し、該初期に指定さて
いるサーバからの該セッション確立要求への応答に従っ
てタスクを実行するサーバを選択するクライアント・ロ
ード・バランサを備えるクライアントと、該クライアン
ト・ロード・バランサからのセッション確立要求を受け
た時に複数のサーバのセッション数を比較して該セッシ
ョン確立要求への応答を該クライアント・ロード・バラ
ンサに送信すると共にセッション数を管理するサーバ・
ロード・バランサを備えるサーバとによって構成される
ことを特徴とするクライアント・サーバ型情報処理シス
テム。 （付記２） クライアントからのセッション確立要求を
受けたサーバが、 複数のサーバからセッション数を収
集して比較してセッション数が少ない順にサーバ接続優
先順位を決定し、該サーバ接続優先順位をセッション確
立要求を発したクライアントに送信し、クライアント
は、該サーバ接続優先順位に従ってタスクを実行するサ
ーバを選択することを特徴とする並列ロード・バランス
方式。 （付記３） 請求項２記載の並列ロード・バランス方式
において、上記セッション確立要求の送信先のサーバが
故障している場合には、クライアントは故障しているサ
ーバの情報を付加したセッション確立要求を他のサーバ
に送信し、該故障しているサーバの情報を付加したセッ
ション確立要求を受けたサーバは該故障しているサーバ
を除いたサーバからセッション数を収集して比較してセ
ッション数が少ない順にサーバ接続優先順位を決定し、
該サーバ接続優先順位をセッション確立要求を発したク
ライアントに送信し、クライアントは該サーバ接続優先
順位に従ってタスクを実行するサーバを選択することを
特徴とする並列ロード・バランス方式。 （付記４） クライアントからセッション確立要求を受
けたサーバは、該セッション確立要求は自己に対する接
続要求であるか否か判定し、自己に対する接続要求であ
る場合には直ちに該クライアントとの接続を行ない、自
己に対する接続要求ではない場合には請求項２又は請求
項３のいずれかに記載のセッション数の比較を行なって
サーバ接続優先順位を該クライアントに送信することを
特徴とする並列ロード・バランス方式。 （付記５） 複数のサーバは他のサーバのセッション数
を格納し、クライアントからセッション確立要求を受け
た時には格納しているセッション数を比較して、自己の
セッション数が最少の場合には直ちに該クライアントと
の接続を行なうと共に新セッション数を自己のサーバ記
憶装置に格納し、自己のセッション数が最少ではない場
合には該クライアントにサーバ接続優先順位を送信する
ことを特徴とする並列ロード・バランス方式。 （付記６） 付記１記載のクライアント・サーバ型情報
処理システムにおいて、複数のサーバに、クライアント
との接続が完了した時にセッション数を更新し、クライ
アントとの接続を切断した時にセッション数を更新する
構成を備えることを特徴とするクライアント・サーバ型
情報処理システム。

【０１４７】

【発明の効果】以上詳述した如く、本発明により、ロー
ド・バランス機能をクライアントとサーバに分散した情
報処理システム及びクライアントとサーバに分散したロ
ード・バランス機能によって自律的にサーバ間のロード
・バランスをとる並列ロード・バランス方式に関する。
ロード・バランス機能をクライアントとサーバに分散し
た情報処理システム及びクライアントとサーバに分散し
たロード・バランス機能によって自律的にサーバ間のロ
ード・バランスをとる並列ロード・バランス方式を実現
することができる。

【０１４８】即ち、第一の発明によれば、クライアント
には初期に指定さているサーバに対してセッション確立
要求を送信し、該初期に指定さているサーバからの該セ
ッション確立要求への応答に従ってタスクを実行するサ
ーバを選択するクライアント・ロード・バランサが備え
られており、サーバには該クライアント・ロード・バラ
ンサからのセッション確立要求を受けた時に並列のサー
バのセッション数を比較して該セッション確立要求への
応答を該クライアント・ロード・バランサに送信すると
共にセッション数を管理するサーバ・ロード・バランサ
が備えられているので、複数のサーバの処理負荷の現状
に従ってクライアントが必要とするタスクを複数のサー
バのいずれかに振り分けることができる。しかも、ロー
ド・バランス機能が分散されているので、情報処理シス
テムのロード・バランス機能の信頼度が向上され、情報
処理システムの拡張をロード・バランス機能が阻害する
ことがない。

【０１４９】又、第二の発明によれば、クライアントか
らのセッション確立要求を受けたサーバが、複数のサー
バからセッション数を収集して比較してセッション数が
少ない順にサーバ接続優先順位を決定し、該サーバ接続
優先順位をセッション確立要求を発したクライアントに
送信し、クライアントは該サーバ接続優先順位に従って
タスクを実行するサーバを選択するので、複数のサーバ
のうちで処理負荷が最少なサーバにクライアントが必要
とするタスクを振り分けることができる。

【０１５０】又、第三の発明によれば、上記セッション
確立要求の送信先のサーバが故障している場合には、ク
ライアントは故障しているサーバの情報を付加したセッ
ション確立要求を他のサーバに送信し、該故障している
サーバの情報を付加したセッション確立要求を受けたサ
ーバは該故障しているサーバを除いたサーバからセッシ
ョン数を収集して比較してセッション数が少ない順にサ
ーバ接続優先順位を決定し、該サーバ接続優先順位をセ
ッション確立要求を発したクライアントに送信し、クラ
イアントは該サーバ接続優先順位に従ってタスクを実行
するサーバを選択するので、サーバにおけるロード・バ
ランスの処理付加を軽減できる。

【０１５１】第四の発明によれば、クライアントからセ
ッション確立要求を受けたサーバは、該セッション確立
要求は自己に対する接続要求であるか否か判定し、自己
に対する接続要求である場合には直ちに該クライアント
との接続を行ない、自己に対する接続要求ではない場合
には第二の発明又は第三の発明におけるセッション数の
比較を行なって上記サーバ接続優先順位を該クライアン
トに送信するので、自己に対する接続要求である場合に
はロード・バランスのための処理付加を軽減することが
できる。

【０１５２】更に、第五の発明によれば、複数のサーバ
は他のサーバのセッション数を格納し、クライアントか
らセッション確立要求を受けた時には格納しているセッ
ション数を比較して、自己のセッション数が最少の場合
には直ちに該クライアントとの接続を行なうと共に新セ
ッション数を他のサーバに送信し、自己のセッション数
が最少ではない場合には該クライアントにサーバ接続優
先順位を送信するので、サーバが行なうセッション数の
比較のための処理負荷を大幅に軽減することができる。

【図面の簡単な説明】

【図１】 本発明のクライアント・サーバ型情報処理シ
ステムの構成。

【図２】 セッション確立要求に対する処理（その
１）。

【図３】 セッション確立要求に対する処理（その
２）。

【図４】 セッション確立要求に対する処理（その
３）。

【図５】 セッション確立要求に対する処理（その
４）。

【図６】 セッション切断要求に対する処理。

【図７】 従来のロード・バランサを適用した情報処理
システムの概念的構成。

【符号の説明】

１ クライアント ２ サーバ ２ａ サーバ ３ ネットワーク １１ クライアント・ロード・バランサ １２ クライアント記憶装置 １３ クライアント通信装置 ２１ サーバ・ロード・バランサ ２２ サーバ記憶装置 ２３ サーバ通信装置 ２４ セッション確立装置 ２５ セッション切断装置 １１１ 接続装置 １１２ サーバ情報管理装置 ２１１ セッション数判定装置 ２１２ セッション確立記録装置 １０１ クライアント １０２ サーバ １０２ａ サーバ １０３ ロード・バランサ １０４ ネットワーク

───────────────────────────────────────────────────── フロントページの続き (72)発明者 藤井 賢一 北海道札幌市厚別区下野幌テクノパーク１ 丁目１番５号 富士通北海道通信システム 株式会社内 (72)発明者 渡邊 博実 北海道札幌市厚別区下野幌テクノパーク１ 丁目１番５号 富士通北海道通信システム 株式会社内 (72)発明者 在原 佳典 北海道札幌市厚別区下野幌テクノパーク１ 丁目１番５号 富士通北海道通信システム 株式会社内 Ｆターム(参考） 5B045 BB47 BB49 GG01 GG04 JJ08 5B089 GA11 GA21 KA06 KA12 KC23 KC39 KG03 MA03

Claims (5)

【特許請求の範囲】
1. 【請求項１】 予め指定されている優先順位に従ってサ
   ーバに対してセッション確立要求を送信し、該セッショ
   ン確立要求を受けたサーバからの応答にある優先順位に
   従ってタスクを実行するサーバを選択するクライアント
   ・ロード・バランサを備えるクライアントと、 該クライアント・ロード・バランサからのセッション確
   立要求を受けた時に複数のサーバのセッション数を比較
   して該セッション確立要求への応答としてセッション確
   立の優先順位を該クライアント・ロード・バランサに送
   信すると共に、セッション数を管理するサーバ・ロード
   ・バランサを備えるサーバとによって構成されることを
   特徴とするクライアント・サーバ型情報処理システム。
2. 【請求項２】 クライアントからのセッション確立要求
   を受けたサーバが、 複数のサーバからセッション数を収集、比較してセッシ
   ョン数が少ない順にサーバ接続優先順位を決定し、 該サーバ接続優先順位をセッション確立要求を発したク
   ライアントに送信し、 クライアントは、 該サーバ接続優先順位に従ってタスクを実行するサーバ
   を選択することを特徴とする並列ロード・バランス方
   式。
3. 【請求項３】 請求項２記載の並列ロード・バランス方
   式において、 上記セッション確立要求の送信先のサーバが故障してい
   る場合には、クライアントは故障しているサーバの情報
   を付加したセッション確立要求を他のサーバに送信し、 該故障しているサーバの情報を付加したセッション確立
   要求を受けたサーバは該故障しているサーバを除いたサ
   ーバからセッション数を収集、比較してセッション数が
   少ない順にサーバ接続優先順位を決定し、 該サーバ接続優先順位をセッション確立要求を発したク
   ライアントに送信し、 クライアントは該サーバ接続優先順位に従ってタスクを
   実行するサーバを選択することを特徴とする並列ロード
   ・バランス方式。
4. 【請求項４】 クライアントからセッション確立要求を
   受けたサーバは、 該セッション確立要求は自己に対する接続要求であるか
   否か判定し、 自己に対する接続要求である場合には直ちに該クライア
   ントとの接続を行ない、 自己に対する接続要求ではない場合には請求項２又は請
   求項３のいずれかに記載のセッション数の比較を行なっ
   て、 サーバ接続優先順位を該クライアントに送信することを
   特徴とする並列ロード・バランス方式。
5. 【請求項５】 複数のサーバは他のサーバのセッション
   数を格納し、 クライアントからセッション確立要求を受けた時には格
   納しているセッション数を比較して、 自己のセッション数が最小の場合には直ちに該クライア
   ントとの接続を行なうと共に新セッション数を自己のサ
   ーバ記憶装置に格納し、 自己のセッション数が最小ではない場合には該クライア
   ントにサーバ接続優先順位を送信することを特徴とする
   並列ロード・バランス方式。