May 31, 2009

Monitorización de servicios con mon (III)

Y ya para terminar el capítulo de la monitorización de servicios con mon dentro del Sistema de Alta Disponibilidad y Balanceo de Carga que venimos desarrollando, vamos a ver los tres scripts que implementaremos tanto para la parada (service_down.alert) y arranque (service_up.alert) de servicios, como para la monitorización del estado de un determinado proceso (proc.monitor).

Los scripts de parada y arranque serán comunes para todos los nodos del cluster. El script de parada será invocado por mon desde el archivo mon.cf a través de la siguiente forma: "alert service_down.alert comando fichero_estado".

Como primer argumento le pasaremos el comando que tendrá que ejecutar en caso de caída del servicio, y en el segundo, el fichero donde guardar el estado del servicio. Estos valores serán recibidos por el script a través de las variables de entorno $9 y $10 respectivamente.

En el script de parada lo primero que se hace es comprobar si el fichero de estado existe, y en caso contrario se crea con el valor inicial de "on". Si se produce una primera caída del servicio (el fichero de estado contendrá en ese momento el valor "on"), se ejecutará la orden recibida mediante la variable $9. A continuación se pondrá en el fichero de estado el valor "restarted".

Si el servicio siguiera caído cuando mon volviera a comprobar su situación, vería que el valor del fichero de estado es "restarted" (ya ha sido reiniciado previamente), con lo que a continuación reiniciaría el equipo y pondría el valor "rebooted" en dicho fichero. Si el servicio siguiera sin arrancar, apagaría la máquina completamente.
~# cat /usr/lib/mon/alert.d/service_down.alert
#!/bin/sh

if [ ! -f $10 ]; then
echo "on" > $10
fi

case "$(cat $10)" in
"on")
echo "restarted" > $10
$(/usr/bin/sudo $9);;
"restarted")
echo "rebooted" > $10
$(/usr/bin/sudo reboot);;
"rebooted")
echo "on" > $10
$(/usr/bin/sudo halt);;
esac
Por otra parte, el script de arranque (service_up.alert) lo único que hará será poner el valor "on" en el fichero de estado.
~# cat /usr/lib/mon/alert.d/service_up.alert
#!/bin/sh
echo "on" > $10
También será necesario desarrollar un script encargado de comprobar si un determinado servicio sigue vivo. Este script será empleado exclusivamente en los dos nodos traseros para verificar el estado del proceso ndbd.
~# cat /usr/lib/mon/mon.d/proc.monitor

#!/bin/sh
if [ "$(pgrep $1)" = "" ]; then
exit 1
else
exit 0
fi
Estos scripts que acabamos de diseñar les tendremos que otorgar permisos de ejecución:
~# chmod +x /usr/lib/mon/alert.d/service_down.alert

~# chmod +x /usr/lib/mon/alert.d/service_up.alert

~# chmod +x /usr/lib/mon/mon.d/proc.monitor
Mon es lanzado mediante el usuario daemon y este último no tiene privilegios de root para realizar ciertas operaciones (reiniciar apache2 y proftpd, reiniciar y apagar la máquina, etc). Por lo tanto, dentro del fichero /etc/sudoers de cada una de las máquinas habrá que incluir las órdenes necesarias que permitan ejecutar dichos comandos al usuario daemon con permisos de root.

Para los nodos HA1 y HA2 añadiremos las siguientes líneas al fichero /etc/sudoers:
~# cat /etc/sudoers
...
# User privilege specification
root ALL=(ALL) ALL

daemon ALL=NOPASSWD:/etc/init.d/mysql-ndb-mgm restart,/sbin/reboot,/sbin/halt
...
Y para LB1 y LB2:
~# cat /etc/sudoers
...
# User privilege specification
root ALL=(ALL) ALL

daemon ALL=NOPASSWD:/etc/init.d/apache2 restart,/etc/init.d/vsftpd restart,/etc/init.d/glusterfs-server restart,/etc/init.d/mysql restart",/etc/init.d/mysql-ndb restart,/sbin/reboot,/sbin/halt
...
Debido a que mon va a controlar una serie de servicios que deben de estar previamente arrancados, tenemos que modificar su script de arranque (/etc/init.d/mon) para que sea el último en levantarse (le daremos prioridad 99). En caso de apagado o reinicio de la máquina, ocurrirá lo contrario: deberá ser el primer en apagarse (le daremos prioridad 10).
~# update-rc.d -f mon remove
~# update-rc.d mon start 99 2 3 4 5 . stop 10 0 1 6 .
Esto sólo hay que hacerlo en los dos nodos traseros (LB1, LB2), ya que para los dos nodos frontales (HA1, HA2) será Heartbeat el encargado de levantarlo o apagarlo (recordamos el contenido del fichero /etc/ha.d/haresources):
~# cat /etc/ha.d/haresources
ha1 IPaddr2::192.168.1.20 IPaddr2::10.0.0.20 mysql-ndb-mgm ldirectord::ldirectord.cf LVSSyncDaemonSwap::master mon
Por lo tanto, para que Heartbeat sea el único elemento encargado de detener e iniciar el demonio mon, tendremos que quitarlo del sistema de arranque del proceso init en los nodos HA1 y HA2:
~# update-rc.d -f mon remove

May 26, 2009

Monitorización de servicios con mon (II)

En el artículo anterior del Sistema de Alta Disponibilidad y Balanceo de Carga que venimos desarrollando, se expusieron las características principales del demonio mon.

En este segundo artículo vamos a presentar los ficheros de configuración de mon para los cuatro nodos del cluster. Lo primero que vamos a hacer es instalar los paquetes mon (versión 0.99.2) y sendmail (versión 8.14.3) en las cuatro máquinas:

~# aptitude install mon sendmail

A continuación vamos a editar los ficheros de configuración de mon (/etc/mon/mon.cf) en los dos nodos frontales, HA1 y HA2. Para estos dos nodos, mon únicamente comprobará el estado del servicio ndb_mgmd.

root@ha1:~# cat /etc/mon/mon.cf
# Directorio donde residen los ficheros de mon

cfbasedir = /etc/mon

# Directorio donde residen los scripts de alerta
alertdir = /usr/lib/mon/alert.d

# Directorio donde residen los scripts de monitorización
mondir = /usr/lib/mon/mon.d

# Número máximo de procesos que tendrá el monitor
maxprocs = 20

# Número de eventos que serán guardados en el fichero de históricos
histlength = 100

# Tiempo aleatorio (de 0 a 60sg) transcurrido el cual, se arrancará el monitor
randstart = 60s

# Grupo de máquinas a monitorizar
hostgroup ha1 192.168.1.10

# Grupo a monitorizar
watch ha1

# Servicio a monitorizar
service ndb_mgmd

# Intervalo de monitorización
interval 30s

# Script empleado para monitorizar
monitor tcp.monitor -p 1186

# Periodo de monitorización
period wd {Mon-Sun}

# Enviar un correo electrónico en caso de caída del servicio
alert mail.alert -S "[ha1] ndb_mgmd off"
my_mail@gmail.com

# Reiniciar servicio/reiniciar máquina/apagar máquina
alert service_down.alert "/etc/init.d/mysql-ndb-mgm restart" /var/log/mon/mysql-ndb-mgm_status

# Reiniciar el estado del servicio (pasar a "on")
upalert service_up.alert /var/log/mon/mysql-ndb-mgm_status

# Enviar un correo electrónico en caso de recuperación del servicio
upalert mail.alert -S "[ha1] ndb_mgmd on" my_mail@gmail.com

Y para el nodo HA2:

root@ha2:~# cat /etc/mon/mon.cf
# Directorio donde residen los ficheros de mon

cfbasedir = /etc/mon

# Directorio donde residen los scripts de alerta
alertdir = /usr/lib/mon/alert.d

# Directorio donde residen los scripts de monitorización
mondir = /usr/lib/mon/mon.d

# Número máximo de procesos que tendrá el monitor
maxprocs = 20

# Número de eventos que serán guardados en el fichero de históricos
histlength = 100

# Tiempo aleatorio (de 0 a 60sg) transcurrido el cual, se arrancará el monitor
randstart = 60s

# Grupo de máquinas a monitorizar
hostgroup ha2 192.168.1.11

# Grupo a monitorizar
watch ha2

# Servicio a monitorizar
service ndb_mgmd

# Intervalo de monitorización
interval 30s

# Script empleado para monitorizar
monitor tcp.monitor -p 1186

# Periodo de monitorización
period wd {Mon-Sun}

# Enviar un correo electrónico en caso de caída del servicio
alert mail.alert -S "[ha2] ndb_mgmd off"
my_mail@gmail.com

# Reiniciar servicio/reiniciar máquina/apagar máquina
alert service_down.alert "/etc/init.d/mysql-ndb-mgm restart" /var/log/mon/mysql-ndb-mgm_status

# Reiniciar el estado del servicio (pasar a "on")
upalert service_up.alert /var/log/mon/mysql-ndb-mgm_status

# Enviar un correo electrónico en caso de recuperación del servicio
upalert mail.alert -S "[ha2] ndb_mgmd on" my_mail@gmail.com

La opción randstart se utiliza para aleatorizar el lanzamiento del primer test durante el arranque de la máquina (el test comenzará inicialmente, transcurrido un tiempo entre cero y el valor de randstart).

Como puede observarse, se han declarado grupos de monitorización (ha1 y ha2) sobre los cuales se comprobarán una serie de servicios (ndb_mgmd). Cada uno de los vigilantes serán definidos mediante el parámetro watch. Dentro de cada vigilante se establecerán los servicios a controlar (service). El periodo de muestreo se configurará mediante los parámetros interval (30 sg) y period (toda la semana). En caso de caída de un servicio, lanzaremos sendas alertas (alert), y cuando éste se recupere, se ejecutarán dos scripts (upalert).

Los scripts de parada (service_down.alert) y arranque (service_up.alert) los programaremos a través de comandos del bash y serán comunes para todos los nodos del cluster (estos ficheros serán analizados en el siguiente artículo).

A continuación vamos a ver los ficheros de configuración de mon para los dos nodos traseros (LB1 y LB2). En estas dos máquinas, mon comprobará el estado de los servicios http, ftp, glusterfs, mysql y ndbd.

root@lb1:~# cat /etc/mon/mon.cf
# Directorio donde residen los ficheros de mon

cfbasedir = /etc/mon

# Directorio donde residen los scripts de alerta
alertdir = /usr/lib/mon/alert.d

# Directorio donde residen los scripts de monitorización
mondir = /usr/lib/mon/mon.d

# Número máximo de procesos que tendrá el monitor
maxprocs = 20

# Número de eventos que serán guardados en el fichero de históricos
histlength = 100

# Tiempo aleatorio (de 0 a 60sg) transcurrido el cual, se arrancará el monitor
randstart = 60s

# Grupo de máquinas a monitorizar
hostgroup lb1 127.0.0.1

# Grupo a monitorizar
watch lb1

# Servicio a monitorizar
service http
interval 30s
monitor http.monitor -u /index.html
period wd {Mon-Sun}
alert mail.alert -S "[lb1] Apache off" my_mail@gmail.com
alert service_down.alert "/etc/init.d/apache2 restart" /var/log/mon/apache2_status
upalert service_up.alert /var/log/mon/apache2_status
upalert mail.alert -S "[lb1] Apache on" my_mail@gmail.com

# Servicio a monitorizar
service ftp
interval 30s
monitor ftp.monitor
period wd {Mon-Sat}
alert mail.alert -S "[lb1] vsftpd off" my_mail@gmail.com
alert service_down.alert "/etc/init.d/vsftpd restart" /var/log/mon/vsftpd_status
upalert service_up.alert /var/log/mon/vsftpd_status
upalert mail.alert -S "[lb1] vsftpd on" my_mail@gmail.com

# Servicio a monitorizar
service glusterfs
interval 30s
monitor tcp.monitor -p 6996
period wd {Mon-Sat}
alert mail.alert -S "[lb1] glusterfs off" my_mail@gmail.com
alert service_down.alert "/etc/init.d/glusterfs-server restart" /var/log/mon/glusterfs_status
upalert service_up.alert /var/log/mon/glusterfs_status
upalert mail.alert -S "[lb1] glusterfs on" my_mail@gmail.com

# Servicio a monitorizar
service mysql
interval 30s
monitor msql-mysql.monitor --mode mysql --username=root --password=javier1 --database=clustertest
period wd {Mon-Sat}
alert mail.alert -S "[lb1] mysql off" my_mail@gmail.com
alert service_down.alert "/etc/init.d/mysql restart" /var/log/mon/mysql_status
upalert service_up.alert /var/log/mon/mysql_status
upalert mail.alert -S "[lb1] mysql on" my_mail@gmail.com

# Servicio a monitorizar
service ndbd
interval 30s
monitor proc.monitor ndbd
period wd {Mon-Sat}
alert mail.alert -S "[lb1] ndbd off" my_mail@gmail.com
alert service_down.alert "/etc/init.d/mysql-ndb restart" /var/log/mon/ndbd_status
upalert service_up.alert /var/log/mon/ndbd_status
upalert mail.alert -S "[lb1] ndbd on" my_mail@gmail.com

Y para el nodo LB2:

root@lb2:~# cat /etc/mon/mon.cf
# Directorio donde residen los ficheros de mon
cfbasedir = /etc/mon

# Directorio donde residen los scripts de alerta
alertdir = /usr/lib/mon/alert.d

# Directorio donde residen los scripts de monitorización
mondir = /usr/lib/mon/mon.d

# Número máximo de procesos que tendrá el monitor
maxprocs = 20

# Número de eventos que serán guardados en el fichero de históricos
histlength = 100

# Tiempo aleatorio (de 0 a 60sg) transcurrido el cual, se arrancará el monitor
randstart = 60s

# Grupo de máquinas a monitorizar
hostgroup lb2 127.0.0.1

# Grupo a monitorizar
watch lb2

# Servicio a monitorizar
service http
interval 30s
monitor http.monitor -u /index.html
period wd {Mon-Sun}
alert mail.alert -S "[lb2] Apache off" my_mail@gmail.com
alert service_down.alert "/etc/init.d/apache2 restart" /var/log/mon/apache2_status
upalert service_up.alert /var/log/mon/apache2_status
upalert mail.alert -S "[lb2] Apache on" my_mail@gmail.com

# Servicio a monitorizar
service ftp
interval 30s
monitor ftp.monitor
period wd {Mon-Sat}
alert mail.alert -S "[lb2] vsftpd off" my_mail@gmail.com
alert service_down.alert "/etc/init.d/vsftpd restart" /var/log/mon/vsftpd_status
upalert service_up.alert /var/log/mon/vsftpd_status
upalert mail.alert -S "[lb2] vsftpd on" my_mail@gmail.com

# Servicio a monitorizar
service glusterfs
interval 30s
monitor tcp.monitor -p 6996
period wd {Mon-Sat}
alert mail.alert -S "[lb2] glusterfs off" my_mail@gmail.com
alert service_down.alert "/etc/init.d/glusterfs-server restart" /var/log/mon/glusterfs_status
upalert service_up.alert /var/log/mon/glusterfs_status
upalert mail.alert -S "[lb2] glusterfs on" my_mail@gmail.com

# Servicio a monitorizar
service mysql
interval 30s
monitor msql-mysql.monitor --mode mysql --username=root --password=javier1 --database=clustertest
period wd {Mon-Sat}
alert mail.alert -S "[lb2] mysql off" my_mail@gmail.com
alert service_down.alert "/etc/init.d/mysql restart" /var/log/mon/mysql_status
upalert service_up.alert /var/log/mon/mysql_status
upalert mail.alert -S "[lb2] mysql on" my_mail@gmail.com

# Servicio a monitorizar
service ndbd
interval 30s
monitor proc.monitor ndbd
period wd {Mon-Sat}
alert mail.alert -S "[lb2] ndbd off" my_mail@gmail.com
alert service_down.alert "/etc/init.d/mysql-ndb restart" /var/log/mon/ndbd_status
upalert service_up.alert /var/log/mon/ndbd_status
upalert mail.alert -S "[lb2] ndbd on" my_mail@gmail.com

May 16, 2009

Eliminar los pitidos del sistema en GNU/Linux

Cuando instalamos un sistema operativo GNU/Linux, los pitidos de la shell (provenientes del altavoz interno del equipo) vienen activados por defecto.

Estos sonidos pueden llegar a ser realmente molestos, ya que son emitidos por ejemplo cuando intentamos tabular un comando o fichero para completar su nombre y no existe ninguna posibilidad para completarlo. También por ejemplo cuando borramos algo que hemos escrito en la línea de órdenes y nos pasamos más allá del inicio de la cadena de texto que queremos suprimir.

Para eliminar de un plumazo estos horribles sonidos, lo único que tenemos que hacer es quitar del kernel de Linux el módulo (pcspkr) responsable de tal acción:

# modprobe -r pcspkr

Si queremos que este cambio sea permanente, es decir, la próxima vez que arranquemos la máquina tampoco se escuchen los pitidos, tendremos que añadir dicha orden al fichero /etc/rc.local, de tal forma que se ejecute cada vez que se inicie el sistema:

# echo "modprobe -r pcspkr" >> /etc/rc.local

Para hacer permanente el cambio, inicialmente probé a añadirlo a la lista negra de módulos del kernel:

# echo "blacklist pcspkr" >> /etc/modprobe.d/blacklist
# echo >> /etc/modprobe.d/blacklist

Pero no funcionó... Al arrancar nuevamente el sistema operativo seguía teniendo el pitido. Comentar que las pruebas las hice en un sistema RHEL 5.3.

También probé después de añadir el módulo a la lista negra, a generar una nueva imagen initrd, ya que podría ocurrir que dicho módulo ya estuviese cargado en la RAM disk que se utiliza durante el arranque del sistema y por eso se omitiera su exclusión en la lista negra. Pero ni con esas...

May 7, 2009

Monitorización de servicios con mon (I)

Una vez que ya tenemos todos los servicios del Sistema de Alta Disponibilidad y Balanceo de Carga configurados, vamos a proceder a su monitorización a través del demonio mon. Recordar que la última entrada que se trató fue la de Balanceo de carga con LVS (III).

Mon es un demonio que permite monitorizar servicios de red, tales como HTTP, FTP, SMTP, POP3, etc. A través de un fichero de configuración (/etc/mon/mon.cf) se definen los servicios a monitorizar, la forma en la que se monitorizarán (basado en scripts) y el periodo de monitorización.


Por ejemplo, para comprobar que Apache está levantado, se puede verificar si el puerto está abierto, si el proceso Apache2 está operativo, si Apache nos devuelve una página concreta ante una determinada petición, etc. Todos estos scripts de monitorización se deben ubicar en /usr/lib/mon/mon.d/.

En el momento en el que un servicio monitorizado falla, mon puede llevar a cabo una serie de medidas (scripts) definidas también en el fichero de configuración. Estos scripts de actuación ante alertas tienen que residir dentro del directorio /usr/lib/mon/alert.d/. En caso de recuperación del servicio, también pueden ser lanzadas otra serie de medidas.

En los dos nodos frontales (HA1, HA2) se va a monitorizar el servicio ndb_mgmd (administrador de los nodos de almacenamiento MySQL). Para ello se comprobará que el puerto 1186 está abierto.

En los dos nodos traseros (LB1, LB2) se monitorizarán los servicios HTTP (se realizará un GET del servidor web y se comprobará que devuelve un resultado correcto), FTP (se comprobará que el puerto 21 está abierto), GlusterFS (se comprobará que el puerto 6996 está abierto), MySQL (se realizará una petición a la base de datos), ndbd (se comprobará que el proceso ndbd está levantado).

Lo primero que haremos será instalar mon en cada uno de los nodos del cluster, pero éste no estará arrancado en el nodo frontal pasivo, ya que el servicio a monitorizar (ndb_mgmd) estará detenido. Mon comprobará cada 30 sg que los servicios configurados están levantados.

Para monitorizar los protocolos HTTP y FTP en los nodos traseros, utilizaremos dos scripts que vienen de serie dentro del directorio /usr/lib/mon/mon.d/, http.monitor y ftp.monitor:

  • HTTP: realizará un GET del servidor y comprobará que le devuelve un resultado correcto.

  • FTP: verificará que el puerto 21 está abierto.
En caso de caída del servicio, se generarán dos alertas previamente configuradas: mail.alert (script que viene con el paquete mon y que se encarga de enviar un correo electrónico a una dirección determinada) y service_down.alert (script que crearemos nosotros y que en primer lugar tratará de reiniciar el servicio; si no lo consigue, reiniciará la máquina, y en caso de que cuando vuelva a arrancar siga estando el servicio caído, la apagará completamente).

Cuando el servicio vuelva a estar operativo, se lanzarán dos scripts: mail.alert (informaremos al administrador por correo electrónico que el servicio vuelve a estar levantado) y service_up.alert (script que crearemos nosotros y que se encargará de restablecer el fichero donde se guardan las pérdidas de servicio).

Además de instalar mon, también instalaremos el paquete sendmail, ya que será utilizado por el script mail.alert para enviar correos electrónicos. También podríamos haber creado otros script que enviaran correos electrónicos utilizando otro MTA, como por ejemplo Postfix.

May 6, 2009

Acerca del libro "Redes Privadas Virtuales"...

He recibido ya varios correos comentándome que mi libro "Redes Privadas Virtuales" ya no estaba a la venta y que tampoco aparecía en Google Books.

La historia es la siguiente: yo auto-publiqué el libro inicialmente a través de Lulu.com, pero a finales de Febrero firmé un contrato con la editorial RA-MA.


Lo que hice a continuación fue quitarlo a la venta de Lulu.com y de los canales de distribución asociados, así como darlo de baja en el programa de afiliación de libros de Google.

Actualmente RA-MA se encuentra maquetando el libro a su formato comercial, y teniendo en cuenta que son casi 900 páginas, es normal que el proceso lleve su tiempo.

Cuando esté a la venta tanto en librerías físicas (El Corte Inglés, La Casa del Libro, etc.) como por Internet, intentaré darlo nuevamente de alta en Google Books.

May 1, 2009

Kubuntu 9.04 Jaunty Jackalope

El Jueves 23 de Abril salió la versión 9.04 de Kubuntu, también conocida como Jaunty Jackalope.


Entre sus principales novedades cabe destacar las siguientes:

  • Kernel 2.6.28-11.42
  • KDE 4.2.2
  • Qt 4.5.0
  • X.Org server 1.6.0
  • OpenOffice 3.0.1
  • Amarok 2.0.2
Una de las principales características de esta distribución es el kernel 2.6.28, el cual ofrece soporte para el sistema de archivos ext4. Sería interesante realizar unas pruebas de rendimiento comparando una Kubuntu 9.04 con un sistema de archivos ext3, y la misma distribución con el sistema ext4.

Yo me he decantado por utilizar un sistema de ficheros ext4 en mi portátil Dell Latitude E4200, y a priori, el tiempo de arranque (hasta la pantalla de login) es sorprendente:

  • Arranque: 15 sg
  • Apagado: 12 sg
Recordar que en su día calculé estos tiempos en una Kubuntu 8.10 y los resultados fueron los siguientes:

  • Arranque: 27 sg
  • Apagado: 12 sg

Con respecto al software de conexión a redes inalámbricas, se ha sustituido el tradicional KNetworkManager por un plasmoide denominado Gestión de red, el cual tiene la funcionalidad de controlar el estado de la red, tanto inalámbrica como por cable.


A su vez, la lista de plasmoides disponibles ha aumentado considerablemente, destacando el Monitor del sistema (ofrece información del hardware), Pastebin (pegar testo/imágenes a un servidor remoto) y el Selector de caracteres (ver, seleccionar y copiar caracteres de una colección de tipos de letra).


También se ha sustituido el tradicional gestor de paquetes Adept por la herramienta KPackageKit (a nivel funcional es similar a Adept, pero mejora su aspecto visual).


Como reproductor de video sigue viniendo el horrible Dragon Player, así que lo primero que hago siempre es instalar el SMPlayer, que no es más que un skin para el MPlayer de toda la vida.


Otro aspecto a reseñar es que esta nueva Kubuntu 9.04 automáticamente instala y configura QtCurve (a través de la herramienta Autoarranque) con el objetivo de que las aplicaciones basadas en GTK se muestren más atractivas dentro de KDE. A continuación se muestra una captura de pantalla de Firefox.


Por último, decir también que la versión que he instalado ha sido la de 64 bits, ya que la llevo usando desde Kubuntu 8.10 y no me ha dado ningún tipo de problema.