JP2004005360A

JP2004005360A - サーバ負荷分散システム

Info

Publication number: JP2004005360A
Application number: JP2002295556A
Authority: JP
Inventors: Satoshi Kikuchi; 菊地　聡; Noriyasu Kotaki; 小瀧　伯泰
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2002-04-10
Filing date: 2002-10-09
Publication date: 2004-01-08

Abstract

【課題】各サーバの負荷を均等化可能なサーバ負荷分散方法を提供する。
【解決手段】複数のサーバに関する情報をサーバプールとして定義するサーバプール定義部と、サーバプール定義情報及び各サーバの処理状況を記憶する処理状況記憶部と、クライアントから受信した一連のリクエストを分解し、各リクエストの受信時点で最も負荷の少ないサーバへ送信するリクエスト振分部とを備える。
【選択図】　図１

Description

【０００１】
【発明の属する技術分野】
本発明は、クライアントからのリクエストを何れかのサーバへ振り分ける負荷分散装置に関する。
【０００２】
【従来の技術】
企業内及び企業間の円滑なコミュニケーションを実現するために、ＬＡＮ（Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）等のネットワークを介してＰＣ（Ｐｅｒｓｏｎａｌ　Ｃｏｍｐｕｔｅｒ）等の情報処理装置で作成した文書を送受信する電子メールシステムの普及が進んでおり、受信者のメールアドレスを検索する機能、所謂電子電話帳機能として、ＣＣＩＴＴ勧告のＸ．５００（ＩＳＯ９５９４）等に代表されるディレクトリサービスが利用され始めている。
【０００３】
一方、インターネットにおける標準化機関であるＩＥＴＦ（Ｉｎｔｅｒｎｅｔ　Ｅｎｇｉｎｅｅｒｉｎｇ　Ｔａｓｋ　Ｆｏｒｃｅ）は、ＴＣＰ／ＩＰ上のディレクトリクライアント−サーバ間プロトコルとして「ＬＤＡＰ：Ｌｉｇｈｔｗｅｉｇｈｔ　Ｄｉｒｅｃｔｏｒｙ　Ａｃｃｅｓｓ　Ｐｒｏｔｏｃｏｌ（ＲＦＣ２２５１）」を標準化した。ユーザはディレクトリクライアントからＸ．５００等のディレクトリサーバにＬＤＡＰでアクセスし、ユーザのメールアドレス等、所望の情報を検索する。更にＬＤＡＰは、エントリ追加、削除、更新、エントリ名変更等のディレクトリ更新系リクエストも規定している。
【０００４】
ディレクトリサービスは分散システムアーキテクチャに対応可能であり、各ディレクトリサーバが管理している情報を他のサーバへ複製（レプリケーション）可能である。これにより、一台のサーバに障害が発生しても他のサーバによりサービスを継続でき、更にアクセス負荷を複数のサーバへ分散可能である。
【０００５】
サーバの障害に備え、従来のディレクトリクライアントはラウンドロビン等のアルゴリズムを用いて何れかのサーバを選択し、ＬＤＡＰリクエストを送信していた。しかし、クライアントによるサーバ切替方法は、各クライアントに対象サーバのリストを設定する必要があり、サーバの追加時等、運用に伴うメンテナンスが煩雑であった。この問題を解決するため、たとえば特許文献１のように、複数のディレクトリサーバの内、アクセス可能な状態にあるサーバを見つけ、そのサーバへリクエストを振り分ける方法も提案されている。
【０００６】
一方、従来のクライアントによるサーバ切替方法を負荷分散に適用すると、各クライアントが独自にアクセスするサーバを決定するため、必ずしも各サーバの負荷が均等化されないという問題があった。
【０００７】
上記問題を解消する技術として、非特許文献１に記載の負荷分散装置（以下、スイッチとする）が挙げられる。負荷分散装置はクライアントとサーバの間に位置し、クライアントからのリクエストを一手に引き受け、最適なサーバへ一連のリクエストを振り分ける。
【０００８】
【特許文献１】
特開２００１−２２９０７０号公報
【非特許文献１】
ＶＡＬＥＲＩＡ　ＣＡＲＤＥＬＬＩＮＩ外２名、「ＤＹＮＡＭＩＣ　ＬＯＡＤ　ＢＡＬＡＮＣＩＮＧ　ＯＮ　ＷＥＢ−ＳＥＲＶＥＲ　ＳＹＳＴＥＭＳ」、ＩＥＥＥ　ＩＮＴＥＲＮＥＴ　ＣＯＭＰＵＴＩＮＧ、（米国）、ＩＥＥＥ　Ｃｏｍｐｕｔｅｒ　Ｓｏｃｉｅｔｙ　ＰｕｂｌｉｃａｔｉｏｎｓＯｆｆｉｃｅ、１９９９年、第３巻、第３号、ｐ．３２
【０００９】
【発明が解決しようとする課題】
前述した従来のスイッチによると、以下の問題が発生する。
【００１０】
従来のスイッチは、各々のリクエストが独立したＨＴＴＰ（Ｈｙｐｅｒ　Ｔｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ）を処理対象としており、個々のリクエスト単位で分配することができる。それ以外のアプリケーションプロトコルについてはレイヤ４レベル、つまりＴＣＰコネクション単位で負荷分散する。
【００１１】
図４は従来のスイッチを用いた負荷分散の通信シーケンス例である。短期間に、３台のクライアント２ａ、２ｂ、２ｃが、各々、一つのＬＤＡＰコネクションの中で二つの検索リクエストを独自のタイミングで送信し、スイッチ１７が各リクエストを２台のサーバ１ａ、１ｂに振り分けている。ＬＤＡＰは、確立したコネクション上で一連のリクエストやレスポンスを授受するプロトコルであり、ＬＤＡＰコネクションの確立時、ＴＣＰコネクションも確立される。
【００１２】
先に述べたように従来のスイッチ１７はＴＣＰコネクション単位に負荷分散を行うため、同一ＬＤＡＰコネクション上のリクエストは全て同一のサーバへ振り分けられる。つまり、リクエストの振分先はＬＤＡＰコネクション確立時に決定され、以降、ＬＤＡＰコネクションを切断するまで変わらない。例えばクライアント２ａが送信したリクエスト１８と２１は、一つのＬＤＡＰコネクションに含まれるため、リクエスト２４と２７として同一のサーバ１ａに振り分けられる。同様に、クライアント２ｂが送信したリクエスト１９と２２はサーバ１ｂ、クライアント２ｃが送信したリクエスト２０と２３はサーバ１ａに振り分けられる。このとき、サーバ１ａには四つのリクエストが振り分けられているが、サーバ１ｂには二つのリクエストしか振り分けられていない。
【００１３】
上記のように従来のスイッチによる負荷分散方法においては、各サーバの負荷に偏りが生じ、局所的な応答性能が劣化し、ユーザの利便性を損なうことがあった。システムの性能要件を満足させるには冗長なサーバを追加する必要があり、システム規模に比例して情報処理装置の導入コストが増大した。
【００１４】
【課題を解決するための手段】
本発明は、各サーバの負荷をより均等化することが可能なサーバ負荷分散技術を提供する。
【００１５】
本発明のサーバ負荷分散方法によれば、サーバとクライアントから成る情報処理システムにおいて、クライアントから受信する個々のリクエストを、クライアントとの間で確立しているコネクションとは関係なく、その受信時点で最も負荷の少ないサーバへ送信する。
【００１６】
より具体的には、本発明のサーバ負荷分散方法によれば、サーバとクライアントから成る情報処理システムは、その一態様において、複数のサーバに関する情報をサーバプールとして定義するサーバプール定義部と、サーバプール定義情報及び各サーバの処理状況を記憶する処理状況記憶部と、クライアントとの間で確立しているコネクションの中で受信する個々のリクエストを、その受信時点で最も負荷の少ないサーバへ送信するリクエスト振分部とを備える。
【００１７】
【発明の実施の形態】
以下、本発明の一実施例について図面を用いて説明する。以下の図中、同一の部分には同一の符号を付加する。
【００１８】
図１は、本発明を適用したディレクトリシステムの構成図であり、ＬＡＮ等のネットワーク１０で、本実施例のスイッチ３、２台のディレクトリサーバ１ａ、１ｂ、３台のディレクトリクライアント２ａ、２ｂ、２ｃが接続されている。
【００１９】
スイッチ３は、クライアントとの通信処理を実行するクライアント通信制御部４、サーバとの通信処理を実行するサーバ通信制御部７、負荷分散対象のサーバ群（以下、サーバプールと呼ぶ）を定義するサーバプール定義ファイル９、サーバとのコネクションを管理するコネクション管理部８、各サーバの処理状況を記憶する処理状況記憶部６、そしてクライアントから受信したリクエストをその時点で最適なサーバへ振り分けるリクエスト振分部５から成る。
【００２０】
スイッチ３は、ＣＰＵ、メモリ、バス等の内部通信線、ハードディスクなどの二次記憶装置、通信インタフェースから構成される。通信インタフェースは、ネットワークに接続されており、これを経由して、クライアント、サーバと通信する。また、メモリには、以下に述べる処理をＣＰＵに実現させるプログラムと必要なデータが格納されている。プログラムとデータは、予め格納されていても良いし、ネットワークまたは他の記憶媒体を経由して他のサーバから、または二次記憶装置から導入されても良い。
【００２１】
図３はサーバプール定義ファイル９の一例を示すものである。システムの運用管理者は、負荷分散の対象とする複数のサーバの名称１６をサーバプール定義ファイル９に記述する。名称１６には、サーバのホスト名（もしくはＩＰアドレス）とポート番号を「：」で区切り記述する。ここでポート番号は省略可能であり、省略された場合、ＬＤＡＰの標準ポート番号である「３８９」が用いられる。
【００２２】
図２は処理状況記憶部６の情報要素を示すものであり、サーバとの間に確立されたコネクションに関する情報を記憶するコネクションテーブル１１から成る。コネクションテーブル１１は、サーバとの間に確立したコネクション数に相当する配列構造を成す。
【００２３】
各コネクションテーブル１１は、サーバとのコネクションを一意に識別するハンドル情報を記憶する領域１２、該サーバに対して最後に送信したリクエストのメッセージＩＤ（最終メッセージＩＤと呼ぶ）を記憶する領域１３、該サーバが処理中のリクエスト数を記憶する領域１４、そしてクライアントから受信したリクエストに付与されていたクライアントメッセージＩＤを記憶する領域１５から成る。各コネクションテーブル１１中のクライアントメッセージＩＤ１５は、該サーバが処理中のリクエスト数に相当する配列構造を成す。
【００２４】
次に、本実施例のスイッチの動作について説明する。最初に、サーバとのコネクション確立方法について、図６を用い説明する。スイッチが起動する際、コネクション管理部８はサーバプールに属する各サーバとの間にＬＤＡＰコネクションを確立する。
【００２５】
コネクション管理部８は、サーバプール定義ファイル９の先頭に記述されたサーバ名１６を読み出し、サーバとのＬＤＡＰコネクションを確立するＢｉｎｄリクエストを組み立て、サーバ通信制御部７に対し送信を依頼する。（Ｓ６０１）
サーバと接続後、コネクション管理部８は、処理状況記憶部６内に新たなコネクションテーブル１１を生成し、サーバとの間に確立されたＬＤＡＰコネクションを識別するハンドル情報を領域１２に登録すると共に、最終メッセージＩＤ１３を「１」に、リクエスト数１４を「０」に初期化する。（Ｓ６０２）
コネクション管理部８が、サーバプール定義ファイル９に記述された全サーバについてＳ６０１及び６０２の処理を繰り返して、スイッチとサーバ間でＬＤＡＰコネクションを確立した後（Ｓ６０３）、
スイッチ３は起動処理を終え、サービスの開始が可能となる。
【００２６】
リクエストの振分方法について、図７を用い説明する。クライアント通信制御部４は、クライアントからＬＤＡＰコネクションを確立するＢｉｎｄリクエストを受信すると、そのリクエストを何れかのサーバへ送信することなく、確立成功を示すレスポンスをクライアントへ返す。これにより、クライアント−スイッチ間のＬＤＡＰコネクションが確立される。
【００２７】
リクエスト振分部５は、クライアント通信制御部４がクライアントからのリクエストを受信した際、処理に最適なサーバをサーバプール内から選定し、該リクエストを送信する。
【００２８】
クライアント通信制御部４がクライアントからのリクエストを受信すると、リクエスト振分部５は、処理状況記憶部６からリクエスト数１４に登録された数値が最少のコネクションテーブル１１を探すことにより、該リクエストの処理に最適なサーバを選定する。（Ｓ７０１）
次に、選定した最適サーバのコネクションテーブル１１を参照し、リクエスト数１４及び最終メッセージＩＤ１３に「１」を加算する。（Ｓ７０２、Ｓ７０３）
続いてリクエスト振分部５は、該コネクションテーブル１１内に新たなクライアントメッセージＩＤ領域１５を生成し、受信したリクエストに付与されたメッセージＩＤを一時保管する（Ｓ７０４）。
【００２９】
そして、クライアントから受信したリクエスト中のメッセージＩＤを最終メッセージＩＤ１３が示すＩＤに付け替え（Ｓ７０５）、
サーバ通信制御部７に対してサーバコネクションハンドル１２に登録されたハンドル情報を通知することにより、選定したサーバへのリクエスト送信を依頼し（Ｓ７０６）、
該サーバからのレスポンスを待つ。（Ｓ７０７）
サーバ通信制御部７が該サーバからのレスポンスを受信すると、リクエスト振分部５は、受信したレスポンス中のメッセージＩＤを、Ｓ７０４において保管したクライアントメッセージＩＤ１５の値に付け替え（Ｓ７０８）、
クライアント通信制御部４に対して該レスポンスの送信を依頼する（Ｓ７０９）。
【００３０】
最後にリクエスト振分部５は、リクエスト数１４から「１」を減算し（Ｓ７１０）、
Ｓ７０４において生成したクライアントメッセージＩＤ領域１５を削除して（Ｓ７１１）、該リクエストに関する振分処理を完了する。
【００３１】
このように、本実施例によれば、一つのクライアントとの間で確立されたＬＤＡＰコネクションに含まれる複数のリクエストの各々について、そのリクエスト受信時点で最も負荷の少ないサーバへ送信できるので、より良い負荷分散が可能になる。
【００３２】
図５は、本実施形態のスイッチ３を適用した負荷分散の通信シーケンス例である。
【００３３】
クライアント２ａが送信したリクエスト１８と２１は、同一のＬＤＡＰコネクションを介して送信されたにも関わらず、リクエスト２４と３０として異なるサーバ１ａ及び１ｂに振り分けられる。同様に、クライアント２ｂが送信したリクエスト１９と２２、クライアント２ｃが送信したリクエスト２０と２３も、各々異なるサーバ１ａ及び１ｂに振り分けられる。つまり、サーバ１ａ及びサーバ１ｂには各々三つのリクエストが均等に振り分けられる。
【００３４】
上記のように本実施形態のスイッチ３は、ある一つのクライアントコネクションを介して受信した一連のリクエストをサーバとの間で確立された異なるコネクションを介して送信すること（例えばリクエスト２４、３０）、また、クライアントとの間で確立された異なるコネクションを介して受信したリクエストを同一のサーバコネクションを介して送信すること（例えばリクエスト２４、２６、３１）もある。
【００３５】
以上、本発明のサーバ負荷分散方法を適用した一実施例を説明した。本実施例によれば、一つのクライアントコネクションを介して受信した一以上のリクエスト各々を、各リクエスト受信時点で最適なサーバへ、当該サーバへのコネクションを介して送信する。コネクション単位にリクエストの振り分け先を決めていた従来スイッチに比べると、クライアントコネクションに関わらず、受信した時点で最適なサーバにリクエストを振り分けるため、各サーバの負荷の偏りをより減らすことが可能である。
【００３６】
次に本発明の第二の実施例を説明する。上記第一の実施例と同一の処理については説明を割愛する。
【００３７】
上記第一の実施例は、単一のサーバプールによる負荷分散方法に関するものである。しかし用途によっては、複数のサーバプールによる負荷分散を必要する場合もある。例えば、メールサーバからのリクエストとＷｅｂサーバからのリクエストを処理するサーバ群を分けたい場合等である。
【００３８】
図９は、複数のサーバプールに対応可能なスイッチにおけるサーバプール定義ファイル９の一例を示すものである。３８は各サーバプールを一意に識別するプール識別子であり、システムの運用管理者は、プール毎に負荷分散の対象とするサーバ群を定義可能である。本実施例においては、ＲＦＣ２２５１に規定されたＢｉｎｄリクエストのパラメータであるｎａｍｅをプール識別子とする。ｎａｍｅはディレクトリサーバを利用するアイデンティティの名称であり、他の情報処理システムにおけるユーザ名もしくはユーザＩＤに相当する。
【００３９】
図８は、本実施例における処理状況記憶部６の情報要素を示すものであり、各サーバの状況を記憶するサーバテーブル３３とコネクションテーブル１１から成る。サーバテーブル３３は全サーバプール内のサーバに相当する配列構造を成す。
【００４０】
各サーバテーブル３３は、サーバ名等、サーバを一意に識別する情報を記憶する領域３６、該サーバが処理中のリクエスト数を記憶する領域１４、そして該サーバが属するサーバプールの識別子を記憶する領域３７から成る。各サーバテーブル３３中のプール識別子３７は、該サーバが属する全プール数に相当する配列構造を成す。
【００４１】
各コネクションテーブル１１は、サーバコネクションハンドル領域１２、該コネクションが属するサーバプールの識別子を記憶する領域３４、サーバを一意に識別する情報を記憶する領域３５、最終メッセージＩＤ領域１３、そしてクライアントメッセージＩＤ領域１５から成る。
【００４２】
次に、本実施例のスイッチ３の動作について説明する。
【００４３】
スイッチ３が起動する際、コネクション管理部８は、サーバプール定義ファイル９に記述されたサーバと接続した後（Ｓ６０１）、
処理状況記憶部６内に新たなコネクションテーブル１１を生成し、サーバとの間に確立されたコネクションを識別するハンドル情報と、サーバプール定義ファイル９に記述されたプール識別子及びサーバ識別子を、各々領域１２、３４、３５に登録すると共に、最終メッセージＩＤ１３の値を「１」に初期化する。また、該サーバ識別子が登録されたサーバテーブル３３が存在しない場合は、新たなサーバテーブル３３を生成し、プール識別子及びサーバ識別子を、各々領域３７、３６に登録すると共に、リクエスト数１４を「０」に初期化する。一方、該サーバ識別子が登録されたサーバテーブル３３が存在する場合は、プール識別子３７を追加登録する（Ｓ６０２）。
【００４４】
コネクション管理部８が、サーバプール定義ファイル９に記述された全プールの全サーバについて、Ｓ６０１及び６０２の処理を繰り返した後（Ｓ６０３）、
スイッチは起動処理を終え、サービスを開始する。
【００４５】
クライアント通信制御部４がクライアントからのリクエストを受信すると、リクエスト振分部５は、処理状況記憶部６から、先のＢｉｎｄリクエストに含まれたｎａｍｅパラメータと等しい識別子が領域３７に登録され、かつリクエスト数１４に登録された数値が最少のサーバテーブル３３を探すことにより、該リクエストの処理に最適なサーバを選定する（Ｓ７０１）。
【００４６】
次にリクエスト振分部５は、選定したサーバテーブル３３のリクエスト数１４に「１」を加算した後（Ｓ７０２）、
サーバ識別子３６と等しい識別子が領域３５に登録されたコネクションテーブル１１を探索し、最終メッセージＩＤ１３の値に「１」を加算する（Ｓ７０３）。
【００４７】
続いて、リクエスト振分部５は第一の実施例と同様のメッセージ送信処理を実行し、該サーバからのレスポンスをクライアントへ返した後（Ｓ７０４からＳ７０９）、サーバテーブル３３のリクエスト数１４から「１」を減算し（Ｓ７１０）、
Ｓ７０４において生成したコネクションテーブル１１のクライアントメッセージＩＤ領域１５を削除して（Ｓ７１１）、
該リクエストに関する振分処理を完了する。
【００４８】
以上、本発明の第二の実施例を説明した。第二の実施例によると、複数のサーバプールによる負荷分散が可能である。
【００４９】
例えばメールサーバのアイデンティティがｃｎ＝ｍａｉｌ，　ｏ＝ａｂｃ．ｃｏｍ、Ｗｅｂサーバのアイデンティティがｃｎ＝ｗｅｂ，　ｏ＝ａｂｃ．ｃｏｍである場合、図９のサーバプール定義ファイル９のようにサーバプールを定義すると、メールサーバからのアクセスに３台のサーバ、Ｗｅｂサーバからのアクセスに２台のサーバが、負荷分散のために割り当てられる。
【００５０】
また本実施例のスイッチは、各プールから振り分けた処理中リクエストの総和をサーバの負荷として捉えて最適なサーバを選定しているため、１台のサーバを異なるプールで兼用しても、負荷の均等化を実現可能である。
【００５１】
図９の３９は、ある時点におけるサーバが処理中のリクエスト数である。本実施例のスイッチは、この時点で新たに受信したリクエストの送信元がメールサーバである場合はホスト名がｌｄａｐ１．ａｂｃ．ｃｏｍであるサーバへ、送信元がＷｅｂサーバである場合はホスト名がｌｄａｐ３．ａｂｃ．ｃｏｍであるサーバへそのリクエストを振り分け、負荷の均等化を図る。
【００５２】
上記各実施例は、受信したＬＤＡＰリクエストの種別に関わらず、最適なサーバを選択し、リクエストを振り分ける。しかし用途によっては、リクエスト種別によって振り分けるサーバを選別したい場合もある。例えば流通のディレクトリサーバに広く用いられるレプリケーション方法である、あるエントリに関する更新系リクエストを処理可能なサーバを単一にするシングルマスター方式の場合、他のサーバは検索系のリクエストを処理可能であるが、更新系リクエストは受け入れない。また、一般に更新可能なサーバは検索も可能であるが、更新性能を確保するために更新専用とさせたいケースもある。
【００５３】
このようなニーズに対して、例えば上記第二の実施例における図９のプール識別子３８を［検索］、［更新］とし、クライアントから受信したリクエストがＳｅａｒｃｈやＣｏｍｐａｒｅ等の検索系リクエストである場合は［検索］プールに属する何れかのサーバに振り分け、Ａｄｄ、Ｄｅｌｅｔｅ、Ｍｏｄｉｆｙ、Ｍｏｄｉｆｙ　ＤＮ等の更新系リクエストである場合は［更新］プールに属する何れかのサーバに振り分けるよう制御しても良い。
【００５４】
しかし上記方法によると、用途に応じた複数のサーバプールによる負荷分散という第二の実施例の目的を同時に達成できない。
【００５５】
この目的を同時に実現する第三の実施例を次に説明する。上記各実施例と同一の処理については説明を割愛する。
【００５６】
図１０は、複数のサーバプールに対応し、かつリクエスト種別に応じた負荷分散が可能なスイッチにおけるサーバプール定義ファイル９の一例を示すものである。本実施例において、システムの運用管理者は、各サーバ名称１６の最後に、サーバの種別を示す、「ｒｗ」、「ｗｏ」、「ｒｏ」の何れかを付与する。ここで、「ｒｗ」は読み書き可能サーバ、「ｗｏ」は書き込み専用サーバ、「ｒｏ」は読み込み専用サーバを表す。
【００５７】
図７のＳ７０１において、クライアント通信制御部４がクライアントからのリクエストを受信すると、リクエスト振分部５は、処理状況記憶部６から、先のＢｉｎｄリクエストに含まれたｎａｍｅパラメータと等しい識別子が領域３７に登録され、かつ受信したリクエストの種別を処理可能であり、かつリクエスト数１４に登録された数値が最少のサーバテーブル３３を探すことにより、該リクエストの処理に最適なサーバを選定する。
【００５８】
例えば受信したリクエストが検索系リクエストならば、当該プール内で「ｒｗ」もしくは「ｒｏ」として登録されたサーバ、更新系リクエストならば、当該プール内で「ｒｗ」もしくは「ｗｏ」として登録されたサーバが選定候補となる。
【００５９】
以降の処理は上記第二の実施例と同様である。
【００６０】
以上、説明した第三の実施例によると、複数のサーバプールに対応し、かつリクエスト種別に応じた負荷分散が可能である。例えば図１０の処理状況４０のような時点において、本実施例のスイッチは、新たにメールサーバから受信したリクエストが検索系リクエストである場合はホスト名がｌｄａｐ１．ａｂｃ．ｃｏｍであるサーバへ、更新系リクエストである場合はホスト名がｌｄａｐ２．ａｂｃ．ｃｏｍであるサーバへそのリクエストを振り分ける。
【００６１】
上記各実施例におけるスイッチは、クライアントから受信した同一コネクション上の一連のリクエストを、各々、その時点で最適なサーバへ振り分ける。しかし、トランザクション処理等、従来のように一連のリクエストを同一のサーバへ振り分けなければならない処理が混在する場合もあり得る。これに対応する第四の実施例を次に説明する。上記各実施例と同一の処理については説明を割愛する。
【００６２】
図１１は、従来のコネクション単位の負荷分散と本発明のリクエスト単位の負荷分散を同時に実現するスイッチにおけるサーバプール定義ファイル９の一例を示すものである。
【００６３】
本実施例において、＜ＯＰＲ＞指示子４１に続く情報は、上記各実施例と同様にリクエスト単位の負荷分散に用いるサーバプールである。一方、＜ＣＯＮ＞指示子４２に続く情報は、従来と同様のコネクション単位の負荷分散に用いるサーバプールである。
【００６４】
本実施例のスイッチは、Ｂｉｎｄリクエストに含まれたｎａｍｅパラメータがリクエスト負荷分散の何れかのプール識別子３８と一致する場合、上記各実施例と同様に、以降のリクエスト各々をその時点で最適なサーバへ振り分ける。
【００６５】
一方、何れのプール識別子３８にも該当しない場合は、＜ＣＯＮ＞指示子４２に続くサーバ群の中から最適なサーバを選定し、以降の当該クライアントコネクションから受信した全てのリクエストを先に選定したサーバへ振り分ける。
【００６６】
以上、説明した。本実施例のスイッチは、リクエスト単位の負荷分散、コネクション単位の負荷分散に関わらず、処理中リクエストの総和をサーバの負荷として捉えて最適なサーバを選定するため、各サーバ負荷の均等化を実現可能である。図１１の処理状況４３の右二列は、コネクション単位の負荷分散中の未完リクエスト数である。本実施例のスイッチは、新たにメールサーバから受信したリクエストが検索系リクエストである場合はホスト名がｌｄａｐ３．ａｂｃ．ｃｏｍであるサーバへそのリクエストを振り分ける。
【００６７】
上記第三または第四の実施例におけるスイッチは、リクエスト種別に関わらず、処理中リクエストの総和により最適なサーバを選定している。しかし一般的なディレクトリサーバは、ディレクトリ情報の更新時に各種インデックスを生成する等、検索用途向けに最適化されている。このためサーバの処理負荷は、検索系リクエストに比べ、更新系リクエストのほうが高い。このようなディレクトリサーバの特性を考慮し、更新系リクエストに重み付けして最適なサーバを選定するよう制御しても良い。例えば第三の実施例において、更新系リクエストのサーバ処理負荷が検索系リクエストの２倍とする。
【００６８】
図７のＳ７０２において、リクエスト振分部５は、受信したリクエストが更新系ならば、選定したサーバテーブル３３のリクエスト数１４に「２」を加算する。一方、検索系の場合は「１」を加算する。同様にＳ７１０において、処理を完了したリクエストが更新系ならばリクエスト数１４から「２」を減算する。一方、検索系の場合は「１」を減算する。
【００６９】
図１０に示す第三の実施例と同様の処理状況４０において、本スイッチは、新たにメールサーバから受信したリクエストが検索系リクエストである場合はホスト名がｌｄａｐ３．ａｂｃ．ｃｏｍであるサーバへ、更新系リクエストである場合はホスト名がｌｄａｐ１．ａｂｃ．ｃｏｍであるサーバへそのリクエストを振り分ける。
【００７０】
上記説明においては更新系リクエストの重みを２としたが、スイッチの設定ファイル等によりシステム管理者が重み値を定義可能としても良い。
【００７１】
なお、上記各実施例において、スイッチが各サーバとのコネクション確立に認証を要する場合は、サーバプール定義ファイル９のサーバ名称１６にユーザＩＤとパスワード等の認証情報を付記し、Ｓ６０１において該認証情報を用いてサーバとのコネクションを確立すれば良い。
【００７２】
また上記各実施例においては、スイッチの起動時に、負荷分散対象の全サーバとコネクションを確立する例を示した。しかし起動時ではなく、クライアントからのＢｉｎｄリクエストを受けた時点でサーバとのコネクションを確立しても良い。
【００７３】
このサーバとのコネクション確立時には、上記サーバプール定義ファイル９のサーバ名称１６に付記されたユーザＩＤとパスワード等の認証情報を用いても良いし、クライアントからのＢｉｎｄリクエストに含まれる認証情報を用いてサーバとのコネクションを確立しても良い。
【００７４】
ＬＤＡＰは、単一のコネクション上で、リクエストに対応するレスポンスを待たずに次のリクエストを発行することができる。したがって、他のクライアントから同一のＢｉｎｄリクエストを受信した場合は、サーバとのコネクションを新たに確立することなく、既存のコネクションを次のリクエスト振り分けに利用しても良い。
【００７５】
上記各実施例においては、クライアントからＬＤＡＰコネクションを確立するＢｉｎｄリクエストを受信すると、そのリクエストを何れかのサーバへ送信することなく、コネクション確立成功を示すレスポンスをクライアントへ返すものとした。しかし、クライアントを認証する必要があるならば、受信したＢｉｎｄリクエストを何れかのサーバへ送信し、サーバからのレスポンスをクライアントへ返すよう制御しても良い。
【００７６】
この場合、Ｂｉｎｄリクエストの送信によりサーバ間で確立したＬＤＡＰコネクションが冗長ならば、確立直後に、Ｕｎｂｉｎｄリクエストにより解放すれば、無駄なメモリ消費を抑止できる。
【００７７】
また、最初にサーバへ送信したＢｉｎｄリクエストに含まれるユーザＩＤとパスワード等の認証情報を一時記憶領域に記憶しておく、もしくはサーバプール定義ファイル９のサーバ名称１６に認証情報を付記しておき、以降、Ｂｉｎｄリクエストを受信した場合は、そのリクエストを何れかのサーバへ送信することなく、記憶した認証情報と照合し、確立の成功もしくは失敗を示すレスポンスをクライアントへ返すよう制御すれば、サーバの処理負荷をより低減可能である。
【００７８】
ところで、ＬＤＡＰ仕様は、クライアントが身元を明かさない、匿名によるコネクション確立を許している。このような匿名クライアントに対するサーバプールを定義する場合は、サーバプール定義ファイル９のプール識別子３８をヌル（ｎｕｌｌ）とすれば良い。スイッチは、匿名クライアントからのＢｉｎｄリクエストを受けると、以降の当該クライアントコネクションからのリクエストを、定義された匿名プール内の何れかのサーバへ振り分ける。
【００７９】
なお、上記においては、クライアントがサーバプールを選択する手立てとして、Ｂｉｎｄリクエストのパラメータであるｎａｍｅを利用した。しかし、ｎａｍｅ以外の標準化された既存パラメータをプール識別子として利用しても良いし、ＲＦＣ２２５１で定義されたＣｏｎｔｒｏｌやＥｘｔｅｎｄｅｄＲｅｑｕｅｓｔを用いてプール識別子を指定しても良い。
【００８０】
ところで、上記各実施例においてはリクエストに対するレスポンスについては触れていないが、リクエストを送信した先のサーバから対応するレスポンスが返ってくるため、リクエストとレスポンスから成るオペレーションという単位で負荷分散されていることになる。
【００８１】
なお、上記各実施例におけるスイッチは、各サーバの未完リクエスト数により最適なサーバを選定するものとして説明した。しかし、未完リクエスト数ではなく、ＣＰＵ負荷等、サーバの負荷を測るに好適な手法により、最適なサーバを選定するよう制御しても良い。また、実装が容易なラウンドロビン等の手法により最適なサーバを選定しても良い。
【００８２】
ところで、上記各実施例におけるスイッチは、ネットワークに接続された、サーバ及びクライアントとは別の情報処理装置上で動作するものとして説明した。しかし、サーバもしくはクライアントが動作する情報処理装置上で各実施形態のスイッチを動作させる構成としても同様の効果が得られる。
【００８３】
また、上記各実施例においては、本発明をディレクトリシステムに適用した場合を例に説明したが、例えばリレーショナルデータベース管理システムやオブジェクト指向データベース管理システムに代表される流通データベース管理システム等、単一のコネクション上で複数のリクエストを送信可能なあらゆる情報処理システムにおいても有用である。
【００８４】
同一サーバとの間に複数のコネクションを確立するようにシステムを構成することにより、一つのコネクション上に複数のリクエストを多重に送信できるというＬＤＡＰと同様の特徴を備えていない他のデータベースシステムにおいても、並列処理を実現可能である。
【００８５】
【発明の効果】
本発明によれば、各サーバの負荷をより均等化でき、システム全体で安定した応答性能を達成する可能性が高まる。これにより、ユーザの利便性を確保しながらも、コストを低減することが可能となる。
【図面の簡単な説明】
【図１】本発明の一実施例のシステム構成図である。
【図２】第一の実施例における処理状況記憶部６の情報構成例を示す図である。
【図３】第一の実施例におけるサーバプール定義ファイル９の情報構成例を示す図である。
【図４】従来の負荷分散システムにおける通信シーケンスを説明する図である。
【図５】本実施例の負荷分散システムにおける通信シーケンスを説明する図である。
【図６】本発明のコネクション管理部８の動作を説明する図である。
【図７】本発明のリクエスト振分部５の動作を説明する図である。
【図８】第二の実施例における処理状況記憶部６の情報構成例を示す図である。
【図９】第二の実施例におけるサーバプール定義ファイル９の情報構成例を示す図である。
【図１０】第三の実施例におけるサーバプール定義ファイル９の情報構成例を示す図である。
【図１１】第四の実施例におけるサーバプール定義ファイル９の情報構成例を示す図である。
【符号の説明】
１…ディレクトリサーバ、２…ディレクトリクライアント、３…スイッチ、４…クライアント通信制御部、５…リクエスト振分部、６…処理状況記憶部、７…サーバ通信制御部、８…コネクション管理部、９…サーバプール定義ファイル、１０…ネットワーク。

Claims

複数のサーバと一以上のクライアントとから成り、
前記サーバの内、何れか複数のサーバから成るサーバプールを一以上定義するサーバプール定義部と、
前記サーバプール定義情報及び各々の前記サーバの処理状況を記憶する処理状況記憶部と、
前記クライアントから個々のリクエストを受信した時点で、前記処理状況記憶部を参照して前記リクエストを送信すべきサーバを選択し、前記選択したサーバへ前記リクエストを送信するリクエスト振分部とを有することを特徴とするサーバ負荷分散システム。
請求項１において、
前記サーバプール定義部の各サーバプールには識別子が付与され、
前記リクエスト振分部は、前記クライアントから指定された識別子と同一の識別子が付与されたサーバプールに含まれる何れかのサーバを、前記リクエストを送信すべきサーバとして選択することを特徴とするサーバ負荷分散システム。
請求項１において、
前記処理状況記憶部は前記各サーバの未完リクエスト総数を記憶し、
前記リクエスト振分部は、前記処理状況記憶部を参照し、前記サーバプールに含まれ、かつ未完リクエスト総数が最少であるサーバを選択することを特徴とするサーバ負荷分散システム。
請求項１において、
前記リクエスト振分部は、リクエスト種別に応じてリクエストの送信先となるサーバを選択することを特徴とするサーバ負荷分散システム。
請求項４において、
前記処理状況記憶部は前記各サーバの未完リクエスト総数を記憶し、
前記リクエスト振分部は、前記処理状況記憶部を参照し、前記サーバプールに含まれ、かつ受信したリクエストを処理可能であり、かつ未完リクエスト総数が最少であるサーバを選択することを特徴とするサーバ負荷分散システム。
請求項５において、
前記処理状況記憶部はさらに、受信したリクエスト種別に応じて、前記各サーバの未完リクエスト状況を重み付けして記憶することを特徴とするサーバ負荷分散システム。
請求項１において、
前記リクエスト振分部はさらに、前記クライアントからコネクションの確立要求を受信した時点で、前記処理状況記憶部を参照してサーバを選択し、以降のリクエストを前記選択したサーバへ送信することを特徴とするサーバ負荷分散システム。
請求項２において、
前記サーバプール定義部にはさらに識別子を持たないサーバプールが定義され、
前記リクエスト振分部は、クライアントから指定された識別子が前記処理状況記憶部が記憶する何れの識別子とも一致しない場合は、上記識別子を持たないサーバプールに含まれるサーバを選択することを特徴とするサーバ負荷分散システム。
請求項２において、
前記クライアントから指定される識別子は、コネクション確立時にクライアントから指定されるアイデンティティであることを特徴とするサーバ負荷分散システム。
請求項１において、
前記リクエスト振分部は、同一コネクションを介して受信した複数のリクエスト各々を、複数のコネクションを介してサーバへ送信することを特徴とするサーバ負荷分散システム。
請求項１において、
前記リクエスト振分部は、複数のコネクションを介して受信した複数のリクエスト各々を、同一コネクションを介してサーバへ送信することを特徴とするサーバ負荷分散システム。
請求項１において、
前記リクエスト振分部は、複数のコネクションを介して受信した複数のリクエスト各々を、複数のコネクションを介して同一のサーバへ送信することを特徴とするサーバ負荷分散システム。
複数のサーバと一以上のクライアントから成る情報処理システムに用いるサーバ負荷分散装置であって、
前記サーバの内、何れか複数のサーバから成るサーバプールを一以上定義するサーバプール定義部と、
前記サーバプール定義情報及び各々の前記サーバの処理状況を記憶する処理状況記憶部と、
前記クライアントから個々のリクエストを受信した時点で、前記処理状況記憶部を参照して前記リクエストを送信すべきサーバを選択し、前記選択したサーバへ前記リクエストを送信するリクエスト振分部とを有することを特徴とするサーバ負荷分散装置。