Azure Elasticity with Wasabi Application Block
One of the core capabilities provided by cloud computing is elasticity. It means that it is possible to provision new machines automatically when required and delete redundant instances when possible.
Unfortunately Windows Azure did not provide an easy tool-set for implementing elasticity. It was possible but it was not easy. To do that you would have to use the management API for spinning new instances together with storage REST API which was used to query the service diagnostics info.
To fill the void tools such as AzureWatch were developed yet it was weird that Microsoft does not provide its own tools and API for such fundamental cloud computing scenarios.
I am happy to announce that things changed.
Patterns and Practices announced the release of the Enterprise Library Integration Pack (wasabi) which provides a simple yet powerful ways to implement elasticity in windows azure.
With wasabi you create an application (controller) that monitors the state of your cloud services and executes actions such as create or remove instances according to predefined rules. This controller can be hosted on-premises or in the cloud. It make sense that the controller should run 24-7 to capture changes and act accordingly, so a worker role is a natural selection.
So let us write a wasabi controller:
First we create a simple worker role to host the wasabi controller.
Then we have to install the application block in our worker role. (It does much more then add references).
To do that we will use NuGet and look for "wasabi" package.
The NuGet package adds many required references to our project and adds two xml schemas we will use later to audit the rules and services xml files.
Wasabi uses information which is stored on windows Azure storage such as diagnostics info about the services to scale and rules that defines when to scale. The exact location of this info is written in the configuration of the controller application. In this case our worker's role app.config.
To configure our controller app.config we will use Enterprise library configuration tool (you can download it by searching "EnterpriseLibrary.config" in Visual Studio Gallery or by using the VS Extension Manager.
So let us right click app.config and choose "Edit Configuration File"
Now the configuration tools opens and in the Blocks menu we have to choose : AutoScaling Settings.
We can use the default configuration for now and only set the storage location for the information required by the application block.
Lets save and continue.
Now it is time to audit the services xml file.
In this file we define the location of the hosted services and roles we want to scale. We provide the management certificate details and the subscription ID that will be used by wasabi to authenticate against Azure and trigger the management commands. The management certificate must be installed on our machine so the file specifies where to find it. The subscription ID can be found in the Azure portal. It is easy to audit the xml file because its schema (AutoscalingServiceModel.xsd) was installed by NuGet.
<?xml version="1.0" encoding="utf-8" ?>
<serviceModel xmlns="http://schemas.microsoft.com/practices/2011/entlib/autoscaling/serviceModel">
<subscriptions>
<subscription name="ManuCohenYashar"
certificateStoreName="My"
certificateStoreLocation="CurrentUser"
certificateThumbprint="A7595E8F51001BA7CCB27CC6CD68E8BC05Exxxx"
subscriptionId="7d6af05e-632d-48aa-a957-xxxxxxxxxxxxx">
<services>
<service dnsPrefix="manutest" slot="Production">
<roles>
<role alias="WebRole1" roleName="WebRole1" wadStorageAccountName="storagelabs"/>
</roles>
</service>
</services>
<storageAccounts>
<storageAccount alias="storagelabs"
connectionString="DefaultEndpointsProtocol=https;
AccountName=storagelabs;AccountKey=xxxxxx=">
<queues>
<queue alias="queue1" queueName ="queue1"/>
</queues>
</storageAccount>
</storageAccounts>
</subscription>
</subscriptions>
</serviceModel>
The next file we have to audit is the rules file.
In this file we specify the "Business rules" according to we want to scale. (i.e. when to add an instance and when to delete one)
There are two types of rules.
Constraints rules that define a general range for the number of instances we want per role.
Proactive rules that define how to react to changes in the roles performance.
Rules can be ranked. The rules schema allows to define powerful expressions using arguments expressing countless performance attributes such as performance counters, queues length etc. (there are extensibility points here so you can define your own arguments)
<?xml version="1.0" encoding="utf-8" ?>
<rules xmlns="http://schemas.microsoft.com/practices/2011/entlib/autoscaling/rules">
<constraintRules>
<rule name="default" enabled="true" rank="1">
<actions>
<range target="WebRole1" min="2" max="4"/>
</actions>
</rule>
<rule name="peek" enabled="true" rank="100">
<timetable duration="10:00:00" startTime="08:00:00" utcOffset="2">
<weekly days="Sunday"/>
</timetable>
<actions>
<range target="WebRole1" min="20" max="40"/>
</actions>
</rule>
</constraintRules>
<reactiveRules>
<rule name="busy" enabled="true" rank="1">
<when>
<greaterOrEqual operand="cpu" than="60"/>
</when>
<actions>
<scale by="1" target="webrole1"/>
</actions>
</rule>
<rule name="notbusy" enabled="true" rank="1">
<when>
<lessOrEqual operand="cpu" than="20"/>
</when>
<actions>
<scale by="-1" target="webrole1"/>
</actions>
</rule>
<rule name="queueIsFull" enabled="true" rank="1">
<when>
<greaterOrEqual operand="queue" than="10"/>
</when>
<actions>
<scale by="1" target="webrole1"/>
</actions>
</rule>
</reactiveRules>
<operands>
<performanceCounter alias="cpu" performanceCounterName="\Proccessor(_Total\% Processor Time)"
source="WebRole1" aggregate="Average" timespan="00:15:00" />
<queueLength alias="queue" queue="queue1" aggregate="Average" timespan="00:10:00"/>
</operands>
</rules>
The schema for this file (AutoscalingRules.xsd) was also installed by NuGet.
Now it is time to write the code within the controller (our worker role) that will activate the wasabi application block. As you can see it is very simple.
static Autoscaler autoscaler;
public override void Run()
{
autoscaler = EnterpriseLibraryContainer.Current.GetInstance<Autoscaler>();
autoscaler.Start();
while (true)
{
Thread.Sleep(10000);
Trace.WriteLine("Wasabi Controller is running", "Information");
}
}
The next stage is to upload the rules and services to Azure Blob Storage (to the location that was specified in the configuration tool
and is now written in app.config)
This is it. Everything is ready.
Make sure your service (the one you want to scale) is running and is writing information to storage using Azure Diagnostics. Now deploy the controller and watch how it auto scale your service.
I created a demo solution that can be downloaded here.
I recommend watching the video at channel 9.
Enjoy
Manu