Continuando con el Sistema de Alta Disponibilidad y Balanceo de Carga que se está desarrollando (el último punto que se trató fue el cluster para base de datos), vamos a instalar Heartbeat en los dos nodos frontales (HA1 y HA2), configurando el nodo HA1 como activo y el nodo HA2 como pasivo.
Si recordamos el primer artículo que se desarrolló en donde se presentaba el esquema general del cluster, el sistema estaba formado por dos nodos frontales en donde sólo uno de ellos iba a estar activado (HA1), recibiendo las peticiones y balanceándolas a continuación a los dos nodos traseros. La máquina activa iba a tener dos direcciones IP virtuales configuradas (se denominan virtuales porque cuando HA1 falle, HA2 las asumirá), 192.168.1.20 y 10.0.0.20, y una serie de servicios levantados.
¿Cómo funciona todo esto? Es muy sencillo, el Heartbeat del nodo activo (HA1) enviará periódicamente "latidos" al nodo pasivo (HA2) para indicarle que sigue vivo. En caso de que el nodo pasivo no reciba los latidos, interpretará que el nodo HA1 está caído, y en consecuencia pasará a modo activo, levantando automáticamente las direcciones IP virtuales y arrancando los servicios gestionados.
Los latidos pueden ser enviados a través de cualquiera de los interfaces de red, y también como complemento y de forma redundante, a través de un cable serie.
Y con el objetivo de incrementar más aun la fiabilidad del sistema, vamos a instalar un watchdog software que se encargue de controlar a Hearbeat. Si Heartbeat se cae, el watchdog reiniciará la máquina transcurrido un minuto.
Vamos a comenzar instalando los paquetes watchdog y heartbeat en ambos nodos frontales.
~# aptitude install watchdog heartbeat
Heartbeat utiliza tres tipos de ficheros: authkeys (lugar donde se establece la contraseña compartida por los dos nodos), ha.cf (fichero de configuración de Heartbeat) y haresources (fichero donde se indica cuál será el nodo activo, así como los servicios a gestionar).
A continuación se muestra el contenido del fichero authkeys. Este archivo será idéntico en ambos nodos frontales y por seguridad, deberá tener exclusivamente permisos de lectura/escritura para el usuario root.
~# cat /etc/ha.d/authkeys
auth 1
1 md5 d2R5h4!
~# chmod 600 /etc/ha.d/authkeys
Este fichero contiene información que Heartbeat utiliza para autenticar a los miembros del cluster. La primera línea indica a Heartbeat qué clave debe utilizarse para firmar los paquetes salientes (latidos), ya que se pueden definir varias claves en el mismo archivo. La siguiente línea indica el algoritmo que se utilizará para firmar los paquetes (md5) y la propia clave privada con la que se realizará la firma (d2R5h4!).
El siguiente fichero que vamos a tratar va a ser ha.cf. Este archivo se encarga de listar los nodos del cluster (en este artículo cuando hablamos de cluster, nos estamos refiriendo al cluster de Alta Disponibilidad, es decir, los dos nodos frontales), la topología de comunicación y las características de la configuración que están habilitadas.
~# cat /etc/ha.d/ha.cf
# Archivo donde se escribirán los mensajes de debug
debugfile /var/log/ha-debug
# Archivo donde se escribirán el resto de mensajes
logfile /var/log/ha-log
# Facility a emplear por el syslog
logfacility local0
# Tiempo transcurrido entre el envío de cada uno de los latidos (segundos)
keepalive 2
# Tiempo transcurrido hasta declarar al nodo como caído (segundos)
deadtime 12
# Tiempo transcurrido antes de generar un warning (segundos)
warntime 6
# Tiempo transcurrido para comenzar a levantar los servicios (segundos)
initdead 18
# Puerto para la comunicacion UDP
udpport 694
# Interfaz utilizado para enviar los mesajes de broadcast
bcast eth0
# Interfaz y nodo al que enviar los latidos
ucast eth0 ha2
# Si el nodo se cae y se vuelve a recuperar, recuperara su rol original
auto_failback on
# Si el Heartbeat local no envía latidos en un minuto, reinicia la maquina
watchdog /dev/watchdog
# Maquinas que conforman el cluster
node ha1
node ha2
Este fichero será el mismo en ambos nodos, lo único que cambiará será la línea ucast eth0 haX, que en el caso del nodo HA1 será ucast eth0 ha2 (enviar los latidos al nodo HA2 a través del interfaz eth0) y para HA2 ucast eth0 ha1 (enviar los latidos al nodo HA1 a través del interfaz eth0).
Y ya para finalizar, el último fichero que habrá que configurar será haresources. Este archivo se utilizará para definir los recursos que Heartbeat deberá gestionar. Será el mismo para los dos nodos.
~# 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
La línea de datos está formada por dos parámetros, el primero de ellos es el nombre o dirección IP de la máquina activa (HA1, recordar que definimos las direcciones IP asociadas al nombre de la máquina en el fichero /etc/hosts) y el segundo parámetro será la lista de recursos a gestionar. Es necesario establecer una tabulación a continuación del primer parámetro.
Dentro de la lista de recursos, Heartbeat levantará en la máquina activa las dos direcciones IP virtuales (192.168.1.20 y 10.0.0.20) y arrancará un grupo de servicios, como por ejemplo el demonio de administración del cluster MySQL (mysql-ndb-mgm). El resto de servicios serán detallados en los siguientes artículos. A su vez en la máquina pasiva, las dos direcciones IP virtuales no estarán configuradas y los servicios serán detenidos.
Los servicios definidos en haresources se lanzan de izquierda a derecha cuando Heratbeat los arranca (start), y los detiene de derecha a izquierda (stop).
Debido a que Hearbeat se encarga de la administración de dichos servicios (sus scripts de gestión residen en /etc/init.d/), habrá que eliminar todos los enlaces relacionados que se encuentren dentro del directorio /etc/rc[nivel_de_seguridad].d/. Vamos a eliminar en ambos nodos el enlace a mysql-ndb-mgm. El resto de enlaces de los otros servicios los iremos quitando a medida que vayamos viendo sus funciones en los siguientes artículos.
~# update-rc.d -f mysql-ndb-mgm remove
Cuando el sistema esté en funcionamiento (nodo HA1 activo y nodo HA2 pasivo), si hacemos la prueba de matar al demonio de Heartbeat en HA1 (~# pkill heartbeat), al visualizar el log de Heartbeat en el nodo HA2 podremos ver los siguientes mensajes:
root@ha2:~# >/var/log/ha-log ; tail -f /var/log/ha-log
WARN: node ha1: is dead
info: Dead node ha1 gave up resources.
info: Resources being acquired from ha1.
info: Link ha1:eth0 dead
....
Es decir, podremos apreciar cómo HA2 ha detectado la caída de HA1 y a continuación este último asumirá el rol de activo, levantando las dos direcciones IP virtuales y los servicios gestionados.
Para iniciar, detener o reiniciar Heartbeat se pueden emplear los siguientes comandos:
~# /etc/init.d/heartbeat start
~# /etc/init.d/heartbeat stop
~# /etc/init.d/heartbeat restart
muy interesante
ReplyDeleteysi matamos el demonio de mysql ?? o si mysql no responde ??? levanta el nodo2 o no ??
ReplyDeleteCuando desactivo un nodo me elimina todas las ip virtuales, sabrias porque?
ReplyDeleteHola soy nuevo en esto me gustaria saber si dentro de hearbeat se puede configurar algun tipo de algoritmo de balanceo de cargas como roud robin entre otros ... Muchas gracias saludos
ReplyDelete