Load balancing Microsoft Remote Desktop Services (RDS)
Microsoft Remote Desktop Services (RDS) is an industry leading desktop virtualization platforms. It is the successor to Microsoft Terminal Services and facilitates the efficient, flexible and secure deployment of a Windows desktop environment and/or Windowsapplications, to users both locally and remotely.
Loadbalancer.org provides value-add by enabling scalability, high-availability and ease of management to users wishing to load balance their session hosts, connection broker with either session hosts or virtualisation hosts, session hosts with connection broker, gateways and web access servers depending on the infrastructure or operational requirements.
The load balancer is typically used to load balance multiple Connection Brokers, multiple Web Access Servers and multiple Gateway Servers. Session Hosts are normally load balanced by the Connection Brokers, although the load balancer can also be used as detailed in the deployment guide referenced below.
Remote Desktop Services (RDS) protocol table
|Protocol||Ports||Role||Load balancing methods|
|TCP/HTTPS||443||HTTPS (RD Gateway & RD Web Access)||Layer 7|
|UDP||3389||RDP (UDP support was added in RDP v8.0)||Layer 4|
|UDP||3391||RDP for RD Gateway||Layer 4|
Offering performance without limitations, the best-value hardware load balancer on the market supports any environment. Licensed for unlimited throughput, bandwidth and features, upgrading is seamless if your requirements change down the line.
What RDS deployment models/topologies can be load balanced?
We officially support load balancing 6 different deployment scenarios with Microsoft RDS. These are:
- Stand alone session hosts: Load balance RD session host servers directly
- Connection brokers with session hosts: Load balance RD connection brokers sitting in front of RD session host servers
- Connection brokers with virtualization hosts: Load balance RD connection brokers sitting in front of RD virtualization host servers
- Session hosts deployed with connection brokers: Load balance RD session host servers that were deployed with RD connection brokers and use routing tokens and routing token redirection
- Gateways: Load balance RD gateways
- Web access servers: Load balance RD web access servers
What health checks can be used?
Our load balancer allows you to use tuneable, customisable real server health checks. These can be adjusted as required to suit the needs of your network environment, unlike the opaque checking mechanisms that are built into the Microsoft RDS product.
What user persistence options are available?
Inbound connections can be forced to persistently stick to the same real server. Persistence options available for RDS deployments are:
- Stick on source IP: Use the client IP address for real server persistence
- RDP cookie: Use the client’s RDP cookie for real server persistence; useful if inbound connections are NAT-ed and share the same source IP address
- SSL session ID: Use the client’s SSL session ID header for real server persistence; useful if inbound connections are NAT-ed and share the same source IP address
Can real server CPU and RAM use be accounted for when load balancing?
Yes. We have a configurable open source Windows service available that reports real server CPU and RAM load back to the load balancer. The load balancer can adjust real server weighting based on this information, so that busy servers receive less new traffic than idle servers.
Using a feedback agent in this way is particularly useful when load balancing RDS sessions. A scenario can arise with RDS whereby a small number of users performing computationally intensive tasks can quickly tax a real server. In such a situation, load balancing based solely on the number of active connections to a server can cause issues, as this assumes a linear relationship between the number of connections and the amount of resource consumed on a real server.
The service can be downloaded from our blog by clicking here
How do I perform maintenance on my real servers?
Real servers can be gracefully drained of client connections, allowing them to be taken offline for maintenance once all user connections are finished. This simplifies the process of taking servers offline for updates and routine maintenance while not affecting user experience.