- Configuring Load Balancing
- Choosing and Configuring Persistence Settings
- Configuring Features to Protect the Load Balancing Configuration
- A Typical Load Balancing Scenario
You must configure persistence on a virtual server if you want to maintain the states of connections on the servers represented by that virtual server (for example, connections used in e-commerce). The appliance then uses the configured load balancing method for the initial selection of a server, but forwards to that same server all subsequent requests from the same client.
If persistence is configured, it overrides the load balancing methods once the server has been selected. If the configured persistence applies to a service that is down, the appliance uses the load balancing methods to select a new service, and the new service becomes persistent for subsequent requests from the client. If the selected service is in an Out Of Service state, it continues to serve the outstanding requests but does not accept new requests or connections. After the shutdown period elapses, the existing connections are closed. The following table lists the types of persistence that you can configure.
|Persistence Type||Persistent Connections|
|Source IP, SSL Session ID, Rule, DESTIP, SRCIPDESTIP||250K|
|CookieInsert, URL passive, Custom Server ID||Memory limit. In case of CookieInsert, if time out is not 0, any number of connections is allowed until limited by memory.|
If the configured persistence cannot be maintained because of a lack of resources on an appliance, the load balancing methods are used for server selection. Persistence is maintained for a configured period of time, depending on the persistence type. Some persistence types are specific to certain virtual servers. The following table shows the relationship.
|Persistence TypeHeader 1||HTTP||HTTPS||TCP||UDP/IP||SSL_Bridge|
|SSL Session ID||NO||YES||NO||NO||YES|
|Custom Server ID||YES||YES||NO||NO||NO|
You can also specify persistence for a group of virtual servers. When you enable persistence on the group, the client requests are directed to the same selected server regardless of which virtual server in the group receives the client request. When the configured time for persistence elapses, any virtual server in the group can be selected for incoming client requests.
Two commonly used persistence types are persistence based on cookies and persistence based on server IDs in URLs.
When you enable persistence based on cookies, the NetScaler adds an HTTP cookie into the Set-Cookie header field of the HTTP response. The cookie contains information about the service to which the HTTP requests must be sent. The client stores the cookie and includes it in all subsequent requests, and the NetScaler uses it to select the service for those requests. You can use this type of persistence on virtual servers of type HTTP or HTTPS.
The NetScaler inserts the cookie <NSC_XXXX>= <ServiceIP> <ServicePort>
The NetScaler encrypts ServiceIP and ServicePort when it inserts a cookie, and decrypts them when it receives a cookie.
By default, the NetScaler sends HTTP cookie version 0, in compliance with the Netscape specification. It can also send version 1, in compliance with RFC 2109.
You can configure a timeout value for persistence that is based on HTTP cookies. Note the following:
If you set the timeout value to 0, the NetScaler does not specify the expiration time, regardless of the HTTP cookie version used. The expiration time then depends on the client software, and such cookies are not valid if that software is shut down. This persistence type does not consume any system resources. Therefore, it can accommodate an unlimited number of persistent clients.
An administrator can use the procedure in the following table to change the HTTP cookie version.
> set lb vserver vserver-LB-1 -persistenceType COOKIEINSERT Done > show lb vserver vserver-LB-1 vserver-LB-1 (10.102.29.60:80) - HTTP Type: ADDRESS . . . Persistence: COOKIEINSERT (version 0) Persistence Timeout: 2 min . . . Done >
The NetScaler can maintain persistence based on the server IDs in the URLs. In a technique called URL passive persistence, the NetScaler extracts the server ID from the server response and embeds it in the URL query of the client request. The server ID is an IP address and port specified as a hexadecimal number. The NetScaler extracts the server ID from subsequent client requests and uses it to select the server.
URL passive persistence requires configuring either a payload expression or a policy infrastructure expression specifying the location of the server ID in the client requests. For more information about expressions, see "Policy Configuration and Reference."
Example: Payload Expression
The expression, URLQUERY contains sid= configures the system to extract the server ID from the URL query of a client request, after matching token sid=. Thus, a request with the URL http://www.citrix.com/index.asp?&sid;=c0a864100050 is directed to the server with the IP address10.102.29.10 and port 80.
The timeout value does not affect this type of persistence, which is maintained as long as the server ID can be extracted from the client requests. This persistence type does not consume any system resources, so it can accommodate an unlimited number of persistent clients.
> set lb vserver vserver-LB-1 -persistenceType URLPASSIVE Done > show lb vserver vserver-LB-1 vserver-LB-1 (10.102.29.60:80) - HTTP Type: ADDRESS . . . Persistence: URLPASSIVE Persistence Timeout: 2 min . . . Done >