**1.DCFabric控制器的由來(lái)

**1.1 SDN是云計(jì)算數(shù)據(jù)中心網(wǎng)絡(luò)技術(shù)發(fā)展的必然要求

隨著以虛擬化為基礎(chǔ)的云數(shù)據(jù)中心的發(fā)展和成熟, 應(yīng)用數(shù)據(jù)猛增，虛擬服務(wù)器的遷移等要求VLAN可延展到所有匯聚層、接入層交換機(jī)。傳統(tǒng)二層技術(shù)存在鏈路冗余能力、負(fù)載均衡能力、可擴(kuò)展性和網(wǎng)絡(luò)穩(wěn)定性差等諸多缺陷。因此，大二層網(wǎng)絡(luò)技術(shù)如Trill、SPB等應(yīng)運(yùn)而生，卻存在過(guò)長(zhǎng)收斂時(shí)間、低轉(zhuǎn)發(fā)效率、有限網(wǎng)絡(luò)規(guī)模和昂貴的專有設(shè)備等缺點(diǎn)。而SDN則憑借其大二層網(wǎng)互通、全網(wǎng)拓?fù)洹⒁约岸嗦窂搅髁烤獾褥`活高效的功能，使其成為構(gòu)建數(shù)據(jù)中心大二層網(wǎng)絡(luò)的理想方案。

1.2 SDN控制器在云計(jì)算數(shù)據(jù)中心的主要挑戰(zhàn)

隨著數(shù)據(jù)中心規(guī)模的擴(kuò)大，SDN控制器面臨的主要問(wèn)題：交換機(jī)和用戶主機(jī)數(shù)目的增長(zhǎng)，使得每個(gè)交換機(jī)需存儲(chǔ)的流表內(nèi)容也在相應(yīng)增加（理論上每臺(tái)交換機(jī)上的流表最多需覆蓋到網(wǎng)絡(luò)中的所有主機(jī)），這不僅需要每臺(tái)交換機(jī)有更大的存儲(chǔ)容量和更快的查詢速度，也對(duì)控制器的工作效率提出了更高的要求。盡管當(dāng)前已有若干開源SDN控制器，但受制于性能和可擴(kuò)展性等，它們所能管理的網(wǎng)絡(luò)規(guī)模還有限，尚不具備直接的商業(yè)化運(yùn)營(yíng)的能力。因此，隨著大數(shù)據(jù)浪潮的到來(lái)，我們迫切需要可面向云計(jì)算數(shù)據(jù)中心的高性能SDN控制器。

1.3 DCFabric：面向云計(jì)算的SDN開源控制器

為了能盡快推進(jìn)SDN技術(shù)在云計(jì)算數(shù)據(jù)中心的產(chǎn)業(yè)化應(yīng)用進(jìn)程，在國(guó)家高技術(shù)研究發(fā)展計(jì)劃（863計(jì)劃）項(xiàng)目“軟件定義網(wǎng)絡(luò)（SDN）關(guān)鍵技術(shù)研發(fā)與示范”的資助下，上海寬帶中心、武漢綠網(wǎng)、中國(guó)電信聯(lián)合設(shè)計(jì)開發(fā)了面向云計(jì)算數(shù)據(jù)中心的開源SDN控制器——DCFabric控制器（http://www.sdn863.org.cn/）。

圖：DCFabric控制器架構(gòu)

相較于其他開源SDN控制器，DCFabric具有以下的主要特性：

1）基于高效C語(yǔ)言，借助于高效的內(nèi)存管理能力和多線程優(yōu)化，DCFabric具有強(qiáng)大的拓?fù)浒l(fā)現(xiàn)（單實(shí)例>1000個(gè)交換機(jī)）、消息處理和流表下發(fā)能力（>100,000 OpenFlow流表/S）。

2）針對(duì)數(shù)據(jù)中心網(wǎng)絡(luò)流量特點(diǎn)創(chuàng)新地提出了基于流表預(yù)先下發(fā)和流表聚合的SFabric算法，突破了物理OpenFlow交換機(jī)流表數(shù)量限制和通信路徑建立的抖動(dòng)等難題，從而實(shí)現(xiàn)了基于物理OpenFlow交換機(jī)的超大規(guī)模組網(wǎng)與高效交換。

3）架構(gòu)簡(jiǎn)潔，南向接口只支持OpenFlow和OVSDB，基于四種基礎(chǔ)服務(wù)，致力于云計(jì)算環(huán)境下的網(wǎng)絡(luò)交換。

4）易于擴(kuò)展，可方便靈活的進(jìn)行系統(tǒng)定制，實(shí)現(xiàn)各種場(chǎng)景下的SDN應(yīng)用。

2.SFabric算法

當(dāng)前主流的SDN網(wǎng)絡(luò)中的流表下發(fā)方式主要有兩種：前應(yīng)式（Proactive）和反應(yīng)式（Reactive）。由于在云計(jì)算環(huán)境下的NAT等功能的要求，反應(yīng)式的流表下發(fā)是必不可少的。受制于OpenFlow流表下發(fā)的不確定性和并發(fā)性下發(fā)的復(fù)雜性，通信路徑的建立常會(huì)出現(xiàn)由于交換機(jī)和控制器之間的多次Packet-in消息和流表下發(fā)的交互而帶來(lái)的長(zhǎng)時(shí)間劇烈抖動(dòng)，且隨著通信路徑的增長(zhǎng)而快速惡化。再加上交換機(jī)TCAM流表容量有限帶來(lái)的限制，已有的云計(jì)算數(shù)據(jù)中心內(nèi)的SDN方案一般采用基于傳統(tǒng)交換網(wǎng)上的通道技術(shù)的OVERLAY網(wǎng)絡(luò)方案：控制器只控制網(wǎng)絡(luò)邊界的虛擬交換機(jī)。這不僅會(huì)帶來(lái)由于封包、解包所帶來(lái)的性能下降問(wèn)題，而且會(huì)導(dǎo)致在物理網(wǎng)絡(luò)上的網(wǎng)絡(luò)流量的不可視、不可控等問(wèn)題。

針對(duì)上述兩個(gè)問(wèn)題，SFabric創(chuàng)新性的提出了“兩步式”流表下發(fā)法和基于交換機(jī)ID的流表聚合，從而提高了控制器的效率和降低了流表數(shù)量。當(dāng)控制器完成網(wǎng)絡(luò)拓?fù)浒l(fā)現(xiàn)以后，SFabric首先每一個(gè)交換機(jī)分配一個(gè)唯一的Switch ID，然后會(huì)為每對(duì)交換機(jī)計(jì)算兩條有向的通信路徑。計(jì)算路徑時(shí)主要有兩個(gè)問(wèn)題需要考慮：一是到同一個(gè)目的交換機(jī)的路徑應(yīng)該是收斂的，即到同一個(gè)目的交換機(jī)的所有路徑應(yīng)該是構(gòu)成一個(gè)以其為根節(jié)點(diǎn)的樹；二是出于流量均衡等因素，應(yīng)該把所有的路徑在整個(gè)網(wǎng)絡(luò)拓?fù)渲凶龅骄鶆蚍植肌?/p>

計(jì)算好路徑以后，控制器就會(huì)把路徑信息以O(shè)penFlow流表的形式裝載到交換機(jī)中。由于網(wǎng)絡(luò)中到每一個(gè)目的交換機(jī)的路徑構(gòu)成一個(gè)樹，所以需要下發(fā)的OpenFlow流表只需要把目的交換機(jī)的Switch ID作為匹配字段即可。由于而不需要關(guān)心路徑的起始點(diǎn)，所以所有交換機(jī)中的流表的個(gè)數(shù)最多只有n條，其中n表示網(wǎng)絡(luò)中交換機(jī)的個(gè)數(shù)。因此，SFabric可預(yù)先構(gòu)建好交換機(jī)級(jí)別的路由規(guī)劃，從而為后續(xù)數(shù)據(jù)包的端到端單播路徑建立做好提前準(zhǔn)備。考慮到與其它現(xiàn)有OpenFlow交換機(jī)和網(wǎng)卡的兼容 性，SFabric推薦采用VLAN ID作為Switch ID存儲(chǔ)字段。

圖. 示例網(wǎng)絡(luò)拓?fù)浜蚐Fabric流表

當(dāng)SFabric構(gòu)建好轉(zhuǎn)發(fā)路徑以后，系統(tǒng)就完成了初始化程序。由于網(wǎng)絡(luò)中交換機(jī)之間的轉(zhuǎn)發(fā)路徑都已建立，當(dāng)主機(jī)實(shí)際通信時(shí)，控制器只需在主機(jī)的接入交換機(jī)上下發(fā)對(duì)數(shù)據(jù)包進(jìn)行打標(biāo)簽的一個(gè)流表即可。考慮圖1中連接在交換機(jī)1和6上的兩個(gè)主機(jī)Host A和Host B（其IP和MAC分別為IP_A、MAC_A和IP_B、MAC_B），當(dāng)其需要通信時(shí)，SFabric首先查詢其所對(duì)應(yīng)的接入交換機(jī)的Switch ID分別是1和6，然后只需在這兩個(gè)交換機(jī)的Table1分別下發(fā)如圖中所示的兩個(gè)流表來(lái)對(duì)數(shù)據(jù)包添加Vlan標(biāo)簽。

3.基于DCFabric的OpenStack高效網(wǎng)絡(luò)

**3.1當(dāng)前OpenStack主要網(wǎng)絡(luò)架構(gòu)：OverLay

**

OverLay網(wǎng)絡(luò)的主要缺點(diǎn)如下：

1）需要耗費(fèi)主機(jī)的CPU資源進(jìn)行數(shù)據(jù)的封包和解包過(guò)程

2）封包、解包的低效導(dǎo)致了VM的有限的網(wǎng)絡(luò)吞吐量（<2.5 Gpbs in 10GE鏈路）

3）在物理網(wǎng)絡(luò)上的流量的不可視帶來(lái)的不可控問(wèn)題

4）南北向流量都需要從網(wǎng)絡(luò)節(jié)點(diǎn)通過(guò)帶來(lái)的流量瓶頸問(wèn)題

5）網(wǎng)絡(luò)配置的復(fù)雜性帶來(lái)的配置困難和低可靠性

**3.2基于DCFabric的全物理OpenFlow交換機(jī)網(wǎng)絡(luò)

**

為了能更好的發(fā)揮SDN在OpenStack中的應(yīng)用潛力，避免Overlay網(wǎng)絡(luò)帶來(lái)的各項(xiàng)難題，我們提出了基于物理OpenFlow交換機(jī)和DCFabric的高效網(wǎng)絡(luò)方案，其主要優(yōu)點(diǎn)如下：

1）無(wú)須封包、解包帶來(lái)的高網(wǎng)絡(luò)吞吐量，10 Gbps環(huán)境下的虛擬機(jī)最大網(wǎng)絡(luò)帶寬可以達(dá)到9.3 Gpbs以上；

2）VM的南北向流量可以直接通過(guò)物理交換網(wǎng)轉(zhuǎn)發(fā)，不僅南北向帶寬可以達(dá)到線性速度，而且NAT、Floating IP和負(fù)載均衡等高級(jí)網(wǎng)絡(luò)功能都可在控制器的統(tǒng)一調(diào)度下由交換機(jī)來(lái)實(shí)現(xiàn)；

3）基于標(biāo)準(zhǔn)OpenFlow協(xié)議，無(wú)廠商綁定，造價(jià)較傳統(tǒng)網(wǎng)絡(luò)方案可大幅降低，而且網(wǎng)絡(luò)可動(dòng)態(tài)線性擴(kuò)展；

4）物理網(wǎng)絡(luò)中流量可視帶來(lái)的可管可控優(yōu)勢(shì)，可支持網(wǎng)絡(luò)安全功能和流量工程等功能擴(kuò)展，提高系統(tǒng)的靈活性。

圖：基于DCFabric的OpenStack高效網(wǎng)絡(luò)架構(gòu)

審核編輯：郭婷