Autoscaling, Azure, WAP and System Center

The term autoscaling can have several meanings including scaling out (adding additional instance), scaling up (adding more resources to an existing instance) and scaling down (removing resources from an existing instance). In Azure this is explained at http://msdn.microsoft.com/en-us/library/hh680945(v=PandP.50).aspx. In this three part blog post series, my goal is to explain what the current state for autoscaling is in Azure, System Center and WAP. For background on Azure and how System Center works with the cloud check out http://blogs.catapultsystems.com/cfuller/archive/2014/08/01/highlights-from-the-road-to-the-cloud-webinar.aspx.

In this first part of the series, I will look into autoscaling and how it works in Azure. The three parts for this blog series are listed below.

Part 1: Autoscaling in Azure [this blog post]

Part 2: Autoscaling in System Center

Part 3: Autoscaling in WAP

In this blog post we will show examples for how autoscaling can be used in PaaS and IaaS.

    

Autoscaling in PaaS:

Out of the box Azure does not currently provide scaling up or scaling down but scaling out is available for anything in PaaS. Applications written for PaaS can be autoscaled. Azure deploys the applications into VMs as needed. Since these applications are in PaaS we do not need to maintain the VMs (IE patching, anti-virus, etc). As a simple example of how PaaS works let’s focus on a website. Websites work well in a scale out scenario as they can adjust due to unpredictable usage patterns and they are not a monolithic application which needs to scale up during periods of high utilization.

Oftentimes the best way to learn something is just to give it a try to see how it works. For this blog post we will create a simple website in Azure and show how this can be configured to for scaling. To start this process we begin by creating a website in Azure.

Microsoft includes pre-built examples, such as the bakery example shown below.

Once this website is created, we need to configure it to an options which will allow autoscaling. Once the website is ready we can verify that it’s online by browsing to the website (as shown below).

This website can be changed from free to Standard or above which allows configuration for autoscaling.

Once the website has been configured as standard we can now configure schedule times for the website. For this example I am configuring different settings for day and night as shown below.

Setup a schedule

    

With autoscaling I can configure instance counts based on usage (the example below is based upon CPU utilization exceeding 80% during the day, and having between 1 to 3 instances during the day).

 

The other parts of the schedule can be configured differently – the example below shows the night schedule configured to only run one instance.

Using the example above it’s easy to see how a website could be configured to use autoscaling within Azure.

Autoscaling in IaaS:

Out of the box Azure does not currently provide scaling up or scaling down for IaaS but scaling out is available for IaaS. John Savill has provided an excellent explaination of Azure Auto-Scale with IaaS in his walkthrough available at http://youtu.be/Q3EN-SPLs7A. The second part of John’s video (from minute 9 – 14) shows the configurations required in IaaS to use autoscaling in Azure.

I utilize a virtual running in Azure IaaS to provide functionality which I cannot run locally on my Surface 2 RT (discussed at http://blogs.catapultsystems.com/cfuller/archive/2014/04/09/using-the-surface-2-rt-like-a-pro-fessional-1.aspx). To take advantage of the scaling functionality available for IaaS I shut down my existing virtual and made a copy of it. I added these two virtuals into an availability set which includes both of these IaaS virtuals (shown below).

 

The schedule is configured to run one instance of the VM during the day and during the night it is configured for zero instances of the VM. The graph below shows how the virtual count changes between 1 and 0 depending on the time of the day which decreases the total usage of my Azure subscription by shutting down this virtual during non-work hours.


 

Summary: Autoscaling out is a function which is available out of the box in Azure for both PaaS and IaaS. Additionally, scripting can be used to automate autoscaling up and down for resources in Azure. In the next part of this blog post I will discuss autoscaling from a System Center perspective.

Thank you to Tony Nguyen and John Savill for their excellent insights into this topic!

6 thoughts on “Autoscaling, Azure, WAP and System Center

  1. Wilson W.

    How is AD computer account maintenance handled in Azure? Are computer accounts for auto-scaled instances pre-staged in AD or are they dynamically generated? And how is computer account cleanup done when instances are auto-scaled down? Is the computer account automatically removed from the domain or do you have to go and manually clean up all of those old computer accounts?

  2. Pete Zerger

    Auto-scale for IaaS in Azure does not provision new VMs, it simply powers on (or off) existing instances you have already created, so accounts were created in the normal fashion (sometimes a VM is just a VM). On the other hand, the same feature in PaaS will spin up new workers.

  3. Cameron Fuller Post author

    For IaaS my understanding is that virtuals need to be pre-created so they would have their own unique AD computer accounts. When the instances are scaled up they are turned on and when they are scaled down they are turned off. So they would not actually be removed as computer accounts since these are effectively virtuals that are just offline. All of this again is just from the IaaS perspective from what I understand. Others feel free to clarify!

  4. Wilson W.

    Ah, ok. So that leads to another interesting question…..if you were using SCOM to monitor these auto-scaled systems how would you configure SCOM to handle their impermanence? Obviously you don’t want SCOM spitting out heartbeat alerts when an instance gets powered off…..so would all of these pre-staged instances need to be placed into some sort of semi-permanent Maintenance Mode controlled via some sort of runbook?

  5. Cameron Fuller Post author

    Great question and one that is currently on my “to-blog” list. I’m expecting that the best approach will be to put each of these into a distributed application and configure rollup to disregard not monitored conditions. Then to disable heartbeat alerts and ping alerts for these systems. I’m totally interested in ideas on this however as this is the best one I’ve thought of so far. I like the potential maintenance mode approach, if it is brought online it would need to be pulled out of maintenance mode and vice-versa.

  6. Wilson W.

    I suppose you could embed a powershell script in the server’s startup and shutdown sequence to set the Maintenance Mode status of the server……that way you don’t even need to bring Orchestrator into the equation.

    The only thing though is, how long can you set maintenance mode for? When using the drop-down calendar box, it looks like the farthest date you can set MM to expire is 2 years. So eventually in 2 years you will need to reset the timer….

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.