Linux, Antivirus, antispam, Cursos

Diagnosticando problemas en el hardware

Seguro alguna vez nos ha pasado, la máquina tiene un problema de hardware. Los momentos más angustiosos que se pueden pasar administrando un servidor es cuando este tiene problemas en el hardware.

Sin embargo, debemos en efecto establecer que un problema muchas veces no depende de que un dispositivo (pieza o chip) no funcione correctamente por fallas de diseño, sino que muchas veces existen conflictos entre dispositivos de la máquina (colisiones con las mismas interrupciones, etc).

Uno de los síntomas más comunes de este tipo de problema son:

1. La máquina se apaga inesperadamente
2. La PC se queda colgada (congelada) sin responder al teclado o demás
3. Los discos duros comienzan a parpadear interminablemente, o al contrario, no se mueven en largos periodos de tiempo
4. El sistema comienza a dar pánicos
5. El sistema no obedece a comandos desde el shell

Planteamiento del problema

Expondremos un caso real de un servidor que es un clon de redhat enterprise (www.centos.org) que repentinamente deja de funcionar sin previo aviso. El servidor aloja aproximadamente 120 sitios web con sus usuarios (es un servidor de hosting) el cual tiene un disco duro de 80GB, una tarjeta de red realtek 8139 (rtl8139), 1GB de memoria RAM y el procesador Intel(R) Pentium(R) 4 CPU 2.80GHz.

La situación real, al momento de ocurrir el problema es que

* el servidor deja de responder a peticiones de casi cualquier tipo, sean http, smtp, pop3, imap, ftp o ssh.
* Cualquier tipo de conexión que se intente abrir al servidor termina dando timeout.
* El servidor no rechaza las conexiones inmediatamente, sino que hace como si intenta abrir, pero al poco tiempo da timeout la conexión.
* Si se hace un telnet al puerto 25 del servidor, por ejemplo, no obtenemos la tradicional bienvenida que nos da el smtp; en vez del tradicional:

telnet srv3.misitio.com 25
Trying zzzz.www.yyy.xxx...
Connected to srv3.misitio.com (zzzz.www.yyy.xxx).
Escape character is '^]'.
220 srv3.misitio.com ESMTP Sendmail 8.12.11/8.12.11; Fri, 1 Apr 2005 15:42:18 -0500

Obtenemos sólo el inicio (es decir, el demonio responde, pero no acaba abriendo la conexión), así:

telnet srv3.misitio.com 25
Trying zzzz.www.yyy.xxx...
Connected to srv3.misitio.com (zzzz.www.yyy.xxx).
Escape character is '^]'.

Es decir, no está abriendo la sesión correcta ni completamente.

* Otro detalle interesante es que al hacer ping al servidor, este sí nos está respondiendo (el ping usa paquetes ICMP). Y que el servidor que maneja dns, también es capaz de resolver peticiones a sus dns (el dns se maneja a través de paquetes UDP).
* El servidor, si tenemos una sesión abierta en el shell, no nos deja listar, ni emitir ningún comando.
* Al hacer un ifconfig, notamos que el servidor tiene muchas colisiones reportadas en la tarjeta de red, así como muchos errores de tipo de carrier.
* No hay ninguna indicación en los logs de problema. El servidor está guardando sus logs normalmente cuando de repente deja de guardarlos.

Estimación de las causas del problema:

Lo primero que hay que hacer es un estimado de qué está causando este tipo de problemas en el servidor. Es decir, que es lo que nos parece que está dejando de funcionar.

Muchas personas tienden a confundir causas con consecuencias. Por ejemplo, el que se llene la memoria ram de una máquina no significa que solucionemos el problema agregándole más ram. Pues no hemos determinado la causa que puede ser en efecto que requiramos de más memoria, pero sin embargo puede ser un script usando memoria descontroladamente y el incrementar la RAM no la solucione. Sólo nos fijamos en que la memoria se llenaba sin ver más atrás.

Así que procedamos. Por el tipo de síntomas que estamos viendo en el sistema. Al parecer existen algunas causas, muchas con tremenda validez, y otras un poco dudosas:

1- La tarjeta de red no está funcionando 100% efectivamente por la cantidad de colisiones que se dan en la red.

2- La memoria RAM del servidor se llena, pues uno de los síntomas típicos de ram llena es que el servidor no logra abrir las sesiones completamente. Sin embargo cuando es problema de ram, salen algunas indicaciones sobre procesos que no se pueden abrir en los logs. No aparece nada en los logs.

3- El disco duro o la controladora han dejado de funcionar temporal o permanentemente, pues uno de los síntomas típicos de problemas con los dispositivos de almacenamiento es que no se logran abrir las sesiones y que no se logra listar directorios o ejecutar ningún comando estando en el shell. También cuando es problema de I/O, no se pueden guardar los logs.

Estas son las conclusiones preliminares de por qué el servidor está dejando de funcionar correctamente. Todavía no es momento de atacar cualquiera de los problemas sino de estudiar un poco.