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.
