This chapter is from the book
This chapter is from the book
This chapter is from the book
VM Storage Policies
VM storage policies work in an identical fashion to storage profiles introduced in vSphere 5.0, insofar as you simply build a policy containing your VM provisioning requirements. There is a major difference in how storage policies work when compared to the original storage profiles feature. With storage profiles, you simply used the requirements in the policy to select an appropriate datastore when provisioning the VM. The storage policies not only select the appropriate datastore, but also inform the underlying storage layer that there are also certain availability and performance requirements associated with this VM. So while the VSAN datastore may be the destination datastore when the VM is provisioned with a VM storage policy, settings within the policy will stipulate additional requirements. For example, it may state that this VM has a requirement for a number of replica copies of the VM files for availability, a stripe width and read cache requirement for high performance, and a thin provisioning requirement.
VM storage policies are held inside VSAN, as well as being stored in the vCenter inventory database. Every object stores its policy inside its own metadata. This means that vCenter is not required for VM storage policy enforcement. So if for some reason the vCenter Server is unavailable, policies can continue to be enforced.
Enabling VM Storage Policies
In the initial release of VSAN, VM storage policies could be enabled or disabled via the UI. This option is not available in later releases. However, VM storage policies are automatically enabled on a cluster when VSAN is enabled on the cluster. Although VM storage policies are normally only available with certain vSphere editions, a VSAN license will also provide this feature.
Creating VM Storage Policies
vSphere administrators have the ability to create multiple policies. As already mentioned, a number of VSAN capabilities are surfaced up by VASA related to availability and performance, and it is at this point that the administrator must decide what the requirements are for the applications running inside of the VMs from a performance and availability perspective. For example, how many component failures (hosts, network, and disk drives) does the administrator require this VM to tolerate and continue to function? Also, is the application running in this VM demanding from an IOPS perspective? If so, an adequate read cache should be provided as a possible requirement so that the performance requirement is met. Other considerations include whether the VM should be thinly provisioned or thickly provisioned, if RAID-5 or RAID-6 configurations are desired to save storage space, if checksum should be disabled, or if an IOPS limit is required for a particular VM to avoid a “noisy neighbor” situation.
Another point to note is that since vSphere 5.5, policies also support the use of tags for provisioning. Therefore, instead of using VSAN datastore capabilities for the creation of requirements within a VM storage policy, tag-based policies may also be created. The use of tag-based policies is outside the scope of this book, but further information may be found in the generic vSphere storage documentation.
Assigning a VM Storage Policy During VM Provisioning
The assignment of a VM storage policy is done during the VM provisioning. At the point where the vSphere administrator must select a destination datastore, the appropriate policy is selected from the drop-down menu of the available VM storage policies. The datastores are then separated into compatible and incompatible datastores, allowing the vSphere administrator to make the appropriate and correct choice for VM placement.
This matching of datastores does not necessarily mean that the datastore will meet the requirements in the VM storage policy. What it means is that the datastore understands the set of requirements placed in the policy. It may still fail to provision this VM if there are not enough resources available to meet the requirements placed in the policy. However, if a policy cannot be met, the compatibility section in the lower part of the screen displays a warning that states why a policy may not be met.
This three-node cluster example shows a policy that contains a number of failures to tolerate = 2. A three-node cluster cannot meet this policy, but when the policy was originally created, the VSAN datastore shows up as a matching resource as it understood the contents of the policy. However, on trying to use this policy when deploying a VM, the VSAN datastore shows up as noncompliant, as Figure 4.11 demonstrates.
)
Figure 4.11 The VSAN datastore is shown as noncompliant when a policy cannot be met
This is an important point to keep in mind: Just because VSAN tells you it is compatible with a particular policy when that policy is originally created, this in no way implies that it can deploy a VM that uses the policy.