16 de abril de 2010

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:

$ 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:

$ 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:

$ 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:

$ crm ra meta <nombre_del_recurso>

Procedemos a configurar cada uno de los servicios:

$ crm configure primitive <nombre del recurso> <clase>:<proveedor>:<tipo> [params <parámetro>=<valor> [<parámetro>=<valor>...]]

Ejemplo:

$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

$ crm configure monitor <interval>[:<timeout>]

Ejemplo:

$ crm configure monitor Mysql-rsc 10s:30s

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

$ 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: <first-rsc>[:<action>] <then-rsc>[:<action>]

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 <id> <score>: <rsc>[:<role>] <rsc>[:<role>]

Ejemplo:

$ crm configure colocation colocation-1 INFINITY: Mysql-rsc Filesystem-rsc
$ 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.

$ crm configure property start-failure-is-fatal=false
$ crm configure property stonith-enabled=false

Finalmente para guardar la configuración es necesario ejecutar

$ 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:

$ cibadmin --query > configuracion.xml

Para restaurarlo, puede hacerse uso de:

$ cibadmin --replace --xml-file configuracion.xml

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

47 comentarios:

  1. hola Dennis, me gusto el tema, por lo cual estoy interesado en como instalar el paquete de heartbeat en una computadora con ubuntu ultima version, corriendo en una maquina virtual vmware workstation, te agradeceria me indicaras como podria hacer funcionar en 2 servidores en HA.

    gracias de nuevo por el tema en cuestion.

    Saludos

    ResponderEliminar
  2. Hola rol0, los pasos para instalar el heartbeat en una máquina con Ubuntu son los mismos a los indicados.

    En caso solo desearas activar únicamente el Heartbeat; mas no el Pacemaker, es necesario setear el parámetro "crm" con el valor "no" dentro del archivo de configuración /etc/ha.d/ha.cf.

    Saludos

    ResponderEliminar
  3. Dennis, estoy muy agradecido por tu respuesta, hare lo que me comentas y pondre un resultado si no te impota, muchas gracias por tu ayuda.

    Un saludo

    ResponderEliminar
  4. hola, tu blog me sirvio de gran ayuda. Pero yo tengo que migrar apache2 de un nodo a otro en caso de que falle, como seria la configuracion de pacemaker?

    ResponderEliminar
  5. Hola,

    Para ello, luego de ejecutar "crm ra list ocf", el recurso que debes configurar es el que tiene como nombre "apache".

    Verifica su lista de parámetros con el comando "crm ra meta apache".

    A partir de ese punto, puedes seguir los pasos indicados en el artículo.

    Saludos

    ResponderEliminar
  6. Hola Dennis, saludos desde caracas, Vzla.
    Estoy analizando algunas soluciones de HA para implementarlas en la empresa en la cual laboro, y me gustaría que me asesoraras con esto.

    Deseo implementar HA activo-pasivo para un par de servidores que incluyen los servicios de mysql y apache, por los momentos. Ambos servicios quiero configurarlos para que, en caso de fallar apache2 o mysql, o ambos simultaneamente en mi servidor primario, se pasen en forma automatica al servidor #2.

    Haz tenido experiencia con este tipo de Ha activo-pasivo?. Ha esperas de tus prontos comentarios.

    ResponderEliminar
  7. Hola modelado,

    Heartbeat + Pacemaker se ajusta bien a la solución que deseas implementar. Adicionalmente podrías hacer uso de dr:bd para manejar un raid 1 de MySQL a nivel de red. De esa forma si un nodo falla contarás con una réplica sincronizada de MySQL en el otro servidor.

    Para configurar el apache, debes ejecutar el comando "crm ra meta apache" para obtener los parámetros que requieres configurar en el Pacemaker para monitorear el estado del servicio del Apache.

    Ejecutarías la siguiente línea (reemplazando los parámetros): $ crm configure primitive Apache-rsc ocf:heartbeat:apache [params = [=...]]

    Respecto al orden de inicio de los servicios, tendrías que agregar la siguiente línea:
    $ crm configure order order-3 INFINITY: Mysql-rsc Apache-rsc

    Con ello indicas que el Apache inicie después del MySQL

    Por último agrega la siguiente línea para forzar a que el Apache y MySQL levanten en el mismo nodo:

    $ crm configure colocation colocation-3 INFINITY: Mysql-rsc Apache-rsc

    Nota: Es importante complementes los pasos mencionados con el resto del contenido del artículo.

    Nota personal: Yo optaría por tener únicamente el MySQL corriendo en un nodo por separado bajo el esquema de alta disponibilidad Activo - Pasivo. Podrías contar con dos nodos ejecutando Apache funcionando de forma simultánea.

    Saludos,

    ResponderEliminar
  8. Hola Denis
    estoy haciendo el diseño de un cluster de pero me surge la siguiente duda: con heartbeat o pacemaker yo puedo saber que nodo (master o eslcavo) fue el que dejo de funcionar y a su vez arrancar el de reserva con la config del master o esclavo en dependencia de cual se haya caido??

    ResponderEliminar
  9. Hola,

    La idea de hacer uso de Heartbeat + Pacemaker es que, al instante de tiempo en el que el sistema detecte que uno de los nodos involucrados deja de responder o el servicio se detecte como caído, automáticamente el tráfico sea redirigido al nodo de respaldo (ello implica que los servicios en este segundo nodo sean iniciados de forma automática).

    Para saber el estado de cada uno de los nodos y servicios monitoreados por el Heartbeat + Pacemaker se cuenta con un aplicativo llamado crm_mon.

    ResponderEliminar
  10. Anja y en el caso de que quiera arrancar el nodo de respaldo con una configuración X entre otras que tenga como lo podría hacer??

    ResponderEliminar
  11. Hola,

    Por ejemplo, la configuración presentada en el artículo permite contar con dos nodos que funcionen como servidores MySQL cuyo directorio de datos se hallará en un tercer equipo. Uno de los nodos MySQL estará funcionando en forma activa (recibiendo consultas); mientras que el otro funcionará en modo pasivo (únicamente el equpo se hallará prendido; mas el MySQL server no se estará ejecutando). Si el nodo activo por algún motivo fallara (ya sea por falla a nivel del nodo o por falla a nivel del servicio), el equipo dejará de funcionar en modo activo y pasará a un modo pasivo mientras que el equipo en modo pasivo pasará a modo activo.

    La transición de activo a pasivo y de pasivo a activo es completamente automática (no requiere intervención alguna) en caso tanto el Heartbeat como el Pacemaker hallan sido configurados de forma adecuada.

    Para conocer el listado de servicios soportados por Pacemaker, bastará con ejecutar el siguiente comando en cualquiera de los nodos que tengan el Pacemaker instalado: crm ra list ocf

    Para una explicación más detallada relacionada a configuraciones diferentes a las presentadas en el ejemplo, puedes visitar el enlace al final del artículo: "Manual de Pacemaker"

    Saludos,

    ResponderEliminar
  12. Muy interesante todo lo que se menciona.
    Mis felicitaciones a todos por participar y aportar con preguntas y respuestas por que de eso todos aprendemos.

    Una consulta a cualquiera que sepa y me pueda responder (URGENTE porfavor !!!!:

    Un programador que usa la base de datos "firebird" (que no esta preparado para cluster) y Apache (como medio de Interfaz para el cliente de la base de datos) me pide que arme un cluster de tal modo que si cae un nodo, se pueda seguir trabajando normalmente con el otro nodo, de tal modo que los clientes que estan con su navegador accediendo a la base de datos no sepan que algo grave ha ocurrido y la base de datos siga funcinando normalmente

    Mis conocimientos: Centos, Heartbeat basico y drbd(con esto ya he logrado hacerlo funcionar)
    Mi ignorancia: crm y otros

    Preguntas:
    1- ¿se puede resolver esto?
    2- Si la respuesta es si, ¿qué puntos o temas debo tener en cuenta para lograr el objetivo?
    3- Cualquier apreciación, consulta o lo que fuere para ayudarme será bien apreciado.

    Gracias a todos
    Saludos

    ResponderEliminar
  13. Agrego un comentario más sobre mis preguntas anteriomente descritas:

    Mi preocupación principal consiste en que "Firebird" por ser una aplicación de base de datos no preparada para trabajar en cluster, trae con sigo estos inconvenientes:

    1- En un cluster activo/activo, donde corren ambos servicios: apache y firebird en los 2 nodos, accediendo ambos nodos por nfs a una data en común, se estrellan los 2 firebirds al acceder a la data, por que no se diseño para usarse de esa forma.

    2- En un cluster activo/pasivo, los servicios firebird y apache si podrían correr sin problemas, pero cuando caiga el nodo activo, el pasivo debería de continuar con las transacciones pendientes que quedaron despues de la caida del nodo, de no ser así, dará como resultado una base de datos dañada con transacciones pendientes a medio hacer, y eso no se desea que ocurra.

    Te agradeceré Dennis o a cualquiera que pueda ayudarme, si pueden facilitar la respuesta ó directivas que debo tener en cuenta para lograr mi proposito de solución.

    Gracias de antemano
    Saludos

    ResponderEliminar
  14. Hola Cesar,

    Algunas aclaraciones sobre tu configuración:
    Tanto para manejar la replicación en Firebird (activo/activo o activo/pasivo) es necesario que hagas uso de una herramienta de replicación, en el siguiente enlace te presentan algunas alternativas: http://www.firebirdfaq.org/faq249/

    Como mencionas en tu comentario anterior, es posible hacer uso de una replicación activa/pasiva haciendo uso de drbd para replicar la partición de datos.

    Nota cuando indicas: "las transacciones pendientes que quedaron después de la caída del nodo", debes de considerar que las transacciones que se estuvieran ejecutando al momento en que el nodo cae se perderán. La data a la que es posible continuar accediendo es aquella que ya hubiera sido "commiteada" y hubiera sido replicada.

    Si haces uso de drbd necesitaras un servicio que levante el firebird del nodo pasivo al caer el nodo activo (recuerda que en drbd el nodo pasivo no puede acceder al bloque replicado por drbd). Heartbeat brinda la opción de migrar direcciones IP en caso el nodo activo falle; pero tu requieres, como acabo de mencionar, que no solo se migre la dirección IP de la base de datos; sino que también se inicie el servicio (para ello requieres Pacemaker o una herramienta similar; la opción crm de Heartbeat es la encargada de habilitar el Pacemaker).

    Me parece Pacemaker no soporta el servicio de Firebird de forma predefinida; pero ello no implica que no puedas crear tu script que lo soporte. Mayor información:
    http://www.clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Pacemaker_Explained/s-resource-supported.html
    http://www.clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Pacemaker_Explained/ap-ocf.html
    http://www.clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Pacemaker_Explained/ap-lsb.html

    Saludos,

    ResponderEliminar
  15. Muchas gracias Dennis por responderme. valoro mucho tu ayuda. Y aprovecho tu gentileza para decirte cuanto sigue:

    Comentarios:
    ------------
    1- Se que Pacemaker es más avanzado que Heartbeat (debería conocerlo y practicarlo)
    2- Yo ya he hecho funcionar un cluster modo activo/pasivo con Heartbeat, drbd e ipvsadm levantando cualquier servicio del linux configurado con Heartbeat apropiadamente incluyendo la IP Virtual al que sirve el cluster, en una practica personal usé samba para probar el cluster

    Lo malo de mi practica llevandolo a la producción es que ya sea el servicio samba ó firebird levantado, es que las transacciones pendientes se perderán cuando el nodo activo cae, por que el pasivo pasará a activo iniciando los servicios que tenga el cluster pre-configurados, "pero no le dará una continuidad a las transacciones pendientes", por lo tanto éstas se perderán.

    3- En los links que me enviaste no encontré una respuesta concreta a mi duda (o al menos que pueda entender)

    Consulta:
    ---------
    ¿Hay algún modo de hacer que las transacciones pendientes que quedaron en el nodo muerto continuen en el nuevo nodo que se levanta de tal modo que los clientes no se den cuenta?

    Desde ya muchas gracias por tu atención, tu tiempo e información

    Te Agradeceré cualquier pista que me ayude a resolver mi duda tanto para Samba como Firebird

    Saludos Cordiales y mucho éxito

    ResponderEliminar
  16. Nota adicional a lo anteriormente comentado:
    --------------------------------------------
    Dennis, sobre la herramienta de replicación para Firebird que comentaste más arriba, no creo que sea útil, por que se desea un cluster de misión critica, es decir no parar de trabajar bajo ningún concepto, y dicha herramienta realiza replicas periodicas, por lo tanto esta descartada como opción viable. Por ello encuentro imperativo el uso de drbd como una parte de la solución, ya que éste si sincronizará siempre la data en tiempo real.

    Saludos Cordiales

    ResponderEliminar
  17. Hola Cesar,

    Con las herramientas que mencionadas (drbd, heartbeat, ipvsadm) no es posible hacer una replicación de datos a nivel de ram. En el momento en que el servidor activo caiga se pierden los datos que en ese momento se hallen en memoria y no hallan sido commiteados en disco (como es el caso de las transacciones pendientes).

    Por el momento, ya que usas firebird se me ocurre hagas uso de transacciones (en caso no las estuvieras utilizando) por si en caso se de una caída del sistema los datos almacenados sigan manteniendo su integridad referencial.

    Dos puntos adicionales que debes de considerar (quizá ya los estés considerando):
    - Si estás usando el modo de replicación síncrona, a mayor distancia a la que se hallen los servidores el usuario final percibirá una mayor demora en el servicio ya que el DRBD no soltará la transacción hasta que halla sido escrito en el disco de ambos servidores.
    - En caso la transacción efectuada halla sido la responsable de la caída del servidor, el hecho de buscar como replicarla podría poner en riesgo la disponibilidad de tu servidor de respaldo.

    Por el momento no he hallado aplicación que permita replicar la información contenida en memoria; sin embargo, seguiré revisando si hay alternativas para llevar a cabo una replicación de datos a nivel de ram.

    Saludos,

    ResponderEliminar
  18. Hola porfavor ayuda. he configurado todo bien . En el nodo activo extraigo el enlace al router y se activa el nodo secuntario pero al momento de regresar el enlace al nodo primario ya no regresa al estado normal. Tambien resulta que estando trabajando el nodo secundario, si le quito el ennlace simplemente ambos nodos ya no trabajan. Donde le digo que cuando se caiga el enlace se pase al otro nodo y que cuando regrese el enlace, se vuelva al estado normal.. Gracias espero su respuesta...

    ResponderEliminar
  19. Hola Misael,

    Para ello podrías usar la variable resource-stickiness.

    Agregar la siguiente línea usando la opción "crm configure edit" luego de las entradas que hacen referencia a "property".

    rsc_defaults $id="rsc-options" resource-stickiness=score

    El score debe de ser un valor bajo.

    Saludos,

    ResponderEliminar
  20. Hola Dennis,
    He probado la configuración que has dejado y al momento de aplicarlo funciono bastante bien, te agradezco el tutorial que has hecho.
    Ahora bien quisiera hacerte una pregunta a cerca de un tema bastante delicado y poco abarcado, pienso que como manejas información a cerca de Heartbeat, puedes haberlo implementado en alguna caso.

    La pregunta principal es a cerca del fenced, dentro del cluster para evitar split-brain, se que heartbeat maneja stonith pero como lo maneja?? como lo puedo implementar en una plataforma virtual en este caso VMWare con ESX 4.0 ?? alguna experiencia al respecto de como hacer una propia libreria OCF

    Saludos y desde ya muchas gracias por tu respuesta

    ResponderEliminar
  21. Hola esmorfeus,

    Por el lado de stonith, no he tenido mucha experiencia configurándolo. Al menos en mi caso, el hardware que me hallaba usando no era compatible.

    Es probable que los pasos que seguí aquella vez te sean útiles:

    1. Listar los drivers soportados: $ stonith -L
    2. Verificar los parámetros que requiere el driver elegido: $ stonith -t [driver_elegido] -n
    3. Crear un archivo xml temporal que contiene la configuración de un recurso con clase stonith (la estructura la puedes revisar en el enlace líneas abajo: Configurar usando un xml)

    Nota: Para este punto también podría hacerse uso del comando $ crm configure primitive [...]

    4. Crear un clon del recurso si el dispositivo soportará más de un nodo.
    5. Cargar el contenido del xml: $ cibadmin -C -o resources --xml-file [archivo.xml]

    Más información:
    - Configurar usando un xml: http://www.clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Pacemaker_Explained/s-stonith-configure.html
    - Configurar a través del comando crm: http://www.clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Clusters_from_Scratch/ch09s03.html

    Para implementar la solución en una plataforma virtual, te recomendaría contar con dos hosts físicos. Cada par de servidores virtuales deben de haber sido desplegados en diferentes host físicos con el objetivo de que si fallará el hardware, el respaldo podría seguir funcionando.

    Sobre la creación de scripts OCF's; podrías revisar el siguiente enlace: http://www.clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Pacemaker_Explained/ap-ocf.html (a mi me resultó útil cuando requerí escribir una)

    Saludos,

    ResponderEliminar
  22. Dennis, muchas gracias por tu respuesta, te cuento que invente un agente de fenced el cual esta escrito y apunta a vigilar la conectividad. Se clona y corre en ambas maquinas como marcapasos.
    Leere lo que me indicas para poder quizas potenciar el invento.

    Sl2

    PD: si quieres me agregas al gtalk o msn, ocupa mi nickname, para compartir conocimientos y buena onda.

    ResponderEliminar
  23. Saludos, muy buen post, mi situación es la siguiente:
    Tengo 4 recursos en nodos diferentes cada uno y un nodo de reserva. cuales son las reglas que debo definir para que no existan más de un recurso ejecutándose en un nodo??
    Espero que me puedan ayudar.
    Gracias de antemano.

    ResponderEliminar
  24. Hola Dennis, antes de nada te felicito por tu excelente trabajo, lo explicas todo muy bien y tu aporte me ha sido de gran ayuda para mi actividad.

    Me gustaría comentarte que actualmetne estoy atrancado en un error de conexión cuando ejecuto crm la salida es la siguiente:

    # crm
    crm(live)# cib new HA_ApacheDRBD
    Signon to CIB failed: connection failed


    He buscado el log de HA pero no existe el archivo /var/log/ha-log

    Es la primera vez que me meto en este tema que me interesa mucho.

    Saludos

    ResponderEliminar
  25. Hola Bone,

    Para hacer uso de 4 nodos, es debes de usar la entrada bcast del Heartbeat, en lugar de la ucast.

    Asimismo, revisa el comando del Pacemaker: "crm configure colocation"

    Saludos,

    ResponderEliminar
  26. Hola Francisco,

    En caso no cuentes con el /var/log/ha-log; has verificado el archivo /var/log/messages (en caso no contar con el log del Heartbeat, los errores son almacenados en el archivo messages) ?

    Por si acaso, revisa haber habilitado "crm yes" en el archivo de configuración del heartbeat de cada nodo.

    Saludos,

    ResponderEliminar
  27. Hola Deniis Excelente trabajo.

    Tengo configurado dos Debian Squeeze funcionando correctamente siguiendo tu guia, los recursos de FileSystem y IPaddr Sin embargo el recurso de "postfix" no logra caminar te anexo algunos logs para ver si puedes ayudarme

    # crm ra list ocf
    postfix
    ....
    .....

    Como te darás cuenta efectivamente el postfix esta como recurso sin embargo observa esto.

    ~# crm ra meta postfix
    lrmadmin[27985]: 2011/05/02_19:18:57 ERROR: lrm_get_rsc_type_metadata(578): got a return code HA_FAIL from a reply message of rmetadata with function get_ret_from_msg.
    ERROR: ocf:heartbeat:postfix: could not parse meta-data:

    No obstante yo lo configure según ejemplos pero al preguntar el status
    #crm status
    postfix (ocf::heartbeat:postfix): Started sblin12-mda2 (unmanaged) FAILED

    Nuevamente Gracias.
    Victor Oñate

    ResponderEliminar
  28. Hola Dennis,

    Primero te doy las gracias por tu post, me ha servido mucho. Estoy implementando un cluster basado en pacemaker con corosync utilizando los paquetes que me proporciona RHEL6, he tenido algunos problemas menos mal la documentacion de pacemaker no esta nada mal. Mi configuracion consiste en un cluster Activo/Pasivo, utilizo 2 servers virtuales usando vmware como hypervisor utilizo una utilidad de vmware para tener un disco en raid 1 virtual practicamente lo mismo que hace drbd. El cluster es para un cms bajo una infrastructura lamp. Como tengo resuelto el raid1 solo me queda el montaje de la particion y configurar los servicios de apache y mysql.

    Clases:

    Filesystem -> ocf:heartbeat:Filesystem
    IP Float -> ocf:heartbeat:IPAddr
    MYSQL -> ocf:heartbeat:mysql

    Hasta aqui no hay problemas, el problema viene con el servicio apache, en la clase "heartbeat" existe un meta apache actualmente tengo algunos problemas pienso que los debo resolver pronto, por otra parte tmb he probado usar la clase "lsb" para usar el servicio httpd he comprobado que sea compatible con el test que viene en el manual de pacemaker y va pero hay algunos errores tambien.

    Ahora esta analizando un poco la estructura del cluster lei un respuesta tuya donde TU DICES:

    "Nota personal: Yo optaría por tener únicamente el MySQL corriendo en un nodo por separado bajo el esquema de alta disponibilidad Activo - Pasivo. Podrías contar con dos nodos ejecutando Apache funcionando de forma simultánea."

    Corrigeme por favor si me equivoco o si estoy hablando piedras, ahora como la data que usa apache esta en el partion sincronizada bajo un esquema Activo/Pasivo, apache no podria iniciarse en el server Pasivo ya que daria un error porque no encontraria el DirectoryRoot ya que en el pasivo la particion no esta montada. Te dejo mi configuracion no es perfecta y actualmente tiene el error de apache.

    http://pastebin.com/ue673P74

    Talves tengas alguna recomendacion correccion o comentario, te estare muy agradecido.

    Un saludo coordial y gracias nuevamente.

    Kenny.

    ResponderEliminar
  29. Hola Dennis,

    He estado viendo un poco lsb:httpd y esta configuracion me funciona al parecer bien, la dejo talves le ayude a alguien.

    http://pastebin.com/q8TMqQTJ

    Un saludo coordial.

    Kenny.

    ResponderEliminar
  30. Actualizacion:

    Logre configurar ocf:heartbeat:apache tenia que habilitar esto en el file httpd.conf para el monitoreo era claro en el log de corosync



    SetHandler server-status
    Order deny,allow
    # Deny from all
    Allow from localhost


    Esta es la configuracion se podria decir funcionante he ajustado los tiempos de monitoreo tambien.

    http://pastebin.com/MUb6sRhT

    PD: Solo me falta hacer que cuando un server reingrese al cluster los recursos no vengan migrados a este, hay alguien vivo por aca? es broma saludos.

    K.

    ResponderEliminar
  31. Hola Kenny,

    Es bueno saber que este breve post te haya ayudado. Sobre tu última duda relacionada a "evitar que un recurso sea migrado cuando un nodo reingrese al cluster" puedes hacer uso del parámetro resource-stickiness.

    En el siguiente enlace hay un ejemplo de su uso:

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

    Saludos,

    Dennis

    ResponderEliminar
  32. Hola Dennis, mi caso es el siguiente, deseo implementar HA para un servidor de telefonia, exactamente es elastix, quisiera saber si me recomiendas usar heartbeat con pacemaker?

    El cluster debera ser de 3 nodos.

    Gracias de antemano.

    ResponderEliminar
  33. con dr:bd padría manejar un raid 5 de MySQL a nivel de red?????

    ResponderEliminar
  34. estoy tratando de instalar heartbeat sin exito podrias decirme por donde comenzar conozco poco de linux tengo un centos recien instalado agradezco tu apoyo

    ResponderEliminar
  35. buen dia muy bueno tu manual,

    me gustaría saber como podria configurar el pacemaker para manejar un servicio de pgpool el cual es levantado por un script instale el paquete pero me da error al tratar de iniciar el demonio, actualmente realize la configuracion solo con el heartbeat pero al iniciar el domonio no levanta la interfaz vip y al revisar el log no me indica si en algun momento intenta levantarla no se cual podria ser el error.

    ResponderEliminar
  36. cual es tu recomendación para hacer un sistema de DNS en alta disponibilidad.

    ResponderEliminar
  37. Hola, primero felicitarte por tu blog, tengo una pregunta, tengo un montaje de dos bases de datos en debian, y cada que reinicio el corosync los recursos migran sin ningún problema al siguiente nodo pero mi problema es que por alguna razon el recurso es apagado en el nodo en el que estaba, hay alguna forma de que el recurso sea ofrecido por los dos nodos? o que al menos no se apague en el nodo en el que estaba...

    ResponderEliminar
  38. Hola Eddo,

    Para conseguir un esquema de alta disponibilidad podrías hacer uso de dos servidores DNS con Heartbeat.

    Saludos,

    Dennis

    ResponderEliminar
  39. Hola Marna,

    Para tu caso, estás utilizando Corosync en combinación con Pacemaker?

    Saludos,

    Dennis

    ResponderEliminar
  40. Hola me sale el siguiente errro: a que se debe tengo montado una IP virtual y Apache

    root@Nodetwo:~# crm status
    ============
    Last updated: Fri Dec 14 21:25:01 2012
    Last change: Fri Dec 14 20:25:30 2012 via cibadmin on Nodeone
    Stack: openais
    Current DC: Nodethree - partition with quorum
    Version: 1.1.6-9971ebba4494012a93c03b40a2c58ec0eb60f50c
    3 Nodes configured, 3 expected votes
    2 Resources configured.
    ============

    Online: [ Nodetwo Nodeone Nodethree ]

    IP-V (ocf::heartbeat:IPaddr): Started Nodethree
    Apache (ocf::heartbeat:apache): Started Nodethree

    Failed actions:
    Apache_monitor_0 (node=Nodethree, call=3, rc=-2, status=Timed Out): unknown exec error
    Apache_monitor_0 (node=Nodeone, call=3, rc=-2, status=Timed Out): unknown exec error
    root@Nodetwo:~#

    Si fueras tan amable de darme una pista te lo agradecería muchísimo.

    ResponderEliminar
  41. Hola otra vez. Estoy utilizando Pacemaker y Corosync

    ResponderEliminar
  42. ola amigo buen dia, una pregunta...
    no es neseasario modificar el archivo "HARESOURCES"
    O PODRIAS EXPLICARME POR QUE NO LO TOCAS EN LA CONFIGURACION....

    ResponderEliminar
    Respuestas
    1. Hola Anónimo,

      El archivo haresources no se utiliza en configuraciones de Pacemaker + Heartbeat. Pacemaker hace uso de otros archivos que son automáticamente sincronizados entre todos los nodos dentro del clúster.

      Saludos,

      Dennis

      Eliminar
  43. Hola Buenos dia. Tengo una duda los IP que usastes son los IP de la maquina o los IP de la red

    ResponderEliminar
  44. Hola Dennis,

    Esta configuración podría funcionar con Elastix? Necesito hacer un HA Cluster con Elastix y hardware E1 Digium. Podría configurar todo con Corosync + Pacemaker?

    Saludos...

    ResponderEliminar
  45. TOCAYO DENNIS, TENGO 2 NODOS CON HEARTBEAT Y PUSE QUE EL HEARTBEAT INICIE EL APACHE(HTTPD) EN LOS 2 NODOS PERO SOLO SE LEVANTA EL HEARTBEAT MAS NO EL HTTPD, QUE PODRA PASAR AMIGO ENNIS

    ResponderEliminar
  46. He estado haciendo pruebas con Heartbeat y lo que note es que cuando se cae el primer nodo, al levantarlo se pierde la comunicación con la IP virtual por 18 segundos. ¿Alguna recomendación?

    ResponderEliminar