SDN in Unternehmensnetzen

Kommentieren Drucken

SDN weckt immer noch so viele Emotionen wie kaum ein anderes Netzwerkthema in den letzten Jahrzenten. Je nach Sichtweise wird die Technologie zum Heilsbringer, zur Spinnerei technologiegläubiger Akademiker oder gar zum Jobvernichter hochstilisiert

Bei so großen Unterschieden in der Bewertung und Argumentation lohnt es sich in der Regel, mal kurz durchzuatmen, einen Schritt zurückzutreten und mit einem etwas größerem Abstand die Materie zu betrachten. Dies ist das Ziel dieses Artikels.

Was ist SDN?

Getrieben werden die unterschiedlichen Meinung über SDN natürlich nicht zuletzt von der Tatsache, dass SDN eben kein standardisiertes Protokoll oder fertiges Produkt eines Herstellers, das man bewerten könnte, ist. Es gibt noch nicht einmal irgendein Dokument, das SDN umfassend und abschließend festschreibt, denn mit SDN wird eher diffus eine Architektur zur zentralisierten Steuerung von Netzen bezeichnet als eine konkrete Technik.

Diese fehlende allgemein anerkannte Definition führt eben auch dazu, dass jeder mit einem zentralen Managementtool dieses Produkt in letzter Zeit gerne mal in der Nähe von SDN positioniert. Aber so einfach ist es nicht.

SDN steht für „Software Defined Networking“, der Begriff reicht bis in die 1990er Jahre zurück. Die Basis dessen, was wir heute unter SDN verstehen, wurde jedoch erst 2007/2008 an den amerikanischen Universitäten Berkeley und Stanford gelegt und ist eng verbunden mit den Namen Martîn Casado, Nick McKeown und Scott Shenker, dem Unternehmen Nicira und dem Protokoll OpenFlow.

OpenFlow ist ein Kommunikationsprotokoll zur Steuerung von Layer-2- und Layer-3-Swiches und Routern im Netzwerk. Das Protokoll wird von der ONF (Open Networking Foundation) entwickelt und ist historisch gesehen im Grunde der Startpunkt der modernen SDN-Entwicklung.

Das Protokoll basiert auf „Anweisungen“ an die Netzwerkkomponenten, wie mit welchen eingehenden Paketen zu verfahren ist. Diese „Anweisungen“ bestehen jeweils aus einer Mustererkennung und einer oder mehreren Aktionen. Die Aktionen werden von der OpenFlow-Komponente durchgeführt, wenn das eintreffende Paket zu dem jeweiligen Muster passt. Als Muster kommen alle Layer-2-, Layer-3-und Layer-4-Headerkomponenten in Frage, insbesondere also die MAC- und IP-Adressen sowie die Portnummern von UDP und TCP, typische Aktionen sind „Paket an Port x weiterleiten“ oder „Paket wegwerfen“, aber auch Änderungen des Pakets selbst wie VLAN-Zuordnung oder QoS-Markierungen sind möglich.

An den Universitäten stand man damals vor der Aufgabe, neue Netzwerkprotokolle und -verfahren testen zu wollen, ohne aufwändige, dedizierte Testumgebungen aufbauen zu müssen. Die Idee war daher, das Produktiv- bzw. Campusnetz (mit) zu nutzen und pro Anwendung zu steuern, wie die jeweiligen Kommunikationsströme im Netz behandelt werden. Schnell waren die wesentlichen Eckpunkte gefunden, wie man so etwas umsetzen könnte. Man nehme:

  • OpenFlow,
  • einen zentralen Controller, der die Netzwerkströme jetzt via OpenFlow steuert, und
  • Netzwerkkomponenten, die die OpenFlow-Anweisungen des Controllers umsetzen und die einzelnen Pakete entsprechend bearbeiten und weiterleiten können.
Eine wichtige Anmerkung vorweg: Wenn an dieser Stelle und auch später im Artikel von „einem“ oder „dem“ Controller die Rede ist, bedeutet das nicht, dass es sich physisch um ein einzelnes System handelt. Vielmehr ist damit eine zentrale Control Plane gemeint, die natürlich sowohl redundant als auch verteilt aufgebaut werden kann.

Damit ist das Grundgerüst von SDN im Wesentlichen skizziert (siehe Abbildung 1).

  1. Paket kommt beim ersten Switch (Ingress-Switch) an.
  2. Falls der Switch keine Regel kennt, wie das Paket behandelt werden muss, fragt er beim Controller nach. Hierzu leitet er wahlweise das komplette Paket oder nur Metadaten (Header-Daten) an den Controller weiter.
  3. Der Controller entscheidet über Bearbeitungs- und Weiterleitungsregeln und schickt diese Regeln an alle betroffenen Systeme.
  4. Das Paket wird entsprechend dieser Regeln bearbeitet und durch das Netzwerk geschleust.

Schon aus diesem recht einfachen Basiskonzept lassen sich wesentliche Merkmale der ursprünglichen Idee ableiten:

  1. Das Konzept ist flowbasierend.
    Das heißt, der Controller muss Bearbeitungs- und Weiterleitungsregeln nicht für jedes einzelne Paket ableiten und verteilen, sondern nur für ganze Klassen von Verkehrsströmen oder Kommunikationsbeziehungen (sogenannte Flows), die anders behandelt werden müssen als andere. Konkret: die über einen anderen Weg durch das Netz geschleust oder die sonst wie anderes bearbeitet werden sollen.

    Diese Flows werden natürlich durch die Mustererkennung von OpenFlow definiert.

  2. Da die OpenFlow-Regeln auch auf nachfolgende Pakete angewendet werden sollen, muss der Switch oder Router diese Regelsätze zwischenspeichern. Das bedeutet einerseits einen völlig neuen Tabellentyp („Flow Table“) für diese Informationen im Speicher der Netzwerkkomponenten, bietet andererseits aber auch die Chance, die unterschiedlichen Forwarding-Tabellen von MAC-Adressen über IPv4- und IPv6-Adressen bis hinzu ACLs, die man heutzutage alle in Switches findet, zu vereinheitlichen und so eine einheitliche Speicherstruktur (Data Plane) zu schaffen.
  3. Aus architektonischer Sichtweise gestattet es OpenFlow von außen die Forwarding Plane von Netzwerkkomponenten zu manipulieren oder gar komplett zu verwalten. Die sogenannte Control Plane, die für diese Aufgabe zuständig ist, wird also praktisch auf den Controller ausgelagert.

Hier deutet sich bereits an, dass dieses Konzept einige Freiheitsgrade besitzt, die gerne übersehen werden. Stellt man insbesondere den Controller ins Zentrum des Konzepts, wird schnell klar, dass OpenFlow nur eine mögliche Ausprägung der Schnittstelle zu den Hardware-Geräten ist. Wählt oder entwickelt man eine andere Schnittstelle, kann man sich zum Beispiel von OpenFlow-spezifischen Einschränkungen befreien, insbesondere von der Beschränkung auf Layer-2- bis Layer-4-Merkmale:

  • Theoretisch lassen sich nämlich alle klassischen Netzwerkgeräte vom Switch und Router bis hin zu Firewall und Loadbalancer steuern bzw. deren Regelwerk bedarfsgerecht anpassen.
  • Das Konzept (auch mit OpenFlow) erzwingt keineswegs, dass jeglicher Datenverkehr vom Controller gesteuert werden muss. Wir werden diesen Aspekt weiter unten noch diskutieren.
  • Und das Konzept erzwingt keineswegs, dass es nur einen Controller gibt. Es gibt tatsächlich Lösungen mit spezialisierten Controllern für bestimmte Gerätetypen oder Protokolle. Auch diesen Punkt werden wir unten etwas genauer beleuchten.

Was hierbei auf den ersten Blick komplex aussieht, ist das genaue Gegenteil. Es macht überhaupt keinen Sinn Firewalling-Funktionalität in eine Lösung zu bringen, die im Kern die Wegewahl durch das Netzwerk regeln soll. Andererseits wäre es schade, Firewalls prinzipiell auszuschließen.

Die spannende Frage ist also, wie dieses Grundgerüst in der Praxis umgesetzt wird. Tatsächlich gibt es eine breite Palette von Möglichkeiten, die die Bandbreite von SDN aufzeigen, aber gerade auf Grund dieser Bandbreite auch für viel Verwirrung und Unsicherheit im Markt sorgen.

Die Vision: SDN überall

Den Entwicklern von SDN schwebte schon früh die Vision vor, den beschriebene Entwurf auf der Basis von OpenFlow flächendeckend für gesamte Unternehmens- oder Campusnetze einzusetzen und alle Netzwerkkomponenten über einen zentralen Controller zu steuern.

Nick McKeown, einer der Gründungsväter, hatte in seinen Präsentationen folgende Definition von SDN:

A network in which the control plane
is physically separate from
the forwarding plane.

and

A single control plane controls
several forwarding devices.

(That’s it)

Mit anderen Worten: „Dumme“ Netzwerkkomponenten, die nur das reine Packet Forwarding umsetzen, werden von einer zentralen Controller-Instanz gesteuert, wo die komplette Netzwerkintelligenz und alle Statusinformationen des Netzes zusammengeführt werden.

Die Erwartungen an dieses allumfassende und sehr strikte Modell waren sehr groß und wurden mit entsprechend markigen Worten vorgetragen:

  • Ablösung der statischen und dezentralen Netzwerkkonzepte aus den 50er- und 60er-Jahren durch dynamische, zentral gesteuerte Strukturen,
  • Ablösung der „Mainframe-artigen“, proprietären und komplexen Netzwerkkomponenten durch einfache und günstige „Forwarding Devices“, möglichst auf Basis von i386-Standardkomponenten,
  • Ablösung von standardsbasierenden Netzwerkprotokollen mit Innovationszyklen in der Größenordnung von Jahrzehnten (Was ja mit Blick auf die IEEE und IETF durchaus realistisch ist!) durch moderne, schnellentwickelte Softwaremodule im Controller, möglichst auf Open-Source-Basis.

Kurz: Alles wird einfacher und alles wird billiger.

Was bedeutet ein solches Modell für das Netzwerk?

Bleiben wir hierzu kurz noch bei der Vorstellung, dass alle mit der Bearbeitung und Weiterleitung von Netzwerkverkehr beschäftigten Geräte in eine gemeinsame SDN-Architektur eingebunden sind und von einer einzigen übergeordneten Controller-Instanz gesteuert werden.

Ein solches Netz hat beeindruckende neue Eigenschaften: Es gibt im Grunde keine Layer-2- oder Layer-3-Domänen mehr!

Der Controller definiert nämlich für jede Kommunikationsbeziehung, zum Beispiel für eine Datenbankverbindung zwischen zwei Servern oder für eine Anwendung zwischen Server und Client, je einen Pfad von Endpunkt zu Endpunkt quer durch das Netzwerk und verteilt die dazugehörenden Weiterleitungsregeln entlang dieses Wegs.

Und da er das für alle Datenverbindungen macht, heißt das, unser Netzwerk besteht nur noch aus bedarfsgerecht, dynamisch aufgebauten Punkt-zu-Punkt-Verbindungen (gegebenenfalls auch Punkt-zu-Mehrpunkt-Verbindungen): kein Spanning Tree, keine Routing Protokolle, kein Shortest-Path-Bridging und ähnliches, keine VLANs etc. Das Netz (d. h. der Controller) weiß wer mit wem wie kommuniziert und die Pfade durch das Netz können bedarfsgerecht, also zum Beispiel lastabhängig, angepasst werden.

Ein solches flowbasierendes Punkt-zu-Punkt-Layout ist insbesondere deshalb von Bedeutung, weil unsere Anwendungen so arbeiten. Anwendungen versenden in der Regel keine Pakete, sondern Datenströme. Wenn das Netz jetzt ebenfalls auf der Basis von Datenströmen arbeitet, ist das für den Betrieb und das Design des Netzes natürlich vorteilhaft, insbesondere, wenn wir zukünftig Anwendungen in den Fokus unserer Betriebskonzepte stellen wollen (Stichwort Software-Defined Data Center).

Die zentrale Komponente dieses Modells wird der Controller, ohne ihn läuft nichts. Mögliche Controller sollen daher jetzt schon aus Stabilitätsgründen modular aufgebaut werden (siehe Bild 2):

  1. Die Schnittstelle zur Netzwerk-Hardware mit OpenFlow oder einem vergleichbaren Kommunikationsprotokoll bildet das sogenannte Southbound-Interface.
  2. Um den Controller selbst schlank und dynamisch erweiterungsfähig zu machen, wird zusätzlich eine Erweiterungsschnittstelle, das sogenannte Northbound-Interface eingeführt.
  3. Auf dieser Schnittstelle setzen alle Anwendungen auf, die Informationen aus dem Netz und anderen relevanten Systemen abrufen, auswerten und die Entscheidungskriterien für den Controller liefern.

Um die visionäre Kraft dieses Konzepts weiter zu unterstreichen, wird an dieser Stelle gerne der Begriff vom „Netzwerkbetriebssystem“ eingeführt und mehr oder weniger überzeugende Analogien zur klassischen Rechnerarchitektur hergestellt (siehe Bild 3).

Der Leistungsumfang dieses Modells wird offensichtlich vom Funktionsumfang des Southbound-Interfaces bestimmt: Nur der Regelsatz, der vom Controller bereitgestellt und auch von den Netzwerkkomponenten unterstützt wird, kann genutzt werden.

Damit kommt dieser Schnittstelle für das betrachtete „One size fits all“-Modell eine erhebliche Bedeutung zu – und zwar nicht nur auf Controller-Seite, sondern auch in den Netzwerkkomponenten.

Das wichtigste Projekt zur Entwicklung einer solchen Schnittstelle ist natürlich OpenFlow.

OpenFlow wird mittlerweile von nahezu allen Herstellern zumindest in Teilen ihres jeweiligen Switch-Portfolios unterstützt, einschließlich einiger Herstellern von virtuellen Switches. Da im betrachteten Modell die Control Plane der Switches auf den Controller ausgelagert ist, hat OpenFlow damit das Potential, den für virtuelle Switche typischen Mangel an Funktionsumfang auszugleichen.

Trotzdem ist OpenFlow nicht das einzige Protokoll zur Realisierung eines Southbound-Interfaces. Die Alternativen reichen von XML über Routingprotokolle wie BGP und IS-IS bis zu ganz proprietären Lösungen.

Kritik am „SDN überall“-Modell

Der entscheidende Punkt bei diesem Modell (ein Controller steuert zumindest alle Layer-2- und Layer-3-Komponenten vollständig) ist, dass es alles im und um das Netzwerk ändert: die Art wie Datenströme durch das Netz geleitet werden, die Konzepte wie Datenströme voneinander getrennt werden, in der Regel müssen alle Komponenten ausgetauscht werden (lediglich in Ausnahmefällen reicht hier und da eine neue Firmware) etc. pp.

Natürlich könnte man argumentieren, dass man ja alle klassischen Netzwerkprotokolle im Controller nachbilden könne, und tatsächlich gibt es Ansätze, zum Beispiel IP-Routing controllerbasierend nachzubauen, inklusive Hop-Count-Reduzierung etc. Aber ernsthaft: Das ist doch absurd. Da wird eine neue Technologie entwickelt, um das Forwarding bedarfs- und anwendungsgerecht zentral steuern zu können, und dann emuliert man über diese zentrale Steuerung die klassischen dezentralen Regelungen? Das kann nicht der richtige Weg sein.

Wir brauchen lösungsorientierte Produkte, die SDN-Konzepte in unsere Netze integrieren und die Vorteile von SDN nutzen, ohne alles, was gut funktioniert, zu verwerfen.

Doch wo liegt der eigentliche Mehrwert von SDN? Einfach nur Switches und Router zentral steuern zu können, ist ein bisschen wenig, selbst, wenn das mit OpenFlow o. ä. eines Tages herstellerübergreifend möglich wäre.

Der entscheidende Punkt, der SDN zu „Software-Defined“ macht, ist das Northbound-Interface, die Schnittstelle des Controllers zu netzwerkrelevanten Informationen (siehe Bild 3)!

Genau das ist der Kern von SDN: Während klassische Netzwerkprotokolle auf dem Prinzip Lernen beruhen und ausschließlich Informationen aus dem Netz selbst zur Entscheidungsfindung heranziehen können, hat SDN zusätzlich Zugriff auf ergänzende Informationen aus weiteren Quellen.

Typische Beispiele hierfür sind:

  • das Hypervisor-Management (Wo befindet sich eine virtuelle Maschine? Welche MAC- und IP-Adressen hat sie? Wurde sie gerade bewegt? …),
  • das Cloud-Management (Welche Container werden gestartet? Sind andere Clouds angebunden? …),
  • Anforderungen der Anwendungen (Der folgende Datenstrom belegt eine bestimmte Bandbreite oder ist abhängig von maximalem Jitter, …).

Lassen Sie uns einen Blick auf solche Produkte werfen.

SDN zur Edge Provisionierung

Ein weiterer Problempunkt des oben diskutierten OpenFlow-Ansatzes ist, dass jedes einzelne Gerät im Netzwerk jedes eintreffende Paket zu den definierten Flows bzw. Regeln zuordnen muss, unabhängig davon wie komplex und aufwändig diese Zuordnung ist. Im Zweifelsfall bedeutet dies den Einsatz teurer ASICs – und zwar in jedem Gerät.

Deutlich einfacher ist dagegen der Ansatz, alle Pakete am Rand des Netzes zu markieren und sie ab dann nur noch anhand dieser Markierung weiterzuleiten. Nutzt man zur „Markierung“ etablierte Methoden wie beispielsweise Tunnelprotokolle, bedeutet das:

  • Der SDN-Controller ist ausschließlich für die Provisionierung der Tunnel zuständig.
  • Damit hat man eine funktionale Trennung des Netzes in SDN-gesteuerte Ingress-Systeme und ein klassisches Transportnetz.
  • Das Forwarding in diesem inneren Transportnetz kann mit Standardverfahren ohne SDN erfolgen.

VMware NSX ist ein Beispiel für den Einsatz einer solchen SDN-gesteuerten Edge Provisionierung (siehe Bild 4). Das Produkt verbindet virtuelle und physische Server durch Layer-2-Tunnel über ein IP-basierendes Transportnetz. Wie immer in einer solchen Umgebung verfügen die Tunnelendpunkte in den Hypervisors der Virtualisierungshosts und den Gateways jeweils über eine Zuordnungstabelle, in der verzeichnet ist, über welchen Tunnelendpunkt welcher Server erreichbar ist.

Wären wir jetzt in einem klassischen Umfeld, könnten sogenannte unknown Unicasts auftreten. Das heißt, der sendende Tunnelendpunkt findet die Zieladresse eines Servers nicht in seiner Zuordnungstabelle, er weiß also nicht welchen Tunnelendpunkt er adressieren muss. Klassisch bleibt dem Host daher nichts Anderes übrig als Broadcasts oder sogar Multicasts (da das Gesamtkonzept mandantenfähig ist) zu nutzen.

Anders im SDN-Umfeld: Hier hat der NSX-Controller eine Schnittstelle zum Hypervisor-Management und kann somit die Tunnelendpunkt bereits proaktiv darüber informieren, wo sich welcher virtuelle Server befindet und wann ein Server zu einem anderen Host verschoben wird (in der urspünglichen Nicira-Version des Produkts übrigens über OpenFlow). Es gibt keine unknown Unicasts.

SDN zur Sicherstellung von Quality of Service in Voice- und Video-Netzen

Microsoft hat als Teil seiner Skype-for-Business-Architektur eine interessante Schnittstelle geschaffen, die für SDN-Umgebungen genutzt werden kann. Das „Skype for Business SDN Interface“ ist kein Controller sondern im Sinne von Bild 3 eine Anwendung, die über die Northside-Schnittstelle des SDN-Controllers diesen mit netzwerkrelevanten Informationen versorgt (siehe Abbildung 5).
Im konkreten Fall sind dies Informationen über Kommunikationsverbindungen zwischen Skype-Usern, die der SDN-Umgebung in Echtzeit zur Verfügung gestellt werden. Hierzu gehören insbesondere (siehe Abbildung 6):

  • die IP-Adressen der Endgeräte,
  • die UDP-Ports der Medienströme,
  • die Art der Kommunikation (Voice, Video, Chat, Screen-Sharing, File-Transfer etc.),
  • Protokoll, Codec, Bandbreite und mehr.

Solche Informationen sind gerade in Netzen wie zum Beispiel WLANs, wo Bandbreite und Delay Störungen verursachen können, hilfreich, da sie zwei Probleme adressieren:

  1. Identifizieren von autorisierten Echtzeitverbindungen,
  2. Reservieren von Bandbreite.

Und tatsächlich gibt es eine Reihe von Herstellern, die diese SDN-Schnittstelle von Skype for Business abgreifen und die Information zur Steuerung von (Teil-)Netzen nutzen:

  • Die Hersteller Aruba Networks, Dell und Meru nutzen die Information in ihrer controllerbasierenden WLAN-Infrastruktur, um Voice- und Video-Ströme sowohl im Funknetz als auch im kabelgebunden Netz zu priorisieren.
  • HP hat eine passende Schnittstelle in ihrer „Network Optimizer SDN Application“ und kann via OpenFlow den einzelnen Datenströmen ebenfalls QoS-Policies zuordnen.

Die Forderung nach Standardisierung

In guter(?), alter Netzwerkertradition wird gerne gefordert, beide Controller-Schnittstellen, sowohl Northside als auch South-
side, müssten standardisiert werden – und tatsächlich finden sich die bekannten Hersteller reflexartig zusammen, um gemeinsame Verfahren festzuschreiben. Warum eigentlich?

Die böse, wenn auch nicht völlig aus der Luft gegriffene Antwort ist: Weil alle aus Erfahrung wissen, dass ein Standardisierungsprozess das beste Mittel ist, um eine Innovation möglichst lange aufzuhalten.

Ist aber eine Standardisierung dieser Schnittstellen überhaupt nötig oder gar sinnvoll?

Beim Southside-Interface ist man spontan noch am ehesten geneigt, eine standardisierte Schnittstelle zu fordern, um nämlich Interoperabilität mit der Netzwerk-Hardware zu erreichen.

Hier muss man genau hinschauen, wie die SDN-Umgebung ausschaut, welches Konzept umgesetzt werden soll. Denn obwohl die Southside-Schnittstelle von vielen gerne dem Controller zugeordnet wird, geht’s im Grunde um eine Schnittstelle in den Netzwerkkomponenten selbst!

Die Frage ist also, ob man über nur einen Controller herstellerübergreifend Netzwerkkomponenten steuern möchte. Wenn man diese Frage mit Ja beantwortet, braucht man natürlich tatsächlich ein standardisiertes Kommunikationsprotokoll wie beispielsweise OpenFlow. Konzeptionell ist es aber völlig überflüssig zu fordern, dass nur gleichartige Systeme über dasselbe Protokoll angebunden werden können. Das Gegenteil würde einen Controller deutlich flexibler machen. Schauen Sie noch einmal auf das obige Beispiel mit dem Skype-SDN-Interface: Warum sollten die genannten WLAN-Hersteller zusätzlich OpenFlow in ihren Access Points und ihren Controllern unterstützen? Klar wäre es nett, wenn man alle WLAN-Controller und Access Points herstellerübergreifend austauschen könnte, aber es ist doch ziemlich unrealistisch, das zu fordern.

Auch bei der nördlichen Schnittstelle bewerte ich eine Standardisierung eher als hinderlich. Natürlich wird man von einem Controller erwarten, dass er eine möglichst große Anzahl von Standardschnittstellen unterstützt. Dazu gehören sicherlich XML, REST u. ä., vermutlich auch BGP und LLDP, aber das heißt doch nicht, dass die Schnittstelle selbst einer aufwändigen Standardisierung unterworfen werden muss. Wir sprechen gerade über Software! Innovation ist hier wichtiger als Interoperabilität. Und wer besser ist, wird sich durchsetzen.

Zusammenfassung

Die Diskussion um SDN wird sehr technokratisch geführt – und meist steht dabei OpenFlow im Zentrum. Diese Fixierung auf OpenFlow verhindert aber den unbelasteten Blick auf SDN. SDN ist nicht gleich OpenFlow!

Die Intension von OpenFlow ist eine hardwareunabhängige Schnittstelle zwischen Controller und standardisierter Hardware (Southbound Interface).

Diese Idee des einen omnipotenten Controllers, der riesige Netze mit gleichartigen, billigen Switches steuert, ist aber auch zu interessant als dass man sie einfach ignorieren könnte. Ernsthaft umsetzen lässt sie sich aber nur in sehr speziellen Monokulturen, wie sie die sehr großen Provider betreiben. In Unternehmensnetzen ist die Realisierung dieses Konzepts zu aufwändig, mit zu vielen Risiken verbunden und bringt vor allem unter dem Strich zu wenig Mehrwerte.

SDN dagegen (SD steht für Software-Defined!) bezieht sich mehr auf das Norhbound Interface. Hier geht es um ein Konzept, zusätzliche Informationen zur Netzwerksteuerung hinzuzuziehen, auf die klassische Netzwerkprotokolle keinen oder zumindest keinen einfachen Zugriff haben.

Verzichtet man mit Blick auf diese Idee auf den einen Controller und auf die Hardwareunabhängigkeit der südlichen Schnittstelle, wird vieles deutlich einfacher und sinnvoller:

  • Der Controller steuert nicht in Alleinverantwortung den gesamten Netzverkehr, sondern greift nur Sonderfällen korrigierend ein. Beispiele sind unknown Unicasts in virtualisierten Serverumgebungen oder Voice-Datenströme, die im WLAN priorisiert werden.
  • Es können verschiedene spezialisierte Controller zur Steuerung spezieller, gegebenenfalls auch herstellerspezifischer Umgebungen nebeneinander genutzt werden.
  • In Umgebungen, wo es bereits zentrale Systeme zur Steuerung von Netzwerkkomponenten gibt (wie z. B. WLAN-Controller) können diese auch SDN-ähnliche Aufgaben übernehmen.

Die Forderung nach Standardisierung von Northbound Interface, Southbound Interface oder gar des ganzen Controllers erscheint vor diesem Hintergrund wie eine Verhinderungstaktik. Dabei geht es bei allem, was auf uns zukommt (Software-Defined Data Center, Cloud Computing etc.), gerade um das Gegenteil, nämlich um Flexibilität, Dynamik, Agilität.

Es drängt sich natürlich auf, SDN in virtualisierten Umgebungen einzusetzen: Virtuelle Netzwerkkonstrukte sind eh schon Software und es gibt ein übergeordnetes Management, das nahezu alles über die virtuelle Umgebung weiß und damit im SDN-Sinne eine ideale Informationsquelle zur Netzwerksteuerung ist.

Aber SDN ist nicht auf virtualisierte Umgebungen beschränkt. SDN ist der momentan der wichtigste, vermutlich sogar einzige Ansatz, um die Anforderungen von Anwendungen an das Netzwerk dynamisch und automatisiert umzusetzen. Hier geht es nicht um irgendwelche Tunnelprotokolle, es geht noch nicht einmal primär um den Betrieb Ihrer Netze. Es geht um den Betrieb Ihrer IT.

In diesem Sinne ist SDN immanenter Bestandteil jedes anwendungsbewussten (application aware) Netzes und ein wichtiger Baustein des Software-Defined Data Centers. Und hier wird die Zukunft der Unternehmens-IT entschieden – aber das ist ein anderes Thema.

zugeordnete Kategorien: Archiv, Klassiker
zugeordnete Tags:

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.