Lösungsmodell für die VM-Migration mit RDMA

Kommentieren Drucken
Teil 18 von 19 aus der Serie "Virtualisierungstechniken"

Betrachtet man einen einfachen Dienst, wie z.B. das Messaging zwischen zwei Anwendungen oder (normalen) Prozessen, so führt der Austausch der zugrunde liegenden Kommunikationsbasis, also z.B. UDP/IP oder TCP/IP durch RDMA zu gradezu dramatischen Ergebnissen mit einem drei- oder sogar vierstelligen Faktor, also z.B. von Transferdauern im Milli-Sekunden-Bereich zu solchen im Mikro-Sekunden-Bereich.

Hinsichtlich der VM-Migration werden solche dramatischen Faktoren heute noch nicht erreicht, sondern die Verbesserung liegt im Bereich der Halbierung bis zur Zehntelung der Zeit. Das liegt sicherlich nicht an RDMA, aber, es gibt eben den Teil in der Virtualisierungssoftware, der die VM-Migration durchführt und steuert und letztlich den zugrunde liegenden Kommunikationsmechnismus nur nutzt.

Die genaue Konstruktion dieses Teils ist sozusagen Geschäftgeheimnis der Hersteller von Virtualisierungssoftware und sie werden nicht offenlegen, wie er ganz genau funktioniert.

Aus der Perspektive des Netzwerkers ist es aber interessant, zu erfahren, welche grundsätzlichen Mechanismen in einem solchen Verfahren stecken und wie sie arbeiten, um Rückschlüsse darauf ziehen zu können, inwiefern das überhaupt noch mit dem „Netz“ zu tun hat. Letztich ist es doch so, dass wir auch beurteilen können müssen, ob ein Mechanismus wie RDMA, den wir auf der Netzseite einführen, auch noch geeignet sein wird, wenn sich die Mechanismen in der Virtualisirungssoftware gegenüber dem heutigen Stand erheblich verbessert haben, worauf wir keinen Einfluss haben werden.

Der schlimmste Fall, der eintreten könnte, ist, dass wir heute mit einem gewissen Aufwand einen neuen Mechanismus auf der Netzseite einführen, der in zwei oder drei Jahren den dann in der Virtualisierungssoftware bestehenden Verbesserungen mehr im Weg steht als ihnen nützt.

In der Literatur gibt es glücklicherweise die Dissertation von Herrn Dr. Huang. Er hat ein Verfahren für die VM-Migration konstruiert und programmiert und dabei sämtliche Einzelheiten offen gelegt. Da sich die Aufgaben von Software für die VM-Migration in den verschiedenen Virtualisierungsumgebungen nicht wesentlich voneinander unterscheiden, ist es für das Gesamtverständnis sehr hilfreich, sich anzusehen, was Herr Dr. Huang eigentlich genau gemacht hat. Er arbeitet bei der Ohio-State Universität, die eng mit dem IBM T.J. Watson Research Center verbunden ist. IBM ist heute der wichtigste Distribtor von Linux-Lösungen und erheblich treibende Kraft bei funktionalen Verbesserungen. Von daher ist es sehr wahrscheinlich, dass sich die Ergebnisse von Herrn Dr. Huang in kommenden Linux-Versionen niederschlagen.

Wir beginnen mit der Behandlung der zu übertragenden Seiten. Seiten mit Page Tables müssen ja zunächst in das maschinen-unabhängige pfn-Format umgerechnet werden, was einige CPU-Zyklen benötigt. Beim Transfer können sowohl RDMA read als auch RDMA write-Operationen benutzt werden. Das Bild 2 zeigt vereinfacht die Kommunikation zwischen den Migrations-Hilfsprozessen bei einer Iteration des Pre-Copy-Zustands. Das Prinzip bei einer latenzarmen Lösung ist es, die normalen Speicherseiten so früh wie möglich zu verschicken und während ihres Transfers die Umrechnung der Seiten mit Page-Tables vorzunehmen. Und hier ist es praktisch, dass die wesentliche Arbeit für den RDMA-Transfer beim Initiator liegt. Grob gesagt wird nach einer Initialisierungsphase der Ziel-Host zum Initiator des RDMA-Datenverkehrs und liest aktiv die Seiten aus dem Quell-Host aus, auch wenn sich das unlogisch anhört, und der Quell-Host berechnet die Seiten mit Page Tables. Dadurch wird die Arbeit hochgradig parallelisiert. Es gibt dann auch noch Verfahren, die die durch RDMA read und RDMA write Operationen entstehenden Lasten dynamisch entlang der Beobachtung der Gesamtlast dynamisch verteilen, aber das führt an dieser Stelle wirklich zu weit.

Die Reservierung von Speicher ist ein weiteres Problem, weil weder die Vorausreservierung noch die Reservierung on-the-fly wirklich befriedigend funktionieren. Es hilft nichts, man muss die Behandlung der Reservierung nach der Art der Seiten differenzieren. Bei Seiten, die Page Tables enthalten, müssen die Migrations-Hilfsprozesse ein Parsing durchführen, um sie von maschinen-abhängigem Code in maschinen-unabhängigen Code übersetzen zu können. Daher entstehen keine zusätzlichen Kosten (CPU-Zeit) wenn man einen Kopie-basierten Ansatz verfolgt. Auf dem Quell-Host schreibt der Migrations-Hilfsprozess die Seiten direkt in die vor-alloziierten Speicherbereiche und sie können dann von diesen in die vor-alloziierten Speicherbereiche des Zielhosts geschrieben werden. Im Zielhost liest der Migrations-Hilfsprozess die Daten aus den vor-alloziierten Speicherbereichen, übersetzt sie und schreibt das Ergebnis in die Seiten mit Page Tables (für den Neustart der VM auf der Zielmaschine). Bei allen anderen Seiten entstehen zusätzliche Kosten, wenn man einen Kopie-basierten Ansatz verfolgt und der Migrations-Hilfsprozess kann die Seiten, die zur wandernden VM gehören, nicht unmittelbar registrieren. Glücklicherweise unterstützt Infiniband direkten Datentransfer unter Nutzung von Hardware-Adressen des Betriebssystem-Kerns. Das ermöglicht den direkten Transfer von Speicherseiten, die Hardware-DMA-Adressen haben. Diese Hardware-Adressen sind in unserem Fall bekannt, nämlich aus den maschinenorientierten Seiten-Tabellen. Das einzige Problem in Xen ist, dass die Migrations-Helfer-Prozesse anwendungsunterstützende Elementarprozesse sind und nicht direkt auf diese Funktion des Betriebssystem-Kerns zugreifen können. Das Problem kann man dadurch lösen, dass man für diesen speziellen Fall die Zugriffsmöglichkeiten der anwendungsunterstützenden Elementarprozesse, die die Funktion eines Migrations-Helfers haben, so erweitert, dass sie ausnahmsweise doch auf diese Funktion des Betriebssystem-Kerns zugreifen können. Dazu muss lediglich diese Schnittstelle durch einen Export den Helfer-Prozessen verfügbar gemacht werden. Das ist in diesem Fall kein Sicherheitsproblem, weil die Helfer-Prozesse in der Basis-Domäne (Dom0) ablaufen und man die dort ablaufenden Prozesse als sicher und zuverlässig einstuft.

Eine weitere wichtige Fragestellung betrifft die Organisation des virtualisierten Virtuellen Speichers für die VMs durch den Hypervisor einer Virtualisierungssoftware. Wir sehen uns einmal an, wie Xen das macht. Wie man in Bild 3 sieht, verwaltet Xen eine Tabelle zur Abbildung von maschinen-unabhängigen Adressen in maschinen-abhängige Adressen für jede VM.

Diese Abbildung ist beliebig und das physikalische Layout der Speicherseiten kann in weitem Bereich variieren. Insbesondere müssen die Speicherseiten einer VM keinen durchgängigen Bereich bilden, sondern können verteilt abgelegt werden. Während der Migration wird eine Quell-Speicher-Seite auf eine Ziel-Speicher-Seite abgebildet, die die gleiche maschinen-unabhängige Adresse hat, um Transparenz zu gewährleisten. In der Abbildung 3 wird z.B. die Quell-Seite mit der maschinen-abhängigen Adresse 1 auf die Ziel-Seite mit der maschinen-abhängigen Adresse 2 abgebildet, weil beide die maschinen-unabhängige Adresse 3 haben. Xen wählt die Reihenfolge der zu übertragenden Daten nach einem Zufallsverfahren aus, um die Dirty Rate damit statistisch gering zu halten. Das unzusammenhängende Speicherdesign in Verbindung mit einer zufälligen Auswahl der aktuell zu übertragenden Seiten macht es sehr unwahrscheinlich, dass Seiten, die zur Übertragung anstehen, zusammenhängen und bei einer Übertragung kombiniert werden können.

Eine einzelne Seite ist viel kleiner als das, was normalerweise in einem Infiniband- aber auch einem Ethernet-Paket übertragen werden kann. In beiden Systemen ist, auch unter der Voraussetzung einer Switching-Fabric, jede Sendung mit einem gewissen Organisationsaufwand verbunden, der unabhängig von der eigentlichen Paketlänge ist, sondern einfach pro Paket einen gewissen Overhead bildet. Belässt man es bei der Übertragung einzelner Seiten, entsteht ein sehr ungünstiges Verhältnis dieses Overheads zu der eigentlichen Nutzlast.

Deshalb ist es günstig, an dieser Stelle Page Clustering einzuführen, um möglichst viele Seiten mit einer Operation zu übertragen. Das gilt nicht nur für die RDMA-Operationen mit IB, sondern natürlich auch, wenn für die VM-Migration ein TCP/IP-Stack verwendet werden soll. Außerdem fördert Page Clustering eine grundsätzliche Zufälligkeit hinsichtlich der Rate der Dirty Pages.

Bild 3 (a) zeigt, wie das Page Clustering grundsätzlich funktioniert. Zuerst werden auf der Quellmaschine die Page Tables (mit den maschinen-abhängigen Adressen) gemäß der Ordnung dieser Adressen sortiert. In der neu organsierten Adresstabelle sieht man dann sofort, ob Speicherbereiche zusammenhängen. Um die Zufälligkeit beizubehalten, werden die Einträge der Tabelle dann in Mengen zusammenhängender Speicher-Seiten eingeteilt. Jede Menge steht für Speicher-Seiten, die zusammen in einer Operation übertragen werden können. Die Auswahl, welche Menge nun aktuell übertragen wird, geschieht wieder nach dem Zufallsprinzip. Wie viele Seiten dann jeweils mit einer RDMA-Operation (oder einem Ethernet-Paket) gleichzeitig übertragen werden können, hängt natürlich ganz davon ab, wie groß die zusammenhängenden Bereiche sind. Enthält die Menge nur einen Eintrag, bleibt nichts anderes übrig, als die betreffende Seite einzeln zu übertragen. Auf dem Zielhost müssen die Speicherbereiche dann nicht mehr zusammenhängen, weil RDMA auch „Read with scatter“ unterstützt.

Der Einfluss von QoS im Netz
Mit RDMA kann ein sehr geringer Software-Overhead bei der VM-Migration erzielt werden. Die Migration kann jedoch etwas umfangreich sein und dann im Netz die Leistung anderer kommunikations-intensiver Anwendungen negativ beeinflussen.

Xen benutzt einen dynamischen adaptiven Algorithmus, um die Übertragungsrate einer VM-Migration zu begrenzen. Man beginnt immer mit einem relativ geringen Limit für die Übertragungsrate für die erste Phase des Pre-Copy-Prozesses. Danach wird das Rate Limit mit einem konstanten Faktor erhöht, der der „Dirty Rate“ der vorangegangenen Interation entspricht. Damit vermeidet man statistisch den Effekt, dass die Menge der während der Migration geänderten Seiten größer ist als die Menge der Seiten, die übertragen werden können, was natürlich chaotische Folgen für die Migration hätte.

Das Verfahren ist ja nett gedacht, stammt aber noch aus einer Zeit vergleichsweise geringer Datenraten, die wir im RZ ob nun mit Ethernet oder IB längst hinter uns gelassen haben. Gibt es keinen weiteren Verkehr im Netz, ist die künstliche Beschränkung der Übertragungsrate natürlich völliger Unfug. Sinnvoll für die VM-Migration ist es immer, die pre-copy-Phase so schnell wir möglich hinter sich zu bringen.

Huang schlägt ein anderes Verfahren vor. Es basiert auf einer Messung der Antwortzeiten der RDMA-Operationen. Man weiß bei einer gegebenen Datenrate und bei vorliegenden Parametern für die Host CPUs ziemlich genau, wie lange eine Operation durchschnittlich dauert, wenn die Bandbreite voll oder mindestens zu 80% zur Verfügung steht. Dauert die Operation deutlich länger, ist davon auszugehen, dass es Contention auf dem Netz gibt. In diesem Fall muss die Datenrate für die VM-Migration heruntergeregelt werden.

In einem konvergierten Ethernet gibt es ja die Möglichkeit, miminale und maximale Bandbreitengrenzen mit DCB zu definieren und mittels der differenzierten Priorisierung durchzusetzen. In einer relativ statischen VM-Umgebung kann man das durchaus so machen und für die VM-Wanderung einen gewissen Bereich der Bandbreite reservieren.

In mehr dynamischen Systemen sollte man das tunlichst unterlassen. Man stelle sich z.B. vor, dass ein großer Server auszufallen droht und alle auf im befindlichen VMs möglichst schnell migriert werden müssen. Hätte man in einem solchen Fall die Bandbreite mit DCB eingeschränkt, würden sich alle VMs um diese schmale Bandbreite prügeln und die Wahrscheinlichkeit, dass nicht mehr alle schnell genug von dem sinkenden Server wegkommen, ist sehr hoch. In solchen Fällen kann man durchaus hinnehmen, dass eine VM-Völkerwanderung kurzzeitig so viel Bandbreite belegt, dass andere laufende Anwendungen dadurch deutlich behindert werden. Denn die VM-Wanderung mit RDMA oder RoCE bei CEE ist nicht eine Sache von Stunden, sondern weniger Sekunden. Ein ähnliches Szenario entsteht bei einem Cloud-Provider, dessen Geschäftsmodell es ist, dynamisch Kunden-VMs zu provisionieren. Auch hier kann es zu bestimmten Zeiten vorkommen, dass die Anzahl dieser VMs relativ groß wird und sie wollen sich ja alle auf die ihnen zugedachten Ziel-Systeme bewegen. Auch hier wäre eine Einschränkung der Bandbreite für die VM-Migration erheblich kontraproduktiv.

« Teil 17: VM-Migration am Beispiel XenTeil 19: Ergebnisse für die VM-Migration mit RDMA und Nutzung von RoCE »


zugeordnete Kategorien: Virtualisierung
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.

*

.