Hogyan kezeljük a PSOD-t - A lila képernyős halált?

This article is available in the following languages:

‍

‍‍‍

‍

Tartalomjegyzék

Mi az a PSOD? 

Miért történik ez?

Mi a hatása?

Mi a teendő, ha ez történik?

Hogyan lehet megelőzni?

TL;DR

A PSOD legproblémásabb aspektusa az, hogy elveszíti az infrastruktúrába vetett bizalmat, és ebből fakadó szorongást okoz. Amíg meg nem oldja a kiváltó okot, hogy ez újra megtörténhessen, akár egy  másik kiszolgálón, éjszakánként ébren tarthatja az adminokat.

A Runecast Analyzer (ingyenes próbaverzió) segítségével ellenőrizheti, hogy a VMware lila képernyős halált okozó körülményei nem érintik-e valamelyik hosztját. 

Mi az a PSOD?

A PSOD a Purple Screen of Diagnostics (Bíborszínű diagnosztikai képernyő) rövidítése, gyakran a Purple Screen of Death (a szélesebb körben ismert Blue Screen of Death (Kék halál képernyő) nevet viseli, amely néha a Microsoft Windows rendszerben is előfordul).

Ez egy diagnosztikai képernyő, amelyet a VMware ESXi akkor jelenít meg, amikor a rendszermag olyan végzetes hibát észlel, amelyből vagy nem tud biztonságosan helyreállni, vagy nem tudja folytatni a futást anélkül, hogy ne lenne sokkal nagyobb kockázata a jelentős adatvesztésnek. 

Megmutatja a memória állapotát az összeomlás idején, valamint további részleteket, amelyek fontosak az összeomlás okának elhárításában: Az ESXi verziója és buildje, a kivétel típusa, a regiszter dömping, a backtrace, a szerver üzemideje, a hibaüzenetek és a core dump (a hiba után generált fájl, amely további diagnosztikai információkat tartalmaz) információi. 

Ez a képernyő a szerver konzolján látható. Ahhoz, hogy láthassa, vagy az adatközpontban kell lennie, és csatlakoztatnia kell egy monitort, vagy távolról, a szerver sávon kívüli kezelésének segítségével (iLO, iDRAC, IMM... a gyártótól függően).

TUDTA? 

A képernyőt     lilának     vagy    rózsaszínnek nevezik, de valójában a szín    sötét magenta (RGB:171,0,171 | CMYK:0.00, 1.00, 0.00, 0.33).

Miért történik a PSOD? 

A PSOD egy kernelpánik. Bár mindannyian tudjuk, hogy az ESXi nem a UNIX-on alapul, a pánik végrehajtása megfelel a UNIX definíciójának. Az ESXi kernel (vmkernel) ezt a biztonsági intézkedést olyan esemény/hiba esetén váltja ki, amely helyreállíthatatlan, és amely azt jelentené, hogy a futás folytatása nagy kockázatot jelentene a szolgáltatások és a VM-ek számára. Egyszerűen fogalmazva: amikor az ESXi hosztok úgy érzik, hogy megrongálódott, "seppukut" követ el, és lila vért vérezve ír egy búcsúlevelet, amelyben részletezi, hogy miért tette ezt!

A PSOD leggyakoribb okai a következők:

1. Hardverhibák, többnyire RAM-mal vagy CPU-val kapcsolatosak. Általában "MCE" vagy "NMI" hibát dobnak ki. 

• "MCE" - Machine Check Exception, amely a CPU-n belüli mechanizmus a hardverproblémák észlelésére és jelentésére. A lila képernyőn megjelenő kódokban fontos részletek találhatók a probléma kiváltó okának azonosításához. 
• "NMI" - nem maszkolható megszakítás, amely egy olyan hardveres megszakítás, amelyet a processzor nem hagyhat figyelmen kívül. Mivel az NMI egy nagyon fontos üzenet a HW hibáról, az ESXi 5.0-tól kezdve az alapértelmezett válasz a PSOD kiváltása. A korábbi verziók csak naplózták a hibát és folytatták. Az MCE-khez hasonlóan az NMI által okozott lila képernyő is fontos kódokat ad, amelyek kulcsfontosságúak a hibaelhárításhoz.

2. Szoftverhibák

• nem megfelelő kölcsönhatások az ESXi SW-összetevők között (pl.: KB2105711)
• versenyfeltételek (pl.: KB2136430)
• elfogytak az erőforrások: memória, heap, puffer (pl.: KB2034111, KB2150280)
• végtelen ciklus + stack túlcsordulás (pl.: KB2105522)
• nem megfelelő vagy nem támogatott konfigurációs paraméterek (pl.: KB2012125, KB2127997)

3. Rosszul viselkedő illesztőprogramok; hibák az illesztőprogramokban, amelyek megpróbálnak hozzáférni valamilyen helytelen indexhez vagy nem létező módszerhez (pl.: KB2148123).

TUDTA? 

Tesztelés céljából, vagy ha csak kíváncsi vagy, hogy mi történik, akár kézzel is elindíthatsz egy PSOD-ot. Jelentkezzen be az ESXi állomáson a DCUI-n vagy az SSH-n keresztül egy privilegizált fiókkal, és futtassa:

vsish -e set /reliability/crashMe/Panic

Nyilvánvalóan ajánlott egy tesztrendszer, ideális esetben egy virtuálisan beágyazott ESXi, hogy könnyen megfigyelhesse a konzolt. Győződjön meg arról is, hogy befejezte a cikk elolvasását, hogy megértse a művelet következményeit és a tesztrendszerre gyakorolt hatását. 

Milyen hatása van a PSOD-nak?

Amikor a pánikhelyzet bekövetkezik, és a gazda összeomlik, a rajta futó összes szolgáltatást és az összes virtuális gépet is leállítja. A VM-ek nem kíméletesen leállnak, hanem hirtelen kikapcsolódnak. Ha az állomás egy fürt része, és HA-t konfigurált, akkor ezek a VM-ek a fürt többi állomásán indulnak el. A leállás és a VM-ek elérhetetlensége mellett a leállás ideje alatt néhány kritikus alkalmazást, például adatbázis-kiszolgálókat, üzenetvárólistákat vagy biztonsági mentési feladatokat is érinthet a "piszkos" leállás.

Emellett az állomás által nyújtott összes többi szolgáltatás is megszűnik, így ha az állomás egy VSAN fürt tagja, a PSOD a vSAN-ra is hatással lesz.

Számomra a PSOD legproblémásabb aspektusa az, hogy elveszíti az infrastruktúrába vetett bizalmat és szorongást kelt, legalábbis addig, amíg a végére nem járunk a dolognak. Oké, újraindítással helyreállítható, és lehet, hogy van HA vagy akár FT, így a hatás nem lehet pusztító... de amíg nem oldja meg a kiváltó okot, a gondolat, hogy ez újra vagy egy másik szerveren is megtörténhet, nem hagyja aludni az éjszaka.

Mi a teendő, ha PSOD történik?

1. Elemezze a lila képernyő üzenetet

Az egyik legfontosabb dolog, amit PSOD esetén meg kell tenned, hogy képernyőképet készítesz. Ha távolról csatlakozik (IMM, iLO, iDRAC...) a konzolhoz, akkor könnyű képernyőképet készíteni, de ha az adatközpontba kell mennie, akkor lehet, hogy szó szerint elő kell vennie a telefonját, és le kell fényképeznie a képernyőt. Azon a képernyőn sok hasznos információ van az összeomlás okáról. 

2. Kapcsolatfelvétel a VMware támogatással

Mielőtt további vizsgálatokba és hibaelhárításba kezdene, célszerű felvenni a kapcsolatot a VMware támogatásával, ha rendelkezik támogatási szerződéssel. Ők a vizsgálattal párhuzamosan segíteni tudnak Önnek a gyökér ok elemzés (RCA) elkészítésében. 

3. Az érintett ESXi állomás újraindítása

A szerver helyreállításához újra kell indítania azt. Azt is javasolnám, hogy tartsa karbantartási üzemmódban, amíg nem végzi el a teljes RCA-t, nem azonosítja az okot, és nem javítja ki. Ha nem engedheti meg magának, hogy karbantartási üzemmódban tartsa, legalább finomhangolja a DRS-szabályokat, hogy csak a nem fontos VM-ek fussanak rajta, így ha egy másik PSOD lecsapódik, a hatás minimális lesz.

4. Szerezd meg a core dumpot

Miután a szerver elindult, össze kell gyűjtenie a coredumpot. A coredump, más néven vmkernel-zdump egy olyan fájl, amely a lila diagnosztikai képernyőn látottakhoz hasonló, de részletesebb információkat tartalmazó naplófájlokat tartalmaz, és a további hibaelhárítás során használható. Még ha az 1. lépésben elemzett PSOD-üzenetből nyilvánvalónak is tűnhet az összeomlás oka, célszerű a coredump naplóinak megtekintésével megerősíteni azt.

A konfigurációtól függően a core dump a következő formák valamelyikében jelenhet meg:

a. A scratch partíción 

b. .dump fájlként az állomás egyik adattárolóján

c. .dump fájlként a vCenterben - a netdump szolgáltatáson keresztül.

A coredump különösen akkor válik fontossá, ha a hoszt konfigurációja automatikusan visszaáll a PSOD után, ebben az esetben nem fogod látni az üzenetet a képernyőn.

A dumpfile-t SCP segítségével kimásolhatja az ESXi állomásról, majd megnyithatja egy szövegszerkesztővel (például Notepad++). Ez tartalmazza a memória tartalmát az összeomlás idején, és az első részei tartalmazzák a lila képernyőn látott üzeneteket. A teljes fájlt kérheti a VMware support, de csak a vmkernel logot lehet kinyerni, ami egy kicsit ... emészthetőbb:

5. A hiba megfejtése

A hibaelhárítás és a gyökeres okok elemzése miatt az ember úgy érezheti magát, mint Sherlock Holmes. A PSOD-ok néha Arthur Conan Doyle ihlette történetté válhatnak, de a legtöbb esetben ez egy elég egyszerű folyamat, ahol nehéz lesz eljutni az 5 Whys technika ötödik "miértjéhez".

A legfontosabb tünet, amellyel érdemes kezdeni, a lila képernyő által generált hibaüzenet. Szerencsére az előállítható hibaüzenetek száma véges:

Mivel a kernelpánikot a CPU kezeli, az ilyen kivételekkel kapcsolatos további információkért lásd: Intel 64 and IA-32 Architectures Software Developer's Manual, Volume 1: Basic Architecture és Intel 64 and IA-32 Architectures Software Developer's Manual, Volume 3A.

A leggyakoribb esetekkel külön VMware KB cikkek foglalkoznak, én pedig itt csak egy referenciatáblázatot vezetek az ilyen hibákról, mivel a cikkek nagyon részletesek és jól dokumentáltak. Használja tehát ezt a táblázatot a PSOD hibák indexeként:

6. Naplók ellenőrzése

Előfordulhat, hogy a lila képernyő üzenetéből vagy a core dump naplóból nem nagyon derül ki az ok, ezért a következő hely, ahol nyomokat kell keresni, a host naplói, különösen a PSOD-ot közvetlenül megelőző időintervallumban. Még ha úgy is érezzük, hogy megtaláltuk az okot, akkor is tanácsos a naplófájlok megnézésével megerősíteni azt.

Ha vállalati környezetet adminisztrál, akkor valószínűleg van valamilyen speciális naplókezelési megoldása (például a VMware Log Insight vagy a SolarWinds LEM), így könnyen átböngészheti ezeket a naplókat, de ha nincs naplókezelési megoldása, akkor könnyen exportálhatja azokat.

A legérdekesebb naplófájlok a következők:

Hogyan előzhető meg a PSOD?

A szoftverrel kapcsolatos PSOD-k többségét javítások oldják meg, ezért győződjön meg róla, hogy naprakész a legújabb verziókkal.

Győződjön meg róla, hogy a szerverek szerepelnek a VMware Hardverkompatibilitás-ellenőrzési listáján, az összes eszközzel és adapterrel együtt. Ez védelmet nyújt néhány váratlan hardverrel kapcsolatos problémával szemben, de azt is biztosítja, hogy a VMware ügyfélszolgálata PSOD esetén is támogatni tudja Önt.

Amint azt fentebb a "Miért történik" című részben leírtuk, a PSOD-ok gyakori okozója a rosszul működő illesztőprogramok is, ezért feltétlenül ellenőrizze rendszeresen a gyártók támogatási webhelyeit a frissített firmware és illesztőprogramok, és különösen a dokumentált PSOD-okat okozó illesztőprogramok frissítésével kell minél hamarabb reagálni.

A Runecastnál rendszeresen elemezzük a VMware teljes tudásbázisát (kb.vmware.com), amely több mint 30 000 cikkből áll. A KB-ból hasznosítható meglátásokat vonunk ki annak érdekében, hogy proaktív módon rugalmasabbá, biztonságosabbá és hatékonyabbá tegyük a virtualizált infrastruktúrákat. Nagyon jól ismerjük a PSOD-ot, és képesek vagyunk azonosítani a legtöbb előfeltételt, amely a problémához vezethet. A környezetének proaktív elemzésével a Runecast Analyzer segít elkerülni ezeket a problémákat, így nyugodt lehet, hogy a környezetére leselkedő legtöbb PSOD megelőzhető.

>> Runecast Analyzer ingyenes próbaverzió letöltése (angol nyelven)

‍‍‍

‍

‍