2.1 Hardware Building Blocks: Nodes, Blocks, Clusters, and Quorum

Hardware Building Blocks: Nodes, Blocks, Clusters, and Quorum

Core Concept: Nutanix hyperconverged architecture replaces monolithic storage arrays and SAN fabrics with a distributed, software-driven fabric. The physical infrastructure scales out using commodity server components organized into modular building blocks, where distributed consensus algorithms guarantee operational resiliency without single points of failure.

Understanding the precise boundaries between physical hardware packaging, logical cluster definitions, and distributed consensus mechanisms is essential for the Nutanix Certified Associate (NCA) exam. This section details the relationships among nodes, blocks, and clusters, outlines deployment requirements for standard and edge environments, and explains the strict quorum rules that prevent data corruption.

---

Physical Architecture: Nodes vs. Blocks

To understand Nutanix hardware terminology, administrators must distinguish between physical compute/storage sleds (Nodes) and the enclosure chassis (Blocks).

+-------------------------------------------------------------------+
|                    Nutanix 2U Block (Chassis)                     |
|  +---------------------+  +---------------------+                 |
|  |   Node A (Sled 1)   |  |   Node B (Sled 2)   |  Shared Fans    |
|  | CPU / RAM / Drives  |  | CPU / RAM / Drives  |                 |
|  +---------------------+  +---------------------+  Shared Redundant
|  +---------------------+  +---------------------+  Power Supplies 
|  |   Node C (Sled 3)   |  |   Node D (Sled 4)   |  (PSU 1 & 2)    |
|  | CPU / RAM / Drives  |  | CPU / RAM / Drives  |                 |
|  +---------------------+  +---------------------+                 |
+-------------------------------------------------------------------+

The Nutanix Node (Compute & Storage Unit)

A Node is a single physical server motherboard containing:

• One or two multi-core processors (Intel Xeon or AMD EPYC).
• High-density DDR4 or DDR5 ECC memory.
• Direct-attached local storage devices (NVMe PCIe SSDs, SATA/SAS SSDs, and optional high-capacity HDDs).
• Dedicated Baseboard Management Controller (BMC) / IPMI interface for out-of-band management (e.g., Supermicro IPMI, Dell iDRAC, HPE iLO, Lenovo XCC).
• Redundant high-speed network interfaces (dual 10GbE, 25GbE, 40GbE, or 100GbE NICs).

Every node in a Nutanix cluster runs a bare-metal enterprise hypervisor (Nutanix AHV, VMware ESXi, or Microsoft Hyper-V) and hosts exactly one Controller Virtual Machine (CVM). The node is the fundamental computational, memory, and storage failure domain in AOS.

The Nutanix Block (Enclosure Architecture)

A Block is a physical rackmount enclosure—most commonly a 2U chassis—that holds between one and four independent nodes (often referred to as modular sleds).

• Shared Enclosure Resources: The block provides shared, hot-swappable cooling fans and dual redundant power supply units (PSUs).
• No Shared Computing Components: Crucially, a Nutanix block contains no shared computing backplane, no shared memory bus, and no shared storage controllers. Each node slides into the chassis as an electrically isolated server sled with its own dedicated PCIe lanes, CPU sockets, memory slots, and drive bays.
• Sled Servicing: Individual node sleds can be powered down, serviced, or physically pulled from the chassis for maintenance without electrically impacting or interrupting the operation of neighboring nodes in the same block.

Hardware Nomenclature and Models

Nutanix appliance model numbers follow a structured naming convention that reflects form factor and workload targets (e.g., NX-3060-G8):

• NX Family: Official Nutanix-branded appliances manufactured on Supermicro hardware platforms.
• OEM Platforms: Nutanix software also deploys on certified hardware from major original equipment manufacturers, including Dell PowerEdge (XC Series), Lenovo ThinkAgile (HX Series), HPE ProLiant (DX Series), and Cisco UCS.
• First Digit: Typically indicates the model series and target workload (e.g., NX-1000 for ROBO, NX-3000 for general virtualization/VDI, NX-8000 for heavy databases and storage-intensive applications).
• G-Suffix: Indicates the hardware generation (e.g., G7, G8, G9).

---

Cluster Sizing & Minimum Node Topologies

A Nutanix Cluster is a logical entity formed by aggregating 3 or more physical nodes connected over an isolated, low-latency top-of-rack Ethernet network. The cluster pools the local compute, memory, and direct-attached storage of all member nodes into a single, unified Distributed Storage Fabric (DSF).

Standard Production Cluster Thresholds (RF2 vs. RF3)

The minimum number of nodes required to form a production Nutanix cluster depends directly on the configured Redundancy Factor (RF):

[!IMPORTANT] Why does RF2 require a minimum of 3 nodes instead of 2? While storing 2 copies of data mathematically requires only 2 nodes, maintaining cluster quorum and enabling dynamic self-healing requires at least 3 nodes. If a 3-node RF2 cluster loses a node, 2 nodes remain online to preserve metadata quorum and automatically rebuild degraded data extents to restore RF2 compliance.

[!NOTE] Why does RF3 require a minimum of 5 nodes? In Redundancy Factor 3, three independent copies of data and metadata must reside on distinct nodes. To sustain the simultaneous failure of 2 physical nodes without losing quorum, the cluster must start with at least 5 nodes (floor(5 / 2) + 1 = 3 nodes required for quorum). If 2 nodes fail out of 5, exactly 3 nodes remain online, preserving quorum.

---

Specialized Edge & ROBO Topologies

For distributed enterprise environments with dozens or hundreds of edge locations (retail stores, branch offices, manufacturing plants), deploying 3-node clusters at every location can be cost-prohibitive. Nutanix addresses this with specialized Remote Office / Branch Office (ROBO) architectures.

                               +--------------------------------+
                               |     External Witness VM        |
                               | (Core Datacenter / Cloud / AWS)|
                               +--------------------------------+
                                       /                \
                 Heartbeat & Quorum   /                  \   Heartbeat & Quorum
                 (Round-Trip <500ms) /                    \  (Round-Trip <500ms)
                                    v                      v
                         +--------------------+  10GbE   +--------------------+
                         |    ROBO Node 1     |<========>|    ROBO Node 2     |
                         | Local CVM + Disks  | Interlink| Local CVM + Disks  |
                         +--------------------+          +--------------------+
                         | <------------- ROBO Site Cluster -------------> |

Single-Node ROBO Topologies

• Architecture: Consists of a single physical server running Nutanix AHV or VMware ESXi and a local CVM.
• Resiliency: Provides drive-level protection (if multiple drives are present), but zero node-level high availability. If the physical motherboard, CPU, or power supply fails, workloads on that node go offline.
• Workload Role: Used primarily as edge compute appliances, local caching nodes, or backup targets. Virtual machines are backed up or asynchronously replicated across the WAN to a centralized corporate cluster.

Two-Node ROBO Topologies and the Witness VM

A two-node cluster provides local compute and storage high availability for branch offices while minimizing hardware expense. However, a 2-node cluster presents a fundamental computer science challenge: two nodes cannot form a tie-breaking majority during a network partition.

To solve this, Nutanix introduces the Nutanix Witness VM:

• Function: The Witness VM acts as an external arbitrator and tie-breaker to maintain cluster quorum during node or network failures.
• Footprint: A lightweight, specialized virtual appliance requiring only 2 vCPUs and 6 GB of RAM.
• Placement: The Witness VM must reside outside the 2-node cluster's failure domain. It is typically deployed on an existing AHV or ESXi cluster in a core corporate datacenter, or hosted in a public cloud (such as AWS, Azure, or GCP).
• Network Requirements: Communicates with both ROBO nodes over WAN links. The network connection requires a maximum round-trip latency of 500 ms and minimum bandwidth of 1 Mbps.
• Scalability: A single Witness VM can manage quorum arbitration for up to 500 two-node ROBO clusters simultaneously.
• Data Handling: The Witness VM does not store any customer data, virtual disks, or cluster metadata. Its sole responsibility is participating in quorum voting and lock leasing.

---

Distributed Quorum Mechanics and Split-Brain Prevention

In any distributed computing architecture, quorum is the minimum number of voting members required to conduct cluster operations and make authoritative decisions regarding metadata and data placement.

Mathematical Quorum Calculation

Nutanix AOS utilizes a strict majority rule derived from distributed consensus algorithms (specifically Apache ZooKeeper and Paxos). The mathematical formula to determine quorum is:

$\text{Quorum} = \left\lfloor \frac{N}{2} \right\rfloor + 1$

Where $N$ represents the total number of voting nodes in the cluster configuration.

Quorum Thresholds by Cluster Size

The following table illustrates the quorum requirements and tolerable node failure limits across various cluster node counts:

[!WARNING] Notice that an even-numbered cluster size provides no additional node failure tolerance compared to the odd-numbered cluster size immediately preceding it. A 4-node cluster requires 3 nodes for quorum, meaning it can only tolerate 1 node failure—exactly the same as a 3-node cluster! If a 4-node cluster loses 2 nodes simultaneously, exactly 2 nodes remain online. Since 2 is not strictly greater than half ($2 \ngtr 2$), quorum is broken.

The Network Partition Dilemma (Split-Brain Scenario)

Consider what occurs if a physical top-of-rack network failure partitions a 4-node cluster into two isolated halves:

• Side Alpha: Node 1 and Node 2 can communicate with each other.
• Side Beta: Node 3 and Node 4 can communicate with each other.
• The Interconnect: Neither side can communicate across the partitioned network link.

If AOS allowed a simple 50% split to continue operating, both Side Alpha and Side Beta might attempt to accept write operations, update vDisk block pointers, and modify identical metadata entries. This catastrophic condition is known as split-brain:

• Data rapidly diverges between the two partitions.
• Virtual machine file systems suffer unrecoverable cross-block corruption.
• Reconciliation becomes mathematically impossible without data loss.

Because Nutanix enforces the strict majority rule ($\lfloor 4/2 \rfloor + 1 = 3$), neither Side Alpha (2 nodes) nor Side Beta (2 nodes) reaches the required quorum threshold of 3. Consequently, neither partition is permitted to process write I/O, completely preventing data divergence.

Quorum Loss Behavior and Operational Safeguards

When an unplanned failure or network isolation event causes an active cluster to drop below its quorum threshold, AOS executes deterministic fail-safe procedures:

1. Storage Read-Only Lock: The storage fabric halts write I/O processing immediately.
2. Metadata Protection: Cassandra and Zookeeper suspend state updates to prevent corrupting the distributed metadata ring.
3. Prism Reporting: Prism Element generates critical cluster-down and quorum-loss alerts.
4. Workload State: Virtual machine disk writes pause or fail at the hypervisor layer depending on guest operating system disk timeout settings.
5. Automatic Recovery: As soon as network connectivity is restored or missing nodes reboot and rejoin the cluster, distributed consensus daemons re-elect leaders, establish quorum, and resume normal read/write storage operations without requiring manual administrator intervention.