Docker Swarm 进阶：Overlay 网络长连接问题

问题描述

如图所示，在 Swarm 集群中部署了 ServiceA 和 ServiceB 这两个服务，服务间通过 grpc 建立长连接实现服务间调用。然而 ServiceA 在调用 ServiceB 时，偶尔会出现如下错误：

java.io.IOException: Connection reset by peer
    at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
    at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
    at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
    at sun.nio.ch.IOUtil.read(IOUtil.java:192)
    at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380)
    at io.netty.buffer.PooledUnsafeDirectByteBuf.setBytes(PooledUnsafeDirectByteBuf.java:288)
    at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1100)
    at io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:367)
    at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:118)
    at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:642)
    at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:565)
    at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:479)
    at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:441)
    at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:858)
    at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
    at java.lang.Thread.run(Thread.java:745)

在我们查看容器日志时，这个错误出现次数不是很频繁，但是一定会出现，由于这个错误会导致业务系统异常，所以我们花了点时间去处理它。

问题排查

1、 grpc 中间件的问题？
并发测试：50 个线程，10万次请求，重复了 3 次，均能正常响应。因此，排除这种可能性。

2、测试环境网络波动导致的？
持续请求测试：多线程持续请求 4 小时，均能正常响应。然而另外一套测试环境，测试妹子人工测试的时候还是出现这个问题。因此，排除这种可能性。

3、搜索 Connection reset by peer 相关信息
网上很多文章都说明了这个异常可能出现的原因，经过各种 DEBUG，发现这个异常发生时，ServiceA 没有将数据发送到 ServiceB。结合上述 1 和 2 两步的测试，长连接一直维持时无异常；人工测试时，中途会停止请求，时间过长，长连接会断开，ServiceA 无法将数据发送给 ServiceB，就能解释通了。

4、分析 Docker Swarm 中的网络模型

Docker Swarm 中使用 IPVS 将 ServiceA 的请求路由到 ServiceB 的一个实例，ServiceA 与 ServiceB 长连接的建立会经过 IPVS。此处 IPVS 的规则是：当 TCP 会话空闲超过15分钟（900秒）时，IPVS 连接超时并从连接表中清除，即图中 IPVS 与 ServiceB 之间的连接。

下面是两种不同的 timeout ，一种是 IPVS 的，另一种是 TCP 的：

默认 IPVS timeout 值:

• ipvsadm -l --timeout
• Timeout (tcp tcpfin udp): **900** 120 300

默认 TCP timeout 值:

• tcp_keepalive_time = **7200** (秒，连接时长)
• tcp_keepalive_intvl = 75 (秒，探测时间间隔)
• tcp_keepalive_probes = 9 (次，探测频率)

当 IPVS 超时, 它将从连接表中清除。而 IPVS 超时后，时间在 7200s 之内，ServiceA 还是会认为长连接处于连接状态，实则不然，继续调用 ServiceB 则会出现问题。

5、精准复现问题
ServiceA 调用 ServiceB，正常响应，等待 15 分钟以上，ServiceA 继续调用 ServiceB，一定出现 Connection reset by peer 的异常。

问题解决

方式一：ServiceA 在代码层面实现连接重试逻辑

方式二：系统层面设置 TCP 的 timeout

设置 tcp_keepalive_time 小于 900s ，建议 600 ~ 800

sysctl -w net.ipv4.tcp_keepalive_time=600
sysctl -w net.ipv4.tcp_keepalive_intvl=30
sysctl -w net.ipv4.tcp_keepalive_probes=10

或者编辑文件 /etc/sysctl.conf，添加如下内容：

net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 10

为了使配置生效，必须重启 Swarm 中的服务。建议同时应用上述的两种方法。

参考文档

• https://github.com/moby/moby/issues/31208
• https://success.docker.com/article/ipvs-connection-timeout-issue