(This article has also been published on the author's website - http://www.thincomputing.net)
Notice: This article was written based on the Beta 3 release of Windows Server 2008. Features and facts about the Session Broker Load Balancing therefore could be subject to change as Windows Server 2008 moves towards RTM. You should be aware of this!
Session Directory versus Session Broker
Setting Up Session Broker Load Balancing
Like I said earlier, the Load Balancing capabilities of Windows Server 2008 are built into the Session Broker feature of Windows Server 2008. There are four steps you have to take to create your own Load Balanced Terminal Server farm. Notice I used the word “farm” on purpose. Windows Server 2008 uses “farms” as a logical “grouping unit”. Not as advanced as the concept of a Citrix farm but it’s a decent start.
The four steps are:
- Install the TS Session Broker role service on a Server
- Populate the Session Directory Computers local group
- Join the Terminal Servers to the Session Broker and make them participate in the Load Balancing (you could just do session reconnection and no Load Balancing)
- Add DNS entries for all Terminal Servers in the same farm.
Step 1: Installing the Load Balancer Role on a Server
SERVERMANAGERCMD.EXE -INSTALL TS-SESSION-BROKER
Step 2: Populate the Directory Computers Local Group
You need to add all the Terminal Servers that need to join the Session Broker in here. This can be quite a hassle to do by hand. Consider installing Terminal Services through a script and add the computer account to the Session Directory Computers group after the installation has finished. Alternatively, you could use the Restricted Groups feature in Group Policy. If you think you’ve gone nuts when you’re looking for the Group Policy Snap-in or the Group Policy Management on a Domain Controller, relax. You’re not alone… for some reason Microsoft installs Active Directory without any Group Policy management tools. You’ll need to install them. Just run SERVERMANAGERCMD.EXE –INSTALL GPMC
The point is that the Terminal Server computer account needs to be in the Session Directory Computers group or it’s a no-show.
Step3: Configure Terminal Servers To Join Session Broker
TS Session Broker Farm Name
Use IP address Redirection
TS Session Broker Name
TS Session Broker Load Balancing
Terminal Server Maintenance: “Draining”
Step 4: Add DNS Entries For All Terminal Servers
How does the Session Broker Load Balancing Work?
The Session Broker Load Balancing in Windows Server 2008 is usually just refered to as Session Based Load Balancing, which is true. The load balancing is done based on the number of sessions. But there's actually a lot more than meets the eye in regards to the Session Broker Load Balancing than just counting the user sessions. The Session Broker Load Balancing also has built-in black hole protection (logon throttling) and a max-session count.
The black hole protection is pretty advanced (if you don't know what the Black Hole effect is, read this article by Jeroen van de Kamp and Daniel Nikolic). It has two ways of protecting a server against the Black Hole effect. One is by artificially making the load on a server higher during a logon to prevent a Teminal Server being overrun by new logins. The load will return back to normal when the logon processs is finished. Another way the black hole effect is circumvented is by the Session Broker itself. It can have a limit in outstanding connections to the same Terminal Server. So for example no more than eight concurrent user logons per server. Simple but effective.
The max-session count means that every server in the farm has determined a maximum amount of sessions that it can host. This prevents a degraded user experience for the users already connected to a Terminal Server should some Terminal Servers in the farm not be available. This is at the expense of new users not being able to set up a session at all of course. The max-session limit however is something you'll need to configure yourself: it's not automagicly calculated by Terminal Server. Actually, it's disabled by default and not configurable via the GUI. If you want to enable it, you need to set the UserSessionLimit key in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server to the maximum amount of sessions you want to allow on that server.
So how does the whole process work? Well, the easiest way to describe how the Session Broker Load Balancing works is by examining the steps that it takes to set up a successful connection. These are:
- A Client connects to TS-farm.lh.lan. It gets returned the first IP address for this DNS entry (192.168.1.52) in our case.
- If that server should be offline for some reason, the client tries to contact the second server. This continues until the client receives a proper response from the Terminal Server.
- If the Terminal Server is joined to a Session Directory and has Load Balancing enabled, the Terminal Server queries the Session Directory.
- It first checks to see if the user has any disconnected sessions. If the user has a disconnected session, the user is directed to the Terminal Server that hosts the disconnected session.
- If not, it gets returned the least busy server based on the session count (connected and disconnected) of the farm. This takes into account the “weight” the specific Terminal Servers have and whether or not the server is being drained (i.e. is in maintenance mode)
- The client gets redirected to this least busy server and establishes a connection. The steps above are represented in this animation (courtesy of Microsoft)
This way of connecting has some obvious issues. One of these is the “DNS-approach”. If you do not have DNS Round Robin enabled, every connecting client will try the first Terminal Server first. This can put some severe strain on that first Terminal Server at peak login times. Make sure that Round Robin is enabled on the TS-farm.lh.lan records (DNS Round Robin is enabled by default on Windows Server 2003 and Windows Server 2008). If you feel that DNS Round Robin isn't really an enterprise-grade solution you could a "Dedicated Redirector". A Dedicated Redirector is a dedicated Terminal Server that does not host any applications but just queries the Session Directory on behalf of the clients. You could take that a step further and Load Balance two Dedicated Redirectors using a hardware load balancer or even NLB. Note that this needs some more configuration than meets the eye: you need to have clients connect to a DNS Alias instead of the host names of the Dedicated Redirectors or else you will run into server authentication issues.
Another question that comes to mind is: what happens when the Session Broker is down? Well when the Session Broker is down all Session Broker functionality is lost and all you have left is DNS Round Robin "Load Balancing". So if you want redundancy you’ll have to cluster the Session Broker. Back in Windows Server 2003 this could be done by utilizing Windows Clustering. You can use the same techniques to cluster the Session Broker in Windows Server 2008.
What does it do?
Session Based Load Balancing
Terminal Server Draining
Session Sharing is a very important part of any Load Balanced environment. It makes sure that as little separate Terminal Server sessions as possible are used. This has a lot of benefits. For example, it's faster because you don't have to go through the whole login process again and you're less likely to have profile issues.
Session Sharing does work in Windows Server 2008, but it does in a whole different way than you would probably expect. You might think that if you launch a second Remote Program, Windows first checks whether or not that Remote Program isn’t available on the Terminal Server you are already connected to. Turns out it doesn't work that way. It's a little less elegant. The Session Broker is not aware of what Remote Program you are starting, it just directs you to the Terminal Server you already were connected to (actually it first checks to see if you have any disconnected sessions). Exceptions to this behavior apply when the legacy "initial application" setting is used (the Windows Server 2003 wannabee way to do "Remote Programs") or if the single-session-per-user policy is turned off. When such an exception occurs, the Session Broker just tries to launch another session to that same server unless the Terminal Server is in drain mode or has reached its maximal session count.
So in Windows Server 2008 Terminal Server, Microsoft basically assumes you have a single-silo environment (which means that all the same applications are installed onto all Terminal Servers). If have to create silos in your Terminal Server farms to cope with for example conflicting applications, Session Sharing won't work for you all the time.
What doesn’t it do?
Session Broker High Availability Options
Resource Based Load Balancing
As said before, Session Broker Load Balancing does Session Based Load Balancing, not resource based Load Balancing. This means that Session Broker Load Balancing in Windows Server 2008 works by taking a look at just the user load on a Terminal Server, including disconnected session (remember that it also has black hole protection (logon throttling) and a max-session count). If you want to take CPU usage, Memory usage, Disk usage and stuff like that into account, you’re out of luck. I do not think that this is a big deal because in my opinion such resource based Load Balancing usually yields unpredictable loads. Resource based Load Balancing can be important though in environments where you have different types of hardware in your Terminal Server farms. In Windows Server 2008 you deal with this with the “weight” option in the Terminal Services configuration tool.
Oh, one thing to know is that you need a domain to use the Session Broker but I don’t think that will be a huge issue in most environments…
Do I still need Citrix?
Here's the million dollar question. Again...(being in this business feels like watching a rerun of Jeopardy!). Do I still need Citrix? Well, you can basically tell from the “What doesn’t it do” part of this article whether or not if you still need Citrix. It all depends on your environment. I think that the most important reason people buy Citrix Presentation Server Advanced Edition (or even the Enterprise Edition) is because of Citrix’ Load Balancing capabilities (which are the best out there as far as I’m concerned) However, fact of the matter is that now Load Balancing is included in Windows Server 2008, less people are likely to buy Citrix just for Load Balancing. Make that a lot less people.
If you look at the other features that Citrix has over plain Windows Server 2008 Terminal Server, well then it all depends whether or not you actually use the features. Think about features like Resource Manager, Installation Manager, Application Isolation Environments, Application Streaming, Virtual IP, SpeedScreen, Session Reliability, Health Assistant, Configuration Logging, just to name a few. Do you use these features? And if you do, consider whether or not it is worth the added costs that Citrix introduces.
Session Broker Load Balancing is in my opinion a viable option to consider when doing a Windows Server 2008 Server Based Computing deployment. Even in Beta 3 the Session Broker with Load Balancing makes a good impression. It’s easy to set up, provides decent backwards compatibility (important when using Thin Clients for example) and has a simple yet effective architecture. It’s also very important that the Load Balancing works for Remote Programs. Furthermore, this initial version of Session Broker Load Balancing looks really mature with features like the black hole protection, max-session and the drain mode.
It looks like Microsoft just wanted to implement the most important features of Load Balancing in Terminal Server environments and just focus on making that a success. Well they did just that. This coincides nicely with the statement Microsoft has been making about Windows Server 2008 Terminal Server primarily being an easy point-and-click out-of-box solution for low to medium complexity environments and that one would need third-party software in high(er) complexity environments. I guess it then all depends on what percentage of all Windows based Server Based Computing environments turn out to be complex …