Linux system (5) DR mode of LVS cluster, lvsdr

Linux system (5) DR mode of LVS cluster, lvsdr
Preface

The DR mode is one of the three load balancing modes in the lvs cluster. in the previous article, I wrote about the establishment and Principles of the NAT mode. Why do we need the DR mode and IP tunneling mode?

First, let's look at three figures. LVS/NAT mode:

LVS/IP tunneling mode, such:

LVS/DR mode, such.

The above three figures from: http://www.linuxvirtualserver.org/zh/lvs3.html, this article is also officially detailed description of the LVS Cluster implementation of the three IP Load Balancing Technology (VS/NAT, VS/TUN and VS/DR) and their advantages and disadvantages. We recommend that you take a closer look.

Here I will briefly summarize their routing methods and make a difference:

VS/NAT mode: client> request Distribution Server> Real Server> request Distribution Server> client.

VS/DR mode: client> request distributor> Real Server> client.

VS/TUN mode: client> request distributor> Real Server> client.

It can be seen that the request distribution server in NAT mode is the bottleneck of this mode, because all requests and responses must be forwarded by another server. The difference between the IP tunneling mode and the DR mode is that, compared with the IP tunneling mode, the DR mode has no overhead of IP encapsulation, but because of the physical layer (modify MAC address) technology, all servers must be in the same physical network segment.

Detailed LVS/DR mode setup drills

First, I first set up the overall machine architecture Diagram for a more intuitive setup and understanding.

 

First, configure the distributor for this machine. The operation is very simple. Just do it.

• Add eth0: 1 Network Interface

[Root @ localhost network-scripts] # ifconfig eth0: 1 172.18.8.6 netmask quota limit 255 -- this interface only takes effect temporarily, the following configuration is permanently effective [root @ localhost network-scripts] # cd/etc/sysconfig/network-scripts/[root @ localhost network-scripts] # cp ifcfg-eth0: 1

• Edit the copied ifcfg-eth0: 1, note that the mac address must be consistent with eth0.

[root@localhost network-scripts]# cat ifcfg-eth0:1TYPE="Ethernet"BOOTPROTO="static"DEFROUTE="yes"PEERDNS="yes"PEERROUTES="yes"IPV4_FAILURE_FATAL="no"NAME="eth0:1"DEVICE="eth0:1"ONBOOT="yes"IPADDR="172.18.8.6"NETMASK="225.225.225.0"HWADDR="00:0c:29:af:ff:3a"    

• Configure the ipvsadm load algorithm. If you do not know what the ipvsadm is, read my blog: Linux System (4) LVS Cluster load balancing NAT mode.

[root@localhost network-scripts]# ipvsadm -A -t 172.18.8.6:80 -s rr  [root@localhost network-scripts]# ipvsadm -a -t 172.18.8.6:80 -r 172.18.8.5 -g    [root@localhost network-scripts]# ipvsadm -a -t 172.18.8.6:80 -r 172.18.8.4 -g

At this point, the distributor is configured.

Then configure the Real Server

• Configure a temporary loopback interface

[root@localhost ~]# ifconfig lo:1 172.18.8.6 netmask 255.255.255.255[root@localhost ~]# cd /etc/sysconfig/network-scripts/[root@localhost network-scripts]# cp ifcfg-lo ifcfg-lo:1

• Configure the copy-back interface configuration file ifcfg-lo: 1, and then shut down and restart it to make it take effect permanently.

[root@localhost network-scripts]# cat ifcfg-lo:1CE=lo:1IPADDR=272.18.8.6NETMASK=255.255.255.255# 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)ONBOOT=yesNAME=loopback

• In this way, we can see that all three IP addresses are 172.18.8.6. When you enter 172.18.8.6: 80 on the client to access the web server, what will the server respond? The following two configurations are required so that requests accessing the ip address 172.18.8.6 are only processed on the machine of the distributor. These two configurations will be explained later.

[root@localhost network-scripts]# echo "1">"/proc/sys/net/ipv4/conf/eno16777736/arp_ignore"[root@localhost network-scripts]# echo "2">"/proc/sys/net/ipv4/conf/eno16777736/arp_announce"[root@localhost network-scripts]# cat /etc/sysctl.conf# System default settings live in /usr/lib/sysctl.d/00-system.conf.# To override those settings, enter new settings here, or in an /etc/sysctl.d/<name>.conf file## For more information, see sysctl.conf(5) and sysctl.d(5).net.ipv4.conf.eno16777736.arp_ignore=1net.ipv4.conf.eno16777736.arp_announce=2

• Enable the web server. Here I use nginx as a web server.

[root@localhost network-scripts]# /usr/sbin/nginx

• Another Real Server can perform the preceding operations.
• Test: do not initiate a request to 172.18.8.6 in minutes. This is not feasible. If you want to test on another machine, the test result on the 150 machine is as follows.

Directly connect to the realserver. No problem, as shown below.

Access the distributor ip address to achieve round-robin, as shown below.

Understanding the parameters of arp_ignore and arp_announce

Arp response restriction arp_ignore:

• 0-(default): responds to arp query requests from any network interface to any local IP address.
• 1-only answers ARP query requests whose target IP address is the local address of the Access Network Interface
• 2-only answers ARP query requests whose target IP address is the local address of the access network interface. The access IP address must be in the subnet segment of the network interface.
• 3-do not return arp requests in the network, but only respond to the set unique and connection address
• 4-7-reserved unused
• 8-does not respond to arp queries for all (local addresses)

Arp response restriction arp_announce: The ARP response to the local IP address on the network interface, and the corresponding level of restriction: determine the different degree of restriction, announcing an interface for sending Arp requests to local IP addresses

• 0-(default) any local address on any network interface (eth0, eth1, lo)
• 1-avoid arp responses from local addresses that are not in the subnet segment of the network interface. it is useful when the source IP address that initiates an ARP request is set to reach this network interface through a route. check whether the access IP address is one of the ip addresses in the subnet segment of all interfaces. if the access IP address does not belong to the subnet segment of each network interface, level 2 is used for processing.
• 2-use the most appropriate local address for the query target. in this mode, the source address of the IP packet is ignored and the local address that can communicate with the IP packet is selected. first, select the local address of the destination IP address in the out-of-the-box access subnet of all network interfaces. if no suitable address is found, the current sending network interface or other network interfaces that may receive the ARP response will be selected for sending.

In dr mode, our realserver configures the arp_ignore to 1: whether the request is from the ip address of eno16777736. I do not reply to the request. Arp_announce is 2: it means that I will not publish any ip addresses other than the ip address where eno16777736 is located to the public, so as to avoid actively declaring the ip address so that the arp broadcast packet can be sent and responded.

Summary

The following is your favorite summary. The content is as follows:

1. I hope to keep an eye on my other articles.

2. Are there any clear instructions in the blog, or you have a better way? Join the two chat groups in the upper left corner to study and discuss them together.