Directorio de artículos
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.
1. El cliente envía una solicitud al VIP de destino y el Director (balanceador de carga) la 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 local 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 de Internet a través del enrutador.
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 nodos 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 solicitudes ARP cuya IP de destino es la IP local
4. RealServer devuelve el mensaje (la IP de origen es VIP) y el enrutador lo reenvía. Al volver a encapsular el mensaje, primero se debe obtener la dirección MAC del enrutador.
5. Al enviar una solicitud ARP, Linux utiliza 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 de forma predeterminada, en lugar de utilizar la dirección IP de la interfaz de envío.
- Tales como: ens33
6. Una vez que el enrutador recibe la solicitud ARP, actualizará la entrada de la tabla ARP
7. La dirección MAC del Director correspondiente al VIP original se actualizará a la dirección MAC del RealServer correspondiente al VIP
8. El enrutador reenvía el nuevo mensaje de solicitud a RealServer de acuerdo con la entrada de la tabla ARP, lo que provoca que el VIP del Director falle.
Solución:
- Procese el servidor de nodo y establezca 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.
9. Configure métodos para resolver los dos problemas de ARP
Modifique 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
Tres, modo DR, clúster de equilibrio de carga LVS
(1) Análisis de 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 portal 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) Configure la dirección IP VIP en la interfaz lo en el servidor real.
Cuatro pasos de implementación del clúster de equilibrio de carga LVS-DR
Entorno de configuración:
servidor DR (programador de carga) (centos7-5): 192.168.200.50
servidor web 1 (centos7-6): 192.168.200.60
servidor web 2 (centos7-7): 192.168.200.70
servidor NFS (centos7-8) : 192.168.200.80
VIP: 192.168.200.188
Cliente Windows10: 192.168.200.200
1. Configure el programador de carga (192.168.200.50)
systemctl stop firewalld.service
systemctl disable firewalld.service
setenforce 0
modprobe ip_vs #加载ip_vs模块
cat /proc/net/ip_vs #查看ip_vs版本信息
yum install -y ipvsadm
（1）、配置虚拟 IP 地址（VIP：192.168.200.188）
cd /etc/sysconfig/network-scripts/
cp ifcfg-ens33 ifcfg-ens33:0
vim ifcfg-ens33:0
DEVICE=ens33:0
ONBOOT=yes
IPADDR=192.168.200.188
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
或者
ipvsadm --save > /etc/sysconfig/ipvsadm
systemctl start ipvsadm.service
ipvsadm -C #清除原有策略
ipvsadm -A -t 192.168.200.188:80 -s rr
ipvsadm -a -t 192.168.200.188:80 -r 192.168.200.60:80 -g #若为隧道模式，-g替换为-i
ipvsadm -a -t 192.168.200.188:80 -r 192.168.200.70:80 -g
ipvsadm -ln #查看节点状态，Route代表 DR模式
2. Implementar almacenamiento compartido (servidor NFS: 192.168.200.80)
systemctl stop firewalld.service
systemctl disable firewalld.service
setenforce 0
yum install -y nfs-utils rpcbind
systemctl start nfs.service
systemctl start rpcbind.service
systemctl enable nfs.service
systemctl enable rpcbind.service
mkdir /opt/gcc /opt/benet
chmod 777 /opt/gcc/ /opt/benet/
vim /etc/exports
/usr/share *(ro,sync)
/opt/gcc 192.168.200.0/24(rw,sync) #/24与()之间不能有空格
/opt/benet 192.168.200.0/24(rw,sync)
exportfs -rv
showmount -e
3. Configure el servidor de nodo (192.168.200.60, 192.168.200.70)
systemctl stop firewalld.service
systemctl disable firewalld.service
setenforce 0
#将两个节点服务器的网关和DNS注释掉后重启网卡，如果有网关服务器则指向网关服务器
（1）、配置虚拟 IP 地址（VIP：192.168.200.188）
#此地址仅用做发送 Web 响应数据包的源地址，并不需要监听客户机的访问请求（改由调度器监听并分发）。因此使用虚接口 lo:0 来承载 VIP 地址，并为本机添加一条路有记录，将访问 VIP 的数据限制在本地，以避免通信紊乱。
cd /etc/sysconfig/network-scripts/
cp ifcfg-lo ifcfg-lo:0
vim ifcfg-lo:0
DEVICE=lo:0
IPADDR=192.168.200.188
NETMASK=255.255.255.255 #注意子网掩码必须全为1
#NETWORK=127.0.0.0
# If you're having problems with gated making 127.0.0.0/8 a martian,
# you can change this to something else (255.255.255.255, for example)
#BROADCAST=127.255.255.255
ONBOOT=yes
#NAME=loopback
ifup lo:0
ifconfig lo:0
route add -host 192.168.200.188 dev lo:0 #禁锢路由
route -n #查看路由
vim /etc/rc.local
/sbin/route add -host 192.168.200.188 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 install -y nfs-utils rpcbind httpd
systemctl start rpcbind
systemctl start httpd
----------192.168.200.60-----------------
mount.nfs 192.168.200.80:/opt/gcc /var/www/html/
echo 'this is gcc web!' > /var/www/html/index.html
#设为自动挂载
vim /etc/fstab
192.168.200.80:/opt/gcc /var/www/html nfs defaults,_netdev 0 0
mount -a
----------192.168.200.70-----------------
mount.nfs 192.168.200.80:/opt/benet /var/www/html/
echo 'this is benet web!' > /var/www/html/index.html
#设为自动挂载
vim /etc/fstab
192.168.200.80:/opt/benet /var/www/html nfs defaults,_netdev 0 0
mount -a
4. Pruebe el clúster LVS
Utilice un navegador en el cliente para acceder: http://192.168.200.188/, la puerta de enlace predeterminada apunta a 192.168.200.188
