This Solution contains one Azure Project with one Worker Role. It also uses the .Net Azure Service Management API client library found at http://archive.msdn.microsoft.com/windowsazuresamples.

NEWS

In the last alpha version (v1.12), some configurations were removed from the Auto Scaling *cscfg file and added them to the Auto Scaling XML file in order to improve the program's remote management capabilities.

Features

•Manage multiple services of different azure subscriptions
•Setup same or different time schedules to Roles of a hosted service deployment.
•Swap hosted service deployments based on a time schedule
•Stop or Delete hosted service deployments based on a time schedule
•Start hosted service deployments stored in on azure storage account based on a time schedule
•Event Logging to an azure table
•Configure the number of seconds per state update
•Auto Scaling-Up or Scaling-Down an hosted service deployment by it's VM's CPU Load.

Assumptions

•Every hosted service to be managed must be available in subscription.
•Every Storage Account must be available in the same hosted service subscription of the stored deployment.
•Both deployment files must be available on a blob in a storage account.
•XML configuration file must be available on a blob in a storage account.
•The Azure Table for Event Logging must be created in advance.
•The X509 certificate to be used by the Auto Scaling Worker Role must be available in the Subscription Certificate Store and in the worker role hosted service certificates list.

Getting Started

There are a few steps to follow before using the Windows Azure Service Instances Auto Scaling.
•Add a X509 certificate to the Azure Subscription Certificate Management and to the Hosted Service Certificate List
•Create or Edit the XML Configuration file and upload it as a blob to the Worker Role Storage Account. This XML Configuration File can be updated while the Auto Scaling Worker Role is running. Read more information about XML Configuration File bellow.
•Edit the Service Configuration File (.*cscfg)
  • Fill or change "ScalingConfigurationStorageConnectionString" value - Connection String of the storage account where the XML Configuration file is stored. The storage account will contain the logging table
  • Fill or change "ScalingConfigurationBlobContainer" value - Blob Container name where the XML Configuration file stored
  • Fill or change "ScalingConfigurationBlobFileName" value - XML Configuration file name
  • Fill or change the Certificate thumbprint and thumbprint algorithm values
•Finally, add both Windows Azure Service Instances Auto Scaling deployment files to your hosted service. This should be the last step to be done.


Note: The Service Configuration File can be edited on Windows Azure Platform portal.



Scaling by CPU Load Feature
Scaling by CPU Load is a optional feature. It must be configured for every role of an deployment.
For make use of this feature you must follow two steps:
  • Enable Diagnostics for some specific Role (configure the storage account for the diagnostics results);
  • Override the OnStart() method in order to configure the diagnostics:
public override bool OnStart()
{
DiagnosticMonitorConfiguration config = DiagnosticMonitor.GetDefaultInitialConfiguration();
config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
{
CounterSpecifier = @"\Processor(_Total)\% Processor Time",
SampleRate = TimeSpan.FromSeconds(5)
});
config.PerformanceCounters.ScheduledTransferPeriod = TimeSpan.FromMinutes(1);
DiagnosticMonitor.Start("Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString", config);
return base.OnStart();
}

XML Configuration File Description

The XML Configuration File contains all information about the services which Auto Scaling Worker Role must take care of. This region starts with a description of all elements and all attributes of this XML. In the end of this region, there is an example of a valid xml configuration file.

Every configuration file has the following XML skeleton:

<?xml version="1.0" encoding="utf-8" ?>
<root>
<generalconfig />
<subscriptions>
<subscription>
<storages/>
<services/>
</subscription>
</subscriptions>
</root>

As we can see above, inside the root element we have the configurations needed for the Auto Scaling and a list of subscriptions.

Every generalconfig element has nine attributes:
•scalingsecondsperloop - Number of seconds per state update - Minimum Value = 1
•scalinglogtablename - Logging table name
•logtableentitiespartionkey - Partition Key for all log entities
•diagnosticsupperthreshold - Upper Threshold of Average CPU Load - Minimum Value = 2 / Maximum Value = 100 / must be upper than "diagnosticslowerthreshold" value
•diagnosticslowerthreshold - Lower Threshold of Average CPU Load - Minimum Value = 1 / Maximum Value = 99 / must be lower than "diagnosticsupperthreshold" value
•diagnosticsminutestosampleaverages - Number of minutes to get average from CPU Load - Minimum Value = 1
•averagevmboottime - Average Virtual Machine Boot time in minutes - Minimum Value = 1 / Recommended Value = 10
•minutestosleepafterincreasevmnumber value - Additional time to sleep after increase the Virtual Machines number of an Role in minutes - Minimum Value = 1 / Recommended Value = 10
•minutestosleepafterdecreasevmnumber - Time to sleep after decrease the Virtual Machines number of an Role in minutes - Minimum Value = 1 / Recommended Value = 5

Every subscription element has two attributes:
•Name – Subscription representative name on the XML. This is an optional attribute.
•Id –Subscription id. This is a required attribute.

Every Subscription element has two child nodes:
•Storages – This element has no attributes but contains a list of child nodes according to the number of different Storage Accounts required to store all deployment files belonging to the Subscription Hosted Services, which will be managed by Windows Azure Service Instances Auto Scaling. This is a required element, with at least one child node.

<storages>
<storage name=”storagenameA” key=”asdadfrgfreger--” />
<storage name=” storagenameB” key=”tgrtrththgdfdf--” />
</storages>

As we can see above, every storage element has two attributes:
  • Name – Name given to the storage account. This is a required attribute.
  • Key – Access key to the storage account. This is a required attribute.

Services – this element has no attribute either but it contains a list of child nodes according to the number of hosted services belonging to the Subscription and to be managed by Windows Azure Service Instances Auto Scaling. This is a required element with, at least one child node.

<services>
<hostedservice />
<hostedservice />
</ services >

It is within the Hosted Service element where all Schedules and all deployment information will be. Below we have a skeleton of a hosted service element and later will be described all child nodes.

<hostedservice name=”HostedServiceA” urlprefix=”hostedservicea” >
<schedules />
</deployments>
</hostedservice>

Hosted Service element has two attributes:
•Name – Hosted Service representative name on the XML. This is an option attribute.
•Urlprefix –Url Prefix (aka DNS Name) of the service. This is a required attribute.

This element besides the attributes also has two child nodes:
Schedules – List of schedules where each one can be used by one or more deployments of the hosted service. This is a required element with, at least on child node.

< schedules >
< schedule />
< schedule />
</ schedules >

Deployments – List of deployments to be managed by Windows Azure Service Instances Auto Scaling. This is a required element with, at least on child node.

<deployments >
< deployment/>
< deployment/>
</deployments>

Schedule Element

<schedule name="name of that schedule" default="1">
<description>
Description text…
</description>
<daysofweek>
<dayofweek name="Monday" />
<dayofweek name="Wednesday" />
</daysofweek>
<timelist>
<timeschedule instances="0" default="1" />
<timeschedule hour="5" minute="11" instances="1" />
</timelist>
</schedule>

This is an element with two attributes:
•Name – Schedule representative name on the XML. This name must be unique for every schedule element. This is a required attribute.
•Default –Is a Boolean with the value 1 for true and 0 for false. Schedule element with default attribute set to 0 means it will be used every time which a deployment role has no other schedule configured to be used at some instant. The default value of this attribute is 0 and this is an optional attribute.

Schedule element can have up to three child nodes.
Descripion – this element has no attributes and no child nodes. It only contains a description to make easier to distinct that schedule. This is an optional element.
Daysofweek – this element has no attributes. List of days of week where a schedule can be used. This is an optional element. If this element doesn’t exists the schedule can be used for every day of week, but a schedule element with this element has priority over a schedule with no days of week.
  • DayofWeek – this is a child node of daysofweek element. This element only has one attribute.
    • Name – Name of a day of week. This name must be written in English and extensively. This is a required attribute.
Timelist – this element is required for all schedule elements. Represents a list of child nodes where every child node contains time information and a number of instances associated to that time. This element must have at least one child node.
  • TimeSchedule – Number of active instances at some time of day. TimeSchedule element can have up to four attributes and has no child nodes.
    • Instances – Number of active instances. Integer bigger than 0. This is a required attribute.
    • Hour – Starting hour for this timeschedule. Integer bigger than 0. This is an optional attribute but, if this attribute doesn’t exist the default attribute must be set to 1.
    • Minute – Starting Minute for this timeschedule. Integer bigger than 0. This is an optional attribute. If this attribute is being used, the attribute Hour is required.
    • Default –Is a Boolean with the value 1 for true and 0 for false. Timeschedule element with default attribute set to 0 means that it will be used every time a schedule has no other timeschedule configured to be used at some instant of a day. The default value of this attribute is 0 and this is an optional attribute.

Deployment Element

<deployment name="test" storage="afdeployment" storagerelativepath="deployments/">
<topschedules>
<topschedule instances="1" initialhour="1" finalhour="1" initialminute="0" finalminute="2" />
<topschedule instances="3" initialhour="2" finalhour="3" >
<daysofweek>
<dayofweek name=”Monday” />
</daysofweek>
</topschedule>
<topschedule slot="production" initialhour="3" />
<topschedule stop="1" initialhour="3" finalhour="4" initialminute="1" />
<topschedule slot="staging" initialhour="4" />
<topschedule delete="1" initialhour="4" finalhour="5" finalminute="0" />
</topschedules>
<roles>
<role name="sss" maxinstances="2">
<schedule name="default" />
<schedule name ="s1" />
</role>
<role name="td" maxinstances="44" >
<schedule name="default" />
<schedule name ="ljaldsa" />
</role>
</roles>
</deployment>

This is an element with three attributes:
•Name – Name of the deployment. This name will be used on the deployment creation operation as the deployment label. This is a required attribute.
•Storage – Name of storage where the both deployment files, .cspkg and .cscfg, are being stored. This deployment storage attribute must match the name attribute of some storage element within its top subscription. This is a required attribute.
•Storagerelativepath – Relative path inside the storage account where are stored the deployment files. This is a required attribute.

Deployment element can have up to two child nodes.
Topschedules – Group of rules to be applied to all roles of this deployment. Such rules have priority over Time Schedule rules. This is an optional element. Every child node, Topschedule element, has up to six attributes.
  • Instances - Number of active instances for all roles. Integer bigger than 0. This is an optional attribute.
  • Stop – Rule to stop all deployment roles. This attribute must be set to 1. This is an optional attribute.
  • Delete - Rule to stop and delete all deployment roles and the deployment itself. This attribute must be set to 1.
  • Slot – Deployment environment. This attribute may have two distinct values: staging or production. This is an optional attribute.
  • Initialhour –Initial hour of the topschedule. This is a required attribute.
  • Finalhour –Final hour of the topschedule. This is a required attribute but there is an exception when used with the slot attribute, because in that case, the final hour attribute is not needed.
  • InitialMinute – Initial minute of the topschedule. This is an optional attribute but, if this attribute doesn’t exist the default value is 0.
  • FinalMinute –Final minute of the topschedule. This is an optional attribute but, if this attribute doesn’t exist the default value is 0.

This element can have a child node.
  • Daysofweek – this element is pretty much like schedule daysofweek element. The child nodes within this element will restrict this topschedule top rule for determined days of week.

Roles – Group of all roles of a specific deployment. This element has no attributes, but has at least one child node. This is a required element.
  • Role – this element contains all information needed for a role be managed by Windows Azure Service Instances Auto Scaling Worker Role.
This element has two attributes:
* Name - Name of the role. The Deployment Service Configuration file (*.cscfg) must have a role with the same name of this attribute value.
* Maxinstances – Maximum number of simultaneously active instances for a specific role. Integer bigger than 0 .This number will be used to limit the number of instances which can be activated by CPU load information.
This element contains a list of child nodes with at least one child node. These child nodes are the associated schedules to this role.
Schedule – this schedule element only have one attribute.
* Name – Same value as one schedule name attribute within the schedules list of the top subscription element.

Example of a valid XML Configuration File:

<?xml version="1.0" encoding="utf-8" ?>
<root>
<generalconfig>
scalingsecondsperloop="60"
scalinglogtablename="ScalingLogTable"
logtableentitiespartionkey="ScalingLogEntities"
diagnosticsupperthreshold="70"
diagnosticslowerthreshold="20"
diagnosticsminutestosampleaverages="2"
averagevmboottime="10"
minutestosleepafterincreasevmnumber="10"
minutestosleepafterdecreasevmnumber="10" />
<generalconfig />
<subscriptions>
<subscription name="SubName" id="93s8e-eca-r0-955-35ce6a09">
<storages>
<storage name="afdeployment" key="TiVlBPCoBkurCrH7w==" />
</storages>
<services>
<hostedservice name="Service Tester" urlprefix="servtester" >
<schedules>
<schedule name="default" default="1">
<description>
Default schedule
</description>
<timelist>
<timeschedule instances="1" default="1" />
<timeschedule instances="2" hour=”2” minute=”30” />
</timelist>
</schedule>
<schedule name="Other">
<daysofweek>
<dayofweek name=”Tuesday” />
</ daysofweek>
<timelist>
<timeschedule instances="5" hour=”4” minute=”30” />
</timelist>
</schedule>
</schedules>
<deployments>
<deployment name="test" storage="accountname" storagerelativepath="path/">
<topschedules>
<topschedule stop=”1” initialhour=”3” finalhour=”2”>
<topschedule slot=”production” initialhour=”18” >
</topschedules>
<roles>
<role name="WebRole1" maxinstances="3" >
<schedule name="default" />
<schedule name=" Other" />
</role>
<role name="WorkerRole1" maxinstances="4" >
<schedule name="default" />
</role>
</roles>
</deployment>
</deployments>
</hostedservice>
</services>
</subscription>
</subscriptions>
</root>

Last edited Apr 27, 2011 at 2:07 PM by axferr, version 13

Comments

No comments yet.