I received a question recently that revolved around the distinction between the different types of VM Storage Policies available, namely Storage Policy Based Management (SPBM) for vSAN and vVols, and tag-based placement (for all datastores).
SPBM is the storage management framework inherent within vSAN and vVols that allows for granular control over your VM and container storage. Each VM disk or container volume could conceivably have a different policy applied to it that defines its availability and performance requirements/limits of that disk or container volume.
Normally, this would be achieved through the use of different LUNs and datastores within vSphere, each with rigid attributes that cannot be changed (for example, RAID5, replication, number of disks backing the LUN, etc). This is the case with tag-based placement, tag-based placement allows administrators to group datastores into logical divisions based on an arbitrary tag assigned to them – for example, an admin may choose to label a few datastores “High Performance” if they have some flash caching or “High Redundancy” if it is used for site-replication. Tag-based placement can be any mixture of VMFS, NFS, vVols or vSAN datastores.
With tag-based placement there is a limit to the composability, however – for example, if I want “High Performance” and “High Redundancy” then I cannot choose both and get the benefits from them as they would encompass different physical datastores. vSAN and vVols work differently – with traditional LUN-based storage datastores are created per LUN presented from the array (or group of LUNs if using Datastore Clusters) each LUN has its own specific performance and redundancy profile (say one LUN is 10 disks of SAS, RAID5 and another is 20 disks of SAS, FAST cache, and RAID6) and has a finite capacity based on the backing disks that are not easily changed without mass storage migrations.
Taking vSAN as an example, given the storage across all the hosts is aggregated into a single logical datastore and the performance and availability profile of a VM is not dictated by the datastore placement, but rather by the policy applied to the VM.
To explain how SPBM is different – let’s take a look at the lifecycle of an app in development.
- The app starts out in dev – low redundancy, low performance – it’s not business or mission-critical, we can apply the “Development” SPBM policy to that VM, it will use minimal storage but will have enough performance for the developer to do their job.
- The VM moves into the testing phase next usually this would mean Storage vMotioning the VM from its original datastore to another one with different backing disks and different characteristics to deal with the increased load and demand. With SPBM and vSAN the administrator simply changes the VM’s policy to “Testing” and vSAN will move the backing components around on the disks within the cluster transparently to achieve the new policy’s requirements.
- Finally, the app has gone through its proof of concept and is ready to be deployed into the business at large and has now become critical to daily operations – as such, it needs to be replicated across sites, have high performance and high levels of redundancy. Again, when using SPBM and vSAN all the administrator needs to do is change the policy to “Production” and the VM’s backing components will be moved around within the vSAN cluster, replicated across sites and striped across more backing disks as the policy has defined – completely transparent to the VM and anyone operating or managing the cluster.
As you can see, while the different types of VM policies allow for automated placement, tag-based has some limitations that SPBM, vSAN, and vVols overcome that is simply not possible with traditional LUN-based datastores.
For more information on SPBM, check out StorageHub or how vSAN and SPBM enable persistent storage for next-generation applications.
