(Solved) HASetup: Wenn Master Rebootet gibt es stress

[c-mu]

Hallo!
Ich habe ein Problem mit meinem HA Setup.
Wenn ich meinen Master beispielsweise für Update neustarten muss, dann übernimmt der Slave wunderbar seine Dienste. Ist der Master wieder online, fangen die Probleme an. Packet Loss ohne Ende, Master IP teilweise nicht erreichbar. CARP macht ein "Mischmasch", sprich einige VIP's sind auf dem Master "master", und einige auf dem Slave.

Ich habe jetzt zwar einen Workaround gefunden, der aber nicht schön ist, aber vielleicht gibt es jemanden von euch die ausschlaggebene Idee: Ich muss am Switch das Uplinkkabel zum Master einmal ziehen bzw per CLI den Port deakivieren und anschließend wieder online bringen. Dann fängt sich das ganze system nach 2-3 Minuten wieder und es läuft wie es soll.

Es ist ein HP ProCurve switch, auf den Ports selber ist nichts besonderes aktiv, kein LACP oder ähnliches.

Hat jemand vielleicht eine Idee, was das sein kann? Irgendein Protokoll an das ich nicht denke? ARP Cache vllt?
Master & Slave arbeiten auf der zur Zeit aktuellen Version. Das Problem schleppe ich auch schon viele Versionenlang mit mir mit, was natürlich jedesmal für graue Haare sorgt, wenn ich die Firewall aktualisieren muss.

Bin für jeden Tipp Dankbar!

[JeGr]

Da sind einfach zu wenig Infos dazu da. Ist das Hardware? Was für welche? Läuft die ggf. am Limit oder ist gestresst? Braucht der Master beim Reboot zu lange bis er alle CARP VIPS wieder hat und/oder ist noch gar nicht mit Booten fertig und soll schon wieder übernehmen?

Warum schickst du zudem den Master nicht in Perma-CARP-Maint Modus, damit er nach Neustart nicht gleich übernimmt?
Normales Prozedere bei uns ist immer:
* Standby Node updaten
* Standby Node durchbooten
* Standby Node prüfen ob alles läuft, Logs etc.
* Master Node manuell failovern auf Standby
* PRÜFEN ob Standby als Ersatz sauber läuft
* Dann master updaten
* durchbooten
* prüfen ob sauber aktualisiert wurde (gerade bei Zusatz-Paketen noch)
* erst jetzt Carp Maintenance abschalten und Master Status wieder übernehmen.

Hast dus mal so probiert anstatt "wild" einfach nach Neuboot automatisch schon einfach wieder zurückzuschwenken?

[c-mu]

Hallo und danke für die ausführliche Antwort!

Beide Firwalls laufen auf echter Hardware, welche identisch aufgebaut ist. Die ist auch überdimensioniert und arbeitet nicht am limit. Bei ca. 250 aktiven VPN Sessions + diverses Routing für Webservices läuft die Load bei 0,5-0,8. Belegt sind 11GB RAM von 32.

Intel(R) Xeon(R) E-2226G CPU @ 3.40GHz (6 cores)
32GB RAM
4x 10GBit LWL. wobei alles via VLAN auf einem LWL Interface läuft. Alles bis auf Internet Uplink und Crosover Verbindung beider Firewall für die Config und State Synchronisation.


Beide FW's sind mit je einem 10GBit LWL Kabel an einem HP zl5412, auch der ist nicht am limit.

Braucht der Master beim Reboot zu lange bis er alle CARP VIPS wieder hat und/oder ist noch gar nicht mit Booten fertig und soll schon wieder übernehmen?

Das ist eine interessante Frage: da weiß ich gar nicht wie ich das prüfen kann. Wenn ich manuell nicht eingreife, ist auch 15-30min nach dem Booten des Masters der Zustand "kaputt". Länger habe ich noch nicht gewartet.
Auf der Konsole ist das Login Fenster jedenfalls recht flott da (Enterprise SSD).

Warum schickst du zudem den Master nicht in Perma-CARP-Maint Modus, damit er nach Neustart nicht gleich übernimmt? (...)

Das hatte ich tatsächlich auch schon mal gemacht, aber es zeigte keine Wirkung, im Sinne von: der Slave hat zu diesem Zeitpunkt keine Master Dienste übernommen. Erst nachdem der Master im Reboot Prozess gegangen ist, übernahm der Slave die Master Dienste. UND: der Master war nach dem Reboot auch nicht im Perma-CARP-Maint Modus.

Ich update immer erst den Slave und erst ein paar Tage später den Master. Ich muss gestehen, dass ich den Perma-CARP MAint Mode schon länger nicht mehr getestet habe, da ich auch aus anderen quellen gehört habe,d ass dies eher zu Problemen führt als gutes bewirkt. Es hat jedenfalls noch nie sauber funktioniert bei mir.

[c-mu]

Ich lese gerade an anderer Stelle, dass es vielleicht nützlich sein könnte die Entsprechenden Ports auf Switch Seite auf Portfast bzw. im HP Sprech auf admin-edge-port zu stellen. Ggf. Blockiert Spanning Tree an dieser Stelle doch die entscheidenen ersten CARP Packages.

[JeGr]

Bei CARP/VSRP sowieso auf allen Interfaces, ist Portfast/edge port/whatever auf jeden Fall nicht unwichtig! Wenn der Port erst 3-5s dauert, bis er final up kommt weil erst noch der Tree berechnet wird oder eine Loop Detection rumgruschelt, dann ist das für CARP extrem störend. Sollte das also noch nicht sein, auf jeden Fall mal Reinklöppeln

[c-mu]

DAgegen spricht allerdings, dass M-STP aktiv ist, bei dem der Port sehr schnell online kommt. D.h. der ist eigentlich keine paar Sekunden weg. Ausprobieren werde ich es dennoch!

Für weitere Ideen bin ich aber auch offen :-)

[JeGr]

MSTP ist doch nur multiple, aber selbst wenn es wie RSTP - eigentlich - recht schnell geht, es genügen ein paar Sekunden in denen der Port kurz da, kurz weg, kurz wieder da etc. ist um jedes Mal ein CARP Event zu triggern. Was dann ja wieder einige Prozesse der Sense anwirft (Gateway schwenken, Dienste stoppen, Dienste hochfahren etc.) und das ganze wieder zurück... da kommt dann schon was zusammen

Ansonsten beunruhigt mich auch die Aussage mit dem Reboot und dass es 15-30min später immer noch keinen sauberen Failover/Failback gab. Das klingt absolut nicht gut. Ich würde da auch unbedingt mal mitloggen/tracen, ob ggf. noch andere Geräte HA/HSRP/VRRP sprechen und sich da ins Gehege kommen. Oder was man den Logs dazu entnehmen kann.

Dass der Master auch die Rolle nicht abgibt, wenn er in den Carp Maint Mode geschickt wird, ist dann die Sahnehaube, da würde ich definitiv etwas "defekt" vermuten. Das darf nicht sein und ist kein Standardverhalten.

Grüße

[c-mu]

Ich werde beim nächsten Update, das einen Reboot erfordert, nochmal das Procedere nach Handburch durchspielen. Ggf. war ich auch nicht geduldig genug. Ich erinnere mich, dass von triggern des Rebootes bis zum shutdown auch eine gewisse Zeit verstreicht. Ggf. weil erst 200+ VPN Tunnel abgebaut werden müssen, oder so?!

Auch bin ich gespannt, wie das neue Verhalten sein wird, jetzt wo FastPort an den Ports aktiv ist.

[JeGr]

> Ich erinnere mich, dass von triggern des Rebootes bis zum shutdown auch eine gewisse Zeit verstreicht. Ggf. weil erst 200+ VPN Tunnel abgebaut werden müssen, oder so?!

Wenn du vorher den Master schon in den maint mode versetzt, sollte da kein Tunnel mehr sein, da alle bereits auf dem Standby umgeschwenkt haben Daher die Frage ob dus mal mit dem Modus versucht hast.

[c-mu]

Ich formuliere es mal etwas anders:

Ja ich habe den Modus schon ausprobiert, habe aber nicht sofort einen Effekt bemerkt. Ich hatte erwartet, dass der Master sofort alle Dienste auf den Slave umschwenkt. Das war aber nicht der Fall.

Vielleicht ist es aber das gleiche Phänomen wie beim Reboot: sobald ich einen Reboot trigger, dauert es eine gewisse Zeit, bis dieser auch durchgeführt wird.

Meine Vermutung ist jetzt einfach, dass OPNSense viel Zeit braucht um Dienste (hier vermute ich speziel VPN) runterzufahren. Dann war ich mit dem CARP Maint. Mode vermutlich einfach zu ungeduldig.

Aktuell sind rund 15 IPSec Tunnel (Site2Site), 5 OpenVPN Site2Site und, tagesabhängig, zwischen 200-250 OVPN Clients verbunden. Ich denke das kann schonmal einen moment dauern bis der Dienst gestoppt ist.

[JeGr]

> Ja ich habe den Modus schon ausprobiert, habe aber nicht sofort einen Effekt bemerkt. Ich hatte erwartet, dass der Master sofort alle Dienste auf den Slave umschwenkt. Das war aber nicht der Fall.

Hatte ich oben m.W. so verstanden und schon angemerkt, dass das nicht der Normalfall sein sollte. Finde ich beunruhigend. Wenn du es aber mal ausprobieren kannst und dazu die Logs anschauen und timen, wie lange er ungefähr braucht, wäre das sehr interessant als Anhaltspunkt.

Ich kann dir als Gegenwert unseren RZ Cluster anbieten, der zwar auf pfSense läuft, aber für einen Schwenk von ca. 18 IPsec Tunneln, 4 OVPN S2S Tunneln und ca. zwei Dutzend OVPN RAS nur ein paar Sekunden braucht. Der Standby fährt quasi sofort nach drücken die VPNs hoch und der Master fährt sie runter. Da bei VPNs nichts stateful übernommen werden kann (da der VPN Server auf dem Standby nicht lief und keine Infos darüber hat, welche Client IP bspw. ein Client hatte), ist an der Stelle ohnehin mit einem "Ruckler" zu rechnen. VPNs dürfen aber immer (kurz) abreißen, das ist eigentlich allen Kunden klar. Nur nicht ständig

Daher finde ich es extrem merkwürdig und würde damit rechnen, dass irgendwo in den Logs was dazu auftauchen sollte, wenn die Dienste auf dem Master nicht gestoppt werden können (oder auf dem Standby nicht angefahren).

VPNs sollten aber wie gesagt durch ihre Natur kein Showstopper sein.

Viele Grüße

[c-mu]

Kurzes Feedback:
die Probleme die ich hatte, lagen wohl an den Intel X710 Netzwerkkarte. Ich habe vergangenes Wochenende auf Melanox gewechselt und seit dem funktioniert alles tadellos!