Remote Desktop Services, formerly known as Terminal Services, is a technology from Microsoft that allows users to remotely access a session-based desktop, virtual machine-based desktop, or applications hosted in a data center from their corporate network or from the internet.
Multiple RDS servers can be used in a farm. Hence we need to balance the load against them.
There are different ways to achieve this:
using a connection broker
using a load-balancer with the connection broker
using a load-balancer without the connection broker
Of course, our load balancer of choice is HAProxy! In this blog article, we’re going to focus only on the case where a load balancer is used.
The main issue when load balancing multiple Remote Desktop Services servers is ensuring a user has the continuity of his session in case of a network outage. The current article will focus on session high availability for an optimal end-user experience.
HAProxy With a Connection Broker
The connection broker, formerly known as the Session broker, has the main purpose to reconnect a user to his existing session. Since Windows 2008, the connection broker also has had some load balancing mechanisms.
Why Use a Load Balancer if the Connection Broker Can Load Balance?
The answer is simple: security. Since HAProxy is a Reverse-Proxy, it breaks the TCP connection between the client and the server. HAProxy can be deployed in DMZ to give access to users coming from the internet to an RDS farm deployed in the VLAN dedicated to servers.
Note: this configuration works for ALOHA 6.0 and above and HAProxy Enterprise 1.5 and above.
frontend ft_rdp mode tcp bind 192.168.13.128:3389 name rdp timeout client 1h log global option tcplog tcp-request inspect-delay 2s tcp-request content accept if RDP_COOKIE default_backend bk_rdp backend bk_rdp mode tcp balance leastconn persist rdp-cookie timeout server 1h timeout connect 4s log global option tcplog option tcp-check tcp-check connect port 3389 ssl default-server inter 3s rise 2 fall 3 server srv01 192.168.13.13:3389 weight 10 check server srv02 192.168.13.14:3389 weight 10 check
HAProxy Without a Connection Broker
HAProxy can be used on its own to perform session load balancing and resumption. For this purpose, it needs a stick table where the user-server association is stored. A peers section is added to the configuration. So we can share session persistence information between a cluster of ALOHAs or HAProxy Enterprise servers.
peers aloha peer aloha1 192.168.13.1:1023 peer aloha2 192.168.13.2:1023 frontend ft_rdp mode tcp bind 192.168.13.128:3389 name rdp timeout client 1h log global option tcplog tcp-request inspect-delay 2s tcp-request content accept if RDP_COOKIE default_backend bk_rdp backend bk_rdp mode tcp balance leastconn timeout server 1h timeout connect 4s log global option tcplog stick-table type string len 32 size 10k expire 8h peers aloha stick on rdp_cookie(mstshash) option tcp-check tcp-check connect port 3389 ssl default-server inter 3s rise 2 fall 3 server srv01 192.168.13.13:3389 weight 10 check server srv02 192.168.13.14:3389 weight 10 check
To know the user-server association, we can simply read the content of the stick-table:
echo show table bk_rdp | socat /var/run/haproxy.stat - # table: bk_rdp, type: string, size:10240, used:5 0x21c7eac: key=Administrator use=0 exp=83332288 server_id=1 0x21c7eac: key=test-001 use=0 exp=83332288 server_id=2
We can easily read the login used by the user, the expiration date (in milliseconds), and the server ID used for the session.
LinksSubscribe to our blog. Get the latest release updates, tutorials, and deep-dives from HAProxy experts.