摘 要： 基于SDN技術(shù)的虛擬租戶網(wǎng)絡(luò)（VTN）能夠使得數(shù)據(jù)中心網(wǎng)絡(luò)向多個租戶提供互相隔離的虛擬網(wǎng)絡(luò)。VTN提供了VLAN映射、端口映射用于將虛擬網(wǎng)絡(luò)節(jié)點與物理網(wǎng)絡(luò)節(jié)點進行映射。其中VLAN映射需要對每個主機配置VLAN id，增加了映射的復(fù)雜性；端口映射時一旦出現(xiàn)交換機端口故障便不能成功映射。為解決上述問題，本文提出了基于MAC地址映射方法，即通過主機的MAC地址直接與虛擬節(jié)點進行映射。通過搭建OpenDaylight實驗平臺驗證了該方法的可行性。結(jié)果表明，該方法能夠解決以上映射中的不足，簡化了VTN網(wǎng)絡(luò)與底層網(wǎng)絡(luò)映射配置，提高了VTN的性能。
關(guān)鍵詞： SDN；VTN；VLAN映射；端口映射；MAC地址
0 引言
隨著云服務(wù)規(guī)模的擴大，云計算服務(wù)提供商需要向大量租戶提供相互隔離的、具有質(zhì)量保證的虛擬網(wǎng)絡(luò)，即實現(xiàn)網(wǎng)絡(luò)即服務(wù)（NaaS）模式[1]。傳統(tǒng)構(gòu)建虛擬網(wǎng)絡(luò)具有一定的局限性。其中VLAN具有個數(shù)限制以及配置VLAN的交換機需要處理大量的虛擬機使得轉(zhuǎn)發(fā)表變得非常巨大[2]。IP覆蓋方法如VXLAN[3]、GRE方法[4]，這些方法在新增虛擬機時，虛擬交換機就要更新，缺少糾錯工具使得覆蓋網(wǎng)絡(luò)管理復(fù)雜。
基于SDN技術(shù)的虛擬租戶網(wǎng)絡(luò)（Virtual Tenant Network，VTN）能夠很好地使得數(shù)據(jù)中心向多個租戶提供互相隔離的虛擬網(wǎng)絡(luò)，借助于SDN控制器掌握全網(wǎng)網(wǎng)絡(luò)拓撲便于進行集中化控制[5]。解決虛擬網(wǎng)絡(luò)與物理網(wǎng)絡(luò)的映射問題是實現(xiàn)VTN的核心環(huán)節(jié)，也是本文的研究重點。
目前對VTN提供的端口映射、VLAN映射的研究相對成熟。參考文獻[5]提出的端口映射是指通過物理交換機的端口與虛擬網(wǎng)絡(luò)的虛擬交換機接口進行映射，但網(wǎng)絡(luò)易受到物理交換機端口故障或主機入網(wǎng)位置變動的影響。參考文獻[6]提出的VLAN映射是指根據(jù)數(shù)據(jù)流的VLAN id與虛擬交換機進行映射，但需要對每個主機配置VLAN id且VLAN存在個數(shù)限制。
本文在現(xiàn)有映射技術(shù)的基礎(chǔ)上，針對基于SDN技術(shù)的虛擬租戶網(wǎng)絡(luò)技術(shù)，提出了基于主機MAC地址進行虛擬網(wǎng)絡(luò)的映射，并對基于主機MAC地址的映射方案進行設(shè)計以及實現(xiàn)。實驗結(jié)果表明，基于MAC地址的映射機制具有一定的可行性，解決了物理交換機故障對網(wǎng)絡(luò)的影響，簡化了VTN網(wǎng)絡(luò)與底層網(wǎng)絡(luò)映射的配置，提高了VTN的性能。
1 基于SDN的VTN技術(shù)
1.1 VTN簡介
虛擬租戶網(wǎng)絡(luò)（VTN）所解決的場景就是現(xiàn)在數(shù)據(jù)中心網(wǎng)絡(luò)的場景。不同租戶需要不同的網(wǎng)絡(luò)配置，運行不同的應(yīng)用程序。而這些需求將在同一個物理網(wǎng)絡(luò)中實現(xiàn)，達到資源的共用。如果不建立虛擬網(wǎng)絡(luò)，那么在同一物理網(wǎng)絡(luò)中分別針對不同租戶進行配置和管理，情況將變得十分復(fù)雜[7]。
本節(jié)主要介紹了VTN的網(wǎng)絡(luò)架構(gòu)。租戶將通過VTN應(yīng)用程序建立所需的虛擬網(wǎng)絡(luò)，該虛擬網(wǎng)絡(luò)能夠自動與物理網(wǎng)絡(luò)進行映射。其中與物理網(wǎng)絡(luò)映射是VTN的核心問題，也是本文研究的重點。
如1圖所示，VTN由兩個關(guān)鍵部分組成：VTN Coordinator和VTN manager。其中VTN manager向VTN Coordinator提供了建立虛擬網(wǎng)絡(luò)的APIs。該虛擬網(wǎng)絡(luò)由虛擬節(jié)點、虛擬鏈路、虛擬接口組成，如表1所示。
VTN協(xié)調(diào)組件向VTN應(yīng)用程序提供REST API，供用戶建立虛擬網(wǎng)絡(luò)，當虛擬網(wǎng)絡(luò)跨越多個SDN控制器網(wǎng)絡(luò)時，支持多個控制器之間的合作配置，支持動態(tài)添加控制器和刪除控制器。
1.2 VTN網(wǎng)絡(luò)與物理網(wǎng)絡(luò)映射
一旦租戶通過調(diào)用VTN接口建立虛擬網(wǎng)絡(luò)，該虛擬網(wǎng)絡(luò)就能夠與物理網(wǎng)絡(luò)進行映射，VTN通過這些映射關(guān)系調(diào)用SDN控制器routing功能接口計算節(jié)點間的轉(zhuǎn)發(fā)路徑，然后告訴SDN控制器的forwarding rules轉(zhuǎn)發(fā)規(guī)則功能模塊添加什么樣的流表，并通過SDN控制協(xié)議向各個交換機下發(fā)轉(zhuǎn)發(fā)規(guī)則。
VTN映射分為兩個方面：虛擬節(jié)點映射以及虛擬鏈路映射。VTN的鏈路映射問題由SDN控制器決定，SDN控制器掌握全網(wǎng)網(wǎng)絡(luò)拓撲以及資源信息，根據(jù)自身的路徑計算功能，指定節(jié)點之間的路徑。因此本文只討論VTN的節(jié)點映射問題。目前VTN節(jié)點映射方法包括以下兩種：
（1）VLAN映射：利用網(wǎng)包的VLAN id與vBridge進行映射。
（2）端口映射：利用網(wǎng)包到達的物理交換機號、端口號、網(wǎng)包的VLAN號（如果沒有劃分VLAN，則VLAN id默認為0）與虛擬網(wǎng)絡(luò)中的虛擬節(jié)點vBridge的接口進行映射。
這些映射配置完成后，VTN manager存儲這些映射關(guān)系，判斷數(shù)據(jù)流所屬的虛擬網(wǎng)絡(luò)，并按照相應(yīng)的虛擬網(wǎng)絡(luò)轉(zhuǎn)發(fā)規(guī)則進行轉(zhuǎn)發(fā)。
圖2所示為虛擬交換機通過VLAN映射、端口映射與底層物理網(wǎng)絡(luò)的交換機進行映射。
通過VLAN映射與端口映射都能夠使物理交換機與虛擬交換機相對應(yīng)，但都具有一定的缺點。VLAN映射的缺點是每個主機都要進行VLAN的配置，且VLAN有個數(shù)限制，使得網(wǎng)絡(luò)容量受限，不易擴展。端口映射的缺點是當虛擬網(wǎng)絡(luò)的數(shù)量和規(guī)模增大時，端口映射表巨大，而且該種映射配置屬于靜態(tài)配置，一旦與物理交換機相連的主機位置改變或者物理交換機發(fā)生故障都會相應(yīng)地影響虛擬網(wǎng)絡(luò)的可靠性和安全性。
為了改善以上映射的不足，本文提出基于MAC地址的映射。
2 設(shè)計與實現(xiàn)
2.1 MAC地址映射模塊設(shè)計目標
MAC地址映射，就是根據(jù)主機的MAC地址與虛擬交換機vBridge進行映射。MAC地址映射過程如下：
?。?）與主機直接接入的物理交換機第一次收到來自主機的數(shù)據(jù)流時，會將其封裝在packet-in中發(fā)給控制器。
（2）控制器根據(jù)VTN manager中存儲的映射關(guān)系，判斷該數(shù)據(jù)流屬于哪個虛擬網(wǎng)絡(luò)，根據(jù)該虛擬網(wǎng)絡(luò)的路徑規(guī)則以流表的形式下發(fā)到物理交換機上。
其中虛擬網(wǎng)絡(luò)的路徑是由VTN manager根據(jù)映射關(guān)系調(diào)用SDN控制器提供的路徑計算routing功能來計算，并把計算結(jié)果通過API調(diào)用SDN控制器提供的forwarding rules模塊，添加相應(yīng)的流表信息，然后forwarding rules模塊把要求發(fā)給相對應(yīng)的協(xié)議插件（protocol plugin），由協(xié)議插件打包信息發(fā)給底層交換機。
（3）當交換機收到轉(zhuǎn)發(fā)規(guī)則后，對該主機的數(shù)據(jù)流進行轉(zhuǎn)發(fā)。具體流程如圖3所示。
因此要實現(xiàn)MAC地址映射，VTN manager需要添加如下功能：
（1）獲取主機信息，即SDN網(wǎng)絡(luò)下主機的MAC地址。
?。?）記錄分配給虛擬網(wǎng)絡(luò)的主機MAC地址信息以及未分配的主機MAC地址。
?。?）為了防止其中一個已經(jīng)分配的主機再次分配給新的虛擬網(wǎng)絡(luò)，需要對主機進行標記。
?。?）在已有的MapType中添加MacMap，即VTN manager可實現(xiàn)的三種類型的映射。前兩種是端口映射、VLAN映射。
（5）實現(xiàn)MacMap啟動程序。
當MacMap機制啟動后，屬于VTN網(wǎng)絡(luò)的主機向Openflow交換機發(fā)送數(shù)據(jù)包，VTN管理組件通過控制器向該Openflow交換機下發(fā)流表轉(zhuǎn)發(fā)規(guī)則，虛擬交換機vBridge具有自學(xué)習(xí)終端信息的能力，并配置MAC轉(zhuǎn)發(fā)表。最終使得VTN網(wǎng)絡(luò)中的主機能夠互相到達。
2.2 MAC地址模塊實現(xiàn)
本文在研究Opendaylight開源控制器功能以及VTN manager功能基礎(chǔ)上，實現(xiàn)了基于MAC地址虛擬網(wǎng)絡(luò)資源與物理網(wǎng)絡(luò)資源的映射。其中Opendaylight控制器提供了拓撲管理、routing路由計算、forwarding rules流表添加模塊、Arphandler模塊等功能[8]；VTN manager向用戶提供了構(gòu)建虛擬網(wǎng)絡(luò)的資源，包括虛擬交換機、虛擬鏈路等，存儲用戶的物理資源與虛擬資源的映射信息，根據(jù)這些映射信息通過API調(diào)用routing功能接口，計算相應(yīng)的路徑，并通過控制器中的流表添加模塊添加相應(yīng)的流表，最后打包給底層物理交換機[9]。
其中，在VTN manager中實現(xiàn)基于MAC地址映射需要實現(xiàn)如下功能：
?。?）獲取SDN網(wǎng)絡(luò)下主機信息，該功能通過調(diào)用SDN控制器提供的HostTrack功能接口實現(xiàn)。部分實現(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"）；
?。?）因為物理交換機處理的是幀，因此獲取主機信息后，需要記錄所有的主機MAC地址。然后對屬于或不屬于VTN網(wǎng)絡(luò)的主機進行記錄，創(chuàng)建MacMapConfig類，該類作為MacMap機制的配置信息，指出了已經(jīng)分配的主機和沒有進行分配的主機。通過列表來實現(xiàn)部分代碼如下：
Public class MacMapConfig implements Serializable
{Private final Set<DataLinkHost>allowedHosts=
New HashSet<DataLinkHost>（）；//分配的主機
Private final Set<DataLinkHost>deniedHosts=
New HashSet<DataLinkHost>（）；//未分配的主機
?。?）應(yīng)用MacMapPortBusyLog類來記錄該主機有沒有其他的映射。
Public final class MacMapPortBusyLog{
Private final MacVlan host；
Private final NodeConnector port；
//與主機相連的交換機端口
Private final MapReferenceotherMap；
//判斷該端口有無別的映射
（4）在VTN manager提供的MapType中添加MacMap。部分代碼如下：
Enummaptype
{portmapping，vlanmapping，macmapping}
?。?）實現(xiàn)MacMap啟動程序。當與主機直接接入的物理交換機端口已經(jīng)映射，且該端口不存在其他映射則可啟動。部分代碼如下：
Public MacMapActivation（NodeConnectorport，PortMapreleased，boolean activated）{...}
以上功能是MacMap機制的主要功能，除此之外還需要其他一些補充，限于篇幅不再贅述。將MacMap一系列代碼結(jié)合VTNmanager功能以及Opendaylight控制器，可實現(xiàn)簡單的MacMap機制，最終以接口的形式供租戶進行調(diào)用，即通過調(diào)用MacMap機制使得虛擬節(jié)點與物理網(wǎng)絡(luò)設(shè)備進行映射。
3 測試與分析
3.1 測試環(huán)境
服務(wù)器端：物理主機上運行ubuntu12.04系統(tǒng)，配置Java環(huán)境，安裝Opendaylight控制器，安裝VTN Manager。數(shù)據(jù)轉(zhuǎn)發(fā)網(wǎng)絡(luò)采用Mininet進行模擬[10]。
客戶端：物理主機上運行ubuntu12.04系統(tǒng)，配置Java環(huán)境，安裝myeclipse。其中myeclipse中導(dǎo)入了必要的控制器jar包、VTN manager.jar包以及MacMap機制下的代碼。
3.2 測試步驟與結(jié)果分析
（1）在服務(wù)器端運行Opendaylight控制器，運行VTN manager并用Mininet創(chuàng)建轉(zhuǎn)發(fā)網(wǎng)絡(luò)（包括4臺主機、3臺openflow交換機），關(guān)閉Opendaylight控制器默認的網(wǎng)絡(luò)轉(zhuǎn)發(fā)應(yīng)用，使得四臺主機彼此不可達。建立網(wǎng)絡(luò)的命令如下：
Sudomn--controller=remote，ip=<controller-ip>--topotree，2
?。?）配置網(wǎng)絡(luò)使得客戶端與服務(wù)器端可連接，通過運行myeclipse，打開MacMap機制，使之運行。通過調(diào)用控制器HostTrack功能接口得到四臺主機的MAC地址。
?。?）在服務(wù)器端的終端輸入命令實現(xiàn)如下流程：
建立VTN1→在VTN中建立虛擬交換機vBridge1→建立MacMap。
即調(diào)用MacMap接口使得h1的MAC地址、h3的MAC地址與虛擬交換機vBridge進行映射，如圖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操作。最終兩臺主機可以ping通，如圖5所示，h1和h3已被劃分在同一個VTN虛擬網(wǎng)絡(luò)中。
實驗結(jié)果表明，VTN虛擬網(wǎng)絡(luò)可以通過指定的主機MAC地址使得與主機直接接入的物理交換機與虛擬交換機進行映射，即使租戶的主機接入位置發(fā)生改變也不影響VTN網(wǎng)絡(luò)，使得租戶可以靈活接入網(wǎng)絡(luò)。由于不需要額外對端口進行固定配置，簡化了VTN manager的能力。由于獲取主機信息可直接通過調(diào)用控制器提供的功能接口，使得虛擬網(wǎng)絡(luò)與物理網(wǎng)絡(luò)之間的映射變得簡單。同時網(wǎng)絡(luò)的容量也得到一定的提高。
4 結(jié)束語
本文通過研究基于SDN的虛擬租戶網(wǎng)絡(luò)VTN技術(shù)，分析了虛擬網(wǎng)絡(luò)與物理網(wǎng)絡(luò)之間的映射，提出了基于主機的MAC地址的映射方法，該方法解決了終端主機的移動性問題，對基于主機MAC地址的映射方案進行了系統(tǒng)的描述，對MAC地址模塊進行了技術(shù)實現(xiàn)。實驗結(jié)果表明，所提出的基于MAC地址的映射方案具有一定的可行性，提高了VTN網(wǎng)絡(luò)的可靠性，簡化了VTN映射機制。目前研究僅限于在單SDN控制器下租戶網(wǎng)絡(luò)的建立，未來還需繼續(xù)研究在多租戶技術(shù)下基于MAC地址映射機制建立VTN虛擬網(wǎng)絡(luò)。
參考文獻
[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] 陳琳，吳強.基于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.