Cluster Apache, con DRBD, corosync y pacemaker

En la entrada de hoy, vamos  a ver cómo configurar un cluster de un servidor web apache. En este ejemplo vamos a ver cómo implementar un cluster de dos nodos del tipo Activo/Pasivo, es decir uno de los nodos prestará el servicio y si en algún momento se produce una falla, será el otro nodo el que pasará a prestar esos servicios.

Para ello vamos a utilizar tres herramientas:

• DRBD: que nos permitirá replicar los datos de una partición entre ambos nodos, es decir, crearemos algo similar a un RAID1 a través de la red entre ambas máquinas.
• corosync: que se encargará de la comunicación entre los nodos del cluster
• pacemaker: que se encargará de la gestión de los recursos del cluster.
  

Para este tutorial he utilizado dos maquinas con ubuntu server:

server1: con IP 172.16.1.1/24

server2: con IP 172.16.1.2/24

Como IP virtual para el cluster he utilizado la IP 172.16.1.3/24

Instalación y configuración de DRBD

Lo primero que vamos a hacer es instalar drbd en server1 y server2.Nos movemos a la carpeta «/usr/local/src»:

root@server1:~# cd /usr/local/src/

Descargamos la última versión de drbd:

root@server1:/usr/local/src# wget http://oss.linbit.com/drbd/drbd-utils-latest.tar.gz

Descomprimimos el fichero:

root@server1:/usr/local/src# tar xzvf drbd-utils-latest.tar.gz

Accedemos a la carpeta:

root@server1:/usr/local/src# cd drbd-utils-8.9.6/

Y compilamos e instalamos el paquete. He añadido los parámetros necesarios para que los binarios, ficheros de configuración, etc… se coloquen en las carpetas adecuadas, de esta manera nos ahorraremos el trabajo de buscarlos y crear enlaces:

root@server1:/usr/local/src/drbd-utils-8.9.6# ./configure --prefix=/usr --localstatedir=/var --sysconfdir=/etc  && make && make install

Creamos un nuevo fichero con el recurso drbd, en «/etc/drbd.d» en el ejemplo lo he llamado r1.res:

root@server1:~# nano /etc/drbd.d/r1.res

En mi caso el fichero queda asi:

resource r1 {
protocol C;
meta-disk internal;
device    /dev/drbd0;
disk      /dev/sdb1;
net {
#allow-two-primaries;
cram-hmac-alg "sha1";
shared-secret "Alberto";
after-sb-0pri discard-zero-changes;
after-sb-1pri discard-secondary;
after-sb-2pri disconnect;
rr-conflict violently;
}

startup {
wfc-timeout 60;
#become-primary-on both;
}

syncer {
rate 10M;
}
on server1 { address 172.16.1.1:7789; }
on server2 { address 172.16.1.2:7789; }
}

El contenido de este fichero es idéntico en ambos servidores, por lo que podemos copiar el fichero directamente en server2. En mi caso lo he copiado mediante scp:

root@server1:/etc/drbd.d# scp r1.res 172.16.1.2:/etc/drbd.d/

Ahora vamos a particionar el disco que vamos a utilizar con drbd(en el ejemplo /dev/sdb). Lo hacemos también en ambos servidores:

root@server1:~# fdisk /dev/sdb

Escribimos «n» para crear una nueva partición, en el ejemplo le he indicado que será una partición primaria «p», numero de partición «1» y una vez finalice, guardamos los cambios con «w»

root@server2:~# fdisk /dev/sdb
El dispositivo no contiene una tabla de particiones DOS válida ni una etiqueta de disco Sun o SGI o OSF
Se está creando una nueva etiqueta de disco DOS con el identificador 0x4231208e.
Los cambios sólo permanecerán en la memoria, hasta que decida escribirlos. 
Tras esa operación, el contenido anterior no se podrá recuperar.

Atención: el indicador 0x0000 inválido de la tabla de particiones 4 se corregirá mediante w(rite)

Orden (m para obtener ayuda): n
Tipo de partición:
   p primaria (0 primaria, 0 extendida, 4 libre)
   e extendido
Seleccione (predeterminado p): p
Número de partición (1-4, valor predeterminado 1): 1
Se está utilizando el valor predeterminado 1
Primer sector (2048-2097151, valor predeterminado 2048): 
Se está utilizando el valor predeterminado 2048
Último sector, +sectores o +tamaño{K,M,G} (2048-2097151, valor predeterminado 2097151): 
Se está utilizando el valor predeterminado 2097151

Orden (m para obtener ayuda): w
¡Se ha modificado la tabla de particiones!

Llamando a ioctl() para volver a leer la tabla de particiones.
Se están sincronizando los discos.

En ambos servidores creamos el dispositivo drbd para el recurso r1 mediante el siguiente comando:

root@server1:~# drbdadm create-md r1

Ahora iniciamos el servicio en los dos servidores:

root@server1:~# service drbd start

Los siguientes dos pasos, solo es necesario realizarlos en uno de los dos servidores. En el ejemplo yo los he ejecutado en server1.
Establecemos el servidor como primary:

root@server1:~# drbdadm -- --overwrite-data-of-peer primary all

y formateamos el dispositivo drbd:

root@server1:~# mkfs.ext4 /dev/drbd0

Podemos ver como se van sincronizando los discos:

root@server1:~# cat /proc/drbd

Una vez sincronizado, vemos como muestra en ambos servidores como «UpToDate»:

Instalación y configuración del cluster

Comenzamos instalando los paquetes necesarios en ambos servidores, corosync, pacemaker, ntp y el servidor apache:

root@server1:~# apt-get install pacemaker corosync apache2 ntp

Cambiamos el usuario y grupo propietario del directorio «/var/lib/heartbeat» en ambos servidores:

root@server1:~# chown -R hacluster:haclient /var/lib/heartbeat

Generamos la clave de autenticación de corosync en server1:

root@server1:~# corosync-keygen

La clave generada se encuentra en «/etc/corosync/authkey» ahora tenemos que copiarla en server2:

root@server1:~# scp /etc/corosync/authkey 172.16.1.2:/etc/corosync/

Nos aseguramos que el propietario sea root y que tiene los siguientes permisos:

Editamos el fichero «/etc/default/corosync» y ponemos el «START en yes» para que corosync se inicie al arranque del sistema en los dos servidores:

root@server1:~# nano /etc/default/corosync

Lo vemos en la captura:

Y ahora hacemos que pacemaker se inicie también al arranque en los dos servidores:

root@server1:~# update-rc.d pacemaker defaults

También en ambos servidores tendremos que especificar la red en la que se va a escuchar el heartbeat de Pacemaker. Esto se hace en «/etc/corosync/corosync.conf»:

root@server1:~# nano /etc/corosync/corosync.conf

Y modificamos el parámetro «bindnetaddr» donde especificaremos la red en la que pacemaker escuchará el latido (hertbeat):

Vamos a deshabilitar el arranque automático de los servicios apache2 y drbd porque estos servicios los pasará a gestionar el cluster:

root@server1:~#  update-rc.d -f drbd remove
root@server1:~# update-rc.d -f apache2 remove

Podemos comprobar el estado del cluster

root@server1:~# crm status

Como vemos en la captura anterior, ya tenemos los dos nodos online, por lo que podemos proceder a configurar los recursos del cluster.

A partir de ahora solo será necesario realizar las configuraciones que afecten al cluster en uno de los nodos, puesto que lo que configuremos en uno, se propagará al otro.

Escribimos «crm configure» para entrar en la configuración del cluster:

root@server1:~# crm configure

Antes de configurar los recursos vamos a deshabilitar el «stonith» y el «quorum» puesto que en un cluster de solo dos nodos no serán necesarios:

crm(live)configure# property stonith-enabled=false
crm(live)configure# property no-quorum-policy=ignore

Recurso para el servicio Apache, definimos el recurso que gestionará el servicio de apache en el cluster:

crm(live)configure# primitive APACHE lsb:apache2

Recurso para drbd, definimos un recurso para gestionar el servicio drbd de nuestro cluster:

crm(live)configure# primitive drbd_APACHE ocf:linbit:drbd params drbd_resource="r1" op monitor interval="15s"

Recurso para el sistema de ficheros, definimos un recurso para gestionar el sistema de ficheros. En este caso le estamos indicando el disco y la carpeta en la que se tiene que montar:

crm(live)configure# primitive fs_APACHE ocf:heartbeat:Filesystem params device="/dev/drbd0" directory="/var/www/html" fstype="ext4"

Recurso IP para el cluster, en este recurso definimos una IP virtual que será la que asuma el nodo que este como master, de tal forma que independientemente del nodo que este como master nosotros podamos acceder a los recursos a través de esa IP virtual:

crm(live)configure# primitive ip_APACHE ocf:heartbeat:IPaddr2 params ip="172.16.1.3" nic="eth1"

Grupo de recursos, por comodidad y para facilitar la gestión, creamos un grupo de recursos, cada elemento del grupo se irá ejecutando de forma secuencial:

crm(live)configure# group APACHE_GROUP fs_APACHE ip_APACHE APACHE

Recurso Multistate,  creamos este tipo de recurso para el recurso «drbd_APACHE» este tipo de recurso es el que se encarga de permitir que los diferentes nodos asuman el rol «master» o «slave»:

crm(live)configure# ms ms_drbd_APACHE drbd_APACHE meta master-max="1" master-node-max="1" clone-max="2" clone-node-max="1" notify="true"

Colocation, ahora configuramos una constraint en la que definimos donde deben ejecutarse los recursos, en el ejemplo le estamos diciendo que ejecute los recursos en el nodo que asuma el rol de master, es decir el que este como primary en el drbd:

crm(live)configure# colocation APACHE_on_drbd inf: APACHE_GROUP ms_drbd_APACHE:Master

Order, ahora configuramos una constraint en la que establecemos el orden en que se ejecutarán los recursos, primero se ejecutará el recurso «multistate» y una vez haya promocionado un nodo a «master» se ejecutarán en él los recursos del grupo apache:

crm(live)configure# order APACHE_after_drbd inf: ms_drbd_APACHE:promote APACHE_GROUP:start

Y hacemos el «commit» de los cambios:

crm(live)configure# commit

Y podemos salir de la configuración del cluster:

crm(live)configure# quit

Si queremos revisar la configuración completa podemos hacerlo con «crm configure show»:

Ahora comprobamos el estado del cluster:

Como vemos en la captura anterior, actualmente los recursos del cluster ese están ejecutando en el server1.

Podemos probar a poner el server1 en stanby mediante los siguientes comandos:

Y comprobamos que los recursos del cluster ahora están ejecutándose en el server 2:

Independientemente de en que nodo se estén ejecutando los recursos, nosotros siempre podremos acceder a ellos mediante la IP virtual que hemos definido anteriormente(en el ejemplo la 172.16.1.3):

Y hasta aquí hemos llegado con la entrada de hoy, os recomiendo visitar las webs de las diferentes herramientas que hemos utilizado para que podáis haceros una idea de las posibilidades que ofrecen.