A closer look at VVol snapshot policies on Pure Storage with vSphere 6.7

I am in the very fortunate position of having access to a Pure Storage array, and this has been recently updated to support Virtual Volumes. With my new 6.7 vSphere cluster, I finally found some time to take a closer look at Virtual Volume (VVol) snapshots on the Pure array, something that I have been meaning to do for some time. For those of you who are new to Virtual Volumes (VVols), one of the major advantages is the granularity at which certain operations can now be done. In the past, we were always dealing with data services at the volume level (e.g. replication, snapshots). With the arrival of VVols, these operations can now be done at the virtual machine level, meaning that we can now instantiate array based snapshots on a per VM basis. Let’s have a look at this in operations.

Protection Group Setup

The very first step you need to do is to create a Protection Group on the Pure Storage array. Well, actually, this step is optional as we will see later that PGs can be automatically created too. The PG creation section is found in the Storage section of the UI for managing the array. When the Protection Group is created, there is an option to schedule both snapshots and replication. Both options are initially disabled.

To enable a snapshot schedule, simply select the snapshot schedule edit, and enable it. You can also change the frequency and retention times of the snapshots. The default is to snapshot every hour, and keep all snapshots for 1 day. This information about frequency and retention needs to be noted as it will form the basis of our VVol policy on vSphere, which we will do next.

Create a Snapshot Policy on vSphere

The policy will be created in the VM Storage Policies section. The snapshot policies for the Pure array are found under the replication tab once the Pure provider is selected. Here is a sample policy taken from my lab setup. Note that on this occasion I did not specify a name for the replication group, I simply specified that I needed a Local Snapshot Policy Capable array alongside the snapshot interval and retention entries.

The Pure array virtual volume datastore will show as being compliant with this policy.

However when a new VM is deployed with this policy, there is no prompt for a Protection Group name. What happens is that a brand new Protection Group is automatically instantiated on the array, and the newly created VM is placed in this automatically created Protection Group. Note the auto-generated name of the Protection Group below – vp-auto-rg-xxxxx. snap2-test is the name of my VM and you can see the Config-VVol and VMDK/Data VVol are members.

The same behaviour will take place for every VM deployed with this policy – a new protection group will be automatically created.

If we want to deploy a VM to a particular Protection Group, what we need to do is to provide the name of a Protection Group when we create the policy. However, in the policy, the Protection Group is referred to as a Consistency Group. If we add a Consistency Group Name, the policy would look something like this:

Of course, I also have to a consistency group called Snaps on the array, or else the virtual Volume datastore would not appear as compliant. Now when I deploy a VM with this policy, there is a change in the workflow. When the policy is selected during provisioning, I am prompted to select the Protection Group (although in this case it is called a replication group). Note however that only a single replication group is displayed which matches the name we placed in the policy earlier: Snaps.

The preceding tag pure-01 is the name of the array so that groups with the same name on different arrays can be identified. Once the replication group is chosen, the policy should turn compliant and you can continue to deploy the VM as normal. When the VM has been successfully provisioned, you should see the VM (Config and Data VVols) in the Protection Group back on the array. In this example, my VM should be placed in the Snaps Protection Group.

Apply a new policy to an existing VVol based VM

In this final test, I wanted to see the effect of applying a new policy which contains a snapshot requirement to a VM. The VM was already deployed on the array. However, it does not matter if the VM current policy has a snapshot requirement or not, or whether the policy has a Protection Group set, you still have to select the appropriate Protection Group each time you change the policy. The difference is that if you have a Protection Group selected in the new policy, then that is the only one you can choose when applying that policy (but you still have to choose it manually). If you choose a policy that does not have the Protection Group specifically set, then you can choose any of the Protection Groups when you change to the new policy (so long as the other attributed like retention and frequency match).

Here are the results of selecting a VM which originally had no snapshot protection with a policy that has a snapshot policy but the new policy did not specify a Protection Group. I changed the policy from vvol-datastore which has no snapshot requirements to VVols+Snapshots, which does have a snapshot requirement – it does not specify a Protection Group (or as it is called here, replication group). Now I need to select Configure to pick a Protection Group for the snapshots.

After clicking Configure, I now have a choice of Protection Groups to choose from, as all of these have matching retention (1 day) and frequency (1 hour) policies.

After selecting the correct Protection Group, and completing the change policy wizard, the VVols belonging to this VM (Config-VVol, Data VVol) are placed in the selected Protection Group and the VM is shown as Compliant.

That completes the post. I will admit that the use of multiple names (replication group, consistency group, protection group) threw me a little bit at first. This is partly to do with the VVol spec wanting certain naming conventions and partly to do with Pure adding some future-proofing for some new features. However, once I realized that they were all the same thing, it was plain sailing after that and it becomes quite intuitive.

Shameless plug

If you are planning to attend VMworld 2018, I’ll be running a whole breakout session on Storage Policy Based Management with my good buddy Duncan Epping. In this session (HCI1270BU), we’ll be looking at The Power of SPBM, Storage Policy Based Management. This takes place on Tuesday, Aug 28 from 12:30 p.m. to 1:30 p.m. This will cover vSAN, Virtual Volumes, some I/O Filters and how this can all be orchestrated from the likes of vRealize Automation (which now has an SPBM plugin). If this is something you are interested in, we’d love to see you at our session.

4 comments
  1. Hi Cormac,

    Thanks for this post, very interesting. I know you have introduced this concept long back in your posts and I may have missed the bus so far, but now I just beginning to understand the concept of vVols 🙂

    You mentioned ‘With the arrival of VVols, these operations can now be done at the virtual machine level, meaning that we can now instantiate array based snapshots on a per VM basis’.

    That’s very exciting & interesting – Array based snapshots on a per VM basis ? Does that require one-2-one mapping between a VM and vVOL ? For silly example – If I provision a vVOL datastore, via NFS and if I put 5 VMs in that datastore, will I still be able to replicate single VM as oppose to whole the whole Volume ? For NetApp, it would be ‘SnapMirror’ replication, which is generally at volume level, in this case it would replicate vVOL to vVOL with single VM or will it replicate all 5 VMs stored on that vVOL datastore ?

    Thanks and appreciate your precious time.

    Ashwin

    • All mappings between VMs to VVols is on a 1:1 basis. So yes, for each VM, you see a set of distinct VVols on the array.

      The VVol datastore, which holds the VVols, can be thought of as a logical a representation of the storage array to vSphere. Thus you have somewhere to provision your VMs to.

      And yes, even though all the VMs will appear to reside on a “VVol datastore”, they are individual volumes at the back-end, which is why you can do items like snapshot, QoS and replicate on a per VM basis with VVols.

      There are some very good high level sessions on VVols in the VMworld catalog from previous years. They should be able to give you a good overview of the whole VVol concept.

  2. Interesting question from ashwin.

    Also looking forward getting answer here. We also missed vvols completely due to no storage vcenter connect. Storage is completely managed by foreign Teams

    We use already san replication in the backkground with pure and hitachi g1000 still not sure if vvols are such an interesting thing or if i do nit get the point…

    • Hopefully the answer provided to Ashwin helped, but there are other reasons apart from VM granluarity – policy driven consumption model, easier configuration when it comes to pathing/path policies/LUN presentations/LUN Masking and scale are some that spring to mind. But I do think that being able to consume array based data services on a per VM basis is the key advantage.

Comments are closed.