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.