One of the core benefits of using vVols is the integration with storage and vSphere Manage Snapshots. The operations of the managed snapshot are offloaded to the FlashArray and there is no performance penalty for keeping the managed snapshots. When the operations behind managed snapshot are offloaded to VASA and the FlashArray, this creates additional work being done on the FlashArray that is not there with managed snapshots on VMFS.
Massive improvements to vVols performance at scale and load has been released with the FlashArray VASA Provider 2.0.0 with Purity//FA 6.2 and 6.3
Everpure's recommendation when using vVols with the FlashArray is to upgrade to a Purity//FA 6.2.10 or higher.
Please see the KB What's New with VASA Provider Version 2.0.0? for more information.
Here are some points to keep in mind when using Managed Snapshots with vVols based VMs.
- Managed Snapshots for vVols based VMs create volumes for each Data vVol on that VM that have a -snap suffix in their naming.
- The process of taking a managed snapshot for a vVol based VM will first issue a Prepare Snapshot Virtual Volume operation which will cause VASA to create placeholder data-snap volumes. Once completed vSphere will then send the Snapshot Virtual Volume request after stunning the VM. VASA will then take consistent point in time snapshots of each data vVol and copy them out to the placeholder volumes previously created. Once the requests complete for each virtual disk the VM is unstunned and the snapshot is completed.
- With FA volumes being created for the managed snapshot, this directly impacts the volume count on the FlashArray. For example, a vVol VM with 5 VMDK (Data vVols) will create 5 new volumes on the FA for each managed snapshot. If 3 managed snapshots are taken, then this VM has a volume count on the FA of 22 volumes (1 Config and 20 Data vVols while powered off; 1 additional Swap vVol while powered on).
- Managed Snapshots only trigger Point in Time snapshots of the Data vVols and not the Config vVol. In the event that the VM is deleted and a recovery of the VM is desired, it will manually have to be done from a pgroup snapshot.
- The process of VMware taking a managed snapshot is fairly serialized; specifically, the snapshotVirtualVolume operations are serialized. This means that if a VM has 3 VMDKs (Data vVols), the snapshotVIrtualVolume request will be issued for one VMDK and after it's complete the next VMDK will have the operation issued against it. The more VMDKs a VM has, the larger the impact to how long the managed snapshot will take to complete. This could increase the stun time for that VM.
- VMware has committed to improveing the performance of these calls from vSphere. In vSphere 7.0 U3 they have updated snapshotVirtualVolume to use the max batch size advertised by VASA to issue snapshotVirtualVolume calls with multiple data vVols. Multiple snapshotVirtualVolume calls for the same VM will be issued close to the same time now as well in the event that the number of virutal disks is greater than the max batch size.
- Recommendation: Plan accordingly when setting up managed snapshots (scheduled or manual) and configuring backup software which leverages managed snapshots for incremental backups. The size of the Data vVols and the amount of Data vVols per VM can impact how long the snapshot virtual volume op takes and how long the stun time can be for the VM.