Hallo,

Wij zijn druk doende om een nieuwe omgeving in te richten, maar zien enorme vertragingen.

De hardware is als volgt:

Servers:
3x IBM xSeries 365, met 4 XEON procs en 16 GB per server.
Coreswitch is een Cisco 4510

San:
DS4300 FastT

NICs:
Elke server heeft een NIC-bond van 3x 1 Gb, 1 Gb voor het Service Console en 1 Gb voor VMotion
(5 kaarten per server dus)

VM's:
De Virtual machines hebben gemiddeld zo'n 2 Gb memory, en 1 VCPU.

De servers hebben 2x HBA connectie naar het SAN.

Met deze configuratie zou het moeten vlammen, maar dat is helaas niet het geval.
Ter illustratie: het kopieeren van 2000 mailtjes, met een totaalgrootte van ongeveer 250 MB duurde anderhalf uur !

We zijn op dit moment verder aan het specificeren op welke niveau's de vertragingen zich manifesteren.
Zijn er anderen die bij de inrichting dit soort vertragingen zijn tegengekomen, of heeft iemand enig idee wat dit zou kunnen veroorzaken ?
ALLE TIPS ZIJN MEER DAN WELKOM !!!!

Bij voorbaat dank,

George Smits

George,

Zou inderdaad moeten vlammen...

Mijn eerste gedachten gaan uit naar het netwerk. Als je iets kopieerd en het duur zoooo lang dan is er waarschijnlijk iets aan de hand met de NIC's die je hebt toegekent aan de VMkernel. Check daar even de Speed & Duplex van, let vooral op current connection. Probeer eens uit of autonegotiate beter gaat of wellicht juist een vaste waarde.

Kijk ook even of je VM gebruikt maakt van VMXNET netwerken...

Een andere optie is disk I/O, bekijk daarom een de queue size van je VM... Kijk in: /proc/vmware/<widvanVM>/disk/vmhba... en let op queue waarden. Als die constant hoog zijn heb je inderdaad een probleem.

Een probleem wat dat zou kunnen veroorzaken is het failoveren van je HBA als je gebruik maakt man mru policy. Probeer een fixed op alle 4 de paden of dat beter gaat, wellicht is er een SP kapot.

Heb je vmkusage al draaien? Wat zegt virtual center met zijn performace monitoring??? Hoge waardes ergens? Weet je zeker dat het geen omgevingsvariabelen zijn? Verkeerde DNS, huidig netwerkverkeer? Heb je je memory van fysieke ESX servers getest (denk aan memtest86). Heb je al geprobeerd zonder bond? WELKE Nic's gebruik je, staan ze op de HCL? Maak je gebruik van VLAN tagging en kunnen jouw netwerkkaarten dat hardwarematig (softwarematig betekend veel overhead)...

Ik zou er nog wel een paar kunnen verzinnen, maar die gaan dan meer uit naar de fysieke omgeving, netwerk, server waarvandaan je het kopieerd - speed, duplex... IP conflict, enz. enz.

Probeer stap voor stap deze mogelijkheden uit te sluiten. Laaste uitwijk: vmware support als het ECHT niet anders kan...

Enne George, probeer eens specifieker te zijn met welke stappen jezelf al had ondernomen en probeer desnoods met iemand anders samen de boel aan te pakken... Succes en laat weten hoe het gaat!

_________________
Bouke Groenescheij | mijn site: http://www.jume.nl

probeer eens iets te kopieeren tussen 2 vms op dezelvde fysieke machine. Weet je direct of de oorzaak binnen of buiten je machine ligt.
Als je dat zelfde dan ook met 2 fysieke machines probeert op dezlfde swithc en hetzelfde SAN heb je bijna alles uitgesloten volgens mij. Dan weet je iig waar je precies moet zoeken.

We zijn op dit moment bezig, samen met de leverancier om stap voor stap de vertragingen te isoleren.
Dus op console niveau, tussen vm's op verschillende ESX-en, tussen VM's binnen dezelfde ESX, tussen verschillende lun's , tussen dezelfde luns, etc.
We testen niveau voor niveau, dus ook zonder bond, of vmotion verbinding. Vervolgens wordt het stap voors stap weer gelinkt.

Op dit moment geven deze metingen consequent een goede snelheid.
(kopieeren van 650 MB .ISO duurt tussen de 20 en 40 sec)

Alle vm's hebben VMNIX en 1 gig verbindingen.

Aanmelding van een user op het netwerk duurt echter 3 minuten, en da's veel te lang. Dat is het vreemde van de zaak.
Het ene is snel, het volgende is bizar traag.

VMKusage staat aan, en vmktree is ook geinstalleerd voor iets beter overzicht.
Hier zijn geen vreemde waarden te bespeuren.

Ook virtualcenter geeft aan dat de servers balletjes zitten te schieten.
We hebben het memory getest met de IBM utility, het bleek dat MemTest86 niet compatable is met onze IBM servers. Alles OK
We hebben inmiddels wel 1 netwerkkaart van een bond als defect kunnen isoleren. Dus er komt langzaam wel wat bovendrijven, maar we zijn er nog niet !

Zodra ik meer resultaten heb post ik ze hier....

Groeten, George

Geweldig!

Het aanloggen van een user kan natuurlijk meerdere oorzaken hebben en eerlijk gezegt denk ik niet dat dat te maken heeft met het virtuele platform. Ik denk eerder dat er dan een DNS, AD, profiel probleem is... Lastig troubleshooten zo, maar ik heb de volste vertrouwen in jullie dat het gaat lukken!

_________________
Bouke Groenescheij | mijn site: http://www.jume.nl

Goed nieuws,

We hebben de zaak redelijk goed aan de praat, na splitsing van de citrix servers op verschillende luns.
Een van de problemen was in ieder geval toch SCSI-2 locking, waardoor de andere machines moesten wachten.

We zijn echter nog steeds bezig met verdere optimaliseringen. Het performed goed, maar toch nog niet helemaal zoals we van een dergelijke configuratie zouden verwachten.
IBM heeft metingen gedaan op VM & SAN niveau, en dat is vrij behoorlijk.
Dus de stoom is van de ketel !

De rest komt goed.

Zit ik net aan te denken... Wist je dat je zelf de plek van de REDO file mag aangeven. Moet wel VMFS zijn natuurlijk maar op die manier heb je bijvoorbeeld de vmdk op de productie VMFS staan en de REDO's op een appart VMFS op een andere LUN.

Wellicht een idee voor jullie?!?

_________________
Bouke Groenescheij | mijn site: http://www.jume.nl

da's ook wel een goede tip, dat moeten we zeker eens uitproberen.
Onze eerste prioriteit lag in ieder geval bij snelheid in de productieomgeving.

We hebben ook nu na de upgrade van ESX de VMware Tools bijgewerkt, en het gaat nu als een speer.

Natuurlijk geldt altijd de wet van roadrunner, niets went zo snel als snelheid

We optimaliseren rustig verder....