Wie verbindet man ACI Fabrics über mehrere Datacenter?

In den letzten Monaten hat sich die ACI Lösung als Next Generation Datacenter Network Technologie weiter am Markt etabliert und auch als stabile Technologie in produktiven Netzwerken bewiesen. Cisco investiert nun bemerkbar viel Energie in die Weiterentwicklung des Produkts. Eine wichtige Anforderung an ein Data Center Netzwerk ist meiner Meinung nach die Möglichkeit einen stabilen Betrieb unter maximaler Flexibilität, innerhalb eines Data Centers und zwischen geographisch getrennten Standorten, zu gewährleisten.

In meinem ersten Blogbeitrag zum Thema Cisco Application Centric Infrastructure hab ich bereits über die zugrundeliegende Architektur geschrieben: http://www.nts.eu/expertenblog/cisco-aci/. Nun möchte ich einen Überblick über die aktuellen Möglichkeiten von Datacenter Interconnect (DCI) Techniken für ACI zu beschaffen.

 

DCI für ACI: Viele Möglichkeiten, welche ist die Richtige?

Komplexität und Vielzahl an Möglichkeiten ist nicht immer ein Zeichen für Planlosigkeit. Bei Cisco gab es schon immer unzählbare Varianten Data Center miteinander zu verbinden. Zu diesen zahlreichen Möglichkeiten kommt es natürlich einerseits aufgrund von permanenten Neuentwicklungen in Hard- und Software. Wenn man Cisco ACI Entwicklungen mitverfolgt, bemerkt man dieses Wachstum an Möglichkeiten ebenfalls. Positiv hierbei ist die Tatsache, dass selbst die frühesten Ansätze auch heute noch je nach Anforderungen und Gegebenheiten für eine aktuelle Umsetzung tauglich sind.

  1. Single Fabric: Warum nicht eine ACI Fabric mit 2 Spines auf zwei Räume aufteilen?
    → Kurze Distanzen, z.B. ein Unternehmensgelände
  2. Stretched Fabric: 4 Spines, dafür weniger Leaf | Spine Verbindungen am Übergang
    → Kurze Distanzen, z.B. ein Unternehmensgelände bis zu wenigen Kilometern…
  3. Multi-Pod: Ein APIC Cluster, aber getrennte Control Planes, VXLAN am DCI Übergang, Control Plane Isolierung per Datacenter
    → Kurze oder mittlere Distanzen, 50 msec, maximal 800 km
  4. Multi-Fabric: Getrennte APIC Cluster, keine gemeinsame Management- / Controlplane, eher für Active / Passive Datacenter Betrieb bzw. Site lokale Services mit Failover zum zweiten Datacenter
    → Distanz spielt keine Rolle für die ACI Fabrics, Applikationen limitieren das Design
  5. Multi-Site: Getrennte APIC Cluster, gemeinsame Forwarding und Control Plane über DCI Übergang. Ein Multisite Controller für zentrales APIC Management mehrerer APIC Cluster
    → Ebenfalls kein Distanz Limit an das Netzwerk, Multi Site Controller sorgt für gemeinsames Management und Policy über Standorte hinweg, geeignet für Active / Active oder Active / Passive Datacenter

 

“Single Fabric” für zwei Datacenter?

Als mit ACI 1.0 die Reise begann, wurde lediglich eine “Single Fabric” in Leaf / Spine Topologie unterstützt. Damit kann man grundsätzlich trotzdem zwei getrennte Räumlichkeiten innerhalb eines Standorts abdecken, sofern man die dafür nötige Lichtwellenleiter Verkabelung zur Verfügung hat.

 

ACI

 

Die fix vorgegebene Leaf | Spine Topologie erfordert eine Verbindung zwischen jedem Leaf und Spine Switch. Abhängig von der benötigten Anzahl von Leaf Switches pro Räumlichkeit ergibt sich die mitunter hohe Anzahl an LWL Verbindungen. Hierbei sei angemerkt, dass die Mindestbandbreite dieser Verbindungen 40 Gbit/s entspricht. In aktuellen Designs geht man inzwischen eher Richtung 100 Gbit/s.

 

Transceiver für kurze Distanzen

Bei diesen Bandbreiten ist natürlich der Transceiver für die Übertragung zwischen Räumlichkeiten ein bemerkbarer Kostenfaktor. Ein Transceiver für 100 Gbit/s, der bis zu 2 km über Singlemode Verkabelung unterstützt (QSFP-100G-SM-SR) kostet derzeit ca. $4500 Listenpreis. Interessant ist der Vergleich zu einem 40 Gbit/s Transceiver (WSP-Q40GLR4L), der bei gleichen Kennwerten auf $6000 Listenpreis kommt.

 

Die “Stretched Fabric”

… ist eine Evolution der Single Fabric ab ACI Version 1.1 für eine Topologie über räumliche Grenzen hinweg. Der Vorteil liegt hier eindeutig an der Reduktion der notwendigen Verkabelung zwischen den Räumen. Der zweite große Unterschied ist die Notwendigkeit zwei Spine Switches pro Raum zu platzieren. Damit muss man sich im Design die zentrale Frage stellen: Investiere ich lieber in vier Spine Switches, oder reicht ein Spine pro Raum bei gleichzeitig steigender Anzahl an notwendiger Raum zu Raum Verbindungen. Dies muss in jedem Einzelfall gegenübergestellt werden. Für Installationen jenseits eines geschlossenen Unternehmens-Standorts bzw. über größere Distanzen wird eine Stretched Fabric mit jeweils zwei Spines pro Standort die bessere Wahl sein.

 

ACI

 

Grundsätzlich kann eine Stretched Fabric auch über 3 Datacenter Standorte gespannt werden, ein APIC Controller pro Standort, hier würde jedoch ein aktuellerer DCI Ansatz wie Multi-Pod oder Multi-Site die bessere Wahl sein.

Sowohl bei einer “klassischen” Single Fabric, als auch bei der Stretched Fabric kommen in der Regel drei APIC Controller, die über beide Räume aufgeteilt werden zum Einsatz.

 

Kleiner Exkurs: Anzahl der APIC Controller und Redundanz

Cisco empfiehlt derzeit generell den Einsatz von drei APIC Controllern für Installationen mit bis zu 80 Leaf Switches. Das bedeutet, der Einsatz von aktuell 7 unterstützten APIC macht in Wirklichkeit nur für höhere Skalierbarkeit Sinn. Datenstrukturen innerhalb des APIC Cluster sind in Shards organisiert. Dies ermöglicht neben der Datenredundanz auch ein Loadbalancing der Anfragen an den Cluster.

Fällt ein einzelner APIC aus, können die beiden verbliebenen noch alle APIC Funktionen zur Gänze zur Verfügung stellen und man darf auch noch Änderungen an der Fabric vornehmen. Sollen zwei Controller ausfallen, geht der APIC Cluster in einen Read Only Modus über.

 

ACI

 

Man hat volle Visibility auf das System und das Traffic Forwarding in der Fabric ist nicht beeinträchtigt (bei einer VMM Integration und vMotion in diesem Zustand allerdings eventuell schon). Fielen alle drei APIC gleichzeitig aus, ist das Traffic Forwarding ebenfalls nicht beeinträchtigt.

Der Einsatz von beispielsweise 5 APIC ändert die beschriebene Situation nicht bzw. nur teilweise (Manche Shards sind Read-Only, andere Read-Write). Im Dual- Data Center Betrieb bedeuten 3 APIC somit unter Umständen eine “Read Only” Situation, wenn das DC mit zwei beheimateten APIC komplett ausfällt. Um diese Situation zu umgehen, kann man im zweiten DataCenter einen vierten Standby APIC in Betrieb nehmen. Wenn das Data Center mit zwei APIC ausfällt, kann man den Standby Controller im verbliebenen Data Center provisionieren um den Schreibzugriff möglichst schnell wieder herstellen zu können.

 

Multi-Pod

Diese Evolution der Stretched Fabric gibt es seit ACI Version 2.0. Ein Pod ist als separates Leaf | Spine Netzwerk mit gemeinsamer Control Plane (ISIS Underlay, BGP, COOP, usw.) definiert. Eine ACI Fabric ist wiederum durch den gemeinsamen APIC- aka Controller Cluster beschrieben. Multi-Pod bedeutet somit zusammengefasst: Ein einzelner APIC Cluster mit mehreren “getrennten” Leaf | Spine Netzwerken.

 

ACI

 

Gemeinsamkeiten zur Stretched Fabric:

  • Über einen einzelnen APIC Cluster verwaltet
  • Einzelne Management und Policy Domain

Trotz gemeinsamer Management Plane über mehrere Data Center, zusammen mit einem Feature namens “Configuration Zones” kann man die Auswirkungen von Ausfällen, die durch Konfigurationsänderungen auftreten können, auf einen Pod begrenzen.

 

Unterschiede zu einer Stretched Fabric:

  • Mehrere ACI Pods sind über ein Layer 3 Netzwerk verbunden
  • Jeder Pod verfügt über ein eigenes ACI Leaf/Spine Netzwerk
  • Pods zwischen aber auch innerhalb eines DC ermöglichen segmentiertes Zonen Design (Availability Zones)
  • Forwarding Control Plane Isolation (IS-IS, COOP, usw.) am DCI
  • Data Plane VXLAN Encapsulation zwischen Pods / am DCI
  • 10 Gbit/s Bandbreite am Übergang ist unterstützt

Über ein Multi-Pod Netzwerk ergeben sich völlig neue Möglichkeiten der Anbindung am DCI Übergang. Dabei können auch mehr als zwei ACI Fabrics miteinander Verbunden werden, jedoch mehr als 3 Standorte könnte aufgrund des gemeinsamen APIC Clusters problematisch sein.

 

ACI

 

Wie bei der Stretched Fabric ist auch hier die maximal zulässige Latency durch den gemeinsamen APIC Cluster auf derzeit 50 msec begrenzt (seit Version 2.3.1, davor 10 msec).

Abgesehen von den flexiblen Möglichkeiten in den DCI Topologien, sind jedoch noch andere Anforderungen an diesen Übergang zu erfüllen. Es werden separate s.g. Interpod-Network (IPN) Geräte benötigt, die nicht vom APIC aus verwaltet werden können. Wobei das aufgrund der statischen Konfigurationen auf diesen Geräten kein Problem darstellt. Somit dürfen selbst bei einer Verbindung von nur zwei Datacenter die Spines nicht direkt miteinander verbunden werden!

Die wichtigsten Anforderungen an diese IPN Geräte:

  • Multicast BiDir PIM, um den Layer 2 Broadcast, Unknown Unicast, Multicast (BUM) Traffic weiterleiten zu können
  • OSPF fürs Underlay Netzwerk – Erreichbarkeit für die VTEP Adressen
  • MTU muss mindestens die VXLAN Paketgröße unterstützen
  • DHCP Relay Funktionalität, um Fabric Autodiscovery über DCI Grenzen zu ermöglichen

Als Hardware für die IPN Geräte kommt beispielsweise ein Nexus 9200 oder 9300-EX in Frage (nicht die erste Generation). Die günstigste Variante ist derzeit eine IPN Verbindung über 2x Nexus 9200 wie in folgender Skizze gezeigt:

 

 

Distanz und Latency am DCI

Die Distanz zwischen diesen beiden Standorten hat einen großen Einfluss auf die Komplexität und Kosten der Lösung. In den oberhalb beschriebenen DCI Lösungen werden maximal zulässige Distanzen und Latency Werte unterstützt. Eine Stretched Fabric (damit eigentlich der einzelne APIC Cluster) darf zum aktuellen Zeitpunkt über bis zu ca. 800 km Distanz zueinander verbunden werden. Die Latency Grenze ist derzeit mit bis zu maximal 50 msec für den DCI angegeben. Dies Limits gilt für die folgend beschriebenen DCI Lösungsvarianten in der Form nicht, damit sind diese für große Distanzen geeignet.

 

Multi-Fabric mit Layer 2 und/oder Layer 3 DCI

Ab der ersten Version der ACI Fabric war diese Art der Verbindung zweier Datacenter möglich, denn es handelt sich prinzipiell um Standard Layer 2 oder Layer 3 Anbindungen an die ACI Fabric wie man sie auch in Richtung anderer Netzwerkanbindungen ans Datacenter verwirklicht (Campus, WAN, Internet, …).

 

ACI

 

Diese Anbindungen werden im Gegensatz zu Multi-Pod über Border Leafs hergestellt und können direkt über Darkfiber, DWDM, CWDM oder auch über ein geroutetes Provider Netzwerk erfolgen. Man ist hier maximal flexibel, was wohl der größte Vorteil dieser Variante ist. Nachdem hier auch zwei getrennte Management Domains durch getrennte APIC Cluster pro Datacenter agieren, ist man auch an keine maximale Distanz oder Latency gebunden (Applikationen und deren Anforderungen an die Kommunikation ist hier die reale Limitation).

Getrennte Management Plane, Forwarding Control Plane und letztlich isolierte ACI Fabrics sorgen für einen stabilen Betrieb und weniger komplexe Abhängigkeiten als beispielsweise bei einer Multi-Site Implementation. Jedoch keine Vorteile ohne Nachteile, durch die sich die aktuellere Multi-Site Lösung vorteilhaft auszeichnet:

  • Keine MP-BGP EVPN Control Plane zwischen Datacenter
  • Data Plane hat prinzipiell keine VXLAN Encapsulation zwischen Datacenter
  • Keine End to End Policy Definitionen und Enforcement über DCI Übergänge

Durch diese Fehlenden Integrationen am DCI Übergang würde bei einer Layer 2 Kopplung beispielsweise keine Flooding Optimierung stattfinden können. Deshalb ist für diesen Ansatz prinzipiell eine Layer 3 Kopplung zu bevorzugen falls dies die angebundenen Compute Ressourcen erlauben. Die fehlende Management Domain durch getrennte APIC Cluster verhindert eine integrierte Synchronisation von Policies und Konfigurationen. Dennoch darf man nicht die Stärken der APIC API zusammen mit den zur Verfügung stehenden API Frameworks unterschätzen – ein programmatischer Config-Sync kann beispielsweise eine verhältnismäßig einfache Lösung für ein Desaster Recovery Datacenter sein.

Bei NTS setzen wir aktuell eine derartige Desaster Recovery Lösung über zwei Datacener mit parallelen Active/Active Charakteristika nach dem Multi-Fabric Ansatz um.

 

Multi-Site

Der aktuellste Ansatz für DCI Verbindungen in ACI ist vor kurzem durch Version 3.0 hinzugekommen. Multi-Site ist als Evolution des Multi-Fabric Ansatzes zu verstehen. Wie bei der Multi-Pod Lösung werden die Verbindungen direkt über den Spine Layer hergestellt. Außerdem wird ebenfalls ein von ACI separates IP Netzwerk für das DCI benötigt, der Übergang findet geroutet statt.

 

ACI

 

Im Gegensatz zu Multi-Pod wird am DCI Trägernetzwerk kein Multicast benötigt, da andere Traffic Replication Techniken angewandt werden. Damit verbleibt OSPF und die erhöhte MTU durch VXLAN als Anforderung bestehen. Ein großer Vorteil ist nicht zuletzt die Aufhebung des 50 msec Limits für ein reines Multi-Site Deployment. Datacenter können somit grundsätzlich auf weltweiter Skalierung implementiert werden.

Ein weiterer markanter Unterschied ergibt sich durch die so genannte ACI Multi-Zone. Dabei handelt es sich um ein “Umbrella Management” für einen oder mehrere APIC Cluster. Das ermöglicht eine Management Isolierung pro Datacenter bei gleichzeitig zentralem Management mehrerer APIC Cluster und zentrale Policy Verwaltung. Derzeit ist die Multi-Zone Software als vSphere Deployment mit drei VMs unterstützt (diese müssen nicht in einer Fabric laufen). Später sollen KVM und Hardware Appliance Varianten hinzukommen.

 

ACI

 

Wodurch zeichnet sich eine Multi-Site Lösung im Gegensatz zu den anderen Ansätzen aus?

  • Separate ACI Fabrics mit unabhängigen APIC Clustern
  • Gleichzeitig zentrales Multi-Site Management der unabhängigen Cluster
  • MP-BGP EVPN Control Plane zwischen DC Sites
  • VXLAN Data Plane Encapsulation am DCI Übergang
  • Damit zentrale End-to-End Policy Konfiguration und Enforcement über alle DC Sites

In der Multi-Site Lösung wird es möglich sein optional die Multi-Pod Ansätze innerhalb oder zwischen mehreren Datacenter zu implementieren. Dadurch ergeben sich wieder neue Möglichkeiten im Datacenter Design durch die Schaffung von Availability Zones zwischen und auch innerhalb von Datacenter Lokationen.

Hardware- und Software Anforderung für den Multi-Site Betrieb

  • Alle Generationen von Leaf Switches sind erlaubt (auch erste Generation)
  • Nur -EX Spine oder neuere Generation am Spine Layer für DCI Interconnect
  • Der neue Fixed Spine 9364C mit 64x 40G / 100G Ports wird ab 2018 Multi-Site unterstützen
  • Der bis dato für Österreich skalierende 9336PQ ist somit nicht geeignet

Im Multi-Site Design kann man zwischen verschiedenen Ansätzen des DCI Networking wählen, indem man beispielsweise den Scope einer Bridge Domain lokal oder DC übergreifend definiert. Im ersten Usecase existieren verschiedene Bridge Domains mit verschiedenen Subnets pro Datacenter und die DCI Kommunikation erfolgt als geroutete Kommunikation. Dieser Ansatz ist aus Sicht des Netzwerks am schönsten, jedoch aufgrund virtueller Workloads oder Applikations- Anforderungen nicht immer realisierbar.

 

ACI

 

Das zweite Beispiel wäre ein valider Ansatz für den betrieb einer Desaster Recovery Site. Dies ergibt sich durch die Anforderung, gleiche IP Subnetze auf mehreren Standorten zur Verfügung zu stellen. Hier wird die “IP Mobility” in andere DC ohne Layer 2 DCI Erweiterung ermöglicht. Das wird durch optimierte Learning Mechanismen im Spine zusammen mit der MP-BGP EVPN Control Plane am DCI Übergang realisiert. Der Vorteil in diesem Fall ist die Verhinderung von Layer 2 Traffic Flooding zwischen Datacenter, was der Stabilität des Netzwerks zu Gute kommt.

Im dritten Usecase wird der typische Multi-Pod Design Ansatz auf Multi-Site umgelegt, wodurch die Anforderung nach flachen Layer 2 Strukturen über Datacenter Grenzen hinweg realisiert wird. Hierbei sei angemerkt, dass in ACI auch innerhalb einer Bridge Domain Flooding Optimierungen existieren, die in anderen DCI Technologien nicht zur Verfügung stehen würden. Zusammen mit dem Wegfallen des beschriebenen Distanz Limits und Multicast Requirements eine interessante Alternative zu Multi-Pod.

Multi-Site hat bestimmt das größte Potential für zukünftige Weiterentwicklungen im DCI Umfeld. Zusammen mit Multi-Pod könnte man beispielsweise für verschiedene Datacenter Anforderungen ein flexibles, stabiles und isoliertes Netzwerk per Usecase realisieren.

 

Möchten Sie mehr zu Cisco Application Centric Infrastructure erfahren?

Herwig Gans steht ihnen für weitere Fragen und Informationen sehr gerne zur Verfügung.