干货:如何跨过使用Docker网络解决方案Weave遇到的“坑”?

百家 作者:Ucloud 2017-06-21 09:02:41

前言:

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造成虚拟机网络中断

 问题描述

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

问题分析

导致网络断开的原因是由于触发了内核的一个bug,该内核bug的commit链接地址:https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=8a0cafc9a8131cc545dc9924aed38f7176ee4ad7 (网址过长,可输入http://t.cn/Ro53BsH 查看)

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

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

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

 解决方法

1)升级内核,保证内核版本大于等于3.13;

2)关闭虚拟机网卡的ufo特性;

3)centos7.1的kernel-3.10.229内核已经修复了该问题。

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

坑二:Weave无法使用FastDb模式

 问题描述


在内核版本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,该问题也和内核的版本相关。

 问题分析


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;

       }

通过上述代码可以看出,如果出现错误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

}

   (图:内核版本不同造成设置不同)

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

 解决方法


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


总结

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

关注公众号:拾黑(shiheibook)了解更多

[广告]赞助链接:

四季很好,只要有你,文娱排行榜:https://www.yaopaiming.com/
让资讯触达的更精准有趣:https://www.0xu.cn/

公众号 关注网络尖刀微信公众号
随时掌握互联网精彩
赞助链接