Control and scaling concepts
Manage scaling groups
This page describes basic scaling group concepts and actions.
For more topics about scaling groups, see Manage scaling groups advanced.
Introduction to autoscaling
To configure an automatic response to changing demands for resources, you can scale out VMs or scale them in, which is also called horizontal autoscaling. To scale out, the platform clones the base VM and deploys the clones. To scale in, the platform will delete clone VMs and undeploy the base VM. Scaling operations are subject to all standard platform constraints, such as privileges and allocation limits.
Limitations:
Autoscaling does not clone captured VMs, so to use scaling groups with a captured VM, create an instance and recreate the VM. Save VM disks to create an instance template
VApp specs do not support scaling groups. See What do virtual appliance specs save and create
Scaling groups have aggregate alarms that are associated with the base VM. This means that you can push custom metrics for clone VMs but you cannot create alarms for cloned VMs that are part of a scaling group.
State of base VM: A scaling group with a deployed base VM would be destroyed if the base VM were deleted directly on the hypervisor. In contrast, a scaling group with an undeployed base VM is not vulnerable to interference at the hypervisor level
To stop autoscaling, put the scaling group into maintenance mode.
Automatically scale VMs
The platform enables you to automatically scale out (add more VMs) or scale up (add more resources to existing VMs).
Privileges: Manage scaling groups, Manage workflow for scaling groups
To use autoscaling do these steps:
Create a base VM, which can be deployed or undeployed
Configure the VM and enable metrics
Define a scaling group with rules for scaling the VM.
The checkbox to automatically create a scaling action, will create the following automatically:Standard alarms and alerts for the selected metrics
Action plans with scaling actions for the VM and triggers for the action plans, which are monitoring alerts
You can customize the elements the platform creates, or you can create your own configuration.
Related pages:
Define a scaling group
Before you begin:
Configure the base VM that will be scaled
Ensure that you have enough resources in your virtual datacenter to deploy up to the maximum number of cloned VMs, especially IP addresses
To create a scaling group:
Go to Virtual datacenters → Virtual appliances
On the VM icon, from the options menu, select Define scaling group
Enter the scaling parameters
For the Default cooldown, enter the period of time to wait from the start of one scaling operation before allowing another scaling operation
For the Minimum running virtual machines that Abiquo must maintain in the scaling group, the value must be greater than or equal to zero, where zero means that the base machine is not deployed
The option to Keep virtual machines in the same layer can maintain VM anti-affinity layers when autoscaling
Administrators with the privilege to Manage workflow for scaling groups can Disable workflow or enable it as required
Optionally, select Create in maintenance mode to delay the start of autoscaling, and the automatic deployment of VMs to meet the minimum size
Select the option to Create autoscaling action to create basic operations to scale in and scale out, with triggers based on metrics and alarm conditions.
Create scaling rules
For Scale out rules, enter the number of VMs to Add. This is the number of times to clone the base VM and deploy each clone for each scaling step
For Scale in rules, enter the number of VMs to Remove. Abiquo will delete clone machines and undeploy the base machine
If there is no time range, then this is a default scaling rule. A time range must be unique and cannot overlap with other rules with the same scaling direction.
Click Save
When you save the scaling group, Abiquo will mark the VM icon with the scaling group symbol and display the scaling group name.
When the scaling group leaves maintenance mode, Abiquo will create clones of the base VM and deploy them to reach the minimum size.
The number in the bottom right-hand corner of the icon is the number of running VMs in the scaling group, including the base VM.
To open the scaling group and check its parameters, click the scaling group symbol at the top of the VM icon.
Configure automatic scaling actions
To configure automatic scaling actions:
When you define a scaling group, select Create autoscaling action and Save the scaling group
In the dialog, select a Metric to control an autoscaling action
To configure more options, including the thresholds for scaling in and scaling out, click Show more
To add this action, click Add
Add more actions as required
The platform will automatically create the alarms, alerts, and action plan to automatically scale in or out according to your thresholds.
Trigger autoscaling
Before you begin:
Create a VM and a scaling group for the VM. See Manage scaling groups
If you create an automatic scaling action, then the VM metrics will trigger autoscaling when they cross the thresholds set for the actions
To enable autoscaling operations to run:
Create an action plan with a scaling action for the VM with the scaling group. See Manage action plans
Create triggers to run the action plan. See Manage action plans
When scaling, the platform will search for a scaling rule that is valid for the specific time range, or for a default rule. It will create or delete/undeploy the number of VMs in the rule, then wait for the cooldown period before accepting another scaling request.
Autoscaling will not run if the scaling group is in maintenance mode.
How the platform scales VMs
To scale out, the platform does not deploy VMs that are undeployed in the scaling group. To clone the base VM, the platform will do the following:
Create disks using the following:
Copies of content of disks from the VM template
Empty disks or volumes for each additional disk used in the VM
Disk controllers used in the VM
Apply ALL configuration used in the VM, for example:
CPU and RAM
Network connections of the same type (e.g. private network)
Assignment of firewall policies and attachment to load balancers
Backups, startup script, cloud-init, variables, and so on
Metrics. The group of metrics from clone VMs and the base VM (if it is deployed) can activate alarms in the base VM, even if it is not deployed
Exception – Alarms: the scaling group has only one set of alarms in the base VM
To scale in, Abiquo currently selects the VMs to delete or undeploy using first in, first out (FIFO). The platform deletes and undeploys VMs without requesting user confirmation when there are disks that are not stored in the Apps library (ISO configuration drive or additional hard disk).
Perform maintenance on a scaling group
To make changes to your VMs in a scaling group (manually deploy, undeploy, delete, etc.) and edit the scaling group, put it into maintenance mode, which will disable autoscaling.
When you leave maintenance mode, the platform will apply your modifications to the scaling group, e.g. adding new rules. Then the platform will adjust the number of VMs in the group to within the minimum and maximum size range.
To put the scaling group in maintenance mode:
Go to Virtual datacenters → Virtual appliances → select VM
At the bottom of the VM icon, click the cog maintenance symbol at the bottom of the VM icon
OR if the scaling group is open, click the spanner maintenance symbol in the top right corner
To leave maintenance mode
Click a maintenance button
To automatically manage maintenance mode
Trigger action plans with the action "Scaling group: start maintenance mode" or "Scaling group: end maintenance mode".
To delete the base VM, you must delete the scaling group first.
Delete a scaling group
When you delete a scaling group, the platform will place all the VMs in the virtual appliance as regular VMs and the scaling group constraints will no longer exist.
To delete a scaling group:
Go to Virtual datacenters → Virtual appliances
Open the scaling group
Click the wrench maintenance button to put the scaling group into maintenance mode
Click the trash can delete button
Manage alerts
This section describes how to manage multi-cloud alerts for any group of resource metrics across your cloud providers in the multi-cloud platform
Introduction to alerts
An alert is a group of one or more alarms. An alert can notify the user when it activates and it can also trigger action plans. An alert activates when all its alarms are activated. An alarm activates when a metric passes a certain threshold.
If you imagine a dashboard for your metrics, alarms are like red lights that light up when conditions change, for example, when there is a problem. Alerts are like a worker monitoring a group of alarms; when all the lights for the group are lit up, then the worker takes action and activates the alert.
Display alerts
To display and manage alerts:
Go to Control → Alerts
Create alerts and alarms
An alert will trigger when all its alarms are activated. You can use the alert to notify users and trigger automation. See Manage action plans.
Privileges: Access alerts section, Manage alerts
Before you begin:
Retrieve VM built-in metrics, by editing VMs and enabling monitoring (see VM monitoring and metrics) or create custom metrics
Create one or more metric alarms (see Manage cloud alarms and Infrastructure alarms). You cannot save an alert without an alarm
To create an alert:
Go to Control → Alerts
Click the + add button
Enter the General information
To disable action when the alert activates, select the Muted checkbox
For the Email, enter a comma separated list of emails to notify when the alert activates
To assign alarms to the alert, click the + add button. To be able to save the alert, you must assign at least one alarm.
Select an existing alarm, or create a new alarm, and assign it to the alert. You can filter the Alarms list by Metric and also if the alarm is Active or not.
Repeat for the required alarms.
Click Confirm
Click Save
Remove alarms from alerts
You can delete any alarm at any time, even if it is part of one or more alerts. The platform will not warn you that the alarm is used in an alert. However, you can check this in Control view. After you delete an alarm, you cannot recover it.
You can also remove an alarm from an alert.
Privileges: Access alarms section, Manage alarms, Manage alerts
To delete an alarm:
Go to Virtual datacenters or Infrastructure → Alarms
Select the alarm and delete it by clicking on the trash bin delete button
To remove an alarm from an alert:
Go to Control → Alerts → edit alert
Select the alarm, click the trash bin delete button, and confirm
The platform will remove it from this alert, but it will remain in all other alerts that it is associated with
If you delete a VM, the platform will delete any alarms associated with its metrics.
Manage action plans
Introduction to action plans
To enable more control over cloud operations, users can create no-code action plans that can automatically run tasks on VMs and scaling groups, and to run general tasks, such as sending an email or web hook.
Action plans are an important automation functionality of the platform. They can combine general tasks with tasks that run on VMs and scaling groups in different providers and have multiple triggers including alerts from custom metrics, built-in metrics, budget alerts, and schedules.
Users can select groups of VMs or scaling groups to run actions based on tags. And multiple action plans can apply to a VM or scaling group.
Display action plans
To display action plans:
Go to Control → Action plans
Create an action plan
Before you create an action plan, consider the elements that you wish to automate with the action plan. Create VMs or scaling groups, fetch metrics, and create alarms and alerts.
To create an action plan:
Go to Control → Action plans, and click the + add button
Enter the action plan details
Go to Actions to add actions:
Click the + add button
Select the action Type: general action, VM, scaling group, VMs by tags, scaling groups by tags
If you are selecting by tags, then enter the tag filter.
See Search for resources by tag and filter searchEnter action details
Decrease CPU/RAM: you cannot use this with hot-reconfigure and you must check that the OS is compatible
Instance: Name for Instance (clone) template. The platform will append the date to the name supplied
Webhook action - Expected HTTP status code: If this status code is returned, continue running the action plan. Default:
204 No Content
Email action - To, CC: Enter email addresses as a comma separated list
For more details, see Action plan actions table and Webhook actions table below.
Put the actions in run order using the arrow buttons
To run the action plan automatically, go to the Triggers tab and create an alert or schedule trigger.
When you create actions on VMs also consider the following constraints.
User constraints: e.g. allocation limits
Platform constraints: e.g. to create an instance, the VM must be deployed and powered off
Hypervisor constraints: e.g. with hot reconfigure on ESXi, you cannot reduce CPU or RAM
For the API you can request the JSON schema for each action plan entry type from the API.
See: https://wiki.abiquo.com/api/latest/ActionPlansResource.html#list-action-plan-entry-templates
Action plan actions table
Action | Notes and Parameters |
---|---|
Virtual machine | |
Increase CPU | vCPUs |
Decrease CPU | vCPUs. Not supported by hot-reconfigure. Check OS compatibility |
Increase RAM |
|
Decrease RAM |
|
Increase hardware profile | Use the same family and type |
Decrease hardware profile | Use the same family and type |
Resize disk |
|
Instance |
|
Set hardware profile | Select from the available hardware profiles |
General | |
Send email |
Enter email addresses as a comma separated list |
Send webhook | See webhook attributes table |
Scaling group | |
Start maintenance | |
End maintenance | |
Scale in | |
Scale out |
Webhook action attributes table
Attribute | Description | Required | Default value |
---|---|---|---|
Endpoint | Where to submit the request | true | |
HTTP Method | The type of request can be GET, POST, or PUT | false | GET |
Expected HTTP status code | If this status code is returned, continue running the action plan | false | 204 No Content |
Request headers | Headers such as, secret, authentication, and content-type | false | |
Request content | Request body | false |
Run an action plan now
To run an action plan immediately to test it, do these steps:
Go to Control → Action plans
Select the action plan
On the Actions pane, click the Run action plan button
Abiquo recommends that you run an action plan manually to test it before you create a trigger to run it automatically.
Create a trigger for an action plan
The platform supports two types of triggers to run action plans: Alerts and Schedules.
To run your action plan based on metrics, select an existing alert with these steps:
Go to Control → Action plans
Select an action plan
Below the Alerts panel, click the + add button
Select an alert. For details about creating an alert, see Manage alerts.
To run your action plan automatically at selected dates and times, cre
ate a schedule trigger with these steps:
Go to Control → Action plans
Select an action plan
Below the Schedules panel, click the + add button
Enter the details of the schedule using the calendar or time and repeat interval as described below
To run the action plan at intervals of a fixed number of seconds within a set timeframe:
Select an Interval schedule
Enter the following parameters
Interval seconds: the number of seconds from when the action plan execution starts to when it will start again
Repeat count: the number of times to run the action plan. A value of
0
means repeat foreverStart time: date and time
End time: date and time
After you create an interval schedule, the platform will display the execution count of how many times the action plan has run. If the repeat count is 0
, the execution count is null
.
To run the action plan using a Cron-type schedule:
Select an Advanced schedule
Use the calendar selector.
Delete an action plan
If you delete an action plan, Abiquo will also delete the schedule associated with that action plan.