Keepalived wechselt zu häufig den Master

andreasbe · 8. Dezember 2022

Hallo zusammen

ich habe 3 netcup Server über cloud vlan free miteinander verbunden.

Die Betriebssysteme sind

Server 1 Ubuntu 18.x LTS (im vlan 192.168.200.100/24)
Server 2 Ubuntu 20.x LTS (im vlan 192.168.200.110/24)
Server 3 Ubuntu 22.x LTS (im vlan 192.168.200.120/24)

Auf allen habe ich keepalived aus den sourcen installiert, da die Versionen sonst zu unterschiedlich gewesen wären (aus den apt Paketquellen)

Hierfür habe ich Version keepalived-2.2.4 gewählt

(https://www.keepalived.org/software/keepalived-2.2.4.tar.gz)

keepalived wurde auf allen nodes folgendermaßen konfiguriert

Failover IP exemplarisch 111.222.111.222/32

Code

vrrp_instance VI_1 {
    state BACKUP

    interface eth1
    virtual_router_id 10
    priority 170
    advert_int 1

    unicast_src_ip 192.168.200.100/24 // Server 1 im vlan
    
    unicast_peer {
        192.168.200.110/24 // Server 2 im vlan
        192.168.200.120/24 // Server 3 im vlan
    }

    virtual_ipaddress {
        111.222.111.222/32 dev eth0
    }

    authentication {
        auth_type PASS
        auth_pass MYPASS
    }


    notify_master "/root/scripts/keepalived_notify.sh Master"
    notify_backup "/root/scripts/keepalived_notify.sh Backup"
    notify_fault "/root/scripts/keepalived_notify.sh Fault"

}

Alles anzeigen

Die Idee ist damit später per SOAP-API die Failover IP nach dem Skript aus https://forum.netcup.de/netcup…-destinationinterfacemac/ umzuschalten.

Allerdings ist die Master-Wahl noch viel zu wackelig. Ohne erkennbaren Grund kommt es zu Wechseln wie diesem

Hier aus Sicht von Server 2, der eine niedrigere Priorität als Server 1 hat und daher BACKUP sein müsste (statt MASTER)

Zitat

Date: 08-Dec-2022 13:08:56

[INFO] Now Master

===================================

Date: 08-Dec-2022 13:10:22

[INFO] Now Backup

===================================

Date: 08-Dec-2022 13:10:25

[INFO] Now Master

===================================

Date: 08-Dec-2022 13:11:15

[INFO] Now Backup

Alles anzeigen

Server1 war zu jederzeit erreichbar und das Monitoring (Zabbix) meldet keine Ausfälle. Zudem war ich jederzeit per ssh verbunden ohne Abbrüche

Hat jemand eine Idee wie man das stabiler bekommt? Ich würde das SOAP-Script zum Failover-IP-Routing erst aktivieren, wenn das stabil ist

Besten Dank vorab!

Paul · 8. Dezember 2022

Wie oft passiert das denn? Kannst du mal im VLAN einen Ping laufen lassen? Läuft das Monitoring ebenfalls über das VLAN?

Ansonsten ist

Code

advert_int 1

zwar der Default Wert, aber natürlich schon etwas aggressiv. Man könnte zum Test das auch mal etwas erhöhen. Ich stelle das meistens auf 2-3. Reicht ja eigentlich auch. Auch gibt es hier noch Optionen wie

Code

preempt_delay

welcher dafür sorgt, dass nicht zu schnell wieder zurück geschwenkt wird. Das ist vor allem in Verbindung mit der SOAP API wichtig, da ein Umschalten immer eine gewisse Zeit braucht. Wenn keepalived wieder zurückschalten will, aber das Umschalten noch nicht fertig ist, hat der falsche Master die Failover IP und nichts geht mehr. Da muss man etwas aufpassen. Ich würde preemt_delay daher immer mindestens auf 30 setzen.

Es gibt wohl auch noch eine Option

Code

Master_Down_Interval

die man hier ebenfalls mal testen könnte. Die habe ich jetzt persönlich aber noch nicht im Einsatz gehabt.

michaeleifel · 8. Dezember 2022

Hallo,

Paul hat schon ein paar gute Ideen in den Raum geworfen.

Zu deiner Konfig hab ich paar Fragen:
1) Ich sehe keinerlei Konfiguration für Healthchecks von Diensten beispielsweise, ist das so gewollt?

2) Authentication kannst dir glaub sparen, so lese ich zumindest die Notiz:

Code

# Note: authentication was removed from the VRRPv2 specification by RFC3768 in 2004.

3) Warum nimmst du explizit unicast? Das ist meines Wissens nach bei Netcup nicht notwendig

Gibt es eine Node bei dir welche state Master hat?

Gruß

andreasbe · 9. Dezember 2022

Zitat von Paul
Wie oft passiert das denn? Kannst du mal im VLAN einen Ping laufen lassen? Läuft das Monitoring ebenfalls über das VLAN?

Ansonsten ist
Code
advert_int 1
zwar der Default Wert, aber natürlich schon etwas aggressiv. Man könnte zum Test das auch mal etwas erhöhen. Ich stelle das meistens auf 2-3. Reicht ja eigentlich auch. Auch gibt es hier noch Optionen wie
Code
preempt_delay
welcher dafür sorgt, dass nicht zu schnell wieder zurück geschwenkt wird. Das ist vor allem in Verbindung mit der SOAP API wichtig, da ein Umschalten immer eine gewisse Zeit braucht. Wenn keepalived wieder zurückschalten will, aber das Umschalten noch nicht fertig ist, hat der falsche Master die Failover IP und nichts geht mehr. Da muss man etwas aufpassen. Ich würde preemt_delay daher immer mindestens auf 30 setzen.

Hi,

danke für die Rückmeldung

es passiert ca. alle 5-7 Stunden.

Die oberen beiden Werte habe ich angepasst.

Ebenso die Priority mal wie vorgeschlagen mindestens auf 50 Abstand konfiguriert

Code

priority 

To be MASTER, it is recommended to make this 50 more than on
           # other machines. All systems should have different priorities

Also gewünschter Master 200, nächster 150, dritter 100

Das Monitoring läuft über Zabbix Checks von einem externen Host über die public IP (Passive Checks)

Kurzen Schluckauf bekomme ich darüber nicht mit, aber längeres Ausbleiben des Agents. Aber ich glaube das Problem hier ist maximal kurzer temporärer Schluckauf.

zu

Code

Master_Down_Interval

finde ich leider in der Doku (https://www.keepalived.org/manpage.html) nichts.

Ein Ping im VLAN läuft ohne Aussetzer durch. Ich müsste mir aber vermutlich ein Skript bauen welches die (möglichen) Aussetzer loggt, aber wenn man eine zeitlang zuschaut geht es ohne ein Paket Verlust.

andreasbe · 9. Dezember 2022

Zitat von michaeleifel
Hallo,

Paul hat schon ein paar gute Ideen in den Raum geworfen.

Zu deiner Konfig hab ich paar Fragen:
1) Ich sehe keinerlei Konfiguration für Healthchecks von Diensten beispielsweise, ist das so gewollt?

2) Authentication kannst dir glaub sparen, so lese ich zumindest die Notiz:
Code
# Note: authentication was removed from the VRRPv2 specification by RFC3768 in 2004.
3) Warum nimmst du explizit unicast? Das ist meines Wissens nach bei Netcup nicht notwendig

Gibt es eine Node bei dir welche state Master hat?

Gruß
Alles anzeigen

Hi,

dir auch danke

1) ja bisher schon, stehe noch ganz am Anfang und wollte erst mal das Election-Verhalten beobachten und das switchen der Failover-IP bzw. Routing über das SOAP Skript. Leider klappt das wegen dem schnellen Wechsel noch nicht.

2) Danke ist raus

3) Mangels besseren Wissens? Ich finde das Produkt sehr kompliziert
Geht das über cloud vlan free oder müsste ich hier noch eine Spezialkonfiguration vornehmen?

4) Nein, alle starten mit Backup, es übernimmt dann automatisch der mit der höchsten Priorität

Code

 # Initial state, MASTER|BACKUP
           # If the priority is 255, then the instance will transition immediately
           # to MASTER if state MASTER is specified; otherwise the instance will
           # wait between 3 and 4 advert intervals before it can transition,
           # depending on the priority.
           state MASTER

Scheint nur das Startverhalten zu beeinflussen

andreasbe · 9. Dezember 2022

Aktuelle aktive Konfiguration für weitere Tests (und für bessere Lesbarkeit dieses Threads)

Code

vrrp_instance VI_1 {
    state BACKUP

    interface eth1
    virtual_router_id 10
    priority 200 // Master, 150 - Slave1, 100 Slave2
    advert_int 2
    preempt_delay 30
    unicast_src_ip 192.168.200.120/24

        unicast_peer {
        192.168.200.100/24
        192.168.200.110/24
    }

    virtual_ipaddress {
        111.222.111.222/32 dev eth0
    }

     notify_master "/mnt/gv0/keepalived_notify.sh Master"
     notify_backup "/mnt/gv0/keepalived_notify.sh Backup"
     notify_fault "/mnt/gv0/keepalived_notify.sh Fault"

}

Alles anzeigen

Beim Hochfahren meckert er noch diese Option an, ggf. wäre das noch sehr interessant

Zitat

NOTICE: setting config option max_auto_priority should result in better keepalived performance

Code

  # The following options can be used if vrrp, checker or bfd  processes
           # are timing out. This can be seen by a backup vrrp instance becoming
           # master even when the master is still running, because the master or
           # backup system is too busy to process vrrp packets.
           # --
           # keepalived can, if it detects that it is not running sufficiently
           # soon after a timer should expire, increase its priority, first
           # of all switching to realtime scheduling, and if that is not
           # sufficient, it will then increase its realtime priority by one each
           # time it detects a further delay in running. If the event that realtime
           # scheduling is enabled, RLIMIT_RTTIME will be set, using the values for
           # {bfd,checker,vrrp}_rlimit_rttime (see below). These values may need
           # to be increased for slower processors.
           # --
           # To limit the maximum increased automatic priority, specify the following
           # (0 doesn't use automatic priority increases, and is the default. -1 disables
           # the warning message at startup). Omitting the priority sets the maximum value.
           max_auto_priority [<-1 to 99>]  # 99 is really sched_get_priority_max(SCHED_RR)

Alles anzeigen

Die Frage ist nur: Welchen Wert wählt man hier?

Theoretisch ist das beschriebene genau das was hier passieren könnte: Der Master ist durch Backups, Uploads etc zu ausgelastet um die Paket zu verarbeiten.
Backups werden dann zu Master, obwohl der Master eigentlich noch läuft...

michaeleifel · 9. Dezember 2022

Bitte,

was ist denn an dem CloudVLAN Produkt kompliziert? Im Gegensatz zum roten H hast du kein DHCP, aber dafür kannst du auch IPv6 machen, was bei denen nicht geht ( selber leidige Erfahrung gemacht )

Das CloudVLAN free ist halt auf 100Mbit limitiert. Hängt von ab, was du da alles drüber schickst. Bei mir geht der Storage auch darüber, deswegen hab ich ein größeres.

Zitat

Die Frage ist nur: Welchen Wert wählt man hier?
Der Master ist durch Backups, Uploads etc zu ausgelastet um die Paket zu verarbeiten

Genau deswegen will ich die IP ja rüber schieben, der Host hat gerade besseres zu tun und antwortet nicht auf Pakete. Und wie du selbst schreibst starten sowieso alle als Backup

Am Anfang hatte ich diese Konfiguration auch, bin aber mittlerweile dazu übergegangen, dass einer den initial State Master hat, der aber sofort hinfällig wird, wenn ein Healthcheck fehlschlägt und dadurch sich die Priorität auf einen kleineren Wert verringert als von einem der Backups.

Omitting the priority sets the maximum value würde ich so lassen.

andreasbe · 9. Dezember 2022

Zitat von michaeleifel

Bitte,

was ist denn an dem CloudVLAN Produkt kompliziert?

Meinte keepalived

michaeleifel · 9. Dezember 2022

AH, verstehe.

Zumindest die Dokumentation ist aber sehr ausreichend für alle Parameter. Ist es denn schon stabiler geworden?

Zitat von Paul
Code
preempt_delay
welcher dafür sorgt, dass nicht zu schnell wieder zurück geschwenkt wird. Das ist vor allem in Verbindung mit der SOAP API wichtig, da ein Umschalten immer eine gewisse Zeit braucht. Wenn keepalived wieder zurückschalten will, aber das Umschalten noch nicht fertig ist, hat der falsche Master die Failover IP und nichts geht mehr. Da muss man etwas aufpassen. Ich würde preemt_delay daher immer mindestens auf 30 setzen.

Das ist mir irgendwann "zu doof" geworden und habe deswegen neben dem Umschalten über die Notify Skripte noch zusätzlich einen "watcher" laufen der den keepalived status prüft und falls die Node der Master ist, die SOAP API fragt ob die IP auch an den Server geroutet ist, das kan man über

ns1:getVServerIPs prüfen. Ist in 99% der Fälle aber nicht notwendig.

andreasbe · 9. Dezember 2022

Ah cool, genau das wollte ich auch noch einführen, habe bereits entsprechende Skripte vorbereitet.

Also zusätzlich über Cron-Job prüfen ob die Failover IP assigned ist und dann ggf. das SOAP Routing Skript aufrufen.

Der Teil mit ns1:getVServerIPs hat mir noch gefehlt, werde mir da etwas basteln.

Witzig, dass man dann auf die gleichen Ideen kommt

Es muss halt eine 100% Lösung sein, weil sonst ist gegenüber "Single Point of Failure" Deployment nichts gewonnen.

Die Netcup-Kisten laufen ja eigentlich sehr stabil.

Bisherige Beobachtung:

Seit 8:xx Uhr läuft es tatsächlich stabil und hat nicht mehr gewechselt.

Werde es über's Wochenende beobachten

Schönes selbiges

andreasbe · 13. Dezember 2022

Rückmeldung:

Läuft wesentlich stabiler, leider weiterhin jedoch nicht ohne kleinere Störungen, wonach die Failover IP auf dem falschen Host landet und ein Zugriff nicht mehr möglich ist.

Daher teste ich jetzt folgendes Szenario

Umschaltung weiterhin über keepalived notify master script
(Für sich alleine problematisch, siehe Erklärung unten)
Cron Job der jede Minute prüft
- Bin ich der MASTER laut keepalived
- Wenn ja, frage über die SOAP Schnittstelle ns1:getVServerIPs ob Netcup das genauso sieht
- Wenn nein, sorge über die SOAP Schnitstelle ns1:changeIPRouting dass sich das ändert

Downtimes / Nicht Erreichbarkeit von 1 Minute kann ich akzeptieren.

Ich beobachte weiter. Es scheint als scheinen die Zeiten mit den Hängern genau die zu sein wo Datenbank Backups, externe Backups, etc. laufen

Es ist jedoch IMMER zu sehen, dass nach 1-2 Sekunden (manchmal sogar innnerhalb der selben Sekunde) wieder geswitcht wird. z.B.

Code

===================================
Date:  12-Dec-2022 23:20:08
[INFO] Now Master

===================================
Date:  12-Dec-2022 23:20:08
[INFO] Now Backup

Problem ist, dass auf dem eigentlichen Master um 23:20:08 keine Änderung stattfand. Der o.g. Server machte sich also zum Master, was der eigentliche Master aber nicht mitbekam. Daher klappt natürlich auch die Umschaltung per SOAP API nicht mehr zurück auf den eigentlichen Master, da sie nie ausgeführt wurde.

Für den Master sah der letzte Eintrag nämlich so aus (10 Uhr ist wirklich 10 Uhr AM - 24 Format wurde geprüft)

Code

===================================
Date:  12-Dec-2022 10:21:29
[INFO] Now Master

Tags