vSAN policies define virtual-machine storage requirements for performance and availability. These policies determine how storage objects are provisioned and allocated within the datastore to guarantee the required level of service.
vSAN implements Storage Policy Based Management, and each virtual machine deployed in a vSAN datastore has at least one assigned policy. When the VM is created and assigned a storage policy, the policy requirements are pushed to the vSAN layer. See the figure below.
Figure 44. SPBM
Storage policies are a set of rules and are assigned to VMs either manually or a default policy is automatically assigned. A system may have multiple storage policies. For instance, all virtual machines that include PROD-SQL in their name or resource group might be set at RAID 1 and a five-percent read-cache reservation, and TEST-WEB would be automatically set to RAID 0.
Administrators can dynamically change a VM storage policy. When changing attributes such as the number of Failures to tolerate, vSAN attempts to find a new placement for a replica with the new configuration. In some cases, existing parts of the current configuration can be reused, and the configuration just needs to be updated or extended. For example, if an object currently uses Failures to tolerate=1, and the user asks for Failures to tolerate=2, vSAN can simply add another mirror (and witness).
In other cases, such as changing the stripe width from one to two, vSAN cannot reuse existing replicas, and it creates a brand new replica (or replicas) without impacting the existing objects. A storage object has a status of Compliant if the attributes match the policy. When changing a policy online, the object may show as “not compliant” while vSAN reconfigures the object.
The figure below displays an example of the rule set for a storage policy.
Figure 45. vSAN policy attributes
This rule establishes the minimum number of capacity devices used for striping each virtual machine replica. A value higher than 1 might result in better performance, but it also results in higher resource consumption. The default value is the minimum, 1; the maximum value is 12. The stripe size is 1MB.
vSAN may decide that an object needs to be striped across multiple disks without any stripe-width policy requirement. The reason for this can vary, but typically it occurs when a VMDK is too large to fit on a single physical drive. However, when a particular stripe width is required, then it should not exceed the number of disks available to the cluster.
Flash cache reservation refers to flash capacity reserved as read cache for the virtual machine object, and it applies to hybrid configurations only. By default, vSAN dynamically allocates read cache to storage objects based on demand. As a result, no need typically exists to change the default 0 value for this parameter.
In very specific cases, when a small increase in the read cache for a single VM can provide a significant change in performance, it is an option. It should be used with caution to avoid wasting resources or taking resources from other VMs.
The default value is 0 percent. Maximum value is 100 percent.
This FTT option generally defines the number of host and device failures that a virtual machine object can tolerate. For n failures tolerated, n+1 copies of the VM object area created and 2n+1 hosts with storage are required.
The default value is 1. Maximum value is 3.
When erasure coding is enabled for a cluster (by setting FTM=Capacity), RAID 5 is applied if the number of Failures to tolerate is set to 1, and RAID 6 is applied if the number of Failures to tolerate is set to 2. Note a vSAN cluster requires a minimum of four nodes for RAID 5 and six nodes for RAID 6.
Failure tolerance method (FTM) specifies whether the data replication method optimizes for performance or capacity. The RAID 1 failure tolerance method provides better performance and consumes less memory and network resources but uses more disk space. RAID 5/6 erasure coding provides more usable capacity but consumes more CPU and network resources. (An upcoming section on erasure coding section provides additional information.)
This attribute establishes Quality of Service (QoS) for an object by defining an upper limit on the number IOPS a VM/VMDK can perform. The default behavior is that all objects are not limited, and low priority applications could potentially consume resources in a manner that could impact more important workloads. This rule allows different limits for different applications and can be used to keep workloads from impacting each other (the noisy-neighbor issue) or to supply service-level agreements (SLAs) for different workloads and maintain performance for tier-1 applications.
IOPS is calculated based on all of the operations on this VM/VMDK (read & write) including snapshots.
A few notes regarding IOPS limits for objects:
The figure below illustrates how IOs are throttled when the IOPS limit policy is set.
Figure 46. IOPs limits establishes QoS
vSAN uses end-to-end checksum to ensure data integrity by confirming that each copy of an object’s 4K chunk of data is exactly the same. The checksum is five bytes in length and persists with the data. When data is written, the checksum is verified to ensure no corruption occurred when the data transverses the network. When data is read, checksum verifies that the data read matches what was written. If an error is detected; vSAN uses a replica to recover the data and logs an error. Checksum calculation and error-correction are transparent to the user.
The default setting for all objects in the cluster is On, which means that checksum is enabled. The best practice is not to change this setting because detecting data corruption is a critical and valuable feature of vSAN and should not be disabled.
If this option is set to Yes, the object is provisioned even if the rules specified in the storage policy cannot be satisfied by the datastore.
This parameter is sometimes used during an outage when resources are limited and normal provisioning policy cannot be satisfied.
The default is No and will not allow an object to be created if the policy rules cannot be satisfied. This is appropriate for most production environments. If set to Yes, an object can be created even not enough resources are available to satisfy the policy rules. In this case, the object will be displayed as Not Compliant.
Object space reservation is specified as a percentage of the total object size. It reflects the reserved, thick-provisioned space required for deploying virtual machines.
The default value is 0%. Maximum value is 100%.
The value should be set either to 0% or 100% when using RAID-5/6 in combination with deduplication and compression.