Failover Strategien richtig testen: Chaos Engineering für Linux-Cluster

1. Warum ungetesteter Failover keine echte Absicherung ist

Failover testen ist der Schritt, der in vielen Infrastruktur-Projekten übersprungen wird, sobald keepalived, Pacemaker oder HAProxy einmal erfolgreich konfiguriert wurden. Der Trugschluss dabei: Eine Konfiguration, die in der Theorie korrekt aussieht und im Idealfall funktioniert, sagt nichts darüber aus, wie das System unter realistischen Fehlerbedingungen reagiert, etwa bei einem halb funktionierenden Netzwerk, einer hängenden statt abgestürzten Anwendung oder einem Knoten, der nur intermittierend erreichbar ist.

Der Unterschied zwischen einem sauberen Prozessabsturz und einem realen Produktionsausfall ist erheblich. Ein kill -9 auf einen Prozess erzeugt ein eindeutiges Signal, das jeder Health-Check sofort erkennt. Ein Netzwerk-Switch mit Paketverlust, eine Festplatte, die nur noch mit stark erhöhter Latenz antwortet, oder eine Datenbank, die Anfragen annimmt aber nie beantwortet, erzeugen dagegen mehrdeutige Symptome, die viele Health-Checks gar nicht abdecken. Wer Failover nur mit dem einfachen Fall testet, testet nicht den Fall, der in der Praxis am häufigsten zu langen Ausfallzeiten führt.

Systematisches Failover testen bedeutet, kontrollierte Ausfallsimulationen so nah wie möglich an realistischen Fehlermodi durchzuführen, Ergebnisse zu messen und daraus konkrete Verbesserungen an Health-Checks, Timeout-Werten und Constraints abzuleiten. Die folgenden Abschnitte zeigen, wie ein solcher Testprozess von der ersten Kennzahl bis zum wiederkehrenden Game Day aufgebaut wird.

2. RTO und RPO als messbare Zielgrößen

Bevor überhaupt ein Test stattfindet, müssen zwei Zielgrößen definiert sein: Recovery Time Objective, kurz RTO, beschreibt die maximal akzeptierte Zeit bis zur Wiederherstellung des Dienstes nach einem Ausfall. Recovery Point Objective, kurz RPO, beschreibt den maximal akzeptierten Datenverlust, gemessen in Zeit zwischen dem letzten gesicherten Zustand und dem Ausfall. Ohne diese beiden Zahlen ist ein Failover-Test bedeutungslos, weil es keinen Maßstab gibt, an dem ein gemessenes Ergebnis bewertet werden kann.

Ein typisches Beispiel: Ein keepalived-Setup mit einem advert_int von einer Sekunde und drei nötigen fehlgeschlagenen Checks erreicht rechnerisch eine RTO von etwa vier bis sechs Sekunden. Ob dieser Wert für die Anwendung akzeptabel ist, hängt vom Geschäftskontext ab, nicht von der technischen Möglichkeit. Ein Datenbank-Cluster mit synchroner DRBD-Replikation erreicht theoretisch eine RPO von null, aber nur, wenn der Test auch tatsächlich bestätigt, dass kein einziger bestätigter Schreibvorgang beim Failover verloren geht.

3. Chaos-Engineering-Prinzipien für Linux-Cluster

Chaos Engineering überträgt eine einfache Idee auf Infrastruktur: Statt zu hoffen, dass ein System robust ist, wird es absichtlich und kontrolliert gestört, um Schwachstellen zu finden, bevor ein echter Ausfall sie aufdeckt. Die vier Grundprinzipien lauten: einen messbaren stabilen Zustand definieren, eine Hypothese über das Verhalten unter Störung aufstellen, reale Fehlerereignisse simulieren und den Explosionsradius (Blast Radius) des Experiments begrenzen.

Für Linux-HA-Cluster bedeutet das konkret: Bevor ein Failover-Test läuft, wird der aktuelle stabile Zustand über Monitoring-Metriken dokumentiert, etwa Antwortzeiten, Fehlerraten und aktive Verbindungen. Die Hypothese lautet üblicherweise, dass ein Ausfall des primären Knotens innerhalb der definierten RTO zu einem funktionierenden Backup-Knoten führt, ohne messbaren Datenverlust über die RPO hinaus. Der begrenzte Explosionsradius bedeutet in der Praxis, zunächst in einer Staging-Umgebung zu testen, bevor kontrollierte Tests in Produktion mit begrenztem Traffic-Anteil erfolgen.

4. Konkrete Ausfallszenarien systematisch durchspielen

Ein vollständiger Testplan für Failover deckt mehrere unterschiedliche Ausfallmodi ab, nicht nur den einfachsten Fall eines abgestürzten Prozesses. Die folgende Liste zeigt Szenarien, die in aufsteigender Reihenfolge der Realitätsnähe getestet werden sollten, wobei jedes einzelne Szenario einen unterschiedlichen Teil der Failover-Kette prüft.

Ein sauberer Prozessstopp mit systemctl stop prüft, ob Health-Checks und Notify-Skripte grundsätzlich funktionieren. Ein harter Prozessabbruch mit kill -9 prüft, ob auch ohne Cleanup-Möglichkeit des Prozesses zuverlässig reagiert wird. Ein simulierter Netzwerkausfall zwischen den Knoten prüft Split-Brain-Schutzmechanismen wie Fencing und zweite Kommunikationspfade. Eine künstlich erhöhte Latenz statt eines Totalausfalls prüft, ob Health-Check-Timeouts sinnvoll kalibriert sind, oder ob ein nur langsamer, aber funktionierender Knoten fälschlich als ausgefallen markiert wird.

# Scenario 1: clean process stop (baseline test)
sudo systemctl stop haproxy

# Scenario 2: hard kill without cleanup opportunity
sudo pkill -9 -f keepalived

# Scenario 3: simulate full network partition between nodes
sudo iptables -A INPUT -s 10.0.1.12 -j DROP
sudo iptables -A OUTPUT -d 10.0.1.12 -j DROP
# ... observe failover behavior, then restore:
sudo iptables -D INPUT -s 10.0.1.12 -j DROP
sudo iptables -D OUTPUT -d 10.0.1.12 -j DROP

# Scenario 4: artificial latency instead of a full outage (requires tc/netem)
sudo tc qdisc add dev eth0 root netem delay 800ms
# ... observe whether health checks misclassify a slow-but-alive node
sudo tc qdisc del dev eth0 root netem

5. Werkzeuge für kontrollierte Ausfallsimulation

Neben einfachen Bordmitteln wie iptables und tc netem gibt es dedizierte Chaos-Engineering-Werkzeuge, die realistischere und wiederholbare Fehlerinjektion ermöglichen. Das netem-Modul im Linux-Kernel simuliert nicht nur Latenz, sondern auch Paketverlust, Duplizierung und Reihenfolgevertauschung, alles Bedingungen, die reale Netzwerkprobleme deutlich besser abbilden als ein einfacher Verbindungsabbruch.

Für komplexere, wiederholbare Testszenarien mit automatisierter Auswertung eignen sich Werkzeuge wie Chaos Mesh oder Litmus, die ursprünglich für Kubernetes entstanden sind, sich aber auch auf klassische Linux-Cluster übertragen lassen, indem Fehlerinjektion und Beobachtung skriptbasiert kombiniert werden. Wichtig ist bei allen Werkzeugen, Tests zunächst in einer Staging-Umgebung zu etablieren, bevor sie mit begrenztem Explosionsradius in Produktion wiederholt werden.

6. Messung während des Tests: Was wirklich zählt

Ein Failover-Test ohne Messung ist nur eine Beobachtung, kein belastbarer Nachweis. Während jedes Tests sollten mindestens vier Werte kontinuierlich erfasst werden: die tatsächliche Zeit vom Ausfallbeginn bis zur Wiederherstellung des Dienstes, die Anzahl fehlgeschlagener Client-Anfragen während des Übergangs, ob Datenverlust im Vergleich zum letzten bestätigten Schreibvorgang aufgetreten ist, und ob nach dem Failover alle Ressourcen tatsächlich im erwarteten Zustand laufen, nicht nur teilweise.

Ein einfaches, aber wirksames Muster ist ein kontinuierlicher synthetischer Client, der während des gesamten Tests Anfragen an den Dienst sendet und jede erfolgreiche sowie fehlgeschlagene Antwort mit Zeitstempel protokolliert. Aus diesem Log lässt sich die tatsächliche Downtime exakt berechnen, statt sich auf geschätzte Werte aus Logs der Cluster-Software allein zu verlassen.

#!/usr/bin/env bash
# synthetic-client.sh — continuous probe during a failover test
set -euo pipefail

TARGET="http://192.168.10.100/healthz"
LOG="/tmp/failover-test-$(date +%s).log"

while true; do
  start=$(date +%s.%N)
  if curl -sf -o /dev/null -m 2 "$TARGET"; then
    status="OK"
  else
    status="FAIL"
  fi
  end=$(date +%s.%N)
  elapsed=$(echo "$end - $start" | bc)
  echo "$(date -Iseconds) status=$status latency=${elapsed}s" >> "$LOG"
  sleep 0.5
done

7. Game Days: Failover-Tests als wiederkehrender Prozess

Ein einmaliger Failover-Test beim initialen Setup beweist nur, dass die Konfiguration zu diesem Zeitpunkt funktionierte, nicht dass sie es nach der nächsten Software-Aktualisierung, Netzwerkänderung oder Konfigurationsanpassung noch tut. Game Days sind geplante, wiederkehrende Termine, an denen ein Team gemeinsam kontrollierte Ausfallszenarien in einer produktionsnahen Umgebung durchspielt, dokumentiert und die Ergebnisse mit dem vorherigen Test vergleicht.

Ein guter Rhythmus für die meisten Infrastrukturen ist ein Game Day pro Quartal, ergänzt um einen zusätzlichen Test nach jeder größeren Änderung an der Cluster-Konfiguration oder der zugrundeliegenden Cluster-Software-Version. Die Ergebnisse jedes Game Days werden dokumentiert, inklusive gemessener RTO, aufgetretener Fehlerraten und aller identifizierten Schwachstellen, sodass eine langfristige Verbesserungshistorie entsteht, statt jedes Mal bei null anzufangen.

Ein einfaches Runner-Skript, das mehrere Szenarien nacheinander ausführt und die Ergebnisse in einer gemeinsamen Zusammenfassung ablegt, erleichtert die Durchführung eines Game Days erheblich, weil das Team sich auf die Beobachtung statt auf die manuelle Ausführung jedes Einzelschritts konzentrieren kann.

#!/usr/bin/env bash
# game-day-runner.sh — orchestrates multiple failover scenarios in sequence
set -euo pipefail

REPORT="/tmp/game-day-$(date +%Y%m%d).md"
echo "# Game Day Report $(date -Iseconds)" > "$REPORT"

run_scenario() {
  local name="$1"
  local action="$2"
  local restore="$3"

  echo "## Scenario: $name" >> "$REPORT"
  start=$(date +%s)
  eval "$action"
  sleep 30   # observation window before restoring
  eval "$restore"
  end=$(date +%s)
  echo "- Wall clock duration: $((end - start))s" >> "$REPORT"
  echo "- Manual RTO/RPO notes: _fill in after reviewing synthetic-client log_" >> "$REPORT"
}

run_scenario "clean-stop-haproxy" \
  "sudo systemctl stop haproxy" \
  "sudo systemctl start haproxy"

run_scenario "network-partition-node2" \
  "sudo iptables -A INPUT -s 10.0.1.12 -j DROP" \
  "sudo iptables -D INPUT -s 10.0.1.12 -j DROP"

echo "Report written to $REPORT"

8. Typische Fallstricke bei Failover-Tests

Der häufigste Fehler ist, ausschließlich den einfachsten Ausfallmodus zu testen, einen sauberen Prozessstopp, und daraus fälschlich zu schließen, das gesamte Failover-System sei robust. Reale Ausfälle sind selten so eindeutig, und genau die mehrdeutigen Fälle wie Netzwerkpartitionierung oder hängende Prozesse sind es, die in der Praxis die längsten Ausfallzeiten verursachen.

Ein zweiter verbreiteter Fehler ist, Tests nur in einer isolierten Staging-Umgebung durchzuführen, die sich in Netzwerktopologie, Hardware oder Last erheblich von der Produktionsumgebung unterscheidet. Ergebnisse aus einer stark abweichenden Umgebung übertragen sich nicht zuverlässig auf das Produktionsverhalten. Ein dritter Fallstrick ist, Tests nur einmal beim initialen Setup durchzuführen und danach nie zu wiederholen, obwohl sich Konfiguration, Softwareversionen und Lastprofile im Lauf der Zeit ändern.

9. Testreife im Vergleich: von Ad-hoc bis Game Day

Organisationen unterscheiden sich erheblich darin, wie systematisch Failover getestet wird. Die folgende Tabelle ordnet unterschiedliche Reifegrade ein und zeigt, welcher Aufwand mit welchem Vertrauensniveau in die tatsächliche Ausfallsicherheit korrespondiert.

Der Sprung von keinem Test zu einem Ad-hoc-Test kostet wenig Aufwand, bringt aber bereits einen deutlichen Vertrauenszuwachs, weil zumindest der grundlegende Mechanismus einmal beobachtet wurde. Der größere Sprung liegt jedoch zwischen einem regelmäßigen Testplan und echten Game Days mit Chaos-Engineering-Prinzipien, weil erst dort realistische, mehrdeutige Fehlermodi systematisch abgedeckt werden, statt sich weiterhin auf den einfachsten Fall zu beschränken. Teams, die Failover ernsthaft betreiben wollen, sollten diesen Reifegrad als mittelfristiges Ziel behandeln, nicht als optionales Extra für später.

Ein oft unterschätzter Nebeneffekt regelmäßiger Failover-Tests ist der Wissensaufbau im Team selbst. Wer nur einmal bei der initialen Einrichtung mit der Cluster-Konfiguration in Berührung kam, tut sich im echten Ernstfall schwerer, schnell und richtig zu reagieren, als ein Team, das die Abläufe aus wiederholten Game Days bereits kennt. Diese Routine ist selbst ein Teil der tatsächlichen Ausfallsicherheit, unabhängig von der reinen Technik.

10. Zusammenfassung

Failover testen ist der Unterschied zwischen einer theoretischen Annahme über Ausfallsicherheit und einem tatsächlichen Nachweis. Ohne klar definierte RTO- und RPO-Zielwerte ist ein Test bedeutungslos, weil kein Maßstab existiert, an dem das gemessene Ergebnis bewertet werden kann. Chaos-Engineering-Prinzipien mit begrenztem Explosionsradius helfen, realistische Fehlermodi wie Netzwerkpartitionierung oder erhöhte Latenz kontrolliert zu simulieren, statt sich auf den einfachsten Fall eines sauberen Prozessabsturzes zu beschränken.

Kontinuierliche Messung während des Tests, etwa über einen synthetischen Client mit Zeitstempel-Protokoll, liefert belastbare Zahlen statt geschätzter Werte. Der größte Hebel liegt jedoch in der Wiederholung: Ein einmaliger Test beim initialen Setup beweist nur den damaligen Zustand. Game Days als wiederkehrender, dokumentierter Prozess stellen sicher, dass Failover auch nach der nächsten Konfigurationsänderung noch zuverlässig funktioniert.

11. FAQ: Failover Strategien richtig testen