vSAN OSA Storage Policies

In vSAN (VMware vSphere Virtual SAN), storage is organized through an object-based framework, where data linked to virtual machines (VMs) is stored as individual objects within a container. Each of these objects is further segmented into smaller units known as components. Here’s an enhanced explanation of these concepts:

vSAN Objects

VM Home Namespace: This object comprises all the VM’s configuration files, including VMX, NVRAM, and log files.
VM Swap Object(s): When a VM is powered on, a swap object is created to manage the memory that is swapped out of the virtual machine.
Virtual Hard Disk (VMDK): This object represents the VM’s virtual disk, housing the machine’s data.
Snapshots: Each snapshot of a VM produces additional objects that capture the state and data of the VM at the moment the snapshot was taken.

Concept of a VM Snapshot Chain in OSA

You can hear at times, the VM admins say to keep snapshots for a max of 48 hours before removing them.

When we create a snapshot, the parent disk or base disk is converted into a read-only state, creating a new delta disk or child disk. Writes now occur to this delta disk, now assume that a few more snapshots are taken so now the VM has to traverse through multiple disk layers to read all the delta disk and the parent disk to verify which data is changed in the chain. This path formation leads to performance degradation and ultimately snapshot consolidation issues.

vSAN Components

Definition: A component is a smaller, discrete fragment of an object. Objects are divided into components to enhance data distribution across the cluster and streamline managing large volumes of data.
Size Limitation: A single component can grow to a maximum size of 255 GB. If a VMDK file (virtual disk) is 300 GB, it cannot be stored as a single component because it exceeds the 255 GB limit. Instead, vSAN divides it into at least two components: one component of 255 GB and another of 45 GB. This is similar to adding an extent to a VMFS datastore.
eg: If we have created a VM with RAID1, then the storage policy would have created two components on multiple ESXi hosts as shown below. As its raid 1, the components are getting mirrored across and of the two components, one component will be authoritative.

vSAN Witness

A witness is a metadata component and is used as a tiebreaker to avoid split-brain scenarios, also known as quorum in other technologies. Quorum runs on a voting rule, the above components are getting mirrored across and of the two components, one component will be authoritative. We need an odd number of components to establish a quorum and the witness maintains the voting between them. If we lose one ESXi host, our data remains accessible on a RAID 1 policy due to the witness..

Storage Policy Based Management ( SPBM )

vSAN allows administrators to define storage policies that govern how components are distributed across the physical storage devices within the cluster. These policies are applied to objects and can control factors such as replication (for redundancy), striping (to boost performance), and fault tolerance.
SPBM advertises storage arrays’ data transfer capabilities thus responsible for bidirectional communication between the vCenter, ESXi and Storage Arrays. Storage providers communicate via an http interface between vCenter, ESXi and a storage array thus as shown the URL is registered with vCenter when a vSan is configured.

vSAN Storage Policy

Every virtual machine in a vSAN datastore needs a storage policy. If you don’t choose one when setting up a VM, vSAN will automatically use a default policy. This default policy is pretty basic—it can handle one failure without losing data (Failures to Tolerate of 1), uses a single disk stripe per object, and thin-provisions the virtual disks to save space.

However, it’s a good idea to create your own storage policies, even if they’re similar to the default one. Doing this gives you more control and ensures your virtual machines are set up exactly how you need them to be.

By making your own storage policies, you can adjust settings to match your specific needs, like adding more redundancy, improving disk performance, or choosing how storage is allocated such as the choice of RAID etc, how space efficient we need our array to be. This way, your virtual machines will run smoothly and efficiently, tailored to your specific requirements.

You can create multiple storage policies in vSAN based on your site’s disaster tolerance settings and the Failures to Tolerate (FTT) settings and these are applied to VM’s.

Site Disaster Tolerance:

This setting determines the type of vSAN environment you’re creating:

Standard Cluster: A typical vSAN setup within a single site.
Stretched Cluster: A vSAN configuration that spans two sites, providing data redundancy across locations for higher availability.
Two-Node Cluster: A minimal setup where data is mirrored between two nodes, ideal for smaller environments that still need redundancy.

Failures to Tolerate (FTT):

This setting specifies how many failures (like disk or host failures) an object can withstand without losing data. For example:

FTT of 1: The object can tolerate one failure.
FTT of 2: The object can tolerate two failures, providing resilience.
FTT of 3: The object can tolerate three failures, providing even greater resilience.

By combining these settings, you can create customized storage policies that align with your specific disaster recovery needs and the level of fault tolerance you require for your virtual machines.