JP2012038299A - コンテンツ中心ネットワークを介するサービス仮想化 - Google Patents

Abstract

【課題】ネットワークサービスの仮想化を容易にするシステムを提供する。
【解決手段】システムはクライアントからサービス要求を受信し、そのクライアントとの通信セッションを初期化する。システムは、クライアントおよび／または先の通信セッションを識別することのできるセッションステート情報を用いてインタレストを構築する。インタレストは、階層構造化された可変長名称で構成される。このシステムは、そこで幾つかのサーバに対しインタレストを同報通信する。システムは、続いてそのインタレストに応答するサーバから受信したクライアントデータを転送する。
【選択図】図１Ａ

Description

本開示は、概ねコンテンツ中心ネットワークに関する。より具体的には、本開示はコンテンツ中心ネットワークを介するサービス仮想化を容易にする装置および方法に関する。

本発明の一実施形態は、ネットワークサービスの仮想化を容易にするシステムを提供するものである。処理期間中、システムはクライアントからサービス要求を受け取り、クライアントとの通信セッションを開始する。システムは、クライアントおよび／または先の通信セッションを識別することのできるセッションステート情報を用いてインタレストを構築する。インタレストは、階層構造化された可変長の名称で構成される。このシステムは、そこで幾つかのサーバにインタレストを同報通信する。その後、システムは、インタレストに最初に応答するサーバから受信したクライアントデータを転送する。

本実施形態の一つの変形例では、システムは非選択サーバからの将来の応答を無視する。

本実施形態の一つの変形例では、データは伝送制御プロトコル（ＴＣＰ：ｔｒａｎｓｐｏｒｔ ｃｏｎｔｒｏｌ ｐｒｏｔｏｃｏｌ）セッション上でクライアントに転送され、インタレストにはＴＣＰセッション識別子が含まれる。

さらなる変形例では、セッションステート情報はハイパーテキスト転送プロトコル（ＨＴＴＰ：ｈｙｐｅｒｔｅｘｔ ｔｒａｎｓｆｅｒ ｐｒｏｔｏｃｏｌ）クッキーを含む。

本実施形態の一つの変形例では、データはセキュア・ソケット・レイヤ（ＳＳＬ：ｓｅｃｕｒｅ ｓｏｃｋｅｔ ｌａｙｅｒ）セッションを介してクライアントへ転送される。

さらなる変形例では、セッションステート情報はＳＳＬセッション識別子を含む。

本実施形態の一つの変形例では、システムは第１のサーバからのサービス要求に応答するパケットを受け取る。対応するセッションステート情報はパケット名内に埋め込まれ、それによって第１のサーバが通信セッション用にクライアントからさらなるパケットを受信するのを容易にする。

本実施形態の一つの変形例では、システムはクライアントから第２のサーバにパケットを転送する。第２のサーバは、第１のサーバからのセッションに関連するセッションステート情報を受け取る構成とする。

さらなる変形例では、第１のサーバからのセッションステート情報の受信には、セッションステート情報に対するインタレストを第２のサーバから全サーバに同報通信することと第１のサーバからの応答を受けることが含まれる。この応答は、通信セッションに関連するセッションステート情報を含んでおり、それによって第２のサーバ上で通信セッションが継続できるようにしてある。

本実施形態の一つの変形例では、システムは第１のサーバに対するバックアップ用サーバとして第２のサーバを選択する。第２のサーバは、通信セッションに関連するセッションステート情報の複製を保持するよう構成する。システムは、第１のサーバの故障に応答して第２のサーバへクライアントからパケットを転送し、セッションステート情報の複製を用いて第２のサーバ上で通信セッションを再構築する。

本実施形態の一つの変形例では、システムはインタレストに最初に応答するサーバへ確認応答を送信する。

本発明の一実施形態による例示ネットワーク・アーキテクチャを示す線図を提示する。 本発明の一実施形態によるロードバランサ／プロキシサーバの構造を示すブロック線図を提示する。 本発明の一実施形態によりＴＣＰクライアントとＣＣＮサーバとの間のＴＣＰ接続をエミュレートする方法を示すフローチャートを提示する。 本発明の一実施形態によりＴＣＰクライアントとＣＣＮサーバとの間でＳＳＬセッションを確立する方法を示すフローチャートを提示する。 本発明の一実施形態によるＣＣＮを介するサービス仮想化を容易にする例示コンピュータシステムを提示する。

図面中、同様の参照符号は同一の図面要素を指す。

本発明の実施形態は、効果的かつ確実に複数サーバ全体にサーバ機能を配布するネットワークサービス仮想化を容易にするものである。処理期間中、クライアントはプロキシサーバに対しネットワークサービスを要求し、このサーバが全サーバに同報通信するインタレストを構築する。サーバの応答に基づき、プロキシサーバはクライアントの要求を転送する一つのサーバを選択する。勝者が宣言された後、他のサーバはその応答を抑制し、クライアントと選択されたサーバとの間にセッションが確立される。選択されたサーバに一旦セッションが確立されると、システムはＣＮＮ命名法を用いて選択されたサーバとの間でそのセッションに関するパケットを相互に通信することができる。

一部実施形態では、セッションステートはパケットのＣＣＮ名内に埋め込まれ、パケットと共に移動し、したがってステートレス・プロキシサーバを作動可能とする。一部実施形態では、確立されたセッションは一方のサーバから他方へ移動させることができ、ステート情報は先のサーバからそこでセッションが確立されたそのときのサーバにステート情報を引き込むことができる。

コンテンツ中心ネットワーク（ＣＣＮ）では、通信はデータの消費者により駆動される。ＣＣＮでは、２つのパケットの種類、すなわちインタレストとデータとが存在する。インタレストパケット（照会とも呼ぶ）は、何らかのコンテンツに対する要求である。インタレストパケットは、どのコンテンツが所望され、どのコンテンツが不要であるかを表明する特別な形式の照会をエンコードする。データパケット（コンテンツパケットとも呼ばれる）は、コンテンツの１単位である。データパケットは、それらと共にそれらのフルネームを担持することで自己識別する。消費者は、全ての利用可能な接続性を介してそのインタレストを同報通信することで、コンテンツを要求することができる。インタレストを聴取し、それを満たすデータを有するあらゆるノードが、データパケットで応答することができる。データはインタレストだけに応答して送信され、そのインタレストを消費する。インタレストとデータは共に、コンテンツ名（またはＣＣＮ名）により交換されるコンテンツを識別する。一実施形態では、インタレストパケットのＣＣＮ名がデータパケットのＣＣＮ名の接頭辞である場合、データはインタレストを「満たす」ことができる。

ＣＣＮ名は、明示的に特定された数の構成要素から成る不透明な２値オブジェクトである。加えて、ＣＣＮ名は持続的でコンテンツに特有である。すなわち、ファイルあるいはデータオブジェクトのコンテンツを誰かが変更した場合、そのコンテンツは新規名称に効果的に関連付けられる。この持続性は、明示的な版管理装置をもって獲得することができ、ここで、例えば新規コンテンツは所与の名称「第４版」とすることができる。持続性は、暗示的に達成することもできる。例えば、コンテンツはその人が設定した名称だけでなく、認証用メタデータ（例えば、コンテンツの発行人によるデジタル署名）にも関連付けることができる。その結果、所与の名称に関連するデータが変化するときは全コンテンツ名が変化する。

機能的には、ＣＣＮはそれらが表わす様々な名称とコンテンツとの間で関連性を保持することができる。その名称は階層構造化され、可変長を有しており、多くの状況においてユーザが理解することができる。例えば、「／ａｂｃｄ／ｂｏｂ／ｐａｐｅｒｓ／ｃｃｎ／ｎｅｗｓ」は記事の名称、すなわち「ＡＢＣＤ」という名の組織の「Ｂｏｂ」という名のユーザに向けた収蔵論文集「ｃｃｎ」からの「ｎｅｗｓ」記事としうる。ＣＣＮでは、アプリケーションの見地からは、「ＡＢＣＤ」組織を如何に見いだすかをコンテンツ消費者が判定したり、あるいはＢｏｂのＣＣＮ出版物をどのホストが保有しているかを見いだしたりする必要は一切ない。一実施形態では、一片のコンテンツを要求する上で、ＣＣＮ内の装置はそのコンテンツにその名称により関心を抱いている点と、そのコンテンツがローカルネットワーク内で入手可能である場合に、これを自らに経路誘導する点とを、ネットワークに登録する。経路誘導基盤は、見込みのある発行人にインタレストを知的に伝搬し、続いてインタレストが横切る経路に沿ってあらゆる利用可能なコンテンツを戻すよう取り計らう。

ＣＣＮは、それらを格別に魅力的なものにするための追加の属性を有する。全てのコンテンツは暗号によって認証することができ、すなわちネットワーク上のノードの一部の部分集合（例えば、コンテンツの合法的な照会者）が一片のコンテンツの真正さを検証することができる。ＣＣＮはまた、発行人とは無関係にデータが名称によりアクセスできるようにする。同時に、しかるべき発行人によるデータについて特別な要求を特化することができる。例えば、「ｆｏｏ．ｔｘｔ」あるいは「Ｂｏｂが署名したｆｏｏ．ｔｘｔ」を請求することができる。製作者と消費者間の契約として、任意の形態の自己検証名を用いることができる。混成自己検証名を使用することも可能であり、ここでは名称の前半の構成要素が組織用および効率的な経路誘導用とされ、名称の後半の構成要素が自己検証用とされる。最後に、ＣＣＮはコンテンツと信用の分離を可能にし、異なるデータ消費者が同じコンテンツ片において信用を確立する異なる装置を使用できるようにする。コンテンツは単一の発行人により署名しうるが、異なる理由で信用することができる。例えば、一人のユーザはその署名者との直接の個人的な関係が故に所与のコンテンツ片を信用することができ、これに対し別のユーザはこのユーザが信用できると選択した公開鍵基盤（ＰＫＩ：Ｐｕｂｌｉｃ Ｋｅｙ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）におけるコンテンツ署名者の参加によって同一コンテンツを信用しうる。

ネットワークサービスの仮想化は、複雑なネットワーク・アーキテクチャに対処する上で極めて重要とされてきた。ＣＣＮは、従来のＴＣＰ／ＩＰネットワークを含む様々なネットワーク環境で仮想化ネットワークサービスを実施する貴重なツールとすることができる。

従来のＴＣＰ／ＩＰネットワークでは、サービス仮想化はＴＣＰセッションステート情報を維持管理するロードバランサ（負荷分散装置）を介して実行することができる。クライアントからのサービス要求を処理するときに、ロードバランサはクライアントに対するＴＣＰクッキーを調べ、サーバのいずれか一つにＴＣＰセッションステート情報が事前に存在するかどうか判定することができる。存在する場合、ロードバランサは対応するサーバへ要求を導くことができる。そうでなければ、ロードバランサはランダム・ラウンドロビン方式に基づくかあるいはサーバの負荷に基づきサーバを選択する。しかしながら、ＣＣＮに結合されたサーバのサービス仮想化は、ＴＣＰ／ＩＰネットワークのそれとは異なるものである。

図１Ａは、本発明の一実施形態に従う例示ネットワーク・アーキテクチャを示す線図を提示するものである。ネットワーク１００は、クライアント１０２〜１０６を含む幾つかのクライアントと、サーバ１０８〜１１２を含む幾つかのサーバとを含む。クライアント１０２〜１０６は従来のＴＣＰ／ＩＰネットワーク１１６を介してプロキシサーバ１１４に結合され、サーバ１０８〜１１２はＣＣＮ１１８を介してプロキシサーバ１１４に結合してある。クライアント１０２〜１０６は計算処理能力とネットワークを介する通信装置とを用いＴＣＰ／ＩＰネットワーク１１６上でノードを表示できることに、留意されたい。例えば、クライアント１０２〜１０６は、パーソナルコンピュータ（ＰＣ）やラップトップ型コンピュータやワークステーションおよび／またはネットワーク接続性を有する他の電子計算装置に対応させることができる。さらにまた、クライアント１０２〜１０６は有線および／または無線接続を用いてＴＣＰ／ＩＰネットワーク１１６に結合することができる。同様に、サーバ１０８〜１１２はクライアント１０２〜１０６からのサービス要求に対する機能性を含むノードに対応させることができる。サーバ１０８〜１１２は、計算クラスタあるいは独立型サーバとすることができる。プロキシサーバ１１４は、サーバ１０８〜１１２からリソースを見いだすクライアント１０２〜１０６からの要求のための仲介者として機能する。一実施形態では、プロキシサーバ１１４は、クライアント１０２〜１０６からのＴＣＰ接続を処理し、ハイパーテキスト転送プロトコル（ＨＴＴＰ）要求を受信することのできるロードバランサとする。加えて、プロキシサーバ１１４は、サーバ１０８〜１１２内のクライアント１０２〜１０６からのＨＴＴＰ要求を配信することができる。一実施形態では、プロキシサーバ１１４は従来のＴＣＰ／ＩＰネットワークと、ＨＴＴＰとセキュア・ソケット・レイヤ（ＳＳＬ）プロトコルとの組み合わせであるハイパーテキスト転送プロトコル（ＨＴＴＰ）等の固定サービスを仮想化することのできるＣＣＮとの間に位置する境界ゲートウェイである。

処理期間中、クライアント（クライアント１０２等）はＴＣＰ／ＩＰネットワーク１１６を介してプロキシサーバ／ロードバランサ１１４にネットワークサービスを要求する。例えば、クライアント１０２はＨＴＴＰ要求を用いロードバランサ１１４からウェブページを要求することができる。ＴＣＰ接続は、標準のスリーウェイ・ハンドシェイクを介してクライアント１０２とロードバランサ１１４との間に確立することができる。スリーウェイ・ハンドシェイク工程には、下記が含まれることに留意されたい。すなわち、（１）サーバにＴＣＰ同期（ＳＹＮ）パケットを送信するクライアント、（２）ＳＹＮパケットを受信し、クライアントに同期確認応答（ＳＹＮ−ＡＣＫ）パケットを送信するサーバ、（３）サーバにＡＣＫパケットを送信するクライアントである。

スリーウェイ・ハンドシェイクを完成した後、ロードバランサ１１４はクライアントを特定するのに役立てることができ、既存のセッションが存在していたかどうか判定できる情報に対するクライアント要求を検査する。その場合、ロードバランサ１１４はこの種の情報に基づきＣＣＮインタレストを構築する。一実施形態では、この種の情報にはセッションステートを含めることができる。クライアント要求がＨＴＴＰ要求である場合、ロードバランサ１１４はクライアント１０２が送信したＨＴＴＰクッキー（それが在る場合）を試験し、そのクッキーに基づきＣＮＮインタレストパケットを構築する。一実施形態では、インタレストパケットに含まれるＣＣＮ名はＴＣＰ接続およびクッキーに関連する情報を含む。例えば、ＣＣＮ名には下記の名称を含めることができる。すなわち、／ＳＹＮ／＜５Ｔ＞／＜ｃｏｏｋｉｅ＞／＜ｓｅｑ＞／＜ｍｙ．ｓｅｑ＞／ここで、＜５Ｔ＞はＴＣＰ接続用の５タプルの移送署名であり、＜ｓｅｑ＞はクライアント１０２により選択された無作為順序番号であり、＜ｍｙ．ｓｅｑ＞はロードバランサにより選択された確認応答順序番号（その値はクライアント順序番号を１だけ上回る）である。５タプルの移送署名が下記を含む点に留意されたい。すなわち、｛送信元ＩＰアドレス、送信元ポート番号、送信先ＩＰアドレス、送信先ポート番号、接続タイプ｝を含み、ここで「接続タイプ」は「ＴＣＰ」あるいは「ユーザ・データグラム・プロトコル」（ＵＤＰ：ｕｓｅｒ ｄａｔａｇｒａｍ ｐｒｏｔｏｃｏｌ）等の移送レイヤプロトコルを識別するものである。

ロードバランサ１１４は、全サーバにそのインタレストを同報通信する。各サーバはそこでＣＣＮ名内に含まれるクッキーを検査し、クライアント１０２とサーバとの間に既存のセッションが存在するかどうか判定することができる。整合セッションを有するサーバは、適時態様にてインタレストに応答する筈であり、したがってそれはロードバランサ１１４により選択することができるようになる。例えば、サーバ１０８はロードバランサ１１４に応答を送信し、サーバ１０８がクライアント１０２へ送信するクッキーにクライアント１０２が送信するクッキーが整合することを示す。ネットワーク内の他のサーバは、サーバ１０８の応答を観察した後、インタレストに対する応答を差し控える。その後、ロードバランサ１１４はサーバ１０８の応答を承認し、その選択を全サーバに表明することができる。インタレストに応答する２以上のサーバが存在する場合、ロードバランサ１１４は応答サーバのうちの１つを選択することができる。一実施形態では、ロードバランサ１１４は下記のストリング、すなわち／ＳＹＮ／＜５Ｔ＞／＜ｃｏｏｋｉｅ＞／＜ｓｅｑ＞／＜ｍｙ．ｓｅｑ＞／Ｓｅｒｖｅｒ １０８／を含むＣＣＮ名を有するインタレストパケットを同報通信し、サーバ１０８が選択されたことを示す。サーバ１０８はロードバランサ１１４に応答し、選択されたサーバとしてそれ自体を確認するのに対し、サーバ１１０〜１１２を含む他のサーバは同じセッションに関するロードバランサ１１４のインタレストに対する応答を停止する。一旦確認されると、クライアント１０２とサーバ１０８の間にセッションが確立される。クライアント１０２からのそのセッションに関する将来のパケットは、ロードバランサ１１４によりＣＣＮパケットに変換される。これらのＣＣＮパケットの命名法は、同一セッションに関するパケットが選択されたサーバ１０８に転送されることを保証するものである。例えば、これらのパケットのＣＣＮ名は選択されたサーバ１０８を特定することができる。ＣＣＮサーバ１０８〜１１２の存在とサーバのうちの１つに要求が転送される事実とをクライアント１０２が知らない点に、留意されたい。クライアント１０２は、クライアント１０２とロードバランサ１１４との間に確立された従前のＴＣＰ接続に気づくだけである。

図１Ｂは、本発明の一実施形態によるロードバランサ／プロキシサーバの構造を示すブロック線図を提供するものである。ロードバランサ１２０は、受信装置１２２と接続装置１２４とインタレスト構築装置１２６と同報通信装置１２８とサーバ選択装置１３０とセッション確立装置１３２とを含む。処理期間中、受信装置１２２はクライアントから接続要求を受信し、接続装置１２４はロードバランサ１２０とクライアントとの間に接続を確立する。インタレスト構築装置１２６は、クライアント要求に基づきインタレストを構築する。要求中にクッキーが存在する場合、構築されたインタレストのＣＣＮ名はクッキーを含む。同報通信装置１２８は、全ての聴取サーバにインタレストを同報通信する。サーバ選択装置１３０は、サーバから受信した応答に基づきサーバを選択する。サーバ選択装置１３０はさらに全サーバにその選択を表明し、選択されたサーバからの確認を受信する。一旦確認されると、セッション確立装置１３２はクライアントと選択されたサーバとの間にセッションを確立する。

図２は、本発明の一実施形態に従うＴＣＰクライアントとＣＣＮにより作動可能とされるサーバとの間のＴＣＰ接続をエミュレートする工程を示すフローチャートを表わす。処理期間中、ロードバランサはクライアントとのスリーウェイ・ハンドシェイクを完成する（処理２０２）。ロードバランサはそこで、クライアントからの要求がクッキーを含むかどうか判定する（処理２０４）。そうである場合、ロードバランサは、クッキーに基づきインタレストを構築する（処理２０６）。そうでなければ、ロードバランサはクッキーを参照しないインタレストを構築する（処理２０８）。一実施形態では、ロードバランサは５タプルの移送署名に基づきインタレストを構築する。その後、ロードバランサは全サーバにインタレストを同報通信（処理２１０）し、幾つかのサーバからの応答を受信（処理２１２）する。ロードバランサはそこで、サーバからの応答に基づきサーバを選択し、全サーバに同報通信するインタレストパケット内で勝者を表明（処理２１４）する。表明を受信した後、選択されたサーバはそのステートをロードバランサに対する勝者として確認し、このように選択されたサーバとクライアントとの間にセッションを確立（処理２１６）する。

セキュア・ソケット・レイヤ（ＳＳＬ）あるいはトランスポート・レイヤ・セキュリティ（ＴＬＳ）プロトコルは、移送レイヤにおいてネットワーク接続のセグメントを暗号化することで、インターネット等の安全でないネットワークを介する通信に対する安全性を提供する。ＨＴＴＰとＳＳＬ／ＴＬＳとの組み合わせはＨＴＴＰＳ接続をもたらし、これがワールド・ワイド・ウェブ（ＷＷＷ）上の支払いトランザクションや企業情報システム内の厄介なトランザクションにしばしば用いられる。ＳＳＬ／ＴＬＳを実装する他のアプリケーションには、ウェブ閲覧、電子メール、インターネットファックス通信、インスタントメッセージ発信、およびボイスオーバーＩＰ（ＶｏＩＰ）が含まれる。

ＳＳＬ／ＴＬＳは広範に用いられているが、既存のインターネットＳＳＬサービスの仮想化はＣＣＮを実装していない従来のネットワークでは難題のまま残る。ＳＳＬを実装する従来のネットワークでは、ＨＴＴＰクッキーは暗号化され、ロードバランサがセッションごとに新規のＨＴＴＰパケットを送信する先を特定することができるようにする。この種の問題に対処するため、しばしばＳＳＬ加速器を用い、ＳＳＬサービスを終結させ、ロードバランサがクッキーに基づき親和性に対する良好な判断が下せるようにする。しかしながら、加速器でのＳＳＬセッションの終了は危険な境界を生み出す。

ＣＣＮでは、この種の問題は、クライアントとサーバとの間に最後まで暗号化が関係する完全な端末間の確実な接続を確立することで解決することができる。一実施形態では、ＴＣＰクライアントとＣＣＮサーバとの間に位置するロードバランサ（図１に示したロードバランサ１１４同様）は、既存のセッションに関連する暗号ステート情報に基づきインタレストを構築する。暗号ステートを維持するサーバは、他の全サーバに先だってこの種のインタレストに応答し、したがってロードバランサがこの種のサーバを選択できるようにする。一実施形態では、ロードバランサはＴＣＰ／ＩＰ ＳＳＬセッションＩＤを用いてインタレストを構成することができる。加えて、確実なサービス（ＨＴＴＰ等）との効率的な負荷均衡は、サーバがＳＳＬステートデータを交換し、新規あるいは既存のＳＳＬセッションを検出しあるいは処分できるようにすることで達成することができる。その結果、ロードバランサは、過負荷を抱えることなく、ネットワークアドレス変換器（ＮＡＴ：ｎｅｔｗｏｒｋ ａｄｄｒｅｓｓ ｔｒａｎｓｌａｔｏｒ）背後の多数のクライアントの結果とすることのできる任意の数の同時ＳＳＬセッションを扱うことができる。

図３は、本発明の一実施形態に従いＴＣＰクライアントとＣＣＮにより作動可能とされるサーバとの間のＳＳＬセッション確立工程を示すフローチャートを提示するものである。処理期間中、ロードバランサ（あるいはそれがＴＣＰネットワークとＣＣＮとの間の境界に常駐するが故に境界エージェント）はクライアントからパケットを受信し、標準的なスリーウェイ・ハンドシェイクを介してＴＣＰ接続を確立（処理３０２）する。ロードバランサはそこで、ＳＳＬセッション情報に基づきインタレストパケットを構成する（処理３１０）。一実施形態では、ロードバランサはＳＳＬセッションＩＤ（またはチケット）を用いてインタレストを構築する。加えて、ＴＣＰ移送署名（５タプル）もまた、既存の接続を識別すべく構築されたインタレストに含めることができる。

その後、ロードバランサは全サーバにインタレストを同報通信する（処理３１４）。応答時、整合セッション情報を有するサーバはインタレストを満たす素早い応答を送出することができる。この応答は同報通信ドメインにて送信されるため、この応答を他のサーバが観測することができる。その結果、追加的なサーバは一切応答を送信しない筈である。その後、ロードバランサは勝者として最初に応答するサーバを随意選択的に承認し、その選択を表明（処理３１６）する。セッションＩＤがインタレストのＣＣＮ名に含まれる場合、セッションＩＤに整合するセッションステート情報を保存するサーバが先ず要求に応答することになることに、留意されたい。複数サーバが応答する稀な事例（例えば、どのサーバも整合セッション情報を有しておらず、幾つかのサーバが、それらがインタレストに対し応答を送出する前に無作為抽出された遅延量を待機する場合）では、ロードバランサは最初に応答するサーバを選択することができる。ロードバランサは、選択されたサーバに随意選択的に確認を送信することができる。加えて、インタレスト内にセッションＩＤが一切含まれない場合、一つのサーバが既にインタレストのＣＣＮ名における何らかのものに合致させることのできる特定のソフトステート情報を有する場合、そのサーバは新規接続を立ち上げる必要のある他のサーバよりも素早く応答することになる。

その後、選択されたサーバは随意選択的にそのステートを勝者として確認（処理３１８）し、他の全サーバは接続要求に対する応答を停止する。選択されたサーバ上で一旦ＳＳＬセッションが確立されると、ロードバランサが選択されたサーバを参照することでＳＳＬセッション用の接続に関する将来のインタレストを構築し、したがってそのセッションに関する全ての将来のパケットをその選択されたサーバとの間でやり取りする。

セッションＩＤに加え、一部実施形態では、他のセッションステート情報をＣＣＮ名中に埋め込み、したがってステートレス・ロードバランサ／プロキシサーバを可能にすることもできる。一般に、ステートフル・プロキシサーバは、進行中のトランザクションのステートに関する情報を保持するプロキシサーバである。ステート情報には、全ての記憶ステート変数とその値とを含めることができる。特定の集合の値が、ステートを画定する。プロキシサーバは、そのステート変数の値が変化するたびにステートを変える。ステートレス・プロキシサーバは、進行中のトランザクションのステートに関する情報を記憶しないサーバである。ステートレス・プロキシサーバは記憶ステート情報に基づくのではなく、所与の命令（受信データ）にのみ応じて反応する。

本発明の一部実施形態では、一つのサーバ上で確立されたセッションは様々な理由から異なるサーバへ移転することができる。一つのシナリオでは、セッションの均衡を図りあるいは整理統合すべく、ピーク期間中に副サーバを用い主サーバからトラフィックをオフロードすることができる。さらなるシナリオでは、トラフィックロードはエネルギー管理のために一日のうちの時間の関数として拡張しあるいは均衡させることができる。例えば、サービスプロバイダは、データセンターでの冷房コストを低減すべく、沈みゆく太陽に追従して集中的データ処理を或る場所から或る場所へ移すよう選択することができる。さらに、システムは、主サーバの故障が故にあるいは主サーバへのネットワーク接続の劣化が故に、既存のセッションを副サーバへ移すことが必要となることもある。

セッションが主サーバから副サーバへ移ると、副サーバはセッションステートの事前知識は一切有しておらず、何処からかセッションステートを取得する必要がある筈である。主サーバが依然として機能を果たしている場合、副サーバは主サーバからセッションステートを取得することができる。そうでなければ、副サーバは第３のエンティティからセッションステートを取得し、あるいはセッションステートのバックアップコピーを保存する必要がある筈である。

図４は、本発明の一実施形態に従いＣＣＮを介してサービス仮想化を容易にする例示コンピュータシステムを提示するものである。図４中、コンピュータおよび通信システム４００は、プロセッサ４０２とメモリ４０４と記憶装置４０６とを含んでいる。記憶装置４０６は、プロセッサ４０２が実行するプログラムを記憶する。具体的には、記憶装置４０６はサービス仮想化アプリケーション４０８と、加えてアプリケーション４１０や４１２等の他のアプリケーションもまた記憶する。処理期間中、サービス仮想化アプリケーション４０８は記憶装置４０６からメモリ４０４へロードされ、続いてプロセッサ４０２により実行される。プログラムの実行時に、プロセッサ４０２は前述の機能を遂行する。コンピュータおよび通信システム４００は、随意選択的なディスプレイ４１４とキーボード４１６とポインティングデバイス４１８とに結合してある。

Claims (10)

1. ネットワークサービスの仮想化を容易にするコンピュータが実行可能な方法であって、
   クライアントからサービス要求を受け取る工程と、
   クライアントとの通信セッションを開始する工程と、
   クライアントおよび／または先の通信セッションを識別することのできるセッションステート情報を用いてインタレストを構築する工程で、該インタレストが階層構造化された可変長の名称を含む前記工程と、
   前記インタレストを幾つかのサーバへ同報通信する工程と、
   前記インタレストに先ず応答するサーバから受信したクライアントデータを転送する工程とを含む、方法。
2. 非選択サーバからの将来の応答を無視する工程をさらに含む、請求項１に記載の方法。
3. 前記データは伝送制御プロトコル（ＴＣＰ）セッションを介してクライアントへ転送し、前記インタレストはＴＣＰセッション識別子を含む、請求項１に記載の方法。
4. 前記セッションステート情報は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）クッキーを含む、請求項３に記載の方法。
5. 前記データはセキュア・ソケット・レイヤ（ＳＳＬ）接続を介してクライアントへ転送する、請求項１に記載の方法。
6. 前記セッションステート情報は、ＳＳＬセッション識別子を含む、請求項５に記載の方法。
7. 第１のサーバからのサービス要求に応答するパケットを受信する工程をさらに含み、対応するセッションステート情報はパケット名内に埋め込まれ、それによって前記第１のサービスが前記通信セッション用にクライアントから将来のパケットを受信するのを容易にする、請求項１に記載の方法。
8. さらに、前記クライアントから第２のサーバへパケットを転送する工程を含み、前記第２のサーバは前記第１のサーバから前記通信セッションに関連するセッションステート情報を受信する構成とした、請求項１に記載の方法。
9. 前記第１のサーバからセッションステート情報を受信する工程は、前記セッションステート情報に関するインタレストを前記第２のサーバから全サーバへ同報通信する工程と、
   前記第２のサーバにおいて前記第１のサーバからの応答を受信する工程で、該応答が前記通信セッションに関連する前記セッションステート情報を含み、それによって前記通信セッションを前記第２のサーバ上で継続できるようにする工程とを含む、請求項８に記載の方法。
10. さらに、第２のサーバを前記第１のサーバに対するバックアップサーバとして選択する工程で、前記第２のサーバが前記通信セッションに関連するセッションステート情報の複製を保持するよう構成された工程と、
    前記第１のサーバの故障に応答し、前記第２のサーバに前記クライアントからパケットを転送する工程と、
    前記セッションステート情報の複製を用い、前記第２のサーバ上で前記通信セッションを再構築する工程とを含む、請求項１に記載の方法。