云計算網絡中多租戶虛擬網絡隔離的分布式實現研究

嚴立宇 祖立軍 葉家煒* 周雍愷 吳承榮

1(復旦大學計算機科學技術學院 上海 200433)2(網絡信息安全審計與監控教育部工程研究中心 上海 200433)3(中國銀聯股份有限公司電子支付研究院 上海 201201)

?

云計算網絡中多租戶虛擬網絡隔離的分布式實現研究

嚴立宇1，2祖立軍3葉家煒1，2*周雍愷3吳承榮1，2

1(復旦大學計算機科學技術學院 上海 200433)2(網絡信息安全審計與監控教育部工程研究中心 上海 200433)3(中國銀聯股份有限公司電子支付研究院 上海 201201)

近年來，隨著網絡虛擬化技術的快速發展，云服務提供商可以將一套物理網絡抽象成多套相互獨立的虛擬網絡提供給租戶。在多租戶網絡環境中，需要保證租戶網絡的安全隔離，確保租戶數據不會遭到來自其他租戶以及外部網絡的非法訪問。相比傳統物理網絡的邊界，虛擬網絡的邊界定義更加模糊，需要更細粒度的網絡隔離；當前以OpenStack為代表的主流開源云平臺采用集中式部署網絡邊界節點的方式實現虛擬網絡的隔離，虛擬機流量大多集中到單一物理節點上，存在單點故障的隱患。提出分布式實現虛擬網絡隔離的方式，把原本集中的虛擬網絡邊界分布到各臺物理服務器，從而將原本集中于同一節點的網絡流量分攤到各物理服務器，降低單點故障造成損失的可能性。最后經過實驗證實了分布式部署的有效性，同時能夠降低虛擬機通信的網絡延遲。

多租戶虛擬網絡隔離 虛擬網絡邊界 虛擬路由器 分布式 單點故障

0 引 言

隨著虛擬化技術的快速發展，云計算在大型數據中心網絡中已經得到大規模應用，對網絡的性能要求和安全要求也越來越高。與服務器虛擬化類似，網絡虛擬化技術的發展使得云服務提供商能將物理網絡設備抽象成虛擬的網絡設備提供給租戶，并允許每個租戶創建自己的虛擬網絡，結合租戶申請的虛擬機資源定義網絡拓撲，對虛擬網絡進行管理[1]。

對云服務提供商而言，虛擬網絡的基本需求是：允許網絡中多租戶共存，即在同一套物理網絡環境中，支持創建多套具備獨立服務模型、拓撲和IP地址空間的租戶虛擬網絡[2]。而從租戶的角度來看，不僅要求能夠創建一套獨立的虛擬網絡，在其中運行業務，而且要求確保租戶數據的隔離和安全性，保證數據不會遭到來自其他租戶以及外部網絡的非法訪問。

在傳統物理網絡環境中，不同網絡之間的隔離通常由部署在網絡邊界處的路由器和防火墻完成。同樣，虛擬網絡的隔離也應當在虛擬網絡的邊界處實現。但相比之下，虛擬網絡環境中的網絡邊界更加模糊，缺乏明確的定義，因此為租戶虛擬網絡提供路由及防火墻服務也更為復雜。同時，租戶虛擬網絡到實際物理網絡拓撲的映射是相對分散的，同一租戶控制的虛擬機很可能分布在多臺物理服務器上，可見租戶虛擬網絡的邊界可以細化到各物理服務器的邊緣，需要更加細粒度的網絡隔離。

結合典型的虛擬網絡應用場景來看，虛擬網絡中的邊界可分為以下幾類，如圖1所示：

(1) 不同租戶的虛擬網絡之間的邊界；

(2) 同一租戶虛擬網絡下，不同虛擬子網之間的邊界；

(3) 租戶虛擬網絡與外網之間的邊界。

圖1 虛擬網絡的邊界分類

在當前主流的開源云平臺中，已經有針對虛擬網絡安全隔離的解決方案，通過為租戶網絡創建虛擬路由及防火墻的方式實現虛擬網絡的安全隔離[3]。在現有架構下，所有租戶的虛擬路由器及防火墻設備都位于同一物理節點，涉及租戶網絡邊界的流量都被集中到該節點上進行處理，存在引發單點故障的隱患，同時也增加了虛擬機通信的網絡延遲。

1 相關工作

1.1 相關研究進展

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

可見學術界多數研究的重點關注集成、管理和擴展中間件部署的能力和虛擬化I/O問題，旨在提升數據包通過虛擬機與物理機之間的速率，提高中間件平臺的可用性。此外，CloudMB項目[6]關注虛擬網絡服務初始放置的優化，期望在物理拓撲和流分布可知的情況下，通過啟發式算法計算出虛擬網絡服務部署的合理位置，避免可能導致性能瓶頸的機架間流量。文獻[2，10]都為多租戶提供獨立的IP地址空間，采用數據包封裝技術來區分并隔離不同租戶。

而在工業界，針對虛擬網絡層面的安全隔離問題，有不少解決方案試圖通過定義虛擬網絡的邊界，并在相應邊界物理節點部署虛擬路由及防火墻的方式來實現隔離。云計算環境中提供的服務范圍越來越廣，防火墻即服務的概念也已產生，虛擬防火墻及路由器以服務的方式提供給租戶，租戶可以為自己的子網申請虛擬路由器及防火墻，并為虛擬網絡的防火墻添加策略和規則。

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

而在主流開源云平臺(如OpenStack)[3]中仍然采取集中部署虛擬路由器及防火墻的方式，即專設一臺服務器(或專用硬件網絡設備)作為網絡節點，在該網絡節點上為每個租戶部署虛擬路由器，并配置虛擬防火墻作用在虛擬路由器上。這種部署方式的思路就是將虛擬網絡的邊界集中到統一的節點，所有涉及租戶網絡邊界的流量都被集中到網絡節點上進行處理。但這樣的實現方式容易引發單點故障，下一節將具體分析其中存在的問題。

1.2 集中式虛擬路由的問題

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

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

圖2 OpenStack虛擬網絡隔離的路由模式圖

在同租戶不同子網邊界方面：由于云計算的一大特點是東西向流量增大，業務運行時，跨物理機的虛擬機之間經常進行通信。在現有的網絡架構下，跨子網的網絡通信流量都需要通過網絡節點上的虛擬路由器進行轉發。圖2中深色箭頭對應的路徑是租戶A不同子網下的虛擬機之間通信時的數據包路徑，其中位于子網1的虛擬機VM1與位于子網2的虛擬機VM2通信，數據包經過位于網絡節點的虛擬路由器和虛擬防火墻。

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

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

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

2 虛擬網絡隔離的分布式實現

2.1 總體架構

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

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

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

圖3 分布式實現虛擬網絡隔離的路由模式

圖4是本文分布式路由的物理架構圖。本文采用的虛擬交換機為Open vSwitch，部署在所有物理服務器上，其中虛擬交換機br-int連接Hypervisor上的所有虛擬機。而虛擬交換機br-tun作為處理VXLAN協議的端點VTEP(VXLAN-Tunnel-EndPoint)，對虛擬機出物理服務器的流量進行VXLAN封裝，通過數據網網卡轉發；對于接收到的VXLAN數據包，則進行解封裝處理，轉發給連接虛擬機的br-int處理。此外，虛擬交換機br-ex的作用是連接外網網卡，能夠處理虛擬機與外網之間的通信。

圖4 分布式虛擬網絡隔離的物理架構

虛擬路由器利用網絡命名空間技術配置，主要由子網網關端口構成，這些子網網關端口可在虛擬交換機上配置對應端口，起到連接虛擬交換機和虛擬路由器的作用。本文部署虛擬路由器的模式是：根據租戶虛擬機的分布，在所有包含該租戶虛擬機的物理機上為配置分布式虛擬路由器，這些分布式虛擬路由器包含租戶下所有子網的網關端口。

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

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

2.2 虛擬網絡安全隔離分析

引言中已經結合實際應用場景，將虛擬網絡的邊界分為三類，圖1列舉了這三類網絡邊界。本文的分布式虛擬網絡隔離充分考慮了這三類虛擬網絡邊界，并有針對性地采用了相應的網絡虛擬化技術。本節分別分析本文的分布式實現方案在這三類邊界場景下的實際流程和相關技術。

2.2.1 多租戶網絡之間的邊界

網絡虛擬化技術使得云服務提供商能夠將一套物理網絡虛擬化成多套虛擬網絡，分別提供給不同的租戶。從租戶的角度考慮，一個重要的需求就是確保租戶網絡的安全隔離盒獨立性，防止自己的數據遭到來自其他租戶的非法訪問。

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

同一計算節點上可能包含多位租戶所創建的虛擬路由器，連接各自的虛擬子網與外網。由于這些虛擬路由器之間默認沒有關聯，未配置相關聯的路由規則，因此租戶之間的虛擬網絡無法相互訪問通信，從而達到不同租戶虛擬網絡邊界安全隔離的目的。

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

2.2.2 同租戶不同子網之間的邊界

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

? VLAN規模限制

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

? 多租戶支持

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

? 交換機的虛擬機數量

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

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

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

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

圖5 跨子網虛擬機通信場景

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

在原先的集中式路由模式下，VM1-1發出的數據包在本地沒有匹配到路由規則，需要轉發到網絡節點上的虛擬路由進行處理，具體步驟如下：

1) VM1-1發出數據包，目的地址為VM2-2；

2) 計算節點1的虛擬交換機br-int收到數據包，加上子網1的內部VLAN標簽后轉發到VTEP(br-tun)；

3) 計算節點1的br-tun將內部VLAN標簽轉換為子網1對應的VXLAN標識VNI，并從數據網卡通過VXLAN隧道把數據包轉發到網絡節點；

4) 網絡節點的VTEP(br-tun)對數據包進行解封裝處理，將子網1的VXLAN標識轉換為內部VLAN標簽，并轉發到虛擬交換機br-int；

5) 網絡節點的br-int把數據包交到虛擬路由處理，因為目的地址屬于子網2，根據路由規則，數據包通過子網2網關端口轉發，回到br-int；

6) 網絡節點的br-int把數據包加上子網2的內部VLAN標簽，轉發到br-tun；

7) 網絡節點的br-tun將內部VLAN標簽轉換為子網2對應的VXLAN標識VNI，并通過VXLAN隧道把數據包轉發到計算節點2；

8) 計算節點2的VTEP(br-tun)對數據包進行解封裝處理，將子網2的VXLAN標識轉換為內部VLAN標簽，并轉發到虛擬交換機br-int；

9) 計算節點2的br-int將數據包轉發到VM2-2對應端口，VM2-2接收到數據包。

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

1) VM1-1發出數據包，目的IP地址為VM2-2；

2) 計算節點1的虛擬交換機br-int收到數據包，把數據包交到分布式虛擬路由器處理，根據路由規則，將目的地址為VM2-2的數據包通過子網2網關端口轉發，回到br-int；

3) 計算節點1的br-int把數據包加上子網2的內部VLAN標簽，轉發到VTEP(br-tun)；

4) 計算節點1的br-tun將內部VLAN標簽轉換為子網2對應的VXLAN標識VNI，從數據網卡通過VXLAN隧道把數據包轉發到計算節點2；

5) 計算節點2的br-tun對數據包進行解封裝處理，將子網2的VXLAN標識轉換為內部VLAN標簽，并轉發到虛擬交換機br-int；

6) 計算節點2的br-int將數據包轉發到VM2-2對應端口，VM2-2接收到數據包。

以上通信步驟直接在計算節點間進行，無需經過網絡節點處理。

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

2.2.3 租戶網絡與外網之間的邊界

這里以虛擬機VM1-1與外部網絡的通信為例，對比集中式路由與分布式路由。子網1的網關記為GW1，虛擬路由器上的外網網關記為EG1。

OpenStack原有的實現方式需要通過網絡節點上的虛擬路由器，具體步驟如下：

1) VM1-1發出數據包，目的地址為外網的IP地址；

2) 計算節點1的虛擬交換機br-int收到數據包，加上子網1的內部VLAN標簽后轉發到VTEP(br-tun)；

3) 計算節點1的br-tun將內部VLAN標簽轉換為子網1對應的VXLAN標識VNI，并從數據網卡通過VXLAN隧道把數據包轉發到網絡節點；

4) 網絡節點的VTEP(br-tun)對數據包進行解封裝處理，將子網1的VXLAN標識轉換為內部VLAN標簽，并轉發到虛擬交換機br-int；

5) 網絡節點的br-int把數據包交到虛擬路由處理，因為目的地址屬于外部網絡，使用NAT規則把數據包源地址改為外網網關端口EG1的地址；并根據路由規則，從EG1轉發到外網虛擬交換機(br-ex)上；

6) 網絡節點的br-ex通過外網網卡把數據包發送到外網。

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

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

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

1) VM1-1發出數據包，目的地址為外網的IP地址；

2) 虛擬交換機br-int收到數據包，把數據包交到分布式虛擬路由器處理，在租戶虛擬路由的網絡命名空間中，配置了基于iptables的NAT規則，將數據包源地址從VM1-1的私有IP地址轉換到外網網關EG1的IP地址，如：

iptables-A POSTROUTING-s 192.168.30.0/24-j SNAT-to-source 10.10.88.51

即數據包源地址轉換為外部IP(如10.10.88.51)；

3) 根據虛擬路由的默認規則，確定數據包從外網網關EG1轉發到外網虛擬交換機(br-ex)上；

4) 網絡節點的br-ex通過外網網卡把數據包發送到外網。

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

圖6 虛擬機與外網的通信場景

3 部署與實驗

3.1 實驗環境

本文的實驗環境部署在4臺物理服務器上，搭建了基于OpenStack Juno版本的環境。Dell服務器的操作系統為CentOS 7，多網卡，其中控制節點使用單網卡(管理網)，計算節點和網絡節點使用三網卡(管理網、數據網、外網)，管理網網段10.10.82.0/24，數據網網段10.10.87.0/24，外網網段10.10.88.0/24。

根據本文的分布式實現虛擬網絡隔離方式，在這套實驗環境中通過租戶admin創建了一套基于本文分布式架構的虛擬網絡，包括兩個子網和4臺虛擬機，虛擬機的詳細信息(所在物理機、所在子網)見表1所示。

表1 實驗環境虛擬機分布信息

租戶admin的兩個子網IP端分別為192.168.30.0/24和192.168.40.0/24，對應VXLAN標識分別為5和7，兩個計算節點上都有兩臺屬于兩個不同子網的虛擬機。

根據圖4的物理架構，本文的實驗環境運用Linux的網絡命名空間技術，在兩個計算節點上都創建租戶admin的分布式虛擬路由器和防火墻，這兩個虛擬路由器在配置上是相同的，端口包含兩個子網的網關(IP地址分別為192.168.30.1和192.168.40.1)，以及外網網關(IP地址10.10.88.51)。

同樣，通過租戶admin利用OpenStack原有的方式也創建一套類似的虛擬網絡，在配置與虛擬機分布方面與表1相同，便于實驗對照。

3.2 網絡延遲對比

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

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

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

圖7是本文針對三類不同場景的網絡延遲實驗結果對比圖。柱狀圖中白色表示OpenStack原有方式下的網絡延遲，陰影部分表示本文采用的分布式架構下的網絡延遲。可以看到在三類不同場景中，分布式路由模式能有效降低虛擬機的網絡延遲。

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

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

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

4 結 語

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

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

[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。嚴立宇，碩士生，主研領域：信息安全，網絡虛擬化。祖立軍，工程師。葉家煒，工程師。周雍愷，博士生。吳承榮，副教授。

TP393

A

10.3969/j.issn.1000-386x.2016.11.022