Session persistence is a method to direct all requests originating from a single logical client to a single backend web server. Backend servers that use caching to improve performance, or to enable log-in sessions or shopping carts, can benefit from session persistence.
Your load balancer must operate in HTTP mode to support server side, cookie-driven session persistence. You can enable the session persistence feature when you create a backend set. To configure session persistence, you specify a cookie name and decide whether to disable fallback for unavailable servers. You can edit an existing backend set to change the session persistence configuration.
The Load Balancing service activates session persistence when a backend server sends a
Set-Cookie response header containing a recognized cookie name. The cookie name must match the name specified in the backend set configuration. If the configuration specifies a match-all pattern, '*', any cookie set by the server activates session persistence. Unless a backend server activates session persistence, the service follows the load balancing policy specified when you created the load balancer.
The client computer must accept cookies for Load Balancing session persistence feature to work.
The Load Balancing service calculates a hash of the configured cookie and other request parameters, and sends that value to the client in a cookie. The value stored in the cookie enables the service to route subsequent client requests to the correct backend server. If your backend servers change any of the defined cookies, the service recomputes the cookie's value and resends it to the client.
Oracle recommends that you treat cookie data as an opaque entity. Do not use it in your applications.
To stop session persistence, the backend server must delete the session persistence cookie. If you used the match-all pattern, it must delete all cookies. You can delete cookies by sending a
Set-Cookie response header with a past expiration date. The Load Balancing service routes subsequent requests using the configured load balancing policy.
IP Address-driven Session Persistence
Some products offer session persistence support without cookies. These products depend on the IP address of the incoming request. ISP proxies and company exit gateways can issue many requests from a single IP address. In this case, a single backend server can be subject to high traffic volumes. Your backend fleet can become overwhelmed, one server at a time, even though effective load balancing is possible.
Another weakness of IP address-driven session persistence is that the originating IP address can change. In this case, session persistence can be lost or the request redirected to the wrong backend server.
By default, the Load Balancing service directs traffic from a persistent session client to a different backend server when the original server is unavailable. You can configure the backend set to disable this fallback behavior. When you disable fallback, the load balancer fails the request and returns an HTTP 502 code. The service continues to return an HTTP 502 until the client no longer presents a persistent session cookie.
If fallback is disabled, cookies with a distant future expiration date can cause a client outage.
The Load Balancing service considers a server marked
drain available for existing persisted sessions. New requests that are not part of an existing persisted session are not sent to that server.