Cómo lidiar con la PSOD – La pantalla púrpura de la muerte

This article is available in the following languages:

‍

‍‍‍

‍

Contenido

¿Qué es la PSOD? 

¿Por qué ocurre esto?

¿Cuál es el impacto?

¿Qué hacer cuando ocurre?

¿Cómo prevenirlo?

TL;DR

El aspecto más problemático de una PSOD es que te hace perder la confianza en tu infraestructura y la ansiedad que genera. Hasta que no resuelvas la causa raíz, pensar que esto puede volver a ocurrir en este, o en otro servidor puede quitarte el sueño.

Utiliza Runecast Analyzer (prueba gratuita) para comprobar si alguno de tus hosts está afectado por las condiciones que pueden causar la pantalla púrpura de la muerte de VMware. 

¿Qué es la PSOD?

PSOD significa Pantalla Púrpura de Diagnóstico, a menudo denominada Pantalla Púrpura de la Muerte (derivada de la más conocida Pantalla Azul de la Muerte que a veces se encuentra en Microsoft Windows).

Es una pantalla de diagnóstico que muestra VMware ESXi cuando el kernel detecta un error fatal del que no puede recuperarse de forma segura, o no puede seguir funcionando sin tener un riesgo mucho mayor de pérdida de datos. 

Muestra el estado de la memoria en el momento del fallo y también detalles adicionales que son importantes para solucionar la causa del fallo: Versión y compilación de ESXi, tipo de excepción, volcado de registros, backtrace, tiempo de actividad del servidor, mensajes de error e información sobre el volcado del núcleo (un archivo generado tras el error, que contiene más información de diagnóstico). 

Esta pantalla es visible en la consola del servidor. Para verla, tendrás que estar en el centro de datos y conectar un monitor o utilizar remotamente la gestión fuera de banda del servidor (iLO, iDRAC, IMM... dependiendo de tu proveedor).

¿LO SABÍAS? 

La pantalla se denomina     púrpura     o    rosa, pero en realidad el color es   

¿Por qué se produce la PSOD? 

El PSOD es un pánico del kernel. Aunque todos sabemos que ESXi no está basado en UNIX, la implementación del pánico se ajusta a la definición de UNIX. El kernel de ESXi (vmkernel) activa esta medida de seguridad en respuesta a un evento/error irrecuperable y significa que continuar ejecutando supondría un alto riesgo para los servicios y las VMs. En pocas palabras: cuando el host ESXi siente que se ha corrompido, comete "seppuku" y, mientras sangra su sangre púrpura, ¡escribe una carta de suicidio detallando por qué lo ha hecho!

Las causas más comunes de una PSOD son:

1. Fallos de hardware, principalmente relacionados con la RAM o la CPU. Normalmente lanzan un error "MCE" o "NMI". 

• "MCE" - Machine Check Exception es un mecanismo dentro de la CPU para detectar y reportar problemas de hardware. Hay detalles importantes para identificar la causa raíz del problema en los códigos que aparecen en la pantalla púrpura. 
• "NMI" - interrupción no enmascarable es una interrupción de hardware que no puede ser ignorada por el procesador. Dado que NMI es un mensaje muy importante sobre un fallo de HW, la respuesta por defecto a partir de ESXi 5.0 y posteriores es activar un PSOD. Las versiones anteriores se limitaban a registrar el error y continuar. Al igual que con los MCEs, la pantalla púrpura causada por NMI proporcionará códigos importantes que son cruciales para la resolución de problemas.

2. Errores de software

• interacciones inadecuadas entre los componentes SW de ESXi (por ejemplo, KB2105711)
• condiciones de carrera (por ejemplo, KB2136430)
• sin recursos: memoria, heap, buffer (ex: KB2034111, KB2150280)
• bucle infinito + desbordamiento de pila (por ejemplo, KB2105522)
• parámetros de configuración inadecuados o no compatibles (por ejemplo, KB2012125, KB2127997)

3. Controladores que se comportan mal; fallos en los controladores que intentan acceder a algún índice incorrecto o a un método inexistente (por ejemplo: KB2148123)

¿LO SABÍAS? 

Incluso puedes activar manualmente un PSOD para probarlo o si sólo tienes curiosidad por verlo. 

Inicia sesión en el host ESXi a través de DCUI o SSH con una cuenta privilegiada y ejecuta:

vsish -e set /reliability/crashMe/Panic

Obviamente se recomienda un sistema de prueba, idealmente un ESXi virtual anidado para que se pueda observar fácilmente la consola. También asegúrate de terminar de leer este artículo para entender las implicaciones de esta acción y el efecto en su sistema de prueba. 

¿Cuál es el impacto de la PSOD?

Cuando se produce el pánico y el host se bloquea, termina todos los servicios que se ejecutan en él junto con todas las máquinas virtuales alojadas. Las máquinas virtuales no se apagan con gracia, sino que se apagan abruptamente. Si el host forma parte de un cluster y has configurado HA, estas VMs se iniciarán en los otros hosts del cluster. Además de la interrupción y la indisponibilidad de las máquinas virtuales durante el tiempo que están fuera de servicio, algunas aplicaciones críticas como los servidores de bases de datos, las colas de mensajes o los trabajos de copia de seguridad pueden verse afectados por el apagado "sucio".

Además, todos los demás servicios proporcionados por el host se interrumpirán, por lo que si tu host es miembro de un clúster VSAN, un PSOD también afectará a vSAN.

Para mí, el aspecto más molesto de un PSOD es que te hace perder la confianza en tu infraestructura y la ansiedad que genera, al menos hasta que llegues al fondo del asunto. Vale, puedes recuperarte reiniciando y puede que tengas HA o incluso FT por lo que el impacto puede no ser devastador... pero hasta que no resuelvas la causa raíz, el pensar que esto puede volver a ocurrir en este o en otro servidor, puede mantenerte despierto por la noche.

‍
¿Qué hacer cuando se produce una PSOD?

1. Analizar el mensaje de la pantalla púrpura

Una de las cosas más importantes que hay que hacer cuando se tiene un PSOD es tomar una captura de pantalla. Si te conectas remotamente (IMM, iLO, iDRAC...) a la consola será fácil hacer una captura de pantalla, pero si tienes que ir al centro de datos, puede que tengas que sacar literalmente tu teléfono y hacer una foto de la pantalla. Hay mucha información útil sobre la causa del fallo en esa pantalla. 

2. Contacta con el soporte de VMware

Antes de comenzar la investigación y la resolución de problemas, es aconsejable ponerse en contacto con el soporte de VMware, si tienes un contrato de soporte. Paralelamente a tu investigación, ellos podrán ayudarte a realizar el análisis de causa raíz (RCA). 

3. Reinicia el host ESXi afectado

Para recuperar el servidor, tendrás que reiniciarlo. También te aconsejo que lo mantengas en modo de mantenimiento hasta que realices el RCA completo, identifiques la causa y la arregles. Si no puedes permitirte mantenerlo en modo de mantenimiento, al menos afina tus reglas de DRS para que sólo se ejecuten en él las máquinas virtuales que no sean importantes, de modo que si otro PSOD se produce el impacto sea mínimo.

4. Obtener el volcado del núcleo

Después de que el servidor arranque, debes recoger el coredump. El coredump, también llamado vmkernel-zdump, es un archivo que contiene registros con información similar, pero más detallada, a la que se ve en la pantalla de diagnóstico púrpura y se utilizará en la resolución de problemas posteriores. Incluso si la causa del fallo puede parecer obvia a partir del mensaje PSOD que analizaste en el paso 1, es aconsejable confirmarlo mirando los registros del coredump.

Dependiendo de tu configuración puedes tener el volcado del núcleo en una de estas formas:

a. En la partición scratch 

b. Como un archivo .dump en uno de los datastores del host

c. Como un archivo .dump en el vCenter - a través del servicio netdump

El coredump adquiere especial importancia si la configuración del host debe restablecerse automáticamente después de un PSOD, en cuyo caso no podrás ver el mensaje en pantalla.

Puedes copiar el archivo de volcado fuera del host ESXi usando SCP y luego abrirlo usando un editor de texto (como Notepad++). Esto contendrá el contenido de la memoria en el momento del choque y las primeras partes de ella contienen los mensajes que viste en la pantalla púrpura. El archivo completo puede ser solicitado por el soporte de VMware, pero sólo se puede extraer el registro del vmkernel, que es un poco más ... digerible:

5. Descifrar el error

La resolución de problemas y el análisis de la causa raíz pueden hacer que uno se sienta como Sherlock Holmes. Los PSOD pueden convertirse a veces en una historia inspirada en Arthur Conan Doyle, pero en la mayoría de los casos se trata de un proceso bastante sencillo en el que será difícil llegar al quinto "por qué" de la técnica de los 5 porqués.

El síntoma más importante, y por el que deberías empezar, es el mensaje de error que genera la pantalla morada. Por suerte, el número de mensajes de error que se pueden producir es finito: 

Dado que el pánico del kernel es manejado por la CPU, para más información sobre estas excepciones consulta el Manual del Desarrollador de Software de las Arquitecturas Intel 64 e IA-32, Volumen 1: Arquitectura Básica y el Manual del Desarrollador de Software de las Arquitecturas Intel 64 e IA-32, Volumen 3A.

Los casos más comunes están cubiertos en artículos separados de la KB de VMware y sólo mantendré una tabla de referencia de dichos errores aquí ya que los artículos son muy detallados y están bien documentados. Así que utiliza esta tabla como un índice para los errores PSOD:

6. Comprobar los registros

Puede ocurrir que la causa no sea muy obvia mirando el mensaje de la pantalla púrpura o el registro de volcado del núcleo, así que el siguiente lugar donde buscar pistas es en los registros del host, especialmente en el intervalo de tiempo que precede al PSOD. Incluso cuando crees que has localizado la causa, es aconsejable evitar ser parsimonioso y confirmarlo mirando los registros.

Si estás administrando un entorno empresarial es probable que tengas a mano alguna solución especializada de gestión de registros (como VMware Log Insight o SolarWinds LEM) por lo que será fácil examinar esos registros, pero si no tienes una gestión de registros puedes exportarlos fácilmente.

Los archivos de registro más interesantes para explorar serían:

¿Cómo prevenir la PSOD?

La mayoría de las PSOD relacionadas con el software se resuelven mediante parches, así que asegúrate de estar al día con las últimas versiones.

Asegúrate de que tus servidores están en la lista de comprobación de compatibilidad de hardware de VMware, junto con todos los dispositivos y adaptadores. Esto protegerá de algunos de los problemas inesperados relacionados con el hardware, pero también asegurará que el soporte de VMware sea capaz de apoyarte en caso de un PSOD.

Como se describió anteriormente en "Por qué sucede", los controladores que no funcionan bien también son una causa frecuente de PSOD, por lo que es imperativo comprobar regularmente los sitios web de soporte de los proveedores para ver si el firmware y los controladores están actualizados y, especialmente, los controladores documentados que causan PSOD para responder lo antes posible actualizándolos.

En Runecast, analizamos regularmente toda la base de conocimientos de VMware (kb.vmware.com), que consta de más de 30.000 artículos. Extraemos información procesable de la base de conocimientos para hacer que las infraestructuras virtualizadas sean más resistentes, seguras y eficientes. Estamos muy familiarizados con el PSOD y somos capaces de identificar la mayoría de las condiciones previas que pueden conducir a este problema. Al analizar proactivamente su entorno, Runecast Analyzer te ayudará a alejarse de estos problemas, para que pueda tener la tranquilidad de que la mayoría de los PSOD que acechan a tu entorno están prevenidos.

>> Descargar la prueba gratuita de Runecast Analyzer (Idioma en Inglés)