The Stabilizer

Retired Content

This content and the technology described is outdated and is no longer being maintained. For more information, see Transient Fault Handling.

The Stabilizer component is designed to prevent the Autoscaling Application Block from repeatedly performing scaling operations on the same role. For example, the block could scale up a role, and then when the rule evaluator runs again, try to scale up the same role again before the scaling action has had the desired effect. It is also possible that the block could cause oscillations: scaling up a role, then scaling it down, then scaling it up again, and so on.

Because Microsoft Azure takes time to perform scaling operations, there is already a built-in damping effect. Azure will not allow a change to the number of instances of a role while it is currently in the process of starting up new instances or closing down existing instances. However, even with this built-in damping effect, it is still necessary for the block to perform its own stabilization to ensure that the block does not perform unnecessary changes to the number of role instances.

To achieve this, during the rule evaluation activity, the block checks to see if any of the scaling operations proposed by the currently active rules will affect roles that the block has recently scaled. By default, the rule evaluator looks to see if the block has performed any scaling actions on a role during the last 20 minutes; this period is referred to as a "cool down" period. If the block has performed a scaling operation within the cool down period, then the block ignores the current scaling request. You can change the default time period for both scale up and scale down operations, and also change it for individual roles in the service information configuration.

The following chart shows the Autoscaling Application Block running without the stabilizer. It shows how the role instance count always changes in response to the scaling actions from the reactive rules.

Follow link to expand image

The autoscaling process without the stabilizer

The following chart shows the Autoscaling Application Block running over the same period with the stabilizer. The cool down period is set to two hours in this example. It shows how the block makes fewer changes to the role instance count. The block still enforces any constraint rules that override the cool down period.

Follow link to expand image

The autoscaling process with the stabilizer

In order to determine whether the block has previously performed a scaling operation on a role within the configured cool-down period, the block records role instance counts in the data point store. The stabilizer component can then check against the data point store to discover when the block last performed a scaling operation against a role.

The cool down period is measured from the time that the block records a change in the instance count in the data point store. The Metronome component runs the instance count collection activity every two minutes.

Last built: June 7, 2012