Schon bei reinen physikalischen Systemen ohne jegliche Virtualisierung ist
eine Performance-Vorhersage recht schwierig. Es spielen viele 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 schlechte 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 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 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 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, FC, SCSI oder SATA) 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.
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 erstmal 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:
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:
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. Diese Optimierung führen die Systeme nicht automatisch durch, können sie auch nicht, da sie die jeweils unterliegende Schicht ja nicht kennen. Die Informationen müssen jeweils individuell von System zu System zusammengetragen werden und eingestellt 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.
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.
Zum Thema Server-Virtualisierung bieten wir verschiedene Workshops an. Einmal einen regelmäßig stattfindenden Einsteiger-Kurs mit Grundlagen und Lösungsvorschlägen und einen optional Workshop mit einem großen Praxisteil, die Virtualisierung zum Anfassen.
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.
 Übersicht |
 nach oben |
 Angebote |
 Kontakt |
 Suche |
 Navigation |