Autoscaling Azure with WASABi – Part 4

I gave an Autoscaling Azure talk at the Brisbane Azure User Group (BAUG) on the 18th April 2012. This series of posts will walk through the demo I put together for the talk using the Autoscaling Application Block (WASABi).

What are we configuring?

We will be configuring the service information in the file based service information store. This store holds the information for the service that we will be autoscaling.

Add Service Information Store

Right click on the ConsoleAutoscaler project and select Add New Item > XML File. Name the newly created xml file local-serviceinformation-store.xml. Right click on the xml file and select Properties. Ensure that the Copy to Output Directory property has a value of Copy if newer.

Solution Explorer - local-serviceinformation-store.xml

Open the local-serviceinformation-store.xml file, right click in the content window and select Properties. In the XML Document properties window select the Schemas property and then click on the ellipses to select the schema. Select the AutoscalingServiceModel.xsd schema from the resulting list and in the Use column set the property value to Use this schema.

XML Schema selection

Clicking OK should result in the Solution Explorer showing the AutoscalingServiceModel.xsd schema as linked to the local-serviceinformation-store.xml file. This will also now provide intellisense when editing this file.

Solution Explorer - schema linked

Configure Service Information Store

To configure the store we’re going to need subscription information, management certificate keys and store account keys from our Azure subscription. I’ve previously shown how to obtain this information from the Windows Azure preview portal, but will now show you how to do this from Powershell. There are Powershell cmdlets that are made available as part of the Windows Azure SDK for .NET. You can start your Powershell via the Windows Azure Powershell link under the Windows Azure folder in the Windows 7 start menu. I start my Powershell via Console2. It’s an awesome environment to host all your consoles.

I start my Powershell console with the following command. This will load all system modules and the Windows Azure modules into my shell.

 C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe -NoExit -Command "Get-ChildItem -Recurse -Include *.psd1 -Path 'C:\Windows\SysWOW64\WindowsPowerShell\v1.0\Modules', 'C:\Program Files (x86)\Microsoft SDKs\Windows Azure\PowerShell\Azure\' |% { Import-Module $_ }"

Now import the publishsettings file into your Powershell environment. This caches your subscription and management certificate information so that you can interact with Azure without continually having to set the subscription information. My publishsettings file was the same one I downloaded in the first post.

Import-AzurePublishSettingsFile -PublishSettingsFile 'C:\Users\Paul\Downloads\Windows Azure MSDN - Visual Studio Premium-Paul Bouwer-8-18-2012-credentials.publishsettings'

Import your publishsettings file

If you run into issues with this Import-AzurePublishSettingsFile step, you can manually correct the cache by looking at the C:\Users\[YOUR USERNAME]\AppData\Roaming\Windows Azure Powershell folder and correcting the information in the files there. Thanks to Michael Washam in this post for helping me troubleshoot some caching issues I ran into.

Now onto why we actually fired up Powershell !

Run the following command to get a list of Ids and Names for your subscriptions.

 Get-AzureSubscription |% { "{0} : {1}" -f $_.SubscriptionId, $_.SubscriptionName}

Use the Subscription Name and the following command to obtain your management certificate thumbprint.

 (Get-AzureSubscription -SubscriptionName '[YOUR SUBSCRIPTION NAME]').Certificate 

Finally use the Storage Account Name and the following command to obtain the key for the storage account used by the application you will be scaling.

 (Get-AzureStorageKey -StorageAccountName [YOUR STORAGE ACCOUNT NAME]).Primary 

The output from running these commands can be seen below. And no – these are not my real subscription ids, certificates and storage account keys – they are random bits courtesy of my Photoshop skills !All the Powershell commands and their output

Place all of these values and the xml below into your local-serviceinformation-store.xml file. My service name and storage account name values were baugautoscalingapp.

<?xml version="1.0" encoding="utf-8" ?>
<serviceModel xmlns="">
		<subscription name="[YOUR SUBSCRIPTION NAME]"
		              subscriptionId="[YOUR SUBSCRIPTION ID]"
		              certificateThumbprint="[YOUR CERT THUMPRINT]"
		    <service dnsPrefix="[YOUR SERVICE NAME]" slot="Production" scalingMode="Scale">
		        <role alias="WasabiDemoWebRole" 
		              wadStorageAccountName="[YOUR STORAGE ACCOUNT NAME]"/>
		    <storageAccount alias="[YOUR STORAGE ACCOUNT]"
		connectionString="DefaultEndpointsProtocol=https;AccountName=[YOUR STORAGE ACCOUNT NAME];AccountKey=[YOUR STORAGE ACCOUNT KEY]">
		        <queue alias="workerqueue" queueName="workerqueue" />
	<stabilizer scaleUpCooldown="00:01:00"
	        scaleDownOnlyInLastMinutesOfHour="0" />

Lines 4-8 contain the subscription and management certification information. Lines 9-17 contain the service information for the service we will be autoscaling.

On line 10 we can see a scalingMode attribute which is set to Scale. This as the name suggests means that the action that will be taken by the autoscaler when rule conditions are met is to scale the service instance. This attribute can also have a value of Notify which will not scale but notify a list of email addresses that a scaling action should be taken. The third and final value of ScaleAndNotify is a composition of these two actions.

On line 22 we have defined an alias for the queue in our storage account which we will be using as a metric for the rules.

On lines 28-31 we have configured the Stabilizer, which helps to prevent fast scale up and down oscillations and helps to optimize costs by limiting scaling-up operations to the beginning of the hour and scaling-down operations to the end of the hour.

The Service Information Store is now configured. Next up we will be configuring the Rules Store.


2 thoughts on “Autoscaling Azure with WASABi – Part 4

  1. Thanks for the great tutorial! I get the idea there is a bug in my serviceinformation-store.xml file. I get this error only:

    which corresponds to this line:
    var scaler = EnterpriseLibraryContainer.Current.GetInstance();

    Can you help me out maybe?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s