Low Latency Networks im Überblick, Teil 7 Die Realtime-Fähigkeit virtueller Umgebungen im Überblick

Autor / Redakteur: Dr. Franz-Joachim Kauffels / Dipl.-Ing. (FH) Andreas Donner

Wie steht es eigentlich um die Einbindung latenzarmer Netze in die I/O von VMs im Rahmen von Virtualisierungssoftware? Hier gibt es neue Techniken, die allerdings einen erheblichen Erklärungsbedarf nach sich ziehen. Wie kann man solche Umgebungen sicher und sinnvoll betreiben? Fabric as a Service (FaaS) ist hier ein Stichwort. Hersteller und Standardisierung überziehen uns mit einer Menge von Namen, Standards und Produkten. Doch: was steckt wirklich dahinter?

Firma zum Thema

Viel Know-how wie bspw. die I/O-Unterstützung von SR-IOV in Hardware ist nötig, um auch virtuelle Infrastrukturen Latenzarm zu machen
Viel Know-how wie bspw. die I/O-Unterstützung von SR-IOV in Hardware ist nötig, um auch virtuelle Infrastrukturen Latenzarm zu machen
( Archiv: Vogel Business Media )

Es wäre schade, das Thema des High-Speed-Networkings und alle damit zusammenhängenden Fragen rund um latenzarme Netze auf die Unterstützung allgemein bekannter Anwendungen wie Finanztransaktionen, Wettermodelle, umfangreiche Simulationen und weitere aus dem Umfeld des HPC zu beschränken. Denn das kann man auch sehr einfache und umfänglich im Internet nachlesen.

Aber es gibt einen viel nahe liegenderen Bereich, der auch wesentlich mehr Rechenzentren betrifft und die Verantwortlichen dort in Zukunft in weit höherem Maße beschäftigen wird als bisher: die Kommunikation virtueller Maschinen.

Bildergalerie

Blickt man auf die Entwicklungen der letzten Jahre zurück, muss man leider sagen, dass der Beitrag der Netzwerkwelt zur Kommunikation virtueller Maschinen irgendwo zwischen verzweifeltem Basteln und hochgradigem Unsinn anzusiedeln ist.

Letzteres ist bspw. die Verwendung von virtuellen Switches (zum Beispiel Cisco Nexus 1000 V). Denn ein virtueller Switch wird den Hypervisor immer so stark belasten, dass keine Performance zu erwarten ist. Die Hardware-Unterstützung der I/O von VMs durch SR-IOV geht dagegen absolut in die richtige Richtung, aber systemtechnisch fehlte lange Zeit das geeignete Bindeglied. So ist denn auch das Aufkommen von Bemühungen wie VEPA oder spezieller Treiberlösungen einzelner Hersteller zu erklären. Während letztere als proprietäre Lösung definitiv grundsätzlich zu verwerfen sind, ist VEPA wenigstens ein Standard, den man einsetzen kann, solange Alternativen fehlen.

SR-IOV mit DirectPath

Die erste wirkliche sinnvolle Kombination ist SR-IOV mit DirectPath, wie es ab VMware 4.1 angeboten wird.

Die Hersteller von Virtualisierungssoftware wie VMware oder Citrix warten jedoch eigentlich auf etwas anderes: schnelle Inter-Prozess Kommunikation. IPC ist in Betriebssystemen schon lange ein wesentliches grundlegendes Konzept, leider aber meist mangels Netzwerkunterstützung auf eine einzige Maschine festgelegt.

VMs sollen jedoch flexibel zugeordnet werden können und auch wandern dürfen.

Sieht man sich das Thema genauer an, wird die hohe strukturelle Äquivalenz zwischen einem HPC-Cluster (mit physischen Servern) und einer virtualisierten Umgebung (mit VMs) sofort klar (siehe Abbildung 1).

Die Hersteller von Virtualisierungssoftware haben sich um die I/O viel zu wenig gekümmert und auf ihrem nicht grade ruhmreichen Weg wirklich alle Fehler gemacht, die man machen konnte. Zunächst musste der Hypervisor als Schaltstelle herhalten und irgendwie hat man sich noch nicht ganz von der Idee eines logischen Switches auf dieser Ebene verabschiedet. Dabei gibt es schon ein Jahr lang SR-IOV, was von den Adapter- und Serverherstellern fleißig verbaut wird und die Leistung erheblich steigern kann – bis zu 10 Gbps I/O für ein einzelnes Blade und bis zu 30 Gbps I/O für einen individuellen Server sind so möglich.

Die Alternativen VEPA und VEB sehe ich sehr kritisch, das ist immer noch im alten Gedankengut verhaftet und kann zu einer Überstrukturierung und damit zu einer Leistung führen, die einer VM neben der Ein- und Ausgabe auch noch das Häkeln Brüsseler Spitze erlaubt.

Ein Hoffnungsschimmer ist das mit VMware VSphere 4.1 angekündigte „Direct Path“. Hier kann eine VM ziemlich direkt auf die Leistungen von SR-IOV zugreifen. Es wird aber bestimmt wieder Strukturierungsfanatiker geben, denen „Direct Path“ zu direkt ist. In der Tat stehen sich natürlich Überstrukturierung und Performance als unversöhnliche Gegner gegenüber.

Es gibt ohnehin eine Reihe Erweiterungen in VSphere 4.1 gegenüber der Vorgängerversion. Man kann z.B. mehr als das Dreifache an VMs definieren und betreiben. Die Limits für nebenläufige Tasks wurden auch verändert. Man hat jetzt endlich etwas von 10 GbE und besonders stark ist die Steigerung beim Speicherzugriff. Es gibt ein Whitepaper „VCenter Server Performance and Best Practices“, wo man genau sehen kann, wie die Leistung von 4.1 gegenüber 4.0 gestiegen ist. Besonders bei Verwaltungsfunktionen innerhalb eines Clusters ist das eindrucksvoll, wenn man dem Hersteller Glauben schenkt.

Citrix hat einen Treiber für Low Latency entwickelt. In einem Versuch mit latenzarmen Switches von Blade Network Technologies konnte eine Latenz von 26 µs erreicht werden. Leider konnte der Autor bei diesen Herstellern weder eine genauere Beschreibung des Tests noch eine Beschreibung der Funktionsweise des Treibers in Erfahrung bringen. Das hilft uns also nicht wirklich weiter.

Bei VMware kann man aber schon sehr konkret sehen, wie es für die zweite Anwendungskategorie weiter gehen soll. Für die Unterstützung der Entwicklung von Web 2.0-Anwendungen wurde vFabric angekündigt. Das ist eine Sammlung von Entwicklungswerkzeugen, die man für solche Umgebungen benötigt und Abbildungen (ich möchte hier nicht von Treibern sprechen) der durch diese Werkzeuge erzeugten Objekte auf VSphere 4.1-Umgebungen.

weiter mit: Die Funktionen von SR-IOV, DirectPath und VNLink

Die Funktionen von SR-IOV, DirectPath und VNLink

In Abbildung 3 sehen wir die Intel-Implementierung von SR-IOV, wie ich sie ja schon mehrfach ausführlich beschrieben habe. Der Nachteil wird aber auch sofort offenbar. Die aus einem Netz ankommenden Daten werden zwar wunderschön vorsortiert und in die Virtual Machine Device Queues VMDq abgelegt (vice versa für abgehende Daten), dann aber über einen, eigentlich unerwünschten Softswitch, an die VMs (im Bild Kästchen, in Wahrheit die vNIC-Systemprozesse der VM-Software) weitergereicht.

Direct Path ist nunmehr nichts anderes als die Möglichkeit der VMs, direkt auf die durch SR-IOV realisierten VMDqs zuzugreifen, ohne einen Softswitch zu benötigen!

Wie kann das funktionieren? Man erweitert dazu etwas, was man bereits hat, nämlich die Hardware-Speicherunterstützung.

Statt eines normalen Adapters wird in den Server ein SR-IOV-Adapter eingebaut, der die VMDqs enthält. In diesen Schlangen stehen die ankommenden bzw. die abgehenden Daten.

Jetzt kommt der Witz (siehe Abb. 4): die Ein- und Ausgänge der Schlangen werden in einem besonderen Bereich an die Hardware-unterstützten Speicherbereiche gebunden, das sind die magentafarbenen Kästchen in den Speicherbildern. Diese Bindung ist völlig unproblematisch, das ist für die Speicherbilder genau so, als würde eine Speicher-Kachel eingebunden.

Die HW-Unterstützung der Speicherbilder bedeutet, dass es die Shadow-Tabellen schon gibt. Also kann man jetzt die Shadow-Tabellen leicht um ein Bild des Magenta-Kästchens, welches die Enden der VMDqs repräsentiert, erweitern. Das ändert nichts an dem grundsätzlichen Mechanismus zwischen multiplen Speicherbildern und Shadow-Tabellen.

Damit sind wir eigentlich schon fertig, die MMUs müssen nur so erweitert werden, dass die vNIC-Systemprozesse jetzt auf die Magenta-Kästchen in den Shadow-Tabellen zugreifen. Das ist aber überhaupt kein Problem, weil das ja im Wirkungsbereich der Arbeitsweise des nachgemachten Dispatchers liegt.

Damit haben wir die direkte Kommunikation realisiert.

Geschildert wurde hier nur eine Möglichkeit, es gibt durchaus noch andere mit äquivalenter Wirkung, die aber an dieser Stelle nicht weiterführen.

Man sieht jetzt ganz genau, dass der Hypervisor mit der ganzen Sache genauso wenig zu tun hat wie mit dem HW-unterstützten Speicher. Also wird er maximal entlastet. Im Status eines ganz normalen Anwendungsprogramms kann er natürlich ungehindert weiterhin kommunizieren, z.B. mit anderen HVs.

Es ergeben sich folgende unmittelbare Konsequenzen:

  • SR-IOV und DirectPath gehören eng zusammen. Ohne DP kann SR-IOV sozusagen nur halb funktionieren. Ohne SR-IOV könnte DP nicht funktionieren, weil es ja keine VMDqs gäbe
  • Die Leistung dieser Kombination übertrifft die aller anderen denkbaren Varianten deutlich. Mit viel Glück schafft SR-IOV mit Softswitch 10 GbE, SR-IOV mit DP aber 30 GbE
  • Die Latenz dieser Kombination ist sehr gering, weil es keinen Softswitch gibt, der in seiner Reaktionsfähigkeit dadurch beeinträchtigt wird, dass er im Status eines Anwendungsprogrammes auf die Bindung an einen anwendungsunterstützenden Elementarprozess angewiesen ist. Aktuell liegen von VMware und Intel noch keine Messungen dazu vor, aber es gibt keinen Grund, warum die Latenz abgesehen von einem geringen Premium nicht im Bereich eines physischen Servers liegen sollte. Ich schätze das jetzt mal mit 2-5 µs ab.
  • SR-IOV und DP machen aus vShpere 4.1 ein realzeitfähiges System!

DirectPath und vMotion

Momentan harmoniert DP aber noch nicht mit vMotion. Müssen wir befürchten, entweder auf das beliebte vMotion oder auf das schnelle DP verzichten zu müssen? Nein, es ist nur noch nicht fertig programmiert verfügbar.

Die Wanderung einer VM basiert auf dem Austausch eines Vektors, der die Laufzeitumgebung der VM beschreibt. Dieser Vektor ist sozusagen die DNA der VM und man kann mit ihm die VM auf einer fremden Maschine reproduzieren. Dieser Vektor kann erweitert werden. So gab es ja z.B. Erweiterungen von vNICs auf vHBAs und bald kommen auch die vHCAs für CEE und IB.

Und jetzt muss man eben ein neues Feld definieren, in dem steht, dass der vNIC-Systemprozess nicht mehr auf das Register, was ihm der Softswitch gibt, zugreifen soll, sondern auf den speziellen Bereich in der Shadow-Tabelle. Das setzt natürlich voraus, dass die Zielmaschine für die Wanderung auch eine HW-Unterstützung für den Speicher hat, aber das ist schon länger normal.

Es gibt dabei eigentlich nur noch ein ungelöstes Problem: was passiert mit Daten, die während einer VM-Wanderung noch auf der Quellmaschine auflaufen? Rein theoretisch könnten diese Daten dann verloren sein. Es gibt hierfür aber eine Reihe von Lösungsmöglichkeiten:

  • Hinnahme des Datenverlustes als Kollateralschaden der Wanderung. Das wäre bei vielen Anwendungen durchaus vertretbar, aber nicht bei allen.
  • Ausgleich des Datenverlustes durch TCP. Die nach der Wanderung auf dem Zielsystem wieder aktive VM wird die Daten vermissen und sie bei TCP wieder anfordern. Nachteile: ein gewisses Delay und es funktioniert nicht für Anwendungen, die gar kein TCP benutzen.
  • Verhinderung des Datenflusses durch die Definition von vCPUs. Diese stellen dann abgeschlossene Laufzeitumgebungen für VMs bereit. Die Wanderung einer VM von einem physischen Server auf einen anderen bringt einen Informationsaustausch der vCPUs mit sich. Nachteil: Einfügung einer zusätzlichen, komplexen Systemebene. Das ist genau der Weg, den Intel beschreitet. Ziel ist eine Hardwareunterstützung der vCPUs. Das Konzept ermöglicht zudem die Wanderung von VMs zwischen Prozessoren, die unterschiedlichen Familien angehören.
  • Benutzung einer universellen Systemsynchronisation. Wanderungen können nur zu bestimmten Synchronisationspunkten stattfinden. An diese Synchronisationspunkte kann man zusätzliche Bedingungen knüpfen, wie z.B. den Abschluss von I/O-Operationen. IBM verwendet diesen Mechanismus bei iVM, der Weiterentwicklung von VM für den iDataPlex.

Welche dieser Alternativen VMware letztlich benutzen wird, oder ob sie noch eine weitere finden, wissen wir nicht. Lösbar ist das Problem in jedem Fall.

Was ist VNlink?

Letzte Frage: was ist VNlink? Zunächst ja einmal eine Möglichkeit von Cisco, VMs via VMware-Softswitch oder Nexus 1000V an Cisco-Adapter zu binden. Natürlich wissen die auch, dass das zu langsam ist. Also wurde VNlink so erweitert, dass es auch SR-IOV kann. Und damit kann es eben auch mit DP zusammen benutzt werden.

Damit macht Cisco noch nichts anderes als andere Hersteller, wie z.B. Intel. Eine besondere Qualität erreicht Cisco jedoch in Verbindung mit den Fabric Extendern. Diese sind ja letztlich Verlängerungen eines internen Switch-Busses und verlegen die Switch-Ports unter Weglassen einer normalen Adapterkarte direkt in den Server. D.h. technisch gesehen, dass nicht mehr die VMDqs von SR-IOV, sondern direkt die E/A-Warteschlangen eines Switchports an die Shadow-Tabellen gebunden werden.

Damit spart Cisco ca. 2-3 µs. So können sie die Zeit, die sie in ihrem komplizierten Switch-ASIC z.B. gegenüber Blade verlieren, wieder wettmachen. Ein UCS mit Fabric Extender an einem 5500 wird damit eine Latenz haben, die einem vergleichbaren IBM-System mit Blade-Adapter und Blade-Switch nicht wesentlich nachsteht. Es wird aber auch nicht wirklich schneller sein – denn man darf dabei nicht vergessen, dass sie an den durchgelegten Switchports die Logik von SR-IOV nachempfinden müssen, denn sonst fehlt ja die notwendige Vorverteilung auf die Ziel-VMs.

In der Diskussion erscheint VNLink nach außen nur als ein zusätzliches Tag, über das sich HP und IBM in der Standardisierung streiten.