corosync y pacemaker
Post on 26-Dec-2015
32 Views
Preview:
TRANSCRIPT
Aproximacin al clustering de alta disponibilidad ---
(I) Cluster bsico de alta disponibilidad con
Corosync+Pacemaker
(II) Cluster bsico de alta disponibilidad con
Corosync+Pacemaker
---
Tengo que reconocer que desde que empec en esto de la informtica,
el tema del clustering siempre me ha llamado la atencin.
Tambin tengo que decir que hasta hace muy poquito, ni siquiera poda
imaginarme como funcionaba esto por dentro.
Coincidiendo con el desarrollo de mi Proyecto Integrado para
finalizar el ciclo de ASI, voy a escribir una serie de artculos
sobre este tema. As que espero que este sea el primero de una serie
de documentacin que profundice ms en la alta disponibilidad (de la
que por cierto, hay escasa documentacin en Espaol).
Antes de empezar, me gustara llamar la atencin sobre la gran
cantidad de posibles configuraciones y la amplitud de posibilidades
en el mundo del clustering. No entrar en asuntos de clustering de
supercomputacin (no estoy preparado en esa materia).
1 El concepto de recurso
Lo primero que vamos a encontrar al trabajar con un cluster es un
recurso. Es fundamental comprender el concepto de recurso, porque
nos abrir la puerta a entendernos con lo que hay detrs y con las
posibilidades de configuracin.
A priori, un recurso se corresponde con un servicio. Esto quiere
decir lo siguiente:
-> Servicio http (apache) -> Recurso http (apache)
-> Servicio sgbd (mysql) -> Recurso sgbd (mysql)
[etc...]
Una vez comprendida e interiorizada esta correspondencia podemos
decir que un recurso puede ser algo mucho ms completo que un
servicio y que tiene caractersticas aadidas:Movilidad: Un servicio
pertenece a una mquina. Un recurso no pertenece a una mquina (ya lo
veremos).
Integracin: Podemos conseguir un grado muy alto de integracin entre distintos recursos; relaciones de localizacin, relaciones de orden de arranque y parada, etc...
Agrupacin: Podramos decir que un recurso en algunos casos est compuesto de varios servicios, e incluso de otros recursos.
As que podemos resumir que cuando hablamos de un cluster de alta
disponibilidad, nos referimos a un recurso que se ofrece y no a un
servicio.
2 Esquemas de montaje
Existen varias configuraciones posibles para un cluster de alta
disponibilidad.
Tenemos desde un cluster sencillo de dos mquinas (dos nodos,
llamando a las cosas por su nombre) a un cluster de N nodos (usando
cualquier numero de mquinas).
Es importante tener en mente el tipo de cluster que necesitamos y
que estamos montando. Por supuesto, supongo que cada uno puede
inventarse su propio esquema de montaje, aunque los ms comunes
son:Activo/Pasivo -> Configuracin bsica de 2 o ms nodos. Hay un
nodo principal o maestro, donde estn corriendo la mayora de
recursos y una serie de nodos esclavos o de backup, que entrarn en
funcionamiento cuando el nodo principal falle.
Activo/Activo -> Configuracin tambin bsica de 2 o ms nodos. Con este tipo de clusters se desarrolla (entre otras cosas) lo que se llama "balanceo de carga". Generalmente, los recursos estn duplicados (clonados) en varios nodos y mediante algn mecanismo (dns, switches, etc..) repartiremos la carga entre cada nodo.
N+1 -> Combinacin de varios tipos de clusters en uno solo. Esta configuracin es ms avanzada y requiere que el administrador tenga las cosas muy claras sobre lo que est haciendo. En un mismo cluster (por ejemplo, activo/pasivo) podemos combinar un nodo de backup (de ah el nombre) o incluso usar varios nodos de backup.
N-to-N -> Cuando existe posibilidad de usar almacenamiento compartido (lase SAN o NAS) y los requisitos necesarios de hardware, cada nodo puede usarse para lo que queramos, osea, configuraciones de balanceo de carga con clones mltiples de backup. Es una de las configuraciones ms avanzadas y tengo que decir que por ahora a m me viene un poco grande, la verdad.
Ms informacin sobre esquemas de configuracin, con dibujos (bien
hechos jeje) se pueden encontrar en la web/wiki de
clusterlabs.org
3 El software que permite esto
Hay varias tecnologas que permiten la construccin de clusters.
Muchas de ellas son libres y otras privadas; lo normal en estos
casos. Yo voy a centrarme en la combinacin de dos herramientas, que
son Heartbeat y Pacemaker, aunque hay muchas otras
posibilidades:Corosync
OpenIAS
LVS
Keepalived
Yo he llegado tarde a esto, pero parece que la comunidad de alta
disponibilidad ha tendido a estandarizarse, haciendo uso de
esquemas de funcionamiento similiares y configuraciones basadas en
XML (que aunque feas, son fciles a la hora de mover entre distintos
programas).
Bsicamente, necesitamos dos elementos completamente distintos, y
que son:Comunicacin entre nodos para la valoracin de sus estados.
(heartbeat)
Gestin de recursos desplegados en el cluster. (pacemaker)
Por lo tanto, ser en heartbeat donde declararemos qu mquinas forman parte del cluster y en pacemaker qu recursos hay repartidos por el cluster (y en que nodo, y el resto de opciones de configuracin).
4 Vistazo al software y configuracin
Sin meternos en mucho detalle, dir que la configuracin de heartbeat
es relativamente sencilla, y en un par de ficheros de configuracin
tendremos lista la declaracin del cluster.
Para pacemaker el asunto es un poco ms complejo. El tema se maneja
por XML, aunque hay una buena cantidad de herramientas que permiten
hacer una administracin rpida y obviando totalmente los ficheros de
configuracin.CRM shell -> lo ms extendido, programa en terminal
que maneja el XML.
DRBD-MC -> programa grfico en java, que realmente maneja cibadmin por debajo mediante ssh, pero que presenta un aspecto visualmente atractivo e intuitivo.
Heartbeat gui -> Interfaz web. La verdad es que ni lo he probado.
En la mayora de manuales se encuentran referencias a CRM shell,
y es lo que yo mostrar en los siguientes artculos que escriba (si
es que eso ocurre).
Tengo que decir que hay muchas referencias documentales a heartbeat
como nico software de gestin para el cluster, y es cierto. Antes,
heartbeat cumpla las funciones de control de recursos, adems de
encargarse de la comunicacin de estados entre nodos. Esto ya no es
as y hay que huir pavorosamente de todas las documentaciones que
usen el fichero "/etc/ha.d/haresources" .
NOTA EDITADA:
Segn me comentan los desarrolladores, el proyecto "heartbeat" no va
a recibir nuevas actualizaciones, dado que RedHat y Novell/SUSE han
apostado fuerte por Corosync.
En cualquier caso, con el desarrollo actual de heartbeattodavase
puede trabajar.5 Nomenclatura propia
Al principio es un lo tremendo ver tantas abreviaturas y palabras
nuevas, as que dejo un pequeo resumen de los conceptos ms
importantes:CRM -> Cluster Resouce Manager. Es el software que
provee del control sobre los recursos desplegados en el cluster. Yo
he hablado de pacemaker mediante la herramienta CRM Shell.
CIB -> Cluster Information Base. Es el fichero XML donde se refleja la configuracin de los recursos que se ha hecho mediante el CRM. Se genera y se propaga automticamente a todos los nodos del cluster cuando es modificado. Est muy escondido y no es nada recomendable tocarlo a mano.
OCF -> Open Cluster Framework. Podriamos llamarlo el standar mediante el cual el CRM interactua con los servicios que corren en cada mquina. Mediante los standares OCF (realmente son scripts que interactuan con otros scripts) se manejan los scripts tpicos de "/etc/init.d" para obtener el estado de cada servicio, pararlos, arrancarlos, etc..
Messaging Layer -> Donde se coloca Heartbeat, OpenAIS u otro software. Se refiere al programa o demonio que controla la comunicacin de estados entre los nodos.
VIP -> Virtual IP. Generalmente, un cluster tendr una IP virtual que identificar al conjunto de nodos. Suele ser el primer paso en la configuracin de recursos y testeo de configuraciones.
failover/failback -> Cuando un nodo del cluster cae (deja de funcionar) y cuando vuelve a estar activo, respectivamente. Cuando se hace por razones administrativas, tambin puede llamarse switchover.
Esto que yo he escrito aqu pienso que es una buena base para
empezar a meterse en el mundo del clustering de alta
disponibilidad. A mi me ha costado alcanzar claridad en estos
conceptos bastante tiempo, y tenia muchas ganas de plasmar este
resumen y que le sirva a otro.
Al hilo del anterior post "Aproximacin al clustering de Alta
Disponibilidad", voy a explicar como construir y manejar un cluster
bsico basado en Corosync+Pacemaker.
El objetivo es sentar una base desde la que partir a realizar
configuraciones ms avanzadas, y explicar un poco el manejo y
funcionamiento de Pacemaker mediante la herramienta CRM.
Por ahora, solo voy a tratar una configuracin de tipo
activo/pasivo, y es posible que ms adelante escriba algo sobre
activo/activo (con balanceo de carga) u otras configuraciones ms
avanzadas.
Las herramientas que voy a usar son Corosync+Pacemaker, ya se
sabe:Corosync para la "mensajera" entre nodos del cluster.
Pacemaker para la gestin de recursos en alta disponibilidad.
Hay otras herramientas disponibles para la construccin de clusters de alta disponibilidad, que son:Keepalived.
LVS
Wackamole
Heartbeat
Heartattack
OpenAIS
Pero yo voy a centrarme en Corosync+Pacemaker porque despus de
investigar un poco, se detecta rpidamente que son las herramientas
con ms desarrollo, proyeccin de futuro, y actividad. De hecho, hay
algunas herramientas que estn prcticamente muertas, como son
Heartbeat y Wackamole.
Como base para un cluster de alta disponibilidad, la combinacin
Corosync+Pacemaker cumple perfectamente con los requerimientos y
funcionalidades necesarios, teniendo adems la ventaja de una
comunidad muy activa (que puede ayudarnos en determinados
callejones sin salida).
Hardware necesario
En cada nodo del cluster necesitaremos al menos 2 interfaces de
red, 1 para la comunicacin directa entre nodos y otra para los
servicios ofrecidos al exterior.
Aunque sera posible trabajar con una nica interfaz, es muy
recomendable hacerlo de esta manera por motivos de estabilidad,
seguridad, escalabilidad, etc..
El reparto de IPs puede verse en el esquema, con las interfaces que son:eth0 para atender a los clientes.
eth1 para la red interna de comunicacin entre nodos.
IPV: 192.168.0.1 (que alternativamente ser asignada al nodo1 y al nodo 2)
Instalacin
El proceso de instalacin es sencillo: desde los repositorios
oficiales de nuestra distribucin favorita (Debian en mi caso). En
entornos tipo RHEL tendremos que instalar un repositorio
externo.
Instalamos los paquetes en todas las mquinas del
cluster.Debian(root#) aptitude install corosync pacemaker
RHEL(root#) rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm(root#) wget -O /etc/yum.repos.d/pacemaker.repo http://clusterlabs.org/rpm/epel-5/clusterlabs.repo(root#) yum install -y pacemaker corosync heartbeat
Se instala heartbeat por dependencias, cuyos paquetes contienen
algunas libreras necesarias para Pacemaker.
Configuracin y arranque de Corosync
Una configuracin bsica del demonio de Corosync se incluye al
instalar la herramienta, y algo definitivo puede quedar
as:/etc/corosync/corosync.conf compatibility: whitetanktotem
{version: 2secauth: offthreads: 0interface {ringnumber:
0bindnetaddr: 172.16.0.0mcastaddr: 226.94.1.1mcastport:
5405}}logging {fileline: offto_stderr: yesto_logfile: yesto_syslog:
yeslogfile: /tmp/corosync.logdebug: offtimestamp: onlogger_subsys
{subsys: AMFdebug: off}}amf {mode: disabled}Esta configuracin es
comn (en este caso concreto) a todos los nodos del cluster, y no se
propaga automticamente.
Debemos crear la carpeta "/etc/corosync/service.d/", y aadir el
siguiente fichero:/etc/corosync/service.d/pcmkservice {name:
pacemakerver: 0}El parmetro "ver" determina si es Corosync el que
debe arrancar a Pacemaker o no. Segn qu versin del software que
estemos usando, debe estar a 1 o a 0 (en 1, existe un script LSB en
/etc/init.d/ para Pacemaker, y es el sistema operativo el que lo
arranca, con 0 es Corosync el que lo arranca y no existe script
LSB).
Bajo Debian, necesitamos tocar otro fichero de configuracin, sin el
cual Corosync no arrancar bajo ningn
concepto:/etc/default/corosyncSTART=yes
Ya podemos arrancar el servicio y monitorizar el
cluster:(root#)/etc/init.d/corosync start(root#)crm
status============Last updated: Tue May 31 13:45:12 2011Stack:
openaisCurrent DC: nodo1 - partition with quorumVersion:
1.0.11-1554a83db0d3c3e546cfd3aaff6af1184f79ee872 Nodes configured,
2 expected votes0 Resources configured.============
Online: [ nodo1 nodo2 ]
Sincronizacin de ficheros entre nodos
Hay algunos ficheros interesantes que deben ser iguales entre los
nodos del cluster.
No hay ningn mtodo predefinido para hacer una sincronizacin de los
mismos, as que en su momento desarroll un pequeo script en BASH que
hace uso de rsync para tal menester.
Usndolo, el funcionamiento es transparente. Realmente no se si es
la mejor opcin, dado que se usan bastantes recursos del sistemas
durante muchas horas muertas donde no hay nada que sincronizar...
as que estoy abierto a sugerencias.
Est compuesto de dos
ficheros:/usr/local/bin/cluster/sync_files.sh#!/bin/bash
# Este script hace uso de rsync para sincronizar# ficheros entre los nodos de un cluster.
# El script esta pensado para ejecutarse varias veces por minuto. (crontab)
# Todas las maquinas que participen deben intercambiar las claves# para la conexion ssh:# ssh-keygen# ssh-agent $SHELL# ssh-add# ssh-copy-id
# Ademas, es muy importante que las horas esten sincronizadas.# En caso contrario, el comportamiento es ciertamente problematico.
# Los nombres de cada maquina deben ajustarse a `uname -n`# No importa de donde venga la lista de nombres mientras se cumpla.# Debe haber un espacio en blanco entre cada nombre de maquina.
# Se comprueba un lock file para que no se superpongan ejecuciones# de este script
########################## Variables ##########################LISTA_NODOS="nodo1 nodo2"THIS=`uname -n`LISTA_FICHEROS="/etc/rsync.d/sync_files.conf"THIS_PID=$$LOCK_FILE="/var/run/sync_files.sh.LOCK"
########################## Programa ##########################
# Validando ejecucionif [ -e $LOCK_FILE ]thenif [ "`cat $LOCK_FILE`" != $THIS_PID ]thenexit 1fielseecho "$THIS_PID" > $LOCK_FILEfi
# Sincroniafor nodo in $LISTA_NODOSdo# Si el nodo de la lista no es el propio nodo ejecutando este script# se ejecuta la instruccion de rsyncif [ "$nodo" != "$THIS" ]then# Se sincronizan los ficheros especificados en $LISTA_FICHEROS# Usando como copia maestra el mas reciente.rsync -urv --files-from=$LISTA_FICHEROS $nodo:/ /fidone
# Finalizando ejecucionrm -f $LOCK_FILE
Y la lista de ficheros a
sincronizar:/etc/rsync.d/sync_files.conf/etc/rsync.d/sync_files.conf/usr/local/bin/cluster/sync_files.sh/etc/resolv.conf/etc/ntp.conf/etc/corosync/corosync.conf/etc/corosync/service.d/pcmk/etc/modules/etc/sysctl.conf
Para la correcta ejecucin, damos permisos al script tipo "chmod
a+x" y aadimos un par de lneas a crontab/etc/crontab[...]* * * * *
root /usr/local/bin/cluster/sync_files.sh* * * * * root sleep 30
&& /usr/local/bin/cluster/sync_files.sh[...]
Como pone en los comentarios del script, es importante intercambiar
las claves de los nodos, para que el proceso de Rsync (ssh) sea
totalmente transparente.
Adems, es muy interesante indicar que toda comunicacin de un nodo
con otro, se haga a travs de la interfaz interna (eth1), con lo
cual editamos los ficheros:
/etc/hosts en nodo1[...]127.0.0.1 localhost nodo1172.16.0.2
nodo2[...]
/etc/hosts en nodo2[...]127.0.0.1 localhost nodo2172.16.0.2
nodo1[...]
Trabajando con PacemakerMediante la herramienta "crm" se
interacciona con Pacemaker.
Realmente, manejamos el cib.xml (cluster information base), aunque
vamos a ver poco XML por aqu.
Las instrucciones de crm pueden introducirse en cualquier nodo, y
sern propagadas automticamente por todo el cluster.
Primero, indicamos a Pacemaker que nuestro cluster, por ahora, solo
tiene 2 nodos. Necesitamos una configuracin un poco especial para
ello, dado que Pacemaker viene preparado para trabajar con muchos
nodos.root@nodo1:~# crm configure property
stonith-enabled=falseroot@nodo1:~# crm configure property
no-quorum-policy=ignoreroot@nodo1:~# crm configure rsc_defaults
resource-stickiness=100
Con esto, estamos indicando lo siguiente:STONITH est deshabilitado.
STONITH es un servicio que sirve para garantizar que un nodo est
realmente muerto en situaciones de clusters con servicios crticos
en cuanto a integridad de datos.
Ignoramos las polticas de QUORUM. No es necesario para un clusters de 2 nodos, y da problemas si no se deshabilita.
Situamos el nivel de "pegajosidad" de un recurso en 100. Esto es que un recurso tender a quedarse donde est (nodo) antes de moverse a otro nodo sin motivo de fuerza mayor (que son movimiento manual o situacin de failover).
Recursos en alta disponibilidad
La mayora de veces, el primer recurso a crear en alta disponibildad
es una IPV (IP virtual). Sin ella no hacemos nada.
Con CRM, la instruccin es bastante fcil:root@nodo1:~# crm configure
primitive IPV-1 ocf:heartbeat:IPaddr \params ip=192.168.0.1
nic=eth0 cidr_netmask=24 \op monitor interval=5s
Especificamos lo siguiente:crm configure primitive -> Aadimos un
recurso
IPV-1 ocf:heartbeat:IPaddr -> El nombre del recurso es "IPV-1" y hace uso del RA (resource agent, o script que controla el recurso) "ocf:heartbeat:IPaddr".
Los parmetros son la IP, la interfaz que atender a esa IP y la mscara de red.
Como opciones, el "monitor interval" concreta la frecuencia con la que Pacemaker se asegura de que el recurso est funcionando. Este valor es el recomendado en todos sitios.
Cmo sabemos qu Resource Agent se usa para cada servicio? Muy
fcil, el propio CRM buscar y nos mostrar esa
informacin:root@nodo1:~# crm ra classes heartbeat lsb ocf /
heartbeat pacemaker stonith root@nodo1:~# crm ra list ocf heartbeat
[...]AoEtarget AudibleAlarm mysql mysql-proxy syslog-ng tomcat
vmware[...]
Es posible escribir nuestros propios Resource Agent, aunque los
servicios ms comunes ya tienen uno escrito y probado, que se
distribuye en la instalacin del software.
Podemos ver la configuracin de nuestro cluster en cualquier
momento:root@nodo1:~# crm configure shownode nodo1node
nodo2primitive IPV-1 ocf:heartbeat:IPaddr \params ip="192.168.0.1"
nic="eth0" netmask="255.255.255.0" \op monitor
interval="5s"property $id="cib-bootstrap-options"
\dc-version="1.0.11-1554a83db0d3c3e546cfd3aaff6af1184f79ee87"
\cluster-infrastructure="openais" \expected-quorum-votes="2"
\stonith-enabled="false" \no-quorum-policy="ignore"rsc_defaults
$id="rsc-options" \resource-stickiness="100"
Que da como resultado el siguiente status:root@nodo2:~# crm
status============Last updated: Tue May 31 14:28:14 2011Stack:
openaisCurrent DC: nodo1 - partition with quorumVersion:
1.0.11-1554a83db0d3c3e546cfd3aaff6af1184f79ee872 Nodes configured,
2 expected votes1 Resources configured.============
Online: [ nodo1 nodo2 ]
IPV-1 (ocf::heartbeat:IPaddr): Started nodo1
Cuando aadimos recursos, podemos especificar distintas
"constraints" o renstricciones, que son:De orden de arranque (es
probable que algunos recursos requieran a otros antes de
arrancar).
De colocacin (muy importantes, seguramente sea necesario que en el nodo que est colocada una IPV deban correr el resto de recursos).
De preferencia (especificamos dnde prefiere un recurso estar).
La explicacin en profundidad de estas caractersticas daran para
escribir mucho (aunque no es difcil de manejar), as que dejar el
tema para futuras publicaciones.
Pienso que el objetivo de estos post se ha cumplido, que era
familiarizarnos con el entorno de Corosync+Pacemaker y construir
algo muy bsico. Tan bsico que nuestro nico recurso en alta
disponibilidad es una IP, jeje
top related