A scaling activity is triggered when a scaling rule is executed or when an instance is manually added to or removed from a scaling group. After a scaling activity is triggered, the system performs a scale-in or scale-out action. This topic describes the process of a scaling activity, its status, and instance rollback.

Process of the scaling activity when ECS instances are automatically added or removed

When ECS instances are automatically added to a scaling group after a scaling rule is executed:
  1. Check the health status and boundary conditions of the scaling group.
  2. Assign the activity ID and execute the scaling activity.
  3. Create ECS instances.
  4. Modify the number of instances of the scaling group.
  5. Allocate IP addresses to the added ECS instances.
  6. Add the ECS instances to the whitelist of the ApsaraDB for RDS instance.
  7. Start ECS instances.
  8. Add the ECS instances to the backend server group of the SLB instance, and set the weights of these ECS instances to the values specified by the scaling configuration of the scaling group.
  9. The cooldown period starts after the scaling activity is completed.
When ECS instances are automatically removed from a scaling group after a scaling rule is executed:
  1. Check the health status and boundary conditions of the scaling group.
  2. Assign the activity ID and execute the scaling activity.
  3. Remove ECS instances from the backend server group of the SLB instance.
  4. Stop the ECS instances.
  5. Remove the ECS instances from the whitelist of the ApsaraDB for RDS instance.
  6. Release the ECS instances.
  7. Modify the number of instances of the scaling group.
  8. The cooldown period starts after the scaling activity is completed.

Process of the scaling activity when existing ECS instances are manually added or removed

When existing ECS instances are manually added to a scaling group:
  1. Check the health status and boundary conditions of the scaling group, and check the status and types of ECS instances.
  2. Assign the activity ID and execute the scaling activity.
  3. Add ECS instances to the scaling group.
  4. Modify the number of instances of the scaling group.
  5. Add the ECS instances to the whitelist of the ApsaraDB for RDS instance.
  6. Add the ECS instances to the backend server group of the SLB instance and set the weights of these ECS instances to the values specified by the active scaling configuration of the scaling group.
  7. The cooldown period starts after the scaling activity is completed.
When existing ECS instances are manually removed from a scaling group:
  1. Check the health status and boundary conditions of the scaling group.
  2. Assign the activity ID and execute the scaling activity.
  3. The SLB instance stops forwarding traffic to the ECS instances.
  4. Wait 60 seconds, and remove the ECS instances from the backend server group of the SLB instance.
  5. Remove the ECS instances from the whitelist of the ApsaraDB for RDS instance.
  6. Modify the number of instances of the scaling group.
  7. Remove the ECS instances from the scaling group.
  8. The cooldown period starts after the scaling activity is completed.

Status of a scaling activity

A scaling activity may undergo the status described in the following table.
Status Description Example
Rejected The scaling activity is rejected in the request phase and does not perform the scale-in or scale-out action. Scenario:
  • The maximum number of instances in the scaling group is 100.
  • The scaling group already has 100 ECS instances.
  • A scaling rule is executed to automatically create 10 ECS instances.

Result: The scaling activity fails the condition check and the system rejects the activity. No subsequent processes are followed. After the scaling activity ends, the number of instances in the scaling group is still 100.

In Process The scaling activity passes the condition check and is in progress.

Auto Scaling automatically scales in or out the ECS instances based on the maximum and minimum numbers of instances in the scaling group.

Scenario:
  • The maximum number of instances in the scaling group is 100.
  • The scaling group already has 95 ECS instances.
  • A scaling rule is executed to automatically create 10 ECS instances.

Result: The scaling activity passes the condition check and is performed. Only five ECS instances are automatically created. After the scaling activity ends, the number of instances in the scaling group changes to 100.

Successful The scaling activity is completed, and all target ECS instances are added to or removed from the scaling group. Scenario:
  • The maximum number of instances in the scaling group is 100.
  • The scaling group already has 90 ECS instances.
  • A scaling rule is executed to automatically create 10 ECS instances.

Result: The scaling activity passes the condition check and is performed. After the scaling activity ends, the number of instances in the scaling group changes to 100.

Warning The scaling activity is completed, and at least one ECS instance is added to or removed from the scaling group, but at least one ECS instance is not added to or removed from the scaling group.

An ECS instance is considered to be added to the scaling group if the instance is successfully created, added to the backend server group of the SLB instance, and then added to the whitelist of the ApsaraDB for RDS instance. If any step fails, the instance is not considered to be added to the scaling group.

When an instance fails to be added to a scaling group, the instance will be rolled back. For more information, see ECS instance rollback.

Scenario:
  • The scaling group is associated with an SLB instance. All created ECS instances will be automatically added to the backend server group of the SLB instance.
  • The quota of the backend servers of the SLB instance is 200.
    Note For more information, see Limits.
  • The maximum number of instances in the scaling group is 300.
  • The scaling group already has 199 ECS instances that are added to the backend server group of the SLB instance.
  • A scaling rule is executed to automatically create five ECS instances.

Result: The scaling activity passes the condition check and is performed to create five ECS instances. Because the quota of backend servers is 200, four ECS instances failed to be added to the backend server group, and therefore cannot be added to the scaling group. After the scaling activity ends, only one instance is added to the scaling group. The number of instances in the scaling group is 200.

Failed The scaling activity is completed, and all target ECS instances fail to be added to or removed from the scaling group. Scenario:
  • The instance types specified by the scaling configuration are out of stock in the region where the scaling group resides.
  • The maximum number of instances in the scaling group is 100.
  • The scaling group already has 95 ECS instances.
  • A scaling rule is executed to automatically create five ECS instances.

Result: The scaling activity passes the condition check and is performed. The five instances failed to be created due to insufficient resources. After the scaling activity ends, no instances are added to the scaling group. The number of instances in the scaling group is still 95.

ECS instance rollback

When a scaling activity fails to complete, the system prioritizes the integrity of the ECS instances over that of the scaling activity. The system will roll back the ECS instances that failed to be added or removed, but not the scaling activity. Auto Scaling uses Alibaba Cloud Resource Access Management (RAM) to call ECS API operations to create ECS instances. ECS instances that are rolled back still incur fees for the duration of their creation to release.

For example, a scaling group wants to add five ECS instances to the backend server group of an SLB instance. After the five instances are created, only one instance is added to the scaling group, and the other four instances are not added and are automatically released. After the scaling activity ends, the status is Warning.

When the ECS instances are rolled back, the scaling group does not reach its expected capacity. This means that the scaling group is unable to provide the required computing power and achieve the required monitoring metrics. In this case, you can use other methods to ensure that the scaling group can provide the required computing power for your business needs. For example, you can manually trigger scaling rules, manually add existing ECS instances to the scaling group, or configure scheduled or monitoring tasks to trigger a scaling activity.