Data Center Interconnect (DCI): Rechenzentren sicher verbinden

Data Center Interconnect (DCI) beschreibt die sichere, performante und betriebssichere Verbindung zwischen zwei oder mehr Rechenzentren. Der Bedarf entsteht häufig aus Hochverfügbarkeit, Disaster Recovery, Kapazitätserweiterung, regulatorischen Anforderungen oder der Migration in hybride Cloud-Modelle. Ein DCI ist dabei deutlich mehr als „ein schneller Link“: Es geht um definierte Latenz- und Bandbreitenziele, saubere Routing- und Segmentierungsmodelle, kontrollierte Layer-2- und Layer-3-Erweiterungen, konsistente Sicherheitskontrollen sowie Observability und Change-Prozesse, die auch in Störungssituationen funktionieren. Fehler in der DCI-Architektur wirken sich sofort großflächig aus, weil Rechenzentren zentrale Dienste tragen: Identity, DNS, Storage, Virtualisierung, Applikationsplattformen und Sicherheitskomponenten. Daher muss ein DCI-Design gleichzeitig Stabilität und Flexibilität liefern. Dieser Artikel zeigt, wie Sie Rechenzentren sicher verbinden: von grundlegenden DCI-Topologien über Technologieoptionen (Dark Fiber, MPLS/L2VPN, VXLAN/EVPN, IPsec/MACsec) bis zu typischen Designentscheidungen rund um L2-Stretch, Routing, Security, Kapazitätsplanung und Betriebsmodelle.

DCI-Anforderungen sauber definieren: Ohne Zielbild kein gutes Design

Ein DCI-Projekt scheitert selten an der Technik, sondern an unklaren Anforderungen. Bevor Sie Lösungen vergleichen, definieren Sie konkret, welche Workloads über DCI kommunizieren und welche Betriebsziele gelten. Dabei sollten Sie unbedingt zwischen „Recovery“ (asynchron, klare Umschaltprozesse) und „Active-Active“ (gleichzeitiger Betrieb, strikte Konsistenzanforderungen) unterscheiden.

• Use Cases: Disaster Recovery, Storage-Replikation, VM-/Container-Migration, Active-Active-Apps, gemeinsame Services (DNS/AD), Backup/Archive.
• Serviceziele: Verfügbarkeit (SLA/SLO), maximale Latenz, tolerierbarer Paketverlust, Jitter (bei Echtzeit selten DCI-kritisch, aber relevant für bestimmte Systeme).
• Traffic-Profile: East-West (Applikation↔DB), Storage, Backup, Management, Replikation – idealerweise getrennt in Klassen oder Zonen.
• Security und Compliance: Verschlüsselungspflicht, Mandantentrennung, Logging/Retention, Audit Trails.
• Wachstum: erwartete Bandbreitensteigerungen, neue Services, zusätzliche Rechenzentren oder Cloud-Edges.

Topologien für DCI: Von Punkt-zu-Punkt bis Multi-DC

Die Topologie bestimmt, wie resilient und erweiterbar Ihr DCI ist. In der Praxis sind drei Muster häufig: Punkt-zu-Punkt (zwei Rechenzentren), Hub-and-Spoke (zentrales DC mit Satelliten) und Mesh (mehrere DCs mit mehreren Pfaden). Je mehr Standorte, desto wichtiger werden klare Routingdomänen und konsistente Policy-Mechanismen.

• Punkt-zu-Punkt: einfache Architektur, klare Verantwortung, meist am leichtesten zu betreiben.
• Dual-Hub: zwei zentrale DCs versorgen Außenstellen; DCI wird zum Rückgrat für zentrale Dienste.
• Multi-DC/Mesh: hohe Resilienz, aber deutlich komplexer (Routing, Segmentierung, Failure Domains).
• Physische Diversität: getrennte Trassen, getrennte Provider, getrennte Übergabepunkte sind wichtiger als „zwei Ports am selben Link“.

Transportoptionen: Welche DCI-Leitung passt zu welchem Risiko?

DCI kann auf unterschiedlichen Transporten laufen. Entscheidend ist, ob Sie volle Kontrolle (Dark Fiber) oder ein gemanagtes Transportnetz (Carrier Ethernet, MPLS, Wavelength Services) bevorzugen. Die richtige Wahl hängt von Distanz, Kosten, SLA, Security-Anforderungen und interner Betriebskompetenz ab.

• Dark Fiber: maximale Kontrolle und niedrige Latenz, aber Sie betreiben Optik/DWDM und Redundanz selbst.
• Wavelength / DWDM-Service: hohe Bandbreite und geringe Latenz, Provider liefert optische Ebene; gut für skalierbare Backbone-Links.
• Carrier Ethernet / L2VPN: einfache Anbindung, klare SLAs, geeignet für L2/L3-Designs, aber Abhängigkeit vom Provider.
• MPLS (L3VPN/L2VPN): bewährt für Multi-Site, gute Trafficsteuerung; Design muss Providerrollen und Routinggrenzen sauber berücksichtigen.
• Internet-basiert: kosteneffizient, aber meist nur mit starker Verschlüsselung und guter Observability sinnvoll (z. B. IPsec mit klaren Health Checks).

Layer 2 über DCI: Wann L2-Stretch sinnvoll ist und wann nicht

Der kontroverseste DCI-Entscheidungspunkt ist die Frage nach Layer-2-Erweiterung. L2-Stretch kann bestimmte Migrationen vereinfachen (z. B. wenn IP-Adressen erhalten bleiben müssen), erhöht aber Risiko: größere Failure Domains, Broadcast-/ARP-Last, komplexere Fehlersuche und potenziell instabile Szenarien bei Split-Brain. Grundsätzlich gilt: So wenig L2 wie möglich, so viel L3 wie nötig.

• Sinnvoll: kurzfristige Migrationsphasen, klar begrenzte VLANs, definierte Latenz, gut verstandene Failure-Szenarien.
• Riskant: unkontrolliertes Ausdehnen vieler VLANs, unsaubere FHRP-Designs, fehlende Broadcast-Kontrolle.
• Alternative: IP-Renumbering, Anycast-Gateways, DNS-basiertes Switchover, Applikationsdesign auf Active-Active ausrichten.

Overlay-Ansätze: VXLAN und EVPN als modernes DCI-Muster

In modernen Rechenzentren wird DCI häufig über Overlays umgesetzt, insbesondere VXLAN für L2-over-L3 und EVPN als Control Plane. Das reduziert Abhängigkeiten von physischer L2-Erweiterung und verbessert Skalierbarkeit. Die technischen Spezifikationen sind in IETF-Dokumenten beschrieben, etwa VXLAN in RFC 7348 und EVPN in RFC 7432.

• Vorteile: skalierbare Segmentierung, klare L3-Underlay-Grenzen, bessere Kontrolle von MAC/ARP-Verteilung.
• Herausforderungen: MTU-Planung (Overlay-Overhead), Underlay-Stabilität, saubere EVPN-Policy, Troubleshooting-Tooling.
• Designhinweis: DCI sollte als Teil des Underlays (physisch) und Overlays (logisch) klar dokumentiert sein, inklusive Failure Domains.

Routing im DCI: Stabilität, Konvergenz und klare Grenzen

Unabhängig von L2/L3 müssen Routinggrenzen und Pfade eindeutig sein. Ein häufiges Problem in DCI-Projekten sind asymmetrische Pfade, die stateful Security und NAT destabilisieren. Achten Sie darauf, dass Routingentscheidungen deterministisch sind, Failover-Zeiten getestet werden und Default-Routen sowie Metriken konsistent gesetzt sind.

• Klare Routingdomänen: Underlay-Routing getrennt von Overlays, kein „Mischbetrieb“ ohne Plan.
• BGP als Standard: oft sinnvoll für DCI/EVPN, weil Policy und Skalierung gut steuerbar sind.
• Summarization: reduziert Tabellen und beschleunigt Konvergenz, sofern IP-Plan hierarchisch ist.
• Failover testen: Link-Fail, Device-Fail, Provider-Fail, Partial Outages (Peering-Probleme) müssen im Runbook stehen.

Sicherheit im DCI: Verschlüsselung, Segmentierung und Adminpfade

„Rechenzentren sicher verbinden“ bedeutet: Datenpfade schützen, Managementpfade absichern und Mandanten-/Zonenmodelle über Standorte hinweg konsistent durchsetzen. In vielen Branchen ist Verschlüsselung auf dem Transport verpflichtend oder dringend empfohlen. Typische Optionen sind MACsec auf Layer 2 und IPsec auf Layer 3, jeweils mit klarer Schlüsselverwaltung, Monitoring und Leistungsdimensionierung. Für MACsec ist die Normfamilie IEEE 802.1AE eine zentrale Referenz; IPsec ist in IETF-RFCs dokumentiert, z. B. über die RFC Editor-Sammlung.

• Verschlüsselung wählen: MACsec für L2-nahe Strecken (geringer Overhead, aber L2-Domain), IPsec für L3/Internet/Providerunabhängigkeit.
• Segmentierung über Sites: VRFs/Zonen konsistent halten, Inter-Zone-Traffic über kontrollierte Policy-Punkte führen.
• Default Deny: zwischen Zonen und insbesondere zwischen „Management“ und „Produktion“.
• Adminpfade: getrennte Managementnetze, MFA/SSO für zentrale Plattformen, Audit Trails für Changes.
• Schlüssel- und Zertifikatsmanagement: Rotation, Break-Glass, klare Verantwortlichkeiten.

Performance im DCI: Bandbreite, Latenz, MTU und QoS

Performance ist im DCI nicht nur „mehr Gbit/s“. Entscheidend sind Latenz und Stabilität der Pfade, insbesondere für synchrone Replikation, Clustermechanismen oder verteilte Datenbanken. Overlays und Verschlüsselung bringen Overhead, der MTU und CPU/ASIC-Ressourcen beeinflussen kann. Ein gutes DCI-Design definiert daher eine End-to-End-MTU und ein QoS-Modell für Replikation, Backup und Business-Traffic.

• MTU-Planung: Underlay + Overlay + Verschlüsselung berücksichtigen, Fragmentierung vermeiden, PMTUD nicht „blind“ blockieren.
• QoS-Klassen: wenige klare Klassen (Real-Time selten DCI, Business, Replication, Bulk) und Shaping am Engpass.
• Mikrobursts: DCI-Links sind anfällig für kurze Spitzen (Backups, Storage), Queue-Drops aktiv überwachen.
• N-1-Kapazität: Failover-Fall muss die p95-Last tragen, sonst kippt Performance bei Wartung oder Ausfall.

Storage- und Applikationsaspekte: DCI ist kein Ersatz für Architektur

Viele DCI-Projekte werden durch Applikations- und Storage-Anforderungen getrieben. Hier ist es wichtig, Erwartungen zu managen: Ein DCI kann physische Distanz nicht „wegoptimieren“. Synchrone Replikation verlangt in der Regel sehr niedrige Latenz und stabile Pfade; aktive Cluster über große Distanzen erhöhen die Komplexität und das Risiko von Split-Brain-Szenarien. Planen Sie daher gemeinsam mit Storage- und Applikationsteams, welche Modi sinnvoll sind.

• Sync vs. Async: synchrone Replikation ist latenzkritisch; asynchrone ist robuster, aber hat RPO-Implikationen.
• Failover-Logik: automatisches Umschalten braucht klare Quorum-/Witness-Konzepte, sonst droht Split Brain.
• Service-Erreichbarkeit: DNS, Anycast, Global Server Load Balancing oder Applikations-Health-Checks müssen Teil des Designs sein.

Observability für DCI: Sichtbarkeit entscheidet über MTTR

DCI-Störungen sind teuer, weil sie viele Systeme betreffen. Deshalb muss Observability von Anfang an eingeplant werden: Metriken (RTT/Loss, Interface-Errors, Queue-Drops), Logs (Link-Flaps, BGP/EVPN-Events, IPsec/MACsec-Status), Flow-Daten (Replikationsvolumen, Top Talker) und synthetische Checks (DNS/HTTPS zu kritischen Diensten). Für strukturierte Vorgehensweisen in Monitoring und Incident Response bietet das NIST CSRC hilfreiche Referenzen.

• Pfadmessung: Latenz/Loss/Jitter kontinuierlich zwischen DCs und zu kritischen Services messen.
• Event-Korrelation: Changes (Routing, Policy, Encryption) müssen zeitlich mit Incidents korrelierbar sein.
• Alarmhygiene: wenige, hochwertige Alarme mit Runbooks und klaren Eskalationswegen.
• Provider-Eskalation: objektive Messwerte erhöhen die Erfolgsquote bei Tickets.

Change Management und Teststrategie: DCI-Änderungen sind High Risk

Updates, Policy-Änderungen oder Routing-Tuning im DCI sollten immer als High-Risk-Changes behandelt werden. Der wichtigste Schutz ist ein sauberes Runbook mit Pre-/In-/Post-Checks und einem realistischen Rollback. Ein bewährter Rahmen für Change-Disziplin ist die ITIL-orientierte Praxis; eine Übersicht bietet ITIL.

• Pre-Checks: Redundanzstatus, BGP/EVPN-Health, IPsec/MACsec-Status, Baseline-KPIs.
• In-Checks: nach jedem Schritt: Routingtabellen, Tunnelstatus, Drops/Errors, Servicepfade.
• Post-Checks: synthetische Transaktionen, Performancevergleich (p95), Failover-Test im Wartungsfenster.
• Rollback: klar definierte Rückkehrmechanik, inklusive „Time to Rollback“.

Typische DCI-Designfehler und wie Sie sie vermeiden

• Unbegrenzter L2-Stretch: führt zu großen Failure Domains; L2 nur gezielt und befristet, wo wirklich nötig.
• Asymmetrische Pfade: destabilisieren stateful Security; Pfade deterministisch halten und testen.
• MTU ignoriert: Overlays und Encryption erzeugen „komische“ Drops; MTU/MSS end-to-end planen.
• Failover nicht getestet: Redundanz existiert nur auf dem Papier; regelmäßige Übungen sind Pflicht.
• Security nur als „IPsec an“: Management- und Policy-Governance fehlen; MFA/RBAC/Audit Trails gehören dazu.
• Observability-Lücken: ohne Queue-Drops, Flow-Daten und Pfadchecks bleibt Root Cause unklar und MTTR hoch.

Praxis-Checkliste: Rechenzentren sicher verbinden mit DCI

• Anforderungen klären: Use Cases (DR, Migration, Active-Active), Latenz-/Bandbreitenziele, Wachstum, Compliance.
• Topologie wählen: Punkt-zu-Punkt, Dual-Hub oder Multi-DC; physische Diversität sicherstellen.
• Transport entscheiden: Dark Fiber/Wavelength/Carrier Ethernet/MPLS/Internet je nach SLA, Kontrolle und Risiko.
• L2 bewusst begrenzen: L3 bevorzugen, L2-Stretch nur gezielt; VXLAN/EVPN als skalierbarer Ansatz prüfen (RFC 7348, RFC 7432).
• Security durchsetzen: Verschlüsselung (MACsec IEEE 802.1AE oder IPsec), Segmentierung/VRFs, Default Deny, sichere Adminpfade.
• Performance planen: MTU/MSS, QoS/Shaping, Mikrobursts, N-1-Kapazität für Failover und Wartung.
• Observability integrieren: Pfadmessung, Queue-Drops, Logs, Flow-Daten, synthetische Checks; Prozesse an NIST CSRC orientieren.
• Change-Disziplin: High-Risk-Changes, Runbooks, Go/No-Go, Rollback; strukturierte Praxis z. B. über ITIL.

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.