Best Practices for Auto-Scaling

Auto-scaling has improved our customers’ ability to reduce costs by leveraging our platform. Auto-scaling gives your MyCloudIT infrastructure the ability to start additional session hosts (virtual machines) in your infrastructure based on user demand, then after hours, auto-scaling can shut down the unneeded session hosts to save on Azure runtime costs. This is discussed further in a previous blog about deciding to use one large session host or multiple smaller session hosts for an RDS collection. The discussion concluded that with Auto-scaling, multiple smaller session host servers are more cost effective. Now, let’s look at some of the best practices for auto-scaling.

Below is the screen shot of the auto-scaling configuration screen. Each RDS or RemoteApp collection will have its own auto-scaling configuration, thus allowing different collections to be configured differently.

Here is the configuration screen for auto-scaling. Hover over each "?" to view the context to help.

By default, auto-scaling is disabled.  Auto-scaling requires a minimum of two virtual machines within the collection to be effective. Please take advantage of the popup help for each configuration item, detailed explanations have been provided where necessary. 

Here are the best practices for leveraging auto-scaling:

• The RDSMGMT and RDSGW servers must remain running while using auto-scaling. Without the availability of the RDSMGMT and RDSGW servers, users will not be able to connect to the session hosts.
  
  
• The scheduler and auto-scaler can work together to further drive down costs.
  
  
• Peak Time is typically defined as your normal work hours. Keep in mind that between Start Peak Time and End Peak Time, auto-scaling will only start additional VMs, it will not take any VMs offline.
  
  
• After End Peak Time, auto-scaling will only take VMs offline as users sign out of their VMs.
  
  
• If you want your users to be signed out at the End Peak Time, you can enable Force Users to log-off. This will allow you to send a log-off message to your users, then log them off after the specified number of seconds. To provide your users with a 10-minute warning, it would require a setting of Limit Seconds to Force Log Off User of 600.
  
  
• The minimum number of RDSH (session hosts) cannot be less than one. From an auto-scale perspective, at least one session host must always be running. If you want to take a whole collection offline, please leverage the scheduler.
  
  
• Auto-scaling will only start pre-configured session hosts. Auto-scaling will not provision new VMs from an existing Golden Image.  We do this to ensure that your session hosts are properly configured since some customers do not want to use a Golden Image.
  
  
• Session Threshold Per CPU allows you to define the maximum number of users each virtual CPU should support. Note that for multi-core VMs, your user count per VM will be the number of cores the VM contains multiplied by the Session Threshold Per CPU.
  
  
• All session hosts within a collection should be the same size.
  
  
• There is no way to control which VMs are started and stopped. That is all decided by the auto-scaler.
  
  
• Percentage Rule to Increase Capacity defines how many users will be logged into your session host(s) before then next VM is started. This is based on the number of users connected to all session hosts in the collection.
  
  
• Your collection must be prepared for logon storms. It takes about 10 minutes for Azure to start a deallocated VM once auto-scaling requests a new VM. You can prepare for a logon storm in a few different ways:
  • You can have more VMs running in advance of an expected logon storm by having Minimum Number of RDSH for Peak Time set to a larger number.
    
    
  • You can set the Percentage Rule to Increase Capacity to a lower percentage, say 50% so that once ½ the number of users your current session hosts support are logged in, additional VM(s) can be started.
  • Keep in mind that user behavior is not an exact science and by using smaller VM sizes, having an extra VM running for an additional hour will typically cost less than $.40. You can balance VM availability with the end user experience to ensure users are always able to log on, while keeping costs low. The better you can predict the logon behavior of your users, the more precise your auto-scaling configuration can be.
    
    
• Auto-scaling will show your deployment as “Degraded” in the main deployment page. This is OK, since the main deployment page is reporting based on whether all VMs within a deployment are running or not.

Want Future Best Practices Emailed Right to Your Inbox?