ULB4是UCloud自主研發(fā)的基于DPDK的高可用四層負(fù)載均衡產(chǎn)品，轉(zhuǎn)發(fā)能力接近線速；DPDK則是一個(gè)高性能的開源數(shù)據(jù)面開發(fā)套件。ULB4作為用戶應(yīng)用的全局入口，在大流量多元化場景下保證用戶業(yè)務(wù)的持續(xù)穩(wěn)定至關(guān)重要，這也是UCloud網(wǎng)絡(luò)產(chǎn)品團(tuán)隊(duì)的技術(shù)使命。尤其現(xiàn)網(wǎng)單個(gè)ULB集群承載帶寬已達(dá)10G，包量83萬PPS，運(yùn)行環(huán)境復(fù)雜，即使面臨突發(fā)因素(比如觸發(fā)未知BUG)，我們也要設(shè)法保證產(chǎn)品正常工作，避免產(chǎn)生嚴(yán)重影響。
近期，我們?cè)赨LB4的線上環(huán)境中，發(fā)現(xiàn)了一個(gè)DPDK的發(fā)包異?，F(xiàn)象，由于整個(gè)ULB產(chǎn)品為集群架構(gòu)，該異常并未導(dǎo)致用戶服務(wù)不可用。但為了任何時(shí)刻都能保證用戶服務(wù)的足夠穩(wěn)定，團(tuán)隊(duì)通過GDB、報(bào)文導(dǎo)出工具、生產(chǎn)環(huán)境流量鏡像等手段，從現(xiàn)網(wǎng)GB級(jí)流量中捕獲異常報(bào)文，再結(jié)合DPDK源碼分析，定位到原因出自DPDK本身的BUG并修復(fù)解決。期間未對(duì)用戶業(yè)務(wù)造成影響，進(jìn)一步保證了UCloud數(shù)萬ULB實(shí)例的穩(wěn)定運(yùn)行。
本文將從問題現(xiàn)象著手，抽絲剝繭，詳述問題定位、分析與解決全過程，希望能為ULB用戶和DPDK開發(fā)者提供參考與啟迪。
問題背景
在12月初一向穩(wěn)定的ULB4集群中突然出現(xiàn)了容災(zāi)，某臺(tái)ULB4服務(wù)器工作異常被自動(dòng)移出了集群。當(dāng)時(shí)的現(xiàn)象是：
轉(zhuǎn)發(fā)面服務(wù)監(jiān)控到網(wǎng)卡接收方向流量正常，但是發(fā)送方向流量為0，重啟轉(zhuǎn)發(fā)面服務(wù)后又可以正常收發(fā)，同時(shí)集群其他機(jī)器也會(huì)不定期出現(xiàn)異常情況。對(duì)用戶業(yè)務(wù)而言，會(huì)出現(xiàn)少量連接輕微抖動(dòng)，隨后迅速恢復(fù)。
下面是整個(gè)問題的處理過程，我們?cè)诖诉^程中做出種種嘗試，最終結(jié)合DPDK源碼完成分析和解決，后續(xù)也準(zhǔn)備將自研的報(bào)文導(dǎo)出工具開源共享。
問題定位與分析
ULB4集群一直很穩(wěn)定地工作，突然陸續(xù)在集群的不同機(jī)器上出現(xiàn)同樣的問題，并且機(jī)器恢復(fù)加入集群后，過了一段時(shí)間又再次出現(xiàn)同樣的問題。根據(jù)我們的運(yùn)營經(jīng)驗(yàn)，初步猜測(cè)是某種異常報(bào)文觸發(fā)了程序BUG。但是，面對(duì)GB級(jí)流量如何捕獲到異常報(bào)文？又如何在不影響業(yè)務(wù)情況下找出問題呢？
一、GDB調(diào)試報(bào)文，發(fā)現(xiàn)疑點(diǎn)
想要知道整個(gè)程序?yàn)槭裁床话l(fā)包，最好的辦法就是能夠進(jìn)入到程序中去看看具體的執(zhí)行過程。對(duì)于DPDK用戶態(tài)程序來說，GDB顯然是一個(gè)好用的工具。我們?cè)诎l(fā)包程序邏輯中設(shè)置斷點(diǎn)，并通過disassemble命令查看該函數(shù)的執(zhí)行邏輯，反匯編之后足足有七百多行。（該函數(shù)中調(diào)用的很多函數(shù)都使用了inline修飾，導(dǎo)致該函數(shù)在匯編之后指令特別多）
結(jié)合對(duì)應(yīng)DPDK版本的源碼，單條指令一步步執(zhí)行。在多次嘗試之后，發(fā)現(xiàn)每次都會(huì)在下圖所示的地方直接返回。
大致流程是i40e_xmit_pkts()在發(fā)送的時(shí)候，發(fā)現(xiàn)發(fā)送隊(duì)列滿了就會(huì)去調(diào)用i40e_xmit_cleanup()清理隊(duì)列。DPDK中網(wǎng)卡在發(fā)送完數(shù)據(jù)包后會(huì)去回寫特定字段，表明該報(bào)文已經(jīng)發(fā)送，而驅(qū)動(dòng)程序去查看該字段就可以知道這個(gè)報(bào)文是否已經(jīng)被發(fā)過。此處的問題就是驅(qū)動(dòng)程序認(rèn)為該隊(duì)列中的報(bào)文始終未被網(wǎng)卡發(fā)送出去，后續(xù)來的報(bào)文將無法加入到隊(duì)列而被直接丟棄。
至此，直接原因已經(jīng)找到，就是網(wǎng)卡因?yàn)槟撤N原因不發(fā)包或者沒能正確回寫特定字段，導(dǎo)致驅(qū)動(dòng)程序認(rèn)為發(fā)送隊(duì)列始終處于隊(duì)列滿的狀態(tài)，而無法將后續(xù)的報(bào)文加入發(fā)送隊(duì)列。
那么為什么出現(xiàn)隊(duì)列滿？異常包是否相關(guān)呢？帶著這個(gè)疑問，我們做了第二個(gè)嘗試。
二、一鍵還原網(wǎng)卡報(bào)文
隊(duì)列滿，而且后面的報(bào)文一直加不進(jìn)去，說明此時(shí)隊(duì)列里面的報(bào)文一直卡在那。既然我們猜測(cè)可能是存在異常報(bào)文，那么有沒有可能異常報(bào)文還在隊(duì)列里面呢？如果可以把當(dāng)前隊(duì)列里面的報(bào)文全部導(dǎo)出來，那就可以進(jìn)一步驗(yàn)證我們的猜測(cè)了。
基于對(duì)DPDK的深入研究，我們根據(jù)以下步驟導(dǎo)出報(bào)文。
? 我們看i40e_xmit_pkts()函數(shù)，會(huì)發(fā)現(xiàn)第一個(gè)參數(shù)就是發(fā)送隊(duì)列，所以我們可以獲取到隊(duì)列的信息。
? 如下圖所示，在剛進(jìn)入斷點(diǎn)的時(shí)候，查看寄存器信息，以此來獲得該函數(shù)對(duì)應(yīng)的參數(shù)。
? 當(dāng)我們打印該隊(duì)列的消息時(shí)，卻發(fā)現(xiàn)沒有符號(hào)信息，此時(shí)我們可以如下圖所示去加載編譯時(shí)候生成的 i40e_rxtx.o 來獲取對(duì)應(yīng)符號(hào)信息。
? 在得到隊(duì)列信息后，我們使用GDB的dump命令將整個(gè)隊(duì)列中所有的報(bào)文全部按隊(duì)列中的順序?qū)С?，?duì)每個(gè)報(bào)文按序號(hào)命名。
? 此時(shí)導(dǎo)出的報(bào)文還是原始的報(bào)文，我們無法使用wireshark方便地查看報(bào)文信息。為此如下圖所示，我們使用libpcap庫寫了個(gè)簡單的小工具轉(zhuǎn)換成wireshark可以解析的pcap文件。
果然，如下圖所示，在導(dǎo)出的所有報(bào)文中包含了一個(gè)長度為26字節(jié)，但內(nèi)容為全0的報(bào)文。這個(gè)報(bào)文看上去十分異常，似乎初步驗(yàn)證了我們的猜測(cè)：
為了提高在排查問題時(shí)導(dǎo)出報(bào)文的速度，我們寫了一個(gè)報(bào)文一鍵導(dǎo)出工具，可以在異常時(shí)一鍵導(dǎo)出所有的報(bào)文并轉(zhuǎn)成pcap格式。
在多次導(dǎo)出報(bào)文后，我們發(fā)現(xiàn)一個(gè)規(guī)律：每次都會(huì)有一個(gè)長度為26字節(jié)但是全0的報(bào)文，而且在其前面都會(huì)有一個(gè)同樣長度的報(bào)文，且每次源IP地址網(wǎng)段都來自于同一個(gè)地區(qū)。
三、流量鏡像，確認(rèn)異常包
第二步結(jié)論讓整個(gè)排查前進(jìn)了一大步，但是隊(duì)列包是經(jīng)過一系列程序處理的，并不是真正的原始業(yè)務(wù)報(bào)文。不達(dá)目的不罷休，關(guān)鍵時(shí)刻還是要上鏡像抓包，于是當(dāng)晚緊急聯(lián)系網(wǎng)絡(luò)運(yùn)維同事在交換機(jī)上配置port-mirroring（端口鏡像），將發(fā)往ULB4集群的流量鏡像到一個(gè)空閑服務(wù)器上進(jìn)行鏡像抓包。當(dāng)然，鏡像服務(wù)器還需要做特殊配置，如下：
1. 設(shè)置網(wǎng)卡混雜模式，用于收取鏡像流量（ifconfig net2 promisc）。
2. 關(guān)閉GRO功能（ethtool -K net2 gro off），用于收取最原始的報(bào)文，防止Linux的GRO功能提前將報(bào)文進(jìn)行組裝。
根據(jù)異常IP的地域特性，我們針對(duì)性抓取了部分源IP段的流量。
參考命令：nohup tcpdump -i net2 -s0 -w %Y%m%d_%H-%M-%S.pcap -G 1800 “proto gre and (((ip[54:4]&0x11223000)==0x11223000) or ((ip[58:4]&0x11223000)==0x11223000))” &
經(jīng)過多次嘗試后，功夫不負(fù)有心人，故障出現(xiàn)了，經(jīng)過層層剝離篩選，找到了如下報(bào)文：
這是IP分片報(bào)文，但是奇怪的是IP分片的第二片只有IP頭。經(jīng)過仔細(xì)比對(duì)，這兩個(gè)報(bào)文合在一起就是導(dǎo)出隊(duì)列報(bào)文中的那兩個(gè)連在一起的報(bào)文。后26字節(jié)和全0報(bào)文完全吻合。
我們知道在TCP/IP協(xié)議中，如果發(fā)送時(shí)一個(gè)IP報(bào)文長度超過了MTU，將會(huì)觸發(fā)IP分片，會(huì)被拆成多個(gè)小的分片報(bào)文進(jìn)行發(fā)送。正常情況下，所有的分片肯定都是攜帶有數(shù)據(jù)的。但是這一個(gè)分片報(bào)文就很異常，報(bào)文的總長度是20，也就是說只有一個(gè)IP頭，后面不再攜帶任何信息，這樣的報(bào)文是沒有任何意義的。這個(gè)報(bào)文還因?yàn)殚L度太短在經(jīng)過交換機(jī)后被填充了26字節(jié)的0。
至此，我們最終找到了這個(gè)異常報(bào)文，也基本驗(yàn)證了我們的猜測(cè)。但是還需要去實(shí)際驗(yàn)證是否為這種異常報(bào)文導(dǎo)致。（從整個(gè)報(bào)文的交互來看，這一片報(bào)文本來是設(shè)置了不可分片的TCP報(bào)文，但是在經(jīng)過某個(gè)公網(wǎng)網(wǎng)關(guān)后被強(qiáng)制設(shè)定了允許分片，并且分片出了這種異常的形式。）
四、解決方案
如果確實(shí)是這個(gè)異常報(bào)文導(dǎo)致的，那么只要在收包時(shí)對(duì)這種異常報(bào)文進(jìn)行檢查然后丟棄就可以了。于是，我們修改DPDK程序，丟棄這類報(bào)文。作為驗(yàn)證，先發(fā)布了一臺(tái)線上服務(wù)器，經(jīng)過1天運(yùn)行再也沒有出現(xiàn)異常容災(zāi)情況。既然問題根因已經(jīng)找到，正是這種異常報(bào)文導(dǎo)致了DPDK工作異常，后續(xù)就可以按灰度全網(wǎng)發(fā)布了。
五、DPDK社區(qū)反饋
本著對(duì)開源社區(qū)負(fù)責(zé)任的態(tài)度，我們準(zhǔn)備將BUG向DPDK社區(qū)同步。對(duì)比最新的commit后，找到11月6日提交的一個(gè)commit，情況如出一轍，如下：
ip_frag: check fragment length of incoming packet
DPDK 18.11最新發(fā)布的版本中，已對(duì)此進(jìn)行了修復(fù)，和我們處理邏輯一致，也是丟棄該異常報(bào)文。
復(fù)盤和總結(jié)
處理完所有問題后，我們開始做整體復(fù)盤。
一、ULB無法發(fā)包的成因總結(jié)
ULB4無法發(fā)包的整個(gè)產(chǎn)生過程如下：
1. DPDK收到分片報(bào)文中的第一片，將其緩存下來等待后續(xù)分片；
2. 第二片只有IP頭的異常分片到來，DPDK按照正常的報(bào)文處理邏輯進(jìn)行處理，并沒有進(jìn)行檢查丟棄，于是兩片報(bào)文的rte_mbuf結(jié)構(gòu)被鏈在一起，組成了一個(gè)鏈?zhǔn)綀?bào)文返回給ULB4；
3. 這樣的報(bào)文被ULB4接收后，因?yàn)檎麄€(gè)報(bào)文的總長度并沒有達(dá)到需要分片的長度，所以ULB4直接調(diào)用DPDK的發(fā)送接口發(fā)送出去；
4. DPDK沒有對(duì)這種異常報(bào)文進(jìn)行檢查，而是直接調(diào)用相應(yīng)的用戶態(tài)網(wǎng)卡驅(qū)動(dòng)直接將報(bào)文發(fā)送出去；
5. 用戶態(tài)網(wǎng)卡驅(qū)動(dòng)在發(fā)送這樣的異常報(bào)文時(shí)觸發(fā)了網(wǎng)卡tx hang；
6. 觸發(fā)tx hang后，網(wǎng)卡不再工作，驅(qū)動(dòng)隊(duì)列中報(bào)文對(duì)應(yīng)的發(fā)送描述符不再被網(wǎng)卡正確設(shè)置發(fā)送完成標(biāo)記；
7. 后續(xù)的報(bào)文持續(xù)到來，開始在發(fā)送隊(duì)列中積壓，最終將整個(gè)隊(duì)列占滿，再有報(bào)文到來時(shí)將被直接丟棄。
二、為什么異常報(bào)文會(huì)觸發(fā)網(wǎng)卡tx hang
首先我們看下DPDK中跟網(wǎng)卡發(fā)送報(bào)文相關(guān)的代碼。
從以上的圖中我們可以看到，根據(jù)網(wǎng)卡的Datasheet對(duì)相關(guān)字段進(jìn)行正確設(shè)置非常重要，如果某種原因設(shè)置錯(cuò)誤，將可能會(huì)導(dǎo)致不可預(yù)知的后果（具體還是要參考網(wǎng)卡的Datasheet）。
如下圖所示，通常網(wǎng)卡對(duì)應(yīng)的Datasheet中會(huì)對(duì)相應(yīng)字段進(jìn)行相關(guān)描述，網(wǎng)卡驅(qū)動(dòng)中一般都會(huì)有相應(yīng)的數(shù)據(jù)結(jié)構(gòu)與其對(duì)應(yīng)。
在有了基本了解后，我們猜想如果直接在程序中手動(dòng)構(gòu)造這種類似的異常報(bào)文，是否也會(huì)導(dǎo)致網(wǎng)卡異常不發(fā)包？
答案是肯定的。
如下圖所示，我們使用這樣的代碼片段構(gòu)成異常報(bào)文，然后調(diào)用DPDK接口直接發(fā)送，很快網(wǎng)卡就會(huì)tx hang。
三、對(duì)直接操作硬件的思考
直接操作硬件是一件需要非常謹(jǐn)慎的事情，在傳統(tǒng)的Linux系統(tǒng)中，驅(qū)動(dòng)程序一般處于內(nèi)核態(tài)由內(nèi)核去管理，而且驅(qū)動(dòng)程序代碼中可能進(jìn)行了各種異常處理，因此很少會(huì)發(fā)生用戶程序操作導(dǎo)致硬件不工作的情況。而DPDK因?yàn)槠渥陨硎褂糜脩魬B(tài)驅(qū)動(dòng)的特點(diǎn)，使得可以在用戶態(tài)直接操作硬件，同時(shí)為了提升性能可能進(jìn)行了非常多的優(yōu)化，如果用戶自身程序處理出問題就有可能會(huì)導(dǎo)致網(wǎng)卡tx hang這樣的異常情況發(fā)生。
四、工具的價(jià)值
我們編寫了一鍵導(dǎo)出DPDK驅(qū)動(dòng)隊(duì)列報(bào)文的工具，這樣就可以在每次出現(xiàn)問題時(shí)，快速導(dǎo)出網(wǎng)卡驅(qū)動(dòng)發(fā)送隊(duì)列中的所有報(bào)文，大大提高了排查效率。這個(gè)工具再優(yōu)化下后，準(zhǔn)備在UCloud GitHub上開源，希望對(duì)DPDK開發(fā)者有所幫助。
寫在最后
DPDK作為開源套件，通常情況下穩(wěn)定性和可靠性不存在什么問題，但是實(shí)際的應(yīng)用場景千變?nèi)f化，一些特殊情況可能導(dǎo)致DPDK工作異常。雖然發(fā)生概率很小，但是DPDK通常在關(guān)鍵的網(wǎng)關(guān)位置，一旦出現(xiàn)了問題，哪怕是很少見的問題也將會(huì)產(chǎn)生嚴(yán)重影響。
因此技術(shù)團(tuán)隊(duì)理解其工作原理并對(duì)其源碼進(jìn)行分析，同時(shí)能夠結(jié)合具體現(xiàn)象一步步定位出DPDK存在的問題，對(duì)提高整個(gè)DPDK程序的服務(wù)可靠性具有重要意義。值得一提的是，ULB4的高可用集群架構(gòu)在本次問題的處理過程中發(fā)揮了重要作用，在一臺(tái)不可用的時(shí)候，集群中其他機(jī)器也可以繼續(xù)為用戶提供可靠服務(wù)，有效提升了用戶業(yè)務(wù)的可靠性。
申請(qǐng)創(chuàng)業(yè)報(bào)道，分享創(chuàng)業(yè)好點(diǎn)子。點(diǎn)擊此處，共同探討創(chuàng)業(yè)新機(jī)遇！
