A scaling activity is triggered when a scaling rule is executed or when an Elastic Compute Service (ECS) instance or elastic container instance is manually added to or removed from a scaling group. After a scaling activity is triggered, Auto Scaling performs the scale-out or scale-in operation. This topic describes the process and status of a scaling activity and instance rollback. In this topic, a scaling group that contains ECS instances is used.

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 performs the following operations:
  1. Checks the health status and boundary conditions of the scaling group.
  2. Assigns the activity ID and executes the scaling activity.
  3. Creates ECS instances.
  4. Modifies the number of instances in the scaling group.
  5. Assigns IP addresses to the added ECS instances.
  6. Adds the ECS instances to the whitelist of the ApsaraDB RDS instance.
  7. Starts the ECS instances.
  8. Adds the ECS instances to the backend server group of the Server Load Balancer (SLB) instance, and sets the weights of these ECS instances to the values specified in the active scaling configuration of the scaling group.
  9. Starts the cooldown time after the scaling activity is complete.
When ECS instances are automatically removed from a scaling group after a scaling rule is executed, Auto Scaling performs the following operations:
  1. Checks the health status and boundary conditions of the scaling group.
  2. Assigns the activity ID and executes the scaling activity.
  3. Removes the ECS instances from the backend server group of the SLB instance.
  4. Stops the ECS instances.
  5. Removes the ECS instances from the whitelist of the ApsaraDB RDS instance.
  6. Releases the ECS instances.
  7. Modifies the number of instances in the scaling group.
  8. Starts the cooldown time 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 performs the following operations:
  1. Checks the health status and boundary conditions of the scaling group, and checks the status and types of ECS instances.
  2. Assigns the activity ID and executes the scaling activity.
  3. Adds the ECS instances to the scaling group.
  4. Modifies the number of instances in the scaling group.
  5. Adds the ECS instances to the whitelist of the ApsaraDB RDS instance.
  6. Adds the ECS instances to the backend server group of the SLB instance and sets the weights of these ECS instances to the values specified in the active scaling configuration of the scaling group.
  7. Starts the cooldown time after the scaling activity is complete.
When existing ECS instances are manually removed from a scaling group, Auto Scaling performs the following operations:
  1. Checks the health status and boundary conditions of the scaling group.
  2. Assigns the activity ID and executes the scaling activity.
  3. Stops the SLB instance from forwarding traffic to the ECS instances.
  4. Removes the ECS instances from the backend server group of the SLB instance 60 seconds later.
  5. Removes the ECS instances from the whitelist of the ApsaraDB RDS instance.
  6. Modifies the number of instances in the scaling group.
  7. Removes the ECS instances from the scaling group.
  8. Starts the cooldown time after the scaling activity is complete.

Status

The following table describes the status that a scaling activity may undergo.
Status Description Reference
Rejected The scaling activity is rejected in the request phase and Auto Scaling 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 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 is 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

If a specific number of ECS instances fail to be added to a scaling group, Auto Scaling continues the scaling operation until the scaling activity is complete. ECS instances that fail to be added to the scaling group are rolled back.

  • ECS instances that are automatically added: When you call API operations to create ECS instances as a RAM user, you are charged for the rolled-back ECS instances until the ECS instances are released.
    For example, you want to add five ECS instances to a scaling group and to the backend server group of the SLB instance that is associated with the scaling group. After you create the five instances, only two instances are added to the scaling group. The three instances fail to be added and are automatically released. Auto Scaling considers the scaling activity complete, even if the status of the scaling activity is Warning. Scaling activity
  • ECS instances that are manually added: Auto Scaling automatically removes ECS instances that are rolled back from the scaling group. However, the ECS instances that are rolled back are not released.

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.