1. Análisis de flujo de paquetes de datos LVS-DR

Para facilitar el análisis del principio, el Cliente y la máquina del clúster se colocan en la misma red y la ruta del paquete de datos es 1-2-3-4.
Inserte la descripción de la imagen aquí
1. El cliente envía una solicitud al VIP objetivo y el Director (balanceador de carga) lo recibe. En este momento, la dirección MAC de origen es la dirección MAC del cliente y la dirección MAC de destino es la dirección MAC del director del planificador.

2. El Director selecciona RealServer_1 de acuerdo con el algoritmo de equilibrio de carga, no modifica ni encapsula el mensaje IP, pero cambia la dirección MAC de la trama de datos a la dirección MAC de RealServer_1 y luego la envía a la LAN. En este momento, la dirección MAC de origen es la dirección MAC de Director y la dirección MAC de destino es la dirección MAC de RealServer_1.

3. RealServer_1 recibe este marco y encuentra que la IP de destino coincide con la máquina después de la desencapsulación (RealServer está vinculado a VIP de antemano), por lo que procesa este mensaje. Luego, vuelva a encapsular el mensaje y envíe el mensaje de respuesta a la tarjeta de red física a través de la interfaz lo y luego envíelo. En este momento, la dirección MAC de origen es la dirección MAC de RealServer_1 y la dirección MAC de destino es la dirección MAC del cliente.

4. El cliente recibirá el mensaje de respuesta. El Cliente cree que recibe el servicio normal, pero no sabe qué servidor lo maneja.
Nota: Si cruza el segmento de red, el mensaje se devolverá al usuario a través del enrutador a través de Internet.

En segundo lugar, el problema de ARP en LVS-DR

1. En el clúster de equilibrio de carga LVS-DR, tanto el equilibrio de carga como el servidor de nodo deben configurarse con la misma dirección VIP.
2. Tener la misma dirección IP en la red de área local causará inevitablemente un desorden de la comunicación ARP entre servidores.

Cuando la transmisión ARP se envía al clúster LVS-DR, debido a que el equilibrador de carga y el servidor de nodo están conectados a la misma red, ambos recibirán la transmisión ARP.
Solo responde el equilibrador de carga de front-end y otros servidores de nodo no deberían responder a las difusiones ARP.
3. Procese el servidor de nodo para que no responda a las solicitudes de ARP para VIP
Utilice la interfaz virtual lo: 0 para transportar direcciones VIP
Establezca el parámetro del kernel arp_ignore = 1: el sistema solo responde a las solicitudes ARP cuya IP de destino es la IP local.
4. RealServer devuelve paquetes (la IP de origen es VIP) que son reenviados por el enrutador. Al volver a encapsular los paquetes, el MAC primero se debe obtener la dirección del enrutador.
5. Al enviar una solicitud ARP, Linux utiliza de forma predeterminada la dirección IP de origen del paquete IP (es decir, VIP) como la dirección IP de origen en el paquete de solicitud ARP en lugar de la dirección IP de la interfaz de envío, como por ejemplo: ens33
6. Después de que el enrutador reciba la solicitud ARP, actualizará la entrada ARP
7. El VIP original correspondiente a la dirección MAC del Director se actualizará al VIP correspondiente a la dirección MAC del RealServer
8. El enrutador reenviará el nuevo mensaje de solicitud al RealServer de acuerdo con la entrada ARP, lo que da como resultado la
solución de falla VIP del Director :
Para procesar el servidor de nodo, configure el parámetro del kernel arp_announce = 2: el sistema no usa la dirección de origen del paquete IP para establecer la dirección de origen de la solicitud ARP, sino que selecciona la dirección IP de la interfaz de envío.
El método de configuración para resolver los dos problemas de ARP
Modificar el archivo /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

3. Modo DR del clúster de equilibrio de carga LVS

1. Análisis del flujo de paquetes de datos

(1) El cliente envía una solicitud al Director Server (equilibrador de carga) y el mensaje de datos solicitado (la IP de origen es CIP, la IP de destino es VIP) llega al espacio del kernel.
(2) Director Server y Real Server están en la misma red y los datos se transmiten a través de la capa de enlace de datos de la segunda capa.
(3) El espacio del kernel juzga que la IP de destino del paquete de datos es el VIP local. En este momento, IPVS (servidor virtual IP) compara si el servicio solicitado por el paquete de datos es un servicio de clúster y vuelve a empaquetar el paquete de datos si es un servicio de clúster. Modifique la dirección MAC de origen a la dirección MAC del Director Server y modifique la dirección MAC de destino a la dirección MAC del Real Server. Las direcciones IP de origen y destino no han cambiado, y luego envíe el paquete de datos al Real Server.
(4) La dirección MAC del mensaje de solicitud que llega al servidor real es su propia dirección MAC y se recibe el mensaje. El paquete de datos vuelve a encapsular el mensaje (la dirección IP de origen es VIP y la IP de destino es CIP), y el mensaje de respuesta se transmite a la tarjeta de red física a través de la interfaz lo y luego se envía.
(5) Real Server transmite directamente el mensaje de respuesta al cliente.

2. Características del modo DR

(1) Director Server y Real Server deben estar en la misma red física.
(2) Real Server puede utilizar una dirección privada o una dirección de red pública. Si usa una dirección de red pública, puede acceder directamente a RIP a través de Internet.
(3) Director Server sirve como entrada de acceso al clúster, pero no como puerta de enlace.
(4) Todos los mensajes de solicitud pasan por Director Server, pero los mensajes de respuesta de respuesta no pueden pasar por Director Server.
(5) La puerta de enlace del Real Server no puede apuntar a la IP del Director Server, es decir, los paquetes de datos enviados por el Real Server no pueden pasar a través del Director Server.
(6) La interfaz lo en el servidor real está configurada con la dirección IP VIP.

Modo LVS-DR de cuatro experimentos pequeños y simples

########DR模式LVS负载均衡群集部署#########
DR 服务器：192.168.241.3
Web 服务器1：192.168.241.4
Web 服务器2：192.168.241.5
vip :192.168.241.200
客户端：192.168.241.6

1、配置负载调度器（192.168.241.3）
systemctl stop firewalld.service
setenforce 0
modprobe ip_vs
cat /proc/net/ip_vs
yum -y install ipvsadm

(1)配置虚拟IP地址（VIP：192.168.241.200）
cd /etc/sysconfig/network-scripts
#若隧道模式，复制为ifcfg-tunl0
vim ifcfg-ens33:0
DEVICE=ens33:0
ONBOOT=yes
IPADDR=192.168.241.200
NETMASK=255.255.255.255
ifup ens33:0
ifconfig ens33:0
(2)调整proc响应参数
#由于LVS负载调度器和各节点需要共用VIP地址，应该关闭Linux内核的重定向参数响应，不充当路由器
vim /etc/sysctl.conf
net.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
sysctl -p
(3)配置负载分配策略
ipvsadm-save > /etc/sysconfig/ipvsadm
systemctl start ipvsadm
ipvsadm -C
ipvsadm -A -t 192.168.241.200:80 -s rr
ipvsadm -a -t 192.168.241.200:80 -r 192.168.241.4:80 -g		#若隧道模式，-g替换为-i
ipvsadm -a -t 192.168.241.200:80 -r 192.168.241.5:80 -g
ipvsadm
ipvsadm -ln				#查看节点状态，Router代表DR模式

2、部署共享存储（NFS服务器：192.168.241.6）
systemctl stop firewalld.service
setenforce 0

yum -y install nfs-utils rpcbind
mkdir /opt/kgc /opt/benet
chmod 777 /opt/kgc /opt/benet

vim /etc/exports
/opt/kgc 192.168.241.0/24(rw,sync,no_root_squash)
/opt/benet 192.168.241.0/24(rw,sync,no_root_squash)
echo 'this is benet web' > /opt/benet/index.html
echo 'this is kgc web' > /opt/kgc/index.html

systemctl start nfs
systemctl start rpcbind

3、配置节点服务器（192.168.241.4、192.168.241.5）
systemctl stop firewalld.service
setenforce 0
（1）配置虚拟IP地址（VIP：192.168.241.200）
#此地址仅用作发送Web响应数据包的源地址，并不需要监听客户机的访问请求（改由调度器监听并分发）。因此使用需接口lo:0来承载VIP地址，并为本机添加一条路由记录，将访问VIP的数据限制在本地，以避免通信紊乱
cd /etc/sysconfig/network-scripts		##需要将ens33的网关和DNS注释
cp ifcfg-lo ifcfg-lo:0
vim ifcfg-lo:0
DEVICE=lo:0
ONBOOT=yes
IPADDR=192.168.241.200
NETMASK=255.255.255.255
ifup lo:0
ifconfig lo:0

route add -host 192.168.241.200 dev lo:0
或者vim /etc/rc.local
/sbin/route add -host 192.168.241.200 dev lo:0
chmod +x /etc/rc.d/rc.local

(2)调整内核的ARP响应参数以阻止更新VIP的MAC地址，避免发生冲突
vim /etc/sysctl.conf
......
net.ipv4.conf.lo.arp_ignore = 1				#系统只响应目的IP为本地IP的ARP请求
net.ipv4.conf.lo.arp_announce = 2			#系统不使用IP包的源地址来设置ARP请求的源地址，而选择发送接口的IP地址
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
sysctl -p
或者
echo "1" >/proc/sys/net/ipv4/conf/lo/arp_ignore
echo "2" >/proc/sys/net/ipv4/conf/lo/arp_announce
echo "1" >/proc/sys/net/ipv4/conf/all/arp_ignore
echo "2" >/proc/sys/net/ipv4/conf/all/arp_announce

yum -y install nfs-utils rpcbind httpd
systemctl start rpcbind
systemctl start httpd

####192.168.241.4
mount 192.168.241.6:/opt/kgc /var/www/html


####192.168.241.5
mount 192.168.241.6:/opt/benet /var/www/html

4. Pruebe el clúster LVS
. Utilice un navegador en el cliente para visitar http://192.168.241.200, y la puerta de enlace predeterminada apunta a 192.168.241.200
Inserte la descripción de la imagen aquí

Implementación en modo DR de LVS

Tabla de contenido