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


    原文地址: http://blog.csdn.net/lengzijian/article/details/8089661

    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,直接返回客户端请求的信息。

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

  • 相关阅读:
    自动刷新页面
    docker 数据卷管理
    docker container(容器)
    docker images
    docker 设计原理
    hbase数据原理及基本架构
    详谈kafka的深入浅出
    django介绍及路由系统
    mysql爱之深探测
    mysql数据库内容相关操作
  • 原文地址:https://www.cnblogs.com/AloneSword/p/3935897.html
Copyright © 2020-2023  润新知