PracticeVideosBlogFlashcards

6.4 vSAN Space Efficiency & Capacity Accounting

Key Takeaways

  • Thin allocation, parity, compression, deduplication and reclamation are different mechanisms.

  • OSA disk-group deduplication differs from ESA 9.0 global deduplication; availability and feature compatibility must be checked.

  • 600 GiB at a simplified 3+1 multiplier requires 800 GiB before other overhead.

  • Efficiency savings do not eliminate operational/rebuild reserves or independent failure-domain requirements.

Last updated: October 2026

Separate the Capacity Mechanisms

The storage blueprint asks why vSAN space efficiency matters. Thin provisioning, erasure coding, compression, deduplication and space reclamation save capacity through different mechanisms. They do not substitute for fault tolerance, backups or operational headroom. A system can show excellent compression while lacking enough free independent capacity to repair a failed host.

Thin provisioning allocates storage as data is written rather than reserving the full logical disk immediately. Erasure coding stores data and parity instead of full mirrored copies. Compression represents suitable content in fewer bytes; deduplication avoids storing identical blocks repeatedly. Reclamation releases storage that no longer needs to hold live data, subject to the relevant filesystem, snapshot and storage layers.

MechanismWhat reduces consumptionCommon misunderstanding
Thin allocationUnwritten logical capacity need not be physically allocatedLogical provisioned size is not current consumption
Erasure codingParity overhead is lower than extra full copies for applicable policiesA smaller capacity multiplier is not more failure tolerance by itself
CompressionCompressible blocks occupy fewer bytesPrecompressed or encrypted data may save little
DeduplicationIdentical blocks share storage representationSavings depend on actual duplicate content and supported scope
ReclamationUnneeded allocated blocks can be releasedGuest deletion does not always release every underlying layer immediately

OSA and ESA Have Different Designs

All-flash OSA can use deduplication/compression with a disk-group deduplication scope. It also has supported compression-only options in applicable releases; do not claim deduplication and compression must always be enabled together. Enabling or changing a cluster-level efficiency service can involve data movement and operational prerequisites. Plan the change rather than assuming it is just a policy label.

ESA compresses data high in the I/O path, before network transmission, and supports policy-specific controls. ESA 9.0 also introduces global deduplication, so the older statement that ESA eliminates deduplication entirely is incorrect. Its deduplication scope spans the cluster and its processing occurs after data has been persisted, using the supported background design.

Availability is a separate issue from architectural existence. The 9.0 global-deduplication introduction explains the design; the 9.0 FAQ describes limited availability. Verify the exact product release, access, entitlement, encryption compatibility and supported configuration before selecting it. Do not promise that every VVF installation can turn it on immediately.

Work a Capacity Example Correctly

Assume a logical payload of 600 GiB. In a simplified calculation ignoring compression, metadata, snapshots and reservations, two-way RAID-1 mirroring requires 1,200 GiB. A 3+1 erasure-coded layout needs 600 × 4/3 = 800 GiB. A 4+2 layout needs 600 × 6/4 = 900 GiB, providing the corresponding dual-parity protection.

These are planning multipliers, not exact datastore measurements. Add metadata, object-management overhead, reservations, snapshot history, transient policy-conversion space and rebuild headroom. Do not apply a compression ratio twice or mix a raw-to-logical ratio with a logical-to-raw multiplier. Also keep decimal GB/TB separate from binary GiB/TiB.

For ESA 9.0 adaptive RAID-5, a three-to-five-host cluster selects 2+1 and a cluster with six or more hosts selects 4+1. The selected layout's host-count rule differs from simply counting five fragments. Use the architecture-specific behavior rather than importing OSA's 3+1 rule or a later release's Auto-RAID behavior.

Observe Before Promising Savings

Choose representative data, not an empty VM or a duplicated test image alone. Observe logical use, physical use, savings, policy and available reserve over a realistic period. Database encryption, compressed media and repeated operating-system images produce different efficiency results. Background deduplication can also make immediate post-write consumption differ from later steady-state consumption.

A storage-policy change can temporarily need old and new layouts to coexist. Ensure that the cluster has enough compatible hosts/fault domains and free capacity before applying it to many objects. Watch resynchronization and policy compliance afterward. A successful policy edit does not establish that every object's physical conversion has finished.

Administrative Scenario

A capacity report shows strong data reduction but a planned host evacuation fails. Investigate the remaining host count, storage-policy placement, object reservations, operational/rebuild reserves and resync state. Deduplication savings cannot place a second mirror into an unavailable fault domain. Adding nominal free space on the wrong host may also fail to satisfy the placement constraint.

For the exam, explain why a mechanism saves capacity and what it does not prove. The most useful answer connects workload characteristics, supported configuration, resilience and recoverability. A headline reduction ratio alone is insufficient to approve a storage design.

Review Takeaways

  • Thin allocation, parity, compression, deduplication and reclamation are different mechanisms.
  • OSA disk-group deduplication differs from ESA 9.0 global deduplication; availability and feature compatibility must be checked.
  • 600 GiB at a simplified 3+1 multiplier requires 800 GiB before other overhead.
  • Efficiency savings do not eliminate operational/rebuild reserves or independent failure-domain requirements.
Test Your Knowledge

Ignoring all other overhead, what capacity stores a 600 GiB payload in a 3+1 erasure-coded layout?

A

600 GiB

B

1,200 GiB

C

800 GiB

D

1,800 GiB

Sections you finish are checked off in the contents.