Aproximacin al clustering de alta disponibilidad ---
(I) Cluster bsico de alta disponibilidad con Corosync+Pacemaker
(II) Cluster bsico de alta disponibilidad con Corosync+Pacemaker

---

Tengo que reconocer que desde que empec en esto de la informtica, el tema del clustering siempre me ha llamado la atencin.
Tambin tengo que decir que hasta hace muy poquito, ni siquiera poda imaginarme como funcionaba esto por dentro.

Coincidiendo con el desarrollo de mi Proyecto Integrado para finalizar el ciclo de ASI, voy a escribir una serie de artculos sobre este tema. As que espero que este sea el primero de una serie de documentacin que profundice ms en la alta disponibilidad (de la que por cierto, hay escasa documentacin en Espaol).

Antes de empezar, me gustara llamar la atencin sobre la gran cantidad de posibles configuraciones y la amplitud de posibilidades en el mundo del clustering. No entrar en asuntos de clustering de supercomputacin (no estoy preparado en esa materia).


1 El concepto de recurso

Lo primero que vamos a encontrar al trabajar con un cluster es un recurso. Es fundamental comprender el concepto de recurso, porque nos abrir la puerta a entendernos con lo que hay detrs y con las posibilidades de configuracin.

A priori, un recurso se corresponde con un servicio. Esto quiere decir lo siguiente:

-> Servicio http (apache) -> Recurso http (apache)
-> Servicio sgbd (mysql) -> Recurso sgbd (mysql)
[etc...]

Una vez comprendida e interiorizada esta correspondencia podemos decir que un recurso puede ser algo mucho ms completo que un servicio y que tiene caractersticas aadidas:Movilidad: Un servicio pertenece a una mquina. Un recurso no pertenece a una mquina (ya lo veremos).

Integracin: Podemos conseguir un grado muy alto de integracin entre distintos recursos; relaciones de localizacin, relaciones de orden de arranque y parada, etc...

Agrupacin: Podramos decir que un recurso en algunos casos est compuesto de varios servicios, e incluso de otros recursos.

As que podemos resumir que cuando hablamos de un cluster de alta disponibilidad, nos referimos a un recurso que se ofrece y no a un servicio.

2 Esquemas de montaje
Existen varias configuraciones posibles para un cluster de alta disponibilidad.
Tenemos desde un cluster sencillo de dos mquinas (dos nodos, llamando a las cosas por su nombre) a un cluster de N nodos (usando cualquier numero de mquinas).
Es importante tener en mente el tipo de cluster que necesitamos y que estamos montando. Por supuesto, supongo que cada uno puede inventarse su propio esquema de montaje, aunque los ms comunes son:Activo/Pasivo -> Configuracin bsica de 2 o ms nodos. Hay un nodo principal o maestro, donde estn corriendo la mayora de recursos y una serie de nodos esclavos o de backup, que entrarn en funcionamiento cuando el nodo principal falle.

Activo/Activo -> Configuracin tambin bsica de 2 o ms nodos. Con este tipo de clusters se desarrolla (entre otras cosas) lo que se llama "balanceo de carga". Generalmente, los recursos estn duplicados (clonados) en varios nodos y mediante algn mecanismo (dns, switches, etc..) repartiremos la carga entre cada nodo.

N+1 -> Combinacin de varios tipos de clusters en uno solo. Esta configuracin es ms avanzada y requiere que el administrador tenga las cosas muy claras sobre lo que est haciendo. En un mismo cluster (por ejemplo, activo/pasivo) podemos combinar un nodo de backup (de ah el nombre) o incluso usar varios nodos de backup.

N-to-N -> Cuando existe posibilidad de usar almacenamiento compartido (lase SAN o NAS) y los requisitos necesarios de hardware, cada nodo puede usarse para lo que queramos, osea, configuraciones de balanceo de carga con clones mltiples de backup. Es una de las configuraciones ms avanzadas y tengo que decir que por ahora a m me viene un poco grande, la verdad.

Ms informacin sobre esquemas de configuracin, con dibujos (bien hechos jeje) se pueden encontrar en la web/wiki de clusterlabs.org

3 El software que permite esto

Hay varias tecnologas que permiten la construccin de clusters. Muchas de ellas son libres y otras privadas; lo normal en estos casos. Yo voy a centrarme en la combinacin de dos herramientas, que son Heartbeat y Pacemaker, aunque hay muchas otras posibilidades:Corosync

OpenIAS

LVS

Keepalived

Yo he llegado tarde a esto, pero parece que la comunidad de alta disponibilidad ha tendido a estandarizarse, haciendo uso de esquemas de funcionamiento similiares y configuraciones basadas en XML (que aunque feas, son fciles a la hora de mover entre distintos programas).

Bsicamente, necesitamos dos elementos completamente distintos, y que son:Comunicacin entre nodos para la valoracin de sus estados. (heartbeat)

Gestin de recursos desplegados en el cluster. (pacemaker)

Por lo tanto, ser en heartbeat donde declararemos qu mquinas forman parte del cluster y en pacemaker qu recursos hay repartidos por el cluster (y en que nodo, y el resto de opciones de configuracin).

4 Vistazo al software y configuracin
Sin meternos en mucho detalle, dir que la configuracin de heartbeat es relativamente sencilla, y en un par de ficheros de configuracin tendremos lista la declaracin del cluster.
Para pacemaker el asunto es un poco ms complejo. El tema se maneja por XML, aunque hay una buena cantidad de herramientas que permiten hacer una administracin rpida y obviando totalmente los ficheros de configuracin.CRM shell -> lo ms extendido, programa en terminal que maneja el XML.

DRBD-MC -> programa grfico en java, que realmente maneja cibadmin por debajo mediante ssh, pero que presenta un aspecto visualmente atractivo e intuitivo.

Heartbeat gui -> Interfaz web. La verdad es que ni lo he probado.

En la mayora de manuales se encuentran referencias a CRM shell, y es lo que yo mostrar en los siguientes artculos que escriba (si es que eso ocurre).

Tengo que decir que hay muchas referencias documentales a heartbeat como nico software de gestin para el cluster, y es cierto. Antes, heartbeat cumpla las funciones de control de recursos, adems de encargarse de la comunicacin de estados entre nodos. Esto ya no es as y hay que huir pavorosamente de todas las documentaciones que usen el fichero "/etc/ha.d/haresources" .

NOTA EDITADA:
Segn me comentan los desarrolladores, el proyecto "heartbeat" no va a recibir nuevas actualizaciones, dado que RedHat y Novell/SUSE han apostado fuerte por Corosync.
En cualquier caso, con el desarrollo actual de heartbeattodavase puede trabajar.5 Nomenclatura propia
Al principio es un lo tremendo ver tantas abreviaturas y palabras nuevas, as que dejo un pequeo resumen de los conceptos ms importantes:CRM -> Cluster Resouce Manager. Es el software que provee del control sobre los recursos desplegados en el cluster. Yo he hablado de pacemaker mediante la herramienta CRM Shell.

CIB -> Cluster Information Base. Es el fichero XML donde se refleja la configuracin de los recursos que se ha hecho mediante el CRM. Se genera y se propaga automticamente a todos los nodos del cluster cuando es modificado. Est muy escondido y no es nada recomendable tocarlo a mano.

OCF -> Open Cluster Framework. Podriamos llamarlo el standar mediante el cual el CRM interactua con los servicios que corren en cada mquina. Mediante los standares OCF (realmente son scripts que interactuan con otros scripts) se manejan los scripts tpicos de "/etc/init.d" para obtener el estado de cada servicio, pararlos, arrancarlos, etc..

Messaging Layer -> Donde se coloca Heartbeat, OpenAIS u otro software. Se refiere al programa o demonio que controla la comunicacin de estados entre los nodos.

VIP -> Virtual IP. Generalmente, un cluster tendr una IP virtual que identificar al conjunto de nodos. Suele ser el primer paso en la configuracin de recursos y testeo de configuraciones.

failover/failback -> Cuando un nodo del cluster cae (deja de funcionar) y cuando vuelve a estar activo, respectivamente. Cuando se hace por razones administrativas, tambin puede llamarse switchover.

Esto que yo he escrito aqu pienso que es una buena base para empezar a meterse en el mundo del clustering de alta disponibilidad. A mi me ha costado alcanzar claridad en estos conceptos bastante tiempo, y tenia muchas ganas de plasmar este resumen y que le sirva a otro.

Al hilo del anterior post "Aproximacin al clustering de Alta Disponibilidad", voy a explicar como construir y manejar un cluster bsico basado en Corosync+Pacemaker.

El objetivo es sentar una base desde la que partir a realizar configuraciones ms avanzadas, y explicar un poco el manejo y funcionamiento de Pacemaker mediante la herramienta CRM.

Por ahora, solo voy a tratar una configuracin de tipo activo/pasivo, y es posible que ms adelante escriba algo sobre activo/activo (con balanceo de carga) u otras configuraciones ms avanzadas.

Las herramientas que voy a usar son Corosync+Pacemaker, ya se sabe:Corosync para la "mensajera" entre nodos del cluster.

Pacemaker para la gestin de recursos en alta disponibilidad.

Hay otras herramientas disponibles para la construccin de clusters de alta disponibilidad, que son:Keepalived.

LVS

Wackamole

Heartbeat

Heartattack

OpenAIS

Pero yo voy a centrarme en Corosync+Pacemaker porque despus de investigar un poco, se detecta rpidamente que son las herramientas con ms desarrollo, proyeccin de futuro, y actividad. De hecho, hay algunas herramientas que estn prcticamente muertas, como son Heartbeat y Wackamole.

Como base para un cluster de alta disponibilidad, la combinacin Corosync+Pacemaker cumple perfectamente con los requerimientos y funcionalidades necesarios, teniendo adems la ventaja de una comunidad muy activa (que puede ayudarnos en determinados callejones sin salida).


Hardware necesario
En cada nodo del cluster necesitaremos al menos 2 interfaces de red, 1 para la comunicacin directa entre nodos y otra para los servicios ofrecidos al exterior.
Aunque sera posible trabajar con una nica interfaz, es muy recomendable hacerlo de esta manera por motivos de estabilidad, seguridad, escalabilidad, etc..

El reparto de IPs puede verse en el esquema, con las interfaces que son:eth0 para atender a los clientes.

eth1 para la red interna de comunicacin entre nodos.

IPV: 192.168.0.1 (que alternativamente ser asignada al nodo1 y al nodo 2)

Instalacin
El proceso de instalacin es sencillo: desde los repositorios oficiales de nuestra distribucin favorita (Debian en mi caso). En entornos tipo RHEL tendremos que instalar un repositorio externo.
Instalamos los paquetes en todas las mquinas del cluster.Debian(root#) aptitude install corosync pacemaker

RHEL(root#) rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm(root#) wget -O /etc/yum.repos.d/pacemaker.repo http://clusterlabs.org/rpm/epel-5/clusterlabs.repo(root#) yum install -y pacemaker corosync heartbeat

Se instala heartbeat por dependencias, cuyos paquetes contienen algunas libreras necesarias para Pacemaker.


Configuracin y arranque de Corosync
Una configuracin bsica del demonio de Corosync se incluye al instalar la herramienta, y algo definitivo puede quedar as:/etc/corosync/corosync.conf compatibility: whitetanktotem {version: 2secauth: offthreads: 0interface {ringnumber: 0bindnetaddr: 172.16.0.0mcastaddr: 226.94.1.1mcastport: 5405}}logging {fileline: offto_stderr: yesto_logfile: yesto_syslog: yeslogfile: /tmp/corosync.logdebug: offtimestamp: onlogger_subsys {subsys: AMFdebug: off}}amf {mode: disabled}Esta configuracin es comn (en este caso concreto) a todos los nodos del cluster, y no se propaga automticamente.
Debemos crear la carpeta "/etc/corosync/service.d/", y aadir el siguiente fichero:/etc/corosync/service.d/pcmkservice {name: pacemakerver: 0}El parmetro "ver" determina si es Corosync el que debe arrancar a Pacemaker o no. Segn qu versin del software que estemos usando, debe estar a 1 o a 0 (en 1, existe un script LSB en /etc/init.d/ para Pacemaker, y es el sistema operativo el que lo arranca, con 0 es Corosync el que lo arranca y no existe script LSB).

Bajo Debian, necesitamos tocar otro fichero de configuracin, sin el cual Corosync no arrancar bajo ningn concepto:/etc/default/corosyncSTART=yes
Ya podemos arrancar el servicio y monitorizar el cluster:(root#)/etc/init.d/corosync start(root#)crm status============Last updated: Tue May 31 13:45:12 2011Stack: openaisCurrent DC: nodo1 - partition with quorumVersion: 1.0.11-1554a83db0d3c3e546cfd3aaff6af1184f79ee872 Nodes configured, 2 expected votes0 Resources configured.============

Online: [ nodo1 nodo2 ]

Sincronizacin de ficheros entre nodos
Hay algunos ficheros interesantes que deben ser iguales entre los nodos del cluster.
No hay ningn mtodo predefinido para hacer una sincronizacin de los mismos, as que en su momento desarroll un pequeo script en BASH que hace uso de rsync para tal menester.
Usndolo, el funcionamiento es transparente. Realmente no se si es la mejor opcin, dado que se usan bastantes recursos del sistemas durante muchas horas muertas donde no hay nada que sincronizar... as que estoy abierto a sugerencias.

Est compuesto de dos ficheros:/usr/local/bin/cluster/sync_files.sh#!/bin/bash

# Este script hace uso de rsync para sincronizar# ficheros entre los nodos de un cluster.

# El script esta pensado para ejecutarse varias veces por minuto. (crontab)

# Todas las maquinas que participen deben intercambiar las claves# para la conexion ssh:# ssh-keygen# ssh-agent $SHELL# ssh-add# ssh-copy-id

# Ademas, es muy importante que las horas esten sincronizadas.# En caso contrario, el comportamiento es ciertamente problematico.

# Los nombres de cada maquina deben ajustarse a `uname -n`# No importa de donde venga la lista de nombres mientras se cumpla.# Debe haber un espacio en blanco entre cada nombre de maquina.

# Se comprueba un lock file para que no se superpongan ejecuciones# de este script

########################## Variables ##########################LISTA_NODOS="nodo1 nodo2"THIS=`uname -n`LISTA_FICHEROS="/etc/rsync.d/sync_files.conf"THIS_PID=$$LOCK_FILE="/var/run/sync_files.sh.LOCK"

########################## Programa ##########################

# Validando ejecucionif [ -e $LOCK_FILE ]thenif [ "`cat $LOCK_FILE`" != $THIS_PID ]thenexit 1fielseecho "$THIS_PID" > $LOCK_FILEfi

# Sincroniafor nodo in $LISTA_NODOSdo# Si el nodo de la lista no es el propio nodo ejecutando este script# se ejecuta la instruccion de rsyncif [ "$nodo" != "$THIS" ]then# Se sincronizan los ficheros especificados en $LISTA_FICHEROS# Usando como copia maestra el mas reciente.rsync -urv --files-from=$LISTA_FICHEROS $nodo:/ /fidone

# Finalizando ejecucionrm -f $LOCK_FILE
Y la lista de ficheros a sincronizar:/etc/rsync.d/sync_files.conf/etc/rsync.d/sync_files.conf/usr/local/bin/cluster/sync_files.sh/etc/resolv.conf/etc/ntp.conf/etc/corosync/corosync.conf/etc/corosync/service.d/pcmk/etc/modules/etc/sysctl.conf
Para la correcta ejecucin, damos permisos al script tipo "chmod a+x" y aadimos un par de lneas a crontab/etc/crontab[...]* * * * * root /usr/local/bin/cluster/sync_files.sh* * * * * root sleep 30 && /usr/local/bin/cluster/sync_files.sh[...]
Como pone en los comentarios del script, es importante intercambiar las claves de los nodos, para que el proceso de Rsync (ssh) sea totalmente transparente.
Adems, es muy interesante indicar que toda comunicacin de un nodo con otro, se haga a travs de la interfaz interna (eth1), con lo cual editamos los ficheros:
/etc/hosts en nodo1[...]127.0.0.1 localhost nodo1172.16.0.2 nodo2[...]
/etc/hosts en nodo2[...]127.0.0.1 localhost nodo2172.16.0.2 nodo1[...]

Trabajando con PacemakerMediante la herramienta "crm" se interacciona con Pacemaker.
Realmente, manejamos el cib.xml (cluster information base), aunque vamos a ver poco XML por aqu.

Las instrucciones de crm pueden introducirse en cualquier nodo, y sern propagadas automticamente por todo el cluster.

Primero, indicamos a Pacemaker que nuestro cluster, por ahora, solo tiene 2 nodos. Necesitamos una configuracin un poco especial para ello, dado que Pacemaker viene preparado para trabajar con muchos nodos.root@nodo1:~# crm configure property stonith-enabled=falseroot@nodo1:~# crm configure property no-quorum-policy=ignoreroot@nodo1:~# crm configure rsc_defaults resource-stickiness=100
Con esto, estamos indicando lo siguiente:STONITH est deshabilitado. STONITH es un servicio que sirve para garantizar que un nodo est realmente muerto en situaciones de clusters con servicios crticos en cuanto a integridad de datos.

Ignoramos las polticas de QUORUM. No es necesario para un clusters de 2 nodos, y da problemas si no se deshabilita.

Situamos el nivel de "pegajosidad" de un recurso en 100. Esto es que un recurso tender a quedarse donde est (nodo) antes de moverse a otro nodo sin motivo de fuerza mayor (que son movimiento manual o situacin de failover).

Recursos en alta disponibilidad
La mayora de veces, el primer recurso a crear en alta disponibildad es una IPV (IP virtual). Sin ella no hacemos nada.

Con CRM, la instruccin es bastante fcil:root@nodo1:~# crm configure primitive IPV-1 ocf:heartbeat:IPaddr \params ip=192.168.0.1 nic=eth0 cidr_netmask=24 \op monitor interval=5s
Especificamos lo siguiente:crm configure primitive -> Aadimos un recurso

IPV-1 ocf:heartbeat:IPaddr -> El nombre del recurso es "IPV-1" y hace uso del RA (resource agent, o script que controla el recurso) "ocf:heartbeat:IPaddr".

Los parmetros son la IP, la interfaz que atender a esa IP y la mscara de red.

Como opciones, el "monitor interval" concreta la frecuencia con la que Pacemaker se asegura de que el recurso est funcionando. Este valor es el recomendado en todos sitios.

Cmo sabemos qu Resource Agent se usa para cada servicio? Muy fcil, el propio CRM buscar y nos mostrar esa informacin:root@nodo1:~# crm ra classes heartbeat lsb ocf / heartbeat pacemaker stonith root@nodo1:~# crm ra list ocf heartbeat [...]AoEtarget AudibleAlarm mysql mysql-proxy syslog-ng tomcat vmware[...]
Es posible escribir nuestros propios Resource Agent, aunque los servicios ms comunes ya tienen uno escrito y probado, que se distribuye en la instalacin del software.

Podemos ver la configuracin de nuestro cluster en cualquier momento:root@nodo1:~# crm configure shownode nodo1node nodo2primitive IPV-1 ocf:heartbeat:IPaddr \params ip="192.168.0.1" nic="eth0" netmask="255.255.255.0" \op monitor interval="5s"property $id="cib-bootstrap-options" \dc-version="1.0.11-1554a83db0d3c3e546cfd3aaff6af1184f79ee87" \cluster-infrastructure="openais" \expected-quorum-votes="2" \stonith-enabled="false" \no-quorum-policy="ignore"rsc_defaults $id="rsc-options" \resource-stickiness="100"
Que da como resultado el siguiente status:root@nodo2:~# crm status============Last updated: Tue May 31 14:28:14 2011Stack: openaisCurrent DC: nodo1 - partition with quorumVersion: 1.0.11-1554a83db0d3c3e546cfd3aaff6af1184f79ee872 Nodes configured, 2 expected votes1 Resources configured.============

Online: [ nodo1 nodo2 ]

IPV-1 (ocf::heartbeat:IPaddr): Started nodo1

Cuando aadimos recursos, podemos especificar distintas "constraints" o renstricciones, que son:De orden de arranque (es probable que algunos recursos requieran a otros antes de arrancar).

De colocacin (muy importantes, seguramente sea necesario que en el nodo que est colocada una IPV deban correr el resto de recursos).

De preferencia (especificamos dnde prefiere un recurso estar).

La explicacin en profundidad de estas caractersticas daran para escribir mucho (aunque no es difcil de manejar), as que dejar el tema para futuras publicaciones.

Pienso que el objetivo de estos post se ha cumplido, que era familiarizarnos con el entorno de Corosync+Pacemaker y construir algo muy bsico. Tan bsico que nuestro nico recurso en alta disponibilidad es una IP, jeje