Cloud-Computing: Was ist eigentlich Software Defined Networking?
Wer sich mit Cloud-Computing und Lösungen wie Openstack oder Opennebula beschäftigt, stößt zwangsläufig auf Begriffe wie Software Defined Storage und Software Defined Networking. Die meisten Admins können sich zwar unter Cloud-Computing etwas vorstellen, wenn es aber um Software Defined Everything geht, stehen viele vor einem Rätsel.
Bei Software Defined Networking (SDN) gilt das besonders: Wer bisher Netze auf der Switch-Ebene und mit teurer Hardware von Cisco, Juniper & Co. gebaut hat, tut sich schwer mit der Vorstellung, diese Funktionalität virtuell zu implementieren. Es bedarf dringender Klärung: Wozu soll SDN eigentlich gut sein? Warum ist es eine unerlässliche Bedingung für große Cloud-Setups? Und wie sieht die technische Umsetzung des Prinzips konkret aus?
Virtualisierung ist allgegenwärtig
Software Defined Networking beschreibt die Virtualisierung sämtlicher Netzwerk-Aspekte in großen Computing-Umgebungen. Ähnlich wie beim Software Defined Storage, das üblicherweise in Form von Objektspeichern wie Ceph oder Swift daher kommt, bildet SDN also einen Teilaspekt des Betriebs von großer Infrastruktur auf der virtuellen Ebene ab. Ein kurzer Ausflug in die Geschichte der Virtualisierung hilft, die Bedeutung dieses Aspekts besser zu verstehen.
Denn der Begriff Virtualisierung ist in der IT eigentlich alt, schließlich existieren Lösungen wie VMware oder KVM seit Jahren und haben ihren praktischen Nutzen im IT-Alltag längst unter Beweis gestellt. Doch wann immer es in den vergangenen Jahren um Virtualisierung ging, war eigentlich die Virtualisierung von Rechenleistung gemeint. Ganz konkret also die Idee, überpotente Hardware dadurch sinnvoll zu nutzen, dass auf ihr einfach viele kleinere, virtuelle Systeme laufen. Computing hat der Virtualisierung in Rechenzentren insofern zum Durchbruch verholfen, aber es ist eben nicht der einzige wichtige Aspekt.
Die Art und Weise, wie Anbieter Netzwerk-Dienstleistung bei virtualisierten Systemen behandeln, macht das schnell deutlich: Jeder Kunde hat in seiner virtuellen Maschine (VM) zwar eine virtuelle Netzwerkkarte, die auch irgendwie mit der Außenwelt verbunden ist. Doch um alle Aspekte des Netzwerks außerhalb der VM muss sich der Anbieter kümmern. Regelmäßig passiert das in typischen Kernel-basedVirtual-Machine-(KVM)-Installationen dadurch, dass jedem Kunden ein Virtual Local Area Network (VLAN) zugeteilt ist und die virtuellen Netzwerkkarten (Network Interface Cards, NICs) der Kunden-VMs mit den jeweiligen VLAN-Interfaces verbunden sind. Aus Sicht des Anbieters ist das sowohl in Sachen Skalierbarkeit als auch in Sachen Wartung ein Alptraum: Will ein Kunde eine neue VM, ist Handarbeit durch den Anbieter angesagt. Schon die korrekte Konfiguration der Switches selbst verursacht in mittelgroßen Setups erheblichen Wartungsaufwand.
Nicht wenige IT-Planer behaupten vor diesem Hintergrund gern, dass klassische Virtualisierungsumgebungen das Thema Netzwerk de facto wie in konventionellen Umgebungen behandeln. Das Netzwerk solcher Setups sei also überhaupt nicht virtualisiert.
Clouds sind anders
Das ganze Konzept kann in Clouds nicht funktionieren, denn ein wichtiger Aspekt beim Cloud-Computing ist das Thema Selbstbedienung. Kunden wollen sich per Webinterface eine neue VM zusammenklicken und erwarten, dass sie nach wenigen Sekunden einsatzbereit ist. Wichtige Faktoren wie etwa die eigene Netzwerk-Topologie wollen Kunden in der Cloud selbst bestimmen. Zeit für den Anbieter, um in irgendeiner Weise händisch einzugreifen, gibt es also nicht. Stattdessen muss das Netzwerk direkt aus der Cloud-Umgebung heraus und in Übereinstimmung mit dieser konfiguriert sein.
Auch die Trennung von Kunden-Traffic auf der Hardware-Ebene ist wichtig: Sie darf nicht fehlen, denn Kunden dürfen die Pakete anderer Kunden nicht sehen. Klassische Technologien wie VLANs, die das bisher sichergestellt haben, sind aus den genannten Gründen in Clouds aber kaum nutzbar. Stattdessen sind die Hypervisors im Normalfall generisch. Eine VM muss also etwa auch von einem auf den anderen Host umziehen können, ohne dass ihr Netzwerk stirbt - etwa weil auf dem neuen Zielhost das passende VLAN nicht anliegt. Händisch konfigurierte Extrawürste von Hypervisoren oder Netzwerkhardware fallen dadurch aus.
Kurz gesagt: Sämtliche Management-Funktionalitäten, die bisher vorrangig auf spezieller Netzwerkhardware stattgefunden haben, müssen unmittelbarer Teil der Computing-Plattform werden.
Das Zauberwort heißt Entkopplung
Typische Netzwerkkomponenten wie Switches bestehen aus mehreren Teilen. Die Data Plane ist dafür verantwortlich, Pakete von einem Switch-Port hin zu einem anderen zuzustellen. Die Management-Fähigkeiten leistet hingegen die Control Plane. SDN basiert auf der Idee, die beiden Komponenten - Data und Control Plane - voneinander zu trennen: Switches liefern noch immer Pakete von einem Port zu einem anderen, doch die Control Plane und sämtliche zu ihr gehörende Funktionalität ist separiert von der Netzwerkhardware. Um das Ziel zu erreichen, teilen praktisch alle gängigen Lösungen am Markt das Netz in zwei Schichten auf: das Underlay und das Overlay.
Das Underlay bilden zusammen alle Hosts, die innerhalb des SDN-Setups einen Dienst betreiben (auch eine virtuelle Maschine gilt als solcher Dienst). Im Hintergrund sind die beteiligten Hosts mittels einer Tunnel-Technologie zu einem logischen Netzwerk-Segment verbunden, GRE (die Abkürzung steht für Generic Routing Encapsulation, also ein Tunnel-Protokoll) oder VXLAN (Virtual Extensible LAN, eine Weiterentwicklung des VLAN-Konzepts) sind hier Mittel der Wahl.
Auf dem Underlay basiert das Overlay: Innerhalb des Overlays sorgt die gewählte SDN-Lösung dafür, dass die Trennung zwischen den Kunden funktioniert, dass Pakete den Weg von einer VM zu einer anderen VM (auch auf einem anderen Hypervisor) finden und dass Dienste wie das Kommunikationsprotokoll DHCP und Internet in den VMs verfügbar sind. Kunden-VMs sind mit einer virtuellen Bridge im Overlay verbunden. Und weil praktisch alle SDN-Lösungen das Overlay komplett selbst verwalten, sind in ihm beliebige Konfigurationen möglich. Die physischen Switches sind in solchen Setups zu bloßen Data Planes degradiert, die Control Plane lebt im Overlay der SDN-Lösung.
Anforderungen auf der Software-Seite
Um den gewünschten Zustand zu erreichen, kombinieren marktübliche SDNs eine Vielzahl verschiedener Technologien. Die Wichtigste ist Open Flow(öffnet im neuen Fenster) , ein Standard für in Software implementierte Control Planes. Von Open Flow gibt es verschiedene Versionen, die Version 1.0 ist aber bis heute die mit der weitesten Verbreitung.
Allerdings ist Open Flow tatsächlich nur ein Standard, eine konkrete Implementierung ist in diesem nicht enthalten. Theoretisch wäre es also möglich, die Control Planes in Netzwerk-Switches per Open Flow zu steuern - doch entsprechende Geräte sind äußerst rar. Open vSwitch(öffnet im neuen Fenster) springt auf Linux-Systemen als Alternative ein: Neben diversen anderen Standards implementiert Open vSwitch vorrangig Open Flow 1.0 nebst diversen Erweiterungen auf marktüblicher Server-Hardware.
Die Abkürzung vSwitch steht für Virtual Switch: Auf Systemen, auf denen Open vSwitch zum Einsatz kommt, entstehen also virtuelle Switches mit eigener Control Plane. Sie hängen einerseits am physischen Interface, über das von anderen Hosts via GRE- oder VXLAN-Tunnel Pakete eingehen. Auf der anderen Seite docken die virtuellen Netzwerkkarten von VMs an diesen Switches an, um eingehende Pakete anderer Hosts zu empfangen. Im Underlay findet sowohl bei GRE als auch bei VXLAN ein Tagging statt, das klassischen VLAN-Tags ähnlich ist - allerdings heißen diese bei Open vSwitch IDs.
Im virtuellen Switch ist für jeden Port hinterlegt, zu welcher ID er gehört. Kommt also aus dem GRE- oder VXLAN-Tunnel ein Paket für die ID 15, leitet der Open-vSwitch-Switch auf dem Host das Paket nur an jene virtuellen Hosts weiter, deren Ports diese ID haben. In die andere Richtung funktioniert das Konzept auch: Das Paket einer VM, deren Port die ID 23 hat, bekommt von Open vSwitch die Tunnel-ID mit auf den Weg und geht dann durch das Underlay zum Ziel.
Auf diese Weise ist die Trennung auf Netzwerk-Ebene implementiert, die sonst per VLAN auf den Switches umgesetzt wäre. Tatsächlich bietet Open vSwitch das absolute Basis-Set an Funktionalität, um die typischen Cloud-Dienstleistungen zu realisieren.
Open vSwitch ist in Linux übrigens ein eigenes Kernel-Modul, das bereits im Upstream-Kernel enthalten ist. Jede halbwegs aktuelle Linux-Distribution ist deshalb in der Lage, Teil eines auf Open vSwitch basierten SDNs zu werden.
Am konkreten Beispiel: Openstack
Besser verständlich ist die Idee hinter SDN und Open vSwitch anhand eines konkreten Beispiels. Openstack bietet sich an: Eine typische Openstack-Cloud enthält alle Faktoren, die SDN sinnvoll und effektiv nutzbar machen. Hier müssen Kunden ihre Netzwerke selbst verwalten können und gleichzeitig muss es möglich sein, eigene VMs mit der Außenwelt kommunizieren zu lassen und öffentliche IPs zu vergeben. Traffic verschiedener Kunden darf sich dabei keinesfalls behindern. Außerdem muss die Kommunikation von VMs, die zum gleichen Kundennetz gehören, auch dann funktionieren, wenn die VMs auf unterschiedlichen Computing-Hosts laufen. Damit VMs innerhalb von Kundennetzen überhaupt mitspielen können, bedarf es einer mit der Cloud integrierten Lösung für DHCP.
In fast allen Szenarien existieren in einer Openstack-Cloud mindestens zwei Arten von Server-Typen: Controller-Knoten betreiben alle Dienste, die für Openstack selbst relevant sind, und Hypervisor-Knoten beheimaten die VMs, die Kunden per API oder Webinterface starten. Zudem kümmert sich in Openstack ein eigener Dienst um das Thema SDN. Dieser heißt Neutron und besteht aus vielen Komponenten.
Die Neutron-API enthält die gesamte Konfiguration und dient als Anlaufstelle für Clients, die die SDN-Konfiguration verändern wollen. Sie läuft auf den Controller-Knoten. Auf allen Servern arbeitet im Default-Setup der Layer-2-Agent für Open vSwitch. Dieser richtet auf Basis der Konfiguration in der API auf jedem Host die lokalen virtuellen Switches so ein, dass virtuelle Maschinen dort andocken können. Er sorgt auch dafür, dass die GRE- oder auch VXLAN-Verbindung zwischen allen Hosts funktioniert. Im Grunde ist es also die Aufgabe des L2-Agents, Underlay und Overlay herzurichten. Daher rührt auch der Name: Der L2-Agent schafft den "virtuellen" Layer 2 nach dem OSI-Modell, also die virtuellen Switches, mit denen sich VMs anschließend verbinden.
Auf den Controllern ist außerdem der DHCP-Agent zu Hause: Weil die Controller zum Overlay gehören, kann auf ihnen für jedes Kundennetzwerk ein DHCP-Server laufen. In Openstack ist das in der Standardkonfiguration übrigens dnsmasq.
Internet per Network Namespace
Nicht zu vergessen sind auch die Layer-3-Agents. Sie versorgen Kunden-VMs mit Internet. Ihr Name ist wieder ein Verweis auf das OSI-Modell: Die L3-Agents legen die virtuellen Router an, über die VMs die Welt außerhalb des eigenen Netzwerks erreichen. Damit das funktioniert, definiert der Anbieter ein öffentliches Netz, das ins Internet geroutet ist. Kunden können anschließend ihre privaten Netze mit diesem öffentlichen Netz verbinden. Auf Systemebene der Controller ist die Verbindung zwischen Kunden- und Public-Netzwerken per Network Namespace realisiert. Das ist eine Art virtueller Netzwerk-Stack des Hosts, dessen virtuelle Netzwerkkarten außerhalb des Namespaces unsichtbar sind. Network Namespaces sind ein Kernel-Feature, das alle aktuellen Systeme bieten.
Ist ein Network Namespace mit einem externen Netzwerk verbunden, gibt es darin sowohl ein Interface mit öffentlicher IP als auch eines mit einer IP aus dem Kundennetz, das im Hintergrund an Open vSwitch andockt. SNAT-Regeln (Source Network Address Translation, also IP-Masquerading) innerhalb des Namespaces bieten VMs die Möglichkeit, mit der Außenwelt zu kommunizieren. Soll eine VM über eine öffentliche IP erreichbar sein, wird diese IP im Network Namespace aktiviert und per DNAT (Destination Network Address Translation, also gezielte Paket-Weiterleitungen) an die private IP der VM durchgereicht, der sie zugewiesen ist. Der Clou: Anwendungen, die in einem Network Namespace gestartet werden, können diesen nicht verlassen. So sorgt Openstack dafür, dass Traffic von unterschiedlichen Kunden nicht kollidiert, selbst wenn diese öffentliche IPs aus den gleichen Netzen verwenden.
Übrigens: DNAT für die Erreichbarkeit per öffentlicher IP-Adresse führt zwar in regelmäßigen Abständen zu Verwunderung, ergibt im SDN-Kontext aber Sinn. Die Idee dahinter ist, einen Pool von IPs zu haben, aus dem sich Kunden nach Bedarf bedienen können. Denkbar wäre theoretisch auch, einzelnen VMs IPs fix zuzuweisen. Allerdings wissen vermutlich nicht alle Kunden, wie sie in ihren VMs überhaupt eine IP einrichten. Zudem verstößt das Prinzip, Kunden statische IPs seitens des Anbieters fest zuzuweisen, gegen das Gebot der maximalen Skalierbarkeit. Denn niemandem ist geholfen, wenn ein Kunde IP-Adressen bezahlen muss, die er eigentlich gar nicht braucht.
Das "Floating-IP"-Prinzip löst dieses Problem, indem es Kunden die Option gibt, einzelne IPs bei Bedarf zu reservieren oder wieder freizugeben. Verwalten lässt sich das in der Cloud aber nur dann ordentlich, wenn das gesamte Handling öffentlicher IP-Adressen auf der SDN-Ebene und außerhalb der VMs passiert. Obendrein ermöglicht das Floating-IP-Prinzip auch die einfache Migration von öffentlichen IPs hin zu neuen VMs. Das kann besonders bei Updates hilfreich sein: Wer ein neues MySQL ausrollen möchte, kann eine neue VM mit entsprechender Datenbank und passendem Datenstand im Hintergrund vorbereiten und am Tag der Migration einfach die IP auf die neue VM umstellen.
Das beschriebene Setup ist ein guter Beweis für die Möglichkeiten, die SDN in Clouds bietet. Denn Kunden können in diesem Konstrukt virtuelle Netze nach Gutdünken anlegen und mit der Außenwelt verbinden. Traffic verschiedener Kunden ist strikt voneinander getrennt, ohne dass es auf Hardware-Ebene kompliziert wird. Nach dem anfänglichen Setup entsteht für den Anbieter nur bei Updates oder Wartungsarbeiten Aufwand; im Alltag muss er sich mit dem Thema Kundennetze nicht weiter befassen.
Kommerzielle Lösungen bieten mehr Funktionalität
Das dargestellte Setup lässt sich übrigens mit Openstack-Bordmitteln völlig problemlos realisieren. Doch leidet solch ein Konstrukt unter verschiedenen Schwachstellen, die im Alltag mindestens zu Performance-Problemen führen, und zwar gerade in größeren Setups. Verschiedene Anbieter buhlen um die Gunst der Nutzer und wollen die Situation mit ihren eigenen SDN-Ansätzen verbessern: Juniper hat sich mit Contrail(öffnet im neuen Fenster) eine ganze SDN-Firma gekauft, Plumgrid(öffnet im neuen Fenster) und Midokura(öffnet im neuen Fenster) sind reine SDN-Anbieter, und VMware spielt bei SDN bereits seit Jahren eine Rolle.
Alle verfügbaren Eigenleistungen haben Stärken und Schwächen, so dass letztlich nur ein Vergleich vieler Lösungen Aufschluss gibt, welche für das eigene Setup am besten geeignet ist. Fest steht so oder so, dass Software Defined Networking viel weniger ein Hype ist als eine umfassende Umwälzung der Ideen, die Admins vom Netzwerk in Rechenzentren haben. Das Thema bleibt also auch auf lange Sicht spannend für jeden, der ein massiv skaliertes Virtualisierungs-Setup plant oder schon betreibt.
Martin Gerhard Loschwitz arbeitet bei Syseleven in Berlin. Er beschäftigt sich dort bevorzugt mit den Themen Openstack, Software Defined Networking und Software Defined Storage.