I gave an Autoscaling Azure talk at the Brisbane Azure User Group (BAUG) on the 18th April 2012. This series of posts will walk through the demo I put together for the talk using the Autoscaling Application Block (WASABi).
- Part 1 – Target Application (Build and Deploy)
- Part 2 – Autoscaler (Build)
- Part 3 – Autoscaler (Configure Autoscaling Block)
- Part 4 – Autoscaler (Configure Service Information Store)
- Part 5 – Autoscaler (Configure Rules Store)
- Part 6 – Autoscaler (Run and Monitor)
What are we configuring?
We will be configuring the rules in the file based rules store. This store holds the rules that the autoscaler will utilise in scaling our service.
Add Rules Store
Right click on the ConsoleAutoscaler project and select Add New Item > XML File. Name the newly created xml file local-rules-store.xml. Right click on the xml file and select Properties. Ensure that the Copy to Output Directory property has a value of Copy if newer.
Open the local-rules-store.xml file, right click in the content window and select Properties. In the XML Document properties window select the Schemas property and then click on the ellipses to select the schema. Select the AutoscalingRules.xsd schema from the resulting list and in the Use column set the property value to Use this schema.
Clicking OK should result in the Solution Explorer showing the AutoscalingRules.xsd schema as linked to the local-rules-store.xml file. This will also now provide intellisense when editing this file.
Paste the xml below into your local-rules-store.xml file.
<?xml version="1.0" encoding="utf-8" ?> <rules xmlns="http://schemas.microsoft.com/practices/2011/entlib/autoscaling/rules" enabled="true"> <constraintRules> <rule name="Default" enabled="true" rank="1"> <actions> <range target="WasabiDemoWebRole" min="1" max="3" /> </actions> </rule> </constraintRules> <reactiveRules> <rule name="Heavy Load (Increase)" enabled="true"> <actions> <scale target="WasabiDemoWebRole" by="1" /> </actions> <when> <greaterOrEqual operand="QueueLength_Avg_5m" than="5" /> </when> </rule> <rule name="Heavy Load (Decrease)" enabled="true"> <actions> <scale target="WasabiDemoWebRole" by="-1" /> </actions> <when> <less operand="QueueLength_Avg_5m" than="5" /> </when> </rule> </reactiveRules> <operands> <queueLength alias="QueueLength_Avg_5m" aggregate="Average" queue="workerqueue" timespan="00:05:00" /> </operands> </rules>
Lines 4-12 contain the constraint rules. These rules take precedence over the reactive rules. The autoscaling block expects at least one constraint rule to be active when rules are evaluated. If not, no scaling operation will be performed. The upper bound of the constraint rules guard your budget and the lower bound guards your SLA. It is good practice to always include a default constraint rule.
I have added a simple constraint rule that has a rank of 1 (the highest – so effectively the catch all rule). The rule constrains the instance range of my WasabiDemoWebRole to between 1 and 3 instances. You can also add a timetable for your constraint rule. For example during your known busy periods you can pro-actively scale up instances and outside of this busy period scale back down.
Lines 14-34 contain the reactive rules. These rules allow you to react to load or demand. The reactive rules, out the box, can monitor the value of performance counters, Windows Azure queue lengths and instance counts. You can also create custom-defined business metrics to scale the application when those values exceed specified thresholds.
The reactive rules allow you to scale instances or to switch your application into different operating states if you have written your application to cater for application throttling. Application throttling is managed via application settings in the configuration file.
I have added two simple reactive rules. One that scales my WasabiDemoWebRole up by one and a paired rule that performs the scaling down by one. It is good practice to have a pair of reactive rules – one for scaling up and one for scaling back down. My reactive rules both monitor the QueueLength_Avg_5min operand. This operand is defined between lines 36-38 as the average queue length over 5 min of the workerqueue storage account queue. If this value is greater than or equal to 5 the rules scale the WasabiDemoWebRole up by one instance and if this value is less than 5 the rules scale down the WasabiDemoWebRole by one instance.
The Rules Store is now configured. Next up we will be running the autoscaler and observing how the queue length of the workerqueue storage account queue and the rules affect the number of instances of the WasabiDemoWebRole.