Administracin y Gestin de Redes

Servicios de alta disponibilidad

Servicios de alta disponibilidad.

Autores: Enrique V. Bonet Esteban / Susana Pons Sospedra

Introduccin.
La alta disponibilidad es la capacidad de ofrecer un conjunto de servicios sobre un sistema informtico 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 an cuando se produzca una degradacin 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 trminos 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 migracin 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 recuperacin (checkpoint). Un servicio de comunicacin entre los nodos de cluster. Un sistema de monitorizacin para la deteccin de errores en el servidor.

Adems, y de forma general, todos los cluster poseen un sistema de almacenamiento que permite el acceso a la informacin 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 comunicacin 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 start service pacemaker start

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

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

Ingeniera Tcnica en Telecomunicacin Especialidad en Telemtica

Administracin y Gestin de Redes

Servicios de alta disponibilidad

En el ejemplo de configuracin 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 adems que ambos nodos tienen dos interfaces de red, correspondiendo eth0 a una direccin de red privada (192.168.0.1 para nodo1 y 192.168.0.2 para nodo2) y eth1 a una direccin de red pblica (10.0.0.1 para nodo1 y 10.0.0.2 para nodo2). Adems, ambos nodos tienen un interfaz serie /dev/ttyS0 disponible. Por otra parte, suponemos que la direccin pblica flotante del cluster es 10.0.0.3.

Configuracin de corosync
Como hemos comentado, corosync es el paquete que se encarga de proporcionar la comunicacin entre los nodos del cluster. Para ello, utiliza direcciones multicast de forma que todos los nodos que forman un cluster utilizan la misma direccin 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 comunicacin entre los nodos se implementa mediante dos servicios, un servicio de eventos que enva los eventos que suceden a todos aquellos nodos que se han suscrito, y un servicio de mensajes que enva 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.

Ingeniera Tcnica en Telecomunicacin Especialidad en Telemtica

Administracin y Gestin de Redes

Servicios de alta disponibilidad

El fichero corosync.conf.
El fichero corosync.conf esta formado por lneas que configuran directivas las cuales contienen instrucciones sobre el funcionamiento de corosync en su interior. Toda lnea en blanco o que comienza por el carcter # es ignorada. Las directivas pueden ser de cuatro tipos: totem {}: Directivas que configuran opciones de configuracin de la comunicacin del cluster. logging {}: Directivas que configuran opciones de log de la aplicacin. 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.

Adems, al principio puede especificarse el parmetro compatibility para indicar el nivel de compatibilidad requerido por el usuario, de forma que se pueda especificar con que versin anterior de corosync debe ser compatible el funcionamiento de la versin 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
Ingeniera Tcnica en Telecomunicacin Especialidad en Telemtica 3

Administracin y Gestin de Redes

Servicios de alta disponibilidad

debug: off } amf { } mode: disabled }

En el ejemplo podemos ver, en primer lugar, la opcin de compatibilidad (compatibility). Esta opcin 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 continuacin podemos observar tres directivas, totem{}, logging{} y amf{}. La directiva totem{}, que como hemos indicado configura el modo de funcionamiento de la comunicacin del cluster, contiene en este caso los valores2: version: Versin del fichero de configuracin. 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 nmero 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 mnimo una vez dentro de cada directiva totem{}. Esta subdirectiva configura las opciones de red de corosync. Sus valores son: ringnumber: Especifica el nmero del anillo al que pertenece el interface dentro de la configuracin. Cada interface de una directiva totem{} debe poseer un nmero diferente, indicando el nmero la prioridad del interface, de forma que el valor 0 indicara el primario, el valor 1 el de backup, etc. bindnetaddr: Indica la direccin que identifica la red en la que se ejecuta corosync. Por ejemplo, si la direccin de red del interface es 192.168.0.1 con mscara /24, debe ponerse 192.168.0.0, que es la direccin que corresponde a la red (nuestro ejemplo). Si la direccin es 192.168.0.73 con mscara /26 debe ponerse 192.168.0.64. mcastaddr: Direccin multicast a la que enva corosync los mensajes. En nuestro ejemplo estamos usando 226.95.1.1.

Una descripcin detallada de todas las opciones existentes puede encontrarse en las pginas del manual del sistema. Ingeniera Tcnica en Telecomunicacin Especialidad en Telemtica 4

Administracin y Gestin de Redes

Servicios de alta disponibilidad

mcastport: Conjunto de puertos que utiliza corosync para enviar y recibir los paquetes multicast. El puerto UDP de recepcin es el indicado por el valor mcastport y el puerto de envo 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 configuracin que haga que la unin 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 difusin de los mensajes a otras subredes. La directiva logging{} contiene en nuestro caso los valores: fileline: Indica si el nombre del fichero y la lnea 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 enve al lugar especificado para la salida estndar de error. Su valor por defecto es yes, aunque en nuestro ejemplo se encuentra a no. to_logfile: Especifica que el log se enve a un fichero, cuya localizacin 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 enva al syslog del sistema (valor yes) o no (valor no). El valor por defecto es yes. logfile: Indica el nombre del fichero donde se escribirn los log del sistema si la opcin to_logfile tiene valor yes. En nuestro ejemplo le hemos asignado el valor /var/log/cluster/corosync.log. debug: Indica si se activa la opcin de depuracin (valor yes) o no (valor no), que es el valor por defecto. La activacin obliga a corosync a escribir logs ms detallados, siendo til en depuracin de la configuracin. timestamp: Especifica si se escribe la hora del sistema antes de cada lnea 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).

Ingeniera Tcnica en Telecomunicacin Especialidad en Telemtica

Administracin y Gestin de Redes

Servicios de alta disponibilidad

subsys: Es un parmetro requerido por la subdirectiva logger_subsys{} e indica sobre que subsistema se aplica la modificacin. En nuestro caso el subsistema es Availability Management Framework (AMF). debug: Valor de la opcin de depuracin 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 opcin 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 todava 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 lneas:
service { name: pacemaker ver: 1 }

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

El fichero authkey.
El fichero authkey contiene una clave de autenticacin 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 pulsacin de cada tecla y con ella, generar entropa suficiente para obtener una clave lo ms aleatoria posible. Como todos los nodos del cluster deben tener la misma clave, esta debe copiarse de un nodo a otro, y debera utilizarse un canal de comunicaciones seguro (ssh por ejemplo).
Ingeniera Tcnica en Telecomunicacin Especialidad en Telemtica 6

Administracin y Gestin de Redes

Servicios de alta disponibilidad

Configuracin 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 ms tiles son: crm: Herramienta en lnea de comando para la configuracin y administracin de pacemaker. crm_mon: Monitoriza el estado actual de un cluster. crm_verify: Verifica la configuracin de un cluster e informa de errores y advertencias en la configuracin del cluster. cibadmin: Proporciona acceso directo a la configuracin del cluster.

Cada una de estas herramientas posee un gran conjunto de opciones, pudiendo ver en la tabla siguiente las opciones ms destacables y su explicacin, para cada de las herramientas, en la siguiente tabla: Comando crm_mon --version crm_mon -1 crm_mon -fo1 crm_verify -L Descripcin Devuelve la versin de pacemaker que se esta ejecutando. Muestra el estado del cluster y sale de la consola. Igual que el anterior, pero muestra ms informacin. Verifica la consistencia de la configuracin utilizada en la ejecucin del cluster. Igual que el anterior, pero ofrece ms informacin. Chequea la consistencia de un fichero de configuracin. Muestra la configuracin en formato xml.

crm_verify -L -VVVV crm_verify --xml-file <fichero.xml> cibadmin -Q

cibadmin --replace --xml-file <fichero.xml> Sustituye el fichero de configuracin existente por otro proporcionado. crm status crm configure crm configure show Muestra el estado del cluster. Entra en la lnea de comandos para configurar el cluster. Muestra la configuracin actual del cluster.
7

Ingeniera Tcnica en Telecomunicacin Especialidad en Telemtica

Administracin y Gestin de Redes

Servicios de alta disponibilidad

crm configure edit crm configure erase crm node {online|standby} crm configure delete <recurso> crm resource {start|stop} <recurso> crm resource cleanup <recurso>

Muestra el fichero xml de configuracin para editarlo directamente. Borra toda la configuracin del cluster. Activa o para un nodo del cluster. Borra un recurso del cluster. Arranca o para un recurso del cluster. Elimina la informacin de error de un recurso del cluster.

El fichero de configuracin 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 parmetros, se encuentran configurados por defecto, podemos ver estos valores iniciales ejecutando el comando crm configure show, obteniendo como salida:
node nodo1 node nodo2 property $id="cib-bootstrap-options" \ dc-version="1.1.7-1.fc15ee0730e13d124c3d58f00016c3376a1de5323cff" \ cluster-infrastructure="openais"

Donde podemos ver como aparece que pacemaker conoce los dos nodos del cluster que estamos creando, pues esta informacin se la facilita corosync, as como la versin de pacemaker que utiliza y la aplicacin que provee la infraestructura del cluster. Si chequeamos ahora la consistencia de nuestra configuracin, 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 stonithenabled 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 configuracin son debidos a la configuracin 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,
Ingeniera Tcnica en Telecomunicacin Especialidad en Telemtica 8

Administracin y Gestin de Redes

Servicios de alta disponibilidad

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 bsicas de un cluster. La primera propiedad bsica a configurar es el quorum y el comportamiento ante un fallo del quorum. Se dice que un cluster tiene quorum cuando ms 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 corrupcin 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 an 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 0 (cero) Descripcin Los recursos se movern de un nodo a otro en funcin de la carga en cada momento.

>0 (mayor que cero) Los recursos permanecern en el nodo actual, pero puede moverse a otro nodo cuando se considere necesario. Cuando ms alto es el valor menor probabilidad de que algn 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 algn recurso se mueva a otro nodo.
3

La configuracin 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 automtica y deben ser reiniciados manualmente si se produce algn error. Ingeniera Tcnica en Telecomunicacin Especialidad en Telemtica 9

Administracin y Gestin de Redes

Servicios de alta disponibilidad

INFINITY -INFINITY

Los recursos se quedarn en los nodos en los que se encuentran, y solo abandonaran los nodos ante un fallo en los mismos. Los recursos se movern siempre de su ubicacin 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 explcitamente 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 configuracin con el comando crm configure show, obtenemos como salida:
node nodo1 node nodo2 property $id="cib-bootstrap-options" \ dc-version="1.1.7-1.fc15ee0730e13d124c3d58f00016c3376a1de5323cff" \ 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 configuracin 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 segn el recurso que estemos configurando, variando adems el nmero 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 extensin de la convencin 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.
10

Ingeniera Tcnica en Telecomunicacin Especialidad en Telemtica

Administracin y Gestin de Redes

Servicios de alta disponibilidad

lsb: Linux Standard Base, que son los scripts de inicio que posee el sistema, estn situados generalmente en /etc/rc.d/init.d. Pueden dar problemas al no respetar los estndares de pacemaker sobre cdigos de retorno, etc. heartbeat: Scripts que provienen de heartbeat4 y que an continan usndose. stonith: Usados exclusivamente para la comunicacin 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 provedos por distintos proveedores, pudiendo encontrarse un recurso en ms de un proveedor. Dentro de una clase, pueden existir varios proveedores distintos que proporcionen recursos para la misma clase. Por ello, el parmetro <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 mostrarn los recursos que provee ese proveedor dentro de la clase indicada. El resto de valores opcionales son utilizados o no segn el tipo de script que se utilice, poseyendo un nmero variable de opciones, etc. Si se desea ver todos los valores de configuracin, 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. Ingeniera Tcnica en Telecomunicacin Especialidad en Telemtica 11

Administracin y Gestin de Redes

Servicios de alta disponibilidad

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

Obteniendo informacin 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 direccin IP flotante del cluster sera 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 parmetros son la direccin IP flotante a asignar, la mscara 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 informacin. Para ello utilizamos el comando:
crm configure primitive resource="drbd0" DrbdDisk ocf:redhat:drbd.sh params

Donde hemos definido un recurso que se llama DrbdDisk, es de la clase ocf, proveedor redhat y tipo drbd.sh y tiene como parmetro que el recurso es drbd0, pues suponemos que este es el nombre del recurso compartido5. Si a continuacin 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 estndar de sistema mysqld. Podramos seguir definiendo recursos, etc., y en cualquier caso se realizara de forma similar a los ejemplos que hemos visto, por lo que no vale la pena incidir en ms
5

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

Ingeniera Tcnica en Telecomunicacin Especialidad en Telemtica

Administracin y Gestin de Redes

Servicios de alta disponibilidad

ejemplos, pudiendo encontrarse informacin de los parmetros, 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 direccin 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 agrupacin (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"
Ingeniera Tcnica en Telecomunicacin Especialidad en Telemtica 13

Administracin y Gestin de Redes

Servicios de alta disponibilidad

colocation Grupo inf: ClusterIP DrbdDisk fileSys Mysql order Orden inf: ClusterIP DrbdDisk fileSys Mysql property $id="cib-bootstrap-options" \ dc-version="1.1.7-1.fc15ee0730e13d124c3d58f00016c3376a1de5323cff" \ 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 configuracin 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 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 nodo1: standby Node nodo2: standby

Indicando que tenemos configurados 2 nodos y 4 recursos. Adems, 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
Ingeniera Tcnica en Telecomunicacin Especialidad en Telemtica 14

Administracin y Gestin de Redes

Servicios de alta disponibilidad

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 DrbdDisk fileSys Mysql (ocf::heartbeat:IPaddr2): Started nodo1 (ocf::redhat:drbd.sh): Started nodo1 (ocf::heartbeat:Filesystem): Started nodo1 (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 ] ClusterIP DrbdDisk fileSys Mysql (ocf::heartbeat:IPaddr2): Started nodo1 (ocf::redhat:drbd.sh): Started nodo1 (ocf::heartbeat:Filesystem): Started nodo1 (lsb:mysqld): Started nodo1

Pudiendo ver como ambos nodos estn en estado activo y por tanto forman parte del cluster, pero como los recursos continua tenindolos nodo1, pues forman un grupo y adems hemos indicado que el cluster es simtrico 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

Es posible simular un fallo ms traumtico que el aqu expuesto apagando el equipo de forma sbita, por ejemplo quitando la alimentacin, 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 simulacin traumtica, pues puede afectar a los sistemas de ficheros, etc., del ordenador. Ingeniera Tcnica en Telecomunicacin Especialidad en Telemtica 15

Administracin y Gestin de Redes

Servicios de alta disponibilidad

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 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 nodo1: standby Online: [ nodo2 ] ClusterIP (ocf::heartbeat:IPaddr2): Started nodo2 DrbdDisk (ocf::redhat:drbd.sh): Started nodo2 fileSys (ocf::heartbeat:Filesystem): Started nodo2 Mysql (lsb:mysqld): Started nodo2 Si ahora volvemos a poner activo nodo1, los servicios continuaran siendo proporcionados por nodo2 por lo comentado con anterioridad.

Ingeniera Tcnica en Telecomunicacin Especialidad en Telemtica

16