Next-Generation-Networks
SDN: Sinnvoll Definierte Netzwerke
Endlich! Software-Defined-Networking, kurz SDN, eine Technologie, die alle Probleme mit der Netzwerkinfrastruktur lösen wird. Wieder einmal.
Hatten wir das nicht schon einmal? In schöner Regelmäßigkeit sehen wir Technologien dem Gartner-Hype und seinen Phasen folgen. Was vor zwei Jahren noch die Fabrics und auch FCoE (Fibre-Channel over Ethernet) waren - wobei FCoE sich gerade im „Through of desillusionment” befindet - ist SDN auf dem „Peak of inflated expectations”. Oder kann man die Diskussionen zu den Problemlösungen durch SDN, die Anzahl der Startups in diesem Bereich, eine unklare Definition von SDN und den Kauf eines kleinen Startups für 1,25 Milliarden Dollar durch Vmware anders interpretieren? Klar ist für mich, dass SDN eine Technologie ist, die zum Bleiben gekommen ist. Die Konzepte machen sehr viel Sinn; wir bei Enterasys hatten schon in den frühen Neunzigerjahren damit experimentiert und forcieren seit einigen Jahren diese Art des Networking, ohne es je SDN genannt zu haben. Viele Kunden setzen sie heute erfolgreich ein. Auch in der Telefonie waren IN (Intelligente-Netze) schon immer präsent. Was aber genau ist SDN?
Alle Definitionen haben gemeinsam, dass man die Control-Plane von der Data-Plane im Netzwerk sowie den Komponenten separiert und so weit zentralisiert wie möglich. So erreicht man eine bessere zentrale Verwaltung. Dazu ergeben sich Möglichkeiten zur einfachen Service-Definition, höhere Flexibilität, Agilität und ein hoher Automatisierungsgrad durch die Integration mit anderen IT-Applikationen (via „Northbound-APIs”). Dazu zählt unter anderem die Integration von Servervirtualisierungslösungen im Rechenzentrum. Die Netzinfrastruktur lässt sich einfacher unterteilen. Zudem kann bei entsprechender Standardisierung ein Kostenvorteil erzielt werden, da die Netzinfrastruktur autauschbar wird. Zwar versucht gerade die Openflow-Community („OpenFlow“ wurde an der Fakultät für Computerwissenschaften an der Universität Stanford spezifiziert) via der ONF - der Open Network Foundation - das SDN-Protokoll zu positionieren, aber SDN ist weit mehr als nur Openflow. Und auf Openflow-basierende Ansätze sind aktuell noch zu weit weg von einer für Unternehmen einsetzbaren Lösung, die einfach, skalierbar und stabil sein muss. An Universitäten wird damit eifrig experimentiert und auch die Service-Provider (wie die Deutsche Telekom) sowie die großen Cloud-Datacenter-Provider (wie Google oder Facebook) versuchen hier in entsprechenden Testbeds Erfahrungen zu sammeln. Teilweise wird von Implementierung in der Produktion gesprochen - diese sind jedoch sehr übersichtlich, was die Größe angeht. Unter anderem ist diesen Institutionen gemein, dass für sie Networking Kernkompentenz ist und sie entsprechend viele Experten haben, die sich dem Thema widmen. In vielen Unternehmen ist das heute nicht der Fall. Da muss es einfach funktionieren. Es ist noch ein langer Weg zu beschreiten. Und vielleicht kommt man hier nie am Ziel an.
Neben der Standardisierung ist eine weitere Problematik die Skalierbarkeit einer solchen Lösung: Eine totale Zentralisierung (der Control-Plane) bringt zwar auf dem Papier Vorteile für das Management mit sich, jedoch sind Verfügbarkeit und insbesondere Skalierung ein Problem. Die Definition der IP-Flows erfolgt heute beispielsweise bei den Openflow-Testbeds typisch in einer sehr groben Weise und ist statisch vordefiniert. Man muss sich vorher überlegen, wer mit wem kommunizieren möchte - typisch auf IP-Subnetzbasis (Stichwort: Wildcards, Maskierung von Teilen des IP-Headers wie TCP/UDP-Ports etc.).
Wenn man aber eine granulare Kontrolle möchte, sprich Flows aus allen Feldern des IP-Headers erzeugt und das ganze dynamisch, das heißt die Entscheidung zur Programmierung von Flows in der Data-Plane in Echtzeit durchführen will, funktioniert dies mit einer solchen zentralen Architektur wie sie Openflow vorschlägt, nicht mehr. Man muss pro User mit mehreren Flows pro Sekunde rechnen und damit mit mehreren 100.000 Flows pro Sekunde in größeren Netzen - zentral ist dies nicht mehr verwaltbar und wird auch durch heutige Switch-Architekturen nicht unterstützt. Es sei denn, man setzt etwa auf eine „CoreFlow2 ASIC“-Architektur auf, die Switch-Systeme mit bis zu 64 Millionen Flows unterstützt. Commodity-ASICs, die auch Teil der Kostenargumentation pro Openflow sind, bewegen sich im Bereich von 1.000 bis 10.000 Flows. Für die zuvor erwähnte hohe Anzahl von möglichen Flows müsste man wieder eine verteilte Architektur für die Control-Plane wählen und damit steigt die Komplexität wieder an, beziehungsweise sie bietet keine Vorteile gegenüber der heutigen verteilten Architektur einer Netzwerkinfrastruktur. Wir sehen daher eine hybride Architektur für den Aufbau eines SDN als sinnvoll an: Das Management von Flows, Topologiemanagement und Routingentscheidungen wird dezentral getroffen, so wie es heute auch üblich ist; die Service-Definition erfolgt zentral und wird auf alle Komponenten im Netz verteilt. Über Northbound-APIs erfolgt die Integration mit anderen IT-Applikationen. Dadurch erreicht man die Vorteile, die mit einer SDN-Architektur einhergehen in einer sicheren, stabilen und skalierbaren Art und Weise. Dies spiegelt die Anforderungen der Unternehmens-IT heute besser wider. Je nach Fortschritt in der Standardisierung werden einzelne Protokolle nach und nach durch Standards ersetzt. Die Offenheit von Schnittstellen - die Northbound-APIs - ist zunächst entscheidend, damit die Vorteile eines SDN in Bezug auf Flexibilität und Automatisierung genutzt werden können. Wie anfangs erwähnt - SDN ist gekommen, um zu Bleiben. In welcher Ausprägung ist jedoch noch offen, und die nächsten zwölf bis 24 Monaten werden richtungsweisend sein. Kunden sollten nicht blindlings einem Hype folgen, sich aber gut überlegen, wie sie SDN-Architekturen und Konzepte zu ihrem Vorteil heute schon nutzen können.
- SDN: Sinnvoll Definierte Netzwerke
- Europa ist bereit für Software-Defined-Networking
Lesen Sie mehr zum Thema
