Sencillo cluster de alta disponibilidad con Pacemaker y Corosync

albertomolina, , , ,

Este curso me toca impartir por primera vez una breve introducción a los clusters de alta disponibilidad y después de una clase de introducción y una interesante charla por parte de Arturo Borrero, vamos a montar nuestro primer cluster de alta disponibilidad (High Availability(HA)).

El primer caso que vamos a ver es el que se explica en esta entrada: configurar un cluster de alta disponibilidad activo/pasivo en el que uno de los dos equipos pueda responder siempre a la dirección IP que se pretende mantener en alta disponibilidad. Esta situación no es totalmente real, ya que lo lógico es que esos equipos estén ofreciendo algún servicio que se quiera mantener en alta disponibilidad (ldap, http, https, etc.), sin embargo es muy útil para comprender el funcionamiento del software de HA (pacemaker y corosync) sin las configuraciones adicionales necesarias para ofrecer los servicios en HA, además esta configuración es la base de los clusters reales.

Esquema de red

Para implementar este cluster vamos a utilizar la red de máquinas virtuales que utilizamos a diario en clase y que aparece en la siguiente imagen:

esquema de red

Utilizaremos como nodos del clúster los equipos bobesponja (10.0.0.1) y patricio (10.0.0.2), ambos con debian squeeze y como dirección IP virtual (la que usaremos como un recurso en alta disponibilidad) utilizaremos la 10.0.0.11.

Nota: En un cluster de HA siempre es recomendable que los nodos estén interconectados por interfaces dedicadas en otro segmento de red diferente del que se utiliza para ofrecer los recursos, aunque nosotros por simplicidad utilizaremos el mismo.

Instalación de pacemaker y corosync

En ambos nodos instalamos pacemaker y corosync:

boboesponja:~# apt-get install pacemaker corosync
patricio:~# apt-get install pacemaker corosync

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

bobesponja:~# corosync-keygen
bobesponja:~# scp /etc/corosync/authkey patricio:/etc/corosync/authkey
patricio:~# 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:

bobesponja:~# service corosync restart
patricio:~# service corosync restart

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

root@bobesponja:~# crm_mon
============
Last updated: Sun Mar  4 08:46:15 2012
Current DC: NONE
0 Nodes configured, unknown expected votes
0 Resources configured.
============

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

============
Last updated: Sun Mar  4 08:49:40 2012
Stack: openais
Current DC: bobesponja - partition with quorum
Version: 1.0.9-74392a28b7f31d7ddc86689598bd23114f58978b
2 Nodes configured, 2 expected votes
0 Resources configured.
============

Online: [ bobesponja patricio ]

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:

bobesponja:~# crm configure property stonith-enabled=false

Ahora configuramos el recurso de la IP virtual (10.0.0.11):

bobesponja:~# crm configure primitive FAILOVER-ADDR ocf:heartbeat:IPaddr2 params ip="10.0.0.11" nic="eth0" op monitor interval="10s" meta is-managed="true"

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

============
Last updated: Sun Mar  4 09:15:33 2012
Stack: openais
Current DC: bobesponja - partition with quorum
Version: 1.0.9-74392a28b7f31d7ddc86689598bd23114f58978b
2 Nodes configured, 2 expected votes
1 Resources configured.
============

Online: [ bobesponja patricio ]

FAILOVER-ADDR   (ocf::heartbeat:IPaddr2):       Started bobesponja

Desde un equipo de la red 10.0.0.0/24 probamos a hacer ping a la 10.0.0.11 y verificamos la dirección MAC que responde (bobesponja):

host:~$ ping -c 1 10.0.0.1
ping -c 1 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_req=1 ttl=64 time=0.735 ms

--- 10.0.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.735/0.735/0.735/0.000 ms
host:~$ ping -c 1 10.0.0.11
PING 10.0.0.11 (10.0.0.11) 56(84) bytes of data.
64 bytes from 10.0.0.11: icmp_req=1 ttl=64 time=1.35 ms

--- 10.0.0.11 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.352/1.352/1.352/0.000 ms
host:~$ ping -c 1 10.0.0.2 
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_req=1 ttl=64 time=0.667 ms

--- 10.0.0.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.667/0.667/0.667/0.000 ms
host:~$ cat /proc/net/arp 
IP address       HW type     Flags       HW address            Mask     Device
10.0.0.1         0x1         0x2         52:54:00:af:f8:9d     *        virbr1
10.0.0.11        0x1         0x2         52:54:00:af:f8:9d     *        virbr1
10.0.0.2         0x1         0x2         00:16:36:2d:70:4e     *        virbr1

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

============
Last updated: Sun Mar  4 09:20:54 2012
Stack: openais
Current DC: patricio - partition WITHOUT quorum
Version: 1.0.9-74392a28b7f31d7ddc86689598bd23114f58978b
2 Nodes configured, 2 expected votes
1 Resources configured.
============

Online: [ patricio ]
OFFLINE: [ bobesponja ]

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:

patricio:~# 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:

============
Last updated: Sun Mar  4 09:29:58 2012
Stack: openais
Current DC: patricio - partition WITHOUT quorum
Version: 1.0.9-74392a28b7f31d7ddc86689598bd23114f58978b
2 Nodes configured, 2 expected votes
1 Resources configured.
============

Online: [ patricio ]
OFFLINE: [ bobesponja ]

FAILOVER-ADDR   (ocf::heartbeat:IPaddr2):       Started patricio

Desde el equipo externo podemos comprobar que la dirección IP sigue respondiendo al ping, pero ahora está asociada a la dirección MAC de patricio:

host:~$ ping -c 1 10.0.0.11
PING 10.0.0.11 (10.0.0.11) 56(84) bytes of data.
64 bytes from 10.0.0.11: icmp_req=1 ttl=64 time=1.83 ms

--- 10.0.0.11 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.835/1.835/1.835/0.000 ms
host:~$ cat /proc/net/arp  
IP address       HW type     Flags       HW address            Mask     Device
10.0.0.11        0x1         0x2         00:16:36:2d:70:4e     *        virbr1
10.0.0.2         0x1         0x2         00:16:36:2d:70:4e     *        virbr1

Si por último, volvemos a arrancar bobesponja, éste volverá a ofrecer el recurso:

============
Last updated: Sun Mar  4 09:35:18 2012
Stack: openais
Current DC: patricio - partition with quorum
Version: 1.0.9-74392a28b7f31d7ddc86689598bd23114f58978b
2 Nodes configured, 2 expected votes
1 Resources configured.
============

Online: [ bobesponja patricio ]

FAILOVER-ADDR   (ocf::heartbeat:IPaddr2):       Started bobesponja

Sencillo, ¿no?

Referencias

Sencillo cluster de alta disponibilidad con Pacemaker y Corosync

26 comentarios en “Sencillo cluster de alta disponibilidad con Pacemaker y Corosync”

  2. Santiago Troncoso dijo:

    Buenas,

    Muchas gracias por el tutorial, pero hablas de añadir una línea a la configuración de corosync… pero ¿en base a qué archivo? ¿Podrías añadir dicho archivo de configuración?
    ¿En algún otro post explicas los apartados y configuración de CoroSync?

    Un saludo

    Me gusta

    Responder
  3. Saray Gómez dijo:

    Hola Alberto,

    He seguido tu manual y muchísimas gracias! esta genial, pero tengo una duda, hago los mismos pasos que tu, pero a mi envede ser «bobesponja» el primer nodo me sale «patricio» hay alguna manera de cambiar esa prioridad?

    saludos!

    Me gusta

    Responder
      1. Saray Gómez dijo:

        Después de inicializar Corosync y hacer el primer crm_mon, siempre se me inicializa en el segundo nodo (solo me pasa con estas 2 MV, cosa que encuentro curiosa) de hecho cuando luego intento hacer el comando crm configure primitive FAILOVER-ADDR… no me sale, no me da error pero al hacer otra vez el crm_mon no me sale la frase de FailOver.

        Saludos!

        Me gusta

    1. Hola Andrés,

      Cada servicio que se desea poner en alta disponibilidad recibe el nombre de recurso. Cada recurso debe configurarse de forma explícita y en este sencillo ejemplo que aparece en esta entrada, el recurso que se ha configurado es lo que se conoce como «IP failover» de forma que hay un recurso en modo activo-pasivo que es dirección IP que siempre está definida en uno de los dos nodos del cluster. Normalmente esta es la configuración básica sobre la que se van añadiendo más recursos: apache, tomcat, bind, etc. pero eso no se explica aquí, te recomiendo que leas la excelente documentación de pacemaker clusters from scratch

      Me gusta

      Responder
  8. Pablo dijo:

    Hola Alberto, estoy siguiendo los pasos al dedillo de tu tutorial pero cuando ejecuto por primera vez el comando crm_mon en uno alguno de los nodos para comprobar el estado del cluster me aparece los siguiente:

    Attempting connection to the cluster…Could not establish cib_ro connection: Connection refused (111)

    Sabes a que se debe? Necesito ayuda urgente por favor. Gracias de antemano.

    Me gusta

    Responder
    1. Pablo dijo:

      Me auto respondo. Estaba intentando hacer el tutorial en 2 nodos con Ubuntu Server 14.04. Al probarlo en Debian 7.8 me ha salido todo a la primera. Me parece a mi que apparmor da mucho quebraderos de cabeza en Ubuntu. Es posible que por culpa de apparmor no me conectaran los 2 nodos, es una suposición.

      Muy buen tutorial, mil gracias!

      Me gusta

      Responder
  9. David Moya dijo:

    Hola estoy haciendo mi proyecto para final de grado superior de administración de sistemas y he programado una pequeña aplicación web en jsp para conectarme a una base de datos cassandra, pero tengo en problema que solo me conecto a un nodo por lo tanto si esta cae no consigo HA. Estoy intentando conseguirlo con corosync y pacemaker, básicamente para cuando un nodo caiga este me redireccione al siguiente pero cuando pongo la ip virtual en mi programa en vez de la de un nodo me falla la conexión.¿Alquien podria ayudarme?Gracias un saludo.

    Me gusta

    Responder
  10. Franco Cavallotto dijo:

    Hola como estas? estoy siguiendo tu tuto, porque necesito hacer este trabajo para la facu..
    el tema esta en que cuando hago CRM_MON solo me apacere el nodo an el cual estoy..osea si lo hago en bobesponja, solo me aparece nline bobesponja. espero puedas ayudarme!!
    saludos y muchas gracias..

    Me gusta

    Responder

  11. Buen post, veo que lo has hecho sobre Debian,en el cual no se si hay problemas,yo he realizado tu manual pero sobre Ubuntu 14.04 en el cual si hay problemas. Os indico.
    Todo va fenomenal como indicas en el articulo pero cuando hago crm_mon(despues de reiniciar) me pone los dos nodos «offline» entonces digo,¿por que?. Pues bien parece ser que pacemaker tiene un error que evita que se inicie automaticamente al inicio por ello debemos de escribir el siguiente comando en /etc/rc.local(antes de la linea exit 0)

    sudo service pacemaker start

    Solucionado.

    Con respecto a la ip virtual no lo he probado como tu lo has hecho,yo he creado una ip virtual asociada a cada nic de los nodos en /etc/network/interfaces añadiendo lo siguiente(en ambos)

    auto eth0:0
    iface eth0:0 inet static
    address TU_IP_VIRTUAL
    netmask TU_MASCARA

    Y va todo genial.Gracias por el aporte,saludos.

    Me gusta

    Responder

    1. Hola Enrique,

      Esta entrada está un poco desfasada, pero en cualquier caso explica los pasos iniciales que hay que dar en un cluster de alta disponibilidad con pacemaker y corosync para tener una VIP configurada, luego están los pasos siguientes que tienes que dar para configurar el servicio que realmente quieras ofrecer en alta disponibilidad. Con respecto al almacenamiento hay varias opciones, quizás la más sencilla sea DRBD que puedes ver en la doc oficial:

      http://clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Clusters_from_Scratch/ch07.html

      Me gusta

      Responder
  13. Mario dijo:

    Hola muchas gracias por el tutorial, estoy realizando todos los pasos en casa pero llegado el momento de configuracion (para el arranque automatico de corosync) no me aparece el parametro START (/etc/default/corosync). Sabrias por que me puede succeder esto. Muchas gracias de antemano y un saludo.

    Me gusta

    Responder

Deja un comentario