VMware NSX im Enterprise Data Center?

Das Announcement im Sommer letzten Jahres von VMware über seine Netzwerkvirtualisierungsplattform NSX (die Technologie, die aus der Nicira Aquisition hervorgegangen ist) hat einen regelrechten Hype um Overlay Technologien ausgelöst. Diese ermöglichen es den Server-Teams, ohne zusätzliche Netzkonfiguration (physicher Switches) neue Services auszurollen. Zu einem gewissen Maße sehe ich dies als eine Strategie, die orgnisatorischen Herausforderungen der System- und Netzwerkteams im Unternehmen zu bewältigen. Netzwerkteams entwickeln sich heute oftmals nicht in der selben “Geschwindigkeit” wie System/Server-Teams und mit NSX haben diese die Möglichkeit, die Problematik technisch zu umgehen. Die Arbeitsabläufe dieser beiden Teams oft nicht entsprechend eingespielt, automatisiert oder orchestriert. Aber es gibt auch heute schon Lösungen ohne Overlay Technologien für genau diesen Zweck – und wenn diese im Einsatz sind, dann wird auch das geforderte Level an Agilität und Effizienz erreicht, welches von einem Unternehmen verlangt wird.

Aber es bleiben auch hier offene Fragen: Macht es für ein Unternehmen Sinn, ein Overlay-Netz wie NSX im Data Center einzusetzen? Gibt es einen anderen Weg, um das Problem der Automatisierung und Orchestrierung zwischen Server und Netzwerk im Data Center zu lösen? Oder anders gesagt: Gibt es einen anderen Weg zum Software-Defined Data Center?

Ich denke für viele Szenarien ist die Antwort Ja – unsere Data Center Manager (DCM) Lösung wurde beispielsweise bereits bei mehreren Kunden erfolgreich implementiert, um genau diese Herausforderungen zu adressieren. Keiner dieser Kunden hat Probleme mit VLAN ID Begrenzungen, Größe der MAC-Adressen-Tabellen oder Schwierigkeiten mit zu vielen Paketen im Netz („Flooding“), was oft, neben der Abstimmung/Orchestrierung von physicher und virtueller Infrastruktur im Data Center, der Anfang ist, über eine Overlay-Lösung nachzudenken.

Als Hauptanwendungsgebiet für Overlay-Lösungen sind vor allem Cloud-Umgebungen zu nennen, da es hier eine große Anzahl von Kunden/Tenants (was zu einem hohen VLAN ID Verbrauch führt) und Server (was zu einer massiven Anzahl von MAC Adressen und Flooding führt). Die Kunden in diesem Segment können sich höchstwahrscheinlich die zusätzliche Komplexität erlauben, welche ein typisches, „normales“ Unternehmen sich nicht leisten kann (NSX Manager und API, NSX Controller, NSX Gateways und wahrscheinlich noch vSwitches (abhänhig von der Netzwerkumgebung) zusammen mit einer Reihe von neuen Protokollen wie VXLAN, STT, OpenFlow und andere)

Ein weiteres Argument pro Overlay ist die Mobilität von Virtuellen Maschinen, ohne die Layer 2 Domains zu erweitern oder gar neu designen zu müssen. Das ist ein Problem der Skalierung, was die heutigen virtuellen Switching- (VSB, M-LAG) und SPB- (Shortest Path Bridging) Lösungen – hauptsächlich auf Layer 2 – ausgerichtet auch adressieren. Neue VM Mobility Layer 3 Lösungen wie IP Host Mobility erweitert diese auf Layer 3 – zwischen IP Subnetzen. Aber wie immer hängt es davon ab, was der Kunde erreichen möchte. Eine Übersicht der verschiedenen Möglichkeiten finden Sie hier.

Letztlich sollte man immer daran denken, dass wir hier über IP Connectivity sprechen – wenn VPN, FW und Load Balancer (ADC) involviert sind, müssen auch diese entsprechend integriert werden. Denn nur den Overlay zu unterstützen, wird nicht helfen: Immer neue Gruppen von VPN, FW, ADC müssen pro Kunde/Tenant konfiguiert und orchestriert werden. Wenn man alles von einem Hersteller nimmt, das hat man ggf. eine integierte Loesung. Aber ist das ein Ziel?

Nichtsdestotrotz werden die nächsten Jahre zeigen, ob es spezielle Use Cases im Enterprise Data Center gibt, welche diese Lösungen nötig machen.