|Metric||A built-in metric that is provided by a hypervisor or provider (e.g. CPU usage) or a custom metric that the user creates and populates using API calls|
|Alarm||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.
See Manage cloud alarms and Infrastructure Alarms
|Alert||An alert enables you to configure notifications or actions from alarms. |
Alerts are like a worker monitoring a group of alarms; when all the lights for the group are lit up, the alert is activated.
Alerts can trigger action plans.
|Action plan||A sequence of actions to perform on entities on the platform, such as VMs or scaling groups. An action plan is run by a trigger.|
|Trigger||A trigger is an alert or a schedule that will run the action plan, for example, during times of increased demand.|
|Scaling group||For horizontal autoscaling, create a scaling group for a VM with rules to define how the platform should scale it out. |
You can then include scaling operations in an action plan.
|Vertical scaling||Vertical scaling means scaling up, adding more resources to an existing VM, for example, boosting your CPU and or RAM capacity.|
|Horizontal scaling||Horizontal scaling means scaling out, deploying more VMs when you need more resources.|
Then you can configure the display of metrics at the virtual appliance level.
To configure the refresh interval
Choose the metrics you wish to display and filter by metric statistics.
When you are fetching metrics, you can configure alarms on these metrics. See Manage cloud alarms
Screenshot: A scaling group with VMs deployed automatically.
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.
The platform enables you to automatically scale out (add more VMs) or scale up (add more resources to existing VMs). To use autoscaling do these steps:
The checkbox to automatically create a scaling action, will create the following automatically:
You can customize the elements the platform creates, or you can create your own configuration.
To use autoscaling do these steps:
To create a scaling group:
|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 machines||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|
|Create autoscaling action||Create basic operations to scale in and scale out, with triggers based on metrics and alarm conditions.|
|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.
To open the scaling group and check its parameters, click the scaling group symbol at the top of the VM icon.
To enable autoscaling operations to run:
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.
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).
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:
To leave maintenance mode
To automatically manage maintenance mode
To delete the base VM, you must delete the scaling group first.
To move a scaling group to a restricted virtual appliance, do these steps:
To delete a scaling group: