LVS-DR model principle and possible "pseudo-load equilibrium"

LVS-DR Mode principle

Reprinted annotated Source: http://blog.csdn.net/lengzijian/article/details/8089661

Attach a schematic diagram first:

In order to express the LVS-DR principle more clearly, we use the Tcpdump tool to print the TCP data, view the MAC address change, and draw the following sequence diagram;

Figure 1 indicates that 201 receives a forwarding message, Figure 2 indicates that 200 receives a forwarding request (the following two is the wrong figure, and the reason for the error is explained in detail below).

The information above is obtained by Tcpdump command (TCPDUMP-E-x-a-n-s 10000 port 80; The specific meaning is not explained in detail here), the above order is executed on 149, 200, 201 respectively.

The picture is just a supplementary understanding, and it is not studied too deeply at first. Can be understood according to the following explanation slowly.

First of all, we can see this process from two images:

TCP Establishment (three times handshake)-> switch Send request-> server response Request->tcp Disconnect (four waves)

To answer and share the following questions I have encountered:

Question 1: According to my previous understanding of load balancing, it should be 149 to receive the message from the switch, and then forward to 201 or 200, why 201 first receive the data from the switch, and then forward to 149.

This problem has been bothering me for a long time, and then after I cut off the 201 network cable, try again, found that 149 and 200 did not receive the message from the switch, I thought it should be the switch cache (guess). After the service is all stopped, reset the LVS configuration, and then reboot. The TCP stream that you see later is the same as expected.

When 200 receives a message, only 149 and 200 receive the TCP stream information. likewise 201;

Some would say I was superfluous, spent so long in the picture, and finally wrong. Not really. At least later I know how to see if TCP is normal, on the surface of the LVS forwarding message is normal, in fact, the TCP flow more than a few steps. On the surface is load balanced, in fact a realserver load is very high .... This can cause a lot of problems.

Some people want the normal TCP flow diagram, here I do not want to draw more, if there is time to fill it. You can follow the diagram above to transplant the data received by the switch to 149, which is the normal diagram.

The following is the correct TCP flow diagram for the lvs-er mode, 201 the same as when the message is received:

It is more convenient to have the correct diagram understanding principle.

Question 2:vs-dr How to forward a message.

As can be seen from the second step in Figure 3 above, director accept the request to the switch, then select a realserver based on the algorithm, and forward the packet to the past, Realserver receive the package, directly return the result to the switch, and did not walk director.

Specific steps:

1. Receive the source MAC address is 38:22:d6:6c:07:5d, the destination address is 00:1a:4d:8c:fa:d5. Source IP is 192.168.0.237, destination IP is 192.168.30.149

2. VS according to load balance, the source MAC address is changed to 00:1A:4D:8C:FA:D5 and the destination address is changed to 00:26:18:45:d7:88. Both source and destination IP are unchanged

3. Realserver (00:26:18:45:d7:88) receives the request and responds. Source IP changed to 192.168.30.149, Destination IP to 192.168.0.237

4. Realserver's message source Mac is 00:26:18:45:d7:88, the destination MAC address is 38:22:d6:6c:07:5d. So skip 149 and directly return the information requested by the client.

The drawing is tired today, tomorrow is free to talk about the specific configuration problem ...