Content Based Router (CBR) アフィニティー機能は、クライアント IP アドレスをバックエンド・サーバーにマップします。パケットの宛先 IP アドレスがクラスターと一致し、宛先ポートが Load Balancer ポートに一致し、さらにソース IP アドレスが一致すると、アフィニティーが確立されます。
このタスクについて
アフィニティーが確立されると、これ以降のパケットは同じバックエンド・サーバーに送信されます。サーバーのダウンやサーバーの削除が原因でアフィニティーが切断されると、そのサーバーへのアフィニティーしたがって接続がすべて切断されます。
また、コマンド行クライアントまたは GUI クライアントには、接続情報は報告されません。活動中のアフィニティー・レコードの数だけが使用されます。
この方法の利点は、堅固なアフィニティーが得られること、および Load Balancer の効率が向上することにあります。
該当するアフィニティーの方法を使用することで、接続の転送と比較して、メモリー
および CPU の使用率が減少します。
Avoid trouble: アフィニティー・レコードを削除すると接続も切断されるため、Load Balancer for IPv4 から Load Balancer for IPv4 and IPv6 に移行する場合は、最大ステイル・タイムアウト設定に設定した値を Load Balancer for IPv4 and IPv6 のスティッキー時間設定の値として使用する必要があります。
gotcha
CBR コンポーネント
のアフィニティーを、活動 Cookie、受動 Cookie、および URI として指定します。
- 活動 Cookie
- Load Balancer によって生成される Cookie を基にして、アフィニティーをもつ Web トラフィックを同じサーバーにロード・バランシングできます。活動 Cookie アフィニティーに対してルールが使用可能になると、同じクライアントからの正常に実行された要求が最初に選択したサーバーに送信される間に、標準 CBR アルゴリズムを使用して新規クライアント要求のロード・バランスされます。選択したサーバーは、クライアントへの応答で Cookie として保管されます。クライアントの将来の要求に Cookie が入っていて、各要求がスティッキー時間間隔内に到達する限り、クライアントは初期サーバーとのアフィニティーを保守します。
ルール・スティッキーの作成は、通常はサーバー上のクライアント状態を保管する CGI またはサーブレットに使用されます。この状態は、Cookie ID によって識別されます (これがサーバー Cookie です)。クライアント状態は選択したサーバー上にのみ存在するので、
クライアントは要求間で状態を保持するためにそのサーバーからの Cookie を必要とします。
- 受動 cookie
- サーバーによって生成される自己識別 Cookie を基にして、アフィニティーをもつ Web トラフィックを同じサーバーにロード・バランシングできます。受動 cookie アフィニティーが使用可能になっている場合は、Load Balancer はクライアント要求の HTTP ヘッダー中の cookie 名に基づいてサーバーを選択します。
Load Balancer は、
Cookie 値にクライアントの Cookie 名を含んでいるサーバーを初めて見つけると、
要求に対してそのサーバーを選択します。クライアント要求中の cookie 名が見つからないか、サーバーの cookie 値の内容のいずれとも一致しない場合は、サーバーは既存のサーバー選択か重み付きラウンドロビン技法を使用して選択されます。
- URI
- URI アフィニティーによって、固有のコンテンツを個々の各サーバーにキャッシュできる、Caching Proxy サーバーに対して Web トラフィックをロード・バランシングできます。この結果として、サイトのキャッシュの容量は、複数のマシン上のコンテンツの冗長なキャッシュを除去することによって、効果的に増加することになります。
これは、非常に多様なコンテンツを持つ Web サイトが中程度の量のクライアント・トラフィック
をサポートしていて、複数のサーバーにわたって比較的大きなキャッシュを備えるようにしたいといったシナリオに効果的です。
affinity オプションのデフォルトは none です。