Compartir tecnología

Clúster lvs, modo NAT y modo DR, keepalive

2024-07-12

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

Tabla de contenido

concepto de clúster lvs

Tipos de clusters: tres tipos

Índice de confiabilidad del sistema

Terminología en el clúster lvs

como funciona lvs

modo NAT

herramientas lvs

algoritmo

experimento

flujo de datos

paso

1. Configuración del programador (prueba1 192.168.233.10)

2. Configuración RS (nginx1 y nginx2)

3. Traducción de direcciones (prueba1 192.168.233.10)

Resultados experimentales

modo DR

concepto

Diagrama de flujo de datos

pregunta:

1.Conflicto de dirección VIP

2. Cuando se devuelve el mensaje, la dirección VIP todavía está ahí. ¿Cómo puede el cliente recibir la respuesta?

Implementación del modo DR

paso

1. Configuración del programador (prueba1 192.168.233.10)

2. Configuración RS (nginx1 y nginx2) [debe modificarse ambas veces]

Resultados experimentales

Resumir

Experimento resumido

LVS implementa el reenvío de cuatro capas + nginx implementa el reenvío de siete capas (dinámico) Acceder a la dirección VIP de LVS puede lograr una separación dinámica y estática.

Diagrama de flujo de datos

Pasos experimentales

Resultados experimentales

Tres modos de trabajo de lvs.

Arquitectura HA de alta disponibilidad

concepto

experimento de mantener vivo

Pasos experimentales

anfitrión

Editar

Preparar

Resultados experimentales


concepto de clúster lvs

El nombre completo es servidor virtual Linux, que es un software que implementa el equilibrio de carga a nivel del kernel de Linux.

Función principal: forme varios servidores back-end en un clúster de servidores de alto rendimiento y alta disponibilidad, y distribuya las solicitudes de los clientes a los servidores back-end a través de algoritmos de equilibrio de carga para lograr alta disponibilidad y equilibrio de carga.

El equilibrio de carga del servidor SLB de Alibaba se implementa mediante lvs + keepalive.

Agrupados y distribuidos

Cómo ampliar el sistema:

Escalado vertical: escalar hacia arriba para construir computadoras más capaces.Cuello de botella: limitaciones del propio equipo informático; cuellos de botella en el rendimiento del propio hardware;

Expansión horizontal: Expanda hacia afuera y agregue equipos.Ejecute múltiples servicios en paralelo y confíe en la red para resolver problemas de comunicación interna, clúster

Clúster: Un sistema único formado por la combinación de varias computadoras para resolver un problema específico.

Tipos de clusters: tres tipos

LB: Clúster de equilibrio de carga de equilibrio de carga, compuesto por varios hosts, cada host solo soporta parte de las solicitudes de acceso

JA : alta disponibilidad: al diseñar el sistema, se toman ciertas medidas para garantizar que si un componente o parte del sistema falla, todo el sistema aún pueda funcionar normalmente.Para mantener la disponibilidad, confiabilidad y tolerancia a fallas del sistema.

Computación de alto rendimiento:Clúster de computación de alto rendimiento con mayores requisitos de tiempo de respuesta y potencia de procesamiento.

Índice de confiabilidad del sistema

MI NOVIO:Tiempo medio entre fallos Tiempo medio entre fallos

Tiempo medio de transporte:Tiempo medio de recuperación tiempo medio de recuperación

A=MTBF/(MTBF+MTTR)

El índice A debe estar entre 0 y 1. El índice A es una medida de la disponibilidad del sistema. 0 significa que el sistema está menos disponible, 1 significa que el sistema está más disponible.

El indicador A debe estar infinitamente cerca de 1 (98%-99% calificado; 90%-95% no calificado)

Todos están en horas (8760 horas en 1 año, 365 días)

El tiempo de inactividad y el tiempo planificado no están incluidos.

El tiempo no planificado, es decir, el tiempo de falla, es el tiempo total desde que ocurre la falla hasta su resolución. El tiempo no planificado es un indicador al que debemos prestar atención.

Escenarios aplicables de LVS:

Los clústeres pequeños no necesitan usar lvs, use nginx, los clústeres grandes usan lvs

Terminología en el clúster lvs

VS: el nombre lógico del servicio lvs del servidor virtual, que es la dirección IP y el puerto que utilizamos cuando accedemos al clúster lvs externamente.

DS: el servidor principal en el clúster lvs del servidor director, es decir, el programador (es decir, el servidor proxy nginx), es el núcleo del clúster. El programador se utiliza para aceptar solicitudes de clientes y reenviarlas al back-end. servidor.

RS: el servidor real en el clúster lvs del servidor real, el servidor back-end, se utiliza para aceptar solicitudes reenviadas por DS y responder a los resultados.

CIP: ip del cliente La dirección del cliente, es decir, la dirección del cliente que inició la solicitud

VIP: dirección IP virtual utilizada por el clúster lvs, dirección IP virtual que proporciona acceso al clúster externo

DIP: la ip del director es la dirección del planificador en el clúster, utilizada para comunicarse con RS

RIP: IP real La dirección IP del servidor back-end en el clúster.

como funciona lvs

Modo NAT: el programador responde al modo al cliente (traducción de direcciones)

Modo DR (modo de enrutamiento directo): el servidor real responde directamente al cliente

Modo TUN: modo túnel

Modos de uso común: modo NAT y modo DR

modo NAT

En el modo NAT, LVS modificará la dirección IP y el puerto de destino en el mensaje de solicitud del cliente a la dirección IP y el puerto dentro de LVS, y luego reenviará la solicitud al servidor back-end.

Cuando el resultado de la respuesta se devuelve al cliente, lvs procesa el mensaje de respuesta y la IP y el puerto de destino se modifican a la dirección IP y el puerto del cliente.

Principio: Primero, cuando el equilibrador de carga recibe el paquete de solicitud del cliente, determina a qué servidor real (RS) backend enviar la solicitud según el algoritmo de programación.
Luego, el equilibrador de carga cambia la dirección IP de destino y el puerto del paquete de solicitud enviado por el cliente a la dirección IP (RIP) del servidor real back-end.
Después de que el servidor real responde a la solicitud, verifica la ruta predeterminada y envía el paquete de datos de respuesta al balanceador de carga. Después de recibir el paquete de respuesta, el balanceador de carga.
Cambie la dirección de origen del paquete a una dirección virtual (VIP) y envíelo de regreso al cliente.

Ventajas: Los servidores del clúster pueden utilizar cualquier sistema operativo que admita TCP/IP, siempre que el equilibrador de carga tenga una dirección IP legal.

Desventajas: Escalabilidad limitada Cuando los nodos del servidor crecen demasiado, ya que todas las solicitudes y respuestas deben pasar por el equilibrador de carga.
Por lo tanto, el equilibrador de carga se convertirá en el cuello de botella de todo el sistema.

Caracterizado por la traducción de direcciones.

Traducción de direcciones: red interna - red externa, la dirección IP de origen se convierte SNAT

Red externa-red interna convierte la dirección IP de destino DNAT

herramientas lvs

Admin. IPVSHerramientas para configurar y administrar clústeres lvs

-A agrega servidor virtual vip

-D eliminar la dirección del servidor virtual

-s especifica el algoritmo de programación de equilibrio de carga

-a agrega servidor real

-d eliminar el servidor real

-t especifica la dirección VIP y el puerto

-r especifica la dirección y el puerto de rip

-m Usar modo NAT

-g Usar modo DR

-i Usar modo túnel

-w establece el peso

-p 60 mantiene la conexión durante 60 segundos Establece el tiempo de espera de la conexión

-l vista de lista

-n pantalla digital

algoritmo

Encuesta

Encuesta ponderada

Conexión mínima lc

enlace mínimo ponderado wlc

experimento

flujo de datos

nginx1RS1192.168.233.20

nginx2 RS2 192.168.233.30

programador test1 ens33 192.168.233.10 ens36 12.0.0.1

cliente test2 12.0.0.10

paso
1. Configuración del programador (prueba1 192.168.233.10)

yum -y instalar ipvsadm* -y

Configurar ens33

systemctl reiniciar red

Configurar ens36

cd /etc/sysconfig/scripts-de-red/

cp ifcfg-ens33 ifcfg-ens36

vim ifcfg-ens36

systemctl reiniciar red

2. Configuración RS (nginx1 y nginx2)

Configurar nginx1 192.168.233.20 Modificar puerta de enlace

systemctl reiniciar red

Configurar nginx2 192.168.233.30 Modificar puerta de enlace

systemctl reiniciar red

vim /usr/local/nginx/html/index.html

Modificar el contenido de la página visitada

Compruebe si el acceso está conectado

3. Traducción de direcciones (prueba1 192.168.233.10)

iptables -t nat -vnL Compruebe si la tabla nat tiene una política

1.

iptables -t nat -A POSTROUTING -s 192.168.233.0/24 -o ens36 -j SNAT --to 12.0.0.1

La dirección del dispositivo de 192.168.233.0/24 se convierte a 12.0.0.1

2.

ipvsadm -C borra la política original

ipvsadm -A -t 12.0.0.1:80 -s rr Especifique la dirección VIP y el puerto

Primero agregue el VIP, la IP y el puerto del servidor virtual, y luego agregue el servidor real

3.

ipvsadm -a -t 12.0.0.1:80 -r 192.168.233.20:80 -m

-agregar servidor real

-t especifica la dirección vip

-r especifica la dirección y el puerto del servidor real

-m especifica el modo como modo nat

ipvsadm -en vista

4.

ipvsadm-save guardar

ipvsadm -D -t 192.168.233.10:80 eliminar política

ipvsadm -d -r 192.168.233.20: -t 12.0.0.1:80 eliminar servidor de nodo

5. Habilite la función de enrutamiento y reenvío

vim /etc/sysctl.conf

red.ipv4.ip_forward=1

4. Cliente (prueba2 12.0.0.10)

Modificar la dirección IP y la puerta de enlace de test2

Resultados experimentales

encuesta ponderada

modo DR

concepto

es el modo de enrutamiento directo

Modo NAT: el programador es el más importante en todo el clúster LVS. En el modo NAT, es responsable de recibir solicitudes, reenviar el tráfico de acuerdo con el algoritmo de equilibrio de carga y enviar respuestas al cliente.

Modo DR: el programador sigue siendo responsable de recibir solicitudes y también reenvía el tráfico a RS de acuerdo con el algoritmo de equilibrio de carga, y RS envía la respuesta directamente al cliente.

Enrutamiento directo: es un modo de reenvío de Capa 2. La Capa 2 reenvía tramas de datos y las reenvía en función de la dirección MAC de origen y la dirección MAC de destino sin modificar la IP de origen y la IP de destino del paquete de datos. Reenviar según la dirección MAC del paquete de datos.

En el modo DR, LVS también mantiene una dirección IP virtual y todas las solicitudes se envían a este VIP. Dado que se utiliza el reenvío de capa 2, cuando la solicitud del cliente llega al planificador, se selecciona un RS de acuerdo con el algoritmo de equilibrio de carga y el servidor VIP. Se modifica. La mac de destino se convierte en la dirección mac de RS. Después de que RS procesa la solicitud, puede enviar la respuesta directamente al cliente en función de la dirección mac de origen del cliente en el mensaje, sin pasar por el programador.

Principio: Primero, cuando el equilibrador de carga recibe el paquete de solicitud del cliente, determina a qué servidor real (RS) backend enviar la solicitud según el algoritmo de programación.
Luego, el equilibrador de carga cambia la dirección MAC de destino del paquete de solicitud enviado por el cliente a la dirección MAC del servidor real backend (R-MAC).
Después de que el servidor real responde a la solicitud, verifica la ruta predeterminada y envía el paquete de respuesta directamente al cliente sin pasar por el equilibrador de carga.

Ventajas: el equilibrador de carga solo es responsable de distribuir los paquetes de solicitud a los servidores del nodo back-end, mientras que RS envía paquetes de respuesta directamente a los usuarios.
Por lo tanto, se reduce la gran cantidad de flujo de datos a través del balanceador de carga. El balanceador de carga ya no es el cuello de botella del sistema y puede manejar una gran cantidad de solicitudes.

Desventajas: tanto el equilibrador de carga como el servidor real RS deben tener una tarjeta de red conectada al mismo segmento de red física y deben estar en el mismo entorno LAN.

Diagrama de flujo de datos

pregunta:
1.Conflicto de dirección VIP

Motivo: el planificador está configurado con VIP y el RS también está configurado con una dirección VIP. El conflicto de direcciones VIP, debido a que el planificador y RS están en el mismo segmento de red, provocará un trastorno en la comunicación ARP. Debido a que se transmite a través de toda la LAN, todos los dispositivos lo reciben.

Cómo bloquear la respuesta loopback de lo para que solo responda la dirección IP física de esta máquina.

Solución: modifique los parámetros del kernel:arp_ignore=1

Solo la dirección IP física del sistema responderá a las solicitudes ARP y la interfaz de bucle invertido no responderá a las solicitudes ARP.

2. Cuando se devuelve el mensaje, la dirección VIP todavía está ahí. ¿Cómo puede el cliente recibir la respuesta?

Solución:arp_announce=2

El sistema no utiliza la dirección de origen del paquete IP para responder a la solicitud ARP, sino que envía directamente la dirección IP de la interfaz física.

Implementación del modo DR

nginx1 RS (IP real) 192.168.233.20

nginx2RS192.168.233.30

vip192.168.233.100

Programador 192.168.233.10

Cliente 192.168.233.40

paso
1. Configuración del programador (prueba1 192.168.233.10)

yum -y instalar ipvsadm* -y

Agregar tarjeta de red virtual ens33:0

Modificar los parámetros de respuesta del planificador.

vim /etc/sysctl.conf

red.ipv4.ip_forward=0
net.ipv4.conf.all.send_redirects=0
net.ipv4.conf.default.send_redirects=0
net.ipv4.conf.ens33.send_redirects=0
 

sistema -p

Agregar política

cd/optar

ipvsadm -A -t 192.168.233.100:80 -s rr

ipvsadm -a -t 192.168.233.100:80 -r 192.168.233.20:80 -g

ipvsadm -a -t 192.168.233.100:80 -r 192.168.233.30:80 -g

ipvsadm-guardar >/etc/sysconfig/ipvsadm

systemctl reiniciar ipvsadm

ipvsadm-ln

2. Configuración RS (nginx1 y nginx2) [debe modificarse ambas veces]

Modificar el contenido de visualización de páginas estáticas

vim /usr/local/nginx/html/index.html

systemctl reiniciar nginx

Agregar dirección de bucle invertido

cd /etc/sysconfig/scripts-de-red/

cp ifcfg-lo ifcfg-lo:0

vim ifcfg-lo:0

Agregar interfaz lo:0 como vip

ruta agregar -host 192.168.233.100 dev lo:0

Configure la dirección IP en 192.168.233.100 y agréguela a la interfaz loopback como VIP de lvs. Se reenvía a RS a través del modo de enrutamiento, lo que permite al VIP identificar el servidor real.

Modificar la respuesta del kernel del servidor real RS

vim /etc/sysctl.conf

net.ipv4.conf.lo.arp_ignore=1
net.ipv4.conf.lo.arp_announce=2
net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.all.arp_announce=2

Resultados experimentales

Modificar el algoritmo de sondeo VIP

Modificar el peso en las encuestas de políticas

Resumir

La diferencia entre lvs y nginx para el equilibrio de carga

LVS es un reenvío de cuatro capas, utiliza el puerto ip + en modo kernel y solo se puede usar como un proxy de cuatro capas.

Proxy nginx de cuatro capas o proxy de siete capas

Experimento resumido

lvs (modo DR)+nginx+tomcat

LVS implementa el reenvío de cuatro capas + nginx implementa el reenvío de siete capas (dinámico) Acceder a la dirección VIP de LVS puede lograr una separación dinámica y estática.

Diagrama de flujo de datos

Pasos experimentales

Según los experimentos anteriores en modo DR, se logra la separación dinámica y estática.

1. Parte de Tomcat

1. Cree páginas dinámicas en tomcat1 y tomcat2 respectivamente.

<%@ página idioma="java" importación="java.util.*" páginaEncoding="UTF-8"%>
<html>
<head>
<title>Página de prueba 1 de JSP</title>
</head>
<body>
&lt;% out.println("Página dinámica 1, http://www.test1.com");%&gt;
</body>
</html>

2. Agregue sitios a tomcat1 y tomcat2 respectivamente

conferencia de cd

servidor vim.xml

Eliminar el sitio original primero

<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true" xmlValidation="false" xmlNamespaceAware="false">
    <Context docBase="/usr/local/tomcat/webapps/test" path="" reloadable="true" />

Compruebe si el puerto está iniciado

Visita 192.168.233.40:8080/index.jsp

2. parte nginx

Configurar nginx2 y nginx3

Ejecute /usr/local/nginx/conf/

cp nginx.conf nginx.conf.bak.2024.07.08

vim nginx.conf

tomcat aguas arriba {
servidor 192.168.233.40:8080 peso=1;
servidor 192.168.233.50:8080 peso=1;
}

ubicación ~ .*.jsp$ {
contraseña_proxy http://tomcat;
encabezado_conjunto_proxy HOST $host;
encabezado_conjunto_proxy X-Real-IP $dirección_remota;
proxy_set_header X-Reenviado-Para $proxy_add_x_reenviado_para;
        }

Luego systemctl reinicia nginx

Configurar el proxy nginx1

Sea un agente de cuatro niveles

Ejecute /usr/local/nginx/conf

vim nginx.conf

Luego systemctl reinicia nginx

Resultados experimentales

Visita la página estática 192.168.100:81

Visite la página dinámica 192.168.233.100:82/index.jsp

Tres modos de trabajo de lvs.

Dr. Tun

Ventajas: traducción de direcciones, configuración simple, mejor rendimiento WAN, puede lograr el reenvío de paquetes de datos a mayor distancia

Desventajas Cuello de botella en el rendimiento No admite canales dedicados de segmentos entre redes, requiere abrir una VPN (cuesta dinero)

Requisitos de RS: No se deben admitir restricciones en las interfaces no físicas. Se debe admitir el modo túnel.

Cantidad de RS 10-20 unidades 100 unidades 100 unidades

Preguntas de entrevista:

1. Describe brevemente los tres modos y diferencias de lvs.

tabla de arriba

2. Cómo solucionar el cerebro dividido en keepalive

Arquitectura HA de alta disponibilidad

concepto

Es una arquitectura de alta disponibilidad en el cluster vs, solo para la alta disponibilidad del planificador.

Implementar los programadores principales y de respaldo basados ​​en vrp.

Programador principal y programador de respaldo (múltiples unidades)

Cuando el programador principal funciona normalmente, la copia de seguridad está completamente en estado redundante (en espera) y no participa en la operación del clúster. Sólo cuando el programador principal falla, el servidor de respaldo asumirá el trabajo del programador principal. Si el programador principal reanuda su función, el programador principal continuará sirviendo como entrada al clúster y el en espera continuará en un estado redundante, lo que no necesariamente depende de la prioridad.

Keepalive se basa en el protocolo vrp 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 y envía mensajes entre los dispositivos primario y secundario.Determinar si el oponente está vivo.

2. Determinar las posiciones de primaria y secundaria en función de la prioridad.

3. Conmutación por error: si el servidor principal falla, el servidor de respaldo seguirá funcionando.El Señor se ha recuperado y está en espera.

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.

experimento de mantener vivo

prueba1 192.168.233.10 más

test2 192.168.233.50 hora

vip192.168.233.100

nginx1 192.168.233.20

nginx2 192.168.233.30

Cliente 192.168.233.40

Pasos experimentales

1. Tanto las operaciones primarias como las secundarias deben realizarse de la misma manera.

yum -y install ipvsadm mantiene vivo

vim /etc/sysctl.conf

red.ipv4.ip_forward=0
net.ipv4.conf.all.send_redirects=0
net.ipv4.conf.default.send_redirects=0
net.ipv4.conf.ens33.send_redirects=0

sistema -p

ipvsadm-C

ipvsadm -A -t 192.168.233.100:80 -s rr

ipvsadm -a -t 192.168.233.100:80 -r 192.168.233.20:80 -g

ipvsadm -a -t 192.168.233.100:80 -r 192.168.233.30:80 -g

ipvsadm-guardar &gt;/etc/sysconfig/ipvsadm

systemctl reiniciar ipvsadm

ipvsadm-ln

anfitrión

cd /etc/keepalive

vim keepalived.conf

Preparar

Resultados experimentales