Hoch leistungsfähige VM-Migration

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

Eine der nützlichsten mit der Virtualisierung einhergehenden Eigenschaften ist die Möglichkeit, VMs zwischen laufenden Betriebssystemen auf voneinander entfernten, durch ein Netzwerk verbundenen Knoten bewegen zu können. Dies ist heute die Grundlage vieler administrativer Werkzeuge in Cloud-RZs und anderen leistungsorientierten Rechenzentren. Daher ist es wünschenswert, die VM-Migration extrem effizient zu gestalten, um einerseits die Dauer für eine Migration so gering wie möglich zu halten und zum anderen die Prozessoren nicht mehr als nötig damit zu belasten, um Rückwirkungen auf die laufenden Anwendungen möglichst zu vermeiden.

Heute benutzen die meisten Virtualisierungslösungen die Socket-Schnittstelle und den TCP/IP-Stack, um die VM-Migration zu implementieren. Eine neue Alternative zur VM-Migration ist die Verwendung von RDMA (Remote Direct Memory Access). Dies war bislang primär den Betreibern von Infiniband-Netzen vorbehalten, ist jetzt aber vermöge des OFED-Stacks mit dem Protokoll RoCE (RDMA over Converged Ethernet) auch für moderne Ethernet-Infrastrukturen verfügbar, an die lediglich die Anforderung gestellt wird, dass sie ein Protokoll für die verlustfreie Übertragung implementieren, üblich wäre der Einsatz der DCB-Protokolle zu diesem Zweck. Wegen günstiger konstruktiver Eigenschaften und einem geringen Software-Overhead verbessert RDMA die Effizienz der VM-Migration erheblich, wie vielfach an Messungen gezeigt werden konnte. Bei der Verwendung von Xen konnte die Migrationszeit um ca. 80% gesenkt werden, was z.B. bei der Realisierung eines kontinuierlichen Betriebsmodells die Downtime für eine Anwendung um ca. 77% senken kann. Unter VMware konnte die Zeit für vMotion um ca. 40% und damit nicht so deutlich gesenkt werden, dafür aber die CPU-Belastung der beteiligten Rechner um bis zu 90%. Es gibt heute schon eine Reihe von Cloud-Providern, die nicht nur den ausfallsicheren Betrieb, sondern auch die automatische Provisionierung von Kunden-VMs auf der Basis von VM-Migration mit RDMA gestalten, oftmals in einer RedHat LINUX-Umgebung. Hier gibt es auch vorgefertigte Lösungen z.B. für den Betrieb von SAP-Umgebungen. Neben der Eingliederung von RDMA/RoCE in die Virtualisierungssoftware sind auf der Netzseite auch verschiedene Aktivitäten zu verzeichnen, z.B. die Entwicklung einer Erweiterung von SR-IOV um RoCE, was letztlich zu einer Hardware-Unterstützung von VM-Migration und VM-Kommunikation führen wird, die in einer Kombination mit 40 GbE alle bisherigen Leistungseckdaten völlig in den Schatten stellen wird.

Abgesehen von einer Einführung betrachten wir in diesem und den nächsten Artikeln folgende Themen:

  • VM-Migration am Beispiel Xen
  • VM-Migration mit RDMA: mögliche Vorteile und Design-Anforderungen
  • Lösungsmodell für die VM-Migration via RDMA
  • Der Einfluss von QoS im Netz
  • Ergebnisse
  • Anwendung von RDMA/RoCE auf konvergiertem Ethernet sowie mit weiteren Virtualisierungssystemen, besonders VMware

Einführung
Virtualisierungstechnologien haben sich in den letzten Jahren immer mehr durchgesetzt, weil sie eine Reihe von Eigenschaften mitbringen, die in modernen RZ-Umgebungen wünschenswert sind, wie die Möglichkeit der Konsolidierung von Servern, die Isolation von Leistungen und die zunehmende Automatisierung des RZ-Betriebs.

Die VM-Migration ist dabei eine der wichtigsten neuen Funktionen. Sie erlaubt System-Administratoren die Verlagerung einer VM von einer physikalischen Betriebssystem-Instanz zu einer anderen ohne den laufenden Betrieb und die damit verbundenen Dienstleistungen im Rahmen der Implementierung von Anwendungen ernsthaft zu unterbrechen. Die VM-Migration ist ein extrem wirkungsvolles Werkzeug bei der Verwaltung von Clustern und ist die Grundlage vieler moderner Administrations-Werkzeuge für Cluster und RZs, die darauf hinzielen, im laufenden Betrieb Wartung, Rekonfigurierung, Load Balancing und proaktives Fehler-Management vorzunehmen. Daher ist es natürlich besonders wichtig, diese Funktion sehr effizient und ohne große zusätzliche Belastung für die Prozessoren ausführen zu können.

Bevor wir zu den Details kommen, müssen wir zunächst ein oft zu findendes Missverständnis aus dem Weg räumen. VM-Kommunikation und VM-Wanderung werden immer in einem Atemzug genannt und es liegt nahe, dann auch eine einzige Lösung für diese beiden Problemkreise zu finden.

Das ist aber unrichtig, denn bei der VM-Kommunikation im Allgemeinen und bei der VM-Wanderung handelt es sich zunächst um zwei grundverschiedene Dinge:

  • die VM-Kommunikation dient dem Informationsaustausch zwischen VMs und der Kommunikation von VMs mit der Außenwelt. Objekte dieser Kommunikation sind eben allgemein die Daten, die VMs erzeugen und verbrauchen. Operationen auf diesen Objekten sind primär asynchrones Senden und Empfangen. Parameter dieser Operationen sind u.a. Netzwerkadressen, mit denen man die vNICs oder vHBAs der VMs erreichen kann.
  • die VM-Wanderung wird, um es allgemein zu formulieren, von „Wanderungs-Hilfs-Prozessen“ durchgeführt, die zu den Hypervisoren der beteiligten Maschinen gehören oder auf deren Ebene liegen. Objekte dieser Kommunikation sind speziell die Seiten der Bereiche des grundlegenden Betriebssystems, welche die VMs beschreiben. Operationen auf diesen Objekten sind Übertragung von einem System zum anderen verbunden mit Transformation von maschinen-abhängigem Code in maschinen-unabhängigen Code und zurück. Parameter dieser Operationen sind die Netzwerk-Adressen der physikalisch existenten NICs oder HBAs der Quell- und Ziel- Server.

Aktuelle VM-Technologien wie Xen oder VMware implementieren die VM-Migration dadurch, dass Seiten aus dem Speicherbereich des Gast-Betriebssystems auf der Quell-Maschine über den TCP-Socket an den Ziel-Host geschickt werden, damit dort die Arbeit wieder aufgenommen werden kann. Hierbei gibt es dann noch verschiedene Varianten. So gibt es auch das Konzept, auf der Zielmaschine bereits eine vorkonfigurierte Shadow-VM zu starten, die die Arbeit der VM, die von einer Quelle zu diesem Ziel sofort aufnehmen kann, sobald sie die entsprechenden Daten, also den Speicherinhalt hat. Sobald die Shadow-VM laufen kann, wird sie zu der „gewanderten“ VM und die ursprüngliche VM wird terminiert. Das kann man auch noch steigern, indem man die Shadow-VM schon weit vor der eigentlichen Wanderung mit Daten versorgt und somit an zwei physikalischen Stellen zwei identische VMs auf identischen Daten parallel laufen lässt und die Wanderung eigentlich nur darin besteht, eine von diesen VMs zu löschen. Grundsätzlich sind hier praktisch alle Varianten denkbar, die wir schon aus dem Umfeld der ehemaligen PC-Server, z.B. mit Novell NetWare für einen unterbrechungsfreien Betrieb kennen.

Die Verwendung der TCP-Sockets für den Transfer der Speicherinhalte stellt zwar sicher, dass das Konzept sofort auf praktisch allen industriell angebotenen Systemen sofort laufen kann, führt aber zu suboptimaler Leistung wegen zu hohen Protokoll-Overheads, erheblicher Involvierung des Betriebssystem-Kerns und der Notwendigkeit der Einführung zusätzlicher Synchronisationsmechanismen, die die eigentlichen Vorteile erheblich überschatten können. Der oben geschilderte Parallelbetrieb zweier VMs ist ein kardinales Beispiel für die eigentlich völlig unnütz erhöhte zusätzliche Belastung der Prozessoren.

Seit einigen Jahren bieten hoch leistungsfähige Verbindungssysteme wie Infiniband Möglichkeiten, bei der Kommunikation den Betriebssystem-Kern zu umgehen und einen direkten Speicherzugriff auf ein entferntes System (RDMA) vorzunehmen. Ein BS-Bypass ermöglicht es, eine Kommunikation unmittelbar aus der Benutzer-Ebene der Laufzeitumgebung eines Prozesses auszulösen. Darüber hinaus kann man mit RDMA direkt Daten in den Speicher eines entfernten Systems schreiben. Die Kombination aus BS-Bypass und RDMA erlaubt einen sehr effektiven Informationstransfer in ein fremdes System mit sehr geringem zusätzlichen Synchronisationsaufwand. Es gibt seit Jahren viele Anwendungen, die ohne RDMA undenkbar wären, wie z.B. verteilte objektorientierte Datenbanken, Hochfrequenz-Handels-Systeme oder Systeme im Simulations- und Konstruktionsbereich. Alle wichtigen Hersteller von Servern, wie IBM, HP, Cisco oder Dell, bieten für ihre Spitzenmodelle RDMA/Infiniband-Komponenten an, beim neuen HP ProLiant 390 sind sie sogar direkt LOM.

Auch die VM-Kommunikation kann vom Einsatz von Hochgeschwindigkeits-Verbindungen mit RDMA erheblich profitieren. Verbindungstechnologien wie FDR Infiniband (56 Gbps) mit RDMA oder 10/40 Gb-CEE mit RoCE können die zur Übertragung von Speicherseiten notwendige Zeitdauer gegenüber anderen Varianten erheblich reduzieren. Das trägt unmittelbar zur Verringerung der für eine VM-Migration insgesamt benötigten Zeit bei. Die Kommunikation mit dem Betriebssystem-Bypass und RDMA enthebt von der Notwendigkeit, eine CPU, Caches oder Kontext-Switches an dem Prozess zu beteiligen. Dadurch werden die CPUs kaum zusätzlich belastet und Rückwirkungen auf andere laufende Anwendungen praktisch völlig vermieden.

In diesem und den nächsten Artikeln geht es primär um die Implementierung der VM-Migration mit RDMA. Dabei blenden wir die Varianten wie RoCE oder iWARP sowie die Diskussion über die Nutzung des konvergierten Ethernets und die Probleme, die bei der Nutzung von Fernverbindungen auftreten können, zunächst aus. Das holen wir nach, wenn das Grundkonzept geklärt ist. Ebenso vergleichen wir die VM-Migration über RDMA an den dafür in Frage kommenden Stellen nur mit der Implementierung über TCP-Sockets, weil das der allgemein gültige Fall ist. Zu Differenzierungen, die z.B. in unterschiedlichen Virtualisierungslösungen durch die Verwendung Virtueller Switches auftreten, kommen wir ebenfalls wegen der mangelnden Allgemeingültigkeit an einer späteren Stelle.

Wir analysieren die Probleme, die entstehen, wenn man VM-Migration via RDMA implementiert, z.B. hinsichtlich der benutzten Protokollstruktur, der Registrierung in den Speichern, des Daten-Transfers bei nicht direkt benachbarten Systemen, QoS usw. All dies wird ausgeleuchtet, um die Vorzüge von RDMA möglichst vollständig zu erfassen. Natürlich gehen wir auch auf Ergebnisse ein, die bei Tests mit Virtualisierungssoftware unterschiedlicher Hersteller gemacht wurden.

« Teil 15: Zur Kommunikation virtueller Maschinen unter besonderer Berücksichtigung von SR-IOV, DirectPath und VNLinkTeil 17: VM-Migration am Beispiel Xen »


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.

*

.