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.
