Alta disponibilidad en clusteres asterisk

CAPITULO 6
AALLTTAA DDIISSPPOONNIIBBIILLIIDDAADD EENN CCLLUUSSTTEERREESS
VVIIRRTTUUAALLEESS
En este último capítulo del proyecto vamos a profundizar en el concepto de clúster
virtual y vamos a ver como algunas técnicas aplicables en los casos reales pueden ser
implementadas también en este tipo de infraestructuras de igual forma. Más concretamente
dotamos a nuestra infraestructura virtual de una de las características y requisitos
imprescindibles hoy en día a la hora de ofrecer servicios: alta disponibilidad. Cada día que pasa
resulta habitual encontrarnos con servicios que requerimos o que debemos proporcionar con una
gran exigencia: rapidez, eficiencia, simplicidad, las 24 horas al día, los 7 días de la semana, todo
el año. Es entonces cuando consideramos que ese determinado servicio (base de datos, página
web, centralita VoIP, almacenamiento) debe estar continuamente disponible, lo que implica que
debamos aplicar determinadas técnicas tanto hardware como software para cumplir este
objetivo.
Como podemos imaginar existe una gran variedad de soluciones de ambos tipos. Sin
embargo, una de ellas destaca sobre el resto debido al gran potencial que presenta al tratarse de
software libre. Hablamos de Heartbeat, que será introducido en la primera parte de este
capítulo. Instalando y configurando Heartbeat en nuestro clúster virtual nos va a permitir que si
el servicio Asterisk que se está ejecutando en un dominio cae, se arranque de forma automática
en otro dominio virtual del clúster. Como hemos visto en el contenido desarrollado hasta el
momento mediante virtualización también es posible proporcionar alta disponibilidad para
nuestros datos y servicios, haciendo uso de mecanismos como la automatización de procesos de
aprovisionamiento, copias de seguridad, backups de dominios… o, quizás el más importante de
todos, la migración de dominios tanto en parada como en caliente. Esta última modalidad
permite que un dominio sea migrado desde un servidor Xen anfitrión a otro sin que su estado
sea bloqueado. En este capítulo profundizamos en todos estos conceptos relacionados con alta
disponibilidad y virtualización al mismo tiempo que presentamos ejemplos prácticos que
demuestran su gran utilidad.

CAPITULO 6: ALTA DISPONIBILIDAD EN CLUSTERES VIRTUALES 259
© Eugenio Villar y Julio Gómez
http://www.adminso.es
11 IInnttrroodduucccciióónn aa llaa AAllttaa DDiissppoonniibbiilliiddaadd
La alta disponibilidad, ya sea de servicios o de datos, puede ser alcanzada tanto
haciendo uso de soluciones software como de soluciones hardware. La variedad que existe en
ambos grupos es muy grande, pudiendo elegir siempre una solución que encaje perfectamente
según nuestras necesidades. Veamos brevemente de forma introductoria en qué consiste cada
una de ellas.
Las soluciones software nos permiten alcanzar alta disponibilidad instalando y
configurando determinadas herramientas y aplicaciones que han sido diseñadas para tal efecto.
En lo que respecta a alta disponibilidad en servicios son usadas sobre en todo en
servicios de ejecución crítica, como por ejemplo un servidor de bases de datos, una web de una
tienda online, una centralita de telefonía IP, o el Directorio Activo. Lo normal es que con el
software de alta disponibilidad no sea suficiente y haya que hacer uso de herramientas o
complementos adicionales para su configuración, tales como dirección IP, reglas de cortafuegos,
dependencias, políticas de seguridad, copia y recuperación, etc. Entre las herramientas más
importantes dentro de esta categoría en sistemas operativos GNU/Linux podemos citar
Heartbeat, HA-OSCAR, KeepAlived, Red Hat Cluster Suite, The High Availability Linux
Project, LifeKeeper o Veritas Cluster Server.
De una gran importancia son también las soluciones software para alta disponibilidad
de datos, casi siempre requeridos por los servicios críticos de nuestro servidor.
Fundamentalmente consiste en la replicación de los datos, disponiendo de ellos en diversas
localizaciones, permitiendo su efectiva recuperación en caso de fallos desastrosos o cuando el
nodo en el que normalmente se encuentran accesibles no se está disponible. Lo habitual es que
las herramientas que ofrecen alta disponibilidad/replicación de datos trabajen de dos formas
diferentes: replicación de bloque de datos y de bases de datos. En el primer tipo la
información en los sistemas de ficheros es replicada bloque a bloque; algunos ejemplos son
DRBD (ya analizado en mayor detalle en capítulos anteriores) o rsync. En cuanto a la
replicación de bases de datos la forma de trabajar consiste en la replicación de una base de datos
en varias bases de datos, localizadas remotamente, llevando a cabo la replicación instrucción a
instrucción. Algunas utilidades que siguen este modelo de replicación en GNU/Linux son
MySQL Replication, Slony-I, o las propias de Oracle. Otros importantes proyectos de alta
disponibilidad para datos son FreeNAS, NAS Lite-2, u Openfiler. Con los dos primeros por
ejemplo usamos un sistema operativo actuando como NAS (Network-Attached Storage),
logrando que un equipo pueda desempeñar funcionalidades de servidor NAS soportando una
amplia gama de protocolos para compartición de almacenamiento en red y replicación: cifs
(samba), FTP, NFS, rsync, RAID software… y otros.
También mediante hardware es posible alcanzar alta disponibilidad tanto para
datos como para servicios. Este tipo de soluciones depende en gran medida del tipo de datos o
servicios a los que queremos dotar de esta característica, y normalmente suelen usarse para
apoyar las soluciones de tipo software que estemos aplicando, para mantener o superar el nivel
de seguridad y disponibilidad de las mismas. En la mayoría de los casos entendemos como
solución hardware para alta disponibilidad la replicación de recursos hardware, como memoria
o almacenamiento, o la puesta en marcha de dispositivos hardware especializados. Por ejemplo,
para la alta disponibilidad de servicios de telefonía IP podemos instalar un balanceador de
primarios de telefonía E1/T1 (por ejemplo, Redfone), permitiendo que aunque cayera uno de los
nodos del clúster de telefonía IP sea posible establecer llamadas a través de la red de telefonía
tradicional. En cuanto a alta disponibilidad de datos, soluciones como NAS, RAID, SAN,… son
ampliamente conocidas y usadas.
Como podemos ver, dependiendo del proyecto en el que trabajamos disponemos de una
gran variedad de soluciones tanto software como hardware que además es posible usar de forma

260 VIRTUALIZACION DE SERVIDORES DE TELEFONIA IP EN GNU/LINUX
conjunta integrándolas. Las hay propietarias, libres o incluso gratuitas. En el siguiente apartado
la que es en la actualidad la solución open source sobre GNU/Linux más usada en los que a alta
disponibilidad de servicios críticos se refiere (como es nuestro caso, el de las centralitas de
telefonía IP con Asterisk). Heartbeat no sólo es open source sino que además puede ser
descargada y usada de forma gratuita, obteniendo un gran soporte por parte de su activa
comunidad de desarrolladores.
22 AAllttaa ddiissppoonniibbiilliiddaadd ddee sseerrvviicciiooss ccrrííttiiccooss ccoonn HHeeaarrttbbeeaatt
Heartbeat (http://www.linux-ha.org/wiki/Heartbeat) es una solución software de alta
disponibilidad para servicios críticos que permite que éstos se encuentren disponibles en
ejecución de forma ininterrumpida a pesar de los fallos o problemas que puedan surgir durante
su funcionamiento. Mediante su uso es posible obtener alta disponibilidad de servicios como
hemos dicho, además de mejorar sustancialmente su rendimiento, todo ello con un coste de
implementación y administrativo reducido. Heartbeat trabaja sobre un clúster compuesto por
nodos, los cuales son los encargados de ejecutar el servicio dependiendo de la configuración
realizada en Heartbeat y de las circunstancias, que normalmente suelen determinar la
disponibilidad de un nodo. De esta forma un servicio puede ser migrado de forma rápida y
transparente de un nodo del clúster a otro por el motivo que fuese (por ejemplo ante un fallo en
la alimentación del nodo o por motivos administrativos), logrando que éste solamente deje de
estar operativo durante el tiempo en el que Heartbeat detecta el fallo y lleva a cabo la
migración.
Por ejemplo, en el caso del proyecto en el que trabajamos podemos desarrollar un
clúster de alta disponibilidad de telefonía IP formado por dos nodos, cada uno de ellos con
Asterisk instalado. Sobre él es posible establecer una configuración en la que un nodo, llamado
activo, posee y ejecuta el recurso Asterisk mientras que el otro nodo se mantiene a la espera de
posibles fallos (configuración Activo/Pasivo). Datos adicionales, como la base de datos que
contiene información sobre los usuarios, mensajes de voz, ficheros de registro… pueden ser
almacenados en otro nodo a modo de almacenamiento compartido (véase la figura 6-1).
Figura 6.1. Clúster de alta disponibilidad de telefonía IP con Asterisk y Heartbeat.
Mediante Heartbeat los nodos que pueden ejecutar el servicio Asterisk se comunican
mediante mensajes ICMP (Internet Control Message Protocol, por ejemplo ping) de forma que
uno puede monitorizar el estado del otro (y viceversa). Además, cada nodo monitoriza también
en qué estado se encuentran los recursos que actualmente se encuentra ejecutando, para la
detección de posibles irregularidades y fallos. El nodo activo se encuentra por tanto
monitorizando el estado de Asterisk y el nodo pasivo, mientras que el nodo pasivo monitoriza
solamente al nodo activo.

Situémonos en el caso en el que un fallo es detectado en el nodo activo, ya sea un fallo
hardware o un error en la ejecución de los recursos que está ejecutando (Asterisk) o cualquier
otro software que sea imprescindible para prestar los servicios. Por ejemplo, imaginemos que el
servicio Asterisk es saturado y por tanto no puede operar de forma correcta. En este momento el
nodo activo (más concretamente Heartbeat) detecta el fallo en la ejecución de Asterisk y
comprueba la disponibilidad del nodo pasivo para traspasar la ejecución del servicio. De esta
forma el recurso es migrado del primer nodo al segundo, que pasa a ser consecuentemente el
nuevo nodo activo. Ante situaciones de fallo similares el sistema de alta disponibilidad actúa de
forma análoga, consiguiendo que cuando se produzcan fallos en la ejecución del servicio y
aunque éste deje de estar disponible durante unos instantes, el tiempo que transcurre
hasta ejecutar el servicio de nuevo en otro nodo sea mínimo, normalmente inapreciable
por los usuarios. Por ejemplo, en el caso de que el nodo pasivo detecte que falla la
monitorización del nodo activo (ya sea porque la fuente de alimentación no funciona de la
forma adecuada y por tanto fue apagado o cualquier otro motivo), éste considera que el nodo
activo no se encuentra en disposición de ejecutar Asterisk y se inicia el proceso para encargarse
de ello, pasando de nuevo el nodo pasivo a ser el activo y logrando que el servicio no deje de
estar disponible a los usuarios. Independientemente de la recuperación ante desastres que
permiten Heartbeat, los recursos también pueden ser migrados por Heartbeat de forma
manual, ya que ocasionalmente es necesario realizar actividades de administración y
mantenimiento (actualizaciones, instalaciones, reparación y sustitución de componentes, etc.) de
los nodos que ejecutan los servicios críticos, aunque no haya sido detectado ningún error.
Lo habitual es utilizar además del recurso principal (en nuestro caso Asterisk) una
dirección de red IP virtual. La dirección IP virtual permite que el servicio se encuentre
siempre accesible a través de la misma dirección de red independientemente del nodo del clúster
en el que se encuentre en ejecución; de lo contrario ello supondría un grave problema. Así, sea
cual sea el nodo que ejecuta Asterisk éste requiere al mismo tiempo tener configurada la interfaz
de red con la IP virtual; ésta es considerada también un recurso por Heartbeat en su
configuración y es monitorizada y migrada de igual forma que Asterisk.
Como vemos hemos logrado recuperarnos ante un fallo en la ejecución de nuestros
servicios de forma limpia y rápida; es el momento de estudiar el porqué del error en la
operativa del nodo activo y solucionar los problemas que han surgido. Una vez que
llevamos a cabo estas actividades el nodo (anteriormente activo) pasa a encontrarse de
nuevo disponible para prestar sus servicios al clúster. Ahora, dependiendo de la
configuración que realicemos en Heartbeat los servicios que ahora se encuentran en otro
nodo pueden volver al nodo original o bien permanecer en el que actualmente es activo.
Cada una de las dos opciones posee ventajas y desventajas como vemos a continuación.
Si hacemos que los recursos vuelvan de nuevo a su ubicación original una vez que el
nodo que causó el fallo se recupera debemos otra vez detener la ejecución de los servicios para
su migración. Sin embargo, esto permite que la carga de trabajo del nodo que tomó los recursos
tras el fallo se vea considerablemente reducida; esto es especialmente importante cuando éste
nodo normalmente ejecuta otros servicios diferentes a los que fueron migrados.
2.1 ARQUITECTURA HEARTBEAT
Históricamente con el nombre Heartbeat hacíamos referencia a un conjunto de
herramientas y utilidades de alta disponibilidad con una arquitectura estructurada en
capas, formado fundamentalmente por el componente Heartbeat en la capa de mensajes o
comunicación, un administrador de recursos locales (Local Resource Manager o LRM) y un
administrador de recursos del clúster (Cluster Resource Manager o CRM) en la capa de
asignación de recursos, y un agente de recursos (Resource Agent) en la capa de recursos, entre
otros componentes.

A partir de la versión 2.1.4 esta generalización ya no es válida, quedando el nombre
Hearbeat para denominar exclusivamente la capa de comunicación o mensajes entre los
nodos que forman el clúster. El resto de componentes son ahora proyectos independientes,
igualmente necesarios para establecer un clúster de alta disponibilidad, como vemos en el
apartado siguiente con la instalación de Heartbeat 3, referenciados en la actualidad grupalmente
como Linux-HA (Linux High Availability, http://www.linux-ha.org).
La arquitectura presentada en la actualidad por Linux-HA dispone de una gran
flexibilidad debido a la modularidad comentada, algo muy positivo de cara al desarrollo que
experimente el proyecto en los próximos años.
Figura 6.2. Arquitectura del proyecto Linux-HA.
En la figura anterior 6.2 podemos apreciar esta nueva arquitectura, cuyos elementos
vemos a continuación:
• El módulo CRM -gestor del los recursos del clúster- ha sido renombrado a
Pacemaker (http://clusterlabs.org/), encargado de arrancar los recursos o servicios,
detenerlos, configurarlos, monitorizarlos, establecer la configuración global del clúster,
además de otros muchos aspectos que presentaremos en el apartado 2.3 Configuración
de Heartbeat 3. Con él es posible configurar de forma directa (antes había que hacerlo
editando ficheros XML) el clúster. Pacemaker funciona como parte central del proyecto
Linux-HA por encima de la capa de comunicación, que puede hacer uso de Heartbeat u
OpenAIS.
• Heartbeat es ahora solamente la capa que comunica los nodos del clúster, permitiendo
el intercambio de mensajes para determinar la presencia o la ausencia de pares de
procesos entre los nodos. Esta funcionalidad también puede ser soportada por otro
proyecto denominado OpenAIS, como sabemos. Para alcanzar el mayor rendimiento
posible Heartbeat debe ser usado en combinación con Pacemaker, encargado de llevar
a cabo las tareas de arranque y parada de los servicios a los que queremos dotar de alta
disponibilidad.

• Resource Agents son los agentes de recurso, un extenso conjunto de scripts para la
gestión y acceso a los diferentes recursos y servicios que son ofrecidos y mantenidos
por el clúster.
• El componente STONITH ha sido renombrado como ClusterGlue (http://www.linux-
ha.org/wiki/Cluster_Glue), un elemento imprescindible en la arquitectura de alta
disponibilidad de Linux-HA ya que permite la interoperabilidad entre sus diferentes
elementos.
Una vez conocida cómo es la arquitectura del proyecto de alta disponibilidad Linux-HA
y los diferentes elementos que la componen nos centramos por completo en la capa de
mensajes/comunicación Heartbeat en su versión 3. Veremos por tanto a continuación cómo
podemos instalar Heartbeat 3, y cómo podemos configurar nuestro clúster de alta disponibilidad
con Heartbeat de una forma sencilla gracias a Pacemaker.
2.2 INSTALACION DE HEARTBEAT 3
A continuación vamos a ver cómo es el proceso de instalación de una infraestructura de
alta disponibilidad Linux-HA con Heartbeat 3 y el resto de componentes necesarios que han
sido comentados en el apartado anterior a partir de su código fuente, disponible en la web del
proyecto http://www.linux-ha.org/. La instalación y configuración de cada uno de los
componentes debe ser realizada en todos los nodos del clúster.
Figura 6.3. Web oficial del proyecto Linux-HA: http://www.linux-ha.org/.
Antes de comenzar con la instalación propiamente dicha debemos cumplir ciertas
dependencias software, sobre todo librerías que son imprescindibles para que Linux-HA y sus
componentes puedan operar de forma correcta. Lo hacemos instalándolas desde repositorios
mediante el comando apt-get install, ya que usamos la distribución Debian 5 Lenny (para el
resto de distribuciones Linux podemos proceder de forma análoga):
# apt-get install xsltproc docbook-xml docbook-xsl
# apt-get install build-essential libglib2.0-dev pkg-config

Una vez resultas estas dependencias descargamos e instalamos la última versión estable
para cada uno de los componentes del proyecto Linux-HA por este orden: ClusterGlue,
ResourceAgents, Heartbeat, Pacemaker.
2.2.1 Instalación de ClusterGlue 1.0.5
ClusterGlue es un elemento importante ya que gracias a él el resto de componentes de
Linux-HA pueden trabajar de forma conjunta. Además de las dependencias instaladas
anteriormente debemos instalar las siguientes para ClusterGlue:
# apt-get install autoconf libtool libglib2.0-dev flex bison
libxml2-dev libbz2-dev uuid-dev automake
Descargamos la última versión estable de ClusterGlue (en el momento de redacción de
esta memoria es la 1.0.5) desde los repositorios mercurial de Linux-HA mediante el comando
wget:
# wget http://hg.linux-ha.org/glue/archive/glue-1.0.5.tar.bz2
Con el paquete descargado, lo descomprimimos con el uso del comando tar e
ingresamos en el directorio creado en la descompresión:
# tar xjvf glue-1.0.5.tar.bz2
# cd Reusable-Cluster-Components-glue-1.0.5/
Después, en el directorio Reusable-Cluster-Components-glue-1.0.5 ejecutamos los
scripts de preparación de la instalación autogen.sh y configure:
Reusable-Cluster-Components-glue-1.0.5# ./autogen.sh
Reusable-Cluster-Components-glue-1.0.5# ./configure
Finalmente y como es habitual, compilamos el código fuente y realizamos la instalación
ejecutando make y make install, respectivamente:
Reusable-Cluster-Components-glue-1.0.5# make
Reusable-Cluster-Components-glue-1.0.5# make install
Con ClusterGlue instalado avanzamos un nivel en la arquitectura Linux-HA instalando
ResourceAgents.
2.2.2 Instalación de ResourceAgents 1.0.3
Para la instalación de los agentes de recurso procedemos de la misma forma que
para la instalación de ClusterGlue. En primer lugar descargamos el paquete con las
fuentes de la versión 1.0.3 (última versión estable) y los descomprimimos:
# wget http://hg.linux-ha.org/agents/archive/agents-1.0.3.tar.bz2

# tar xjvf agents-1.0.3.tar.bz2
Después cambiamos al directorio obtenido en la descompresión para ejecutar los scripts
autogen.sh y configure, y compilar y realizar la instalación mediante los comandos make y
make install:
# cd Cluster-Resource-Agents-agents-1.0.3/
Cluster-Resource-Agents-agents-1.0.3# ./autogen.sh
Cluster-Resource-Agents-agents-1.0.3# ./configure
Cluster-Resource-Agents-agents-1.0.3# make
Cluster-Resource-Agents-agents-1.0.3# make install
A continuación, una vez que también hemos instalado ya ResourceAgents, ya podemos
instalar Heartbeat 3. Además, vamos a realizar unos pequeños cambios en el sistema para que
éste pueda trabajar correctamente.
2.2.3 Instalación de Heartbeat 3
Vamos a instalar la última versión estable de Heartbeat en el momento de
redacción de este capítulo, 3.0.3. Antes debemos cumplir algunas dependencias de
utilidades y librerías necesarias para configurar y llevar a cabo el proceso de instalación;
lo hacemos utilizando el comando apt-get install como hasta ahora:
# apt-get install libbz2-dev perl-base libperl-dev libltdl3-dev
libxml2-dev libnet1-dev libglib2.0-dev gawk zlib1g zlib1g-dev
Cuando hemos instalado las dependencias podemos descargar el paquete STABLE-
3.0.3.tar.bz2 desde los repositorios mercurial oficiales de Linux-HA usando el comando wget:
# wget http://hg.linux-ha.org/heartbeat-STABLE_3_0/archive/STABLE-
3.0.3.tar.bz2
Descomprimimos entonces el paquete descargado usando tar e ingresamos en el
directorio creado durante la descompresión, que contiene el código fuente de Heartbeat 3:
# tar xjvf STABLE-3.0.3.tar.bz2
# cd Heartbeat-3-0-STABLE-3.0.3/
En primer lugar y antes de nada, ejecutamos el comando bootstrap para prepararnos de
cara al proceso de instalación:
Heartbeat-3-0-STABLE-3.0.3# ./bootstrap
Ahora sí podemos empezar a configurar y realizar la instalación. No lo vamos a hacer
utilizando los comandos clásicos configure, make y make install, sino que ejecutamos como es
recomendable el script ConfigureMe con las opciones configure, make y make install,

respectivamente. Además, a cada una de las ejecuciones añadimos la opción –enable-fatal-
warnings=no para evitar que avisos impidan que culminemos adecuadamente la instalación:
Heartbeat-3-0-STABLE-3.0.3# ./ConfigureMe configure --enable-fatal-
warnings=no
Heartbeat-3-0-STABLE-3.0.3# ./ConfigureMe make --enable-fatal-
warnings=no
Heartbeat-3-0-STABLE-3.0.3# ./ConfigureMe install --enable-fatal-
warnings=no
En este punto ya disponemos de Heartbeat 3 instalado, aunque todavía debemos llevar a
cabo algunas acciones para adecuar el sistema para que Heartbeat trabaje. Creamos primero un
grupo de usuarios denominado haclient y un usuario hacluster dentro de este grupo:
# addgroup haclient
# adduser hacluster –gid 1000
El usuario es añadido al grupo en el momento de su creación especificando el
identificador de grupo gid que podemos obtener del fichero /etc/group. Después, hacemos tanto
a hacluster como a haclient propietarios de los ficheros de Heartbeat con el comando chown,
que permite cambiar el propietario de un fichero/directorio:
# chown –R hacluster:haclient /var/run/heartbeat
# chown –R hacluster:haclient /var/lib/heartbeat
# chown –R hacluster:haclient /usr/lib/heartbeat
# chown –R hacluster:haclient /usr/var/run/heartbeat
Finalmente es necesario antes de poner en marcha el servicio Heartbeat copiar los
siguientes ficheros desde el subdirectorio doc del directorio principal de las fuentes descargadas
en el directorio /etc/ha.d/. Posteriormente cuando configuramos Heartbeat comentamos en qué
consiste cada uno de estos ficheros:
Heartbeat-3-0-STABLE-3.0.3# cp doc/authkeys /etc/ha.d/
Heartbeat-3-0-STABLE-3.0.3# cp doc/ha.cf /etc/ha.d/
Heartbeat-3-0-STABLE-3.0.3# cp doc/haresources /etc/ha.d/
Es necesario también cambiar los permisos de acceso al fichero authkeys (el primero de
los copiados en el código anterior) para que solo los propietarios tengan acceso de lectura y
escritura al mismo:
Heartbeat-3-0-STABLE-3.0.3# chmod 600 /etc/ha.d/authkeys
Hasta aquí la instalación de Heartbeat. El siguiente paso que debemos dar es su
configuración, algo más complejo como podemos ver en el apartado siguiente de este capítulo.
Nos preparamos para su configuración estableciendo en cada nodo del clúster un nombre único
por el que identificarlo. Esto lo podemos hacer con el comando hostname:

# hostname <nombre>
Si queremos comprobar cuál es el nombre del nodo podemos ejecutar hostname sin
opciones y el comando uname con la opción –n:
# uname -n
La salida de estos dos comandos es el nombre a través del cual haremos referencia a los
nodos del clúster en la configuración de Heartbeat. Para terminar, debemos editar el fichero
/etc/hosts en cada nodo del clúster para que pueda comunicarse con el resto de nodos,
incluyendo una línea por nodo de la siguiente forma:
<direccion_ip> <nombre>
De esta forma cada nodo identifica al resto mediante el par dirección IP – nombre,
siendo el nombre el establecido con el comando hostname.
Comentar que aunque la instalación de Heartbeat sea realizada con éxito es posible que
aparezcan algunos problemas en su ejecución. La mayoría de ellos se pueden subsanar copiando
los ficheros ha.cf y authkeys del directorio /etc/ha.d/ al directorio /usr/etc/ha.d/, y el fichero
shellfuncs desde el directorio descomprimido de ClusterGlue al directorio /etc/ha.d/.
cp /downloads/Cluster-Resource-Agents-agents-
1.0.2/heartbeat/shellfuncs /etc/ha.d/shellfuncs
cp /etc/ha.d/ha.cf /usr/etc/ha.d/
cp /etc/ha.d/authkeys /usr/etc/ha.d
2.2.4 Instalación de Pacemaker 1.0.8
Acabamos la instalación de nuestra infraestructura con Pacemaker, en su última versión
estable 1.0.8. Instalar Pacemaker es fundamental ya que sin él configurar el clúster y los
recursos resulta mucho más complejo. Además de las dependencias instaladas anteriormente de
forma global instalación también la librería libxslt-dev:
# apt-get install libxslt-dev
Descargamos en primer lugar las fuentes desde los repositorios mercurial de Cluster
Labs, web oficial del proyecto Pacemaker (http://www.clusterlabs.org/):
# wget http://hg.clusterlabs.org/pacemaker/stable-
1.0/archive/Pacemaker-1.0.8.tar.bz2
Ahora que disponemos del paquete Pacemaker-1.0.8.tar.bz2 con las fuentes de la
utilidad, lo descomprimíos con tar y cambiamos al directorio generado:
# tar xjvf Pacemaker-1.0.8.tar.bz2
# cd Pacemaker-1-0-Pacemaker-1.0.8/

Procedemos a continuación de forma similar a como lo hemos hecho para los otros
componentes de Linux-HA. Ejecutamos los scripts autogen-sh y configure, éste último con la
opción –with-heartbeat para especificar que Heartbeat es el que actúa como capa de
comunicación/mensajes entre los nodos del clúster (recordemos que es posible también utilizar
OpenAIS):
Pacemaker-1-0-Pacemaker-1.0.8# ./autogen.sh
Pacemaker-1-0-Pacemaker-1.0.8# ./configure –-with-heartbeat
Ejecutamos make y make install para finalizar compilando e instalando Pacemaker:
Pacemaker-1-0-Pacemaker-1.0.8# make
Pacemaker-1-0-Pacemaker-1.0.8# make install
Con Pacemaker instalado ya disponemos de nuestra solución de alta disponibilidad
Linux-HA completamente instalada y lista para ser configurada según nuestras necesidades. En
el siguiente apartado vemos cómo podemos hacerlo de forma general editando los ficheros de
configuración de Heartbeat y mediante el administrador Pacemaker, uno de los puntos fuertes
de esta última versión disponible.
2.3 CONFIGURACION DE HEARTBEAT 3
En este apartado vamos a estudiar cómo configurar Heartbeat 3 y nuestro clúster de alta
disponibilidad de una forma sencilla y práctica. Para ello editamos algunos ficheros de
configuración para el componente Heartbeat, para caracterizar las comunicaciones y la
seguridad entre los nodos, y presentamos y usamos la interfaz administrativa para el clúster y
sus recursos Pacemaker. Más adelante en este mismo documento vemos un ejemplo concreto de
cómo llevar a cabo esta configuración en un clúster virtual de alta disponibilidad, uniendo Xen
y Linux-HA.
Dividimos la configuración de nuestro clúster de alta disponibilidad en varias etapas,
distinguiendo además de si la configuración debe ser realizada en todos los nodos del clúster o
no.
2.3.1 Configuración en todos los nodos del clúster
A continuación vemos paso a paso la configuración que debemos realizar en cada uno
de los nodos que forman parte del clúster. Como podemos ver, algunos de estos cambios se
realizan de la misma forma en cada nodo, mientras que otros simplemente debemos adaptarlos
en función del nodo que estamos configurando.
Nombre del nodo y fichero /etc/hosts
Cada uno de los nodos debe disponer de un nombre único que lo identifica
unívocamente en el clúster. Como se ha comentado en el apartado anterior, podemos establecer
el nombre del nodo haciendo uso del comando hostname. Si no facilitamos ningún nombre
como parámetro al comando obtenemos el nombre actual para el nodo.
Además, es fundamental que en cada uno de los nodos del clúster editemos el fichero
/etc/hosts como también hemos indicado en el apartado anterior. Incluimos una línea por cada
uno de los nodos del clúster, especificando dirección de red y nombre.

Fichero /etc/ha.d/authkeys
En el fichero /etc/ha.d/authkeys vamos a configurar las claves de las que hacen uso los
nodos del clúster para autenticarse, habiendo tres esquemas diferentes posibles para ser usados:
crc, md5 o sha1. Es decir, en este fichero configuramos los aspectos de seguridad del clúster.
Usaremos uno u otro modo de autenticación dependiendo de las exigencias de seguridad y
rendimiento que establezcamos:
• El método crc es recomendable cuando los nodos del clúster se comunican a través de
una red segura. Crc apenas consume recursos por lo que su aplicación también es
recomendable cuando necesitamos disponer de la máxima cantidad de recursos posible.
• La autenticación mediante sha1 es justamente lo contrario, es el método que requiere
una mayor cantidad de recursos de CPU en su aplicación al mismo tiempo que aporta
una gran seguridad.
• Como solución intermedia a los dos métodos anteriores existe md5.
De forma general el fichero muestra el siguiente contenido:
auth <identificador>
<identificador> <metodo_autenticacion> [<clave_autenticacion>]
Fichero /etc/ha.d/ha.cf
La configuración principal del clúster es la que incluimos en el fichero ha.cf, ubicado en
el directorio /etc/ha.d/. El fichero contiene todas las características configurables para el clúster,
las cuales pueden ser habilitadas o deshabilitadas en función de la configuración requerida; para
ello basta con descomentar o comentar la línea correspondiente, respectivamente. De manera
general podemos decir que algunos de los aspectos configurables son los ficheros que
almacenan información sobre la ejecución de los servicios como log, los parámetros que rigen la
monitorización de recursos y nodos, puertos e interfaces de escucha para Heartbeat o los nodos
que conforman el clúster.
Veamos cuáles son las opciones configurables más destacables:
• debugfile. Permite especificar la ubicación del fichero que almacena los mensajes
generados por Heartbeat en modo depuración.
• logfile. Al igual que la opción anterior, nos permite generar el resto de mensajes
generados como log.
• logfacility. En él indicamos la facilidad para el uso de syslog() o logger.
• keepalive. Es el tiempo (por defecto en segundos, aunque es posible especificarlo en
milisegundos escribiendo ms) que transcurre entre la emisión de dos pings hacia cada
nodo del clúster para su monitorización.

• deadtime. Permite especificar el tiempo en segundos que deben transcurrir para asumir
que un nodo no encuentra disponible o que está muerto. Si establecemos este parámetro
demasiado bajo podemos experimentar un conocido problema denominado splitbrain o
partición del clúster, en el que varios nodos o grupos de nodos pueden tomar la
ejecución de un recurso al mismo tiempo al creer que el resto no se encuentran
disponibles.
• warntime. En la opción warntime especificamos el tiempo en segundos que transcurre
antes de indicar la advertencia de último intento de ping en la monitorización. Si es
habitual alcanzar el último intento de ping entonces quiere decir que nos encontramos
próximos a considerar el nodo como muerto.
• initdead. Es el tiempo en segundos que debe transcurrir de manera obligatoria antes de
la puesta en marcha de Heartbeat. Si por el motivo que fuese un nodo no logra iniciarse
antes de que transcurra este tiempo es considerado como un nodo muerto.
• udpport. Permite especificar el número de puerto que utilizar Hearbeat para las
comunicaciones de tipo unicast y broadcast. Este puerto es el mismo tanto para el envío
de pings de monitorización al resto de nodos como para su recepción.
• bcast. Interfaz de red que usa Heartbeat para el envío de los pings. Lógicamente, si
nodos diferentes disponen de interfaces de red diferentes debemos tenerlo en cuenta a la
hora de establecer el valor de esta opción.
• ucast. Su uso es similar a la opción anterior, con la diferencia de que es usada cuando
disponemos solamente de comunicaciones entre pares de nodos en el clúster. Además
de la interfaz de red para la comunicación escribimos la dirección de red del otro nodo,
por lo que este parámetro es diferente en cada nodo.
• autofailback. Esta opción sirve para especificar el comportamiento de Heartbeat
cuando un fallo se produjo en el nodo activo que ejecutaba los servicios, éstos fueron
migrados a otro nodo y después se solventaron los problemas en el nodo primario. Hay
dos opciones posibles: que una vez que el nodo que falló se recupera los recursos
vuelvan a él, o que permanezcan en el nuevo nodo activo. Para la primera opción
escribimos el valor true mientras que para la segunda escribimos false.
• node. Con node especificamos los nodos que forman parte del clúster. Para cada nodo
escribimos el nombre que obtenemos al ejecutar en él el comando hostname o uname –
n, de ahí la importancia de su configuración como hemos visto anteriormente.
• crm. Con el uso de la opción crm permitimos o no el uso del administrador de recursos
del clúster CRM (Cluster Resource Manager). Escribimos yes para permitirlo o no para
no hacerlo. Como ya hemos dicho en varias ocasiones, Pacemaker es el CRM que
estudiamos en este capítulo y que aplicamos para la administrar la funcionalidad y los
recursos de nuestro clúster.
Como podemos imaginar existen otras muchas opciones disponibles para su
configuración en este fichero; aunque las presentadas son las más básicas con su uso podemos
garantizar el correcto funcionamiento de nuestro sistema Linux-HA.

2.3.2 Configuración en uno de los nodos del clúster
A continuación seguimos configurando el clúster desde uno de los nodos del mismo, ya
que como vamos a ver los cambios que aplicamos se replican y distribuyen al resto de nodos
realizada la configuración vista hasta el momento. Es momento de comenzar a definir la
funcionalidad de nuestro clúster: qué servicios se van a ser ejecutados y en qué nodos, cómo
van a ser monitorizados tanto nodos como servicios o recursos, qué tipo de comunicaciones se
establecen entre los nodos, cuando se produce la migración de los servicios o grupos de
servicios, etc. Para configurar todos estos aspectos usamos la aplicación Pacemaker.
Introducción a la configuración del CRM/Pacemaker
Como ya hemos citado en algunas ocasiones Pacemaker es el administrador de
recursos del clúster (Cluster Resource Manager o CRM) que vamos a usar de manera conjunta
con Heartbeat 3 (como capa de mensajes/comunicación) en nuestro sistema de alta
disponibilidad Linux-HA. Con Pacemaker gestionamos toda la funcionalidad del clúster: nodos,
recursos, ficheros de configuración, propiedades globales del clúster, agentes de recursos, etc.
Todos estos aspectos quedan recogidos en la configuración del clúster en forma de fichero xml,
por lo que uno de los objetivos principales de Pacemaker es facilitar la manipulación de estos
ficheros por parte del administrador.
A continuación presentamos y analizamos algunos de los elementos más importantes
del fichero cib.xml, antes de realizar su configuración en el clúster. Es de importancia que el
administrador del clúster conozca bien en qué consisten, cuál es su finalidad o qué puede
obtener cuando se incluyen o aplican. El fichero cib.xml (Cluster Information Base), ubicado en
el directorio /usr/var/lib/heartbeat/crm/ es el fichero principal que recoge toda la funcionalidad
del clúster y cómo ésta se encuentra configurada y debe ser explotada. Además de editar el
contenido de cib.xml con Pacemaker (crm) es posible hacerlo de forma manual si así lo
deseamos; la sintaxis utilizada en los comandos crm es prácticamente igual a la notación xml
utilizada en el fichero para representar los diferentes elementos.
El fichero cib.xml
Analicemos la estructura de este fichero tan importante y qué tipo de elementos puede
contener en sus líneas para definir el comportamiento del clúster. El archivo cib.xml contiene
dos secciones bien diferenciadas: una sección estática <configuration> que recoge la
configuración del clúster y otra dinámica <status> que contiene su estado en todo
momento:
<cib>
<configuration>
<crm_config/>
<nodes/>
<resources/>
<constraints/>
</configuration>
<status/>
</cib>
La sección <status> (dinámica) es mantenida en todo momento por el CRM mostrando
información sobre el estado actual del clúster: qué nodos se encuentran online y cuáles offline,
en qué nodos se encuentran ejecutándose los recursos, cuáles fueron los últimos fallos

registrados por Heartbeat, etc. Ya que es actualizada por el CRM no es recomendable manipular
manualmente esta sección y sí en cambio hacer uso de las herramientas disponibles para ello.
Como podemos ver en el código anterior la sección <configuration> contiene a su vez
otras cuatro sub-secciones. En cada una de estas sub-secciones es donde se incluyen los
diferentes elementos que componen y determinan la configuración del clúster: propiedades
generales para el clúster, definición y configuración de nodos, definición y configuración de
recursos y restricciones o relaciones entre los recursos. Veamos en los siguientes puntos en qué
consiste cada una de ellas:
• Configuración del CRM. La sección <crm_config> contiene los distintos atributos y
propiedades que determinan cómo se comporta el clúster como entidad grupal. Esta
configuración era por lo general más difícil de establecer en versiones anteriores de
Heartbeat, pero en la actual gracias a Pacemaker es mucho más sencillo ya que éste
permite que se gestionen de forma automática los identificadores de las propiedades o
las etiquetas xml que debemos utilizar.
Entre las propiedades básicas para la configuración de nuestro clúster
encontramos las siguientes:
o default-action-timeout. Es el tiempo máximo o timeout fijado para que un
agente de recurso realice una operación determinada (start, stop, status,
monitor) sobre un recurso. Si definimos un timeout particular para la operación
en el recurso, es éste último el timeout que se aplica y no el establecido en
action-idle-timeout.
o symmetric-cluster. Permite indicar si el clúster es simétrico (los recursos
pueden ser ejecutados en cualquier nodo, true) o no (false), en cuyo caso
debemos especificar en cuáles es posible.
o stonith-enabled. Mediante esta propiedad podemos habilitar o no el que un
dispositivo adicional al clúster (dispositivo stonith) pueda apagar un reiniciar un
nodo que ha experimentado dificultades (esta operación es conocida como node
fencing). Es necesario su uso en ocasiones, ya que es posible que aunque un
nodo haya sido identificado como fallido no haya liberado los recursos que
estaba ejecutando.
o stonith-action. Permite especificar la acción a llevar a cabo por el dispositivo
stonith, visto en la propiedad anterior. Tenemos dos posibilidades: off para
apagar el nodo fallido y reboot para reiniciarlo.
o cluster-infrastructure. Permite especificar el tipo de infraestructura para el
clúster, pudiendo elegir entre heartbeat u openais dependiendo de la utilidad
empleada para realizar las funciones propias en la capa de comunicación y
mensajes de la solución de alta disponibilidad.
o no-quorum-policy. Permite definir qué hacer cuando el clúster no dispone de
mecanismo quorum, el encargado de resolver el problema citado anteriormente
llamado SplitBrain. La solución planteada por quorum es la de no seleccionar
más de una partición en el clúster para la ejecución de los recursos cuando
fallen las comunicaciones.
o default-resource-stickiness. Permite establecer la adherencia por defecto de los
recursos para ser ejecutados en el nodo actual o por el contrario ser migrados a

otro nodo que ofrece unas condiciones mejores. Aunque admite valores
negativos, lo normal es establecer un valor mayor o igual a cero, teniendo que
cuanto mayor sea el valor mayor es la adherencia para permanecer en el nodo
actual. Si establecemos como valor INFINITY, el recurso nunca es migrado a
otro nodo. Es útil sobre todo cuando establecemos sistemas de puntuaciones
para la ejecución de los recursos en determinados nodos, en los que el valor
escrito en default-resource-stickiness o resource-stickiness para el recurso es
añadido a su puntuación particular para ser ejecutado en un nodo.
o default-resource-failure-stickiness. De forma similar a default-resource-
stickiness, en este caso establecemos un valor que es usado como penalización
en la puntuación del recurso para ser ejecutado en un determinado nodo.
Análogamente, aunque admite valores positivos lo normal es utilizar valores
menores o iguales a cero, teniendo que si escribimos –INFINITY el recurso es
migrado a otro nodo siempre que un fallo sea detectado.
o is-managed-default. Mediante esta propiedad es posible habilitar la
administración manual del clúster, lo que incluye operaciones tales como la
manipulación del estado de un recurso –iniciarlos, pararlos-, el nodo en el que
se encuentra ejecutándose, etc.
• Nodos y grupos de nodos. En esta segunda parte de la sección <configuration>,
<nodes>, son incluidos los nodos que forman el clúster. Para identificar cada nodo de
forma única dentro del clúster disponemos de su nombre de equipo (el que
establecemos con el comando hostname) y un identificador alfanumérico.
Para hacer más fácil la configuración del clúster cuando el número de nodos
comienza a no ser lo manejable que deseamos Heartbeat permite agrupar varios nodos
en grupos de nodos. Así, de igual forma que es posible establecer restricciones o
relaciones de orden, colocación o localización entre diferentes nodos lo es entre grupos
de nodos. Por ejemplo, podemos establecer para un determinado recurso que sólo sea
posible ejecutarlo en un grupo de nodos determinado.
• Recursos y grupos de recursos. En la sección <resources> definimos los recursos del
clúster, es decir, los elementos a los que queremos dotar de alta disponibilidad. En esta
definición incluimos servicios, aplicaciones, herramientas, configuraciones, elementos
hardware… Por ejemplo, un recurso puede ser una dirección IP, el servicio de
centralitas de VoIP Asterisk, un servidor web, un disco duro, una tarjeta de red, etc.
Un recurso debe poder soportar cuatro operaciones diferentes: start, stop, status
y monitor. Es decir, para que un elemento pueda actuar como recurso en la
infraestructura de alta disponibilidad administrada por Heartbeat debe poder ser
iniciado, detenido, y debe ser posible comprobar su estado en cualquier instante de
tiempo (status: iniciado o detenido) y el estado de su ejecución (monitor). Para
administrar los recursos Heartbeat hace uso de unos scripts que contienen información
sobre cómo llevar a cabo estas operaciones: los agentes de recursos. Los agentes de
recursos son creados siguiendo diferentes estándares, por ejemplo lsb u ocf. Es
obligatorio que para poder ofrecer alta disponibilidad de un recurso dispongamos de un
agente de recurso para operar sobre él; Heartbeat proporciona una gran cantidad de
agentes de recursos para los recursos más habituales, pero para otros debemos
implementarlos nosotros mismos como usuarios o cambiar los existentes (por ejemplo,
para dotar de alta disponibilidad al servicio Asterisk debemos editar el script asterisk

instalado por defecto con la aplicación ya que éste no incluye las operaciones status y
monitor).
En muchas ocasiones, cuando el número de recursos en nuestro sistema de alta
disponibilidad crece, es necesario tratar varios recursos de la misma forma, aplicar un
gran número de restricciones o relaciones entre los recursos, etc. Es por ello que
Heartbeat permite el establecimiento de grupos de recursos, siendo éstos manipulados
como si de un solo recurso se tratara, facilitando enormemente las tareas de
configuración y administración de la alta disponibilidad del clúster. Los recursos que
forman parte de un grupo de recursos:
o Siempre son ejecutados en el mismo nodo, es decir, existe una restricción de
colocación entre los recursos de un mismo grupo de forma que cada recurso
siempre es ejecutado en el mismo nodo que el resto.
o Siempre son puestos en marcha y detenidos en el mismo orden, es decir,
existe una restricción de orden entre los recursos de un mismo grupo que los
obliga a ello.
Como los grupos de recursos son tratados como si fueran recursos individuales
también es posible definir restricciones o relaciones entre grupos de recursos de la
misma forma.
• Restricciones. Como se ha citado en varias ocasiones en las últimas páginas es posible
establecer ciertas restricciones o relaciones entre nodos o grupos de nodos y entre
recursos o grupos de recursos con el objetivo de definir de la forma más concisa
posible su comportamiento. Aplicar restricciones se hace necesario cuando existen
dependencias entre recursos. Por ejemplo, el recurso Asterisk requiere ser ejecutado en
el mismo nodo que el recurso IPaddr (IP virtual), ya que de lo contrario el Asterisk
estaría en funcionamiento pero no accesible para el establecimiento de llamadas.
En Heartbeat existen tres tipos de restricciones o relaciones entre recursos:
o Restricciones de localización. Permiten especificar para un recurso en qué
nodos es posible su ejecución. Para ello son utilizadas reglas de preferencia
para la ejecución del recurso en un nodo y se evalúan determinadas expresiones
como condiciones para ver si la regla se cumple o no. Para referenciar el
recurso utilizados su identificador único. La prioridad de ejecución del recurso
en el nodo es recogida en el atributo score. Si al evaluar la condición la regla se
cumple, la puntuación del recurso es modificada teniendo en cuenta score.
o Restricciones de colocación. Permiten indicar qué recursos pueden ser
ejecutados en un mismo nodo y qué recursos no pueden hacerlo. En este tipo de
restricciones dos recursos son citados junto a una puntuación o score asociada
que determina si pueden ser ejecutados en el mismo nodo o no. Lo habitual es
escribir como puntuación INFINITY si deseamos que puedan hacerlo o –
INFINITY en caso contrario. El orden en que son facilitados los dos recursos es
determinante (el primer recurso es denominado recurso ’from’ y el segundo
recurso o ‘to’), ya que no es lo mismo imponer que un recurso A sea ejecutado
siempre en el mismo nodo que el recurso B que al contrario.
o Restricciones de orden. Son utilizadas para especificar el orden en que las
operaciones start y stop que debe realizar un agente de recurso tienen que
llevarse a cabo. Esto es necesario, por ejemplo, cuando ponemos en marcha un
sitio web que hace uso de una base de datos: el servicio de base de datos debe

estar iniciado previamente. Es posible especificar que la operación se realice
antes o después para el primer recurso en relación al segundo.
Configuración del fichero cib.xml con Pacemaker
Con configuración cib (Cluster Information Base) hacemos referencia a la
configuración que realizamos en el fichero cib.xml. Este fichero contiene toda la configuración
funcional del clúster, especificada en notación xml. En versiones anteriores de Heartbeat
teníamos que editar este fichero directamente, con las complicaciones que ello conlleva. En
cambio, en la versión actual disponemos de Pacemaker, y más concretamente de su utilidad
crm, para su edición y configuración.
Antes de comenzar a utilizar crm debemos iniciar el servicio Heartbeat en cada uno de
los nodos del clúster, para lo que ejecutamos el script ubicado en /etc/init.d/ con el parámetro
start:
# /etc/init.d/heartbeat start
Starting High-Availability services: Done.
Con Heartbeat ejecutándose basta con escribir el comando crm en una terminal para
acceder a la consola de esta herramienta como podemos ver a continuación:
# crm
crm(live)#
A partir de aquí se abre un abanico de diversos menús y posibilidades para la
configuración del clúster estructurados en niveles administrativos. Si pulsamos dos veces la
tecla tabulador o escribimos help en el primer nivel podemos observar los diferentes menús de
configuración y comandos disponibles para comenzar, como se aprecia en la figura 6-4.
Figura 6.4. Diferentes menús disponibles al comenzar a trabajar con crm.
Veamos de forma breve en qué consiste cada una de estas posibilidades:
• cib. Eligiendo cib estamos en disposición de editar y configurar el fichero cib.xml. crm
guarda en diferentes ficheros denominados cib shadow las distintas configuraciones que
vayamos realizando. Por ejemplo, podemos crear un cib shadow para la configuración
del clúster con alta disponibilidad para el servicio Asterisk, y otro cib shadow para la
configuración con alta disponibilidad para el servicio web Apache; es decir, podemos

mantener un fichero por cada servicio que ofrece el clúster y aplicarlo cuando lo
creamos conveniente.
Desde cib podemos crear nuevos ficheros shadow, editar los existentes o
eliminarlos, elegir el que queremos usar, distribuir los cambios realizados al resto de
nodos del clúster, etc. Si escribimos help después de ingresar en cib podemos ver las
distintas posibilidades que tenemos, como muestra la figura 6.5: new, delete, reset,
commit, use, diff, list, import, cibstatus, quit, bye, exit, help, end, cd y up.
Figura 6.5. Comandos posibles a ejecutar en el nivel cib.
• resource. Escribiendo resource accedemos a la administración de los recursos del
clúster. Podemos conocer el estado de los recursos, listarlos, cambiar su estado
(iniciarlos, detenerlos, reiniciarlos…), migrarlos a otro nodo del clúster, editar los
parámetros de los mismos así como sus metadatos, ver la cuenta de fallos asociada, etc.
Figura 6.6. Comandos posibles a ejecutar en el nivel resource.

• node. Node permite el acceso a la administración de los nodos que forman parte del
clúster. Disponemos de comandos para mostrar o listar los nodos del clúster, cambiar el
estado de un nodo (online/offline), apagarlo, eliminarlo de la configuración… también
podemos conocer el estado de sus atributos y editarlos si lo consideramos necesario.
Figura 6.7. Comandos posibles a ejecutar en el nivel node.
• options. Desde aquí podemos editar las preferencias relativas al usuario para la interfaz
de la consola. Por ejemplo, es posible cambiar el usuario para el clúster, qué editor abrir
cuando editamos directamente ficheros, o el esquema de colores utilizado para la salida
de crm.
Figura 6.8. Comandos posibles a ejecutar en el nivel node.
• configure. A través de configure desarrollamos la configuración que contienen los
ficheros cib shadow. El número de comandos disponibles bajo configure es mucho
mayor que en los casos anteriores, ya que la configuración posible a realizar también es
mayor. Es muy importante este menú ya que a través de él podemos realizar las
operaciones más relevantes, como la administración de nodos y recursos en el clúster,
la administración de grupos de recursos, de restricciones de localización/orden para los
recursos, o propiedades generales del clúster, por ejemplo.

Figura 6.9. Comandos posibles a ejecutar en el nivel cib.
Asimismo podemos realizar muchas más operaciones necesarias e interesantes,
como la manipulación en vivo del fichero CIB, su publicación y distribución en el resto
de nodos del clúster… Dos de los comandos más importantes son show y commit. Si
ejecutamos el comando show podemos ver la configuración actual del clúster (véase la
figura 6.10); ejecutando commit actualizaremos la configuración CIB en todos los
nodos.
Figura 6.10. Ejecución del comando show en el nivel configure.
• ra. En el nivel ra encontramos el centro de información sobre los agentes de recurso.
Los agentes de recurso permiten controlar los recursos del clúster y realizar diversas
operaciones sobre ellos (como iniciarlos, detenerlos, etc.) pudiendo seguir para ello
diferentes estándares (lsb, ocf,…).

Figura 6.11. Comandos posibles a ejecutar en el nivel ra.
Como se puede apreciar en la figura 6.11, es posible por ejemplo listar las clases
y proveedores de agentes de recursos, listar los agentes de recursos para una
determinada clase o proveedor o mostrar los metadatos sobre un agente de recurso.
• status. Tecleando status accedemos al nivel para conocer el estado del clúster. Muestra
si los nodos se encuentran actualmente online, qué servicios se encuentran ejecutándose
en qué nodos, cuáles fueron los últimos fallos detectados, etc (véase la figura 6.7).
Figura 6.12. Ejecución del comando/nivel status.
• quit, bye, exit. Se trata de los tres comandos disponibles para abandonar crm.
• help. Ejecutando help obtenemos ayuda en cualquier momento, no sólo en el primer
nivel de la aplicación, sobre los comandos y opciones disponibles.
• end, cd, up. Mediante estos tres comandos podemos navegar entre los diferentes niveles
administrativos en los que se encuentra dividido crm, ya que permiten regresar al nivel
inmediatamente superior.
Conocemos en mayor profundidad cómo realizar una configuración de nuestro sistema
de alta disponibilidad con Pacemaker y crm en el siguiente apartado, en el que desarrollamos la
implementación de un clúster virtual de alta disponibilidad para el servicio Asterisk. Además de
las utilidades de configuración presentadas Heartbeat dispone de otras muchas que pueden ser
utilizadas en función de nuestras necesidades, como por ejemplo Softdog, Stonith o pingd, que

permite determinar si un nodo ha perdido la conectividad cuando su interfaz de red cae o no es
alcanzable y migra los recursos que estuviera ejecutando.
Hemos podido comprobar que las posibilidades presentadas por Pacemaker, crm y
Heartbeat son muy grandes. Es de absoluta recomendación visitar la web de Cluster Labs
(http://www.clusterlabs.org/) y revisar la documentación facilitada para conocer mejor cómo
configurar nuestro clúster; hay determinadas cuestiones, como por ejemplo los atributos
configurables para un nodo o un recurso, que es recomendable consultar en la documentación
facilitada: la guía Cluster from scratch (clúster desde cero) wiki, ejemplos, guías howto,
referencias, etc.
33 AAllttaa ddiissppoonniibbiilliiddaadd eenn ccllúússtteerreess vviirrttuuaalleess ccoonn HHeeaarrttbbeeaatt 33
Una vez que hemos presentado en las páginas anteriores en qué consiste teóricamente
un clúster de alta disponibilidad y cómo es posible instalar y configuración la solución más
importante en este campo vamos a aplicarlo de forma práctica en la construcción de un clúster
virtual de alta disponibilidad para el servicio de telefonía IP Asterisk.
Como fue introducido en el capítulo 2. Virtualización de Plataforma podemos
relacionar de forma inmediata las técnicas de clustering y la virtualización mediante la
creación de clústeres virtuales, en los que los dominios invitados pueden actuar como nodos del
clúster. Los nodos virtuales pueden por tanto encontrarse ubicados en un mismo equipo físico si
comparten el sistema anfitrión o bien en anfitriones distintos si así lo consideráramos necesario.
De esta forma podemos ver cómo es posible integrar estas dos tecnologías y conseguir exprimir
al máximo las ventajas de una y otra, especialmente las que puede aportar la
virtualización: podemos ahorrar espacio y consumo por parte de los nodos del clúster,
aprovechamos en mayor grado el hardware de los servidores, y los costes administrativos se
reducen, permitiendo debido a la nueva naturaleza de los nodos del clúster mejorar los procesos
de recuperación ante desastres, puesta en marcha, copias de seguridad, etc. Esta mejoría la
podemos apreciar más aún si cabe si implantamos un clúster virtual de tipo Beowulf, en el que
todos los nodos son idénticos. En tal caso tan sólo debemos configurar una máquina virtual y
replicarla tantas veces como nodos queramos tener disponibles.
Mediante el establecimiento de clústeres virtuales potenciamos dos de las
características fundamentales que deben estar presentes en un clúster: escalabilidad y robustez.
Es indudable la gran escalabilidad de las máquinas virtuales frente a equipos físicos, resultando
mucho más económico, aumentando la seguridad y flexibilidad de nuestras configuraciones.
Respecto a estas características debemos puntualizar un detalle: si disponemos nuestro clúster
virtual en un único servidor físico tanto escalabilidad como robustez disminuyen
considerablemente, ya que la depende fundamentalmente de los recursos disponibles en él y si
cae el servidor físico por un fallo hardware, las máquinas virtuales que aloja caerían también.
Por este motivo es totalmente recomendable que un clúster virtual no sólo disponga de un
servidor físico como anfitrión.
En la figura 6.13 podemos apreciar la arquitectura presentada por el clúster virtual de
alta disponibilidad que desarrollamos y configuramos en los apartados siguientes. Como
podemos ver en la imagen y de acuerdo a todo el trabajo realizado hasta el momento usamos
Xen como virtualizador de plataforma en la consolidación de servidores de telefonía IP
Asterisk, y Heartbeat-Linux-HA para proporcionar alta disponibilidad a los nodos virtuales.

Figura 6.13. Clúster virtual de alta disponibilidad usando Xen, Asterisk y Heartbeat.
Disponemos de dos anfitriones diferentes para crear una infraestructura lo más real y
eficiente posible; aunque en ella sólo incluimos un dominio por anfitrión en condiciones reales
éstos pueden convivir con otros que sean configurados con otros propósitos. Los equipos usados
como anfitriones son exactamente idénticos en hardware y sistema operativo: ambos son
servidores HP Proliant DL120 G5 con procesador Intel(R) Xeon(R) CPU E3110 @ 3.00GHz
y de 4Gb de memoria RAM. Como sistema operativo disponen de Debian 5 Lenny. Veamos a
continuación los pasos seguidos para la creación del clúster virtual: configuración de los
servidores anfitriones con Xen, puesta en marcha de los nodos virtuales con Asterisk como
servicio crítico en ejecución y finalmente la configuración de alta disponibilidad gracias al uso
de Heartbeat 3.
3.1 CONFIGURACION DE LOS SERVIDORES ANFITRIONES
Un clúster virtual no puede ser creado sin configurar previamente los servidores
anfitriones que van a soportar la creación y mantenimiento de los dominios invitados o nodos
virtuales. Contamos para nuestro caso práctico de dos servidores con las características
recogidas en la tabla 6.1.
Tabla 6-1. Servidores anfitriones que aloja el clúster virtual
Modelo Procesador Memoria Virtualiz. HW Disco Red
HP
Proliant
DL120 G5
Intel(R) Xeon(R) CPU
E3110 @ 3.00GHz
(Coreduo)
4 Gb
SDRAM
DDR2 PC2-
6400
Sí (Intel VT -
vmx)
1 disco duro
SATA 250 Gb
NetXtreme
BCM5722
Gigabit
Ethernet PCI
Express 1GB/s
64 bits
Ambos servidores disponen del mismo hardware y el mismo sistema operativo
instalado, Debian 5 Lenny como hemos citado en el apartado anterior. Partiendo de este punto,

Xen ha sido instalado en ambos servidores (deb1 y deb2) como virtualizador de plataforma,
siguiendo los procedimientos y configuraciones explicadas en detalle en los capítulos 3 y 4, Xen
y Desarrollo, Implementación y Prueba de una Infraestructura Virtual.
3.2 PUESTA EN MARCHA DE LOS NODOS VIRTUALES
Para la creación y puesta en marcha de los nodos virtuales de nuestro clúster creamos
una máquina virtual tipo en uno de los anfitriones la cual replicamos en el segundo anfitrión. De
esta forma los tiempos de aprovisionamiento y disposición de los nodos virtuales pueden verse
considerablemente reducidos, quedando pendiente la configuración particular para cada nodo,
como por ejemplo sus interfaces de red o nombre de host.
Las imágenes de disco de las máquinas virtuales han sido creadas siguiendo la
metodología vista en los capítulos 3 y 4, teniendo como sistema operativo instalado Debian 5
Lenny. A continuación podemos ver el contenido de los ficheros de configuración de ambos
dominios (ast1 y ast2, los dos nodos virtuales), usados por los anfitriones para el arranque de
los mismos.
Fichero de configuración para el dominio/nodo virtual ast1:
kernel = "/boot/vmlinuz-2.6.26-2-xen-amd64"
ramdisk = "/boot/initrd.img-2.6.26-2-xen-amd64"
memory = 1024
name = "ast1"
disk =
['file:/media/imagenes/ast1_hb/imagen,sda1,w','file:/media/imagenes/
ast1_hb/swap,sda2,w']
root = "/dev/sda1 ro"
dhcp = "no"
vif = ['mac=1A:1B:1C:2A:2B:2C']
netmask = '255.255.255.0'
gateway = '150.214.153.1'
ip = '150.214.153.233'
broadcast = '150.214.153.255'
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'
cpus = "0"
vcpus = 1
extra = 'console=hvc0 xencons=tty1'
vnc=1
sdl=0
Fichero de configuración para el dominio/nodo virtual ast2:
kernel = "/boot/vmlinuz-2.6.26-2-xen-amd64"
ramdisk = "/boot/initrd.img-2.6.26-2-xen-amd64"
memory = 1024
name = "ast2"
disk =
['file:/media/imagenes/ast2_hb/imagen,sda1,w','file:/media/imagenes/
ast2_hb/swap,sda2,w']
root = "/dev/sda1 ro"
dhcp = "no"
vif = ['mac=2A:2B:2C:3A:3B:3C']
netmask = '255.255.255.0'
gateway = '150.214.153.1'
ip = '150.214.153.234'

broadcast = '150.214.153.255'
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'
cpus = "1"
vcpus = 1
extra = 'console=hvc0 xencons=tty1'
vnc=1
sdl=0
Es fácil observar que ambos dominios son similares, con las diferencias en su
configuración relativas al nombre de dominio, ficheros imagen de disco y swap, y configuración
de la interfaz de red; es importante resaltar que el nodo ast1 dispone de la dirección IP
150.214.153.233 y el nodo ast2 150.214.153.234. Ambos nodos hacen uso de un solo
procesador de su equipo anfitrión.
Además, en ambos nodos instalamos Asterisk de acuerdo a los pasos presentados en el
capítulo 4, Introducción a la telefonía IP. No es necesario realizar configuración alguna de este
servicio pues las pruebas a realizar en este capítulo tienen como objetivo observar la correcta
migración de los servicios de un nodo a otro del clúster cuando algún fallo es detectado, y no si
Asterisk se encuentra configurado de forma eficiente o conocer el número de llamadas
simultáneas que es capaz de soportar, como se hizo en el capítulo anterior.
Finalmente instalamos también paso por paso ClusterGlue, ResourceAgents, Heartbeat
y Pacemaker en cada uno de los dominios.
3.3 CONFIGURACION DE ALTA DISPONIBILIDAD
Alcanzado este punto disponemos de dos servidores anfitriones con un dominio invitado
ejecutándose en cada uno. Es hora de configurar nuestro sistema de alta disponibilidad como ha
sido presentado anteriormente tomando como nodos de nuestro clúster los dos sistemas
invitados ast1 y ast2. Como podemos ver, una vez que disponemos de nuestros nodos virtuales
ejecutándose, las diferencias entre configurar un clúster virtual y uno normal son inexistentes.
3.3.1 Configuración en todos los nodos del clúster virtual
Sigamos los pasos establecidos en el punto anterior para comenzar a configurar nuestro
clúster virtual. Primero realizamos la configuración replicada en cada uno de los nodos
virtuales del clúster, nos preparamos para dar soporte de alta disponibilidad. Después,
configuramos en un solo nodo el fichero cib.xml, que define cómo es el comportamiento de
nuestro clúster, distribuyéndose automáticamente esta configuración en el resto de nodos.
Nombre del nodo y fichero /etc/hosts
Asignamos a los dos nodos su nombre usando el comando hostname. Comprobamos
que lo hemos hecho correctamente con el propio comando sin parámetros o mediante el
comando uname con el flag -n:
Nodo virtual ast1:
ast1:/# hostname ast1
ast1:/# hostname

ast1
ast1:/# uname -n
ast1
Nodo virtual ast2:
ast2:/# hostname
ast2
ast2:/# uname -n
ast2
Una vez que disponemos de cada nodo con su correspondiente nombre de host
correctamente asignado editamos el fichero /etc/hosts e incluimos una línea por cada nodo. De
esta forma conseguimos que los dos nodos puedan comunicarse usando para ello el nombre de
host en lugar de su dirección de red, requisito necesario presentado por Heartbeat:
150.214.153.233 ast1
150.214.153.234 ast2
Fichero /etc/ha.d/authkeys
A continuación comenzamos con la configuración de Heartbeat editando el
fichero /etc/ha.d/authkeys. Mediante este fichero la seguridad del clúster es configurada,
ya que establecemos cómo vamos a realizar la autenticación entre nodos. Como los
servidores anfitriones se encuentran directamente interconectados a través de un switch
Gigabit Ethernet no son necesarias grandes medidas de seguridad por lo que es suficiente con
aplicar el primero de los métodos vistos, crc:
auth 1
1 crc
Fichero /etc/ha.d/ha.cf
Realizamos ahora la configuración de los aspectos principales de la operatividad de
Heartbeat en el fichero ha.cf. Este fichero es muy importante ya que permite indicar a
Heartbeat por ejemplo cada cuánto tiempo realizar la monitorización de los recursos y nodos o
qué puerto e interfaz utilizar para sus comunicaciones.
A continuación podemos ver un el contenido del fichero ha.cf configurado de forma
idéntica en los dos nodos virtuales (se han destacado las opciones habilitadas en negrita):
#
# There are lots of options in this file. All you have to have is
a set
# of nodes listed {"node ...} one of {serial, bcast, mcast, or
ucast},
# and a value for "auto_failback".
#
# ATTENTION: As the configuration file is read line by line,
# THE ORDER OF DIRECTIVE MATTERS!
#

# In particular, make sure that the udpport, serial baud rate
# etc. are set before the heartbeat media are defined!
# debug and log file directives go into effect when they
# are encountered.
#
# All will be fine if you keep them ordered as in this example.
#
#
# Note on logging:
# If all of debugfile, logfile and logfacility are not
defined,
# logging is the same as use_logd yes. In other case, they are
# respectively effective. if detering the logging to syslog,
# logfacility must be "none".
#
# File to write debug messages to
debugfile /var/log/ha-debug
#
#
# File to write other messages to
#
logfile /var/log/ha-log
#
#
# Facility to use for syslog()/logger
#
logfacility local0
#
#
# A note on specifying "how long" times below...
#
# The default time unit is seconds
# 10 means ten seconds
#
# You can also specify them in milliseconds
# 1500ms means 1.5 seconds
#
#
# keepalive: how long between heartbeats?
#
keepalive 2
#
# deadtime: how long-to-declare-host-dead?
#
# If you set this too low you will get the problematic
# split-brain (or cluster partition) problem.
# See the FAQ for how to use warntime to tune deadtime.
#
deadtime 30
#
# warntime: how long before issuing "late heartbeat" warning?
# See the FAQ for how to use warntime to tune deadtime.
#
warntime 10
#
#
# Very first dead time (initdead)
#
# On some machines/OSes, etc. the network takes a while to come up
# and start working right after you've been rebooted. As a result
# we have a separate dead time for when things first come up.
# It should be at least twice the normal dead time.
#
initdead 30
#
#
# What UDP port to use for bcast/ucast communication?
#
udpport 694

#
# Baud rate for serial ports...
#
#baud 19200
#
# serial serialportname ...
#serial /dev/ttyS0 # Linux
#serial /dev/cuaa0 # FreeBSD
#serial /dev/cuad0 # FreeBSD 6.x
#serial /dev/cua/a # Solaris
#
#
# What interfaces to broadcast heartbeats over?
#
bcast eth0 # Linux
#bcast eth1 eth2 # Linux
#bcast le0 # Solaris
#bcast le1 le2 # Solaris
#
# Set up a multicast heartbeat medium
# mcast [dev] [mcast group] [port] [ttl] [loop]
#
# [dev] device to send/rcv heartbeats on
# [mcast group] multicast group to join (class D multicast
address
# 224.0.0.0 - 239.255.255.255)
# [port] udp port to sendto/rcvfrom (set this value to
the
# same value as "udpport" above)
# [ttl] the ttl value for outbound heartbeats. this effects
# how far the multicast packet will propagate. (0-255)
# Must be greater than zero.
# [loop] toggles loopback for outbound multicast
heartbeats.
# if enabled, an outbound packet will be looped back
and
# received by the interface it was sent on. (0 or 1)
# Set this value to zero.
#
#
#mcast eth0 225.0.0.1 694 1 0
#
# Set up a unicast / udp heartbeat medium
# ucast [dev] [peer-ip-addr]
#
# [dev] device to send/rcv heartbeats on
# [peer-ip-addr] IP address of peer to send packets to
#
#ucast eth0 192.168.1.2
#
#
# About boolean values...
#
# Any of the following case-insensitive values will work for true:
# true, on, yes, y, 1
# Any of the following case-insensitive values will work for
false:
# false, off, no, n, 0
#
#
#
# auto_failback: determines whether a resource will
# automatically fail back to its "primary" node, or remain
# on whatever node is serving it until that node fails, or
# an administrator intervenes.
#
# The possible values for auto_failback are:
# on - enable automatic failbacks
# off - disable automatic failbacks
# legacy - enable automatic failbacks in systems

# where all nodes do not yet support
# the auto_failback option.
#
# auto_failback "on" and "off" are backwards compatible with the
old
# "nice_failback on" setting.
#
# See the FAQ for information on how to convert
# from "legacy" to "on" without a flash cut.
# (i.e., using a "rolling upgrade" process)
#
# The default value for auto_failback is "legacy", which
# will issue a warning at startup. So, make sure you put
# an auto_failback directive in your ha.cf file.
# (note: auto_failback can be any boolean or "legacy")
#
auto_failback off
#
#
# Basic STONITH support
# Using this directive assumes that there is one stonith
# device in the cluster. Parameters to this device are
# read from a configuration file. The format of this line is:
#
# stonith <stonith_type> <configfile>
#
# NOTE: it is up to you to maintain this file on each node in
the
# cluster!
#
#stonith baytech /etc/ha.d/conf/stonith.baytech
#
# STONITH support
# You can configure multiple stonith devices using this
directive.
# The format of the line is:
# stonith_host <hostfrom> <stonith_type> <params...>
# <hostfrom> is the machine the stonith device is attached
# to or * to mean it is accessible from any host.
# <stonith_type> is the type of stonith device (a list of
# supported drives is in /usr/lib/stonith.)
# <params...> are driver specific parameters. To see the
# format for a particular device, run:
# stonith -l -t <stonith_type>
#
#
# Note that if you put your stonith device access information in
# here, and you make this file publically readable, you're asking
# for a denial of service attack ;-)
#
# To get a list of supported stonith devices, run
# stonith -L
# For detailed information on which stonith devices are supported
# and their detailed configuration options, run this command:
# stonith -h
#
#stonith_host * baytech 10.0.0.3 mylogin mysecretpassword
#stonith_host ken3 rps10 /dev/ttyS1 kathy 0
#stonith_host kathy rps10 /dev/ttyS1 ken3 0
#
# Watchdog is the watchdog timer. If our own heart doesn't beat
for
# a minute, then our machine will reboot.
# NOTE: If you are using the software watchdog, you very likely
# wish to load the module with the parameter "nowayout=0" or
# compile it without CONFIG_WATCHDOG_NOWAYOUT set. Otherwise even
# an orderly shutdown of heartbeat will trigger a reboot, which is
# very likely NOT what you want.
#

#watchdog /dev/watchdog
#
# Tell what machines are in the cluster
# node nodename ... -- must match uname -n
node ast1
node ast2
#
# Less common options...
#
# Treats 10.10.10.254 as a psuedo-cluster-member
# Used together with ipfail below...
# note: don't use a cluster node as ping node
#
#ping 10.10.10.254
#
# Treats 10.10.10.254 and 10.10.10.253 as a psuedo-cluster-member
# called group1. If either 10.10.10.254 or 10.10.10.253 are up
# then group1 is up
# Used together with ipfail below...
#
#ping_group group1 10.10.10.254 10.10.10.253
#
# HBA ping derective for Fiber Channel
# Treats fc-card-name as psudo-cluster-member
# used with ipfail below ...
#
# You can obtain HBAAPI from http://hbaapi.sourceforge.net. You
need
# to get the library specific to your HBA directly from the vender
# To install HBAAPI stuff, all You need to do is to compile the
common
# part you obtained from the sourceforge. This will produce
libHBAAPI.so
# which you need to copy to /usr/lib. You need also copy hbaapi.h
to
# /usr/include.
#
# The fc-card-name is the name obtained from the hbaapitest
program
# that is part of the hbaapi package. Running hbaapitest will
produce
# a verbose output. One of the first line is similar to:
# Apapter number 0 is named: qlogic-qla2200-0
# Here fc-card-name is qlogic-qla2200-0.
#
#hbaping fc-card-name
#
#
# Processes started and stopped with heartbeat. Restarted unless
# they exit with rc=100
#
#respawn userid /path/name/to/run
#respawn hacluster /usr/lib/heartbeat/ipfail
#
# Access control for client api
# default is no access
#
#apiauth client-name gid=gidlist uid=uidlist
#apiauth ipfail gid=haclient uid=hacluster
###########################
#
# Unusual options.
#
###########################
#
# hopfudge maximum hop count minus number of nodes in config
#hopfudge 1
#
# deadping - dead time for ping nodes

#deadping 30
#
# hbgenmethod - Heartbeat generation number creation method
# Normally these are stored on disk and incremented as
needed.
#hbgenmethod time
#
# realtime - enable/disable realtime execution (high priority,
etc.)
# defaults to on
#realtime off
#
# debug - set debug level
# defaults to zero
#debug 1
#
# API Authentication - replaces the fifo-permissions-based system
of the past
#
#
# You can put a uid list and/or a gid list.
# If you put both, then a process is authorized if it qualifies
under either
# the uid list, or under the gid list.
#
# The groupname "default" has special meaning. If it is
specified, then
# this will be used for authorizing groupless clients, and any
client groups
# not otherwise specified.
#
# There is a subtle exception to this. "default" will never be
used in the
# following cases (actual default auth directives noted in
brackets)
# ipfail (uid=HA_CCMUSER)
# ccm (uid=HA_CCMUSER)
# ping (gid=HA_APIGROUP)
# cl_status (gid=HA_APIGROUP)
#
# This is done to avoid creating a gaping security hole and
matches the most
# likely desired configuration.
#
#apiauth ipfail uid=hacluster
#apiauth ccm uid=hacluster
#apiauth cms uid=hacluster
#apiauth ping gid=haclient uid=alanr,root
#apiauth default gid=haclient
# message format in the wire, it can be classic or netstring,
# default: classic
#msgfmt classic/netstring
# Do we use logging daemon?
# If logging daemon is used, logfile/debugfile/logfacility in this
file
# are not meaningful any longer. You should check the config file
for logging
# daemon (the default is /etc/logd.cf)
# more infomartion can be fould in the man page.
# Setting use_logd to "yes" is recommended
#
# use_logd yes/no
#
# the interval we reconnect to logging daemon if the previous
connection failed
# default: 60 seconds
#conn_logd_time 60

#
#
# Configure compression module
# It could be zlib or bz2, depending on whether u have the
corresponding
# library in the system.
#compression bz2
#
# Confiugre compression threshold
# This value determines the threshold to compress a message,
# e.g. if the threshold is 1, then any message with size greater
than 1 KB
# will be compressed, the default is 2 (KB)
#compression_threshold 2
# Enable CRM (Pacemaker)
crm yes
Aunque hemos destacado en negrita las opciones habilitadas y configuradas para el
comportamiento de Heartbeat quedan resumidas como vemos a continuación:
debugfile /var/log/ha-debug
logfile /var/log/ha-log
logfacility local0
keepalive 2
deadtime 30
warntime 10
initdead 30
udpport 694
bcast eth0
auto_failback off
node ast1
node ast2
crm yes
De esta forma determinamos que:
• El fichero para log de mensajes generados por Heartbeat en modo depuración se ubica
en /var/log/ha-debug.
• El fichero para log del resto de mensajes generados por Heartbeat se ubica en
/var/log/ha-log.
• El tiempo que debe transcurrir entre ping y ping hacia cada nodo del clúster para
monitorización hardware es de dos segundos (keepalive).
• El tiempo que debe transcurrir para considerar un nodo del clúster como muerto o no
accesible de 30 segundos (deadtime).
• El número de segundos que tienen que transcurrir antes de indiciar último ping de
monitorización es de 10 (warntime).
• Antes de iniciar el servicio Heartbeat los nodos virtuales deben esperar por espacio de
30 segundos de forma obligatoria (initdead).
• El puerto de escucha para las comunicaciones Heartbeat es el 694.
• La interfaz de red usada para las comunicaciones Heartbeat es eth0. En ambos nodos es
la misma; si en alguno de los nodos el nombre de la interfaz fuera diferente debemos
editar el fichero haciéndolo corresponder con el nombre válido.

• Cuando un fallo es detectado en un nodo y los recursos son migrados a otro válido, una
vez que los problemas son solucionados en el nodo original los recursos permanecen en
el nuevo nodo (auto_failback off).
• El clúster se compone de dos nodos: ast1 y ast2.
• Habilitamos el uso del Cluster Resource Manager o crm (Pacemakerk) para la
administración de los recursos del clúster.
3.3.2 Configuración en uno de los nodos del clúster virtual
Una vez concluida la configuración común para los nodos del clúster virtual debemos
pasar a establecer la configuración de la funcionalidad del clúster. Esto lo hacemos en uno sólo
de los nodos, ya que como hemos citado anteriormente la configuración realizada mediante
Pacemaker es distribuida y replicada entre los diferentes nodos una vez que es aceptada y
guardada.
En el siguiente apartado vemos por tanto cómo definir los servicios/recursos que van a
ser ejecutados en el clúster virtual, en qué nodos van a hacerlo, cómo va a ser implementada la
monitorización de los mismos, qué comunicaciones van a tener lugar entre los nodos y bajo qué
condiciones va a tener lugar la migración de los servicios. De manera resumida, las siguientes
directrices nos permiten configurar la funcionalidad que queremos sea gestionada por Heartbeat
3 y Pacemaker, teniendo en mente la arquitectura desarrollada, mostrada en la figura 6.13
Clúster virtual de alta disponibilidad usando Xen, Asterisk y Heartbeat:
• En nuestro clúster virtual contamos con dos nodos: ast1 y ast2. La definición y
creación de ambos ha sido desarrollada en apartados anteriores. Van a ser los
encargados de la ejecución de los servicios con alta disponibilidad.
• Debemos definir el recurso Asterisk. Este recurso consiste en la ejecución del
software Asterisk para el establecimiento de la centralita VoIP en el clúster.
Debemos dotar a este recurso de alta disponibilidad, siendo ejecutado solamente en
uno de los nodos virtuales del clúster.
• Se hace necesario disponer también de un recurso del tipo IP virtual. Las IPs
virtuales permiten identificar al servicio que es ofrecido a través de ellas (en nuestro
caso Asterisk), sea cual sea su ubicación. Por ejemplo, si un nodo que está
ejecutando Asterisk falla y no disponemos de una IP virtual migrar el servicio a otro
nodo no sirve de nada ya que los clientes siguen intentando acceder al servicio a
través de la dirección IP del nodo que ha fallado; es entonces cuando aparece la
necesidad de utilizar una dirección IP virtual, tratada como un recurso más en el
clúster y que es migrado igualmente entre los nodos, permitiendo que los servicios
se encuentren siempre accesibles en la misma dirección.
• Otro requisito imprescindible es que el recurso Asterisk y el recurso IP virtual
deben conformar un grupo de recursos. El recurso Asterisk precisa que la
dirección IP virtual esté disponible para su funcionamiento, por lo que ambos
recursos deben ejecutarse siempre en el mismo nodo. En definitiva, el grupo de
recursos es tratada como un único recurso. Es el grupo de recursos el lugar en el que
debemos definir las condiciones mediante las cuales los recursos son migrados de
un nodo a otro.

• Del apartado anterior podemos concluir que es fundamental definir las
restricciones de localización, colocación y orden para los recursos del clúster
virtual. Es decir:
Los recursos (o más bien, el grupo de recursos) tiene preferencia para
ejecutarse en el primero de los nodos del clúster, denominado ast1.
Los dos recursos deben ser ejecutados siempre en el mismo nodo; esto,
como ya hemos dicho en el punto anterior, implica la creación del grupo de
recursos.
Finalmente, los recursos del grupo de recursos deben ser iniciados y
detenidos siempre en el mismo orden: primero la IP virtual, después
Asterisk.
• También es necesario como vamos a ver en el siguiente apartado la definición de
algunas variables globales para el clúster virtual, por ejemplo, para especificar el
tipo de infraestructura para el clúster, las políticas quorum o la pegajosidad por
defecto para los recursos (valores que permiten calcular la adherencia de un recurso
para determinados nodos).
A continuación pasamos a detallar cómo podemos lograr establecer toda esta
configuración utilizando Pacemaker sobre nuestro clúster virtual con Heartbeat.
Configuración del fichero cib.xml con Pacemaker
Antes de comenzar a trabajar es requisito previo iniciar el servicio Heartbeat en cada
uno de los nodos del clúster virtual (ast1 y ast1) de la siguiente forma, ejecutando el script
disponible tras su instalación en el directorio /etc/init.d:
ast1:~# /etc/init.d/heartbeat start
ast2:~# /etc/init.d/heartbeat start
Ahora que Heartbeat se encuentra en ejecución podemos iniciar la utilidad CRM
(Cluster Resource Manager) de Pacemaker, para configurar todos los detalles de la
funcionalidad para el clúster virtual de alta disponibilidad. Recordamos que a partir de ahora
sólo debemos trabajar en uno de los nodos del clúster, ya que la configuración realizada es
replicada en el otro nodo de forma automática. Accedemos al intérprete crm ejecutando el
siguiente comando:
ast1:/# crm
crm(live)#
Como primer paso debemos crear el fichero cib shadow en el que vamos a almacenar la
configuración del clúster. Esto lo hacemos ejecutando el comando new en el nivel cib y
escribiendo el nombre que queremos dar al fichero, por ejemplo HA_Asterisk:
crm(live)# cib new HA_Asterisk

INFO: HA_Asterisk shadow CIB created
Con el fichero cib shadow creado debemos indicar a crm que queremos hacer uso de él
de aquí en adelante, ejecutando el comando use también del nivel cib para elegirlo:
crm(HA_Asterisk)# cib use HA_Asterisk
Sentadas las bases para la configuración a realizar, comenzamos creando a continuación
los recursos individuales sobre los que va a operar Heartbeat (dirección IP virtual y Asterisk).
Ahora debemos bajar un nivel y operar en configure, para lo cual operamos así:
crm(HA_Asterisk)# configure
Con crm los recursos son credos mediante el comando primitive. Primitive acepta como
parámetros el nombre para el recurso, el agente de recurso que lo administra, los parámetros a
su vez que éste precisa así como las diferentes operaciones que debe soportar. En la parte final
además podemos definir el valor para algunas de las características del recurso, como por
ejemplo su estado inicial. Para definir el recurso IP virtual lo hacemos como sigue:
crm(HA_Asterisk)configure# primitive failover-ip
ocf:heartbeat:IPaddr params ip=”150.215.153.235” op monitor
interval=”10s” meta target-role=”Started”
Donde:
• Damos el nombre failover-ip al recurso.
• Indicamos que el agente del recurso fue creado siguiendo el estándar ocf:heartbeat,
y se llama IPaddr (en concreto este agente de recurso es proporcionado por el
propio Heartbeat listo para poder ser usado en la configuración del clúster si lo
estimamos conveniente).
• Como parámetro al agente del recurso añadimos la dirección de red que queremos
establecer como IP virtual: 150.214.153.235. Recordamos que para los dominios
ast1 y ast2 las direcciones de red configuradas fueron 150.214.153.233 y
150.214.153.234, respectivamente.
• Recordamos que un recurso debe poder soportar cuatro operaciones diferentes:
start, stop, status y monitor. Si no especificamos nada para ellas, Heartbeat toma
los valores por defecto de los que dispone. En nuestro caso hemos considerado
necesario concretar el intervalo de tiempo entre la ejecución de dos operaciones
monitor en 10 segundos.
• Al final, mediante la etiqueta meta hemos indicado a Hearbeat que el estado inicial
para el recurso debe ser Started (iniciado). Esto es, cada vez que el clúster es puesto
en marcha el recurso es iniciado.
De forma similar vamos a definir el recurso para el servicio Asterisk, con la
importante salvedad de que Heartbeat no dispone de un script que actúe como agente de
recurso para Asterisk de manera predeterminada. Podemos usar como agente de recurso el script
asterisk de inicio y parada del servicio instalado con Asterisk y que se encuentra en el directorio
/etc/init.d/; en cambio, si observamos el contenido de este fichero, podemos ver que no contiene

una definición para las operaciones monitor y status, necesarias para que Heartbeat pueda
monitorizar el estado del recurso. Así, finalmente hemos hecho uso de un script especial para
Asterisk con las operaciones necesarias definidas, el cual hemos copiado en el directorio
/etc/init.d/ para sustituir al existente (previamente creamos una copia de seguridad del mismo):
ast1:/etc/init.d# mv asterisk asterisk.old
ast1:~# cp /root/asterisk /etc/init.d/asterisk
Para poder hacer uso de este script y las funciones monitor y status que contiene
debemos crear un grupo de usuarios asterisk e instalar la utilidad para el rastreado de redes y
servicios de red nmap:
# groupadd asterisk
# apt-get install nmap
También es necesario eliminar todas las referencias para iniciar el servicio Asterisk de
forma automática cada vez que el sistema es puesto en marcha (ejecutando el script asterisk), ya
que a partir de ahora va a ser Heartbeat el encargado de iniciar y detener este servicio. Para ello
ejecutamos el siguiente comando:
ast1:~# update-rc.d -f asterisk remove
La definición del recurso failover-asterisk queda por tanto de la siguiente forma:
crm(HA_Asterisk)configure# primitive failover-asterisk lsb:asterisk
op monitor interval=”15s” meta target-role=”Started”
A diferencia de los parámetros vistos para el recurso IP virtual, ahora el agente del
recurso es del tipo lsb y la operación monitor es llevada a cabo cada 15 segundos, es decir,
Heartbeat comprueba cada 15 segundos que Asterisk está siendo ejecutado con normalidad:
comprueba primera si existe el proceso; después comprueba si el puerto SIP 5060 se encuentra a
la escucha; para terminar se asegura de que el módulo SIP está cargado.
Con los dos recursos individuales creados, procedemos después a crear el grupo de
recursos al que van a pertenecer. Para crear un grupo de recursos utilizamos la cláusula
group, también en el nivel configure como primitive. Escribimos después de group el nombre
que queremos asignar al grupo así como los nombres de los recursos que pertenecen a él, en el
orden en el que queremos que sean iniciados/detenidos –así creamos la restricción de orden
en la que la IP virtual debe estar disponible antes de que el servicio Asterisk sea iniciado-:
crm(HA_Asterisk)configure# group asterisk-group failover-ip
failover-asterisk
Creando el grupo de recursos asterisk-group también hemos establecido la restricción
de colocación necesaria para nuestro escenario: los recursos IP virtual y asterisk deben
ejecutarse siempre en el mismo nodo. Antes de proseguir configurando la monitorización del
grupo de recursos por parte de Heartbeat vamos a establecer los valores para dos de las
propiedades globales del clúster: no-quorum-policy y stonith-enabled. Con la primera
podemos establecer la política quorum para el clúster, es decir, cómo debe actuar en el caso en
que el problema SplitBrain sea detectado: ignore (ignorar). Mediante la segunda
habilitamos/deshabilitamos el que un dispositivo adicional al clúster (dispositivo stonith) pueda
apagar un reiniciar un nodo que ha experimentado dificultades; como no es el objetivo del
proyecto establecer una configuración excesivamente compleja deshabilitamos esta propiedad

(con el valor false). Para modificar los valores de las propiedades del clúster usamos la palabra
clave property, también en el nivel configure:
crm(HA_Asterisk)configure# property no-quorum-policy=”ignore”
crm(HA_Asterisk)configure# property stonith-enabled=”false”
Durante la configuración del comportamiento del clúster mediante crm siempre tenemos
la posibilidad de verificar que lo estamos haciendo bien y que no existen errores en los
procedimientos y sintaxis. Para ello, podemos escribir verify:
crm(HA_Asterisk)configure# verify
Si la ejecución de verify no devuelve nada, ningún problema ha sido detectado. También
es bastante útil cada cierto tiempo observar de un vistazo el contenido del fichero cib shadow
que estamos creando ejecutando show:
crm(HA_Asterisk)configure# show
Por ejemplo, si ejecutamos show en este punto de la configuración realizada para el
nuestro clúster virtual:
Figura 6.14. Clúster virtual de alta disponibilidad usando Xen, Asterisk y Heartbeat.
Podemos apreciar en la Figura 6.14 como además han sido incluidos en la configuración
del fichero cib shadow los nodos virtuales que forman parte del clúster. Éstos han sido tomados
de forma automática por Pacemaker al ser descritos en el fichero ha.cf. Debemos continuar
entonces con la configuración del clúster ya que aún no hemos especificado ninguna restricción
de localización ni las condiciones bajo las cuales va a tener lugar la migración de los servicios
de un nodo a otro en caso de fallo.
Añadimos ahora la restricción de localización para el grupo de recursos asterisk-
group. Continuando en el nivel configure, usamos la palabra clave location utilizando la
sintaxis siguiente:
location <id> <rsc> {node_pref|rules}
node_pref :: <score>: <node>
rules ::

rule [id_spec] [$role=<role>] <score>: <expression>
[rule [id_spec] [$role=<role>] <score>: <expression> ...]
Como podemos ver en primer lugar debemos escribir un identificador (nombre que
queremos dar a la restricción), por ejemplo run_asterisk_group. Después especificamos el
nombre del recurso para que queremos establecer la restricción, en este caso el nombre del
grupo de recursos (asterisk-group). Para finalizar debemos escribir el nombre del nodo
preferido para la ejecución del recurso junto con una puntuación o detallar una regla para
determinar esta preferencia (las reglas son creadas con una puntuación y una expresión a
evaluar). Si la preferencia es resuelta favorablemente entonces la puntuación es incrementada en
el valor indicado.
Siguiendo esta notación, la restricción de localización para el grupo de recursos
asterisk-group la definimos de la siguiente forma:
crm(HA_Asterisk)configure# location run_asterisk-group asterisk-
group rule 100: #uname eq ast1 rule 90: #uname eq ast2
Vamos a completar para terminar un poco más los detalles para los recursos y grupo de
recursos, así como otras propiedades globales para el clúster. En este último aspecto,
establecemos los valores para las propiedades default-resource-stickiness y default-resource-
failure-stickiness, con las que podemos establecer la adherencia por defecto de los recursos
para ser ejecutados en el nodo actual o por el contrario ser migrados a otro nodo que ofrece unas
condiciones mejores. Asignamos una puntuación positiva en default-resource-stickiness para
premiar la correcta ejecución del grupo en un nodo y una puntuación negativa en default-
resource-failure-stickiness para penalizar la ejecución del grupo en un nodo si han sido
detectado fallos. Esto lo hacemos de nuevo utilizando property:
crm(HA_Asterisk)configure# property default-resource-stickiness=20
crm(HA_Asterisk)configure# property default-resource-failure-
stickiness=-20
De todos modos, y aunque estos valores son por defecto para cualquier recurso definido
en el fichero para el clúster, añadimos estas propiedades con sus valores respectivos de forma
local en el grupo de recursos asterisk-group. Para ello salimos del nivel configure ejecutando
end. Antes, es necesario que salvemos los cambios realizados hasta ahora en la configuración
por lo que ejecutamos el comando commit:
crm(HA_Asterisk)configure# commit
crm(HA_Asterisk)configure# end
Es necesario también comunicar los cambios realizados cuando guardamos al resto de
nodos del clúster. Esto lo logramos con la ejecución del comando commit también, pero en el
nivel cib y escribiendo además el nombre del fichero cib shadow que queremos distribuir:
crm(HA_Asterisk)# cib commit HA_Asterisk
INFO: commited 'HA_Asterisk' shadow CIB to the cluster
Finalmente establecemos los valores para las propiedades resource-stickiness y
resource-failure-stickiness para el grupo de recursos cambiando al nivel resource y haciendo
uso del comando meta de la siguiente forma:

Alta disponibilidad en clusteres asterisk

Alta disponibilidad en clusteres asterisk

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Alta disponibilidad en clusteres asterisk

Similar a Alta disponibilidad en clusteres asterisk (20)

Más de Javier Boquin Rivera

Más de Javier Boquin Rivera (6)

Último

Último (20)

Alta disponibilidad en clusteres asterisk