Auto Scaling:Centrally monitor and scale ECS and non-Alibaba Cloud instances

Prerequisites

• An Alibaba Cloud account. If you do not have one, create an Alibaba Cloud account.

• A non-Alibaba Cloud server with public internet access.

Scenarios

Use this solution if you run stateless applications on non-Alibaba Cloud servers and struggle with manual scaling due to significant traffic fluctuations.

After you register non-Alibaba Cloud servers as managed instances and add them to a scaling group, Auto Scaling monitors all instances and automatically scales ECS instances based on metric changes:

• During traffic peaks, automatically scale out ECS instances to handle the increased load.

• During traffic lulls, automatically scale in ECS instances to save costs.

Concepts

Key concepts:

Procedure

Step 1: Register non-Alibaba Cloud instances

Prepare the non-Alibaba Cloud servers to register. This example uses three servers. managed instances.

1. Create an activation code.

   On the ECS console, create an activation code for the managed instances, generate an installation script, and save it. Step 1: Create an activation code. Sample installation script for Linux (.deb) system:

   # Download the Cloud Assistant agent .deb package.
   sudo wget https://aliyun-client-assist.oss-accelerate.aliyuncs.com/linux/aliyun_assist_latest.deb
   # Install the latest version of the Cloud Assistant agent.
   sudo dpkg -i aliyun_assist_latest.deb
   # Register the managed instance.
   sudo aliyun-service --register --RegionId "cn-hangzhou" \
      --ActivationCode "a-hz011wm7BNH3JnTMyx22****VJ6d" \
      --ActivationId "A4C23294-D8E9-5591-87A2-CCA2****2AC9"

2. Install the Cloud Assistant agent and register the managed instances.

   Run the installation script on each non-Alibaba Cloud server to install the Cloud Assistant agent and register it as a managed instance.

   1. Log on to a non-Alibaba Cloud server.

   2. Paste and run the installation script. This installs the Cloud Assistant agent and registers the server as a managed instance. The system automatically assigns an instance ID.

      Run the following commands to download and install the Cloud Assistant agent, then use the activation code to register the managed instance. Upon successful registration, the managed instance ID is returned (for example, mi-hzxxx...xxx134).

      $ sudo wget https://aliyun-client-assist.oss-accelerate.aliyuncs.com/linux/aliyun_assist_latest.deb
      --2023-07-24 15:33:07--  https://aliyun-client-assist.oss-accelerate.aliyuncs.com/linux/aliyun_assist_latest.deb
      Resolving aliyun-client-assist.oss-accelerate.aliyuncs.com (aliyun-client-assist.oss-accelerate.aliyuncs.com)... 1xxx.xxx.xxx.xxx6
      Connecting to aliyun-client-assist.oss-accelerate.aliyuncs.com (aliyun-client-assist.oss-accelerate.aliyuncs.com)|1xxx.xxx.xxx.xxx6|:443... connected.
      HTTP request sent, awaiting response... 200 OK
      Length: 36237058 (35M) [application/octet-stream]
      Saving to: 'aliyun_assist_latest.deb'
      
      aliyun_assist_latest.deb          100%[============================================================>]
      
      2023-07-24 15:33:09 (16.2 MB/s) – 'aliyun_assist_latest.deb' saved [36237058/36237058]
      
      $ sudo dpkg -i aliyun_assist_latest.deb
      Selecting previously unselected package aliyun-assist.
      (Reading database ... 72699 files and directories currently installed.)
      Preparing to unpack aliyun_assist_latest.deb ...
      Unpacking aliyun-assist (2.2.3.421) ...
      Setting up aliyun-assist (2.2.3.421) ...
      install linux aliyun-assist at /usr/local/share/aliyun-assist/2.2.3.421 ...
      install assist ok
      start assist ok
      need to install assist_daemon
      create ok
      start ok
      
      $ sudo aliyun-service --register --RegionId "cn-hangzhou" \
      >    --ActivationCode "a-hzxxx...xxxVi" \
      >    --ActivationId "3DC2F9xxx...xxxA667"
      register ok
      instance id: mi-hzxxx...xxx134
      restart service

3. View the managed instances.

   After registration, go to the ECS Cloud Assistant page on the ECS console. On the Manage Instances tab, record the instance IDs. In this example, the three instances are named Test-01, Test-02, and Test-03.

   Note

   The IDs of managed instances start with mi-, and the IDs of ECS instances start with i-.

Step 2: Install the CloudMonitor agent

1. Log on to a managed instance.

2. Run the following command to install the CloudMonitor agent:

   ARGUS_VERSION=3.5.9.11 /bin/bash -c "$(curl -s https://cloudmonitor-agent.oss-cn-hangzhou.aliyuncs.com/Argus/agent_install_necs-1.8.sh)"

3. Run the following command to check the status of the CloudMonitor agent:

   ps aux | grep argusagent | grep -v grep

   The following output confirms successful installation.

   root      12590  0.0  0.1  33440  6924 ?        Ss   15:55   0:00 /usr/local/cloudmonitor/bin/argusagent -d
   root      12592  0.0  0.4 850972 16096 ?        Sl   15:44   0:00 /usr/local/cloudmonitor/bin/argusagent

   Note

   You can also verify the installation on the Host Monitoring page of the CloudMonitor console, which displays CPU utilization, memory usage, and disk usage for the managed instance.

Step 3: Add managed instances to a scaling group

Important

Before you begin:

• Select appropriate monitoring metrics for your scaling group and create event-triggered tasks. Overview of event-triggered tasks.

• If a scaling group contains both ECS and managed instances, event-triggered tasks use aggregated metrics from all instances. Because managed instances support only agent-based metrics, use agent-based metrics for your event-triggered tasks.

• Managed instances can only be manually added to or removed from a scaling group. They are not released upon removal.

Procedure

1. Create a scaling group.

   Only ECS-type scaling groups support managed instances. Create an ECS-type scaling group (for example, Scalinggroup_ecs). Create a scaling group.

2. Create and enable a scaling configuration.

   Create a scaling configuration for ECS instances.

3. Enable the scaling group.

   Enable or disable a scaling group.

4. Create scaling rules.

   Create two simple scaling rules. Create a scaling rule.

   • Scale-out rule (Add1): a scaling rule to add one ECS instance.

   • Scale-in rule (Reduce1): a scaling rule to remove one ECS instance.

5. Create event-triggered tasks.

   Create two event-triggered tasks using the (Agent) CPU Utilization metric to keep average CPU utilization between 40% and 60%. Configure an event-triggered task.

   • Scale-out task (ScaleOutAlarm): For the (Agent) CPU Utilization metric, set the condition to Average >= 60% and associate the task with the scale-out rule (Add1). This adds one ECS instance when the group's average CPU utilization is 60% or higher.

   • Scale-in task (ScaleInAlarm): For the (Agent) CPU Utilization metric, set the condition to Average <= 40% and associate the task with the scale-in rule (Reduce1). This removes one ECS instance when the group's average CPU utilization is 40% or lower.

6. Manually add the three managed instances to the scaling group.

   Important

   Managed instances in a scaling group can only be manually added or removed.

   1. On the details page of the scaling group, click the Instance Management tab.

   2. On the Managed Instance tab, click Add Instance.

   3. In the Add Instance dialog box that appears, select the instances that you want to add, and then click the icon.

   4. Click Are you sure that you want to add.

      You can view the added instances on the Managed Instance tab. If the status shows In Service, the instances are successfully managed.

Verification

Scenario 1: Group with three idle managed instances

When managed instances have no load, average CPU utilization falls below 40%, triggering ScaleInAlarm. However, Auto Scaling cannot automatically remove managed instances:

• During the 22:01–22:07 period, average CPU utilization is below 40%. ScaleInAlarm triggers but fails to execute.

  The event-triggered task details page shows that ScaleInAlarm is in Alarm state. The associated scale-in rule is Reduce1. The monitoring chart shows that CPU Utilization Average is approximately 0.7% at 22:07.

• During the 22:01–22:07 period, the system rejects the scale-in activity and instance count remains unchanged. Click View Rejection Reason for details.

Scenario 2: Group with three high-load managed instances

If you use a stress testing tool (such as lookbusy) to maintain CPU utilization at approximately 90% on the managed instances, average CPU utilization exceeds 60%:

• During the 22:14–22:25 period, average CPU utilization exceeds 60%. ScaleOutAlarm triggers and executes successfully.

  The event-triggered task ScaleOutAlarm details page shows Normal status. The CPU utilization line chart in the monitoring area shows that average CPU utilization surged to approximately 90% after the stress test started, then gradually decreased as scale-out activities were executed.

• During the 22:14–22:25 period, a scale-out activity adds two ECS instances (total: five). Scaling stops after 22:25 when average CPU utilization stabilizes between 40% and 60%.

  On the Scaling Activities tab, you can view the execution status and results of each scaling activity. Successful scale-out activities increased Total Instances After Change from 3 to 5. Some activities were Rejected due to invalid rules (click View Rejection Reason for details).

Scenario 3: Stop stress testing on managed instances

After Scenario 2, the scaling group contains two ECS instances and three managed instances with average CPU utilization between 40% and 60%. Stopping the stress test causes CPU utilization to drop below 40%, triggering ScaleInAlarm. However, managed instances can only be removed manually:

• During the 22:48–22:54 period, a scale-in activity removes both ECS instances (count: five to three). After 22:55, CPU utilization remains below 40% but subsequent scale-in activities fail because only managed instances remain.

• After 22:55, average CPU utilization remains below 40%. ScaleInAlarm triggers but fails because the group contains only managed instances, which must be removed manually.

  The event-triggered task details page shows that ScaleInAlarm is currently in alarm state. The trigger condition is (Agent) CPU Utilization Average ≤ 40% for 5 consecutive periods. The associated scale-in rule is Reduce1. The monitoring chart at the bottom shows that CPU utilization dropped to near 0% after 22:51, continuously meeting the trigger condition.