Remote Desktop Server farms explained (Part 1)

If you would like to read the next part in this article series please to to Remote Desktop Server farms explained (Part 2).

Introduction

In this article, we will be taking a closer look at Remote Desktop Farms in Windows Server 2008 R2. A Remote Desktop Server farm consists of multiple Remote Desktop Session Host Servers. Why would you need a RDS Farm? What are the options? What are the scenarios? These are some of the questions we will answer in this article. There are of course also 3rd party tools available that work on top of and extend RDS farms, but in this article our main focus will be out-of-the-box Microsoft solutions.

What is a RDS Farm?

In this article we use the term farm when we describe multiple servers running the RD Session Host role that serve the same purpose, so either publish the same desktop or publish the same applications and share the same initial connection (later on in this article we’ll see exactly what this means).

Why the need for a RDS farm?

So why do we need a RDS farm? I highly doubt this but in case you are not convinced, read this paragraph:

There are several reasons for needing an RDS farm. One of the reasons is obvious, your organizations user base has grown to an amount that simply does not “fit” (in terms of technical resources) on one RD Session Host server. Despite the fact that available hardware grows extremely fast especially with Server Virtualization, there is a point where it simply no longer performs to certain standards on a single RD Session Host. Another big reason of course is High Availability. Especially if you host a complete desktop on your RD Session Host for your users, downtime means those users can no longer perform their daily tasks. Therefore, as with all professional IT services your RD Session Host servers must be Always Available, meaning running multiple servers with the RD Session Host role to serve high SLA standards related to uptime and availability. Of course virtualizing your RD Session Host server on a server virtualization cluster (like for example a Hyper-V cluster) creates high availability of the hardware but that does not cover (software) issues on RD Session Host Server. A third reason is maintenance. Consider having to update, upgrade or perform maintenance on the RD Session Host Server. If you would be running one server, that could mean downtime for your end-users. If you are running a farm with multiple servers however, you could very fluently drain the server (allowing existing connections to run, but deny additional new sessions) in question until it is free of sessions without creating downtime to the delivered service.

What are the challenges concerning a RDS farm?

Now that we know what a farm is and we are convinced that we need one, let’s look at what functional challenges, without going into too much technical detail, we have to face here. Ok, so we know that our environment will have multiple RD Session Host servers, how does the workload get evenly spread over those servers in order to optimally use the available resources? This is where the term load balancing, a technique to spread workload based on several conditions, steps in. Now that we have multiple RD Session Host servers, can it be assured that in case of a (network) failure between the client and the server, I will return to the session I left open? Yes, it can. An additional Windows Server role called the Remote Desktop Connection Broker can make sure you do.

What are the scenarios and options?

Now that we know what a farm is, we are convinced that we need one and we know what functional challenges to face let us look at some possible scenarios and implementations, and discuss the pros and cons.

Let’s first look at the load balancing part. Remember that the main reasons to implement load balancing are spreading the workload as optimal as possible, creating High Availability and being able to drain sessions.

Option 1:  Round Robin DNS

Round Robin DNS (often referred to as RR DNS or DNS RR) is a, although very basic, form of load balancing. RR DNS is implemented by pointing a DNS entry A (or AAAA) record to multiple destinations. Let’s consider a scenario where we have three RD Session Host Servers. The DNS configuration to create RR DNS could be as follows

RDSFarm1     Host(A)     192.168.1.20
RDSFarm1     Host(A)     192.168.1.21
RDSFarm1     Host(A)     192.168.1.22

In this case RDSFarm1 is the DNS name of the farm and it points to three RD Session Host servers. How does the load balancing work? Users connect to the farm by running a (pre)configured RDP-file (either via RD WebAccess or use mstsc directly) and use RDSFarm1 as the hostname. The client on which the RDP session is started will resolve the hostname and the RR DNS construction will return one of the DNS entries.

PROS:

• easy to setup and no additional hardware or servers roles.

CONS:

• RR DNS does not detect RD Session Host Servers that are down and could cause users to connect to a server that is unavailable.
• RR DNS does not detect RD Session Host Servers that are in maintenance (drain mode) and could cause users to connect to a server that is unavailable.
• Sessions are not evenly spread because of challenges like for example DNS cache
• Without a RD Connection Broker, you cannot reconnect to a disconnected session

Bottom-line is that RR DNS is very basic with some big cons to consider. RR DNS can also be combined with the RD Connection Broker role as well to take away some of the cons, we’ll look deeper into that later on in this article.

Option 2: Network Load Balancing

Network Load Balancing (short NLB) is software load balancing based on an out-of-the-box available Server Role on Windows Server 2008 R2 (and also available within previous releases of Windows Server). When we setup NLB, again we need to define a farm name but this time point it to a single IP-address (the farm IP-address). Without going into too much technical detail about the configuration, you basically create a NLB farm with a farm name and IP-address and this address becomes available as a “secondary address” on all RD Session Host servers. Again, users connect to the farm by running a (pre)configured RDP-file (either via RD WebAccess or use mstsc directly) and use RDSFarm1 as the hostname. This time NLB makes sure that the session is sent to the RD Session Host server with the least load, based on the number of sessions per RD Session Host that NLB “counts”.

PROS:

• No additional hardware required (NLB compatible network hardware excluded)
• Sessions are evenly spread based on number of sessions per RD Session Host

CONS:

• There can be challenges at a network level based on the type of network switches that are used.
• The number of sessions is typically not the most optimal measurement to define a RD Session Host with the least workload

NLB can also be combined with the RD Connection Broker role as well. Again, we’ll look deeper into that later on in this article.

Option 3: Hardware load balancing or 3rd Party software load balancing

Hardware load balancing basically has the same PROS as NLB but on top of that can, based on the type of hardware (or software) spreads users over RD Session Host based on better conditions than just the amount of sessions. Most of these hardware or software products provide a way to create a “virtual load” that can be defined. For example, the available CPU or memory can be added as a measurement. In addition, typical applications that are running can be added as a measurement. You could, if you know that a particular application generally uses many resources, for example define that 10 users on 1 RD Session Host are running that application is considered as a 100% load and thus you do not allow new sessions. The obvious CON for this scenario is of course the fact that you need additional hardware or software.

Again, this option can also be combined with RD Connection Broker.

Option 4: RD Connection Broker Load balancing

RD Connection Broker is, just like RD Session Host, a Server Role that comes with Windows Server 2008 R2. The (non-technical) functionality is the same as NLB, new sessions are sent to the server with the least load based on number of connection the RD Connection Broker has notion of. There is one difference here though; the RD Connection Broker Load balancing feature does not have a farm DNS name to connect to. So how would we connect to a farm load balanced by the RD Connection Broker? This is where the dedicated redirector is introduced. The dedicated redirector is nothing more than a server running the RD Session Host role, however, it does not run any actual connections. In fact, under the hood, it is a RD Session Host running in Drain mode. So users connect to the farm by running a (pre)configured RDP-file (either via RD WebAccess or use mstsc directly) and use a hostname or FQDN pointing to that dedicated redirector. Since this RD Session Host does not allow new connections (drain mode) the RD Connection Broker is contacted which performs its load balancing actions to determine the server with the least load which will be the server that the user gets connected to. Be aware though that this construction could lead to the Dedicated Redirector being a Single Point of Failure. Unless you configure multiple dedicated redirectors and load balance those using for example RR DNS.

The central role of the RD Connection Broker

It’s important to realize that options 1 to 3 are all intended to define the initial RD Session Host server to connect to. In option 4, the Dedicated Redirector is always the initial server to connect to (unless the Dedicated Redirector itself is also load balanced) and that the RD Connection Broker decides what the server with the least load is to host the actual session.

On multiple occasions in the article we mentioned that the options can (and I believe should) be combined with the RD Connection Broker role. In part II of this article we’ll continue were we left of here and discuss further the central role of the RD Connection Broker and how it can be combined with the options discussed above. Stay tuned…

If you would like to read the next part in this article series please to to Remote Desktop Server farms explained (Part 2).