The storage nodes in a two-node cluster must be the same model type.
• Two-node storage clusters are best suited for small-scale deployments with workloads that are not
dependent on large capacity and high performance requirements.
• In addition to two storage nodes, a two-node storage cluster also includes two NetApp HCI Witness
Nodes.
Learn more about
• You can scale a two-node storage cluster to a three-node storage cluster. Three-node clusters increase
resiliency by providing the ability to auto-heal from storage node failures.
• Two-node storage clusters provide the same security features and functionality as the traditional four-node
storage clusters.
• Two-node storage clusters use the same networks as four-node storage clusters. The networks are set up
during NetApp HCI deployment using the NetApp Deployment Engine wizard.
Storage cluster quorum
Element software creates a storage cluster from selected nodes, which maintains a replicated database of the
cluster configuration. A minimum of three nodes are required to participate in the cluster ensemble to maintain
quorum for cluster resiliency. Witness Nodes in a two-node cluster are used to ensure that there are enough
storage nodes to form a valid ensemble quorum. For ensemble creation, storage nodes are preferred over
Witness Nodes. For the minimum three-node ensemble involving a two-node storage cluster, two storage
nodes and one Witness Node are used.
In a three-node ensemble with two storage nodes and one Witness Node, if one storage
node goes offline, the cluster goes into a degraded state. Of the two Witness Nodes, only
one can be active in the ensemble. The second Witness Node cannot be added to the
ensemble, because it performs the backup role. The cluster stays in degraded state until the
offline storage node returns to an online state, or a replacement node joins the cluster.
If a Witness Node fails, the remaining Witness Node joins the ensemble to form a three-node ensemble. You
can deploy a new Witness Node to replace the failed Witness Node.
Auto-healing and failure handling in two-node storage clusters
If a hardware component fails in a node that is part of a traditional cluster, the cluster can rebalance data that
was on the component that failed to other available nodes in the cluster. This ability to automatically heal is not
available in a two-node storage cluster, because a minimum of three physical storage nodes must be available
to the cluster for healing automatically. When one node in a two-node cluster fails, the two-node cluster does
not require regeneration of a second copy of data. New writes are replicated for block data in the remaining
active storage node. When the failed node is replaced and joins the cluster, the data is rebalanced between the
two physical storage nodes.
Storage clusters with three or more nodes
Expanding from two storage nodes to three storage nodes makes your cluster more resilient by allowing auto-
healing in the event of node and drive failures, but does not provide additional capacity. You can expand using
the
NetApp Hybrid Cloud Control
can be stranded (see
installation. A single Witness Node is still available to keep the ensemble quorum in the event of a storage
Witness Nodes.
UI. When expanding from a two-node cluster to a three-node cluster, capacity
Stranded
capacity). The UI wizard shows warnings about stranded capacity before
Need help?
Do you have a question about the HCI and is the answer not in the manual?
Questions and answers