ComprarBuy
1-855-856-7678
SuporteSupport
EN
Este conteúdo não está disponível em seu idioma, mas aqui está a versão em inglês.
Hosting the Scaling Engine
Updated: October 5, 2011
Author: http://msdn.microsoft.com/pt-br/library/windowsazure/hh307529
Learn more about RBA Consulting.
Using the Scaling Engine
After a scaling engine is in place, it is time to revisit the original scalability issues that brought about the need for a scaling engine in the first place. The most challenging part of building a scaling engine may be how to configure the providers that represent the scaling rules. However, first classifying the application’s load into one of the four known patterns (On and Off, Growing Fast, Predictable Bursting, and Unpredictable Bursting) will make this configuration easier.
For on and off loads, a scaling engine is not appropriate because the scaling engine requires a deployed application to manage. If an application with an on and off load runs with a deployed package during inactive periods, then the load itself may be closer to the Predictable Bursting pattern. For fast-growing loads, the PerformanceCounterMetricProvider provider's configuration might include moderate levels that are above the threshold. However, the low threshold could have a very long duration. This is to prevent the application from being scaled down, because it is assumed that the load will continue to increase and never decrease.
On the other hand, both predictable and unpredictable bursting loads can use load-based scaling rules such as the PerformanceCounterScalingLogicProvider. This provider handles both these types of load very well because it can detect the changes in the load. If timing that is more accurate is required and the load is predictable, developers can use a provider that implements time-based scaling rules rather than the PerformanceCounterScalingLogicProvider. These providers can contain more aggressive above-threshold levels because their below-threshold limits allow these applications to scale down.
In order to tweak these configuration values, the scaling logic providers provide diagnostic data. The data includes information about the encountered thresholds, and the durations that prompted the scaling action. This tweaking process may involve some iteration, but once the levels are set, they may not require additional changes until the application performance or the load properties changes.
Hosting the Scaling Engine
The scaling engine interacts with Windows Azure Management APIs through HTTP and with the appropriate keys and certificate. The engine only requires that the target application collect and transfer performance counters when applicable. Because of this, the scaling engine offers many hosting options. In fact, the scaling engine can run on any Windows platform that is connected to the Internet.
On-Premises
For cloud-enabled applications with on-premises support of a manageable infrastructure, the scaling engine can be provided as a service or a desktop application. This means that a compiled executable can be distributed to a server and configured with the proper connection strings and certificate. The portability of this solution allows other project members to manage the scalability of the system. Additionally, tweaking the scaling rules (the provider thresholds) can be performed more frequently by simply restarting the application. For infrastructures that have very secure firewalls, the application needs to be granted access to the Windows Azure Service Management API URL, and to the table storage URL, which is the location of the WADPerformanceCountersTable table.
If the scaling engine is packaged as an executable such as a console application, then the hosting application must target a framework that is not a Client Profile because the engine uses assemblies in the ASP.NET and the advanced WCF domains. The subset of assemblies that comprise the .NET Framework Client Profile does not include assemblies such as System.Web and System.ServiceModel.Web. This is a very minor change for the hosting application, although an important one.
Using an Existing Role
If on-premises support is not available or is not appropriate, the scaling engine can be incorporated in the target application. The scaling engine contains logic to start as a singleton. This ensures that when you use an existing role, the scaling engine only runs on the first instance (instance zero). The first instance guarantees that the scaling engine exists until the deployed environment is deleted. This type of hosting offers a cost-free option because it does not rely on the infrastructure or additional roles. In return, the system sacrifices some resources to the first instance from the additional computational and storage requirements of the scaling engine.
 Important |
|---|
| The scaling engine requires the management certificate to operate. Thus, running the scaling engine from within an existing role means that the management certificate must be deployed with the role. You should consider the risks of deploying your management certificate in the cloud as it may introduce a security risk. For example, someone who gains access to the role could download the management certificate. |
Using a Separate Role
This option is similar to the previous option of using an existing role in that it is appropriate when on-premises support may not be available. However, this option uses an entirely separate role to prevent any resource demands on the first instance. Clearly, this option carries the additional cost of running an extra role. Fortunately for applications that require this type of hosting, the Windows Azure’s pricing model includes an Extra Small instance that provides a 1.0 GHz CPU and 768 MB of memory that costs $0.05 per hour ($1.20 per day). This size is acceptable, despite the I/O performance rating of Low, if you consider that the scaling engine only issues HTTP requests when it reads table storage or invokes the management APIs.
Certificates
A certificate is required to access the set of Windows Azure Management APIs. For on-premises hosting solutions, the installation of the certificate is straightforward. Right-click the certificate (.pfx) file and click Install. When you use either an existing or a separate role as the host for the scaling engine, the certificate must be included in the deployment. If you use Visual Studio to configure the deployment, you can include the certificate by accessing the property page for the role and navigating to the Certificates tab. From there, you can add the certificate to the role so that it is available when the scaling engine looks it up (the code examples in this article use the certificate's thumbprint to look it up. The following illustration shows the certificate's location in Visual Studio from where you can upload it to Windows Azure.
Final Words
Windows Azure provides its applications with the benefit of scalability. By incorporating a scaling engine into these web applications, you gain many advantages. A scaling engine not only enhances the throughput and responsiveness of the system, but it maximizes the use of each running instance. A scaling engine minimizes the headroom, which translates into lower costs. You can save even more by selecting the appropriate hosting option. Moreover, an extensible scaling engine allows developers to create providers that have scaling rules tailored to their applications.
