91 lines
4.8 KiB
Markdown
91 lines
4.8 KiB
Markdown
# Brainstorming Anforderungen/Hintergründe
|
|
|
|
|
|
## Warum Hochverfügbarkeit?
|
|
|
|
|
|
### Die Basics
|
|
|
|
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.
|
|
|
|
Viele Dienste und Arbeiten benötigen eine zuverlässige Netzwerkverbindung, mindestens aber eine unterbrechungsarme Verbindung.
|
|
|
|
* Saisonale Einschreibungsverfahren mit Fristen
|
|
* Saisonale Prüfungsan/abmeldungen mit Fristen
|
|
* Kommunikation per E-Mail
|
|
* eduroam
|
|
* Zeiterfassung
|
|
* Automatisierte Backups (u.A. für leichte/mittlere Desaster-Recovery)
|
|
* Geschäftsprozesse der einzelnen Organisationseinheiten (Ausleihe, Personalverwaltung, Studierendenverwaltung, ...)
|
|
|
|
Natürlich können größere Ausfälle oft ausreichend verkraftet werden, aber ich schlafe ohne große Ausfälle deutlich entspannter.
|
|
|
|
|
|
### Verringerte Auswirkung von Hardwaredefekten
|
|
|
|
Fällt eine Firewallmaschine aus, steht eine zweite Maschine für einen Failover bereit.
|
|
Geschätztes Risiko: hoffentlich 1 mal in 3-5 Jahren, dafür immer zu ungünstigen Zeitpunkten (es ist immer ungünstig).
|
|
|
|
* Automatischer Failover (max 10s Unterbrechung)
|
|
* Manueller Failover bei Cold-Standby (menschliche Reaktionszeit + max ~5 Minuten Unterbrechung)
|
|
|
|
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.
|
|
|
|
|
|
### Automatische Installation von Software-Updates (Sicherheitspatches)
|
|
|
|
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)
|
|
|
|
|
|
#### Erwartete Nutzen bei Hochverfügbarkeit
|
|
|
|
* 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)
|
|
|
|
|
|
### Durchführung von Konfigurationsänderungen
|
|
|
|
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:
|
|
|
|
* :1
|
|
* Update durchführen
|
|
* Neustart durchführen
|
|
* Automatische Tests?
|
|
* "Gesundmeldung" an der aktiven Firewall
|
|
* Failover
|
|
* GOTO 1
|
|
|