Next in the SPBM Series is vSAN. In today’s storage landscape, there is a myriad of choices. But what sets VMware managed storage apart, whether vSAN or VVols, is storage policy-based management. By using SPBM policies to manage your storage, the arduous and inefficient process of setting up specific storage LUNs or volumes is no longer required. In the previous blog, I talked about Virtual Volumes and how easy they enable SPBM management of external storage. In this blog, we will dive into some details of using SPBM with vSAN.
With VMware vSAN, we have a lot of granularity in configuring storage policies and to what they are applied. With vSAN and SPBM we can apply different policies to different disks of a single VM, an entire VM or numerous VMs similar to VVols. With vSAN SPBM policies and the required node setup, you can utilize features like deduplication and compression or RAID 5 or 6 erasure coding which can add space efficiency and extend the value of your vSAN. If you have vSAN edge sites or stretched vSAN clusters, there are also policies that can be applied for these setups. All these features can greatly improve performance or protection of applications while reducing costs by avoiding over-provisioning resources not needed for low-performance functionality.
A typical, multi-policy, example is SQL. Often with SQL setups, there are different disks for different performance requirements. IE: TempDB, backup, data, logs, etc. Some require more performance while others, like backup, do not need performance and would be a waste high-performance resources. With vSAN SPBM policies, you can apply different policies to each disk based on its requirement. Gold tier for tempdb, logs, or data, silver for OS and maybe bronze for backup. Now your VM/application gets the performance required and storage is more efficiently utilized saving cost and extending resources.
vSAN SPBM policies can be changed anytime, but be careful. When a policy is changed on vSAN there can be a temporary increase in storage space utilization as the changes are made. You must make sure you have extra, unused space, available in your vSAN datastore to be able to make the policy change. The amount of space needed depends on the policy applied. This can be compounded if making policy changes to several VMs at the same time. Furthermore, some policies actually increase storage usage, for example, if you want more fault tolerant data and increase the failures to tolerate. Be cautious and aware of available space, and the changes in space requirements for the policy being applied.
In this blog rather than show you how a policy is created and applied, I’m going to let you go through some demos and create them yourself. The first demo is on creating a vSAN SPBM policy. The second demo really helps to show how data is placed and where additional storage may be required.
- First demos is creating a policy for vSAN:
- Second demo shows applying a policy and how that policy change affects the placement of the data for each object or disk:
Hopefully, this helps you to understand the incredibly powerful functionality of vSAN SPBM policies. Make sure to check out of blogs in the SPBM series.
Stay Tuned for the SPBM Blog Series
- Using Tag-based SPBM Policies to Manage Your Storage
- Storage Capabilities and Services
- Data Services SPBM Policies
Other blogs on vSAN SPBM functionality
- SPBM, because not all applications are created equal
- vSAN Operations: Use separate SPBM policies for VMs in stretched clusters
Additional SPBM Resources
