Goal and context
In edge environments, we often only have two machines available in a given location: cost and power constraints, limited rack space, mobility requirements, or the lack of connectivity that would make adding a third node realistic.
At the same time, expectations around high availability (HA) are similar to those in a data center: automatic failover, resilience to hardware and/or software failures, split‑brain control, and fast recovery.
The challenge is that most popular HA technologies (clusters, distributed systems, databases) are designed for (at least) 3 nodes to achieve quorum and make safe decisions in ambiguous situations (for example, during network partitions).
In this article I collect practical options for a two‑node cluster: from classic resource clusters (Pacemaker), through virtualization (Proxmox/Hyper‑V/VMware), to storage and databases.
I focus on what actually works in the field, what the boundary conditions are, and where the traps are.
Assumptions: two nodes (Node A and Node B) in a single location, automatic failover required, and workloads can run as a system service, VM, or containers.
Why two nodes are hard: split‑brain and quorum
In a two‑node cluster, the key risk is split‑brain: a situation where both nodes decide “the other one is down” and both try to take over resources at the same time (VIP, volume, leader role, writes to the same database, etc.).
In consensus‑based systems (Raft/Paxos) and many enterprise products, requiring an odd number of votes eliminates part of the ambiguity.
Two nodes cannot, on their own, decide “who is right” when communication breaks.
Common mitigation strategies
-
Witness (tie‑breaker / quorum device) – We add a third “vote”, but not as a full compute node. – A witness can be:
- a small VM (for example in the cloud),
- a device in the same network (for example a NAS),
- an arbitration service (qdevice),
- a storage component (for example a witness disk).
-
Fencing (STONITH) + preference rules – When nodes lose contact, the cluster must be able to power off the other node or otherwise cut its access to resources (power/IPMI, iDRAC/iLO, PDU, BMC, watchdog). – In edge deployments this can be difficult (no managed PDU, heterogeneous hardware).
-
Active/Passive instead of Active/Active – We simplify the architecture: one node active, the other on standby. – This is often easier to get right, at the cost of reduced flexibility.
-
Asymmetry / priorities / “one node always wins” – Possible, but risky if there is no hard mechanism to remove access to shared resources.
Practical edge design questions
Before you pick a technology, it’s helpful to answer a few questions:
- Does the application tolerate brief downtime (seconds/minutes)?
- Are the data shared (single volume) or replicated (copies on both nodes)?
- Can you place a witness outside the site (for example a small cloud instance / VPS)?
- Do you have fencing (IPMI/iLO/iDRAC, PDU) or at least a watchdog?
- Does HA cover:
- system services,
- containers,
- virtual machines,
- storage,
- databases,
- or all of the above?
Approach 1: classic resource cluster (Pacemaker/Corosync)
Open source: Pacemaker + Corosync (+ SBD/qdevice)
This is one of the most mature and flexible HA stacks on Linux.
A common two‑node pattern is:
- Corosync as the cluster communication layer,
- Pacemaker as the resource manager (VIPs, services, promotable resources),
- fencing/STONITH and/or SBD (Storage Based Death) or qdevice as a tie‑breaker.
Documentation and references:
– Pacemaker: https://clusterlabs.org/pacemaker/
– Corosync: https://corosync.github.io/corosync/
– “ClusterLabs” docs: https://clusterlabs.org/
– SBD (used for example by SUSE): https://github.com/ClusterLabs/sbd
– corosync-qdevice (quorum device for 2 nodes): https://github.com/corosync/corosync-qdevice
Advantages
- Very flexible: you can “wrap” almost any service.
- Works great in an active/passive model.
- Well known in enterprise ecosystems (SUSE, RHEL‑like).
Two‑node challenges
- You must intentionally solve quorum (qdevice) or implement strong fencing.
- Without fencing, split‑brain is easy—especially with shared storage.
Commercial / enterprise distributions of this approach
- SUSE Linux Enterprise High Availability Extension: https://www.suse.com/products/highavailability/
- Red Hat High Availability Add‑On: https://www.redhat.com/en/technologies/linux-platforms/enterprise-linux/high-availability
In practice these solutions still rely on Pacemaker/Corosync, but you get tooling, support, and hardened scenarios.
Approach 2: HA at the virtualization layer (2 hosts + witness)
If your workloads run as VMs, it’s often simplest to provide HA at the hypervisor layer.
Proxmox VE (open source)
Proxmox uses corosync for cluster membership and typically expects at least 3 votes for full quorum.
For 2 nodes, a typical approach is QDevice as a witness.
- Proxmox VE: https://www.proxmox.com/en/proxmox-virtual-environment/overview
- Proxmox cluster/Corosync/QDevice docs (search for pvecm qdevice): https://pve.proxmox.com/pve-docs/
Benefit: you get HA by restarting VMs on the other host.
Drawback: you still need a third vote (even as a small witness).
VMware vSphere (commercial)
VMware HA/DRS is a common choice in data centers.
Two‑host configurations are also used at the edge (with various trade‑offs), plus tie‑break mechanisms (for example witness for storage / vSAN witness in ROBO scenarios).
- vSphere High Availability: https://docs.vmware.com/en/VMware-vSphere/index.html
- vSAN 2‑Node + Witness (concept): https://core.vmware.com/vsan-2-node-cluster-guide
Microsoft Hyper‑V Failover Cluster (commercial)
Windows Server Failover Clustering supports two‑node setups with a witness: File Share Witness or Cloud Witness.
- Failover Clustering: https://learn.microsoft.com/en-us/windows-server/failover-clustering/failover-clustering-overview
- Cloud Witness: https://learn.microsoft.com/en-us/windows-server/failover-clustering/deploy-cloud-witness
At the edge this is often very practical: the “third vote” can be in the cloud and is lightweight.
Approach 3: data replication + application failover (no shared storage)
At the edge, the “each node has its own disks” approach is often better, and data are replicated.
Split‑brain is still dangerous (two primaries), but you no longer have a single shared volume that’s easy to corrupt.
DRBD + Pacemaker (open source)
DRBD replicates block devices between nodes and is typically used as active/passive (primary/secondary).
It is often combined with Pacemaker.
- DRBD: https://linbit.com/drbd/
- LINBIT (vendor; open source + commercial model): https://linbit.com/
For two nodes, DRBD is a proven pattern, but you must take care of:
- fencing and/or mechanisms that prevent dual‑primary,
- resource promotion policy,
- network partition testing.
Database‑level replication
If the main problem is the database, sometimes it’s better to build HA within the DB layer than across the whole server.
Examples (briefly):
- PostgreSQL: streaming replication + (for example) Patroni (more commonly 3+), but with 2 nodes you usually still need a witness or an external DCS.
- Patroni: https://patroni.readthedocs.io/
- MySQL / MariaDB: async replication, Group Replication (usually 3+), Galera (usually 3+).
- MariaDB Galera Cluster: https://mariadb.com/kb/en/galera-cluster/
Approach 4: Kubernetes on two nodes (and what about the control plane?)
Kubernetes (etcd) assumes an odd number of quorum members.
A “production” two‑node cluster is possible, but requires conscious trade‑offs:
- control plane can be single‑node (reducing HA),
- or two control‑plane nodes + a third external etcd member (witness) / external etcd,
- or a managed control plane outside the site (sometimes unacceptable for edge).
References: – etcd quorum: https://etcd.io/docs/ – Kubernetes HA (official docs): https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/
Approach 5: active/active at the application level (no hard failover)
Sometimes the best option in a two‑node edge scenario is… not to build a classic cluster.
Instead:
- you run the application actively on both nodes,
- distribute traffic via a load balancer or DNS,
- keep data in an “eventually consistent” model or with conflict resolution.
This approach is harder for applications, but can be more tolerant to network issues, because it doesn’t require “a single leader” in every situation.
Good practices for two‑node setups (regardless of technology)
- Always design for network partitions, not just node failures.
- Use a tie‑breaker: qdevice / cloud witness / file share witness / witness VM.
- If you use shared storage, fencing is mandatory.
- Automate HA tests:
- cutting network,
- resetting a node,
- losing storage,
- rejoining the node back to the cluster.
- Collect cluster metrics and logs in one place (edge is often offline‑friendly).
Summary
A two‑node HA cluster is like a “bridge suspended on two points”: it can be done, but it needs an additional decision mechanism (witness) and/or a hard cut‑off (fencing).
The most practical, repeatable patterns at the edge are:
- 2 nodes + witness (cloud/VM/qdevice) — the cleanest approach to quorum,
- Pacemaker/Corosync + fencing/SBD for Linux services,
- hypervisor HA for VM‑based environments,
- DRBD for data replication without shared storage.
In two‑node clusters, you need to add a third element that helps decide which node should remain active—even if that third element is a human administrator 🙂
In upcoming articles I’ll try to describe a solution developed by our team specifically for edge servers.
The Systegrate HA cluster solution combines several of the above approaches into a coherent whole, allowing you to: – keep state in a key=value store, – fail over the HA cluster, – provide ways of handling emergency situations.
—
References and further reading
[1] https://learn.microsoft.com/en-us/windows-server/failover-clustering/failover-clustering-overview
[2] https://clusterlabs.org/pacemaker/
[3] https://etcd.io/docs/
[4] https://clusterlabs.org/
[5] https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/
[6] https://clusterlabs.org/pacemaker/doc/
[7] https://corosync.github.io/corosync/
[8] https://learn.microsoft.com/en-us/windows-server/failover-clustering/deploy-cloud-witness
[9] https://pve.proxmox.com/pve-docs/
[10] https://github.com/corosync/corosync-qdevice
[11] https://core.vmware.com/vsan-2-node-cluster-guide
[12] https://linbit.com/drbd/
[13] https://patroni.readthedocs.io/
[14] https://github.com/ClusterLabs/sbd
[15] https://www.suse.com/products/highavailability/
[16] https://mariadb.com/kb/en/galera-cluster/
[17] https://www.cs.cornell.edu/home/rvr/papers/OSDI04.pdf
[18] https://medium.com/@johanesmistrialdo/simple-2-node-kubernetes-deployment-with-kubeadm-bb9b3385b950
NOTE: This article was prepared with the use of AI tools to support the writing and editing process.