Cluster HTTP en alta disponibilidad con CentOS + Heartbeat

En esta entrada vamos a montar un cluster de alta disponibilidad con dos nodos CentOS, Heartbeat y servidor web Apache. A partir de esta configuración básica el cluster puede aumentar su número de nodos según requerimientos de forma gradual y sencilla.

La configuración del cluster es la siguiente:

nodo 1:

IP: 192.168.1.129
HOSTNAME: cluster01

nodo 2:

IP: 192.168.1.130
HOSTNAME: cluster02

IP virtual para el cluster:

IP: 192.168.1.131

Cluster Apache Heartbeat

Una vez configurado en los dos nodos el hostname e IPs (la IP virtual de momento no la tocamos), pasamos directamente a la instalación de Heartbeat y Apache, en ambos nodos deberíamos instalar:

 yum install httpd

Si preferís compilar apache en lugar de usar paquetes precompilados acudir a este post: compilar apache y php.

Nota: Tendréis que configurar Apache para que escuche por la IP virtual, no lo arranquéis todavía:

Listen 192.168.1.131:80

Evitamos que httpd arranque automáticamente, lo hará HeartBeat:

# chkconfig httpd off

Instalamos Heartbeat mediante yum:

# yum install heartbeat

Una vez instalado pasamos a la configuración de Heartbeat. Los ficheros básicos son authkeys, ha.cf y haresources. La ruta en la que debemos configurarlos es /etc/ha.d/. Si necesitamos ejemplos o los ficheros base los podemos encontrar en /usr/share/doc/heartbeat-2.1.2/.

ha.cf

ha.cf es el fichero en el que se especifica la configuración global del cluster. Nuestra configuración base es la siguiente. En el fichero de muestra tenéis información sobre todas las directivas disponibles:

logfile /var/log/cluster.log
logfacility local0
warntime 5
deadtime 30
initdead 120
keepalive 2
bcast eth0
udpport 694
auto_failback on
node cluster01
node cluster02

En primera instancia especificamos que el log donde se volcará toda la información será /var/log/cluster.log. Las directivas de detección de fallo de nodos son las siguientes:

  • warntime: Heartbeat avisará cuando un nodo falle tras 5 segundos.
  • deadtime: Hearbeat confirmará que un nodo ha caído, 30 segundos.
  • initdead: Tiempo máximo que Heartbeat esperará a que un nodo arranque, 60 segundos.
  • keepalive: Especifica cada cuanto tiempo Heartbeat enviará paquetes para comprobar la disponibilidad de los nodos, 2 segundos.

A través de «node» especificamos cada uno de los nodos que componen el cluster (sus hostname), uddport es el puerto UDP utilizado para la comunicación y bcast la interfaz broadcast.

authkeys

Este es el fichero en el que se configura el sistema de autenticación entre todos los nodos del cluster. El formato es el siguiente:

auth num
num algorithm secret

Los algoritmos disponibles son crc (1) sha1 (2) y md5 (3). Se recomienda utilizar sha1 así que lo utilizamos para nuestro cluster. «clu$ter-4uth» será la llave de autenticación (secret):

auth 2
2 sha1 clu$ter-4uth

Únicamente root debe poder leer el fichero, así que asignamos los permisos correspondientes:

# chmod 600 /etc/ha.d/authkeys

haresources

En este fichero se especifican los servicios que se moveran entre los distintos nodos del cluster cuando uno de ellos caiga. En este caso únicamente trabajaremos con httpd, en el propio fichero tenéis toda la información. Le especificamos también la IP virtual asignada al servicio:

cluster01 192.168.1.131 httpd

Propagar cambios de configuración entre nodos

Una vez finalizada la configuración inicial, podemos propagar los cambios entre todos los nodos mediante el comando ha_propagate. Hay que tener conectividad ssh/scp entre las máquinas, si no utilizáis llaves os pedirá la clave ssh de los nodos:

# /usr/lib/heartbeat/ha_propagate
Propagating HA configuration files to node cluster02.

ha.cf                                                                                                                    100%   11KB  10.7KB/s   00:00
authkeys                                                                                                                 100%  672     0.7KB/s   00:00
Setting HA startup configuration on node cluster02.
..
...

Arrancar y probar el cluster

Una vez finalizada la configuración ya podemos proceder a arrancar el cluster, para ello iniciamos HeartBeat en cada uno de los nodos:

# /etc/init.d/heartbeat start

El propio HeartBeat reiniciará Apache, no lo hagáis manualmente:

IPaddr[4618]:    2011/04/19_11:43:02 INFO:  Resource is stopped
ResourceManager[4591]:    2011/04/19_11:43:02 info: Running /etc/ha.d/resource.d/IPaddr 192.168.1.131 start
IPaddr[4694]:    2011/04/19_11:43:02 INFO: Using calculated nic for 192.168.1.131: eth0
IPaddr[4694]:    2011/04/19_11:43:02 INFO: Using calculated netmask for 192.168.1.131: 255.255.255.0
IPaddr[4694]:    2011/04/19_11:43:03 INFO: eval ifconfig eth0:0 192.168.1.131 netmask 255.255.255.0 broadcast 192.168.1.255
IPaddr[4677]:    2011/04/19_11:43:03 INFO:  Success
ResourceManager[4591]:    2011/04/19_11:43:03 info: Running /etc/init.d/httpd  start

En este caso no estamos montando a través de iSCSI, NFS o similar los datos que sirve Apache, de modo que para verificar contra qué nodo del cluster estamos conectando en cada momento podemos crear un index.html básico en cada uno de los nodos, ruta /var/www/html/index.html en el que indiquemos el nodo en el que nos encontramos.

En este momento, si accedermos a http://192.168.1.131 ya deberíamos poder acceder vía web al servicio, y nos indicará que es el cluster01 quien está sirviendo el contenido.

La primera prueba que vamos a hacer para probar el cluster es tirar el nodo cluster01, para ello tiramos la interfaz de red, en mi caso eth0:

# ifdown eth0

Una vez pasado el tiempo especificado en la configuración, en nodo cluster02 debería tomar el control de httpd y servir la web http://192.168.1.131, en el log veréis algo similar a:

heartbeat[2354]: 2011/04/19_11:31:24 WARN: node cluster01: is dead
heartbeat[2354]: 2011/04/19_11:31:24 WARN: No STONITH device configured.
heartbeat[2354]: 2011/04/19_11:31:24 WARN: Shared disks are not protected.
heartbeat[2354]: 2011/04/19_11:31:24 info: Resources being acquired from cluster01.
heartbeat[2354]: 2011/04/19_11:31:24 info: Link cluster01:eth0 dead.
harc[2417]:	2011/04/19_11:31:25 info: Running /etc/ha.d/rc.d/status status
heartbeat[2418]: 2011/04/19_11:31:25 info: No local resources [/usr/share/heartbeat/ResourceManager listkeys cluster02] to acquire.
mach_down[2447]:	2011/04/19_11:31:26 info: Taking over resource group 192.168.1.131
ResourceManager[2473]:	2011/04/19_11:31:27 info: Acquiring resource group: cluster01 192.168.1.131 httpd
IPaddr[2500]:	2011/04/19_11:31:28 INFO:  Resource is stopped
ResourceManager[2473]:	2011/04/19_11:31:28 info: Running /etc/ha.d/resource.d/IPaddr 192.168.1.131 start
IPaddr[2576]:	2011/04/19_11:31:30 INFO: Using calculated nic for 192.168.1.131: eth0
IPaddr[2576]:	2011/04/19_11:31:30 INFO: Using calculated netmask for 192.168.1.131: 255.255.255.0
IPaddr[2576]:	2011/04/19_11:31:31 INFO: eval ifconfig eth0:0 192.168.1.131 netmask 255.255.255.0 broadcast 192.168.1.255
IPaddr[2559]:	2011/04/19_11:31:32 INFO:  Success
ResourceManager[2473]:	2011/04/19_11:31:32 info: Running /etc/init.d/httpd  start
mach_down[2447]:	2011/04/19_11:31:33 info: /usr/share/heartbeat/mach_down: nice_failback: foreign resources acquired
mach_down[2447]:	2011/04/19_11:31:33 info: mach_down takeover complete for node cluster01.
heartbeat[2354]: 2011/04/19_11:31:33 info: mach_down takeover complete.

Y efectivamente, al entrar por navegador a http://192.168.1.131/ accedemos al cluster02.

Esta es la configuración más básica de un cluster HTTP con HeartBeat, a partir de aquí es cuestión de ir haciendo pruebas de failover y failback tirando nodos, levantandolos, y en definitiva, trastear con la configuración, etc ya que HeartBeat permite una gran cantidad de configuraciones.

16 comentarios en “Cluster HTTP en alta disponibilidad con CentOS + Heartbeat

  1. Excelente tutorial, pero me nace una pregunta, entiendo que ambos servidores VPS poseen diferentes ip:

    nodo 1:

    IP: 192.168.1.129
    HOSTNAME: cluster01

    nodo 2:

    IP: 192.168.1.130
    HOSTNAME: cluster02

    pero en el caso de la ip virtual, a cual de los 2 se la debemos asignar? o directamente le asignamos y la cogerá automáticamente de la lista de ips disponibles de ese direccionamiento?

  2. Hola tengo una pregunta. Nose como configurar Apache para que escuche por la IP virtual. Que archivo de apache hay que modificar. o solo hay que poner el comando Listen seguido de la IP VIRTUAL??

  3. Buenos días. Pues creo que no el fichero: sudo less /etc/apache2/httpd.conf lo tengo vacío, probaré a poner ahí mi IP:PUERTO, quedaría mas o menos así.
    Listen 192.168.2.10:80 Ya que está IP ya la tengo montada comó recurso de mi CLUSTER. a ver si tengo suerte. Gracias.

  4. Buenas

    he visto mucha informacion en internet, y lo que deseo es poder correr varios servidores Linux CentOS, los cuales todos «esscriban» sobre el mismo storage.
    Me explico mejor:

    ServerCoreNLB
    Server1 APACHE, MYSQL, CORREO, FTP
    Server2 APACHE, MYSQL, CORREO, FTP

    El ServerCoreNLB lo que me hace es un balanceo de carga. IP Virtual
    Lo que que busco es que Server1 y Server2 accedan al mismo Storage compartido. Indiferentemente donde acceda el usuario la informacion sea la misma. Esto es viable con CentOS 6.x

  5. Hola a todos, necesito que me ayuden; tengo un so Ubuntu 12.04.2 necesito configurar un cluster con heartbeat para conectar 3 máquinas virtuales, dos de las cuales estarán conectadas entre sí, mientras la tercera será la instancia que contendrá la información con Mysql, tambien tengo que fusionarlas usando pacemaker. Mi pregunta: ¿Cómo lo hago, cómo conecto las máquinas para hacer funcionar a heartbeat y pacemaker? me urge. gracias

  6. Excelente tutorial. Necesito una ayuda o aclaración con dos situaciones concretas:
    1.- Ip publica (x ej 198.198.100.10) proporcionada por el proveedor que apunta a un servidor con ip local 192.168.1.1. Ademas tenemos otro servidor 192.168.1.2. Con estos dos vamos a ajustar la configuración del tutorial, la duda es, ¿cual es la ip virtual? ¿una nueva que asignamos nosotros x ej 192.168.1.3? En este caso, supongo habremos de indicar al proveedor que la ip publica que nos ha proporcionado la redirija a la ip virtual que hayamos creado ¿es correcto?
    2.- Dos servidores, ambos con ip publica, ¿es posible aplicar esta configuración? ¿Cual sería la ip virtual?

Comments are closed.