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.
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
- Ejecutamos el siguiente comando para obtener el nombre asignado a cada servidor. uname -a
- Se procede a editar el archivo /etc/hosts en ambos servidores agregando la siguiente línea:
- Servidor mysql1
- Servidor mysql2
192.168.190.190 mysql2192.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
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:
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:
La salida de este comando debería de ser similar a:
mysql2(0d00d69e-a6b6-4d11-9ecf-f1174932d8fe): normal
Procederemos a verificar la lista de clases y proveedores:
La salida sería similar a:
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:
Dentro de la salida mostrada, los valores que para este caso nos interesarían son:
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:
Procedemos a configurar cada uno de los servicios:
Ejemplo:
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
Ejemplo:
Es posible modificar los valore singresados hasta el momento (o agregar nuevos valores haciendo uso del comando:
En este punto verificaremos que los valores relacionados a la configuración de los recursos sean similares a:
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:
Ejemplo:
$ 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.
Ejemplo:
$ 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 stonith-enabled=false
Finalmente para guardar la configuración es necesario ejecutar
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:
Para restaurarlo, puede hacerse uso de:
Para mayor información pueden consultar el manual de Pacemaker: Manual de Pacemaker
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.
ResponderEliminargracias de nuevo por el tema en cuestion.
Saludos
Hola rol0, los pasos para instalar el heartbeat en una máquina con Ubuntu son los mismos a los indicados.
ResponderEliminarEn 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
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.
ResponderEliminarUn saludo
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?
ResponderEliminarHola,
ResponderEliminarPara 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
Hola Dennis, saludos desde caracas, Vzla.
ResponderEliminarEstoy 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.
Hola modelado,
ResponderEliminarHeartbeat + 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,
Hola Denis
ResponderEliminarestoy 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??
Hola,
ResponderEliminarLa 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.
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??
ResponderEliminarHola,
ResponderEliminarPor 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,
Muy interesante todo lo que se menciona.
ResponderEliminarMis 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
Agrego un comentario más sobre mis preguntas anteriomente descritas:
ResponderEliminarMi 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
Hola Cesar,
ResponderEliminarAlgunas 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,
Muchas gracias Dennis por responderme. valoro mucho tu ayuda. Y aprovecho tu gentileza para decirte cuanto sigue:
ResponderEliminarComentarios:
------------
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
Nota adicional a lo anteriormente comentado:
ResponderEliminar--------------------------------------------
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
Hola Cesar,
ResponderEliminarCon 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,
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...
ResponderEliminarHola Misael,
ResponderEliminarPara 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,
Hola Dennis,
ResponderEliminarHe 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
Hola esmorfeus,
ResponderEliminarPor 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,
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.
ResponderEliminarLeere 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.
Saludos, muy buen post, mi situación es la siguiente:
ResponderEliminarTengo 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.
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.
ResponderEliminarMe 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
Hola Bone,
ResponderEliminarPara 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,
Hola Francisco,
ResponderEliminarEn 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,
Hola Deniis Excelente trabajo.
ResponderEliminarTengo 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
Hola Dennis,
ResponderEliminarPrimero 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.
Hola Dennis,
ResponderEliminarHe 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.
Actualizacion:
ResponderEliminarLogre 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.
Hola Kenny,
ResponderEliminarEs 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
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?
ResponderEliminarEl cluster debera ser de 3 nodos.
Gracias de antemano.
con dr:bd padría manejar un raid 5 de MySQL a nivel de red?????
ResponderEliminarestoy tratando de instalar heartbeat sin exito podrias decirme por donde comenzar conozco poco de linux tengo un centos recien instalado agradezco tu apoyo
ResponderEliminarbuen dia muy bueno tu manual,
ResponderEliminarme 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.
cual es tu recomendación para hacer un sistema de DNS en alta disponibilidad.
ResponderEliminarHola, 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...
ResponderEliminarHola Eddo,
ResponderEliminarPara conseguir un esquema de alta disponibilidad podrías hacer uso de dos servidores DNS con Heartbeat.
Saludos,
Dennis
Hola Marna,
ResponderEliminarPara tu caso, estás utilizando Corosync en combinación con Pacemaker?
Saludos,
Dennis
Hola me sale el siguiente errro: a que se debe tengo montado una IP virtual y Apache
ResponderEliminarroot@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.
Hola otra vez. Estoy utilizando Pacemaker y Corosync
ResponderEliminarola amigo buen dia, una pregunta...
ResponderEliminarno es neseasario modificar el archivo "HARESOURCES"
O PODRIAS EXPLICARME POR QUE NO LO TOCAS EN LA CONFIGURACION....
Hola Anónimo,
EliminarEl 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
Hola Buenos dia. Tengo una duda los IP que usastes son los IP de la maquina o los IP de la red
ResponderEliminarHola Dennis,
ResponderEliminarEsta 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...
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
ResponderEliminarHe 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