一部の顧客環境(通信およびISP)では、単一のサーバーが制御トラフィックとデータトラフィックの両方を処理します。特定のクライアント IP アドレスでは、制御トラフィックとデータトラフィックの両方を同じバックエンドサーバーに送信する必要があります。このため、クライアント認証トラフィックの処理には1つの仮想サーバーが必要で、通常はルールベースの永続性がその上に設定されます。たとえば、radius.req.avp (8) .value.typecast_text_t' などです。データトラフィックを処理する 2 番目の仮想サーバー。通常、SourceIP パーシステンスが設定されています。
以前は、永続性エントリは仮想サーバーに対してローカルでした。複数の仮想サーバーに永続性を適用する必要がある場合は、仮想サーバーを負荷分散グループに追加し、グループに共通の永続性タイプを適用する必要がありました。負荷分散グループにバインドされているすべての仮想サーバが、グループに設定された永続性を継承しているため、この要件は達成できません。
仮想サーバー間の永続性共有機能を使用すると、グループ設定から継承するのではなく、グループ内の仮想サーバーが独自の永続性パラメータを使用できるように、負荷分散グループの新しいuseVserverPersistencyパラメータを設定できます。各仮想サーバーで個別のルールベースの永続性を構成できます。
必要に応じて、グループ内の仮想サーバーの 1 つをメイン仮想サーバーとして指定することもできます。仮想サーバーがメイン仮想サーバーとして指定されている場合、その仮想サーバーだけが永続性エントリを作成します。永続エントリは、グループ内のすべての仮想サーバーによって使用されます。メイン仮想サーバーがダウンしている場合、NetScaler ADCアプライアンスは永続性エントリを作成しません。
注:仮想サーバー間でのパーシステンス共有は、ルールベースの永続性メソッドでのみサポートされます。メンバー仮想サーバーで互換性のあるルールベースの永続性パラメータを設定します。
例:
v1 と v2 がロードバランシンググループにバインドされ、v1 が RADIUS タイプの仮想サーバ、v2 が HTTP タイプの仮想サーバであると仮定します。「Radius.req.avp (8) .value.typecast_text_t」永続性はv1上で構成され、「client.ip.src」はv2上で構成されています。
トラフィックが RADIUS 仮想サーバ v1 を通過すると、評価されたルール文字列に基づいて永続的なエントリが作成されます。その後、トラフィックが HTTP タイプの仮想サーバー v2 に到達すると、v2 はロードバランシンググループの永続性エントリをチェックし、同じ永続セッションを使用してトラフィックを同じバックエンドサーバーに送信します。