Hardware-Unterstützung von Overlay-Netzen

Kommentieren Drucken
Teil 10 von 11 aus der Serie "Chip, Chip, Hurra"

Ohne die Hardware-Unterstützung für VM-orientierten virtuellen Speicher in Virtualisierungsumgebungen wäre ein Virtualisierungskonzept völlig uninteressant. Genauso verhält es sich mit der VM-Kommunikation, die man nicht alleine überforderten Softswitches überlassen kann. Niciria/VMware trennt im Rahmen seines SDN-Konzeptes das Netz durch die Einführung von Tunneln völlig von der VM-Ebene. Also muss es Hardware-Unterstützung für Tunnel-Overlays geben. Sehen wir uns an, wie der BCM 56640 das macht.

Die konkreten Vorstellungen von Niciria hinsichtlich des Aussehens einer virtualisierten Kommunikationslösung hatte ich in meinem Artikel „SDN- was macht eigentlich Niciria?“ vom 4.3.2013 ausführlich dargestellt. Da Niciria von VMware übernommen wurde, haben sie besonderes Gewicht. Letztlich wird vom Hardware-Netz verlangt, dass es Tunnel unterstützt, nicht mehr und nicht weniger. Obwohl VMware primär VXLAN unterstützt, wird sich ein Chip-Hersteller nicht auf ein einziges Tunnelprotokoll beschränken.

Zur Bildung von Virtualisierungslösungen im Cloud-Scale unterstützt Broadcom Tunnel-Protokolle wie L2GRE, VXLAN und NVGRE in Hardware. Obwohl diese Protokolle unterschiedliche Initiatoren haben und unterschiedlich weiterentwickelt werden, haben sie doch eine gemeinsame Auswirkung auf die Ethernet-Switching-Ebene, die zusammnefassend als L2oL3-Overlay bezeichnet werden kann. In einer Frage ergeben sie ein generisches Paketfeld bestehend aus dem L2GRE, VXLAN oder NVGRE-Header und einer Tunnel-ID. (siehe Bild 1)

Die Theorie ist jetzt, dass eine derartige Konstruktion Netzwerk-Virtualisierung und Multimandantenfähigkeit unterstützt. Voraussetzung dafür ist aber, dass alle Switches komplette L2oL3-Switches sind. In der Praxis wird es aber meist so sein, dass die Tunnel End Punkte (TEPs) diese Funktion, zur Kommunikation Tunnel zu benutzen, nicht immer haben. Beispiele wären native Linux- oder Windows-Server, die Prozesse, die nativ zur Prozess-Ebene dieser Server gehören, wie die zur VM-Migration benötigten Migrations-Hifls-Prozesse, ein älterer Hypervisor, eine Load Balancing Appliance usw. In all diesen Fällen benötigt man L2oL3-TEP Gateways. Die können auch dann hilfreich sein, wenn einige Teile eines Netzes noch keine Tunnel-Funktionalität unterstützen.

In Bild 2 sehen wir eine solche mögliche Situation. Es gibt Server, die schon Tunnel-Protokolle beherrschen (grüner Punkt) und solche, für die das nicht zutrifft. Diese müssen dann mit TEP-Gateways in den ToR-Switches versorgt werden.

Das Bild 3 zeigt das RZ-Netz eines Cloud-Providers, welches Mehr-Mandantenfähigkeit unterstützt und Verbindungen zu den RZs der unterschiedlichen Mandanten unterhält. Man sieht die Nutzung von L2oL3 Transit Switches und TEP-Gateways für diese hybriden Mehrmandanten-Umgebungen. Die Schattierung unterlegt ein flaches virtuelles L2-Segment eines Mandanten A, welches die VM Life Migration und andere von L2 abhängige Funktionen über das Netz des Mandanten und die RZ-Struktur des Cloud-Providers ermöglicht. Die andere Schattierung zeigt das Gleiche für Mandant B. In der Abbildung gehen wir zur Vereinfachung davon aus, dass das L2-Segment aus Servern besteht. Man kann natürlich die Multi-Mandanten-Granularität auch bis zur VM-Ebene durchziehen.

Anforderungen an einen L2oL3 Transit-Switch
Zur Vereinfachung der Darstellung gehen wir wieder von einem generischen Paket-Format aus und lassen die kleinen Unterschiede zwischen L2GRE, VXLAN und NVGRE beiseite. Das L2oL3-Paket besteht aus einem äußeren Header, einem inneren Header und der Nutzlast. Das Format variiert entsprechend der verschiedenen Spezifikationen für die genannten Tunnel-Protokolle. Die Smart-NV-Technologie von Broadcom erkennt den Protokolltyp automatisch und kann daher enkapsulierte Protokolle aller drei Protokolle bearbeiten und transportieren.

Der innere Header des L2oL3-Paketes enthält VM-spezifische Netzwerk-Adressierung und QoS-Anforderungen. Smart-NV ermöglicht VM-Level Granularität bei den Netzwerk-Services wie Class of Service, Sicherheit, Load Balancing, Link Aggragation usw., die von dem L2oL3-Switch angeboten werden. Basierend auf dem Inhalt des inneren Headers muss der Switch in der Lage sein, Klassifizierungen und Hash-Funktionen auszuüben. Vom äußeren Header muss er Entropie-Informationen (z.B. für Fehlererkennung oder verlustfreie Datenkompression) sammeln und anwenden. Zudem muss er in der Lage sein, Queuing und Shaping-Regeln auf VM- und Mandanten-Ebene durchzusetzen.

Für Multi-Mandanten-Netze müssen entsprechende Isolationen und Sicherheitsfunktionen implementiert werden. Und alle diese Funktionen müssen natürlich in Line Rate ausgeführt werden !

Die Arbeitsweise des Netzes muss auf der Mandanten-Ebene überwacht werden können. Dazu muss der L2oL3 Transit Switch in der Lage sein, entsprechende Pakete an Überwachungs- oder Spiegelports zu schicken.

Bestimmte Implementierungen der Netzwerk-Kontrollschicht für ein L2oL3 Overlay-Netzwerk benötigen einen Adress-Auflösungs- und –Konsolidierungsmechanismus, der auf IP Multicast basiert. Das bedeutet, dass alle L2oL3 Transit-Switchs auf dem Datenweg IP Multicast Features unterstützen müssen. Die Anzahl der möglichen IP Multicast-Einträge, die von einem L2oL3-Switch unterstützt werden, bestimmt die Skalierbarkeit des Netzes hinsichtlich der Anzahl der Tunnel und Mandanten, die von diesem Netz unterstützt werden können. Z.B. können existierende L2-Meachnismen wie Flooding und dynamisches Lernen von MAC-Adressen dazu benutzt werden, um externe MAC-Adressen zu entdecken und entsprechende MAC-zu-TEP-Abbildungen vorzunehmen. IP Multicast kann dazu benutzt werden, den Bereich, über den das Flooding ausgeführt wird, auf die Hosts zu beschränken, die ein Interesse an der Nutzung der Tunnel-Mechanismen haben. Jedes Overlay-Segment kann auf eine IP-Multicast-Adresse abgebildet werden, um so das L2-Flooding auf die Host zu begrenzen, auf denen die VMs arbeiten, die an dem gleichen Overlay-Segment teilnehmen. In großen Umgebungen können IP-Multicast Adressen aggregiert werden, wenn die Zahl der durch die Transit-Switches unterstützten IP-Multicast Adressen für eine derart individuelle Lösung nicht ausreicht. Broadcom Switches mit Smart-NV haben aber aktuell die größten IP-Multicast-Adresstabellen in der Industrie.

Im Gegensatz zum traditionellen Multicast, bei dem eine Wurzel (Sender) Informationen an eine Menge von Zweigen (Empfänger) verteilt, ist im Falle der L2oL3 Overlay Netze der Tunnel ein Multicast-Baum mit VMs als Endpunkten und die teilnehmenden VMs können sowohl Sender als auch Empfänger sein. Multicast-Trees, die als L2oL3 Tunnel fungieren, müssen daher ein skalierbares und leistungsfähiges bidirektionales Multicast-Modell unterstützen. Smart-NV erlaubt hier eine maximale Skalierung und hohe Leistung durch Hardware-Unterstützung.

Anforderungen an L2oL3 TEP-Gateways
Ein L2oL3 TEP-Gateway muss alle Funktionen eines L2oL3 Transit Switches unterstützen. Zusätzlich ist seine Funktion die Herstellung einer Verbindung zwischen der neuen auf Tunneln basierenden Netzwerkumgebung und älteren Komponenten, die diese Umgebungen gar nicht kennen. Ein Netzwerk-Switch, der zwischen dem Overlay-Netz und den älteren Komponenten sitzt, muss eine TEP Gateway-Funktion implementieren. Für Pakete, die aus dem Overlay-Netz in eine ältere Umgebung gehen, muss das Gateway die enkapsulierten Tunnel-Pakete auspacken. Dieser Übergang führt zu neuen L2- und L3-Forwarding-Aktionen.

Für die L2-Forwarding Aktionen zwischen einem Tunnel-Netz und einer älteren Umgebung muss das TEP Gateway die L2oL3 Tunnel-ID (also z.B. die VXLAN ID) in eine passende VLAN-ID oder eine Kombination aus MAC-Adresse und Port übersetzen und vice versa. Es kann auch vorkommen, dass das TEP Gateway als Bridge zwischen zwei Netzwerk-Overlay-Segmenten fungieren muss. In diesem Fall sind die Tunnel-Ids der zwei Segmente unterschiedlich. Eine solche Situation kann z.B. auftreten, wenn zwei Segmente in zwei unterschiedlichen RZs liegen. In diesem Fall muss das TEP-Gateway, welches an einer RZ-Netz-Kante sitzt, die Tunnel-IDs aufeinander abbilden können.

Komplexere L3-Forwarding-Aktionen können z.B. dann entstehen, wenn das TEP-Gateway einen L2oL3-Tunnel und das L3-Segment, welches zu diesem Tunnel gehört, terminiert. Das Forwarding der Information nach Verlassen des Tunnels basiert auf der angegebenen L3-Zieladresse. In der anderen Richtung müssen IP-Pakete in das Tunnelformat enkapsuliert werden. Moderne RZ-Switches bieten ein „Inter-VLAN-Routing“ an. Dem entsprechend muss ein TEP-Gateway ein „Inter-L2oL3-Segment-Routing“ implementieren können.

Eine wichtige Design-Frage ist es, an welcher Stelle die TEP-Gateways implementiert werden. In den Abbildungen haben wir ja schon verschiedene mögliche Positionen z.B. in der Nähe eines Servers und an der Netzkante gesehen. Die Positionierung hat u.a. einen Einfluss auf die Leistungsfähigkeit einer VM-Migation. Wichtig ist, dass ein Switch-ASIC für alle möglichen denkbaren Fälle unterschiedliche Bandbreiten und Portraten anbietet, um für jede Positionierung die optimale Lösung anbieten zu können.

Konsequenzen für die Netze in Unternehmen und Organisationen
Bei ihrem Erscheinen wurden die Tunnel-Protokolle für den Einsatz im Bereich von Virtualisierungstechniken mit Recht heftig kritisiert. Ich verweise in diesem Zusammenhang auf den hervorragenden Artikel von Herrn Höchel-Winter im Insider ?/2012.

Blickt man aber genau hin, ergeben sich eigentlich nur drei grundsätzliche Problembereiche mit diesen Overlay-Protokollen:

  • die Befürchtung, dass diese Protokolle zusätzlichen leistungsmindernden Overhead erzeugen
  • die Tatsache, dass die Overlay-Protokolle zu manchen älteren Konstruktionen und Kombinationen überhaupt nicht passen wollen und deshalb nicht überall so funktionieren, wie man sich das eigentlich vorstellt
  • die berechtigte Befürchtung, dass die Festlegung auf ein Overlay-Protokoll, wie z.B. VXLAN, dazu führt, dass man eine Virtualisierungs-Software, die ausgerechnet dieses Protokoll nicht unterstützt, wie z.B. im Fall von VXLAN Microsoft Hyper-V nicht mehr einsetzen können wird

All dies ist absolut berechtigt, aber eine Hardware-Unterstützung wie sie z.B. vom BCM 56640 realisiert wird, lässt die Probleme verschwinden:

  • eine Hardware-Unterstützung von Overlay-Protokollen in Line Rate stellt zusammen mit anderen Mechanismen zur Unterstützung der VM-Kommunikation die schnellste denkbare Alternative dar. Noch schneller als Line Rate braucht niemand!
  • durch die vielfältige Unterstützung von L2- und L3-Strukturierungsverfahren lassen sich die mit einem BCM 56640 ausgestatteten Access-Switches mit hoher Wahrscheinlichkeit auch problemlos in ein bestehendes L2 oder L3-Core-Netz einbinden, sofern dies die schon länger üblichen Standard-Verfahren benutzt.
  • welches Overlay-Protokoll konkret benutzt wird, interessiert den BCM 56640 nicht, weil seine primären Funktionen auf dem dargestellten generischen Format beruhen und die notwendigen Umsetzungen zwischen den spezifischen Protokollen und dem generischen Format sehr einfach in Hardware durchgeführt werden können. Obwohl es aus betrieblichen Aspekten weder wünschenswert noch letztlich sinnvoll ist, könnte man auch unterschiedliche Overlay-Verfahren parallel benutzen.

Da sich die Hersteller Integrierter Schaltungen üblicherweise gegenseitig nicht das Grünzeug in der Boullion gönnen, ist in Kürze mit weiteren Produkten zu rechnen, die die Bildung von Overlay-Strukturen direkt in Hardware unterstützen. Der FM 7000 von Intel kann schon heute IP-Tunnel für IPv4 und IPv6 bilden. Die innere Parsing-Struktur für ankommende Pakete ist sehr flexibel und kann mit Sicherheit relativ leicht an die Bedarfe der Overlay-Protokolle angepasst werden. Wahrscheinlich wird der FM 8000 das bereits können.

Durch die Verfügbarkeit einer Hardware-Unterstützung für Overlay-Konzepte verlieren die Bestrebungen von Niciria/VMware ihre Schrecken, die sie zur Zeit noch verbreiten. Wenn Sie jetzt gar keinen Zugang zu den Switch-ICs haben, stellen Sie sich den BCM 56640 einfach als Schweizer Berg mit von der Natur vorgefertigten Tunnelröhren vor und überlegen Sie dann, wie Ihnen das beim Straßen- und Eisenbahnbau helfen könnte.

« Teil 9: Weitere Hardware-Entwicklungen


zugeordnete Kategorien: LAN
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.

*

.