Clústeres de Alta Disponibilidad

¿Qué es un clúster HA?

Un clúster de alta disponibilidad está compuesto por múltiples nodos de servidor que, mediante diseño redundante y conmutación automática de fallos, garantizan que los servicios esenciales permanezcan disponibles, minimizando el tiempo de inactividad.

• Cuando un servidor que aloja un sitio web falla, otra máquina toma su rol

Métodos de implementación de clústeres HA

• Keepalived

Detalles sobre Keepalived

1. Visión General

1.1. Introducción

• Keepalived es un software ligero de alta disponibilidad basado en el protocolo VRRP, con funcionalidades principales de migración de VIP (IP virtual) y verificación de salud de servicios
• Realiza verificaciones de salud para LVS, pero no tiene capacidad de equilibrio de carga por sí mismo, dependiendo del LVS en el kernel de Linux
• Utiliza el protocolo VRRPv2 para manejar la conmutación por fallos en clústeres de equilibrio de carga, realizando comprobaciones de latido entre nodos y migrando la IP flotante a nodos operativos en caso de fallo

1.2. Componentes principales de Keepalived

• vrrp_stack: Módulo central que implementa el protocolo VRRP, responsable de la migración de VIP y la elección maestro-esclavo
• checkers: Módulo de verificación de salud, supervisa servicios como nginx, mysql, etc., y evita redirigir solicitudes a servidores con fallos
• libipvs: Módulo de equilibrio de carga que integra funcionalidades LVS, implementando HA + equilibrio de carga en una sola solución

Terminología especializada:

• VIP: IP virtual, único punto de acceso para servicios externos, puede migrar entre nodos
• Migración de direcciones: Proceso por el cual la IP se traslada al nodo secundario cuando el primario falla
• Comprobación de latido: Mecanismo para determinar roles maestro/esclavo y supervisar el estado de los nodos
• Partición cerebral (Split-brain): Situación donde ambos nodos pierden comunicación y ambos intentann tomar el control de la IP

1.3. Protocolo VRRP (Principios fundamentales)

El protocolo VRRP es la base de la alta disponibilidad. Cuando un servidor falla, el servidor secundario asume el rol del primario.

Mecanismo de estado VRRP:

• Inicial (inicialize): Estado no operativo cuando Keepalived se inicia o un nodo falla. En este estado, no se procesan paquetes VRRP
• Maestro (master): Estado activo donde Keepalived funciona normalmente y gestiona el tráfico. El nodo tiene la VIP y envía paquetes VRRP con prioridad 255
• Esclavo (backup): Estado en espera que no gestiona tráfico, solo recibe y procesa comprobaciones de latido. Si el maestro falla, toma la VIP y se convierte en maestro

Mecanismo de elección VRRP:

• La elección se basa en la prioridad de los nodos; el de mayor prioridad se convierte en maestro
• Si las prioridades son iguales, se compara la dirección IP de la interfaz; el nodo con la IP mayor se convierte en maestro

Mecanismo anti-partición cerebral:

• Implementar software de arbitraje externo
• Reforzar la red de latido con interfaces dedicadas
• Utilizar scripts de verificación personalizados

1.4. Principios de funcionamiento de Keepalived

• Basado en el protocolo VRRPv2 y verificación de salud de servicios
• Los dos nodos primero realizan una elección; el maestro recibe solicitudes y realiza comprobaciones de latido con el esclavo
• El protocolo VRRPv2 permite la conmutación automática
• También realiza verificación de salud de servidores backend con LVS

1.5. Métodos de verificación de salud en Keepalived

• TCP_CHECK: Opera en la capa 4, enviando solicitudes de conexión TCP. Si no hay respuesta o se agota el tiempo, el servidor se considera no operativo
• HTTP_GET: Opera en la capa 5, realizando solicitudes HTTP a URLs específicas. Compara el resultado mediante hash MD5 o códigos de estado HTTP
• SSL_GET: Similar a HTTP_GET pero utilizando conexiones SSL
• MISC_CHECK: Utiliza scripts personalizados para verificar el estado de los servicios. Un código de salida 0 indica estado normal

2. Configuración detallada de Keepalived

2.1. Instalación y archivo de configuración

sudo yum -y install keepalived

# Ruta del archivo de configuración
sudo rpm -qc keepalived
/etc/keepalived/keepalived.conf
/etc/sysconfig/keepalived

2.2. Análisis detallado del archivo de configuración principal

# Configuración global
global_defs {
    notification_email {
        admin@ejemplo.com     # Correo de notificación 1
        operaciones@ejemplo.com  # Correo de notificación 2
    }
    notification_email_from keepalived@servidor    # Dirección del remitente
    smtp_server 127.0.0.1                          # Servidor SMTP
    smtp_connect_timeout 30                         # Tiempo de espera de conexión SMTP
    router_id LVS_DEVEL                             # Identificador del router, debe ser único
    vrrp_skip_check_adv_addr                        # Omitir comprobación de direcciones de anuncio
    vrrp_strict                                     # Cumplimiento estricto del protocolo VRRP
    vrrp_garp_interval 0                            # Intervalo ARP gratuito
    vrrp_gna_interval 0                             # Intervalo de anuncio de vecino
    script_user nobody                              # Usuario para ejecutar scripts
    enable_script_security                          # Habilitar seguridad de scripts
}

# Configuración de verificación de scripts
vrrp_script verificar_nginx {
    script "/usr/bin/killall -0 nginx"              # Ruta del script de verificación
    interval 2                                      # Intervalo de verificación (segundos)
    weight 2                                        # Valor de cambio de prioridad
    fall 2                                          # Número de fallos para considerar no operativo
    rise 2                                          # Número de éxitos para considerar operativo
    user nobody                                     # Usuario de ejecución
}

# Configuración de instancia VRRP (parte central)
vrrp_instancia VI_1 {                             
    estado MAESTRO                                 # Estado inicial: MAESTRO/ESCLAVO
    interfaz eth0                                 # Interfaz de red para la VIP
    virtual_router_id 51                           # ID del router virtual (0-255), debe ser consistente
    prioridad 100                                  # Prioridad (1-254), mayor valor = mayor prioridad
    
    advert_int 1                                   # Intervalo de anuncio (segundos)
    
    # Configuración de autenticación
    autenticacion {
        tipo_auth PASO                             # Tipo de autenticación: PASO/AH
        auth_pass 1111                             # Contraseña (máximo 8 caracteres)
    }
    
    # Configuración de VIP (puede haber múltiples)
    virtual_ipaddress {
        192.168.1.100/24 dev eth0                  # VIP 1
        192.168.1.200/24 dev eth0 label eth0:1     # VIP 2 (con etiqueta)
    }
    
    # Seguimiento de scripts (verificación de salud)
    track_script {
        verificar_nginx                             # Referencia al script definido
    }
}

# Configuración de servicio virtual (relacionado con LVS)
servidor_virtual 192.168.1.100 80 {                
    delay_loop 6                                   # Intervalo de verificación de salud
    lb_algo rr                                     # Algoritmo de scheduling: rr|wrr|lc|wlc|lblc|sh|dh
    lb_kind DR                                     # Modo LVS: NAT|DR|TUN
    protocolo TCP                                  # Tipo de protocolo
    
    # Pool de servidores reales
    servidor_real 192.168.1.10 80 {                
        peso 1                                     # Peso
        # Verificación TCP
        TCP_CHECK {
            connect_timeout 10
            retry 3
            delay_before_retry 3
            connect_port 80
        }
    }
}

2.3. Configuración de verificación de scripts

Existen dos enfoques para la configuración de scripts:

Primer enfoque (compatible con todas las versiones)

vrrp_script nginx_check {
script "/etc/keepalived/verificar_nginx.sh"
interval 1
weight -5
fail 3
}

vrrp_instancia Nginx {
track_script {
    nginx_check
    }
}

3. Implemantación práctica

3.1. Keepalived + Nginx

Objetivo: Asegurar que el servicio continúe operativo incluso si Keepalived falla. También abordar el problema de que cuando un servicio falla, la VIP permanece en el nodo defectuoso.

Configuración de Keepalived

Configuración del nodo maestro:

! Archivo de configuración para keepalived

global_defs {
   router_id lb_maestro
}

vrrp_instancia VI_1 {
    estado MAESTRO
    interfaz eth0
    virtual_router_id 51
    prioridad 254
    advert_int 1
    autenticacion {
        tipo_auth PASO
        auth_pass 1111
    }
    virtual_ipaddress {
	192.168.100.10/24
    }
}

Configuración del nodo esclavo:

! Archivo de configuración para keepalived

global_defs {
   router_id lb_esclavo
}

vrrp_instancia VI_1 {
    estado ESCLAVO
    interfaz eth0
    virtual_router_id 51
    prioridad 100
    advert_int 1
    autenticacion {
        tipo_auth PASO
        auth_pass 1111
    }
    virtual_ipaddress {
	192.168.100.10/24
    }
}

Configuración del script de verificación de servicios

#!/bin/bash
# /etc/keepalived/verificar_servicio.sh

systemctl is-active nginx &> /dev/null
if [ $? -ne 0 ];then
	exit 10
else
	exit 0
fi

Asignar permisos de ejecución:

chmod +x /etc/keepalived/verificar_servicio.sh

Integración del script en la configuración

vrrp_script verificar_servicio {
  script "/etc/keepalived/verificar_servicio.sh"
  interval 2
  fail 3
}

vrrp_instancia VI_1 {
    estado MAESTRO
    interfaz eth0
    virtual_router_id 51
    prioridad 254
    advert_int 1
    autenticacion {
        tipo_auth PASO
        auth_pass 1111
    }
    virtual_ipaddress {
	192.168.100.10/24
    }
   track_script {
    verificar_servicio
}
}

3.2. Keepalived + LVS

Implementación de alta disponibilidad para VIP con verificación de salud mediante HTTP_GET.

Configuración del nodo maestro LVS

global_defs {
   router_id lb_maestro_lvs
}

vrrp_instancia VI_1 {
    estado MAESTRO
    interfaz eth0
    virtual_router_id 51
    prioridad 255
    advert_int 1
    autenticacion {
        tipo_auth PASO
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.100.10/24
    }
}

servidor_virtual 192.168.100.10 80 {
    delay_loop 6
    lb_algo rr
    lb_kind DR
    protocolo TCP

    servidor_real 192.168.100.11 80 {
        peso 1
        HTTP_GET {
            url {
              path /
	      status_code 200
            }
            connect_timeout 3
            retry 3
            delay_before_retry 3
        }
    }

    servidor_real 192.168.100.12 80 {
        peso 1
        HTTP_GET {
            url {
              path /
	      status_code 200
            }
            connect_timeout 3
            retry 3
            delay_before_retry 3
        }
    }
}

Configuración de parámetros del kernel en nodos LVS

sudo sysctl -w net.ipv4.ip_forward=1

Configuración de servidores backend

Configurar interfaces ARP y loopback en servidores backend:

sudo nmcli connection add type dummy ifname dummy1 con-name dummy1 ipv4.method manual ipv4.addresses 192.168.100.10/24 autoconnect yes 

# Configurar sysctl para ignorar ARP
echo "net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.dummy1.arp_ignore=1
net.ipv4.conf.all.arp_announce=2
net.ipv4.conf.dummy1.arp_announce=2" | sudo tee -a /etc/sysctl.conf

sudo sysctl -p /etc/sysctl.conf

4. Consideraciones para entornos de producción

• Keepalived + LVS para equilibrio de carga a nivel de red
• Keepalived + HAProxy para equilibrio de carga a nivel de aplicación
• Keepalived + Nginx para equilibrio de carga con verificación de estado

En configuraciones Nginx, modificar server_name para usar la VIP e implementar scripts de verificación del servicio Nginx para migración automática de VIP.