JP2008537421A - 通信システム内の接続を確立する方法 - Google Patents

Abstract

本発明は、フロント・エンド・ノードといくつかのサーバ・ノードとを含む通信システムにおいてトランスポート層接続を多重化することに関するものである。外部ノードに関連する宛先情報を含む第１のパケットが、サーバ・ノードからフロント・エンド・ノードに経路指定される。フロント・エンド・ノードでは、宛先情報に関連する終了ポイントが確立される。第１のパケットに由来するアプリケーション・データが、フロント・エンド・ノード内のアプリケーション・エンティティに提供される。当該第１のパケットは、外部ノードに送信される。
【選択図】 なし

Description

本発明は、通信システム内のサーバ・クラスタの提供に関するものである。特に、本発明は、通信システム内の接続を確立する方法に関するものである。

高トラフィックのインターネット・サイトをサポートする際は、単一の物理ノードを使用するサイトを提供することは事実上不可能である。したがって、サーバ・クラスタの概念が開発されている。他のインターネット・ノードから見るとサーバ・クラスタは単一のノードだけから構成されているように見える。他のノードは、単一のＩＰアドレスを使用してサーバ・クラスタにアクセスする。しかしながら、単一のＩＰアドレスに宛てられたサービス要求パケットはまずディスパッチャ・ノードに経路指定され、その後クラスタ化されたいくつかのサーバ・ノードのうちの１つに割り当てられることになる。各サービス要求は、他のサービス要求とは別個に割り当てることができる。そのようなサービスの一例としては、単一のドメイン名の下で提供されるいくつかのページを含むＷＷＷサイトがある。サーバ・クラスタの場合では、ドメイン名は単一のＩＰアドレスに解決することができる。一方、ＩＰマルチメディアの導入に伴い、そのようなサービスはＩＰマルチメディア・セッション処理サーバを介して行われることもある。ＷＷＷサイトの場合と同様に、ＩＰマルチメディア・セッション処理サーバは、やはり単一のＩＰアドレスに解決されることになるドメイン名を使用して識別される。

単にコンテンツのダウンロードをサポートするだけのＷＷＷサイトの場合では、ハイパーテキスト転送プロトコル（ＨＴＴＰ）要求と、サービス要求に応じてサーバ・ノードから提供される応答とを別個に取り扱うことが可能である。サービス要求／応答に関してアプリケーション層の処理は必要とされない。最も重要な要因は、ダウンロード・トランザクションに関連する要求が１つしか存在しないことである。ここでは、後続の要求メッセージとそれ以前の要求メッセージとの間の相関付けを行うことが可能である必要はない。

ＩＰマルチメディアの場合、その状況は少し異なる。クラスタ内のサーバ・ノード間の適正なロード・バランシングを実行できるようにするには、アプリケーション層を関与させる必要がある。セッション開始プロトコル（ＳＩＰ）の送信勧誘要求（Ｉｎｖｉｔｅ ｒｅｑｕｅｓｔ）が外部ノードから受信され、当該送信勧誘要求がサーバ・ノードに割り当てられた後に、ディスパッチャ・ノードは、当該送信勧誘要求に関する後続のＳＩＰメッセージの関連付けを行い、それらのＳＩＰメッセージを割り当て対象となるサーバ・ノードに経路指定することができなければならない。したがって、アプリケーション層のロード・バランサは、伝送制御プロトコル（ＴＣＰ）接続を終了させ、全てのセッションに関するシグナリング・メッセージを処理しなければならない。ＳＩＰの説明は、インターネット技術特別調査委員会（ＩＥＴＦ）の文書「ＲＦＣ ３２６１」に詳しく記載されている。

ここで図１を参照すると、従来技術の伝送制御プロトコル（ＴＣＰ）セグメント・ヘッダが示されている。ＴＣＰの説明は、ＩＥＴＦの文書「ＲＦＣ ７９３」に詳しく記載されている。ＴＣＰは、開放型システム間相互接続（ＯＳＩ）データ通信モデルのトランスポート層のタスクを行う。図１にはＴＣＰセグメント・ヘッダ１００が示されている。ヘッダ１００では、送信元ポートがＴＣＰセグメントを送信したアプリケーションを識別し、宛先ポートがターゲット・アプリケーションを識別する。単一のアプリケーションは、いくつかのポートを使用してデータ送信を行うことができ、いくつかのポートをリスンして受信データの有無を確認することができる。プロトコル・スタックは、ポート番号を利用して、ＴＣＰセグメントを送信しなければならない正しいアプリケーション・エンティティを認識するものである。シーケンス番号は、送信中のバイト・ストリーム内の現在位置をバイト単位で識別するものである。肯定応答番号は、バイト・ストリーム内のバイトのうち、受信者によって正しく受信されたバイトを送信者に指示するものである。ＴＣＰ接続が確立されている間に送信側ホストと受信側ホストとの間で初期シーケンス番号（ｉｎｉｔｉａｌ ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒ：ＩＳＮ）が交換される。Ｌｅｎフィールドは、ＴＣＰヘッダの長さを３２ビット・ワード単位で指示するものである。フラグは、緊急フラグ、肯定応答フラグ（ＡＣＫ）、プッシュ・フラグ、接続リセット・フラグ、同期シーケンス番号（ＳＹＮ）フラグ、及び終了フラグ（ＦＩＮ）を含む。フラグ「ＳＹＮ」は、接続確立フェーズで使用される。ＳＹＮフラグを有するセグメントは、ＳＹＮセグメント又はＴＣＰ‐ＳＹＮセグメントと呼ばれる。同様に、ｏｎのＡＣＫフラグを有するセグメントは、ＡＣＫセグメントと呼ばれる。ウィンドウ・サイズは、現在のセグメントの送信者が受け入れを希望する、肯定応答フィールド内で指示されるデータ・バイトから始まるデータ・バイト数である。チェックサムは、ＩＰヘッダと、ＴＣＰヘッダと、データとから収集される情報を含む擬似ヘッダの１の補数を合計し、これを１６ビットの１の補数として計算するものであり、必要に応じて２バイトの倍数となるように末尾に「０」のバイトがパディングされる。本明細書で論じられていないＴＣＰヘッダ・フィールドの残りの部分の説明は、例えば「ＲＦＣ ７９３」等の文書で確認することができる。

ＴＣＰ接続は、接続確立フェーズと、データ転送フェーズと、接続終了フェーズの３つのフェーズを含む。接続の確立には３方向ハンドシェークが使用される。接続の遮断には４方向ハンドシェークが使用される。１対のホスト同士が介在する接続を同時に開始することも可能ではあるが、典型的には一方のホストがソケットをオープンし、他方のホストからの接続を受動的にリスンする。この処理はパッシブ・オープンと呼ばれており、接続のサーバ・サイドを指定するものである。確立すべき接続のクライアント・サイドは、３方向ハンドシェークの一環として初期のＳＹＮセグメントをサーバに送信することによってアクティブ・オープンを開始する。サーバ・サイドは、有効なＳＹＮセグメントに対して、やはりｏｎのＡＣＫフラグを有するＳＹＮセグメントを用いて応答する。最後に、クライアント・サイドはＡＣＫセグメントを用いて応答し、それによって３方向ハンドシェーク及び接続確立フェーズが完了する。

次に図２を参照すると、従来技術のＴＣＰ接続ルータを備えたクラスタ・サーバを示すブロック図が示されている。ＴＣＰ接続ルータは、クラスタ・サーバの入力側のＴＣＰ接続だけを取り扱うものである。図２の場合では、サービス要求／応答に関してアプリケーション層の処理は必要とされない。当該サービス要求／応答は、典型的にはハイパーテキスト転送プロトコル（ＨＴＴＰ）要求／応答である。図２に示すのと同様の解決策は、刊行物「ＮｅｔＤｉｓｐａｔｃｈｅｒ：Ａ ＴＣＰ Ｃｏｎｎｅｃｔｉｏｎ Ｒｏｕｔｅｒ」、Ｇ． Ｇｏｌｄｓｚｍｉｄｔ、Ｇ． Ｈｕｎｔ、ＩＢＭ Ｒｅｓｅａｒｃｈ Ｄｉｖｉｓｉｏｎ、Ｔ．Ｊ． Ｗａｔｓｏｎ Ｒｅｓｅａｒｃｈ Ｃｅｎｔｅｒ、Ｙｏｒｋｔｏｗｎ Ｈｅｉｇｈｔｓ、Ｎｅｗ Ｙｏｒｋ（１９９７年）に記載されている。

図２にはサーバ・クラスタが示されている。当該サーバ・クラスタは、ＴＣＰ接続ルータ２００を含み、当該ＴＣＰ接続ルータは、例えばローカル・エリア・ネットワーク２０５を介してサーバ・ノード２０１〜２０４と接続される。ＴＣＰ接続ルータ２００は、クラスタ内の各サーバの状態を認識している。ＴＣＰ接続ルータ２００は、ロード・バランシングを実行する。ＴＣＰルータ２００は、ＩＰネットワーク２１０に接続されている。ＩＰネットワーク２１０は、例えばインターネットであっても企業イントラネットであってもよい。ＩＰネットワーク２１０には、２つのクライアント・ノード、即ちクライアント・ノード２１２及びクライアント・ノード２１４も接続されている。図２には２つの要求／応答トランザクションが示されている。これらのトランザクションは、例えばサーバ・クラスタが提供するＷＷＷサイトからのＨＴＭＬページの検索である。

まず、クライアント２１２は、ＨＴＴＰ要求をサーバ・クラスタに送信する。当該ＨＴＴＰ要求はまず、ＴＣＰ接続ルータ２００において処理される。ＴＣＰ接続ルータ２００は、その時点で最も輻輳が少ないサーバ・ノード、言い換えれば処理上の負荷が最も小さいサーバ・ノードを判定する。あるいは、ＴＣＰ接続ルータは、要求メッセージ・ヘッダに含まれる少なくとも１つのフィールドから計算されるハッシュ値に基づいてサーバ・ノードのランダム・アロケーションを実行することもできる。

クライアント２１２の場合では、ＴＣＰ接続ルータは、矢印２５０で示されるようにＨＴＴＰ要求をサーバ２０２に送信しなければならないことを判定する。サーバ２０２からクライアント２１２に戻される応答は、ＴＣＰ接続ルータ２００を経由しない。当該応答は、矢印２５２で示されるように、ＩＰネットワーク２１０を経由してクライアント２１２へと経路指定される。クライアントＢ２１４がＨＴＴＰ要求をサーバ・クラスタに送信する場合は、まず当該要求がＴＣＰ接続ルータ２００によって処理された後、ＴＣＰ接続ルータ２００が当該ＨＴＴＰ要求をサーバ２０４に送信すべきことを判定する。ＨＴＴＰ要求の経路は、図２の矢印２６０で示されている。サーバ２０４からクライアント２１４に戻されるＨＴＴＰ要求は、ＴＣＰルータ２００を経由するのではなくＴＣＰ接続ルータ２００を迂回するように経路指定され、矢印２６２で示されるようにＩＰネットワーク２１０を経由してクライアント２１４へと経路指定される。クラスタ内のサーバをターゲットとする全てのＨＴＴＰ要求において、宛先アドレスは常にＴＣＰ接続ルータ２００を参照する。それ故、ＩＰネットワーク２１０は入力パケットを経路指定する際は常に、パケットをＴＣＰ接続ルータ２００に経路指定する。

従来技術の解決策の課題は、アプリケーション層のエンティティが相互に関連するいくつかのアプリケーション・プロトコル要求／応答の相関付けを行わなければならず、そのため、一方では外部ノードとの接続を終了させ、他方ではクラスタ内のサーバ・ノードとの接続を終了させなければならない場合について、適用可能な解決策が示されていない点である。更に、従来技術の解決策では、２つのノード間のシグナリング・トラフィックを単一のトランスポート層接続に多重化する必要がある場合の対処法についても教示していない。

本発明は、少なくともフロント・エンド・ノードと少なくとも１つのサーバ・ノードとを含む通信システムにおいて外部ノードとの接続を確立する方法であって、前記サーバ・ノードは、前記フロント・エンド・ノードと通信するように構成され、前記フロント・エンド・ノードは、前記外部ノードと通信するように構成され、外部ノードに関連する宛先情報を含む第１のパケットを、前記サーバ・ノードから前記フロント・エンド・ノードに配信するステップと、前記フロント・エンド・ノードにおいて前記宛先情報に関連する終了ポイントを確立するステップと、を含む方法に関するものである。

本発明はまた、外部ノードとの接続を確立するシステムであって、前記外部ノードに関連する宛先情報を含む第１のパケットを送信するように構成された少なくとも１つのサーバ・ノードと、前記サーバ・ノードから前記第１のパケットを受信し、前記宛先情報に関連する終了ポイントを確立するように構成されたフロント・エンド・ノードと、を備えるシステムに関するものである。

本発明はまた、外部ノードとの接続を確立するネットワーク・ノードであって、前記外部ノードに関連する宛先情報を含む第１のパケットをサーバ・ノードから受信するように構成されたプロトコル・スタック・エンティティと、前記宛先情報に関連する終了ポイントを確立するように構成されたアプリケーション・エンティティと、を備えるネットワーク・ノードに関するものである。

本発明はまた、コンピュータ・プログラムであって、データ処理システム上で実行されたときに、前記サーバ・ノードから前記フロント・エンド・ノードに向けて発信され、外部ノードに関連する宛先情報を含む第１のパケットを受信するステップと、前記宛先情報に関連する終了ポイントを確立するステップと、を実行するように適合されたコードを含むコンピュータ・プログラムに関するものである。

本発明の一実施形態において、前記少なくとも１つのサーバ・ノードは、サーバ・クラスタに含まれる。前記サーバ・クラスタは、例えばブレード・サーバとして実施することができる。前記フロント・エンド・ノードは、前記サーバ・クラスタの一部とすることができる。

本発明の一実施形態において、終了ポイントの確立とは、例えば前記プロトコル・スタック・エンティティとアプリケーション・エンティティとの間の論理的な関連性を形成することを指す。所与のノード内の論理的な関連性は、当該ノードを参照する宛先情報で識別される。言い換えれば、所与のノードを参照する宛先情報は、前記ノード内の前記プロトコル・スタック・エンティティとアプリケーション・エンティティとの間の論理的な関連性に関する識別子も含む。また、終了ポイントの確立とは、既存の論理的な関連性が前記プロトコル・スタック・エンティティとアプリケーション・エンティティとの間の通信に使用できるようになることを指す。本発明の一実施形態において、前記終了ポイントはソケットであり、前記終了ポイントの確立は前記ソケットのオープンを指す。

本発明の一実施形態において、宛先情報という用語は、前記外部ノードのようなノードのアドレスを含む。本発明の一実施形態において、宛先情報という用語は、前記外部ノードのようなノードのアドレスと、アプリケーション・エンティティを判定するフィールドとを含む。前記フィールドは、例えば前記ノード内のアプリケーション・エンティティを参照するポート番号とすることができる。前記ノード内の前記アプリケーション・エンティティは、それ自体を、前記ポート番号を使用して識別されるポートのユーザとして登録することができる。前記ポートは、例えば伝送制御プロトコル（ＴＣＰ）ポートとすることができる。本発明の一実施形態において、宛先情報という用語は単に、ノード内のアプリケーション・エンティティを判定するポート番号等のフィールドを含む。

本発明の一実施形態において、前記第１のパケットに由来するアプリケーション・データは、前記終了ポイントを経由して前記フロント・エンド・ノード内のアプリケーション・エンティティに提供される。前記フロント・エンド・ノードは、前記外部ノードとの接続の多重化を実行する。前記多重化は、前記少なくとも１つのサーバ・ノードから前記フロント・エンド・ノードに送られたパケットが受信されるたびに実行される。前記多重化は、例えば前記外部ノードとの間で利用できる接続が存在しない場合に、前記アプリケーション・エンティティが前記外部ノードとの接続をオープンすることを含む。その結果、メッセージが前記アプリケーション・エンティティから前記外部ノードに送信される。

本発明の一実施形態において、前記第１のパケットは、プロトコル・スタック・エンティティから前記フロント・エンド・ノード内のアプリケーション・エンティティに提供される。前記アプリケーション・エンティティは、前記外部ノードとの間で利用できる接続が存在しない場合には、前記外部ノードとのトランスポート層接続をオープンする。その結果、前記アプリケーション・エンティティは、前記第１のパケットに由来する情報を含むアプリケーション・プロトコル・メッセージを、前記トランスポート層接続を介して前記外部ノードに送信する。

本発明の一実施形態において、前記終了ポイントはソケットである。本発明の一実施形態において、ソケットという用語は一般に、プロトコル・スタック・エンティティとアプリケーション・エンティティとの間の関連性を指す。受信側でのソケットのオープンは、アプリケーション・エンティティが前記プロトコル・スタック・エンティティに対して、特定のポート番号又はアプリケーション識別子フィールドを有するパケットを受信した場合はそれらのパケットを当該アプリケーション・エンティティに提供しなければならない旨を指示することによって行われる。本発明の一実施形態において、前記ソケットは、伝送制御プロトコル（ＴＣＰ）／インターネット・プロトコル（ＩＰ）ソケットである。

本発明の一実施形態において、前記方法は、前記フロント・エンド・ノードにおいて前記サーバ・ノードの少なくともアドレスを指定する第１のフィルタを作成するステップと、前記フロント・エンド・ノードにおいて前記第１のパケットを前記第１のフィルタに基づいて選択するステップと、前記フロント・エンド・ノードにおいて前記宛先情報を指定する第２のフィルタを作成するステップと、前記フロント・エンド・ノードにおいて前記第１のパケットを前記第２のフィルタに基づいて選択するステップと、を更に含む。

本発明の一実施形態において、前記ネットワーク・ノードは、前記第１のパケットを、終了ポイントを経由してアプリケーション・エンティティに提供するように構成された前記プロトコル・スタック・エンティティと、メッセージを前記外部ノードに送信するように構成された前記アプリケーション・エンティティと、を更に備える。

本発明の一実施形態において、前記ネットワーク・ノードは、前記サーバ・ノードの少なくともアドレスを指定する第１のフィルタを作成し、外部ノードに関連する宛先情報を指定する第２のフィルタを作成するように構成された管理エンティティと、前記第１のパケットをポリシー・エンティティに提供するように構成された前記プロトコル・スタック・エンティティと、前記第１のパケットを前記第１のフィルタに基づいて選択し、前記第１のパケットを前記第２のフィルタに基づいて選択するように構成されたポリシー・エンティティと、を更に備える。

本発明の一実施形態において、前記サーバ・ノードから発信される第２のパケットは、内部ネットワークが前記フロント・エンド・ノードを前記少なくとも１つのサーバ・ノードに接続することによって、前記フロント・エンド・ノードに経路指定される。前記第２のパケットは、前記外部ノードを参照する宛先情報を含む。前記第２のパケットは、前記フロント・エンド・ノードにおいて前記第２のフィルタに基づいて選択される。言い換えれば、前記第２のパケットは、前記第２のパケットが前記フロント・エンド・ノードにおいて受信されると同時に、前記第２のパケットを前記プロトコル・スタック・エンティティから取得する前記ポリシー・エンティティによって傍受される。

前記第２のパケットは、前記ポリシー・エンティティから前記プロトコル・スタック・エンティティを経由して前記アプリケーション・エンティティに提供される。前記第２のパケットがフィルタ・ルールの結果前記ポリシー・エンティティから前記プロトコル・スタック・エンティティに送り返された場合を考えると、前記プロトコル・スタック・エンティティは、前記第２のパケットを当初前記フロント・エンド・ノードにアドレス指定されたパケットと見なすことになる。前記プロトコル・スタック・エンティティは、前記第２のパケットに含まれる宛先情報に基づいて、前記アプリケーション・エンティティによってオープンされたソケットを識別する。前記プロトコル・スタック・エンティティは、前記第２のパケットを、前記ソケットを経由して前記アプリケーション・エンティティに提供する。

前記アプリケーション・エンティティは、前記第２のパケットに由来する情報を含むアプリケーション・プロトコル・メッセージを、前記トランスポート層接続を介して前記外部ノードに送信する。前記アプリケーション・プロトコル・メッセージは、前記第１のパケットに由来する情報も含むことができる。前記アプリケーション・プロトコル・メッセージは、前記第１のパケットと前記第２のパケットとの間で送信される少なくとも１つのパケットに由来する情報も含むことができる。前記アプリケーション・エンティティは、前記サーバ・ノードから前記ソケットを経由して完全なアプリケーション・プロトコル・メッセージが届くのを待ってから、受信情報に関するアプリケーション層の処理を実行し、前記アプリケーション・プロトコル・メッセージを前記外部ノードに送信することもできる。本発明の一実施形態において、前記プロトコル・スタック・エンティティは、少なくともＴＣＰ及びＩＰプロトコルを含む。

本発明の一実施形態において、前記サーバ・クラスタ内のサーバ・ノードはアクティブ状態に入ると、それ自体のアドレスと、任意選択で少なくとも１つのアプリケーション層エンティティに関するポート番号とを、前記フロント・エンド・ノードに知らせる。アクティブ状態とは、サーバ・ノードがアプリケーション層の要求メッセージを処理する準備が整った状態、又は前記サーバ・ノードが負荷分散に関与する他のトラフィックを処理する準備が整った状態を指す。この逆の状態がパッシブ状態であり、この場合、サーバ・ノードは、例えばソフトウェア又はハードウェアのアップグレードを行うために検査モードに入り、又は非アクティブ状態となる。サーバ・ノードは、例えば再起動処理の後に又はオペレータのアクションに応じて自動的にアクティブ状態に入る。

前記アプリケーション層エンティティは、前記フロント・エンド・ノードの処理に関わるエンティティである。これらのエンティティは、例えば前記フロント・エンドによって実行されるロード・バランシング処理を受ける。

本発明の一実施形態において、前記第１のパケットは、同期化ビットの値を１とする伝送制御プロトコル・セグメントを含む。言い換えれば、前記第１のパケットはＳＹＮ ＴＣＰセグメントに相当する。

本発明の一実施形態において、前記フロント・エンド・ノードは、サーバ・ノード・クラスタ内のサーバ・ノードのうち、入力サービス要求を割り当てなければならないサーバ・ノードを判定するロード・バランサ・ノードである。前記ロード・バランシングは、例えば前記クラスタ内の前記サーバ・ノードから受信される負荷状態情報に基づいて行うことも、前記フロント・エンド・ノードによって実行されるランダム・アロケーション又は疑似ランダム・アロケーションに基づいて行うこともできる。

本発明の一実施形態において、前記サーバ・ノードはセッション開始プロトコル（ＳＩＰ）サーバを含み、前記アプリケーション・エンティティはセッション開始プロトコル（ＳＩＰ）エンティティである。本発明の一実施形態において、前記フロント・エンド・ノードは、セッション開始プロトコル（ＳＩＰ）プロキシ又はサーバを含む。
本発明の一実施形態において、前記通信システムは、グローバル移動通信システム（ＧＳＭ）ネットワーク及びユニバーサル移動電話システム（ＵＭＴＳ）ネットワークのうちの少なくとも１つを含む。

本発明の一実施形態において、前記サーバ・ノードは、ＩＰマルチメディア・サブシステム（ＩＭＳ）の呼状態制御機能（ＣＳＣＦ）を形成する。
本発明の一実施形態において、前記コンピュータ・プログラムは、コンピュータ可読媒体に記憶される。前記コンピュータ可読媒体は、取り外し可能なメモリ・カード、磁気ディスク、光ディスク、あるいは磁気テープとすることができる。

本発明の利点は、アプリケーション層で単一のアプリケーション層セッションに関連するいくつかの要求メッセージの関連付けを行う必要がある場合に、当該アプリケーション層におけるロード・バランシングの実行を可能にすることに関するものである。
本発明の更なる理解を与えるために添付した本明細書の一部を形成する添付図面は、本発明の諸実施形態を図示するものであり、本明細書と併せて本発明の諸原理を説明するのに役立てるものである。

ここで、添付図面にその実例が示される本発明の諸実施形態を詳細に説明する。
図３は、本発明の一実施形態に係るロード・バランサ・ノードを含むクラスタ・サーバを示すブロック図である。

図３にはサーバ・クラスタが示されている。サーバ・クラスタは、ロード・バランサ・ノード３５０と、内部ＩＰネットワーク３８０と、２つの内部サーバ、即ち内部サーバ３６０及び内部サーバ３７０とを含む。内部ＩＰネットワーク３８０は、例えばイーサネット（登録商標）を使用して実施することができる。内部サーバ３６０及び３７０内にはそれぞれＳＩＰアプリケーション３６２及び３７２が存在する。どちらの内部サーバもＴＣＰ／ＩＰ及びＵＤＰ／ＩＰプロトコル・スタック（図示せず）を有する。ＳＩＰアプリケーション３６２は、ソケット３６４をオープンしている。

図示のとおりソケット３６４に関連するＩＰアドレスはＩＰ‐Ａであり、ポート番号はＹである。ＳＩＰアプリケーション３７２は、ソケット３７４を有し、当該ソケットのＩＰアドレスはＩＰ‐Ｂであり、ポート番号はＸである。ＳＩＰロード・バランサ・ノード３５０は、ＴＣＰ／ＩＰプロトコル・スタック３５２を備える。ＴＣＰ／ＩＰプロトコル・スタック３５２にはポリシー・エンティティ３５３も関連付けられている。ポリシー・エンティティ３５３は、ＩＰパケットのフィルタリングを実行するものであり、それ自体に関連するいくつかのポリシー・ルール、即ちどのＩＰパケットを受け取るべきかを知らせ、当該ＩＰパケットをＳＩＰロード・バランサ・ノード３５０内のどの部分に提供しなければならないかを知らせるポリシー・ルールを有する。ＳＩＰロード・バランサ・ノード３５０内には、ＳＩＰアプリケーション・エンティティ３５５及びＳＩＰ管理エンティティ３５４も存在する。

ＳＩＰロード・バランサ・ノード３５０は、例えばインターネット又は企業イントラネットであってもよい外部ＩＰネットワーク３８２に接続されている。外部ＩＰネットワーク３８２には、外部サーバ３９０も接続されている。外部サーバ３９０内にはＳＩＰアプリケーション・エンティティ３９４も存在する。ＳＩＰアプリケーション・エンティティ３９４は、ソケット３９２をリスンする。ソケット３９２のＩＰアドレスはＩＰ‐Ｅであり、ポート番号はＺである。

図３では、内部サーバ３６０においてＳＩＰメッセージを外部サーバ３９０に送信する必要が生じたときに処理が開始される。ＳＩＰメッセージは、ＳＩＰロード・バランサ・ノード３５０を経由して外部サーバ３９０へと経路指定される。しかしながら、ＳＩＰロード・バランサ・ノード３５０がリスンしているべき外部サーバ３９０のＩＰアドレス及びポート番号を認識していないという問題も発生する。したがって、ポリシー・エンティティ３５３に関するフィルタ・ルールを構成しなければならない。フィルタ・ルールのデータ自体は、ＳＩＰロード・バランサ・ノード３５０のメモリに記憶される。ＳＩＰ管理エンティティ３５４は、送信元アドレスＩＰ‐Ａ及びポート番号Ｙを有する全てのＴＣＰパケットをＳＩＰ管理エンティティ３５４に引き渡さなければならない旨を指定するフィルタ・ルールを、ポリシー・エンティティ３５３に追加する。

本発明の一実施形態において、フィルタ・ルールは、ポリシー・エンティティ３５３に関連し、ＳＩＰ管理エンティティ３５４に対する実際の通知を処理する機能拡張エンティティ（図示せず）を指定することもできる。当該フィルタ・ルールの追加は、矢印３０１で示されている。その後のある時点で、内部サーバ３６０はパケットをＩＰアドレスＩＰ‐Ｅ及びポート番号Ｚに送信する。内部ＩＰネットワーク３８０は、当該パケットをＳＩＰロード・バランサ・ノード３５０に経路指定する。経路指定の判断は、内部サーバ３６０で既に実行されていることもある。当該パケットは、矢印３０２で示されている。当該パケットは、ＴＣＰ／ＩＰプロトコル・スタック３５２において処理され、そこから矢印３０３で示されるようにポリシー・エンティティ３５３に引き渡される。

ポリシー・エンティティ３５３は、先に定義されたフィルタ・ルールに基づき、当該パケットをＳＩＰ管理エンティティ３５４に通知しなければならない旨を含めて、ＩＰパケット内の宛先ＩＰアドレスがＩＰ‐Ｅであり、ＴＣＰポート番号がＺであることを通知する。ポリシー・エンティティ３５３は、矢印３０４で示されるように、入力パケットをＳＩＰ管理エンティティ３５４に通知する。ＳＩＰ管理エンティティ３５４は、矢印３０５で示されるように、ＩＰアドレスＩＰ‐Ｅ及びポート番号Ｚを有するリスン対象ソケットのオープン要求をＳＩＰアプリケーション・エンティティ３５５に送信する。ＳＩＰアプリケーション３５５は、線３０６で示されるようにリスン対象ソケットをオープンする。当該ソケットがオープンされると、ＳＩＰアプリケーション３５５は、矢印３０８で示されるように当該オープンの肯定応答をＳＩＰ管理エンティティ３５４に送信する。その結果、ＳＩＰ管理エンティティ３５４は、宛先アドレスＩＰ‐Ｅ及び宛先ポートＺを有する全てのＴＣＰパケットをローカル・スタックに引き渡さなければならない旨を指定するフィルタ・ルールの追加要求を、ポリシー・エンティティ３５３に送信する。

また、ＳＩＰ管理エンティティ３５４は、当該パケットをＴＣＰ／ＩＰプロトコル・スタック３５２に再投入（ｒｅ‐ｉｎｊｅｃｔ）するようポリシー・エンティティ３５３に知らせる。ポリシー・エンティティ３５３は、矢印３１０で示されるように、当該パケットをＴＣＰ／ＩＰプロトコル・スタック３５２に再投入する。ここで、ＴＣＰ／ＩＰプロトコル・スタック３５２は当該パケットを処理する際に、ＳＩＰロード・バランサ・ノード３５０内で当該パケットを受信すべきリスン対象ソケットがオープン状態にあることを判定する。この判定は、ＩＰアドレスＩＰ‐Ｅ及びポート番号Ｚに基づいて行われる。矢印３１１及び３１２で示されるように、ＴＣＰ／ＩＰプロトコル・スタック３５２は当該パケットを、ソケット３５６を経由してＳＩＰアプリケーション３５５に引き渡す。

ＳＩＰアプリケーション３５５は、当該パケットからＳＩＰメッセージに関するデータを取得する。ＳＩＰメッセージは、当該パケットにその全体が収容されることも、内部サーバ３６０から発信される少なくとも１つの後続パケットにまたがって収容されることもある。ＳＩＰメッセージを抽出する上で更なるパケットが必要とされる場合には、ＳＩＰアプリケーション３５５は、ＳＩＰメッセージ全体が受信されるまで、ソケット３５６を経由する後続パケットを待つ。ＳＩＰアプリケーション・エンティティ３５５は、外部サーバ３９０に対してオープンの状態にあるＴＣＰ接続が既に存在するかどうかを判定する。そのような接続が存在しない場合には、ＴＣＰ接続がＳＩＰアプリケーション３５５によってオープンされる。最後に、当該パケットは、矢印３１３で示されるように外部サーバ３９０に送信され、ポート３９２を介して外部サーバ３９０内のＳＩＰアプリケーション３４９に送られる。

ＳＩＰロード・バランサ・ノード３５０とサーバ・ノード３６０との間のＴＣＰ／ＩＰ接続に関する後続パケットはまず、ＴＣＰ／ＩＰプロトコル・スタック３５２において処理され、そこからポリシー・エンティティ３５３に経路指定され、ポリシー・エンティティ３５３は、先に作成されたフィルタ・ルールに基づいて、当該パケットをローカルＴＣＰ／ＩＰプロトコル・スタック処理に再投入しなければならないことを判定する。ＴＣＰ／ＩＰプロトコル・スタック３５２において、再投入されたパケットは、当初からＳＩＰロード・バランサ・ノード３５０をターゲットとしているパケットの場合と同様に扱われるので、そのようなパケットが所期の宛先以外に経路指定される恐れはない。ＴＣＰ／ＩＰプロトコル・スタック３５２は、当該パケットを、初期のパケットの場合と同様にソケット３５６を経由してＳＩＰアプリケーション３５５に提供する。

図４は、本発明の一実施形態に係るＴＣＰ接続の多重化方法を示すフローチャートである。
ステップ４００で、サーバ・ノード用のパケット・フィルタが作成される。パケット・フィルタは、例えばサーバ・ノードがサーバ・クラスタに追加されたとき、又はパッシブ状態にある既存のサーバ・ノードがアクティブ状態に入ったときに作成される。サーバ・ノードは、パケットを外部ノードに向けて送信するために使用するソケットのうち、オープン状態にあるソケットに関する情報をＳＩＰロード・バランサ・ノードに知らせることができる。ステップ４０２で、ＳＩＰロード・バランサ・ノードはサーバ・ノードからのパケットを待つ。パケットが受信されない場合にはステップ４０２に進む。パケットが受信された場合にはステップ４０４に進む。

ステップ４０４で、ＳＩＰロード・バランサ・ノードは、それ自体のＴＣＰ／ＩＰプロトコル・スタックにおいてパケットを受信し、当該パケットが外部ノードにアドレス指定されていることを判定する。
ステップ４０６で、ＳＩＰロード・バランサ・ノードは、当該外部ノードのアドレス及びポートに関するソケットをオープンする。当該ＩＰアドレス及びポート番号は、サーバ・ノードから受信された入力パケットに基づいて宛先ＩＰアドレス及びＴＣＰポート番号を検査することによって判定される。

ステップ４０８で、ＳＩＰロード・バランサ・ノードは、当該外部ノード用のパケット・フィルタを作成する。当該パケット・フィルタでは、当該パケットが当初から送信者によってＳＩＰロード・バランサ・ノードにアドレス指定されている場合と同様に、入力パケット内で指定されるＩＰアドレス及びポート番号をターゲットとするパケットをプロトコル・スタックに再投入しなければならない旨の情報が指定される。
ステップ４１０で、現在のパケットは、ローカルＴＣＰ／ＩＰプロトコル・スタック内の処理に再投入される。

ステップ４１２で、現在のパケットは、ローカルＴＣＰ／ＩＰプロトコル・スタックによって処理された後、ステップ４０６でオープンされたソケットを経由してローカル・アプリケーション・エンティティに提供される。ローカル・アプリケーション・エンティティは、当該パケットからアプリケーション・プロトコル・メッセージに関するデータを取得する。アプリケーション・プロトコル・メッセージは、当該パケットにその全体が収容されることも、サーバ・ノードから発信される少なくとも１つの後続パケットにまたがって収容されることもある。アプリケーション・プロトコル・メッセージを抽出する上で更なるパケットが必要とされる場合には、ローカル・アプリケーション・エンティティは、アプリケーション・プロトコル・メッセージ全体が受信されるまで、ソケットを経由する後続パケットを待つ。

ステップ４１４で、ＳＩＰロード・バランサ・ノードは、外部ノードに対するＴＣＰ接続が存在するかどうかを判定する。当該ＴＣＰ接続が存在しない場合には、ステップ４１６で、外部ノードとの新しいＴＣＰ接続が確立される。

当該ＴＣＰ接続が存在する場合には、ステップ４１８で、既存のＴＣＰ接続を使用してアプリケーション・プロトコル・メッセージが外部ノードに転送される。当該アプリケーション・プロトコル・メッセージは、ＴＣＰ／ＩＰプロトコル・スタックに引き渡される。当該アプリケーション・プロトコル・メッセージは、最大伝送単位のサイズに応じて１つのパケット又はいくつかの別個のパケットに入れて送信される。

ＳＩＰアプリケーション３５５と、ＳＩＰ管理エンティティ３５４と、ポリシー・エンティティ３５３と、ＴＣＰ／ＩＰプロトコル・スタック３５２との間の通信は、内部フォーマットで実行される。ソフトウェア・コンポーネント、即ち図３に示される各エンティティは、様々な手法で実装することができる。これらのエンティティは、ネイティブ・オペレーティング・システムの下で実行されるプロセスとして実装することができる。当該ソフトウェア・エンティティは、別個のプロセスとして実装することも、いくつかの異なるソフトウェア・エンティティが１つのプロセスで実行されるように実装することもできる。いくつかのソフトウェア・エンティティは、別のエンティティとリンクするモジュールとして実装することもできる。

本発明の一実施形態において、オペレーティング・システムは、Ｌｉｎｕｘ（登録商標）オペレーティング・システムである。本発明の一実施形態において、ポリシー・エンティティ３５３とＳＩＰ管理エンティティ３５４との間の通信は、ネットワーキング・フックを使用してプロトコル・スタック・エンティティに取り付けられるローダブル・カーネル・モジュールとして実装される。当該カーネル・モジュールは、Ｎｅｔｌｉｎｋソケット・インターフェイスを使用することによってユーザ空間のＳＩＰ管理エンティティ３５４と通信する。ＳＩＰ管理エンティティ３５４は、送信元ＩＰアドレス及びポートを定義するルールをカーネル・モジュールに設定する。

ＴＣＰ ＳＹＮパケットがルールと一致すると、カーネル・モジュールは、受信されたＴＣＰ ＳＹＮパケットに従って新しいリスン対象ソケットをオープンさせる信号をＳＩＰ管理エンティティ３５４に送信した後、ＳＩＰ管理エンティティ３５４からの応答を受け取ると、当初のＴＣＰ ＳＹＮパケットをＩＰスタックに再投入する。再投入されたパケットは、先に作成されたリスン対象ソケットに届けられることになる。

本発明の一実施形態において、ＴＣＰ／ＩＰプロトコル・スタック・エンティティ３５２と、ポリシー・エンティティ３５３のフィルタリング機能とは、オペレーティング・システム・カーネルに含まれる。ポリシー・エンティティ３５３が有する他のエンティティとの通信機能は、ローダブル・カーネル・モジュールとして実装することができる。本発明の一実施形態において、ＳＩＰ管理エンティティ３５４及びＳＩＰアプリケーション３５５は、単一のアプリケーション・エンティティ、例えばシングル・プロセス又はスレッドとして実装することができる。

本発明の基本概念は、技術の進歩に伴い様々な手法で実施できることが当業者には明らかであるだろう。それ故、本発明及び本発明の諸実施形態は、上述の実施例に限定されるものではなく、添付の特許請求の範囲に記載の各請求項の範囲内で様々な形をとることができる。

従来技術の伝送制御プロトコル（ＴＣＰ）セグメント・ヘッダを示す図である。 従来技術のＴＣＰ接続ルータを含むクラスタ・サーバを示すブロック図である。 本発明の一実施形態に係るロード・バランサ・ノードを含むクラスタ・サーバを示すブロック図である。 本発明の一実施形態に係るＴＣＰ接続の多重化方法を示すフローチャートである。

Claims (27)

1. 少なくともフロント・エンド・ノードと少なくとも１つのサーバ・ノードとを含む通信システムにおいて外部ノードとの接続を確立する方法であって、前記少なくとも１つのサーバ・ノードは、前記フロント・エンド・ノードと通信するように構成され、前記フロント・エンド・ノードは、前記外部ノードと通信するように構成され、
   外部ノードに関連する宛先情報を含む第１のパケットを、前記少なくとも１つのサーバ・ノードから前記フロント・エンド・ノードに配信するステップと、
   前記フロント・エンド・ノードにおいて前記宛先情報に関連する終了ポイントを確立するステップと、
   を含む方法。
2. 前記宛先情報は、アドレスと、ポート番号と、を含む、請求項１に記載の方法。
3. 前記終了ポイントは、ソケットである、請求項１に記載の方法。
4. 前記フロント・エンド・ノードにおいて前記外部ノードとの接続を多重化するステップと、
   前記第１のパケットに由来するアプリケーション・データを、前記終了ポイントを経由して前記フロント・エンド・ノード内のアプリケーション・エンティティに提供するステップと、
   メッセージを前記アプリケーション・エンティティから前記外部ノードに送信するステップと、
   を更に含む、請求項１に記載の方法。
5. 前記フロント・エンド・ノードにおいて前記サーバ・ノードの少なくともアドレスを指定する第１のフィルタを作成するステップと、
   前記フロント・エンド・ノードにおいて前記第１のパケットを前記第１のフィルタに基づいて選択するステップと、
   前記フロント・エンド・ノードにおいて前記宛先情報を指定する第２のフィルタを作成するステップと、
   前記フロント・エンド・ノードにおいて前記第１のパケットを前記第２のフィルタに基づいて選択するステップと、
   を更に含む、請求項１に記載の方法。
6. 前記サーバ・ノードから発信され、前記外部ノードに関連する宛先情報を含む第２のパケットを、前記フロント・エンド・ノードに経路指定するステップと、
   前記フロント・エンド・ノードにおいて前記第２のパケットを前記第２のフィルタに基づいて選択するステップと、
   前記第２のパケットに由来するアプリケーション・データを、前記終了ポイントを経由して前記アプリケーション・エンティティに提供するステップと、
   前記メッセージを前記アプリケーション・エンティティから前記外部ノードに送信するステップと、
   を更に含む、請求項４に記載の方法。
7. 前記サーバ・ノードがアクティブ状態に入るステップと、
   前記サーバ・ノードが少なくともそれ自体のアドレスを前記フロント・エンド・ノードに送信するステップと、
   を更に含む、請求項１に記載の方法。
8. 前記第１のパケットは、同期化ビットの値を１とする伝送制御プロトコル・セグメントを含む、請求項１に記載の方法。
9. 前記フロント・エンド・ノードは、ロード・バランサ・ノードである、請求項１に記載の方法。
10. 前記サーバ・ノードは、セッション開始プロトコル（ＳＩＰ）サーバを含み、前記アプリケーション・エンティティは、セッション開始プロトコル（ＳＩＰ）エンティティである、請求項１に記載の方法。
11. 外部ノードとの接続を確立するシステムであって、
    前記外部ノードに関連する宛先情報を含む第１のパケットを送信するように構成された少なくとも１つのサーバ・ノードと、
    前記サーバ・ノードから前記第１のパケットを受信し、
    前記宛先情報に関連する終了ポイントを確立する
    ように構成されたフロント・エンド・ノードと、
    を備えるシステム。
12. 前記宛先情報は、アドレスと、ポート番号と、を含む、請求項１１に記載のシステム。
13. 前記終了ポイントは、ソケットである、請求項１１に記載のシステム。
14. 前記外部ノードとの接続を多重化し、
    前記第１のパケットに由来するアプリケーション・データを、前記終了ポイントを経由して前記フロント・エンド・ノード内のアプリケーション・エンティティに提供し、
    メッセージを前記アプリケーション・エンティティから前記外部ノードに送信する
    ように構成された前記フロント・エンド・ノード
    を更に備える、請求項１１に記載のシステム。
15. 前記サーバ・ノードの前記少なくともアドレスを指定する第１のフィルタを作成し、
    前記第１のパケットを前記第１のフィルタに基づいて選択し、
    前記宛先情報を指定する第２のフィルタを作成し、
    前記第１のパケットを前記第２のフィルタに基づいて選択する
    ように構成された前記フロント・エンド・ノード
    を更に備える、請求項１１に記載のシステム。
16. 前記サーバ・ノードから発信され、前記宛先情報を含む第２のパケットを受信し、
    前記第２のパケットを前記第２のフィルタに基づいて選択し、
    前記第２のパケットに由来するアプリケーション・データを、前記終了ポイントを経由して前記アプリケーション・エンティティに提供し、
    前記メッセージを前記アプリケーション・エンティティから前記外部ノードに送信する
    ように構成された前記フロント・エンド・ノード
    を更に備える、請求項１５に記載のシステム。
17. アクティブ状態に入り、前記アクティブ状態に入ったことに応じて少なくともそれ自体のアドレスを前記フロント・エンド・ノードに知らせるように構成された前記サーバ・ノード
    を更に備える、請求項１１に記載のシステム。
18. 前記第１のパケットは、同期化ビットの値を１とする伝送制御プロトコル・セグメントを含む、請求項１１に記載のシステム。
19. 前記フロント・エンド・ノードは、ロード・バランサ・ノードである、請求項１１に記載のシステム。
20. 前記サーバ・ノードは、セッション開始プロトコル（ＳＩＰ）サーバを含み、前記アプリケーション・エンティティは、セッション開始プロトコル（ＳＩＰ）エンティティである、請求項１１に記載のシステム。
21. 外部ノードとの接続を確立するネットワーク・ノードであって、
    前記外部ノードに関連する宛先情報を含む第１のパケットをサーバ・ノードから受信するように構成されたプロトコル・スタック・エンティティと、
    前記宛先情報に関連する終了ポイントを確立するように構成されたアプリケーション・エンティティと、
    を備えるネットワーク・ノード。
22. 前記第１のパケットを、終了ポイントを経由してアプリケーション・エンティティに提供するように構成された前記プロトコル・スタック・エンティティと、
    メッセージを前記外部ノードに送信するように構成された前記アプリケーション・エンティティと、
    を更に備える、請求項２１に記載のネットワーク・ノード。
23. 前記サーバ・ノードの少なくともアドレスを指定する第１のフィルタを作成し、外部ノードに関連する宛先情報を指定する第２のフィルタを作成するように構成された管理エンティティと、
    前記第１のパケットをポリシー・エンティティに提供するように構成された前記プロトコル・スタック・エンティティと、
    前記第１のパケットを前記第１のフィルタに基づいて選択し、前記第１のパケットを前記第２のフィルタに基づいて選択するように構成されたポリシー・エンティティと、
    を更に備える、請求項２２に記載のネットワーク・ノード。
24. コンピュータ・プログラムであって、データ処理システム上で実行されたときに、
    前記サーバ・ノードから前記フロント・エンド・ノードに向けて発信され、外部ノードに関連する宛先情報を含む第１のパケットを受信するステップと、
    前記宛先情報に関連する終了ポイントを確立するステップと、
    を実行するように適合されたコードを含むコンピュータ・プログラム。
25. コンピュータ可読媒体に記憶される、請求項２４に記載のコンピュータ・プログラム。
26. 前記コンピュータ可読媒体は、取り外し可能なメモリ・カードである、請求項２５に記載のコンピュータ・プログラム。
27. 前記コンピュータ可読媒体は、磁気ディスク又は光ディスクである、請求項２５に記載のコンピュータ・プログラム。

Images