Site icon CormacHogan.com

Changing policies on-the-fly with VVols

Last week, I was presenting at the VMware User Group (VMUG) event in Poland. My topic was SPBM, Storage Policy Based Management. This is the framework for consuming data services, whether these are provided from vSAN, Virtual Volumes or VAIO (IO Filters). You can get the presentation from here. One of the attendees who had implemented Virtual Volumes (aka VVols) asked a very interesting question about changing policies of a VVol based VM on-the-fly. The question is whether a policy change causes a new VVol has to be instantiated, data synced to original VVol and then the original VVol is discarded, or if an existing VVol can simply inherit the new policy settings. I suspected that this might be an implementation specific behaviour, so since the customer was using HPE 3PAR, I reached out to my good friend Eric Siebert for his advice. Eric not only provided me with details on how HPE 3PAR’s VVol implementation would handle this, but also how Nimble’s VVol implementation handles it (HPE having bought Nimble Storage earlier this year).

Let’s start with 3PAR first. Eric stated that right now, with 3PAR, you cannot change a policy that involves a different tier of disk (known as a CPG on 3PAR). A CPG is short for Common Provisioning Group and examples could be Fiber Channel disks in a RAID-1 configuration, or Solid State Disks (SSD) in a RAID-5 configuration. When setting up a policy on 3PAR, you would select a CPG for the base storage and another CPG for snapshots. However it would seem that other policy settings like thin persistence, thin deduplication and adaptive flash cache can be enabled or disabled in the policy on-the-fly on the same VVol/VM.

Eric went on to say that in an upcoming release, HPE will have support for a 3PAR feature called Dynamic Optimization. This will then allow data to be moved around on the array to different CPGs, dynamically. Wit this feature, if and admin changes the SPBM policy, the 3PAR array can move the VVol/data to another CPG and discard the old VVol/data in the original CPG.

And Nimble? It seems that the only policy setting that might require a change of backing storage is enabling or disabling the “All Flash” option. But if you enable or disable this option, it does not automatically move the VVol to a different tier when the policy is changed.  On an array with a mix of all-flash and hybrid, Nimble will not move the VVol from one pool/folder to another depending on this policy setting. Instead they report the VM/VVol as non-compliant with its policy, and the user will then have to use migration tools such as Storage vMotion to move the VM/VVol to the appropriate Storage Container to make the VM/VVol compliant again. Remember that with VVols, Storage Container just look like datastores to vSphere. So yes, you can simply migrate between them as you would with NFS or VMFS.

For most other capabilities on the Nimble, they can dynamically adjust the VM and the VVol’s configuration, for example Quality of Service (QOS) Limits, Protection and Replication Schedules. Nimble has triple parity RAID as default for adaptive and All Flash. Thus there is no need to ever change the RAID levels for different drive types.

I reached out to Cody Hosterman over at Pure Storage to ask how things behaved on their VVol implementation. Cody told me that pretty much anything can be changed on a VVol policy on-the-fly in their implementation. They will never have to create a new VVol, anything can be moved/re-applied on-the-fly if that array supports it. If that array doesn’t support it, or doesn’t match the requirement (for instance one of their capabilities is naming a group of FlashArrays, aka “I want my VVol to be on a FlashArray in Chicago, not new York”.) adding that to a policy which causes a violation would require a storage vMotion to make it right. But things like replication interval, snapshot policies, etc can be changed on the fly and are immediately reflected when the VM is re-mediated.

Andy Banta was kind enough to share this regarding ElementOS, and the SolidFire VVol implementation. With ElementOS any policy can be changed on the fly, with the exception of encryption. Any policies that are changed at the VMware level, either a change to a base policy or a change of the policy a VMDK is using, are reflected immediately. This requires no data movement and no interaction with the storage admin interface or SolidFire APIs. It is handled entirely in the context of the VASA compliance check. For SolidFire, encryption is a cluster-wide capability, so an entire cluster is either encrypted or unencrypted. Changing this policy would actually require moving the VMDKs to a different cluster to satisfy compliance.

My next update was from Joel Kaufman over at NetApp. Joel told me that for ONTAP, any policy can be changed and the VVol inherits the new policy settings without having any changes to the storage, and no data movement. If the policy change brings the VM/VVol out of compliance with regards to the location where it is currently stored, a vSphere alarm showing that it is out of compliance state is triggered. An administrator can then move (using Storage vMotion once again I assume) the VM to a new location to bring it back to compliance, or update the policy to bring the VM back into compliance.

I’d like to thank Eric, Cody, Andy and Joel for their quick responses to this query. Watch this space for some further updates as I get them.

Exit mobile version