Kemp Technologies announced today that the newest software update for their entire line of load balancing appliances will make them all "RDP-aware," meaning that they can intelligently load balance between Terminal Servers and/or integrate with Session Directory.
Kemp has been in the hardware load-balancing business for about five years. I first wrote about them in 2005 in an article about load balancing Citrix Web Interface servers. We've been a customer of Kemp for probably three years now, having bought a pair of LM1500's for $2500 each to sit in front of the web servers that host BrianMadden.com.
I talked to Tony Bourke, independent consultant and owner of LBdigest.com, about the hardware load-balancing market. Tony said the industry is really splitting into two camps: the "premium" load balancers like those from Citrix (NetScaler), F5, Cisco, and others which often cost $100k+ once you get the redundancy and options you need, and the "value" market, including Kemp, Barracuda, and Coyote Point, where a full high-availability pair starts at around $5k.
The traditional sweet spot for the "value" load balancers
Kemp has always been able to generically support any TPC or UDP port / protocol combination. If you wanted to do connection load balancing based on more than a simple number of current network connections, you had to write a script that calculates the load of each host that's accessible via HTTP by the load balancers. (In other words, a script runs on each host and generates a number from 1 to 100, and then the load balancers check http://host1/myscript, http://host2/myscript, etc. to determine which server should receive new load.) It wasn't the most ideal situation, but it sure was flexible since you could use any perfmon counter, WMI interface, EXE, or anything else you could dream up to generate those numbers. (For BrianMadden.com we had a script that ran several checks or web sites and sample database queries. If everything came back as expected, it generated a load number. If any aspect failed, the script generated a value of "100" which told the Kemp that server was "full," thus preventing new connections to the broken server.)
Kemp's products have traditionally found their sweet spot in front of web servers, and really the only place they've had in Citrix environments has been to load balance Web Interface servers since Citrix's own load balancing features are more integrated into the product. Load balancing pure Terminal Servers, however, has never been too great out of the box. The only free solution in the past was to use Windows Network Load Balancing. (Ron and I wrote an article about this in 2004.)
In the past, you could also use a "generic" hardware load balancer from to load balance your Terminal Servers. You could configure them to listen to port 3389 and you could even install IIS on your servers to create some cool load balancing algorithms. This worked well except for one thing: If a user with an existing disconnected session reconnects, there is no way for the load balancers to know about that existing disconnected session, so the user is routed to the least-busy server. Maybe the user is lucky and that server happens to be the one with their disconnected session (meaning they'll be automatically reconnected). But chances are they'll be sent to a different server, thus starting a new session even though they already have an existing session.
Integration with Windows Server 2003 Session Directory
With the release of Windows Server 2003, Microsoft introduced the "Session Directory"--a simple Access database running on one of the Terminal Servers--that maintains a list of all active and disconnected sessions on all servers. The session directory can then interact with hardware load balancers via a "routing token." Essentially this means that the hardware load balancers know about the session directory, so once a new incoming user authenticates to a Terminal Server (but before the session is started), the load balancer can then check to see if that user has an existing session on another server. If so, the session is switched over to the other server.
Session directory worked well enough, except only the expensive load balancers supported it. With today's announcement from Kemp, they now fully support session directory, even in their entry-level $2500 appliance.
But it gets much cooler than this.
What about Windows Server 2008?
With Windows Server 2008, Microsoft is introducing an out-of-the-box load balancing feature called Terminal Server Session Broker. (Michel Roth wrote a great overview of this last year.) It turns out that the TS session broker in 2008 is almost identical to the session directory in 2003--the prime difference being that 2008's session broker can route incoming connections to the least-busy server in addition to routing users with pre-existing disconnected sessions back to the server running their session.
So with this new feature of 2008, why would someone need the new load-balancing features in Kemp's products? Why not just use 2008's built-in session directory?
It turns out that while the session broker is cool, there are some complexities in its configuration. The most fundamental challenge is that TS session broker runs on one specific server. (And all incoming client connections are pointed to that server so they can be routed to the proper Terminal Server.) While this works well, it's also a single point of failure! And how do you alleviate single points of failure? You build redundancy. So now we're talking about building two session brokers. But now you need a way to fail over between the two (unless you just want to tell your users to try one address first, and then try the other if that doesn't work). So to failover between these two, you need to configure Windows network load balancing (NLB). But what's wrong with NLB? It will still send traffic to a server as long as that server's IP stack is up and the NLB service is running. So even if your session broker service fails horribly, NLB will keep routing users to a down server. So how to you avoid that? You put a smart, Layer 7 application load balancer in front of your session brokers so that incoming user requests are always routed to a functioning session broker server.
Or, you could just skip all that session broker complexity and just use that same Layer 7 application load balancer in place of the session broker. This is where Kemp comes in.
Understanding Kemp's new Terminal Server load balancing capabilities
Remember, one of the new features of Kemp's update to their load balancers is that they support the routing tokens that allow them to communicate with the TS session directory (Windows 2003) or the TS session broker (Windows 2008). So that's cool.
But, in addition to working with the Windows features, a new feature from Kemp allows you to use Kemp's load balancers to completely replace the session broker / session directory. (In other words, the Kemp's become your load balancers and route users to their disconnected sessions without using the session broker or session directory at all.) This works because now Kemp has added RDP to the list of Layer 7 protocols that they fully support. At the bare minimum, this means that the Kemp load balancers can do Terminal Server health checking by testing whether a server can receive RDP connections.
Kemp also has a resource agent running on each Terminal Server. The load balancer contacts these agents (at a configurable interval) so that it knows which server is the most appropriate for new connections. Furthermore, they can track active and disconnected sessions for you, so you don't have to deal with the session directory at all.
Kemp's resource load balancing works the same way it always has, which means the load balancer will contact each server in the load balance group via HTTP (on any port) looking for a value between 0 and 100. What's new for Kemp is that they wrote a little EXE that you can run on your servers that actually generates that value. This EXE reads a text configuration file that tells it what perfmon counters to look for and how they should be weighted for the final calculation. (In other words, you can use any perfmon counter in any way for your load balancing algorithms. (And if you have different servers that you want to weight differently, then just put a different text configuration file on them.) All that little EXE agent does is spit out a 0 to 100 value, so really if you want to use some other method altogether for load-balancing, that's no problem.
The only catch is that the load balancer reads the value of the agent on each individual Terminal Server via HTTP. This means you need to run some kind of web server service on each of your Terminal Servers. If you're using the TS Web Access feature of Server 2008 then this won't be a problem since that needs to have IIS running on each of your Terminal Servers anyway. But if you're not, you'll need to add IIS to each of your servers. Since IIS will only be serving the small static load file to the Kemp's, you won't need any additional capabilities such as ASP or ASP.NET installed, but some people might be nervous about IIS anyway. If you fall in that camp, there are actually several little HTTP daemons you could use instead of IIS, such as lighttpd or cherokee. In fact, these are the same daemons that many of the more expensive monitoring tools bundle into their agents anyway.
To reiterate, all of these software updates are available for all of Kemp's existing load balancers. So even the $2500 one that we bought three years ago can now do everything mentioned here. Of course for redundancy, you'll want more than one hardware load balancer. You can configure two Kemps as a high-availability pair. The first one is active, and the second one is passive and just monitors the first one. If the active load balancer fails, the passive one assumes its IP address and everything continues without interruption. So this means that you can get a fully-redundant, Layer 7 Terminal Server application load balancer that can balance off of any perfmon counter, do TS health checking, and replace the session directory, for $5000.
One last note: Kemp has several models of load balancers, but they all run the same software. The various model numbers have different hardware specs, so each supports various load and use scenarios. Hmm.. I just remembered that the Kemps also offer SSL off-loading for web servers. I wonder if you could use that with RDP as well? I've never tried. I'll look into this and update this article later today.