Introduction

Web applications rely on load balancers for high availability, fail-over, and scaling. Client to application communication happens via a load balancer over HTTP/S which is inherently stateless however many times applications require the client state to be maintained throughout a session or for a period of time till a multi-step transaction is completed.

In load balanced environment with multiple application servers in a cluster, maintaining a client state is possible either when the application shares the session state with other servers in the cluster or if all the HTTP requests from a client reach the same backend server throughout a session. The first option (sharing state in the cluster) is pretty complex to implement and is often not supported by applications. A load balancer service comes to rescue. Most of the modern-day load balancers support maintaining a client to server connection by adding session persistence (aka sticky session) in some way.

OCI Load balancer session persistence OCI Load balancer service supports session persistence in two ways

1) Application cookie persistence Session persistence is triggered when a specific cookie of your choice is set by the backend server. The Load Balancing service calculates a hash of the configured cookie and other request parameters, and sends that value to the client in another cookie (let’s call it a sticky session cookie). The value stored in the sticky session 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 re-computes the sticky session cookie's value and resends it to the client.

When using application cookie persistence, if the OCI load balancer service is used at multiple tiers i.e. to load balance traffic between web servers, app servers and data tier, the LB uses the same sticky cookie name and the value may get overwritten by a load balancer service at different tiers. 

2) Load balancer cookie persistence  The load balancer inserts its own sticky cookie independent of the backend server. The session persistence relies on the load balancer sticky session cookie only.

This is simpler, does not depend on a backend server cookie and customers get more control over the ‘sticky’ cookie attributes as they can choose the name, the cookie flags like HTTP only/Secure, and the time for which the stickiness is desired etc.

So, the load balancer cookie session persistence is a better choice in most cases and the remaining post would focus on this option.

Steps to setup and test OCI Load balancer cookie session persistence

Here is a simple setup with an application running on 2 servers in OCI and front ended with an OCI Load balancer service. The sample application is called “helloworld” which prints the server name serving the request.

The load balancer is set to round robin the traffic between these two application instances/servers. To setup session persistence, edit the backend set and under “session persistence” choose “Enable Load Balancer Cookie Persistence”  

 Session Persistence Parameters

Testing

It’s a fairly simple test. Access the application via the Load Balancer Service  

 Notice that as long as the load balancer cookie (X-Oracle-BMC-LBS-Route) is available, all the requests from the same client will reach the same backend server (Server_1 in this case). If the browser is closed and reopened to load the same URL, the request would go to the second server.

Summary

The post discussed the OCI load balancing session persistence feature and shown steps to setup and test this feature.