New variants of OpenShift topologies, targeting two nodes deployments - Part 1
Â
Customer Demand for High Availability on two nodes only (esp. Retail, Industrial, Telco)
Main Driver: Cost for large scale deployments of the 3d node.
How:Â
Two Node OpenShift with Arbiter (TNA)Â đşđ˝
Two Node OpenShift with Fencing (TNF)Â đ
Â
Two Node OpenShift with Arbiter (TNA) - GA Red Hat Openshift V4.20
You can install a cluster with two control plane nodes and one local arbiter node by using one of the following methods:
- Installing on bare metal:Â Configuring a local arbiter node
- Installing with the Agent-based Installer:Â Configuring a local arbiter node
- Two node solution for cost sensitive customersÂ
- Small arbiter node (2 vCPU, 8Gi), running only 3d etcd instance
- Technically a three node cluster
- Arbiter Node is a regular node and could be used to run additional components/workload
- Arbiter node can be co-located (same chassis)
- Arbiter Node is free of charge
- Arbiter node has to be within <500msec max effective end to end latency (incl. Disc io)
- X86 and Arm, bare metal only (platform = none/baremetal), no cloud provider integrationÂ
- any RHEL 9 / OpenShift certified Hardware, e.g. NUC style for the arbiter
- OCP Virtualization fully supported
- See the product documentation
Â
Two Node OpenShift with Fencing (TNF) - Red Hat Openshift V4.20 Tech Preview
- True two node solution for cost sensitive customersÂ
- Relies on proven RHEL-HA technologies (corosync, pacemaker) to provide etcd HA
- Uses fencing to protect against split brain situations: the surviving node power downs the failed node to ensure consistency
- Requires a Base Management Controller (BMC) that supporters RedFish for fencing
- Node local storage supported (e.g. LVMS)
- Shared / Distributed Storage options currently under investigation with partners
- X86, bare metal only
- OCP Virt supportedÂ
Â
Â
