# Auto scaling

> Add and remove servers in a resource's tier as its CPU load changes

---

Site [llms.txt](/llms.txt)

---

Auto scaling is built from Cloud Management Platform (CMP) parts you can see and change: a rule that checks deployed resources on a schedule, plugins that read CPU load, and a parameter on each resource that sets the thresholds.

## How it works

The **Check Resources for Scaling Conditions** rule reads each resource's **Auto-Scaling Config** parameter, which sets the minimum and maximum CPU thresholds per tier. When a tier exceeds its maximum, CMP adds more servers to it and adds them to the load balancer; when it falls below its minimum, CMP deletes servers and takes them out of the rotation. A tier is also brought back inside its `min_servers` and `max_servers` bounds whatever the CPU is doing.

CPU load is read by a separate plugin for each platform, so load measurements can differ between platforms such as vCenter and EC2. The rule looks for plugins whose name starts with **Get CPU Utilization**, then narrows them by the resource's group, the tier's environment, and the environment's resource technology, matching either a plugin restricted to that value or one left unrestricted. If more than one matches, it logs a warning and uses the first, which is why the setup step restricts each plugin to its own technology.

## Prerequisites

Start with a blueprint that deploys one or more servers and, optionally, a load balancer. Two web servers serving static content behind a load balancer make a good test case. Deploy it, confirm the resource behaves as expected, and confirm that manual scaling works. CMP ships a **Scale** resource action, disabled by default, that adds or removes servers in a tier and reconfigures the load balancer. Get that working before automating it.

## Set up auto scaling

1. Create the rule, plugins, and parameters. They are not installed by default. On the CMP appliance, become root and run the setup script:

   ```bash
   sudo su -
   /opt/cloudbolt/initialize/create_objects.py /opt/cloudbolt/initialize/cloud_bursting.py
   ```

1. Open each **Get CPU Utilization** plugin and set its **Resource technologies** to the technology it reads: VMware vCenter for **Get CPU Utilization for VMware**, and Amazon Web Services for **Get CPU Utilization for EC2**. Leaving the field blank makes a plugin eligible for every technology, which is what causes the wrong one to be picked.
1. Open the resource to scale, select its **Parameters** tab, and add **Auto-Scaling Config** with a value like the following, replacing the capitalized names with your own tier and environment:

   ```json
   {
       "TIER NAME": {
           "ENVIRONMENT NAME": {
               "cpu_max_threshold": 40,
               "cpu_min_threshold": 10,
               "max_servers": 5,
               "min_servers": 1,
               "scale_by": 1
           }
       }
   }
   ```

1. Enable the **Check Resources for Scaling Conditions** rule and the recurring job that runs rules. Neither is enabled by default; see [Rules](/docs/cmp/use/orchestration/rules/).

### Auto-Scaling Config keys

The value is a JSON object, keyed by tier name and then by environment name. Within each environment:

| Key | What it does |
| --- | --- |
| `max_servers` | The most servers the tier may have in this environment. Required. |
| `min_servers` | The fewest servers the tier may have in this environment. Required. Set it to 0 for an environment that should be empty until the tier bursts into it. |
| `cpu_max_threshold` | The average CPU percentage above which the tier scales up. Defaults to 100, which never triggers. |
| `cpu_min_threshold` | The average CPU percentage below which the tier scales down. Defaults to 0, which never triggers. |
| `scale_by` | How many servers to add or remove each time the tier scales. Defaults to 1. |
| `burst_into` | The name of the environment to grow into once this one is at its maximum. Optional. |

<div class="alert alert-info" role="alert">


To test the thresholds without generating real load, set the resource's **Simulated CPU Load** parameter. When that parameter has a non-zero value, CMP reads its value via the **Get CPU Utilization from Parameter** plugin rather than from the platform, ignoring all technology restrictions.
</div>


## Burst into another environment

A tier can grow into a second environment once the first is full, which is how a tier that normally runs on-premises spills into a public cloud at peak.

1. In the blueprint, configure that server build item to deploy to the second environment as well.
1. In the resource's **Auto-Scaling Config**, add a second environment for the tier with its own thresholds.
1. Add a `burst_into` key to the first environment naming the second:

   ```json
   {
       "TIER NAME": {
           "ENVIRONMENT 1 NAME": {
               "cpu_max_threshold": 20,
               "cpu_min_threshold": 10,
               "max_servers": 2,
               "min_servers": 1,
               "scale_by": 1,
               "burst_into": "ENVIRONMENT 2 NAME"
           },
           "ENVIRONMENT 2 NAME": {
               "cpu_max_threshold": 50,
               "cpu_min_threshold": 20,
               "max_servers": 3,
               "min_servers": 0,
               "scale_by": 1
           }
       }
   }
   ```

Once the tier has burst, the second environment scales up and down on its own thresholds, and the first can burst again if it fills up.

## Related

- [Rules](/docs/cmp/use/orchestration/rules/): Enable the scaling rule, run it on demand, and see how rules are scheduled.
- [Advanced network support](/docs/cmp/use/blueprints/build/advanced-network-support/): Configure the load balancer that scaling adds servers to and removes them from.
- [Resource actions](/docs/cmp/use/orchestration/actions/resource-actions/): The **Scale** action and adding your own day-two operations.