PORTADA Pacemaker

10 Nmero 85 W W W . L I N U X - M A G A Z I N E . E S

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 AgentesLos 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

Pacemaker 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 AllCuando 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 DRBDLos 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

11Nmero 85W W W . L I N U X - M A G A Z I N E . E S

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 primitivaLa 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 MatarAl 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 MonitorizacinEl 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:IP.,

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.

UmbralesPacemaker usa un concepto conocido

como umbral de migracin, lo que sig-

PORTADA Pacemaker

12 Nmero 85 W W W . L I N U X - M A G A Z I N E . E S

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

nombre_del_recurso

en Bash para restablecer Failcount para

el recurso. Este proceso guarda la situa-

cin inicial (vase la Figura 4).

Ampliar los AgentesSi 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 LecturaSi 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].

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.