Im Vergleich: Cisco SDN und VMware Network Virtualisierung

Mit Cisco SDN und VMware Network Virtualization gibt es zwei Optionen für Software-basierte Netzwerke, die allerdings stark voneinander abweichen.

Software-defined Network-Produkte sind mittlerweile keine Zukunftsmusik mehr, sondern aktuell verfügbar. Im Zentrum des SDN-Marktes stehen Cisco und VMware, die beide ihre SDN-Strategien über die Akquisitionen von Insieme bzw. Nicira ausgerollt haben. Die VMware Network Virtualization ist eine Software-Lösung, während Ciscos Angebot eher auf Hardware basiert.

VMware Virtualization: Für jeden Hypervisor

VMware NSX gibt es als vSphere oder als Multi-Hypervisor-Version. Die vSphere Edition integriert sich in bestehende VMware ESXi-Umgebungen und baut auf den distributed Virtual Switch auf (dVS). Funktionen der Layer 4 bis 7, wie Routing, Firewall und Loadbalancing, werden aus der virtual Cloud Network Security (vCNS) heraus genutzt. 

Die Hypervisor-Edition bedient Citrix Xen und KVM, basierend auf Open vSwitch. NSX kann die Layer-2/3-Gateway-Dienste der Hardware von Herstellern wie Arista, Brocade und Juniper Networks nutzen, ist aber nicht an sie gebunden und funktioniert in jedem physischen Netzwerk. Das zwingt IT-Administratoren nicht dazu, sich strikt für einen Hersteller entscheiden zu müssen, um SDN-Funktionen in ein bestehendes Netzwerk zu integrieren.

Network Overlays mit VMware Network Virtualization umsetzen

Ein NSX-Controller-Cluster besteht aus mindestens drei logischen Systemen, die verschiedene Hypervisor-Funktionen aktivieren, beispielsweise Routing, Switchin oder Layer-7-Firewall-Schutz. Kontrolliert wird das Ganze über das NSX Manager Web Interface oder das NSX RESTful API. NSX baut auf der vSphere-Fähigkeit auf, Hosts einfach zu erstellen oder zu löschen und nutzt dies erweitert auf das gesamte Netzwerk. 

Logische Netzwerke, Firewalls, Routers und Loadbalancer können mit wenig Aufwand erstellt. Es bedarf lediglich der Dokumentation in Visio. Durch das Erstellen von Overlay-Netzwerken auf existierenden Switches wird ein Großteil der Komplexität vom physischen Netzwerk getrennt, da der Traffic über point-to-point-Verbindungen mittels Protokollen wie GRE, VXLAN (UDP Transport) oder STT (TCP-ähnlich) transportiert wird.

Allerdings hat diese Abstraktion auch ihre Nachteile. Zwar entfallen manuelle Änderungen, um neue Services aufzusetzen, das physische Netzwerk verliert aber seine Applikations-Layer-Übersicht. Es lassen sich Differentiated Services Code Point (DSCP)-Marker vom inneren zum äußeren Paket kopieren, letztendlich aber wird der Traffic das virtuelle Netzwerk verlassen und sich den Weg auf das physische Netzwerk bahnen. 

Traffic-Management-Komponenten wie Intrusion Detection-Sensoren, Paket-Shaper und WAN-Optimierer, die auf Layer 7 operieren, sehen den getunnelten Traffic nicht. Netzwerk-Management-Tools haben leider nicht die Flexibilität, beide Netzwerk-Layer zu verstehen und werden somit nutzlos. Diese Probleme lassen sich auf lange Sicht lösen. Hier ist ein Re-Engineering erforderlich, mit dem die meisten IT-Manager nicht gerechnet haben.

Alles neu mit Cisco ACI

Cisco ACI ist ein Framework an Hard- und Software und keine Software-Suite, um bestehende Netzwerke zu verschweißen. Basierend auf den Nexus-9000-Switches, wird es über Application Policy Infrastructure Controllers (APICs) kontrolliert. Die APICs sitzen außerhalb des Datenpfades und verbinden den physischen Nexus mit dem virtuellen Switch Nexus 1000v. Ein überzeugender Punkt von ACI ist das neu eingeführte Hierarchische Objekt-Model, das aus fünf Komponenten besteht:

  1. Tenants;
  2. Context (virtuelles Routing und Forwarding);
  3. End Point Groups (EPGs);
  4. End Points;
  5. Application Network Profiles.

Zugriffskontrolle, Service-Interagtion und QoS-Policies werden zwischen den EPGs definiert und über so genannte Verträge miteinander verbunden. Verschiedene Applikations-Tiers, wie zum Beispiel Web, Datenbank und Management, werden in Endpoint Groups zusammengefasst und zusammen als Application Networks Profile verwaltet.

Cisco SDN vs. NSX: Unterschiedliche Herausforderungen

Ciscos Hardware-Ansatz mag die Sichtbarkeits- bzw. Übersichtsprobleme lösen, die man in der NSX-Installation hat. Diese Möglichkeit einer zentralen Übersicht auf Underlay- und Overlay-Netzwerke wird sicher einige Unternehmen überzeugen. Um das zu erreichen, verlässt sich Cisco allerdings auf nur eine bestimmte Highend-Hardware, den Nexus 9000 Switch. 

Die Investition in solche Highend-Hardware mag viele abschrecken. Nicht jeder Anwender benötigt über 1.000 nicht-blockierende 10-Gbps-Ports und es wird eine Weile dauern, bis die Mehrheit diese wirklich braucht. Investitionsschutz ließe sich durch das Einbinden des Nexus 2000 Series Fabric Extender in die ACI-Lösung gewähren, vorausgesetzt der Nexus 9000 kommt auch zum Einsatz. 

Cisco selbst gibt an, dass Nexus 5000 und 7000 nach wie vor wichtig für die Netzwerk-Edges sind, aber dieses Argument ist für viele Anwender nicht überzeugend. SDN ist ein End-to-End-Ansatz, der langfristig greifen soll und somit sollte man als IT-Manager technologische Inseln vermeiden, da dies die Fähigkeiten der Software-basierten Lösung minimiert.

Was die Cisco-Lösung dennoch interessant macht, ist, dass ACI eine Option für viele schnell wachsende Infrastrukturen sein könnte, die über einen leistungsfähigen Switch, verbunden mit einem nativen Controller, verfügen. Darüber hinaus kann Cisco ACI als Technical Assistance Center-Paket anbieten, wenn sie ACI monolithisch aufbauen. Schaut man sich Ciscos Marketing an, so lässt sich daraus schließen, dass ACI-Installationen professionellen Service verlangen und nicht vom Anwender selbst umgesetzt werden können.

NSX auf der anderen Seite kann in vSphere integriert werden und mag so die besseren Budget-Argumente haben. Administratoren können testen, welchen Mehrwert SDN für ihr bestehendes Kit hat. Zwar lässt sich NSX sicherlich schneller umsetzen, Anwender müssen aber einen Weg finden, Overlay- und Underlay-Management zu verbinden, was bei den existierenden Tools nicht einfach ist. 

Will man mehr als nur eine Machbarkeitsstudie bzw. ein Proof-of-Concept, wird dies sicherlich Fragen bezüglich der physischen Infrastruktur aufwerfen, die sich nicht einfach beantworten lassen. Darüber hinaus ist das Preis-Konzept nicht ganz klar und es könnte teuer werden, je nachdem wie hoch der Preis pro VM bei einer NSX-Implementation letztlich wirklich ausfällt.

Letztendlich entstehen Netzwerke schrittweise. Die meisten Administratoren und Netzwerkarchitekten entscheiden entsprechend und bauen lieber auf den bestehenden Infrastrukturen auf, als wirklich alles einzureißen und neu aufzusetzen. Zumindest wird dies so sein, so lange sich SDN und Netzwerk-Virtualisierung noch nicht völlig durchgesetzt und technisch etabliert haben. Es ist denkbar, dass VMware sich schneller integrieren und umsetzen lässt, Cisco könnte allerdings auf lange Sicht doch noch die Nase vorn haben.

Über den Autor: 
Glen Kemp ist Enterprise Solution Architect für einen britischen Managed Service Provider. Er konzipiert und installiert Netzwerk- und Applikations-Tools. Dazu gehören Zugriffskontrolle, Remote-Zugriff, Firewalls und anderen Technologien, die „böse Buben“ von Netzwerken fernhalten soll. Er ist ebenso ein erfahrener Service Consultant. Seine Blogs finden Sie unter sslboy.net und unter Packet Pushers Podcast. Folgen Sie ihm auf Twitter @ssl_boy.

Folgen Sie SearchNetworking.de auch auf Facebook, Twitter und Google+!

Erfahren Sie mehr über Software-defined Networking

- GOOGLE-ANZEIGEN

ComputerWeekly.de

Close