The name must be 1 to 128 characters in length and can contain Chinese characters, letters, digits, spaces, hyphens (-), underscores (_), periods (.), parenthesis (), colons (:), and plus signs (+) and cannot begin or end with spaces.

• If you create an auto-scaling group for the first time, the number of VM instances in the group is equal to the initial VM count you set.
• The initial VM count must be an integer ranging from 1 to 1000. Make sure that the initial VM count is greater than the minimum VM count and smaller than the maximum VM count. Make your configurations as needed.

• When a scale-in policy is configured, the number of VM instances in the auto-scaling group must not be smaller than that of the specified minimum VM count.
• The minimum VM count must be an integer ranging from 1 to 1000. Make your configurations as needed.

• When a scale-out policy is configured, the number of VM instances in the group must not be greater than that of the specified maximum VM count.
• The maximum VM count must be an integer ranging from 1 to 1000. Make your configurations as needed.

• Load Balancer: Select a load balancer.
  • Before you can select a load balancer, create it first and then associate one or more listeners with it.
• Listener: Select a listener that is associated with the load balancer.
  • The listener list displays all listeners associated with the load balancer.
  • If you select multiple listeners, they listen on their respectively configured ports of VM instances in the auto-scaling group.
• 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 or flat network. Specifically, the VPC network must be attached to a VPC vRouter.
  • If you use the load balancing service, the network you select must be included in the backend network of the load balancer.
• Health Check Method: Select a health check method. We recommend that you choose Load Balancer.
  • VM-based health check: This method checks the health status of VM instances in real time. If a VM instance is detected in stopped, unknown, or deleted state, it is considered to be unhealthy. Then, the VM instance is automatically removed from the auto-scaling group and a new one is created. This ensures the number of healthy VM instances in an auto-scaling group is no less than the specified minimum VM count.
  • Load balancer-based health check: This method use the built-in mechanism of the load balancer.
• Health Check Grace Period: Set the health check grace period after you select the load balancer-based health check method.
  • The health check grace period is a period of time after VM instances in the auto-scaling group are created and booted. During this period, application services related to these VM instances are probably still booting, and the auto-scaling group will not perform load balancer-based health checks. After this period, the health status of the VM instances are monitored based on the health check mechanism of the load balancer.
  • The grace period must be longer than 10 seconds. Enter an integer. Unit: second, minute, and hour.

• Load Balancer: Leave this field blank.
• Network: Select a private L3 network.
  Note: Currently, our auto-scaling service offers auto-scaling capabilities that let you automatically add or delete VM instances in the scenarios such as VPC networks and flat networks.
• Health Check Method:
  • VM-based health check: This method checks the health status of VM instances in real time. If a VM instance is detected in stopped, unknown, or deleted state,it is considered to be unhealthy. Then, the VM instance is automatically removed from the auto-scaling group and a new one is created. This ensures the number of healthy VM instances in an auto-scaling group is not less than the specified minimum VM count.

• VM instances in an auto-scaling group are named in the format of asg-Auto-Scaling Group Name-VM Name-First Five Digits of VM UUID. "asg" is an abbreviation of "autoscaling group".

• If you do not select a disk offering, the size of the root disk offering is consistent with the size of the selected image.

• Data Disk Offering: Select a data disk offering. The data disk offering can be used to directly create data volumes and attach them to the VM instance.
• VM Scheduling Group: Optional. Add the VM instance to a VM scheduling group.
  • A VM instance can be added to only one VM scheduling group. After the addition, the VM instance will be scheduled based on the scheduling policy associated with group.
  • The scheduling policies associated with a VM scheduling group can be classified into the following four types: VM Exclusive from Each Other, VM Affinitive to Each Other, VMs Affinitive to Hosts, and VMs Exclusive from Hosts.
• Security Group: Select a security group. VM instances in the group share the same security group rules.
• Console Password: Enter a password (VNC password) for the VM console. Password length: 6 to 18 characters.
• SSH Public Key: Inject an SSH public key into the VM instance. By doing so, you can SSH in to the VM instance without a password.
  • Before you can inject an SSH public key into the VM instance, install cloud-init for the VM image first. Recommended cloud-init version: 0.7.9, 17.1, 19.4, 19.4, and later.
• User Data: Import User Data. You can upload user-defined parameters or scripts to customize configurations for VM instances or to accomplish specific tasks.
  • Before you can import User Data to Linux-based VM instances, install cloud-init for the VM image first.
    The following is a sample script of importing User Data to a Linux-based 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'
    fqdn: Perf-test
    disable_root: false
    ssh_pwauth: yes
    chpasswd:
      list: |
          root:word
      expire: False
    runcmd:
     - echo ls -l / >/root/list.sh

    The sample script above implements the following functions:

    1. Creates a user with the name test for the VM instance and inject it with an ssh-key.
    2. Writes the /etc/hosts file when the VM instance starts. Meanwhile, creates a /tmp/temp directory, and write in the file under the directory.
    3. Sets a hostname, enable the user root, allow the user to SSH to the VM instance, and change the root password.
    4. Runs the echo ls -l / command.
  • Before you can import User Data to Windows-based VM instances, install Cloudbase-Init for the VM image first. For detailed information about the installation method, see Cloudbase-Init Documentation.
    The following is a sample script of importing User Data to a Windows-based 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 sample script above creates the b64, b64_1, and gzip files in the C drives when the VM instance starts.

  Note: When you use user data, note the following: If an L2 network has multiple L3 networks within the same CIDR, only the user data of the first L3 network takes effect. This will make the internal monitoring of the VM instance fail to work properly.

• Trigger Metric: Select a trigger metric. Available trigger metrics are as follows:
  • VM Memory Utilization Average: The sum of the memory utilization of a single VM instance in the auto-scaling group/The total number of VM instances in the auto-scaling group
  • VM CPU Utilization Average: The sum of the CPU utilization of a single VM instance in the auto-scaling group/The total number of VM instances in the auto-scaling group
  • VM Memory Utilization Average (Agent Required): The sum of the memory utilization of a single VM instance in the auto-scaling group/The total number of VM instances in the auto-scaling group
  • VM CPU Utilization Average (Agent Required): The sum of the CPU utilization of a single VM instance in the auto scaling group/The total number of VM instances in the auto scaling group
  Note:

  • We recommend that you use an agent to monitor the average memory utilization of VM instances. The data monitored through this method is more accurate.
  • If you select trigger metrics that require an agent, make sure that you select an image with an installed agent when you create VM instances.
  • You can install agents by using the User Data script for Linux-based VM instances. For more information, see the User Data part in this topic.
  • If you did not install an agent for internal monitoring but select trigger metrics that require an agent, the auto-scaling group would fail to take effect.

• Scale-out policy:
  • Trigger Rule: Set a trigger condition and the threshold duration.
    • The utilization must be an integer ranging from 1 to 100. Unit: %.
    • The threshold duration must be an integer that is greater than 0. Unit: second, minute, and hour.
  • Addition Policy: Enter the number of VM instances to be added each time when a scale-out action is triggered.
    Note: A minimum number of 1 VM instance can be added each time during the scale-out activity. If the value is too large, the scale-out activity might fail.
  • Cooldown Time: Set the cooldown time.
    • Cooldown time refers to a specified period after a successful scaling activity. During this period, the auto-scaling group is in the locked state and rejects to perform another scaling action.
    • The cooldown time must be an integer that is greater than 0. Unit: second and minute.
• Scale-in policy:
  • When workloads decrease, auto-scaling groups automatically scale in to avoid resource waste.
  • Auto-scaling groups scale in based on the alarm rules that you set for the groups.

    For example, if the average memory utilization of all VM instances in an auto-scaling group keeps lower than 20% for a period of time, a reasonable number of VM instances are removed. This way, the workloads are well balanced at a reasonable level among the VM instances.

  To configure the scale-in policy, set the following parameters:

  • Trigger Rule: Set a trigger condition and the threshold duration. You can set to trigger the policy when the utilization greater than, less than, or equal to a specified value.
    • The utilization must be an integer ranging from 1 to 100. Unit: %. Note that the trigger rule set for the scale-out policy cannot conflict with that for the scale-in policy.
    • The threshold duration must be an integer that is greater than 0. Unit: second, minute, and hour.
  • Removal Policy: Select a removal policy and enter the number of VM instances to be removed each time when a scale-in action is triggered. Available removal policies are as follows:
    • Most Recent Created VM Instance (default): When the auto-scaling group starts scale-in activities, the latest created VM instances are removed successively at first.
    • Earliest Created VM Instance: When the auto-scaling group starts scale-in activities, the earliest created VM instances are removed successively at first.
    • VM with Minimum CPU Usage: When the auto-scaling group starts scale-in activities, VM instances with the minimum CPU usage are removed successively at first.
    • VM with Minimum Memory Usage: When the auto-scaling group starts scale-in activities, VM instances with the minimum memory usage are removed successively at first.
    Note: A minimum number of 1 VM instance can be removed each time during the scale-in activity. If the value is too large, the scale-in activity might fail.
  • Cooldown Time: Set the cooldown time.
    • Cooldown time refers to a specified period after a successful scaling activity. During this period, the auto-scaling group is in the locked state and rejects to perform another scaling action.
    • The cooldown time must be an integer that is greater than 0. Unit: second and minute.
• Alarm Notification: Choose whether to enable alarm notification. You can configure a monitoring and alarm mechanism to trigger auto-scaling. By default, alarm notification is not enabled.
  • If enabled, you must specify one or more endpoints.
    Endpoint: Specify one or more endpoints.

    • You can either select the system endpoint (default) or select a custom endpoint such as email, DingTalk, HTTP application, short message service, and Microsoft Teams.

• Scale-out policy:
  • Scale-out Period: Select a scale-out period. Options: scale-out by month, scale-out by week, scale-out by day, scale-out by hour, and scale-out by minute.
  • Execution Time: If you set the scale-out period as scale-out by month, scale-out by week, or scale-out by day, select an execution time for the scale-out activities.
  • Addition Policy: Enter the number of VM instances to be added each time when the auto-scaling group performs a scale-out activity.
    Note: A minimum number of 1 VM instance can be added each time during the scale-out activity. If the value is too large, the scale-out activity might fail.
  • Cooldown Time: Set the cooldown time.
    • Cooldown time refers to a specified period after a successful scaling activity. During this period, the auto-scaling group is in the locked state and rejects to perform another scaling action.
    • The cooldown time must be an integer that is greater than 0. Unit: second and minute.
  • Schedule Effective Time: Specify the time when the scale-out activities starts. The auto-scaling group executes scale-out actions according to the scale-in period since this time point.
    Note: You can set the effective time if you choose to scale-out by month, scale-out by week, or scale-out by day.
• Scale-in policy:
  • Scale-in Period: Select a scale-in period. Options: scale-in by month, scale-in by week, scale-in by day, scale-in by hour, and scale-in by minute.
  • Execution Time: If you set the scale-in period as scale-in by month, scale-in by week, or scale-in by day, select an execution time for the scale-in activities.
  • Removal Policy: Select a removal policy and enter the number of VM instances to be removed each time when the auto-scaling group performs a scale-in activity. Available removal policies are as follows:
    • Most Recent Created VM Instance (default): When the auto-scaling group starts performing scale-in activities, the latest created VM instances are removed successively at first.
    • Earliest Created VM Instance: When the auto-scaling group starts performing scale-in activities, the earliest created VM instances are removed successively at first.
    • VM with Minimum CPU Usage: When the auto-scaling group starts performing scale-in activities, VM instances with the minimum CPU usage are removed successively at first.
    • VM with Minimum Memory Usage: When the auto-scaling group starts performing scale-in activities, VM instances with the minimum memory usage are removed successively at first.
    Note: A minimum number of 1 VM instance can be removed each time during the scale-in activity. If the value is too large, the scale-in activity might fail.
  • Cooldown Time: Set the cooldown time.
    • Cooldown time refers to a specified period after a successful scaling activity. During this period, the auto-scaling group is in the locked state and rejects to perform another scaling action.
    • The cooldown time must be an integer that is greater than 0. Unit: second and minute.
  • Schedule Effective Time: Specify the time when the scale-in activities starts. The auto-scaling group executes scale-in actions according to the scale-in period since this time point.
    Note: You can set the effective time when you choose to scale-in by month, scale-in by week, or scale-in by day.