Labs 導(dǎo)讀
NFV技術(shù)從誕生起，從根本上來說就是為了解決運(yùn)營商網(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)營商期望的多層解耦部署模式推行困難。同時(shí)，在NFV的轉(zhuǎn)發(fā)性能提升、MANO管理模式選型、VNFM選型和NFVO部署等方面也多多少少存在影響電信云落地的問題。
1 NFV部署模式選型
NFV通過軟硬件解耦，使得網(wǎng)絡(luò)設(shè)備開放化，軟硬件可以獨(dú)立演進(jìn)，避免廠家鎖定�；贜FV分層解耦的特性，根據(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í)。目前，中國電信的4G/VoLTE/IMS網(wǎng)絡(luò)就是采用這種方式，在短期內(nèi)對(duì)中國移動(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的定位，考慮到中國移動(dòng)蘇州研發(fā)中心與VMware的戰(zhàn)略合作情況，可以預(yù)期不遠(yuǎn)的將來中國移動(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)上。目前，中國移動(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)營復(fù)雜度高，故障定位和排除較為困難，對(duì)運(yùn)營商的運(yùn)營能力要求較高。該模式是中國移動(dòng)一直不遺余力推廣的模式，目前在陜西移動(dòng)已初步完成蘇研VIM+分布式存儲(chǔ)、華為VNFM和研究院NFVO+的標(biāo)準(zhǔn)三層部署模式驗(yàn)證，并打通了標(biāo)準(zhǔn)三層組網(wǎng)下FirstCall。
另外，以上各方案都涉及MANO的解耦，涉及運(yùn)營商自主開發(fā)或者第三方的NFVO與不同廠商的VNFM、VIM之間的對(duì)接和打通，屏蔽了供應(yīng)商間的差異，統(tǒng)一實(shí)現(xiàn)網(wǎng)絡(luò)功能的協(xié)同、面向業(yè)務(wù)的編排與虛擬資源的管理。但是，NFVO+的解耦目前還停留在實(shí)驗(yàn)驗(yàn)證階段，在中國移動(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)營商級(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ù)包處理提供庫函數(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)營商如何推動(dòng)三層解耦落地？
在NFV方面，解耦是首當(dāng)其沖的問題，目前業(yè)界有不解耦、軟硬件解耦和三層解耦這3種思路，其中軟硬件解耦又分為共享虛擬資源池和硬件獨(dú)立兩種方案，不同方案的對(duì)比介紹在本文的NFV部署模式部分已有介紹，這里不再贅述。
不解耦無法實(shí)現(xiàn)硬件共享，運(yùn)營商依賴廠商，網(wǎng)絡(luò)開放能力弱，不支持自動(dòng)化部署，顯然不符合NFV技術(shù)的初衷；而僅硬件解耦不支持多廠商VNF在同一云平臺(tái)部署，運(yùn)營商仍舊依賴廠商；三層解耦可以解決上述問題，但其涉及多廠商垂直互通，系統(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)營商會(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)營商細(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)營商去推動(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)營商需要需要有角色對(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)營商在提升DevOps能力的基礎(chǔ)上，依托持續(xù)集成與持續(xù)部署和運(yùn)維自動(dòng)化技術(shù)，形成NFV系統(tǒng)的持續(xù)集成、測(cè)試和部署能力，大白話就是要求運(yùn)營商亟待需要提升自主開發(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)營商來說，三層解耦會(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)營商對(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部署的靈活性。
