About Load Balancing

Updated on 24 Aug 2022
1 Minute to read

Print
Share
Dark
Light

Article Summary

Share feedback

Thanks for sharing your feedback!

Load balancers are commonly deployed when multiple application servers are used with Decisions. A load balancer acts as a primary point of contact so that all application servers appear the same to end-users.

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

IMPORTANT

Decisions requires STICKY SESSIONS for load balancer configuration to make sure a user's session interacts with the same server within the cluster for the duration of the session.

If available, Cookie Based Session Persistence is recommended; this uses a cookie to uniquely identify a session and later reference that cookie to push the connection to the appropriate server.

SSL Termination

The use of SSL Termination at the load balancer is recommended. If HTTP Redirect is being used, it must be configured at the load balancer, not on the Decisions Servers.

The following sections outline the requirements for each specific configuration.

Backend Pool of VMs with IIS/Decisions Application

Configured as a Decisions Cluster
No SSL Termination on the IIS side (termination is completed on the AAG)
- SSL Offloading
- Increased performance from backend pool to AAG

Azure Application Gateway

SSL Termination
HealthCheck configuration
HTTP/HTTPS redirect/rules configuration
HTTP/2
Requires separate Virtual Networks within the same address space of the backend pool
Cookie Session Affinity configuration

Decisions Configuration Supporting AAG

Requires configuration for Cookie Affinity

For further information on Installation, visit the Decisions Forum.

Was this article helpful?

What's Next

Load Balancer Health Probes

Table of contents

SSL Termination
Azure Application Gateway/Cookie-Based Session