Heartbeat, mi configuración
Cuando estaba leyendo documentación, acerca de heartbeat lo que más me gustó, es el nombre de la técnica utilizada para nodeFencing, STONITH: “Shut the other node in the head”, que buen hack ;), a groso modo cuando un nodo del cluster es declarado muerto, este se asegura de que realmente lo esté, con un tiro de gracia. http://www.linux-ha.org
Bueno este post no es un tutorial, solamente son mis archivos de configuración para heartbeat, para crear un servidor web de alta disponibilidad (cluster de alta disponibilidad), es decir dos máquinas(por que solo tengo 2 :p), una sirve normalmente la página y si falla la otra la reemplaza hasta que se restablezca el servicio en la primera.
Como nota inicial, me recuerdo que el demonio de log ya no se configura en /etc/ha.d/ha.cf si no en /etc/logd.cf
Vamos al grano, necesitamos configurar 3 archivos dentro de /etc/ha.d
ha.cf, haresources y authkeys
Primero ha.cf:
# archivo donde escribir los logs
debugfile /var/log/ha-debug
# archivo a donde escribir los mensajes
logfile /var/log/ha-log
# Facility to use for syslog()/logger
logfacility local0
# keepalive: que tanto tiempo se debe esperar entre latidos?
keepalive 2
# deadtime: que tanto se debe esperar para declarar un host
# muerto?
deadtime 30
# que tanto antes de que se lance una advertenia de un “latido
#de corazón, retrazado” warntime 10
warntime 10
# Cuando se reinicia un sist. operativo puede haber un retraso
# en el inicio del correcto funcionamiento de la red.
initdead 120
#initdead 100 What UDP port to use for bcast/ucast communication? Qué
# puerto UDP usar para la comunicación broadcast/unicast.
udpport 694
# La frecuentia, baudios para puertos seriales
baud 19200
# What interfaces to broadcast heartbeats over? En que interfaz
# se debe lanzar el broadcast (para la comunicación entre los
# modos.
bcast br0
# Linux, en el otro nodo se lo pongo a eth0
# Configurar un medio multicast para heartbeat
mcast eth0 225.0.0.1 694 1 0
# configurar un medio unicast/udp para heartbeat
ucast eth0 192.168.5.19
# Le decimos que cuando se restablesca el nodo maestro, le
# retorne el control del servicio
auto_failback on
# Le decimos que máquinas están en el custer
node linuxha1
node linuxha2
# Agrega un pseudo miembro del cluster para que sea usado por
# todos como referencia por si la conexión de red falla.
# Idealmente debe ser un switch o un cluster que no forma parte
# del custer. Es decir, van a estar haciendo ping a este nodo,
# si no alcanzan respuesta dirán, ho no!!!, estamos
# desconectados.
ping 192.168.5.1
# Definimos la aplicación que se encargará de la detección de
#fallos y la conectividad respawn userid /path/name/to/run
respawn hacluster /usr/lib/heartbeat/ipfail
# Esto ya no hace lo que tu crees, debes usar para eso /etc/logd.cf
use_logd yes
haresources:
# En este archivo indicamos el servicio que vamos a mantener, con
# halta disponibilidad. en este caso el host llamado “linuxha1″ es el
# nodo maestro, brindando el servicio apache2 (servidor web) Respecto
# a los nombres, asegurense de configurar en cada máquina los nombres
# correctos de host en /etc/hostname (nombre local de la computadora)
# y en /etc/hosts el listado de nombres de los nodos y su la ip que le
# corresponde.
linuxha1 192.168.5.21 apache2
authkeys:
#Aca indicamos el método y la contraseña, para la autenticación entre nodos.
auth 3
#1 crc
#2 sha1 HI!
3 md5 acavaelpassword