Scaling activities
Scaling activities are triggered when scaling rules execute or when you manually add or remove ECS or ECI instances. Auto Scaling automatically completes all resulting scale-out and scale-in actions, including instance creation, removal, and rollback.
Scaling activity workflow
Automatic scaling workflow
-
Automatic ECS instance creation
-
Checks the health status and boundary conditions of the scaling group, such as the maximum instance count or minimum instance count.
-
Assigns a scaling activity ID and executes the scaling activity.
-
Creates ECS instances.
-
Updates the instance count in the scaling group.
-
Assigns IP addresses to the ECS instances.
-
(Optional) Adds the ECS instances to the ApsaraDB for RDS instance whitelist.
-
Starts the ECS instances and waits for them to start up.
-
(Optional) Adds the ECS instances to the backend server group of a Classic Load Balancer (CLB) instance. Their weight is set to the value specified in the scaling configuration.
-
The scaling activity is complete. The cooldown starts.
-
-
Automatic ECS instance removal
-
Checks the health status and boundary conditions of the scaling group, such as the maximum instance count or minimum instance count.
-
Assigns a scaling activity ID and executes the scaling activity.
-
(Optional) Removes the ECS instances from the backend server group of the Classic Load Balancer (CLB) instance.
-
Stops the ECS instances and waits for them to stop.
-
(Optional) Removes the ECS instances from the ApsaraDB for RDS instance whitelist.
-
Releases the ECS instances.
-
Updates the instance count in the scaling group.
-
The scaling activity is complete. The cooldown starts.
-
Manual scaling workflow
-
Manually adding ECS instances
-
Checks the health status and boundary conditions of the scaling group, such as the maximum instance count or minimum instance count, and the status and type of the ECS instances.
-
Assigns a scaling activity ID and executes the scaling activity.
-
Adds the ECS instances to the scaling group.
-
Updates the instance count in the scaling group.
-
(Optional) Adds the ECS instances to the ApsaraDB for RDS instance whitelist.
-
(Optional) Adds the ECS instances to the backend server group of a Classic Load Balancer (CLB) instance. The weight is set to the value specified in the active scaling configuration of the scaling group.
-
The scaling activity is complete. The cooldown starts.
-
-
Manually removing ECS instances
-
Checks the health status and boundary conditions of the scaling group, such as the maximum instance count or minimum instance count.
-
Assigns a scaling activity ID and executes the scaling activity.
-
(Optional) The Classic Load Balancer (CLB) instance stops forwarding traffic to the ECS instance. After 60 seconds, the ECS instance is removed from the backend server group of the CLB instance.
-
(Optional) Removes the ECS instance from the ApsaraDB for RDS instance whitelist.
-
Updates the instance count in the scaling group.
-
Removes the ECS instance from the scaling group.
-
The scaling activity is complete. The cooldown starts.
-
Scaling activity statuses
Scaling activities can have the following statuses.
|
Status |
Description |
Example |
|
Rejected |
The request for the scaling activity was rejected. No scale-out or scale-in action was performed. Note
You can click View Rejection Reason next to the Rejected status to see why the activity was rejected. |
Scenario:
Result: The scaling activity fails the condition check and is rejected. No subsequent actions are performed. After the activity ends, the instance count in the scaling group remains 100. |
|
Running |
The scaling activity passed the condition check and is in progress. Auto Scaling adjusts the number of instances to add or remove based on the scaling group's maximum and minimum instance counts. |
Scenario:
Result: The scaling activity passes the condition check and proceeds, but the number of ECS instances to create is adjusted to 5. After the activity ends, the instance count in the scaling group is 100. |
|
Successful |
The scaling activity completed successfully, adding or removing all target ECS instances from the scaling group. |
Scenario:
Result: The scaling activity passes the condition check and is executed. After the activity ends, the instance count in the scaling group is 100. |
|
Warning |
The scaling activity is complete but only partially successful. At least one instance was added or removed, while at least one other failed. For an ECS instance to be successfully added, all the following steps must complete: the instance is created, added to the Classic Load Balancer (CLB) backend server group, and added to the ApsaraDB for RDS instance whitelist. If any step fails, the instance fails to join the scaling group. Note
A rollback is triggered when an ECS instance fails to join a scaling group. For more information, see ECS instance rollback. |
Scenario:
Result: The activity passes the condition check and creates 5 ECS instances. However, because the CLB instance's backend server quota is 200, only one new instance can be added. The other four fail to join the backend server group and are rolled back. After the activity ends, the instance count in the scaling group is 200. |
|
Failed |
The scaling activity is complete, but no target ECS instances are added to or removed from the scaling group. |
Scenario:
Result: The activity passes the condition check, but instance creation fails due to insufficient inventory. After the activity ends, the instance count in the scaling group remains 95. |
ECS instance rollback
If not all ECS instances join a scaling group during a scaling activity, Auto Scaling rolls back only the failed instances, not the entire activity.
When an ECS instance rollback occurs, the scaling group's instance count may fall short of the desired number, which can affect compute capacity or metric targets. To compensate, add instances through other methods, such as manually executing a scaling rule, manually adding existing ECS instances, or configuring a scheduled or event-triggered task.
-
Automatically added ECS instances
When you use OpenAPI to elastically create ECS instances, Auto Scaling relies on Alibaba Cloud Resource Access Management (RAM). You are charged for any rolled-back instances from their creation time until they are automatically released.
For example, if a scaling activity creates five ECS instances that must also join a load balancer's backend server group, and only two succeed, the three failed instances are automatically released. The activity completes with a status of Warning. On the Scaling Activities page, you can view the activity status (Successful, Warning, or Failed), instance counts, and other details. Click the activity to view the failure cause, such as a load balancer backend server quota being exceeded.
-
Manually added ECS instances
If you manually add existing instances and some fail to join the group, Auto Scaling removes them from the scaling group but does not release (terminate) them.