java - EC2 上跨 jgroups channel 丢失数据包的问题

Question

当我们试图通过在 Amazon 的 64 位 linux AMI 上运行的 Jgroups 3.1.0-FINAL 在 EC2(大型实例)上设置 Infinispan 时，我们一直看到不一致的网络故障。一个空的缓存开始时很好，似乎可以工作一段时间，但是一旦缓存已满，同步的新服务器会导致缓存锁定。

我们决定滚动我们自己的缓存，但看到了大致相同的行为。同步期间正在交换 10 兆字节，但它们没有被淹没。在应用程序级别存在来回数据 -> 确认对话，但看起来有些消息从未到达远程。

在查看 UNICAST 跟踪日志记录时，我看到以下内容:

# my application starts a cache refresh operation 
01:02:12.003 [Incoming-1,mprewCache,i-f6a9d986] DEBUG c.m.e.q.c.l.DistributedMapManager - i-f6a9d986: from i-d2e29fa2: search:REFRESH 
01:02:12.003 [Incoming-1,mprewCache,i-f6a9d986] INFO  c.m.e.q.c.l.DistributedMapRequest - starting REFRESH from i-d2e29fa2 for map search, map-size 62373 
01:02:12.003 [Incoming-1,mprewCache,i-f6a9d986] DEBUG c.m.e.q.c.l.DistributedMapManager - i-f6a9d986: to i-d2e29fa2: search:PUT_MANY, 50 keyValues 
# transmits a block of 50 values to the remote but this never seems to get there 
01:02:12.004 [Incoming-1,mprewCache,i-f6a9d986] TRACE o.j.p.UNICAST - i-f6a9d986 --> DATA(i-d2e29fa2: #11, conn_id=10) 
# acks another window 
01:02:12.004 [Incoming-1,mprewCache,i-f6a9d986] TRACE o.j.p.UNICAST - i-f6a9d986 --> ACK(i-d2e29fa2: #4) 
# these XMITs happen for over and over until 01:30:40 
01:02:12.208 [Timer-2,mprewCache,i-f6a9d986] TRACE o.j.p.UNICAST - i-f6a9d986 --> XMIT(i-d2e29fa2: #6) 
01:02:12.209 [Timer-2,mprewCache,i-f6a9d986] TRACE o.j.p.UNICAST - i-f6a9d986 --> XMIT(i-d2e29fa2: #7) 
01:02:12.209 [Timer-2,mprewCache,i-f6a9d986] TRACE o.j.p.UNICAST - i-f6a9d986 --> XMIT(i-d2e29fa2: #8) 
...

这是我们的 Jgroups stack .我们在运行时将 PING 协议(protocol)替换为我们自己的 EC2_PING 版本，该版本使用 AWS 调用来查找其他候选集群成员。这不是连接问题。

知道为什么有些数据包没有到达目的地吗？

Answer 1

Any ideas why some of the packets are not arriving at their destination?

这是一个需要追踪的有趣问题。它似乎对某些 EC2 实例的影响比对其他实例的影响多。问题在于通过 UDP 在 EC2 实例之间发送大数据包。

缓存同步代码向远程服务器发送了一个约 300k 的大消息，该消息被分段(使用 FRAG2)分成 4 个 60k(默认大小)的数据包和 1 个 43k 的数据包，然后发送到远程服务器。由于某些网络限制，远程框仅接收最后(第 5 条)43k 消息。 6 万条消息从未到达。这似乎只发生在某些主机对之间——其他主机对可以通过大数据包大小进行良好通信。它不是普遍的，这就是我花了很长时间才确定诊断问题的原因。

我最初认为这是 UDP 接收器窗口大小问题并尝试调整它 (sysctl -w net.core.rmem_max=10240000) 但这没有帮助。查看 tcpdump 显示 60k 数据包没有到达远程主机。只有 43k 数据包是。

解决方案是将片段大小减小到 16k(32k 可能没问题，但我们比较保守)。当数据包在 Amazon 的虚拟网络中传输时，AWS 对数据包大小有一些内部限制，该虚拟网络正在过滤可能超过 50k 的大型 UDP 数据包。默认的 Jgroups 片段大小 (60k) 是大 IMO，可能应该减少到 32k 左右。

我们就此向亚马逊提交了一张票，他们承认了这个问题，但普遍的 react 是他们很难解决。我们已经调整了片段大小并且正在努力，所以票被关闭了。引用票证:

From: Amazon Web Services

This is an update for case XXXXXXXXX. We are currently limited to packet sizes of 32k and below on Amazon EC2 and can confirm the issues you are facing for larger packet sizes. We are investigating a solution to this limitation. Please let us know if you can keep your packet sizes below this level, or if this is severe problem blocking your ability to operate.

We are actively looking into increasing the packet size along with other platform improvements, and apologize for this inconvenience.

关于 EC2 的一些其他评论。首先，我们已经看到同一可用区中的主机需要大于 8 的 TTL。如果您正在使用多播，请确保您的 TTL 设置为 128 或其他。我们最初认为这是问题所在，但最终不是。

希望这对其他人有帮助。