摘  要： 基于SDN技術(shù)的虛擬租戶(hù)網(wǎng)絡(luò)（VTN）能夠使得數(shù)據(jù)中心網(wǎng)絡(luò)向多個(gè)租戶(hù)提供互相隔離的虛擬網(wǎng)絡(luò)。VTN提供了VLAN映射、端口映射用于將虛擬網(wǎng)絡(luò)節(jié)點(diǎn)與物理網(wǎng)絡(luò)節(jié)點(diǎn)進(jìn)行映射。其中VLAN映射需要對(duì)每個(gè)主機(jī)配置VLAN id，增加了映射的復(fù)雜性；端口映射時(shí)一旦出現(xiàn)交換機(jī)端口故障便不能成功映射。為解決上述問(wèn)題，本文提出了基于MAC地址映射方法，即通過(guò)主機(jī)的MAC地址直接與虛擬節(jié)點(diǎn)進(jìn)行映射。通過(guò)搭建OpenDaylight實(shí)驗(yàn)平臺(tái)驗(yàn)證了該方法的可行性。結(jié)果表明，該方法能夠解決以上映射中的不足，簡(jiǎn)化了VTN網(wǎng)絡(luò)與底層網(wǎng)絡(luò)映射配置，提高了VTN的性能。

　　關(guān)鍵詞： SDN；VTN；VLAN映射；端口映射；MAC地址

0 引言

　　隨著云服務(wù)規(guī)模的擴(kuò)大，云計(jì)算服務(wù)提供商需要向大量租戶(hù)提供相互隔離的、具有質(zhì)量保證的虛擬網(wǎng)絡(luò)，即實(shí)現(xiàn)網(wǎng)絡(luò)即服務(wù)（NaaS）模式[1]。傳統(tǒng)構(gòu)建虛擬網(wǎng)絡(luò)具有一定的局限性。其中VLAN具有個(gè)數(shù)限制以及配置VLAN的交換機(jī)需要處理大量的虛擬機(jī)使得轉(zhuǎn)發(fā)表變得非常巨大[2]。IP覆蓋方法如VXLAN[3]、GRE方法[4]，這些方法在新增虛擬機(jī)時(shí)，虛擬交換機(jī)就要更新，缺少糾錯(cuò)工具使得覆蓋網(wǎng)絡(luò)管理復(fù)雜。

　　基于SDN技術(shù)的虛擬租戶(hù)網(wǎng)絡(luò)（Virtual Tenant Network，VTN）能夠很好地使得數(shù)據(jù)中心向多個(gè)租戶(hù)提供互相隔離的虛擬網(wǎng)絡(luò)，借助于SDN控制器掌握全網(wǎng)網(wǎng)絡(luò)拓?fù)浔阌谶M(jìn)行集中化控制[5]。解決虛擬網(wǎng)絡(luò)與物理網(wǎng)絡(luò)的映射問(wèn)題是實(shí)現(xiàn)VTN的核心環(huán)節(jié)，也是本文的研究重點(diǎn)。

　　目前對(duì)VTN提供的端口映射、VLAN映射的研究相對(duì)成熟。參考文獻(xiàn)[5]提出的端口映射是指通過(guò)物理交換機(jī)的端口與虛擬網(wǎng)絡(luò)的虛擬交換機(jī)接口進(jìn)行映射，但網(wǎng)絡(luò)易受到物理交換機(jī)端口故障或主機(jī)入網(wǎng)位置變動(dòng)的影響。參考文獻(xiàn)[6]提出的VLAN映射是指根據(jù)數(shù)據(jù)流的VLAN id與虛擬交換機(jī)進(jìn)行映射，但需要對(duì)每個(gè)主機(jī)配置VLAN id且VLAN存在個(gè)數(shù)限制。

　　本文在現(xiàn)有映射技術(shù)的基礎(chǔ)上，針對(duì)基于SDN技術(shù)的虛擬租戶(hù)網(wǎng)絡(luò)技術(shù)，提出了基于主機(jī)MAC地址進(jìn)行虛擬網(wǎng)絡(luò)的映射，并對(duì)基于主機(jī)MAC地址的映射方案進(jìn)行設(shè)計(jì)以及實(shí)現(xiàn)。實(shí)驗(yàn)結(jié)果表明，基于MAC地址的映射機(jī)制具有一定的可行性，解決了物理交換機(jī)故障對(duì)網(wǎng)絡(luò)的影響，簡(jiǎn)化了VTN網(wǎng)絡(luò)與底層網(wǎng)絡(luò)映射的配置，提高了VTN的性能。

1 基于SDN的VTN技術(shù)

　　1.1 VTN簡(jiǎn)介

　　虛擬租戶(hù)網(wǎng)絡(luò)（VTN）所解決的場(chǎng)景就是現(xiàn)在數(shù)據(jù)中心網(wǎng)絡(luò)的場(chǎng)景。不同租戶(hù)需要不同的網(wǎng)絡(luò)配置，運(yùn)行不同的應(yīng)用程序。而這些需求將在同一個(gè)物理網(wǎng)絡(luò)中實(shí)現(xiàn)，達(dá)到資源的共用。如果不建立虛擬網(wǎng)絡(luò)，那么在同一物理網(wǎng)絡(luò)中分別針對(duì)不同租戶(hù)進(jìn)行配置和管理，情況將變得十分復(fù)雜[7]。

　　本節(jié)主要介紹了VTN的網(wǎng)絡(luò)架構(gòu)。租戶(hù)將通過(guò)VTN應(yīng)用程序建立所需的虛擬網(wǎng)絡(luò)，該虛擬網(wǎng)絡(luò)能夠自動(dòng)與物理網(wǎng)絡(luò)進(jìn)行映射。其中與物理網(wǎng)絡(luò)映射是VTN的核心問(wèn)題，也是本文研究的重點(diǎn)。

　　如1圖所示，VTN由兩個(gè)關(guān)鍵部分組成：VTN Coordinator和VTN manager。其中VTN manager向VTN Coordinator提供了建立虛擬網(wǎng)絡(luò)的APIs。該虛擬網(wǎng)絡(luò)由虛擬節(jié)點(diǎn)、虛擬鏈路、虛擬接口組成，如表1所示。

　　VTN協(xié)調(diào)組件向VTN應(yīng)用程序提供REST API，供用戶(hù)建立虛擬網(wǎng)絡(luò)，當(dāng)虛擬網(wǎng)絡(luò)跨越多個(gè)SDN控制器網(wǎng)絡(luò)時(shí)，支持多個(gè)控制器之間的合作配置，支持動(dòng)態(tài)添加控制器和刪除控制器。

　　1.2 VTN網(wǎng)絡(luò)與物理網(wǎng)絡(luò)映射

　　一旦租戶(hù)通過(guò)調(diào)用VTN接口建立虛擬網(wǎng)絡(luò)，該虛擬網(wǎng)絡(luò)就能夠與物理網(wǎng)絡(luò)進(jìn)行映射，VTN通過(guò)這些映射關(guān)系調(diào)用SDN控制器routing功能接口計(jì)算節(jié)點(diǎn)間的轉(zhuǎn)發(fā)路徑，然后告訴SDN控制器的forwarding rules轉(zhuǎn)發(fā)規(guī)則功能模塊添加什么樣的流表，并通過(guò)SDN控制協(xié)議向各個(gè)交換機(jī)下發(fā)轉(zhuǎn)發(fā)規(guī)則。

　　VTN映射分為兩個(gè)方面：虛擬節(jié)點(diǎn)映射以及虛擬鏈路映射。VTN的鏈路映射問(wèn)題由SDN控制器決定，SDN控制器掌握全網(wǎng)網(wǎng)絡(luò)拓?fù)湟约百Y源信息，根據(jù)自身的路徑計(jì)算功能，指定節(jié)點(diǎn)之間的路徑。因此本文只討論VTN的節(jié)點(diǎn)映射問(wèn)題。目前VTN節(jié)點(diǎn)映射方法包括以下兩種：

　?。?）VLAN映射：利用網(wǎng)包的VLAN id與vBridge進(jìn)行映射。

　?。?）端口映射：利用網(wǎng)包到達(dá)的物理交換機(jī)號(hào)、端口號(hào)、網(wǎng)包的VLAN號(hào)（如果沒(méi)有劃分VLAN，則VLAN id默認(rèn)為0）與虛擬網(wǎng)絡(luò)中的虛擬節(jié)點(diǎn)vBridge的接口進(jìn)行映射。

　　這些映射配置完成后，VTN manager存儲(chǔ)這些映射關(guān)系，判斷數(shù)據(jù)流所屬的虛擬網(wǎng)絡(luò)，并按照相應(yīng)的虛擬網(wǎng)絡(luò)轉(zhuǎn)發(fā)規(guī)則進(jìn)行轉(zhuǎn)發(fā)。

　　圖2所示為虛擬交換機(jī)通過(guò)VLAN映射、端口映射與底層物理網(wǎng)絡(luò)的交換機(jī)進(jìn)行映射。

　　通過(guò)VLAN映射與端口映射都能夠使物理交換機(jī)與虛擬交換機(jī)相對(duì)應(yīng)，但都具有一定的缺點(diǎn)。VLAN映射的缺點(diǎn)是每個(gè)主機(jī)都要進(jìn)行VLAN的配置，且VLAN有個(gè)數(shù)限制，使得網(wǎng)絡(luò)容量受限，不易擴(kuò)展。端口映射的缺點(diǎn)是當(dāng)虛擬網(wǎng)絡(luò)的數(shù)量和規(guī)模增大時(shí)，端口映射表巨大，而且該種映射配置屬于靜態(tài)配置，一旦與物理交換機(jī)相連的主機(jī)位置改變或者物理交換機(jī)發(fā)生故障都會(huì)相應(yīng)地影響虛擬網(wǎng)絡(luò)的可靠性和安全性。

　　為了改善以上映射的不足，本文提出基于MAC地址的映射。

2 設(shè)計(jì)與實(shí)現(xiàn)

　　2.1 MAC地址映射模塊設(shè)計(jì)目標(biāo)

　　MAC地址映射，就是根據(jù)主機(jī)的MAC地址與虛擬交換機(jī)vBridge進(jìn)行映射。MAC地址映射過(guò)程如下：

　?。?）與主機(jī)直接接入的物理交換機(jī)第一次收到來(lái)自主機(jī)的數(shù)據(jù)流時(shí)，會(huì)將其封裝在packet-in中發(fā)給控制器。

　　（2）控制器根據(jù)VTN manager中存儲(chǔ)的映射關(guān)系，判斷該數(shù)據(jù)流屬于哪個(gè)虛擬網(wǎng)絡(luò)，根據(jù)該虛擬網(wǎng)絡(luò)的路徑規(guī)則以流表的形式下發(fā)到物理交換機(jī)上。

　　其中虛擬網(wǎng)絡(luò)的路徑是由VTN manager根據(jù)映射關(guān)系調(diào)用SDN控制器提供的路徑計(jì)算routing功能來(lái)計(jì)算，并把計(jì)算結(jié)果通過(guò)API調(diào)用SDN控制器提供的forwarding rules模塊，添加相應(yīng)的流表信息，然后forwarding rules模塊把要求發(fā)給相對(duì)應(yīng)的協(xié)議插件（protocol plugin），由協(xié)議插件打包信息發(fā)給底層交換機(jī)。

　?。?）當(dāng)交換機(jī)收到轉(zhuǎn)發(fā)規(guī)則后，對(duì)該主機(jī)的數(shù)據(jù)流進(jìn)行轉(zhuǎn)發(fā)。具體流程如圖3所示。

　　因此要實(shí)現(xiàn)MAC地址映射，VTN manager需要添加如下功能：

　?。?）獲取主機(jī)信息，即SDN網(wǎng)絡(luò)下主機(jī)的MAC地址。

　　（2）記錄分配給虛擬網(wǎng)絡(luò)的主機(jī)MAC地址信息以及未分配的主機(jī)MAC地址。

　?。?）為了防止其中一個(gè)已經(jīng)分配的主機(jī)再次分配給新的虛擬網(wǎng)絡(luò)，需要對(duì)主機(jī)進(jìn)行標(biāo)記。

　　（4）在已有的MapType中添加MacMap，即VTN manager可實(shí)現(xiàn)的三種類(lèi)型的映射。前兩種是端口映射、VLAN映射。

　?。?）實(shí)現(xiàn)MacMap啟動(dòng)程序。

　　當(dāng)MacMap機(jī)制啟動(dòng)后，屬于VTN網(wǎng)絡(luò)的主機(jī)向Openflow交換機(jī)發(fā)送數(shù)據(jù)包，VTN管理組件通過(guò)控制器向該Openflow交換機(jī)下發(fā)流表轉(zhuǎn)發(fā)規(guī)則，虛擬交換機(jī)vBridge具有自學(xué)習(xí)終端信息的能力，并配置MAC轉(zhuǎn)發(fā)表。最終使得VTN網(wǎng)絡(luò)中的主機(jī)能夠互相到達(dá)。

　　2.2 MAC地址模塊實(shí)現(xiàn)

　　本文在研究Opendaylight開(kāi)源控制器功能以及VTN manager功能基礎(chǔ)上，實(shí)現(xiàn)了基于MAC地址虛擬網(wǎng)絡(luò)資源與物理網(wǎng)絡(luò)資源的映射。其中Opendaylight控制器提供了拓?fù)涔芾怼outing路由計(jì)算、forwarding rules流表添加模塊、Arphandler模塊等功能[8]；VTN manager向用戶(hù)提供了構(gòu)建虛擬網(wǎng)絡(luò)的資源，包括虛擬交換機(jī)、虛擬鏈路等，存儲(chǔ)用戶(hù)的物理資源與虛擬資源的映射信息，根據(jù)這些映射信息通過(guò)API調(diào)用routing功能接口，計(jì)算相應(yīng)的路徑，并通過(guò)控制器中的流表添加模塊添加相應(yīng)的流表，最后打包給底層物理交換機(jī)[9]。

　　其中，在VTN manager中實(shí)現(xiàn)基于MAC地址映射需要實(shí)現(xiàn)如下功能：

　?。?）獲取SDN網(wǎng)絡(luò)下主機(jī)信息，該功能通過(guò)調(diào)用SDN控制器提供的HostTrack功能接口實(shí)現(xiàn)。部分實(shí)現(xiàn)代碼如下：

　　public class host {

　　public void GetHost（） throws IOException， JSONException{

　　JSONObject response=

　　client.json（odl.resolve（"hosttracker/default/hosts/active"））.toObject（）；//解析控制器中hosttrack的信息

　　JSONArray data=response.getJSONArray

　?。?quot;hostConfig"）；

　?。?）因?yàn)槲锢斫粨Q機(jī)處理的是幀，因此獲取主機(jī)信息后，需要記錄所有的主機(jī)MAC地址。然后對(duì)屬于或不屬于VTN網(wǎng)絡(luò)的主機(jī)進(jìn)行記錄，創(chuàng)建MacMapConfig類(lèi)，該類(lèi)作為MacMap機(jī)制的配置信息，指出了已經(jīng)分配的主機(jī)和沒(méi)有進(jìn)行分配的主機(jī)。通過(guò)列表來(lái)實(shí)現(xiàn)部分代碼如下：

　　Public class MacMapConfig implements Serializable

　　{Private final Set<DataLinkHost>allowedHosts=

　　New HashSet<DataLinkHost>（）；//分配的主機(jī)

　　Private final Set<DataLinkHost>deniedHosts=

　　New HashSet<DataLinkHost>（）；//未分配的主機(jī)

　　（3）應(yīng)用MacMapPortBusyLog類(lèi)來(lái)記錄該主機(jī)有沒(méi)有其他的映射。

　　Public final class MacMapPortBusyLog{

　　Private final MacVlan host；

　　Private final NodeConnector port；

　　//與主機(jī)相連的交換機(jī)端口

　　Private final MapReferenceotherMap；

　　//判斷該端口有無(wú)別的映射

　?。?）在VTN manager提供的MapType中添加MacMap。部分代碼如下：

　　Enummaptype

　　{portmapping，vlanmapping，macmapping}

　?。?）實(shí)現(xiàn)MacMap啟動(dòng)程序。當(dāng)與主機(jī)直接接入的物理交換機(jī)端口已經(jīng)映射，且該端口不存在其他映射則可啟動(dòng)。部分代碼如下：

　　Public MacMapActivation（NodeConnectorport，PortMapreleased，boolean activated）{...}

　　以上功能是MacMap機(jī)制的主要功能，除此之外還需要其他一些補(bǔ)充，限于篇幅不再贅述。將MacMap一系列代碼結(jié)合VTNmanager功能以及Opendaylight控制器，可實(shí)現(xiàn)簡(jiǎn)單的MacMap機(jī)制，最終以接口的形式供租戶(hù)進(jìn)行調(diào)用，即通過(guò)調(diào)用MacMap機(jī)制使得虛擬節(jié)點(diǎn)與物理網(wǎng)絡(luò)設(shè)備進(jìn)行映射。

3 測(cè)試與分析

　　3.1 測(cè)試環(huán)境

　　服務(wù)器端：物理主機(jī)上運(yùn)行ubuntu12.04系統(tǒng)，配置Java環(huán)境，安裝Opendaylight控制器，安裝VTN Manager。數(shù)據(jù)轉(zhuǎn)發(fā)網(wǎng)絡(luò)采用Mininet進(jìn)行模擬[10]。

　　客戶(hù)端：物理主機(jī)上運(yùn)行ubuntu12.04系統(tǒng)，配置Java環(huán)境，安裝myeclipse。其中myeclipse中導(dǎo)入了必要的控制器jar包、VTN manager.jar包以及MacMap機(jī)制下的代碼。

　　3.2 測(cè)試步驟與結(jié)果分析

　　（1）在服務(wù)器端運(yùn)行Opendaylight控制器，運(yùn)行VTN manager并用Mininet創(chuàng)建轉(zhuǎn)發(fā)網(wǎng)絡(luò)（包括4臺(tái)主機(jī)、3臺(tái)openflow交換機(jī)），關(guān)閉Opendaylight控制器默認(rèn)的網(wǎng)絡(luò)轉(zhuǎn)發(fā)應(yīng)用，使得四臺(tái)主機(jī)彼此不可達(dá)。建立網(wǎng)絡(luò)的命令如下：

　　Sudomn--controller=remote，ip=<controller-ip>--topotree，2

　?。?）配置網(wǎng)絡(luò)使得客戶(hù)端與服務(wù)器端可連接，通過(guò)運(yùn)行myeclipse，打開(kāi)MacMap機(jī)制，使之運(yùn)行。通過(guò)調(diào)用控制器HostTrack功能接口得到四臺(tái)主機(jī)的MAC地址。

　?。?）在服務(wù)器端的終端輸入命令實(shí)現(xiàn)如下流程：

　　建立VTN1→在VTN中建立虛擬交換機(jī)vBridge1→建立MacMap。

　　即調(diào)用MacMap接口使得h1的MAC地址、h3的MAC地址與虛擬交換機(jī)vBridge進(jìn)行映射，如圖4所示。命令如下：

　　Curl-X PUT http：//localhost：8080/controller/nb/v2/vtn/default/vtns/Tenant1/vBridge1/macmap-d′{“host1mac”：{4e：3a：e0：40：2c：5b}，“host3mac”：{9e：3b：56：a7：4a：e7}}′

　　然后應(yīng)用mininet執(zhí)行h1和h3的ping操作。最終兩臺(tái)主機(jī)可以ping通，如圖5所示，h1和h3已被劃分在同一個(gè)VTN虛擬網(wǎng)絡(luò)中。

　　實(shí)驗(yàn)結(jié)果表明，VTN虛擬網(wǎng)絡(luò)可以通過(guò)指定的主機(jī)MAC地址使得與主機(jī)直接接入的物理交換機(jī)與虛擬交換機(jī)進(jìn)行映射，即使租戶(hù)的主機(jī)接入位置發(fā)生改變也不影響VTN網(wǎng)絡(luò)，使得租戶(hù)可以靈活接入網(wǎng)絡(luò)。由于不需要額外對(duì)端口進(jìn)行固定配置，簡(jiǎn)化了VTN manager的能力。由于獲取主機(jī)信息可直接通過(guò)調(diào)用控制器提供的功能接口，使得虛擬網(wǎng)絡(luò)與物理網(wǎng)絡(luò)之間的映射變得簡(jiǎn)單。同時(shí)網(wǎng)絡(luò)的容量也得到一定的提高。

4 結(jié)束語(yǔ)

　　本文通過(guò)研究基于SDN的虛擬租戶(hù)網(wǎng)絡(luò)VTN技術(shù)，分析了虛擬網(wǎng)絡(luò)與物理網(wǎng)絡(luò)之間的映射，提出了基于主機(jī)的MAC地址的映射方法，該方法解決了終端主機(jī)的移動(dòng)性問(wèn)題，對(duì)基于主機(jī)MAC地址的映射方案進(jìn)行了系統(tǒng)的描述，對(duì)MAC地址模塊進(jìn)行了技術(shù)實(shí)現(xiàn)。實(shí)驗(yàn)結(jié)果表明，所提出的基于MAC地址的映射方案具有一定的可行性，提高了VTN網(wǎng)絡(luò)的可靠性，簡(jiǎn)化了VTN映射機(jī)制。目前研究?jī)H限于在單SDN控制器下租戶(hù)網(wǎng)絡(luò)的建立，未來(lái)還需繼續(xù)研究在多租戶(hù)技術(shù)下基于MAC地址映射機(jī)制建立VTN虛擬網(wǎng)絡(luò)。

參考文獻(xiàn)

　　[1] KEMPF J， ZHANG Y， MISHRA R， et al. Zeppelin-a third generation data center network virtualization technology based on SDN and MPLS[C]. Cloud Networking （CloudNet）， 2013 IEEE 2nd International Conference on. IEEE， 2013：1-9.

　　[2] BARI M F， BOUTABA R， ESTEVES R， et al. Data center network virtualization： a survey[J]. Communications Surveys & Tutorials， IEEE， 2013，15（2）：909-928.

　　[3] KANG S H， KWAK J Y， LEE B Y， et al. The study on configuration of multi-tenant networks in SDN controller[C].Advanced Communication Technology （ICACT）， 2014 16th International Conference on， 2014：1223-1226.

　　[4] LARA A， KOLASANI A， RAMAMURTHY B. Network innovation using OpenFlow： a survey[J]. OmmnaonRvy& Oral， 2014， 16（1）：493-512.

　　[5] 陳琳，吳強(qiáng).基于SDN技術(shù)構(gòu)建數(shù)據(jù)中心虛擬網(wǎng)絡(luò)[J].互聯(lián)網(wǎng)天地，2013（1）：40-44.

　　[6] DAS S， SHARAFAT A R， PARULKAR G， et al. MPLS with a simple OPEN control plane[J]. Optical Fiber Communication Conference and Exposition（OFC/NFOEC），2011（10）：1-3.

　　[7] 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.

　　[8] CASADO M， KOPONEN T， RAMANATHAN R， et al. Virtualizing the network forwarding plane[C]. Proceedings of the Workshop on Programmable Routers for Extensible Services of Tomorrow， ACM， 2010： 8.

　　[9]  ELFERKOUSS O， CORREIA S， BEN A R， et al. Opendaylight： towards a model-driven SDN controller architecture[C]. Global Telecommunications Conference（GLOBECOM 2012）， IEEE， 2012：1-6.

　　[10] CHEN Z， DONG W， LI H， et al. Collaborative network security in multi-tenant data center for cloud computing[J]. Tsinghua Science and Technology， 2014，19（1）：82-94.