[Jderobot-admin] Caída del servidor del finde pasado

[Oscar Garcia]

El jue, 01-11-2012 a las 14:29 +0100, Borja Mon Serrano escribió:
> Después de analizar cómo estaba el sistema (o así interpreto yo todo
> lo que hay antes del siguiente oom-killer) mató el servidor apache.
> Después de varias llamadas a oom-killer (en las que no sé exactamente
> qué es lo que está haciendo) terminó por matar la base de datos,
> mysqld.


No creo que se cargara el servidor web, posiblemente matara un proceso
hijo que sería regenerado por el proceso apache padre. Estoy casi seguro
que fue un hijo pq oom-killer deja los procesos cuyo id es "root" para
los últimos, a parte de que trata de matar los procesos que llevan menos
tiempo ejecutándose y los procesos apache hijos tienen una vida mucho
más corta que el proceso apache padre. Eso asegura que servidores como
apache o sshd seguirán en pie y sólo sus hijos (procesos workers) serán
los sacrificados.



> A las 00:05:57 se tiene el último log, por lo que tampoco se puede
> determinar en qué momento terminó de caer el servidor. Lo que sí está
> claro es que desde que se mató al servidor apache ya no se pudo volver
> a levantar.


Repito que posiblemente el servidor apache no muriera. He tenido
muchísimos servidores con problemas de memoria que han provocado a
oom-killer a matar procesos apache y éste no ha caído nunca (bueno,
menos los que se quedan "zombies" después de eso, pero no es por haber
muerto un proceso hijo).


> ¿El problema? Que se quedase sin swap. No sé a qué puede responder
> exactamente. Lo peor es que he leído que no tiene por qué solucionarse
> añadiendo más memoria RAM al sistema [1], si no que habría que
> recurrir a otras alternativas como se explican en ese enlace. Lo que
> sí estaría bien es, tal y como comentó Óscar, instalar herramientas de
> monitorización del sistema. Pero aquí nos topamos con el problema del
> libc de ayer...


Perdona que no consulte la web proporcionada. Depende del problema que
originó el desastre aumentar la RAM ayuda o no. Lo que sí que no ayuda
ABSOLUTAMENTE NADA es aumentar la SWAP.

Tengo decenas de servidores en producción con 1 o 2 GB de swap y algunos
SIN SWAP alguna (sobre todo en las instancias ligeras de EC2).

El problema es que hay que dimensionar el servidor (o los procesos
servidor) para la RAM que se tiene. Por ejemplo, limitar el número de
procesos hijos que puede levantar apache (con zabbix sería bueno
monitorizar el número) o usar un acelerador web como squid para
aligerarle el trabajo.

También se puede limitar el número de sesiones activas de un usuario
en /etc/security/limits.conf (maxlogins) para evitar acumulaciones de
intentos de entrada svn, rsync, ssh, etc.

Por otro lado hay que ver qué más procesos se levantan y si hay tareas
programadas o bots que hagan algo de manera automática que se puedan ir
acumulando si no terminan el trabajo en el tiempo que se suponía que
debían hacerlo.

Por ejemplo, uno de mis servidores cascaba cada x días debido a que la
sincronización de archivos que se ejecutaba cada 30 minutos usando lftp
se ralentizaba por problemas de ancho de banda o se quedaban pillados
los procesos de manera indefinida (porque el servidor de la Junta de
Andalucía se caía y se quedaba zombi como el vuestro) de modo que se
acumulaban cientos de procesos lftp todos conectados al servidor FTP.

El servidor empezaba a sufrir problemas de memoria (oom-killer al
ataque) pero éste se equivocaba matando procesos "jóvenes" como los del
servidor web en vez de los lftp que se iban acumulando ya que éstos
tenían un tiempo de ejecución elevado y, error mío, eran ejecutados por
el usuario root en cron.

Casi siempre lo arreglaban simplemente reiniciando el servidor cuando lo
veían "raro" y todo iba bien, pero en vacaciones el servidor se
"cuajaba" hasta que descubrí el problema real.


> Durante todo el rato que he estado analizando el fichero de log he ido
> mirando cuánta memoria disponible hay en el servidor. Tiene 2GB
> instalados, y normalmente hay usados unos 1650MB (unas veces más y
> otras veces menos, pero por ahí); eso sí, la swap está completamente
> libre.


¿Has restado a esa cantidad la caché de disco usada?

redstar en greystar:~$ cat /proc/meminfo 
MemTotal:        2431608 kB
MemFree:          512600 kB
Buffers:          189232 kB
Cached:           470668 kB

redstar en tauri:~$ cat /proc/meminfo 
MemTotal:        4020452 kB
MemFree:          549760 kB
Buffers:          709448 kB
Cached:           536100 kB

Aunque pone en ambos casos que la memoria libre es cerca a 512 MB es
falso, a eso hay que añadirle la totalidad de la caché de disco (Cached)
que es descartada cuando se requiere memoria RAM y parte de los buffers
(sockets, archivos, etc) que también pueden ser liberados.

¿Tuviste en cuenta esos datos para tomar la medida de uso de memoria? ¿O
usaste el valor que te ponía algún comando como top o free?


> Veo poco probable el hecho de que hubiera un ataque al servidor para
> tirarlo abajo, aunque también se podría intentar mirar (en estos
> momentos no sé exactamente cómo, tendría que investigarlo) si hubo un
> aumento inusual del tráfico en la noche del sábado al domingo.
> Seguramente fuese algún proceso que se terminase de comer toda la
> memoria disponible del sistema, pero es algo que no he alcanzado a ver
> con el syslog. Os adjunto un extracto del syslog donde se ve todo lo
> que os he comentado. Si necesitáis más, lo saco y os lo envío.


El problema es que el syslog pudo ser matado y dejó de loguear eventos,
por eso es bueno tener un watchdog configurado. En la configuración
viene para descomentar la monitorización del archivo de log "syslog"
para que se reinicie la máquina en caso de que éste caiga.


> A día de hoy no hay nada que indique que no se pueda volver a
> producir, así que de momento, mientras no se pueda arreglar lo de la
> dependencia de libc, hay que andarse con mucho ojo.


Recuerdo que dijiste que todo el software adicional se instalaba en /opt
o /usr/local... pero tiene toda la pinta de que alguien instaló perl5
(creo recordar) en el directorio root.

¿Podéis comprobarlo? Cuando se instalan programas en paralelo que son
usados por los gestores de paquetes para ejecutar scripts de instalación
o configuración... ¡puf! es cuando te la juegas.

Por cierto, ¿no habéis pensado en redundar la instalación?

Por otro lado, podríais meter ciertos servicios dentro de un contenedor
virtual dentro de la misma máquina para limitar los recursos usados. Yo
soy un usuario compulsivo de openvz.

Creo que cuanto antes se tenga montado el servidor zabbix y se
monitorice el comportamiento del servidor antes sabremos cuál es el
origen del problema (cuando se repita) para arreglarlo.

PD: Hablando de ataques, también recomendaría usar fail2ban para tener
una mínima defensa contra ataques de fuerza bruta en el servidor ssh (y
otros que se configuren) y tener watchlog enviando informes diarios de
actividad del servidor. 

Un saludo.