Este artículo ha optimizado los pasos de construcción de keepalived en el blog anterior, y lo siguiente es productos secos publicados directamente
1. Medio ambiente
Anfitrión: estación de trabajo profesional Win10
VMware: 16Pro (16.1.0)
CentOS 7
Adaptador de red: todo en modo NAT
Configuración de la tarjeta de red: obtener IP estáticamente
Fuente de YUM: local
Servidor DR principal (programador de carga) (CentOS 7-1): 192.168.126.11
Desde el servidor DR (programador de carga) (CentOS 7-2): 192.168.126.12
Servidor web 1 (CentOS 7-3): 192.168.126.13
Servidor web 2 (CentOS 7-4): 192.168.126.14
Servidor NFS (CentOS 7-5): 192.168.126.15
VIP: 192.168.126.166
Cliente Win10: 192.168.126.10
2. Pasos de construcción
Este experimento se basa en el clúster de equilibrio de carga LVS-DR que se ha preparado, y solo se agrega un programador esclavo, y la configuración es consistente con el programador maestro
Al ver esto, necesito seguir mi blog anterior para construir LVS + DR primero, y luego agregar un programador esclavo con la misma configuración. El enlace se publica a continuación
Primero, el maestro y el esclavo ejecutan este comando por separado
Como puede ver, solo el maestro tiene VIP
Luego cerramos el keepalived principal para intentar
El VIP se desvió hacia el programador esclavo, luego reiniciamos el keepalived del programador maestro y encontramos que la IP virtual estaba de nuevo, esto está relacionado con la prioridad maestro-esclavo establecida previamente.
Por lo tanto, se verifica que la dirección IP del enrutador virtual (VIP) se puede transferir entre los enrutadores en el grupo de espera activa
Verifiquemos finalmente el acceso al navegador, aquí la puerta de enlace predeterminada del cliente no necesita apuntar a VIP