云計算網(wǎng)絡(luò)中多租戶虛擬網(wǎng)絡(luò)隔離的分布式實現(xiàn)研究

嚴(yán)立宇 祖立軍 葉家煒* 周雍愷 吳承榮

1(復(fù)旦大學(xué)計算機科學(xué)技術(shù)學(xué)院 上海 200433)2(網(wǎng)絡(luò)信息安全審計與監(jiān)控教育部工程研究中心 上海 200433)3(中國銀聯(lián)股份有限公司電子支付研究院 上海 201201)

?

云計算網(wǎng)絡(luò)中多租戶虛擬網(wǎng)絡(luò)隔離的分布式實現(xiàn)研究

嚴(yán)立宇1，2祖立軍3葉家煒1，2*周雍愷3吳承榮1，2

1(復(fù)旦大學(xué)計算機科學(xué)技術(shù)學(xué)院 上海 200433)2(網(wǎng)絡(luò)信息安全審計與監(jiān)控教育部工程研究中心 上海 200433)3(中國銀聯(lián)股份有限公司電子支付研究院 上海 201201)

近年來，隨著網(wǎng)絡(luò)虛擬化技術(shù)的快速發(fā)展，云服務(wù)提供商可以將一套物理網(wǎng)絡(luò)抽象成多套相互獨立的虛擬網(wǎng)絡(luò)提供給租戶。在多租戶網(wǎng)絡(luò)環(huán)境中，需要保證租戶網(wǎng)絡(luò)的安全隔離，確保租戶數(shù)據(jù)不會遭到來自其他租戶以及外部網(wǎng)絡(luò)的非法訪問。相比傳統(tǒng)物理網(wǎng)絡(luò)的邊界，虛擬網(wǎng)絡(luò)的邊界定義更加模糊，需要更細(xì)粒度的網(wǎng)絡(luò)隔離；當(dāng)前以O(shè)penStack為代表的主流開源云平臺采用集中式部署網(wǎng)絡(luò)邊界節(jié)點的方式實現(xiàn)虛擬網(wǎng)絡(luò)的隔離，虛擬機流量大多集中到單一物理節(jié)點上，存在單點故障的隱患。提出分布式實現(xiàn)虛擬網(wǎng)絡(luò)隔離的方式，把原本集中的虛擬網(wǎng)絡(luò)邊界分布到各臺物理服務(wù)器，從而將原本集中于同一節(jié)點的網(wǎng)絡(luò)流量分?jǐn)偟礁魑锢矸?wù)器，降低單點故障造成損失的可能性。最后經(jīng)過實驗證實了分布式部署的有效性，同時能夠降低虛擬機通信的網(wǎng)絡(luò)延遲。

多租戶虛擬網(wǎng)絡(luò)隔離 虛擬網(wǎng)絡(luò)邊界 虛擬路由器 分布式 單點故障

0 引 言

隨著虛擬化技術(shù)的快速發(fā)展，云計算在大型數(shù)據(jù)中心網(wǎng)絡(luò)中已經(jīng)得到大規(guī)模應(yīng)用，對網(wǎng)絡(luò)的性能要求和安全要求也越來越高。與服務(wù)器虛擬化類似，網(wǎng)絡(luò)虛擬化技術(shù)的發(fā)展使得云服務(wù)提供商能將物理網(wǎng)絡(luò)設(shè)備抽象成虛擬的網(wǎng)絡(luò)設(shè)備提供給租戶，并允許每個租戶創(chuàng)建自己的虛擬網(wǎng)絡(luò)，結(jié)合租戶申請的虛擬機資源定義網(wǎng)絡(luò)拓?fù)洌瑢μ摂M網(wǎng)絡(luò)進行管理[1]。

對云服務(wù)提供商而言，虛擬網(wǎng)絡(luò)的基本需求是：允許網(wǎng)絡(luò)中多租戶共存，即在同一套物理網(wǎng)絡(luò)環(huán)境中，支持創(chuàng)建多套具備獨立服務(wù)模型、拓?fù)浜虸P地址空間的租戶虛擬網(wǎng)絡(luò)[2]。而從租戶的角度來看，不僅要求能夠創(chuàng)建一套獨立的虛擬網(wǎng)絡(luò)，在其中運行業(yè)務(wù)，而且要求確保租戶數(shù)據(jù)的隔離和安全性，保證數(shù)據(jù)不會遭到來自其他租戶以及外部網(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ò)的邊界處實現(xiàn)。但相比之下，虛擬網(wǎng)絡(luò)環(huán)境中的網(wǎng)絡(luò)邊界更加模糊，缺乏明確的定義，因此為租戶虛擬網(wǎng)絡(luò)提供路由及防火墻服務(wù)也更為復(fù)雜。同時，租戶虛擬網(wǎng)絡(luò)到實際物理網(wǎng)絡(luò)拓?fù)涞挠成涫窍鄬Ψ稚⒌?，同一租戶控制的虛擬機很可能分布在多臺物理服務(wù)器上，可見租戶虛擬網(wǎng)絡(luò)的邊界可以細(xì)化到各物理服務(wù)器的邊緣，需要更加細(xì)粒度的網(wǎng)絡(luò)隔離。

結(jié)合典型的虛擬網(wǎng)絡(luò)應(yīng)用場景來看，虛擬網(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)前主流的開源云平臺中，已經(jīng)有針對虛擬網(wǎng)絡(luò)安全隔離的解決方案，通過為租戶網(wǎng)絡(luò)創(chuàng)建虛擬路由及防火墻的方式實現(xiàn)虛擬網(wǎng)絡(luò)的安全隔離[3]。在現(xiàn)有架構(gòu)下，所有租戶的虛擬路由器及防火墻設(shè)備都位于同一物理節(jié)點，涉及租戶網(wǎng)絡(luò)邊界的流量都被集中到該節(jié)點上進行處理，存在引發(fā)單點故障的隱患，同時也增加了虛擬機通信的網(wǎng)絡(luò)延遲。

1 相關(guān)工作

1.1 相關(guān)研究進展

上文提到虛擬網(wǎng)絡(luò)的邊界更模糊，需要更細(xì)粒度的網(wǎng)絡(luò)安全隔離措施。學(xué)術(shù)界針對虛擬化環(huán)境下的安全隔離問題有不少研究，并結(jié)合網(wǎng)絡(luò)功能虛擬化(NFV)的概念，將虛擬防火墻一類的網(wǎng)絡(luò)設(shè)備定義為網(wǎng)絡(luò)中間件(MiddleBox)。文獻(xiàn)[4]提出NetVM平臺，將防火墻、路由器一類的設(shè)備部署在虛擬化層，相比預(yù)先部署在專用硬件設(shè)備的方案更具靈活性；同時，NetVM利用Intel的DPDK庫和零拷貝技術(shù)，提升了虛擬化層的網(wǎng)絡(luò)速率和吞吐量，并實現(xiàn)網(wǎng)絡(luò)高性能。文獻(xiàn)[5]圍繞網(wǎng)絡(luò)功能虛擬化的概念，提出ClickOS虛擬化平臺，在其中部署高性能的中間件平臺，包括虛擬防火墻、NAT、負(fù)載均衡器等，優(yōu)化中間件的數(shù)據(jù)包處理，提供了一種通過軟件實現(xiàn)網(wǎng)絡(luò)中間件的方案。文獻(xiàn)[11]則重點關(guān)注虛擬網(wǎng)絡(luò)性能，提出Pulsar平臺來為租戶提供虛擬數(shù)據(jù)中心(VDC)的抽象模型，并保證虛擬網(wǎng)絡(luò)性能達(dá)到租戶的需求。

可見學(xué)術(shù)界多數(shù)研究的重點關(guān)注集成、管理和擴展中間件部署的能力和虛擬化I/O問題，旨在提升數(shù)據(jù)包通過虛擬機與物理機之間的速率，提高中間件平臺的可用性。此外，CloudMB項目[6]關(guān)注虛擬網(wǎng)絡(luò)服務(wù)初始放置的優(yōu)化，期望在物理拓?fù)浜土鞣植伎芍那闆r下，通過啟發(fā)式算法計算出虛擬網(wǎng)絡(luò)服務(wù)部署的合理位置，避免可能導(dǎo)致性能瓶頸的機架間流量。文獻(xiàn)[2，10]都為多租戶提供獨立的IP地址空間，采用數(shù)據(jù)包封裝技術(shù)來區(qū)分并隔離不同租戶。

而在工業(yè)界，針對虛擬網(wǎng)絡(luò)層面的安全隔離問題，有不少解決方案試圖通過定義虛擬網(wǎng)絡(luò)的邊界，并在相應(yīng)邊界物理節(jié)點部署虛擬路由及防火墻的方式來實現(xiàn)隔離。云計算環(huán)境中提供的服務(wù)范圍越來越廣，防火墻即服務(wù)的概念也已產(chǎn)生，虛擬防火墻及路由器以服務(wù)的方式提供給租戶，租戶可以為自己的子網(wǎng)申請?zhí)摂M路由器及防火墻，并為虛擬網(wǎng)絡(luò)的防火墻添加策略和規(guī)則。

在安全隔離的部署架構(gòu)方面，以VMWare的NSX[7]為代表的商用虛擬網(wǎng)絡(luò)解決方案中已經(jīng)提出了分布式邏輯路由，以及分布式虛擬防火墻的概念。該方案采用位于物理網(wǎng)絡(luò)邊界的集中式節(jié)點處理南北向流量(租戶虛擬機與外部網(wǎng)絡(luò)的流量)、位于各物理服務(wù)器內(nèi)部的分布式虛擬路由/防火墻處理東西向流量(跨物理機的虛擬機之間的流量)。

而在主流開源云平臺(如OpenStack)[3]中仍然采取集中部署虛擬路由器及防火墻的方式，即專設(shè)一臺服務(wù)器(或?qū)Ｓ糜布W(wǎng)絡(luò)設(shè)備)作為網(wǎng)絡(luò)節(jié)點，在該網(wǎng)絡(luò)節(jié)點上為每個租戶部署虛擬路由器，并配置虛擬防火墻作用在虛擬路由器上。這種部署方式的思路就是將虛擬網(wǎng)絡(luò)的邊界集中到統(tǒng)一的節(jié)點，所有涉及租戶網(wǎng)絡(luò)邊界的流量都被集中到網(wǎng)絡(luò)節(jié)點上進行處理。但這樣的實現(xiàn)方式容易引發(fā)單點故障，下一節(jié)將具體分析其中存在的問題。

1.2 集中式虛擬路由的問題

上文中圖1給出了虛擬網(wǎng)絡(luò)邊界的3種場景。OpenStack允許租戶分別創(chuàng)建各自的虛擬路由和虛擬防火墻，不同租戶的虛擬路由器之間默認(rèn)沒有關(guān)聯(lián)，無法相互訪問，因此可以達(dá)到隔離多租戶虛擬網(wǎng)絡(luò)的目的，但在處理(2)、(3)兩類網(wǎng)絡(luò)邊界場景時，存在不合理之處。

圖2是OpenStack實現(xiàn)虛擬網(wǎng)絡(luò)隔離的路由模式，其中網(wǎng)絡(luò)節(jié)點是OpenStack專設(shè)的實現(xiàn)虛擬網(wǎng)絡(luò)功能的物理服務(wù)器節(jié)點，所有租戶的虛擬路由器均部署在網(wǎng)絡(luò)節(jié)點上，虛擬防火墻的規(guī)則作用在相應(yīng)虛擬路由器上，而計算節(jié)點則是部署了虛擬機管理程序(Hypervisor)及虛擬機資源的物理服務(wù)器。為便于說明問題，假設(shè)租戶A創(chuàng)建了一套虛擬網(wǎng)絡(luò)，配置了兩個子網(wǎng)，子網(wǎng)下的虛擬機分布在不同計算節(jié)點上。

圖2 OpenStack虛擬網(wǎng)絡(luò)隔離的路由模式圖

在同租戶不同子網(wǎng)邊界方面：由于云計算的一大特點是東西向流量增大，業(yè)務(wù)運行時，跨物理機的虛擬機之間經(jīng)常進行通信。在現(xiàn)有的網(wǎng)絡(luò)架構(gòu)下，跨子網(wǎng)的網(wǎng)絡(luò)通信流量都需要通過網(wǎng)絡(luò)節(jié)點上的虛擬路由器進行轉(zhuǎn)發(fā)。圖2中深色箭頭對應(yīng)的路徑是租戶A不同子網(wǎng)下的虛擬機之間通信時的數(shù)據(jù)包路徑，其中位于子網(wǎng)1的虛擬機VM1與位于子網(wǎng)2的虛擬機VM2通信，數(shù)據(jù)包經(jīng)過位于網(wǎng)絡(luò)節(jié)點的虛擬路由器和虛擬防火墻。

在租戶與外網(wǎng)邊界方面：虛擬機與外部網(wǎng)絡(luò)之間的通信流量也需要經(jīng)過網(wǎng)絡(luò)節(jié)點，通過網(wǎng)絡(luò)地址轉(zhuǎn)換(NAT)和防火墻規(guī)則的過濾，如圖2中淺色箭頭所示。租戶A的虛擬機數(shù)據(jù)包在通往外網(wǎng)的過程中經(jīng)過網(wǎng)絡(luò)節(jié)點，通過部署在虛擬路由器上的NAT規(guī)則進行IP地址轉(zhuǎn)換，獲取外網(wǎng)IP資源，同時也經(jīng)過部署在虛擬路由器上的虛擬防火墻規(guī)則進行過濾，防止與外網(wǎng)間的非法通信。

因此，在多租戶的場景下，現(xiàn)有的虛擬網(wǎng)絡(luò)隔離實現(xiàn)模式會導(dǎo)致租戶虛擬機的大部分流量都經(jīng)過單一物理節(jié)點，對網(wǎng)絡(luò)節(jié)點造成極大的負(fù)載壓力。如果采用集中式部署的虛擬網(wǎng)絡(luò)隔離架構(gòu)，將網(wǎng)絡(luò)節(jié)點作為實現(xiàn)網(wǎng)絡(luò)功能和服務(wù)的單一節(jié)點，很容易引發(fā)單點故障問題；同時，由于租戶網(wǎng)絡(luò)隔離機制需要采用基于VXLAN的覆蓋網(wǎng)絡(luò)協(xié)議，對虛擬機網(wǎng)絡(luò)數(shù)據(jù)包進行封裝(在第2節(jié)詳細(xì)介紹)，虛擬機數(shù)據(jù)包在不同物理節(jié)點間的轉(zhuǎn)發(fā)都會經(jīng)過封裝與解封裝的過程。數(shù)據(jù)包統(tǒng)一經(jīng)過網(wǎng)絡(luò)節(jié)點處理，進一步增加了通信的網(wǎng)絡(luò)延遲。因此現(xiàn)有的虛擬網(wǎng)絡(luò)隔離架構(gòu)存在引發(fā)單點故障的隱患以及網(wǎng)絡(luò)延遲的問題，不具有高可用性和可擴展性。

虛擬網(wǎng)絡(luò)邊界相比傳統(tǒng)網(wǎng)絡(luò)而言更加模糊和復(fù)雜，需要更明確的網(wǎng)絡(luò)邊界節(jié)點定義以及更合理的網(wǎng)絡(luò)邊界隔離的解決方案。針對虛擬網(wǎng)絡(luò)的高可用性問題，文獻(xiàn)[2]采用的解決方案是關(guān)鍵組件集群式部署，即發(fā)生故障時可切換到集群中的備用設(shè)備，從而保證高可用。而本文則是從路由模式的角度出發(fā)，針對開源云平臺中存在的問題，提出了一種分布式實現(xiàn)多租戶虛擬網(wǎng)絡(luò)隔離的解決方案。

2 虛擬網(wǎng)絡(luò)隔離的分布式實現(xiàn)

2.1 總體架構(gòu)

與當(dāng)前主流云平臺(如OpenStack)的虛擬網(wǎng)絡(luò)隔離方式不同，本文提出了一種虛擬網(wǎng)絡(luò)安全隔離的分布式實現(xiàn)方式，將租戶虛擬路由器和防火墻分布到每個計算節(jié)點中。總體思路是把原本集中到單一物理節(jié)點的虛擬網(wǎng)絡(luò)邊界分散到各臺物理服務(wù)器，從而將原本集中于同一節(jié)點的網(wǎng)絡(luò)流量分?jǐn)偟礁魑锢矸?wù)器，降低單點故障造成損失的可能性。即使在某個節(jié)點上出現(xiàn)故障，也只影響這臺服務(wù)器上的虛擬機通信，網(wǎng)絡(luò)中的其他虛擬機仍可以正常通信。

圖3的路由模式圖給出的是同一租戶的虛擬網(wǎng)絡(luò)(包括子網(wǎng)和分布式虛擬路由)。本文的方案在支持多租戶方面，允許每個租戶創(chuàng)建相互獨立的虛擬子網(wǎng)和虛擬路由器，即同一臺物理服務(wù)器上可能包含多個租戶創(chuàng)建的虛擬路由器和防火墻，利用Linux內(nèi)核的網(wǎng)絡(luò)命名空間技術(shù)解決可能存在的多租戶IP地址沖突問題。此外，圖中的內(nèi)部數(shù)據(jù)網(wǎng)包括計算節(jié)點間的物理網(wǎng)絡(luò)設(shè)備(交換機、路由器等)。

可以對比圖3分布式實現(xiàn)的路由模式與圖2中OpenStack集中式實現(xiàn)的路由模式。在通過分布式實現(xiàn)的模式中，虛擬機與外網(wǎng)之間的通信，直接通過其所在Hypervisor上的分布式虛擬路由器通向外網(wǎng)；跨子網(wǎng)的虛擬機之間的通信，也直接通過分布式路由進行處理。這兩類流量直接由計算節(jié)點上的分布式路由處理，無需通過統(tǒng)一的網(wǎng)絡(luò)邊界節(jié)點。

圖3 分布式實現(xiàn)虛擬網(wǎng)絡(luò)隔離的路由模式

圖4是本文分布式路由的物理架構(gòu)圖。本文采用的虛擬交換機為Open vSwitch，部署在所有物理服務(wù)器上，其中虛擬交換機br-int連接Hypervisor上的所有虛擬機。而虛擬交換機br-tun作為處理VXLAN協(xié)議的端點VTEP(VXLAN-Tunnel-EndPoint)，對虛擬機出物理服務(wù)器的流量進行VXLAN封裝，通過數(shù)據(jù)網(wǎng)網(wǎng)卡轉(zhuǎn)發(fā)；對于接收到的VXLAN數(shù)據(jù)包，則進行解封裝處理，轉(zhuǎn)發(fā)給連接虛擬機的br-int處理。此外，虛擬交換機br-ex的作用是連接外網(wǎng)網(wǎng)卡，能夠處理虛擬機與外網(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)端口可在虛擬交換機上配置對應(yīng)端口，起到連接虛擬交換機和虛擬路由器的作用。本文部署虛擬路由器的模式是：根據(jù)租戶虛擬機的分布，在所有包含該租戶虛擬機的物理機上為配置分布式虛擬路由器，這些分布式虛擬路由器包含租戶下所有子網(wǎng)的網(wǎng)關(guān)端口。

為便于說明，設(shè)定以下場景：租戶A的虛擬網(wǎng)絡(luò)包含兩個子網(wǎng)(子網(wǎng)1和2)，虛擬機分布在兩個計算節(jié)點上，圖4中VMx-y代表計算節(jié)點x上屬于子網(wǎng)y的虛擬機，兩個計算節(jié)點各包含兩臺虛擬機，分別屬于租戶A的子網(wǎng)1和子網(wǎng)2。兩個計算節(jié)點的分布式虛擬路由器上均配置了子網(wǎng)1和子網(wǎng)2的網(wǎng)關(guān)。

下一節(jié)將結(jié)合三類虛擬網(wǎng)絡(luò)邊界場景，具體描述分布式虛擬網(wǎng)絡(luò)隔離的部署模式，并分析對比分布式路由與集中式路由的路由模式。

2.2 虛擬網(wǎng)絡(luò)安全隔離分析

引言中已經(jīng)結(jié)合實際應(yīng)用場景，將虛擬網(wǎng)絡(luò)的邊界分為三類，圖1列舉了這三類網(wǎng)絡(luò)邊界。本文的分布式虛擬網(wǎng)絡(luò)隔離充分考慮了這三類虛擬網(wǎng)絡(luò)邊界，并有針對性地采用了相應(yīng)的網(wǎng)絡(luò)虛擬化技術(shù)。本節(jié)分別分析本文的分布式實現(xiàn)方案在這三類邊界場景下的實際流程和相關(guān)技術(shù)。

2.2.1 多租戶網(wǎng)絡(luò)之間的邊界

網(wǎng)絡(luò)虛擬化技術(shù)使得云服務(wù)提供商能夠?qū)⒁惶孜锢砭W(wǎng)絡(luò)虛擬化成多套虛擬網(wǎng)絡(luò)，分別提供給不同的租戶。從租戶的角度考慮，一個重要的需求就是確保租戶網(wǎng)絡(luò)的安全隔離盒獨立性，防止自己的數(shù)據(jù)遭到來自其他租戶的非法訪問。

OpenStack現(xiàn)有的實現(xiàn)方式能夠很好地支持多租戶網(wǎng)絡(luò)安全隔離，因此本文在隔離多租戶虛擬網(wǎng)絡(luò)方面基本沿用了OpenStack的思路，并將集中式路由改為分布式。在實際部署上，將原先集中部署在網(wǎng)絡(luò)節(jié)點的租戶虛擬路由器和防火墻分布到租戶虛擬機所在的計算節(jié)點上，即所有包含租戶A的虛擬機的物理服務(wù)器上都部署屬于租戶A的虛擬路由器和虛擬防火墻。

同一計算節(jié)點上可能包含多位租戶所創(chuàng)建的虛擬路由器，連接各自的虛擬子網(wǎng)與外網(wǎng)。由于這些虛擬路由器之間默認(rèn)沒有關(guān)聯(lián)，未配置相關(guān)聯(lián)的路由規(guī)則，因此租戶之間的虛擬網(wǎng)絡(luò)無法相互訪問通信，從而達(dá)到不同租戶虛擬網(wǎng)絡(luò)邊界安全隔離的目的。

此外，考慮到多租戶虛擬網(wǎng)絡(luò)中，不同租戶可能采用相同的內(nèi)部IP地址資源，從而引起系統(tǒng)中路由、NAT及防火墻規(guī)則配置的沖突，因此需要使用Linux的網(wǎng)絡(luò)命名空間技術(shù)。該技術(shù)允許在操作系統(tǒng)中定義多個虛擬空間，每個空間可相互獨立、透明地進行網(wǎng)絡(luò)操作，從而能很好地支持多租戶虛擬網(wǎng)絡(luò)的需求。同一物理服務(wù)器中多租戶虛擬路由器的創(chuàng)建和管理配置正是基于網(wǎng)絡(luò)命名空間技術(shù)實現(xiàn)的。

2.2.2 同租戶不同子網(wǎng)之間的邊界

傳統(tǒng)網(wǎng)絡(luò)中常使用VLAN技術(shù)對網(wǎng)絡(luò)進行邏輯上的劃分，但隨著數(shù)據(jù)中心網(wǎng)絡(luò)規(guī)模以及虛擬機數(shù)量的飛速增長，VLAN暴露出一些問題。近年來，VXLAN[8]協(xié)議應(yīng)運而生，能夠解決以下幾方面的問題：

? VLAN規(guī)模限制

當(dāng)前的VLAN協(xié)議中，使用12位數(shù)據(jù)作為VLAN標(biāo)簽，最多支持4094個子網(wǎng)。隨著數(shù)據(jù)中心規(guī)模的擴大以及租戶虛擬網(wǎng)絡(luò)增多，這一數(shù)量不足以提供必要的傳播的獨立性。而在VXLAN中，引入了VNI(虛擬網(wǎng)絡(luò)標(biāo)識符)的概念，從12位擴展到了24位，支持超過1600萬個子網(wǎng)。

? 多租戶支持

數(shù)據(jù)中心托管多個租戶，而每個租戶需要流量隔離。這種隔離處于第二層，正如VLAN所提供的。在三層網(wǎng)絡(luò)的情況下，有可能有兩個租戶使用相同的三層尋址方案，需要以不同的方式提供隔離。VXLAN可以在現(xiàn)有的基礎(chǔ)設(shè)施上運行，使用VNI封裝虛擬機的數(shù)據(jù)包，建立VXLAN隧道，區(qū)分不同的虛擬子網(wǎng)。

? 交換機的虛擬機數(shù)量

在大二層網(wǎng)絡(luò)環(huán)境下，數(shù)據(jù)流需要通過明確的網(wǎng)絡(luò)尋址以保證準(zhǔn)確到達(dá)目的地，因此網(wǎng)絡(luò)設(shè)備的MAC地址表項大小，成為決定云計算環(huán)境下虛擬機的規(guī)模的上限的因素，限制了整個云計算數(shù)據(jù)中心的虛擬機數(shù)量。而通過VXLAN將虛擬機數(shù)據(jù)封裝在UDP數(shù)據(jù)包中后，對網(wǎng)絡(luò)只表現(xiàn)為封裝后的網(wǎng)絡(luò)參數(shù)，即VXLAN隧道端點(VTEP)的地址，因此，對于承載網(wǎng)絡(luò)(特別是接入交換機)的MAC地址規(guī)格需求極大降低。

在本文方案中采用基于VXLAN協(xié)議的覆蓋網(wǎng)絡(luò)技術(shù)，在不同計算節(jié)點之間建立VXLAN隧道，對虛擬機之間通信的數(shù)據(jù)包進行封裝，并通過VNI劃分不同虛擬子網(wǎng)。

同租戶跨子網(wǎng)的虛擬機之間的通信，根據(jù)虛擬機的位置分布，可以細(xì)分為同一物理機和跨物理機兩種情況。在原有的集中式路由模式下，同一租戶下跨子網(wǎng)的虛擬機之間的通信都需要經(jīng)過網(wǎng)絡(luò)節(jié)點上的虛擬路由處理。即使兩臺在同一物理機上的虛擬機之間通信，由于不處于同一子網(wǎng)，也沒有本地的路由關(guān)聯(lián)，因此必須先發(fā)送到網(wǎng)絡(luò)節(jié)點。這樣的步驟是十分繁瑣的，不僅增加了通信中的網(wǎng)絡(luò)延遲，也帶來了引發(fā)單點故障的隱患。

通過圖5說明本文的分布式路由如何處理同租戶跨子網(wǎng)的東西向流量。

圖5 跨子網(wǎng)虛擬機通信場景

這里以不同物理機上跨子網(wǎng)虛擬機通信為例，即圖5中VM1-1與VM2-2之間的通信。兩臺虛擬機分別屬于子網(wǎng)1和子網(wǎng)2。

在原先的集中式路由模式下，VM1-1發(fā)出的數(shù)據(jù)包在本地沒有匹配到路由規(guī)則，需要轉(zhuǎn)發(fā)到網(wǎng)絡(luò)節(jié)點上的虛擬路由進行處理，具體步驟如下：

1) VM1-1發(fā)出數(shù)據(jù)包，目的地址為VM2-2；

2) 計算節(jié)點1的虛擬交換機br-int收到數(shù)據(jù)包，加上子網(wǎng)1的內(nèi)部VLAN標(biāo)簽后轉(zhuǎn)發(fā)到VTEP(br-tun)；

3) 計算節(jié)點1的br-tun將內(nèi)部VLAN標(biāo)簽轉(zhuǎn)換為子網(wǎng)1對應(yīng)的VXLAN標(biāo)識VNI，并從數(shù)據(jù)網(wǎng)卡通過VXLAN隧道把數(shù)據(jù)包轉(zhuǎn)發(fā)到網(wǎng)絡(luò)節(jié)點；

4) 網(wǎng)絡(luò)節(jié)點的VTEP(br-tun)對數(shù)據(jù)包進行解封裝處理，將子網(wǎng)1的VXLAN標(biāo)識轉(zhuǎn)換為內(nèi)部VLAN標(biāo)簽，并轉(zhuǎn)發(fā)到虛擬交換機br-int；

5) 網(wǎng)絡(luò)節(jié)點的br-int把數(shù)據(jù)包交到虛擬路由處理，因為目的地址屬于子網(wǎng)2，根據(jù)路由規(guī)則，數(shù)據(jù)包通過子網(wǎng)2網(wǎng)關(guān)端口轉(zhuǎn)發(fā)，回到br-int；

6) 網(wǎng)絡(luò)節(jié)點的br-int把數(shù)據(jù)包加上子網(wǎng)2的內(nèi)部VLAN標(biāo)簽，轉(zhuǎn)發(fā)到br-tun；

7) 網(wǎng)絡(luò)節(jié)點的br-tun將內(nèi)部VLAN標(biāo)簽轉(zhuǎn)換為子網(wǎng)2對應(yīng)的VXLAN標(biāo)識VNI，并通過VXLAN隧道把數(shù)據(jù)包轉(zhuǎn)發(fā)到計算節(jié)點2；

8) 計算節(jié)點2的VTEP(br-tun)對數(shù)據(jù)包進行解封裝處理，將子網(wǎng)2的VXLAN標(biāo)識轉(zhuǎn)換為內(nèi)部VLAN標(biāo)簽，并轉(zhuǎn)發(fā)到虛擬交換機br-int；

9) 計算節(jié)點2的br-int將數(shù)據(jù)包轉(zhuǎn)發(fā)到VM2-2對應(yīng)端口，VM2-2接收到數(shù)據(jù)包。

可見這是一個復(fù)雜的過程，而本文在建立分布式路由后，可將跨子網(wǎng)虛擬機通信簡化為以下步驟(與圖5中的序號對應(yīng))：

1) VM1-1發(fā)出數(shù)據(jù)包，目的IP地址為VM2-2；

2) 計算節(jié)點1的虛擬交換機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) 計算節(jié)點1的br-int把數(shù)據(jù)包加上子網(wǎng)2的內(nèi)部VLAN標(biāo)簽，轉(zhuǎn)發(fā)到VTEP(br-tun)；

4) 計算節(jié)點1的br-tun將內(nèi)部VLAN標(biāo)簽轉(zhuǎn)換為子網(wǎng)2對應(yīng)的VXLAN標(biāo)識VNI，從數(shù)據(jù)網(wǎng)卡通過VXLAN隧道把數(shù)據(jù)包轉(zhuǎn)發(fā)到計算節(jié)點2；

5) 計算節(jié)點2的br-tun對數(shù)據(jù)包進行解封裝處理，將子網(wǎng)2的VXLAN標(biāo)識轉(zhuǎn)換為內(nèi)部VLAN標(biāo)簽，并轉(zhuǎn)發(fā)到虛擬交換機br-int；

6) 計算節(jié)點2的br-int將數(shù)據(jù)包轉(zhuǎn)發(fā)到VM2-2對應(yīng)端口，VM2-2接收到數(shù)據(jù)包。

以上通信步驟直接在計算節(jié)點間進行，無需經(jīng)過網(wǎng)絡(luò)節(jié)點處理。

在實際應(yīng)用場景中，同一租戶的不同虛擬機之間也存在訪問控制的需求，要通過配置虛擬防火墻的方式實現(xiàn)。與分布式虛擬路由類似，本文的虛擬防火墻同樣將原有集中式部署改為分布式部署，防火墻規(guī)則通過iptables的形式作用在分布式虛擬路由器對應(yīng)的網(wǎng)絡(luò)命名空間中。

2.2.3 租戶網(wǎng)絡(luò)與外網(wǎng)之間的邊界

這里以虛擬機VM1-1與外部網(wǎng)絡(luò)的通信為例，對比集中式路由與分布式路由。子網(wǎng)1的網(wǎng)關(guān)記為GW1，虛擬路由器上的外網(wǎng)網(wǎng)關(guān)記為EG1。

OpenStack原有的實現(xiàn)方式需要通過網(wǎng)絡(luò)節(jié)點上的虛擬路由器，具體步驟如下：

1) VM1-1發(fā)出數(shù)據(jù)包，目的地址為外網(wǎng)的IP地址；

2) 計算節(jié)點1的虛擬交換機br-int收到數(shù)據(jù)包，加上子網(wǎng)1的內(nèi)部VLAN標(biāo)簽后轉(zhuǎn)發(fā)到VTEP(br-tun)；

3) 計算節(jié)點1的br-tun將內(nèi)部VLAN標(biāo)簽轉(zhuǎn)換為子網(wǎng)1對應(yīng)的VXLAN標(biāo)識VNI，并從數(shù)據(jù)網(wǎng)卡通過VXLAN隧道把數(shù)據(jù)包轉(zhuǎn)發(fā)到網(wǎng)絡(luò)節(jié)點；

4) 網(wǎng)絡(luò)節(jié)點的VTEP(br-tun)對數(shù)據(jù)包進行解封裝處理，將子網(wǎng)1的VXLAN標(biāo)識轉(zhuǎn)換為內(nèi)部VLAN標(biāo)簽，并轉(zhuǎn)發(fā)到虛擬交換機br-int；

5) 網(wǎng)絡(luò)節(jié)點的br-int把數(shù)據(jù)包交到虛擬路由處理，因為目的地址屬于外部網(wǎng)絡(luò)，使用NAT規(guī)則把數(shù)據(jù)包源地址改為外網(wǎng)網(wǎng)關(guān)端口EG1的地址；并根據(jù)路由規(guī)則，從EG1轉(zhuǎn)發(fā)到外網(wǎng)虛擬交換機(br-ex)上；

6) 網(wǎng)絡(luò)節(jié)點的br-ex通過外網(wǎng)網(wǎng)卡把數(shù)據(jù)包發(fā)送到外網(wǎng)。

與OpenStack原有的方式相比，本文的分布式路由模式在處理虛擬機與外網(wǎng)之間的通信時更為直接。

如圖6所示，在計算節(jié)點上設(shè)置了租戶分布式路由器，并配置了外網(wǎng)網(wǎng)卡。虛擬機與外網(wǎng)間的通信不再像原先那樣必須通過網(wǎng)絡(luò)節(jié)點，而是通過宿主機上的分布式虛擬路由，從外網(wǎng)網(wǎng)卡直接訪問外網(wǎng)。

下面是虛擬機VM1-1訪問外網(wǎng)的過程(與圖6中的序號對應(yīng))：

1) VM1-1發(fā)出數(shù)據(jù)包，目的地址為外網(wǎng)的IP地址；

2) 虛擬交換機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)虛擬交換機(br-ex)上；

4) 網(wǎng)絡(luò)節(jié)點的br-ex通過外網(wǎng)網(wǎng)卡把數(shù)據(jù)包發(fā)送到外網(wǎng)。

作為隔離過濾外部非法訪問的重要手段，本文的虛擬防火墻基于iptables規(guī)則配置，與上面的NAT一樣，把規(guī)則作用在虛擬路由器所在的Linux網(wǎng)絡(luò)命名空間中。

圖6 虛擬機與外網(wǎng)的通信場景

3 部署與實驗

3.1 實驗環(huán)境

本文的實驗環(huán)境部署在4臺物理服務(wù)器上，搭建了基于OpenStack Juno版本的環(huán)境。Dell服務(wù)器的操作系統(tǒng)為CentOS 7，多網(wǎng)卡，其中控制節(jié)點使用單網(wǎng)卡(管理網(wǎng))，計算節(jié)點和網(wǎng)絡(luò)節(jié)點使用三網(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ù)本文的分布式實現(xiàn)虛擬網(wǎng)絡(luò)隔離方式，在這套實驗環(huán)境中通過租戶admin創(chuàng)建了一套基于本文分布式架構(gòu)的虛擬網(wǎng)絡(luò)，包括兩個子網(wǎng)和4臺虛擬機，虛擬機的詳細(xì)信息(所在物理機、所在子網(wǎng))見表1所示。

表1 實驗環(huán)境虛擬機分布信息

租戶admin的兩個子網(wǎng)IP端分別為192.168.30.0/24和192.168.40.0/24，對應(yīng)VXLAN標(biāo)識分別為5和7，兩個計算節(jié)點上都有兩臺屬于兩個不同子網(wǎng)的虛擬機。

根據(jù)圖4的物理架構(gòu)，本文的實驗環(huán)境運用Linux的網(wǎng)絡(luò)命名空間技術(shù)，在兩個計算節(jié)點上都創(chuàng)建租戶admin的分布式虛擬路由器和防火墻，這兩個虛擬路由器在配置上是相同的，端口包含兩個子網(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ò)，在配置與虛擬機分布方面與表1相同，便于實驗對照。

3.2 網(wǎng)絡(luò)延遲對比

在本文第2節(jié)中，已經(jīng)通過對比集中式虛擬網(wǎng)絡(luò)隔離與分布式虛擬網(wǎng)絡(luò)隔離，分析了分布式架構(gòu)可以避免虛擬機流量集中到單一網(wǎng)絡(luò)節(jié)點，降低單點故障的可能性；也從理論上分析了本文分布式虛擬網(wǎng)絡(luò)隔離方案在路由步驟上更加簡潔，可以減少跨子網(wǎng)虛擬機通信的網(wǎng)絡(luò)延遲。本節(jié)將給出實驗環(huán)境中的對比，分析OpenStack原有集中式路由與本文分布式路由在幾種不同場景下的網(wǎng)絡(luò)延遲對比。

根據(jù)上文的分析，集中式路由在處理同租戶不同子網(wǎng)之間的邊界、以及租戶虛擬網(wǎng)絡(luò)與外網(wǎng)邊界時存在不合理之處，即租戶虛擬機跨子網(wǎng)通信和虛擬機與外網(wǎng)通信這兩種情況。其中租戶虛擬機跨子網(wǎng)的通信還可以根據(jù)虛擬機在計算節(jié)點的分布，細(xì)分為同一物理機和跨物理機兩種。

表1中的虛擬機VM1與VM2位于計算節(jié)點1(compute1)，分別屬于30和40網(wǎng)段，它們之間的通信屬于跨子網(wǎng)同物理機情況；VM1與VM4分別位于計算節(jié)點1(compute1)和計算節(jié)點2(compute2)，分別屬于30和40網(wǎng)段，它們之間的通信屬于跨子網(wǎng)跨物理機情況；而VM1與外網(wǎng)的通信則屬于虛擬機與外網(wǎng)通信，本文以虛擬機訪問www.fudan.edu.cn為例。

圖7是本文針對三類不同場景的網(wǎng)絡(luò)延遲實驗結(jié)果對比圖。柱狀圖中白色表示OpenStack原有方式下的網(wǎng)絡(luò)延遲，陰影部分表示本文采用的分布式架構(gòu)下的網(wǎng)絡(luò)延遲?？梢钥吹皆谌惒煌瑘鼍爸校植际铰酚赡Ｊ侥苡行Ы档吞摂M機的網(wǎng)絡(luò)延遲。

圖7 不同場景下虛擬機網(wǎng)絡(luò)延遲對比(單位：毫秒)

在以上三類場景中，分布式比集中式的虛擬機網(wǎng)絡(luò)延遲低的原因是，相比OpenStack原有的集中式虛擬網(wǎng)絡(luò)路由模式，本文的方式更為直接。不論是虛擬機跨子網(wǎng)通信，還是虛擬機與外網(wǎng)通信，數(shù)據(jù)包無需專門經(jīng)過網(wǎng)絡(luò)節(jié)點進行處理，而是直接由所在宿主機上的虛擬路由處理，從而簡化了虛擬機數(shù)據(jù)包在網(wǎng)絡(luò)中的路由步驟和流程，降低網(wǎng)絡(luò)延遲。

實驗證明，在分布式虛擬網(wǎng)絡(luò)隔離模式下，虛擬機的數(shù)據(jù)包直接由宿主機上的分布式虛擬路由器進行處理，減少了虛擬機通信的網(wǎng)絡(luò)延遲，從而提高虛擬網(wǎng)絡(luò)中的效率。另一方面，避免虛擬機流量集中到同一個節(jié)點，也降低了單點故障的風(fēng)險。

4 結(jié) 語

當(dāng)前主流開源云平臺(如OpenStack)中，虛擬網(wǎng)絡(luò)隔離采用集中式部署虛擬路由器/防火墻的方式實現(xiàn)，存在單點故障的隱患。本文采用分布式實現(xiàn)虛擬網(wǎng)絡(luò)隔離的方式，將原先集中部署在單一節(jié)點的虛擬路由器/防火墻分布到各計算節(jié)點，從而將虛擬機通信流量直接交給宿主機上的分布式虛擬路由器處理，降低發(fā)生單點故障影響整個網(wǎng)絡(luò)通信的可能性。即使在某個物理節(jié)點上出現(xiàn)故障，也只影響這臺服務(wù)器上的虛擬機通信，網(wǎng)絡(luò)中的其他虛擬機不受影響，仍可以正常通信。實驗驗證了本文分布式部署架構(gòu)的有效性，并根據(jù)集中式路由與分布式路由的虛擬機網(wǎng)絡(luò)延遲對比，證實本文的分布式路由可以簡化虛擬機的通信流程，降低網(wǎng)絡(luò)延遲。

本文的部署模型將租戶虛擬路由器/防火墻部署在所有相關(guān)計算節(jié)點上，屬于一種靜態(tài)部署的方式，而云網(wǎng)絡(luò)中虛擬機遷移與變更時常發(fā)生，虛擬路由和防火墻也面臨相應(yīng)的變更。下一步的研究計劃是動態(tài)確定虛擬網(wǎng)絡(luò)邊界節(jié)點的位置，將分布式路由/防火墻部署到相應(yīng)邊界節(jié)點(即部分計算節(jié)點上)，從而降低虛擬機遷移造成的影響，提高分布式配置的效率。

[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