If you would like to read the next article in this series please go to Load Balancing Terminal Services: All you wanted to know but were afraid to ask (Part 2).
Again, as in most of my articles, I just want to point this one was written for all the guys out there now thinking about expanding their one server environment or even trying to find out if they could improve the way they are currently load balancing their multi-server environment. This article does not intend to go in depth on how you actually configure/use every single option mentioned here. We want our readers to simply have a better understanding of what Load Balancing is, the most common features you should look for and what your options are (with all their PROs and CONs). It is that simple.
Introduction
As Terminal Services becomes mainstream (thanks to Microsoft for making it part of the Windows Server OS), pretty much every company, large or small, knows what Terminal Services is and they probably have played with it a little bit. After going in production with their first server, the first question that comes to their minds is, “If our TS server goes down, what will happen? How can we prevent that?”. The answer, in a certain way, is simple and straight forward: simply add another server, running the same applications, and you will have redundancy.
But the answer is not that simple. If you now have multiple servers, how do you tell your users which server they should connect to? Ideally this should be completely transparent. This is when Load Balancing comes to the picture.
So what is that Load Balancing thing?
Load balancing means distributing the incoming terminal server connections to two or more terminal servers, transparently to your users. It can be implemented with hardware, software, or a combination of both.
Ok, I get the idea. Load Balancing will be performed by something, either software or hardware. Good. But how this will work for my users? The ideal solution is very simple, user-wise: your users will launch the Microsoft RDP client, type in the IP address of the ‘load balancer’ (or its Fully Qualified Domain Name – FQDN) and after pressing enter, they will see the Terminal Services logon screen. The Load Balancer will connect them to any of your available servers. But how does it decide which TS is the best one? Well, some options will not go for the best TS. They will simply send you to a TS. 🙂
This is why you must understand how each option selects the next TS to take the new session request. Some are smart; some are not. Let’s take a look at the options!
Your options
Well as stated above we must split them into two categories: software and hardware (and of course a combination of both). By Software Load Balancer I mean an application that you will install on PC hardware (server class or not) running some well known OS; by Hardware Load Balancer I mean an external, often proprietary, piece of hardware (like an appliance) that will sit on your network.
Software
For software load balancing, many options are available. As you may be aware, some of these may introduce what we call a SPOF (single point of failure) or may not be compatible with all platforms at all! Let’s take a quick look at each option and their PROs and CONs.
DNS Round Robin
Yes, the oldest thing, available since the time before time. If you are not familiar with DNS Round Robin, this is simply a method where a certain Fully Qualified Domain Name (FQDN) like mypc.mycompany.com resolves to multiple IP addresses in sequence. The DNS server will return (in a rotation scheme) a different IP address (you will have to set this up on your DNS server) every time a machine tries to resolve that particular FQDN. For example, you setup mypc.mycompany.com to resolve to 192.168.1.1 and 192.168.1.2. When the first machine tries to resolve that address, the DNS server returns 192.168.1.1; the next time a machine tries to resolve it, it will return the next known IP address, in this case 192.168.1.2.
PROs
- Cheap
- Simple to setup. (This may not be true if you are not in charge of your DNS servers; some network administrators that may not have anything to do with your Terminal Services implementation may give you a hard time to implement/change anything at their end!).
- Works with any client. This simply means if your clients will be using Windows based terminals (CE, XPe, etc), Linux based terminals or any kind of device running any kind of OS, they will be able to connect to your TSs.
CONs
- Not Resource Based. Another term I must define. Resource Based Load Balancing means the solution in use for load balancing is aware of your servers’ status; it knows how your servers are doing (CPU, memory, number of users, etc) at any given time. This is important because you do not want a user to be sent to a server that has 100 users on it and is almost dead, instead of sending it to the other server with 5 users! Resuming: resource based means knowing how the servers are performing at any time and based on this knowledge, decide which server is the best at that time to handle the next user trying to connect.
- No reconnection. Here we go again. 🙂 Reconnection is simple to understand. If I am a user, working on server1 and for some reason my network connection drops (like my internet connection fails), after my network issue is solved and I try to reconnect to my terminal servers, ideally I would like to be reconnected to the server I was logged in so I can resume my work from the exact point I was at the time of disconnection. So the load balancing solution must be aware of all sessions (usernames, servers they are on, etc) in order to be able to reconnect you back to where you were. This is probably one of the most sought after features when load balancing terminal servers.
- If a server is down it will still send users to that server.
Microsoft Network Load Balancing (NLB)
When Microsoft released Windows 2000 Server, they introduced something called Network Load Balancing, available only on the Enterprise version. On NLB you basically create a farm (or cluster) of machines and assign a Virtual IP to it. All machines belonging to this farm will then respond, in sequence, to requests on any port you define (RDP, TCP 3389 for example) on that virtual IP address. The main difference from DNS Round Robin is the fact NLB actually knows if a server is down or not and therefore does NOT send users to a dead server (as DNS Round Robin does). Now on Windows 2003, NLB is part of the Server version so you do not need to pay an additional amount if all you want is NLB.
PROs
- Built-in on Windows 2003 Server.
- Smarter than Round Robin (as it knows if a server is down or not).
- Works with any client.
- Free (if you run Windows 2003; extra $$$ if you are on Windows 2000 Server).
CONs
- Not Resource Based.
- No reconnection.
- Unpredictable behaviour. What I mean here is simply based on an extensive research I did with MANY, I mean MANY, customers and companies running NLB out there. Given the way NLB works (you can read it in detail here) some routers/switches do not like it very much and this may lead to unpredictable behaviour. I know some companies where in one location it works perfectly and at a different site it stops working after a couple days! So the bottom line here is, it may work just great for you but it may not work depending on the day of the month, the moon phase and so on…
- Limited to 32 servers.
- All servers must be on the same subnet.
- Some people find it a PITA to implement. Again, as I mentioned above, for some people this is not only easy to implement but it works at the first try. But for many others, it does not work, the configuration seems weird and so on. Try it for yourself and let me know what you think. 🙂
- If you are still on Windows 2000…
That’s all for Part 1 in the series. In Part 2 I will round off the rest of the software options avaialble, discuss the hardware options avaialble and conclude with some useful advice. See you then!
If you would like to read the next article in this series please go to Load Balancing Terminal Services: All you wanted to know but were afraid to ask (Part 2).
