Load Balancer Session Persistence
Use session persistence with a load balancer to direct all requests originating from a single logical client to a single backend web server.
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.
You enable session persistence when you create a load balancer or when you create a backend set. You can also edit an existing backend set to enable, disable, or change the session persistence configuration.
Sticky Cookies
The Load Balancer service offers two mutually exclusive cookie-based configurations for enabling session persistence:
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.
Application Cookie Stickiness
To configure application cookie session persistence, you specify a cookie name and decide whether to disable fallback for unavailable servers.
The Load Balancer service activates application cookie session persistence (stickiness) 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.
Requirements:
- Your load balancer must operate in HTTP mode to support server side, cookie-driven session persistence.
- The client computer must accept cookies for Load Balancer session persistence feature to work.
The Load Balancer 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 later 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.
We recommend that you treat cookie data as an opaque entity. Don't use it in your applications.
The backend server can stop application cookie persistence by deleting 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 Balancer service routes later requests using the configured load balancing policy.
Load Balancer Cookie Stickiness
When you configure load balancer cookie stickiness, the load balancer inserts a cookie into the response. The parameters configured within the cookie enable session stickiness. This method is useful when you have applications and web backend services that can't generate their own cookies.
To configure load balancer cookie session persistence, you specify:
- The cookie name.
If you don't specify a cookie name, the default name is
X-Oracle-BMC-LBS-Route.Note
Ensure that the cookie name used at the backend application servers is different from the cookie name used at the load balancer. To minimize the chance of name collision, We recommend that you use a prefix such asX-Oracle-OCI-.If both a backend server and the load balancer insert cookies with the same name, the client or browser behavior can vary depending on the domain value associated with the cookie. If the name and domain values of the
Set-cookieheader (generated by a backend server) and theSet-cookieheader (generated by the load balancer) are the same, the client or browser treats them as one cookie. The client returns only one of the cookie values in later requests. If bothSet-cookienames are the same, but the domain names are different, the client or browser treats them as two different cookies. - The domain in which the cookie is valid. The
Set-cookieheader inserted by the load balancer contains a domain attribute with the specified value.This attribute has no default value. If you don't specify a value, the load balancer doesn't insert the domain attribute into the
Set-cookieheader.Note
- RFC 6265 - HTTP State Management Mechanism describes client and browser behavior when the domain attribute is present or not present in the
Set-cookieheader.If the value of the
Domainattribute isexample.comin theSet-cookieheader, the client includes the same cookie in theCookieheader when making HTTP requests toexample.com,www.example.com, andwww.abc.example.com. If theDomainattribute isn't present, the client returns the cookie only for the domain to which the original request was made. - Ensure that this attribute specifies the correct domain value. If the
Domainattribute in theSet-cookieheader doesn't include the domain to which the original request was made, the client or browser might reject the cookie. As specified in RFC 6265, the client accepts a cookie with theDomainattribute valueexample.comorwww.example.comsent fromwww.example.com. It doesn't accept a cookie with theDomainattributeabc.example.comorwww.abc.example.comsent fromwww.example.com.
- RFC 6265 - HTTP State Management Mechanism describes client and browser behavior when the domain attribute is present or not present in the
- The URI path in which the cookie is valid. The
Set-cookieheader inserted by the load balancer contains aPathattribute with the specified value.Clients include the cookie in an HTTP request only if the path portion of the
request-urimatches, or is a subdirectory of, the cookie'sPathattribute.The default value is `/`.
- The amount of time the cookie remains valid. The
Set-cookieheader inserted by the load balancer contains aMax-Ageattribute with the specified value.The specified value must be at least one second. No default value for this attribute exists. If you do not specify a value, the load balancer does not include the
Max-Ageattribute in theSet-cookieheader. Usually, the client or browser retains the cookie until the current session ends, as defined by the client. - Whether the
Set-cookieheader should contain theSecureattribute. TheSecureattribute directs the client or browser to send the cookie only using a secure protocol.Note
If you set this field to true, you can't associate the corresponding backend set with an HTTP listener.
- Whether the
Set-cookieheader should contain theHttpOnlyattribute. TheHttpOnlyattribute limits the scope of the cookie to HTTP requests. This attribute directs the client or browser to omit the cookie when providing access to cookies through non-HTTP APIs. For example, it restricts the cookie from JavaScript channels. - Whether to disable fallback for unavailable servers.
Path route rules take precedence to decide the target backend server. The load balancer verifies that session stickiness is enabled for the backend server and that the cookie configuration is valid for the target. The system ignores invalid cookies.
Fallback
By default, the Load Balancer 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 Balancer service considers a server marked drain available for existing persisted sessions. New requests that aren't part of an existing persisted session aren't sent to that server.