Red Hat’s Daniel Froehlich and Paul Lancaster are taking aim at an edge-deployment problem that is brutally practical: the “prohibitive cost of powering, maintaining, and deploying a third node across hundreds or thousands of sites.” In other words, edge customers are showing up to the party and refusing to bring the third server. Their new approach pushes high-availability OpenShift to work with fewer servers, specifically a two-server setup, by changing how the cluster handles the moment connectivity breaks.

The catch is what happens when two nodes lose contact. Red Hat notes that its existing two-node OpenShift setup can use an “arbiter” device to maintain quorum between the two nodes and help avoid the split-brain problem. That arbiter is not a free lunch: it needs at least two virtual CPUs, 8GB of RAM, and 50GB of solid-state storage. Froehlich and Lancaster’s pitch is that even this added machine, and the complexity of running it, has become an issue. So they adapt a technique called fencing so the cluster can treat a disconnected node as truly dead, rather than ambiguously alive.

Let’s unpack the split-brain problem in plain terms, because it is the real villain in this story. In a two-node cluster, a network partition can cause both servers to believe the other is gone, and both try to act as the primary. That can mean parallel work, possibly overwriting changes, and a mess you do not want to debug across “hundreds or thousands of sites.” Historically, high availability systems have to pick a single, consistent answer about who is in charge when the line between nodes goes quiet.

Red Hat’s updated two-server design takes tech from its Red Hat Enterprise Linux High Availability Add-On, specifically Corosync and Pacemaker, to implement fencing. The core idea is consistency by force. As Froehlich and Lancaster explain, “Fencing imposes consistency by requiring that Pacemaker on the surviving node forcefully powers down or reboots the failed or disconnected node.” That changes the cluster’s behavior at the exact point of uncertainty. Corosync declares a failure state when one node can no longer reach the other, but without fencing, the disconnected node might still be running. In a two-node rig without fencing, Pacemaker treats the lost node as definitively dead and takes over all work, which removes the possibility of the cluster entering split-brain.

This is not magic; it has a hardware requirement. Not every server can do this. Red Hat says you need a baseboard management controller that supports the Redfish API. That matters because fencing depends on being able to power down or reboot the node from the surviving side. For edge deployments, where the whole point is to reduce staff time and hardware footprint, that requirement can be either a smart standardization opportunity or a barrier to entry, depending on what hardware is already deployed.

The post also admits that two-node OpenShift still has challenges beyond fencing. One specific scenario is when one node comes back online after its independent power supply kicks back in. In those circumstances, Red Hat cannot guarantee consistency upon restart. And in the worst case, if both nodes go down and one restarts, manual intervention may be required. That is an important nuance for decision-makers: the proposal is designed to reduce the number of servers and avoid split-brain, but it does not claim to eliminate every operational edge case. It shifts which trade-offs matter most.

Why are these details suddenly urgent? Red Hat explicitly connects the motivation to a “recent steep increase in hardware prices.” Edge deployments often involve long, messy lifecycles across remote sites. When hardware costs rise, the cost of keeping an extra node alive and serviceable becomes harder to justify. The second-order effect is that buyers start to optimize for resilience per device, not resilience as an abstract topology. Red Hat also points out a likely deployment pattern for the future: pundits believe users will often deploy inferencing hardware at edge locations, such as retail sites analyzing video in near-real-time. Inferencing hardware is rarely cheap, and the edge site economics already run tight. So reducing node counts while maintaining enough consistency to keep workloads from diverging becomes a credible differentiator.

There is also a competitive angle. Two-node OpenShift supports Red Hat’s OpenShift Virtualization, making the platform a more potent challenger to VMware. In practice, this matters because virtualization and high-availability stacks tend to be evaluated together in enterprise procurement. If Red Hat can offer a topology that better matches the edge budget, it can strengthen the “platform” story, not just the orchestration story. For executives and boards, the strategic stakes are straightforward: if edge customers stop paying for third nodes, platforms that require them either lose deals or have to re-architect. Red Hat is trying to stay in the running by making a two-server design behave more like a three-node one, without the same hardware bill.