Module 8: Unified Storage (Files, Objects, Volumes)

The Promise

By the end of this module you will:

1. Make the unified-storage consolidation pitch on a whiteboard in 5 minutes. Replace separate filers (NetApp, Isilon), separate object storage (Cloudian, Scality, on-prem S3), and separate iSCSI arrays with one Nutanix cluster. Three vendor relationships consolidate to one. Three refresh cycles consolidate to one.
2. Pass roughly 80% of NCP-US, the Unified Storage specialty cert. This module is the foundation. NCP-US tests Files, Objects, and Volumes architecture, configuration, and operations.
3. Position Files, Objects, and Volumes against their incumbent competitors. NetApp ONTAP for files. AWS S3 or on-prem object stores for objects. Pure or Dell arrays for iSCSI block. Each comparison is honest: Nutanix is competitive in 90% of cases, behind in specific niches, with the integration and platform consolidation as the durable win.
4. Recognize when unified storage is the wrong answer. Some workloads (extreme-throughput HPC filers, hyperscale object workloads, very specialized SAN block scenarios) are still better served by purpose-built storage. Naming the gap honestly buys customer trust.
5. Make the backup-target consolidation case. Nutanix Objects as a Veeam, Commvault, or Rubrik target replaces a separate Data Domain, Quantum, or NetApp StorageGRID appliance. One of the more concrete economic wins in 2026 and one of the easier-to-prove ROI cases.
6. Identify which storage service to recommend for which use case. Files for user shares and SMB-aware applications. Objects for backup targets and cloud-native applications. Volumes for non-Nutanix consumers (physical hosts, Oracle RAC on bare metal, legacy apps requiring iSCSI).

This module is the answer to "what other storage problems can Nutanix solve?" The answer, more often than customers expect, is "most of them."

Foundation: What You Already Know

Your customer has multiple storage appliances. Walk into any enterprise datacenter and you find:

• A NetApp filer (or Isilon, Pure FlashBlade, Dell PowerScale) handling user shares, application file storage, and backup targets that need NFS or SMB.
• An object storage tier somewhere: AWS S3 for cloud-resident data, possibly Cloudian or Scality or MinIO on-prem for archive or backup.
• An iSCSI array for workloads that need block storage but aren't on the VMware cluster: physical database servers, legacy applications, bare-metal Linux, sometimes backup targets.
• Possibly a Data Domain or similar dedup appliance for backup repositories.

Each is a separate appliance with its own controller hardware, its own software upgrade cycle, its own support contract, its own management UI, its own replication story, and its own capacity-planning surface. Your customer's storage admin has spent years getting good at this. They are not necessarily happy about it.

The unified-storage story for Nutanix is: those four appliances consolidate to one cluster. Files replaces the filer. Objects replaces the object store and often the dedup appliance. Volumes replaces the iSCSI array. All three run on the same DSF substrate, in the same management plane, with the same lifecycle.

This is consolidation at the storage tier. It is the same operational argument that drove HCI adoption for compute, applied to storage services. The customer who saved one team's effort by collapsing compute-storage-network into HCI saves another team's effort by collapsing file-object-block onto unified storage.

Core Content

Nutanix Files: SMB and NFS at HCI Scale

Nutanix Files is a scale-out file storage service that runs on top of a Nutanix cluster. It provides SMB shares (for Windows clients and applications) and NFS exports (for Linux clients and applications). The architecture:

• A File Server is a logical SMB/NFS service. You can have multiple File Servers per cluster (e.g., one for Production, one for Engineering, one for VDI profiles).
• Each File Server is implemented as a cluster of FSVMs (File Server VMs). FSVMs are dedicated VMs that run the file-services stack on top of Nutanix. Three FSVMs per File Server is the typical deployment for HA and scale-out. Smaller deployments support single-FSVM File Servers (intended for one- and two-node Nutanix clusters or small-environment scenarios), but a single FSVM gives up the HA-across-FSVMs property and limits horizontal scale. Distributed shares and exports require three or more FSVMs.
• FSVMs distribute the file-services workload across the underlying cluster. Adding FSVMs scales capacity and performance horizontally.
• File data sits on DSF with all of DSF's properties: RF, compression, deduplication, snapshots, replication.

Capabilities:

• SMB 2.x and 3.x with full Active Directory integration. Kerberos, ACLs, ABE (Access-Based Enumeration), DFS-N integration. Standard for Windows shares and applications.
• NFS v3 and v4 for Linux clients and applications. Kerberos for v4.
• Multi-protocol shares (SMB and NFS on the same data, with appropriate ACL translation).
• Snapshots at the File Server, share, or path level. Native to DSF; instant; no I/O penalty.
• Self-Service Restore (SSR). End users can restore deleted files from snapshot via the Windows "Previous Versions" tab, without involving IT.
• Files Analytics / Data Lens. Analytics on file usage, access patterns, hot/cold data identification, and ransomware-pattern anomaly detection. The on-cluster product is Files Analytics; the broader unified-storage analytics and ransomware-detection service that evolved from it is Data Lens. Data Lens v2.0 (GA 2026) supports fully on-premises deployment, including air-gapped and dark-site environments.
• Anti-ransomware. Real-time pattern detection on writes; alerts and (optionally) blocks suspicious activity. This has matured significantly in recent AOS releases.
• Replication to another Nutanix cluster (DR for file data).
• Quotas at the share or directory level.
• DFS-N integration for namespace-based access.

When Files is the right tool:

• User home directories and department shares (the canonical SMB use case).
• Application file storage: Windows applications that need an SMB share, Linux apps that need NFS.
• VDI persistent profiles (combined with Citrix or Horizon profile management).
• Web content stores, software distribution shares.
• Backup target for VM-level backups (where SMB/NFS is the protocol).

When Files is not the right tool:

• Extreme-throughput HPC scenarios where you need genuinely thousands of clients hitting one filer at saturation. Dedicated parallel filers (Lustre, GPFS / IBM Spectrum Scale, dedicated Isilon clusters) still win at the very top end.
• Workloads requiring features specific to a particular filer (NetApp FlexClone for file-level cloning, FlexCache for distributed caching, certain ONTAP-specific snapshot policies). Files is competitive but does not match every NetApp feature.

Diagram: Files Architecture

Files Analytics and Data Lens: A Real Differentiator

Most filers have analytics. Files Analytics (the on-cluster service inside Files) and Data Lens (the broader cloud-and-on-prem unified-storage governance product that evolved from Files Analytics) are genuinely good. The pair provides:

• File-system aging. What percentage of data hasn't been accessed in 12+ months? (Often surprising and budget-relevant.)
• Top users by capacity. Who owns the largest file footprints?
• Top users by I/O activity. Who is actively reading/writing the most?
• File type breakdown. PDF, video, log, database files: where is your storage actually going?
• Anomaly detection. A user account that suddenly accesses 10,000x normal volume is flagged. This is the foundation of the anti-ransomware capability.
• Permission audit. Which users have access to which shares; who has elevated permissions; what changed recently.
• Compliance reporting. Standard reports for various compliance frameworks.

Anti-Ransomware: The Security Story for Files

Files (with Files Analytics on-cluster) and Data Lens include real-time ransomware detection that watches file write patterns. Data Lens ships with a constantly-growing library of known ransomware signatures (65,000+ as of 2026) plus behavior-based anomaly detection. The detection-and-block flow watches for encrypt-at-write patterns, mass-rename patterns, and suspicious extension changes, and can trigger:

• Alerts (immediate notification to administrators).
• Optional blocking (refusing the suspicious writes, preventing further damage).
• Snapshot creation at detection time (preserving the pre-attack state).

For customers concerned about ransomware (which by 2026 is essentially every customer), this is a meaningful security story. It is not a complete anti-ransomware strategy by itself; it is a layer that complements endpoint protection, network segmentation, backup hygiene, and user awareness training.

Nutanix Objects: S3 at Cluster Scale

Nutanix Objects is an S3-compatible object storage service running on top of a Nutanix cluster. It provides:

• S3 API compatibility. Standard S3 endpoints, signatures, requests. Most S3-compatible tools work without modification.
• Buckets as the unit of organization, with access policies, IAM-style users, and versioning.
• Object versioning. Multiple versions of an object retained per bucket configuration.
• WORM (Write Once Read Many). Compliance-driven immutability via the S3 Object Lock specification. Once a bucket is marked WORM, there is a 24-hour grace period for testing; after that, no objects within the bucket (or the bucket itself) can be deleted until the date specified by the WORM policy. The retention period can be extended but never reduced. WORM buckets have versioning auto-enabled (versioning cannot be suspended on a WORM bucket). Useful for regulatory archives and some backup retention scenarios.
• Lifecycle policies. Auto-tier or auto-delete objects based on age.
• Replication to other Nutanix Objects deployments or to AWS S3.
• Multi-tenancy. Separate object stores for different tenants, each with their own users and policies.

The architecture is similar in spirit to Files: dedicated VMs (the Objects "Object Service") run the S3 stack on top of DSF. Capacity scales by adding cluster capacity; throughput scales by adding object service VMs.

When Objects is the right tool:

• Backup targets. Veeam, Commvault, Rubrik, Cohesity all support S3 as a target. Objects becomes a Veeam repository, replacing a separate Data Domain or NetApp StorageGRID. One of the most concrete consolidation wins.
• Cloud-native applications. Apps designed against the S3 API (which is most modern apps) work natively against Objects.
• Archives and long-term retention. Use lifecycle policies to age data toward longer retention.
• Compliance archives. WORM mode for regulatory data (financial, healthcare, legal).
• Big data and analytics intermediate storage. Spark, Hadoop, modern data-warehouse staging often use S3-compatible storage.

When Objects is not the right tool:

• Hyperscale workloads at AWS-S3 scale (tens of petabytes, millions of TPS). Objects scales well but is not in the same league as AWS infrastructure.
• Workloads that require AWS-specific features beyond S3 API (S3 Glacier deep archive economics, S3 Select compute pushdown for some specific patterns).
• Workloads where the cloud-economics arbitrage (capex vs cloud-opex) clearly favors public cloud.

Diagram: Objects Architecture

Nutanix Volumes: iSCSI for Non-Nutanix Consumers

Nutanix Volumes is the iSCSI block-storage service. It exposes LUNs (called Virtual Volumes in Nutanix vocabulary) over iSCSI to external consumers: physical servers, non-Nutanix VMs, certain bare-metal database deployments, legacy applications.

The architecture:

• Volume Group: a logical grouping of one or more LUNs that are presented together. Useful for application-aware grouping (e.g., "all the disks for SQL Server cluster instance ABC").
• iSCSI Target: the cluster acts as an iSCSI target. Standard initiator software on Linux, Windows, ESXi, or other consumers connects.
• Multi-pathing: the cluster exposes multiple iSCSI portal IPs for HA. Standard iSCSI multipath software on the consumer handles failover.
• Data resides in DSF: with all DSF properties (RF, compression, snapshots, replication, EC if applicable).

When Volumes is the right tool:

• Physical Linux or Windows servers that need block storage but aren't running on Nutanix as VMs. Examples: standalone database hosts, legacy physical applications, specialized hardware that runs bare metal.
• Oracle RAC or other clustered databases that prefer raw block storage shared across nodes (RAC's ASM works well over iSCSI).
• Legacy iSCSI consumers that the customer hasn't yet migrated.
• VMware ESXi clusters not on Nutanix that want to use Nutanix storage. ESXi can mount Volumes as iSCSI datastores. (Niche but real, often during migrations.)
• Backup targets for backup software that prefers iSCSI over SMB/NFS/S3.

When Volumes is not the right tool:

• Standard VM workloads on AHV. Just use AHV's normal vDisk presentation; you don't need iSCSI on top.
• Workloads where the consumer can use SMB, NFS, or S3 instead. Block protocols are more complex than file or object; only use them where genuinely required.

The Cycle, Frame Two: Unified Storage as Consolidation

For an operations leader or CIO, the durable Unified Storage story is consolidation. Specifically:

Four appliances consolidate to one cluster. The customer's BOM gets simpler. Their refresh cycles align. Their support contracts consolidate. Their team's effort goes into one platform instead of four.

The economic argument is real. Run the actual numbers for the specific customer; the savings depend on their deployment size and current depreciation schedule. Typical mid-market deployments save 30-50% over five years compared to maintaining four separate storage tiers.

The Cycle, Frame Three: Unified Storage as DSF Made Consumable

For a technical architect, the architectural frame is more interesting: unified storage is DSF's distributed-storage primitives made consumable through industry-standard protocols.

DSF already does the hard parts: distributed metadata, replication, erasure coding, compression, dedup, snapshots, geographic replication. Files, Objects, and Volumes are protocol layers on top of DSF that translate user requests (SMB/NFS/S3/iSCSI) into DSF operations.

This is why all three services automatically benefit from DSF improvements. When DSF gets better at compression in a future release, Files, Objects, and Volumes all get better at compression. When DSF improves replication, all three services benefit.

The architecture is a single platform with multiple consumption protocols. Compare this to the NetApp world where the filer is purpose-built for files and bolting on object or block requires different products (StorageGRID for object, ONTAP block features for iSCSI), each with their own software lifecycles.

The Cycle, Frame Four: Unified Storage as the Backup-Target Win

For backup teams, the durable frame is specifically about backup repositories. Most enterprise backup deployments today use:

• Primary backup tier: a deduplication appliance (Data Domain, Quantum, NetApp StorageGRID-with-dedup-software).
• Secondary tier: sometimes tape; increasingly cloud (AWS S3, Azure Blob).
• Cloud archive: AWS S3 Glacier or equivalent.

This stack costs real money. The dedup appliance alone is often a six-figure capex item. Software licensing on top of the appliance is more.

Unified Storage's pitch: Nutanix Objects becomes the primary backup repository. The major backup vendors (Veeam, Commvault, Rubrik, Cohesity, HYCU) all support S3-compatible storage as a target. The customer's backup workflow stays the same; the destination changes from Data Domain to Nutanix Objects. Replication to Objects in another datacenter (or to NC2 in cloud) handles geographic redundancy. Lifecycle policies handle long-term retention.

The consolidation: dedup appliance gone, separate cloud-archive billing simplified (depending on retention strategy), one less vendor relationship.

Diagram: Unified Storage Consolidation

What Unified Storage Genuinely Lacks

Honest gap list. Read it carefully.

1. Files vs NetApp ONTAP at the high end. ONTAP has 30+ years of file-services maturity: FlexClone for file-level cloning, FlexCache for distributed caching, advanced quotas, ABE policy refinement, ONTAP-specific snapshot policies, deep volume-management semantics. Files is competitive for the bulk of enterprise file workloads. For customers running deep ONTAP workflows, the comparison favors ONTAP.
2. Objects vs AWS S3 ecosystem maturity. AWS S3 has the broadest tooling ecosystem and the most niche-feature depth (S3 Select, Glacier Deep Archive economics, S3 Outposts, dozens of S3-native AWS services). Nutanix Objects is S3-compatible at the API level, which works for nearly every common S3 tool, but AWS-specific features beyond S3 are not available.
3. Hyperscale object workloads. AWS-scale or Google-scale object workloads (multi-petabyte, millions of operations per second) are out of scope for Nutanix Objects. Use cloud for cloud-scale.
4. Specialized HPC filers. Lustre, IBM Spectrum Scale (GPFS), and other parallel filers serve workloads where extreme throughput across thousands of clients is the requirement. Files does not target this segment.
5. Volumes vs purpose-built block arrays at the very top end. For block workloads requiring sub-millisecond p99 latency at extreme IOPS, dedicated block arrays still have an edge in some scenarios. Most enterprise block workloads are well-served by Volumes; the very top end is the exception.

These are real. None are deal-breakers for typical mid-market or enterprise workloads. Customers in those niches need targeted purpose-built storage.

What Unified Storage Has That Separates It From Pieces-Bought-Separately

1. Single platform. One cluster, one vendor, one upgrade cycle, one support contract.
2. Shared DSF foundation. All three services inherit DSF's snapshots, replication, compression, dedup, EC.
3. Shared management plane. Files, Objects, and Volumes all configured and monitored from Prism Central.
4. Shared identity integration. AD or SAML configured once, applies across all three services.
5. Shared replication topology. Files Replication, Objects Replication, and DSF Async all use compatible network paths and policies.
6. Shared scaling. Adding cluster capacity adds capacity for VMs, files, objects, and block simultaneously.
7. Shared licensing. Bundled into AOS subscriptions; specific tier requirements vary but no separate appliance licensing.

Lab Exercise: Deploy Files, Create a Share, Test Snapshot Recovery

1. Verify Files availability on your CE cluster. From Prism Central, navigate to Services > Files. If available, proceed; if not, walk through the deployment workflow conceptually.
2. Deploy a File Server. Use the deployment wizard:
   • Name: lab-fs-01
   • Number of FSVMs: 3 (the minimum for HA)
   • Storage container: default or new
   • Network: place FSVMs on an existing virtual network
   • Domain: integrate with AD if available; otherwise workgroup
3. Create an SMB share. Once the File Server is up: name lab-share-01, type SMB (or NFS), path /lab-data, permissions appropriate for your test environment.
4. Mount the share from a client. From a Windows VM, map a network drive: \\<file-server-name>\lab-share-01. From Linux, mount via NFS or SMB.
5. Generate test data on the share. Copy some files. Create directories. Make the share look "real."
6. Take a snapshot of the share. Files > Snapshots > Create. Note that this is instant regardless of share size.
7. Test Self-Service Restore. From a Windows client with the share mapped: right-click on a file > Properties > Previous Versions. You should see the snapshot. Restore a previous version. This is the user-facing recovery experience and is genuinely valuable for customers.
8. Configure a snapshot schedule. Define an hourly schedule with retention. Confirm snapshots are taken on schedule.
9. (Optional) Test Volumes. Create a Volume Group with one or more LUNs. From a Linux VM:

   iscsiadm -m discovery -t sendtargets -p <cluster-data-services-ip>
   iscsiadm -m node -T <iqn> -p <portal> --login

   The new block device should appear; format and mount it.
10. Inspect Files via CLI. From a CVM:

    afs                          # Files CLI (ssh to FSVM if needed)
    ncli filesserver list        # List file servers
    ncli filesserver status name=<name>

What this teaches you:

• Files deployment workflow and architecture in practice.
• The user-facing Self-Service Restore experience (a key customer-demo moment).
• iSCSI / Volumes consumption pattern from an external-style consumer.

Customer-demo angle: Steps 6-7 are the customer demo for Files SSR. Show how an end user can restore their own deleted files without an IT ticket. Help-desk reductions land emotionally. Time it: 90 seconds total.

What You Now Have

You can articulate the unified-storage consolidation pitch in 5 minutes on a whiteboard: NetApp + Cloudian + Pure-iSCSI + Data-Domain consolidate to one Nutanix cluster running Files + Objects + Volumes on shared DSF.

You know each service's purpose: Files for SMB/NFS file workloads, Objects for S3-compatible object storage (especially backup targets and cloud-native apps), Volumes for iSCSI block to non-Nutanix consumers.

You know each service's architecture: Files uses dedicated FSVMs; Objects uses Object Service VMs; Volumes is the cluster acting as iSCSI target. All three sit on DSF and inherit DSF's properties.

You know Files' operational features: Self-Service Restore, Files Analytics, anti-ransomware, multi-protocol shares, replication. You can demo SSR in 90 seconds.

You know Objects' compliance and lifecycle features: versioning, WORM, lifecycle policies, replication. You know which backup vendors support it (Veeam, Commvault, Rubrik, Cohesity, HYCU).

You know Volumes' use cases: physical hosts, bare-metal databases (Oracle RAC), legacy iSCSI consumers, ESXi clusters not on Nutanix that want to consume Nutanix storage.

You have the honest gap list: Files vs ONTAP at the high end (FlexClone, FlexCache, advanced policies); Objects vs AWS S3 ecosystem maturity; hyperscale workloads still cloud-native; specialized HPC filers still purpose-built.

You have the consolidation economics: typical mid-market deployments save 30-50% over 5 years compared to maintaining four separate storage tiers. The backup-target consolidation alone (Objects replacing Data Domain) is one of the easier ROI wins.

You are now ready for licensing. Module 9 covers Nutanix licensing, NCM tiers, AOS subscription models, hardware vs software pricing, and the financial conversation that frequently decides deals. After all the technical depth, this is the dimension that gets things signed.