VXLAN (Virtual eXtensible LAN) – VMwares neuster Draft

Kommentieren Drucken

Auf der VMworld in Las Vegas hat Steve Herrod, Chief Technology Officer von VMware ein neues Infrastrukturprotokoll für virtualisierte Rechenzentren angekündigt: VXLAN steht für „Virtual eXtensible LAN“ und ist ein weiterer Ansatz, um die insbesondere von vMotion benötigten großen Layer-2-Netze zur Verfügung zu stellen.

Die Problematik ist hinlänglich bekannt:
Wird ein virtueller Server via vMotion verschoben, ändert sich zwar der Standort des Servers, aber eben nicht dessen IP-Adresse (zumindest nicht ohne weiteres und sicher nicht, wenn offene Verbindungen bestehen bleiben sollen). Um am neuen Standort weiterhin IP-Konnektivität zu gewährleisten, muss dort dasselbe Layer-2-Netz verfügbar sein wie zuvor am ehemaligen Standort. Um aber die volle Effektivität eines virtualisierten Rechenzentrums zu ermöglichen, ist es wünschenswert, dass vMotion auch über Rack- und letztlich sogar über RZ-Grenzen hinweg funktioniert. Dort befindet man sich aber bei vielen Betreibern in einem anderen Subnetz.

Damit steht man vor zwei Alternativen: Entweder man baut ein umfassendes und damit wahrscheinlich sehr großes Layer-2-Netz oder man realisiert Layer-2-Tunnel, durch die die Erreichbarkeit der „weg gewanderten“ VMs weiterhin möglich ist.

Jetzt sollte man ja meinen, dass es Lösungsansätze hierzu mittlerweile zur Genüge gibt, Layer-2-Tunnel sind beileibe keine neue Technologie. Um nur ein paar aktuelle Varianten zu nennen, auf die ich später noch kurz eingehen werde: Mit TRILL und 802.1aq konkurrieren gleich zwei so genannte „Shortest Path Bridging“-Technologien um die Vorherrschaft in Layer-2-Netzen ohne Spanning Tree und Cisco hat mit OTV („Overlay Transport Virtualization“) eine Lösung am Markt, die Layer-2-Netze in verschiedenen Rechenzentren über Layer 3 verbindet.

Warum also ein weiteres Protokoll?
Herrod fokussiert in seinem Blog-Beitrag zu VXLAN auf das eben beschriebene altbekannte IP-Adress-Problem: „One of the fundamental challenges with today’s networking is that we use an IP address for two unrelated purposes, as an identity AND as a location. Tying these together restricts a (virtual) machine from moving around as easily as we would like.“ und vergleicht die Situation mit der in Telefonnetzen vor der Einführung von Handys (siehe Bild 1).
(Gut, Herrod hat da etwas missverstanden: Telefonnummern sind nach wie vor im Wesentlichen ortsgebunden, sonst müssten er und wir keine Roaming-Gebühren bezahlen, dieser Punkt ändert sich erst mit der Einführung von (providerunabhängigen) SIP-URIs – aber das ist ein völlig anderes Thema.)


Für wesentlicher halte ich das Argument, das im gleichzeitig veröffentlichten IETF-Draft genannt wird:
Benutzergruppen, Anwendungsgruppen und gegebenenfalls sogar verschiedene Mandaten müssen in großen Rechenzentren netzwerktechnisch voneinander getrennt werden. Auf Layer 2 sind hierfür VLANs das Mittel der Wahl. Hierbei gibt es allerdings in der Praxis (mindestens) zwei Probleme:

  1. In den Netzen verschiedener Mandanten werden gleiche VLAN-IDs und gegebenenfalls sogar gleiche MAC-Adressen verwenden (vSphere generiert beispielsweise unter bestimmten Umständen gerne bestimmte MAC-Adressen).
  2. In großen Infrastrukturen genügen die maximal verfügbaren 4094 VLAN-IDs nicht aus. Hierbei muss man bedenken, dass in virtualisierten Umgebungen deutlich mehr VLANs benötigt werden als in klassischen Umgebungen, wo aufgrund physischer Server-Uplinks Netzsegmente leicht auch physisch voneinander getrennt werden können. Nehmen Sie beispielsweise eine 3-Tier-Anwendung: Wenn alle beteiligten Server virtualisiert sind, müssen die unterschiedlichen Tiers in der Regel mittels VLANs voneinander getrennt werden.

Beide Punkte sollen von VXLAN adressiert werden!

Darüber hinaus nennt der Draft zwei weitere Motivationspunkte:

  • In großen Layer-2-Netzen werden die Adresstabellen beispielsweise in ToR-Switches sehr groß, für manche Produkte zu groß.
  • Natürlich fehlt auch in diesem Draft der Hinweis nicht, wie ineffektiv der Einsatz des Spanning-Tree-Protokolls ist.

Protokolldetails
VXLAN ist ein „MAC-in-UDP“-Verfahren, das Frame-Format ist in Bild 2 dargestellt.


Der Original-Frame wird nacheinander um drei Header erweitert:

  • Der VXLAN-Header enthält im Wesentlichen einen 24 Bit Identifier. Damit können mehr als 16 Millionen VXLAN-Segmente unterschieden und somit deutlich mehr als mit 802.1Q-VLANs. Virtuelle Maschinen in verschiedenen VXLAN-Segmenten können nicht miteinander kommunizieren.
  • Der UDP/IP-Header sorgt dafür, dass der eingekapselte Frame über Layer 3 transportiert werden kann. Hierfür wird eine Zuordnungstabelle „innere Ziel-MAC-Adresse“ – „IP-Adresse des entsprechenden Tunnel-Endpunktes“ aufgebaut – dies geschieht wie üblich durch Lernen.
  • Und schließlich ein passender MAC-Transport-Header, der sich wie üblich beim Durchgang durch das IP-Netz regelmäßig ändert.

Die eigentliche Besonderheit des Konzepts ist, dass Broadcasts (und unbekannte Unicast-Adressen) mittels IP-Multicasts weitergeleitet werden. Damit auch diese Kommunikation innerhalb des VXLAN-Segments bleibt, erhält jedes VXLAN-Segment eine eigene IP-Multicast-Adresse. Diese Zuordnung von IP-Multicast-Adresse zu VXLAN-ID erfolgt laut Draft auf Management-Ebene und wird über einen nicht näher spezifizierten „Management Channel“ an die verschiedene VXLAN-Endpunkte verteilt werden („This mapping is done at the management layer and provided to the individual VTEPs through a management channel.“). Die Endpunkte selbst propagieren ihre jeweilige Zugehörigkeit zu bestimmten Multicast-Gruppen dann via IGMP an das Transportnetzwerk.

Das Verfahren definiert also pro VXLAN-ID je ein Layer-2-Overlay-Netz über ein Layer-3-Transportnetz und verbindet so alle Layer-2-Segmente, denen dieselbe VXLAN-ID zugewiesen wurde (siehe Bild 3). Segmente mit unterschiedlichen VXLAN-IDs sind völlig voneinander getrennt und können nicht miteinander kommunizieren. Daher spielt es auch keine Rolle, wenn in solchen Segmenten gleiche VLANs oder gleiche MAC-Adressen verwenden werden.

Was mit den oben angesprochenen „Management-Ebene“ und „Management Channel“ gemeint ist, wird deutlicher, wenn man liest, dass die VXLAN-Funktionalität innerhalb des Hypervisors gesehen wird! Hier setzt VMware wie üblich eine übergreifende Steuerungsschicht in Form eines vCenter Servers oder vCenter Clusters voraus, über den alle Hypervisor gesteuert werden. Im Prinzip sprechen wir an dieser Stelle über dieselbe Funktionalität, wie man sie von der „Distributed vSwitch“-Funktionalität kennt, bei der ja jetzt schon Switch-Parameter und Parameter von Portgruppen clusterweit synchronisiert werden. Daher ist es auch nicht weiter verwunderlich, dass Cisco praktisch am gleichen Tag erklärt hat, VXLAN in seiner speziellen Form des Distributed vSwitch, nämlich im Nexus 1000V unterstützen zu wollen.

Bewertung
VMware versucht mit dieser Lösung einmal mehr eine Netzwerkfunktion in den Hypervisor hineinzuziehen. Ich denke, das ist der falsche Weg. Standards wie SR-IOV (Single-Root I/O-Virtualization), VEPA (IEEE 802.1Qbg) und VN-Tag (IEEE 802.1Qbh) zeigen eine ganz andere Richtung, nämlich Netzwerkfunktion aus dem Hypervisor rauszuziehen und in die physische Switch-Hardware (zurück) zu verlagern. CPU-Kapazität des Hypervisor für Netzwerkfunktionen zu verschwenden, ist letztlich zu teuer und vermutlich auch zu ineffektiv.

VMware hat VXLAN natürlich nicht alleine und im Stillen entwickelt. Herrod nennt in seinem Blog explizit Cisco, Arista, Broadcom, Brocade, Emulex und Intel, als Autoren des Draft-Dokuments treten außerdem noch Citrix und Red Hat auf. Eine auf den ersten Blick beeindruckende Liste.
Trotzdem darf man skeptisch sein. Cisco hat, wie oben bereits erwähnt, die Unterstützung des Protokolls in der Nexus 1000V-Serie angekündigt, das sind aber wie VMwares dvSwitches virtuelle Switche! Es genügt aber nicht, VXLAN nur innerhalb der Hypervisor zur Verfügung zu stellen! Um Systemen, die via VXLAN angebunden sind, auch die Kommunikation mit der restlichen Welt zu ermöglichen, werden VXLAN-Gateways benötigt – und wenn man diese Funktionalität nicht ebenfalls über VMware abdecken möchte, braucht man also echte, physische Switche (Layer-3-Switche !), die VXLAN unterstützen.

Brauchen wir VXLAN?
Wie eingangs erwähnt, gibt es mit TRILL und SPB (IEEE 802.1aq) bereits zwei Protokolle, die vergleichbares über MAC-in-MAC-Tunnel leisten – und es gibt nicht nur die Spezifikationen dieser Protokolle sondern auch jetzt und heute verfügbare Produkte, die sie unterstützen.

TRILL hat allerdings das Problem, dass keine zusätzlichen VLANs zur Verfügung gestellt werden. Im oben skizzierten Sinn ist TRILL also nicht mandantenfähig. 802.1aq aber schon! 802.1aq beruht auf IEEE 802.1ah („Provider Backbone Bridging“) und bringt daher einen (ebenfalls) 24 Bit großen „Service Identifier“ mit, um Kunden-Infrastrukturen inklusive aller Kunden-VLANs vollständig vor der Backbone-Infrastruktur zu verbergen. Die oben formulierten Anforderungen „Mandantenfähigkeit“ und „mehr VLANs“ werden also mit SPB (IEEE 802.1aq) erfüllt.
Bleiben noch zwei Punkte: die Reduzierung der MAC-Adressen im ToR-Switch und der Transport über ein Layer-3-Netz. Punkt 1 lässt sich offensichtlich nur erfüllen, wenn die Tunnel vor dem ToR-Switch beginnen, und damit befindet man sich im Hypervisor. Das ist einerseits banal, andererseits erscheint das ganze Argument etwas an den Haaren herbeigezogen. Auch beim zweiten Punkt gibt es wenig zu diskutieren: Wenn man zwei Layer-2-Segmente über Layer 3 transparent verbinden will, muss man durch das übergeordnete Layer-3-Transportnetz tunneln – und das tun weder TRILL noch IEEE 802.1aq.

Und was ist mit Ciscos OTV? Die Frame-Formate von OTV und VXLAN sind äußerst ähnlich, OTV benötigt allerdings keine Multicast-Infrastruktur und ist damit etwas einfacher zu administrieren. Cisco wird aber erklären müssen, wie VXLAN gegenüber OTV positioniert wird. Oder wird OTV durch VXLAN abgelöst? Das erscheint mir durchaus denkbar.

zugeordnete Kategorien: Data Center, Virtualisierung
zugeordnete Tags:

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.