Cluster Resource Manager

Administración y Gestión de Redes Servicios de alta disponibilidad

Servicios de alta disponibilidad.

Autores: Enrique V. Bonet Esteban / Susana Pons Sospedra

Introducción.

La alta disponibilidad es la capacidad de ofrecer un conjunto de servicios sobre un sistema informático que es capaz de recuperarse ante fallos. La alta disponibilidad se relaciona mucho con los sistemas tolerantes a fallos, es decir un sistema que es capaz de funcionar aún cuando se produzca una degradación de los componentes que lo forman.

Es importante no confundir la alta disponibilidad con sistemas de alto rendimiento, pues en este segundo caso lo que se pretende es que el servicio se ofrezca en términos de mejores prestaciones como, por ejemplo, menores tiempos de respuesta o menores tiempos de computo, etc.

De forma general, un cluster de alta disponibilidad esta formado por los siguientes elementos:

• Un conjunto de nodos que proporcionan los servicios del cluster. Cada nodo implementa un conjunto de servicios con una IP única para todo el nodo.

• Un conjunto de estrategias que permitan la migración de los servicios de un nodo a otro tras el fallo del nodo principal. Esto supone reiniciar los servicios siempre y cuando no exista la posibilidad de ejecutar este servicio desde un punto de recuperación (checkpoint).

• Un servicio de comunicación entre los nodos de cluster.

• Un sistema de monitorización para la detección de errores en el servidor.

Además, y de forma general, todos los cluster poseen un sistema de almacenamiento que permite el acceso a la información almacenada a los nodos que forman el cluster1.

En este tema explicaremos corosync junto con pacemaker, que son un conjunto de paquetes de software que permite implementar un servicio de alta disponibilidad. Corosync proporciona la comunicación entre los nodos del cluster, mientras que pacemaker proporciona el control de los recursos en cada uno de los nodos del cluster. Los servicios de corosync y pacemaker se arrancan con los comandos:

service corosync startservice pacemaker start

Debiendo arrancarse ambos servicios pues corosync no arranca pacemaker ni viceversa.

1 Este sistema de almacenamiento puede estar formado por DRBD, tal y como vimos en temas anteriores.

Ingeniería Técnica en Telecomunicación 1Especialidad en Telemática


En el ejemplo de configuración que utilizaremos durante todo el tema supondremos dos nodos, de nombres nodo1 y nodo2, de forma que nodo1 será el nodo principal del cluster y nodo2 el nodo de respaldo del cluster. Supondremos además que ambos nodos tienen dos interfaces de red, correspondiendo eth0 a una dirección de red privada (192.168.0.1 para nodo1 y 192.168.0.2 para nodo2) y eth1 a una dirección de red pública (10.0.0.1 para nodo1 y 10.0.0.2 para nodo2). Además, ambos nodos tienen un interfaz serie /dev/ttyS0 disponible.

Por otra parte, suponemos que la dirección pública flotante del cluster es 10.0.0.3.

Configuración de corosync

Como hemos comentado, corosync es el paquete que se encarga de proporcionar la comunicación entre los nodos del cluster. Para ello, utiliza direcciones multicast de forma que todos los nodos que forman un cluster utilizan la misma dirección multicast para comunicarse entre ellos. Existe la posibilidad de utilizar direcciones broadcast y direcciones unicast, pero para ello es necesario que cada nodo conozca las direcciones de todos los nodos del cluster, por lo que es preferible utilizar direcciones multicast.

La comunicación entre los nodos se implementa mediante dos servicios, un servicio de eventos que envía los eventos que suceden a todos aquellos nodos que se han suscrito, y un servicio de mensajes que envía mensajes entre dos nodos finales. Por último, existe un mecanismo que permite sincronizar el acceso a los mensajes enviados.

El paquete corosync, trabajando con pacemaker, se configura en tres ficheros, /etc/corosync/corosync.conf, /etc/corosync/authkey y /etc/corosync/service.d/pacemaker.



El fichero corosync.conf.

El fichero corosync.conf esta formado por líneas que configuran directivas las cuales contienen instrucciones sobre el funcionamiento de corosync en su interior. Toda línea en blanco o que comienza por el carácter # es ignorada.

Las directivas pueden ser de cuatro tipos:

• totem {}: Directivas que configuran opciones de configuración de la comunicación del cluster.

• logging {}: Directivas que configuran opciones de log de la aplicación.

• event {}: Directivas que configuran opciones del servicio de eventos entre nodos del cluster.

• amf {}: Directivas que configuran el Availability Management Framework (AMF), un conjunto de herramientas que permiten configurar, monitorizar, etc., el cluster.

Además, al principio puede especificarse el parámetro compatibility para indicar el nivel de compatibilidad requerido por el usuario, de forma que se pueda especificar con que versión anterior de corosync debe ser compatible el funcionamiento de la versión instalada.

Un ejemplo del fichero corosync.conf es el siguiente:

compatibility: whitetank

totem { version: 2 secauth: off threads: 0 interface {

ringnumber: 0 bindnetaddr: 192.168.0.0 mcastaddr: 226.95.1.1 mcastport: 5405 ttl: 1

} }

logging { fileline: off to_stderr: no to_logfile: yes to_syslog: yes logfile: /var/log/cluster/corosync.log debug: off timestamp: on logger_subsys {

subsys: AMF



debug: off }

}

amf { mode: disabled

}

En el ejemplo podemos ver, en primer lugar, la opción de compatibilidad (compatibility). Esta opción de compatibilidad puede tomar dos valores, valor whitetank (valor por defecto) que indica que sea compatible con versiones de corosync anteriores a la 1.X.Y, y el valor none, que indica que solo sea compatible con versiones 1.X.Y.

A continuación podemos observar tres directivas, totem{}, logging{} y amf{}.

La directiva totem{}, que como hemos indicado configura el modo de funcionamiento de la comunicación del cluster, contiene en este caso los valores2:

• version: Versión del fichero de configuración. El único valor valido es 2.

• secauth: Especifica si los mensajes deben ir autenticados o no. El valor por defecto es on (mensajes autenticados), aunque en nuestro caso esta desactivado (valor off).

• threads: Indica el número de hilos que son usados para encriptar y enviar los mensajes multicast si el valor de secauth es on. Un valor de 0 (valor por defecto) indica que no se utilicen hilos para encriptar y enviar los mensajes.

• interface{}: Es una subdirectiva que siempre debe existir como mínimo una vez dentro de cada directiva totem{}. Esta subdirectiva configura las opciones de red de corosync. Sus valores son:

◦ ringnumber: Especifica el número del anillo al que pertenece el interface dentro de la configuración. Cada interface de una directiva totem{} debe poseer un número diferente, indicando el número la prioridad del interface, de forma que el valor 0 indicaría el primario, el valor 1 el de backup, etc.

◦ bindnetaddr: Indica la dirección que identifica la red en la que se ejecuta corosync. Por ejemplo, si la dirección de red del interface es 192.168.0.1 con máscara /24, debe ponerse 192.168.0.0, que es la dirección que corresponde a la red (nuestro ejemplo). Si la dirección es 192.168.0.73 con máscara /26 debe ponerse 192.168.0.64.

◦ mcastaddr: Dirección multicast a la que envía corosync los mensajes. En nuestro ejemplo estamos usando 226.95.1.1.

2 Una descripción detallada de todas las opciones existentes puede encontrarse en las páginas del manual del sistema.



◦ mcastport: Conjunto de puertos que utiliza corosync para enviar y recibir los paquetes multicast. El puerto UDP de recepción es el indicado por el valor mcastport y el puerto de envío es el valor mcastport-1. Como en nuestro ejemplo el valor es 5405, se utiliza el puerto UDP 5404 para enviar los mensajes multicast y el 5405 para recibir los mensajes multicast. Cada par mcastaddr:mcastport define un cluster distinto, por lo que los componentes de un mismo cluster deben tener este par de valores iguales, mientras que los componentes de otro cluster deben usar una configuración que haga que la unión de estos dos valores sea distinta a cualquier otra.

◦ ttl: Tiempo de vida de los paquetes. El valor 1 es el recomendable (valor del ejemplo) para un cluster formado por nodos dentro de una subred con un router de salida. Sin embargo en otros casos puede ser necesario incrementar este valor para permitir la difusión de los mensajes a otras subredes.

La directiva logging{} contiene en nuestro caso los valores:

• fileline: Indica si el nombre del fichero y la línea deben ser indicados en el log. El valor por defecto es off.

• to_stderr: Especifica junto con la siguiente el destino de la salida de log generada por corosync. to_stderr indica que el log se envíe al lugar especificado para la salida estándar de error. Su valor por defecto es yes, aunque en nuestro ejemplo se encuentra a no.

• to_logfile: Especifica que el log se envíe a un fichero, cuya localización se especifica con posterioridad en otro argumento. Su valor por defecto es no, aunque nuestro ejemplo se encuentra a yes.

• to_syslog: Indica si el log se envía al syslog del sistema (valor yes) o no (valor no). El valor por defecto es yes.

• logfile: Indica el nombre del fichero donde se escribirán los log del sistema si la opción to_logfile tiene valor yes. En nuestro ejemplo le hemos asignado el valor /var/log/cluster/corosync.log.

• debug: Indica si se activa la opción de depuración (valor yes) o no (valor no), que es el valor por defecto. La activación obliga a corosync a escribir logs más detallados, siendo útil en depuración de la configuración.

• timestamp: Especifica si se escribe la hora del sistema antes de cada línea de log (valor on) o no (valor off). El valor por defecto es off.

• logger_subsys{}: Es una subdirectiva que permite modificar algunos de los valores anteriores para identificar el subsistema sobre el que se aplican los cambios indicados. Es posible modificar todos los valores menos fileline, timestamp y function_name (no explicado).



◦ subsys: Es un parámetro requerido por la subdirectiva logger_subsys{} e indica sobre que subsistema se aplica la modificación. En nuestro caso el subsistema es Availability Management Framework (AMF).

◦ debug: Valor de la opción de depuración para este subsistema, valor off en nuestro caso.

La última directiva usada en nuestro ejemplo, amf{}, permite configurar el funcionamiento del subsistema Availability Management Framework (AMF). Actualmente la única opción existente es mode, y el único valor que puede tomar es disabled, pues el AMF se encuentra en la actualidad en fase de desarrollo y todavía no esta disponible en las versiones actuales de corosync.

El fichero pacemaker.

El fichero pacemaker, que se encuentra dentro del subdirectorio service.d, indica a corosync que el control de los recursos lo proporciona pacemaker. El fichero contiene las líneas:

service { name: pacemaker ver: 1 }

Donde name indica el nombre del servicio que utiliza corosync (pacemaker en nuestro caso) y ver indica la versión del servicio que se utiliza, en nuestro caso la versión 1 de pacemaker, correspondiente a cualquier versión de pacemaker 1.X.

El fichero authkey.

El fichero authkey contiene una clave de autenticación entre los nodos que forman el cluster, de forma que si el valor secauth de la directiva totem{} tiene el valor on, los mensajes se autenticaran utilizando esta clave. La clave debe ser igual en todos los nodos y debe tener como permisos 400 y como usuario y grupo root:root, pues en caso contrario el sistema la considerará invalida.

La clave es generada utilizando el comando:

corosync-keygen

El cual crea directamente el fichero /etc/corosync/authkey.

El comando corosync-keygen debe ser ejecutado desde la consola de un sistema, pues solicita la ayuda del usuario, el cual debe pulsar teclas para que el programa pueda detectar la velocidad de pulsación de cada tecla y con ella, generar entropía suficiente para obtener una clave lo más aleatoria posible.

Como todos los nodos del cluster deben tener la misma clave, esta debe copiarse de un nodo a otro, y debería utilizarse un canal de comunicaciones seguro (ssh por ejemplo).



Configuración de pacemaker.

Como hemos indicado con anterioridad, pacemaker proporciona el control de los recursos en cada uno de los nodos del cluster. Pacemaker esta formado por un amplio conjunto de herramientas, de las cuales las más útiles son:

• crm: Herramienta en línea de comando para la configuración y administración de pacemaker.

• crm_mon: Monitoriza el estado actual de un cluster.

• crm_verify: Verifica la configuración de un cluster e informa de errores y advertencias en la configuración del cluster.

• cibadmin: Proporciona acceso directo a la configuración del cluster.

Cada una de estas herramientas posee un gran conjunto de opciones, pudiendo ver en la tabla siguiente las opciones más destacables y su explicación, para cada de las herramientas, en la siguiente tabla:

Comando Descripción

crm_mon --version Devuelve la versión de pacemaker que se esta ejecutando.

crm_mon -1 Muestra el estado del cluster y sale de la consola.

crm_mon -fo1 Igual que el anterior, pero muestra más información.

crm_verify -L Verifica la consistencia de la configuración utilizada en la ejecución del cluster.

crm_verify -L -VVVV Igual que el anterior, pero ofrece más información.

crm_verify --xml-file <fichero.xml> Chequea la consistencia de un fichero de configuración.

cibadmin -Q Muestra la configuración en formato xml.

cibadmin --replace --xml-file <fichero.xml> Sustituye el fichero de configuración existente por otro proporcionado.

crm status Muestra el estado del cluster.

crm configure Entra en la línea de comandos para configurar el cluster.

crm configure show Muestra la configuración actual del cluster.



crm configure edit Muestra el fichero xml de configuración para editarlo directamente.

crm configure erase Borra toda la configuración del cluster.

crm node {online|standby} Activa o para un nodo del cluster.

crm configure delete <recurso> Borra un recurso del cluster.

crm resource {start|stop} <recurso> Arranca o para un recurso del cluster.

crm resource cleanup <recurso> Elimina la información de error de un recurso del cluster.

El fichero de configuración de pacemaker se encuentra en /var/lib/heartbeat/crm/cib.xml, aunque por su complejidad nunca debe editarse directamente, sino que debe utilizarse uno de los comandos explicados con anterioridad para su manejo.

Inicialmente, cuando se crea un cluster con corosync, los nodos que forman parte del cluster, así como otros parámetros, se encuentran configurados por defecto, podemos ver estos valores iniciales ejecutando el comando crm configure show, obteniendo como salida:

node nodo1node nodo2property $id="cib-bootstrap-options" \

dc-version="1.1.7-1.fc15-ee0730e13d124c3d58f00016c3376a1de5323cff" \

cluster-infrastructure="openais"

Donde podemos ver como aparece que pacemaker conoce los dos nodos del cluster que estamos creando, pues esta información se la facilita corosync, así como la versión de pacemaker que utiliza y la aplicación que provee la infraestructura del cluster.

Si chequeamos ahora la consistencia de nuestra configuración, mediante el comando crm_verify -L obtenemos:

crm_verify[1542]: 2012/05/09_11:51:42 ERROR: unpack_resources: Resource start-up disabled since no STONITH resources have been defined crm_verify[1542]: 2012/05/09_11:51:42 ERROR: unpack_resources: Either configure some or disable STONITH with the stonith-enabled option crm_verify[1542]: 2012/05/09_11:51:42 ERROR: unpack_resources: NOTE: Clusters with shared data need STONITH to ensure data integrity Errors found during check: config not valid

Los errores que aparecen al chequear la configuración son debidos a la configuración de stonith. Stonith es un componente de pacemaker que se encarga de reiniciar un nodo cuando se encuentra en un estado indeterminado y que debe ser configurado junto con pacemaker. Como stonith no esta configurado, pero esta activo,



pacemaker reconoce este hecho como un error e informa del mismo. Por ello, debemos desactivar stonith mediante el comando:

crm configure property stonith-enabled=false

Una vez configurado correctamente pacemaker, suele ser recomendable configurar stonith y activar el mismo poniendo el valor anterior a true3.

Una vez desactivado stonith, debemos empezar a configurar algunas propiedades básicas de un cluster.

La primera propiedad básica a configurar es el quorum y el comportamiento ante un fallo del quorum. Se dice que un cluster tiene quorum cuando más de la mitad de los nodos que forman el cluster esta online, de forma que pacemaker, si un cluster no tiene quorum detiene todos los servicios del mismo para evitar una posible corrupción de datos. En nuestro caso, como el cluster esta formado por dos nodos y deseamos alta disponibilidad, no podemos permitir este comportamiento de pacemaker, por lo que deberemos ejecutar los comandos:

crm configure property expected-quorum-votes="2"crm configure property no-quorum-policy=ignore

De forma que le indicamos que el quorum de nuestro cluster esta formado por dos votos (nodos) y que ignore el hecho de que no exista quorum, por lo que seguirá ofreciendo sus recursos aún con un solo nodo en el cluster, pues deseamos alta disponibilidad y, por tanto, carece de sentido que deje de ofrecer sus servicios por problemas en uno de los nodos.

Otra propiedad que es necesario configurar es el comportamiento de los recursos en los nodos, debemos configurar como se deben repartir los recursos dentro de los nodos cuando se incorporen nuevos nodos al cluster, al haber sido arrancado un nodo del cluster, por ejemplo.

El reparto de los recursos en los nodos se realiza con la propiedad rsc_defaults resource-stickiness, que puede tomar los valores que se muestran en la siguiente tabla:

Valor Descripción

0 (cero) Los recursos se moverán de un nodo a otro en función de la carga en cada momento.

>0 (mayor que cero) Los recursos permanecerán en el nodo actual, pero puede moverse a otro nodo cuando se considere necesario. Cuando más alto es el valor menor probabilidad de que algún recurso se mueva a otro nodo.

<0 (menor que cero) Los recursos tienen preferencia a moverse a otro nodo cuando se considere necesario. Cuanto mayor valor absoluto, mayor probabilidad de que algún recurso se mueva a otro nodo.

3 La configuración de stonith no se verá en estos apuntes, pues un cluster puede funcionar con stonith desactivado, perdiendo unicamente seguridad en el funcionamiento del cluster, pues los nodos no se reinician de forma automática y deben ser reiniciados manualmente si se produce algún error.



INFINITY Los recursos se quedarán en los nodos en los que se encuentran, y solo abandonaran los nodos ante un fallo en los mismos.

-INFINITY Los recursos se moverán siempre de su ubicación actual.

Por otro lado, la propiedad symmetric-cluster de pacemaker indica si los recursos del cluster pueden arrancarse en cualquier nodo del mismo (valor true) o debe indicarse explícitamente el nodo donde debe arrancarse (valor false). Como nosotros deseamos configurar un cluster de alta disponibilidad en el que los recursos deben arrancarse en cualquiera de los nodos, configuraremos el cluster como:

crm configure property rsc_defaults resource-stickiness="INFINITY"crm configure property symetric-cluster="true"

Si comprobamos ahora la configuración con el comando crm configure show, obtenemos como salida:

node nodo1 node nodo2property $id="cib-bootstrap-options" \


cluster-infrastructure="openais" \stonith-enabled="false" \ expected-quorum-votes="2" \ no-quorum-policy="ignore" \

symmetric-cluster="true"rsc_defaults $id="rsc-options" \

resource-stickiness="INFINITY"

La configuración de los recursos se realiza de acuerdo a la sintaxis:

crm configure primitive <recurso> [<class>:[<provider>:]]<type> [params <param>=<valor>[<param>=<valor>]] [meta <atributo>=<valor> [<atributo>=<valor>]] [utilization <atributo>=<valor> [<atributo>=<valor>]] [operations id_spec [op tipo [<atributo>=<value>]]]

Donde se puede observar que el único requisito es el nombre que tendrá el recurso <recurso> que estamos configurando y el tipo <type> del recurso, que corresponde con el nombre del script que se llamará para iniciar y terminar ese recurso. El resto de elementos son opcionales y son necesarios o no según el recurso que estemos configurando, variando además el número de atributos que utilizan.

De los elementos opcionales, la clase <class> especifica la clase del recurso que estamos creando. Existen cuatro clases posibles:

• ocf: Open Cluster Framework, que son recursos cuyo script de inicio son una extensión de la convención Linux Standard Base para scripts de inicio, de forma que los valores devueltos, etc., corresponden correctamente con los valores de retorno esperados por pacemaker y por tanto son los scripts preferibles para su uso con pacemaker.



• lsb: Linux Standard Base, que son los scripts de inicio que posee el sistema, están situados generalmente en /etc/rc.d/init.d. Pueden dar problemas al no respetar los estándares de pacemaker sobre códigos de retorno, etc.

• heartbeat: Scripts que provienen de heartbeat4 y que aún continúan usándose.

• stonith: Usados exclusivamente para la comunicación con recursos relacionados con stonith.

Los recursos existentes dentro de cada clase pueden ser listados utilizando el comando:

crm ra list <clase>

Los tipos de recursos pueden ser proveídos por distintos proveedores, pudiendo encontrarse un recurso en más de un proveedor.

Dentro de una clase, pueden existir varios proveedores distintos que proporcionen recursos para la misma clase. Por ello, el parámetro <provider> permite elegir el proveedor que deseamos utilizar. Los proveedores existentes para la clase ocf se encuentran dentro del directorio /usr/lib/ocf/resource.d, donde podemos ver que aparecen tres proveedores distintos, heartbeat, pacemaker y redhat. Si se desean ver los recursos dentro de cada clase y proveedor puede ejecutarse el comando:

crm ra list <clase> <proveedor>

Y se mostrarán los recursos que provee ese proveedor dentro de la clase indicada.

El resto de valores opcionales son utilizados o no según el tipo de script que se utilice, poseyendo un número variable de opciones, etc. Si se desea ver todos los valores de configuración, etc., que pueden usarse para un determinado tipo de script se puede ejecutar el comando:

crm ra info <clase>:<proveedor>:<tipo>

Por ejemplo, si ejecutamos crm ra info ocf:heartbeat:IPaddr2 obtenemos como respuesta:

Manages virtual IPv4 addresses (Linux specific version) (ocf:heartbeat:IPaddr2)

This Linux-specific resource manages IP alias IP addresses. It can add an IP alias, or remove one. In addition, it can implement Cluster Alias IP functionality if invoked as a clone resource.

Parameters (* denotes required, [] the default): ip* (string): IPv4 address

4 Heartbeat es otro paquete de software que permite configurar alta disponibilidad entre sistemas, aunque es menos completo que corosync.



The IPv4 address to be configured in dotted quad notation, for example "192.168.1.1". ...

Obteniendo información sobre para que sirve cada uno de los tipos, el uso de los mismos así como el resto de elementos que se necesitan. Por ejemplo, para configurar la dirección IP flotante del cluster sería necesario ejecutar el comando:

crm configure primitive ClusterIP ocf:heartbeat:IPaddr2 params ip="10.0.0.3" cidr_netmask="24" op monitor interval="30s"

Donde le estamos indicando que el recurso se llama ClusterIP, es de la clase ocf y el proveedor es heartbeat, siendo del tipo IPaddr2. Sus parámetros son la dirección IP flotante a asignar, la máscara de red de esa subred (hemos supuesto una subred /24) y que se monitorice cada 30 segundos.

De igual forma podemos definir otros recursos, como por ejemplo el uso de un recurso de DRBD para que los dos nodos compartan información. Para ello utilizamos el comando:

crm configure primitive DrbdDisk ocf:redhat:drbd.sh params resource="drbd0"

Donde hemos definido un recurso que se llama DrbdDisk, es de la clase ocf, proveedor redhat y tipo drbd.sh y tiene como parámetro que el recurso es drbd0, pues suponemos que este es el nombre del recurso compartido5.

Si a continuación ejecutamos el comando:

crm configure primitive fileSys ocf:heartbeat:Filesystem params device="/dev/drbd0" directory="/var/lib/mysql" fstype="ext3" op start interval="0" timeout="60s" op stop interval="0" timeout="60s"

Estamos definiendo un recurso llamado fileSys que podrá montar el recurso DRBD que hemos definido en el paso anterior. Podemos ver que le hemos pasado el dispositivo a montar (/dev/drbd0), el directorio donde debe montar ese dispositivo (/var/lib/mysql) así como el tipo de fichero (ext3). Como opciones le hemos indicado que tiene 60 segundos para montar y desmontar el sistema de ficheros, dando error en caso de que en ese tiempo no lo haya conseguido.

Podemos ahora indicar que nuestro cluster va a utilizar una base de datos MySQL, y que por tanto debe ejecutar el MySQL mediante el comando:

crm configure primitive Mysql lsb:mysqld

Donde hemos definido un recurso Mysql que se arranca mediante el script estándar de sistema mysqld.

Podríamos seguir definiendo recursos, etc., y en cualquier caso se realizaría de forma similar a los ejemplos que hemos visto, por lo que no vale la pena incidir en más

5 Consultar en el tema de servicios de raid en red los nombres de los recursos.



ejemplos, pudiendo encontrarse información de los parámetros, etc., de cada recurso tal y como se ha comentado con anterioridad.

Una vez hemos definido todos los recursos del cluster existen dos problemas que debemos resolver para que el cluster de alta disponibilidad pueda funcionar de forma correcta.

El primero de estos problemas es indicar que todos los recursos deben ejecutarse en el mismo nodo del cluster, pues para el cluster cada recurso es inicialmente independiente de los otros, por lo que puede decidir asignar la dirección IP a un nodo del cluster, el DRBD a otro nodo del cluster e intentar montar el sistema de ficheros de DRBD en un tercer nodo del cluster (si existiera un tercer nodo). Por tanto, es necesario indicarle los nodos donde deben arrancar los recursos del cluster. Esto se realiza mediante el comando:

crm configure colocation Grupo inf: ClusterIP DrbdDisk fileSys Mysql

Donde le decimos que los recursos que hemos llamado ClusterIP, DrbdDisk, fileSys y Mysql forman una agrupación (colocation), que hemos llamado Grupo, y que por tanto deben ser ejecutados todos ellos en el mismo nodo del cluster.

El segundo de los problemas es el orden en que se arrancan y terminan los recursos. Si, por ejemplo, el sistema intenta montar antes el sistema de ficheros de DRBD antes de que el DRBD haya sido puesto en estado primario se producirá obviamente un error, por lo que es necesario indicarle el orden de arranque y parada de los recursos del cluster. Esto se soluciona con el comando:

crm configure order Orden inf: ClusterIP DrbdDisk fileSys Mysql

Donde hemos definido un recurso llamado Orden que configura el orden (order) de arranque y parada de los recursos, de forma que el orden de arranque es el indicado, esto es, primero ClusterIP, luego DrbdDisk, luego fileSys y por último Mysql.

Una vez hemos configurado el sistema, si ejecutamos el comando crm configure show obtenemos como salida:

node nodo1 \ attributes standby="on"

node nodo2 \ attributes standby="on"

primitive ClusterIP ocf:heartbeat:IPaddr2 \ params ip="10.0.0.3" cidr_netmask="23" \ op monitor interval="30s"

primitive DrbdDisk ocf:redhat:drbd.sh \ params resource="drbd0"

primitive Mysql lsb:mysqld primitive fileSys ocf:heartbeat:Filesystem \

params device="/dev/drbd0" directory="/var/lib/mysql" fstype="ext3" \

op start interval="0" timeout="60s" \ op stop interval="0" timeout="60s"



colocation Grupo inf: ClusterIP DrbdDisk fileSys Mysqlorder Orden inf: ClusterIP DrbdDisk fileSys Mysqlproperty $id="cib-bootstrap-options" \


cluster-infrastructure="openais" \ expected-quorum-votes="2" \ stonith-enabled="false" \ no-quorum-policy="ignore" \ symmetric-cluster="true" \ last-lrm-refresh="1335536629"

rsc_defaults $id="rsc-options" \ resource-stickiness="INFINITY"

Donde podemos ver la configuración actual del sistema.

Funcionamiento del cluster.

Una vez configurado el cluster, podemos ver el estado del mismo mediante el comando:

crm status

Si ejecutamos el mismo obtendremos como salida:

============ Last updated: Wed May 9 17:33:28 2012 Last change: Wed May 9 17:32:05 2012 via crm_attribute on nodo1Stack: openais Current DC: nodo1 - partition with quorum Version: 1.1.7-1.fc15-ee0730e13d124c3d58f00016c3376a1de5323cff 2 Nodes configured, 2 expected votes 4 Resources configured. ============

Node nodo1: standby Node nodo2: standby

Indicando que tenemos configurados 2 nodos y 4 recursos. Además, los dos nodos se encuentran en estado de standby (parados), por lo que los recursos del cluster no se encuentran disponibles.

Si deseamos arrancar el nodo en el que nos encontramos (suponemos nodo1) ejecutamos el comando:

crm node online

Y comprobamos, ejecutando otra vez el comando crm status, que el estado actual es:

============ Last updated: Wed May 9 17:38:15 2012 Last change: Wed May 9 17:37:45 2012 via crm_attribute on nodo1



Stack: openais Current DC: nodo1 - partition with quorum Version: 1.1.7-1.fc15-ee0730e13d124c3d58f00016c3376a1de5323cff 2 Nodes configured, 2 expected votes 4 Resources configured. ============

Node nodo2: standby Online: [ nodo1 ]

ClusterIP (ocf::heartbeat:IPaddr2): Started nodo1 DrbdDisk (ocf::redhat:drbd.sh): Started nodo1 fileSys (ocf::heartbeat:Filesystem): Started nodo1 Mysql (lsb:mysqld): Started nodo1

Pudiendo comprobar como nodo1 ha pasado a estar activo y nodo2 continua en estado parado, habiendo tomado nodo1 los recursos del cluster.

Si ahora ejecutamos en nodo2 el comando crm node online y con posterioridad volvemos a ejecutar el comando crm status obtenemos:

============ Last updated: Wed May 9 17:42:04 2012 Last change: Wed May 9 17:37:45 2012 via crm_attribute on nodo1 Stack: openais Current DC: nodo1 - partition with quorum Version: 1.1.7-1.fc15-ee0730e13d124c3d58f00016c3376a1de5323cff 2 Nodes configured, 2 expected votes 4 Resources configured. ============

Online: [ nodo1 nodo2 ]


Pudiendo ver como ambos nodos están en estado activo y por tanto forman parte del cluster, pero como los recursos continua teniéndolos nodo1, pues forman un grupo y además hemos indicado que el cluster es simétrico y no deben cambiarse los recursos de un nodo a otro.

Si ahora simulamos un fallo en nodo1, lo cual puede hacerse parando ese nodo mediante el comando6:

crm node standby

6 Es posible simular un fallo más traumático que el aquí expuesto apagando el equipo de forma súbita, por ejemplo quitando la alimentación, pues un fallo simulado con un rearranque del equipo es similar al que aquí realizamos, pues el sistema al apagarse ejecutara los scripts de parada de corosync y pacemaker y por tanto parará de forma controlada el nodo. De todas formas no resulta recomendable realizar la simulación traumática, pues puede afectar a los sistemas de ficheros, etc., del ordenador.



Y esperamos unos segundos, podemos ver como los recursos son transferidos al nodo2, tal y como muestra ahora la salida del comando crm status:

============ Last updated: Wed May 9 17:46:48 2012 Last change: Wed May 9 17:46:03 2012 via crm_attribute on nodo1Stack: openais Current DC: nodo1 - partition with quorum Version: 1.1.7-1.fc15-ee0730e13d124c3d58f00016c3376a1de5323cff 2 Nodes configured, 2 expected votes 4 Resources configured. ============

Node nodo1: standby Online: [ nodo2 ]


Si ahora volvemos a poner activo nodo1, los servicios continuaran siendo proporcionados por nodo2 por lo comentado con anterioridad.


Cluster Resource Manager

Documents

Transcript of Cluster Resource Manager