摘要
- OpenStack 為NFV的實(shí)施提供幫助，但其并非為電信應用而設計
- NFV在5個(gè)特定方面需要提升，以應對在電信行業(yè)的部署
- 一個(gè)開(kāi)源、多廠(chǎng)商的NFV平臺是促成這一目標的關(guān)鍵
對于電信網(wǎng)絡(luò )功能虛擬化(NFV)架構而言， OpenStack并不是一個(gè)固守現狀的方案。OpenStack是一個(gè)開(kāi)源的云管理技術(shù)，可提供任何NFV環(huán)境中所需的很多能力。這已在許多電信運營(yíng)商中激起了極大興趣。
但要實(shí)現NFV的所有優(yōu)勢，運營(yíng)商需要一個(gè)NFV平臺，能夠提供額外的能力以支持分布式的云、增強的網(wǎng)絡(luò )控制、生命周期管理和高性能的數據平面。
OpenStack/NFV回顧
2010年，RackSpace 和NASA聯(lián)合發(fā)布了OpenStack ，這是一個(gè)開(kāi)源的云計算平臺。從那時(shí)開(kāi)始，OpenStack社區得到了極大的發(fā)展勢頭，超過(guò)200家公司加入進(jìn)來(lái)。
最初，OpenStack本身并非按照運營(yíng)商需求想法而設計。所以，在2012年，一些主要的電信運營(yíng)商發(fā)起了旨在將虛擬化和云的理念應用于電信領(lǐng)域的活動(dòng)。
網(wǎng)絡(luò )功能虛擬化這一術(shù)語(yǔ)正是因此而產(chǎn)生。運營(yíng)商要求廠(chǎng)商創(chuàng )建虛擬化的網(wǎng)絡(luò )功能(VNFs)和NFV平臺，以幫助他們在部署業(yè)務(wù)時(shí)更加靈活便利，并降低設備和運維成本。
為彌補OpenStack和其他相關(guān)開(kāi)源項目的不足，業(yè)界主要的相關(guān)方在2014年9月以L(fǎng)inux 基金會(huì )合作項目的形式創(chuàng )建了“NFV開(kāi)源平臺”。其目的是為NFV創(chuàng )建一個(gè)運營(yíng)商級的開(kāi)源的參照平臺。業(yè)界各方將共同創(chuàng )建這一平臺以推動(dòng)NFV的演進(jìn)并保證一致性、性能以及多個(gè)開(kāi)源組件間的互通性。
目前，針對電信NFV環(huán)境，OpenStack在下述5個(gè)方面是有所欠缺的：
- 分布式
- 網(wǎng)絡(luò )連接
- 自動(dòng)化的生命周期管理
- NFV架構運營(yíng)
- 高性能數據平面
1.分布式
在IT的世界里，企業(yè)試圖將其數據中心聚合起來(lái)以降低成本。但對于NFV而言，這并非總是最佳選擇。很多NFV應用要求低時(shí)延的實(shí)時(shí)響應。NFV應用也需要高可用性和災難生存能力。運營(yíng)商需要靈活性以便將網(wǎng)絡(luò )功能部署在一個(gè)分布式的架構上— 無(wú)論是網(wǎng)絡(luò )核心、城域邊緣、接入甚至可能是客戶(hù)側。
分布式的NFV架構
OpenStack支持Cell，Region和Availabilities Zone，但這些概念對于NFV需求還不夠。每個(gè)OpenStack的Region提供相互隔離的API端點(diǎn)，各Region間沒(méi)有協(xié)調。典型情況下，一個(gè)數據中心中可能有一個(gè)或多個(gè)Region。Cell組件可提供一個(gè)單一的API端點(diǎn)用于匯聚多個(gè)Region。
利用Cell，跨Cell的負載分配(“調度”)通過(guò)明確的指定或隨機選擇而生成。Cell組件沒(méi)有分配機制來(lái)基于應用需求選擇最佳的位置。
Horizon GUI每次都被限定在單個(gè)區域內。沒(méi)有GUI能夠顯示NFV云架構的聚合視圖。OpenStack Glance虛機鏡像管理器也被限定在單個(gè)區域。這意味著(zhù)NFV運營(yíng)商不得不根據區域的需求手動(dòng)進(jìn)行鏡像的部署。
關(guān)鍵點(diǎn)：運營(yíng)商需要一個(gè)能夠有效應對NFV架構的平臺，該架構可提供低信號時(shí)延和災難生存能力。該架構還必須能夠作為一個(gè)單一的分布式的云被管理，提供全局視圖、統計和策略。
2.網(wǎng)絡(luò )連接
VNF根據其網(wǎng)絡(luò )需求而千變萬(wàn)化。由于它們是部署在整個(gè)NFV架構上的，NFV網(wǎng)絡(luò )的基本需求就是連接，包括數據中心內部的和跨廣域網(wǎng)的。基于安全性考慮，要求不同的網(wǎng)絡(luò )功能僅在需要交換數據時(shí)才彼此相連，而NFV控制、數據和管理流量應當相互隔離。
由于網(wǎng)絡(luò )功能被分解到諸如數據平面組件和一個(gè)集中化的控制平面組件中，這些組件間的連接需要保持與傳統的集成式架構同樣的高可靠性，需要有足夠的網(wǎng)絡(luò )資源以保證來(lái)自其它應用的突發(fā)流量不會(huì )對NFV應用造成影響。
網(wǎng)絡(luò )應當具備相應的彈性對抗設備故障和不可抗災難。時(shí)延和抖動(dòng)會(huì )有較多變化，從某些控制和管理系統的數百毫秒，到移動(dòng)網(wǎng)關(guān)和云化RAN的幾個(gè)毫秒。
NFV網(wǎng)絡(luò )通常包含一個(gè)半靜態(tài)的物理層架構，還有一個(gè)更加動(dòng)態(tài)的overlay網(wǎng)絡(luò )層以滿(mǎn)足VNF的需要。Overlay層需要對某些需求做出快速響應，例如業(yè)務(wù)需求變更和新業(yè)務(wù)部署。
OpenStack Neutron是OpenStack的網(wǎng)絡(luò )組件，提供抽象化能力，例如L2和L3的網(wǎng)絡(luò )，子網(wǎng)、IP地址和虛擬化的中間設備。Neutron具備一個(gè)基于插件的架構。連接請求發(fā)送給Neutron后，被轉發(fā)到Neutron中安裝的插件，這些插件用于對當前網(wǎng)絡(luò )的細節進(jìn)行處理。Neutron被限制在一個(gè)單一的網(wǎng)絡(luò )資源空間內，這些資源通常與一個(gè)OpenStack region相關(guān)聯(lián)。無(wú)法直接對多個(gè)網(wǎng)絡(luò )域進(jìn)行跨接，并管理WAN的能力。
關(guān)鍵點(diǎn)：運營(yíng)商需要一個(gè)平臺來(lái)建立和管理局域網(wǎng)和廣域網(wǎng)(LAN and WAN)架構，以可編程模式創(chuàng )建的運營(yíng)商應用需要這一架構。
3.自動(dòng)化的生命周期管理
作為一個(gè)基于軟件的方案，NFV一個(gè)最大的優(yōu)勢就是其實(shí)現運維流程自動(dòng)化的能力。包括應用的整個(gè)生命周期，從部署到監控、伸縮、故障恢復和升級，直到退出。研究表明，這種自動(dòng)化能力將使得運營(yíng)商在某些情況下能縮減超過(guò)50%的運維成本(OPEX)。
OpenStack Heat允許用戶(hù)創(chuàng )建模板，以組件資源的語(yǔ)言來(lái)描述虛擬應用（“stacks”)，例如包含嵌入式stack的虛機。早期，Heat模板基于A(yíng)WS CloudFormation ，但最近，Heat編排模板(HOT)的引入，提供了額外的表達呈現能力。Heat聚焦于定義和部署應用stack，但對生命周期的其他階段，并無(wú)特別支持。
OpenStack Solum是一個(gè)新項目，被設計用于使云業(yè)務(wù)更易被購買(mǎi)使用以及集成在開(kāi)發(fā)流程中。它被設計用來(lái)提供某些缺失的生命周期自動(dòng)化功能。通過(guò)將OpenStack Ceilometer的評估能力與Heat相結合，在自動(dòng)伸縮方面已經(jīng)開(kāi)展了一些早期的工作。Heat 目前受限于單一的OpenStack領(lǐng)域。
關(guān)鍵點(diǎn)：運營(yíng)商需要一個(gè)平臺，不僅能夠對部署和伸縮實(shí)現自動(dòng)化，還要對復雜的運營(yíng)商應用中的很多其它生命周期運維工作實(shí)現自動(dòng)化，并附帶許多組件功能。
4.NFV架構運維
NFV架構的分布性，跨越運營(yíng)商網(wǎng)絡(luò )上的許多位置 – 而不是少數集中的位置 – 這就帶來(lái)一些特有的挑戰，并將影響運維流程和支撐系統。相較于一個(gè)集中化的云，NFV的分布式架構意味著(zhù)，不同位置的云節點(diǎn)的添加、升級、和/或移除將更為頻繁。這些過(guò)程將盡可能的在遠端進(jìn)行，避免跨區的現場(chǎng)支持。
OpenStack TripleO (OpenStack on OpenStack) 是一個(gè)對OpenStack家族實(shí)驗性的新增功能。該項目旨在使用OpenStack自有的云工具實(shí)現OpenStack云的安裝、升級和運維的自動(dòng)化。TripleO使用Heat在裸機架構上部署OpenStack實(shí)例。
關(guān)鍵點(diǎn)：運營(yíng)商需要一個(gè)針對分布式NFV架構而特別設計的平臺，該平臺可對復雜的軟件stack部署和升級流程實(shí)現自動(dòng)化。
5.高性能數據平面
很多運營(yíng)商網(wǎng)絡(luò )的功能（比如深度包檢測、媒體網(wǎng)關(guān)、會(huì )話(huà)邊界控制器和移動(dòng)核心服務(wù)網(wǎng)關(guān)以及分組數據網(wǎng)絡(luò )網(wǎng)關(guān)）目前是基于定制化硬件實(shí)現的，為的是獲得更高的處理能力和輸入輸出吞吐量。在商業(yè)服務(wù)器上以hypervisor運行這些功能會(huì )導致10倍 的性能下降。
業(yè)界目前正在對新技術(shù)加以研究，這些新技術(shù)有望提升商業(yè)服務(wù)器上的數據平面性能，某些情況下甚至接近定制化硬件的水平。
然而，數據平面性能在OpenStacks社區一直是個(gè)邊緣化的領(lǐng)域。直到最近，隨著(zhù)Juno版本的發(fā)布，更多的人開(kāi)始關(guān)注數據平面的加速問(wèn)題。Juno為虛機調用英特爾的Single Root I/O虛擬化技術(shù)提供支持。
關(guān)鍵點(diǎn)：運營(yíng)商需要一個(gè)平臺，用于管理商業(yè)服務(wù)器上的高性能數據平面網(wǎng)絡(luò )功能。
OpenStack再進(jìn)一步：現在部署NFV還需要什么？
全球大多數的運營(yíng)商都在尋找一個(gè)基于OpenStack的開(kāi)放、多廠(chǎng)商的NFV平臺。但正如我們所提到的，OpenStack社區在某些關(guān)鍵NFV需求上沒(méi)有給予足夠的關(guān)注。所缺失的是一個(gè)NFV平臺，該平臺要超越OpenStack的范疇，以幫助客戶(hù)實(shí)現CAPEX和OPEX的削減以及提升業(yè)務(wù)靈活性的目標。
OpenStack在某些方面仍然處于密集開(kāi)發(fā)的狀態(tài)。一旦其成熟，OpenStack的功能將更為穩定和豐富，使其更好的滿(mǎn)足某些領(lǐng)域的NFV需求。然而，它不可能滿(mǎn)足所有需求。
運營(yíng)商需要一個(gè)水平化的NFV平臺來(lái)提供：
- 用于VNF的計算、存儲和網(wǎng)絡(luò )資源
- 一個(gè)用于NFV編排(NFVO)的集中化平臺
- 一個(gè)用于管理VNF生命周期的集中化VNF管理器（VNFM）
- 這一方式使得消除今天多應用形成的豎井式結構成為可能。
本文基于阿爾卡特朗訊/紅帽白皮書(shū) 以具備OpenStack特性的CloudBand作為NFV平臺。
