Step-by-step two node HA setup for Proxmox 5.0

[Mateusz B]

Hi

I know that's not officially supported, but I have no budget to spend on additional third server to provide HA

I want to prevent split-brain related problems with using bonded cross-connected (no switch between servers) network interfaces. I think that's well enough to prevent split-brain scenario due network connectivity problems. No ping from remote side will always mean problem with other server.

Does anyone have working setup example, how to get this running using latest Proxmox version?

I found some examples for older versions, but I'm not sure if they are still relevant in 5.0

 

[jeffwadsworth]

You can try some of the ideas here for a cheaper 3rd node. Note what was was written by


t.lamprecht

https://forum.proxmox.com/threads/two-node-high-availability-cluster-on-proxmox-4-x.23828/

 

[wolfgang]

I know that's not officially supported, but I have no budget to spend on additional third server to provide HA

It is not possible to have HA with 2 nodes.
see https://en.wikipedia.org/wiki/Byzantine_fault_tolerance

 

[Mateusz B]

It is not possible to have HA with 2 nodes.
see

That's not true and not applies to all kinds of systems. I've done multiple HA clusters with corosync or keepalived, all two node, all working OK and handling fail-overs gracefully, for many years. With bonded cross-conected NIC's I have never had any split-brain related problem

What's so unique with Proxmox that it absolutely require three nodes?

 

[jeffwadsworth]

They are trying to tell you that 2 node HA is not supported with Proxmox now.

 

[Alwin]

https://en.wikipedia.org/wiki/Byzantine_fault_tolerance

A Byzantine fault is any fault presenting different symptoms to different observers.[3] A Byzantine failure is the loss of a system service due to a Byzantine fault in systems that require consensus.[4]

The objective of Byzantine fault tolerance is to be able to defend against Byzantine failures, in which components of a system fail with symptoms that prevent some components of the system from reaching agreement among themselves, where such agreement is needed for the correct operation of the system. Correctly functioning components of a Byzantine fault tolerant system will be able to provide the system's service, assuming there are not too many faulty components.

In a two node setup, there are different views to the same failure.

For example, if a heartbeat is setup between two nodes and this heartbeat fails, which node is the working one and which isn't?

This usually leads to the "split brain" situation and that is why you need at least three views onto the same issue, so two parties can agree on a working state. That is where the Byzantine generals come into play.

High availability needs even more attention, if resources are shared, for example especially storage, that is very often the case in a HA setup. While a two node cluser is possible, a majority vote needs to be established through different channels then.

https://en.wikipedia.org/wiki/High-availability_cluster

HA clusters usually use a heartbeat private network connection which is used to monitor the health and status of each node in the cluster. One subtle but serious condition all clustering software must be able to handle is split-brain, which occurs when all of the private links go down simultaneously, but the cluster nodes are still running. If that happens, each node in the cluster may mistakenly decide that every other node has gone down and attempt to start services that other nodes are still running. Having duplicate instances of services may cause data corruption on the shared storage.