我目前正在尝试找出问题的核心,我的 LVS 控制器似乎不时会丢弃来自客户端的数据包。我们的生产系统上存在此问题,并且可以在准备阶段重现此问题。
我在 lvs-users-mailing-list 上发布了这个问题,但至今没有收到回复。
我们的设置:
我们在 PV XEN-DomU 中将 ipvsadm 与 Linux CentOS5 x86_64 结合使用。
当前版本详情:
- 内核:2.6.18-348.1.1.el5xen
- ipvsadm:1.24-13.el5
LVS 设置:
我们在 DR 模式下使用 IPVS,并使用 lvs-kiss 来管理正在运行的连接。
ipvsadm
在 heartbeat-v1-cluster(两个虚拟节点)中运行,主节点和备份节点在两个节点上持续运行。
对于 LVS 服务,我们使用由心跳设置的逻辑 IP(主动/被动集群模式)
真实服务器是物理的 Linux 机器。
网络设置:
充当控制器的虚拟机使用桥接网络在 Dom0 上作为 XEN-PV-DomU 运行。
网络“正在发挥作用”:
- abn-network(staging-network,用于将客户端连接到 director),由 real-server 用来将答案发送给客户端(直接路由方法),用于 ipvsadm slave/master multicast-traffic
- lvs-network:这是连接控制器和真实服务器的专用 VLAN
- DR-arp-problem:解决了我在真实服务器上针对服务 IP 抑制 arp 应答的问题
- 服务 IP 配置为真实服务器上的 lvs 接口上的逻辑 IP。
- 在此设置中,任何地方都不需要 ip_forwarding(无论是在主管上,还是在真实服务器上)。
虚拟机详细信息:
1 GB RAM、2 vCPU、系统负载几乎为 0、可用内存 73M、缓冲区 224M、缓存 536M、无交换。
top
显示几乎总是 100% 空闲,0% us/sy/ni/wa/hi/si/st。
配置详细信息:
ipvsadm -Ln
对于相关服务显示:
TCP x.y.183.217:12405 wrr persistent 7200
-> 192.168.83.234:12405 Route 1000 0 0
-> 192.168.83.235:12405 Route 1000 0 0
xy 前两个八位字节来自我们的内部 B 类范围。我们使用 192.168.83.x 作为 lvs 网络进行暂存。
持久 ipvsadm 配置: ipvsadm 命令:--设置 20 20 20
集群配置: /etc/ha.d/haresources:$primary_directorname lvs-kiss xy183.217
上述服务的 lvs-kiss-configuration-snippet:
<VirtualServer idm-abn:12405>
ServiceType tcp
Scheduler wrr
DynamicScheduler 0
Persistance 7200
QueueSize 2
Fuzz 0.1
<RealServer rs1-lvs:12405>
PacketForwardingMethod gatewaying
Test ping -c 1 -nq -W 1 rs1-lvs >/dev/null
RunOnFailure "/sbin/ipvsadm -d -t idm-abn:12405 -r rs1-lvs"
RunOnRecovery "/sbin/ipvsadm -a -t idm-abn:12405 -r rs1-lvs"
</RealServer>
<RealServer rs2-lvs:12405>
PacketForwardingMethod gatewaying
Test ping -c 1 -nq -W 1 rs2-lvs >/dev/null
RunOnFailure "/sbin/ipvsadm -d -t idm-abn:12405 -r rs2-lvs"
RunOnRecovery "/sbin/ipvsadm -a -t idm-abn:12405 -r rs2-lvs"
</RealServer>
</VirtualServer>
idm-abn、rs1 和 rs2 通过以下方式解析/etc/hosts。
关于服务:
这是一个 soa-web 服务。
我们如何重现错误:
我们从客户端以每三秒一次的间隔不断调用 Web 服务。从主管到客户端的连接有时会被重置。
有趣的是:这在第 nx 100 次 + 1 次尝试中发生 - 有趣的是其中之一。
我们为追查问题所做的事情:
- 已检查/proc/sys/net/ipv4/vs:所有值均设置为默认值,因此 drop_packet 不存在(=0)
- 客户端上的 tcpdump、控制器的前端/abn、目录的后端/lvs、真实服务器的 lvs 和 abn
在此 tcpdump 中,我们可以看到来自客户端的请求,由控制器重置连接来响应。数据包未通过 LVS 转发。
我欢迎任何关于如何进一步追踪此问题的想法。如果任何信息不清楚/缺失以深入探究问题 - 请询问。
答案1
你有什么有状态的 iptablesLVS-DR 控制器上的规则是什么?我可以看到,您使用的是端口 12405,因此,如果您有如下规则:
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 12405 -j ACCEPT
在 LVS-DR 中,真实服务器正在回复来自客户端(而不是控制器)的请求,控制器不会将这些连接添加到连接跟踪表中,并且FIN
控制器的 iptables 不会使用规则检测到数据包ESTABLISHED,RELATED
。由于您只允许NEW
(SYN
)端口 12405 上的数据包,FIN
因此将被阻止。您必须使用无状态防火墙在用于负载平衡服务的 LVS-DR 导向器上:
iptables -A INPUT -m tcp -p tcp --dport 12405 -j ACCEPT