Hoe om te gaan met PSOD – Het paarse scherm des doods

This article is available in the following languages:

‍

‍‍‍

‍

‍

Inhoud

Wat is PSOD? 

Waarom gebeurt het?

Wat is de impact?

Wat doe je als het gebeurt?

Hoe voorkom je het?

TL;DR

Het meest storende aspect van een PSOD is dat het je vertrouwen in je infrastructuur doet verliezen en de ongerustheid die dat teweegbrengt laat groeien. Zolang je de hoofdoorzaak niet oplost, kan de gedachte dat dit opnieuw of op een andere server kan gebeuren je 's nachts wakker houden.

Gebruik Runecast Analyzer (gratis proefversie) om te controleren of één van uw hosts wordt beïnvloed door omstandigheden die het VMware paarse scherm des doods kunnen veroorzaken.

Wat is PSOD?

PSOD staat voor Purple Screen of Diagnostics, vaak aangeduid als Purple Screen of Death (afgeleid van het meer bekende Blue Screen of Death dat soms voorkomt bij Microsoft Windows).

Het is een diagnosescherm dat door VMware ESXi wordt weergegeven wanneer de kernel een fatale fout detecteert waarvan hij niet veilig kan herstellen, of die hij niet kan blijven uitvoeren zonder een veel groter risico op groot. 

Het toont de geheugenstatus op het moment van de crash en ook extra details die belangrijk zijn bij het oplossen van de oorzaak van de crash: ESXi versie en build, exception type, register dump, backtrace, server uptime, foutmeldingen en informatie over de core dump (een bestand gegenereerd na de fout, met verdere diagnostische informatie). 

Dit scherm is zichtbaar op de console van de server. Om het te kunnen zien, moet je ofwel in het datacenter zijn en een monitor aansluiten, ofwel op afstand het out-of-band beheer van de server gebruiken (iLO, iDRAC, IMM... afhankelijk van je leverancier).

WIST U DAT? 

Het scherm wordt aangeduid als paars of roze, maar in feite is de kleur  donker magenta (RGB:171,0,171 | CMYK:0.00, 1.00, 0.00, 0.33) 

Waarom gebeurt PSOD? 

De PSOD is een kernel panic. Hoewel we allemaal weten dat ESXi niet op UNIX gebaseerd is, past de panic-implementatie in de UNIX-definitie. De ESXi-kernel (vmkernel) zet deze veiligheidsmaatregel in werking als reactie op een gebeurtenis/fout die niet meer te herstellen is en waardoor het blijven draaien een groot risico zou vormen voor de diensten en VM's. Eenvoudig gezegd: als de ESXi-host voelt dat hij corrupt is geworden, pleegt hij "seppuku" en schrijft hij, terwijl hij zijn paarse bloed laat bloeden, een zelfmoordbrief waarin hij gedetailleerd beschrijft waarom hij dat deed!

De meest voorkomende oorzaken van een PSOD zijn:

1. Hardwarestoringen, meestal RAM of CPU gerelateerd. Ze geven gewoonlijk een "MCE" of "NMI" foutmelding. 

• "MCE" - Machine Check Exception, een mechanisme in de CPU om hardwareproblemen op te sporen en te melden. De codes op het paarse scherm bevatten belangrijke details om de oorzaak van het probleem te achterhalen. 
• "NMI" - non-maskable interrupt, dit is een hardware interrupt die niet genegeerd kan worden door de processor. Aangezien een NMI een zeer belangrijke melding is over een HW fout, is de standaard reactie vanaf ESXi 5.0 en later het triggeren van een PSOD. Eerdere versies logden gewoon de fout en gingen verder. Net als bij MCE's geeft een paars scherm veroorzaakt door een NMI belangrijke codes die cruciaal zijn voor troubleshooting.

2. Software fouten

• onjuiste interacties tussen ESXi SW-componenten (ex: KB2105711)
• race conditions (ex: KB2136430)
• geen middelen meer: geheugen, heap, buffer (ex: KB2034111, KB2150280)
• oneindige lus + stack overflow (ex: KB2105522)
• onjuiste of niet-ondersteunde configuratieparameters (bijv. KB2012125, KB2127997)

3. Stuurprogramma's die zich misdragen; bugs in stuurprogramma's die proberen toegang te krijgen tot een onjuiste index of een niet-bestaande methode (bijv. KB2148123)

WIST U DAT? 

U kunt zelfs handmatig een PSOD activeren voor testdoeleinden of als u gewoon nieuwsgierig bent om het te zien gebeuren. 

Log in op de ESXi host via DCUI of SSH met een bevoorrechte (priviliged) account en voer uit:

vsish -e set /reliability/crashMe/Panic

Uiteraard is een testsysteem aan te raden, idealiter een virtuele geneste ESXi zodat u de console gemakkelijk kunt observeren. Zorg er ook voor dat u dit artikel volledig doorleest om de implicaties van deze actie en het effect op uw testsysteem te begrijpen. 

Wat is de impact van PSOD?

Wanneer de paniek uitbreekt en de host crasht, worden alle daarop draaiende diensten en alle gehoste virtuele machines beëindigd. De VM's worden niet netjes afgesloten, maar juist abrupt uitgeschakeld. Als de host deel uitmaakt van een cluster en je HA hebt geconfigureerd, worden deze VM's opgestart op de andere hosts in het cluster. Naast de uitval en de onbeschikbaarheid van de VM's gedurende de tijd dat ze uit de lucht zijn, kunnen sommige kritieke applicaties, zoals databaseservers, berichtwachtrijen of back-uptaken, worden beïnvloed door de "vuile" uitschakeling.

Bovendien worden alle andere services die door de host worden geleverd, beëindigd, dus als uw host lid is van een VSAN-cluster, heeft een PSOD ook invloed op vSAN.

Voor mij is het meest storende aspect van een PSOD dat het je vertrouwen in je infrastructuur doet verliezen en de angst die het creëert, tenminste, tot je het tot op de bodem hebt uitgezocht. Ok, je kunt herstellen door opnieuw op te starten en je hebt misschien HA of zelfs FT, dus de impact is misschien niet verwoestend... maar zolang je de hoofdoorzaak niet oplost, kan de gedachte dat dit opnieuw kan gebeuren of op een andere server je 's nachts wakker houden.

Wat te doen als PSOD gebeurt?

1. Analyseer het paarse scherm bericht

Één van de belangrijkste dingen die je moet doen als je een PSOD hebt, is een screenshot maken. Als u op afstand verbinding maakt (IMM, iLO, iDRAC...) met de console is het gemakkelijk om een screenshot te maken, maar als u naar het datacenter moet, kan het zijn dat u letterlijk uw telefoon moet pakken en een foto van het scherm moet maken. Er staat veel nuttige informatie over de oorzaak van de crash in dat scherm. 

2. Neem contact op met VMware-ondersteuning

Voordat u verder onderzoek en troubleshooting start is het raadzaam om contact op te nemen met VMware support, indien u een support contract heeft. Zij kunnen u, parallel aan uw onderzoek, helpen bij het maken van de Root Cause Analysis (RCA). 

3. Herstart de getroffen ESXi host

Om de server te herstellen, zult u hem opnieuw moeten opstarten. Ik zou ook adviseren om hem in onderhoudsmodus te houden totdat je de volledige RCA hebt uitgevoerd, de oorzaak hebt vastgesteld en deze hebt verholpen. Als je het je niet kunt veroorloven om hem in onderhoudsmodus te houden, stel dan op zijn minst je DRS regels zo af dat alleen onbelangrijke VM's er op draaien, zodat als een andere PSOD de server raakt, de impact minimaal zal zijn.

4. Download de coredump

Nadat de server is opgestart, zou je de coredump moeten verzamelen. De coredump, ook wel vmkernel-zdump genoemd, is een bestand met logs met soortgelijke, maar meer gedetailleerde informatie als die op het paarse diagnosescherm en zal gebruikt worden bij verdere probleemoplossing. Zelfs als de oorzaak van de crash duidelijk lijkt uit de PSOD melding die u analyseerde in stap 1, is het raadzaam om het te bevestigen door naar de logs van de coredump te kijken.

Afhankelijk van uw configuratie kan de core dump een van deze vormen hebben:

a. Op de scratch partitie 

b. Als een .dump bestand op één van de datastores van de host

c. Als een .dump bestand op het vCenter - via de netdump service

De coredump wordt vooral belangrijk als de configuratie van de host automatisch gereset moet worden na een PSOD, in welk geval je het bericht niet op het scherm te zien krijgt.

U kunt het dumpbestand uit de ESXi host kopiëren met SCP en het dan openen met een teksteditor (zoals Notepad++). Dit zal de inhoud van het geheugen bevatten op het moment van de crash en de eerste delen ervan bevatten de berichten die je op het paarse scherm zag. Het hele bestand kan worden opgevraagd door VMware support, maar je kunt zelf alleen het vmkernel log eruit pakken, dat is een beetje meer handelbaar:

5. Ontcijfer de fout

Troubleshooting en Analyse van de Onderliggende Oorzaak kunnen je het gevoel geven dat je Sherlock Holmes bent. PSOD's kunnen soms uitdraaien op een door Arthur Conan Doyle geïnspireerd verhaal, maar in de meeste gevallen is het een vrij rechtlijnig proces waarbij het moeilijk zal zijn om tot het vijfde "waarom" van de 5 waarom-techniek te komen.

Het belangrijkste symptoom, en het symptoom waarmee u moet beginnen, is de foutmelding die door het paarse scherm wordt gegenereerd. Gelukkig is het aantal foutmeldingen dat kan worden gegenereerd eindig:

Aangezien de kernel panic door de CPU wordt afgehandeld, wordt voor meer informatie over deze uitzonderingen verwezen naar: Intel 64 and IA-32 Architectures Software Developer's Manual, Volume 1: Basic Architecture en Intel 64 and IA-32 Architectures Software Developer's Manual, Volume 3A.

De meest voorkomende gevallen worden behandeld in afzonderlijke VMware KB artikelen en ik zal hier alleen een referentietabel van dergelijke fouten bijhouden, aangezien de artikelen zeer gedetailleerd en goed gedocumenteerd zijn. Gebruik deze tabel dus als een index voor de PSOD fouten:

6. Logboeken controleren

Het kan gebeuren dat de oorzaak niet erg duidelijk is uit het paarse scherm bericht of uit de core dump log, dus de volgende plaats waar je naar aanwijzingen moet zoeken is in de host logs, vooral in het tijdsinterval net voor de PSOD. Zelfs als je denkt dat je de oorzaak hebt gevonden, is het nog steeds raadzaam om niet te lichtvaardig te zijn en het te bevestigen door naar de logs te kijken.

Als u een bedrijfsomgeving beheert, hebt u waarschijnlijk een gespecialiseerde oplossing voor logboekbeheer bij de hand (zoals VMware Log Insight of SolarWinds LEM), zodat u gemakkelijk door die logboeken kunt bladeren, maar als u geen logboekbeheer hebt, kunt u ze gemakkelijk exporteren.

De meest interessante logbestanden om te onderzoeken zouden zijn:

Hoe voorkom je PSOD?

De meeste software-gerelateerde PSOD's worden opgelost door patches, dus zorg ervoor dat u up-to-date bent met de laatste versies.

Zorg ervoor dat uw servers op de Hardware Compatibility Checklist van VMware staan, samen met alle apparaten en adapters. Dit zal bescherming bieden tegen sommige onverwachte hardwaregerelateerde problemen, maar het zal er ook voor zorgen dat VMware support in staat zal zijn u te ondersteunen in geval van een PSOD.

Zoals hierboven beschreven in "Waarom het gebeurt", zijn slecht werkende drivers ook vaak de oorzaak van PSOD's, dus het is noodzakelijk om regelmatig de ondersteuningswebsites van de leveranciers te controleren op bijgewerkte firmware en drivers en vooral op de gedocumenteerde PSOD veroorzakende drivers om zo snel mogelijk te reageren door ze te upgraden.

Bij Runecast analyseren we regelmatig de volledige VMware Knowledge Base (kb.vmware.com), die bestaat uit meer dan 30.000 artikelen. We halen bruikbare inzichten uit de KB's om gevirtualiseerde infrastructuren proactief veerkrachtiger, veiliger en efficiënter te maken. Wij zijn zeer vertrouwd met de PSOD en zijn in staat om de meeste randvoorwaarden te identificeren die tot dit probleem kunnen leiden. Door uw omgeving proactief te analyseren, zal Runecast Analyzer u helpen om deze problemen te vermijden, zodat u de gemoedsrust heeft dat de meeste PSOD's die in uw omgeving op de loer liggen, voorkomen worden.

‍‍‍