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.

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.

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.

  

• 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.

• 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%.

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.