keepalived VRRP_script non esegue il failover


11

Quindi sto eseguendo keepalived su due server e non riesco a eseguire il failover sull'altro.

Di seguito ho la mia configurazione per uno dei server. L'unica differenza tra i due è il master dei numeri di priorità che è 110 e che è 109.

Ma quando interrompo il mio processo con /etc/init.d/process stop keepalived non esegue il failover. Ho appena ricevuto il VRRP_Script (chk_script) fallito e nient'altro. Nessun failover o niente.

vrrp_script chk_script {
script "/usr/local/bin/failover.sh"
interval 2
weight 2
}

vrrp_instance HAInstance {
state BACKUP
interface eth0
virtual_router_id 8
priority 109
advert_int 1
nopreempt
vrrp_unicast_bind 10.10.10.8
vrrp_unicast_peer 10.10.10.9
virtual_ipaddress {
  10.10.10.10/16 dev eth0
}
notify /usr/local/bin/keepalivednotify.sh
track_script {
  chk_script weight 20
}
}

Questo è il mio chk_script qui sotto. Lo stesso problema si verifica anche quando eseguo il processo killall -0 del mio script.

!/bin/bash
SERVICE='process'
STATUS=$(ps ax | grep -v grep | grep $SERVICE)

if [ "$STATUS" != "" ]
then
    exit 0
else
    exit 1
fi

Qualcuno sa una soluzione per questo? Grazie.


La tua istanza di backup nota la modifica della priorità o registra qualcosa? I registri di entrambi sarebbero utili.
Jim G.

No non lo fa. L'unica volta che nota un cambiamento è quando il maestro se ne va. Come quando mi fermo keepalived. L'arresto del processo che sto monitorando mostra solo VRRP_Script (chk_script) non riuscito sul master. Con niente sullo schiavo.
Nvasion,

Risposte:


13

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


Sembra anche che non specificare un peso significhi che un track_script fallito attiverà direttamente lo stato di errore
Oscar

@Nvasion: accetta gentilmente questa risposta perché anche il mio problema è stato risolto.
Ankur Soni,

4

Ho avuto lo stesso problema: due server CentOS 7.1 con track_script e la mancata esecuzione di vrrp_script sul MASTER comporterebbe solo il messaggio di registro solitario "VRRP_Script (chk_script) non riuscito", non in un failover. Sul server BACKUP, tuttavia, ho ricevuto molti messaggi di keepalived che cercavano di impadronirsi dell'IP virtuale per tutto il tempo in cui il track_script sul server MASTER non funzionava.

Soluzione nel mio caso: il firewall (iptables) sul server MASTER non è stato configurato correttamente per consentire i pacchetti VRRP / pacchetti multicast, mentre allo stesso tempo il firewall sull'altro server, il BACKUP, è stato configurato correttamente.

Avevo inserito le stesse regole di iptables in entrambi i server come segue:

iptables -A INPUT -i eth0 -d 224.0.0.0/8 -j ACCEPT
iptables -A INPUT -p vrrp -i eth0 -j ACCEPT

Funzionava su uno dei server (il server BACKUP VRRP) ma non su quello MASTER perché avevo dimenticato che l'interfaccia non era chiamata "eth0" sul server MASTER, quindi le due regole non avevano alcun effetto.

Questo ha spiegato il comportamento che avevo osservato:

Se keepalived non può vedere nessun altro oratore VRRP per un certo virtual_router_id, si ritiene comunque quello con la massima priorità (quindi il legittimo MASTER) anche dopo una modifica del peso negativo in quanto non riceve mai messaggi VRRP con una priorità superiore alla sua ( perché gli annunci pubblicitari di altri altoparlanti sono bloccati dal firewall e non possono mai raggiungere il processo keepalived per renderli consapevoli di loro). Ecco perché non lo vedi rilasciare il VIP.

Il server BACKUP, tuttavia, è stato in grado di vedere le pubblicità del (ora fallito) MASTER, ha trovato la priorità in quei pacchetti ridotta a un valore inferiore al suo e ha proceduto a dichiararsi MASTER e inviare ARP gratuiti per rivendicare il VIP. Quindi siamo finiti in una situazione in cui entrambi i server pensavano che avrebbero dovuto servire il VIP come MASTER.

Conclusioni: - Controllare sempre la configurazione del firewall su tutti gli altoparlanti VRRP se si verificano comportamenti strani (nessun failover, diversi MASTER). La registrazione keepalived non è così utile come potrebbe essere (un semplice messaggio "VIP non rilasciato perché sono ancora il più alto prio" dopo che la riga "VRRP_Script (chk_script) non è riuscita" avrebbe facilitato immensamente la risoluzione dei problemi.

  • Un track_script non è un tipo di interruttore on / off ("se lo script è OK: idoneo per le elezioni VIP; se NON OK: completamente non ammissibile per le elezioni VIP") - aumenta semplicemente / diminuisce la probabilità di vincere le elezioni, e se mantenuto solo si è mai visto come l' unico oratore VRRP e non riceve mai messaggi da altri oratori, non c'è davvero molta elezione - vinci sempre.

0

Mi sono appena imbattuto nella tua stessa situazione e ho studiato a proposito di keepalived. Pensiamo a cosa sta succedendo in ciascun server. Supponendo di voler implementare l'architettura di failback manuale,

Sul primo nodo BACKUP

Ogni volta che track_script fallisce il numero di volte di caduta , invia l'annuncio al secondo nodo BACKUP. Punto qui è la priorità impostata all'interno dell'annuncio. Nel tuo caso,

129 (109 + 20)

viene inviato al secondo server BACKUP.

Sul secondo server BACKUP

Il prossimo è sul secondo nodo BACKUP.

Secondo RFC ,

If the Priority in the ADVERTISEMENT is Zero, then:

  o  Set the Master_Down_Timer to Skew_Time
else:

  If Preempt_Mode is False, or If the Priority in the
  ADVERTISEMENT is greater than or equal to the local
  Priority, then:

    o Reset the Master_Down_Timer to Master_Down_Interval
  else:

    o Discard the ADVERTISEMENT
  endif
endif

Poiché non hai abilitato nopreempt e ricevi vrrp con priorità più alta, il secondo nodo BACKUP non andrà in fase di transizione.

Soluzione

Quindi, se vuoi far avvenire la transizione di stato sul secondo nodo, puoi

  1. Impostare il peso su 0 sul primo nodo BACKUP. Questo invierà l' annuncio con priorità 0 al secondo nodo BACKUP. il documento descrive di più sul peso 0.

  2. Disattiva nopreempt sul secondo nodo BACKUP.

  3. Impostare il peso su almeno -2 sul primo nodo BACKUP.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.