Lange ist es her, dass eine neue Technologie so überwältigendes Interesse fand wie Software-Defined Networking. Doch noch schrecken viele Unternehmen davor zurück, SDN einzusetzen, denn es fehlen die praktischen Erfahrungen bei Migration und Betrieb. Diese Lücke will die ONF (Open Networking Foundation) nun zumindest partiell schließen.
Bis zum Jahr 2017 soll der SDN-Markt für Rechenzentren und Unternehmen weltweit ein Volumen von drei Milliarden Dollar haben, prognostiziert Infonetics.10 Prozent der Ethernet-Switches sollen bis dahin mit SDN-Fähigkeiten ausgerüstet sein. Laut Infonetics-Analyst Michael Howard zögern Provider bereits bei Switch- und Routereinkäufen, um sich für die Umstellung auf SDN nicht gerätetechnisch falsch zu positionieren.
Wie aber vollzieht man eine Migration zu SDN? Schließlich soll der Übergang zu der neuen, softwaregesteuerten Infrastruktur möglichst reibungslos erfolgen – ohne Betriebsausfälle, Sicherheitslücken oder Datenverluste.
Mit diesem Thema befasst sich das Whitepaper „Use Cases and Migration Methods“ der Arbeitsgruppe Migration der ONF (Open Networking Foundation). Es zeigt zunächst an einigen prominenten Beispielen wie Googles internem Netzwerk oder dem Campusnetz der Stanford-Universität, wie die Migration in unterschiedlich gelagerten Fällen abgewickelt werden kann. Erkennbar ist daraus, dass es keinen für alle Situationen passenden, einschlägigen Migrationsweg gibt.
Keine Standardmigration
Diese Erkenntnis setzt die ONF anschließend in grundlegende Überlegungen um, die jeder Anwender, der an einen Umstieg auf die neue Technologie denkt, beherzigen sollte. Dabei standen hinsichtlich des neuen Netzwerkdesigns, die ONF spricht von Target Network, unter anderem folgende Ziele im Mittelpunkt:
Das Zielnetz soll mit Hilfe von APIs programmierbar sein und verschiedene Funktionen durch Durchgriff auf die unteren Netzwerkebenen/Geräte kombinieren oder erweitern. Es soll dynamische Softwareupdates ohne Unterbrechungen ermöglichen, heterogene Gerätewelten unterstützen und mittels Software wartbar sein.
Das Papier unterscheidet zwischen direktem Upgrade und schrittweiser Migration; bei letzterer sind die bisherige und die neue Kontrollebene zeitweise parallel in Aktion. Weitere Migrationstypen sind die Implementierung von SDN-Overlay-Diensten und die hierarchische Open-Flow-Kontrolle, bei der zwischen einzelnen Endpunkten nicht mit OpenFlow gearbeitet wird, die obersten Kontrollebenen aber über OpenFlow abgebildet sind.
In der Praxis dürfte es selten komplette Greenfield-Ansätze geben. In der Regel wird man gemischte oder hybride Ansätze vorfinden. Bei gemischten Architekturen koexistieren Open-Flow- und traditionelle Systeme. Mit traditionellen Systemen auf der unteren Ebene kann der neue OpenFlow-Controller aber nur über den hergebrachten Controller kommunizieren.
Bei hybriden Ansätzen implementiert man neben den bestehenden traditionellen sowohl reine OpenFlow-Systeme als auch solche, die traditionelle und OpenFlow-Technologie gleichzeitig unterstützen. Letztere können mit dem OpenFlow- und dem traditionellen Controller kommunizieren. Welcher Ansatz jeweils passend ist, lässt sich nur im Einzelfall entscheiden.
Sollen Domain- übergreifende Ende-zu-Ende-Services via OpenFlow implementiert werden, braucht man immer einen OpenFlow-Controller auf der obersten Ebene. In den einzelnen Domains müssen nicht alle Geräte OpenFlow unterstützen, die Realisierung ist auch über gemischte oder hybride Infrastrukturen hinweg möglich.
Die Netzwerkinfrastrukturen auf dem Campus, in Unternehmensrechenzentren, in Kollokations- oder Multi-Tenant-Umbegungen und Carriernetzen haben jeweils unterschiedliche Charakteristiken, die bei der SDN-Implementierung zu berücksichtigen sind. So sind beispielsweise in Unternehmensrechenzentren Applikationsdienste häufig besonders wichtig, Campusnetze sind meist vielfach logisch partitioniert, im Multi-Tenant-Rechenzentrum werden Lasten häufig zwischen Servern verschoben und Providernetze integrieren in der Regel unterschiedliche Netzwerktypen – vom Mobilnetz bis zum Glasfaserbreitband-Backbone.
Zudem muss bei der Implementierung sorgfältig darauf geachtet werden, auf welchen Netzwerkebenen und Geräten Open-Flow-Funktionen sinnvoll und notwendig sind. Kandidaten für Open-Flow-Agenten oder -Systeme sind immer diejenigen Geräte, die Verbindungen oder Dienste terminieren beziehungsweise neu ins Netz integrieren.
Eine diesbezüglich durchdachte Migration ermöglicht es, im Einzelfall zu entscheiden, ob und wo traditionelle Geräte bleiben können, wo hybride Geräte eingesetzt werden können und wo reine Open-Flow-Systeme notwendig sind. Auch die zu erwartenden Charakteristiken der Flow-Typen müssen dabei erwogen werden: Echtzeit-Sprache braucht andere Verbindungseigenschaften als Multicast-Video, SAP-Abrechnungen oder Best-Effort-Daten. Dabei gilt es, alle architektonischen Erwägungen und Entscheidungen sorgfältig zu dokumentieren.
Nicht zu vergessen, wird die Sicherheit immer wichtiger. In SDN-Infrastrukturen sollte sie zentral bereitgestellt werden, aber flexibel genug sein, schnell auf neue Bedrohungen zu reagieren. Durch Analyse des Netzwerkgeschehens und Ad-hoc-Veränderung von Datenpfaden bei Sicherheitsbedrohungen können OpenFlow-Infrastrukturen nach Meinung der ONF sogar sicherer sein als konventionelle Netze. Empfohlen wird, einen experimentellen Dienst – zum Beispiel ein VLAN – zu definieren, diesen zunächst mit offenen SDN-Sicherheitslösungen zu härten, die entsprechenden Lösungen freizuschalten und erst dann die Anwender dorthin zu migrieren.
Ohne gründliche Vorbereitung keine erfolgreiche Migration
Schließlich gibt die ONF eine Reihe generalisierter Empfehlungen zur Migrationsplanung und dem Migrationsablauf. So sollte die Vorbereitung mit einer Analyse funktionaler Lücken und ihrer Auswirkungen auf Services beginnen. Vor und nach der Migration sollten spezifische Applikationen und Verbindungen anhand von Checklisten auf Funktion überprüft und Fehler auf ihre Verursachung durch den Migrationsprozess hin analysiert werden.
Vor dem eigentlichen Migrationsvorgang muss zudem das Ursprungsnetz in einen stabilen Status gebracht werden. Ideal ist es, wenn man für fehlgeschlagene Migrationsprozesse einen automatisierten Rückweg zur ursprünglichen Netzkonfiguration offen hält, damit daraus keine verschlechterte Servicequalität oder gar Unterbrechung resultiert. Zudem sollte der OpenFlow-Controller bereits im Vorfeld einer genauen Anforderungsanalyse unterworfen werden.
Schon während der Migration sollten die Werkzeuge für das zukünftige Management und Monitoring der SDN-Infrastruktur bereitstehen. Es gilt sicherzustellen, dass alle OpenFlow-Geräte mit dem OpenFlow-Controller kompatible OpenFlow-Versionen fahren. Firmware und Code müssen eventuell entsprechend aktualisiert werden.
Außerdem sollte man prüfen, ob die Verbindung zwischen den einzelnen Geräten und dem OpenFlow-Controller auch tatsächlich funktioniert. In gemischten Umgebungen empfiehlt es sich, zunächst einen Testservice einzurichten und zu sehen, ob dieser funktioniert. Außerdem sollte man von vorn herein Routinen von hintereinander abzuwickelnden Tests zur Prüfung von Verbindungen für den Fehlerfall festlegen.
Was mit der Migration im Einzelnen angestrebt wird, sollte man aufschreiben. Nach der Migration überprüft man dann am migrierten Netz und der Zieldokumentation, ob die Infrastruktur wie gewünscht funktioniert.
Die ONF sieht diese Hinweise nicht als abschließend an, sondern betont, dass SDN sich in einer rasanten Entwicklung befindet. Die Implementierungsregeln werden daher wohl in Zukunft verfeinert und immer wieder dem aktuellen Stand der Technik angepasst.
+49 (0)6324