如何跨过 Docker 集群网络 Weave 遇到的“坑”?

阅读数:24 2019 年 11 月 13 日 17:32

如何跨过Docker集群网络Weave遇到的“坑”?

Weave 作为 Docker(一个开源的应用容器引擎)跨主机集群网络解决方案的一种,可以用于连接部署在多台主机上的 Docker 容器,使用网络的应用程序不必去配置端口映射、链接等信息。另外,Weave 的通信支持加密,用户可以从一个不受信任的网络连接到主机。

Weave 在控制层和 Calico 类似,在数据层通过 UDP 封装实现 L2 overlay。Weave 在 1.2 版本之前都是通过 usersapce 实现,在 Weave-1.2 版本之后,Weave 结合了内核 Open vSwitch 模块,实现了 Open vSwitch datapath(ODP)功能,结合 kernel 的 vxlan 特性,在网络性能上有较大提升。

由于 ODP 功能与内核相关模块结合较为紧密,因此在实际使用中可能会遇到一些与内核相关的“坑”。本文描述的这两个问题都跟内核有关系。

坑一:使用 Weave FastDb 造成网络中断

1 问题描述

在 Weave 的 1.2 版本之后,考虑到原先 sleeve 模式网络性能较差,故增加 FastDb 模式,该模式也成为 Weave 启动时的默认模式。在 FastDb 模式中使用了 kernel 中的 Open vSwitch 模块,做报文封装时使用 vxlan 协议。在使用 qemu-kvm 创建的云主机上,如果安装 CentOS7.0,内核版本为 kernel-3.10.123,那么在启动 Weave 并使用 FastDb 模式时,会造成 virtio_net 虚拟网卡无法发送数据,进而导致整个虚拟机的网络中断。

2 问题分析

导致网络断开的原因是由于触发了内核的一个 bug,该内核 bug 的 commit 链接地址:

http://t.cn/Ro53BsH。

触发该 bug 主要是因为 Weave 在初始化时会发送一个 60000 字节的 UDP 数据包进行 PMTU 探测,并且 Weave 发送使用的套接字为 raw socket,导致 virtio_net 使用的内存被污染,具体表现就是无法通知到宿主机上 vhost 获取数据,在接口上看到发送报文的计数始终不会增加。

该问题不是只有 Weave 才能触发,用普通应用程序建立 socket 时使用 raw socket, 并且发送的数据大于接口的 MTU 值,接口的 UFO 功能是打开的,这些情况下都极有可能触发该问题,造成网络中断。

如何跨过Docker集群网络Weave遇到的“坑”?如何跨过Docker集群网络Weave遇到的“坑”?如何跨过Docker集群网络Weave遇到的“坑”?如何跨过Docker集群网络Weave遇到的“坑”?

(图 1:FastDb 模式的数据流原理)

3 解决方法

1、升级内核,保证内核版本大于等于 3.13;
2、关闭虚拟机网卡的 ufo 特性;
3、CentOS7.1 的 kernel-3.10.229 内核已经修复了该问题。

(图 2:guest 通知 vhost 读取数据流程)

坑二:Weave 无法使用 FastDb 模式

1 问题描述

在内核版本 CentOS Linux (3.10.0-327.10.1.el7.x86_64) 7 (Core) 上 ,Weave 版本大于 1.2,如果云主机的 MTU 值为 1450 或者小于 1474,Weave 启动时无法正常选择 Fast Data Path 模式。在 Weave 启动后一直选择 sleeve 模式,本应该默认模式为 FastDb,该问题也和内核的版本相关。

2 问题分析

Weave 的 Fast Data Path 路径使用到 ODP 技术,也就是内核中的 OVS 模块,在 Container 中直接发送数据包到 ovs 模块。在启动 Weave 时,会自动选择使用 sleeve 模式还是 FastDb 模式,这里通过发送心跳包来决定。出现该问题时,在云主机通过 Docker logs Weave 日志可以看到出错信息:“FastDb timed out waiting for vxlan heartbeat”。

heartbeat 数据包是一个 UDP 包,目的端口号为 6784,在某些云主机上接口的 MTU 值为 1454,但在发送 UDP 的 heartbeat 数据包时,发送的是 1474 字节,这样就会对报文在 IP 层进行分片,而在主机上发现心跳报文发送不出去,当 MTU 的值修改为 1500 后,就可以发送出去。

在 MTU 为 1454 的情况下,会出现下面的 ICMP 错误报文:

(图 3: 出现的错误 ICMP 报文)

上面出现错误的 ICMP 报文是内核中的 ip_fragment 函数调用 ICMP_send 函数发送的:

复制代码
if (unlikely(((iph->frag_off & htons(IP_DF)) && !skb->ignore_df) ||
(IPCB(skb)->frag_max_size &&
IPCB(skb)->frag_max_size > mtu))) {
IP_INC_STATS(dev_net(dev), IPSTATS_MIB_FRAGFAILS);
ICMP_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED,
htonl(mtu));
kfree_skb(skb);
return -EMSGSIZE;
}
{1}

通过上述代码可以看出,如果出现错误 ICMP 报文,下面的判断条件 iph->frag_off & htons(IP_DF)) && !skb->ignore_df 需要成立。通过对抓取的报文分析可知 iph->frag_off & htons(IP_DF)) 的值为真,那么 skb->ignore_df 值需要为 0,而此处的关键在于 skb->ignore_df 的值是何时赋值为 0 的。

通过分析 Weave 发送心跳包的流程可知,在 vxlan_tnl_send 函数中,对 skb->ignore_df 赋值为 1,最后调用 tunnel 的发送函数 iptunnel_xmit 时,调用了 skb_scrub_packet 函数,在该函数中又重新对 skb->ignore_df 赋值为 0(kernel 版本为:3.10.0-327.el7),造成后续发送报文时,ICMP 目的不可达,并且错误码为 ICMP_FRAG_NEEDED 的报文。

复制代码
void skb_scrub_packet(struct sk_buff *skb, bool xnet)
{
skb->tstamp.tv64 = 0;
skb->pkt_type = PACKET_HOST;
skb->skb_iif = 0;
skb->ignore_df = 0;
skb_dst_drop(skb);
secpath_reset(skb);
nf_reset(skb);
nf_reset_trace(skb);
if (!xnet)
return;
skb_orphan(skb);
skb->mark = 0;
}

上面代码是 CentOS7 的 3.10.0-327.el7,而在一些旧内核版本 3.10.0-123.el7 上,iptunnel_xmit 调用的是 secpath_reset(skb) 函数,该函数并没有对 skb->local_df(低版本内核使用 local_df)进行重新初始化,也就是 skb->local_df 值仍旧为 1,因此在该版本上不会出现上述问题。

复制代码
static inline void
secpath_reset(struct sk_buff *skb)
{
#ifdef CONFIG_XFRM
secpath_put(skb->sp);
skb->sp = NULL;
#endif
}
(图 4:内核版本不同造成设置不同)

虽然新的内核版本中存在该问题,不过内核本身没有问题,还是 Weave 用户态管理 datapath 程序与内核适配上出现问题 (它并不是使用 ovs-switchd),在 OVS 中对 tunnel 类型可以设置为 df_default=false 进行分片。

3 解决方法

保证接口的 MTU 值为默认为 1500。

总 结

Weave 的 ODP 功能使用了内核特性,在使用 Weave 的 FastDb 功能时遇到上述两个问题都与内核密切相关。通过对内核层分析,可以定位到问题的根本原因,所以后续遇到类似问题时,可以多从内核角度进行考虑。

本文转载自公众号 UCloud 技术(ID:ucloud_tech)。

原文链接:

https://mp.weixin.qq.com/s/h8g3aXu0oD5FfXEnv72Kwg

评论

发布