vSphere - Festplatten Performance der VMs prüfen ?

[andreas222]

Hallo zusammen,

wir haben ein FC-SAN von dem ich mehrere LUNs zugewiesen bekommen habe.
Wie ich erfahren habe sind in den LUNs wohl nur SATA-HDs verschaltet.
Der Zugriff erfolgt über 2GB FC-Swichte.

Einer meiner Kunden hat nun innerhalb seiner Gast VM mehrere Benchmarks laufen lassen u. meint die Platten-Performance waäre nicht so gut.

Welche Informationen sollte ich zum Thema "Festplatten Performance" kennen ?
Welche Parameter sollte ich prüfen ?

Merci für Tips
Gruesse Andreas

[Saturnous]

esxtop währed der Kunde sein benchmark laufen lässt und vscsistats (um latenz verschiedener Blockgrössen mitzuschneiden - ggf maximale Blockgrösse runtersetzen).

Ein supporter würde "vm-support -s" während des Tests laufen lassen und das dann auf seinem ESX (geht auch ne VM) entpacken und mit "esxtop -R [Verzeichnis]" aufrufen und sich die Sache anschauen.

[bla!zilla]

Also grundsätzlich ist die Aussage, dass die Plattenperformance nicht so gut wäre, reichlich subjektiv. Habt ihr Probleme mit den Applikationen? Wisst ihr was für ein Storage dahintersteht? Teilt ihr euch die Platten mit anderen logischen Laufwerken? Wieviele VMs pro VMFS? Wieviele ESXer pro VMFS?

[f12345]

Wir hatten genau das selbe Problem. Wie kann ich die Performance messen?

Auslöser war das wir auf eine SAN Virtualisierung setzen und die vm´s immer langsamer wurden. Ich habe wirklich tagelang rumprobiert wie man es "fassen" kann. Anfangs in einer vm mittels IOmeter. (War nicht so dolle)

Jetzt lege ich eine Datei über die Service Konsole auf den LUN´s an mittels folgendem Befehl

time /usr/sbin/vmkfstools -c 10G -d eagerzeroedthick perf.vmdk

Über den Output time kann man den Durchsatz ermitteln.
Wichtig ist auch über esxtop sich die Latenzwerte anzusehen.

Folgende Referenzwerte habe ich ermittelt:

Lokaler Strorage ca. 120MB/s
SCSI HP MSA ca. 150MB/s
SAN Storage ca. 165MB/s
Mirror Storage über SAN Virtualierung ca 20-40MB/s

Dieser Test läuft bei mir stündlich. Die Daten werden in einer LOG Datei abgelegt. Somit kann man Tendenzen jetzt zuverlässig erkennen.

cu,
Michael

[andreas222]

Hallo zusammen,

sorry komme jetzt erst wieder zum Thema.

OK auf dem besagten ESX-Host läuft bisher nur die betroffene Gast-VM.
Die Gast-VM selbst liegt auf einem SAN-Storage, Zugriff eben über 2 GB FC-Switche.

Die Applikation ist ein Open Suse mit LAMP System bzw. ein Webserver laut Kunde.
Applikation ist soweit in Ordnung.

Storage ist ein SUN ST6140. Wenn ich nicht irre wird liegt eine SUN ZFS drunter.
Vermutlich sind noch andere Leute mit auf dem Storage wie die Aufteilung ist muss ich noch rausbekommen. Welcher Parameter sollte ich erfragen ?

Aktuell haben wir/ich 4 ESX Host in einem Cluster mit 14VMs (Windows u. Linux Gäste) am Start.
Insgesamt habe ich 4 LUN zugewiesen bekommen 2 x 1TB u. 2 x 500GB.

Ähm doofe Frage das VMFS ist doch für alle ESX-Hosts dasselbe richtig ?

Könnt ihr mir bitte den Befehl etwas genauer erklären.... login direkt auf den ESX Host, Befehl ausführen..es wird eine 10GB datei angelegt u. die Zeit gemessen, richtig ?

> time /usr/sbin/vmkfstools -c 10G -d eagerzeroedthick perf.vmdk


Merci für Tips
Gruesse Andreas

[f12345]

Ja, genau!
Es wird eine Datei angelegt mit bsp. 10GB
Über die Laufzeit (time) kann man schön den Durchsatz ausrechen.
In jedem Fall diesen Befehl verwenden. nicht DD verwenden.

Welche Laufzeit hast du???

cu,
Michael

[andreas222]

Hallo,

also hab nun folgendes gemacht.
Auf der LUN auf welcher die betroffene VM liegt das Komando ausgeführt, richtig ?!
- time /usr/sbin/vmkfstools -c 10G -d eagerzeroedthick perf.vmdk

Ergebnis:
Creating disk 'perf.vmdk' and zeroing it out...
Create: 100% done.

real 6m30.147s
user 0m0.000s
sys 0m0.860s

Wenn ich das nun richtig ausgerechnet habe...
Datenübertragungsrate = 10Gbyte/390s = ca. 25,64 MB/s

Ist das richtig bzw. dieser Wert ist doch etwas lahm ?

Gruesse & Merci
Andreas

[andreas222]

Hi,

noch als Vergleich Zeitmessung direkt auf ESX-Host-HD

# time /usr/sbin/vmkfstools -c 10G -d eagerzeroedthick perf.vmdk

Creating disk 'perf.vmdk' and zeroing it out...
Create: 100% done.

real 2m5.367s
user 0m0.000s
sys 0m0.910s

10000 MByte/ 125s = ca. 80 Mbyte/s

Das ist doch eigentlich normal, richtig ?

Gruesse & Merci
Andreas

[f12345]

Ja, die Zahl kommt hin.
1GB=1024MB (Kleiner Rundungsfehler) ist aber hier nicht wichtig.

Ich denke du hast die Datei auf ein VMFS Volume in deinem Storage angelegt.
Teste mal ein anders VMFS Volume.
Der Wert ist leider grottig schlecht.

Wir haben intern 120MB/s Durchsatz Latenz <20ms festgelegt.
Wenn diese Werte unterschritten werden, gibt es einen Alert.

cu,
MiK

[irix]

Bei lokalem Storage mit 10K SAS RAID 10:

Code: Alles auswählen

real    0m46.215s
user    0m0.000s
sys     0m0.760s

10240 MByte/ 46s = ca.222 MByte/s

Auf einem Open-E iSCSI SAN auf einem RAID5 mit SATA

Code: Alles auswählen

real    2m13.015s
user    0m0.010s
sys     0m0.680s
10240 MByte/133 = 77MByte/s


Auf einem Equallogic RAID50 SATA

Code: Alles auswählen

real    1m53.729s
user    0m0.000s
sys     0m0.070s
10240 MByte/113 = 90MByte/s


Das ganze im lfd. Betrieb.

Gruss
Joerg

[andreas222]

Hallo zusammen,


dachte das nun mit 1000 statt mit 1024 gerechnet wird...ähm dachte das wurde mal gleichgezogen...aber das ist ja vorerst wurscht.

Auf LUN2:

real 4m51.725s
user 0m0.000s
sys 0m0.910s
[root@legolas temp]#

10000 Mbyte / 291s = 34,36


Auf LUN3
real 4m52.512s
user 0m0.000s
sys 0m0.900s

10000Mbyte / 292s = 34,24 Mbyte/s

also alles recht bescheiden.
Nun die Frage... wo muss man nun ansetzen ?

werde mit den storage leuten mal reden, welche Fehler kann man den im storage design machen ?

Die FC Verkabelung meinerseits ist die klassische Überkreuz-Verkabelung je 2 pfade zu den RAIDs.

Gruesse merci für Tips.
andreas

[parkesel]

Das ist ja super...

Das ist ja genau was ich auch brauche.

Ich habe ja das Problem wenn ich intern vom Gast aus von "c" nach "C:\temp ein 1gb file kopiere zeigt mir einen kopiersoft 10MB/s an auf scsi u320 2x36gb 15k raid 0


probleme ansich habe ich nicht mich ärgert nur der Speed.

[eini]

@parkesel

Musst ja schon Mal 2 rechnen, was´n das für ein System? Sprich lokaler Server Storage etc.

Läuft ggf. noch was anderes nebenbei? Hat der Server Schreibcache enabled?

@all

Das Thema ist recht interessant mit diesem Script welches eine Datei schreibt und ausnullt. Aber das sagt nur was darüber aus welche Performance das System beim Sequentiellen schreiben hat. Aber man hat ja fast immer ein Problem mit den I/O´s und die kommen in der Regel parallel. Von daher sollte aus meiner Sicht mit IO Meter gemessen werden und zwar mit einem realistischem "Real Life" Szenario.

[parkesel]

Habe nun auch den speedtest gemacht:

2x scsi 76 10k raid 0


real 5m42.167s
user 0m0.000s
sys 0m0.930s

10240 MByte\342 =29



real 3m40.179s
user 0m0.000s
sys 0m1.000s


1x sata 200gb

10240 Mbyte\220 = 46


1x scsi 36gb 15k raid0

real 5m25.838s
user 0m0.000s
sys 0m0.920s

10240 Mbyte\325 = 31

Man das gibs ja nicht..... Habe bereits mit verschiedenen Controllern getestet zurzeit hängt ein Smartarray 642 ohne cache.

Die Sata paltte ist schneller als die scsi

Danke Leute

[andreas222]

hi,

wie testet man mit IO-Meter...ist das Teil kostenlos ?

Welche Erkenntnisse habt ihr noch , Ideen etc ?

Gruesse & merci
andreas

[eini]

@andreas222

Ja das ist kostenlos aber durchaus etwas komplex.

@parkesel
Wie ohne Cache, ohne Cache gibt´s auch keine Performance. Ohne Cache geht goarnix!

[andreas222]

Hi,

kennt sich jemand mit IO-Meter aus ?
Ich meine ist das einfach nur ein Werkzeug oder gibt es Gefahren ?

Gruesse & Merci
Andreas

[GTMK]

Ich habe es schon des öfteren eingesetzt - gefährlich ist es an sich nicht. Im Zweifelsfall schreibt es dir halt die Platte/Partition/LUN voll.

Testszenarien (schon etwas älter, aber immer noch anwendbar) gibt es bspw. hier:

http://www.scribd.com/doc/2477328/Windo ... erformance

Georg.

[RogerG781]

Das ist ja ein Super Thread, der genau auf meine Fragen auch passt.

Werde heut abernd erstmal einen Speedtest machen und schauen, was ich dort im Raid 1 an einem Dell Perc 5/i erreiche.

Allerdings ist ja, die I/O-Wichtig, leider kann ich mir den Link nicht anschauen.
Erst später, was mich aber Interessieren würde:

Wie kann ich den überhaupt nen I/O-Wert auf dem Storage selbst ermitteln? Gibt es da ne Möglichkeit?

Wenn ich jetzt nur eine VM betreibe und dort I/O-Meter laufen lasse, wie aussagekräftig ist das dann noch?

Gibt der ESXi die Performance 1:1 an die VM weiter oder reserviert er sich selbst was?

Danke und Gruß

[GTMK]

Wie kann ich den überhaupt nen I/O-Wert auf dem Storage selbst ermitteln? Gibt es da ne Möglichkeit?

Das hängt wohl von deinem Storage ab...

Wenn ich jetzt nur eine VM betreibe und dort I/O-Meter laufen lasse, wie aussagekräftig ist das dann noch?

Es ist schon eine Weile her, seit ich das das letzte Mal gemacht habe, aber damals stimmten die Werte am Storage und in der VM ziemlich gut überein.

Georg.

[RogerG781]

Erstmal danke für deine Antwort.

Handelt sich um internen Storage der an einem RAID-Controller (Perc 5/i) direkt dem ESXi zur Verfügung gestellt wird (DAS).

Hab derzeit auch nur einen ESXi-Host. Ein zweiter ist mal geplant, derzeite decke ich alles über einen zweiten Controller ab, der nächtliche Backups der VM`s fährt.

Werde heut Abend mal Tests mit einer VM machen und dann die Ergebnisse bekannt geben.

Gibt es noch Empfehlungen, wieviele I/O`s pro VM gebraucht werden?

[eini]

@RogerG781

1 zu 1 wird er die Performance sicher nicht durchreichen können, aber seit den neuen Paravirtualisierten Treibern ist die Performance deutlich besser als mit den alten Treibern. Ich kann auch nicht genau sagen wieviel Overhead es gibt, dazu ist die Thematik sicher zu komplex und die Umgebungen zu unterschiedlich.

Aber tendenziell denke ich i/o Meter in einer VM ist wohl das Beste was man in dieser Hinsicht machen kann. Dazu noch ein esxtop und die I/O´s auf´m Storage gegenprüfen und dann ist das eine saubere Sache.

Nur braucht man eben auch eine Baseline damit man überhaupt "erkennt" ob alles in Ordnung ist oder eben nicht..

Die Frage noch nach den I/O´s pro VM kann man natürlich so überhaupt nicht beantworten. Wie immer kommt das auf die Last der Applikation an. Ist es ein Mailserver mit sehr vielen Random Zugriffen sieht es anders aus als bei einem Domaincontroller z.B. Aber meiner Erfahrung nach "ziehen" VM´s mit hoher Last um die 1000 I/O´s und VM´s mit wenig Last so um die bis zu 50 I/O´s aber das sind meine Erfahrungen...

[GTMK]

"ziehen" VM´s mit hoher Last um die 1000 I/O´s

Ich würde es mir verkneifen, hier Zahlen zu nennen... es gibt da keine VM-spezifischen Werte, sondern es hängt nur von der Anwendung ab und davon, was die Hardware liefern kann (Server, Storage). VMware jedenfalls behauptet, dass sie der Physik schon ziemlich nahe kommen. Virtualisierungsoverhead ist natürlich immer da, und wenn es nur ein ganz kleines bisschen ist.

Georg.

[eini]

@GTMK

Wieso? Er fragt danach und ich sagte ja extra dazu das dies meiner Erfahrung entspricht. Wobei wir dennoch die Frage stellen müssten wie mein I/O aussieht, dass ist ja auch wieder ein Thema. Dennoch kann/darf/soll man auch was sagen, sehe keinen Grund mir was verkneifen zu müssen..

Zurück zu den konstruktiven Beiträgen.

[GTMK]

Ich denke, dass man die Frage

Gibt es noch Empfehlungen, wieviele I/O`s pro VM gebraucht werden?

schlicht und ergreifend so nicht beantworten kann (und diese Frage auch nicht richtig gestellt ist). It depends, und zwar von vielen Variablen. Mit deiner Aussage, dass deine VMs unter hoher Last um die 1000 IOps ziehen, kann ich jedenfalls nichts anfangen. Weder weiß ich, was für eine Maschine mit welchem wie konfigurierten Storage spricht, noch welche Anwendungen laufen und ob diese ächzen oder noch Luft nach oben haben, und du sagst auch nicht, wieviele VMs das parallel leisten.

Ich finde es schon konstruktiv, wenn ich die Meinung äußere, dass die genannte Frage nicht mit Zahlen beantwortet werden kann, weil sie dem Fragesteller nicht weiterhelfen und ihn schlimmstenfalls irreführen können. Habe mir da wohl die schwache Stelle eines ansonsten konstruktiven Beitrags herausgepickt...

Georg.