Abiquo 5.1
Now users could work directly with public cloud platforms, it may seem difficult to maintain control, as though the users were just walking into a datacenter and grabbing a few servers to install and run their choice of software! This section explains how the Abiquo multi-cloud platform can bring everything together and save costs, and it also introduces some basic technical concepts of the public cloud integrations.
This section describes just two of the key concepts of public cloud management in Abiquo. These features are in addition to the powerful policy and governance of Abiquo's multi-cloud platform, which includes user privileges and allocation limits for private and public cloud.
No one likes a big public cloud bill surprise but you probably know someone who has received one! The Abiquo public cloud platform obtains public cloud billing data for recent bills from all providers and even has an aggregate view of all providers, so that you and your users (if you allow them) can discover the trends in public cloud costs.
And it loads the current usage on a daily basis to incorporate into an estimate of the next bill.
And Abiquo enables you to create and track budgets across multiple public cloud provider accounts based on this usage and billing data.
All of these cost control features are available at both a reseller and a customer level.
If your organization is a public cloud reseller (for example, as part of the CSP or APN programs), then you can easily create customer accounts through the platform, with the click of a button.
Just enter the details that the provider requires, including the cloud tenant ("Enterprise") that the account will belong to.
The platform will automatically create an account in the provider and add the credentials for the cloud tenant, so they will be ready to deploy.
Let's look at some key technical concepts of the Abiquo integrations with vCloud Director, AWS, and Azure. Abiquo offers unifies multiple different public cloud offerings to make it easier for your users to work in public cloud, and saving your public cloud experts time. It also gives you control over how much your users consume with resource allocation limits to match these technical elements.
The platform offers user access to virtual datacenters (VDCs) that are separate groups of virtual resources. A VDC has equivalents in each cloud provider, so it gives you a common interface and API to all the providers - see the table below. For example, the platform’s concept of the VDC is equivalent to the VPC in AWS (Amazon). In vCloud Director (vCloud), the VDC is equivalent to a vApp. In ARM Compute (Azure), the VDC is equivalent to a Virtual Network and its associated resources.
Within its VDCs, the platform groups VMs into virtual appliances (VApps). The purpose of the VApp is to enable you to manage a group of VMs together, which means that you can deploy them in one click, or view their metrics together, or create custom metrics for the VApp, for example. You can move VMs from one VApp to another within the same VDC. A VApp is not equivalent to any specific concept in vCloud or public cloud.
In vCloud, the platform supports the onboarding of the following networks. Users can also fully manage certain network types.
All users should configure their user accounts before starting work with the cloud platform.
To change your user password and user details:
Note that you cannot change many of the details of the main cloud administrator account, and you cannot change its role and privileges. However, you can replace the main cloud administrator account with another equivalent cloud administrator account. You can also edit this user account and other user accounts in Users View
Before you begin:
To enable two-factor authentication for your user account, do these steps:
Copy the Backup codes from the configuration window to a secure place. You can use these codes to log in to the platform if the authentication cycle fails
The platform will display Backup codes ONCE only
Privilege: Access Infrastructure view and PCRs, Manage public cloud regions
Before you begin:
To create a new public cloud region:
Click the + add button at the bottom of the public cloud regions list.
The Create public cloud region dialog will open. Enter the base Name and select the Provider. Select the Regions
The platform will create the first region with the Name you enter and the others with a suffix of "_1", "_2", and so on.
If for some reason the platform cannot create a region, it will move on to the next region on the list
Click Next
The platform will create your public cloud region.
Privilege: Manage enterprises, Manage users of all enterprises
Before you begin managing enterprises, we recommend that you do these steps:
To create a cloud tenant enterprise, do these steps:
Go to Users → Enterprises
Click the + add button below the Enterprises list
Abiquo will create the enterprise and filter to display only this enterprise. To display other enterprises, click the X beside the enterprise name in the filter box at the top of the Enterprises list.
After you have created the enterprise:To set enterprise allocation limits:
Limit | Checked at | Description |
---|---|---|
Memory | Deployment | Total amount of RAM that may be used by VMs including hardware profiles assigned to VMs |
Virtual CPUs | Deployment | Total number of virtual CPU cores that may be used by VMs including hardware profiles assigned to VMs |
Local hard disk | Deployment | Total size of hard disk that may be used by VMs on hypervisor datastores and in public cloud providers |
External storage | Configuration | Total size of external storage that may be assigned to VMs |
VLANs | Configuration | Total number of private VLANs that may be defined. Note that a private VLAN is automatically created for every VDC, so this limit may restrict the number of VDCs that users can create |
Public /floating/NAT IPs | Configuration | Total number of public IPs, floating IPs (in public cloud), and NAT IPs that may be used |
Repository | Operations | Total size of NFS Repository space that maybe used for the Apps Library including templates and instances (but not conversions). See Manage the Datacenter Apps Library#HowmuchspacecanatenantuseintheAppsLibrary? |
Virtual machines | Deployment | Total number of VMs that users can deploy in the location using their allowed resources |
In public cloud regions, the platform does not use Repository (Apps library storage) features or limits
To set the datacenters and public cloud regions that an enterprise is allowed to access:
Drag datacenters and public cloud regions from the left pane to the Allowed datacenters right pane
If you have multiple public cloud regions on the platform, they may be grouped provider, which enables you to drag providers or regions. To set default Allocation limits and VDC roles for regions in a provider, edit the provider.
To display the enterprises with access to a public cloud region, go to Infrastructure → Public → select region → servers view → Virtual machines → Accounts
To configure resources, including allocation limits for each allowed datacenter and public cloud region, see Configure an Enterprise in a Cloud Location.
At the location level, you can limit resources and set defaults. This means you can set an allocation limit for an enterprise in each datacenter or public cloud region.
To configure the same limits for all regions in a provider, select a provider group. For example, if you enter a hard limit of 8 CPUs, then the platform will create a hard limit of 8 CPUs in each region for this provider. This option is available when regions are grouped by provider or vCloud endpoint. See Group public cloud regions by provider or endpoint
To limit resources in a datacenter or public cloud region, set allocation limits:
This is process is very similar to that of setting enterprise limits.
Limit | Checked at | Description |
---|---|---|
Memory | Deployment | Total amount of RAM that may be used by VMs including hardware profiles assigned to VMs |
Virtual CPUs | Deployment | Total number of virtual CPU cores that may be used by VMs including hardware profiles assigned to VMs |
Local Hard Disk | Deployment | Total size of hard disk that may be used by VMs on hypervisor datastores and in public cloud providers |
External Storage | Configuration | Total size of external storage that may be created for assignment to VMs |
VLANs | Configuration | Total number of private VLANs that may be defined. Note that a private VLAN is automatically created for every VDC, so this limit may restrict the number of VDCs that users can create. |
Public IPs | Configuration | Total number of Public IPs, floating IPs (in public cloud), and NAT IPs that may be used |
Repository | Operations | Private cloud: Total size of NFS Repository space that maybe used for the Apps Library including templates and instances (but not conversions). Manage the Datacenter Apps Library#How much space can I use in the Apps Library? |
Virtual machines | Deployment | Total number of VMs that users can deploy in the location using their allowed resources |
Privilege: Manage provider credentials
Before you begin:
Obtain credentials to access the cloud provider's API. We provide basic guides but you should always check with your provider. See Obtain public cloud credentials.
To add public cloud credentials:
Attribute | Description |
---|---|
Provider | Select public cloud provider or vCloud Director region. Some providers may require different credentials for groups of regions, for example, "Amazon (CHINA)". If a specific provider does not display, for example, a vCloud Director region, the cloud administrator may need to allow access for your enterprise. |
Access key ID | Identity to access the cloud provider API. For example, a username, API access key ID, subscription ID and certificate, or another account identifier. For DigitalOcean v2, the platform does not use this field but you need to write something in to enable the button Add account after. For Azure, the format is subscription-id#app-id#tenant-id |
Secret access key | Key to access the cloud provider API. For example, an API key or other API credential. For DigitalOcean v2 enter the token. |
Also use for pricing | Use this credential to access pricing data in the provider. For example, to get hardware profile prices from AWS. For Azure, add a separate pricing credential. |
Current credentials | Provider that have credentials already in the platform |
Create account | For resellers with Amazon, Azure ARM, and other partner accounts, click the enterprise create account button to create a customer account in the provider and add it to an enterprise in the platform |
Finish editing the enterprise and click Save
This will add a cloud provider account for a tenant enterprise with access to a public cloud region.
In the Abiquo Apps Library you can compile a selection of certified public cloud templates for your users to deploy by self-service.
Abiquo will store the details of these templates but not their disks.
Public cloud libraries can have many thousands of VM templates (e.g. AWS has 19,000 AMIs) that are difficult to find and manage. In addition, administrators cannot control the content of public cloud templates. In the Apps library, you can define a cache of details of your approved or certified public cloud templates. And you can customize the templates' representation to make it even easier for cloud users to find the right template.
To display the details of a template, move the mouse over the template. A tooltip will display the template information.
To filter templates in the Apps library:
To reset filter values to defaults, click Clear.
You can onboard virtual resources from public cloud into the platform. If the cloud provider supports virtual datacenter (VDC) entities, such as AWS VPCs or Azure virtual networks, you can onboard them as VDCs and synchronize them. If the cloud provider does not support VDCs, then you can onboard the resources from the public cloud regions, such as RackSpace regions
To onboard a virtual datacenter from public cloud:
Field | Description |
---|---|
Location | Select the public cloud region to synchronize from the pull down list |
Virtual datacenter | Select the virtual datacenter entity to onboard. In AWS, this will be a VPC. In Azure, it will be a virtual network and its resources. If the provider does not support a virtual datacenter entity, the paltform will onboard all of the compatible virtual resources in the region into a default virtual datacenter. |
See classic | Click here to display classic VMs that the platform does not onboard |
Field | Description |
---|---|
Role | To limit access to the VDC for cloud users, select a more restrictive role to replace user roles within this VDC. For example, to give users read only access, select the ENTERPRISE_VIEWER role |
User exceptions | To create exceptions to the VDC role, select a username and an exception role for the user and click Add. The exception will enable all privileges that are included in both the user's role and the exception role |
Users with bespoke network configurations should check the results of the synchronization.
The platform will synchronize private and public IP addresses even if they are not in use by VMs, and mark the IP addresses in use by provider entities with provider identifiers.
The platform will import VM templates. If the platform cannot find the VM template, the VM will have no template in the platform. To save a copy of your VM disk to create a template, so you can recreate the VM, make an Abiquo instance of the VM.
If you delete a synchronized VDC, the platform will delete it in the provider. If your enterprise does not have valid credentials for the public cloud provider, when you delete public cloud entities in the platform, they will still exist in the public cloud provider
To display classic VMs in public cloud:
Click the See classic link
To synchronize specific resources such as networks, public IPs, and so on:
For more information, see the resource documentation.
To delete these resources (if they are not in use), select the resource and click the delete button.
Before you begin:
To delete onboarded resources in public cloud:
If the enterprise does not have valid credentials for the public cloud provider, when you delete public cloud entities in the platform, they will continue to exist in the public cloud provider
Abiquo API Feature
This feature is available in the Abiquo API. See VirtualDatacentersResource for synchronization and AllowedLocationsResource for retrieval of virtual datacenters and VMs.
If your public cloud provider does not support virtual datacenter entities, to onboard virtual resources do the following steps:
The platform will place all VMs and network resources that are not related to existing virtual resources into a generic virtual datacenter. The platform names this virtual datacenter with the same name as the public cloud region, but the user can rename it. The platform will use this virtual datacenter for future synchronizations, adding or removing resources to match the cloud provider.
If there are already virtual resources in the platform for this provider, then these entities will already be part of a virtual datacenter. The platform will check if any new entities in the provider are related to the existing ones in the platform and place them in the existing virtual datacenter.
If the integration with the provider supports entities that are not in a virtual datacenter, such as firewalls, load balancers, or floating IPs, the platform may load these as separate entities.
If conflicts occur during synchronization, the platform will cancel the synchronization. This would occur if two VMs already exist in different VDCs but are related by a firewall or load balancer. Or if two firewall policies or load balancers exist in different virtual datacenters but are related by a VM.
You can work with virtual machines, networks and storage in Virtual datacenters view
This section describes the basic details to enter when creating a virtual datacenter. The following sections describe further configuration.
Field | Description |
---|---|
Name | The name of the virtual datacenter |
Location | The datacenter or public cloud region where virtual appliances will be deployed. You can select any of your allowed locations |
Hypervisor | The type of the hypervisor for the virtual datacenter. This option will not display if there is only one choice. |
Network |
|
If your environment supports NAT you may also be able to select the IP address for the default SNAT rule
Field | Description |
---|---|
NAT network | Optionally select the NAT network to use for the default SNAT rule |
Default NAT IP | Optionally select the NAT IP address for the default SNAT rule for the virtual datacenter |
When you create a virtual datacenter, the platform always creates a private network and it counts as part of your VLAN allocation limits, even if the default network is another type of network.
The private network can be the "Automatically-created private VLAN", which is called "default_private_network", or a custom private network, which will be set as the default network.
To create a Custom private network, complete the Network section of this dialog.
To manage the VLANs or other networks of your virtual datacenter, go to Virtual datacenters → Network. See Manage Networks.
The rules for creating allocation limits are as follows:
When editing limits, you cannot set the hard limits below the existing resource usage.
Limit | Checked at | Description |
---|---|---|
Memory | Deployment | Total amount of RAM that may be used by VMs including hardware profiles assigned to VMs |
Virtual CPUs | Deployment | Total number of virtual CPU cores that may be used by VMs including hardware profiles assigned to VMs |
Local hard disk | Deployment | Total size of hard disk that may be used by VMs on hypervisor datastores and in public cloud providers |
External storage | Configuration | Total size of external storage that may be created for VMs |
VLANs | Configuration | Total number of private VLANs that may be defined. Note that a private VLAN is automatically created for every VDC, so this limit may restrict the number of VDCs that users can create |
Public /floating/NAT IPs | Configuration | Total number of public IPs, floating IPs (in public cloud), and NAT IPs that may be used |
Virtual machines | Deployment | Total number of VMs that users can deploy in the location using their allowed resources |
In public cloud regions, the platform does not use Repository (Apps library storage) features or limits.
Field | Description |
---|---|
Default datastore tier | Select the default disk service level for your non-persistent virtual machine disks on the hypervisor. This is the default datastore tier for the virtual datacenter.
To clear the current tier, click the black x symbol beside the tier name |
Privilege: Manage roles, No VDC restriction
Field | Description |
---|---|
Role | To limit access to the VDC for cloud users, select a more restrictive role to replace user roles within this VDC. For example, to give users read only access, select the ENTERPRISE_VIEWER role |
User exceptions | To create exceptions to the VDC role, select a username and an exception role for the user and click Add. The exception will enable all privileges that are included in both the user's role and the exception role |
After you have entered Allocation limits, Defaults, and Role, click Save.
The platform will create the virtual datacenter and the default private VLAN and display it in the Virtual datacenters view.
API Documentation
For the Abiquo API documentation of this feature, see Abiquo API Resources and the page for this resource VirtualDatacentersResource.
This section describes how to manage networks in private datacenters and public cloud providers.
Privileges: Manage virtual network elements, Access external networks tab, Access public networks tab
API Features
Virtual datacenter networks are available in the Abiquo API. For example, see VirtualDatacentersResource and PrivateNetworksResource.
Screenshot: Private networks in private cloud
Screenshot: Private networks in public cloud (AWS)
In the Networks list, to view the pool and allocation of IPs:
You can then:
Private networks are only available within a virtual datacenter. However, your cloud provider may configure an external gateway for your virtual datacenter.
To create a private network:
Create private network
Create private network Amazon
Button | Action |
---|---|
Name | Name of the network (VLAN). The name can contain up to 128 characters |
IPv6 | Select checkbox for IPv6 network |
Network Address | Private address range of the network |
Netmask | For IPv4 a network mask with an integer value of between 16 and 30 |
Gateway | Gateway of the VLAN. Must be an IP within the range of the network address and mask |
Availability zone | In AWS, optionally select an Availability zone for high availability. To deploy a group of VMs separately, use a different availability zone for each VM. To assign a VM to an availability zone, assign a private IP address in the network belonging to the required availability zone |
Primary DNS | The primary DNS |
Secondary DNS | The secondary DNS |
DNS suffix | The DNS suffix |
Excluded from firewall | Select Excluded from firewall to define a network where VM firewalls will not apply |
Static Routes | In supported providers, optionally select Define to create static routes. See Configure Static Routes using DHCP |
Default network | Select to make this network the default network, replacing the existing default network |
You can configure static routes when you create or edit a network. However, you should check with your systems administrator about when your VM will receive changes to static routes.
Field | Description | Example |
---|---|---|
Netmask | Destination network mask | 255.255.255.0 |
Network ID | Destination network or host | 1.1.1.0 |
Gateway IP | Next hop (on your network) | 10.10.10.100 |
To create new IP addresses in a private network do these steps.
Or you can add an IP directly to a VM. To do this:
IP Addresses |
---|
30.30.30.30 |
30.30.30.31 |
30.30.30.32 |
30.30.30.33 |
30.30.30.34 |
30.30.30.35 |
When you add IPv6 addresses on strict networks, you don't need to set the starting address. On non-strict IPv6 networks, Abiquo recommends that you create an automatic IP address, or you can enter a From IP address manually.
The new settings will apply to all VMs deployed after you save the network.
To delete a private network:
Privileges: Manage virtual network elements, Access external networks tab, Manage external network elements
To display onboarded external networks
If an onboarded network has been deleted in the provider, its name will display in light gray text. If a VM is using an IP from this network, then you cannot deploy the VM.
If there are no VMs using the IPs of an external network that was already deleted in the provider, to delete the network in the platform, select it and click the delete button.
Privileges: Manage virtual datacenter network elements, Access public network tab, Manage public network elements, Access external network tab, Manage external network elements
To set a new or existing network as the default:
In private cloud, if you set a public network as the default, remember to obtain IP addresses for your VMs before you deploy!
Privilege: Manage public IPs, Access public networks tab, Manage public network elements
To add new public IP addresses to your virtual datacenter:
The platform will add the IPs to your VDC
You can also reserve public IPs directly from the Edit VM dialog.
During onboarding from public cloud, the platform will onboard existing public IP addresses in providers that support them, such as AWS and Azure. You can obtain them from the provider and assign them to your virtual datacenters and VMs.
The provider may charge for public IP addresses as soon as you reserve them for your virtual datacenter. Therefore you should reserve your IP addresses just before you deploy and check they are deleted when you undeploy your VMs. Remember that your provider may also limit the number of public IP addresses that you can use per virtual datacenter.
To add public IP addresses to your virtual datacenter, so that you can later assign them to your VMs:
Privileges: Manage virtual network elements, Manage floating IPs, Access public networks tab, Manage public network elements
Now when you edit a VM in the VDC and go to Network → Public, the platform will display the public IP address and you can add it to your VM.
To obtain a public IP directly for a VM, click Purchase public IPs.
To onboard any public IP addresses that were already created in your cloud provider, or update changes made directly in the provider:
Privileges: Manage virtual network elements, Manage floating IPs, Access public networks tab, Manage public network elements
You can release a public IP if it is not assigned to a VM.
In private cloud, to release a public IP that belongs to a public network, select the IP in the IP list and click the delete button.
In public cloud, click the link to Remove from VDC and then click the delete button.
During onboarding from public cloud, the platform will onboard existing public IP addresses in providers that support them, such as AWS and Azure. You can obtain them from the provider and assign them to your virtual datacenters and VMs.
The provider may charge for public IP addresses as soon as you reserve them for your virtual datacenter. Therefore you should reserve your IP addresses just before you deploy and check they are deleted when you undeploy your VMs. Remember that your provider may also limit the number of public IP addresses that you can use per virtual datacenter.
To add public IP addresses to your virtual datacenter, so that you can later assign them to your VMs:
Privileges: Manage virtual network elements, Manage floating IPs, Access public networks tab, Manage public network elements
Now when you edit a VM in the VDC and go to Network → Public, the platform will display the public IP address and you can add it to your VM.
To obtain a public IP directly for a VM, click Purchase public IPs.
To onboard any public IP addresses that were already created in your cloud provider, or update changes made directly in the provider:
Privileges: Manage virtual network elements, Manage floating IPs, Access public networks tab, Manage public network elements
Related links:
This section describes firewall policies, which are similar to security groups. The platform supports firewall policies in private cloud with network managers (NSX) and in public cloud (AWS, Azure). In Oracle Cloud, the platform enables users to onboard classic firewalls and assign them to VMs.
In vCloud Director, the platform also supports classic firewalls, which are Edge firewalls at level of the public cloud region (orgVDC). See Manage classic firewalls
To synchronize firewalls do these steps:
To synchronize a firewall before you add new firewall rules:
The platform can create firewall policies in virtual datacenters in the provider, or in the platform only, for later use in providers, depending on provider support.
Privilege: Manage firewall
To create a new firewall, do these steps:
Field | Description |
---|---|
Name | Name of the firewall policy. |
Location | Public cloud region or datacenter |
Virtual datacenter |
|
Default | Optional. Select to make the firewall the default for the virtual datacenter |
Description | Description of the firewall policy |
If you entered a virtual datacenter, the platform created your firewall in the provider. The platform will display a Provider-ID and a Virtual datacenter ID for the firewall.
If you selected No virtual datacenter, the firewall will be created in the platform in the public cloud region for your enterprise. The synchronize process will not update this firewall. The platform will not create it in the provider until you select a virtual datacenter.
Privilege: Manage default firewall
To set or unset a default firewall for a virtual datacenter:
When the user creates a VM, the platform will assign the default firewall. The firewall rules apply to VMs, not individual NICs on the VMs. Changes to the firewall ruleset will apply to every VM in the virtual datacenter with the default firewall. If you do not set a default firewall but the provider requires one, for example, AWS, the platform will set the provider's default firewall. In AWS the default firewall is not marked.
To edit a firewall policy:
Field | Description |
---|---|
Name | Name of the firewall policy. Some providers will not allow you to edit the name of the firewall policy |
Default | Select this option to set the firewall as the default. The platform will assign the default firewall to new VMs. |
Description | Description of the firewall policy |
To move a firewall to another virtual datacenter
To add a new firewall rule:
Before you edit firewall rules in AWS, synchronize the firewall to update the rules because AWS will not allow you to create a rule that already exists in the security group. Remember that it may take some time for firewall rules to propagate throughout AWS. Until the rules have propagated, the platform will not be able to detect them. See http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/query-api-troubleshooting.html#eventual-consistency
To delete firewall rules, do these steps.
To display firewalls that exist in a virtual datacenter in the provider:
To display all firewalls in a location (public cloud region or datacenter), including those that only exist in the platform and not in the provider:
To filter firewalls, enter text in the Search box to search by the Name, Description, and Provider ID in the Firewalls list.
See Assign a firewall policy to a VM
To delete a firewall policy:
API Documentation
For the Abiquo API documentation of this feature, see Abiquo API Resources and the page for this resource FirewallPoliciesResource.
Please refer to cloud provider documentation as the definitive guide to the load balancing features. And remember to check your cloud provider pricing before you begin.
In vCloud Director, load balancers belong to a public cloud region, not a virtual datacenter. This means that in vCloud Director, you can attach VMs from more than one virtual datacenter to the same load balancer, and these load balancers do not work with private networks, which belong to only one virtual datacenter.
See Provider support for load balancers tables
To display load balancers in a region, including those that are not assigned to a virtual datacenter in a provider
To display load balancers in virtual datacenters:
Select a virtual datacenter
Go to Network → Load balancers.
Privilege: Manage load balancers, Assign load balancers
To create a load balancer:
Click the + add button and complete the following dialogs according to your cloud provider's documentation
The following screenshots are from AWS or Azure
Field | Value |
---|---|
Name | The name of the load balancer.
|
Subnets | In providers that support subnets, the subnets to which the load balancer will connect |
Algorithm | See cloud provider documentation for more information |
Addresses |
|
Field | Value |
---|---|
Common protocols | Select one of the common protocols to load presets |
Protocol in | The incoming protocol to the load balancer. See cloud provider documentation for accepted values. |
Port in | The incoming port to the load balancer. See cloud provider documentation for accepted values. |
Protocol out | The outgoing protocol from the load balancer. |
Port out | The outgoing port from the load balancer |
SSL Cerftificate | For secure connections (e.g. HTTPS), you can add an SSL certificate.
|
Add | Click Add to save a routing rule for the load balancer |
To delete a routing rule, click the delete button beside the name of the routing rule in the list
Field | Value |
---|---|
Name | Name of the certificate |
Certificate | The certificate contents |
Intermediate certificate | An intermediate certificate can be issued by a provider to support older browsers that may not have all of the trusted root certificates for that provider, so that users will not receive invalid SSL warnings. If you have an intermediate certificate, add it at the same time as the certificate to ensure that a trusted-chain certificate is configured. |
Private key | The RSA private key for the certificate |
Field | Value |
---|---|
Common protocols | Select one of the most common protocols to load presets |
Name | Name of the health check |
Protocol | The protocol with which the health check will be performed |
Port | The port to which the health check will be performed |
Path | The server path to ping (for supported protocols) |
Interval (sec) | The interval in seconds between health checks |
Timeout (sec) | The timeout in seconds after which an attempted health check will be considered unsuccessful |
Attempts | The number of attempts before the health check will be considered unsuccessful |
Add | Add the current health check to the load balancer |
If your provider supports firewalls, to add a firewall to your load balancer, select your firewall from the list of Firewalls that were created in your provider. Rackspace does not display a firewall selection list.
If a firewall is not on the list, it may not have been properly synchronized. In this case, you will need to click Cancel, synchronize firewalls and start again to create a new load balancer.
To assign your load balancer to VMs, drag and drop the VMs them from the Available Nodes list into the Attached Nodes list.
The platform will display the Status of the load balancer nodes on the Nodes tab, if status information is available from the provider.
You can also check the status using the Abiquo API.
API Documentation
For the Abiquo API documentation of this feature, see Abiquo API Resources and the page for this resource LoadBalancersResource.
The cloud provider determines which elements of a load balancer that you can modify. Due to different provider support for load balancer features, it may be possible to make modifications in the platform that will later be rejected by the cloud provider, triggering an error. Check your cloud provider documentation for supported modifications.
Privilege: Assign load balancers
To assign a virtual machine to a load balancer, select the load balancer from the list.
To access vCloud load balancers, and provider-only load balancers
To synchronize all load balancers in a VDC or region:
Load balancers that have been deleted directly in the provider are displayed in light gray text. You can edit these load balancers to recreate them in the provider, or delete them.
If your enterprise does not have credentials in the provider, then the load balancer will be released (it will be deleted in the platform but it will remain in cloud provider).
This section describes the tasks that may be performed by the cloud user.
If you are using a single sign on, you may need to ask your system administrator to update your details
To filter templates:
To clear the search:
To configure the VM with a basic general configuration, optionally change the following:
To enable remote access to the VM in private cloud:
You can now continue with further configuration or Save and deploy your VM.
To configure IP addresses on your VM, do these steps:
Select the Firewall policies to add. You can add as many firewall policies as necessary, up to the cloud provider's limit. If you can't see the expected policies, you may need to synchronize with your provider or wait for the platform to update provider data
Select the Load balancers to use for the VM.
To enable monitoring and metrics do these steps:
The platform will check your access and schedule or allocate your VM to a hypervisor, public cloud region or Docker. Then the platform will configure it in the virtualization technology, then power it on. Of course, you can also deploy the whole group of VMs by clicking Deploy virtual appliance.
To display all the VMs in a specific virtual datacenter, select the Virtual datacenter.
To move between icon and grid view, click the icon symbol or the grid symbol in the top right hand corner.
Icon view
Grid view
To filter VMs by text in the VM name, enter text in the Search box, with wildcards as required. See Search for VMs and filter the search
Remember that the VM usually has the format ABQ_xxx.
To filter the VMs by other values, such as the VM labels, click the filter button and enter text from the VM details .
To move a VM to another VApp in the same virtual datacenter:
Select the VM
On the VM control panel, click the VM move button
Select the virtual appliance or create a new one, and click Accept
If you have the privilege to restrict VMs, you may also be able to move the VM to a restricted VApp in the same virtual datacenter.
To move a VM to a restricted virtual appliance:
Click the VM move button on the VM control panel
Select the option to Move the VM to a restricted VApp OR select a restricted VApp from the list, or create a new Vapp
Privilege: Manage VM move
To move a deployed VM to another VDC:
The platform will move the VM to the new virtual datacenter. If the move is not successful, the VM will be restored to the original virtual datacenter.
This feature does not move VMs with the following configuration:
If the virtual appliance or VM is deployed, you do not need to undeploy it. You can directly delete a VM that is deployed, even if it is powered on.
If you would like the platform to notify you when an alarm activates, create an Alert for it in Control view.
You can create alarms for built-in VM metrics or scaling group metrics, as well as custom metrics created using the API for VMs, scaling groups, virtual appliances, and virtual datacenters.
To create an alarm:
Privilege: Access alarms section, Manage alarms
Field | Description |
---|---|
Entity type | Select an entity with metrics from the list on the left. |
Entity name | The name of the entity |
Entity label | The label of the entity, which for VMs is shown in the list on the left |
Entity icon | The icon that the platform displays in the UI for VMs and virtual appliances |
Name | Name of the alarm with up to 128 characters. Alarm names must be unique for each metric |
Description | Description of the alarm. Used together with the alarm name and VM name to identify the alarm, for example, when creating an alert |
Metric | Select one of the metrics available for the VM |
Metric unit | The unit of the metric. Read only |
Metric description | The description of the metric. Read only |
Dimension | When the metric has multiple dimensions, optionally select one or more dimensions. For example, if a VM has multiple hard disks, then the disk read bytes metric may have a dimension for each disk |
Last datapoints in period | The number of datapoints that the platform will evaluate the metric during the elapsed time. If you request the evaluation of an alarm more frequently than metric data is collected by the platform or sent by the provider, then the alarm will not activate. We recommend that you create alarms with longer evaluation periods, for example, an average of 10 points over the last hour, so the transmission and collection intervals will not affect the activation of the alarm. |
Statistic | Statistic that the platform will use for evaluating the alarm, which can be: average, maximum, minimum, sum, count, dev |
Formula | Operator that the platform will use for evaluation of the alarm, for example, greater than. Values can be: notequal, greaterthan, greaterthanorequalto, lessthan, lessthanorequalto, trendup, trenddown |
Threshold | Value that the platform will evaluate the alarm against, if appropriate |
The platform will create the alarm for the metric. If you would like the platform to notify you when an alarm is triggered, create an Alert.
Troubleshooting alarms that do not trigger
For a scaling group, an alarm on a metric of the VM in the base workload will receive input from the metrics of all VMs in the scaling group. This means the base workload and/or the clone VMs. So an alarm for a scaling group can activate, even if the base workload is not deployed.
For API documentation about alarms on an entity, see the API documentation for the entity's resource. For example, for VMs, see VirtualMachinesResource.
When you edit an alarm, there is an extra field, "Active", that shows if the alarm is activated or not.
After you save the alarm, the platform will start to evaluate it again with new data when it receives the next set of metrics datapoints.
You can also remove an alarm from an alert.
Privilege: Access alarms section, Manage alarms, Manage alerts
To delete an alarm:
To remove an alarm from an alert:
Go to Control → Alerts → edit alert
Select the alarm, click the 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.
Alerts are 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.
Privilege: Access alerts section, Manage alerts
Before you begin:
To create an alert:
Enter the alert details and assign alarms as described below
Click Save
Field | Description |
---|---|
Name | Name of the alert. The name can contain up to 128 characters |
Description | Describe the alert |
Muted | Select this checkbox to disable action when the alert is activated |
List of email addresses to notify when the alert activates. Click Add email to save an address |
Click the + add button to assign alarms to the alert.
You must assign at least one alarm to be able to save the alert. Select an existing alarm, or create a new alarm, and assign it to the alert. Repeat for the required alarms
You can filter the Alarms list by Metric and also if the alarm is Active or not.
You can also remove an alarm from an alert.
Privilege: Access alarms section, Manage alarms, Manage alerts
To delete an alarm:
To remove an alarm from an alert:
Go to Control → Alerts → edit alert
Select the alarm, click the 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.
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).
Privilege: Manage scaling groups, Manage workflow for scaling groups
To use autoscaling do these steps:
To create a scaling group:
Field | Description |
---|---|
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. |
Scaling rules
Field | Description |
---|---|
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 configure automatic scaling actions:
The platform will automatically create the alarms, alerts, and action plan to automatically scale in or out according to your thresholds.
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.
You can also display all the elements created for the automatic scaling action in the relevant sections of the UI, such as the Alarms tab, and the Control view.
To move a scaling group to a restricted virtual appliance, do these steps:
To delete a scaling group:
API Documentation
For the Abiquo API documentation of this feature, see Abiquo API Resources and the page for this resource ScalingGroupsResource.
To enable more control over cloud operations, users can create action plans that will automatically run tasks on VMs and scaling groups, and to run general tasks.
Action plans are an important automation functionality on 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 or built-in metrics. Each VM or scaling group can have multiple action plans.
To create an action plan:
Put the actions in run order using the arrow buttons. Delete actions as required using the trash can button to the left of the action name.
Field | Description |
---|---|
Name | The name of the action plan |
Description | A description of the action plan |
Actions
Action Notes and Parameters 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 |
|
Send webhook | See webhook parameters 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 |
When you create actions on VMs also consider the following constraints.
For the API, note that 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
To run the action plan automatically, go to the Triggers tab and create an alert or schedule trigger.
Abiquo recommends that you run an action plan manually to test it before you create a trigger to run it automatically
To run your action plan based on metrics, select an existing alert with these steps:
To run your action plan automatically at selected dates and times, create a schedule trigger with these steps:
If you delete an action plan, Abiquo will also delete the schedule associated with that action plan.
To add a VM bootstrap configuration or script in public cloud:
This functionality is available through the API. The platform stores variables in the VirtualMachine "variables" attribute, which is a dictionary of keys and values. See Update a virtual machine in VirtualMachinesResource
To add VM variables:
Go to Virtual datacenters → edit a VM that is not deployed → Variables
Enter each Key and Value
The length of these can be up to 255 characters each
Click Add
To delete a variable click the trash can symbol beside the Key. To edit the Value of a variable, click the pencil edit button beside the Value
To apply changes to variables, and other changes to the VM, click Save
Chef is an infrastructure automation product that uses configuration recipes. You can use Abiquo Chef Integration to deploy a VM that will then configure itself using Chef recipes and roles. In datacenters, the Abiquo Chef integration works with Cloud-init or Cloud-base-init, so you will need compatible templates and you will need to select this guest setup option.
The Chef tab is enabled if the enterprise is Chef-enabled and the VM template is marked for Cloud-init support.
Before you deploy the VM, you can select from the available roles and recipes. By default, you can select roles. Mark the "Select individual components" checkbox to select individual recipes too. The platform will add your selection to the Virtual Appliance's runlist in order of selection. When you deploy the VM, it will download the roles and recipes, and run them in order.
To change the order of the runlist, click on the pencil Edit button beside a role or recipe, then enter the new order number, then click ok.
If you change the runlist after deploy, Abiquo will update the Chef server, and your Chef-client recipe can obtain these changes from the Chef server.
Related links: