HA Cluster Design: Active/Active vs. Active/Passive – echte Auswirkungen

HA Cluster Design ist eine der wichtigsten Architekturentscheidungen in Netzwerken und Security-Infrastrukturen, weil sie direkt über Verfügbarkeit, Fehlertoleranz, Performance und Betriebsrisiko entscheidet. Ob Firewall-Cluster, Load Balancer, VPN-Gateways, Router, Proxys oder zentrale Management-Plattformen: Sobald ein System „kritisch“ ist, stellt sich die Frage, wie es ausfallsicher betrieben wird. Dabei wird häufig sehr vereinfacht über Active/Active vs. Active/Passive gesprochen – als wäre Active/Active automatisch besser, weil „beide Geräte arbeiten“, oder Active/Passive automatisch sicherer, weil „nur ein Gerät aktiv ist“. In der Praxis sind die Auswirkungen komplexer: Failover-Verhalten, Session-State, Routing-Asymmetrie, NAT-Tabellen, Synchronisation, Split-Brain-Risiken, Upgrades, Kapazitätsplanung und Monitoring unterscheiden sich je Modell erheblich. Wer HA Cluster Design ohne diese Details plant, bekommt im Ernstfall Überraschungen: kurze Ausfälle, abreißende Sessions, One-Way-Audio bei VoIP, VPN-Rekeys, flappende BGP-Nachbarschaften oder Performance-Einbrüche unter Last. Dieser Artikel erklärt Active/Active vs. Active/Passive aus Engineering-Sicht und zeigt, welche echten Auswirkungen die Modelle auf Datenpfad, Control Plane und Betrieb haben – inklusive praxistauglicher Designregeln für stabile, testbare und auditierbare Hochverfügbarkeit.

Grundbegriffe: Verfügbarkeit, Redundanz und Failover-Ziele

Bevor man ein HA-Modell auswählt, müssen die Ziele klar sein. Hochverfügbarkeit ist nicht nur „zwei Geräte“, sondern eine Kombination aus Architektur, Betriebsprozessen und messbaren SLOs.

• Availability (A): prozentuale Verfügbarkeit eines Dienstes über einen Zeitraum (z. B. monatlich).
• MTBF/MTTR: mittlere Zeit zwischen Ausfällen und mittlere Zeit zur Wiederherstellung.
• RTO: maximal tolerierbare Wiederherstellungszeit nach einem Ausfall.
• RPO: maximal tolerierbarer Datenverlust (bei Netzwerkgeräten oft weniger relevant, bei Management-Systemen wichtig).
• Failover Time: Zeit bis Traffic wieder stabil fließt (inkl. Konvergenz, ARP/ND, Routing, Session-Recovery).

Ein HA-Cluster ist nur dann „gut“, wenn er die Zielwerte in realen Störfällen erreicht – nicht nur im Datenblatt.

Active/Passive: Was es wirklich bedeutet

Bei Active/Passive ist ein Node aktiv (führt Datenpfad aus), der andere ist Standby. Im Fehlerfall übernimmt der Passive. Viele Plattformen bieten zusätzlich Varianten wie „Active/Passive mit Preemption“, „Non-Preemptive“ oder „Warm Standby“. Entscheidend ist, wie State und Identitäten gehandhabt werden.

• Traffic-Pfad: Normalbetrieb über einen aktiven Node.
• Failover: Passive Node übernimmt Interfaces/virtuelle IPs und ggf. Sessions.
• State-Sync: Je nach Produkt werden Session Tables, NAT States, VPN SAs, User-ID Mappings synchronisiert.
• Wartung: Upgrade/Restart oft einfacher, weil man aktiv/passiv tauschen kann.

Active/Passive wird oft als „stabiler“ wahrgenommen, weil nur ein Node den Datenpfad bedient. Das stimmt jedoch nur, wenn die Übernahme gut designed ist: Failover muss schnell, deterministisch und ohne Split-Brain funktionieren.

Active/Active: Was es wirklich bedeutet

Active/Active heißt nicht automatisch „jede Session läuft auf beiden Nodes“. Meist bedeutet es, dass beide Nodes gleichzeitig Traffic verarbeiten, aber aufgeteilt nach Sessions, Flows, VLANs, VRFs oder virtuellen Kontexten. Die Verteilung kann statisch oder dynamisch erfolgen.

• Traffic-Verteilung: via ECMP, LACP, Flow-hashing, Policy-based Steering oder Load-Balancing-Mechanismen.
• State-Handling: entweder vollständige State-Sync (ideal, aber teuer) oder teilweiser State pro Flow.
• Failover: bei Node-Ausfall übernimmt der verbleibende Node den Traffic-Anteil – oft mit kurzfristigen Session-Losses.
• Kapazität: höhere Ausnutzung im Normalbetrieb, aber sorgfältige Überbuchungs- und Headroom-Planung nötig.

Active/Active ist besonders attraktiv, wenn horizontale Skalierung im Datenpfad gewünscht ist. Gleichzeitig ist es empfindlicher gegenüber Asymmetrien und State-Inkonsistenzen.

Die echte Hauptfrage: Stateful oder stateless Failover?

Der entscheidende Unterschied in HA Cluster Design ist oft nicht Active/Active vs. Active/Passive, sondern ob ein Failover stateful ist. „Stateful“ bedeutet, dass Sessions nach einem Failover weiterlaufen, ohne dass Clients neu verbinden müssen. „Stateless“ bedeutet: Sessions reißen ab, Clients müssen neu aufbauen.

• Stateful relevant für: Long-lived Sessions, VPN, VoIP, API Streams, große File Transfers, TLS Sessions, NAT-intensive Workloads.
• Stateless oft tolerierbar bei: kurzlebigen Web-Requests mit Retries, idempotenten APIs, gutem Client-Side Retry.

Je mehr State synchronisiert werden muss (NAT, IPS, TLS Inspection, App-ID), desto höher werden CPU/Memory/Interconnect-Anforderungen – und desto mehr steigt auch die Komplexität der Fehlerbilder.

Failover-Mechaniken: VRRP, VIP, MAC Move und Routing-Konvergenz

Die meisten Cluster arbeiten mit virtuellen IPs (VIPs) oder virtuellen MACs, damit Clients und Upstream/Downstream-Geräte nicht umadressiert werden müssen. Failover bedeutet dann: VIP und MAC „wandern“. Das klingt simpel, erzeugt aber reale Effekte.

• ARP/ND Refresh: Nach Failover müssen Nachbarn neue Zuordnungen lernen (ARP für IPv4, Neighbor Discovery für IPv6).
• Gratuitous ARP/NA: Viele Systeme senden nach Übernahme aktive Updates; ohne das kann Traffic Minuten „ins Leere“ laufen.
• Routing-Konvergenz: Bei dynamischem Routing (OSPF/BGP) muss die Nachbarschaft stabil bleiben oder schnell neu entstehen.
• Session Pinning: In Active/Active ist die Frage, ob Rückwege garantiert über denselben Node laufen.

In realen Umgebungen ist die Failover-Zeit oft weniger vom Cluster selbst abhängig als von ARP/ND-Timern, Routing-Timern und dem Verhalten der angeschlossenen Switches.

Asymmetry: Der häufigste HA-Killer in Active/Active Designs

Asymmetrische Pfade sind in modernen Netzen normal (ECMP, mehrere Uplinks, SD-WAN). Für stateful Security-Geräte kann Asymmetrie aber fatal sein: Wenn Hinweg über Node A und Rückweg über Node B läuft, sieht jeder Node nur „halbe Sessions“.

• Symmetrie erzwingen: Hashing konsistent machen (5-Tuple), Policy-based Routing, Session Steering, „stickiness“ in Load Balancern.
• State Sharing: Wenn Symmetrie nicht garantiert werden kann, braucht man echte State-Synchronisation oder zentralen Session-Broker.
• Fehlerbilder: sporadische Drops, Retransmits, „funktioniert manchmal“, VPN-Rekey-Probleme, One-Way-Audio.

Active/Passive ist hier oft einfacher, weil der aktive Node beide Richtungen sieht – sofern das Netz nicht gleichzeitig alternative Rückwege hat.

Performance-Realität: Durchsatz, CPS und Session Tables unter HA

Herstellerwerte zu Throughput oder CPS (Connections per Second) gelten oft nur unter idealen Bedingungen. HA verändert diese Realität:

• Active/Passive: Sie müssen die Last so planen, dass ein einzelner Node die gesamte Produktionslast tragen kann (N+1). Das heißt: Im Normalbetrieb brauchen Sie Headroom.
• Active/Active: Normalbetrieb nutzt beide Nodes, aber im Fehlerfall muss der verbleibende Node den kompletten Traffic übernehmen. Wenn Sie im Normalbetrieb bereits nahe 50% pro Node fahren, kann Failover sofort in Überlast kippen.
• State Sync Overhead: Je mehr Features aktiv sind (IPS, TLS Inspection, User-ID), desto mehr kostet State-Sync und desto geringer ist die nutzbare Datenpfadleistung.
• Session Table Pressure: Beim Failover entstehen oft neue Sessions (Reconnects), was CPS-Spikes erzeugt.

Ein praktischer Grundsatz: Planen Sie nicht „für Durchschnitt“, sondern für Failover-Moment + Burst. Das ist der kritische Peak.

Wartung und Upgrades: Wer gewinnt wirklich?

Viele wählen Active/Passive, weil Wartung „einfacher“ wirkt. Das stimmt oft, aber nicht immer. Entscheidend ist, wie Ihre Plattform Upgrades, Commit-Mechaniken und State-Migration unterstützt.

• Active/Passive Vorteil: Controlled failover, Upgrade des Standby, dann Switchover, dann Upgrade des zweiten Nodes.
• Active/Active Vorteil: Traffic kann schrittweise umverteilt werden (drain), besonders bei Load-Balancer-ähnlichen Systemen.
• Risiko: Versionsmischbetrieb kann problematisch sein; manche Systeme erlauben kein „mixed version cluster“.
• Praxis: Wartungsfenster lassen sich mit „progressive rollouts“ auch bei HA reduzieren, wenn Drain/Canary möglich ist.

Split-Brain: Das Worst-Case-Szenario und wie man es verhindert

Split-Brain bedeutet: Beide Nodes glauben, sie seien aktiv. Das kann VIP-Konflikte, Routing-Chaos und Datenpfad-Kollisionen verursachen. Ursache ist meist ein Ausfall des Heartbeats/Interconnects bei gleichzeitigem Weiterbetrieb beider Geräte.

• Mehrere Heartbeat-Pfade: Dedizierter HA-Link plus sekundärer Pfad (z. B. Management-Netz).
• Quorum/Arbitration: Ein dritter „Arbiter“ oder Quorum-Mechanismus verhindert, dass beide aktiv werden.
• Fail-safe Policy: Bei Verlust des Quorums muss klar definiert sein, ob ein Node in „shutdown“ oder „standalone“ geht.
• Monitoring: Alarme auf HA-Link-Errors, flapping states, MAC move storms.

Split-Brain ist selten, aber wenn er auftritt, ist er meist teurer als ein normaler Ausfall. Deshalb muss Split-Brain-Prevention in jedem HA Cluster Design explizit geprüft werden.

State-Objekte, die wirklich zählen: NAT, VPN, TLS, User Context

Viele HA-Konzepte scheitern daran, dass Teams nur „Sessions“ betrachten, aber nicht, welche States tatsächlich synchronisiert werden müssen. Besonders kritisch:

• NAT States: Bei Failover ohne NAT-State können Rückpakete nicht gematcht werden; Sessions reißen ab.
• VPN SAs: IPsec/IKE Security Associations sind stateful; Rekey kann nach Failover schmerzen, wenn SAs nicht migrieren.
• TLS Sessions: Bei TLS Inspection (Inbound oder Outbound) ist der State deutlich komplexer, Failover kann zu Handshake-Stürmen führen.
• User/Device Context: Identity-aware Policies brauchen konsistente User-ID/Device-ID Zuordnung.

Je mehr dieser States Sie „im Datenpfad“ nutzen, desto wichtiger wird die Frage, ob das HA-Modell diese States zuverlässig repliziert.

Design-Entscheidungshilfe: Wann Active/Passive sinnvoller ist

• Stateful Security im Vordergrund: VPN, NAT-heavy, TLS Inspection, IPS mit Session-Correlation.
• Symmetrie schwer garantierbar: mehrere Uplinks/ECMP ohne saubere Stickiness.
• Einfaches Wartungsmodell benötigt: klare Switchover-Prozeduren, predictable behavior.
• Auditierbarkeit und Risiko-Minimierung: weniger komplexe Fehlerbilder, leichteres Runbooking.

Active/Passive ist nicht „altmodisch“, sondern häufig die richtige Wahl, wenn Stabilität und deterministisches Verhalten wichtiger sind als maximale Auslastung.

Design-Entscheidungshilfe: Wann Active/Active sinnvoller ist

• Skalierung im Datenpfad: Last ist hoch, und beide Nodes sollen dauerhaft tragen.
• Traffic ist gut steerbar: saubere Hashing-Mechaniken, Session Stickiness, definierte Traffic-Segmente.
• Workloads sind resilient: kurzlebige Sessions, Retries, idempotente APIs, verteilte Services.
• Edge-/Load-Balancer-Szenarien: L7-Load-Balancing, Reverse Proxy, WAF-Frontends mit sauberem Session Handling.

Active/Active kann Change Windows reduzieren, weil man Traffic auf einen Node „drainen“ und Änderungen schrittweise ausrollen kann – vorausgesetzt, die Plattform unterstützt sauberes Drain/Drain-Back.

Testen statt raten: HA muss im Betrieb verifiziert werden

Das wichtigste Element eines HA Cluster Designs ist der Test. Ohne regelmäßige Failover-Drills ist „HA“ eine Hoffnung, kein Nachweis. Ein gutes Testprogramm umfasst:

• Planned Switchover: kontrollierter Wechsel aktiv ↔ standby, Beobachtung von Failover Time und Session Impact.
• Unplanned Failure: Node-Crash, HA-Link-Ausfall, Interface-Down, Power Loss (im Lab oder kontrolliert).
• Load Tests: Failover unter Peak-Last, um CPS-Spikes und Session-Table Pressure zu sehen.
• Routing Tests: BGP/OSPF Nachbarschaften, ECMP-Verhalten, ARP/ND Konvergenz.

Für strukturiertes Incident- und Recovery-Testing kann ein Blick in NIST SP 800-61 helfen, um Drills und Runbooks in einen wiederholbaren Prozess zu bringen.

Monitoring: Signale, die HA-Probleme früh anzeigen

HA-Design wird im Betrieb sichtbar. Gute Telemetrie reduziert Überraschungen, weil sie Drift und Vorboten erkennt.

• HA State Changes: flapping, häufige Role Changes, verlorene Heartbeats.
• Interconnect Health: Drops, CRC Errors, Latency, Link Flaps.
• Session Metrics: Sessions, CPS, timeouts, failover-induced reconnect spikes.
• Routing Signals: BGP resets, OSPF neighbor flaps, RIB/FIB churn.
• ARP/ND Anomalien: MAC move storms, ND cache issues.

Für Logging- und Telemetriegrundlagen (Normalisierung, Retention, Datenqualität) ist NIST SP 800-92 eine solide Referenz.

Praktische Entscheidungscheckliste für HA Cluster Design

• 1) Workload-Charakter: Sind Sessions kurzlebig und retryfähig oder lang und stateful?
• 2) Symmetrie: Können Sie Hin- und Rückweg zuverlässig über denselben Node führen?
• 3) State-Sync Bedarf: NAT, VPN, TLS, User Context – was muss synchron sein?
• 4) Failover-Ziel: Welche Failover Time ist akzeptabel, und was passiert mit Sessions?
• 5) Kapazität: Kann ein Node die Gesamtlast tragen (N+1)? Gibt es Headroom für Failover-Spikes?
• 6) Split-Brain Prevention: Quorum/Arbiter, Heartbeat-Redundanz, Fail-safe Verhalten.
• 7) Upgrade-Strategie: Mixed-Version möglich? Drain möglich? Wartungsfenster-Anforderungen.
• 8) Observability: Welche Metriken/Logs sind verfügbar, und werden sie aktiv genutzt?
• 9) Tests: Gibt es regelmäßige Drills mit dokumentierten Ergebnissen?
• 10) Runbooks: Switchover, Failover, Split-Brain, Recovery – klar und geübt.

Outbound-Links für Vertiefung

• NIST SP 800-61 Rev. 2 (Incident Handling, Drills und Recovery-Prozesse)
• NIST SP 800-92 (Log Management für HA-Telemetrie und Nachweisführung)
• RFC 5798 (VRRP – Grundlagen virtueller Router und Failover-Mechaniken)
• RFC 4271 (BGP – relevant für HA an Edges und Routing-Konvergenz)

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.