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;具体含义这里就不详细讲解了),用上述命令分别在149200201上执行。

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

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

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

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

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

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

200接收到消息时,只有149200会收到tcp流信息。同理201

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

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

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

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

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

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

具体步骤:

1.    接收到源mac地址为38:22:d6:6c:07:5d,目的地址为00:1A:4D:8C:FA:D5。源ip192.168.0.237、目的ip192.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的消息源mac00:26:18:45:D7:88,目的mac地址为38:22:d6:6c:07:5d。所以跳过了149,直接返回客户端请求的信息。

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

 

 

 

阅读更多

没有更多推荐了,返回首页