13

I have two machines (A and B, A is Master) running VRPP (from keepalived) for a Virtual IP.

How can I prevent A from becoming Master again if it has failed and come back up (for whatever reason)?

I'm doing this so that we have a single fail-over to the second box, and going back to normal would require manual intervention.

quanta
  • 50,327
  • 19
  • 152
  • 213
MrMahgu
  • 273
  • 1
  • 2
  • 6

3 Answers3

14

According to this relatively old thread on the keepalived developer list, it can be done. You set both servers to be equal priority (or none at all), and do not declare the state for either as MASTER or BACKUP, and instead set the state to EQUAL for both.

EDIT (07-Dec-2017):

It appears that EQUAL is not actually a valid state, despite it appearing to provide the desired effect at the time this answer was posted. Please note the comments below, in particular the link to the current issues list for keepalived provided by @cristi.

James Sneeringer
  • 6,755
  • 23
  • 27
  • 3
    Thank you -- Also worth a note, using above configuration (of equal priority and using "EQUAL") if no master has taken over, the VRRP instance with lowest IP will become MASTER. – MrMahgu Jul 22 '09 at 17:37
  • 1
    This is wrong. See this message from the developers: https://github.com/acassen/keepalived/issues/707 – cristi Dec 04 '17 at 10:27
  • @cristi - It was a working solution at the time it was posted (2009), which in turn was based on information I clearly acknowledged was old even then (2003). I've updated the link in my answer to a working one since osdir.com no longer seems to have the keepalived-devel archives. I would guess that, at the time, the software silently ignored the invalid `EQUAL` directive and treated it as though no priority was set at all (which just happened to have the desired effect). – James Sneeringer Dec 07 '17 at 15:37
8

The way we solved this is by adding the nopreempt flag to our keepalived config file. Didn't have to change anything else (still left one as MASTER and one as BACKUP and so on). Basically this tells it to not switch masters just because a new server came online, only switch when the current master fails.

quanta
  • 50,327
  • 19
  • 152
  • 213
davr
  • 1,729
  • 3
  • 14
  • 24
  • 4
    from "http://article.gmane.org/gmane.linux.keepalived.devel/1537" If "state" is set to MASTER, "nopreempt" is basically ignored since when the machine with "state MASTER" returns it will just grab the IP from the machine with "state BACKUP" without even holding an election. I had to set both my machines to state BACKUP with one having higher priority in order for "nopreempt" to function as intended. – MrMahgu Jul 22 '09 at 19:07
  • Deleted priority and state and added nopreempt. Works well for me – Rihard Novozhilov Sep 13 '19 at 12:22
-1

As I understand it, when a new VRRP server comes up, it forces an election, and the current server doesn't get any benefit, so the old master will come up and win the election. I doubt there is much you could do to stop this, beyond the rather brutal Shoot The Other Node In The Head. Keepalive may have some configuration to control the election process. Sadly I don't have time to check now, but I'll try to look later.

David Pashley
  • 23,151
  • 2
  • 41
  • 71
  • There is a config flag of doing this, so this answer is wrong. – davr Jul 22 '09 at 17:54
  • The voted answer is correct for a general deployment of vrrp where you don't want a master to take over when it returns to service. As you say, there is also a keepalived way of doing this which is probably more correct for when doing linux HA stuff instead of just using vrrp to provide L3 redundancy for a default route (the more traditional reason for using vrrp). – chris Jul 22 '09 at 18:59