Brainstorming Funktionalität basic
This commit is contained in:
parent
12c05829c7
commit
3b17557777
|
@ -48,3 +48,28 @@ Geplante Änderungen können zuerst auf passives System angewendet werden, bevor
|
||||||
* 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
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue