[VMWare] Hoge avg. disk queue length op fileserver

[nextware]

Hallo medetweakers,

Op het werk lopen we op dit moment tegen een heel raar verschijnsel aan. Ik zal proberen het zo duidelijk mogen te omschrijven:

Situatie:

- VMware ESX 3.5 omgeving
- Equallogic iSCSI SAN ( onderverdeeld in RAID10 en RAID50 )
- Windows 2003 gebaseerde servers (virtueel)
- Op iedere server staat Microsoft iSCSI initiator geïnstalleerd

Probleem:

Nu lopen we dus de laatste dagen tegen een probleem aan dat tussen 08:20 uur en 09:30 uur de performance op de fileserver gewoon recht naar beneden dondert. Op dat moment zien we via onze monitoringtool ( Nagios ) dat de avg. disk queue lengt rond de 25 - 30 schommelt op deze betreffende servers.

Het inloggen en werken met documenten is op dat moment dus echt niet vooruit te branden.

Het filesysteem van de betreffende server staat op de RAID50 omgeving van de SAN. De overige servers die hierop staan, hebben totaal geen probleem. Het is echt alleen de fileserver die het probleem heeft.

Op deze server staan (oa) de volgende shares:
- Userprofiles
- Groepsmappen

VM-config van de fileserver:

- 2 CPU's
- 4GB intern geheugen

Nu ligt het dus voor de hand dat het probleem veroorzaakt wordt door het inloggen van een zeer groot aantal gebruikers. Ongeveer 700 medewerkers van de organisatie begint met werken om 08:30 uur. Dit kan dus de grote queue veroorzaken.

Maar we kunnen dus echt op dit moment niet achterhalen, waar precies de opstopping ontstaat. Recentelijk zijn de specs van de fileserver al geüpgrade naar de bestaande waarden ( zie boven ).

Op het moment van inloggen loopt er nog een full backup van de betreffende server. Maar die performance dondert dan ook naar beneden. Logisch, want de disk queue length stijgt als een raket.

In eerdere tests met het pauzeren van de backups heeft dit wel een heel klein beetje geholpen, maar de performance is nog steeds slecht.

Onderzocht:
- Meldingen op de SAN => geen meldingen gevonden
- Logs op de betreffende server => geen opvallende meldingen gevonden ten tijde van de storing
- Backup uitgezet => geen performance winst
- Loopt er een virusscan => nee, er loopt geen virusscan

We hebben nog een kleine visuele controle op de betreffende core switches gehouden. Hierop zien we geen echte toename van de drukte van het netwerkverkeer.

Zelf hebben we een klein vermoeden dat het wellicht te vinden is in de Microsoft iSCSI initiator ( software matige oplossing ). Wellicht dat de software de drukte niet kan verwerken. Maar dit is dus een vermoeden. Er is niet veel te vinden hierover op internet. Er zijn enkele meldingen, maar deze hebben veelal betrekking op SQL-server. De versie die we gebruiken is 2.5.2.

Heeft één van jullie wel eens hiermee te maken gehad ? Of heeft een mogelijke oplossing / oorzaak waar we nog niet naar hebben gekeken ?!

[MoBi]

Backup zorgt er deel voor dat de disk performance naar beneden gaat, maar het kan ook een virus scanner zijn. Dit heb ik ook gemerkt. Voor al als er in het login script veel exe of bestanden worden aangeraakt. Probeer eens je virus scanner niet bij een read te laten scannen maar alleen op new en save acties.
Waarom heb je op de je virtuele server iscsi aan staan en niet onder vmware? Heb je voor je virtuele server met iscsi een eigen virtuele netwerkkaart en physieke netwerkkaart?

[TheNazgul]

Uit hoeveel disken bestaat je raidgroep ?

Hoeveel servers staan er op die betreffende raidgroep ?

We hebben een FC SAN, onze fileserver laat ook zeer intensieve disk IO zien, voornamelijk veroorzaakt door de backup en door een applicatie (filearchiving van Symantec).

Ik heb de fileserver op een eigen raidgroep gezet (raid 5) zodat de server een eigen disk stack heeft.
Dit voorkomt dat andere servers nadeel ondervinden van de performance.

Als je nog vrije ruimte hebt op je SAN, zou je kunnen proberen de fileserver te migreren naar een "eigen stukje" SAN, niet gedeeld met andere servers, vaak komt dit de performance ten goede.

Ik heb dit probleem ook gehad met een exchange server, deze had 2 eigen disken in een raid10. Performance was zeer slecht, na de migratie naar raid 10, bestaande uit 4 disken was de performance aanzienlijk verbetert. Misschien is het een kwestie van meer spindels toevoegen aan je raidgroep.

[Qwerty-273]

MoBi schreef op maandag 20 oktober 2008 @ 12:19:
Probeer eens je virus scanner niet bij een read te laten scannen maar alleen op new en save acties.

Je kan inderdaad in je clients het beste scannen van netwerk bestanden uitschakelen - en dit overlaten aan een virus scanner op je fileservers. Vooral met veel applicaties/grootte bestanden in de profielen/ hoofdgroepmappen veroorzaken clients veel netwerk en data verkeer (wat in veel gevallen onnodig is).

[2wakky]

Welke MTU's gebruik je ? default is 1500, en dat is zeer laag voor iSCSI.
Zelf heb ik alles naar 9000 gezet, dit geeft redelijk wat meer performance

[nextware]

Je kan inderdaad in je clients het beste scannen van netwerk bestanden uitschakelen - en dit overlaten aan een virus scanner op je fileservers. Vooral met veel applicaties/grootte bestanden in de profielen/ hoofdgroepmappen veroorzaken clients veel netwerk en data verkeer (wat in veel gevallen onnodig is).

Dit hebben we ook al eens uitgeschakeld als test. Had ook echter weinig effect op de performance. Ook het uitschakelen van de backup heeft niks opgeleverd.

Het vreemde is ook dat het niet iedere dag optreedt, maar gewoon willekeurig op een ochtend.

Welke MTU's gebruik je ? default is 1500, en dat is zeer laag voor iSCSI.
Zelf heb ik alles naar 9000 gezet, dit geeft redelijk wat meer performance

Wat ik begrepen heb, is dat de MS iSCSI initiator dit automatisch afbreekt naar 1500, dus daar zou het volgens ons niet aan kunnen liggen.

Waarom heb je op de je virtuele server iscsi aan staan en niet onder vmware? Heb je voor je virtuele server met iscsi een eigen virtuele netwerkkaart en physieke netwerkkaart?

Waarom dit is gebeurd, weet ik ook niet. Dit is zo ingeregeld tijdens de oplevering van het netwerkdoor de leverancier.

Uit hoeveel disken bestaat je raidgroep ?

Hoeveel servers staan er op die betreffende raidgroep ?

De RAID-50 groep bestaat uit 14 disken. Er staan een totaal van 21 volumes op. De totale grootte van het volume is 6,54TB. De hoeveelheid free space ( op dit moment ) 3,93TB.

De SAN is een equallogic PS400E.

[TheNazgul]

Je zou kunnen proberen de fileserver te migreren van de raid50 naar de raid10 groep.
Puur om te kijken waar de bottleneck zit.
Hoe is je raid10 groep opgebouwd?

Voor hele intensieve systemen maak ik meestal een apparte raidgroep/lun op een eigen set van disks.
Ik neem aan dat je alle kabinetten al ingedeeld zijn?

[erwinb]

Ik zou voor een dergelijk systeem gebruik gaan maken van iSCSI kaarten van b.v. qlogic. Deze zorgen ervoor dat de load op iSCSI een heel stuk hoger kan worden als die van adapters die standaard in een server zitten.
Als je dit niet wil moet je even goed kijken naar de ip poorten op de server zelf. soms zie je servers die b.v. twee merken chips gebruiken (SUN in de X2100) hier zou je dan mogelijk ook een voordeel uit kunnen halen.