When we last left off, we had a web application spinning away in the cloud,
and a local console application watching it
and reacting to changes in demand. Reactions that were specified by a set of
rules. Let’s talk about those
rules.
Constraints. The first set of
rules this application answered to were the
constraints. Here is what they looked like: <constraintRules>
<rule name="default" enabled="true" rank="1" description="The default constraint rule">
<actions>
<range min="1" max="4" target="AutoscalingApplicationRole"/>
</actions>
</rule>
</constraintRules>
Pretty basic. We have one role, the “AutoscalingApplicationRole”,
and we have decided to have it live within a range of 1 to 4. This rule does not adjust, but instead, set’s limits on what other
rules can do. It has a rank, so you can have you can specify other sets of
constraints, perhaps based on time or date, to allow for deviations from this set. But for now, let’s keep it simple. In the real world, you would probably use the minimum to set a lower end SLA. A common value might be a 2, to prevent the reactive
rules from ever taking you down to 1 role. The maximum is often used to keep a rule from driving the cost up, setting an upper limit to prevent you waking up one morning
and find a bill for hundreds of instances you didn’t expect.
So, here we have the range we want our application to live inside. This is good for our investigation
and testing. Next, let’s take a look at the reactive
rules. These
rules are what you use to react (hence reactive rules) to changing demands on your application. The HOL has two simple
rules. One that looks at a queue depth,
and one that looks at a performance counter that reports cpu utilization. the XML in the
rules file looks like this:
<reactiveRules>
<rule name="ScaleUp" rank="10" description="Scale Up the web role" enabled="true">
<when>
<any>
<greaterOrEqual operand="Length_05_holqueue" than="10"/>
<greaterOrEqual operand="CPU_05_holwebrole" than="65"/>
</any>
</when>
<actions>
<scale target="AutoscalingApplicationRole" by="1"/>
</actions>
</rule>
<rule name="ScaleDown" rank="10" description="Scale down the web role" enabled="true">
<when>
<all>
<less operand="Length_05_holqueue" than="5"/>
<less operand="CPU_05_holwebrole" than="40"/>
</all>
</when>
<actions>
<scale target="AutoscalingApplicationRole" by="-1"/>
</actions>
</rule>
</reactiveRules>
<operands>
<performanceCounter alias="CPU_05_holwebrole" performanceCounterName="\Processor(_Total)\% Processor Time" source="AutoscalingApplicationRole" timespan="00:05:00" aggregate="Average" />
<queueLength alias="Length_05_holqueue" queue="hol-queue" timespan="00:05:00" aggregate="Average"/>
</operands>
These
rules are currently contained in a file called
rules.xml, that is in the root of the console application. The console app, starts up, grabs the
rules and starts watching the 2 operands. When it detects a rule has been satisfied, it performs the desired action. (here, scale up or down my 1).
But I want to host the autoscaler in the cloud. For my first trick, I will move the
rules (and another file called services.xml) to azure blob storage. Look for part 3.
