Lvs-dr (Virtual Server via Direct Routing) principle Description and configuration use case
Lvs-nat (Virtual Server via NAT) principle description and configuration use case
How does the LVS-DR mode work?
The user Requests Load Balancing server (Linuxdirector), when the data packet (data frame) arrives at the load balanced server, the load balancing server chooses a real server according to the dispatch algorithm, rewrites the MAC address of the data frame as the MAC address of the real server, and sends out the The switch sends packets to the real server based on the MAC address, and the real server returns the processed results directly to the client.
Whether or not to be confused. Let's use an experiment to understand it.
Note: You must first turn off the firewall before testing
Note: LVS is responsible for balancing the server and the real server must be in the same network segment (because forwarding is based on the data Link layer), the client is arbitrary.
Real server
Mac 00:0c:29:4e:80:4a 192.168.80.135:8080
Mac 00:0c:29:c6:4e:63 192.168.80.136:8080
Load Balancing Server
Mac 00:0c:29:16:0a:e1 192.168.80.138:8080
Client
Mac 00-50-56-c0-00-08 192.168.80.1
The network topology map is as follows:
@1 Client Access Load Balancing server 192.168.80.138:8080, the packet is as follows.
Original Mac |
Target Mac |
Original IP |
Original port |
Destination IP |
Target Port |
00-50-56-c0-00-08 |
00:0c:29:16:0a:e1 |
192.168.80.1 |
59345 |
192.168.80.138 |
8080 |
@2 is responsible for balancing the server received the packet, according to the scheduling algorithm to select a real server (assuming that the 192.168.80.136 00:0c:29:c6:4e:63), then the target MAC address of the data frame is changed to 192.168.80.136 MAC address 00 : 0c:29:c6:4e:63, the original Mac is modified to its own Mac, and then the packet sent out, the packet is the following.
Original Mac |
Target Mac |
Original IP |
Original port |
Destination IP |
Target Port |
00:0c:29:16:0a:e1 |
00:0c:29:c6:4e:63 |
192.168.80.1 |
59345 |
192.168.80.138 |
8080 |
Note: You can see that LVS only modifies (the original Mac) and (the target Mac), and the destination IP address is not modified, then when the packet is sent by the switch to the server (192.168.80.136), 136 the network card of this server will check whether the destination IP address belongs to its native p address, if it is not the case will refuse to handle this packet, in order to solve this problem, we need to each real server in the loopback network card configuration (192.168.80.138) This IP for their own native IP, This will allow you to process the packet.
@3 according to the forwarding rules of the data link layer, the switch will send the packet to 192.168.80.136 00:0c:29:c6:4e:63 according to the MAC address of the data frame, which can handle the request of the user, and send the packet directly to the client after the processing is finished, the data packet is as follows.
@4 the entire TCP Request packet grab packet, you can see, from 192.168.80.1 to 192.168.80.138 packets are in pairs, this is because LVS received packets after the modified MAC address again to send packets to the real server, So the packets are all in pairs, and each pair of packets has only a different MAC address.
Installing and configuring LVS load Balancing on CentOS
1, in 138 server installation IPVSAMD Yum Install Ipvsadm can refer to http://blog.csdn.net/nimasike/article/details/51932674
2, shut down all the machines of the firewall, test the first shutdown, test through after the open fixed port.
3. Add a list of forwarding rules to the LVS load balancing server.
Add a virtual service and develop a scheduling algorithm --A add- t IP and Port-s scheduling algorithm altogether 8 kinds of
Note: The port must be the same as the back-end server port, because the contract only modifies the MAC address, the target port will not be modified.
ipvsadm-a-T 192.168.80.138:8080-s RR
Add back-end server,-G for Dr Mode
Ipvsadm-a-t 192.168.80.138:8080-r 192.168.80.135:8080-g-W 1
ipvsadm-a-T 192.168.80.138:80 80-r 192.168.80.136:8080-g-W 1
Ipvsadm-s-N Check Configuration
4, because we do not use the VIP, but directly using the load-balanced server real IP, so need to configure the LVS load Server real server MAC address.
Arp-s 192.168.80.135 00:0c:29:4e:80:4a
arp-s 192.168.80.136 00:0c:29:c6:4e:63
Because 138 sends an ARP request asking for a 135 or 136 MAC address, they will not answer ARP because 138 is configured on a return address of 135 and 136.
Conversely, if the VIP is configured with a 135 and a 136 return address, then 138 sends an ARP request, and the real server responds.
Note: The above settings reboot is invalid and you will need to add a configuration file if you want to reboot.
Vim/etc/ethers didn't just add one.
00:0c:29:4e:80:4a 192.168.80.135
00:0c:29:c6:4e:63 192.168.80.136
Then modify/etc/rc.d/rc.local this file, add arp-f this sentence, finally to the file executable permissions chmod +x/etc/rc.d/rc.local
Can arp-e look at MAC address
5, will 192.168.80.138 this IP configuration for the real server return address, and set ARP response suppression.
Start./lvs_real.sh Start
Stop./lvs_real.sh stop
#!/bin/bash
#description: Start realserver
vip=192.168.80.138
/etc/rc.d/init.d/functions case
"$ ' In
start '
echo ' start LVS of Realserver '
/sbin/ifconfig lo:0 $VIP broadcast $VIP netmask 255.255.255.255 up
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;
;
Stop)
/sbin/ifconfig lo:0 down
echo "Close LVS directorserver"
echo "0" >/proc/sys/net/ipv4/conf/lo /arp_ignore
echo "0" >/proc/sys/net/ipv4/conf/lo/arp_announce
echo "0" >/proc/sys/net/ipv4/conf/ All/arp_ignore
echo "0" >/proc/sys/net/ipv4/conf/all/arp_announce
;
*)
echo "Usage: $ {start|stop}"
exit 1
Esac
Arp_ignore parameter is to define the Linux host after receiving the ARP Request packet, send ARP response packet of the condition level, the parameter range is 0~8, the meaning of each value is:
0 (default)-whenever the IP address requested by the ARP request packet belongs to any local address (that is, any native configured IP address), the ARP response packet is responded to, even if the IP address does not belong to the NIC that received the ARP Request packet.
1-The ARP response packet is only responded to if the IP address requested by the ARP Request packet belongs to the IP address of the current network adapter.
2-In addition to meet the 1 of the conditions, but also to meet the ARP Request packet sender IP address also belong to the current network adapter subnet, this will respond to ARP response packets.
4~7--Reserved
8-even if the IP address requested by the ARP request data belongs to any one local address, it does not respond to the ARP response packet.
We set to 1: because we put 192.168.80.138 this IP set the real server for LO Port loopback address, can not let him answer ARP request, otherwise will cause ARP disorder.
Arp_announce By default, it sends out the original IP address of the packet is 138, before the contract it will first through the ARP request to the client's MAC address, in the sending ARP request packet, the IP address will use 138 this address, This will cause other hosts to log the wrong list of MAC addresses, and should actually send ARP requests with 136 IP.
As an example:
If the Linux host has a, B two cards, the corresponding IP address is ip_a, Ip_b, the corresponding MAC address for mac_a, Mac_b, assuming that an application ready to communicate with the external, its socket binding source IP address for ip_a, However, according to the system routing and Related settings, its communication packets will be sent from the B network card, before sending the packet, the system will send ARP Request packets through network card B. If we set the value of Arp_announce to 0, the sender IP address of the ARP Request packet is ip_a and the sender MAC address is mac_b, leaving Ip_a and mac_b corresponding records on the ARP Address table of the network device or the other host. But the actual correct should be ip_a corresponding mac_a, ip_b corresponding mac_b, so this may cause the potential network problem, the specific problem and performance and network topology and network configuration. And if we set the Arp_announce to 2, then when sending ARP request packets, the sender IP address will not be ip_a, but ip_b, so that will not cause the problem mentioned just now. As for the arp_announce=1 situation, I am not very clear, so I can not cite concrete examples.
So we set to 2: So when the ARP request is sent, although the original IP is in the 138 but the actual ARP request is written in the IP is the real server IP.
6, access to the http://192.168.80.138:8080/can be load-balanced access, you can see the packet is distributed to the real server node.
7. The list of forwarding rules added through the IPVSADM command will fail after reboot and we can save it to a configuration file
Ipvsadm-save-n >/etc/sysconfig/ipvsadm Saves the configuration to a file.
We can also make the boot service, let the system turn on the automatic load configuration file. (CentOS7), other versions are similar in principle.
Vim/lib/systemd/system/ipvsadm.service
[Unit]
Description=initialise the Linux Virtual Server
after=syslog.target network.target
[Service]
type= OneShot
execstart=/bin/bash-c "Exec/sbin/ipvsadm-restore </etc/sysconfig/ipvsadm"
#ExecStop =/bin/bash -C "Exec/sbin/ipvsadm-save-n >/etc/sysconfig/ipvsadm"
execstop=/sbin/ipvsadm-c
Remainafterexit=yes
[Install]
Wantedby=multi-user.target
Technical Exchange Group: 212320390
Ifconfig eno16777736:0 192.168.80.138 netmask 255.255.255.255 broadcast 192.168.80.255 up
Reference articles:
LVS-DR Mode Official document: http://www.linuxvirtualserver.org/VS-DRouting.html
ARP protocol: http://blog.chinaunix.net/uid-13423994-id-5146098.html