11.4 Cluster Expansion: Node Types and In-Node Expansion Capabilities

11.4 Cluster Expansion: Node Types and In-Node Expansion Capabilities

Objective 3.2 contains two adjacent knowledge statements: "identify the node types for expansion" and "identify expansion capabilities within a node." They describe two different answers to "we need more," and part of the skill is knowing which question is being asked.

Scaling Out: Adding Nodes

The defining property of a scale-out architecture is that growth is incremental and non-disruptive. Where a traditional array forces a forklift replacement when the controllers run out of headroom, a Nutanix cluster grows a node at a time, and every node added brings compute, storage, and controller capacity together.

The Expand Cluster workflow

From Prism Element, Expand Cluster runs the process:

1. Discovery. Prism discovers candidate nodes on the network that are not yet part of a cluster.
2. Selection and addressing. You select nodes and supply host, CVM, and out-of-band management IP addresses.
3. Imaging if required. If the new node is running a different AOS or hypervisor version than the cluster, it is imaged to match. This is the step that makes expansion safe: a cluster is not left running mixed versions.
4. Addition. The node joins the cluster and its storage becomes part of the storage pool.
5. Rebalancing. Data is automatically redistributed in the background so the new node carries its share.

The workflow is non-disruptive. Guest VMs continue running throughout, and the rebalance is a background activity rather than a migration you plan.

[!TIP] The pre-check step matters: the blueprint references "Prerequisites and Requirements for Expanding a Cluster." Candidate nodes must be network reachable, compatible with the cluster, and have the necessary addressing available. Failed expansions are usually addressing or reachability problems rather than hardware faults.

The Three Node Types

Choosing the node type is a matching exercise between the shape of the shortage and the shape of the node:

Storage-only nodes

A storage-only node runs a CVM and contributes its drives to the storage pool, but never hosts guest VMs. Two properties make it examinable:

1. It always runs AHV, even when the cluster hosts its workloads on ESXi. Because it runs no guests, no ESXi licensing is required for it — which makes storage-only nodes the standard way to add capacity to a VMware-based Nutanix cluster economically.
2. It changes the compute-to-capacity ratio of the cluster, which is precisely the point when data grows faster than the workload that produces it.

Compute-only nodes

The mirror image: CPU and memory, no contribution to the storage fabric. VMs on a compute-only node read and write across the network to CVMs on other nodes, so they do not benefit from data locality in the same way. Use them when the constraint is genuinely cores — a workload licensed per core, or a compute-heavy application with a modest data footprint.

[!IMPORTANT] A cluster cannot be made only of compute-only nodes. They add compute to a cluster whose storage is provided by hyperconverged and storage-only nodes.

Scaling Within a Node

Sometimes the answer is not another node. "Identify expansion capabilities within a node" covers growth inside the chassis you already own:

• Adding drives to empty bays. Most node models ship partially populated. Filling empty bays adds capacity to the storage pool without adding a node, and is by far the cheapest form of growth when the bays exist.
• Adding memory. Subject to the platform's DIMM slots and supported configurations. Memory is frequently the first resource a cluster exhausts, because AHV VMs are fixed-size by default.
• Adding or upgrading network adapters. Additional NICs for more bandwidth or redundancy, or faster adapters where the uplinks have become the constraint.

Every one of these is model-constrained. How many bays, how many DIMM slots, which drive types are supported, which NICs are qualified — these come from the platform specification and the Compatibility and Interoperability Matrix, not from a general rule.

[!TIP] Decision shortcut. Are there empty drive bays or DIMM slots? If yes, in-node expansion is usually cheaper and faster. Do you need more controller and compute capability, not just capacity? Then you need nodes, because adding drives does not add a CVM.

After Expansion

Adding capacity, whether by node or by drive, triggers automatic background rebalancing. Curator redistributes data so the new capacity is used and the cluster returns to an even distribution. No manual data migration is required, and it happens as background work rather than as a maintenance activity.