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 a 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, Auto Scaling perform the following operations:
  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 in the scaling group.
  5. Assign IP addresses to the added ECS instances.
  6. Add the ECS instances to the whitelist of the ApsaraDB for RDS instance.
  7. Start the 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 active scaling configuration of the scaling group.
  9. The cooldown period starts after the scaling activity is complete.
When ECS instances are automatically removed from a scaling group after a scaling rule is executed, Auto Scaling perform the following operations:
  1. Check the health status and boundary conditions of the scaling group.
  2. Assign the activity ID and execute the scaling activity.
  3. Remove the 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 in the scaling group.
  8. The cooldown period starts after the scaling activity is complete.

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

When ECS instances are manually added to a scaling group, Auto Scaling perform the following operations:
  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 the ECS instances to the scaling group.
  4. Modify the number of instances in 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 complete.
When existing ECS instances are manually removed from a scaling group, Auto Scaling perform the following operations:
  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 in the scaling group.
  7. Remove the ECS instances from the scaling group.
  8. The cooldown period starts after the scaling activity is complete.

Status of a scaling activity

The following table describes the states that a scaling activity may undergo.
Status Description Reference
Rejected The scaling activity is rejected in the request phase and does not perform the scale-in or scale-out action. Scenarios:
  • 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 is rejected. No subsequent processes are followed. After the scaling activity is complete, the number of instances in the scaling group is still 100.

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

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

Scenarios:
  • 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 is complete, the number of instances in the scaling group is changed to 100.

Successful The scaling activity is complete, and all 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 is complete, the number of instances in the scaling group is changed to 100.

Warning The scaling activity is complete. At least one ECS instance is added to or removed from the scaling group, while at least one ECS instance fails to be added to or removed from the scaling group.

An ECS instance is considered to be added to the scaling group if the instance is 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 in the scaling group are automatically added to the backend server group of the SLB instance.
  • The quota for 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 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. However, four ECS instances fail to be added to the backend server group and cannot be added to the scaling group because the quota for backend servers of the SLB instance is 200. After the scaling activity is complete, only one instance is added to the scaling group. The number of instances in the scaling group is 200.

Failed The scaling activity is complete, and all ECS instances fail to be added to or removed from the scaling group. Scenario:
  • The instance types specified by the active 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 fail to be created due to insufficient resources. After the scaling activity is complete, no instances are added to the scaling group. The number of instances in the scaling group is still 95.

ECS instance rollback

When some ECS instances fail to be added to a scaling group during a scaling activity, Auto Scaling prioritizes the integrity of the ECS instances over that of the scaling activity. Auto Scaling will roll back the ECS instances that fail to be added to the scaling group, 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 are still charged after they are created and before they are automatically released.

For example, you want to add five ECS instances to a scaling group and to the backend server group of the SLB instance associated with the scaling group. After the five instances are created, two instances are added to the scaling group, and three instances fail to be added and are automatically released. After the scaling activity is complete, its status is Warning.

When ECS instances in a scaling group are rolled back, the scaling group does not reach its expected capacity. This means that the scaling group cannot provide the required computing power and maintain monitoring metrics at the required values. 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 event-triggered tasks to trigger a scaling activity.