9.2 NCI Core Components, Configurations, and Common Deployment Scenarios
Key Takeaways
- Objective 1.1 asks you to describe the core components in NCI, identify core component-related configurations, identify common deployment scenarios, and align a component with its use case.
- Single-node and two-node clusters exist specifically for edge and remote-office deployments; two-node clusters require an external Witness VM to arbitrate.
- Three nodes is the minimum for a standard RF2 cluster, and five nodes is the minimum for RF3.
- Nutanix Central is a SaaS control plane that gives a single global view across on-premises clusters and NC2, sitting above individual Prism Central instances.
- Multicloud Snapshot Technology (MST) writes protected snapshots to object storage, giving a low-cost disaster recovery target without a second full cluster.
9.2 NCI Core Components, Configurations, and Common Deployment Scenarios
Objective 1.1 contains four knowledge statements that all circle the same skill: given a customer situation, recognize which Nutanix building block fits. This section is that mapping exercise.
The Core Components Included in NCI
Nutanix Cloud Infrastructure is a software bundle, not a single program. The components you must be able to name:
| Component | What it is | What it does for you |
|---|---|---|
| AOS | The Acropolis Operating System | The distributed system that turns independent servers into a cluster |
| DSF | Distributed Storage Fabric | Pools every node's drives into one logical storage layer with replication and data efficiency |
| CVM | Controller VM | One per node; runs the AOS services and owns the local drives via passthrough |
| AHV | The included hypervisor | Runs guest VMs without separate hypervisor licensing |
| Prism Element | Per-cluster management UI | Day-to-day operation of a single cluster |
| Prism Central | Multi-cluster management plane | One console across clusters; home of categories, templates, and policy |
| Flow Virtual Networking | Software-defined networking | Virtual switches, subnets, IPAM, and network policy |
Cluster Sizing: The Configurations That Follow From Replication Factor
"Identify core component-related configurations" is largely a question about node counts, and the numbers come straight from how many copies of data the cluster keeps:
| Topology | Minimum nodes | Failures tolerated | Typical use |
|---|---|---|---|
| Single-node cluster | 1 | Drive-level only | Edge sites, small ROBO, backup targets |
| Two-node cluster | 2 + Witness VM | 1 node | Remote and branch offices needing node redundancy cheaply |
| Standard RF2 cluster | 3 | 1 node | The mainstream production configuration |
| RF3 cluster | 5 | 2 nodes simultaneously | Large or high-criticality clusters |
[!IMPORTANT] Memorize 3 for RF2 and 5 for RF3. The logic: to keep n copies of data and still have somewhere to rebuild after a failure, the cluster needs more nodes than copies. These two numbers appear on Nutanix exams at every level.
Why Two-Node Clusters Need a Witness
A two-node cluster has an unsolvable problem on its own: if the two nodes stop seeing each other, each one believes the other has failed. If both keep serving writes, the data diverges — split brain.
The Witness VM solves this. It runs outside the cluster, at a third location or in another site, and does exactly one thing: when the two nodes lose contact, each races to claim the Witness, and the one that succeeds continues as a single-node cluster while the other stops serving I/O. The Witness holds no user data and arbitrates rather than participating.
The Witness VM is also named separately in Objective 1.3 as one of the seven tools you must recognize, so it earns points twice.
Node Types Within a Cluster
Not every node is a full hyperconverged node:
- Hyperconverged (standard) node — contributes CPU, memory, and storage, and hosts guest VMs.
- Storage-only node — contributes storage and CVM resources, hosts no guest VMs, and always runs AHV. Used to grow capacity faster than compute, and to add capacity to an ESXi cluster without extra hypervisor licensing.
- Compute-only node — contributes CPU and memory and hosts guest VMs, but contributes no storage to the fabric. Used when an application needs cores far out of proportion to its capacity, often for licensing reasons.
The recognition rule: storage-heavy workload growing faster than compute → storage-only. Compute-heavy workload with modest data → compute-only.
Common Deployment Scenarios
Core datacenter. Multi-node RF2 or RF3 clusters, registered to Prism Central, running mixed enterprise workloads. The default shape.
Edge and ROBO. Single-node or two-node clusters at retail sites, factories, clinics, or branches. Low node count, remote administration through Prism Central, and often a dark site with no direct internet access — which shapes how licensing and LCM updates are performed.
Public cloud with NC2. Nutanix Cloud Clusters (NC2) runs the native AOS and AHV stack directly on bare-metal instances in AWS and Azure. Because it is the same software, VMs and data move between on-premises and cloud without reformatting or nested virtualization.
Disaster recovery. Either a second cluster receiving replication, or — increasingly — Multicloud Snapshot Technology (MST), which writes protected snapshots to object storage instead of requiring a full standby cluster. MST appears explicitly in the blueprint reference list as "Disaster Recovery using Multicloud Snapshot Technology," and its use case is cheap retention and recovery without paying for idle compute.
Platform-Level Services Above the Cluster
Two newer services appear in the Objective 1.1 references and are unfamiliar to anyone studying from older material:
- Nutanix Central — a SaaS control plane that provides a single global view across all your Nutanix deployments, on-premises and NC2 alike. Where Prism Central manages a set of clusters, Nutanix Central sits above Prism Central instances and gives fleet-wide visibility, capacity, and alert summaries from one console.
- Nutanix Konnector — a service in Prism Central and Nutanix Central that automatically registers clusters, notably Nutanix Kubernetes Platform clusters, so they appear in the management console without a manual onboarding step.
[!TIP] Keep the hierarchy straight: Prism Element manages one cluster, Prism Central manages many clusters, and Nutanix Central gives one view across many Prism Centrals and cloud deployments.
A retail chain wants node-level redundancy at each of 200 small stores but cannot justify three nodes per site. What deployment fits, and what additional component does it require?
What are the minimum node counts for a cluster configured with Redundancy Factor 2 and Redundancy Factor 3 respectively?
An administrator needs a single console showing capacity and alert summaries across several Prism Central instances, some managing on-premises clusters and some managing NC2 deployments. Which product provides that view?