Construcción y utilización de un cluster con Heartbeat y DRDB (mini how-to)

Transcripción

1 Construcción y utilización de un cluster con Heartbeat y DRDB (mini how-to) M. Besio P. García E. Gómez Balaguer D. Marqués I. Scena 18 de noviembre de Introducción Ciertas aplicaciones requieren que el tiempo en que los recursos de un servidor no se encuentran disponibles sea mínimo. Por ejemplo, para un sito web de ecommerce resulta inaceptable estar fuera del aire por períodos incluso breves. Ya sea por fallas de software o hardware, o por actualizaciones críticas que requieren poner offline el servidor, debe encontrarse una solución para que no se pierda la disponibilidad de los recursos. A tal fin existen los clusteres de alta disponibilidad (High-Availability clusters) o HA por su sigla en inglés. Un HA típico consta de dos servidores (nodos), donde ambos conocen a través de un enlace (llamado heartbeat) el estado del otro. En caso de detectarse una falla, el servidor que no ha fallado reemplaza automáticamente y sin intervención al que ha fallado en sus tareas. Existen dos grandes formas de operar un cluster HA: modo activo/pasivo o modo activo/activo. En el modo activo/pasivo, uno de los dos nodos se encuentra en estado de espera por una falla del otro, que es el único que sirve recursos. En caso de fallar, el que se encontraba pasivo pasa a ser activo. Por el contrario, en el modo activo/activo ambos servidores sirven recursos, distintos entre sí. En este caso debe tenerse en cuenta que como en estado normal ningún servidor sirve la carga total, en caso de falla cualquiera de ambos deberá poder tolerar el total de tráfico. 2. Entorno El cluster de pruebas configurado utiliza dos nodos, ambos con Ubuntu, conjuntamente con los software Heartbeat y DRDB de Linux-HA. Dicho 1

2 cluster corre un servidor Tomcat en el cual se hostea un sitio web que almacena pares (título, texto) en disco, y permite recuperar el texto a partir del título. Existe un enlace privado para heartbeat, con dirección IP /24 en el nodo 1, y /24 en el nodo 2. Cada nodo a su vez posee un enlace público cuya dirección IP es asignada por un DHCP xx/24 para el nodo 1, yy/24 para el nodo 2. El cluster posee una dirección IP virtual /24, a la cual los clientes acceden a través de la red pública configurando debidamente sus tablas de ruteo. 3. DRBD Distributed Replicated Block Device (DRBD) es un software de base, una solución para la replicación del contenido de los dispositivos de bloques (discos duros, particiones) entre los servidores. Caracteristicas de la replicación de DRBD Tiempo real. La replicación se produce en forma continua, mientras las aplicaciones modifican el contenido del dispositivo. Transparencia. Las aplicaciones que guardan sus datos en los dispositivos de replicación pueden olvidarse que los datos son guardados en varios ordenadores. Sincrónica o asincrónica. Con sincronismo, una aplicación es notificada de la finalización de la escritura solo despues que se escribio la información en todos los ordenadores. Asincronitamente la aplicación es notificada de la finalización de la escritura cuando se termina de escribir los datos localmente, pero despues esos datos se replican a los otros ordenadores La funcionalidad basica de DRBD se aplica por medio de un módulo del kernel de linux. En concreto, DRBD constituye un controlador para un dispositivo de bloque virtual, por lo que DRBD se encuentra cerca de la parte inferior de un sistema de I/O, esto se puede ver en la figura 1. Debido a esto, DRBD es extremadamente flexible y versátil, lo que lo convierte en una solución de replicación adecuada para la adición de alta disponibilidad para casi cualquier aplicación. DRBD dispone de dos modos de funcionamiento: Single-primary mode. Sólo un nodo del cluster manipula los datos en cualquier momento, de este modo se puede utilizar con cualquier sistema de archivos convencionales. 2

3 Figura 1: Posición de DRBD en el módulo de Linux Dual-primary mode. Esta característica está disponible en DRBD 8.0 y posteriores. El acceso concurrente a los datos es posible, pero este modo requiere el uso compartido de un cluster del sistema de archivos que utiliza un gestor de bloqueo distribuido Instalación En esta sección se muestran los pasos para instalar DRBD en Ubuntu y la versión que se instalo es DRBD 8.1. Para instalar DRBD se deben correr los siguientes comandos desde una consola: apt-get update apt-get install drbd8-utils drbd8-module-source \ build-essential module-assistant module-assistant auto-install drbd Configuración En esta sección se especifican los pasos a seguir para poder configurar de forma íntegra DRBD Preparación de los dispositivos de almacenamiento Luego de instalar DRBD en el sistema, es necesario configurar dos áreas de almacenamiento idénticas en ambos nodos del clúster. Dichas áreas serán 3

4 los dispositivos de bajo nivel utilizados por los recursos que se configuren en DRBD. Los dispositivos elegidos pueden ser cualquier tipo de dispositivo de bloques (una partición, un disco rígido completo, LVM, EVMS, etc). No es necesario que las áreas de almacenamiento estén vacías, ya que si una de ellas contiene información útil (por ejemplo, proveniente de un cluster no redundante) que quiera replicarse a través de DRBD, se lo puede hacer sincronizando ambos nodos, tal como se explicará más adelante. Para este howto, se utilizaron dos particiones nuevas (una en cada nodo del cluster activo/pasivo), de 100MB con el nombre /dev/sda5. Para que DRBD sea quien monte el recurso en el nodo activo cuando corresponda, se debe ingresar en el archivo /etc/fstab de ambos nodos, la siguiente información: <filesystem>: /dev/drbd0 (drbd0 es el nombre dado al recurso, tal como se explica en la sección 3.2.3) <mount point>: /drbd <type>: ext3 (se eligió ext3 en este caso pero el filesystem puede ser otro) <optons>: noauto (para que no se monte automáticamente, sino que sea DRBD quien lo haga cuando sea necesario) <dmp>: 0 <pass>: Preparación de la configuración de red Es recomendable, aunque no obligatorio, que la replicación de DRBD se corra sobre una conexión Gigabit Ethernet dedicada, con la finalidad de poseer suficiente ancho de banda para poder efectuar la transferencia de información. DRBD utiliza por default a partir del puerto 7788 de TCP. Cada recurso escucha en un puerto separado (comenzando por el 7788 e incrementándose en función de la cantidad de recursos configurados). Para lograr un correcto funcionamiento, es necesario que la configuración del firewall permita dichas conexiones y que no haya otras aplicaciones que hagan uso de dichos puertos. Las direcciones IP e interfaces elegidas en el presente documento se explican en la sección Configuración de recursos (archivo drbd.conf ) Acontinuación se muestra el archivo de configuración de DRBD que en las distribuciones de Ubuntu se encuentra en /etc/drbd.conf. 4

5 # # drbd.conf # # resource drbd0 { # transfer protocol to use. # C: la escritura es reportada como finalizada cuando la misma se # completa en todos los nodos. # B: la escritura es reportada como finalizada cuando la misma se # completa en el nodo local y en el buffer cache de los nodos remotos. # A: la escritura es reportada como finalizada cuando la misma se # completa en el nodo local y en el buffer local de TCP. # Aplica en redes de alta latencia. # Para clusters de alta disponibilidad, el protocolo adecuado es el C protocol C; startup { } net { } syncer { TRADUCIR!!!!!!!!!!!!!! # Configures the size of the active set. Each extent is 4M, # 257 Extents ~> 1GB active set size. In case your syncer # 10MB/sec, all resync after a primary s crash will last # 1GB / ( 10MB/sec ) ~ 102 seconds ~ One Minute and 42 Seconds. # BTW, the hash algorithm works best if the number of al-extents # is prime. (To test the worst case performace use a power of 2) al-extents 257; } on node1 { # Device que se debe usar en la aplicación. Los devices nodes deben tener # el mismo número que los driver de DRBD (en este caso 0). device /dev/drbd0; # DRBD usa este dispositivo para guardar y recuperar los datos. # No se debe acceder al mismo mientras DRBD está accediendo al mismo. disk /dev/sda5; # Ddirección IP del nodo con el puerto en donde se # encuentra escuchando al otro dispositivo para realizar la # sincronización de los datos. address :7788; meta-disk internal; 5

6 TRADUCIR!!!!!!!!!!!!!! # meta-disk is either internal or /dev/ice/name [idx] # # You can use a single block device to store meta-data # of multiple DRBD s. # E.g. use meta-disk /dev/hde6[0]; and meta-disk /dev/hde6[1]; # for two different resources. In this case the meta-disk # would need to be at least 256 MB in size. # # internal means, that the last 128 MB of the lower device # are used to store the meta-data. # You must not give an index with internal. } } on node2 { device /dev/drbd0; disk /dev/sda5; address :7788; meta-disk internal; } Activación de los recursos por primera vez Luego de finalizada la configuración inicial de recursos, deben realizarse en ambos nodos los siguientes pasos: 1. Creación de la metadata (responder que si a los mensajes de advertencia): drbdadm create-md drbd0 2. Asociar el recurso de DRBD con su dispositivo: drbdadm attach drbd0 3. Conectar el recurso de DRBD con el del otro nodo: drbdadm connect drbd0 Los pasos 2 y 3 pueden reducirse a uno solo si se ejecuta el comando drbdadm up drbd0. Para observar el estado de la configuración, puede ejecutarse el comando cat /proc/drbd. A esta altura, la salida debería ser similar a la siguiente: version: 8.1 (api:88/proto:86-88) GIT-hash: 6

7 fc00c6e00a1b6039bfcebe37afa3e7e28dbd92fa build by :44:36 0: cs:connected st:secondary/secondary ds:inconsistent/inconsistent C r--- ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 resync: used:0/31 hits:0 misses:0 starving:0 dirty:0 changed:0 act_log: used:0/257 hits:0 misses:0 starving:0 dirty:0 changed:0 El estado Inconsistent/Inconsistent es esperable en este punto ya que, si bien DRBD ya ha alocado los recursos de disco y de red y está listo para operar, aún no ha sincronizado la información entre los nodos. Para ello debe correrse el siguiente comando en el nodo que posea la información adecuada para realizar la sincronización inicial (los datos que quieran poseerse en el clúster replicado). drbdadm overwrite-data-of-peer primary drbd0 Luego de ejecutada la sentencia anterior, comenzará la sincronización, el progreso de la misma puede monitorearse a través de /proc/drbd (recordar que DRBD se instala como un módulo del kernel de Linux). Además de indicarse que el nodo donde se corre el comando es la fuente de información para llevar a cabo la sincronización, se está indicando que será el nodo que actúe como primario, es decir, en él podrá montarse el filesystem y ser accedido para operaciones de lectura y escritura. El otro nodo, será el secundario, y como el clúster se ha configurado como activo/pasivo, no podrá ser accedido para operaciones de ningún tipo, pero DRBD se encargará de mantener sincronizada su información con la del nodo primario. Cuando el nodo primario sufra alguna falla, el secundario pasará a ocupar el rol de primario y viceversa. Este comportamiento también puede forzarse manualmente, por medio de los comandos: drbdadm primary drbd0 y drbdadm secondary drbd0. 4. Heartbeat Heartbeat es el componente de Linux-HA encargado de detectar la caída de un nodo y gestionar las comunicaciones y administración del cluster. A partir de la versión 2, suma dos funcionalidades de gran importancia: soporte para más de dos nodos y monitoreo de recursos. La primera implica que el tamaño del cluster pasa a ser ilimitado, mientras que la segunda permite establecer no sólo la vida o muerte de un nodo, sino también la vida o muerte de un recurso que ejecuta dicho nodo. Por lo tanto, pueden detectarse problemas que impiden la correcta disponibilidad de los recursos aún si esto no implica la caída del servidor. 7

8 4.1. Instalación Para instalar la versión 2 de Heartbeat en Ubuntu se ejecuta apt-get install heartbeat2 Es de importancia que se respete la versión, ya que la configuración para la versión 1 es diferente (principalmente dado que no incluye funcionalidades para monitoreo de recursos) 4.2. Configuración La configuración de Heartbeat consta de 3 archivos: authkeys, ha.cf y cib.xml 4.3. authkeys El objetivo de este archivo es que los paquetes de Hearbeat estén firmados con una determinada clave, a fin de evitar que un atacante pueda impersonar a Hearbeat inyectando paquetes apócrifos en la red. Posee la estructura siguiente: # este archivo especifica el tipo de autenticación a usar: # crc - baja # md5 - media # sha1 - alta # esta línea especifica cuál será el valor a utilizar del listado # que la sigue. el número que se utiliza debe estar en el principio de # la línea auth 2 # con crc no hace falta espeficar clave alguna 1 crc # con sha1 o md5 sí 2 sha1 clave_del_cluster es decir que se utiliza cifrado SHA-1 y la clave es clave_del_cluster. Es importante que se tengan los permisos correctos sobre authkeys, ejecutar chmod 600 authkeys ha.cf Este es el archivo principal de configuración de Heartbeat, donde la principal especificación es la cantidad de nodos del cluster y las condiciones para considerar muerto a un nodo. Cada nodo posee un archivo ha.cf. Posee la estructura siguiente: 8

9 # archivo ha.cf, debe ser muy parecido en todos los nodos # nombre del archivo a donde van los logs de debug debugfile /var/log/ha-debug # nombre del archivo de logs logfile /var/log/ha-log # tiempo en segundos entre heartbeats keepalive 2 # tiempo de demora de un heartbeat para lanzar un warning (posible muerte del otro nodo) warntime 10 # tiempo de demora para considerar un nodo muerto deadtime 30 # puerto de escucha para heartbeat udpport 694 # tipo de comunicación de los heartbeats: broadcast en eth0 y eth1 (tambien podria ser serial RS232, #por ejemplo) bcast eth0 eth1 # podríaa ser un unicast entre nodos para tener menos tráfico #ucast eth # esta directiva en principio se ignora en la v2 (su finalidad es que los servicios que corren en un nodo # vuelvan a levantarse en dicho nodo si es que #en algún momento murió y posteriormente revivió) #auto_failback on # nombres de los nodos #node node1 #node node2 # en vez de especificar los nombres de los nodos, se usa esta # directiva para que se unan automáticamente, total la autenticación # con psk sha es bastante fuerte autojoin any # nodo a pinguear para chequear conectividad: NO DEBE SER PARTE DEL CLUSTER ping # Manejo de recursos crm yes 4.5. cib.xml Dado que en ha.cf existe la directiva crm yes, se utiliza manejo de recursos. El manejo de recursos es configurado a través del archivo cib.xml, que tiene la estructura siguiente: <cib admin_epoch="0" epoch="0" num_updates="0"> <configuration> <crm_config> <cluster_property_set id="cib-bootstrap-options"> <!-- Opciones globales del cluster --> 9

10 <!-- Timeout para decretar que una transición no pudo ser llevada a cabo (hay un grafo de transiciones para los recursos) --> <nvpair id="cib-bootstrap-options-transition_idle_timeout" name="transition_idle_timeout" value="60s"/> <!-- El cluster es simétrico (todos los recursos pueden correrse en cualquier lado, son 2 vms iguales) --> <nvpair id="cib-bootstrap-options-symmetric_cluster" name="symmetric-cluster" value="true"/> <!-- STONITH: Shoot The Other Node In The Head, ante la duda de que está fallando, le manda un reboot, excepto que esté inciándose. Con esto se pretende evitar que puedan quedar corriendo servicios y en caso de que reviva abruptamente ocurra que por ejemplo ambos nodos quieren escribir el mismo recurso (dado que se pasaron al otro los recursos del muerto) --> <nvpair id="cib-bootstrap-options-stonith_enabled" name="stonith-enabled" value="false"/> <nvpair id="cib-bootstrap-options-stonith_action" name="stonith-action" value="reboot"/> <!-- Dejarlo en true siempre --> <nvpair id="cib-bootstrap-options-startup-fencing" name="startup-fencing" value="true"/> <!-- Si no hay quorum (siempre lo hay por más que sean 2 nodos), parar --> <nvpair id="cib-bootstrap-options-no_quorum_policy" name="no-quorum-policy" value="stop"/> <!-- Cuán apegados son los recursos a sus ubicaciones, 0 es lo normal. default-resource-stickiness=500 (bonus por quedarse donde está). El stickiness determina la probabilidad de que un recurso sea movido a otro nodo en función de, por ejemplo, una política de balanceo de carga --> <nvpair id="cib-bootstrap-options-default_resource_stickiness" name="default-resource-stickiness" value="500"/> <!-- default-resource-failure-stickiness=-1 (cuenta para el cociente de movimiento en caso de fallas repetidas). El failure-stickiness debería ser negativo siempre --> <nvpair id="cib-bootstrap-options-default_resource_failure-stickiness" name="default-resource-failure-stickiness" value="-1"/> <!-- Especifica si los recursos serán administrados (inciados, parados, monitoreados, movidos) según sea necesario o requerido --> <nvpair id="cib-bootstrap-options-is_managed_default" name="is-managed-default" value="true"/> <!-- Especifica si los recursos o acciones que son encontrados para los que no se tiene una definición son detenidos --> <nvpair id="cib-bootstrap-options-stop_orphan_resources" name="stop-orphan-resources" value="true"/> <nvpair id="cib-bootstrap-options-stop_orphan_actions" name="stop-orphan-actions" value="true"/> <!-- remove-after-stop [boolean: default=false]: Remove resources from the LRM after they are stopped Always set this to false. Other values are, at best, poorly tested and potentially dangerous. (del wiki de heartbeat) --> <nvpair id="cib-bootstrap-options-remove_after_stop" name="remove-after-stop" value="false"/> <!-- Sin datos --> <nvpair id="cib-bootstrap-options-short_resource_names" name="short_resource_names" value="true"/> <!-- Cuánto tiempo esperar a que las acciones se completen --> <nvpair id="cib-bootstrap-options-default_action_timeout" name="default-action-timeout" value="20s"/> <!-- Demora en la red del cluster (no cuenta la ejecución de la acción). Es para no decretar que un nodo está muerto cuando hay mucha carga en la red --> <nvpair id="cib-bootstrap-options-cluster-delay" name="cluster-delay" value="60s"/> <!-- Cantidades de errores, warnings, inputs a guardar. -1 = ilimitado --> 10

11 <nvpair id="cib-bootstrap-options-pe-error-series-max" name="pe-error-series-max" value="-1"/> <nvpair id="cib-bootstrap-options-pe-warn-series-max" name="pe-warn-series-max" value="-1"/> <nvpair id="cib-bootstrap-options-pe-input-series-max" name="pe-input-series-max" value="-1"/> </cluster_property_set> </crm_config> <!-- Nodos del cluster (se llenan dinámicamente con la directiva auto_join, pero pueden ser especificados acá) --> <nodes/> <!-- Recursos del cluster que administra o se relacionan con heartbeat --> <resources> <!-- Recurso master/slave: drbd configurado como activo/pasivo. Debe correrse como un clone especial --> <master_slave id="ms-drbd0"> <!-- Parámetros que utiliza heartbeat con este recurso --> <instance_attributes id="ma-ms-drbd0"> <!-- Máxima cantidad de clones en el cluster --> <nvpair id="ma-ms-drbd0-1" name="clone_max" value="2"/> <!-- Máxima cantidad de clones en el nodo --> <nvpair id="ma-ms-drbd0-2" name="clone_node_max" value="1"/> <!-- Máxima cantidad de masters en el cluster --> <nvpair id="ma-ms-drbd0-3" name="master_max" value="1"/> <!-- Máxima cantidad de masters en un nodo --> <nvpair id="ma-ms-drbd0-4" name="master_node_max" value="1"/> <!-- Notificaciones --> <nvpair id="ma-ms-drbd0-5" name="notify" value="yes"/> <!-- Si el recurso tiene una única instancia simultánea --> <nvpair id="ma-ms-drbd0-6" name="globally_unique" value="false"/> <!-- Objetivo --> <nvpair id="ma-ms-drbd0-7" name="target_role" value="started"/> </instance_attributes> <!-- Recurso a clonar: drbd --> <primitive id="drbd0" class="ocf" provider="heartbeat" type="drbd"> <instance_attributes id="ia-drbd0"> <!-- Idenficador del recurso --> <nvpair id="ia-drbd0-1" name="drbd_resource" value="drbd0"/> </instance_attributes> <!-- Operaciones definir --> <operations> <op id="op-drbd0-1" name="monitor" interval="6s" timeout="10s" role="master"/> <op id="op-drbd0-2" name="monitor" interval="7s" timeout="10s" role="slave"/> </operations> </primitive> </master_slave> 11

12 <!-- La directiva group es equivalente a las siguientes constraints (en la sección correspondiente) <rsc_colocation id="ip" from="tomcat" to="ip" score="infinity"/> <rsc_order id="ip_before_tomcat" from="ip" action="start" type="before" to="tomcat" symmetrical="true"/> en este caso agrupamos el tomcat con la ip, el resto queda afuera --> <group id="ip_and_tomcat"> <!-- Recurso filesystem --> <primitive class="ocf" provider="heartbeat" type="filesystem" id="fs0"> <!-- Atributos para el master --> <instance_attributes id="ma-fs0"> <nvpair name="target_role" id="ma-fs0-1" value="started"/> </instance_attributes> <instance_attributes id="ia-fs0"> <!-- Especificamos los parámetros a pasarle a drbd al momento de iniciarlo --> <nvpair id="ia-fs0-1" name="fstype" value="ext3"/> <nvpair id="ia-fs0-2" name="directory" value="/drbd"/> <nvpair id="ia-fs0-3" name="device" value="/dev/drbd0"/> </instance_attributes> </primitive> <!-- Recurso ip, con IPaddr usa ifconfig, con IPaddr2 usa los más modernos comandos ip --> <primitive class="ocf" id="ipaddr_192_168_3_1" provider="heartbeat" type="ipaddr"> <!-- Operaciones para el recurso: monitoreo, levantar y bajar la iface --> <operations> <!-- Start delay es el tiempo que espera antes de empezar a hacer el monitoreo para que se cargue el recurso --> <!-- on_fail="restart" => si el monitoreo falla, heartbeat tratará de hacer un stop/start del recurso --> <op id="ipaddr_192_168_3_1_mon" interval="5s" name="monitor" timeout="5s" start_delay="15s" on_fail="restart"/> <op id="ipaddr_192_168_3_1_start" name="start" prereq="nothing"/> <op id="ipaddr_192_168_3_1_stop" name="stop" prereq="nothing"/> </operations> <!-- Parámetros del recurso --> <instance_attributes id="ipaddr_192_168_3_1_inst_attr"> <!-- IP virtual a usar --> <nvpair id="ipaddr_192_168_3_1_attr_0" name="ip" value=" "/> <!-- Interface a usar --> <nvpair id="ipaddr_192_168_3_1_attr_2" name="nic" value="eth1:1"/> <!-- Máscara de la red --> <nvpair id="ipaddr_192_168_3_1_attr_1" name="netmask" value="24"/> </instance_attributes> </primitive> <!-- Otro recurso: el tomcat --> <primitive class="lsb" id="tomcat5.5_2" provider="heartbeat" type="tomcat5.5"> 12

13 <!-- Operaciones para el recurso: monitoreo, levantar y bajar el tomcat --> <operations> <!-- Iguales que para la interface --> <op id="tomcat5.5_2_mon" interval="10s" name="monitor" timeout="6s" start_delay="30s" on_fail="restart"/> <op id="tomcat5.5_2_start" name="start" prereq="nothing"/> <op id="tomcat5.5_2_stop" name="stop" prereq="nothing"/> </operations> </primitive> </group> <!-- Clonar: correr un recurso en todo el cluster en forma simultánea --> <clone id="pingd-clone"> <!-- Con los meta atributos se especifica la forma de clonado --> <instance_attributes id="pingd-clone-ma"> <!-- Máxima cantidad de clones en el cluster (2 fue arbitrario) --> <nvpair id="clones_in_cluster" name="clone_max" value="2"/> <!-- Máxima cantidad de clones en un nodo --> <nvpair id="clones_in_node" name="clone_node_max" value="1"/> </instance_attributes> <!-- El recurso es el ping, los nodos de pingueo están especificados en el archivo ha.cf --> <primitive id="pingd-child" provider="heartbeat" class="ocf" type="pingd"> <operations> <op id="pingd-child-monitor" name="monitor" interval="10s" timeout="10s" prereq="nothing" on_fail="restart"/> <op id="pingd-child-start" name="start" prereq="nothing"/> </operations> <!-- Parámetros a pasar a pingd --> <instance_attributes id="pingd_inst_attr"> <!-- Reduce la valuación si tarda más de 25 segundos --> <nvpair id="pingd-1" name="dampen" value="25s"/> <! es el multiplicador de la cantidad de ping nodes a los que llega el nodo --> <nvpair id="pingd-2" name="multiplier" value="3050"/> </instance_attributes> </primitive> </clone> </resources> <!-- Restricciones para los recursos --> <constraints> <!-- Las restricciones de locación especifican dónde se desea que los recursos idealmente corran --> <rsc_location id="rsc_location_ip" rsc="ip_and_tomcat"> <!-- Para la ubicación del grupo se agrega un score de 1600 al nodo node1 (preferencia de ubicación) --> <rule id="prefered_location_ip" score="1600"> <expression id="prefered_location_ip_expr" attribute="#uname" operation="eq" value="node1"/> </rule> </rsc_location> 13

14 <!-- Le damos más puntaje al nodo que tiene mejor conectividad agregando el multiplicador al score de pingd --> <rsc_location id="ip_and_tomcat:connected" rsc="ip_and_tomcat"> <rule id="ip_and_tomcat:connected:pingd_rule" score_attribute="pingd"> <expression id="ip_and_tomcat:connected:expr:defined" attribute="pingd" operation="defined"/> </rule> </rsc_location> <rsc_location id="drbd:connected" rsc="ms-drbd0"> <rule id="drbd:connected:pingd_rule" score_attribute="pingd" > <expression id="drbd:connected:expr:defined" attribute="pingd" operation="defined"/> </rule> </rsc_location> <!-- Indicamos que el master de drbd será aquel que tenga al grupo ip_and_tomcat corriendo --> <rsc_order id="drbd0_before_fs0" from="ip_and_tomcat" action="start" to="ms-drbd0" to_action="promote"/> <!-- Indicamos que el drbd master estará siempre junto al grupo que corre el webserver --> <rsc_colocation id="fs0_on_drbd0" to="ms-drbd0" to_role="master" from="ip_and_tomcat" score="infinity"/> </constraints> </configuration> </cib> Se puede observar que se agrega a DRBD como un recurso a manejar por Heartbeat, esto se logra a través de la inclusión del recurso con nombre drbd0, de tipo drbd y se setean tiempos de monitoreo de 6 segundos para el nodo maestro y 7 para el esclavo. Como se desea que este recurso sea migrado conjuntamente con la ip y el servicio Tomcat, se lo agrega al grupo denominado ip_and_tomcat. Además se especifica que el recurso es un filesystem con formato ext3 y que se monta en el directorio /drbd utilizando el dispositivo de bajo nivel /dev/drbd0. Hacia el final del archivo de configuración de Heartbeat (cib.xml), se especifica, por medio de la directiva order, que para poder iniciar el servicio de Tomcat y tener asignada la ip virtual, primero debe estar corriendo el recurso drbd0 (filesystem). Referencias [1] [2] [3] [4] 14

15 Índice 1. Introducción 1 2. Entorno 1 3. DRBD Instalación Configuración Preparación de los dispositivos de almacenamiento Preparación de la configuración de red Configuración de recursos (archivo drbd.conf ) Activación de los recursos por primera vez Heartbeat Instalación Configuración authkeys ha.cf cib.xml