李德方, 古 亮, 閆爭爭, 陳曉帆

1(中國科學(xué)院 深圳先進(jìn)技術(shù)研究院, 深圳 518055)

2(深信服科技股份有限公司, 深圳 518055)

1 引言

隨著云計(jì)算技術(shù)的不斷發(fā)展, 業(yè)務(wù)上云在各個(gè)大中小企業(yè)、政府機(jī)關(guān)、教育醫(yī)療機(jī)構(gòu)等逐漸成為趨勢,并且該需求在后疫情時(shí)代變得更加緊迫. 但公有云并不適合于所有的用戶和業(yè)務(wù)場景, 由于數(shù)據(jù)的保密性等原因, 利用超融合[1]基礎(chǔ)設(shè)施來構(gòu)建私有云或者混合云是中小企業(yè)、政府機(jī)關(guān)、教育醫(yī)療機(jī)構(gòu)等實(shí)現(xiàn)業(yè)務(wù)上云的有效手段. 超融合設(shè)備實(shí)現(xiàn)了計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)等基礎(chǔ)設(shè)施的虛擬化, 此外, 借助于網(wǎng)絡(luò)功能虛擬化(network function virtualization, NFV), 網(wǎng)絡(luò)安全檢測功能體也可以集成到超融合設(shè)備中. 當(dāng)前國內(nèi)廠商如深信服、華為、華三、SmartX等, 國外廠商如VMware、Nutanix、Redhat等都提供超融合設(shè)備以及完善的基于超融合的云解決方案. 本文將關(guān)注于基于超融合構(gòu)建的私有云或者混合云的網(wǎng)絡(luò)問題以及解決方案.

借助于網(wǎng)絡(luò)虛擬化, 傳統(tǒng)的盒子式的硬件網(wǎng)絡(luò)設(shè)備被一段段代碼替代. 網(wǎng)絡(luò)虛擬化的實(shí)現(xiàn)方式一般分為內(nèi)核態(tài)實(shí)現(xiàn)和用戶態(tài)實(shí)現(xiàn)(本文涉及到的虛擬化技術(shù)默認(rèn)都是基于Linux系統(tǒng)來進(jìn)行實(shí)現(xiàn)的. Linux系統(tǒng)在運(yùn)行時(shí)會(huì)分為用戶態(tài)空間和內(nèi)核態(tài)空間). 內(nèi)核態(tài)實(shí)現(xiàn)主要方案為借助于Vhost-net/Virtio-net架構(gòu)[2]和OpenVSwitch (OVS)來進(jìn)行實(shí)現(xiàn), 但其性能不高. 為了提升虛擬網(wǎng)絡(luò)的轉(zhuǎn)發(fā)性能, 業(yè)界也提出了很多轉(zhuǎn)發(fā)優(yōu)化方案, 如內(nèi)核態(tài)的OVS+XDP (eXpress DataPlane)方案[3]. 其中應(yīng)用最廣的還是基于DPDK (data plane development kit)[4]的方案. DPDK是Intel開發(fā)的一套數(shù)據(jù)面性能優(yōu)化套件, 借助于此, 開發(fā)者可以在Linux用戶態(tài)空間定制化地開發(fā)所需的虛擬網(wǎng)絡(luò)轉(zhuǎn)發(fā)設(shè)備,如虛擬交換機(jī)、虛擬路由器等. 性能測試表明, 基于DPDK的數(shù)據(jù)面(data plane, DP)的轉(zhuǎn)發(fā)性能相對于普通的內(nèi)核轉(zhuǎn)發(fā)性能可以提升10倍以上[5]. 因此, DPDK技術(shù)在高性能數(shù)據(jù)轉(zhuǎn)發(fā)場景得到了廣泛的應(yīng)用.

為了提升虛擬網(wǎng)絡(luò)的性能, 超融合設(shè)備的網(wǎng)絡(luò)轉(zhuǎn)發(fā)面(也即虛擬網(wǎng)絡(luò)數(shù)據(jù)面)一般還會(huì)應(yīng)用軟件定義網(wǎng)絡(luò) (software-defined network, SDN)技術(shù)[6], 借助于該技術(shù), 可以實(shí)現(xiàn)網(wǎng)絡(luò)轉(zhuǎn)發(fā)和網(wǎng)絡(luò)控制功能的分離, 以及快慢路分離的轉(zhuǎn)發(fā)路徑[7], 大大提升了網(wǎng)絡(luò)轉(zhuǎn)發(fā)效率. 其實(shí)OVS即是SDN交換機(jī)的具體形式, 而DPDK+OVS的方式也是高性能虛擬網(wǎng)絡(luò)數(shù)據(jù)面的主流開源實(shí)現(xiàn)方案. 本文所述虛擬交換機(jī)并不是OVS但是基于DPDK和SDN思想來開發(fā)的, 工作原理與OVS相近.

隨著虛擬化技術(shù)、SDN技術(shù)、DPDK用戶態(tài)轉(zhuǎn)發(fā)技術(shù)等新技術(shù)的不斷引入, 云計(jì)算中的網(wǎng)絡(luò)(虛擬網(wǎng)絡(luò))性能也變得越來越高, 但同時(shí)也變得越來越復(fù)雜.對于網(wǎng)絡(luò)運(yùn)維人員而言, 虛擬網(wǎng)絡(luò)更像是一個(gè)全新的事物, 需要學(xué)習(xí)如何去管理, 但不幸的是, 應(yīng)用于傳統(tǒng)物理網(wǎng)絡(luò)設(shè)備的很多經(jīng)典工具無法滿足虛擬網(wǎng)絡(luò)排障的需求, 這就使得虛擬網(wǎng)絡(luò)呈現(xiàn)出了一種“黑盒”的特征, 網(wǎng)絡(luò)運(yùn)維人員不能獲知虛擬網(wǎng)絡(luò)的運(yùn)行狀態(tài), 當(dāng)虛擬網(wǎng)絡(luò)發(fā)生故障時(shí), 如連續(xù)長時(shí)丟包, 也就無法很快地定位出故障位置以及故障原因, 進(jìn)而導(dǎo)致更長的故障修復(fù)時(shí)間, 更大的經(jīng)濟(jì)損失.

為了解決虛擬網(wǎng)絡(luò)的排障問題, 工業(yè)界和學(xué)術(shù)界均提出了很多解決方案, 如將傳統(tǒng)的工具進(jìn)行虛擬化改造, 但更有效的方法是設(shè)計(jì)新的遙測技術(shù)(telemetry),如思科和華為提出的帶內(nèi)網(wǎng)絡(luò)遙測(in-band network telemetry, INT)技術(shù)[8-10], 開源的OpenTelemetry技術(shù)[11], OpenTracing技術(shù)[12]等. 遙測技術(shù)一般分為帶內(nèi)遙測(in-band telemetry)和帶外遙測(out-band telemetry), 帶內(nèi)遙測獲得的信息更加準(zhǔn)確, 但性能開銷比較大, 并且可擴(kuò)展性也不如帶外遙測. 帶外遙測獲得的信息不如帶內(nèi)遙測精確, 但性能開銷一般較小, 并且具備良好的可擴(kuò)展性. 本文提出的方案是一種帶外遙測, 但我們做了一系列的優(yōu)化, 使之能取得接近于帶內(nèi)要測的效果.

在設(shè)計(jì)虛擬網(wǎng)絡(luò)故障檢測工具或者系統(tǒng)時(shí), 需要遵循如下3個(gè)原則.

高性能: 基本上任何的檢測或者監(jiān)控工具/系統(tǒng)都會(huì)產(chǎn)生“觀察者效應(yīng)”[13], 觀察者效應(yīng)會(huì)影響到觀察結(jié)果的有效性, 觀察者效應(yīng)越明顯, 所得到的結(jié)果也就越不準(zhǔn)確, 也就失去了觀測的意義. 這種觀察者效應(yīng)在虛擬化環(huán)境中會(huì)更加明顯, 因而虛擬化環(huán)境是更加功能集中, 資源緊缺的, 因此, 設(shè)計(jì)的檢測或者監(jiān)控工具要做到高性能、低資源開銷.

低干擾: 除了觀察者效應(yīng)的影響, 設(shè)計(jì)的檢測或者監(jiān)控工具/系統(tǒng)在運(yùn)行時(shí)不應(yīng)該干擾到正常的業(yè)務(wù)流量, 更不能因?yàn)楣收蠙z測導(dǎo)致正常業(yè)務(wù)崩潰.

信息完全性: 收集到的信息應(yīng)該足夠全面, 并且分析方法也要全面, 可以多角度地對收集到的信息進(jìn)行分析并得出結(jié)論.

在上述原則下, 本文設(shè)計(jì)了一種虛擬網(wǎng)絡(luò)持續(xù)性丟包探測系統(tǒng): Flowprobe, 該系統(tǒng)可以回答以下問題:

1) 數(shù)據(jù)包在虛擬網(wǎng)絡(luò)中的詳細(xì)轉(zhuǎn)發(fā)路徑是什么?是否與其路徑一致.

2) 若發(fā)生丟包, 則持續(xù)性丟包的虛擬網(wǎng)元或者位置在哪.

3) 持續(xù)性丟包的原因是什么.

該虛擬網(wǎng)絡(luò)持續(xù)性丟包檢測系統(tǒng)針對基于HCI構(gòu)建的私有云或者混合云而設(shè)計(jì), 其主要思想是通過主動(dòng)發(fā)送帶標(biāo)記的探測包, 虛擬網(wǎng)絡(luò)數(shù)據(jù)面識別到這些探測包以后解析探測包的指令信息, 根據(jù)指令信息上傳探測信息至控制器, 在控制器進(jìn)行路徑計(jì)算和丟包計(jì)算. 該系統(tǒng)針對的虛擬網(wǎng)絡(luò)是基于DPDK來實(shí)現(xiàn)的, 因此, 該系統(tǒng)完全位于Linux用戶空間, 運(yùn)行時(shí)不會(huì)對Linux內(nèi)核空間造成干擾. 為了使得所設(shè)計(jì)的系統(tǒng)符合上述原則以及解決所提出的問題, 做了如下創(chuàng)新設(shè)計(jì)與優(yōu)化:

1) 支持定制不同類型的IPv4/IPv6探測包, 如TCP、UDP、ICMP等, 并支持探測包包頭參數(shù)和包大小的定制. 支持?jǐn)?shù)據(jù)包的定制可以使得探測包更加接近于用戶業(yè)務(wù)包, 如此一來, 探測包經(jīng)歷的網(wǎng)絡(luò)行為與業(yè)務(wù)包經(jīng)歷的網(wǎng)絡(luò)行為就更加一致, 得到的探測結(jié)果也更加準(zhǔn)確.

2) 設(shè)計(jì)了高效的探測包標(biāo)記方案. 通過該方案做到了對虛擬網(wǎng)絡(luò)數(shù)據(jù)面正常業(yè)務(wù)轉(zhuǎn)發(fā)的最小影響.

3) 探測包不會(huì)由用戶虛擬機(jī)發(fā)出, 也不會(huì)進(jìn)入到用戶虛擬機(jī). 如此一來, 可以減小對用戶虛擬機(jī)工作負(fù)載的干擾.

4) 支持探測路徑的計(jì)算和展示.

5) 支持顯示數(shù)據(jù)包被丟棄的原因.

通過該系統(tǒng), 用戶可以觀測數(shù)據(jù)包在虛擬網(wǎng)絡(luò)中的詳細(xì)路徑、經(jīng)歷的轉(zhuǎn)發(fā)行為, 定位丟包的位置, 獲知丟包的原因. 實(shí)驗(yàn)表明, 該系統(tǒng)可以針對576種虛擬網(wǎng)絡(luò)持續(xù)丟包場景進(jìn)行檢測以及給出問題根因, 并且該系統(tǒng)做到了對正常轉(zhuǎn)發(fā)業(yè)務(wù)的無影響, 性能測試表明,該系統(tǒng)開啟以后, 對用戶正常業(yè)務(wù)的轉(zhuǎn)發(fā)影響可以控制在1%以內(nèi). 該系統(tǒng)已經(jīng)在超融合生產(chǎn)環(huán)境持續(xù)運(yùn)行了3年, 幫助用戶以及網(wǎng)絡(luò)運(yùn)維人員解決了諸多虛擬網(wǎng)絡(luò)故障問題.

接下來的部分將對Flowprobe系統(tǒng)進(jìn)行詳細(xì)的介紹. 第2節(jié)將介紹研究背景, 針對超融合設(shè)備、SDN網(wǎng)絡(luò)、DPDK、網(wǎng)絡(luò)遙測技術(shù)等進(jìn)行簡明的闡述. 第3節(jié)將介紹相關(guān)工作. 第4節(jié)將具體介紹Flowprobe的系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn). 第5節(jié)對Flowprobe系統(tǒng)進(jìn)行了詳細(xì)的功能和性能評估. 最后在第6節(jié), 對工作進(jìn)行了總結(jié),并討論了以后的演進(jìn)方向.

2 研究背景

2.1 超融合與超融合云網(wǎng)絡(luò)

超融合是一種 IT 基礎(chǔ)架構(gòu)解決方案, 將計(jì)算、存儲(chǔ)和網(wǎng)絡(luò)資源整合在一個(gè)統(tǒng)一系統(tǒng)中. 超融合基礎(chǔ)架構(gòu)由計(jì)算資源(虛擬機(jī))、軟件定義存儲(chǔ)和軟件定義網(wǎng)絡(luò)組成, 并使用超級資源管理器(hypervisor)進(jìn)行統(tǒng)一管理和配置[14].

超融合設(shè)備可以認(rèn)為是當(dāng)前虛擬化技術(shù)的集大成者, 在超融合設(shè)備中會(huì)使用到計(jì)算虛擬化、網(wǎng)絡(luò)虛擬化、存儲(chǔ)虛擬化等多種虛擬化技術(shù). 一般而言, 主流的開源超融合虛擬化實(shí)現(xiàn)方案是基于KVM與QEMU來實(shí)現(xiàn)的.

圖1是HCI的一般架構(gòu)圖[15]. HCI會(huì)集成計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)、安全等功能, 并且可以構(gòu)建平臺(tái)即服務(wù)(platform as a service, PaaS)和基礎(chǔ)設(shè)施即服務(wù) (infrastructure as a service, IaaS)平臺(tái). 在PaaS和IaaS的基礎(chǔ)之上提供多種多樣的應(yīng)用服務(wù). HCI基礎(chǔ)設(shè)施既包括軟件也包括硬件, 因此它擁有硬件管理服務(wù)和軟件定義基礎(chǔ)設(shè)施管理服務(wù), 通過這兩種服務(wù), 用戶可以對平臺(tái)資源進(jìn)行管理和調(diào)度, 構(gòu)建集群, 進(jìn)行高可用配置等. 平臺(tái)自身一般會(huì)提供REST API接口, 并可以與第三方軟件進(jìn)行集成.

圖1 HCI功能架構(gòu)

借助于虛擬化, HCI可以為用戶提供靈活便捷的基礎(chǔ)設(shè)施管理和配置方式. 如深信服的HCI設(shè)備提供豐富的網(wǎng)絡(luò)虛擬化功能, 包括分布式虛擬交換機(jī)、虛擬路由器、分布式虛擬防火墻、虛擬負(fù)載均衡器、虛擬上網(wǎng)行為管理設(shè)備等, 并且提供一個(gè)“畫布”, 在上面可以通過簡單的拖拽、點(diǎn)擊、連線就可以構(gòu)建出一個(gè)包括上述各種虛擬網(wǎng)元的完整可用網(wǎng)絡(luò).

鑒于HCI的高度虛擬化和便捷的管理特性, 用戶可以基于HCI來很方便、快捷地構(gòu)建自身的私有云或者混合云環(huán)境. 圖2是一個(gè)基于HCI設(shè)備搭建的簡單的云網(wǎng)絡(luò)示例. 從圖中我們可以看出基于HCI構(gòu)建的私有云或者混合云網(wǎng)絡(luò)可以被清晰地分為兩部分: 虛擬網(wǎng)絡(luò)部分和物理網(wǎng)絡(luò)部分. 物理網(wǎng)絡(luò)用來連接一個(gè)個(gè)HCI設(shè)備. 其中在虛擬網(wǎng)絡(luò)中, 會(huì)區(qū)分不同的租戶.當(dāng)網(wǎng)絡(luò)發(fā)生故障時(shí), 針對物理網(wǎng)絡(luò), 網(wǎng)絡(luò)運(yùn)維人員可以使用豐富的排障工具包進(jìn)行問題定位, 但是這些工具并不能很好地應(yīng)用到虛擬網(wǎng)絡(luò)中, 因此, 針對虛擬網(wǎng)絡(luò)需要設(shè)計(jì)專門的排障工具或者系統(tǒng).

圖2 基于HCI構(gòu)建的云網(wǎng)絡(luò)示例

本文提出的Flowprobe即是針對上述HCI網(wǎng)絡(luò)結(jié)構(gòu)設(shè)計(jì)的持續(xù)性丟包檢測與分析系統(tǒng).

2.2 SDN網(wǎng)絡(luò)

SDN網(wǎng)絡(luò)有3大特征, 分別是[6]:

1) 集中式控制.

2) 控制功能與轉(zhuǎn)發(fā)功能分離.

3) 可編程.

為了提升虛擬網(wǎng)絡(luò)的轉(zhuǎn)發(fā)性能以及方便虛擬網(wǎng)絡(luò)的管理, HCI內(nèi)部的網(wǎng)絡(luò)一般采用SDN架構(gòu). SDN控制器也即HCI網(wǎng)絡(luò)的管理平面可以獲知虛擬網(wǎng)絡(luò)的拓?fù)湫畔?、配置信息? 可以完成路由計(jì)算、網(wǎng)絡(luò)負(fù)載均衡、設(shè)備主備切換等功能. 因此, 借助于SDN控制器可以進(jìn)行網(wǎng)絡(luò)排障分析, Flowprobe系統(tǒng)的路徑計(jì)算即是借助于SDN控制器中信息來完成的.

2.3 用戶態(tài)數(shù)據(jù)面與DPDK

圖3是用戶態(tài)數(shù)據(jù)面和內(nèi)核態(tài)數(shù)據(jù)面接收數(shù)據(jù)包的流向示意圖(數(shù)據(jù)包發(fā)送為相反方向). 數(shù)據(jù)包被網(wǎng)卡接收以后直到被應(yīng)用(圖中為VM, 即虛擬機(jī))處理,需要經(jīng)過宿主機(jī)也即(HCI內(nèi)核系統(tǒng))的數(shù)據(jù)包轉(zhuǎn)發(fā).

圖3 用戶態(tài)數(shù)據(jù)面和內(nèi)核態(tài)數(shù)據(jù)面接收數(shù)據(jù)包數(shù)據(jù)包流向

經(jīng)典的網(wǎng)絡(luò)轉(zhuǎn)發(fā)是由Linux內(nèi)核網(wǎng)絡(luò)協(xié)議棧來完成的, 在網(wǎng)絡(luò)協(xié)議棧中, 數(shù)據(jù)包被重新進(jìn)行校驗(yàn)、拼接、信息統(tǒng)計(jì)等, 上述操作都通過的數(shù)據(jù)包然后被由內(nèi)核空間再復(fù)制到用戶空間, 進(jìn)而傳送到VM內(nèi). 該過程比較繁瑣, 此外, 由于涉及到了數(shù)據(jù)包拷貝, 因此還會(huì)有一定的性能損耗.

用戶態(tài)數(shù)據(jù)面位于Linux的用戶空間(user space),圖3中的用戶態(tài)數(shù)據(jù)面是基于DPDK來實(shí)現(xiàn)的, DPDK并非用戶態(tài)數(shù)據(jù)面所必須, 但基于DPDK的用戶態(tài)數(shù)據(jù)面可以獲得非常好的性能, 并且也在生產(chǎn)環(huán)境中得到了廣泛的應(yīng)用. 數(shù)據(jù)包由物理網(wǎng)卡直接透傳到用戶態(tài)數(shù)據(jù)面, 并不會(huì)經(jīng)過內(nèi)核態(tài)空間, 該過程會(huì)利用到零拷貝、直接內(nèi)存訪問 (direct memory access, DMA)等技術(shù), 因此不會(huì)存在由內(nèi)核空間向用戶態(tài)空間進(jìn)行數(shù)據(jù)拷貝的操作. 一般而言, 用戶態(tài)數(shù)據(jù)面專注于L2/L3轉(zhuǎn)發(fā), 比較少有L4的處理, 因?yàn)樘摂M網(wǎng)絡(luò)的主要職責(zé)在于進(jìn)行高速數(shù)據(jù)轉(zhuǎn)發(fā), 并不會(huì)有過多進(jìn)行L4及以上層的數(shù)據(jù)包解析的需求.

DPDK是Intel推出的高性能數(shù)據(jù)面開發(fā)套件. 為了取得加速數(shù)據(jù)包轉(zhuǎn)發(fā), DPDK做了一系列的優(yōu)化, 如基于輪詢的收發(fā)包驅(qū)動(dòng)(poll mode driver, PMD), 使用大頁內(nèi)存, 增加CPU的親和性, 重新設(shè)計(jì)數(shù)據(jù)包緩存結(jié)構(gòu)等. 實(shí)驗(yàn)表明基于DPDK實(shí)現(xiàn)的網(wǎng)絡(luò)轉(zhuǎn)發(fā)面的性能可以10倍于普通的基于內(nèi)核的網(wǎng)絡(luò)轉(zhuǎn)發(fā)面. 因此DPDK在生產(chǎn)環(huán)境中得到了廣泛地應(yīng)用. 此外DPDK應(yīng)用完全運(yùn)行于用戶態(tài)空間, 相對于運(yùn)行于內(nèi)核空間的轉(zhuǎn)發(fā)面會(huì)具備更加好的穩(wěn)定性, 即使其發(fā)生故障也不會(huì)引起整個(gè)系統(tǒng)的崩潰.

基于DPDK的轉(zhuǎn)發(fā)賦予了開發(fā)者靈活的開發(fā)能力, 使得開發(fā)者可以根據(jù)自己的需要實(shí)現(xiàn)數(shù)據(jù)面轉(zhuǎn)發(fā)能力. 這也導(dǎo)致基于DPDK的數(shù)據(jù)轉(zhuǎn)發(fā)面相對于基于內(nèi)核的轉(zhuǎn)發(fā)面沒有那么標(biāo)準(zhǔn)統(tǒng)一, 增大了使用者和網(wǎng)絡(luò)運(yùn)維人員的維護(hù)成本. 事實(shí)上, 很少有使用者或者網(wǎng)絡(luò)運(yùn)維人員能理解DPDK技術(shù)以及基于該技術(shù)實(shí)現(xiàn)的轉(zhuǎn)發(fā)應(yīng)用的工作原理, 因?yàn)榻y(tǒng)一的、規(guī)范的資料比較少, 并且需要較深的專業(yè)背景. 基于DPDK開發(fā)的轉(zhuǎn)發(fā)應(yīng)用或者虛擬網(wǎng)絡(luò)需要像基于內(nèi)核的網(wǎng)絡(luò)轉(zhuǎn)發(fā)面一樣可以有很多方便的工具來進(jìn)行監(jiān)控和檢測, 使得使用者及網(wǎng)絡(luò)運(yùn)維人員能夠直觀地了解基于DPDP開發(fā)的網(wǎng)絡(luò)轉(zhuǎn)發(fā)應(yīng)用的運(yùn)行狀態(tài), 才能降低使用者的門檻, 方便他們的使用. 但這些運(yùn)維工具恰恰是當(dāng)前DPDK生態(tài)所欠缺的.

本文提出了一種針對基于DPDK實(shí)現(xiàn)的虛擬網(wǎng)絡(luò)轉(zhuǎn)發(fā)面的持續(xù)性丟包檢測系統(tǒng), 其目的即在于方便用戶以及網(wǎng)絡(luò)運(yùn)維人員能夠直觀地看到數(shù)據(jù)包在虛擬網(wǎng)絡(luò)中的詳細(xì)轉(zhuǎn)發(fā)路徑、丟包發(fā)生位置、丟包原因等, 大大降低他們維護(hù)基于DPDK的虛擬網(wǎng)絡(luò)的門檻和時(shí)間.

3 相關(guān)工作

隨著虛擬化技術(shù)的深層次化地引入, 云計(jì)算網(wǎng)絡(luò)也變得越來越復(fù)雜, 如網(wǎng)元數(shù)目呈指數(shù)級增長, 網(wǎng)元種類也越來越多. 在此背景下, 當(dāng)網(wǎng)絡(luò)出現(xiàn)性能下降或者故障時(shí), 如何定位網(wǎng)絡(luò)故障, 以及進(jìn)行網(wǎng)絡(luò)性能分析就變得十分困難. 這就使得高效、靈活的網(wǎng)絡(luò)故障感知、定位變得越來越重要. 高效、靈活的網(wǎng)絡(luò)運(yùn)維技術(shù)可以大大提高網(wǎng)絡(luò)的管理和維護(hù)的效率, 進(jìn)而帶來巨大的經(jīng)濟(jì)價(jià)值.

傳統(tǒng)的網(wǎng)絡(luò)故障檢測工具, 如ping、traceroute等,可以對網(wǎng)絡(luò)狀態(tài)進(jìn)行一定的探查, 如查看源/目的端的網(wǎng)絡(luò)是否處于正常連接狀態(tài), 源到目的的簡單路徑信息顯示等. 但這種簡單地網(wǎng)絡(luò)狀態(tài)探知已經(jīng)不能滿足當(dāng)前云計(jì)算網(wǎng)絡(luò), 尤其是虛擬網(wǎng)絡(luò)的需要. 為此, 在業(yè)界和學(xué)術(shù)界對網(wǎng)絡(luò)狀態(tài)或者故障探測一直都有著廣泛深入的研究.

微軟提出了Everflow技術(shù)來解決數(shù)據(jù)中心丟包、時(shí)延的檢測和根因分析問題[16]. Everflow設(shè)計(jì)了功能強(qiáng)大的數(shù)據(jù)包過濾器, 允許用戶設(shè)置匹配規(guī)則, 然后將這些規(guī)則下發(fā)到交換機(jī)上對指定類型的數(shù)據(jù)包進(jìn)行鏡像. 通過負(fù)載均衡操作將鏡像的數(shù)據(jù)包分散到多個(gè)處理服務(wù)器, 提高數(shù)據(jù)分析處理的速度. 云杉網(wǎng)絡(luò)認(rèn)為高級的網(wǎng)絡(luò)管理功能依賴于詳細(xì)的網(wǎng)絡(luò)流量分析, 為此,他們提出了一種基于策略的網(wǎng)絡(luò)流量鏡像方案[17]. 在該方案中, 他們提出了一種創(chuàng)新的流量分類算法, 以加快策略的匹配速度, 同時(shí)降低性能損耗.

傳統(tǒng)的探測手段一般都屬于帶外探測技術(shù), 帶外探測技術(shù)實(shí)現(xiàn)簡單、靈活, 但獲取的信息并不精確. 基于流量鏡像的技術(shù)雖然可以獲取到最詳細(xì)的網(wǎng)絡(luò)信息,但性能開銷大, 產(chǎn)生的數(shù)據(jù)量也大, 需要付出大量的計(jì)算資源去處理流量信息, 對于很多網(wǎng)絡(luò)場景并不適用.為了精準(zhǔn)探測網(wǎng)絡(luò)狀態(tài)、對網(wǎng)絡(luò)故障進(jìn)行快速定位,并在一定程度上降低信息采集時(shí)的性能損耗. 思科和華為提出了INT技術(shù)[8-10]. 通過INT技術(shù), 網(wǎng)絡(luò)的數(shù)據(jù)平面可以收集和上報(bào)網(wǎng)絡(luò)的詳細(xì)運(yùn)行狀態(tài), 而無需進(jìn)行數(shù)據(jù)包鏡像. 在INT架構(gòu)中, 數(shù)據(jù)包在其頭部包含有可以被網(wǎng)絡(luò)設(shè)備解析的遙感指令. 根據(jù)這些遙感指令,INT使能的網(wǎng)絡(luò)設(shè)備可以知道收集何種信息, 并將這些信息寫入流經(jīng)它的數(shù)據(jù)包內(nèi). INT流量源(traffic sources, 包括但不限于網(wǎng)絡(luò)應(yīng)用、主機(jī)網(wǎng)絡(luò)協(xié)議棧、超級管理器、網(wǎng)卡、發(fā)送方交換機(jī)等)可以將遙感指令嵌入到正常的數(shù)據(jù)包中, 或者特殊的探針包(probe packets)中. 在INT流量目的地(traffic sinks)中, 收集到的信息被從數(shù)據(jù)包中提取出來, 借此INT技術(shù)可以監(jiān)控?cái)?shù)據(jù)平面的運(yùn)行狀態(tài). 經(jīng)典的INT技術(shù)是將探測信息封裝到探測包之中, 但這種方式受限于數(shù)據(jù)包的大小, 以及路徑的MTU等, 導(dǎo)致這種方式的INT技術(shù)無法探測比較長的路徑, 如基于這種技術(shù)架構(gòu)實(shí)現(xiàn)INT技術(shù)的華為交換機(jī)最大只能支持8跳探測[18]. 為此, 華為提出了Postcard模式的INT技術(shù)[19], 即探測包僅封裝探測指令, 每個(gè)INT使能的網(wǎng)元接收到探測包以后, 解析指令信息, 然后根據(jù)探測指令收集所需探測信息, 最后將探測信息額外封裝到另一個(gè)數(shù)據(jù)包之中,上傳到控制器. 阿里云在自己的Overlay網(wǎng)絡(luò)上實(shí)現(xiàn)了一套持續(xù)性丟包檢測系統(tǒng)—vTrace[20], 該系統(tǒng)可以自動(dòng)發(fā)現(xiàn)阿里云Overlay網(wǎng)絡(luò)發(fā)生持續(xù)性丟包的位置以及丟包的原因, 其實(shí)現(xiàn)原理與華為的Postcard模式的INT技術(shù)原理類似. 文獻(xiàn)[21]中, 作者針對云計(jì)算網(wǎng)絡(luò)基于Open vSwitch的流表設(shè)計(jì)了一種可行的INT技術(shù)方案, 但該方案的性能損耗比較大.

如上所述, INT技術(shù)會(huì)帶來額外的開銷, 影響網(wǎng)絡(luò)流的處理時(shí)間, 增加了處理時(shí)延, 進(jìn)而會(huì)影響應(yīng)用層面的網(wǎng)絡(luò)性能. 為此, 在文獻(xiàn)[22]中, 作者提出了一種統(tǒng)計(jì)型INT技術(shù), 它將探測信息編碼到多個(gè)數(shù)據(jù)包之中,最大可以將額外開銷降低到1 bit每數(shù)據(jù)包. 在文獻(xiàn)[23]中, 作者提出了一種基于sketchlets的INT探測系統(tǒng),sketchlet是他們精心設(shè)計(jì)的數(shù)據(jù)結(jié)構(gòu), 該數(shù)據(jù)結(jié)構(gòu)可以嵌入到數(shù)據(jù)包之中, 隨數(shù)據(jù)包進(jìn)行轉(zhuǎn)發(fā)和信息收集, 該數(shù)據(jù)結(jié)構(gòu)的大小是固定的, 在轉(zhuǎn)發(fā)過程中并不會(huì)一直增大, 這在很大程度上解決了INT技術(shù)的可擴(kuò)展性和性能損耗問題.

借鑒于INT技術(shù)的思想, 我們針對基于超融合設(shè)備構(gòu)建的云計(jì)算網(wǎng)絡(luò)設(shè)計(jì)了一套持續(xù)性丟包檢測系統(tǒng),該系統(tǒng)可以發(fā)現(xiàn)超融合虛擬網(wǎng)絡(luò)中的持續(xù)性丟包的位置, 并給出丟包的原因. 該系統(tǒng)是一種帶外探測技術(shù),但為了接近帶內(nèi)探測的效果, 我們支持探測包可定制,用戶可以通過參數(shù)來配置探測包, 以最大程度地接近自己的業(yè)務(wù)包, 詳細(xì)設(shè)計(jì)見第4節(jié).

4 系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)

4.1 系統(tǒng)架構(gòu)

圖4為Flowprobe的總體架構(gòu)示意圖. 由圖可知,Flowprobe是一個(gè)典型的分布式CS (client-server)系統(tǒng), 其中包括中央控制器(Flowprobe controller)、分布在各個(gè)HCI宿主機(jī)上的代理(Flowprobe agent)、以及在每一個(gè)HCI轉(zhuǎn)發(fā)面中的虛擬探針(vProbe).Flowprobe controller負(fù)責(zé)接收用戶的探測請求, 處理用戶的探測配置, 將探測配置和命令下發(fā)到Flowprobe agent, 接收來自于Flowprobe agent的探測信息, 對探測信息進(jìn)行路徑的拼裝, 將探測信息進(jìn)行存儲(chǔ), 向上層應(yīng)用提供API接口供前端或者第三方應(yīng)用調(diào)用等.

圖4 Flowprobe總體架構(gòu)示意圖

Flowprobe agent主要負(fù)責(zé)接收來自Flowprobe controller的探測指令, 根據(jù)指令構(gòu)造探測包, 將探測包注入到HCI數(shù)據(jù)轉(zhuǎn)發(fā)面, 并接受來自轉(zhuǎn)發(fā)面vProbe的探測信息, 將探測信息進(jìn)行打包上傳到Flowprobe controller. Flowprobe agent與Flowprobe controller之間使用RPC (remote process call)進(jìn)行通信. vProbe的主要作用在于識別探測包, 根據(jù)探測包中的指令信息將數(shù)據(jù)面對探測包的轉(zhuǎn)發(fā)行為進(jìn)行記錄并上傳到本地Flowprobe agent. vProbe與Flowprobe agent之間使用UNIX socket進(jìn)行通信.

圖5是Flowprobe的一個(gè)探測示例, 下面將以該示例說明Flowprobe的工作流程.

圖5 Flowprobe系統(tǒng)探測示例

用戶從UI (user interface)界面配置探測包, 并開啟Flowprobe探測功能. 隨后用戶的配置被向下傳遞到Flowprobe controller, Flowprobe controller對配置進(jìn)行合法性檢查、格式化等, 然后將探測包配置信息下發(fā)到探測發(fā)起HCI的Flowprobe agent.

Flowprobe agent根據(jù)配置信息構(gòu)造出探測數(shù)據(jù)包.探測數(shù)據(jù)包從位于用戶虛擬機(jī)機(jī)1 (VM 1)和虛擬防火墻(vFirewall 1)之間的虛擬鏈路(vlink)注入, 隨后探測數(shù)據(jù)包在各個(gè)網(wǎng)元之間被進(jìn)行轉(zhuǎn)發(fā), 分別經(jīng)過

vSwitch 1, vRouter 1, vSwitch 2, vRouter 2, vSwitch 3,vFirewall 2. 探測數(shù)據(jù)包經(jīng)過的各個(gè)網(wǎng)元分別將自身的設(shè)備信息、對數(shù)據(jù)包執(zhí)行的網(wǎng)絡(luò)行為利用UNIX socket傳遞給本地Flowprobe agent, 最后這些信息被Flowprobe agent進(jìn)行格式化被上傳到Flowprobe controller.

Flowprobe controller進(jìn)行信息處理(關(guān)聯(lián)、去冗余等)和路徑重建以后, 將探測信息存入到數(shù)據(jù)庫中. 前端或者第三方應(yīng)用可以通過標(biāo)準(zhǔn)API或者CLI接口對數(shù)據(jù)庫進(jìn)行訪問, 對結(jié)果進(jìn)行可視化展示.

值得注意的是, 在探測數(shù)據(jù)包到達(dá)vFirewall 2時(shí),vFirewall 2在完成自身信息和網(wǎng)絡(luò)行為(送達(dá))的統(tǒng)計(jì)和上傳以后, 即將探測數(shù)據(jù)包丟棄, 而并不將其轉(zhuǎn)發(fā)進(jìn)用戶虛擬機(jī)2 (VM 2). 由整個(gè)探測過程可知, 探測包不會(huì)由用戶虛擬機(jī)發(fā)出, 也不會(huì)進(jìn)入到用戶虛擬機(jī). 如此以來, 可以最大程度降低對用戶虛擬機(jī)工作負(fù)載的干擾.

在接下來的第4.2節(jié)和第4.3節(jié), 將對詳細(xì)的系統(tǒng)設(shè)計(jì)進(jìn)行闡述, 以揭示系統(tǒng)設(shè)計(jì)時(shí)對高性能、低干擾和信息完全性的考慮. 第4.2節(jié)介紹了Flowprobe agent和vProbe的設(shè)計(jì), 第4.3節(jié)介紹了Flowprobe controller的詳細(xì)架構(gòu).

4.2 Flowprobe agent與vProbe

Flowprobe agent和vProbe的詳細(xì)架構(gòu)如圖6所示.從圖中可知, Flowprobe agent由4個(gè)模塊組成, 分別是:指令接收模塊(instructions receiving from controller)、探測包構(gòu)造模塊(probing packet construction)、數(shù)據(jù)包注入和信息接收模塊(packet injection and information receiving)以及探測信息上傳模塊(probing information uploading). vProbes則由兩部分組成: 探測包識別與處理模塊(probing packet identification and processing)、探測信息上傳模塊(probing information uploading). 下面就各個(gè)模塊功能進(jìn)行介紹.

圖6 Flowprobe agent和vProbe詳細(xì)功能架構(gòu)

指令接收模塊(instructions receiving from controller):主要負(fù)責(zé)接收來自控制器的探測指令. 探測包構(gòu)造模塊根據(jù)這些指令來構(gòu)造探測包. 這些指令包括探測包類型、探測包包頭配置信息、探測包負(fù)載需要攜帶的指令信息、數(shù)據(jù)面DPI功能開啟指令等. 當(dāng)前探測包支持的數(shù)據(jù)包類型以及可配置項(xiàng)如表1所示. 通過豐富的可配置項(xiàng)支持, 構(gòu)造的探測包可以最大程度地接近用戶業(yè)務(wù)包, 從而保證探測包在虛擬網(wǎng)絡(luò)中經(jīng)歷的網(wǎng)元行為、經(jīng)過的路徑等與業(yè)務(wù)包一致, 使得探測結(jié)果更加準(zhǔn)確.

表1 探測包類型及可配置項(xiàng)

探測包構(gòu)造模塊(probing packet construction): 該模塊根據(jù)探測指令中的配置信息來構(gòu)造探測包, 在設(shè)計(jì)系統(tǒng)過程中, 我們使用了開源的Scapy庫[24]來實(shí)現(xiàn)探測包的構(gòu)造. 構(gòu)造探測包的過程中要實(shí)現(xiàn)探測包的“染色”, 以使得數(shù)據(jù)面可以區(qū)分探測包與正常數(shù)據(jù)包. 數(shù)據(jù)面在高效快速地區(qū)分出探測包和正常數(shù)據(jù)包之后可以對探測包和正常業(yè)務(wù)包分別進(jìn)行處理, 因此, 良好的探測包“染色”方案可以降低探測過程對數(shù)據(jù)面的轉(zhuǎn)發(fā)性能的影響. 因此, 我們設(shè)計(jì)了一種創(chuàng)新的探測包“染色”方案來達(dá)到上述目的. 該方案將在第4.2.1節(jié)進(jìn)行闡述.

數(shù)據(jù)包注入和信息接收模塊(packet injection and information receiving): 主要負(fù)責(zé)將探測包注入到數(shù)據(jù)面, 接收來自數(shù)據(jù)面的探測信息.

探測包識別與處理模塊(probing packet identification and processing): 該模塊位于數(shù)據(jù)面, 主要區(qū)分探測包和正常業(yè)務(wù)包, 隨之對探測包進(jìn)行DPI (deep packet inspection)解析, 得到探測包負(fù)載(payload)中的探測指令, 根據(jù)指令收集探測包經(jīng)歷的網(wǎng)元轉(zhuǎn)發(fā)信息, 并將這些信息進(jìn)行格式化封裝. 探測包識別和處理的詳細(xì)流程將在第4.2.2節(jié)進(jìn)行闡述.

探測信息上傳模塊(probing information uploading): 該模塊主要負(fù)責(zé)將探測信息向上進(jìn)行傳遞. vProbe中的該模塊將探測信息通過UNIX socket傳遞給Flowprobe agent. Flowprobe agent中的該模塊通過RPC將探測信息傳遞給Flowprobe controller.

4.2.1 探測包染色方案

本小節(jié)將詳細(xì)闡述探測包的“染色”方案. 如前所述,探測包支持IPv4和IPv6兩種類型, 因此, 探測包“染色”方案也分為兩種. 如圖7所示, 為IPv4探測包的包結(jié)構(gòu)示意圖. 我們選擇IPv4包頭中DSCP (differentiated services code point, 區(qū)分服務(wù)比特)位中的2個(gè)保留位(reserved bits)中的一個(gè)作為染色位, 具體而言, 我們選擇最后一位作為染色位. 保留位的值通常為0, 我們將其改為1, 以標(biāo)識該IPv4數(shù)據(jù)包位探測包.

圖7 IPv4探測包解構(gòu)示意圖

IPv6數(shù)據(jù)包頭結(jié)構(gòu)與IPv4的大不相同, 其中并沒有DSCP位. 針對IPv6類型的探測包, 可用于標(biāo)記探測包的方案有3種:

1) 使用特殊的IPv6地址.

2) 使用IPv6包頭中flow label中的某一比特.

3) 使用特殊的擴(kuò)展頭.

但方案1有IP沖突的風(fēng)險(xiǎn), 并且可擴(kuò)展性差. 方案2中flow label位目前使用還不規(guī)范, 容易和外部物理網(wǎng)絡(luò)起沖突. 因此, 綜合可靠性和可擴(kuò)展性, 我們使用IPv6擴(kuò)展頭中的比特位來作為染色標(biāo)記. 具體而言, 我們使用IPv6擴(kuò)展頭中的hop-by-hop擴(kuò)展頭, 該類型擴(kuò)展頭的結(jié)構(gòu)如圖8中展示. Options是可變長的, 通常必須是64比特的整數(shù)倍, 并且由0進(jìn)行填充. 我們將填充位中的最后一個(gè)0變?yōu)?來作為探測包的染色位.

圖8 IPv6探測包解構(gòu)示意圖

在DPDK轉(zhuǎn)發(fā)中, 使用rte_mbuf存儲(chǔ)數(shù)據(jù)包[25],也即DPDK轉(zhuǎn)發(fā)面需要首先解析rte_mbuf, 再進(jìn)行rte_mbuf中數(shù)據(jù)包信息的解析, 因此, 如果能提早識別出探測包rte_mbuf, 那么就只需對探測包rte_mbuf進(jìn)行信息解析. 圖9是DPDK rte_mbuf的數(shù)據(jù)結(jié)構(gòu), 圖中mbuf struct存儲(chǔ)了該mbuf的元信息, 并且有一些自定義字段可供使用, 因此我們在mbuf struct中定義了一個(gè)字段來表明該rte_mbuf中的數(shù)據(jù)包是探測包, 可以對該rte_mbuf進(jìn)行DPI操作.

圖9 DPDK rte_mbuf結(jié)構(gòu)示意圖

結(jié)合DPDK轉(zhuǎn)發(fā)的特點(diǎn), IPv4及IPv6數(shù)據(jù)包的特點(diǎn), Flowprobe系統(tǒng)設(shè)計(jì)了上述探測包“染色”方案. 該染色方案可以使得數(shù)據(jù)面快速、準(zhǔn)確地識別出探測包,并在之后僅對探測包執(zhí)行DPI操作, 以獲得探測包負(fù)載中的指令信息. 這樣, 最大程度地降低了對正常業(yè)務(wù)轉(zhuǎn)發(fā)性能的影響.

4.2.2 探測包識別與探測信息處理

探測包負(fù)載中包含的信息以及含義如表2所示.

表2 探測包負(fù)載信息項(xiàng)及含義

表2中MsgID是數(shù)據(jù)包被丟棄原因的標(biāo)識碼, 通過查表可以得到數(shù)據(jù)包被丟棄的具體原因. PktIndex記錄了當(dāng)前數(shù)據(jù)包經(jīng)過的虛擬網(wǎng)絡(luò)設(shè)備的個(gè)數(shù), 探測數(shù)據(jù)包每經(jīng)過一個(gè)虛擬網(wǎng)絡(luò)設(shè)備該值加1并更新到探測包負(fù)載中的指令信息之中. 可以根據(jù)該值確定探測包經(jīng)過各個(gè)虛擬網(wǎng)絡(luò)設(shè)備的順序, 并以此計(jì)算出探測包在轉(zhuǎn)發(fā)面經(jīng)歷的轉(zhuǎn)發(fā)路徑. Flowprobe系統(tǒng)在每次丟包探測過程中均會(huì)發(fā)送多個(gè)探測包, 以增強(qiáng)可靠性, 同時(shí)也方便計(jì)算丟包率. SeqNum記錄該探測包是一次探測中的第幾個(gè)包, 該值用來區(qū)分上傳的探測信息屬于那個(gè)探測包.

探測包每經(jīng)過一個(gè)虛擬網(wǎng)絡(luò)設(shè)備, 位于數(shù)據(jù)面的vProbe即會(huì)記錄該虛擬網(wǎng)絡(luò)設(shè)備對探測包的操作行為(actions)以及上述探測指令信息, 然后將這些信息單獨(dú)進(jìn)行信息封裝, 通過UNIX socket上傳到Flowprobe agent. 虛擬網(wǎng)絡(luò)探測設(shè)備對探測包的行為主要包括接收、轉(zhuǎn)發(fā)、送達(dá)等.

4.3 Flowprobe controller

Flowprobe控制器的詳細(xì)功能架構(gòu)如圖10所示.

由圖10可知, Flowprobe控制器主要由8個(gè)模塊組成, 各個(gè)功能模塊的主要作用如下.

配置驗(yàn)證模塊(configuration validation): 該模塊主要接收前端傳遞過來的探測配置, 包括探測包的配置信息, 發(fā)起探測的用戶信息等, 并對這些配置信息進(jìn)行合法性以及安全性校驗(yàn).

接口處理模塊(interface handler): 該模塊主要負(fù)責(zé)實(shí)現(xiàn)對外開放的接口, 如圖10中的UI接口、CLI接口、API接口等.

圖10 Flowprobe控制器詳細(xì)功能架構(gòu)

配置處理模塊(configuration processing): 該模塊主要負(fù)責(zé)對接收到的探測配置進(jìn)行處理, 如格式轉(zhuǎn)換、信息關(guān)聯(lián)等. 從圖10中可以看出, 配置驗(yàn)證和配置處理模塊分別位于RPC客戶端(RPC client)和RPC服務(wù)端(RPC server), 這是因?yàn)镕lowprobe controller做了異步處理設(shè)計(jì), RPC客戶端中的配置驗(yàn)證模塊在完成對配置的檢查以后即將結(jié)果返回給前端, 若檢查通過則告知用戶等待探測結(jié)果, 若檢查未通過則告訴用戶校驗(yàn)輸入?yún)?shù)并重新發(fā)起探測. 這種異步處理方式可以使得前端可以快速響應(yīng), 并實(shí)現(xiàn)前端展示與后端探測的解耦, 提升系統(tǒng)的模塊化設(shè)計(jì), 降低系統(tǒng)的耦合性.

網(wǎng)絡(luò)拓?fù)涮幚砟K(network topology handler): 該模塊主要負(fù)責(zé)與SDN控制器進(jìn)行通信, 獲得虛擬網(wǎng)絡(luò)的拓?fù)浣Y(jié)構(gòu), 以便于探測信息相結(jié)合進(jìn)行探測路徑的重建.

數(shù)據(jù)面DPI處理模塊(DP DPI handler): 該模塊主要負(fù)責(zé)控制數(shù)據(jù)面DPI功能的開啟和關(guān)閉. DPI功能是會(huì)影響數(shù)據(jù)轉(zhuǎn)發(fā)性能的, 因此不能長期開啟, 需要在探測完成以后及時(shí)關(guān)閉數(shù)據(jù)面中的DPI功能.

指令分發(fā)和信息接收模塊(instructions dispatching and information receiving): 該模塊負(fù)責(zé)將探測包配置信息、探測指令信息、數(shù)據(jù)面DPI控制指令信息等下發(fā)到各個(gè)Flowprobe agent. 此外, 負(fù)責(zé)接收來自各個(gè)Flowprobe agent上傳的探測信息. 該模塊使用Python進(jìn)行實(shí)現(xiàn), 為了加快信息處理速度, 我們使用了Python的多進(jìn)程多協(xié)程模型來實(shí)現(xiàn)高并發(fā)處理.

路徑重建模塊(path reconstruction): 路徑重建負(fù)責(zé)結(jié)合網(wǎng)絡(luò)拓?fù)湫畔⑴c上傳的探測信息重建出探測包在虛擬網(wǎng)絡(luò)中的轉(zhuǎn)發(fā)路徑. 路徑計(jì)算方法如算法1所示.

算法1. 路徑計(jì)算算法1) 根據(jù)TenantID, TaskID將探測信息進(jìn)行分組聚合;2) 根據(jù)PktIndex, 虛擬網(wǎng)絡(luò)設(shè)備轉(zhuǎn)發(fā)行為, 網(wǎng)絡(luò)拓?fù)湫畔?gòu)建虛擬網(wǎng)絡(luò)設(shè)備的鄰接矩陣;3) 在虛擬網(wǎng)絡(luò)設(shè)備構(gòu)建的鄰接矩陣上運(yùn)行簡單路徑計(jì)算算法[26], 得到探測源虛擬機(jī)到目的虛擬機(jī)的完整路徑.

值得一提的是, 在步驟2中, 我們根據(jù)虛擬網(wǎng)絡(luò)設(shè)備的轉(zhuǎn)發(fā)行為以及PktIndex來判斷起始虛擬網(wǎng)絡(luò)設(shè)備、終點(diǎn)虛擬網(wǎng)絡(luò)設(shè)備以及網(wǎng)絡(luò)設(shè)備之間的前后關(guān)系.虛擬網(wǎng)絡(luò)設(shè)備對數(shù)據(jù)包的行為有以下類型: 注入(inject)、接收(in)、轉(zhuǎn)發(fā)(out)、送達(dá)(delivered)、丟棄(drop).其中執(zhí)行“注入”這一行為的虛擬網(wǎng)絡(luò)設(shè)備必是路徑的首節(jié)點(diǎn), 而“丟棄”和“送達(dá)”這兩種行為對應(yīng)的虛擬網(wǎng)絡(luò)設(shè)備必是路徑的末節(jié)點(diǎn), 接收和轉(zhuǎn)發(fā)行為為路徑的中間節(jié)點(diǎn), 對這些中間節(jié)點(diǎn)我們使用PktIndex來確定它們之間的先后順序.

數(shù)據(jù)庫(database): 該模塊主要用來保存探測配置信息、探測結(jié)果等. 前端在接收到RPC客戶端的返回結(jié)果以后(若通過配置檢查, 則成功開啟探測, RPC客戶端會(huì)返回給前端一個(gè)唯一的探測ID, 即表2中的TaskID), 會(huì)根據(jù)TaskID向數(shù)據(jù)庫進(jìn)行輪詢, 一旦探測結(jié)果計(jì)算完成即可立刻返回結(jié)果.

5 系統(tǒng)功能和性能評估

Flowprobe系統(tǒng)在深信服超融合計(jì)算產(chǎn)品中已經(jīng)使用了3年多的時(shí)間, 最新的版本已經(jīng)落地到了深信服的超融合云計(jì)算產(chǎn)品aCloud之中. 該系統(tǒng)經(jīng)過了嚴(yán)格的產(chǎn)品化測試, 針對582種虛擬網(wǎng)絡(luò)持續(xù)丟包故障進(jìn)行了場景化測試, 結(jié)果表明在576個(gè)場景中均可以實(shí)現(xiàn)持續(xù)性丟包檢測. 接下來, 將在第5.1節(jié)對Flowprobe的功能進(jìn)行驗(yàn)證, 在第5.2節(jié)對Flowprobe的性能進(jìn)行評估. 功能驗(yàn)證是在一個(gè)由3臺(tái)HCI設(shè)備構(gòu)建的生產(chǎn)集群上進(jìn)行的, 該集群內(nèi)每一臺(tái)HCI設(shè)備的配置是相同的, CPU配置為: Intel(R) Xeon(R) Platinum 8260 CPU @ 2.40 GHz, 24核, 128 GB內(nèi)存. 性能測試是在一個(gè)額外的HCI主機(jī)上進(jìn)行的, Flowprobe controller和agent所在宿主機(jī)CPU配置為: Intel(R) Xeon(R)CPU E3-1231 v3 @ 3.40 GHz, 8核, 32 GB內(nèi)存.

5.1 Flowprobe系統(tǒng)功能驗(yàn)證

本小節(jié)將對Flowprobe的功能進(jìn)行驗(yàn)證.

如圖11所示為驗(yàn)證Flowprobe功能所用網(wǎng)絡(luò)拓?fù)? 圖中有3個(gè)虛擬機(jī), 3臺(tái)虛擬交換機(jī), 2臺(tái)虛擬路由器. 值得注意的是, 虛擬交換機(jī)具有分布式特性, 也即每一個(gè)虛擬交換機(jī)在每一個(gè)物理宿主機(jī)上都有一個(gè)實(shí)例, 這些實(shí)例之間使用VXLAN進(jìn)行通信和狀態(tài)同步.圖11中的拓?fù)湟晥D由深信服超融合設(shè)備管理界面的“所畫即所得”網(wǎng)絡(luò)管理功能所得. 在該界面上可以通過對各個(gè)虛擬網(wǎng)元的拖動(dòng)、以及連線快速構(gòu)建出所需網(wǎng)絡(luò)架構(gòu). 其中的“連通性探測”功能即是本文中所說Flowprobe系統(tǒng)在深信服超融合產(chǎn)品上的具體實(shí)現(xiàn).

圖11中Centos7-Kafka、Centos7-MongDB、Centos7-Mysql是3個(gè)業(yè)務(wù)虛擬機(jī). 我們首先在網(wǎng)絡(luò)正常的狀態(tài)下由Centos7-Mysql向Centos7-Kafka發(fā)起Flowprobe探測(連通性探測), 結(jié)果如圖12所示. 從圖12的結(jié)果中, 可以清晰地看到探測包在虛擬網(wǎng)絡(luò)中的轉(zhuǎn)發(fā)路徑、各個(gè)虛擬網(wǎng)元的轉(zhuǎn)發(fā)行為、各個(gè)虛擬網(wǎng)元所在的宿主機(jī)等信息.

圖11 Flowprobe功能驗(yàn)證拓?fù)?/p>

圖12 Centos7-Mysql向Centos7-Kafka發(fā)起Flowprobe探測結(jié)果(正常)

接著, 去除邊界路由器1中關(guān)于Centos7-Mysql虛擬機(jī)的路由, 再發(fā)起同樣的探測, 結(jié)果如圖13所示.可以看到, 探測精準(zhǔn)地定位到了出現(xiàn)故障的虛擬網(wǎng)元,以及出現(xiàn)網(wǎng)絡(luò)中斷的原因: 虛擬路由器查詢路由表失敗.

圖13 Centos7-Mysql向Centos7-Kafka發(fā)起Flowprobe探測結(jié)果(邊界路由器1失敗)

最后, 我們恢復(fù)邊界路由器1的路由, 將邊界路由器2與交換機(jī)2的接口禁用, 再發(fā)起同樣的探測, 結(jié)果如圖14所示.

由圖14可見, Flowprobe系統(tǒng)亦可精準(zhǔn)地定位出出問題的路由器以及網(wǎng)絡(luò)中斷的原因.

圖14 Centos7-Mysql向Centos7-Kafka發(fā)起Flowprobe探測結(jié)果(邊界路由器2網(wǎng)口禁用)

上述實(shí)驗(yàn)僅是Flowprobe可探測的持續(xù)性丟包或網(wǎng)絡(luò)中斷場景中的一小部分, 嚴(yán)格的產(chǎn)品化測試流程表明, Flowprobe系統(tǒng)可以對576種虛擬網(wǎng)絡(luò)持續(xù)性丟包或者網(wǎng)絡(luò)中斷場景進(jìn)行探測與故障定位.

5.2 Flowprobe系統(tǒng)性能評估

本小節(jié)將對Flowprobe系統(tǒng)的性能進(jìn)行評估. 圖15、圖16分別是Flowprobe controller和Flowprobe agent的CPU資源消耗, 由圖可知, Flowprobe controller的總體CPU資源消耗約在2.5%, Flowprobe agent的CPU資源利用率小于0.2%.

圖15 Flowprobe controller CPU資源消耗

圖16 Flowprobe agent CPU資源消耗

圖17、圖18分別是Flowprobe controller和Flowprobe agent的內(nèi)存資源消耗. 從圖中可知, Flowprobe controller和Flowprobe agent的內(nèi)存占用分別約為96 MB, 48 MB.

圖17 Flowprobe controller內(nèi)存資源消耗

圖18 Flowprobe agent內(nèi)存資源消耗

除了資源消耗以外, 我們還利用思博倫根據(jù)RFC2544測試了Flowprobe功能開啟前和開啟后DP吞吐量的變化, 表3顯示了測試結(jié)果. 由結(jié)果可見, 開啟Flowprobe前后, DP的最大吞吐量沒有發(fā)生變化. 這其實(shí)與我們精心設(shè)計(jì)的數(shù)據(jù)包標(biāo)記方案有關(guān), 設(shè)計(jì)的標(biāo)記方案最大程度上地減少了DPI的執(zhí)行次數(shù), 盡最大可能地降低了對DP正常轉(zhuǎn)發(fā)性能的影響.

表3 Flowprobe開啟前后DP吞吐量對比

6 結(jié)論與展望

本文設(shè)計(jì)了一種虛擬網(wǎng)絡(luò)持續(xù)性丟包探測系統(tǒng),該系統(tǒng)旨在解決基于DPDK用戶態(tài)虛擬網(wǎng)絡(luò)的持續(xù)性丟包檢測及根因定位問題. 文中詳細(xì)描述了該系統(tǒng)的設(shè)計(jì)思想. 為了減小探測對正常轉(zhuǎn)發(fā)的影響, 我們提出了一系列的優(yōu)化措施, 如精心設(shè)計(jì)的探測包標(biāo)記方案,路徑重建算法等.

該系統(tǒng)未來將持續(xù)進(jìn)行功能和性能的優(yōu)化, 后續(xù)將嘗試將該系統(tǒng)應(yīng)用到安全運(yùn)維領(lǐng)域, 實(shí)現(xiàn)對網(wǎng)絡(luò)功能服務(wù)鏈的轉(zhuǎn)發(fā)路徑驗(yàn)證功能. 另外, 基于該系統(tǒng)實(shí)現(xiàn)虛擬網(wǎng)絡(luò)轉(zhuǎn)發(fā)過程中逐鏈路時(shí)延的探測等.