開源邊緣計算平臺研究分析

引  言

2020 年,5G 商用引爆通信業發展。以往通信設備都是軟硬件一體,一旦標準技術換代,就得研製新設備,導致投資大、靈活性差。5G 引入 SDN/NFV 技術後,採用標準服務器、存儲器和交換機來承載軟件化網絡功能,替代原有軟硬件一體專有設備,解決了通信設備迭代更新難度大問題。隨着 5G 不斷向軟件定義網絡方向發展,網絡架構變得更加靈活,爲了適應這種變化,傳統 CT、IT、公有云廠商也適時推出了開源邊緣計算平臺項目。

01 邊緣計算平臺現狀

萬物互聯時代到來,邊緣計算規模和業務複雜度發生了根本變化:邊緣實時計算、分析和邊緣智能等新型業務不斷湧現,對邊緣計算效率、可靠性和資源利用率提出了更高要求;因此,諸多廠家提出建設邊緣計算平臺,平臺涉及邊緣側網絡、計算以及存儲資源管理,提供基礎功能,如設備接入、安全校驗、監控等,其接口、架構、管理逐步成體系。但各廠家的邊緣計算平臺差異較大,行業邊緣應用部署時需要適配不同邊緣計算平臺,導致跨平臺應用部署難度大,故考慮引入開源技術打造 5G MEC 邊緣計算架構和能力開放的事實標準,打破當前邊緣計算平臺市場煙囪式、碎片化現狀,降低產業應用客戶上車門檻,實現規模複製,通過開源協作方式構建統一 5G MEC 平臺。下文從邊緣計算平臺參考架構入手,引出 2 種開源邊緣計算平臺進行分析。

02 典型邊緣計算平臺參考架構

2020 年,在 OSF 邊緣計算小組(Open Stack 基金會主導)發佈的《邊緣計算:架構,設計和測試的下一步》白皮書【1】中,開源基礎設施運營商和供應商聯合定義了以下 2 類典型邊緣參考體系結構模型。

a) 集中式控制平面模式:傳統單數據中心環境下中心控制器和邊緣計算節點由廣域網連接。該模式從集中運營角度看有優勢,安全性高,但節點嚴重依賴集中式數據中心來承載管理和協調邊緣計算、存儲和網絡服務,邊緣節點自主性差,是一種傳統架構模式。

b) 分佈式控制平面模式:多數控制服務駐留在大 / 中型邊緣數據中心上,也要求邊緣站點自身功能全面。這種體系結構比較靈活,尤其在網絡連接丟失情況下更凸顯其優勢,但由於需要跨地域運行大量控制功能,管理編排類型服務更復雜。KubeEdge 和 StarlingX 屬於此類去中心化架構模式【2】。

03 開源平臺項目分析

KubeEdge、Open NESS 是市面上較爲常見的幾類開源平臺,均採用了通用 VNF Manger 和 NFV Orchestrator 組件,參考了標準 ETSI  MANO 體系結構,但其特點不盡相同,詳細分析如下。

3.1  KubeEdge

2019 年,由華爲捐給 CNCF 基金會,基於 Kubernetes(簡稱 k8s)構建,100% 兼容 k8s API,是 Kubernetes IoT Edge WG 關鍵參考架構之一, 可提供雲邊協同能力開放。

3.1.1  整體架構

該平臺分爲雲端、邊緣端和終端三層,解耦式的架構,具體如圖 2 所示。

a) 雲端:負責應用和配置策略下發,通過旁路設計開發 CloudCore 組件,進行邊緣節點同步和維護,利用 list watch 與 Kubernetes 集羣做信息同步。

b) 邊緣端:負責運行邊緣應用和管理接入設備。Edgecore 支持 CRI,底層可以對接多種 container runtime、device Twin 和 DEvent Bus,主要是做設備元數據管理以及 MQTT 協議訂閱和發佈,從而完成與終端設備通信。

c) 終端:運行各種邊緣設備。設備終端有多類訪問協議,部分新設備可能直接支持 MQTT 協議。但部分專用設備存在專用協議,KubeEdge 採用 Mapper 設計,可將專有設備協議轉換成 MQTT 協議,實現邊緣應用和雲上設備數據同步和管理【3】。

圖片

圖 1  KubeEdge 整體架構

3.1.2  主要特點

KubeEdge 針對邊緣側實際環境做了諸多優化。

a) 雲邊可靠協同:採用雙向多路複用消息通道,支持邊緣節點位於私有網絡中,雲邊消息傳輸默認使用 websocket 消息封裝,減少通信壓力,高時延下仍可正常工作。

b) 邊緣離線自治:通過消息總線和元數據本地存儲實現節點離線自治,節點故障恢復也無需 list-watch, 從而降低網絡壓力,提升故障恢復速度。

c) 邊緣極致輕量化:邊緣側節點 Edgecore 內存約 70M,支持 CRI 集成 containerd 和 CRI-O, 優化了 runtime 資源消耗,方便在資源受限邊緣上運行;保留了 Kubernetes 的管理面,重新開發了節點 agent,大幅降低邊緣組件資源佔用率。

d) k8s 原生支持:雲端可以通過 k8s API 管理邊緣設備和邊緣應用程序。

但是作爲一個開源項目,KubeEdge 仍有很多方面待繼續完善。

a) 不支持設備協議如 OPC-UA。

b) 不支持使用數千個 Edge 節點和數百萬個設備評估並啓用更大範圍的 Edge 羣集。

c) 不支持對大型 Edge 集羣的應用程序進行智能調度【4】。

3.2  OpenNESS

由 Intel 主導,是一套開源軟件開發套件, 爲在用戶邊緣側或網絡邊緣側等位置運行的應用提供單一應用託管環境,旨在多種網絡接入方式(WiFi/4G/5G 等)下助力邊緣業務管理與編排,通過抽象化去除網絡複雜性,讓開發人員可以像編寫雲軟件一樣輕鬆編寫適用於邊緣的軟件,該項目在 Akraino Edge Stack(Linux 基金會項目)中被廣泛應用【5】。

3.2.1  整體架構

OpenNess 由邊緣節點和邊緣控制器 2 個部分構成【6】。

a) 邊緣節點:支持多種網絡接入方式,能夠從 IP、SI_U 或者 SG1 接口提取數據;支持針對 5G 延遲、多租戶和服務註冊流量定向,並支持部署邊緣應用。

b) 邊緣控制器:一般處於數據中心、雲中或邊緣等位置,進行邊緣平臺編排,採用 GUI 方式,支持其他通信服務提供商採用 API 方式鏈接到自己的控制器 GUI 環境。圖 3 爲 OpenNESS 抽象描述,展示邊緣節點上軟件和雲控制器與其他技術相互配合的使用方式。

圖片

圖 2  OpenNESS 整體架構

3.2.2  主要特點

OpenNESS 當前側重 4G/5G 功能集成、底層 Cloud native 能力以及不同硬件資源適配能力。

a) 支持獨立 5G NR 和增強平臺感知部署。有 5G 接入模塊,AF 可與 NEF 通過 N33 接口或者與 PCF 通過 N5 接口通信,幫助 MEP 下發分流規則以及事件訂閱等,支持 HTTP/2 HTTPS/oAuth2 協議;OpenNESS 的 DataPlane 模塊是所有邊緣開源項目中比較獨特的。

b) 高效擴展簡化編排:可以與 Kubernetes(將來還包括 Openstack)配合使用,可用於預配邊緣資源併爲網絡邊緣配置增強型平臺感知功能,雖然本身不包含服務編排,但具備可連接到服務編排器的控制 API。

c) 提供應用使能服務能力:提供 API,可供應用實現服務註冊、發現、訂閱和已訂閱服務查詢。

d) 靈活擴展性強,多雲兼容:基於微服務和開源 API,OpenNESS 可以爲 AWS Green grass、Microsoft Azure IoT Hub 和百度 IntelliEdge 提供雲連接器,因此更易於實施升級和更新管理【7】。

3.3  對比分析

整體來看,各平臺涉及技術棧基本一致,但在部署形態、架構、編排策略、可靠性和應用場景等方面仍有差異(見表 1),因此未來多平臺共存將是常態,如何加強各平臺間的協作將是未來的研究重點。

表 1:開源邊緣計算平臺性能分析對比

圖片

04 3GPP& ETSI 邊緣計算平臺架構映射分析

4.1  3GPP

3GPP 主要關注的是網絡架構對 MEC 特性的支持,其中 5G 網元 UPF 作爲邊緣計算的數據錨點、涉及用戶面重選、靈活業務疏導和計費等服務質量保障方面內容;MEC 與 5G 的融合架構主要關注 3 個接口:MEC 平臺與 NEF 的接口 N33,與 PCF 的接口 N5,與 UPF 的接口 N6。目前由 Intel 開發的 OpenNESS 平臺也已經搭建了 5G+MEC 測試牀。

4.2  ETSI

ETSI 定義 MEC 爲在移動網絡邊緣提供 IT 服務環境和計算能力。MEC 架構設計遵守基礎資源開放、平臺能力開放 (通過 MP1 接口,爲 APP 提供 ME services)、網絡能力開放(RNS API、Location API、bandwidth API、UE identity API)、管理能力開放、本地流量卸載以及移動性管理這幾個原則。

4.3  部分開源平臺映射關係

OpenNESS 符合 ETSI MEC 框架,其中邊緣控制器對應 MEPM, 邊緣服務對應 MEP, 邊緣應用對應 ME APP。OpenNESS 主要參考 ETSI  MEC 規範,OpenNESS 與 ETSI 的映射關係如圖 9 所示,其中藍色及橘色部分由 OpenNESS 實現【13】。

圖片

圖 3  OpenNESS 與 ETSI 的映射關係

05 運營商實施建議

隨着企業大步向雲原生時代邁進,電信運營商也逐步將雲原生技術擴展到邊緣側,並密切關注全過程中的安全性、服務遙測、計算性能、彈性和擴展性,以便未來以開放互操作的方式調整組織、業務和運營流程,加快部署節奏,降低總成本和運維風險【11】,筆者建議如下。

a) 提供統一邊緣計算參考實現標準,聚焦整體框架、接口定義及實現方式,並進一步統一面嚮應用的接口,降低應用開發夥伴上車門檻,逐步打破各家煙囪式 MEC 方案,打破市場隔離。

b) 積極與公有云廠商合作,作爲當前公有云服務提供商的補充,可避免重複部署資本密集型基礎設施,實現快速上市和測試新行業用例,共享行業應用程序生態系統資源。

c)重點關注邊緣計算平臺的異構硬件支持、移動性支持、IT/CT 鴻溝的關鍵技術點以及平臺是否支持邊緣節點輕量化部署和邊緣離線自治【13】。

總體看來,當前邊緣計算相關創新和開源化進程仍處於早期階段。雖然開源將打破舊有設備供應鏈格局,但在開放架構下,如何加強各開源平臺間協同創新,保障各方利益,平衡開源和專利保護,這些有待進一步研究與探討。

參考文獻

【1】Beth Cohen,Gergely Csatári,Shuquan Huang,Bruce Jones,Adrien Lebre,David Paterson,Ildikó Váncsa.Edge Computing: Next Steps in Architecture, Design andTesting[EB/OL].https://www.openstack.org/use-cases/edge-computing/edge-computing-next-steps-in-architecture-design-and-testing/?lang=en_US,2020.

【2】梁家越, 劉斌, 劉芳. 邊緣計算開源平臺現狀分析 [J]. 中興通訊技術 邊緣計算專刊, 2019,25(3):12-18.

【3】開源社區. KubeEdge 官網 [EB/OL].https://github.com/kubeedge/kubeedge,2019.

【4】HarmonyCloud. 乾貨滿滿 | 諧雲在 KubeEdge 雲邊協同落地實踐分享 [EB/OL].https://mp.weixin.qq.com/s/Jh74RSMbrKG2WrKjv1XAVA,2020-09-01.

【5】官網. openness 介紹 [EB/OL].https://www.openness.org/

【6】Intel.openness-and-the-network-edge-eguide-cn[Z].global:Intel,2020-4.

【7】高紀明. OpenNESS 基於雲原生的一體化 MEC 解決方案 [Z]. 中國: INTEL,2020-8.

【8】官網. StarlingX 項目介紹 [EB/OL].https://www.starlingx.io/learn/,2019.

王毅. 時間敏感網絡在 StarlingX 的集成方案介紹 [Z]. 中國: INTEL,2020-8.

【9】開源社區. openyurt 官網 [EB/OL]. https://github.com/alibaba/openyurt,2020.

【10】新勝. 深度解讀. OpenYurt:從邊緣自治看 YurtHub 的擴展能力 [EB/OL].https://mp.weixin.qq.com/s/b0gGlXvXRS3hz9vRrqSFnQ,2020-07-10.

【11】高維濤. 由 CloudNative 引發的思考:什麼是 EdgeNative(邊緣原生)[EB/OL].https://mp.weixin.qq.com/s/7HgUiGuboLDhqdCLh415bA,2020-09-07.

【12】開源中文社區. 電信公司,在考慮雲原生、邊緣時請注意這 5 個問題 [EB/OL].https://mp.weixin.qq.com/s/4QAhNukaCEV3Ivz6Vyiorg,2020-09-03.

【13】TEF,DT,HTK,etc.GSMAFutureNetworksProgrammeOperatorPlatformConcept_Whitepaper[R].london:GSMA,2020.

作者簡介:

黃倩,工程師,碩士,從事邊緣計算,開源技術,5G 標準化工作,5G 垂直行業諮詢工作;

黃蓉,高級工程師,博士,從事白盒基站,邊緣計算工作;

陳杲,高級工程師,博士,從事邊緣計算技術研究工作;

王友祥,高級工程師,博士,從事 5G/6G 新技術及產業推進工作;

編輯:李星初

審覈:薛海斌

來源:郵電設計技術

編輯:邊緣計算社區

本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源https://mp.weixin.qq.com/s/VZVLefTzZeZggGt9vYZnPQ