Introduction
One of the more common use cases that we help customers address during an engagement is translating their business logic for virtual machine placement into dynamic resource placement decisioning. The two main mechanisms that we use to achieve the desired result have existed in vRealize Automation for years; however, until just recently, if you needed to achieve automated results, you would have needed to write custom code in vRealize Orchestrator to address some of the advanced placement decisioning we have seen requested by our customers. Over the last few releases of the SovLabs Plugin, we have been steadily adding support for a number of special vRA Custom Properties that can only be addressed at runtime (aka runtime properties) and cannot be modified after a Catalog Item has been requested. In this blog post, I address two of these properties that help with resource placement decisioning: Vrm.DataCenter.Location and ReservationPolicyID.
Vrm.DataCenter.Location
According to the vRA 7.6 Custom Properties Reference, Vrm.DataCenter.Location: allows you to use a blueprint to provision machines on more than one compute resource. You can add the Vrm.DataCenter.Location property to a blueprint, or enable the Display Location on Request option in the blueprint, to require that the user supply a data center location when they request machine provisioning.
In practice, what I typically find is that, if a company is using this custom property, most of the time it is used to denote a geographical location. For example, in the diagram below, Vrm.DataCenter.Location is used to select clusters in either the Boston, or London “locations”. This location could represent three separate clusters in the same datacenter, or three clusters in three separate availability zones located in the same region.
Once the appropriate location has been selected, vRA will select a Reservation for the requesting business group on one of the clusters in that region.
ReservationPolicyID
According to the vRA 7.6 Custom Properties Reference, ReservationPolicyID: specifies the reservation policy ID, not the reservation policy name. For example, the name that is returned by the vRealize Orchestrator property getApplicableReservationPolicies is the reservation policy name, not the reservation policy ID.
Most of the time when I encounter customers using the ReservationPolicyID custom property, it denotes the different purposes for which the cluster is designed to be used. In the following example, that would be production, test, and development clusters.
ReservationPolicyID is certainly not limited to the environment example shown above. Another use case is application specific clusters (eg. SQL may need to be placed on a separate cluster). One thing that you will want to note is that, in its native implementation in vRA, this property expects the UID of the Reservation Policy and not the user friendly name that you can easily remember and reference. The way that we have approached Reservation Policy with the SovLabs Property Toolkit removes this cumbersome constraint. More on that point later in the post.
Reference Use Case
For the purposes of this article, our reference use case will include two datacenters, with four clusters in each datacenter. Here is what the physical layout looks like:
The physical layout, however, is very often the simplest part of the equation. Some of my more detailed discussions revolve not around what the physical layout is, but around the WHY: the business logic that is far too often undocumented of why a particular resource gets provisioned in a specific cluster. So, in this particular example, my business logic looks a little more like this:
- Boston is used as a location for primary resources.
- London is used as a location for DR resources.
- The clusters in each location are subdivided into environments Prod, Test, and Dev. Each of which use separate networks, storage, etc.
- If the resource requested is both a production, and a SQL server, that resource should end up in Cluster 4.
For this use case, we will be using both Vrm.DataCenter.Location and Reservation Policies together with the SovLabs Property Toolkit to take a data-driven approach to dynamically determine the appropriate location for each resource. Here is a high-level overview of the solution:
Implementation
SovLabs plugin 2019.24.0 or greater is required to use Vrm.DataCenter.Location and ReservationPolicyID.
Set up the Locations
First, you will need to create the location selections for your environment if you have not done so already. The vRA documentation for this procedure can be found here. In our example use case, I will be using the locations of “Boston”, and “London”.
Next, you will need to tag each cluster with the appropriate location. To do so, navigate to Infrastructure > Compute Resources > Compute Resources and then edit each cluster.
Set up the Reservation Policies
Now that the Datacenter locations have been configured appropriately, we can set the reservation policies for each cluster. First, you will need to go to Infrastructure > Reservations > Reservation Policies to create the required Reservation Policies.
Once the Reservation policies have been created, we can then create the appropriate reservations for our business group, note that each reservation has the appropriate reservation policy applied.
Configure the Blueprint
Now we need to create a new blueprint, and as part of that blueprint we need to give the end user a way to select the values that drive our resource(s) to the appropriate endpoints. Whenever adding properties to blueprints, I try to be very conscious of the level where I set the properties. If I plan on having a multi-machine blueprint, I will make sure to set properties that apply to ALL VMs in the blueprint at the deployment level, since deployment level properties propagate to all child VMs. Doing so means less required input from the end user and can ensure uniformity across multiple VMs in the same deployment. For example, very rarely do I ever see a single request create VMs that are members of more than one environment (prod, test, dev) at a time. While, technically, it can be done, I just haven’t seen many business requirements for such a blueprint, so I typically set an environment custom property at the deployment level. My purpose and application properties, however, will both be set at the machine level because, most of the time, these properties are machine specific.
So, at the Deployment level, we add the Environment property.
And at the machine level we add Purpose, and Application.
From here, we can create a Custom Form, expose each of our required 3 properties in the form, and create the drop down values for each.
SovLabs Property Toolkit Properties
One of the things that our customers have identified as being really inconvenient about the way that ReservationPolicyID works natively is that the value of the property that vRA is expecting is the UID that corresponds to the Reservation Policy as opposed to the name of the Reservation Policy itself. The way that the SovLabs Property Toolkit addresses this situation is to allow you to specify the name of the reservation policy. The Property Toolkit will then find the corresponding ID of the Reservation Policy and set the UID as the value of the ReservationPolicyID property on your blueprint.
To apply ReservationPolicyID using the Property Toolkit, we will be using the SovLabs_vRAReservationPolicy property on our blueprint. We are going to use the SovLabs Template Engine to drive the custom logic for our use case without writing a single line of custom code in vRO. To test the Template Engine syntax, we start from the Catalog tab and search for template to find the SovLabs Template Tester.
The SovLabs Template Engine is included with every one of our modules, but when licensed for the Property Toolkit, we can use the Template Engine to wrap logic around any vRA Custom Property to include system properties (such as location and reservation policy). We can construct a simple IF statement using the Template Engine syntax to apply the PRODSQL reservation policy if the application selected was SQL and the environment is PROD. For any other conditions, we are just going to return the environment as the value of our reservation policy.
{% if Application == “SQL” and Environment == “PROD” %}PRODSQL{% else %}{{Environment}}{% endif %}
Here is how this looks in the Template Tester.
To apply Vrm.DataCenter.Location using the Property Toolkit, we will be using the SovLabs_VrmDataCenterLocation property on our blueprint. The SovLabs_VrmDataCenterLocation property would correspond to the name of the location that you would like to set on your blueprint.
{% if Purpose == “Primary” %}Boston{% else %}London{% endif %}
Anytime I create new syntax, I always use the Template Tester.
Now that I have my syntax tested, I can copy and paste the syntax in the value for each of my properties in my blueprint. I am going to set both of these properties at the deployment level for my blueprint, because they will propagate to each machine in a blueprint and evaluate the properties individually for each VM in the canvas. This means that if one VM in the blueprint selected “Primary”, and another “DR” for purpose that each of the VMs will be driven to the appropriate geographic location.
Create Approval Policies and Add to Entitlement
Since the location and reservation policy properties are the special runtime properties that we discussed earlier, the only way that they can be accessed and modified after submission is by an approval policy. The Property Toolkit includes a catalog item that will facilitate the creation of these approval policies for you, whether you need to create a brand new approval policy, or to append the SovLabs approval level to an existing approval policy. We want to make this process as seamless to our customers as possible. To access the Manage Property Toolkit Approval Policies catalog item, go to the Catalog tab and search for Approval.
In this example, we are going to create a new approval policy; however, if you have an existing policy, you can select “Update” for the “Action” field to select an existing approval policy and append the SovLabs approval information to that policy.
Next, we will need to add this approval policy to the entitlement for our Catalog Item. Go to Administration > Catalog Management > Entitlements, select the entitlement for the business group. We can then assign an approval policy to our catalog item. You may need to select the “Show all” link if the newly created approval policy does not show as an option.
Once we have assigned the approval policy, we should be ready to submit a request. I am going to submit two requests, one that should end up in Boston on the PRODSQL cluster, and one should end up in London on the DEV cluster.
Below, you can see the machines were placed where expected.
Summary
This fairly simple example really showcases how powerful the SovLabs Property Toolkit is when used for determining resource placement. The SovLabs Property Toolkit can be used to enable much more advanced customizations than those we’ve illustrated here, and, when used in conjunction with the other SovLabs modules, it offers a true end-to-end extensibility solution without the requirement of complex custom code.
