Telefonie findet inzwischen als VoIP-Datenverkehr statt. Menschen mögen es nicht, wenn ihre Telefongespräche abgebrochen werden, oder ihr Telefon für mehr als 15-20 Minuten nicht erreichbar/verfügbar ist.
Mal kurz die BWL-Perspektive ausgepackt: Selbst kurze Unterbrechungen der Netzwerkversorgung bringen viele Beschäftigte (und auch Studierende) bei der Durchführung einer Aufgabe aus dem Tritt.
Plötzlich funktioniert etwas nicht mehr, und das lenkt von der eigentlich bearbeiteten Aufgabe ab.
Bis die Beschäftigten sich dann auf eine andere Aufgabe konzentrieren können, die keine Netzwerkverbindung erfordert - oder bis sie sich wieder auf ihre ursprüngliche Aufgabe konzentrieren können, nachdem die Netzwerkversorgung wiederhergestellt wurde, vergeht zusätzliche Zeit.
Es ist in unserer Branche nicht so wichtig, wie in privaten Unternehmen, aber auch bei uns gehen dadurch während eines Ausfalls mindestens ca. 500-1000 Personenstunden verloren, die vom Staat (also auch von mir, und teilweise den Studiengebühren) finanziert werden.
Das können schon so 10.000€+ sein, wenn ich mich nicht verschätze.
In diesen beiden Fällen kann eine Ersatzmaschine nach "best effort" bereitgestellt werden, weil die passive Maschine für diese Zeit den Dienst aufrecht erhält.
Die manuelle Installation einer Ersatzmaschine dauert nach bisherigen Erfahrungen ungefähr 1-2 Tage bei guten Bedingungen, das entspricht 1-2 Tagen Downtime oder mehr.
Beim händischen Einspielen von Updates ergeben sich folgende Situationen, die
* Neustarts von Diensten erforderlich (kurze Serviceunterbrechung)
* Bei besonderen Diensten oder Kernel-Updates Neustart des Betriebssystems erforderlich (mittleres Risiko [alle paar Wochen], wenige Minuten Downtime)
* Probleme nach einem Update möglich (geringes Risiko [geschätzt 1-2 mal pro Jahr], mindestens 30-60 Minuten oder mehr Downtime, da manueller Eingriff erforderlich)
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.
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:
* Automatische Updates können zuerst auf passivem System installiert werden
* Unbeaufsichtigte, automatische Neustarts bei gestaffeltem Updatekonzept möglich:
1. passives System installiert Updates und startet neu
2. Aktives System folgt erst dann, wenn das passive System die Updates erfolgreich überstanden hat (Boot war erfolgreich, Konfiguration und aktive Dienste entsprechen vorgegebenen Erwartungen)
* Systeme sind auf mit kürzester Verzögerung auf dem neustem Stand
* Durch regelmäßiges Wechseln zwischen aktiv/passiv ist sichergestellt, dass beide Systeme sich gegenseitig vertreten können (Tages-/Wochenrhythmus)