VM-Migration am Beispiel Xen

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

Xen ist eine populäre Virtualisierungstechnologie, die ursprünglich an der Universität Cambridge entwickelt wurde. Wir wählen Xen hier zur Erklärung, weil die Klarheit des Konzeptes etwas deutlicher ist als bei anderen Virtualisierungsprodukten, auf die wir später noch kommen werden. Wir können dann zeigen, welche Anforderungen sich an ein Netzwerk-System ergeben, welches die VM-Migration unterstützen soll.

Bild 1 zeigt die Struktur einer physikalischen Maschine, auf der Xen läuft.

Der Xen Hypervisor (der Virtual Machine Monitor VMM) befindet sich auf der untersten Stufe und hat direkten Zugriff zur Hardware. Über dem Xen Hypervisor befinden sich die Xen-Domänen (die VMs), in denen die Gast-Betriebssysteme ablaufen. Jedes Gast-Betriebssystem kann einen vordefinierten Bereich des physikalischen Speichers benutzen. Eine privilegierte Domäne mit dem Namen domain0 oder dom0 wird beim Booten erzeugt und kann auf die Kontroll-Schnittstelle des Hypervisors zugreifen. So kann sie die Funktionen ausüben, die dazu nötig sind, andere Gast-VMs (User Domain oder DomU) zu erzeugen, zu terminieren oder zu bewegen.

An dieser Stelle können wir auch die Erklärung nachschieben, warum das Konzept zunächst am Beispiel Xen erläutert wird. Im Xen beherbergt jede Domäne (VM) nur ein einziges Gast-Betriebssystem. Das erspart uns die Differenzierung bei der Wanderung einer VM, einer Domäne und einer Betriebssystem-Instanz. Außerdem ist der VMM eine singuläre Komponente, in der alle notwendigen Funktionen vereinigt sind. Das ist nicht immer so. Bei VMware gibt es zum einen den Hypervisor für die Realisierung der Laufzeitumgebungen, die letztlich die VMs bilden und einen virtuellen Switch für die Kommunikation, unter die auch die Wanderung fällt. Das kompliziert die Verhältnisse erheblich, wie wir später noch sehen werden.

Wenn bei Xen ein Gast-Betriebssystem (eine VM) migriert werden soll, nimmt Xen zunächst einen pre-copy-Zustand ein, in dem alle Speicherseiten des zu migrierenden Gast-Betriebssystems an vor-alloziierte Speicherbereiche der Zielmaschine übertragen werden. Das wird durch einen „Domain-Migration-Helper“-Prozesse in den Dom0s beider Maschinen (Quelle und Ziel) erledigt. Alle Speicher-Seiten der migrierenden Betriebssystem-Instanz (VM) werden auf den Adressraum der Helper-Prozesse abgebildet. Danach werden diese Seiten im Sinne eines File-Transfers via des TCP/IP-Sockets an das Zielsystem geschickt. Bei Speicherseiten, die Page Tables enthalten, muss man besonders aufpassen und alle maschinenabhängigen Adressen (machine frame numbers oder mfn) in maschinen-unabhängige Adressen (physical frame numbers pfn) umsetzen, bevor man die Seiten überträgt. Die Adressen werden dann im Zielhost wieder auf zu diesem passende mfns umgerechnet. Das sichert Transparenz, denn die Gast-Betriebssysteme (VMs) benutzen pfns, um auf einen Speicher zuzugreifen.

Sobald alle Speicher-Seiten transferiert sind, kann die VM auf dem Quell-System terminiert werden und ihre Arbeit auf dem Zielsystem wieder aufnehmen.

Xen ermöglicht auch die sog. Live Migration, bei der der pre-copy-Zustand in mehreren Iterationen durchlaufen wird. Die erste Iteration sendet alle Speicher-Seiten wie zuvor beschrieben. Bei der „normalen“ Migration wird die wandernde VM auf der Quellmaschine während der Übertragung der Speicherseiten angehalten und die Inhalte der Seiten ändern sich deshalb nicht mehr. Bei der Life Migration läuft die VM aber weiter und somit können sich die Inhalte der bereits an das Zielsystem übertragenen Seiten nochmal ändern. Im Jargon wird das als „Verschmutzung“ (der schönen sauberen bereits übertragenen Seiten) bezeichnet. Die Iteration des pre-copy-Zustandes wird also durchgeführt, um die zwischenzeitlich „verschmutzten“ Seiten erneut zu übertragen, weil deren Inhalte ja sonst beim Neuanlauf der migrierten VM nicht mehr „stimmen“ würden, weil sie veraltet sind. Die Iteration des pre-copy-Zustandes hört dann auf, wenn entweder in einem Zeitraum mehr Seiten verschmutzt werden als Seiten übertragen werden können oder wenn die Anzahl der Iterationen einen vordefinierten Wert übersteigt. Die bei der Life Migration sozusagen von außen zu betrachtende Downtime einer VM ist lediglich die Dauer der letzten Iteration, weil die VM dafür angehalten und letztlich terminiert wird, um weitere Änderungen der Seiten zu vermeiden, bevor sie auf der Zielmaschine wieder starten und die Arbeit fortsetzen kann.

Normale Anwendungen und Web-Applikationen haben starke Lokalitäts-Eigenschaften und ändern Informationen üblicherweise zu einer Zeit nur in einem kleinen Bereich des virtuellen Speichers. Das ist seit Jahrzehnten die Grundlage für die Konstruktion virtueller Speichersysteme, bei denen ein Großteil der Seiten, die von einer Anwendung aktuell benutzt und somit geändert werden, immer in einem im Vergleich zu ihrem möglichen Adressraum sehr kleinen Bereich liegen. Ein Demand Paging Verfahren lädt dann die benötigten Seiten in gewisser Weise meist vorausschauend nach. Da auf den VMs nun überwiegend derart normale Anwendungen laufen, lässt sich das Lokalitätsverhalten übertragen, was bedeutet, dass eine VM auch überwiegend mit einem kleinen tatsächlich benutzten Speicherbereich arbeitet, der sich mit der Zeit verschiebt. Daher ist die Live Migration ein sehr sinnvolles Konzept, weil in der Regel nur ein kleiner Teil der zu übertragenden Seiten tatsächlich „verschmutzt“ werden wird.
Infiniband und RDMA

Infiniband IB ist ein Kommunikationssystem extrem hoher Leistung für anspruchsvolle RZ-Umgebungen. Die aktuelle Ausbaustufe FDR (Fourteen Data Rate, 14-fach gegenüber der ersten Ausbaustufe) bietet eine verlustfreie Übertragung mit 56 Gbps. Durch eine einfache Link-Aggregierung sind allerdings auch Übertragungsleistungen zwischen 360 und 400 Gbps möglich und auch in Einzelfällen implementiert. IB spannt ein eigenes Universum aus Komponenten aus, also IB Adapterkarten, IB Verbindungen und IB Switches, die sich konstuktiv erheblich von Ethernet unterscheiden. IB wurde ursprünglich von Itel ins Leben gerufen und wird heute von der IBTA (Infiniband Trade Association) weiterentwickelt. Pro übertragenem Gigabit ist eine IB-Lösung preiswerter oder höchstens genau so teuer wie eine entsprechende Ethernet-Lösung. Dennoch hat es sich nur in bestimmten Bereichen, wie in RZs für HPC und Cloud Providern, wirklich durchsetzen können. Die überwiegende Anzahl privater RZs benutzt kein IB und möchte es in Zukunft auch nicht einsetzen.

Wesentlich mit IB verbunden ist RDMA. Ganz vereinfacht gesprochen erweitert die RDMA-Semantik die Hardware eines Rechners um zwei einfache Kommandos: direktes Lesen (RDMA read) und direktes Ändern (RDMA write) des Inhalts eines entfernten Speichers. Ist RDMA einmal auf zwei Systemen installiert, kann letztlich jede Software auf einem System diese Funktionen auf dem anderen System benutzen. Für eine größere Anzahl von Systemen gibt es natürlich eine zweistufige Adressierung, die auf den physikalischen IB-Adressen beruht. Ein kleiner Protokollstack sorgt dann dafür, dass logische RDMA-Verbindungen auf- und abgebaut sowie verwaltet werden können. Dieser Stack hat keinerlei Möglichkeiten, auf Paketverluste zu reagieren. Wie bei Fibre Channel wird ein verlustfreies Übertragungssystem vorausgesetzt, was IB eben per Konstruktion ist.

RDMA-Operationen finden auf der initiierenden Seite statt und erzeugen keinen Software-Overhead auf dem jeweiligen Zielsystem. Bevor RDMA-Operationen stattfinden können, muss das Zielsystem lediglich Speicherbereiche registrieren und bei dieser Registrierung einen Schlüssel erzeugen, den es dann an die initiierende Seite schickt. Dieser Registrierungsprozess hilft Infiniband dabei, die DMA-Adressen der Speicherpuffer, die von den Benutzer-Prozessen gebraucht werden, zu erfahren. Es hilft außerdem dabei, zu vermeiden, dass fehlerhafte Programme Unfug in den betreffenden Speicherbereichen anstellen. Bei IB/RDMA müssen die Speicherbereiche der Initiatoren nicht durchgängig (zusammenhängend) sein, die Zielpuffer aber in jedem Fall.

VM-Migration mit RDMA: mögliche Vorzüge und Design-Anforderungen
In diesem Abschnitt betrachten wir sozusagen zur Motivation die möglichen Vorzüge der Implementierung einer VM-Migration mit RDMA, aber auch bestimmte Probleme, die konstruktiv gelöst werden müssen.

Neben dem puren Zuwachs an Bandbreite profitiert die VM-Migration im Wesentlichen in zwei Bereichen von RDMA. Zunächst ermöglicht RDMA den direkten Speicherzugriff durch Hardware I/O-Geräte ohne die Nutzung einer Betriebssystem-Funktion. Das ist für ein physikalisches System so, als sei der Speicher gar nicht auf einem fremden, entfernten Rechner, sondern würde direkt lokal bereitgestellt. Das bedeutet, dass die zu einer VM-Migation gehörigen Speicherseiten im Sinne einer Null-Kopie direkt an den entfernten Host geschickt werden können. Das vermeidet den Overhead, der durch die Nutzung eines TCP/IP-Stacks entsteht.

In Wahrheit ist das Ganze ja noch viel komplizierter. In einem Multiprozess-Betriebssystem existiert eine Menge von Elementarprozessen, die durch einen Scheduler abwechselnd auf den Prozessor (oder einen Core, wenn der Prozessor mehrere davon hat) abgebildet werden und dann eine Zeitscheibe zum Arbeiten erhalten. Das bedeutet im Klartext, dass zu einer Zeit immer nur genau ein einziger Prozess arbeitet. Nach dem Aufbrauchen seiner Zeitscheibe bzw. dem Eintreten eines Unterbrechungsereignisses wird der Prozess schlafen gelegt, bis er wieder an der Reihe ist. Zu den Unterbrechungsereignissen gehört auch die I/O. Grundsätzlich werden die Prozesse unterteilt in Systemprozesse und anwendungsunterstützende Prozesse.

Möchte ein anwendungsunterstützender Prozess während seiner Arbeit etwas ausgeben, kann er das nur in ein Register legen. Er kann dann anders weiterarbeiten, die I/O kann er aber nicht selbst machen. Dazu dient ein I/O-Prozess. Sobald dieser seine Zeitscheibe bekommt, kann er arbeiten und Informationen aus Registern holen und Informationen in Register schreiben. Die Register werden entweder von anwendungsunterstützenden Prozessen oder von anderen Systemprozessen gefüllt und entleert.

So weit, so gut. Die bei der VM-Migration notwendige Verlagerung von Speicherseiten bedeutet grob, dass der Systemprozess, der die VM-Migration steuert, einem anderen I/O-Prozess, der den TCP/IP-Stack implementiert, die Seiten Register für Register übergibt oder einen weiteren Hilfsprozess anstößt, der diese Übergabe erledigt. Der TCP/IP-Prozess erzeugt dann die Datenpakete und durchläuft seine Verfahren. Das kann er aber nicht alleine, denn er hat keinerlei physikalische Mittel zur Kommunikation. Die hat einzig der I/O-Prozess, der die Adapterkarte nutzt und steuert. Also gibt der TCP/IP-Prozess die Daten paketweise an den I/O-Prozess. Im Zielsystem läuft das Ganze ebenfalls auf die besprochene Art und Weise ab. Das funktioniert zwar, aber durch die vielen beteiligten Prozesse und die vielen notwendigen Prozesswechsel wird das beliebig langsam. Kommt dann noch wie im Falle von VMware ein virtueller Switch mit ins Spiel, verkompliziert sich das Ganze weiter, denn dann gibt es auf beiden Seiten noch zusätzliche anwendungsunterstützende Prozesse, die den V-Switch implementieren.

Alleine die Anzahl der benötigten Komponenten und die vielfältige Kommunikation zwischen ihnen verlängern nicht nur den Weg und erhöht die Latenz, sondern ist auch die Ursache dafür, dass der Prozessor oder Core durch diese Konstruktion erheblich belastet wird.

Jedes Mal, wenn Informationen in der besprochenen Art und Weise weitergegeben werden, spricht man in der Betriebssystem-Terminologie auch von einem Kontext-Wechsel (es gibt noch viele andere Anlässe für Kontext-Wechsel, aber die spielen hier keine Rolle).

Von daher erscheint die Idee, diese ganze Anhäufung einfach zu überspringen, in noch hellerem Licht als ohnehin schon. Zusammenfassend reduziert RDMA die Anzahl der im Rahmen einer VM-Migration notwendigen Kontext-Wechsel ganz erheblich.
Ein weiterer wesentlicher Vorteil ergibt sich durch die weiter oben schon dargestellte Asymmetrie von RDMA. Die Zielmaschine muss fast nichts tun. Dadurch wird sie im Zusammenhang mit einer RDMA-gestützten VM-Migration kaum belastet. Das steht in krassem Gegensatz zu der VM-Migration über TCP/IP, bei der Quell- und Zielmaschine grob die gleiche Last haben, weil die oben beschriebenen Vorgänge ja auf beiden Seiten ablaufen.

Die Einsparung von CPU-Zyklen ist in manchen Anwendungsfällen wirklich wesentlich. Eines der wesentlichen Ziele der Virtualisierungstechnologie ist ja die Server-Konsolidierung, bei der multiple Betriebssysteme auf einem physikalischen System laufen, um seine Ressourcen effektiv ausnutzen zu können. Heute sind die Virtualisierungs-Strukturen in privaten RZs überwiegend sehr übersichtlich sowohl hinsichtlich der Anzahl der VMs als auch der Nutzung von Zusatzfunktionen wie FT. Außerdem ist das Ganze relativ starr strukturiert. In der Zukunft kann hier eine zunehmende Dynamisierung erwartet werden, wie es sie in großen RZs schon gibt. Die VM-Migration ist dann eine Basisfunktion der gesamten virtualisierten Umgebung und wird dann nicht nur alle paar Tage, sondern Tausende Male im ganz normalen Betrieb z.B. bei der dynamischen Provisionierung von VMs für Kunden-Anwendungen oder bei einem automatisierten System, welches aus Gründen der Energie-Effizienz danach strebt, Server immer möglichst vollständig oder gar nicht zu nutzen und daher die Menge der laufenden Server dynamisch steuert, ausgeführt. Belastet dann die VM-Migration die CPUs allzu stark, könnte diesen entweder einfach die Puste ausgehen, was für alle anderen Anwendungen, die auf einem betroffenen Core oder Prozessor laufen, mindestens ungünstig ist, oder fortgeschritten dynamische Konzepte völlig ad absurdum führen.

Der durch RDMA erheblich reduzierte Overhead ist vor allem bei leistungs-sensitiven Funktionen wie Load Balancing oder zur proaktiven Fehlertoleranz hoch interessant.

Um aber das Potential von RDMA richtig entfalten zu können, müssen einige Design-Anforderungen bei der Konstruktion von VM-Kommunikation via RDMA bewältigt werden.

Wir beschränken uns an dieser Stelle auf die Migration in Xen und die Nutzung von RDMA mit IB. Die Fragestellungen und Ergebnisse sind aber auch auf andere Virtualisierungssysteme und die Nutzung von RoCE über CEE übertragbar, was wir später nachtragen.

Kern einer leistungsfähigen Lösung ist der Entwurf eines sinnfälligen Systems für die Migration an sich, welches die Leistungen von RDMA richtig nutzt. Wie bereits dargestellt, können normale Speicher-Seiten einfach übertragen werden, aber Seiten mit Page Tables müssen vorbehandelt werden. Ein Migrationsverfahren muss mit diesen beiden Typen von Seiten sinnvoll umgehen. Für die Migration können sowohl RDMA Read als auch RDMA-Write-Primitive benutzt werden. Sie haben aber unterschiedliche Auswirkungen auf Quell- oder Ziel-Hosts. Ein Migrationsverfahren sollte hier eine möglichst ausgewogene Methode verfolgen.

Infiniband verlangt, dass Speicherbereiche registriert werden, bevor sie benutzt werden können. Es gibt hier zwei grundsätzliche Lösungen. Eine Methode ist es, die Daten immer in vor-registrierte Puffer zu schreiben, die andere ist es, die Puffer on-the-fly zu reservieren (Zero Copy, Nullkopie). Keiner dieser Ansätze arbeitet aber wirklich gut für die VM-Migration. Der erste Ansatz verbraucht relativ unnötig CPU-Zyklen und belegt Speicherplatz, der nachher vielleicht gar nicht benötigt wird. Er hat also die gleichen Nachteile wie der Transfer mit TCP. Zero Copy verlangt die Reservierung von Puffern, die eigentlich einer fremden VM gehören. Das ist im IB-Standard aus Sicherheitsgründen nicht vorgesehen.

Unterbrechungen beim Datenverkehr. Die Original Live Migration bei Xen überträgt die Daten in Seiten-Granularität. Jedes Mal sendet der Quell-Host genau eine Seite an den Zielhost. Das mag gut für eine Kommunikation mit TCP sein, führt aber zu einer absoluten Unterbeschäftigung der leistungsfähigen IB-RDMA-Verbindung. Für eine gute Ausnutzung einer RDMA-Verbindung wäre es wünschenswert, direkt mehrere Seiten auf einmal übertragen zu können.

QoS im Netz. Obwohl RDMA den größten Teil des üblichen Netzwerk-Overheads minimiert, steht es natürlich in einem Netz in Konflikt mit anderen Verkehrsströmen. Um eine wirklich reibungslose VM-Kommunikation zu ermöglichen, sind gesonderte Maßnahmen erforderlich, um den zur Migration gehörenden Verkehr zu schützen. In modernen IB-Installationen gibt es hierzu ein passendes QoS-Verfahren. Besitzer eines konvergierten Ethernets haben es sogar noch ein wenig besser, weil sie die Verkehrslenkung im Rahmen der DCB-Protokolle definieren und durch die Verfahren im Netz automatisch durchsetzen lassen können. Diese Eigenschaft des konvergierten Ethernets macht es für die RDMA/RoCE-basierte VM-Migration sogar noch einen Tick besser als reines IB.

« Teil 16: Hoch leistungsfähige VM-MigrationTeil 18: Lösungsmodell für die VM-Migration mit RDMA »


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.

*

.