Netzwerk-Virtualisierung und Storage Defined Networking

Bei einem softwaredefinierten Netzwerk (SDN, Software Defined Network) handelt es sich um eine Architektur, die ihrerseits aus vielen Technologien besteht. Egal, ob Fabric- oder Overlay-basiert, kann die Netzwerk-Virtualisierung als eine SDN-Anwendung angesehen werden. Der Hauptvorteil einer Netzwerk-Virtualisierungslösung besteht darin, dass virtuelle Maschinen unabhängig vom physischen Netzwerk bewegt werden können. SDN hat jedoch andere potenzielle Vorteile, einschließlich weniger administrative Last bei der Bereitstellung von Funktionen wie QoS und Sicherheit. Während einige der Merkmale eines SDN, wie etwa die größere Abhängigkeit von Software, bereits weiträumig auf dem Markt akzeptiert sind, bieten Anbieter erst seit Kurzem SDN-Lösungen an. Die Verbreitung von SDN beginnt gerade erst. Bei all den potenziellen Vorteilen, die SDN vermutlich bieten wird, müssen IT-Organisationen planen, wie sie ihre Netzwerke entwickeln, um SDN zu implementieren.

Das softwaredefinierte Networking (SDN) und die Netzwerk-Virtualisierung (NV) gehören zu den interessantesten Themen im IT-Umfeld. Bei IT-Abteilungen in Unternehmen gibt es jedoch dazu noch viele Missverständnisse. Dafür existiert eine Vielzahl von Gründen: Einer davon ist die Menge an Anbietern, die Lösungen für unterschiedliche Problemstellungen anbieten, die aus unterschiedlichen Lösungsarchitekturen und -technologien bestehen.

Jeder von ihnen behauptet, SDN und/oder NV-Lösungen anzubieten. In herkömmlichen Networking-Ansätzen wird der Großteil der Netzwerkfunktionen in einem dedizierten Gerät zusammengefasst, zum Beispiel einem Switch, Router oder Application Delivery Controller. Außerdem wird in diesem dedizierten Gerät der Großteil aller Funktionen in Form einer dedizierten Hardware wie beispielsweise einem ASIC (Application Specific Integrated Circuit) implementiert. Dieser Ansatz zur Entwicklung von Netzwerkgeräten weist folgende Hauptmerkmale auf:

• Die ASICs, die die Netzwerkfunktionen bereitstellen, entwickeln sich nur langsam.
• Die Entwicklung der ASIC-Funktionen erfolgt unter der Kontrolle des Geräteherstellers.
• Die Geräte sind proprietär.
• Jedes Gerät wird individuell konfiguriert.
• Aufgaben wie das Provisioning, das Change Management und das De-Provisioning sind sehr zeitaufwändig und fehleranfällig.

Organisationen stehen unter dem wachsenden Druck, effizienter und flexibler sein zu müssen, als es mit einer herkömmlichen Netzwerkarchitektur möglich ist. Eine Ursache für diesen Druck ist die großflächige Verbreitung der Server-Virtualisierung. Virtuelle Maschinen (VMs) werden innerhalb von Sekunden oder Minuten dynamisch von einem Server auf einen anderen verlegt. Wenn jedoch diese Verlagerung einer VM über eine Layer-3-Grenze hinweg stattfindet, kann es Tage oder Wochen dauern, um das Netzwerk so zu rekonfigurieren, dass die VM an ihrem neuen Standort optimal unterstützt wird. Es erweist sich unter Umständen als schwierig, exakt zu definieren, was man unter einem flexiblen Netzwerk versteht. Wenn nun also die Verlagerung einer VM eine Netzwerk-Neukonfigurierung von einigen Wochen nach sich zieht, ist das betroffene Netzwerk nicht flexibel.

Generell gilt: Ein herkömmliches Netzwerk entwickelt sich langsam; seine Funktionen sind je nachdem, was die ASIC- und Netzwerkgerät-Anbieter zur Verfügung stellen, eingeschränkt; es verursacht vergleichsweise hohe Betriebsausgaben und ist von relativ statischer Natur. SDN verspricht, ohne diese Beschränkungen auszukommen.

Ein herkömmliches Datennetzwerk ist von seiner Struktur her weitgehend hardwarezentriert. Jedoch führte die Umstellung auf virtualisierte Netzwerk-Appliances und das immer größer werdende Interesse am Software-Defined Datencenter (SDDCs) in den letzten Jahren dazu, dass man immer mehr auf softwarebasierte Netzwerkfunktionalität setzt. Mitte bis Ende der 2000er-Jahre beispielsweise bestanden Netzwerkgeräte wie WAN Optimization Controller (WOCs) und Application Delivery Controller (ADCs) aus zweckgebundener Hardware.

Das bedeutet, dass Funktionen wie Verschlüsselung/Entschlüsselung und die Verarbeitung von TCP-Streams von einer speziell für diesen Zweck entwickelten Hardware durchgeführt wurden. Hauptsächlich aufgrund der gestiegenen Anforderungen an die Flexibilität ist es mittlerweile üblich, die Funktionen eines WOC oder ADC von einer Software ausführen zu lassen, die sich auf einem Standard-Server oder einer VM befindet.

Ein SDDC könnte man als komplettes Gegenstück zu den herkömmlichen Rechenzentrumsnetzwerken bezeichnen. Eines der Hauptmerkmale eines softwaredefinierten Rechenzentrums ist beispielsweise, dass die komplette Rechenzentrumsinfrastruktur virtualisiert und als Service bereitgestellt wird. Ein weiteres Hauptmerkmal besteht darin, dass die automatisierte Kontrolle der Rechenzentrums-Anwendungen und -Services über ein richtlinienbasiertes Management‑System bereitgestellt wird.

Bei grundlegend neuen Technologieansätzen bestehen häufig Missverständnisse darüber, in welchen Bereichen diese neuen Ansätze Vorteile aufweisen. Um einen neuen Technologieansatz wie SDN erfolgreich zu bewerten und einzuführen, müssen IT-Organisationen die Vorteile ermitteln, die der Organisation wichtig sind und die mit diesem neuen Ansatz ermöglicht werden. Nach all den Diskussionen zum Thema SDN haben sich die folgenden Punkte als Vorteile herauskristallisiert:

• Unterstützung der dynamischen Bewegung, Replikation und Zuteilung virtueller Ressourcen;
• Vereinfachte administrative Aufgaben wie Konfiguration und Bereitstellung von Funktionen wie QoS und Sicherheitsfunktionen;
• Vereinfachte Bereitstellung und Skalierbarkeit von Netzwerkfunktionen;
• Traffic Engineering mit einer End-to-End-Sicht des Netzwerks;
• Effizientere Verwendung von Netzwerkressourcen;
• Verringerte Betriebsausgaben;
• Netzwerkfunktionen können, basierend auf einem Software-Entwicklungszyklus, schneller entwickelt werden;
• Anwendungen können bei Bedarf dynamisch Services vom Netzwerk anfordern;
• Effizientere Sicherheitsfunktionen sowie
• Verringerte Komplexität.

Die Open Networking Foundation (ONF) ist die Gruppe, die hauptsächlich mit der Entwicklung und Standardisierung von SDN in Verbindung gebracht wird. Laut ONF 1 ist softwaredefiniertes Networking (SDN) eine im Trend liegende Architektur, die sich als dynamisch, verwaltbar, kosteneffizient und anpassungsfähig erweist. Dadurch eignet sich SDN ideal für die dynamischen Anwendungen von heute, die eine hohe Bandbreite erfordern. Diese Architektur entkoppelt Netzwerkkontroll- und Weiterleitungsfunktionen und ermöglicht es, die Netzwerkkontrolle direkt programmierbar zu machen. Die darunterliegende Infrastruktur wird somit abstrahiert und für Anwendungen und Netzwerk-Services verfügbar gemacht. Laut ONF ist eine SDN-Architektur:

• direkt programmierbar: Die Netzwerkkontrolle ist direkt programmierbar, da sie von den Weiterleitungsfunktionen losgelöst ist.
• flexibel: Die Trennung von Kontroll- und Weiterleitungsfunktionen ermöglicht Administratoren, netzwerkweite Datenverkehrsströme anzupassen, um dadurch wechselnden Anforderungen gerecht zu werden.
• zentral verwaltet: Die Netzwerkintelligenz ist (logisch) in softwarebasierten SDN-Controllern zentralisiert, die eine globale Ansicht des Netzwerks aufrechterhalten. Diese wird von Anwendungen und Policy Engines als einzelner, logischer Switch angesehen.
• programmatisch konfiguriert: Ein SDN ermöglicht es Netzwerkmanagern, mithilfe von dynamischen, automatisierten SDN-Programmen Netzwerkressourcen schnell zu konfigurieren, zu managen, abzusichern und zu optimieren. Diese können sie selbst schreiben, da sie nicht von proprietärer Software abhängig sind.
• auf offenen Standards basierend und anbieterunabhängig: SDN vereinfacht – wenn über offene Standards implementiert – das Netzwerkdesign und den Netzwerkbetrieb, da Anweisungen von den SDN-Controllern stammen, anstatt von mehreren, anbieterspezifischen Geräten und Protokollen.

Ein Grund für die vielen Missverständnisse bezüglich SDN ist, dass viele Anbieter die von ONF aufgestellte Definition von SDN nicht vollständig akzeptieren. Während beispielsweise einige Anbieter OpenFlow als grundlegendes Element einer SDN-Lösungen sehen, warten andere lieber noch ab. Ein weiterer Grund für Missverständnisse ist die Uneinigkeit darüber, was die Infrastrukturebene ausmacht. Laut ONF ist die Infrastrukturebene eine umfassende Reihe an physischen und virtuellen Switches und Routern. Ein aktueller Ansatz zur Implementierung von Netzwerkvirtualisierung stützt sich auf eine Architektur, die der in Abbildung 1 ähnelt, aber ausschließlich virtuelle Switches und Router enthält.

Netzwerk-Virtualisierung

Bei der Netzwerk-Virtualisierung handelt es sich um kein neues Thema, da Organisationen schon seit langer Zeit Technologien wie virtuelle LANs (VLANs), Virtual Routing and Forwarding (VRF) und Virtual Private Networks (VPNs) implementiert haben. Jedoch bezieht sich der Begriff Netzwerk-Virtualisierung in diesem Beitrag auf die Funktionen, die in der rechten Hälfte von Abbildung 2 gezeigt werden. Insbesondere bezieht sich Netzwerk-Virtualisierung auf die Fähigkeit, End-to-End-Netzwerkverbindungen bereitzustellen, die von der darunterliegenden physischen Netzwerkinfrastruktur abstrahiert sind. Dies ähnelt der Art, wie virtualisierte Server, die von der darunterliegenden Infrastruktur von x86-basierten Servern abstrahiert sind, IT-Ressourcen verteilen.

Eine Möglichkeit, Netzwerk-Virtualisierung zu implementieren, besteht aus einer Anwendung, die auf einem SDN-Controller ausgeführt wird, das OpenFlow-Protokoll nutzt und virtuelle Netzwerke definiert. Letzteres geschieht basierend auf den Richtlinien, die mithilfe der L1–L4-Bestandteile des Headers den entsprechenden virtuellen Netzwerken Datenströme zuteilen. Dieser Ansatz wird oft als Fabric-basierte Netzwerk-Virtualisierung bezeichnet.

Eine andere Möglichkeit, Netzwerk-Virtualisierung zu implementieren, ist der Gebrauch von Datenkapselung und Tunneling, um mehrere virtuelle Netzwerk-Topologien zu erstellen, die über ein übliches physisches Netzwerk gelegt werden. Dieser Ansatz wird oft als Overlay-basierte Netzwerk-Virtualisierung bezeichnet. IT-Organisationen haben in den letzten Jahren basierend auf Protokollen wie VXLAN Netzwerk-Virtualisierung über Overlays implementiert. Die erste Welle dieser Lösungen verfügte jedoch nicht über einen Controller. Da diese Controller-losen Lösungen typischerweise Informationen mithilfe von Flooding an die Endsysteme verteilten, ließen sie sich schlecht skalieren.

Abbildung 3 zeigt einen moderneren Ansatz zur Implementierung der Netzwerk-Virtualisierung. In diesem Ansatz wird ein Controller verwendet. Zusätzlich ist eine Architektur vorhanden, die jener in Abbildung 1 ähnelt. Der Unterschied ist, dass die Netzwerkelemente entweder vSwitches oder vRouter sind. Eine der Hauptfunktionen des Controllers in Abbildung 3 ist es, einen Tunnel für die Steuerebene bereitzustellen. Diese Funktion ermöglicht es dem sich zuschaltenden Gerät, einen Mapping-Vorgang zu implementieren, der festlegt, wohin das gekapselte Datenpaket gesendet werden soll, um die geplante Ziel-VM zu erreichen.

Im Netzwerk-Virtualisierungsansatz, der in Abbildung 3 gezeigt wird, kann ein virtuelles Netzwerk ein Layer-2- oder Layer-3-Netzwerk sein, während das physische Netzwerk je nach Overlay-Technologie ein Layer-2-, Layer-3-Netzwerk oder eine Kombination aus beiden sein kann. Mit Overlays enthält der Header ein Feld, das üblicherweise 24 Bit lang ist. Diese 24 Bit können verwendet werden, um ca. 16 Millionen virtuelle Netzwerke zu identifizieren. Die praktischen Grenzen liegen jedoch oft im Bereich von 16.000 bis 32.000 virtuellen Netzwerken. Im in Abbildung 3 gezeigten Ansatz wird die Virtualisierung an der Netzwerkgrenze vorgenommen, während der Rest des physischen L2/L3-Netzwerks unverändert bleibt. Die Konfiguration muss nicht modifiziert werden, um die Netzwerk-Virtualisierung zu unterstützen. Der Hauptvorteil einer Overlay-basierten Netzwerk-Virtualisierungslösung besteht darin, dass virtuelle Maschinen unabhängig vom physischen Netzwerk bewegt werden können. Wenn eine VM ihren Standort ändert – sie kann sich nun sogar in einem neuen Subnetz befinden – müssen die Switches an der Grenze des Overlays einfach ihre Mapping-Tabellen aktualisieren, um den neuen Standort der VM wiederzugeben. (rhh)

Der Beitrag basiert auf Informationen von Citrix