Lösung 1:
Pakete werden nicht zwischen Computern auf der em1-Schnittstelle ausgetauscht (was zu einem Split-Brain-Szenario führt, wie Mike feststellt).
- Überprüfen Sie Ihre Firewall, um sicherzustellen, dass keine Pakete abgefangen werden
- Überprüfen Sie Ihr Netzwerk, um sicherzustellen, dass em1 auf beiden Computern dasselbe Netzwerk ist
Hier ist ein Beispiel dafür, wie eines der Pakete aussieht:
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)
Lösung 2:
In meinem Fall musste ich Multicast-Verkehr durch die Firewall zu 224.0.0.18 zulassen , für ufw:
ufw allow from 224.0.0.18
ufw allow to 224.0.0.18
Das hat mir geholfen.
Lösung 3:
In meinem Fall musste ich für CentOS/RHEL 8 nur die Firewall-Rich-Rule für das vrrp-Protokoll zulassen, um dieses Keepalived-Split-Brain-Problem zu lösen, bei dem beide Server die VIP-IP-Adresse hatten. Ich musste das sysctl-Kernel-Flag hinzufügen, damit HAProxy sich an nicht lokale VIP-IPs binden kann.
Fügen Sie für sysctl net.ipv4.ip_nonlocal_bind = 1 hinzu in /etc/sysctl.conf Datei und führen Sie dann sysctl -p aus zum Neuladen der sysctl config. Ich brauchte dies NICHT für das Split-Brain-Szenario von Keepalived, sondern um HAProxy an seine eigene IP-Adresse für Statistiken (z. B. bind 192.168.0.10:1492/stats) und an die VIP-Adresse (virtuelle IP) für das Load-Balancing-Web zu binden Verkehr (Bindung 192.168.0.34:80 und Bindung 192.168.0.34:443). Andernfalls konnte der HAProxy-Dienst nicht gestartet werden und gab an, dass er sich nicht nur mit der VIP-IP-Adresse an Port 80 und 443 binden kann. Ich habe dies getan, um zu vermeiden, *:80 und *:443 zu binden. Auch, fühlt sich wie ein Kinderspiel an, wird aber leicht übersehen, überprüfen Sie, ob Sie den Port, den Sie für Statistiken verwenden, durch die Firewall zugelassen haben, wenn Sie die Statistikseite nicht erreichen können.
Führen Sie für die Firewall die folgenden Befehle aus:
# firewall-cmd --add-rich-rule='rule protocol value="vrrp" accept' --permanent
# firewall-cmd --reload
Ich habe diese Flags und andere Informationen direkt aus der RedHat-Dokumentation für HAProxy und Keepalived gefunden:
Firewall-Referenz:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/load_balancer_administration/s1-lvs-connect-vsa
Nichtlokale Bind-Flag-Referenz (diese wurde jedoch für HAProxy verwendet, da ich Keepalived nicht für den Lastenausgleich verwendet habe):https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/load_balancer_administration/s1-initial -setup-forwarding-vsa
Nur HAProxy FYI:Wenn HAProxy immer noch nicht an Ports binden kann, sollten Sie sich das gute alte SELinux ansehen, das es blockiert. Für mich musste ich unter CentOS 8 einen semanage port -a -t http_port_t -p tcp 1492 machen für meine HAProxy-Statistikseite.