Vamos a montar el esquema de red, en primer lugar la red del virtual box que vamos a usar será la 10.0.0.11, nos vamos a archivo, preferencias, red, redes solo anfitrión, marcamos la red, le damos al destornillador y ponemos la red que queramos.

Lo siguiente que hacemos es coger dos máquinas que pondremos en modo de red solo anfitrión, que harán de nodos.

Ponemos la red manualmente en cada máquina desde el archivo /etc/network/interfaces. Y luego la bajamos y subimos con ifdown eth0 ifup eht0.

Ponemos el nombre en ambas máquinas desde /etc/hostname.

En ambas máquinas instalaremos pacemaker y corosync.

apt-get update

apt-get install pacemaker corosync

Creamos en bobesponja la clave de autenticación de corosync y la copiamos a patricio:

corosync-keygen

scp authkey root@192.168.1.123: /etc/corosync

En Ubuntu no tienes permisos como root, así que hay que enviarlo a una carpeta que el usuario tenga permisos como /home/usuario y luego copiarlo a /etc/corosync. Así que el comando sería: scp authkey usuario@192.168.1.123: /home/usuario y luego

cp /home/usuario/authkey /etc/corosync/.

En patricio le damos permisos para poder acceder al archivo

chmod 400 /etc/corosync/authkey

Editamos el fichero de configuración de corosync (/etc/corosync/corosync.conf) de ambos nodos y añadimos la red que se va a utilizar para controlar el latido entre los nodos (en nuestro caso va a ser la misma por la que se ofrecen los recursos, pero lo habitual sería que fuese una interfaz dedicada):

bindnetaddr: 10.0.0.0

Además para que corosync se inicie de forma automática al arrancar la máquina, marcamos a “yes” el parámetro START del fichero de configuración del demonio (/etc/default/corosync) en ambos nodos.

Reiniciamos corosync en los dos nodos: service corosync restart.

En Ubuntu hay que reiniciar también el servicio de pacemaker con service pacemaker restart.

Si comprobamos el estado del cluster con crm_mon, podremos comprobar que inicialmente tenemos algo como:

Pero al cabo de unos instantes, pasamos al siguiente estado:

Donde podemos comprobar que los dos nodos se han detectado, aunque todavía no hay ningún recurso configurado.

Configuración de la IP virtual como recurso

El recurso que vamos a configurar en este ejemplo va a ser una dirección IP 10.0.0.11, para ello en primer lugar desactivamos el mecanismo de STONITH (Shoot The Other Node In The Head), que se utiliza para parar un nodo que esté dando problemas y así evitar un comportamiento inadecuado del cluster:

crm configure property stonith-enabled=false

Después escribimos lo siguiente:

Al monitorizar ahora el cluster, veremos que aparece el recurso FAILOVER-ADDR asociado en este momento a bobesponja:

Hacemos ping para comprobar.

Ahora probamos el funcionamiento del cluster apagando bobesponja y monitorizamos el cluster desde patricio:

Sin embargo patricio no pasa a ofrecer el recurso directamente porque no hay cuórum en el cluster. El cuórum (quorum) es una propiedad que utiliza pacemaker para tomar las decisiones apropiadas mediante consultas consensuadas a todos los nodos, pero no tiene razón de ser en un cluster de solo dos nodos, ya que sólo habrá quorum cuando los dos nodos estén operativos, así que ignoramos las decisiones basadas en cuórum:

crm configure property no-quorum-policy=ignore

Podemos comprobar ahora como patricio pasa a ofrecer el recurso, aunque nos advierte que no ha habido cuórum a la hora de tomar esa decisión:

Se baja la interface de Patricio con ifdown eth0, y salta bobesponja a seguir enviando los ping.

Configuración del recurso apache.

Configuraremos el recurso para apache:

crm configure primitive P_APACHE ocf:heartbeat:apache params configfile="/etc/apache2/apache2.conf" statusurl="http://localhost/server-status" op monitor interval="40s"

Pondremos el orden en el que mirara el estado

crm configure order START_ORDER inf: FAILOVER-ADDR P_APACHE