Alta disponibilidad con LinuxHA

CDA 2022/23


Índice General

1 Descripción

Ejemplo de cluster de alta disponibilidad en modo activo-pasivo utilizando LinuxHA.

Recursos complementarios

2 Entorno de prácticas

2.1 Software de virtualización VIRTUALBOX

En estas prácticas se empleará el software de virtualización VIRTUALBOX para simular los equipos GNU/Linux sobre los que se realizarán las pruebas.

2.2 Imágenes a utilizar

  1. Scripts de instalación

    Notas:

  2. Imágenes descargadas

  3. Usuarios configurados e inicio en el sistema

2.3 Máquinas virtuales y redes creadas

3 Clusters Linux-HA

Linux-HA (High-Availability Linux) ofrece una colección de herramientas para desplegar cluster de alta disponibilidad en GNU/Linux, FreeBSD y otros entornos UNIX-like.

Detalles en https://clusterlabs.org/

Image esquema_linuxha

Gestor de nodos: componente responsable de monitorizar y gestionar los nodos que forman parte del cluster HA

Gestor de recursos: componente responsable de asignar ”recursos” a los nodos del cluster HA

Resource agents: colección de scripts shell responsables de controlar los ”recursos” gestionados por el cluster HA

4 EJERCICIO ENTREGABLE: Servidor Apache en alta disponibilidad con Linux-HA

4.1 Configuración previa

  1. Instalación de LinuxHA en las máquinas del cluster (ya hecho) 
    apt-get install corosync cluster-glue
apt-get install pacemaker resource-agents crmsh

  2. Asegurar un fichero /etc/hosts con las direcciones correctas (ya hecho) 
    ------Contenido-----
127.0.0.1   localhost
10.10.10.11 servidor1
10.10.10.22 servidor2
------Contenido-----

    Asegurar también que los hostnames son los correctos 

    servidor1:~# hostname
servidor2:~# hostname
    (si es necesario asignar los correctos con los comandos 1”hostname servidor1” ó ”hostname servidor2”)

  3. Diferenciar las webs por defecto de Apache (sólo para depuración y pruebas) 
    servidor1:~# nano /var/www/html/index.html
servidor2:~# nano /var/www/html/index.html

  4. IMPORTANTE: Detener el demonio de Apache en ambas máquinas (Pacemaker se encargará de iniciar los servidores cuando ”toque”) 
    servidor1:~# systemctl stop apache2
servidor2:~# systemctl stop apache2


4.2 Configuración de Corosync

Corosync se encarga de gestionar los nodos del cluster y su estado (up/down)

  1. Eliminar la configuración previa y detener los servicios Corosync y Pacemaker (en ambos nodos) 

    servidor1:~# crm configure erase
servidor1:~# systemctl stop pacemaker 
servidor1:~# systemctl stop corosync

    servidor2:~# crm configure erase
servidor2:~# systemctl stop pacemaker 
servidor2:~# systemctl stop corosync

  2. Crear la clave compartida de autenticación de mensajes con el comando corosync-keygen(en cualquier nodo) 
    servidor1:~# corosync-keygen 
Corosync Cluster Engine Authentication key generator.
Gathering 2048 bits for key from /dev/urandom.
Writing corosync key to /etc/corosync/authkey.

  3. Editar la configuración de Corosync(en cualquier nodo) 
    servidor1:~# cd /etc/corosync
servidor1:/etc/corosync/# mv corosync.conf corosync.conf.orig
servidor1:/etc/corosync/# nano corosync.conf
------ Contenido a incluir -----

## Configuración de la comunicación entre nodos (knet sobre udp con pulsos/mensajes cifrados y autenticados)
totem {
    version: 2
    cluster_name: clustercda
    transport: knet
    knet_transport: udp
    crypto_cipher: aes256
    crypto_hash: sha256
    interface {
        linknumber: 0
        bindnetaddr: 10.10.10.0
        mcastport: 5405
    }
}

## Esquema de quorum (con 2 nodos no tiene sentido y la opción two_node:1 lo deshabilita)
quorum {
    provider: corosync_votequorum
    expected_votes: 2
    two_node: 1
}

## Lista explicita de nodos que forman el cluster HA
nodelist {
    node {
        nodeid: 1
        name: servidor1
        ring0_addr: 10.10.10.11
    }
    node {
        nodeid: 2
        name: servidor2
        ring0_addr: 10.10.10.22
   }
}


logging {
    to_logfile: yes
    logfile: /var/log/corosync/corosync.log
    to_syslog: yes
    timestamp: on
}

------ Contenido a incluir -----

    Nota: Más información en http://corosync.github.io/corosync/. Lista completa de parámetros en ayuda en línea (man) 

    servidor1:~/# man corosync_overview
servidor1:~/# man corosync.conf
servidor1:~/# man votequorum

  4. Copiar la configuración a los demás nodos del cluster (se hace mediante SSH) 
    servidor1:/etc/corosyncs/# scp {corosync.conf,authkey} root@servidor2:/etc/corosync

(pedirá la contraseña de root de cada máquina del cluster [purple])

    Comprobar en el directorio /etc/corosync de la máquina servidor2 que realmente se han copia los 2 ficheros (corosync.conf, authkeys) con los permisos correctos.

  5. Arrancar los servicios Corosyn y Pacemaker en todas las máquinas del cluster 

    servidor1:~# systemctl start corosync 
servidor1:~# systemctl start pacemaker

    servidor2:~# systemctl start corosync 
servidor2:~# systemctl start pacemaker

    Se puede ver como se ”suman” nodos al cluster con el comando crm_mon (desde cualquier nodo) 

    servidor1:~/# crm_mon        (también crm_mon --show-detail)
servidor2:~/# crm_mon

    (finalizar con CONTROL+C)

    Al finalizar el ”arranque” del cluster (tardará un tiempo) mostrará que hay configurados 2 nodos y 0 recursos, indicando los nodos que están online (Online: [servidor1 servidor2]) 

        
servidor1:~# crm status

    NOTA 1: Es posible que se muestren nodos adicionales en estado offline. Se trata de ”restos” de la configuración inicial de corosync existente en la imagen base de las máquinas virtuales.

    NOTA 2: Para el desarrollo de la práctica lo más cómodo es dejar el comando crm_mon ejecuándose en una ventana propia y así poder comprobar la evolución y el estado del cluster en cualquier momento.

    $\to$ A INCUIR EN EL ENTREGABLE: ¿Qué ha pasado en los nodos del cluster al iniciar el demonio corosync en todos ellos?


4.3 Configuración de Pacemaker

Pacemaker gestiona los recursos (servicios del cluster) y su asignación a los nodos.

En este ejemplo Pacemaker gestionará 2 recursos en modo activo-pasivo:

La consola de administración de Pacemaker (comando crm) tiene dos modos de uso (ambos equivalentes)

  1. Entrar en la consola de configuración de Pacemaker [crm shell] (permite TAB para autocompletar) 
        
servidor1:# crm configure

crm(live) configure# show
crm(live) configure# show xml

    Nota: En ”modo comando” se ejecutaría desde el intérprete de comandos del sistema el comando crm configure show.

  2. Ajustar parámetros (deshabilitar STONITH y ajustar QUORUM) 
        
crm(live) configure# property stonith-enabled=false
crm(live) configure# property no-quorum-policy=ignore
crm(live) configure# commit
crm(live) configure# show

  3. Añadir el recurso DIR_PUBLICA

    Se definirá un ”recurso” que se corresponde con la asignación de una dirección IP pública (193.147.87.47) a uno de los equipos del cluster.

    1. PREVIO: Desde la máquina cliente lanzar el comando ping a la dirección IP 193.147.87.47 (fallará hasta que el cluster la habilite) 

          
   cliente:~/# ping 193.147.87.47

    2. Revisar los parámetros del ”resource agent” IPaddr 
          
crm(live) configure# ra
crm(live) configure ra# list ocf
     (muestra los ”agentes de recurso” Heartbeat/Pacemaker de tipo OCF disponibles [los scripts fueron instalados con 'apt-get install resource-agentes en /usr/lib/ocf/resource.d/heartbeat/])
 
crm(live) configure ra# list lsb       
     (muestra los ”agentes de recurso” correspondientes a scripts de arranque de tipo init [scripts en /etc/init.d, controlados con 'service <script> start|stop|restart ]')

crm(live) configure ra# list systemd       
     (muestra los ”agentes de recurso” correspondiente a servicos del systema gestionados por systemd [controlados con 'systemctl start|stop|restart <servico>)

crm(live) configure ra# info ocf:heartbeat:IPaddr               (regreso al terminal con letra Q)
crm(live) configure ra# up

    3. Darlo de alta y configurarlo con la IP pública del servidor web y el interfaz de red a usar

      (ojo con el separador de líneas \)

      SINTAXIS: primitive <nombre-recurso> <class>:<provider>:<nombre> [params <atributo>=<valor>] 

          
crm(live) configure# help primitive                                     (regreso al terminal con letra Q)
crm(live) configure# primitive DIR_PUBLICA ocf:heartbeat:IPaddr \
                               params ip=193.147.87.47  cidr_netmask=255.255.255.0 nic=enp0s3
crm(live) configure# commit
crm(live) configure# show

      (comprobar el ping desde cliente [en algún momento empezará a responder])

      • Comprobar con ”crm status” o ”crm_mon” a qué nodo se le ha asignado el recurso DIR_PUBLICA
      • En esa máquina ver la configuración de las tarjetas de red con ”ip address” (habrá vinculado a la tarjeta enp0s3 la dirección 193.147.87.47)

    $\to$ A INCUIR EN EL ENTREGABLE: ¿Qué ha pasado en los nodos del cluster al hacer commit y declarar el recurso DIR_PUBLICA?

  4. Añadir el recurso APACHE

    Se definirá un ”recurso” que se corresponde con la ejecución de un servidor HTTP Apache.

    1. Revisar los parámetros del ”resource agent APACHE 
         
crm(live) configure# ra list ocf
crm(live) configure# ra info ocf:heartbeat:apache

    2. Darlo de alta y configurarlo 
          
crm(live) configure# primitive APACHE ocf:heartbeat:apache \
                               params configfile=/etc/apache2/apache2.conf
crm(live) configure# commit
crm(live) configure# show
      • Desde otro terminal o desde el otro nodo: comprobar cómo evoluciona el estado del cluster [comando ”crm_mon” ó ”crm status”]
      • Puede suceder que el recurso DIR_PUBLICA se asigne a un nodo y el recurso APACHE al otro
    3. Vincular los recursos DIR_PUBLICA y APACHE (”co-localizar” ambos recursos)

      SINTAXIS: colocation <nombre> <score>: <nombre-recurso> <nombre-recurso> ! 

          
crm(live) configure# help colocation
crm(live) configure# colocation APACHE_SOBRE_DIRPUBLICA inf: DIR_PUBLICA APACHE
crm(live) configure# commit
crm(live) configure# show
      • Comprobar cómo evoluciona el estado del cluster con el comando ”crm_mon” hasta que se estabilice y los dos recursos se asignen al mismo nodo.

      • Cuando los dos recursos migren al mismo nodo, comprobar que ahora es posible el acceso al servidor web desde la máquina cliente con lynx o Falkon (empleando la dirección 193.147.87.47)

    $\to$ A INCUIR EN EL ENTREGABLE: ¿Qué ha pasado en los nodos del cluster al hacer commit e incluir la restricción de ”colocalización” APACHE_SOBRE_DIRPUBLICA?

  5. Forzar la migración de los recursos a otra máquina

    Desde el contexto resource del ”modo interactivo”

    SINTAXIS: move <nombre-recurso> <nodo> 

        
crm(live)configure# up
crm(live)# resource
crm(live)resource# help move
crm(live)resource# move APACHE servidorX

    Directamente con el ”modo comando” de crm desde línea de comandos 

        
servidor1:~# crm resource move APACHE servidorX   
servidor1:~# crm status

    $\to$ A INCUIR EN EL ENTREGABLE: ¿Qué ha pasado en los nodos del cluster al ejecutar el comando move del contexto resource?

  6. Detener la máquina donde se esté ejecutando (servidorX) [apagándola directamente] y comprobar que el otro servidor ocupa su lugar 
        
servidorX:~/# shutdown -h now   # MEJOR: apagar la MV desde el boton "Cerrar"


servidorY:~/# crm_mon   (o crm --show-detail) 
                        [esperar hasta que detecte  el fallo y migre recursos]
ó
servidorY:~/# crm status
    Cuando termine la migración, comprobar el acceso al servidor web desde la máquina cliente con lynx o Falkon.

    $\to$ A INCUIR EN EL ENTREGABLE: ¿Qué ha pasado en los nodos del cluster al apagar la máquina con los recursos DIR_PUBLICA y APACHE?

    Volver a ”encender” la máquina apagada y comprobar que sucede.

NOTA: En el fichero de LOG /var/log/corosync/corosync.log (disponible en los dos nodos) se puede ver la evolución del cluster, los eventos y las decisiones tomadas por los nodos del cluster.

5 Documentación a entregar

Detallar los pasos seguidos y los resultados obtenidos en los siguientes puntos del ejemplo (señalados con $\to$ A INCLUIR EN EL ENTREGABLE):

  1. Configuración del gestor de nodos Corosync (punto 5 en la sección 4.2)
  2. Declaración del recurso DIR_PUBLICA (punto 3 en la sección 4.3)
  3. Declaración del recurso APACHE y establecimiento de la restricción de ”co-localización” (punto 4 en la sección 4.3)

  4. Migración del recurso APACHE a otro nodo (punto 5 en la sección 4.3)
  5. Apagado/caída de un nodo (punto 6 en la sección 4.3)

En cada uno de esos puntos a explicar:

Entrega: MOOVI

Fecha límite: hasta el domingo 27/11/2022