Cluster, o Alta disponibilidad, voy a comentar un poco que es Heartbeat o pacemaker ahora y a configurar a un nivel básico. Mi objetivo esta vez sera explicar el funcionamiento de un cluster, algo un tanto sencillo y que a modo de aprendizaje puede servir para poder crear un cluster de cualquier otra cosa, como puede ser de maquinas virtuales con KVM/XEN, una base de datos postgresql u otro tipo de servicios Samba, NFS, MySQL, y cualquier otro recurso. La palabra cluster ya que como no pertenece al idioma español, no tiene una buena traducción y podría dar a mucha confusión, por lo tanto prefiero utilizar cluster, ya que esta misma esta en forma universal presente en todos los conceptos de tecnologia.

Para comenzar: ¿Que es heartbeat?

Heartbeat es una utilidad que simplemente envía un latido de corazón de hecho heartbeat en español, seria latido de corazón, un simple pulso, o paquete pequeño de datos a uno o mas equipos. De esta manera, esta aplicación nos permite que en un cluster se realice un monitoreo automático, para saber si el nodo esta vivo y los servicios corriendo en el, haciendo que en caso de que un nodo muera, automáticamente el o los nodos vivos tomen ese servicio, lo inicien y continúen trabajando.
Ahora bien, quisiera aclarar, que también existe pacemaker, que no es mas que la evolución de Heartbeat,  un proyecto que parte del anterior, simplemente eso.
Quiero que entiendan sobre la gran cantidad de posibles configuraciones y la amplitud de posibilidades en el mundo del clustering. No entraré en asuntos de clustering de supercomputación no es el tema de este articulo, pero puede ser la base para hacerlo.

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 detrás y con las posibilidades de configuración.
Inicialmente, un recurso se corresponde con un servicio. Esto quiere decir lo siguiente:

Servicio http (apache) -> Recurso http (apache)
Servicio sgbd (mysql) -> Recurso sgbd (mysql)
y asi para los demas servicios.

Una vez comprendida esta correspondencia podemos decir que un recurso puede ser algo mucho más completo que un servicio y que tiene características añadidas:
Movilidad: Un servicio pertenece a una máquina. Un recurso no pertenece a una máquina (ya lo veremos).
Integración: Podemos conseguir un grado muy alto de integración entre distintos recursos; relaciones de localización, relaciones de orden de arranque y parada, etc...
Agrupación: Podríamos 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.

Existen varias configuraciones posibles para un cluster de alta disponibilidad.
Tenemos desde un cluster sencillo de dos máquinas (dos nodos, llamando a las cosas por su nombre) a un cluster de N nodos (usando cualquier numero de máquinas).
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 más comunes son:

Activo/Pasivo -> Configuración básica de 2 o más nodos. Hay un nodo principal o maestro, donde están corriendo la mayoría de recursos y una serie de nodos esclavos o de backup, que entrarán en funcionamiento cuando el nodo principal falle.
Activo/Activo -> Configuración también básica de 2 o más nodos. Con este tipo de clusters se desarrolla (entre otras cosas) lo que se llama "balanceo de carga". Generalmente, los recursos están duplicados (clonados) en varios nodos y mediante algún mecanismo (dns, switches, etc..) repartiremos la carga entre cada nodo.
N+1 -> Combinación de varios tipos de clusters en uno solo. Esta configuración es más 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 (léase 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 múltiples de backup. Es una de las configuraciones más avanzadas, requiere un poco mas de experiencia en la realización de este tipo de conceptos, pero no es complicado.

Más información sobre esquemas de configuración, http://clusterlabs.org/wiki/Main_Page

Hay varias tecnologías que permiten la construcción de clusters. Muchas de ellas son libres y otras privadas; lo normal en estos casos. Centrémonos en la combinación de dos herramientas, que son Heartbeat, Pacemaker, Corosync, y openais aunque hay muchas otras posibilidades.

La comunidad de alta disponibilidad ha tendido a estandarizarse, haciendo uso de esquemas de funcionamiento similares y configuraciones basadas en XML, fáciles a la hora de mover entre distintos programas.

Básicamente, necesitamos dos elementos completamente distintos, y que son:

1. Comunicación entre nodos para la valoración de sus estados. heartbeat
2. Gestión de recursos desplegados en el cluster. pacemaker

Por lo tanto, será en heartbeat donde declararemos qué máquinas forman parte del cluster y en pacemaker qué recursos hay repartidos por el cluster y en que nodo, y el resto de opciones de configuración.
Sin meternos en mucho detalle, diré que la configuración de heartbeat es relativamente sencilla, y en un par de ficheros de configuración tendremos lista la declaración del cluster.

Para pacemaker el asunto es un poco más complejo. El tema se maneja por XML, aunque hay una buena cantidad de herramientas que permiten hacer una administración rápida y obviando totalmente los ficheros de configuración.

CRM shell -> lo más extendido, programa en terminal que maneja el XML.
DRBD-MC -> programa gráfico en java, que realmente maneja cibadmin por debajo mediante ssh, pero que presenta un aspecto visualmente atractivo e intuitivo.

En la mayoría de manuales se encuentran referencias a CRM shell.

Tengo que decir que hay muchas referencias documentales a heartbeat como único software de gestión para el cluster, y es cierto. Antes, heartbeat cumplía las funciones de control de recursos, además de encargarse de la comunicación de estados entre nodos. Esto ya no es así todas las documentaciones que usen el fichero "/etc/ha.d/haresources", ya en muchos casos no son funcionales.

Manifiestan los desarrolladores del proyecto heartbeat, que este 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 heartbeat todavía se puede trabajar.

Al principio es un lío tremendo ver tantas abreviaturas y palabras nuevas, así que dejo un pequeño resumen de los conceptos más importantes:
1. 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.
2. CIB -> Cluster Information Base. Es el fichero XML donde se refleja la configuración de los recursos que se ha hecho mediante el CRM. Se genera y se propaga automáticamente a todos los nodos del cluster cuando es modificado. Está muy escondido y no es nada recomendable tocarlo a mano.
3. OCF -> Open Cluster Framework. Podriamos llamarlo el standar mediante el cual el CRM interactua con los servicios que corren en cada máquina. Mediante los standares OCF (realmente son scripts que interactuan con otros scripts) se manejan los scripts típicos de "/etc/init.d" para obtener el estado de cada servicio, pararlos, arrancarlos, etc..
4. Messaging Layer -> Donde se coloca Heartbeat, OpenAIS u otro software. Se refiere al programa o demonio que controla la comunicación de estados entre los nodos.
5. VIP -> Virtual IP. Generalmente, un cluster tendrá una IP virtual que identificará al conjunto de nodos. Suele ser el primer paso en la configuración de recursos y testeo de configuraciones.
6. failover/failback -> Cuando un nodo del cluster cae (deja de funcionar) y cuando vuelve a estar activo, respectivamente. Cuando se hace por razones administrativas, también puede llamarse switchover.

Corosync+Pacemaker.

El objetivo es sentar una base desde la que partir a realizar configuraciones más avanzadas, y explicar un poco el manejo y funcionamiento de Pacemaker mediante la herramienta CRM.
Por ahora, solo voy a tratar una configuración de tipo activo/pasivo, algo mas avanzado sobre activo/activo con balanceo de carga no esta contemplado, pues requiere configuraciones mas avanzadas.
Las herramientas que voy a usar son Corosync+Pacemaker, como lo estoy comentando:
Corosync para la "mensajería" entre nodos del cluster.
Pacemaker para la gestión de recursos en alta disponibilidad.

Hay otras herramientas disponibles para la construcción de clusters de alta disponibilidad, que son:
Keepalived.
LVS
Heartbeat
Heartattack

Corosync+Pacemaker son las herramientas con más desarrollo, proyección de futuro, y actividad. De hecho, hay algunas herramientas que están prácticamente muertas, como son Heartbeat.
Como base para un cluster de alta disponibilidad, la combinación Corosync+Pacemaker cumple perfectamente con los requerimientos y funcionalidades necesarios, teniendo además la ventaja de una comunidad muy activa.