Failover: automatisch und manuell

In L6 hast du gelernt was Cluster sind. Beim Active-Passive-Modell und auch zwischen Standorten muss aber etwas Konkretes passieren, wenn der aktive Knoten ausfällt: ein Failover. Das ist der eigentliche „magische" Moment, in dem die Standby-Komponente übernimmt – und genau hier scheitern viele Setups in der Praxis.

Diese Lektion erklärt was beim Failover passiert: wie Ausfälle erkannt werden, wie die Übernahme abläuft, wie automatisch und manuell gesteuerte Failover sich unterscheiden, und was beim Failback (Rückfall auf den ursprünglichen Knoten) zu beachten ist. Ein gut funktionierender Failover ist der Unterschied zwischen „HA-Cluster auf dem Papier" und „echte Hochverfügbarkeit".

1) Was ist Failover?

Failover bezeichnet die automatische oder manuelle Übernahme der Aufgaben eines ausgefallenen Systems durch ein anderes. Das Ziel: minimale Unterbrechung der Service-Bereitstellung für die Endnutzer.

Failover findet auf vielen Ebenen statt – jede Lektion vorher hat eine Form davon angeschnitten:

• Stromversorgung: USV/Aggregat übernimmt bei Netzausfall (L4)
• Festplatte: RAID übernimmt bei Defekt (K57)
• Server: Cluster-Manager schaltet auf Standby um (L6)
• Load Balancer: schaltet bei Ausfall einzelner Backends (L5)
• Rechenzentrum: DR-Site übernimmt komplette Workloads

Egal auf welcher Ebene – die Mechanik ist immer ähnlich: Erkennen → Entscheiden → Umschalten → Verifizieren.

2) Die Phasen eines Failovers

Jeder Failover-Prozess durchläuft typische Phasen. Hier am Beispiel eines DB-Server-Failovers:

3) Automatisches vs. manuelles Failover

Die zentrale Designentscheidung: soll der Failover automatisch oder erst nach Mensch-Entscheidung passieren? Beide Modelle haben Berechtigung:

4) Wann automatisch, wann manuell?

Faustregeln für die Entscheidung:

Automatisches Failover sinnvoll wenn:

• Niedriger RTO gefordert (Sekunden bis wenige Minuten)
• System ist gut verstanden und getestet
• Fehler-Erkennung ist zuverlässig (klares Ja/Nein)
• Failover-Mechanismus ist idempotent und sicher
• Service ist zustandslos oder zustandsbehaftet mit guter Replikation

Manuelles Failover sinnvoll wenn:

• Hoher RTO akzeptabel (Stunden)
• Komplexe Fehler-Situationen möglich
• Datenkonsistenz wichtiger als Verfügbarkeit
• Geo-Failover zwischen Rechenzentren (große Entscheidung)
• Service ist zustandsbehaftet ohne automatische Replikation

Beispiele: Webserver-Cluster → automatischer Failover (einfach, schnell, zustandslos). Datenbank-Cluster zwischen Rechenzentren → oft manueller Failover (Datenkonsistenz, Bandbreiten-Kosten, Komplexität).

5) Detection-Methoden

Wie wird ein Ausfall überhaupt erkannt? Es gibt mehrere Mechanismen, die oft kombiniert werden:

6) Failover-Auslöser

Was kann einen Failover triggern?

• Hardware-Ausfall: Server stürzt komplett ab
• Software-Crash: Anwendung beendet sich unerwartet
• Hängender Service: keine Reaktion auf Health-Checks
• Netzwerk-Ausfall: Knoten nicht mehr erreichbar
• Resource-Erschöpfung: CPU 100%, RAM voll, Disk voll
• Datenbank-Replikations-Lag: Replikation hängt zu weit zurück
• Geplante Wartung: manuell ausgelöster Failover für Updates
• Lasttest: bewusste DR-Übung

Wichtig: nicht alle dieser Auslöser sollten automatisch Failover triggern. Bei Resource-Erschöpfung etwa wandert das Problem oft mit zum Standby – besser ist Skalierung oder Last-Reduktion.

7) Failback – die Rückkehr

Wenn der primäre Knoten repariert ist, kommt die Frage: wandert die Last zurück? Das ist das Failback. Zwei Strategien:

Wichtig: Failback ist nicht trivial. Während der Standby aktiv war, sind dort Daten verändert worden. Bevor primary wieder Active werden kann, müssen diese Änderungen erst zurück-repliziert werden. Sonst gibt's Datenverlust.

8) DNS-basiertes Failover

Eine spezielle Form: DNS-Failover. Beim Ausfall wird die DNS-Auflösung geändert, sodass User auf einen anderen Server geleitet werden:

9) VIP-Failover (Floating IP)

Für lokale HA-Cluster gibt's eine elegantere Methode als DNS: die Virtual IP (VIP). Eine IP-Adresse, die zwischen Knoten wandern kann. Realisiert über das VRRP-Protokoll oder ähnliche Mechanismen:

Funktionsweise: Master und Backup tauschen via VRRP Heartbeats aus. Master „besitzt" die VIP, antwortet auf ARP-Anfragen für sie. Fällt der Master aus, übernimmt Backup die VIP – User merken nichts. Failover in 3-5 Sekunden.

10) Failover-Zeiten verschiedener Technologien

Wie schnell ist Failover in der Praxis? Hier eine Übersicht:

11) Datenbank-Failover im Detail

Datenbank-Failover ist besonders kritisch und komplex. Schauen wir uns das genauer an, am Beispiel PostgreSQL Streaming Replication:

• Primary: nimmt alle Schreib-Vorgänge entgegen, sendet WAL-Logs zum Standby
• Standby: Read-Only-Replica, spielt WAL-Logs nach, ist sekunden-aktuell
• Replication Lag: typisch <1 Sek, kann bei Last steigen

Failover-Ablauf:

1. Primary fällt aus, Standby erkennt das (Heartbeat-Timeout)
2. Standby wartet auf letzte WAL-Logs (kurze Verzögerung wegen Replikations-Lag)
3. Standby wird via pg_promote() oder pg_ctl promote zum neuen Primary befördert
4. Applications müssen wissen, dass sie nun zu einer anderen Adresse connecten
5. Häufig via VIP, Connection-Pooler (PgBouncer) oder DNS-Failover gelöst

Komplikation: Replication Lag bedeutet möglichen Datenverlust. Wenn 2 Sekunden Lag und Primary stirbt, sind die letzten 2 Sekunden Schreibvorgänge weg. Synchrone Replikation eliminiert das – ist aber langsamer im Normalbetrieb. Tools wie Patroni, repmgr oder Stolon automatisieren das.

12) Häufige Failover-Probleme

Failover sieht im Konzept einfach aus, scheitert aber oft an Details. Klassische Probleme:

• Split Brain: kein Fencing → ausgefallener Knoten taucht wieder auf, beide aktiv → Datenkonflikte
• Flapping: kurze Aussetzer triggern wiederholte Failovers, System pendelt unkontrolliert
• Stuck Resources: Failover bleibt hängen, eine Ressource lässt sich nicht freigeben
• Stale Connections: Clients halten alte Verbindungen, gehen nicht automatisch auf neuen Knoten
• App nicht failover-aware: kann nicht mit Reconnect umgehen, verliert Sessions
• Replication Lag: Daten zwischen letztem Replikations-Punkt und Disaster sind weg
• ARP-Caching: Switches behalten alte MAC-IP-Mapping, neue VIP-Position braucht Gratuitous ARP
• DNS-TTL zu hoch: bei DNS-Failover dauert's ewig bis User umschwenken
• Asymmetrische Hardware: Standby kann die Last nicht tragen
• Versteckter SPoF: Failover scheitert weil eine andere Komponente auch betroffen ist
• Fail-back-Probleme: nach Reparatur kann Original-Primary nicht zurückübernehmen
• Failover nie getestet: theoretisch konfiguriert, im Ernstfall ungeprüft

13) Failover testen

Wie bei Backups gilt auch hier: ungetesteter Failover funktioniert wahrscheinlich nicht. Regelmäßige Tests sind Pflicht:

• Geplante Failover: in Wartungsfenstern bewusst auslösen, Verhalten beobachten
• Chaos Engineering: Netflix-Stil – Komponenten zufällig ausschalten, sehen was passiert
• DR-Drills: vierteljährliche / jährliche Tests des kompletten Failovers (siehe K58 L8)
• Smoke Tests: nach jedem Failover-Test prüfen, ob alles funktioniert
• Failover-Zeit messen: mit Stoppuhr dokumentieren, ob die RTO-Vorgaben eingehalten werden

Best Practice: nach jedem realen Failover ein Postmortem – was lief gut, was nicht, was kann verbessert werden? Lessons Learned ins Runbook übernehmen.

14) Failover-Runbooks

Selbst bei automatischem Failover braucht's Runbooks – schriftliche Anleitungen für die menschliche Aktionen, die folgen. Inhalte:

• Verifizieren dass Failover erfolgreich war (Service erreichbar, Daten konsistent)
• Root-Cause-Analyse: warum ist der primary ausgefallen?
• Reparatur-Schritte für den ausgefallenen Knoten
• Failback-Prozedur, wenn primary repariert ist
• Kommunikation: wer wird informiert? Status-Pages? Kunden-Benachrichtigung?
• Dokumentation des Vorfalls für späteren Postmortem

Runbooks müssen auch ohne Original-Admin ausführbar sein. Im Ernstfall ist die zuständige Person vielleicht im Urlaub. Die Doku muss so klar sein, dass auch jemand anderes den Failover-Prozess durchführen kann.

Zusammenfassung

Failover = automatische oder manuelle Übernahme der Aufgaben eines ausgefallenen Systems durch ein anderes. Phasen: Detection → Verification → Decision → Fencing → Resource Migration → App Recovery → Verification → Notification. Typische Failover-Zeit: 30 Sekunden bis 5 Minuten. Automatisch (schnell, 24/7, Risiko von Fehl-Failovers) vs. Manuell (kontrolliert, Mensch entscheidet, langsamer). Detection-Methoden: Heartbeat, Service Health Check, Resource Monitoring, Synthetic Probing, App Self-Reporting. Kombinieren für volle Abdeckung. Auslöser: Hardware-Crash, Software-Crash, hängender Service, Netzwerk-Ausfall, Resource-Erschöpfung, Replikations-Lag, geplante Wartung. Failback: Rückkehr zum primary – meist manuell, um Doppel-Downtime zu vermeiden, mit Daten-Resync. Mechanismen: VIP/VRRP (Keepalived, sehr schnell, lokal), DNS-Failover (cross-region, TTL-abhängig), DB-Replikations-Failover (Promote Standby zu Primary). Failover-Zeiten: LB 5 Sek, VRRP 10 Sek, Cluster 30 Sek, DB-Promotion 2 Min, DNS 5 Min, Geo-DR 15+ Min. Häufige Probleme: Split Brain, Flapping, Replication Lag, ARP-Caching, App nicht failover-aware, ungetestet. Best Practice: regelmäßig testen, Runbooks pflegen, Postmortems machen.