keepalived VRRP_script ne basculant pas

Je lance donc keepalived sur deux serveurs et je n'arrive pas à le faire basculer sur l'autre.

Ci-dessous, j'ai ma configuration pour l'un des serveurs. La seule différence entre les deux est que le numéro de priorité maître est 110 et le retour 109.

Mais quand j'arrête mon processus avec /etc/init.d/process stop keepalived ne bascule pas. Je reçois juste le VRRP_Script (chk_script) a échoué et rien d'autre. Pas de basculements ou rien.

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
}
}

Voici mon chk_script ci-dessous. Le même problème se produit également lorsque je fais le processus killall -0 comme mon script.

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

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

Quelqu'un connaît-il une solution à cela? Merci.

J'ai eu exactement le même problème mais mon problème n'était pas dans le pare-feu ni dans mon adaptateur Ethernet mais dans les paramètres de "poids" du script de vérification.

C'était ma configuration:

MAÎTRE:

vrrp_instance haproxy {
state MASTER
interface eth0
virtual_router_id 51
priority 150
advert_int 1

SAUVEGARDE:

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

}

La raison pour laquelle le maître refusait de libérer le VIP était que malgré le fait que le script ait échoué, le maître avait toujours un numéro de priorité plus élevé du serveur BACKUP. Cela s'est produit parce que le paramètre "weight" sur check_script n'était pas suffisant pour couvrir le "GAP" entre le numéro de priorité, ce qui signifie augmenter le numéro de priorité du serveur BACKUP supérieur à celui de MASTER Server. J'expliquerai plus loin:

Selon le manuel de keepalived, un nombre positif sur le paramètre "poids" ajoutera ce nombre à la priorité si le contrôle réussit.
Un nombre négatif soustrait ce nombre du numéro de priorité si la vérification échoue.

Donc, selon ma configuration:

Priorités du serveur Échec préalable du script:
MASTER: 152
BACKUP: 100
Failover_IP: MASTER

L'IP de basculement est correctement «saisie» par le serveur maître car le maître a une priorité plus élevée que le serveur de sauvegarde (152> 100)

Priorités du serveur APRÈS l'échec du script:
serveur MASTER: 148
serveur BACKUP: 102
Failover_IP: STILL ON MASTER

L'IP de basculement est toujours sur le serveur maître car Master a encore une priorité plus élevée que BACKUP (148> 102). Le serveur MASTER refusait de libérer l'adresse IP et il l'a fait car sa priorité était plus élevée que l'autre serveur.

La solution à ma situation était:

Solution -1: Modifiez le numéro de priorité des deux serveurs afin qu'ils n'aient pas beaucoup de "GAP".
Par exemple:
Master Priority: 150
Priority Priority: 149
Check_script weight: Tel quel (2).

Avec la configuration ci-dessus, lorsque le script réussit (ce qui signifie que tout va bien), les priorités sont les suivantes:
Maître: 152
Sauvegarde: 149
IP_Location: Sur maître (152> 149)

Lorsque le script échoue:
Maître: 150
Sauvegarde: 151
IP_Location: En sauvegarde (151> 150)

Solution - 2: changez le numéro de poids du script de 2 à -60

J'ai eu le même problème - deux serveurs CentOS 7.1 avec track_script, et l'échec du vrrp_script sur le MASTER ne ferait que provoquer le message de journal solitaire "VRRP_Script (chk_script) a échoué", pas dans un basculement. Sur le serveur BACKUP, cependant, j'ai reçu beaucoup de messages de keepalived essayant de prendre en charge l'IP virtuelle aussi longtemps que j'avais échoué le track_script sur le serveur MASTER.

Solution dans mon cas: le pare-feu (iptables) sur le serveur MASTER n'était pas configuré correctement pour autoriser les paquets VRRP / paquets de multidiffusion, tandis que le pare-feu sur l'autre serveur, le BACKUP, était configuré correctement.

J'avais entré les mêmes règles iptables sur les deux serveurs comme suit:

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

Cela fonctionnait sur l'un des serveurs (le serveur BACKUP VRRP) mais pas sur le MASTER car j'avais oublié que l'interface n'était pas nommée 'eth0' sur le serveur MASTER, donc les deux règles n'avaient aucun effet.

Cela expliquait le comportement que j'avais observé:

Si keepalived ne peut voir aucun autre haut-parleur VRRP pour un certain virtual_router_id, il se croit toujours être celui avec la priorité la plus élevée (donc MASTER légitime) même après une modification de poids négative car il ne reçoit jamais de messages VRRP avec une priorité supérieure à la sienne ( parce que les publicités d'autres haut-parleurs sont bloquées par le pare-feu et ne peuvent jamais atteindre le processus keepalived pour en avoir connaissance). C'est pourquoi vous ne le voyez pas libérer le VIP.

Le serveur BACKUP, cependant, a pu voir les publicités du MASTER (maintenant échoué), a trouvé la priorité dans ces paquets réduite à une valeur inférieure à la sienne, et a continué à se déclarer MASTER et à envoyer des ARP gratuits pour réclamer le VIP. Nous nous sommes donc retrouvés dans une situation où les deux serveurs pensaient qu'ils auraient besoin de servir le VIP en tant que MASTER.

Conclusions: - Vérifiez toujours la configuration du pare-feu sur toutes les enceintes VRRP si vous rencontrez un comportement étrange (pas de basculement, plusieurs MASTERs). La journalisation persistante n'est pas aussi utile qu'elle pourrait l'être (un simple message "VIP non publié car je suis toujours le plus élevé" après l'échec de la ligne "VRRP_Script (chk_script)" aurait énormément facilité le dépannage.

• Un track_script n'est pas un interrupteur de type marche / arrêt ("si le script est OK: éligible pour l'élection VIP; s'il n'est PAS OK: complètement inéligible pour l'élection VIP") - il augmente / diminue simplement la probabilité de gagner l'élection, et s'il est conservé uniquement s'observe toujours comme le seul orateur VRRP et ne reçoit jamais de messages d'autres orateurs, il n'y a pas vraiment d'élections - vous gagnez toujours.

Je suis juste tombé sur la même situation que toi et j'ai fait des études sur Keepalived. Réfléchissons à ce qui se passe sur chaque serveur. En supposant que vous souhaitiez implémenter l'architecture de rétablissement manuel,

Sur le 1er nœud BACKUP

Chaque fois que le track_script échoue, le nombre de fois où il tombe tombe , il envoie la publication au 2e nœud BACKUP. Le point ici est la priorité définie à l'intérieur de la publicité. Dans ton cas,

129 (109 + 20)

est envoyé au 2ème serveur BACKUP.

Sur le 2ème serveur BACKUP

Vient ensuite sur le 2e nœud BACKUP.

Selon 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

Étant donné que vous n'avez activé aucun préempt et que vous recevez un vrrp de priorité plus élevée, le deuxième nœud BACKUP ne passera pas en phase de transition.

Solution

Donc, si vous voulez que la transition d'état se produise sur le 2e nœud, vous pouvez le faire,

1. Définissez le poids à 0 sur le 1er nœud BACKUP. Cela enverra une annonce de priorité 0 au deuxième nœud BACKUP. doc décrit plus sur le poids 0.

2. Désactivez le nopreempt sur le 2e nœud BACKUP.

3. Définissez le poids sur au moins -2 sur le 1er nœud BACKUP.