Session Persistence

Session persistence, also known as sticky sessions, ensures that consecutive requests from the same client are directed to the same backend server. This is essential for stateful applications that store session data locally on the server rather than in a shared data store.

Why Session Persistence Matters

Many web applications maintain server-side session state including login status, shopping cart contents, and form wizard progress. If a client's requests are distributed across different backends, the client may lose session context, resulting in unexpected logouts, lost data, or application errors.

Session persistence solves this by binding a client to a specific backend for the duration of their session.

Source IP Affinity (Layer 4)

Source IP affinity is the persistence method available for Layer 4 VIPs. The load balancer uses the client's source IP address to determine backend assignment. All connections originating from the same IP address are forwarded to the same backend server.

This method works for any protocol, but it has limitations. Clients behind a shared NAT gateway will all appear to originate from the same IP address, causing uneven distribution. Clients whose IP changes mid-session will be directed to a different backend.

Source IP affinity is configured by selecting the Source IP Hash algorithm on the VIP.

Cookie-Based Persistence (Layer 7)

Cookie-based persistence is available for Layer 7 HTTP/HTTPS VIPs and provides more reliable client identification than IP-based methods. The load balancer uses an HTTP cookie to track backend assignment, ensuring consistent routing regardless of the client's IP address.

Tula supports two cookie persistence modes:

Cookie Insert

In insert mode, the load balancer injects a persistence cookie into the HTTP response. On subsequent requests, the client sends this cookie back, and the load balancer reads it to determine which backend should handle the request. The cookie is transparent to the application. This is the recommended mode for most deployments.

Configuration options:

• Cookie name: The name of the persistence cookie (e.g., SERVERID).
• Secure flag: Set the cookie's Secure attribute to ensure it is only transmitted over HTTPS.
• HttpOnly flag: Prevent client-side JavaScript from accessing the cookie.

Cookie Prefix

In prefix mode, the load balancer prepends a server identifier to an existing application cookie rather than creating a new one. The load balancer adds the prefix on the response path and strips it on the request path, so the application sees its original cookie value unmodified.

Cookie prefix mode requires that the application set a cookie on every response. If the application does not set the expected cookie, persistence will not function.

Session Timeout Configuration

Persistence entries expire after a configurable timeout period. The timeout defines how long the load balancer remembers the client-to-backend binding after the client's last request.

• Too short: Clients may be reassigned to a different backend during periods of inactivity within a single session.
• Too long: Backend server pools become unbalanced because clients remain pinned to specific servers even after their sessions have ended.

A timeout of 30 minutes is a reasonable default for most web applications. Adjust this value based on your application's session lifetime and expected user behavior.

Testing Persistence

To verify that session persistence is functioning correctly:

1. Send multiple requests to the VIP from the same client and confirm that all responses originate from the same backend. Inspect the persistence cookie in the response headers for cookie-based persistence.
2. Open a new browser or clear cookies to simulate a new client, and confirm that the load balancer may assign a different backend.
3. Check the Monitoring > Statistics view in NetMan to verify that traffic distribution reflects the expected persistence behavior.
4. Stop a backend server and verify that affected clients are gracefully reassigned to a healthy backend on their next request.