lvs-dr模式原理详解和可能存在的“假负载均衡”

lvs-dr模式原理

转载注明出处：http://blog.csdn.net/lengzijian/article/details/8089661

先附上一张原理图：

为了更清晰的表述lvs-dr原理，我们用tcpdump工具打印出tcp数据，查看mac地址的更改情况，绘制出如下的时序图；

图1表示201收到转发消息，图2表示200收到转发请求(下面两张为错误的图，错误的理由下面会详细解释)

上面的信息全部用tcpdump命令取得(tcpdump -e -X-A -n -s 10000 port 80;具体含义这里就不详细讲解了)，用上述命令分别在149、200、201上执行。

图只是辅助理解，刚开始不用研究太深入。可以根据下面的讲解慢慢体会。

首先，从两幅图中我们都能看到这样的流程：

TCP建立(三次握手)->交换机发送请求->服务器响应请求->TCP连接断开(四次挥手)

下面解答和分享下我所遇到的问题：

问题1:按照我之前对负载均衡的理解，应该是149收到交换机发来的消息，然后转发给201或者200，为什么是201先收到交换机发来的数据，然后转发到149呢？

这个问题也困扰了我好久，后来我把201网线断掉之后，重新尝试，发现149和200都没有收到交换机发过来的消息，心想应该是被交换机缓存了(猜测)。之后把服务全停掉，重新设置lvs配置，然后重启。之后看到的tcp流，就和预想中的一样。

当200接收到消息时，只有149和200会收到tcp流信息。同理201；

有人会说我这是多此一举，花了这么久的图，最后还是错的。其实不是这样。起码以后我知道如何查看tcp是否正常，表面上看lvs转发消息时正常的，其实tcp流多走了几步。表面上是负载均衡,其实一台realserver负载非常高。。。。这里可能会导致很多问题。

有人想要正常的tcp流图，这里本人不想再多画了，如果有时间再补上吧。可以按照上面的图，把交换机接受的数据移植到149上，就是正常的图啦。

下面补上正确的lvs-er模式的tcp流图，201收到消息时同理：

有了正确的图理解原理更加方便了。

问题2：vs-dr如何转发消息的？

由上图3中第二步骤可以看出，director接受到交换机的请求，然后根据算法选取一台realserver，并且把包转发过去，realserver接收到包后，直接把结果返回给交换机，而没有走director。

具体步骤：

1.接收到源mac地址为38:22:d6:6c:07:5d，目的地址为00:1A:4D:8C:FA:D5。源ip为192.168.0.237、目的ip为192.168.30.149

2.vs根据负载均衡，把源mac地址改为00:1A:4D:8C:FA:D5，目的地址改为00:26:18:45:D7:88。源ip和目的ip都不变

3.realserver(00:26:18:45:D7:88)接收到请求,做出响应。源ip改为192.168.30.149，目的ip改为192.168.0.237

4.realserver的消息源mac为00:26:18:45:D7:88，目的mac地址为38:22:d6:6c:07:5d。所以跳过了149，直接返回客户端请求的信息。

今天画图画累了，明天有空再讲下具体配置问题。。。