建站
咨詢
售后
建站咨詢
新聞中心
Labs 導(dǎo)讀
NFV技術(shù)從誕生起，從根本上來說就是為了解決運(yùn)營商網(wǎng)絡(luò)演進(jìn)中部署成本高，迭代更新慢，架構(gòu)僵化等痛點問題。同時，在引入NFV技術(shù)前，舊有產(chǎn)業(yè)鏈相對單一，核心成員主要包括設(shè)備制造商、芯片制造商等，而NFV引入后拉長了整體通信產(chǎn)業(yè)鏈條，傳統(tǒng)設(shè)備制造商面臨嚴(yán)峻的挑戰(zhàn)，原本軟硬件一體化設(shè)備銷售模式被拆解為通用硬件、虛擬化平臺和網(wǎng)元功能三部分銷售模式。這也直接決定了運(yùn)營商期望的多層解耦部署模式推行困難。同時，在NFV的轉(zhuǎn)發(fā)性能提升、MANO管理模式選型、VNFM選型和NFVO部署等方面也多多少少存在影響電信云落地的問題。
專注于為中小企業(yè)提供成都網(wǎng)站制作、網(wǎng)站建設(shè)服務(wù),電腦端+手機(jī)端+微信端的三站合一,更高效的管理,為中小企業(yè)韶關(guān)免費做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動了1000+企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設(shè)實現(xiàn)規(guī)模擴(kuò)充和轉(zhuǎn)變。
1、NFV部署模式選型
NFV通過軟硬件解耦，使得網(wǎng)絡(luò)設(shè)備開放化，軟硬件可以獨立演進(jìn)，避免廠家鎖定。基于NFV分層解耦的特性，根據(jù)軟硬件解耦的開放性不同，可將集成策略分為單廠家、共享資源池、硬件獨立和三層全解耦4種方案，如下圖所示。
方案1：單廠家方案，優(yōu)點就是可以實現(xiàn)快速部署，整體系統(tǒng)的性能、穩(wěn)定性與可靠性都比較理想，不需要進(jìn)行異構(gòu)廠商的互通測試與集成。缺點是與傳統(tǒng)網(wǎng)絡(luò)設(shè)備一樣，存在軟硬件一體化和封閉性問題，難以實現(xiàn)靈活的架構(gòu)部署，不利于實現(xiàn)共享;與廠商存在捆綁關(guān)系，不利于競爭，會再次形成煙囪式部署，總體成本較高，也不利于自主創(chuàng)新以及靈活的迭代式部署升級。目前，中國電信的4G/VoLTE/IMS網(wǎng)絡(luò)就是采用這種方式，在短期內(nèi)對中國移動的業(yè)務(wù)發(fā)展形成較大壓力。
方案2：傾向于IT化思路，選擇最好的硬件平臺和虛擬機(jī)產(chǎn)品，要求上層應(yīng)用向底層平臺靠攏。只對VNF與NFVI層解耦，VNF能夠部署于統(tǒng)一管理的虛擬資源之上，并確保功能可用、性能良好、運(yùn)行情況可監(jiān)控、故障可定位;不同供應(yīng)商的VNF可靈活配置、可互通、可混用、可集約管理。其中，VNFM與VNF通常為同一廠商(即“專用VNFM”)，這種情況下VNF與VNFM之間的接口不需標(biāo)準(zhǔn)化;特殊場景下采用跨廠商的“VNFM”(即“通用VNFM”)。VMware的解決方案就是典型的方案二廠商A的定位，考慮到中國移動蘇州研發(fā)中心與VMware的戰(zhàn)略合作情況，可以預(yù)期不遠(yuǎn)的將來中國移動的NFV網(wǎng)絡(luò)架構(gòu)中會出現(xiàn)類似部署方案。
方案3：傾向于電信思路，通用硬件與虛擬化層軟件解耦，基礎(chǔ)設(shè)施全部采用通用硬件，實現(xiàn)多供應(yīng)商設(shè)備混用;虛擬化層采用商用/開源軟件進(jìn)行虛擬資源的統(tǒng)一管理。可以由電信設(shè)備制造商提供所有軟件，只是適配在IT平臺上。目前，中國移動大區(qū)集中化網(wǎng)絡(luò)建設(shè)就是采用此部署方案。
方案4：全解耦的好處是可以實現(xiàn)通用化、標(biāo)準(zhǔn)化、模塊化、分布式部署，架構(gòu)靈活，而且部分核心模塊可選擇進(jìn)行定制與自主研發(fā)，也有利于形成競爭，降低成本，實現(xiàn)規(guī)?；渴?不利的地方是需要規(guī)范和標(biāo)準(zhǔn)化，周期很長，也需要大量的多廠商互通測試，需要很強(qiáng)的集成開發(fā)能力，部署就緒時間長，效率較低，后續(xù)的運(yùn)營復(fù)雜度高，故障定位和排除較為困難，對運(yùn)營商的運(yùn)營能力要求較高。該模式是中國移動一直不遺余力推廣的模式，目前在陜西移動已初步完成蘇研VIM+分布式存儲、華為VNFM和研究院NFVO+的標(biāo)準(zhǔn)三層部署模式驗證，并打通了標(biāo)準(zhǔn)三層組網(wǎng)下FirstCall。
另外，以上各方案都涉及MANO的解耦，涉及運(yùn)營商自主開發(fā)或者第三方的NFVO與不同廠商的VNFM、VIM之間的對接和打通，屏蔽了供應(yīng)商間的差異，統(tǒng)一實現(xiàn)網(wǎng)絡(luò)功能的協(xié)同、面向業(yè)務(wù)的編排與虛擬資源的管理。但是，NFVO+的解耦目前還停留在實驗驗證階段，在中國移動的電信云一階段還是采用NFVO與VNFM同廠商捆綁的模式。
2、NFV轉(zhuǎn)發(fā)性能的提升
NFV設(shè)計的初衷是針對部分低轉(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ù)的推動，引入了40Gbit/s的高速轉(zhuǎn)發(fā)能力，但目前也只是實驗驗證階段，并未實際部署)。
傳統(tǒng)硬件網(wǎng)元能夠通過專用芯片實現(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ù)，報文在服務(wù)器各層面間傳遞，會受到CPU開銷等多方面因素的影響，因此服務(wù)器的內(nèi)部轉(zhuǎn)發(fā)性能是NFV系統(tǒng)的主要瓶頸。
NFV中的網(wǎng)絡(luò)業(yè)務(wù)應(yīng)用運(yùn)行于服務(wù)器的虛擬化環(huán)境中，單個應(yīng)用業(yè)務(wù)流量的收發(fā)要經(jīng)過虛擬化層、服務(wù)器I/O通道、內(nèi)核協(xié)議棧等多個處理流程，而多個應(yīng)用業(yè)務(wù)之間又可以用復(fù)雜的物理或虛擬網(wǎng)絡(luò)相連接。因此，NFV系統(tǒng)的整體性能取決于單服務(wù)器轉(zhuǎn)發(fā)性能與業(yè)務(wù)組鏈轉(zhuǎn)發(fā)性能兩個方面。如下所示：
業(yè)務(wù)應(yīng)用流量的收發(fā)I/O通道依次包括物理網(wǎng)卡、虛擬交換機(jī)、虛擬網(wǎng)卡3個環(huán)節(jié)(見上圖左半部分);從軟件結(jié)構(gòu)上看，報文的收發(fā)需要經(jīng)過物理網(wǎng)卡驅(qū)動、宿主機(jī)內(nèi)核網(wǎng)絡(luò)協(xié)議棧、內(nèi)核態(tài)虛擬交換層、虛擬機(jī)網(wǎng)卡驅(qū)動、虛擬機(jī)內(nèi)核態(tài)網(wǎng)絡(luò)協(xié)議棧、虛擬機(jī)用戶態(tài)應(yīng)用等多個轉(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)卡在收到報文后，一般采用DMA(Direct Memory Access，直接存儲器存取)方式直接寫入內(nèi)存并產(chǎn)生CPU硬件中斷，在低速轉(zhuǎn)發(fā)應(yīng)用中此方法十分有效。
但是，當(dāng)網(wǎng)絡(luò)流量激增時，CPU的大部分時間阻塞于中斷響應(yīng)。在多核系統(tǒng)中，可能存在多塊網(wǎng)卡綁定同一個CPU核的情況，使其占用率達(dá)到100%。中斷處理方式在低速網(wǎng)絡(luò)I/O場景下非常有效。然而，隨著高速網(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)卡面對大量高速數(shù)據(jù)分組引發(fā)頻繁的中斷，中斷引起的上下文切換開銷將變得不可忽視，造成較高的時延，并引起吞吐量下降。因此，網(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ā)時，會使用內(nèi)核網(wǎng)絡(luò)協(xié)議棧。這將產(chǎn)生兩方面的性能問題：一是系統(tǒng)調(diào)用導(dǎo)致的內(nèi)核上下文切換，會頻繁占用CPU周期;二是協(xié)議棧與用戶進(jìn)程間的報文復(fù)制是一種費時的操作。
NFV系統(tǒng)中，業(yè)務(wù)應(yīng)用報文處理從物理網(wǎng)卡到業(yè)務(wù)應(yīng)用需要完成收發(fā)操作各1次，至少經(jīng)過4次上下文切換(宿主機(jī)2次以及VM內(nèi)2次)和4次報文復(fù)制。將網(wǎng)絡(luò)協(xié)議棧移植到用戶態(tài)是一種可行的思路，但這種方法違反了GNU協(xié)議。GNU是GNU GPL(GNU General Public License，通用公共許可證)的簡稱，Linux內(nèi)核受GNU GPL保護(hù)，內(nèi)核代碼不能用于Linux內(nèi)核外。因此，棄用網(wǎng)絡(luò)協(xié)議棧以換取轉(zhuǎn)發(fā)性能，是唯一可行的辦法，但需要付出大量修改業(yè)務(wù)應(yīng)用代碼的代價。
2.1.3 虛擬化層的封裝效率
業(yè)務(wù)應(yīng)用中存在兩類封裝：服務(wù)器內(nèi)部的I/O封裝和網(wǎng)絡(luò)層對流量的虛擬化封裝。前者是由于NFV的業(yè)務(wù)應(yīng)用運(yùn)行于VM中，流量需要經(jīng)歷多次封裝/解封裝過程，包括：宿主機(jī)虛擬化軟件對VM的I/O封裝、虛擬交換機(jī)對端口的封裝、云管理平臺對虛擬網(wǎng)絡(luò)端口的封裝;后者是為實現(xiàn)NFV用戶隔離，在流量中添加的用戶標(biāo)識，如VLAN、VxLAN(Virtual Extensible Local Area Network，可擴(kuò)展虛擬局域網(wǎng))等。這兩類封裝/解封均要消耗CPU周期，會降低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ù)量較大時，會消耗大量網(wǎng)絡(luò)設(shè)備端口。因此，在業(yè)務(wù)鏈組網(wǎng)范圍不大時，如在IDC內(nèi)部，為簡化組網(wǎng)和節(jié)約端口，更多地采用串行連接。
當(dāng)串行連接時，NFV控制器需要在多個業(yè)務(wù)應(yīng)用中選擇合適位置的應(yīng)用進(jìn)程或進(jìn)程組來處理流量，以均衡各應(yīng)用負(fù)荷并兼顧業(yè)務(wù)鏈網(wǎng)絡(luò)性能。不合適的負(fù)載均衡算法會造成流量在不同進(jìn)程組的上下行鏈路之間反復(fù)穿越，嚴(yán)重降低業(yè)務(wù)鏈網(wǎng)絡(luò)的帶寬利用率。
2.1.5 其他開銷
緩存未命中開銷：緩存是一種能夠有效提高系統(tǒng)性能的方式，然而，由于設(shè)計的不合理造成頻繁的緩存未命中，則會嚴(yán)重削弱NFV數(shù)據(jù)平面的性能。
鎖開銷：當(dāng)多個線程或進(jìn)程需要對某一共享資源進(jìn)行操作時，往往需要通過鎖機(jī)制來保證數(shù)據(jù)的一致性和同步性，而加鎖帶來的開銷會顯著降低數(shù)據(jù)處理的性能。
上下文切換開銷：NFV的擴(kuò)展需要多核并行化的支持，然而在該場景下，數(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種開銷對于NFV轉(zhuǎn)發(fā)性能的影響較大，在實際的轉(zhuǎn)發(fā)過程中，開銷不止這3種。
2.2 NFV引入的開源技術(shù)
針對以上影響轉(zhuǎn)發(fā)性能的挑戰(zhàn)，NFV在落地過程引入不同開源技術(shù)進(jìn)行應(yīng)對，具體的實現(xiàn)原理會在第二部分《NFV關(guān)鍵技術(shù)》中詳細(xì)闡述，這里只是做一個簡單的介紹，使初學(xué)者有個概念性的了解。
2.2.1 輪詢?nèi)〈袛?/h4>
作為I/O通信的另一種方式，輪詢不存在中斷所固有的開銷。以網(wǎng)卡接收分組為例，在輪詢模式下，系統(tǒng)會在初始化時屏蔽收發(fā)分組中斷，并使用一個線程或進(jìn)程來不斷檢測收取分組描述符中的收取分組成功標(biāo)志是否被網(wǎng)卡置位，以此來判斷是否有數(shù)據(jù)分組。整個收取過程沒有發(fā)生上下文切換，因此也就避免了相應(yīng)的開銷。
當(dāng)I/O速率接近CPU速率時，中斷的開銷變得不可忽略，輪詢模式的優(yōu)勢明顯;相反，如果數(shù)據(jù)吞吐率很低，中斷能有更好的CPU利用率，此時不宜采用輪詢模式?；谝陨戏治?，針對網(wǎng)絡(luò)流量抖動較大的場景，可以選用中斷與輪詢的混合模式，即在流量小時使用中斷模式，當(dāng)遇到大流量時切換為輪詢模式。目前Linux內(nèi)核與DPDK都支持這種混合中斷輪詢模式。
2.2.2 零復(fù)制技術(shù)
零復(fù)制技術(shù)主要用以避免CPU將數(shù)據(jù)從一個內(nèi)存區(qū)域復(fù)制到另一個內(nèi)存區(qū)域帶來的開銷。在NFV數(shù)據(jù)平面操作的場景下，零復(fù)制指的是除網(wǎng)卡將數(shù)據(jù)DMA復(fù)制進(jìn)內(nèi)存外(非CPU參與)，從數(shù)據(jù)分組接收到應(yīng)用程序處理數(shù)據(jù)分組，整個過程中不存在數(shù)據(jù)復(fù)制。零復(fù)制技術(shù)對于高速網(wǎng)絡(luò)而言是十分必要的。
DPDK、Netmap、PF-ring等高性能數(shù)據(jù)分組處理框架都運(yùn)用了零復(fù)制技術(shù)，可以實現(xiàn)在通用平臺下高效的網(wǎng)絡(luò)處理，大幅提升單服務(wù)器內(nèi)的報文轉(zhuǎn)發(fā)性能。進(jìn)一步地，DPDK不僅實現(xiàn)了網(wǎng)卡緩沖區(qū)到用戶空間的零復(fù)制，還提供虛擬環(huán)境下的虛擬接口、兼容OpenvSwitch虛擬交換機(jī)、專為短小報文提供的hugepage訪問機(jī)制等實用技術(shù)。
上述開源方案能很好地滿足NFV中DPI(Deep Packet Inspection，深度數(shù)據(jù)包檢測)、防火墻、CGN(Carrier-Grade NAT ，運(yùn)營商級網(wǎng)絡(luò)地址轉(zhuǎn)換)等無需協(xié)議棧的網(wǎng)絡(luò)業(yè)務(wù)功能，但存在著大量改寫原有業(yè)務(wù)應(yīng)用套接字的問題，應(yīng)用中需要在性能提升與代碼改動之間進(jìn)行取舍。
2.2.3 高效虛擬化技術(shù)
目前在NFV領(lǐng)域常用的高效虛擬化技術(shù)大致可以歸為以下兩類。
基于硬件的虛擬化技術(shù)
I/O透傳與SR-IOV是兩種經(jīng)典的虛擬化技術(shù)。I/O透傳指的是將物理網(wǎng)卡直接分配給客戶機(jī)使用，這種由硬件支持的技術(shù)可以達(dá)到接近宿主機(jī)的性能。不過，由于PCIe設(shè)備有限，PCI研究組織提出并制定了一套虛擬化規(guī)范——SR-IOV，即單根I/O虛擬化，也就是一個標(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)卡都有獨立的中斷、收發(fā)隊列、QoS等機(jī)制，可以使一塊物理網(wǎng)卡提供多個虛擬功能(VF)，而每個VF都可以直接分配給客戶機(jī)使用。
SR-IOV使虛擬機(jī)可以直通式訪問物理網(wǎng)卡，并且同一塊網(wǎng)卡可被多個虛擬機(jī)共享，保證了高I/O性能，但SR-IOV技術(shù)也存在一些問題。由于VF、虛端口和虛擬機(jī)之間存在映射關(guān)系，對映射關(guān)系的修改存在復(fù)雜性，因此除華為外，大部分廠商目前還無法支持SR-IOV場景下的虛擬機(jī)遷移功能。另外，SR-IOV特性需要物理網(wǎng)卡的硬件支持，并非所有物理網(wǎng)卡都提供支持。
半虛擬化技術(shù)
半虛擬化無需對硬件做完全的模擬，而是通過客戶機(jī)的前端驅(qū)動與宿主機(jī)的后端驅(qū)動一同配合完成通信，客戶機(jī)操作系統(tǒng)能夠感知自己處在虛擬化環(huán)境中，故稱為半虛擬化。由于半虛擬化擁有前后端驅(qū)動，不會造成VM-exit，所以半虛擬化擁有更高的性能。主流虛擬化平臺Xen就使用了半虛擬化的驅(qū)動，半虛擬化比起SR-IOV的優(yōu)勢在于支持熱遷移，并且可以與主流虛擬交換機(jī)對接。但是，在大流量轉(zhuǎn)發(fā)場景下，前后端驅(qū)動中Domain0也是最大的瓶頸。
2.2.4 硬件分流CPU能力
CPU具有通用性，需要理解多種指令，具備中斷機(jī)制協(xié)調(diào)不同設(shè)備的請求，因此CPU擁有非常復(fù)雜的邏輯控制單元和指令翻譯結(jié)構(gòu)，這使得CPU在獲得通用性的同時，損失了計算效率，在高速轉(zhuǎn)發(fā)場景下降低了NFV的轉(zhuǎn)發(fā)性能。
業(yè)界普遍采用硬件分流方法來解決此問題，CPU僅用于對服務(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ù)包分類、報文校驗、有狀態(tài)流量分析、Overlay報文封裝和解封裝、流量負(fù)載均衡，以及根據(jù)通信協(xié)議最大傳輸單元限制，將數(shù)據(jù)包進(jìn)行拆分或整合。
除此之外，CPU+專用加速芯片的異構(gòu)計算方案也是一種硬件分流思路。異構(gòu)計算主要是指使用不同類型指令集(X86、ARM、MIPS、POWER等)和體系架構(gòu)的計算單元(CPU、GPU、NP、ASIC、FPGA等)組成系統(tǒng)的計算方式。在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場景下，仍然有其他I/O環(huán)節(jié)需要進(jìn)行優(yōu)化，如網(wǎng)卡硬件中斷、內(nèi)核協(xié)議棧等。開源項目DPDK作為一套綜合解決方案，對上述問題進(jìn)行了優(yōu)化與提升，可以應(yīng)用于虛擬交換機(jī)和VNF。DPDK是Intel提供的數(shù)據(jù)平面開發(fā)工具集，為Intel處理器架構(gòu)下用戶空間高效的數(shù)據(jù)包處理提供庫函數(shù)和驅(qū)動的支持。它不同于Linux系統(tǒng)以通用性設(shè)計為目的，而是專注于網(wǎng)絡(luò)應(yīng)用中數(shù)據(jù)包的高性能處理。有關(guān)DPDK的詳細(xì)介紹，大家可參見《深入淺出DPDK》這本書。
一般來說，服務(wù)器上的每個CPU核會被多個進(jìn)程/線程分時使用，進(jìn)程/線程切換時，會引入系統(tǒng)開銷。DPDK支持CPU親和性技術(shù)，優(yōu)化多核CPU任務(wù)執(zhí)行，將某進(jìn)程/線程綁定到特定的CPU核，消除切換帶來的額外開銷，從而保證處理性能。
同時，DPDK支持巨頁內(nèi)存技術(shù)。一般情況下，頁表大小為4KB，巨頁技術(shù)將頁表尺寸增大為2MB或1GB，使一次性緩存內(nèi)容更多，有效縮短查表消耗時間。同時，DPDK提供內(nèi)存池和無鎖環(huán)形緩存管理機(jī)制，加快了內(nèi)存訪問效率。
報文通過網(wǎng)卡寫入服務(wù)器內(nèi)存的過程中，會產(chǎn)生CPU硬件中斷，在數(shù)據(jù)流較大的情況下，硬件中斷會占用大量時間。DPDK采用輪詢機(jī)制，跳過網(wǎng)卡中斷處理過程，釋放了CPU處理時間。服務(wù)器對報文進(jìn)行收發(fā)時，會使用內(nèi)核網(wǎng)絡(luò)協(xié)議棧，由此產(chǎn)生內(nèi)核上下文頻繁切換和報文拷貝問題，占用了CPU周期，消耗了處理時間。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)行性能提升研究和測試驗證工作。
3、運(yùn)營商如何推動三層解耦落地?
在NFV方面，解耦是首當(dāng)其沖的問題，目前業(yè)界有不解耦、軟硬件解耦和三層解耦這3種思路，其中軟硬件解耦又分為共享虛擬資源池和硬件獨立兩種方案，不同方案的對比介紹在本文的NFV部署模式部分已有介紹，這里不再贅述。
不解耦無法實現(xiàn)硬件共享，運(yùn)營商依賴廠商，網(wǎng)絡(luò)開放能力弱，不支持自動化部署，顯然不符合NFV技術(shù)的初衷;而僅硬件解耦不支持多廠商VNF在同一云平臺部署，運(yùn)營商仍舊依賴廠商;三層解耦可以解決上述問題，但其涉及多廠商垂直互通，系統(tǒng)集成和維護(hù)難度大，部署周期長。NFV三層解耦要求在部署NFV時不同組件由不同的廠商提供，需要比傳統(tǒng)電信網(wǎng)絡(luò)更復(fù)雜的測試驗證、集成和規(guī)劃部署工作。
NFV分層解耦的方式由于缺乏主集成商(蘇研努力的目標(biāo)，陜西目前試點的主要目的)和完整驗證，距離開放的全解耦目標(biāo)還有相當(dāng)距離，運(yùn)營商會面臨一定的運(yùn)維風(fēng)險和技術(shù)挑戰(zhàn)。NFV分層解耦的技術(shù)挑戰(zhàn)主要有以下幾點：
(1)不同廠商的硬件設(shè)備之間存在管理和配置的差異，如存儲設(shè)備管理配置、安全證書、驅(qū)動、硬件配置等方面的問題，會導(dǎo)致統(tǒng)一資源管理困難、自動化配置失效;另一方面，各類VNF和虛擬化軟件部署于不同的硬件設(shè)備上，在缺乏預(yù)先測試驗證的情況下，硬件板卡或外設(shè)之間，如PCIe網(wǎng)卡、RAID卡硬件、BIOS，存在兼容性不一致問題。因此，NFV三層解耦規(guī)模商用前，需要運(yùn)營商細(xì)化服務(wù)器安全證書、硬件選型方面的規(guī)范要求，重點關(guān)注硬件可靠性和兼容性問題，在商用前進(jìn)行軟硬件兼容性和可靠性驗證。以上問題需要通過大量的適配、驗證和調(diào)優(yōu)來解決。
(2)不同基礎(chǔ)軟件之間存在兼容性問題，如操作系統(tǒng)與驅(qū)動層之間、虛擬交換機(jī)與操作系統(tǒng)之間、虛擬化軟件與VNF之間，不同的模塊和不同的版本，以及不同的配置參數(shù)、優(yōu)化方法，都會造成性能、穩(wěn)定性、兼容性的較大差異，有待進(jìn)一步測試與驗證。為此，需要盡量減少虛擬化層類型，適時引入自主研發(fā)虛擬化層軟件，減少持續(xù)不斷的三層解耦測試工作量。采用集中的云管平臺(統(tǒng)一VIM)，降低NFVO與VIM集成的復(fù)雜度。
(3)分層之后，從NFV各層之間的接口定義與數(shù)據(jù)類型，到層內(nèi)功能的實現(xiàn)機(jī)制，乃至層間的協(xié)同處理均需要運(yùn)營商去推動和完善。如VNF在發(fā)生故障時，涉及VM遷移與業(yè)務(wù)倒換機(jī)制以及NFVI、NFVO和VIM的處理流程;又如VNF對配置文件管理和存儲設(shè)備使用不當(dāng)，同樣會導(dǎo)致VM實例化失效。因而，在VNF多廠家集成過程中，集成方或者運(yùn)營商需要需要有角色對問題定界、定位進(jìn)行裁決，在集成和運(yùn)維的過程中，對技術(shù)問題進(jìn)行端到端的管理，對各層的功能進(jìn)行詳細(xì)定義或者詳細(xì)規(guī)范。
(4)NFV系統(tǒng)集成涉及多廠商、多軟硬組件的高度集成，由于虛擬化環(huán)境的存在，在初期的測試驗證、中期的系統(tǒng)部署、后期的運(yùn)維過程中，進(jìn)行系統(tǒng)評測與管理部署都較為困難。這就要求運(yùn)營商在提升DevOps能力的基礎(chǔ)上，依托持續(xù)集成與持續(xù)部署和運(yùn)維自動化技術(shù)，形成NFV系統(tǒng)的持續(xù)集成、測試和部署能力，大白話就是要求運(yùn)營商亟待需要提升自主開發(fā)、自主集成和自主測試能力。同時，MANO架構(gòu)需要全網(wǎng)統(tǒng)一。由于目前VNFM通常與VNF是綁定的廠商組件，而實際上真正的VIM也是廠商提供的，因此VNFM、VIM仍然是與VNF、NFVI就近部署。所以需要盡早明確NFVO的架構(gòu)(例如，采用集團(tuán)NFVO+區(qū)域NFVO兩層架構(gòu))，明確VNFM和VIM的跨專業(yè)、跨地域部署能力和部署位置，明確已部署的云管平臺與VIM架構(gòu)的關(guān)系，以及已有的EMS、NMS與VNFM架構(gòu)的關(guān)系。
對于運(yùn)營商來說，三層解耦會是一個較長的過程，與廠商的博弈也需要時間，再加上自主能力(研發(fā)、測試、集成)也需要時間，在實現(xiàn)最終目標(biāo)之前可以先選擇過渡方案，例如廠商一體化方案(不適合作為商業(yè)化規(guī)模部署方案)、部分解耦方案(硬件與軟件解耦、MANO中的NFVO解耦出來)等，在試點和小規(guī)模部署過程中培育能力，逐漸實現(xiàn)最終的解耦目標(biāo)，并在解耦基礎(chǔ)上逐步提升自主研發(fā)比例，增強(qiáng)對網(wǎng)絡(luò)NFV化的掌控力。
4、MANO管理模式利弊分析
EISI NFV對MANO的資源管理提出直接模式和間接模式兩種方案。NFV-MANO允許NFVO和VNFM兩者都能管理VNF生命周期所需的虛擬化資源，直接和間接是相對VNFM而言的。
直接(Direct)模式：VNFM直接通過VIM分配VNF生命周期管理所需的虛擬化資源。VNFM向NFVO提出對VNF的生命周期管理操作進(jìn)行資源授權(quán)，NFVO根據(jù)操作請求及整體資源情況返回授權(quán)結(jié)果;VNFM根據(jù)授權(quán)結(jié)果直接與VIM交互完成資源的調(diào)度(分配、修改、釋放等);VNFM向NFVO反饋資源變更情況。如下圖所示：
間接(Indirect)模式：VNFM向NFVO提出對VNF的生命周期管理操作進(jìn)行資源授權(quán)，NFVO根據(jù)操作請求及整體資源情況返回授權(quán)結(jié)果;VNFM根據(jù)授權(quán)結(jié)果向NFVO提出資源調(diào)度(分配、修改、釋放等)請求，NFVO與VIM交互完成實際的資源調(diào)度工作;NFVO向VNFM反饋資源變更情況。如下圖所示：
總體而言，兩者都由VNFM提供VNF生命周期管理。在執(zhí)行VNF生命周期管理操作之前，無論該操作新增資源，還是修改或者釋放已分配的資源，VNFM都需要向NFVO請求資源授權(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ù)雜度以及安全性方面的對比分析如下所示：
綜合以上分析，從功能、落地部署、安全性、未來演進(jìn)角度考慮，間接模式較好;性能方面，直接模式占優(yōu);系統(tǒng)集成復(fù)雜度兩者相當(dāng)?？紤]網(wǎng)絡(luò)的未來發(fā)展，從運(yùn)營商對網(wǎng)絡(luò)的自主掌控能力出發(fā)，要求廠商必須支持間接模式，以推進(jìn)分層解耦、實現(xiàn)對虛擬資源的統(tǒng)一管控。
5、VNFM如何選型?
通用VNFM和專用VNFM是ETSI定義的兩種架構(gòu)選項。
通用VNFM：通用VNFM可以服務(wù)于不同類型或不同廠商提供的VNF，對它所管理的多種類型、多廠商VNF的操作沒有依賴性，但它必須能夠在VNF包中定義的不同VNF的特定腳本。按照管理要求，可能有多個通用VNFM，每個VNFM管理一定VNF的子集。在這種情況下，NFVO需要同時處理多個通用VNFM。下圖展示了通用VNFM的架構(gòu)。
專用VNFM：專用VNFM與它所管理的VNF之間具有依賴性，一般管理由同一廠商提供的VNF。NFV架構(gòu)框架同時也允許一個或多個專用VNFM連接到單個NFVO。在VNF生命周期管理過程復(fù)雜，且一些管理特性與這些VNF緊耦合的場景下，就需要使用專用VNFM。下圖展示了專用VNFM的架構(gòu)。
兩種架構(gòu)選項具有相同的VNFM功能要求，如VNFD解析，獲得部署VNF所需資源要求及所需部署的業(yè)務(wù)軟件;NFVI告警與VNF告警關(guān)聯(lián)、VNF彈性策略執(zhí)行;VNF生命周期管理，包括實例化、查詢、擴(kuò)/縮容、終止等。但是，兩種架構(gòu)在技術(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的一個功能實體，在部署時，可以有如下兩種部署形態(tài)。
6.1 NFVO功能不分解部署
NFVO作為一個獨立的實體部署，可采用級聯(lián)的方式來部署。如下圖所示，每個管理域可以被當(dāng)作一個或多個數(shù)據(jù)中心，在該管理域中部署一套獨立的NFVO，以及VNFMs、VIMs，用來管理該域中的網(wǎng)絡(luò)服務(wù)。另外，再部署一套頂層NFVO，用來管理域間的網(wǎng)絡(luò)服務(wù)，它并不管理下層管理域中的網(wǎng)絡(luò)服務(wù)，不過它可以接收下層管理域中網(wǎng)絡(luò)服務(wù)實例化、彈性伸縮，以及終止操作的請求，并將此請求直接傳遞給下層管理域中的NFVO，由下層管理域的NFVO來完成實際的操作。
6.2 NFVO功能分解部署
NFVO可以分為兩個獨立的實體來部署，NSO主要完成NS的生命周期管理，包括NS模板以及VNF包的管理，如下圖所示。NSO不再關(guān)注資源的狀態(tài)以及資源所在的管理域，僅關(guān)注資源的額度。RO主要完成管理域內(nèi)資源的管理和編排，如資源的預(yù)留、分配、刪除等操作，以及支持資源的使用率和狀態(tài)的監(jiān)控。
NFVO功能不分解部署時，資源申請效率高;集成難度相對較低;若NFVO故障，則只會影響該NFVO管理域的業(yè)務(wù)和資源。NFVO分解后，VNFM訪問或申請資源的效率會降低;如果RO出現(xiàn)故障，則只會影響該RO管理的資源;但是，一旦NSO出現(xiàn)故障，則將影響所有整個NFV的業(yè)務(wù)功能;NFVO分解為NSO、RO之后，或增加NSO-RO之間的接口，增加系統(tǒng)集成難度。
根據(jù)分析比較，在一定的業(yè)務(wù)規(guī)模下，將NFVO分解為NSO、RO難以帶來明顯的優(yōu)勢或收益，反而會導(dǎo)致性能降低、集成復(fù)雜。因此，建議NFVO采用不分解架構(gòu)。另外，考慮后續(xù)的演進(jìn)和發(fā)展，在技術(shù)架構(gòu)上可將NSO和RO進(jìn)行內(nèi)部功能解耦，并實現(xiàn)微服務(wù)化，以增強(qiáng)未來NFVO部署的靈活性。
【本文為專欄作者“移動Labs”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】
網(wǎng)站題目：NFV網(wǎng)絡(luò)云落地過程中若干問題分析
當(dāng)前網(wǎng)址：http://fisionsoft.com.cn/article/cdjjhjd.html
