Cluster LVS-NAT mode

LVS-NAT mode

The scenarios of DR use belong to the conventional use load of the intranet, and the NAT mode is necessary to realize the NAT function, as follows.

  • The scheduler has public network and Intranet addresses, and needs to realize public network access for load
  • The IP addresses of virtualization scenarios are all used internally by virtualization, and the IP address on the host is similar to the function of the public network to realize virtualization and the load of the intranet

That is to say, the communication between the two sides of the scheduler cannot be realized, which can be solved by using NAT mode

NAT is much simpler than DR mode, because the principle is that we commonly use the SNAT and gateway configuration of firewall to forward the traffic of multiple servers through one computer. The premise is that the gateway of multiple computers needs to point to the computer that forwards the traffic, and the public network needs to access the scheduler through DNAT (the public network enters through DNAT, and the internal network sends through SNAT)

Take a look at traffic forwarding

The public network accesses the server through DNAT
If the intranet wants to access the public network, it needs SNAT

The uncomplicated NAT mode is NAT mapping, but the question is whether the scheduler and the real server can not be in the same network segment?

No, because the real server needs to forward the traffic to the scheduler, that is, through the function of the gateway. If it is not in a network segment, the server will forward the traffic to the gateway configured by itself instead of the address of the scheduler. In this way, it is impossible to establish with the public network, that is, if you want to realize the DR mode, you can't accept the traffic without forwarding the traffic


  • For the forwarding of data involving multiple network cards, it is necessary to turn on the routing forwarding function of the scheduler
vim /etc/sysctl.conf 
net.ipv4.ip_forward = 1
# sysctl -p


  • The scheduler and the real server need to be in a broadcast domain
  • The real server needs to point to the gateway as the scheduler
  • Different support ports
  • The flow in and out passes through the scheduler, which is under great pressure


lvs_vip vip is in different network segments
lvs_dip dip and rip are in the same network segment
Server168.in141.ngx server
server2 nginx server

Scheduler LVS to configure
[root@LVS1 ~]# ls /usr/lib/modules/3.10.0-957.el7.x86_64/kernel/net/netfilter/ipvs/ |grep  -e ip_vs                
#Query whether the kernel integrates LVS module
lsmod |grep ip_vs
#Whether to load or not depends on whether the system calls the lvs module, as long as the kernel integration is ensured
yum install -y ipvsadm
# Install user management tools
ipvsadm --save > /etc/sysconfig/ipvsadm
systemctl start ipvsadm
systemctl enable ipvsadm
#Ensure that the service starts normally, otherwise the configuration cannot be saved permanently

vi /etc/sysctl.conf
#sysctl -p

LVS virtual service configuration

ipvsadm -A -t -s rr
ipvsadm -a -t -r -m
ipvsadm -a -t -r -m
ipvsadm --save
#Save configuration

Real host configuration

 Configure gateway as lvs_dip´╝îRestart the network card

#Install nginx service for testing 	

Verify that the traffic in and out of NAT mode passes through the scheduler

Modifying the port number 8080 of server2 is also supported

Tags: cluster

Posted by meral on Sun, 15 May 2022 12:17:54 +0300