Software-Definded Networking
Neue Netze
Herkömmliche Netzwerkgeräte tun sich schwer, die Dynamik von Virtualisierungs- und Cloud-Umgebungen angemessen abzubilden. Deshalb hat sich ein Industriekonsortium in der Open Networking Foundation (ONF) zusammengeschlossen, um einen neuen Ansatz zu propagieren: Software-Definded Networking (SDN) soll die Kontroll- und Datenebene entkoppeln und die Netzwerk-intelligenz zentralisieren, um Netzwerke flexibler zu machen - und nicht zuletzt herstellerunabhängig.
„Virtualisierung? Das machen wir doch schon längst“, argumentieren Netzwerkausrüster gerne und verweisen dazu auf die bewährten VLANs (Virtual LANs). In der Tat erlauben es VLANs, Netze für einzelne Kunden oder Benutzergruppen logisch zu trennen. Was VLANs jedoch nicht leisten, ist die vollständige Entkopplung der Hardware vom Betriebssystem, wie man dies von der Bare-Metal-Virtualisierung à la VMware Vsphere oder Citrix Xenserver von der Server-Seite her kennt. Zwar findet man in Carrier-Netzen das Konzept der „Virtual Router“, der klassische LAN-Switch ist heutzutage allerdings nach wie vor ein physisches Gerät. Und so monieren Kritiker, das Netzwerkequipment im LAN und RZ sei heute viel zu altbacken und monolithisch, um den neuen Anforderungen virtualisierter Server-Farmen oder Cloud-Umgebungen gerecht zu werden. Tatsächlich diskutiert die Gemeinde der Netzwerkausrüster derzeit intensiv, welche architektonischen Auswirkungen die veränderten Datenverkehrsmuster in virtualisierten und Cloud-Umgebungen auf Netzwerkseite bedingen: Statt des herkömmlichen „Nord-Süd-Verkehrs“ (also Traffic zwischen Clients und Servern) findet man hier verstärkt „Ost-West-Verkehr“ (also Datenaustausch zwischen Server-Instanzen) – und dies deutlich variabler und dynamischer als in herkömmlichen LANs. Deshalb hat heute jeder Anbieter von Cisco über Juniper, Brocade, Enterasys etc. bis hin zu IBM, HP und Dell sein eigenes Rezept, um diesem Wandel zu begegnen (zu IBMs Ansatz siehe den Beitrag auf Seite 36).
Netze stoßen an Grenzen
Im Non-Profit-Industriekonsortium ONF (Open Networking Foundation) reichen die Überlegungen aber noch einen deutlichen Schritt weiter: Hier geht man davon aus, dass die aktuellen Marktanforderungen mit traditionellen Netzwerkarchitekturen überhaupt nicht bedient werden können. Denn heutige Netze, so das ONF, sind zu komplex und damit zu starr, um sich dynamisch wandelnden Bedingungen von Cloud-Services, virtualisierten Applikationen und Big-Data-Verkehr rasch genug anpassen zu können. Die aktuelle Netzwerktechnik nutzt eine Reihe von Protokollen und Mechanismen, die das Ethernet-basierende Networking zwar flexibel einsetzbar machen, dies aber zum Preis eines beträchtlichen Konfigurationsaufwands. Zur Einrichtung eines neuen Netzwerks sind diverse Geräte wie Switches, Router und Firewalls manuell oder mit Netzwerk-Management-Tools auf Geräteebene einzurichten; zudem gilt es, zahlreiche Parameter wie Authentifizierungsdaten, ACLs, VLANs, QoS (Quality of Service), Priorisierung etc. ebenfalls auf Device-Ebene vorzugeben, um das ungestörte herstellerübergreifende Zusammenspiel der Netzwerkkomponenten zu garantieren. Das Ergebnis ist im besten Fall ein leistungsfähiges, stabiles und hochverfügbares Netzwerk – aber eben zugleich ein komplexes Gebilde, das der Administrator gemäß dem altbewährten Leitsatz „Never touch a running system“ möglichst nicht mehr anfasst. Zu groß scheint das Risiko, durch eine Rekonfigration Inkonsistenzen, Loops oder Sicherheitslücken zu provozieren. Dieser statische Charakter des Netzwerk-Managements war lange Zeit unproblematisch, ist aber angesichts virtualisierter Umgebungen mit automatisierten VM-Migrationen (etwa durch VMware Vmotion) nicht mehr zeitgemäß. Insbesondere die großen Cloud-Service-Provider mit ihren Mega-Rechenzentren haben dies zu spüren bekommen, da hier der stark – und vor allem nur schwer absehbar – schwankende Daten-Traffic vom Netzwerk eine sehr flexible und hohe Skalierung erfordert, bis hin zum so genannten „Hyperscale Networking“.
Radikaler Schnitt
Deshalb diskutiert man beim ONF nicht, wie man Three-Tier-Netze zu Two-Tier-Netzen komprimieren oder auf andere Art Latenzzeit einsparen kann. Vielmehr propagiert das Konsortium einen radikalen Wechsel: die vollständige Trennung von Kontroll- und Datenebene. Man will die Netzwerkintelligenz von den Switches entkoppeln und stattdessen an zentraler Stelle vorhalten. Die vom ONF vorgeschlagene Netzwerkarchitektur sieht wie folgt aus (Bild 1): Die Netzwerkintelligenz wird logisch im Control Layer in Form von softwarebasierenden SDN-Controllern zentralisiert. Diese SDN-Controller dienen somit als Dreh- und Angelpunkt, von dem aus der Administrator alle Einstellungen für das Netzwerk vorgibt. Die Netzwerkgeräte werden damit zu reinen Forwarding-Maschinen, die ihre Befehle von der externen Steuerungsinstanz entgegennehmen, statt selbsttätig zahlreiche Protokolle abzuarbeiten. Charmant ist an diesem Ansatz aus Anwendersicht nicht nur, dass er das Design und den Betrieb des Netzwerks stark vereinfachen kann. Vielmehr ist ein SDN prinzipiell herstellerunabhängig. (Juniper hat mit seinem Qfabric ebenfalls bereits Data Plane und Control Plane entkoppelt, allerdings als proprietäre Einzellösung.) Ein Unternehmen wäre mit SDN nicht mehr von den Innovationszyklen seines Netzwerklieferanten abhängig – und auch nicht von dessen Preisstruktur. Bekanntlich ist Cisco seit Jahren stark darum bemüht, möglichst viel Intelligenz in die Cisco-Netze zu packen. Ein SDN ist dazu der vollständig gegenteilige Ansatz, degradiert es die Switches doch zu „dummen Transporteseln“. Entsprechend kann man das SDN-Konzept auch als einen Angriff auf Ciscos Vorherrschaft im LAN verstehen: Die Forwarding-Intelligenz ist in Software abgebildet und damit im kostengünstigsten Fall auf Standard-Servern; auf der Switch-Seite genügen dann wiederum schnelle, aber einfache Geräte. Ebenso reizvoll am SDN ist für den Administrator, dass nur noch das Control Layer zu konfigurieren ist, um zum Beispiel neue virtuelle Server als Netzwerkknoten einzubinden oder neue Applikationen priorisiert zu behandeln: Die Kontrollebene dient in der SDN-Architektur als intelligentes Provisionierungs- und Orchestrierungssystem, das für die echtzeitnahe und netzwerkweite Umsetzung der Netzwerk-Policies sorgt. Das manuelle Codieren von Netzwerkgeräten entfällt vollständig. Zur Kommunikation zwischen Kontrollschicht und den Applikationen bedient sich ein SDN verschiedener APIs, zu der zwischen Infrastrukturkomponenten und dem Control Layer sieht das SDN-Konzept ein „Control/Data Plane Interface“ vor. Diese Kommunikation läuft über das Protokoll Openflow – bislang das erste und damit einzige offene SDN-Protokoll, das es tatsächlich schon gibt. Openflow ermöglicht es, das Netzwerk pro Flow zu programmieren und erlaubt somit eine wesentlich granularere Kontrolle über das Netzwerkverhalten als das traditionelle Switching und Routing, so die Argumentation des ONF.
Markt im Umbruch
Dass Software-Defined Networking kein Hirngespinst ist, sondern immer mehr Akzeptanz findet, ist leicht daran zu erkennen, dass SDN derzeit den Netzwerkmarkt ordentlich durcheinanderwirbelt. So hat Virtualisierungsschwergewicht VMware im Juli den SDN-Spezialisten Nicira zum stolzen Preis von 1,26 Milliarden Dollar gekauft – und dies, obwohl Niciras Lösung NVP (Network Virtualization Platform) gerade einmal ein halbes Jahr alt ist. Allerdings kann Nicira bereits bekannte Namen wie AT&T, NTT und Rackspace als Referenzen vorweisen. Die kostspielige Übernahme zeigt: VMware hat erkannt, wie wichtig das Netzwerk für künftige Cloud-Rechenzentren ist. Ein Schritt zu mehr Offenheit in der Cloud – auf den Spuren von Google, deren interner Backbone vollständig auf Openflow basiert. Die Akquisition war ein Paukenschlag, der den Markt in Schwung brachte: Immerhin sah sich Oracle genötigt, nur wenige Tage später die Akquisition des Nicira-Konkurrenten Xsigo Systems bekanntzugeben. Citrix wiederum hat im Mai seine Cloudplatform auf der Basis von Apache Cloudstack vorgestellt, welche die SDN-Controller-Funktionalität von Xenserver 6.0 nutzt. Zusammen mit dem hauseigenen ADC Netscaler seien künftig sogar „App-Aware SDNs“ möglich. Ansonsten sieht Citrix VMwares Akquisition gelassen, denn der SDN-Markt entwickle sich nur relativ langsam. Cisco hat aber bereits Openflow-Unterstützung angekündigt und in den SDN-Anbieter Insieme investiert, Juniper will binnen Jahresfrist SDN-Produkte vorstellen. Vom Openflow-Protokoll und Startups wie Nicira abgesehen ist vieles am SDN-Konzept bislang noch guter Vorsatz. Aber das Engagement von VMware, Oracle und Co. zeigt, dass wichtige Player große Hoffnungen auf Software-Defined Networking setzen. Man darf also gespannt sein, wie schnell sich das Netzwerk-Business der schönen neuen Welt der offenen, dynamischen Cloud-Umgebungen annähern wird. SDN bietet jedenfalls die Möglichkeit, dass sich ganz neue Player am Markt etablieren, die eine Cloud-gerechte Steuerung von Netzwerken bieten – abseits bekannter Switch- und Router-Produzenten. Der Autor auf LANline.de: wgreiner
Lesen Sie mehr zum Thema
