Failover-IP umschwenken im Fehlerfall

  • Hallo,


    hat vielleicht jemand schon das Umschwenken der Failover-IP im Fehlerfall (Ausfall eines Nodes von netcup) auf einen anderen, funktionierenden Server ausprobiert?


    Wir haben hier zwei identisch konfigurierte Server, das Schwenken der IP im VCP funktioniert auch einwandfrei, wenn beide Nodes einwandfrei funktionieren.


    Gestern ist es allerdings zu einem Ausfall eines unserer Server gekommen (später gab es dazu eine Benachrichtigung von Netcup, dass ein Node ausgefallen ist). Ich habe dann versucht die Failover-IP im VCP auf unseren zweiten Server (der war erreichbar) umzuschwenken (klick auf "IP auf vServer routen"). Dabei kam leider nur die (wenig informative) Fehlermeldung: "Es ist ein Fehler aufgetreten."


    Lässt sich die Failover-IP-Adresse im Fehlerfall (falls ein Fehler bei Netcup vorliegt) nicht über das VCP ändern? Funktioniert es dann über den Webservice? Der Netcup-Support hat mir dazu nur geschrieben:

    Quote

    die IP-Adressen werden im VCP einmalig geroutet. Das Umschalten geschieht, wie Sie bereits schrieben, per Webservice/Skript.


    Ich würde das wirklich gerne glauben, aber hat das vielleicht schon einmal jemand getestet? Falls sich die Failover-IP-Adressen nämlich nur umschwenken lassen, falls beide Nodes einwandfrei funktionieren, so ist der Nutzen für uns begrenzt (Wartungsarbeiten, Softwarefehler, etc.).

  • Hallo w_a,


    bei uns gab es bislang auch einen Fehlerfall (Downtime von 30 Minuten) und dort hat das umschwenken der Failover-IP auch nicht geklappt.


    Der Support hatte nicht mehr als ein "kurzfristige Inkonsistenz im System" parat - was ich mal akzeptiert habe.


    Wenn du aber ähnlich Probleme hast und auch deine IP während eines Ausfalls nicht umschwenken konntest scheint es hier ein echtes Problem zu geben. Und das hätte ich schon gerne behoben.
    Wir haben die Failover-IP nämlich auch nur für den Fall dass der eine Host ausfällt so damit der andere zeitnah übernehmen kann (deswegen wird der zweite Host auch warm gehalten).
    Wenn das natürlich nie geht ist der Nutzen tatsächlich ziemlich begrenzt.


    Wäre schön wenn sich hier mal von netcup jemand dazu melden könnte.
    Ich kann zwar noch genaue Details liefern wann das Problem war, hab aber nicht die exakte Fehlermeldung protokolliert.


    Fakt war dass ich weder per Webservice noch per VCP die Failover-IP umschwenken konnte. Die Fehlermeldung war bei beidem irgendein unbestimmter "Error".


    Thomas

  • Hallo,



    wir bedauern das es hier zu Fehlern gekommen ist und werden den Fall jetzt in einer Testumgebung nachstellen. Selbstverständlich soll eine Failover-IP auch bei einem Nodeausfall umgeroutet werden können. Das ist mit ein wesentlicher Berechtigungsgrund für die Failover-IPs.


    Sobald ich mehr weiß melde ich mich.



    Mit freundlichen Grüßen


    Felix Preuß

  • Guten Abend,



    wir konnten in der Tat den Fehler reproduzieren. Unter bestimmten Umständen funktioniert die Änderung einer Route zu einer Failover-IP nicht.


    Der Fehler wird morgen Früh im Rahmen eines Updates behoben werden.


    Vielen Dank für Ihre Aufmerksamkeit!



    Mit freundlichen Grüßen


    Felix Preuß

  • Hallo,


    vorab bitte ich um Entschuldigung, dass ich diesen Thread ausgrabe; doch bei der Suche nach "Failover Webservice" findet man vor Allem iesen Thread hier und deshalb wollte ich hier kurz eine Info bzw. auf einen möglichen Stolperstein hinweisen.


    tl;dr: Nur https://www.servercontrolpanel.de/WSEndUser?wsdl nutzen (vorne kein "v"; nicht vServerControlPanel.de)


    tl;dr (extended): Mit dem Webservice https://www.vservercontrolpanel.de/WSEndUser?wsdl (mit "v" vorne, im folgenden "alter Webservice") kann eine FailOver-IP mehreren Servern zugewiesen sein. Das Verhalten des Routings ist dann nur noch mäßig zuverlässig. Laut Support soll nur noch der Webservice unter https://www.servercontrolpanel.de/WSEndUser?wsdl genutzt werden (ohne "v"; "neuer Webserivce") [Verhalten wird heute Nacht verifiziert].

    Hintergrund

    Ich habe in meinem Setup drei Server per corosync/pacemaker in einem Cluster, in dem die FailOverIP auch eine Ressource ist (sorgt dafür, dass die IP auf eth0:0 auf jeweils dem aktive Server gebunden wird). Ebenfalls wird ein Request an den Webservice ausgelöst, dass die FailOver-IP auf den dann aktiven Server geroutet werden soll. Was mir erst heute auffiel: Alle drei Server hatten die FailOver-IP zugewiesen (wohl, weil sie über die Zeit alle mal primary waren). Das Ganze hat die letzten Monate dennoch gut funktioniert; es wurde wohl quasi immer (Zufall?) an den "neusten" Server geroutet.


    Bis heute um zwischen 8:15 und 8:30 Uhr. Da wurde die IP scheinbar gar nicht mehr geroutet oder so; auf jeden Fall kamen Pakete, die an diese IP gesendet wurden auf keinem der drei Server an. Zuvor wurde kein Request an die API ausgelöst und ich (alleiniger Zugriff auf CCP / SCP) war noch am frühstücken. Ich hab ca. 1,5h gebraucht bis ich realisiert habe, dass im SCP an allen drei Servern die FailOverIP dran steht. Habe sie dann bei allen drei entfernt und absichtlich den aktuellen Primary gekillt, um ein FailOver zu provozieren; danach ging alles wieder wie gewohnt.


    Zwischenzeitlich habe ich mit dem Support Kontakt aufgenommen (NC-2017071710002805) und hoffe, dass durch die Umstellung des Webservices das Problem nicht mehr auftreten kann.


    Da die FailOverIP im produktiven Betrieb ist, werde ich erst heute Nacht testen können, ob das FailOver-Switching mit dem neuen Webservice zuverlässig funktioniert oder ob die IP dann wieder an allen Servern dran steht.


    Vielleicht hilft jemandem, der auf ähnliche Probleme stößt, dieser Post.

  • Trotz neuer Schnittstelle, trat der Fehler eben erneut auf. Eine FailOver war (oder ist?) scheinbar mehreren Servern zugewiesen.


    Leicht hilfloses herumklicken im SCP (um diese IP von einem Server ent-zuzuweisen - Button fehlte), brachte nichts. Ich hab jetzt absichtlich einen Node heruntergefahren, um einen erneuten FailOver API-Call zu forcieren. Das SCP ist jetzt auch etwas... unentschlossen welchem Server die IP jetzt gehört (zumindest verhält es sich inkonsistent). Werde dazu ein Ticket eröffnen.

  • Hallo Hecke29 ,

    Trotz neuer Schnittstelle, trat der Fehler eben erneut auf. Eine FailOver war (oder ist?) scheinbar mehreren Servern zugewiesen.


    Leicht hilfloses herumklicken im SCP (um diese IP von einem Server ent-zuzuweisen - Button fehlte), brachte nichts. Ich hab jetzt absichtlich einen Node heruntergefahren, um einen erneuten FailOver API-Call zu forcieren. Das SCP ist jetzt auch etwas... unentschlossen welchem Server die IP jetzt gehört (zumindest verhält es sich inkonsistent). Werde dazu ein Ticket eröffnen.

    Gab es hierzu eine Rückmeldung? Im Wiki ist zu lesen, dass man eine Zuordnung unter Verwendung der MAC-Adresse 00:...:00 löschen könnte.

    Ist es "best practice", dies vor einer Neuzuordnung vorzunehmen?

  • Auf der "Startseite" eines einzelnen Servers im SCP stehen unten rechts ja die zugewiesenen IPs (inkl. FailOver-IPs). Jetzt war es wohl so (hab ich mir aus den Antworten abgeleitet), dass dieser Teil wohl gecached wurde, weshalb es im SCP so aussah als sei die IP mehreren Servern zugewiesen worden (ist real wohl nicht der Fall). (1. "Report" von mir)


    Allerdings habe ich auch darlegen können, dass im "Netzwerk"-Tab (hier wird wohl nicht gecached) im SCP in einem solchen bei mir vorkommenden Fehlerfall auch komische "Dinge" passieren: Wenn ich in der Detailansicht des Netzwerk-Tabs bei Server A war, stand im Netzwerk-Tab, dass der Server nur eine IP hat und daunter wie gewohnt das DropDown zum zuweisen einer FailOver-IP. Hier stand hinter der FailOver-IP jedoch schon, dass diese IP (Server A) zugewiesen ist; die IP wurde aber nicht in der Liste von Server A aufgeführt und wurde real auch nicht dorthin geroutet => Inkonsistent / Kaputt. (2. "Report" von mir)


    Hier wurde wohl auch etwas seitens netcup in der FailOver-Mechanik geändert (unabhängig vom SCP) und seitdem ist das auch nicht wieder passiert (ist aber auch nur so 2-3 mal in den letzten 12 Monaten überhaupt passiert).


    Als 3. "Report" hatte ich noch gemeldet, dass ich von der SOAP-API auch mal Antworten mit dem Inhalt "generall error" u.ä. bekomme (Zuletzt: 2 mal am 26. März 2018). Ich habe hier die Vermutung geäußert, dass es daran liegen könnte, dass ich unter bestimmten Umständen parallel mehrere Requests bzgl. gleichen IP schicke (wenn der Cluster aufgrund von Netzwerk-Konnektivitätsproblemen in ein "Split-Brain"-Szenario kommt) und ob ich das lassen soll (müsste dann eine zentrale Stelle einführen, was ich nicht möchte). Das wurde jedoch weder von mir noch von netcup weiter verfolgt und ich darf mich melden, sobald das wieder vorkommt (hab ich im März nicht gemacht, weil kein Ausfall daraus resultierte).


    Ich hab mein (sehr einfaches) bash-Script, was die Zuweisung der FailOver per XML-Request vornimmt, nicht angepasst. Dass die IP zuerst Ent-Zugewiesen wird im FailOver-Fall wäre wohl auch mein Ansatz gewesen. Dazu muss man bedenken, dass so ein FailOver-Request eh schon eine Laufzeit von 20+ Sekunden hat und es danach auch etwas dauert bis die Pakete anderes geroutet werden. Real ist die Fail-Over-Zeit so 40-50 Sekunden. Da nochmal 20 Sekunden drauf packen, um die IP erst ent-zuzuweisen sollte nicht notwendig sein und führe ich wie gesagt bisher nicht durch.


    Insgesamt ist das Thema für mich lästig und ich stecke zugegebenermaßen auch keine Zeit darein solange alles läuft.

  • Ich hab ein Corosync/Pacemaker-Setup, bei dem ein Verbund aus drei Nodes untereinander schaut, ob die anderen erreichbar sind und für die Ressource "FailOver-IP" voted, wer der Master ist.


    Mein IST-Zustand:

    Kann Server B die anderen beiden nicht mehr erreichen (weil zwei Pings z.B. nicht durchgehen) denkt er, dass er nun alleine ist, und schnappt sich die IP. A und C sind aber durchaus erreichbar und wissen das untereinander auch; da B für die beiden nun weg ist, wird zur Bestätigung erneut das Fail-Over-Script vom aktuellen Master (z.B. Server C) ausgeführt (ist eigentlich ein Konfigurationsfehler von mir gewesen, in dem Fall aber praktisch :D ).

    So werden bei mir ggf. parallel (von Server B und C) für die selbe Fail-Over-IP Zuweisungs-XML-Requests ausgelöst. Dies führt in der Regel aber nicht zu einem Ausfall, da sowohl B als auch C sich ja auch für die IP zuständig fühlen.


    Das Problem ist ja kein Unbekanntes / Ungelöstest und lässt sich durch STONITH ("Shoot the other node in the head") verhindern: Dabei würden Node A und C nachdem Sie B verloren haben entscheiden, dass B erschossen werden muss :( (ist natürlich eine Metapher für Herunterfahren :D ) . Ich wollte auch mal ein Stonith-Device für die Netcup-API schreiben (hard-shutdown); komme aber zeitlich nicht dazu und hat geringe Prio. Es gibt noch das SSH-Stonith, wo einfach per SSH ein "shutdown" an den zu tötenden Node geschickt wird. Sollte man natürlich nicht produktiv einsetzen, da wenn B gar nicht mehr reagiert (z.B. wie erwähnt nicht per Netzwerk erreichbar ist), das SSH-Stonith nutzlos ist und trotzdem ein Split-Brain entstehen kann. Aber besser als nichts.


    Mein Anwendungsfall ist ein MySQL-Reverse-Proxy (HA-MariaDB-Cluster)