Red Hat cuts OpenShift edge cluster footprint to two servers

Red Hat has described a two-server high-availability configuration for OpenShift edge deployments that removes the need for a separate arbiter machine, a response to customer concern over hardware costs. The IBM-owned software company did not quantify the expected savings, but said the pressure is coming from deployments spread across hundreds or thousands of locations.

Daniel Froehlich and Paul Lancaster of Red Hat said customers are asking for alternatives to larger edge cluster designs because adding, powering and maintaining a third device has become harder to justify as hardware prices rise. That is a notable admission for an edge platform vendor, since edge economics often break on operational details rather than software licensing alone.

Red Hat already supports two-node OpenShift clusters through an arbiter, a small system that helps the cluster decide which node should remain in control if connectivity fails. The arbiter requirements are modest: at least two virtual CPUs, 8GB of memory and 50GB of solid-state storage. Red Hat’s new approach is aimed at customers for whom even that extra footprint adds cost and operational overhead at scale.

How the two-node design works

The change relies on technology from the Red Hat Enterprise Linux High Availability Add-On, specifically Corosync and Pacemaker. Red Hat is using those components to apply fencing, a high-availability technique that prevents both servers in a two-node cluster from continuing to act as if they are in charge after a failure or network partition.

In a conventional split-brain failure, two nodes lose contact and each can assume it should take over. That can lead to parallel writes and inconsistent state. Red Hat’s explanation is that Corosync detects the failure condition, while Pacemaker on the surviving node treats the unreachable server as down and forces it to reboot or power off. That leaves one node running the workloads rather than two nodes making conflicting decisions.

The setup has a hardware dependency. Red Hat said the servers need a baseboard management controller that supports the Redfish API, since the surviving system must be able to control the failed or disconnected node’s power state. That requirement narrows the addressable hardware pool and could limit the appeal for customers trying to use lower-cost or older edge gear.

Resilience still has caveats

Red Hat also acknowledged that the design does not erase the hard cases in two-node clustering. If a disconnected node comes back after its independent power source is restored, Red Hat said it cannot guarantee consistency on restart. If both nodes fail and one later boots, manual intervention may be needed.

The target market is edge infrastructure that needs more resilience than a single machine but cannot absorb the cost or management burden of a larger cluster at every site. Retail locations running near-real-time video analysis are one example cited in the discussion around edge inference, where compute costs are already high before clustering overhead is added.

The move also matters for Red Hat’s broader platform positioning. Two-node OpenShift supports OpenShift Virtualization, giving Red Hat another way to pitch OpenShift as an alternative to VMware in smaller distributed environments. The claim is practical rather than flashy: fewer boxes can make edge deployments easier to justify, provided customers have the right management hardware and accept the recovery limits Red Hat has disclosed.

This story draws on original reporting from The Register.