Auto scaling
4 minute read
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
-
Create the rule, plugins, and parameters. They are not installed by default. On the CMP appliance, become root and run the setup script:
sudo su - /opt/cloudbolt/initialize/create_objects.py /opt/cloudbolt/initialize/cloud_bursting.py -
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.
-
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:
{ "TIER NAME": { "ENVIRONMENT NAME": { "cpu_max_threshold": 40, "cpu_min_threshold": 10, "max_servers": 5, "min_servers": 1, "scale_by": 1 } } } -
Enable the Check Resources for Scaling Conditions rule and the recurring job that runs rules. Neither is enabled by default; see 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. |
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.
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.
-
In the blueprint, configure that server build item to deploy to the second environment as well.
-
In the resource’s Auto-Scaling Config, add a second environment for the tier with its own thresholds.
-
Add a
burst_intokey to the first environment naming the second:{ "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: Enable the scaling rule, run it on demand, and see how rules are scheduled.
- Advanced network support: Configure the load balancer that scaling adds servers to and removes them from.
- Resource actions: The Scale action and adding your own day-two operations.