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

5.8 KiB

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)

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. Das kostet dann entsprechend 2 Personentage oder mehr - je nachdem, wie viele Personen die Ersatzmaschine installieren. Und da der Ersatz quasi sofort gestellt werden muss, ist Stress ein zusätzlicher Faktor dabei. Bonuspunkte gibt es dann, wenn eine Person diese Aufgabe in Vertretung für eine andere Person bewältigen soll. (Ja, die Doku dafür kann man weiter verbessern, aber trotzdem bleibt es eine fiese Aufgabe für Vertretungen.)

Kurz: Kann man machen, hat bisher aber keinen großen Spaß gemacht. Bisher habe ich dabei immer gut Plusstunden gesammelt.

Mehr Wartung und Pflege

Gerade für zentrale, wichtige Dienste ist eine häufige Wartung und Pflege um so wichtiger. Fakt ist: Ohne redundanten Betrieb traut man sich soetwas aber fast nicht - aus Angst vor unerwarteten Problemen und daraus resultierender Downtime. Wartungsintervalle werden somit immer größer und größer - das ist nicht gut.

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)

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

  • 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)