Statement
Software-Defined-Networking
Das Thema Software-Defined-Networking ist derzeit in aller Munde und der "Open Networking Summit" in Santa Clara, Kalifornien, sowie der "OpenStack Summit" in Portland, Oregon, haben zu einer Flut von Ankündigungen in diesem Bereich geführt. Generell steht die Netzwerk-Industrie vor massiven Veränderungen, weil sich die Anforderungen an das Netzwerk in großen Cloud-, Rechenzentrums- und Telko-Umgebungen in den letzten Jahren durch den Einsatz von Virtualisierungstechnologien sehr verändert haben.
Software-Defined-Networking, kurz SDN, revolutioniert die Netzwerke in Cloud-, Datacenter und Telko-Umgebungen. Drei Ansätze für die Lösung sehr unterschiedlicher Probleme lassen sich derzeit unterscheiden: Openflow, Overlay-Netzwerke und Network-Functions-Virtualization (NFV).
Openflow
Openflow entstand im Campus-Umfeld (der Universitäten von Stanford und Berkeley), weil die Forscher mit neuen Protokollen experimentieren wollten ohne die Software in ihren Netzwerk-Geräten bei jedem Versuch neu zu ändern. So entstand die (nicht neue) Idee die Data/Forwarding- und Control-Plane zu separieren und eine zentralisierte Control-Plane, den so genannten Openflow-Controller zu verwenden. Das Betriebssystem der Netzwerk-Hardware wird hierbei durch das Openflow-Instruction-Set ersetzt und der Controller übernimmt die Rolle eines Netzwerk-Betriebssystems, das per SSL mit den einzelnen Geräten kommuniziert.
Die übermittelten Openflow-Instruktionen bestehen dabei aus regulären Ausdrücken für die verschiedenen Felder (Quell- und Ziel-MAC/IP-Adresse, VLAN-ID, etc.) von Netzwerk-Paketen und entsprechenden Aktionen (wegwerfen, weiterleiten an Port X, etc), die vom Netzwerk-Endpunkt ausgeführt werden. Hierbei kann es sich um physische oder auch virtuelle Switche, FPGA- und SR-IOV/Openflow-fähige Netzwerk-Karten handeln. Gerade letztere eröffnen die Möglichkeit hardwarebeschleunigte Openflow-Netzwerke bis zu den virtuellen Maschinen hin zu erstellen.
Da der Controller zu jedem Zeitpunkt sowohl die Topologie als auch die Performance-Daten des gesamten Netzwerks kennt, kann er problemlos mehrere Pfade parallel verwenden (Multipathing), Optimierungen beliebiger Art vornehmen (nach Durchsatz, Stromverbrauch, etc.) und bei Engpässen oder Ausfällen entsprechend reagieren.
Es gibt mittlerweile eine Vielzahl von Open-Source und proprietären Openflow-Controllern in den verschiedensten Programmiersprachen (C/C++, Python, Ruby, Java, Erlang, etc.). Um Openflow zu standardisieren, wurde ein anwendergetriebenes Konsortium – die Open Networking Foundation – ins Leben gerufen, bei dem mittlerweile alle bekannten Hersteller (Cisco, IBM, HP, Dell, Juniper, Arista, etc.) Mitglieder sind.
Parallel dazu gibt es seit kurzem das „OpenDaylight-Projekt“ unter dem Dach der Linux Foundation, welches bis Ende des Jahres die erste Version einer produktionsreifen, Open-Source-basierenden SDN-Plattform erstellen will.
Openflow ist dabei nur eine von vielen möglichen (Southbound-)Schnittstellen von Open-Daylight. Andere sind Overlay-Netzwerke oder herstellerspezifische Schnittstellen zu klassischen Netzwerk-Geräten. Interessant wird Open-Daylight durch die geplanten Netzwerk-Service-Funktionen und „RESTful APIs“, die von den unterschiedlichsten Cloud-Orchestrierungstools (Openstack, „IBM SmartCloud Orchestrator“, etc.) verwendet werden können und völlig neue Netzwerk-Service-basierende Geschäftsmodelle ermöglichen.
- Software-Defined-Networking
- Overlay-Netzwerke
- Network-Function-Virtualization
Lesen Sie mehr zum Thema
