为什么LVS要丢弃数据包？

Question

我目前正试图深入到一个问题的核心，在这个问题上，我的LVS总监似乎不时从客户端掉下一个包。我们在我们的生产系统上有这个问题，并且可以在分期时重现这个问题。

我在lvs-用户邮件列表上发布了这个问题，但到目前为止没有得到任何回应。

我们的设置：

我们在中与Linux CentOS5 x86_64一起使用ipvsadm。

当前版本详细信息：

• 内核: 2.6.18-348.1.1.el5xen
• ipvsadm: 1.24-13.el5

LVS-设置：

我们在DR模式下使用IPVS，用于管理运行中的连接，我们使用lvs。

ipvsadm在心跳-v1-集群(两个虚拟节点)中运行，主节点和备份在两个节点上不断运行。

对于LVS-服务，我们使用按心跳设置的逻辑IP(主动/被动集群模式)。

真正的服务器是物理的Linux机器。

Network-Setup:

作为指导的VM正在使用桥接网络在Dom0上以的身份运行。

网络“游戏”：

• abn-网络(分期-网络，用于将客户端连接到导演)，由实际服务器用来向客户端发送答案(直接路由方法)，用于ipvsadm从/主多播通信。
• lvs-网络:这是一个专用的VLAN，连接导演和实际服务器。
• DR-arp问题:解决了我的抑制arp-在服务的真实服务器上的答案-ip。
• 在实际服务器上的lvs-接口上，服务- IP被配置为逻辑IP。
• 在这个设置中，ip_forwarding在任何地方都不需要(不管是在主管上还是在真正的服务器上)。

VM详细信息：

1GB RAM，2个vCPU，系统负载几乎为0，内存73 m空闲，224 m缓冲区，536 M缓存，无交换。

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

x.y前两个八位数来自我们内部的B级范围。我们使用192.168.83.x作为lvs-网络进行分期。

持久性ipvsadm-配置: /etc/sysconfig/ipvsadm：-set 20 20 20

集群-配置: /etc/ha.d/haresources：$primary_directorname lvs-kiss x.y.183.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，rs1和rs2通过/etc/主机解析。

关于服务的

：

这是一个soa网络服务。

我们如何重现错误：

从客户端，我们在三秒钟内以一次调用的间隔运行对web服务的持续调用。有时会有一个连接重置从董事到客户端。

有趣:这发生在nx100th+1尝试上--有趣就是其中之一。

我们做了什么来追踪这个问题：

• 选中/proc/sys/net/ipv4 4/vs:所有值都设置为默认值，因此drop_packet不到位(=0)
• 客户端tcpdump，目录的前端/ abn，目录的后端/ lvs，真正服务器的lvs和abn。

在这个tcpdump中，我们可以看到客户端的请求，由主管重新设置连接。数据包不是通过LVS转发的。

我欢迎任何关于如何进一步追踪这个问题的想法。如果有任何信息不清楚/遗漏，请查究问题-请问。

Answer 1

你对LVS的导演有什么有状态的规定吗？正如我所看到的，您使用的是端口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中，真正的服务器正在响应来自客户端(而不是导演)的请求，导演不会在连接跟踪表中添加这些连接，并且在导演的iptable上不会用规则FIN ESTABLISHED,RELATED检测到这些连接。由于您只允许端口12405上的NEW (SYN)数据包，FIN将被阻塞。对于负载平衡服务，您必须在LVS主管上使用无状态防火墙：

iptables -A INPUT -m tcp -p tcp --dport 12405 -j ACCEPT