keepalived ne détecte pas la perte de virtuelle IP

j'utilise keepalived Pour changer l'adresse IP flottante entre deux machines virtuelles.


/etc/keepalived/keepalived.conf

sur vm 1:

vrrp_instance VI_1 {
state MASTER
interface ens160
virtual_router_id 101
priority 150
advert_int 1
authentication {
auth_type PASS
auth_pass secret
}
virtual_ipaddress {
1.2.3.4
}
}


/etc/keepalived/keepalived.conf

sur vm 2:

vrrp_instance VI_1 {
state MASTER
interface ens160
virtual_router_id 101
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass secret
}
virtual_ipaddress {
1.2.3.4
}
}

Cela fonctionne essentiellement bien, à une exception près: chaque fois que systemd Mise à jour (Ça marche sous contrôle Ubuntu 18.04), Il redémarre son composant de réseau, qui conduit à la suppression d'une adresse IP flottante, car elle n'est pas configurée dans le système. Depuis les deux copies keepalived Vous pouvez toujours ping l'un d'autre, aucun d'entre eux ne voit rien de mal et aucun d'entre eux n'y réagit, à la suite de laquelle l'adresse IP flottante reste déconnectée.

J'ai trouvé que vous pouvez vérifier l'adresse IP avec un tel script simple:

vrrp_script chk_proxyip {
script "/sbin/ip addr |/bin/grep 1.2.3.4"
}

vrrp_instance VI_1 {
# [...]
track_script {
chk_proxyip
}
}

Mais je ne suis pas sûr que ceci est une approche de travail.

Si je comprends bien, si je configure ce script sur VM1, ce qui suit se produira:

VM1 perd IP En raison du redémarrage systemd

keepalived sur vm1 détecte la perte IP

Keepalived S'allume

FAULT

Statut et arrête les paquets de diffusion vrrp

Keepalived sur VM2 Détecte la perte keepalived sur VM1 et installe une adresse IP flottante

En ce moment IP Ouvrir à nouveau sur VM2, mais VM1 restera dans cet état parce que IP ne semblera jamais sur VM1. Si un VM2 sera hors de la construction (Pour une raison quelconque), VM1 ne la prendra pas sur lui-même parce qu'elle est toujours dans

FAULT

Etat.

Comment puis-je garantir que l'adresse IP flottante est toujours active sur l'une des machines virtuelles?

Autres tests:

J'ai essayé de mettre l'adresse IP flottante au lieu de vérifier s'il est actif sur un certain hôte de check_script:

vrrp_script chk_proxyip {
script "/bin/ping -c 1 -w 1 1.2.3.4"
interval 2
}

Définition de ce script sur le nœud 2 conduit à ce qui suit:

Suppression IP Sur le nœud 1 pour tester

nouer 2 Trouvé une perte IP et changé avec

BACKUP

à

FAULT

nouer 1 ignoré le changement de l'état et est resté

MASTER

Résultat: IP Il est resté éteint.

Configuration du script sur le nœud 1 conduit à ce qui suit:

Suppression IP Sur le nœud 1

nouer 1 Trouvé une perte IP et changé avec

MASTER

à

FAULT

nouer 2 Détecté une modification de l'état sur le nœud 1 et changé S.

BACKUP

à

MASTER

, Personnaliser flottant IP Sur le nœud 2

Eh bien ...

Feb 13 10:11:26 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Transition to MASTER STATE
Feb 13 10:11:27 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Entering MASTER STATE
Feb 13 10:11:29 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Received advert with higher priority 150, ours 100
Feb 13 10:11:29 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Entering BACKUP STATE
Feb 13 10:11:32 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Transition to MASTER STATE
Feb 13 10:11:33 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Entering MASTER STATE
Feb 13 10:11:36 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Received advert with higher priority 150, ours 100
Feb 13 10:11:36 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Entering BACKUP STATE
Feb 13 10:11:38 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Transition to MASTER STATE
Feb 13 10:11:39 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Entering MASTER STATE
Feb 13 10:11:41 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Received advert with higher priority 150, ours 100
Feb 13 10:11:41 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Entering BACKUP STATE
Feb 13 10:11:44 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Transition to MASTER STATE
Feb 13 10:11:45 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Entering MASTER STATE
Feb 13 10:11:47 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Received advert with higher priority 150, ours 100
...

J'ai dû redémarrer keepalived sur node1, Pour arrêter le jeu dans Ping Pong entre les nœuds.
Invité:

Dominique

Confirmation de:

Nous avons rencontré ce problème et avons décidé que ceci est un problème avec systemd-networkd dans ubuntu 18.04, Qui utilise maintenant netplan. Une version plus récente keepalived Il devrait le réparer, car il peut détecter la suppression d'une adresse IP flottante, qui provoque une commutation d'urgence, voir
https://github.com/acassen/keepalived/issues/836
.

Une version plus récente keepalived Indisponible B. 18.04, et au lieu d'essayer de sauvegarder, nous avons décidé de rester sur ubuntu 16.04 Et attendez jusqu'à ubuntu 20.04 Pour nos serveurs qui utilisent keepalived.

Hannah

Confirmation de:

Ce problème est fixé dans keepalived 2.0.0 de 26.05.2018, cm.
https://www.keepalived.org/changelog.html

Supprimer la surveillance VIP / eVIP et transition à la sauvegarde si VIP / eVIP Supprimé, déverrouille en configurant l'option de suivi.

Giselle

Confirmation de:

Je pense que votre approche partagée est bonne, mais vous devez repenser les conditions de test. L'état qui vous dérange est de redémarrer si systemd Infrastructure de réseau (conséquence indirecte de cela, que votre VIP), C'est donc ce que vous devez vérifier.

Je n'ai pas de système que je peux facilement tester, le gagne, donc YMMV, mais

systemctl is-active network.service

Peut-être assez pour le couvrir. Sinon, le contrôle de statut

systemctl show network.service | grep 'ActiveState'

Pour un état autre que "actif" devrait le faire.

Au fait, ne doit pas être configuré l'un de vos nœuds avec le statut "Sauvegarde" et non avec un "maître"?

Alice

Confirmation de:

En tant que contournement, j'ai configuré l'adresse IP flottante comme une adresse IP en option sur le nœud principal. (avec une priorité plus élevée)

/etc/netplan/01-netcfg.yaml

:

network:
version: 2
renderer: networkd
ethernets:
ens160:
addresses: [ 1.2.3.5/24, 1.2.3.4/24 ]
gateway4: 1.2.3.254
nameservers:
search: [ example.com ]
addresses:
- "1.2.3.40"

Ainsi, lors du chargement ou de la reconfiguration systemd L'adresse IP flottante est située sur le nœud principal. En cas d'échec, il procède au nœud secondaire à travers keepalived. Si le nœud principal renvoie une réponse, l'adresse IP est libérée en supportant l'activité du nœud secondaire.

En fait, ce n'est pas une solution, mais je ne vois rien encore.

Rafraîchir

Bien que cette solution de contournement fonctionnait, il avait des effets secondaires. Après avoir redémarré l'adresse IP flottante existait sur l'interface deux fois:

2: ens160: <broadcast,multicast,up,lower_up> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 00:50:56:a3:d7:d1 brd ff:ff:ff:ff:ff:ff
inet 1.2.3.5/24 brd 1.2.3.255 scope global ens160
valid_lft forever preferred_lft forever
inet 1.2.3.4/32 scope global ens160
valid_lft forever preferred_lft forever
inet 1.2.3.4/24 brd 1.2.3.255 scope global secondary ens160
valid_lft forever preferred_lft forever

Cela semble être affecté par tout ce qui a travaillé, mais cela m'a inquiété. En conséquence, j'ai eu
https://serverfault.com/a/956219/38644
et réinstallé des machines virtuelles avec Ubuntu 16.04.
</broadcast,multicast,up,lower_up>

Agathe

Confirmation de:

Je pense que vous pouvez vérifier ping sur une adresse IP flottante, puis quand il échoue, redémarrez le service keepalived Sur tous les nœuds

Tu IP Être écrit

Placer cronjob, qui commence chaque minute ou 5 minutes

Pour répondre aux questions, connectez-vous ou registre