基于DPDK的邊緣集群內(nèi)低成本高速通信方案

吳明杰，陳慶奎

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

1 引 言

隨著物聯(lián)網(wǎng)[1]規(guī)模的不斷擴(kuò)大，數(shù)據(jù)的不斷增加，基于云的物聯(lián)網(wǎng)解決方案將承受更大的壓力.為了緩解這一現(xiàn)狀，越來(lái)越多的企業(yè)開(kāi)始將目光轉(zhuǎn)向邊緣計(jì)算[2]，并將其作為云的延伸擴(kuò)展，以加快數(shù)據(jù)分析的速度，減少延遲.邊緣計(jì)算是一種分散式計(jì)算架構(gòu)，將終端的部分計(jì)算需求從原有的云計(jì)算中心分配到邊緣計(jì)算集群中[3].這樣不僅能夠充分緩解數(shù)據(jù)中心的計(jì)算和通信壓力，還能充分利用邊緣計(jì)算集群的資源，改善用戶的響應(yīng)需求和計(jì)算需求.邊緣計(jì)算的關(guān)鍵不僅僅是計(jì)算性能，還需要高速的處理機(jī)制和通信機(jī)制.

據(jù)估計(jì)，未來(lái)50%的物聯(lián)網(wǎng)數(shù)據(jù)將在數(shù)據(jù)源頭附近進(jìn)行處理，包括設(shè)備端和邊緣側(cè).而且，隨著邊緣AI[4，5]的興起，使得越來(lái)越多的人工智能應(yīng)用如智能監(jiān)控、車聯(lián)網(wǎng)、自動(dòng)駕駛等被部署在邊緣側(cè).這不僅使得邊緣節(jié)點(diǎn)所面臨的數(shù)據(jù)量增加，邊緣集群內(nèi)通信的數(shù)據(jù)量也將驟增，這對(duì)邊緣集群內(nèi)的通信帶寬提出了更高的要求.

物聯(lián)網(wǎng)設(shè)備的龐大規(guī)模，決定了邊緣計(jì)算節(jié)點(diǎn)的數(shù)量不可能少，而且是高度分布式的.他們不僅分布在辦公室、工廠、校園等場(chǎng)所，有些甚至分布在遙遠(yuǎn)的、難以訪問(wèn)的地方.邊緣計(jì)算節(jié)點(diǎn)不僅要執(zhí)行數(shù)據(jù)采集、程序更新、設(shè)備管理和監(jiān)控、機(jī)器學(xué)習(xí)模型更新等高級(jí)功能，而且還要進(jìn)行實(shí)時(shí)的數(shù)據(jù)處理、AI計(jì)算等.這些決定了邊緣計(jì)算節(jié)點(diǎn)需要低成本和支持復(fù)雜業(yè)務(wù)的屬性.如何以較低的成本實(shí)現(xiàn)邊緣計(jì)算節(jié)點(diǎn)對(duì)復(fù)雜任務(wù)的支持，將會(huì)是研究熱點(diǎn).

本文針對(duì)邊緣計(jì)算對(duì)集群內(nèi)高速通信的需求，提出一種以較低成本實(shí)現(xiàn)更高帶寬的通信方案.相比于傳統(tǒng)的通信方案，本文提出的方案能夠在提供相同帶寬的情況下，成本縮減2/3，延遲降低10%，丟包率降低60%.

2 相關(guān)工作

隨著邊緣計(jì)算所面臨的數(shù)據(jù)和業(yè)務(wù)規(guī)模增加，邊緣節(jié)點(diǎn)的實(shí)現(xiàn)方式也由單機(jī)擴(kuò)展到了集群，而且集群內(nèi)的通信數(shù)據(jù)量和頻率的增加，對(duì)帶寬也提出了更高的要求.雖然現(xiàn)在的網(wǎng)絡(luò)設(shè)備帶寬從最初的百兆增加至千兆，但是網(wǎng)絡(luò)帶寬的增長(zhǎng)速度遠(yuǎn)不及網(wǎng)絡(luò)流量，千兆帶寬對(duì)于實(shí)時(shí)性較高的業(yè)務(wù)也顯得捉襟見(jiàn)肘.萬(wàn)兆帶寬的高昂價(jià)格，也使得其難以普及.在邊緣集群內(nèi)實(shí)現(xiàn)萬(wàn)兆帶寬連接，將會(huì)增加邊緣節(jié)點(diǎn)的成本負(fù)擔(dān).

現(xiàn)有的服務(wù)器操作系統(tǒng)的bonding模式[6]，可以通過(guò)多網(wǎng)卡增加服務(wù)器帶寬，但其實(shí)現(xiàn)復(fù)雜，甚至需要專用的通信設(shè)備.而且bonding模式下，單條網(wǎng)絡(luò)連接無(wú)法突破單張物理網(wǎng)卡理論速率的限制，要想充分利用多張網(wǎng)卡的疊加帶寬，必須運(yùn)用多線程多連接技術(shù)[7]，增加了使用難度，傳統(tǒng)的網(wǎng)絡(luò)協(xié)議和處理機(jī)制也使得網(wǎng)絡(luò)帶寬的利用率不高.現(xiàn)有通信技術(shù)主要從兩方面進(jìn)行改進(jìn)：一方面通過(guò)硬件手段如FPGA等專用硬件進(jìn)行數(shù)據(jù)包處理.賴裕平、馬秀等人基于輪詢系統(tǒng)的特性，提出一種基輪詢的mac協(xié)議的FPGA設(shè)計(jì)[8].利用FPGA的可重構(gòu)和靈活的特性從硬件手段進(jìn)行通信性能的提升.雖然性能提升明顯，降低了傳輸時(shí)延，提高了總線利用率，但是價(jià)格昂貴，也沒(méi)有從根本上解決內(nèi)核協(xié)議性能低下的問(wèn)題.另一方面通過(guò)對(duì)現(xiàn)有的傳輸協(xié)議進(jìn)行改進(jìn)或者進(jìn)行數(shù)據(jù)量壓縮.例如Hei X等人提出一種基于UDP的Deque-ERUDP高效傳輸協(xié)議，通過(guò)協(xié)議動(dòng)態(tài)的提升通信效率，降低網(wǎng)絡(luò)阻塞[9].而B(niǎo)etzel F等人則從數(shù)據(jù)角度出發(fā)，采用近似壓縮削減冗余數(shù)據(jù)量[10].然而這種方式容易丟失數(shù)據(jù)細(xì)節(jié)并消耗大量計(jì)算資源.在2014年，Intel針對(duì)x86架構(gòu)推出了一種數(shù)據(jù)平面開(kāi)發(fā)套件DPDK[11，12]，旨在應(yīng)對(duì)網(wǎng)絡(luò)中數(shù)據(jù)包的高速傳輸.DPDK利用用戶態(tài)驅(qū)動(dòng)、親和性、內(nèi)存大頁(yè)和輪詢等技術(shù)，使得網(wǎng)卡的收發(fā)速率可接近線速[13，14].DPDK繞過(guò)傳統(tǒng)的內(nèi)核協(xié)議棧，將數(shù)據(jù)鏈路層數(shù)據(jù)直接交給用戶進(jìn)程處理，減少了通信過(guò)程中數(shù)據(jù)的交付時(shí)延[15].DPDK對(duì)于多核和多網(wǎng)口的支持，能夠成倍地增加通信帶寬.DPDK的眾多特性，能夠極大地提升網(wǎng)絡(luò)通信效率[16].

在成本受限和高速率傳輸需求的驅(qū)動(dòng)下，改進(jìn)網(wǎng)絡(luò)協(xié)議和處理機(jī)制、多網(wǎng)口并行通信是一種新的出路.本文基于Intel的DPDK技術(shù)提出一種多網(wǎng)卡的高速傳輸方案.該方案首先利用DPDK用戶態(tài)驅(qū)動(dòng)技術(shù)，將數(shù)據(jù)包的處理移至用戶空間，不僅繞過(guò)了系統(tǒng)內(nèi)核協(xié)議棧，使網(wǎng)卡能夠接近線速率傳輸，而且結(jié)合DPDK多核多網(wǎng)口的特性[17]，實(shí)現(xiàn)了多網(wǎng)口的并行高速傳輸和帶寬疊加；其次，利用操作系統(tǒng)Socket本地回環(huán)機(jī)制[18，19]，為用戶應(yīng)用提供語(yǔ)言無(wú)關(guān)的調(diào)用接口，并且單條連接能夠達(dá)到多張網(wǎng)卡的疊加帶寬.

3 設(shè) 計(jì)

DPDK是繞過(guò)傳統(tǒng)的內(nèi)核協(xié)議棧，能夠接近網(wǎng)卡的線速進(jìn)行數(shù)據(jù)收發(fā).再結(jié)合CPU多核特性，DPDK能夠充分利用多張網(wǎng)卡的疊加帶寬，使十張千兆網(wǎng)卡的疊加帶寬能夠與一張萬(wàn)兆網(wǎng)卡相匹敵，但成本卻降低了很多.DPDK是C語(yǔ)言開(kāi)發(fā)的，對(duì)于其他高級(jí)語(yǔ)言的支持不夠友好.因此，本文想利用操作系統(tǒng)的套接字機(jī)制，實(shí)現(xiàn)DPDK對(duì)于多語(yǔ)言編程環(huán)境的支持.套接字的回環(huán)機(jī)制作為本地操作系統(tǒng)不同進(jìn)程間的通信方式之一，能夠?qū)崿F(xiàn)DPDK進(jìn)程與不同語(yǔ)言的用戶進(jìn)程之間進(jìn)行通信.為了驗(yàn)證操作系統(tǒng)本地回環(huán)機(jī)制的帶寬，本文在配有DDR3-1600Mhz的服務(wù)器上使用Iperf軟件進(jìn)行測(cè)試，最終測(cè)得本地回環(huán)的TCP通信帶寬為60Gbps，經(jīng)過(guò)優(yōu)化的UDP通信帶寬為14Gbps.操作系統(tǒng)本地回環(huán)機(jī)制的帶寬不僅能過(guò)支持DPDK多張千兆網(wǎng)卡疊加帶寬，甚至能夠支持DPDK多張萬(wàn)兆網(wǎng)卡的疊加帶寬.因此，本文的這種通信方案具有很高的升級(jí)空間和應(yīng)用前景.

3.1 物理拓?fù)?/h3>

DPDK利用UIO技術(shù)，將數(shù)據(jù)鏈路層數(shù)據(jù)直接交給用戶進(jìn)程處理.因此，用戶需要自定義通信協(xié)議.DPDK基于數(shù)據(jù)鏈路層的數(shù)據(jù)包處理技術(shù)決定了網(wǎng)絡(luò)拓?fù)浜?jiǎn)單，網(wǎng)絡(luò)設(shè)備要求低，僅需要二層網(wǎng)絡(luò)設(shè)備即可實(shí)現(xiàn)通信.

圖1 物理拓?fù)銯ig.1 Physical topology

如圖1所示，本文的方案通過(guò)普通網(wǎng)線將服務(wù)器的多張網(wǎng)卡與二層交換機(jī)相連，對(duì)傳統(tǒng)的網(wǎng)絡(luò)結(jié)構(gòu)沒(méi)有影響.而且，集群節(jié)點(diǎn)的擴(kuò)展與傳統(tǒng)的交換機(jī)級(jí)聯(lián)技術(shù)并無(wú)沖突，只需將待擴(kuò)展服務(wù)器的多張網(wǎng)卡通過(guò)網(wǎng)線接入二層交換機(jī)即可實(shí)現(xiàn).

3.2 系統(tǒng)框架

通過(guò)操作系統(tǒng)套接字的本地回環(huán)機(jī)制，本文的通信方案能夠支持不同高級(jí)語(yǔ)言應(yīng)用的使用.如圖2所示，虛線左側(cè)為傳統(tǒng)通信，右側(cè)為本文的通信方案.本文的通信方案與傳統(tǒng)的通信方案相互兼容共存，可以為集群內(nèi)的主機(jī)間提供兩套通信方案，能夠支持更加復(fù)雜的上層任務(wù).本文的通信方案基于DPDK實(shí)現(xiàn)底層多網(wǎng)卡的數(shù)據(jù)收發(fā)，通過(guò)本地回環(huán)機(jī)制為用戶應(yīng)用提供統(tǒng)一的使用接口.而且，內(nèi)部也實(shí)現(xiàn)了多網(wǎng)卡的負(fù)載均衡以及多應(yīng)用的帶寬均衡機(jī)制.

圖2 系統(tǒng)框架Fig.2 System framework

4 實(shí) 現(xiàn)

4.1 通信模型

本文的通信方案利用本地回環(huán)機(jī)制為用戶提供使用接口，底層的通信過(guò)程對(duì)用戶是透明的.同時(shí)，通信過(guò)程也是全雙工的，即在通信過(guò)程中數(shù)據(jù)發(fā)送和接收方可以同時(shí)互相通信.如圖3所示，集群內(nèi)主機(jī)Node1和Node2的通信過(guò)程.

圖3 通信模型Fig.3 Communication model

為了實(shí)現(xiàn)本文的通信方案，我們自定義了通信協(xié)議，各字段含義與占用字節(jié)數(shù)如圖4所示.DPDK是基于數(shù)據(jù)鏈路層的數(shù)據(jù)傳輸，Ethernet數(shù)據(jù)幀頭內(nèi)的目的MAC字段需要根據(jù)上層應(yīng)用傳入的目的節(jié)點(diǎn)決定.因此，需要實(shí)現(xiàn)類似于傳統(tǒng)ARP網(wǎng)絡(luò)協(xié)議的機(jī)制，可以根據(jù)節(jié)點(diǎn)編號(hào)獲取目的主機(jī)的MAC地址列表，并本地緩存.上層用戶應(yīng)用需要填充服務(wù)類型、目的節(jié)點(diǎn)編號(hào)、目的回環(huán)端口、源節(jié)點(diǎn)編號(hào)、源回環(huán)端口、數(shù)據(jù)長(zhǎng)度以及數(shù)據(jù)字段.Ethernet數(shù)據(jù)幀頭內(nèi)MAC地址有基于DPDK的模塊進(jìn)行填充，并通過(guò)負(fù)載均衡算法，選擇合適的網(wǎng)口進(jìn)行發(fā)送.

圖4 協(xié)議字段Fig.4 Protocol field

4.2 內(nèi)存模型

DPDK提供的許多內(nèi)存對(duì)象模型來(lái)應(yīng)對(duì)數(shù)據(jù)包的高速處理，本文利用MBuf與ring內(nèi)存模型進(jìn)行數(shù)據(jù)的處理.如圖5所示，用戶應(yīng)用UA_1首先與本地回環(huán)公共端口進(jìn)行連接(TCP需要，UDP不需要)，連接建立后即可發(fā)送數(shù)據(jù)，并且在接收端口進(jìn)行數(shù)據(jù)接收.DPDK模塊的主邏輯核在本地回環(huán)公共端口進(jìn)行連接接入和數(shù)據(jù)接收，如果為TCP連接，需要將用戶端的連接端口和連接套接字sock_fd對(duì)象記錄到TCP_conn_Table 表中，UDP則不需要此步操作.主邏輯核接收到傳輸數(shù)據(jù)，首先從DPDK_rte環(huán)境中申請(qǐng)MBuf對(duì)象，并填充數(shù)據(jù)段以及節(jié)點(diǎn)編號(hào)、端口等信息，并將其放入由多個(gè)ring組成的公共發(fā)送緩沖區(qū)Public_send_buffer中.

DPDK模塊的多個(gè)從邏輯核將從公共發(fā)送緩沖區(qū)Public_send_buffer中取出待發(fā)送MBuf，根據(jù)其目的節(jié)點(diǎn)和源節(jié)點(diǎn)的編號(hào)，從Node_MACs_table表中根據(jù)負(fù)載均衡算法和輪詢算法選出本地發(fā)送網(wǎng)卡和目的接收網(wǎng)卡，將其MAC地址填充到MBuf的Ethernet數(shù)據(jù)幀頭內(nèi)，并在相應(yīng)的網(wǎng)卡端口進(jìn)行數(shù)據(jù)發(fā)送.多個(gè)從邏輯核也從各網(wǎng)卡端口不停地接收數(shù)據(jù)，根據(jù)數(shù)據(jù)包的服務(wù)類型字段和端口字段將數(shù)據(jù)包發(fā)送到對(duì)應(yīng)的本地回環(huán)端口上.如果是TCP連接的數(shù)據(jù)包，需要通過(guò)TCP_conn_Table 表查找對(duì)應(yīng)的連接套接字sock_fd，并將數(shù)據(jù)發(fā)送到該sock_fd.

4.3 端口負(fù)載均衡模型

對(duì)于多端口并行通信，端口負(fù)載均衡是必不可少的.傳統(tǒng)的端口分發(fā)策略包括平衡循環(huán)法和權(quán)重輪詢法，由于其只考慮數(shù)據(jù)收發(fā)的公平性，并未考慮到實(shí)際運(yùn)行環(huán)境(如端口負(fù)載、端口性能等)，容易出現(xiàn)端口擁塞和大量丟包問(wèn)題.高效的端口負(fù)載均衡算法才能夠保證數(shù)據(jù)的高速率傳輸，過(guò)于復(fù)雜的算法并不適用.為了保證數(shù)據(jù)傳輸?shù)母咝院头€(wěn)定性，根據(jù)網(wǎng)口的實(shí)時(shí)負(fù)載信息，本文提出一種動(dòng)態(tài)負(fù)載均衡機(jī)制，如圖6所示.

發(fā)送核心從公共發(fā)送緩沖區(qū)Public_send_buffer中取出待發(fā)送mbuf，并從中提取五元組信息Quintuple(ptype，s_node，d_node，s_pump，d_pump)，其中s_node表示源節(jié)點(diǎn)編號(hào)，d_node表示目的節(jié)點(diǎn)編號(hào)，s_pump表示源端口號(hào)，d_pump表示目的端口號(hào)，ptype表示服務(wù)類型.首先，利用微軟拓普利茲算法對(duì)提取到的五元組信息計(jì)算散列值，并與端口總數(shù)進(jìn)行取模運(yùn)算，選擇出發(fā)送網(wǎng)口.根據(jù)選擇出的網(wǎng)口負(fù)載情況，決定是否調(diào)用調(diào)整函數(shù)重新選擇合適的發(fā)送網(wǎng)口.然后，根據(jù)輪詢算法選擇出目的節(jié)點(diǎn)的接收端口.最終得到一個(gè)最四元組Quad(s_port，s_mac，d_port，d_mac)，對(duì)應(yīng)信息填入以太網(wǎng)包頭后，調(diào)用DPDK端口發(fā)送數(shù)據(jù).

圖5 內(nèi)存模型Fig.5 Memory model

根據(jù)DPDK提供的網(wǎng)口統(tǒng)計(jì)信息函數(shù)所獲取到的網(wǎng)卡動(dòng)態(tài)參數(shù)，建立網(wǎng)口負(fù)載信息模型，對(duì)端口選擇提供參考.各符號(hào)在表1中進(jìn)行了詳細(xì)的說(shuō)明.

圖6 端口負(fù)載均衡模型Fig.6 Port load balancing model

對(duì)于普遍的全雙工網(wǎng)卡，我們能夠得到6個(gè)基本的動(dòng)態(tài)參數(shù)N_ip_porti，N_op_porti，N_ib_porti，N_ob_porti，N_imp_porti，N_iep_porti.通過(guò)時(shí)間周期T進(jìn)行采集，可以計(jì)算出網(wǎng)口在T周期內(nèi)的各參數(shù)的速率狀態(tài)V_ip_porti，V_op_porti，V_ib_porti，V_ob_porti，V_imp_porti，V_iep_porti，計(jì)算方式如公式(1)-式(7)所示.

(1)

(2)

(3)

(4)

(5)

(6)

(7)

(8)

(9)

(10)

(11)

(12)

(13)

(14)

表1 符號(hào)描述Table 1 Symbol description

為防止負(fù)載信息因采集干擾而出現(xiàn)突變，提高負(fù)載信息準(zhǔn)確性，本文對(duì)計(jì)算得到的網(wǎng)口負(fù)載率進(jìn)行自動(dòng)調(diào)節(jié)，使其平滑過(guò)渡.平滑過(guò)渡計(jì)算公式如公式(15)、公式(16)所示，其中r為調(diào)整因子，通常設(shè)置為0.8.

Li*_porti(t)=r×Li_porti(t)+(1-r)×Li_porti(t-1)

(15)

Lo*_porti(t)=r×Lo_porti(t)+(1-r)×Lo_porti(t-1)

(16)

為了衡量當(dāng)前網(wǎng)口負(fù)載率相比其他網(wǎng)口負(fù)載率是否過(guò)高，提出網(wǎng)口負(fù)載均衡度.網(wǎng)口負(fù)載均衡度能夠體現(xiàn)出網(wǎng)口之間負(fù)載率的差異程度，對(duì)于是否調(diào)用調(diào)整函數(shù)具有參考價(jià)值.網(wǎng)口接收負(fù)載均衡度和發(fā)送負(fù)載均衡度由公式(19)、公式(20)給出定義.對(duì)于發(fā)送網(wǎng)口選擇，當(dāng)網(wǎng)口發(fā)送負(fù)載均衡度超過(guò)用戶定義的負(fù)載均衡度閾值δ時(shí)，調(diào)用調(diào)整函數(shù)重新選擇合適的發(fā)送網(wǎng)口；對(duì)于接收網(wǎng)口選擇，當(dāng)網(wǎng)口接收負(fù)載均衡度超過(guò)用戶定義的負(fù)載均衡度閾值δ時(shí)，調(diào)用調(diào)整函數(shù)重新選擇合適的接收網(wǎng)口.最終返回最優(yōu)的網(wǎng)口信息四元組Quad(s_port, s_mac, d_port, d_mac).

(17)

(18)

(19)

(20)

4.4 帶寬分配模型

由于本地回環(huán)機(jī)制的帶寬遠(yuǎn)遠(yuǎn)高于網(wǎng)卡的帶寬，因此需要對(duì)用戶應(yīng)用的發(fā)送進(jìn)行限制.而且，在多用戶應(yīng)用發(fā)送數(shù)據(jù)時(shí)，還必須保證帶寬公平性，限制每個(gè)用戶應(yīng)用的發(fā)送帶寬.用戶應(yīng)用在發(fā)送數(shù)據(jù)時(shí)，可以根據(jù)速率調(diào)節(jié)模塊計(jì)算值動(dòng)態(tài)調(diào)整實(shí)時(shí)發(fā)送速率.如圖7所示，DPDK模塊將多網(wǎng)卡的總帶寬共享到Share_info中的Total_BW.每個(gè)應(yīng)用在發(fā)送數(shù)據(jù)之前，需要增加Share_info中的應(yīng)用數(shù)量APP_NB.Rate_BW 為DPDK模塊對(duì)所有網(wǎng)卡可用帶寬的實(shí)時(shí)監(jiān)控值.

圖7 帶寬分配模型Fig.7 Bandwidth allocation model

Vavailable_ob_porti(t)=Vmax_ob_porti-V_ob_porti(t)

(21)

(22)

(23)

(24)

(25)

5 實(shí) 驗(yàn)

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

為了驗(yàn)證本文方案的性能，我們使用10臺(tái)普通主機(jī)和一臺(tái)48口千兆二層交換機(jī)搭建邊緣集群.服務(wù)器配置詳細(xì)信息如表2所示.每臺(tái)服務(wù)器CPU為8核心Intel Xeon E3-1230 V2@3.3Ghz，兩張4口Intel-I350-T4千兆網(wǎng)卡，共8網(wǎng)口.BPCM系統(tǒng)是基于DPDK-17.11.3版本開(kāi)發(fā)，配置了8G大頁(yè)內(nèi)存，端口接收隊(duì)列和發(fā)送隊(duì)列各1個(gè)，且大小為1024，可調(diào)節(jié).由于服務(wù)器CPU為8核心，且有8個(gè)網(wǎng)口，為避免CPU核心全占用對(duì)實(shí)驗(yàn)數(shù)據(jù)產(chǎn)生影響，本文采用4張網(wǎng)卡作為多網(wǎng)卡傳輸性能測(cè)試，占用5個(gè)CPU核心進(jìn)行數(shù)據(jù)處理.

表2 主機(jī)配置信息Table 2 Host configuration information

實(shí)驗(yàn)前，我們首先使用Iperf3軟件對(duì)主機(jī)的本地回環(huán)機(jī)制的帶寬進(jìn)行了測(cè)試，測(cè)試結(jié)果如表3所示.從表3中可以看出，隨著線程數(shù)量的增加，TCP和UDP帶寬有所增加，但當(dāng)線程數(shù)量超過(guò)3時(shí)，帶寬不再增加.而且在多線程時(shí)，各線程均勻分配總帶寬.

表3 本地回環(huán)帶寬測(cè)試Table 3 Local loop-back bandwidth test

5.2 性能評(píng)估

由于本文方案的DPDK模塊并未實(shí)現(xiàn)可靠傳輸，因此選取傳統(tǒng)UDP通信進(jìn)行對(duì)比.套接字本地回環(huán)機(jī)制的TCP和UDP通信帶寬遠(yuǎn)遠(yuǎn)高于多張網(wǎng)卡的疊加帶寬，并非本文方案的通信瓶頸，因此實(shí)驗(yàn)中本地回環(huán)選取TCP或者UDP，并不會(huì)對(duì)實(shí)驗(yàn)數(shù)據(jù)產(chǎn)生太大影響.在接下來(lái)的實(shí)驗(yàn)中，我們方案的本地回環(huán)選取UDP作為通信方式.我們討論了在單張千兆網(wǎng)卡和10張千兆網(wǎng)卡兩種情況下傳統(tǒng)UDP與本文方案的傳輸性能.通過(guò)多次發(fā)送10GB的數(shù)據(jù)，并且選取數(shù)據(jù)包大小分別為64B、128B、256B、516B、1024B，統(tǒng)計(jì)傳輸速率、丟包率以及傳輸延時(shí).

如圖8所示，在單張千兆網(wǎng)卡和單條連接的實(shí)驗(yàn)中，得益于DPDK用戶驅(qū)動(dòng)和內(nèi)存大頁(yè)等技術(shù)，使數(shù)據(jù)包的處理時(shí)間大幅降低，基于DPDK的本文傳輸方案在傳輸速率、丟包率和延時(shí)上都優(yōu)于傳統(tǒng)UDP通信.

現(xiàn)有操作系統(tǒng)對(duì)于多網(wǎng)卡的并行傳輸并不友好，雖然內(nèi)核中提供多網(wǎng)卡的bonding模塊，但該模塊主要用于網(wǎng)絡(luò)負(fù)載均衡與冗余.要實(shí)現(xiàn)帶寬的增加，還需要交換機(jī)支持IEEE802.3ad 動(dòng)態(tài)鏈路聚合.bonding模塊雖然能夠增加總帶寬，但是無(wú)法突破單個(gè)連接的帶寬限制(千兆網(wǎng)卡的理論速率).要實(shí)現(xiàn)總帶寬的傳輸速率，還需要多連接與多線程技術(shù)的配合.為了進(jìn)行多網(wǎng)卡并行傳輸性能對(duì)比，我們將發(fā)送服務(wù)器和接收服務(wù)器的4張網(wǎng)卡通過(guò)Linux系統(tǒng)的bonding模塊綁定為模式4，并且啟用LAN內(nèi)交換機(jī)的LACP功能.

圖8 單張千兆網(wǎng)口-單條連接Fig.8 Single gigabit NIC-single connection

在多網(wǎng)卡單條連接的實(shí)驗(yàn)中，傳統(tǒng)UDP由于受到操作系統(tǒng)bonding模式底層實(shí)現(xiàn)的限制，傳輸速率無(wú)法突破單張網(wǎng)卡的理論速率.本文傳輸方案基于DPDK多核技術(shù)的支持，能夠?qū)?張網(wǎng)卡的總帶寬充分利用起來(lái)，使用戶在單條連接內(nèi)即可使用多張網(wǎng)卡的疊加帶寬，實(shí)驗(yàn)結(jié)果如圖9所示.

在多網(wǎng)卡多連接的實(shí)驗(yàn)中，傳統(tǒng)UDP通信方式中我們創(chuàng)建4個(gè)線程，每個(gè)線程建立一條連接，每條連接保證使用底層不同的物理網(wǎng)卡，進(jìn)行并發(fā)性數(shù)據(jù)發(fā)送測(cè)試，結(jié)果如圖10所示.傳統(tǒng)的UDP雖然也可以使用多張網(wǎng)卡的疊加帶寬，但是受限于系統(tǒng)內(nèi)核協(xié)議棧的處理耗時(shí)，其帶寬利用率不高，丟包率和傳輸時(shí)延大大增加.而且多連接多線程技術(shù)會(huì)增加編程難度，需要額外的數(shù)據(jù)同步技術(shù)支持，在大多數(shù)數(shù)據(jù)傳輸場(chǎng)景并不適用.本文的方案能夠在單條連接內(nèi)提供多張網(wǎng)卡的疊加帶寬，不僅降低了編程難度，而且傳輸延時(shí)大幅降低.

圖9 4張千兆網(wǎng)口-單條連接Fig.9 Four gigabit NICs-single connection

圖10 4張千兆網(wǎng)口-多條連接Fig.10 Four gigabit NICs-multiple connections

對(duì)本文的端口負(fù)載均衡算法性能進(jìn)行驗(yàn)證，與傳統(tǒng)的端口輪詢算法進(jìn)行對(duì)比.通過(guò)多次發(fā)送10GB的數(shù)據(jù)，并且選取數(shù)據(jù)包大小分別為64B、128B、256B、516B、1024B.統(tǒng)計(jì)了各網(wǎng)口的負(fù)載率以及丟包率.如圖11(a)所示，本文提出的端口負(fù)載均衡算法比輪詢算法使各網(wǎng)口的負(fù)載率更加均勻，而且丟包率也相應(yīng)的減少，如圖11(b)所示.

圖11 端口負(fù)載均衡Fig.11 Port load balancing

本文的速率調(diào)節(jié)模塊是為了保證多用戶應(yīng)用帶寬公平性和減少用戶無(wú)效數(shù)據(jù)傳輸而設(shè)計(jì)的.實(shí)驗(yàn)中模擬5個(gè)應(yīng)用程序依次發(fā)送10GB數(shù)據(jù)，并且選取數(shù)據(jù)包大小分別為64B、128B、256B、516B、1024B統(tǒng)計(jì)各應(yīng)用的占用帶寬和丟包率.如圖12(a)所示，總帶寬幾乎完全利用，而且各用戶應(yīng)用均勻的分配帶寬.圖12(a)顯示速率調(diào)節(jié)一定程度上減少丟包率.

圖12 多應(yīng)用帶寬分配Fig.12 Multi-application bandwidth allocation

6 總 結(jié)

本文在邊緣集群內(nèi)對(duì)低成本、高速率通信帶寬需求的驅(qū)動(dòng)下，基于DPDK提出廉價(jià)多網(wǎng)卡提高帶寬的方案.本文的方案不僅能夠在單條連接內(nèi)提供多張網(wǎng)卡的疊加帶寬，降低編程難度，而且在可擴(kuò)展性、可升級(jí)性、實(shí)施簡(jiǎn)便性上都更具優(yōu)勢(shì).利用操作系統(tǒng)的Socket本地回環(huán)機(jī)制，本文的方案還能夠?yàn)橛脩籼峁┱Z(yǔ)言無(wú)關(guān)的調(diào)用接口.通過(guò)本文設(shè)計(jì)的端口負(fù)載均衡算法和速率調(diào)節(jié)模塊，能夠在均衡使用帶寬的同時(shí)，減少丟包率和傳輸時(shí)延.最后，我們也做了成本對(duì)比，如表4所示，本文的通信方案能夠?qū)⑦吘壖簝?nèi)組網(wǎng)的成本降低2/3，同時(shí)提供相同的通信帶寬.

本文的工作雖然能夠以低成本提供高帶寬，但在可靠性方面未進(jìn)行研究.接下來(lái)的工作我們將在硬件可靠性和軟件可靠性等方面進(jìn)一步研究，如多交換機(jī)備份，可靠傳輸協(xié)議等.

表4 搭建10臺(tái)規(guī)模萬(wàn)兆帶寬連接邊緣集群的網(wǎng)絡(luò)設(shè)備成本Table 4 Cost of building 10 sets of 10-Gigabit bandwidth network equipment connected to the edge cluster