Berichten

Hyper-V cluster shared volume iscsi errors and event ID 20 and event ID 34

De gehele avond besteeds aan e.e.a. aan problematiek inzake een Hyper-V Cluster Shared Volume omgeving. De feiten:

Stroomuitval
Alles is herstart en er blijven problemen. Een node opbrengen helpt niet, meerdere nodes ook niet. Allemaal komen ze met dezelfde events 20 en 34

Event 20:
Connection to the target was lost. The initiator will attempt to retry the connection.

Event 34:
A connection to the target was lost, but Initiator successfully reconnected to the target. Dump data contains the target name.

Wat kwam er nog meer voorbij (sorry,  het is 03:30 ’s nachts) o.a.:

STOP 0x0000009E zie hiervoor:
http://blogs.technet.com/b/askcore/archive/2009/06/12/why-is-my-2008-failover-clustering-node-blue-screening-with-a-stop-0x0000009e.aspx

Dit zegt feitelijk “Alles wijst naar het cluster, maar het bevind zich op een diepere laag”. Als we dit combineren ga je ervanuit dat e.e.a. met elkaar te maken heeft.

Verder hadden we nog de volgende error:
“Cluster resource ‘Cluster Disk 1’ (resource type ”, DLL ‘clusres.dll’) either crashed or deadlocked”

Maar dit gaat “veel dieper” dan de laag waarop ik het vermoeden heb (had ;)).

Uiteindelijk was alles te herleiden naar de stroomuitval. De iSCSI switches waren niet gevoed en die vielen direct uit. Wat is er gebeurd, de switches zijn de config’s verloren en de “Jumbo frames” setting is verloren gegaan. Je raad al wat er gebeurt, de verbindingen gaan staan klapperen en dus “disken” ook. Wel contact, geen contact, enz. enz. De hosts stonden op 9000, het SAN ook, behalve de switches…..

Aanpassen en alles liep weer :)

hoe een BSOD (blue screen of death) en memory.dmp probleem op te lossen

Gelukkig komt het steeds minder vaak voor, maar helaas nog vaak genoeg. Pc’s die spontaan (ogenschijnlijk zonder reden) herstarten, servers, of beide die niet herstarten maar wel een blauw scherm met getallen en letters geven. Vrijwel altijd is er een memory.dmp file aanwezig in c:\windows\system32\memory.dmp. Als deze niet aangemaakt word kan dit ingesteld worden dat deze volgende keer _wel_ aangemaakt word en het apparaat niet zomaar opnieuw start zodat je als gebruiker weet dat de machine “vastgelopen” is.

Vaak kan je met de stop code al een hoop achterhalen, zoals b.v. stop 0x0000007B een “inaccesible boot device” betekent. Dit kan een beschadigde HD zijn (gebruik dan chkdsk) of de chipset word niet herkend (b.v. na het clonen van een hd) of er is iets met de windows installatie door b.v. een virus. Gebruik dan de windows recovery console.

Maar wat als dit het allemaal niet is?! Dan kunnen we de Memory.dmp file gebruiken om het geheugen op het moment van crashen uit te lezen om te zien welke applicatie, dll, driver o.i.d. verantwoordelijk hiervoor gehouden kan worden.

Deze kan vervolgens geupdate worden, vervangen, dan wel verwijderd (of de .dll of .exe renamen omdat de applicatie waarvan deze was niet meer geinstalleerd staat).

Kijk hier voor meer informatie en een duidelijk omschrijving hoe e.e.a. in zijn werk gaat: 
http://blogs.techrepublic.com.com/window-on-windows/?p=1922