[Procurve 2910&Dell Equallogic]CRC Error/slechte performance

[Anoniem: 301987]

Situatie: 3 ESX servers, Dell Equallogic bak en 2 Procurve 2910's. ISCSI en Public LAN wordt gescheiden middels VLAN. Geen best practice, maar belasting is nihil
Equallogic poorten staan fixed op gigabit, met jumbo frames en flow control. Staat ook aan, aan de kant van de Equallogic. Storage VMotion gaat met een whoppin 1MB/s, switchen loggen CRC alignment errors.
Duplex mismatch zou je zeggen, maar dat kan bijna niet.

Iemand nog ideeen? Hierna wil ik ze even vervangen voor een zwaardere switch om die uit te sluiten, Procurve 3500

[SpamLame]

Hoe is je vmotion/management netwerk ingestelt?
Helpt een andere switchpoort (brak wellicht?) voor de EQ danwel ESX doos.

Je hebt het over 2 switches, is dat voor multipathing of is dat om dat ESX aan sw1 en de EQ aan sw2 zit?
Wellicht is de trunk/etherchannel tussen de twee switches niet goed (geconfigureerd)?

Ideeen zat maar het helpt als je vermeld (ook de uitkomst van) wat je zelf al geprobeerd en gecontroleerd hebt.

[Anoniem: 301987]

Is voor multipathing, zie onderstaand. De trunk is gedoublechecked, flow control aan en LACP based. Net schoot de storage vmotion door naar 60MB/s, vreemd, nu weer terug traag.
Kapotte poort is onwaarschijnlijk, het zou dan om dezelfde poort op 2 switches gaan



Had gister de trunk opnieuw aangemaakt just to be sure.

Oja bpdu-filtering staat aan op de trunk van VLAN10..geen STP daar dus

[ Voor 7% gewijzigd door Anoniem: 301987 op 18-09-2009 10:33 ]

[MoBi]

Staan aan de kant van de switch ook je poorten op fixed gig, anders heb je inderdaad duplex mismatch tussen je eq en switch en klopt het crc error probleem. Zet de eq en switches eens op auto klinkt raar maar werkt meestal wel. Officieel is autonegotiation namelijk verplicht bij gigabit.

[ Voor 29% gewijzigd door MoBi op 18-09-2009 13:08 ]

[Anoniem: 164444]

Procurve 2910 mag het probleem niet zijn qua capaciteit. Wat wel van belang is: Jumbo frames aanzetten heeft alleen zin als je het in de hele keten aanzet. Switches, storage server en hosts. Daar zit hem nou juist de clou: Officieel ondersteunt VMware geen jumbo frames op ESX 3.5, althans niet voor produktie. Wel in ESX 4 heb ik begrepen. Ik ga voor het vervolg even uit van ESX 3.5...
Bij één van onze klanten draait het prima met iSCSI en jumbo frames, je moet echter wel met een paar dingen rekening houden. MTU kun je alleen instellen bij het aanmaken van je virtual switch en je vmKernel adapter. Niet naderhand wijzigen. Maak dus een nieuwe virtual switch aan met een MTU van 9000, koppel daaraan je vmKernel interface, die je ook nieuw aanmaakt met MTU 9000, en koppel daaraan je externe iSCSI netwerk adapters. En inderdaad: zet alles gewoon op auto negotiate. Vast zetten kan altijd later nog in geval van problemen.

[Anoniem: 301987]

Thanks voor de tips, switch staat op auto-1000, en het is ESX 4.0. Wat jij zegt pbarends, is me inderdaad ook door Dell en HP gezegd, overal Jumbo aan of overal uit. Dat van de vmkernel was ik ook achter, dat is niet zo'n fijne optie dus

Ik zal de switch eens op auto "gewoon" zetten. Wel vreemd eigenlijk, heb in de netwerk-wereld altijd geleerd "auto=slecht", en het SAN kan ook eens iets anders dan Gigabit, wat weer alleen full-duplex kan zijn.
Kwam het elders ook tegen

Maar ga het zeker proberen! Nu de klant even inlichten...vanavond dan maar

[Predator]

Anoniem: 301987 schreef op vrijdag 18 september 2009 @ 15:38:
Ik zal de switch eens op auto "gewoon" zetten. Wel vreemd eigenlijk, heb in de netwerk-wereld altijd geleerd "auto=slecht", en het SAN kan ook eens iets anders dan Gigabit, wat weer alleen full-duplex kan zijn.
Kwam het elders ook tegen

Ik zet zelden of nooit speed/duplex settings fixed. Fixed settings hebben ook nadelen. Een mens vergeet soms ook de portsettings aan te passen als je eens kabels verzet en zo
Ik vind dat het evenveel problemen veroorzaakt als oplost, alleen kost het meer admin werk.
In de praktijk heb ik nog maar weinig gevallen gehad waar de auto-negotiation faalt.
IBM i-series zijn o.a. uitzonderingen.

Maar euh, waarom loop je gewoon niet eens de speed/duplex settings na van al je poorten ?

[axis]

Die fixed settings, dat was vroegah.. Bij Gigabit zou auto goed moeten werken. Ik zou zeker alles op auto zetten. (Heb ik ook op mijn serverpark met Dell servers, Equalogic units en Procurves).

Sowieso is dit volgens mij niet een architectuur naar Equallogic/VMware's best practices (althans niet voor ESX3.5), die raadde aan 2 switches met een stack te verbinden (tot 1 virtuele switch dus), en de nics in je VMware dozen te teamen/trunken. Maar helaas hebben de procurves geen stacking mogelijkheden (mijn 2848's althans niet), en kun je geen team maken (static lacp) over een team/trunk heen. (Daarom heb ik laatst ook 2 Cisco C3750G's gekocht om voor m'n EQL's te zetten). Maar ondanks dat zou je huidige oplossing volgens mij wel gewoon moeten werken..

Weet niet of deze setup al in productie staat, of je dat je nog naar hartelust kunt prutsen? Dan zou je eens kunnen proberen hoe het performed met een enkele switch. Eventueel met flow control en jumbo frames uit, en daarna een voor een flow control aan, en daarna jumbo frames aan..

Hoe zit het trouwens met de performance op de SRVAPP01? (Windows doos met MPIO?) Mount daar eens een volume op de PS4000E en laat eens een atto benchmark draaien? Hoe is de performance daar? Dan kunnen we in ieder geval uitsluiten dat het iets met ESX te maken heeft.

[Anoniem: 301987]

Heb net even ISCSI controller poorten(op de switch op) auto gezet. Het is een soort van productie, draait een enkele server op.
@Axis Ja het is inderdaad geen config die ideal is(fysiek scheiden zou mijjn keus geweest zijn) maarja het is verkocht...

Met geen enkele lowof en mid -endprocurve kun je trunks over meerdere switches laten lopen, dacht ik. Wou inderdaad één 3500 gaan zetten, maar ik zag dat een oudere 3500(die ik heb liggen) ongeveer net zo snel is als een nieuwe 2910. Maargoed

Gezien de errors op de switch lijkt ESX uit te sluiten, maar we kunnen het proberen...

[axis]

Gezien de errors op de switch lijkt ESX uit te sluiten, maar we kunnen het proberen...

Sja, je moet toch wat dingen uitsluiten.. Wat voor bekabeling heb je? Zelfgeknipte kabels, of molded kabels uit de fabriek? Cat5e neem ik aan?

Je zegt dat je switch crc alignment problemen logged, maar op welke poorten dan? Allemaal? En ja, zet flow control eens uit ja, kijken of dat nog iets uit maakt.

Trouwens nieuwste firmware in je switches staan? De procurves die ik koop hebben vaak oude firmwares erin, met alle bugs van dien. Firmwares kun je gratis downloaden van de hp site..

[Anoniem: 301987]

Thanks Axis. Heb ze met de laatste firmware weggezet, 14.29 uit het hoofd. Het zijn nieuwe cat5e kabels.

De errors doen zich voor op poort 18, de ISCSI controller. Ik zal flow control eens uitzetten....
Gisteravond tijdens de back-up zag ik ze nog elke minuut gelogd worden(poort op auto)

[axis]

Wat bedoel je met 'de iscsi controller'? Die EQL heeft 2 actieve poorten (en 2 op de standby controller), en als je meerdere luns benadert, stuurt de EQL er op aan dat de load gelijk verdeeld wordt over de nics..

Ik neem aan dat je meerdere luns (volumes in EQL terminologie) hebt aangemaakt, en daarop VMFS draait.. Start simultance benchmarks op guests die op verschillende luns draaien, en verifieer (bijvoorbeeld in de switch gui) dat de beide poorten goed benut worden. Hebben ze beiden problemen?

[Uberprutser]

axis schreef op vrijdag 18 september 2009 @ 22:42:
Die fixed settings, dat was vroegah

Een beetje offtopic maar ik zie het steeds vaker dat performanceproblemen opgelost zijn door alles op fixed te zetten ipv auto en met name op FD. Helaas heb ik van de rest van het onderwerp weinig kaas gegeten behalve op hobby basis.

[Zwelgje]

Ballebek schreef op zaterdag 19 september 2009 @ 18:26:
[...]

Een beetje offtopic maar ik zie het steeds vaker dat performanceproblemen opgelost zijn door alles op fixed te zetten ipv auto en met name op FD. Helaas heb ik van de rest van het onderwerp weinig kaas gegeten behalve op hobby basis.

volgens IEEE normering mag gbit ethernet niet op fixed full worden gezet. letwel: het kan wel, het werkt ook wel maar het is niet supported op alle apparatuur.

Wikipedia: Gigabit Ethernet

http://standards.ieee.org...E802.3af-2003interp-6.pdf

als je perse wilt dat ze alleen gbit met elkaar kletsen pas je toch de 'advertising speed' aan dat hij alleen gbit adverteerd dan heb je netjes auto neg. en kunnen ze alleen gbit onderhandelen

[FatalError]

Voor de snelheid maakt het geen fluit uit of je Autonegotiation doet op gigabit full duplex, of dat je hem fixed instelt. Maar als een van de kanten fixed staat werkt autonegotiation niet meer en gaat ie automatisch op half-duplex werken. Dat is heel erg slecht voor je snelheid. Je ziet dat dus ook terug in de switch... CRC en alignment erros zijn vrijwel altijd het gevolg van een duplex mismatch.

[CyBeR]

Gigabit ethernet over koper kun je niet echt instellen, autonegotiation is verplicht. (Volgens de standaard, als fabrikanten zich daar niet aan houden is 't wat anders natuurlijk). Dit omdat er gebruik wordt gemaakt van een master/slave systeem aangaande een clock, en dat moet genegotiate worden.

Gigabit over fiber kun je wel hard instellen.

[Anoniem: 301987]

axis schreef op zaterdag 19 september 2009 @ 18:20:
Wat bedoel je met 'de iscsi controller'?

Actieve poorten zijn verdeeld over 2 switches, vandaar. IOmeter op de SRVapp01 gedraaid, steady 130MB/s, 2 uur lang. Aandacht gaat nu naar de Vswitches...

[Anoniem: 301987]

Dell beweert dat het aan de gebrekkige buffers op de 2910al(6mb 0,25mb per port) ligt. Alleen de 3500 en 5400(met >36mb) worden ondersteund.
Lijkt mij sterk verhaal, ben mensen tegengekomen die een 2824 gebruikten, met verouderde chipset en minder geheugen.
Kijken wat Procurve hierop zegt
Morgen kunnen we verder testen.

[axis]

Ben geen export op dat gebied, maar dat is ook de reden dat ik tussen mijn EQL's 2 Cisco C3750G's heb gekocht, de 2848's die ik heb liggen schijnen het ook niet zo goed te doen..

Maar dan nog, zonder flow control en jumbo frames moet je best wel een respectabele snelheid kunnen halen, zonder dat de performance instort. Meten is weten..

[Anoniem: 301987]

Het gaat dus meer om de CRC errors, performance is daar weer het gevolg van. Nu een setup zonder jumbo frames en met een enkele switch, gaat op zich goed. Maar we verliezen paden naar de storage 's-nachts.

Dell wil geen 2910AL ondersteunen, wel hun eigen "ISCSI optimized" switch. Voor de gein specs naast elkaar


Dell Powerconnect Procurve 2910 AL
Switch Fabric 48 GBPS 128GBPS
Forwarding rate 35.6Mpps 95.6Mpps
CPU SDram 64mb 512mb
Packet buffer size 6MB 6MB
Mac address table size 8000 16.000

[FatalError]

Heb je enkel CRC errors of ook collisions?

[Anoniem: 301987]

Geen collissions, wel retransmits op de Dell Equallogic.
Net 24 uur jetstress gedraaid op een 3500yl....gaat wel goed

[Anoniem: 301987]

2910 AL ondersteund officieel wel jumbo én flow control. Maar dat ging dus niet goed.
Op de linker controller van de dell uberhaupt nog geen fouten.

Lijkt dus een combinatie tussen
- 2910 al niet geschikt voor jumbo/flow control/niet zo'n fantastische packet buffer
- muffe controller

[Anoniem: 301987]

Dell heeft een nieuwe controller gestuurd, kijken wat dat brengt

[Master_duck]

Meschien een domme vraag maar heb je wel "spaning tree" goed ingesteld op je root switch?
kan je wel een raare dingen op je netwerk gebeuren, aan gezien je de 3 procurves in een loop staan

en wat ik op een andere forum vond:
"Understanding BPDU Filtering

The BPDU filtering feature can be globally enabled on the switch or can be enabled per interface, but the feature operates with some differences.

At the global level, you can enable BPDU filtering on Port Fast-enabled interfaces by using the spanning-tree portfast bpdufilter default global configuration command. This command prevents interfaces that are in a Port Fast-operational state from sending or receiving BPDUs. The interfaces still send a few BPDUs at link-up before the switch begins to filter outbound BPDUs. You should globally enable BPDU filtering on a switch so that hosts connected to these interfaces do not receive BPDUs. If a BPDU is received on a Port Fast-enabled interface, the interface loses its Port Fast-operational status, and BPDU filtering is disabled.

At the interface level, you can enable BPDU filtering on any interface by using the spanning-tree bpdufilter enable interface configuration command without also enabling the Port Fast feature. This command prevents the interface from sending or receiving BPDUs. "

basically still sends them out initially.

however ED I have to ask why turn on bpdu filter on a trunk? by the nature of a trunk port you are connecting to another switch and therefore risk causing a loop and bringing the world to an end!

Try the same but using it an an access port.

I did a quick test two trunk links with BPDU gaurd, no shuts and they go in to shutdown (BPDU violation)

o ja de source:
http://www.techexams.net/...ess-bpdus-being-sent.html

[ Voor 83% gewijzigd door Master_duck op 17-10-2009 10:27 ]

[Anoniem: 301987]

Even een terugkoppeling: controller #1 van de equallogic vervangen, sindsdien geen problemen meer.

Slechte support van Dell. "Zoek het maar uit". Maar na lang zeuren een nieuwe gekregen en wat blijkt.....jammer dat we al die uren nooit meer terugkrijgen+overlast voor de klant

[DukeBox]

Anoniem: 301987 schreef op woensdag 07 oktober 2009 @ 12:02:
Dell heeft een nieuwe controller gestuurd, kijken wat dat brengt

Sorry van het kicken van dit topic, maar toevallig loop ik tegen exact hetzelfde probleem aan.
2x 2910 met een 10GB interconnect. Aan deze 2 switches hangen 5 EQL's: 2xPS100 1xPS6000 in 1 groep en 1xPS100 met een 1xPS4000 in een andere (test) groep.
Op geen van de poorten problemen behalve waar de PS4000 aan hangt. nu heb ik ook een nieuwe controller gekregen en daarvan is 1 poort nu zonder CRC errors, maar de 2e nog wel, ging het bij jou ook om een PS4000 ?