Low Latency Networks im Überblick, Teil 7

Die Realtime-Fähigkeit virtueller Umgebungen im Überblick

23.12.2010 | Autor / Redakteur: Dr. Franz-Joachim Kauffels / Andreas Donner

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

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?

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.

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

 

ComConsult Netzwerk-Redesign Forum 2011

Inhalt des Artikels:

Kommentare werden geladen....

Kommentar zu diesem Artikel

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 2049007 / Low Latency Networking)