LVS + keepalived问题

             在做项目的过程中，经常会用到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关闭重启后，流量再次出现了异常。问题暂时还未解决。