基于超融合云網絡環境的持續丟包主動探測系統①

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

1(中國科學院 深圳先進技術研究院, 深圳 518055)

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

1 引言

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

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

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

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

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

在設計虛擬網絡故障檢測工具或者系統時, 需要遵循如下3個原則.

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

低干擾: 除了觀察者效應的影響, 設計的檢測或者監控工具/系統在運行時不應該干擾到正常的業務流量, 更不能因為故障檢測導致正常業務崩潰.

信息完全性: 收集到的信息應該足夠全面, 并且分析方法也要全面, 可以多角度地對收集到的信息進行分析并得出結論.

在上述原則下, 本文設計了一種虛擬網絡持續性丟包探測系統: Flowprobe, 該系統可以回答以下問題:

1) 數據包在虛擬網絡中的詳細轉發路徑是什么?是否與其路徑一致.

2) 若發生丟包, 則持續性丟包的虛擬網元或者位置在哪.

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

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

1) 支持定制不同類型的IPv4/IPv6探測包, 如TCP、UDP、ICMP等, 并支持探測包包頭參數和包大小的定制. 支持數據包的定制可以使得探測包更加接近于用戶業務包, 如此一來, 探測包經歷的網絡行為與業務包經歷的網絡行為就更加一致, 得到的探測結果也更加準確.

2) 設計了高效的探測包標記方案. 通過該方案做到了對虛擬網絡數據面正常業務轉發的最小影響.

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

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

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

通過該系統, 用戶可以觀測數據包在虛擬網絡中的詳細路徑、經歷的轉發行為, 定位丟包的位置, 獲知丟包的原因. 實驗表明, 該系統可以針對576種虛擬網絡持續丟包場景進行檢測以及給出問題根因, 并且該系統做到了對正常轉發業務的無影響, 性能測試表明,該系統開啟以后, 對用戶正常業務的轉發影響可以控制在1%以內. 該系統已經在超融合生產環境持續運行了3年, 幫助用戶以及網絡運維人員解決了諸多虛擬網絡故障問題.

接下來的部分將對Flowprobe系統進行詳細的介紹. 第2節將介紹研究背景, 針對超融合設備、SDN網絡、DPDK、網絡遙測技術等進行簡明的闡述. 第3節將介紹相關工作. 第4節將具體介紹Flowprobe的系統設計與實現. 第5節對Flowprobe系統進行了詳細的功能和性能評估. 最后在第6節, 對工作進行了總結,并討論了以后的演進方向.

2 研究背景

2.1 超融合與超融合云網絡

超融合是一種 IT 基礎架構解決方案, 將計算、存儲和網絡資源整合在一個統一系統中. 超融合基礎架構由計算資源(虛擬機)、軟件定義存儲和軟件定義網絡組成, 并使用超級資源管理器(hypervisor)進行統一管理和配置[14].

超融合設備可以認為是當前虛擬化技術的集大成者, 在超融合設備中會使用到計算虛擬化、網絡虛擬化、存儲虛擬化等多種虛擬化技術. 一般而言, 主流的開源超融合虛擬化實現方案是基于KVM與QEMU來實現的.

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

圖1 HCI功能架構

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

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

圖2 基于HCI構建的云網絡示例

本文提出的Flowprobe即是針對上述HCI網絡結構設計的持續性丟包檢測與分析系統.

2.2 SDN網絡

SDN網絡有3大特征, 分別是[6]:

1) 集中式控制.

2) 控制功能與轉發功能分離.

3) 可編程.

為了提升虛擬網絡的轉發性能以及方便虛擬網絡的管理, HCI內部的網絡一般采用SDN架構. SDN控制器也即HCI網絡的管理平面可以獲知虛擬網絡的拓撲信息、配置信息等, 可以完成路由計算、網絡負載均衡、設備主備切換等功能. 因此, 借助于SDN控制器可以進行網絡排障分析, Flowprobe系統的路徑計算即是借助于SDN控制器中信息來完成的.

2.3 用戶態數據面與DPDK

圖3是用戶態數據面和內核態數據面接收數據包的流向示意圖(數據包發送為相反方向). 數據包被網卡接收以后直到被應用(圖中為VM, 即虛擬機)處理,需要經過宿主機也即(HCI內核系統)的數據包轉發.

圖3 用戶態數據面和內核態數據面接收數據包數據包流向

經典的網絡轉發是由Linux內核網絡協議棧來完成的, 在網絡協議棧中, 數據包被重新進行校驗、拼接、信息統計等, 上述操作都通過的數據包然后被由內核空間再復制到用戶空間, 進而傳送到VM內. 該過程比較繁瑣, 此外, 由于涉及到了數據包拷貝, 因此還會有一定的性能損耗.

用戶態數據面位于Linux的用戶空間(user space),圖3中的用戶態數據面是基于DPDK來實現的, DPDK并非用戶態數據面所必須, 但基于DPDK的用戶態數據面可以獲得非常好的性能, 并且也在生產環境中得到了廣泛的應用. 數據包由物理網卡直接透傳到用戶態數據面, 并不會經過內核態空間, 該過程會利用到零拷貝、直接內存訪問 (direct memory access, DMA)等技術, 因此不會存在由內核空間向用戶態空間進行數據拷貝的操作. 一般而言, 用戶態數據面專注于L2/L3轉發, 比較少有L4的處理, 因為虛擬網絡的主要職責在于進行高速數據轉發, 并不會有過多進行L4及以上層的數據包解析的需求.

DPDK是Intel推出的高性能數據面開發套件. 為了取得加速數據包轉發, DPDK做了一系列的優化, 如基于輪詢的收發包驅動(poll mode driver, PMD), 使用大頁內存, 增加CPU的親和性, 重新設計數據包緩存結構等. 實驗表明基于DPDK實現的網絡轉發面的性能可以10倍于普通的基于內核的網絡轉發面. 因此DPDK在生產環境中得到了廣泛地應用. 此外DPDK應用完全運行于用戶態空間, 相對于運行于內核空間的轉發面會具備更加好的穩定性, 即使其發生故障也不會引起整個系統的崩潰.

基于DPDK的轉發賦予了開發者靈活的開發能力, 使得開發者可以根據自己的需要實現數據面轉發能力. 這也導致基于DPDK的數據轉發面相對于基于內核的轉發面沒有那么標準統一, 增大了使用者和網絡運維人員的維護成本. 事實上, 很少有使用者或者網絡運維人員能理解DPDK技術以及基于該技術實現的轉發應用的工作原理, 因為統一的、規范的資料比較少, 并且需要較深的專業背景. 基于DPDK開發的轉發應用或者虛擬網絡需要像基于內核的網絡轉發面一樣可以有很多方便的工具來進行監控和檢測, 使得使用者及網絡運維人員能夠直觀地了解基于DPDP開發的網絡轉發應用的運行狀態, 才能降低使用者的門檻, 方便他們的使用. 但這些運維工具恰恰是當前DPDK生態所欠缺的.

本文提出了一種針對基于DPDK實現的虛擬網絡轉發面的持續性丟包檢測系統, 其目的即在于方便用戶以及網絡運維人員能夠直觀地看到數據包在虛擬網絡中的詳細轉發路徑、丟包發生位置、丟包原因等, 大大降低他們維護基于DPDK的虛擬網絡的門檻和時間.

3 相關工作

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

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

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

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

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

借鑒于INT技術的思想, 我們針對基于超融合設備構建的云計算網絡設計了一套持續性丟包檢測系統,該系統可以發現超融合虛擬網絡中的持續性丟包的位置, 并給出丟包的原因. 該系統是一種帶外探測技術,但為了接近帶內探測的效果, 我們支持探測包可定制,用戶可以通過參數來配置探測包, 以最大程度地接近自己的業務包, 詳細設計見第4節.

4 系統設計與實現

4.1 系統架構

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

圖4 Flowprobe總體架構示意圖

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

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

圖5 Flowprobe系統探測示例

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

Flowprobe agent根據配置信息構造出探測數據包.探測數據包從位于用戶虛擬機機1 (VM 1)和虛擬防火墻(vFirewall 1)之間的虛擬鏈路(vlink)注入, 隨后探測數據包在各個網元之間被進行轉發, 分別經過

vSwitch 1, vRouter 1, vSwitch 2, vRouter 2, vSwitch 3,vFirewall 2. 探測數據包經過的各個網元分別將自身的設備信息、對數據包執行的網絡行為利用UNIX socket傳遞給本地Flowprobe agent, 最后這些信息被Flowprobe agent進行格式化被上傳到Flowprobe controller.

Flowprobe controller進行信息處理(關聯、去冗余等)和路徑重建以后, 將探測信息存入到數據庫中. 前端或者第三方應用可以通過標準API或者CLI接口對數據庫進行訪問, 對結果進行可視化展示.

值得注意的是, 在探測數據包到達vFirewall 2時,vFirewall 2在完成自身信息和網絡行為(送達)的統計和上傳以后, 即將探測數據包丟棄, 而并不將其轉發進用戶虛擬機2 (VM 2). 由整個探測過程可知, 探測包不會由用戶虛擬機發出, 也不會進入到用戶虛擬機. 如此以來, 可以最大程度降低對用戶虛擬機工作負載的干擾.

在接下來的第4.2節和第4.3節, 將對詳細的系統設計進行闡述, 以揭示系統設計時對高性能、低干擾和信息完全性的考慮. 第4.2節介紹了Flowprobe agent和vProbe的設計, 第4.3節介紹了Flowprobe controller的詳細架構.

4.2 Flowprobe agent與vProbe

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

圖6 Flowprobe agent和vProbe詳細功能架構

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

表1 探測包類型及可配置項

探測包構造模塊(probing packet construction): 該模塊根據探測指令中的配置信息來構造探測包, 在設計系統過程中, 我們使用了開源的Scapy庫[24]來實現探測包的構造. 構造探測包的過程中要實現探測包的“染色”, 以使得數據面可以區分探測包與正常數據包. 數據面在高效快速地區分出探測包和正常數據包之后可以對探測包和正常業務包分別進行處理, 因此, 良好的探測包“染色”方案可以降低探測過程對數據面的轉發性能的影響. 因此, 我們設計了一種創新的探測包“染色”方案來達到上述目的. 該方案將在第4.2.1節進行闡述.

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

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

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

4.2.1 探測包染色方案

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

圖7 IPv4探測包解構示意圖

IPv6數據包頭結構與IPv4的大不相同, 其中并沒有DSCP位. 針對IPv6類型的探測包, 可用于標記探測包的方案有3種:

1) 使用特殊的IPv6地址.

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

3) 使用特殊的擴展頭.

但方案1有IP沖突的風險, 并且可擴展性差. 方案2中flow label位目前使用還不規范, 容易和外部物理網絡起沖突. 因此, 綜合可靠性和可擴展性, 我們使用IPv6擴展頭中的比特位來作為染色標記. 具體而言, 我們使用IPv6擴展頭中的hop-by-hop擴展頭, 該類型擴展頭的結構如圖8中展示. Options是可變長的, 通常必須是64比特的整數倍, 并且由0進行填充. 我們將填充位中的最后一個0變為1來作為探測包的染色位.

圖8 IPv6探測包解構示意圖

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

圖9 DPDK rte_mbuf結構示意圖

結合DPDK轉發的特點, IPv4及IPv6數據包的特點, Flowprobe系統設計了上述探測包“染色”方案. 該染色方案可以使得數據面快速、準確地識別出探測包,并在之后僅對探測包執行DPI操作, 以獲得探測包負載中的指令信息. 這樣, 最大程度地降低了對正常業務轉發性能的影響.

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

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

表2 探測包負載信息項及含義

表2中MsgID是數據包被丟棄原因的標識碼, 通過查表可以得到數據包被丟棄的具體原因. PktIndex記錄了當前數據包經過的虛擬網絡設備的個數, 探測數據包每經過一個虛擬網絡設備該值加1并更新到探測包負載中的指令信息之中. 可以根據該值確定探測包經過各個虛擬網絡設備的順序, 并以此計算出探測包在轉發面經歷的轉發路徑. Flowprobe系統在每次丟包探測過程中均會發送多個探測包, 以增強可靠性, 同時也方便計算丟包率. SeqNum記錄該探測包是一次探測中的第幾個包, 該值用來區分上傳的探測信息屬于那個探測包.

探測包每經過一個虛擬網絡設備, 位于數據面的vProbe即會記錄該虛擬網絡設備對探測包的操作行為(actions)以及上述探測指令信息, 然后將這些信息單獨進行信息封裝, 通過UNIX socket上傳到Flowprobe agent. 虛擬網絡探測設備對探測包的行為主要包括接收、轉發、送達等.

4.3 Flowprobe controller

Flowprobe控制器的詳細功能架構如圖10所示.

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

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

接口處理模塊(interface handler): 該模塊主要負責實現對外開放的接口, 如圖10中的UI接口、CLI接口、API接口等.

圖10 Flowprobe控制器詳細功能架構

配置處理模塊(configuration processing): 該模塊主要負責對接收到的探測配置進行處理, 如格式轉換、信息關聯等. 從圖10中可以看出, 配置驗證和配置處理模塊分別位于RPC客戶端(RPC client)和RPC服務端(RPC server), 這是因為Flowprobe controller做了異步處理設計, RPC客戶端中的配置驗證模塊在完成對配置的檢查以后即將結果返回給前端, 若檢查通過則告知用戶等待探測結果, 若檢查未通過則告訴用戶校驗輸入參數并重新發起探測. 這種異步處理方式可以使得前端可以快速響應, 并實現前端展示與后端探測的解耦, 提升系統的模塊化設計, 降低系統的耦合性.

網絡拓撲處理模塊(network topology handler): 該模塊主要負責與SDN控制器進行通信, 獲得虛擬網絡的拓撲結構, 以便于探測信息相結合進行探測路徑的重建.

數據面DPI處理模塊(DP DPI handler): 該模塊主要負責控制數據面DPI功能的開啟和關閉. DPI功能是會影響數據轉發性能的, 因此不能長期開啟, 需要在探測完成以后及時關閉數據面中的DPI功能.

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

路徑重建模塊(path reconstruction): 路徑重建負責結合網絡拓撲信息與上傳的探測信息重建出探測包在虛擬網絡中的轉發路徑. 路徑計算方法如算法1所示.

算法1. 路徑計算算法1) 根據TenantID, TaskID將探測信息進行分組聚合;2) 根據PktIndex, 虛擬網絡設備轉發行為, 網絡拓撲信息構建虛擬網絡設備的鄰接矩陣;3) 在虛擬網絡設備構建的鄰接矩陣上運行簡單路徑計算算法[26], 得到探測源虛擬機到目的虛擬機的完整路徑.

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

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

5 系統功能和性能評估

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

5.1 Flowprobe系統功能驗證

本小節將對Flowprobe的功能進行驗證.

如圖11所示為驗證Flowprobe功能所用網絡拓撲, 圖中有3個虛擬機, 3臺虛擬交換機, 2臺虛擬路由器. 值得注意的是, 虛擬交換機具有分布式特性, 也即每一個虛擬交換機在每一個物理宿主機上都有一個實例, 這些實例之間使用VXLAN進行通信和狀態同步.圖11中的拓撲視圖由深信服超融合設備管理界面的“所畫即所得”網絡管理功能所得. 在該界面上可以通過對各個虛擬網元的拖動、以及連線快速構建出所需網絡架構. 其中的“連通性探測”功能即是本文中所說Flowprobe系統在深信服超融合產品上的具體實現.

圖11中Centos7-Kafka、Centos7-MongDB、Centos7-Mysql是3個業務虛擬機. 我們首先在網絡正常的狀態下由Centos7-Mysql向Centos7-Kafka發起Flowprobe探測(連通性探測), 結果如圖12所示. 從圖12的結果中, 可以清晰地看到探測包在虛擬網絡中的轉發路徑、各個虛擬網元的轉發行為、各個虛擬網元所在的宿主機等信息.

圖11 Flowprobe功能驗證拓撲

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

接著, 去除邊界路由器1中關于Centos7-Mysql虛擬機的路由, 再發起同樣的探測, 結果如圖13所示.可以看到, 探測精準地定位到了出現故障的虛擬網元,以及出現網絡中斷的原因: 虛擬路由器查詢路由表失敗.

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

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

由圖14可見, Flowprobe系統亦可精準地定位出出問題的路由器以及網絡中斷的原因.

圖14 Centos7-Mysql向Centos7-Kafka發起Flowprobe探測結果(邊界路由器2網口禁用)

上述實驗僅是Flowprobe可探測的持續性丟包或網絡中斷場景中的一小部分, 嚴格的產品化測試流程表明, Flowprobe系統可以對576種虛擬網絡持續性丟包或者網絡中斷場景進行探測與故障定位.

5.2 Flowprobe系統性能評估

本小節將對Flowprobe系統的性能進行評估. 圖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的內存資源消耗. 從圖中可知, Flowprobe controller和Flowprobe agent的內存占用分別約為96 MB, 48 MB.

圖17 Flowprobe controller內存資源消耗

圖18 Flowprobe agent內存資源消耗

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

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

6 結論與展望

本文設計了一種虛擬網絡持續性丟包探測系統,該系統旨在解決基于DPDK用戶態虛擬網絡的持續性丟包檢測及根因定位問題. 文中詳細描述了該系統的設計思想. 為了減小探測對正常轉發的影響, 我們提出了一系列的優化措施, 如精心設計的探測包標記方案,路徑重建算法等.

該系統未來將持續進行功能和性能的優化, 后續將嘗試將該系統應用到安全運維領域, 實現對網絡功能服務鏈的轉發路徑驗證功能. 另外, 基于該系統實現虛擬網絡轉發過程中逐鏈路時延的探測等.