Abiquo Cloud Broker Integrations and Deployment

Cloud Broker user interface

The user interface of the Cloud Broker (Broker) requires a screen resolution of at least 1024 x 768 for productive work. It is based on HTML5 and you must use browsers that support these HTML5 features:

• Forms block

• Drag and drop

The following browsers are compatible with the user interface.

For mobile devices, check if your browser is compatible with HTML5 using a test such as https://html5test.com/

Cloud Broker concepts and equivalence

Cloud Broker virtual datacenters

Through the Broker you will access 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. For example, the Broker’s concept of the VDC is equivalent to:

• VPC in AWS (Amazon). 
• vApp In vCloud Director (vCloud). 
• Virtual Network and its associated resources in ARM Compute (Azure)

Virtual appliances

Within its VDCs, the Broker 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 do things such as:

• Deploy the VMs with one click
• View VMs' metrics together
• Create custom metrics for the VApp  

You can move VMs from one VApp to another.

A VApp is not equivalent to any specific concept in vCloud or public cloud.

Networks

In vCloud, the Broker supports the onboarding of the following networks:

• External networks outside the OrgVDC but connected to the Edge are external networks in the Broker, for use by load balancers but not VM vNICs

• External networks outside the OrgVDC with a direct connection to OrgVDC as OrgVDCNetwork are external networks

• Org networks inside the Org VDC and routed through the Edge are external networks

• Isolated Org networks are external networks, for use by VM vNICs but not load balancers

• vApp networks are private networks

Storage

All providers support auxiliary disks for VMs.

vCloud

• In vCloud, when you work with a multi-disk template, the Broker will display only one disk with the sum of the sizes of all the disks. It will also display only one disk when you create a VM from the template. When you deploy the VM, the Broker will correctly detect the disks and display them on the VM details Storage panel.
• You can add and remove hard disks in the Broker, with hot-reconfigure for SCSI disks. If you modify the disks in the provider, the Broker will detect the changes. 
• When you create an instance template from a multi-disk VM, the template will be correctly created in vCloud with all of the disks, and you can create and deploy a VM from this template as for other vCloud templates.

Amazon

• In Amazon, you can work with volumes that are EBS disks. Users can onboard and create volumes, and attach them to VMs as auxiliary disks. The volumes must be in the same availability zone as the VM network. 
• When you onboard disks, the platform will make them available to users that can access All virtual datacenters in the tenant 
• After users detach auxiliary disks from VMs, the synchronization process will make them available in the virtual datacenter. Users can move disks between virtual datacenters and release them to the region. When users undeploy or delete a VM, the synchronization process will make auxiliary disks available in the virtual datacenter. 
• If you onboard a VM with Delete on termination disks. When you undeploy or delete the VM, the platform will destroy these disks. When you detach the disks from the deployed VM, the platform will synchronize them as volumes in the virtual datacenter. 
• In AWS, users can create an instance template with a copy of the selected VM disks. 

  When you create a VM from an instance template, the platform will display one disk only, with the total size of all disks. After you deploy the VM, the platform will update the additional disks.

Azure

• In Azure, you can work with volumes that are Managed Disks. Users can onboard and create volumes, and attach them to VMs. 
• When you onboard disks, the platform will make them available to users that can access All virtual datacenters in the tenant
• After users detach volumes from VMs or delete VMs, the synchronization process will make the volumes available in the public cloud region. Users can move volumes between virtual datacenters and release them to the region. 
• In Azure the VM instance functionality to take a snapshot of a VM has been disabled pending further development.

Onboarding and creating resources

Your existing resources will be onboarded for you to manage with the Broker, and you can create new resources using the Broker’s web interface or the API. We recommend that you make all changes in the Broker; however, it is often possible to synchronize compatible changes made outside the Broker.

When you synchronize a VDC, the Broker will ensure that the resources in the Broker and the provider are the same.

• It will delete entities in the Broker that were deleted already in the provider
• However, it will maintain resources that are part of the configuration of undeployed VMs in the Broker
  • For example, if a user has an undeployed VM with IPs and a load balancer, then after the synchronization, these resources are attached to the VM in the Broker only
  • Warning: These resources are "free" in the provider. Users working directly in the provider could assign these resources to other VMs, which will cause a conflict and error at deploy time

You can also synchronize resources such as networks, public IPs, firewalls, volumes, and load balancers.

Monitoring and Alarms

The Broker collects and displays the metrics that the provider or hypervisor sends.

• If you request the evaluation of an alarm more frequently than metric data is collected or sent, the alarm will not activate. 
• The minimum recommended alarm evaluation period is 2 minutes.
• The Broker collects metrics data every 2 minutes by default, but this can be configured with the vsm.vmmetrics.collectfrequency property for each provider or hypervisor
• The sending and collection intervals will not affect the activation of alarms with longer evaluation periods, for example, "an average of 10 points over the last hour"
• Providers send metrics at different intervals, for example:
  • Amazon Basic monitoring, every 5 minutes
  • Amazon Advanced monitoring, every 1 minute 
  • vCloud, on consultation

Resource limits

Cloud providers may have resource limits, such as a limit on the number of public IPs that each account can use. As multiple users may work with the same account in the Broker, your administrator may also set limits in the Broker to ensure that the resources are correctly shared  with sufficient resources available to all users. Of course, you may able to bypass the Broker’s limits by working directly in a cloud provider. However, after you onboard or synchronize resources, the Broker may block deploy, reconfigure, or undeploy actions on these resources.

Naming Resources

Broker identifiers for VMs

The Broker identifies the VMs it creates with a UUID (universally unique identifier) and a VM Name (generally ABQ-uuid).

When the Broker onboards a virtual datacenter, it will use the following:

• Name = urn:vcloud:vm:xxx-xxx (Internal identifier in vCloud)
• Label = myVm (Name of the VM in the provider).

When the Broker creates a VM in the cloud provider, it assigns the VM Name to the VM. This is the Broker’s identifier for the VM

• In Amazon, the Broker assigns the VM Name to the virtualMachine tag of the VM.

• In vCloud, the Broker assigns the VM Name to the Name attribute of the VM. The Broker assigns the Abiquo UUID to the VM metadata. When you perform a "Copy to" or "Move to Catalog"  action directly in vCloud, it will copy the metadata. You must remove this metadata to prevent multiple VMs with the same ID. In this situation, the plugin will disregard one of the VMs.

• In Azure, the Broker assigns the VM Name to the Name attribute of the VM in lower-case format (abq-uuid). It truncates the name to the provider’s standard for Windows VMs of 15 characters in length

If you change the Broker’s identifier in the cloud provider, you will not be able to manage the VM with the Broker again.

User labels for VMs

The Broker enables you to set a Label that is a user-friendly name to identify your VMs.

• In Amazon, the Broker assigns the label to the Name tag of the VM

• Planned improvement: The VM Label will be added in all cloud providers. For VMs deployed in Amazon and vCloud, you will be able to change the label in the Broker when you reconfigure the VM.

Broker virtual datacenter names

The Broker onboards and synchronizes virtual datacenter names as follows:

• For Amazon, the Broker uses the VPC ''name'' tag
• For vCloud, the Broker uses the Name of the vCloud vApp

Broker virtual appliances and names

If the Broker onboards each of the VMs in a vCloud VDC into its own virtual appliance in the Broker, then the Broker will use the VM Label as the name of the virtual appliance. 

• To onboard all VMs into a single virtual appliance for a tenant, set the “sync.singlevapp” enterprise property to “true” for the tenant. 
• To configure the name of the virtual appliance, set the “sync.singlevapp.name” enterprise property to the desired name.

Load balancer names

When creating a load balancer you can enter any name in the Broker but the following providers have restrictions:

• Amazon will only accept the following characters: A-Z, a-z, 0-9 and "-".  
  • After you create the load balancer in Amazon, it will not allow you to change the name.
• Azure will not accept names with white space.

Making changes to deployed VMs

The Broker enables you to make changes to deployed VMs subject to the limitations imposed by the cloud providers themselves.

• In Amazon, power off to change hardware profile, firewalls, and load balancers. Amazon does not support changes to NICs
• In Azure,  power off the VM to edit VMs to attach and detach firewalls and load balancers, and change NICs and hardware profiles. 
• In vCloud, select the hot configure options for the VM template in the Broker if the operating system supports it. Note that you can use this feature without redeploying your VMs. If hot reconfigure is not supported, power off the VM to reconfigure it.

Removing tenants and resources

To remove a tenant, first remove its VDCs and any other resources, such as firewalls, from the Broker.

• When you remove a VDC in the Broker, you can choose if you also want to remove it in the provider.
• If you remove the VDC in the Broker only, the Broker will automatically remove all the associated resources in the Broker.
• To remove a VDC in the provider, first remove the resources, such as: VMs, public IPs, firewalls, and load balancers. During the next synchronization, the broker will delete public IPs in a VDC that are not in use by VMs

Note: If a tenant does not have valid credentials in the Broker, when you delete resources, they will remain unchanged in the provider.

If you remove the VDC’s equivalent in the cloud provider’s native interface, the broker will display the resource name in light gray to indicate that the user cannot work with the resource. You  should manually remove the VDC in the Broker.

Provider Support

We are constantly extending the platform to provide new functionality both for individual providers and the Broker itself. The sections below review platform and provider behavior, planned improvements, and known issues for each cloud provider environment.

vCloud Director Integration

The cloud broker is integrated with VMware vCloud Director to enable users to work with virtual resources with VDCs based on vCloud vApps.

• Features: https://wiki.abiquo.com/display/doc/vCloud+Director

The cloud broker can use a vCloud Director administrator account or an organization administrator account to connect to a vCloud Director virtual datacenter. Each Abiquo enterprise should have its own organization administrator account. 

• Credentials: https://wiki.abiquo.com/display/doc/vCloud+Director

The cloud broker can onboard organization networks as external networks and manage IPs. Users can also manage virtual appliance networks.

Hints and Tips for vCloud Director

 The Broker onboards vApps from vCloud as VDCs where you can create VMs using templates from the vCloud template repository.

 The Broker onboards and synchronizes private and external networks. The Broker does not onboard or manage static routes or NAT. Create these configurations directly in vCloud.

 When you onboard a VM, the Broker creates a placeholder template. In the Apps library, this template will be marked as Unavailable because it cannot be used to create a VM. Before you undeploy the VM you MUST create an Instance template, which will clone the VM disks. Otherwise, you will not be able to recreate the VM. When you undeploy an onboarded VM, the Broker will destroy the VM and the placeholder template.

After you create an instance template of an onboarded VM, the platform will update the VM template in the Apps library to point to this template and put it in the Available state. The Broker will save a multi-disk template correctly to the vCloud registry, but it will also appear to have a single disk in the Broker. If you undeploy a VM with a saved instance template, when you deploy the VM again, the platform will use the saved instance template. Remember to check your configuration

When the platform onboards a template from vCloud, it caches the template details in the Apps library as a template, and points to the vCloud template. When you modify the template in the Broker, this sets the default configuration of VMs deployed in the Broker using the template. It does not modify the vCloud template. After you create a VM, you can change its resources by editing the VM configuration.

 If you deploy a VM and then add or remove disks, when you redeploy the VM, the platform will use the template disks.

Users can modify cores per socket values in their VMs. The cores per socket must always be a divisor of the CPU.

 You can onboard existing Edge firewalls from vCloud as Classic firewalls in the Broker.  Do not create security groups for VMs because they are not supported in the Broker environment.

 In VDCs in vCloud in the Broker, tenant private networks are isolated by default because the “vcd.parentnetwork” property is set to “none” in the platform configuration. It is possible to configure a connection to the outside world via the orgVdc Edge gateway by setting the enterprise property “vcd.parentnetwork” for a tenant to “edge-uplink”, which is the routed internal network, or to the name of another existing orgNetwork. 

 When you remove a virtual datacenter from vCloud and it still exists in the Broker, when synchronizing, an error is displayed that the resource no longer exists. The user can then manually delete the VDC from the broker.

 In vCloud when you create an external network that can support load balancers (direct or routed, with a connection to an Edge), you must create a static IP pool with the number of IP addresses to reserve for load balancers. The Broker uses a configuration property to set the this number. If you do not create the static IP pool or there are not enough addresses in the connected network, the Broker’s onboarding process will ignore the network. The number of static IPs reserved for load balancers is also a limit on the number of load balancers that users can create in a network.

 In vCloud the Broker supports the following ethernet drivers: VMXNET3, PCNET32 (in vCloud this is VLANCE), and E1000. The Broker will use the configured VMXNET3 driver when deploying or onboarding a VM with an unsupported ethernet driver.

 When you create a load balancer for vCloud, you must select a “public address”, which is an address on an external network (connected to the Edge, meaning external to the OrgVDC or external routed networks). The Broker does not support the use of private subnets for load balancers in vCloud because vCloud cannot use isolated external networks or private networks when creating load balancers. The Broker enables you to change routing rules after you create them. Limitation: The Broker does not support NSX-Edge Compact or fenced vApps.

 To load balance multiple protocols and ports, you can use multiple load balancers to the same IP address but each with a different port. The algorithms vCloud supports are ROUND_ROBIN, IP_HASH, LEAST_CONN, and URI. For routing rules for incoming traffic, vCloud accepts HTTP, HTTPS, and TCP. For HTTP routing rules, vCloud supports HTTP or TCP health checks. For HTTPS rules, it supports SSL or TCP. For TCP rules, it only supports TCP.

When importing templates into the platform, the private checkbox filters to display templates in the same organization, and the public checkbox filters to display templates in other organizations.

Currently specs do not support external networks, but in vCloud, when an external network is listed in the spec validation process, you can select it, then continue with the process. The platform will create the virtual appliance correctly. Remember that you will need to ensure that there are enough external IP addresses available to use in the new virtual appliance

 Planned improvements for vCloud

• On VMs with multiple NICs, enable the user to select NICs to add the LB

• Prevent changes in NIC order on a VM (in cloud Broker only) when you synchronize networks

Amazon Integration

The cloud broker is integrated with Amazon Web Services EC2 to enable users to work in Amazon public cloud regions with VPCs. 

• Features: https://wiki.abiquo.com/display/doc/AWS+features+table

Each Abiquo public cloud region corresponds to a single region in Amazon EC2. Each Abiquo enterprise using the Amazon public cloud region should have its own Amazon account. Abiquo will validate your Amazon credentials (Access Key ID and Secret Access Key) with Amazon. Each tenant enterprise may register one set of credentials for the enterprise's Amazon account.

• Credentials: https://wiki.abiquo.com/display/doc/Obtain+AWS+credentials

Abiquo creates a Virtual Private Cloud (VPC) for each Abiquo virtual datacenter. The VPCs have NAT support with a public subnet, and VMs on different subnets can be connected to the same load balancer. Abiquo supports the AWS gateway address as the first address in the network. Users can attach Elastic IPs to VMs with a connection to the public subnet. Abiquo uses VPC networking Scenario 2 as described in the AWS documentation http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Scenario2.html.

Hints and Tips for Amazon

 When you create a VDC, the Broker configures VPC networking. Under this configuration, users must attach Elastic IPs to VMs with a connection to the public subnet. And by default, VMs in private networks will have internet access through the public subnet. Amazon uses an Elastic IP for the NAT gateway. When creating the NAT gateway of a VPC, the Broker will reuse elastic IPs that are not assigned to a VDC.

 Amazon reserves five IP addresses in your private networks. It reserves the first four IP addresses and the last IP address of the VPC private connect network. These IP addresses are not displayed or used by the Broker. Therefore, the first available IP address in a network that is defined to start with address 0, will be address 5, and the gateway address will be address 1.

 The Broker enables you to attach the number of IP addresses supported by the Amazon hardware profile (instance type). See http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI

 You cannot deploy an AMI from the AWS marketplace because the Broker cannot display the EULA for you to accept. However, you can deploy in the Amazon cloud native interface and onboard in the Broker. If you import an AMI from the AWS marketplace, the Broker will display a warning message.

 If you need to manage Elastic IPs directly in Amazon, synchronize them to update the Broker with the changes or you may see unexpected results.

 When onboarding a VPC, the Broker will detect a public subnet by the presence of a custom route table and NAT gateway. The Broker can also import other network configurations, such as VPCs without a NAT gateway. Users with bespoke configurations should check the results of onboarding.

 The platform will onboard and synchronize private and public IP addresses even if they are not in use by VMs, and it will indicate the IP addresses in use by provider entities by displaying provider identifiers.

 The Broker will import VM templates. If the VM template cannot be found, the VM will be created in the platform with no registered template. In this case, to save a copy of your VM disk as a template (so you can recreate the VM after undeploying), make a snapshot (instance) template of the VM.

 Before deleting VDCs, always check which is the default VPC in your region because it may be inconvenient to delete this VPC.

 Amazon load balancers are created for VDC networks (VPC subnets). The Broker will not create a load balancer in Amazon until it is assigned to at least one subnet. You can have VMs in different subnets attached to the same load balancer. For high availability, create private networks (subnets) in different availability zones in your VDC.

 When you modify a load balancer in the Broker, you can add new subnets and delete subnets.

After a load balancer is created in Amazon, the provider will not allow you to change the description.

 When you are creating a load balancer for Amazon, and you would like to add a firewall, if the firewall does not display, 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 create a load balancer in the Broker only, do not supply a subnet. To later create it in the provider, select a subnet. If you delete the load balancer directly in the cloud provider’s interface, it will also remain in the Broker only. You can then later assign the load balancer to another VDC. The cloud Broker never stores SSL certificates, so you cannot create a routing rule for a secure connection in a Broker-only load balancer.

 A load balancer in Amazon will assign a previously unhealthy machine a healthy status after a number of successful health checks. The required number of health checks is configured for the Broker.

 For Amazon load balancers, you can add a new certificate or an existing one registered in Amazon with an ARN. Remember that to list and upload SSL server certificates to IAM your Amazon user credentials will require IAM privileges to manage IAM.

 Amazon only supports the ROUND_ROBIN protocol. To manage multiple incoming connections, use one load balancer with multiple incoming connections to different ports. You can only create one routing rule per protocol and path. You must create at least one routing rule and there must always be at least one routing rule in the load balancer. For incoming traffic, the routing rule protocols can be HTTP, HTTPS, or TCP, and the ports can be 80, 443, or 1024-65535 inclusive.

 Amazon will only allow you to create one health check per load balancer. If you do not create a health check, Amazon will create a default TCP check to one of the ports specified in a routing rule. The health check name will be in the format "PROTOCOL:port", for example, "TCP:80".

Azure Integration

The cloud broker is integrated with Microsoft Azure Resource Manager (ARM) compute to enable users to work with virtual resources in VDCs based on Azure virtual networks.

• Features: https://wiki.abiquo.com/display/doc/Azure+features+table

Each Abiquo public cloud region corresponds to a single Region in Azure. Each Abiquo enterprise using the Azure public cloud region should have its own Azure account or be a customer of an Azure reseller CSP. Each enterprise must have an Azure subscription and from there they must create an ARM application and add credentials of the application to Abiquo. 

• Credentials: https://wiki.abiquo.com/display/doc/Obtain+Azure+ARM+credentials

Hints and Tips for Azure

 In Azure a VDC is a virtual network and its associated resources. The Broker will map a private network to a subnet in the VDC network.

 For Azure, users can add public IP addresses to their VDCs and VMs, as in Amazon. Azure uses the first public IP address as the primary IP for remote access. The Broker will onboard and synchronize dynamic public IPs. 

 The Abiquo instance functionality was disabled in Azure in Abiquo 4.7.0 pending further development.

 Azure only supports one firewall policy per VM. When you edit a firewall, Azure does not allow you to change the name, but you can modify the description, which is also stored as a tag attached to the security group.

 Azure does not allow you to attach a VM with a Basic hardware profile to a load balancer. Azure does not support premium storage for some hardware profiles. The Broker does not enable you to configure VMs with premium storage.

 The load balancing algorithms supported by Azure are DEFAULT, SOURCEIP, and SOURCEIPPROTOCOL. The load balancer must have one and only one public OR private address. The load balancer can only be attached to one subnet, which is mandatory for private addresses. One load balancer can have multiple incoming connections to different ports.

You must create at least one routing rule. There must always be at least one routing rule in the load balancer in the Broker. You can only create one routing rule per incoming port and one rule per outgoing port (i.e. two rules cannot receive traffic on the same port or route it to the same port). The Broker does not onboard or synchronize Azure load balancers without routing rules, because it does not support them. You can create routing rules for connections over TCP or UDP, and the IN and OUT ports of the rule must be the same. 

In the Broker you can only configure one health check for an Azure load balancer, for protocols TCP or HTTP on a port between 1 and 65535. The health check interval must be between 5 and 2147483646.

 The Broker enables users to filter Azure templates by publisher

 When you undeploy in the Broker, it completely removes the VM and the associated resources. If you undeploy a VM in the Azure portal, you should check for orphan network interfaces because you may need to remove them before you redeploy the VM.

 Limitations for Azure

• The Broker does not support load balancers with SSL or firewalls (NSG)

• The Broker adds all the VMs in a VDC to a single Availability Set to ensure that they can all access the Basic load balancers in the VDC. This means that Azure assigns the VMs to a hardware cluster with some limitations, including a limited set of hardware profiles. If the user tries to deploy with an unsupported hardware profile, the Broker will display an error message listing the supported profiles. We plan to improve this functionality in the short term.

Reports

The following reports are currently available in the Abiquo Cloud Broker Platform.  

Audit and Compliance Report for Administrators

• User Audit Report 
  

Planning Report for Administrators

• Resource Allocation Limits by Enterprise Report 
  

User Reports

• Enterprise Activity Report

• Inventory Report

• Resource Usage By Enterprise Report

How to deploy a basic architecture in the Cloud Broker

This document describes how to deploy a basic web architecture in the Cloud Broker. First you should create the networks directly in vCloud and then you should configure and  deploy the servers in the Broker.

1. In vCloud, create the following networks:

   1. Net1: external network connected to the external interface of the Edge, as if it were a public network (Direct network) - Created by Provider during onboarding

   2. Net2: internal network connected to the internal interface of the Edge, to protect the 2 front-end servers (FE1 and FE2) with the firewall. (Routed network) - Created by Provider during onboarding or by the customer

   3. Net3: internal network with FE1, FE2 and 1 back-end server (BE). (Isolated network). This network is not connected to the Edge, so the connections to the VM will not be load balanced or protected by the firewall- Created by the customer

2. In the Broker, create a virtual datacenter

   1. Go to Cloud → Virtual datacenters list

   2. Click + and select Create virtual datacenter

   3. Enter the Name and select the Location, which is the public cloud region (vCloud Org VDC name)
      

3. Import the external networks, load balancers, and classic firewalls

   1. Go to Cloud → select the Virtual datacenter →  click the round arrow Refresh button
      

4. Create the web front-end VMs

   1. Go to Cloud → Virtual appliances → open the Virtual appliance by clicking its name

   2. Drag and drop or double-click two templates to create front-end servers

   3. Edit each VM

      1. Enter the name and other details as required

      2. Go to Network

         • Drag and drop to add the first IP address (NIC 0) on the routed network (net2)

         • Add another IP address (NIC 1)  on the isolated network (net3)
           

5. Create the back-end VM

   1. Edit the VM and configure a NIC on the isolated network (net3)

   2. Configure auxiliary hard disks as required

6. Configure a load balancer in the public cloud region

   1. Go to Virtual datacenters (Click the Back to VDC button at the top left)

   2. Select All Virtual datacenters → Network → Load balancers → select the public cloud region

   3. Click + and create a load balancer

      1. Select an Automatically created private IP address. This will be an address on the external routed network - net1

      2. Select net1 as the subnet

         

      3. Create a routing rule for HTTPS-443

      4. Create a health check with SSL

      5. Attach the front-end servers.

      6. Make a note of the load balancer IP address for configuring the firewall

7. Configure the firewalls from the public cloud region

1. Go to Virtual datacenters → select All → Network → Classic firewalls →  select a location.

2. At the top of the Classic firewalls list, click the double-arrow button to onboard firewalls.

3. Select the firewall and click the round arrows synchronize button next to the firewall name

4. Create a firewall rule allowing only HTTPS-443  to the load balancer IP address from any IP address
   

8. Create a scaling group for each VM

   1. Select the VM and from the options menu → select Define scaling group

   2. Enter the Name and Default cooldown for example, 900 seconds for a Windows VM

   3. Set a Minimum of 2 VMs and a Maximum of 4 VMs

   4. Create Scaling rules for default scaling, for example, to add 1 VM and remove 1 VM

   5. Click Save

9. Configure the autoscaling action

   1. Click Show more to configure the scaling thresholds

      1. Use the default of All data points and enter 15 minutes

      2. Enter a threshold of 30% - 70%, to scale down when below 30% and to scale up when above 70%
   2. Click Add to save

10. To enable scaling to start, click the cog icon to leave maintenance mode. 

The Broker will create the scaling group, and automatically create the alarms, alerts, and action plans for autoscaling. The Broker will automatically deploy VMs to create the minimum number in each scaling group.

• To display the scaling actions created automatically by the Broker, put the scaling group into maintenance mode, edit it, and go to Autoscaling actions.

When any of the VMs reach the maximum CPU threshold, the Broker will automatically scale out.