vSAN storage policies specify the amount of storage required for your virtual machines.
These policies govern how virtual machine storage objects are provided and allocated within the datastore, ensuring the required level of service. When you enable vSAN on a host cluster, a single vSAN datastore is created and assigned the default storage policy.
When you understand your virtual machines' storage requirements, you can design a storage policy that references the datastore's advertised capabilities. You can construct many policies to address different types or classes of requirements.
Each virtual machine deployed to vSAN datastores receives at least one virtual machine storage policy. When you create or edit virtual machines, you have the option to assign storage policies.
If you do not assign a storage policy to a virtual machine, vSAN uses the default policy. Failures to tolerate is set to one in the default policy, which also includes a single disc stripe per object and a thinly provisioned virtual disc.
The VM swap object and the VM snapshot memory object follow the storage rules specified to each VM, with Failures to tolerate set to 1. They may not be as available as other objects with a policy that specifies a different value for Failures to tolerate.
If vSAN Express Storage Architecture is enabled, each snapshot does not create a new object. A single vSAN object contains both the base VMDK and its snapshots. In addition, in vSAN ESA, the digest is supported by a vSAN object. This differs from vSAN's Original Storage Architecture.
The first two policies are of type Availability
🪩 Failures to tolerate (FTT)
specifies how many device and host failures a virtual machine object can withstand. Every piece of data is saved in n+1 locations, including parity copies if RAID-5 or RAID-6 is being used, for a total of n failures allowed.
It is necessary to have 2n+1 fault domains with hosts providing capacity if fault domains are established. A host is regarded as having its own single-host fault domain if it is not a part of a fault domain.
You can choose a data replication technique that maximises capacity or performance. Although RAID-1 (Mirroring) requires more disc capacity to store object components, it offers faster object access. Erasure coding, or RAID-5/6, reduces disc space usage but degrades performance. One of the following choices is available to you:
- No data redundancy: If you do not want a single mirror copy of virtual machine objects to be protected by vSAN, select this option. This implies that your data is not safeguarded and that you could lose it in the event that a device fails in the vSAN cluster. Unusual delays may occur when the host enters maintenance mode. The reason for the delays is that in order for the repair operation to be completed, vSAN needs to remove the object from the host.
- No data redundancy with host affinity: To execute vSAN Shared Nothing Architecture (SNA) workloads on the vSAN Data Persistence Platform, you must select this option.
- 1 failure - RAID-1 (Mirroring): If your virtual machine object can withstand a single host or device failure, select this option. Using RAID-1 (Mirroring) with a FTT of 1 to protect a 100 GB virtual machine object uses 200 GB.
- 1 failure - RAID-5 (Erasure Coding): If your virtual machine object can withstand a single host or device failure, select this option. 133.33 GB are used by vSAN OSA to protect a 100 GB virtual machine object using RAID-5 (Erasure Coding) with a FTT of 1. Depending on the cluster size, vSAN Express Storage Architecture generates an optimised RAID-5 format. vSAN generates a RAID-5 (2+1) format if the cluster has fewer than six hosts. In the event that there are six or more hosts, vSAN generates a RAID-6 (4+1) format. After 24 hours of the configuration adjustment, vSAN automatically resizes the format when the cluster size eventually grows or decreases.
- 2 failures - RAID-1 (Mirroring): If your virtual machine object can withstand up to two device failures, select this option. There is a capacity overhead because RAID-1 (Mirroring) requires a FTT of 2. Using RAID-1 (Mirroring) with a FTT of 2 to protect a 100 GB virtual machine object uses 300 GB.
- 2 failures - RAID-6 (Erasure Coding): If your virtual machine objects can withstand up to two device failures, select this option. It takes 150 GB to use RAID-6 (Erasure Coding) with a FTT of 2 to secure a 100 GB virtual machine object.
- 3 failures - RAID-1 (Mirroring): If your virtual machine objects can withstand up to three device failures, select this option. It takes 400 GB to use RAID-1 (Mirroring) with a FTT of 3 to protect a 100 GB virtual machine object. vSAN makes a single mirror copy of the virtual machine objects if you create a storage policy without setting a value for FTT. It is able to withstand one failure. Your data could be at danger, though, if several parts fail.
🪬 Site disaster tolerance
This policy governs the type of cluster used: standard, stretched, or 2-node. When configuring a vSAN stretched cluster, you can specify whether data should be mirrored across both sites or only on one. Additionally, host affinity can be set to store data primarily on either the Preferred or Secondary site.
🎀 Cluster Type and Behaviour Options
- 🛝 Standard Cluster (None): Default setting with no disaster recovery across sites.
- 🎎 2-Node Cluster (Host Mirroring): Specifies how many extra failures an object can endure beyond the failures set by FTT (Failures To Tolerate). Data is mirrored at the disk group level, and each data host must have a minimum of three disk groups or three disks in a pool to apply this rule.
- 🪢 Stretched Cluster (Site Mirroring): Defines the number of additional host failures that an object can withstand beyond the FTT threshold.
🎚️ Data Placement Preferences in Stretched Clusters
- 🧶 Preferred Site Only (None): Stores data exclusively on the Preferred site without site-level failure protection. Ideal when you want data access restricted to the designated primary location.
- 🧩 Secondary Site Only (None): Stores data solely on the Secondary site. These objects remain accessible even if failures occur in the Inter-Switch Link (ISL) or the witness host, as long as the selected site is operational.
- 🪞 No Site Mirroring (None): Disables site failure tolerance and may lead to inaccessibility if either site goes down. This mode can generate excessive ISL traffic and cause latency issues for mirrored objects. Recommended only for temporary use when the cluster faces resource constraints (CPU, memory, or storage).
The next three policies are of type Storage rules
🔐 Encryption Services
Specifies the encryption method for virtual machines (VMs) deployed to the datastore. The available options are:
- Data-at-Rest Encryption: Enables encryption for data stored in the datastore to ensure confidentiality.
- No Encryption: Disables all forms of encryption for stored data.
- No Preference: Applies both encrypted and non-encrypted configurations. vSAN manages encryption policies automatically.
📦 Space Efficiency
Defines data reduction settings for VMs within the datastore to optimize storage utilization. Select one of the following options:
Deduplication and Compression
Enables both deduplication and compression mechanisms to minimize storage footprint.-
Compression Only
Applies compression without deduplication.- On vSAN Original Storage Architecture, this is a cluster-level configuration.
- On vSAN Express Storage Architecture, compression operates at the object level, allowing selective compression per VM.
No Space Efficiency
Disables both deduplication and compression for VM objects.No Preference
Automatically applies all available space efficiency settings based on vSAN’s internal optimization logic.
🗂️ Storage Tier
Specifies the storage tier compatibility for all VMs governed by the assigned storage policy:
- All-Flash: Ensures VM compatibility exclusively with all-flash storage infrastructure.
- Hybrid: Ensures VM compatibility exclusively with hybrid storage configurations.
- No Preference: Enables VM compatibility with both all-flash and hybrid storage environments.
The last six policies are of type Advanced Policy Rules
💽 Number of Disk Stripes per Object
Specifies the minimum number of capacity devices across which each replica of a virtual machine (VM) object is distributed.
- Higher stripe counts may improve performance but increase resource consumption.
- Default: 1; Maximum: 12
- Modification of the default value is generally not recommended.
In hybrid configurations, disk stripes span magnetic disks. In all-flash environments, striping is applied across flash devices within the capacity layer. Ensure adequate capacity devices are available in the vSAN cluster to support stripe configurations.
⚙️ IOPS Limit for Object
Defines the maximum allowable IOPS (Input/Output Operations Per Second) for objects such as VMDKs.
- IOPS is calculated using a weighted size model. For example, with a base size of 32 KB, a 64-KB I/O equals two operations.
- Read and write operations are treated equally; however, cache hit ratios and sequential access patterns are not considered.
- When the IOPS limit is exceeded, vSAN applies throttling.
- A value of 0 disables IOPS enforcement.
vSAN permits burst performance—doubling the IOPS limit during the first second or following an idle period.
📊 Object Space Reservation
Determines the percentage of a VM disk object's logical size that must be reserved at deployment time. This corresponds to thick provisioning options. Available settings include:
- Thin provisioning (default)
- 25% reservation
- 50% reservation
- 75% reservation
- 100% reservation (Thick provisioning)
⚡ Flash Read Cache Reservation (%)
Allocates a portion of flash storage as read cache for a VM disk object, specified as a percentage of its logical size.
- Reserved flash capacity is dedicated and cannot be shared.
- Default: 0%; Maximum: 100%
This setting is only applicable in hybrid vSAN configurations; it is unsupported in all-flash or vSAN Express Storage Architecture (ESA) environments.
Unreserved cache is dynamically and fairly distributed. In most cases, the default value yields optimal performance. Over-provisioning cache reservations can result in inefficient use of flash storage and may negatively impact workload performance.
🔍 Disable Object Checksum
Indicates whether checksum validation is enabled for a VM object’s data integrity.
- No (default): Enables checksum validation.
- Yes: Disables checksum validation.
Checksum operations verify data during read/write processes and facilitate automatic repair in case of mismatches. In vSAN ESA environments, checksum functionality is always enabled and cannot be disabled.
🚨 Force Provisioning
Allows provisioning of VM objects even when the specified storage policy cannot be fulfilled due to constraints in the datastore.
- Yes: Enables forced provisioning, useful during bootstrapping or outages.
- No (default): vSAN enforces standard policy compliance; VM provisioning fails if requirements are unmet, though the policy itself is successfully created.
Understanding the influence of these storage policy parameters is critical for managing resource consumption and optimizing performance within a vSAN cluster.
Top comments (0)