Showing posts with label applicationblock. Show all posts
Showing posts with label applicationblock. Show all posts

Azure Tools Belt: Auto-scaling Application Block – WASABi

Labels: , , , , , , ,
One of the questions that clients often ask is: What tools could be used for Windows Azure development. Everyone knows that you need a web browser and a code editor (ex: Visual Studio), but what else? So, I decided to do a serie of posts to present them. This second post is about the Auto-scaling Application Block or WASABi for friends.

This serie is not meant to be an exhaustive list of all tools. Some other excellent tools are surely available. If you think I have forgotten one or want me to talk about one, let me know. I will be more than happy to adding it to the list.

Already in the Azure Tool Belt:

What is WASABi?

To achieve elasticity until now, you needed to do it manually through the Azure management portal or writing your own code using the REST API. Using Wasabi, you just need to define some rules and the application will scale automatically: It can use a schedule or can be triggered by metrics, for example running fewer instances at night or adding extra instances if the CPUs are used at more than 80%.

The auto-scaling application block can be hosted either in a Windows Azure role or in an on-premises application. The auto-scaling application is typically hosted in a separate application from the target application that you want to scale.

Various scenarios are available to help you manage the auto-scaling by dynamically changing instance counts or performing application throttling of web/worker roles. The rules can auto scale based on timetables or metrics collected from the application and/or Windows Azure. You can even use notifications to preview any scaling operations before they take place and you can also use some PowerShell cmdlets to manage the autoscaler. You can constrain the auto scaling by:
  • Setting the instance counts upper and lower bounds
  • Preventing fast oscillations in the number of role instances with the stabilizer
  • Limiting scaling operations acknowledging billing hours

How to use it

For this demo we will use a simple Hello word application and scale it with a rule via a console application based on time.


Step 1: Put the app in Azure

clip_image001[4]To get started an Azure application is needed. Don’t forget to assign a certificate since the console application will need it.

You can then publish the application on the cloud.





Step 2: Adding the scaling application

clip_image002[4]Now create a console application and name it AutoScalingConsole. Add the WASABi package by executing: Install-Package EnterpriseLibrary.WindowsAzure.Autoscaling.
It should run without error and your Solution should look like this.







Step 3: Add and configure the rules

Add a new file call Rules.xml and set the property Copy to Output Directory: Copy always. Copy-paste this xml into the rules file. 
<?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" description="The default constraint rule">
      <actions>
        <range min="1" max="1" target="AutoscalingApplicationRole"/>
      </actions>
    </rule>
    <rule name="peaktime" enabled="true" rank="10" description="Increase instance count at peak times">
      <timetable startTime="20:00:00"  duration="00:20:00" />
      <actions>
        <range min="2" max="4" target="AutoscalingApplicationRole"/>
      </actions>
    </rule>
  </constraintRules>
</rules>

It contains two rules: A default one that is always active, defining minimum and maximum instance counts of 1, and a second one used for scaling. The variable “Is rank” with a value of one means that it can be overridden by other constraint rules with a higher rank. . Naturally, if that rule is applied, there will be only a single instance of the role.

The second rule is named peaktime. This rule has the same target, a higher rank, a minimum value of two, a maximum value of four. Also a timetable makes the rule active for 20 minutes, starting at 10 minutes from the current time.

Step 4: Define the service model

You will now add a new xml file called services.xml and set the property Copy to Output Directory: Copy always. Copy-paste this xml into the services file. 
<?xml version="1.0" encoding="utf-8" ?>
<serviceModel xmlns="http://schemas.microsoft.com/practices/2011/entlib/autoscaling/serviceModel">

  <subscriptions>
    <subscription name="[yoursubscriptionname]"
                  certificateThumbprint="[yourmanagementcertificatethumbprint]"
                  subscriptionId="[yoursubscriptionid]"
                  certificateStoreLocation="CurrentUser" certificateStoreName="My">
      <services>
        <service dnsPrefix="[yourhostedservicednsprefix]" slot="Staging">
          <roles>
            <role alias="AutoscalingApplicationRole" roleName="AutoscalingApplicationRole" wadStorageAccountName="elazurehol"/>
          </roles>
        </service>
      </services>
      <storageAccounts>
        <storageAccount alias="elazurehol"
                        connectionString="DefaultEndpointsProtocol=https;AccountName=[yourstorageaccountname];AccountKey=[yourstorageaccountkey]">
        </storageAccount>
      </storageAccounts>
    </subscription>
  </subscriptions>
</serviceModel>

In this file, make the following changes:

Replace [yoursubscriptionname] with the name of your Windows Azure subscription and [yoursubscriptionid] with your Windows Azure subscription ID.		clip_image001

Replace [yourmanagementcertificatethumbprint] with your Windows Azure management certificate thumbprint.		clip_image002

Replace [yourhostedservicednsprefix] with the URL prefix of your Windows Azure hosted service.

Replace [yourstorageaccountname] with your Windows Azure storage account name and [yourstorageaccountkey] with your Windows Azure storage account primary access key.		clip_image003

Step 5: Configure the Auto-scaling Application Block

Right-click on the App.config file in Solution Explorer, add one if needed, then click Edit Configuration File. In the Blocks menu, click Add Autoscaling Settings. Now set the rules.xml and services.xml as sources for Rules Store and Service Information Store. Via the File menu, Save then Exit.

wasabidemo_4

To by able to track evolution of the the testing let’s add some logging.  In Visual Studio, double-click on the App.config file to open it in the editor. Then add this system.diagnostics at the end of the file:
<system.diagnostics>
   <sources>
      <source name="Autoscaling General"  switchName="SourceSwitch" switchType="System.Diagnostics.SourceSwitch" />
      <source name="Autoscaling Updates"  switchName="SourceSwitch" switchType="System.Diagnostics.SourceSwitch" />
   </sources>
   <switches>
      <add name="SourceSwitch" value="Verbose, Information, Warning, Error, Critical" />
   </switches>
</system.diagnostics>

Step 6: Try it

You can now run the console application and observe how the auto-scaling rules work with the Azure application. Check the Output window in Visual Studio that logs which rules are being matched.


Conclusion

Using Wasabi makes your application elastic but doesn’t make your application scalable you must therefore design for scalability. If you have any comments, suggestions or experiences to share, feel free to let me know by adding a comment, by e-mail or by the contact page.
 

Where to find More info?


Note:


~Frank


Subscribe to: Posts (Atom)