Aria Automation Deployment Scale Out

Jan 25, 2023 vRA8 Scaleout
Share on:

How to scale out a VM deployment in vRA8

Table of Contents

Introduction

The number of virtual machines in a vRA7 deployment could be easily increased by the built in Scale Out action. Unfortunately this functionality is still missing from Aria Automation (at least up to version 8.10).

In this post I present a custom Day 2 action that can substitute for the old deployment action.

Scaling out by deployment update (previous approach)

The number of VMs in a deployment can be defined by the count property. To add a new VM we can run the Update deployment action and change the inputs. Here is a simple cloud template for demonstration purposes:

 1formatVersion: 1
 2inputs:
 3  count:
 4    type: integer
 5    default: 1
 6  zone:
 7    type: string
 8    enum:
 9      - lan
10      - dmz
11resources:
12  photon:
13    type: Cloud.vSphere.Machine
14    properties:
15      count: ${input.count}
16      image: photon
17      flavor: small
18      templateprop: value2
19      zone: ${input.zone}
20      tags:
21        - key: zone
22          value: ${input.zone}
23      networks:
24        - network: ${resource.net0.id}
25          assignment: static
26  net0:
27    type: Cloud.vSphere.Network
28    properties:
29      networkType: existing
30      constraints:
31        - tag: zone:${input.zone}

Here is the Update form:


The problem is that the user can change any input, not only add new machines. In our case, changing the Zone input would reconfigure VM networking, which is an undesired side-effect. To prevent that, we'd need to create a custom Day 2 action and hide this input, then calling the Update action via REST API. Not very easy to make.

If we add any disks to an existing VM by the Add Disk action, we'll face additional problems. Let's see what happens to this deployment:


The Update Plan writes that a new VM is to be added, and our disk is to be deleted.


This sounds bad. In vRA 8.5, the Update action actually did delete the extra disk(s) not present on the cloud template. This is certainly not what we want. In vRA 8.10 the situation is improved, but still not nice:


The automation tries to delete the disk, but since it is attached to a VM, it fails, thus the whole Update action fails. The new virtual machine is created, but the user sees an error that should not happen:
"Only disk with status AVAILABLE can be deleted, as it is not attached by any VM."


When we try to delete the deployment, we'll see the same error message again, and our extra disk is not deleted:


Scaling out by IaaS API

We can use Aria Automation REST API to initiate new VM creation:


For vRA REST API I prefer Orchestrator Plug-in for vRealize Automation. It is easy to use and no need to deal with authentication tokens.

We create a service user apiuser with Cloud Assembly Administrator role (required for IaaS API):

Then create a vRA endpoint within vRO:

Then create the Scale Out workflow with a single count input of type number:


There is only one JavaScript scriptable task in it:

 1System.log("Requesting " + count + " machines.")
 2
 3var resourceProperties = System.getContext().getParameter("__metadata_resourceProperties");
 4System.debug(resourceProperties);
 5
 6var vraHost = VraHostManager.findHostsByType("vra-onprem").filter(
 7    function (host) {
 8        return host.name == 'admin'  // find the vRA endpoint to use
 9    }
10)[0];
11
12var interface = VraEntitiesFinder.getMachineNetworkInterfaces(vraHost, resourceProperties.resourceId)[0];
13System.debug(interface);
14var networkId = interface.toString().match(/\/iaas\/api\/networks\/(\S+)/)[1]; // extract network Id
15System.log("IaaS Network Id: " + networkId);
16
17var vraMachine = VraEntitiesFinder.getMachine(vraHost, resourceProperties.resourceId);
18System.log(vraMachine.name + " found.");
19
20var machineService = vraHost.createInfrastructureClient().createMachineService();
21var machineSpec = new VraMachineSpecification();
22
23machineSpec.name = resourceProperties.name;
24machineSpec.machineCount = count;
25machineSpec.deploymentId = resourceProperties.__deployment_id;
26machineSpec.projectId = resourceProperties.project;
27machineSpec.image = resourceProperties.image;
28machineSpec.flavor = resourceProperties.flavor;
29
30var nicAttachmentSpecification = new VraNetworkInterfaceSpecification();
31nicAttachmentSpecification.name = "net0";
32nicAttachmentSpecification.networkId = networkId;
33nicAttachmentSpecification.addAddressesItem(resourceProperties.address); // for choosing right subnet
34
35machineSpec.addNicsItem(nicAttachmentSpecification);
36
37for each(tag in vraMachine.tags) {  // copy tags
38    machineSpec.addTagsItem(tag);
39}
40
41var machine = machineService.createMachine(machineSpec);
42System.log("Create machine request has been successfully completed with machine id " + machine.id)

IaaS API - Create machine

Some code is copied from the sample workflow in /Library/vRealize Automation 8.x and Cloud Services/Infrastructure/Machines/Create Machine

We need to collect the following information to create the new VM:

  • VM name (this is only a prefix)
  • number of VMs to create
  • image
  • flavor
  • network Id to attach the VM
  • deployment Id to place the new VM into

The System context contains the current VM's attributes, so we can collect the image name, flavor name and deployment Id easily. For the network Id we call another IaaS API /iaas/api/machines/<vmid>/network-interfaces by using VraEntitiesFinder.getMachineNetworkInterfaces().

By VraEntitiesFinder.getMachine() we collect the existing VM's tags and pass them to machineService.createMachine(), so the new VM will have the same tags.

W.r.t. IP address allocation, the new VM gets its IP address from the same IPAM solution (phpIPAM in our case). We need to specify some IP address in the same subnet, so we simply pass the existing VM's address (no collision will happen, just a required input to make the allocation logic happy).

Day 2 action

Let's define the Day 2 action:


The input form is simple:


Even with an added disk, we do not see errors when scaling out:


The resulting deployment topology, the new VM has the same tags:


... and we can delete the deployment without problems:


Summary

We need to make sure the Scale Out workflow matches our cloud template. If we have custom properties, additional networks, etc. then the submitted VraMachineSpecification must reflect that. In that sense the solution is not a universal replacement of vRA7 Scale Out functionality, but eliminates issues we had with the previous implementation based on deployment Update.