Site icon bintorosoft.com

Redundanzdiagramme: Failure Domains und Single Points of Failure markieren

Red Snapper

A complex illustration of interconnected devices representing the internet of things, highlighting digital communication and modern technology networks with various gadgets and cloud computing symbols.

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:

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:

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.

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:

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

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:

Typische DC-SPOFs, die Diagramme sichtbar machen sollten

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.

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

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

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

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

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.

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.

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

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

Checkliste: Redundanzdiagramme mit Failure Domains und SPOFs

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:

Lieferumfang:

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.

 

Exit mobile version