La depuración de máquinas Linux se congela

Tengo 15 servidores Linux RH 4.7 idénticos de 64 bits. Ejecutan la base de datos del clúster (el clúster es el nivel de aplicación). En ocasiones (cada mes más o menos) se congela un cuadro aleatorio (nunca el mismo).

Puedo hacer ping a la caja y hacer ping funciona. Si trato de ssh en el cuadro me sale:

ssh_exchange_identification: Connection closed by remote host

SSH está configurado correctamente.

Cuando voy a la sala de servidores e intento iniciar sesión directamente en la consola, puedo cambiar de consola con Alt+ Fn, puedo ingresar un nombre de usuario y los caracteres se muestran, pero después de presionar Enter, no sucede nada. Esperé 8 horas una vez y no cambió.

Configuré syslog para registrar todo en un host remoto, y no hay nada en esos registros. Cuando reinicio la máquina, funciona sin problemas. He ejecutado pruebas HW: todo está bien y no hay nada en los registros. Las máquinas también se controlan con NAGIOS, y no hay una carga o actividad inusual antes de la congelación.

Me he quedado sin ideas; ¿Qué más puedo hacer o consultar?

Parece que su kernel entró en pánico de alguna manera tal que sshd no pudo enviar las claves del servidor. Posiblemente, el kernel se acuñó de tal manera que la pila de red todavía estaba activa, pero la capa vfs no estaba disponible.

Cuando experimenté problemas similares en un sistema RHEL4, configuré los servicios netdump y netconsole , y un servidor dedicado netdump y syslog para detectar los volcados de memoria y la información de kernel panic. También configuré el kernel.panic sysctl en 10. De esa manera, cuando un sistema entra en pánico, obtienes tanto el seguimiento del kernel como una copia de la memoria en ese sistema, a la que puedes analizar con la utilidad 'crash'.

Sin duda, también se beneficiaría de configurar una consola en serie para los hosts, para que pueda ver la consola apagada y potencialmente presionar las teclas mágicas sysrq. Además, si está dispuesto a configurar la red y tiene hardware que lo admite, puede usar IPMI para apagar, encender, reiniciar y consultar el hardware de forma remota.

(por lo que vale, RHEL5 tiene una funcionalidad similar con kexec / kdump, solo el volcado por caída se almacena localmente)

Apostaré dólares a donas que te estás quedando sin memoria. El sistema se está deteniendo mientras trata de averiguar de dónde obtener algo. Puede estar sucediendo tan rápido que su monitoreo no lo detecta. Intensificaría la supervisión, incluido el registro remoto del uso de memoria. Compruebe también en los registros los mensajes OOM.

(Es posible que incluso desee tener algunas ventanas ssh abiertas en la parte superior).

Para mí, esto parece que el sistema no tiene recursos, por lo que no se puede asignar el proceso que necesita el lado del servidor de ssh.

El cuello de botella real puede variar, fuera de los procesos o fuera de la memoria, y la única manera de asegurarse es mirar los registros y la consola para ver si hay algo allí. Es posible que desee configurar un escenario de trabajos ssh preiniciados, uno para cada máquina, simplemente para estar preparado la próxima vez que suceda.

Si es realmente malo, puede considerar iniciar otro shell con más comandos integrados para que pueda investigar más sin tener que iniciar un proceso adicional, ya que esto puede no ser posible. También "tail -f / var / log / *" puede ser muy útil.

Buena suerte.

La única vez que vi algo similar fue cuando se usó un conmutador KVM y se utilizó una tecla de acceso rápido del teclado (por ejemplo, alt + n) para cambiar entre servidores. No sucedió todo el tiempo y fue el servidor que se apagó el que se vio afectado, por lo que no se notó de inmediato. No se producirían bloqueos si se usara un botón físico en el conmutador KVM para alternar entre servidores. Si la tecla de acceso rápido se usaba con frecuencia, ocasionalmente un servidor no permitiría nuevos inicios de sesión. Las sesiones SSH existentes no se vieron afectadas.