About Load Balancing

Overview

Load balancing refers to distributing the incoming traffic dynamically across a group of backend servers. This balancing of the load is handled by “Load Balancers”.

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

Load Balancers internally route data to each of the servers in a Cluster based on configured criteria. 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 level. There are no configurations for load distribution within Decisions.

When choosing a Load balancer, Decisions has two requirements:

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 does 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 the 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 does 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 common Load balancers that support Cookie-based session persistence and WebSocket.

SSL (Secured Socket Layer) Termination at Load Balancer

SSL Termination or SSL Offloading removes SSL-based encryption from incoming traffic at the load balancer and sends the decrypted request to the servers. This reduces the computational work of the servers and increases 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 certificates 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 setting in the 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