訂閱
糾錯(cuò)
加入自媒體

面向5GC的容器部署及演進(jìn)探討

基于容器的微服務(wù)架構(gòu)是5GC演進(jìn)方向

3GPP R15的5G網(wǎng)絡(luò)規(guī)范在5G控制面引入了基于服務(wù)的體系架構(gòu)(SBA),每個(gè)網(wǎng)絡(luò)功能(Network Function)對外提供服務(wù)化的接口。該網(wǎng)絡(luò)規(guī)范定義了網(wǎng)絡(luò)功能服務(wù)(NF service),這些網(wǎng)絡(luò)功能服務(wù)可以通過服務(wù)化的接口被其他NF訪問。網(wǎng)絡(luò)功能服務(wù)本身需自包含、可重用,且同一個(gè)網(wǎng)絡(luò)功能的服務(wù)管理相互獨(dú)立(如彈性、自愈)。通信運(yùn)營商欲借鑒IT行業(yè)云原生、微服務(wù)架構(gòu)以實(shí)現(xiàn)自身網(wǎng)絡(luò)功能重構(gòu)。

云原生是一個(gè)思想的集合,包括DevOps、持續(xù)交付(Continuous Delivery)、微服務(wù)(MicroServices)、敏捷基礎(chǔ)設(shè)施(Agile Infrastructure)等技術(shù)與方法,而微服務(wù)作為云原生的關(guān)鍵特征之一,是一種軟件“架構(gòu)”組織的方法,用一組小的服務(wù)來開發(fā)一個(gè)應(yīng)用(在CT域“應(yīng)用”對應(yīng)VNF),服務(wù)劃分的粒度的大小根據(jù)需要決定。每個(gè)服務(wù)有如下特點(diǎn):第一,在自己的進(jìn)程中運(yùn)行(running in its own process);第二,相互之間通過輕量級通信機(jī)制(lightweight mechanisms),通常是HTTP API;第三,圍繞商業(yè)邏輯構(gòu)建,并且能夠獨(dú)立部署(independently deployable)。

基于微服務(wù)架構(gòu)的軟件設(shè)計(jì)已經(jīng)在IT領(lǐng)域規(guī)模商用。IT應(yīng)用采用微服務(wù)架構(gòu),主要有兩方面原因:一方面是由互聯(lián)網(wǎng)業(yè)務(wù)特點(diǎn)驅(qū)動(dòng),用戶需求變化快、訪問量大,軟件架構(gòu)必須適應(yīng)業(yè)務(wù)需求。另一方面,單體架構(gòu)維護(hù)成本高、持續(xù)交付周期長、可擴(kuò)展性差,必須采用新架構(gòu)來解決這些問題。

CT領(lǐng)域應(yīng)用也存在類似的痛點(diǎn),而且CT是在標(biāo)準(zhǔn)的網(wǎng)絡(luò)架構(gòu)下定義網(wǎng)絡(luò)功能、協(xié)議接口,系統(tǒng)穩(wěn)定但缺乏靈活性,限制了業(yè)務(wù)迭代速度。這需要借助IT目前廣泛應(yīng)用的微服務(wù)架構(gòu)解決這些場景下的問題;赟BA 5GC網(wǎng)元需要實(shí)現(xiàn)微服務(wù)解耦,將緊耦合的單體結(jié)構(gòu)拆分為松耦合的多個(gè)微服務(wù),這些微服務(wù)可以獨(dú)立部署、升級和擴(kuò)展,有利于實(shí)現(xiàn)業(yè)務(wù)快速迭代和創(chuàng)新。

容器技術(shù)作為微服務(wù)的實(shí)踐技術(shù),是未來實(shí)現(xiàn)5GC服務(wù)按需功能調(diào)用和靈活編排所需的云化NFV平臺(tái)能力。

容器技術(shù)分析

虛擬機(jī)和容器技術(shù)并非替代關(guān)系。相比于虛擬機(jī)技術(shù),容器技術(shù)一方面具有輕量化、敏捷性等優(yōu)勢;而另一方面,也存在標(biāo)準(zhǔn)不成熟、安全隔離性較差等劣勢,需要具體分析。

標(biāo)準(zhǔn)化程度

ETSI NFV中虛擬機(jī)標(biāo)準(zhǔn)化程度較高,而容器標(biāo)準(zhǔn)仍不成熟。2018年6月,ETSI  NFV開始在IFA研究容器相關(guān)內(nèi)容,目前已完成容器用例和模塊功能,而信息模型以及架構(gòu)影響仍在討論中。標(biāo)準(zhǔn)組織后續(xù)還會(huì)開展架構(gòu)、接口、信息模型、安全等方面標(biāo)準(zhǔn)的研究。

資源占用率

相比于虛機(jī),容器直接在裸機(jī)操作系統(tǒng)上運(yùn)行應(yīng)用進(jìn)程,省去了客戶操作系統(tǒng)和hypervisor層,資源的利用率比較高,可達(dá)95%以上,接近裸機(jī),從而減少運(yùn)營商對基礎(chǔ)設(shè)施的投資成本。

安全隔離性

容器實(shí)例與主機(jī)共享操作系統(tǒng)內(nèi)核,通過內(nèi)核提供的運(yùn)行時(shí)隔離能力為服務(wù)提供獨(dú)立的用戶域、文件系統(tǒng)、網(wǎng)絡(luò)和進(jìn)程運(yùn)行空間。虛擬機(jī)每個(gè)實(shí)例自帶操作系統(tǒng),是一種硬件級的隔離 ,因而安全隔離性高于容器。

彈性伸縮

彈性伸縮時(shí)間取決于應(yīng)用的啟動(dòng)速度,因電信應(yīng)用啟動(dòng)時(shí)間較長(分鐘級),容器+APP彈縮時(shí)間比起VM+APP彈縮時(shí)間不具備太大優(yōu)勢。

運(yùn)維方面

無論是虛擬機(jī)還是容器,都可以引入DevOps,DevOps自動(dòng)拉通了設(shè)備商與運(yùn)營商的開發(fā)和運(yùn)維流程,將敏捷開發(fā)、自動(dòng)測試、快速部署、灰度升級等環(huán)節(jié)貫通,實(shí)現(xiàn)從設(shè)計(jì)、開發(fā)、測試到發(fā)布全流程的自動(dòng)化,幫助運(yùn)營商進(jìn)一步實(shí)現(xiàn)網(wǎng)絡(luò)業(yè)務(wù)的高效運(yùn)維,節(jié)約運(yùn)維成本。

5GC網(wǎng)元部署與演進(jìn)建議

如何采用NFV技術(shù)快速部署一張基于SBA 架構(gòu)的5GC,對運(yùn)營商是一項(xiàng)重大挑戰(zhàn)。

網(wǎng)絡(luò)的基礎(chǔ)設(shè)施正在從傳統(tǒng)虛擬機(jī)向基于容器的輕型虛擬化逐步演進(jìn)。傳統(tǒng)的虛擬機(jī)適于面向底層硬件的生產(chǎn)環(huán)境,可用性高、管理性好、技術(shù)成熟,但架構(gòu)復(fù)雜、性能較差、成本偏高;基于容器的輕型虛擬化,適用于面向上層應(yīng)用進(jìn)程的環(huán)境,架構(gòu)簡單、部署靈活、適用任意平臺(tái),但管理性、可用性、標(biāo)準(zhǔn)化等方面尚未成熟。因此可能的應(yīng)用前景是基于容器的虛擬化面向上層應(yīng)用進(jìn)程、基于虛擬機(jī)的虛擬化面向底層硬件等。

容器的引入原則建議遵循由易到難,按需部署,分步驟引入。具體部署建議如下:

第一階段:基于虛機(jī)容器方案,容器對外不可見(2019~2020),如圖1。

圖1 虛機(jī)容器方案(容器不可見)

當(dāng)前NFV技術(shù)標(biāo)準(zhǔn)基于Hypervisor,以支持虛機(jī)部署為主,因此5G核心網(wǎng)部署初期,可采用虛機(jī)容器方案。

考慮到5G核心網(wǎng)VNF對性能的要求,容器一般是嵌入在廠家提供的VNF內(nèi),NFVO不必感知容器的存在。這一方案的最大好處是可直接沿用現(xiàn)有ETSI NFV架構(gòu),無需進(jìn)行改造。各個(gè)容器共享所屬虛機(jī)的Guest OS內(nèi)核,而不需要獲取Host OS的管理權(quán)限,安全隔離性更高。

1  2  下一頁>  
聲明: 本文由入駐維科號(hào)的作者撰寫,觀點(diǎn)僅代表作者本人,不代表OFweek立場。如有侵權(quán)或其他問題,請聯(lián)系舉報(bào)。

發(fā)表評論

0條評論,0人參與

請輸入評論內(nèi)容...

請輸入評論/評論長度6~500個(gè)字

您提交的評論過于頻繁,請輸入驗(yàn)證碼繼續(xù)

  • 看不清,點(diǎn)擊換一張  刷新

暫無評論

暫無評論

智慧城市 獵頭職位 更多
文章糾錯(cuò)
x
*文字標(biāo)題:
*糾錯(cuò)內(nèi)容:
聯(lián)系郵箱:
*驗(yàn) 證 碼:

粵公網(wǎng)安備 44030502002758號(hào)