About Load Balancing

Overview

Load balancing refers to distributing incoming traffic dynamically across a group of backend servers. Load balancers handle this load balancing.

A load balancer is a service or application that sits between incoming client requests and the backend servers. It is configured to receive requests from a single URL, which is publicly exposed and secured via SSL. Thus, it acts as a primary point of contact for all incoming requests.

Load balancers internally route data to each of the servers in a cluster architecture. The following document discusses and explains common uses for a load balancer in Decisions-based server architecture.

Note:

All the configurations for load distribution must be done at the Load balancer. There are no configurations for load distribution at the Decisions server. For more information refer to Setting up a Cluster server.

When choosing a Load balancer, there are two key points to consider:

Cookie-Based Session Persistence

Session persistence, specifically cookie-based, ensures that a user's requests are consistently directed to the same backend server throughout their session. It associates a unique identifier (cookie) with a user, allowing the load balancer to maintain the user's session state.

Why do Decisions need Session Persistence?

Decisions use Cookie-Based Session Persistence to maintain data during user interactions. For instance, when a user fills out a Form, it ensures a stable connection to the server. Without it, the user might be directed to different servers, risking data loss in the Form. Session persistence achieves this by associating a unique session identifier (usually stored in a cookie) with the user. The load balancer uses this identifier to consistently route the user's requests to the same server, preserving their session state.

WebSocket Support

WebSocket is a two-way communication protocol that enables both the client and server to exchange messages in real-time using a continuous connection. This is different from conventional HTTP, where one end sends a request, and the other end responds. In contrast, WebSocket provides a more effective way of exchanging information instantly and continuously between client and server.

Why do Decisions need WebSockets?

WebSockets are used to maintain sticky sessions, allowing multiple events to be sent from the server to the client more quickly.

WebSocket URL: [PortalBaseURL]/events

The following table lists a few of the Load balancers that support Cookie-based session persistence and WebSocket.

SSL (Secured Socket Layer) Termination at Load Balancer

SSL Termination or SSL Offloading is removing the SSL-based encryption from incoming traffic at the Load balancer and sending the decrypted request to the servers. This reduces the computational work of the servers to increase their efficiency.

While offloading SSL, the https to http redirection must be configured at Load Balancer and not on the Decisions server.

If SSL is Terminated at the Load Balancer

Users can install Decisions without adding any SSL certificate to the application server. This will allow the servers to receive requests only in http. Thus, it is important to configure the following settings in settings.xml.

• Ensure that the EnableHttp is set to true in Settings.xml.
  
  

• When SSL is terminated the servers send requests in HTTP to the load balancer, but the load balancer (LB) is set up to accept only HTTPS, then ForceBaseURI helps to send specific data in HTTPS. Users must add the following settings to Settings.xml.

<ForceBaseURI>LoadBalancerURL</ForceBaseURI>

Configuring Health Check

Load balancers monitor the status of application servers with a health probe. The health probe adds or removes servers/VMs from the load balancer based on their response to health checks. The app server Health Monitor, or HealthCheck, provides a summary of the overall health of the platform. For more information, refer to the article App Server Health Monitor.

HealthCheck URL: [PortalBaseURL]/home/healthcheck