Stor IT Back - Ihr Speicherspezialist

Stor IT Back

Server-Virtualisierung - Performance V1.6 (c) Stor IT Back 2023


Grundlagen Performance Server-Virtualisierung, Analyse, Optimierung und Tuning

Schon bei reinen physikalischen Systemen ohne jegliche Virtualisierung ist eine Performance Vorhersage recht schwierig. Es spielen einige Faktoren bei der Performance-Betrachtung eine wichtige Rolle, viele sind nur sehr schwer zu erfassen.

Ein einfaches Beispiel: Eine Datenbank zeigt eine sehr schlechte Performance, die User beschweren sich über langsame Antwortzeiten, die Applikationen sind wegen der schlechten Geschwindigkeit nur schwer zu bedienen. Woran kann dies liegen? Allgemein am Server, am Netzwerk, am Client oder an der Datenbank oder Applikation. Nehmen wir in dieser Betrachtung mal die Datenbank und die Applikation heraus (obwohl dort erfahrungsgemäß die größten Probleme liegen können), auch für den Client und das Netzwerk schließen wir mal den Flaschenhals aus. Dann haben wir noch den Server, dieser Besteht aus CPU, Hauptspeicher und Festplattenspeicher.

Die Dimensionierung von CPU und Hauptspeicher sind bei der Virtualisierung sehr wichtig. Ein Hauptvorteil der Server-Virtualisierung ist ja gerade die bessere Ausnutzung der modernen CPUs. Aber was ist, wenn die CPU jetzt überlastet ist? Die Anwendung wird langsamer als sie sein sollte. Bei einer richtigen Überwachung durch Schwellwert-Alarme in der Virtualisierungsschicht ist dieses Problem leicht zu erkennen. Auch bei der Auslastung des Hauptspeichers bietet die Virtualisierung meist einfache und effektive Überwachungsmöglichkeiten. Gleiches muss dann auch entsprechend in den virtuellen Maschinen überwacht werden. Ist die Dimensionierung von Hauptspeicher- und CPU-Ressource für die VM angemessen? Oder muss dort angepasst werden?

Jetzt bleibt bei dieser Betrachtung nur noch der Speicherplatz übrig. Auch dort bieten viele Virtualisierungsprodukte umfangreiche Analysewerkzeuge an. So kann z.B. die I/O Belastung einer Platte gemessen und grafisch ausgewertet werden, ebenso der Durchsatz und die I/O-Wartezeit. Wird dort ein Engpass angezeigt, so wird es aber schwierig dies zu verbessern. Bei fehlendem Hauptspeicher ist es einfach: Aufrüstung des RAMs in der physikalischen Maschine oder die Verlagerung von virtuellen Maschinen auf eine andere Hardware. Aber was kann bei Performance-Problemen im Storage-Backend geändert werden?

Schauen wir uns die Storage-Möglichkeiten in der virtuellen Welt einmal etwas genauer an. Die VM (virtuelle Maschine) nutzt einen Treiber, um die Daten an den virtuellen Hardware-Adapter der Virtualisierung weiterzuleiten. Dieser virtuelle Hardware-Adapter leitet es dann an das Filesystem der Virtualisierung (beim VMware ist es das VMFS, bei Hyper-V zum Beispiel NTFS) weiter. Vom Filesystem geht es dann über den Treiber zum physikalischen Speicheradapter weiter. Dieser ist über das Speichernetzwerk an das RAID-System angeschlossen. Auch beim Speichernetzwerk (zum Beispiel Fibre Channel oder iSCSI) gibt es noch Optimierungsmöglichkeiten. Dann im externen RAID-System ist ein Cache vorhanden und über einen RAID-Level geht es auf die Platten. Je nach RAID-Level und Möglichkeiten des RAID-Controllers mit unterschiedlichen Stipe-Sizes. Und bei den Festplatten ist auch noch eine große Auswahl (SAS-Platten oder SATA, oder gar SSDs) vorhanden, mit unterschiedlichen Vor- und Nachteilen. In dieser Kette sind viele Faktoren vorhanden, die zum größten Teil auch noch untereinander abhängig sind.

Nachfolgenden finden Sie zwei Beispiele für das Performance Tuning im Storage-Bereich. Dies gilt nicht nur alleine für die Virtualisierung, auch bei großen und performanten Anwendungen auf einem physikalischen Server kann ein Tuning einiges an Verbesserungen bringen.



 
 

Blöcke bei der Server-Virtualisierung

Viele denken jetzt: Das ist aber Trivial, was soll ich schon bei den Blöcken von Filesystem und RAID machen? Da nehme ich immer die Default-Werte und gut ist ... Aber warum nehmen wirklich so viele Administratoren die Default-Werte? Wenn man etwas ändern oder anpassen möchte, muss man auch wissen warum man etwas ändern muss und welches die richtige Änderung ist (kleiner oder größer oder alles gleich). Und genau in diesem Punkt wird es sehr schwierig. Aber schauen wir uns erst mal die Grundlagen an. In der Übertragungskette gibt es sehr viele verschiedene Blöcke in den einzelnen Schichten. Vom Betriebssystem der VM wird ein bestimmter Block im NTFS angesprochen, der liegt in einem oder mehreren Blöcken im Filesystem der Virtualisierungsschicht. Diese Blöcke liegen wiederum auf einem RAID-System und werden über ein Netzwerk (FC oder iSCSI), auch in Blöcken, transportiert.

Schauen wir uns mal ein ungünstiges Beispiel an:

Blöcke in virtualisierten Umgebungen nicht optimiert

Die Blöcke starten immer am Anfang (so ist der Default) und es werden auch die Default Werte bei den Blöcken genutzt. Greift in unserem ersten Beispiel jetzt in der VM eine Anwendung auf einen einzelnen Block im NTFS zu, so müssen schon 3 Blöcke aus dem RAID-Set gelesen werden. Haben wir beispielsweise eine Stripe-Size von 256 kB eingestellt, so müssen wir trotzdem 768 kB lesen, also das Dreifache. Sind wir in diesem Fall am Limit des RAID-Controllers oder des Übertragungsmediums angekommen, so könnte durch die Optimierung der 3fache Durchsatz für die VM erzielt werden.

Jetzt ein wesentlich besser optimiertes Beispiel. Es wird pro benötigten Block in der VM am wenigsten Daten übertragen, die Startpunkte der jeweiligen Systeme sind aufeinander abgestimmt worden:

Performance Tuning Blöcke in virtualisierten Umgebungen optimiert

Benötigt jetzt eine Anwendung in der VM einen Block, so muss genau ein Block aus dem VMFS und ein entsprechender Block aus dem RAID gelesen werden. Wichtig ist bei dieser Optimierung, dass der Startpunkt der Blöcke für VMFS und NTFS jeweils soweit nach innen verschoben wird, das die Grenzen übereinander liegen. Wird dies nicht gemacht, so müssen dann zwei VMFS-Blöcke und mindestens 3 Stripe-Blöcke gelesen werden.

Es sind jetzt verschiedene Varianten denkbar. Wenn zum Beispiel immer viele NTFS Blöcke hintereinander gelesen werden müssen (sequentielle Daten), dann können auch mehr NTFS-Blöcke in einem VMFS-Block liegen, bzw. mehrere VMFS-Blöcke in einem Stripe. Da wird es aber schon wieder schwieriger. Sind jetzt ein Fileserver mit großen Daten und ein Datenbankserver mit kleiner Blocksize auf einem Storage-System (bzw. in einer Virtualisierung) untergebracht, so behindern sich die Optimierungen gegenseitig. Da bleibt eigentlich nur noch ein individueller Test, welche Optimierung bzw. welcher Kompromiss für alle Systeme am besten ist.

Lange Rede: Was ist jetzt in der Praxis? Bei VMware (ab der Version ESXi 5.0) ist es normalerweise so, dass beim Anlegen des VMFS Filesystems oder der VMDK Datei über die GUI, diese schon automatisch ausrichtet werden. Es sollte also nur in Ausnahmefällen die CLI genutzt werden. Aber auch wenn die VMFS Volumes schon mit Versionen vor ESXI 5.0 angelegt wurden, kann ein Neuanlegen (zum Beispiel bei einer Migration) die Performance verbessern. Dazu müssen aber die Daten vorher verschoben werden.



 
 

iSCSI Protokoll Tuning

Besteht das Storage-Netzwerk in einer virtuellen Umgebung aus iSCSI-Komponenten, so sind vielfältige Tuning-Möglichkeiten vorhanden. Auch hier muss erst einmal analysiert werden, wo denn das Nadelöhr ist. Ein einfaches Beispiel: Die CPU in der Hardware ist sehr stark belastet und die VMs verursachen nicht die gesamte Last. Dies könnte durchaus vom Software-iSCSI-Initiator kommen. Bei der iSCSI-Software-Lösung wird die gesamte Verpackung und Entpackung der iSCSI Pakete durch die CPU erledigt. Also je mehr I/O, desto mehr CPU Belastung. Eine einfache Abhilfe sind Netzwerkkarten mit TCP Offload Engine (TOE) oder iSCSI HBAs. Auf den Karten sind eigene Prozessoren enthalten, die die Verpackung der Pakete übernehmen.

Ist aber die Datenübertragung bei iSCSI an sich zu langsam, so kann auch dies noch verbessert werden. Im iSCSI (und TCP) gibt es einige Einstellmöglichkeiten, die die Performance beeinflussen. Leider gibt es keine allgemeingültigen Parameter für optionale Ergebnisse. Als Beispiel haben wir einen VMware ESX 4 Server mit einem Open-E iSCSI System als Storage betrachtet. VMware, wie auch Open-E geben einige Parameter an, die vom Default geändert werden sollen:

MaxRecvDataSegmentLength=262144
MaxBurstLength=16776192
Maxxmitdatasegment=262144
Maxoutstandingr2t=8
InitialR2T=No
ImmediateData=Yes

Diese Werte lassen sich im ESX Server über die erweiterten Einstellungen der iSCSI Ports bzw. im Storage-System über das jeweilige Target einstellen. Wie schon gesagt, sind dies nicht unbedingt für jede Umgebung die idealen Werte. Evtl. muss da individuell getestet und verglichen werden. Auch das obige Thema mit den Blöcken spielt in dieses Thema rein und vereinfacht es nicht gerade. Sind die optionalen Blöcke im Filesystem und auf dem RAID ein klein wenig zu groß für die iSCSI Blöcke, so bringt die Optimierung im Filesystem unter Umständen überhaupt nichts.



 
 

Performance-Analyse mit esxtop bei VMware vSphere

Werden in einer virtuellen Umgebung Performanceprobleme festgestellt, so ist die Analyse erst mal recht undurchsichtig. Wo liegt jetzt das eigentliche Problem? Nehmen wir einmal VMware vSphere als Beispiel. Wenn dort die Antwortzeiten von Anwendungen und Applikationen schlecht sind, dann gibt es viele Analysemöglichkeiten. Der zentrale Ansatz ist auf jeden Fall der ESXi. Und der bringt auch einige Möglichkeiten zur Fehlersuche mit. Dies ist einmal die grafische Aufbereitung der Performancedaten. Hier lassen sich schon viele Probleme erkennen. Ist die CPU Auslastung über einen langen Zeitraum recht hoch für den Server, dann kann auf die einzelnen virtuellen Maschinen geschaut werden, welche zu viel CPU verbraucht. Hier kann man auch recht schnell entscheiden ob der CPU Verbrauch einer VM richtig ist, oder ob schon dort der Fehler vorliegt. Ähnlich kann auch mit dem RAM verfahren werden. Dort ist die Lösung meist recht einfach, wenn an sich keine Störung vorliegt, es wird einfach mehr RAM eingebaut, oder eine VM wird verschoben.
Problematischer wird die Fehlersuche meist bei den Datenspeichern. Auch hier bietet VMware viele grafische Auswertung an, jedoch sind diese immer zeitlich gemittelt. Kleine Peaks werden meist nicht erkannt und komplexe Zusammenhänge werden grafisch meist wegen Unübersichtlichkeit nicht erkannt. Hier hilft das Texttool esxtop direkt auf der Console des ESXi. Es ist dem üblichen top von Linux nachempfunden und zeigt detailliert die Zustände im ESXi an. Neben CPU und RAM werden die Devices und Units ausgewertet, aber auch die virtuellen Maschinen. Durch eine einstellbare Aktualisierungsrate können auch kleine Peaks noch erkannt werden.

Beispiel esxtop für Devices:

6:51:15pm up 13 days 1:41, 326 worlds, 3 VMs, 4 vCPUs; CPU load average: 0.11, 0.14, 0.14

ADAPTRPATHNPTHCMDS/sREADS/sWRITES/sMBREAD/sMBWRTN/sDAVG/cmdKAVG/cmdGAVG/cmdQAVG/cmd
vmhba0-00.000.000.000.000.000.000.000.000.00
vmhba1-21.000.001.000.000.000.760.010.770.00
vmhba32-00.000.000.000.000.000.000.000.000.00
vmhba33-00.000.000.000.000.000.000.000.000.00
vmhba34-00.000.000.000.000.000.000.000.000.00
vmhba35-10.000.000.000.000.000.000.000.000.00
vmhba36-12.810.002.810.000.011.530.011.540.00

Hier können Basisdaten wie zum Beispiel die Reads oder Writes pro Sekunde oder die Übertragungsrate getrennt nach Read und Write ermittelt werden. Bei diesen Werten gibt es kein "Gut" oder "Schlecht", eher ein "sinnvoll" oder ein "nicht nachvollziehbar". Es kommt immer auf die Umgebung an, große Datenbanken können auch sehr viele Lese- oder Schreiboperationen verursachen, ohne dass es eine Störung ist. Diese Werte müssen immer von Fall zu Fall abgeglichen werden. Interessant sind mehr die DAVG/cmd und die KAVG/cmd, beide Werte zeigen die Antwortzeit. Liegt zum Beispiel die DAVG über 25, so wird das meist als kritisch eingestuft. Die KAVG Werte über 3 deuten auf Probleme im Kernel hin, zum Beispiel eine fehlerhafte Failover Policy oder eine falsche Queue Depth.
Insgesamt muss das System und auch die ganze Umgebung genau analysiert werden, esxtop kann aber als erste Anlaufstelle zur Ermittlung der Fehlerursache genutzt werden.



 
 

Workshops und Schulungen zum Thema Performance

Workshop Cloud Technologien
Workshop Cloud Technologien / Cloud Computing
Cloud Definition / Begriffe
Technischer Aufbau
Vorteile von Cloud Technologien
Was ist auf jeden Fall zu beachten?
Server-Virtualisierung - ein herstellerunabhängiger Überblick
Server-Virtualisierung - ein herstellerunabhängiger Überblick
Grundlagen der Server-Virtualisierung
Betrieb und Überwachung
VMware, Hyper-V, XEN und KVM
Praxisworkshop Server-Virtualisierung
Praxisworkshop Server-Virtualisierung
Aufbau einer Server-Virtualisierung
Hochverfügbarkeit und Sicherheit
Backup-Lösung in der Praxis
Vergleich VMware, Hyper-V, XEN und KVM
 
 

Für Virtualisierungsprojekte bieten wir die passenden Storage-Lösungen an, setzen Sie sich mit uns in Verbindung. Natürlich können Sie auch komplette Lösungen von uns bekommen. Egal zu welcher Virtualisierungssoftware, wir finden ein für Sie passendes Storagesystem.



 
 

Angebote der Stor IT Back zum Thema Server Virtualisierung / Performance

Proxmox VE auf Lenovo Server
Proxmox VE Virtualisierung
QEMU/KVM und LXC (Linux Containers)

auf Lenovo Server
Single Server bis HA-Umgebung
ab 4.155,00 Euro
zzgl. MwSt.
Angebot VMware vSAN 7 HPE DL360

VMware Hyper Converged Infrastructure
vSAN und HPE DL 360 Server
2 HPE DL360 Gen10 Server für VMware ESXi 7
und vSAN 7
Preis
auf Anfrage
Angebot VMware ESXi Server Virtualisierung FC

VMware ESX Fibre Channel Paket (Essentials Plus)
2 x Fujitsu RX2520 M5 für VMware ESXi
und Dell EMC Unity XT 380 FC
Preis
auf Anfrage
 
 
Zurück zur Übersicht
Server Virtualisierung Performance
Übersicht der Angebote
Kontakt zur Stor IT Back
Suche auf der Webseite