To configure an automatic response to changing demands for resources, you can scale out VMs, 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 but it will just undeploy the base VM. Scaling operations are subject to all standard platform constraints, such as privileges and allocation limits.
- The platform does not clone captured VMs, so you will need to create an instance and recreate the VM from the resulting template to use scaling groups
- VApp specs do not support scaling groups
- 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
The platform enables you to automatically scale out (add more VMs) or scale up (add more resources to existing VMs).
Privilege: Manage scaling groups, Manage workflow for scaling groups
To use autoscaling do these steps:
- Create a base VM, which can be deployed or undeployed
- Define a scaling group with rules for scaling the VM
- Create an action plan with scaling actions for the VM. Create triggers for the action plan, which are either monitoring alerts for virtual appliances or schedules for planned scaling
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
- Select the base VM, and from the menu on the VM icon, select the Create scaling group option
- Enter the scaling parameters and rules
- Click Save
|Name||Name of the scaling group |
|Default cooldown||Period of time to wait from the start of one scaling operation before allowing another scaling operation|
|Minimum running virtual machines|
The minimum running VMs 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
|Maximum running virtual machiness||The maximum running VMs that Abiquo must maintain in the scaling group|
|Keep virtual machines in the same layer||Select this option to maintain VM anti-affinity layers when autoscaling|
|Disable workflow||Administrators with the privilege to Manage workflow for scaling groups can use this option to disable workflow or enable it as required.|
|Create in maintenance mode||Select this option to create the scaling group with maintenance mode ON, for example, to delay the automatic deployment of VMs to meet the minimum size|
|Scaling rules||Scaling rules describe how Abiquo will behave when a scaling event is triggered, for example, by an alert or a schedule.|
|VMs||For a scale out rule, the number of times to clone the base machine and deploy each clone for each scaling step. For a scale in rule, the number of machines to remove from the scaling group (Abiquo will delete clone machines and undeploy the base machine)|
|Cooldown||The cooldown time to wait between scaling operations under this rule|
|Start||Date and time to start the time range when scaling triggers will start a scaling operation under this rule. The time range must be unique and cannot overlap with other rules with the same scaling direction. If there is no time range, then this is a default scaling rule.|
|End||Date and time that is the end of the time range when scaling triggers will start a scaling operation. The time range must be unique and cannot overlap with other rules with the same scaling direction. If there is no time range, then this is a default scaling rule|
When you save the scaling group, Abiquo will mark the VM icon with the scaling group symbol and display the scaling group name. If the minimum number of deployed VMs are not present and the scaling group is not in maintenance, 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 in the top right-hand corner of the VM icon.
Before you begin:
- Create a VM and a scaling group for the VM. See Define a scaling group
To trigger autoscaling operations:
- Create an action plan with a scaling action for the VM with the scaling group. See Create an action plan to automate VM actions
- Create triggers to run the action plan. See Create a trigger for an action plan
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.
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
- Chef recipes, backups, 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
Maintenance mode temporarily disables autoscaling and enables you to make changes to your VMs (deploy, undeploy, delete etc.) and edit the scaling group. Note that you cannot delete the base VM without deleting the scaling group. Also you cannot create alarms for cloned VMs that are part of a scaling group, because the scaling group alarms are in the base VM. When you leave maintenance mode, Abiquo will apply your modifications to the scaling group, e.g. adding new rules. Then Abiquo 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
- Click the "cog" maintenance button
- Trigger an action plan with the action "Scaling group: start maintenance mode"
To leave maintenance mode, click the "cog" maintenance button again or trigger an action plan with the action "Scaling group: end maintenance mode".
Move a scaling group to another virtual appliance in the same virtual datacenter
To move a scaling group in maintenance mode to another virtual appliance in the same virtual datacenter:
- Click the Move VM button
- Select the new virtual appliance
Restrict a scaling group
To move a scaling group to a restricted virtual appliance, do these steps:
- Go to Virtual datacenters → select scaling group
- Click the VM move button on the VM control panel
- Select the checkbox to Move to a restricted virtual appliance, select a restricted virtual appliance, or create a new VApp and select the Restrict virtual appliance checkbox
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 → select scaling group
- Click the "cog" button to put the scaling group into maintenance mode or run a maintenance action in an action plan
- Click the delete button
Manage scaling groups with the API