Failover (Faliover-IP vs. DNS-Änderung)

    Ein Failover auf einen anderen Server per API kann man ja bei netcup auf zwei verschiedene Arten realisieren:


    1) Echtes Failover mit Failover-IPs über die API des SCP

    2) Failover über Änderung der DNS-Records mit der CCP-API


    Beides habe ich erfolgreich getestet und beide Methoden haben ihre Vor- und Nachteile.


    Vorteile von 1)

    • Geht auch, wenn die DNS-Verwaltung nicht bei netcup liegt.
    • Geht schneller (Es wird sofort umgeschaltet)
    • Die domain behält dauerhaft die gleiche IP


    Vorteile von 2)

    • Geht auch standortübergreifend (Sogar Providerübergreifend)
    • Kostet nix (Bei echtem Failover benötigt man zwei IPs (ipv4 und ipv6) für je 5,-)
    • Netzwerkkonfiguration einfacher.


    Welche Methode präferiert oder nutzt ihr? (Erfahrung?)

    Gibt es noch weitere Gesichtspunkte?

    Von einem Failover mittels DNS würde ich dringend abraten. Das Problem sind die vielen "kaputten" DNS Clients da draußen. Du kannst die TTL noch so kurz stellen, jeder Client oder Resolver kann das selbst überschreiben. Es gibt genügend Resolver, die selbst bei einer kurzen TTL die Records länger im Cache lassen. Auch gibt es Fälle, wo der DNS nur einmal abgefragt wird und dann erst wieder beim nächsten Neustart. nginx ist so ein Beispiel. Da bringt dir der DNS Failover im Grunde nichts, weil die Clients das nicht mitmachen. Das halte ich daher in der Praxis für keine gute Idee.

    Quote from Paul

    Das halte ich daher in der Praxis für keine gute Idee.

    Effektiv wird das aber z.B. bei AWS ELB gemacht. Wenn dort eine eine von den 3 Endpunkten für maintenance rausgenommen wird, kommt eine neue IP dazu. Deswegen soll man da mit einen CNAME arbeiten statt die A Records vom LB zu setzen. Aber wahrscheinlich sperrt man dann alle mit den faulty DNS resolvern aus.

    Nachteil an der Failover IP ist halt auch, dass man kein DNS Load Balancen zwischen seinen Servern dann hat. Außer man bucht sich direkt 2-3 Failover IPs auf denen man dann auflöst und dann im Failover fail ein Server 2 IP zugeordnet hat.

    ~ RS4000 9.5G ; VPS 200 G10s ; 2 x ; VPS nano G11s ; 3 x VPS 3000 ARM G11 ; 6 x VPS 2000 ARM G11 (200% SSD)

    Thanks 1 Like 1

    Das Thema Failover ist neben dem "shared Storage" eines meiner Probleme bei Netcup.


    Ebenso wie Paul hab ich schlechte Erfahrungen mit DNS Failover, wenn man nicht alle Resolver in der Kette unter Kontrolle hat. Es gibt verschiedene Payment Dienste die bspw einen DNS TTL von 10 Sekunden haben und das versuchen.


    Bei der FailoverIP gibt es noch bei DualStack die Situation, dass diese im Falle des Wechsels eventuell auf 2 unterschiedliche Systeme zeigt und dadurch die Antworten nicht konsistent sind. Meiner Erfahrung nach waren es ~20 Sekunden nach dem Auslösen, bis die IP dann auf dem anderen System lag.


    Deswegen bevorzuge ich prinzipiell Loadbalancer mit Healthchecks oder bspw HAProxy als ReverseProxy der dann auch bei Bedarf im Hintergrund auf eine andere Node zurückgreift, wenn die lokale nicht antwortet.


    Quote from saremox

    Effektiv wird das aber z.B. bei AWS ELB gemacht. Wenn dort eine eine von den 3 Endpunkten für maintenance rausgenommen wird, kommt eine neue IP dazu. Deswegen soll man da mit einen CNAME arbeiten statt die A Records vom LB zu setzen. Aber wahrscheinlich sperrt man dann alle mit den faulty DNS resolvern aus.

    Standardmäßig sind es nur 2, können aber X Adressen werden. Und die IPs wechseln in unregelmäßigen Abständen trotzdem durch, daher wollen sie nicht, dass man A records setzt. Die Zeiten für die DNS Auflösung sind dementsprechend nicht prickelnd.

    Quote from michaeleifel

    Bei der FailoverIP gibt es noch bei DualStack die Situation, dass diese im Falle des Wechsels eventuell auf 2 unterschiedliche Systeme zeigt und dadurch die Antworten nicht konsistent sind

    das vermeidest mit einer Kombination aus echtem Failover und DNS-CNAME-Records

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

    Quote from aRaphael

    Kannst du das mal näher erläutern?

    wenn du ein Failover-IP-Gespann hast aus einer IPv4 und einer IPv6, dann machst dafür je einen

    A-Record [IPv4] und AAAA-Record [IPv6]

    die Reverse-IP[v6]-DNS Namen werden ebenfalls gesetzt

    z.B.

    fail.example.de IN A 100.100.100.100

    fail.example.de IN AAAA 2001:db8::100

    das sind z.B. die IP[v6] von Host1, daher hast im Normalfall

    use.example.de IN CNAME fail.example.de

    und merkst dass eines der beiden (IPv4 od. IPv6) unresponsive wird,

    dann schaltest BEIDE auf IPs [v4 und v6] auf Host 2 um;

    Thats it

    einen Active-Active-Failover-Cluster mittels DNS-Round-Robin hinzubekommen halte ich übrigens f. nicht ganz unproblematisch


    der Umweg über die DNS-CNAME hat hier nur den Zweck einer etwas strukturierteren Ordnung

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

    Quote from aRaphael

    Welche Methode präferiert oder nutzt ihr? (Erfahrung?)

    Ich nutze meine FaiOverIP´s (IPv4 und IPv6) in der Form, dass ich Diese auf einem vServer als Gateway schalte und den eigentlichen Servern (LXC´s) oder auch weitere vServer von Netcup, die die jeweilige FailOverIP (IPv4 und IPv6) aufgeschaltet haben sollen, über das vLAN zur Verfügung stelle. Somit umgehe ich die damit vom Nutzer michaeleifel angesprochene Wartezeit und eventuell auch weitere Probleme.


    Das funktioniert seit ca. einem Jahr ausgesprochen gut.


    Die Infrastruktur von Netcup brauche ich nur dann zu bemühen, wenn ich mal von einem alten auf einen neuen vServer als Gateway wechsle.

    Quote from michaeleifel

    Das Umschalten der IPv4/v6 erfolgt parallel, nicht sequentiell. Trotzdem kam es bei mir manchmal zu diesen Effekten.

    aber gerade wenn das Umschalten parallel [im Sinne von gleichzeitig] erfolgt wäre ja genau der von Dir erwähnte Effekt ausgeschlossen;

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

    Quote from michaeleifel

    Das Umschalten der IPv4/v6 erfolgt parallel, nicht sequentiell.

    Mein API-Skript macht das allerdings tatsächlich sequentiell. Ich schalte zunächst die ipv4 um und nur wenn das erfolgreich ist, schalte ich danach auch die ipv6 um. Falls schon ipv4 scheitert, bekomme ich nur eine Panikmail zugeschickt, dass manuelles Eingreifen nötig ist. ^^

    Quote from mainziman

    aber gerade wenn das Umschalten parallel [im Sinne von gleichzeitig] erfolgt wäre ja genau der von Dir erwähnte Effekt ausgeschlossen;

    [Blocked Image: https://i.imgur.com/fxSy8lT.jpeg]

    Dachte ich auch. Aber "Effekte" im Backend haben dann doch manchmal dazu geführt. Muss dazu aber auch sagen, dass mein Monitoring weit engmaschiger als jede Minute prüft und es daher unter normalen Umständen außer nen kurzen Schluckauf gar nicht merkt. Lustig wird es aber, wenn das Failover Backend Probleme hat oder im VLAN Dinge verrückt laufen. Alles schon erlebt, leider.



    Quote from andreas.

    Ich nutze meine FaiOverIP´s (IPv4 und IPv6) in der Form, dass ich Diese auf einem vServer als Gateway schalte und den eigentlichen Servern (LXC´s) oder auch weitere vServer von Netcup, die die jeweilige FailOverIP (IPv4 und IPv6) aufgeschaltet haben sollen, über das vLAN zur Verfügung stelle. Somit umgehe ich die damit vom Nutzer michaeleifel angesprochene Wartezeit und eventuell auch weitere Probleme.


    Das funktioniert seit ca. einem Jahr ausgesprochen gut.


    Die Infrastruktur von Netcup brauche ich nur dann zu bemühen, wenn ich mal von einem alten auf einen neuen vServer als Gateway wechsle.

    Was passiert wenn das Gateway ausfällt? Händischer Eingriff?

    Das ist dann für mich keine praktikable Lösung, da muss ich ja doch wieder um 3 nachts aufstehen oder mich Beamen, wenn was los ist. Da kann ich dann mit den Ungereimtheiten von oben sehr gut leben und Nodes rebooten, bis der Kunde mit dem Schlagstock vor der Tür steht.

    In deinem Fall würde ich dann eher die TTL auf 5 Minuten stellen und mir die 10€ für die beiden IPs sparen. Oder einen externen Loadbalancer anbinden.

    Quote from michaeleifel

    In deinem Fall würde ich dann eher die TTL auf 5 Minuten stellen und mir die 10€ für die beiden IPs sparen. Oder einen externen Loadbalancer anbinden.

    Ich habe mehr als nur 2 Failover-IPv4-Adressen und ein Failover-IPv6-Netz, die derzeit auf einem GW-Server geschaltet sind.


    Was hältst du oder ihr von zwei GW-Servern, die im Master- Slave-Betrieb laufen würden und auf denen die Failover IPv4-Adressen und das Failover-IPv6-Netz im Störungsfall vollautomatisiert über einen zusätzlichen externen Monitoringdienst, der eventuell auch aus Kostengründen zuhause läuft, umgeschwenkt werden?


    Am 21.12.2024 hatte ich aufgrund meiner Antwort #15 hier unter der Überschrift Failover IPv4- oder IPv6-Adresse aus der Ferne von Server A auf B umschwenken auch ein entsprechendes Beispiel abgelegt, mit dem z.B. sowas auch realisiert werden könnte.


    Weil sich aber in der Vergangenheit gezeigt hat, dass die Verfügbarkeit bezüglich der Netzanbindung bei Netcup sehr hoch ist, kann ich auch mit meiner derzeitigen Konfiguration recht gut leben.

    https://de.wikipedia.org/wiki/Murphys_Gesetz

    Ich saß im Auto auf den Weg zum Bodensee, noch 4 Stunden Fahrzeit, als mein Monitoring mich darüber informierte, dass die Failover IP geschwenkt wurde und 1 Server weg ist. Ich konnte dann den Notfall Support erreichen und der konnte mir dann nach späteren Rückruf bestätigen, dass der Wirt ausgefallen war. 10 Minuten später kam dann auch die Meldung vom Support über den Ausfall. Ohne Automatisierung hätte ich den Rest des Tages mit Anrufen und Schlichtungen verbracht.


    | über einen zusätzlichen externen Monitoringdienst,

    Warum eine weitere Single Point of Failure Komponente dazufügen, wenn man genug Server hat und die API direkt vom Server erreicht?


    | Failover IPv4- oder IPv6-Adresse aus der Ferne von Server A auf B umschwenken

    Ich mache dir mal einen Gegenvorschlag:


    Bei mir sind das 3 Server mit Keepalived Konfiguration, die dann über die API Schnittstelle vollautomatisiert schwenken ( Skript sind ähnlich deinen geposteten, weil gleicher Mechanismus). Diese stehen die ganze Zeit im Kontakt zueinander und prüfen verschiedenste Dienste lokal und nicht nur ob der Webserver selbst bspw läuft.

    Auch gibt es Abstufungen / Unterschiede in der Gewichtung. Wenn die Gesamtpunktzahl nicht mehr stimmt und nicht innerhalb 1 Minute wieder healthy ist, wird geschwenkt. Es gibt auch einen Check der von außen mit in die Gewichtung fließt und prüft ob die externe Kommunikation wie erwartet funktioniert. Der lokale Check gegen die FailoverIP ist nicht ohne.


    Vorteil ist auch, dass du die ganzen variablen Informationen aus dem Skript nicht erst selbst zusammen suchen muss, sondern diese auf dem System automatisiert abgreifen kannst oder per Ansible ausrollst.

    Quote from michaeleifel

    ...und nicht innerhalb 1 Minute wieder healthy ist, wird geschwenkt.

    Recht kurz. Hast du da nicht manchmal unnötige Schwenks drin?


    Ich bin da etwas großzügiger und prüfe sowieso nur alle 5 Minuten. Außerdem restarte ich zunächst den Stack und wenn das nicht hilft den Server, bevor ich umschwenke, weil das ja nicht selten (nach meiner Erfahrung) ein Problem schon behebt. Aber bei mir ist das alles auch nicht allzu zeitkritisch.

    Ich will halt erst dann auf den Failover umschalten, wenn alles andere versagt hat, weil der keine echte Spiegelung ist, sondern da tatsächlich nur das abgespeckte Notfallprogramm drauf ist.

    Quote from michaeleifel

    | über einen zusätzlichen externen Monitoringdienst,

    Warum eine weitere Single Point of Failure Komponente dazufügen, wenn man genug Server hat und die API direkt vom Server erreicht?


    So wie ich es hier im Forum schon mitbekommen habe, geht es den meisten Nutzern eher darum, sehr viele Kosten einzusparen, deswegen habe ich mich dazu unter anderem auch wie folgt geäußert:

    Quote from andreas.

    ... , der eventuell auch aus Kostengründen zuhause läuft, umgeschwenkt werden?


    Das von mir hier im Forum reingestellte Beispiel sollte kein fertiges System sein, sondern nur als Anregung für ein eigenes Failover-System sein. Denn jeder hat andere Bedürfnisse und wird diese eventuell auch anders lösen wollen.