0
0
Fork 0
concept-ha-fw-nftables/Brainstorming.md

43 lines
2.6 KiB
Markdown
Raw Normal View History

# Brainstorming Anforderungen/Hintergründe
## Warum Hochverfügbarkeit?
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.
Und so ganz nebenbei verlassen sich mittlerweile fast alle Dienste und Arbeiten bei uns darauf, dass eine zuverlässige Internetverbindung vorhanden ist.
* 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.
### 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)
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.