適用于邊緣計(jì)算的6H并行計(jì)算架構(gòu)

李 磊,鄭黎明,王宏義,柴永毅,劉培國(guó)

(1.國(guó)防科技大學(xué)電子科學(xué)學(xué)院,湖南 長(zhǎng)沙 410073;2.中國(guó)電子科技集團(tuán)公司第十五研究所,北京 100083;3.軍委裝備發(fā)展部體系評(píng)估中心,北京 100009)

1 引言

近年來,物聯(lián)網(wǎng)、大數(shù)據(jù)、人工智能、5G等技術(shù)的大規(guī)模應(yīng)用催生了一大批新的互聯(lián)網(wǎng)應(yīng)用,如智慧城市、智慧工廠、自動(dòng)駕駛、增強(qiáng)現(xiàn)實(shí)、虛擬現(xiàn)實(shí)等。傳統(tǒng)的云集中式計(jì)算模型采用“云+端”兩級(jí)模式,將傳感器產(chǎn)生的所有數(shù)據(jù)通過網(wǎng)絡(luò)上傳至云計(jì)算中心,利用云計(jì)算中心的超強(qiáng)計(jì)算能力來集中解決應(yīng)用的計(jì)算需求問題[1]。然而,針對(duì)萬物互聯(lián)的泛在式計(jì)算需求,云計(jì)算集中式計(jì)算模式存在一系列問題:

(1)云計(jì)算中心接入帶寬和計(jì)算資源無法支撐接入設(shè)備的指數(shù)式增長(zhǎng)[2]。

(2)無法滿足低延時(shí)、高服務(wù)質(zhì)量類應(yīng)用需求。

(3)存在丟失大量本地環(huán)境信息的風(fēng)險(xiǎn),可能導(dǎo)致大數(shù)據(jù)分析效果不理想。

(4)存在隱私泄露和核心數(shù)據(jù)不受控的風(fēng)險(xiǎn)。

為解決上述問題,廣大研究人員從不同的角度提出了不同的解決思路[3,4],如移動(dòng)邊緣計(jì)算MEC(Mobil-Edge Computing)、霧計(jì)算(Fog Computing)和移動(dòng)云計(jì)算MCC(Mobil Could Computing);各大學(xué)及研究組織也啟動(dòng)了多個(gè)相關(guān)項(xiàng)目,如微云(Cloudlet)、CDRD(Central Office Re- Architected as a Datacenter)、Nebula和FemtoCloud等。本文總結(jié)如下:

(1)霧計(jì)算。為滿足萬物互聯(lián)的泛在式計(jì)算需求,思科拓展了云計(jì)算的概念,提出將計(jì)算資源、存儲(chǔ)資源、數(shù)據(jù)及數(shù)據(jù)分析服務(wù)擴(kuò)展到網(wǎng)絡(luò)邊緣,使用戶能夠在本地分析和管理數(shù)據(jù),即霧計(jì)算。霧計(jì)算是一種面向物聯(lián)網(wǎng)的分布式計(jì)算模型,其計(jì)算節(jié)點(diǎn)不是性能強(qiáng)大的服務(wù)器,而是性能較弱、更為分散的各種功能計(jì)算機(jī),如IoT節(jié)點(diǎn)、聯(lián)網(wǎng)的車輛、無線傳感器節(jié)點(diǎn)、路由網(wǎng)關(guān)和各類控制器等。霧計(jì)算強(qiáng)調(diào)的是所有空閑的聯(lián)網(wǎng)設(shè)備都共享計(jì)算和存儲(chǔ)資源,重點(diǎn)是讓計(jì)算和存儲(chǔ)在空閑設(shè)備之間遷移,是典型的去中心化分布式計(jì)算環(huán)境。

(2)移動(dòng)邊緣計(jì)算。在5G技術(shù)的推動(dòng)下,電信標(biāo)準(zhǔn)化組織和移動(dòng)運(yùn)營(yíng)商為避免移動(dòng)承載網(wǎng)絡(luò)被管道化,提出希望將5G網(wǎng)絡(luò)與移動(dòng)互聯(lián)網(wǎng)及物聯(lián)網(wǎng)業(yè)務(wù)深度融合,以提升移動(dòng)網(wǎng)絡(luò)帶寬的經(jīng)濟(jì)價(jià)值。為此,歐洲電信標(biāo)準(zhǔn)協(xié)會(huì)ETSI(European Telecommunications Standards Institute)提出了移動(dòng)邊緣計(jì)算,其基本思想是把云平臺(tái)從移動(dòng)核心網(wǎng)絡(luò)內(nèi)部遷移到移動(dòng)接入網(wǎng)邊緣,實(shí)現(xiàn)計(jì)算及存儲(chǔ)資源的彈性利用。這一概念將傳統(tǒng)電信蜂窩網(wǎng)絡(luò)與互聯(lián)網(wǎng)及物聯(lián)網(wǎng)業(yè)務(wù)進(jìn)行了深度融合,旨在減少移動(dòng)業(yè)務(wù)交互的端到端時(shí)延,發(fā)掘無線網(wǎng)絡(luò)的內(nèi)在能力,從而提升用戶體驗(yàn),給電信運(yùn)營(yíng)商的運(yùn)作模式帶來全新變革,并建立新型的產(chǎn)業(yè)鏈及網(wǎng)絡(luò)生態(tài)圈。

(3)移動(dòng)云計(jì)算。移動(dòng)云計(jì)算是在云計(jì)算基礎(chǔ)上,針對(duì)用戶端計(jì)算資源和存儲(chǔ)資源有限的特征,引入移動(dòng)代理技術(shù),實(shí)現(xiàn)計(jì)算服務(wù)和存儲(chǔ)服務(wù)在云端、邊緣節(jié)點(diǎn)、用戶端動(dòng)態(tài)遷移的計(jì)算模式[5]。當(dāng)用戶端移動(dòng)設(shè)備的計(jì)算和存儲(chǔ)資源無法滿足計(jì)算需求時(shí),移動(dòng)云計(jì)算框架將大塊數(shù)據(jù)的存儲(chǔ)和密集計(jì)算任務(wù)交給可能是邊緣節(jié)點(diǎn)也可能是云計(jì)算中心的遠(yuǎn)程主機(jī)執(zhí)行。Cloudlet是卡內(nèi)基梅隆大學(xué)一個(gè)研究組織對(duì)移動(dòng)云計(jì)算模式的一種典型實(shí)現(xiàn)[6]。

雖然移動(dòng)邊緣計(jì)算、霧計(jì)算、移動(dòng)云計(jì)算等的出發(fā)點(diǎn)不盡相同,但它們都體現(xiàn)了萬物聯(lián)網(wǎng)時(shí)代對(duì)新計(jì)算模式的需求,實(shí)時(shí)的服務(wù)響應(yīng)速度、穩(wěn)定的服務(wù)質(zhì)量、為用戶提供定制化服務(wù)已逐漸成為用戶關(guān)注的焦點(diǎn)。本文將計(jì)算、存儲(chǔ)等服務(wù)遷移到更靠近數(shù)據(jù)源所在的網(wǎng)絡(luò)上運(yùn)行。盡可能減小數(shù)據(jù)往返云端的延時(shí)、減少網(wǎng)絡(luò)帶寬需求的計(jì)算模式統(tǒng)稱為邊緣計(jì)算。

2 邊緣計(jì)算架構(gòu)分析

學(xué)術(shù)界和產(chǎn)業(yè)界提出并實(shí)現(xiàn)了多種邊緣計(jì)算體系架構(gòu),但大部分是參考云計(jì)算體系架構(gòu),將邊緣計(jì)算節(jié)點(diǎn)簡(jiǎn)單地等同云計(jì)算節(jié)點(diǎn),采用軟件定義網(wǎng)絡(luò)SDN(Software Defined Network)和網(wǎng)絡(luò)功能虛擬化NFV(Network Functions Virtualization)實(shí)現(xiàn)計(jì)算節(jié)點(diǎn)的動(dòng)態(tài)管理。最典型的有針對(duì)5G技術(shù)發(fā)展提出的移動(dòng)邊緣計(jì)算體系架構(gòu),如ETSI發(fā)布的MEC(Mobile-Edge Computing)技術(shù)白皮書[7],給出了移動(dòng)邊緣計(jì)算的詳細(xì)架構(gòu),其核心是MEC服務(wù)器,它用于提供計(jì)算資源、存儲(chǔ)空間、連接以及相關(guān)無線網(wǎng)絡(luò)的實(shí)時(shí)信息等。MEC服務(wù)平臺(tái)主要由3部分組成:主機(jī)平臺(tái)、應(yīng)用平臺(tái)及APP管理平臺(tái)。MEC主機(jī)平臺(tái)分為MEC的硬件資源層與MEC的虛擬層。MEC硬件資源層主要包括CPU、GPU、內(nèi)存、硬盤和網(wǎng)絡(luò)等資源,MEC虛擬層提供IaaS(Infrastructure as a Ser- vice)服務(wù)。MEC應(yīng)用平臺(tái)主要為MEC平臺(tái)上的各類應(yīng)用程序提供一組標(biāo)準(zhǔn)化的、通用化的基礎(chǔ)服務(wù),包括服務(wù)注冊(cè)、服務(wù)之間的通信、無線網(wǎng)絡(luò)服務(wù)、流量卸載功能。APP管理平臺(tái)主要是通過一組標(biāo)準(zhǔn)的API接口,實(shí)現(xiàn)對(duì)托管的APP及APP虛擬機(jī)進(jìn)行生命周期管理。

文獻(xiàn)[8]針對(duì)物聯(lián)網(wǎng)的計(jì)算需求,提出了統(tǒng)一的霧計(jì)算架構(gòu),并對(duì)霧計(jì)算的分類法進(jìn)行了研究。文獻(xiàn)[9]對(duì)移動(dòng)云計(jì)算進(jìn)行了總結(jié),對(duì)比分析了各種已經(jīng)實(shí)現(xiàn)的移動(dòng)云計(jì)算體系架構(gòu)。整體上來說,移動(dòng)邊緣計(jì)算、霧計(jì)算、移動(dòng)云計(jì)算在體系架構(gòu)上都是基于云計(jì)算體系架構(gòu),進(jìn)行適當(dāng)?shù)男薷耐晟啤Ｅc云計(jì)算體系架構(gòu)不同的主要是更加關(guān)注計(jì)算任務(wù)在多個(gè)計(jì)算節(jié)點(diǎn)之間的遷移。

還有一些研究針對(duì)某一類特定的應(yīng)用場(chǎng)景設(shè)計(jì)了特定的邊緣計(jì)算體系結(jié)構(gòu)。文獻(xiàn)[10]針對(duì)物聯(lián)網(wǎng)設(shè)備設(shè)計(jì)了PhiPU,使用異構(gòu)多核的結(jié)構(gòu)并行處理深度學(xué)習(xí)任務(wù)和普通的計(jì)算任務(wù)(實(shí)時(shí)操作系統(tǒng))。文獻(xiàn)[11]為解決云中心計(jì)算模式在深度學(xué)習(xí)方面的弊端,提出了一種自動(dòng)化增強(qiáng)式計(jì)算框架(In-situ AI),該框架通過數(shù)據(jù)診斷選擇最小數(shù)據(jù)移動(dòng)的計(jì)算模式,將深度學(xué)習(xí)任務(wù)部署到邊緣計(jì)算節(jié)點(diǎn)。文獻(xiàn)[12]針對(duì)大規(guī)模視頻監(jiān)控應(yīng)用,采用3層計(jì)算結(jié)構(gòu)解決圖像的實(shí)時(shí)計(jì)算問題。文獻(xiàn)[13]針對(duì)霧計(jì)算節(jié)點(diǎn)組織問題,提出采用軟件定義網(wǎng)絡(luò)的方式組織所有霧計(jì)算節(jié)點(diǎn),實(shí)現(xiàn)節(jié)點(diǎn)之間的消息路由,針對(duì)單個(gè)節(jié)點(diǎn),提出了一種實(shí)現(xiàn)隱私保護(hù)的分層體系結(jié)構(gòu)。

綜上所述,提出和實(shí)現(xiàn)的邊緣計(jì)算構(gòu)架基本都是基于虛擬化、SDN、NFV技術(shù),解決了很多現(xiàn)實(shí)問題,但深入分析后發(fā)現(xiàn)它們依然存在以下問題:

(1)虛擬化導(dǎo)致系統(tǒng)配置優(yōu)化成本增加。

已有一些研究證明,Hypervisors虛擬化技術(shù)對(duì)性能的影響很小。但是,通過分析及大量的實(shí)驗(yàn)發(fā)現(xiàn),達(dá)到虛擬機(jī)最優(yōu)性能往往需要根據(jù)具體的應(yīng)用、資源情況(計(jì)算、存儲(chǔ)、網(wǎng)絡(luò))進(jìn)行有針對(duì)性的優(yōu)化[14]。文獻(xiàn)[15]通過實(shí)驗(yàn)證明,不同的虛擬機(jī)技術(shù),不同的測(cè)試用例,往往導(dǎo)致性能差異很大。每個(gè)虛擬機(jī)技術(shù)有不同的適用場(chǎng)景,每個(gè)虛擬機(jī)需要根據(jù)實(shí)際使用場(chǎng)景進(jìn)行有針對(duì)性的優(yōu)化才能實(shí)現(xiàn)最佳的性能。對(duì)具體的實(shí)驗(yàn)數(shù)據(jù)進(jìn)行分析可知,在不同硬件平臺(tái)上采用通用的虛擬機(jī)配置,不進(jìn)行有針對(duì)性的優(yōu)化,將導(dǎo)致性能急劇下降。特別是在霧計(jì)算環(huán)境下,需要將各種移動(dòng)計(jì)算資源納入計(jì)算體系,這將導(dǎo)致系統(tǒng)優(yōu)化配置難度激增。

(2)虛擬化技術(shù)資源管理的粒度不夠細(xì)。

以虛擬化技術(shù)構(gòu)建的計(jì)算架構(gòu),通常將面向特定服務(wù)的一組應(yīng)用部署在一個(gè)虛擬機(jī)中。Hypervisors生命周期管理的粒度為虛擬機(jī),但是許多計(jì)算任務(wù)需要對(duì)整個(gè)計(jì)算任務(wù)進(jìn)行并行化劃分,消除計(jì)算性能瓶頸,采用并行計(jì)算和微服務(wù)的思想提高整體性能。特別是在邊緣計(jì)算環(huán)境下,計(jì)算節(jié)點(diǎn)的可用資源有限,往往希望將任務(wù)進(jìn)行細(xì)粒度劃分后分派到不同的計(jì)算節(jié)點(diǎn)。

(3)虛擬機(jī)之間通信和遷移成本過高。

虛擬化技術(shù)幫助云計(jì)算中心提升伸縮性和靈活性,集中式管理簡(jiǎn)化了資源和服務(wù)的管理和維護(hù)。相對(duì)云計(jì)算中心,邊緣計(jì)算環(huán)境地理更加分布、硬件更加異構(gòu)、可用資源更加動(dòng)態(tài)、I/O操作更加頻繁。虛擬機(jī)需要構(gòu)建虛擬化操作系統(tǒng),導(dǎo)致整體容量達(dá)上百兆,非常不利于在動(dòng)態(tài)計(jì)算環(huán)境下進(jìn)行遷移。文獻(xiàn)[15]已經(jīng)證明在I/O操作密集時(shí),虛擬機(jī)的性能將大幅下降。

(4)不同虛擬機(jī)技術(shù)的虛擬化主機(jī)之間互操作差。

到現(xiàn)階段為止,虛擬化技術(shù)及虛擬化產(chǎn)品眾多,有商用的也有開源的,超過10種。不同的虛擬機(jī)采用的技術(shù)和方案不同,虛擬機(jī)之間的通信沒有統(tǒng)一標(biāo)準(zhǔn),導(dǎo)致通信困難。計(jì)算任務(wù)在同類虛擬機(jī)之間能輕松遷移,但是在不同技術(shù)的虛擬機(jī)之間遷移則存在諸多困難。

綜上,現(xiàn)有針對(duì)云計(jì)算的虛擬化技術(shù)不是特別適合邊緣計(jì)算場(chǎng)景,需要更加輕量級(jí)的虛擬化技術(shù)。另一方面,已經(jīng)有研究表明,采用Docker等輕量級(jí)虛擬化技術(shù)來處理邊緣計(jì)算任務(wù)能取得更好的效果[16]。本文針對(duì)邊緣計(jì)算場(chǎng)景,凝練了高性能、高可用、高可擴(kuò)展、高模塊化、高可伸縮、高易用的6H計(jì)算需求,基于輕量化虛擬機(jī)技術(shù),充分借鑒并拓展并行計(jì)算架構(gòu),提出了適用于邊緣計(jì)算環(huán)境的6H并行計(jì)算架構(gòu)。

3 6H計(jì)算需求

針對(duì)物聯(lián)網(wǎng)、5G等典型應(yīng)用場(chǎng)景,邊緣計(jì)算架構(gòu)需要滿足以下6H計(jì)算需求:

(1)高可用性。5G應(yīng)用包括高可靠、低時(shí)延通信場(chǎng)景,遠(yuǎn)程醫(yī)療、自動(dòng)駕駛、無人機(jī)控制等應(yīng)用,對(duì)網(wǎng)絡(luò)和服務(wù)的可用性提出了嚴(yán)苛的要求。但是,在邊緣計(jì)算動(dòng)態(tài)環(huán)境,計(jì)算節(jié)點(diǎn)動(dòng)態(tài)加入和退出、任務(wù)動(dòng)態(tài)裝載,所以邊緣計(jì)算體系架構(gòu)需要在動(dòng)態(tài)環(huán)境下解決高可用問題。

(2)高性能。邊緣計(jì)算環(huán)境中很多計(jì)算節(jié)點(diǎn)是網(wǎng)絡(luò)邊緣設(shè)備、智能移動(dòng)設(shè)備,各計(jì)算節(jié)點(diǎn)存在計(jì)算資源受限的情況。為了在資源受限的節(jié)點(diǎn)上運(yùn)行深度學(xué)習(xí)、增強(qiáng)學(xué)習(xí)、圖像處理等人工智能算法,需要提供高性能的計(jì)算架構(gòu),充分整合和利用各計(jì)算節(jié)點(diǎn)的計(jì)算資源,匯聚成高性能的一體化計(jì)算架構(gòu),對(duì)外提供高性能計(jì)算服務(wù)。

(3)高可擴(kuò)展性。在邊緣計(jì)算環(huán)境下,隨著用戶數(shù)量和應(yīng)用的增加,計(jì)算和存儲(chǔ)需求必然不斷增加。計(jì)算架構(gòu)能通過簡(jiǎn)單增加硬件的方式滿足不斷增長(zhǎng)的計(jì)算和存儲(chǔ)需求,即系統(tǒng)性能隨著加入的計(jì)算節(jié)點(diǎn)數(shù)量的增加呈線性增長(zhǎng)。

(4)高模塊化。在高度動(dòng)態(tài)化的邊緣計(jì)算環(huán)境,計(jì)算異常情況明顯增多,需要采用虛擬化技術(shù)有效隔離每個(gè)計(jì)算模塊,限定異常的影響范圍。另一方面,需要對(duì)所有計(jì)算任務(wù)進(jìn)行細(xì)粒度劃分。針對(duì)計(jì)算瓶頸,可以采用并行計(jì)算和軟件定義網(wǎng)絡(luò)等思路,對(duì)計(jì)算瓶頸模塊啟動(dòng)多個(gè)計(jì)算實(shí)例,有效減少系統(tǒng)的部署和集成難度。

(5)高可伸縮性。在邊緣計(jì)算動(dòng)態(tài)環(huán)境下,加入的可用計(jì)算和存儲(chǔ)資源動(dòng)態(tài)變化。計(jì)算架構(gòu)能適應(yīng)不同規(guī)模的硬件條件,既能有效組織少量節(jié)點(diǎn),滿足小規(guī)模計(jì)算和存儲(chǔ)需求,也能適用大規(guī)模計(jì)算節(jié)點(diǎn)環(huán)境,滿足大規(guī)模計(jì)算和存儲(chǔ)需求。

(6)高易用性。相對(duì)普通編程,并行編程的難度較高,需要提供簡(jiǎn)單的編程模型和易用的用戶界面,用戶可以方便地劃分、管理和部署所有計(jì)算任務(wù),提高系統(tǒng)的易用性。

4 6H計(jì)算架構(gòu)

4.1 6H計(jì)算架構(gòu)概述

從物理部署架構(gòu)上看,6H計(jì)算架構(gòu)和移動(dòng)邊緣計(jì)算、霧計(jì)算、移動(dòng)云計(jì)算等架構(gòu)類似,具體部署場(chǎng)景如圖1所示。

在圖1中,邊緣計(jì)算服務(wù)器具有一定的穩(wěn)定性,性能較好,作為主服務(wù)器使用,是6H分布式計(jì)算環(huán)境的核心。物聯(lián)網(wǎng)設(shè)備接入網(wǎng)絡(luò),從屬于不同的邊緣計(jì)算服務(wù)器。邊緣計(jì)算服務(wù)器按照計(jì)算任務(wù)情況、網(wǎng)絡(luò)情況、計(jì)算節(jié)點(diǎn)資源情況,給物聯(lián)網(wǎng)設(shè)備分配計(jì)算任務(wù)。

將地理位置上、邏輯功能上相關(guān)的邊緣計(jì)算服務(wù)器共同組成分布式計(jì)算環(huán)境,采用多網(wǎng)絡(luò)浮動(dòng)IP的集群方式實(shí)現(xiàn)高可用分布式計(jì)算環(huán)境,其組網(wǎng)方式如圖2所示。所有的邊緣服務(wù)器都具備2套網(wǎng)絡(luò)資源,一套用于對(duì)外提供服務(wù)(如果被選中作為主服務(wù)器),一套用于系統(tǒng)內(nèi)部進(jìn)程間通信。

Figure 2 Edge server networking method

單個(gè)計(jì)算節(jié)點(diǎn)計(jì)算架構(gòu)如圖3所示,處于最底層的是CPU、內(nèi)存、網(wǎng)絡(luò)等計(jì)算資源;計(jì)算資源層以上是操作系統(tǒng)層;操作系統(tǒng)層上有虛擬化容量引擎,上面是一個(gè)個(gè)輕量級(jí)虛擬進(jìn)程。在邊緣服務(wù)器上,有APP服務(wù)進(jìn)程和SDN控制進(jìn)程。由于采用輕量化虛擬機(jī)技術(shù),一個(gè)輕量化虛擬機(jī)就對(duì)應(yīng)并行計(jì)算中一個(gè)具體的進(jìn)程,在后面描述的過程中,計(jì)算進(jìn)程等同于輕量化虛擬機(jī)。

Figure 3 Architecture of single computing node

各個(gè)模塊的功能和作用如下所示:

(1)計(jì)算資源層主要包括邊緣服務(wù)器及參與計(jì)算的邊緣設(shè)備所屬資源(包括計(jì)算、存儲(chǔ)和網(wǎng)絡(luò)資源)。

(2)操作系統(tǒng)層主要包括各種不同類型的操作系統(tǒng),核心要求是輕量級(jí)虛擬化技術(shù)需要支持不同的操作系統(tǒng)。

(3)虛擬化容器引擎主要是根據(jù)任務(wù)進(jìn)程管理需要,對(duì)輕量級(jí)虛擬機(jī)進(jìn)行動(dòng)態(tài)裝載、運(yùn)行、停止、卸載及運(yùn)行狀態(tài)監(jiān)控等。

(4)進(jìn)程間通信框架主要是采用并行計(jì)算技術(shù),提供了一套基于消息機(jī)制的進(jìn)程間數(shù)據(jù)傳遞模型,以及一套對(duì)應(yīng)的編程框架。

(5)服務(wù)管理進(jìn)程主要用于實(shí)現(xiàn)各個(gè)服務(wù)的注冊(cè)、性能監(jiān)控、管理等功能,針對(duì)性能要求及瓶頸,根據(jù)計(jì)算策略自動(dòng)在合適的服務(wù)器上啟動(dòng)新的進(jìn)程實(shí)例,并更新全局消息路由信息。

(6)操作支持系統(tǒng)OOS(Operation Support Systems)進(jìn)程,主要對(duì)各個(gè)服務(wù)器、輕量級(jí)虛擬機(jī)的相關(guān)配置及資源進(jìn)行管理。

(7)SDN控制進(jìn)程主要根據(jù)APP服務(wù)進(jìn)程的要求,將用戶請(qǐng)求分解為不同的計(jì)算任務(wù),并將不同的計(jì)算任務(wù)正確路由到不同的計(jì)算節(jié)點(diǎn)及計(jì)算進(jìn)程,計(jì)算結(jié)束后,將結(jié)果反饋給APP服務(wù)進(jìn)程。

(8)APP服務(wù)進(jìn)程主要接收用戶APP發(fā)來的業(yè)務(wù)操作,并將SDN控制進(jìn)程返回的計(jì)算結(jié)果反饋給用戶,典型的如Web服務(wù)器進(jìn)程。

其中SDN控制進(jìn)程和APP服務(wù)進(jìn)程作為主服務(wù)器特有的功能,只部署在邊緣服務(wù)器上。

4.2 交互模型

交互模型規(guī)定了各進(jìn)程/輕量級(jí)虛擬機(jī)之間的交互方式,主要包括通信模式、命令幀格式及消息路由機(jī)制。

進(jìn)程間通信主要在TCP/IP網(wǎng)絡(luò)通信基礎(chǔ)上,充分參考和借鑒并行計(jì)算框架MPI的設(shè)計(jì)思路,支持點(diǎn)對(duì)點(diǎn)、廣播等通信機(jī)制,點(diǎn)對(duì)點(diǎn)通信采用管道方式,支持PULL和PUSH 2種模式。每個(gè)進(jìn)程綁定2個(gè)標(biāo)識(shí),一個(gè)是發(fā)送端標(biāo)識(shí),一個(gè)是接收端標(biāo)識(shí),采用TCP://IP:Port的方式標(biāo)識(shí),其中IP、Port支持通配符。通信模型如圖4所示。

Figure 4 Inter process communication model

系統(tǒng)采用JSON統(tǒng)一定義了進(jìn)程之間交互的消息格式,具體如下所示:

{

Sender_Pid：UINT32;//發(fā)送者進(jìn)程號(hào)

Receiver_Pid：UINT32;//接受者進(jìn)程號(hào)

CMD_Code：UINT32;//命令碼

Task_ID：UINT32;//任務(wù)碼

Frame_Type：UNIT32;//消息幀類別

Frame_NO：UNIT32;//消息幀序號(hào),用于多幀

Priority：UINT32;//消息幀處理優(yōu)先級(jí)

Created_Time：time;//創(chuàng)建時(shí)間

Data_length：UINT32;//消息幀長(zhǎng)度

Custome_Data：String;//客戶自定義

}

消息幀中的CMD_Code是命令碼,命令碼是整個(gè)系統(tǒng)消息處理和路由的核心,每個(gè)服務(wù)器上的服務(wù)管理進(jìn)程管理本機(jī)及本機(jī)附屬的移動(dòng)結(jié)算節(jié)點(diǎn)上的所有計(jì)算進(jìn)程,所有其他進(jìn)程需要向該進(jìn)程注冊(cè),更新消息路由表。其他進(jìn)程在發(fā)送消息時(shí),根據(jù)消息路由表計(jì)算出消息的目的進(jìn)程,實(shí)現(xiàn)業(yè)務(wù)操作的軟件可定義。

4.3 CMD-Worker-Handler編程模型

每個(gè)計(jì)算任務(wù)對(duì)應(yīng)一個(gè)輕量級(jí)虛擬機(jī),也就是一個(gè)典型的計(jì)算進(jìn)程。每個(gè)計(jì)算任務(wù)又按照處理的業(yè)務(wù)不同劃分為多個(gè)功能模塊,也就是劃分成若干個(gè)Worker,每個(gè)Worker對(duì)應(yīng)操作系統(tǒng)原生態(tài)的線程,進(jìn)程作為這些Worker的容器。在進(jìn)程啟動(dòng)時(shí),根據(jù)配置信息動(dòng)態(tài)加載Worker。具體的編程模型如圖5所示。

Figure 5 CMD worker handler programming model

在并行化程序編程時(shí),用戶只需要關(guān)注自己的業(yè)務(wù)邏輯實(shí)現(xiàn)。將業(yè)務(wù)邏輯分解成不同的計(jì)算任務(wù)(Process),再將計(jì)算任務(wù)分解為不同的功能模塊(Worker),功能模塊包含多個(gè)功能需求(Handler),每個(gè)功能需求對(duì)應(yīng)一個(gè)命令碼。將所有任務(wù)分解成命令碼以后,規(guī)劃好全局路由信息。在具體編程時(shí),則只需要擴(kuò)展CMD Handler,在CMD Handler中處理針對(duì)具體消息的處理邏輯。

5 原型系統(tǒng)測(cè)試

考慮到Python的靈活性和C++語言的高效性,本文采用Python/C++混合編程模式實(shí)現(xiàn)了一個(gè)6H計(jì)算框架。其中,隨業(yè)務(wù)變動(dòng)較大的業(yè)務(wù)邏輯采用Python語言實(shí)現(xiàn),相對(duì)固定且要求處理性能的進(jìn)程間通信、消息隊(duì)列管理、高可用等模塊采用C++語言實(shí)現(xiàn),采用Python和C/C++語言的相互調(diào)用機(jī)制實(shí)現(xiàn)2種語言的交互,參數(shù)傳輸采用JSON序列化方式。

測(cè)試環(huán)境包括測(cè)試的實(shí)施場(chǎng)地及測(cè)試系統(tǒng)等內(nèi)容。項(xiàng)目所有的測(cè)試工作都嚴(yán)格按照相應(yīng)的測(cè)試標(biāo)準(zhǔn)設(shè)置測(cè)試環(huán)境,并在測(cè)試前進(jìn)行儀器設(shè)備的校準(zhǔn)。本節(jié)僅對(duì)測(cè)試環(huán)境重點(diǎn)的幾個(gè)方面進(jìn)行說明。

在邊緣計(jì)算典型硬件條件下,采用物聯(lián)網(wǎng)典型用例對(duì)該計(jì)算框架進(jìn)行了測(cè)試。測(cè)試主要關(guān)注計(jì)算架構(gòu)的高性能、高可用、高可擴(kuò)展、高模塊化、高可伸縮方面。高易用性從CMD-Worker-Handler編程模型能充分體現(xiàn)。

5.1 測(cè)試環(huán)境

5.1.1 網(wǎng)絡(luò)環(huán)境

測(cè)試組網(wǎng)如圖6所示,共6臺(tái)邊緣服務(wù)器,通過千兆交換機(jī)實(shí)現(xiàn)互連,相關(guān)的傳感器按照邏輯關(guān)系劃分到不同的邊緣服務(wù)器管轄。6臺(tái)邊緣服務(wù)器采用隨機(jī)選舉的方式產(chǎn)生主節(jié)點(diǎn),當(dāng)主節(jié)點(diǎn)選定以后,主節(jié)點(diǎn)綁定對(duì)外IP地址,其他邊緣服務(wù)器作為從節(jié)點(diǎn)工作。

Figure 6 Network diagram for prototype system testing

5.1.2 軟硬件環(huán)境

所有的邊緣服務(wù)器采用HP Gen8 DL388e服務(wù)器,2顆6核2.2 GHz主頻的CPU,內(nèi)存為24 GB,采用國(guó)產(chǎn)麒麟操作系統(tǒng),Linux內(nèi)核版本為2.6.32。為了進(jìn)行性能測(cè)試,開發(fā)了各式傳感器模擬器,在本文實(shí)驗(yàn)過程中,模擬實(shí)現(xiàn)了RFID傳感器。軟件壓力測(cè)試工具采用WebBench。所有網(wǎng)絡(luò)通信采用千兆網(wǎng)交換機(jī)。

5.2 測(cè)試設(shè)計(jì)及測(cè)試結(jié)果

5.2.1 單節(jié)點(diǎn)并行性

采用1臺(tái)測(cè)試模擬服務(wù)器模擬100個(gè)傳感器,每個(gè)傳感器產(chǎn)生10條數(shù)據(jù),每條傳感數(shù)據(jù)處理邏輯在邊緣服務(wù)器上耗時(shí)0.1 s。設(shè)計(jì)單節(jié)點(diǎn)測(cè)試場(chǎng)景:6H計(jì)算架構(gòu)運(yùn)行于1臺(tái)邊緣計(jì)算服務(wù)器上,連接的100個(gè)傳感器連續(xù)向6H計(jì)算架構(gòu)發(fā)送10條傳感數(shù)據(jù),在邊緣服務(wù)器上依次啟動(dòng)1個(gè)、2個(gè)、3個(gè)和4個(gè)處理進(jìn)程,事件路由策略采用隨機(jī)方式。實(shí)驗(yàn)重復(fù)100次。

邊緣服務(wù)器上啟動(dòng)1個(gè)、2個(gè)、3個(gè)和4個(gè)處理進(jìn)程時(shí),傳感數(shù)據(jù)處理計(jì)算耗時(shí)如圖7所示。

Figure 7 Comparison of calculation time for different number of processes

在多顆多核CPU硬件條件下,1個(gè)、2個(gè)、3個(gè)和4個(gè)進(jìn)程條件下計(jì)算時(shí)間基本成比例減少,說明6H計(jì)算架構(gòu)在單節(jié)點(diǎn)條件下具有較好的并行性。

5.2.2 多節(jié)點(diǎn)并行性

測(cè)試環(huán)境類似單節(jié)點(diǎn)并行性,設(shè)計(jì)多節(jié)點(diǎn)測(cè)試場(chǎng)景:6H計(jì)算架構(gòu)中依次運(yùn)行1臺(tái)、2臺(tái)、3臺(tái)、4臺(tái)、5臺(tái)和6臺(tái)邊緣計(jì)算服務(wù)器,連接的100個(gè)傳感器連續(xù)向6H計(jì)算架構(gòu)發(fā)送10條傳感數(shù)據(jù),在邊緣服務(wù)器上運(yùn)行1個(gè)處理進(jìn)程,事件路由策略采用隨機(jī)方式。實(shí)驗(yàn)重復(fù)100次。

6H計(jì)算架構(gòu)中邊緣服務(wù)器依次為1臺(tái)、2臺(tái)、3臺(tái)、4臺(tái)、5臺(tái)和6臺(tái)時(shí),傳感數(shù)據(jù)處理計(jì)算耗時(shí)如圖8所示。

Figure 8 Comparison of calculation time for different number of edge servers

在邊緣服務(wù)器依次為1臺(tái)、2臺(tái)、3臺(tái)、4臺(tái)、5臺(tái)和6臺(tái)時(shí)計(jì)算時(shí)間基本成比例減少,說明6H計(jì)算架構(gòu)在多節(jié)點(diǎn)條件下具有較好的并行性。

5.2.3 單節(jié)點(diǎn)高并發(fā)

在測(cè)試模擬服務(wù)器上運(yùn)行WebBench壓力測(cè)試工具,模擬用戶通過Web服務(wù)器訪問內(nèi)部計(jì)算邏輯,Web服務(wù)器處理及內(nèi)部業(yè)務(wù)邏輯處理在邊緣服務(wù)器上的計(jì)算耗時(shí)為2 s。設(shè)計(jì)單節(jié)點(diǎn)高并發(fā)測(cè)試場(chǎng)景:6H計(jì)算架構(gòu)中只運(yùn)行1臺(tái)邊緣計(jì)算服務(wù)器,同時(shí)部署Web服務(wù)器進(jìn)程和業(yè)務(wù)計(jì)算邏輯進(jìn)程,連接的不同數(shù)量用戶連續(xù)向6H計(jì)算架構(gòu)發(fā)送Web請(qǐng)求,事件路由策略采用隨機(jī)方式。實(shí)驗(yàn)重復(fù)100次。

不同數(shù)量用戶發(fā)送請(qǐng)求時(shí),請(qǐng)求數(shù)量及失敗請(qǐng)求失敗數(shù)量如圖9所示。

Figure 9 Number of failed requests with different concurrent requests (single node)

圖9中橫坐標(biāo)為WebBench中模擬的并發(fā)用戶數(shù)量,左側(cè)縱坐標(biāo)是Web請(qǐng)求數(shù)量,右側(cè)縱坐標(biāo)是Web請(qǐng)求失敗數(shù)量。單臺(tái)服務(wù)器,并發(fā)在線用戶為1 000時(shí),系統(tǒng)能提供可靠的服務(wù),說明6H計(jì)算架構(gòu)在單節(jié)點(diǎn)條件下具有較好的性能。

5.2.4 多節(jié)點(diǎn)高并發(fā)

測(cè)試環(huán)境類似單節(jié)點(diǎn)高并發(fā),設(shè)計(jì)多節(jié)點(diǎn)高并發(fā)測(cè)試場(chǎng)景:6H計(jì)算架構(gòu)中只運(yùn)行5臺(tái)邊緣計(jì)算服務(wù)器,其中1臺(tái)負(fù)責(zé)處理Web請(qǐng)求,4臺(tái)部署業(yè)務(wù)計(jì)算邏輯,連接的不同數(shù)量用戶連續(xù)向6H計(jì)算架構(gòu)發(fā)送Web請(qǐng)求,事件路由策略采用隨機(jī)方式。實(shí)驗(yàn)重復(fù)100次。

不同數(shù)量用戶發(fā)送請(qǐng)求時(shí),請(qǐng)求數(shù)量及失敗請(qǐng)求數(shù)量如圖10所示。圖10中橫坐標(biāo)為WebBench中模擬的并發(fā)用戶數(shù)量,左側(cè)縱坐標(biāo)是Web請(qǐng)求數(shù)量,右側(cè)縱坐標(biāo)是Web請(qǐng)求失敗數(shù)量。多臺(tái)服務(wù)器,并發(fā)在線用戶為6 000時(shí),系統(tǒng)能提供可靠的服務(wù),說明6H計(jì)算架構(gòu)在多節(jié)點(diǎn)條件下具有較好的性能。

Figure 10 Number of failed requests with different concurrent requests (multiple nodes)

5.2.5 高可用測(cè)試

在圖6所示的測(cè)試網(wǎng)絡(luò)條件下,從3個(gè)方面測(cè)試其可用性:主節(jié)點(diǎn)網(wǎng)絡(luò)故障、從節(jié)點(diǎn)網(wǎng)絡(luò)故障和節(jié)點(diǎn)網(wǎng)絡(luò)故障恢復(fù)。

當(dāng)主節(jié)點(diǎn)網(wǎng)絡(luò)故障時(shí),其他從節(jié)點(diǎn)發(fā)現(xiàn)和主節(jié)點(diǎn)的心跳包發(fā)送失敗后,連續(xù)重試連接。如果連續(xù)多次重試失敗后,所有從節(jié)點(diǎn)按照配置的選舉規(guī)則重新選擇主節(jié)點(diǎn)。主節(jié)點(diǎn)則綁定外部IP,啟動(dòng)主服務(wù)進(jìn)程,更新全局路由表。在實(shí)驗(yàn)時(shí),設(shè)定重試5次,優(yōu)先選擇內(nèi)網(wǎng)IP地址二進(jìn)制值小的主機(jī)做主節(jié)點(diǎn)。重復(fù)10次實(shí)驗(yàn),主節(jié)點(diǎn)網(wǎng)絡(luò)故障后,52 s內(nèi)恢復(fù)正常服務(wù)。

當(dāng)從節(jié)點(diǎn)網(wǎng)絡(luò)故障時(shí),主節(jié)點(diǎn)和其他從節(jié)點(diǎn)發(fā)現(xiàn)和故障從節(jié)點(diǎn)的心跳包發(fā)送失敗后,連續(xù)重試連接。如果連續(xù)多次重試失敗后,主節(jié)點(diǎn)更新全局路由表,將故障從節(jié)點(diǎn)的計(jì)算任務(wù)路由到其他服務(wù)器處理。如需要在其他服務(wù)器上啟動(dòng)服務(wù)進(jìn)程,則請(qǐng)求從服務(wù)器加載相關(guān)進(jìn)程。在實(shí)驗(yàn)時(shí),設(shè)定重試5次,在其他服務(wù)器上不需要加載其他進(jìn)程,重復(fù)10次實(shí)驗(yàn),從節(jié)點(diǎn)網(wǎng)絡(luò)故障后,服務(wù)不受影響。

當(dāng)節(jié)點(diǎn)故障恢復(fù)時(shí),恢復(fù)節(jié)點(diǎn)向所有節(jié)點(diǎn)發(fā)送心跳包,請(qǐng)求加入計(jì)算框架。恢復(fù)節(jié)點(diǎn)按照主節(jié)點(diǎn)需求及恢復(fù)節(jié)點(diǎn)的配置信息加載計(jì)算任務(wù)進(jìn)程,主節(jié)點(diǎn)更新全局路由表。在實(shí)驗(yàn)時(shí),重復(fù)10次實(shí)驗(yàn),從節(jié)點(diǎn)網(wǎng)絡(luò)故障恢復(fù)后,38 s內(nèi)恢復(fù)的故障節(jié)點(diǎn)加入6H計(jì)算框架并提供正常服務(wù)。

6 結(jié)束語

本文深入分析邊緣計(jì)算的需求特點(diǎn),基于輕量級(jí)虛擬化、軟件定義網(wǎng)絡(luò)、并行計(jì)算等基本理念,提出適用于邊緣計(jì)算環(huán)境的6H并行計(jì)算架構(gòu),即高性能、高可用、高可擴(kuò)展、高模塊化、高可伸縮、高易用。為驗(yàn)證6H并行計(jì)算架構(gòu)的合理性和科學(xué)性,本文采用Python/C++混合編程模式實(shí)現(xiàn)了一個(gè)6H計(jì)算框架,在邊緣計(jì)算典型硬件條件下,采用物聯(lián)網(wǎng)典型用例對(duì)該計(jì)算框架進(jìn)行了測(cè)試,其結(jié)果表明,該計(jì)算框架并行度接近1,可擴(kuò)展性很好,可伸縮性好,具有很高的可用性。下一步將在本文基礎(chǔ)上,將6H計(jì)算框架應(yīng)用于實(shí)際的邊緣計(jì)算環(huán)境,服務(wù)于視頻處理、人工智能等應(yīng)用場(chǎng)景。