vSAN Storage Policy – Part 2
This is part of the VMware vSAN guide post series. By using the following link, you can access and explore more objectives from the VMware vSAN study guide.
In the previous post, I provided an explanation about the first tab of the VM Storage policy, now I want to explain the rest of the VM Storage Policy and explore the different options it offers.
In the Storage Rules tab, you have the opportunity to establish rules for encryption, space efficiency, and storage tier preferences.
Encryption Services
vSAN doesn’t just about performance and scalability; it also offers a set of security features to protect your data from both internal and external threats. vSAN Encryption is designed to provide data-at-rest and data-in-transit encryption for the data stored on the vSAN datastore.
- Data-at-rest encryption is a feature designed to protect your data in situations where data might compromise for example disks are stolen or when disks or hosts are being decommissioned. This encryption process involves using encryption keys to encrypt data before it is written to disk and decrypting it when read. This ensures that even if someone gains access to the underlying storage, the data remains unreadable without the proper decryption keys.
- Data-in-transit encryption is a feature designed to protect data as it moves around the vSAN cluster. All data and metadata traffic between hosts are encrypted. This encryption ensures that the data remains unreadable even if intercepted without the decryption keys.
You have three encryption options to choose from in order to define the desired data store for this virtual storage policy.
- Data-At-Rest encryption: To apply encryption to your data.
- No encryption: To apply no kind of encryption to your data.
- No preference: It makes policy to be compatible with both options
You cannot enable or disable data-at-rest or data-in-transit encryption here. These options can be enabled within the vSAN Cluster settings. However, if you’ve been following my blog series, you’d know that we already enabled data-at-rest encryption during the cluster creation.
Space Efficiency
The following settings will include various storage efficiency settings to define the desired data store for this virtual storage policy.
- Deduplication and compression: Apply both deduplication and compression to your data.
- Compression only: Apply only compression to your data.
- No space efficiency: Apply no kind of space efficiency to your objects.
- No preference: It makes policy to be compatible with all options
Data deduplication is a method that identifies duplicate blocks within data and employs a hash table to point to a single instance of that data block, avoiding the need to store identical blocks multiple times.
On the other hand, data compression focuses on optimizing data storage by employing encoding methods to represent the information more efficiently within a given amount of data.
These two techniques are unrelated but attempt to achieve a similar goal: aim to enhance space efficiency.
Deduplication is not supported yet on vSAN ESA, but it is on the roadmap!
Storage Tier
The next step involves specifying the storage tier for this storage policy. In vSAN ESA, the hybrid mode is no longer available. Therefore, you should choose the all-flash option.
- All Flash: If you want to make policy compatible with an all-flash vSAN.
- Hybrid: If you want to make policy compatible with only a hybrid environment.
- No preference: It makes policy to be compatible with both hybrid and all-flash environments.
Advanced Policy Rules
The next tab is Advanced Policy Rules, in which you can define some advanced configurations for VM storage policy.
- Number of disk stripes per object split the objects into chunks of data across more capacity devices. Allows you to specify how many stripes each object should be divided (maximum value is 12) into when it’s stored on the vSAN cluster. By distributing an object’s data across multiple disk stripes on different physical disks, vSAN can take advantage of parallelism in read and write operations, resulting in improved I/O performance. For instance, as demonstrated in the following GIF, I implemented a vSAN policy with 4 disk stripes and divided each object into 4 components.
As demonstrated in the screenshot below and the GIF above, only the performance leg creates four components for each object. In the capacity leg we are utilizing of RAID-5 erasure code which remains unchanged. This behavior arises due to modification in the stripe width policy, a change implemented since vSAN 7 Update 1. But if we employ RAID 1 in a similar situation, resulting in the creation of four components for each object within the capacity leg. For more information, I would recommend you to read the following blog post.
https://core.vmware.com/blog/stripe-width-improvements-vsan-7-u1
When using the vSAN OSA, a value higher than 1 might result in better performance, but when using the vSAN ESA, leave it to the default value of 1.
- IOPS limit for object number of I/O operations for an object such as VMDK. vSAN allows the object to double the rate of the IOPS limit during the first second of operation or after a period of inactivity.
- Object space reservation defines the percentage of the size of the object that must be reserved when deploying virtual machines. The following options are available:
- Thin provisioning (default)
- 25% reservation
- 50% reservation
- 75% reservation
- (100%) Thick provisioning
- Flash read cache reservation (%) is a percentage of the logical size of the virtual machine disk (vmdk) object on the SSD as read cache. This policy supported only hybrid storage in vSAN OSA, and for all-flash and vSAN ESA, do not use this option.
- Disable Object checksum by default the checksum is always on and if you enable it, it will not calculate checksum information to ensure the integrity of data by confirming that each copy of a file is exactly the same as the source file.
- Force provisioning If you enable this option, the object is provisioned even if the storage policy cannot be fulfilled by the datastore.
Tags
You can leverage tags to establish personalized storage capabilities, using them as references while formulating storage policies for virtual machines. Consider a scenario where your data center encompasses two vSAN clusters. When you construct a storage policy, it might match both vSAN clusters. However, if your intention is to create distinct policies for each vSAN datastore, you can adopt a tag-based approach.
In this context, you can assign a unique tag to each vSAN datastore and associate it accordingly. Subsequently, you have the option to incorporate this specific tag within the VM Storage Policy, ensuring that the policy aligns precisely with the intended vSAN datastore. This strategic utilization of tags enables more control over storage policy assignment, thereby optimizing your virtual machine storage management.
Conclusion
vSAN storage policy feature empowers organizations to achieve the perfect balance between performance, availability, and capacity utilization. By customizing storage settings to meet the exact demands of their workloads, administrators can optimize resource usage, reduce storage costs, and ensure data resiliency. As virtualized environments become increasingly complex, vSAN storage policies emerge as a valuable tool for building agile, efficient, and future-ready infrastructures.
In the upcoming post, I will explain how to create, apply and modify vSAN storage policies. Stay tuned!
References:
https://core.vmware.com/resource/vsan-encryption-services
https://core.vmware.com/blog/cluster-level-encryption-vsan-express-storage-architecture
https://core.vmware.com/blog/vsan-8-compression-express-storage-architecture
https://core.vmware.com/blog/stripe-width-storage-policy-rule-vsan-esa
https://core.vmware.com/blog/stripe-width-improvements-vsan-7-u1
