Ergebnisse für die VM-Migration mit RDMA und Nutzung von RoCE

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

Man kann sich theoretisch überlegen, wie eine VM-Migration am besten funktioniert, letztlich wichtig sind aber nur Messergebnisse. Diese sind natürlich wiederum von den Umgebungen abhängig. In diesem Abschnitt bleiben wir erst einmal bei den bisher beschriebenen Verfahren im Zusammenhang mit dem Xen-Server mit purem RDMA auf Infiniband. Viele private RZs verwenden heute noch kein IB, sondern lieber konvergiertes Ethernet. Also sehen wir uns an, wie man die Mechanismen (und damit die Ergebnisse) auf CEE übertragen kann.

Im konkreten Fall wurde das Migrations-Design mit InfiniBand Open Fabric words und Xen 3.0.3 implementiert. Verglichen wird das mit der bestehenden Lösung unter TCP/IP. Um dabei aber fair zu bleiben, wurde mit der Variante IP über IB (IPoIB) gearbeitet und nicht mit normalem Ethernet. IPoIB liefert in der Praxis für die Übertragung deutlich bessere Ergebnisse als IP über CEE und es geht ja hier zunächst primär darum, die Qualität der entworfenen Verfahren zu bestimmen.

Die Experimente wurden auf einem Infiniband-Cluster gemacht. Jedes System des Clusters hat eine duale Intel Xeon 2,66 GHz-Plattform mit 2 GB Speicher und einem Mellanox MT 23108 PCI-X-IB-HCA. Auf allen Knoten läuft Xen 3.0.3 mit dem Linux 2.6.16.29-Kern.

Das Bild 1 zeigt, wie lange VMs mit unterschiedlichen Speicherkonfigurationen zu ihrer Migration benötigen. Es wurden vier verschiedene Arbeits-Schemata verwendet, nämich mit RDMA read oder RDMA write sowie jeweils mit und ohne Page Clustering. Es zeigt sich, dass das Page Clustering den erwarteten Vorzug bringt und durch die Zusammenfassung von zu übertragenden Seiten eine bis zu 27 % schnellere Migrationszeit erreicht werden kann. Der Effekt ist umso deutlicher, desto größer der gesamte Speicherbereich einer VM ist, wie zu erwarten war. In der Zukunft werden VMs in jedem Falle eher größer als kleiner werden, von daher ist das ein sehr wichtiges Ergebnis.

Das Bild 2 zeigt dann den Vergleich zwischen der VM-Migration mittels IPoIB im Vergleich zu RDMA. Das Ergebnis ist noch erschütternder, als man annehmen konnte: die Dauer einer VM-Migration kann durch RDMA um bis zu 80% gesenkt werden !

Es gibt noch kleine Unterschiede zwischen den RDMA read und RDMA write-Varianten, die darauf beruhen, dass die RDMA write-Operation durchschnittlich etwas mehr Bandbreite zur Verfügung stellt.

In Bild 3 wird ein ganz besonders spannender Test durchgeführt. Zu Beginn liegt eine Anzahl von VMs auf einem zentralen Server und sie werden dann alle auf jeweils einen anderen Server migriert. Gemessen wird die Gesamtzeit dieser Operation. Das entspricht dem Szenario, bei dem ein Server unterzugehen droht und im Rahmen des proaktiven Fehler-Managements alle auf ihm laufenden VMs verlagert werden müssen oder dem Fall, der entsteht, wenn Kunden-VMs in größerer Anzahl provisioniert werden müssen. Man sieht bei der Verwendung von IPoIB, dass die Gesamt-Dauer erheblich ansteigt, sobald drei oder mehr VMs bewegt werden müssen. Das liegt einfach daran, dass in den betrachteten Rechnern jeweils zwei Cores sind und der Quell-Server dann in die Situation kommt, mehr VMs bewegen zu müssen als er Cores hat, was zu einer Serialisierung führt. Hier kommt jetzt sehr anschaulich der Einfluss der durch die bei der VM-Migration verwendeten Übertragungstechnik implizierten Prozessorbelastung zum Tragen. TCP/IP, in welcher Form auch immer, belastet einen Prozessor bzw. Core relativ stark, während RDMA die Belastung sehr gering hält. In dieser Konstellation ist es daher so, dass die Belastung durch IP bei mehr als 2 zu bewegenden VMs den gesamten Vorgang erheblich verlangsamt, während mit RDMA auch viele VMs ohne große Mühe bewegt werden können.

Im Falle der Live-Migration ist es ja entscheidend, wie lange die Phase dauert, in der die VM tatsächlich nicht arbeiten kann. Die unterste Grenze ergibt sich durch die Round-Trip-Zeit des zugrunde liegenden Kommunikationsmechanismusses. Sie ist bei RDMA immer unter 10 µsek. Im besprochenen Szenario wurde gemessen, dass die tatsächliche Downtime einer bei der RDMA-gestützten Live-Migration abhängig von ihrer Größe bis 256 MB deutlich unter einer Sekunde liegt. Davon kann eine IP-gestützte Lösung nur träumen.

Anwendung von RDMA/RoCE auf konvergiertem Ethernet
Bisher haben wir ausschließlich die VM-Migration unter Xen mit RDMA unter IB betrachtet. Für die Anwendung in privaten Unternehmensnetzen ist sicherlich die Nutzung von RoCE interessanter. Ebenso müssen wir uns ansehen, wie die RDMA/RoCE-Entwicklung bei anderen Virtualisierungssystemen aussieht, vor allem bei VMware.
Dazu sehen wir uns zunächst kurz den OFED-Stack an.

Der RDMA-Stack realisiert seit vielen Jahren zuverlässige höchst performante Inter-Prozess-Kommunikation mit der Übertragungstechnik InfiniBand. IB ist hinsichtlich der Performance den Ethernet-Lösungen immer einen großen Schritt voraus, ohne teurer zu sein. Deshalb ist es auch die bevorzugte Übertragungstechnik in den TOP 500 Rechenzentren der Welt und darüber hinaus Standard bei HPC.

Betreiber konventioneller privater RZs möchten deren Netze aber weiterhin auf Basis von Ethernet weiterentwickeln. Daher ist es außerordentlich erfreulich, dass VM-Kommunikation und VM-Migration auf RDMA-Basis seit einigen Monaten auch für konvergiertes Ethernet verfügbar ist. Das hat recht spontan dazu geführt, das fast 80% der Fortune 2000-RZs mit dieser Technik arbeiten oder dies testen.

Den Durchbruch in dieser Hinsicht brachte die Definition einer kleinen zusätzlichen Abstraktionsstufe durch die OFA (Open Fabrics Association) im Rahmen des so genannten OFED-Modells (Open Fabrics Enterprise Distribution). Sinn von OFED ist es generell, Entwicklungen aus dem HPC-Umfeld auch für normale RZs verfügbar zu machen.

Im konkreten Fall definiert OFA mit OFED einen Message Passing Service, auf den kommunizierende Komponenten auf eine übersichtliche Menge von „verbs“ zugreifen. Das OFED verbs API ist die Methode, mit der ein Objekt auf den Message Passing Service zugreift.

Dese Verbs stehen für Aktionen wie „schreibe X in den Speicher von B“ wenn man z.B. das Objekt A ist, das mit B kommunizieren möchte. Über diese einfachen Aktionen kann man auch eine Synchronisation von Prozessen herbeiführen. Wichtig ist folgendes:

  • den „verbs“ ist die Natur des Objektes, welches sei benutzt, völlig egal. Das kann also eine VM sein, aber auch eine normale Anwendung, oder ein Systemprozess, der einen Speicher unter sich hat und diesen durch eine LUN präsentiert.
  • die kommunizierenden Objekte sehen nur die „verbs“, mit dem sie den Mechanismus zum Nachrichtenaustausch benutzen. Die weitere Implementierung ist für sie eine Black Box

RDMA ist eine extrem leistungsfähige Implementierungsmöglichkeit für den Message-Passing Service, bleibt aber jetzt hinter den „verbs“ versteckt.

Wegen dieser Abstraktion kann man das Innere der Black Box auch austauschen. Dabei werden zwei Protokolle besonders interessant: RoCE und iWARP. RoCE (RDMA oder Converged Ethernet) ist ein Protokoll, um RDMA-Nachrichten auf konvergiertem (verlustfreien) Ethernet zu übertragen. Prinzipiell also wie FCoE nur mit dem Unterschied, dass es in Tausenden Installationen bereits prima funktioniert und auch keine Probleme mit Hintereinanderschaltung von Switches hat. iWARP (Internet Wide Area RDMA Protocol) ist das L3-Gegenstück zu RoCE und überträgt RDMA-Nachrichten über IP-Netze. Es kommt jetzt auf die Implementierung an, ob die Verlustfreiheit in diesem Falle durch TCP oder durch einen verschlankten Mechanismus durchgeführt wird. Das kann dem Betreiber aber egal sein, es gibt schon iWARP FPGAs.

In einem „normalen“ RZ ist es aber nunmehr wiederum völlig übertrieben, für jede Art der Kommunikation RDMA, RoCE oder iWARP zu benutzen, denn dann würde man sozusagen den beschriebenen Fehler, IPC via I/O zu machen, dadurch wiederholen, dass man jetzt die I/O via IPC implementiert. In diesem Zusammenhang kommt RoCE eine besondere Bedeutung zu. Es wird dadurch nämlich möglich, die Konvergenz von Ethernet, die wir hinsichtlich der Integration von Speicherverkehr mit FCoE implementieren, endlich auch auf IPC zu erweitern.

Dadurch erhalten wir sozusagen eine Ethernet-Trilogie:

  • „normales“ Networking mit TCP/IP
  • Speicherverkehr mit FCoE (oder natürlich iSCSI)
  • Low Latency Messaging IPC mit RoCE

RDMA wird auf dafür ausgelegten HCAs, also Adaptern, implementiert. Dadurch kann es für die VM-Migration von den daran beteiligten Prozessen unmittelbar genutzt werden. Dies gilt auch, wenn zusätzlich der beschriebene OFED-Sack implementiert wird, um RDMA nicht auf IB, sondern auf konvergiertem Ethernet einzusetzen.

Aber: RoCE hat einen erheblich weiteren Anwendungsbereich als die bloße VM-Kommunikation. Der OFED-Stack ist in vielen Linux-Distributionen enthalten. Bild 8 gibt auszugsweise eine Übersicht über andere Implementierungsbereiche, siehe Bild 11.

Hersteller von Virtualisierungssoftware arbeiten aber, wie wir gesehen haben, auch daran, die RDMA-Kommunikation in einer Art „Durchgriff“ auch für die VMs verfügbar zu machen. Damit eröffnet sich die Perspektive, die beiden sehr unterschiedlichen Kommunikationsarten auf einer technischen Basis zusammen zu fassen.

Und das Beste fast zum Schluss: alles, was in diesem Abschnitt beschrieben wurde, ist sofort verfügbar. Wegen der Bedeutung für große Betreiber traut sich kein Server-Hersteller, RDMA nicht angemessen zu unterstützen. Bei den neuen großen HP ProLiant 390-Servern ist es sogar LOM. Der primäre Weltmarktführer für IB-Switches und HCAs mit RDMA ist zwar Mellanox, aber durch den OFED-Stack entstehen hier keine wirklich dauerhaften Abhängigkeiten. Einmal in ein RoCE-Paket eingepackt, reist ein RDMA-Paket friedlich durch alle Ethernet-Fabrics, sofern sie verlustfrei aufgebaut sind, also die DCB-Protokolle auf allen Wegen implementieren. Manchmal muss man bei den Line Cards aufpassen, für den Nexus 7000 von Cisco Systems sind nur die F-Cards aktuell auf lossless Ethernet ausgelegt. RoCE wurde von Arista, Cisco, IBM, Mellanox QLogic und RedHat gemeinsam entwickelt.

« Teil 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.

*

.