SDNLAB技術(shù)分享：開源SDN控制器DCFabric及云計算高效網(wǎng)絡

**1.DCFabric控制器的由來

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

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

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

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

1.3 DCFabric：面向云計算的SDN開源控制器

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

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

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

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

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

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

4）易于擴展，可方便靈活的進行系統(tǒng)定制，實現(xiàn)各種場景下的SDN應用。

2.SFabric算法

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

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

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

圖. 示例網(wǎng)絡拓撲和SFabric流表

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

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

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