Persistence settings 编辑

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.

The * in the preceding table refers to the following:

250K sessions per core is the default per packet engine. To configure 1 million session entries per packet engine, run the following command:

set lb parameter -sessionsthreshold <1000000*number of PE>

For a 3 PE system, run the following command:

set lb parameter -sessionsthreshold 3000000

Table 1. Limitations on Number of Simultaneous Persistent Connections

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.

Table 2. Persistence Types Available for Each Type of Virtual Server

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.

Configure persistence based on cookies

When you enable persistence based on cookies, the Citrix ADC appliance 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 ADC 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 Citrix ADC appliance inserts the cookie <NSC_XXXX>= <ServiceIP> <ServicePort>

where:

• <<NSC_XXXX> is the virtual server ID that is derived from the virtual server name.
• <<ServiceIP> is the hexadecimal value of the IP address of the service.
• <<ServicePort> is the hexadecimal value of the port of the service.

If the useEncryptedPersistenceCookie option is enabled, the ADC encrypts ServiceIP and ServicePort using the SHA2 hash algorithm when it inserts a cookie and decrypts when it receives a cookie.

Note: If the client is not allowed to store the HTTP cookie, the subsequent requests do not have the HTTP cookie, and persistence is not honored.

By default, the ADC appliance 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 HTTP cookie version 0 is used, the Citrix ADC appliance inserts the absolute Coordinated Universal Time (GMT) of the cookie’s expiration (the expires attribute of the HTTP cookie), calculated as the sum of the current GMT time on an ADC appliance, and the timeout value.
• If an HTTP cookie version 1 is used, the ADC appliance inserts a relative expiration time (Max-Age attribute of the HTTP cookie). In this case, the client software calculates the actual expiration time.

Note: Most client software currently installed (Microsoft Internet Explorer and Netscape browsers) understand HTTP cookie version 0; however, some HTTP proxies understand HTTP cookie version 1.

If you set the timeout value to 0, the ADC appliance 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 change the HTTP cookie version.

To change the HTTP cookie version by using the CLI

At the command prompt, type;

set ns param [-cookieversion ( 0 | 1 )]
<!--NeedCopy-->