With the rise of pocket computing, users can access their applications and data from anywhere any time. The only issue with this is that now, there is an expectation that the applications will be available… you guessed it… any where any time… (sheesh!)
But how do we do it? How do we make sure that your critical application or resource is up all of the time: Enter the ADC. These are problems that ADC's are born to solve. ADC's are the best way to keep your application ticking along regardless of outage, change window, administration errors and all the other things that plague your application stack.
Now, a misconception that I come across regularly is that ADC's can only provide value if the application is web based. This, simply put, is not true. In this example, I am going to show you how to make a farm of Microsoft Windows 2008R2 Remote Desktop Services servers highly available with a little more intelligence than using knuckle-headed "Round Robin" DNS, in an environment where direct connections to the servers just aren't possible.
In my example, I built a farm of three Remote Desktop Servers in under an hour in Amazon's Virtual Private Cloud, and front ended it with a Stingray Traffic Manager. Now, the AWS VPC setups and instructions for enabling MS RDS are pretty well documented, so I am not going to go into it here. The magic here lies in Traffic Script being able to parse just about any application protocol and interpret it at the application layer to make smart traffic management decisions.
In this instance, we are parsing the RDS x.224 headers that RDS Session brokers use to instruct an RDS client to connect to a particular RDS server. Traffic script can grab the header and read the important RDC Routing Token like this:
Now this is a numeric value that, when decoded, will tell the Traffic Manager which back end node to send the traffic to. The Traffic Script in questions is available here:
Happy Traffic Managing!