基于DPDK并行通信的動態(tài)監(jiān)控模型

李 翠，陳慶奎

（上海理工大學光電信息與計算機工程學院，上海200093）

0 引言

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

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

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

1 相關工作

1.1 DPDK

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

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

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

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

1.3 并行設計

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

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

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

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

1.4 并行通信結構

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

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

1.5 負載均衡分析

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

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

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

2 監(jiān)控模塊設計

2.1 監(jiān)控模型

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

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

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

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

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

master 先廣播一個時間同步包，各個node 收到后將采集的本機監(jiān)控數據信息整理并回復給master，延時一段時間后，master 將收集的所有節(jié)點的監(jiān)控數據信息整理打包并廣播，每一個node 都會獲得相關監(jiān)控信息并依據這些信息分析出系統(tǒng)網絡狀況。

2.3 監(jiān)控對象

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

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

網口流量Fport（t）（單位：b）計算公式如下：

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

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

其中：Fport(t)表示當前的流量值，Fport(t-1)表示上次收集時的流量值，Δτ 表示兩次收集時間差；BW 表示網口帶寬，取值為1 Gb/s。

2.4 監(jiān)控數據采集

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

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

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

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

3 負載均衡

3.1 多網口負載均衡模型

本文針對DPDK 的Link Bonding PMD 庫存在的缺陷與不足，設計了一種基于DPDK 多網口的負載均衡結構，并實現了動態(tài)負載均衡算法。

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

圖4 負載均衡框架Fig.4 Load balancing framework

3.2 動態(tài)負載均衡算法

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

則第i（i=1，2，…，n）個網口t時刻的負載為式（5）：

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

其中：γ表示調整因子，取值為0.8。

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

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

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

步驟2 通過散列函數得到散列結果，在散列表中找到發(fā)送網口對應項。

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

步驟4 當網口不可用或者網口過載時，通過調整函數找出當前可用發(fā)送網口中負載最小的作為發(fā)送網口，填充源MAC地址。

步驟5 通過調整函數找出當前可用接收網口中負載最小的作為接收網口，填寫目的MAC地址。

步驟6 發(fā)送數據包至發(fā)送網口的TX（Transport）隊列。

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

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 實驗分析

4.1 實驗環(huán)境

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

圖5 系統(tǒng)拓撲結構Fig.5 System topology

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

表2 服務器配置信息Tab.2 Configuration information of server

4.2 實驗結果

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

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

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

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

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

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

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

表4 網口監(jiān)控對象數據Tab.4 Data of monitoring objects of network port

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

4.2.2 負載均衡測試

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

圖9 node4網口利用率Fig.9 Network port utilization of node4

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

圖10 master網口利用率Fig.10 Network port utilization of master

5 結語

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