Clustering: Active-Active vs. Active-Passive

In den letzten Lektionen hast du gesehen, wie wichtig SPoF-Eliminierung (L3) und Load Balancing (L5) sind. Damit kommt natürlich die Frage: wie organisierst du mehrere Server, die zusammen einen Dienst bereitstellen? Die Antwort: Cluster. Mehrere Server werden zu einer logischen Einheit zusammengefasst, die nach außen wie ein einzelnes System wirkt.

Cluster gibt's in zwei Hauptvarianten: Active-Active (alle Server arbeiten gleichzeitig) und Active-Passive (einer arbeitet, einer wartet). Beide haben Berechtigung, beide haben Trade-offs. Diese Lektion erklärt die Unterschiede, die wichtigen Cluster-Konzepte (Quorum, Split Brain, Fencing) und zeigt typische Cluster-Software.

1) Was ist ein Cluster?

Ein Cluster ist ein Verbund mehrerer Server, die gemeinsam einen Dienst bereitstellen und sich gegenseitig überwachen. Wenn ein Server ausfällt, übernehmen die anderen. Aus Sicht des Clients ist das Cluster eine einzige logische Entität – meist über eine Virtual IP (VIP) oder einen DNS-Namen erreichbar.

Cluster werden für zwei Hauptzwecke eingesetzt:

• Hochverfügbarkeit (HA): Ausfall eines Servers wird automatisch kompensiert. Endnutzer merken nichts.
• Skalierbarkeit: Last wird auf mehrere Server verteilt, mehr Kapazität durch mehr Knoten.

Ob beides oder nur eines erreicht wird, hängt vom Cluster-Typ ab. Hier kommen Active-Active und Active-Passive ins Spiel.

2) Active-Active Cluster

Bei einem Active-Active Cluster arbeiten alle Knoten gleichzeitig. Jeder verarbeitet Requests, jeder trägt zur Gesamt-Leistung bei. Wenn einer ausfällt, übernehmen die anderen seine Arbeit zusätzlich:

3) Active-Passive Cluster

Bei Active-Passive arbeitet nur ein Knoten aktiv, der andere ist im Standby-Modus. Der Standby ist bereit, aber bedient keine Requests. Erst bei Ausfall des aktiven Knotens übernimmt der Standby:

4) Direkter Vergleich

Welche Variante ist besser? Es kommt drauf an. Hier die Trade-offs:

5) Hybrid: N+M-Cluster

In der Praxis gibt's oft Mischformen. Zwei wichtige Beispiele:

• N+1 Active-Passive: N aktive Knoten, 1 Standby für alle. Wenn einer der N ausfällt, übernimmt der Standby seine Rolle. Effizient bei vielen Knoten.
• N×M Active-Active mit Übergewicht: alle Knoten aktiv, aber jeder ist nur zu 70% ausgelastet. Wenn einer ausfällt, übernehmen die anderen seine Last, ohne sich zu überlasten (70% + 30%/restliche = unter 100%).

Wichtig ist immer: planen für den Worst Case. Wenn Cluster A aktiv-aktiv mit 3 Knoten à 80% Last läuft und einer ausfällt, müssen die anderen je 120% schultern. Das geht nicht. Überdimensionierung ist Pflicht.

6) Cluster-Grundkonzepte: Heartbeat

Wie wissen die Knoten in einem Cluster voneinander, dass sie alive sind? Über den Heartbeat – ein periodischer „Lebenszeichen"-Mechanismus:

7) Quorum verstehen

Quorum ist eines der wichtigsten Konzepte verteilter Systeme. Schauen wir uns Szenarien an:

8) Shared Storage vs. Replicated Storage

Eine wichtige architektonische Entscheidung in Clustern: wo liegen die Daten?

• Shared Storage (Shared-Nothing): zentrales Storage-System (SAN, NAS, Cluster-Filesystem wie GFS2, OCFS2), auf das alle Knoten zugreifen. Vorteil: einfache Konsistenz. Nachteil: Storage selbst ist ein SPoF, muss eigene HA haben.
• Replicated Storage: jeder Knoten hat lokale Storage, Daten werden zwischen Knoten repliziert (DRBD, ZFS-Replikation, Datenbank-Replikation). Vorteil: kein zentraler SPoF. Nachteil: komplexer, Konsistenz-Herausforderungen.
• Distributed Storage: Daten werden über alle Knoten verteilt und repliziert (Ceph, GlusterFS, MinIO). Beste Skalierung und HA, aber komplexeste Architektur.

Klassische Active-Passive-Cluster nutzen oft Shared Storage (z.B. SAN mit Multipath). Moderne Active-Active-Cluster nutzen oft Distributed Storage – bessere Skalierung, aber höhere Komplexität.

9) Cluster-Typen nach Anwendungsfall

Cluster gibt's für viele unterschiedliche Anwendungsfälle. Hier die wichtigsten Klassen:

10) Cluster-Software

Die wichtigsten Tools und Plattformen für Cluster-Management:

11) Cluster-Aufbau: Pacemaker-Beispiel

So sieht ein einfaches Linux-Cluster mit Pacemaker aus. Zwei Knoten, ein Apache-Webserver soll als HA-Service laufen:

Was hier passiert: Pacemaker verwaltet zwei Ressourcen – eine Virtual IP (10.0.0.100) und einen Apache-Webserver. Beide laufen auf einem Knoten. Wenn dieser ausfällt, wandert sowohl die VIP als auch der Apache automatisch auf den anderen. Endnutzer erreichen die App weiterhin unter der VIP.

12) Cluster-Setup im Schnellüberblick

Typische Schritte beim Aufbau eines HA-Clusters:

1. Hardware bereitstellen: identische Server, redundante Netzwerke (Heartbeat-Netz separat), ggf. Shared Storage
2. Cluster-Software installieren: Pacemaker, Keepalived, Microsoft FCI etc.
3. Heartbeat-Netzwerk konfigurieren: mindestens eine, besser zwei separate Verbindungen
4. Quorum konfigurieren: bei 2 Knoten Quorum-Disk oder Witness-Knoten
5. Fencing/STONITH einrichten: über IPMI, iLO, Power Distribution Unit
6. Ressourcen definieren: Apps, VIPs, Filesysteme, die im Cluster verwaltet werden
7. Constraints festlegen: welche Ressourcen müssen zusammen / dürfen nicht zusammen / Reihenfolge
8. Testen, testen, testen: Failover manuell auslösen, Netzwerk trennen, Reboots provozieren
9. Monitoring: in Prometheus/Nagios integrieren, Alerts bei Failover
10. Dokumentation: Runbooks für Failover, Recovery, Wartung

13) Häufige Cluster-Probleme

Cluster sind komplex, und es gibt klassische Fallstricke:

• Split Brain durch fehlendes Quorum: 2-Knoten-Cluster ohne Witness → bei Netzwerk-Partition beide Knoten aktiv → Datenkonflikte
• Heartbeat über produktives Netzwerk: bei Netzlast werden Heartbeats verzögert → fälschliche Failover
• Kein Fencing konfiguriert: ausgefallener Knoten taucht wieder auf, übernimmt fälschlich Ressourcen → Konflikte
• Asymmetrische Hardware: Standby ist schwächer als Active → kann nach Failover die Last nicht tragen
• SPoF im Cluster selbst: gemeinsames Storage ohne Multipath, gleicher Stromkreis, gleicher Switch
• Failover nie getestet: theoretisch konfiguriert, im Ernstfall funktioniert's nicht (siehe K58 L8)
• Konfiguration-Drift: Knoten haben über die Zeit unterschiedliche Konfigurationen entwickelt → unklares Verhalten
• App nicht cluster-aware: Anwendung speichert lokale Zustände, die beim Failover verloren gehen
• Lange Failover-Zeiten: Cluster funktioniert, aber Failover dauert 5 Minuten → SLA verletzt
• Mangelnde Dokumentation: nur der Original-Admin versteht das Setup → bei dessen Abwesenheit Probleme

Zusammenfassung

Cluster = Verbund mehrerer Server, die gemeinsam einen Dienst bereitstellen. Erreichbar über Virtual IP (VIP). Zwei Hauptvarianten: Active-Active (alle arbeiten, Lastverteilung, beste Skalierung, komplexer) und Active-Passive (einer aktiv, einer wartet, einfacher, „verschwendet" Hardware). Hybride Formen: N+1, N+M. Zentrale Konzepte: Heartbeat (Lebenszeichen zwischen Knoten), Quorum (Mehrheits-Prinzip, ungerade Knoten-Anzahl), Split Brain (Horror-Szenario bei Netzwerk-Partition), Fencing/STONITH (ausgefallener Knoten wird abgeschaltet). Storage-Modelle: Shared (SAN), Replicated (DRBD), Distributed (Ceph). Cluster-Typen: HA-Failover, Load-Balancing, DB-Replikation, Multi-Master-DB, Hypervisor (vSphere), Container (Kubernetes), HPC, Storage. Software: Pacemaker+Corosync, Keepalived, Microsoft FCI, VMware HA, Galera, Patroni, DRBD. Häufige Probleme: Split Brain, Heartbeat über prod Netz, kein Fencing, asymmetrische Hardware, Failover nie getestet, Config-Drift.