Keepalived combinado con Nginx para realizar un servicio WEB de alta disponibilidad

prefacio

Con la tendencia de desarrollo de Nginx en China, cada vez más empresas de Internet utilizan Nginx. El alto rendimiento y la estabilidad de Nginx lo han convertido en el servidor HTTP y proxy inverso preferido por los profesionales de TI.
El balanceo de carga de Nginx generalmente se encuentra en el front-end o capa intermedia de toda la arquitectura del sitio web. Si es el front-end, un solo Nginx tendrá un único punto de falla, es decir, un tiempo de inactividad de Nginx, lo que afectará el acceso de los usuarios. a todo el sitio web. Por lo tanto, es necesario unirse al servidor de respaldo de Nginx. El servidor principal de Nginx y el servidor de respaldo forman alta disponibilidad. Una vez que se descubre que el servidor principal de Nginx está inactivo, el sitio web puede restaurarse rápidamente en el host de respaldo.

1. Uso de scripts para lograr una alta disponibilidad

De esta manera, ambos servidores están vinculados al mismo VIP y se usan junto con el servicio.Al juzgar si el servicio es normal, si el servicio es anormal o está cerrado, el VIP en el servidor principal se desplazará al servidor en espera para lograr un nivel alto. solución disponible.

1. Necesita preparar 2 servidores
2. Cierre el firewall por adelantado
3. Instale nginx en ambos servidores
4. Ambos servidores implementan la misma dirección IP VIP
5. Los dos servidores juzgan si el servicio es normal a través del script de inicio

sistema de servidor	Atender	IP	IP VIP
CentOS7.9	Nginx	192.168.154.128	192.168.154.188
CentOS7.9	Nginx	192.168.154.23	192.168.154.188

1. Implementar el servicio nginx

Aquí, use yum install para instalar rápidamente el servicio nginx (los siguientes pasos, ambos servidores deben operarse).
Si desea instalarlo de otras maneras, puede consultar este artículo: Implementar e instalar la instancia del servicio Nginx

yum install -y epel-release; yum install -y nginx  

Aquí primero debe instalar epel-release, y luego tendrá el paquete nginx después de instalar esta fuente de extensión.

Para que las páginas web de los dos servidores se vean diferentes, restablezca el archivo de página index.html.
Primer servidor:

[root@localhost ~]# cd /usr/share/nginx/html/
[root@localhost html]# rm -rf *
[root@localhost html]# echo "This is 154.128 WebServer " > index.html

Segundo servidor:

[root@localhost ~]# cd /usr/share/nginx/html/
[root@localhost html]# rm -rf *
[root@localhost html]# echo "This is 154.23 WebServer " > index.html

Inicie el servicio nginx

[root@localhost html]# systemctl start nginx

ver en la web

2. Configurar la subred del VIP

Cambie al directorio correspondiente para crear una subred (ambos servidores deben configurarse)

[root@localhost html]# cd /etc/sysconfig/network-scripts/
[root@localhost network-scripts]# vim ifcfg-ens32:0
[root@localhost network-scripts]# cat ifcfg-ens32:0
TYPE="Ethernet"
BOOTPROTO="static"
DEVICE="ens32:0"
ONBOOT="yes"
IPADDR="192.168.154.188"
NETMAST="255.255.255.0"

No es necesario agregar una puerta de enlace aquí, puede ver la puerta de enlace existente predeterminada

[root@localhost network-scripts]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.154.1   0.0.0.0         UG    100    0        0 ens32
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0

Una vez completada la configuración, puede usar el comando ifup para iniciar la tarjeta de red para ver si hay algún problema; puede probarlo en ambos servidores. Si el primer servidor se inicia y prueba sin ningún problema, debe usar ifdown ens32. :0 para detener primero la tarjeta de red y luego Iniciar en otro servidor.

[root@localhost network-scripts]# ifup ens32:0
[root@localhost network-scripts]# echo $?
0
[root@localhost html]# ifconfig |grep -wi "inet"|awk 'NR==2,NR==3{print $2}'
192.168.154.23
192.168.154.188

3. Programación de Shell para realizar el script de alta disponibilidad de Nginx

Implemente dos servidores Nginx y publique páginas de prueba WEB.
Puede acceder a páginas WEB a través de ambas IP.
Agregue una tercera IP, llamada VIP, que puede vincularse a un cierto 0.188
para acceder a VIP (nombre de dominio) para acceder a un servicio WEB Nginx
Cuando el El servicio Nginx WEB está inactivo, el VIP cambiará automáticamente a otro WEB
para garantizar que, sin importar qué Nginx WEB esté inactivo, el VIP pueda acceder a la WEB

Una vez que tenga una idea, puede comenzar a escribir guiones y puede dividir los guiones en varios pasos para lograr

[root@localhost ~]# vim auto_nginx_status.sh
#!/bin/bash
#2023年5月10日15:47:28
#auto nginx status 
#####################
NGINX_NUM=$(ps -ef|grep nginx|grep -Ev "grep|auto_nginx"|wc -l)
if [ $NGINX_NUM -gt 0 ];then
        ping -c3 192.168.154.188 >>/dev/null 2>&1
        if [ $? -ne 0 ];then
                cd /etc/sysconfig/network-scripts/
                cat>ifcfg-ens32:0<<-EOF
                TYPE="Ethernet"
                BOOTPROTO="static"
                DEVICE="ens32:0"
                ONBOOT="yes"
                IPADDR="192.168.154.188"
                NETMAST="255.255.255.0"
                EOF
                ifup ens32:0
        fi
else
        cd /etc/sysconfig/network-scripts/
        ifdown ens32:0 >>/dev/null 2>&1
        rm -rf /etc/sysconfig/network-scripts/ifcfg-ens32:0
fi

La primera versión del script asocia el servicio Nginx con el VIP y agrega la tarjeta de red VIP al evaluar si el proceso del script es normal; antes de agregar, haga ping a la IP para ver si puede comunicarse, y si puede comunicarse, significa que el VIP está en uso. Si la tarjeta de red no puede comunicarse, significa que está en un estado liberado, luego otro servidor agregará una tarjeta de red VIP.

Por supuesto, este script todavía tiene fallas, porque solo se puede juzgar y luego salir del script. Necesitamos hacer que este script se ejecute todo el tiempo. Debe agregar una instrucción de bucle while.

[root@localhost ~]# vim auto_nginx_status.sh
#!/bin/bash
#2023年5月10日15:47:28
#auto nginx status 
#####################
while true
do
        sleep 5
        date
        NGINX_NUM=$(ps -ef|grep nginx|grep -Ev "grep|auto_nginx"|wc -l)
        if [ $NGINX_NUM -gt 0 ];then
                ping -c3 192.168.154.188 >>/dev/null 2>&1
                if [ $? -ne 0 ];then
                        cd /etc/sysconfig/network-scripts/
                        cat>ifcfg-ens32:0<<-EOF
                        TYPE="Ethernet"
                        BOOTPROTO="static"
                        DEVICE="ens32:0"
                        ONBOOT="yes"
                        IPADDR="192.168.154.188"
                        NETMAST="255.255.255.0"
                        EOF
                        ifup ens32:0
                fi
        else
                cd /etc/sysconfig/network-scripts/
                ifdown ens32:0 >>/dev/null 2>&1
                rm -rf /etc/sysconfig/network-scripts/ifcfg-ens32:0
        fi
done

La segunda versión está disponible, y el bucle while puede mantener la secuencia de comandos ejecutándose en segundo plano, y puede limitar la cantidad de segundos que se ejecuta una vez y mostrar la hora. Pero si lo miras de esta manera, hay muchos campos que se repiten, podemos definirlo como una variable, lo que hace que la visualización sea mucho más concisa.

#!/bin/bash
#2023年5月10日15:47:28
#auto nginx status 
#####################
ENS_FILE="ens32:0"
ENS_VIP="192.168.154.188"
ENS_DIR="/etc/sysconfig/network-scripts"
while true
do
        sleep 5
        date 
        NGINX_NUM=$(ps -ef|grep nginx|grep -Ev "grep|auto_nginx"|wc -l)
        if [ $NGINX_NUM -gt 0 ];then
                ping -c3 ${ENS_VIP} >>/dev/null 2>&1
                if [ $? -ne 0 ];then
                        cd ${ENS_DIR}/
                        cat>ifcfg-${ENS_FILE}<<-EOF
                        TYPE="Ethernet"
                        BOOTPROTO="static"
                        DEVICE="${ENS_FILE}"
                        ONBOOT="yes"
                        IPADDR="${ENS_VIP}"
                        NETMAST="255.255.255.0"
                        EOF
                        ifup ${ENS_FILE}
                fi
        else
                cd ${ENS_DIR}/
                ifdown ${ENS_FILE} >>/dev/null 2>&1
                rm -rf ifcfg-${ENS_FILE}
        fi
done

Básicamente, todas las funciones se pueden realizar, vamos a probarlo

4. Realización funcional del script de prueba.

Detectar si el VIP se desviará al segundo servidor cuando haya un problema con el primer servicio Nginx, para que el sitio web pueda lograr una solución de alta disponibilidad.
Ejecute este script en ambos servidores.

[root@localhost ~]# /bin/bash auto_nginx_status.sh 
2023年 05月 10日 星期三 16:08:27 CST
2023年 05月 10日 星期三 16:08:34 CST
2023年 05月 10日 星期三 16:08:41 CST
2023年 05月 10日 星期三 16:08:48 CST
2023年 05月 10日 星期三 16:08:55 CST
2023年 05月 10日 星期三 16:09:02 CST
2023年 05月 10日 星期三 16:09:09 CST
2023年 05月 10日 星期三 16:09:16 CST
[root@localhost ~]# ifconfig |grep -wi "inet"|awk 'NR==1,NR==2{print $2}'
192.168.154.128
192.168.154.188

El VIP actual está en el servidor 128. En

este momento, apagaremos el servicio Nginx en el primer servidor para ver si el VIP salta al segundo servidor, para que el contenido que se muestra en la página web sea la información del índice. Archivo .html de 23. .

[root@localhost ~]# pkill nginx
[root@localhost ~]# ifconfig |grep -wi "inet"|awk 'NR==1,NR==2{print $2}'
192.168.154.128
127.0.0.1

Al finalizar el proceso nginx, verifique la IP de la tarjeta de red y descubra que se ha liberado VIP 188, luego verifique si el VIP en la página web muestra el contenido en el segundo servidor.

Se ha convertido en la información del archivo index.html en el segundo servidor y, por supuesto, el VIP también está vinculado al segundo servidor.

[root@localhost ~]# ifconfig |grep -wi "inet"|awk 'NR==2,NR==3{print $2}'
192.168.154.23
192.168.154.188

No hay problema con los resultados de la prueba, pero después de una cuidadosa consideración, se encontrará que este método obviamente no es lo suficientemente automático. El script debe ejecutarse manualmente, el proceso es engorroso y se debe configurar una subred adicional.
El keepalived del que hablaremos a continuación será mucho más simple. Justo después de que se implemente el servicio, keepalived verificará si el servicio es normal. Después de que el servicio sea normal, permita que el servidor regrese al clúster de servidores nuevamente.

2. Utilice el servicio Keepalived para lograr una alta disponibilidad

Concepto ======> "Keepalived Concept and Installation and Deployment Process"
necesita implementar el servicio primero y luego configurar los parámetros correspondientes.
Aquí usamos directamente yum para instalar el servicio

Atender	sistema	IP	Role
Keepalived，Nginx	CentOS7.9	172.17.0.2	Maestro
Keepalived，Nginx	CentOS7.9	172.17.0.3	Respaldo

2.1 Implementar Keepalive

yum install keepalived -y

Escriba el script asociado con Keepalived y Nginx, que debe configurarse en dos servidores

cat auto_config_nginx_status.sh
#!/bin/bash
NGINX_NUM=$(ps -ef|grep nginx|grep -Ev "grep|auto_config"|wc -l)
if [ $NGINX_NUM -eq 0 ];then
        systemctl stop keepalived.service
fi   
#还需要将脚本权限设置成可执行权限
chmod +x auto_config_nginx_status.sh

Agregue el script al archivo de configuración de keepalived

El primer servidor se establece como maestro maestro:

vim /etc/keepalived/keepalived.conf 
  1 ! Configuration File for keepalived
  2 
  3 global_defs {
    
    
  4    notification_email {
    
    
  5      [email protected]
  6    }
  7    notification_email_from [email protected]
  8    smtp_server 127.0.0.1
  9    smtp_connect_timeout 30
 10    router_id LVS_DEVEL
 11 }
 12 
 13 vrrp_script check_nginx {
    
    
 14         script "/root/auto_config_nginx_status.sh"  #脚本的路径
 15         interval 5     #每隔5秒执行脚本
 16 
 17 vrrp_instance VI_1 {
    
    
 18     state MASTER
 19     interface eth0
 20     virtual_router_id 151
 21     priority 100
 22     advert_int 5
 23     authentication {
    
    
 24         auth_type PASS
 25         auth_pass 1111
 26     }
 27     virtual_ipaddress {
    
    
 28         172.17.0.188
 29     }
 30     track_script {
    
    
 31         check_nginx
 32     }
 33 }

Segundo servidor:

vim /etc/keepalived/keepalived.conf 
  1 ! Configuration File for keepalived
  2 
  3 global_defs {
    
    
  4    notification_email {
    
    
  5      [email protected]
  6    }
  7    notification_email_from [email protected]
  8    smtp_server 127.0.0.1
  9    smtp_connect_timeout 30
 10    router_id LVS_DEVEL
 11 }
 12 
 13 vrrp_script check_nginx {
    
    
 14         script "/root/auto_config_nginx_status.sh"
 15         interval 5
 16 }
 17 
 18 vrrp_instance VI_1 {
    
    
 19     state BACKUP
 20     interface eth0
 21     virtual_router_id 151
 22     priority 90
 23     advert_int 5
 24     authentication {
    
    
 25         auth_type PASS
 26         auth_pass 1111
 27     }
 28     virtual_ipaddress {
    
    
 29         172.17.0.188
 30     }
 31     track_script {
    
    
 32         check_nginx
 33    }
 34 }

Luego inicie el servicio en ambos servidores y listo.

systemctl restart keepalived.service

2.2 Comprobar el registro del núcleo

Ver el estado del servicio de inicio en el registro del kernel del sistema

[root@Master-02 ~]# tail -Fn 30 /var/log/messages
May 11 05:41:25 8be7506dd805 Keepalived_vrrp[1652]: Opening file '/etc/keepalived/keepalived.conf'.
May 11 05:41:30 8be7506dd805 Keepalived_vrrp[1652]: VRRP_Instance(VI_1) Transition to MASTER STATE
May 11 05:41:35 8be7506dd805 Keepalived_vrrp[1652]: VRRP_Instance(VI_1) Entering MASTER STATE
May 11 05:41:35 8be7506dd805 Keepalived_vrrp[1652]: VRRP_Instance(VI_1) setting protocol VIPs.
May 11 05:41:35 8be7506dd805 Keepalived_vrrp[1652]: Sending gratuitous ARP on eth0 for 172.17.0.188
May 11 05:41:35 8be7506dd805 Keepalived_vrrp[1652]: VRRP_Instance(VI_1) Sending/queueing gratuitous ARPs on eth0 for 172.17.0.188
May 11 05:41:35 8be7506dd805 Keepalived_vrrp[1652]: Sending gratuitous ARP on eth0 for 172.17.0.188
May 11 05:41:35 8be7506dd805 Keepalived_vrrp[1652]: Sending gratuitous ARP on eth0 for 172.17.0.188

La dirección VIP actual está en el servidor maestro y la actual 172.17.0.2 está en estado MAESTRO

[root@localhost ~]# curl 172.17.0.188
0.2IP server 

La información de la página web actual que muestra el VIP también está en la máquina 0.2, veamos la información de registro del servidor de respaldo

[root@Backup-03 ~]# tail -Fn 30 /var/log/messages
May 11 05:41:44 b31c0155f7d0 Keepalived_healthcheckers[1441]: Opening file '/etc/keepalived/keepalived.conf'.
May 11 05:41:44 b31c0155f7d0 Keepalived_vrrp[1442]: SECURITY VIOLATION - scripts are being executed but script_security not enabled.
May 11 05:41:44 b31c0155f7d0 Keepalived_vrrp[1442]: VRRP_Instance(VI_1) removing protocol VIPs.
May 11 05:41:44 b31c0155f7d0 Keepalived_vrrp[1442]: Using LinkWatch kernel netlink reflector...
May 11 05:41:44 b31c0155f7d0 Keepalived_vrrp[1442]: VRRP_Instance(VI_1) Entering BACKUP STATE

El servidor de respaldo muestra que el archivo keepalived.conf también está activado y el estado actual es RESPALDO.

Puede saber quién está en el estado MAESTRO comprobando en qué servidor está configurado el VIP.

2.3 Ver la IP de la tarjeta de red

Cabe señalar aquí que keepalivedel comando de uso VIP ifconfigno se puede ver

[root@Master-02 ~]# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.17.0.2  netmask 255.255.0.0  broadcast 172.17.255.255
        ether 02:42:ac:11:00:02  txqueuelen 0  (Ethernet)
        RX packets 4462  bytes 975851 (952.9 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2738  bytes 376935 (368.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Debe ip addr verificarse en el comando. La IP VIP solo puede estar en uno de los clústeres de servidores. Si el VIP existe en varios servidores, significa que hay un problema en la configuración.

[root@Master-02 ~]# ip addr|grep -Eio "([0-9]{1,3}\.){3}[0-9]{1,3}"
127.0.0.1
172.17.0.2
172.17.255.255
172.17.0.188

Por supuesto, también puedes comprobar quién es el MAESTRO capturando paquetes.

VRRP implementa la función de un enrutador virtual a través de un protocolo de elección, y todos los paquetes de protocolo se envían en forma de paquetes IP de multidifusión (multidifusión) (dirección de multidifusión 224.0.0.18).

2.4 Usar tcpdump para capturar paquetes

Si no tiene este comando, puede usar yum para descargar

[root@localhost ~]# which tcpdump
/usr/sbin/tcpdump
[root@localhost ~]# rpm -qf /usr/sbin/tcpdump
tcpdump-4.9.2-4.el7_7.1.x86_64
[root@Backup-03 ~]#yum install -y  tcpdump-4.9.2-4.el7_7.1.x86_64

El servidor 172.17.0.2 envía un paquete de multidifusión (224.0.0.18) al clúster de servidores cada 5 segundos.

[root@Backup-03 ~]# tcpdump -i eth0 -nn host 172.17.0.2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
06:09:26.728428 IP 172.17.0.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 151, prio 100, authtype simple, intvl 5s, length 20
06:09:31.728754 IP 172.17.0.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 151, prio 100, authtype simple, intvl 5s, length 20
06:09:36.729083 IP 172.17.0.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 151, prio 100, authtype simple, intvl 5s, length 20
06:09:41.729403 IP 172.17.0.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 151, prio 100, authtype simple, intvl 5s, length 20
06:09:46.729751 IP 172.17.0.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 151, prio 100, authtype simple, intvl 5s, length 20

A continuación, simulamos el tiempo de inactividad del servicio del servidor 0.2 para ver si la dirección VIP se trasladará a otro servidor.

2.5 Simular el tiempo de inactividad del servicio

Elimine nginx en 172.17.0.2. Debido a la configuración de la secuencia de comandos, cuando se cierra el servicio nginx, Keepalived también se cerrará.

[root@Master-02 ~]# pkill nginx
[root@Master-02 ~]# systemctl status keepalived
● keepalived.service - LVS and VRRP High Availability Monitor
   Loaded: loaded (/usr/lib/systemd/system/keepalived.service; disabled; vendor preset: disabled)
   Active: inactive (dead) since Thu 2023-05-11 06:19:37 UTC; 12s ago
  Process: 2952 ExecStart=/usr/sbin/keepalived $KEEPALIVED_OPTIONS (code=exited, status=0/SUCCESS)
 Main PID: 2953 (code=exited, status=0/SUCCESS)
   CGroup: /docker/8be7506dd805cc8dab483ae8954e61f78629d981094ef138546ad1328fa489af/system.slice/keepalived.service

Compruebe la información de registro de 0.2

May 11 06:19:36 8be7506dd805 Keepalived[2953]: Stopping
May 11 06:19:36 8be7506dd805 systemd: Stopping LVS and VRRP High Availability Monitor...
May 11 06:19:36 8be7506dd805 Keepalived_vrrp[2955]: VRRP_Instance(VI_1) sent 0 priority
May 11 06:19:36 8be7506dd805 Keepalived_vrrp[2955]: VRRP_Instance(VI_1) removing protocol VIPs.
May 11 06:19:36 8be7506dd805 Keepalived_healthcheckers[2954]: Stopped
May 11 06:19:37 8be7506dd805 Keepalived_vrrp[2955]: Stopped
May 11 06:19:37 8be7506dd805 Keepalived[2953]: Stopped Keepalived v1.3.5 (03/19,2017), git commit v1.3.5-6-g6fa32f2
May 11 06:19:37 8be7506dd805 systemd: Stopped LVS and VRRP High Availability Monitor.

El servicio keepalived en 0.2 se ha detenido; continúe viendo la información de registro de 0.3

May 11 06:19:37 b31c0155f7d0 Keepalived_vrrp[1442]: VRRP_Instance(VI_1) Transition to MASTER STATE
May 11 06:19:42 b31c0155f7d0 Keepalived_vrrp[1442]: VRRP_Instance(VI_1) Entering MASTER STATE
May 11 06:19:42 b31c0155f7d0 Keepalived_vrrp[1442]: VRRP_Instance(VI_1) setting protocol VIPs.
May 11 06:19:42 b31c0155f7d0 Keepalived_vrrp[1442]: Sending gratuitous ARP on eth0 for 172.17.0.188
May 11 06:19:42 b31c0155f7d0 Keepalived_vrrp[1442]: VRRP_Instance(VI_1) Sending/queueing gratuitous ARPs on eth0 for 172.17.0.188
May 11 06:19:42 b31c0155f7d0 Keepalived_vrrp[1442]: Sending gratuitous ARP on eth0 for 172.17.0.188

El estado de 0.3 ha cambiado a MAESTRO, y el VIP también se ha desplazado a la máquina 0.3.

[root@Backup-03 ~]# ip addr |grep -Eo "([0-9]{1,3}\.){3}[0-9]{1,3}"
127.0.0.1
172.17.0.3
172.17.255.255
172.17.0.188

En el proceso de implementación anterior, si el servicio en el primer servidor falla, se liberará el VIP en el primer servidor y la tecnología de redundancia de enrutamiento VRRP de Keepalived configurará el VIP en el segundo servidor; después de restaurar el servicio del primer servidor a la normalidad por el personal de operación y mantenimiento, al reiniciar el servicio de keepalived, ya que la prioridad del primer servidor es mayor que la del segundo servidor, entonces el VRRP de keepalived pasará la elección, 100>90, y el segundo servidor El VIP vuelve a derivar al primer servidor;
este método obviamente tendrá un mayor impacto en la empresa, porque desde el primer servidor hasta el segundo servidor, VRRP liberará el VIP y luego lo vinculará a otro servidor, durante este período, habrá será de 3 a 5 segundos, y los usuarios no podrán acceder a la página web; después de que se restablezca el primer servicio, el VIP retrocederá, y en este momento, los usuarios no podrán acceder durante unos segundos; actualmente en keepalive Puede configurar el modo de no prioridad en el servidor , de modo que incluso si se restaura el primer servicio, no volverá al primer servidor si la prioridad es mayor que la del segundo.

Debe restablecerse en el archivo de configuración. Debe tenerse en cuenta que si se establece en no preferencia, el estado debe cambiarse a RESPALDO, porque el estado MAESTRO ignora la configuración de no preferencia.

#此时VIP在172.17.0.3的服务器中
[root@Backup-03 ~]# ip addr |grep -Eo "([0-9]{1,3}\.){3}[0-9]{1,3}"
127.0.0.1
172.17.0.3
172.17.255.255
172.17.0.188

#在172.17.0.2的配置文件中将实例1的VIP设置成不抢占，并且将状态修改成BACKUP
! Configuration File for keepalived

global_defs {
    
    
   notification_email {
    
    
     [email protected]
   }
   notification_email_from [email protected]
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id LVS_DEVEL
}
vrrp_script check_nginx {
    
    
        script "/root/auto_config_nginx_status.sh"
        interval 5
}
vrrp_instance VI_1 {
    
    
    state BACKUP
    interface eth0
    virtual_router_id 151
    priority 100
    nopreempt  		#不抢占
    advert_int 5
    authentication {
    
    
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
    
    
        172.17.0.188
    }
    track_script {
    
    
        check_nginx
    }
}

Se puede ver que cuando la prioridad del primer servidor es más alta que la del segundo servidor, no habrá ninguna situación de apropiación del VIP.

[root@Master-02 ~]# tail -Fn 30 /var/log/messages
May 11 07:27:08 8be7506dd805 Keepalived_vrrp[11506]: VRRP_Instance(VI_1) removing protocol VIPs.
May 11 07:27:08 8be7506dd805 Keepalived_vrrp[11506]: Using LinkWatch kernel netlink reflector...
May 11 07:27:08 8be7506dd805 Keepalived_vrrp[11506]: VRRP_Instance(VI_1) Entering BACKUP STATE
May 11 07:27:08 8be7506dd805 Keepalived_vrrp[11506]: VRRP sockpool: [ifindex(88), proto(112), unicast(0), fd(10,11)]
May 11 07:27:08 8be7506dd805 Keepalived_vrrp[11506]: VRRP_Script(check_nginx) succeeded

Lo anterior es solo el modo activo/en espera de Nginx+keepalived. Siempre hay un servidor en estado inactivo, entonces, cómo hacer un mejor uso de los dos servidores, lo siguiente se puede realizar mediante la arquitectura de doble maestro Nginx+keepalived, por lo que que los dos servidores tienen dos direcciones VIP externas, mientras reciben las solicitudes de los usuarios.

3. Implemente Nginx+Keepalived en una arquitectura maestra dual

Este método puede usar de manera efectiva los recursos existentes, aumentar la concurrencia de la recepción de solicitudes y hacer que los dos servidores se activen y se respalden entre sí. Para lograr este efecto, debe agregar una instancia en el archivo de configuración VI_2.

3.1 Agregar funcionalidad al archivo de configuración

servidor 172.17.0.2:

! Configuration File for keepalived
global_defs {
    
    
   notification_email {
    
    
     [email protected]
   }
   notification_email_from [email protected]
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id LVS_DEVEL
}
vrrp_script check_nginx {
    
    
        script "/root/auto_config_nginx_status.sh"
        interval 5
}
vrrp_instance VI_1 {
    
    
    state MASTER
    interface eth0
    virtual_router_id 151
    priority 100
    advert_int 5
    authentication {
    
    
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
    
    
        172.17.0.188
    }
    track_script {
    
    
        check_nginx
    }
}
vrrp_instance VI_2 {
    
       # 实例2
    state BACKUP        #第一台服务器上添加第二个实例，有一个主状态，这个就设置成备用状态
    interface eth0     #网卡接口不变
    virtual_router_id 152   #id号需要修改，实例之间ID号不能一致
    priority 90				#作为备用服务器，优先级可以设置成90
    advert_int 5			#表示每五秒进行一次健康检查
    authentication {
    
    
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
    
    
        172.17.0.189 		#VIP IP设置成189
    }
    track_script {
    
    
        check_nginx
    }
}

servidor 172.17.0.3:

! Configuration File for keepalived

global_defs {
    
    
   notification_email {
    
    
     [email protected]
   }
   notification_email_from [email protected]
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id LVS_DEVEL
}
vrrp_script check_nginx {
    
    
        script "/root/auto_config_nginx_status.sh"
        interval 5
}
vrrp_instance VI_1 {
    
    
    state BACKUP
    interface eth0
    virtual_router_id 151
    priority 90
    advert_int 5
    authentication {
    
    
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
    
    
        172.17.0.188
    }
    track_script {
    
    
        check_nginx
   }
}
vrrp_instance VI_2 {
    
    
    state MASTER       
    interface eth0
    virtual_router_id 152
    priority 100
    advert_int 5
    authentication {
    
    
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
    
    
        172.17.0.189

Después de la configuración, puede reiniciar el servicio

[root@Backup-03 ~]# systemctl restart keepalived

Todavía verifique el archivo de registro para ver el estado

[root@Master-02 ~]# tail -fn 30 /var/log/messages
May 11 06:40:30 8be7506dd805 Keepalived_vrrp[6728]: VRRP_Instance(VI_1) Transition to MASTER STATE
May 11 06:40:35 8be7506dd805 Keepalived_vrrp[6728]: VRRP_Instance(VI_1) Entering MASTER STATE
May 11 06:40:35 8be7506dd805 Keepalived_vrrp[6728]: VRRP_Instance(VI_1) setting protocol VIPs.
May 11 06:40:35 8be7506dd805 Keepalived_vrrp[6728]: Sending gratuitous ARP on eth0 for 172.17.0.188
May 11 06:40:35 8be7506dd805 Keepalived_vrrp[6728]: VRRP_Instance(VI_1) Sending/queueing gratuitous ARPs on eth0 for 172.17.0.188
May 11 06:40:35 8be7506dd805 Keepalived_vrrp[6728]: Sending gratuitous ARP on eth0 for 172.17.0.188
May 11 06:40:35 8be7506dd805 Keepalived_vrrp[6728]: Sending gratuitous ARP on eth0 for 172.17.0.188

El servidor 172.17.0.2 todavía usa el VIP de 172.17.0.188;
verifique la información de registro del servidor 172.17.0.3

May 11 06:40:36 b31c0155f7d0 Keepalived_vrrp[6422]: VRRP_Instance(VI_2) Transition to MASTER STATE
May 11 06:40:41 b31c0155f7d0 Keepalived_vrrp[6422]: VRRP_Instance(VI_2) Entering MASTER STATE
May 11 06:40:41 b31c0155f7d0 Keepalived_vrrp[6422]: VRRP_Instance(VI_2) setting protocol VIPs.
May 11 06:40:41 b31c0155f7d0 Keepalived_vrrp[6422]: Sending gratuitous ARP on eth0 for 172.17.0.189
May 11 06:40:41 b31c0155f7d0 Keepalived_vrrp[6422]: VRRP_Instance(VI_2) Sending/queueing gratuitous ARPs on eth0 for 172.17.0.189
May 11 06:40:41 b31c0155f7d0 Keepalived_vrrp[6422]: Sending gratuitous ARP on eth0 for 172.17.0.189
May 11 06:40:41 b31c0155f7d0 Keepalived_vrrp[6422]: Sending gratuitous ARP on eth0 for 172.17.0.189
May 11 06:40:41 b31c0155f7d0 Keepalived_vrrp[6422]: Sending gratuitous ARP on eth0 for 172.17.0.189
May 11 06:40:41 b31c0155f7d0 Keepalived_vrrp[6422]: Sending gratuitous ARP on eth0 for 172.17.0.189

El servidor 172.17.0.3 usa el VIP 172.17.0.189 de la instancia v2,
use el comando ip addr para verificar si el VIP entra en conflicto;

[root@Master-02 ~]# ip addr |grep -Eo "([0-9]{1,3}\.){3}[0-9]{1,3}"
127.0.0.1
172.17.0.2
172.17.255.255
172.17.0.188

[root@Backup-03 ~]# ip addr |grep -Eo "([0-9]{1,3}\.){3}[0-9]{1,3}"
127.0.0.1
172.17.0.3
172.17.255.255
172.17.0.189

3.2 Simular el tiempo de inactividad del servicio

Continúe intentándolo después de que el servicio esté inactivo, ¿cuál es el resultado que se muestra?
El servicio nginx del primer servidor está cerrado

[root@Master-02 ~]# pkill nginx

[root@Backup-03 ~]# ip addr |grep -Eo "([0-9]{1,3}\.){3}[0-9]{1,3}"
127.0.0.1
172.17.0.3
172.17.255.255
172.17.0.189
172.17.0.188

Se puede ver que ambos VIP han corrido al segundo servidor, entonces alguien preguntará si habrá error si los dos VIP están en el mismo servidor, en teoría no será así, puedes verificar esto en la página web Los resultados mostrados por los dos VIP.

[root@VM-12-17-centos ~]# curl 172.17.0.188
0.3IP server 
[root@VM-12-17-centos ~]# curl 172.17.0.189
0.3IP server 

En este momento, después de que se restablezca el servicio del primer servidor, el VIP de 188 se vinculará nuevamente al servidor 172.17.0.2.

[root@Master-02 ~]# /usr/sbin/nginx
[root@Master-02 ~]# systemctl start keepalived;tail -fn 30 /var/log/messages
May 11 07:00:47 8be7506dd805 Keepalived_vrrp[8605]: Opening file '/etc/keepalived/keepalived.conf'.
May 11 07:00:47 8be7506dd805 Keepalived_vrrp[8605]: VRRP_Instance(VI_2) Entering BACKUP STATE
May 11 07:00:47 8be7506dd805 Keepalived_vrrp[8605]: VRRP sockpool: [ifindex(88), proto(112), unicast(0), fd(10,11)]
May 11 07:00:47 8be7506dd805 Keepalived_vrrp[8605]: VRRP_Script(check_nginx) succeeded
May 11 07:00:49 8be7506dd805 Keepalived_vrrp[8605]: VRRP_Instance(VI_1) Transition to MASTER STATE
May 11 07:00:54 8be7506dd805 Keepalived_vrrp[8605]: VRRP_Instance(VI_1) Entering MASTER STATE
May 11 07:00:54 8be7506dd805 Keepalived_vrrp[8605]: VRRP_Instance(VI_1) setting protocol VIPs.
May 11 07:00:54 8be7506dd805 Keepalived_vrrp[8605]: Sending gratuitous ARP on eth0 for 172.17.0.188
May 11 07:00:54 8be7506dd805 Keepalived_vrrp[8605]: VRRP_Instance(VI_1) Sending/queueing gratuitous ARPs on eth0 for 172.17.0.188
May 11 07:00:54 8be7506dd805 Keepalived_vrrp[8605]: Sending gratuitous ARP on eth0 for 172.17.0.188
May 11 07:00:54 8be7506dd805 Keepalived_vrrp[8605]: Sending gratuitous ARP on eth0 for 172.17.0.188

3.3 Aspectos a los que prestar atención en la estructura empresarial de doble propietario

La arquitectura empresarial Nginx+keepalived de doble propietario requiere los siguientes aspectos en el proceso diario de mantenimiento y administración:

• El archivo de configuración principal de Keepalived debe configurarse con diferentes nombres de VRRP, y las configuraciones de prioridad y VIP también son diferentes;
• El tráfico total del sitio web de Nginx es la suma de dos servidores Nginx, y se pueden escribir scripts para contar el tráfico automáticamente;
• Los dos Nginxes son maestros y hay dos direcciones VIP. Para acceder al VIP desde la red externa, el nombre de dominio debe asignarse a los dos VIP.
• El método de asignación de diferentes VIP a través del DNS de la red externa también se denomina modo de equilibrio de carga de DNS; puede monitorear si el estado de acceso VIP es normal a través de Zabbix en tiempo real.

Resumir

Es relativamente fácil configurar la alta disponibilidad de Keepalived+Nginx, cabe señalar que al configurar, el número de id debe ser el correspondiente, y la prioridad también debe determinarse qué máquina es la maestra y cuál es la copia de seguridad. arriba Si el contenido está bien, ¡por favor dale me gusta y apóyalo!