JP2009501373A - ネットワークに接続されたサーバ・クラスタ内のクライアント・セッションの動的リバランシングを行う方法及びシステム - Google Patents

Abstract

【課題】 クラスタ内の個々のサーバ間のセッション・リバランシングを行うメカニズムを提供する。
【解決手段】 動的リバランサは、トラフィックをクラスタ内の各サーバに振り分けるルータとは独立してサーバ・クラスタ内で動作する。分析コンポーネントは、構成情報及び統計情報を使用して、セッションが存在する場合にはどのセッションを移動すべきか判定する。フィルタ・コンポーネントは、分析コンポーネントから転送命令を受信する。フィルタ・コンポーネントは、分析コンポーネントから転送命令を受信したときはリダイレクト・コマンドをクライアント要求に追加する。リダイレクト・コマンドは、クライアントがリダイレクト・コマンドを受信し、クライアント要求を新しいサーバに送信し始めるまで、セッション内のクライアント要求を新しいサーバにリダイレクトし続ける。
【選択図】 図１

Description

本発明は一般に、複数のルータを有するサーバ・クラスタ全体のセッション・リバランシングに関するものである。

複数のウェブ・ベース・アプリケーションからのクライアント要求に応じるサービス・プロバイダは、２つ以上のサーバを必要とする。サービス・プロバイダは、クライアントから要求されたタスクをサーバ・クラスタと呼ばれる個々のサーバ・アレイに分配する。クライアントはウェブ・ブラウザを介して、サーバ・クラスタ内の個々のサーバ上で実行されるアプリケーションに対して要求を行い、各アプリケーションから結果を受信する。要求の送信及び結果の受信は、クライアントとサーバの間の、セッションと呼ばれる一連のハイパーテキスト転送プロトコル（ＨＴＴＰ）通信の形で実行される。セッションの例としては、オン・ライン商店における商品の選択及び購入、又は一連の銀行取引が挙げられる。

サーバ・クラスタのプロバイダは、個々のＨＴＴＰクライアントがセッション内の複数の要求にわたって同じサーバに送り届けられるような仕組みを採用することによってＨＴＴＰセッションの状態を維持する。特定のサーバが特定のクライアントに割り当てられる場合、当該サーバとクライアントの間の関係はアフィニティ（ａｆｆｉｎｉｔｙ）と呼ばれ、また、割り当てサーバはアフィニティ・サーバと呼ばれる。

追加的なクライアントがサーバ・クラスタにアクセスしたときは、当該クライアントと割り当てサーバとの間の新しいセッションが発生することになる。余りにも多くのセッションが単一のサーバに割り当てられた場合には、サーバが過負荷状態となり、その結果、システム故障を含めた様々な性能問題が生じる恐れがある。したがって、サーバ・クラスタ内のサーバ負荷のバランシングを行うために、新しいセッションはサーバ・クラスタ全体の様々なサーバに分配されることになる。クラスタ上の様々なサーバにセッションを分配する処理は、ロード・バランシングと呼ばれている。

複数のサーバを対象とするロード・バランシングが知られている。Ｏｌｉｖｅｒ Ｍａｔｓｕｔｔｉの「Ｄｉｓｔｒｉｂｕｔｅｄ Ｗｅｂ Ｓｅｓｓｉｏｎ Ｍａｎａｇｅｍｅｎｔ」（Ｍａｓｔｅｒ’ｓ Ｔｈｅｓｉｓ／２０００年）には、ＨＴＴＰのリダイレクト・コマンド（Ｒｅｄｉｒｅｃｔ ｃｏｍｍａｎｄ）を使用して、クライアント要求の宛先となるサーバとは異なるサーバに当該クライアント要求を割り当てる手法が開示されている。Ｍａｔｓｕｔｔｉのソフトウェアはウェブ・サーバ上に所在するものであり、クライアント要求をリダイレクトする判断は、宛先アプリケーション・サーバを選択するルータの働きをするウェブ・サーバにおいて行われる。
Ｏｌｉｖｅｒ Ｍａｔｓｕｔｔｉの「Ｄｉｓｔｒｉｂｕｔｅｄ Ｗｅｂ Ｓｅｓｓｉｏｎ Ｍａｎａｇｅｍｅｎｔ」（Ｍａｓｔｅｒ’ｓ Ｔｈｅｓｉｓ／２０００年）

リダイレクトがルータ・レベルで開始される場合に複数のルータが採用されると、問題が生じることになる。稼動中の分散システムでは、個々の各ルータ・インスタンスが同一の代替宛先を選ばなければならない。言い換えれば、異なるルータが所与のインスタンスの同じデータを有していなければならない。複数のルータが所与のセッションに関する複数の要求を新たに選択された同じサーバに分配するのに必要な状態情報を転送する際は、タイミング問題が生じる可能性がある。そのようなタイミング問題に対処する解決策としては一般に、分散ロッキング・メカニズム（ｄｉｓｔｒｉｂｕｔｅｄ ｌｏｃｋｉｎｇ ｍｅｃｈａｎｉｓｍ）が知られている。

具体的には、分散ロッキング・メカニズムは、各ルータが要求の送信先について同じ判断を行うように各ルータ内の状態情報を調整する。しかし、分散ロッキング・メカニズムでは、ルータのアクションを調整する上で膨大な量のコードを書き込む必要がある。

このようなルータの調整問題に加えて、サーバ・クラスタではサーバの追加又は削除が行われる可能性があり、新しいアプリケーションがクラスタ内の既存のサーバにインストールされる可能性もあり、また、特定のサーバに与えられた重みがロード・バランシングのために変更される可能性もある。したがって、クラスタ内の個々のサーバ間のリバランシングを行う際は、サーバ・クラスタの構成変更が生じるという別の問題が発生することになる。

したがって、複数のルータを調整するコードを書き込む必要なく、またサーバ・クラスタの構成変更も伴うことなく、クラスタ内の個々のサーバ間のセッション・リバランシングを行うメカニズムが必要とされている。

上記の必要性に対処するシステムが、サーバ・クラスタ内で動作する動的リバランサ（ｄｙｎａｍｉｃ ｒｅｂａｌａｎｃｅｒ：「ＤＲ」）である。ＤＲはルータとは独立して動作する故に、複数のルータ間の調整は必要なくなる。複数のアプリケーション・サーバを含むサーバ・クラスタと、当該サーバ・クラスタ及び複数のルータに接続された複数のクライアントとを有するシステムにおいて、動的リバランサは、セッションの移動を行う上でルータを調整するためのコードを必要としない。ＤＲは、構成コンポーネント（ＣＣ）、統計コンポーネント（ＳＣ）、管理コンポーネント（ＭＣ）、分析コンポーネント（ＡＣ）、及びフィルタ・コンポーネント（ＦＣ）を有しており、これらの各コンポーネントが連動してサーバ・クラスタ内のロード・バランシングを実現する。

ＣＣは、クラスタ内の各サーバを監視し、クラスタ内の各サーバがそれぞれの構成に関する実時間情報を受信することができるように、それらの各サーバに構成情報を送信する。構成情報としては、サーバがオン・ラインであるのかそれともオフ・ラインであるのかを示すもの、各サーバ上にインストールされているアプリケーションを示すもの、及び各サーバに割り当てられる「比重（ｐｒｏｐｏｒｔｉｏｎａｌ ｗｅｉｇｈｔ）」を示すものが挙げられる。ＳＣは、各サーバ上のメモリ内のＨＴＴＰセッション数を含めた、クラスタ内の各サーバに関する実時間の統計情報の受信及び登録を行う。

ＭＣは、ＣＣから構成情報を収集し、ＳＣから統計情報を収集し、当該情報をＡＣに送信する。更に、ＭＣは、移動すべきセッションに関するセッション情報がサーバ・クラスタ内の他のサーバから検索可能な状態を保証し、また、セッションを移動するのに安全なタイミングをＦＣに通知する。

ＡＣは、構成情報及び統計情報を使用して、セッションが存在する場合にはどのセッションを移動すべきか判定する。ＡＣは、移動すべきセッションを次の２つの手法で判定することができる。第１に、ＡＣは、ＦＣからのフィルタ要求に応じて、セッションを移動すべきかどうかを判定する分析を実行することができる。第２に、ＡＣは、構成変更が検出されＡＣが新しいサーバにセッションを転送することを選択したときに、セッション移動命令を送出することができる。

ＦＣには２種類の動作がある（上述した２種類のＡＣ動作に対応する）。第１に、ＦＣは、サーバに対する全てのクライアント要求を代行受信（ｉｎｔｅｒｃｅｐｔ）する。ＦＣは、セッションを転送すべきかどうかを判定するために、フィルタ要求をＡＣに送信することができる。セッションを転送すべきことが判定された場合には、ＡＣは、転送命令をＦＣに送信する。第２に、ＦＣは、ＡＣが構成変更に応じて判定を行ったときに、当該ＡＣから転送命令を受信する。

ＦＣは、ＡＣから転送命令を受信した場合はクライアント要求にクッキーを追加し、当該要求を新しいサーバに送信する。クッキーは、セッション内の後続の要求を新しいサーバに送信するようクライアントに命令するリダイレクト・コマンドを含む。ＦＣは、クライアントがリダイレクト・コマンドを受信し、クライアント要求を新しいサーバに送信し始めるまで、セッション内のクライアント要求を新しいサーバにリダイレクトし続ける。

ＤＲを用いれば、リダイレクトを実行する全てのステップが、ルータを関与させずにサーバ上で実行されることになる。ＤＲはクラスタ上で実行されるため、クラスタ状態を実時間で認識する。

ＤＲの一代替実施形態では、リダイレクト送信コマンド（ｓｅｎｄ ｒｅｄｉｒｅｃｔ ｃｏｍｍａｎｄ）又は新しいクッキーをクライアントに渡す代わりに、アクティブ・セッションの存続期間中にリダイレクト送信コマンドを代行受信する、ルータ・プラグ・インが使用される。

添付の特許請求範囲には、本発明の特徴と考えられる新規な特徴が示されている。しかしながら、本発明自体ならびにその好ましい使用形態、他の目的、及び利点は、例示的な一実施形態に関する以下の詳細な説明を参照し、これを添付図面と併せて読めば最もよく理解されるだろう。

本発明の諸原理は、様々なコンピュータ・ハードウェア構成及びソフトウェア構成に適用可能なものである。本明細書で使用される限り「コンピュータ・ハードウェア」又は「ハードウェア」という用語は、データを記憶し又は表示することに関するロジック処理を解釈して実行することができ、必ずしもそれだけに限定されるわけではないが、処理装置及びメモリを含む任意の機械又は装置を指し、「コンピュータ・ソフトウェア」又は「ソフトウェア」という用語は、コンピュータ・ハードウェアに処理を実行させるように動作可能な任意の命令セットを指す。本明細書で使用される限り「コンピュータ」という用語は、必ずしもそれだけに限定されるわけではないが、ハードウェアとソフトウェアの任意の有益な組合せを含み、「コンピュータ・プログラム」又は「プログラム」は、必ずしもそれだけに限定されるわけではないが、コンピュータ・ハードウェアにデータの記憶または表示に関するロジック処理を解釈させて実行させるように動作可能な任意のソフトウェアを含む。コンピュータ・プログラムは、必ずしもそれだけに限定されるわけではないが、サブルーチン、モジュール、関数、メソッド、及びプロシージャを含むより小さな複数のプログラミング単位から構成されてもよく又そのように構成されていることが多い。それ故、本発明の機能は複数のコンピュータ及びコンピュータ・プログラムに分散させることができる。とはいえ、本発明は１つ又は複数の汎用コンピュータを構成して本発明の新規な諸態様を実装することを可能にする単一のコンピュータ・プログラムとして最もよく説明される。説明上本発明のコンピュータ・プログラムは、「動的リバランサ（ＤＲ）」と呼ぶ。

更に、ＤＲは、図１に描かれるハードウェア・デバイスの１つの例示的なネットワークを参照して以下に説明する。「ネットワーク」は、インターネットのような通信媒体を介して相互に結合され通信し合う任意の数のハードウェア・デバイスを有する。「通信媒体」は、必ずしもそれだけに限定されるわけではないが、ハードウェア又はソフトウェアがその媒体を介してデータを伝送できる任意の物理媒体、光媒体、電磁気媒体、又はその他の媒体を含む。説明上例示的なネットワーク１００は、クライアント・コンピュータ１ １０４、クライアント・コンピュータ２ １０６、クライアント・コンピュータ３ １０８、クライアント・コンピュータ４ １１０、ルータ１ １２２、ルータ２ １２０、サーバ１ １３２、サーバ２ １３４、サーバ３ １３６、サーバ４ １３８、及びサーバ５ １４０を含む限られた数のノードだけを有する。第１のネットワーク接続１０２は、ネットワーク・ノード１０４〜１２２間での通信を可能にする上で必要な全てのハードウェア、ソフトウェア、及び通信媒体を有する。第２のネットワーク接続１３０は、ネットワーク・ノード１３２〜１４０間での通信を可能にする上で必要な全てのハードウェア、ソフトウェア、及び通信媒体を有する。クラスタ１５０は、第２のネットワーク接続１３０、サーバ１ １３２、サーバ２ １３４、サーバ３ １３６、サーバ４ １３８、及びサーバ５ １４０を有する。以下の文脈で特に明記しない限り、全てのネットワーク・ノードは、公衆利用可能なプロトコル又はメッセージング・サービスを使用し、第１のネットワーク接続１０２及び第２のネットワーク接続１３０を介して相互に通信する。

動的リバランサ（ＤＲ）２００は、典型的には図２のストレージ２０２として概略的に示されるストレージ内に配置される。本明細書で使用される限り「ストレージ」という用語は、必ずしもそれだけに限定されるわけではないが、コンピュータがデータ又はソフトウェアを任意の期間その内部で記憶することができる、電気回路、磁気ディスク、光ディスクのような任意の揮発性媒体又は永続性媒体を含む。単一のストレージは複数の媒体を包含することができ、あるいは複数の媒体に分散させることができる。それ故、図２は単に説明の便宜上示されるものであり、必ずしもストレージ２０２の特定の物理的な実施形態が反映されているわけではない。ストレージ２０２は、サーバ・クラスタ１５０の各サーバ内に所在するように示されているが、サーバ・クラスタ１５０内に分散させることもできる。図３は、プラグ・イン２６０をそれ自体の内部に含むルータ・ストレージ２５０を示している。ルータ・ストレージ２５０は、ネットワーク１００内の各ルータに接続することも、ネットワーク１００の各ルータ内に所在させることもできる。本明細書で使用される限り「ルータ」は、クライアント要求をサーバ・クラスタ内のサーバに配信する働きをする任意のソフトウェア、ハードウェア、又はソフトウェアとハードウェアの組合せを指す。

ＤＲ ２００は、構成コンポーネント（ＣＣ）３００、統計コンポーネント（ＳＣ）４００、管理コンポーネント（ＭＣ）５００、分析コンポーネント（ＡＣ）６００、及びフィルタ・コンポーネント（ＦＣ）７００を有しており、これらの各コンポーネントが連動してサーバ・クラスタ１５０のようなサーバ・クラスタ内のセッション・ロード・バランシングを実現する。ＤＲ ２００は、セッション・テーブル２２０へのアクセスも行う。

ＣＣ ３００は、クラスタ内の各サーバを監視し、クラスタ内の各サーバがそれぞれの構成に関する実時間情報を受信することができるように、それらの各サーバに構成情報を実時間で送信する。構成情報としては、サーバがオン・ラインであるのかそれともオフ・ラインであるのかを示すデータ、各サーバ上にインストールされているアプリケーションを示すデータ、及び各サーバに割り当てられる「比重」を示すデータが挙げられる。図４を参照すると、ＣＣ ３００は、構成情報３１０を初期化するステップ３０２から開始し、当該構成情報をクラスタ内の他の各サーバに送信する（ステップ３２０）。ＣＣ ３００は、クラスタ３３０を監視し、クラスタ３３０の構成が変更されているかどうかを判定する（ステップ３４０）。構成情報３１０の変更が検出された場合には、ＣＣ ３００は、構成情報３１０を更新し（ステップ３６０）、ステップ３２０に進む。変更が検出されない場合には、ＣＣ ３００は、処理を続行すべきかどうかを判定する（ステップ３５０）。ＣＣ ３００は、続行すべきと判定した場合にはステップ３３０に進み、続行すべきでないと判定した場合には処理を終了する（ステップ３７０）。

ＳＣ ４００は、各サーバ上のメモリ内のＨＴＴＰセッション数を含めた、クラスタ内の各サーバに関する実時間の統計情報の受信及び登録を行う。図５を参照すると、ＳＣ ４００は、ステップ４０２から開始し、サーバ・クラスタの監視を行う（ステップ４１０）。ＳＣ ４００は、サーバ・クラスタ上の各サーバから統計情報を受信し（ステップ４２０）、当該統計情報をＭＣ ５００からアクセス可能な形で（図６参照）登録する（ステップ４３０）。ＳＣ ４００は、処理を続行すべきかどうかを判定し（ステップ４４０）、続行すべきと判定した場合にはステップ４１０に進む。続行すべきでないと判定した場合には、ＳＣ ４００は処理を終了する（ステップ４５０）。

ＭＣ ５００は、ＣＣ ３００から構成情報を収集し、ＳＣ ４００から統計情報を収集し、当該情報をＡＣ ６００に送信する（図７参照）。図６を参照すると、ＭＣ ５００は、ステップ５０２から開始し、ＣＣ ３００から構成情報を収集し（ステップ５１０）、当該構成情報をＡＣ ６００に送信する（ステップ５１２）。ＭＣ ５００は、ＳＩ ４００から構成情報を収集し（ステップ５１４）、当該構成情報をＡＣ ６００に送信する（ステップ５１６）。ＭＣ ５００は、セッションを移動するのに安全なタイミングかどうかを問う照会がＦＣ ７００から（図８参照）受信されたかどうかを判定する（ステップ５１８）。そのような照会が受信された場合には、ＭＣ ５００は、移動すべきセッションに関するセッション情報がサーバ・クラスタ内の他のサーバから検索可能な状態を保証した上で（ステップ５２０）、当該セッションを移動するのに安全なタイミングであることをＦＣ ７００に通知する（ステップ５２２）。ＭＣ ５００は、処理を続行すべきかどうかを判定し（ステップ５４０）、続行すべきと判定した場合にはステップ５１０に進み、続行すべきでないと判定した場合には処理を終了する（ステップ５５０）。

ＡＣ ６００は、上記の構成情報及び統計情報を使用して、セッションが存在する場合にはどのセッションを移動すべきか判定する。ＡＣ ６００は、ステップ６０２から開始し、ＣＣ ３００から構成情報を受信し（ステップ６１０）、ＳＣ ４００から統計情報を受信する（ステップ６１２）。ＡＣ ６００は、サーバ・クラスタの構成変更の有無を判定する（ステップ６１４）。構成変更としては、必ずしもそれだけに限定されるわけではないが、新しいサーバが追加されたこと、新しいアプリケーションがクラスタ内のサーバのいずれかにインストールされたこと、又はサーバに付与されている重みがロード・バランシングの目的で変更されたことが挙げられる。構成変更が検出された場合には、ＡＣ ６００はステップ６１８に進む。構成変更が検出されない場合には、ＡＣ ６００は、ＦＣ ７００からの要求が受信されたかどうかを判定する（ステップ６１６）。要求が受信された場合には、ＡＣ ６００は、構成情報及び統計情報の分析を行い（ステップ６１８）、セッションを転送すべきかどうかを判定する（６２０）。セッションを転送すべきと判定した場合には、ＡＣ ６００は、転送命令をＦＣ ７００に送信し、ステップ６２４に進む。ステップ６１６又はステップ６１８で負の判定がなされた場合には、ＡＣ ６００はステップ６２４に進む。ステップ６２４で、ＡＣ ６００は処理を続行すべきかどうかを判定し、続行すべきと判定した場合にはステップ６１０に進み、続行すべきでないと判定した場合には処理を終了する（ステップ６２６）。

ＦＣ ７００は、ステップ７０２から開始し、サーバ・クラスタ宛てのクライアント要求を代行受信する（ステップ７１０）。ＦＣ ７００は、フィルタ要求をＡＣ ６００に送信すべきかどうかを判定し（ステップ７１２）、送信すべきと判定した場合にはフィルタ要求をＡＣ ６００に送信する（ステップ７１６）。送信すべきでないと判定した場合には、ＦＣ ７００はクライアント要求を通過させ、当該クライアント要求をサーバ・クラスタに到達させ（ステップ７１４）、ステップ７２６に進む。ＦＣ ７００が進行中のアクティブ・セッション内の各要求を通過させると、新しいセッションに関するフィルタ要求が送出されることになる。しかしながら、ＦＣ ７００は、他の手法で構成されてもよい。例えば、ＦＣ ７００は、クライアント要求の宛先となるアプリケーションが許容限界内で動作していることを判定してもよく、あるいは当該アプリケーションがロード・バランシング要件から除外されることを判定してもよい。それ故、セッションの分析を行う必要がない場合には、フィルタを用いて、各要求がウェブ・アプリケーションを介してクライアントに到達するようにすることが可能となる。ＦＣ ７００は、ＡＣ ６００から転送命令が受信されたかどうかを判定する（ステップ７１８）。受信された場合には、ＦＣ ７００は、対応するクライアント要求にクッキーを追加し（ステップ７２０）、当該要求を新しいサーバに送信する（ステップ７２２）。クッキーは、セッション内の後続の要求を新しいサーバに送信するようクライアントに命令するリダイレクト・コマンドを含む。ＦＣ ７００は、転送が実行されたのと同じクライアント及びセッションに由来する要求が受信されたかどうかを判定し（ステップ７２４）、当該要求が受信された場合にはステップ７２２に進み、当該要求を新しいサーバに送信する。当該要求が受信されない場合には、ＦＣ ７００は別の要求が受信されたかどうかを判定し（ステップ７２６）、別の要求が受信された場合にはステップ７１２に進み、別の要求が受信されない場合には処理を終了する（ステップ７３０）。ステップ７２４から、ＦＣ ７００は、クライアントがリダイレクト・コマンドを受信し、各要求を新しいサーバに送信し始めるまで、セッション内のクライアント要求を新しいサーバにリダイレクトし続ける。

一代替実施形態では、ルータ・プラグ・イン・コンポーネント（ＰＩ）８００が、ルータにおけるＦＣ ７００の機能の一部を実現する。特に、ＰＩ ８００は、リダイレクト送信コマンドを伴うクッキーがクライアントに送信されないようにする。図９を参照すると、ＰＩ ８００はステップ８０２から開始し、サーバ・クラスタからの応答を監視する（ステップ８１０）。リダイレクト・コマンドが応答に追加されていることが判定された場合には（ステップ８１２）、ＰＩ ８００は、リダイレクト・コマンドを取り除き（ステップ８１４）、当該応答を転送する（ステップ８１６）。リダイレクト・コマンドが追加されていないことが判定された場合には、ＰＩ ８００はステップ８１０に進む。ＰＩ ８００は処理を続行すべきかどうかを判定し（ステップ８１８）、続行すべきと判定した場合にはステップ８１０に進み、続行すべきでないと判定した場合には処理を終了する（ステップ８２０）。

以上、本発明の好ましい一形態を添付の図面に表示し上述してきたが、好ましい一形態の変形形態が当業者には明らかとなるだろう。上記の記載は例示的なものに過ぎず、本発明は、図示し本明細書に記載した特定の形態に限定されるものと解釈すべきではない。本発明の範囲は、添付の特許請求範囲の文言だけによって限定されるべきである。

サーバ・クラスタ、複数のルータ、及び複数のクライアントを有するネットワークを示す図である。 動的リバランサ・コンポーネントを含むストレージ構成を示す図である。 代替実施形態のルータ・プラグ・イン・コンポーネントを含むルータ・ストレージ構成を示す図である。 構成コンポーネントのロジックを示すフローチャートである。 統計コンポーネントのロジックを示すフローチャートである。 管理コンポーネントのロジックを示すフローチャートである。 分析コンポーネントのロジックを示すフローチャートである。 フィルタ・コンポーネントのロジックを示すフローチャートである。 ルータ・プラグ・インを利用する代替実施形態のロジックを示すフローチャートである。

Claims (11)

1. 複数のルータ及びインターネットを介して複数のクライアント・コンピュータに接続されたサーバ・クラスタ全体のセッションを管理する装置であって、
   前記サーバ・クラスタのサーバ内のストレージに所在するフィルタ・プログラムを有し、前記フィルタ・プログラムは、前記サーバ・クラスタ内の第１のサーバ宛てのクライアント要求を代行受信することと、フィルタ要求を分析コンポーネントに送信することと、を担当し、更に、セッションを第２のサーバに転送する命令を受信することと、前記クライアント要求にリダイレクト・コマンドを追加し、当該クライアント要求を第２のサーバに転送することと、を担当する、
   装置。
2. 前記分析コンポーネントは、構成情報及び統計情報を使用して前記セッションの転送命令を送信すべきかどうかを判定する、請求項１に記載の装置。
3. 構成情報を前記サーバ・クラスタ内の前記各サーバに送信するように動作可能な構成コンポーネント
   を更に有する、請求項１に記載の装置。
4. 前記サーバ・クラスタを監視し、統計情報の受信及び登録を行うように動作可能な統計コンポーネント
   を更に有する、請求項１に記載の装置。
5. 構成情報及び統計情報を収集し、前記構成情報及び前記統計情報を前記分析コンポーネントに送信するように動作可能な管理コンポーネント
   を更に有する、請求項１に記載の装置。
6. 前記管理コンポーネントは更に、移動すべきセッションに関するセッション情報が前記サーバ・クラスタ内の前記複数のサーバから検索可能な状態を保証するように動作可能である、請求項１に記載の装置。
7. コンピュータ実行方法であって、
   サーバ・クラスタに接続されたストレージ内に所在するフィルタ・プログラムを使用し、前記サーバ・クラスタ内の第１のサーバ宛てのクライアント要求をルータによって代行受信し、フィルタ要求を分析プログラムに送信するステップと、
   前記分析プログラムからの命令の受信に応じて、リダイレクト・コマンドを前記クライアント要求に追加し、当該クライアント要求を前記分析コンポーネントによって選択された第２のサーバに送信するステップと、
   を有する方法。
8. 構成情報を受信するステップと、
   統計情報を受信するステップと、
   管理プログラムを使用し、前記構成情報及び前記統計情報を収集し、前記構成情報及び前記統計情報を前記分析プログラムに送信するステップと、
   を更に有する、請求項７に記載のコンピュータ実行方法。
9. 前記管理プログラムは、
   移動すべきセッションに関するセッション情報が前記サーバ・クラスタ内の前記複数のサーバから検索可能な状態を保証するステップ
   を更に有する、請求項７に記載のコンピュータ実行方法。
10. それ自体がコンピューティング装置上で実行されたときに、請求項７乃至９のいずれか一項に記載のステップを全て実行するプログラム・コードを有するコンピュータ・プログラム。
11. 複数のルータ及びインターネットを介して複数のクライアント・コンピュータに接続されたサーバ・クラスタを有するネットワークであって、前記サーバ・クラスタの各サーバにはフィルタ・プログラムが記憶されており、前記フィルタ・プログラムは、前記サーバ・クラスタ内の第１のサーバ宛てのクライアント要求を代行受信することと、フィルタ要求を分析コンポーネントに送信することと、を担当し、更に、セッションを第２のサーバに転送する命令を受信することと、前記クライアント要求にリダイレクト・コマンドを追加し、当該クライアント要求を第２のサーバに転送することと、を担当する、ネットワーク。

Images