Build1 publisher2 min readPublished
Red Hat's two-node OpenShift edge clusters leave one survivor carrying the whole workload
TNA keeps a third etcd vote in a lightweight arbiter; TNF fences the dead node over its BMC. Both keep an edge cluster running on two servers, and both leave one survivor to run everything the site was running.
The Engineer · Build desk
What happened
- Red Hat now has two production-grade ways to run an OpenShift edge cluster on two servers instead of three, and each solves the failure-coordination problem by a different mechanism.
- In the arbiter topology, two full-sized nodes carry every workload while the lightweight third participant holds only the third etcd vote and runs no workloads or control-plane components of its own.
- Red Hat positions that arbiter topology as preserving the same HA characteristics as a standard three-node cluster, and made it generally available with OpenShift 4.20.
- The fencing topology reached general availability with OpenShift 4.22 in July 2026, two releases after the arbiter topology's 4.20 debut.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- cost A two-node bill of materials takes out the third box's power circuit, rack space, shipping and every truck roll it would have needed. The site operator books that saving a few hundred times over.
- decision Sizing moves: each of the two remaining nodes has to be specified to carry the whole site's workload alone, so some of the deleted server's cost comes back as bigger nodes.
- constraint Quorum-based health signals stay silent on whether the survivor can absorb the load, so capacity headroom needs instrumentation of its own.
- exposure Sites already running both nodes hot are the ones exposed, because the failed node's workload lands on a server that was already busy.
Losing a node runs differently in the control plane under each topology and identically in the data plane. Under TNA, the arbiter's vote plus the survivor's is two out of three, so etcd keeps quorum [2]. Under TNF there is no third participant of any kind [4], so Pacemaker and Corosync fence the unresponsive node through its BMC and the survivor carries on without split-brain risk [5]. The arbiter's job ends at the vote [2]. Either way, the pods from both nodes end up on one server [8].
Two workload-bearing nodes and one survivor put a ceiling on steady-state utilization. To bring the whole workload through a single node failure, each node has to sit at or below 50 percent [1]. At 65 percent per node, the survivor is asked for 130 percent of what one node can deliver [2]. Whether 50 percent transfers to a given fleet depends on three things: requests and limits that reflect real usage, pods from the failed node that the survivor will admit, and no pod pinned to the dead node by local state. Where any of those breaks down, the working ceiling sits below half.
The dev.to post from ntctech sets the two topologies side by side. It is precise about the distinction: removing the third full-sized server does not remove high availability, it removes one full unit of failure capacity [10]. It also concedes the caveat that makes the argument fair. N+1 is a design condition, not a node count. A three-node cluster run hot enough that two survivors cannot carry the load never had N+1, and the third node made the shortfall less obvious [11].
Red Hat's TNF documentation, as cited in that post, says the surviving node keeps the cluster running after a fence, with HA redundancy lost and the cluster degraded until the second node returns [7]. Quorum can be intact in the same minutes the survivor is over-committed. The post does not give arbiter sizing requirements or fencing timeouts.
In my view TNA is the easier of the two to defend at review, because TNF's protection depends on a management controller being reachable on the box that just failed [5]. The compute problem afterwards is the same in both [8]. The difference is what has to be working before the survivor is allowed to continue: a vote that lives somewhere else [2], or a BMC on the failed node [5].
What to watch
- A published reference architecture stating supported node sizes for two-node sites, so operators can test the 50 percent ceiling against a real BOM.
- Field reports of a TNA or TNF site where the survivor could not admit the failed node's pods after a fence.
- Whether Red Hat makes TNF available below 4.22, since fleets standardised on 4.20 otherwise need a version jump to adopt it.