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