前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >Docker Swarm 进阶:Overlay 网络长连接问题

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

作者头像
轻量级云原生架构实验室
发布2018-09-27 10:10:36
3.5K0
发布2018-09-27 10:10:36
举报
文章被收录于专栏:轻量级微服务

问题描述

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

代码语言:javascript
复制
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

代码语言:javascript
复制
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,添加如下内容:

代码语言:javascript
复制
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 10

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

参考文档

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2018.08.21 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 问题描述
  • 问题排查
  • 问题解决
  • 参考文档
相关产品与服务
容器镜像服务
容器镜像服务(Tencent Container Registry,TCR)为您提供安全独享、高性能的容器镜像托管分发服务。您可同时在全球多个地域创建独享实例,以实现容器镜像的就近拉取,降低拉取时间,节约带宽成本。TCR 提供细颗粒度的权限管理及访问控制,保障您的数据安全。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档