Solution 1 :
Les paquets ne passent pas entre les machines sur l'interface em1 (provoquant un scénario de cerveau divisé comme l'indique Mike).
- vérifiez votre pare-feu pour vous assurer que les paquets ne sont pas interceptés
- vérifiez votre réseau pour vous assurer que em1 est le même réseau sur les deux machines
Voici un exemple de ce à quoi ressemble l'un des paquets :
Frame 2: 54 bytes on wire (432 bits), 54 bytes captured (432 bits)
Arrival Time: Jun 1, 2013 03:39:50.709520000 UTC
Epoch Time: 1370057990.709520000 seconds
[Time delta from previous captured frame: 0.000970000 seconds]
[Time delta from previous displayed frame: 0.000970000 seconds]
[Time since reference or first frame: 0.000970000 seconds]
Frame Number: 2
Frame Length: 54 bytes (432 bits)
Capture Length: 54 bytes (432 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ip:vrrp]
Ethernet II, Src: 00:25:90:83:b0:07 (00:25:90:83:b0:07), Dst: 01:00:5e:00:00:12 (01:00:5e:00:00:12)
Destination: 01:00:5e:00:00:12 (01:00:5e:00:00:12)
Address: 01:00:5e:00:00:12 (01:00:5e:00:00:12)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Source: 00:25:90:83:b0:07 (00:25:90:83:b0:07)
Address: 00:25:90:83:b0:07 (00:25:90:83:b0:07)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Type: IP (0x0800)
Internet Protocol Version 4, Src: 10.0.10.11 (10.0.10.11), Dst: 224.0.0.18 (224.0.0.18)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
Total Length: 40
Identification: 0x8711 (34577)
Flags: 0x00
0... .... = Reserved bit: Not set
.0.. .... = Don't fragment: Not set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 255
Protocol: VRRP (112)
Header checksum: 0x4037 [correct]
[Good: True]
[Bad: False]
Source: 10.0.10.11 (10.0.10.11)
Destination: 224.0.0.18 (224.0.0.18)
Virtual Router Redundancy Protocol
Version 2, Packet type 1 (Advertisement)
0010 .... = VRRP protocol version: 2
.... 0001 = VRRP packet type: Advertisement (1)
Virtual Rtr ID: 254
Priority: 151 (Non-default backup priority)
Addr Count: 1
Auth Type: No Authentication (0)
Adver Int: 1
Checksum: 0x3c01 [correct]
IP Address: 10.0.0.254 (10.0.0.254)
Solution 2 :
Pour mon cas, j'ai dû autoriser le trafic multicast à travers le pare-feu à 224.0.0.18 , pour ufw :
ufw allow from 224.0.0.18
ufw allow to 224.0.0.18
Cela m'a aidé.
Solution 3 :
Dans mon cas, pour CentOS/RHEL 8, je n'avais qu'à autoriser la règle riche du pare-feu pour le protocole vrrp pour résoudre ce problème de cerveau partagé Keepalived où les deux serveurs détenaient l'adresse IP VIP. J'ai dû ajouter l'indicateur de noyau sysctl pour permettre à HAProxy de se lier à une adresse IP VIP non locale.
Pour sysctl, ajoutez net.ipv4.ip_nonlocal_bind = 1 en /etc/sysctl.conf fichier puis faites un sysctl -p pour recharger la configuration sysctl. J'avais besoin de cela PAS pour le scénario Keepalived split-brain mais pour que HAProxy se lie à sa propre adresse IP pour les statistiques (ex:bind 192.168.0.10:1492/stats) et se lie à l'adresse VIP (IP virtuelle) pour le web d'équilibrage de charge trafic (lier 192.168.0.34:80 et lier 192.168.0.34:443). Sinon, le service HAProxy n'a pas pu démarrer, indiquant qu'il ne peut pas se lier aux ports 80 et 443 avec l'adresse IP VIP uniquement. Je faisais cela pour éviter d'avoir bind *:80 et bind *:443. De plus, cela semble évident mais facilement négligé, vérifiez si vous avez autorisé le port que vous utilisez pour les statistiques à travers le pare-feu si vous ne parvenez pas à accéder à la page des statistiques.
Pour le pare-feu, exécutez les commandes suivantes :
# firewall-cmd --add-rich-rule='rule protocol value="vrrp" accept' --permanent
# firewall-cmd --reload
J'ai trouvé ces drapeaux et d'autres informations directement à partir de la documentation RedHat pour HAProxy et Keepalived :
Référence du pare-feu :https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/load_balancer_administration/s1-lvs-connect-vsa
Référence du drapeau de liaison non local (cela a été utilisé pour HAProxy, car je n'utilisais pas Keepalived pour l'équilibrage de charge):https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/load_balancer_administration/s1-initial -setup-transfert-vsa
Juste HAProxy FYI:Si HAProxy ne parvient toujours pas à se lier aux ports, vous voudrez peut-être regarder le bon vieux SELinux le bloquer. Pour moi, sur CentOS 8, j'ai dû faire un semanage port -a -t http_port_t -p tcp 1492 pour ma page de statistiques HAProxy.