Two-Node Cluster with a Local Witness

A two-node cluster with a local witness lets you run a fully highly-available cluster on SC//HyperCore™ HyperVisor from two storage/compute nodes plus a separate, physical witness node that acts as a quorum tiebreaker. You still get the rolling updates and automatic failover of a standard HA cluster, but with only two nodes running VMs instead of three or more. This makes it a good fit for edge and remote sites where rack space, power, and budget are constrained.

The witness node itself runs no SCRIBE real storage devices (RSDs) and hosts no VMs. It participates in neither storage nor compute; it exists to provide quorum so the cluster can make a safe decision if the two compute nodes lose contact with each other. Because it carries no data or workload, it can run on minimal hardware.

Prerequisites

Confirm the following before deploying a two-node cluster with a local witness:

• SC//HyperCore v9.7.5 or later. This is the minimum version that supports the configuration.

• SCRIBE’s relaxed placement spec (introduced in v9.6). In a two-node configuration it isn’t always possible to mirror data across fully distinct failure groups, so SCRIBE relaxes placement hierarchically: it first tries distinct drives in distinct failure groups, then distinct drives within the same failure group (same node), and only as a last resort the same drive. This fallback is what makes a resilient two-node configuration possible.

• A witness node, meeting the following minimum hardware:

  • At least 4 GB of RAM
  • An x86 processor
  • Enough storage to run the OS (128 GB is sufficient)

  Any SC//HyperCore-capable node type can be initialized in Witness Mode.

• Local deployment for the witness. The witness must be deployed in the same location and on the same network as the two compute nodes. It is not designed to be deployed at a separate site.

• Sizing headroom on both compute nodes. With only two nodes running VMs, each compute node must have enough CPU and memory to run all VMs in the cluster on its own in a failure situation. This is critical anywhere high availability is a hard requirement.

• Licensing. The witness node needs an SC//HyperCore license applied — either a dedicated, no-cost Witness Node License or a standard/site SC//HyperCore license. Work with your Scale Computing account team to make sure the right license is in place before deployment.

Configuration Steps

Initialize the Cluster from the Command Line

The cluster command line is the primary way to deploy this configuration. The witness node must be initialized last, after both compute nodes. Follow the steps below:

1. Hook a monitor and keyboard to the first compute node. Log in using the default credentials (username admin, password admin).

2. Run the node configuration command:

   sudo scnodeinit

   You may be prompted for a password — use the same password as the node login.

3. Enter each piece of requested IP and network information: LAN IP, LAN Netmask, LAN Gateway, Backplane IP of this node, Backplane IP of the first node in the system (the same as this node’s Backplane IP, since it is the first node), and the unique software serial number.

4. Repeat steps 1–3 on the second compute node, using its own monitor and keyboard connection.

5. Once both compute nodes are configured, hook up a monitor and keyboard to the node that will serve as the witness and run:

   sudo WITNESS=1 scnodeinit

Zero Touch Provisioning

The SC//HyperCore software supports initializing a two-node-with-witness configuration via Zero Touch Provisioning (ZTP) as of v9.7.5. SC//Fleet™ Manager does not yet support defining a witness node as part of the ZTP workflow; support for this is expected at a future date.

Configuration Options and Behavior

A node operating in Witness Mode differs from a normal compute node in a few important ways:

• It cannot run VMs and does not contribute storage to SCRIBE for VM use.
• It cannot be set as the initializing node during cluster setup — see Configuration Steps.
• Node deletion must be facilitated by Scale Computing Support. Two-node clusters do not automatically initiate SCRIBE data recoveries when a node goes offline, because doing so risks consuming too much of the remaining node’s capacity rewriting blocks from the down node. SC//HyperCore v9.7 requires recoveries to complete before a node can be removed, so Support uses a dedicated tool to bypass that requirement and forcibly remove a node when needed.

Usable Storage Calculation

Even though the witness does not participate in SCRIBE storage, usable storage on the compute nodes is calculated the same way as a standard three-node cluster: take the total raw storage capacity of all drives in the compute nodes, subtract the capacity of the largest drive, and divide by two.

Network Speed Mismatch Condition

If NIC speeds on the witness don’t match the speeds on the compute nodes, the cluster will raise a Network Speeds Mismatch condition. This does not mean the cluster is unsupported or at risk; a method to silence this condition is planned for a future SC//HyperCore software update.

Best Practices for Two-Node + Witness Environments

• Replace an offline node or witness immediately. A two-node cluster only guarantees a single copy of data while a node is down, and snapshots are suspended during that time. The cluster continues operating safely with one node or the witness offline, but a second failure at that point constitutes a double fault and can result in data loss.
• Size both compute nodes for full failover. Each compute node must independently be able to run every VM in the cluster, since there is no third node to absorb load during a failure.
• Keep the witness local. Deploy the witness in the same site and network as the compute nodes — it is not intended for a separate, remote location.
• Plan for one witness per cluster. A single witness cannot provide quorum for multiple clusters at the same time, and a cluster only makes use of one witness.
• Match NIC speeds where possible between the witness and compute nodes to avoid the Network Speeds Mismatch condition.
• Treat a witness failure like any node failure. Applications on the compute nodes are not disrupted and will not fail over when the witness goes offline, but the witness should still be replaced as soon as possible to avoid a double-fault scenario.