Aufgaben Hochverfügbarkeit

Lösung

Stunden pro Jahr: 365 × 24 = 8.760 h. Maximale Downtime = 8760 × (1 − SLA).

• 99,0%: 8760 × 0,01 = 87,6 h ≈ 3 Tage 15 Stunden
• 99,9%: 8760 × 0,001 = 8,76 h ≈ 8 Stunden 45 Minuten
• 99,99%: 8760 × 0,0001 = 0,876 h ≈ 52 Minuten 35 Sekunden
• 99,999%: 8760 × 0,00001 = 0,0876 h ≈ 5 Minuten 15 Sekunden

Faustregel: jede zusätzliche „Neun" reduziert die erlaubte Downtime um Faktor 10. Mehr in L1.

Lösung

MTBF (Mean Time Between Failures): mittlere Zeit zwischen zwei aufeinanderfolgenden Ausfällen eines Systems. Maß für die Zuverlässigkeit.

MTTR (Mean Time To Repair/Recovery): mittlere Zeit zur Wiederherstellung nach einem Ausfall. Maß für die Wartbarkeit.

Verfügbarkeits-Formel: A = MTBF / (MTBF + MTTR)

Leichter beeinflussbar: in der Praxis meist die MTTR. Sie hängt von Prozessen, Tools, Training und Automatisierung ab. Verbesserungen erfordern oft keine Investitionen in neue Hardware:

• Bessere Monitoring-Tools verkürzen die Detection-Zeit
• Dokumentierte Runbooks beschleunigen die Reparatur
• Automatisches Failover eliminiert manuelle Schritte
• Cross-Training reduziert Abhängigkeit von einzelnen Personen

MTBF erhöhen kostet oft mehr (bessere Hardware, mehr Redundanz). Mehr in L2.

Lösung

Ausgangswert: A = 2000 / (2000 + 4) = 2000 / 2004 = 0,998004 ≈ 99,80%

Das entspricht ca. 17,5 Stunden Downtime pro Jahr.

Mit MTTR = 1 Stunde: A = 2000 / (2000 + 1) = 2000 / 2001 = 0,999500 ≈ 99,95%

Das entspricht ca. 4,4 Stunden Downtime pro Jahr.

Erkenntnis: durch Verkürzung der MTTR von 4h auf 1h (Faktor 4) konnte die Downtime um Faktor 4 reduziert werden. Effiziente Investition in Monitoring und Automatisierung statt teurere Hardware.

Lösung

Single Point of Failure (SPoF): eine Komponente in einem System, deren Ausfall das gesamte System lahmlegt. SPoFs haben keine Redundanz – wenn sie kaputt gehen, gibt's keinen Ersatz.

Ebenen mit Beispielen:

• Energie: einzelner Stromkreis, einzelne USV ohne Redundanz, fehlendes Notstrom-Aggregat
• Hardware: einzelne Festplatte ohne RAID, einzelne CPU, eine Netzwerkkarte
• Netzwerk: ein Switch, eine Firewall, ein Uplink, ein Internet-Provider
• Server: einzelner Webserver, einzelne VM auf einem Host
• Daten: einzelne Datenbank ohne Replikation, fehlende Backups
• Services: einzelner DNS-Server, einzelner AD-Controller, einzelner License-Server
• Standort: ein Rechenzentrum, ein Bürogebäude
• Personen: nur ein Admin kennt das System, fehlende Vertretungsregelung

Wichtig: RAID ist kein Backup, Cloud-Sync ist kein Backup – das sind klassische Anti-Patterns. Mehr in L3.

Lösung

VFD – Offline / Standby: Der Server bekommt im Normalfall direkt Netzstrom. Bei Ausfall schaltet die USV auf Batterie um – mit 5-10 ms Umschaltzeit. Einfachster und günstigster Typ.

• Einsatz: Heim-PC, einfache Büro-Geräte
• Vorteil: günstig
• Nachteil: Schutz nur vor Stromausfall, langsame Umschaltung

VI – Line-Interactive: Beinhaltet einen Automatic Voltage Regulator (AVR), der Spannungsschwankungen ausgleicht ohne Batterie-Eingriff. Bei größeren Problemen Umschaltung auf Batterie mit 2-5 ms.

• Einsatz: KMU-Server, kleine NAS-Systeme
• Vorteil: Schutz auch vor Über-/Unterspannung
• Nachteil: nicht für hochkritische Systeme

VFI – Online / Double-Conversion: Der Strom geht immer durch den Wechselrichter, der von der Batterie gespeist wird. Der Server sieht nie direkt das Netz. Umschaltzeit: 0 ms.

• Einsatz: Rechenzentren, kritische Server, Medizintechnik
• Vorteil: Schutz vor allen 9 Strom-Anomalien (Blackout, Sag, Surge, Spike, Frequenzabweichung, Oberwellen etc.)
• Nachteil: teurer, mehr Energieverbrauch (Doppel-Konversion)

Goldstandard für Rechenzentren, weil die VFI alle Strom-Probleme filtert. Server bekommen perfekten Sinus-Strom konstanter Spannung und Frequenz. Bei Netzausfall keine Umschaltung – Batterie übernimmt nahtlos. Schützt Hardware vor Beschädigung durch Spannungsspitzen (z.B. Blitzeinschlag). Mehr in L4.

Lösung

Layer-4 Load Balancer (TCP/UDP-Ebene):

• Verteilt Anfragen basierend auf IP-Adresse + Port
• Kennt den Inhalt der Pakete nicht (keine Anwendungsdaten)
• Sehr schnell, geringe Latenz
• Funktioniert für jedes TCP/UDP-Protokoll
• Keine inhaltsbasierten Entscheidungen möglich
• Beispiele: AWS NLB, HAProxy im TCP-Modus

Layer-7 Load Balancer (HTTP-Ebene):

• Entscheidet basierend auf HTTP-Headern, URL, Cookies, Hostname
• Kann SSL terminieren, Inhalte modifizieren
• URL-basiertes Routing möglich (/api/* → API-Server)
• Cookie-basierte Sticky Sessions, WAF-Funktionen
• Langsamer (Pakete müssen analysiert werden)
• Nur für HTTP/HTTPS-basierte Anwendungen
• Beispiele: AWS ALB, nginx, Traefik, Envoy

Für Microservices mit URL-basiertem Routing: eindeutig Layer-7 Load Balancer. Beispiel:

• /api/users/* → User-Service-Pool
• /api/orders/* → Order-Service-Pool
• /static/* → CDN/Static-Server

Layer-4 könnte das nicht – er sieht nur Ziel-IP und Port, kann keine URL-Entscheidungen treffen. Mehr in L5.

Lösung

Active-Active Cluster: alle Knoten arbeiten gleichzeitig und bedienen Anfragen. Die Last verteilt sich auf alle. Bei Ausfall eines Knotens übernehmen die anderen seine Last zusätzlich.

• Vorteil: maximale Hardware-Auslastung, bessere Skalierung, kein „verschwendeter" Standby
• Nachteil: komplexer (verteilte Zustände, Konflikte möglich), Risiko der Überlast
• Geeignet für: zustandslose Services (Web-Server, App-Server)

Active-Passive Cluster: ein Knoten ist aktiv, der andere wartet als Standby. Bei Ausfall übernimmt der Standby (Failover).

• Vorteil: einfacher, kein Daten-Konflikt-Risiko, klassische Architektur
• Nachteil: 50% der Hardware ungenutzt, Failover dauert
• Geeignet für: zustandsbehaftete Services (klassische Datenbanken, File-Server)

Kernkonzepte:

• Heartbeat: periodisches „Ich lebe"-Signal zwischen Knoten. Bleibt es aus, gilt der Knoten als ausgefallen.
• Quorum: das Mehrheits-Prinzip. Nur die Mehrheit der Knoten darf weiterarbeiten. Bei 5 Knoten braucht's mindestens 3. Verhindert Split Brain bei Netzwerk-Partitionen.
• Split Brain: Horror-Szenario bei Netzwerk-Trennung: zwei isolierte Teil-Cluster denken jeweils sie wären die einzigen, arbeiten beide weiter, verursachen Datenkonflikte.
• Fencing / STONITH („Shoot The Other Node In The Head"): ausgefallener Knoten wird physisch/logisch abgeschaltet (via IPMI, iLO, Power-Distribution-Unit), bevor andere Ressourcen übernehmen. Verhindert dass er später Konflikte verursacht.

Warum ungerade Knoten-Anzahl? Bei gerader Anzahl (z.B. 2 oder 4) kann es bei Netzwerk-Partition zu Patt-Situationen kommen, in denen keine Hälfte Quorum hat. Bei ungerader Anzahl (3, 5, 7) gibt es immer eine Mehrheit. Alternative bei 2-Knoten-Clustern: ein Witness oder Quorum-Disk als zusätzlicher Schiedsrichter. Mehr in L6.

Lösung

Failover-Phasen:

1. Detection: Ausfall erkennen (Heartbeat-Timeout, Health-Check-Fehler) – 3-10 Sek
2. Verification: Fehler bestätigen über mehrere Wege, um Fehl-Failover zu vermeiden – 3-15 Sek
3. Decision: Failover entscheiden, Quorum prüfen, Standby auswählen – 1-5 Sek
4. Fencing: primären Knoten isolieren (STONITH), damit er später keine Konflikte verursacht – 5-30 Sek
5. Resource Migration: Standby übernimmt: VIP wandert, Filesystem mounten, DB-Promote, Services starten – 5 Sek - 5 Min
6. Application Recovery: Caches aufbauen, Connections re-etablieren, ggf. Crash-Recovery – 5 Sek - 2 Min
7. Verification: Smoke-Tests gegen neuen Knoten, ist der Service erreichbar? – 2-30 Sek
8. Notification: Team alarmieren, damit ausgefallener Knoten untersucht wird – sofort

Gesamt-Failover-Zeit: typisch 30 Sek bis 5 Min.

Automatisches Failover sinnvoll wenn:

• Niedriger RTO gefordert (Sekunden bis wenige Minuten)
• Fehler-Erkennung ist zuverlässig (eindeutig Ja/Nein)
• System ist zustandslos oder hat robuste Replikation
• Webserver-Cluster, Load Balancer, Container-Orchestrierung

Manuelles Failover sinnvoll wenn:

• Komplexe Situationen, die menschliche Beurteilung brauchen
• Datenkonsistenz wichtiger als Verfügbarkeit
• Geo-Failover zwischen Rechenzentren
• Bei Datenbank-Korruption (automatisches Failover würde Korruption replizieren)

Best Practice: Hybrid-Modell – einfache Ausfälle automatisch, komplexe Situationen mit Admin-Bestätigung. Mehr in L7.

Lösung

DRP vs. BCP:

• DRP (Disaster Recovery Plan): fokussiert auf die IT-Wiederherstellung. Wie kriegen wir Server, Daten, Anwendungen wieder online? Technisch, detailliert.
• BCP (Business Continuity Plan): fokussiert auf den gesamten Geschäftsbetrieb. Wie hält die Firma im Notfall funktionsfähig (Personal, Standorte, Lieferanten, Kommunikation)? Umfassender, übergeordnet.
• Der DRP ist ein Teil des BCP. BCP enthält DRP plus viele nicht-IT-Aspekte.

DR-Site-Typen:

• Cold Site: leerer Raum mit Strom, Klima, Netzwerk – aber keine Hardware. Bei Disaster muss erst Hardware geliefert und installiert werden. RTO: Tage. Kosten: niedrig. Für unkritische Systeme.
• Warm Site: Hardware installiert, aber nicht aktiv. Daten werden regelmäßig (täglich/stündlich) repliziert. Bei Disaster aktivieren + ggf. Daten nachladen. RTO: Stunden. Kosten: mittel.
• Hot Site: komplette identische Infrastruktur, kontinuierliche Replikation, sofort übernahmebereit. Oft Active-Active mit echtem Live-Traffic. RTO: Minuten bis Sekunden. RPO: ~0. Kosten: hoch.

Business Impact Analyse (BIA): das Herzstück jedes BCP. Sie beantwortet die Frage „Welche Geschäftsprozesse sind wie kritisch und was kostet uns ihr Ausfall?". Schritte:

1. Geschäftsprozesse identifizieren
2. Kritikalität bewerten (1-5 oder mission-critical/business-critical/important/nice-to-have)
3. Ausfallkosten ermitteln (€/Stunde, €/Tag)
4. Abhängigkeiten kartieren (IT-Systeme, Lieferanten, Personal)
5. MTPD, RTO, RPO festlegen
6. Mindest-Service-Level definieren
7. Prozesse priorisieren
8. BIA-Bericht erstellen

Mehr in L8 und L9.

Lösung

Anforderungen: 99,99% SLA = max. 52 Min Downtime/Jahr, RTO 30 Min, RPO 5 Min. Das erfordert einen redundanten Aufbau auf allen Ebenen.

1. Stromversorgung:

• Zwei redundante Netzteile pro Server (A-Feed / B-Feed an verschiedene Stromkreise)
• Zwei Online-USVs (VFI) pro Stromkreis, N+1-Konfiguration
• Notstrom-Aggregat (Diesel) mit monatlichem Test, 24h Tankreserve

2. Netzwerk:

• Zwei unabhängige Internet-Provider mit BGP-Failover
• HA-Firewall-Cluster (Active-Passive mit Keepalived/VRRP)
• Redundante Switches, Server mit 2 NICs (LACP zu verschiedenen Switches)

3. Server & Load Balancing:

• Mindestens 3 Web-Server im Active-Active-Cluster (N+1)
• HA-Load-Balancer-Pärchen (z.B. nginx oder HAProxy mit Keepalived) auf VIP
• Layer-7 Routing für URL-basierte Verteilung
• Server in verschiedenen Racks mit unterschiedlichen Stromkreisen

4. Datenbank (RPO 5 Min):

• PostgreSQL mit Streaming Replication (synchron oder semi-sync) → RPO < 1 Sek
• Mindestens ein synchroner Standby + ein asynchroner für Reads
• Patroni für automatisches Failover-Management
• Connection Pooling über PgBouncer (Apps können einfach reconnecten)

5. Backup-Strategie nach 3-2-1-1-0:

• Kopie 1: produktive Systeme
• Kopie 2: Backup-Appliance lokal (Veeam o.ä.), tägliche Vollsicherung + inkrementelle alle 4h
• Kopie 3: Off-Site-Backup zu Cloud (z.B. AWS S3 mit Object Lock für Immutability)
• Binary Logs / WAL für PITR alle 5 Minuten ins Backup → erfüllt RPO 5 Min
• Restore-Tests monatlich, dokumentiert

6. DR-Site (RTO 30 Min):

• Warm Site mit pre-installiertem System, kontinuierliche DB-Replikation
• DNS-Failover via Route 53 mit Health Checks, TTL 60 Sek
• Failover-Runbook dokumentiert, automatisierte Skripte für schnelle Aktivierung
• Standort mindestens 50 km entfernt vom Haupt-RZ

7. Monitoring & Failover:

• Prometheus + Grafana für Metriken, Alertmanager für Alarme
• Synthetic Monitoring von externer Quelle (User-Sicht)
• Automatisches Failover für Standard-Fälle (Server-Crash → andere übernehmen)
• Manuelles Failover für komplexe Fälle (DB-Korruption, RZ-Wechsel)

8. Tests:

• Täglich: automatischer Backup-Existence-Check
• Wöchentlich: Backup-Integrity-Check
• Monatlich: Restore einer DB auf Test-System, USV-Lasttest
• Quartalsweise: Failover-Test im Haupt-RZ, DR-Site-Aktivierung
• Jährlich: Full-Scale DR-Drill mit dokumentiertem Postmortem

9. Dokumentation & Personal:

• DRP und BCP dokumentiert, jährlich aktualisiert
• Runbooks für alle Failover-Szenarien
• Cross-Training: mindestens 2 Personen pro kritischer Aufgabe
• On-Call-Rotation mit klarer Eskalations-Matrix
• Kontaktverzeichnis (Krisenstab + Vertretungen) zentral abgelegt, auch offline verfügbar

Verfügbarkeits-Analyse: Mit allen redundanten Komponenten (je 99,9%) sollte das Setup eine berechnete Gesamt-Verfügbarkeit von > 99,99% erreichen. Wichtig: echte Unabhängigkeit der redundanten Komponenten (verschiedene Racks, Stromkreise, Provider).

Diese Strategie erfüllt RTO 30 Min (Warm Site + automatisches Failover für Standard-Fälle) und RPO 5 Min (synchrone DB-Replikation + WAL-Archiving). Kosten: deutlich höher als Einzel-Server-Setup, aber wirtschaftlich begründbar bei einem geschäftskritischen Webshop. Mehr in L8 und K58.