嚴(yán)立宇 祖立軍 葉家煒* 周雍愷 吳承榮
1(復(fù)旦大學(xué)計(jì)算機(jī)科學(xué)技術(shù)學(xué)院 上海 200433)2(網(wǎng)絡(luò)信息安全審計(jì)與監(jiān)控教育部工程研究中心 上海 200433)3(中國(guó)銀聯(lián)股份有限公司電子支付研究院 上海 201201)
?
云計(jì)算網(wǎng)絡(luò)中多租戶虛擬網(wǎng)絡(luò)隔離的分布式實(shí)現(xiàn)研究
嚴(yán)立宇1,2祖立軍3葉家煒1,2*周雍愷3吳承榮1,2
1(復(fù)旦大學(xué)計(jì)算機(jī)科學(xué)技術(shù)學(xué)院 上海 200433)2(網(wǎng)絡(luò)信息安全審計(jì)與監(jiān)控教育部工程研究中心 上海 200433)3(中國(guó)銀聯(lián)股份有限公司電子支付研究院 上海 201201)
近年來(lái),隨著網(wǎng)絡(luò)虛擬化技術(shù)的快速發(fā)展,云服務(wù)提供商可以將一套物理網(wǎng)絡(luò)抽象成多套相互獨(dú)立的虛擬網(wǎng)絡(luò)提供給租戶。在多租戶網(wǎng)絡(luò)環(huán)境中,需要保證租戶網(wǎng)絡(luò)的安全隔離,確保租戶數(shù)據(jù)不會(huì)遭到來(lái)自其他租戶以及外部網(wǎng)絡(luò)的非法訪問。相比傳統(tǒng)物理網(wǎng)絡(luò)的邊界,虛擬網(wǎng)絡(luò)的邊界定義更加模糊,需要更細(xì)粒度的網(wǎng)絡(luò)隔離;當(dāng)前以O(shè)penStack為代表的主流開源云平臺(tái)采用集中式部署網(wǎng)絡(luò)邊界節(jié)點(diǎn)的方式實(shí)現(xiàn)虛擬網(wǎng)絡(luò)的隔離,虛擬機(jī)流量大多集中到單一物理節(jié)點(diǎn)上,存在單點(diǎn)故障的隱患。提出分布式實(shí)現(xiàn)虛擬網(wǎng)絡(luò)隔離的方式,把原本集中的虛擬網(wǎng)絡(luò)邊界分布到各臺(tái)物理服務(wù)器,從而將原本集中于同一節(jié)點(diǎn)的網(wǎng)絡(luò)流量分?jǐn)偟礁魑锢矸?wù)器,降低單點(diǎn)故障造成損失的可能性。最后經(jīng)過實(shí)驗(yàn)證實(shí)了分布式部署的有效性,同時(shí)能夠降低虛擬機(jī)通信的網(wǎng)絡(luò)延遲。
多租戶虛擬網(wǎng)絡(luò)隔離 虛擬網(wǎng)絡(luò)邊界 虛擬路由器 分布式 單點(diǎn)故障
隨著虛擬化技術(shù)的快速發(fā)展,云計(jì)算在大型數(shù)據(jù)中心網(wǎng)絡(luò)中已經(jīng)得到大規(guī)模應(yīng)用,對(duì)網(wǎng)絡(luò)的性能要求和安全要求也越來(lái)越高。與服務(wù)器虛擬化類似,網(wǎng)絡(luò)虛擬化技術(shù)的發(fā)展使得云服務(wù)提供商能將物理網(wǎng)絡(luò)設(shè)備抽象成虛擬的網(wǎng)絡(luò)設(shè)備提供給租戶,并允許每個(gè)租戶創(chuàng)建自己的虛擬網(wǎng)絡(luò),結(jié)合租戶申請(qǐng)的虛擬機(jī)資源定義網(wǎng)絡(luò)拓?fù)?,?duì)虛擬網(wǎng)絡(luò)進(jìn)行管理[1]。
對(duì)云服務(wù)提供商而言,虛擬網(wǎng)絡(luò)的基本需求是:允許網(wǎng)絡(luò)中多租戶共存,即在同一套物理網(wǎng)絡(luò)環(huán)境中,支持創(chuàng)建多套具備獨(dú)立服務(wù)模型、拓?fù)浜虸P地址空間的租戶虛擬網(wǎng)絡(luò)[2]。而從租戶的角度來(lái)看,不僅要求能夠創(chuàng)建一套獨(dú)立的虛擬網(wǎng)絡(luò),在其中運(yùn)行業(yè)務(wù),而且要求確保租戶數(shù)據(jù)的隔離和安全性,保證數(shù)據(jù)不會(huì)遭到來(lái)自其他租戶以及外部網(wǎng)絡(luò)的非法訪問。
在傳統(tǒng)物理網(wǎng)絡(luò)環(huán)境中,不同網(wǎng)絡(luò)之間的隔離通常由部署在網(wǎng)絡(luò)邊界處的路由器和防火墻完成。同樣,虛擬網(wǎng)絡(luò)的隔離也應(yīng)當(dāng)在虛擬網(wǎng)絡(luò)的邊界處實(shí)現(xiàn)。但相比之下,虛擬網(wǎng)絡(luò)環(huán)境中的網(wǎng)絡(luò)邊界更加模糊,缺乏明確的定義,因此為租戶虛擬網(wǎng)絡(luò)提供路由及防火墻服務(wù)也更為復(fù)雜。同時(shí),租戶虛擬網(wǎng)絡(luò)到實(shí)際物理網(wǎng)絡(luò)拓?fù)涞挠成涫窍鄬?duì)分散的,同一租戶控制的虛擬機(jī)很可能分布在多臺(tái)物理服務(wù)器上,可見租戶虛擬網(wǎng)絡(luò)的邊界可以細(xì)化到各物理服務(wù)器的邊緣,需要更加細(xì)粒度的網(wǎng)絡(luò)隔離。
結(jié)合典型的虛擬網(wǎng)絡(luò)應(yīng)用場(chǎng)景來(lái)看,虛擬網(wǎng)絡(luò)中的邊界可分為以下幾類,如圖1所示:
(1) 不同租戶的虛擬網(wǎng)絡(luò)之間的邊界;
(2) 同一租戶虛擬網(wǎng)絡(luò)下,不同虛擬子網(wǎng)之間的邊界;
(3) 租戶虛擬網(wǎng)絡(luò)與外網(wǎng)之間的邊界。
圖1 虛擬網(wǎng)絡(luò)的邊界分類
在當(dāng)前主流的開源云平臺(tái)中,已經(jīng)有針對(duì)虛擬網(wǎng)絡(luò)安全隔離的解決方案,通過為租戶網(wǎng)絡(luò)創(chuàng)建虛擬路由及防火墻的方式實(shí)現(xiàn)虛擬網(wǎng)絡(luò)的安全隔離[3]。在現(xiàn)有架構(gòu)下,所有租戶的虛擬路由器及防火墻設(shè)備都位于同一物理節(jié)點(diǎn),涉及租戶網(wǎng)絡(luò)邊界的流量都被集中到該節(jié)點(diǎn)上進(jìn)行處理,存在引發(fā)單點(diǎn)故障的隱患,同時(shí)也增加了虛擬機(jī)通信的網(wǎng)絡(luò)延遲。
1.1 相關(guān)研究進(jìn)展
上文提到虛擬網(wǎng)絡(luò)的邊界更模糊,需要更細(xì)粒度的網(wǎng)絡(luò)安全隔離措施。學(xué)術(shù)界針對(duì)虛擬化環(huán)境下的安全隔離問題有不少研究,并結(jié)合網(wǎng)絡(luò)功能虛擬化(NFV)的概念,將虛擬防火墻一類的網(wǎng)絡(luò)設(shè)備定義為網(wǎng)絡(luò)中間件(MiddleBox)。文獻(xiàn)[4]提出NetVM平臺(tái),將防火墻、路由器一類的設(shè)備部署在虛擬化層,相比預(yù)先部署在專用硬件設(shè)備的方案更具靈活性;同時(shí),NetVM利用Intel的DPDK庫(kù)和零拷貝技術(shù),提升了虛擬化層的網(wǎng)絡(luò)速率和吞吐量,并實(shí)現(xiàn)網(wǎng)絡(luò)高性能。文獻(xiàn)[5]圍繞網(wǎng)絡(luò)功能虛擬化的概念,提出ClickOS虛擬化平臺(tái),在其中部署高性能的中間件平臺(tái),包括虛擬防火墻、NAT、負(fù)載均衡器等,優(yōu)化中間件的數(shù)據(jù)包處理,提供了一種通過軟件實(shí)現(xiàn)網(wǎng)絡(luò)中間件的方案。文獻(xiàn)[11]則重點(diǎn)關(guān)注虛擬網(wǎng)絡(luò)性能,提出Pulsar平臺(tái)來(lái)為租戶提供虛擬數(shù)據(jù)中心(VDC)的抽象模型,并保證虛擬網(wǎng)絡(luò)性能達(dá)到租戶的需求。
可見學(xué)術(shù)界多數(shù)研究的重點(diǎn)關(guān)注集成、管理和擴(kuò)展中間件部署的能力和虛擬化I/O問題,旨在提升數(shù)據(jù)包通過虛擬機(jī)與物理機(jī)之間的速率,提高中間件平臺(tái)的可用性。此外,CloudMB項(xiàng)目[6]關(guān)注虛擬網(wǎng)絡(luò)服務(wù)初始放置的優(yōu)化,期望在物理拓?fù)浜土鞣植伎芍那闆r下,通過啟發(fā)式算法計(jì)算出虛擬網(wǎng)絡(luò)服務(wù)部署的合理位置,避免可能導(dǎo)致性能瓶頸的機(jī)架間流量。文獻(xiàn)[2,10]都為多租戶提供獨(dú)立的IP地址空間,采用數(shù)據(jù)包封裝技術(shù)來(lái)區(qū)分并隔離不同租戶。
而在工業(yè)界,針對(duì)虛擬網(wǎng)絡(luò)層面的安全隔離問題,有不少解決方案試圖通過定義虛擬網(wǎng)絡(luò)的邊界,并在相應(yīng)邊界物理節(jié)點(diǎn)部署虛擬路由及防火墻的方式來(lái)實(shí)現(xiàn)隔離。云計(jì)算環(huán)境中提供的服務(wù)范圍越來(lái)越廣,防火墻即服務(wù)的概念也已產(chǎn)生,虛擬防火墻及路由器以服務(wù)的方式提供給租戶,租戶可以為自己的子網(wǎng)申請(qǐng)?zhí)摂M路由器及防火墻,并為虛擬網(wǎng)絡(luò)的防火墻添加策略和規(guī)則。
在安全隔離的部署架構(gòu)方面,以VMWare的NSX[7]為代表的商用虛擬網(wǎng)絡(luò)解決方案中已經(jīng)提出了分布式邏輯路由,以及分布式虛擬防火墻的概念。該方案采用位于物理網(wǎng)絡(luò)邊界的集中式節(jié)點(diǎn)處理南北向流量(租戶虛擬機(jī)與外部網(wǎng)絡(luò)的流量)、位于各物理服務(wù)器內(nèi)部的分布式虛擬路由/防火墻處理東西向流量(跨物理機(jī)的虛擬機(jī)之間的流量)。
而在主流開源云平臺(tái)(如OpenStack)[3]中仍然采取集中部署虛擬路由器及防火墻的方式,即專設(shè)一臺(tái)服務(wù)器(或?qū)S糜布W(wǎng)絡(luò)設(shè)備)作為網(wǎng)絡(luò)節(jié)點(diǎn),在該網(wǎng)絡(luò)節(jié)點(diǎn)上為每個(gè)租戶部署虛擬路由器,并配置虛擬防火墻作用在虛擬路由器上。這種部署方式的思路就是將虛擬網(wǎng)絡(luò)的邊界集中到統(tǒng)一的節(jié)點(diǎn),所有涉及租戶網(wǎng)絡(luò)邊界的流量都被集中到網(wǎng)絡(luò)節(jié)點(diǎn)上進(jìn)行處理。但這樣的實(shí)現(xiàn)方式容易引發(fā)單點(diǎn)故障,下一節(jié)將具體分析其中存在的問題。
1.2 集中式虛擬路由的問題
上文中圖1給出了虛擬網(wǎng)絡(luò)邊界的3種場(chǎng)景。OpenStack允許租戶分別創(chuàng)建各自的虛擬路由和虛擬防火墻,不同租戶的虛擬路由器之間默認(rèn)沒有關(guān)聯(lián),無(wú)法相互訪問,因此可以達(dá)到隔離多租戶虛擬網(wǎng)絡(luò)的目的,但在處理(2)、(3)兩類網(wǎng)絡(luò)邊界場(chǎng)景時(shí),存在不合理之處。
圖2是OpenStack實(shí)現(xiàn)虛擬網(wǎng)絡(luò)隔離的路由模式,其中網(wǎng)絡(luò)節(jié)點(diǎn)是OpenStack專設(shè)的實(shí)現(xiàn)虛擬網(wǎng)絡(luò)功能的物理服務(wù)器節(jié)點(diǎn),所有租戶的虛擬路由器均部署在網(wǎng)絡(luò)節(jié)點(diǎn)上,虛擬防火墻的規(guī)則作用在相應(yīng)虛擬路由器上,而計(jì)算節(jié)點(diǎn)則是部署了虛擬機(jī)管理程序(Hypervisor)及虛擬機(jī)資源的物理服務(wù)器。為便于說(shuō)明問題,假設(shè)租戶A創(chuàng)建了一套虛擬網(wǎng)絡(luò),配置了兩個(gè)子網(wǎng),子網(wǎng)下的虛擬機(jī)分布在不同計(jì)算節(jié)點(diǎn)上。
圖2 OpenStack虛擬網(wǎng)絡(luò)隔離的路由模式圖
在同租戶不同子網(wǎng)邊界方面:由于云計(jì)算的一大特點(diǎn)是東西向流量增大,業(yè)務(wù)運(yùn)行時(shí),跨物理機(jī)的虛擬機(jī)之間經(jīng)常進(jìn)行通信。在現(xiàn)有的網(wǎng)絡(luò)架構(gòu)下,跨子網(wǎng)的網(wǎng)絡(luò)通信流量都需要通過網(wǎng)絡(luò)節(jié)點(diǎn)上的虛擬路由器進(jìn)行轉(zhuǎn)發(fā)。圖2中深色箭頭對(duì)應(yīng)的路徑是租戶A不同子網(wǎng)下的虛擬機(jī)之間通信時(shí)的數(shù)據(jù)包路徑,其中位于子網(wǎng)1的虛擬機(jī)VM1與位于子網(wǎng)2的虛擬機(jī)VM2通信,數(shù)據(jù)包經(jīng)過位于網(wǎng)絡(luò)節(jié)點(diǎn)的虛擬路由器和虛擬防火墻。
在租戶與外網(wǎng)邊界方面:虛擬機(jī)與外部網(wǎng)絡(luò)之間的通信流量也需要經(jīng)過網(wǎng)絡(luò)節(jié)點(diǎn),通過網(wǎng)絡(luò)地址轉(zhuǎn)換(NAT)和防火墻規(guī)則的過濾,如圖2中淺色箭頭所示。租戶A的虛擬機(jī)數(shù)據(jù)包在通往外網(wǎng)的過程中經(jīng)過網(wǎng)絡(luò)節(jié)點(diǎn),通過部署在虛擬路由器上的NAT規(guī)則進(jìn)行IP地址轉(zhuǎn)換,獲取外網(wǎng)IP資源,同時(shí)也經(jīng)過部署在虛擬路由器上的虛擬防火墻規(guī)則進(jìn)行過濾,防止與外網(wǎng)間的非法通信。
因此,在多租戶的場(chǎng)景下,現(xiàn)有的虛擬網(wǎng)絡(luò)隔離實(shí)現(xiàn)模式會(huì)導(dǎo)致租戶虛擬機(jī)的大部分流量都經(jīng)過單一物理節(jié)點(diǎn),對(duì)網(wǎng)絡(luò)節(jié)點(diǎn)造成極大的負(fù)載壓力。如果采用集中式部署的虛擬網(wǎng)絡(luò)隔離架構(gòu),將網(wǎng)絡(luò)節(jié)點(diǎn)作為實(shí)現(xiàn)網(wǎng)絡(luò)功能和服務(wù)的單一節(jié)點(diǎn),很容易引發(fā)單點(diǎn)故障問題;同時(shí),由于租戶網(wǎng)絡(luò)隔離機(jī)制需要采用基于VXLAN的覆蓋網(wǎng)絡(luò)協(xié)議,對(duì)虛擬機(jī)網(wǎng)絡(luò)數(shù)據(jù)包進(jìn)行封裝(在第2節(jié)詳細(xì)介紹),虛擬機(jī)數(shù)據(jù)包在不同物理節(jié)點(diǎn)間的轉(zhuǎn)發(fā)都會(huì)經(jīng)過封裝與解封裝的過程。數(shù)據(jù)包統(tǒng)一經(jīng)過網(wǎng)絡(luò)節(jié)點(diǎn)處理,進(jìn)一步增加了通信的網(wǎng)絡(luò)延遲。因此現(xiàn)有的虛擬網(wǎng)絡(luò)隔離架構(gòu)存在引發(fā)單點(diǎn)故障的隱患以及網(wǎng)絡(luò)延遲的問題,不具有高可用性和可擴(kuò)展性。
虛擬網(wǎng)絡(luò)邊界相比傳統(tǒng)網(wǎng)絡(luò)而言更加模糊和復(fù)雜,需要更明確的網(wǎng)絡(luò)邊界節(jié)點(diǎn)定義以及更合理的網(wǎng)絡(luò)邊界隔離的解決方案。針對(duì)虛擬網(wǎng)絡(luò)的高可用性問題,文獻(xiàn)[2]采用的解決方案是關(guān)鍵組件集群式部署,即發(fā)生故障時(shí)可切換到集群中的備用設(shè)備,從而保證高可用。而本文則是從路由模式的角度出發(fā),針對(duì)開源云平臺(tái)中存在的問題,提出了一種分布式實(shí)現(xiàn)多租戶虛擬網(wǎng)絡(luò)隔離的解決方案。
2.1 總體架構(gòu)
與當(dāng)前主流云平臺(tái)(如OpenStack)的虛擬網(wǎng)絡(luò)隔離方式不同,本文提出了一種虛擬網(wǎng)絡(luò)安全隔離的分布式實(shí)現(xiàn)方式,將租戶虛擬路由器和防火墻分布到每個(gè)計(jì)算節(jié)點(diǎn)中??傮w思路是把原本集中到單一物理節(jié)點(diǎn)的虛擬網(wǎng)絡(luò)邊界分散到各臺(tái)物理服務(wù)器,從而將原本集中于同一節(jié)點(diǎn)的網(wǎng)絡(luò)流量分?jǐn)偟礁魑锢矸?wù)器,降低單點(diǎn)故障造成損失的可能性。即使在某個(gè)節(jié)點(diǎn)上出現(xiàn)故障,也只影響這臺(tái)服務(wù)器上的虛擬機(jī)通信,網(wǎng)絡(luò)中的其他虛擬機(jī)仍可以正常通信。
圖3的路由模式圖給出的是同一租戶的虛擬網(wǎng)絡(luò)(包括子網(wǎng)和分布式虛擬路由)。本文的方案在支持多租戶方面,允許每個(gè)租戶創(chuàng)建相互獨(dú)立的虛擬子網(wǎng)和虛擬路由器,即同一臺(tái)物理服務(wù)器上可能包含多個(gè)租戶創(chuàng)建的虛擬路由器和防火墻,利用Linux內(nèi)核的網(wǎng)絡(luò)命名空間技術(shù)解決可能存在的多租戶IP地址沖突問題。此外,圖中的內(nèi)部數(shù)據(jù)網(wǎng)包括計(jì)算節(jié)點(diǎn)間的物理網(wǎng)絡(luò)設(shè)備(交換機(jī)、路由器等)。
可以對(duì)比圖3分布式實(shí)現(xiàn)的路由模式與圖2中OpenStack集中式實(shí)現(xiàn)的路由模式。在通過分布式實(shí)現(xiàn)的模式中,虛擬機(jī)與外網(wǎng)之間的通信,直接通過其所在Hypervisor上的分布式虛擬路由器通向外網(wǎng);跨子網(wǎng)的虛擬機(jī)之間的通信,也直接通過分布式路由進(jìn)行處理。這兩類流量直接由計(jì)算節(jié)點(diǎn)上的分布式路由處理,無(wú)需通過統(tǒng)一的網(wǎng)絡(luò)邊界節(jié)點(diǎn)。
圖3 分布式實(shí)現(xiàn)虛擬網(wǎng)絡(luò)隔離的路由模式
圖4是本文分布式路由的物理架構(gòu)圖。本文采用的虛擬交換機(jī)為Open vSwitch,部署在所有物理服務(wù)器上,其中虛擬交換機(jī)br-int連接Hypervisor上的所有虛擬機(jī)。而虛擬交換機(jī)br-tun作為處理VXLAN協(xié)議的端點(diǎn)VTEP(VXLAN-Tunnel-EndPoint),對(duì)虛擬機(jī)出物理服務(wù)器的流量進(jìn)行VXLAN封裝,通過數(shù)據(jù)網(wǎng)網(wǎng)卡轉(zhuǎn)發(fā);對(duì)于接收到的VXLAN數(shù)據(jù)包,則進(jìn)行解封裝處理,轉(zhuǎn)發(fā)給連接虛擬機(jī)的br-int處理。此外,虛擬交換機(jī)br-ex的作用是連接外網(wǎng)網(wǎng)卡,能夠處理虛擬機(jī)與外網(wǎng)之間的通信。
圖4 分布式虛擬網(wǎng)絡(luò)隔離的物理架構(gòu)
虛擬路由器利用網(wǎng)絡(luò)命名空間技術(shù)配置,主要由子網(wǎng)網(wǎng)關(guān)端口構(gòu)成,這些子網(wǎng)網(wǎng)關(guān)端口可在虛擬交換機(jī)上配置對(duì)應(yīng)端口,起到連接虛擬交換機(jī)和虛擬路由器的作用。本文部署虛擬路由器的模式是:根據(jù)租戶虛擬機(jī)的分布,在所有包含該租戶虛擬機(jī)的物理機(jī)上為配置分布式虛擬路由器,這些分布式虛擬路由器包含租戶下所有子網(wǎng)的網(wǎng)關(guān)端口。
為便于說(shuō)明,設(shè)定以下場(chǎng)景:租戶A的虛擬網(wǎng)絡(luò)包含兩個(gè)子網(wǎng)(子網(wǎng)1和2),虛擬機(jī)分布在兩個(gè)計(jì)算節(jié)點(diǎn)上,圖4中VMx-y代表計(jì)算節(jié)點(diǎn)x上屬于子網(wǎng)y的虛擬機(jī),兩個(gè)計(jì)算節(jié)點(diǎn)各包含兩臺(tái)虛擬機(jī),分別屬于租戶A的子網(wǎng)1和子網(wǎng)2。兩個(gè)計(jì)算節(jié)點(diǎn)的分布式虛擬路由器上均配置了子網(wǎng)1和子網(wǎng)2的網(wǎng)關(guān)。
下一節(jié)將結(jié)合三類虛擬網(wǎng)絡(luò)邊界場(chǎng)景,具體描述分布式虛擬網(wǎng)絡(luò)隔離的部署模式,并分析對(duì)比分布式路由與集中式路由的路由模式。
2.2 虛擬網(wǎng)絡(luò)安全隔離分析
引言中已經(jīng)結(jié)合實(shí)際應(yīng)用場(chǎng)景,將虛擬網(wǎng)絡(luò)的邊界分為三類,圖1列舉了這三類網(wǎng)絡(luò)邊界。本文的分布式虛擬網(wǎng)絡(luò)隔離充分考慮了這三類虛擬網(wǎng)絡(luò)邊界,并有針對(duì)性地采用了相應(yīng)的網(wǎng)絡(luò)虛擬化技術(shù)。本節(jié)分別分析本文的分布式實(shí)現(xiàn)方案在這三類邊界場(chǎng)景下的實(shí)際流程和相關(guān)技術(shù)。
2.2.1 多租戶網(wǎng)絡(luò)之間的邊界
網(wǎng)絡(luò)虛擬化技術(shù)使得云服務(wù)提供商能夠?qū)⒁惶孜锢砭W(wǎng)絡(luò)虛擬化成多套虛擬網(wǎng)絡(luò),分別提供給不同的租戶。從租戶的角度考慮,一個(gè)重要的需求就是確保租戶網(wǎng)絡(luò)的安全隔離盒獨(dú)立性,防止自己的數(shù)據(jù)遭到來(lái)自其他租戶的非法訪問。
OpenStack現(xiàn)有的實(shí)現(xiàn)方式能夠很好地支持多租戶網(wǎng)絡(luò)安全隔離,因此本文在隔離多租戶虛擬網(wǎng)絡(luò)方面基本沿用了OpenStack的思路,并將集中式路由改為分布式。在實(shí)際部署上,將原先集中部署在網(wǎng)絡(luò)節(jié)點(diǎn)的租戶虛擬路由器和防火墻分布到租戶虛擬機(jī)所在的計(jì)算節(jié)點(diǎn)上,即所有包含租戶A的虛擬機(jī)的物理服務(wù)器上都部署屬于租戶A的虛擬路由器和虛擬防火墻。
同一計(jì)算節(jié)點(diǎn)上可能包含多位租戶所創(chuàng)建的虛擬路由器,連接各自的虛擬子網(wǎng)與外網(wǎng)。由于這些虛擬路由器之間默認(rèn)沒有關(guān)聯(lián),未配置相關(guān)聯(lián)的路由規(guī)則,因此租戶之間的虛擬網(wǎng)絡(luò)無(wú)法相互訪問通信,從而達(dá)到不同租戶虛擬網(wǎng)絡(luò)邊界安全隔離的目的。
此外,考慮到多租戶虛擬網(wǎng)絡(luò)中,不同租戶可能采用相同的內(nèi)部IP地址資源,從而引起系統(tǒng)中路由、NAT及防火墻規(guī)則配置的沖突,因此需要使用Linux的網(wǎng)絡(luò)命名空間技術(shù)。該技術(shù)允許在操作系統(tǒng)中定義多個(gè)虛擬空間,每個(gè)空間可相互獨(dú)立、透明地進(jìn)行網(wǎng)絡(luò)操作,從而能很好地支持多租戶虛擬網(wǎng)絡(luò)的需求。同一物理服務(wù)器中多租戶虛擬路由器的創(chuàng)建和管理配置正是基于網(wǎng)絡(luò)命名空間技術(shù)實(shí)現(xiàn)的。
2.2.2 同租戶不同子網(wǎng)之間的邊界
傳統(tǒng)網(wǎng)絡(luò)中常使用VLAN技術(shù)對(duì)網(wǎng)絡(luò)進(jìn)行邏輯上的劃分,但隨著數(shù)據(jù)中心網(wǎng)絡(luò)規(guī)模以及虛擬機(jī)數(shù)量的飛速增長(zhǎng),VLAN暴露出一些問題。近年來(lái),VXLAN[8]協(xié)議應(yīng)運(yùn)而生,能夠解決以下幾方面的問題:
? VLAN規(guī)模限制
當(dāng)前的VLAN協(xié)議中,使用12位數(shù)據(jù)作為VLAN標(biāo)簽,最多支持4094個(gè)子網(wǎng)。隨著數(shù)據(jù)中心規(guī)模的擴(kuò)大以及租戶虛擬網(wǎng)絡(luò)增多,這一數(shù)量不足以提供必要的傳播的獨(dú)立性。而在VXLAN中,引入了VNI(虛擬網(wǎng)絡(luò)標(biāo)識(shí)符)的概念,從12位擴(kuò)展到了24位,支持超過1600萬(wàn)個(gè)子網(wǎng)。
? 多租戶支持
數(shù)據(jù)中心托管多個(gè)租戶,而每個(gè)租戶需要流量隔離。這種隔離處于第二層,正如VLAN所提供的。在三層網(wǎng)絡(luò)的情況下,有可能有兩個(gè)租戶使用相同的三層尋址方案,需要以不同的方式提供隔離。VXLAN可以在現(xiàn)有的基礎(chǔ)設(shè)施上運(yùn)行,使用VNI封裝虛擬機(jī)的數(shù)據(jù)包,建立VXLAN隧道,區(qū)分不同的虛擬子網(wǎng)。
? 交換機(jī)的虛擬機(jī)數(shù)量
在大二層網(wǎng)絡(luò)環(huán)境下,數(shù)據(jù)流需要通過明確的網(wǎng)絡(luò)尋址以保證準(zhǔn)確到達(dá)目的地,因此網(wǎng)絡(luò)設(shè)備的MAC地址表項(xiàng)大小,成為決定云計(jì)算環(huán)境下虛擬機(jī)的規(guī)模的上限的因素,限制了整個(gè)云計(jì)算數(shù)據(jù)中心的虛擬機(jī)數(shù)量。而通過VXLAN將虛擬機(jī)數(shù)據(jù)封裝在UDP數(shù)據(jù)包中后,對(duì)網(wǎng)絡(luò)只表現(xiàn)為封裝后的網(wǎng)絡(luò)參數(shù),即VXLAN隧道端點(diǎn)(VTEP)的地址,因此,對(duì)于承載網(wǎng)絡(luò)(特別是接入交換機(jī))的MAC地址規(guī)格需求極大降低。
在本文方案中采用基于VXLAN協(xié)議的覆蓋網(wǎng)絡(luò)技術(shù),在不同計(jì)算節(jié)點(diǎn)之間建立VXLAN隧道,對(duì)虛擬機(jī)之間通信的數(shù)據(jù)包進(jìn)行封裝,并通過VNI劃分不同虛擬子網(wǎng)。
同租戶跨子網(wǎng)的虛擬機(jī)之間的通信,根據(jù)虛擬機(jī)的位置分布,可以細(xì)分為同一物理機(jī)和跨物理機(jī)兩種情況。在原有的集中式路由模式下,同一租戶下跨子網(wǎng)的虛擬機(jī)之間的通信都需要經(jīng)過網(wǎng)絡(luò)節(jié)點(diǎn)上的虛擬路由處理。即使兩臺(tái)在同一物理機(jī)上的虛擬機(jī)之間通信,由于不處于同一子網(wǎng),也沒有本地的路由關(guān)聯(lián),因此必須先發(fā)送到網(wǎng)絡(luò)節(jié)點(diǎn)。這樣的步驟是十分繁瑣的,不僅增加了通信中的網(wǎng)絡(luò)延遲,也帶來(lái)了引發(fā)單點(diǎn)故障的隱患。
通過圖5說(shuō)明本文的分布式路由如何處理同租戶跨子網(wǎng)的東西向流量。
圖5 跨子網(wǎng)虛擬機(jī)通信場(chǎng)景
這里以不同物理機(jī)上跨子網(wǎng)虛擬機(jī)通信為例,即圖5中VM1-1與VM2-2之間的通信。兩臺(tái)虛擬機(jī)分別屬于子網(wǎng)1和子網(wǎng)2。
在原先的集中式路由模式下,VM1-1發(fā)出的數(shù)據(jù)包在本地沒有匹配到路由規(guī)則,需要轉(zhuǎn)發(fā)到網(wǎng)絡(luò)節(jié)點(diǎn)上的虛擬路由進(jìn)行處理,具體步驟如下:
1) VM1-1發(fā)出數(shù)據(jù)包,目的地址為VM2-2;
2) 計(jì)算節(jié)點(diǎn)1的虛擬交換機(jī)br-int收到數(shù)據(jù)包,加上子網(wǎng)1的內(nèi)部VLAN標(biāo)簽后轉(zhuǎn)發(fā)到VTEP(br-tun);
3) 計(jì)算節(jié)點(diǎn)1的br-tun將內(nèi)部VLAN標(biāo)簽轉(zhuǎn)換為子網(wǎng)1對(duì)應(yīng)的VXLAN標(biāo)識(shí)VNI,并從數(shù)據(jù)網(wǎng)卡通過VXLAN隧道把數(shù)據(jù)包轉(zhuǎn)發(fā)到網(wǎng)絡(luò)節(jié)點(diǎn);
4) 網(wǎng)絡(luò)節(jié)點(diǎn)的VTEP(br-tun)對(duì)數(shù)據(jù)包進(jìn)行解封裝處理,將子網(wǎng)1的VXLAN標(biāo)識(shí)轉(zhuǎn)換為內(nèi)部VLAN標(biāo)簽,并轉(zhuǎn)發(fā)到虛擬交換機(jī)br-int;
5) 網(wǎng)絡(luò)節(jié)點(diǎn)的br-int把數(shù)據(jù)包交到虛擬路由處理,因?yàn)槟康牡刂穼儆谧泳W(wǎng)2,根據(jù)路由規(guī)則,數(shù)據(jù)包通過子網(wǎng)2網(wǎng)關(guān)端口轉(zhuǎn)發(fā),回到br-int;
6) 網(wǎng)絡(luò)節(jié)點(diǎn)的br-int把數(shù)據(jù)包加上子網(wǎng)2的內(nèi)部VLAN標(biāo)簽,轉(zhuǎn)發(fā)到br-tun;
7) 網(wǎng)絡(luò)節(jié)點(diǎn)的br-tun將內(nèi)部VLAN標(biāo)簽轉(zhuǎn)換為子網(wǎng)2對(duì)應(yīng)的VXLAN標(biāo)識(shí)VNI,并通過VXLAN隧道把數(shù)據(jù)包轉(zhuǎn)發(fā)到計(jì)算節(jié)點(diǎn)2;
8) 計(jì)算節(jié)點(diǎn)2的VTEP(br-tun)對(duì)數(shù)據(jù)包進(jìn)行解封裝處理,將子網(wǎng)2的VXLAN標(biāo)識(shí)轉(zhuǎn)換為內(nèi)部VLAN標(biāo)簽,并轉(zhuǎn)發(fā)到虛擬交換機(jī)br-int;
9) 計(jì)算節(jié)點(diǎn)2的br-int將數(shù)據(jù)包轉(zhuǎn)發(fā)到VM2-2對(duì)應(yīng)端口,VM2-2接收到數(shù)據(jù)包。
可見這是一個(gè)復(fù)雜的過程,而本文在建立分布式路由后,可將跨子網(wǎng)虛擬機(jī)通信簡(jiǎn)化為以下步驟(與圖5中的序號(hào)對(duì)應(yīng)):
1) VM1-1發(fā)出數(shù)據(jù)包,目的IP地址為VM2-2;
2) 計(jì)算節(jié)點(diǎn)1的虛擬交換機(jī)br-int收到數(shù)據(jù)包,把數(shù)據(jù)包交到分布式虛擬路由器處理,根據(jù)路由規(guī)則,將目的地址為VM2-2的數(shù)據(jù)包通過子網(wǎng)2網(wǎng)關(guān)端口轉(zhuǎn)發(fā),回到br-int;
3) 計(jì)算節(jié)點(diǎn)1的br-int把數(shù)據(jù)包加上子網(wǎng)2的內(nèi)部VLAN標(biāo)簽,轉(zhuǎn)發(fā)到VTEP(br-tun);
4) 計(jì)算節(jié)點(diǎn)1的br-tun將內(nèi)部VLAN標(biāo)簽轉(zhuǎn)換為子網(wǎng)2對(duì)應(yīng)的VXLAN標(biāo)識(shí)VNI,從數(shù)據(jù)網(wǎng)卡通過VXLAN隧道把數(shù)據(jù)包轉(zhuǎn)發(fā)到計(jì)算節(jié)點(diǎn)2;
5) 計(jì)算節(jié)點(diǎn)2的br-tun對(duì)數(shù)據(jù)包進(jìn)行解封裝處理,將子網(wǎng)2的VXLAN標(biāo)識(shí)轉(zhuǎn)換為內(nèi)部VLAN標(biāo)簽,并轉(zhuǎn)發(fā)到虛擬交換機(jī)br-int;
6) 計(jì)算節(jié)點(diǎn)2的br-int將數(shù)據(jù)包轉(zhuǎn)發(fā)到VM2-2對(duì)應(yīng)端口,VM2-2接收到數(shù)據(jù)包。
以上通信步驟直接在計(jì)算節(jié)點(diǎn)間進(jìn)行,無(wú)需經(jīng)過網(wǎng)絡(luò)節(jié)點(diǎn)處理。
在實(shí)際應(yīng)用場(chǎng)景中,同一租戶的不同虛擬機(jī)之間也存在訪問控制的需求,要通過配置虛擬防火墻的方式實(shí)現(xiàn)。與分布式虛擬路由類似,本文的虛擬防火墻同樣將原有集中式部署改為分布式部署,防火墻規(guī)則通過iptables的形式作用在分布式虛擬路由器對(duì)應(yīng)的網(wǎng)絡(luò)命名空間中。
2.2.3 租戶網(wǎng)絡(luò)與外網(wǎng)之間的邊界
這里以虛擬機(jī)VM1-1與外部網(wǎng)絡(luò)的通信為例,對(duì)比集中式路由與分布式路由。子網(wǎng)1的網(wǎng)關(guān)記為GW1,虛擬路由器上的外網(wǎng)網(wǎng)關(guān)記為EG1。
OpenStack原有的實(shí)現(xiàn)方式需要通過網(wǎng)絡(luò)節(jié)點(diǎn)上的虛擬路由器,具體步驟如下:
1) VM1-1發(fā)出數(shù)據(jù)包,目的地址為外網(wǎng)的IP地址;
2) 計(jì)算節(jié)點(diǎn)1的虛擬交換機(jī)br-int收到數(shù)據(jù)包,加上子網(wǎng)1的內(nèi)部VLAN標(biāo)簽后轉(zhuǎn)發(fā)到VTEP(br-tun);
3) 計(jì)算節(jié)點(diǎn)1的br-tun將內(nèi)部VLAN標(biāo)簽轉(zhuǎn)換為子網(wǎng)1對(duì)應(yīng)的VXLAN標(biāo)識(shí)VNI,并從數(shù)據(jù)網(wǎng)卡通過VXLAN隧道把數(shù)據(jù)包轉(zhuǎn)發(fā)到網(wǎng)絡(luò)節(jié)點(diǎn);
4) 網(wǎng)絡(luò)節(jié)點(diǎn)的VTEP(br-tun)對(duì)數(shù)據(jù)包進(jìn)行解封裝處理,將子網(wǎng)1的VXLAN標(biāo)識(shí)轉(zhuǎn)換為內(nèi)部VLAN標(biāo)簽,并轉(zhuǎn)發(fā)到虛擬交換機(jī)br-int;
5) 網(wǎng)絡(luò)節(jié)點(diǎn)的br-int把數(shù)據(jù)包交到虛擬路由處理,因?yàn)槟康牡刂穼儆谕獠烤W(wǎng)絡(luò),使用NAT規(guī)則把數(shù)據(jù)包源地址改為外網(wǎng)網(wǎng)關(guān)端口EG1的地址;并根據(jù)路由規(guī)則,從EG1轉(zhuǎn)發(fā)到外網(wǎng)虛擬交換機(jī)(br-ex)上;
6) 網(wǎng)絡(luò)節(jié)點(diǎn)的br-ex通過外網(wǎng)網(wǎng)卡把數(shù)據(jù)包發(fā)送到外網(wǎng)。
與OpenStack原有的方式相比,本文的分布式路由模式在處理虛擬機(jī)與外網(wǎng)之間的通信時(shí)更為直接。
如圖6所示,在計(jì)算節(jié)點(diǎn)上設(shè)置了租戶分布式路由器,并配置了外網(wǎng)網(wǎng)卡。虛擬機(jī)與外網(wǎng)間的通信不再像原先那樣必須通過網(wǎng)絡(luò)節(jié)點(diǎn),而是通過宿主機(jī)上的分布式虛擬路由,從外網(wǎng)網(wǎng)卡直接訪問外網(wǎng)。
下面是虛擬機(jī)VM1-1訪問外網(wǎng)的過程(與圖6中的序號(hào)對(duì)應(yīng)):
1) VM1-1發(fā)出數(shù)據(jù)包,目的地址為外網(wǎng)的IP地址;
2) 虛擬交換機(jī)br-int收到數(shù)據(jù)包,把數(shù)據(jù)包交到分布式虛擬路由器處理,在租戶虛擬路由的網(wǎng)絡(luò)命名空間中,配置了基于iptables的NAT規(guī)則,將數(shù)據(jù)包源地址從VM1-1的私有IP地址轉(zhuǎn)換到外網(wǎng)網(wǎng)關(guān)EG1的IP地址,如:
iptables-A POSTROUTING-s 192.168.30.0/24-j SNAT-to-source 10.10.88.51
即數(shù)據(jù)包源地址轉(zhuǎn)換為外部IP(如10.10.88.51);
3) 根據(jù)虛擬路由的默認(rèn)規(guī)則,確定數(shù)據(jù)包從外網(wǎng)網(wǎng)關(guān)EG1轉(zhuǎn)發(fā)到外網(wǎng)虛擬交換機(jī)(br-ex)上;
4) 網(wǎng)絡(luò)節(jié)點(diǎn)的br-ex通過外網(wǎng)網(wǎng)卡把數(shù)據(jù)包發(fā)送到外網(wǎng)。
作為隔離過濾外部非法訪問的重要手段,本文的虛擬防火墻基于iptables規(guī)則配置,與上面的NAT一樣,把規(guī)則作用在虛擬路由器所在的Linux網(wǎng)絡(luò)命名空間中。
圖6 虛擬機(jī)與外網(wǎng)的通信場(chǎng)景
3.1 實(shí)驗(yàn)環(huán)境
本文的實(shí)驗(yàn)環(huán)境部署在4臺(tái)物理服務(wù)器上,搭建了基于OpenStack Juno版本的環(huán)境。Dell服務(wù)器的操作系統(tǒng)為CentOS 7,多網(wǎng)卡,其中控制節(jié)點(diǎn)使用單網(wǎng)卡(管理網(wǎng)),計(jì)算節(jié)點(diǎn)和網(wǎng)絡(luò)節(jié)點(diǎn)使用三網(wǎng)卡(管理網(wǎng)、數(shù)據(jù)網(wǎng)、外網(wǎng)),管理網(wǎng)網(wǎng)段10.10.82.0/24,數(shù)據(jù)網(wǎng)網(wǎng)段10.10.87.0/24,外網(wǎng)網(wǎng)段10.10.88.0/24。
根據(jù)本文的分布式實(shí)現(xiàn)虛擬網(wǎng)絡(luò)隔離方式,在這套實(shí)驗(yàn)環(huán)境中通過租戶admin創(chuàng)建了一套基于本文分布式架構(gòu)的虛擬網(wǎng)絡(luò),包括兩個(gè)子網(wǎng)和4臺(tái)虛擬機(jī),虛擬機(jī)的詳細(xì)信息(所在物理機(jī)、所在子網(wǎng))見表1所示。
表1 實(shí)驗(yàn)環(huán)境虛擬機(jī)分布信息
租戶admin的兩個(gè)子網(wǎng)IP端分別為192.168.30.0/24和192.168.40.0/24,對(duì)應(yīng)VXLAN標(biāo)識(shí)分別為5和7,兩個(gè)計(jì)算節(jié)點(diǎn)上都有兩臺(tái)屬于兩個(gè)不同子網(wǎng)的虛擬機(jī)。
根據(jù)圖4的物理架構(gòu),本文的實(shí)驗(yàn)環(huán)境運(yùn)用Linux的網(wǎng)絡(luò)命名空間技術(shù),在兩個(gè)計(jì)算節(jié)點(diǎn)上都創(chuàng)建租戶admin的分布式虛擬路由器和防火墻,這兩個(gè)虛擬路由器在配置上是相同的,端口包含兩個(gè)子網(wǎng)的網(wǎng)關(guān)(IP地址分別為192.168.30.1和192.168.40.1),以及外網(wǎng)網(wǎng)關(guān)(IP地址10.10.88.51)。
同樣,通過租戶admin利用OpenStack原有的方式也創(chuàng)建一套類似的虛擬網(wǎng)絡(luò),在配置與虛擬機(jī)分布方面與表1相同,便于實(shí)驗(yàn)對(duì)照。
3.2 網(wǎng)絡(luò)延遲對(duì)比
在本文第2節(jié)中,已經(jīng)通過對(duì)比集中式虛擬網(wǎng)絡(luò)隔離與分布式虛擬網(wǎng)絡(luò)隔離,分析了分布式架構(gòu)可以避免虛擬機(jī)流量集中到單一網(wǎng)絡(luò)節(jié)點(diǎn),降低單點(diǎn)故障的可能性;也從理論上分析了本文分布式虛擬網(wǎng)絡(luò)隔離方案在路由步驟上更加簡(jiǎn)潔,可以減少跨子網(wǎng)虛擬機(jī)通信的網(wǎng)絡(luò)延遲。本節(jié)將給出實(shí)驗(yàn)環(huán)境中的對(duì)比,分析OpenStack原有集中式路由與本文分布式路由在幾種不同場(chǎng)景下的網(wǎng)絡(luò)延遲對(duì)比。
根據(jù)上文的分析,集中式路由在處理同租戶不同子網(wǎng)之間的邊界、以及租戶虛擬網(wǎng)絡(luò)與外網(wǎng)邊界時(shí)存在不合理之處,即租戶虛擬機(jī)跨子網(wǎng)通信和虛擬機(jī)與外網(wǎng)通信這兩種情況。其中租戶虛擬機(jī)跨子網(wǎng)的通信還可以根據(jù)虛擬機(jī)在計(jì)算節(jié)點(diǎn)的分布,細(xì)分為同一物理機(jī)和跨物理機(jī)兩種。
表1中的虛擬機(jī)VM1與VM2位于計(jì)算節(jié)點(diǎn)1(compute1),分別屬于30和40網(wǎng)段,它們之間的通信屬于跨子網(wǎng)同物理機(jī)情況;VM1與VM4分別位于計(jì)算節(jié)點(diǎn)1(compute1)和計(jì)算節(jié)點(diǎn)2(compute2),分別屬于30和40網(wǎng)段,它們之間的通信屬于跨子網(wǎng)跨物理機(jī)情況;而VM1與外網(wǎng)的通信則屬于虛擬機(jī)與外網(wǎng)通信,本文以虛擬機(jī)訪問www.fudan.edu.cn為例。
圖7是本文針對(duì)三類不同場(chǎng)景的網(wǎng)絡(luò)延遲實(shí)驗(yàn)結(jié)果對(duì)比圖。柱狀圖中白色表示OpenStack原有方式下的網(wǎng)絡(luò)延遲,陰影部分表示本文采用的分布式架構(gòu)下的網(wǎng)絡(luò)延遲。可以看到在三類不同場(chǎng)景中,分布式路由模式能有效降低虛擬機(jī)的網(wǎng)絡(luò)延遲。
圖7 不同場(chǎng)景下虛擬機(jī)網(wǎng)絡(luò)延遲對(duì)比(單位:毫秒)
在以上三類場(chǎng)景中,分布式比集中式的虛擬機(jī)網(wǎng)絡(luò)延遲低的原因是,相比OpenStack原有的集中式虛擬網(wǎng)絡(luò)路由模式,本文的方式更為直接。不論是虛擬機(jī)跨子網(wǎng)通信,還是虛擬機(jī)與外網(wǎng)通信,數(shù)據(jù)包無(wú)需專門經(jīng)過網(wǎng)絡(luò)節(jié)點(diǎn)進(jìn)行處理,而是直接由所在宿主機(jī)上的虛擬路由處理,從而簡(jiǎn)化了虛擬機(jī)數(shù)據(jù)包在網(wǎng)絡(luò)中的路由步驟和流程,降低網(wǎng)絡(luò)延遲。
實(shí)驗(yàn)證明,在分布式虛擬網(wǎng)絡(luò)隔離模式下,虛擬機(jī)的數(shù)據(jù)包直接由宿主機(jī)上的分布式虛擬路由器進(jìn)行處理,減少了虛擬機(jī)通信的網(wǎng)絡(luò)延遲,從而提高虛擬網(wǎng)絡(luò)中的效率。另一方面,避免虛擬機(jī)流量集中到同一個(gè)節(jié)點(diǎn),也降低了單點(diǎn)故障的風(fēng)險(xiǎn)。
當(dāng)前主流開源云平臺(tái)(如OpenStack)中,虛擬網(wǎng)絡(luò)隔離采用集中式部署虛擬路由器/防火墻的方式實(shí)現(xiàn),存在單點(diǎn)故障的隱患。本文采用分布式實(shí)現(xiàn)虛擬網(wǎng)絡(luò)隔離的方式,將原先集中部署在單一節(jié)點(diǎn)的虛擬路由器/防火墻分布到各計(jì)算節(jié)點(diǎn),從而將虛擬機(jī)通信流量直接交給宿主機(jī)上的分布式虛擬路由器處理,降低發(fā)生單點(diǎn)故障影響整個(gè)網(wǎng)絡(luò)通信的可能性。即使在某個(gè)物理節(jié)點(diǎn)上出現(xiàn)故障,也只影響這臺(tái)服務(wù)器上的虛擬機(jī)通信,網(wǎng)絡(luò)中的其他虛擬機(jī)不受影響,仍可以正常通信。實(shí)驗(yàn)驗(yàn)證了本文分布式部署架構(gòu)的有效性,并根據(jù)集中式路由與分布式路由的虛擬機(jī)網(wǎng)絡(luò)延遲對(duì)比,證實(shí)本文的分布式路由可以簡(jiǎn)化虛擬機(jī)的通信流程,降低網(wǎng)絡(luò)延遲。
本文的部署模型將租戶虛擬路由器/防火墻部署在所有相關(guān)計(jì)算節(jié)點(diǎn)上,屬于一種靜態(tài)部署的方式,而云網(wǎng)絡(luò)中虛擬機(jī)遷移與變更時(shí)常發(fā)生,虛擬路由和防火墻也面臨相應(yīng)的變更。下一步的研究計(jì)劃是動(dòng)態(tài)確定虛擬網(wǎng)絡(luò)邊界節(jié)點(diǎn)的位置,將分布式路由/防火墻部署到相應(yīng)邊界節(jié)點(diǎn)(即部分計(jì)算節(jié)點(diǎn)上),從而降低虛擬機(jī)遷移造成的影響,提高分布式配置的效率。
[1] Jain R, Paul S. Network virtualization and software defined networking for cloud computing: a survey[J]. Communications Magazine, IEEE, 2013, 51(11): 24-31.
[2] Koponen T, Amidon K, Balland P, et al. Network virtualization in multi-tenant datacenters[C]//USENIX NSDI. 2014.
[3] OpenStack[EB/OL].[2015]. http://docs.openstack.org.
[4] Hwang J, Ramakrishnan K K, Wood T. NetVM: high performance and flexible networking using virtualization on commodity platforms[C]//11th USENIX Symposium on Networked Systems Design and Implementation (NSDI 14). Seattle, WA: USENIX Association. 2014: 445-458.
[5] Martins J, Ahmed M, Raiciu C, et al. ClickOS and the art of network function virtualization[C]//Proc. USENIX NSDI. 2014: 459-473.
[6] Gember A, Grandl R, Anand A, et al. Stratos: Virtual middleboxes as first-class entities[J]. UW-Madison TR1771, 2012.
[7] VMware NSX Network Virtualization Design Guide[EB/OL].[2015]. http://www.vmware.com/files/pdf/products/nsx/vmw-nsx-network-virtualization-design-guide.pdf.
[8] Mahalingam M, Dutt D, Duda K, et al. Virtual extensible local area network (VXLAN): A framework for overlaying virtualized layer 2 networks over layer 3 networks[J]. Internet Req. Comments, 2014.
[9] Open vSwitch[EB/OL].[2015]. http://openvswitch.org.
[10] Mudigonda J, Yalagandula P, Mogul J, et al. NetLord: a scalable multi-tenant network architecture for virtualized datacenters.[J]. Acm Sigcomm Computer Communication Review, 2011,41(4):62-73.
[11] Angel S, Ballani H, Karagiannis T, et al. End-to-end performance isolation through virtual datacenters[J]. Osdi14 Usenix Symposium on Operating Systems Design & Implementation, 2014.
RESEARCH ON DISTRIBUTED VIRTUAL NETWORK ISOLATION IN MULTI-TENANT CLOUD-COMPUTING NETWORK
Yan Liyu1,2Zu Lijun3Ye Jiawei1,2*Zhou Yongkai3Wu Chengrong1,2
1(SchoolofComputerScience,FudanUniversity,Shanghai200433,China)2(EngineeringResearchCenterofCyberSecurityAuditingandMonitoring,MinistryofEducation,Shanghai200433,China)3(InstituteofElectronicPayment,ChinaUnionPayCo.,Ltd,Shanghai201201,China)
In recent years, with the rapid development of network virtualization technology, cloud service providers can provide virtual networks abstracted from one set of physical network for tenants. In the multi-tenant network environment, tenants should be guaranteed that their virtual networks are isolated and won’t be accessed illegally from other tenants or outer networks. The definition of the virtual network borders is more obscure than physical network borders, so more fine-grained network isolation is required. Mainstream open source cloud platforms like OpenStack uses centralized network border to realize the isolation of virtual networks, and most traffic of VMs (virtual machines) is converged into single physical node, which may lead to SPOF (single point of failure). Thus, a distributed realization of virtual network isolation is proposed, which distributes the centralized border to each physical server, and the network traffic is distributed to physical servers so that the possibility of loss caused by SPOF will be reduced. Finally, experiments prove the availability of the distributed deployment and the lower network latency of VM communication in the distributed realization.
Multi-tenant virtual network isolation Border of virtual networks Virtual routers Distribution Single point of failure
2015-09-22。嚴(yán)立宇,碩士生,主研領(lǐng)域:信息安全,網(wǎng)絡(luò)虛擬化。祖立軍,工程師。葉家煒,工程師。周雍愷,博士生。吳承榮,副教授。
TP393
A
10.3969/j.issn.1000-386x.2016.11.022