SDN: Was macht eigentlich Niciria?

Kommentieren Drucken

Der Hersteller Niciria ist ja, wie sicher bekannt, von VMware übernommen worden. VMware seinerseits neigt dazu, selbst für lieferbare Produkte nicht wirklich genau zu sagen, wie sie aufgebaut sind und funktionieren. Das könnte man auch als „Informations-Virtualisierung“ bezeichnen. Wir können also nicht sagen, was aus den Ideen und Produkten von Niciria wirklich am Ende wird. Dennoch können wir einen Blick darauf werfen, was Niciria vor der Übernahme gemacht hat. Das ist ganz interessant und letztlich auch ein SDN-Controller-Design.

Die Niciria Network Virtualization Platform NVP kreiert eine intelligente Abstraktionsschicht zwischen den Host und dem existierenden Netzwerk. Man kennt aus der Providertechnik den Begriff des „Edge Networks“, welches den Übergang von dem Providernetz, z.B. einem optischen DWDM-Netz mit seinen inneren technischen Eigenschaften, zu „normalen“ Netzwerkumgebungen, wie IP-Netzen, schafft. Dazu verwendet man so genannte Edge Router und deren Leistungsfähigkeit ist sehr kritisch für den Erfolg des gesamten Konzeptes eines Providers für sein Netz.

Letztlich ist NVP eine Konstruktion aus kooperierenden Controllern, die gegenüber den virtualisierten Hosts eine vergleichbare Aufgabe haben. Alle Eigenheiten des physikalischen Netzes müssen den Host gegenüber völlig verborgen bleiben. Die NVP-Elemente sind sozusagen virtuelle Edge-Controller/Router.

Man kann diese Analogie noch weiter spinnen. Die Aufgabe eines Provider-Netzes ist die Unterstützung der Kommunikation der Kunden des Providers. Diese Kunden können Privatleute sein, die z.B. lediglich einen Internet-Anschluss wünschen, aber auch Unternehmen, die z.B. unter Verwendung eines VPN-Konzeptes ein „eigenes“ Unternehmensnetz auf der technischen Struktur des Providers aufbauen wollen. In jedem Fall beinhaltet die Konstruktion eines Edge-Netzes die absolut zuverlässige Unterstützung einer Mehr-Mandanten-Struktur.

Und das ist in einer virtualisierten Umgebung nicht anders. Die „Kunden“ sind die VMs, die eher so wie die Privatkunden zu sehen sind, und die Prozesse, die im Rahmen der Virtualisierungslösung die beliebten Zusatzfunktionen, wie Hochverfügbarkeit oder Lastverteilung auf der Grundlage der Migration von VMs herstellen. Keiner dieser „Kunden“ hat ein auch nur minimal ausgeprägtes Interesse an der Beschaffenheit des physikalischen Transportnetzes.

Es gibt in der Architektur von Niciria zwei wesentliche Komponenten: den Open vSwitch und das Controller Cluster.

Der Open vSwitch (OVS) ist eine für Fernsteuerung ausgelegte Switch-Software und arbeitet in den Server-Hypervisoren, um die gewünschte Abstraktion herzustellen. Der Open vSwitch ist sozusagen das Äquivalent eines Edge-Routers. Der OVS kann als komplette Software-Lösung in Xen, XenServer, KVM und ESX-Hypervisoren eingesetzt werden. Eine zweite Alternative ist die Realisierung des OVS als NVP-Gateway in Form einer physikalischen oder virtuellen Appliance. Ein solches NVP-Gateway ist dafür gedacht, bestehende Netze zu ergänzen und als Mittler zwischen ihnen und den Hosts zu fungieren oder den Anschluss an das Internet zu realisieren.

Das NVP Controller Cluster ist ein hoch verfügbares verteiltes System für die Verwaltung aller virtualisierten Netzwerk-Komponenten und Verbindungen. Das Controller Cluster stellt ein Web-Services API (RESTful) zur Verfügung und definiert virtuelle Netze. Es kann Tausende von OVS Edge Devices steuern und verwalten, sitzt dabei aber selbst nicht auf dem allgemeinen Data Path und ist dadurch natürlich auch von ihm unabhängig.

NVP kann unterbrechungsfrei zu allen existierenden Netzwerken hinzugefügt werden oder als Basis für die Steuerung von Neuentwicklungen in der Netzwerk-Hardware genutzt werden. Es gibt entsprechende Entwicklungsumgebungen. Nach Angaben von Niciria möchten Netzwerk-Komponenten-Hersteller relativ einfache, vollständige L3-Netzwerke herstellen, die dann mit NVP gesteuert werden können. Diese Aussage wird durch die Entwicklung des Intel FM 7000-Switch-ASICs gestützt, der ja ein komplettes L3-Netz vollständig in Hardware liefert.

NVP ermöglicht die Programm-basierte Kreation isolierter Virtueller Netze, von denen jedes seine eigenen Adressraum, Statistik-Zähler, QoS-Regeln, Sicherheitsfunktionen und weitere höher qualifizierte Netzwerkdienste haben kann. Diese Netze erlauben die Mobilität von Workloads über unterschiedliche Subnetze und Verfügbarkeitszonen, skalierbare Multimandantenfähigkeit und eine völlige Unabhängigkeit von ggf. notwendigen Umstrukturierungen und/oder Aufrüstungen des physikalischen Netzes. Die Implementierung sicherer Anwendungen in derartigen Umgebungen geschieht in Minuten statt in Wochen, die Konfiguration wird weitest gehend automatisiert.

Die auf diese Weise vollzogene Abkopplung der virtuellen Netze von den physikalischen Infrastrukturen reduziert die Komplexität des physikalischen Netzes dramatisch. Wie die Menge der virtualisierten Server wird das physikalische Netz letztlich zu einem gesharten Pool von Netzwerk-Kapazität, die dynamisch angefordert, benutzt und wieder einem anderen Zweck zugeführt werden kann. NVP ist einfach zu installieren und zu vrwalten, die Netzwerk-IP-Hardware kann eigentlich von jedem beliebigen Hardware-Hersteller kommen.

Wie baut Niciria das nun konkret konstruktiv auf? Die Antwort gibt ein Blick auf DVNI, die Distributed Virtual Network Infrastructure, siehe Bild 2.

In DVNI wird die Trennung der virtualisierten Instanzen auf den Hosts von den Eigenheiten des zugrunde liegenden physikalischen Netzwerks durch ein System kontrolliert arbeitender Tunnel implementiert. In der Abbildung finden wir folgende Bereiche:

  1. Das Virtuelle Netz. Das ist die Abstraktion, die von DVNI vorgenommen wird. Das Virtuelle Netz ist die Stelle, an die sich VMs wenden, wenn sie Kommunikation haben möchten und die von Administratoren und Cloud Managern dazu benutzt wird, die Kommunikation aufzusetzen und zu verwalten. Das Virtuelle Netzwerk ist von der zugrunde liegenden physikalischen Lösung, deren Technologie und Topologie vollständig abgekoppelt. Das bedeutet auch, dass die Netzwerk-Services, die vom Virtuellen Netz geliefert werden, nicht unmittelbar durch die Hardware unterstützt werden müssen und somit technologische Änderungen, Verbesserungen oder Aufrüstungen in der Physik keinerlei auf dieser Ebene unmittelbar zu verspürende Auswirkungen auf die vom Virtuellen Netz gelieferten Leistungen und Schnittstellen hat. Aus der Sicht eines Administrators oder eines Orchestrierungs-Systems sind Virtuelle Netz wie VMs: sie können erzeugt und terminiert werden, dynamisch wachsen oder schrumpfen, und innerhalb eines RZs oder sogar zwischen RZs hin- und her bewegt werden, ohne dass die virtuelle Perspektive unterbrochen oder geändert wird. Das Virtuelle Netz wird an den Netzkanten verteilt implementiert und die Funktionen der Instanzen an den jeweiligen Stellen beziehen sich lediglich auf die VMs und Funktionen in ihrem Sichtbereich.
  2. Das Maschen-Netz der Tunnel. Der gesamte virtuelle Verkehr wird mittels Tunneln über das physikalische L2- oder L3-Netz transportiert. Diese Einkapselung verbirgt den internen Verkehr vor den physikalischen Komponenten des Netzes und befreit die Netzwerk-Einrichtungen von der Notwendigkeit, mit vielfältigen Adressierungen oder weiteren komplexen Eigenheiten des Verkehrs zwischen VMs behelligt zu werden. Bei virtuellen Workloads werden die Tunnel grundsätzlich in den vSwitches terminiert, bei physikalischen Workloads in den ToR-Switches oder Gateways. Für die Architektur ist das eigentliche Tunnelprotokoll zweitrangig, es gibt ja da eine große Auswahl wie GRE, NVGRE, VXLAN oder CAPWAP. Die Topologie der Tunnel ist nicht in der Architektur fixiert. In der Frage, wie die Tunnel angeordnet werden, ist die Skalierung oft ein wichtiger Parameter. vSwitches können ohne Weiteres mit hinreichender Performance Zehntausende Tunnel unterstützen, ohne ihre Enden durcheinander zu bringen. Macht man das aber über ausgedehnte Multi-Hop-Netzwerke, kann es technisch sehr problematisch werden. Neben den virtuellen L2-Frames tragen die Pakete auf den Tunneln noch verschiedene Informationen hinsichtlich des virtuellen Netzes. Das umfasst allgemeine Informationen über das Virtuelle Netz, den Status des Virtuellen Netzes und Rekonfigurationsinformationen für das Virtuelle Netz. Nach Angaben von Niciria können Tunnel-Implementierungen in den vSwitches mit einer Line Rate von bis zu 10 GbE betrieben werden und belasten einen Core mit höchstens ca. 40%. Das hört sich erst einmal ganz nett an, ist aber eine Menge Holz.
  3. Netzwerk-Services. DVNI drückt die Look-Ups an die Kanten des Netzes, wo die Bearbeitung aber tatschlich erfolgt, ist nicht festgelegt. Z.B. kann der Firts Hop vSwitch die Look-Ups für L2, L3 und die ACLs vornehmen, oder aber der Vorgang wird auf den ersten und den letzten vSwitch in der Kette verteilt. In anderen Fällen kann es sinnvoll sein, einen Hypervisor mit diesen Aufgaben nicht zu belasten, sondern das auf andere Appliances zu verlegen, die an die Tunnel geheftet werden. Es gibt da viele Möglichkeiten, man könnte die Appliances auch generisch erzeugen und dynamisch einsetzen.
  4. Gateways. Das Gateway ist die „Rampe“ in die virtuelle Welt. Es ist der Punkt, an dem ein Paket, was zunächst in der virtuellen Umgebung bearbeitet wurde, auf einen physikalischen Draht gesetzt wird. Das Gateway befindet sich außerhalb der Kontrolle der DVNI-Architektur. Gateways können Pakete entweder direkt auf eine Verbindung setzen oder ihrerseits wiederum eine andere VPN-Enkapsulierung oder komplexere Technologien wie VLANs oder MPLS benutzen. Eine gute DVNI-Implementierung unterstützt Load-Balancing und Funktionsverlagerung über multiple Gateways, falls eines von ihnen ausfällt.
  5. Physical Fabric. Die einzige Anforderung, die DVNI an eine physikalische Switching Fabric hat, ist, dass diese IP unterstützt. Das ist kompatibel zu praktisch jedem existierenden Design für RZ-Netze. Damit VMs aber so wie gewünscht platziert werden können und es nicht zu Performance-Engpässen kommt, sollte das Netz, wenn überhaupt, nur leicht oversubscribed sein. Weiterhin sollte jedes Element im Netz in der Lage sein, QoS-Anforderungen, die durch Standard-Marker angezeigt werden, angemessen zu unterstützen und durchzusetzen.

Controller Cluster. Die Controller verwalten den Zustand an den Netz-Kanten stellen ein API für Provisionierung, Konfigurierung und Überwachung der virtuellen Netze. Eine gute DVNI-Architektur wird diese Controller verteilt implementieren.

Und um meine Analogie von Beginn dieses Artikels fortzusetzen, könne ich frech sagen, dass sie diese Vorgehensweise von den Provider-Netzen „geklaut“ haben, und zwar konkret von Carrier Ethernet. Bei Carrier Ethernet werden abstrakte Grunddienste für die Mandanten bereitgestellt, die natürlich im Rahmen eines Multi-Mandanten-Konzepts logisch völlig voneinander isoliert sind, obwohl sie auf dem gleichen Carrier-Netz laufen. Diese Services sind bei Carrier Ethernet E-Line, E-LAN und E-Tree und in der Implementierung allesamt Tunnel. An den entsprechenden Carrier Ethernet Edge Routern werden sie auf das physikalische Carrier Netz umgesetzt. Dieses Netz kann im Extremfall sogar ein SONET sein.

Und genau an dieser Analogie kann man die fundamentalen Problembereiche einer solchen Architektur identifizieren: es sind die Edge-Router, oder wie sie in DVNI heißen, die Netzwerk-Services. Genau die Übergangsfunktionen fressen Performance. Man kann sich natürlich auf den Standpunkt stellen, dass bei geeigneter Implementierung der Funktionen durch eine Ansammlung von VMs auf genügend vielen Prozessoren keine Leistungsengpässe auftreten werden, aber umsonst ist das Ganze mit Sicherheit nicht.

Die multiplen, verteilten Controller sind sicherlich eine sehr gute Idee, nimmt man aber alles zusammen stellt sich die Frage, ob das Konzept nicht für viele Anwendungsbereiche einfach maßlos übertrieben ist.

Nun, wir können das hier nicht abschließend klären sondern werden abwarten müssen, was VMware aus den Ideen von Niciria am Ende macht.

zugeordnete Kategorien: LAN
zugeordnete Tags:

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.