vSAN storage policies define storage requirements for your virtual machines. These policies determine how the virtual machine storage objects are provisioned and allocated within the datastore to guarantee the required level of service.
When you enable vSAN on a host cluster, a single vSAN datastore is created and a default storage policy is assigned to the datastore.
When you know the storage requirements of your virtual machines, you can create a storage policy referencing capabilities that the datastore advertises. You can create several policies to capture different types or classes of requirements.
Each virtual machine deployed to vSAN datastores is assigned at least one virtual machine storage policy. You can assign storage policies when you create or edit virtual machines.
The VM swap object and the VM snapshot memory object do not adhere to the storage policies assigned to a VM. These objects are configured with Primary level of failures to tolerate set to 1. These objects might not have the same availability as other objects that have been assigned a policy with a different value for Primary level of failures to tolerate.
| Capability | Description |
|---|---|
| Primary level of failures to tolerate (PFTT) | Defines the number of host and device failures that a virtual machine object can tolerate. For n failures tolerated, each piece of data written is stored in n+1 places, including parity copies if using RAID 5 or RAID 6. When provisioning a virtual machine, if you do not select a storage policy, vSAN assigns this policy as the default virtual machine storage policy. If fault domains are configured, 2n+1 fault domains with hosts contributing capacity are required. A host which does not belong to a fault domain is considered its own single-host fault domain. Default value is 1. Maximum value is 3.
Note: If you do not want
vSAN to protect a single mirror copy of virtual machine objects, you can specify
PFTT = 0. However, the host might experience unusual delays when entering maintenance mode. The delays occur because
vSAN must evacuate the object from the host for the maintenance operation to complete successfully. Setting
PFTT = 0 means that your data is unprotected, and you might lose data when the
vSAN cluster encounters a device failure.
Note: If you create a storage policy and you do not specify a value for
PFTT,
vSAN creates a single mirror copy of the VM objects. It can tolerate a single failure. However, if multiple component failures occur, your data might be at risk.
In a stretched cluster, this rule defines the number of site failures that a virtual machine object can tolerate. You can use PFTT with the SFTT to provide local fault protection for objects within your data sites. The maximum value for a stretched cluster is 1. |
| Secondary level of failures to tolerate (SFTT) | In a stretched cluster, this rule defines the number of additional host failures that the object can tolerate after the number of site failures defined by PFTT is reached. If PFTT = 1 and SFTT = 2, and one site is unavailable, then the cluster can tolerate two additional host failures. Default value is 1. Maximum value is 3. |
| Data Locality | In a stretched cluster, this rule is available only if the Primary level of failures to tolerate is set to 0. You can set the Data Locality rule to None, Preferred, or Secondary. This rule enables you to limit virtual machine objects to a selected site or host in the stretched cluster. Default value is None. |
| Failure tolerance method | Specifies whether the data replication method optimizes for Performance or Capacity. If you select RAID-1 (Mirroring) - Performance, vSAN uses more disk space to place the components of objects but provides better performance for accessing the objects. If you select RAID-5/6 (Erasure Coding) - Capacity, vSAN uses less disk space, but the performance is reduced. You can use RAID 5 by applying the RAID-5/6 (Erasure Coding) - Capacity attribute to clusters with four or more fault domains, and set the Primary level of failures to tolerate to 1. You can use RAID 6 by applying the RAID-5/6 (Erasure Coding) - Capacity attribute to clusters with six or more fault domains, and set the Primary level of failures to tolerate to 2. In stretched clusters with Secondary level of failures to tolerate configured, this rule applies only to the Secondary level of failures to tolerate. For more information about RAID 5 or RAID 6, see Using RAID 5 or RAID 6 Erasure Coding. |
| Number of disk stripes per object | The minimum number of capacity devices across which each replica of a virtual machine object is striped. A value higher than 1 might result in better performance, but also results in higher use of system resources. Default value is 1. Maximum value is 12. Do not change the default striping value. In a hybrid environment, the disk stripes are spread across magnetic disks. For an all-flash configuration, the striping is across flash devices that make up the capacity layer. Make sure that your vSAN environment has sufficient capacity devices present to accommodate the request. |
| Flash read cache reservation | Flash capacity reserved as read cache for the virtual machine object. Specified as a percentage of the logical size of the virtual machine disk (vmdk) object. Reserved flash capacity cannot be used by other objects. Unreserved flash is shared fairly among all objects. Use this option only to address specific performance issues. You do not have to set a reservation to get cache. Setting read cache reservations might cause a problem when you move the virtual machine object because the cache reservation settings are always included with the object. The Flash Read Cache Reservation storage policy attribute is supported only for hybrid configurations. You must not use this attribute when defining a VM storage policy for an all-flash cluster. Default value is 0%. Maximum value is 100%.
Note: By default,
vSAN dynamically allocates read cache to storage objects based on demand. This feature represents the most flexible and the most optimal use of resources. As a result, typically, you do not need to change the default 0 value for this parameter.
To increase the value when solving a performance problem, exercise caution. Over-provisioned cache reservations across several virtual machines can cause flash device space to be wasted on over-reservations. These cache reservations are not available to service the workloads that need the required space at a given time. This space wasting and unavailability might lead to performance degradation. |
| Force provisioning | If the option is set to Yes, the object is provisioned even if the Primary level of failures to tolerate, Number of disk stripes per object, and Flash read cache reservation policies specified in the storage policy cannot be satisfied by the datastore. Use this parameter in bootstrapping scenarios and during an outage when standard provisioning is no longer possible. The default No is acceptable for most production environments. vSAN fails to provision a virtual machine when the policy requirements are not met, but it successfully creates the user-defined storage policy. |
| Object space reservation | Percentage of the logical size of the virtual machine disk (vmdk) object that must be reserved, or thick provisioned when deploying virtual machines. The following options are available:
|
| Disable object checksum | If the option is set to No, the object calculates checksum information to ensure the integrity of its data. If this option is set to Yes, the object does not calculate checksum information. vSAN uses end-to-end checksum to ensure the integrity of data by confirming that each copy of a file is exactly the same as the source file. The system checks the validity of the data during read/write operations, and if an error is detected, vSAN repairs the data or reports the error. If a checksum mismatch is detected, vSAN automatically repairs the data by overwriting the incorrect data with the correct data. Checksum calculation and error-correction are performed as background operations. The default setting for all objects in the cluster is No, which means that checksum is enabled. |
| IOPS limit for object | Defines the IOPS limit for an object, such as a VMDK. IOPS is calculated as the number of I/O operations, using a weighted size. If the system uses the default base size of 32 KB, a 64-KB I/O represents two I/O operations. When calculating IOPS, read and write are considered equivalent, but cache hit ratio and sequentiality are not considered. If a disk’s IOPS exceeds the limit, I/O operations are throttled. If the IOPS limit for object is set to 0, IOPS limits are not enforced. vSAN allows the object to double the rate of the IOPS limit during the first second of operation or after a period of inactivity. |
When working with virtual machine storage policies, you must understand how the storage capabilities affect the consumption of storage capacity in the vSAN cluster. For more information about designing and sizing considerations of storage policies, see "Designing and Sizing a vSAN Cluster" in Administering VMware vSAN.
How vSAN Manages Policy Changes
vSAN 6.7 Update 3 and later manages policy changes to reduce the amount of transient space consumed across the cluster. Transient capacity is generated when vSAN reconfigures objects for a policy change.
When you modify a policy, the change is accepted but not applied immediately. vSAN batches the policy change requests and performs them asynchronously, to maintain a fixed amount of transient space.
Policy changes are rejected immediately for non-capacity related reasons, such as changing a RAID5 policy to RAID6 on a five-node cluster.
You can view transient capacity usage in the vSAN Capacity monitor. To verify the status of a policy change on an object, use the vSAN health service to check the vSAN object health.
