Udostępnij za pośrednictwem


Hosting the Autoscaling Application Block in a Worker Role

Retired Content

This content and the technology described is outdated and is no longer being maintained. For more information, see Transient Fault Handling.

patterns & practices Developer Center

On this page:
Usage Notes

This topic describes how to host the Autoscaling Application Block in a Microsoft Azure worker role. This is the most common deployment scenario for the block.

The Autoscaling Application Block uses rules to determine which scaling operations it should perform on your Azure application and when. You must have a running Autoscaler instance that can perform the scaling operations. The following code sample shows how you can start and stop an Autoscaler instance when a worker role starts and stops.

You may decide to include this logic in an existing worker role that also performs other tasks, or create a worker role that just performs the autoscaling activities.

Note

The worker role that performs the autoscaling activities can be in the same or a different hosted service from the application to which you are adding autoscaling behavior.

public class WorkerRole : RoleEntryPoint
{
    private Autoscaler autoscaler;

    ...

    public override bool OnStart()
    {
        // Set the maximum number of concurrent connections 
        ServicePointManager.DefaultConnectionLimit = 12;

        CloudStorageAccount.SetConfigurationSettingPublisher(
          (configName, configSetter) =>
          configSetter(RoleEnvironment.GetConfigurationSettingValue(configName)));

        DiagnosticMonitorConfiguration dmc = 
          DiagnosticMonitor.GetDefaultInitialConfiguration();
        dmc.Logs.BufferQuotaInMB = 4;
        dmc.Logs.ScheduledTransferPeriod = TimeSpan.FromMinutes(1);
        dmc.Logs.ScheduledTransferLogLevelFilter = LogLevel.Verbose;
        DiagnosticMonitor.Start(
          "Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString", dmc);
        
        autoscaler = 
         EnterpriseLibraryContainer.Current.GetInstance<Autoscaler>();
        autoscaler.Start();


        return base.OnStart();
    }

    public override void OnStop()
    {
        autoscaler.Stop();
    }
}

Note

If you decide to host the block in the same worker role as your application, you should get the Autoscaler instance and call the Start method in the Run method of the WorkerRole class instead of in the OnStart method.

To understand and troubleshoot the block's behavior, you must use the log messages that the block writes. To ensure that the block can write log messages, you must configure logging for the worker role. By default, the block uses the logging infrastructure from the System.Diagnostics namespace. The block can also use the Enterprise Library Logging Application Block or a custom logger.

Note

When you call the Start method of the Autoscaler class, the block attempts to read and parse the rules in your rules store. If any error occurs during the reading and validation of the rules, the block will log the exception with a "Rules store exception" message and continue. You should correct the error condition identified in the log message and save a new version of the rules to your rules store. The block will automatically attempt to load your new set of rules.
By default, the block checks for changes in the rules store every 30 seconds. To change this setting, see the topic "Entering Configuration Information."

For more information about how to configure the System.Diagnostics namespace logger or the Enterprise Library Logging Application Block logger, see the topic "Autoscaling Application Block Logging."

For more information about how to select the logging infrastructure that the Autoscaling Application Block should use, see the topic "Entering Configuration Information."

When the block communicates with the target application, it uses a service certificate to secure the Azure Service Management API calls that it makes. The administrator must upload the appropriate service certificate to Azure. For more information, see the topic "Deploying the Autoscaling Application Block."

Usage Notes

Here is some additional information:

  • For more details of the integration of Enterprise Library and Unity, see "Creating and Referencing Enterprise Library Objects."

  • If you have multiple instances of your worker role, then the Autoscaler class can use a lease on an Azure blob to ensure that only a single instance of the Autoscaler can execute the autoscaling rules at any one time. See the topic "Entering Configuration Information" for more details.

    Note

    The default setting is that the lease is not enabled. If you are planning to run multiple instances of the worker role that hosts the Autoscaling Application Block, you must enable the lease.

  • The block uses the FromConfigurationSetting method in the Azure Storage API to read connecting strings from the .cscfg file. Therefore, you must call the SetConfigurationSettingPublisher method, as shown in the sample code.

  • It is important to call the Stop method in the Autoscaler class when the worker stops. This ensures that the block releases its lease on the blob before the role instance stops.

  • The block uses information collected by Azure diagnostics to evaluate some reactive rules.

Next Topic | Previous Topic | Home

Last built: June 7, 2012