How AutoScaling works in Cloud Computing
The task triggers a scaling activity according to the trigger condition.
- The CloudMonitor task monitors the performance of ECS instances in the scaling group in real time and triggers the request for executing a scaling rule based on the configured alarm rules. For example, when the average CPU usage of all ECS instances in the scaling group exceeds 60%.
- The scheduled task triggers the request for executing a scaling rule at the specified time.
- The custom task triggers the request for executing a scaling rule based on the monitoring system and alarm rules. For example, the number of online users or the job queue.
- Health check tasks regularly check the health status of the scaling group and its ECS instances. If an ECS instance is found to be unhealthy (not in running status), the health check task triggers a request to remove the ECS instance from the group.
The system triggers a scaling activity through the ExecuteScalingRule interface and specifies the scaling rule to be executed by its unique Cloud resource identifier (ARI) in this interface.
If a custom task needs to be executed, you must have the ExecuteScalingRule interface called in your program.
The system obtains information about the scaling rule, scaling group, and scaling configuration based on the scaling rule ARI entered in Step 2 and creates a scaling activity.
i. The system uses the scaling rule ARI to query the scaling rule and scaling group, computes the number of ECS instances to be added, and configures the Server Load Balancer and RDS instances.
ii. According to the scaling group, the system queries the scaling configuration to determine the correct parameters (CPU, memory, and bandwidth) to use when creating new ECS instances.
iii. The system creates scaling activity based on the number of ECS instances to be added, the ECS instance configuration, and the Server Load Balancer and RDS instance configurations.
During the scaling activity, the system creates ECS instances and configures Server Load Balancer and RDS instances.
i. The system creates the specified number of ECS instances based on the instance configuration.
ii. The system adds the intranet IP addresses of the created ECS instances to the white list of the specified RDS instance and adds the created ECS instances to the specified Server Load Balancer instance.
After the scaling activity is completed, the system starts the cool-down function for the scaling group. The cool-down time must elapse before the scaling group can execute any new scaling activity.
Considerations
Scaling rules
When you execute and compute a scaling rule, the system can automatically adjust the number of ECS instances according to the MaxSize value and the MinSize value of the scaling group. For example, if the number of ECS instances is set to 50 in the scaling rule, but the MaxSize value of the scaling group is set to 45, the system will compute and execute the scaling rule with 45 ECS instances.
Scaling activity
Only one scaling activity can be executed at a time in a scaling group.
A scaling activity cannot be interrupted. For example, if a scaling activity to add 20 ECS
Instances is being executed, it cannot be forced to terminate when only 5 instances have been created.
When a scaling activity fails to add or remove ECS instances to or from a scaling group, the system maintains the integrity of ECS instances rather than the scaling activity. That is, the system rolls back ECS instances, not the scaling activity. For example, if the system has created 20 ECS instances for the scaling group, but only 19 ECS instances are added to the Server Load Balancer instance, the system only releases the failed ECS instance.
Since Auto Scaling uses Cloud’s Resource Access Management (RAM) service to replace ECS instances through ECS Open API, the rollback ECS instance will still be charged.
Cool-down time
During the cool-down time, only scaling activity requests from CloudMonitor alarm tasks are rejected by the scaling group. Other tasks, such as manually executed scaling rules and scheduled tasks, can immediately trigger scaling activities without waiting for the cool-down time to expire.
The cool-down time starts after the last ECS instance is added to or removed from the scaling group by a scaling activity.
Product restrictions
An application deployed in an ECS instance for Auto Scaling must be stateless and horizontally scalable.
ECS instances for Auto Scaling cannot be used to save application status (for example, session) or related data (for example, databases and logs) because Auto Scaling automatically releases ECS instances. Status information can be saved to an independent state server, database (for example, RDS), or centralized log storage (for example, SLS).
An ECS instance for Auto Scaling is not automatically added to the OCS whitelist. You can manually add it if necessary.
Auto Scaling does not support vertical scaling. It cannot automatically upgrade or downgrade the CPU, memory, or bandwidth for an ECS instance.
Usage Notes Removal policies
There are two types of removal policies: default policy and custom policy.
Default removal policy
This policy first performs level-1 instance screening on the ECS instances created according to the oldest scaling configuration (OldestScalingConfiguration), and then performs level-2 screening on the oldest ECS instances (OldInstances).
This policy first selects the ECS instances created according to the oldest scaling configuration (OldestScalingConfiguration) of the scaling group, and then selects the oldest ECS instance (OldestInstance) from these ECS instances. If more than one oldest ECS instance is found, one of them is selected at random and removed from the scaling group.
Manually added ECS instances are not first selected for removal because they are not associated with any scaling configuration.
If all ECS instances associated with the scaling configuration have been removed, but more instances still need to be removed from the scaling group, this policy selects the instance that was manually added earliest.
Custom release policy
You can set multiple policies to select and remove ECS instances successively from the scaling group.
Release policy types
OldestInstance: This policy selects the ECS instance that was created earliest. As level-1 screening, the policy selects the earliest ECS instance, either created manually or automatically.
NewestInstance: This policy selects the ECS instance that was created most recently. As level- 1 screening, the policy selects the newest ECS instance, either created manually or automatically.
OldestScalingConfiguration: This policy selects the instance created according to the oldest scaling configuration and skips over manually added instances. However, if all ECS instances associated with scaling configurations have been removed, but more instances still need to be removed from the scaling group, this policy randomly selects a manually added ECS instance (an instance not associated with any scaling configuration).
Comments
Post a Comment