5.1 Storage Efficiency: Compression, Deduplication, and Erasure Coding (EC-X)
Key Takeaways
- Inline compression with LZ4 evaluates data blocks upon write; zero-delay (delay = 0) compresses data before committing to the Extent Store, while delay compression (default 60 minutes) defers compression until extents become cold.
- Nutanix deduplication provides two distinct tiers: Content Cache in CVM RAM/SSD for dynamic read optimization, and Extent Store post-process deduplication using SHA-1 fingerprints for persistent capacity savings.
- Erasure Coding (EC-X) applies Reed-Solomon parity encoding exclusively to write-cold data extents, preserving RF2 or RF3 durability while recovering 25% to 33% raw capacity under RF2 (3+1) and up to 50% under RF3 (4+2).
- EC-X requires a strict cluster minimum of 4 nodes for RF2 (3 data + 1 parity across separate nodes) and at least 6 nodes for RF3 (4 data + 2 parity).
- Overwriting a data block within an erasure-coded stripe never triggers an expensive distributed read-modify-write; AOS marks the original extent invalid and writes the new block as a standard replicated extent.
5.1 Storage Efficiency: Compression, Deduplication, and Erasure Coding (EC-X)
[!NOTE] Core Storage Optimization Philosophy: The Nutanix Distributed Storage Fabric (DSF) is designed to optimize capacity consumption without compromising high-performance virtual machine I/O. By distinguishing between active "hot" write data and dormant "cold" capacity, AOS dynamically applies software-driven compression, deduplication, and erasure coding at the storage container level to maximize usable enterprise flash and disk capacity.
In traditional storage architectures, data reduction technologies often created severe controller bottlenecks or introduced unpredictable latency spikes during peak workloads. Nutanix hyperconverged infrastructure eliminates these bottlenecks by distributing compression, deduplication, and parity calculations across every Controller VM (CVM) in the cluster. Administrators can configure these capabilities granularly on a per-storage-container basis to match the precise profile of each hosted application.
Compression Mechanics: Inline vs. Post-Process
Nutanix AOS provides two primary compression mechanisms: Inline Compression and Post-Process Compression. Both operate on 1 MB extents within the Distributed Storage Fabric, at the sub-extent slice granularity DSF uses for read/modify/write and can be tailored depending on workload I/O patterns.
INLINE COMPRESSION (Delay = 0):
Guest Write ───> Stargate (CVM) ───> LZ4 Compression Engine ───> Extent Store (SSD)
(Best for sequential I/O, database bulk loads, and cold archive containers)
DELAYED COMPRESSION (Delay > 0, e.g., 60 mins):
Guest Write ───> OpLog (Uncompressed) ───> Extent Store (Uncompressed)
│
Data cools for 60 minutes
│
▼
Stargate / Curator ───> Background Batch ───> Compressed Extent Store
(Preserves sub-millisecond write latencies for bursty, random I/O workloads)
Compression Algorithms: LZ4 and LZ4HC
AOS employs the high-speed LZ4 and LZ4HC (High Compression) compression algorithms:
- LZ4 Algorithm: Selected for its exceptional decompression throughput (often exceeding 1 to 2 GB/s per CPU core) and negligible computational overhead. LZ4 compresses data blocks rapidly during the write pipeline without saturating CVM vCPU resources.
- LZ4HC Algorithm: Used primarily during post-process batch optimizations where Curator can trade modest CPU cycles for superior compression ratios on dormant data.
- Adaptive Intelligence: If an extent cannot be compressed by at least 15% to 30% (for instance, pre-compressed JPEG images, video files, or encrypted database tables), AOS immediately abandons compression for that block and writes it raw, avoiding wasted CPU cycles.
Inline Compression
When Inline Compression is enabled on a storage container with delay = 0 (zero-delay):
- Incoming sequential or batch writes bypass the low-latency OpLog tier and stream directly toward the Extent Store.
- The local Stargate daemon compresses the extents using LZ4 in memory before committing them to persistent flash.
- Ideal Workloads: Highly compressible sequential data, archive repositories, logging targets, and batch analytics engines where data is written once and rarely modified.
Post-Process Compression (Delay Compression)
When compression is configured with a delay (the default recommended setting is delay = 60 minutes):
- Incoming random writes are ingested directly into the OpLog or SSD tier uncompressed, delivering maximum write IOPS and minimal latency.
- The extents remain uncompressed during their active write lifecycle.
- After data remains inactive ("write-cold") for the specified delay period, background Curator sweeps identify eligible extents.
- Stargate processes the extents in low-priority background batches, compressing the blocks and updating Cassandra metadata pointers.
- Ideal Workloads: High-transaction databases, transactional ERP systems, and general virtualization where write latency is paramount.
Deduplication: Cache Deduplication vs. Capacity Deduplication
Nutanix deduplication operates across two discrete functional tiers: the Content Cache (performance tier) and the Extent Store (capacity tier).
| Deduplication Tier | Location | Scope | Primary Benefit | Workload Suitability |
|---|---|---|---|---|
| Content Cache (Read Dedup) | CVM RAM & SSD Tier | Dynamic in-memory fingerprinting | Eliminates redundant read I/O; accelerates shared OS blocks | VDI boot storms, cloned test/dev environments |
| Capacity Deduplication (Post-Process) | Extent Store (SSD & HDD) | Cluster-wide background extent consolidation | Permanent disk capacity savings via SHA-1 fingerprint matching | Full-clone VM farms, static template repositories |
1. Content Cache (Cache Deduplication)
Content Cache operates dynamically in the memory and solid-state storage of each individual CVM:
- As data is read from or written to the storage fabric, Stargate generates a 160-bit SHA-1 hash (fingerprint) for each data block.
- If multiple virtual machines on the same host access identical data blocks (such as standard Windows system DLLs, kernel files, or shared binaries across dozens of virtual desktops), AOS stores only a single copy of that block in the CVM's local read cache (RAM).
- All subsequent read requests for that fingerprint are fulfilled directly from host memory at microsecond speeds, completely bypassing physical disk access and network hops.
- Content Cache operates with zero disk space overhead and requires no manual administrative capacity planning.
2. Capacity Deduplication (Extent Store Fingerprint Deduplication)
Capacity deduplication is designed to achieve permanent physical storage reductions across persistent tiers:
- When enabled on a storage container, Stargate generates SHA-1 fingerprints for candidate extents written to disk.
- These fingerprints are tracked in the distributed Cassandra database.
- In the background, Curator executes MapReduce jobs that analyze fingerprint tables to detect identical extents across the cluster.
- When duplicates are discovered, Curator instructs Stargate to consolidate identical blocks into a single shared physical extent on disk, releasing duplicate blocks back to the free storage pool.
- Cassandra metadata pointers are updated so that all referencing vDisks point to the shared physical extent.
[!IMPORTANT] CVM Memory Sizing for Deduplication: Enabling Capacity Deduplication significantly increases Cassandra metadata tracking requirements. Nutanix best practices mandate provisioning additional RAM to the Controller VMs (typically upgrading CVM memory from the default 32 GB to 48 GB or 64 GB per node) to support large-scale capacity deduplication fingerprint tables without paging to disk.
Erasure Coding (EC-X): Web-Scale Reed-Solomon Striping
Traditional enterprise SAN storage relied on hardware RAID controllers (RAID 5 or RAID 6) to provide parity protection. However, hardware RAID suffers from prolonged rebuild times, rigid drive configurations, and catastrophic performance penalties during drive failures.
Nutanix Erasure Coding (EC-X) is a software-defined implementation of the Reed-Solomon (RS) coding algorithm designed specifically for distributed hyperconverged scale-out architectures.
TRADITIONAL RF2 (2-WAY REPLICATION): 100% OVERHEAD
Node 1: [Data Chunk A] (Primary Copy)
Node 2: [Data Chunk A] (Replica Copy) ──> 20 TB Data requires 40 TB Raw Space (2.0x)
NUTANIX EC-X (3+1 STRIPE): 33% OVERHEAD
Node 1: [Extent A] (Data)
Node 2: [Extent B] (Data)
Node 3: [Extent C] (Data)
Node 4: [Parity P] (P = A ⊕ B ⊕ C) ──> 30 TB Data requires 40 TB Raw Space (1.33x)
===> Recovers 25% to 33% of Raw Disk Capacity!
How EC-X Operates Exclusively on Write-Cold Data
A critical architectural distinction tested on the NCA exam is that Nutanix EC-X never encodes active, write-hot data inline:
- When an application writes new data, it is always written using standard Redundancy Factor replication (RF2 with 2 copies, or RF3 with 3 copies). This guarantees zero write penalty and sub-millisecond commit latency.
- Over time, data that is not overwritten or modified becomes write-cold (typically inactive for at least 60 minutes to several hours).
- Curator scans the Extent Store and identifies groups of cold extents across distinct nodes.
- Curator gathers these cold extents, computes Reed-Solomon parity extents, and distributes the data chunks and parity chunks across separate physical nodes (or separate blocks/racks for rack-fault-tolerant clusters).
- Once the parity stripe is verified in Cassandra metadata, the redundant duplicate copies from the original RF2/RF3 writes are deallocated, immediately reclaiming physical storage capacity.
Striping Ratios and Cluster Minimum Requirements
| Cluster Redundancy | EC-X Stripe Configuration | Data + Parity Chunks | Storage Overhead | Capacity Savings vs. Standard Replication | Minimum Node Requirement |
|---|---|---|---|---|---|
| Redundancy Factor 2 (RF2) | 3+1 | 3 Data + 1 Parity | 33% (1.33x) | ~25% to 33% raw capacity savings | 4 Nodes |
| Redundancy Factor 2 (RF2) | 4+1 | 4 Data + 1 Parity | 25% (1.25x) | ~37.5% raw capacity savings | 5 Nodes |
| Redundancy Factor 3 (RF3) | 4+2 or 3+2 | 4 Data + 2 Parity | 50% (1.50x) | Up to 50% raw capacity savings | 6 Nodes |
- RF2 with 3+1 Striping: Requires at least 4 nodes in the cluster so that the three data extents and single parity extent can each reside on a completely distinct physical server. If one node fails, the parity extent and surviving two data extents can instantly reconstruct the missing data block.
- RF3 with 4+2 Striping: Requires at least 6 nodes in the cluster. Tolerates the simultaneous loss of two full nodes while reducing raw storage overhead from 200% (3.0x under standard RF3) down to just 50% (1.5x).
Overwrite Behavior on Erasure-Coded Stripes
In traditional RAID 5 or RAID 6 arrays, modifying a single block inside an existing parity stripe causes the notorious "write hole" and requires a 4-step I/O penalty (read old data, read old parity, compute new parity, write new data and parity).
Nutanix resolves this elegantly using immutability and Redirect-on-Write:
- When a virtual machine updates a block residing in an erasure-coded stripe, AOS never performs an in-place parity update or distributed read-modify-write.
- Instead, AOS leaves the cold stripe untouched, marks the target extent as invalid in Cassandra metadata, and writes the newly modified block as a standard replicated extent (RF2 or RF3) to local flash storage.
- Later, during routine background maintenance, Curator garbage-collects the invalidated extent and restripes remaining data.
Storage Optimization Selection Guidelines
Choosing the right combination of compression, deduplication, and EC-X depends on workload profiles:
+-----------------------------------------------------------------------------------+
| Workload Storage Optimization Decision Matrix |
+-----------------------------------------------------------------------------------+
| Workload Type | Compression | Deduplication | Erasure Coding |
|-------------------------|-----------------------|---------------|-----------------|
| Virtual Desktops (VDI) | Inline (Delay 0) | Cache Dedup | Yes (Cold OS) |
| High-Perf OLTP Database | Delay Comp (60 mins) | Disabled | Disabled |
| File Servers / Archives | Inline (Delay 0) | Disabled | Yes (EC-X 3+1) |
| Cloned Test/Dev VMs | Inline (Delay 0) | Capacity Dedup| Yes (EC-X 3+1) |
| Video / Media Repos | Disabled (Pre-comp.) | Disabled | Yes (EC-X 3+1) |
+-----------------------------------------------------------------------------------+
[!TIP] NCA Exam Quick Rule: Remember that Erasure Coding (EC-X) is designed strictly for write-cold, read-mostly data (such as file servers, archives, log repositories, and static VMs). It is never recommended for high-write transactional databases. Conversely, Inline Compression with delay = 0 delivers immediate savings for sequential workloads, while Delayed Compression protects IOPS for transactional systems.
What is the minimum number of nodes required in a Nutanix AOS cluster to enable Erasure Coding (EC-X) on a storage container configured with Redundancy Factor 2 (RF2)?
An administrator observes that high-performance transactional database VMs experience latency spikes when write data is compressed immediately. Which compression configuration eliminates this write-path latency penalty while still saving disk capacity over time?
How does Nutanix AOS handle an overwrite to a data block that already belongs to an Erasure Coded (EC-X) cold data stripe?