Scaling out RDS in Windows Azure
Blogs
23-2-2014
Scaling out RDS in Windows Azure
Freek Berson a Remote Desktop Services (RDS) MVP developed this concept model on driving a solution for RDS in Azure. The question we ask when discussing this topic with Freek was: What if you wanted to get all the great enhancements to Remote Desktop Services in Windows Server 2012 R2 to securely enable remote users, but could scale up or down to meet changing demand—without having to pay for the excess capacity unless you were using it? Freek has been working on a proof of concept (POC) with one of his customers to accomplish exactly that.Why Am I doing This?
The customer needed a solution to be able to easily scale up the amount of RD Session Host Servers during a specific period of the month, and scale down during the rest of the month to save resources they weren’t using. They also needed this solution to be simple—it shouldn’t matter to the operation of the overall deployment whether it was running at full capacity or not. Adding capacity to a RD Session Host server farm is conceptually simple: if you add more RD Session Host servers to the farm, then the RD Connection Broker will distribute incoming connections based on server load. If the farm is homogenous (the model assumed in RDS) it really doesn’t matter how big it is so long as sufficient capacity exists to meet user demand. In the following diagram you will get a basic layout of what this solution looks like:
figure 1. Basic infrastructure diagram
There’s a hitch, though: if you scale up and down in the private cloud, you still have to support and host the infrastructure. What if we could use Windows Azure to host the spare RD Session Host server capacity?
Running RDS in Windows Azure might seem like an expensive solution, since his testing show an average maximum of 36 concurrent users running a medium workload on an Extra Large Windows Azure VM. However, one of the advantages of Windows Azure is that you pay for your resources per minute. You don’t pay for VMs that are switched off and deallocated, so hosting spare capacity not only makes the deployment more flexible but could potentially lower costs.
Can you even Host RDS in Azure?
RDS on Azure is a relatively new option. If you’re familiar with his personal blog you’ll know that he’s been doing a lot of testing on this subject since the early days of Windows Azure. These are some of the key developments.- In September 2012 he set up a first lab environment running a very basic RDS deployment in Windows Azure. “At that time, Microsoft did not support running any RDS role in Windows Azure yet; I just wanted to see if it was technically doable.” Freek said.
- On July 1st 2013, Microsoft updated the Product Use Rights to allow running session-based RDS roles on Windows Azure. However, licensing back then was only possible by using Subscriber Access Licenses (SALs) purchased through the Microsoft Service Provider Licensing Agreement (SPLA). To get insights in to what kind of workloads the various types of Azure Virtual Machines would be able to handle, Freek performed a first performance test running Login VSI Medium workloads.
- In September 2013, he performed some additional testing in regards to publishing High Available load balanced environments in Windows Azure and adding additional Management Suites.
- Recently Microsoft announced that from 2014 you can use RDS CALs (Client Access Licenses) instead of SALs) to connect to Azure-hosted RD Session Host servers.
Making this work
“For the POC I only deployed RD Session Host servers in Windows Azure, because my goal is to create a flexible way to scale RD Session Host server capacity with demand. For simplicity, all the other roles, such RD Connection Broker, RD Web Access to present a common portal for , RD Licensing etc. are still hosted on premises. However, depending on the exact customer demands the location of these roles technically should not matter as long as all servers running these roles can communicate with each other through the Windows Azure VPN.” Freek commented. Using the VPN means that he didn’t need to use an instance of RD Gateway for the servers running in Azure, although if needed, technically you still could “One of my key goals was flexible scale, and there is no tool in the UI to automatically scale up and down RD Session Host servers in a deployment. However, since RDS in Windows Server 2012 and later is fully manageable using PowerShell I could write a script to detect load, drain users from underutilized servers, and then (once no one was logged in) power down and deallocate the servers so I wouldn’t get charged for them. Because this customer’s demand increases at a predictable time, I could run a second script slightly prior to that time to provision more RD Session Host servers and add them to my deployment.” He said. The PowerShell scripts takes a few parameters (configurable in a config.ini file):- The name of the Session Collection
- The name of the Active* RD Connection Broker
- The number of hosts you would like to be available in out-of-office hours
Figure 2. Sample output of the script
A second scheduled task, scheduled to run just before we expect to need full capacity again, runs a PowerShell scripts to check which servers are offline and powers them up. Since the servers were previously set to “drain mode (until reboot)” they will automatically start accepting new sessions again.
Closing thoughts
Freek said he had three goals for this POC:- Automatically scale the size of the farm to meet changing demand
- Host the spare capacity in Windows Azure so my customer would only pay for the servers when they were in use
- Securely connect the excess capacity to the main deployment hosted on the customer site, so the user connection experience didn’t change as the farm changed.