Beste VMUG-ers.

Sinds enige tijd hebben wij een Equallogic ps4000e is combinatie met Dell powerconnect 5524 switches in stack. De equallogic was door de leverancies netjes opgezet met een MTU van 9000. De switches waren ook door hun geconfigureerd. Het enige dat nog moest gebeuren waren de VMware hosts. Dit heb ik enige tijd geleden gedaan (icm multipathing) en sindsdien hebben wij performance issues. Tijdens backups 's nachts worden alle VM's enorm traag en zien wij failed services.

Na een flinke zoektocht kwam ik erachter dat de switches niet voorzien waren van de Jumbo Frames optie. Die kan wel aangezet worden. Het enige dat ervoor moet gebeuren is een reboot van de switches om Jumbo Frames dus te enablen.

Nu mijn vraag aan jullie. Hoe kan je dit netjes oplossen? De vm's mogen niet uit, das het nadeel. Maar kan je bv per switch rebooten? en komt dan de failover in gevaar? Zijn hier stappen voor?

Thanks in advance.

Henk

5524 kan je per stacked member rebooten, dat is geen enkel probleem.
Ik ga er natuurlijk wel vanuit dat je zowel je hosts als je eql over je stack zijn verdeeld.

ja, ik zie in alle fysieke vmware servers een dubbel pad lopen. dus dat werkt. niet overal staat nog round robin aan, maar dat maakt voor dit niet zoveel uit.

Maar zijn er dingen die mis kunnen gaan tijdens dit? hebben jullie ervaringen met "gekke" dingen?

Thanks voor het snelle antwoord trouwens

Het moet dus een fysiek pad zijn, dus niet dat je PS4000 met zijn aktieve controller aan 1 pSwitch hangt.
Verder kan er weinig gebeuren als je je aan alle iSCSI richtlijnen gehouden hebt (timeouts, failover tressholds e.d.)

ik heb destijds gewoon de standaard PDF gevolgd waarin de opzet van een multipathing setup staat.

Maar goed, ondertussen heb ik dus Jumbo Frames aangezet op de Switches. Daarna Switch voor Switch gereload, en ik kan nu een vmkping doen hoger dan 1500 MTU. Dus dat is goed lijkt me.

Maar het gekke was wel dat ik wel een hapering merkte in de VM's tijdens het rebooten van de 2e switch. Kan het zijn dat de failover van de ene switch naar de anders switch toch een kleine hickup op kan leveren? of moet dat vlekkeloos gaan?

Je moet er altijd even wat tijd tussen laten om je paden weer online te krijgen en de ARP tabellen bij te laten werken. Zeker wanneer 802.1w uit staat.

ja, ik heb express gewacht tot ik in VMware beide paths weer terug zag. Daarna ben ik met de volgende switch begonnen. Tja, een kleine hapering van een paar seconden vind ik persoonlijk niet zo'n heel groot issue.

Het kan wel verstandig zijn er even naar te kijken want als je bijv. bij een vMotion of DRS dat ook hebt is er iets niet helemaal goed.

Normaliter gaat dit bij mij altijd zonder hapering, idd wat Dukebox aangeeft, even wachten dat de paden correct zijn hersteld, dan beginnen met de volgende

_________________
| Blog.vmpros.nl | Twitter | DBL | vExpert 2010/2011/2012 |

Wat zijn dan de plekken waar ik settings moet nalopen om te kijken of onze situatie dan echt goed is. het meeste heb ik nu wel gedaan, maar aangezien er een extern bedrijf ook tussen heeft gezeten ben ik er niet meer zeker van of alles optimaal is.

Dan pak je gewoon de 'best practice' voor jouw vSphre versie en SAN/NAS en loopt die helemaal na.

Is de switch situatie/configuratie uberhaupt getest zonder vSphere? Bijvoorbeeld een fysieke 2008 server koppelen met bijv een nic team naar 2 switches met de MPIO driver van de vendor?

Anders ga je zoeken in iets waar je niet zoeken moet

Edit:

Daarnaast, indien je hebt geupgrade van bijv. vSphere 4 naar 5.. en miss een firmware upgrade heb gedaan op het SAN dan kan voor vSphere 5 een andere configuratie "best practice" gelden als dat ze toen hebben gesteld voor vSphere 4

Tip dus; pak de laatste documenten van de vendoren bij elkaar en configureer zoals het NU wordt voorgesteld

_________________
| Blog.vmpros.nl | Twitter | DBL | vExpert 2010/2011/2012 |

Nou, dat is een beetje het vervelende. Er is een bedrijf binnen gerold die in 4 uurtjes tijd de equallogic aansloten en configureerden, switches configureerden en weggingen. As part of the deal zeg maar. Het was nog redelijk uitzoeken wat ze gedaan hadden. En op zich is reversed engineering een goed iets, aangezien je dan overal komt.

Maar om je vraag te beantwoorden, nee. er is geen fysieke machine erop gekoppeld en getest. En op dit moment word dat ook lastig. Het systeem willen ze nu niet meer gaan testen. Vandaar dat ik dan alles maar na ga lopen.

Hm ja dat is lastig, maargoed als supporter/beheerder moet het dan ook een uitdaging voor je zijn om er wegwijs in te worden en juist een stabiele omgeving neer te zetten. Vooral in snelle projecten worden nog wel eens best practices vergeten toe te passen en wordt alles z.s.m. opgeleverd. Indien je er echt niet helemaal uit komt, laat dan door een extern bureau een audit uitvoeren, misschien komt dan nog meer boven water.

Lastig om die dingen te testen omdat je er blijkbaar toch hinder van ondervindt dus kan je overdag niet eea testen

Zou het toch eens proberen, sluit een nieuwe fysieke server aan op beide switches, trek er een onderuit en kijk of je ping verliest, zoja hoe lang en wat zijn de gevolgen en ga vooral dingen uitsluiten, beetje bij beetje kom je dan steeds verder

_________________
| Blog.vmpros.nl | Twitter | DBL | vExpert 2010/2011/2012 |

ja, ik denk gewoon dat we op een bepaalde maintenance toch eens moeten testen. Het werkt in theorie wel, maar niet optimaal lijkt het.

ik ga eens zoeken. Thanks voor jullie hulp in ieder geval.