NFCloud：基于OpenContrail的NFV實踐

溫曙光 賀 鵬 姜海洋 關洪濤 謝高崗

網絡功能虛擬化(Network Function Virtualization,NFV)[1]是歐洲電信標準組織ETSI在2012年提出的一項愿景，借助云計算、虛擬化和SDN技術把電信設備從目前的專用平臺遷移到通用的X86平臺上來，幫助運營商和數據中心更加敏捷地為客戶創建和部署網絡特性，降低設備投資和運營費用。

NFV是從電信領域提出來的概念，“網絡功能”在NFV白皮書中主要是指電信網絡的功能模塊(Network Function，NF)，比如IP Multimedia Subsystem(IMS)、Evolved Packet Core(EPC)。隨著技術的發展與相互融合，NFV的概念已經突破了原始的定義從電信網絡進入數通網絡領域[2]，研究機構和相關的公司開始探索利用NFV的方法和工具將數據網絡中的面向連接的網絡功能服務化，常見的網絡功能有：防火墻、網絡地址轉換NAT、因特網入侵防護監測和保護IDS/IPS、緩存Cache、深度數據包檢測DPI、廣域網加速、Web防火墻WAF、漏洞掃描等。

OpenContrail[3]正是Juniper瞄準這一市場機會推出的開源解決方案，為云計算平臺提供網絡虛擬化(Network Virtualization, NV)和網絡功能虛擬化的能力。它采用Openstack[4]作為云資源管理平臺，具有良好的可擴展性。本文介紹的NFCloud是我們基于OpenContrail構建的用于數據通訊領域的NFV系統，具有敏捷靈活、融合、高性能和高可用的特點。

1 業務模型

OpenContrail的NFV業務模型如圖1所示。租戶的業務運行在虛擬機A1～A6中，這些虛擬機連接到租戶網絡A/A1/A2上，租戶網絡是在基礎網絡(物理網絡)上利用overlay技術構建的虛擬網絡(Virtual Net, VNet)。OpenContrail的NFV功能允許在租戶的兩個VNet間(如圖1上部所示)或者VNet和Internet間(如圖1下部所示)增加以下兩種形式的功能：1)一組服務實例串接形成一條服務鏈(如圖1下部的FW和LB業務)，這兩個網絡間的流量會依次經過整條服務鏈上的每一個虛擬的網絡功能(Virtual Network Function, vNF)服務實例，每個vNF都在兩個網絡間轉發流量；2)一個并聯的vNF服務實例(如圖1下部的IPS業務)，這兩個網絡間的流量會被鏡像到vNF，vNF可以對流量進行離線的深度數據包分析而無需轉發。整條服務鏈既可以做二層轉發也可以做三層轉發，依據實際部署和應用場景而定。

在OpenContrail的模型中，接入vNF的一端必須是租戶的虛擬網絡，這一要求將其提供NFV的能力限定于云平臺之上。NFCloud在調研之后提出來，NFV平臺應該滿足下列的需求。

1)將NFV的業務能力擴展到物理網絡中，也就是說，NFV平臺能為物理網絡加載vNF服務。

2)提供多租戶的環境，不同的用戶能運行不同的vNF服務，他們之間是相互隔離的。

3)vNF能以服務鏈的形式串聯或者并聯在租戶物理網絡出口。

4)vNF能以云主機的形式部署在網絡邊緣。跟服務鏈上的服務不同，云主機有可達的IP地址，用戶可以通過地址直接連接到云主機上。云主機的地址可以跟用戶在同一個網段，也可以在網管單獨分配的網段。

根據這樣的需求，NFCloud所支持的業務模型如圖2所示。圖2左邊是一般的園區網絡結構，上面的路由器與Internet相連提供出口服務，下面的核心交換機提供大容量的交換網絡，往下通過接入層接入不同的用戶，用戶間的流量一般是通過IP地址或者VLAN標簽區分。在出口路由器下，NFCloud部署透明網關(Transparent GateWay,TGW)，將用戶的物理網絡流量引入到各自訂購的虛擬服務鏈中來。如圖2所示，用戶1訂購了一組服務；而其他用戶尚未訂購服務。所有的用戶都可以隨時登陸NFCloud系統啟用或者停用訂閱的服務。服務分為兩種：服務鏈和云主機。服務鏈處理所有從該用戶與Internet之間的流量，云主機則是一臺用戶可以訪問的虛擬機。跟OpenContrail一樣，服務鏈里面又包括串聯服務和并聯服務。從用戶的視角出發，NFCloud在用戶的物理網絡出口提供了虛擬網關(Virtual Gateway, VG)的功能，在VG上，用戶可以根據自己的需求，加載不同的業務。在NFCloud平臺上，用戶可以租賃vNF服務，也可以稱為“租戶”，因此在本文的討論中，“用戶”和“租戶”的意義可以互換。

圖1 OpenContrail的NFV功能的業務模型

圖2 NFCloud的業務模型

NFCloud實現的4點需求，尤其是將NFV的業務能力擴展到物理網絡這一點，使得我們可以將NFV這一強大的工具用于改造傳統的物理網絡上。它的架構使得它適合于部署在網絡服務提供商出口，如園區網絡、數據中心網絡出口，或者運營商側的匯聚鏈路上，提供面向多租戶的虛擬網絡服務和近用戶側的云計算能力。

2 系統架構

圖3所示的是NFCloud的系統架構。整個架構采用微服務架構耦合，這是當前分布式系統開發的一種較為流行的架構。它將系統里面的各個組件劃分為多個獨立運行的服務，相互之間采用RESTful API請求、遠過程調用或者消息隊列的方式進行服務。每個服務完成的工作相對比較簡單，清晰。按照各個服務所部署的位置，在NFCloud系統中有三類節點：控制節點、計算節點和透明網關轉發設備。

圖3 NFCloud的系統架構

控制節點運行各個子系統的控制平面。NFCloud-web是用戶的入口，提供交互操作界面，它將用戶的網絡配置下發到透明網關控制平面TGW-control，從Openstack生成虛擬機組成服務鏈，服務鏈的配置下發到Opencontrail；Openstack和Opencontrail再通過其內部的機制管理計算節點。vNF-webproxy是vNF的管理平面提供的一個操作界面代理，允許用戶從NFCloud-web直接管理vNF應用。TGW-control通過BGP協議跟Opencontrail協商服務鏈的隧道信息，并將它們存放在ZooKeeper里通知到透明網關轉發設備TGW-forwarder。

計算節點是運行服務鏈和云主機虛擬機的服務器。計算節點由Openstack和Opencontrail管理，NFCloud在Openstack和Opencontrail上層開發的組件并不直接和計算節點交互。計算節點運行虛擬交換機(Virtual Switch，vSwitch)，負責為虛擬機構建VNet和服務鏈。計算節點之間的網絡互連由高速的光纖(10G/40G)互連，這個高速互連網絡稱為Fabric網絡。

透明網關轉發設備T G W-forwarder則是將用戶的物理網絡與vNF聯通的關鍵設備。它通過上下行鏈路串入到物理網絡中，通過Fabric網絡與計算節點相連。TGW-forwarder從Zookeeper中獲取TGW-control寫入的用戶配置和路由信息。TGW-forwarder將用戶的流量加上2層隧道頭送給服務鏈或者云主機中的vNF，把處理完的流量再送回到物理網絡中。

控制節點和計算節點都是標準的X86服務器；而TGW-forwarder作為網絡接入設備，既可以采用X86服務器，也可以采用眾核處理卡或者NP。在標準部署中，一套完整的NFCloud系統，包括一個主控制節點和一個備份控制節點，多個計算節點和一個透明網關轉發設備。

3 挑戰與解決方案

在通信通訊領域，服務提供商一直強調連接服務的高性能和高可靠性。而作為通信能力服務化的一種技術手段，NFV正是因為其在性能和可靠性方面達不到電信運營商的標準而成為其商業化的障礙[5-6]。在我們與客戶的接觸中發現，NFCloud提出的業務模型的接受度是非常高的，他們對OpenContrail底層能提供的性能和可靠性同樣表現了不滿意的態度。下面討論NFCloud在性能和可靠性方面所做的工作。

3.1 透明網關

從功能的角度來看，透明網關屬于傳統的數據平面設備，其處理邏輯如圖4所示：對流量按照上層定義的屬性進行分類，如果它屬于本設備的報文則進行協議棧處理；如果是送入vNF的數據包，按照用戶進行數據包分類，即屬于某個用戶服務鏈或者云主機則加上隧道頭從Fabric網絡送入NFCloud后端的云虛擬機里，其余的報文直接轉發；如果是vNF發送到物理網絡的數據包，則解封裝，提取出接口，恢復二層頭發送到上下行網絡中。

從部署的角度來看，透明網關串接到園區網絡、數據中心網絡出口或者運營商側匯聚鏈路上。前者的鏈路多以1G速率為主，在這種場景下，基于X86平臺DPDK[7]的純軟件的透明網關也可以滿足性能要求。而對于后兩種場景，目前的鏈路以10G/40G的光纖接入為主，即使只將少部分流量導入到NFCloud云中，由于所有的流量都需要經過透明網關進行用戶查找，因此，對透明網關的性能壓力是巨大的。為應付高速率鏈路對透明網關的性能需求，NFCloud在集成了眾核處理器+交換芯片的硬件平臺上開發了高性能透明網關，其結構如圖5所示。

在圖5中，TGW-forwarder的中心是交換芯片，對外提供上下行鏈路和Fabric接口，對內連接兩邊的眾核處理芯片，兩塊芯片分別處理上下行的流量。從網絡進來的流量經過交換芯片進行類型判斷和用戶查找：如果不需要額外處理的報文直接就轉發；如果需要進行上層協議處理和隧道處理的報文，交換芯片會插入相應的用戶信息送給CPU處理。這個結構把圖4中性能關鍵的部分放到了交換芯片，包類型判斷用交換芯片的ACL規則實現，用戶查找用TCAM實現。由于使用了交換芯片，提高了透明網關轉發平面的性能和可靠性。

圖4 透明網關轉發數據包處理流程

圖5 基于眾核處理器平臺的透明網關轉發平面

3.2 虛擬交換機

透明網關將服務鏈的流量通過Fabric網絡送到服務鏈或者云主機中的vNF進行處理。vNF是虛擬機中的應用程序，而計算節點上面運行虛擬交換機(Virtual Switch, VS)軟件處理Fabric接口和虛擬機的虛擬接口之間的報文交換。虛擬交換機由于其連接著物理接口和虛擬接口，其采用的技術直接決定了IO接口數據轉發的性能，因此，VS的性能優化尤其重要。

主流的VS架構，多采用基于內核的數據通路+vhost-net+virtio的方式進行虛擬交換[8]，其結構如圖6(a)所示。由于Linux內核中網絡協議棧的通用性，基于內核的數據通路的額外開銷較多，在1次IO中需要2次內存分配和釋放+1次數據包拷貝；另外，由于涉及到驅動、協議棧、iptables/ebtables等多層功能，處理也較復雜。基于內核的數據通路很難提供超過1Gb/s線速的性能。為追求更高的性能，VS都開始朝著用戶態交換的架構演進，以消除內核協議棧過重的額外開銷。用戶態交換把圖6(a)都遷移到了用戶態來如圖6(b)所示，變成了DPDK+vhost-user+virtio。相較原來的基于內核數據通路的方式而言，減少了1次內存分配和釋放，由于不需要考慮過多通用的功能，處理可以專注在虛擬交換上。在這種模式下，VS的性能可以提高到3Gb/s線速。

除了VS的架構外，降低VS處理的復雜性對性能也有較好的提升。原生的VS為全功能的處理設計了通用而復雜的流表規則和動作集。已有研究表明，通過算法的優化，比如Hypersplit[9]，流表cache可以對通用的流表匹配有較好的加速作用。而NFCloud將服務鏈IO的處理進行了大幅簡化，避免了復雜的流表規則和動作集，比一些通用的優化算法效果更好，能將性能再次提升10%左右。

圖6 基于內核態和用戶態通路的VS架構

3.3 服務實例

服務實例是運行在虛擬機里面的vNF，一般是基于DPDK開發的用戶態程序，對租戶的流量進行業務處理。從虛擬化的角度來提升虛擬機的性能，Openstack和KVM社區有很多共性的優化的方法，比如大頁面的使用，NUMA親和性的綁定，VCPU和物理CPU的綁定等，這些方法同樣適合于在NFV場景，因此我們都已經把這些優化技術引入到NFCloud系統中。從NFV的特性下手去提高服務實例的性能，NFCloud主要是從網絡流量的IO著手，對vNIC的virtio-net前后端驅動進行改造，使其能夠支持vNF對網絡流量進行并行化處理和批處理。

1)vNF應用對流量進行并行化處理。雖然多核處理器已經發布超過10年，但由于并行編程的難度，許多NF應用在利用多核處理器的能力上仍然表現不佳。根據我們之前已有的研究成果總結[10]，網絡流量并行編程模型主要有三種，即Run-To-Complete(RTC)模型、Software-Pipeline(SPL)模型以及由上面兩種模型共同衍生出來的混合模型，包括Supra-linear模型、Multi-Snort、Para-Snort等。混合模型的出發點是SPL模型中的每一個Pipeline的復雜度是不均等的，對于較復雜的Pipeline應該采用RTC再進行并行化。Para-Snort模型在NF應用中適合網絡流量處理特性因而性能較好，而且Para-Snort模型的編程復雜度較低開發容易。因此Para-Snort模型在新一代NF應用的開發中占據了主流的地位。

對于Para-Snort模型，在作者其它研究表明[11]，數據包捕獲+負載均衡越靠近底層，從用戶態→內核態→硬件越往下走，整個系統的可擴展性和性能就越好。在NFCloud中，數據包捕獲+負載均衡是實現在虛擬交換層+vNIC上，將virtio-net的前后端都改造為支持多隊列收發的并行結構，使得數據包從網卡進入系統就能夠被并行處理，減少后續處理的拷貝和同步開銷，極大地提高了vNF應用的性能。

2)vNF應用對流量進行批處理。我們建議vNF應用一次從網卡上收多個數據包進行處理；發送時則緩存多個數據包一次發送。從IO上來說，批處理可以減少系統開銷；從應用來說，批處理可以提高代碼和數據的熱度，提高Cache命中率。

3.4 可用性

由于數據通訊處于互聯網應用的基礎地位，高可用性是天然的業務要求。而云管理平臺在單個業務的可用性方面，主要是上層業務做負載均衡+冗余備份，在NFCloud控制平面也采用相同的方法(如圖3所示部署的備份控制節點)。而對于NFV工作的數據通訊層上的可用性，包括Openstack在內的云管理平臺都缺乏足夠的保護措施。NFCloud在這方面做了增強，從手段來說是冗余+監控+保護，從保護范圍來說是系統→服務鏈→單個vNF應用三級。

1)vNF應用監控和服務鏈狀態監控。前者是對vNF是否正常進行業務轉發進行監控，后者對某個租戶的整條業務鏈轉發進行監控。這兩種方式都是通過主動發送探測包并監控返回來的探測包來推測被監控對象的行為和狀態。這兩套機制都是借用802.1AG協議的Connectiv Fault Management(CFM)的狀態機。當監測應用或者服務鏈的的行為異常時，NFCloud會通知控制平面嘗試做修復工作，比如重啟虛擬機，暫時將流量跳過某一級或全部應用，或者跟ECMP聯動。

2)Equal Cost Multi Path(ECMP)冗余備份，利用負載均衡對vNF進行備份。ECMP是一種網絡層的負載均衡技術，如圖7所示，對于FW這個vNF運行了3個相同的虛擬機對流量進行處理。當NFCloud采用vNF應用監控和服務鏈狀態監控的方法監測到某一個FW虛擬機失效時，FW前一級的VS將會知道并跳過失效的FW虛擬機。它既提供良好的可擴展性，也提供冗余備份能力。

3)入口短路保護，采用光保護交換機對透明網關TGW和整套云平臺進行監控。其工作原理如圖8所示，光保護交換機放置在TGW-forwarder前，兩者之間有一條心跳線。在系統正常工作時，光保護交換機會將上下行間的流量送給TGW-forwarder；當系統不能正常工作時，比如光保護交換機掉電、兩者時間的光纖無信號或者沒有心跳時，光保護交換機直接將上下行的流量透傳，從而保護上下行間的鏈路。

圖7 ECMP對業務進行負載均衡

圖8 光保護交換機的工作原理

4 總結

NFV成為改造網絡的一個強大的工具，有許多網絡服務提供商正在計劃將它們的服務遷移到NFV平臺上去。本文總結了我們在Opencontrail上構建面向數據通訊NFV平臺——NFCloud時遇到的問題和解決方法。NFCloud的核心價值在于解決以下兩個問題：NFV應該怎樣提供業務能力和NFV平臺如何滿足服務提供商的技術要求。

NFV應該怎樣提供業務能力？我們在調研了好幾種商用和開源的NFV平臺后發現，vNF的主要運行模式包括Middlebox服務和主機服務[12]，我們將這兩種業務抽象為在出口的服務鏈和在邊緣的云主機。所有的NFV平臺都提供運行云主機這種能力。而對于服務鏈業務，對于加載網絡的Middlebox業務，這是特別合適的業務模式，但是，服務鏈業務在各種NFV平臺中的功能要么缺失，要么有較大的局限性(只能用于VNet之間)，要么使用較復雜。NFCloud將NFV平臺業務能力總結為4點需求：擴展到物理網絡、多租戶、提供服務鏈功能、提供云主機功能。這使得NFCloud適合部署在網絡出口，如園區網絡、數據中心網絡出口，或者運營商側的匯聚鏈路上，提供面向多租戶的虛擬網絡服務和近用戶側的云計算能力。

NFV平臺如何滿足服務提供商的技術要求？NFV底層使用云計算技術來運行vNF。這兩者在技術要求上并不一致：NFV在數據通路上提供虛擬服務，要求高性能和高可用性；而云計算正是允許犧牲部分性能來解決資源彈性使用的問題。在整個數據通路上我們采用了多種技術來提高性能：使用專用的眾核處理平臺來實現10G的透明網關轉發平面；采用用戶態交換并簡化規則處理來提高虛擬交換的性能；在virtio接口上提供并行化和批處理能力來提高vNF自身的性能。在可用性上，NFCloud采用監控+冗余+保護手段對系統→服務鏈→單個vNF應用三級的可用性進行加強。

參考文獻

[1]ETSI: Network Function Virtualization[EB/OL].[2016-01-02].http://www.etsi.org/technologies-clusters/technologies/nfv

[2]華一強,郭曉琳,楊艷松.NFV及其在IP網中應用的探討[J].郵電設計技術,2015(2):11-16

[3]Opencontrail: An open-source network virtualization platform for the cloud[EB/OL].[2016-01-02].http://www.opencontrail.org/

[4]Openstack: Open source software for creating private and public clouds[EB/OL].[2016-01-02].http://www.openstack.org/

[5] 李晨,段曉東,陳煒,等.SDN和NFV的思考和實踐[J].電信科學,2014(8):23-27

[6]史凡,解云鵬,胡曉娟,等.SDN/NFV技術對電信網絡架構的價值和引入要點分析[J].電信網技術,2015(4):1-4

[7]DPDK: a set of libraries and drivers for fast packet processing[EB/OL].[2016-01-03].http://www.dpdk.org/

[8]Rusty Russell.Virtio: towards a de-facto standard for virtual I/O devices[J].ACM SIGOPS Operating Systems Review,2008(5): 95-103

[9]賀鵬.高效包分類方法研究[D].北京:中國科學院大學,2015

[10]姜海洋.網絡入侵檢測系統并行化技術研究[D].北京:中國科學院大學,2015

[11]溫曙光,謝高崗.libpcap-MT:一種多線程的通用數據包捕獲庫[J].計算機研究與發展,2011(5):756-764

[12]薛淼,符剛.基于SDN/NFV的Service Chaining關鍵技術研究[J].郵電設計技術,2015(2):1-6