Compartir tecnología

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

La arquitectura de alta disponibilidad en el clúster lvs es solo para la alta disponibilidad del programador.

Implementar los programadores principal y de respaldo basados ​​en vrrp

Arquitectura HA de alta disponibilidad

Programador principal y programador de respaldo (puede haber múltiples programadores de respaldo)

Cuando el planificador funciona normalmente, el equipo está completamente redundante (en espera). No participa en la operación del clúster. Solo cuando el programador principal falla, la copia de seguridad asumirá el trabajo del programador principal. Una vez que el programador principal recupere su función, el maestro continuará sirviendo como entrada al clúster. y la copia de seguridad seguirá en un estado redundante (según la prioridad).

Keepalive se basa en el protocolo vrrp para implementar la solución de alta disponibilidad LVS.

1. Dirección de multidifusión:

224.0.0.18 se comunica según la dirección de multidifusión. Los dispositivos primario y secundario envían mensajes para determinar si la otra parte está viva.

2. Determinar las posiciones primaria y secundaria según la prioridad.

3. Conmutación por error: si la máquina principal cuelga, la máquina de respaldo continuará funcionando. Cuando la máquina maestra se recupere, la máquina de respaldo continuará esperando.

4. El cambio entre primario y secundario es el cambio de dirección VIP.

Keepalive aparece específicamente para LVS, pero no es exclusivo de LVS.

módulo central: el módulo central de keepalive, responsable del inicio y mantenimiento del proceso principal y la carga de archivos de configuración global

Módulo vrrp: el módulo que implementa el protocolo vrrp, que es el módulo de función principal

Módulo de verificación: responsable de la verificación de estado y también puede verificar el estado del servidor real en segundo plano.

Basado en el experimento del modo DR en el capítulo anterior, agregamos algunas configuraciones. Esta vez se utilizan dos programadores, uno principal y otro de respaldo.

Primero instale keepalive en el programador

yum -y install keepalived

Una vez completada la instalación

Cambiemos el archivo keepalived.conf

[root@test1 ~]# vim /etc/keepalived/keepalived.conf
   notification_email_from [email protected]
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id LVS_01
   vrrp_skip_check_adv_addr
   vrrp_strict
   vrrp_garp_interval 0
   vrrp_gna_interval 0
   vrrp_iptables
}
 
vrrp_instance VI_1 {
    state MASTER
    interface ens33
    virtual_router_id 51
    priority 120
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.124.100
    }
}
 
virtual_server 192.168.124.100 80 {
    delay_loop 6
    lb_algo rr
    lb_kind DR
    persistence_timeout 50
    protocol TCP
 
    real_server 192.168.124.40 80 {
        weight 1
            TCP_CHECK {
            connect_port 80
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
 
    real_server 192.168.124.50 80 {
                                                                     9,1           36%

Copie el archivo de configuración en el primer programador al segundo programador

scp root@192.168.233.10:/etc/keepallved/keepallved.conf
/etc/keepallved

Luego cambia la configuración

Prioridad de primaria y secundaria.

Agregar una opción de iptables

De esta manera, el acceso a las reglas de keepalive no se detendrá en la tabla de reglas de ipetables.

[root@localhost ~]# ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  192.168.124.100:80 rr persistent 50
  -> 192.168.124.40:80            Route   1      0          0
  -> 192.168.124.50:80            Route   1      0          0

Échale un vistazo

Luego reinicia todo

Eche un vistazo a los resultados del cliente.

Primero cerremos el programador principal.

stsemctl stop keepalived.servers

El programador de respaldo asume el trabajo del maestro y continúa trabajando.

Esta es la dirección VIP que se ha cargado en el programador preparado. El cliente está accediendo a ella.

Todavía puedo acceder

---

Resumir

Keepalived tiene principalmente tres módulos: core (módulo central, responsable del inicio del proceso principal, mantenimiento y carga y análisis de archivos de configuración global), check (módulo de verificación de estado) y vrrp (implementación del protocolo vrrp).

El principio de funcionamiento de Keepalived se basa en el protocolo VRRP. Varios servidores que proporcionan las mismas funciones se forman en un grupo de servidores, que tiene un maestro y múltiples copias de seguridad. Hay un VIP en el maestro que proporciona servicios al mundo exterior (la ruta predeterminada de otras máquinas en la LAN donde se encuentra el servidor es este VIP. El maestro enviará multidifusión cuando la copia de seguridad no pueda recibir el paquete VRRP). Pensará que el maestro está inactivo y luego, de acuerdo con la prioridad del nivel VRRP, elegirá una copia de seguridad para convertirse en el nuevo maestro.

Al configurar LVS + Keepalived, generalmente necesita instalar software relacionado (como ipvsadm, keepalived) en los nodos maestro y de respaldo, y configurar el archivo keepalived.conf. Por ejemplo, en el archivo de configuración del nodo maestro, debe especificar el estado (state) como maestro, interfaz de red (interfaz), ID de ruta virtual (virtual_router_id), prioridad (prioridad), intervalo de publicidad (advert_int), información de autenticación. (autenticación) y dirección IP virtual (virtual_ipaddress), etc., la configuración del nodo de respaldo es similar, pero el estado es de respaldo y la prioridad suele ser menor que la del maestro.

Una vez completada la configuración, reinicie el servicio keepalived para lograr un equilibrio de carga de alta disponibilidad. Cuando el nodo maestro falla, VIP cambiará automáticamente al nodo de respaldo para garantizar el acceso normal al servicio; después de que el nodo maestro se recupere, volverá a actuar como el nodo de carga principal; Además, el servidor real (rs) también se puede configurar en consecuencia. Por ejemplo, cuando se utiliza el modelo DR para la comunicación, lo debe configurarse como VIP en la tarjeta de red de rs.

De esta manera, la combinación LVS + Keepalived puede lograr los siguientes objetivos: el cliente accede al servicio a través de VIP y la solicitud se distribuirá de acuerdo con las reglas de configuración cuando falla el nodo de equilibrio de carga del maestro y puede cambiar automáticamente a la copia de seguridad; nodo para garantizar que el servicio sea normal; cuando un determinado rs Cuando un nodo falla, el nodo se puede eliminar automáticamente y se puede agregar nuevamente al clúster después de la recuperación.

En aplicaciones reales, se debe prestar atención a cuestiones relevantes, como que la dirección IP configurada por virtual_ipaddress en el archivo de configuración Keepalived debe estar en el mismo segmento de red, cuanto mayor sea el valor de prioridad, mayor será la probabilidad de que el nodo se convierta en maestro; nodo; cuanto menor sea el valor de advert_int, mayor será la probabilidad de que el nodo envíe mensajes VRRP. Al mismo tiempo, también es necesario considerar factores como el entorno de la red y el rendimiento del servidor para garantizar la estabilidad y el funcionamiento eficiente de todo el sistema.