The old shortcut was simple: RAID-1 for performance, RAID-5/6 to save capacity. vSAN ESA changes the write path behind that trade-off, but it does not turn a vendor claim into a physical law. Choosing a policy in VCF 9.1 requires understanding the mechanism, its capacity cost, and the caveat that remains in current documentation.
The running example is vcf-par-01 at Nordwind Logistics. Its cl-fret-prod-01 cluster has 8 hosts and 4 fault domains; cl-fret-dens-01 has 4 hosts. Those numbers frame the study but cannot establish the policy actually applied. Read it from the target environment.
A limitation, not an editorial blocker
No local benchmark was run. The mechanisms and values below come from Broadcom documentation; performance on a specific platform still needs verification in a lab or test platform. This article can guide a decision, but it does not claim to publish a Nordwind measurement.
TL;DR
- ESA coalesces writes in vSAN LFS, protects them in a durable log, then produces aligned full-stripe writes for RAID-5 or RAID-6.
- Broadcom has claimed since 2022 that this path removes the historical penalty, but TechDocs 9.1 still says RAID-1 needs fewer I/O operations and can perform better.
- The right policy combines resilience, host count, capacity factor, and workload measurement; the slogan is not a substitute for a test.
OSA and ESA organise drives differently
In OSA, a disk group combines one flash cache device with one or more capacity devices. In ESA, devices claimed by vSAN form one storage pool per host and all contribute to capacity and performance. That architectural difference matters more than the RAID label in isolation.
ESA introduces the vSAN Log-Structured File System, or LFS. Broadcom says LFS ingests new data, coalesces writes, and prepares an efficient full-stripe write. It also stores metadata with the flow instead of reconstructing parity for every small change.
DOCUMENTÉ — what the write path does
Incoming I/O is coalesced, packaged with metadata, and written to a durable log tied to the object. It is briefly protected as a 2-way or 3-way mirror, depending on policy, before the VM receives acknowledgement. The capacity leg then receives an aligned full-stripe write matching RAID-5 or RAID-6.
Alignment is the central point: the documented path avoids the read-modify-write sequence that makes another approach read old content and old parity before rewriting. ESA does not remove parity computation, physical writes, or metadata. It reorganises the work so that every small write does not pay that sequence.
What Broadcom claims—and what the documentation qualifies
Two Broadcom posts from 2022 state the promise directly: RAID-5/6 without a performance compromise, or even without a penalty. They describe the preceding mechanism and recommend erasure coding for cluster sizes that support the required layouts.
Current VCF 9.1 product documentation adds a critical counterpoint. It says RAID-1 mirroring requires fewer I/O operations to storage devices, can therefore provide better performance, and can shorten a resynchronisation, for example. The same page says its general comparison covers both OSA and ESA.
À_VALIDER_EN_LAB — a documentation tension
No reviewed source publishes a same-hardware comparison of ESA RAID-5/6 and ESA RAID-1. Nor does a reviewed 9.0 or 9.1 page reconcile the 2022 claim with the TechDocs 9.1 caveat. Latency, IOPS, throughput, and CPU cost therefore need verification against a representative data set.
RECONSTITUTION: the mechanism explains why ESA reduces the historical cost of erasure coding; it does not prove universal equality. Both statements could coexist if the gap is negligible for some profiles and visible for others. Going further without comparable measurements would be speculation.
The capacity cost is published
For a standard ESA cluster, the current table gives these layouts:
| Policy | Layout | Minimum hosts | Overhead |
|---|---|---|---|
| RAID-1, FTT=1 | 2 mirrors | 3 | 2x |
| RAID-5, FTT=1 | 2+1 | 3 | 1.5x |
| RAID-5, FTT=1 | 4+1 | 6 | 1.25x |
| RAID-6, FTT=2 | 4+2 | 6 | 1.5x |
For FTT=1, TechDocs also gives an example where RAID-1 needs 2 times the virtual disk size, compared with 1.33 times for RAID-5. That second figure belongs to its example and must not replace the 1.5x factor for the ESA 2+1 layout in the table.
VCF 9.1 adds Auto-RAID. For a standard cluster, Broadcom publishes this mapping:
- fewer than 3 hosts: FTT=0, factor 1.0x;
- 3 to 5 hosts: FTT=1, RAID-5, factor 1.5x;
- 6 hosts or more: FTT=2, RAID-6, factor 1.5x.
New clusters use Auto-RAID by default. Existing clusters retain their policy and can receive a health alert recommending migration. This is why the 8 hosts in cl-fret-prod-01 do not establish its effective state by themselves—and its 4 fault domains are another reason to read rather than assume it.
The selected factor then feeds the ESA effective-capacity formula. That is where RAID becomes a measurable budget decision.
Decide without waiting for a permanent lab
The absence of a test platform does not prevent an honest architecture rule. It changes the confidence level.
- Read actual state. Record topology, fault domains, effective policy, and RAID Factor.
- Set the resilience need. Choose FTT before optimising capacity.
- Calculate capacity. Use documented overhead without assuming data reduction.
- Classify the workload. Writes, block sizes, queue depth, and resynchronisation belong in the test plan.
- Qualify before generalising. A temporary test platform, pilot, or controlled window is enough to verify hardware-specific assertions.
HYPOTHÈSE_DE_DESIGN — Nordwind rule
Nordwind adopts Auto-RAID as the starting point but keeps a RAID-1 exception when a comparable test shows that latency or resynchronisation budgets are not met. This operating choice is not a Broadcom prescription.
RÉSULTAT_ATTENDU: the decision record associates each policy with its FTT, capacity factor, and performance evidence from the target hardware. If that evidence does not exist yet, the row says “verify on a test platform” instead of carrying an estimated result.
Mistakes that distort the verdict
- Presenting “no penalty” as a local measurement when it is a Broadcom claim from 2022.
- Reusing an ESA-versus-OSA result to claim a comparison between ESA RAID-6 and ESA RAID-1.
- Inferring policy from host count alone without reading fault domains and inherited policy.
- Mixing ESA storage with NVMe memory tiering: they can compete for the same physical slots but cannot share one device.
- Turning an architectural improvement into a guaranteed resynchronisation or upgrade duration.
This caution fits the broader VCF 9 architecture: automating a choice does not remove the need to preserve its assumptions and evidence.
Conclusion
The path changes
A durable log and full-stripe write replace the historical read-modify-write sequence.
Cost remains visible
FTT, layout, and RAID Factor provide a verifiable capacity baseline.
Performance is qualified
Documentation guides the test; it does not replace measurement on the target platform.
ESA makes RAID-5/6 much easier to defend as a default policy, but the important word is “defend,” not “guarantee.” The next step is to arbitrate the same NVMe slots between storage and memory: NVMe memory tiering, 2x VM density and its conditions.
Primary sources: vSAN concepts, ESA RAID-5/6 write path, VCF 9.1 RAID comparison, and VCF 9.1 Auto-RAID.
Get the next one by email
New articles and series, sent when they are published. No other mail.
