it-swarm.com.de

keepalived erkennt keinen Verlust der virtuellen IP

Ich verwende keepalived, um eine Floating-IP zwischen zwei VMs zu wechseln.

/etc/keepalived/keepalived.conf on 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 on 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
    }
}

Dies funktioniert grundsätzlich einwandfrei, mit einer Ausnahme: Jedes Mal, wenn systemd aktualisiert wird (es läuft unter Ubuntu 18.04), wird die Netzwerkkomponente neu geladen, was dazu führt, dass die Floating-IP gelöscht wird, da sie nicht im System konfiguriert ist. Da sich beide Keepalived-Instanzen immer noch gegenseitig anpingen können, sieht keiner von ihnen etwas Falsches und keiner von ihnen reagiert darauf, was dazu führt, dass die schwebende IP nicht funktioniert.

Ich habe festgestellt, dass Sie mit einem einfachen Skript wie diesem nach der IP suchen können:

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

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

Ich bin mir aber nicht sicher, ob dies ein funktionierender Ansatz ist.

Wenn ich es richtig verstehe, würde Folgendes passieren, wenn ich dieses Skript auf VM1 konfiguriere:

  1. VM1 verliert die IP aufgrund eines Neustarts des Systems
  2. keepalived auf VM1 erkennt den Verlust der IP
  3. keepalived wechselt in den Status FAULT und beendet die Übertragung von vrrp-Paketen
  4. keepalived auf VM2 erkennt den Verlust von Keepalived auf VM1 und stellt die Floating-IP auf

Zu diesem Zeitpunkt funktioniert die IP auf VM2 wieder, aber VM1 würde in diesem Zustand bleiben, da die IP auf VM1 nie wieder angezeigt wird. Wenn VM2 ausfällt (aus welchem ​​Grund auch immer), würde VM1 es nicht übernehmen, da es sich noch im Zustand FAULT befindet.

Wie kann ich sicherstellen, dass die Floating-IP auf einer der VMs immer aktiv ist?

Weitere Tests:

Ich habe versucht, die Floating-IP zu pingen, anstatt zu überprüfen, ob sie auf einem bestimmten Host in einem check_script aktiv ist:

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

Das Konfigurieren dieses Skripts auf Knoten 2 führte zu folgenden Ergebnissen:

  1. die IP auf Knoten 1 wurde zum Testen entfernt
  2. knoten 2 hat den IP-Verlust erkannt und von BACKUP zu FAULT geändert
  3. knoten 1 ignorierte die Statusänderung und blieb MASTER

Das Ergebnis: Die IP blieb niedrig.

Das Konfigurieren des Skripts auf Knoten 1 führte zu folgenden Ergebnissen:

  1. die IP auf Knoten 1 wurde entfernt
  2. knoten 1 hat den IP-Verlust erkannt und von MASTER zu FAULT geändert
  3. knoten 2 erkannte die Statusänderung auf Knoten 1 und wechselte von BACKUP zu MASTER, wobei die schwebende IP auf Knoten 2 konfiguriert wurde

Na und dann ...

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

Ich musste keepalived auf Knoten 1 neu starten, um das Ping-Pong-Spiel zwischen den Knoten zu stoppen.

8

Wir haben dieses Problem festgestellt und festgestellt, dass es sich um ein Problem mit systemd-networkd in Ubuntu 18.04 handelt, das jetzt netplan verwendet. Eine neuere Version von keepalived sollte dies beheben, da sie das Entfernen der schwebenden IP erkennen kann, die ein Failover verursacht, siehe https://github.com/acassen/keepalived/issues/836 .

Die neuere Version von keepalived ist in 18.04 nicht verfügbar. Anstatt zu versuchen, einen Backport durchzuführen, haben wir uns entschlossen, auf Ubuntu 16.04 zu bleiben und bis Ubuntu 20.04 auf unsere Server zu warten, die Keepalived verwenden.

7
mp3foley

Dieses Problem wurde in keepalived 2.0.0 vom 26.05.2018 behoben, siehe Änderungsprotokoll von keepalived

  • Überwachen Sie das Löschen von VIP/eVIP und den Übergang zur Sicherung, wenn ein VIP/eVIP entfernt wird, wenn es nicht mit der Option "Keine Spur" konfiguriert ist.
5
teissler

Ich denke, Ihr allgemeiner Ansatz ist in Ordnung, aber Sie müssen Ihre Testbedingungen überdenken. Die Bedingung, über die Sie sich Sorgen machen, ist, ob systemd die Netzwerkinfrastruktur neu startet (die indirekte Folge davon ist, ob Ihr VIP ist aktiv) oder nicht, also müssen Sie dies überprüfen zum.

Ich habe kein System, auf dem ich während der Eingabe leicht testen kann, also YMMV, jedoch systemctl is-active network.service kann ausreichen, um dies abzudecken. Andernfalls wird der Status von systemctl show network.service | grep 'ActiveState' für einen anderen Zustand als 'aktiv' sollte dies tun.

Sollte einer Ihrer Knoten nicht mit dem Status 'BACKUP' konfiguriert werden, sondern mit beiden als 'MASTER'?

0
clockworknet

Als Problemumgehung habe ich die Floating-IP als zusätzliche IP auf dem Primärknoten konfiguriert (mit der höheren Priorität).

/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"

Auf diese Weise befindet sich die Floating-IP beim Neustart oder bei der Neukonfiguration des Systems auf dem Primärknoten. Sollte dies fehlschlagen, wird es vom Sekundärknoten über keepalived übernommen. Sollte der primäre Knoten zurückkehren, wird die IP von keepalived auf dem sekundären Knoten freigegeben.

Es ist nicht wirklich eine Lösung, aber derzeit sehe ich nichts besseres.


Update

Während diese Problemumgehung irgendwie funktionierte, hatte sie einige Nebenwirkungen. Nach einem Neustart war die Floating-IP-Adresse zweimal auf der Schnittstelle vorhanden:

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

Das schien nichts zu beeinflussen, es funktionierte, aber es störte mich. Am Ende habe ich die Antwort von mp3foley erhalten und die VMs mit Ubuntu 16.04 neu installiert.

0

Ich denke, Sie können eine Ping-Prüfung auf der schwebenden IP durchführen und dann, wenn dies fehlschlägt, den Keepalived-Dienst auf allen Knoten neu starten

Du wirst wiederkommen

Legen Sie dies in einen Cronjob, der jede Minute oder 5 Minuten läuft

0
Mark