Load Balancer Configuration

In a Thinfinity® Workspace deployment, the Load Balancer serves as the central distribution point for all inbound traffic. In cloud environments, it ensures high availability, efficient session distribution, and continuous health monitoring of backend instances.

Key Functions

• Traffic Distribution: Implements load balancing of HTTPS/TLS traffic across multiple Thinfinity Gateway instances employing defined routing algorithms to enhance resource efficiency and eliminate single points of failure.
• High Availability: Continuously monitors the health status of Gateway nodes using health check mechanisms and dynamically reroutes network traffic away from degraded or non-responsive nodes to operational Gateways, ensuring uninterrupted service continuity.
• Secure Termination: Handles TLS session termination at the network edge, with configurable re-encryption to backend Gateways aligned with security policies to uphold end-to-end data confidentiality.
• Session Management: Facilitates persistent WSS connections, supporting long-duration sessions necessary for Thinfinity Workspace functionalities.
• Health Monitoring: Conducts ongoing health assessments of Gateway and Broker instances utilizing active and passive probing methods to validate operational integrity and maintain session stability.

Best Practices

• Configure HTTPS listeners with TLS 1.2 and TLS 1.3 as minimum versions.
• Utilize valid, trusted digital certificates, ensuring they are renewed and updated periodically.
• Enable WebSocket support by allowing HTTP/1.1 upgrade requests and 101 Switching Protocols responses.
• Set liberal timeout durations (minimum of 30 to 60 minutes) for sustained, long-lived sessions.
• Enable per-node health checks on /__health__/ endpoints for both gateways and brokers.
• In high concurrency deployment scenarios, verify Network Address Translation (NAT) capacity and connection throughput limits to prevent port exhaustion.

Thinfinity-Specific Requirements

The best practices above apply to any load-balanced service. The requirements below are specific to Thinfinity Workspace behaviour — a load balancer that violates any of them will cause observable failures (dropped sessions, 403/405 responses, missing GeoIP data, or health checks that mark healthy nodes as down).

• Pass through the WebSocket upgrade. Allow HTTP/1.1 WebSocket upgrades (Upgrade: websocket → 101 Switching Protocols) without inspection. Session traffic and the /__messaging__ channel use long-lived WebSockets; a load balancer that strips the upgrade or inspects payloads breaks the session connection.
• Set a long idle timeout. Keep the idle timeout above 30 seconds; 3,600 seconds (one hour) is a common operational choice. The pool emits a keep-alive echo every 15 seconds and the Gateway’s inactivity sweep removes channels that are silent for 120 seconds, so an idle timeout shorter than the inactivity window can drop a channel the Gateway still considers healthy.
• Enable sticky sessions when gateways share a public address. When more than one Gateway sits behind a single public address through the load balancer, enable sticky sessions by cookie. Browser authorisations and the /__messaging__ channel live on the Gateway that first received the browser — a later request routed to a different Gateway returns 403 (or 405 for the WebSocket upgrade), and the connection fails.
• Health-check GET /__health__/ with the trailing slash. The Gateway returns 200 OK while the process is running, on primary and Communications Gateways alike. The path must match exactly: /__health__ without the trailing slash isn’t recognized as a health check, and the probe fails. On a Communications Gateway the probe passes the lockdown only because /__health__/ is in [Gateway.Lockdown] AllowEndpointList by default; if you edit that list, keep /__health__/ in it. IP-based filtering, such as GeoIP filtering, also applies to health probes, so make sure the load balancer’s probe addresses aren’t blocked.
• Terminate TLS at the load balancer, then set [Broker] PublicGatewayURL. Gateways do not read X-Forwarded-Proto, so a Gateway behind an HTTPS load balancer has no other way to know the public scheme — the admin tells it by setting [Broker] PublicGatewayURL to the https:// entry URL. Do not configure an HTTP → HTTPS redirect on the Gateway binding the load balancer uses; it would loop with the load balancer’s forwarded HTTP request.
• Preserve the Host header and forward the client IP. Gateways route by hostname and attribute incoming requests by the IP found in X-Forwarded-For (or X-Real-IP). Without those, every browser appears to come from the load balancer’s address, which breaks GeoIP-based routing to Communications Gateways and the [Gateway.Lockdown] AllowIpList filter.

Load Balancer Configuration (Example)

This configuration is based on the parameters for the OCI (Oracle Cloud Infrastructure) load balancer. While other vendors (like AWS, Azure, etc.) may have different options or use different labels, the core configuration principles are the same.

If you have questions about a specific vendor, or if your provider is not covered in our documentation, please contact our support team for assistance.

Component Parameters

Summary

The Load Balancer functions as a vital element within the network infrastructure. It enforces encryption through secure TLS protocols, performs intelligent session distribution via advanced routing algorithms, and continuously monitors backend server health metrics. These mechanisms collectively establish a resilient, high-availability access layer optimized for performance and reliability.