Ho avuto esattamente lo stesso problema, tuttavia il mio problema non era nel firewall né nel mio adattatore Ethernet, ma nelle impostazioni "peso" dello script di controllo.
Questa era la mia configurazione:
MAESTRO:
vrrp_instance haproxy {
state MASTER
interface eth0
virtual_router_id 51
priority 150
advert_int 1
BACKUP:
vrrp_instance haproxy {
state BACKUP
interface eth0
virtual_router_id 51
priority 100
advert_int 1
Check_script:
vrrp_script chk_haproxy {
script "python /root/ha_check.py"
interval 2 # check every 2 seconds
weight 2
rise 2
fall 2
}
Il motivo per cui il master si stava rifiutando di rilasciare il VIP era perché, nonostante il fatto che lo script fosse fallito, il master aveva ancora un numero di priorità più elevato dal server BACKUP. Ciò è accaduto perché l'impostazione "peso" su check_script non era sufficiente a coprire il "GAP" tra il numero di priorità, il che significa aumentare il numero di priorità del server BACKUP maggiore di quello di MASTER Server. Spiegherò ulteriormente:
Secondo il manuale di keepalived, un numero positivo sull'impostazione "peso" aggiungerà quel numero alla priorità se il controllo ha esito positivo.
Un numero negativo sottrarrà quel numero dal numero di priorità se il controllo fallisce.
Quindi, secondo la mia configurazione:
Priorità del server Errore precedente dello script:
MASTER: 152
BACKUP: 100
Failover_IP: MASTER
L'ip di failover viene correttamente "acquisito" dal server principale poiché il Master ha una priorità più alta rispetto al server di backup (152> 100)
Priorità del server DOPO errore dello script:
server MASTER: 148
server BACKUP: 102
Failover_IP: STILL ON MASTER
L'ip di failover è ancora sul server principale perché il Master ha di nuovo una priorità più alta rispetto a BACKUP (148> 102). Il server MASTER si stava rifiutando di rilasciare l'IP e lo ha fatto proprio perché la sua priorità era più alta dell'altro server.
La soluzione alla mia situazione era:
Soluzione -1: modificare il numero di priorità di entrambi i server in modo che non abbiano molto "GAP".
Ad esempio:
Priorità principale: 150
Priorità backup: 149
Peso Check_script: Come è (2).
Con la configurazione sopra, quando lo script ha
esito positivo (significa che tutto è ok) le priorità sarebbero:
Master: 152
Backup: 149
IP_Location: On Master (152> 149)
Quando lo script non riesce:
Master: 150
Backup: 151
IP_Location: su backup (151> 150)
Soluzione - 2: modifica il numero di peso dello script da 2, a -60