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

In VMware vSAN, snapshots are managed using the Object Storage Architecture (OSA), which is different from traditional snapshot mechanisms. Instead of creating multiple delta disks that can result in performance degradation over time, vSAN OSA snapshots create a new object for each snapshot. This object holds the changes made after the snapshot was taken, and the original object becomes read-only.

One of the key advantages of vSAN OSA snapshots is that they don’t rely on a chain of delta disks, so there is no need to traverse through multiple layers of disks to read or write data. This helps maintain better performance and reduces the risk of bottlenecks commonly seen in traditional snapshot methods.

Each snapshot object is stored separately within the vSAN datastore and is fully integrated into the vSAN’s distributed storage system. This means snapshots benefit from vSAN’s policies, ensuring they are distributed across the cluster for availability and resilience.

While vSAN OSA snapshots provide improved performance and scalability, they still require proper management. If too many snapshots are taken, or if they are not consolidated properly, storage efficiency can be impacted. Periodically consolidating snapshots is essential to prevent storage bloat and ensure that the VM’s storage remains optimized. Overall, vSAN OSA snapshots offer an efficient and scalable solution for managing snapshots in a virtualized environment.

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.