Virtualisierung ist aus heutiger Sicht aus dem Data Center nicht mehr wegzudenken. Umso wichtiger ist es, dass die verschiedensten Lösungen und Technologien gut zusammenspielen und im Ganzen “eine runde Sache” bilden. Im SDN-Bereich haben sich zwei mächtige Spieler positioniert und kämpfen um Kunden und Marktanteile:

 

  • VMware mit NSX
  • Cisco mit ACIO

 

Obwohl beide unterschiedliche Historien haben, und sich die Lösungen im Detail deutlich unterscheiden, haben beide dieselben Ziele:

 

  • Automatisierung durch Bereitstellung von Schnittstellen und APIs
  • Security vor allem durch Microsegmentierung und den damit verbundenen Policies
  • Flexibilität durch Aufbrechen der physikalischen Grenzen des Netzwerks

 

Mein Kollege Herwig Gans hat bereits einen ersten Einblick in den Aufbau und Funktionsweise der ACI Fabric gegeben. Ich werde mich heute mit der Integration der Virtualisierung befassen und nicht weiter auf Basiskonzepte wie EPGs, Contracts, Bridge-Domains, etc. eingehen.

3 (4) WEGE ZUM GLÜCK

Im Gegensatz zu VMware NSX bietet die ACI Infrastruktur die Möglichkeit mehrere Hypervisor Architekturen anzubinden. Hierzu zählen neben VMware vSphere (was sonst), auch Microsofts Hyper-V sowie auch Openstack mit KVM. Dies wird mit der Konfiguration der sogenannten VMMs (Virtual Machine Manager) erreicht. Diese beinhalten grundsätzlich die Anmeldeinformationen des jeweiligen Managers der zugrunde liegenden Virtualisierungslösung (z.B. VMware vCenter oder Microsoft SCVMM), sowie auch einige spezifische Einstellungen. Gerade beim Platzhirsch VMware existieren sogar drei (vier) unterschiedliche Möglichkeiten die Integration durchzuführen:

 

  • (Statisches EPG zu VLAN Mapping)
  • VMware DVS (Distributed Virtual Switch)
  • VMware DVS mit vShield (VxLAN Modus)
  • Cisco AVS (Application Virtual Switch)

 

Das statische Assignment ist – wie der Name schon verspricht – ein in der Regel manuelles Mapping von EPG zu bestimmten VLANs / Ports durch den Administrator. Diese Art der Konfiguration unterscheidet sich nicht zur Konfiguration von physikalischen Hosts und ist in keinster Weise auf die Virtualisierung abgestimmt.

 

Bei der VMware DVS Variante werden die EPGs dynamisch auf die jeweiligen VLANs gemapped. Dieses Mapping wird durch die Integration der APIC Controller mit dem vCenter kommuniziert, und die entsprechenden Port-Gruppen mit dem richtigen VLAN Mapping werden am DVS im vCenter konfiguriert. Dieser Weg bedient sich noch nicht des VxLAN Overlays. Er automatisiert nur den Konfigurationsvorgang zwischen den EPGs und den Port-Gruppen am DVS.

 

Soll nun auch VxLAN als Overlay verwendet werden, so muss das VMware DVS Setup um den vShield Manager entsprechend erweitert werden. Dieser stellt die Schnittstelle zwischen den APIC Controllern und dem DVS am vCenter dar. Die Konfiguration des vShield Managers übernimmt (größtenteils) die ACI Fabric (oder besser gesagt die Controller) – einzig die Konfiguration und Auswahl des Clusters und des Infrastruktur-VLANs muss durch den Administrator einmalig konfiguriert werden. Zusätzlich dazu werden ein paar VIBs auf den jeweiligen ESXi Host gepushed, welche für das Abhandeln des VxLAN Traffics zuständig sind.

 

Die wahrscheinlich aus ACI beste Art der VMware Integration stellt der AVS dar. Dieser setzt auf die bewährte Nexus 1000v Technologie auf und bedient sich sogar derselben VIBs (gewohnte Kommandos wie vem status, … gehen natürlich auch noch 😉 ). Bei der Konfiguration kann zwischen der VLAN oder VxLAN Encapsulation gewählt werden und es werden hierfür keine zusätzlichen Services / VMs (wie bei vShield) benötigt. Außerdem bietet der AVS die Möglichkeit sich zwischen zwei Switching Modi zu entscheiden:

 

  • No Local Switching
  • Local Switching

Wie der Grafik zu entnehmen ist, kontrolliert die Option, ob Traffic zwischen zwei VMs in derselben EPG zum Leaf gesendet werden sollen oder nicht. Aus meiner Sicht ist die local Switching Methode zu bevorzugen (vor allem dann wenn weitere Devices zwischen den ESXi Hosts und Leaf Switches ihre Arbeit verrichten – siehe UCS Fabric Interconnects (noch) ).

 

EMPFOHLENE (UND SUPPORTETE) AVS TOPOLOGIEN

Grundsätzlich können bzw. müssen wir bei den Topologien zwischen jenen unterscheiden, bei denen die Server / Hypervisors direkt an den Leaf Knoten angebunden sind und jenen, wo ein (oder auch mehrere) aktive Geräte (Switch oder auch UCS Fabric Interconnect) dazwischen laufen. Die folgenden Abbildungen zeigen diese:

In unserem weiteren Setup sehen wir die Topologie, welche ebenfalls das UCS beinhaltet. Im Detail sieht diese wie folgt aus:

Bei dieser Topologie läuft der ESXi Host (oder auch ein HyperV 😉 ) auf dem B200 M4 Blade mit dem installiertem AVS Modul. Aufgrund der Architektur des UCS können wir keinen vPC oder Ähnliches zwischen den Blades und den Fabric Interconnects konfigurieren (dies ist keine Besonderheit / Limitierung von ACI bzw. dem AVS sondern bei jeder VMware Installation ebenfalls der Fall), sondern arbeiten mit dem MAC Pinning. Zwischen dem UCS Fabric Interconnect und den ACI Leafs können (und sollen) wir natürlich VPCs mit der entsprechenden Bandbreite konfigurieren. Diese Konfiguration ist auch unabhängig von der Generation des UCS.

 

VON DER THEORIE ZUR PRAXIS

Nun werden wir uns mit der Umsetzung des Gelernten beschäftigen und einen AVS in die ACI Fabric und vCenter integrieren. Kann ja nicht so schwer sein – vCenter IP und Credentials und dann geht’s los, oder? ;-). Um ein wenig Würze in die Sache zu bringen, werden wir ebenfalls ein UCS in die Konfiguration / Topologie aufnehmen und uns die Unterschiede bzw. die Gotchas ansehen. Dabei setzen wir voraus, dass sowohl die ACI Fabric als auch das UCS Basis-konfiguriert ist.

Aus ACI Sicht wäre der erste Schritt die Konfiguration einer sogenannten VMM (Virtual Machine Manager) Domain, welche in unserem Fall das vCenter darstellt. Dies könnte sehr wohl auch der SCVMM sein. Pro ACI Fabric kann ich natürlich auch mehrere VMM Domains haben, sowohl auch mehrere vCenter als auch vCenter / SCVMM Kombinationen. Es ist auch durchaus möglich, dass mehrere VMM Domains auch dasselbe vCenter ansprechen. Dies mag im ersten Augenblick ein wenig komisch klingen, ist aber ganz klar wenn man sich vor Augen führt, was die VMM in Wirklichkeit darstellt – nämlich ein Distributed Virtual Switch.

Beim Konfigurieren der VMM Domain bekommt man den folgenden Dialog präsentiert:

Dabei sind neben dem Virtual Switch Namen (VMM Namen) auch die Auswahl zwischen AVS und VMware DVS, sowie auch gleich die Auswahl der Switching Methode (local oder auch nicht), die wir bereits besprochen haben. Mithilfe der vCenter Credentials und der vCenter Domain wird dann das entsprechende vCenter konfiguriert und erlaubt somit den API Zugriff vom APIC Controller aus. Da wir in unserer Topologie ein UCS zwischen den Leafs und den Blades/Hypervisor haben, müssen wir bei der Konfiguration der Uplinks auf ein paar Details achten:

 

  • Die vSwitch Policy sollte entsprechend der UCS Konfiguration entweder CDP oder LLDP erlauben, wobei LLDP die bevorzugte Option darstellt
  • Der Port-Channel Mode kann – wie schon angesprochen – nur MAC Pinning sein. Für direkt an die Leafs angeschlossenen Server hätten wir da durchaus mehr Optionen zur Verfügung:

LACP und statische Etherchannel (oder auch vPCs) können dann ebenfalls konfiguriert werden – im Falle vom UCS ist die MAC Pinning+ die empfohlene Methode.

  • BPDU Filter und BPDU Guard können ebenfalls konfiguriert werden (und sollten es auch werden.
  • Der Delimiter gibt das Trennzeichen vor, welches für die Benennung der Port-Gruppen im vCenter verwendet werden – welches sich wie folgt zusammensetzt: TENNANT|APP|EPG
  • Der Multicast IP Pool wird für das Forwarding der entsprechenden EPGs benötigt, da jede EPG eine eigene Multicast IP Adresse aus diesem Pool bekommt
  • Zu guter Letzt wird auch noch das AAEP definiert, welches die Port-Konfigurationen auf der Leaf-Seite bestimmt. Die oben beschriebenen Port-Channel Modi sind für die Hypervisor-Seite bestimmt. Im Falle von UCS ist dieser Teil etwas komplizierter. Dabei beschreibt der AAEP in dieser Topologie eigentlich den virtual Port-Channel zwischen dem Leaf und den  Fabric Interconnects. Dies ist einer der Fälle, wo die AAEP Konfig von jener des Hypervisors abweicht.

 

Ist die Konfiguration abgeschlossen, sehen wir sowohl im APIC GUI als auch im vCenter einen neuen Distributed Switch:

Hier noch ein Blick aus dem vSpehere Web Client:

UND NUN ZU DEN ESXI HOSTS

Mit der Konfiguration der VMMs haben wir zwar die Verbindung zwischen dem APIC und dem vCenter hergestellt und auch sogar einen Distributed Switch erstellt und konfiguriert, jedoch müssen – wie auch bei einem nativen VMware Distributed vSwitch die Hosts erst zu diesem hinzugefügt werden. Hierfür muss – wie auch beim Nexus 1000v – das VEM Modul zuerst auf den ESXi Hosts installiert werden. Hierfür stehen drei Optionen zur Verfügung:

 

  • Manuelle Installation des VIBs auf dem Host (mittels esxcli software vib install)
  • Automatische Installation mithilfe des vSphere Update Managers (VUM)
  • Deployment des Cisco Virtual Switch Update Managers (VSUM)

 

Bei der VSUM Variante muss zunächst der VSUM als OVA deployed, konfiguriert und ins vCenter integriert werden. Dies ist genauso einfach wie jede OVA Appliance, die man in letzter Zeit installiert hat – da hat Cisco ebenfalls guten Job geleistet. Ist dieser erst einmal deployed, taucht der VSUM im vCenter auf – ja nur im Web Client ;-).

Mit diesem Tool können sowohl Hosts zum AVS hinzugefügt werden alsauch das Upgrade der VEM Module, welche auf den entsprechenden Hosts installiert sind, durchgeführt werden. Wie gesagt, der VSUM ist definitiv kein Muss für die Installation und Konfiguration des AVS, aber er macht einem das Leben definitiv ein bisschen einfacher, da sich der Aufwand für die Installation definitiv in Grenzen hält.

Hier sehen wir wie man mithilfe des VSUM Hosts zum AVS hinzufügen kann und auch das Upgrade der VEM Module auf den ESXi Hosts. Hierfür muss davor natürlich das entsprechende File dem VSUM (über den Web Client) bereitgestellt werden – da gibt es leider noch keine direkte Cisco.com Integration :-/.

Wenn wir nun einen genauen Blick auf den ESXi Host werden können wir dort (wie auch mit dem Nexus 1000v) einige interessante Kommandos ausführen. Fangen wir mal mit etwas einfachem und bekannten an:

Dabei sehen wir, dass wir einen DVS mit dem Namen XXX-AVS01 haben, dem vmnic4 und 5 als Uplinks zugeordnet sind. Da wir ja mit der ACI Fabric über VXLAN sprechen, benötigen wir zumindest einen (besser zwei) VTEP (virtual Tunnel EndPoint), welcher uns die äußere IP Adresse, .. bereitstellt. Diese(r) VTEP(s) ist aus VMware Sicht ein normaler VMKernel Port mit der Besonderheit, dass dieser seine IP per DHCP von der ACI Fabric bekommt. Dieses Konzept ist gleichzusetzen mit der Erweiterung der ACI Fabric um weitere physikalische Leaf Switches und den Autoconfiguration/Plug’n’Play Gedanken, der mit ACI verbunden ist. Hierfür ist es notwendig, dass das Infrastruktur-VLAN (welches beim ACI Setup konfiguriert wird und alle (v)TEP Adressen der Switches beinhaltet) an die ESXi Hosts getrunked wird (da wir VXLAN sprechen, ist das auch das einzige VLAN, welches wir durchreichen müssen 😉 ).

Für die Konfiguration und diversen Informationsaustausch wird das Opflex Protokoll im Hintergrund verwendet. Um die Konnektivität optimal auszunutzen, werden im Fall von MAC-Pinning (und vPC im Hintergrund – wir erinnern uns, dass wir ein UCS dazwischen haben) – zwei VTEPs konfiguriert, welche jeweils den anderen Uplink verwenden (also Fabric A und Fabric B). Ok klingt mal super, wo kann ich das überprüfen? Wir probieren es mal auf der CLI 😉

Besondere Achtung geben wir auf die LTLs der VMKernel Interfaces und der PNICs.

Dabei können wir feststellen, dass die VTEPs die LTL 50 und 51 haben und die PNICs die LTL 23 und 22 haben. Beim letzen output können wir ebenfalls sehen, dass die ANSIBLE VM den LTL 55 besitzt über den VTEP mit der LTL 51 rausgeht, welcher die PNIC LTL 23 benutzt. Klingt mal etwas verwirrend und vor allem – ich seh ja keine LTLs in der VMware GUI :-(. Ein weiteres Show Command hilft uns da auch aus der Patsche:

Dieser Output liefert uns nun alle notwendigen Infos, damit wir uns auch in der VMware Welt zurechtfinden: LTL 23 entspricht der vmnic5 und der LTL 51 dem VMK2 Port.  Aber an dieser Stelle lassen wir das mal mit der CLI ein bisschen sein.

 

ACI VCENTER PLUGIN

Im vorigen Kapitel haben wir etwas unter die Haube der VXLAN / AVS Funktionsweise geschaut (VTEPs, LTLs, … ). Nun wieder zurück zu Klicki-Bunti – nämlich dem ACI vCenter Web Client Plugin. Dies ist – neben dem VSUM – das zweite Plugin, welches im Zusammenhang mit ACI (und auch AVS) steht – jedoch auch problemlos ohne AVS verwendet werden kann. Mit dessen Hilfe kann ich aus dem vCenter heraus meine EPGs, Netzwerke, … konfigurieren. Das besondere an diesem Plugin ist, dass es auch tatsächlich richtig gut funktioniert ;-). Kann ich alle ACI Tasks mit dem Tool erledigen? Sicher nicht – aber für die täglichen Tasks wie EPGs und Contracts anlegen bzw. bearbeiten ist es richtig brauchbar. Hier mal ein Screenshot zum Beweis (die Sinnhaftigkeit der verwendeten Namen und Contracts ist definitiv in Frage zu stellen 😉 ).

Dabei seh ich nicht nur die vorhandenen EPGs und Contracts sondern auch die Beziehungen untereinander und kann mit Drag-n-Drop auch wietere EPGs, … konfigurieren.

Weitere Konfigurations-, Monitoring und Troubleshooting Optionen sind ebenfalls über das Plugin möglich, würden aber langsam den Rahmen sprengen ;-).

 

WENN MAL ALLES GUT LÄUFT …

Leider hat sich die VMware Anfang April entschlossen, die vSwitch API aufzukündigen und somit alle 3rd Party vSwitch Hersteller – Cisco inklusive – vor Probleme zu stellen . Die Details können in dem VMware KB Artikel  2149722 (https://kb.vmware.com/selfservice/microsites/microsite.do?cmd=displayKC&docType=kc&externalId=2149722&sliceId=1&docTypeID=DT_KB_1_1) detailliert(er) nachgelesen werden. Wann wird es soweit sein? Ab vSphere 6.5 Update 2, welches mit Ende des Jahres erwartet wird, fällt der Support der API. Das bedeutet aber auch zugleich, dass die vSphere 6.0 Release weiterhin supported ist und eingesetzt werden kann. Diese Aktion ist für mich aus zwei Gründen etwas unverständlich:

 

  • Wieso schließe ich eine vorhandene und genutzte API?
  • Wieso wird dieser Schritt mit einem Update 2 eingeführt (welches ganz einfach über den VUM eingespielt werden kann) und nicht mit der nächsten Major Release?

 

Derzeit gibt es noch keine offizielle Stellungnahme seitens Cisco – wir werden Sie aber informieren, sobald es eine offizielle Aussage gibt. (Btw der vSphere 6.5 Support ist seit letzter Woche da 😉 )

 

FAZIT

Die Cisco ACI bietet viele Möglichkeiten die Anbindung der unterschiedlichen Hypervisor Architekturen (vSphere, HyperV, Openstack) zu bewerkstelligen. Im Gegensatz zum NSX ist der ACI Ansatz Hypervisor-übergreifend und ermöglicht die Abbildung derselben Policies (EPGs, Contracts, …) über Hypervisor-Grenzen hinweg, sowie auch in der physischen (nicht virtualisierten) Welt. Die Anbindung an die VMware Umgebung selbst bietet drei unterschiedliche Varianten, wobei jede ihre eigenen Vor- und Nachteile aufweist. Der AVS Weg, den wir uns heute genauer angeschaut haben, war (bis zum VMware Announcement) unserer Meinung nach definitiv der optimalere Weg, da sowohl die Konfiguration sehr gut funktioniert hat als auch die von uns durchgeführten Tests sehr vielversprechend waren. Dies bedeutet jedoch nicht, dass ACI nicht mehr mit VMware eingesetzt werden kann, sondern lediglich dass sich die Anzahl der Anbindungsoptionen reduziert hat. Für weitere Fragen betreffend ACI (oder auch des VMware Announcements) sind wir wie gewohnt zur Stelle.

NTS Man Admin
Chief Customer Officer
am 25.04.2017

Zum Thema