Software-defined networking

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche

Software-defined networking (SDN) ist ein Ansatz zum Bau von Computernetzwerk-Geräten und Software, die zwei wesentliche Komponenten solcher Geräte voneinander trennt und abstrahiert. Dabei handelt es sich um die Control Plane und die Data Plane. Erste Konzepte hierzu stammen von der Stanford University aus der Zeit um 2005. 2013 bezeichnen viele Hersteller ihre Produkte als SDN-fähig, so dass bereits von einem Hype gesprochen wird.[1]

Beschreibung[Bearbeiten]

SDN ermöglicht Netzwerkadministratoren, das Netzwerk einfacher zu verwalten, indem die unteren Funktionsebenen in virtuelle Services abstrahiert werden. Die Hardware muss also nicht mehr manuell konfiguriert werden.[2]. Das wurde immer wichtiger mit dem Aufkommen von Virtualisierung, bei der ein größeres Rechenzentrum in zunehmender Anzahl über das Netzwerk virtuelle Systeme erstellen und konfigurieren muss, und zugehörige Firewall-Regeln und Netzwerkadressen generiert werden müssen. Es gibt etliche Ansätze, analog auch virtuelle Netzwerke (VLANs) zu generieren, aber das führt zu einer hohen Komplexität.[2] SDN gibt den Netzwerkadministratoren eine programmierbare, zentrale Steuerung des Netzwerkverkehrs, ohne manuell Zugriff auf die einzelnen physischen Netzwerkkomponenten nehmen zu müssen.[3][4]

SDN entkoppelt das System, das entscheidet, wohin die Daten geschickt werden (die Control-Plane), vom darunterliegenden System, das die Daten zum ausgewählten Bestimmungsort weiterleitet (die Data-Plane).[5] Die Entwickler und Anbieter dieser Systeme geben an, dass diese Technologie die Netzwerkadministration vereinfacht [6] und neue Anwendungen ermöglicht, wie die Netzwerk-Virtualisierung, bei der die Control-Plane von der Data-Plane getrennt und als reine Anwendung implementiert wird.[7]

Die Open Networking Foundation wurde gegründet, um SDN-Standards zu fördern. Trends wie Cloud Computing verwischen die Grenzen zwischen Netzwerk und Computer in einem technologischen Umfeld, wo SDN-Standards nützlich erscheinen.[2] Alcatel-Lucent [8][9] schlägt allerdings einen eigenen Weg vor.

Hintergrund[Bearbeiten]

Internet Protocol (IP)-basierende Netzwerke basieren auf dem Konzept Autonomer Systeme (AS). Dieser Ansatz erlaubt es, Netzwerke zu erweitern, indem immer weitere Knoten angeschlossen werden, die eintreffende Pakete zu einem sinnvollen nächsten Knoten weiterleiten und dabei keinen detaillierten Blick auf die gesamte Netzstruktur benötigen. Dieses Konzept ist einfach und hat sich als stabil und erweiterbar erwiesen. Im einfachsten Fall erlaubt dieses Konzept es einer Komponente nicht, sich an einer anderen Stelle im Netzwerk anzuschließen, denn sie würde ihre Pakete nicht mehr erhalten. Die Identität einer Netzwerkkomponente ergibt sich aus ihrer Stelle im Netzwerk. Außerdem ist es mit einfachen AS-Strukturen kaum möglich, der Komponente bestimmte Eigenschaften zuzuordnen, wie logische Gruppierung, Zugriffskontrolle, Quality of Service, eine spezifische Verarbeitung von Daten vor der Zustellung oder auch Kontextinformationen zu Datenströmen, die über den Inhalt des einzelnen Pakets hinausgehen.

Ergänzende Standards wurden von der Internet Engineering Task Force (IETF) verabschiedet, um diesen Bedürfnissen Rechnung zu tragen, wie DHCP, Routing, virtuelle LANs oder virtuelle private Netzwerke (VPNs). Nach und nach wuchs hierdurch die Komplexität bei der Spezifikation und Konfiguration des Netzwerks durch die Administratoren.

Die verstärkte Internet-Nutzung, inzwischen auch über mobile Endgeräte, war einer der Treiber, die den Bedarf an hoch standardisierten Betriebssysteminstanzen forcierte. Cloud-Architekturen mit dynamischer Ressourcen-Zuordnung tragen dem Rechnung, und SDN strebt an, die erforderlichen Netzwerkkonfigurationen vergleichbar automatisiert auszurollen wie virtuelle Systeme. Die hohe Dynamik bei der Verlagerung mehr oder weniger stark genutzter Systeme auf jeweils passende Hardware-Ressourcen wird dabei unterstützt. Es muss nicht jedes Mal manuell an Switches konfiguriert werden, um die vereinbarten Policys einzuhalten. Vielmehr erfolgen die Anpassungen von Routing- und Firewall-Regeln, Bandbreitenzuteilungen usw. automatisiert und zentralisiert, während die dezentralen Hardware-Komponenten nur noch einfache Aufgaben wie die Weiterleitung eines Pakets zum richtigen Port übernehmen.

Die zentrale, software-definierte Steuerung erkennt auch spezifische Kontexte, die an Quelle-Ziel-Beziehungen festzumachen sind. So muss nicht jedes Paket der kompletten Firewall-Prüfung unterzogen werden, wenn frühere, vergleichbare Pakete aus derselben Verbindung die Prüfung bereits bestanden haben. Passende Mechanismen zur Einbindung herstellerspezifischer Funktionen und Implementierungen wurden gefunden. Einen Schritt weiter geht Openflow mit der Standardisierung von Befehlen zur Konfiguration der Data Plane. Das OpenFlow-Protokoll ermöglicht die Entwicklung von Software-Controllern, die das gesamte Netz steuern. Sie können zentralisiert oder verteilt implementiert werden, um über die traditionellen IP-Kernfunktionen eine Ebene zu legen, welche die komplexeren und teilnehmerspezifischen Netzwerkfunktionen verwaltet.

Der Begriff "Software-Defined Networking" wird 2009 von Kate Greene verwendet.[10]

Entkopplung von Data Plane und Control Plane[Bearbeiten]

Man kann ein SDN so konfigurieren, dass die Hardware mit der Control Plane eine andere ist, als die mit der Data Plane, so dass ein Switch nur Pakete weiterleitet, während ein separater Server die Aufgaben der Control Plane übernimmt.

Es gibt zwei Gründe für diesen Ansatz. Zum einen können unterschiedliche Gerätezahlen, Austauschzyklen usw. zum Einsatz kommen. Zum anderen kann jeweils optimal geeignete Hardware eingesetzt werden, z. B. ein leistungsfähiger Server für die Control Plane und eine größere Anzahl energiesparender Switches für reines Forwarding.

Control Planes und Data Planes müssen hier selbst über das Netzwerk miteinander kommunizieren. OpenFlow ist ein Standard für ein solches Protokoll, jedoch können auch andere Verfahren eingesetzt werden. OpenFlow wird von der Open Networking Foundation verwaltet.[11]

SDN-Einsatzmodelle[Bearbeiten]

Symmetrisch vs. asymmetrisch
In einem asymmetrischen Modell wird die globale Information eines SDN so weit wie möglich zentralisiert, während der Betrieb der Switches so weit wie möglich verteilt wird. Die Erwartungen daran sind klar: Zentralisierung der Konfiguration vermeidet zu viele Redundanzen und mögliche Inkonsistenzen, während die Verteilung des Datenverkehrs Bandbreitenengpässe an zentralen Stellen vermeidet. Allerdings bleiben Aspekte zu bedenken, z. B. wie störunanfällig eine solche Konstruktion gerade bei mehreren Lokationen ist und ob solche zentralisierten Strukturen ausreichend wachsen können. Beim gegenteiligen Ansatz kennt jede Komponente auch alle für sie relevanten Control-Plane-Konfigurationen, so dass auch bei beliebigen Teilausfällen jede verbleibende Teilstruktur in ihren Grenzen normal weiter arbeiten kann. Praxistauglich sind vor allem solche Ansätze, bei denen zwar die Anzahl der Control Planes minimal ist, wobei aber jede Lokation zur Not autonom arbeiten kann und zwar ohne einen Single Point of Failure.
Floodless vs. flood-based
Im Flood-based-Modell wird ein erheblicher Anteil der globalen Informationsverteilung erreicht, indem jede Veränderung über normale Broadcast- und Multicast-Mechanismen kommuniziert wird. Dadurch können SDN-Modelle symmetrischer werden. Transparentes Bridging wird genutzt, um Informationen allgemein bekannt zu machen und die Identität der Netzteilnehmer zu verbreiten. Andererseits steigt die Netzwerklast pro Netzwerkknoten an, je mehr Knoten hinzukommen, was die Skalierbarkeit begrenzt. Beim Floodless-Modell wird die korrekte Funktion aller Komponenten dagegen über lokale Caches von SDN-Lookup-Tables sichergestellt, welche von Zeit zu Zeit miteinander synchronisiert werden.
Host-based vs. netzwerk-zentriert
Das host-based Modell nimmt an, dass es in Rechenzentren mit vielen virtuellen Maschinen günstig ist, die SDN-Verarbeitung auf dem Hypervisor-System zu erledigen, weil es hier immer freie Kapazitäten für die relativ geringe entstehende Last gibt. Der netzwerk-zentrierte Ansatz dagegen bleibt bei dedizierten Routern wie traditionell üblich und überlässt die Routing-Funktionen nicht den Virtualisierungshosts.
Einige Grenzlinien sind nicht immer scharf zu ziehen. So können Virtualisierungshosts einige CPU-lastige SDN-Aufgaben wie die Verschlüsselung von VPN-Verkehr übernehmen, während andere Funktionen auf dedizierten SDN-Servern angesiedelt sind. Auch gibt es gewisse Abhängigkeiten; so implizieren Host-based Ansätze ein asymmetrisches Design.

Anwendungen[Bearbeiten]

Eine Anwendung von SDN ist Infrastructure as a Service (IaaS). Hier wird SDN kombiniert mit virtuellen Systemen und virtuellem Storage, was eine "elastische", also bedarfsabhängige Ressourcenallokation erlaubt. Insbesondere Scale-Out-Szenarien, bei der nach Bedarf weitere Systeme zugeschaltet werden, profitieren von der möglichen Automatisierung. Die Anbieter sehr großer Softwareinstallation wie Google und Facebook zeigen, dass passende Software-Architekturen für solche verteilten Systeme gefunden werden können. Aber auch für kleine Anwendungen, die nur auf einer VM laufen, können dieselben Mechanismen helfen, vollständig von der (Netzwerk-) Hardware zu abstrahieren.

Ein anderer Ansatz sorgt für eine dynamische Re-Allokation virtueller Systeme auf den Virtualisierungshosts. Ziel dabei ist es, möglichst wenige Hosts möglichst gut auszunutzen. Virtualisierungsumgebungen, bei denen Re-Allokationen (wenn überhaupt) nur manuell durchgeführt werden, berücksichtigen bestenfalls die überlasteten Hosts, während ungenutzte Kapazitäten meist keine Beachtung finden, was zu einer schleichenden Unterforderung der betreffenden Hosts und der Verschwendung von Ressourcen führt.

SDN erlaubt die Verteilung von Lasten auf viele Verbindungen, beispielsweise zwischen den Anwendungsservern und dem Netzwerk-Backbone. Traditionell werden hier manuell VLANs definiert und Routen gesetzt oder mit Bondings gearbeitet, was aufwändig ist und keine dynamische Anpassung an wechselnde Lasten ermöglicht. Load-Balancing auf verschiedene Anwendungsserver, verteilte Firewalls und weitere Anwendungen kommen hinzu.

SDN kann in Unternehmen oder bei Carriern auch Managed Network Services (MNS) übernehmen. Hier geht es um Service Level Agreements, d. h. auch bei permanenten Veränderungen am Netzwerk, wie es in solchen Umgebungen unausweichlich ist, soll der einzelne Teilnehmer seine garantierten Bandbreiten, Latenzzeiten, Verfügbarkeiten und Sicherheitsfeatures bekommen.

Wenn der SDN-"Overlay" nicht die Charakteristika der darunter liegenden Infrastruktur berücksichtigt, sind Ineffizienz und geringer Durchsatz die wahrscheinliche Folge.[12] Gerade Carrier sind daher interessiert an SDN-Lösungen, welche Datenmengen, Topologie und Hardware berücksichtigen und entsprechend reagieren.[13] Entsprechend gibt es einen Vorschlag für eine SDN-Lösung, die Netzwerk-Ressourcen berücksichtigt, so dass der Datenstrom kontinuierlich optimiert werden kann, und die Anforderungen in besser vorhersehbarer Weise gehandhabt werden.[14]

Zugriffskontrolle in SDN[Bearbeiten]

Fernzugriff auf die Control Plane wird den Administratoren aus Sicherheitsgründen üblicherweise per RBAC ermöglicht.

Quellen[Bearbeiten]

  1. Sean Michael Kerner: OpenFlow Inventor Martin Casado on SDN, VMware, and Software Defined Networking Hype. In: Enterprise Networking Planet, 29. April 2013. Abgerufen am 21. Mai 2013. 
  2. a b c http://arstechnica.com/information-technology/2013/02/100gbps-and-beyond-what-lies-ahead-in-the-world-of-networking/2/
  3. Margaret Rouse: software-defined networking (SDN). TechTarget. June 2012. Abgerufen am 21. Mai 2013.
  4. Bort, Julie.The Three Letters That Are Setting The Enterprise Tech World On Fire, Business Insider, 5 October 2012
  5. Software-Defined Networking: The New Norm for Networks (PDF; 739 kB) In: White Paper. Open Networking Foundation. 13. April 2012. Abgerufen am 21. Mai 2013.
  6. Big Switch Networks Products. Abgerufen am 20. Oktober 2013.
  7. David Strom: Software-defined networking could drastically change today’s network infrastructure. TechTarget. November 2012. Abgerufen am 21. Mai 2013.
  8. http://enterprise.alcatel-lucent.com/?dept=Innovation&page=SoftwareDefinedNetworks
  9. http://www.networkcomputing.com/next-gen-network-tech-center/alcatel-lucents-sdn-strategy-downplays-o/240142962
  10. Kate Greene: TR10: Software-Defined Networking. In: Technology Review, MIT, March/April 2009. Abgerufen am 21. Mai 2013. 
  11. Open Networking Foundation. Abgerufen am 20. Oktober 2013.
  12. Still no VMware of Networking. Overlays change nothing beneath the surface.. Abgerufen am 20. Oktober 2013.
  13. Adoption of SDN: Progress Update. Archiviert vom Original am 21. Oktober 2012. Abgerufen am 20. Oktober 2013.
  14. Blueprint for Infrastructure SDN (PDF; 719 kB) Abgerufen am 20. Oktober 2013.

Weblinks[Bearbeiten]