Software-Defined Networks
Netzwerke flexibel ändern
Die klassischen Netzwerkgeräte wie Router und Switches enthalten jeweils ihr eigenes Betriebssystem und L2/L3-Tabellen. Falls sich die Wege durch das Netzwerk ändern, müssen die Geräte individuell neu- oder umkonfiguriert und Routen neu berechnet werden. Bislang stellte dies kein großes Problem dar, da sich die Wege nur selten änderten und häufig nur einzelne Anpassungen an wenigen Routern oder Switches nötig waren. Server- und Storage-Virtualisierung sowie die Einführung flexibler Private-Cloud-Services haben jedoch die Situation in den meisten Unternehmen deutlich verändert.Damit Netzwerkinfrastrukturen die erforderliche Flexibilität durch Automatisierung erhalten können, übernehmen Hersteller derzeit das Virtualisierungsprinzip vom Storage-, Server- und Desktop- in den Netzwerkbereich. Dies bedeutet, dass Hardware und Software voneinander getrennt werden, im Falle des Netzwerks die Kontroll- von der Datenebene. Die Weiterleitung der Daten erfolgt nach wie vor durch in der Hardware gespeicherte L2/L3-Tabellen. Doch das Management der Übertragungswege und Routing-Tabellen erfolgt nicht mehr direkt auf dem Switch, sondern zentral aus der Ferne über eine spezielle Konsole. Das wiederum bedeutet, dass der IT-Administrator für eine Änderung der Übertragungswege nicht mehr jeden Switch einzeln umprogrammieren muss, sondern dies für mehrere Geräte, im Idealfall sogar für sämtliche Netzwerkkomponenten, in einem Schritt erledigen kann. Dies spart Zeit und Aufwand, die Ressourcen und Systeme lassen sich deutlich schneller und flexibler an aktuelle Anforderungen anpassen. Doch die Netzwerkvirtualisierung hat weitere Vorteile. Denn auch die Suche und Analyse möglicher Fehler geht damit deutlich schneller vonstatten. Bislang muss der Administrator bei Problemen an einem bestimmten Switch sämtliche Geräte analysieren, um die Fehlerquelle zu finden. Dies funktioniert nun automatisch, fehlerhafte Switches werden schnell abgeschaltet sowie bei der Weiterleitung der Daten umgangen. Zudem laufen durch das zentrale Management und die programmierbaren Interfaces auch Performance- und Sicherheitsanalysen deutlich schneller ab. Neue Richtlinien lassen sich wesentlich einfacher einführen und bestehende Policies ändern. Durch die verbesserte Nutzung der Netzwerkintelligenz verläuft die Orchestrierung von Richtlinien und Analysen ebenfalls effizienter und zuverlässiger. Jedoch erhalten Unternehmen die zahlreichen Vorteile durch Netzwerkvirtualisierung nicht ganz ohne Haken. Zur Programmierung der Netzwerkkomponenten ist nämlich eine umfangreiche Erfahrung in der Softwareentwicklung nötig. Denn bislang funktioniert diese noch weitgehend über Kommandozeilen. Allerdings stehen bereits Software Development Kits (SDKs) und offene Schnittstellen (APIs) bereit, die bei einer größeren Nutzungsrate auch zu Entwicklungs-Tools mit grafischen Nutzeroberflächen führen dürften. Diese wiederum werden die Akzeptanz der neuen Technik deutlich fördern, sodass sich ihre vielfältigen Funktionen einfacher nutzen lassen. Doch bis dahin setzen nur große Unternehmen mit entsprechenden Ressourcen wie Public-Cloud-Provider oder technisch sehr versierte Organisationen wie Universitäten programmierbare Komponenten ein. Trennung von Kontroll- und Datenebene Zur Trennung von Kontroll- und Datenebene nutzen die meisten Unternehmen und Universitäten den Ansatz Software-Defined Networks (SDN). Diese Technik extrahiert die Kontrollebene sozusagen aus dem Router und überträgt sie in ein eigenes System, den SDN Controller. Dieser kann ein physischer Server sein, eine virtuelle Maschine oder eine Hardware-Appliance. Der Controller definiert, an welchen Port und mit welcher Priorität die Daten weiterzuleiten sind, und übergibt diese Informationen an die ASICs in den Switches und Routern. Für die Kommunikation zwischen Controller und Infrastruktur sorgt zum Beispiel der offene Standard Openflow, an dem auch Unternehmen wie Cisco aktiv mitarbeiten. Er wurde an der Stanford University in Kalifornien entwickelt, die Open Networking Foundation (ONF) überwacht ihn inzwischen. Es bestehen zwar auch alternative Ansätze, etwa Path Computation Elements (PCE), vor allem für SDN in Weitverkehrsnetzen entwickelt; doch die meisten Unternehmen setzen derzeit auf das flexiblere und auch in LANs gut nutzbare Openflow. Openflow kann ein Teil einer SDN-Architektur sein, aber SDN setzt dieses Protokoll nicht voraus. Es wird auf beiden Seiten der Schnittstelle zwischen Netzwerk-Infrastrukturgerät und SDN-Control-Software implementiert. Openflow nutzt das Datenflusskonzept, um Netzwerkverkehr basierend auf definierten Match-Regeln zu identifizieren. Diese kann die IT statisch oder dynamisch durch die SDN-Control-Software programmieren. Das ermöglicht der IT auch die Definition, wie der Verkehr durch die Netzwerkgeräte fließen soll, basierend auf Parametern wie Nutzungsmuster, Applikationen und Cloud-Ressourcen. Da Openflow es erlaubt, das Netzwerk auf einer Pro-Fluss-Basis zu programmieren, bietet eine darauf basierende SDN-Architektur eine extrem detaillierte Kontrolle. Dadurch kann das Netzwerk auf Anwendungs-, Benutzer- oder Session-Ebene in Echtzeit auf Änderungen reagieren. Derzeitiges IP-basiertes Routing bietet diese Kontrollmöglichkeiten nicht, da alle Datenflüsse zwischen zwei Endpunkten die gleichen Pfadregeln durch das Netzwerk befolgen müssen. Openflow kann dabei auf der gleichen Infrastruktur parallel mit herkömmlichen Protokollen laufen. Alternativen zu Openflow Im Zusammenhang mit SDN wird immer wieder der Begriff Openstack diskutiert. Dieser Satz von Standard-Programmierschnittstellen wurde für Server-, Netzwerk- und Storage-Infrastruktur für orchestrierte Cloud- und RZ-Infrastrukturen entwickelt, vor allem für die automatische Bereitstellung einer Cloud-Umgebung. Dazu enthält er Funktionen für netzwerkbezogene Bereitstellungsaufgaben wie VLAN und Adressierung. Bei Openflow und Openstack handelt es sich aber um völlig unterschiedliche Techniken. Während OpensStack eine Orchestrierungsebene für die Bereitstellung und Konfiguration einer Cloud-Infrastruktur ist, sorgt Openflow für die Konfiguration der Weiterleitung von Datenpaketen auf Netzwerkgeräten. Openstack kann zwar auf Basis von Openflow laufen, aber auch mit klassischen Netzwerkprotokollen. Overlay Networks kommen ebenfalls für die Automatisierung des Datentransfers in Frage. Die Knoten im Overlay Network werden über virtuelle oder logische Links verbunden, die jeweils einem Pfad im darunterliegenden Netzwerk entsprechen. So lassen sich zum Beispiel Cloud-Lösungen als Overlay Network des darunterliegenden Internets realisieren. Diese Lösung zur Automatisierung bewältigt aber nur einen Teil der Herausforderungen, da Kontroll- und Datenebene immer noch auf dem Switch bleiben. Zudem erhöht sich die Komplexität des Netzwerks und des Managements durch teils mehrere zu erzeugende Netzwerkebenen. Der Vorteil ist jedoch, dass man bestehende Netzwerke weiter nutzen kann. Vor allem große Cloud-Provider profitieren von programmierbaren Netzwerk-Overlays und Openstack, da sie hochskalierbare Mandantenfähigkeit für die automatisierte Provisionierung erhalten. Service-Provider können damit per richtlinienbasierter Kontrolle und Analyse auf flexiblere Weise höherwertige kostenpflichtige Dienste anbieten. Unternehmen automatisieren verstärkt ihre Private Clouds mit verbesserten Orchestrierungs-Tools, wodurch sie virtuelle Workloads flexibler unter Einhaltung zum Beispiel von Sicherheitsrichtlinien betreiben können. Für Overlay-Netzwerke bestehen jedoch einige Voraussetzungen. So benötigt auch ein logisches Netzwerk immer noch Server-Knoten, die hier aber meist auf virtuellen Maschinen basieren. Zur logischen Isolierung des Netzwerkverkehrs und Partitionierung dienen VLAN- oder VXLAN-Zuordnungen (Virtual Extensible LAN). VXLAN erhöht die Skalierbarkeit der Infrastruktur und bietet eine Möglichkeit zur Erstellung isolierter, mandantenfähiger Broadcast-Domänen über Rechenzentrum-Fabrics hinweg. Dazu erstellt es logische Layer-2-Netzwerke, die in Layer-3-Standard-IP-Paketen gekapselt werden. Die logischen VXLAN-Netzwerke unterscheiden sich anhand einer Segment-ID in jedem Frame voneinander, sodass keine VLAN-Tags erforderlich sind. Dies ermöglicht die Koexistenz einer sehr großen Anzahl isolierter Layer-2-VXLAN-Netzwerke in einer gemeinsamen Layer-3-Infrastruktur. Overlay Transport Virtualization (OTV) vereinfacht die Erweiterung von Layer 2-Applikationen über verteilte Rechenzentren. Damit lässt sich ein Data Center Interconnect (DCI) zwischen Sites installieren, ohne dass man das bestehende Netzwerkdesign ändern oder rekonfigurieren müsste. Um die Routing-Systeme noch effizienter zu machen, trennt LISP (Locator/ID Separation Protocol) Routing Locator und Endpoint Identifier. Und Virtual Private LAN Services (VPLS) schließlich unterstützen die Verbindung mehrerer Sites in einer einzigen überbrückten Domain über ein verwaltetes IP/MPLS-Netzwerk. Damit auch WAN-Services wie LAN-Dienste erscheinen, nutzt die Technik Edge-Router auf VPN-Basis, die über Tunnels miteinander verbunden sind. Überblick statt Chaos Bei diesen verschiedenen Protokollen und Lösungsmöglichkeiten geht schnell der Überblick verloren und die Komplexität erreicht ungeahnte Höhen. Daher ist neben diesen Einzellösungen ein umfassender, pragmatischer Management-Ansatz für das Netzwerk nötig. Dieser muss sowohl übergeordnete Ebenen wie Netzwerkdienste und Orchestrierungen als auch untergeordnete Layer wie das Transportprotokoll umfassen. Dabei hat eine flexible Architektur möglichst offen für verschiedene Szenarien zu sein, etwa das Hosten von Workloads auf physischen Infrastrukturen, einem Hypervisor oder in einem Cloud-Service. Für Unternehmen spielt nämlich die zugrunde liegende Technik nur eine untergeordnete Rolle. Sie möchten eine Lösung, die auf bestmögliche Weise ihre individuellen sowie sich ständig ändernden Anforderungen und Geschäftsprozesse unterstützt. Nach einer Vereinfachung des Managements durch die Trennung von Kontroll- und Datenebene steht daher als zweiter Schritt die Erhöhung der Portabilität ihrer Infrastruktur im Fokus. Zudem benötigt jedes Unternehmen schon heute individuelle Infrastrukturlösungen. Daher sollte man zusätzlich eine Programmierebene einführen, um die Protokolle, Routing-Anweisungen, Richtlinien oder Analysen zu verändern. Zudem hat die Infrastruktur so offen zu sein, dass ein größerer Umbau der Technik oder die Migration auf neue Systeme möglichst problemlos ist. Dazu wurde das Konzept Open Network Environment (ONE) entwickelt. Es umfasst Programmierschnittstellen (APIs), Controller und Agenten sowie Overlays. Im Gegensatz zu SDN auf Openflow-Basis lassen sich damit unterschiedliche Protokolle verwenden. Dies funktioniert auf allen Ebenen wie Netzwerk-Services, Sicherheit, Load Balancing oder Analysen, um das Verhalten des Netzwerks flexibel anzupassen. Auch ein zugehöriges Platform Kit ist erhätltlich. Zur Einführung des Konzepts sind nicht unbedingt neue Netzwerkkomponenten nötig. Denn bereits heute stehen Switches und Router zur Verfügung, die ein programmierbares Interface besitzen und sich entsprechend nutzen lassen. Diese können Openflow oder andere Standards verarbeiten, parallel dazu die traditionelle Kontrollebene verwenden oder nach einem neuen Boot-Vorgang zwischen nativem Betriebssystem und dem offenen Protokoll hin- und herwechseln. Durch diese Flexibilität ist auch eine schrittweise Migration von der bisherigen Infrastruktur auf das programmierbare Netzwerk möglich. Dies ist für viele Unternehmen aufgrund des Investitionsschutzes eine wichtige Voraussetzung. So können sie ihre bestehenden Komponenten weiterhin nutzen und je nach gewünschten Funktionen die eingesetzten Router und Switches umprogrammieren oder neue einführen. Entscheidend ist dabei nicht die Technik, sondern welche Eigenschaften das Netzwerk erhalten soll und welche Vorteile das Unternehmen daraus zieht. Neben der flexiblen Programmierung des Netzwerks erhalten Unternehmen auch mehr Informationen und umfassendere Analysen zum Netzwerkverkehr. Daraus lassen sich intelligentere Richtlinien und Business-Logiken entwickeln, um das Netzwerk weiter zu verbessern. Fazit: Flexibilität auch auf höheren Ebenen nötig Unternehmen benötigen heute eine Infrastruktur, die sich möglichst flexibel und schnell ändern lässt. Dies liegt nicht nur an immer mehr Aufgaben, die das Netz erledigen muss, sondern auch an neuen Prozessen und Trends wie Bring Your Own Device oder Big Data. Den klassischen Netzwerkansätzen fehlt für diese neuen Anforderungen die Flexibilität, da sie festgelegte, starre Verkehrsbeziehungen nutzen. Um die Flexibilität der Infrastruktur zu erhöhen und das Management zu vereinfachen, sind Kontroll- und Datenebene zu trennen. Für ein vollständig virtualisiertes Netzwerk sollte der gewählte Ansatz übergeordnete Ebenen wie Netzwerkdienste und Orchestrierungen sowie untergeordnete Layer wie das Transportprotokoll umfassen.
Lesen Sie mehr zum Thema
