JP4942921B2 - ホスト状態情報を用いるネットワーク負荷分散 - Google Patents

Description

この開示は、一般にネットワーク負荷分散（ｎｅｔｗｏｒｋ ｌｏａｄ ｂａｌａｎｃｉｎｇ）に関し、詳細には、制限ではなく例として、ホスト状態情報を用いるネットワーク負荷分散に関する。

通信、および通信と絡む生活の多数の様相は、インターネットによって大きく影響を受けた。インターネットによって、２人の人および／または２つのエンティティの間ですばやく比較的簡単に情報を通信することができる。インターネットには、情報を人および／またはエンティティの間で転送できるように共にリンクされた多数のネットワークノードが含まれる。一部のネットワークノードは、あるリンクから別のリンクへパケットを伝搬するルータであり、個々のクライアントコンピュータであり、異なるエンティティのパーソナルネットワーク（会社のイントラネットなど）である。

このパーソナルネットワークの場合ならびに他の場合において、１つまたは複数のインターネットノードに到着するパケットは、パーソナルネットワーク内の他のノードに分散される。そのようなパーソナルネットワークは、たとえば、パーソナルネットワークに到着するパケットに対してそれぞれ作用する一連のサーバから形成され得る。会社、大学、官庁などは、そのパーソナルネットワークにおいて、短いタイムフレームに多数のパケットを受信する場合がある。タイムリーに応答し、到着パケットの拒否または消失の可能性を減らすために、パーソナルネットワークは、各々が到着パケットを同時に処理できる複数のサーバに依存する場合がある。

到着パケットは、文書、カタログ品目、ウェブページ等のある種の情報に関する質問である場合が多い。到着パケットは、顧客と販売者の間の経済上の取引に関する場合もある。パケットベース通信のパケットには、他の目的が考えられる。いずれにせよ、到着パケットを一連のサーバの中の異なるサーバ間で分散させることにより、素早く到着するパケットおよび／または複雑な通信交換に対応する。

一連のサーバの中の異なるサーバ間で到着パケットを分散（ｄｉｓｔｒｉｂｕｔｉｏｎ）することは、ネットワーク負荷分散と称される場合が多い。言い換えると、負荷分散動作は、１つまたは複数のノードがパーソナルネットワークを構成する場合、および／またはそれらがパーソナルネットワークをインターネットに接続する場合、パケットがインターネットの１つまたは複数のノードに到着するときに、それらのパケットに対して実行され得る。

そのような負荷分散動作は、パーソナルネットワークをインターネットに接続し、かつ／またはインターネット上のパーソナルネットワークの存在を提供する１つまたは複数のノードでパーソナルネットワークに面する専用ハードウェアを使用することにより達成される。負荷分散動作を実行する物理的ハードウェアは、通常は、完全に複製化され、冗長性を実現し、負荷分散動作の可用性を高める。負荷分散動作の能力を高めるために、前の負荷分散ハードウェアの全体を複製し、その動作機能を複製する一層強力なハードウェアを前の負荷分散ハードウェアと置き換える。したがって、そのような負荷分散動作能力を高めることは、置き換えによってハードウェアのパワーを高めることに限られる。

負荷分散動作を実施するために、ハードウェアは、通常、到着する接続リクエストのラウンドロビン分散を実行する。言い換えると、到着する接続リクエストは、単一の接続リクエストを各サーバに分散する方法を繰り返して、一連のサーバの中のサーバに線形的に分散される。この接続のラウンドロビン負荷分散分配は、通常は、パーソナルネットワークの状態または到着する接続リクエストの種類とは関係なく利用される。負荷分散動作が、ラウンドロビン分散を超えて拡大される場合、これらの他の要因は、ネットワークトラフィックおよび／またはパーソナルネットワークの輻輳レベルから推論できる範囲で考慮されるに過ぎない。

したがって、ネットワーク負荷分散および／またはそれと関連するオプションを改善する方式および／または技法が必要である。

第１の例示的媒体実施形態では、１つまたは複数のプロセッサアクセス可能媒体に、プロセッサ実行可能命令が含まれ、前記プロセッサ実行可能命令は、実行されたとき、複数のホストでホスト状態情報を蓄積する動作と、前記複数のホストから前記蓄積されたホスト状態情報を送信する動作とを実行するようにシステムに指示する。第２の例示的媒体実施形態では、１つまたは複数のプロセッサアクセス可能媒体に、プロセッサ実行可能命令が含まれ、前記プロセッサ実行可能命令は、実行されたとき、システムに、複数のホストからホスト状態情報を受信する動作と、前記受け取ったホスト状態情報に応答して負荷分散判断を行う動作とを実行するように指示する。第３の例示的媒体実施形態では、１つまたは複数のプロセッサアクセス可能媒体に、プロセッサ実行可能命令が含まれ、前記プロセッサ実行可能命令は、実行されたとき、システムに、アプリケーションごとのベースでヘルス（ｈｅａｌｔｈ）および負荷情報を判定する動作と、前記ヘルスおよび負荷情報に応答して複数のアプリケーションの中からアプリケーションを選択する動作とを実行するように指示する。

第４の例示的媒体実施形態では、１つまたは複数のプロセッサアクセス可能媒体に、プロセッサ実行可能命令が含まれ、前記プロセッサ実行可能命令は、実行されたとき、システムに、複数のアプリケーションエンドポイントのヘルスおよび／または負荷情報を分析する動作と、前記分析に応答して、前記複数のアプリケーションエンドポイントのトークン割当を確定する動作とを実行するように指示する。

第５の例示的媒体実施形態では、１つまたは複数のプロセッサアクセス可能媒体に、プロセッサ実行可能命令が含まれ、前記プロセッサ実行可能命令は、実行されたとき、システムが少なくとも１つのホストと１つまたは複数の負荷分散ユニットとの間のメッセージプロトコルを実行できるようにし、前記メッセージプロトコルは、前記少なくとも１つのホストおよび前記１つまたは複数の負荷分散ユニットとの間でヘルスおよび／または負荷情報を通信するのに使用可能である。

例示的システム実施形態では、システムに、１つまたは複数のアプリケーションをホスト（ｈｏｓｔ）している少なくとも１つの装置であって、前記少なくとも１つの装置は、複数のエントリを含むヘルスおよび負荷テーブルを含み、前記複数のエントリの各エントリは、前記１つまたは複数のアプリケーションの中のアプリケーションに関連し、前記複数のエントリの中の各エントリは、前記１つまたは複数のアプリケーションの中の特定のアプリケーションのアプリケーション識別子と、前記特定のアプリケーションの少なくとも１つの状態の特性を表す情報と、前記特定のアプリケーションに関する少なくとも１つの負荷分散命令とを含む、少なくとも１つの装置が含まれる。

他の方法、システム、手法、装置、アプリケーションプログラミングインターフェース（ＡＰＩ）、装置、メディア、プロシージャ、構成などの実施形態を、本明細書で説明する。

図面全体を通じて、同一の符号は、類似するおよび／または対応する態様、特徴、および構成要素を参照するのに使用される。

（ネットワーク負荷分散のパラダイムの一例）
この節では、ネットワーク負荷分散のパラダイムの一例を説明し、次の節の説明の基礎、環境、コンテキストなどを提供する。この節では、主に図１〜３を参照する。

図１は、負荷分散インフラストラクチャ１０６および複数のホスト１０８を示す例示的なネットワーク負荷分散のパラダイム１００である。例示的なネットワーク負荷分散のパラダイム１００は、複数のクライアント１０２（１）、１０２（２）．．．１０２（ｍ）、複数のホスト１０８（１）、１０８（２）．．．１０８（ｎ）、ネットワーク１０４および負荷分散インフラストラクチャ１０６を含む。

各クライアント１０２は、コンピュータ、モバイルステーション、エンターテイメント機器、その他のネットワークなどのネットワーク通信可能な装置であれば何でもよい。クライアント１０２は、クライアント装置を操作している人及び／又はエンティティとも関係する。言い換えると、クライアント１０２は、ユーザおよび／または機械である論理的クライアントを備えることができる。ネットワーク１０４は、インターネット、イントラネット、有線電話網、無線電話網などの１つまたは複数のネットワークから形成される場合がある。クライアント１０２の装置の追加例およびネットワーク１０４のネットワーク種類／トポロジの別の例については、「コンピュータまたは他の装置のオペレーティング環境の例」という題名の節で、図４０を参照しつつ説明する。

個々のクライアント１０２は、ネットワーク１０４にまたがって負荷分散インフラストラクチャ１０６を介して１つまたは複数のホスト１０８と通信でき、逆も同様である。ホスト１０８は、クライアント１０２による使用のために、クライアント１０２と相互作用／通信をする１つまたは複数のアプリケーションをホスト（ｈｏｓｔ）する。各ホスト１０８は、１つのサーバおよび／または装置、複数のサーバおよび／または複数の装置、サーバの一部および／または装置の一部、これらの組合せなどに対応する場合がある。ホスト１０８の特定の実施形態を、異なるネットワーク負荷分散状態と絡めて以下でさらに説明する（しかし、ホスト１０８のバックエンドサポートは、明確にするために、示さない）。さらに、ホスト１０８の装置の別の例については、以下で、「コンピュータまたは他の装置のオペレーティング環境の例」という題名の節で、図４０を参照しつつ説明する。

負荷分散インフラストラクチャ１０６は、ネットワーク１０４を介して１つまたは複数の仮想インターネットプロトコル（ＩＰ）アドレスで連絡可能（ｒｅａｃｈａｂｌｅ）または位置づけ可能（ｌｏｃａｔａｂｌｅ）である。負荷分散インフラストラクチャ１０６の仮想ＩＰアドレス宛のクライアント１０２（または他のノード）からの通信は、そこで受信され、ホスト１０８に転送される。負荷分散インフラストラクチャ１０６は、ハードウェア構成要素および／またはソフトウェアコンポーネントからなる（図１には明示的に図示せず）。

負荷分散インフラストラクチャ１０６は、完全な楕円として図示されているが、負荷分散を達成するインフラストラクチャは、ネットワーク負荷分散パラダイム１００の他の態様に分配されてもよい。たとえば、負荷分散インフラストラクチャ１０６のソフトウェアコンポーネントは、以下でさらに説明するように、１つまたは複数のホスト１０８上に配置されてもよい。負荷分散インフラストラクチャ１０６のアーキテクチャの例については、「コンピュータまたは他の装置のオペレーティング環境の例」という題名の節で、図４０を参照しつつ説明する。

（１）に示されているように、１つまたは複数のホスト１０８は、ホスト１０８からのホスト状態情報を負荷分散インフラストラクチャ１０６に提供することができる。このホスト状態情報は、アプリケーション固有とすることができる。そのようなホスト状態情報の例を、以下でさらに説明するが、この例は、ホスト１０８に関する、ヘルス（ｈｅａｌｔｈ）情報および／または負荷情報、セッション情報などを含む。ホスト１０８から負荷分散インフラストラクチャ１０６へのヘルス情報および／または負荷情報の提供を含む特定の実施形態については、「ヘルスおよび負荷の処理」という題名の節で説明する。

（２）において、リクエストは、クライアント１０２（１）からネットワーク１０４を介して負荷分散インフラストラクチャ１０６の仮想ＩＰアドレスに送信される。クライアント１０２からのリクエストの内容、フォーマットなどは、リクエストが向けられるアプリケーションに依存し、用語「リクエスト」には、文脈に応じて、ホスト１０８からの１つまたは複数の応答が暗に含まれる場合がある。クライアントリクエストの種類に、下記が含まれるが、これに制限はされない。

１．ブラウザプログラムを使用するクライアントからのハイパーテキスト転送プロトコル（ＨＴＴＰ）ＧＥＴリクエスト。アプリケーション（より詳細には、リクエストのｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｌｏｃａｔｏｒ（ＵＲＬ））に応じて、様々なホストのセットによってリクエストにサービスすることがよい場合があり、ホスト上のクライアント「セッション」状態の存在は、特定のクライアントからの特定のホストへのリクエストのルーティングに影響を及ぼす場合がある。リクエストは、ｓｅｃｕｒｅ ｓｏｃｋｅｔｓ ｌａｙｅｒ（ＳＳＬ）（または他の形で暗号化された）接続を通っても良い。

２．仮想プライベートネットワーク（ＶＰＮ）接続（たとえば、ホストがＶＰＮサーバの組である）。この場合に、「リクエスト」を、レイヤ２トンネリングプロトコル（ｌａｙｅｒ−２ ｔｕｎｎｅｌｉｎｇ ｐｒｏｔｏｃｏｌ）（Ｌ２ＴＰ）「接続」またはポイントツーポイントトンネリングプロトコル（ｐｏｉｎｔ−ｔｏ−ｐｏｉｎｔ ｔｕｎｎｅｌｉｎｇ ｐｒｏｔｏｃｏｌ）（ＰＰＴＰ）「接続」とみなすことができる（後者は、伝送制御プロトコル（ｔｒａｎｓｍｉｓｓｉｏｎ ｃｏｎｔｒｏｌ ｐｒｏｔｏｃｏｌ）（ＴＣＰ）制御接続と、関連する一般的ルーティングカプセル化（ｇｅｎｅｒｉｃ ｒｏｕｔｉｎｇ ｅｎｃａｐｓｕｌａｔｉｏｎ）（ＧＲＥ）データトラフィックの組み合わせである）。

３．ターミナルサーバ接続（たとえば、ホストが、ターミナルサーバの組である）。

４．独自仕様（ｐｒｏｐｒｉｅｔａｒｙ）のアプリケーション固有プロトコルを使用する個々のＴＣＰ接続（リクエストごとに１つ）の形の独自仕様リクエスト。

５．シンプルオブジェクトアクセスプロトコル（ｓｉｍｐｌｅ ｏｂｊｅｃｔ ａｃｃｅｓｓ ｐｒｏｔｏｃｏｌ）（ＳＯＡＰ）リクエスト。

６．ＴＣＰ接続を介する制御情報およびリアルタイムプロトコル（ｒｅａｌ−ｔｉｍｅ ｐｒｏｔｏｃｏｌ）（ＲＴＰ）を介する待ち時間に敏感な（ｌａｔｅｎｃｙ−ｓｅｎｓｉｔｉｖｅ）メディアストリームを用いるリアルタイム通信リクエスト。

したがって、リクエストは、多数の多種多様なアプリケーション固有の形になり得る。ある本明細書で説明される実施形態では、負荷分散インフラストラクチャ１０６によって、アプリケーション固有転送判断を行うことができる。

（３）で、（この例では）負荷分散インフラストラクチャ１０６は、リクエストをクライアント１０２（１）からホスト１０８（２）に転送する。負荷分散インフラストラクチャ１０６は、リクエストが転送されるホスト１０８を選択する時に、本明細書に記載のどの実施形態が使用されているかに応じて、多数の要因のうちの１つまたは複数を検討することができる。たとえば、負荷分散インフラストラクチャ１０６は、各ホスト１０８のアプリケーションヘルスおよび／または負荷情報、ホスト１０８に記憶されるクライアント１０２（１）に関するセッション情報などを考慮に入れることができる。

図２は、複数の負荷分散ユニット１０６および複数のホスト１０８を示す例示的なネットワーク負荷分散パラダイム２００を示す図である。具体的に言うと、負荷分散インフラストラクチャ１０６は、例示的なネットワーク負荷分散パラダイム２００内では複数の負荷分散ユニット１０６（１）、１０６（２）．．．１０６（ｕ）として図示されている。さらに、２つのルータおよび／またはスイッチ２０２（１）および２０２（２）が図示されている。

ルータ／スイッチ２０２は、存在する場合に、負荷分散インフラストラクチャ１０６（図１の）の一部またはこれと分離していると考えることができる。ルータ／スイッチ２０２は、ネットワーク１０４から受信される全部のリクエストおよび個々のパケットを負荷分散ユニット１０６の共有仮想ＩＰ（ＶＩＰ）アドレスに向ける責任を負う。第１のルータ／スイッチ２０２に障害が発生する場合に、第２のルータ／スイッチ２０２は、第１のルータ／スイッチの引継ぎをすることができる。２つのルータ／スイッチ２０２が示されているが、その代わりに１つまたは３つ以上のルータ／スイッチ２０２を使用することができる。

ルータ／スイッチ２０２は、負荷分散インフラストラクチャについて知らないか、負荷分散対応（ｌｏａｄ−ｂａｌａｎｃｉｎｇ ａｗａｒｅ）である。ルータ／スイッチ２０２が負荷分散対応でない場合には、２つの例示的オプションの１つを使用することができる。第１のオプションでは、１つの負荷分散ユニット１０６に、共有ＶＩＰアドレスが「割り当てられ」、すべてのネットワークトラフィックが、これに転送される。この１つの負荷分散ユニット１０６は、トラフィックを他の負荷分散ユニット１０６の間に均等に再分配する。しかし、第１のオプションには、ボトルネックおよびフェールオーバ（ｆａｉｌｏｖｅｒ）の問題がある（複数のＶＩＰアドレスが共有され、複数の負荷分散ユニット１０６の間で分割される場合に、軽減することができる）。第２のオプションでは、ルータ／スイッチ２０２を「だまして」（ｔｒｉｃｋｅｄ）ネットワークトラフィックをすべての負荷分散ユニット１０６に向けさせ、この負荷分散ユニット１０６は、個別に、負荷分散のためにどのトラフィックが受け入れるかを判断する。しかし、この第２のオプションには、非効率的な労力の重複と、スイッチ性能／互換性の問題がある。

その一方で、ルータ／スイッチ２０２が、負荷分散対応である場合には、ルータ／スイッチ２０２を、入力ネットワークトラフィックを複数の負荷分散ユニット１０６の間で分配（たとえばラウンドロビン式で）するようにすることができる。そのような負荷分散対応ルータ／スイッチ２０２が、基本レベル（たとえばハードウェア）で負荷分散機能を実行できることを理解されたい。たとえば、負荷分散対応ルータ／スイッチ２０２によって、単純なＩＰアドレスベースのセッションアフィニティ（ｓｅｓｓｉｏｎ ａｆｆｉｎｉｔｙ）を実行し、その結果、特定の発信元ＩＰアドレスからのすべてのパケットを、同一の負荷分散ユニット１０６に向けることができるようになる。

負荷分散ユニット１０６の各別々に図示された負荷分散ユニット１０６によって、１つの物理装置、複数の物理装置、または単一の物理装置の一部を表すことができる。たとえば、負荷分散ユニット１０６（１）は、１つのサーバ、２つのサーバ、またはより多くのサーバに対応するものとすることができる。その代わりに、負荷分散ユニット１０６（１）および負荷分散ユニット１０６（２）が、一緒に、単一のサーバに対応するものとすることができる。例示的な負荷分散ユニット１０６を、図３を参照して、機能的考え方からさらに以下に説明する。

２つの例示的なリクエストパス［１］および［２］が、図２に示されている。リクエストパス［１］では、クライアント１０２（２）は、ネットワーク１０４を介してリクエストを送信し、このリクエストは、ルータ／スイッチ２０２（１）に到達する。ルータ／スイッチ２０２（１）は、クライアント１０２（２）から発せられたリクエストのパケットを負荷分散ユニット１０６（１）に向ける。負荷分散ユニット１０６（１）は、ある負荷分散機能（たとえばポリシ）に従って、このリクエストのパケットをホスト１０８（１）に転送する。リクエストパス［２］では、クライアント１０２（ｍ）は、ネットワーク１０４を介してリクエストを送信し、このリクエストは、ルータ／スイッチ２０２（２）に到達する。ルータ／スイッチ２０２（２）は、クライアント１０２（ｍ）から発せられたリクエストのパケットを負荷分散ユニット１０６（ｕ）に向ける。負荷分散ユニット１０６（ｕ）は、ある負荷分散機能に従って、このリクエストのパケットをホスト１０８（ｎ）に転送する。例示的な負荷分散機能を、以下で図３を参照してさらに説明する。

図３は、分離された機能を有する例示的な負荷分散ユニット１０６および例示的なホスト１０８を示す。負荷分散ユニット１０６は、７つの機能ブロック３０２〜３１４を含む。負荷分散ユニット１０６のこれらの機能ブロックは、少なくとも部分的にソフトウェアを使用して実現される。ホスト１０８には、１つまたは複数のアプリケーション３１６が含まれる。実施形態では、負荷分散ユニット１０６には、フォワーダ（ｆｏｒｗａｒｄｅｒ）３０２、クラシファイヤ（ｃｌａｓｓｉｆｉｅｒ）３０４、リクエストルータ３０６、セッショントラッカ（ｓｅｓｓｉｏｎ ｔｒａｃｋｅｒ）３０８、接続マイグレータ（ｃｏｎｎｅｃｔｉｏｎ ｍｉｇｒａｔｏｒ）３１０、トンネラ（ｔｕｎｎｅｌｅｒ）３１２、ならびにヘルスおよび負荷ハンドラ３１４が含まれる。

ヘルスおよび負荷ハンドラ３１４は、一部がホスト１０８に、一部が負荷分散ユニット１０６の装置に位置する。ヘルスおよび負荷ハンドラ３１４は、ホスト１０８のヘルスおよび／または負荷（あるいはより一般的に状況）を監視し、その結果、ヘルスおよび／または負荷情報は、負荷分散機能のために使用できるようになる（たとえば、負荷分散決定を行う時）。ヘルスおよび負荷ハンドラ３１４の例示的実施形態を、以下で、特に「例示的ヘルスおよび負荷の処理」という題名の節で説明する。

セッショントラッカ３０８もまた、一部をホスト１０８に、一部を負荷分散ユニット１０６の装置に配置することができる。セッショントラッカ３０８は、クライアント１０２によって確立されるセッションを監視し、その結果、前に確立されたセッションの再接続／継続を、負荷分散機能によって実現できるようになる。たとえば、一部のアプリケーションは、ホスト上で（ホスト状態情報の１つの種類でもある）アプリケーション固有クライアントセッションデータを保持する。これらのアプリケーションは、通常、クライアントが所与のセッションの持続時間中に同一のホストを使用することを予期する。セッションの例示的な種類には（ｉ）ＴＣＰ接続（厳密に言えばセッション）、（ｉｉ）ＳＳＬセッション、（ｉｉｉ）セキュアＩＰ（ＩＰｓｅｃ）セッション、（ｉｖ）ＨＴＴＰクッキーベースセッションなどが含まれる。

セッショントラッカ３０８は、負荷分散ユニット１０６内の別個のブロックとして図示されているが、セッショントラッカ３０８のセッショントラッキング機能は、実際には、グローバルレベルで実施することができる。言い換えると、セッションアフィニティは、複数の負荷分散ユニット１０６にまたがってサポートされる。セッショントラッカ３０８には、セッションアフィニティを保存するために、セッション情報の集中データベースおよび／または分散データベースが含まれる。セッショントラッカ３０８の例示的実施形態を、分散データベース手法を強調して、下の「セッショントラッキングの例」という題名の節でさらに説明する。

クラシファイヤ３０４は、ヘルスおよび負荷ハンドラ３１４および／またはセッショントラッカ３０８によって獲得され維持されるデータを、おそらくは他の要因と共に使用して、入力リクエストを分類する。言い換えると、クラシファイヤ３０４は、クライアント１０２からの入力リクエストのそれぞれについてターゲットのホスト１０８を選択する。フォワーダ３０２は、クラシファイヤ３０４によって選択されたターゲットホスト１０８に従って、クライアントリクエスト（および／またはそのパケット）を転送する。フォワーダ３０２およびクラシファイヤ３０４は、パケットごとのベースで動作することができる。フォワーダ３０２およびクラシファイヤ３０４の例示的実施形態を、以下で、特に「柔軟なネットワーク負荷分散に対する手法の例」および「分類、転送、およびリクエストルーティングの例」という題名の節でさらに説明する。

リクエストルータ３０６は、フォワーダ３０２およびクラシファイヤ３０４のパケットごとの実施形態とは対照的に、ホスト１０８上で動作するアプリケーションのプロキシとしての役割をはたすことができる。たとえば、リクエストルータ３０６は、ＴＣＰ接続の終端、クライアント１０２からの各論理リクエストの（おそらくは部分的な）解析、およびターゲットホスト１０８への各論理リクエストの再提出（ｒｅｓｕｂｍｉｔ）を行うことができる。その結果、クライアント１０２からの各論理リクエストを、リクエストルータ３０６によって行われる判断に基づいて、異なるホスト１０８に向けることができる。さらに、リクエストルータ３０６は、接続に関する処理ごとに（たとえばＳＳＬ暗号化）動作でき、あるリクエストを吸収することを選択でき（たとえば、リクエストルータ３０６が応答のキャッシュを維持するので）、リクエストをホスト１０８に転送する前に任意にリクエストを修正することなどができる。リクエストルータ３０６の例示的実施形態を、以下で、特に「柔軟なネットワーク負荷分散に対する手法の例」および「分類、転送、およびリクエストルーティングの例」という題名の節でさらに説明する。

接続マイグレータ３１０によって、まず負荷分散ユニット１０６で接続を終端し、その後、接続が後にホスト１０８で終端されるように、その接続を移行することができる。この接続移行によって、アプリケーションレベルの負荷分散を容易にすることができる。接続マイグレータ３１０は、負荷分散ユニット１０６での元々の終端がリクエスト元のクライアント１０２および新たに終端するホスト１０８のアプリケーション３１６に透過的になる形で、負荷分散ユニット１０６からホスト１０８に接続を移行することができる。トンネラ３１２によって、各トンネルされるパケット（ｔｕｎｎｅｌｅｄ ｐａｃｋｅｔ）に対するオーバーヘッドを導入しないパケットのトンネリングに関するカプセル化方式を利用することができる。

トンネラ３１２の機能を、接続移行を必要としない状況でも使用することができる。さらに、接続マイグレータ３１０および／またはトンネラ３１２を、非負荷分散の実施形態で追加して使用することができる。接続マイグレータ３１０ならびにトンネラ３１２の例示的実施形態を、以下で、特に「任意のトンネリングおよび／またはアプリケーションレベルロードバランシングを伴う接続移行の例」という題名の節でさらに説明する。

負荷分散ユニット１０６の任意の所与の実施形態は、１つまたは複数の図示された機能を含むことができる。別々に図示されてはいるが、ブロック３０２〜３１４の機能のそれぞれは、実際には、他の機能と相関し、オーバーラップし、かつ／または他の機能を含む場合がある。たとえば、ヘルスおよび負荷ハンドラ３１４のヘルスおよび／または負荷情報を、クラシファイヤ３０４によって使用することができる。また、接続マイグレータ３１０およびトンネラ３１２は、フォワーダ３０２およびクラシファイヤ３０４と共に機能する。他の例示的なオーバーラップおよび相互作用を、以下で説明する。

説明される実施形態で、ホスト１０８は、実行され、１つまたは複数のアプリケーション３１６に対するアクセスを提供する。一般に、アプリケーション３１６には、ファイル配信プログラム、ウェブサイト管理／サーバプログラム、リモートアクセスプログラム、電子メールプログラム、データベースアクセスプログラムなどが含まれる。具体的には、アプリケーション３１６に、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｃｏｒｐｏｒａｔｉｏｎ社のＩｎｔｅｒｎｅｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｒｖｅｒ（登録商標）（ＩＩＳ）などのウェブサーバ、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｔｅｒｍｉｎａｌ Ｓｅｒｖｅｒ（商標）などのターミナルサーバ、ならびにＩｎｔｅｒｎｅｔ Ｓｅｃｕｒｉｔｙ ａｎｄ Ａｃｃｅｌｅｒａｔｉｏｎ Ｓｅｒｖｅｒ（商標）（ＩＳＡ）などのファイヤウォールおよびプロキシ製品を含めることができるが、これに制限はされない。前の文の特定のアプリケーション３１６の例は、Ｍｉｃｒｏｓｏｆｔ（登録商標）社の製品に関するが、本明細書に記載のネットワーク負荷分散は、特定のベンダ、アプリケーション、またはオペレーティングシステムに制限されない。

（柔軟なネットワーク負荷分散へのアプローチ例）
この節では、本明細書のこの節および他の節に記載のネットワーク負荷分散実施形態によって、ネットワーク負荷分散に対する柔軟な手法がどのように提供されるかを示す。この節では、主に図４〜９Ｂを参照する。

上記で注記したように、ネットワーク負荷分散機能は、第１のネットワーク負荷バランサ（ｎｅｔｗｏｒｋ ｌｏａｄ ｂａｌａｎｃｅｒ）を、第２のより大きく強力なネットワーク負荷バランサに置換することによってスケールアップすることができる。第２のネットワーク負荷バランサのハードウェア機能は、より高い能力を提供することを除いて、第１のネットワーク負荷バランサのハードウェア機能全体を複製する。これは、特に１つのネットワーク負荷分散機能だけが性能を制限し、ネットワーク負荷バランサのアップグレードを早める場合に、非常に非効率的である可能性がある柔軟でない手法である。

図４に、分離された分類機能および転送機能を有するネットワーク負荷分散インフラストラクチャの例を示す。分離された分類機能および転送機能は、それぞれクラシファイヤ３０４およびフォワーダ３０２によって表される。分類機能および転送機能は、以下で、特に「分類、転送、およびリクエストルーティングの例」という題名の節でさらに説明するが、ネットワーク負荷分散インフラストラクチャ機能とホスト１０８の間の相互作用の例として、最初の説明をここで提示する。

説明される実施形態で、フォワーダ３０２は、仮想ＩＰ（ＶＩＰ）アドレス（１つまたは複数）に対応し、それに関するネットワークエンドポイントである。フォワーダ３０２は、パケットをさらなる宛先または最終的な宛先にルーティングする場合に、単純化されたおよび／または基本的なポリシ決定をする比較的低レベルの構成要素である。フォワーダ３０２は、ルーティングテーブルを調べてこの宛先を決定する。クラシファイヤ３０４は、１つまたは複数の要因（たとえば、ホスト状態情報）に基づいてルーティングテーブルに投入（ｐｏｐｕｌａｔｅ）するが、これは本明細書の他の節でさらに説明する。

クライアント１０２およびホスト１０８は、示されたネットワークアドレスにも対応する。具体的に言うと、クライアント１０２（１）は、アドレスＣ１に対応し、クライアント１０２（２）は、アドレスＣ２に対応し．．．クライアント１０２（ｍ）は、アドレスＣｍに対応する。また、ホスト１０８（１）は、アドレスＨ１に対応し、ホスト１０８（２）は、アドレスＨ２に対応し．．．ホスト１０８（ｎ）は、アドレスＨｎに対応する。

５つの通信パス（１）〜（５）が、図４に示されている。通信パス（１）は、クライアント１０２（１）とフォワーダ３０２の間のパスであり、通信パス（５）は、フォワーダ３０２とホスト１０８（１）の間のパスである。通信パス（２）〜（４）は、フォワーダ３０２とクラシファイヤ３０４の間のパスである。この例では、説明を簡単にするために、通信パス（１）〜（５）に関連する接続は、ＨＴＴＰ ＴＣＰ接続である。さらに、この例の負荷分散は、少なくともアプリケーションレベル負荷分散の明示的な考察なしの、最小の負荷のホスト１０８への入力接続のルーティングに関する。

通信パス（１）〜（５）は、フォワーダ３０２およびクラシファイヤ３０４がクライアント１０２（１）からの単一のＨＴＴＰ ＴＣＰ接続をどのように負荷分散するかを示す。（１）において、クライアント１０２（１）は、ＶＩＰアドレス宛のＴＣＰ ＳＹＮパケットを送信することによって、ＴＣＰ接続を開始する。ネットワーク１０４のルーティングインフラストラクチャは、このパケットを、ルータ／スイッチ２０２（１）を介してフォワーダ３０２にルーティングし、このルータ／スイッチ２０２（１）は、フォワーダ３０２に「最も近い」ルータ／スイッチ２０２である。

（２）において、フォワーダ３０２は、この接続をルックアップするために、フォワーダ３０２の内部または他の形でフォワーダからアクセス可能なルーティングテーブルを調べる。この接続は、ＴＣＰ／ＩＰ４―タプル（ｔｕｐｌｅ）（すなわち、発信元ＩＰアドレス、発信元ＴＣＰポート、宛先ＩＰアドレス、宛先ＴＣＰポート）によって、ルーティングテーブル内で識別することができる。これは、接続の最初のパケットなので、ルーティングテーブルにはエントリがない。したがって、フォワーダ３０２は、「デフォルトルート」アクションを適用するが、これは、このパケットをクラシファイヤ３０４に送ることである。

（３）において、クラシファイヤ３０４は、ホスト１０８（１）、１０８（２）．．．１０８（ｎ）に関するホスト状態情報のキャッシュ（たとえば統合キャッシュ）を調べる。クラシファイヤ３０４は、たとえば、この瞬間に、ホスト１０８（１）が使用可能であり、最小の負荷を有するホスト１０８であると結論付ける。また、クラシファイヤ３０４は、このＴＣＰ接続に関してフォワーダ３０２によって調べられたルーティングテーブル内のルートを「プラム（ｐｌｕｍｂ）」する。例えば、クラシファイヤ３０４は、（例えばＴＣＰ４タプルによって識別される）ＴＣＰ接続を特定の宛先ホスト１０８にマッピングするルーティングテーブルにルートエントリを追加するか、追加することをフォワーダ３０２に指示を出す。この例では、宛先ホストは、ホスト１０８（１）である。具体的に言うと、このルートエントリは、ホスト１０８（１）のネットワークアドレスＨ１を指定する。

（４）において、クラシファイヤ３０４は、ＴＣＰ ＳＹＮパケットを、フォワーダ３０２に送り返す。あるいは、クラシファイヤ３０４は、この最初のＴＣＰ ＳＹＮパケットを、フォワーダ３０２を使用せずにホスト１０８（１）に転送することができる。クラシファイヤ３０４が使用可能な他のオプションを、以下でさらに説明する。

（５）において、フォワーダ３０２は、ＳＹＮパケットによって表される接続のルートエントリにアクセスすることができ、したがって、フォワーダ３０２は、アドレスＨ１のホスト１０８（１）にパケットを転送する。フォワーダ３０２は、この接続に関するクライアント１０２（１）からのすべての後続パケットを、ホスト１０８（１）に直接に転送する。言い換えると、フォワーダ３０２は、この接続に関するクラシファイヤ３０４とのさらなる相互作用を避けることができる。以下でさらに説明する機構の１つまたは組合せを使用して、接続終了時にルートエントリを削除することができる。

多くのプロトコル環境の通信パス（５）について、フォワーダ３０２は、ネットワークアドレスＨ１のホスト１０８（１）にクライアント１０２（１）からのパケットを単純にそのままで送ることはできない。というのは、これらのパケットは、ＶＩＰアドレス宛であり、これがフォワーダ３０２自体によってホストされるからである。その代わりに、フォワーダ３０２は、下記の例示的オプションの１つまたは複数を使用することができる。

１．フォワーダ３０２は、（ｉ）発信元（クライアント１０２（１））ＩＰアドレス（Ｃ１）およびポート番号をフォワーダ３０２のＩＰアドレスおよびネットワークアドレス変換（ＮＡＴ）によって生成されたポート番号によって上書きし、（ｉｉ）宛先ＩＰアドレス（ＶＩＰ）をホスト（１０８（１））のＩＰアドレス（Ｈ１）によって上書きすることによって、ＮＡＴを実行する。

２．フォワーダ３０２は、宛先ＩＰアドレス（ＶＩＰ）をホスト（１０８（１））のＩＰアドレス（Ｈ１）によって上書きし、その結果、発信元（クライアント１０２（１））ＩＰアドレス（Ｃ１）およびポート番号が保存されるようにすることによって、「半ＮＡＴ」（Ｈａｌｆ−ＮＡＴ）を実行する。

３．フォワーダ３０２は、クライアント１０２（１）から受信されたパケットを、フォワーダ３０２からホスト１０８（１）に「トンネリング」する。具体的には、この例では、各パケットを、ホスト１０８（１）にアドレッシングされた新しいＩＰパケット内にカプセル化することによって、トンネリングを実現することができる。ホスト１０８（１）上のネットワーク負荷分散対応ソフトウェアは、クライアント１０２（１）からフォワーダ３０２によって受信された元々のパケットを再構成する。この元々のパケットは、ホスト１０８（１）の仮想インターフェースに示される（たとえば、フォワーダ３０２に対応するＶＩＰアドレスは、ホスト１０８（１）のこの仮想インターフェースに束縛される。）。そのようなトンネリングの例示的実施形態を、以下で、特に接続移行シナリオに関して、特に「任意のトンネリングおよび／またはアプリケーションレベルロードバランシングを伴う接続移行の例」という題名の節で、トンネラ３１２に関してさらに説明する。

図４〜９Ｂに、２つの特定の別々の機能すなわち、分類および転送が示されているが、リクエストルータ３０６、セッショントラッカ３０８、接続マイグレータ３１０、ならびにヘルスおよび負荷ハンドラ３１４の機能などの他の機能も、以下でさらに説明するように、独立にスケールアウトする（たとえば、独立にファクタアウトする）ことができることを理解されたい。さらに、１つまたは３つ以上の機能を、独立に異なる時および／または同時に分離し、スケールアウトできることに留意されたい。また、この節および他の節の多くの例で、説明を明瞭にするためにＴＣＰ／ＩＰが使用されるが、本明細書に記載のネットワーク負荷分散の原理は、他の伝送プロトコルおよび／または通信プロトコルに適用可能である。

図４の例示的な形では、（図３に示されたような）ネットワーク負荷分散機能を、スケーラビリティのために互いに分離することができる。可用性を高めるために、これらを分離し、さまざまな構成に複製することもできる。スケーラビリティおよび／または可用性に関する例示的構成を、以下で、図５の方法を説明した後で図６〜９Ｂを参照して説明する。

図５は、ネットワーク負荷分散インフラストラクチャの異なる構成へのスケールアウトの例示的な方法を示すフローチャート５００である。フローチャート５００には、３つのブロック５０２〜５０６が含まれる。フローチャート５００の動作は、他の環境でさまざまなソフトウェア方式と共に実行することができるが、特にこの方法のさまざまな態様および例を示すために、図１〜４および６〜９Ｂを使用する。

ブロック５０２において、ネットワーク負荷分散インフラストラクチャを第１の構成で動作させる。たとえば、各構成を、異なる負荷分散機能の選択、比率、および／または相互関係、異なる装置の数および／または種類、異なるコンポーネントの編成および／またはレイアウト、リソースの分配および／または割当などの１つまたは複数に関連するものとすることができる。ブロック５０４において、ネットワーク負荷分散インフラストラクチャをスケールアウトする。たとえば、分離された負荷分散機能を、個別および／または独立ベースで、拡大し、かつ／または付随して縮小することができる。ブロック５０６において、スケールアウトされたネットワーク負荷分散インフラストラクチャを第２の構成で動作させる。

上記で注記したように、前のネットワーク負荷分散ハードウェアをより強力なネットワーク負荷分散ハードウェアに取り替えることによってネットワーク負荷分散機能の全体を高めることによって、モノリシックネットワーク負荷バランサをスケールアップすることができる。反対に、ネットワーク負荷分散インフラストラクチャのスケールアウトによって、ネットワーク負荷分散（副）機能を個別におよび／または独立にスケールアウトすることを可能にすることができるようになる。これによって、ネットワーク負荷分散機能を、異なる数の装置の間で一緒にまたは個別にスケールアウトできるようになる。装置、コンポーネント、およびリソース指向のスケールアウトの例を、下に示す。

図６に、装置の観点からの第１の例示的なネットワーク負荷分散インフラストラクチャ構成を示す。この第１の装置指向ネットワーク負荷分散インフラストラクチャ構成には、３つの装置６０２（１）、６０２（２）、および６０２（３）が示されている。しかし、１つ、２つ、または４つ以上の装置６０２を、その代わりに使用することができる。

図からわかるように、フォワーダ３０２（１）、クラシファイヤ３０４（１）、およびホスト１０８（１）は、装置６０２（１）に常駐し、動作している。フォワーダ３０２（２）、クラシファイヤ３０４（２）、およびホスト１０８（２）は、装置６０２（２）に常駐し、動作している。またフォワーダ３０２（３）、クラシファイヤ３０４（３）、およびホスト１０８（３）は、装置６０２（３）に常駐し、動作している。したがって、この第１の装置指向ネットワーク負荷分散インフラストラクチャ構成では、それぞれのフォワーダ３０２、クラシファイヤ３０４、およびホスト１０８は、それぞれの装置６０２のリソースを共有する。

動作中には、フォワーダ３０２は、ＶＩＰアドレスのネットワークエンドポイントである。どのクラシファイヤ３０４でも、ホスト状態情報に応じて、任意のホスト１０８への接続のためのルートをプラムすることができる。たとえば、クラシファイヤ３０４（２）は、ホスト１０８（３）への新しい入力接続に関するルートをプラムすることができる。この接続の新しいルートエントリに従って、フォワーダ３０２（２）は、後続パケットをホスト１０８（３）に転送する。

図示の第１の装置指向ネットワーク負荷分散インフラストラクチャ構成をスケールアウトすることができる１つの代替の装置指向ネットワーク負荷分散インフラストラクチャ構成では、フォワーダ３０２（４）、クラシファイヤ３０４（４）、およびホスト１０８（４）を含む第４の装置６０２（４）（図６に明示的には図示せず）を追加することができる。その一方で、クラシファイヤ３０４（１〜３）によって十分な分類機能が既に存在するが、追加の転送機能がホスト１０８のリクエスト処理のためになる場合に、フォワーダ３０２（４）および任意選択のホスト１０８（４）を含む第４の装置６０２（４）を追加することができる。このスケールアウトされた構成に関して、別のクラシファイヤ３０４（１、２、または３）によって、ホスト１０８（１、２、または３）および存在する場合にホスト１０８（４）への、フォワーダ３０２（４）のためのルートをプラムすることができる。

図６の第１の装置指向の例示的なネットワーク負荷分散インフラストラクチャ構成は、特に、ネットワーク負荷分散インフラストラクチャの別々の装置が技術的におよび／または経済的に価値がないか実行可能でない、より小さいホスティング状況に適する可能性がある。しかし、ホスティング義務が、より多数のホスト１０８に拡張される（かつ／または同数のホストへのより多くの需要がある）時、またはホスト１０８のネットワーク負荷が大きい場合に、第１の装置指向の例示的なネットワーク負荷分散インフラストラクチャ構成を、図７の第２の装置指向の例示的なネットワーク負荷分散インフラストラクチャ構成によって表されるように、この拡張に対処するためにスケールアウトすることができる。

図７は、装置の観点からの第２の例示的なネットワーク負荷分散インフラストラクチャ構成を示す。この第２の例示的なネットワーク負荷分散インフラストラクチャ構成でも、３つの装置６０２（１）、６０２（２）、および６０３（３）が示されている。やはり、１つ、２つ、または４つ以上の装置６０２を、代わりに使用することができる。

図からわかるように、フォワーダ３０２（１）およびクラシファイヤ３０４（１）は、装置６０２（１）に常駐し、動作している。フォワーダ３０２（２）およびクラシファイヤ３０４（２）は、装置６０２（２）に常駐し、動作している。また、フォワーダ３０２（３）およびクラシファイヤ３０４（３）は、装置６０２（３）に常駐し、動作している。したがって、この第２の装置指向のネットワーク負荷分散インフラストラクチャ構成では、それぞれのフォワーダ３０２およびクラシファイヤ３０４は、それぞれの装置６０２のリソースを、ホスト１０８と共有していない。さらに、このネットワーク負荷分散インフラストラクチャは、任意の数のホスト１０８をサービスすることができる。

動作中に、フォワーダ３０２は、やはり、ＶＩＰアドレスのネットワークエンドポイントである。また、どのクラシファイヤ３０４でも、ホスト状態情報に応じて、任意のホスト１０８への接続のルートをプラムすることができる。たとえば、クラシファイヤ３０４（３）によって、ホスト１０８（２）への新しい入力接続のルートをプラムすることができる。この接続の新しいルートエントリに従って、フォワーダ３０２（３）は、後続のパケットをホスト１０８に転送する。

したがって、例えば、ネットワーク負荷分散インフラストラクチャ（またはその一部）を、ホスト１０８と共有される装置からホスト１０８と共有されない装置に移動することによって、ソフトウェアで実現されるネットワーク負荷分散インフラストラクチャをスケールアウトすることができる。また、上記で図６に関してほのめかしたように、もう１つの装置６０２（４）をネットワーク負荷分散インフラストラクチャに追加して、追加の転送機能、追加の分類機能、追加の両方の種類の機能などを提供することができる。

図８Ａおよび８Ｂに、コンポーネントの観点からの第１および第２の例示的なネットワーク負荷分散インフラストラクチャ構成を示す。図からわかるように、第１のコンポーネント指向の例示的なネットワーク負荷分散インフラストラクチャ構成８００は、４つのコンポーネントを含む。第２のコンポーネント指向の例示的なネットワーク負荷分散インフラストラクチャ構成８５０は、６つのコンポーネントを含む。代替の第２の構成８５０は、破線のブロックによって示されるように、７つの構成要素を含むが、これは以下で説明する。

具体的に言うと、第１のコンポーネント指向の例示的なネットワーク負荷分散インフラストラクチャ構成８００（または第１構成８００）は、（ｉ）２つのフォワーダ３０２（１）および３０２（２）と、（ｉｉ）２つのクラシファイヤ３０４（１）および（２）を含む。第２のコンポーネント指向のネットワーク負荷分散インフラストラクチャ構成８５０（または第２構成８５０）は、（ｉ）４つのフォワーダ３０２（１）、３０２（２）、３０２（３）および３０２（４）と、（ｉｉ）２つのクラシファイヤ３０４（１）および（２）を含む。したがって、この例では転送コンポーネントである２つのコンポーネントを追加することによって、第１構成８００が第２構成８５０にスケールアウトされる。

説明される実施形態では、それぞれのネットワーク負荷分散関連機能コンポーネントは、それぞれの装置（図８Ａまたは８Ｂで明示的に図示せず）に対応するが、各コンポーネントを、その代わりに、装置の一部または複数の装置に対応するものとすることができる。たとえば、フォワーダ３０２（１）および３０２（２）を、３つの装置にまたがって分散させることができる。あるいは、フォワーダ３０２（１）およびクラシファイヤ３０４（１）は、第１装置に対応し、フォワーダ３０２（２）およびクラシファイヤ３０４（２）は、第２装置に対応することができる。

２つのネットワーク負荷分散関連機能コンポーネントが追加されて、第１構成８００が第２構成８５０にスケールアウトされる。しかし、その代わりに、１つのコンポーネント（または３つ以上）を追加して、ネットワーク負荷分散インフラストラクチャをスケールアウトすることができる。さらに、複数の異なる種類の機能コンポーネントを、「同時に」スケールアウトすることができる。たとえば、破線のブロックによって示されているように、第１構成８００を第２構成８５０にスケールアウトする時に、もう１つの分類コンポーネント（たとえばクラシファイヤ３０４（３））を追加することもできる。

さらに、複数の異なる種類の機能コンポーネントによるスケーリングを、互いに類似する比率（たとえば同等に）または異なる比率で実行することができる。図からわかるように、フォワーダコンポーネント３０２（３）および３０２（４）を追加し、クラシファイヤコンポーネント３０４を追加しないか、単一のクラシファイヤコンポーネント３０４（３）を追加することによって、異なる比率のスケールアウトが示される。しかし、類似する比率でのスケールアウトのために、２つのクラシファイヤコンポーネント３０４（３）および３０４（４）（後者は、図８には明示的に示されていない）を追加すると同時に、２つのフォワーダコンポーネント３０２（３）および３０２（４）を追加することができる。いずれにせよ、各個々のネットワーク負荷分散関連機能コンポーネントは、図９Ａおよび９Ｂを参照して説明するように、異なる量の使用可能ネットワーク負荷分散関連機能インフラストラクチャリソースを消費する可能性がある。

図９Ａおよび９Ｂに、リソースの観点からの第１および第２の例示的なネットワーク負荷分散インフラストラクチャ構成を示す。第１のリソース指向の例示的なネットワーク負荷分散インフラストラクチャ構成９００（または第１構成９００）には、負荷分散ユニット１０６の第１のリソース分配またはリソース割当が含まれる。第２のリソース指向の例示的なネットワーク負荷分散インフラストラクチャ構成９５０（または第２構成９５０）には、負荷分散ユニット１０６の第２のリソース分配が含まれる。

図からわかるように、第１構成９００には、７０％−３０％リソース配分が含まれ、第２構成９５０には、４０％−６０％リソース配分が含まれる。そのようなリソースには、総装置リソース（たとえば装置の数）、処理リソース（たとえばプロセッササイクルの数）、メモリリソース（たとえばキャッシュの一部、メインメモリなど）、ネットワーク帯域幅および／またはインターフェースリソース（たとえば、ビット毎秒および／または物理ネットワークインターフェースカード（ＮＩＣ））などを含めることができる。

第１構成９００について具体的に言うと、フォワーダ３０２は、負荷分散ユニット１０６のリソースの７０％を消費し、クラシファイヤ３０４は、このリソースの３０％を消費する。第２構成９５０を作るスケールアウトプロシージャ中の再割当の後に、フォワーダ３０２は、負荷分散ユニット１０６のリソースの４０％を消費し、クラシファイヤ３０４は、このリソースの６０％を消費する。

例示的な状況では、第１構成９００は、より少数のより長いトランザクションが関連ホスト（図９Ａおよび９Ｂに図示せず）によって処理されている時に、よりよいネットワーク負荷分散性能を促進する可能性がある。というのは、分類機能が、接続の最初の通信時に使用され、転送機能が、その後に使用されるからである。その一方で、第２構成９５０は、より多数のより短いトランザクションが関連ホストによって処理されている時に、よりよいネットワーク負荷分散性能が促進する可能性がある。というのは、分類機能が、ネットワーク負荷分散インフラストラクチャを介して集められるパケットの総数のうちのより大きい比率のために使用されるからである。この状況では、リクエストルーティング機能も使用されている場合に、リクエストルータ３０６もまた、総コンピューティングリソースのうちのある比率を割り当てられる。この３つの機能の間でのリソース分配は、現在のリソース消費および／または不足に応じて、接続の処理中に調整する（たとえば、「オンザフライ」で調整する）ことができる。

上記で図２および３に関して示したように、各負荷分散ユニット１０６は、ネットワーク負荷分散インフラストラクチャ１０６全体のすべてまたは一部に対応するものとすることができる。所与の物理的に、論理的に、任意等に定義されるか規定された負荷分散ユニット１０６について、そのリソースを、スケールアウトプロシージャ中に再割り当てすることができる。具体的に言うと、負荷分散ユニット１０６の異なるネットワーク負荷分散関連の分離された機能の間のリソース分配を、スケールアウトプロシージャ中で変更することができる。さらに、複数の異なる機能ならびに図９Ａおよび９Ｂに特に示されていない他のネットワーク負荷分散関連の機能を、異なるリソース比率で割り当てることができる。

すべての負荷分散機能に割り当てられる総システムリソースの比率も、スケールアウトプロシージャ中で変更することができる。一般的な処理能力の例として、総処理能力のうちで負荷分散に振り向けられる比率を、負荷分散を必要とするトラフィックの量が増える時に、徐々に増やすことができる。

ネットワーク負荷分散ソフトウェアは、任意選択として、監視を実行して、分析し、リソースを再割り当てしなければならないかどうかを判定することができる。たとえば、ネットワーク負荷分散ソフトウェアは、異なるネットワーク負荷分散関連機能のプロセッサ使用率を監視することができる。実際の再割り当てを、任意選択として、オフラインモードまたはオンラインモードのネットワーク負荷分散ソフトウェアによって自動的に実行することもできる。

本明細書に記載のネットワーク負荷分散インフラストラクチャのスケールアウト機能（たとえば、少なくとも部分的にソフトウェアで実現される）を、異なるインストールに関連させることができ、このスケールアウト機能が、必ずしも単一のインストールに対する変更でないことを理解されたい。リソース指向の例では、本明細書に記載のネットワーク負荷分散インフラストラクチャを、あるインストール環境で１つのリソース分配に従って構成でき、異なる動作パラメータを有する別のインストール環境で、別の異なるリソース分配に従って構成することができる。さらに、スケールアウトに関して上記で説明した機能、特徴、オプションなどは、「スケールイン」にも適用可能である。言い換えると、ネットワーク負荷分散インフラストラクチャ（またその副機能）に振り向けられるリソースを、減らすこともできる。

（ヘルスおよび負荷の処理例）
この節では、ヘルスおよび／または負荷情報などのホスト状態情報を、ネットワーク負荷分散でどのように収集でき、使用できるかを説明する。この節では、主に図１０〜１８を参照し、ヘルスおよび負荷ハンドラ３１４（図３）によって提供されるヘルスおよび負荷機能を示す。図３を参照して上記で説明したように、各ホスト１０８は、１つまたは複数のアプリケーション３１６をホストする。ヘルスおよび負荷ハンドラ３１４は、ネットワーク負荷分散のある説明される実施形態のアプリケーション３１６および／またはホスト１０８に関連するヘルスおよび／または負荷情報を使用する。

図１０に、ホスト状態情報（ＨＳＩ）１００６を含む例示的なネットワーク負荷分散手法を示す。各ホスト１０８（１）、１０８（２）．．．１０８（ｎ）には、１つまたは複数のアプリケーション３１６（１）、３１６（２）．．．３１６（ｎ）が含まれる。全般的にこれらのホスト１０８および具体的にこれらのアプリケーション３１６は、時々状況を変更することができる。

たとえば、ホスト１０８およびアプリケーション３１６は、新しい接続を受け入れつつある場合と、そうでない場合がある。また、これらが、クライアントリクエストをすばやく処理している場合と、ゆっくり処理している場合がある。さらに、これらが、予備の多数のリソースを有する場合と、未使用のリソースがほとんどない場合がある。そのようなデータまたは他のデータのすべてまたは一部に、ホスト状態情報１００６が含まれる場合がある。一般に、ホスト状態情報１００６は、ホスト１０８および／またはそこで動作するアプリケーション３１６のある態様の状況の表示を提供する。

説明された実施形態では、各ホスト１０８（１）、１０８（２）．．．１０８（ｎ）に、ホスト状態情報（ＨＳＩ）デターミナ（ｄｅｔｅｒｍｉｎｅｒ）１００２（１）、１００２（２）．．．１００２（ｎ）が含まれる。各ホスト１０８（１）、１０８（２）．．．１０８（ｎ）には、ホスト状態情報（ＨＳＩ）ディセミネータ（ｄｉｓｓｅｍｉｎａｔｏｒ）１００４（１）、１００４（２）．．．１００４（ｎ）も含まれる。ホスト状態情報デターミナ１００２および／またはホスト状態情報ディセミネータ１００４のそれぞれを、負荷分散インフラストラクチャ（ＬＢＩ）１０６の一部とすることができる。

各ホスト状態情報デターミナ１００２は、それぞれのホスト１０８および／またはそこで動作するアプリケーション３１６のホスト状態情報１００６を判定する。そのようなホスト状態情報１００６を判定する例示的技法を、以下で、図１２〜１４、特に図１３Ａを参照して説明する。各ホスト状態情報ディセミネータ１００４は、そのそれぞれのホスト１０８および／またはアプリケーション３１６に関するホスト状態情報１００６を、負荷分散インフラストラクチャ１０６（たとえば、負荷分散インフラストラクチャ１０６のうちでホスト１０８に位置しない部分）に配布する（ｄｉｓｓｅｍｉｎａｔｅ）。そのようなホスト状態情報１００６の配布の例示的技法を、以下で図１２〜１７、特に図１３Ｂおよび１５〜１７を参照して説明する。

具体的に言うと、各ホスト状態情報ディセミネータ１００４は、ホスト状態情報１００６を、少なくとも１つのヘルスおよび負荷ハンドラ３１４および／またはクラシファイヤ３０４を含む負荷分散インフラストラクチャ１０６の各負荷分散ユニット（ＬＢＵ）１０６に（直接にまたは間接的に）配布する。負荷分散インフラストラクチャ１０６は、ネットワーク負荷分散を実施する時にホスト状態情報１００６を参照する。たとえば、ロジック１００８によって示されるように、負荷分散インフラストラクチャ１０６は、負荷分散判断がホスト状態情報１００６に応答するようにすることができる。

（１）での動作で、ホスト状態情報デターミナ１００２は、それぞれのホスト１０８および／またはアプリケーション３１６についてホスト状態情報１００６を判定する。（１）および（２）で、ホスト状態情報ディセミネータ１００４は、ホスト状態情報１００６をホスト１０８から負荷分散インフラストラクチャ１０６に配布する。たとえば、ホスト状態情報１００６を、個々の負荷分散ユニット１０６に配布できる。（３）で、ロジック１００８は、負荷分散判断が、ホスト状態情報１００６に反応するようにする。（４）で、ネットワーク負荷分散判断に基づいて、接続がターゲットのホスト１０８に転送される。

図１１は、ホスト状態情報を含むネットワーク負荷分散の例示的な方法を示すフローチャート１１００である。フローチャート１１００には、３つのブロック１１０２〜１１０６が含まれる。フローチャート１１００の動作は、他の環境でおよびさまざまなソフトウェア方式と共に実行することができるが、図１〜３および１０を特に使用して、この方法の一部の態様および例を示す。

ブロック１１０２において、ホスト状態情報は、ホストから負荷分散ユニットに送信される。たとえば、ホスト状態情報１００６は、ホスト１０８から負荷分散ユニット１０６に送信される。ブロック１１０４において、ホスト状態情報は、負荷分散ユニットでホストから受信される。たとえば、負荷分散ユニット１０６は、ホスト１０８からのホスト状態情報１００６を受信できる。ブロック１１０６において、負荷分散判断は、受信されたホスト状態情報に応答するようにされる。たとえば、負荷分散ユニット１０６のロジック１００８は、ネットワーク負荷分散に関する判断を、ホスト状態情報１００６に応答するようにすることができる。

したがって、図１０では、負荷分散インフラストラクチャ１０６は、ホスト１０８（および／またはそのアプリケーション３１６）からホスト状態情報１００６を収集し、ホスト１０８に向けられた入力リクエストが、ホスト状態情報１００６に応答して負荷分散される。以下で図１２〜１８を参照してさらに説明するように、このホスト状態情報１００６は、アプリケーション固有とすることができる。やはり以下でさらに説明するように、ホスト状態情報１００６の例には、ヘルスおよび／または負荷情報を含めることができる。

図１２に、ヘルスおよび／または負荷情報（ＨＬＩ）１２０６を含む例示的なネットワーク負荷分散手法を示す。ホスト１０８（１）、１０８（２）．．．１０８（ｎ）が、ネットワークなどの通信リンケージ１２１０を介して負荷分散ユニット１０６（１）、１０６（２）．．．１０６（ｕ）に結合される。

図からわかるように、ホスト１０８は、ヘルスおよび負荷情報１２０６を、通信リンケージ１２１０を使用して負荷分散ユニット１０６に通信する。ヘルスおよび負荷情報１２０６の双方向通信は、両方に頭がある矢印によって示されるように、負荷分散ユニット１０６からホスト１０８への２方向通信であって、完全さ、コヒーレンシ、正しさなどを供給する通信を指し、ホスト１０８および／または負荷分散ユニット１０６が、互いに独立に障害を発生することができるようになっている。そのような負荷分散ユニット１０６からホスト１０８への２方向の通信を、以下で、特に図１５を参照してさらに説明する。

ヘルス情報は、所与のホストおよび／またはアプリケーションがクライアントリクエストを処理できるかどうかを反映する。負荷情報は、所与のホストおよび／またはアプリケーションが特定の瞬間に処理できるクライアントリクエストの数、量、および／またはレベルを反映する。言い換えると、負荷は、所与のホストおよび／またはアプリケーションの総容量の使用可能な数、量、および／またはレベルを直接におよび／または逆に反映することができる。上記で注記したように、図１２〜１８を参照して説明する実施形態は、ヘルスおよび／または負荷情報に焦点を合わせたものであるが、この実施形態は、（そのアプリケーションを含む）ホストの一般的な状態情報にも適用可能である。

説明される実施形態では、各ホスト１０８（１）、１０８（２）．．．１０８（ｎ）には、それぞれのヘルスおよび負荷インフラストラクチャ（Ｈ＆ＬＩ）コンポーネント１２０２（１）、１２０２（２）．．．１２０２（ｎ）が含まれる。各ヘルスおよび負荷インフラストラクチャコンポーネント１２０２は、任意選択として、各ホスト１０８に常駐し、実行される負荷分散インフラストラクチャ１０６の一部とすることができる。ヘルスおよび負荷情報１２０６を、ソフトウェアで実現することができる。機能する時に、各ヘルスおよび負荷インフラストラクチャ１２０２（１）、１２０２（２）．．．１２０２（ｎ）は、それぞれのヘルスおよび負荷（Ｈ＆Ｌ）テーブル１２０４（１）、１２０４（２）．．．１２０４（ｎ）が作成する。

これらのヘルスおよび負荷テーブル１２０４には、アプリケーション固有エントリを含めることができる。ヘルスおよび負荷テーブル１２０４に記憶されるヘルスおよび負荷情報１２０６は、負荷分散インフラストラクチャ１０６とは独立にすることができる。たとえば、管理者、設計者などは、構成時にヘルスおよび負荷情報１２０６の判断基準を指定することができる。さらに、ホスト１０８であるかホスト１０８を有する装置の外部のエンティティは、装置上のアプリケーション３１６のヘルスおよび負荷情報１２０６の判定に寄与することができる。例示的なヘルスおよび負荷テーブル１２０４を、以下で図１３Ａを参照してさらに説明する。

各負荷分散ユニット１０６（１）、１０６（２）．．．１０６（ｕ）には、それぞれの統合ヘルスおよび負荷（Ｈ＆Ｌ）キャッシュ１２０８（１）、１２０８（２）．．．１２０８（ｕ）が含まれる。各統合ヘルスおよび負荷キャッシュ１２０８に、各ヘルスおよび負荷テーブル１２０４（１）、１２０４（２）．．．１２０４（ｎ）からの情報が含まれる。その結果、各負荷分散ユニット１０６に、負荷分散ユニット１０６がそのネットワークトラフィックを負荷分散するホスト１０８のそれぞれのヘルスおよび負荷情報１２０６へのすばやい（たとえばキャッシュに格納された）アクセスが与えられる。

動作中に、ヘルスおよび負荷インフラストラクチャ１２０２は、ヘルスおよび負荷テーブル１２０４からのヘルスおよび負荷情報１２０６を、統合ヘルスおよび負荷キャッシュ１２０８にプッシュする。ヘルスおよび負荷情報１２０６を供給する機構は、イベントドリブンであり、ヘルスおよび負荷テーブル１２０４への変更が、適時にスケーラブルな形で統合ヘルスおよび負荷キャッシュ１２０８に供給されるようになっている。

図１３Ａは、図１２に示された例示的なヘルスおよび負荷テーブル１２０４を示す図である。説明される実施形態では、ヘルスおよび負荷テーブル１２０４には、それぞれが異なるアプリケーション３１６に関連する複数のエントリ１３０２が含まれる。各エントリ１３０２は、３つの列を有するヘルスおよび負荷テーブル１２０４の１行に対応するものとすることができる。これらの列は、アプリケーション識別子（ＩＤ）１３０２（Ａ）、アプリケーション状態特性１３０２（Ｂ）、および負荷バランサ命令１３０２（Ｃ）に対応する。

各エントリ１３０２は、特定のアプリケーション３１６に関連するので、各アプリケーションがスピンアップされる（たとえば管理者によって）時に、１つの行が追加される。同様に、アプリケーションがクローズダウンされるたびに、１行が削除／除去される。同様に、列１３０２（Ａ）、１３０２（Ｂ）、および／または１３０２（Ｃ）の個々のフィールドは、その値が変化する時に修正／更新される。たとえば、所与のアプリケーション３１６に関して状態特性値が変化した時に、所与のアプリケーション３１６のエントリ１３０２のアプリケーション状態特性１３０２（Ｂ）のフィールドの値が更新される。

アプリケーション３１６のエントリ１３０２の追加および削除は、ホスト１０８の制御マネージャからの入力によって実現することができる。たとえば、オペレーティングシステムの制御マネージャ部分は、アプリケーション３１６の起動および停止に能動的にかかわるので、アプリケーション３１６が起動され、停止される時を知っている。したがって、制御マネージャは、少なくとも部分的に、アプリケーション３１６を起動したことを識別でき、制御マネージャは、少なくとも部分的に、アプリケーション３１６を停止したことを確立することができる。したがって、ヘルスおよび負荷インフラストラクチャ１２０２に、制御マネージャによってアプリケーション３１６の起動および停止について知らせることができる。したがって、アプリケーション３１６からの明示的な通信を、ヘルスおよび負荷インフラストラクチャ１２０２に供給する必要はない。制御マネージャの例が、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｃｏｒｐｏｒａｔｉｏｎ社のＷｉｎｄｏｗｓ（登録商標）Ｏｐｅｒａｔｉｎｇ ＳｙｓｔｅｍのＳｅｒｖｉｃｅ Ｃｏｎｔｒｏｌ Ｍａｎａｇｅｒ（ＳＣＭ）である。

アプリケーション識別子１３０２（Ａ）には、エントリ１３０２が関連するアプリケーション３１６を一意に識別するのに使用される情報が含まれる。アプリケーション識別子１３０２（Ａ）に、関連するアプリケーション３１６の、仮想ＩＰアドレスおよびポート、物理ＩＰアドレスおよびポート、使用されるプロトコル、およびプロトコル固有情報の１つまたは複数を含めることができる。プロトコルは、ＨＴＴＰ、ＩＰｓｅｃ、ＳＯＡＰなどとすることができる。プロトコル固有情報は、エントリ１３０２に関連するアプリケーションをさらに表すＵＲＬパターンまたはストリングとすることができる。したがって、アプリケーション識別子１３０２（Ａ）によって、特定のホスト１０８の特定のアプリケーションエンドポイントがより具体的に参照される。

他のアプリケーション識別子を、代わりに使用することができる。たとえば、通信帯域幅を減らすために、アプリケーション識別子１３０２（Ａ）を、ヘルスおよび負荷インフラストラクチャ１２０２および負荷分散ユニット１０６で上記の例示的な情報にマッピングされる３２ビットの数とすることができる。さらに、エントリ１３０２のフィールドのどれにも、実際に、そのフィールドの真の情報をルックアップするためのキーとして使用されるグローバル一意識別子（ＧＵＩＤ）を含めることができる。

アプリケーション状態特性１３０２（Ｂ）には、エントリ１３０２に関連するアプリケーション３１６の状況を反映する情報が含まれる。アプリケーション状態特性１３０２（Ｂ）には、関連するアプリケーション３１６の、アプリケーションヘルス、アプリケーション負荷、およびアプリケーション容量が含まれる。アプリケーションヘルスは、アプリケーションが機能しているかどうかを示す擬似ブール値である。アプリケーションヘルスは、ｈｅａｌｔｈｙ（健全）、ｆａｉｌｉｎｇ（障害）、またはｕｎｋｎｏｗｎ（未知）とすることができる。アプリケーションヘルスは、比較的瞬間的な値であり、アプリケーションヘルス値が変化する時に、比較的短い待ち時間（たとえば、約１秒または数秒）で負荷分散ユニット１０６に通信される。

アプリケーション負荷は、所与のアプリケーションがどれほど使用されているかまたはビジーであるかを示し、したがって、所与のアプリケーションがどれほどの追加の負荷を処理できるかを直接にまたは逆に示す値である。アプリケーション負荷は、望まれる場合に負荷の増減の過渡的スパイクをなくすために、ヒステリシスを誘導する機構によって平滑化することができる、比較的ゆっくりと変化するまたは平均的な値である。これは、比較的低い頻度で負荷分散ユニット１０６に通信される（たとえば、毎分約１回から４回）。アプリケーション負荷の値は、アプリケーション容量に関して意味を与えられる。

アプリケーション容量は、アプリケーションの最大容量を示す値である。これは、所与のコンテキストで意味を持つが、他のコンテキストに関しても十分に柔軟になるように一般的な形で選択される。アプリケーション容量は、構成時に決定される、無単位の有界値（たとえば０〜９９）である。これは、処理能力、メモリサイズ／速度、ネットワークアクセス、これらの組合せなどに基づくものとすることができる。アプリケーション容量によって、ホスト１０８（１、２．．．ｎ）の組での同一種類の他のアプリケーションの間での相対容量が表される。

したがって、アプリケーション容量に関して、アプリケーション負荷が意味を持つ。所与のアプリケーションのアプリケーション負荷は、所与のアプリケーションのアプリケーション容量の比率である。その代わりに、アプリケーション負荷を、無単位数として表すことができ、この数から、アプリケーション容量の値に関する比率を突き止めることができる。

負荷バランサ命令１３０２（Ｃ）には、エントリ１３０２が関連するアプリケーション３１６に関する負荷分散ユニット１０６のヘルスおよび負荷インフラストラクチャ１２０２によって確立される命令の所望のおよび／または期待される状態を反映する情報が含まれる。負荷バランサ命令１３０２（Ｃ）には、関連するアプリケーション３１６の、ターゲット負荷分散状態および現在負荷分散状態が含まれる。

ターゲット負荷分散状態によって、ヘルスおよび負荷インフラストラクチャ１２０２によって望まれる、負荷分散ユニット１０６への命令の状態が反映される。現在負荷分散状態によって、ヘルスおよび負荷インフラストラクチャ１２０２が、負荷分散ユニット１０６で記録される負荷分散ユニット１０６への命令の現在の状態をどのように理解するかが反映される。したがって、現在負荷分散状態によって、負荷分散ユニット１０６が通信プロトコルを使用する指示によってその下で現在動作しているとヘルスおよび負荷インフラストラクチャ１２０２が期待する負荷分散命令が反映される。そのような例示的な通信プロトコルを、以下で図１５に関してさらに説明する。ターゲット負荷分散状態と現在負荷分散状態の間の相互作用および関係も、以下で図１５に関してさらに説明する。

ターゲット負荷分散状態および現在負荷分散状態は、それぞれ、ａｃｔｉｖｅ（アクティブ）、ｉｎａｃｔｉｖｅ（非アクティブ）、ｄｒａｉｎｉｎｇ（排出中）の値にすることができる。ａｃｔｉｖｅ命令は、新しいリクエスト／接続が歓迎され、エントリ１３０２に関連するアプリケーションでターゲットにできることを示す。ｉｎａｃｔｉｖｅ命令は、関連するアプリケーションに追加パケットを転送してはならないことを示す。ｄｒａｉｎｉｎｇ命令は、新しいリクエスト／接続に関するパケットを関連するアプリケーションに送信してはならないが、既存のリクエスト／接続に関するパケットを、関連するアプリケーションに転送し続けなければならないことを示す。

説明される実施形態では、それぞれのヘルスおよび負荷情報１２０６の決定版が、複数のホスト１０８のそれぞれのホスト１０８に位置するヘルスおよび負荷テーブル１２０４に記憶される。この実施形態では、ホスト１０８がクラッシュする場合に、失われるヘルスおよび負荷情報１２０６が、やはりクラッシュするアプリケーション３１６に関するものである。したがって、高可用性の手段が、データの複製なしで自動的に得られる。しかし、ヘルスおよび負荷情報１２０６の決定版を、その代わりに他の場所に記憶することができる。他のそのようなストレージオプションに、負荷分散ユニット１０６自体、複数の他の（他のすべてを含む）ホスト１０８のヘルスおよび負荷情報１２０６を記憶し、維持するホスト１０８（その唯一のタスクとしてまたはホスティング義務と共に）、もう１つの別々のおよび／または外部の装置などが含まれる。

ヘルスおよび負荷情報１２０６の決定版が、ホスト１０８（１、２．．．ｎ）に分散される以外の場所に記憶され、維持される場合には、そのようなヘルスおよび負荷情報１２０６を、高可用性のために冗長に記憶することができる（たとえば、複製装置にも記憶する、バックアップするなど）。ヘルスおよび負荷情報１２０６の記憶に関する例示的なプロキシシナリオを、以下で図１７Ａおよび１７Ｂを参照して説明する。図１７Ａは、ヘルスおよび負荷テーブル１２０４のプロキシシナリオを対象とし、図１７Ｂは、統合ヘルスおよび負荷キャッシュ１２０８のプロキシシナリオを対象とする。

図１３Ｂは、図１２に示された例示的な統合ヘルスおよび負荷キャッシュ１２０８を示す図である。説明される実施形態では、各負荷分散ユニット１０６内の各統合ヘルスおよび負荷キャッシュ１２０８に、各ホスト１０８のヘルスおよび負荷インフラストラクチャ１２０２ごとの各ヘルスおよび負荷テーブル１２０４に記憶される情報の少なくとも一部が含まれる。キャッシュされたヘルスおよび負荷情報を、統合ヘルスおよび負荷キャッシュ１２０８で任意の形で編成することができる。

図からわかるように、統合ヘルスおよび負荷キャッシュ１２０８には、それぞれのホスト１０８（１、２．．．ｎ）のヘルスおよび負荷テーブル１２０４内の情報の一部またはすべてが複製される、ホスト１０８（１）、１０８（２）．．．１０８（ｎ）ごとのキャッシュが含まれる。具体的に言うと、統合ヘルスおよび負荷キャッシュ１２０８には、ホスト＃１のキャッシュ１３０４（１）、ホスト＃２のキャッシュ１３０４（２）．．．ホスト＃ｎのキャッシュ１３０４（ｎ）が含まれる。したがって、図示の統合ヘルスおよび負荷キャッシュ１２０８は、広義のレベルではホスト１０８（１、２．．．ｎ）によって編成され、各個々のキャッシュ１３０４に、対応するそれぞれのホスト１０８（１、２．．．ｎ）のアプリケーション固有エントリが含まれる。別法では、統合ヘルスおよび負荷キャッシュ１２０８を、広義のレベルでアプリケーション３１６の種類によって編成することができ、特定のアプリケーション種類に向けられる個々のブロックを、さらに、ホスト（１、２．．．ｎ）によって分割することができる。他のデータ構造フォーマットも、使用することができる。

図１４は、ヘルスおよび負荷情報を含むネットワーク負荷分散の例示的な方法を示すフローチャートである。フローチャート１４００には、８つのブロック１４０２〜１４１６が含まれる。フローチャート１４００の動作は、他の環境でおよびさまざまなソフトウェア方式と共に実行することができるが、図１〜３および１２〜１３Ｂを特に使用して、この方法のある態様および例を示す。たとえば、２つのブロック１４０２〜１４０４の動作が、ホスト１０８によって実行され、６つのブロック１４０６〜１４１６の動作が、負荷分散ユニット１０６によって実行される。

ブロック１４０２で、ホストのヘルスおよび負荷情報を判定する。たとえば、アプリケーション３１６（２）のヘルスおよび負荷情報１２０６を、ヘルスおよび負荷インフラストラクチャ１２０２（２）によって確かめ、ホスト１０８（２）のヘルスおよび負荷テーブル１２０４（２）に記憶することができる。ブロック１４０４で、判定されたヘルスおよび負荷情報を、負荷分散ユニットに配布する。たとえば、ヘルスおよび負荷インフラストラクチャ１２０２（２）によって、アプリケーション３１６（２）のヘルスおよび負荷情報１２０６を負荷分散ユニット１０６（１、２．．．ｕ）に送ることができる。矢印１４１８によって示されるように、ブロック１４０２および１４０４の動作は、繰り返され、その結果、（アプリケーション）ヘルスおよび負荷が、継続的に監視され、変化が発生する時に更新される。

ブロック１４０６で、ヘルスおよび負荷情報をホストから受け取る。たとえば、負荷分散ユニット１０６（１）によって、複数のホスト１０８（１、２．．．ｎ）からヘルスおよび負荷情報１２０６を受け取ることができ、これに、ホスト１０８（２）のアプリケーション３１６（２）のヘルスおよび負荷情報１２０６が含まれる。ブロック１４０８で、受け取ったヘルスおよび負荷情報をキャッシュに格納する。たとえば、負荷分散ユニット１０６（１）によって、ホスト１０８（１、２．．．ｎ）からのヘルスおよび負荷情報１２０６を統合ヘルスおよび負荷キャッシュ１２０８（１）に記憶することができる。統合ヘルスおよび負荷キャッシュ１２０８（１）の図１３Ｂの実施形態を参照すると、ホスト１０８（２）からのアプリケーション３１６（２）のヘルスおよび負荷情報１２０６を、ホスト＃２のキャッシュ１３０４（２）に記憶することができる。矢印１４２０によって示されるように、ブロック１４０６および１４０８の動作が繰り返され、その結果、（アプリケーション）ヘルスおよび負荷情報を、継続的に受け取り、変化が発生する時に更新することができる。

破線の矢印１４２２によって示されるように、負荷分散ユニット１０６によって、（アプリケーション）ヘルスおよび負荷の問題を処理しながら、クライアント１０２からの通信も処理される。ブロック１４１０で、新しい接続をリクエストするパケットを受け取る。たとえば、負荷分散ユニット１０６（１）によって、ネットワーク１０４を介してクライアント１０２（２）からＴＣＰ ＳＹＮパケットを受け取ることができる。ブロック１４１２で、キャッシュされたヘルスおよび負荷情報を調べる。たとえば、負荷分散ユニット１０６（１）によって、統合ヘルスおよび負荷キャッシュ１２０８（１）を調べることができる。具体的に言うと、負荷分散ユニット１０６（１）によって、ホスト＃１、＃２．．．＃ｎのキャッシュ１３０４（１、２．．．ｎ）にまたがって、ＴＣＰ ＳＹＮパケットが向けられるアプリケーションに関連するエントリを調べることができる。

ブロック１４１４で、キャッシュされたヘルスおよび負荷情報に応答するホストを選択する。たとえば、負荷分散ユニット１０６（１）によって、統合ヘルスおよび負荷キャッシュ１２０８（１）にキャッシュされたヘルスおよび負荷情報１２０６に応答するアプリケーション３１６（２）を有するホスト１０８（２）を選択することができる。選択されたアプリケーション３１６（およびホスト１０８）は、健全であり、追加の負荷を受け入れることができなければならない（たとえば、おそらくは、ＴＣＰ ＳＹＮパケットが向けられるアプリケーション種類であるアプリケーションの間で最も負荷の軽いアプリケーション）。

キャッシュされたヘルスおよび負荷情報の調査（ブロック１４１２での）、およびキャッシュされたヘルスおよび負荷情報に応答するホスト選択（ブロック１４１４での）は、特定の新しい接続をリクエストするパケットの受取の前におよび／またはバッチ方式を使用して実行することができる。また、選択は、多数の方式のいずれかによるものとすることができる。たとえば、トークンベースの方式またはラウンドロビンベースの方式を使用することができる。どちらの方式でも、選択に、アプリケーションオプションの間での相対負荷の重みづけを含めることができる。この調査および選択を、トークンベース方式およびラウンドロビンベース方式と共に、以下で図１８を参照して、「分類、転送、およびリクエストルーティングの例」という題名の節で、特に分類機能に関して説明する。

ターゲットホストがブロック１４１４で選択された後に、新しい接続をリクエストするパケットを、そのホストに送ることができる。ブロック１４１６で、クライアントから受け取られたパケットを、選択されたホストに転送する。たとえば、ＴＣＰ ＳＹＮパケットが、負荷分散ユニット１０６（１）から、選択されたホスト１０８（２）に転送される。この最初のパケットの転送は、やはり以下で「分類、転送、およびリクエストルーティングの例」という題名の節でさらに説明するように、クラシファイヤ３０４またはフォワーダ３０２によって直接に実現することができる。

説明される実施形態について、ヘルスおよび負荷インフラストラクチャ１２０２は、複数のホスト１０８に常駐し、これにまたがって分散されると同時に、（ヘルス及び負荷ハンドラ３１４によって表される）負荷分散ユニット１０６にも位置する。ヘルスおよび負荷インフラストラクチャ１２０２は、３つの責任を有する。第１に、ヘルスおよび負荷インフラストラクチャ１２０２は、リスニングポイントを公開して、ヘルスおよび負荷テーブル１２０４のアプリケーション状態特性１３０２（Ｂ）に関するアプリケーション状況更新を達成する。第２に、ヘルスおよび負荷インフラストラクチャ１２０２は、アプリケーション状況情報を合成して、負荷分散ユニット１０６が行わなければならないことを判定する。これは、負荷バランサ命令１３０２（Ｃ）で実施される。第３に、ヘルスおよび負荷インフラストラクチャ１２０２は、この命令をホスト１０８から負荷分散ユニット１０６に通信する。

負荷バランサ命令１３０２（Ｃ）の命令内容は、効果的に、アプリケーション状態特性１３０２（Ｂ）の情報のダイジェスト版になる。しかし、負荷分散ユニット１０６は、アプリケーション状態特性１３０２（Ｂ）の生情報ならびにこの処理された命令を受け取ることもできる。ヘルスおよび負荷テーブル１２０４のこれらおよび他のフィールドの内容の通信は、以下で図１５を参照して説明するメッセージプロトコルを使用して達成される。

図１５に、図１２に示されたホスト１０８と負荷分散ユニット１０６の間のヘルスおよび負荷情報に関連する通信の例示的なメッセージプロトコル１５００を示す。一般に、イベントドリブン機構を使用して、ホスト１０８から負荷分散ユニット１０６にヘルスおよび負荷テーブル１２０４へ変更をプッシュする。言い換えると、説明される実施形態では、ヘルスおよび負荷テーブル１２０４が更新される時に、ホスト１０８から負荷分散ユニット１０６に情報が送られる。これによって、各ヘルスおよび負荷テーブル１２０４のすべてのスナップショットを周期的に送ることがなくなり、これによって、ヘルスおよび負荷インフラストラクチャ１２０２によるネットワーク帯域幅消費が減る。

メッセージプロトコル１５００は、任意の使用可能なメッセージトランスポート機構を使用して実施することができる。そのような機構に、信頼性のあるマルチキャスト伝送、ポイントツーポイント伝送（たとえば、ユーザデータグラムプロトコル（ｕｓｅｒ ｄａｔａｇｒａｍ ｐｒｏｔｏｃｏｌ、ＵＤＰ））などが含まれる。図からわかるように、メッセージプロトコル１５００に７つのメッセージ種類１５０２〜１５１４すなわち、ハートビートメッセージ１５０２、グッドバイメッセージ１５０４、行チェンジメッセージ１５０６、テーブルスナップショット取得メッセージ１５０８、テーブルスナップショット送信メッセージ１５１０、テーブル状態仮定メッセージ（ｐｏｓｔｕｌａｔｅ ｔａｂｌｅ ｓｔａｔｅ ｍｅｓｓａｇｅ）１５１２、および誤仮定メッセージ（ｐｏｓｔｕｌａｔｅ ｗｒｏｎｇ ｍｅｓｓａｇｅ）１５１４が含まれる。

矢印１５１６および１５１８を除いて、この図によって、異なるメッセージ種類１５０２〜１５１４の間の時間的関係が暗示されていないことを理解されたい。たとえば、行チェンジメッセージ１５０６は、通常は、グッドバイメッセージ１５０４に続かない。

ハートビートメッセージ１５０２によって、特定のホスト１０８が機能していることが示され、統合ヘルスおよび負荷キャッシュ１２０８内の特定のホスト１３０４の対応する特定のキャッシュに関する対応する特定のヘルスおよび負荷テーブル１２０４の内容の、あるエラー検査が提供される。各ホスト１０８のヘルスおよび負荷インフラストラクチャ１２０２によって、各負荷分散ユニット１０６の各統合ヘルスおよび負荷キャッシュ１２０８に直接的にまたは間接的にハートビートメッセージが送られる。

ハートビートメッセージ１５０２によって、各ヘルスおよび負荷テーブル１２０４全体のスナップショットが各負荷分散ユニット１０６に周期的に送信されないことに部分的に起因して生じる統合ヘルスおよび負荷キャッシュ１２０８のデータのエージングアウト（ａｇｉｎｇ−ｏｕｔ）問題に対処する。ハートビートメッセージ１５０２の伝送方式を、以下で図１６を参照してさらに説明する。

ハートビートメッセージ１５０２には、ホストの識別子、エラー検査データ、および任意選択としてＤＮＳ名が含まれる。ホストの識別子は、構成時に選択される一意の（たとえば３２ビット）数とすることができる。エラー検査データは、チェックサム、状態変化シーケンス番号、世代番号、ＣＲＣ値など、受取り側の負荷分散ユニット１０６が、統合ヘルスおよび負荷キャッシュ１２０８の内容が送る側のホスト１０８のヘルスおよび負荷テーブル１２０４の内容と一致することを検証できるようにするものとすることができる。世代番号手法が使用される場合に、複数の世代ＩＤを、アプリケーションの「チャンク」（ｃｈｕｎｋ）に割り当てられる各世代ＩＤと共に使用することができる。その後、メッセージは、コンテキストに応じて、チャンク番号またはチャンク番号／世代ＩＤ対を参照することができる。

エラー検査データは、ヘルスおよび負荷テーブル１２０４全体に関する単一の値とすることができ、あるいは、エントリ１３０２ごとのベースで判定される複数の値とすることができる。ＤＮＳ名を任意選択として送って（たとえば「ｘ」個のハートビートごとに）、ホストの現在の正しいネットワークアドレスを検証または更新することができる。

グッドバイメッセージ１５０４は、特定のホスト１０８がシャットダウンを計画していることを示すために、特定のホスト１０８から負荷分散ユニット１０６に送られる。グッドバイメッセージ１５０４には、特定のホスト１０８のネットワークアドレスにインデクシング／マッピングすることができるホスト識別子が含まれる。グッドバイメッセージ１５０４は、「高速クリア」を早めるためのホスト１０８によるクリーンな意図的なシャットダウンに使用される。しかし、グッドバイメッセージ１５０４が失われる場合に、ハートビートメッセージ１５０２が送られなくなるので、キャッシュは、最終的に特定のホスト１０８のエントリをエージングアウトする。

行チェンジメッセージ１５０６は、特定のホスト１０８の所与のアプリケーション３１６のヘルスおよび／または負荷が変化したことを示すために、特定のホスト１０８から負荷分散ユニット１０６に送られる。行チェンジメッセージ１５０６には、ホスト識別子、アプリケーション識別子、動作、および動作のデータが含まれる。例示的なホスト識別子は、上記で、ハートビートメッセージ１５０２およびグッドバイメッセージ１５０４に関して説明した。例示的なアプリケーション識別子は、上記で、ヘルスおよび負荷テーブル１２０４のアプリケーション関連エントリ１３０２のアプリケーション識別子１３０２（Ａ）に関して説明した。

行チェンジ動作を、追加し、削除し、更新することができる。言い換えると、動作のデータを、負荷分散ユニット１０６の統合ヘルスおよび負荷キャッシュ１２０８に既に存在する情報に追加（追加動作について）または置換（更新動作について）することができる。削除動作について、データを供給する必要はない。メッセージプロトコル１５００は、単一の行チェンジメッセージ１５０６について複数の動作の実行を規定できるように定義される。したがって、特定のホスト識別子について、アプリケーション識別子、動作、および動作データの組を、その特定のホスト識別子によって識別されるホスト１０８の複数のアプリケーション３１６について繰り返すことができる。

テーブルスナップショット取得メッセージ１５０８は、特定の統合ヘルスおよび負荷キャッシュ１２０８の負荷分散ユニット１０６から個々のまたは複数のホスト１０８に送られる。このテーブルスナップショット取得メッセージ１５０８は、ホスト１０８のヘルスおよび負荷インフラストラクチャ１２０２が、それぞれのホスト１０８のそれぞれのヘルスおよび負荷テーブル１２０４のスナップショットを供給することをリクエストする。このメッセージには、リクエスト元の負荷分散ユニット１０６の識別が含まれ、このメッセージは、負荷分散ユニット１０６によって、（ｉ）負荷分散ユニット１０６に障害が発生し、回復した後に、（ｉｉ）ホスト１０８に障害が発生し、回復し、ハートビートメッセージ１５０２の送信をもう一度開始した後に、（ｉｉｉ）行チェンジメッセージ１５０６が負荷分散ユニット１０６に送られたが、メッセージが捨てられ、したがって、統合ヘルスおよび負荷キャッシュ１２０８が、それぞれのホスト１０８のそれぞれのヘルスおよび負荷テーブル１２０４と同期していない場合に、および（ｉｖ）他の場合に、使用することができる。

第３の（ｉｉｉ）状況について、統合ヘルスおよび負荷キャッシュ１２０８とそれぞれのホスト１０８のそれぞれのヘルスおよび負荷テーブル１２０４との間の同期がないことは、それぞれのホスト１０８からの後続のハートビートメッセージ１５０２によって発見される。というのは、「エラー検査」によって、統合ヘルスおよび負荷キャッシュ１２０８が古いことが示されるからである。その後、負荷分散ユニット１０６によってテーブルスナップショット取得メッセージ１５０８を送ることができ、その結果、統合ヘルスおよび負荷キャッシュ１２０８を更新することができる。したがって、３つの（ｉ、ｉｉ、ｉｉｉ）例示的な状況について、負荷分散ユニット１０６によって、その後、テーブルスナップショット取得１５０８を使用して統合ヘルスおよび負荷キャッシュ１２０８が再構成される。テーブルスナップショット取得１５０８は、ポイントツーポイントの形で各ホスト１０８に繰り返して送ることができ、あるいは、マルチキャストの形で多数のホスト１０８に１回で送ることができる。

テーブルスナップショット送信メッセージ１５１０は、矢印１５１６によって示されるように、個々のホスト１０８が、特定の負荷分散ユニット１０６からテーブルスナップショット取得メッセージ１５０８を受け取った後に、個々のホスト１０８から特定の負荷分散ユニット１０６に送られる。テーブルスナップショット送信メッセージ１５１０の内容は、ヘルスおよび負荷インフラストラクチャ１２０２によって準備され、これには、個々のホスト１０８のヘルスおよび負荷テーブル１２０４のすべてまたは少なくとも複数の行が含まれ、その結果、特定の負荷分散ユニット１０６が統合ヘルスおよび負荷キャッシュ１２０８を再構築できるようになる。テーブルスナップショット送信メッセージ１５１０は、別々に指定されるメッセージとすることができ、あるいは、行チェンジメッセージ１５０６の追加動作のシーケンスと同等にすることができる。

テーブル状態仮定メッセージ１５１２および誤仮定メッセージ１５１４は、ヘルスおよび負荷テーブル１２０４のエントリ１３０２の負荷バランサ命令１３０２（Ｃ）のターゲット負荷分散状態と現在負荷分散状態に関する。ターゲット負荷分散状態は、負荷分散ユニット１０６がその下で動作することをヘルスおよび負荷インフラストラクチャ１２０２が望む命令である。現在負荷分散状態は、負荷分散ユニット１０６が現在その下で動作するとヘルスおよび負荷インフラストラクチャ１２０２が期待するか考える命令である。一般に、この２つの負荷分散状態は、同一である。

しかし、ターゲット負荷分散状態は、状態命令変化の推移期間中に、現在負荷分散状態と異なる場合がある。たとえば、ターゲット負荷分散状態および現在負荷分散状態は、両方とも、当初はａｃｔｉｖｅにセットされる。ホスト１０８および／またはそのホストのアプリケーション３１６の問題が、検出され、ターゲット負荷分散状態命令が、ドレイニング(ｄｒａｉｎｉｎｇ)に切り替えられる。このドレイニング命令が、行チェンジメッセージ１５０６を使用して負荷分散ユニット１０６に通信される。

この命令変化が、すべての負荷分散ユニット１０６のすべての統合ヘルスおよび負荷キャッシュ１２０８に記録される前に、遅延がある。この推移期間中に、ターゲット負荷分散状態が、ドレイニングであり、現在負荷分散状態が、まだ、ホスト１０８のヘルスおよび負荷テーブル１２０４ではアクティブである。現在負荷分散状態をドレイニングに変更する前に、ヘルスおよび負荷インフラストラクチャ１２０２は、統合ヘルスおよび負荷キャッシュ１２０８が実際にドレイニングの新しい命令状態に更新されることを保証することを求める。

負荷分散ユニット１０６の統合ヘルスおよび負荷キャッシュ１２０８が新しい状態命令に更新されたことを検証するために、ヘルスおよび負荷インフラストラクチャ１２０２は、テーブル状態仮定メッセージ１５１２を負荷分散ユニット１０６に送信する。テーブル状態仮定メッセージ１５１２は、状態命令を変更しなければならないことを示す行チェンジメッセージ１５０６の送信後のある時（たとえば、所定の遅延期間の後）に送信される。テーブル状態仮定メッセージ１５１２は、この例では、テーブル状態がドレイニングでなければならないことを示す。破線の矢印１５１８によって示されるように、負荷分散ユニット１０６は、統合ヘルスおよび負荷キャッシュ１２０８が仮定される状態命令と異なる場合に、このテーブル状態仮定メッセージ１５１２に応答する。

統合ヘルスおよび負荷キャッシュ１２０８の命令が、状態仮定命令と異なる場合に、負荷分散ユニット１０６は、テーブル状態仮定メッセージ１５１２を発行したホスト１０８のヘルスおよび負荷インフラストラクチャ１２０２に、誤仮定メッセージ１５１４を送る。その後、このヘルスおよび負荷インフラストラクチャ１２０２は、統合ヘルスおよび負荷キャッシュ１２０８から誤仮定メッセージ１５１４が受け取られなくなるまで、周期的にテーブル状態仮定メッセージ１５１２を再送信する。誤仮定メッセージ１５１４が受け取られなくなった時点で、ヘルスおよび負荷インフラストラクチャ１２０２は、新しい現在負荷分散状態で行チェンジメッセージ１５０６を送る。この意味で、統合ヘルスおよび負荷キャッシュ１２０８は、現在負荷分散状態の決定的デターミナであり、ヘルスおよび負荷インフラストラクチャ１２０２は、ターゲット負荷分散状態の決定的デターミナである。

図１６に、図１２に示されたホスト１０８と負荷分散ユニット１０６の間の通信の例示的なメッセージ伝送方式を示す。例示的メッセージ伝送方式によって、通信リンケージ１２１０でハートビートメッセージ１５０２によって消費される帯域幅を減らすことができる。図１６のメッセージ伝送方式は、ハートビートメッセージ１５０２に特に適合されているが、メッセージプロトコル１５００の他のメッセージにも使用することができる。

ホスト１０８（１）、１０８（２）、１０８（３）．．．１０８（１１）、および１０８（１２）のグループが、負荷分散ユニット１０６（１）、１０６（２）．．．１０６（ｕ）と共に示されている。線のそれぞれは、ホスト１０８（１、２．．．１２）の間のメンバシップリンケージまたは包含を表す。ホスト１０８（１、２．．．１２）のグループは、負荷分散ユニット１０６にハートビート情報を伝搬させるために一緒に働くノードのメンバシップを形成する。１２のホストが示されているが、より多数またはより少数を、ホストの所与のグループの一部とすることができる。また、１つの負荷分散インフラストラクチャ１０６によってサービスされるホスト１０８の組全体を、１つ、２つ、３つ、またはより多数のホストのグループに分割することができる。

説明される実施形態では、ホスト１０８（１、２．．．１２）のグループのノードのメンバシップは、ハートビートメッセージ１５０２を負荷分散ユニット１０６に送信する責任を負うリーダーを選ぶ。ホスト１０８（１、２．．．１２）のグループの各（リーダーでない）ホスト１０８は、選ばれたリーダーにハートビートメッセージ１５０２を送る。この例では、ホスト１０８（４）が選ばれたリーダーである。

ノードのメンバシップによって、ホスト１０８（１、２．．．１２）のグループの各ホスト１０８のハートビート情報が、グループリーダーホスト１０８（４）に伝搬される。ホスト１０８（４）によって、ハートビート情報が収集され、統合ハートビートメッセージ１６０２に統合される。統合ハートビートメッセージ１６０２（１）、１６０２（２）．．．１６０２（ｕ）が、それぞれの負荷分散ユニット１０６（１）、１０６（２）．．．１０６（ｕ）に送られる。この統合ハートビートメッセージ１６０２は、任意選択として、さらに帯域幅消費を減らすために圧縮することができる。

もう１つの別法として、リーダーホスト１０８（４）によって、グループメンバシップの変化だけを統合ヘルスおよび負荷キャッシュ１２０８に転送することができる。言い換えると、このモードでは、統合ヘルスおよび負荷キャッシュ１２０８によって、それだけではないにせよ主に、メンバシップに対する状態変化が扱われる。あるホスト１０８がオンラインになる時に最初のハローが転送されることと、そのホスト１０８がオフラインになる時にグッドバイメッセージ１５０４が送信されることを保証するのは、リーダーホスト１０８（４）の責任である。さらに、ホスト１０８によって、ハートビートメッセージ１５０２が「転送」されることを周期的に指定することができる。これによって、リーダーホスト１０８（４）に、メンバシップ変更を表さない場合であっても統合ヘルスおよび負荷キャッシュ１２０８にメッセージを送ることが指示される。

ハートビートメッセージ１５０２（統合ハートビートメッセージ１６０２を含む）は、統合ヘルスおよび負荷キャッシュ１２０８がヘルスおよび負荷テーブル１２０４と非同期になった時に、負荷分散ユニット１０６によって使用される。この同期の欠如は、たとえば、統合ヘルスおよび負荷キャッシュ１２０８のクラッシュまたは他の障害および／あるいは負荷分散ユニット１０６のクラッシュまたは他の障害から生じる可能性がある。上記で説明したように、各ハートビートメッセージ１５０２に、エラー検査データが含まれ、このエラー検査データは、統合ヘルスおよび負荷キャッシュ１２０８とヘルスおよび負荷テーブル１２０４の間の同等性を検証するのに使用可能である。特定のホスト１０８および／またはそのホストのアプリケーション３１６に関する非同等性が発見された場合には、その特定のホスト１０８のＤＮＳ名が、ハートビートメッセージ１５０２から獲得される。

ＤＮＳ名が、統合ヘルスおよび負荷キャッシュ１２０８によって使用されて、テーブルスナップショット送信メッセージ１５１０の形で更新されたヘルスおよび負荷情報１２０６を得るために、テーブルスナップショット取得メッセージ１５０８が特定のホスト１０８に送信される。非同等性が発見されたホスト１０８のそれぞれに、異なるまたは同一のテーブルスナップショット取得メッセージ１５０８が送信される。最終的に、統合ヘルスおよび負荷キャッシュ１２０８内のヘルスおよび負荷情報１２０６が、新しいハートビートメッセージ１５０２によって検証可能なように、ヘルスおよび負荷テーブル１２０４のヘルスおよび負荷情報１２０６と同等になる。この形で、メッセージプロトコル１５００および同等性検査方式を使用する手動の管理なしで、障害を発生した統合ヘルスおよび負荷キャッシュ１２０８を動作状態にブートストラップすることができる。

図１７Ａおよび図１７Ｂに、それぞれヘルスおよび負荷テーブル１２０４および統合ヘルスおよび負荷キャッシュ１２０８の例示的なヘルスおよび負荷情報プロキシストレージシナリオを示す。図１２〜１６に関して上記で説明した実施形態では、ホスト１０８に、ヘルスおよび負荷インフラストラクチャ１２０２が含まれる。しかし、他の実施形態に、ヘルスおよび負荷インフラストラクチャ１２０２を含まないホストを伴うことができる。

たとえば、ホストは、ヘルスおよび負荷インフラストラクチャが、実施されないか、ポリシのためにホストにインストール不能であるかのいずれかのバージョンのアプリケーションおよび／またはオペレーティングシステムを実行している場合がある。その結果、これらの種類のホストは、その上でヘルスおよび負荷インフラストラクチャ１２０２を実行していない。ホスト１７０２は、そのような、ヘルスおよび負荷インフラストラクチャ１２０２を実行しないホストである。それでも、ホスト１７０２は、プロキシ１７０４などの１つまたは複数のプロキシで実行されるヘルスおよび負荷インフラストラクチャ１２０２を使用することができる。

プロキシ１７０４は、常駐し、実行中のヘルスおよび負荷インフラストラクチャ１２０２を備え、このヘルスおよび負荷インフラストラクチャ１２０２には、ヘルスおよび負荷テーブル１２０４が含まれる。ホスト１７０２は、ホスト１７０２で実行中のアプリケーションのヘルスおよび負荷テーブル１２０４にヘルスおよび負荷情報１２０６を供給することによって、ヘルスおよび負荷インフラストラクチャ１２０２の機能を使用することができる。別法では、プロキシ１７０４は、外部監視動作を実行することによって、ホスト１７０２のヘルスおよび負荷を推定することができる。プロキシ１７０４は、冗長性および結果の高可用性のために、プロキシ１７０４（１）および１７０４（２）として図示されている。

上記で図１２〜１６を参照して、および以下で図１８を参照して説明する実施形態では、負荷分散は、統合ヘルスおよび負荷キャッシュ１２０８を含む負荷分散ユニット１０６を用いて実現される。しかし、他の実施形態に、統合ヘルスおよび負荷キャッシュ１２０８を含まない負荷分散ユニットを伴うことができる。

たとえば、統合ヘルスおよび負荷キャッシュ１２０８を記憶または他の形で含まず、かつ／またはそれができないモノリシックな負荷分散ハードウェアまたは他の負荷分散インフラストラクチャによって、負荷分散を実現することができる。負荷バランサ１７０６は、統合ヘルスおよび負荷キャッシュ１２０８を有しない１つまたは複数の負荷分散装置を反映する。それでも、負荷バランサ１７０６は、プロキシ１７０８などの１つまたは複数のプロキシに存在する統合ヘルスおよび負荷キャッシュ１２０８を使用することができる。

プロキシ１７０８には、統合ヘルスおよび負荷キャッシュ１２０８が含まれ、この統合ヘルスおよび負荷キャッシュ１２０８に、負荷バランサ１７０６によってサービスされるホストされるアプリケーションのヘルスおよび負荷情報１２０６が記憶される。負荷バランサ１７０６によって、負荷バランサ１７０６のネイティブであり負荷バランサ１７０６によってサポートされるアプリケーションプログラミングインターフェース（ＡＰＩ）を使用してヘルスおよび負荷情報にアクセスすることによって負荷分散機能を実行する時に、統合ヘルスおよび負荷キャッシュ１２０８のヘルスおよび負荷情報１２０６を使用することができる。別法では、統合ヘルスおよび負荷キャッシュ１２０８は、ＡＰＩを呼び出して、命令を含むヘルスおよび負荷情報１２０６を負荷バランサ１７０６にプッシュすることができる。プロキシ１７０８は、冗長性およびその結果の高可用性のために、プロキシ１７０８（１）および１７０８（２）として図示されている。

図１８に、負荷分散ユニット１０６のクラシファイヤ３０４ならびにヘルスおよび負荷ハンドラ３１４を伴う例示的なターゲットアプリケーションエンドポイント割当プロシージャを示す。ヘルスおよび負荷ハンドラ３１４が、統合ヘルスおよび負荷キャッシュ１２０８を獲得した後に、ヘルスおよび負荷情報１２０６は、新しいリクエスト／接続のアプリケーションエンドポイントの選択に使用される。

上記で図１３Ｂを参照して説明したように、統合ヘルスおよび負荷キャッシュ１２０８には、複数のホスト１０８のキャッシュされたヘルスおよび負荷情報１２０６が含まれる。複数のホスト１０８から発するヘルスおよび負荷情報１２０６からの統合ヘルスおよび負荷キャッシュ１２０８の作成および更新を容易にするために、その中のヘルスおよび負荷情報１２０６が編成され、その結果、各ホスト１０８の識別子によってアクセス可能になる。しかし、ヘルスおよび負荷情報１２０６は、アプリケーションエンドポイント選択を容易にするために、アプリケーション３１６の種類によってアクセス可能にもなるように編成される。

言い換えると、ヘルスおよび負荷ハンドラ３１４は、複数のホスト１０８についてヘルスおよび負荷情報１２０６にまたがってアプリケーション３１６ごとのベースでヘルスおよび負荷情報１２０６にアクセスすることができる。所与のアプリケーション３１６のヘルスおよび負荷情報１２０６が、ホスト１０８ごとにアクセスされた後に、入力接続リクエストの割当を、ヘルスおよび負荷情報１２０６に従って実行することができる。たとえば、所与のアプリケーション３１６の健全なエンドポイントの間で使用可能な相対負荷容量を統合する、所与のアプリケーション３１６のエンドポイントの選択によって、所与のアプリケーション３１６の可能なエンドポイントを入力接続リクエストに割り当てることができる。

説明される実施形態では、クラシファイヤ３０４によって、ヘルスおよび負荷ハンドラ３１４へのターゲットアプリケーションエンドポイント割当リクエスト１８０２が行われる。図からわかるように、ターゲットアプリケーションエンドポイント割当リクエスト１８０２には、（ｉ）仮想ＩＰアドレスおよびポート、（ｉｉ）プロトコル、ならびに（ｉｉｉ）プロトコル固有情報が含まれる。したがって、ターゲットアプリケーションエンドポイント割当リクエスト１８０２は、入力接続リクエストが向けられるアプリケーション３１６の種類を識別する。

ヘルスおよび負荷ハンドラ３１４は、ターゲットアプリケーションエンドポイント割当リクエスト１８０２を受信し、多数の選択機構のうちのいずれか１つまたは複数を使用して、アプリケーション３１６の識別された種類に対応する少なくとも１つの物理エンドポイントを選択する。待ち時間を減らすために、ヘルスおよび負荷ハンドラ３１４は、多数の入力接続リクエストに対して使用されるアプリケーションエンドポイントの割当を選択する。この割当は、ターゲットアプリケーションエンドポイント割当応答１８０４を使用して、ヘルスおよび負荷ハンドラ３１４からクラシファイヤ３０４に供給される。図からわかるように、ターゲットアプリケーションエンドポイント割当応答１８０４には、アプリケーション３１６の識別された種類の物理的ＩＰアドレスおよびポートの割当（エンドポイントＩＰ１、ＩＰ２、およびＩＰ３など）が含まれる。

ターゲットアプリケーションエンドポイント割当応答１８０４の割当は、１つまたは複数の割当方式を使用して完了することができる。たとえば、トークン割当方式１８０６およびパーセンテージ割当方式１８０８が図示されている。トークン割当方式１８０６は、ユニットベースの割当方式であり、パーセンテージ割当方式１８０８は、時間ベースの割当方式である。

トークン割当方式１８０６では、相対的な負荷および容量の比率に応じて健全なエンドポイントＩＰ１、ＩＰ２、およびＩＰ３のそれぞれにトークンを割り当てる。図示の、総使用可能容量の例では、ＩＰ１が、使用可能容量の４０％を有し、ＩＰ２が、使用可能容量の３５％を有し、ＩＰ３が、使用可能容量の２５％を有する。したがって、トークンの総数が、これらの比率に従って分割される。トークンの総数は、ターゲットアプリケーションエンドポイント割当リクエスト１８０２の一部として供給するか、ヘルスおよび負荷ハンドラ３１４によって判定することができる。

１０、４５、１００、２５０、６３７、１０００など、トークンの総数の任意の値を使用することができる。この値は、毎秒の接続リクエストの数、ならびにアプリケーションヘルスおよび／または負荷が変化する速度／頻度に依存して設定することができる。クラシファイヤ３０４は、トークンが使い果たされるまで、アプリケーションエンドポイント割当に関する接続リクエストに応答する時に、１つのトークンを「使い果たし」／消費し、その後、クラシファイヤ３０４は、ターゲットアプリケーションエンドポイント割当リクエスト１８０２を使用して別のトークン割当をリクエストする。

パーセンテージ割当方式１８０８では、類似する形で使用可能な相対容量が判定される。しかし、トークンの代わりに、アプリケーションエンドポイントあたりのこの判定された使用可能相対容量が、持続時間タイマ１８１０と共にクラシファイヤ３０４に供給される。クラシファイヤ３０４によって、持続時間タイマ１８１０が満了するまで、ターゲットアプリケーションエンドポイントが、使用可能な相対容量パーセンテージに従って入力接続リクエストに割り当てられる。

パーセンテージ割当方式１８０８について、クラシファイヤ３０４は、割り当てられたパーセンテージを厳守し、持続時間タイマ１８１０の時間を記憶するために、アプリケーションエンドポイント割当のランニングレコードを維持する。タイマが満了する時に、クラシファイヤ３０４は、ターゲットアプリケーションエンドポイント割当リクエスト１８０２を使用して、別のパーセンテージ割当をリクエストする。

トークン割当方式１８０６で、時間制限も使用できることに留意されたい。割り当てられたトークンが古すぎる場合に、これを破棄し、新しいトークンを獲得しなければならない。そうでなければ、クラシファイヤ３０４は、現在は古すぎるヘルスおよび負荷情報に基づいて前に割り当てられた古いトークンを消費する可能性がある。クラシファイヤ３０４によるアプリケーションエンドポイント割当の使用を、以下で、「分類、転送、およびリクエストルーティングの例」という題名の節でさらに説明する。

（セッショントラッキングの例）
この節では、セッション情報などのホスト状態情報がネットワーク負荷分散のためにどのように収集され、ネットワーク負荷分散においてどのように使用されるかを説明する。この節では、主に図１９〜２４を参照し、セッショントラッカ３０８（図３）によって提供されるセッションアフィニティ保存機能を示す。上記で図１〜３を参照して説明したように、各ホスト１０８は、クライアント１０２にサービスを提供する１つまたは複数のアプリケーション３１６をホストする。セッショントラッカ３０８は、ネットワーク負荷分散のある記述される実施形態のために、アプリケーション３１６とクライアント１０２の間で確立される接続のコンテキストに関するセッション情報を使用する。

図１９に、セッション情報１９０２を含む例示的なネットワーク負荷分散手法を示す。接続［１］には、クライアント１０２（１）が、負荷分散インフラストラクチャ１０６を介してホスト１０８（２）と新たな接続を行うことが示されている。負荷分散インフラストラクチャ１０６は、１つまたは複数の負荷分散ユニット１０６から構成される場合がある。接続リクエストが、負荷分散インフラストラクチャ１０６に到達すると、そのリクエストは、通常は、ホスト１０８および／またはアプリケーション３１６のヘルスおよび／または負荷情報（図１９には明示せず）に応答するネットワーク負荷分散機能を使用してホスト１０８にルーティングされる。

接続［１］が行われると、クライアント１０２（１）と、サービスするアプリケーション３１６との間でセッションが確立され、このアプリケーション３１６は、この例ではホスト１０８（２）上にある。このセッションは、クライアント１０２（１）とホスト１０８（２）の間の通信交換のコンテキストを提供する。セッションコンテキストの情報は、ホスト１０８（２）に記憶される。接続［１］が完了すると、セッションコンテキストを再び使用することはできない。その一方で、クライアント１０２（１）が、アプリケーション３１６によって提供されるサービスのために、ホスト１０８と別の接続を開始することを試みる場合に、セッションコンテキストは、再び有用になる場合がある。この別の接続が、セッションコンテキストを記憶するホストと同一のホスト１０８（２）にルーティングされない場合には、クライアント１０２（１）は、新しいセッションコンテキストを確立しなければならず、これは、時間がかかり、データ／処理が集中し、かつ／またはクライアント１０２（１）の人間のユーザをいらいらさせるものになる可能性がある。ヘルスおよび／または負荷情報に基づくネットワーク負荷分散を用いると、第２の接続がホスト１０８（２）にルーティングされる可能性がランダム以上になる可能性はない。

しかし、負荷分散インフラストラクチャ１０６が、セッション情報とホスト１０８の間のマッピングにアクセスできる場合には、負荷分散インフラストラクチャ１０６は、前に確立されたセッションに関連する接続リクエストを、適切なホスト１０８にルーティングすることができる。セッション情報の一部は、負荷分散インフラストラクチャ１０６を通って流れるパケットの内容から推測できる。しかし、この手法は、多数の理由から、不正確であり、無計画である。第１に、セッション確立および終了は、単に推測されるにすぎない。第２に、一部のセッションは、パケットに含まれる適切な表示を用いて「公式には」終了しない。たとえば、一部のセッションは、単純にタイムアウトする。第３に、ホスト１０８（２）からクライアント１０２（１）に送られるパケットは、負荷分散インフラストラクチャ１０６を含まないパスを通る場合があり、このことは、セッション情報に関する負荷分散インフラストラクチャ１０６によるパケットのスヌーピングを妨げる。

図１９からわかるように、ホスト１０８は、セッション情報（ＳＩ）１９０２を負荷分散インフラストラクチャ１０６に供給する。ホスト１０８からのセッション情報１９０２を使用して、セッションアフィニティプリザーバ（ｐｒｅｓｅｒｖｅｒ）１９０４は、確立されたセッションと、セッションがその上で確立されたホスト１０８との間のアフィニティを保存することができる。セッション情報１９０２には、クライアント１０２と特定のホスト１０８の間で確立された各セッションとその特定のホスト１０８の間のリンケージまたはマッピングが含まれる。このマッピングは、ホストセッション情報マッピング１９０６の一部としてセッションアフィニティプリザーバ１９０４からアクセス可能である。セッション情報１９０２のより詳細な例を、以下で特に図２０、２２、２３Ａ、および２３Ｂを参照して説明する。

セッショントラッキングに関するある説明される実施形態で、クライアント１０２の論理的性質が関係する。図１に関して上記で注記したように、クライアント１０２は、特定の装置および／またはある装置の特定のユーザであり得る。その結果、異なる装置からホスト１０８にアクセスするユーザクライアント１０２のセッションアフィニティを、保存することができる。したがって、セッション情報１９０２を使用するセッション継続性を、プロキシシナリオ（たとえば、インターネットサービスプロバイダ（ＩＳＰ）のプロキシ）でも実現することができる。

接続［１］の例を続けると、ホスト１０８（２）で確立されるセッションが、セッション情報１９０２として負荷分散インフラストラクチャ１０６に供給される。具体的に言うと、（ｉ）クライアント１０２（１）およびホスト１０８（２）のセッションコンテキストと（ｉｉ）ホスト１０８（２）の識別子との間のリンケージ／マッピングが、ホストセッション情報マッピング１９０６で作成される。接続［２］の接続リクエストが、その後、同一のセッションコンテキストに関して到着する時に、セッションアフィニティプリザーバ１９０４によって、ホストセッション情報マッピング１９０６内でこのセッションコンテキストが突き止められ、リンケージ／マッピングから、ホスト１０８（２）がこのセッションコンテキストに関連することが確かめられる。

ホストセッション情報マッピング１９０６からセッションアフィニティプリザーバ１９０４によって確かめられたリクエストされたセッションコンテキストへのホスト１０８（２）のマッピングに応答して、接続［２］が、ホスト１０８（２）にルーティングされる。この意味で、セッションアフィニティの保存は、負荷分散インフラストラクチャ１０６にとって、アプリケーションヘルスおよび負荷ベースのネットワーク負荷分散決定よりも優先順位が高い。しかし、ヘルスおよび／または負荷は、たとえば負荷が極端に高い時またはセッション関連アプリケーションおよび／またはホストが障害状態である時に、セッショントラッキングよりも重要なネットワーク負荷分散要因になる場合がある。

多くの種類の接続が、セッション関連である可能性がある。その例には、ＴＣＰ接続、トランスポートレイヤセキュリティ（ＴＬＳ）／ＳＳＬセッション、ＰＰＴＰセッション、ＩＰＳｅｃ／Ｌ２ＴＰセッション、ＩＳＡセッション、ＨＴＴＰクッキーベースセッション、ターミナルサーバセッション、管理者によって定義されるセッションなどが含まれる。説明のために、ＴＰＣ接続を、ＴＣＰパケットのセッションとみなす。また、管理者によるセッションの定義のモデルを、列挙し、サポートすることができる。さらに、タイムアウトによって境界を示されるクライアントＩＰアドレスベースのセッションも、サポートすることができる。これは、比較的非インテリジェントなセッションサポートであるが、一部のユーザによって期待されるサポートである。

クライアント１０２からの接続リクエストは、所望のセッションの種類によって変化する。たとえば、種類「ＴＰＣ接続」のセッションについて、接続リクエストに、ＴＰＣパケットが含まれる。種類「ＳＳＬセッション」のセッションについて、接続リクエストに、ＴＣＰ接続が含まれる。他のそのような接続リクエストは、他のセッション種類に対応する。これらの例によって、セッションレイヤがどのようにしてあるかも示される。より下位のセッションレベルで、ＴＣＰ接続に関するセッションコンテキストに、ＴＣＰ４タプル、セッション番号、送信／受信されるバイト数などを含めることができる。より上位のセッションレベルで、ＳＳＬセッションのセッションコンテキストに、３２バイトセッションＩＤ、ホスト１０８に供給されるクライアント１０２の公開鍵などを含めることができる。

図２０に、通知２００６およびメッセージ２００８を使用するセッション情報の通信を用いる例示的なネットワーク負荷分散手法を示す。複数の負荷分散ユニット１０６（１）、１０６（２）．．．１０６（ｕ）および複数のホスト１０８（１）、１０８（２）．．．１０８（ｎ）が示されている。それぞれのホスト１０８（１）、１０８（２）．．．１０８（ｎ）に、そこに常駐し、その上で実行されている１つまたは複数のそれぞれのアプリケーション３１６（１）、３１６（２）．．．３１６（ｎ）が含まれる。通知２００６は、アプリケーション３１６からセッション情報を供給するのに使用され、メッセージ２００８は、ホスト１０８から負荷分散ユニット１０６にセッション情報を供給するのに使用される。

図からわかるように、それぞれのホスト１０８（１）、１０８（２）．．．１０８（ｎ）に、それぞれのセッショントラッキングインフラストラクチャ（ＳＴＩ）２００２（１）、２００２（２）．．．２００２（ｎ）が含まれる。それぞれのセッショントラッキングインフラストラクチャ２００２（１）、２００２（２）．．．２００２（ｎ）に、それぞれのセッションテーブル２０１４（１）、２０１４（２）．．．２０１４（ｎ）が含まれる（図１９にはセッションテーブル２０１４（１）だけが明示的に図示されている）。

それぞれの負荷分散ユニット１０６（１）、１０６（２）．．．１０６（ｕ）に、それぞれのトラフィックルーティング機能（ＴＲＦ）２０１２（１）、２０１２（２）．．．２０１２（ｕ）が含まれる。トラフィックルーティング機能２０１２に、たとえば、それぞれクラシファイヤ３０４およびリクエストルータ３０６によって提供されるものなどの、分類機能および／またはリクエストルーティング機能を含めることができる。負荷分散ユニット１０６（１）、１０６（２）．．．１０６（ｕ）の全域で分散されるのが、分散セッショントラッキングマネージャ２０１０である。

説明される実施形態では、トラフィックルーティング機能２０１２および分散セッショントラッキングマネージャ２０１０が、負荷分散インフラストラクチャ１０６の一部である。セッショントラッキングインフラストラクチャ２００２も、負荷分散インフラストラクチャ１０６の（たとえばリモートの）一部とすることができる。

ＡＰＩ２００４を使用して、アプリケーション３１６からセッショントラッキングインフラストラクチャ２００２にセッション情報を供給する。ＡＰＩ２００４を使用して、アプリケーション３１６は、それに対するさまざまな変更を含むセッション情報についてセッショントラッキングインフラストラクチャ２００２に通知する権限を与えられる。具体的に言うと、各アプリケーション３１６は、通知２００６を供給することができ、セッショントラッキングインフラストラクチャ２００２は、通知２００６を受け入れることができる。

セッションが新たに確立されるかオープンされる時に、セッションが確立されたことの通知（またはセッション確立通知２００６（Ｅ））が、アプリケーション３１６から供給される。セッション確立通知２００６（Ｅ）には、セッション識別子と、任意選択としてアプリケーション３１６の識別子が含まれる。セッションが終了されるかクローズされる時に、セッションが終了したことの通知（または、セッション終了通知２００６（Ｔ））が、アプリケーション３１６から供給される。セッション終了通知２００６（Ｔ）にも、セッション識別子と、任意選択としてアプリケーション３１６の識別子が含まれる。

セッショントラッキングインフラストラクチャ２００２は、セッション確立通知２００６（Ｅ）を受け入れる時に、新しいセッションのエントリをセッションテーブル２０１４に挿入する。例示的なセッションテーブル２０１４を、以下で図２３Ａを参照して説明する。セッショントラッキングインフラストラクチャ２００２は、セッション終了通知２００６（Ｔ）を受け入れる時に、セッションテーブル２０１４内の古いセッションのエントリを除去する。

セッションテーブル２０１４（１）は、ホスト１０８（１）上のアプリケーション３１６（１）に関するセッション情報１９０２の正式の供給源である。しかし、一般に、セッション参照を有する入力接続リクエストのそれぞれの受信時にセッションテーブル２０１４にアクセスするためにホスト１０８に連絡するようにトラフィックルーティング機能２０１２に要求すると、待ち時間が多すぎる。したがって、セッション情報１９０２は、負荷分散ユニット１０６でキャッシュに格納される。

負荷分散ユニット１０６で、分散セッショントラッキングマネージャ２０１０によって、セッショントラッキング管理責任の一部として、セッション情報１９０２がキャッシュに格納される。一般に、分散セッショントラッキングマネージャ２０１０は、各負荷分散ユニット１０６に部分的に常駐する分散アプリケーションおよび／または仮想サービスである。論理セッションごとに、分散セッショントラッキングマネージャ２０１０によって、信頼性がありスケーラブルな形でそのセッション情報の少なくとも１つのキャッシュされたコピーが保持され、このコピーは、セッション参照を有する入力接続リクエストが負荷分散ユニット１０６によって受け取られる時に、トラフィックをルーティングするためにすばやく使用することができる。

ホスト１０８と負荷分散ユニット１０６の間の通信は、ホスト１０８から送られたメッセージ２００８が、所期の負荷分散ユニット１０６に到着することを保証する信頼性のあるプロトコルによって実現される。各ホスト１０８は、メッセージ２００８の所期の負荷分散ユニット１０６である少なくとも１つの特定の負荷分散ユニット１０６に束縛される。この束縛は、セッショントラッキングインフラストラクチャ２００２と分散セッショントラッキングマネージャ２０１０の間でセッショントラッキングメッセージ２００８を送るために、特定の負荷分散ユニット１０６のＩＰアドレスを各ホスト１０８に割り当てることによって作成される。負荷分散インフラストラクチャ１０６の高可用性を実現するために、負荷分散ユニット１０６に障害が発生する場合に、もう１つの負荷分散ユニット１０６が、障害を発生した負荷分散ユニット１０６のＩＰアドレスを引き継ぐ。ＩＰアドレス引継ぎのための障害検出は、ハートビートまたは別のアライブネス（ａｌｉｖｅｎｅｓｓ）監視方式を使用して達成することができる。

したがって、メッセージ２００８によって、セッショントラッキングインフラストラクチャ２００２から分散セッショントラッキングマネージャ２０１０にセッション情報１９０２が通信される。たとえば、セッショントラッキングインフラストラクチャ２００２によってセッション確立通知２００６（Ｅ）が受け入れられる時に、セッショントラッキングインフラストラクチャ２００２によって、セッションアップメッセージ２００８（Ｕ）も分散セッショントラッキングマネージャ２０１０に送られる。セッションアップメッセージ２００８（Ｕ）には、セッション識別子、ホスト識別子、および任意選択の他の情報が含まれる。セッションアップメッセージ２００８（Ｕ）の内容は、分散セッショントラッキングマネージャ２０１０の実施形態によってセッションごとに記憶できる情報に関して、以下で図２３Ｂを参照してさらに説明する。セッショントラッキングインフラストラクチャ２００２によって、セッション終了通知２００６（Ｔ）が受け入れられる時に、セッショントラッキングインフラストラクチャ２００２によって、分散セッショントラッキングマネージャ２０１０にセッションダウンメッセージ２００８（Ｄ）も送られる。メッセージ２００８は、セッショントラッキングインフラストラクチャ２００２が、通知２００６に応答して適切にセッションテーブル２０１４を変更する前、変更中、または変更の後に送ることができる。

図２１は、通知およびメッセージを使用するセッション情報の通信を用いるネットワーク負荷分散の例示的な方法を示すフローチャート２１００である。フローチャート２１００には、１５個のブロック２１０２〜２１３０が含まれる。フローチャート２１００の動作は、他の環境およびさまざまなソフトウェア方式で実行することができるが、図１〜３および１９〜２０を使用して、特にこの方法のある態様および例を示す。

たとえば、４つのブロック２１０２〜２１０４および２１１８〜２１２０の動作は、アプリケーション３１６によって実行され、６つのブロック２１０６〜２１１０および２１２２〜２１２６の動作は、セッショントラッキングインフラストラクチャ２００２によって実行され、５つのブロック２１１２〜２１１６および２１２８〜２１３０は、分散セッショントラッキングマネージャ２０１０によって実行される。８つのブロック２１０２〜２１１６の動作は、主にセッションのオープンを対象とし、７つのブロック２１１８〜２１３０の動作は、主にセッションのクローズを対象とする。

ブロック２１０２で、セッションをオープンする。たとえば、アプリケーション３１６によって、クライアント１０２とのセッションをオープンすることができる。ブロック２１０４で、セッション確立通知を供給する。たとえば、アプリケーション３１６によって、セッションのオープンの結果としておよび／またはセッションのオープンに関連して、ＡＰＩ２００４を使用して、セッショントラッキングインフラストラクチャ２００２にセッション確立通知２００６（Ｅ）を供給することができる。

ブロック２１０６で、セッション確立通知を受け入れる。たとえば、セッショントラッキングインフラストラクチャ２００２によって、ＡＰＩ２００４に従って、アプリケーション３１６からセッション確立通知２００６（Ｅ）を受け入れることができる。ブロック２１０８で、セッションテーブルにエントリを挿入する。たとえば、セッショントラッキングインフラストラクチャ２００２によって、オープンされたセッションに関するエントリをセッションテーブル２０１４に挿入することができる。そのような挿入の例を、以下で特に図２３Ａを参照してさらに説明する。ブロック２１１０で、セッションアップメッセージを送る。たとえば、セッショントラッキングインフラストラクチャ２００２によって、信頼性のある通信プロトコルを使用して、分散セッショントラッキングマネージャ２０１０にセッションアップメッセージ２００８（Ｕ）を送ることができる。

ブロック２１１２で、セッションアップメッセージを受け取る。たとえば、分散セッショントラッキングマネージャ２０１０によって、信頼性のある通信プロトコルに従って、セッショントラッキングインフラストラクチャ２００２からセッションアップメッセージ２００８（Ｕ）を受け取ることができる。ブロック２１１４で、セッション情報エントリを作成する。たとえば、分散セッショントラッキングマネージャ２０１０によって、１つまたは複数の負荷分散ユニット１０６でキャッシュされるセッション情報１９０２のセッション情報エントリを作成することができる。そのような作成およびその後の追加の例を、以下で特に図２２および２３Ｂを参照してさらに説明する。

ブロック２１１６で、セッション情報を用いてネットワークトラフィックをルーティングする。たとえば、分散セッショントラッキングマネージャ２０１０と共に、トラフィックルーティング機能２０１２によって、作成されたセッション情報エントリを含むキャッシュされたセッション情報１９０２を使用して、セッション参照を有する入力接続リクエストをルーティングすることができる。そのようなトラフィックルーティングの例を、以下で、特に図２４を参照してさらに説明する。追加の例を、下の「分類、転送、およびリクエストルーティングの例」という題名の節で説明する。

ブロック２１１８で、セッションをクローズする。たとえば、アプリケーション３１６によって、クライアント１０２とのセッションをクローズすることができる。ブロック２１２０で、セッション終了通知を供給する。たとえば、アプリケーション３１６によって、セッションクローズの結果としておよび／またはセッションクローズに関連して、ＡＰＩ２００４を使用して、セッショントラッキングインフラストラクチャ２００２にセッション終了通知２００６（Ｔ）を供給することができる。

ブロック２１２２で、セッション終了通知を受け入れる。たとえば、セッショントラッキングインフラストラクチャ２００２によって、ＡＰＩ２００４に従って、アプリケーション３１６からセッション終了通知２００６（Ｔ）を受け入れることができる。ブロック２１２４で、セッションテーブルのエントリを除去する。たとえば、セッショントラッキングインフラストラクチャ２００２によって、クローズされたセッションの、セッションテーブル２０１４内のエントリを除去することができる。ブロック２１２６で、セッションダウンメッセージを送る。たとえば、セッショントラッキングインフラストラクチャ２００２によって、信頼性のある通信プロトコルを使用して、分散セッショントラッキングマネージャ２０１０にセッションダウンメッセージ２００８（Ｄ）を送ることができる。

ブロック２１２８で、セッションダウンメッセージを受け取る。たとえば、分散セッショントラッキングマネージャ２０１０によって、信頼性のある通信プロトコルに従って、セッショントラッキングインフラストラクチャ２００２からセッションダウンメッセージ２００８（Ｄ）を受け取ることができる。ブロック２１３０で、セッション情報エントリを破壊する。たとえば、分散セッショントラッキングマネージャ２０１０によって、セッション情報エントリを有する負荷分散ユニット１０６でキャッシュされたセッション情報１９０２のセッション情報エントリを破壊することができる。そのような破壊およびその後の削除の例を、以下で特に図２２および２３Ｂを参照してさらに説明する。

図２２に、複数の負荷分散ユニット１０６でセッション情報を管理する例示的な手法を示す。それぞれの負荷分散ユニット１０６（１）、１０６（２）．．．１０６（ｕ）に、分散アトムマネージャ（ＤＡＭ）２２０２のそれぞれの部分２２０２（１）、２２０２（２）．．．２２０２（ｕ）が含まれる。ＤＡＭ２２０２は、分散セッショントラッキングマネージャ２０１０の例示的な実施形態である。それぞれのＤＡＭ部分２２０２（１）、２２０２（２）．．．２２０２（ｕ）に、ＤＡＭテーブル（ＤＡＭＴ）２２０６のそれぞれの部分２２０６（１）、２２０６（２）．．．２２０６（ｕ）が含まれる。

ＤＡＭ２２０２は、信頼性がありスケーラブルな形でセッション情報１９０２を管理し、その結果、トラフィックルーティング機能２０１２がこれを使用してセッションアフィニティを保存できるようになる、分散アプリケーションまたは仮想サービスである。たとえば、トラフィックルーティング機能２０１２によって、ＡＰＩ（特に図示せず）を使用してＤＡＭ２２０２にアクセスして、ＤＡＭＴ２２０６を検索するか検索させることができる。関数呼出し２２０４、ＤＡＭ２２０２の動作、および図２２の他の態様を、以下で、図２３Ａおよび２３Ｂの説明の後にさらに説明する。

図２３Ａは、図２０に示された例示的なセッションテーブル２０１４を示す図である。セッションテーブル２０１４には、「ｖ」個のエントリ２３０２（１）、２３０２（２）．．．２３０２（ｖ）が含まれる。各エントリ２３０２は、アプリケーション３１６から受け入れられたセッション確立通知２００６（Ｅ）に応答してセッショントラッキングインフラストラクチャ２００２によって挿入される。各エントリ２３０２は、アプリケーション３１６から受け入れられたセッション終了通知２００６（Ｔ）に応答して、セッショントラッキングインフラストラクチャ２００２によって除去される。

上記で説明したように、各セッション確立通知２００６（Ｅ）に、セッション識別子および任意選択としてアプリケーション３１６の識別子が含まれる。セッションテーブル２０１４内のそれぞれのエントリ２３０２（１）、２３０２（２）．．．２３０２（ｖ）に、（ｉ）セッション識別子２３０２（１Ｉ）、２３０２（２Ｉ）．．．２３０２（ｖＩ）、および（ｉｉ）セッション種類および／またはアプリケーション２３０２（１Ｔ）、２３０２（２Ｔ）．．．２３０２（ｖＴ）のそれぞれのフィールドが含まれる。

セッション種類および／またはアプリケーション２３０２（Ｔ）は、''ＴＣＰ''、''ＩＰＳＥＣ''、''Ｔｅｒｍｉｎａｌ Ｓｅｒｖｅｒ''、''ＨＴＴＰ−ｃｏｏｋｉｅ''、上記で注記したアプリケーション種類などとすることができる。セッション識別子２３０２（Ｉ）は、''＜発信元ＩＰアドレス、発信元ＴＣＰポート、宛先ＩＰアドレス、宛先ＴＣＰポート＞''、''Ｃｌｉｅｎｔ ＩＰ＝１７２．３０．１８９．１２２''、''Ｕｓｅｒ＝’ｊｏｅ＿ｕｓｅｒ’''、''Ｃｏｏｋｉｅ＝’｛ｂ７５９５ｃｃ９−ｅ６８ｂ−４ｅｂ０−９ｂｆ１−ｂｂ７１７ｂ３１ｄ４４７｝’''、別のもの、たとえばセッションのアプリケーション固有識別子などとすることができる。ＴＣＰ接続／セッション種類の場合に、セッション識別子２３０２（Ｉ）を、その代わりに、ＴＣＰ４タプル（ＩＰｖ４またはＩＰｖ６）の正規版とすることができる。セッション識別子２３０２（Ｉ）およびアプリケーション／セッション種類２３０２（Ｔ）のフィールドの他の値を、その代わりに使用することができる。

図２３Ｂは、図２２に示された例示的な分散アトムマネージャ（ＤＡＭ）テーブル（ＤＡＭＴ）２２０６を示す図である。ＤＡＭテーブル２２０６には、「ｗ」個のエントリ２３０４（１）、２３０４（２）．．．２３０４（ｗ）が含まれる。各セッション情報エントリ２３０４は、セッショントラッキングインフラストラクチャ２００２から受け取られるセッションアップメッセージ２００８（Ｕ）に応答してＤＡＭ２２０２によって作成される。各セッション情報エントリ２３０４は、セッショントラッキングインフラストラクチャ２００２から受け取られるセッションダウンメッセージ２００８（Ｄ）に応答して破壊される。以下でさらに説明するように、ＤＡＭテーブル２２０６のセッション情報エントリ２３０４は、実際には、関数呼出し２２０４を使用して、ＤＡＭ２２０２によって操作することができる。

上記で説明したように、セッションアップメッセージ２００８（Ｕ）に、セッション識別子、ホスト識別子、および任意選択の他の情報が含まれる。ＤＡＭテーブル２２０６内のそれぞれのセッション情報エントリ２３０４（１）、２３０４（２）．．．２３０４（ｗ）に、（ｉ）キー２３０４（１Ｋ）、２３０４（２Ｋ）．．．２３０４（ｗＫ）、（ｉｉ）データ２３０４（１Ｄ）、２３０４（２Ｄ）．．．２３０４（ｗＤ）、および（ｉｉｉ）メタデータ２３０４（１Ｍ）、２３０４（２Ｍ）．．．２３０４（ｗＭ）が含まれる。たとえば、キー２３０４（Ｋ）フィールドの値を、英数字ストリングとすることができ、データ２３０４（Ｄ）フィールドの値を、２進ビットとすることができる。キー２３０４（Ｋ）の値を、２進ビットとすることもできる。

キー２３０４（Ｋ）は、セッション識別子２３０２（Ｉ）に対応するものとすることができる。データ２３０４（Ｄ）は、セッションコンテキストが存在するホスト１０８のネットワークアドレスなどのホスト識別子に対応するものとすることができる。メタデータ２３０４（Ｍ）は、他の任意選択の情報に対応するものとすることができる。そのようなメタデータ２３０４（Ｍ）の例に、アトム衝突を解決し、アトムアライブネスを追跡する（たとえばタイムアウト機構を介して）のにＤＡＭ２２０２によって内部で使用されるデータを含めることができる（アトミックとしてのエントリ２３０４のこの特性記述は、下の段落でさらに説明する）。具体的に言うと、メタデータ２３０４（Ｍ）に、とりわけ、ＤＡＭテーブル２２０６にセッション情報エントリ２３０４を追加したエンティティ（たとえば、トラフィックルーティング機能２０１２のインスタンス）の識別が含まれる。

説明される実施形態では、各セッション情報エントリ２３０４は、ＤＡＭ２２０２がエントリ２３０４を総括して追加、削除、コピーなどを行えるが、ＤＡＭ２２０２は、通常、エントリ２３０４全体の一部を修正しないという意味でアトミックである。したがって、アトミックエントリ２３０４は、セッションアフィニティ保存実施形態の可用性およびスケーラビリティを実施するために、ＤＡＭ２２０２によってＤＡＭテーブル２２０６にまたがって、追加、削除、コピー、および他の形で操作される。

関数呼出し２２０４（図２２の）は、ＤＡＭテーブル２２０６のアトミックエントリ２３０４を操作するために、ＤＡＭ２２０２によって使用可能である。関数呼出し２２０４は、ポイントツーポイントまたはマルチキャストの形で、ある負荷分散ユニット１０６から１つまたは複数の他の負荷分散ユニット１０６に通信することができる。この関数呼出しに、追加アトム２２０４（Ａ）、削除アトム２２０４（Ｄ）、照会アトム２２０４（Ｑ）、およびリターンアトム２２０４（Ｒ）が含まれる。

追加アトム２２０４（Ａ）は、ＡｄｄＡｔｏｍ（キー、データ）の形になり、アトミックエントリ２３０４を１つまたは複数のＤＡＭテーブル２２０６に追加するのに使用される。したがって、追加アトム２２０４（Ａ）関数呼出しを、ＡｄｄＡｔｏｍ（＜セッション識別子＞、ホストＩＰアドレス）として定式化することができる。削除アトム２２０４（Ｄ）は、ＤｅｌｅｔｅＡｔｏｍ（キー）の形になり、１つまたは複数のＤＡＭテーブル２２０６のアトミックエントリ２３０４を削除するのに使用される。削除アトム２２０４（Ｄ）関数呼出しは、キー２３０４（Ｋ）によって識別されるセッションのコピーを有することが既知のＤＡＭテーブル２２０６に向けることができ、あるいは、コピーが削除されることを保証するためにすべてのＤＡＭテーブル２２０６にマルチキャストすることができる。

照会アトム２２０４（Ｑ）は、ＱｕｅｒｙＡｔｏｍ（キー）の形になり、入力接続リクエストによって参照されるセッション識別子が、特定のＤＡＭ部分２２０２の特定のローカルＤＡＭテーブル２２０６で突き止められない時に、特定のＤＡＭ部分２２０２によって使用される。照会アトム２２０４（Ｑ）関数呼出しは、１つまたは複数の（おそらくすべてを含む）他のＤＡＭ部分２２０２に送られる。これに応答して、各他のＤＡＭ部分２２０は、キー／セッション識別子についてそのローカルＤＡＭテーブル２２０６を調べる。キーが別のＤＡＭ部分２２０２によって突き止められる場合に、この別のＤＡＭ部分２２０２が、リターンアトム２２０４（Ｒ）によってリプライされる。

リターンアトム２２０４（Ｒ）は、ＲｅｔｕｒｎＡｔｏｍ（キー、データ）の形になり、照会アトム２２０４（Ｑ）関数呼出しに応答するのに使用される。リターンアトム２２０４（Ｒ）関数呼出しは、ＤＡＭ部分２２０２が、照会アトム２２０４（Ｑ）呼出しで指定されたキー２３０４（Ｋ）によって識別されるリクエストされたアトミックエントリ２３０４をローカルＤＡＭテーブル２２０６内に有する時に使用される。リターンアトム２２０４（Ｒ）関数呼出しは、照会アトム２２０４（Ｑ）関数呼出しを発行したＤＡＭ部分２２０２に向けることができる。

追加アトム２２０４（Ａ）関数呼出しは、セッションアップメッセージ２００８（Ｕ）に応答して、かつ／または１つまたは複数の他のＤＡＭテーブル２２０６にアトミックエントリ２３０４を複製するために、使用される。そのような複製は、冗長性および／またはスケーラビリティのためのものとすることができる。

削除アトム２２０４（Ｄ）関数呼出しは、セッションダウンメッセージ２００８（Ｄ）に応答して使用され、１つまたは複数の他のＤＡＭテーブル２２０６に送ることもできる。アトミックエントリ２３０４が削除された後に、そのアトミックエントリ２３０４は、ＤＡＭ２２０２と共にとどまるように「ゾンビ」状態に入ることができ、任意選択として、その結果、アトミックエントリ２３０４のメタデータ２３０４（Ｍ）フィールドにゾンビ表示がある状態でＤＡＭテーブル２２０６とともに実際は記憶されている。

したがって、アトミックエントリ２３０４が削除された後に、そのエントリは、ゾンビ状態でＤＡＭ２２０２およびＤＡＭテーブル２２０６に留まることができ、その結果、この（現在は死んでクローズされた）セッションのパケットが、正しいプロトコル固有の扱いのためにセッションコンテキストのホスト１０８に向けられる。たとえば、ＴＣＰ接続が破壊された後に受け取られるＴＣＰパケットが、その接続を終了したホスト１０８に向けられる。このホスト１０８は、適切に、おそらくはＲＳＴを送るかＦＩＮ−ＡＣＫを再送信することによって応答することができる。アトミックエントリ２３０４がこのゾンビ状態で過ごす時間は、使用される信頼性のある通信プロトコルのプロトコル固有デッドタイムに（適度に可能なだけ近く）一致する。

照会アトム２２０４（Ｑ）関数呼出しは、第１の負荷分散ユニット１０６のＤＡＭ２２０２のローカルＤＡＭテーブル２２０６に記憶されていないセッションを参照する入力接続リクエストを第１の負荷分散ユニット１０６が受け取る時に、アトミックエントリ２３０４を獲得するのに使用される。肯定のリターンアトム２２０４（Ｒ）関数呼出しを受け取るまで、ブロードキャスト照会アトム２２０４（Ｑ）関数呼出しと同時にまたはシーケンシャルに、他のＤＡＭ部分２２０２に照会できることに留意されたい。

リターンアトム２２０４（Ｒ）関数呼出しは、第１の負荷分散ユニット１０６のＤＡＭ部分２２０２にアトミックエントリ２３０４を供給するために、第２の負荷分散ユニット１０６のＤＡＭ部分２２０２によって使用され、このアトミックエントリ２３０４は、照会アトム２２０４（Ｑ）関数呼出しのキー／セッション識別子によって指定されるキー２３０４（Ｋ）を有し、この照会アトム２２０４（Ｑ）関数呼出しは、第１の負荷分散ユニット１０６のＤＡＭ部分２２０２によって前に発行されたものである。トラフィックルーティング機能２０１２などの他のコンポーネントも、ＡＰＩまたは類似物に従って、特に照会アトム２２０４（Ｑ）関数呼出しなどの関数２２０４を呼び出せることに留意されたい。

ＤＡＭ部分２２０２およびＤＡＭテーブル２２０６は、無数の形で編成し、管理することができる。例の形は、複製／冗長性、獲得時のローカルキャッシング、位置選択のためのハッシュ化などに関する。完全な複製までの０、１、２、または３つ以上のレベルの複製を使用することができる。０レベルの複製では、各アトミックエントリ２３０４が、他のＤＡＭ部分２２０２への複製なしで、セッションアップメッセージ２００８（Ｕ）を受け取るＤＡＭ２２０２に記憶される。

複製の第１レベルに関して、各アトミックエントリ２３０４は、それに関するセッションアップメッセージ２００８（Ｕ）を受け取ったＤＡＭ２２０２に記憶され、追加アトム２２０４（Ａ）関数呼出しを使用して１つの他のＤＡＭ部分２２０２にも追加（コピー）される。これによって、負荷分散ユニット１０６に関する１レベルの障害が処理される。同様に、複製の第２レベルに関して、各アトミックエントリ２３０４は、それに関するセッションアップメッセージ２００８（Ｕ）を受け取ったＤＡＭ２２０２に記憶され、２つの他のＤＡＭ部分２２０２にも追加される。一般に、所与のＤＡＭ部分２２０２によってアトミックエントリ２３０４がコピーされる１つ、２つなどの他のＤＡＭ部分２２０２は、事前に決定されるか、ランダムに選択される。第３、第４などの複製のレベルも、使用することができる。

さらに、それに関するセッションアップメッセージ２００８（Ｕ）を受け取ったＤＡＭ２２０２に記憶される各アトミックエントリ２３０４をすべての他のＤＡＭ部分２２０２に追加させることによって、完全な複製を使用することができる。複製レベルの選択によって、複数の要因が影響を受ける。複製レベルが高くなるにつれて、可用性が高まり、待ち時間が減る。その一方で、複製レベルが高くなるにつれて、ネットワークトラフィックおよびメモリ使用量の両方が増える。

完全な複製が使用されない時に、獲得時のローカルキャッシングを行うことができる。たとえば、ＤＡＭ部分２２０２によって、ＤＡＭテーブル２２０６のそのＤＡＭの部分内で、参照されるセッション識別子を突き止められない時に、そのＤＡＭ部分２２０２は、照会アトム２２０４（Ｑ）関数呼出しを発行して、リターンアトム２２０４（Ｒ）関数呼出しを介して、参照されるセッション識別子に関連するアトミックエントリ２３０４を獲得する。使用の後に、獲得されたアトミックエントリ２３０４を廃棄するのではなく、ＤＡＭ部分２２０２は、ＤＡＭテーブル２２０６のそのＤＡＭの部分内で、獲得されたアトミックエントリ２３０４をキャッシュに格納する。このオプションによって、上記で列挙した要因の間のトレードオフが提供される。

完全な複製が使用されない時のもう１つのオプションとして、位置選択のハッシュ化を行うことができる。セッションの第１のアトミックエントリ２３０４が、セッションアップメッセージ２００８（Ｕ）を受け取るＤＡＭ部分２２０２に記憶される。複製された１つまたは複数のコピーが、追加アトム２２０４（Ａ）関数呼出しを介して、ハッシュ関数を使用して特定のＤＡＭ部分２２０２に送られる。各ＤＡＭ部分２２０２に、可能なハッシュ値の範囲全体のうちのサブセットが割り当てられる。各セッション識別子が、あるハッシュ関数を使用してハッシュ化されて、ハッシュ値に達する。このハッシュ値が、割り当てられるＤＡＭ部分２２０２にマッピングされる。最初にアトミックエントリ２３０４が追加されるＤＡＭ部分２２０２によって、そのアトミックエントリ２３０４が、割り当てられたＤＡＭ部分２２０２に複製される。

位置選択のハッシュ化に関して、所望のアトミックエントリ２３０４をそのＤＡＭテーブル２２０６にローカルにキャッシュされている少なくとも１つのＤＡＭ部分２２０２を、セッション識別子から知ることができる。したがって、照会アトム２２０４（Ｑ）関数呼出しを、既知のＤＡＭ部分２２０２に向けることができる。これによって、通常は、ネットワークトラフィックおよび／または待ち時間が減る。

この位置選択のハッシュ化は、１つ、２つ、３つ、または４つ以上のレベルの複製と共に使用することができ、ハッシュ値の各範囲が、それぞれ、１つ、２つ、３つなどの異なるＤＡＭ部分２２０２にマッピングされる。さらに、位置選択のハッシュ化を、獲得時のローカルキャッシングと共に使用することができる。

図２４は、複数の負荷分散ユニットでセッション情報を管理する例示的な方法を示すフローチャート２４００である。フローチャート２４００に、８つのブロック２４０２〜２４１６が含まれる。フローチャート２４００の動作は、他の環境でおよびさまざまなソフトウェア方式と共に使用することができるが、図１〜３、１９、２０、２２、および２３Ｂを使用して、特にこの方法のある態様および例を示す。

ブロック２４０２で、セッション参照を有する入力接続リクエストを分析する。たとえば、トラフィックルーティング機能２０１２によって、特定の種類の前にオープン／確立されたセッションを参照する入力接続リクエストを受け取ることができる。ブロック２４０４で、セッション参照を使用してローカルＤＡＭテーブルを検索する。たとえば、所与の負荷分散ユニット１０６およびトラフィックルーティング機能２０１２に関して、そのＤＡＭ部分２２０２によって、それに対応するＤＡＭテーブル２２０６を検索して、セッション参照を探すことができる。

ブロック２４０６で、セッション参照がローカルＤＡＭテーブルのキーと一致するかどうかを判定する。たとえば、ＤＡＭ部分２２０２によって、ＤＡＭテーブル２２０６の複数のエントリ２３０４のキーフィールド２３０４（Ｋ）を検索して、セッション参照がキーフィールド２３０４（Ｋ）のいずれかの値と一致するかどうかを判定することができる。そうである場合には、フローチャート２４００は、ブロック２４１２で継続される。

その一方で、セッション参照がどのキーとも一致しない場合には、フローチャート２４００は、ブロック２４０８で継続される。ブロック２４０８で、照会アトム関数呼出しを行う。たとえば、ＤＡＭ部分２２０２によって、キーとしてセッション参照／識別子を含む照会アトム２２０４（Ｑ）関数呼出しを行うことができる。照会アトム２２０４（Ｑ）関数呼出しを、少なくとも１つの他のＤＡＭ部分２２０２に送ることができる。照会アトム２２０４（Ｑ）に関する可能な宛先ＤＡＭ部分２２０２の数、選択、順序などは、ＤＡＭ２２０２によって使用されるオプションに依存するものとすることができる（たとえば、複製レベル、位置選択のハッシュ化、獲得時のローカルキャッシング、ポイントツーポイントかマルチキャストかなど）。

ブロック２４１０で、返されたアトムを受け取る。たとえば、別のＤＡＭ部分２２０２によって発行されたリターンアトム２２０４（Ｒ）関数呼出しからの情報を受け取ることができる。その別のＤＡＭ部分２２０２は、それに対応するＤＡＭテーブル２２０６内でアトミックエントリ２３０４を成功裡に突き止めており、突き止められたアトミックエントリ２３０４は、セッション参照と一致するキーを有する。リターンアトム２２０４（Ｒ）関数呼出しからの情報に、キーフィールド２３０４（Ｋ）および突き止められたアトミックエントリ２３０４のデータフィールド２３０４（Ｄ）からの値が含まれる。これらの値は、セッションのセッション識別子およびそのセッションにアフィニティ化（ａｆｆｉｎｉｔｉｚｅ）されたホスト１０８のネットワークアドレスに対応する。

ブロック２４１２で、アトミックエントリを抽出する。アトミックエントリは、（ブロック２４０４および２４０６で）一致がローカルに見つかった場合にはローカルＤＡＭテーブルから、（ブロック２４０８および２４１０で）一致が他所で見つかった場合には返されたアトムから、抽出される。たとえば、アトミックエントリ２３０４は、ＤＡＭ部分２２０２のＤＡＭテーブル２２０６から、またはリターンアトム２２０４（Ｒ）関数呼出しによって受け取られる情報から抽出することができる。抽出されたアトミックエントリ２３０４は、リターンアトム２２０４（Ｒ）関数呼出しの結果として受け取られた場合に、ローカルＤＡＭテーブル２２０６でキャッシュすることができる。

ブロック２４１４で、参照されるセッションとのセッションアフィニティを有するホストが、アトミックエントリから確かめられる。たとえば、抽出されたアトミックエントリ２３０４のデータフィールド２３０４（Ｄ）の値を確かめ、これによって、アフィニティ化されたホスト１０８のネットワークアドレスを確かめることができる。ブロック２４１６で、入力接続リクエストを、確かめられたホストにルーティングする。たとえば、トラフィックルーティング機能２０１２および／または転送機能によって、セッション参照を有する入力接続リクエストを、確かめられたアフィニティ化されたホスト１０８にルーティングすることができる。例示的な分類機能、リクエストルーティング機能、および転送機能を、次の節で説明する。

（分類、転送、およびリクエストルーティングの例）
この節では、トラフィックルーティング機能の高可用性に関するものを含めて、ネットワーク負荷分散についてトラフィックルーティングをどのように実施できるかを説明する。トラフィックルーティング機能には、特に転送機能に関して、分類機能および／またはリクエストルーティング機能を含めることができる。この節では、主に図２５〜３１を参照する。この節では、リクエストルータ３０６（図３）の機能、トラフィックをルーティングする時のセッションのトラッキングとヘルスおよび負荷情報の使用の間の相互関係、セッション情報ならびに／またはヘルスおよび負荷情報を用いるトラフィックルーティング相互作用に関する動作実施形態、ネットワーク負荷分散インフラストラクチャの高可用性のためのフェールオーバープロシージャ（分類コンポーネント、転送コンポーネント、および／またはリクエストルーティングコンポーネントの障害の処理を含む）、追加のネットワーク負荷分散インフラストラクチャ構成などを明らかにする。

図２５に、リクエストルータ３０６（Ｈ／Ｓ）によって実現されるリクエストルーティング機能を有する例示的なネットワーク負荷分散インフラストラクチャを示す。トラフィックルーティング機能２０１２に関して上記で注記したように、トラフィックルーティングは、分類（たとえば転送を伴う）および／またはリクエストルーティングに関連する可能性がある。パケットレベルの分類を、転送と共に、特に図４を参照して上記で説明した。リクエストルーティングを、特に図２５に関してここで説明する。

リクエストレベルルーティングは、パケットレベルルーティングより上位のレベルで行われる。一般に、リクエストルータ３０６は、ホスト１０８で動作するアプリケーション３１６のプロキシとして働く。リクエストルータ３０６によって、ＴＣＰ接続が終端され、クライアント１０２からの各リクエストが（おそらくは部分的に）解析され、各リクエストがホスト１０８に再提出される。リクエストルータ３０６は、ＳＳＬ暗号化解除など、接続に対する前処理を実行することができる。また、リクエストルータ３０６は、ある種のリクエストを吸収することを選択でき（たとえば、リクエストルータが、応答のキャッシュを維持することができる）、リクエストをホスト１０８に転送する前に、「任意に」リクエストを修正することができる。

リクエストルータ３０６は、通常は、アプリケーション固有であり、行えることに関して無制限とすることができる。例として、リクエストルータ３０６の単一のクラスすなわちＨＴＴＰ／ＳＳＬリクエストルータ３０６（Ｈ／Ｓ）は、以下の説明で対処する。図からわかるように、ネットワークアドレスＣ１を有するクライアント１０２が、ネットワーク１０４を介して、それぞれネットワークアドレスＨ１およびＨ２を有するホスト１０８（１）および１０８（２）と通信している。この通信は、ＨＴＴＰ／ＳＳＬリクエストルータ３０６（Ｈ／Ｓ）を含む負荷分散インフラストラクチャを介して実現される。

ＨＴＴＰ／ＳＳＬリクエストルータ３０６（Ｈ／Ｓ）によって、ＨＴＴＰおよびＳＳＬトラフィックが終端され、ＳＳＬトラフィックが暗号化解除され、クライアント１０２からの各ＨＴＴＰリクエストが検査され、各リクエストを分類し、アプリケーションエンドポイントのヘルスおよび負荷情報を考慮しながらそのリクエストに「最適の」エンドポイントを判定するためにアプリケーション固有ルールが適用され、リクエストがエンドポイントに提出される。エンドポイントへのリクエスト提出では、クライアント１０２から発したものと別々のＴＣＰ接続が使用される（後者の接続は、ＨＴＴＰ／ＳＳＬリクエストルータ３０６（Ｈ／Ｓ）で終端される）。これらの動作は、クラシファイヤ３０４によって実行される動作と論理的に同等とみなすことができるが、ＨＴＴＰ／ＳＳＬリクエストルータ３０６（Ｈ／Ｓ）でのこれらの動作が、ＴＣＰ接続内のリクエストごとに論理リクエストレベルで行われるという点で差が生じる。ＨＴＴＰ／ＳＳＬリクエストルータ３０６（Ｈ／Ｓ）およびリクエストルータ３０６全般は、同一の（ｉ）アプリケーションヘルスおよび負荷ならびに（ｉｉ）クラシファイヤ３０４によって使用されるセッショントラッキングインフラストラクチャを使用することができる。

ＨＴＴＰ／ＳＳＬリクエストルータ３０６（Ｈ／Ｓ）は、クライアント１０２と２つのホスト１０８（１）および１０８（２）の間の仲介物として働く。ＨＴＴＰ／ＳＳＬリクエストルータ３０６（Ｈ／Ｓ）は、単一のＴＣＰ接続を介するクライアント１０２からの２つのリクエストを処理している。説明される実施形態では、結果のリクエストルーティングに、複数の動作が用いられる。第１に、クライアント１０２によって、ＨＴＴＰ／ＳＳＬリクエストルータ３０６（Ｈ／Ｓ）へのｈｔｔｐまたはｈｔｔｐｓ接続［１］が確立され、リクエスト＃１ ２５０２（１）が送信される。

第２に、（トラフィックがＳＳＬ暗号化される場合に）ＨＴＴＰ／ＳＳＬリクエストルータ３０６（Ｈ／Ｓ）によって、ＳＳＬセッションが終端され、リクエスト＃１ ２５０２（１）が解析され、リクエスト＃１ ２５０２（１）の内容が検査される。アプリケーションヘルスおよび負荷ならびにセッション情報を考慮に入れて、ＨＴＴＰ／ＳＳＬリクエストルータ３０６（Ｈ／Ｓ）によって、ホスト１０８（１）がこの例でこの特定のリクエスト＃１ ２５０２（１）に「最良」のホストであると判定される。

第３に、ＨＴＴＰ／ＳＳＬリクエストルータ３０６（Ｈ／Ｓ）によって、ホスト１０８（１）への第２のＴＣＰ接続［２］が確立される。その代わりに、ホスト１０８（１）への既存の接続［２］を使用することができる。ＨＴＴＰ／ＳＳＬ要求ルータ３０６（Ｈ／Ｓ）によって、たとえばリクエスト＃１ ２５０２（１）の暗号化解除されたバージョンが、ホスト１０８（１）に送られる。第４に、ホスト１０８（１）が、応答＃１ ２５０４（１）によって応答する。第５に、ＨＴＴＰ／ＳＳＬリクエストルータ３０６（Ｈ／Ｓ）によって、この応答＃１ ２５０４（１）が暗号化され、ＴＣＰ接続［１］でクライアント１０２に送り返される。

第６に、クライアント１０２によって、もう１つのリクエスト、リクエスト＃２ ２５０２（２）が送信される。リクエスト＃２ ２５０２（２）は、リクエスト＃１ ２５０２（１）の処理に似た形で処理されるが、ＨＴＴＰ／ＳＳＬリクエストルータ３０６（Ｈ／Ｓ）がホスト１０８（２）を選択する点で異なる。この異なる選択は、ホスト１０８（１）が、障害を発生したか又はより負荷が重いので、リクエスト＃２ ２５０２（２）がリクエスト＃１ ２５０２（１）と異なるＵＲＬに向けられるので、などの理由によるものである。それにもかかわらず、ＨＴＴＰ／ＳＳＬリクエストルータ３０６（Ｈ／Ｓ）によって、別の副ＴＣＰ接続が確立されるが、この副ＴＣＰ接続［３］は、ホスト１０８（２）に対するものである。暗号化解除されたリクエスト＃２ ２５０２（２）が、ホスト１０８（２）にルーティングされ、応答＃２ ２５０４（２）が、そこから結果として受け取られる。応答＃２ ２５０４（２）の暗号化されたバージョンが、ＨＴＴＰ／ＳＳＬリクエストルータ３０６（Ｈ／Ｓ）からクライアント１０２に送られる。

第７に、クライアント１０２によって、ＨＴＴＰ／ＳＳＬリクエストルータ３０６（Ｈ／Ｓ）とのＴＣＰ接続［１］がクローズされる。ＨＴＴＰ／ＳＳＬリクエストルータ３０６（Ｈ／Ｓ）は、（将来のある時に）それぞれホスト１０８（１）および１０８（２）に対して行った接続［２］および［３］をクライアント１０２の代わりにクローズする。ＴＣＰ接続［２］は、その代わりに、ＨＴＴＰ／ＳＳＬリクエストルータ３０６（Ｈ／Ｓ）がリクエスト＃２ ２５０２（２）のＴＣＰ接続［３］をオープン／使用すると決定した後にクローズすることができる。

ＨＴＴＰ／ＳＳＬリクエストルータ３０６（Ｈ／Ｓ）によって、ｈｔｔｐ／ｈｔｔｐｓ接続が終端されるので、ＨＴＴＰ／ＳＳＬリクエストルータ３０６（Ｈ／Ｓ）は、リクエストのルーティング以上のことを行うことができる。たとえば、ＨＴＴＰ／ＳＳＬリクエストルータ３０６（Ｈ／Ｓ）によって、潜在的に、応答のそれ自体のキャッシュを維持することができる（たとえば、キャッシュの無効化に帯域外機構を用いる）。上の例で注記したように、ＨＴＴＰ／ＳＳＬリクエストルータ３０６（Ｈ／Ｓ）によって、潜在的に、異なる種類のリクエストを、たとえばリクエストされたＵＲＬに基づいて、ホスト１０８の異なる組にルーティングすることができる。逆に、ＨＴＴＰ／ＳＳＬリクエストルータ３０６（Ｈ／Ｓ）によって、潜在的に、多数の長続きしないクライアント接続からのリクエストを集約し、これらを少数の長続きするＴＣＰ接続を介してホスト１０８に送ることができる。そのような接続集約によって、ホスト１０８でのＴＣＰ接続処理オーバーヘッドを減らすことができる。

他のクラスのリクエストルータを、ＨＴＴＰ以外の他の例示的なプロトコルに対応するものとすることができる。たとえば、リクエストルータを、ＳＯＡＰリクエストルータとすることができる。ＳＯＡＰリクエストルータは、ＨＴＴＰ／ＳＳＬリクエストルータ３０６（Ｈ／Ｓ）に類似する形で機能する。しかし、ＳＯＡＰリクエストルータは、ＳＯＡＰトラフィックのルーティングを専門とする。ＳＯＡＰリクエストルータによって、ＳＯＡＰヘッダが理解され、ＳＯＡＰヘッダならびにアプリケーションヘルスおよび負荷に基づいて、ルーティング決定が行われる。

パケットレベルの分類および転送（またはパケットレベルのルーティング）とリクエストレベルのルーティングの両方によって、ある形のレイヤ７負荷分散を提供することができる。レイヤ７負荷分散は、以下で、「任意のトンネリングおよび／またはアプリケーションレベルロードバランシングを伴う接続移行の例」という題名の節でさらに説明する。パケットレベルルーティングによって、クライアントのＴＣＰ接続データの最初の部分への読取専用アクセスがもたらされ、リクエストレベルルーティングによって、データストリーム全体への読み取りアクセスおよび修正アクセスがもたらされる。

パケットレベルルーティングは、通常は、リクエストレベルルーティングに対する複数の長所を有する。この長所には、透過性（クライアントパケットは、そのままでホストに配信され、発信元および宛先のＩＰアドレスおよびポート番号が保存される）、低い処理オーバーヘッド（一般に、トラフィックの転送にはルートルックアップが伴う）、短い待ち時間（個々のパケットが転送され、ＴＣＰ接続宛先が判定されたならばパケットはキューイングされなくなる）、および高可用性（一般に、フォワーダの障害ではＴＣＰ接続は終了されない）が含まれる。その一方で、リクエストレベルルーティングは、通常は、パケットレベルルーティングに対する下記の長所を有する：クライアントとの間を流れるデータストリーム全体を検査する能力、およびデータストリームを変換し、複数のホストの間でデータストリームを分割するか、複数のクライアントからのデータストリームを集約する能力。

図２６は、（ｉ）セッション情報ならびに（ｉｉ）ヘルスおよび負荷情報に関して入力パケットをルーティングする例示的な方法を示すフローチャート２６００である。フローチャート２６００に、８つのブロック２６０２〜２６１６が含まれる。フローチャート２６００の動作は、他の環境でおよびさまざまなソフトウェア方式と共に使用することができるが、図１〜３、１２、１８〜２２、および２３Ｂを使用して、特にこの方法のある態様および例を示す。

ブロック２６０２で、入力パケットを受け取る。たとえば、クライアント１０２からのパケットを、負荷分散ユニット１０６のフォワーダ３０２で受け取ることができる。ブロック２６０４で、受け取ったパケットが先在するセッションに関するものであるかどうかを判定する。たとえば、フォワーダ３０２によって、ローカルＤＡＭテーブル２２０６（）を調べて、受け取ったパケットが既にＴＣＰ／ＩＰセッションの一部であると判定することができる。

さらに、フォワーダ３０２によって、ローカルＤＡＭテーブル２２０６（）を調べ、受け取ったパケットがまだＴＣＰ／ＩＰセッションの一部でないと判定することができる。この場合には、フォワーダ３０２によって、受け取られたパケットがクラシファイヤ３０４に供給され、クラシファイヤ３０４によって、受け取られたパケットがセッション参照を有する場合に、そのパケットに関する上位のセッションアフィニティを調べる。これらの動作の例は、上記で、特に図２４を参照して説明したが、以下で、特に図２７および２８を参照して説明する。

受け取られたパケットが、先在するセッションに関する（ブロック２６０４での判定で）場合に、フローはブロック２６０６で継続される。ブロック２６０６で、先在するセッションにアフィニティ化されたホストを確かめる。たとえば、アフィニティ化されたホスト１０８を、ローカルＤＡＭテーブル２２０６（）および／または全体的な分散ＤＡＭ２２０６から、フォワーダ３０２またはクラシファイヤ３０４によって確かめることができる。

ブロック２６０８で、アフィニティ化されたホストが健全であるかどうかを判定する。たとえば、クラシファイヤ３０４によって、統合ヘルスおよび負荷キャッシュ１２０８を調べて、特にＴＣＰ／ＩＰセッションより上位の論理レベルのセッションの一部である受け取られたパケットについて、アフィニティ化されたホスト１０８が健全であるかどうかを判定することができる。このブロックの動作は、ヘルスおよび負荷ハンドラ３１４と共に達成することができる。

アフィニティ化されたホストが健全である（ブロック２６０８の判定で）場合に、フローは、ブロック２６１０で継続される。ブロック２６１０で、受け取られたパケットをアフィニティ化されたホストにルーティングする。たとえば、フォワーダ３０２（ＴＣＰ／ＩＰセッションに関する）またはクラシファイヤ３０４（上位レベルセッションに関する）によって、アフィニティ化されたホスト１０８にパケットをルーティングすることができる。代替実施形態では、クラシファイヤ３０４によって、上位レベルセッションの一部である受け取られたパケットについても、アフィニティ化されたホスト１０８へのルーティングのために、受け取られたパケットをフォワーダ３０２に返すことができる。

その一方で、（ブロック２６０８の判定で）アフィニティ化されたホストが健全でない場合に、フローは、ブロック２６１２で継続される。また、その一方で、（ブロック２６０４の判定で）受け取られたパケットが先在するセッションに関するものでない場合に、フローはブロック２６１２で継続される。ブロック２６１２で、ヘルスおよび負荷情報に応答してホストを選択する。たとえば、クラシファイヤ３０４によって、ヘルスおよび負荷ハンドラ３１４から獲得されるヘルスおよび負荷関連アプリケーション割当（たとえば、ターゲットアプリケーションエンドポイント割当応答１８０４から）からおよび／またはそれを使用して、ホスト１０８を選択することができる。この動作の例は、上記で特に図１９および１８を参照して説明したが、以下で、特に図３０を参照してさらに説明する。

ブロック２６１４で、受け取られたパケットを選択されたホストにルーティングする。たとえば、クラシファイヤ３０４によって、選択されたホスト１０８にパケットをルーティングする（任意選択としてフォワーダ３０２を介して）ことができる。ブロック２６１６で、選択されたホストへの接続パスのルートをプラムする。たとえば、クラシファイヤ３０４によって、特に受け取られたパケットをクラシファイヤ３０４に供給したフォワーダ３０２にローカルなＤＡＭテーブル２２０６（）で、ＤＡＭテーブル２２０６にセッション情報エントリを追加することができる。このセッション情報エントリは、ＤＡＭ２２０２について設けられた（たとえばセッショントラッカ３０８の）冗長性ポリシに従って複製することができる。

ブロック２６１４の動作およびブロック２６１６の動作は、特に図示された順序で、ブロック２６１６をブロック２６１４の前に実行して、任意の順序で部分的にまたは完全にオーバーラップして、などで実行することができる。クラシファイヤ３０４によって、上記で説明したように実行される動作を、その代わりにリクエストルータ３０６（または、より一般的にトラフィックルーティング機能２０１２）によって実行できることに留意されたい。

図２７に、障害がないときの例示的なトラフィックルーティングフローを示す。図からわかるように、１つまたは複数の負荷分散対応スイッチ２０２（ＬＢＡ）が、残りの負荷分散インフラストラクチャ１０６（別々には図示せず）に面する。転送および分類機能が、３つの装置またはノードにまたがって分配される。第１の装置に、フォワーダ３０２（１）およびクラシファイヤ３０４（１）が含まれる。第２の装置に、クラシファイヤ３０４（２）が含まれる。第３の装置に、フォワーダ３０２（２）が含まれる。

クラシファイヤ３０４（２）が第２装置で実行され、フォワーダ３０２（２）が第３装置で実行される状態で、各装置を、特にそれぞれの機能に合わせて調整することができる。たとえば、第２装置および第３装置のハードウェア、ソフトウェア、ファームウェア、これらの組合せなどを、過度な供給なしで所望の機能をサポートするように適合させることができる。したがって、フォワーダ３０２（２）を含む第３装置を、ハードウェア機能の観点からスイッチおよび／またはルータに似たものにすることができ、クラシファイヤ３０４（２）を含む第２装置を、ハードウェア機能の観点からサーバおよび／またはパーソナルコンピュータに似たものにすることができる。

４つのコンポーネントにまたがる機能を提供する３つの装置として図示されているが、転送および分類機能の代替の論理構成および／または装置レベル構成を、図２７についてここで説明する例示的なトラフィックルーティングフローに適用可能である。また、ルーティング宛先が、ホスト１０８として図示されているが、ルーティング実施形態の本明細書での説明を、その代わりに、より一般的に、必ずしもパケットを消費する最後のノードではなく、パケットの次のノード宛先に適用することができる。

セッショントラッカ３０８のＤＡＭ２２０２実現を使用して、ＤＡＭテーブル２２０６を実施する。しかし、セッションアフィニティプリザーバ１９０４全般も、図２７の例示的トラフィックルーティングフローに適用可能である。フォワーダ３０２（１）に、ＤＡＭテーブル部分２２０６（１）が含まれ、フォワーダ３０２（２）に、ＤＡＭテーブル部分２２０６（２）が含まれる。入力パケットは、ホスト１０８（１）またはホスト１０８（２）にルーティングされる。

説明される実施形態では、ＤＡＭ２２０２が、セッション情報を有する、「アトム」２３０４の分散式のインメモリテーブルである（たとえば、任意選択のメタデータを伴うキーワード／値ペア）。ＤＡＭ２２０２およびＤＡＭテーブル２２０６は、上記で特に図２２〜２４を参照して説明した。クラシファイヤ３０４のクラスタ内のどのノードでも、アトム２３０４の追加、照会、および削除を行うことができる。ＤＡＭ２２０２によって、アクティブ（たとえばＴＣＰ／ＩＰレベル）ルータならびに高水準セッション情報を含む高可用性のＤＡＭテーブル２２０６が維持される。

（１）で、負荷分散対応スイッチ２０２（ＬＢＡ）によって、入力パケットがフォワーダ３０２（１）に向けられる。（２）で、フォワーダ３０２（１）によって、その内部ルーティングテーブルであるＤＡＭテーブル２２０６（１）が調べられる。フォワーダ３０２（１）は、このパケットのアトミックエントリ２３０４を見つけられない場合に、そのパケットを、それに割り当てられたおよび／または関連するクラシファイヤであるクラシファイヤ３０４（１）に転送する。

（３）で、クラシファイヤ３０４（１）によって、この例のパケットがＴＣＰ−ＳＹＮパケットであることが認識される。したがって、クラシファイヤ３０４（１）によって、このパケットが、クライアント１０２からの新しいＴＣＰ接続の始めとして扱われる。ヘルスおよび負荷ハンドラ３１４（特に図示せず）からのヘルスおよび負荷情報を使用して、クラシファイヤ３０４（１）によって、ホスト１０８（１）がこのＴＣＰ接続を受け取らなければならないと判定される。クラシファイヤ３０４（１）によって、フォワーダ３０２（１）のローカルルーティングテーブルとして働くＤＡＭテーブル２２０６（１）が更新され、ＤＡＭ２２０６全体へのルートを表すアトミックエントリ２３０４も挿入される。これらは、別々の動作、ＤＡＭテーブル２２０６のＴＣＰ／ＩＰレベルセッションがフォワーダ３０２に位置する単一の動作などとすることができる。ＤＡＭ２２０２によって、その内部で、このルートが、規定された冗長性ポリシに従って、クラシファイヤ３０４のクラスタの１つまたは複数の他のメンバに複製される。

（４）で、フォワーダ３０２（１）によって、この接続の後続パケットが、クラシファイヤ３０４（１）との相互作用なしに、ホスト１０８（１）に直接に転送される。ＤＡＭ２２０２を使用して、フォワーダ３０２、クラシファイヤ３０４、またはフォワーダ／クラシファイヤ対３０２／３０４の障害を、少なくとも部分的にマスクすることができる。ＤＡＭ２２０２を使用して、負荷分散対応スイッチ２０２（ＬＢＡ）が確立された接続のパケットを不注意に異なるフォワーダ３０２に送り始める場合のクライアント接続性を防ぐこともできる。

図２８に、障害があるときの例示的なトラフィックルーティングフローを示す。図２７の「無障害」（ｆａｉｌｕｒｅ−ｆｒｅｅ）の例示的なトラフィックルーティングフローと異なって、障害が、図２８のネットワーク負荷分散インフラストラクチャ１０６（特に図示せず）の一部で発生している。具体的に言うと、フォワーダ３０２（１）およびクラシファイヤ３０４（１）が常駐し動作している第１装置が、図２７に示された接続が確立された後に障害を発生する。この障害は、少なくとも部分的に、ＤＡＭ２２０２によってマスクされる。

（１）で、負荷分散対応スイッチ２０２（ＬＢＡ）によってフォワーダ３０２（１）の障害が検出され、クラスタ内の他のフォワーダ３０２への、その接続のパケットの転送が開始される。この例では、他のフォワーダ３０２が、フォワーダ３０２（２）である。図２８に、障害状況が示されているが、負荷分散対応スイッチ２０２（ＬＢＡ）は、フォワーダ３０２（１）がまだ使用可能である場合であっても、このトラフィックをフォワーダ３０２（２）に送ることもできる。この非障害誘導のフォワーダ３０２の変更は、たとえば、負荷分散対応スイッチ２０２（ＬＢＡ）がフォワーダ３０２（１）へのこのトラフィックのアフィニティを「忘れた」という理由で発生する可能性がある。表記（２）〜（５）の動作は、障害状況および「忘れられたアフィニティ」状況の両方に適用される。

（２）で、フォワーダ３０２（２）によって、そのルーティングテーブルであるＤＡＭテーブル２２０６（２）が調べられる。このパケットに関するルートが見つからない時には、フォワーダ３０２（２）によって、そのパケットがクラシファイヤ３０４（２）に転送される。（３）で、クラシファイヤ３０４（２）によって、このパケットが「ミッドコネクション（ｍｉｄ−ｃｏｎｎｅｃｔｉｏｎ）」パケットであることが認識され、クラシファイヤ３０４（２）によって、このパケットのルートに関してＤＡＭ２２０２が照会される。ＤＡＭ２２０２は、これに関連するアトミックエントリ２３０４からの接続のルートを応答する。

（４）で、クラシファイヤ３０４（２）によって、フォワーダ３０２（２）内のルートがプラムされる。ルートをプラムする例示的なプロトコルを、以下でさらに説明する。（５）で、フォワーダ３０２（２）に向けられたこの接続の後続パケットが、クラシファイヤ３０４（２）に相談せずに、正しいホスト、この例ではホスト１０８（１）に直接にルーティングされる。

一般に、クラシファイヤ３０４とフォワーダ３０２の間の通信のルートプラムプロトコルに、ルートを追加する命令とルートを除去する命令が含まれる。具体的に言うと、ルート追加命令は、フォワーダ３０２から所与の接続の宛先ホスト１０８へのルートをプラムするために、クラシファイヤ３０４からフォワーダ３０２に送られる。たとえば、ルート追加命令を、図２８の（４）に示されているように、フォワーダ３０２（２）からクラシファイヤ３０４（２）に供給することができる。ルート（たとえば、キーおよび対応する値）は、将来のフォワーダ３０２（２）によるすばやいアクセスのために、ローカルＤＡＭテーブル２２０６（２）に追加される。この例では、クラシファイヤ３０４（２）が、フォワーダ３０２（２）と別々の装置であり、したがって、ルートプラムプロトコルを、装置間プロトコルとすることができる。しかし、ルートプラムプロトコルを、装置内通信にも使用することができる。

説明される実施形態では、クラシファイヤ３０４（２）に、接続インベントリ２８０２が含まれる。接続インベントリ２８０２を用いて、クラシファイヤ３０４（２）によって、クラシファイヤ３０４（２）がそれのためにルートをプラムするフォワーダ３０２（フォワーダ３０２（２）など）の接続が記憶される。クラシファイヤ３０４（２）が、接続の中止も含めて接続を記憶できるようにするために、フォワーダ３０２（２）によって、接続の最後のパケット（ＴＣＰ ＦＩＮパケットなど）がクラシファイヤ３０４（２）に転送される。クラシファイヤ３０４（２）によって、接続に対応する接続インベントリ２８０２のエントリが削除され、ルート削除命令がフォワーダ３０２（２）に送られる。ルート削除命令を受け取る時に、フォワーダ３０２（２）によって、ＤＡＭテーブル２２０６（２）内の対応するルートが除去される。この形で、セッショントラッキング機能と共に、分類機能によって、転送機能によって使用されるルートテーブルおよびそのルートを制御することができる。その結果、異なるデバイスに分離された転送機能を、高速だが比較的単純なハードウェアを使用して実現することができる。

図２９に、ネットワーク負荷分散インフラストラクチャ１０６の高可用性に関する追加の例示的なフェールオーバープロシージャを示す。２つの異なる障害、障害２９０２および障害２９０６のフェールオーバープロシージャを説明する。図からわかるように、ネットワーク負荷分散インフラストラクチャ１０６（特に図示せず）に、５つのコンポーネントすなわち、フォワーダ３０２（１）、フォワーダ３０２（２）、フォワーダ３０２（３）、クラシファイヤ３０４（１）、およびクラシファイヤ３０４（２）が含まれる。

説明される実施形態では、この５つのコンポーネント３０２（１）、３０２（２）、３０２（３）、３０４（１）、および３０４（２）のそれぞれが、個々の装置に対応する。しかし、類似するフェールオーバープロシージャが、異なる負荷分散コンポーネントが装置を共有する環境に適用される。

［１］で当初、ルータ／スイッチ２０２によって、新しい接続に関して起こった入力パケットが、フォワーダ３０２（１）に向けられる。フォワーダ３０２（１）は、そのローカルルーティングテーブルにこの接続のルートを有しないので、（１）の破線の両方向の矢印によって示されるように、クラシファイヤ３０４（１）にパケットを送る。クラシファイヤ３０４（１）によって、まず、考えられる上位レベルセッションアフィニティについてのセッショントラッキング３０８を参照してセッション情報が検査される。この例では、このパケットは、既存セッションにアフィニティ化されておらず、したがって、クラシファイヤ３０４（１）によって、ヘルスおよび負荷ハンドラ３１４に関するヘルスおよび負荷情報に関する宛先ホスト１０８が選択される。

具体的に言うと、クラシファイヤ３０４（１）によって、この例ではホスト１０８（１）が選択される。このパケットがＴＣＰ／ＩＰ接続に関するものであると仮定すると、ホスト１０８（１）にリンクされたこのＴＣＰ／ＩＰセッションが、クラシファイヤ３０４（１）によって、追加アトム２２０４（Ａ）関数呼出しを使用してＤＡＭ２２０２に追加される。最初のパケットが、クラシファイヤ３０４（１）またはフォワーダ３０２（１）によってホスト１０８（１）に転送される。クラシファイヤ３０４（１）によって、フォワーダ３０２（１）のローカルルーティングテーブル内でルートがプラムされる。後続パケットは、クラシファイヤ３０４（１）とのさらなる相互作用なしで、フォワーダ３０２（１）によってホスト１０８（１）に転送される。

接続［１］中のある時に、フォワーダ３０２（１）で障害２９０２が発生する。負荷分散対応ルータ／スイッチ２０２（ＬＢＡ）によって、この障害２９０２が検出される。その結果、点２９０４で、ルータ／スイッチ２０２によって、接続［１］に沿ってフォワーダ３０２（１）に送られるはずの後のパケットが、別のフォワーダ３０２に向けられ、このフォワーダは、この例ではフォワーダ３０２（２）である。

したがって、フォワーダ３０２（２）によって、将来のパケットが接続［２］に沿って受け取られる。フォワーダ３０２（２）は、前にフォワーダ３０２（１）に向けられたパケットのエントリをローカルルーティングテーブルに有しないので、フォワーダ３０２（２）によって、接続［２］の最初に受け取られるパケットが、それが割り当てられかつ／または関連するクラシファイヤに送られる。この例では、フォワーダ３０２（２）が、（２）の破線の両方向の矢印によって示されるように、クラシファイヤ３０４（２）に割り当てられる。

クラシファイヤ３０４（２）によって、照会アトム２２０４（Ｑ）関数呼出しが使用されて、既存ＴＣＰ／ＩＰ接続に関連するＤＡＭ２２０２からアトミックエントリ２３０４（明示的には図示せず）が獲得される。このアトミックエントリ２３０４が、セッショントラッキング３０８のＤＡＭ２２０２を介して、リターンアトム２２０４（Ｒ）関数呼出しを介して供給される。クラシファイヤ３０４（２）によって、返されたアトミックエントリ２３０４から、このＴＣＰ／ＩＰ接続にアフィニティ化されたホスト１０８（１）が抽出される。クラシファイヤ３０４（２）によって、接続［２］の最初に受け取られたパケットが、ホスト１０８（１）に転送され、フォワーダ３０２（２）のローカルルーティングテーブル内のルートもプラムされる。後続のパケットは、クラシファイヤ３０４（２）とのさらなる相互作用なしで、フォワーダ３０２（２）によってホスト１０８（１）に転送される。

上の説明では、主に、個々のフォワーダ３０２コンポーネントの障害に焦点を合わせた。しかし、クラシファイヤ３０４コンポーネントも障害を発生する可能性がある。たとえば、ある点で、クラシファイヤ３０４（２）で障害２９０６が生じる。フォワーダ３０２（２）は、分類サービスを消費しようとする時に、またはハートビート種類のインジケータなどのアライブネス表示の欠如に気付くことを介して、障害２９０６を検出する。障害２９０６を処理するために、フォワーダ３０２（２）は、異なるクラシファイヤ３０４、この例ではクラシファイヤ３０４（１）に再割り当てまたは再関連付けされる。将来の分類機能は、（３）の破線の両方向の矢印によって示されるように、クラシファイヤ３０４（１）によってフォワーダ３０２（２）に提供される。

図３０に、ヘルスおよび負荷情報とのトラフィックルーティング相互作用の例示的な動作実施形態を示す。フォワーダ３０２およびクラシファイヤ３０４は、ホスト１０８（１）、１０８（２）．．．１０８（ｎ）にパケットをルーティングするために、ヘルスおよび負荷ハンドラ３１４と相互作用する。フォワーダ３０２およびクラシファイヤ３０４が図示されているが、例示的な動作実施形態は、リクエストルータ３０６（または、一般にトラフィックルーティング機能２０１２）にも適用可能である。

図からわかるように、ホスト１０８（１）に、それぞれアプリケーション＃１、アプリケーション＃１、およびアプリケーション＃２のアプリケーションエンドポイントＩＰ１、ＩＰ３、およびＩＰ４が含まれる。ホスト１０８（２）に、それぞれアプリケーション＃１およびアプリケーション＃２のアプリケーションエンドポイントＩＰ２およびＩＰ６が含まれる。ホスト１０８（ｎ）に、アプリケーション＃２のアプリケーションエンドポイントＩＰ５が含まれる。これらのホスト１０８（１）、１０８（２）．．．１０８（ｎ）ならびにアプリケーション、エンドポイントＩＰ１、ＩＰ２、ＩＰ３、ＩＰ４、ＩＰ５、およびＩＰ６は、ヘルスおよび負荷ハンドラ３１４によって監視される（たとえば、ヘルスおよび負荷インフラストラクチャ１２０２、統合ヘルスおよび負荷キャッシュ１２０８などを使用して）。

説明される実施形態では、（１）で、クラシファイヤ３０４によって、トークン割当方式１８０６を使用する環境で、１つまたは複数のアプリケーションエンドポイント割当がリクエストされる（たとえば、少なくとも１つのターゲットアプリケーションエンドポイント割当リクエスト１８０２を介して）。この例では、ヘルスおよび負荷ハンドラ３１４が、トークン割当３００２を供給することによって応答する（たとえば、少なくとも１つのターゲットアプリケーションエンドポイント割当応答１８０４を介して）。

具体的に言うと、アプリケーション＃１のトークン割当３００２（１）およびアプリケーション＃２のトークン割当３００２（２）が、クラシファイヤ３０４から使用可能である。アプリケーション＃１のトークン割当３００２（１）によって、当初、ＩＰ１に４０トークン、ＩＰ２に３５トークン、およびＩＰ３に２５トークンが与えられる。アプリケーション＃２のトークン割当３００２（２）によって、ＩＰ４に１０トークン、ＩＰ５に７２トークン、およびＩＰ６に１８トークンが与えられる。クラシファイヤ３０４によってアプリケーションエンドポイントへのルーティングが割り当てられる新しい接続ごとに１つのトークンが、クラシファイヤ３０４によって消費される。

（２）で、フォワーダ３０２によって、新しい接続の最初の入力パケットが受け取られる。この新しい接続のルーティングは、フォワーダ３０２のローカルＤＡＭテーブル部分２２０６に存在しないので、フォワーダ３０２によって、この最初のパケットが（３）でクラシファイヤ３０４に転送される。

（４）で、クラシファイヤ３０４によって（たとえば、最初のパケットに上位レベルセッションに関するセッション参照が含まれないと判定した後に）、ヘルスおよび負荷情報に応答してアプリケーションエンドポイント（したがって、ホスト１０８）が選択される。具体的に言うと、アプリケーション＃１によってサービスされる新しい接続について、クラシファイヤ３０４によって、それぞれのエンドポイントのトークンがまだ存在する場合に、ＩＰ１、ＩＰ２、およびＩＰ３のどれをも選択することができる。

クラシファイヤ３０４によって、多数の可能な形のいずれかでトークンを消費することができる。たとえば、クラシファイヤ３０４によって、エンドポイントごとのトークンの数にかかわりなく、ラウンドロビン手法を使用することができる。その代わりに、クラシファイヤ３０４によって、単純にＩＰ１から開始し、線形手法で次のエンドポイントに移動する前に各エンドポイントの全トークンを消費しながら、ＩＰ３まで進むことができる。また、クラシファイヤ３０４によって、現在、ある瞬間に最も多数のトークンを有する、エンドポイントによって定義されるトークンの組からのトークンを消費することができる。後者の手法を使用する場合に、クラシファイヤ３０４によって、ＩＰ１が選択される。他の手法も使用することができる。

図からわかるように、クラシファイヤ３０４によって、アプリケーションエンドポイントＩＰ２のトークンが消費される。その結果、ＩＰ２のトークンセットは、トークンが消費されるので３５トークンから３４トークンに減る。また、新しい接続の最初のパケットが、アプリケーションエンドポイントＩＰ２にルーティングされる。

（５Ａ）で、最初のパケットが、クラシファイヤ３０４からホスト１０８（２）のアプリケーションエンドポイントＩＰ２に転送される。この転送の前、転送中、またはその後に、クラシファイヤ３０４によって、（５Ｂ）で、ローカルＤＡＭテーブル部分２２０６内でこの接続のルートがプラムされる。クラシファイヤ３０４によって、このセッションのアトミックエントリ２３０４を、分配および複製のためにＤＡＭテーブル２２０６に追加することもできる。（６）で、この接続／セッションの将来のパケットが、図３０のローカルＤＡＭテーブル部分２２０６によって実現されるフォワーダ３０２のローカルルーティングテーブルを使用して、フォワーダ３０２からホスト１０８（２）のアプリケーションエンドポイントＩＰ２に転送される。

図３１に、ネットワーク負荷分散インフラストラクチャ１０６の例示的な高可用性機構を示す。具体的に言うと、例示的な障害検出３１０４、例示的な障害ハンドリング３１０６、および例示的な障害リカバリ３１０８が示されている。これらの例示的な高可用性機構を、異なるネットワーク負荷分散インフラストラクチャ１０６コンポーネントに関して説明する。ネットワーク負荷分散インフラストラクチャ１０６コンポーネントには、フォワーダ３０２、クラシファイヤ３０４、リクエストルータ３０６、セッショントラッカ３０８、ならびにヘルスおよび負荷ハンドラ３１４が含まれる。

３１０２（Ａ）で、フォワーダ３０２が、ローカル障害をこうむる。３１０４（Ａ）で、少なくとも１つの負荷分散対応スイッチによって、この障害が検出される。ローカル障害３１０２（Ａ）を処理するために、パケットが、負荷分散対応スイッチによって、３１０６（Ａ）で他のフォワーダにリダイレクトされる。フォワーダ３０２の障害から回復するために、フォワーダ３０２でローカルに記憶されたルートが、３１０８（Ａ）で、ＤＡＭおよびそのＤＡＭテーブルなど、分散セッショントラッキングマネージャおよびそのテーブルを使用して、パケットがリダイレクトされたフォワーダで再構築される。したがって、分散セッショントラッキングマネージャに、１つまたは複数のレベルのデータ冗長性を含めることができる。

３１０２（Ｂ）で、クラシファイヤ３０４が、ローカル障害をこうむる。３１０４（Ｂ）で、少なくとも１つのフォワーダによって、この障害が検出される。ローカル障害３１０２（Ｂ）を処理するために、パケットが、障害を検出したフォワーダによって３１０６（Ｂ）で他のクラシファイヤにリダイレクトされる。クラシファイヤ３０４の障害から回復するために、クラシファイヤ３０４でローカルに記憶されたセッション情報が、３１０８（Ｂ）で、パケットがリダイレクトされたクラシファイヤで、ＤＡＭを使用して再構築される。このセッション情報は、たとえば、ベースラインＴＣＰ／ＩＰ接続より上位のセッション情報とすることができる。また、そのようなセッション情報を、クラシファイヤ３０４と同一装置に存在するセッショントラッキングインフラストラクチャの一部とみなすことができる。

３１０２（Ｃ）で、リクエストルータ３０６が、ローカル障害をこうむる。３１０４（Ｃ）で、少なくとも１つのフォワーダおよび／または負荷分散対応スイッチによって、この障害が検出される。ローカル障害３１０２（Ｃ）を処理するために、パケットが、３１０６（Ｃ）で、フォワーダおよび／または負荷分散対応スイッチによって他のルータにリダイレクトされる。ローカル障害３１０２（Ｃ）の発生時にリクエストルータ３０６によって扱われていた個々の現在の論理リクエストは、各個々の論理リクエストが、そのリクエストのサービス中に複製されない限り、失われる可能性がある。リクエストルータ３０６の障害から回復するために、リクエストルータ３０６でローカルに記憶されたセッション情報および／またはルートが、３１０８（Ｃ）で、パケット（したがって新しい論理リクエスト）がリダイレクトされるリクエストルータで再構築される。セッション情報再構築は、ＤＡＭを使用して実現することができる。やはり、そのようなセッション情報は、リクエストルータ３０６と同一の装置に存在するセッショントラッキングインフラストラクチャの一部とみなすことができる。

３１０２（Ｄ）で、セッショントラッカ３０８が、ローカル障害をこうむる。３１０４（Ｄ）で、少なくとも１つのフォワーダおよび／またはクラシファイヤによって、この障害が検出される。たとえば、セッショントラッカ３０８が、クラシファイヤと同一の装置に常駐する場合に、フォワーダまたは別のクラシファイヤによって、この障害を検出することができる。セッショントラッカ３０８が、別々の装置に存在する場合には、クラシファイヤによってこの障害を検出することができる。ローカル障害３１０２（Ｄ）を処理するために、１つまたは複数のレベルのデータ冗長性および複数の装置にまたがる分配が、３１０６（Ｄ）で、トラッキングされるセッション情報について開始される。冗長性および分配が、障害３１０２（Ｄ）の前に開始されることに留意されたい。セッショントラッカ３０８の障害から回復するために、ＤＡＭのテーブルからのセッション情報を、３１０８（Ｄ）で、障害の第２のレベルを処理するために、（まだそのように分散され、十分に複製されていない場合に）少なくとも２つの装置にまたがって再分配させ、再複製することができる。

３１０２（Ｅ）で、ヘルスおよび負荷ハンドラ３１４が、ローカル障害をこうむる。３１０４（Ｅ）で、少なくとも１つのクラシファイヤおよび／またはリクエストルータによって、この障害が検出される。たとえば、ヘルスおよび負荷ハンドラ３１４からヘルスおよび負荷情報を受け取っているコンポーネントによって、ヘルスおよび負荷ハンドラ３１４が応答しなくなる場合、特にヘルスおよび負荷ハンドラ３１４が、照会するコンポーネントと異なる装置に存在する場合に、障害を検出することができる。ローカル障害３１０２（Ｅ）を処理するために、キャッシュに格納されたヘルスおよび負荷データ冗長性および固有の障害ハンドリングが、ヘルスおよび負荷情報について３１０６（Ｅ）で使用される。

たとえば、各ヘルスおよび負荷ハンドラ３１４に、ヘルスおよび負荷テーブル１２０４の情報を複数のホスト１０８に複製する統合ヘルスおよび負荷キャッシュ１２０８を含めることができる。また、所与のヘルスおよび負荷ハンドラ３１４のヘルスおよび負荷情報１２０６のコンシューマを、ヘルスおよび負荷ハンドラ３１４と同一の装置に配置することができ、その結果、ヘルスおよび負荷ハンドラ３１４の障害を本質的に許容可能にすることができる。同様に、ヘルスおよび負荷情報１２０６のそれぞれの部分の正式バージョンを、それぞれのホスト１０８に配置し、その結果、ホスト１０８の障害によって、ヘルスおよび負荷情報のそれぞれの部分の消失が許容可能にされるようにする。

ヘルスおよび負荷ハンドラ３１４の障害から回復するために、ヘルスおよび負荷情報を消費する所与のネットワーク負荷分散コンポーネントによって、異なるヘルスおよび負荷ハンドラに照会することができる。というのは、各そのようなヘルスおよび負荷ハンドラに、ヘルスおよび負荷ハンドラ情報の統合キャッシュが含まれるからである。また、ヘルスおよび負荷ハンドラ３１４が、もう一度アクセス可能になる時に、メッセージプロトコル１５００を３１０８（Ｅ）で使用して、そのヘルスおよび負荷情報の統合キャッシュを再構築することができる。これらの例示的な高可用性機構を使用すると、クライアント１０２から障害をマスクするために、ネットワーク負荷分散インフラストラクチャ１０６コンポーネントの障害を、検出し、処理し、それから回復することができる。

（任意のトンネリングおよび／またはアプリケーションレベルバランシングを伴う接続移行の例）
この節では、接続移行などの接続操作をネットワーク負荷分散でどのように使用できるかを説明する。この節では、主に、図３２〜３９を参照し、接続マイグレータ３１０（図３）によって提供されるものなどの接続移行機能を明らかにする。上記で図３および４に関して説明したように、負荷分散インフラストラクチャ１０６での各入力接続は、そこで終端することができる。その後、接続をホスト１０８に移行することができ、その接続が、ホスト１０８で終端されるようになる。接続マイグレータ３１０は、この接続移行を実行することができ、接続マイグレータ３１０を、移行を実現するためにホスト１０８に部分的に配置することができる。そのような接続移行は、アプリケーションレベルの負荷分散と共に、クラシファイヤ３０４によっておよび／またはトンネラ３１２を介するトンネリングを使用して実行することができる。

図３２に、接続移行を有するアプリケーションレベルネットワーク負荷分散への例示的な手法を示す。アプリケーションレベルまたはレベル７の負荷分散は、接続を処理するアプリケーションに関する負荷分散決断を行うことに関する。アプリケーションレベル負荷分散を実行するために、負荷分散インフラストラクチャ１０６では、通常は、接続のデータ部分を考慮に入れる。リクエストルーティングが使用されない場合に、クラシファイヤ３０４によって、通常は、接続の初期部分が覗き見され、その後、接続が、接続マイグレータ３１０とあいまって、選択されたホスト１０８に移行される。

ＴＣＰベースの環境でのアプリケーションレベル負荷分散全般に関して、クラシファイヤ３０４によって、クライアントのＴＣＰ接続をどこに転送するかを判断する時に、クライアントのＴＣＰデータの最初の部分が覗き見される。したがって、アプリケーションレベルのロジックによって、クライアントのデータが試験され、そのデータに基づいて負荷分散決定が行われる。たとえば、接続が（暗号化されない）ＨＴＴＰ接続である場合に、クラシファイヤ３０４によって、接続の最初のＨＴＴＰのＨＴＴＰヘッダを覗き見することができ、ヘッダの内容のある部分（たとえばＵＲＬ、クッキーなど）に基づいてルーティング決定を行うことができる。アプリケーションレベル負荷分散、接続移行、およびトンネリングは、他のプロトコルに適用可能であるが、本明細書の例では主にＴＣＰ／ＩＰを使用する。

図からわかるように、負荷分散インフラストラクチャ１０６（特に図示せず）に、フォワーダ３０２、クラシファイヤ３０４、トンネラ３１２、および接続マイグレータ３１０（および、おそらく、たとえば負荷分散対応ルータ／スイッチ２０２（ＬＢＡ））が含まれる。フォワーダ３０２は、仮想ＩＰアドレスに対応し、クラシファイヤ３０４によるホスト選択に従ってホスト１０８にパケットを転送する。図３２には特に図示されていないが、ホスト１０８に、接続マイグレータ３１０の機能およびトンネラ３１２の機能も含まれる。

説明される実施形態で、フォワーダ３０２、クラシファイヤ３０４、および接続マイグレータ３１０（クラシファイヤ３０４およびホスト１０８の）が、クラシファイヤ３０４およびホスト１０８のＴＣＰプロトコルソフトウェアと共に、協力して接続移行を提供する。図３２に示された接続移行は、当初はクラシファイヤ３０４で終端されるクライアント１０２（１）からの接続に関する。接続移行の後に、クライアント１０２（１）からの接続が、ホスト１０８（１）で終端される。接続がホスト１０８（１）で終端されたならば、接続のパケットを、トンネラ３１２（フォワーダ３０２およびホスト１０８（１）の）を使用してトンネリングすることができる。

（１）で、クライアント１０２（１）によって、フォワーダ３０２にＳＹＮパケットが送られて、新しいＴＰＣ接続の開始がシグナリングされる。（２）で、フォワーダ３０２によって、このパケットがクラシファイヤ３０４に転送される。（３）で、クラシファイヤ３０４によって、ホスト１０８の代わりにＴＣＰ接続が受け入れられる（実際のターゲットホスト１０８（）がまだ選択されていないので、ホストの識別はまだ、未知である）。ＴＣＰプロトコル用語では、クラシファイヤ３０４によって、クライアント１０２（１）にＳＹＮ−ＡＣＫパケットが送られる。

（４）で、クライアント１０２（１）が、データの送出を開始する（最初のＳＹＮパケットにもデータを含めることができる）。データは、クラシファイヤ３０４によって処理され、クラシファイヤ３０４は、アプリケーション固有ロジックを調べることができる。アプリケーション固有ロジックは、どのホスト１０８がどの種類のリクエストまたは接続を処理できるまたは最もよく処理しているかに関するものとすることができる。したがって、クラシファイヤ３０４によって、このデータならびにヘルスおよび負荷ハンドラ３１４からのヘルスおよび負荷情報および任意選択としてセッショントラッカ３０８からのアプリケーションセッション情報を使用して、クライアント１０２（１）からのこの接続の処理によりよくまたは最もよく適するホスト１０８が判定される。この例では、ホスト１０８（１）が選択される。

（５）で、クラシファイヤ３０４によって、ＴＣＰ接続の状態を表す「バイナリブロブ（ｂｉｎａｒｙ ｂｌｏｂ）」が、ホスト１０８（１）に送られる。この接続状態は、接続マイグレータ３１０によって、クラシファイヤ３０４上のＴＣＰスタックからの協力を得て集約される。バイナリブロブには、クラシファイヤ３０４によって肯定応答されたクライアント１０２（１）からのデータと、ＴＣＰ／ＩＰ４タプル、初期シーケンス番号などのＴＣＰパラメータが含まれる。

（６）で、ホスト１０８（１）（図３２には明示的に図示せず）の接続マイグレータ３１０コンポーネントによって、この接続がホスト１０８（１）のＴＣＰスタックに「注入」される。この接続状態注入は、ホスト１０８（１）のＴＣＰスタックと協力して実行され、ホスト１０８（１）のアプリケーション３１６からは、この接続が元々ホスト１０８（１）自体によって受け入れられたように見えるようになる。クライアント１０２（１）は、接続移植について知らない。

（７）で、クラシファイヤ３０４によって、クラシファイヤ３０４のＴＣＰスタックと協力して、この接続のために維持される内部状態が静かにクリーンアップされる。また、クラシファイヤ３０４によって、この接続のパケットの宛先としてホスト１０８（１）を示すルートが、フォワーダ３０２のローカルルーティングテーブルに追加される。

（８）で、接続の後続パケットが、フォワーダ３０２によってホスト１０８（１）にルーティングされる。これらのパケットは、フォワーダ３０２によって、接続移行なしで分類され、ルーティングされる接続のパケットと同一の形で扱うことができる。この後続パケットを、任意選択として、トンネラ３１２を使用してフォワーダ３０２からホスト１０８（１）にトンネリングすることができる。トンネラ３１２は、クラシファイヤ３０４の接続マイグレータ３１０側でも示されている（破線を使用して）が、これは、トンネラ３１２によって使用されるあるパラメータを、接続移行中におよび／または移行される接続に関連して判定できるからである。トンネラ３１２の例示的実施形態を、以下で、特に図３８および３９を参照してさらに説明する。

図３３は、第１装置から第２装置に接続を移行する例示的な方法を示すフローチャート３３００である。フローチャート３３００には、７つのブロック３３０２〜３３１４が含まれる。図３２および３４〜３７では、主にネットワーク負荷分散環境での接続移行に焦点を合わせるが、本明細書に記載の接続移行は、接続マイグレータ３１０の機能などの接続移行機能をそれぞれが含む２つの装置全般の間で実現することができる。

ブロック３３０２で、第１装置で接続を受け入れる。たとえば、第１装置によって、ネットワークスタックのプロトコルスタック部分の１つまたは複数のプロトコルに従って入力接続を終端することができる。ブロック３３０４で、第１装置で接続に関するデータを受け取る。たとえば、このデータを、接続をリクエストする最初のパケットで、または接続の受入の後に受信される１つまたは複数のパケットで受け取ることができる。

ブロック３３０６で、第１装置で、受け入れられた接続の接続状態をプロトコルスタックから（あるいは、より一般的にはネットワークスタックから）集約する。たとえば、プロトコルスタックの１つまたは複数のプロトコルのプロトコル状態を、肯定応答されたすべての受信データについてコンパイルし、集約することができる。ブロック３３０８で、第１装置から第２装置に接続状態を送る。たとえば、接続状態の集約された情報を、信頼性のあるプロトコルを使用して第２装置に送ることができる。

ブロック３３１０で、第２装置で、移行される接続の接続状態を第１装置から受け取る。ブロック３３１２で、第２装置のプロトコルスタック（または、より一般的にはネットワークスタック）に接続状態を注入する。たとえば、プロトコルスタックレベルの上のプログラムが、接続が移行された接続であることを知らないように、第２装置のプロトコルスタックのプロトコルを使用して、接続を元に戻すことができる。具体的に言うと、プロトコル状態を、プロトコルスタックに注入することができる。接続状態の集約されたデータも、第２装置で組み込まれる。ブロック３３１４で、第２装置で、接続を継続する。たとえば、接続が以前に他所で終端されなかったかのように、第２装置で接続を継続することができる。

図３４に、送信元装置（ｏｒｉｇｉｎａｔｉｎｇ ｄｅｖｉｃｅ）３４００の観点からの接続移行に対する例示的な手法を示す。送信元装置３４００での接続移行は、少なくとも部分的に、接続マイグレータ３１０によって実現される。説明される実施形態では、送信元装置３４００が、ネットワーク負荷分散インフラストラクチャ１０６の一部である装置である。たとえば、送信元装置３４００に、おそらくはフォワーダ３０２と共にクラシファイヤ３０４、リクエストルータ３０６などを含めることができる。

図からわかるように、送信元装置３４００に、そのネットワークスタックの一部として、物理ネットワークインターフェース（ＰＮＩ）３４１０、ＰＮＩミニポート３４０８、プロトコルハードウェアインターフェース３４０６、プロトコルスタック３４０４、およびソケットレイヤ３４０２が含まれる。送信元装置３４００には、アプリケーションレベルのクラシファイヤ３０４および接続マイグレータ３１０などの負荷分散機能１０６も含まれる。具体的に言うと、接続マイグレータ３１０に、マイグレータ中間ドライバ３４１４およびマイグレータシム３４１２が含まれる。接続マイグレータ３１０は、送信元装置３４００から接続をオフロードすることができる。

説明される実施形態では、物理ネットワークインターフェース３４１０を、ネットワークインターフェースカード（ＮＩＣ）（たとえばイーサネット（登録商標）ＮＩＣ）、無線インターフェースなどとすることができる。１つの物理ネットワークインターフェース３４１０だけが図示されているが、所与の装置が、実際に複数の物理ネットワークインターフェース３４１０を有することができる（すなわち、送信元装置３４００を、マルチホームとすることができる）。各物理ネットワークインターフェース３４１０は、通常は、１つまたは複数の物理ネットワークアドレスに対応する。

ＰＮＩミニポート３４０８は、物理ネットワークインターフェース３４１０の特定のハードウェア実現を理解し、これとインターフェースするソフトウェアモジュールである。プロトコルハードウェアインターフェース３４０６は、１つまたは複数のそれぞれのプロトコルとＰＮＩミニポート３４０８の間の１つまたは複数のそれぞれのインターフェースを含むレイヤである。

プロトコルスタック３４０４に、それぞれ１つまたは複数のそれぞれのプロトコルに対処する１つまたは複数のそれぞれのモジュールが含まれる。そのようなプロトコルの例を、以下で図３６および３７を参照してさらに説明する。一時のコンテキストで、プロトコルスタック３４０４に、送信元装置３４００に存在する各接続のプロトコル状態３４２０が含まれる。ソケットレイヤ３４０２は、負荷分散機能１０６などのプログラムとプロトコルスタック３４０４の間にある。ソケットレイヤ３４０２によって、負荷分散機能１０６とプロトコルスタック３４０４の間のＡＰＩが提供され、とりわけ、接続のためにプログラムを登録できるようになる。

マイグレータ中間ドライバ３４１４またはより一般的にマイグレータドライバ３４１４は、プロトコルハードウェアインターフェースレイヤ３４０６に位置する。マイグレータシム３４１２は、プロトコルスタック３４０４とソケットレイヤ３４０２の間に透過的に位置する。

新しい接続をリクエストする最初のパケット（図示せず）が、送信元装置３４００に提示される時に、パケットが、物理ネットワークインターフェース３４１０から上に、ＰＮＩミニポート３４０８、プロトコルハードウェアインターフェースレイヤ３４０６を介してプロトコルスタック３４０４に向けられる。パケットが、プロトコルスタック３４０４の１つまたは複数のプロトコルをトラバースする時に、プロトコル状態３４２０がそこで作成される。また、この最初のパケットの結果として、またはリクエスト時に覗き見される接続を負荷分散機能１０６が受け入れた結果として、データ３４１６が、送信元装置３４００に到着する。

動作時に、マイグレータ中間ドライバ３４１４によって、データ３４１６のコピーが、接続マイグレータ３１０のロジックに迂回される。負荷分散機能１０６によって、接続移行関数呼出しが発行される時に、その移行関数呼出しが、プロトコルスタック３４０４の最上部のレイヤに渡され、その結果、接続状態集約３４１８を開始できるようになる。プロトコル状態３４２０は、プロトコルスタック３４０４の１つまたは複数のプロトコルからコンパイルされる。ＴＣＰ／ＩＰ実施形態では、プロトコル状態３４２０に、（ｉ）宛先および発信元のＴＣＰポートおよびＩＰアドレス（たとえば、ＴＣＰ／ＩＰ４タプル）、（ｉｉ）ＴＣＰウィンドウ状態、（ｉｉｉ）初期シーケンス番号、（ｉｖ）タイムアウト情報、（ｖ）ＩＰフラグメントＩＤ、（ｖｉ）ルーティング情報、および（ｖｉｉ）その他を含めることができる。

接続状態集約３４１８によって、接続マイグレータ３１０に迂回され、送信元装置３４００から既に肯定応答された（たとえば、負荷分散機能１０６によって）データ３４１６も集約される。この集約された接続状態３４１８に、プロトコル状態３４２０およびデータ３４１６（および、任意選択として、他の接続関連情報）が含まれる。集約された接続状態３４１８は、次に、バイナリブロブ３４２２として、送信元装置３４００からターゲット装置へ信頼性のあるプロトコルを使用して送られる。このバイナリブロブ３４２２は、接続が後にトンネラ３１２によってトンネリングされる場合に、フロー識別子と一束にすることもできる。トンネリングに関するフロー識別子は、以下で特に図３８および３９に関してさらに説明する。

図３５に、ターゲット装置３５００の観点からの接続移行に対する例示的な手法を示す。ターゲット装置３５００は、接続マイグレータ３１０を含めて、さまざまな図示のレイヤ／モジュールに関して送信元装置３４００に似る。しかし、図からわかるように、アプリケーションレベルの少なくとも１つのアプリケーション３１６が、ソケットレイヤ３４０２とインターフェースする。したがって、ターゲット装置３５００に、ホスト１０８を含めることができる。また、接続マイグレータ３１０は、送信元装置３４００から接続をアップロードすることができる。

説明される実施形態では、アプリケーション３１６が、送信元装置３４００で受け取られる接続開始パケットの宛先である。送信元装置３４００から、ターゲット装置３５００によってバイナリブロブ３４２２が受け取られる。バイナリブロブ３４２２には、ターゲット装置３５００に移行される接続に関連する接続情報と、任意選択としてフロー識別子が含まれる。この接続状態に、プロトコル状態３４２０および肯定応答されたデータ３４１６（および、おそらくは他の接続関連情報）が含まれる。

動作時に、バイナリブロブ３４２２がプロトコルハードウェアインターフェースレイヤ３４０６に達する時に、マイグレータ中間ドライバ３４１４によって、それが接続移行に関するブロブとして認識され、方向を変えられる。接続状態は、３５０２で注入されて、接続が元々ターゲット装置３５００で終端していたというアプリケーション３１６に対する外見が作成される。

具体的に言うと、注入された接続状態３５０２のプロトコル状態３４２０は、プロトコルスタック３４０４に注入される。説明される実施形態では、プロトコル状態３４２０が、まずプロトコルスタック３４０４の上位レベルプロトコルで注入され、その後、下位レベルプロトコルに注入される。プロトコル状態３４２０が、プロトコルスタック３４０４に注入された後に、データ３４１６を、上へ、アプリケーションまで示すことができる。このデータ３４１６は、新にローカルに終端される接続の一部であるかのようにアプリケーション３１６に供給することができる。

接続状態注入３５０２が完了した後に、送信元装置３４００で受け取られたパケットによって開始された接続が、そこからターゲット装置３５００に成功裡に移行されている。この接続の後続パケットは、送信元装置３４００を通過せずに直接にターゲット装置３５００に転送することができ、あるいは、少なくともごく単純なルーティングだけで、アプリケーションレベル分析は適用されない。任意選択として、これらのパケットをトンネリングし、マイグレータ中間ドライバ３４１４が、仮想ＩＰアドレスに束縛されるソフトウェアベースの仮想ＮＩＣとして効果的に動作するようになる。

図３６に、接続移行に関するオフロードするプロシージャ３６００への例示的な手法を示す。移行オフロードプロシージャ３６００によって、送信元装置３４００による接続移行の追加の例示的詳細が示される。図からわかるように、一般的なプロトコルスタック３４０４に、ＴＣＰスタック３４０４（Ｔ）、ＩＰスタック３４０４（Ｉ）、およびアドレス解決プロトコル（ＡＲＰ）スタック３４０４（Ａ）が含まれる。しかし、他の特定のプロトコルスタック３４０４（）を、その代わりに使用することができる。

たとえば、プロトコルハードウェアインターフェースレイヤ３４０６を、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステム（ＯＳ）環境のネットワークドライバインターフェース規約（ＮＤＩＳ）ベースレイヤとして実現することができる。また、ソケットレイヤ３４０２を、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｗｉｎｄｏｗｓ（登録商標）ＯＳ環境のＷｉｎｓｏｃｋ（商標）レイヤとして実現することができる。

説明される実施形態では、マイグレータ中間ドライバ３４１４に、ＡＲＰスタック３４０４（Ａ）とＰＮＩミニポート３４０８の接合点にあるプロトコルハードウェアインターフェースレイヤ３４０６が含まれる。マイグレータ中間ドライバ３４１４は、移行オフロードプロシージャ３６００のオフロードターゲットとして働く。オフロードターゲットは、この例に示されているように、プロトコルハードウェアインターフェース３４０６ミニポートである。移行アップロードプロシージャ３７００（図３７など）では、マイグレータ中間ドライバ３４１４が、アップロードダイバータとして働く。

具体的に言うと、マイグレータ中間ドライバ３４１４は、各物理ネットワークインターフェース３４１０に束縛され、この物理ネットワークインターフェース３４１０を介してＴＣＰ接続を移行することができる。マイグレータ中間ドライバ３４１４は、通常は、これ以外の点ではパケットと相互作用せずに、ネットワークスタック内で上下にパケットを渡すことによって、パススルードライバとして動作する。しかし、マイグレータ中間ドライバ３４１４は、接続移行に関連するパケットには相互作用する（任意選択として後続のトンネリングされるパケットを含む）。

マイグレータ中間ドライバ３４１４の責任には、（ｉ）移行オフロードリクエストを受け入れることと、（ｉｉ）接続状態情報を作るために、肯定応答されたデータと共に、指定されたプロトコルスタック３４０４（）からコンパイルされる、移行されるＴＣＰ接続に関連するプロトコル状態情報を集約することと、（ｉｉｉ）移行アップロードプロシージャ３７００のためのターゲット装置３５００への集約された接続状態の送出が含まれる。そのような送出の信頼性のあるワイヤプロトコルを、セッショントラッキングコンポーネント２００２および２０１０によって使用されるものと共有して、セッション情報メッセージ２００８（たとえば、図２０を参照して上記で説明したもの）を送受することができる。

マイグレータ中間ドライバ３４１４のもう１つの責任（たとえば、移行アップロードプロシージャ３７００での）は、他の装置から受け取られる移行された接続のアップロードを開始し、移行される接続に関連する入力パケットのすべてを、アップロードの過程の間にバッファリングすることである。接続をアップロードするために、マイグレータ中間ドライバ３４１４によって、アップロードリクエストがマイグレータシム３４１２に送られる。マイグレータシム３４１２によって、プロトコルスタック３４０４のＴＣＰスタック３４０４（Ｔ）で下に注入呼出しが発行されて、ネットワークスタックのプロトコルスタック３４０４部分で接続がインスタンス化される。

マイグレータシム３４１２によって、クライアントインターフェースがＴＣＰスタック３４０４（Ｔ）に公開され、プロバイダインターフェースがソケットレイヤ３４０２に公開される。マイグレータシム３４１２は、２つの役割すなわち、（ｉ）送信元装置３４００で接続移行オフロードプロシージャ３６００を開始し、その後、ターゲット装置３５００で移行アップロードプロシージャ３７００を開始することと、（ｉｉ）ホストアプリケーション３１６プログラム、負荷分散クラシファイヤ３０４プログラム、およびソケットレイヤ３４０２の間で分類プロセスを調停することが含まれる。マイグレータシム３４１２およびマイグレータ中間ドライバ３４１４の両方を、以下で図３６および３７を参照してさらに説明する。

例示的な移行オフロードプロシージャ３６００について、ＴＣＰ接続の移行は、１つ、２つ、またはそれ以上のパケットを使用して、クラシファイヤ３０４によって入力ＴＣＰ接続が分類された後に実行される。移行オフロードプロシージャ３６００を、点＜１＞〜＜７＞で説明する。

＜１＞で、分類動作の前に初期化を実行する。プロトコルスタック３４０４によって、プロトコルハードウェアインターフェースレイヤ３４０６での照会が行われて、オフロード機能がある場合に、それが使用可能であるかどうかが判定される。マイグレータ中間ドライバ３４１４によって、接続移行オフロードが使用可能であることが示され、この照会がＰＮＩミニポート３４０８まで下に伝搬される。ＴＣＰチムニオフロード能力が、物理ネットワークインターフェース３４１０によって提供される場合に、ＰＮＩミニポート３４０８もそれを示す。ＴＣＰチムニオフロードによって、一部のＴＣＰ／ＩＰ処理を、物理ネットワークインターフェース３４１０のハードウェアからオフロードできるようになり、ＴＣＰチムニオフロードには、プロトコル状態３４２０のあるコンパイルが含まれる。その結果、一部のコンパイルおよび集約ロジックを、２つのオフロード機構の間で共有できるようになる。

＜２＞で、ＴＣＰ接続を分類したならば、クラシファイヤ３０４によって、選択されたホスト１０８へのＴＣＰ接続移行が開始される。具体的に言うと、ターゲット装置３５００を示す移行コマンドが、ソケットレイヤ３４０２を介してマイグレータシム３４１２に発行される。

＜３＞で、マイグレータシム３４１２によって、ＴＣＰ接続移行が開始されて、ＴＣＰプロトコル状態がコンパイルされる。具体的に言うと、マイグレータシム３４１２によって、ＴＣＰ移行オフロード開始ＡＰＩ（またはより一般的には接続移行関数呼出しまたは接続移行コマンド）が呼び出される。このルーチンによって、ターゲット装置３５００で接続を元どおりにするのに使用される指定されたＴＣＰ接続の関連する状態がコンパイルされる。コンパイルされたプロトコル状態３４２０に、ＴＣＰスタック３４０４（Ｔ）、ＩＰスタック３４０４（Ｉ）、およびＡＲＰスタック３４０４（Ａ）を含む中間スタックレイヤからの状態が含まれる。

＜４＞で、プロトコルスタック３４０４によって、移行されるＴＣＰ接続に関するプロトコル状態３４２０がコンパイルされたならば、プロトコルスタック３４０４によって、束縛されるミニポート（この例では、ミニポートがマイグレータ中間ドライバ３４１４である）に対して移行オフロード開始ＡＰＩが呼び出される。しかし、実際には、プロトコルスタック３４０４とマイグレータ中間ドライバ３４１４の間に挿入される、ＩＰ ＱｏＳなどの他の中間ドライバがある場合がある。そうである場合には、これらのＩＭドライバが、関連する場合に、その状態をコンパイルし、移行される接続に関する接続状態情報に集約することによって、移行に参加することができる。中間ドライバは、ネットワークスタックを下に移行オフロード開始呼出しを伝搬させ続け、ネットワークスタックで、最終的に、マイグレータ中間ドライバ３４１４での移行オフロードハンドラの実行がもたらされる。この時点で、マイグレータ中間ドライバ３４１４によって、ターゲット装置３５００へのＴＣＰ接続の転送に関する残りの接続状態に関する肯定応答されたデータも集約されている。

＜５＞で、移行されるＴＣＰ接続の接続状態情報を記憶／コピーした後に、マイグレータ中間ドライバ３４１４によって、移行オフロード開始完了ＡＰＩを呼び出すことによって、移行がその最終段階であることがネットワークスタックに通知される。この移行オフロード開始完了ＡＰＩは、逆のパスに従って、ネットワークスタックを上に、同一の中間ドライバ（ある場合に）を介して、最終的にプロトコルスタック３４０４に達する。各レイヤでこの呼出しが処理される時に、移行される接続に関連する状態情報を解放することができる。この呼出しの処理が完了するまでは、各レイヤが、ネットワークスタックの下に更新通知を送って、移行が開始された後に変更された接続状態のすべての部分を更新することができる。

＜６＞で、移行オフロード開始完了ルーチンが、ＴＣＰスタック３４０４（Ｔ）に達した時に、ＴＣＰによって、静かに（すなわち、クライアント１０２にリセットを送らずに）接続がクローズされ、移行された接続に関連するすべての状態がフラッシュされ、移行オフロード開始完了呼出しが、マイグレータシム３４１２に伝搬される。この時点で、ネットワークスタックは、移行されたＴＣＰ接続の残存している知識に一切制限されない。

＜７＞で、移行オフロード開始完了呼出しが、マイグレータ中間ドライバ３４１４にリターンする時に（接続マイグレータ３１０のマイグレータシム３４１２部分を介して）、送信元装置３４００からターゲット装置３５００へのＴＣＰ接続の移行を、接続状態の転送によって開始することができる。接続状態は、非同期に信頼性のある形で転送することができる。

移行が始まると、送信元装置３４００は、クライアント１０２からの後続データがターゲット装置３５００に転送されることを保証する責任も負う。その結果、接続が成功裡にターゲットに移行された後であっても、起点は、後続パケットをターゲットに正しくルーティングするために、接続の状態の一部を保持する（たとえば、ルーティングテーブルエントリ）。接続が終了する時に、ターゲットは、起点に通知して、起点が、移行された接続に関する残留する状態の残りのすべてを消去するようにする。

さらに、接続移行の非同期性の結果として、送信元装置３４００（または別々の装置の場合にそれによって指定されるフォワーダ）によって転送される移行される接続のデータパケットが、ターゲット装置３５００が移行される接続状態を受け取る前にターゲット装置３５００に到着し始める場合がある。ターゲット装置３５００のマイグレータ中間ドライバ３４１４は、関連する移行される接続がターゲット装置３５００で確立されるまで、これらのパケットをバッファリングする責任を負う。

図３７に、接続移行に関するアップロードプロシージャ３７００への例示的な手法を示す。移行アップロードプロシージャ３７００によって、ターゲット装置３５００による接続移行に関する追加の例示的な詳細が示される。

移行される接続が、ターゲット装置３５００に到達する時に、この接続は、処理のためにマイグレータ中間ドライバ３４１４に中継される。移行される接続状態を融合化し、同化した後に、マイグレータ中間ドライバ３４１４が、マイグレータシム３４１２とあいまって、アプリケーション３１６に透過的な形で、移行される接続をローカルネットワークスタックに注入する。例示的な移行アップロードプロシージャ３７００について、点＜１＞〜＜８＞でのＴＣＰ接続の移行を説明する。

＜１＞で、上記で移行オフロードプロシージャ３６００に関して説明したように、アプリケーションホスティング動作の前に初期化を実行する。具体的に言うと、プロトコルスタック３４０４によって、オフロード機能がある場合に、それが使用可能であるかどうかに関する照会が行われる。マイグレータ中間ドライバ３４１４によって、ＴＣＰ接続移行サポート照会が満たされて、接続移行アップロードが使用可能であることが示され、その照会が、可能なＴＣＰチムニオフロード機能に関してＰＮＩミニポート３４０８まで下に伝搬される。

＜２＞で、接続移行データがターゲット装置３５００に到着する時に、接続移行情報（たとえば、束にされたバイナリブロブ３４２２）が、マイグレータ中間ドライバ３４１４に配布される。マイグレータ中間ドライバ３４１４によって、接続状態が再組立され、移行中に到着した関連データと突き合わされ、ネットワークスタックへのアップロードの準備がされる。移行される接続をアップロードする処理中に到着するクライアント１０２からのデータのすべてが、マイグレータ中間ドライバ３４１４によってバッファリングされる。移行の成功裡の完了時に、データが、アプリケーション３１６に配布される。

＜３＞で、ローカルネットワークスタックへの移行される接続のアップロードを開始するために、マイグレータ中間ドライバ３４１４によって、移行される接続リクエストが到着したことが、マイグレータシム３４１２に通知される。マイグレータ中間ドライバ３４１４によって、接続状態（または、少なくともプロトコル状態３４２０）も、マイグレータシム３４１２に配布される。

＜４＞で、マイグレータシム３４１２によって、ＴＣＰ注入開始ルーチン（または、より一般的にはプロトコル状態注入ルーチン）を呼び出すことと、移行されるプロトコル状態３４２０をＴＣＰスタック３４０４（Ｔ）に供給することによって、移行される接続のアップロードが開始される。＜５＞で、ＴＣＰ／ＩＰによって、供給されたプロトコル状態３４２０を使用してプロトコルスタック３４０４全体で移行される接続が再作成される。このプロトコル状態３４２０に、トランスポート状態（ＴＣＰ）、パス状態（ＩＰ）、近傍および次ホップ状態（ＡＲＰ）などの１つまたは複数を含めることができる。

＜６＞で、移行される接続が、ターゲット装置３５００で成功裡に再確立された場合に、ＴＣＰによって、マイグレータシム３４１２のクライアント部分への接続イベントが開始されて、新しい接続が確立されたことが示される。障害には複数の可能な理由があるが、一般的な理由に、対応するリスナの欠如、ルーティング障害などを含めることができる。移行される接続をネットワークスタックによって再確立できない場合には、接続イベントは示されず、障害状況が、注入開始完了呼出しで指定される。接続マイグレータ３１０は、移行のクリーンアップと、接続を放棄するためのクライアント１０２へのリセット通知の送出の責任を負う。

＜７＞で、マイグレータシム３４１２が、プロバイダとして働いて、接続イベントをソケットレイヤ３４０２に伝搬させて、新しい接続が確立されたことを、リスンしているアプリケーション３１６に示す。アプリケーション３１６は、この接続を受け入れる場合に、通常のソケット読取動作およびソケット書込動作を介して、リクエストを処理し、応答する。アプリケーション３１６は、接続が移行されたことを知らないものとすることができる。接続が、アプリケーション３１６によって受け入れられない場合には、ＴＣＰによって、接続が終了されるが、クライアント１０２にリセット通知は送られない。やはり、障害状況が、注入開始完了呼出しで指定され、接続マイグレータ３１０が、移行のクリーンアップと、接続を放棄するためのクライアント１０２へのリセット通知の送出の責任を負う。

アプリケーション３１６およびクラシファイヤ３０４が、同一の装置に位置する時に、特別な状況が生じ、マイグレータシム３４１２が、これらの間の仲裁役になることができる。この両方のクラスのプログラムが同一のホスト１０８上にある時に、これらの両方が、同一のＩＰアドレスおよびＩＰポートをリスンしている可能性がある。しかし、ＴＣＰは、通常は、一意のＩＰアドレスおよびＩＰポートごとに１つのリスナを有する。その結果、マイグレータシム３４１２は、ＴＣＰレイヤでの単一のリスナへの２つのソケットを多重化することによって、２つのプログラムが同一のＩＰアドレスおよびＩＰポートをリスンしている構成を隠すことができる。

その場合に、接続イベントがマイグレータシム３４１２のクライアント部分に到着する時に、プロバイダとしてのマイグレータシム３４１２によって、ソケットレイヤ３４０２でどのリスニングソケットに接続通知を配布するかを判定する。対応するＩＰアドレスおよびＩＰポートをリスンするソケットが１つだけの場合には、そのソケットが接続イベントを受け取る。複数のソケットがリスンしている場合には、受取り側は、接続イベントが示されたコンテキストに依存する。接続イベントが、仮想ＩＰアドレスに関する新規接続である場合には、接続イベントは、クラシファイヤ３０４に配布され、接続イベントが、専用ＩＰアドレス（負荷分散ＩＰアドレス以外）または移行される接続のアップロードの結果である場合には、接続イベントは、ターゲットアプリケーション３１６に配布される。

＜８＞で、移行される接続の注入が完了したならば、ＴＰＣによって、供給された注入開始完了ハンドラを呼び出すことによって、マイグレータシム３４１２に通知する。状況コードを供給して、接続が成功裡にアップロードされたか否かをマイグレータシム３４１２に通知する。移行される接続のアップロードに失敗した場合には、接続マイグレータ３１０が、移行のクリーンアップと、リセットを送ることによる接続が放棄されたことのクライアント１０２への通知の責任を負う。移行される接続が、成功裡にローカルネットワークスタックに注入された場合には、マイグレータ中間ドライバ３４１４は、受け取ったパケットをプロトコルハードウェアインターフェース３４０６のパケット受信パスを介して上に渡すことによって、クライアント１０２からのバッファリングされたデータの配布を開始することができる。

移行された接続が、終了される（アップロードに失敗したので、移行された接続が、その後、通常の手段を介してクローズされたので、などの理由）時に、ターゲット装置３５００によって、送信元装置３４００に通知する。送信元装置３４００は、この通知を使用して、ルーティングテーブルエントリを含む移行された接続に関する残っている状態をより効率的に信頼性のある形でクリーンアウトする。したがって、将来に任意に終了される成功裡に移行された接続を説明するために、マイグレータシム３４１２によって、その活動を監視し、ソケットがクローズされた時にマイグレータ中間ドライバ３４１４に通知することができる。

図３８に、フォワーダ３０２およびホスト１０８の間のパケットトンネリングに対する例示的な手法を示す。カプセル化されたパケット３８０８を、送信されるパケットごとのオーバーヘッドをこうむらずに、フォワーダ３０２からホスト１０８にトンネリングすることができる。以下でさらに説明するように、トンネリングは、フロー識別子３８１４ならびにそれぞれフォワーダ３０２およびホスト１０８のトンネラ３１２（Ｆ）および３１２（Ｈ）のカプセル化マッピングテーブル３８０６および３８１０を使用して実現される。フロー識別子３８１４は、カプセル化されたパケット３８０８に挿入される。

上記で図３２を参照して注記したように、接続移行の後に来る接続のパケットを、トンネラ３１２によるトンネリングを使用して、フォワーダ３０２によってホスト１０８（１）にルーティングすることができる。（８）（図３２）で、フォワーダ３０２によって、そのような後続パケットが、ネットワークアドレス「Ｆ」を有するフォワーダ３０２から、ネットワークアドレス「Ｈ１」を有するホスト１０８（１）に転送される。上記で図４を参照して説明したように、フォワーダ３０２は、入力パケットをホスト１０８（１）にルーティングするために、ＮＡＴ、半ＮＡＴ、トンネリングなどを実行することができる。

そのような入力パケットに、クライアント１０２（１）から到着するパケットの、仮想ＩＰ（「ＶＩＰ」）アドレスの宛先ＩＰアドレスおよび「Ｃ１」の発信元ＩＰアドレスが含まれる。ホスト１０８（１）にルーティングされるパケットは、Ｈ１の宛先ＩＰアドレスと、Ｃ１（半ＮＡＴの場合）または「Ｆ」（フルＮＡＴの場合）の発信元アドレスを有する。このアドレスの再書込は、クライアント１０２（１）およびホスト１０８（１）の両方が発信元アドレスおよび宛先アドレスの同一のビューを有することを期待するプロトコルと干渉する可能性がある。

さらに、少なくともフルＮＡＴに関して、ホスト１０８（１）からクライアント１０２（１）への、フォワーダ３０２を介しないリターンパスは、ホスト１０８（１）がクライアント１０２（１）のアドレスを知らないので、禁止される。ホスト１０８（１）からクライアント１０２（１）への直接パスは、ホスト１０８（１）からクライアント１０２（１）へのトラフィックが非常に多い状況および／または反対方向のトラフィックよりもかなり多い状況（たとえば、ホスト１０８（１）が、クライアント１０２（１）にストリーミングメディアを供給する時）で望ましい。

本明細書に記載のトンネラ３１２によるトンネリングによって、クライアント１０２およびホスト１０８上のアプリケーション３１６の発信元アドレスおよび宛先アドレス（およびポート）に関する理想的なビューを提供することができる。たとえば、図３４および３５に関して、フォワーダ３０２およびホスト１０８のそれぞれのトンネラ３１２は、接続マイグレータ３１０のマイグレータ中間ドライバ３４１４の一部として、またはこれとあいまって動作することができる。

図３８の説明される実施形態では、接続マイグレータ３１０によって、フロー識別子３８１４とＴＣＰ／ＩＰ４タプル３８０４の間のカプセル化マッピング３８１２がもたらされる。接続マイグレータ３１０をクラシファイヤ３０４に関連付けることができ、接続マイグレータ３１０（任意選択としてそのようなクラシファイヤ３０４と共に）を、フォワーダ３０２と同一の装置に配置することができる。別法では、接続マイグレータ３１０（ならびにクラシファイヤ３０４）を、フォワーダ３０２と異なる装置に配置することができる。カプセル化マッピング３８１２を、その代わりに、たとえばクラシファイヤ３０４に位置するおよび／またはこれに関連するトンネラ３１２機能によってまたはこれと共に提供することができる。

カプセル化マッピング３８１２でＴＣＰ／ＩＰ４タプル３８０４にマッピングされることによって、フロー識別子３８１４は、特定の接続のカプセル化されたパケット３８０８のフローを識別するように働く。ＴＣＰ／ＩＰ４タプル３８０４に、ＴＣＰ／ＩＰプロトコルまたは類似するプロトコルによる特定の接続の発信元および宛先のネットワークアドレス（およびポートなど）が含まれる。フロー識別子３８１４は、説明される実施形態では３２ビットである。というのは、３２ビットが、インターネットＩＰｖ４プロトコルに従って確立される接続で使用可能であるからである。しかし、他の長さのフロー識別子３８１４を、特にインターネットＩＰｖ６、ＵＤＰなどの他のプロトコルについて、その代わりに使用することができる。

フロー識別子３８１４は、増分式の接続カウンタなどの適切な機構を使用して生成することができる。さらに、ＴＣＰ／ＩＰ４タプル３８０４は、より一般的には発信元／宛先対である。個々の発信元／宛先対の各発信元値および宛先値に、特定の接続で伝搬される所与のパケットの発信元および宛先のネットワークノード識別子（たとえば、ネットワークアドレス、ポート、その組合せなど）を含めることができる。

接続マイグレータ３１０によって、ホスト１０８にカプセル化マッピング３８１２が供給される。ホスト１０８のトンネラ３１２によって、カプセル化マッピングテーブル３８１０内のカプセル化マッピング３８１２が、カプセル化マッピングエントリ３８１０（１）として記憶される。したがって、トンネラ３１２（Ｈ）によって、フロー識別子３８１４を使用して、ＴＣＰ／ＩＰ４タプル３８０４に対応する特定の接続にマッピングし、識別することができる。カプセル化マッピング３８１２を、任意選択として、接続移行動作の束にされるバイナリブロブ３４２２の一部としてホスト１０８に供給することができる。

フォワーダ３０２に、カプセル化マッピングテーブル３８０６と共にトンネラ３１２（Ｆ）コンポーネントも含まれる。カプセル化マッピングテーブル３８０６によって、特定の接続のＴＣＰ／ＩＰ４タプル３８０４をフロー識別子３８１４にリンク／マッピングするカプセル化マッピングエントリ３８０６（１）が記憶される。トンネラ３１２（Ｆ）によって、カプセル化マッピングエントリ３８０６（１）のマッピング情報も、接続マイグレータ３１０から受け取られる（たとえば、カプセル化マッピング３８１２として）。

１つのカプセル化マッピングエントリ３８０６（１）および３８１０（１）だけが図示されているが、カプセル化マッピングテーブル３８０６およびカプセル化マッピングテーブル３８１０のそれぞれが、複数のエントリを有することができる。このカプセル化マッピングテーブル３８０６および３８１０を、セッショントラッカ３０８のセッション情報のテーブルなど、他の情報と組み合わせることができる。

カプセル化されたパケット３８０８の送信装置（フォワーダ３０２など）および受信装置（ホスト１０８など）が、お互いの間でトンネリングするだけである時に、そのカプセル化マッピングテーブルが、同一のカプセル化マッピングエントリを有する可能性が高い。そうでない場合に、カプセル化マッピングテーブル３８０６およびカプセル化マッピングテーブル３８１０が、それぞれカプセル化マッピングエントリ３８０６（）およびカプセル化マッピングエントリ３８１０（）の異なる組を有する可能性が高い。

動作時に、特定の接続の入力パケット３８０２が、フォワーダ３０２で受け取られる。特定の接続が、ＴＣＰ／ＩＰ４タプル３８０４に関連付けられる。入力パケット３８０２に、発信元ＩＰアドレス（クライアント１０２の）、宛先ＩＰアドレス（仮想ＩＰ）、発信元ＴＣＰポート（クライアント１０２の）、および宛先ＴＣＰポートを有するＴＣＰ／ＩＰ４タプル３８０４が含まれる。

トンネラ３１２（Ｆ）によって、ホスト１０８へのトンネリングに関する入力パケット３８０２が受け入れられる。ＴＣＰ／ＩＰ４タプル３８０４を使用して、トンネラ３１２（Ｆ）によって、カプセル化マッピングテーブル３８０６にアクセスして、カプセル化マッピングエントリ３８０６（１）を突き止める。フロー識別子３８１４が、ＴＣＰ／ＩＰ４タプル３８０４にリンク／マッピングされたカプセル化マッピングエントリ３８０６（１）から抽出される。

カプセル化されたパケット３８０８を作成するために、トンネラ３１２（Ｆ）によって、ＴＣＰ／ＩＰ４タプルヘッダの発信元部分および宛先部分に、フロー識別子３８１４が挿入される。インターネットＩＰｖ４実施形態に関して、この２つのＴＣＰポート部分によって、合計３２ビットのスペースが提供される。また、ＴＣＰ／ＩＰ４タプルヘッダの発信元ＩＰアドレス部分に関して、トンネラ３１２（Ｆ）によって、フォワーダ３０２のＩＰアドレス「Ｆ」が挿入される。ＴＣＰ／ＩＰ４タプルヘッダの宛先ＩＰアドレス部分に関して、トンネラ３１２（Ｆ）によって、ホスト１０８のＩＰアドレス「Ｈ」が挿入される。

フォワーダ３０２によって、カプセル化されたパケット３８０８がホスト１０８にルーティング／送信され、ホスト１０８によって、フォワーダ３０２からのカプセル化されたパケット３８０８が受け取られる。ホスト１０８のトンネラ３１２（Ｈ）コンポーネントによって、カプセル化されたパケット３８０８が、非カプセル化されなければならないトンネリングされたパケットであることが検出される。

フロー識別子３８１４が、カプセル化されたパケット３８０８から抽出され、カプセル化マッピングテーブル３８１０のカプセル化マッピングエントリ３８１０（１）内でリンクされた対応するＴＣＰ／ＩＰ４タプル３８０４をルックアップするのに使用される。ＴＣＰ／ＩＰ４タプル３８０４は、トンネラ３１２（Ｈ）によって、フォワーダ３０２で入力パケット３８０２で最初に受け取られたＴＣＰ／ＩＰ４タプル３８０４ヘッダを再作成するのに使用される。

具体的に言うと、フォワーダ３０２のＩＰアドレスＦが、発信元ＩＰアドレスと置換され、ホスト１０８のＩＰアドレスＨが、宛先ＩＰアドレスと置換される。さらに、フロー識別子３８１４が、発信元ＴＣＰポートおよび宛先ＴＣＰポートと置換される。非カプセル化されたパケットが、ホスト１０８のネットワークスタックでターゲットアプリケーション３１６まで示される。

一般的に言うと、パケットヘッダのうちで、所与のパケットを通信するのに必ずしも使用されない、所与のパケットの発信元／宛先対の一部を含む部分を、フロー識別子３８１４を担持するのに使用することができる。ホスト１０８で発信元／宛先対の少なくとも一部を事前に提供することによって、フロー識別子３８１４を使用して、各パケットでのカプセル化オーバーヘッドをこうむらずにパケットをトンネリング（たとえば、カプセル化および／または非カプセル化）することができる。さらに、所与のプロトコルに関してフルサイズであるパケットを、分割せずにトンネリングすることができる。

図３９は、第１装置と第２装置の間のパケットトンネリングの例示的な方法を示すフローチャート３９００である。たとえば、第１装置および第２装置は、それぞれ負荷分散インフラストラクチャ１０６およびホスト１０８のクラスタの、送信元装置３４００およびターゲット装置３５００とすることができる。それでも、トンネリングを、負荷分散以外の実施形態で使用することができる。

フローチャート３９００に、１２個のブロック３９０２〜３９２４が含まれる。フローチャート３９００の動作を、他の環境でおよびさまざまなソフトウェア方式と共に実行することができるが、特に図１〜３、３２、３４、３５、および３８を使用して、この方法のある態様および例を示す。

ブロック３９０２で、フロー識別子−ＴＣＰ／ＩＰ４タプルのマッピングを、送信元装置からターゲット装置に送る。たとえば、送信元装置３４００によって、フロー識別子３８１４をＴＣＰ／ＩＰ４タプル３８０４にリンクするカプセル化マッピング３８１２を送ることができる。ブロック３９１４で、フロー識別子−ＴＣＰ／ＩＰ４タプルのマッピングを、ターゲット装置で送信元装置から受け取る。たとえば、ターゲット装置３５００によって、フロー識別子３８１４をＴＣＰ／ＩＰ４タプル３８０４にリンクするカプセル化マッピング３８１２を送信元装置３４００から受け取る。

その代わりに、ターゲット装置３５００によって、別の装置からカプセル化マッピング３８１２を受け取ることができる。破線の矢印３９２６および３９２８によって示されるように、ブロック３９０４〜３９１２およびブロック３９１６〜３９２４の動作を、それぞれブロック３９０２および３９１４の動作の後に行うことができる。

ブロック３９０４で、送信元装置でクライアントから入力パケットを受け取る。たとえば、ＴＣＰ／ＩＰ４タプル３８０４を含むヘッダを有する入力パケット３８０２を、送信元装置３４００でクライアント１０２から受け取ることができる。ブロック３９０６で、入力パケットのＴＣＰ／ＩＰ４タプルを使用して、クライアントのパケットに対応する接続についてフロー識別子をルックアップする。たとえば、カプセル化マッピングテーブル３８０６のカプセル化マッピングエントリ３８０６（１）内でそれにマッピングされるＴＣＰ／ＩＰ４タプル３８０４を使用してクライアント１０２との接続についてフロー識別子３８１４をルックアップすることができる。

ブロック３９０８で、入力パケットの発信元ＩＰおよび宛先ＩＰを、それぞれ送信元装置の元のＩＰアドレスおよびターゲット装置のターゲットＩＰアドレスに置換する。たとえば、送信元装置３４００によって、入力パケット３８０２のヘッダのＴＣＰ／ＩＰ４タプル３８０４のＩＰアドレス部分を、送信元装置３４００およびターゲット装置３５００のＩＰアドレスに置換することができる。

ブロック３９１０で、入力パケットの発信元ポートおよび宛先ポートを、フロー識別子を用いて置換する。たとえば、送信元装置３４００によって、入力パケット３８０２のＴＣＰ／ＩＰ４タプル３８０４部分の発信元ＴＣＰポートおよび宛先ＴＣＰポートを、フロー識別子３８１４を用いて置換することができる。ブロック３９１２で、カプセル化されたパケットを、送信元装置からターゲット装置に送る。たとえば、送信元装置３４００によって、カプセル化されたパケット３８０８をターゲット装置３５００に送ることができる。

ブロック３９１６で、カプセル化されたパケットを、ターゲット装置で送信元装置から受け取る。たとえば、ターゲット装置３５００によって、送信元装置３４００からカプセル化されたパケット３８０８を受け取ることができる。ブロック３９１８で、フロー識別子を使用して、クライアントから受け取ったパケットに対応する接続についてＴＣＰ／ＩＰ４タプルをルックアップする。たとえば、ターゲット装置３５００によって、フロー識別子３８１４をＴＣＰ／ＩＰ４タプル３８０４にマッピングするカプセル化マッピングエントリ３８１０（１）でカプセル化マッピングテーブル３８１０にアクセスすることができる。

ブロック３９２０で、ルックアップされたＴＣＰ／ＩＰ４タプルを使用して、起点ＩＰアドレスおよびターゲットＩＰアドレスを、発信元ＩＰアドレスおよび宛先ＩＰアドレスに置換する。たとえば、ターゲット装置３５００によって、カプセル化されたパケット３８０８内の送信元装置３４００およびターゲット装置３５００のＩＰアドレスを、カプセル化マッピングテーブル３８１０から獲得されるＴＣＰ／ＩＰ４タプル３８０４からの発信元ＩＰアドレスおよび宛先ＩＰアドレスに置換することができる。

ブロック３９２２で、ルックアップされたＴＣＰ／ＩＰ４タプルを使用して、フロー識別子を、入力パケットの発信元ポートおよび宛先ポートを用いて置換する。たとえば、ターゲット装置３５００によって、ＴＣＰ／ＩＰ４タプル３８０４の発信元ＴＣＰポートおよび宛先ＴＣＰポートを用いて、カプセル化されたパケット３８０８内のフロー識別子３８１４を置換することができる。ブロック３９２４で、クライアントのパケットを、ターゲット装置でアプリケーションに示す。たとえば、カプセル化されたパケット３８０８の非カプセル化されたバージョンまたは入力パケット３８０２が、ターゲット装置３５００のアプリケーション３１６に示される。

図１〜３９の動作、態様、特徴、コンポーネントなどは、複数のブロックに分割される図に示されている。しかし、図１〜３９が説明され、かつ／または示された順序、相互接続、レイアウトなどは、制限として解釈されることを意図されたものではなく、任意の数のブロックを、ネットワーク負荷分散に関する１つまたは複数のシステム、方法、装置、プロシージャ、媒体、ＡＰＩ、装置、構成などを実施するために、任意の形で組み合わせ、再配置し、増補し、省略することができる。さらに、本明細書の説明に、特定の実施形態（および図４０の例示的動作環境）への参照が含まれるが、図示され、かつ／または説明される実施形態は、適切なハードウェア、ソフトウェア、ファームウェア、またはこれらの組合せで、適切なネットワーク編成、トランスポート／通信プロトコル、アプリケーションプログラミングインターフェース（ＡＰＩ）、クライアント−サーバアーキテクチャなどを使用して実施することができる。

（コンピュータまたは他の装置の動作環境の例）
図４０に、本明細書に記載のネットワーク負荷分散の少なくとも１つのシステム、装置、装置、コンポーネント、構成、プロトコル、手法、方法、プロシージャ、媒体、ＡＰＩ、これらの組合せなどを実施することができる（完全にまたは部分的に）例示的なコンピューティング（または一般装置）動作環境４０００を示す。動作環境４０００は、以下で説明するコンピュータおよびネットワークアーキテクチャで、または独立型の状況で使用することができる。

例示的な動作環境４０００は、環境の１つの例にすぎず、適用可能な装置（コンピュータ、ネットワークノード、エンターテイメント装置、モバイル機器、一般電子装置などを含む）アーキテクチャの使用または機能の範囲に関する制限を暗示することを意図されたものではない。動作環境４０００（またはその装置）を、図４０に示された構成要素の１つまたはその組合せに関する依存性または要件を有するものと解釈してもならない。

さらに、ネットワーク負荷分散を、多数の他の汎用のまたは特殊目的の装置（コンピューティングシステムを含む）環境または構成を用いて実施することができる。使用に適する可能性がある周知の装置、システム、環境、および／または構成の例には、パーソナルコンピュータ、サーバコンピュータ、シンクライアント、シッククライアント、携帯情報端末（ＰＤＡ）または携帯電話機、腕時計、ハンドヘルド装置またはラップトップ装置、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラマブル家電、ビデオゲーム機、ゲーム機、ポータブルまたはハンドヘルドゲーミングユニット、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、ネットワークノード、上記のシステムまたは装置のいずれかを含む分散コンピューティング環境またはマルチプロセッシングコンピューティング環境、これらの組合せなどが含まれるが、これに制限はされない。

ネットワーク負荷分散の実施形態をプロセッサ実行可能命令の全般的な文脈で説明することができる。一般に、プロセッサ実行可能命令には、特定のタスクの実行および／またはイネーブルおよび／または特定の抽象データ型の実施を行う、ルーチン、プログラム、プロトコル、オブジェクト、インターフェース、コンポーネント、データ構造などが含まれる。本明細書でいくつかの実施形態で説明したネットワーク負荷分散は、通信リンクおよび／または通信ネットワークを介して接続されたリモートリンクされた処理装置によってタスクが実行される分散処理環境でも実践することができる。特に分散コンピューティング環境では、プロセッサ実行可能命令が、別々の記憶媒体に位置し、異なるプロセッサによって実行され、かつ／または伝送媒体を介して伝搬されることが可能である。

例示的な動作環境４０００に、コンピュータ４００２の形の汎用コンピューティング装置が含まれ、コンピュータ４００２に、コンピューティング／処理機能を有するすべての（たとえば電子）装置を含めることができる。コンピュータ４００２の構成要素には、１つまたは複数のプロセッサまたは処理ユニット４００４、システムメモリ４００６、およびプロセッサ４００４を含むさまざまなシステム構成要素をシステムメモリ４００６に結合するシステムバス４００８を含めることができるが、これに制限はされない。

プロセッサ４００４は、それを形成する材料またはそれに使用される処理機構によって制限されない。たとえば、プロセッサ４００４は、半導体および／またはトランジスタからなるものとすることができる（たとえば、電子集積回路（ＩＣ））。そのような文脈で、プロセッサ実行可能命令を、電子的に実行可能な命令とすることができる。別法では、プロセッサ４００４の機構またはこれのための機構、したがってコンピュータ４００２の機構またはこれのための機構に、量子コンピューティング、光コンピューティング、機械コンピューティング（たとえばナノテクノロジを使用する）などを含めることができるが、これに制限はされない。

システムバス４００８は、メモリバスまたはメモリコントローラ、ポイントツーポイント接続、スイッチングファブリック、周辺機器バス、ａｃｃｅｌｅｒａｔｅｄ ｇｒａｐｈｉｃｓ ｐｏｒｔ、およびさまざまなバスアーキテクチャのいずれかを使用するプロセッサバスまたはローカルバスを含むさまざまな種類の有線または無線のバス構造のいずれかの１つまたは複数を表す。たとえば、そのようなアーキテクチャに、Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、Ｅｎｈａｎｃｅｄ ＩＳＡ（ＥＩＳＡ）バス、Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ（ＶＥＳＡ）ローカルバス、メザニンバスとも称するＰｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔｓ（ＰＣＩ）バス、これらの組合せなどを含めることができる。

コンピュータ４００２に、通常は、さまざまなプロセッサアクセス可能媒体が含まれる。そのような媒体は、コンピュータ４００２または別の（たとえば電子）装置によってアクセス可能な任意の使用可能な媒体とすることができ、これには、揮発性および不揮発性の媒体、取外し可能および取外し不能の媒体、ならびに記憶媒体および伝送媒体の両方が含まれる。

システムメモリ４００６に、ランダムアクセスメモリ（ＲＡＭ）４０１０などの揮発性メモリ、および／または読取専用メモリ（ＲＯＭ）４０１２などの不揮発性メモリの形のプロセッサアクセス可能記憶媒体が含まれる。起動中などにコンピュータ４００２内の要素の間での情報の転送を助ける基本ルーチンを含む基本入出力システム（ＢＩＯＳ）４０１４が、通常ＲＯＭ４０１２に記憶される。ＲＡＭ４０１０に、通常は、処理装置４００４によって即座にアクセス可能および／または現在操作されつつあるデータおよび／またはプログラムモジュール／命令が含まれる。

コンピュータ４００２には、他の取外し可能／取外し不能および／または揮発性／不揮発性記憶媒体も含めることができる。たとえば、図４０に（通常は）取外し不能不揮発性磁気媒体（別々には図示せず）から読み取り、これに書き込むハードディスクドライブまたはディスクドライブアレイ４０１６、（通常は）取外し可能不揮発性磁気ディスク４０２０（たとえば「フロッピディスク」）から読み取り、これに書き込む磁気ディスクドライブ４０１８、およびＣＤ、ＤＶＤ、または他の光学媒体などの（通常は）取外し可能不揮発性光ディスク４０２４から読み取り、かつ／またはこれに書き込む光ディスクドライブ４０２２が示されている。ハードディスクドライブ４０１６、磁気ディスクドライブ４０１８、および光ディスクドライブ４０２２のそれぞれは、１つまたは複数の記憶媒体インターフェース４０２６によって、システムバス４００８に接続される。別法では、ハードディスクドライブ４０１６、磁気ディスクドライブ４０１８、および光ディスクドライブ４０２２を、１つまたは複数の他の別々のまたは組み合わされたインターフェース（図示せず）によってシステムバス４００８に接続することができる。

ディスクドライブおよびそれに関連するプロセッサ可読媒体によって、コンピュータ４００２のデータ構造、プログラムモジュール、および他のデータなどのプロセッサ実行可能命令の不揮発性ストレージが提供される。例示的なコンピュータ４００２に、ハードディスク４０１６、取外し可能磁気ディスク４０２０、および取外し可能光ディスク４０２４が示されているが、磁気カセットまたは他の磁気記憶装置、フラッシュメモリ、コンパクトディスク（ＣＤ）、ディジタル多用途ディスク（ＤＶＤ）、または他の光ストレージ、ＲＡＭ、ＲＯＭ、電気的消去可能プログラマブル読取専用メモリ（ＥＥＰＲＯＭ）などの、装置によってアクセス可能な他の種類のプロセッサアクセス可能媒体によって命令を記憶できることを理解されたい。そのような媒体に、いわゆる特殊目的ＩＣチップまたはハードワイヤドＩＣチップも含めることができる。言い換えると、例示的な動作環境４０００の記憶媒体を実現するのに、どのプロセッサアクセス可能媒体でも使用することができる。

一般的な例としてオペレーティングシステム４０２８、１つまたは複数のアプリケーションプログラム４０３０、他のプログラムモジュール４０３２、およびプログラムデータ４０３４を含む任意の数のプログラムモジュール（あるいは命令／コードの他の単位または組）を、ハードディスク４０１６、磁気ディスク４０２０、光ディスク４０２４、ＲＯＭ４０１２、および／またはＲＡＭ４０１０に記憶することができる。

ユーザは、キーボード４０３６およびポインティング装置４０３８（たとえば「マウス」）などの入力装置を介してコンピュータ４００２にコマンドおよび／または情報を入力することができる。他の入力装置４０４０（特に図示せず）に、マイクロホン、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、パラレルポート、スキャナ、および／または類似物を含めることができる。これらおよび他の入力装置は、システムバス４００８に結合された入出力インターフェース４０４２を介して処理ユニット４００４に接続される。しかし、その代わりに、入力装置および／または出力装置を、パラレルポート、ゲームポート、ｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌ ｂｕｓ（ＵＳＢ）ポート、赤外線ポート、ＩＥＥＥ １３９４（「Ｆｉｒｅｗｉｒｅ」）インターフェース、ＩＥＥＥ ８０２．１１無線インターフェース、Ｂｌｕｅｔｏｏｔｈ（登録商標）無線インターフェースなどの他のインターフェースおよびバス構造によって接続することができる。

モニタ／ビュースクリーン４０４４または他の種類のディスプレイ装置も、ビデオアダプタ４０４６などのインターフェースを介してシステムバス４００８に結合することができる。ビデオアダプタ４０４６（または別の構成要素）は、グラフィックス集中型計算を処理し、過酷なディスプレイ要件を処理するグラフィックスカードとするか、これに含めることができる。通常、グラフィックスカードに、グラフィックス処理ユニット（ＧＰＵ）、ビデオＲＡＭ（ＶＲＡＭ）などが含まれて、グラフィックスの迅速な表示およびグラフィックス演算の実行が実現される。モニタ４０４４の他に、他の出力周辺装置に、スピーカ（図示せず）およびプリンタ４０４８などの構成要素を含めることができ、これらを、入出力インターフェース４０４２を介してコンピュータ４００２に接続することができる。

コンピュータ４００２は、リモートコンピューティング装置４０５０などの１つまたは複数のリモートコンピュータへの論理接続を使用して、ネットワーク化された環境で動作することができる。たとえば、リモートコンピューティング装置４０５０は、パーソナルコンピュータ、ポータブルコンピュータ（たとえば、ラップトップコンピュータ、タブレットコンピュータ、ＰＤＡ、モバイルステーションなど）、パームまたはポケットサイズのコンピュータ、腕時計、ゲーム機、サーバ、ルータ、ネットワークコンピュータ、ピア装置、別のネットワークノード、または上に示したもの以外の装置種類などとすることができる。しかし、リモートコンピューティング装置４０５０は、コンピュータ４００２に関して本明細書で説明した要素および特徴の多くまたはすべてを含めることができるポータブルコンピュータとして図示されている。

コンピュータ４００２とリモートコンピューティング装置４０５０の間の論理接続は、ローカルエリアネットワーク（ＬＡＮ）４０５２および一般の広域ネットワーク（ＷＡＮ）４０５４として図示されている。そのようなネットワーキング環境は、オフィス、会社全体のコンピュータネットワーク、イントラネット、インターネット、固定電話網、携帯電話網、アドホック無線ネットワーク、インフラストラクチャ無線ネットワーク、他の無線ネットワーク、ゲーミングネットワーク、これらの組合せなどでありふれたものである。そのようなネットワークおよび通信接続が、伝送媒体の例である。

ＬＡＮネットワーキング環境で実施される時に、コンピュータ４００２は、通常は、ネットワークインターフェースまたはネットワークアダプタ４０５６を介してＬＡＮ４０５２に接続される。ＷＡＮネットワーキング環境で実施される時に、コンピュータ４００２に、通常は、ＷＡＮ４０５４を介する通信を確立する、モデム４０５８または他の手段が含まれる。モデム４０５８は、コンピュータ４００２に内蔵または外付けとすることができるが、入出力インターフェース４０４２または他の適切な機構を介してシステムバス４００８に接続することができる。図示のネットワーク接続が、例示的であり、コンピュータ４００２と４０５０の間の通信リンクを確立する他の手段を使用できることを理解されたい。

さらに、サーバ用に特に設計された他のハードウェアを使用することができる。たとえば、ＳＳＬアクセラレーションカードを使用して、ＳＳＬ計算をオフロードすることができる。さらに、特にネットワーク負荷分散動作環境で、ネットワークインターフェースまたはネットワークアダプタ４０５６上（たとえばネットワークインターフェースカード上）のＴＣＰオフロードハードウェアおよび／またはパケットクラシファイヤをサーバ装置でインストールし、使用することができる。

動作環境４０００と共に図示されたものなどのネットワーク化された環境では、コンピュータ４００２に関して示されたプログラムモジュールまたは他の命令あるいはその一部を、完全にまたは部分的にリモートメディアストレージ装置に記憶することができる。たとえば、リモートアプリケーションプログラム４０６０は、リモートコンピュータ４０５０のメモリ構成要素に常駐するが、コンピュータ４００２を介して使用可能または他の形でアクセス可能とすることができる。また、図示において、アプリケーションプログラム４０３０および、オペレーティングシステム４０２８などの他のプロセッサ実行可能命令が、この図では別個のプログラムとして図示されているが、そのようなプログラム、コンポーネント、および他の命令が、さまざまな時にコンピューティング装置４００２（および／またはリモートコンピューティング装置４０５０）の異なる記憶構成要素に常駐し、コンピュータ４００２（および／またはリモートコンピューティング装置４０５０）のプロセッサ４００４によって実行されることを理解されたい。

システム、媒体、装置、方法、プロシージャ、装置、技法、方式、手法、構成、および他の実施形態を、構造的、論理的、アルゴリズム的、および機能的な特徴および／または図に固有の言葉で説明したが、請求項で定義される発明が、説明された特定の特徴または図に必ずしも制限されないことを理解されたい。そうではなく、特定の特徴および図は、請求される発明を実施する例示的な形として開示されたものである。

負荷分散インフラストラクチャおよび複数のホストを示す例示的なネットワーク負荷分散パラダイムを示す図である。 複数の負荷分散ユニットおよび複数のホストを示す例示的なネットワーク負荷分散パラダイムを示す図である。 分離された機能を有する例示的な負荷分散ユニットおよび例示的なホストを示す図である。 分離された分類機能および転送機能を有する例示的なネットワーク負荷分散インフラストラクチャを示す図である。 ネットワーク負荷分散インフラストラクチャの異なる構成へのスケールアウトの例示的な方法を示すフローチャートである。 装置の観点からの第１の例示的なネットワーク負荷分散インフラストラクチャ構成を示す図である。 装置の観点からの第２の例示的なネットワーク負荷分散インフラストラクチャ構成を示す図である。 コンポーネントの観点からの第１の例示的なネットワーク負荷分散インフラストラクチャ構成を示す図である。 コンポーネントの観点からの第２の例示的なネットワーク負荷分散インフラストラクチャ構成を示す図である。 リソースの観点からの第１の例示的なネットワーク負荷分散インフラストラクチャ構成を示す図である。 リソースの観点からの第２の例示的なネットワーク負荷分散インフラストラクチャ構成を示す図である。 ホスト状態情報を含む例示的なネットワーク負荷分散手法を示す図である。 ホスト状態情報を含むネットワーク負荷分散の例示的な方法を示すフローチャートである。 ヘルスおよび負荷情報を含む例示的なネットワーク負荷分散手法を示す図である。 図１２に示された例示的なヘルスおよび負荷テーブルを示す図である。 図１２に示された例示的な統合ヘルスおよび負荷キャッシュを示す図である。 ヘルスおよび負荷情報を含むネットワーク負荷分散の例示的な方法を示すフローチャートである。 図１２に示されたホストと負荷分散ユニットの間の通信の例示的なメッセージプロトコルを示す図である。 図１２に示されたホストと負荷分散ユニットの間の通信の例示的なメッセージ伝送方式を示す図である。 図１３Ａのヘルスおよび負荷テーブルの例示的なヘルスおよび負荷情報プロキシストレージシナリオを示す図である。 図１３Ｂの統合ヘルスおよび負荷キャッシュの例示的なヘルスおよび負荷情報プロキシストレージシナリオを示す図である。 ヘルスおよび負荷情報を使用する例示的なターゲットホスト割当プロシージャを示す図である。 セッション情報を含む例示的なネットワーク負荷分散手法を示す図である。 通知およびメッセージを使用するセッション情報の通信を用いる例示的なネットワーク負荷分散手法を示す図である。 通知およびメッセージを使用するセッション情報の通信を用いるネットワーク負荷分散の例示的な方法を示すフローチャートである。 複数の負荷分散ユニットでセッション情報を管理する例示的な手法を示す図である。 図２０に示された例示的なセッションテーブルを示す図である。 図２２に示された例示的な分散アトムマネージャ（ＤＡＭ）テーブル（ＤＡＭＴ）を示す図である。 複数の負荷分散ユニットでセッション情報を管理する例示的な方法を示すフローチャートである。 リクエストルーティング機能を有する例示的なネットワーク負荷分散インフラストラクチャを示す図である。 （ｉ）セッション情報ならびに（ｉｉ）ヘルスおよび負荷情報に関して入力パケットをルーティングする例示的な方法を示すフローチャートである。 障害がないときの例示的なトラフィックルーティングフローを示す図である。 障害があるときの例示的なトラフィックルーティングフローを示す図である。 ネットワーク負荷分散インフラストラクチャの高可用性に関する追加の例示的なフェールオーバープロシージャを示す図である。 ヘルスおよび負荷情報とのトラフィックルーティング相互作用の例示的な動作実施形態を示す図である。 ネットワーク負荷分散インフラストラクチャの例示的な高可用性機構を示す図である。 接続移行を有するアプリケーションレベルネットワーク負荷分散への例示的な手法を示す図である。 第１装置から第２装置に接続を移行する例示的な方法を示すフローチャートである。 送信元装置の観点からの接続移行に対する例示的な手法を示す図である。 ターゲット装置の観点からの接続移行に対する例示的な手法を示す図である。 接続移行に関するオフロードプロシージャへの例示的な手法を示す図である。 接続移行に関するアップロードプロシージャへの例示的な手法を示す図である。 フォワーダとホストの間のパケットトンネリングに対する例示的な手法を示す図である。 第１装置と第２装置の間のパケットトンネリングの例示的な方法を示すフローチャートである。 本明細書に記載のネットワーク負荷分散の少なくとも１つの態様を実施することができる（完全にまたは部分的に）例示的なコンピューティング（または一般装置）動作環境を示す図である。

符号の説明

１０２ クライアント
１０４ ネットワーク
１０６ 負荷分散インフラストラクチャ
１０８ ホスト
２０１ ルータ／スイッチ
３０２ フォワーダ
３０４ クラスファイア

Claims (58)

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. 前記プログラムは、実行されたとき、前記コンピューティングシステムに、
    前記パケットの受信に応答してキャッシングされたホスト状態情報を調べる動作と
    をさらに実行させ、前記決定する動作は、
    前記調べる動作に応答して、前記複数のアプリケーションの中から前記アプリケーションを選択する動作を含むことを特徴とする請求項２６に記載のコンピュータ読み取り可能な記録媒体。
28. 前記パケットは、特定のアプリケーション種類に関連することを特徴とする請求項２７に記載のコンピュータ読み取り可能な記録媒体。
29. 前記決定する動作は、前記ホスト状態情報に応答して、複数のアプリケーションエンドポイントの中からアプリケーションエンドポイントを選択する動作を含むことを特徴とする請求項１に記載のコンピュータ読み取り可能な記録媒体。
30. 前記決定する動作は、前記ホスト状態情報に応答して、複数のホストの間で分散される複数のアプリケーションエンドポイントの中からアプリケーションエンドポイントを選択する動作を含むことを特徴とする請求項１に記載のコンピュータ読み取り可能な記録媒体。
31. 前記決定する動作は、前記ホスト状態情報に応答して、複数のアプリケーションエンドポイントの間またはその中の相対容量に関して前記複数のアプリケーションエンドポイントの中からアプリケーションエンドポイントの割当を選択する動作を含むことを特徴とする請求項１に記載のコンピュータ読み取り可能な記録媒体。
32. 前記決定する動作は、トークン割当方式を使用してアプリケーションエンドポイントの前記割当を選択する動作を含むことを特徴とする請求項１に記載のコンピュータ読み取り可能な記録媒体。
33. 前記決定する動作は、パーセンテージ割当方式を使用してアプリケーションエンドポイントの前記割当を選択する動作を含むことを特徴とする請求項１に記載のコンピュータ読み取り可能な記録媒体。
34. 前記複数のアプリケーションエンドポイントは、単一のアプリケーション種類のアプリケーションに対応することを特徴とする請求項３１に記載のコンピュータ読み取り可能な記録媒体。
35. 前記決定する動作は、入力パケットによって引き起こされるネットワーク負荷を分散するために、前記ヘルスおよび負荷情報に応答して前記複数のアプリケーションの中から前記アプリケーションを選択する動作を含むことを特徴とする請求項１に記載のコンピュータ読み取り可能な記録媒体。
36. 少なくとも１つのプロセッサと、
    前記少なくとも１つのプロセッサによって実行することができるコンピュータ実行可能命令を含む１つまたは複数のコンピュータ読み取り可能な記録媒体とを含むシステムであって、前記コンピュータ実行可能命令は、前記プロセッサに、
    複数のアプリケーションを備えるホストが、前記ホストで動作するアプリケーションの状態に関するホスト状態情報を判定する動作であって、前記ホスト状態情報は、複数のエントリを含むヘルス及び負荷テーブルを含み、前記複数のエントリの各々は前記複数のアプリケーションのうちでそれぞれ異なるアプリケーションに関連付けられ、複数のエントリの各々は、
    複数のアプリケーションのうちの特定のアプリケーションを一意に識別するためのアプリケーション識別子と、
    前記特定のアプリケーションの状態を表すアプリケーション状態特性情報であって、前記特定のアプリケーションの状態が健全、障害、または未知のどれであるかを表すアプリケーションヘルスと、前記特定のアプリケーションがどれほど占有されているかを示すアプリケーション負荷と、前記特定のアプリケーションの最大容量を示すアプリケーション容量とを含む、アプリケーション状態特性情報と、
    前記特定のアプリケーションについて、負荷分散インフラストラクチャを有する負荷分散ユニットが行わなければいけないことを判定するための少なくとも１つの負荷分散命令と
    を含む、動作と、
    少なくとも１つのホストと少なくとも１つの負荷分散ユニットとの間でメッセージプロトコルを実装し、前記メッセージプロトコルを使用して前記少なくとも１つのホストと前記少なくとも１つの負荷分散ユニットとの間で通信する動作であって、前記通信する動作は、
    前記少なくとも１つのホストの各々が、前記少なくとも１つの負荷分散ユニットに前記ホスト状態情報を送信する動作と、
    前記少なくとも１つの負荷分散ユニットが、前記少なくとも１つのホストから送信されたホスト状態情報を受信する動作と、
    を含む、動作と、
    前記少なくとも１つの負荷分散ユニットが、該受信したホスト状態情報を統合ヘルスおよび負荷キャッシュにキャッシングする動作と、
    前記少なくとも１つの負荷分散ユニットが、接続をリクエストするパケットを受信する動作と、
    前記少なくとも１つの負荷分散ユニットが、前記負荷分散インフラストラクチャを用いて、前記ホスト状態情報に基づいてどのホストに前記パケットを送信するかを決定する動作と
    を実行させるように適合され、
    前記通信する動作は、
    前記少なくとも１つのホストが、前記少なくとも１つのホストが機能していることを示すためのハートビートメッセージを前記少なくとも１つの負荷分散ユニットに送信する動作であって、前記ハートビートメッセージは、エラー検査データを含み、前記エラー検査データは、前記少なくとも１つの負荷分散ユニットにおける前記統合ヘルスおよび負荷キャッシュが前記少なくとも１つのホストにおける前記ヘルス及び負荷テーブルと同期しているかを検証するために使用される、動作と、
    前記少なくとも１つの負荷分散ユニットが、前記エラー検査データにより前記統合ヘルスおよび負荷キャッシュが前記ヘルス及び負荷テーブルと同期していないことが検証されたホストにテーブルスナップショット取得メッセージを送信する動作であって、前記テーブルスナップショット取得メッセージは、前記少なくとも１つのホストの現在のヘルス及び負荷テーブルのスナップショットを供給することをリクエストする、動作と
    を含み、
    前記ホスト状態情報を送信する動作は、
    前記テーブルスナップショット取得メッセージを受信した後に、前記テーブルスナップショット取得メッセージを送信した負荷分散ユニットにテーブルスナップショット送信メッセージを送信する動作であって、前記テーブルスナップショット送信メッセージは、前記少なくとも１つのホストの前記現在のヘルス及び負荷テーブルのスナップショットを含む、動作を含み、
    前記ホスト状態情報を受信する動作は、前記テーブルスナップショット送信メッセージを受信する動作を含むことを特徴とするシステム。
37. 前記ホスト状態情報を受信する動作は、少なくとも１つのプロキシを介して複数のホストから前記ホスト状態情報を受信する動作を含むことを特徴とする請求項３６に記載のシステム。
38. 前記ホスト状態情報を受信する動作は、１つまたは複数のアプリケーションプログラミングインターフェース（ＡＰＩ）を呼び出している少なくとも１つのプロキシを介して複数のホストから前記負荷分散命令を受信し、前記負荷分散命令をプッシュする動作を含むことを特徴とする請求項３６に記載のシステム。
39. ホストのホスト状態情報を判定するように適合されたホスト状態情報デターミナと、
    前記ホスト状態情報を負荷分散インフラストラクチャに配布するように適合されたホスト状態情報ディセミネータと
    を含むことを特徴とする請求項３６に記載のシステム。
40. 前記ホスト状態情報デターミナは、前記１つまたは複数のアプリケーションに関して前記ホスト状態情報を判定することを特徴とする請求項３９に記載のシステム。
41. 前記アプリケーション識別子は、仮想インターネットプロトコル（ＩＰ）アドレスおよびポート、物理ＩＰアドレスおよびポート、前記特定のアプリケーションに関連するプロトコル、ならびに前記プロトコルに固有の情報の少なくとも１つを含むことを特徴とする請求項３６に記載のシステム。
42. 前記アプリケーション識別子は、少なくとも１つのグローバル一意識別子（ＧＵＩＤ）を含むことを特徴とする請求項３６に記載のシステム。
43. 前記特定のアプリケーションの前記最大容量は、前記システム内で実行されつつある前記特定のアプリケーションの種類と同一の種類のアプリケーションの総容量に関して表現されることを特徴とする請求項３６に記載のシステム。
44. 前記特定のアプリケーションの前記最大容量は、無単位の有界数として表現されることを特徴とする請求項３６に記載のシステム。
45. 前記少なくとも１つの負荷分散命令は、前記特定のアプリケーションに関するおよび同一のアプリケーション種類の他のアプリケーションに関するネットワーク負荷分散のガイダンスを提供するために複数の負荷分散ユニットに供給され得ることを特徴とする請求項３６に記載のシステム。
46. 前記少なくとも１つの負荷分散命令は、アクティブ、非アクティブ、および排出中の少なくとも１つを含むことを特徴とする請求項３６に記載のシステム。
47. 前記少なくとも１つの負荷分散命令は、ターゲット負荷分散状態命令および現在負荷分散状態命令を含むことを特徴とする請求項４６に記載のシステム。
48. 前記ターゲット負荷分散状態命令は、前記少なくとも１つのホストに位置するヘルスおよび負荷インフラストラクチャが、複数の負荷分散ユニットに位置するヘルスおよび負荷インフラストラクチャがその下で動作することを意図する負荷分散状態を示すことを特徴とする請求項４７に記載のシステム。
49. 前記現在負荷分散状態命令は、前記少なくとも１つのホストに位置するヘルスおよび負荷インフラストラクチャが、複数の負荷分散ユニットに位置するヘルスおよび負荷インフラストラクチャが現在その下で動作しているとみなす負荷分散状態を示すことを特徴とする請求項４８に記載のシステム。
50. 前記統合ヘルスおよび負荷キャッシュは、複数のホストで実行中の前記複数のアプリケーションに関するアプリケーション固有のヘルスおよび負荷情報を記憶することを特徴とする請求項３６に記載のシステム。
51. 前記アプリケーション固有のヘルスおよび負荷情報は、アプリケーションエンドポイント固有のヘルスおよび負荷情報を含むことを特徴とする請求項５０に記載のシステム。
52. 前記ヘルスおよび負荷インフラストラクチャの少なくとも一部を含むプロキシ装置であって、前記ヘルスおよび負荷インフラストラクチャの前記少なくとも一部は、外部監視動作を実行することによって前記アプリケーション固有のヘルスおよび負荷情報を判定するように適合される、プロキシ装置をさらに含むことを特徴とする請求項５１に記載のシステム。
53. 前記メッセージプロトコルは、ハートビートメッセージ種類、グッドバイメッセージ種類、行チェンジメッセージ種類、テーブルスナップショット取得メッセージ種類、テーブルスナップショット送信メッセージ種類、テーブル状態仮定メッセージ種類、および誤仮定メッセージ種類の１つまたは複数を含むことを特徴とする請求項５２に記載のシステム。
54. 前記メッセージプロトコルは、グループメンバシップを使用して通信する能力を含むことを特徴とする請求項５２に記載のシステム。
55. 前記負荷分散インフラストラクチャは、さらに、１つまたは複数の割当方式を使用して前記複数のアプリケーションにリクエストを割り当てるように適合されることを特徴とする請求項３６に記載のシステム。
56. 前記１つまたは複数の割当方式は、トークン割当方式およびパーセンテージ割当方式の少なくとも１つを含むことを特徴とする請求項５５に記載のシステム。
57. 前記１つまたは複数の割当方式は、タイマ満了機構を使用することを含むことを特徴とする請求項５５に記載のシステム。
58. ネットワーク負荷分散に関する方法であって、
    複数のアプリケーションを備えるホストが、前記ホストで動作するアプリケーションの状態に関するホスト状態情報を判定するステップであって、前記ホスト状態情報は、複数のエントリを含むヘルス及び負荷テーブルを含み、前記複数のエントリの各々は前記複数のアプリケーションのうちでそれぞれ異なるアプリケーションに関連付けられ、複数のエントリの各々は、
    複数のアプリケーションのうちの特定のアプリケーションを一意に識別するためのアプリケーション識別子と、
    前記特定のアプリケーションの状態を表すアプリケーション状態特性情報であって、前記特定のアプリケーションの状態が健全、障害、または未知のどれであるかを表すアプリケーションヘルスと、前記特定のアプリケーションがどれほど占有されているかを示すアプリケーション負荷と、前記特定のアプリケーションの最大容量を示すアプリケーション容量とを含む、アプリケーション状態特性情報と、
    前記特定のアプリケーションについて、負荷分散インフラストラクチャを有する負荷分散ユニットが行わなければいけないことを判定するための負荷分散命令と
    を含む、ステップと、
    少なくとも１つのホストと少なくとも１つの負荷分散ユニットとの間でメッセージプロトコルを実装し、前記メッセージプロトコルを使用して前記少なくとも１つのホストと前記少なくとも１つの負荷分散ユニットとの間で通信するステップであって、前記通信するステップは、
    前記少なくとも１つのホストの各々が、前記少なくとも１つの負荷分散ユニットに前記ホスト状態情報を送信するステップと、
    前記少なくとも１つの負荷分散ユニットが、前記少なくとも１つのホストから送信されたホスト状態情報を受信するステップと
    を含む、ステップと、
    前記少なくとも１つの負荷分散ユニットが、該受信したホスト状態情報を統合ヘルスおよび負荷キャッシュにキャッシングするステップと、
    前記少なくとも１つの負荷分散ユニットが、新しい接続をリクエストするパケットを受信するステップと、
    前記少なくとも１つの負荷分散ユニットが、前記負荷分散インフラストラクチャを用いて、前記ホスト状態情報に基づいてどのホストに前記パケットを送信するかを決定するステップと
    を備え、
    前記通信するステップは、
    前記少なくとも１つのホストが、前記少なくとも１つのホストが機能していることを示すためのハートビートメッセージを前記少なくとも１つの負荷分散ユニットに送信するステップであって、前記ハートビートメッセージは、エラー検査データを含み、前記エラー検査データは、前記少なくとも１つの負荷分散ユニットにおける前記統合ヘルスおよび負荷キャッシュが前記少なくとも１つのホストにおける前記ヘルス及び負荷テーブルと同期しているかを検証するために使用される、ステップと、
    前記少なくとも１つの負荷分散ユニットが、前記エラー検査データにより前記統合ヘルスおよび負荷キャッシュが前記ヘルス及び負荷テーブルと同期していないことが検証されたホストにテーブルスナップショット取得メッセージを送信するステップであって、前記テーブルスナップショット取得メッセージは、前記少なくとも１つのホストの現在のヘルス及び負荷テーブルのスナップショットを供給することをリクエストする、ステップと
    を含み、
    前記ホスト状態情報を送信するステップは、
    前記テーブルスナップショット取得メッセージを受信した後に、前記テーブルスナップショット取得メッセージを送信した負荷分散ユニットにテーブルスナップショット送信メッセージを送信するステップであって、前記テーブルスナップショット送信メッセージは、前記少なくとも１つのホストの前記現在のヘルス及び負荷テーブルのスナップショットを含む、ステップを含み、
    前記ホスト状態情報を受信するステップは、前記テーブルスナップショット送信メッセージを受信するステップを含むことを特徴とする方法。

Images