解决OS虚拟机内采用LVS-DR模式请求超时问题

公司大促期间，由于扩容了大量云主机，采用LVS DR模式的Zabbix-Proxy端请求巨增，导致监控数据采集的队列长时间堆积，已经在前端界面无法展示。所以这个时候负责监控的同事从我这里申请了20多台虚拟机用于抗监控流量。

Zabbix-Proxy的集群框架是 Keepalived + lvs ,原本以为只需要给安装Keepavlived的两台虚拟机分配一个Vip就好了 (让虚拟机支持高可用的vrrp协议) ，结果过了一阵监控的同事告诉我vip的端口访问超时，我便开始觉得自己想得太简单。

看下问题现场:

客户端返回内容很简单，连接超时。

LVS端看到问题很明显，客户端请求过来的连接状态全部卡在 SYN_RECV ,说明请求已经到达LVS，但是在丢给后端Real Server的时候处理异常。

那么问题点出在哪儿呢？

最开始怀疑是虚拟机上iptables规则影响DR模式的报文转发，因为DR模式下的LVS在接收到请求后，会将报头拆解，将dst mac改成后端RealServer的MAC地址,然后重新封装好报文通过广播vip地址丢到后端的RealServer处理。

于是我清空所有虚拟机的iptales，并关闭selinux。但问题仍然存在，说明问题不在虚拟机上。

根据LVS DR模式的特性，后端的RealServer上的lo网卡需要绑定vip地址，否则当接受到转发过来 dst ip 为vip的报文时，默认也会丢弃，造成客户端访问超时的问题。

通过和监控的同事沟通，确定排除这块问题，我又想到会不会需要把vip同时也绑定到RealServer上。我再用 allowed_address_pairs 参数更新了后端虚拟机的Port。客户端请求依然超时，说明问题并不是这里。

由于排除了虚拟机问题，我这边将解决问题的重点移至安全组策略。我们知道Neutron通过iptables规则来实现虚拟机进出流量的限制。

于是我将安全组策略全部打开，如下图：

客户端还是超时!!!这个时候我已经感觉无计可施。

转折

过了一会，我觉得应该做最后一搏，于是我将宿主机上iptables全部清空，客户端居然通了！

排查

看来问题点在宿主机上的Iptables，找到这个方向后，我便开始根据VIP对iptables进行反向排查。

Chain neutron-openvswi-o38833ad6-c

上面这一条意思很明确，就是绑定虚拟机IP和MAC地址，只允许MAC地址为 FA:16:3E:C4:20:C7 ,IP地址为 10.1.26.252 和 10.1.26.144 通过，其余DROP掉。 neutron-openvswi-s38833ad6-c 这条Chain是从 neutron-openvswi-o38833ad6-c 跳转下来的。

Chain neutron-openvswi-o38833ad6-c

neutron-openvswi-o38833ad6-c 这条Chain是用于规则虚拟机出口流量，可以看到它是从两条Chian上跳转下来的 neutron-openvswi-INPUT 和 neutron-openvswi-sg-chain 。

neutron-openvswi-o38833ad6-c 主要定义虚拟机engress的安全规则。这里可以看到之前创建的规则已经下发到ipables上应用成功。将没匹配的到规则丢给 neutron-openvswi-sg-fallback ，fallback里面就一条规则，丢弃进来的所有报文。

Chain neutron-openvswi-i38833ad6-c

neutron-openvswi-i38833ad6-c 这条Chain是用于规则虚拟机入口流量，这里看住它只从 neutron-openvswi-sg-chain 上面跳转下来，同时将没匹配的到规则丢给 neutron-openvswi-sg-fallback 。

Chain neutron-openvswi-sg-chain

这里可以看到 neutron-openvswi-sg-chain 处理虚拟机入口和出口流量，同时由 neutron-openvswi-FORWARD 跳转而来。

physdev模块是iptables用于过滤linuxbridge上的网络包，

Chain neutron-openvswi-FORWARD

根据上下文可以确定， neutron-openvswi-FORWARD 是由filter表的 FORWARD 跳转过来。

Chain FORWARD

这里看到报文在转发之前还进入了 neutron-filter-top 链，继续往下。

看到这里我想大部分同学应该明白了，LVS DR模式的虚拟机在转发报文时，默认的FORWARD链里面并没有针对处理报文转发的规则。于是我在 neutron-openvswi-local 加了一条ACCEPT的语句，终于客户端就能正常请求VirtualServer了。

思考

由于LVS的DR模式的特殊性，VirtualServer在收到客户端请求时，并不响应请求，只修改报头重新转发给RealServer。从宏观来看过程并不是VS去请求RS。当请求走到VS所在宿主机上面时，自然会分到FORWARD链上，而这时Netron处理虚拟机iptables时，只做了对虚拟机访问的限制，而当虚拟机需要转发自己数据包时就没有处理规则。从而导致客户端在连接时出现超时的现象。

由于Neutron有基于Haproxy的负载均衡服务，并不鼓励在虚拟机上直接搭建负载均衡器，所以我想在处理这类的问题应该都转到FAAS上面了。总之通过这次排点，对Neutron这块又有了新的认识。

负载均衡！中级运维必知的10个问题

负载均衡 是衡量初中级以上运维技术水平的重要标尺！

负载均衡 是普通运维人员很难有机会接触和系统学习的知识！

一、负载均衡转发数重要吗？

keepalived + lvs 的组合，执行ipvsadm ，输出的数据显示了每个后端服务器连接的数量，一些服务器的值高些，而一些却低一些。一些人纠结：怎么a服务器活跃数是90，而b服务器才55？

负载均衡的均衡是相对的，当访问量很小的时候，这个差异会明显一些。一旦上量，差别就会缩小。比如活跃数都是数千个，一些机器多几十或者少几百，你不会觉得有什么不妥。

负载均衡的主要目标是高可用，只要负载均衡、监控检查、失败切换三个功能正常，并且从用户的角度出发，访问应用（比如网站）一切正常，才是重点，多几个负载量，少几个负载量无关紧要。

二、哪种负载均衡工具更好？

lvs + keepalived、haproxy+nginx、nginx + keepalived几种组合，keepalived倒是一致之选，而其它几个工具，选谁更好呢？

看场景吧，缓存类的应用，如squid适合lvs；其它情形可根据自己的使用习惯来选择。

现在一般的web服务，弃用apache而选nginx居多，如果负载均衡再部署一个nginx，变成keepalived + nginx + nginx 的形式，个人感觉有点别扭，更愿意选择haproxy。

三、vip不漂移怎么办？

很多时候可能是输入的时候不小心，犯了低级的错误。比如keepalived里边，主备两系统的router_id不一致、或者virtual_router_id不一致。

这类错误比较难以排查，在书写的时候，一定要仔细。

另外一个情况可能是，在同一个局域网内，有多个负载均衡集群存在，集群之间的router_id 、virtual_router_id 要注意分别，保持唯一性。

四、完成负载均衡的最佳实践？

经常在网上有人求助，按文档部署的集群不能正常的工作。通过沟通，发现工作方式往往不正确。

那么正确、高效的方式是什么呢（有些人称最佳实践）？请往下看：

五、什么情况下需要负载均衡？

有人说我没那么大的访问量，用负载均衡有点浪费。负载均衡是实现高可用的手段之一，不是以流量大小为出发点的。

如果你的公司或者机构，主要收入来自与网络的话，发生故障造成服务不可访问，造成的损失是否可以忍受，考虑好这个，再做决策。

还有人说，我用了阿里云、腾讯云，弹性计算、高可用，买个高配的云主机，要什么负载均衡！建议多了解一下，这些云服务商有专门的负载均衡，要花钱的，用不着的话，它推这个有啥意义？

六、开源软件不稳定吗？

这是商业解决供应商的说辞，他们的市场做得比较成功，以至于一些技术人员，一旦提及开源解决方案，第一反应就是：开源的稳定么？性能上得去么？

前几天有个系统集成商也只要质疑，我回答他：“你拿一个商业软件，我找一个对应的开源软件比比如何？”

七、公有云上的负载均衡？

大部分公有云不提供havip支持，因此在技术上不太容易实现负载均衡。

从产品设计上考虑，用户自己部署负载均衡，会与云服务商推出的服务产生冲突。

从其不断推出的产品线来看，恨不得把所有的服务都囊括进去，让用户从此依赖服务商，财源滚滚。

八、如何快速排查负载均衡故障？

步骤如下：

A.确定问题是部分还是全部？是网络问题还是系统问题？

B.检查后端服务是否正常。因为后端才是真实提供服务的场所，是整个负载均衡存在的根基（就算负载均衡体系暂时崩溃了，只要后端服务正常，可临时采取措施，把用户请求直接暴露给用户，可最快速度恢复业务）。在实际的工作中，大部分的故障集中在后端服务器，比如大名鼎鼎的502。

C.排查负载均衡是否正常。一般情况下，负载均衡服务器基本不安装其它服务（一机多用者慎重），因此，除了硬盘被日志塞满产生故障外，另外一个可能就是硬件损坏。本人管理的系统，运行时间最长的负载均衡服务器，有超过八年没趴窝的。

九、有负载均衡就完事无忧了么？

部署了负载均衡，后端服务器可以部分失效、负载均衡器本身也可以有一个失效。看起来很让人放心，就算发生故障，也暂时能顶一阵。是不是慢吞吞地地心情好了，想起来了再去做故障恢复？

最好不要这样干，有故障发生，发现以后，尽可能快的把故障修复并再次加入集群，不玩心跳。

十、负载均衡能承载多大的并发？

这与后端服务关系密切，后端程序、逻辑性能极佳，承载的并发数就大；反之就小，无确切的数据支撑。

上线前，有可能对系统做压力测试，但这种测试大部分是一致性测试（至少是同一个访问源），与真实的用户访问还是存在很大差异。

真实的用户访问，来源不同，访问的对象不同，比如有的用户网络环境差，访问速度慢，完成一次连接的时间长，占有资源的释放时间就要久一些。这种测试可做大概的参考，评估时应该预留余量。

---