Working principle of LVS-DR

For convenience, I made another diagram based on the official schematic diagram, as shown in: VS/DR architecture:

I will explain the principle of LVS-DR based on this schematic diagram and specific examples, including the data packet, data frame direction and conversion process.

Official principles: ctor receives user requests, selects a RealServer Based on the server Load balancer algorithm, forwards packets, and then the RealServer directly replies to the user.

Instance scenario device list:

Note: For convenience, the client is a machine with the same network segment as the VIP. If it is accessed by an external user, replace the client with the gateway, because the IP address header is unchanged and the source MAC address is changed.

① The client sends a request to the target VIP and the Director receives the request. The IP header and data frame header information are as follows:

② Vs selects an active RealServer (Suppose 192.168.57.122) based on the load balancing algorithm, takes the MAC address of the NIC where the RIP is located as the target MAC address, and sends it to the LAN. The IP header and data frame header information are as follows:

③ The RealServer (192.168.57.122) receives the frame in the LAN and finds that the destination IP address (VIP) matches the local IP address. Then, the packets are re-encapsulated and sent to the LAN. The IP header and data frame header information are as follows:

④ If the client and vs are in the same network segment, the client (192.168.57.135) will receive this reply message. If the network segment is exceeded, the packets are returned to the user through the gateway/router over the Internet.

 

FAQs about how the LVS/DR mode works.

1. How does LVS/DR process request packets and modify the IP packet content?

1.1 VS/DR itself does not care about the information above the IP layer, even if the port number is also the TCP/IP protocol stack to determine whether the correct, VS/DR itself mainly do the following:

1) receive client requests and select the IP address of a RealServer Based on the server Load balancer algorithm you set;

2) use the MAC address corresponding to the selected IP address as the target MAC address, and then encapsulate the IP package into a frame and forward it to the RS;

3) record the connection information in the hash table.

VS/DR does very few things and is also very simple, so it is very efficient, not much worse than the Hardware load balancing device.

The general flow of data packets and data frames is as follows: client --> vs --> Rs --> Client

1.2 The answer was answered earlier. VS/DR will not modify the content of the IP package.

2. Why does RealServer configure VIP on the lo interface? Can I configure the VIP address on the egress Nic?

2.1 To enable rs to process IP packets whose destination address is VIP, RS must first receive the packet.

Configure the VIP address on lo to receive the packet and return the result to the client.

2.2 The answer is that the VIP cannot be set on the egress Nic. Otherwise, the client's ARP request will be responded, resulting in disorder of the client/gateway ARP table, and the entire load balance will not work properly.

3. Why does RealServer suppress ARP frames?

This issue has been explained in the previous issue. Here we will further discuss it with the Implementation command. We will make the following adjustments during implementation and deployment:

       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

I believe that many people will not understand what their role is, but they must know that they must. I am not going to discuss it in detail here. I just want to make a few notes to add.

3.1

echo "1" >/proc/sys/net/ipv4/conf/lo/arp_ignoreecho "2" >/proc/sys/net/ipv4/conf/lo/arp_announce

You can skip these two steps because ARP has no significance for logical interfaces.

3.2 If your Rs's external network interface is eth0

echo "1" >/proc/sys/net/ipv4/conf/all/arp_ignoreecho "2" >/proc/sys/net/ipv4/conf/all/arp_announce

What is actually to be executed is:

echo "1" >/proc/sys/net/ipv4/conf/eth0/arp_ignoreecho "2" >/proc/sys/net/ipv4/conf/eth0/arp_announce

Therefore, I personally suggest adding the above two to your script, because in case the default values of the above two are not 0, there may be problems.

Arp_ignore:

Define ARP queries with the target IP address as the local IP address in different response modes 0

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)

Determines the IP address that sends the ARP request to the outside even if the VIP address

Arp_announce-integer

When an ARP response is sent from a local IP address on a network interface, the following restrictions are imposed:

Determine the limits to different degrees, and announce the 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.

Limits the use of the local VIP address as the preferred Network Interface

 

4. Why are LVS/DR Load balancer (director) and RS in the same network segment?

From the first question, we should understand how VS/DR forwards requests to Rs? It is implemented at the data link layer, so director must be in the same network segment as Rs.

5. Why does the eth0 interface have an IP address (DIP) in addition to the VIP address on ctor )?

5.1 if keepalived or other tools are used for HA or load balance, dip is required for health check.

5.2 ha or load balance without health check mechanism has no practical significance.

6. Do I need to enable LVS/DR ip_forward?

No. Because Director and RealServer are in the same network segment, you do not need to enable forwarding.

7. Must the Director VIP netmask be 255.255.255.255?

In LVS/DR, the Director VIP netmask does not need to be set to 255.255.255.255, and does not need to be set again.

route add -host $VIP dev eth0:0

Director's VIP is intended to be advertised as a normal IP address. Do not make such a special announcement.

 

From: http://www.cnblogs.com/czh-liyu/archive/2011/11/29/2267963.html