Software Defined Networking: Quo Vadis

Kommentieren Drucken

Endlich! Eine Technologie, die alle Probleme mit der Netzwerkinfrastruktur lösen wird. Wieder einmal. Aber hatten wir das nicht schon einmal? In schöner Regelmäßigkeit sehen wir Technologien dem Gartner Hype und seinen Phasen folgen. Was vor 2 Jahren noch die Fabrics und auch FCoE (Fibre Channel over Ethernet) waren – und 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 der Kauf eines kleinen Startups für 1,25 Milliarden USD 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 90ern damit experimentiert und forcieren seit einigen Jahren diese Art des Networking, ohne es je SDN genannt zu haben. Viele Kunden setzen die heute erfolgreich ein. Auch in der Telefonie waren IN Intelligente Netze auch schon immer präsent. Was aber genau ist ein SDN?

Nun ja, alle Definition haben gemeinsam, dass man die Control Plane von der Data Plane im Netzwerk und den Komponenten – bis zu einem gewissen Maße – separiert und so weit zentralisiert wie möglich. Damit erreicht man eine bessere zentrale Verwaltung und Möglichkeiten zur einfachen Service-Definition, höhere Flexibilität, Agilität und einen hohen Automatisierungsgrad durch Integration mit anderen IT-Applikationen (via “Northbound APIs”) bei der Definition neuer Services im Netz – wie zum Beispiel mit der Integration von Servervirtualisierungslösungen im Data Center. Die Netzinfrastruktur kann logisch einfacher unterteilt warden – Stichwort Netzwerkvirtualisierung – und man soll bei entsprechender Standardisierung einen Kostenvorteil erzielen können, da die Netzinfrastruktur austauschbar wird. Aber gerade dort ist noch viel zu tun. Zwar versucht sich 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 – als das SDN-Protokoll zu positionieren, aber SDN ist weit mehr als nur OpenFlow. Und auf OpenFlow-basierende Lösungen 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 z.B. die Deutsche Telekom) sowie die großen Cloud Data Center Provider (Google, Facebook und anderen sind sehr in der ONF aktiv) versuchen hier in entsprechenden Testbeds Erfahrungen zu sammeln. Teilweise wird von Implementierung in Produktion gesprochen – diese sind jedoch mehr als ü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 niemals am Ziel an. Neben der Standardisierung ist eine Problematik die Skalierbarkeit eine 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 z.b. erfolgt heute bei den OpenFlow Testbeds typisch in einer sehr groben Weise und ist statisch vordefiniert. D.h. man muss sich vorher überlegen, wer mit wem kommunizieren möchte – typisch auf IP-Subnetz-Basis (Stichwort Wildcards, Maskierung von Teilen des IP-Headers wie TCP/UDP-Ports usw.). Wenn man aber eine granulare Kontrolle möchte, d.h. Flows aus allen Feldern des IP-Headers erzeugt und das ganze dynamisch, d.h. 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 100k Flows pro Sekunde in größeren Netzen – zentral ist dies nicht mehr managebar und auch durch heutige Switch-Architekturen nicht unterstützt. Es sei denn, man setzt auf die CoreFlow2-ASIC-Architektur von Enterasys auf, die heute Switch-Systeme mit bis zu 64M Flows unterstützt. Commodity ASICs, die auch Teil der Kostenargumentation pro OpenFlow sind, bewegen sich typischerweise im Bereich von 1k bis 10k 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 bzw. 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 Routing-Entscheidungen werden 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 und man erreicht dadurch 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 wieder. 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. Dies wird durch unsere Management heute schon geleistet – und selbst southbound zur Infrastruktur werden ausschließlich standardisierte Protokolle verwendet.

Wie Anfangs erwähnt – SDN ist gekommen, um zu bleiben. In welcher Ausprägung jedoch ist noch offen und die nächsten 12 bis 24 Monaten werden hier wohl 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.

zugeordnete Kategorien: LAN, Virtualisierung
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.

*

.