Die Netzwerke unterliegen, genauso wie der Rest der IT, einem ständigen Wandel. Dies gilt für die generelle Architektur und natürlich erst recht für die eingesetzten konkreten Technologien. Die frühen Netzwerke wurden als Ring (Token Ring) konzipiert. Die Ringstruktur wurde später durch ein Bus-System (Ethernet) abgelöst. Sowohl auf dem Ring als auch auf dem Bus werden die Datenpakete an alle Knoten geleitet. Die Netzwerkkarte entscheidet dann anhand der Adresse, ob sie das Paket annehmen will.
Mit zunehmender Größe der Netzwerke wurden Ringe und Busse immer mehr zum Engpass. An ihre Stelle trat die strukturierte Verkabelung. Hierbei ist das Netzwerk als mehrstufiger Baum realisiert. Die unterste Ebene bilden dabei die Anschlusspunkte für Server und Desktops. Für Clients ist dies meist sein Standardrouter. Eine Stufe darüber finden sich die Aggregation-Switches. Ihrem Namen folgend sammeln (aggregieren) sie die Endgeräte zu einem größeren Verbund. Am oberen Ende der Netzwerkstruktur befinden sich schließlich die Core Switches. Sie sind direkt mit dem Backbone (dem Rückgrat) der Verkabelung verknüpft.
Strukturierte Verkabelung zementiert die Netze
Diese Strukturierung des gesamten Netzwerks ermöglicht die Optimierung der Kommunikation nach den jeweiligen Anforderungen. Aufgrund des mehrstufigen Aufbaus werden die Datenpakete immer über mehrere Knoten vom Sender zum Empfänger geleitet. Allerdings haben die traditionellen Router, die auf der Ebene des IOS/OSI-Layer 3 arbeiteten, heute meist ausgedient. Anstelle des Routings anhand der Layer-3-Informationen und der IP-Adresse ist nunmehr das Layer-2-Switching getreten. Dabei erfolgt das Routen anhand der MAC-Informationen, nicht der IP-Adressen. Die prinzipielle Technik allerdings ist im Kern die gleiche geblieben.
Die Netzwerkbaugruppe, die das Paket annimmt, entscheidet anhand der Information im Header des Datenpakets, wohin das Paket weitergeschickt werden soll. Ziel der strukturierten Verkabelung ist, den richtigen und wenn möglich schnellsten Weg für die Datenpakete zu finden - egal ob diese nun über einen Router oder einen Switch geschleust werden. Eine zweite zentrale Forderung an jegliche Kommunikation ist die Absicherung des Weges gegen Ausfälle oder temporäre Engpässe. Das TCP-Protokoll sorgt dabei für eine gesicherte Übertragung, unabhängig vom gewählten Weg. Dazu müssen aber mehrere mögliche Wege vom Sender eines Datenpaketes zum Empfänger existieren. Dies erfolgt durch die Routing-Protokolle.
Heutige Anforderungen verlangen nach Dynamik
Die strukturiert Verkabelung kann ihre Vorzüge vor allem bei festgezurrten Strukturen ausschöpfen. Den Systemen kann genau die Netzanbindung und Bandbreite zugewiesen werden, die sie benötigen oder erhalten sollen. So lassen sich zwei Server mit hohem Kommunikationsaufkommen kurzerhand über einen Top-of-Rack-Switch direkt miteinander verschalten, oder sie kommunizieren nahe am Backbone miteinander. Für Desktops mit geringer Last werden die Pakete jedoch über mehrere Stufen (Hops) zum Empfänger geschleust. Änderungen an solchen Strukturen sind eher selten - dann aber aufwendig.
Foto: Juniper
Doch die Neuerungen der IT passen immer weniger zu den bestehenden Netzwerkstrukturen. Virtualisierung, Cloud Computing oder mobile Mitarbeiter mit wechselnden Standorten haben besondere Anforderungen an die Netzwerkstrukturen. Die dynamische Bereitstellung von Server und Ressourcen, wie es diese Technologien benötigen, erfordert eine flexible Anpassung der IP-Adressen oder der MAC-Adressen oder spezielle VLAN-Konfigurationen. So werden zum Beispiel die Anschlusspunkte von stationären Desktops gepatched - nicht aber die Verbindung der mobilen Benutzer im WLAN. Sie müssen automatisiert durchgeschaltet werden.
Konzept des Software Defined Networks
Da die traditionellen Netzwerktechniken für die aktuellen Anforderungen nur bedingt geeignet sind, suchten die Hersteller nach neuen Lösungen. Software Defined Networks sollen für eine flexiblere Netzwerkkonfiguration sorgen. Dabei wird die traditionelle dreistufige Netzwerkarchitektur zugunsten eines flexibleren Netzwerk-Layouts aufgelöst. An die Stelle der physischen Verkabelung tritt dabei die softwarebasierte Konfiguration der Routen. Herkömmliche Netzwerke sind dafür zu starr. Dennoch sind Software Defined Networks nicht in der Gänze als neu zu betrachten. Die Technologie greifen vielmehr auf positive und gewünschte Eigenschaften der Vergangenheit und deren Netzwerkprotokolle, wie Spanning Tree oder Open Shortest Path First (OSPF), zurück.
Spanning Tree ist ein Routing-Protokoll. Dessen Ziel liegt in der Optimierung des Weges. Spanning Tree sorgt dafür, dass es immer nur einen gültigen Weg zwischen zwei Netzwerkknoten gibt. Durch die Abstimmungen des Protokolls sollen Schleifen oder redundante Pfade verhindert werden. Denn dies könnte zum Beispiel unerwünschte Duplikate von Daten zur Folge haben, was wiederum Netzwerkfehler nach sich ziehen könnte.
Spanning Tree wurde mittlerweile zu Rapid Spanning Tree Protocol (RSTP) weiterentwickelt. RSTP kommt besser mit den laufenden Änderungen in der Netzwerkstruktur zurecht. Um die Nachteile von Spanning Tree zu umgehen, greift man oftmals auf Open Shortest Path First (OSPF) zurück. Auch OSPF dient, wie Spanning Tree, zur Wegebestimmung zwischen zwei Knoten. OSPF kann als Weiterentwicklung des RIP (Routing Information Protocol) oder auch Spanning Tree betrachtet werden. OSPF ist ein Layer-2-Multipath-Protokoll. Layer-2-Multipath-Implementierungen basieren auf einem vermaschten Netzwerk. Auch Software Defined Networks setzt auf solche flachen Netzwerke auf.
Das Kernstück von OSPF ist eine Tabelle der benachbarten Router, zu denen eine Netzwerkbaugruppe Verbindung hat. Durch den Austausch von Routing-Informationen wird die Tabelle aufgebaut und dann auch laufend aktualisiert. Auch TRILL (Transparent Interconnect of Lots of Links) soll, ebenso wie Spanning Tree oder OSPF, die Flusssteuerung in Netzwerken verbessern. Es vermeidet die Nachteile von Shortest Path Routing, die im Zusammenhang mit beliebigen Netzwerktopologien auftreten können. TRILL verlangt beziehungsweise definiert ein spezielles Protokoll und Informationen des Link State Routing. Durch das Link State Protokoll werden benachbarte Bridges über die Existenz der weiteren Bridges informiert. Es dient dazu, den nächstgelegenen Netzwerkknoten zu ermitteln.
Netzwerkkonfiguration durch eine zentrale Instanz
Beim Software-Defined Network werden Netzwerkbaugruppen wie Router und Switches von einer zentralen Verwaltungsinstanz gesteuert und konfiguriert. Dazu wird die Kontrollschicht der Netzwerkbaugruppen auf einen zentralen Punkt zusammengezogen. An die Stelle einer verteilten Verwaltung unterschiedlicher Switches oder Router tritt nun das zentrale Management.
Foto: OpenFlow.org
Dies erlaubt eine weitaus schnellere Reaktion auf die Erfordernisse. An die Stelle des manuellen Patchens von Verbindungen treten programmgesteuerte Kommunikationswege. Dazu müssen die Netzwerkbaugruppen mit einem Programmier-Interface ausgestattet sein. Ferner wird eine Verwaltungssoftware mit angebundener Managementkonsole benötigt. Die Verwaltungskomponenten kennt somit immer den aktuellen Zustand des Netzwerks und kann damit schnell reagieren.
Foto: OpenFlow.org
Die Pfade zwischen zwei Knoten - sie werden oftmals als "Flow" bezeichnet - bestimmen den Weg, den ein Paket vom Sender zum Empfänger zurücklegen muss. Dies ermöglicht auch eine dynamische und programmgesteuerte Konfiguration des Netzwerks. Software Defined Networks gehen damit in den Möglichkeiten weiter, als es die Netzwerkverwaltungsprotokolle heute zulassen. Letztere versuchen, durch die Optimierung eines Pfades das bestehende Netzwerk bestmöglich zu nutzen.
Software Defined Networks allerdings setzen vorher an: Sie ermöglichen die Konfiguration eines Netzwerks nach den Anforderungen. Der zentral platzierte Controller verwaltet dabei die Einträge in den Forwarding-Tabellen und bestimmt somit, welchen Weg die Pakete nehmen sollen. Dazu nimmt er dynamisch Einträge in der "Flow-Table" vor oder löscht andere, die nicht mehr benötigt werden.
OpenFlow - das Protokoll für Software Defined Networks
Software Defined Networks sind Blaupausen für neue Netzwerkstrukturen. Die Hersteller von Netzwerkbaugruppen können diese nach eigenen Vorstellungen umsetzen. Eine konkrete Implementierung für das Modell eines Software Defined Networks ist OpenFlow. OpenFlow-Netzwerke basieren somit auf den Vorgaben von Software Defined Networks. Sie implementieren einen dynamischen Netzwerkaufbau und können auch als Alternative zu Layer-2-Architekturen betrachtet werden.
Foto: Cisco
Das OpenFlow-Protokoll trennt ganz im Sinne des Software Defined Networks die Datenebene- und die Steuerungsebene. Dadurch kann eine im Controller sitzende Verwaltungsinstanz den Weg der Datenpakete kontrollieren. Dies basiert auf einem Regelwerk, ähnlich wie es bei Firewalls verwendet wird. Nur definiert dieses Regelwerk nicht den Zugang zu den Systemen, sondern den Weg, den die Datenpakete vom Sender zum Empfänger nehmen sollen.
In einem Software Defined Network werden die Router und Switches durch eine zentrale Managementsoftware gesteuert. Bei OpenFlow wird die Kontrollschicht von einer Data Forwarding Plane abstrahiert. Dabei erhält ein zentraler Netzwerk-Controller immer eine aktuelle Sicht auf den Netzwerkstatus. Dies erfolgt in Echtzeit und umfasst auch das gesamte, durch den Controller verwaltete Netzwerk.
Durch den Controller werden Netzwerkpfade definiert, auch "Flows" genannt. Diese geben dem Konzept auch den Namen. Der Controller verteilt die Flow-Daten an seine angeschlossenen Switches und Router. Über diesen Weg weist der Controller seine Switches und Router an, an welche nachgeschalten Ports die Datenpakete weiterzuleiten sind. Durch OpenFlow soll damit ein standardisiertes Netzwerk entstehen. Dies muss nicht unbedingt der präferierte Weg der Hersteller sein, denn Standards drücken meist auf den Preis, der für Produkte zu erzielen ist. Jedoch wird sich kein Hersteller diesem neuen Konzept ganz verschließen können.
Foto: HP
Die Hersteller von Netzwerkbaugruppen arbeiten daher derzeit an der Umsetzung der neuen Anforderungen. Hewlett-Packard bietet FlexFabric-Switches mit OpenFlow-Features an. Auch NEC hat bereits mehrere OpenFlow-basierte Netzwerkgeräte im Angebot. Korrespondierend dazu liefert der Netzausrüster mit dem ProgrammableFlow Controller (PFC) auch einen passenden Verwaltungs-Controller.
IBM gehört zu den Gründern der OpenNetworking Foundation. Das Unternehmen hatte bereits vor Jahren OpenFlow 1.0 in den 10-Gbit-Ethernet-Switch (RackSwitch G8264) integriert. Der Switch unterstützt auch die IBM-Virtual-Fabric-Architektur. Diese erlaubt eine Reduktion der I/O-Adapter auf einen einzigen Dual-Port-10-Gbit-Adapter.
OpenFlow für vSphere
OpenFlow ist aber nicht die einzige Umsetzung für ein SDN. Auch VMware arbeitet mit Arista Network an einer Implementierung für eine SDN. Das als VXLAN bezeichnete Konzept soll durch Kapselung und Segmentierung die virtuellen Maschinen unabhängig von der Netzwerkanbindung eines ESX-Hosts machen. Das Interesse von VMware an dem Thema ist leicht nachvollziehbar.
Um schneller auf Laständerungen in den vSphere-Strukturen zu reagieren, hält VMware schon heute ein ganzes Bündel an Techniken bereit. Ausgehend von vMotion über DRS (Distributed Resources Scheduler) bis hin zu Storage vMotion hat der Virtualisierungsspezialist mehrere Ebenen, um die virtuellen Strukturen dynamischer zu gestalten.
Eine physikalische Verdrahtung des Netzwerks lässt sich nur dann schnell ändern, wenn das Netzwerk per Software angepasst wird - just so, wie es durch SDN gefordert wird. Arista arbeitet derzeit an der Integration von Open vSwitch mit dem eigenen Switching-Betriebssystem. Dabei soll VMware vSphere als Netzwerk-Controller herangezogen werden können. Durch die Unterstützung erfolgt eine automatisierte Anpassung des Netzwerks mitsamt der Neukonfiguration der Arista-Switches beim Verschieben einer virtuellen Maschine. Hierzu setzt Arista deshalb auf einer definierten Schnittstelle zwischen den Switches und vSphere auf.
Erschwertes Monitoring
Dennoch sind das SDN-Konzept und OpenFlow nicht gänzlich unumstritten. Denn es können durchaus Lücken in der Transparenz des Netzwerks auftreten. Dies erschwert das Monitoring der Netzwerkaktivitäten. So sind beispielsweise Situationen denkbar, in denen die Netzwerktechniker nicht mehr nachvollziehen können, welche Anwendungen Probleme verursachen.
Foto: Riverbed
Um diese Lücken nicht entstehen zu lassen, müssen die Monitoring- und Management-Tools für Netzwerke angepasst werden. Dabei gilt es, nicht nur den Traffic selbst, sondern jegliche zusätzlichen Daten, die in dem Zusammenhang notwendig sind, "sichtbar" zu machen. Hierfür haben auch weitere Anbieter ihre Unterstützung zugesagt. Riverbed beispielsweise unterstützt mit seiner virtuellen Appliance Cascade 10.0 das VMware-Protokoll VXLAN. Die Appliance ist in der Lage, den UDP-Tunnel innerhalb eines Virtual Data Center zu durchleuchten und somit eine Paket-Inspection durchzuführen. Die so gewonnenen Informationen können dann dazu eingesetzt werden, die Netzwerkinfrastruktur in Bezug auf die Leistungsfähigkeit zu beurteilen. (hal)