Alta Disponibilidad en Linux: Heartbeat y Pacemaker

Para conseguir la Alta Diponibilidad de nuestros servicios, se detallará como llevar a cabo la configuración de dos herramientas:

• Heartbeat: Encargado de revisar que cada nodo se halle funcionando. En caso un nodo falle migrará los recursos a otro nodo que también se halle ejecutando el servicio heartbeat
• Pacemaker: Verifica el estado de los recursos (o servicios) que le han sido asignados. En caso algún servicio falle, en caso se halla configurado, Pacemaker puede reiniciarlo.

Mientras heartbeat se encarga que revisar el estado de cada nodo; Pacemaker es el responsable de verificar el estado de los servicios que deseemos sean HA dentro de los nodos.

Configuración

Se tienen dos (2) servidores, cada uno de los cuales está conectado a un mismo dispositivo de almacenamiento externo. Cada uno de los servidores cuenta con un servicio mysqld instalado:

• mysql1 (192.168.190.189)
• mysql2 (192.168.190.190)

En ambos servidores se han instalado los paquetes heartbeat 3.x, pacemaker 1.x, cluster-glue (con sus respectivas dependencias)
El objetivo de la configuración es garantizar la disponibilidad de la base de datos en caso uno de los dos nodos falle.

Editar el archivo /etc/hosts

1. Ejecutamos el siguiente comando para obtener el nombre asignado a cada servidor.
   uname -a
2. Se procede a editar el archivo /etc/hosts en ambos servidores agregando la siguiente línea:
   
   • Servidor mysql1
   192.168.190.190 mysql2
   • Servidor mysql2
   192.168.190.189 mysql1

Editar el archivo /etc/ha.d/ha.cf

En cada uno de los servidores se edita el archivo de configuración del heartbeat

# Logging
debug 1
use_logd false
logfacility daemon

# Misc Options
traditional_compression off
compression bz2
coredumps true

# Communications
udpport 691
# bcast eth0
ucast eth0 192.168.190.X # IP del servidor con el que se comunicará
# reemplazar X con 189 o 190 según corresponda
autojoin none
node mysql1 mysql2

# Thresholds (in seconds)
keepalive 500ms # how long between heartbeats
warntime 5 # late heartbeat warning
deadtime 10 # declare host dead
initdead 30 # first dead time > 2 * deadtime

# Enable Pacemaker
crm yes

Editar el archivo /etc/ha.d/authkeys

Este archivo contiene el algoritmo y la palabra secreta que será usada para establecer comunicación los diversos servidores interconectados por heartbeat.

• Seleccionar el algoritmo que se desea utilizar
  
  auth 1
  crc # Usar solo en desarrollo, no brinda seguridad alguna
  # 2 sha1 SECRET-KEY
  # 3 md5 SECRET-KEY
  
• Únicamente el usuario root debe poder modificar este archivo
  
  chown root.root /etc/ha.d/authkeys
  chmod 600 /etc/ha.d/authkeys

Iniciar Heartbeat

Para iniciar Heartbeat ejecutar el siguiente comando en cada uno de los nodos:

service heartbeat start

Configurar Pacemaker

Para configurar el Pacemaker, se hará uso de la herramienta crm.
Para verificar que nuestra configuración ha sido la adecuada y los nodos pueden verse entre sí, ejecutaremos la opción:

vampii@scatha:~$ crm node show

La salida de este comando debería de ser similar a:

mysql1(3bda1ae0-a614-45f1-8d6c-3c9336103e74): normal
mysql2(0d00d69e-a6b6-4d11-9ecf-f1174932d8fe): normal

Procederemos a verificar la lista de clases y proveedores:

vampii@scatha:~$ crm ra classes

La salida sería similar a:

heartbeat

lsb

ocf / heartbeat pacemaker <- Este es el valor que nos interesa, clase ocf y proveedor heartbeat stonith

Para conocer el listado de recursos que pacemaker puede administrar ejecutamos:

vampii@scatha:~$ crm ra list ocf

Dentro de la salida mostrada, los valores que para este caso nos interesarían son:

Filesystem: Recurso que permite montar y desmontar automáticamente unidades de disco.
IPaddr: Recurso que permite mover una misma IP virtual entre varios nodos.
mysql: Recurso encargado de iniciar / detener el servicio mysqld.

Para conocer el listado de parámetros que recibe cada uno de los recursos, es necesario ejecutar lo siguiente:

vampii@scatha:~$ crm ra meta

Procedemos a configurar cada uno de los servicios:

vampii@scatha:~$ crm configure primitive :: [params = [=...]]

Ejemplo:

vampii@scatha:~$crm configure primitive Mysql-rsc ocf:heartbeat:mysql \
params datadir=/mnt/mysql log=/mnt/log/mysqld.log socket=/tmp/mysql.sock binary="/usr/bin/mysqld_safe"

Configuramos el tiempo de monitoreo para cada recurso

vampii@scatha:~$ crm configure monitor [:]

Ejemplo:

vampii@scatha:~$ crm configure monitor Mysql-rsc 10s:30s

Es posible modificar los valore singresados hasta el momento (o agregar nuevos valores haciendo uso del comando:

vampii@scatha:~$ crm configure edit

En este punto verificaremos que los valores relacionados a la configuración de los recursos sean similares a:

primitive Filesystem-rsc ocf:heartbeat:Filesystem \
params device="/dev/sdb1" directory="/mnt" fstype="ext3" \
op monitor interval="20s" timeout="40s" \
op start interval="0s" timeout="100s" \
op stop interval="0s" timeout="100s"
primitive IPaddr-rsc ocf:heartbeat:IPaddr \
params ip="192.168.190.179" \
op monitor interval="5s" timeout="20s" \
op start interval="0s" timeout="90s" \
op stop interval="0s" timeout="100s"
primitive Mysql-rsc ocf:heartbeat:mysql \
params datadir="/mnt/mysql" pid="/var/run/mysqld/mysqld.pid" log="/mnt/log/mysqld.log" socket="/tmp/mysql.sock" binary="/usr/bin/mysqld_safe" \
op monitor interval="10s" timeout="30s" \
op start interval="0s" timeout="120s" \
op stop interval="0s" timeout="120s" \
meta target-role="Started"

Procedemos a definir un orden en el que se iniciarán los recursos:

order score-type: [:] [:]

Ejemplo:

$ crm configure order order-1 INFINITY: Filesystem-rsc Mysql-rsc
$ crm configure order order-2 INFINITY: IPaddr-rsc Mysql-rsc

Nota: Un score de tipo INFINITY significa el orden definido es de cumplimiento obligatorio.
El siguiente paso consiste en indicar en qué nodos han de iniciarse los recursos.

colocation : [:] [:]

Ejemplo:

vampii@scatha:~$ crm configure colocation colocation-1 INFINITY: Mysql-rsc Filesystem-rsc
vampii@scatha:~$ crm configure colocation colocation-2 INFINITY: Mysql-rsc IPaddr-rsc

Nota: En este caso un score de tipo INFINITY significa que ambos recursos especificados por cada colocation deben de ser iniciados en un mismo nodo. Lo que se busca es que tanto la dirección IP virtual, el montado de la unidad externa que contendrá los valores de la base da datos y el servicio mysqld sean iniciados en un mismo nodo, en caso el nodo fallara, el conjunto de recursos serían migrados al otro nodo.
Configuraremos el valor de la propiedad start-failure-is-fatal en false. Este paso es efectuado para que, en caso de error el servicio mysqld se detuviera, este sea reiniciado automáticamente por el Pacemaker en lugar de ser migrado al otro nodo. Si la cantidad de fallos alcanzado por este recurso fuera igual al valor definido en migration-threshold, el conjunto de recursos serán migrados a otro nodo.

vampii@scatha:~$ crm configure property start-failure-is-fatal=false
vampii@scatha:~$ crm configure property stonith-enabled=false

Finalmente para guardar la configuración es necesario ejecutar

vampii@scatha:~$ crm configure commit

Nota: La configuración serán replicados entre los diferentes nodos de forma automática.
Para guardar una copia de la configuración efectuada puede utilizarse el comando:

vampii@scatha:~$ cibadmin --query > configuracion.xml

Para restaurarlo, puede hacerse uso de:

vampii@scatha:~$ cibadmin --replace --xml-file configuracion.xml

Para mayor información pueden consultar el manual de Pacemaker: Manual de Pacemaker
 

Tomado de: http://denniscm20.blogspot.com/2010/04/alta-disponibilidad-en-linux-heartbeat.html