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

作者: Anoyi

2018.08.21 17:54

问题描述

如图所示,在 Swarm 集群中部署了 ServiceAServiceB 这两个服务,服务间通过 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 的一个实例,ServiceAServiceB 长连接的建立会经过 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 中的服务。建议同时应用上述的两种方法。

参考文档

评论

评论

昵称
邮箱