Das Netz wird programmierbar

IT-Verantwortliche kommen nicht zur Ruhe. Unter anderem deshalb, weil sie sich derzeit mit einer ganzen Reihe von Hype-Begriffen auseinandersetzen müssen: von Cloud Computing über den Einsatz privater, mobiler Endgeräte im Unternehmen (Bring your own Device) bis hin zu Data Center Fabrics. Und 2013 erwartet sie ein weiteres heißes Thema: Software Defined Networking (SDN). Entsprechend euphorisch geben sich einige Marktforschungsinstitute. IDC geht beispielsweise davon aus, dass der weltweite Umsatz mit SDN-Produkten 2013 bei 200 Millionen Dollar liegen wird. Bis 2016 soll er auf mehr als zwei Milliarden Dollar steigen.

Skeptischer zeigt sich dagegen Andre Kindness, Principal Analyst bei Forrester Research: "SDN-Lösungen und entsprechende Produkte benötigen noch etwa fünf Jahre, bis sie für den Einsatz in Enterprise Networks reif sind." Er moniert unter anderem, dass es bei SDN aufwendig sei, Netzwerkkomponenten miteinander zu koppeln, vorhandene Management-Systeme zu integrieren, die Verwaltung von Hypervisors einzubinden und das Ganze auf Netzwerk-Services abzustimmen, die auf den Ebenen 4 bis 7 des ISO/OSI-Modells angesiedelt sind.

Nur ein Hilfsmittel?

Auch Stuart Bailey, Gründer und Chief Technology Officer von Infoblox, einem Anbieter von Produkten für die Automatisierung von Netzwerken, hält die überschäumende Begeisterung für SDN für wenig hilfreich: "Der Hype ist problematisch und sorgt für Verwirrung. SDN sollte vielmehr als Hilfsmittel gesehen werden, mit dem sich konkrete Herausforderungen im Netzbereich bewältigen lassen, etwa im Bereich Big Data", so Bailey in einem Gespräch mit dem Online-Community-Portal "SDN Central".

SDN ist kein neues Konzept

Software Defined Networking beziehungsweise Software Defined Networks sind kein brandneues Konzept. Es findet beispielsweise in Wireless LANs Verwendung, in denen ein WLAN-Controller vorhanden ist. Ebenso sind in MPLS-Netzen (Multi-Protocol Label Switching) SND-Methoden zu finden. Das bestätigt Markus Nispel, Chief Technology Strategist bei Enterasys: "Bereits in den 90er Jahren gab es mehrere Unternehmen, die softwarebasierte Netzarchitekturen auf ihre Tragfähigkeit hin untersuchten, darunter auch Enterasys. Wir ließen das Projekt fallen, weil der damalige Ansatz nicht die erforderliche Skalierbarkeit bot."

Im Vergleich zu herkömmlichen Netzwerk- und Switching-Architekturen weisen Software Defined Networks einige Besonderheiten auf. Die gravierendste ist die Trennung der Control Plane von der Data Plane beziehungsweise Forwarding Plane auf Layer 2 und 3 von Switches und Routern, also die Separierung von Kontroll- und Datenpfad.

Die Control Plane ist für die Konfiguration eines Switchs beziehungsweise Routers zuständig, außerdem für das Programmieren der Pfade, über die Daten transportiert werden. Bei SDN wird die Control Plane gewissermaßen aus Switches und Routern extrahiert und in ein separates System verlagert - den SDN-Controller.

Kernelement: der SDN-Controller

Ein SDN-Controller ist nicht an eine bestimmte Form gebunden. Es kann sich um einen physischen Server handeln, aber auch um eine Virtual Machine oder eine Hardware-Appliance. Der Controller gibt der Forwarding Plane vor, wie sie mit Datenpaketen umgehen soll, also wohin (an welchen Port) die Pakete übermittelt werden sollen und mit welcher Priorität das erfolgen muss.

Die Forwarding Plane übermittelt diese Regeln wiederum an die applikationsspezifischen ICs (ASICs) im Router oder Switch. Vereinfacht gesagt: SDN separiert Entscheidungen, welche die Weitervermittlung von Paketen und Regeln (Policies) betreffen, von der Netzwerktopologie und der Transportebene.

Unterschiedliche Ansätze

Die Kommunikation zwischen Controller und Infrastrukturebene (Data/Forwarding Plane) erfolgt über ein spezielles Protokoll. Hier kommt derzeit vor allem OpenFlow zum Einsatz, das an der Stanford University in Kalifornien entwickelt wurde. Für die Anbindung der Anwendungen sind standardisierte Application Programming Interfaces (APIs) zuständig. Derzeit favorisieren etliche Netzhersteller OpenFlow, darunter Hewlett-Packard, NEC und IBM. Allerdings gibt es auch andere Ansätze, beispielsweise Path Computation Elements (PCE), ein speziell für SDN in Weitverkehrsnetzen entwickeltes Konzept.

Die Switches und Router in einer SDN-Infrastruktur müssen das Protokoll "verstehen", das der SDN-Controller verwendet, also etwa OpenFlow. Das bedeutet im Extremfall den Austausch von älteren Systemen gegen neue, die über entsprechende Schnittstellen verfügen. Die meisten Anbieter von Netzausrüstung für Enterprise Networks und Telekommunikationsnetze statten derzeit ihre Systeme mit entsprechenden Interfaces aus.

Das leistet SDN

Die Verfechter des Konzepts führen unter anderem folgende Vorteile von SDN an:

• Beim Controller handelt es sich um kein herstellerspezifisches, geschlossenes System. Netzadministratoren können darauf zugreifen und den Controller programmieren.

• Unterschiedliche Netzsysteme lassen sich von einer zentralen Stelle aus steuern, von physischen Switches und Routern bis hin zu virtualisierten Switches (vSwitches), WLAN-Access-Points und WAN-Optimierungssystemen.

• Anwendungen und neue Netzdienste können innerhalb von Stunden bereitgestellt werden. Derzeit erfordert dies oft mehrere Tage oder gar Monate. Bei SDN lassen sich über Einträge in Flow Tables auch Dienste und Eigenschaften konfigurieren, bei denen das in herkömmlichen Netzen nicht mittels Scripts möglich ist, etwa Quality-of-Service-Merkmale und VLAN-Einstellungen.

• Servicedefinitionen müssen nicht mehr auf physikalische Netz-Ports "gemappt" werden. Das verringert den Konfigurationsaufwand.

• Der Controller vermittelt dem Administrator eine "ganzheitliche" Sicht auf die Anwendungen, Netzelemente und Datenströme (Flows).

• Laut Oracle verringert SDN die Komplexität einer Netzwerkinfrastruktur um bis zu 70 Prozent, weil weniger Switch-Ports und Kabel erforderlich sind. Bei LANs und Storage Area Networks seien es etwa 50 Prozent.

Die University of Stanford (Kalifornien) führt an, dass Software Defined Networks vor allem die Handhabung von Virtual Machines (VM) erleichtern. Demnach lassen sich in einer SDN-Infrastruktur VMs auf einfachere Weise im Netz verschieben. Der Grund ist, dass sich mit einem SDN-Controller sowohl physische wie auch virtualisierte Data Planes steuern lassen.

Geringere Ausgaben für das Netz

Die genannten Faktoren schlagen sich nach Berechnungen der Beratungsgesellschaft International Strategy and Investment Group (ISI) in geringeren Kosten nieder. Durch die effizientere Auslastung der Systeme in einem typischen Server-Rack sollen sich mit Hilfe von SDN etwa 20 Prozent der Server, Speicher- und Netzsysteme sowie der zugehörigen Verkabelung und Netzbandbreite einsparen lassen.

In einem Rechenzentrum mit zehn Racks, die jeweils mit Ausrüstung im Wert von einer Million Dollar bestückt seien, könnten dadurch zwei Racks entfallen. Das entspricht einem Gegenwert von zwei Millionen Dollar. Zudem, so ISI, reduziert SDN die Betriebskosten. Der Grund: Im Vergleich zu einer herkömmlichen Netzinfrastruktur lassen sich mit SDN mehr Netzwerk-Management-Prozesse automatisieren. Das entlaste die IT-Abteilung, vor allem bei der Migration zu einer Private-Cloud-Umgebung oder einer Hybrid Cloud, in der sowohl hausinterne IT-Systeme und -Services als auch Public-Cloud-Angebote genutzt werden.

Kritikpunkte

Allerdings gibt es eine Reihe von Punkten, die Fachleute am Software Defined Networking kritisieren. So steigt mit dem Konzept eines zentralen Controllers die Fehleranfälligkeit: Fällt der Controller aus, "steht" das Netz. Dies lässt sich beheben, indem mehrere Controller zum Einsatz kommen. Das erhöht jedoch die Komplexität der Infrastruktur und damit auch den Management-Aufwand.

Bedenken gibt es zudem in Bezug auf die Skalierbarkeit einer SDN-Infrastruktur. Speziell in komplexen Netzen mit vielen Switches, Servern und Virtual Machines müssen Controller mehrere hunderttausend oder Millionen Flows bewältigen. In den derzeitigen Testinstallationen der University of Stanford fallen jedoch nur mehrere hundert bis tausend Flows an.

"Neben der Standardisierung ist die Skalierbarkeit einer solchen Lösung eine Herausforderung", bestätigt Enterasys-Technikstratege Nispel. "Eine totale Zentralisierung der Control Plane bringt zwar theoretisch Vorteile für das Management, jedoch sind Verfügbarkeit und insbesondere Skalierung ein Problem." Die Definition der IP-Flows in den gegenwärtig vorhandenen OpenFlow-Testumgebungen erfolge in einer groben Weise und sei statisch vordefiniert: "Das heißt, man muss sich vorher genau überlegen, wer mit wem kommunizieren möchte."

Nachbesserung ist notwendig

Laut Adva Optical Networking, einem Hersteller von optischen Netzkomponenten für Weitverkehrsnetze, eignet sich SDN auf Basis von OpenFlow zudem nur unzureichend für optische Netze, in denen eine leitungsvermittelnde Übertragung stattfindet. Hier seien Erweiterungen der OpenFlow-Spezifikation erforderlich. Allerdings hat die Internet Engineering Task Force (IETF) mit Path Computation Elements eine SDN-Spezifikation zur Verfügung gestellt, die für das Software Defined Networking in Weitverkehrsnetzen auf IP-Basis zugeschnitten ist.

Weiterhin ist zu berücksichtigen, dass der Verkehr im Netzwerk durch die Kommunikation zwischen den Controllern nach ersten Erfahrungswerten um etwa drei bis vier Prozent steigt. Dies dürfte in vielen Fällen nicht problematisch sein, führt aber dennoch zu einer stärkeren Belastung des Netzes.

Noch unklar ist ferner, wie sich SDN in komplexen Netzen umsetzen lässt. Dies betrifft vor allem das Management von IT-Ressourcen über mehrere Domains hinweg. Ebenfalls noch nicht zufriedenstellend gelöst ist die Frage, wie sich Verkehrsströme und Daten in Netzen trennen lassen, die auf eine "Shared Infrastructure" zurückgreifen. Das ist beispielsweise in MPLS-Weitverkehrsnetzen (Multi Protocol Label Switching der Fall.

Viel Auswahl an SDN-Controllern

Kein Mangel herrscht an Controllern für Software Defined Networks. Derzeit sind unterschiedliche Produkte diverser Anbieter auf dem Markt. Die Palette reicht von Open-Source-Produkten wie Beacon und Floodlight bis zu kommerziellen Controllern wie ProgrammableFlow und Onix. Die meisten stammen von kleineren Unternehmen wie etwa Big Switch. Auch etablierte Netzspezialisten, beispielsweise Cisco (Cisco SDN OpenFlow Controller), HP (HP Virtual Application Networks SDN Controller) und IBM (IBM System Networking Programmable Network Controller) haben entsprechende Produkte vorgestellt oder zumindest angekündigt.

Mangelware SDN-Switches

Was SDN-fähige Switches betrifft, ist die Auswahl noch nicht sonderlich groß. Die größte Palette kann mit 16 Systemen die Networking-Sparte von HP vorweisen. Acht weitere Switches der Reihe HP 3800 kommen 2013 hinzu, ebenso der erwähnte SDN-Controller. Generell ist festzustellen, dass sich alle etablierten Switch-Hersteller SDN auf die Fahnen geschrieben haben. Einige verfolgen jedoch herstellerspezifische Ansätze, zum Beispiel Marktführer Cisco Systems: Die Open-Network-Environment-Plattform (Cisco ONE) des Unternehmens enthält APIs, Agents, Controller und Komponenten für Overlay-Netze, die sich programmieren lassen. Die Plattform ist allerdings auf Netze zugeschnitten, die auf Komponenten von Cisco basieren.

SDN in der Praxis

Die praktischen Erfahrungen mit SDN beschränken sich bisher vor allem auf Netze von Forschungseinrichtungen und Hochschulen wie der Stanford University oder dem Kernforschungszentrum Cern in Genf. Allerdings haben auch Google und Microsoft einen Teil ihrer Rechenzentren in eine SDN-Infrastruktur eingebunden.

Andreas Müller, Country Manager von HP Networking in Deutschland, erwartet jedoch, dass sich SDN auch im kommerziellen Umfeld etabliert: "In Verbindung mit OpenStack werden sich Software Defined Networks auf Basis von OpenFlow auch im Cloud-Computing-Bereich und in großen Firmennetzen durchsetzen." Der Grund ist, dass solche komplexen Netze in immer stärkerem Maße ein weitgehend automatisiertes Management erfordern: "Das ist mit herkömmlichen Methoden nicht zu erreichen."

SDN-Controller: Was zu verbessern ist

In einer Untersuchung zur Leistungsfähigkeit von Software Defined Networking kommt das Institut für Parallele und Verteilte Systeme (IPVS) der Universität Stuttgart zu dem Schluss, dass SDN ein tragfähiger Ansatz ist, um Middleware für künftige Generationen von Unternehmensnetzen und des Internets zu erstellen. Nach Auffassung der Autoren existieren jedoch einige Bereiche, in denen Nachbesserungen beziehungsweise weitergehende Untersuchungen erforderlich sind:

Skalierbarkeit: Vor allem in großen, dynamischen Netzen kann sich ein Controller als Flaschenhals erweisen. Ein Ausweg sind Cloud-basierte SDN-Controller, deren Leistung sich bei Bedarf erhöhen lässt, etwa indem ihnen mehr CPU-Cores zur Verfügung gestellt werden. Eine weitere Option ist der Einsatz von verteilten ("distributed") Controllern.

Größe der Flußtabellen (Flow Tables): Eine hohe Zahl von Einträgen in den Flow Tables eines Switchs (typischerweise bis zu 150.000) kann sich negativ auf die Netzbandbreite auswirken.

Koordination verteilter Controller: Die Control Plane in einer SDN-Infrastruktur lässt sich auf mehrere Controller verteilen, um etwa die Fehleranfälligkeit zu verringern oder einen Lastausgleich (Load Balancing) vorzunehmen. Dies setzt allerdings optimierte Abstimmungsprozesse zwischen den Systemen voraus. Denkbar sind eine hierarchische Struktur und ein Peer-to-Peer-Modell. Beide erfordern jedoch unterschiedliche Koordinationskonzepte.

Unterstützung von Quality-of-ServiceMechanismen: Echtzeitanwendungen wie Voice over IP oder Applikationen für die Steuerung des Netzes erfordern QoS. Es müssen somit entsprechende Verfahren für das Reservieren von Netzressourcen und das Forwarding verwendet werden. In diesem Fall hat SDN Vorteile in Bezug auf die Performance, weil das Forwarding auf dem Layer 3 (Netzwerkebene) erfolgt, nicht auf der Anwendungsebene (Layer 7).

Fazit

Für die Hersteller von Netzkomponenten bedeutet SDN, dass proprietäre Hardware wie etwa Switches an Bedeutung verliert. Dafür werden SDN-Controller und entsprechende Management-Tools wichtiger. Für SDN sprechen die hohe Flexibilität und die Möglichkeit, die Netzinfrastruktur besser als bislang auf die speziellen Anforderungen von Anwendungen abstimmen zu können - etwa in Bezug auf die erforderlichen Bandbreiten oder Quality-of-Service-Parameter. Diese Flexibilität wird vor allem in komplexen Netzen, etwa Private oder Hybrid Clouds, wichtiger.

Bis Software Defined Networking das Unternehmensnetz erreicht, dürften dennoch einige Jahre vergehen. Zum einen gibt es bislang noch zu wenige Produkte, die SDN-Protokolle wie OpenFlow unterstützen. Nach Angaben von VMware sind derzeit bestenfalls ein bis zwei Prozent der Netzwerk-Switches für OpenFlow ausgelegt. Zum anderen müssen Software Defined Networks noch den Beweis antreten, dass sie auch in komplexen Installationen "beherrschbar" sind. Dennoch ist SDN ein Schritt in die richtige Richtung. Erfreulich ist, dass durch die Diskussion über SDN die etablierten Anbieter, die bislang auf geschlossene Welten setzen, aufgeschreckt wurden. Für den Anwender kann sich dies mittelfristig auszahlen. (hi)