建站
咨詢
售后
建站咨詢
新聞中心
前言
網站建設哪家好，找成都創(chuàng)新互聯公司！專注于網頁設計、網站建設、微信開發(fā)、成都微信小程序、集團企業(yè)網站建設等服務項目。為回饋新老客戶創(chuàng)新互聯還提供了天元免費建站歡迎大家使用！
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創(chuàng)建的云主機上，如果安裝centos7.0，內核版本為kernel-3.10.123，那么在啟動Weave并使用FastDb模式時，會造成virtio_net虛擬網卡無法發(fā)送數據，進而導致整個虛擬機的網絡中斷。
問題分析導致網絡斷開的原因是由于觸發(fā)了內核的一個bug，該內核bug的commit鏈接
觸發(fā)該bug主要是因為Weave在初始化時會發(fā)送一個60000字節(jié)的UDP數據包進行PMTU探測，并且 Weave發(fā)送使用的套接字為raw socket，導致virtio_net使用的內存被污染，具體表現就是無法通知到宿主機上vhost獲取數據，在接口上看到發(fā)送報文的計數始終不會增加。
該問題不是只有Weave才能觸發(fā)，用普通應用程序建立socket時使用raw socket,并且發(fā)送的數據大于接口的MTU值，接口的UFO功能是打開的，這些情況下都極有可能觸發(fā)該問題，造成網絡中斷。
(圖：FastDb模式的數據流原理)
2. 解決方法
1)升級內核，保證內核版本大于等于3.13;
2)關閉虛擬機網卡的ufo特性;
3)centos7.1的kernel-3.10.229內核已經修復了該問題。
(圖：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中直接發(fā)送數據包到ovs模塊。在啟動Weave時，會自動選擇使用sleeve模式還是FastDb模式，這里通過發(fā)送心跳包來決定。出現該問題時，在云主機通過Docker logs Weave日志可以看到出錯信息：FastDb timed out waiting for vxlan heartbeat。
heartbeat數據包是一個UDP包，目的端口號為6784，在某些云主機上接口的MTU值為1454，但在發(fā)送UDP的heartbeat數據包時，發(fā)送的是1474字節(jié)，這樣就會對報文在IP層進行分片，而在主機上發(fā)現心跳報文發(fā)送不出去，當MTU的值修改為1500后，就可以發(fā)送出去。
在MTU為1454的情況下，會出現下面的ICMP錯誤報文。
(圖3: 出現的錯誤ICMP報文)
上面出現錯誤的ICMP報文是內核中的ip_fragment函數調用ICMP_send函數發(fā)送的，
- 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發(fā)送心跳包的流程可知，在vxlan_tnl_send函數中，對skb->ignore_df賦值為1，***調用tunnel的發(fā)送函數iptunnel_xmit時，調用了skb_scrub_packet函數，在該函數中又重新對skb->ignore_df賦值為0(kernel版本為：3.10.0-327.el7)，造成后續(xù)發(fā)送報文時，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用戶態(tài)管理datapath程序與內核適配上出現問題(它并不是使用ovs-switchd)，在OVS中對tunnel類型可以設置為df_default=false進行分片。
解決方法
保證接口的MTU值為默認為1500。
總結
Weave的ODP功能使用了內核特性，在使用Weave的FastDb功能時遇到上述兩個問題都與內核密切相關。通過對內核層分析，可以定位到問題的根本原因，所以后續(xù)遇到類似問題時，可以多從內核角度進行考慮。
分享題目：如何跨過使用Docker網絡解決方案Weave遇到的“坑”？
網頁URL：http://www.5511xx.com/article/djpecie.html
