Festplattenperfomance im Keller

[cotec]

Hallo zusammen,

ich brauche mal einen Rat zu einem ESXi-Host 5.1 welcher seit einiger Zeit hohe Latenzen im Speicherbereich aufweist. (siehe Screenshots)
zum System: ein HP-Server ML350p G8, 65GB RAM (50% augelastet wenn alle VMs an), CPU-Last ist sehr gering ~1Ghz.

Der Host besitzt 6 lokale Platten á 2TB.
Konfiguriert sind 5 Platten als RAID 5 und eine macht HotSpare. Es existiert ein Datatore mit der vollen Raid-5-Größe auf dem alle VMs platziert worden sind. (mehrere Datastores für die VMs zu generieren hätte den gleichen Effekt, schließlich hängt ja die Festplattenleistung)

Letztens ist eine HDD ausgestiegen, HotSpare griff ein, Festplatte wurde getauscht, Rebuild zurück, HotSpare wieder frei -> alles i.O.
Auf dem Host selbst laufen 7 VM's mit Windows Server 2008R2, eine vCenterAppliance und eine Win7-VM.

[Bild 1]

[Bild 2]

[Bild3]

[Bild4]


Es gibt für mich keine plausiblen Grund, warum bei Bild 1 so viele Spitzen im regelmäßigen Abständen (alle 3-4 Minuten) zustande kommen. Außerdem warum die Festplattenleistung so dermaßen in den Keller geht.

Für Verbesserungsvorschläge wäre ich dankbar.
-cotec

[~thc]

Nochmal zur Klärung: Zeigt der Host dieses Verhalten erst nach dem Ausfall/Rebuild?

Passen die durchschnittlichen IOPS der laufenden VMs auch in die IOPS-Leistung des RAIDs?

EDIT: Man kann mit den physischen Werten der Platte (RPM und Seektime) und dem RAID-Typ (5) die IOPS-Leistung des RAIDs ganz gut abschätzen. Wenn jetzt 3 oder mehr VMs regelmäßig IO-Last erzeugen, kann das ein einzelnes RAID5 aus 5 Disks schon überfordern.

Das sieht für mich so aus, als würde auf unterster Ebene (ESXi Treiber / Hardware) ein Elevator oder Buffer regelmäßig voll laufen und dann das System zum Hängen bringen.

[cotec]

Nochmal zur Klärung: Zeigt der Host dieses Verhalten erst nach dem Ausfall/Rebuild?

Ob dies davor schon der Fall war, kann ich nicht mit bestimmtheit sagen

die Festplatten sind alle: 7200'ter SATA - 2TB
Als Server laufen die "Standarddienste": ActiveDirectory+DNS+DHCP,zwei Dateiserver,WSUS,AntiVirus (GDATA) und ein Webproxy.
WSUS, AntiVirus und Webproxy bringen jeweils eine Datenbank mit.

[kastlr]

Hallo,

probier doch erst einmal herauszufinden, wer der Verursacher dieser Werte ist.

Ich würde dazu wie folgt vorgehen.

1. Öffne zwei ssh Sessions zum ESXi Host
2. Führe in beiden ssh Sessions esxtop aus
3. Wechsel in Session 1 die Anzeige durch Eingabe von u, s 2<Return> auf die Anzeige für deine physikalischen Devices.
4. Wechsel in Session 2 die Anzeige durch Eingabe von v, s 2<Return> auf die Anzeige für deine VM's und ihrer virtuellen Disks.
5. In Session 2 kannst du dir auch noch die Informationen für jede einzelne vmdk anzeigen lassen, verwende dazu auf dem Ziffernblock 2 + 8 zum Blättern, 4 zum ausblenden einer VM und 6 für die erweiterten Informationen

Da das "Problem" ja alle 3-4 Minuten auftritt, solltest du damit ziemlich schnell in der Lage sein, den Verursacher einzugrenzen.

Gruß,
Ralf

[Dayworker]

Falls das auch nichts bringt, wähle mal die Windows-Standardlösung und mach nen Reboot. Das kann je nach Controller und Platten manchmal Wunder bewirken.

Mich würde auch interessieren, ob du nach dem Tausch die vorherige Hotspareplatte weiter als reguläre Platte laufen lassen oder diese wieder zum Hotspare gemacht hattest.

[stahly]

Vielleicht ist auch einfach nur die Raid Controller Batterie defekt / leer.

Schonmal überprüft?

[~thc]

die Festplatten sind alle: 7200'ter SATA - 2TB
Als Server laufen die "Standarddienste": ActiveDirectory+DNS+DHCP,zwei Dateiserver,WSUS,AntiVirus (GDATA) und ein Webproxy.
WSUS, AntiVirus und Webproxy bringen jeweils eine Datenbank mit.

Uh oh.

Eine 7200 S-ATA Platte liegt im Bereich von 70-80 IOPS. Ein Daraus gebautes RAID5 mit 5 Platten liegt bei ungefähr 100 IOPS Gesamtleistung. Abhängig von den IOPS deiner VMs (konkurrierende Lese- und Schreibvorgänge im Regelbetrieb) kann das RAID also "einfach so" ins Schwitzen kommen.

[cotec]

Mich würde auch interessieren, ob du nach dem Tausch die vorherige Hotspareplatte weiter als reguläre Platte laufen lassen oder diese wieder zum Hotspare gemacht hattest.

Laut HP-Support sollte man einfach die neue Platte einsetzen und das Rebuild läuft automatisch von der HotSpare wieder zurück auf die eben eingesetzte. Bedeutet HotSpare ist nach wie vor die gleiche Platte.

Vielleicht ist auch einfach nur die Raid Controller Batterie defekt / leer.
Schonmal überprüft?

RAID-Einstellungen lassen sich ja nur im ACU (Array Configuration Utility) einsehen und dazu muss der Server heruntergefahren werden. Ich hoff ich bekomm heut nachmittag mal ne Downtime genehmigt... =/

[Dayworker]

Wenn der Hotspare immer wieder auf dieselbe Platte schwenkt, ist das in meinen Augen etwas ungünstig. Der Hotspare läuft ja trotzdem die ganze Zeit mit und altert daher fast in demselben Maße wie deine Raid5-Mitglieder. Mit steigender Betriebszeit macht das einen weiteren, "normalen" Raid-Mitgliedsausfall wahrscheinlich, bei dem dann auch der Hotspare zwar ohne Zugriffsstreß aber aufgrund seiner hohen Laufleistung mit ausfällt.
Mir ist in dem Zusammenhang auch nicht klar, wann man wirklich ein Hotspare vorsehen oder ab welcher Spindelanzahl man besser gleich auf Raid6 oder besser setzen sollte.



Bei einem HP-Server siehst du eigentlich sämtliche Systemkomponenten, wenn du entweder das HP-ISO oder die CIM-Provider eingespielt hast. Nur um den Zustand der BBU zu checken, brauchst du dann meines Wissens nicht das ACU.

[stahly]

...
Mir ist in dem Zusammenhang auch nicht klar, wann man wirklich ein Hotspare vorsehen oder ab welcher Spindelanzahl man besser gleich auf Raid6 oder besser setzen sollte.
...

Wobei Raid6 in diesem Fall wohl noch langsamer werden würde.

[cotec]

Der Hotspare läuft ja trotzdem die ganze Zeit mit und altert daher fast in demselben Maße wie deine Raid5-Mitglieder.
...bei dem dann auch der Hotspare zwar ohne Zugriffsstreß aber aufgrund seiner hohen Laufleistung mit ausfällt.

Ich kann jetzt nur für HP sprechen, aber dort wird die Platte erst Online geschalten, wenn die wirklich in Benutzung geht.

Bei einem HP-Server siehst du eigentlich sämtliche Systemkomponenten, wenn du entweder das HP-ISO oder die CIM-Provider eingespielt hast. Nur um den Zustand der BBU zu checken, brauchst du dann meines Wissens nicht das ACU.

Das System wurde mit HP-branded-Datenträger installiert, die Shell-Erweiterung 'hpaucli' hab ich schon getestet, hab aber keine Möglichkeit gefunden den Status der BBU auszulesen.

edit: im vCenter Hardwarestatus findet man folgendes: (ist allerdings nicht besonders aussagekräftig | Warum PowerSupply 6 & 7 Unbekannten Status aufweisen ist auch so ne Sache...)



Möglicherweise habe ich den Fehler gefunden.
Wir besitzen einen baugleichen Server in einer Nebenstelle, der noch auf dem alten Firmwarestand ist. Dazu sei gesagt: Nachdem die defekte Platte getauscht wurde, hat der HP-Support gemeint ein Firmwareupdate des Controllers wäre noch notwendig - gesagt getan.

Nun unterscheiden sich die beiden Systeme nach intensiver Betrachtung nur in zwei Punkten:



Auf der Seite, mit Storage-Problem:
Boot Controller: Ja
Firmware-Version: 4.6.8
RAID 6 (ADG-Status): Aktiviert


Auf der Seite, ohne Storage-Problem:
Boot Controller: Nein
Firmware-Version: 3.22
RAID 6 (ADG-Status): Deaktiviert

Zum ADG (Advanced Data Guarding) ist dieser Foreneintrag recht interessant:
http://h30499.www3.hp.com/t5/ProLiant-S ... qlmWuKnl1N

The main disadvantage of RAID ADG is a relatively low write-performance
(lower than RAID 5), because of the need for two sets of parity data.

Es könnte die Probleme verursachen, dazu werd ich mich mit dem HP-Support nochmal auseinandersetzen...

edit: Neustart des Hosts brachte keine Lösung...

- cotec

[blue_focus]

Also ich tippe ja auch leider mal darauf, dass die Datastore Konzeption für die Anforderungen nicht ganz optimal ist. Ich hatte mit SATA-Platten im Serverumfeld leider noch nie besonders prickelnde Erfahrungen. Immer wieder versucht und immer wieder zurück zu den "echten" SAS-Platten gegangen. Wir haben bei uns als lowcost-Storage einige Hitachi HUS Systeme im Einsatz. Jeweils mit 14 Spindeln a 3TB. Mehr als 300-350 IOPS am reinen Diskbackend machen die einfach nicht. Wäre da nicht ein 4GB großer Cache der VSP vorgeschalten wären die selbst für die einfachsten vSphere-Anwendung gänzlichst unbrauchbar. Dank Cache reichen die aber zumindest für diverse Datenfriedhöfe und Dataminer.

[Dayworker]

@"blue_focus"
Das ist zwar alles richtig, erklärt aber dennoch nicht die Probleme erst seit dem Plattentausch.
Wenn es vorher genau so damit gelaufen ist und diese Spikes nicht auftraten, kann ide Ursache doch nur die neue Platte sein.

[mbreidenbach]

Von einem HP Server mit ESXi kann man sich mit dem Windows Tool HPRSMCLI den Systemstatus der Hardware auslesen und z.B. in eine Textdatei umleiten. Da steht dann auch was zu Platten und RAID drin.

[blue_focus]

Nochmal zur Klärung: Zeigt der Host dieses Verhalten erst nach dem Ausfall/Rebuild?

Ob dies davor schon der Fall war, kann ich nicht mit bestimmtheit sagen

@ Dayworker.

Ich hätte mich auf diese Aussage hier bezogen. Sollte es wirklich erst seit dem Plattentausch sein hast du natürlich völlig recht.

[Dayworker]

@blue_focus

Ob dies davor schon der Fall war, kann ich nicht mit bestimmtheit sagen

Den hab ich dafür wieder mal überlesen, danke für die Erinnerung.

Ich glaube wir kommen hier wohl nicht wirklich ohne "contec" und besseres Zahlenwerk bzw Meßwerte weiter.

[cotec]

hat lange gedauert.... HP Support hat eine Lösunge gefunden:

http://h20565.www2.hp.com/portal/site/h ... .492883150

Exakt unser Problem, gleicher Server, gleicher Controller, gleiches Betriebsystem.

Auf der Konsole geprüft ob Modul vorhanden:

Code: Alles auswählen

esxcli software vib list | grep hp-smx-provider

Code: Alles auswählen

esxcli software vib remove -n hp-smx-provider

danach Deinstallation vom Modul vorgenommen und noch im selben Moment seh ich in der Leistungsübersicht die Verbesserung. Ca. 8:30 wurde der Befehl gesendet, man siehts deutlich:



Nun sind die Latenzen von Spitzenwerten von bis zu 12.000ms auf 8ms gesunken.


Alles wieder im grünen Bereich. =)

[cotec]

Klasse, kaum 2 Monate später wieder das gleiche...
Diesmal kanns nicht am smx-provider liegen...

Einzige Möglichkeit die ich noch sehe nochmal die Firmwarestände des Servers zu prüfen und ein ESX-Update zu fahren.

Hat jemand andere Vorschläge oder Ideen?

[kastlr]

Hallo,

hast du dir das jemals unter esxtop angesehen, wie bereits vorgeschlagen?
Wie viele IO's sind denn überhaupt betroffen?
Was sagt denn das vmkernel.log?

Wenn ich die Transferraten sehe macht die Platte nicht wirklich was.
Nicht das du hier einem Phantom nachjagst, weil alle 5 Minuten mal ein IO "hängen" bleibt.

Bei geringer IO Anzahl sind die Grafiken nur bedingt geeignet und sagen erst recht nichts über ein Performance Problem aus.

Gruß,
Ralf

[cotec]

Nicht das du hier einem Phantom nachjagst, weil alle 5 Minuten mal ein IO "hängen" bleibt.
Bei geringer IO Anzahl sind die Grafiken nur bedingt geeignet und sagen erst recht nichts über ein Performance Problem aus.

Problematisch ist, das sich die Benutzer beschweren über lange Anmeldezeiten, also kann von Phantom keine Rede sein...


vmkernel.log

Code: Alles auswählen

2014-03-17T07:18:12.178Z cpu0:8200)NMP: nmp_ThrottleLogForDevice:2319: Cmd 0x1a (0x4124003c0140, 0) to dev "mpx.vmhba0:C0:T1:L0" on path "vmhba0:C0:T1:L0" Failed: H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x20 0x0. Act:NONE
2014-03-17T07:18:12.178Z cpu0:8200)ScsiDeviceIO: 2316: Cmd(0x4124003c0140) 0x1a, CmdSN 0xa95a from world 0 to dev "mpx.vmhba0:C0:T1:L0" failed H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x20 0x0.


außerdem hab ich jede Einträge zur USB-Maus, diese werde ich sicherheitshalber mal abziehen, brauchen wir eh nicht, da ILO Adv. vorhanden

Code: Alles auswählen

2014-03-17T07:18:46.860Z cpu2:8662)<6>usb 1-1.6: new low speed USB device using ehci_hcd and address 24
2014-03-17T07:18:46.978Z cpu2:8662)<6>usb 1-1.6: New USB device found, idVendor=093a, idProduct=2510
2014-03-17T07:18:46.978Z cpu2:8662)<6>usb 1-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
2014-03-17T07:18:46.978Z cpu2:8662)<6>usb 1-1.6: Product: USB Optical Mouse
2014-03-17T07:18:46.978Z cpu2:8662)<6>usb 1-1.6: Manufacturer: PixArt
2014-03-17T07:18:46.980Z cpu3:8662)<6>generic-usb 0003:093a:2510.197a: input: USB HID v1.11 Mouse [PixArt USB Optical Mouse] on usb-0000:00:1a.0-1.6/input0
2014-03-17T07:18:46.980Z cpu3:8662)<6>usbhid 1-1.6:1.0: interface is claimed by usbhid
2014-03-17T07:18:46.980Z cpu3:8662)<6>usb 1-1.6: device is not available for passthrough
2014-03-17T07:18:46.980Z cpu3:8662)<6>usb 1-1.6: usbfs: registered usb0118


ich werd erstmal auf die neueste FW-Version und ESX-Version patchen, in der Hoffnung das es damit gefixt wird... (auf VMware ESXi 5.1 Update 2)

[kastlr]

Hallo,

laut T10 Webseite meldet das Device mpx.vmhba0:C0:T1:L0 folgenden Status.

Code: Alles auswählen

H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x20 0x0

Command OpCode = 0x1a      -> Mode Sense
Status Code    = 0x2       -> Check Condition
Sense Key      = 0x5       -> Illegal Request
Add Sense Key  = 0x20 0x0  -> Invalid Command Operation Code

Sofern diese Meldung wirklich mit dem Problem zusammen hängen sollte, sendet offenbar ein Prozess ein vom Device nicht unterstütztes Kommando.

Vielleicht hift dir ja folgender Link weiter.
vHBAs and other PCI devices may stop responding in ESXi 5.x and ESXi/ESX 4.1 when using Interrupt Remapping

VAAI ist in so einem Fall auch immer mal wieder ein gern gesehener Kandidat, ich würde es daher vorübergehend deaktivieren.

Aber ohne den ganzen vmkernel Log oder zumindest die Aussage, welches Device denn geanu betroffen ist (in den Screenshots ist diese Info geschwärzt) ist das zum größten Teil Spekulation.

Gruß,
Ralf