vSAN Storage Policies inside out – Part 1

As vSAN is a policy-based storage system, storage policies play an active role in how storage objects are stored in a vSAN datastore. If you require prior knowledge of the basic concepts of vSAN, please look at my other post on vSAN architectural details.

Storage Objects

There are three things that a storage policy is generally responsible for:

  1. Storage policies in vSphere, construct storage objects to be stored in the underlying datastore.
  2. Storage policies are used to maintain a certain level of service.
  3. Storage policies are used to leverage VASA to use specific capabilities.

When storing objects on a vSAN datastore, there are three things that require attention, 2 replica objects, and one witness object. To ensure accessibility, vSAN uses a quorum-based architecture. For instance, if we consider a VMDK of 100 GB.

Components are the actual data, and witness is just metadata acting as a tiebreaker. In this architecture, if one of the hosts containing the replica experience failure, a quorum will be formed between a component and a witness object, making sure the availability of data.

vSAN Storage Policy

when looking at the vSAN storage policy, there are 4 distinct options to consider.

Availability

In the availability section, you are required to choose your disaster site policy, whether, you’ll go with the standard cluster option or stretched cluster. In the case of a stretched cluster, do you also require local redundancy and remote redundancy together? These are the questions you’ll be faced when tackling with vSAN storage policies. You will also deal with FTT, the option that specifies host failure to tolerate.

  • None – Standard Cluster: That means, you’ll have a local vSAN cluster with no remote availability and replication.
  • Host Mirroring: That is a 2-node cluster, generally used for branch offices. That requires a witness host in the third datacenter.
  • Site Mirroring – Stretched Cluster: That’s an N+N+1 cluster stretched between 2 datacenters for disaster avoidance. All the VMs associated with this storage policy will have their replica on the remote site. (Local + Remote Redundancy)
  • None – Keep Data on Preferred (Stretched Cluster): That’s an option where you’ll have a stretched cluster, but VMs associated with this storage policy will not have remote redundancy. (Local Redundancy) No protection across datacenters.
  • None – Keep Data on Secondary (Stretched Cluster): That’s an option where VMs associated with this policy will only have remote redundancy. (Remote Redundancy) No protection across datacenters.

  • None – Stretched Cluster: That’s an option where objects will be stored across the two datacenters. That means files of a particular VM can span across hosts in two datacenters.

with this option, a performance penalty is one of the consequences. Besides, intersite link failure will result in object accessibility.

In the coming blogpost, we’ll continue with other parts of vSAN storage policies. I hope this’s been informative for you.

Leave a Reply

Your email address will not be published.