Failover-IPv4: Deadlock / RaceConditions erkennen?

  • Hallo zusammen,


    ich bastele aktuell an meinem Keepalived Setup wieder. Die Healthchecks etc. laufen bereits alle selber und alle notwendigen Checks sind in Verwendung.


    Leider hab ich ein paar Dinge entdeckt welche ich noch gerne verbessern würde und wollte mal fragen ob jemand mir da evtl. Tipps geben kann

    oder man sich zum Setup austauschen kann. Auch für Hinweise in der Dokumenation bin ich dankbar.:)



    Aktuell hab ich folgendes Setup:

    - Jede Node hat Healthchecks wie bspw Kubernetes API Erreichbarkeit, Ingress Status, Healthchecks vom Monitoringagent

    - Jede Node hat bereit die notwendingen FloatingIPs konfiguriert, da ich Probleme hatte wenn ich diese dynamische von Keepalived verwalten lasse

    - Alle Nodes sprechen per CloudVLAN miteinander und einigen sich, wer der Master ist

    - Beim Übergang zum Masterstate führe ich dann per Curl den SOAP Request aus welche die Zuweisung der IP auf diese Node dann vornimmt (notwendige Informationen sind automatisiert, dynamisch über System Informationen ausgelesen)


    Aktuelle "Nichtigkeiten":

    - Curl Befehl wird ausgeführt (/usr/bin/curl -H 'Content-Type: text/xml; charset=utf-8' -H 'SOAPAction:' -d @/etc/keepalived/netcup_failover.xml -X POST https://www.servercontrolpanel.de:443/WSEndUser)

    - Dieser gibt innerhalb von 1 Sek bereits einen Statuscode zurück, weswegen aus keepalived sicht der prozess abgeschlossen ist

    - Innerhalb der nächsten 10 Sekunden kommt es zu einem erneuten Masterstate wechsel, weswegen die nächste Node den Curl Befehl absetzt



    Wie kann ich bspw ein skript formulieren, welches erst wenn die FloatingIP der Node "wirklich" zugewiesen ist terminiert?:/


    Und wie handelt die Netcup SOAP diese Befehle?

    - gewinnt automatisch der letzte Befehl?:?:

    - werden weitere Anweisungen der IP Zuweisung blockiert wenn der Vorgang noch nicht abgeschlossen ist?:?:



    Gruß

  • Die Problematik kenne ich. Darüber bin ich damals auch bei meinen Keepalived Setups gestolpert. Was aber helfen könnte, wäre folgende Option


    ```
    preempt_delay 60

    ```


    Das sollte das zu häufige "Flappen" des Masters etwas abmildern. Bei Bedarf noch etwas höher setzen.

    Aus meiner Erfahrung gewinnt immer der erste SOAP Befehl, solange dieser noch "in Arbeit" ist. Bei mir hatte das damals immer so um die 30 Sekunden gedauert, bis die Failover IP Adresse erfolgreich zugewiesen wurde. Wenn dann zwischenzeitlich Keepalived die Floating IP selbst wieder gewechselt hat, hat sie aber trotzdem auf den falschen Server gezeigt und der Service war schlussendlich nicht erreichbar.

  • Die Problematik kenne ich. Darüber bin ich damals auch bei meinen Keepalived Setups gestolpert. Was aber helfen könnte, wäre folgende Option


    ```
    preempt_delay 60

    ```


    Das sollte das zu häufige "Flappen" des Masters etwas abmildern. Bei Bedarf noch etwas höher setzen.

    Aus meiner Erfahrung gewinnt immer der erste SOAP Befehl, solange dieser noch "in Arbeit" ist. Bei mir hatte das damals immer so um die 30 Sekunden gedauert, bis die Failover IP Adresse erfolgreich zugewiesen wurde. Wenn dann zwischenzeitlich Keepalived die Floating IP selbst wieder gewechselt hat, hat sie aber trotzdem auf den falschen Server gezeigt und der Service war schlussendlich nicht erreichbar.


    Vielen Dank für den Input. Bei mir verhielt es sich wegen der IP ähnliich, weswegen ich mittendrin sogar mit Dummy IPs im VRRP Service gearbeitet hatte. Hab mein Setup gestern mal entsprechend angepasst und werde berichten.


    Falls jemand Interesse hat kann ich dass mal auf Github packen. Dass ganze ist momentan ein Helm Chart was ich aus einem anderen Github Projekt für Netcup leicht angepasst habe. Die Informationen welche für die SOAP Kommunikation noch notwendig sind (vServer, MAC Adresse) werden vom Container selbst beim Start vom Hostsystem gelesen.

  • Ich hoffe es ist OK dass ich hier einen neuen Beitrag verfasse anstatt den alten anzupassen.


    Heute morgen war es wieder soweit, ich hatte eine Deadlock Kombination zwischen 2 Servern gehabt, die im selben Moment meinten Master werden zu müssen. Zwar haben sie sich innerhalb von 1 sek geeinigt, der SOAP Call war allerdings trotzdem schon unterwegs. Aufgrund dessen habe ich weitere Anpassung im Keepalived Setup vorgenommen und ein rudimentäres Shellskript geschrieben.



    Es deckt rudimentär meine Funktionen ab die ich brauche und hat zumindest ein paar simple Checks (netcup API / URL da) drin statt nur einen einfach Curl Request. Zudem habe ich den Parameter "notify_master_rx_lower_pri" ebenfalls auf das Skript angesetzt. Allerdings kann ich die Aussage:


    Zitat

    Bei einer MAC von 00:00:00:00:00:00 wird die IP aus der Routingtabelle gelöscht und diese muss vor einer weiteren Verwendung erst neu zugeordnet werden. Beim Löschauftrag muss als destinationVserverName der Server angegeben werden, auf den die IP aktuell geroutet ist.

    von https://www.netcup-wiki.de/wik…rvice#Web_Service_Methods noch nicht bestätigen. Trigger ich den entsprechenden SOAP Call auf einer Node, welche aktuell nicht die FloatingIP hat, so wird diese vom anderen Server getrennt. Für Anregungen / Ideen bin ich weiterhin offen.


    Die entsprechenden referenzierten XML Files werden per Ansible (Vault) mit den Parametern gefüttert. Finde ich "persönlich" lesbarer als InlineCode.


    Gruß