適用于邊緣計算的6H并行計算架構

李 磊,鄭黎明,王宏義,柴永毅,劉培國

(1.國防科技大學電子科學學院,湖南 長沙 410073;2.中國電子科技集團公司第十五研究所,北京 100083;3.軍委裝備發展部體系評估中心,北京 100009)

1 引言

近年來,物聯網、大數據、人工智能、5G等技術的大規模應用催生了一大批新的互聯網應用,如智慧城市、智慧工廠、自動駕駛、增強現實、虛擬現實等。傳統的云集中式計算模型采用“云+端”兩級模式,將傳感器產生的所有數據通過網絡上傳至云計算中心,利用云計算中心的超強計算能力來集中解決應用的計算需求問題[1]。然而,針對萬物互聯的泛在式計算需求,云計算集中式計算模式存在一系列問題:

(1)云計算中心接入帶寬和計算資源無法支撐接入設備的指數式增長[2]。

(2)無法滿足低延時、高服務質量類應用需求。

(3)存在丟失大量本地環境信息的風險,可能導致大數據分析效果不理想。

(4)存在隱私泄露和核心數據不受控的風險。

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

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

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

(3)移動云計算。移動云計算是在云計算基礎上,針對用戶端計算資源和存儲資源有限的特征,引入移動代理技術,實現計算服務和存儲服務在云端、邊緣節點、用戶端動態遷移的計算模式[5]。當用戶端移動設備的計算和存儲資源無法滿足計算需求時,移動云計算框架將大塊數據的存儲和密集計算任務交給可能是邊緣節點也可能是云計算中心的遠程主機執行。Cloudlet是卡內基梅隆大學一個研究組織對移動云計算模式的一種典型實現[6]。

雖然移動邊緣計算、霧計算、移動云計算等的出發點不盡相同,但它們都體現了萬物聯網時代對新計算模式的需求,實時的服務響應速度、穩定的服務質量、為用戶提供定制化服務已逐漸成為用戶關注的焦點。本文將計算、存儲等服務遷移到更靠近數據源所在的網絡上運行。盡可能減小數據往返云端的延時、減少網絡帶寬需求的計算模式統稱為邊緣計算。

2 邊緣計算架構分析

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

文獻[8]針對物聯網的計算需求,提出了統一的霧計算架構,并對霧計算的分類法進行了研究。文獻[9]對移動云計算進行了總結,對比分析了各種已經實現的移動云計算體系架構。整體上來說,移動邊緣計算、霧計算、移動云計算在體系架構上都是基于云計算體系架構,進行適當的修改完善。與云計算體系架構不同的主要是更加關注計算任務在多個計算節點之間的遷移。

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

綜上所述,提出和實現的邊緣計算構架基本都是基于虛擬化、SDN、NFV技術,解決了很多現實問題,但深入分析后發現它們依然存在以下問題:

(1)虛擬化導致系統配置優化成本增加。

已有一些研究證明,Hypervisors虛擬化技術對性能的影響很小。但是,通過分析及大量的實驗發現,達到虛擬機最優性能往往需要根據具體的應用、資源情況(計算、存儲、網絡)進行有針對性的優化[14]。文獻[15]通過實驗證明,不同的虛擬機技術,不同的測試用例,往往導致性能差異很大。每個虛擬機技術有不同的適用場景,每個虛擬機需要根據實際使用場景進行有針對性的優化才能實現最佳的性能。對具體的實驗數據進行分析可知,在不同硬件平臺上采用通用的虛擬機配置,不進行有針對性的優化,將導致性能急劇下降。特別是在霧計算環境下,需要將各種移動計算資源納入計算體系,這將導致系統優化配置難度激增。

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

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

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

虛擬化技術幫助云計算中心提升伸縮性和靈活性,集中式管理簡化了資源和服務的管理和維護。相對云計算中心,邊緣計算環境地理更加分布、硬件更加異構、可用資源更加動態、I/O操作更加頻繁。虛擬機需要構建虛擬化操作系統,導致整體容量達上百兆,非常不利于在動態計算環境下進行遷移。文獻[15]已經證明在I/O操作密集時,虛擬機的性能將大幅下降。

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

到現階段為止,虛擬化技術及虛擬化產品眾多,有商用的也有開源的,超過10種。不同的虛擬機采用的技術和方案不同,虛擬機之間的通信沒有統一標準,導致通信困難。計算任務在同類虛擬機之間能輕松遷移,但是在不同技術的虛擬機之間遷移則存在諸多困難。

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

3 6H計算需求

針對物聯網、5G等典型應用場景,邊緣計算架構需要滿足以下6H計算需求:

(1)高可用性。5G應用包括高可靠、低時延通信場景,遠程醫療、自動駕駛、無人機控制等應用,對網絡和服務的可用性提出了嚴苛的要求。但是,在邊緣計算動態環境,計算節點動態加入和退出、任務動態裝載,所以邊緣計算體系架構需要在動態環境下解決高可用問題。

(2)高性能。邊緣計算環境中很多計算節點是網絡邊緣設備、智能移動設備,各計算節點存在計算資源受限的情況。為了在資源受限的節點上運行深度學習、增強學習、圖像處理等人工智能算法,需要提供高性能的計算架構,充分整合和利用各計算節點的計算資源,匯聚成高性能的一體化計算架構,對外提供高性能計算服務。

(3)高可擴展性。在邊緣計算環境下,隨著用戶數量和應用的增加,計算和存儲需求必然不斷增加。計算架構能通過簡單增加硬件的方式滿足不斷增長的計算和存儲需求,即系統性能隨著加入的計算節點數量的增加呈線性增長。

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

(5)高可伸縮性。在邊緣計算動態環境下,加入的可用計算和存儲資源動態變化。計算架構能適應不同規模的硬件條件,既能有效組織少量節點,滿足小規模計算和存儲需求,也能適用大規模計算節點環境,滿足大規模計算和存儲需求。

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

4 6H計算架構

4.1 6H計算架構概述

從物理部署架構上看,6H計算架構和移動邊緣計算、霧計算、移動云計算等架構類似,具體部署場景如圖1所示。

在圖1中,邊緣計算服務器具有一定的穩定性,性能較好,作為主服務器使用,是6H分布式計算環境的核心。物聯網設備接入網絡,從屬于不同的邊緣計算服務器。邊緣計算服務器按照計算任務情況、網絡情況、計算節點資源情況,給物聯網設備分配計算任務。

將地理位置上、邏輯功能上相關的邊緣計算服務器共同組成分布式計算環境,采用多網絡浮動IP的集群方式實現高可用分布式計算環境,其組網方式如圖2所示。所有的邊緣服務器都具備2套網絡資源,一套用于對外提供服務(如果被選中作為主服務器),一套用于系統內部進程間通信。

Figure 2 Edge server networking method

單個計算節點計算架構如圖3所示,處于最底層的是CPU、內存、網絡等計算資源;計算資源層以上是操作系統層;操作系統層上有虛擬化容量引擎,上面是一個個輕量級虛擬進程。在邊緣服務器上,有APP服務進程和SDN控制進程。由于采用輕量化虛擬機技術,一個輕量化虛擬機就對應并行計算中一個具體的進程,在后面描述的過程中,計算進程等同于輕量化虛擬機。

Figure 3 Architecture of single computing node

各個模塊的功能和作用如下所示:

(1)計算資源層主要包括邊緣服務器及參與計算的邊緣設備所屬資源(包括計算、存儲和網絡資源)。

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

(3)虛擬化容器引擎主要是根據任務進程管理需要,對輕量級虛擬機進行動態裝載、運行、停止、卸載及運行狀態監控等。

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

(5)服務管理進程主要用于實現各個服務的注冊、性能監控、管理等功能,針對性能要求及瓶頸,根據計算策略自動在合適的服務器上啟動新的進程實例,并更新全局消息路由信息。

(6)操作支持系統OOS(Operation Support Systems)進程,主要對各個服務器、輕量級虛擬機的相關配置及資源進行管理。

(7)SDN控制進程主要根據APP服務進程的要求,將用戶請求分解為不同的計算任務,并將不同的計算任務正確路由到不同的計算節點及計算進程,計算結束后,將結果反饋給APP服務進程。

(8)APP服務進程主要接收用戶APP發來的業務操作,并將SDN控制進程返回的計算結果反饋給用戶,典型的如Web服務器進程。

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

4.2 交互模型

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

進程間通信主要在TCP/IP網絡通信基礎上,充分參考和借鑒并行計算框架MPI的設計思路,支持點對點、廣播等通信機制,點對點通信采用管道方式,支持PULL和PUSH 2種模式。每個進程綁定2個標識,一個是發送端標識,一個是接收端標識,采用TCP://IP:Port的方式標識,其中IP、Port支持通配符。通信模型如圖4所示。

Figure 4 Inter process communication model

系統采用JSON統一定義了進程之間交互的消息格式,具體如下所示:

{

Sender_Pid：UINT32;//發送者進程號

Receiver_Pid：UINT32;//接受者進程號

CMD_Code：UINT32;//命令碼

Task_ID：UINT32;//任務碼

Frame_Type：UNIT32;//消息幀類別

Frame_NO：UNIT32;//消息幀序號,用于多幀

Priority：UINT32;//消息幀處理優先級

Created_Time：time;//創建時間

Data_length：UINT32;//消息幀長度

Custome_Data：String;//客戶自定義

}

消息幀中的CMD_Code是命令碼,命令碼是整個系統消息處理和路由的核心,每個服務器上的服務管理進程管理本機及本機附屬的移動結算節點上的所有計算進程,所有其他進程需要向該進程注冊,更新消息路由表。其他進程在發送消息時,根據消息路由表計算出消息的目的進程,實現業務操作的軟件可定義。

4.3 CMD-Worker-Handler編程模型

每個計算任務對應一個輕量級虛擬機,也就是一個典型的計算進程。每個計算任務又按照處理的業務不同劃分為多個功能模塊,也就是劃分成若干個Worker,每個Worker對應操作系統原生態的線程,進程作為這些Worker的容器。在進程啟動時,根據配置信息動態加載Worker。具體的編程模型如圖5所示。

Figure 5 CMD worker handler programming model

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

5 原型系統測試

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

測試環境包括測試的實施場地及測試系統等內容。項目所有的測試工作都嚴格按照相應的測試標準設置測試環境,并在測試前進行儀器設備的校準。本節僅對測試環境重點的幾個方面進行說明。

在邊緣計算典型硬件條件下,采用物聯網典型用例對該計算框架進行了測試。測試主要關注計算架構的高性能、高可用、高可擴展、高模塊化、高可伸縮方面。高易用性從CMD-Worker-Handler編程模型能充分體現。

5.1 測試環境

5.1.1 網絡環境

測試組網如圖6所示,共6臺邊緣服務器,通過千兆交換機實現互連,相關的傳感器按照邏輯關系劃分到不同的邊緣服務器管轄。6臺邊緣服務器采用隨機選舉的方式產生主節點,當主節點選定以后,主節點綁定對外IP地址,其他邊緣服務器作為從節點工作。

Figure 6 Network diagram for prototype system testing

5.1.2 軟硬件環境

所有的邊緣服務器采用HP Gen8 DL388e服務器,2顆6核2.2 GHz主頻的CPU,內存為24 GB,采用國產麒麟操作系統,Linux內核版本為2.6.32。為了進行性能測試,開發了各式傳感器模擬器,在本文實驗過程中,模擬實現了RFID傳感器。軟件壓力測試工具采用WebBench。所有網絡通信采用千兆網交換機。

5.2 測試設計及測試結果

5.2.1 單節點并行性

采用1臺測試模擬服務器模擬100個傳感器,每個傳感器產生10條數據,每條傳感數據處理邏輯在邊緣服務器上耗時0.1 s。設計單節點測試場景:6H計算架構運行于1臺邊緣計算服務器上,連接的100個傳感器連續向6H計算架構發送10條傳感數據,在邊緣服務器上依次啟動1個、2個、3個和4個處理進程,事件路由策略采用隨機方式。實驗重復100次。

邊緣服務器上啟動1個、2個、3個和4個處理進程時,傳感數據處理計算耗時如圖7所示。

Figure 7 Comparison of calculation time for different number of processes

在多顆多核CPU硬件條件下,1個、2個、3個和4個進程條件下計算時間基本成比例減少,說明6H計算架構在單節點條件下具有較好的并行性。

5.2.2 多節點并行性

測試環境類似單節點并行性,設計多節點測試場景:6H計算架構中依次運行1臺、2臺、3臺、4臺、5臺和6臺邊緣計算服務器,連接的100個傳感器連續向6H計算架構發送10條傳感數據,在邊緣服務器上運行1個處理進程,事件路由策略采用隨機方式。實驗重復100次。

6H計算架構中邊緣服務器依次為1臺、2臺、3臺、4臺、5臺和6臺時,傳感數據處理計算耗時如圖8所示。

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

在邊緣服務器依次為1臺、2臺、3臺、4臺、5臺和6臺時計算時間基本成比例減少,說明6H計算架構在多節點條件下具有較好的并行性。

5.2.3 單節點高并發

在測試模擬服務器上運行WebBench壓力測試工具,模擬用戶通過Web服務器訪問內部計算邏輯,Web服務器處理及內部業務邏輯處理在邊緣服務器上的計算耗時為2 s。設計單節點高并發測試場景:6H計算架構中只運行1臺邊緣計算服務器,同時部署Web服務器進程和業務計算邏輯進程,連接的不同數量用戶連續向6H計算架構發送Web請求,事件路由策略采用隨機方式。實驗重復100次。

不同數量用戶發送請求時,請求數量及失敗請求失敗數量如圖9所示。

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

圖9中橫坐標為WebBench中模擬的并發用戶數量,左側縱坐標是Web請求數量,右側縱坐標是Web請求失敗數量。單臺服務器,并發在線用戶為1 000時,系統能提供可靠的服務,說明6H計算架構在單節點條件下具有較好的性能。

5.2.4 多節點高并發

測試環境類似單節點高并發,設計多節點高并發測試場景:6H計算架構中只運行5臺邊緣計算服務器,其中1臺負責處理Web請求,4臺部署業務計算邏輯,連接的不同數量用戶連續向6H計算架構發送Web請求,事件路由策略采用隨機方式。實驗重復100次。

不同數量用戶發送請求時,請求數量及失敗請求數量如圖10所示。圖10中橫坐標為WebBench中模擬的并發用戶數量,左側縱坐標是Web請求數量,右側縱坐標是Web請求失敗數量。多臺服務器,并發在線用戶為6 000時,系統能提供可靠的服務,說明6H計算架構在多節點條件下具有較好的性能。

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

5.2.5 高可用測試

在圖6所示的測試網絡條件下,從3個方面測試其可用性:主節點網絡故障、從節點網絡故障和節點網絡故障恢復。

當主節點網絡故障時,其他從節點發現和主節點的心跳包發送失敗后,連續重試連接。如果連續多次重試失敗后,所有從節點按照配置的選舉規則重新選擇主節點。主節點則綁定外部IP,啟動主服務進程,更新全局路由表。在實驗時,設定重試5次,優先選擇內網IP地址二進制值小的主機做主節點。重復10次實驗,主節點網絡故障后,52 s內恢復正常服務。

當從節點網絡故障時,主節點和其他從節點發現和故障從節點的心跳包發送失敗后,連續重試連接。如果連續多次重試失敗后,主節點更新全局路由表,將故障從節點的計算任務路由到其他服務器處理。如需要在其他服務器上啟動服務進程,則請求從服務器加載相關進程。在實驗時,設定重試5次,在其他服務器上不需要加載其他進程,重復10次實驗,從節點網絡故障后,服務不受影響。

當節點故障恢復時,恢復節點向所有節點發送心跳包,請求加入計算框架。恢復節點按照主節點需求及恢復節點的配置信息加載計算任務進程,主節點更新全局路由表。在實驗時,重復10次實驗,從節點網絡故障恢復后,38 s內恢復的故障節點加入6H計算框架并提供正常服務。

6 結束語

本文深入分析邊緣計算的需求特點,基于輕量級虛擬化、軟件定義網絡、并行計算等基本理念,提出適用于邊緣計算環境的6H并行計算架構,即高性能、高可用、高可擴展、高模塊化、高可伸縮、高易用。為驗證6H并行計算架構的合理性和科學性,本文采用Python/C++混合編程模式實現了一個6H計算框架,在邊緣計算典型硬件條件下,采用物聯網典型用例對該計算框架進行了測試,其結果表明,該計算框架并行度接近1,可擴展性很好,可伸縮性好,具有很高的可用性。下一步將在本文基礎上,將6H計算框架應用于實際的邊緣計算環境,服務于視頻處理、人工智能等應用場景。