Managing Alarm Triggering Policies

Overview

AS supports scaling out the number of instances in the scaling group dynamic based on monitored metrics. You need to define an alarm-triggering policy, that is, the monitoring indicator state that triggers scaling-out and how to scale according to demand changes.
To create an alarm policy, you need to specify conditions and actions:

• Conditional Format: A certain metric + threshold + cycle + the number of consecutive cycles that reach the threshold. That is, the metric reaches the threshold for N consecutive periods.
• Execution Actions: Send notification + increase/decrease the specified number of CVM.
  We recommend that you create two policies for each scaling group: One for scaling-out and another for scaling-in. When the business volume reaches the conditions specified by the alarm policy, the AS executes the associated policy to scale-in (by terminating instances) or scale-out (by launching instances) the scaling group.

Scenario Example

For example, you have an e-commerce website application and currently use five instances. You have done an operation activity and are worried that the traffic will be much greater than you estimated. You can set it to launch two additional instances when the load on the current instance rises to 70% and then terminate the excess instances when the load drops to 40%. You can configure a scaling group to automatically scale-out based on these conditions.

Operation step

1. Open the auto scaling console and select Scaling Group in the sidebar.
2. Select the scaling group to be modified and click Scaling Group ID/Name to go to the scaling group basic information page.
3. Select the Alarm Triggered Policy in the sidebar above to manage the alarm trigger policy associated with the scaling group.
   • Click Create to add a new alarm trigger policy;
   • Click Delete to delete the alarm trigger policy;
     

Specifying a Server That is Not Affected by the Alarm Scaling Policy

Before using auto scaling, your system may already have frequently used servers, and you may not want the machines to be removed by the alarm scaling policy for the following reasons:

• Multi-purpose machine: In addition to its role in the cluster, a server may also serve other purposes. For example, during the early stages of WDS, a server could be used both as a cache/caching server and as a file server. When such cache/caching servers are placed in a scaling group, you might not want them to be removed by the alert scaling strategy.
• Store Data: This server is stateful or has data that other servers do not have. For example, the incremental data generated during the running of other servers in the cluster are all saved in this server.
• Update Image/Snapshot: Use this server regularly for mirroring and snapshots.
  Setting Method:

1. You can click the scaling group where the server is located in the scaling group list to enter the management page.
2. In the Instance List at the bottom of the management page, click Enable Removal Protection for the instance you want to set.