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