DN(軟件定義網(wǎng)絡(luò))通過邏輯上集中的主控制器實(shí)現(xiàn)對底層交換機(jī)報(bào)文處理的管理，在業(yè)界也因此出現(xiàn)了多種SDN/OpenFlow的控制器比如 RYU，OpenDaylight、Floodlight等;隨著云計(jì)算技術(shù)的發(fā)展在IaaS領(lǐng)域涌現(xiàn)很多開源的云平臺管理工具，但是這兩個(gè)領(lǐng)域目前還沒有很好的融合。本項(xiàng)目通過為OpenStack的網(wǎng)絡(luò)實(shí)現(xiàn)一個(gè)可擴(kuò)展的OpenFlow控制器Plugin，試圖解決早期OpenFlow控制器在擴(kuò)展性方面的缺陷。

一、簡介

云計(jì)算越來越普及，云提供的彈性和服務(wù)的動(dòng)態(tài)提供日益受人矚目。隨著OpenStack項(xiàng)目的出現(xiàn)，云平臺的創(chuàng)新也越來越容易。最初 OpenStack項(xiàng)目由instance管理項(xiàng)目(Nova)，object存儲項(xiàng)目(Swift)和image repository項(xiàng)目(Glance)組成，網(wǎng)路部分由Nova提供flat network配置和VLAN隔離，并沒有受到太多關(guān)注。這種簡單的網(wǎng)絡(luò)能力使得租戶很難設(shè)立多級網(wǎng)絡(luò)(flat networking模式)，同時(shí)沒有擴(kuò)展性可言。

從Quantum項(xiàng)目開始，OpenStack在接口設(shè)備(比如vNIC)間提供“網(wǎng)絡(luò)連接即服務(wù)”。Quantum使得租戶可以輕松建立虛擬網(wǎng)絡(luò)，模塊化的架構(gòu)和標(biāo)準(zhǔn)的API可方便實(shí)現(xiàn)防火墻和ACL的Plugin。在大量涌現(xiàn)的Plugin中，和網(wǎng)絡(luò)最相關(guān)的就是OpenFlow控制器RYU 的plugin，但是RYU開源的Plugin缺乏云計(jì)算最基本的特性：擴(kuò)展性。本項(xiàng)目將為Quantum設(shè)計(jì)一個(gè)更具擴(kuò)展性的openflow plugin，同時(shí)利用SDN的集中控制，我們還會(huì)演示基于控制器的虛機(jī)遷移應(yīng)用。

二、實(shí)現(xiàn)方法

Floodlight是基于Java的OpenFlow控制器，來源于Stanford大學(xué)最早開發(fā)的Beacon控制器(另一個(gè)最早的控制器是 NOX)，本項(xiàng)目選擇Floodlight是因?yàn)樗且豢钕鄬唵斡志哂休^高性能的控制器，不過本項(xiàng)目采用的方法可同樣適用于其它控制器。

OpenFlow開源控制器RYU提供和本項(xiàng)目類似的Plugin，實(shí)現(xiàn)了邏輯上的集中控制和API，便于創(chuàng)建新的網(wǎng)絡(luò)管理和控制應(yīng)用。RYU進(jìn)行租戶的2層網(wǎng)絡(luò)隔離不是通過VLAN，而是為VM內(nèi)部通信建立單獨(dú)的流，有實(shí)驗(yàn)表明這種方法在數(shù)據(jù)中心網(wǎng)絡(luò)不具有擴(kuò)展性，因?yàn)樗鼤?huì)很快耗盡交換機(jī)的內(nèi)存資源。

我們基于Floodlight為Quantum開發(fā)一款擴(kuò)展性更好的OpenFlow Plugin。最初選擇Floodlight是因?yàn)樗且豢罡咝阅艿钠髽I(yè)級控制器(譯注：非常遺憾Floodlight已經(jīng)停止更新)。不過本項(xiàng)目的方法可以很容易應(yīng)用于其他標(biāo)準(zhǔn)的OpenFlow控制器。

我們的Plugin將來自Quantum API的建立/更新/刪除網(wǎng)絡(luò)資源的請求傳遞給底層網(wǎng)絡(luò)。除了Plugin，每一個(gè)Nova VM會(huì)加載一個(gè)Agent用來處理該VM的虛擬接口的創(chuàng)建，并將它們與Quantum網(wǎng)絡(luò)對接。我們的方案利用支持OpenFlow的 OpenvSwitch(OVS)來提供Quantum所需的底層網(wǎng)絡(luò)，并通過Floodlight控制器對OVS進(jìn)行配置。

1 挑戰(zhàn)

為Quantum提供OpenFlow控制器Plugin的最大挑戰(zhàn)就是擴(kuò)展性。RYU開源的Plugin為所有的VM間流量創(chuàng)建流，當(dāng)流的數(shù)目超過OpenFlow交換機(jī)TCAM支持的最大條目后擴(kuò)展性就會(huì)成為問題。

本方法采用更具有擴(kuò)展性的VLAN方案對租戶網(wǎng)絡(luò)進(jìn)行隔離。我們知道VLAN同樣有擴(kuò)展性的限制，因此，后續(xù)方案開發(fā)可以考慮新的封裝協(xié)議比如VXLAN。

2 架構(gòu)

Quantum的Plugin用來處理網(wǎng)絡(luò)建立請求，它將來自Quantum的網(wǎng)絡(luò)ID轉(zhuǎn)換為VLAN并將這個(gè)轉(zhuǎn)換關(guān)系維護(hù)在數(shù)據(jù)庫中。 Plugin負(fù)責(zé)OVS Bridge的創(chuàng)建，記錄邏輯網(wǎng)路模型。Agent和Plugin同時(shí)紀(jì)錄進(jìn)入網(wǎng)絡(luò)的端口，通知Floodlight有新的流量進(jìn)入網(wǎng)絡(luò)?；诰W(wǎng)絡(luò)端口的分配情況和端口的源MAC地址，流量被控制器加上VLAN ID標(biāo)簽。一旦加上標(biāo)簽后，網(wǎng)絡(luò)流量就基于傳統(tǒng)的learning switch進(jìn)行轉(zhuǎn)發(fā)。因此，通過VLAN標(biāo)簽和OpenFlow的控制我們就可以基于租戶進(jìn)行VM流量的隔離。

上圖所示為Plugin的架構(gòu)。租戶通過nova-client將指令傳遞給Quantum管理單元，管理單元再將這些Call傳遞給真正執(zhí)行創(chuàng)建 /讀取/更新/刪除(CRUD)功能的控制器Plugin。Plugin通過在每個(gè)租戶的網(wǎng)絡(luò)ID和VLAN ID間建立映射關(guān)系實(shí)現(xiàn)上述功能。每當(dāng)有新的端口加載于Quantum網(wǎng)絡(luò)，Plugin就會(huì)相應(yīng)地添加端口到OVS-bridge，保存端口和VLAN ID間的映射關(guān)系。最后，以Daemon形式運(yùn)行于每個(gè)Hypervisor之上的Quantum agent不斷輪詢數(shù)據(jù)庫和OVS Bridge，當(dāng)有變化發(fā)生時(shí)就通知Floodlight Client，Client采用RESTful API告知Floodlight控制器模塊。這樣控制器就獲取了端口、網(wǎng)絡(luò)ID和VLAN ID的映射關(guān)系。當(dāng)?shù)竭_(dá)OVS的新報(bào)文沒有任何entry時(shí)，報(bào)文會(huì)送到控制器做決策。然后控制器會(huì)推送一條規(guī)則到OVS告知其采用哪個(gè)VLAN ID來標(biāo)記報(bào)文以及封裝報(bào)文所用的物理主機(jī)地址。另外，控制器還會(huì)為物理交換機(jī)增加一條規(guī)則，動(dòng)作為按照普通報(bào)文處理流程處理報(bào)文，所以報(bào)文的轉(zhuǎn)發(fā)將會(huì)按照基本的Leaning Switch方式。通過這個(gè)方法每個(gè)物理交換機(jī)所需的TCAM條目數(shù)與通過交換機(jī)的VLAN數(shù)目成正比。

3 分析對比

本節(jié)分析對比上述方法與RYU方法在流表數(shù)目上對交換機(jī)的需求。假定每個(gè)服務(wù)器有20個(gè)VM，每個(gè)VM有10條并發(fā)流(出入各5條)。在這樣的設(shè)定下，如果采用RYU的方法VM-VM間的流不具有擴(kuò)展性。上圖所示為兩種方法的對比圖。假定RYU的匹配規(guī)則基于VM的源和目的地址，因此ToR交換機(jī)需要在TCAM中存儲20 servers/rack x 20 VMs/server x 10并發(fā)流/VM = 4000條流表。然而在我們的方案中基于每個(gè)報(bào)文的VLAN標(biāo)簽可對流表進(jìn)行聚合，即使在物理交換機(jī)上每個(gè)VM都有一條匹配規(guī)則(這里假定最壞情況即服務(wù)器上的每個(gè)VM都屬于不同的租戶)，需要存儲在交換機(jī)TCAM中的流表?xiàng)l目數(shù)也只有400條，可以下降十倍以上。

4 管理應(yīng)用示例：VM遷移

OpenFlow和我們的OpenStack Plugin實(shí)現(xiàn)網(wǎng)絡(luò)的全局視角以及對轉(zhuǎn)發(fā)行為的直接控制，因而可以簡化操作管理。接下來我們提供一個(gè)應(yīng)用案例：VM遷移。

高速無縫的VM遷移是數(shù)據(jù)中心實(shí)現(xiàn)負(fù)載均衡、配置管理、能耗節(jié)約等提升資源利用率的重要手段。但是VM遷移需要更新網(wǎng)絡(luò)狀態(tài)，可能導(dǎo)致沖突、業(yè)務(wù)中斷、環(huán)路以及SLA不達(dá)標(biāo)等一系列問題，因此VM遷移對服務(wù)提供商來講始終是一個(gè)挑戰(zhàn)。SDN為解決這些棘手問題提供一個(gè)強(qiáng)有力的手段：在邏輯上集中的控制器位置運(yùn)行算法和可精確控制交換機(jī)轉(zhuǎn)發(fā)層面的能力有助于在兩個(gè)狀態(tài)間切換網(wǎng)絡(luò)。

本方法特別解決以下問題：對于分別由帶有特定轉(zhuǎn)發(fā)規(guī)則的交換機(jī)組成的起始網(wǎng)絡(luò)和目標(biāo)網(wǎng)絡(luò)，我們是否可以設(shè)計(jì)出一套OpenFlow指令將起始網(wǎng)絡(luò)狀態(tài)轉(zhuǎn)換到目標(biāo)網(wǎng)絡(luò)，同時(shí)保持某些狀態(tài)比如路徑無環(huán)以及保證帶寬。這個(gè)問題可以分解為兩個(gè)小問題：確定VM遷移的順序或者規(guī)劃排序;對于每一個(gè)要遷移的 VM，確定要執(zhí)行或者丟棄的OpenFlow指令的順序。

為了在有正確性保證的情況下進(jìn)行遷移，我們測試了最佳算法(用來從所有可能的遷移順序組合中確定導(dǎo)致最少?zèng)_突的排序)的性能。算法可以計(jì)算出VM遷移的排序以及一系列的轉(zhuǎn)發(fā)狀態(tài)改變。 算法運(yùn)行在SDN控制器之上所以可以編排整個(gè)網(wǎng)絡(luò)的改變。為了評估設(shè)計(jì)的性能，我們在真實(shí)的數(shù)據(jù)中心用虛擬的網(wǎng)絡(luò)拓?fù)浞抡嫘阅堋τ诟鞣N負(fù)載情況，算法可以大幅提高遷移的隨機(jī)排序性能(80%以上)。

在共享的物理數(shù)據(jù)中心分配虛擬網(wǎng)絡(luò)已經(jīng)有很多研究，本項(xiàng)目借用這些工作中物理底層網(wǎng)絡(luò)和VN的拓?fù)浜驮O(shè)置。另外，對于底層拓?fù)?，我們測試了用于隨機(jī)圖、樹、胖樹、D-Cell和B-Cube的算法。對于VN，我們采用Web服務(wù)應(yīng)用常見的星形、樹和3-tier圖。在遷移前最初分配VN時(shí)，我們使用了SecondNet的算法。

我們隨機(jī)選擇虛擬節(jié)點(diǎn)來進(jìn)行遷移，從有空余資源的底層節(jié)點(diǎn)任意選擇目的網(wǎng)絡(luò)。在其他場景下當(dāng)需要不同的節(jié)點(diǎn)或目標(biāo)選取策略時(shí)或許會(huì)影響算法的性能，基于本算法可以繼續(xù)進(jìn)行研究。

遷移平臺基于Intel的Core i7-2600K，16GB內(nèi)存。圖3實(shí)驗(yàn)為200個(gè)節(jié)點(diǎn)的樹，鏈接帶寬為500MB，VN為9節(jié)點(diǎn)樹，鏈路帶寬為10MB。如圖所示，采用最佳算法后沖突比例保持在30%以下，而某些隨機(jī)排序下則接近100%。

　　三、擴(kuò)展工作：VXLAN

隨著VXLAN等新的協(xié)議出現(xiàn)，擴(kuò)展多租戶云網(wǎng)絡(luò)的其他方法也可以被應(yīng)用于Plugin的通信底層機(jī)制。

VLAN(IEEE802.1q)傳統(tǒng)上常被用于為云中的不同租戶和組織提供隔離機(jī)制。雖然VLAN通過將網(wǎng)絡(luò)分隔為獨(dú)立的廣播域解決了2層網(wǎng)絡(luò)的問題，但是它無法提供敏捷的服務(wù)，可支持的host數(shù)目有限。因此，服務(wù)需要擴(kuò)展時(shí)不得不適配不同的VLAN，導(dǎo)致服務(wù)的分隔。另外，在手工配置的情況下，VLAN配置很容易出錯(cuò)，難于管理。雖然可以借助于VLAN管理策略服務(wù)器(VMPS)和VLAN trunking協(xié)議(VTP)自動(dòng)化地配置access端口和trunk端口，但是網(wǎng)絡(luò)管理員很少采用VTP，因?yàn)樵谶@種情況下，管理員必須將交換機(jī)分為不同VTP域，域中的每一個(gè)交換機(jī)必須加入域中所有的VLAN，造成不必要的負(fù)擔(dān)。再加上VLAN頭只提供12位的VLAN ID，網(wǎng)絡(luò)中最多有4096個(gè)VLAN?？紤]到VLAN廣泛的用途，這個(gè)數(shù)目難堪重任。數(shù)據(jù)中心虛擬化后進(jìn)一步增大對VLAN的需求。虛擬可擴(kuò)展 VLAN(VXLAN)是IETF推出的標(biāo)準(zhǔn)，試圖通過引入24位的VLAN網(wǎng)絡(luò)標(biāo)識符(VNI)來消除VLAN的限制，也就是說VXLAN可在網(wǎng)絡(luò)中創(chuàng)建16M個(gè)VLAN。VXLAN主要利用hypervisor中軟交換(或者硬件接入交換機(jī))的虛擬隧道端點(diǎn)(VTEP)并將與VM相關(guān)的VNI和報(bào)文進(jìn)行封裝。VTEP基于IGMP協(xié)議加入多播組，這有助于消除未知的單播flood。

限制：VXLAN中16M個(gè)VLAN將超過多播組的最大數(shù)目，所以屬于不同VNI的多個(gè)VLAN可能共享同一多播組。這可能導(dǎo)致安全和性能的問題。

四、總結(jié)

基于OpenFlow交換機(jī)部署OpenStack可充分體現(xiàn)SDN的優(yōu)勢。本項(xiàng)目實(shí)現(xiàn)了可擴(kuò)展的Quantum/Neutron網(wǎng)絡(luò)Plugin，同時(shí)為后續(xù)進(jìn)一步基于VXLAN等新封裝協(xié)議優(yōu)化改善Plugin提供了設(shè)計(jì)方向。