HP Proliant DL380 G7 - Data corruptie op netwerk poorten

[Q]

Hallo,

Helaas heb ik moeten mee maken dat over de periode van een week data op onze server corrupt raakte door een flaky HP server. Ik heb uitgebreid getest met md5sums etc en uiteindelijk was corruptie van netwerk verkeer aantoonbaar. File systems waren prima in orde, geen storage issue.

Feit is dat de machine niet de laatste firmware draaide en ook niet de meest recente VMware versie.

Ik ben eigenlijk benieuwd of anderen dit ooit wel eens hebben meegemaakt en hoe ze er mee zijn omgegaan. Ik zelf heb tegen management gezegd dat ik de server niet meer vertrouw en als ik er niet achter kom wat de oorzaak was (die kans is aanzienlijk) dan vertrouw ik die server nooit meer en wil ik er geen productie meer op draaien.

Natuurlijk kun je het ding updaten qua firmware, en VMware, maar wie zegt dan dat het probleem van data corruptie niet meer voorkomt? Patchen en dan maar fingers crossed dat het niet meer voor komt? Met data corruptie wil ik echt geen risico nemen.

Wat mij betreft komt er een nieuwe server.

[Equator]

Kan je uitleggen wat voor probleem je ervaart? Want en netwerk kan wel eens lastig doen maar op meerdere lagen in het netwerk wordt er gecontroleerd of er niets fout gaat..

[mookie]

Hij refereert denk ik aan zijn vorige topic over dfs.
Daarin kreeg hij data corruptie op bestanden en dacht dat het aan DFS lag maar het bleken allemaal door VMs the komen van die machine.
Maar ik kon me er ook niet zoveel bij voorstellen.

Zie je op die VMs in de eventlog niet iets van delayed write failed meldingen?
Is eigenlijk het enigste wat ik me voor kan stellen.

Hoe heb je eigenlijk getest dat het aan het netwerk verkeer ligt?
Gesniffed en daar iets bijzonders in gezien?

[Q]

De achtergrond was mijn DFS topic ja.

SSH file transfers naar VMs geven packet corrupt fout meldingen. Binnen Windows kregen we ook unexpected exceptions en dan was de md5sum van de file onjuist. Ik heb omwille van de tijd geen packet capture gemaakt, wat achteraf wel jammer is, want dan hadden we het exacte gedrag kunnen zien.

Het punt is dat het problemen alleen optraden op deze specifieke host en dat VMs op deze host onderling geen data corruptie problemen ondervonden, omdat het netwerk verkeer dan nooit de host verlaat. Het zou nog iets kunnen zijn op de switch. Zelfs de iLO interface van de machine was niet meer bereikbaar. Ook niet in een andere switchpoort. Een vmotion van VMs op het getroffen systeem naar een betrouwbaare host loste alle problemen op. Een vmotion terug van een test system liet weer problemen zien.

ik heb een hele excel spreadsheet ingevuld met tests tussen hosts en het patroon matchte precies de voorspelling.

Maar al heb ik het helemaal mis. De vraag is eigenlijk: hoe ga je om met een server die data corruptie vertoond op de netwerk interfaces.

Mijn stelling is dan: als je niet de oorzaak kan aantonen en aantoonbaar weet op te lossen, dan is deze server voor altijd onvertrouwd en niet langer geschikt voor productie. Als je het risico toch wil nemen vanwege de kosten, so be it, maar hoeveel kosten brengt data corruptie met zich mee?

[ Voor 19% gewijzigd door Q op 27-11-2013 16:47 ]

[twiekert]

Ik zou toch eerst wat diag tools van HP draaien om te kijken wat die zeggen. Zoals Equator al zegt kan het op verschillende lagen misgaan, kapotte netwerkchips/bug in firmware, vmware driver, os driver.

Als de HP tools al aangeven dat er wat mis is dan is het een kwestie van firmware update uitvoeren, en daarna weer de HP tools draaien. Als het dan nog mis is garantie claimen bij HP of bruikbare onderdelen eruit en dan > prullenbak.

[Q]

Het ging mij meer om het principe. Zolang je de oorzaak niet weet kun je een machine met een history van data corruptie niet meer inzetten.

De HP tools geven zoals ik wel verachtte geen errors.

[ Voor 17% gewijzigd door Q op 28-11-2013 09:31 ]

[RedShift]

Probeer eens met netcat of iperf3 een bestand over te zetten, neem daarna de sha1 sum van beide bestanden, dit zou moeten hetzelfde zijn. Doe dit met een laptop of whatever die direct verbonden is, om zo stapgewijs het één en het ander uit te sluiten.

[bigfoot1942]

Q schreef op donderdag 28 november 2013 @ 09:31:
Het ging mij meer om het principe. Zolang je de oorzaak niet weet kun je een machine met een history van data corruptie niet meer inzetten.

De HP tools geven zoals ik wel verachtte geen errors.

Hmz, om het op detailniveau te pinpointen; je vertrouwt de NIC van die server niet meer.
Verkeer tussen de VM's ging wel goed, het ging mis wanneer de VM naar buiten communiceerde (over de NIC).
Gooi er een andere NIC in (bij voorkeur ander merk), extra testje en gaan.
Nics kunnen ook stuk (of firmware of drivers)

[Ethirty]

Wij hebben zelf en bij klanten 10-tallen G7's draaien, zowel met VMware als met HyperV. Maar wat jij beschrijft heb ik gelukkig nog niet meegemaakt.

Ik zou sowieso zsm firmware en ESXi updaten, dan pak je ook gelijk de bijgewerkte drivers van HP mee. Om de server nu gelijk als "schroot" te bestempelen en een nieuwe te kopen lijkt mij niet alleen overdreven, maar ook onnodig kostbaar.

[Q]

Dat is waarschijnlijk waar het op uit gaat draaien, maar die keuze laat ik aan de business over. Zij mogen kiezen. Ik heb ontdekt dat er een critical firmware is die ontbreekt en die mogelijk hier mee te maken kan hebben (als in 'mogelijk' maar ik heb geen bewijs/idee).

[Dennism]

Waarom test je het niet gewooon ipv de server af te schrijven (zit er trouwens geeen garantie meer op?). Ik zie weinig G7's die al uit garantie zijn (ivm meestal verlengen carepack).

Mocht ie al weel uit garantie zijn. Haal em uit productie, en daarna uitgebreid testen (firmwares updaten, laatste VMware erop), test setup na bouwen waarmee je in productie het probleem hebt. Wanneer ie dan wel weer goed werkt een besluit nemen, terug in productie, of preventief vervangen en voor een ander doen inzetten (beheer server, test server). Wanneer ie nog steeds niet goed werkt, nic's uitschakelen, deze vervangen en wederom testen.

Dat de ilo onbereikbaar was kan een volledig andere oorzaak hebben, ik heb gemerkt dat alle ILO3 firmwares onder de 1.28 (huidige is 1.61 geloof ik) niet echt betrouwbaar zijn, deze dus ook snel upgraden als deze nog onder de 1.28 is. Van de week zelf eenn zelfde issue gehad met eenn G7 die nog op 1.10 draaide, niet meer te bereiken via netwerk behalve via SSH. via SSH firmware geupgrade (1.10 naar 1.26, 1.26 naar 1.61) en het draaide weer als een zonnetje. De 1.26 is een verplichte tussenstap anders misluke (iig bij mij) de upgrade.

[ Voor 3% gewijzigd door Dennism op 30-11-2013 22:28 ]

[Gomez12]

Q schreef op woensdag 27 november 2013 @ 16:37:
Maar al heb ik het helemaal mis. De vraag is eigenlijk: hoe ga je om met een server die data corruptie vertoond op de netwerk interfaces.

Als hij aantoonbaar data corruptie vertoond op de NIC dan de NIC vervangen (en alle bijbehorende spullen)

Mijn stelling is dan: als je niet de oorzaak kan aantonen en aantoonbaar weet op te lossen, dan is deze server voor altijd onvertrouwd en niet langer geschikt voor productie. Als je het risico toch wil nemen vanwege de kosten, so be it, maar hoeveel kosten brengt data corruptie met zich mee?

Zolang je de oorzaak niet weet aan te tonen gewoon verder zoeken. Hier wordt er juist niets afgeschreven zonder een duidelijke oorzaak (anders kunnen we bezig blijven, als ik moet gaan bedenken hoeveel stagaires gezegd hebben dat de test-bak stuk is...)

Momenteel heb je simpelweg niet goed onderzocht imho, getuige :

Feit is dat de machine niet de laatste firmware draaide en ook niet de meest recente VMware versie.

Voordat iets hier defect verklaar wordt is stap 1 toch wel alles op laatste nivo brengen en stap x is dan alsnog de hele server reinstallen (waardoor je automatisch de laatste versies krijgt)

Als ik jouw onderzoek zo zie gok ik dat het ook nog gewoon aan de driver kan liggen. Oftewel nog genoeg softwarematige dingen om te testen voordat je een nieuwe server krijgt.

[Q]

Als een server gewoon zou uitvallen, so be it. Maar we spreken hier over data corruptie. Als je daar mee gaat gokken dan kan de schade veel groter zijn.

Als er na een reboot geen data corruptie meer is, hoe ga je dan ooit verifieren dat het probleem weg is? Dus ga je gokken, dat een firmware etc. het probleem zal oplossen. Met het risico dat je dan weer data corruptie krijgt. Als management daarmee wil gokken: hun keuze, niet de mijne.

De business wil wel even aanzien of we kunnen achterhalen wat de oorzaak was, maar als we daar niet achter komen, komt er een nieuwe machine. 8K is niet echt een bedrag dat een issue is voor onze size, maar we hoeven het ook niet nodeloos weg te gooien als de oorzaak aan te tonen en op te lossen valt.

[ Voor 7% gewijzigd door Q op 03-12-2013 14:01 ]

[SkiFan]

Heb zoiets ooit ook gehad, weliswaar een kloon, maar toch. Netwerkadapter vervangen en het problem was opgelost.

[Ethirty]

Q schreef op dinsdag 03 december 2013 @ 14:00:
Als een server gewoon zou uitvallen, so be it. Maar we spreken hier over data corruptie. Als je daar mee gaat gokken dan kan de schade veel groter zijn.

Als er na een reboot geen data corruptie meer is, hoe ga je dan ooit verifieren dat het probleem weg is? Dus ga je gokken, dat een firmware etc. het probleem zal oplossen. Met het risico dat je dan weer data corruptie krijgt. Als management daarmee wil gokken: hun keuze, niet de mijne.

De business wil wel even aanzien of we kunnen achterhalen wat de oorzaak was, maar als we daar niet achter komen, komt er een nieuwe machine. 8K is niet echt een bedrag dat een issue is voor onze size, maar we hoeven het ook niet nodeloos weg te gooien als de oorzaak aan te tonen en op te lossen valt.

Snap ik. Maar datacorruptie kan ook onstaan door een slechte firmware op een RAID controller of harddisk. Ga je daar de firmware dan ook niet van updaten als in de release notes staat dat ze daaraan gewerkt hebben? En wie zegt dat de nieuwe server die je koopt ook niet een probleem in andere firmware heeft of gaat krijgen?

HP stelt niet voor niks dat je voor het inschakelen van support eerst alle firmware en drivers moet bijwerken, omdat veel fouten daarmee kennelijk al verholpen worden. Ik snap niet dat je ondertussen niet al een uurtje hebt uitgetrokken om de firmware te updaten. HP heeft dat zo simpel gemaakt. DVD'tje downloaden, rebooten, wachten, klaar!

[Dennism]

Q schreef op dinsdag 03 december 2013 @ 14:00:


Als er na een reboot geen data corruptie meer is, hoe ga je dan ooit verifieren dat het probleem weg is? Dus ga je gokken, dat een firmware etc. het probleem zal oplossen. Met het risico dat je dan weer data corruptie krijgt. Als management daarmee wil gokken: hun keuze, niet de mijne.

Daarom haal je de server ook uit productie en ga je uitgebreid testen in een na gebouwde situatie waarin eerderr het probleem optrad. Als je het testen zelfs heel secuur wil doen kun je zelfs alle firmwares los installeren en na iedere update testen om te kijken of het probleem opgelost is.

Sneller is natuurlijk gewoon alle firmwares upgraden (is zelfs best practise bij HP om dit regelmatig uit te voeren), hierna te testen om te kijken of het probleem opgelost is.

Goed gecontroleerd testen is heel wat anders dan gokken

Voor 8K kun jij heel wat meer uurtjes testen, mocht de machine nog te redden zijn dan dat je nodig hebt om het probleem vast te stellen

[ Voor 7% gewijzigd door Dennism op 03-12-2013 19:19 ]

[ivocare]

Ja,

Ook wel een keer meegemaakt. Exact zelfde type server. Helaas wel tot gevolg dat er VM's corrupts geraakt zijn. Via backup de VM restores uitgevoerd en inderdaad server eruit gehaald.

Ik kan je zeggen, ik werd hier niet vrolijk van met een nogal actieve vMotion omgeving!

Het was trouwens een van de NIC's naar het SAN.

[ Voor 8% gewijzigd door ivocare op 03-12-2013 19:24 ]

[Gomez12]

Q schreef op dinsdag 03 december 2013 @ 14:00:
Als een server gewoon zou uitvallen, so be it. Maar we spreken hier over data corruptie. Als je daar mee gaat gokken dan kan de schade veel groter zijn.

Als er na een reboot geen data corruptie meer is, hoe ga je dan ooit verifieren dat het probleem weg is?

Hoe je dat gaat verifieren is heel simpel : Op dezelfde manier als dat je met een nieuwe server gaat doen...

Of is het wellicht toch zo dat je gokt dat de nieuwe server het niet heeft?

Daarom is bij ons het devies : doorzoeken, als je dan een reproduceerbare test-situatie hebt gecreeerd dan is het gelijk ook voor alle nieuwe servers een te testen scenario.

Ik heb daadwerkelijk een paar servers met data-corruptie gehad, maar de oorzaken waren heel divers (zo was er bijv 1 die optrad bij een bepaalde driver versie, kernel versie x en als je x bytes over de draad had gegooid, dan konden we wel een nieuwe server neerzetten maar die zou dezelfde driver versie gekregen, dezelfde kernel versie en die zou dus ook na x tijd datacorruptie gaan vertonen)
Maar in de praktijk ben ik het heel erg weinig tegengekomen dat datacorruptie aan fatsoenlijke hardware lag.

Natuurlijk kan het in jouw geval aan de hardware liggen, maar zonder testmethode weet je niet of de nieuwe server er geen last van heeft.

[Q]

Helemaal mee eens, maar mijn punt is: als het niet lukt om het issue te reproduceren, dan weet je nooit wat de oorzaak is geweest. Het is waar dat je dan ook niet weet of FW updates of andere hardware het probleem verhelpen. Het blijft allemaal gokken zolang je niets kunt reproduceren. Inderdaad is nieuwe hardware dan ook een gok.

[Gomez12]

Wat bedoel je met : Het lukt niet om het issue te reproduceren?
In je Topicstart zeg je dat het aantoonbaar is, dat lees ik als : 100% reproduceerbaar.

Wellicht dat je nog niet het probleem kan pinpointen, maar dat is dan enkel nog een kwestie van testen.

Kijk, ik heb geen idee wat jullie beleid qua servers en software is, maar als er straks een nieuwe server binnenkomt en die krijgt een nieuwere FW en een nieuwere VMWare versie dan weet je helemaal niets meer.
Als je dan over 2 maanden hetzelfde probleem bij een andere server krijgt, wat dan? Ook maar nieuwe server en preventief het hele server park maar weer vervangen?

Kijk je moet het helemaal zelf weten, maar (zoals je zelf al zei) met data-corruptie zou ik niet snel gaan gokken en die nieuwe server is een heel grote gok als je geen idee hebt waar het inzit.

[Onbekend]

Heb je toevallig ook network teaming geactiveerd?

[Q]

@Gomez12: sorry voor de onduidelijkheid: het was op moment van de storing 100% reproduceerbaar, maar na een reboot van de host niet meer. Op het moment van storing was ook iLO niet meer bereikbaar. Dus niet alleen puur de 'getroffen NICS'. UTP ompluggen in andere switches hielp niet. iSCSI storage die via 10Gbit nics loopt, was niet getroffen, op dat vlak geen data corruptie.

Zoals ik verwachtte gaf de HP diagnostics nul problemen.

Network teaming was niet geactiveerd naar mijn weten. Wel failover in vmware.

Ik zit dus nu met een host die data corruptie gaf maar na een reboot weer 'goed' werkt. Ik heb dit geverifieerd door met 1 test VM wat data heen en weer te kopiëren. O.a. met dd netcat en dan verificatie met md5. Ook getest met scp enzo.

De machine draait dus nu weer OK, maar er is niets veranderd, dus niets opgelost. Dit kan weer voorkomen. Er is wel een firmware update van toepassing op de 'getroffen' nics die als critical wordt bestempeld en ik gemist heb. Die gaat niet over data corruptie maar wel over 'disconnects'. Mogelijk dat er een relatie is.

Maar de firmwares updaten + vmware updaten wil niet zeggen dat het dan over is. Je kunt het aannemelijk maken, maar het blijft gissen en data corruptie is iets waar je niet mee wilt gokken.

Maar waarom valt iLO uit als het issue betrekking heeft op totaal andere hardware? Dat zint mij niet. iLO is een soort van embedded mini computer die totaal stand-alone zou moeten draaien, ongeacht de toestand van de host.

[ Voor 69% gewijzigd door Q op 07-12-2013 13:59 ]

[Dennism]

Mijn eerdere post nog gelezen, mocht je oude ILO firmware draaien dan is dat een bekend probleem.

Dat de ilo onbereikbaar was kan een volledig andere oorzaak hebben, ik heb gemerkt dat alle ILO3 firmwares onder de 1.28 (huidige is 1.61 geloof ik) niet echt betrouwbaar zijn, deze dus ook snel upgraden als deze nog onder de 1.28 is. Van de week zelf eenn zelfde issue gehad met eenn G7 die nog op 1.10 draaide, niet meer te bereiken via netwerk behalve via SSH. via SSH firmware geupgrade (1.10 naar 1.26, 1.26 naar 1.61) en het draaide weer als een zonnetje. De 1.26 is een verplichte tussenstap anders misluke (iig bij mij) de upgrade.

[ Voor 5% gewijzigd door Dennism op 07-12-2013 14:41 ]

[Ethirty]

Q schreef op zaterdag 07 december 2013 @ 13:43:
Maar de firmwares updaten + vmware updaten wil niet zeggen dat het dan over is. Je kunt het aannemelijk maken, maar het blijft gissen en data corruptie is iets waar je niet mee wilt gokken.

Natuurlijk geeft het geen garanties, maar je lijkt nu gewoon te weigeren de firmware te willen updaten. Het is een simpele manier om een mogelijke oorzaak uit te sluiten. Als ik elke firmware update van harddisks had gekozen voor het kopen van een nieuwe disk, dan waren we nu allang failliet

[Q]

Dat de iLO onbereikbaar was kan inderdaad een andere oorzaak hebben, mogelijk was deze al onbereikbaar voordat de hele ellende begon, zo vaak gebruiken wij die interface niet.

Als ik de firmware update kan ik nooit meer aantonen dat het ook de oorzaak van het incident was, behalve dan door maar weer productie te draaien en de vingers gekruist te houden.

Als ik nu met de oude firmware het issue kan reproduceren en na de nieuwe firmware niet meer, dan ben ik behoorlijk zeker dat ik het data corruptie issue heb opgelost.

Een interessante aanwijzing dat de oude firmwares de oorzaak zijn is deze advisory:

c02964542 - FIRMWARE UPGRADE REQUIRED to Avoid the Loss and Automatic Recovery of Ethernet Connectivity or Adapter Unresponsiveness

Als ik nu de machine qua firmware helemaal up-to-date maak zonder bewijs dat hier de oorzaak lag, dan gok ik het er maar op dat dit de problemen oplost. Ik denk dat die kans best groot is, maar het blijft een risico en de business moet dat wel snappen en de optie om te kiezen. Ik zou de gok acceptabel vinden, het is ook niet mijn geld, was het mijn data, dan zou ik de gok niet nemen.

Mijn les is vooral dat je critical advisories moet opvolgen en doorvoeren en niet moet laten liggen. Als de firmware daadwerkelijk de oorzaak was, dan was deze ellende nooit voorgekomen. Hoe stom het ook klinkt, maar zo'n officieel proces is er bij ons niet en met alle drukte heb ik er ook onvoldoende aandacht aan besteed.

[ Voor 60% gewijzigd door Q op 07-12-2013 17:19 ]

[Dennism]

Volgens mij kan je, als je een HP account hebt je ergens inschrijven voor HP alerts. Ik krijg volgens mij altijd netjes een mailtje als er weer een proliant update pack update uitgebracht is.

[Ethirty]

Klopt, je kan aangeven welke hardware je hebt en je ontvangt alleen daarvan de alerts.
Er zijn een aantal niveau's van updates ook. In ieder geval required (als in zsm, want bug fixes) en recommended (eerder features dan bug fixes)

HP brengt de criticals uit als er genoeg meldingen zijn vanuit de klantenkring dat er problemen zijn en/of ze dit zelf hebben kunnen nabootsen en oplossen. Je mag er dus redelijkerwijs van uit gaan, dat als je vergelijkbare problemen ervaart, dat de update deze verhelpt of op zijn minst sluit je uit dat die betreffende bug bij jou van toepassing is.

[TAMW]

Q schreef op dinsdag 26 november 2013 @ 21:45:
Hallo,

Helaas heb ik moeten mee maken dat over de periode van een week data op onze server corrupt raakte door een flaky HP server. Ik heb uitgebreid getest met md5sums etc en uiteindelijk was corruptie van netwerk verkeer aantoonbaar. File systems waren prima in orde, geen storage issue.

Feit is dat de machine niet de laatste firmware draaide en ook niet de meest recente VMware versie.

Ik ben eigenlijk benieuwd of anderen dit ooit wel eens hebben meegemaakt en hoe ze er mee zijn omgegaan. Ik zelf heb tegen management gezegd dat ik de server niet meer vertrouw en als ik er niet achter kom wat de oorzaak was (die kans is aanzienlijk) dan vertrouw ik die server nooit meer en wil ik er geen productie meer op draaien.

Natuurlijk kun je het ding updaten qua firmware, en VMware, maar wie zegt dan dat het probleem van data corruptie niet meer voorkomt? Patchen en dan maar fingers crossed dat het niet meer voor komt? Met data corruptie wil ik echt geen risico nemen.

Wat mij betreft komt er een nieuwe server.

Niet toevellig deze issue:

Possible data corruption after a Windows 2012 virtual machine network transfer (2058692)

[Q]

Wij passen geen 2012 toe momenteel.

[MrJ]

Hier idd ook meegemaakt.

Vage issues op een VM die niet met de standaard tools te pinpointen waren. Uiteindelijk na een fysieke disconnect (kabeltjes lostrekken) de defecte NIC gevonden en deze niet meer gebruikt.

Geen repair gedaan aangezien er toen op korte termijn al een hardware refresh van de hypervisors aankwam.

[RobBosman]

Als je VMWare op je servers draait heeft HP ook het HP VMWare - recipe. Dat komt elke paar maanden uit en er staat dan precies voor elk type server op welk niveau je moet zitten qua bios/firmwares.
Als je het laatste SPP van juni draait dan zit je sowieso goed.
Wel is het aan te rade om niet meer dan 1 SPP versie over te slaan wanneeer je gaat updaten, houdt daar even rekening mee wanneer je aan het updaten gaat om problemen te voorkomen.

Ps. Excuses voor omhoog kicken van topic had niet gezien dat het al zo oud was.

[ Voor 8% gewijzigd door RobBosman op 14-08-2014 21:09 ]