VMware vCloud Automation Center is the center piece of VMware’s Software-Defined Enterprise vision. It is also the primary user and admin interface for enterprise and application services, and therefore it makes a lot of sense for vCAC to be the core integration point for the SDDC.
Rawlinson Rivera (@PunchingClouds) recently posted a blog post titled “VMware Virtual SAN Interoperability: vCloud Automation Center“, where he highlights the use of vCloud Automation Center (vCAC) 6.0 to deploy applications directly to a VSAN Datastore while also leveraging a VM Storage Policy. In short, the desired storage policy is applied to the template backing the vCAC Blueprint. Once provisioned, the resulting machine adopts the associated storage policy and the rest is glorious, app-centric VSAN storage consumption. I recommend reviewing that post to get a better idea of what we’re doing here.
So now that we have a basic understanding of the interoperability between vCAC and VSAN, let’s dive into some more advanced concepts for a glimpse into the art of the possible by expanding on Rawlinson’s example and using some of vCAC’s extensibility features to deliver greater functionality.The integration between vCAC and VSAN can greatly enhance how applications are provisioned. Since storage policies can be configured per-application or VM, you can specify varying policies based on the use case, tier, application criticality, SLA, etc…all backed by a common VSAN Datastore. If you are not familiar with VM Storage Policies, I highly recommend gaining an understanding of when/why/how to use them before continuing.
vCAC + VSAN, VMware vSphere Blog |
Overview
vCAC provides some pretty awesome extensibility in the form of the Property Dictionary, Custom Properties, and the ability to invoke vCenter Orchestrator workflows during pre-, active-, or post-provisioning states. Using some of the out-of-the-box capabilities of vCAC, we can allow users to actually select the storage policy when an application is being requested — and that is what this post is all about! But first, let’s review the different options for accomplishing this task:
- Wait for VMware to add native visibility into Software Policy-Based Management (SPBM). In the spirit of tighter integration, you can assume that this is something VMware is working on.
Pro: should be pretty obvious.
Con: wait. - Use vCAC’s Property Dictionary and Custom Properties to provide a drop-down selection during provision. Once requested, vCAC uses a vm template that is pre-configured with the corresponding VM Storage Policy.
Pro: this method provides a fairly straightforward means of accomplishing the task at hand by utilizing the Property Dictionary and Custom Properties with minimal learning curve.Con: a template has to be created and preconfigured per each storage policy option. - Use more complex extensibility options to dynamically allocate a user-selected VM Storage Policy during or after a machine is provisioned.
Pro: although the most complex of these options, this will provide the greatest flexibility and automation.
Con: more complex, requires a solid understanding of vCAC’s extensibility and vCO to build associated workflows and API integration.
Tasks Summary
- Create a VM Storage Policy based on your use cases (I will use “HighIO” and “LowIO” examples)
- Create a vm template for each machine + desired storage policy
- Apply appropriate storage policy to each vm (template)
- Create a Property Dictionary definition in vCAC using the “CloneFrom” reserved custom property
- Apply the Property Definition to a vCAC Blueprint
- Go!
1.) Create your VM Storage Policies
2.) Create a VM template per Storage Policy
As a prerequisite to the proceeding steps, you need to create at least two templates in vCenter that will each receive a unique VM Storage Policy. But first, we’ll need to create the VM’s and apply the storage policy to them before converting to templates (VM Storage Policies can only be applied to VM’s). My example is built on an Ubuntu guest, so I created two identical Ubuntu VM’s named “ubuntu_v12-04_HighIO” and “ubuntu_v12-04_LowIO“. The names are important as they will be exposed to vCAC and users in later steps and should represent the storage policy one way or another. You should also avoid spaces in the names to prevent problems in vCAC later.
3.) Apply Storage Policies to each VM
4.) Create a new Property Definition in vCAC
5.) Apply the Property Definition to your vCAC Blueprint
6.) Go! – Test Your Blueprint
Steps
|
Screenshot
|
From the “Catalog” tab, request the catalog item that contains the custom property (previous step). Note: there is an assumption that you have already published and entitled this catalog item. If not, you need to go back and do that before it is visible in the Catalog. |
|
You should see the new field titled “Select App Tier” in the request form. Use the drop-down to select one of the preconfigured options. In this example, I select “ubuntu_v12-04_LowIO”, which corresponds to a template with the exact name in vCenter. Submit the request… |
|
Once provisioned, use vSphere Web Client to check the VM Storage Policy applied to the new machine. Here you can see “ops-5024” is configured with the “LowIO Apps” policy and is compliant |
|
Success!! (if not, leave a comment or take it to twitter) |
Final Thoughts
There are many tweaks that can be done to this guide to deliver a result that works better for your environment. For example, “HighIO” and “LowIO” policies aren’t really the best example of how to use VM Storage Policies (in hindsight). I used these options purely as an example and representation. Also, since the drop-down menu in vCAC must match the VM template name, you should be able to come up with something a little more descriptive of the storage policy – just as long as the template name matches the property definition values where it is noted.
The ultimate goal for this post is to get you thinking about the art of the possible with vCAC and VSAN (individually or combined). Please feel free to leave a comment or start a discussion on twitter!
@virtualjad
This procedure looks doesn’t work with vRA 7.x. The VM clones the correct template but put the VM using the first storage defined on the reservation not the Storage Profile associated with the template.