Error en VMware vRealize Log Insight: «XXXX.XXXX watchdog: BUG: soft lockup – CPU#X stuck for XXs!»

En esta ocasión les traigo un problema que nos pasó sobre nuestra infraestructura productiva. Resulta que en las ultimas semanas al querer loguearnos a VMware Log Insight, ya sea con un usuario local o con un usuario AD, nos daba el siguiente mensaje:

Al principio suponíamos que era algún servicio o usuario malicioso que al intentar loguearse en reiteradas ocasiones sin éxito, generaba el bloqueo de las cuentas. Pero, cuando hacíamos el procedimiento para desbloquear por ejemplo la cuenta «admin», nos encontrábamos con la sorpresa de que el usuario no figuraba en estado bloqueado por intentos fallidos. Si todavía no sabes como es el procedimiento para desbloquear usuarios en VMware vRealize Log Insight, te dejo el paso a paso en el siguiente link: https://bitacoradelanube.com/2022/03/08/como-desbloquear-el-usuario-admin-en-vmware-vrealize-log-insight/ .

Ahora bien, volviendo al asunto de este articulo, nos dirigimos a revisar la consola y nos encontramos con el siguiente error:

Al buscar información correspondiente al mensaje que aparecía en la consola, llegamos a esta KB https://kb.vmware.com/s/article/67623, en donde detallaba la explicación del mismo error pero sobre la appliance de VMware vCenter Server.

Si bien no mencionaba específicamente a VMware Log Isnight, la realidad es que se trata de una appliance de VMware, que en pocas palabras no es mas que una VM con un sistema operativo propietario independientemente del servicio que tenga corriendo arriba. Esto quiere decir que puede que tengan comportamientos similares a la hora de presentarse ciertos errores o problemas. Volviendo a la KB, explica que el error puede estar relacionado a problemas de performance en el Storage (sea cual sea la tecnología usada: SAN, ISCSI, vSAN, etc.), snapshot (ya sea ejecución o consolidación) y valores de CPU tanto para los ESXI como para las VMs.

A simple vista, descartamos problemas de rendimiento a nivel de computo (CPU y memoria), ya que el Cluster de nodos ESXI estaba bastante holgado en ese sentido. Revisando métricas en VMware vROps tampoco vimos índices altos de CPU Ready sobre dichas VMs. Por lo tanto, pasamos a revisar a nivel de Storage (en nuestro caso una SAN) el cual a simple vista no presentaba errores, alarmas o picos de IOPS. ¿Cómo fue que procedimos para quitarnos la duda?. Simple, ejecutamos un Storage vMotion y migramos las VMs a unos Datastores diferentes, los cuales no pertenecían a la SAN bajo sospecha. De esta manera procedimos a monitorear el comportamiento de las VMs durante una semana, para ver si volvían a presentar el mismo error, y el cual no volvió a registrarse. Cabe destacar que una manera simple de solucionar el problema y para que los usuarios puedan loguearse nuevamente, es realizar el reinicio a nivel de SO (click derecho sobre la VM, seleccionamos Power–>Restart Guest OS) para que los servicios vuelvan a levantar de manera correcta. Si bien es un paliativo, dicha acción no terminará de resolver el problema de fondo.

Por ultimo y para cerrar el tema, se procedió a abrir un caso con el soporte técnico del Storage y con las herramientas con las que ellos cuentan detectaron problemas de performance debido a errores en la versión del Firmware.

Conclusiones:

  • El síntoma que muestra es que los usuarios no pueden loguearse, como si sus cuentas estarían bloqueadas, aunque al revisar el estado de las mismas no aparecen como bloqueadas.
  • El error está relacionado con problemas de performance ya sea a nivel de computo o storage.
  • El error de autenticación de los usuarios se resuelve reiniciando las appliances.
  • Para detectar el problema lo mejor es contar con herramientas de monitoreo tales como VMware vRealize Operations Manager que permitan revisar las métricas de performance.
  • En caso de que no cuenten con herramientas de monitoreo lo mejor es abrir un caso con el soporte oficial de VMware o con el soporte del hardware en cuestión.
  • Hasta que se detecte el origen del problema, lo mejor es migrar las cargas de trabajo hacia otro ESXI, Cluster o Datastore.

¡Hasta la próxima publicación!

Se autoriza la reproducción de los materiales de este blog citando la fuente e incluyendo un enlace al mismo.

Deja una respuesta

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Salir /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Salir /  Cambiar )

Conectando a %s

A %d blogueros les gusta esto: