4.3 vSAN Storage Policies & Data Protection

4.3 vSAN Storage Policies & Data Protection

Traditional enterprise SAN storage models enforce data availability and performance policies at the coarse granularity of a physical LUN or shared NFS volume. In this legacy approach, every virtual machine residing on that datastore inherits identical redundancy, caching, and RAID levels regardless of its actual workload requirements.

VMware vSAN replaces this rigid paradigm with Storage Policy Based Management (SPBM). In vSAN, storage availability, performance, and data protection rules are configured as software policies in vCenter Server and applied dynamically at the granular level of individual virtual machines or virtual disks (VMDKs).

---

vSAN Storage Objects & Components

Every virtual machine provisioned on a vSAN datastore is decomposed into distinct, self-contained storage objects. An object is a logical volume with its own storage policy requirements, composed of one or more physical components distributed across the cluster:

1. VM Home Namespace Object: Contains the VM configuration file (.vmx), log files (vmware.log), descriptor files, and snapshot metadata files.
2. VMDK Data Object: The virtual hard disk file storing the guest operating system and user data.
3. VM Swap Object: Created dynamically when a virtual machine is powered on, sized equal to the unreserved portion of the VM's configured virtual RAM.
4. Snapshot Delta Object: Created when a virtual machine snapshot is taken to record incremental data changes.
5. Memory Object: Created when a virtual machine snapshot captures the active memory state or when a VM is suspended.

Component Boundaries and Chunking Rules

• Maximum Component Size: In the Original Storage Architecture (OSA), a single component cannot exceed 255 GB. If an administrator provisions a 1 TB VMDK, vSAN automatically chunks the object into at least four 255 GB components before applying mirroring or striping rules.
• Component Limits: An OSA host supports up to 9,000 components, so very large VMs with wide stripes can hit the per-host limit before they run out of capacity.

---

Failures to Tolerate (FTT) & Failure Tolerance Methods

The core of every vSAN storage policy is the definition of Failures to Tolerate (FTT) paired with a Failure Tolerance Method:

1. Performance: RAID-1 (Mirroring)

RAID-1 creates identical byte-for-byte replicas of data components across different ESXi hosts or fault domains, paired with a witness component to maintain quorum.

• Host Count Formula: Requiring 2n + 1 hosts (where n = FTT):
  • FTT=1: 2 data mirrors + 1 witness = 3 hosts minimum.
  • FTT=2: 3 data mirrors + 2 witnesses = 5 hosts minimum.
  • FTT=3: 4 data mirrors + 3 witnesses = 7 hosts minimum.
• Capacity Consumption Multiplier:
  • FTT=1 consumes 200% (2.0x): A 100 GB VMDK consumes 200 GB of raw storage.
  • FTT=2 consumes 300% (3.0x): A 100 GB VMDK consumes 300 GB of raw storage.
  • FTT=3 consumes 400% (4.0x): A 100 GB VMDK consumes 400 GB of raw storage.
• Workload Profile: Best suited for write-intensive workloads (e.g., transactional databases, high-IOPS messaging queues) because writes only incur a single replica mirror operation without parity calculation penalties.

2. Capacity: RAID-5 / RAID-6 (Erasure Coding)

Erasure Coding breaks data into multiple fragments and calculates distributed mathematical parity blocks across hosts, mimicking traditional hardware RAID-5 and RAID-6 mechanics without requiring dedicated parity drives.

• RAID-5 (3+1 Erasure Coding):
  • Provides FTT=1 protection (tolerates 1 host or drive failure).
  • Deconstructs data into 3 data fragments and 1 distributed parity fragment (3+1).
  • Host Requirement: Requires a minimum of 4 hosts in OSA. vSAN 8 ESA replaces 3+1 with adaptive RAID-5: a 2+1 scheme (1.5x) on clusters of 3 to 5 hosts and a 4+1 scheme (1.25x) on clusters of 6 or more hosts.
  • Capacity Consumption: Consumes only 133% (1.33x): A 100 GB VMDK consumes ~133.3 GB of raw storage, yielding a 33% capacity savings compared to RAID-1.
• RAID-6 (4+2 Erasure Coding):
  • Provides FTT=2 protection (tolerates 2 concurrent host or drive failures).
  • Utilizes double parity: 4 data fragments and 2 distributed parity fragments (4+2).
  • Host Requirement: Strictly requires a minimum of 6 hosts.
  • Capacity Consumption: Consumes only 150% (1.5x): A 100 GB VMDK consumes 150 GB of raw storage, yielding a massive 50% capacity savings compared to RAID-1 FTT=2 (300%).
• Workload Profile: Ideal for read-dominated workloads, web servers, file shares, and archival applications. In OSA, erasure coding incurs a "write penalty" (read-modify-write cycle) during unaligned writes. Erasure coding in OSA is supported only on All-Flash clusters.

+-----------------------------------------------------------------------------+
|                  RAID-1 Mirroring vs. RAID-5 Erasure Coding                 |
+-----------------------------------------------------------------------------+
|                                                                             |
|   [ RAID-1 (Mirroring, FTT=1) - 3 Hosts Min, 200% Capacity ]                |
|   +-------------------+  +-------------------+  +-------------------+       |
|   |   ESXi Host 1     |  |   ESXi Host 2     |  |   ESXi Host 3     |       |
|   | [Data Mirror 1]   |  | [Data Mirror 2]   |  | [Witness Comp]    |       |
|   |     (100 GB)      |  |     (100 GB)      |  |     (Metadata)    |       |
|   +-------------------+  +-------------------+  +-------------------+       |
|                                                                             |
|   [ RAID-5 (Erasure Coding 3+1, FTT=1) - 4 Hosts Min, 133% Capacity ]       |
|   +-----------+  +-----------+  +-----------+  +-----------+                |
|   |  Host 1   |  |  Host 2   |  |  Host 3   |  |  Host 4   |                |
|   |  [Data 1] |  |  [Data 2] |  |  [Data 3] |  |  [Parity] |                |
|   | (33.3 GB) |  | (33.3 GB) |  | (33.3 GB) |  | (33.3 GB) |                |
|   +-----------+  +-----------+  +-----------+  +-----------+                |
+-----------------------------------------------------------------------------+

---

Advanced Policy Rules & Attributes

Beyond basic FTT settings, SPBM allows administrators to fine-tune object performance, striping, and space guarantees:

Number of Disk Stripes Per Object (Stripe Width)

• Range: 1 to 12 (Default is 1).
• Mechanics: Breaks each replica component into smaller sub-components and stripes them across multiple capacity drives within different disk groups or hosts.
• Use Case: If a virtual disk demands higher aggregate IOPS than a single physical capacity flash drive can deliver, increasing the stripe width distributes the queue depth across multiple physical devices. It is also used when a single VMDK component approaches the 255 GB OSA boundary.

Flash Read Cache Reservation

• Range: 0% to 100% (Default is 0%).
• Mechanics: Explicitly locks a percentage of the flash cache device in a hybrid cluster for this specific VMDK object.
• Rule: This setting applies exclusively to hybrid OSA clusters. In all-flash clusters, this setting is completely ignored because all reads are already served from flash capacity media.

Object Space Reservation (OSR)

• Settings: Thin Provisioning (0%, Default) vs. Thick Provisioning (100%).
• Mechanics:
  • At 0%, vSAN dynamically allocates physical storage blocks only as the guest operating system writes to them.
  • At 100%, vSAN pre-allocates and reserves the full logical address space of the object across capacity drives upon creation, preventing "datastore out of space" conditions for mission-critical databases.

IOPS Limit for Object (QoS)

• Mechanics: Imposes a ceiling on the IOPS an individual object can generate. vSAN counts I/Os in 32 KB units (a 64 KB I/O counts as two), which matters when sizing the limit. Useful for multi-tenant environments or "noisy neighbor" mitigation.

Force Provisioning

• Mechanics: Instructs vSAN to provision the virtual machine object even if the cluster currently lacks sufficient hosts or disk groups to satisfy the storage policy's redundancy rules. The object provisions in a Non-Compliant state (e.g., FTT=0) and automatically reconstructs into compliance once additional hosts or drives are added.

---

vSAN Encryption Architecture

VMware vSAN provides native, software-based cryptographic protection without requiring self-encrypting drives (SEDs).

Data-at-Rest Encryption (DRE)

vSAN Data-at-Rest Encryption operates at the hypervisor datastore layer, securing all objects with AES-XTS 256-bit encryption. It utilizes an industry-standard two-tier key management architecture:

1. Key Encryption Key (KEK):
   • Generated and maintained by an external Key Management Server (KMS) compliant with KMIP 1.1+, or by the vSphere Native Key Provider (NKP).
   • The ESXi host obtains the KEK from the key provider and uses it to wrap and unwrap the DEKs.
2. Data Encryption Key (DEK):
   • An internal key generated by the ESXi host per physical disk.
   • Encrypts the actual data blocks written to the storage media.
   • The DEK is encrypted (wrapped) by the KEK and stored in an encrypted header on the physical drive itself.

Data-in-Transit Encryption (DTE)

While Data-at-Rest Encryption protects against physical drive theft, Data-in-Transit Encryption protects data traversing the physical network fabric between ESXi hosts.

• Uses AES-GCM 256-bit encryption on vSAN traffic between hosts.
• Rekeys automatically on a configurable interval (1 day by default).
• Does not require an external KMS; key negotiation is managed natively by vCenter Server.

---

Storage Policy Rules & Overhead Comparison Table