ZStack 3.10.0>Tutorials>Private Cloud>Auto-Scaling Tutorial>Auto Scaling Group

Auto Scaling Group

An auto scaling group contains a logical collection of VM instances that share the same usage scenarios for the purposes of automatic scaling and management. With an auto scaling group, auto scaling or elastic self-health services can be automatically achieved based on business changes.

An auto scaling group supports the following operations:

Create the auto scaling group.
Check the details of the auto scaling group.
Enable the auto scaling group.
Disable the auto scaling group.
Delete the auto scaling group.

Create Auto Scaling Group

In the navigation pane of the ZStack Private Cloud UI, choose Resource Pool > Auto Scaling Group. On the Auto Scaling Group page, click Create Auto Scaling Group. On the displayed Create Auto Scaling Group page, create an auto scaling group.

To create an auto scaling group, follow these steps:

Set the bas information. To set the basic information, set the following parameters:
- Group Name: Enter a name for the auto scaling group.
- Description: Optional. Enter a description for the auto scaling group.
- Minimum Group Size: Set the minimum number of VM instances in the auto scaling group.
  - When an elastic scale-in policy is triggered, the number of the VM instances in the auto scaling group must not be smaller than that of the specified minimum number of the VM instances.
  - Enter an integer. Value range: 1-1000, inclusive. Make your configurations as needed.
- Maximum Group Size: Set the maximum number of VM instances in the auto scaling group.
  - When an elastic scale-out policy is triggered, the number of the VM instances in the auto scaling group must not be greater than that of the specified maximum number of the VM instances.
  - Enter an integer. Value range: 1-1000, inclusive. Make your configurations as needed.
- Desired Group Size: Set the number of VM instances that the auto scaling group attempts to maintain.
  - If you create an auto scaling group for the first time, the number of VM instances in the auto scaling group is equal to the desired capacity of VM instances.
  - Enter an integer. Value range: 1-1000, inclusive. The desired capacity of VM instances must be set between the minimum number of the VM instances and the maximum number of VM instances. Make your configurations as needed.
- If you choose to configure the load balancing service, we recommend that you set the following parameters:
  - Load Balancer: Select a load balancer.
    - Ensure that you create a load balancer in advance, and bind one or more listeners to it.
    - For more information about how to use the load balancing service, see Load Balancing in the User Guide.
  - Listener: Select a listener after you choose the load balancer.
    - The listener list displays all listeners bound by the load balancer.
    - If you select multiple listeners, the same collection of the VM instances within the corresponding listeners will be listened separately via different ports.
  - L3 Network: Select an L3 network used for creating VM instances.
    - If you do not use the load balancing service, you can select a VPC network, vRouter network, or flat network. Specifically, the VPC network must be attached to a VPC vRouter.
    - If you use the load balancing service, you can select networks available to the service.
      - If the load balancer that you selected provides the load balancing service by using the VIP created from a public network, the following three scenarios are supported:
        
        Scenario 1: Assume that the L3 network is a VPC network attached to the same VPC vRouter. In that case, make sure that the L3 network that is created from the VPC vRouter offering and the public network where the VIP resides are the same.
        
        Scenario 2: Assume that the L3 network is a vRouter network. In that case, make sure that this vRouter network that attaches a vRouter offering and the public network where the VIP resides are the same.
        
        Scenario 3: Assume that the L3 network is a flat network. In that case, make sure that the flat network that attaches a vRouter offering and the public network where the VIP resides are the same.
      - If the load balancer that you selected provides the load balancing service by using the VIP created from a VPC network, you can select the VPC network attached by the same VPC vRouter. In that case, the VPC network that you selected and the VPC network that provides the VIP must be attached to the same VPC vRouter.
      - If the load balancer that you selected provides the load balancing service by using the VIP created from a flat network, the following two scenarios are supported:
        
        Scenario 1: The L3 network is a flat network that creates a VIP. In that case, the flat network with a vRouter offering is supported.
        
        Scenario 2: The L3 network is other types of flat network. In that case, make sure that the flat network that attaches a vRouter offering and the flat network where the VIP resides are the same.
    Note:
    - If the selected listener has bound a VM NIC, this L3 network and the network attached by the listener must belong to the same router.
  - Health Check: We recommend that you select health check for the load balancer.
    - Load balancer health check is the health check mechanism native to the load balancer.
    - For more information about the details of the health check mechanism on the load balancer, see Load Balancing in the User Guide.
  - Health Check Grace Period: Set the health check grace period after you select the load balancer health check.
    - Health check grace period is a period of time after the VM instances in the auto scaling group are created and booted. During this period of time, application services related to the VM instances are probably still booting, and the auto scaling group will not perform health checks for the load balancer. If this period of time is exceeded, the health status of the VM instances are listened based on the health check mechanism of the load balancer.
    - Enter an integer that is greater than 10. Unit: second | minute | hour. Make your configurations as needed, as shown in the (Recommended) Auto Scaling Group Configures Load Balancing.
  Figure 1. (Recommended) Auto Scaling Group Configures Load Balancing
- If you do not configure the load balancing feature, we recommend that you set the following parameters:
  - Load Balancer: Leave this field blank.
  - Listener: Leave this field blank.
  - L3 Network: Select a private L3 network.
    Note: Currently, our auto scaling service offers autoscaling capabilities that let you automatically add or delete VM instances in the scenarios such as vRouter network and VPC network.
  - Health Check: Default to display the health check of the VM instances.
    - VM health check enables you to check the health status of the VM instances in real time. If VM instances are detected as unhealthy (including stopped, unknown, and deleted), the unhealthy VM instances will be automatically removed, and new VM instances will be created. Hence, the number of the healthy VM instances in the auto scaling group are ensured to be not lower than that of the specified minimum number of the VM instances.
  The following figure shows the scenario where load balancing is not configured for the auto scaling group, as shown in Auto Scaling Group Do not Configure Load Balancing.
  Figure 2. No Load Balancing Configured for Auto Scaling Group
- Enable alarm notification: Select whether to enable the alarm notifications. If selected, the ZWatch monitoring alarm mechanism can be configured to trigger the auto scaling service for the auto scaling group.
  - By default, this checkbox is not selected. Associated alarm messages can be viewed at the Notification Center.
  - If selected, you must specify one or more endpoints.
    Endpoint: Specify one or more endpoints.
    - You can either select the default system endpoint or choose custom endpoints such as email, DingTalk, HTTP application, short message service, and Microsoft Teams.
    - For more information about how to create endpoints, see Endpoint in the User Guide.
- Apply immediately after creation: Select whether to enable the auto scaling group immediately after you create the auto scaling group. By default, this checkbox is not selected.
Step 1 is about how to set the basic information, as shown in Step 1 Set Basic Information.
Figure 3. Step 1 Set Basic Information
Configure the auto-scaling VM instance. Auto-scaling configurations define the template configuration information of VM instances in the auto scaling group. To configure the information, set the following parameters:
- VM Name: Enter a name for the VM instance.
  - The unified naming convention for the VM instances in an auto scaling group is asg-Auto Scaling Group name-VM name-the first 5-digit VM UUID. Specifically, asg stands for auto scaling group.
- VM Description: Optional. Enter a description for the VM instance.
- Instance Offering : Select an instance offering for the VM instance.
- Image: Select an image for the VM instance.
  Note:
  - Under this scenario, you can add two types of VM image: qcow2 and raw.
  - If you want to use the internal monitoring metrics, select either an image that has installed an agent, or install the agent manually by using the User Data script.
  - If you change the image after you create the VM instance, the new image will only be effective for the subsequently created VM instances, and the original image remains unchanged for the previously created VM instances.
- L3 Network: Default to display the private L3 network that you have set in the previous step.
- Advanced: Make advanced settings for the VM instance as needed.
  - Data Disk Offering: Select a data disk offering. The data disk offering can be created directly and then attached to the VM instance.
  - Security Group: Select a security group. VM instances in the auto scaling group will share the same security group rules.
  - Console Password: Enter the password (VNC password) for the VM console. Password length: 6-18.
  - SSH Public Key: Inject an SSH public key into the VM instance. By doing so, you can log in to the VM instance without passwords via SSH.
    - To inject an SSH public key into the VM instance, install cloud-init for the image in advance.
    - For more information about the details of the SSH public key, see SSH Key Management in the User Guide.
  - User Data: Import User Data to the VM instance. By uploading custom parameters or a script, customize configurations or complete specific tasks for the VM instance.
    - To import User Data to a Linux VM instance, this Linux VM instance must install cloud-init in advance.
      The following is a sample script of importing User Data to a Linux VM instance:
      #cloud-config users: - name: test shell: /bin/bash groups: users sudo: ['ALL=(ALL) NOPASSWD:ALL'] ssh-authorized-keys: - ssh-rsa AAAAB3NzaC1LXCJfjroD1lT root@10-0-0-18 bootcmd: - mkdir /tmp/temp write_files: - path: /tmp/ZStack_config content: | Hello,world! permissions: '0755' hostname: Perf-test disable_root: false ssh_pwauth: yes chpasswd: list: | root:word expire: False runcmd: - echo ls -l / >/root/list.sh
      The preceding sample script can achieve the following functionalities:
      
      When you create a VM instance, create a user with the name test by using ssh-key.
      
      Start the VM instance, and write the /etc/hosts file. Also, create the /tmp/temp directory, and create a file under the directory and write contents into the file.
      
      Set hostname, enable the user root, log in to the VM instance by using the SSH password, and change the password for the root.
      
      Run the echo ls -l / command.
    - To import User Data to a Windows VM instance, this Windows VM instance must install Cloudbase-Init in advance. For more information about the detailed installation method, see Cloudbase-Init Documentation.
      The following is a sample script of importing User Data to a Windows VM instance:
      #cloud-config write_files: - encoding: b64 content: NDI= path: C:\b64 permissions: '0644' - encoding: base64 content: NDI= path: C:\b64_1 permissions: '0644' - encoding: gzip content: !!binary | H4sIAGUfoFQC/zMxAgCIsCQyAgAAAA== path: C:\gzip permissions: '0644'
      The preceding sample script can achieve the following functionalities: When the VM instance boots, three files: b64, b64_1, and gzip are created in the C drive.
    Note: When you use User Data, note that you can configure only one L3 network for an L2 network.
Step 2 is about how to configure the autoscaling VM instance, as shown in Step 2 Configure Autoscaling VM Instance.
Figure 4. Step 2 Configure Autoscaling VM Instance

Note:
Exercise caution. If you delete resources (such as instance offering, image, and network) in the template configurations, you will fail to create the auto scaling group.
Configure the scaling policy. A scaling policy includes scale-out and scale-in.
- Scale-out policy:
  - When businesses are growing, the auto scaling group automatically adds additional VM instances to avoid access latency and excessive resource load.
  - An elastic scale-out policy can be triggered by the ZWatch monitoring mechanism that you set.
    For example, when the average memory utilization of all VM instances in the auto scaling group is detected to continuously exceed 80% within a period of time, an appropriate number of VM instances will be automatically created. Hence, the auto scaling group will regain the reasonable load balancing.
  To configure the scale-out policy, set the following parameters:
  - Trigger Metric: Select a trigger metric, including average VM CPU utilization and average VM memory utilization.
    - Average VM CPU utilization: the sum of the utilization for a single VM CPU in an auto scaling group/the total number of VM instances in the auto scaling group
    - Average VM memory utilization: the sum of the memory utilization for a single VM instance in an auto scaling group/the total number of VM instances in the auto scaling group
    - Average VM CPU utilization (install agent): the sum of the utilization for a single VM CPU in an auto scaling group/the total number of VM instances in the auto scaling group
    - Average VM memory utilization (install agent): the sum of the memory utilization for a single VM instance in an auto scaling group/the total number of VM instances in the auto scaling group
    Note:
    
    We recommend that you use an agent, internal monitoring tool, to monitor the average memory utilization of VM instances. By doing this, the monitoring data is more accurate.
    
    If you must select trigger metrics that require you to install an agent, make sure that you select an image with an installed agent when you create VM instances.
    
    Linux VM instances enable you to install agents by using the User Data script. For more information, see the User Data part in this topic.
    
    If you did not install an agent for internal monitoring and still wanted to select trigger metrics that require you to install the agent, the auto scaling group would fail to take effect.
  - Trigger Condition: Set a trigger condition. Options: > | ≥.
    - Enter an integer between 1-100, inclusive. Unit: %. Make your configurations as needed.
  - Duration: Set the duration.
    - Enter an integer that is greater than 0. Unit: second | minute | hour. Make your configurations as needed.
  - Cooldown Time: Set the cooldown time.
    - Cooldown time refers to a period of time during which an auto scaling group that is in the locked status rejects any new scaling activity after one scaling activity is launched successfully in the auto scaling group.
    - Enter an integer that is greater than 0. Unit: second | minute. Make your configurations as needed.
  - VMs To Be Added Per Time: Add more VM instances when the auto scaling group performs a scale-out activity.
    Note: Each time the minimum allowed scale-out number of VM instances is 1. If the value is too large in this field, the scale-out activity will fail.
  The scale-out policy can be configured, as shown in Configure Scale-out Policy.
  Figure 5. Configure Scale-out Policy
- Scale-in policy:
  - When businesses are declining, the auto scaling group automatically deletes VM instances to avoid a waste of resources.
  - An elastic scale-in policy can be triggered by the ZWatch monitoring mechanism that you set.
    For example, when the average memory utilization of all VM instances in the auto scaling group is detected to continuously drop below 20% within a period of time, an appropriate number of VM instances will be automatically removed. Hence, the auto scaling group will regain the reasonable load balancing.
  To configure the scale-in policy, set the following parameters:
  - Trigger Metric: When you set the scale-in policy, the trigger metric is unselected in which this trigger metric is consistent with that of the scale-out policy.
  - Trigger Condition: Set a trigger condition. Options: < | ≤.
    - Enter an integer between 1-100, inclusive. Unit: %. This trigger condition cannot be in conflict with that of the scale-out policy. Make your configurations as needed.
  - Duration: Set the duration.
    - Enter an integer that is greater than 0. Unit: second | minute | hour. Make your configurations as needed.
  - Cooldown Time: Set the cooldown time.
    - Cooldown time refers to a period of time during which an auto scaling group that is in the locked status rejects any new scaling activity after one scaling activity is launched successfully in the auto scaling group.
    - Enter an integer that is greater than 0. Unit: second | minute. Make your configurations as needed.
  - Removal Policy: Select a removal policy, including:
    - Most recent created VM instance (default): When the auto scaling group starts performing scale-in activities, the latest created VM instances will be removed successively at first.
    - Earliest created VM instance: When the auto scaling group starts performing scale-in activities, the earlier created VM instances will be removed successively at first.
    - VM instance with the minimum CPU utilization: When the auto scaling group starts performing scale-in activities, the VM instances with the minimum CPU utilization will be removed successively at first.
    - VM instance with the minimum memory utilization: When the auto scaling group starts performing scale-in activities, the VM instance with the minimum memory utilization will be removed successively at first.
  - VMs To Be Removed Per Time: Remove VM instances when the auto scaling group performs a scale-in activity.
    Note: Each time the minimum allowed scale-in number of VM instances is 1. If the value is too large in this field, the scale-in activity will fail.
  The scale-in policy can be configured, as shown in Configure Scale-in Policy.
  Figure 6. Configure Scale-in Policy
Step 3 is about how to configure the auto scaling policies, as shown in Step 3 Configure Auto Scaling Policy.
Figure 7. Step 3 Configure Auto Scaling Policy

Check Auto Scaling Group Details

On the Auto Scaling Group page, select an auto scaling group, expand its details page, and then check the state and information of the currently created auto scaling group, including basic attributes, VM instance, scaling record, and audit.

Basic information:
- Display the current state, name, description, basic information (such as the minimum number of VM instances, the maximum number of VM instances, the number of the current VM instances, the desired number of the VM instances, health check mechanism, load balancing, and endpoints that push alarm notifications), scaling configurations (the template configuration information of VM instances in the auto scaling group), and scaling policy (such as scale-out and scale-in policies).
- Specifically, you can change the name, description, scale-out policy, and scale-in policy for the auto scaling group.
VM instance:
- Display a list of the currently healthy VM instances in the auto scaling group.
- The auto scaling group monitors the health state of VM instances based on the health check mechanism. We recommend that you use load balancer health check. If the unhealthy VM instances are detected, these unhealthy VM instances will be automatically deleted, and new VM instances will be created. Hence, the number of the healthy VM instances in the auto scaling group are ensured to be not lower than that of the specified minimum number of the VM instances.
- Display the monitoring status of the auto scaling group. The monitoring status has the following two types:
  - Collect normal: The auto scaling group normally collect the monitoring data of VM instances.
  - Insufficient data: The auto scaling group cannot normally collect the monitoring data of VM instances. The reasons may be as follows:
    1. For newly-created VM instances, collecting the monitoring data takes a while.
    2. For VM instances without an agent installed, the monitoring data cannot be collected. To collect the internal monitoring data of VM instances, install GuestTools by going to the details page of the VM instances.
    3. For abnormal VM instances, check the state of the VM instances.
Scaling record: Display the scaling record of the scaling activities performed by the auto scaling group. You can search the scaling record by adjusting an appropriate time range.
Audit: Check related operations of the auto scaling group.

Enable/Disable Auto Scaling Group

Enable auto scaling group: Enable the auto scaling group that is stopped.
Disable auto scaling group: Disable the auto scaling group.
Note:
- Assume that the auto scaling group has triggered the scaling activity. If you disable the auto scaling group, the ongoing scaling activity will not be affected. After the scaling activity is completed, a new scaling activity will be rejected.
- Assume that the auto scaling group is being inspected. If you disable the auto scaling group, ZWatch or the health check mechanism will stop inspecting the auto scaling group immediately, and will reject a new scaling activity.

Delete Auto Scaling Group

Exercise Caution. Deleting an auto scaling group will delete all VM instance in the auto scaling group as well.

More Information

Business applications running on the VM instances of an auto scaling group must be stateless and can be extensible horizontally.
The auto scaling service will automatically release VM instances. We recommend that you do not manually attach volumes, NICs, or security groups to the VM instances in the auto scaling group. If the VM instances in the auto scaling group contain stateful information, associated data will be lost.
The auto scaling group cannot be extended vertically. That is, instance offerings, network bandwidth, and other resources cannot be automatically scaled in or out.
If you want to change an external monitoring metric to an internal monitoring metric, delete the corresponding auto scaling group and create a new one.
The auto scaling service can be set in the global settings as follows:
- When the auto scaling group uses the health check mechanism of a load balancer, you can configure the health check interval of the VM instances in the load balancer.
  Method: Go to Settings > Global Settings > Advanced, locate Health checking interval of loadBalancing VM instance, and set a value as needed. Default value: 10. Unit: Second. Minimum value: 10 seconds. Maximum value: 1000 seconds.
- When the auto scaling group uses the health check mechanism of a load balancer, you can configure the thread count of the VM health check in the load balancer.
  Method: Go to Settings > Global Settings > Advanced, locate Health checking threads of loadBalancing VM instance, and set a value as needed. Default value: 10. Minimum thread count: 10. Maximum thread count: 1000.
- When the auto scaling group uses the health check mechanism of a VM instance, you can make configurations to delete the health check interval of unhealthy VM instances in the auto scaling group.
  Method: Go to Settings > Global Settings > Advanced, locate Interval for remove unhealthy instance in group, and set a value as needed. Default value: 30. Unit: Second. Minimum value: 10 seconds. Maximum value: 1000 seconds.
- When the auto scaling group uses the health check mechanism of a VM instance, you can make configurations to delete the thread count of unhealthy VM instances in the auto scaling group.
  Method: Go to Settings > Global Settings > Advanced, locate Threads limitation for Unhealthy thread instance, and set a value as needed. Default value: 10. Minimum thread count: 10. Maximum thread count: 1000.
- The health check interval of the VM count in the auto scaling group can be set.
  Method: Go to Settings > Global Settings > Advanced, locate Checking interval for instance count in group, and set a value as needed. Default value: 20. Unit: Second. Minimum value: 10 seconds. Maximum value: 1000 seconds.

Notice

If an auto scaling group repeatedly performs the scaling policies, such as continuously creating and removing VM instances, the reasons may be as follows:
- The newly-created VM instances cannot enter health status within the tolerance time. Then, the Cloud triggers the elastic self-health policy which deletes the unhealthy VM instances and add additional VM instances. Hence, an elastic self-health loop is formed. In that case, you need to check the health status or modify the health check mechanism of the VM instances.
- The scale-in or scale-out thresholds are set inappropriately. For example, set a trigger condition where a scale-out activity is launched as the CPU of VM instances is below 40%. If an auto scaling group has only one VM instance, the average CPU load of the VM instance in the auto scaling group is 60%. Then, two VM instances are added after the scale-out activity is triggered, and the average CPU workload of the VM instances in the auto scaling group reduces to 60%. Hence, a loop is formed. At this time, you need to set an appropriate threshold for the scaling policies.
If an auto scaling does not perform the scaling policies but continuously triggers alarms, the reason may be as follows:
- The maximum number of the VM instances and the scale-out trigger condition are set inappropriately. When the number of the VM instance in the auto scaling group has reached the specified maximum limit, and the average workload of the VM instances are still higher than the scale-out threshold, alarms will continuously be triggered. In that case, you need to configure the appropriate thresholds for the maximum number of VM instances and the scale-out trigger condition.

Next Chapter:Typical Scenario Practice

Auto Scaling Group

Create Auto Scaling Group

Check Auto Scaling Group Details

Enable/Disable Auto Scaling Group

Delete Auto Scaling Group

More Information

Notice

Products

Solutions

Help & Support

Contact Us