Load balancing Concepts

https://docs.citrix.com/en-us/netscaler/11/traffic-management/load-balancing/load-balancing-persistence/source-ip-persistence.html

https://docs.citrix.com/en-us/netscaler/11/traffic-management/load-balancing/load-balancing-persistence/http-cookie-persistence.html

Netscalar Concepts

https://www.citrix.com/blogs/2010/06/01/configuring-verifying-and-monitoring-persistence-on-netscaler/

What is persistence in Server Load Balancing?

Before understanding what persistence is, let us get an overview of Server Load balancing (SLB). The SLB feature selects a server (service to be precise) from a set of configured servers to serve a client request based on a load balancing algorithm configured by an administrator.

In Figure 1, user B’s first request can be served by one of the servers – Server 1, Server 2, or Server 3. Let us say Server 2 is selected by SLB. Once a server is selected, persistence will tie the user to the selected server, so in this case user B is tied to Server 2.

Why is persistence required?

Applications which work based on transaction states (stateful transaction) require persistence. For example, banking portal applications are interactive programs based on user input and selections. User logs on by providing a username and password. Once logged on, the user can do a variety of tasks, such as checking account balance, transferring fund, etc. If persistence is not configured, user might have authenticated with Server 1, but his/her next request (say transferring fund) may go to Server 2 or Server 3. In this case, the application will reject the user request since Server 2 or Server 3 does not have user’s transaction state & authentication details. If appropriate persistence is configured (Cookie in this e.g.), all subsequent requests will be directed to the server which got selected in the first request. In this example, all requests will be forwarded to Server 2. Persistence can be configured for the following protocols: HTTP, SSL, IP, TCP, UDP, SIP, and RTSP.

How long is persistence valid once a user is tied to the server (service)?

Based on the application requirement, the administrator can configure persistence interval along with persistence type.

What are different types of persistence?

NetScaler supports 10 persistence types. To get the best utilization of servers, network, and NetScaler, it is very important to choose the right persistence type based on the deployment scenario (Server Load Balancing, Firewall Load balancing, etc.) and the traffic pattern. Some persistence types, (such as Source IP and SIP CallID), take NS memory to store persistence information while other persistence types (such as Cookie, URL Passive, and Custom Server ID) do not take any memory to store persistence information. Persistence information is derived from the request.

Following table shows the commonly used persistence types and the supported protocols.

In the above table, protocols marked with GREEN are recommended as they can give the best NetScaler resource utilization in terms of CPU and memory. For example, Cookie persistence type is well suited for HTTP & HTTPS as it does not take NetScaler memory to store persistence details. Persistence details are encoded in the Cookie generated by the NetScaler. For IP/TCP/UDP traffic, Source IP persistence type is well suited and it uses NetScaler memory to store persistence information.

Let us see how to configure and debug two most commonly used persistence types, Cookie persistence and Source IP persistence. NetScaler provides options to configure persistence by using the command line interface (CLI), Graphical User Interface (GUI), and XML-API

To configure Cookie persistence by using the CLI, enter the following commands:

To verify the cookie value of a service, enter the show lb vserver V1 command.

Cookie value of S1 = NSC_W1=ffffffffcbc3c71045525d5f4f58455e445a4a423660
Cookie value of S2 = NSC_W1=ffffffffcbc3c71345525d5f4f58455e445a4a423660
Cookie value of S3 = NSC_W1=ffffffffcbc3c71245525d5f4f58455e445a4a423660

To verify how cookie persistence works, send HTTP requests from a client. Before sending a request, capture the Service selection counter and Cookie persistence counter by entering the nsconmsg -i V1 -s ConLb=1 -d oldconmsg command at the NetScaler shell prompt.

Counter ‘Hits’ marked in Yellow, gives the number of HTTP requests vserver V1 received, Counter ‘Hits’ marked in Green gives the number of requests this service served and Counter ‘P’ marked in Rose gives persistent requests served by this service. Since vserver V1 did not serve any traffic all the counters are ‘0’.

Now send six HTTP requests from client’s browser (cookie cache enabled) and check cookie persistence.

You can see due to cookie persistence all the 6 (Hits) requests from the client goes to service (S2) 200.203.217.2 and Persistence counter ‘P’ of S2 is 5 (first request is load balanced and subsequent 5 requests are served by S2 due to cookie persistence).

How to debug cookie persistence?

If you think cookie persistence is not working properly, check the vserver “Hit’ counter, service ‘Hit’ counter, and ‘P’ counter in the nsconmsg output as explained above. Make sure cookie caching is enabled in client’s web browser. If cookie caching is enabled, make sure that the cookie value stored in the browser cache is not corrupted by comparing it against the cookie value of the services displayed in the show lb vserver output.

How to configure Source IP Persistence?

To configure SourceIP persistence with 5 minute persistence timeout interval, enter the following commands:

Before sending an HTTP request, capture the hits and persistence counter values by entering the nsconmsg -i V1 -s ConLb=1 -d oldconmsg command at the NetScaler shell prompt.

In the above output, all the counters are ‘0’ as no traffic was send to the vserver. Let us pump 10 requests to vserver V1 from Client 2

From the nsconmsg output, you can see that all the requests are served by S1 (Hits=10, P=10). (Note: For SourceIP persistence, counter ‘P’ value can be equal to ‘Hits’ counter value of the service or one less than the ‘Hits’ counter, both the scenarios are correct.)

The show persistentSessions -summary command displays persistence session information. In the following screen capture, you can see persistence session information for source IP 10.102.3.108. If we consider the second show output, at that point of time if a traffic is generated from 10.102.3.108 within 279 minutes, it will go to S1 and the persistence session will be refreshed to be valid for 5 more minutes, but once the persistence session times out (third output), the session information is removed, and any new request will be first load balanced, then a persistence entry will be created and for subsequent requests, persistence will be honored till the session times out.