Hallo,

wij hebben een performance probleem.

We maken gebruik van ESX 3.5 U3 met de laatste patches. Dit is geïnstalleerd op 5 HP DL380 G5 machines, ieder voorzien van 2 HBA's. 3 machines voorzien van HP branded Qlogic HBA's en 2 machines zijn voorzien van HP branded Emulex HBA's.

Deze machines zijn via fibre verbonden met een HP EVA 8100.

Nou viel me op in esxtop dat de AQLEN bij de machines met de Qlogic kaarten op 4096 staat en de machines met de Emulex kaarten op 1014 staat.

Natuurlijk heb ik al wat lopen zoeken en schrok eigenlijk van de waardes in esxtop. Op de verschillende plekken op het web worden verschillende dingen geroepen, maar het komt er volgens mij op neer dat de Queue depth voor zowel Qlogic als Emulex 32 zou moeten zijn.

Kan dit het performance probleem veroorzaken? En na eventuele aanpassing dus verhelpen?

Grtz, RAdV

je spuit wel een theorie maar vergeet even te vertellen wat voor problemen je precies hebt. het begrip "performance probleem" is nogal breed.

Daar heb je gelijk in.
De klacht die we te horen kregen was dat veel mensen de VM's traag vinden.

We hebben wat disk performance testen vanuit een vm en vanaf verschillende hosts gedaan en daarbij zien we dat de read performance echt belabberd is:

Sequential Read : 21.146 MB/s
Sequential Write : 182.150 MB/s
Random Read 512KB : 9.744 MB/s
Random Write 512KB : 36.116 MB/s
Random Read 4KB : 0.158 MB/s
Random Write 4KB : 6.824 MB/s

Test Size : 500 MB

Dit geld dus voor iig 3 van de 5 hosts en aangezien de overige 2 gelijk zijn ingericht...

Bij wat onderzoek kwam ik ook nog tegen dat de Disk.UseDeviceReset hier op 1 ingesteld staat. Volgens verschillende bronnen zou dit 0 moeten zijn bij het gebruik van een SAN omgeving. Maar kan dat zo verschrikkelijk veel uit maken? Ik weet van andere bedrijven dat men het daar ook default heeft gelaten...

Misschien zoek ik het ook wel in de compleet verkeerde hoek, ook dat hoor ik dan natuurlijk graag!

RAdV

Ik weet niet wat de performance op een HP EVA hoort te zijn. maar het lijkt mij inderdaad aan de lage kant.
Je zou kunnen proberen om op een fysieke machine dezelfde test te draaien en die te vergelijken.

Dat de write rates hoger liggen dan de read is te verklaren dat writes in de cache gebeuren. En die is natuurlijk vele malen sneller dan de disks.

Ik zou kijken of je ergens last hebt van queueing. OP ESX, je fibre switch of op je Storage box. Queueing betekent dat er meer IO wil plaatsvinden dan dat er afgehandeld kan worden.
Indien je last hebt van queueing kun je de queuedepth aanpassen om eventueel te tunen, maar dan moet je wel eerst weten of er een bottleneck is en waar.

Verder zou je kunnen kijken over hoeveel disks je diskgroup gestriped is en wellicht over meerdere disken gaan stripen.

Ook zou ik kijken als het een active/active configuratie is om de luns over de HBA's te verdelen(load balancen). Standaard gaat alle verkeer over hba1

En misschien heb je wel gewoon last van een slechte fiber kabel en worden niet alle paden gebruikt!

_________________
Try nothing physical tomorrow if you can virtualize today... Blogging: http://www.van-lieshout.com Twitter: http://www.twitter.com/avlieshout

Even een testje gedaan op een werkstation (sata) levert op dat de read meer dan 2x zo hoog ligt als op het SAN...

Ik ben nog niet goed bekend met HP tools om uit te kunnen vinden of het SAN de bottleneck is.
Kan iemand mij daar info over geven?

over hp weet ik vrij weinig maar de waarden die je opgeeft zijn behoorlijk laag ja. Ben wel benieuwd hoe je de meting hebt gedaan.
Heb je die vanuit een VM gedaan terwijl er nog meer VMs draaiden? Dan is deze test n; totaal niet representatief voor de overall performance van je SAN. Misschien is er wel 1 VM die veel beslag op de disk I/O en zo andere VMs het leven moelijk maakt. Inclusief de VM waarvandaan jij de tests deed. Misschien is het zelfs wel een fysieke machine die dit veroorzaakt zodat vmware er zelf geen invloed op heeft.

Een test uitvoeren op een san dat gebruikt wordt door een aantal VMs vergelijken met een test op een enkel sata diskje is appels en peren vergelijken.

Goed... ik ben er achter... en ik moet me diep te schamen.
Ik had niet alle info: er zijn 2 diskgroepen. Dat wist ik. Wat ik niet wist: 1 met SCSI disks en 1 met FATA disks. De LUN's voor het ESX cluster staan op FATA schijven. Dus na een LUN op SCSI (VRAID5) te hebben aangemaakt, aan een ESX te hebben geconnecteerd en daarop even een machine te hebben gezet om te testen, zagen we een performance zoals we die graag willen zien.

Daarna ook nog even lopen 'spelen' met Disk.UseDeviceReset. Standaard staat deze hier op 1. Na deze op 0 te hebben gezet zagen we nog weer een aardig stukje snelheidswinst. De laatste test leverde dit op:

Sequential Read : 335.861 MB/s
Sequential Write : 148.992 MB/s
Random Read 512KB : 337.969 MB/s
Random Write 512KB : 38.099 MB/s
Random Read 4KB : 1.191 MB/s
Random Write 4KB : 8.296 MB/s

Test Size : 50 MB (9x)

De host setting in CVE stond ook niet op VMware. Ook dat is aangepast, maar ik kon geen verschil merken tussen de instelling Windows of VMware. Iemand daar nog ideeën over?
We gaan die instellingen natuurlijk wel doorvoeren.

ChrisR en Arnim: dank jullie wel!

@ChrisR: Je hebt gelijk: andere hosts waren ook geconnecteerd aan dat LUN met meerdere VM's en dus zegt de eerste meting helemaal niets.

FATA ?

Fiber ATA

Da's HP z'n manier om er voor te zorgen dat je niet gewone (s)ata diskjes in je san prikt..........


ben van de write speeds trouwens nog steeds niet heel erg onder de indruk maar weet niet wat dat san nog meer stond te doen natuurlijk.
ter vergelijking: op een HP dl 380 met MSA (scsi connectie) en 14 disks kan je 300Mb/s halen. kost een stuk minder dan een EVA.

Ahh.. ok. Ik ken het alleen als FC hdd's.. daarom had ik de link niet zo snel gelegd.

Quedepth van QLogic kaarten moet zover ik weet op 64 staan, niet op 32.

_________________
Groeten,
Michiel