Low Latency Networks im Überblick, Teil 7

Die Realtime-Fähigkeit virtueller Umgebungen im Überblick

Seite: 2/2

Firma zum Thema

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!

Bildergalerie

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.