What happens to a 2-node cluster when the master node dies?

[paul.o]

I am looking at 2-node and 3-node ha/cluster configuration, testing out different dr scenarios. When I purposely disconnect the master node, seems the cluster wont survive. Any tips how to overcome this?

 

[sterzy]

Hey,

there isn't a "master node" per-se. Clustering is based on Corosync and that requires a majority of votes in a quorum to function. If you create a two node cluster and take down one node, no majority can be found as at most only 50% (1 vote) are voting. You'll need to set up a QDevice to improve your cluster's stability [1].

[1]: https://pve.proxmox.com/pve-docs/pve-admin-guide.html#_corosync_external_vote_support

Sorry forgot to check the forum and thought your post related to PVE clusters. Ignore that!

 

[paul.o]

Hi Stefan, thanks for the quick response. I am referring to this guide on proxmox mail gateway.

 

[sterzy]

Yes sorry, forgot to check which forum this relates to. The manual actually has a chapter on dealing with a master node failure [1]:

• Promote another node to be the master node: pmgcm promote
• Tell other nodes that the master has changed: pmgcm sync --master_ip <master_ip>

[1]: https://pmg.proxmox.com/pmg-docs/pmg-admin-guide.html#_master_failure

 

[paul.o]

Thank you Stefan. I was able to recover of a master node failure with that chapter. So it seems there is no auto failover happening. This means the mail gateway set-up is dependent on the availability of the master node. Has anyone achieve the auto-promote/auto-failover set-up?

 

[dcsapak]

This means the mail gateway set-up is dependent on the availability of the master node.

not quite. the rules and config are replicated to the slave nodes, and run independent of the master. so your mail setup should still work even without a running master
the only thing not working then is that you can't configure anything until you either fixed the master, or promoted a slave

 

[paul.o]

Hi Dominik, thank you. Yes that was the case based on testing. Seems great to me as a failsafe mechanism avoiding inconsistencies in the cluster, allowing master node only to hold the editing of config. This is a great approach. Thank you thank you!