vSAN storage polices define storage requirements for your virtual machines. These policies guarantee the required level of service for your VMs because they determine how storage is allocated to the VM.
VMware Cloud on AWS includes two vSAN datastores, one for the management VMs (vsanDatastore) and one for the workload VMs (WorkloadDatastore). Both datastores share the same underlying storage devices and consume from the same pool of free space.
Each virtual machine deployed to a vSAN datastore is assigned at least one virtual machine storage policy. You can assign storage policies when you create or edit virtual machines.
Storage policies have availability attributes and advanced attributes.
Availability Attributes for vSAN VM Storage Policies
- Site disaster tolerance
- Defines the data redundancy method used by stretched clusters to handle a site failure. This attribute applies to stretched clusters. If you have a standard vSAN cluster, choose None (standard cluster).
The options are:
- None (standard cluster)
- Dual-site monitoring (stretched cluster)
- None-Keep data on primary (stretched cluster)
- None - Keep data on secondary (stretched cluster)
- Failures to tolerate
Defines the number of host and device failures that a virtual machine can tolerate. You can choose to have no data redundancy, or select a RAID configuration optimized for either performance (Mirroring) or capacity (Erasure Coding).
Table 1. RAID Configurations, FTT, and Host Requirements RAID Configuration Failures to Tolerate (FTT) Minimum Hosts Required RAID-1 (Mirroring) This is the default setting. 1 3 RAID-5 (Erasure Coding) 1 4 RAID-1 (Mirroring) 2 5 RAID-6 (Erasure Coding) 2 6 RAID-1 (Mirroring) 3 7
The initial number of hosts in a cluster and the way in which hosts are added to or removed from a cluster affects its RAID configuration. For example, a three-host cluster is initially configured with RAID 1. When you add a host, you can reconfigure the cluster for RAID-5, but that reconfiguration is not automatic. A four-host cluster is initially configured with RAID-5. See Storage Capacity and Data Redundancy for details.
Advanced Attributes for vSAN VM Storage Policies
- Number of disk stripes per object
- 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. Change the default value only when recommended by VMware support.
- 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.
- 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.
Default value is 0%. Maximum value is 100%.
- 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 vSAN 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.
- 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.
- 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.
Storage Policies and SLA Requirements
When working with virtual machine storage policies, it's important to understand how they affect the consumption of storage capacity in the vSAN cluster and whether they meet the requirements defined in the Service Level Agreement for VMware Cloud on AWS (the SLA).
The default vSAN storage policy is initially configured based on the number of hosts in the cluster. For example, a three-host cluster defaults to FTT=1 using the Raid-1 Mirroring policy. A four-host cluster also defaults to FTT=1 but uses the more space-efficient Raid-5 Erasure Coding policy. Clusters with more than six i3.metal hosts in a single AZ default to FTT=2 using the Raid-6 Erasure Coding policy. You can create custom policies that align data availability with the needs of your underlying data, but workload VMs with storage policies that do not meet the requirements set forth in the Service Level Agreement may not qualify for SLA Credits. The VM Storage Policy must be configured with the appropriate level of protection. Ephemeral workloads may use the No Data Redundancy policy to save capacity, foregoing any SLA guarantees of availability.
When scaling an i3.metal cluster up from five to six hosts, you must update the underlying policy configuration to FTT=2 using either Mirroring or Erasure Coding to compensate for the larger failure pool. Continued use of FTT=1 for this host configuration means that VMware cannot guarantee availability per the service definition guidance. R5.metal clusters using Elastic vSAN are able to sustain the SLA with FTT=1 regardless of cluster size.
For more information about designing and sizing considerations of storage policies, see the Administering VMware vSAN documentation.