VCF 9 Storage Architecture: Designing Around Policy, Not Datastores

The old storage design question was usually “which datastore should this VM live on?” That still matters when you are dealing with external arrays, VMFS, or NFS. But in a modern VMware Cloud Foundation (VCF) design with vSAN, the better first question is:

What policy promise does this workload need?

That policy promise decides failure tolerance, RAID layout, placement, capacity overhead, rebuild behavior, and whether a workload is being optimized for latency, resilience, or usable capacity. The datastore becomes the storage pool. The policy becomes the service definition.

Workload requirement
  -> storage policy
    -> FTT and RAID method
      -> object placement
        -> capacity overhead, rebuild scope, and operational risk

This is why VCF storage architecture is not just a sizing exercise. A cluster with enough raw TB can still be a poor design if the policies cannot survive the failures, maintenance windows, and rebuild behavior the platform is expected to handle.

Policy first, datastore second

A vSAN datastore is shared cluster capacity. A vSAN storage policy tells vSAN how each VM object should be protected and placed. That difference is the architectural pivot.

In a traditional datastore conversation, you might create gold, silver, and bronze datastores. Each datastore has a fixed protection and performance profile. In vSAN, you can keep the same mental labels, but they should map to policies rather than LUNs.

The FTT decision

Failures to tolerate (FTT) is the most important policy setting because it defines what failure the object should survive. The exact meaning depends on the cluster topology.

In a standard vSAN cluster, FTT usually means host or device failures. In a stretched cluster, site disaster tolerance handles the site-level promise, while secondary FTT (SFTT) handles protection inside each data site.

Standard cluster

  FTT=1 means:
    survive one host, disk, or fault-domain failure

Stretched cluster

  Site disaster tolerance means:
    survive preferred-site or secondary-site failure

  SFTT=1 means:
    also survive a local host/device failure inside a data site

That distinction matters because a stretched policy can become expensive very quickly. Site mirroring with no local SFTT is roughly 2x data. Site mirroring with local SFTT=1 RAID-1 can become roughly 4x data because each site keeps local mirrors.

RAID is the method, not the goal

RAID-1, RAID-5, and RAID-6 are implementation choices. The business goal is the failure promise and workload behavior.

Broadcom’s VCF 9.1 documentation describes ESA Auto-RAID behavior where the policy can select an appropriate layout based on the cluster shape. That is useful, but it does not remove the architecture decision. You still need to know whether the resulting promise matches the workload.

Possible/manual protection layouts

Capacity planning should always start with logical data and then apply policy overhead. A clean 100 GB example keeps the math honest. This table shows common protection shapes you may discuss or manually select; it is not the Auto-RAID decision table.

VCF 9.1 ESA Auto-RAID decisions

Auto-RAID is more specific than “pick any efficient layout.” Current VCF 9.1 ESA behavior is easier to reason about as its own table:

The trap is designing to raw capacity instead of effective capacity. If you buy 100 TB raw and plan every production VM as if it were 100 TB usable, the policy bill arrives later as an outage, a failed maintenance evacuation, or a cluster that cannot rebuild after a host loss.

Diagram: same datastore, different promises

This is the design shift in one picture. The datastore is shared, but the VMs can have different object layouts because their policies are different.

                    vSAN datastore / storage pool
  ┌─────────────────────────────────────────────────────────────┐
  │                                                             │
  │  VM: SQL01                 VM: WEB01            VM: LAB01   │
  │  Policy: FTT=1 RAID-1      Policy: FTT=1 RAID-5 Policy: FTT=0
  │                                                             │
  │  ┌──────┐ ┌──────┐         ┌────┐┌────┐┌────┐   ┌──────┐   │
  │  │copy A│ │copy A│         │D1  ││D2  ││P1  │   │copy A│   │
  │  └──────┘ └──────┘         └────┘└────┘└────┘   └──────┘   │
  │                                                             │
  └─────────────────────────────────────────────────────────────┘

  One datastore does not mean one protection model.

That is why VCF private cloud teams should publish policy-backed storage classes rather than asking application owners to pick random datastore names.

Rebuild behavior changes the design

FTT and RAID overhead are visible at provisioning time. Rebuild behavior shows up when something goes wrong or when maintenance takes longer than planned.

When a host, disk group, or capacity device fails, vSAN tries to bring affected objects back into policy compliance. The amount of work depends on the policy layout and the failure scope.

For planned host maintenance, the key question is not only “will the VMs stay up?” It is “will the cluster still have enough capacity and placement options to restore the policy if the host does not return on time?”

Before failure: FTT=1 RAID-1

  Host 1          Host 2          Host 3
  ┌──────┐        ┌──────┐        ┌─────────┐
  │copy A│        │copy A│        │ witness │
  └──────┘        └──────┘        └─────────┘

Host 2 fails:

  Host 1          Host 2          Host 3          Host 4
  ┌──────┐        ┌──────┐        ┌─────────┐     ┌──────┐
  │copy A│        │down  │        │ witness │ --> │copy A│
  └──────┘        └──────┘        └─────────┘     └──────┘

Rebuild consumes capacity, network, CPU, and device write endurance.

Workload requirements drive policy selection

The cleanest policy design starts from workload requirements, not a preferred RAID layout. Ask what the workload actually needs.

Here is a practical mapping for a VCF workload domain:

Management appliances      -> gold-ftt1-raid1
Tenant databases           -> gold-ftt1-raid1 or gold-ftt2-raid6
General app servers        -> silver-ftt1-raid5
VDI replicas / rebuildable -> bronze-ftt0 or bronze-ftt1 depending on RTO
Backup repositories        -> capacity-ftt1-raid5, sized for ingest and restore
Stretched critical apps    -> stretched-site-mirror-sftt1 when the sites support it

The important bit is that every line has an operational reason. “RAID-5 because it saves space” is incomplete. “RAID-5 because this workload is read-heavy, capacity-sensitive, and can tolerate parity rebuild behavior” is a design decision.

A policy audit snippet

Once policies are published, audit them like any other platform contract. This kind of PowerCLI snippet is useful before a design review or migration wave.

$clusterName = "WLD01-CL01"

Get-Cluster $clusterName | Get-VM | ForEach-Object {
  $vm = $_
  Get-SpbmEntityConfiguration -VM $vm | Select-Object `
    @{n="VM";e={$vm.Name}},
    @{n="Policy";e={$_.StoragePolicy.Name}},
    ComplianceStatus
} | Sort-Object Policy, VM | Format-Table -AutoSize

For a deeper operational check, pair policy inventory with resync and capacity state.

esxcli vsan debug resync summary get
esxcli vsan health cluster list

You are looking for mismatches:

• Critical VMs using a default or unknown policy.
• Capacity-heavy workloads using RAID-1 without a latency reason.
• Stretched workloads missing a clear site tolerance decision.
• Large policy changes queued during business hours.
• Resync already active before planned maintenance begins.

Design checklist

Before signing off a VCF storage architecture, answer these plainly:

1. Which workload classes exist, and what storage promise does each class need?
2. Which policies map to those classes?
3. What is the effective usable capacity after policy overhead?
4. What happens when the largest host or fault domain fails?
5. Can the cluster rebuild while staying within free-space and network budgets?
6. Which policies are allowed in management domains, workload domains, and stretched sites?
7. Who can create or change policies, and how are changes reviewed?
8. What dashboards or scripts prove that VMs are compliant with the intended policy?

The architecture is not finished when the datastore is mounted. It is finished when the policy catalog, capacity model, and rebuild plan all describe the same reality.

The takeaway

VCF 9 storage architecture should be designed around policy because policy is where the platform promise lives. FTT defines what can fail. RAID defines how the promise is implemented. Capacity overhead tells you what the promise costs. Rebuild behavior tells you what the promise costs under stress. Workload requirements tell you whether the promise is appropriate in the first place.

Design from that chain and the datastore stops being a mysterious bucket of TB. It becomes a platform service with clear contracts.

Official references

• About vSAN policies in VCF
• What are vSAN default storage policies
• Selecting the best RAID configuration for a vSAN storage cluster
• Auto-RAID in VMware vSAN for VCF 9.1
• vSAN deployment, administration, and monitoring in VCF