VMware-Performance: RDM vs. VMFS, Resource Pools, CBT und Paravirtualisierung

    TuningIm Vergleich zu physikalischen Maschinen sind virtualisierte Systeme zweifellos flexibler, allerdings um den Preis zusätzlicher Komplexität. Gerade wenn es um die dynamische Zuteilung von Ressourcen zu Workloads geht, ist VMware vSphere das System mit den am meisten fortgeschrittenen Funktionen. Sie bieten jedoch auch Anlass zu falschen Interpretationen. Der holländische Blogger und vExpert Eric Sloof widerlegt 4 häufige Annahmen über die Auswirkung bestimmter Features auf die Performance von vSphere.

    Sloof hielt den mehr als eine Stunde dauernden Vortrag, der nun auf YouTube angesehen werden kann, ursprünglich auf der VMworld 2011. Er widmet sich Funktionen und Konfigurationen, die sich angeblich negativ auf die VMware-Performance auswirken oder umgekehrt im Ruf stehen, diese zu verbesseren. Einzelne dieser Auffassungen waren in früheren Stadien der Virtualisierung berechtigt, sind aber durch die Weiterentwicklung von vSphere und der Hardware obsolet geworden.

    Raw Device Mapping (RDM) versus VMFS

    RDM bietet die Möglichkeit, einer virtuellen Maschine die LUN eines SAN direkt zugänglich zu machen. Es scheint naheliegend, dass eine solche Konfiguration schneller ist als die sonst übliche Kombination aus dem Cluster-Dateisytem VMFS und einer VMDK-Datei. Unter ESX 3.x war dies offenbar wirklich der Fall.

    Allerdings weist Eric Sloof darauf hin, dass Schreib- und Lesezugriffe sowohl bei RDM als auch bei VMFS/VMDK durch den ESX-Kernel laufen, der nur noch sehr kurze Latenzzeiten verursacht, während jene des Storage-Arrays in der Regel um ein Vielfaches höher seien. Die geringen Ersparnisse bei den Guest-Latenzen sind laut der Messungen von Sloof so gering, dass sie in der Praxis so gut wie nicht nachweisbar seien.

    Bei Virtual RDM ist die VMDK-Datei nur mehr ein symbolischer Link auf einem VMFS-Volume, der auf das Raw LUN verweist.Wer daher Raw Disks wählt, um eine bessere Leistungen zu erzielen, liegt falsch und handelt sich obendrein ein paar Nachteile ein. Sie bestehen unter anderem darin, dass eine LUN exklusiv für eine VM bereitgestellt werden muss, was sich bei maximal 255 LUN-IDs schnell als hinderlich erweisen kann. Beim Physical Mode von RDM bestehen die unerwünschten Nebeneffekte sogar darin, dass keine Snapshots erstellt werden können. Außerdem sind neue Features in vSphere 5 wie Storage DRS an die Verwendung von VMFS gebunden.

    Dennoch gibt es Gründe, RDM zu verwenden. Ein wesentlicher ist die Größenbeschränkung von VMDK-Dateien. Während das Limit von VMFS in vSphere 5 auf 64 TB hochgeschraubt wurde, blieb es für VMDKs bei 2TB. Wenn eine VM damit nicht auskommt, dann können über RDM bis zu 40TB bereitgestellt werden. Unumgänglich ist RDM im Physical Mode, wenn man Windows-VMs über Microsofts Cluster-Service zusammenspannt. Als Alternative zu den Cluster-Services bietet sich für virtuelle Windows-Server daher die Verwendung von VMware HA an.

    Die Ergebnisse für vSphere lassen sich weitgehend auf Hyper-V übertragen. Ein von Microsoft durchgeführter Vergleichstest ergab, dass Pass-through Disks keine nennenswerte Performance-Vorteile (docx) gegenüber fixed VHDs erzielen. Dafür unterstützen sie keine Snapshots und keine Backups durch den VSS Writer von Hyper-V.

    Auswirkungen von Changed Block Tracking

    Changed Block Tracking ist ein mit vSphere 4 eingeführtes Feature, das Buch über geänderte Blöcke in virtuellen Festplatten führt und Auskunft geben kann über alle Schreibzugriffe seit einem bestimmten Zeitpunkt. Dies ist besonders nützlich für Backup und Replikation, weil es solchen Programmen erheblichen Aufwand erspart und dadurch das Backup-Fenster verkürzt. Hyper-V bietet diese Funktion noch nicht, so dass die Entwickler von Backup-Software anhand von selbst verwalteten Block-Maps herausfinden müssen, welche Informationen seit der letzten Sicherung verändert wurden. Auch hier zeigt sich übrigens eine weitere Einschränkung von Physical RDM, für das kein CBT möglich ist.

    Bei CBT handelt es sich um eine Funktion, die für einzelne VMs ein- oder ausgeschaltet werden kann. Per Voreinstellung ist sie deaktiviert. Offenbar hält sich bei vielen Admins die Ansicht, dass der Overhead von CBT so groß sei, dass man es besser ausgeschaltet lässt. Auch hier sprechen die Testergebnisse eine klare Sprache: bei einer VMDK mit der Maximalgröße von 2TB benötigt ESXi nur 256KB RAM zur Verwaltung der Änderungen und auch nur wenig Rechenzeit, weil pro Schreibvorgang nur 1 Bit in einer Bitmap geändert wird. Faktisch konnten keine Auswirkungen auf die Performance von VMs durch CBT gemessen werden. Wenn die Backup-Software CBT unterstützt, sollte es daher auf jeden Fall eingeschaltet werden.

    Falsch verstandene Resource Pools

    Bei den Resource Pools verhält es sich genau anders herum als bei CBT. Sie werden nicht als Performance-Hemmnisse wahrgenommen, sondern Sloof zufolge oft leichtfertig für die Kategorisierung von VMs verwendet, ohne die Auswirkungen auf die Leistung des Systems in Betracht zu ziehen.

    Resource Pools dienen dazu, einer Gruppe von VMs bestimmte Mengen an CPUs, RAM oder Storage zur gemeinsamen Nutzung zuzuweisen. Bei steigender Arbeitslast rivalisieren die VMs eines Pools zunehmend um die für sie vorgesehene Gesamtmenge an Ressourcen.

    Verwendet man unkonfigurierte Ressource-Pools um VMs logisch zu organisieren, dann übersieht man, dass auch die Default-Werte eine bestimmte Menge (4000) von Anteilen (Shares) an den Gesamtressourcen vergeben. Da normalerweise jeder Resource-Pool eine andere Zahl an VMs enthält, fallen für darin eingebundene virtuelle Maschinen unterschiedlich große Anteile an der Systemleistung ab. Noch schlimmer wird die Situation, wenn man große VMs, die keinem Pool angehören, mit einem solchen zusammen auf einer Inventory-Ebene einsortiert. Dann erhält die einzelne VM überproportional viel Ressourcen zu Lasten des Pools und seiner Mitglieder.

    Wer Resource Pools verwendet, sollte genau berechnen, welche Leistung den einzelnen VMs dann in der Praxis zukommt. Und für die Kategorisierung von VMs sind sie überhaupt nicht vorgesehen, dafür gibt es Container und Ordner.

    LSI Logic versus paravirtualisiertes SCSI

    Legt man unter VMware eine neue VM an, so schlägt der Wizard für den Festplatten-Controller standardmäßig einen virtuellen LSI Logic-Adapter vor. Seit vSphere 4 gibt es alternativ auch einen paravirtualisierten SCSI-Adapter, der vor allem für VMs mit besonders hoher Arbeitslast gedacht ist. Er sollte dem Host weniger Rechenleistung aufbürden als der Standard-SCSI-Adapter.

    Aufgrund seiner ersten Implementierung in vSphere 4, die unter einigen Einschränkungen litt, gab es offenbar einige Zweifel über die Leistungsfähigkeit von paravirtualisiertem SCSI. Diese traten besonders bei VMs mit relativ wenigen I/O-Operationen in Form schlechter Performance zu Tage.

    Die aktuellen Messungen des mittlerweile deutlich verbesserten Treibers zeigen, dass paravirtualisiertes SCSI auch bei "normalen" VMs gleichauf liegt mit LSI Logic und bei "Moster-VMs" besser abschneidet. Gleichzeitig entlastet es auch bei gewöhnlichen Workloads den Host nachweisbar, so dass bei neuen VMs paravirtualisiertes SCSI dem voreingestellten LSI Logic vorzuziehen sei. Eine nachträgliche Anpassung bestehender VMs dürfte in der Regel zu aufwändig sein, weil in diesem Fall ja auch das Gastsystem modifiziert werden muss. Ein solcher Schritt wäre indes für die VMs mit dem höchsten Datendurchsatz sinnvoll.

    Keine Kommentare