vRealize Automation/vRealize Orchestration plugin for Storage Automation v2.5
As mentioned in the introduction, there is now an updated plugin called vRA plugin for Storage Automation v2.5 available on VMware Solution Exchange. This plugin will allow VMs deployed via vRA blueprints to consume storage policies. While this plugin has been available in one form or another for a few years, the major change is that VMware is now providing official support for it via GSS as well as a dedicated engineering team (so long as you have an active vRA and vSAN/vSphere license).
Here is an overview of the solution:
- Expose SPBM storage policies from vCenter to vRA UI (vSAN, VVols, etc)
- Self-service selection of a storage policy during day 1 VM provisioning
- Self-service changing of a storage policy during day 2 operations, which includes automated migrating/adjusting underlying datastore placement to a different datastore (or even across vCenter Servers).
- Fully interop with vRA 7.5/7.4 as well as latest vSphere/vSAN releases
You can find more information about the new v2.5 Storage Automation plugin in this official VMware blog and there is also a demo and detailed technical guidance on StorageHub.
Cloud Assembly
Let’s talk about updates to Cloud Assembly next. I suppose the first thing to point out is that is not simply a SaaS version of vRA. It would be more precise to state that it is a ground-up build of our cloud management stack, available in SaaS. Features include:
- Set of automation (SaaS) services developed as a true cloud-native application
- Engineered to support modern DevOps practices and API-centric approaches
- Part of VMware Cloud Services portfolio
- Includes core provisioning and Lifecycle Management., Infrastructure as Code (IaC), Catalog and Pipeline
- Multi-cloud use cases: On-premises VMW SDDC, VMware Cloud on AWS, AWS, Azure
- Multi-platform: VMs, container services (PKS), PaaS (PCF)
As I mentioned at the beginning of the post, from a storage perspective, SPBM policies are natively exposed in Cloud Assembly and are consumable during provisioning. Cloud Assembly will discover and collect all existing SPBM policies once the vSphere provider is configured. This includes all the out-of-the-box SPBM policies – e.g. Default Storage Policy, VM Encryption, VVol No Reqs, etc. – and anything created by the user.
The policies can be tagged via Capability Tags to provide additional controls on placement. To use these policies, the VI-Admin must first create one or more Storage Profiles in Cloud Assembly, selecting the desired Storage Policy, associated datastore, and other options shown below. A Capability Tag can then be added to identify the Storage Profile by some named value (e.g. ALL-FLASH-VSAN, ENCRYPTED-VSAN).
Storage Profiles can be created for all storage types, vSAN, VMFS, NFS, as shown below:
Storage placement is declared in the blueprint’s YAML (properties -> storage -> constraints -> tag). In this case, the tag is populated by user input at provisioning time, which will result in the WebTier disk (selected in the blueprint) being placed on a datastore which matches a tag within the configured Storage Profile:
Now a common question we have had in the past is whether we have any lower granularity to select/build a policy at provisioning time, e.g. for vSAN, can we select a FailuresToTolerate value at provisioning time? At this point in time, the answer is no. The granular SPBM policies are currently not exposed for use right now. However, I am led to believe that this may change in future.
In closing, I do want to emphasize one point – the new SPBM plugin mentioned earlier is NOT a requirement for Cloud Assembly. It is only required for vRealize Automation when you wish to consume SPBM policies at provisioning time.
Kudos to my colleague and good friend Jad El-Zein for fielding a lot of my questions on this behavior. If you’re not already following Jad on twitter, please consider doing so for all the latest and greatest VMware management information.