Autoscaling Application Blocks WIndows Azure

Autoscaling Application Blocks can automatically scale the Windows Azure application based on the rules defined specifically for the application.

The Autoscaling Application Block supports two autoscaling mechanisms:

Instance Autoscaling, where the block changes the number of role instances based on constraint and reactive rules.
Throttling, where the application modifies its own behavior to change its resource utilization based on a set of reactive rules. For example switching off non-essential features, or gracefully degrading its UI.

So, there are two types of rules:

Constraint rules: Constraint rules set the upper and lower bounds on the number of instances. For example, in the evening between 6:00 and 8:00, you need a minimum of 3 instances and a maximum of 7 instances, then use the constraint rule.
Reactive rules: Reactive rules enable the number of role instances to change in response to unpredictable changes in demand. For example, if the workload increases then increase the number of role instances by 1. The reactive rules can use a variety of techniques like performance counters, or the Windows Azure queue length to monitor and control the application's workload. A reactive rule makes changes to the number of role instances only if a constraint rule applies at the same time. It is easy to create a default constraint rule that always applies.

While defining the target of an autoscaling rule, you can identify a scale group instead of an individual role. A Scale group enables you to define autoscaling rules that target multiple roles. A scale group can have any number of roles.

The following is an example of a rule XML. In this there are two constraint rules. One is always active and the default constraint. While another only becomes active at peak time daily at 6 for 2 hours, and overrides the default rule. There are two reactive roles: One will increase the instance count by 1 if the average CPU power usage for the last 30 minutes is over 70%, while the other one decreases the instance count by 1 if the average CPU usage for the last 30 minutes is less than 30%.

<rules xmlns="http://schemas.microsoft.com/practices/2011/entlib/autoscaling/rules" enabled="true">
<constraintRules>
<rule name="Default" description="Always active" enabled="true" rank="1">
<actions>
<range min="2" max="5" target="RoleA"/>
</actions>
</rule>

<operands>
<performanceCounter alias="Avg_CPU_RoleA" performanceCounterName="\Processor(_Total)\% Processor Time" aggregate="Average" source="RoleA" timespan="00:30:00"/>
</operands>
</rules>

Conflicting Rules

Conflicting Constraint and Reactive rules: A constraint rule always overrides a reactive rule.
Conflicting Constraint rules: If two or more constraint rules includes timetables that specify they are active at the same time then:

a) The rule with highest rank is given priority.

b) If two or more constraint rules of the same rank conflict, then the block will perform the action from the first constraint rule it finds.
Conflicting Reactive rules: If two or more reactive rules results in conflicting changes to a number of role instances then:

a) The rule with highest rank is given priority.

b) If two or more reactive rules of the same rank conflict, then if any rule suggests an increase in the number of instances, then the largest increase is used.

c) If two or more reactive rules of the same rank conflict, then if any rule suggests a decrease in the number of instances, then the lowest decrease is used.

For example if one rule suggest increasing the number of instances by one, another suggests increasing the number by two and another suggests decreasing the number by one, then the number will increase by two. Another example; if one rule suggests decreasing the number of instances by one and another suggests decreasing the number by three, then the number of instances will decrease by one.
Conflicting actions on scale group: It is possible that multiple rules could suggest different scaling actions on the same target at the same time, either because same role is a member of a different scale group or so. In that case, it uses the same logic as is used in conflicting reactive rules.