Performance-Optimierung für ESXi und vCenter: Im Turbogang
Auch der Betrieb von ESXi-Hosts verursacht Kosten. Parallel erwarten die Nutzer eine angemessene Performance ihrer Workloads. In diesem Artikel beleuchten wir einige Möglichkeiten, um die Leistung von ESXi und vCenter zu verbessern. Viele der Maßnahmen lassen sich sogar vorbeugend umsetzen, bevor es zu Engpässen kommt. Dabei empfiehlt es sich zunächst, die limitierende Ressource zu ermitteln.
Die Performance-Optimierung für ESXi und vCenter beginnt bereits beim Kauf der Hardware. Zwar lassen sich auch nicht auf der Hardware Compatibility List (HCL) befindliche Komponenten in vielen Fällen betreiben, bringen aber unter Umständen nicht vorhersagbare Performancenachteile mit sich und können im Supportfall kritisch sein.
Wichtig ist bei der Hardwarebeschaffung auch, die virtuellen Maschinen (VMs), die Sie darauf betreiben möchten, in ihren Anforderungen einschätzen zu können. So haben Datenbanksysteme eher höhere Anforderungen bezüglich der eingesetzen Speichersysteme, während bei virtuellen Desktops eher hochwertige GPUs zur Gesamtperformance beitragen. In mittleren bis großen Umgebungen ergibt es daher Sinn, mehrere Cluster mit unterschiedlicher Ausstattung für den jeweiligen Anwendungsfall vorzusehen. Eine Liste der ESXi-Hardwarekomponenten finden Sie auf der HCL [1] für die jeweilige ESXi-Version.
In den letzten Jahren wurden mehrere Schwachstellen in modernen CPUs entdeckt, die unter Namen wie Spectre, Meltdown, L1TF und anderen bekannt sind. Es empfiehlt sich folglich, bei Neuanschaffungen möglichst aktuelle CPUs einzusetzen. Weiterhin unterstützen aktuelle Intel CPUs das "Advanced Encryption Standard New Instruction Set" (AES-NI). Arbeiten Sie intensiv mit Verschlüsselung oder setzen Sie sogar VM- oder vSAN-Verschlüsselung ein, sollten Sie darauf achten, dass die eingesetzten CPUs AES-NI unterstützen. Dieses muss natürlich auch im BIOS des ESXi Hosts eingeschaltet sein, was eventuell ein BIOS-Upgrade erfordert.
Wer sich vor den Kosten einer Hardware-Neuanschaffung scheut, sollte bei der Kalkulation auch berücksichtigen, dass neuere Server bei besserer Leistung oftmals geringere Energiekosten verursachen. Angesichts der gestiegenen Strompreise ist dies ein wichtiger Faktor, der die Anschaffungskosten durch verringerte Betriebskosten relativiert.
CPU entlasten
Um CPU-Ressourcen zu entlasten, sollten Sie überdimensionierte VMs vermeiden. Insbesondere in mittleren bis großen Umgebungen kommen die Hardwarespezifikationen virtueller Maschinen häufig von den Applikationsveratwortlichen und beinhalten oft deutlich mehr virtuelle CPUs (vCPUs) als tatsächlich benötigt. Als Grundregel sollten Sie aber nur so viele vCPUs konfigurieren, wie Sie tatsächlich benötigen. VMware Aria Operations (früher vRealize Operations) kann hierbei unterstützen und überdimensionierte VMs proaktiv melden.
Ungenutzte vCPUs verbrauchen virtuelle Timer-Ticks, was zu einem gewissen Overhead führt. Zusätzlich machen viele ungenutzte vCPUs dem Scheduler des ESXi-Hosts das Leben unnötig schwer, was zu den sogenannten Co-Scheduling-Stops führen kann. Mehr dazu lesen Sie im Beitrag "Messdaten für CPU, RAM, Storage und Netz analysieren" auf Seite 152 des IT-Administrator Sonderheft II/2023 - VMware vSphere-8
Ein weiterer Weg, die CPU zu entlasten, besteht darin, grundsätzlich ungenutzte Hardware wie virtuelle optische Laufwerke, Floppylaufwerke, serielle Ports et cetera von der VM zu trennen oder ganz aus der Konfiguration zu entfernen. Windows und teilweise auch andere Gastsysteme neigen dazu, solche virtuellen Hardwarekomponenten von Zeit zu Zeit abzufragen, was unnötige CPU-Last verursacht.
RAM-Speicher freigeben
Wie auch bei den vCPUs sind VMs häufig überdimensioniert, was die Speicherausstattung (RAM) angeht. Bei einem Speicherengpass kann ESXi solchen virtuellen Maschinen ungenutzten Speicher auch wieder wegnehmen. Ein Mechanismus dazu ist das sogenannte "Ballooning", wobei ESXi mit einem Treiber innerhalb der VM spricht. Dieser fordert vom Gastsystem bevorzugt ungenutzten Speicher an, der dann im ESXi wieder zur Verfügung steht. Hierzu sind allerdings zwei Voraussetzungen zu erfüllen:
1. Der Balloon-Treiber muss im Gastsystem installiert sein. Er ist Bestandteil der VMware Tools, die grundsätzlich in jeder virtuellen Maschine installiert sein sollten.
2. Der Speicher der VM darf nicht garantiert (reserviert) sein.
Überdimensionierte VMs mit einer hohen Speicherreservierung können keinen Speicher durch Balloning abgeben. Daher kann das Reduzieren dieser Reservierung bei potenziell überdimensionierten VMs deutlich helfen, Speichernot ohne wesentlichen Performanceverlust zu beseitigen. Andererseits leidet natürlich die Leistung von VMs, die ihren Speicher auslasten, wenn sie von Ballooning betroffen sind (zum Beispiel Datenbanken). Diese sollten dann bei drohender Speichernot durchaus eine großzügige Reservierung erhalten.
I/O-Last verteilen
Bei blockbasiertem Storage lässt sich die I/O-Last mit verschiedenen Methoden über die verfügbaren Pfade verteilen (Multipathing). Folgende Algorithmen stehen hierbei zur Verfügung:
-Most Recently Used: Für jede logische Festplatte (LUN) wird einer der verfügbaren Pfade gewählt. Fällt dieser aus, wählt ESXi einen beliebigen anderen. Steht der ausgefallene Pfad wieder zur Verfügung, kommt er nicht wieder zum Einsatz, es sei denn, er ist der einzig mögliche. Somit ist dieser Algorithmus nicht wirklich gut geeignet, die Last über alle verfügbaren Pfade zu verteilen. Einen Vorteil bietet er allerdings: Er ist mit jedem Storage-System kompatibel.
-Fixed: Der Name ist hier irreführend, da Nutzer zum Teil annehmen, der Pfad sei hier fest vorgegeben und es bestehe keine Redundanz. Sie können für jede LUN einen bevorzugten Pfad angeben. Fällt der bevorzugte Pfad temporär aus, wird ein anderer Pfad gewählt, bis der bevorzugte wieder zur Verfügung steht. Zwar haben Sie für jede einzelne LUN nur maximal die Geschwindigkeit eines einzelnen Pfades verfügbar, bei ausreichender Anzahl an LUNs lassen sich aber trotzdem alle Pfade einigermaßen gleichmäßig auslasten. Besteht ein Ungleichgewicht in der Auslastung, können Sie einzelne LUNs auch im laufenden Betrieb auf einen anderen bevorzugten Pfad verlegen.
-Round Robin: Dies ist, was die Lastverteilung angeht, der eleganteste Algorithmus. Die Last wird für jede einzelne LUN über alle verfügbaren Pfade verteilt. Als Standardwert wechselt ESXi nach jeweils 1000 I/Os den Pfad der jeweiligen LUN. Ob hier der Wert von 1000 optimal ist, müssen Sie der Dokumentation des Storage-Herstellers entnehmen. Die Angaben reichen von "egal" bis zu "Pfadwechsel nach jedem I/O". Als Beispiel zeigt Bild 1 die nötigen Kommandos, um alle LUNs eines bestimmten Herstellers auf "Round Robin" mit dem vom Anbieter empfohlenen Wert für Pfadwechsel nach jeweils zehn I/Os umzustellen.
Während "Most Recently Used" mit jedem Storage-System kompatibel ist, müssen Sie bei Fixed und Round Robin zwingend in der Dokumentation des Speicherherstellers überprüfen, ob das jeweilige Storage-System diese unterstützt. Hierbei sind unbedingt eventuelle Angaben zu benötigten Softwareständen des Systems zu beachten. Die Multipathing-Einstellungen den jeweiligen Herstelleranforderungen anzupassen, kann deutliche Vorteile bringen.
Bei über NFS angesprochenen Storage-Systemen findet die Lastverteilung auf der Netzwerkebene statt. Ein einzelner VMkernel-Port, der bevorzugt mit dem NFS-Storage-System im selben Netz (VLAN) liegt, ist hier ausreichend. Die für diesen VMkernel Port verwendete Portgruppe stellen Sie auf "IP Hash Load Balancing", und den Speicher versehen Sie mit mindestens so vielen IP-Adressen, wie auf den ESXi-Netzwerkkarten für den NFS-Zugriff zum Einsatz kommen. Dies erfordert allerdings eine Link Aggregation Group (LAG) – statisch oder mit LACP (Link Aggregation Control Protocol) – auf den physichen Switches, an die ESXi angeschlossen ist.
Aus Redundanzgründen sollten Sie außerdem die Netzwerkkarten der ESXi-Hosts auf mindestens zwei physische Switches verteilen. Hierzu ist es nötig, Switches einzusetzen, die LAGs auch gehäuseübergreifend unterstützen (Multi Chassis LAG, kurz MC-LAG beziehungsweise virtual Portchannel, kurz vPC – je nach Hersteller).
Geschwindigkeit mit virtuellen Netzwerkkarten erhöhen
Der Weg eines Pakets vom Gastbetriebssystem bis zur physischen Netzwerkkarte des ESXi-Hosts ist deutlich komplexer als bei einem physischen System. Die Übergabe zwischen dem Treiber der virtuellen Netzwerkkarte (vNIC Driver) und dem virtuellen Gerät im ESXi-Host (vNIC Device) ist hier besonders kritisch. Der effizienteste und gleichzeitig einfachste Weg, diese zu optimieren, ist der Einsatz virtueller Netzwerkkarten vom Typ "vmxnet3". Dabei erfolgt die Übergabe über einen sowohl vom Hypervisor als auch von der VM ansprechbaren Ring-Puffer im RAM.
Damit hängt die Geschwindigkeit nur noch von der Performance der eingesetzen Speicherbausteine ab. Auch wenn eine virtuelle vmxnet3-Karte im Gastsystem als 10 GBit/s-Karte zu sehen ist, sind Geschwindigkeiten von 25 GBit/s und mehr von beziehungsweise zu einer einzelnen VM möglich.
Jedes Netzwerkpaket muss den kompletten in Bild 2 dargestellten Weg durchlaufen. Für virtuelle Maschinen mit sehr hohem Durchsatz liegt es auf der Hand, dass Sie die Performance durch das Verringern der zu verarbeitenden Pakete steigern können. Dies lässt sich ebenfalls sehr einfach realisieren, indem Sie die Maximum Transmission Unit (MTU), also die maximale Größe der Nutzdaten in einem einzelnen Ethernet-Frame, erhöhen. Diese Maßnahme vergrößert nicht nur den potenziellen Durchsatz einer VM, sondern entlastet auch die Host-CPUs. Zu beachten ist allerdings, dass Sie die MTU bei einer Ende-zu-Ende-Verbindung erhöhen müssen, physische Netzwerkelemente eingeschlossen.
Auch für VMs mit mehreren virtuellen Netzwerkkarten kommt per Standard nur ein einzelner Thread für das Senden von Netzwerkpaketen zum Einsatz. Um bei VMs mit sehr hoher Senderate diese zu optimieren, können Sie einen oder sogar mehrere dedizierte Threads pro Netzwerkkarte verwenden. Dies lässt sich sowohl für den gesamten ESXi-Host als auch für einzelne VMs konfigurieren.
Auf dem Host ist der Advanced-Parameter "Net.NetVMTxType" beziehungsweise bei einzelnen VMs der Parameter "Ethernet<X>.ctxPerDev" (das "<X>"steht für die jeweilige Nummer der Netzwerkkarte) einzustellen. Der Standardwert "2" bedeutet, dass es einen Thread pro VM gibt. Mit dem Wert "1" erhalten Sie einen Thread pro vNIC. Nähere Informationen finden Sie unter [2].
Der Transport von zu sendenden Paketen von der VM zum virtuellen Switch sowie vom virtuellen Switch zur physischen Netzwerkkarte erfolgt normalerweise in einem einzelnen Thread. Die Geschwindigkeit beim Senden lässt sich deutlich erhöhen, wenn Sie hierzu zwei Threads verwenden. Dies schalten Sie auf dem ESXi-Host durch folgendes Kommando ein:
vsish –e set /net/pNics/vmnic<X>/sched/txMode 1
wobei das "<X>" hinter vmnic wieder für die Nummer der physischen Netzwerkkarte steht. Bei Optimierungen, die dazu führen, dass zusätzliche Threads auf den CPUs laufen, sollten Sie allerdings beachten, dass diese durchaus zu erhöhter CPU-Last führen können.
vCenter-Leistung verbessern
Wollen Sie die Performance von vCenter erhöhen, untersuchen Sie im ersten Schritt, ob nicht die Clientperformance oder ein Netzwerkengpass zwischen Client und vCenter die vermeintlichen Performanceprobleme verursacht.
Die auf Basis der VMware eigenen Linux-Plattform "Photon OS" ausgelieferte vCenter-Server-Appliance erfüllt in vielen Fällen ohne weitere Modifikation die Anforderungen bezüglich Performance. Selbstverständlich ist dafür zu sorgen, dass vCenter über ausreichende CPU-und RAM-Ressourcen verfügt. Diese lassen sich bei Bedarf auch erhöhen.
Besonderes Augenmerk gilt der vCenter-Datenbank, da die Gesamtleistung von vCenter sehr stark von der Datenbank abhängt. vCenter sammelt unter anderem auch Performance-Statistiken. Wie detailliert dies erfolgt, lässt sich von Level 1 bis 4 konfigurieren. In der Regel reicht die kleinste Detailtiefe (Level 1) völlig aus.
Erhöhen Sie die Detailtiefe, müssen Sie auf jeden Fall die Latenzen der für die Datenbank verwendeten virtuellen Festplatte (Hard disk 6) im Auge behalten. Steigen die Latenzen, empfiehlt sich, zumindest die Datenbank auf ein Storage-System mit besserer Performance zu verschieben.Sind Abfragen der Datenbank langsam, kann es auch helfen, in der vCenter-Datenback das Kommando VA-CUUM ANALYZE; auszuführen. Wie Sie sich mit der vCenter-Datenbank verbinden, beschreibt [3].
Übrigens sollte das System die CPU-Last von vCenter 70 Prozent prinzipiell nicht überschreiten. Ist dies doch der Fall, gibt es zwei typische Quellen dieser Last:
-Der vCenter-Dienst selbst (vpxd): Hier hilft es typischerweise, für vCenter mehr vCPUs zu konfigurieren.
-Java Dienste: Hier kann es hilfreich sein, den Java memory heap zu vergrößern [4].
Welche Dienste wie stark zur CPU-Last beitragen, finden Sie auf der vCenter-Kommandozeile mit dem Kommando vimtop heraus.
Fazit
In diesem Beitrag haben wir einige Möglichkeiten aufgezeigt, um die Performance einer vSphere-8-Umgebung zu optimieren. Das Dokument "vSphere 7.0 Performance Best Practices" [5] liefert noch weiterführende Informationen, die ebenso für Version 8 gültig sind. Das Training "VMware vSphere: Operate, Scale and Secure" [6] vermittelt ebenfalls weitere Einblicke in die Thematik.
(jm/dr)
Link-Codes
[1] ESXi-Hardwarekomponenten
[2] Optimierung der Sendeleistung von vNIC
[3] Mit vCenter-Datenbank verbinden
[4] Java memory heap vergrößern
[5] vSphere 7.0 Performance Best Practices
[6] VMware vSphere: Operate, Scale and Secure
Ein Artikel aus dem IT-Administrator Sonderheft II/2023 - VMware vSphere-8 Seite 149