EINE LÖSUNG FÜR IHRE ANFORDERUNGEN IM DATACENTER?

SDN, die beflügelte Abkürzung für Software Defined Network ist in aller Hersteller Munde, sodass man im IT Arbeitsumfeld derzeit unmöglich an diesem Begriff vorbeikommt. Als Kunde stellt man sich mitunter eine provokante Frage: “Ist SDN das neue IPv6?” – oder anders gefragt: “Sind SDN Lösungen mit ihren völlig neuen Ansätzen in Wirklichkeit nur für einen kleinen Markt und dessen spezielle Anforderungen geeignet?”

Ob Cisco ACI aufgrund seiner Architektur eine SDN Lösung im ursprünglichen Sinne ist, könnte man lange diskutieren. Mit ähnlich philosophisch abstrakten Fragestellungen versuchen sich derzeit manche Hersteller diesem Thema zu nähern. Während das Zusammenwachsen von Netzwerk, Server und Applikation im Datacenter durchaus viele Vorteile mit sich bringen kann, steigt parallel die Komplexität einer Produktfindung für den Kunden, da sich plötzlich Server-, Netzwerk Hersteller und Entwickler von Applikationen als Konkurrenten verstehen. Ob SDN Lösung oder nicht, Cisco ACI ist ein konkretes Produkt mit konkreten Ansätzen.

 

Gibt es ACI Use Cases für jedes Datacenter?

Was kann mir ACI im Vergleich zum traditionellen Netzwerk bieten? Wie komplex ist eine Migration?

 

In diesem Blog möchte ich auf diese Fragestellungen aus dem Blickwinkel eines “Netzwerkers an der Front” eingehen.

 

WELCHE MOTIVATION STEHT HINTER DER ENTWICKLUNG VON CISCO ACI?

In der Netzwerktechnik sind wir aufgrund der Historie gewohnt in VLAN- und IP Netzwerkstrukturen zu denken. Dem gegenüber stehen Applikationsentwickler, die ein IP Netzwerk naturgemäß tendenziell als gegebenes, möglichst flach organisiertes Konstrukt für die Kommunikation ihrer Applikationen untereinander nutzen. Dazwischen existieren diverse Server- und Virtualisierungsarchitekturen. Diese bis dato eher gekapselten  Arbeitsbereiche mit ihren individuellen Anforderungen verursachen strukturelle Widersprüche in einer Gesamtlösung in Bezug auf Stabilität, Flexibilität und Sicherheit. Die Provisionierung neuer Services ist komplex, da an vielen Punkten unterschiedliche Konfigurationen notwendig sind, um letztlich ein Ziel zu erreichen.

Die Cisco ACI verfolgt einen völlig neuen Ansatz, um diese Probleme zu adressieren, indem  Applikationen und deren Kommunikation am Netzwerk, über Server- bzw. Virtualisierungsarchitekturen ins Zentrum einer umfassenderen, zentral steuerbaren Lösung gerückt werden.

VOR- UND NACHTEILE EINER CISCO ACI LÖSUNG IN STICHWORTEN

Es gibt kürzere Artikel zum Thema ACI, ein vergeblicher Versuch das Produkt schnell attraktiv zu machen. Es ist unmöglich das Konzept in wenigen Absätzen zu beschreiben. Aufgrund des größeren Umfangs dieses Blogs möchte ich vorzeitig meine Einschätzung über die Vor- und Nachteile einer Cisco ACI Lösung in Kurzform zusammenfassen. Auf die einzelnen Punkte wird in den einzelnen Kapiteln genauer eingegangen.

Die Vorteile sind global gesehen durchaus gewichtig:

 

  • “East-West” Security ohne Skalierungsprobleme im Datacenter durch EPG und Security Contracts.Dieses Security Konzept steht in der ACI Fabric in voller Forwarding Performance zur Verfügung.Derzeit durchaus ein Hauptargument, das für den Einsatz von ACI spricht.
  • Optimiertes Traffic Forwarding durch Reduzierung von Broadcasts und Unknown Unicast Frames in der ACI Fabric
  • Zentrale Verwaltung über gut organisiertes GUI, CLI, API Programmierung
  • Automatische Provisionierung von EPG (Endpoint Group) Kommunikation bis zur VM direkt aus der zentralen Verwaltung der ACI Lösung
  • Policy basierte Konfiguration, wodurch jedes neue Service mit ihren Abhängigkeiten beliebig oft sehr effizient provisionierbar ist
  • Einfache, modulare Topologie mit maximal flexiblen Erweiterungsmöglichkeiten

 

Die Nachteile sind eine sehr komplexe und mitunter langwierige Migration von Services eines bestehenden Datacenters in eine Service und Contract basierte ACI Policy und der anfängliche Schulungsaufwand für MitarbeiterInnen. Abgesehen davon entspricht die Umsetzung der integrierten ACI Security keiner Stateful Firewall Funktion, sondern s.g. “reflexive” Access Control Lists (ACL). Für eine saubere Implementierung von Security Contracts muss man exakt wissen, welche Kommunikation zwischen Servern im Datacenter existiert.

 

ACI BAUT AUF EIN VXLAN OVERLAY NETZWERK AUF

WARUM SIND VLANS EIN FEINDBILD IM DATACENTER?

Ein Argument ist, dass VLANs aufgrund des fixen Limits von 4000 nicht ausreichend skalieren würden. Es stimmt, dass ACI aufgrund der integralen VXLAN Encapsulation viel besser skaliert (auf bis zu 16 Millionen Segmente). Dies kann jedoch mit Rücksicht auf die Größe der meisten der Cisco Netzwerke, die wir kennen, nicht als primäres Verkaufsargument gelten.

Datenübertragung über ein traditionelles VLAN Netzwerk bringt gewichtige Limitationen mit sich:

 

  • Spanning Tree zur Auflösung von Netzwerk Loops mit bekannten Limitationen
  • Dezentrales MAC Address Table learning, damit keine zentrale Sicht auf angeschlossene Endgeräte
  • Flooding Verhalten in VLANs ist kaum kontrollierbar
  • Transport von Layer 2 Frames über Layer 3 Grenzen hinweg nicht möglich

 

Für die Beseitigung dieser Limitationen werden in einer ACI Fabric VXLAN Overlay Features genutzt. Ein Überblick über die VXLAN Technologie kann in folgendem Blog von mir nachgelesen werden: VXLAN – Overlays im Rechenzentrum

 

ACI ist jedoch viel mehr als ein reines VXLAN Overlay, auf die ACI spezifischen Funktionen wird hier genauer eingegangen.

NEXUS 9000 MIT NX-OS UND VXLAN VERSUS ACI BETRIEB

VXLAN kann auf der Nexus 9000 Platform im klassischen NX-OS Modus ohne ACI Fabric betrieben werden. Der größte Nachteil dabei ist die komplexe Konfiguration bzw. das dezentrale Management über die Command Line. Diesen Nachteil gibt es bei Cisco ACI nicht, da VXLAN automatisch von der Fabric konfiguriert und verwaltet wird!

VLAN Encapsulation gibt es bei ACI weiterhin, jedoch nur mehr für einige Anbindungen zwischen Endsystemen und der ACI Fabric. Es wird zwischen “Localised” und “Normalised” Encapsulation in der Fabric unterschieden. Der Übergang dafür liegt auf den Leaf Switches, die in der Funktion eines VTEP (Virtual Tunnel Endpoint) die Übersetzung von lokaler zu normalisierter VXLAN Encapsulation durchführen.

 

EINFACHE, KLARE TOPOLOGIE ALS GRUNDBAUSTEIN

Cisco ACI verlangt nach einer starren “Leaf-Spine” Fabric Topologie, die keine alternativen Anbindungsvarianten erlaubt. Formuliert man es so, klingt das nach einer unflexiblen Lösung, wie man sie im eigenen Netzwerk eigentlich nicht haben will. In Wirklichkeit ist dieser Ansatz jedoch als großer Vorteil in Hinblick auf Skalierung und Stabilität zu werten.

Leaf Switches stellen die Verbindung zu Endsystemen oder externen Netzwerken her. Spine Switches stellen ausschließlich die Verbindung zu allen Leaf Switches her (in Ausnahmefällen zu externen Anbindungen). Weder Spine noch Leaf Switches dürfen direkt miteinander verbunden werden. Das stellt sicher, dass “Inter-Leaf” Traffic immer über einen Spine Switch muss – eine sehr wichtige Notwendigkeit der ACI Lösung.

Die verfügbare Bandbreite zwischen Leaf und Spine ist natürlich von zentraler Wichtigkeit in dieser Topologie. Inzwischen sprechen wir von 40G und 100G im Datacenter zu Preisen, die noch vor 2 Jahren nicht denkbar waren. Außerdem sorgt die VXLAN Encapsulation zusammen mit dem ISIS Routingprotokoll in der ACI Fabric für gleichmäßige Auslastung bei mehreren Uplinks zwischen Leaf und Spine Switches.

 

BUILDING BLOCKS

Leaf und Spine Switches bestehen aus der Cisco Nexus 9000 Platform, die statt dem NX-OS Betriebssystem mit einer ACI Software betrieben werden. Neben den angesprochenen Leaf bzw. Spine Komponenten ist der APIC (Application Policy Infrastructure Controller) der zentrale Punkt für sämtliche Konfigurationen. Damit ergeben sich die einzelnen Building Blocks einer ACI Lösung mit folgenden Hauptfunktionen.

LEAF SWITCHES

Die Auswahl der Leaf Switches richtet sich nach folgenden Kennwerten, in denen sich die verschiedenen Generationen unterscheiden.

  • Aktuelle Leaf Switches erlauben eine Connectivity von bis zu 25 Gbps zu Endsystemen und 100 Gbps zum Spine
  • Physikalische Anbindung via 10GBase-T oder 10/25 Gbps SFP zu Endsystemen
  • Buffer und Queue Management, dynamisches Load Balancing und QoS für Latency sensitive Flows
  • Policy CAM ist ein Hardware Speicher für die Segmentierung von Endpoint Gruppen in Security Zonen. Security Contracts werden darüber realisiert.
  • Multicast Routing Support
  • Analyse Support
  • Skalierung für Endpunkte, richtet sich nach der größe der TCAM Tables am Modell
  • FCoE Support
  • Layer 4-7 Redirect features über s.g. Service Graphs
  • Microsegmentation – Isolierung von Endpunkten z.B. basierend nach VM Properties, IP- oder MAC Adressen usw. (Funktion vergleichbar zu Private VLANs)

SPINE SWITCHES

In der ACI Fabric wird basierend auf host Lookups Traffic weitergeleitet. Jeder Leaf hat eine lokale Lookup Datenbank für Endsysteme, die am Leaf angeschlossen sind. Spine Switches haben eine globale Sicht über alle Endpunkte der gesamten Fabric, alle bekannten Endpunkte sind in der ACI Spine Datenbank gespeichert. Das ermöglicht geringere Anforderungen an die Hardware auf den Leafs. Spine Switches werden somit neben der Uplink Bandbreite auch nach der Anzahl der Endpunkten dimensioniert.

 

Es gibt modulare und fixe Spine Switches:

  • Nexus 9336PQ fixed unterstützt bis zu 200.000 Endpunkte
  • Nexus 9500, 4 Slots – bis zu 300.000 Endpunkte
  • Nexus 9500, 8 Slots – bis zu 600.000 Endpunkte
  • Nexus 9500, 16 Slots – bis zu 1,2 Millionen Endpunkte
  • Cisco Application Policy Infrastructure Controller – APIC

 

CISCO APPLICATION POLICY INFRASTRUCTURE CONTROLLER – APIC

Der APIC Controller besteht aus 3 mitgelieferten Cisco UCS C220 Servern und stellt die zentrale Verwaltung der gesamten ACI Infrastruktur dar. Sie sind physisch an die Leaf Switches via 10G Bandbreite angeschlossen, weiters hat ein Controller einen 1G OOB Anschluss. Den APIC gibt es in zwei Größen: APIC-M für bis zu 1000 Edge Ports und APIC-L ab 1000 Edge Ports.

APIC – FLEXIBILITÄT IN DER KONFIGURATION

In den ersten Versionen der APIC Software stand ein generisches graphisches User Interface, das sehr nahe am modularen Policy Ansatz der ACI Lösung entwickelt wurde. Dieses Interface wird primär für die Konfiguration einer ACI Fabric verwendet. Dieses GUI ist in Wirklichkeit eine visuelle Darstellung einer zugrunde liegenden API zum APIC Controller. Diese REST API steht dem Kunden zusätzlich als offene Schnittstelle zur programmatischen Steuerung der kompletten ACI Fabric mit allen beinhalteten Funktionen zur Verfügung. Für die API werden derzeit Python, Ruby und Window Powershell SDKs mitgeliefert.

Später kam auf vielfachen Kundenwunsch ein weiterer GUI Modus (Basic) und eine vollwertige NX-OS CLI für Puristen hinzu. Diese CLI ist sehr hilfreich für viele Troubleshooting Prozesse.

 

VIRTUAL MACHINE ORCHESTRIERUNG

Die Cisco ACI Software unterstützt die gängigsten Hypervisor Lösungen. Damit kann es mit verschiedensten VM Managern wie VMware vSphere, Microsoft SCVMM und OpenStack verbunden werden.

Durch diese Integration entsteht ein weiterer Vorteil einer ACI Lösung gegenüber klassischem Datacenter Networking, in der ein Techniker auf jeder einzelnen Komponente VLANs provisionieren und diese dann auch noch in gleicher Weise zusätzlich auf der VM Infrastruktur provisionieren muss. Mit der ACI VM Integration können Port Profile am VM Management automatisch aufgrund der ACI Service Definition erstellt werden. Es gibt damit lediglich einen Punkt der Konfiguration für die Provisionierung neuer Networking Services im Datacenter und diese beinhaltet auch die VM Infrastruktur bis zur virtuellen Maschine.

In der aktuellen ACI Software Version kann aber auch der umgekehrte Weg beschritten werden, indem das ACI Networking mittels vCenter Plugin von VM Manager Seite her konfiguriert werden kann. Weitere Plugins für Orchestrierung und Automatisierung stehen derzeit für Cisco UCS Director, CloudCenter, Microsoft Azure Pack und VMware vRealize zur Verfügung.

 

ENDPOINT GROUPS – SECURITY BASIERTE SEGMENTIERUNG

In einem traditionellen Design wird Security im Allgemeinen zwischen Netzwerksegmenten am Layer 3 Übergang realisiert.

Filter innerhalb eines Layer 2 Segments sind im Datacenter kaum machbar. Uplink Bandbreiten liegen aktuell bei 40 bis 100 Gbps, hier eine Firewall zu platzieren ist ineffizient. Dennoch gibt es vermehrt die Anforderung Server und dessen Applikationen voneinander zu isolieren bzw. Zugriffe exakt steuern zu können. ACI erfüllt diese Anforderung über das Konzept von Endpoint Groups (EPG) und Contracts zwischen diesen.

Dabei werden Endgeräte wie z.B. Server (Baremetal, VM, etc.) mittels EPG nach definierbaren Kriterien wie VLAN Tag, IP Adresse, MAC Adresse zugewiesen. Ein Endgerät kann immer nur einer Endpoint Group zugewiesen sein. Systeme in einer Endpoint Group dürfen uneingeschränkt miteinander kommunizieren (sofern keine Micrisegmentation zum Einsatz kommt). Endgeräte in verschiedenen EPG dürfen per Default nicht miteinander kommunizieren, dies kann ausschließlich über s.g. Contracts (entsprechen Zugriffsregeln) erfolgen.

Contracts entsprechen technisch gesehen s.g. “reflexive” Access-Lists, in denen Server und Client Rolle (Consumer und Provider) definiert und Retour-Traffic entsprechend automatisch freigeschaltet werden kann. Diese Rules werden direkt in der ACI Leaf Hardware implementiert. Somit steht diese Art der Security “Line Rate”, also mit voller ACI Forwarding Performance in der Fabric zur Verfügung.

 

BRIDGE DOMAINS – OPTIMIERTES LAYER 2 FORWARDING IN DER ACI FABRIC

Die beschriebenen Konzepte von EPG und Contracts sind eine der Alleinstellungsmerkmale in der ACI Architektur. Egal ob Datentransfer innerhalb einer EPG oder übergreifend mit Contracts, für das Forwarding innerhalb der ACI Fabric kommt VXLAN zum Einsatz. Auch hier wurden sinnvolle Anpassungen vorgenommen, auf die hier nicht im Detail eingegangen werden.

Für ein Endgerät darf es keinen Unterschied machen, ob es über ein traditionelles  Netzwerk oder eine ACI Fabric kommuniziert. Für Layer 2 Frames gibt es in ACI das Konzept von Bridge Domains (BD) die auch gleichzeitig Broadcast Domains darstellen. Endpoint Groups sind immer einer BD untergeordnet, es können mehrere EPG einer Bridge Domain angehören.

Bridge Domains werden oft mit VLANs verglichen, da sie analog zu VLANs die Grenzen für Layer 2 Frames definieren und unter anderem ARP und anderen Broadcast Traffic behandeln. Außerdem können Bridge Domains (mehrere) IP Adressen als Gateways zugewiesen werden, analog zu Default Gateways in VLAN Strukturen. Dieser Vergleich ist dennoch irreführend, da Bridge Domains völlig unabhängig zu VLANs funktionieren. Es gibt keine VLAN Tags in der ACI Fabric. Server in verschiedenen EPG können trotzdem in derselben Bridge Domain zugewiesen sein, obwohl sie sich lokal (z.B. auf VM Level) in verschiedenen VLANs befinden!

Für ARP, Broadcast und Multicast Traffic wurden in ACI spezielle Optimierungen implementiert, die darauf abzielen Traffic Flooding innerhalb einer Broadcast Domain möglichst gering zu halten. Ohne weiter ins Detail zu gehen sei erwähnt, dass viele Broadcast Pakete in der Fabric zu Unicast Paketen umgewandelt werden können, da die ACI Fabric aufgrund der intern verwalteten Mapping Tables bereits Kenntnis über die Zielsysteme (bzw. Leaf, auf dem diese Systeme angeschlossen sind) hat.

 

TENANTS SIND MANDANTEN

Die oberste Ebene der ACI Architektur stellen Tenants dar, sie können wie Mandanten verstanden werden und es können mehrere Mandanten parallel betrieben werden.

Jeder Tenant kann ein oder mehrere virtuelle Routing (VRF) Instanzen verwalten. Darunter kann jedes VRF wiederum ein oder mehrere Bridge Domains (BD) beheimaten und jede BD unterstützt mehrere IP Subnetze(und deren Default Gateways für Hosts). Letztlich werden Endsysteme mittels Endpoint Group (EPG) an die ACI Fabric herangeführt. Diese EPG können mehrere Endsysteme beinhalten und sind letztlich den Bridge Domains untergeordnet. Es können mehrere EPG einer BD angehören.

Aus dieser Ableitung kann folgendes Beispiel einer Hierarchie mit zwei Tenants und entsprechend untergeordneten ACI Building Blocks gezeichnet werden:

Wie bereits beschrieben können Endgeräte innerhalb einer Endpoint Group ohne Security Contracts “frei” kommunizieren. Eine Endpoint Group kann immer nur einer Bridge Domain angehören. Endgeräte in verschiedenen EPG können über Contracts miteinander kommunizieren. Dies ist auch zwischen EPG in verschiedenen Bridge Domains und VRFs möglich. Endgeräte in verschiedenen Tenants können ebenfallsinnerhalb der ACI Fabric kommunizieren, obwohl sich die Endgeräte in verschiedenen VRFs befinden. Dies ist über ein integriertes Route Leaking Feature innerhalb der ACI Fabric möglich. Diese Inter-Tenant Kommunikation muss jedoch explizit im Sinne der “Zero Trust” Contract Architektur von ACI bewusst konfiguriert werden.

Werden Contracts zwischen Tenants exportiert, können diese durch integriertes Route Leaking miteinander kommunizieren:

Auf die grundlegende Routing Architektur innerhalb und außerhalb einer ACI Fabric wird im nächsten Kapitel eingegangen.

 

ACI INTERNES UND EXTERNES ROUTING

Ein Leaf Switch, der ein Paket von einem Host erhält muss feststellen, ob die Ziel IP Adresse innerhalb oder außerhalb der ACI Fabric liegt. Um das zu ermöglichen hält ein Leaf Switch alle Subnetze aller Bridge Domainsdes eigenen Tenants. All diese ACI internen Netze zeigen auf Spine Switches (Proxy Spine Adresse).

 

In der ACI Fabric werden somit beide Möglichkeiten abgedeckt:

  • ACI interne Netze sind mit Tenants und deren Bridge Domains
  • ACI externe Netze entsprechen L3out Routen, die in der ACI Fabric gelernt werden.

IP Routing muss gezielt pro Bridge Domain aktiviert werden. Ist es eingeschaltet, lernt ein Spine neben den MAC Adressen einer BD zusätzlich auch die IP Adressen. Außerdem hält Leaf hat einen Cache mit lokalen und Remote Destinationen. Ein Leaf Switch versucht somit Pakete anhand seines lokalen Cache direkt zuzustellen. Ist dies nicht möglich, übt der Spine diese Funktion aus, sofern dieser einen Eintrag in seinem Mapping Table hat.

Hat der Spine Layer ebenfalls keine Kenntnis über das Ziel, werden ARP Pakete für alle Leaf Switches in dieser Broadcast Domain generiert.

Für Ziele außerhalb der ACI Fabric lernen Leaf Switches diese Netze via MP-BGP Routing Protokoll. Dies ist notwendig, da Spines nur “exact match route lookups” machen und nicht “longest match lookups”, wie es Router üblicherweise tun. Die externen Destinationen werden über einen Vergleich der Destination IP mit allen Subnetzen aller Bridge Domains des eigenen Tenants erkannt. Gibt es keinen Match mit den internen Netzen konsultiert der Leaf seinen Routing Table für externe Routen.

Inter-Tenant Kommunikation findet aufgrund der beschriebenen ACI Hierarchie automatisch immer zwischen VRF Instanzen statt. Die logische Konsequenz wäre: Endpunkte in verschiedenen Tenants müssen zwangsläufig über ein ACI externes Routing realisiert werden. In der ACI Fabric wurde jedoch die Möglichkeit geschaffen, diesen Verkehr zwischen Tenants innerhalb der Fabric zu erlauben – mittels Route Leaking, das bewusst über Contracts Exports in beiden Tenants konfiguriert werden muss. Dies stellt sicher, dass nicht ein Tenant (z.B. Kunde) die Routen eines anderen ohne dessen Wissen importiert.

 

Abschließend zur Erinnerung: Aus Sicht von Endpoint Groups müssen in jedem Fall Contracts für Ziele außerhalb der eigenen EPG existieren und die Kommunikation muss zwischen EPG erlaubt sein. Dieser Prozess ist grundsätzlich ident, egal ob ein Paket innerhalb einer Bridge Domain “switched”, oder über BD / VRF Grenzen über einen Routing Prozess zugestellt werden muss. Anders ausgedrückt sind EPG mit ihren Security Contracts eine von der Forwarding Control Plane abstrahierte Logik.

SKALIERUNG UND KOMPATIBILITÄT

Cisco ACI unterstützt ein beliebiges mischen von Leaf- bzw. Spine Platform Generationen im Betrieb einer ACI Fabric. Das ist ein nicht zu unterschätzender Vorteil für den langfristigen Betrieb. Man kann jederzeit Leaf Switches der neuesten Generation zu bestehender Fabric hinzufügen und erhält damit auch die neuen Features für diese hinzugefügten Geräte. Lokale Features wie z.B. EPG Classification Mode stehen damit am neuen Leaf sofort zur Verfügung. Globale Features, z.B. Multicast Routing, müssten jedoch isoliert für diese Leafs in Betrieb genommen werden und erfordern genauere Planung.

Maximale Flexibilität in einer Fabric Erweiterung besteht für die Spine Hardware. Der eingesetzte Spine Typ hat keinen Einfluss auf die unterstützten Features der gesamten Fabric.

Die Auswahl eines Spines richtet sich generell nur nach folgenden Kriterien:

  • Uplink Bandbreiten zwischen Leaf und Spines
  • Skalierung der Mapping Datenbank (Anzahl der maximal gleichzeitig betriebenen Endgeräte in der Fabric)

Auch ein Betrieb verschiedener Software Versionen auf Leafs wird unterstützt. In dem Fall werden nicht unterstützte Features von Leafs mit älterer Software an den APIC Controller mit einem “reject” quittiert, jedoch kein Fehler in der gesamten Fabric für dieses Feature erzeugt.

 

WIE KOMPLEX IST EINE MIGRATION?

Abschließend Überlegungen, wie sich eine ACI Infrastruktur in ein bestehendes Netzwerk integrieren lässt. Die beschriebenen Funktionen einer ACI Lösung machen deutlich: Es gilt einiges zu bedenken um ein bestehendes, VLAN basiertes Datacenter Netzwerk mit allen vorhandenen Endgeräten in eine ACI Architektur zu siedeln.

 

EINE REINE LAYER 3 KOPPLUNG

Die einfachste Umsetzung ist möglich, wenn man von vorne beginnen kann. Dies ist naturgemäß bei einem neuen Datacenter Standort der Fall und man hat gleichzeitig die besten Voraussetzungen, ACI im Sinne der darin enthaltenen Konzepte sauber umzusetzen.

 

Die Vorteile liegen auf der Hand:

  • Neues IP Address Konzept angepasst an ein Bridge Domain Design
  • Definition von passenden Service Gruppen und Applikationen in Endpoint Groups
  • Die Security Policy Definitionen in Contracts leitet sich daraus ab
  • Gesteuerte und überschaubare Implementation per Service / Applikation von Beginn an

 

Es ist aber nicht zwangsläufig so, dass man in bestehenden Datacenter Netzwerken alle Komponenten völlig ersetzen muss. Eine klar definierte Layer 3 Kopplung zwischen einem bestehenden Netzwerk und einer neuen ACI Infrastruktur ermöglicht den oberhalb beschriebenen strukturierten Zugang in Form einer Migration mit überschaubarer Komplexität. Der Nachteil in diesem Fall ist, dass man alle bestehenden Services der “alten Welt” bei der Siedlung in die ACI Fabric mit neuen IP Adressen versehen muss, um diese gesteuert im Sinne eines ACI Security Contract Designs definieren und umsetzen zu können. Dies kann ein sehr langwieriger Prozess sein und man muss in der ersten Planungsphase von Fall zu Fall abwägen ob dies ein valider Ansatz ist.

 

Die Umsetzung dieser Variante ist gut steuer- bzw. überschaubar:

  • Layer 3 only Kopplung am Übergang zum bestehenden Netzwerk
  • Contracts nach ACI Design Richtlinien
  • Siedlung erfolgt Service by Service auf neue Server Komponenten, oder  bestehende Server, die völlig neu in die ACI Fabric provisioniert werden können.

BESTEHENDES VLAN KONZEPT IN ACI ÜBERNEHMEN?

Diesen Ansatz könnte man mit der Anforderung definieren, bestehende Server, Services oder Applikationen mit möglichst geringem Aufwand auf Seite der Endsysteme in eine ACI Fabric zu übersiedeln. Um das zu ermöglichen, muss neben einer Layer 3 auch eine Layer 2 Kopplung zwischen bestehendem Netzwerk und ACI Fabric realisiert werden.

Cisco nennt diese Brownfield Migrationen “Network Centric ACI”. Im Endeffekt wird hierbei die bestehende VLAN Struktur unverändert in die ACI Fabric über idente Bridge Domains übertragen. In diesem Fall erfolgt eine völlige Gleichschaltung der ACI Hierarchie (VLAN = EPG = BD).

Anhand dieses Mappings auf Basis bestehender VLANs können und müssen Security Contracts zwischen VLANs (=BD und EPG) erfolgen, so wie es eventuell bereits zuvor über eine zentrale Datacenter Firewall der Fall war. Der Vorteil ist hier die integrierte Security Policy direkt in der Fabric in der maximalen Forwarding Performance.

Ist das ACI Netzwerk in dieser Form vorbereitet, müssen Server lediglich in die ACI Fabric “verschoben” werden (beispielsweise über VMware VMotion). Auch Baremetal Server können so viel leichter migriert werden.

Nach Abschluss der Server Migration könnte man damit beginnen eine granularere ACI Security zu implementieren, indem man einzelne Endsystem Ressourcen in verschiedene Endpoint Gruppen zuordnet und damit ein höheres Maß an Security im Datacenter erreicht. Die zugewiesenen Bridge Domains müssen bei diesem Ansatz aufgrund der vorgegebenen IP Adressierung in diesem Fall jedoch bestehen bleiben. Neue Systeme können natürlich zukünftig beliebig an die ACI Fabric herangeführt werden.

Eine direkte Migration in verschiedene EPG aus einer bestehenden VLAN Struktur ist auch möglich, jedoch kaum überschaubar und man müsste beim Verschieben der Ressourcen exakt wissen welche Kommunikationen zwischen Servern im Datacenter existieren. Diese Art der Migration ist nicht empfehlenswert.

 

EIN NEUER ANSATZ MIT VIEL POTENTIAL

Eine deutlich herausragende Funktion von ACI ist die granulare Security integriert in ein hoch performantes Datacenter Netzwerk. Nicht zu vernachlässigen sind jedoch auch viele andere umgesetzte und verbesserte Konzepte, die wir aus bekannten Limitationen der Vergangenheit kennen. Auf der anderen Seite muss man auch erwähnen, dass gewisse Anforderungen in einer Cisco ACI Lösung nicht so einfach umsetzbar sind wie wir es in der Vergangenheit  gewohnt waren.

Es gibt natürlich noch viel mehr zum Thema Cisco ACI zu berichten, wir haben erst an der Oberfläche gekratzt. Herwig Gans steht Ihnen für weitere Fragen und Informationen sehr gerne zur Verfügung.

Herwig Gans
Senior Systems Engineer
am 28.02.2017

    Zum Thema