4.1 Explain how Storage Polices Work
What is a storage policy?
vSAN storage polices 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.
vSAN requires that the virtual machines deployed on the vSAN datastores are assigned at least one storage policy. When provisioning a virtual machine, if you do not explicitly assign a storage policy to the virtual machine the vSAN Default Storage Policy is assigned to the virtual machine.
How do they work?
You can create a storage policy that defines storage requirements for a VM and its virtual disks. In this policy, you reference storage capabilities supported by the vSAN datastore.
Those requirements include:
- Number of disk stripes per object – Defines the number of stripes for a VM object such as the VMDK. By default, the value is set to 1. If you choose for example two stripes, the VMDK is stripped across two physical disks.
- Primary level of failures to tolerate (FTT) – Specifies the resilience of the object inside the vSAN and the number of faults tolerated. If the value specified is 1, the object can support a single failure. If the value is set to 2, the object can support two failures etc…
- 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 PFTT = 2, and one site is unavailable, then the cluster can tolerate two additional host failures. Default value is 1. Maximum is 3.
- 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.
- 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.
- 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.
- 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.
- Affinity – 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 Affinity rule to None, Preferred, or Secondary. This rule enables you to limit virtual machine objects to a selected site in the stretched cluster. Default value is none.
- 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%.
- 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.
When you assign a user-defined storage policy to a datastore, vSAN applies the settings for the user-defined policy on the specified datastore. At any point, you can assign only one virtual machine storage policy as the default policy to the vSAN datastore.
Characteristics of the vSAN Default Storage Policy
- The vSAN default storage policy is assigned to all virtual machine objects if you do not assign any other vSAN policy when you provision a virtual machine. The VM Storage Policy text box is set to Datastore default on the Select Storage page.
- Note: VM swap and VM memory objects receive the vSAN Default Storage Policy with Force provisioning set to Yes.
-
- The vSAN default policy only applies to vSAN datastores. You cannot apply the default storage policy to non-vSAN datastores, such as NFS or a VMFS datastore.
- Because the default virtual machine storage policy is compatible with any vSAN datastore in the vCenter Server, you can move your virtual machine objects provisioned with the default policy to any vSAN datastore in the vCenter Server.
- You can clone the default policy and use it as a template to create a user-defined storage policy.
- You can edit the default policy, if you have the StorageProfile.View privilege. You must have at least one vSAN enabled cluster that contains at least one host. Typically you do not edit the settings of the default storage policy.
- You cannot edit the name and description of the default policy, or the vSAN storage provider specification. All other parameters including the policy rules are editable.
- You cannot delete the default policy.
- The default storage policy is assigned when the policy that you assign during virtual machine provisioning does not include rules specific to vSAN.
Most of this objectives content was taken from the VMware Docs website due to the verbose amount of content for the subject. I’ve picked out parts I thought were relevant for this objective. Content came from this link and it’s sub-categories. Using vSAN Policies.