Nutanix AHV – Der unsichtbare Turbo

Kunden die bereits AHV als Hypervisor einsetzen, wissen bereits um die Vorteile der einfachen Verwaltung. Und ebenso unauffällig erhält der AHV Hypervisor mit Version 5.5 einen neuen „Turbo Modus“, welcher den Datenpfad für Storage I/O, zwischen VM und der CVM, extrem optimiert.

Es stellte sich die bisherige Situation so dar, dass eine AHV VM nur einen einzelnen virtuellen SCSI Controller nutzt und dieser auch nur eine I/O Queue mit bis zu 128 Outstanding I/Os verfügt. Gleiches galt für die einzelne vDisks, welche pro Device auch nur eine I/O Queue zur Verfügung hatten. Gab es mehrere Applikationen die I/Os auf der gleichen vDisk erzeugten, mussten diese sich um Plätze in der Queue streiten (Lock Contention) und alle I/Os aller vDisks, flossen in einer Queue des SCSI Controllers zusammen. Diese Queue wird bis dato auch nur von einem Thread verarbeitet.

Die erste Frage die sich natürlich stellt, wie können Kunden zukünftig den AHV Turbo Mode nutzen? Einzig ein One-Click Upgrade auf AOS 5.5 und AHV 20170830.58, ist dazu notwendig.

AHV-One-Click-Upgrade

Die Optimierung findet transparent unter der Haube satt und wird automatisch für alle VMs aktiviert, die auf einem aktualisierten AHV gestartet werden und alle Anforderungen erfüllt.

Mit dem neuen AHV Turbo Mode, wird gleich an mehreren Stellen der I/O Pfad optimiert.

Die erste Station ist die Anzahl der I/O Queues pro vDisk, die jetzt an die Anzahl der vCPUs einer VM geknüpft ist. Sprich hat eine VM 4 vCPUs, hat jede vDisks 4 I/O Queues.

Die zweite Station ist der virtuelle SCSI Controller, welcher zwar noch immer ein einzelner Controller ist, aber jetzt über mehre I/O Queues verfügt, deren Anzahl ist ebenso an die der vCPUs gebunden.

All diese I/O müssen jetzt aber auch entsprechend effizient verarbeitet und Richtung CVM transportiert werden. Dazu können diese Queues auf Ebene des SCSI Controllers jetzt mittels mehrerer Threads verarbeitet werden.

FRODO

Eine weitere Besonderheit ist, dass der I/O Pfad nicht wie bisher durch QUEMU direkt erfolgt, sondern die I/Os durch eine eigens entwickelte „FRODO“ Komponente verarbeitet werden. Pro QUEMU/VM Instanz, wird ein dazugehöriger FRODO Prozess gestartet. FRODO weiß quasi, dass „er“ dafür da ist, SCSI Befehle zu verarbeiten und dass „er“ von der VM SCSI Befehle erhält und das die Gegenseite, also die CVM, auch solche erwartet. Das heißt, dass in diesem Fall die SCSI Befehle nur mit einem iSCSI Header versehen werden und nicht anderweitig übersetzt werden müssen. Somit wird der I/O Pfad nicht nur durch mehrere Queues und Multi-Threading optimiert, sondern auch der Overhead auf ein Minimum reduziert, was sich in einer reduzierte CPU Last widerspiegelt.

Hier ein paar Beispiele:

  1. 25% Reduzierte CPU Auslastung bei ziemlich gleicher sequentieller Write Performance (2929MBps vs. 2964MBps)
  2. 5% höhere sequentielle Read Performance (9512MBps vs. 7207MBps)
  3. 52% Mehr random Read IOPS (510121 vs. 261265)
  4. 75% Mehr in random Write IOPS (336326 vs. 239193)

Die Werte habe ich bei meinem Kollegen Josh Odgers geliehen und nicht selbst gemessen.

Der neue I/O Pfad kann somit ideal das Potential der lokale Speicher Medien, wie beispielsweise NVMe basierte Flash Devices nutzen. Hier mal ein Beispiel dafür, was somit aus einer VM heraus möglich ist.

AHV_Turbo_1m

Um die maximale Performance ausreizen zu können, sollte in den jeweiligen Gastbetriebssystemen „Multi-Queuing“ (MQ) aktiviert werden. Unter Linux erfolgt dies über die Kernel Command Line:

scsi_mod.use_blk_mq=y

Es sei noch erwähnt, dass der Kernel ab Version 4.14 MQ standardmäßig aktiviert hat.

Während für Windows, durch Nutanix, bald neue VirtIO Treiber angeboten werden, welche die Nutzung von MQ möglich machen. Diese findet man dann entsprechend im Nutanix Support Portal zum Download.