To ensure stability of stateful applications, load balancers implement persistence which directs all related connections to the same server. Different types of persistence are supported to address different types of application needs.
Some applications maintain the server state such as, shopping carts. Such state can be per client and identified by the client IP address or per HTTP session. Applications can access or modify this state while processing subsequent related connections from the same client or HTTP session.
The source IP persistence profile tracks sessions based on the source IP address. When a client requests a connection to a virtual server that enables the source address persistence, the load balancer checks if that client was previously connected, and if so, returns the client to the same server. If not, the load balancer selects the server pool member based on the pool load balancing algorithm. Source IP persistence profile is used by Layer 4 and Layer 7 virtual servers.
If rule persistence, cookie persistence, and server keep-alive are all configured, the load balancer follows the priority of rule persistence > cookie persistence > server keep-alive.
- Cookie Insert - the load balance inserts its own cookie with the pool member information (encoded or not) in the server response to the client. The client then forwards the received cookies in subsequent requests (NSX cookie included), and the load balancer uses that information to provide the pool member persistence. The NSX cookie is trimmed from the client request when sent to the pool member.
- Cookie Prefix - the load balancer appends the pool member information (encoded or not) in the server response to the client. The client then forwards the received HTTP cookie in subsequent requests (with the NSX prepended information), and the load balancer uses that information to provide the pool member persistence. The NSX cookie prefix is trimmed from the client request when sent to the pool member.
- Cookie Rewrite - the load balancer replace server cookie value with the pool member information (encoded or not) in the server response to the client. The client then forwards the received HTTP cookie in subsequent requests (with the NSX prepended information), and the load balancer uses that information to provide the pool member persistence. The original server cookie is replaced in the client request when sent to the pool member.
The generic persistence profile supports persistence based on the HTTP header, cookie, or URL in the HTTP request. Therefore, it supports application session persistence when the session ID is part of the URL. This profile is not associated with a virtual server directly. Specify this profile when you configure a load balancer rule for request forwarding and response rewrite.