Showing posts with label Application Blocks. Show all posts
Showing posts with label Application Blocks. Show all posts

Thursday, May 17, 2012

Autoscaling Application Blocks


Autoscaling Application blocks can automatically scale the Windows Azure application based on the rules defined specifically for the application. The Autoscaling application Block supports two autoscaling mechanisms:

1)      Instance Autoscaling, where the block changes the number of role instances based on constraint and reactive rules.
2)      Throttling, where the application modifies its own behavior to change its resource utilization based on set of reactive rules. For example switching off non-essential features, or gracefully degrading its UI.

So, there are two types of rules:

1)      Constraint rules: Constraint rule set the upper and lower bounds on the number of instances. For example, in evening between 6:00 and 8:00, you need a minimum of 3 instances and a maximum of 7 instances, then use constraint rule.
2)      Reactive rules: Reactive rule enables the number of role instances to change in response to unpredictable changes in demand. For example, if workload increases then increase the number of role instances by 1. The reactive rules can use a variety of techniques like performance counters, or windows azure queue length to monitor and control application’s workload. A reactive rule makes changes to the number of role instances only if a constraint rule applies at the same time. It is easy to create a default constraint rule that always applies.

While defining target of an autoscaling rule, you can identify a scale group instead of an individual role. A Scale group enables you to define autoscaling rules that target multiple roles. A scale group can have any number of roles.

Following is an example rule xml. In this there are two constraint rules. One is always active and default constraint. While other only become active at peak time daily at 6 for 2 hours, and overrides the default rule. There are two reactive roles:  One will increase the instance count by 1 if the average CPU power usage for last 30 minutes is over 70%, while the other one decrease the instance count by 1 if the average CPU usage for last 30 minutes is less than 30%.

<rules xmlns="http://schemas.microsoft.com/practices/2011/entlib/autoscaling/rules" enabled="true">
<constraintRules>
       <rule name="Default" description="Always active" enabled="true" rank="1">
              <actions>
                     <range min="2" max="5" target="RoleA"/>
              actions>
       rule>

       <rule name="Peak" description="Active at peak times" enabled="true" rank="100">
              <actions>
                     <range min="3" max="7" target="RoleA"/>
              actions>
              <timetable startTime="06:00:00" duration="02:00:00">
                     <daily/>
              timetable>
       rule>
constraintRules>

<reactiveRules>
       <rule name="ScaleUp" description="Increases instance count" enabled="true" rank="10">
              <when>
                     <greater operand="Avg_CPU_RoleA" than="70"/>
              when>
              <actions>
                     <scale target="RoleA" by="1"/>
              actions>
       rule>
       <rule name="ScaleDown" description="Decreases instance count" enabled="true" rank="10">
              <when>
                     <less operand="Avg_CPU_RoleA" than="30"/>
              when>
              <actions>
                     <scale target="RoleA" by="-1"/>
              actions>
       rule>
reactiveRules>

<operands>
       <performanceCounter alias="Avg_CPU_RoleA" performanceCounterName="\Processor(_Total)\% Processor Time" aggregate="Average" source="RoleA" timespan="00:30:00"/>
operands>
rules>

Conflicting Rules
1)      Conflicting Constraint and Reactive rules: A constraint rule always overrides a reactive rule.
2)      Conflicting Constraint rules: If two or more constraint rule includes timetables that specify they are active at the same time then
a)      The rule with highest rank is given priority.
b)       If two or more constraint rules of same rank conflict, then block will perform the action from first constraint rule it finds.
3)      Conflicting Reactive rules: If two or more reactive rules results in conflicting changes to number of role instances then
a)      The rule with highest rank is given priority.
b)      If two or more reactive rules of same rank conflict, then if any rule suggests increase in number of instances, then largest increase is used.
c)       If two or more reactive rules of same rank conflict, then if any rule suggests decrease in number of instances, then lowest decrease is used.
For example if one rule suggest increase the no. of instances by one, another suggest increase the number by two, and another suggest decrease the number by one, then the number will increase by two. Another example, if one rule suggest decrease in number of instances by one, another suggest decrease in number by three, then number of instances will decrease by one.
4)      Conflicting actions on scale group: It is possible that multiple rules could suggest different scaling actions on same target at same time, either because same role is member of different scale group or so. In that case, it uses same logic as it is used in conflicting reactive rules.

Thursday, October 13, 2011

Logging Application Block

First we need to know what application blocks are?
Application Blocks are reusable software components and are part of Microsoft’s Enterprise Library. Enterprise library provides configurable features to manage crosscutting concerns like validation, logging, exception management etc. Here I elaborate on one of the feature of Enterprise Library- Logging Application Block. One can use the Logging Application Block to log information to:
1)      Event logs
2)      A text file
3)      An email message
4)      A database
5)      A message queue
6)      Windows Management Instrumentation (WMI) event
7)      Customize the logging location
In this article we will see how to configure the logging. One need to install the Enterprise Library.
Create a windows form application. Now add a reference of Enterprise Library Logging Application Block to the solution.

Now add a configuration file for configuring the log. Now edit it with Enterprise Library Configuration.


It opens a window. In that select Blocks -> Add Logging Settings


It creates a default logging settings as follows:


It contains a category named “General”, which is using an “Event Log Listener” with a “Text Formatter”. For now we can leave Special Categories. So, what all these are doing?

Let’s understand it with an example. There may be some logs which you need to write in event log and a text file, and for some log you need to mail also. So you create one category which writes all logs to event log and text file, and another category for sending mail of only error logs. Then you have to create 3 listeners, for logging in event log, text file and mailing. You can also define different formatters for different type of listeners. For example you need a detailed log for logging in events log and precise log for mailing. All these settings are defined in the configuration. All you need to do is when you write a log just defines the category of the log and rest is done by the application block.

Categories:
Category can filter the log entry and route it to different listeners. The filter can be based on the severity, i.e., Critical, Error, Warning or Information.

Logging Target Listeners:
Different listeners can be defined here. We only need to do configuration and these listeners can write to event logs, a flat file, xml file, to database, send mail etc.

Log Message formatters:
This is used to define a format in which log is written. Text formatter is the default formatter, which writes all the information. For customizing the formatter, define a template.
A sample project is uploaded. This contains a general category which logs to event logs and a flat file using text formatter. And mail category which sends mail using mail formatter. And depending on the conditions it logs to general category, or sends mail, or can do both.

So now you can see a configuration section “loggingConfiguration” in the app.config file.
This configuration section contains listeners, formatters, categorysources and specialSources. One can configure listener, formatter, categories here.

To write a log you just need to create a LogEntry and specify the category. Of category is not specified, log will be written to default category.
So, now you can see logging so easy using Application blocks.