Benefits of load balancing Leostream
Here are a few key benefits of load balancing Leostream:
- Resilience and disaster recovery: Supporting continued user logins in situations when a particular data centre goes down
- High Availability (HA): To ensure your users are always able to log in
- Optimized performance of your connection brokers: When integrated with global and local load balancers
About Leostream
Leostream provides the critical remote desktop connection management technology required for organizations to build successful large-scale remote access solutions for physical, virtual, and cloud-hosted desktops.
It is the industry’s most widely deployed vendor-independent remote desktop connection management solution, enabling enterprises to integrate the complex array of clients, hosting platforms, guest operating systems, and display protocols required for successful VDI, hosted desktop, and application deployments.
Why Loadbalancer.org for Leostream?
Loadbalancer’s intuitive Enterprise Application Delivery Controller (ADC) is designed to save time and money with a clever, not complex, WebUI.
Easily configure, deploy, manage, and maintain our Enterprise load balancer, reducing complexity and the risk of human error. For a difference you can see in just minutes.
And with WAF and GSLB included straight out-of-the-box, there’s no hidden costs, so the prices you see on our website are fully transparent.
More on what’s possible with Loadbalancer.org.
How to load balance Leostream
The load balancer can be deployed in 4 fundamental ways: Layer 4 DR mode, Layer 4 NAT mode, Layer 4 SNAT mode, and Layer 7 Reverse Proxy (Layer 7 SNAT mode).
For Leostream, using Layer 4 DR mode is recommended.
Load balancing and HA requirements
For high availability and scalability, it is recommended that multiple Leostream Gateway servers and multiple Connection Broker servers are deployed in load balanced clusters.
Persistence (aka server affinity)
Source IP address based persistence is required to successfully load balance a Leostream deployment. This is true for load balancing Leostream gateway servers and for load balancing connection brokers.
Virtual service (VIP) requirements
To provide load balancing and HA for Leostream, the following VIP is required:
- Leostream Gateway Service
Optionally, an additional VIP may be required as follows:
- Leostream Connection Broker Service
Port requirements
The focus will be on the following remote protocols:
| Port | Protocols | Use |
|---|---|---|
| 80 | TCP/HTTP | HTTP Logon to Leostream Service |
| 443 | TCP/HTTPS | HTTPS Logon to Leostream Service |
| 3389 | TCP/UDP/RDP | (Optional) Connection to RDP Hosts |
| 42966 | TCP/UDP/HP RGS | (Optional) ZCentral Remote Boost (Formerly HP Remote Graphics Software) |
| 4172 | TCP/UDP/PCoIP | (Optional) PC-over-IP Remote Display Protocol |
| 50001 | TCP/PCoIP | (Optional) PC-over-IP Remote Display Protocol |
| 50002 | TCP/PCoIP | (Optional) PC-over-IP Remote Display Protocol |
Leostream is also compatible with a plethora of other different remote connection protocols. Refer to the guide below for more details.
Deployment architecture
Leostream recommends the deployment of at least a pair of gateways and also (if needed) a pair of connection brokers. This makes the Leostream services highly available; if one of the gateway servers or connection brokers becomes unavailable then there is another server still online, healthy, and able to handle client connections.
In this scenario, we will position the load balancer in front of the gateways and in front of the connection brokers.
Step 1: Authentication (Clustered Leostream Connection Brokers):
Step 2: Authentication (Clustered Leostream Connection Brokers):
About Layer 4 DR mode load balancing
One-arm direct routing (DR) mode is a very high performance solution that requires little change to your existing infrastructure.
DR mode works by changing the destination MAC address of the incoming packet to match the selected Real Server on the fly which is very fast.
When the packet reaches the Real Server it expects the Real Server to own the Virtual Services IP address (VIP). This means that you need to ensure that the Real Server (and the load balanced application) respond to both the Real Server’s own IP address and the VIP.
The Real Servers should not respond to ARP requests for the VIP. Only the load balancer should do this. Configuring the Real Servers in this way is referred to as Solving the ARP problem.
On average, DR mode is 8 times quicker than NAT for HTTP, 50 times quicker for Terminal Services and much, much faster for streaming media or FTP.
The load balancer must have an Interface in the same subnet as the Real Servers to ensure Layer 2 connectivity required for DR mode to work.
The VIP can be brought up on the same subnet as the Real Servers, or on a different subnet provided that the load balancer has an interface in that subnet.
Port translation is not possible with DR mode, e.g. VIP:80 → RIP:8080 is not supported. DR mode is transparent, i.e. the Real Server will see the source IP address of the client.
