Linux permite la creación de sistemas en cluster formados por al menos dos máquinas, en el que se pueden crear servicios en alta disponibilidad que pueden superar situaciones en las que una de las máquinas sufra un problema de pérdida de servicio. De esta forma, aunque una de las máquinas deje de estar disponible (por fallo hardware o software), el servicio puede continuar estando disponible desde la otra máquina sin que haya apenas corte en el servicio ofrecido, proporcionando alta disponibilidad de aplicaciones.
Para implementar este tipo de soluciones se puede hacer uso de hearbeat, que es un software que permite enviar «pulsos» entre ambos servidores para detectar cuando uno de ellos tiene algún problema, y de esta forma poder mover los servicios configurados al otro nodo. También, por supuesto, se pueden programar diferentes chequeos para mover servicios en caso de que se detecte algún fallo de software, con mon, monit u otro similar.
Por tanto, la idea básica de heartbeat es que se definen uno o varios servicios para los que se desea obtener alta disponibilidad (apache, mysql, …) entre varios servidores en modos activo/pasivo o activo/activo, y heartbeat se encargará de hacer que estos servicios estén siempre ejecutándose mientras uno de los dos nodos esté funcionando correctamente.
Prerrequisitos
Alguno de los prerrequisitos para montar un sistema de clúster con heartbeat son los siguientes:
- Un interfaz de red para ofrecer el servicio
- Un interfaz de red para los pulsos heartbeat. Habitualmente un cable cruzado entre ambos servidores
- Conexión por cable serie cruzado entre servidores, por si hay algún error con la conexión ethernet. Si las máquinas no tienen puerto serie, se puede utilizar un conversor USB-Serie que funcionan sin problema.
Instalación
La instalación es tan sencilla como lo siguiente:
# apt-get install heartbeat
Configuración
Los ficheros de configuración se encuentran en /etc/ha.d. Al menos, hay que configurar tres ficheros. Por un lado, una clave secreta y compartida solamente en estos dos servidores, por ejemplo:
maquinaA-dedi:/etc/ha.d# cat authkeys
auth 2
#1 crc
2 sha1 uhmuHsiK_52,diWJiwLm
#3 md5 Hello!
Por otro lado, el fichero de configuración general de heartbeat (ha.cf). En este fichero se especifican las opciones de configuración generales que establecen los interfaces por los que se envían los pulsos, los ficheros de log, los nodos que forman parte del cluster,… por ejemplo:
debugfile /var/log/ha-debug
logfile /var/log/ha-log
serial /dev/ttyS0 # Linux
bcast eth1 eth2 # Linux
auto_failback off
node maquinaA-dedi.acens.net maquinaB-dedi.acens.net
Y por último, en el fichero haresources se especifican los servicios que forman parte del cluster y que estarán en alta disponibilidad, por ejemplo:
maquinaA-dedi.acens.net IPaddr::X.X.X.X/29/eth0 drbddisk::r0 Filesystem::/dev/drbd0::/shared::ext3 drbdlinks mysql apache2
En el ejemplo anterior, se especifica que uno de los servicios del cluster es IPaddr::X.X.X.X/29/eth0, eso significa que en el nodo activo del cluster se configurará la dirección IP X.X.X.X. Esta es la IP de servicio y es la que se suele asociar a los servicios en alta disponibilidad que se presten en la máquina.
Además de la dirección IP, también se especifica que se va a utilizar el dispositivo drbd r0, que configuramos anteriormente, en el nodo activo, y por tanto será montado automáticamente en el mismo por heartbeat.
Por último, aparecen los servicios drbdlinks, mysql y apache2. Esto significa que cuando un nodo se convierte en primario, se ejecutará lo siguiente de forma automática:
# /etc/init.d/drbdlinks start
# /etc/init.d/mysql start
# /etc/init.d/apache2 start
NOTA: Es importante tener en cuenta que los servicios gestionados por heartbeat (drbdlinks, mysql y apache2 en este ejemplo) deben ser deshabilitados de los niveles de ejecución predeterminados para que no sean arrancados al entrar en ellos, porque será heartbeat el que se encargue de pararlos o arrancarlos cuando corresponda. Para ello, en Debian habría que hacer lo siguiente:
# update-rc.d –f drbdlinks remove
# update-rc.d –f apache2 remove
# update-rc.d –f mysql remove
El servicio drbd si debe estar activo en los niveles de ejecución predeterminados, porque se encarga de cargar el módulo de kernel correspondiente y de disponer los metadispositivos disponibles, pero no de poner activo en el nodo primario, de esto último se encargará heartbeat.
Muy bien explicado.
Como se comporta un disco san presentado a uno de los servidores del cluster, como deberia verlo el otro ?
ffsierra.ffs@gmail.com
Fabian, ¿te refieres a un disco iSCSI o FC por ejemplo? Pues en ese caso, el disco puede estar presentado a ambas máquinas, pero solo una de ellas puede «montar» ese disco al mismo tiempo, a no ser que tengas un sistema de ficheros que lo soporte (OCFS de Oracle, GFS de RedHat, …).
Lo normal es que monte y utilice el disco el servidor activo, y que tengas algún script que permita hacer lo propio en el pasivo cuando tenga el servicio. Ese script debe estar incluído en los que gestiona heartbeat para tu clúster activo/pasivo.