LVS + keepalived问题

服务器 专栏收录该内容
27 篇文章 1 订阅

             在做项目的过程中,经常会用到nginx或者LVS来做负载均衡,用keepalived来做高可用方案。

            一般情况下,LVS+keepalived的架构是这样的:

        LVS和keepalived部署两台作为入口,将请求转发到其他三台realServer服务器上。但是有时候服务器没有那么多,我们会将LVS和realServer部署在同一台服务器上。

      按照这种结构部署后,基本功能都可以实现。 从浏览器访问VIP(虚拟ip)的时候,会访问到三台realServer中的随机一台。关闭掉director的master那一台的keepalived后,转发功能也正常运行,VIP也从关闭的那一台director转移到了另一台realServer了。再次启动master,VIP又转移到master上来了,转发功能还是正常的。

       此时,一切看起来都很正常。

      但是,当使用apache bench工具测试性能的时候,发现这种架构的转发性能非常低。后来监控流量的时候发现,两台director之间的流量非常之高,甚至在客户端停止发送请求之后,流量都没有降下来,因此是两台director之间在互相发送数据包,陷入了死循环,流程图如下:

       

 

原因分析:当客户端发送数据包给 VIP 。比如我们的 Director1 (Master 主)这个接口正在工作,这时 LVS 能接收到这个包,然后根据 keepalived 的配置进行 load balance 。这时 Director1 会使用 LVS-DR 的功能给包路由给自己、第二台realServer或者 Director2 (Backup)。

这时有个问题,在这个例子中因为我们使用了 keepalived 。这时 Director2 这台是一台 VIP 的备份服务器。这时 keepalived 默认会立即启动使用 ipvsadm 的规则来配置这台服务器怎么样做备份的处理.来使得更快的故障转移。所以这时这些规则这台备份的 Director2 主机都会存在。

这就有问题了。当从 Director1 (Master 主),比如使用 rr 。会转发大约 33% 的包从 Director1 到  Director2 (Backup)。这时因为 Director2 因为这些 LVS-DR 的配置规则会接着给这些包,再做一次 load balance 。又发回去给 Director1,这时会产生一个死的循环。

随着时间的推移,不但不能正常的处理连接,您的服务器也会崩溃,在他们中间或后端不断的反复连接。

 

网上的解决方案:

                      给进入 eth0 的包打包 mark 的标记,当数据包是发给 VIP:80  并且 MAC 不是另一个 LVS 服务器的话. 才做个 mark ,这样才会对指定的 fwmark 进行 loadbalance 放入到 LVS 中处理。只要数据包是另一台LVS转发过来的(通过MAC识别), 会不进行 loadbalanced, 而是直接转给后面监听的  demon 程序进行应用的处理。实际就是我们使用 iptables 来对进入的流量设置 MARK.然后配置 keepalived 只处理有 MARK 过的流量。不在使用以前绑定 VIP 和端口。

iptables 的配置如下:

同时服务于 LVS-DR,又要做为数据库的后端。所以我们要注意,只接收一个 director 的数据包。

这时我们在 Director1 中设置($MAC_Director2 是指我在  Director1 上所能见到从  Director2 发过来包的 MAC 地址) :

iptables -t mangle -I PREROUTING -d $VIP -p tcp -m tcp --dport $VPORT -m mac  ! --mac-source $MAC_Director2 -j MARK --set-mark 0x3

并在备份的 keepalived 的服务器 Director2 中设置:

iptables -t mangle -I PREROUTING -d $VIP -p tcp -m tcp --dport $VPORT -m mac  ! --mac-source $MAC_Director1 -j MARK --set-mark 0x4

 接着在 keepalived 中分别配置这二个。

Director1: virtual_server fwmark 3 {
Director2: virtual_server fwmark 4 {

大概的架构如下:

 

在这种配置之下,再次用ab工具测试。

第一次,先启动keepalived的master,再启动keepalived的slave。 转发正常,流量正常。

第二次,在上面的基础上,关闭master。转发正常,流量正常。

第三次,在上面的基础上,再次启动master。转发异常,流量激增。

 

所以,使用上述的方法,在第一次启动的时候是正常的。但当master关闭重启后,流量再次出现了异常。问题暂时还未解决。

  • 0
    点赞
  • 0
    评论
  • 3
    收藏
  • 打赏
    打赏
  • 扫一扫,分享海报

©️2021 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页

打赏作者

嫩草终结者

你的鼓励将是我创作的最大动力

¥2 ¥4 ¥6 ¥10 ¥20
输入1-500的整数
余额支付 (余额:-- )
扫码支付
扫码支付:¥2
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值