0
0
Fork 0

Brainstorming Funktionalität basic

This commit is contained in:
Jan Philipp Timme 2020-01-03 22:45:36 +01:00
parent 12c05829c7
commit 3b17557777
1 changed files with 26 additions and 1 deletions

View File

@ -47,4 +47,29 @@ Nutzen bei Hochverfügbarkeit
Geplante Änderungen können zuerst auf passives System angewendet werden, bevor es aktiv geschaltet wird. Geplante Änderungen können zuerst auf passives System angewendet werden, bevor es aktiv geschaltet wird.
* Bei Problemen kann auf das zweite System zurückgeschwenkt werden, sodass unerwartete Probleme nur zu wenigen Minuten Downtime führen. Das dann kaputte, passive System kann in der Zeit untersucht und repariert werden. * Bei Problemen kann auf das zweite System zurückgeschwenkt werden, sodass unerwartete Probleme nur zu wenigen Minuten Downtime führen. Das dann kaputte, passive System kann in der Zeit untersucht und repariert werden.
Ja, an dieser Stelle wäre ein Testsystem die erste Instanz, aber auch danach können produktiv menschliche Fehler passieren. Ich bin da recht gut drin. Ja, an dieser Stelle wäre ein Testsystem die erste Instanz, aber auch danach können produktiv menschliche Fehler passieren. Ich bin da recht gut drin.
## Benötigte Funktionalität
Damit sich die Konzipierung und Umsetzung auch lohnt, soll hier geklärt werden, welche Anforderungen an eine hochverfügbare Firewall aus zwei Maschinen gestellt werden.
### Failover bei Ausfall einer Maschine
Wenn die aktive Maschine für die passive Maschine nicht mehr erreichbar ist, muss die passive Maschine aktiv werden.
Diese Funktion kann mit `keepalived` erreicht werden.
### Automatische Updates mit Sanity-Check
Sobald eine passive Maschine mit ihrem Update dran ist, muss die aktive Maschine darauf achten, dass die passive Maschine das Update erfolgreich übersteht:
* :1
* Update durchführen
* Neustart durchführen
* Automatische Tests?
* "Gesundmeldung" an der aktiven Firewall
* Failover
* GOTO 1