Feature #1205
open
Hohe Verfügbarkeit des BAS
30%
Description
Der BAS dient als globaler Einstiegspunkt für alle Maschinen und wird so zum ein single point of failure.
Daher ist die hohe Verfügbarkeit (HA) des Dienstes zwingend notwendig, um das Booten der Maschinen stets zu gewährleisten.
Hierzu sollten verschiedene HA-Techniken diskutiert und evaluiert werden.
Updated by Jonathan Bauer almost 6 years ago
- Tracker changed from Bug to Feature
Updated by Dirk von Suchodoletz almost 6 years ago
Das Ganze muss im Zusammenhang mit dem Aussehen der BAS-Basiskomponente diskutiert werden (-> Manuel Messner). Hierbei wird das Thema Konfigurationsdatei und Datenbank eine Rolle spielen ...
Updated by Dirk von Suchodoletz almost 6 years ago
- Assignee set to Christian Hofmaier
Diskussion von HA-Failover-Lösungen (mögliche Setups, Dateinsynchronisation, ...)
Ausfall-Detection, Umgang mit den verschiedenen Fehlerfällen (z.B. Read-Only, wenn Primary weg, ...)
Verschiedene Fehlerfälle und Umgang mit diesen im Wiki diskutieren/dokumentieren
HA für TFTP mit Tamas (DHCP/Infoblox) diskutieren
Updated by Christian Hofmaier over 5 years ago
Ergebnis der Diskussion #1217:
- TFTP Ausfall soll vom DHCP (Infoblox) geregelt werden
- iPXE-Skripts können Fallback selber regeln (z.B. DNS Round Robin)
- Lokal booten wenn gar nichts geht
Updated by Dirk von Suchodoletz over 5 years ago
Die TFTP-Seite wurde schon mit Tamas besprochen?
Updated by Dirk von Suchodoletz about 5 years ago
- Priority changed from Normal to High
Mit Aufnahme des Produktivbetriebs für die WM4 ist das ein zentrales Feature. Wie ist hier der Stand?
Updated by Udo Daniel Walter about 5 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 30
Es ist jetzt ein HAProxy davorgeschaltet. Der Node Server läuft also nicht mehr direkt auf Port 443. HTTP wird jetzt auch auf HTTPS weitergeleitet.
Unter https://bas.intra.uni-freiburg.de:1337/haproxy_stats gibts auch eine stats Page dazu. Die Anmeldedaten gibts dann persönlich.
Dadurch könnten jetzt mehrere Instanzen des Node Application gestartet werden und die Anfragen werden durch Load Balancing verteilt.
Wenn man das ganze auf einer zweiten Maschine noch einrichtet könnte man mit einer floating IP Adresse beide ansprechen, je nach dem welche erreichbar ist.
Damit hätte man auch zwei TFTP Server und so verbesserte Ausfallsicherheit. Wir reden mal mit Tamas darüber.
Updated by Dirk von Suchodoletz about 4 years ago
- Due date set to 05/07/2020
Benennung von Maschinen: Interne IP-Adressen sollten nie auf eine offizielle Domain, z.B. uni-freiburg.de enden. Wie ist der aktuelle Stand?
- Wo wird im Moment der BAS betrieben?
- Gibt es eine zweite, dritte Maschine?
- Wie erfolgt der Abgleich der Datenhaltung (Sync, Async - Master/Minion, ...)?
- Überwachung des Zustandes, Verfügbarkeit der Instanzen?
- Gibt es Ansible o.ä. Skripten für ein automatisches Redeployment?
- ...
Updated by Dirk von Suchodoletz about 4 years ago
Hier nochmal kurz der Stand der Diskussion:
Ebene des BAS: Das sollte recht klar sein. Es gibt einen Master und min. einen Minion (bzw. auch mehrere). Nur der Master hat das UI und nur hier können Daten tatsächlich geändert werden. Die Minions erhalten regelmäßig Updates vom Master. Es wird auf komplexe Synchronisierung etc. verzichtet und eine Änderung von Daten muss zur Not auf das Wiederanfahren des Masters warten.
Ebene HA: Die ist etwas schwieriger. Hier werden wir schauen, ob wir das über API-Calls (FQDN-IP ändern) oder über andere Mechanismen (floating IPs, SDN, ...) regeln.
Updated by Simon Rettberg about 4 years ago
Floating IP wäre einfach, weil wir dann keine Anforderung an die Netzabteilung haben, außer eben dass an beiden Standorten das gleiche VLAN sein muss. die RO-Instanz macht dann alle X Sekunden ein arping auf den master und übernimmt notfalls die IP. Gibts sicherlich n duzend fertige Implementierungen für, aber man kann das sicher auch in 20 Zeilen bash nachbauen.
Hat den Nachteil dass der Master ja auch so halb kaputt rumeiern könnte, wo er keine Requests mehr verarbeiten kann weil httpd gecrasht oder sich ins nirvana geswapt, aber der Kernel noch auf ARP antwortet. Da würde es auch nicht sonderlich viel bringen, stattdessen vom slave den HTTP-Port zu prüfen, da dann beide Kisten auf ARP antworten.
Per API-Call an Infoblox den fqdn für den next-server umbiegen: Bis zu 10 min Verzögerung, außerdem ist die Frage, ob Infoblox bei der Nummer die next-server tatsächlich auch aktualisiert. Also allgemein: Wann übersetzt Infoblox einen Hostnamen den ich bei next-server eingegeben habe zu einer IP? Einmal beim Speichern des next-servers? Bei jedem mal wenn ein Client danach fragt? Alle drölf Stunden? Wenn ich einen Hostnamen ändere, der irgendwo als next-server benutzt wird?