Two Nodes Can Preserve Availability. They Can't Preserve N+1 Capacity.

Two-node edge deployment no longer means what it meant two years ago. Red Hat now has two production-grade ways to run an OpenShift edge cluster on two servers instead of three, and both address the failure-coordination problem through different mechanisms. TNA preserves a third etcd vote through an arbiter; TNF uses hardware fencing to isolate a failed node. Neither mechanism changes what happens to the workload once one of the two workload-bearing servers is gone.

The Economics Behind Every Two-Node Edge Deployment

Edge infrastructure has never been a smaller version of datacenter infrastructure — it's a different cost equation entirely. A third full-sized server at a retail site, a manufacturing floor, or a remote clinic doesn't just cost the hardware. It costs the power circuit, the rack space, the shipping, and the truck roll every time it needs hands-on maintenance. Multiply that by a few hundred sites and the third node stops being an engineering decision and starts being a line item somebody has to defend.

That's the pressure Red Hat's newer two-node topologies are responding to, and it's a legitimate response — the mechanics of two-node quorum are well understood at this point, and the industry has stopped pretending a third server is the only way to keep a cluster safe. But there's a distinction worth being precise about first: removing the third full-sized server does not automatically remove high availability. It removes one full unit of failure capacity. Those are two different guarantees, and the rest of this piece is about the gap between them — inside the broader discipline of virtualization architecture, where hypervisor and control-plane decisions carry exactly this kind of five-year consequence.

Red Hat Has Two Ways to Build a Two-Node Edge

Red Hat's own documentation splits this into two distinct architectures, and conflating them produces the wrong analysis.

01 — Two-Node with Arbiter (TNA)

Two full-sized nodes carry every workload. A lightweight third participant — the arbiter — holds only the third etcd vote needed for quorum. It runs no workloads and no control-plane components of its own. Red Hat positions TNA as preserving the same HA characteristics as a standard three-node cluster, and GA'd it with OpenShift 4.20. The third node's coordination role survives; its compute role doesn't.

02 — Two-Node with Fencing (TNF)

No arbiter, no third participant of any kind — genuinely two servers. Pacemaker and Corosync use BMC-based hardware fencing to isolate a failed or unresponsive node so the survivor can continue without split-brain risk. Both nodes run workloads directly; there's no separate compute tier to fall back on. TNF reached general availability with OpenShift 4.22 in July 2026, two releases after TNA's 4.20 GA introduction.

Neither approach changes the arithmetic of losing one of the two workload-bearing nodes. TNA replaces the third server's coordination role with a lightweight arbiter; TNF replaces it with fencing. In both cases, the production workload starts with two places to run — and after one node fails, only one remains.

That distinction matters most inside the virtualization control plane itself, where cluster coordination and scheduling authority decide what "the cluster is up" actually means once a node is gone.

The Guarantee You Preserved Isn't the Guarantee You Lost

That last row is the whole argument, but it needs one caveat before it's fair: N+1 isn't a node count, it's a design condition. A three-node cluster running hot enough that two surviving nodes still can't carry the full workload never had real N+1 capacity either — the third node just made the shortfall less obvious. What a two-node topology does is remove the place where that shortfall used to hide.

TNF's own documentation is explicit about this: after one node is fenced, the surviving node keeps the cluster running, but the cluster has lost HA redundancy and operates in a degraded state until the second node returns. The availability mechanism can work exactly as designed while the capacity model fails exactly as designed.

This is exactly the gap CPU Ready and CPU Wait metrics expose at the scheduler layer — a dashboard that reads "healthy" while the thing that actually determines performance sits somewhere the dashboard doesn't look. Quorum status is the same kind of metric.

The Capacity Problem Appears After the Failure, Not During Deployment

Split the timeline into three states and the mistake becomes obvious.

Before failure, the two nodes' aggregate capacity looks fine on paper. During failure, that aggregate number stops mattering — the surviving node inherits all of the failed node's workload, on top of what it was already carrying. After recovery, the architecture returns to its steady state, but the question that actually determined whether the incident was survivable already happened during the interval in between.

Two conversations, two different questions:

• The procurement conversation: "We're saving one full server at every edge site."
• The failure conversation: "One server now has to absorb everything the other one was running."

That's not a hypothetical. Red Hat's own TNA guidance recommends sizing each workload node at no more than roughly 50% utilization if the surviving node needs to absorb the full workload with zero performance degradation after a failure. Don't over-index on that specific number — utilization isn't a universal capacity unit. But the shape of the recommendation is the point: two nodes running at 50% isn't wasted capacity. In an N-1 design, that apparent headroom is frequently the exact capacity you purchased for the failure you're hoping never happens — the same aggregate-versus-usable capacity gap that shows up anywhere utilization and contention get treated as the same number.

The Mature Question Isn't "Can It Stay Up?"

TNA has a longer production history than TNF — worth knowing, but secondary to the question that actually matters. The immature question is whether the platform remains available after a node is lost. Red Hat has already answered that convincingly for both topologies. The mature question is what the surviving infrastructure is expected to carry once it does — and that answer isn't in the release notes.

Getting that answer right is a governance question: what happens to that failure-capacity envelope across the platform's lifecycle — through upgrades, patches, and the licensing and cost pressures that tend to erode a capacity margin nobody's actively watching.

The same discipline applies during planned events, not just unplanned ones — rolling maintenance on a hyperconverged platform already means deliberately operating at N-1 for the duration of the window. A two-node cluster doesn't get a maintenance exemption from that arithmetic.

The Architecture Review Question

That isn't an abstract risk: while TNF is degraded, Red Hat disables cluster upgrades, etcd CA rotation, and fencing of the surviving node, and explicitly treats degraded operation as temporary. "How long can it stay degraded?" isn't a theoretical question — it's a documented operational constraint.

An architecture review that approves "two nodes" as an availability statement has approved the easy half of the decision. The harder half is this: are you buying two-node availability, or are you claiming two-node resilience?

📥 Download the 6-slide carousel (TNA vs. TNF, the availability-vs-capacity table, and the architecture-review question): https://rack2cloud.com/downloads/carousels/two-node-edge-deployment-carousel-v1.pdf

Architect's Verdict

Red Hat didn't remove the third node's job. It decomposed it. TNA keeps the coordination function alive in a component that costs almost nothing to run; TNF removes that component entirely and replaces its function with node isolation. What neither architecture restores is a third full-sized workload node standing by after a failure.

That's not a criticism of either topology — both are honest engineering responses to a real cost problem, and both keep the promise they actually make. The failure is downstream of the product, in the architecture review that treats "the cluster stayed up" as the whole answer.

Two-node edge deployment removes that margin for error. Approve the failure mechanism you're comfortable with — arbiter or fencing — and then size the surviving node for the day it's the only one left.

Originally published at rack2cloud.com