Back in July, we were contacted to see if we could assist with a customer implementing our load balancer for a suite of products supplied by Leostream. So, here I will take a look at how a load balancer can be utilised to provide high availability for this solution.
With the current rise in remote working, companies have been looking for solutions that allow their remote workers to work from home while being as productive as if they were sitting at a desk in an office. For a lot of us, a laptop and a solid VPN is all we need to be able to do our job, while others may use very specific software and high-end workstations (such as video editors), where a laptop and VPN simply don’t cut it. Sure, they “could” take the workstation home with them, but who wants the pressure of transporting and storing a machine worth £1000s that isn’t their own? Enter the world of “Virtual Desktop Infrastructure” (VDI) or “Remote Desktop Protocol” (RDP). There are multiple products that supply such technology, such as Leostream, Citrix, and VMWare Horizon.
The Leostream platform is a suite of products designed to provide end-users with consistent and reliable access to desktops from a wide range of client devices. At its core, Leostream provides a connection broker and remote access gateway which provide you with the tools to build a completely customisable VDI solution to your specific business needs.
What this means in layman’s terms is that by using the Leostream suite, you can allow your remote workers to access their desktops remotely, just as if they were there in the office.
I mentioned VMWare Horizon and Citrix above. Where Leostream differs from these offerings is that VMWare Horizon and Citrix are both classed as full-stack VDI solutions. By that, I mean the products include:
- A hypervisor
- A connection broker
- A display protocol
- OS streaming or refreshes
- A remote access gateway
- User environment management software
This makes both of these products very expensive.
Where Leostream differs is that it only provides you with the connection broker and remote access gateway. You then get to pick and choose all of the other options available, making it a very versatile and cost effective solution for your requirements.
Leostream Standard Architecture
In the standard Leostream architecture where a load balancer hasn’t been installed, user authentication and remote desktop connection are handled in 2 separate steps.
Step 1 of the process authenticates the user through login credentials (setup within the connection broker) and the user is then presented with a set of workstations that they can connect to (based on configured policies at the broker).
Step 2 of the process initiates and manages the user’s remote connection to the workstation. When the user disconnects, the connection broker cleans up the connection and frees up the workstation.
As with any engagement, the first thing that we need to do is identify where (if possible) a load balancer should sit. This will almost always depend on where the single points of failure are identified in the infrastructure.
With that in mind, 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.
As a high level overview, I am going to focus on the deployment architecture where there are both dual gateways and brokers deployed.
Step 1 of the process now goes via the gateway virtual service on the loadbalancer. The gateways will then forward the authentication request via the broker virtual service and on to the brokers themselves.
Step 2 of the process will see the remote connection via the gateway virtual service and then on to one of the workstations, which are managed separately by the brokers.
The main requirement from my discussions with the good folk over at Leostream is that we need to ensure that source IP transparency is maintained in a load balanced deployment. This can be achieved in 4 ways with the Loadbalancer.org appliance, by using:
- Layer 4 DR Mode
- Layer 4 NAT Mode
- Layer 7 with X-Forwarded-For (XFF) headers enabled
- Layer 7 with Transparent Proxy (TPROXY) configured
Leostream uses XFF headers within their suite, so straight away this makes option 3 seem like a very good option for implementation. However, certain remote display protocols require the use of both TCP and UDP: this means our layer 7 load balancing solution isn’t a good fit as it’s TCP only. Depending on the remote protocol you’re using, this may mean that a layer 7 solution is entirely out of the question.
With the above in mind, this points us to either option 1 or 2. Keeping in mind that the end use of this service is for a very reliable VDI experience, I recommend going down the Layer 4 DR mode route; DR mode is a rock solid, mature, and extremely fast solution. Just make sure to resolve “the ARP issue” on your real servers.
Going back to the beginning of this blog, the initial ask from the customer was “Can we load balance the Leostream suite?” Following on from our initial discussions with Leostream, our deployment investigation, and testing, the answer to the customer’s question is a resounding yes: yes, we can!
As with a lot of other software deployments, we have a Leostream specific deployment guide to walk you through the specific steps of “how to load balance Leostream”. You should be able to get yourself up and running with a highly available, load balanced Leostream deployment. As always, we’re more than happy to assist you with any issues you might have; feel free to contact our awesome support team.