How to specify a deployment target when using vRealize Automation
I regularly get the question ‘Can I specify a deployment target when using vRealize Automation?’. Most of the time this question comes up at customers who want to use vRealize Automation on top of a vSphere Metro Storage Cluster environment. For those of you that don’t know what that is, a VMware vSphere Metro Storage Cluster configuration is a vSphere certified solution that combines replication with array-based clustering. These solutions are typically deployed in environments where the distance between data centers is limited, often metropolitan or campus environments. vSphere Metro Storage Cluster infrastructures are implemented with a goal of reaping the same benefits that high-availability clusters provide to a local site, in a geographically dispersed model with two data centers in different locations. A vSphere Metro Storage Cluster infrastructure is essentially a stretched cluster.
What’s the problem?
When using vRealize Automation the location of the deployment is determined by the reservations available to a Business Group. But the reservation only defines the amount of resources and the priority of the different reservations. Within that reservation the deployment target is randomly selected. So, if for example you add Cluster A to the reservation, deployment initiated by vRealize Automation can be performed on any host within that cluster. After deployment the placement is determined by vSphere DRS. If your cluster spans multiple locations, the new virtual machine(s) may end up in Data Center A or Data Center B. That’s why customers running a vSphere Metro Storage Cluster environment want to specify a deployment target.
With the release of vRealize Automation 7.3 VMware added Policy-Based Optimization of virtual machine placement. This allows you to integrate vRealize Automation with vRealize Operations to combine vRealize Automation governance with performance based insight to place virtual machines according to performance goals, using multiple algorithms. But this does not solve the problem of customers running a vSphere Metro Storage Cluster environment.
How to solve this
We can solve this issue but the are some things you need to have in place before you start.
First of all, you need to have a mechanism in place that keeps virtual machines pinned to a certain location or you need to disable DRS. Customers running a vSphere Metro Storage Cluster environment probably use DRS VM/host groups and VM/host rules to do this. When deploying a virtual machine with vrealize Automation we need to include the virtual machine in these VM/host groups so that the VM/host rules apply to that.
I have the following host and virtual machine groups in place to identify the virtual machine and hosts:
To bind virtual machines to certain hosts which in turn represent a data center location I have the following rules in place.
Make sure you select ‘Should run’, this means the VM Group should run on the hosts in the group. However, in case of a vSphere HA event, this rule will be overruled in order to keep the VMs running.
Second, assigning a specific deployment target will introduce a single point of failure. To make sure that the deployment is successful even when a host is down, you should create some DNS host entries using a data center location as the name and referring to the IP addresses of the associated hosts in that data center. I have six hosts (192.168.2.201 to 206) so I created the following DNS configuration.
Make sure to change/remove these DNS entries when a host is down or else it will still fail.
Third and last, we need to create some custom properties to influence the deployment and assign a specific deployment target data center. A complete list of custom properties can be found in the Custom Properties Reference documentation. For this we need the following two custom properties:
|VirtualMachine.Admin.ForceHost||Specifies the name of the ESX host. The property is only honored if VirtualMachine.Admin.HostSelectionPolicy is set to EXACT_MATCH.|
Note: This property is for vSphere only.
|VirtualMachine.Admin.HostSelectionPolicy||Optionally set to EXACT_MATCH to require the machine to be placed on the host specified by the VirtualMachine.Admin.ForceHost property. If the host is unavailable, the request results in a failure. If a host is not specified, the next best available host is selected. If set to EXACT_MATCH, an error occurs if the specified host does not have enough memory or is in maintenance mode.|
Note: This property applies to vSphere only.
Now that we have that in place, lets set it up.
How to setup a deployment target in vRealize Automation
I’ve created the two custom properties in the property definitions and for the VirtualMachine.Admin.ForceHost I defined two static values.
To group the two custom properties I created a Property Group called ‘Select Data Center’ and I put both custom properties in it. I configured the VirtualMachine.Admin.HostSelectionPolicy with the static value EXACT_MATCH and I set ‘Do not show in request‘ to No.
Last thing to do is to setup an event broker subscription to assign the virtual machine to the correct VM group (DataCenterA_VMs or DataCenterB_VMs).
To do this create the following vRealize Orchestrator script which is a combination of the payload extraction part and the standard ‘Add virtual machines to DRS Group‘ which you can find in Library > vCenter > Cluster and Compute resources.
The input comes from the vRealize Automation payload transferred to vRealize Orchestrator which should contain three variables which should be forwarded to the Add virtual machine to DRS group workflow:
- Cluster name (you can hardcode this in the workflow if there’s only one cluster).
- Virtual machine (vms variable) which needs to be added to the group.
- VM/host group (vm_group variable) to which the virtual machine needs to be added.
This requires a little bit of coding to include the following logic:
- If during request Location A was chosen, VirtualMachine.Admin.ForceHost = DataCenterA.corp.local then vm_group = DataCenterA_VMs (corresponding to the name of the VM/host group)
- If during request Location B was chosen, VirtualMachine.Admin.ForceHost = DataCenterB.corp.local then vm_group = DataCenterB_VMs (corresponding to the name of the VM/host group)
Then create a new Machine Provisioning event broker subscription which calls this script after the deployment has finished. I added the blueprint name in the subscription to limit it to this blueprint only, but if you want to use it on all blueprint you can skip that filter. Make sure you execute the workflow just after the creating of the virtual machine and before the initial power on, if not DRS may move the virtual machine to hosts in the other data center.
This should deploy the virtual machine(s) in a specific data center location and maintain that binding due to the binding of virtual machines to a specific set of hosts configured in DRS .
This article is a part in the VMGuru vRealize Automation Series.
Other articles in the series vRealize Automation:
- Infoblox & vRealize Automation, Setup IPAM endpoint
- Infoblox & vRealize Automation, Install Infoblox IPAM plugin
- Setup provisioning of vCloud Air workloads
- Setup a vCloud Air Endpoint in vRealize Automation
- Setup Postgres database high availability for vRealize Automation
- Setup vRealize Automation Cost profiles & currency
- Speed up vRealize Automation life cycle updates
- Configure vRealize Automation not to delete virtual machines
- Track infrastructure changes with vRealize Automation Data Collection
- MS SQL high availability support for vRealize Automation
- Setup the vRealize Automation prerequisites for IaaS
- vRealize Automation: How to …
- Downgrade the vRealize Automation license
- vRealize Automation 7 – New Architecture & Installation
- vRealize Automation 7 – Improved Authentication
- vRealize Automation 7 – Converged Blueprints
- vRealize Automation 7 – LifeCycle Extensibility
- How to transfer vRealize Automation payload to Orchestrator
- Automation is not difficult with vRealize Automation 7
- vRA custom host name using Orchestrator and Event Broker
- How to deliver Database-as-a-Service with vRealize Automation
- Prepare Windows for vRA software deployment
- Missing endpoints after upgrading to vRealize Automation 7.3
- How to run Containers as a Service – Part 1
- How to run Containers as a Service – Part 2
- Infoblox & vRealize Automation, IP Address Management (IPAM) made easy
- How to run Containers as a Service – Secure Docker communications
- Create a new database user using vRealize Automation XaaS
- Infoblox & vRealize Automation, Infoblox NIOS setup
- Infoblox & vRealize Automation, vRA setup
- vRealize Automation failed requests monitoring
- vRealize Automation 7.2 released
- How to specify a deployment target when using vRealize Automation
- vRealize Suite just became a lot easier with Lifecycle Manager
- LAMP Stacks made easy with VMware and Puppet
- PowerShell Friday: ExtensionData by Anne Jan Elsinga
- vRA custom host name using Orchestrator and Event Broker by Dimitri De Swart
- New release vSphere HTML5 Web Client fling by Sander Martijn
- How to transfer vRealize Automation payload to Orchestrator by Erik Scholten
- vSphere host maintenance with instant clones by Sander Martijn