CCAAPPÍÍTTUULLOO 44

ALTA DISPONIBILIDAD EN GNU/LINUX

11 IInnttrroodduucccciióónn

En los sistemas GNU/Linux existen muchas herramientas que nos permiten ofrecer alta disponibilidad. Dichas herramientas las podemos clasificar en las categorías de software y hardware.

1.1 Soluciones Software para alta disponibilidad

Las soluciones de alta disponibilidad basadas en software que van a ser aquí comentadas están destinadas a ofrecer alta disponibilidad en servicios y alta disponibilidad en datos. A continuación se pueden ver cada una de ellas.

1.1.1 Servicios

Las soluciones de alta disponibilidad enfocada a los servicios son especialmente utilizadas en servicios críticos. Normalmente, estos servicios irán acompañados de complementos que se requieren para su funcionamiento tales como: direccionamiento IP, reglas de firewall, copias de seguridad, etc. Por ejemplo, la mayoría de las empresas requieren de la utilización del servicio de Directorio Activo por lo que este se convierte en este caso en un servicio crítico. Una configuración de alta disponibilidad podría consistir por ejemplo en dos nodos donde solo uno de ellos dispone de una dirección IP Virtual, mediante la cual las aplicaciones acceden al Directorio Activo. En caso de fallo del nodo que ofrece el servicio, la dirección IP Virtual se establece en el otro nodo (nodo secundario o backup) lo que permite a los clientes y aplicaciones seguir accediendo al Directorio Activo como si no hubiera ocurrido nada.

Algunas de las herramientas GNU/Linux enfocadas a la alta disponibilidad en servicios son: KeepAlived, Heartbeat, etc.

1.1.2 Datos

Las soluciones de alta disponibilidad enfocadas a los datos son fundamentales y por lo general es necesaria su integración con los sistemas de alta disponibilidad enfocados a servicios.

El objetivo que se persigue con la alta disponibilidad enfocada a los datos es mantener en varias localizaciones una serie de datos, los cuales no presentan problemas de consistencia ni integridad entre ellos. En GNU/Linux se dispone de varias herramientas software que cumplen este cometido. Estas herramientas se pueden clasificar en dos categorías:

� Replicación de bloque de datos

La replicación de bloque de datos consiste en replicar la información bloque a bloque del sistema de ficheros. Una de las herramientas que se utilizan para la replicación de datos es DRBD o Distributed Replicated Block Device, un software de replicación de dispositivos de bloque (discos duros, particiones, volúmenes, etc.) creando discos duros espejo en distintos servidores. Algunas de sus características son una replicación en tiempo real de manera continua, transparencia en las aplicaciones que estén almacenando datos en la unidad ya que no sabrán que está se está replicando en varias localizaciones, etc. La principal limitación que presenta DRBD es cuando los cambios se están realizando en más de una localización a la vez, ya que la “unión” de los datos de más de una localización no es posible ya que solo se permite tomar una de las localizaciones como modelo de copia (master), siendo el resto esclavos (slaves). Otra herramienta de este tipo es rsync, una aplicación para sistemas de tipo Unix que ofrece transmisión eficiente de datos incrementales comprimidos y cifrados.

� Replicación de bases de datos

La replicación de bases de datos consiste en replicar una base de datos en diversas bases de datos remotas. A diferencia de lo anterior, la replicación se lleva a cabo sentencia a sentencia. Gracias a la flexibilidad de diseño que permiten las bases de datos actualmente es posible realizar modificaciones en las bases de datos de más de una localización. Flexibilidad presente en funcionalidades como la Replication de MySQL y a sus atributos como auto_increment_increment y auto_increment_offset permiten superar la limitación que tienen las soluciones basadas en bloque de datos. En GNU/Linux se dispone también de otras muchas herramientas de replicación de base de datos como Slony-I, además de la replicación que ofrece Oracle entre muchos otros.

1.2 Soluciones hardware

Las soluciones hardware para alta disponibilidad también pueden ser clasificadas en las categorías de servicios y datos. A continuación se muestran estas categorías:

1.2.1 Servicios

En muchas ocasiones las soluciones de alta disponibilidad basadas en software requieren adicionalmente de soluciones basadas en hardware para aumentar su funcionalidad. Concretamente en entornos VoIP existen soluciones hardware que permiten dotar a los primarios de telefonía de alta disponibilidad. Una de estas soluciones es RedFone, un balanceador de primarios de telefonía E1/T1. Por tanto si se dispone de un cluster de alta

disponibilidad para VoIP una solución como RedFone permitiría que, sea cual sea el nodo que se encuentre en un momento determinado ofreciendo el servicio, pueda realizar y recibir llamadas de la red de telefonía tradicional, ya que en todo momento la comunicación con los primarios se va a mantener, incluso reestableciéndose en caso de fallo en uno de los nodos.

1.2.2 Datos

Soluciones hardware que se integran perfectamente en entornos GNU/Linux son por ejemplo las unidades RAID, NAS, etc que son por lo general más conocidas por todos.

22 PPrrooyyeeccttooss ddee aallttaa ddiissppoonniibbiilliiddaadd

Para GNU/Linux existen una gran variedad de proyectos que nos aportan las características de la alta disponibilidad, proyectos tanto para la alta disponibilidad en servicios como en datos.

Algunos de los proyectos destinados a ofrecer alta disponibilidad en servicios son:

� HA-OSCAR. Es un proyecto Open Source cuyo objetivo es proporcionar de manera combinada el poder de la alta disponibilidad con un gran rendimiento de cómputo. El proyecto está basado en un sistema de clustering Beowulf enfocándose por tanto a aplicaciones que requieren un grado elevado de disponibilidad. HA-

OSCAR tiene en cuenta los puntos débiles por lo que adopta redundancia de componentes. HA-OSCAR incorpora detección de fallos, mecanismos de recuperación, etc.

� The High Availability Linux Project. Proporciona una solución de alta disponibilidad ofreciendo fiabilidad, disponibilidad. Es una de las soluciones más ampliamente extendidas, estimándose que ha sido instalado en más de treinta mil instalaciones críticas desde 1999. Se integra perfectamente con multitud de servicios y sigue aún mejorando dicha integración gracias a la aportación de su activa comunidad.

� Kimberlite. Es considerado un proyecto único ya que es una completa infraestructura de alta disponibilidad de código abierto que incluye incluso garantía sobre la integridad de los datos. Actualmente es un proyecto abandonado o de muy baja actividad.

� LifeKeeper. Es una alternativa moderna y flexible comparada con los productos que ofrecen soluciones de alta disponibilidad. Dispone de mecanismos para mantener la integridad de los datos. Una numerosa colección de kits de recuperación para los distintos servicios y/o aplicaciones permiten instalar LifeKeeper en cuestión de horas. Es un producto de la empresa SteelEye.

� HP Serviceguard. Es un software especializado para ofrecer alta disponibilidad a las aplicaciones más críticas ante fallos tanto hardware como software. HP

Serviceguard monitoriza el estado de cada nodo y responde rápidamente en caso de fallo permitiendo minimizar el tiempo durante el cual no se está ofreciendo el servicio. Está disponible tanto para Linux como para HP-UX.

� Red Hat Cluster Suite. Ha sido diseñado específicamente para Red Hat Enterprise Linux. Proporciona además de alta disponibilidad balanceo de carga. Dispone de

soluciones listas para implantar para la mayoría de los servicios, pudiendo además proporcionar soporte cuando sea necesario.

� Veritas Cluster Server. Es un producto de la empresa Symantec, una solución clustering de alta disponibilidad para la industria.

� KeepAlived. El objetivo principal del proyecto es el de proporcionar alta disponibilidad al proyecto Linux Virtual Server. KeepAlived es un servicio que monitoriza el estado del cluster LVS para que en caso de fallo el cluster siga en funcionamiento.

Algunos de los proyectos destinados a ofrecer alta disponibilidad en datos son:

� DRBD. Software de replicación de dispositivos de bloque formando un RAID 1 a través de la red, es decir, replica los datos en distintas localizaciones. Datos de un sistema de archivos, de una base de datos, etc. Algunas de sus características son una replicación en tiempo real de manera continua, transparencia en las aplicaciones que estén almacenando datos en la unidad, posibilidad de recuperación de los datos ante un desastre, etc. Se complementa perfectamente con Heartbeat.

� FreNAS. FreeNAS es un servidor NAS “Network-Attached Storage” gratuito, que soporta: protocolos Cifs (Samba), Ftp, Nfs, Rsynv, autentificación de usuario local, RAID (0,1,5) por software con un completo interfaz de configuración Web. FreeNAS ocupa menos de 32MB una vez instalado en Compact Flash, disco duro o un dispositivo de memoria usb. FreeNAS está basado en FreeBSD que es un derivado de Unix, permitiendo clientes tanto de GNU/Linux como Windows y por supuesto Unix.

� Openfiler. Es un sistema operativo para compartir en red el almacenamiento de tipo SAN-NAS. Provee de buena integración con iSCSI (Internet SCSI) y “fibre channel”, muy útiles en entornos empresariales y en virtualización tal como Xen y VMware. Cuenta con una interfaz Web para su administración y soporta clientes de todos los sistemas operativos. Dispone de soporte empresarial previo pago.

� NAS Lite-2. Es un sistema operativo NAS que permite transformar un computador personal en un servidor de archivos Smb/Cifs, Nfs, Afp, Ftp, Http y Rsync. Su principal característica es que NAS Lite está optimizado para ofrecer el máximo rendimiento manteniendo un mínimo consumo de recursos, es decir, NAS Lite es compacto, estable y muy fiable y lo más sorprendente es que se ejecuta directamente sobre la ram necesitando únicamente 8MB de disco.

� Mdadm. Es una utilidad de GNU/Linux que permite crear, borrar y monitorizar un sistema RAID software. Para hacer uso de esta utilidad es necesario habilitar el soporte RAID en el núcleo.

� MySQL Replication. Es un módulo del servicio MySQL. Consiste en una replicación asíncrona unidireccional: un servidor actúa como maestro y uno o más actúan como esclavos. El servidor maestro escribe actualizaciones en el fichero de log binario, y mantiene un índice de los ficheros para rastrear las rotaciones de logs. Estos logs sirven como registros de actualizaciones para enviar a los servidores esclavos. Cuando un esclavo se conecta al maestro, informa al maestro de la posición hasta la que el esclavo ha leído los logs en la última actualización satisfactoria. El esclavo recibe cualquier actualización que han tenido lugar desde entonces, y se bloquea y espera para que el master le envíe nuevas actualizaciones.

� Slony-I. Es un sistema de replicación de “maestro a múltiples esclavos”, el cuál además soporta el concepto de “cascada” (un nodo puede proveer a otro nodo, el

cual puede proveer a otro) permitiendo así la recuperación ante errores. Incluye las principales características para replicar bases de datos de gran información a un número límite razonables de esclavos. Es por tanto un sistema diseñado para centros de datos y sitios de backup donde el funcionamiento normal requiere que todos los nodos estén disponibles en un momento determinado.

Algunos de los proyectos aquí listados son de pago, otros son completamente gratuitos, otros ofrecen soporte o disponen de una gran comunidad, etc. En GNU/Linux disponemos de diversas soluciones pudiendo escoger la que más se adapte a nuestras necesidades.

A continuación nos vamos a centrar en la herramienta Heartbeat por ser la solución de alta disponibilidad enfocada a los servicios más ampliamente difundida y poseer una comunidad muy activa y además ser gratuita. Posteriormente dedicaremos otro capítulo a DRBD así como a la utilidad Mysql Replicación.

33 LLiinnuuxx--HHAA:: HHeeaarrttbbeeaatt

En la dirección www.linux-ha.org se encuentra el proyecto Heartbeat. Heartbeat es un software que ofrece alta disponibilidad a determinados recursos mediante la creación y mantenimiento de un clúster compuesto por una serie de nodos. Los recursos se ejecutan y se mueven entre los distintos nodos ya sea por motivos de fallo o simplemente por motivos de administración. Por ejemplo un recurso podría ser el servicio Web de una entidad de tal manera que si sucede un evento como el fallo de la fuente de alimentación del nodo que en ese momento ejecuta el servicio, el servicio Web o recurso se mueve hacia otro nodo del cluster por lo que el servicio en cuestión se continua ofreciendo de manera ininterrumpida a pesar del suceso.

Figura 4-1. Logotipo Heartbeat

Veamos a continuación un ejemplo más completo de las posibilidades que ofrece Heartbeat:

Supongamos que disponemos de dos servidores con el servicio Asterisk instalado en cada uno de ellos. Con ellos formamos un clúster de alta disponibilidad donde el recurso a dotar de alta disponibilidad es el recurso Asterisk mediante una configuración Activa/Pasiva. Esta configuración consiste en que únicamente uno de los nodos ofrece el servicio (solo lo ofrece el nodo activo de todo el cluster) mientras que el resto de nodos se mantienen a la espera (nodo pasivos) de un posible fallo del nodo activo. Todos los datos de los clientes, los privilegios a la hora de llamar, mensajes de voz, etc, son almacenados en un servidor de archivos compartidos

conectado a cada uno de los servidores del clúster a través de la red. Véase la figura figura 4-2 en la que se muestra dicha arquitectura.

Figura 4-2. Un clúster de alta disponibilidad

Durante el funcionamiento normal del clúster cada servidor está en comunicación constante con el otro mediante pinging (paquetes ICMP). Además cada nodo realiza encuestas periódicas (monitorización software) de los recursos que tiene bajo su control con el fin de detectar el fallo de alguno de ellos (exclusivamente en Heartbeat-2). Haciendo referencia de nuevo a la figura 4-2 el nodo activo que está ofreciendo el recurso Asterisk monitoriza el estado del servicio Asterisk con la finalidad de comprobar si se está ejecutando correctamente.

Ahora supongamos que el servidor que ofrece el servicio o recurso Asterisk experimenta un problema, ya sea hardware o software. Supongamos que es un problema hardware, por ejemplo, un fallo en la fuente de alimentación, lo que provocará que el nodo se apague y la imposibilidad de este para responder a los ping (realizado por los otros nodos del cluster) mediante un mensaje “estoy vivo”. Ante tal evento el nodo pasivo del clúster se hace cargo del recurso del nodo fallido ya que no recibe respuestas que confirmen que el nodo que ofrece el servicio o recurso Asterisk (nodo activo) está vivo. La figura 4-3 muestra como el recurso se mueve al nodo pasivo.

Figura 4-3. Un clúster de alta disponibilidad balanceado

El nodo pasivo para continuar ofreciendo el servicio Asterisk toma la dirección IP Virtual asociada al servicio, de esta manera, el servicio Asterisk aunque es interrumpido, el periodo de tiempo es tan pequeño, que el fallo es transparente para los clientes.

Ahora supongamos que los problemas que provocaron la caída del anterior servidor (anterior nodo activo) se solucionan y el servidor se vuelve a poner operativo. El servicio Asterisk puede volver de nuevo al servidor original o permanecer en el servidor en el que se encuentra actualmente. Esto depende de la configuración que se establezca inicialmente en el clúster. Lo cierto es que volver a su servidor original o primario presenta la desventaja de que durante la migración es necesario parar de nuevo el servicio produciendo durante unos segundos la baja de éste. Sin embargo la ventaja de hacerlos volver a su nodo primario, es que la carga del servidor que lo está ofreciendo actualmente se ve reducida. Esto último se puede apreciar más claramente en una configuración Activa/Activa, donde ambos nodos del clúster son activos, es decir, cada uno ofrece un servicio simultáneamente. Por ejemplo uno de los nodos ofrece Asterisk y el otro servidor un recurso o servicio Web. Si el servidor que ofrece Asterisk falla, el otro servidor (el que ofrece el servicio Web) se hará también cargo del servicio Asterisk. Ambos servicios provocarán una carga más elevada en este servidor.

Como ya comentamos anteriormente Heartbeat también permite mover los recursos de manera manual, independientemente de que se produzca un error de software o hardware. El motivo puede ser, por ejemplo, por mantenimiento o administración del nodo, que suele ser lo más habitual.

En definitiva hacer uso de Heartbeat en este tipo de escenarios está más que justificado: ofrece disponibilidad a los servicios, mejora el rendimiento de estos, bajo coste de implementación, recuperación ante desastres y consolidación del almacenamiento.

3.1 Heartbeat-1 vs Heartbeat-2

La segunda versión de Heartbeat ha sido modificada para eliminar ciertas restricciones presentes en la primera versión, las cuales presentaban grandes limitaciones en su funcionamiento. Las restricciones más importantes que limitaban la funcionalidad de la primera versión de Heartbeat son las siguientes:

� Clúster con un tamaño máximo de dos nodos.

� Incapacidad de monitorizar los recursos. Heartbeat-1 no monitoriza los recursos con la finalidad de comprobar si los recursos están operando correctamente por lo que solo se supervisa el estado de funcionamiento del nodo (monitorización hardware) sin tener en cuenta el estado de ejecución de los recursos (monitorización software). De esta manera si el nodo que ofrece el servicio contesta adecuadamente al ping indicando “estoy vivo” pero el recurso, por ejemplo un servicio Web, no se está ejecutando correctamente o incluso ha parado, no se toma ninguna medida de recuperación. Para monitorizar recursos con Heartbeat-1 es necesario hacer uso de aplicaciones de monitorización externas tales como Watchdog.

� Mínima capacidad de expresar la información dependiente. En Heartbeat-1 no es posible crear grupos de recursos que compartan las mismas restricciones, grupos de nodos, etc, lo que repercuten en una pobre flexibilidad a la hora de configurar el cluster.

De una manera más detallada y a modo de resumen se muestra la tabla 4-1 Ventajas de Heartbeat-2 sobre Heartbeat-1 y la tabla 4-2 Desventajas de Heartbeat-2 sobre Heartbeat-1.

Tabla 4-1. Ventajas de Heartbeat-2 sobre Heartbeat-1

Ventajas Descripción

1 Un clúster puede estar formado por 255 nodos y no por un máximo de dos nodos como sucedía en la primera versión.

2 La configuración del clúster basta con establecerla en un nodo ya que automáticamente se propaga al resto del cluster. No es necesario establecer la configuración del clúster en cada uno de los nodos que lo forman de manera individual como en la primera versión.

3

Heartbeat-2 monitoriza el estado del recurso y del nodo a diferencia de Heartbeat-1 que únicamente monitorizaba el estado del nodo necesitando una aplicación externa si se deseaba monitorizar el estado de ejecución de los recursos. Heartbeat-2 por tanto monitoriza tanto a nivel software como hardware.

4

Permite definir con mayor detalle el comportamiento del clúster: orden de ejecución a la hora de arrancar los recursos, orden a la hora de parar los recursos, que recursos pueden ejecutarse o no en un mismo nodo, que nodos son los preferidos por el recurso para su ejecución, etc.

5 Posibilidad de establecer varios grupos de recursos a diferencia de Heartbeat-1 que solo soporta dos como máximo.

Tabla 4-2. Desventajas de Heartbeat-2 sobre Heartbeat-1

Desventajas Descripción

1 Heartbeat-2 es más complejo tanto en su configuración como en su administración debido al gran potencial y flexibilidad que presenta.

2 Establecer como se ha de monitorizar un recurso no es tan sencillo.

3.2 Arquitectura Heartbeat-2

Como se ha comentado en el punto anterior, Heartbeat-2 eliminó las barreras que limitaban la funcionalidad y flexibilidad de Heartbeat-1. Para ello la arquitectura en Heartbeat-

2 fue modificada añadiendo diversos módulos que extendían el comportamiento respecto de su versión anterior. En la figura 4-4 se muestra la arquitectura de Heartbeat-2 (fuente Novell Inc.).

Figura 4-4. Arquitectura de Heartbeat-2

La arquitectura de Heartbeat-2 se compone de cuatro capas: capa de comunicación, capa de consenso, capa de asignación de recursos, capa de recursos.

Capa de comunicación (Messaging/Infrastructure)

Es la capa de nivel más bajo también conocida como “capa de mensajeo”. En esta capa se encuentran diversos componentes:

� Componente Heartbeat

También conocido como módulo de comunicaciones. Es necesario para que los nodos del clúster entre sí se envíen mensajes tales como “sigo vivo” (pinging) pudiendo así determinar cuando uno de los nodos está fallando. La comunicación entre los dos nodos puede realizarse de dos formas distintas: a través de la red Ethernet IP (Unicast UDP IPv4, Broadcast UDP IPv4 o Multicast UDP IPv4) y mediante el Puerto

Serie (muy útil para utilizarlo cuando los firewalls filtran la comunicación entre los nodos).

� Logd – Servidor logging no bloqueante

Puede ir registrando los sucesos del clúster en syslog, en archivos o en ambos.

� apphbd

Proporciona un temporizador a Watchdog. Si apphbd es configurado en el clúster, cuando los recursos fallan en su monitorización apphbd notifica a RMD o Recovery Manager Daemon para matar el proceso y reiniciar por completo la aplicación. De esta manera Heartbeat-2 si detecta el fallo en la ejecución de un recurso ya que monitoriza el software.

Capa de consenso (Membership)

Es la segunda capa de la arquitectura. Provee servicios de conexión entre los miembros del clúster, asegurando que cualquier nodo puede hablar con todos los otros nodos del clúster. En esta capa se encuentra un componente denominado CCM o Cluster Consensus Membership encargado de representar el clúster como un grupo de nodos a las capas superiores.

Capa de asignación de recursos (Resource Allocation)

Es la capa más compleja de toda la arquitectura ya que está formada por diversos componentes:

� Componente CRM - Cluster Resource Manager

CRM o Cluster Resource Manager es el cerebro de Heartbeat. Todas las acciones relacionadas con la asignación de recursos pasan a través de CRM. Como podemos ver en la figura 4-4 Arquitectura de Heartbeat-2 cualquier comunicación entre las capas superiores y la capa de asignación de recursos u otra de nivel inferior siempre se realiza a través de CRM.

El CRM de cada nodo determina el comportamiento de su nodo en el clúster. Para que CRM pueda administrar adecuadamente el comportamiento de cada nodo requiere disponer de la configuración de cada uno de ellos. Esta información se encuentra definida en el componente CIB o Cluster Information Base el cual almacena

la información del clúster referente a la configuración de los recursos, qué recursos ejecutar y en qué nodo, etc.

A destacar que el CRM de uno de los nodos del clúster es designado DC o Designated Coordinator, lo que indica que dicho CRM tiene el CIB principal del clúster. Todos los otros CIB del clúster son replicas del CIB del nodo designado como DC. La funcionalidad del nodo DC es la siguiente:

o Única entidad del clúster que decide los cambios que han de realizarse en este. Los cambios convenientes se realizan en cada nodo mediante el respectivo LRM.

o Recibir información sobre nuevos miembros del clúster o actualizaciones del estado de estos a través de CCM.

Haciendo referencia otra vez a la figura 4-4 Arquitectura de Heartbeat-2

pueden observarse los componentes TE/PE y CIB los cuales pueden verse como subcomponentes de CRM.

� Subcomponente PE (Policy Engine) / TE (Transition Engine).

Siempre que el nodo designado coordinador (DC) o nodo representante del clúster, necesita hacer un cambio en el estado del cluster PE es usado para calcular el siguiente estado del clúster y la lista de acciones requeridas para lograrlo. Lo que hace PE es calcular un diagrama de transición de todo el estado actual del sistema teniendo en cuenta la localización y estado actual de los recursos, la disponibilidad de los nodos, etc, que le permite obtener las modificaciones a realizar necesarias en el clúster. Estas modificaciones calculadas por PE son ejecutadas por el Transition Engine o TE. El DC enviará entonces mensajes al CRM de cada nodo con los cambios que han de realizar. Cada nodo para llevarlos a cabo estos cambios hará uso de su Local Resource Manager o LRM. Destacar de nuevo que PE/TE solo están activos en el nodo DC (ver figura 4-4).

� Subcomponente CIB - Cluster Information Base

CIB es un repositorio con información de los recursos del clúster y de los nodos que lo conforman. La información que se incluye en CIB es la siguiente:

o Información estática. Nodos que conforman el clúster, recursos, restricciones sobre estos, etc.

o Información dinámica. Que recursos están actualmente corriendo, donde y cuál es el estado de estos, etc.

Toda la información es representada en formato XML. Se dispone de una anotación DTD mediante la cual se define toda la información necesaria.

� Subcomponente LRM- Local Resource Manager

Es el gestor de recursos del nodo. Cada nodo, sea DC o no, dispone de este componente (ver figura 4-4). Arranca, para, monitoriza, etc., los recursos locales al nodo. Soporta varias clases de agentes de recurso (resource agents o RA. Los tipos de estándares que actualmente son soportados son:

o OCF – Open Cluster Framework

o Heartbeat (versión 1)

o LSB – Linux Standard Base (típicos scripts de inicio)

o Stonith

En el apartado 3.6 ¿Qué es un recurso? se verá mejor el significado de cada uno de estos conceptos.

� Componente Stonith Daemon

Proporciona al clúster la capacidad de reinicio gracias a las mejoras de la API Stonith implementadas en la segunda versión de Heartbeat. Stonith es el componente encargado de reiniciar o incluso apagar un determinado nodo del clúster cuando se produce un evento el cuál ha sido previamente configurado para tal hecho.

Capa de recursos (Resources)

Corresponde a la cuarta y más alta capa. Esta capa incluye los agentes de recursos, en inglés Resource Agent (RA). Un agente de recurso es un programa, por lo general un script, donde se define como un recurso ha de realizar las acciones de start, stop, monitor, etc. Los agentes de recursos son escritos siguiendo estándares, tales como, LSB, OCF, etc. Los agentes de recurso son llamados por LRM cuando este debe de actuar sobre el recurso localmente para cumplir así los cambios establecidos por CRM que se necesitan aplicar en el clúster para alcanzar el nuevo estado.

3.3 Un ejemplo del funcionamiento interno de Heartbeat

Supongamos que queremos añadir un nuevo recurso en un clúster. El recurso a dotar de alta disponibilidad se trata de una dirección IP. Para hacer esto, podemos hacer uso del comando de administración cibadmin (más adelante en el apartado 3.13 se verán los comandos de administración) o incluso haciendo uso de la interfaz gráfica. Mencionar que aunque vayamos a modificar el CIB del nodo DC no es necesario hacer uso de la utilidad cibadmin o de la interfaz gráfica en el nodo DC, se puede hacer uso de cualquier utilidad desde cualquier nodo del clúster ya que los cambios realizados en un CIB de un nodo no DC serán actualizados automáticamente en el CIB principal del clúster.

Una vez que estos nuevos cambios han sido recibidos y realizados por el nodo DC en su CIB principal o CIB master, éste replicará entonces todos los cambios realizados al resto de nodos del clúster por lo que finalmente podrá dar comienzo el procedimiento de transición.

Con ayuda de PE y TE, el nodo DC obtiene los pasos que necesita realizar en el clúster para poder gestionar la nueva dirección IP que se ha añadido. Una vez conocidas las modificaciones que se han de llevar a cabo en cada nodo, el DC envía los mensajes necesarios a cada uno de ellos haciendo uso del módulo de comunicaciones Heartbeat. Estos mensajes son recibidos por el CRM de cada nodo.

Los nodos que requieran realizar cambios harán uso de LRM e informarán de vuelta al DC con los resultados obtenidos.

Una vez que DC ha finalizado con éxito los pasos encomendados por PE/TE el clúster vuelve a estar disponible a la espera de próximos eventos. Al haber realizado cambios, se obtiene un nuevo CIB, debido, en este caso, a una nueva información estática, ya que se ha añadido un nuevo recurso.

Si por cualquier motivo cualquier operación no se realiza con éxito, PE se ejecuta de nuevo con la nueva información registrada en el CIB.

Cuando un recurso falla (fallo software) o un nodo falla (fallo hardware) el DC será informado por el CCM (en caso de caída de un nodo por ejemplo) o por LRM (en caso de error en una operación de monitorización de un recurso) respectivamente. Si un error ocurriera, ya sea hardware o software, los mismos pasos anteriormente citados se llevarían a cabo, calculándose un nuevo CIB que en este caso presentará novedades en la información dinámica.

3.4 Instalar Heartbeat-2

La página oficial del proyecto Heartbeat de alta disponibilidad para GNU/Linux es http://www.linux-ha.org. En ella se pone a disposición HeartBeart desde las fuentes así como los paquetes para diversas distribuciones tales como: openSUSE/SUSE, Red Hat, Fedora, Mandriva, CentOS, Debian y Gentoo.

A modo de curiosidad, en la página oficial del proyecto linux-ha en la sección Downloads, apartado Debian Packages se pone a disposición un enlace a un proyecto muy completo que integra Heartbeat con el proyecto de alto rendimiento LVS. La dirección Web de es este proyecto es http://www.ultramonkey.org

Aquí se va a comentar la instalación de Heartbeat desde los sources en la distribución Debian ETCH 4.0 con kernel 2.6.18-6-486. La última versión estable hasta el momento es la 2.1.3.

Atención: la instalación de Heartbeat ha de llevarse a cabo en todos los nodos del cluster.

Para instalar desde las fuentes nos descargamos Heartbeat-2.1.3.tar.gz desde el área de descarga de Linux-HA: http://linux-ha.org/download/index.html#2.1.3

Lo descomprimimos ejecutando el comando:

tar xzf Heartbeat-2.1.3.tar.gz

Dentro del directorio Heartbeat-2.1.3, que se nos acaba de crear al descomprimir, se encuentra el script ConfigureMe. Se recomienda utilizar ConfigureMe en lugar de los comandos conocidos ./configure && make && make install. Utilizar ConfigureMe es muy sencillo pero antes vamos a instalar las dependencias:

apt-get install libbz2-dev libperl5.8 libperl-dev l ibltdl3-dev libxml2-dev libnet1-dev libglib2.0-dev gawk zlib1g- dev

Una vez instaladas todas las dependencias, procedemos a configurar, crear e instalar Heartbeat mediante el script ConfigureMe. Para ello y en el directorio Heartbeat-2.1.3:

./ConfigureMe configure

./ConfigureMe make

./ConfigureMe install

Una vez instalado es necesario crear el grupo “haclient” y el usuario “hacluster” y hacerlos propietarios de los archivos de Heartbeat. Para ello es necesario ejecutar:

addgroup haclient adduser hacluster adduser hacluster haclient chown –R hacluster:haclient /var/run/Heartbeat chown –R hacluster:haclient /var/lib/Heartbeat chown –R hacluster:haclient /usr/lib/Heartbeat

Tanto si realizamos la instalación de Heartbeat desde los sources como si la realizamos a través de los paquetes precompilados a la hora de arrancar el servicio el sistema nos informa que faltan los archivos de configuración. Estos archivos se encuentran en la documentación de Heartbeat, por tanto procedemos a copiarlos:

cp /usr/share/doc/Heartbeat/authkeys /etc/ha.d/ cp /usr/share/doc/Heartbeat/ha.cf.gz /etc/ha.d/ cp /usr/share/doc/Heartbeat/haresources.gz /etc/ha. d/

En el directorio /etc/ha.d se encuentran los archivos ha.cf y haresources que acabamos de copiar están comprimidos en formato .gz. Se descomprimen ejecutando:

gzip -d ha.cf.gz gzip -d haresources.gz

Finalmente es necesario establecer permisos al archivo authkeys que acabamos de copiar:

chmod 600 authkeys

El siguiente paso y más complejo es la configuración de Heartbeat. Para la configuración es necesario que cada nodo que va a componer el cluster tenga un nombre ya que a la hora de referirnos a cada una de ellas durante la configuración lo haremos mediante su nombre en lugar de su dirección IP. Para dar o cambiar el nombre a una máquina se puede utilizar el comando:

hostname <nombre>

Aunque es más recomendable hacerlo de manera permanente modificando el archivo /etc/hostname.

Para comprobar el nombre asignado a una máquina:

uname –n

Nota: en el archivo /etc/hosts de cada nodo tienen que estar los nombres de todos los nodos.

3.5 Configurar Heartbeat-2

La configuración de Heartbeat se lleva a cabo en los archivos de configuración authkeys, ha.cf y haresources. La configuración en un principio es válida tanto para Heartbeat-

1 como para Heartbeat-2, sin embargo en el apartado 3.7 El archivo CIB se explica cómo aprovechar todo el potencial de Heartbeat-2 haciendo uso del archivo cib.xml.

3.5.1 Configurar authkeys

Inicialmente se va a configurar el archivo authkeys que se encuentra en el directorio /etc/ha.d. Este archivo determina la seguridad del clúster. Para ello se hace uso de claves que deben ser iguales en todos los nodos. Se puede seleccionar entre tres esquemas de autentificación: crc, md5 o sha1. Si Heartbeat se ejecuta sobre una red segura, conectada por ejemplo, con un cable cruzado se puede usar únicamente crc. Este es el esquema que menos recursos necesita. Si por el contrario la red es insegura, pero se está demasiado preocupado por la seguridad y se desea una relación seguridad/consumo CPU buena, se puede utilizar md5. Por último si se desea la mejor seguridad sin importarte el consumo de CPU, se puede usar sha1.

El formato del archivo es el siguiente:

auth <number> <number> <authmethod> [<authkey>]

Por ejemplo:

auth 1 #Número de identificador asociado 1 sha1 PutYourSuperSecretKeyHere #Método de firma s ha1 y clave secreta compartida

Para esta prueba experimental no importa la seguridad por lo que se ha optado por utilizar crc.

auth 1 1 crc

3.5.2 Configurar ha.cf

El siguiente archivo a configurar es /etc/ha.d/ha.cf. En él se establece la configuración del clúster, como por ejemplo: nodos que lo componen, que interfaz usará cada nodo para comunicarse con el clúster, puertos que usarán para la comunicación así como numerosas funciones adicionales. Las opciones fundamentales para configurar ha.cf son las siguientes:

� debugfile. Almacena los mensajes de Heartbeat en modo debug.

� logfile. Guarda los logs del sistema.

� logfacility. syslog()/logger

� keepalive. Indica el intervalo de tiempo entre ping y ping hacia cada nodo del clúster para la monitorización hardware.

� deadtime. Establece el número de segundos que tienen que transcurrir para declarar a dicho nodo como “muerto”.

� warntime. Establece el número de segundos antes de indicar la advertencia del último latido, es decir, último intento de ping o de monitorización. Este parámetro es importante ya que nos permite ajustar los parámetros deadtime y keepalive. Si con frecuencia Heartbeat llega al último intento de latido indica que el nodo ha estado próximo a pensar que el nodo monitorizado ha muerto, lo cual no tiene por qué ser siempre cierto ya que las respuestas al ping pueden retrasarse por motivos como la latencia de la red.

� initdead. Establece el tiempo obligatorio que el nodo tiene que esperar antes de iniciar el servicio Heartbeat. Es un parámetro muy importante, ya que si uno de los nodos del cluster no arranca antes de que expire este tiempo se considerará un nodo “muerto”, por ejemplo, en determinadas ocasiones durante el arranque del nodo la tarjeta de red puede tardar en levantarse y activarse adecuadamente, algunos servicios realizan ciertas comprobaciones, etc, lo que demora el arranque del nodo. Un buen valor es el doble del establecido para deadtime.

� udpport. Puerto que utiliza Heartbeat para las comunicaciones ucast y bcast tanto para enviar como recibir los latidos (pinging).

� bcast. Interfaz de red que usa Heartbeat para enviar latidos al resto de nodos del cluster con objeto de monitorizarlos. Si tenemos una tarjeta red únicamente dedicada a Heartbeat es aquí donde debemos indicar su interfaz. Generalmente este aspecto de la configuración sí cambia de un nodo a otro, todo depende de qué interfaz queramos usar en cada uno de ellos.

Otro tipo de comunicación entre los nodos del cluster es una comunicación multicast o una comunicación ucast. Si el cluster está formado por únicamente dos nodos, podemos usar ucast. Para ello, únicamente debemos indicar la dirección IP del otro nodo. Atención: este valor sí cambia en la configuración entre un nodo y otro.

� autofailback. Cuando el nodo original, que inicialmente ofrece el servicio, falla, el recurso balancea a otro nodo del cluster como ya se ha visto. Sin embargo una vez que el nodo ha sido reparado se pueden considerar dos opciones: que el recurso vuelva a su nodo primario (nodo inicial) o que permanezca en el nodo en el que se encuentra. Esta opción es útil en Heartbeat-1 aunque no en Heartbeat-2 donde ha sido sustituida por resource_stickiness (se verá en el Punto 3.7 El archivo CIB). autofailback toma el valor true o false.

� node. Indica el nombre de las maquinas o nodos que forman el clúster. El nombre de la máquina ha de coincidir con uname –n y con la resolución que se indicó en el archivo /etc/hosts.

Un ejemplo de configuración del archivo ha.conf es el Código 4-3 ha.cf que se muestra a continuación:

Código 4-3. ha.cf # # There are lots of options in this file. All you have to have is a set # of nodes listed {"node ...} one of {serial, bcast , mcast, or ucast}, # and a value for "auto_failback". # # ATTENTION: As the configuration file is read line by line, # THE ORDER OF DIRECTIVE MATTERS! # # In particular, make sure that the udpport, serial baud rate # etc. are set before the Heartbeat media are defin ed! # debug and log file directives go into effect when they # are encountered. # # All will be fine if you keep them ordered as in t his example. # # # Note on logging: # If any of debugfile, logfile and logfacilit y are defined then

they # will be used. If debugfile and/or logfile a re not defined and # logfacility is defined then the respective logging and debug # messages will be loged to syslog. If logfac ility is not defined # then debugfile and logfile will be used to log messges. If # logfacility is not defined and debugfile an d/or logfile are not # defined then defaults will be used for debu gfile and logfile as # required and messages will be sent there. # # File to write debug messages to debugfile /var/log/ha-debug # # # File to write other messages to # logfile /var/log/ha-log # # # Facility to use for syslog()/logger # logfacility local0 # # # A note on specifying "how long" times below... # # The default time unit is seconds # 10 means ten seconds # # You can also specify them in milliseconds # 1500ms means 1.5 seconds # # # keepalive: how long between Heartbeats? # keepalive 2 # # deadtime: how long-to-declare-host-dead? # # If you set this too low you will get the problem atic # split-brain (or cluster partition) problem. # See the FAQ for how to use warntime to tune dead time. # deadtime 30 # # warntime: how long before issuing "late Heartbeat " warning? # See the FAQ for how to use warntime to tune deadt ime. # warntime 10 # # # Very first dead time (initdead) # # On some machines/OSes, etc. the network takes a w hile to come up # and start working right after you've been reboote d. As a result # we have a separate dead time for when things firs t come up. # It should be at least twice the normal dead time. # initdead 120 # # # What UDP port to use for bcast/ucast communicatio n? # udpport 694 # # Baud rate for serial ports... #

#baud 19200 # # serial serialportname ... #serial /dev/ttyS0 # Linux #serial /dev/cuaa0 # FreeBSD #serial /dev/cuad0 # FreeBSD 6.x #serial /dev/cua/a # Solaris # # # What interfaces to broadcast Heartbeats over? # bcast eth0 # Linux #bcast eth1 eth2 # Linux #bcast le0 # Solaris #bcast le1 le2 # Solaris # # Set up a multicast Heartbeat medium # mcast [dev] [mcast group] [port] [ttl] [loop] # # [dev] device to send/rcv Heartbeats on # [mcast group] multicast group to join (class D mu lticast address # 224.0.0.0 - 239.255.255.255) # [port] udp port to sendto/rcvfrom (set this valu e to the # same value as "udpport" above) # [ttl] the ttl value for outbound Heartbeats. th is effects # how far the multicast packet will propagate. ( 0-255) # Must be greater than zero. # [loop] toggles loopback for outbound multicast Heartbeats. # if enabled, an outbound packet will be looped b ack and # received by the interface it was sent on. (0 or 1) # Set this value to zero. # # #mcast eth0 225.0.0.1 694 1 0 # # Set up a unicast / udp Heartbeat medium # ucast [dev] [peer-ip-addr] # # [dev] device to send/rcv Heartbeats on # [peer-ip-addr] IP address of peer to send packets to # #ucast eth0 192.168.1.2 # # # About boolean values... # # Any of the following case-insensitive values will work for true: # true, on, yes, y, 1 # Any of the following case-insensitive values will work for false: # false, off, no, n, 0 # # # # auto_failback: determines whether a resource wil l # automatically fail back to its "primary" node, or remain # on whatever node is serving it until that node fa ils, or # an administrator intervenes. # # The possible values for auto_failback are: # on - enable automatic failbacks # off - disable automatic failbacks # legacy - enable automatic failbacks in systems # where all nodes do not yet support

# the auto_failback option. # # auto_failback "on" and "off" are backwards compat ible with the old # "nice_failback on" setting. # # See the FAQ for information on how to convert # from "legacy" to "on" without a flash cut. # (i.e., using a "rolling upgrade" process) # # The default value for auto_failback is "legacy", which # will issue a warning at startup. So, make sure y ou put # an auto_failback directive in your ha.cf file. # (note: auto_failback can be any boolean or "legac y") # auto_failback off # # # Basic STONITH support # Using this directive assumes that there is one stonith # device in the cluster. Parameters to this device are # read from a configuration file. The format of this line is: # # stonith <stonith_type> <configfile> # # NOTE: it is up to you to maintain this file on each node in the # cluster! # #stonith baytech /etc/ha.d/conf/stonith.baytech # # STONITH support # You can configure multiple stonith devices using this directive. # The format of the line is: # stonith_host <hostfrom> <stonith_type> <p arams...> # <hostfrom> is the machine the stonith dev ice is attached # to or * to mean it is accessible fro m any host. # <stonith_type> is the type of stonith dev ice (a list of # supported drives is in /usr/lib/ston ith.) # <params...> are driver specific parameter s. To see the # format for a particular device, run: # stonith -l -t <stonith_type> # # # Note that if you put your stonith device access i nformation in # here, and you make this file publically readable, you're asking # for a denial of service attack ;-) # # To get a list of supported stonith devices, run # stonith -L # For detailed information on which stonith devices are supported # and their detailed configuration options, run thi s command: # stonith -h # #stonith_host * baytech 10.0.0.3 mylogin mysecr etpassword #stonith_host ken3 rps10 /dev/ttyS1 kathy 0 #stonith_host kathy rps10 /dev/ttyS1 ken3 0 # # Watchdog is the watchdog timer. If our own heart doesn't beat for # a minute, then our machine will reboot. # NOTE: If you are using the software watchdog, you very likely # wish to load the module with the parameter "noway out=0" or # compile it without CONFIG_WATCHDOG_NOWAYOUT set. Otherwise even # an orderly shutdown of Heartbeat will trigger a r eboot, which is # very likely NOT what you want. # #watchdog /dev/watchdog

# # Tell what machines are in the cluster # node nodename ... -- must match uname -n node ast1 node ast2 # # Less common options... # # Treats 10.10.10.254 as a psuedo-cluster-member # Used together with ipfail below... # note: don't use a cluster node as ping node # #ping 10.10.10.254 # # Treats 10.10.10.254 and 10.10.10.253 as a psuedo- cluster-member # called group1. If either 10.10.10.254 or 10 .10.10.253 are up # then group1 is up # Used together with ipfail below... # #ping_group group1 10.10.10.254 10.10.10.253 # # HBA ping derective for Fiber Channel # Treats fc-card-name as psudo-cluster-member # used with ipfail below ... # # You can obtain HBAAPI from http://hbaapi.sourcefo rge.net. You need # to get the library specific to your HBA directly from the vender # To install HBAAPI stuff, all You need to do is to compile the common # part you obtained from the sourceforge. This will produce libHBAAPI.so # which you need to copy to /usr/lib. You need also copy hbaapi.h to # /usr/include. # # The fc-card-name is the name obtained from the hb aapitest program # that is part of the hbaapi package. Running hbaap itest will produce # a verbose output. One of the first line is simila r to: # Apapter number 0 is named: qlogic-qla2200-0 # Here fc-card-name is qlogic-qla2200-0. # #hbaping fc-card-name # # # Processes started and stopped with Heartbeat. Re started unless # they exit with rc=100 # #respawn userid /path/name/to/run #respawn hacluster /usr/lib/Heartbeat/ipfail # # Access control for client api # default is no access # #apiauth client-name gid=gidlist uid=uidlist #apiauth ipfail gid=haclient uid=hacluster ########################### # # Unusual options. # ########################### # # hopfudge maximum hop count minus number of nodes in config #hopfudge 1 # # deadping - dead time for ping nodes

#deadping 30 # # hbgenmethod - Heartbeat generation number creatio n method # Normally these are stored on disk and incremente d as needed. #hbgenmethod time # # realtime - enable/disable realtime execution (hig h priority, etc.) # defaults to on #realtime off # # debug - set debug level # defaults to zero #debug 1 # # API Authentication - replaces the fifo-permission s-based system of the past # # # You can put a uid list and/or a gid list. # If you put both, then a process is authorized if it qualifies under either # the uid list, or under the gid list. # # The groupname "default" has special meaning. If it is specified, then # this will be used for authorizing groupless clien ts, and any client groups # not otherwise specified. # # There is a subtle exception to this. "default" w ill never be used in the # following cases (actual default auth directives n oted in brackets) # ipfail (uid=HA_CCMUSER) # ccm (uid=HA_CCMUSER) # ping (gid=HA_APIGROUP) # cl_status (gid=HA_APIGROUP) # # This is done to avoid creating a gaping security hole and matches the most # likely desired configuration. # #apiauth ipfail uid=hacluster #apiauth ccm uid=hacluster #apiauth cms uid=hacluster #apiauth ping gid=haclient uid=alanr,root #apiauth default gid=haclient # message format in the wire, it can be classic or netstring, # default: classic #msgfmt classic/netstring # Do we use logging daemon? # If logging daemon is used, logfile/debugfile/logf acility in this file # are not meaningful any longer. You should check t he config file for logging # daemon (the default is /etc/logd.cf) # more infomartion can be fould in http://www.linux -ha.org/ha_2ecf_2fUseLogdDirective # Setting use_logd to "yes" is recommended # # use_logd yes/no # # the interval we reconnect to logging daemon if t he previous connection failed # default: 60 seconds

#conn_logd_time 60 # # # Configure compression module # It could be zlib or bz2, depending on whether u h ave the corresponding # library in the system. #compression bz2 # # Confiugre compression threshold # This value determines the threshold to compress a message, # e.g. if the threshold is 1, then any message with size greater than 1 KB # will be compressed, the default is 2 (KB) #compression_threshold 2

El archivo de configuración ha.cf dispone de numerosas opciones que no han sido comentadas. Algunas de ellas como ping, ping_group, etc, se verán en el Punto 3-8 Otras

posibilidades que ofrece Heartbeat en su configuración.

Manejar todas las opciones de configuración de Heartbeat requiere de tiempo y experiencia, sin embargo, las vistas hasta el momento son suficientes para una configuración básica del servicio.

3.5.3 Configurar haresources

El último archivo a configurar es /etc/ha.d/haresources. En este fichero se establecen los recursos que el clúster va a gestionar. El formato de haresources a la hora de definir los recursos es el siguiente:

<nombre_nodo_primario> <recurso>[::parámetro][…] <r ecurso>[::parámetro][…]

donde <nombre_nodo_ primario> hace referencia al nodo primario o nodo en el que los recursos que se listen a continuación van a comenzar a ejecutarse inicialmente y <recurso> hace referencia al nombre del recurso que va a gestionar el nodo inicialmente.

Atención: el nombre del recurso ha de coincidir con el nombre del RA o agente del recurso

que posteriormente ha de colocarse en /etc/ha.d/resource.d/. Se verá a continuación en la

sección Configuración de los RA

Adicionalmente los recursos se pueden personalizar mediante el paso de parámetros de la forma [::parámetro] [::parámetro ][…]. Algunos recursos requieren obligatoriamente ciertos parámetros de configuración para su funcionamiento. A continuación se muestra el ejemplo de una dirección IP:

ast1 IPaddr::192.168.21.87 asterisk

En el ejemplo se definen dos recursos en el cluster, en cuyo nodo primario (ast1) se ejecutarán los recursos. El primer recurso es una dirección IP y mediante el parámetro indicado, se especifica que la dirección sea 192.168.21.87. El otro recurso es asterisk.

A destacar que los recursos colocados en la misma línea forman un grupo de recursos (el concepto de grupo de recursos será visto posteriormente en el Punto 3-7 El archivo CIB.xml). En el ejemplo anterior ambos recursos conforman un grupo de recursos: IPaddr y asterisk.

El orden a la hora de listar los recursos en haresources también es importante. Los recursos son ejecutados (start) por Heartbeat de izquierda a derecha y parados (stop) de derecha a izquierda. No siempre es importante el orden de ejecución de los recursos, pero es importante tenerlo en mente ya que, para determinadas configuraciones y escenarios, los resultados pueden no ser los esperados.

3.5.4 Configuración de los Agentes de Recurso (RA)

Un Resource Agent (RA) o en español agente de recurso es un programa, generalmente un script, donde se define cómo el clúster ha de gestionar el recurso.

Nota: en el apartado 3-6 ¿Qué es un recurso? se amplía la definición y se hace referencia a

ejemplos para su mayor entendimiento.

Por tanto, como no existe un RA para asterisk, es necesario crear uno que lo gestione. Sin embargo, hasta el momento se está configurando Heartbeat-1 por lo que es suficiente con hacer uso del script de inicio de asterisk.

Nota: a continuación en la sección Configuración Heartbeat-2 se verá como activar la

funcionalidad de esta nueva versión.

Dado que los RA de Hearbeat han de situarse en /etc/ha.d/resource.d/ podemos copiarlo o simplemente crear un enlace simbólico desde /etc/ha.d/haresources/<nombre_recurso> al directorio /etc/init.d/<nombre_servicio>. El nombre de enlace simbólico ha de coincidir por tanto con el nombre que se indica en el archivo de configuración haresources.

El script de inicio de asterisk se encuentra en la documentación de las fuentes. En asterisk-1.4.18/contrib/init.d/ se encuentran diversos script de inicio para las distintas distribuciones. Por tanto, si no tenemos ya el script de inicio de asterisk en /etc/init.d/ lo copiamos y creamos en enlace simbólico a /etc/ha.d/resource.d

cp asterisk-1.4.18/contrib/init.d/rc.debian.asteris k /etc/init.d/asterisk

ln –s /etc/init.d/asterisk /etc/ha.d/resource.d/ast erisk

En la figura 4-5 Agentes de Heartbeat-1 se pueden ver los enlaces simbólicos creados para el servicio apache y asterisk.

Nota: el recurso IPaddr puede ser configurado con multitud de parámetros más tales como la

interfaz sobre la cual levantarla, máscara de red e incluso hasta con una dirección MAC

Virtual específica.

Figura 4-5. Agentes de Heartbeat-1

Ya se encuentra configurado nuestro sistema de alta disponibilidad para Asterisk. Hay que recordar que los ficheros hosts, ha.cf, haresources, authkeys, así como los enlaces simbólicos pertinentes realizados en /etc/ha.d/resource.d, han de existir y ser iguales (salvo opciones como la interfaz a usar para Heartbeat, etc) en todos los nodos del cluster.

Dado que Heartbeat va a ser el encargado de ejecutar los servicios que se le indiquen, en este caso una IP Virtual y asterisk, se ha de eliminar cualquier referencia de rcX.d para que los servicios no sean arrancados por el sistema al iniciarse. Para ello:

update-rc.d –f asterisk remove

Por último vamos a levantar el servicio Heartbeat en ambos nodos:

/etc/init.d/Heartbeat start

Tras el arranque de Heartbeat en ambos nodos, los recursos, en este caso, asterisk y la IP virtual arrancarán en el nodo primario que hayamos establecido después del tiempo de inicio que haya sido especificado (initdead). Sin embargo la configuración mostrada hasta ahora no hace uso de la nueva funcionalidad de Heartbeat-2. Para usar Heartbeat-2 no basta únicamente con instalar desde las fuentes o instalar desde un binario Heartbeat-2, es necesario activarlo durante la configuración del clúster.

3.5.5 Configurando Heartbeat-2

Para usar las nuevas funcionalidades ofrecidas por Heartbeat-2 se ha de activar el CRM o Cluster Resource Manager. Para activar el CRM se ha de editar de nuevo el archivo /etc/ha.d/ha.cf y añadir al final de este:

#CRM crm yes

Si tenemos activado Heartbeat-2, el lugar y forma en que se definen los recursos es diferente ya que una de las ventajas de Heartbeat-2 es que se tiene una mayor flexibilidad a la hora de configurar los recursos. Antes, los servicios a los que se pretende dotar de alta disponibilidad se definieron en el archivo haresources, pues bien, en Heartbeat-2, este archivo deja de utilizarse y se hace uso de un fichero XML. La manera más sencilla de crear este archivo XML, de nombre cib.xml, es hacer uso de un script el cual nos va a exportar nuestro actual haresources al nuevo formato definido en el archivo cib.xml. Para ello ejecutamos lo siguiente:

/usr/lib/Heartbeat/haresources2cib.py /etc/ha.d/har esources

El script haresources2cib.py exporta haresources al nuevo archivo cib.xml y lo sitúa en la ruta /var/lib/hearbeat/crm.

Sin embargo haresources2cib.py únicamente traslada la información indicada en haresources a cib.xml sin especificar ninguna de las nuevas funcionalidades ofrecidas por Heartbeat-2 de las que probablemente, se quiera hacer uso.

Para hacer uso de estas nuevas funcionalidades es necesario editar el fichero cib.xml. Sin embargo, antes de editar el contenido es importante tener ciertas nociones básicas de algunos conceptos, de cómo se estructura el archivo y qué se indica en él.

Atención: para editar cib.xml, el servicio Heartbeat ha de estar parado en todos los nodos del

clúster. Después, y en primer lugar, hay que borrar todo el contenido del directorio

/var/lib/Heartbeat/crm/, luego modificar el fichero cib.xml y arrancar Heartbeat de nuevo. Si

no se realiza en el orden correcto, no arrancará o incluso desestimará nuestros cambios

volviendo a la versión anterior que guarda a modo de copia de seguridad.

Por ello se recomienda continuar con la lectura del apartado 3-5-1 ¿Qué es un recurso?

donde se amplia el concepto de recurso y finalmente la lectura del apartado 3-7 El archivo cib.xml donde se explica y se muestran ejemplos de cómo hacer uso de las nuevas prestaciones de Heartbeat-2.

3.5.6 ¿Qué es un recurso?

Un recurso es la unidad básica a la que se puede dotar de alta disponibilidad. Un recurso es una abstracción, la cual puede ser de distintos tipos. Puede ser algo tan general como un servicio o tan concreto como un disco, un lector de tarjetas, o algo más abstracto como una dirección IP, reglas de un firewall, etc…

En definitiva un recurso debe soportar la realización de las siguientes operaciones básicas:

� Start. El recurso debe disponer de un estado en el que se considera que está iniciado, arrancado o activado.

� Stop. El recurso debe disponer de un estado en el que se considera que está parado o desactivado.

� Status. Es una funcionalidad donde se informa del estado actual del recurso en un momento determinado, es decir, si el recurso esta arrancado o parado.

� Monitor. El recurso debe disponer de una funcionalidad que permita de manera más o menos detallada, conocer el estado de ejecución del recurso cuando este se encuentra arrancado.

Como ya se ha comentado, un recurso es, por ejemplo, el servicio httpd. Es un servicio que se puede arrancar (httpd start), se puede parar (httpd stop), se puede consultar en que estado se encuentra (httpd status) y es posible conocer si se está ejecutando correctamente, por ejemplo, comprobado si existe un PID (identificador de proceso) asociado a httpd mediante el comando ps aux|grep httpd por ejemplo. Cierto es que comprobar solo si existe un PID asociado a http no es algo que nos pueda asegurar con garantía que el servicio se está ejecutando correctamente. Para comprobarlo de manera más detallada sería mejor enviar una petición GET y comprobar si la respuesta HTTP es OK. Ya sea con mayor o menor detalle, lo cierto es que es posible comprobar si el recurso se está ejecutando correctamente, cumpliendo así el requisito de disponer de la funcionalidad monitor vista anteriormente.

Otro nuevo concepto que es necesario conocer es el de agente de recurso (en inglés Resource Agente o RA). Un RA es un script donde se define como se va a realizar las funciones start, stop, status y monitor cumpliendo unos estándares tales como: LSB, OCF, etc. Por tanto para dar alta disponibilidad a un recurso es necesario definir su RA.

A modo de ejemplo ya que sabemos como arrancar, parar y monitorizar el servicio httpd por lo tanto las funciones de su RA se muestran en la tabla 4-5:

Tabla 4-4. Funciones de un agente de recurso

Función Implementación

Start Arrancar el servicio mediante /usr/sbin/httpd y comprobar si se ha creado el identificador de proceso correspondiente.

Stop Parar el servicio mediante killall httpd y comprobar que no exista ningún identificador de proceso asociado.

Status Sería una mezcla de los dos anteriores. Si el identificador de proceso existe, el servicio está start, mientras que si no existe el servicio se encuentra en estado stop.

Monitor Enviar una petición HTTP y ver si la respuesta HTTP es OK. Comprobar si el puerto 80 se encuentra abierto, etc…

Se puede implementar un agente de recurso que lleve a cabo las distintas funciones con un alto nivel de detalle y más profundidad. Esto es complejo ya que depende del conocimiento que tengamos sobre el determinado recurso, sin embargo un RA que conozca profundamente el servicio garantizará con mayor seguridad que el comportamiento o disponibilidad del servicio es el adecuado.

3.5.7 El archivo CIB.xml

El archivo CIB o Cluster Information Base almacena la información del clúster relacionada con los recursos: qué recursos ejecutar y en qué nodo, bajo qué condiciones, etc.

Básicamente, CIB divide su contenido en dos secciones:

� Sección configuración (estática)

� Sección estado (dinámica)

La sección de configuración contiene la configuración del clúster, es decir, las opciones que afectan al funcionamiento del clúster como un todo, los atributos de cada uno de los nodos, las instancias de configuración de los recursos, y las restricciones entre los recursos. Esta sección es identificada con una marca de tiempo con objeto de identificar cuál es la configuración más reciente del clúster.

Por otro lado, la sección de estado es generada y actualizada de manera dinámica por CRM y representa la información referente al estado actual del clúster en un momento dado. La información que se indica en esta sección corresponde a qué nodos están activos, qué nodos han fallado, en qué nodo se encuentra cierto recurso, etc. Esta parte dado que es actualizada por CRM y nunca ha de ser modificada manualmente. Por ejemplo, si hemos reparado un nodo que previamente había fallado, nunca se ha de modificar manualmente la información dinámica en todo caso se hará uso de las utilidades de administración que ofrece Heartbeat.

La estructura del archivo cib.xml presenta el siguiente aspecto:

<cib> <configuration> # Inicio sección configuración <crm_config/> <nodes/> <resources/> <constraints/> </configuration> # Fin sección configuración <status/> # Sección estado </cib>

Como se puede apreciar en el código anterior, la sección de configuración (estática) se divide a su vez en varias secciones:

� Opciones de configuración del cluster

� Nodos

� Recursos

� Restricciones o relación entre los recursos

A continuación se detallan cada una de sus subsecciones.

Opciones de configuración del cluster

En esta primera sección se definen las opciones o propiedades que determinan el comportamiento del clúster, el comportamiento del cluster como conjunto.

Las opciones o propiedades del clúster se indican mediante una lista de tags nvpair.

<crm_config> <cluster_property_set id=”cib-bootstrap-options”> <attributes> <nvpair id="1" name="cib-bootstrap-options-clu ster-delay" value="120s"/> </attributes> </cluster_property_set> </crm_config>

El valor del atributo id puede ser seleccionado libremente, con la precaución de que, como todo identificador en XML, éste debe ser único. El atributo name indica la propiedad del cluster al vamos a dar valor.

A continuación se muestra un listado con algunas de las propiedades que pueden especificarse para el cluster.

� action-idle-timeout. Especifica el timeout o máximo tiempo global que dispone el RA para realizar una operación. Ya se han visto las operaciones que tiene que realizar un RA de tal manera que si se establece un timeout de 60 segundos para realizar, por ejemplo, la operación monitor, si establecemos el atributo del cluster action-idle-timeout, el timeout de toda operación que se tenga definida será sobrescrito por el valor establecido en action-idle-timeout.

� symmetric_cluster. Si es true, a los recursos se le permite correr en cualquier nodo. Si por el contrario es false, se tiene que especificar una restricción (ver Sección Restricciones o relación entre los recursos) para indicar explícitamente dónde pueden ejecutarse. Por defecto su valor es true.

� stonith_enabled. Permite habilitar o deshabilitar el NodeFencing. NodeFencing es lo que se conoce vulgarmente como “disparo en la cabeza” y no es más que permitir que el un dispositivo adicional al cluster pueda reiniciar o apagar un nodo en caso de fallo. Es necesario su uso ya que un nodo a pesar de ser considerado por todo el clúster como un nodo muerto es posible que no haya podido liberar los recursos que mantenía, afectando a aquellos recursos que no pueden ser compartidos. Si se habilita a true en caso de fallo los nodos podrán ser

fenced. Por tanto se requiere configurar un recurso stonith para llevar a cabo esta acción. Por defecto está establecido a false.

� stonith_action. Determina la acción del dispositivo stonith, pudiéndose elegir entre reboot u off. Reboot hará que el nodo se reinicie mientras que off obligará al nodo a apagarse. Lo más habitual es que el valor sea reboot.

� default_stickiness. Establece si los recursos prefieren ejecutarse en el nodo actual o ser movidos a otro nodo en el cual se han ejecutado en mejores condiciones con anterioridad. Se pueden establecer diversos valores:

o 0. Es el valor neutro de tal manera que los recursos no tienen predilección por ejecutarse en un nodo o en otro. Esta opción es casi equivalente a auto_failback a excepción de que el recurso puede ser movido a otros nodos distintos de aquel en el que previamente se encontraba activo.

o >0. Los recursos prefieren permanecer en el nodo en el que actualmente se encuentran pero pueden ser movidos si otro nodo más conveniente se encuentra disponible. Cuanto mayor sea este valor mayor preferencia tendrá el recurso por mantenerse en el nodo en el que se encuentra actualmente.

o <0. Los recursos prefieren moverse a otro nodo del clúster en lugar de permanecer en el que se encuentran. Cuanto menor sea este valor mayor será la preferencia de los recursos por abandonar el nodo en el que se encuentran actualmente ejecutándose.

o INFINITY. Los recursos siempre permanecerán es el nodo actual a menos que este deje de estar operativo. Esta opción es casi equivalente a auto_failback a excepción de que el recurso puede ser movido a otros nodos distintos de aquel en el que previamente se encontraba activo.

o –INFINITY. Los recursos nunca se ejecutarán en el nodo, siempre intentarán moverse a otros nodos.

� is_managed_default. Permite establecer si se desea administrar manualmente el clúster para poder realizar el mantenimiento de éste: mover los recursos de un nodo a otro, pararlos, arrancarlos, etc. Si el valor es true los recursos son arrancados, parados, monitorizados, movidos, etc, si es necesario. Si por el contrario, el valor es false, los recursos no son levantados si están parados, parados si están levantados, o cualquier otra acción prevista o programada. Por defecto el valor es true.

� stop_orphan_resources. Define la acción a realizar sobre los recursos para los cuales no tienen actualmente una definición. Esto puede ocurrir, por ejemplo, cuando el administrador elimina un recurso mediante una utilidad de administración del cluster sin que el recurso sea previamente parado. El recurso ya no es gestionado por el cluster, pero el proceso sí que se encuentra ejecutándose en el nodo. Si el valor es true el recurso se detiene a la vez que se elimina del cluster, si por el contrario el valor es false, el recurso se eliminará del cluster sin previamente detenerse. Por defecto el valor es true.

� short_resource_names. Para tener compatibilidad con versiones anteriores a las 2.0.2 las cuales no obligaban a un único id para cada tipo de tag. Por defecto su

valor está establecido a false pero es recomendable establecerlo a true. El clúster debe estar completamente parado antes de modificar este valor.

Nodos

En esta sección se establecen los nodos que conforman el cluster. Cada nodo se identifica mediante el nombre de host y un identificador. Esta sección es completada automáticamente por haresources2cib.py, por lo que no es necesaria ninguna intervención por nuestra parte.

Recursos

Vamos a ver la manera en la que se configuran los recursos en el archivo cib.xml, con objeto de poder conocerlos mejor y configurarlos de la forma más adecuada a la especificación requerida.

Los recursos, como por ejemplo una dirección IP, un servidor Web, etc, sabemos que son controlados por RA siguiendo diversos estándares: LSB, OCF o Legacy.

Aquí se muestra un ejemplo básico de cómo agregar un recurso al cluster que va a ser controlado por un agente OCF.

<primitive id="IPServidorWeb_1" class="ocf" provide r="Heartbeat" type="IPaddr"> <operations> <op id=”IPServidorWeb_1_mon” interval=”5s” name=”m onitor” timeout=”5s” /> </operations> <instance_attributes id=”=“IPServidorWeb_1_inst _attr”> <attributes> <nvpair id=“IPServidorWeb_1_attr_0” nam e="ip" value="127.0.0.26"/> </attributes> </instance_attributes> </primitive>

Nota: la configuración del recurso mostrada es de un agente de recurso que sigue el estándar

OCF, por lo que puede haber ligeras modificaciones respecto de hacer uso de otros

estándares. Por ejemplo, los agentes de recursos OCF pueden aceptar parámetros de entrada

si es necesario mientras que LSB no puede tomarlos. Los agentes STONITH son muy parecidos

a los agentes OCF.

Un recurso en el cluster se define entre las etiquetas <primitive> y </primitive>. En ella el valor del atributo id puede ser seleccionado libremente y, al igual que todos los IDs en XML, este debe ser único, y si nos fijamos siempre se le van añadiendo a los posteriores IDs de las siguientes etiquetas ciertos caracteres que lo diferencian.

Los tres atributos siguientes: class, type y provider determinan el RA o agente de recurso que va a encargarse de gestionar el recurso. En la Tabla 4-6 Atributos class, provider y type se muestra el significado de estos atributos.

Tabla 4-5. Atributos class, provider y type

Atributo Valor Significado

Heartbeat

El directorio donde se encuentra el RA es /etc/ha.d/resource.d

lsb

El directorio donde se encuentra el RA es /etc/init.d class

ocf

Directorio relativo donde se encuentra el RA, siendo el directorio base /usr/lib/ocf/resource.d/<provider>

type

----- Nombre del RA

El RA del recurso WebServer_IP_1 que se ha definido se ha de encontrar en /usr/lib/ocf/resource.d/Heartbeat con el nombre IPaddr y escrito siguiendo el estándar OCF.

Entre las etiquetas <instance_attributes> e </instance_attributes> representa dónde se va a dar lugar la instanciación de los atributos del agente del recurso, en otras palabras, son los parámetros de entrada del RA. Todos los atributos que requiere el agente son introducidos en forma de lista como tags nvpair tras la etiqueta <attributes>. En el ejemplo anterior, el nombre del argumento de entrada ip tiene como valor 127.0.0.26. Para este RA es obligatorio indicar este parámetro ya que gestiona un recurso de una dirección IP Virtual y, por tanto, requiere conocer la dirección. Pasar más parámetros es posible siempre que se indiquen entre las etiquetas <attributes>.

Por último hacer referencia a la etiqueta <operations> que representa las acciones u operaciones que va a realizar el agente del recurso. Heartbeat-2 soporta las acciones start, stop y status, al igual que Heartbeat-1 y añade además la acción monitor.

Las acciones se listan entre etiquetas <op> y </op> especificando en su interior la acción en sí. Una acción básicamente se define por los atributos indicados en la Tabla 4-7 Atributos básicos de una acción.

En la tabla 4-6 se muestran los parámetros que se deben especificar a la hora de definir la acción para un recurso.

Tabla 4-7. Atributos básicos de una acción

Atributo Significado

name Acción a realizar de entre las distintas que nos permite el agente del recurso: start, stop y monitor generalmente.

interval Tiempo que tiene que transcurrir entre acción y acción.

timeout Tiempo máximo que puede transcurrir antes de considerar la acción fallida.

Las acciones start y stop son ejecutadas por defecto a diferencia de la acción monitor que hay que especificarla en caso de querer ejecutarla. Sin embargo las acciones start y stop pueden establecerse en el caso de que quiera personalizarse su comportamiento.

<primitive id="ServidorNombres" class="lsb" type="n amed"> <operations> <op id="1" name="stop" timeout="3s"/> <op id="2" name="start" timeout="5s"/> <op id="3" name="monitor" interval="10s" t imeout="3s"/> <op id="4" name="monitor" interval="1min" t imeout="5s"/> </operations> </primitive>

Restricciones o relación entre los recursos

Para que funcione correctamente el sistema, es necesario especificar cierta información adicional para que los recursos del sistema queden completamente configurados. Esta información a la que nos referimos son las restricciones o la relación entre los recursos. Por ejemplo, una restricción podría ser en qué nodo hay que arrancar inicialmente el servicio MySQL, ya que arrancar MySQL en un nodo del cluster distinto al nodo que ejecuta el servicio httpd sería inútil para nuestra página PHP, siempre y cuando la página PHP requiera de manera local la base de datos.

En Heartbeat-2 existen tres tipos de restricciones disponibles:

� Restricciones de lugar. Definen en qué nodos puede ejecutarse un recurso.

� Restricciones de colocación. Indican al clúster qué recursos corren en el mismo nodo y cuáles no pueden hacerlo.

� Restricciones de orden. Definen en qué orden realizará cada RA una acción, como por ejemplo, en qué orden comienzan a ejecutar los recursos.

Restricciones de lugar.

La restricciones de lugar definen en qué nodos puede correr un recurso. Una restricción de lugar se define entre la etiqueta <rsc_location> y </rsc_location>. Además se requiere de una <rule> donde se indicará la preferencia del recurso por correr en un nodo y una etiqueta <expression> que evaluará una determinada condición. En caso de que la <expression> (expresión) sea cierta, se aplicará la preferencia establecida en la <rule> (regla).

Un sencillo ejemplo, que incrementa la probabilidad del recurso con identificador filesystem_1 a ejecutarse en el nodo de nombre tierra mediante una puntuación de 100, puede ser el siguiente:

<rsc_location id="filesystem_1_location" rsc="files ystem_1"> <rule id="pref_filesystem_1" score="100"> <expression attribute="#uname" id=” pref_file system_1_exp” operation="eq" value="tierra"/> </rule> </rsc_location>

El contenido de rsc es el identificador del recurso sobre el cual se establece la restricción. El atributo score establece la prioridad del recurso por ejecutarse en un nodo, ya que Heartbeat-2 dispone de un sistema de puntuaciones que indican la prioridad que tiene un recurso por ejecutarse en un determinado nodo del cluster. Para más información ver el apartado 3-6 Funcionamiento interno de Heartbeat-2.

La regla se activa dependiendo del resultado de la evaluación de la expresión. Si la regla finalmente se activa, la puntuación del recurso se verá modificada en función del valor score. Por ejemplo, si el nombre del nodo es igual a tierra, la expresión es válida y por tanto la regla se activa haciendo que la prioridad del recurso filesystem_1 para ejecutarse en el nodo tierra aumente en 100 unidades.

A continuación se muestra otro ejemplo donde se indica la gran flexibilidad que ofrecen las restricciones:

<rsc_location id="run_IPServidorWeb" rsc="IPServido rWeb"> <rule id="pref_run_IPServidorWeb" score="INFINI TY"> <expression attribute="#uname" operation="e q" value="c001n01"/> </rule> <rule id="pref_run_IPServidorWeb" score="-INFIN ITY"> <expression attribute="#uname" operation="n e" value="c001n01"/> </rule> </rsc_location>

En el ejemplo se establece que el recurso IPServidorWeb sólo puede ejecutarse en el nodo de nombre c001n01 y no en ningún otro.

Restricciones de colocación.

La restricción de colocación se utiliza para definir qué recursos tienen que correr en el mismo nodo y cuáles no pueden hacerlo.

La sintaxis es muy sencilla ya que sólo es necesario especificar dos recursos mediante su identificador y una puntuación que indica si pueden correr o no juntos en el mismo nodo. Actualmente la puntuación solo es posible indicarla como INFINITY (deben correr en el mismo nodo) o –INFINITY (no deben correr en el mismo nodo).

El ejemplo de una restricción de colocación que establece que los recursos de identificadores filesystem_resource y nfs_group deben correr siempre en el mismo host se muestra a continuación:

<rsc_colocation id="nfs_on_filesystem" to="filesystem_resource" from="nfs_group" scor e="INFINITY"/> </rsc_location>

Hay que tener en mente la direccionalidad de la restricción, ya que la restricción establece que el recurso indicando en el parámetro from se ejecute siempre en el mismo nodo que el recurso especificado en el parámetro to, y no al contrario.

Restricciones de orden

Las restricciones de orden establecen el orden en que los recursos deben iniciarse (start) y pararse (stop). En algunos escenarios es necesario establecer este orden, por ejemplo, no es posible montar un sistema de archivos sin que previamente se encuentre disponible en el sistema la unidad donde va a ser montado.

Para definir una restricción de orden se utiliza la etiqueta <rsc_order>.

<rsc_order id="nfs_after_filesystem" from="group_nf s" action="start" to="filesystem_resource" to_action="start" ty pe="after"/>

Hay que prestar especial atención al tipo de restricción, ya que type=after indica que la acción del recurso from se realiza después de la acción del recurso to. En este caso group_nfs

comenzará a ejecutarse (acción start) después de completar la acción start del recurso filesystem_resource.

3.5.8 Otras posibles configuraciones

Hasta el momento se ha visto como realizar una configuración básica de Heartbeat-2, de modo que mientras el número de recursos a configurar y el comportamiento que se le exija, tanto a estos como al cluster, no sea muy especifico, es más que suficiente. Sin embargo si necesitamos dotar de alta disponibilidad a muchos servicios se hacen necesarios mecanismos adicionales de configuración que faciliten la tarea.

Supongamos que vamos a dotar de alta disponibilidad a tres recursos: un servicio Web, un servicio de base de datos y una IP Virtual mediante la cuál accederán los clientes externos al portal que hemos creado para nuestra empresa. Si analizamos la situación en la que estos recursos han de funcionar podemos observar el siguiente comportamiento:

� Tanto el servicio Web, el servicio de base de datos como la IP Virtual deben ejecutarse siempre juntos en el mismo nodo, ya que el servicio Web sin base de datos no puede funcionar, y del mismo modo, si la dirección IP Virtual no se encuentra levantada en el nodo donde se encuentran los servicios ejecutándose, los clientes no pueden acceder al servicio.

� Entre los tres servicios existe un cierto orden lógico para comenzar a ejecutarse. No tiene sentido tener la dirección IP Virtual levantada y aún no tener ejecutándose ninguno de los dos servicios. El resultado sería que los clientes podrían alcanzar la dirección IP pero no se ofrecería ningún servicio en ella. Además el servicio Web requiere que previamente haya sido ejecutado el servicio de base de datos ya que si los clientes acceden al servicio Web, la página Web no va a mostrar contenido ya que las consultas no pueden llevarse a cabo.

Estas restricciones se pueden establecer con lo que se ha visto hasta el momento, sin embargo, es cierto que el número de restricciones resultantes va a ser elevado, y no pensemos en la posibilidad de además de tener estos tres servicios se tengan otros tres servicios más que cumplan estas mismas restricciones de comportamiento y además ambos conjuntos no puedan ejecutarse en el mismo nodo.

Heartbeat-2 solventa estos inconvenientes de configuración permitiendo agrupar los recursos para formar un grupo entre sí, a lo que denomina “grupo de recursos”. Principalmente la finalidad de hacer un grupo de recursos es:

� Los recursos del grupo siempre se ejecutan en el mismo nodo. Cada recurso del grupo tendrá implícita una restricción de colocación con el resto de recursos.

� Los recursos del grupo siempre arrancan y paran en un determinado orden. Cada recurso tendrá implícita una restricción de orden.

Esto facilita enormemente la configuración y posterior mantenimiento del cluster aunque se crea una desventaja, y es que perdemos el gran potencial que se tiene cuando se definen de manera individual cada una de las restricciones para cada uno de los recursos, sin embargo, personalmente opino que para la mayoría de las situaciones las ventajas son mucho más interesantes.

Hay que recordar que si en el archivo haresources se escriben los recursos en una misma línea se está definiendo automáticamente un grupo de recursos, es decir, por cada

línea a modo de listado de recursos en haresources se crea un grupo de recursos, donde los recursos además se ejecutarán en el orden en el que se listen, de izquierda a derecha y pararan secuencialmente en orden inverso, de derecha a izquierda.

Continuando con el ejemplo anterior, se muestra a continuación cómo definir los recursos para formar con ellos un grupo. Por lo tanto, estos recursos comenzarán y siempre se ejecutarán en el mismo nodo además de comenzar y parar en el orden en que se declaren dentro del grupo.

<group id="MiEmpresaWWW"> <primitive id="IPServidorWeb" class="ocf" type="I Paddr" provider="Heartbeat"> <instance_attributes> <attributes> <nvpair name="ip" value="127.0.0.26"/> </attributes> </instance_attributes> </primitive> <primitive id="ServidorBaseDatosWeb" class="lsb" type="oracle" provider="Heartbeat"> <instance_attributes> <attributes> <nvpair name="SID" value="servidorweb_db"/> </attributes> </instance_attributes> </primitive> <primitive id="ServidorWebApache" class="ocf" typ e="Apache" provider="Heartbeat"> <instance_attributes> <attributes> <nvpair name="apache_config" value="/home/www.miempresa.com/conf/apache.conf"/> </attributes> </instance_attributes> </primitive> </group>

Como se puede apreciar en el ejemplo, hay que definir una serie de recursos de manera individual con la diferencia de que la definición de los recursos va entre las etiquetas <group> y </group>.

Del mismo modo que para un recurso individual, a los grupos de recursos también se le pueden definir restricciones. El concepto de restricción es el mismo que para un recurso individual salvo que ahora se establece a más de un recurso simultáneamente. La mejor manera de definir correctamente las restricciones para un grupo de recursos es pensar como si se tratara de un recurso individual, aunque de mayor abstracción, pero al fin y al cabo un recurso individual.

Por ejemplo, si se quiere que el portal Web de nuestra empresa comience inicialmente a ejecutarse en el nodo luna, la restricción de localización sería como sigue:

<constraints> <rsc_location id="run_MiEmpresaWWW" rsc="MiEmpresaW WW"> <rule id="pref_run_IPServidorWeb" score="100"> <expression attribute="#uname" operation= "eq"

value="luna"/> </rule> </rsc_location>

</constraints>

Ahora el valor del atributo rsc es el identificador del grupo al cuál se va a aplicar dicha restricción. En el ejemplo el identificador del grupo es “MiEmpresaWWW”.

Para el resto de restricciones la filosofía con grupos de recursos es lo mismo que para recursos individuales.

Si para los recursos se puede crear un grupo de recursos, para los nodos sucede lo mismo. Varios nodos pueden agruparse formando un conjunto de nodos entre sí lo que facilita enormemente la configuración del cluster para aquellos casos en los que se tienen un gran número de nodos en el cluster.

Por ejemplo, supongamos un cluster se compone de 27 nodos: un nodo A, B,…., Z y el recurso IPServidorWeb. Si un determinado recurso R no puede ejecutarse en los nodos que van desde el M hasta el Z no es necesario establecer una restricción de localización como la que se muestra a continuación para cada uno de los nodos:

<rsc_location id="run_IPServidorWeb" rsc="IPServido rWeb"> <rule id="pref_run_IPServidorWeb" score="-INFIN ITY"> <expression attribute="#uname" operation="n e" value="nodoX"/> </rule> </rsc_location>

Simplemente se define un grupo de nodos formado por los nodos del M al Z y con una única restricción de localización indicando en el atributo value el nombre del grupo de nodos.

<nodes> <node id="f67904e0-4dfc-4db1-83a2-e930fc1d20f4" u name="nodoA" type="member"> <instance_attributes> <attributes> <nvpair name="cluster_group" value="grupo_n odos_1"/> </attributes> </instance_attributes> </node> … <node id="c2896699-96b8-4dbc-a94e-6c3b9252b559" u name="nodoZ" type="member"> <instance_attributes> <attributes> <nvpair name="cluster_group" value="grupo_n odos_1"/> </attributes> </instance_attributes> </node> </nodes> <constraints> <rsc_location id="run_IPServidorWeb" rsc="IPServ idorWeb"> <rule id="pref_run_IPServidorWeb" score="-I NFINITY">

<expression attribute="#uname" operati on="ne" value="grupo_nodos_1"/> </rule> </rsc_location> </contraints>

Heartbeat-2 dispone además de muchos otros mecanismos que permiten configurar el cluster de alta disponibilidad a nuestra medida: Stonith, Softdog, etc. Uno de los más útiles es pingd, que sustituye a IPFail de Heartbeat-1, de tal manera que si una interfaz cae o la red a la que estamos conectados no es alcanzable debido a un problema de algún dispositivo hardware o por la presencia de un cortafuegos, se puede establecer que los recursos del nodo que ha perdido la conectividad migren a otro nodo o migren simplemente al nodo con mayor conectividad. Pingd realiza su función en colaboración con los PingNodes. En la figura 4-6. IPFail Heartbeat se muestra un escenario donde se hace uso de dos interfaces, una de ellos para mantener la comunicación con el otro nodo del cluster y la otra para mantener conectividad con el PingNode además se puede ver como en caso de pérdida de conectividad con el PingNode, los recursos pasan a ser responsabilidad del otro nodo.

Figura 4-6. IPFail Heartbeat

3.6 Funcionamiento de Heartbeat

En el apartado anterior 3-5 Configurar Heartbeat-2 se vio como en las restricciones se establecían una determinadas puntuaciones para indicar que un recurso debe ejecutarse en un nodo antes que en otro, que dos recursos han de ejecutarse siempre juntos, etc… esto no es más que una prioridad del recurso por ejecutarse en un determinado nodo. Heartbeat-2 internamente maneja un sistema de puntuaciones donde cada recurso dispone de una puntuación o prioridad para ejecutarse en cada nodo y aquellos nodos con mayor puntuación para cada recurso toman el privilegio de ejecutar un determinado recurso.

Por ejemplo, un cluster de dos nodos, nodo A y nodo B, en el que se tienen definidos dos recursos: un servicio de correo y un servicio DNS. Heartbeat-2 mantendría la siguiente tabla de puntuación:

Tabla 4-8. Tabla de puntuación

Recurso Nodo Puntuación

Servidor de correo A 100

Servicio de correo B 50

Servicio DNS A 75

Servicio DNS B 65

Por tanto el servicio de correo así como el servicio DNS se ejecutan en el nodo A, ya que es el nodo con mayor puntuación para cada recurso. Sin embargo estas puntuaciones pueden ir modificándose, si así lo deseamos, debido a situaciones en las que se producen fallos en el nodo haciendo que la prioridad que tiene un recurso por ejecutarse en el nodo aumente o por el contrario disminuya. En el siguiente apartado se muestra como Heartbeat-2 tiene en cuenta estos aspectos.

3.6.1 El cálculo de puntuación de un recurso en un nodo

Básicamente, el cálculo se realiza de la siguiente manera:

� Por defecto todos los recursos tienen una puntuación de cero.

� La puntuación puede ser un valor numérico positivo o negativo. Este puede ser también INFINITY (mayor valor posible) o –INFINITY (menor valor posible).

� Cada recurso tiene una puntuación para cada nodo, inicialmente establecida en las distintas restricciones de localización.

� El nodo con mayor puntuación será el que ejecute el recurso.

� El nodo con una puntuación negativa nunca intentará tomar la ejecución del recurso. Es algo muy importante que debemos tener siempre en mente.

� Si la preferencia del recurso por un nodo cambia a un valor mayor que la preferencia que se tiene por el nodo en el que se está ejecutando hasta el momento, o un nuevo nodo entra a formar parte del cluster y obtiene la mayor puntuación para el recurso, el recurso migrará a éste (si el recurso no tiene restricciones de colocación que se lo impida).

� Si la preferencia del recurso por el nodo en el que se está ejecutando se reduce y existe un nodo con una preferencia mayor, el recurso migrará a éste.

La puntuación irá modificándose, o bien aumentado o disminuyendo según el atributo resource_stickiness y el atributo resource_failure_stickiness respectivamente.

� resource_stickiness. Indica la preferencia de un recurso de permanecer en el nodo, traduciendo literalmente, la “pegajosidad” que tiene el recurso de permanecer en el nodo. El valor asignado debería ser >=0, ya que un valor negativo, aunque es permitido, no tiene sentido. Si se establece el valor INFINITY el recurso siempre permanecerá ejecutándose en el nodo independientemente de resource_failure_stickiness ya que INFINITY +/- num = INFINITY

� resource_failure_stickiness. Es una penalización que se refleja en la puntuación del recurso si este falla al ejecutarse en el nodo. El valor asignado debería ser <=0, ya que un valor positivo aunque es permitido no tiene sentido. Si se establece el valor a –INFINITY el recurso dejará de ejecutarse en el nodo actual ante el primer fallo que se produzca ya que -INFINITY +/- num = -INFINITY.

Estos pueden ser establecidos de manera global para todos los recursos. Para ello han de indicarse en la sección crm_config de CIB.

<nvpair id="default-resource-stickiness" name="defa ult-resource- stickiness" value="100"/> <nvpair id="default-resource-failure-stickiness" na me="default-resource-failure-stickiness" value="-100"/>

Aunque también pueden ser especificados para cada recurso. Para ello es necesario definirlos como meta_attributes:

<primitive> <meta_attributes id="ma-webserver">

<attributes> <nvpair name="resource_stickiness" id="ma-1" v alue="100"/> <nvpair name="resource_failure_stickiness" id= "ma-2" value="-100"/> </attributes>

</meta_attributes> </primitive>

Nota: se pueden definir meta_attributes para un grupo de recursos.

Si no se especifican resource_stickiness y/o resource_failure_stickiness se usarán entonces los valores globales por defecto default-resource-stickiness y/o default-resource-failure-stickiness, respectivamente.

Veamos cuando afectan estos atributos a la puntuación o prioridad de permanecer un recurso en un nodo:

� Cada vez que un determinado recurso es arrancado con éxito en un nodo, el valor de resource_stickiness será añadido a la puntuación del recurso en dicho nodo particular.

� Si un recurso falla en un nodo, el valor de resource_failure_stickiness será añadido tanta veces como el número de fallos ocurridos en dicho nodo (ya que los fallos ocurridos en cada nodo se acumulan para cada recurso) a la puntuación del recurso en el nodo. Hay que recordar que su valor es negativo.

3.6.2 Ejemplos de cálculo de puntuaciones en diversos escenarios

Escenario 1

Supongamos un cluster formado por tres nodos: ACE, King y Queen. El recurso al que van a dar servicio es WebServer. Vamos a tener en cuenta la siguiente consideración: para ejecutar el recurso WebServer tenemos como primera preferencia el nodo ACE aunque también puede correr en el nodo King. Sin embargo en Queen no debe correr.

Conocido ya el escenario podemos definir las restricciones de localización:

<constraints> <rsc_location id="rscloc-webserver" rsc="web server"> <rule id="rscloc-webserver-rule-1" s core="200"> <expression id="rscloc-webse rver-expr-1" attribute="#uname" operation="eq" value="ace"/> </rule> <rule id="rscloc-webserver-rule-2" score ="150"> <expression id="rscloc-webse rver-expr-2" attribute="#uname" operation="eq" value="king"/> </rule> <rule id="rscloc-webserver-rule-3" s core="-100"> <expression id="rscloc-webse rver-expr-3" attribute="#uname" operation="eq" value="queen"/> </rule> </rsc_location> </constraints>

Hasta el momento, en este escenario no vamos a hacer uso de los atributos resource_stickiness y default_resource_stickiness.

Entonces según las restricciones que se han definido, inicialmente las puntuaciones se encuentran de la siguiente manera:

Tabla 4-9. Puntuaciones iniciales

Recurso Nodo Puntuación

WebServer ACE 200

WebServer King 150

WebServer Queen -100

Como se puede ver a través de la puntuación el recurso WebServer va a comenzar en ACE. Supongamos ahora que previamente si que teníamos definidos los atributos resource_stickiness y default_resource_stickiness con los valores 100 y -100 respectivamente. Se muestra el <crm_config> resultante:

<crm_config> <cluster_property_set id="cib-bootstrap-options "> <attributes> <nvpair name="default-resource-stickine ss" id="default-resource-stickiness" value="100"/> <nvpair name="default-resource-failure- stickiness" id="default-resource-failure-stickiness" value="-10 0"/> </attributes> </cluster_property_set> </crm_config>

Con esta nueva configuración del cluster y sabiendo que el recurso comenzó a ejecutarse correctamente en ACE la puntuación sería entonces:

ACE = (puntuación_restricciones) + (resource_stickiness) +

(nºfallos * (resource_failure_stickiness))

ACE = 200+100+ (0*(-100))

La puntuación quedaría finalmente:

Tabla 4-10. Puntuación final

Recurso Nodo Puntuación

WebServer ACE 300

WebServer King 150

WebServer Queen -100

Como el recurso ha arrancado correctamente en ACE el valor de resource_stickiness se suma a la puntuación o preferencia por dicho nodo.

Escenario 2

Continuando con el escenario 1, supongamos que la operación que está monitorizando el estado del recurso WebServer informa de un error (hay que tener en cuenta que un error es distinto a que el recurso no esté ejecutándose) por lo hay que recalcular de nuevo todas las puntuaciones ya que el recurso tiene que ser arrancado de nuevo:

ACE = (puntuación_restricciones) + (resource_stickiness) +

(nºfallos * (resource_failure_stickiness))

ACE= 200+100+ (1*(-100))

Tabla 4-11. Puntuación tras el error

Recurso Nodo Puntuación Errores

WebServer ACE 200 1

WebServer King 150 0

WebServer Queen -100 0

Dado que se ha producido un error en el servicio WebServer, el recurso es parado para ser arrancado de nuevo. Debido a que la mayor puntuación la vuelve a tener el nodo ACE el recurso WebServer arranca de nuevo en este mismo nodo.

Imaginemos que de nuevo se vuelve a producir un nuevo error durante la ejecución del recurso.

ACE = (puntuación_restricciones) + (resource_stickiness) +

(nºfallos * (resource_failure_stickiness))

ACE = 200 + 100 + (2 * (-100))

Tabla 4-12. Puntuación tras otro nuevo error

Recurso Nodo Puntuación Errores

WebServer ACE 100 2

WebServer King 150 0

WebServer Queen -100 0

Igual que antes el recurso WebServer para, pero esta vez para arrancar selecciona el nodo King dado que tiene una mayor puntuación.

Según la definición de resource_stickiness este atributo aumenta la puntuación si el servicio arranca con éxito en el nodo. Por tanto si WebServer arranca con éxito en King se le ha de sumar el valor de resource_stickiness a la puntuación o prioridad por el nodo King, sin olvidar que a ACE ya no hay que sumárselo:

ACE = (puntuación_restricciones) + (nºfallos * (resource_failure_stickiness))

ACE = 200 + (2 * (-100))

King = (puntuación_restricciones) + (resource_stickiness) +

(nºfallos * (resource_failure_stickiness))

King = 150 + 100 + (0 * (-100))

Tabla 4-13. Puntuación tras cambiar el recurso de nodo

Recurso Nodo Puntuación Errores

WebServer ACE 0 2

WebServer King 250 0

WebServer Queen -100 0

Podemos apreciar como el recurso a pesar de haberse ejecutado más veces en el nodo ACE no le da ninguna importancia a este hecho a la hora de calcular las puntuaciones aunque por el contrario si que tiene en cuenta las veces que ha tenido un error.

Escenario 3

Ahora volvamos al escenario 1, es decir, no ha ocurrido ningún error y el recurso acaba de arrancar con éxito en el nodo ACE.

Durante una operación de monitorización del recurso realizada por el RA de WebServer se informa que el recurso no está ejecutándose. Ello obliga a recalcular de nuevo las puntuaciones:

ACE = (puntuación_restricciones) + (nºfallos * (resource_failure_stickiness))

ACE = 200 + (1 * (-100))

Tabla 4-14. Puntuación tras no ejecutarse

Recurso Nodo Puntuación Errores

WebServer ACE 100 1

WebServer King 150 0

WebServer Queen -100 0

A destacar que resource_stickiness no se suma ya que tal y como indica su definición este atributo solo incrementa la puntuación del recurso en el nodo si el recurso ha sido previamente arrancado con éxito en el nodo. Sin embargo, el hecho de no estar ejecutándose, sí que se considera como un error ya que resource_failure_stickiness tiene valor uno.

De nuevo, y siguiendo los mismos pasos vistos anteriormente, el recurso para, comprueba que el nodo con mayor puntuación es King y comienza a arrancar en él. Finalmente, el recurso arranca con éxito en King.

King = (puntuación_restricciones) + (resource_stickiness) +

(nºfallos * (resource_failure_stickiness))

King = 150 + 100 + (0 * (-100))

Tabla 4-15. Puntuación tras arrancar con éxito

Recurso Nodo Puntuación Errores

WebServer ACE 100 1

WebServer King 250 0

WebServer Queen -100 0

A diferencia del escenario anterior, ACE no se ve esta vez modificado ya que no hay que calcular una nueva puntuación sin resource_stickiness puesto que no lo arrancó con éxito.

En definitiva que un recurso no esté arrancado se considera como un error, con la diferencia que el valor de resource_stickiness si se añadiría a la puntuación si arrancó con éxito.

3.7 Principales problemas

Uno de los principales problemas de Heartbeat, en general de los cluster de alta disponibilidad, es el SplitBrain. A continuación, en el siguiente apartado, se muestra una situación SplitBrain para posteriormente ver las distintas soluciones existentes para evitarlo.

3.7.1 SplitBrain

Supongamos el escenario de la figura 4-7. Un cluster formado por seis nodos, tres de ellos conectados con un switch A y los otros tres conectado con un switch B. Un switch C conecta, el switch A con el B para que todos los nodos del cluster puedan comunicarse entre sí.

Figura 4-7. Escenario SplitBrain

El SplitBrain en este cluster puede suceder, por ejemplo, si el switch A se rompe esto hace creer a los nodos del switch A que los nodos del switch B han muerto y viceversa, por lo que cada nodo procede a tomar los recursos del otro, de tal manera que ocurre lo que se conoce como “partición del cluster”, ya que todos los servicios que ofrece una parte del cluster son ofrecidos por la otra parte. Supongamos en nuestro cluster que los tres nodos del switch B ofrecen respectivamente: un servidor Web, un servidor de correo, y un servicio Ftp. Los nodos del switch A son respectivamente los nodos que van a tomar los recursos en caso de fallo. Si el switch A falla los nodos del swtich B no podrán comunicarse con los del switch A y por tanto pensarán que han muerto. Esto hará que los nodos del switch B levanten los mismos servicios que aún están ofreciendo los nodos del switch A. Lo que sucede entonces es que el cluster se ha particionado, tres nodos del switch A y otros tres del switch B ofrecen los mismo servicios debido a un fallo en la comunicación con su par respectivo. Este hecho es lo que se conoce como SplitBrain.

Realmente, puede ser que el nodo esté realmente muerto, pero también puede suceder que esté incomunicado (rotura de la tarjeta o del cable Ethernet por el que se realiza el pinging, switch, router, etc…), por lo que lo único que se puede decir del otro nodo es que su estado es desconocido.

3.7.2 ¿Cómo resolver el SplitBrain?

Existen diferentes formas de solucionar el SplitBrain, las cuales no son incompatibles entre sí. Estas se muestran a continuación:

Quorum

Es el nombre que se le da al mecanismo cuyo objetivo es ayudar a resolver el problema SplitBrain. La solución que plantea quorum es la de no seleccionar más de una “partición del cluster”, cuando falla la comunicación en el cluster, es decir, que sólo una partición del cluster ofrezca los servicios.

El método más conocido para hacer quorum en un cluster de n-nodos es dar “el quórum” a la partición que tenga más de n/2 nodos en ella. Pero claro, en caso de n=2 existen problemas, que en caso de SplitBrain causará el apagado total del cluster. Para resolver estos casos se dispone de algunas soluciones que se verán en el apartado 3.9.3 Quorum.

Fencing

Se denomina fencing al proceso de bloquear los recursos de un nodo cuyo estado es incierto (desconocido). Si hacemos uso del ejemplo, los nodos del switch A tiene un estado incierto o desconocido para los nodos del switch B. Hay varias técnicas disponibles para realizar fencing:

� NodeFencing. Permite bloquear o separar un nodo del cluster de todos los recursos que maneja de una vez sin la cooperación o aprobación por parte del nodo, esto es, forzosamente. Heartbeat hace uso de Stonith para esta técnica de fencing. Stonith realiza esto de una manera muy especial que requiere de dispositivos externos adicionales. Stonith vulgarmente se conoce como “disparo en la cabeza”, y no es más que permitir que el dispositivo adicional reinicie o apague un nodo en caso de fallo si es necesario

� ResourceFencing. Consiste en permitir o negar la funcionalidad de un recurso. Por ejemplo, si a una unidad SAN se accede a través de un conmutador, Heartbeat

podría indicar al conmutador que rechace la comunicación del nodo caído con el recurso SAN, con la finalidad de que no pueda hacer uso de él. La implementación de ResourceFencing varía en función del recurso y de como el acceso a este puede ser permitido o denegado. Básicamente es la misma idea que NodeFencing con la diferencia que el fencing en este caso realiza sobre un recurso en lugar de sobre un nodo.

� SelfFencingResourcer. Consiste en que es el propio recurso el que automáticamente garantiza el acceso exclusivo. Es la misma idea que ResourceFencing con la diferencia que en este caso es el propio recurso el que se hace fencing a si mismo sin requerir la intervención de terceras partes.

Varios caminos de comunicación

Otra manera es la de disponer de varios caminos de comunicación entre los nodos del cluster, por lo que si un interfaz o camino rompe la comunicación entre los nodos va a poder llevarse a cabo por otros caminos o vías. Se recomienda hacer uso de comunicaciones redundantes y fencing simultáneamente.

3.8 Comandos de administración

Heartbeat dispone de una gran cantidad de utilidades para la administración del clúster en tiempo real que no requieren interrumpir temporalmente su funcionamiento. Aquí se listan algunas de las funcionalidades más básicas de estas utilidades de administración:

� Comprobar qué servicios hay en un cluster:

crm_resource -L | grep <id_recurso>

� Comprobar en qué nodo se está ejecutando el recurso:

crm_resource -W -r <id_recurso>

� Arrancar un recurso:

crm_resource -r <id_recurso> -p target_role -v star ted

� Parar un recurso:

crm_resource -r <id_recurso> -p target_role -v stop ped

� Migrar un recurso a otro nodo:

crm_resource -M -r <id_recurso> -H <nodo_destino>

� Migrar un recurso al nodo primario:

crm_resource -U -r <id_recurso>

� Dejar un nodo en Standby:

crm_resource -H <nombre_nodo> -v on

� Poner un Nodo OnLine:

crm_resource -H <nombre_nodo> -v off

El número de utilidades que ofrece Heartbeat es amplio: cibadmin, crmadmin,

crm_attribute, crm_diff, crm_failcount, crm_master, crm_mon, crm_resource, crm_standby,

crm_uuid y crm_verify por lo que se requiere experiencia y cierta práctica para usarlas adecuadamente.

44 DDRRBBDD

Distributed Replicated Block Device o DRBD es un software de replicación de dispositivos de bloque (discos duros, particiones, volúmenes, etc.) que permite formar un RAID

1 a través de la red.

Figura 4-8. Logotipo DRBD

Las principales características de DRBD son:

• Tiempo real. La replicación se realiza de manera continua.

• Transparencia. Las aplicaciones que estén almacenando datos en la unidad no sabrán que está se está replicando en varias localizaciones.

• Síncrono o asíncrono. Con replicación síncrona la aplicación que escribe es notificada que la escritura se ha completado solo después de que ésta haya sido replicada. Con replicación asíncrona la notificación de que la escritura se ha completado será entregada a la aplicación cuando ésta haya sido realizada de manera local, esto es, antes de que la escritura haya sido propagada al resto de ordenadores.

DRBD ha sido implementado como un módulo adicional para el Kernel Linux que permite crear dispositivos de bloques virtuales por lo que está muy próximo al sistema de E/S. Es por ello por lo que posee una extrema flexibilidad y versatilidad convirtiendo a DRBD en una buena solución para la redundancia de datos mediante la replicación estos.

4.1 Conceptos fundamentales

Al igual que Heartbeat, DRBD requiere definir los recursos de datos a los cuales se va a dotar de alta redundancia. Más detalladamente, un recurso en DRBD es una colección de términos que hace referencia a todos los aspectos de un dispositivo particular de almacenamiento replicado. Un recurso está formado por:

• Nombre. Un nombre para el recurso.

• Unidad DRBD. Disponer de un dispositivo o unidad de bloque virtual. Se encuentran en /dev/drbdm donde 0 < m < 147.

• Configuración del disco. Concierne todos los aspectos de copia local de los datos y meta datos de uso interno de DRBD.

• Configuración de red. Concierne todos los aspectos de comunicación con el nodo con el que se van a replicar los datos.

En DRBD cualquier recurso tiene un papel, un papel que puede ser primario o secundario. Estos papeles hacen referencia al concepto de disponibilidad del almacenamiento. Sin embargo hay otros dos términos que generan mucha confusión con estos:

activo y pasivo. Estos últimos hacen referencia a la disponibilidad de una aplicación. Usualmente en entornos de alta disponibilidad el nodo primario es también el nodo activo, pero esto no tiene porqué ser siempre así.

• Una unidad o recurso DRBD con papel de primario se puede usar sin restricciones para operaciones de lectura y escritura.

• Una unidad o recurso DRBD con el papel de secundario, solo se encarga de recibir todas las actualizaciones procedentes del recurso primario no permitiéndosele el acceso a los datos para lectura o escritura. De esta forma se mantiene la coherencia de caché.

Los roles de un recurso se pueden modificar ya sea manualmente o de manera automática por una aplicación de gestión del cluster DRBD. Modificar el rol de un recurso en un nodo de secundario a primario se conoce como “ascenso o promoción”, mientras que modificar el rol de primario a secundario se conoce como “descenso”.

4.2 Modos de funcionamiento de DRBD

En el punto anterior se han visto como los roles de un recurso, primario o secundario, son fundamentales, ya que según el rol asignado al recurso en un nodo este podrá o no realizar lecturas así como modificaciones sobre los datos.

DRBD por defecto se encuentra configurado en modo single-primary, de tal manera que cualquier recurso solamente puede tomar en uno de los nodos el rol o papel de primario. Ello permite garantizar que sólo uno de los nodos del cluster podrá manipular los datos (el primario) mientras que la funcionalidad del otro nodo se limita a escribir los datos que recibe para mantenerlos así replicados. Este modo es por tanto compatible con sistemas de ficheros como ext3, ext4, XFS, etc.

Sin embargo a partir de la versión de DRBD 8.0, se ha añadido un nuevo modo de funcionamiento conocido como modo dual-primary en el que cualquier recurso puede tener en ambos nodos del cluster el rol de primario. Esto es posible desde que se dispone sistemas de almacenamiento compartido concurrente tales como GFS y OCFS2 que permiten la modificación de ficheros de forma concurrente.

Cada uno de estos modos de redundancia de datos puede tener un enfoque para ser integrado con alta disponibilidad o con alto rendimiento. El modo single-primary posee un enfoque de alta disponibilidad mientras que el modo dual-primary posee un enfoque de alto rendimiento, ya que permite el acceso concurrente a los datos por parte de los dos nodos.

4.3 Otras funcionalidades de DRBD

4.3.1 Comprobación de la integridad de datos en línea

Esta característica está disponible en la versión 8.2.5 y posteriores.

La verificación On-line permite realizar una comprobación de la integridad de los datos entre los nodos. Esta comprobación se lleva a cabo básicamente de la siguiente manera: uno de los nodos es el nodo origen, el cual de manera secuencial calcula un compendio de todos y cada uno de los bloques de un recurso en particular. DRBD entonces envía cada compendio al nodo backup el cual lo comprueba comparando con el compendio obtenido con sus datos

locales. Si este compendio no coincide, el bloque en cuestión es marcado como out-of-sync para ser posteriormente sincronizado.

Una ventaja de este método es que DRBD no envía el bloque sino un compendio de éste, por lo que a pesar de consumir un gran ancho de banda para hacer la verificación On-line podemos decir que ésta es bien aprovechada. Además los recursos DRBD que se están verificando pueden ser utilizados ya que no se causa ningún tipo interrupción en el servicio.

4.3.2 Recuperación automática del SplitBrain

Esta característica ha sido incorporado en la versión 8.0 y posteriores. Por defecto esta deshabilitada.

Una situación de SplitBrain sucede debido a un fallo temporal de la comunicación entre los nodos del cluster o tal vez por un error del administrador gestionando el cluster, lo que provoca que los recursos de cada nodo tomen el papel de primario. Esto ofrece la posibilidad a las aplicaciones que se puedan realizar modificaciones de los datos independientes en cada uno de los nodos no siendo estas modificaciones replicadas con objeto de mantener los datos consistentes.

Ante esta situación se recomienda actuar manualmente, sin embargo, DRBD dispone de varios algoritmos que intentan automatizar este proceso:

� Deshacer las modificaciones realizadas en el “nuevo o joven nodo primario”. De esta manera cuando la comunicación entre los nodos es restablecida DRBD deshace las modificaciones realizadas en el último nodo que cambió su rol a primario, es decir, el antiguo secundario.

� Deshacer las modificaciones realizadas en el “antiguo nodo primario”. De esta manera DRBD deshace las modificaciones realizadas en el primer nodo que cambió su rol a primario, es decir, el antiguo primario.

� Deshacer las modificaciones en el nodo primario con menos cambios. DRBD comprueba cuál de los dos nodos es el que menos modificaciones ha sufrido durante este tiempo de SplitBrain, y estas modificaciones se deshacen en el nodo con menos cambios.

� Si uno de los host no ha sufrido modificaciones durante el tiempo del SplitBrain, DRBD informará que el SplitBrain se ha resuelto. Hay que tener en cuenta que esta posibilidad es bastante improbable.

El seleccionar una opción u otra viene dictaminado por las aplicaciones que hacen uso de los datos DRBD. Si se permite la posibilidad de perder ciertas modificaciones producidas en los datos DRBD, la recuperación automática del SplitBrain puede ser una buena solución, sin embargo, si los datos son, por ejemplo de una aplicación financiera y no se permite la pérdida de información, la mejor actuación sería la recuperación manual.

4.3.3 Datos anticuados temporalmente

DRBD distingue entre datos “inconsistentes” y datos “anticuados” (fuera de fecha, outdated). Datos inconsistentes son datos a los que no se puede acceder ya que no tienen utilidad. Un buen ejemplo de estos datos, son los datos que están sincronizándose en un nodo (inconsistentes = durante la sincronización).

Datos anticuados, en cambio, son datos consistentes en el nodo secundario, pero no sincronizados o mejor dicho, actualizados al día, con el nodo primario. Una situación en la que se tienen datos anticuados puede ocurrir por ejemplo cuando la comunicación entre los dos nodos se pierde (teniendo un nodo primario y el otro secundario). Los datos del nodo secundario representan un estado en el que nodo primario se encontraba en el pasado. Para no hacer uso de estos datos anticuados, DRBD impide automáticamente la “promoción” del recurso.

La utilidad de impedir la promoción del recurso a primario se presenta en las situaciones de SplitBrain, ya que al impedir que el nodo secundario se convierta también en primario se evita que las modificaciones de los datos se puedan realizar de manera independiente en cada uno de los nodos. Por tanto el SplitBrain se solventa de manera automática sin requerir de la acción del administrador. Esta funcionalidad se integra perfectamente con Heartbeat.

4.4 Instalar DRBD 8

En la página oficial del proyecto, http://www.drbd.org se pueden encontrar diversos paquetes para distribuciones como Debian, SUSE Enterprise y RHEL entre otras.

En el repositorio de Debian se encuentra por ejemplo el paquete drbd0.7-module-source que, además de no ser de las últimas versiones, no se instala automáticamente con un simple apt-get install, sino que descarga las fuentes para ser compilados e instalados por nosotros mismos. Por ello, y por que no existen paquetes precompilados para todas las distribuciones, se van a ver los pasos necesarios para instalar DRBD 8 desde las fuentes.

En la página oficial de linbit, http://oss.linbit.com/drbd/, podemos descargar las fuentes de la última versión hasta el momento drbd-8.3.0.

Al descomprimir el tar.gz nos encontramos con un archivo drbd_config.h, el cual se puede configurar comentando o descomentando las opciones pertinentes. Sin embargo para facilitarnos la instalación se dispone de un script en /drbd/script llamado adjust_drbd_config_h.sh que nos ayuda a configurarlo. En este caso no se ha hecho uso de adjust_drbd_config_h.sh ya que el archivo drbd_config.h se ha dejado por defecto.

Una vez configurado con éxito se procede a instalarlo. Para ello habrá que situarse en la raíz del directorio drbd-8.X.X y ejecutar:

cd drbd make clean all

Volvemos de nuevo al directorio raíz y continuamos con la instalación:

cd .. make tools make install make install-tools

Nota: se espera que el kernel source se encuentre en “lib/modules/`úname -r`/build”, si no se

encuentra ahí, ejecutar:

make clean

make KDIR=<path del kernel source>

Si la instalación se ha realizado con éxito estos últimos dos comandos no son necesarios

ejecutarlos.

Para comprobar si el modulo se ha instalado correctamente, se intenta cargarlo:

modprobe drbd

Los pasos que se acaban de realizar, tanto la instalación de DRBD así como la carga del módulo, se han de llevar a cabo en ambos nodos.

El siguiente paso ha de realizarse también en los dos nodos. Este consiste en crear la partición donde se van a encontrar los datos que se va a replicar, por ejemplo en un disco duro auxiliar utilizado sólo para este fin:

Una vez creada la partición, ya se puede comenzar con la configuración. Destacar que se ha de crear la partición sin ningún formato ni sistema de ficheros, en caso de que se haya creado uno nos encontraremos con problemas durante la configuración aquí expuesta.

4.5 Configuración de DRBD 8

Una vez creada la partición cuyo contenido va a ser replicado ya podemos comenzar a configurar el servicio. Toda la configuración de DRBD se lleva a cabo en un único archivo de configuración, drbd.conf el cual podemos encontrar en el tar.gz, en el directorio scripts además perfectamente documentado.

El archivo drbd.conf tiene que encontrarse en el directorio etc. Un ejemplo básico de este archivo de configuración es el Código 4-16. ha.cf

Código 4-16. ha.cf resource nombre_recurso { # Por ejemplo: resource r0 common { protocol C; } on nombre_del_nodo_1 { device /dev/drbd0; #Path de la unidad virtual /de v/drbdx disk /dev/sdb1; #Path de la partición a usar para replicación address direcciónIP_nodo_1 : puerto_para_replicar ; meta-disk internal; } on nombre_del_nodo_2 { device /dev/drbd0; #Path de la unidad virtual /de v/drbdx disk /dev/sdb1; #Path de la partición a usar para replicación address direcciónIP_nodo_2 : puerto_para_replicar ; meta-disk internal; } }

Nota: este archivo de configuración debe ser igual en ambos nodos

El archivo de configuración que se acaba de mostrar es un archivo de configuración para una configuración básica de DRBD.

La replicación del recurso se va a realizar de una manera totalmente síncrona ya que se ha seleccionado como modo de replicación el protocolo C.

Nota: el protocolo C es un protocolo de replicación síncrono. Las operaciones de escritura

locales en el nodo primario son consideradas “completas” solo después de que ambos nodos

realicen la escritura en sus discos correspondientes, es decir, se repliquen. Por tanto la

pérdida de un nodo garantiza que los datos no se perderán. Una posibilidad en la que se

perderían los datos inevitablemente es si ambos nodos fallan en el mismo instante, caso

bastante improbable

En este ejemplo básico de configuración se define un cluster de replicación formado por dos nodos, nodo_1 y nodo_2. En el bloque definido para cada uno de ellos se indica el camino o path de la unidad virtual, el camino o path de la partición física a usar que va a contener la redundancia de datos, la dirección IP del propio nodo junto con el puerto que va a usar para sincronizarse con el otro nodo y un disco de metadatos interno. El espacio para metadatos es utilizado por DRBD para almacenar el tamaño de la partición DRBD, identificadores, los bloques de disco que están sincronizados, obsoletos o son inconsistentes, etc. En definitiva en él se almacena la información que DRBD necesita para funcionar.

Ahora es necesario, en ambos nodos, crear el espacio para metadatos y la unidad virtual a la que hemos hecho referencia en el archivo de configuración drbd.conf.

drbdadm create-md nombre_recurso drbdadm attach nombre_recurso

La salida esperada de create-md es:

drbdadm create-md resource v08 Magic number not found Writing meta data... initialising activity log NOT initialized bitmap New drbd meta data block sucessfully created. success

Sin embargo, al ejecutar attach podemos obtener un error como el siguiente:

Figura 4-9. Un posible error durante la configuración de DRBD

Tanto si la salida de create-md no es la esperada como si obtenemos un error al ejecutar attach, el motivo es que el servicio drbd esta arrancado y no permite ni crear los metadatos ni crear una unidad virtual en este estado por lo que, previamente, hay que parar el servicio /etc/init.d/drbd stop.

Si por el contrario no se muestra ningún error, es entonces el momento de arrancar drbd en ambos nodos.

/etc/init.d/drbd start

Una vez que DRBD se encuentra arrancado en ambos nodos se ha de proceder a establecer la comunicación entre los dos nodos para que pueda dar comienzo la sincronización inicial. Para conectarlos hay que ejecutar el siguiente comando:

drbdadm connect nombre_ recurso

Es posible ver el estado de la sincronización de las particiones de disco mediante el comando:

cat /proc/drbd

Por último, y una vez que se ha determinado la partición virtual en ambos nodos y ambos nodos se ha conectado entre sí, es necesario, realizar la sincronización inicial entre los dispositivos de bloque de datos creados. Este paso solo ha de realizarse en un nodo, y solo en el nodo cuyos datos queremos conservar y replicar. Es muy importante prestar especial atención a este punto para no realizar la sincronización inicial en la dirección equivocada. Para ello, ejecutar en el nodo cuyos datos queremos conservar y replicar, el siguiente comando:

drbdadm -- --overwrite-data-of-peer primary nombre_recurso

Los datos comenzarán a sincronizarse. El tiempo que dura el proceso dependerá de la velocidad de la red, del tamaño de la partición a replicar así como de la velocidad de transferencia indicada en el archivo de configuración de DRBD. Se puede consultar el estado de la replicación mediante el comando cat /proc/drbd.

Una vez finalizada la sincronización podemos comprobar mediante el comando cat /proc/drbd si DRBD ya se encuentra preparado. Para ello cs ha de ser Connected, indicando que ambos nodos están conectados, ld ha de ser UpToDate indicando que los datos se encuentran sincronizados y actualizados y st ha de ser Primary/Secondary en un nodo y Secondary/Primary en el otro quedando así perfectamente definido el rol DRBD de cada uno de los nodos. Finalmente DRBD está operativo.

La idea ahora es la de crear un sistema de ficheros en la partición virtual, montarla para poder hacer uso de ella como si se tratara de una partición normal. Por tanto, creamos el sistema de ficheros:

mke2fs –j /dev/drbd0

Y montamos la partición virtual para guardar aquellos datos que queremos replicar en el directorio /media/replica:

mkdir /media/replica mount /dev/drbd0 /replica

Para realizar la copia de datos en la partición virtual: se copia en ella los directorios y/o archivos que deseamos, manteniendo la estructura original, y se sustituyen estos archivos copiados por un enlace simbólico que haga referencia a estos archivos situados ahora en la partición virtual.

55 MMyySSQQLL RReepplliiccaattiioonn

El software MySQL proporciona un servidor de base de datos SQL muy rápido, multiusuario y robusto. El servidor MySQL está diseñado para entornos de producción críticos, con alta carga de trabajo así como para integrarse en software para ser distribuido. MySQL es una marca registrada de MySQL AB y se ha convertido en unas de las bases de datos de código abierto más populares siendo uno de los motivos que los usuarios tienen la opción de poder elegir entre usar el software MySQL como un producto Open Source bajo los términos de la licencia GNU General Public License o pueden adquirir una licencia comercial estándar de MySQL AB.

Son varias las versiones existentes de MySQL pero en este punto se va a tratar concretamente MySQL 5.0.

Figura 4-10. Logotipo MySQL

Una de las características que incluye MySQL 5 es la de soporte de replicación, una replicación asíncrona unidireccional donde un servidor actúa como maestro y uno o más actúan como esclavos. El servidor maestro escribe las actualizaciones que se llevan a cabo en él, en el fichero de log binario, y mantiene un índice de los ficheros para rastrear las rotaciones de logs. Estos logs sirven como registros de actualizaciones para enviar a los servidores esclavos. Cuando un esclavo se conecta al maestro, el esclavo informa al maestro de la posición hasta la que ha leído los logs en la última actualización satisfactoria. El esclavo recibe cualquier actualización que ha tenido lugar desde entonces, y se bloquea y espera para recibir futuras actualizaciones enviadas por el master.

Figura 4-11. Replicación MySQL

Una característica muy importante de la replicación es la replicación en cadena, donde un servidor esclavo puede ser maestro para otro servidor esclavo como se muestra en la figura 4-11 Replicación MySQL.

Hay que tener en cuenta que cuando se usa replicación, todas las actualizaciones de las tablas que se realizan en el servidor maestro se replican hacia los esclavos, por lo que hay que ser cuidadoso para evitar conflictos entre actualizaciones que hacen los usuarios en las tablas del maestro y las actualizaciones que se realizan en las tablas de los esclavos.

Esta replicación unidireccional tiene beneficios para la robustez, velocidad, y administración del sistema:

� Robustez. Se incrementa con un escenario maestro/esclavo. En caso de problemas con el maestro, puede cambiar al esclavo como copia de seguridad.

� Velocidad. Puede conseguirse un mejor tiempo de respuesta dividiendo la carga de consultas a procesar entre los servidores maestros y esclavo. Se puede enviar consultas SELECT al esclavo para reducir la carga en el maestro. Sin embargo, las sentencias que modifican datos deben enviarse siempre al maestro, de forma que el maestro y el esclavo no pierdan la sincronización. Esta estrategia de balanceo de carga es efectiva si dominan consultas que no actualizan datos frente a las que actualizan.

� Administración del sistema. Otro beneficio de usar replicación es que se pueden realizar copias de seguridad usando un servidor esclavo sin molestar al maestro. El maestro continúa procesando actualizaciones mientras se realiza la copia de seguridad.

5.1 Conceptos fundamentales

Antes de comenzar con la configuración de la replicación MySQL es necesario conocer como se lleva ésta a cabo, lo que obliga a conocer una serie de ficheros de texto en los cuales se indican los cambios que se han producido en el maestro, las actualizaciones llevadas a cabo por el esclavo, etc. A continuación se muestran un listado donde se indican los ficheros que intervienen en el proceso de replicación.

Log Binario

El registro binario contiene toda la información referente a actualizaciones, en un formato más eficiente y de una manera que es segura para las transacciones.

El registro binario contiene todas las sentencias que han actualizado datos o podrían haberlo hecho (por ejemplo, un DELETE que no encontró filas concordantes). Las sentencias se almacenan en forma de “eventos” que describen las modificaciones.

El registro binario también contiene información sobre cuánto ha tardado cada sentencia que actualizó la base de datos. No contiene sentencias que no hayan modificado datos, sin embargo, si se desea registrar todas las sentencias (por ejemplo, para identificar una sentencia problemática), esto es posible.

El propósito principal del registro binario es el de actualizar la base de datos durante una operación de recuperación tan pronto como sea posible, ya que el registro binario contiene todas las actualizaciones hechas tras la copia de seguridad. Otro de los propósitos es el de utilizarse como recordatorio de las sentencias llevadas a cabo en los servidores maestros que deben ser enviadas a los servidores esclavos.

Cuando MySQL se ha iniciado con la opción --log-bin[=file_name] mysqld escribe un archivo de registro que contiene todos los comandos SQL que actualizan datos. Si no se da ningún valor para file_name, el valor por defecto es el nombre de la máquina host seguido por -bin. Si se da el nombre del archivo, pero ninguna ruta, el archivo se escribe en el directorio de

datos de datos MySQL. No es recomendable no dar ningún valor para el nombre de log-bin, ya que si el nombre de la máquina es modificado en un futuro, la replicación no funcionará.

mysqld agrega una extensión numérica al nombre del registro binario. Este número se incrementa cada vez que se inicia el servidor o se vuelcan los registros. También se crea un nuevo registro binario cuando el actual llega al tamaño especificado en max_binlog_size. Un registro binario puede llegar a ser más grande de max_binlog_size si está utilizando transacciones grandes ya que una transacción se escribe en el registro de una sola pieza, no partiéndose nunca entre diferentes registros.

Log Binario Index

Mantiene un índice sobre cuáles y cuántos archivos de registro binario diferentes han sido utilizados. Por defecto éste tiene el mismo nombre que el archivo de registro binario, con la extensión .index. Puede cambiar el nombre del archivo de índice con la opción --log-bin-index[=file_name]. No debería editar este archivo manualmente mientras mysqld se está ejecutando ya que podría confundir a mysqld.

Relay Log

El esclavo lee el log binario del maestro y las actualizaciones realizadas en éste, las copia en ficheros locales, llamados logs retardados o relay log, en el directorio de datos del esclavo. Posteriormente el esclavo lee los logs retardados y ejecutar las actualizaciones que contiene.

Por defecto los relay log se nombran usando nombres de ficheros de la forma host_name-relay-bin.nnnnnn, donde host_name es el nombre del servidor esclavo y nnnnnn es un número de secuencia. Los ficheros de logs retardados sucesivos en MySQL 5.0 se crean usando números de secuencia sucesivos, comenzando a partir de 000001. Por defecto, estos ficheros se crean en el directorio de datos del esclavo cuyo nombre puede cambiarse con las opciones de servidor --relay-log.

Los logs retardados tienen el mismo formato que los logs binarios. Un log retardado se borra automáticamente por el flujo SQL en cuanto ha ejecutado todos sus eventos y no los necesita más.

Relay Log Index

El esclavo guarda los logs retardados en uso en este fichero índice. El nombre del índice del log retardado por defecto es host_name-relay-bin.index. Por defecto, este fichero se crea en el directorio de datos del esclavo cuyo nombre puede cambiarse con las opciones de servidor --relay-log-index .

master.info & relay-log.info

Un servidor esclavo de replicación crea dos pequeños ficheros adicionales en el directorio de datos. Estos ficheros de estado se llaman master.info y relay-log.info por defecto. Contienen información como la mostrada en la salida del comando SHOW SLAVE STATUS. Como ficheros escritos en disco que son sobreviven a una parada del servidor esclavo, de tal manera que la siguiente vez que arranque el servidor esclavo, leerá estos ficheros para

determinar hasta dónde ha procesado los logs binarios del maestro y sus propios logs retardados.

Mediante todos estos archivos, los datos relacionados con el proceso de replicación se hacen persistentes, por lo que ante la pérdida de comunicación entre los nodos o fallo de algunos de ellos, la replicación continuará automáticamente una vez solventados los problemas mencionados.

5.2 Funcionamiento de la replicación MySQL

Para mostrar el funcionamiento de la replicación, se muestra a continuación un sencillo ejemplo en la figura 4-12 Escenario básico de replicación MySQL, un escenario compuesto por dos nodos, nodo A y nodo B, donde el nodo A va a ser el nodo maestro y el nodo B el nodo esclavo.

Figura 4-12. Escenario básico de replicación MySQL

Supongamos que la base de datos a replicar es ejemplo que contiene la tabla prueba. Dado que esta base de datos, existente por el momento solo en el nodo A (se acaba de crear), va a ser replicada en el nodo B por lo que es necesario crear esta misma estructura en el nodo esclavo. Por lo tanto en el nodo B entramos a una consola MySQL, se crea la base de datos ejemplo, se selecciona esta base de datos ejemplo y por último se crea la tabla prueba:

mysql –user=root –password=mipassword

create database ejemplo; use ejemplo;

CREATE TABLE prueba ( id int(11) NOT NULL, c char(10) DEFAULT NULL, PRIMARY KEY (id) );

Imaginemos que la replicación MySQL ya está configurada y plenamente operativa. A partir de este momento la siguiente inserción se realiza en el nodo A:

insert into prueba values (null, 'aaa'), (null, 'bb b'), (null, 'ccc');

Para comprobar los resultados producidos por la replicación consultamos el estado de la tabla prueba en el nodo B:

//Nodo B select * from prueba; +----+------+ | id | c | +----+------+ | 1 | aaa | | 2 | bbb | | 3 | ccc | +----+------+

Y en el nodo A:

//Nodo A select * from prueba; +----+------+ | id | c | +----+------+ | 1 | aaa | | 2 | bbb | | 3 | ccc | +----+------+

De manera resumida cuando la inserción se produjo en el nodo A este escribió dicho evento en su log binario (bin-log). De manera inmediata el nodo esclavo consulta la secuencia del último log binario en el que el maestro ha escrito (recordar que tras el nombre añaden una secuencia) así como la posición que ocupa actualmente en éste tras la escritura. Para ello consulta el master.info. Una vez conocidos los movimientos del nodo maestro, el nodo B comprueba si estos valores son los mismos que él posee, localmente, consultando el archivo relay-log.info. Detectará que los valores no son iguales, generalmente las posiciones, y por tanto sabrá que ha de replicar los datos desde la posición que indica relay-log.info hasta la posición indicada en master.info. Una vez copiados los datos y replicados, actualiza los valores de su relay-log.info y queda a la espera de que se produzcan nuevas modificaciones en el nodo maestro.

Hasta el momento la replicación cumple su objetivo perfectamente sin ningún inconveniente. Sin embargo… ¿Qué sucedería si ahora se realiza una inserción cualquiera en el nodo B? Supongamos la siguiente inserción:

insert into prueba values (null, 'ddd');

El estado de la tabla prueba del nodo B pasaría a ser:

//Nodo B select * from prueba; +----+------+ | id | c | +----+------+ | 1 | aaa | | 2 | bbb | | 3 | ccc | | 4 | ddd | +----+------+

Todo parece ser correcto, sin embargo, supongamos que ahora se realiza una nueva inserción en el nodo A:

insert into prueba values (null, 'eee');

El estado de la tabla prueba del nodo A pasaría a ser:

//Nodo A select * from prueba; +----+------+ | id | c | +----+------+ | 1 | aaa | | 2 | bbb | | 3 | ccc | | 4 | eee | +----+------+

Y la del nodo B sería:

//Nodo B select * from prueba; +----+------+ | id | c | +----+------+ | 1 | aaa | | 2 | bbb | | 3 | ccc | | 4 | ddd | +----+------+

En el nodo B los resultados no son los esperados. El motivo es que el nodo B al realizar la inserción llevada a cabo por el nodo A obtiene un error de duplicidad de clave, ya que el campo id es clave primaria y por tanto no puede haber en la misma tablas dos claves primarias iguales.

MySQL implementa una solución que solventa este tipo de inconvenientes, muy necesaria en escenarios donde se requiere por ejemplo de alta disponibilidad en bases de datos. En el siguiente punto se muestra el funcionamiento de esta solución.

5.3 Funcionamiento avanzado de la replicación MySQL

Existen soluciones avanzadas de replicación permiten solventar el inconveniente de la duplicidad de las claves, visto en el punto anterior, sin importar ni el nodo ni el orden en que se lleven a cabo las futuras inserciones, borrados, modificaciones, etc.

Antes de mostrar, la solución es necesario modificar la tabla prueba en ambos nodos para poder hacer uso de esta y añadir el parámetro AUTO_INCREMENT al campo o columna id:

CREATE TABLE prueba ( id int(11) NOT NULL AUTO_INCREMENT, c char(10) DEFAULT NULL, PRIMARY KEY (id) );

La solución consiste en que cada nodo realice las inserciones siguiendo una determinada secuencia en el campo id. básicamente y para el caso de dos nodos sería por ejemplo que el nodo A realizará las inserciones con un valor siempre par en el campo id, mientras que el nodo B realizará con un valor siempre impar en el campo id. De esta manera la situación de duplicidad de las claves a causa de la replicación no sería posible.

Volviendo al escenario básico propuesto en el Punto 5.2 Funcionamiento de la

replicación MySQL, la primera inserción que se realiza en el nodo A, produciría los siguientes estados en el nodo A y en el nodo B:

insert into prueba values (null, 'aaa'), (null, 'bb b'), (null, 'ccc');

//Nodo B select * from prueba; +----+------+ | id | c | +----+------+ | 2 | aaa | | 4 | bbb | | 6 | ccc | +----+------+ //Nodo A select * from prueba; +----+------+ | id | c | +----+------+ | 2 | aaa | | 4 | bbb | | 6 | ccc | +----+------+

Ahora de nuevo supongamos la inserción que posteriormente se realizó en el nodo B:

insert into prueba values (null, 'ddd');

El estado de la tabla prueba del nodo B, a diferencia del punto anterior, pasaría a ser:

//Nodo B select * from prueba; +----+------+ | id | c | +----+------+ | 1 | ddd | | 2 | aaa | | 4 | bbb | | 6 | ccc | +----+------+

Si ahora se realiza la posterior inserción que se realizó en el nodo A:

insert into prueba values (null, 'eee');

El estado de la tabla prueba del nodo A pasaría a ser:

//Nodo A select * from prueba; +----+------+ | id | c | +----+------+ | 2 | aaa | | 4 | bbb | | 6 | ccc | | 8 | eee | +----+------+

Y la del nodo B sería:

//Nodo B select * from prueba; +----+------+ | id | c | +----+------+ | 1 | ddd | | 2 | aaa | | 4 | bbb | | 6 | ccc | | 8 | eee | +----+------+

Mediante esta técnica, la replicación sí se realiza correctamente, sin importar el orden en que se realice las inserciones. La implementación de esta técnica es muy sencilla ya que solo hay que hacer uso de dos opciones adicionales en la configuración de la replicación: auto_increment_increment y auto_increment_offset:

� auto_increment_increment. Establece el valor que se ha de incrementar en cada inserción. Por lo general el valor que se le asigna corresponde al número de nodos presentes en la replicación, para que de esta manera cada uno lleve su propia secuencia.

� auto_increment_offset. Establece el valor inicial de cada secuencia.

Estos atributos serán aplicados de manera automática en aquellas columnas o campos que hayan sido creadas mediante el parámetro AUTO_INCREMENT.

5.4 Configuración de MySQL Replication

Conocido, por tanto, como se realiza la replicación, así como los ficheros necesarios, podemos dar comienzo a la configuración de esta funcionalidad de MySQL. La configuración mostrada a continuación va a ser la del Punto 5.2 Funcionamiento de la replicación MySQL.

Supongamos el mismo caso que el propuesto en el punto 5.2, dos nodos cada uno con el servicio MySQL instalado, y se pretende que ambas bases de datos se repliquen para conseguir así redundancia en los datos almacenados. La configuración de la replicación MySQL se lleva a cabo en el archivo my.cnf de cada uno de los nodos.

El nodo A va a ser el nodo maestro y el nodo B va a ser el nodo esclavo. Lo que se requiere añadir al archivo de configuración my.cnf en [mysqld] para que el nodo A ejerza como maestro se muestra a continuación:

#Inicio replicacion MySQL server-id=1 log-bin=/var/lib/mysql/master-bin log-bin-index=/var/lib/mysql/master-bin log-error=/var/lib/mysql/master-error #Fin replicacion MySQL

Para que el nodo B se comporte como esclavo, únicamente es necesario añadir en [mysqld] la siguiente configuración:

#Inicio Replicacion MySQL server-id=2 relay-log=/var/lib/mysql/slave-bin relay-log-index=/var/lib/mysql/slave-bin relay-log-info=/var/lib/mysql/slave-error replicate-do-db=ejemplo #Fin Replicacion MySQL

Nota: destacar la importancia de identificar cada servidor con el identificador “server_id”

Con la configuración establecida el nodo B va a ser el nodo esclavo, consultando los cambios ocurridos en el log binario del servidor A. Sin embargo para que el nodo esclavo pueda acceder al log_bin del nodo maestro es necesario que tenga permisos de replicación. Por lo tanto, el siguiente paso consiste en dar permisos de replicación al nodo B en el nodo A. Para ello en el nodo A se ha de ejecutar las siguientes sentencias SQL:

mysql> GRANT REPLICATION SLAVE, REPLICATION CLIENT -> ON *.* -> TO 'repl'@'nodoB' -> IDENTIFIED BY 'q1w2e3';

De esta manera se otorga permiso de replicación al nodo identificado con el usuario repl que se acredite con el password q1w2e3 procedente del nodoB (

Atención: ello requiere que el nodo A incluya en el archivo host una resolución para el

nombre nodoB.

Antes de dar inicio a la replicación es necesario que ambas bases de datos partan del mismo punto, es decir, con el mismo contenido por lo que se requiere hacer un backup del nodo A y restaurar todo su contenido en el nodo B.

Para hacer el backup de la base de datos ejemplo en el archivo situado en el directorio /tmp/nodoA.dump ejecutar el siguiente comando (no es una sentencia SQL) en el nodo A:

mysql –user=root –password=mipassword --extended-in sert

--databases ejemplo --master-data > /tmp/nodoA.dum p

Para restaurar el backup en el nodo B ejecutar, previamente copiando el fichero backup creado nodoA.dump por ejemplo al directorio /tmp/backup_mysql/nodoA.dump:

mysql --user=root --password=my_pwd </tmp/backup_my sql/nodoA.dump

Por último faltaría indicar al nodo esclavo el nombre del fichero del log binario maestro en el que actualmente escribe y la posición hasta la que se ha escrito en este log.

Para conocer el nombre y posición del log_bin que actualmente se encuentra usando el maestro es necesario ejecutar en este la siguiente sentencia SQL:

show master status\G

La salida será similar a la que se muestra a continuación :

mysql > SHOW MASTER STATUS; +---------------+----------+ | File | Position | +---------------+----------+ | mysql-bin.003 | 73 | +---------------+----------+

mysql-bin.003 corresponde al log binario que está usando actualmente el maestro y 73 corresponde a la posición actual que ocupa tras la última sentencia de modificación.

Finalmente es necesario indicar la información al nodo esclavo ejecutando en este la siguiente sentencia SQL:

mysql> CHANGE MASTER TO -> MASTER_HOST=' nodoA ', -> MASTER_USER=' minodoB ', -> MASTER_PASSWORD='q1w2e3', -> MASTER_LOG_FILE='mysql-bin.003', -> MASTER_LOG_POS= 73 ;

Atención: ello requiere que el nodo B incluya en el archivo host una resolución para el

nombre nodoA.

Por último comenzar la replicación en el nodo esclavo mediante las sentencias:

mysql –-user=root –password=mipassword

start-slave;

Para comprobar si la replicación MySQL se encuentra en ejecución se puede ejecutar la siguiente sentencia SQL en el nodo esclavo y comprobar si el resultado de Slave_IO_Running y Slave_SQL_Running es el siguiente:

Slave_IO_Running: Yes Slave_SQL_Running: Yes

Si la salida es correcta la replicación estará completamente operativa y todas las actualizaciones realizadas en el nodo maestro serán replicadas de inmediato al nodo esclavo. Si por el contrario la salida no es correcta es muy recomendable leer en el nodo maestro el bin-log –err situado en el path que hemos indicado en el archivo de configuración del nodo maestro ya que se indica claramente la causa de fallo.