Enabling dynamic site selection in the Private Cloud with vRealize Automation

20161114-1In HobbitCloud we have the ability to deploy vRealize Automation workloads to multiple sites. This enables us to leverage different technologies like NSX for vSphere and NSX-T, without having to mix both in the same site. It also means that if we have to scale up workloads for certain projects, we can utilise different clusters.

However there’s also an additional benefit to having multiple sites, and that’s to enable active/active deployments.

Most HobbitCloud tenants don’t care where their workloads are provisioned. They just want to request resources and access them wherever they land. Occasionally there’s a need to specify a site, for example to ensure data stays within a certain geographical boundary – but this is the exception to the rule.

For example, if a customer has two datacentres and wants to ensure both sites are used in an active/active manner, how can they achieve this without manual intervention?

The Scenario

We will assume the following customer scenario:

  • 2 x datacentres (AZ1 / AZ2)
  • 2 x workload (compute) clusters (one at each site)
  • 2 x reservation for each business group (also one per site)
  • 2 x NSX Universal Logical Switches

The aim of this solution is to calculate which site has the least memory utilization and deploy to that site.

Configure the Infrastructure

The first thing we need to do is configure our sites. To do this, we first need to edit the file DataCenterLocations.xml, which can usually be found in C:\Program Files (x86)\VMware\vCAC\Server\Website\XmlData on all IaaS Web Manager hosts.

In our example we have gone with non-geographical names:

<?xml version="1.0" encoding="utf-8" ?>
<CustomDataType>
  <Data Name="AZ1" Description="Availability Zone 1"/>
  <Data Name="AZ2" Description="Availability Zone 2"/>
</CustomDataType>

This needs to be the same on all Web Managers.

Next we need to edit our compute resource in vRA to pair an Availability Zone with a cluster:

Choosing the Site with vRO

In vRO, create an action called chooseAvailabiltyZone and set the return type to Array/String. Paste in the following text:

//Set variables
var tmpMem = null;
var lowestMem = 10000000;
var availabilityZone;

//Function to calculate percentage
function percentage(partialValue, totalValue) {
	return (100 * partialValue) / totalValue;
}

//Get all clusters from the vCenter plugin
var allComputeClusters = VcPlugin.getAllClusterComputeResources();  
for each (var cluster in allComputeClusters) {
	var usage = cluster.resourceUsage;
	System.log("Cluster name is: " + cluster.name);
	
	//Calculate the free storage. Halt and catch fire if over 65%
	var usedStorage = percentage(usage.storageUsedMB, usage.storageCapacityMB);
	if (usedStorage > 65){
		break;
	}
	
	//Log the math for demo purposes
	tmpMem = null;
	tmpMem = usage.memUsedMB;	
	System.log("tmpMem: " + tmpMem);
	System.log("lowestMem: " + lowestMem);
	
	//Cycle through, keeping the lowest mem. Deploy to this site.
	if (tmpMem < lowestMem) {
		lowestMem = tmpMem;
		availabilityZone = cluster.name;
		System.log("The availability zone is: " + availabilityZone);
	}
}

//Correlate clusters to sites
switch(availabilityZone){
	case "HC-COMPUTE-01":
		return ["AZ1"];
		break;
	case "HC-COMPUTE-02":
		return ["AZ2"];
		break;
	//If you add further clusters insert the logic here
};

Notes:

  • The only vCenters defined in vRO are compute (workload) clusters. If you have others, you would need to filter them out.
  • The storage admin has decided that if vSAN usage goes above 65% then the deployment should bomb out. Hey, SAS SSDs are expensive, even for HobbitCloud.
  • The above code only knows about two clusters/sites. If you bring more online, you would need to extend your case block.
  • Feel free to remove the extraneous logging. I hacked that together in about three minutes, and it pays to be verbose at speed.

Create a new workflow called Wrapper – Choose Availability Zone. Edit it, and drag an action onto the canvas. Select the action, save and close the workflow.

Run the workflow to verify the least utilized compute cluster is returned.

Configure vRA

In vRA. create a custom property called Vrm.DataCenter.Location. Give it a friendly Label, set the Data Type to String, Required to Yes, and the Display as to Dropdown.

Click External Values, then click Select to choose the vRO action we created previously:

Finally click OK.

Choosing the Correct Network

We now have the ability to deploy to the least used cluster. There is only one datastore defined per cluster, so storage selection is not an issue. However we have no control over which network will be selected.

Back in vRO, create another action called chooseNetworkProfile. Again, set the Return type to Array/String, and create two input parameters of type String called inAvailabilityZone and inBusinessGroup. Paste in the following code:

var networkProfile = new Array();
var netProfStr = "ULS-" + inAvailabilityZone + "-" + inBusinessGroup;
networkProfile.push(netProfStr);

return networkProfile;

The above line:

var netProfStr = "ULS-" + inAvailabilityZone + "-" + inBusinessGroup;

Reflects the naming convention for our NSX Universal logical switches. Amend as necessary.

Create another custom property called VirtualMachine.Network0.NetworkProfileName and configure as follows:

Select the vRO action we just created as an external value. Select the inAvailabilityZone input parameter, click Edit, then Bind, and use the dropdown box to select the Vrm.Datacenter.Location custom property.

Repeat the process for the inBusinessGroup in parameter, this time selecting the custom property from Capture the Business Group at request time in vRealize Automation.

Note: you can completely skip the business group part – it’s just how we define our logical switches.

By specifying the network profile in this way, it will also choose the correct virtual network to assign to our VM. Bear in mind, this will work without any networking components defined on the blueprint – and if there are some defined, this will overwrite them.

Deployment

To tie this up, either add both custom properties to your blueprint, or create a property group for them both and attach that.

At deployment time, verify everything works as expected:

Voila!

2 thoughts on “Enabling dynamic site selection in the Private Cloud with vRealize Automation

  1. Thank you so much for the post. Very helpful information.
    Can you assist me with a similar requirement in a stretched vSAN cluster.
    We have Host in physical data-centers in 2 sites that are part of a stretched vSAN cluster. The requirement is to select a site from the catalog request form and build the VM in the selected site. Not very sure how to proceed with this.Is there a possibility to use the location xml for this requirement?

    Creating a VM/Host affinity “should” rule and adding the VM to the rule seems like the only option to me, but not very sure if there are other ways of achieving this, also not confident of “Should” affinity rule binding. Please assist with input on this. Thanks again.

    Like

    • I would define a custom property with two values, one for each site – and then use that vale to define where the VM is provision.

      The location XML isn’t that smart really. You’ll have to code this in yourself I’m afraid.

      The article will get you most of the way there.

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.