一、Arquitectura de Alta Disponibilidad

1、Necesidad de esta solución

HAProxy actúa como un punto de recepción de solicitudes de clientes y las distribuye a los servidores del backend

Existe un problema crítico: si el nodo que recibe las solicitudes de los clientes falla, todo el servicio queda inaccesible Aquí es donde Keepalived proporciona la solución mediante nodos primario y secundario. Cuando el nodo primario falla, el secundario asume automáticamente las solicitudes, evitando la interrupción del servicio

• Una desventaja de esta configuración es que el nodo secundario permanece inactivo la mayor parte del tiempo, lo que representa una utilización del 50% de los recursos disponibles

2、Principios de funcionamiento

Flujo de operación

• Los clientes acceden a una dirección IP virtual (VIP), donde HAProxy está escuchando las solicitudes entrantes
• El nodo HAProxy establece conexiones con los servidores del backend
• Los servidores del backend procesan las solicitudes y devuelven las respuestas al nodo HAProxy
• Finalmente, las respuestas se envía de vuelta a los clientes
• El ciclo completo de procesamiento de una solicitud se completa así
• Cuando el nodo primario falla, ocurre una transición automática al nodo secundario (se puede implementar un script de monitoreo que verifique el estado de Keepalived)

Mecanismo de migración del VIP

El protocolo VRRP es el componente central de Keepalived VRRP utiliza multicast para señales de vida, elecciones basadas en prioridad y el mecanismo de ARP gratuito para seleccionar el nodo maestro

• El concepto principal es mantener una dirección VIP que puede migrar entre nodos, proporcionando transparencia para los clientes

3、Configuración del entorno

• Se configura una IP virtual que utilizan los clientes como punto de acceso

Configuración del nodo maestro

# Archivo de configuración de Keepalived
[root@servidor-principal ~]# cat /etc/keepalived/keepalived.conf
! Archivo de configuración para Keepalived

global_defs {
   identificador_enrutador LVS_MAESTRO
}

instancia_vrrp cluster_servidores {
    estado MAESTRO
    interfaz eth0
    id_router_virtual 55
    prioridad 250
    intervalo_anuncio 1
    autenticacion {
        tipo_contrasena SIMPLE
        contrasena seg2024
    }
    direccion_ip_virtual {
        172.16.0.100/24
    }
}

# Configuración de HAProxy
frontend servicios_web
    vinculacion *:8080
    grupo_predeterminado servidores_backend

backend servidores_backend
    metodo_balanceo roundrobin
    servidor web01 192.168.10.20:80 verificaciones
    servidor web02 192.168.10.30:80 verificaciones

Configuración del nodo secundario

# Configuración de Keepalived para el nodo de respaldo
[root@servidor-respaldo ~]# cat /etc/keepalived/keepalived.conf
! Archivo de configuración para Keepalived

global_defs {
   identificador_enrutador LVS_RESPALDO
}

instancia_vrrp cluster_servidores {
    estado RESPALDO
    interfaz eth1
    id_router_virtual 55
    prioridad 100
    intervalo_anuncio 1
    autenticacion {
        tipo_contrasena SIMPLE
        contrasena seg2024
    }
    direccion_ip_virtual {
        172.16.0.100/24
    }
}

# Configuración de HAProxy
frontend servicios_web
    vinculacion *:8080
    grupo_predeterminado servidores_backend

backend servidores_backend
    metodo_balanceo roundrobin
    servidor web01 192.168.10.20:80 verificaciones
    servidor web02 192.168.10.30:80 verificaciones

Configuración de los servidores del backend

• Se configura un srevicio HTTP básico en cada servidor del backend para responder a las solicitudes

Modo Maestro-Maestro

• Esta arquitectura emplea dos direcciones IP virtuales, permitiendo que ambos nodos actúen simultáneamente como servidores activos, duplicando así la capacidad de procesamiento disponible