Hochverfuegbarkeit

[wintermute]

Wie funktioniert Dein Ansatz?

Mal als Zwischenmeldung ein kleiner Konzeptabriss, damit keiner auf die Idee kommt das Thema waere eingeschlafen

• Es werden ein Master (mit der IP "mIP") und ein Slave (mit der IP "sIP") benutzt, der Slave befindet sich dabei im Hot-Standby - er ist also permanent aktiv und "wartet" darauf, dass der Master ausfaellt
• Zusaetzlich wird eine "virtuelle IP" (hier "vIP" genannt) benutzt ueber die die Visu jeweils erreichbar ist. Master bzw Slave konfigurieren dazu ihr Netzwerk entsprechend um und setzen passende NAT-Regeln auf (ersteres ist auch der Grund wieso das unter Docker nicht funktionieren wird). Das NAT reicht ALLE Netzwerkverbindungen von der virtuellen IP auf die kanonische IP durch, also egal ob http(s), ssh, ftp, mqtt, whatever...
• Der Master ist also grundsaetzlich wie gewohnt ueber seine kanonische IP (mIP) erreichbar und fuehrt auch alle Kommunikation ueber dieser IP durch. Die virtuelle IP wird nur fuer die Visu und Zugriffe von ausserhalb genutzt (also zB Visu-Zugriff ueber Reverse-Proxies, externe Zugriffe auf irgendwelche KOs per HTTP und aehnliches).
• Faellt der Master aus (dies wird im wesentlichen ueber arpings ueberprueft) uebernimmt der Slave die virtuelle IP und ersetzt so den Master.
• Kommt der Master zurück so wird der Slave die Kontrolle wieder abgeben (zumindest ist das momentan so angedacht, muss ich mal gucken ob und wie genau das Sinn macht).

In etwas detailreicher:
Es wird einen LBS geben der die komplette Funktionalitaet beinhaltet, es werden keine Zusatzinstallation notwendig. Allerdings ist ein Update des iputils-Paketes notwendig weil die Version im 6.5er CentOS zu buggy ist um das vernueftig umzusetzen. Der LBS kann das Update bei Bedarf auch automatisch einspielen.
Auf dem Master wird der LBS installiert und entsprechend konfiguriert, auf dem Slave kann ein leeres Projekt angelegt werden das nur aus demselben LBS mit identischer Konfiguration besteht.

Wenn der Master startet:

1. konfiguriert er - sofern vIP nicht bereits im Netz vergeben ist - vIP als zusaetzliche IP auf das angegebene Interface und etabliert die NAT-Regeln
2. ist vIP bereits vergeben wird davon ausgegangen das momentan der Slave aktiv ist und solange gewartet bis vIP wieder verfuegbar ist
3. der LBS spaltet einen Prozess ab, der den EXEC-Teil des LBS ueberwacht - dies ist notwendig damit bei einem Absturz des EXEC-Teils (bzw von Edomi) die Netzwerkkonfiguration wieder rueckgaengig gemacht werden kann
4. das aktuellste Backup wird per FTP auf den Slave uebertragen
5. er wartet eine gewisse Zeit und
6. ueberprueft ob ein neues Backup vorhanden ist und uebertraegt dieses ebenfalls zum Slave
7. GOTO 5

Wenn der Slave startet:

1. versucht er den Master via mIP zu erreichen - wenn dies nicht gelingt GOTO 9, andernfalls
2. er legt - falls noch nicht geschehen - einen FTP-User mit dem konfigurierten Passwort an
3. der LBS spaltet einen eigenen Prozess ab und beendet Edomi
4. er ueberprueft ob ein neues Backup hochgeladen wurde und entpackt dieses - dabei werden einige Aenderungen vorgenommen, vornehmlich in der edomi.ini - vornehmlich weil mIP ungleich sIP
5. er ueberprueft ob er mIP erreichen kann, falls das nicht klappt GOTO 8, andernfalls
6. wartet er gewisse Zeit
7. GOTO 4
8. da der Master nicht mehr erreichbar ist wird jetzt der Slave aktiv, das macht er indem er rebootet, das entspricht dann effektiv einem GOTO 1
9. der EXEC-Teil des LBS konfiguriert vIP auf das entsprechende Interface, etabliert passende NAT-Regeln und versucht das Netzwerk durch entsprechende Pakete davon zu ueberzeugen, dass vIP jetzt ueber eine andere MAC zu erreichen ist
10. der Slave sollte jetzt ueber vIP erreichbar sein und laeuft mit dem letzten Backup-Stand des Masters
11. im EXEC-Teil wird in regelmaessigen Abstaenden versucht mIP zu erreichen, wenn dies klappt geht der Slave davon aus, dass der Master wieder funktioniert und rebootet sich selber, das ist faktisch ein GOTO 1

Ich hoffe, das war jetzt einigermassen verstaendlich formuliert o\
Der Master-Teil ist schon fast komplett fertig, auf der Slave-Seite fehlen noch ein paar Punkte. Ist alles ein wenig komplexer als anfaenglich gedacht

[trollmar]

WOW!

Ließt sich auch kompliziert
...hoffe das klappt!!

Das Konzept ist also auf den Hardware Ausfall vom Edomi-Master konzipiert?
Wer macht den die arpings? der Slave?

LG

[wintermute]

Das Konzept ist also auf den Hardware Ausfall vom Edomi-Master konzipiert?
Wer macht den die arpings? der Slave?

Jein & Jein...
Auch der Master pingt den Slave an, aber das hat nur rein informativen Charakter - bzw kann es zur Alarmierung genutzt werden wenn der Slave ausfallen sollte (das merkt man ja fuer gewoehnlich nicht).
Und auch ein Software-Ausfall (also zB MySQL, EDOMI, Kernel Panic) auf dem Master fuehrt zur Umschaltung auf den Slave (zumindest ist das der Plan )

[DerSeppel]

Da bin ich mal gespannt.
Habe das mal so ähnlich mit zwei Servern bei Hetzner gemacht.
Alle Zugriffe über eine FailoverIP. Auf beiden Maschinen ein haproxy als Loadbalancer.
Wenn der Slave sieht, dass der Master nicht mehr antwortet, dann die IP auf sich ziehen. Geht bei Hetzer über ne API.

Habe schon überlegt wie ich das hier umgesetzt bekomme.

Seit dem Wochenende läuft bei mir ein Esxi laufen. Bin wirklich gespannt was du da zusammengebaut hast.

[Brick]

ganz kurz... zum Verständnis ...
der Slave zieht sich vom Master das Projekt ? (über das Backup)... wann passiert das ?
vor dem Umschalten oder zyklisch ?

Denn wenn das vor dem Umschalten passiert hat man ja, je nach Backup schon ein paar Minuten downtime..
nicht das das jetzt sehr wild wäre... aber wäre es nicht auch praktisch, zb. jede Nacht um kurz nach 12 (wenn das
Master Backup gemacht wurde) das auf den Slave zu pushen ?

Gruß Martin

[DerSeppel]

Wenn ich es richtig gelesen habe in Beitrag #16 dann macht er das zyklisch, jede Nacht.
Vor dem Umschalten macht ja wenig Sinn, da nur umgeschaltet wird, wenn der Master mutmaßlich tot ist.

[Brick]

habs jetzt ein paar mal durchgelesen und jetzt glaub ich verstanden
Das übertragen macht er zyklisch... (nach einer eingestellten Zeit)

Gruß Martin

[wintermute]

Das übertragen macht er zyklisch... (nach einer eingestellten Zeit)

Eigentlich macht er die Uebertragung des Backups "sofort wenn ein neueres Backup gefunden wurde - oder nen Hauch spaeter".
Spaeter deswegen, weil in der Hauptschleife (logischerweise) bei jedem Durchlauf ein paar Sekunden gewartet wird und auch weil das File erst dann uebertragen wird, wenn seine mtime weit genug zurueck liegt - um zu verhindern, dass unfertige Backup Files uebertragen werden. Also nochmal so 20s oder so drauf gerechnet - IMHO lieber etwas mehr als etwas zu wenig.
Also wenn man beim Master auf "Backup downloaden" klickt, dann sollte der Slave so circa nach ner Minute denselben Projektstand haben. Selbiges gilt natuerlich fuer die naechtlichen Backups.

Aber eine ueberschaubare Downtime hat man so oder so, das geht auch nicht weg. Erstmal muss der Slave sich ja sicher sein, dass der Master auch tot ist und nicht nur grad neu startet oder ein Projekt aktiviert. Also wird vor der Uebernahme eine gewisse Totzeit abgewartet und die sollte sich schon im Bereich von ein paar Minuten bewegen. Dazu kommt dann noch die Zeit fuer den Neustart des Slaves.

[Brick]

seh ich jetzt aber eh auch als unkritisch... wenn da mal 2-5 min. das System weg is... man verliert da ja kaum was...

Wie ist der Weg zurück ?

Also wenn der Slave jetzt zb. um 1 Uhr Nachts übernehmen muss, gehen ja zb. alle Messwerte die in einer Datenbank
gespeichert werden in das "Projekt" am Slave. Wenn ich dann am Abend den Master wieder am laufen hab, will ich ja die
Daten die ich Tagsüber gesammelt hab nicht verlieren. Sprich, es müsste am Slave ein Backup gezogen werden und am Master
wieder eingespielt werden...

Gruß Martin

[wintermute]

Wie ist der Weg zurück ?

Prinzipiell gibts ja bei Rueckkehr des Masters erstmal zwei Moeglichkeiten:

1. man muss das manuell zurueckstellen
2. der Slave gibt von alleine ab und der Master uebernimmt wieder

Nummer 2 klingt zwar smarter, aber da der Master ja nicht "einfach so" ausfallen und wieder funktionieren sollte ist ohnehin anzunehmen, dass in der Zwischenzeit irgendwelche manuelle Arbeit anfaellt. Und in dem Zeitraum kann und wird es eventuell wieder zu Ausfaellen des Masters kommen - wenn Master und Slave dann waehrendedessen Pingpong mit dem Projekt spielen ist ja auch keinem geholfen. Also wird es wohl auf eine manuelle Umschaltung zurueck zum Master hinauslaufen.

Und ja, genau die Sache mit den verlorenen Daten ist so ein Dingen dabei. Momentan ist erstmal nicht vorgesehen, dass irgendwelche Daten vom Slave zurueck zum Master gespielt werden. Der Master startet also mit exakt demselben Status (das gilt auch fuer remanente KOs und aehnliches) wie vor dem Ausfall.

Erstmal isses ja so, dass die Backups nicht minuetlich erstellt und transferiert werden, also startet der Slave schonmal zwingend mit einem Datenloch das im schlimmsten Fall 24h tief sein kann. Daraus folgt wiederum, dass man die Daten des Slaves nicht "einfach so" in den Master spielen kann - wenn ueberhaupt muesste man die Datenbanken irgendwie verschmelzen (ich schreib jetzt bewusst nicht "merge" )... keine Ahnung, wenn da jemand ne Idee hat, immer her damit.

Davon ab: wenn der Master in einem nonHA-Setup ausfaellt gehen auch Messdaten verloren. So haste wenigstens noch eine Visu und nen Geraet welches dein Haus steuern kann

[Brick]

Du müsstes die Datenbank noch zusätzlich auf ein eigenes System auslagern .. so das Master und Slave auf die gleiche zugreifen

Aber das ist albern... wie du sagst, je nachdem wann das Ding ausfällt hat man Datenverlust.. und beim zurück von Slave auf Master,
würde ich da auch eher auf den manuellen Weg setzten, da man so und so Hand anlegen muss... KISS Prinzip..

Gruß Martin

[EinAnfaenger]

Bin kein MySQL Experte, aber wenn man den Datenverlust minimieren möchte wäre evt. Log-Shipping eine Option.

[crewo]

Das mit der Datenbank würde auch so gehen über Master-Master-Replikation, oder?

[wintermute]

Das mit der Datenbank würde auch so gehen über Master-Master-Replikation, oder?

Ja, vermutlich. Kann man spaeter mal angehen, wenn die Grundlagen funktionieren... Baby-Schritte und so

[DerSeppel]

Ja, vermutlich. Kann man spaeter mal angehen, wenn die Grundlagen funktionieren... Baby-Schritte und so

Ich habe das im oben erwähnten Fall mit Galera gemacht. Ich weiss nicht, wie da der Stand der Entwicklung ist, aber ist vielleicht mal einen Blick wert.