李 翠，陳慶奎

（上海理工大學(xué)光電信息與計(jì)算機(jī)工程學(xué)院，上海200093）

0 引言

隨著物聯(lián)網(wǎng)、5G、大數(shù)據(jù)和人工智能等技術(shù)的飛速發(fā)展，云計(jì)算因其資源利用率不高、可靠性低、可用性差、網(wǎng)絡(luò)延遲大等不足逐漸滿足不了用戶業(yè)務(wù)的需求［1-3］，邊緣計(jì)算作為云計(jì)算的擴(kuò)展和延伸，迅速得到了人們的關(guān)注。邊緣計(jì)算就近邊緣提供智能服務(wù)，融合了網(wǎng)絡(luò)、計(jì)算、存儲(chǔ)、應(yīng)用等核心技術(shù)［4-5］。無(wú)論是云計(jì)算還是邊緣計(jì)算都需要高可靠的虛擬化集群技術(shù)的支撐以應(yīng)對(duì)海量數(shù)據(jù)帶來(lái)的壓力。

隨著網(wǎng)絡(luò)技術(shù)的發(fā)展，網(wǎng)絡(luò)流量規(guī)模不斷增大，網(wǎng)絡(luò)傳輸速度逐步提高，接口帶寬也從千兆發(fā)展到萬(wàn)兆甚至更高，但網(wǎng)絡(luò)帶寬的增長(zhǎng)速度遠(yuǎn)遠(yuǎn)趕不上數(shù)據(jù)的增長(zhǎng)速度。為了應(yīng)對(duì)網(wǎng)絡(luò)中數(shù)據(jù)包的高速傳輸，Intel 設(shè)計(jì)了高性能的數(shù)據(jù)包處理框架DPDK（Data Plane Development Kit）［7］。DPDK 在Intel 架構(gòu)的通用處理器上有效地執(zhí)行數(shù)據(jù)包處理，相比Linux 內(nèi)核有10倍左右的性能提升［6-9］。

為了更好地發(fā)揮系統(tǒng)性能，充分利用節(jié)點(diǎn)的資源，對(duì)節(jié)點(diǎn)各個(gè)性能指標(biāo)進(jìn)行實(shí)時(shí)監(jiān)控變得尤為重要。本文設(shè)計(jì)了基于DPDK 并行通信的動(dòng)態(tài)網(wǎng)絡(luò)監(jiān)控模型，實(shí)現(xiàn)了對(duì)通信系統(tǒng)運(yùn)行時(shí)的各個(gè)指標(biāo)的實(shí)時(shí)監(jiān)控和監(jiān)控信息的收集，如中央處理器（Central Processing Unit，CPU）負(fù)載、CPU 利用率、內(nèi)存利用率、網(wǎng)口信息、網(wǎng)絡(luò)流量、節(jié)點(diǎn)狀態(tài)等。若發(fā)現(xiàn)異常情況，能夠第一時(shí)間進(jìn)行處理，在用戶還沒(méi)有察覺(jué)之前處理完故障和異常，將損失降到最低；還可以根據(jù)采集的監(jiān)控?cái)?shù)據(jù)優(yōu)化系統(tǒng)配置，包括配置出最優(yōu)的路由路徑和負(fù)載均衡策略等。

1 相關(guān)工作

1.1 DPDK

DPDK 是一套強(qiáng)大、高度優(yōu)化的用戶空間庫(kù)和驅(qū)動(dòng)程序，可以幫助用戶將控制面和數(shù)據(jù)面平臺(tái)進(jìn)行整合［10］。DPDK 繞過(guò)了Linux 內(nèi)核協(xié)議棧，工作在用戶態(tài)；利用線程的CPU 親和綁定方式避免了線程在不同核間頻繁切換；采用內(nèi)存大頁(yè)技術(shù)降低旁路轉(zhuǎn)換緩沖（Translation Lookaside Buffer，TLB）miss，減少訪存的開銷［9］；使用輪詢技術(shù)減少中斷處理開銷。DPDK允許開發(fā)者自由地修改源代碼，將其應(yīng)用于其他場(chǎng)景，包括加速包處理軟件庫(kù)，性能調(diào)優(yōu)，為網(wǎng)絡(luò)功能虛擬化（Network Function Virtualization，NFV）技術(shù)的發(fā)展提供平臺(tái)，為網(wǎng)絡(luò)監(jiān)控提供關(guān)鍵技術(shù)等。

1.2 監(jiān)控系統(tǒng)

計(jì)算機(jī)監(jiān)控領(lǐng)域有一些開源的軟件系統(tǒng)，近年來(lái)，很多研究想通過(guò)有效監(jiān)控去提升集群性能。文獻(xiàn)［11］以Nagios為起點(diǎn)，介紹了一種專為云架構(gòu)設(shè)計(jì)的監(jiān)控系統(tǒng)Rocmon，它以插件為導(dǎo)向，靈活性很強(qiáng)。文獻(xiàn)［12］研究了Nagios 用于監(jiān)視和解決Apache Web 服務(wù)器和Oracle 數(shù)據(jù)庫(kù)服務(wù)器中的問(wèn)題，提出了Nagios 中的自我修復(fù)功能用于自動(dòng)解決Linux 服務(wù)器問(wèn)題。文獻(xiàn)［13］介紹了一個(gè)基于Nagios 的服務(wù)框架設(shè)計(jì)和實(shí)現(xiàn)，該框架能夠監(jiān)視物理和虛擬基礎(chǔ)架構(gòu)的資源；但Nagios的缺點(diǎn)也不容忽視，它配置復(fù)雜，對(duì)性能、流量等的處理也不占優(yōu)勢(shì)。文獻(xiàn)［14］利用Zabbix 構(gòu)建了分布式的網(wǎng)絡(luò)監(jiān)控系統(tǒng)，實(shí)現(xiàn)對(duì)Windows 和Linux 平臺(tái)上關(guān)鍵應(yīng)用服務(wù)的監(jiān)控。文獻(xiàn)［15］設(shè)計(jì)了一種基于Zabbix 的網(wǎng)絡(luò)監(jiān)控系統(tǒng)，能夠有效監(jiān)控分布在不同網(wǎng)絡(luò)中的服務(wù)器和應(yīng)用程序，具有較好的穩(wěn)定性和普適性；但Zabbix 缺少數(shù)據(jù)匯總功能，報(bào)警設(shè)置比較多，對(duì)于深層的監(jiān)控需要二次開發(fā)。

現(xiàn)有監(jiān)控系統(tǒng)大多是基于Linux內(nèi)核協(xié)議棧，采用應(yīng)用層傳輸控制協(xié)議（Transmission Control Protocol，TCP）或者用戶數(shù)據(jù)報(bào)協(xié)議（User Datagram Protocol，UDP）或者簡(jiǎn)單網(wǎng)絡(luò)管理協(xié)議（Simple Network Management Protocol，SNMP）作為傳輸協(xié)議，傳輸速度都相對(duì)比較慢，不適合高速率、大流量的并行通信系統(tǒng)。本文介紹的動(dòng)態(tài)監(jiān)控采用的是基于DPDK 的數(shù)據(jù)包傳輸技術(shù)，繞開了復(fù)雜的內(nèi)核架構(gòu)，工作在用戶態(tài)空間，傳輸協(xié)議是基于二層通信協(xié)議DMPD（Dynamic Monitor Protocol based DPDK）的，很好地保證了監(jiān)控信息的實(shí)時(shí)性。

1.3 并行設(shè)計(jì)

本文基于DPDK 進(jìn)行了二次開發(fā)，針對(duì)局域網(wǎng)內(nèi)多核多網(wǎng)口服務(wù)器節(jié)點(diǎn)之間的并行通信，提供了高效可靠的數(shù)據(jù)包傳輸、轉(zhuǎn)發(fā)及處理，主要用到了以下三種并行結(jié)構(gòu)。

1）多核并行處理任務(wù)。在數(shù)據(jù)包處理領(lǐng)域，多核架構(gòu)的處理器已經(jīng)廣泛應(yīng)用。多核處理器內(nèi)部集成了多個(gè)完整的內(nèi)核，采用“橫向擴(kuò)展”的方法提高了系統(tǒng)的性能。本文模型采用了8 核處理器，通過(guò)任務(wù)劃分的方式，讓不同的核負(fù)責(zé)專門的任務(wù)，從而提高工作效率。其中：主邏輯核負(fù)責(zé)控制線程，完成一些控制任務(wù)，包括自我監(jiān)控、配合協(xié)調(diào)者完成系統(tǒng)監(jiān)控信息同步、執(zhí)行系統(tǒng)任務(wù)、接受用戶配置等；其他邏輯核負(fù)責(zé)輪詢，及時(shí)將要發(fā)送的數(shù)據(jù)包選擇網(wǎng)卡發(fā)送或者將網(wǎng)卡收到的數(shù)據(jù)包過(guò)濾后分發(fā)到不同的應(yīng)用管道中，以此來(lái)提高并行度。

2）多網(wǎng)口并行收發(fā)數(shù)據(jù)包。單網(wǎng)卡單端口已經(jīng)不足以應(yīng)對(duì)網(wǎng)絡(luò)中高速的流量傳輸，由于網(wǎng)卡的價(jià)格相對(duì)服務(wù)器其他配件比較便宜，因此本文采用多網(wǎng)口技術(shù)增加帶寬，提高服務(wù)器吞吐量，使收發(fā)包速率盡可能接近線速。多網(wǎng)口技術(shù)還可以提高通信的可靠性，通過(guò)“一包多發(fā)”，在不采用丟包重傳的情況下，降低丟包率。多網(wǎng)口配合多核處理器，可動(dòng)態(tài)調(diào)整各網(wǎng)口流量，降低網(wǎng)口負(fù)載壓力，從而保證服務(wù)器訪問(wèn)的穩(wěn)定和流暢。

3）多管道并行處理數(shù)據(jù)包。本文采用了多管道技術(shù)，將管道與軟件結(jié)合，每個(gè)應(yīng)用綁定一對(duì)雙向管道；各應(yīng)用之間保持相對(duì)獨(dú)立，結(jié)合多核多網(wǎng)口技術(shù)，并行處理各自的數(shù)據(jù)包。每對(duì)管道設(shè)有優(yōu)先級(jí)標(biāo)志、流量閾值、緩存大小、管道狀態(tài)等控制字段，用戶應(yīng)用可以根據(jù)自己的需求來(lái)對(duì)管道進(jìn)行控制，包括設(shè)置更高的發(fā)送優(yōu)先級(jí)、申請(qǐng)更多的緩存空間、降低帶寬等，從而做到分而治之。還設(shè)計(jì)了系統(tǒng)反饋控制，根據(jù)系統(tǒng)的運(yùn)行狀態(tài)和監(jiān)控信息動(dòng)態(tài)調(diào)整共享區(qū)的資源申請(qǐng)上限。

1.4 并行通信結(jié)構(gòu)

通信系統(tǒng)由多個(gè)node和一個(gè)master組成。node是一個(gè)通信和被監(jiān)控的節(jié)點(diǎn)，一般是服務(wù)器，用node_num 來(lái)唯一標(biāo)識(shí)。node 上運(yùn)行一段程序用來(lái)采集本地節(jié)點(diǎn)監(jiān)控?cái)?shù)據(jù)，并提交給master，每個(gè)node 都可以作為master 的候選者。master 是一個(gè)特殊的通信和監(jiān)控節(jié)點(diǎn)，它是由所有node 選舉出來(lái)的一個(gè)node，作為通信系統(tǒng)的協(xié)調(diào)者，用來(lái)匯總和收集node提交的監(jiān)控?cái)?shù)據(jù)。單個(gè)節(jié)點(diǎn)通信系統(tǒng)分為通信模塊和應(yīng)用程序接口模塊。前者實(shí)現(xiàn)了局域網(wǎng)內(nèi)服務(wù)器節(jié)點(diǎn)間的并行通信；后者為用戶應(yīng)用程序提供了調(diào)用接口。通信模塊包含三部分：組網(wǎng)、監(jiān)控和通信。其中：組網(wǎng)部分將局域網(wǎng)內(nèi)的服務(wù)器節(jié)點(diǎn)及節(jié)點(diǎn)信息進(jìn)行初始化和組織管理，為節(jié)點(diǎn)間通信和監(jiān)控提供基礎(chǔ)保證；監(jiān)控部分對(duì)節(jié)點(diǎn)的硬件信息、系統(tǒng)運(yùn)行狀態(tài)以及資源利用情況等進(jìn)行監(jiān)控和處理；通信部分則主要提供局域網(wǎng)內(nèi)節(jié)點(diǎn)之間的通信，同時(shí)也支持三層通信框架的擴(kuò)展。通信系統(tǒng)結(jié)構(gòu)如圖1所示。

圖1 節(jié)點(diǎn)通信系統(tǒng)結(jié)構(gòu)Fig.1 Structure of node communication system

1.5 負(fù)載均衡分析

負(fù)載均衡主要是根據(jù)某種算法將網(wǎng)絡(luò)的流量平均分配到不同的服務(wù)器、網(wǎng)絡(luò)設(shè)備和CPU 上，減輕單個(gè)設(shè)備壓力。DPDK 框架在負(fù)載均衡上采用了RSS（Receive Side Scaling）技術(shù)，RSS 技術(shù)［16］是依據(jù)包的類型匹配相應(yīng)的關(guān)鍵字決定收包隊(duì)列。文獻(xiàn)［17］介紹了對(duì)稱RSS，將同一連接的數(shù)據(jù)包映射到同一個(gè)網(wǎng)卡隊(duì)列，減少了線程在不同核間切換的開銷；文獻(xiàn)［18］介紹的HNLB（Hybrid NIC-offloading Load Balancer）是基于Intel 提出的Flow Director 技術(shù)實(shí)現(xiàn)的，它根據(jù)包的字段精確匹配，將其分配到某個(gè)特定隊(duì)列。這兩種方法都只考慮了接收端的負(fù)載均衡。

Linux內(nèi)核的Bonding 模塊運(yùn)用聚合的方法將多個(gè)物理網(wǎng)口綁定為一個(gè)虛擬網(wǎng)口，同時(shí)支持7 種模式來(lái)提供負(fù)載均衡和網(wǎng)絡(luò)冗余服務(wù)，從而實(shí)現(xiàn)高帶寬、高可用性等目標(biāo)。其中前6種模式只能處理發(fā)送數(shù)據(jù)端的負(fù)載均衡，第7種模式能夠處理發(fā)送和接收數(shù)據(jù)端的負(fù)載均衡，但對(duì)于接收數(shù)據(jù)端的負(fù)載均衡只是利用地址解析協(xié)議（Address Resolution Protocol，ARP）協(xié)商機(jī)制實(shí)現(xiàn)，通過(guò)預(yù)先靜態(tài)分配網(wǎng)口來(lái)實(shí)現(xiàn)接收端流量的負(fù)載均衡。在實(shí)際的復(fù)雜網(wǎng)絡(luò)環(huán)境下，該模式容易出現(xiàn)過(guò)載現(xiàn)象。

DPDK 的Link Bonding PMD 庫(kù)支持綁定相同速度和雙工的rte_eth_dev 端口組，允許將多個(gè)（從屬）網(wǎng)絡(luò)接口控制器（Network Interface Controller，NIC）聚合到服務(wù)器和交換機(jī)中的單個(gè)邏輯接口。然后，新的聚合的物理介質(zhì)關(guān)聯(lián)層（Physical Media Dependent layer，PMD）將根據(jù)指定的操作模式處理這些接口，以支持冗余鏈路、容錯(cuò)和負(fù)載均衡等功能。但PMD 的實(shí)現(xiàn)需要更改Linux 的網(wǎng)口驅(qū)動(dòng)，使得網(wǎng)口不能做其他用途，并且提供的6 種模式都只做了發(fā)送端網(wǎng)口負(fù)載均衡，沒(méi)有考慮到接收端的網(wǎng)口壓力，這樣會(huì)導(dǎo)致接收端網(wǎng)口出現(xiàn)性能瓶頸。

2 監(jiān)控模塊設(shè)計(jì)

2.1 監(jiān)控模型

單獨(dú)的控制節(jié)點(diǎn)只用來(lái)對(duì)系統(tǒng)進(jìn)行監(jiān)視與控制，不參與處理任務(wù)的執(zhí)行，這樣的設(shè)置容易出現(xiàn)單點(diǎn)故障，使通信系統(tǒng)的可靠性很大程度上受到控制節(jié)點(diǎn)的影響。為了避免此類情況的發(fā)生，保證通信系統(tǒng)的可靠性和穩(wěn)定性，本文介紹的通信系統(tǒng)的每個(gè)節(jié)點(diǎn)在任務(wù)處理和自我監(jiān)控方面地位是對(duì)等的，控制節(jié)點(diǎn)只是用來(lái)收集和廣播監(jiān)控信息的一個(gè)載體，通信系統(tǒng)中每個(gè)節(jié)點(diǎn)都保存有整個(gè)系統(tǒng)的監(jiān)控信息，都可以作為控制節(jié)點(diǎn)的備份節(jié)點(diǎn)。

動(dòng)態(tài)監(jiān)控包括自我監(jiān)控和整體監(jiān)控。其中：自我監(jiān)控是指每個(gè)節(jié)點(diǎn)監(jiān)控本機(jī)節(jié)點(diǎn)并采集監(jiān)控對(duì)象數(shù)據(jù)，當(dāng)本地節(jié)點(diǎn)出現(xiàn)問(wèn)題時(shí)能夠主動(dòng)脫離集體，避免不一致的產(chǎn)生。整體監(jiān)控由master 收集保存各節(jié)點(diǎn)狀態(tài)及資源信息，然后以心跳包DMPD 協(xié)議格式廣播給所有node，以便發(fā)生故障時(shí)，各節(jié)點(diǎn)能夠做出正確的決定并及時(shí)更新系統(tǒng)狀態(tài)。監(jiān)控模型結(jié)構(gòu)如圖2所示。

圖2 監(jiān)控模型結(jié)構(gòu)Fig.2 Structure of monitoring model

2.2 監(jiān)控工作原理

通信系統(tǒng)中每個(gè)服務(wù)器節(jié)點(diǎn)都配置有多個(gè)網(wǎng)口，其中一個(gè)網(wǎng)口作為外網(wǎng)接口，其余的用來(lái)完成基于DPDK 的局域網(wǎng)通信。每個(gè)網(wǎng)口綁定一個(gè)或多個(gè)發(fā)送隊(duì)列和接收隊(duì)列，網(wǎng)口從網(wǎng)絡(luò)上捕獲監(jiān)控?cái)?shù)據(jù)包后，將數(shù)據(jù)包映射到public_ring 環(huán)上，然后將public_ring 環(huán)交由邏輯核去處理。本文模型選用主邏輯核解析監(jiān)控?cái)?shù)據(jù)包，并對(duì)系統(tǒng)監(jiān)控信息進(jìn)行科學(xué)準(zhǔn)確的分析、計(jì)算和整理，針對(duì)不同的異常，做出合適、及時(shí)的處理。通信系統(tǒng)用public_ring 環(huán)，將監(jiān)控?cái)?shù)據(jù)包與通信數(shù)據(jù)包進(jìn)行分離，避免了控制數(shù)據(jù)包對(duì)常規(guī)通信數(shù)據(jù)包的干擾。

master 先廣播一個(gè)時(shí)間同步包，各個(gè)node 收到后將采集的本機(jī)監(jiān)控?cái)?shù)據(jù)信息整理并回復(fù)給master，延時(shí)一段時(shí)間后，master 將收集的所有節(jié)點(diǎn)的監(jiān)控?cái)?shù)據(jù)信息整理打包并廣播，每一個(gè)node 都會(huì)獲得相關(guān)監(jiān)控信息并依據(jù)這些信息分析出系統(tǒng)網(wǎng)絡(luò)狀況。

2.3 監(jiān)控對(duì)象

通信系統(tǒng)中節(jié)點(diǎn)越多、資源越分散，系統(tǒng)管理就越困難。為了保證通信系統(tǒng)的正常運(yùn)行，需要對(duì)系統(tǒng)各節(jié)點(diǎn)的運(yùn)行狀況和資源狀況信息進(jìn)行全面收集和統(tǒng)一管理。影響系統(tǒng)正常運(yùn)行的因素有很多，包括節(jié)點(diǎn)的CPU、內(nèi)存、網(wǎng)絡(luò)、網(wǎng)卡等多個(gè)組件的相關(guān)信息，Linux系統(tǒng)已經(jīng)內(nèi)置了很多監(jiān)控信息并且提供相應(yīng)的接口，本文主要針對(duì)網(wǎng)卡端口和管道進(jìn)行更細(xì)粒度的監(jiān)控，以更好地應(yīng)對(duì)局域網(wǎng)內(nèi)高速率流量傳輸。主要監(jiān)控內(nèi)容如表1所示。

表1 監(jiān)控對(duì)象Tab.1 Objects of monitoring

網(wǎng)口流量Fport（t）（單位：b）計(jì)算公式如下：

其中：n 表示網(wǎng)卡總的收發(fā)隊(duì)列，i 表示第i 個(gè)收發(fā)隊(duì)列，RX 表示收包環(huán)形隊(duì)列，TX表示發(fā)包環(huán)形隊(duì)列。

其中：Trecv表示所有收到的包數(shù)量，Tsend表示一共發(fā)送的包數(shù)量。

其中：Fport(t)表示當(dāng)前的流量值，F(xiàn)port(t-1)表示上次收集時(shí)的流量值，Δτ 表示兩次收集時(shí)間差；BW 表示網(wǎng)口帶寬，取值為1 Gb/s。

2.4 監(jiān)控?cái)?shù)據(jù)采集

采集的數(shù)據(jù)主要來(lái)自監(jiān)控對(duì)象。通過(guò)在每個(gè)網(wǎng)口設(shè)置原子計(jì)數(shù)器，來(lái)記錄網(wǎng)口流量值、收發(fā)包數(shù)量、錯(cuò)誤包數(shù)量、丟包數(shù)量以及隊(duì)列溢出次數(shù)，并且記錄了網(wǎng)口一段時(shí)間的歷史值；每個(gè)核設(shè)置原子計(jì)數(shù)器和空閑計(jì)數(shù)器，分別用來(lái)記錄核的收發(fā)包數(shù)量和空輪詢的次數(shù)；通過(guò)讀取配置文件可以獲取大頁(yè)大小、管道數(shù)目、節(jié)點(diǎn)網(wǎng)口數(shù)量等靜態(tài)信息；通過(guò)調(diào)用Linux系統(tǒng)函數(shù)可以獲取CPU負(fù)載、內(nèi)存大小、內(nèi)存利用率、CPU溫度、CPU核數(shù)目、工作電壓等系統(tǒng)信息。

采集的信息采用DMPD 協(xié)議格式進(jìn)行封裝，以提高信息的規(guī)范性，簡(jiǎn)化信息的解析。封裝好的信息通過(guò)基于send/recv 模式的心跳機(jī)制在通信節(jié)點(diǎn)間進(jìn)行消息交換。本文介紹的系統(tǒng)監(jiān)控的心跳機(jī)制是將傳統(tǒng)的心跳信息附加到監(jiān)控信息中一起發(fā)送，減少了額外的寬帶和流量消耗。

心跳數(shù)據(jù)包的傳輸用到了額外的傳輸協(xié)議DMPD，它是基于DPDK 開發(fā)的二層傳輸協(xié)議，包括心跳包協(xié)議和響應(yīng)心跳包協(xié)議。心跳數(shù)據(jù)包是master 通過(guò)廣播，將收集保存的node 信息發(fā)送到所有node 的每一個(gè)網(wǎng)卡；響應(yīng)心跳數(shù)據(jù)包是node收到心跳數(shù)據(jù)包后回復(fù)給master的本地節(jié)點(diǎn)的監(jiān)控信息及對(duì)master的監(jiān)控信息。協(xié)議格式如圖3所示。其中：m前綴代表網(wǎng)口信息，p 前綴代表管道信息，n 前綴代表node 信息，SCORE 表示核數(shù)目，UCPU 表示CPU 利用率，LCPU 表示CPU負(fù)載，LIO 表示IO 負(fù)載，SMEM 表示內(nèi)存大小，UMEM 表示內(nèi)存利用率。

圖3 DMPD協(xié)議示意圖Fig.3 Schematic diagram of DMPD protocol

3 負(fù)載均衡

3.1 多網(wǎng)口負(fù)載均衡模型

本文針對(duì)DPDK 的Link Bonding PMD 庫(kù)存在的缺陷與不足，設(shè)計(jì)了一種基于DPDK 多網(wǎng)口的負(fù)載均衡結(jié)構(gòu)，并實(shí)現(xiàn)了動(dòng)態(tài)負(fù)載均衡算法。

當(dāng)收到數(shù)據(jù)包時(shí)，將定制的關(guān)鍵字元組，即五元組（Snode_num，Dnode_num，Spump，Dpump，Ptype）根據(jù)微軟托普利茲算法［19］計(jì)算散列值，并通過(guò)取模操作來(lái)選擇發(fā)送網(wǎng)口和接收網(wǎng)口，然后根據(jù)散列表中對(duì)應(yīng)網(wǎng)口的負(fù)載，決定是否調(diào)用調(diào)整函數(shù)，選擇當(dāng)前最優(yōu)網(wǎng)口進(jìn)行發(fā)包或者收包，還采用心跳機(jī)制動(dòng)態(tài)更新網(wǎng)口負(fù)載，保證網(wǎng)口選擇的可靠性。其中：Snode_num 表示源節(jié)點(diǎn)編號(hào)，Dnode_num 表示目的節(jié)點(diǎn)編號(hào)，Spump 表示源節(jié)點(diǎn)管道，Dpump 表示目的節(jié)點(diǎn)管道，Ptype 表示包類型。負(fù)載均衡框架如圖4所示。

圖4 負(fù)載均衡框架Fig.4 Load balancing framework

3.2 動(dòng)態(tài)負(fù)載均衡算法

本節(jié)給出了網(wǎng)口負(fù)載信息模型，設(shè)有n 個(gè)網(wǎng)口，每個(gè)網(wǎng)口有m 個(gè)影響網(wǎng)口負(fù)載的因素，每個(gè)因素占用的權(quán)重系數(shù)為λ，λ的取值范圍為［0，1］，且權(quán)重系數(shù)滿足式（4）：

則第i（i=1，2，…，n）個(gè)網(wǎng)口t時(shí)刻的負(fù)載為式（5）：

本文選取的影響網(wǎng)口負(fù)載的因素分別為網(wǎng)口利用率、網(wǎng)口丟包率和隊(duì)列溢出率，通過(guò)反復(fù)實(shí)驗(yàn)，選出效果比較好的權(quán)重系數(shù)分別為0.84、0.09 和0.07。由于距離、延遲或突發(fā)的網(wǎng)絡(luò)故障等原因，會(huì)讓采集到的監(jiān)控信息產(chǎn)生誤差，為了防止負(fù)載信息出現(xiàn)突變，提高負(fù)載信息準(zhǔn)確性，本文選擇使用自動(dòng)調(diào)節(jié)公式平滑過(guò)渡。設(shè)上次采集負(fù)載為L(zhǎng)port_i(t-1)，當(dāng)前采集負(fù)載值為L(zhǎng)port_i'(t)，i 表示第i 個(gè)網(wǎng)口，則當(dāng)前負(fù)載值為式（6）：

其中：γ表示調(diào)整因子，取值為0.8。

為了對(duì)多網(wǎng)口的負(fù)載進(jìn)行總體統(tǒng)籌，準(zhǔn)確調(diào)用調(diào)整函數(shù)，本文采用了負(fù)載均衡度對(duì)各網(wǎng)口負(fù)載進(jìn)行衡量。負(fù)載均衡度反映了多網(wǎng)口數(shù)據(jù)包收發(fā)處理的差異程度，它的值越小，表明各網(wǎng)口的數(shù)據(jù)包分配就越均勻。式（7）是網(wǎng)口t時(shí)刻的平均負(fù)載，式（8）為負(fù)載均衡度。

其中：n 為網(wǎng)口的數(shù)量，Lport_i(t)表示在時(shí)刻t 第i(i=1，2，…，n)個(gè)網(wǎng)口的負(fù)載。這里的μ 值是期望負(fù)載，可以調(diào)整，在當(dāng)前網(wǎng)口負(fù)載高于平均負(fù)載且負(fù)載均衡度的值大于1.86 時(shí)，就會(huì)調(diào)用調(diào)整函數(shù)選出當(dāng)前最優(yōu)網(wǎng)卡，調(diào)整函數(shù)采用小根堆結(jié)構(gòu)，經(jīng)過(guò)一次堆調(diào)整找出當(dāng)前負(fù)載最小的網(wǎng)口。動(dòng)態(tài)負(fù)載均衡算法流程步驟描述如下：

步驟1 收到將要發(fā)送的數(shù)據(jù)包后，解析包頭，得到關(guān)鍵字元組（Snode_num，Dnode_num，Spump，Dpump，Ptype）。

步驟2 通過(guò)散列函數(shù)得到散列結(jié)果，在散列表中找到發(fā)送網(wǎng)口對(duì)應(yīng)項(xiàng)。

步驟3 查看發(fā)送網(wǎng)口狀態(tài)值，如果為不可用，則執(zhí)行步驟4，否則計(jì)算當(dāng)前平均負(fù)載和負(fù)載均衡度；如果負(fù)載均衡度沒(méi)有超過(guò)閾值，則選擇該網(wǎng)口作為發(fā)送網(wǎng)口，填充源MAC（Media Access Control）地址，跳至步驟5，否則執(zhí)行步驟4。

步驟4 當(dāng)網(wǎng)口不可用或者網(wǎng)口過(guò)載時(shí)，通過(guò)調(diào)整函數(shù)找出當(dāng)前可用發(fā)送網(wǎng)口中負(fù)載最小的作為發(fā)送網(wǎng)口，填充源MAC地址。

步驟5 通過(guò)調(diào)整函數(shù)找出當(dāng)前可用接收網(wǎng)口中負(fù)載最小的作為接收網(wǎng)口，填寫目的MAC地址。

步驟6 發(fā)送數(shù)據(jù)包至發(fā)送網(wǎng)口的TX（Transport）隊(duì)列。

動(dòng)態(tài)負(fù)載均衡算法的偽代碼如下：

Algorithm of load balancing

while（pthread_quit！=0）

Receive packets to be sent

Parse the header of packets and get the key_touple

Get the hash result

Find the sending port by key

if（port_state==0）

Find the minimum load sending port from the available ports

Fill source MAC address

else

Compute current Lport(t)and WL(t)

if（WL(t)＞threshold）

Find the minimum load sending port from the available ports

Fill source MAC address

end if

end if

Find the minimum load receiving port from the available ports

Fill destination MAC address

Send packets to the TX

end while

4 實(shí)驗(yàn)分析

4.1 實(shí)驗(yàn)環(huán)境

在Linux 環(huán)境下實(shí)現(xiàn)了基于DPDK 的數(shù)據(jù)密集型并行通信系統(tǒng)，它由20 000 行C 語(yǔ)言代碼組成，是基于DPDK18.02版本開發(fā)的，動(dòng)態(tài)監(jiān)控是它的一個(gè)組成部分。為了驗(yàn)證動(dòng)態(tài)網(wǎng)絡(luò)監(jiān)控的有效性，搭建了千兆網(wǎng)絡(luò)的局域網(wǎng)通信系統(tǒng)，由一臺(tái)二層交換機(jī)和10臺(tái)服務(wù)器組成，系統(tǒng)拓?fù)浣Y(jié)構(gòu)如圖5所示，服務(wù)器配置信息則如表2所示。

圖5 系統(tǒng)拓?fù)浣Y(jié)構(gòu)Fig.5 System topology

在測(cè)試中，使用DPDK 提供的流量發(fā)生器Pktgen［20］作為數(shù)據(jù)包生成工具來(lái)產(chǎn)生大小不同的數(shù)據(jù)包。局域網(wǎng)10 臺(tái)服務(wù)器的應(yīng)用連接數(shù)目各不一樣，不同節(jié)點(diǎn)應(yīng)用之間相互通信，接收端服務(wù)器收到這些報(bào)文后會(huì)進(jìn)行過(guò)濾解析，將其分發(fā)到目的應(yīng)用管道中。整個(gè)過(guò)程中，監(jiān)控模塊一直在動(dòng)態(tài)地監(jiān)控通信系統(tǒng)的資源與節(jié)點(diǎn)的狀態(tài)信息，為節(jié)點(diǎn)通信提供可靠性保證。

表2 服務(wù)器配置信息Tab.2 Configuration information of server

4.2 實(shí)驗(yàn)結(jié)果

在上述的實(shí)驗(yàn)環(huán)境中，不同節(jié)點(diǎn)之間相互通信，發(fā)送大小不同的數(shù)據(jù)包，其中：node1、node2發(fā)送64 B的數(shù)據(jù)包，node3、node4 發(fā)送128 B 的數(shù)據(jù)包，node9 發(fā)送256 B 的數(shù)據(jù)包，node5、node6 發(fā)送512 B 的數(shù)據(jù)包，node7、node8 發(fā)送1 024 B的數(shù)據(jù)包，master發(fā)送1 024 B大小以上的數(shù)據(jù)包。

4.2.1 監(jiān)控性能測(cè)試

master、node1、node3、node6、node7 配置8 個(gè)網(wǎng)口，其余節(jié)點(diǎn)配置4 個(gè)網(wǎng)口，每隔5 s 對(duì)系統(tǒng)資源及節(jié)點(diǎn)狀態(tài)進(jìn)行采集，表3 是一段時(shí)間某一時(shí)刻系統(tǒng)的監(jiān)控信息統(tǒng)計(jì)結(jié)果，其中CPU 負(fù)載一列展示的是最近1 min、5 min、15 min 的負(fù)載值。表4 是網(wǎng)口監(jiān)控信息統(tǒng)計(jì)，其中：網(wǎng)口狀態(tài)一列每一位表示一個(gè)網(wǎng)口的狀態(tài)，1 表示正常狀態(tài)，0 表示不可用狀態(tài)；網(wǎng)口數(shù)據(jù)流速率一列每個(gè)值表示一個(gè)網(wǎng)口單位時(shí)間的流量；網(wǎng)口利用率一列每個(gè)值表示一個(gè)網(wǎng)口收發(fā)包速率和帶寬的百分比。選取master、node1、node3、node6這4個(gè)節(jié)點(diǎn)30 s內(nèi)的8個(gè)網(wǎng)口總的收包、丟包、數(shù)據(jù)包處理情況進(jìn)行分析計(jì)算，結(jié)果分別如圖6～8所示。

圖6 不同包大小的節(jié)點(diǎn)的數(shù)據(jù)流速率Fig.6 Data flow rate of nodes with different package size

圖7 不同包大小的節(jié)點(diǎn)的丟包率Fig.7 Packet loss rate of nodes with different package size

圖8 不同包大小的節(jié)點(diǎn)的數(shù)據(jù)包處理能力Fig.8 Packet handling capability of nodes with different package size

表3 系統(tǒng)監(jiān)控對(duì)象數(shù)據(jù)Tab.3 Data of monitoring objects of system

表4 網(wǎng)口監(jiān)控對(duì)象數(shù)據(jù)Tab.4 Data of monitoring objects of network port

由圖6～8 可以看出，隨著數(shù)據(jù)包的增大，節(jié)點(diǎn)丟包率逐漸下降到0，收發(fā)包速率（節(jié)點(diǎn)數(shù)據(jù)流速率）逐漸向線速逼近，數(shù)據(jù)包處理能力逐漸增強(qiáng)至能夠及時(shí)處理所有收到的數(shù)據(jù)包。由表3、4 數(shù)據(jù)可看出，系統(tǒng)各個(gè)節(jié)點(diǎn)的各項(xiàng)指標(biāo)相對(duì)一致，系統(tǒng)狀態(tài)與預(yù)期一致，由此可說(shuō)明動(dòng)態(tài)監(jiān)控模型能夠正確有效地監(jiān)控各個(gè)節(jié)點(diǎn)的各項(xiàng)指標(biāo)，保證通信系統(tǒng)處在一個(gè)相對(duì)穩(wěn)定的狀態(tài)。

4.2.2 負(fù)載均衡測(cè)試

在上述測(cè)試的基礎(chǔ)上，流量限制為4 Gb/s，每隔5 s，對(duì)node4（4 網(wǎng)口，8 核心）和master（8 網(wǎng)口，8 核心）的監(jiān)控信息進(jìn)行采集（5 s 內(nèi)的平均值），計(jì)算各網(wǎng)口的利用率，采用負(fù)載均衡前后的節(jié)點(diǎn)網(wǎng)口利用率情況如圖9、10所示。

圖9 node4網(wǎng)口利用率Fig.9 Network port utilization of node4

由圖9和圖10可以看出，未采用負(fù)載均衡時(shí)，各網(wǎng)口利用率層次不齊，不同網(wǎng)口之間差距很大，采用負(fù)載均衡方法后，各網(wǎng)口利用率變得相對(duì)比較平均，各網(wǎng)口之間相互分擔(dān)負(fù)載，避免了瓶頸的發(fā)生，提高了服務(wù)器的性能。

圖10 master網(wǎng)口利用率Fig.10 Network port utilization of master

5 結(jié)語(yǔ)

本文首先對(duì)DPDK、并行通信和動(dòng)態(tài)監(jiān)控進(jìn)行了研究分析，設(shè)計(jì)實(shí)現(xiàn)了基于DPDK 并行通信的動(dòng)態(tài)監(jiān)控模型；然后對(duì)監(jiān)控對(duì)象進(jìn)行了分析，針對(duì)不同對(duì)象設(shè)置了合適的探測(cè)點(diǎn)，通過(guò)DMPD 協(xié)議進(jìn)行監(jiān)控?cái)?shù)據(jù)采集，并且根據(jù)監(jiān)控信息設(shè)計(jì)了一種基于多網(wǎng)口的動(dòng)態(tài)負(fù)載均衡算法；最后通過(guò)實(shí)驗(yàn)驗(yàn)證了動(dòng)態(tài)網(wǎng)絡(luò)監(jiān)控及負(fù)載均衡算法的性能。接下來(lái)我們將對(duì)功耗控制、廣播包過(guò)濾功能做進(jìn)一步的探討和研究。