Redundanzdiagramme: Failure Domains und Single Points of Failure markieren

Redundanzdiagramme sind das fehlende Bindeglied zwischen „Wir haben alles redundant“ und der harten Realität im Betrieb: Ein einziges übersehenes Bauteil, eine gemeinsame Abhängigkeit oder ein falsch verstandener Failover-Mechanismus reicht aus, um aus vermeintlicher Hochverfügbarkeit einen Single Point of Failure zu machen. In Rechenzentrum, Campus und WAN/Cloud sind Redundanzkonzepte heute komplex: HA-Cluster, Dual-Provider, LACP/MLAG, diverse Routingpfade, getrennte Strompfade, zentrale DNS/NTP/Identity-Dienste, SASE/Proxy-Kontrollpunkte und immer mehr Overlays. Wer diese Redundanz nur in Konfigurationen oder Tickets „im Kopf“ trägt, verliert bei Incidents Zeit, trifft riskante Entscheidungen und kann gegenüber Stakeholdern kaum belegen, warum ein Ausfall passieren konnte. Ein gutes Redundanzdiagramm macht deshalb zwei Dinge sichtbar: Failure Domains (gemeinsame Ausfallbereiche) und Single Points of Failure (SPOFs). Es zeigt nicht nur, dass es zwei Links gibt, sondern ob diese Links wirklich unabhängig sind, welche Komponenten gemeinsam genutzt werden und wie Failover technisch und organisatorisch funktioniert. Dieser Artikel erklärt, wie Sie Redundanzdiagramme professionell erstellen, welche Markierungen sich bewähren, wie Sie Failure Domains korrekt abgrenzen und wie Sie die Diagramme so pflegen, dass sie als Living Documentation im Betrieb echten Nutzen bringen.

Warum Redundanzdiagramme mehr sind als „zwei Kästchen und zwei Linien“

In vielen Netzwerkteams bestehen „Redundanzdiagramme“ aus einer optischen Doppelung: zwei Switches, zwei Firewalls, zwei Links. Das ist ein Anfang, aber keine Aussage über Ausfallsicherheit. Entscheidend ist, ob die Doppelung echte Unabhängigkeit erzeugt oder nur eine Illusion. Typische Beispiele:

• Zwei Uplinks, aber beide laufen durch dasselbe Patchpanel oder dieselbe Glasfasertrasse.
• Zwei Provider, aber beide enden am gleichen Demarc oder sind im gleichen PoP geschaltet.
• HA-Firewalls, aber beide hängen an demselben Management-, Logging- oder Lizenz-Backend.
• Dual-Homing via MLAG/vPC, aber Peer-Link ist Single Point oder die Keepalive-Strecke fehlt.
• Cloud-Redundanz, aber ein zentraler Identity Provider oder DNS-Resolver ist nicht redundant.

Ein Redundanzdiagramm muss deshalb nicht nur Topologie zeigen, sondern Abhängigkeiten und gemeinsame Ausfallursachen. Es ist ein Diagnose- und Planungswerkzeug, kein Marketingbild.

Begriffe, die in Redundanzdiagrammen klar sein müssen

Damit Redundanzdiagramme teamweit funktionieren, sollten Sie grundlegende Begriffe konsistent verwenden. Die wichtigsten sind:

• Single Point of Failure (SPOF): Eine Komponente oder Abhängigkeit, deren Ausfall den Service unterbricht.
• Failure Domain: Ein Bereich, in dem ein einzelnes Ereignis mehrere Komponenten gleichzeitig beeinflussen kann (z. B. Stromkreis, Rack, PoP, Region, Control Plane).
• Redundanzgrad: N+1, N+N, 2N (je nach Kontext), inklusive Kapazitätsannahmen.
• Failover: Mechanismus und Trigger, die den Wechsel auf eine alternative Ressource ermöglichen.
• Degradation: Service läuft weiter, aber mit eingeschränkter Leistung (z. B. weniger Bandbreite, höhere Latenz).

Gerade im SRE-Kontext ist es hilfreich, Verfügbarkeit und Fehlerbudgets als Denkrahmen zu nutzen, um Redundanz pragmatisch zu priorisieren. Eine gute Einführung zu SLOs und Error Budgets bietet Google SRE: Service Level Objectives.

Die Leitfrage: Was fällt gemeinsam aus?

Der Kern jedes Redundanzdiagramms ist eine einzige Leitfrage: „Welche Komponenten teilen sich eine gemeinsame Failure Domain?“ Sobald Sie diese Frage beantworten können, finden Sie SPOFs fast automatisch. In der Praxis bedeutet das: Nicht nur Geräte und Links zeichnen, sondern gemeinsame Abhängigkeiten markieren.

• Gemeinsame Stromversorgung (PDU, USV, Einspeisung)
• Gemeinsame Trasse/ODF/Patchpanel
• Gemeinsames Routing/Control Plane (RR, Controller, Management Plattform)
• Gemeinsame Dienste (DNS, NTP, IdP, PKI/OCSP)
• Gemeinsame Provider-Infrastruktur (PoP, last mile, Carrier-Core)

Redundanzdiagramm-Typen: Welche Sicht Sie wirklich brauchen

„Ein Diagramm für alles“ wird unlesbar. Redundanz ist kontextabhängig, daher funktionieren Layered Views auch hier besonders gut. In der Praxis haben sich vier Diagrammtypen bewährt:

• Physical Redundancy View: Racks, Strompfade, Trassen, Demarcs, Cross-Connects (L1-nah).
• Logical Path View: Pfade und Failover-Logik (L3/Overlay-nah), ohne physische Details.
• Control Plane View: Controller, Route Reflectors, Management- und Policy-Abhängigkeiten.
• Service Dependency View: Service Map/DFD-ähnlich: DNS, LB, Firewall, DB, externe Abhängigkeiten.

Ein gutes Redundanzdiagrammset verlinkt diese Sichten miteinander, statt sie zu vermischen.

Markierungen, die Redundanzdiagramme sofort lesbar machen

Redundanzdiagramme leben von visueller Semantik. Sie brauchen klare Markierungen für „Backup“, „shared“, „critical“ und „SPOF“. Bewährt hat sich ein minimalistischer Standard, der auch ohne Farben funktioniert (wichtig für Ausdrucke und Barrierefreiheit).

Empfohlene visuelle Konventionen

• Primärpfad: durchgezogene Linie.
• Backup-/Sekundärpfad: gestrichelte Linie.
• Geteilte Abhängigkeit: dicke Klammer/Bracket oder „Shared“-Badge am Element.
• Failure Domain: Container/Fläche mit Label (z. B. „Rack R12“, „PDU-A“, „PoP Frankfurt“).
• SPOF: klarer Marker, z. B. „SPOF“-Badge oder Warnsymbol am Element.
• Degradation: Hinweis am Pfad („50% BW“, „No HA“) statt nur „up/down“ zu denken.

Failure Domains in Rechenzentren: Strom, Rack, Trasse, Cluster

Im Rechenzentrum entstehen viele SPOFs nicht auf Routingebene, sondern in der physischen und betrieblichen Kette. Ein Redundanzdiagramm sollte daher mindestens diese Failure Domains abbilden:

• Strompfade: A/B-PDU, USV, Einspeisung, Generator, unterschiedliche Phasen.
• Rack: gemeinsame Temperatur-/Kühlzonen, gemeinsame ToR-Switches, gemeinsame Kabelwege.
• Trassen/Backbone: ODF/Fiber Trays, physische Wege (auch über Brandabschnitte hinweg).
• Cluster-Domänen: HA-Paare, vPC/MLAG-Paare, Storage-Fabrics (A/B), Control-Plane-Services.

Typische DC-SPOFs, die Diagramme sichtbar machen sollten

• Ein einzelner ODF-Port oder ein einzelnes Fiber-Tray, durch das „alle“ Uplinks laufen
• Ein gemeinsamer Management-Switch für beide HA-Knoten
• Ein zentraler Logcollector oder License Server, dessen Ausfall Policies/HA beeinträchtigt
• Ein einzelner Out-of-Band-Zugang (OOB), der bei Incident nicht erreichbar ist

Campus und Standorte: Failure Domains jenseits von Switch-Redundanz

Im Campus wird Redundanz oft als „zwei Distribution-Switches“ verstanden. Doch die kritischen Failure Domains liegen häufig im Gebäude-Backbone, in Etagenverteilern und in der Stromversorgung. Außerdem ist die „Last Mile“ (Gebäudeanbindung, Tiefbau, Gebäudeverteiler) oft der echte Engpass.

• MDF/IDF: wenn beide Uplinks durch denselben Verteiler laufen, ist das eine gemeinsame Failure Domain.
• Glasfaserstrecken: zwei Fasern sind nicht redundant, wenn sie im gleichen Rohrbündel liegen.
• Strom/PoE: ein PoE-Switch als SPOF für APs oder VoIP kann einen Standort „quasi offline“ machen.
• Gebäudeeintritt: Provider-Übergabepunkt und Demarc sind oft Single-Point, wenn nicht bewusst doppelt geplant.

WAN und Internet: Provider-Redundanz richtig darstellen

WAN-Redundanzdiagramme werden oft zu optimistisch gezeichnet, weil Providerdetails fehlen. Ein belastbares Diagramm zeigt daher nicht nur „Carrier A“ und „Carrier B“, sondern auch die relevante Failure Domain: unterschiedliche Demarcs, unterschiedliche PoPs, unterschiedliche letzte Meile, unterschiedliche Trassenführung. Zusätzlich sollte die Failover-Logik (BGP/SD-WAN, SLA-Policies) sichtbar sein.

Was in WAN-Redundanzdiagrammen stehen sollte

• Circuit-IDs und Demarc-Positionen als Referenz (für Betrieb und Eskalation)
• PoP/Region des Providers (wenn bekannt) als Failure Domain
• Exit-Strategie: local breakout vs. backhaul, primär/backup
• Failover-Trigger: BGP Attribute, SLA (Loss/Jitter/Latency), statische Präferenzen
• Degradation: was passiert bei Verlust eines Links (z. B. „nur 1 Gbit/s statt 2 Gbit/s“)

Overlay-Redundanz: SD-WAN, EVPN/VXLAN, SASE als eigene Failure Domains

Overlays bringen neue Failure Domains, die in klassischen L3-Diagrammen unsichtbar bleiben: Control-Plane-Controller, Route Reflectors, Orchestratoren, Policy Engines, Zertifikats- und Rekey-Prozesse. Redundanzdiagramme sollten Overlays deshalb als eigene Ebene darstellen, insbesondere die Trennung zwischen Underlay und Overlay.

Typische Overlay-SPOFs

• Controller Reachability: Edges/Tunnel laufen, aber Orchestrator/Control-Plane fällt aus (oder umgekehrt).
• MTU/MSS: Underlay reduziert MTU, Overlay fragmentiert und degradiert „still“.
• Zertifikate/Keys: ablaufende Zertifikate oder fehlgeschlagene Rekeys als globale Failure Domain.
• Policy Drift: unterschiedliche Policies pro Region/Edge führen zu asymmetrischem Verhalten.

Redundanz vs. Hochverfügbarkeit: Aktiv/Aktiv, Aktiv/Passiv und die Betriebsrealität

Ein Redundanzdiagramm sollte nicht nur „doppelt vorhanden“ zeigen, sondern auch den Betriebsmodus: Aktiv/Aktiv (Lastverteilung), Aktiv/Passiv (Standby), N+1 (Reserven) und wie Umschaltung tatsächlich passiert. Das ist wichtig, weil sich Risiken und Degradation unterscheiden.

Darstellungsmuster für Betriebsmodi

• Aktiv/Aktiv: beide Pfade als primär kennzeichnen, Lastverteilung als Hinweis („ECMP“, „LB active/active“).
• Aktiv/Passiv: primärer Pfad solid, sekundärer Pfad dashed, Failover-Trigger labeln.
• N+1: Reservekomponente als „Spare“-Element markieren, inklusive Kapazitätsannahme.
• Stateful Komponenten: Firewalls/LBs als stateful markieren (Risiko von Session Drops beim Failover).

Single Points of Failure systematisch finden

Der größte Wert eines Redundanzdiagramms ist nicht das Bild, sondern der Prozess, der es erzeugt. Nutzen Sie eine systematische SPOF-Checkliste entlang der Kette: Physical, Network, Control Plane, Services, People/Process.

SPOF-Checkliste für Netzwerkteams

• Physical: ein Rack, eine PDU, ein Patchpanel, eine Trasse, ein Demarc
• Network: ein Default-Exit, ein RR, ein einziger Transit, eine Redistribution-Stelle ohne Guardrails
• Control Plane: ein Orchestrator, ein Managementsystem, ein License/PKI-Backend
• Services: ein DNS-Resolver, ein NTP-Server, ein IdP/AAA-Endpunkt, ein Logging-Collector
• Process: nur eine Person mit Zugang, kein Break-Glass, kein getesteter Rollback

Wenn Sie dafür Controls und Betriebsdisziplin systematisch verankern möchten, sind die CIS Controls als praxisorientierter Katalog hilfreich, weil sie u. a. Asset-Management, sichere Konfiguration, Monitoring und Incident Response in überprüfbare Themenblöcke fassen.

Evidence-by-Design: Redundanzdiagramme audit- und incidentfähig machen

Redundanzdiagramme sind besonders wertvoll, wenn sie mit Nachweisen verknüpft werden: Failover-Tests, Maintenance-Protokolle, Monitoring-SLIs, Incident-Timelines. Das Diagramm bleibt schlank, aber verweist auf Evidence. So entsteht Audit-Readiness ohne hektische Nacharbeit.

• Failover-Test-Link: wann wurde das letzte Mal Failover eines Links/Clusters getestet?
• Monitoring-Links: SLIs für Pfade (Loss/Jitter/Latency), Cluster-Status, Controller-Health
• Runbooks: „Provider down“, „BGP neighbor flaps“, „Firewall failover“, „DNS degraded“
• Change-Referenzen: große Änderungen an Redundanzstrukturen sind nachvollziehbar verlinkt

Diagramm-Standards: Damit Redundanzdiagramme teamweit konsistent sind

Ein Redundanzdiagramm kann nur dann „schnell gelesen“ werden, wenn Symbolik und Metadaten standardisiert sind. Ein minimaler Standard reicht meist aus, wenn er konsequent angewendet wird.

• Legende: Linienarten (primär/backup/control), Symbole (SPOF, shared, failure domain)
• Metadaten: Owner, Scope (Site/Region/Umgebung), Last updated, Version
• Benennungen: Site-Code, Device-Namen, Circuit-IDs als Referenz (nicht als lange Tabellen)
• Granularität: pro Diagramm eine Leitfrage, keine Mischformen aus L1/L2/L3/Service-Map

Living Documentation: Redundanzdiagramme aktuell halten

Redundanzdiagramme veralten schnell, weil Redundanz oft „nebenbei“ verändert wird: ein neuer Cross-Connect, ein neuer Provider, eine neue Firewall-Policy-Chain, ein neues SASE-Onramp. Der wirksamste Hebel ist eine Definition of Done: Jede Änderung, die Pfade, Boundaries oder Control-Plane-Abhängigkeiten betrifft, erfordert ein Diagrammupdate.

Definition of Done für redundanzrelevante Changes

• Failure Domains aktualisiert (neue Trasse, neues Rack, neuer PoP, neue Control-Plane)
• SPOF-Markierungen geprüft und angepasst
• Failover-Mechanismus dokumentiert (Trigger, erwartete Degradation)
• Monitoring/SLIs verlinkt oder angepasst
• Runbook/Operational Notes aktualisiert (Eskalation, Providerkontakte, Rollback)

Für prozessorientierte Einbettung in Change- und Knowledge-Management kann ITIL Best Practices als Rahmen helfen, damit Updates nicht optional bleiben.

Typische Anti-Pattern in Redundanzdiagrammen

• Redundanz ohne Failure Domains: „zwei Links“ ohne Trasse/Demarc/PoP; Lösung: Domain-Container und Shared-Marker.
• Nur Geräte, keine Dienste: DNS/NTP/IdP fehlen; Lösung: kritische Plattformdienste als Abhängigkeiten einzeichnen.
• Failover als Mythos: nicht getestet; Lösung: Evidence-Links und Testtermine an Pfaden verlinken.
• Unklare Degradation: alles wirkt „gleich kritisch“; Lösung: Degradation-Labels und Kapazitätsannahmen dokumentieren.
• Keine Metadaten: niemand vertraut dem Stand; Lösung: Owner + Last updated verpflichtend.
• Alles in einem Diagramm: unlesbar; Lösung: Physical/Logical/Control/Service Views trennen.

Checkliste: Redundanzdiagramme mit Failure Domains und SPOFs

• Das Diagramm beantwortet die Leitfrage: „Was fällt gemeinsam aus (Failure Domains) und wo sind SPOFs?“
• Failure Domains sind als Container dargestellt (Rack, PDU, Trasse, PoP, Region, Control Plane)
• SPOFs sind klar markiert und priorisiert (kritisch vs. tolerierbar mit Degradation)
• Primär- und Backup-Pfade sind visuell unterscheidbar (Linienarten) und mit Failover-Triggern annotiert
• Provider-/WAN-Redundanz zeigt echte Unabhängigkeit (Demarc/PoP/Last Mile) statt nur „Carrier A/B“
• Overlay- und Control-Plane-Abhängigkeiten sind sichtbar (Controller, RRs, Zertifikate/Keys, Management)
• Kritische Plattformdienste sind als Abhängigkeiten enthalten (DNS, NTP, IdP/AAA, Logging/Monitoring)
• Evidence-by-Design ist verankert (Links zu Failover-Tests, Monitoring-SLIs, Runbooks, Change-Records)
• Diagrammstandard ist definiert (Legende, Symbole, Metadaten, Naming) und teamweit konsistent
• Living Documentation ist gesichert (Definition of Done bei redundanzrelevanten Changes, Review-Zyklen)

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.