Auto Scaling (AS) can automatically adjust CVM computing resources according to configured policies and your business needs, ensuring that you always have the correct number of CVM instances available to handle the load of your applications. Intelligent scale-out and scale-in are important for cost control and resource management. When the traffic increases, you need to add more servers to process the additional load. When the traffic decreases, you need to terminate the unnecessary servers.
With AS, you only need to set up the conditions for scale-out and scale-in in advance. When the scale-out conditions are satisfied, AS will automatically add CVMs to maintain performance. When demand decreases, AS will remove CVMs according to the scale-in conditions.
As shown in the following figures, Auto Scaling can help maintain the appropriate amount of resources, and keep your cluster stay in healthy status. You will get rid of the following troubles in the traditional model:
In common Web application services, your cluster usually runs multiple copies of an application to meet client traffic, for example, the frontend server cluster at the access layer, the application server cluster at the logical layer, and the backend cache server cluster. Every instance can process client requests.
These instances are similar or identical and the quantity is usually adjustable. You can add them to one scaling group for easy management:
Basic concepts related to Auto Scaling:
A scaling group contains a collection of CVM instances that follow the same policies and have a shared purpose. Scaling groups define attributes such as the maximum and minimum numbers of CVM instances in the group and their associated CLB instances.
A launch configuration is the template for the automatic creation of CVMs. It contains the image ID, CVM instance type, system disk/data disk types and capacities, key pair, security group, etc.
When a scaling group is created, it must be specified and cannot be edited once created.
A scaling policy defines the conditions for executing a scaling action. The trigger condition can be a time point or an alarm of cloud monitoring, and the action can be removing or adding a CVM.
There are two types of scaling policies:
Scheduled scaling policy
CVM instances are automatically added or removed at a specified point in time, which can be performed on a periodic basis.
Dynamic scaling policy
CVM instances are automatically added or removed based on cloud monitoring metrics such as CPU, memory, and network traffic.
Cooldown period refers to the locking duration after one scaling activity (addition or removal of CVM instances) is executed in a scaling group. The scaling group does not perform scaling activities during this duration. The cooldown period can be specified as between 0-999999 (seconds).