Häufig geht es bei Terminen mit Kunden immer wieder darum, dass ACI (Application Centric Infrastructure) zu komplex ist, Vorteile der Trennung in EPG (Endpoint Groups) nicht benötigt werden und es zu schwierig zu verwalten ist. Aber es geht auch anders.
Der einfachste Weg ACI zu betrachten ist die netzwerkzentrische Sicht.
Im ACI wird alles in Objekten verwaltet und diese Objekte erlauben am Ende des Tages dann das Traffic zwischen zwei Endpunkten fließen darf oder eben nicht. Als oberste Instanz steht immer der Tenant. Dieser kann für eine logische Unterteilung in Abteilungen, Kunden oder auch für Sandboxumgebungen benutzt werden. Unterhalb des Tenants sitzt das Private Network oder auch VRF (Virtual Route Forwarding). Dieses bildet wie im klassischen Netzwerk die Layer 3 Unterteilung.
Bisher ist zum klassischen Netzwerk also eigentlich nur die Mandantenfähigkeit hinzugekommen. Jetzt kommen wir einen Schritt weiter und führen Application Profiles, EPGs und darin liegende EPs ein…
Logische Design von ACI
OK.
Einen Schritt zurück…
Bei der Betrachtung des netzwerkzentrischen Modus ist ein VLAN = EPG. Das bedeutet, dass sich eine EPG auch genauso verhält wie ein VLAN. Jeder darf innerhalb einer Layer 2 Subnetzes miteinander reden. Parallel ist damit auch gegeben, dass ich genau eine Bridge Domain an ein VLAN hänge. Ein Application Profile kann mehrere Bridge Domains und auch mehrere EPGs beinhalten. Wenn ich nun sage, dass ich zwei VLANs für Server verwende, dann könnte ich ein Application Profile bauen, welches Server beinhaltet und darin eben die beiden neue EPGs einsetzen. Dann wäre das Konstrukt genau gleich zu dem was ich bisher kenne.
Ich kann also auf sehr einfache Weise meine logische gewachsene Infrastruktur in ein ACI überführen und zeitgleich die Vorteile der Fabric nutzen.
- Zentrales Management: Die gesamte Fabric wird gemanaged wie ein einzelner Switch
- Zentrale API: Alles in der gesamten Fabric ist per API Call erreichbar und kann simpel automatisiert werden
- Microsegmentierung: Parallel zu meiner klassischen Überführung der Infrastruktur kann ich beginnen neue Netze für neue Applikationen anzulegen, die dem Grundprinzip der Mikrosegmentierung entsprechen
In vielen Fällen stellt sich die Frage, wie man denn nun ganz konkret VLANs ins ACI migrieren kann.
Wir erinnern uns daran, dass im netzwerkzentrischen Modus ein EPG = VLAN ist. Um eine “legacy Umgebung” an das ACI zu verbinden, gibt es mehrere Wege. Wenn ich an eine Lifemigration von virtuellen Maschinen von einem Cluster der legacy Umgebung in ein Cluster auf der ACI Fabric denke, wäre der Weg über ein L2-Out der gängigste. Das würde bedeuten, dass man schlicht und einfach einen Trunk nutzt und das VLAN in die Fabric verlängert. Somit kann unterbrechungsfrei die virtuelle Maschine in die Fabric migriert werden.
Sobald alle Maschinen in das Netz migriert wurden, muss man sich die Frage stellen, ob das Default Gateway für das VLAN ebenfalls in die Fabric wandern soll. Wenn ja, würde der Umzug des Default Gateways erfolgen, der möglicherweise einhergehend mit einem kurzen Pingausfall zu vermerken wäre. Falls keine Livemigration in Betracht gezogen wird, wäre der Weg über ein L3-Out also einem gerouteten Interface ebenfalls denkbar.
Für ACI muss man nicht alles neu lernen.
Klassisches Netzwerkwissen ist die Grundlage, um ACI zu betreiben. Zentrale Punkte des Managements vereinfachen im Anschluss den Betrieb und ermöglichen neue Möglichkeiten, um schneller und effizienter produktive Umgebungen betreiben zu können.
Also… Let’s deploy ACI!
Authors
