首頁|必讀|視頻|專訪|運(yùn)營(yíng)|制造|監(jiān)管|大數(shù)據(jù)|物聯(lián)網(wǎng)|量子|元宇宙|博客|特約記者
手機(jī)|互聯(lián)網(wǎng)|IT|5G|光通信|人工智能|云計(jì)算|芯片報(bào)告|智慧城市|移動(dòng)互聯(lián)網(wǎng)|會(huì)展
首頁 >> 技術(shù) >> 正文

NFV網(wǎng)絡(luò)云落地過程中若干問題分析

2021年8月4日 11:29  移動(dòng)Labs  作 者:李冰

Labs 導(dǎo)讀

NFV技術(shù)從誕生起,從根本上來說就是為了解決運(yùn)營(yíng)商網(wǎng)絡(luò)演進(jìn)中部署成本高,迭代更新慢,架構(gòu)僵化等痛點(diǎn)問題。同時(shí),在引入NFV技術(shù)前,舊有產(chǎn)業(yè)鏈相對(duì)單一,核心成員主要包括設(shè)備制造商、芯片制造商等,而NFV引入后拉長(zhǎng)了整體通信產(chǎn)業(yè)鏈條,傳統(tǒng)設(shè)備制造商面臨嚴(yán)峻的挑戰(zhàn),原本軟硬件一體化設(shè)備銷售模式被拆解為通用硬件、虛擬化平臺(tái)和網(wǎng)元功能三部分銷售模式。這也直接決定了運(yùn)營(yíng)商期望的多層解耦部署模式推行困難。同時(shí),在NFV的轉(zhuǎn)發(fā)性能提升、MANO管理模式選型、VNFM選型和NFVO部署等方面也多多少少存在影響電信云落地的問題。

1 NFV部署模式選型

NFV通過軟硬件解耦,使得網(wǎng)絡(luò)設(shè)備開放化,軟硬件可以獨(dú)立演進(jìn),避免廠家鎖定。基于NFV分層解耦的特性,根據(jù)軟硬件解耦的開放性不同,可將集成策略分為單廠家、共享資源池、硬件獨(dú)立和三層全解耦4種方案,如下圖所示。

方案1:?jiǎn)螐S家方案,優(yōu)點(diǎn)就是可以實(shí)現(xiàn)快速部署,整體系統(tǒng)的性能、穩(wěn)定性與可靠性都比較理想,不需要進(jìn)行異構(gòu)廠商的互通測(cè)試與集成。缺點(diǎn)是與傳統(tǒng)網(wǎng)絡(luò)設(shè)備一樣,存在軟硬件一體化和封閉性問題,難以實(shí)現(xiàn)靈活的架構(gòu)部署,不利于實(shí)現(xiàn)共享;與廠商存在捆綁關(guān)系,不利于競(jìng)爭(zhēng),會(huì)再次形成煙囪式部署,總體成本較高,也不利于自主創(chuàng)新以及靈活的迭代式部署升級(jí)。目前,中國(guó)電信的4G/VoLTE/IMS網(wǎng)絡(luò)就是采用這種方式,在短期內(nèi)對(duì)中國(guó)移動(dòng)的業(yè)務(wù)發(fā)展形成較大壓力。

方案2:傾向于IT化思路,選擇最好的硬件平臺(tái)和虛擬機(jī)產(chǎn)品,要求上層應(yīng)用向底層平臺(tái)靠攏。只對(duì)VNF與NFVI層解耦,VNF能夠部署于統(tǒng)一管理的虛擬資源之上,并確保功能可用、性能良好、運(yùn)行情況可監(jiān)控、故障可定位;不同供應(yīng)商的VNF可靈活配置、可互通、可混用、可集約管理。其中,VNFM與VNF通常為同一廠商(即“專用VNFM”),這種情況下VNF與VNFM之間的接口不需標(biāo)準(zhǔn)化;特殊場(chǎng)景下采用跨廠商的“VNFM”(即“通用VNFM”)。VMware的解決方案就是典型的方案二廠商A的定位,考慮到中國(guó)移動(dòng)蘇州研發(fā)中心與VMware的戰(zhàn)略合作情況,可以預(yù)期不遠(yuǎn)的將來中國(guó)移動(dòng)的NFV網(wǎng)絡(luò)架構(gòu)中會(huì)出現(xiàn)類似部署方案。

方案3:傾向于電信思路,通用硬件與虛擬化層軟件解耦,基礎(chǔ)設(shè)施全部采用通用硬件,實(shí)現(xiàn)多供應(yīng)商設(shè)備混用;虛擬化層采用商用/開源軟件進(jìn)行虛擬資源的統(tǒng)一管理?梢杂呻娦旁O(shè)備制造商提供所有軟件,只是適配在IT平臺(tái)上。目前,中國(guó)移動(dòng)大區(qū)集中化網(wǎng)絡(luò)建設(shè)就是采用此部署方案。

方案4:全解耦的好處是可以實(shí)現(xiàn)通用化、標(biāo)準(zhǔn)化、模塊化、分布式部署,架構(gòu)靈活,而且部分核心模塊可選擇進(jìn)行定制與自主研發(fā),也有利于形成競(jìng)爭(zhēng),降低成本,實(shí)現(xiàn)規(guī)模化部署;不利的地方是需要規(guī)范和標(biāo)準(zhǔn)化,周期很長(zhǎng),也需要大量的多廠商互通測(cè)試,需要很強(qiáng)的集成開發(fā)能力,部署就緒時(shí)間長(zhǎng),效率較低,后續(xù)的運(yùn)營(yíng)復(fù)雜度高,故障定位和排除較為困難,對(duì)運(yùn)營(yíng)商的運(yùn)營(yíng)能力要求較高。該模式是中國(guó)移動(dòng)一直不遺余力推廣的模式,目前在陜西移動(dòng)已初步完成蘇研VIM+分布式存儲(chǔ)、華為VNFM和研究院NFVO+的標(biāo)準(zhǔn)三層部署模式驗(yàn)證,并打通了標(biāo)準(zhǔn)三層組網(wǎng)下FirstCall。

另外,以上各方案都涉及MANO的解耦,涉及運(yùn)營(yíng)商自主開發(fā)或者第三方的NFVO與不同廠商的VNFM、VIM之間的對(duì)接和打通,屏蔽了供應(yīng)商間的差異,統(tǒng)一實(shí)現(xiàn)網(wǎng)絡(luò)功能的協(xié)同、面向業(yè)務(wù)的編排與虛擬資源的管理。但是,NFVO+的解耦目前還停留在實(shí)驗(yàn)驗(yàn)證階段,在中國(guó)移動(dòng)的電信云一階段還是采用NFVO與VNFM同廠商捆綁的模式。

2 NFV轉(zhuǎn)發(fā)性能的提升

NFV設(shè)計(jì)的初衷是針對(duì)部分低轉(zhuǎn)發(fā)流量類業(yè)務(wù)功能,x86服務(wù)器在配備高速網(wǎng)卡(10Gbit/s)后,業(yè)務(wù)應(yīng)用不經(jīng)特殊優(yōu)化,基本也可以滿足大多數(shù)低速率轉(zhuǎn)發(fā)業(yè)務(wù)的處理要求(即使后續(xù)隨著SDN技術(shù)的推動(dòng),引入了40Gbit/s的高速轉(zhuǎn)發(fā)能力,但目前也只是實(shí)驗(yàn)驗(yàn)證階段,并未實(shí)際部署)。

傳統(tǒng)硬件網(wǎng)元能夠通過專用芯片實(shí)現(xiàn)高轉(zhuǎn)發(fā)性能,而x86環(huán)境下的虛擬化網(wǎng)元尚不具備萬兆以上端口的小包線速轉(zhuǎn)發(fā)能力,在同等業(yè)務(wù)量的情況下,虛擬化網(wǎng)元和傳統(tǒng)設(shè)備相比存在一定的性能差距。x86服務(wù)器采用軟件轉(zhuǎn)發(fā)和交換技術(shù),報(bào)文在服務(wù)器各層面間傳遞,會(huì)受到CPU開銷等多方面因素的影響,因此服務(wù)器的內(nèi)部轉(zhuǎn)發(fā)性能是NFV系統(tǒng)的主要瓶頸。

NFV中的網(wǎng)絡(luò)業(yè)務(wù)應(yīng)用運(yùn)行于服務(wù)器的虛擬化環(huán)境中,單個(gè)應(yīng)用業(yè)務(wù)流量的收發(fā)要經(jīng)過虛擬化層、服務(wù)器I/O通道、內(nèi)核協(xié)議棧等多個(gè)處理流程,而多個(gè)應(yīng)用業(yè)務(wù)之間又可以用復(fù)雜的物理或虛擬網(wǎng)絡(luò)相連接。因此,NFV系統(tǒng)的整體性能取決于單服務(wù)器轉(zhuǎn)發(fā)性能與業(yè)務(wù)組鏈轉(zhuǎn)發(fā)性能兩個(gè)方面。如下所示:

業(yè)務(wù)應(yīng)用流量的收發(fā)I/O通道依次包括物理網(wǎng)卡、虛擬交換機(jī)、虛擬網(wǎng)卡3個(gè)環(huán)節(jié)(見上圖左半部分);從軟件結(jié)構(gòu)上看,報(bào)文的收發(fā)需要經(jīng)過物理網(wǎng)卡驅(qū)動(dòng)、宿主機(jī)內(nèi)核網(wǎng)絡(luò)協(xié)議棧、內(nèi)核態(tài)虛擬交換層、虛擬機(jī)網(wǎng)卡驅(qū)動(dòng)、虛擬機(jī)內(nèi)核態(tài)網(wǎng)絡(luò)協(xié)議棧、虛擬機(jī)用戶態(tài)應(yīng)用等多個(gè)轉(zhuǎn)發(fā)通道(見上圖右半部分),存在著海量系統(tǒng)中斷、內(nèi)核上下文切換、內(nèi)存復(fù)制、虛擬化封裝/解封等大量CPU開銷操作過程。

2.1 影響NFV轉(zhuǎn)發(fā)性能的主要因素

2.1.1 網(wǎng)卡硬件中斷

目前大量流行的PCI/PCIe(Peripheral Component Interconnect,外設(shè)部件互連標(biāo)準(zhǔn)/PCI-Express)網(wǎng)卡在收到報(bào)文后,一般采用DMA(Direct Memory Access,直接存儲(chǔ)器存。┓绞街苯訉懭雰(nèi)存并產(chǎn)生CPU硬件中斷,在低速轉(zhuǎn)發(fā)應(yīng)用中此方法十分有效。

但是,當(dāng)網(wǎng)絡(luò)流量激增時(shí),CPU的大部分時(shí)間阻塞于中斷響應(yīng)。在多核系統(tǒng)中,可能存在多塊網(wǎng)卡綁定同一個(gè)CPU核的情況,使其占用率達(dá)到100%。中斷處理方式在低速網(wǎng)絡(luò)I/O場(chǎng)景下非常有效。然而,隨著高速網(wǎng)絡(luò)接口等技術(shù)的迅速發(fā)展,10Gbit/s、40Gbit/s甚至100Gbit/s的網(wǎng)絡(luò)端口已經(jīng)出現(xiàn)。隨著網(wǎng)絡(luò)I/O速率的不斷提高,網(wǎng)卡面對(duì)大量高速數(shù)據(jù)分組引發(fā)頻繁的中斷,中斷引起的上下文切換開銷將變得不可忽視,造成較高的時(shí)延,并引起吞吐量下降。因此,網(wǎng)卡性能改進(jìn)一般采用減少或關(guān)閉中斷(如輪詢?nèi)〈袛、零?fù)制技術(shù)、大頁內(nèi)存技術(shù)等)、多核CPU負(fù)載均衡等優(yōu)化措施。

2.1.2 內(nèi)核網(wǎng)絡(luò)協(xié)議棧

在Linux或FreeBSD系統(tǒng)中,用戶態(tài)程序調(diào)用系統(tǒng)套接字進(jìn)行數(shù)據(jù)收發(fā)時(shí),會(huì)使用內(nèi)核網(wǎng)絡(luò)協(xié)議棧。這將產(chǎn)生兩方面的性能問題:一是系統(tǒng)調(diào)用導(dǎo)致的內(nèi)核上下文切換,會(huì)頻繁占用CPU周期;二是協(xié)議棧與用戶進(jìn)程間的報(bào)文復(fù)制是一種費(fèi)時(shí)的操作。

NFV系統(tǒng)中,業(yè)務(wù)應(yīng)用報(bào)文處理從物理網(wǎng)卡到業(yè)務(wù)應(yīng)用需要完成收發(fā)操作各1次,至少經(jīng)過4次上下文切換(宿主機(jī)2次以及VM內(nèi)2次)和4次報(bào)文復(fù)制。將網(wǎng)絡(luò)協(xié)議棧移植到用戶態(tài)是一種可行的思路,但這種方法違反了GNU協(xié)議。GNU是GNU GPL(GNU General Public License,通用公共許可證)的簡(jiǎn)稱,Linux內(nèi)核受GNU GPL保護(hù),內(nèi)核代碼不能用于Linux內(nèi)核外。因此,棄用網(wǎng)絡(luò)協(xié)議棧以換取轉(zhuǎn)發(fā)性能,是唯一可行的辦法,但需要付出大量修改業(yè)務(wù)應(yīng)用代碼的代價(jià)。

2.1.3 虛擬化層的封裝效率

業(yè)務(wù)應(yīng)用中存在兩類封裝:服務(wù)器內(nèi)部的I/O封裝和網(wǎng)絡(luò)層對(duì)流量的虛擬化封裝。前者是由于NFV的業(yè)務(wù)應(yīng)用運(yùn)行于VM中,流量需要經(jīng)歷多次封裝/解封裝過程,包括:宿主機(jī)虛擬化軟件對(duì)VM的I/O封裝、虛擬交換機(jī)對(duì)端口的封裝、云管理平臺(tái)對(duì)虛擬網(wǎng)絡(luò)端口的封裝;后者是為實(shí)現(xiàn)NFV用戶隔離,在流量中添加的用戶標(biāo)識(shí),如VLAN、VxLAN(Virtual Extensible Local Area Network,可擴(kuò)展虛擬局域網(wǎng))等。這兩類封裝/解封均要消耗CPU周期,會(huì)降低NFV系統(tǒng)的轉(zhuǎn)發(fā)效率。

2.1.4 業(yè)務(wù)鏈網(wǎng)絡(luò)的轉(zhuǎn)發(fā)效率

NFV的業(yè)務(wù)鏈存在星形和串行兩種組網(wǎng)方式,如下圖所示。

星形連接依賴于物理網(wǎng)絡(luò)設(shè)備的硬件轉(zhuǎn)發(fā)能力,整體轉(zhuǎn)發(fā)性能較優(yōu),但當(dāng)應(yīng)用的數(shù)量較大時(shí),會(huì)消耗大量網(wǎng)絡(luò)設(shè)備端口。因此,在業(yè)務(wù)鏈組網(wǎng)范圍不大時(shí),如在IDC內(nèi)部,為簡(jiǎn)化組網(wǎng)和節(jié)約端口,更多地采用串行連接。

當(dāng)串行連接時(shí),NFV控制器需要在多個(gè)業(yè)務(wù)應(yīng)用中選擇合適位置的應(yīng)用進(jìn)程或進(jìn)程組來處理流量,以均衡各應(yīng)用負(fù)荷并兼顧業(yè)務(wù)鏈網(wǎng)絡(luò)性能。不合適的負(fù)載均衡算法會(huì)造成流量在不同進(jìn)程組的上下行鏈路之間反復(fù)穿越,嚴(yán)重降低業(yè)務(wù)鏈網(wǎng)絡(luò)的帶寬利用率。

2.1.5 其他開銷

緩存未命中開銷:緩存是一種能夠有效提高系統(tǒng)性能的方式,然而,由于設(shè)計(jì)的不合理造成頻繁的緩存未命中,則會(huì)嚴(yán)重削弱NFV數(shù)據(jù)平面的性能。

鎖開銷:當(dāng)多個(gè)線程或進(jìn)程需要對(duì)某一共享資源進(jìn)行操作時(shí),往往需要通過鎖機(jī)制來保證數(shù)據(jù)的一致性和同步性,而加鎖帶來的開銷會(huì)顯著降低數(shù)據(jù)處理的性能。

上下文切換開銷:NFV的擴(kuò)展需要多核并行化的支持,然而在該場(chǎng)景下,數(shù)據(jù)平面需要進(jìn)行資源的分配調(diào)度,調(diào)度過程中涉及多種類型的上下文切換。在網(wǎng)卡中斷、系統(tǒng)調(diào)用、進(jìn)程調(diào)度與跨核資源訪問等上下文切換過程中,操作系統(tǒng)均需要保存當(dāng)前狀態(tài),而這一類的切換開銷往往相當(dāng)昂貴,嚴(yán)重影響系統(tǒng)性能。

以上3種開銷對(duì)于NFV轉(zhuǎn)發(fā)性能的影響較大,在實(shí)際的轉(zhuǎn)發(fā)過程中,開銷不止這3種。

2.2 NFV引入的開源技術(shù)

針對(duì)以上影響轉(zhuǎn)發(fā)性能的挑戰(zhàn),NFV在落地過程引入不同開源技術(shù)進(jìn)行應(yīng)對(duì),具體的實(shí)現(xiàn)原理會(huì)在第二部分《NFV關(guān)鍵技術(shù)》中詳細(xì)闡述,這里只是做一個(gè)簡(jiǎn)單的介紹,使初學(xué)者有個(gè)概念性的了解。

2.2.1 輪詢?nèi)〈袛?/P>

作為I/O通信的另一種方式,輪詢不存在中斷所固有的開銷。以網(wǎng)卡接收分組為例,在輪詢模式下,系統(tǒng)會(huì)在初始化時(shí)屏蔽收發(fā)分組中斷,并使用一個(gè)線程或進(jìn)程來不斷檢測(cè)收取分組描述符中的收取分組成功標(biāo)志是否被網(wǎng)卡置位,以此來判斷是否有數(shù)據(jù)分組。整個(gè)收取過程沒有發(fā)生上下文切換,因此也就避免了相應(yīng)的開銷。

當(dāng)I/O速率接近CPU速率時(shí),中斷的開銷變得不可忽略,輪詢模式的優(yōu)勢(shì)明顯;相反,如果數(shù)據(jù)吞吐率很低,中斷能有更好的CPU利用率,此時(shí)不宜采用輪詢模式;谝陨戏治,針對(duì)網(wǎng)絡(luò)流量抖動(dòng)較大的場(chǎng)景,可以選用中斷與輪詢的混合模式,即在流量小時(shí)使用中斷模式,當(dāng)遇到大流量時(shí)切換為輪詢模式。目前Linux內(nèi)核與DPDK都支持這種混合中斷輪詢模式。

2.2.2 零復(fù)制技術(shù)

零復(fù)制技術(shù)主要用以避免CPU將數(shù)據(jù)從一個(gè)內(nèi)存區(qū)域復(fù)制到另一個(gè)內(nèi)存區(qū)域帶來的開銷。在NFV數(shù)據(jù)平面操作的場(chǎng)景下,零復(fù)制指的是除網(wǎng)卡將數(shù)據(jù)DMA復(fù)制進(jìn)內(nèi)存外(非CPU參與),從數(shù)據(jù)分組接收到應(yīng)用程序處理數(shù)據(jù)分組,整個(gè)過程中不存在數(shù)據(jù)復(fù)制。零復(fù)制技術(shù)對(duì)于高速網(wǎng)絡(luò)而言是十分必要的。

DPDK、Netmap、PF-ring等高性能數(shù)據(jù)分組處理框架都運(yùn)用了零復(fù)制技術(shù),可以實(shí)現(xiàn)在通用平臺(tái)下高效的網(wǎng)絡(luò)處理,大幅提升單服務(wù)器內(nèi)的報(bào)文轉(zhuǎn)發(fā)性能。進(jìn)一步地,DPDK不僅實(shí)現(xiàn)了網(wǎng)卡緩沖區(qū)到用戶空間的零復(fù)制,還提供虛擬環(huán)境下的虛擬接口、兼容OpenvSwitch虛擬交換機(jī)、專為短小報(bào)文提供的hugepage訪問機(jī)制等實(shí)用技術(shù)。

上述開源方案能很好地滿足NFV中DPI(Deep Packet Inspection,深度數(shù)據(jù)包檢測(cè))、防火墻、CGN(Carrier-Grade NAT <Network Address Translation>,運(yùn)營(yíng)商級(jí)網(wǎng)絡(luò)地址轉(zhuǎn)換)等無需協(xié)議棧的網(wǎng)絡(luò)業(yè)務(wù)功能,但存在著大量改寫原有業(yè)務(wù)應(yīng)用套接字的問題,應(yīng)用中需要在性能提升與代碼改動(dòng)之間進(jìn)行取舍。

2.2.3 高效虛擬化技術(shù)

目前在NFV領(lǐng)域常用的高效虛擬化技術(shù)大致可以歸為以下兩類。

基于硬件的虛擬化技術(shù)

I/O透?jìng)髋cSR-IOV是兩種經(jīng)典的虛擬化技術(shù)。I/O透?jìng)髦傅氖菍⑽锢砭W(wǎng)卡直接分配給客戶機(jī)使用,這種由硬件支持的技術(shù)可以達(dá)到接近宿主機(jī)的性能。不過,由于PCIe設(shè)備有限,PCI研究組織提出并制定了一套虛擬化規(guī)范——SR-IOV,即單根I/O虛擬化,也就是一個(gè)標(biāo)準(zhǔn)化的多虛機(jī)共享物理設(shè)備的機(jī)制。完整的帶有SR-IOV能力的PCIe設(shè)備,能像普通物理PCIe設(shè)備那樣被發(fā)現(xiàn)、管理和配置。

SR-IOV主要的應(yīng)用還是在網(wǎng)卡上,通過SR-IOV,每張?zhí)摂M網(wǎng)卡都有獨(dú)立的中斷、收發(fā)隊(duì)列、QoS等機(jī)制,可以使一塊物理網(wǎng)卡提供多個(gè)虛擬功能(VF),而每個(gè)VF都可以直接分配給客戶機(jī)使用。

SR-IOV使虛擬機(jī)可以直通式訪問物理網(wǎng)卡,并且同一塊網(wǎng)卡可被多個(gè)虛擬機(jī)共享,保證了高I/O性能,但SR-IOV技術(shù)也存在一些問題。由于VF、虛端口和虛擬機(jī)之間存在映射關(guān)系,對(duì)映射關(guān)系的修改存在復(fù)雜性,因此除華為外,大部分廠商目前還無法支持SR-IOV場(chǎng)景下的虛擬機(jī)遷移功能。另外,SR-IOV特性需要物理網(wǎng)卡的硬件支持,并非所有物理網(wǎng)卡都提供支持。

半虛擬化技術(shù)

半虛擬化無需對(duì)硬件做完全的模擬,而是通過客戶機(jī)的前端驅(qū)動(dòng)與宿主機(jī)的后端驅(qū)動(dòng)一同配合完成通信,客戶機(jī)操作系統(tǒng)能夠感知自己處在虛擬化環(huán)境中,故稱為半虛擬化。由于半虛擬化擁有前后端驅(qū)動(dòng),不會(huì)造成VM-exit,所以半虛擬化擁有更高的性能。主流虛擬化平臺(tái)Xen就使用了半虛擬化的驅(qū)動(dòng),半虛擬化比起SR-IOV的優(yōu)勢(shì)在于支持熱遷移,并且可以與主流虛擬交換機(jī)對(duì)接。但是,在大流量轉(zhuǎn)發(fā)場(chǎng)景下,前后端驅(qū)動(dòng)中Domain0也是最大的瓶頸。

2.2.4 硬件分流CPU能力

CPU具有通用性,需要理解多種指令,具備中斷機(jī)制協(xié)調(diào)不同設(shè)備的請(qǐng)求,因此CPU擁有非常復(fù)雜的邏輯控制單元和指令翻譯結(jié)構(gòu),這使得CPU在獲得通用性的同時(shí),損失了計(jì)算效率,在高速轉(zhuǎn)發(fā)場(chǎng)景下降低了NFV的轉(zhuǎn)發(fā)性能。

業(yè)界普遍采用硬件分流方法來解決此問題,CPU僅用于對(duì)服務(wù)器進(jìn)行控制和管理,其他事務(wù)被卸載到硬件進(jìn)行協(xié)同處理,降低CPU消耗,提升轉(zhuǎn)發(fā)性能。

網(wǎng)卡分流技術(shù)是將部分CPU事務(wù)卸載到硬件網(wǎng)卡進(jìn)行處理,目前大多數(shù)網(wǎng)卡設(shè)備已經(jīng)能夠支持卸載特性。網(wǎng)卡卸載的主要功能有:數(shù)據(jù)加解密、數(shù)據(jù)包分類、報(bào)文校驗(yàn)、有狀態(tài)流量分析、Overlay報(bào)文封裝和解封裝、流量負(fù)載均衡,以及根據(jù)通信協(xié)議最大傳輸單元限制,將數(shù)據(jù)包進(jìn)行拆分或整合。

除此之外,CPU+專用加速芯片的異構(gòu)計(jì)算方案也是一種硬件分流思路。異構(gòu)計(jì)算主要是指使用不同類型指令集(X86、ARM、MIPS、POWER等)和體系架構(gòu)的計(jì)算單元(CPU、GPU、NP、ASIC、FPGA等)組成系統(tǒng)的計(jì)算方式。在NFV轉(zhuǎn)發(fā)性能方面,使用可編程的硬件加速芯片(NP、GPU和FPGA)協(xié)同CPU進(jìn)行數(shù)據(jù)處理,可顯著提高數(shù)據(jù)處理速度,從而提升轉(zhuǎn)發(fā)性能。

2.2.5 整體優(yōu)化方案DPDK

PCI直通、SR-IOV方案消除了物理網(wǎng)卡到虛擬網(wǎng)卡的性能瓶頸,但在NFV場(chǎng)景下,仍然有其他I/O環(huán)節(jié)需要進(jìn)行優(yōu)化,如網(wǎng)卡硬件中斷、內(nèi)核協(xié)議棧等。開源項(xiàng)目DPDK作為一套綜合解決方案,對(duì)上述問題進(jìn)行了優(yōu)化與提升,可以應(yīng)用于虛擬交換機(jī)和VNF。DPDK是Intel提供的數(shù)據(jù)平面開發(fā)工具集,為Intel處理器架構(gòu)下用戶空間高效的數(shù)據(jù)包處理提供庫(kù)函數(shù)和驅(qū)動(dòng)的支持。它不同于Linux系統(tǒng)以通用性設(shè)計(jì)為目的,而是專注于網(wǎng)絡(luò)應(yīng)用中數(shù)據(jù)包的高性能處理。有關(guān)DPDK的詳細(xì)介紹,大家可參見《深入淺出DPDK》這本書。

一般來說,服務(wù)器上的每個(gè)CPU核會(huì)被多個(gè)進(jìn)程/線程分時(shí)使用,進(jìn)程/線程切換時(shí),會(huì)引入系統(tǒng)開銷。DPDK支持CPU親和性技術(shù),優(yōu)化多核CPU任務(wù)執(zhí)行,將某進(jìn)程/線程綁定到特定的CPU核,消除切換帶來的額外開銷,從而保證處理性能。

同時(shí),DPDK支持巨頁內(nèi)存技術(shù)。一般情況下,頁表大小為4KB,巨頁技術(shù)將頁表尺寸增大為2MB或1GB,使一次性緩存內(nèi)容更多,有效縮短查表消耗時(shí)間。同時(shí),DPDK提供內(nèi)存池和無鎖環(huán)形緩存管理機(jī)制,加快了內(nèi)存訪問效率。

報(bào)文通過網(wǎng)卡寫入服務(wù)器內(nèi)存的過程中,會(huì)產(chǎn)生CPU硬件中斷,在數(shù)據(jù)流較大的情況下,硬件中斷會(huì)占用大量時(shí)間。DPDK采用輪詢機(jī)制,跳過網(wǎng)卡中斷處理過程,釋放了CPU處理時(shí)間。服務(wù)器對(duì)報(bào)文進(jìn)行收發(fā)時(shí),會(huì)使用內(nèi)核網(wǎng)絡(luò)協(xié)議棧,由此產(chǎn)生內(nèi)核上下文頻繁切換和報(bào)文拷貝問題,占用了CPU周期,消耗了處理時(shí)間。DPDK使用戶態(tài)進(jìn)程可直接讀寫網(wǎng)卡緩沖區(qū),旁路了內(nèi)核協(xié)議棧處理。

DPDK以用戶數(shù)據(jù)I/O通道優(yōu)化為基礎(chǔ),結(jié)合Intel虛擬化技術(shù)(主要是VT-d技術(shù))、操作系統(tǒng)、虛擬化層與虛擬交換機(jī)等多種優(yōu)化方案,形成了完善的轉(zhuǎn)發(fā)性能加速架構(gòu),并開放了用戶態(tài)API供用戶應(yīng)用程序訪問。DPDK已逐漸演變?yōu)闃I(yè)界普遍認(rèn)可的完整NFV轉(zhuǎn)發(fā)性能優(yōu)化技術(shù)方案。但目前DPDK還無法達(dá)到小包線速轉(zhuǎn)發(fā),仍需進(jìn)行性能提升研究和測(cè)試驗(yàn)證工作。

3

運(yùn)營(yíng)商如何推動(dòng)三層解耦落地?

在NFV方面,解耦是首當(dāng)其沖的問題,目前業(yè)界有不解耦、軟硬件解耦和三層解耦這3種思路,其中軟硬件解耦又分為共享虛擬資源池和硬件獨(dú)立兩種方案,不同方案的對(duì)比介紹在本文的NFV部署模式部分已有介紹,這里不再贅述。

不解耦無法實(shí)現(xiàn)硬件共享,運(yùn)營(yíng)商依賴廠商,網(wǎng)絡(luò)開放能力弱,不支持自動(dòng)化部署,顯然不符合NFV技術(shù)的初衷;而僅硬件解耦不支持多廠商VNF在同一云平臺(tái)部署,運(yùn)營(yíng)商仍舊依賴廠商;三層解耦可以解決上述問題,但其涉及多廠商垂直互通,系統(tǒng)集成和維護(hù)難度大,部署周期長(zhǎng)。NFV三層解耦要求在部署NFV時(shí)不同組件由不同的廠商提供,需要比傳統(tǒng)電信網(wǎng)絡(luò)更復(fù)雜的測(cè)試驗(yàn)證、集成和規(guī)劃部署工作。

NFV分層解耦的方式由于缺乏主集成商(蘇研努力的目標(biāo),陜西目前試點(diǎn)的主要目的)和完整驗(yàn)證,距離開放的全解耦目標(biāo)還有相當(dāng)距離,運(yùn)營(yíng)商會(huì)面臨一定的運(yùn)維風(fēng)險(xiǎn)和技術(shù)挑戰(zhàn)。NFV分層解耦的技術(shù)挑戰(zhàn)主要有以下幾點(diǎn):

(1)不同廠商的硬件設(shè)備之間存在管理和配置的差異,如存儲(chǔ)設(shè)備管理配置、安全證書、驅(qū)動(dòng)、硬件配置等方面的問題,會(huì)導(dǎo)致統(tǒng)一資源管理困難、自動(dòng)化配置失效;另一方面,各類VNF和虛擬化軟件部署于不同的硬件設(shè)備上,在缺乏預(yù)先測(cè)試驗(yàn)證的情況下,硬件板卡或外設(shè)之間,如PCIe網(wǎng)卡、RAID卡硬件、BIOS,存在兼容性不一致問題。因此,NFV三層解耦規(guī)模商用前,需要運(yùn)營(yíng)商細(xì)化服務(wù)器安全證書、硬件選型方面的規(guī)范要求,重點(diǎn)關(guān)注硬件可靠性和兼容性問題,在商用前進(jìn)行軟硬件兼容性和可靠性驗(yàn)證。以上問題需要通過大量的適配、驗(yàn)證和調(diào)優(yōu)來解決。

(2)不同基礎(chǔ)軟件之間存在兼容性問題,如操作系統(tǒng)與驅(qū)動(dòng)層之間、虛擬交換機(jī)與操作系統(tǒng)之間、虛擬化軟件與VNF之間,不同的模塊和不同的版本,以及不同的配置參數(shù)、優(yōu)化方法,都會(huì)造成性能、穩(wěn)定性、兼容性的較大差異,有待進(jìn)一步測(cè)試與驗(yàn)證。為此,需要盡量減少虛擬化層類型,適時(shí)引入自主研發(fā)虛擬化層軟件,減少持續(xù)不斷的三層解耦測(cè)試工作量。采用集中的云管平臺(tái)(統(tǒng)一VIM),降低NFVO與VIM集成的復(fù)雜度。

(3)分層之后,從NFV各層之間的接口定義與數(shù)據(jù)類型,到層內(nèi)功能的實(shí)現(xiàn)機(jī)制,乃至層間的協(xié)同處理均需要運(yùn)營(yíng)商去推動(dòng)和完善。如VNF在發(fā)生故障時(shí),涉及VM遷移與業(yè)務(wù)倒換機(jī)制以及NFVI、NFVO和VIM的處理流程;又如VNF對(duì)配置文件管理和存儲(chǔ)設(shè)備使用不當(dāng),同樣會(huì)導(dǎo)致VM實(shí)例化失效。因而,在VNF多廠家集成過程中,集成方或者運(yùn)營(yíng)商需要需要有角色對(duì)問題定界、定位進(jìn)行裁決,在集成和運(yùn)維的過程中,對(duì)技術(shù)問題進(jìn)行端到端的管理,對(duì)各層的功能進(jìn)行詳細(xì)定義或者詳細(xì)規(guī)范。

(4)NFV系統(tǒng)集成涉及多廠商、多軟硬組件的高度集成,由于虛擬化環(huán)境的存在,在初期的測(cè)試驗(yàn)證、中期的系統(tǒng)部署、后期的運(yùn)維過程中,進(jìn)行系統(tǒng)評(píng)測(cè)與管理部署都較為困難。這就要求運(yùn)營(yíng)商在提升DevOps能力的基礎(chǔ)上,依托持續(xù)集成與持續(xù)部署和運(yùn)維自動(dòng)化技術(shù),形成NFV系統(tǒng)的持續(xù)集成、測(cè)試和部署能力,大白話就是要求運(yùn)營(yíng)商亟待需要提升自主開發(fā)、自主集成和自主測(cè)試能力。同時(shí),MANO架構(gòu)需要全網(wǎng)統(tǒng)一。由于目前VNFM通常與VNF是綁定的廠商組件,而實(shí)際上真正的VIM也是廠商提供的,因此VNFM、VIM仍然是與VNF、NFVI就近部署。所以需要盡早明確NFVO的架構(gòu)(例如,采用集團(tuán)NFVO+區(qū)域NFVO兩層架構(gòu)),明確VNFM和VIM的跨專業(yè)、跨地域部署能力和部署位置,明確已部署的云管平臺(tái)與VIM架構(gòu)的關(guān)系,以及已有的EMS、NMS與VNFM架構(gòu)的關(guān)系。

對(duì)于運(yùn)營(yíng)商來說,三層解耦會(huì)是一個(gè)較長(zhǎng)的過程,與廠商的博弈也需要時(shí)間,再加上自主能力(研發(fā)、測(cè)試、集成)也需要時(shí)間,在實(shí)現(xiàn)最終目標(biāo)之前可以先選擇過渡方案,例如廠商一體化方案(不適合作為商業(yè)化規(guī)模部署方案)、部分解耦方案(硬件與軟件解耦、MANO中的NFVO解耦出來)等,在試點(diǎn)和小規(guī)模部署過程中培育能力,逐漸實(shí)現(xiàn)最終的解耦目標(biāo),并在解耦基礎(chǔ)上逐步提升自主研發(fā)比例,增強(qiáng)對(duì)網(wǎng)絡(luò)NFV化的掌控力。

4

MANO管理模式利弊分析

EISI NFV對(duì)MANO的資源管理提出直接模式和間接模式兩種方案。NFV-MANO允許NFVO和VNFM兩者都能管理VNF生命周期所需的虛擬化資源,直接和間接是相對(duì)VNFM而言的。

直接(Direct)模式:VNFM直接通過VIM分配VNF生命周期管理所需的虛擬化資源。VNFM向NFVO提出對(duì)VNF的生命周期管理操作進(jìn)行資源授權(quán),NFVO根據(jù)操作請(qǐng)求及整體資源情況返回授權(quán)結(jié)果;VNFM根據(jù)授權(quán)結(jié)果直接與VIM交互完成資源的調(diào)度(分配、修改、釋放等);VNFM向NFVO反饋資源變更情況。如下圖所示:

間接(Indirect)模式:VNFM向NFVO提出對(duì)VNF的生命周期管理操作進(jìn)行資源授權(quán),NFVO根據(jù)操作請(qǐng)求及整體資源情況返回授權(quán)結(jié)果;VNFM根據(jù)授權(quán)結(jié)果向NFVO提出資源調(diào)度(分配、修改、釋放等)請(qǐng)求,NFVO與VIM交互完成實(shí)際的資源調(diào)度工作;NFVO向VNFM反饋資源變更情況。如下圖所示:

總體而言,兩者都由VNFM提供VNF生命周期管理。在執(zhí)行VNF生命周期管理操作之前,無論該操作新增資源,還是修改或者釋放已分配的資源,VNFM都需要向NFVO請(qǐng)求資源授權(quán);資源容量和狀態(tài)等信息由NVFO統(tǒng)一維護(hù)管理。兩種模式的不同主要體現(xiàn)在:直接模式下,VNFM和NFVO都需要與VIM交互,將VIM的虛擬資源管理接口暴露給VNFM使用;間接模式下,VFNM不需要和VIM進(jìn)行交互,NFVO需要提供VIM代理能力。

兩種模式在架構(gòu)、業(yè)務(wù)成效、性能、集成復(fù)雜度以及安全性方面的對(duì)比分析如下所示:

綜合以上分析,從功能、落地部署、安全性、未來演進(jìn)角度考慮,間接模式較好;性能方面,直接模式占優(yōu);系統(tǒng)集成復(fù)雜度兩者相當(dāng)。考慮網(wǎng)絡(luò)的未來發(fā)展,從運(yùn)營(yíng)商對(duì)網(wǎng)絡(luò)的自主掌控能力出發(fā),要求廠商必須支持間接模式,以推進(jìn)分層解耦、實(shí)現(xiàn)對(duì)虛擬資源的統(tǒng)一管控。

5

VNFM如何選型?

通用VNFM和專用VNFM是ETSI定義的兩種架構(gòu)選項(xiàng)。

通用VNFM:通用VNFM可以服務(wù)于不同類型或不同廠商提供的VNF,對(duì)它所管理的多種類型、多廠商VNF的操作沒有依賴性,但它必須能夠在VNF包中定義的不同VNF的特定腳本。按照管理要求,可能有多個(gè)通用VNFM,每個(gè)VNFM管理一定VNF的子集。在這種情況下,NFVO需要同時(shí)處理多個(gè)通用VNFM。下圖展示了通用VNFM的架構(gòu)。

專用VNFM:專用VNFM與它所管理的VNF之間具有依賴性,一般管理由同一廠商提供的VNF。NFV架構(gòu)框架同時(shí)也允許一個(gè)或多個(gè)專用VNFM連接到單個(gè)NFVO。在VNF生命周期管理過程復(fù)雜,且一些管理特性與這些VNF緊耦合的場(chǎng)景下,就需要使用專用VNFM。下圖展示了專用VNFM的架構(gòu)。

兩種架構(gòu)選項(xiàng)具有相同的VNFM功能要求,如VNFD解析,獲得部署VNF所需資源要求及所需部署的業(yè)務(wù)軟件;NFVI告警與VNF告警關(guān)聯(lián)、VNF彈性策略執(zhí)行;VNF生命周期管理,包括實(shí)例化、查詢、擴(kuò)/縮容、終止等。但是,兩種架構(gòu)在技術(shù)實(shí)現(xiàn)難度、運(yùn)維復(fù)雜度等方面卻存在著差異。

6

NFVO如何部署?

目前,ETSI NFV進(jìn)一步細(xì)化了NFVO功能模塊的具體功能要求。按照MANO規(guī)范,NFVO可以分解為網(wǎng)絡(luò)服務(wù)編排(Network Service Orchestrator,NSO)和資源編排(Resource Orchestrator,RO)。網(wǎng)絡(luò)服務(wù)生命周期的管理功能,即NSO功能;跨VIM的NFVI資源編排功能,即RO功能。NFVO作為MANO的一個(gè)功能實(shí)體,在部署時(shí),可以有如下兩種部署形態(tài)。

6.1 NFVO功能不分解部署

NFVO作為一個(gè)獨(dú)立的實(shí)體部署,可采用級(jí)聯(lián)的方式來部署。如下圖所示,每個(gè)管理域可以被當(dāng)作一個(gè)或多個(gè)數(shù)據(jù)中心,在該管理域中部署一套獨(dú)立的NFVO,以及VNFMs、VIMs,用來管理該域中的網(wǎng)絡(luò)服務(wù)。另外,再部署一套頂層NFVO,用來管理域間的網(wǎng)絡(luò)服務(wù),它并不管理下層管理域中的網(wǎng)絡(luò)服務(wù),不過它可以接收下層管理域中網(wǎng)絡(luò)服務(wù)實(shí)例化、彈性伸縮,以及終止操作的請(qǐng)求,并將此請(qǐng)求直接傳遞給下層管理域中的NFVO,由下層管理域的NFVO來完成實(shí)際的操作。

6.2 NFVO功能分解部署

NFVO可以分為兩個(gè)獨(dú)立的實(shí)體來部署,NSO主要完成NS的生命周期管理,包括NS模板以及VNF包的管理,如下圖所示。NSO不再關(guān)注資源的狀態(tài)以及資源所在的管理域,僅關(guān)注資源的額度。RO主要完成管理域內(nèi)資源的管理和編排,如資源的預(yù)留、分配、刪除等操作,以及支持資源的使用率和狀態(tài)的監(jiān)控。

NFVO功能不分解部署時(shí),資源申請(qǐng)效率高;集成難度相對(duì)較低;若NFVO故障,則只會(huì)影響該NFVO管理域的業(yè)務(wù)和資源。NFVO分解后,VNFM訪問或申請(qǐng)資源的效率會(huì)降低;如果RO出現(xiàn)故障,則只會(huì)影響該RO管理的資源;但是,一旦NSO出現(xiàn)故障,則將影響所有整個(gè)NFV的業(yè)務(wù)功能;NFVO分解為NSO、RO之后,或增加NSO-RO之間的接口,增加系統(tǒng)集成難度。

根據(jù)分析比較,在一定的業(yè)務(wù)規(guī)模下,將NFVO分解為NSO、RO難以帶來明顯的優(yōu)勢(shì)或收益,反而會(huì)導(dǎo)致性能降低、集成復(fù)雜。因此,建議NFVO采用不分解架構(gòu)。另外,考慮后續(xù)的演進(jìn)和發(fā)展,在技術(shù)架構(gòu)上可將NSO和RO進(jìn)行內(nèi)部功能解耦,并實(shí)現(xiàn)微服務(wù)化,以增強(qiáng)未來NFVO部署的靈活性。

編 輯:章芳
聲明:刊載本文目的在于傳播更多行業(yè)信息,本站只提供參考并不構(gòu)成任何投資及應(yīng)用建議。如網(wǎng)站內(nèi)容涉及作品版權(quán)和其它問題,請(qǐng)?jiān)?0日內(nèi)與本網(wǎng)聯(lián)系,我們將在第一時(shí)間刪除內(nèi)容。本站聯(lián)系電話為86-010-87765777,郵件后綴為#cctime.com,冒充本站員工以任何其他聯(lián)系方式,進(jìn)行的“內(nèi)容核實(shí)”、“商務(wù)聯(lián)系”等行為,均不能代表本站。本站擁有對(duì)此聲明的最終解釋權(quán)。
相關(guān)新聞              
 
人物
工信部張?jiān)泼鳎捍蟛糠謬?guó)家新劃分了中頻段6G頻譜資源
精彩專題
專題丨“汛”速出動(dòng) 共筑信息保障堤壩
2023MWC上海世界移動(dòng)通信大會(huì)
中國(guó)5G商用四周年
2023年中國(guó)國(guó)際信息通信展覽會(huì)
CCTIME推薦
關(guān)于我們 | 廣告報(bào)價(jià) | 聯(lián)系我們 | 隱私聲明 | 本站地圖
CCTIME飛象網(wǎng) CopyRight © 2007-2024 By CCTIME.COM
京ICP備08004280號(hào)-1  電信與信息服務(wù)業(yè)務(wù)經(jīng)營(yíng)許可證080234號(hào) 京公網(wǎng)安備110105000771號(hào)
公司名稱: 北京飛象互動(dòng)文化傳媒有限公司
未經(jīng)書面許可,禁止轉(zhuǎn)載、摘編、復(fù)制、鏡像