Study guide
5.1 Storage Efficiency: Compression, Deduplication, and Erasure Coding (EC-X)
Nutanix Certified Associate NCA
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Nutanix Cloud Platform & HCI Foundations
1.1 Nutanix NCA Exam Overview, Format, and Objectives 1.2 Hyperconverged Infrastructure (HCI) vs. Traditional 3-Tier Architecture 1.3 The Nutanix Enterprise Cloud Portfolio (NCI, NUS, NCM, EUC, NC2)
2 Chapter 2: Platform Architecture & Distributed Core Services
2.1 Hardware Building Blocks: Nodes, Blocks, Clusters, and Quorum 2.2 Controller VM (CVM) Architecture, Datapath, and Autopathing 2.3 Core Distributed Services: Cassandra, Stargate, Curator, Zookeeper, and Genesis
3 Chapter 3: Prism Administration & Cluster Operations
3.1 Prism Element vs. Prism Central Architecture and Interface Navigation 3.2 Entity Management, Categories, and Role-Based Access Control 3.3 Nutanix Licensing Tiers, Add-ons, and Pulse Telemetry
4 Chapter 4: AOS Distributed Storage Fabric & Data Placement
4.1 Storage Pools, Storage Containers, and vDisk Virtual Architecture 4.2 Redundancy Factor (RF2 vs. RF3), Failure Domains, and Fault Tolerance 4.3 Data Locality Mechanics and Intelligent Lifecycle Management (ILM)
5 Chapter 5: Storage Optimization & Business Continuity
5.1 Storage Efficiency: Compression, Deduplication, and Erasure Coding (EC-X) 5.2 Space-Efficient Redirect-on-Write (ROW) Snapshots and Zero-Byte Clones 5.3 Protection Domains, Consistency Groups, and Disaster Recovery Replication
6 Chapter 6: AHV Virtual Machine Lifecycle Management
6.1 AHV VM Provisioning, Resource Allocation (vCPU, vRAM, Disks), and Boot Types 6.2 Nutanix Image Service and Virtual Machine Templates 6.3 Nutanix Guest Tools (NGT) Architecture, Features, and Deployment 6.4 AHV High Availability (HA), Acropolis Dynamic Scheduling (ADS), and Affinity Rules
7 Chapter 7: AHV Networking & Flow Security Fundamentals
7.1 AHV Virtual Networking Architecture, Open vSwitch (OVS), and Bridges 7.2 Host Network Uplinks, Virtual Switch Configuration, and NIC Bonding Modes 7.3 Virtual Networks: Managed vs. Unmanaged Networks and IPAM 7.4 Nutanix Flow Network Security & Microsegmentation Fundamentals
8 Chapter 8: Cluster Maintenance, Health Monitoring & Support
8.1 Nutanix Cluster Health Monitoring, Alerts, and Events Engine 8.2 Nutanix Cluster Check (NCC) Architecture and Execution 8.3 Life Cycle Manager (LCM) and Rolling Non-Disruptive Upgrades 8.4 Nutanix Support Ecosystem: Diagnostics, Log Gathering, and Support Bundles
9 Chapter 9: Recognizing Nutanix Solutions, Hypervisors & the Product Portfolio
9.1 Supported Hypervisors for NCI and Feature Supportability 9.2 NCI Core Components, Configurations, and Common Deployment Scenarios 9.3 Nutanix Unified Storage: Files, Objects, and Volumes Use Cases 9.4 Nutanix Database Service (NDB) and Database Automation 9.5 Nutanix Kubernetes Platform, Enterprise AI, and End-User Computing
10 Chapter 10: Nutanix Tools — Migration, Deployment, and Validation
10.1 Nutanix Move: Cross-Hypervisor and Cloud Migration 10.2 Foundation and Foundation Central: Imaging and Cluster Deployment 10.3 X-Ray, Collector, and the Objective 1.3 Tool Inventory
11 Chapter 11: Cluster Configuration, Security & Hardware Maintenance
11.1 Cluster Services Configuration: DNS, NTP, SMTP, and SNMP 11.2 Cluster Security Options: Lockdown, Encryption, and the Recycle Bin 11.3 Node Maintenance Mode, Host Shutdown, and Cluster Shutdown 11.4 Cluster Expansion: Node Types and In-Node Expansion Capabilities 11.5 Out-of-Band Management and Remote Console Access
12 Chapter 12: Storage, Network, and Software Administration Tasks
12.1 Volume Groups, vDisk Placement, and Live vDisk Migration 12.2 Network Visualizer, Physical Switch Monitoring, and Network Segmentation 12.3 The Software Compatibility Matrix and Upgrade Path Planning 12.4 Taking and Managing VM Snapshots in Prism 12.5 License Operations: State, Assignment, Reclamation, and Expiry
13 Chapter 13: Performance Analysis, Reporting & Support Operations
13.1 Prism Analysis: Metric Charts, Entity Charts, and Custom Reports 13.2 Custom Alert Policies and Behavioural Anomaly Detection 13.3 Interpreting Workload Performance: CPU Contention, CPU Ready, Memory, and I/O Latency 13.4 Creating Support Cases, Required Documentation, and Insights
5.1 Storage Efficiency: Compression, Deduplication, and Erasure Coding (EC-X)
Key Takeaways Explain This Topic AI
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.
Last updated: September 2026
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.