PORTADA Pacemaker

10
Nmero 85 WWW. L I NUX- MAGAZI NE. ES
inicie el servidor web, Pacemaker no
iniciar Apache directamente. En lugar
de eso, esta tarea est a cargo de los
agentes de recursos: actan como inter-
faz entre los servidores y Pacemaker en
el clster. Un agente tpico es un script
shell diseado especficamente para el
programa.
Los agentes de recursos aguardan
tres argumentos, start , stop y monitor,
que el gestor de clster puede pasarles
en el momento de llamar al script.
Pacemaker llama a los agentes con
estos parmetros y espera que funcio-
nen en consecuencia: start debe iniciar
un servicio, stop debe detener un servi-
cio y monitor le indica a Pacemaker si
un servicio todava se est ejecutando o
no.
Clases de Agentes
Los agentes de recursos para Pacema-
ker se agrupan en tres categoras: agen-
tes LSB (es decir, scripts de inicio nor-
males en lnea con la especificacin
Linux Standard Base), agentes heart-
beat (que se consideran obsoletos) y
Open Cluster Framework (OCF) [2],
que contienen los agentes ms destaca-
dos diseados para su uso con Pacema-
ker y que, en muchos casos, permiten
al administrador especificar los par-
metros para la configuracin de los ser-
vidores directamente dentro de la
configuracin del clster. Lo que todas
estas clases tienen en comn es que
necesitan soportar las tres opciones
para iniciar, finalizar o monitorizar ser-
vicios.
Antes de que podamos afinar la ins-
talacin de Pacemaker para monitori-
zar, primero tenemos que comprobar si
P
acemaker se ha convertido en la
eleccin estndar indiscutible
como solucin de alta disponi-
bilidad para sistemas Linux. Si uno de
los nodos de un clster falla, Pacema-
ker lanza los servicios fallidos en el
otro nodo de clster. Pero si usamos
Pacemaker solamente para acciones de
control de fallos como stas, nos esta-
mos perdiendo una de sus mejores
caractersticas. Muchos administrado-
res no son conscientes de que Pacema-
ker puede poner de nuevo en pie apli-
caciones de forma automtica.
El hardware que falla no es la nica
razn por la que un servicio puede
fallar. Por ejemplo, una aplicacin
puede fallar o doblar la rodilla si el ker-
nel se queda sin memoria RAM (OOM,
sin memoria).
Los administradores suelen imple-
mentar soluciones integrales de moni-
torizacin para hacer frente a proble-
mas como ste. Cuando un servicio
falla, se genera un aviso con Nagios (o
una herramienta de monitorizacin
equivalente) y as informa al adminis-
trador del sistema. Sin embargo, puede
pasar un tiempo significativo hasta que
el administrador est en disposicin de
resolver el problema. Mientras tanto, el
servicio que ha fallado no est disponi-
ble, aunque el resto de los servicios que
quedan en el clster se estn ejecu-
tando de forma habitual.
Para estos casos, Pacemaker soporta
una monitorizacin sencilla, que ataja
el problema volviendo a lanzar el pro-
grama colgado.
Pacemaker no se comunica directa-
mente con los servicios. Si el adminis-
trador le indica al gestor del clster que
cada uno de los agen-
tes de recursos en reali-
dad puede manejar estos
tres parmetros. Aunque
estos parmetros bsica-
mente siempre trabajan con
agentes OCF, la situacin
puede ser bastante desoladora
en el caso de scripts de inicio. En
particular, encontramos varios
scripts en sistemas Debian que no
entienden el parmetro monitor y por
tanto, generan como salida un mensaje
de error.
Este resultado es fatal para el contro-
lador del clster: debido al mensaje de
error, supone que el servicio no se est
ejecutando. Si a continuacin intenta
iniciar un servicio debido a esta suposi-
cin, podemos esperar el caos en nues-
tro clster. Llamar a un script de inicio
con el comando monitor por delante es
ms seguro. Si el agente devuelve un
valor plausible, el script de inicio es
adecuado para la implementacin de
monitorizacin con Pacemaker.
Si estamos seguros de que todos los
agentes en cualquier configuracin de
Pacemaker entienden el parmetro
monitor, no hay nada que nos impida
utilizar esta caracterstica en nuestra
configuracin de Pacemaker. La herra-
mienta preferida para la modificacin
de la configuracin del clster es el
shell CRM (vase la Figura 1). Podemos
iniciarla en nuestros sistemas Pacema-
ker realizando la llamada crm configure
en Bash.
El comando nos lleva directamente al
men configure. No nos har dao ase-
gurarnos de antemano de que nuestra
eleccin de editor de lnea de coman-
Monitorizacin automatizada con agentes de recursos Pacemaker
Estar All
Cuando un nodo de clster falla, el software de alta disponibilidad Pacemaker lanza los servicios en
otro nodo. Una funcionalidad menos conocida de Pacemaker es la capacidad de poner los servi-
cios fallidos de nuevo en pie en el gestor del clster. POR MARTIN LOSCHWITZ.
Probablemente encontraremos varios
recursos de este tipo en una
configuracin existente de CRM. Cada
uno de ellos soporta diferentes tipos de
parmetros de configuracin: parme-
tros que influyen directamente en el
programa a travs del agente y opera-
ciones de recursos. El primero se intro-
dujo en la configuracin de primitive
por la palabra clave params.
La palabra clave op introduce opera-
ciones. Los administradores pueden
utilizar las operaciones para definir
cmo Pacemaker debe manejar recur-
sos especficos. El repertorio estndar
incluye tres operaciones: start y stop
nos permiten configurar los lmites de
tolerancia de los tiempos de espera de
arranque y parada. La tercera es
la operacin monitor (vase
la Figura 2) que indica a
Pacemaker que llame regu-
larmente al agente de
recursos con el comando
monitor y saque conclusiones
de los resultados.
Para habilitar la monitorizacin
de un recurso primitive necesitamos
aadir la siguiente lnea a nuestra
configuracin:
op monitor interval=60sU
timeout=30s
Esta operacin le indica a Pacemaker
que compruebe si el servicio se est
ejecutando una vez por minuto. Si el
gestor del clster no recibe un valor de
retorno de las llamadas del programa
tras 30 segundos, se supone que la ope-
racin ha fallado y Pacemaker lanza un
reinicio del recurso. Tambin lo hace si
la comprobacin del recurso pone de
manifiesto que no se est ejecutando.
Adicionalmente, Pacemaker incrementa
el failcount del recurso, registrando de
esta manera el hecho de que el recurso
se haya colgado.
Caso especial DRBD
Los administradores con frecuencia
combinan Pacemaker con dispositivos
de bloque replicados de forma distri-
buida (DRBDs). Esta solucin de alma-
cenamiento replicado juega un papel
especial en Pacemaker: utiliza los
recursos maestro-esclavo para que
Pacemaker PORTADA
11
Nmero 85 WWW. L I NUX- MAGAZI NE. ES
dos est realmente configurada en la
variable de entorno $EDITOR. Tras eso,
el siguiente comando en CRM, edit, ini-
ciar este editor y cargar la
configuracin del clster existente.
Monitorizacin primitiva
La funcin de monitor se refiere a
recursos sencillos conocidos como pri-
mitivas en el lenguaje de Pacemaker.
Figura 1: crm ra info muestra informacin acerca del agente de recur-
sos. Las capacidades especficas de monitorizacin suelen figurar en
esta lista.
Figura 2: Monitorizar a nivel de recursos se habilita aadiendo la ope-
racin monitor para primitive.
nifica, tras haberse
detectado un
cierto nmero de
cuelgues en un
nodo del clster,
que un recurso no
se va a iniciar en
ese nodo. En este
caso, el controla-
dor del clster pro-
bara suerte en un
nodo diferente del
clster.
La funcionalidad
es prctica para
diferentes servi-
cios, como bases
de datos. Si
MySQL se cuelga
varias veces en el
servidor porque la
memoria RAM de
la mquina est
rota, no tiene sen-
tido reiniciar conti-
nuamente la base
de datos en ese
servidor. Podemos restringir este pro-
ceso usando el parmetro
migration-threshold. Pero, antes de que
el parmetro de umbral pueda tener
efecto, necesitamos ir al shell CRM y
aadir la siguiente lnea al bloque pro-
perty de la seccin configure:
cluster-recheck-interval=5m
Este paso asegura que el controlador
del clster no interviene solamente
sobre cualquier caso anterior, sino que
comprueba regularmente el estado de
todo el clster cada cinco minutos, con
la excepcin de las instrucciones de
monitorizacin, que tienen sus propios
intervalos.
Para habilitar el umbral para un
recurso, se necesita la siguiente entrada
para el mismo:
meta migration-threshold=2
failure-timeout=60s
En este caso, Pacemaker migrara el
servicio a un nodo diferente del clster
despus de dos cuelgues y permitira
que el servicio se ejecutase de nuevo en
el nodo original del clster despus de
60 segundos. En lugar de 60s, tambin
podemos especificar aqu un nmero
de minutos. 1440m asegurara que el
recurso no pueda ejecutarse en el nodo
problemtico durante todo un da, a
menos que el administrador intervenga
de forma manual.
Licencia para Matar
Al ser llamados, la mayora de los agen-
tes de recursos slo realizan comproba-
ciones superficiales sobre un programa
si se est ejecutando con monitor. Lo
que suelen hacer es comprobar si el
proceso correspondiente aparece en la
tabla de procesos y si el proceso reac-
ciona al comando kill -0. Es habitual
que las aplicaciones cumplan con
ambas condiciones, aunque no funcio-
nen correctamente.
Ejemplos de esto: mquinas virtuales
cuyos procesos kvm an se estn ejecu-
tando, pero que no responden a un
ping, o cuando Asterisk se ejecuta en
una mquina virtual pero ya no res-
ponde, aunque el proceso est en ejecu-
cin. Los autores de recursos de agen-
tes deben tener cuidado con estos pro-
blemas por si mismos. Existen solucio-
nes para los dos ejemplos citados: tanto
ocf:heartbeat:VirtualDomain como
ocf:heartbeat:asterisk ofrecen mecanis-
mos avanzados de comprobacin para
evitar falsos positivos.
Scripts de Monitorizacin
El Agente de Dominio Virtual utiliza el
parmetro monitor_scripts en la
configuracin de CRM para controlar
este problema. El administrador puede
especificar una lista de scripts separada
por comas a la que llama Pacemaker
durante las operaciones monitor. Si
especificamos scripts externos aqu, los
agentes de recursos recogen los valores
de retorno desde los resultados de
monitor.
Existen scripts adicionales (vase la
Figura 3) que pueden probar funciones
arbitrarias. Un script recomendable
comprueba la IP de la mquina virtual
con ping y devuelve 0 si la mquina
responde al ping, o 1 en caso contrario.
El agente especial de Asterisk
ocf:heartbeat:asterisk utiliza una fun-
cin muy similar. Si el programa sipsak
est instalado en el sistema de destino
y si definimos el siguiente parmetro
en la configuracin de CRM
monitor_sipuri=sip:<I>IP<I>.,
pueda gestionar DRBD en ambos
modos del cluster, sin importar si el
recurso DRBD se encuentra en ese
momento en modo Primary o Secon-
dary.
La configuracin maestro-esclavo
toma la forma de una regla ms en la
configuracin de Pacemaker que con-
tiene una referencia al recurso primitive
DRBD adecuado. A fin de garantizar
que funcionan las operaciones de
monitorizacin, debemos estar al tanto
de este caso especial: la operacin
monitor para un recurso primitive al
que apunta una regla ms tiene el
siguiente aspecto:
op monitor interval=30sU
role=Slave
op monitor interval=25sU
role=Master
En otras palabras, necesitamos separar
operaciones monitor para los roles
Master y Slave , pero los intervalos no
deben ser idnticos ya que la opera-
cin monitor no funcionara en este
caso.
Umbrales
Pacemaker usa un concepto conocido
como umbral de migracin, lo que sig-
PORTADA Pacemaker
12
Nmero 85 WWW. L I NUX- MAGAZI NE. ES
Figura 3: Si queremos que los agentes de recursos hagan algo ms
que simplemente comprobar la existencia de un proceso, necesitamos
incorporar esta capacidad en el script.
el agente enva una peticin SIP al
servidor de Asterisk para cada lla-
mada de monitorizacin. Si se
devuelve una respuesta significativa
a la solicitud, la operacin concluye
con xito. De lo contrario, Pacemaker
etiqueta el proceso como failed y
contina con su procedimiento nor-
mal.
Por cierto, si se resuelve el problema
que llev al fallo de la operacin de
monitorizacin, podemos ejecutar
crm resource cleanupU
<I>nombre_del_recurso<I>
en Bash para restablecer Failcount para
el recurso. Este proceso guarda la situa-
cin inicial (vase la Figura 4).
Ampliar los Agentes
Si un agente de recursos de nuestra
configuracin del clster no tiene fun-
ciones avanzadas de control de inicio,
no hay problema. Por lo general, podre-
mos aadir las funcionalidades necesa-
rias al agente sin mucha dificultad. Los
agentes LSB generalmente residen en el
directorio /etd/ init.d, los agentes Heart-
beat en /etc/ ha.d/ resources.d y los
agentes OCF en /usr/ lib/ ocf/ resource.d.
Para ampliar un agente, slo tenemos
que encontrar el archivo adecuado. El
shell scripting no debera ser un obst-
culo para la mayora de los administra-
dores. Slo tenemos que buscar la fun-
cin a la que llama el agente en la sec-
cin monitor y agregar all el cdigo
adicional.
Material de Lectura
Si estamos interesados en obtener
informacin ms en profundidad sobre
editar agentes de recursos, hay dos
documentos a tener en cuenta: la gua
para desarrolladores de agentes OCF
[2] y un artculo en la revista ADMIN,
que describe el proceso de creacin de
un agente OCF de inicio a fin [3]. I
Pacemaker PORTADA
[1] Pacemaker: http:// www. clusterlabs. org
[2] The OCF Resource Agents Developers Guide, por Florian Hass: http:// www.
linux-ha. org/ doc/ dev-guides/ ra-dev-guide. html
[3] Writing Your Own OCF Agent, por Martin Loschwitz, revista ADMIN Network &
Security, nmero 07, pg. 66 .
RECURSOS
Figura 4: p_filesystem:1 se ha colgado, pero
Pacemaker ha remediado automaticamente
la situacin. crm_mon -1 -rf nos indica si los
recursos se colgaron anteriormente.