李 婉，沈蘇彬，吳振宇

(1.南京郵電大學 計算機學院，江蘇 南京 210003；2.南京郵電大學 物聯(lián)網(wǎng)學院，江蘇 南京 210003)

0 引 言

軟件定義聯(lián)網(wǎng)(Software Defined Networking，SDN)是一種新型的網(wǎng)絡架構(gòu)，實現(xiàn)了控制平面和數(shù)據(jù)平面的分離，能夠更好地管理網(wǎng)絡流量，為網(wǎng)絡及其應用提供了良好的平臺。

隨著支持OpenFlow設備的增加，數(shù)據(jù)平面大量的流量被發(fā)送到控制平面，引起網(wǎng)絡中SDN控制器的負載增加，SDN控制器受到性能和容量的限制，有可能限制了網(wǎng)絡的性能。傳統(tǒng)的SDN設備依賴于單個集中化的控制器，控制器是SDN網(wǎng)絡的核心，擁有全局網(wǎng)絡視圖，集中控制整個網(wǎng)絡，處理交換機發(fā)送過來的大量請求。雖然SDN控制器從單線程發(fā)展為多線程，但是單控制器在可擴展性、可靠性、安全性等方面存在固有缺陷[1]，因此，業(yè)界提出了邏輯上集中、物理上分布的多SDN控制器部署方案HyperFlow[2]、Kandoo[3]和Onix[4]，多個控制器協(xié)同工作，實現(xiàn)對整個網(wǎng)絡的集中式控制，有著更好的擴展性。

最早提出的分布式控制平面HyperFlow，實際上由物理上分布、邏輯上集中的多SDN控制器組成，在提供可擴展性的同時保持網(wǎng)絡集中控制的優(yōu)點。HyperFlow根據(jù)網(wǎng)絡規(guī)模設置多個管理域，每個管理域中的控制器獨立管理自己區(qū)域的交換機，只與鄰近的控制器交互，不主動地與遠處的控制器進行通信，減少了控制器和交換機之間的流配置時間。Kandoo采用分層思想將控制器分為兩層：根控制器和本地控制器。根控制器維護網(wǎng)絡的狀況，本地控制器主要負責管理交換機。

Onix主要包括物理基礎設施層、連接基礎設施、Onix和控制邏輯四部分。物理基礎設施層由路由器、交換機和其他網(wǎng)絡元素組成，主要為Onix提供讀寫狀態(tài)的API；連接基礎設施為物理基礎設施層和Onix提供通信通道；Onix為控制邏輯提供到網(wǎng)絡的可編程訪問接口；控制邏輯決定網(wǎng)絡的行為，其包含一個NIB(Network Information Base，網(wǎng)絡信息庫)，用于維護全網(wǎng)的狀態(tài)。由此可知，目前的分布式控制平面研究的重點是SDN控制器在正常工作的情況下，如何實現(xiàn)分布式控制器實例之間一致的狀態(tài)。多控制器部署方案[2-4]中控制器和交換機之間的關系是靜態(tài)配置的，但是網(wǎng)絡中的流量是動態(tài)變化的。如果一段時間內(nèi)，某一控制器管轄的交換機中流量突增，將導致控制器負載過大，緊接著導致控制器響應時間過長，從而降低了整個網(wǎng)絡的性能。而其他控制器有可能處于閑置狀態(tài)，引起控制器之間負載不均衡，造成了控制器資源的浪費。

為解決SDN控制器負載不均衡問題，文獻[5-6]提出的彈性分布式控制器ElastiCon能夠根據(jù)網(wǎng)絡中的負載動態(tài)減少或增加控制器。為了實現(xiàn)彈性分布式控制器，提出了交換機遷移協(xié)議。但是該方案考慮的情況比較簡單，只有一個控制器負載過載，采用就近遷移的策略。雖然可以減少交換機和控制器之間的延遲，但是如果鄰近控制器的負載過大，將導致多次遷移交換機，效率并不是很高，甚至需要添加新的控制器。

針對上面多控制器負載失衡的問題，文中提出一種交換機動態(tài)遷移機制。該機制基于控制器角色實現(xiàn)交換機的遷移，并且提出一種調(diào)度算法，該算法綜合考慮了控制器的負載和交換機與控制器之間的傳輸時延兩個因素，選擇合適的交換機和目標控制器后，控制器通過改變其角色、與其連接的活躍交換機的個數(shù)，完成交換機的遷移。為了評價其性能，驗證了控制平面的響應時間和吞吐量，并和傳統(tǒng)的靜態(tài)配置作對比。

1 相關技術分析

和傳統(tǒng)網(wǎng)絡相比，SDN在靈活性和管理性等方面表現(xiàn)出了很多優(yōu)點，但隨著網(wǎng)絡的急劇擴張，控制器的性能、可擴展性和可靠性逐漸成為瓶頸。另外，一旦控制器失效，將導致整個網(wǎng)絡面臨癱瘓。所以單SDN控制器很難應用于大型網(wǎng)絡中。為此，研究人員提出了分布式控制器架構(gòu)來提高SDN控制平面可擴展性。但是，目前大多數(shù)方案中交換機與控制器實例之間靜態(tài)的映射關系會因為流量的動態(tài)變化造成控制器負載不均衡。針對上面的問題，ADVAIT等提出了彈性分布式控制器ElastiCon。ElastiCon提出了一種負載窗口機制，當負載超過上、下閾值時，采取增加新控制器、減少已有控制器或遷移交換機的動作，提高了控制器的資源利用率。但是ElastiCon并沒有明確怎樣選擇増?zhí)砗蛣h除的控制器數(shù)量及位置。另外，文獻[5]是將交換機遷移到最近的控制器，減少了控制器和交換機之間的時延，但是沒有考慮到鄰近控制器的負載，有可能導致鄰近控制器又超載，緊接著可能多次遷移交換機。因此，如何精細控制控制器的負載，減少交換機的遷移頻率，實現(xiàn)多控制器之間的負載均衡是必須要解決的問題。文獻[7]提出了一種彈性方案，在不同的情況下，動態(tài)改變控制器的個數(shù)和位置。文獻[8]介紹了在集群中動態(tài)添加或移除控制器但沒有產(chǎn)生引起網(wǎng)絡中斷的算法，同時也提到了給控制器動態(tài)分配交換機的必要。文獻[9]使用利用率最低的遷移策略，每次都將交換機遷移到剩余容量不經(jīng)常使用的控制器下，沒有考慮到控制器和交換機之間的傳輸時延；另外，也沒有實現(xiàn)總體的負載均衡。

目前的交換機遷移算法大部分都是選擇負載較大的控制器下的交換機進行遷移，然后判斷遷移后的控制器負載是否過大，如果過載則繼續(xù)進行遷移。雖然這種遷移方式的單次遷移效率較高，但是對于大規(guī)模傳輸速率較大的網(wǎng)絡來說，該遷移方式仍需要花費較大的代價。所以，如何對負載過大的控制器下的交換機進行遷移，提高遷移效率也是一個必須要解決的問題。

文中提出的算法綜合考慮了控制器的負載和交換機與控制器之間的傳輸時延兩個因素，然后在控制器和交換機位置確定的情況下，當控制器之間的負載大于事先設置的閾值時，交換機將原來連接的主控制器變?yōu)閺目刂破?，將其中的一個從控制器變?yōu)橐粋€新的主控制器。發(fā)生遷移的交換機必須滿足遷移到的新的主控制器的負載沒有超過其最大負載和交換機遷移之后控制器之間的負載更均衡兩個條件。當兩個條件都滿足的情況下，選擇與控制器之間傳輸時延最小的交換機進行遷移。

2 方案設計

交換機遷移的過程其實是根據(jù)網(wǎng)絡中的流量重新部署交換機和控制器之間的關系。OpenFow1.3.4協(xié)議[10]提到每個交換機可以連接一個主控制器和多個從控制器。另外，OpenFlow協(xié)議還介紹了多種消息，交換機如果收到控制器發(fā)送的Role-request消息，會根據(jù)請求的控制器角色類型做出回復，并向控制器發(fā)送Role-reply消息，告訴控制器是否允許修改角色。主控制器域內(nèi)的交換機在某時刻如果流請求不斷激增的話，需要對該域內(nèi)交換機實現(xiàn)向外遷移，遷移之前，需要從多個從控制器集合中選擇一個從控制器作為該交換機新的主控制器，同時把原來的主控制器變更為從控制器。

本節(jié)展示了如何定義和估算控制器負載，并討論了基于交換機遷移的負載均衡模式。管理框架包含三個功能，說明如下：

(1)負載監(jiān)測功能：周期性收集和計算控制器的負載，并協(xié)調(diào)維護全局負載信息表。

(2)負載調(diào)度功能：檢查每個控制器負載信息表，并決定是否執(zhí)行交換機遷移，哪個控制器應選為主控制器實施負載轉(zhuǎn)移，哪個交換機執(zhí)行遷移。

(3)交換機遷移功能：控制器協(xié)調(diào)交換機遷移和改變交換機與控制器之間的映射。

2.1 負載監(jiān)測

負載監(jiān)測主要用于周期性監(jiān)測控制器的負載，設置閾值，判斷控制器的負載狀態(tài)。文獻[11]主要考慮兩個負載信息：交換機指標和控制器指標。交換機指標包括與控制器連接的活躍交換機的個數(shù)和與控制器相連的所有交換機的Packet-in消息請求速率?？刂破髦笜耸强刂破魇占降乃胸撦d信息，包括當前的CPU使用率和內(nèi)存使用率。使用具體的負載值表示控制器真實的負載信息，但是對于不同的網(wǎng)絡狀況，可能會有不同的負載信息。所以，在實際網(wǎng)絡中，為了表示不同的負載信息，可以引入系數(shù)，指示了綜合負載計算中不同負載信息的權重。由文獻[5]可以看出，CPU是控制器的主要限制。因此，控制器的負載主要監(jiān)測主機的CPU使用率、內(nèi)存使用率和控制器每秒處理Packet-in的消息個數(shù)。

假設網(wǎng)絡中有N個控制器{C1,C2,…,Cn}和M個交換機{S1,S2,…,Sm}。根據(jù)網(wǎng)絡中的狀態(tài)調(diào)節(jié)收集和計算負載信息的時間間隔。如果時間間隔較短，雖然可以獲得一個準確的負載信息，但是會引起額外的系統(tǒng)開銷和通信開銷。如果時間間隔較長，則不能準確地描述控制器的負載情況。根據(jù)控制器的負載動態(tài)調(diào)整收集和計算負載信息的時間間隔，不僅可以減少系統(tǒng)開銷，還可獲得準確的負載信息。

2.2 負載調(diào)度

負載調(diào)度算法根據(jù)負載信息表決定是添加控制器、減少控制器還是執(zhí)行交換機遷移。遷移交換機過程中哪個控制器應選為主控制器實施負載轉(zhuǎn)移，以及哪個交換機執(zhí)行遷移。

算法1：整體算法。

While (true) do

if (Ldifi>C) then

Balance(Ci,Sj);

end if

if (Max_Load_Ratio>α) then

Add_controller;

Else if(Max_Load_Ratio<β)then

Sub_cohtntroller;

End if

(1)是否增加/減少控制器。

根據(jù)文獻[1]可知，控制器每秒能夠處理有限的數(shù)據(jù)包，如果控制器每秒處理的數(shù)據(jù)包個數(shù)較少，則會造成控制器資源的浪費，因此為控制器每秒處理數(shù)據(jù)包的個數(shù)設置上下限閾值，分別為α和β。應該做什么操作由算法1確定。如果資源池中控制器的負載超過事先設置的閾值α，則添加新的控制器。如果資源池中控制器的負載低于事先設置的閾值β，則關閉或者移除部分控制器。如果在兩者之間，則需要一直監(jiān)測控制器的負載，判斷是否需要平衡控制器之間的負載。

(2)是否執(zhí)行交換機遷移。

是否執(zhí)行交換機遷移由控制器的負載狀況決定。具體的遷移策略參見算法2。其中，LOAD(Ci)表示控制器Ci的負載，按照從小到大的順序列出控制器的負載，最重的負載和最輕的負載之差為Ldifi。當Ldifi比閾值C大時，交換機發(fā)生遷移。一個合適的閾值C，可以實現(xiàn)預想的負載平衡，避免頻繁地遷移交換機。

算法2：平衡控制器之間的負載。

While (LOAD(Ci)Table!=NULL) do

Sort_Descending(LOAD(C1),…,LOAD(Cn))

if (Ldifi>C) then

Sort_ Descending(S1,…,Sm) to Migrate

根據(jù)式(1)計算函數(shù)值

MigrateSjtoCi

End if

UpdateCiSjmapping

end while

(3)哪個控制器選為主控制器。

該系統(tǒng)中設置一個協(xié)調(diào)節(jié)點，一個特殊的控制器。協(xié)調(diào)節(jié)點負責收集每個控制器的負載信息，并且計算系統(tǒng)具體的負載。協(xié)調(diào)節(jié)點也有交換機和控制器之間的靜態(tài)映射和負載信息表。協(xié)調(diào)節(jié)點通常是第一個加入到系統(tǒng)中的節(jié)點。一旦協(xié)調(diào)節(jié)點發(fā)生故障，其他控制器可以迅速修改角色變成協(xié)調(diào)節(jié)點。根據(jù)負載信息表，負載最輕并且時延滿足的控制器選為主控制器，實現(xiàn)某個交換機的遷移。為了實現(xiàn)控制平面的擴展性，當在該組加入新的交換機時，負載較輕的控制器作為主控制器。

(4)哪個交換機應該遷移。

具體選擇哪個交換機實現(xiàn)遷移對其負載平衡有著重要的影響。如果選擇遷移Packet-in請求速率較高的交換機，將導致新的主控制器的負載較大。如果選擇遷移Packet-in請求速率較小的交換機，將導致多次遷移。

文獻[6]中提到控制器的響應時間直接影響著流安裝的處理速度。控制器的響應時間表示交換機和控制器相連后，交換機發(fā)送一個消息給控制器，控制器對該消息進行處理，并將結(jié)果返回給相應的交換機的過程所使用的時間。對于交換機是否應該遷移，使用響應時間這個參數(shù)，設置一個最初的權值Wi，表示交換機選擇的優(yōu)先級。

(1)

根據(jù)算法2，對該控制器管控的交換機在時間間隔內(nèi)產(chǎn)生的平均流請求進行降序排序，初始時選擇平均流請求最大的交換機作為待遷移的對象，然后按照上面介紹的方式依次遍歷該控制器管控下的所有交換機，直到選擇合適的交換機和控制器。

2.3 交換機遷移

設計交換機遷移機制，當控制器負載較大時，實現(xiàn)將交換機資源遷移到負載較小的控制器管理域內(nèi)[5-6]。為了保證交換機遷移過程中消息的正常處理，需遵循兩個原則：

(1)活躍性：交換機在遷移過程中，要保證與該遷移交換機至少有一臺控制器處于正常運行狀態(tài)，不能直接將控制器的角色改成主模式來完成交換機的遷移工作。例如控制器在遷移開始之前，發(fā)送了一條Flow-mod刪除消息到交換機中，在交換機遷移之前還沒有回復Flow-removed消息到控制器中，那么遷移之后會造成信息的丟失和狀態(tài)的不一致性。

(2)安全性：交換機在遷移過程中，要保證只能有一臺控制器處理交換機的異步消息。例如多臺控制器對同一交換機的Packet-in消息進行處理，會造成流表項的多次安裝，還會造成分布式數(shù)據(jù)存儲的不一致性。

3 系統(tǒng)實現(xiàn)

3.1 控制器部署

文中采用ZooKeeper[12]技術搭建多個控制器，ZooKeeper是一個簡單高效的分布式協(xié)調(diào)器。當服務器啟動后，從配置文件設置的服務器中選擇一臺SDN控制器作為領導者，其余控制器便成為跟隨者。領導者負責對多個SDN控制器進行管理并提供北向接口服務，跟隨者主要負責管理控制交換機。

ZooKeeper采用了原子廣播協(xié)議，分為廣播模式和恢復模式。廣播模式可用于數(shù)據(jù)同步，保證了控制器之間的一致性。服務啟動或在領導者崩潰后，恢復模式用于選舉領導者。ZooKeeper組服務的功能,可以感知集群中控制器的添加和移除。Zookeeper的觀察機制可以實時同步控制器的狀態(tài)信息。

控制器之間可以通過Zookeeper進行通信，協(xié)商完成交換機的遷移，并且更新交換機和控制器之間的映射關系。

每臺控制器都有兩部分信息：控制器節(jié)點的負載信息和控制器與交換機之間的角色映射關系。為了更好地模擬大型網(wǎng)絡，將整個系統(tǒng)劃分為若干個更小的范圍。這里采用分組的形式，每組控制器只知道自己的完整拓撲結(jié)構(gòu)，不知道其他組的拓撲結(jié)構(gòu)，減少了網(wǎng)絡上的通信量。

如圖1所示，對控制器進行分組，在部署過程中，各分組物理上是分布的，交換機就近選擇控制器，減少了控制器和交換機之間的傳輸時延。每組至少有兩臺控制器，在主控制器失效的情況下，集群能夠從多臺從控制器中選擇一個作為新的主控制器，避免了控制器的單點故障。當其中一臺控制器負載過大，交換機可以遷移到其他的控制器，實現(xiàn)了集群的負載均衡。同時，控制器對交換機透明化，交換機不需要知道接受哪臺控制器的控制，保證了邏輯上的集中。

圖1 多控制器部署方式

3.2 負載均衡的實現(xiàn)

主要通過修改運行中的控制器角色完成交換機的遷移過程，從而均衡控制器之間的負載。通過對OpenFlow協(xié)議的學習，文中提出的遷移機制由從控制器發(fā)送Role-request消息開始，后續(xù)階段對其響應，逐步完成交換機的遷移。假設交換機(S)分別與主控制器(C1)和從控制器(C2)相連，當C1的負載較大、C2的負載較輕時，通過S實現(xiàn)負載的轉(zhuǎn)移。交換機的遷移過程如圖2所示，主要分為4個階段。

圖2 交換機的無縫遷移過程

第1階段：C2請求修改角色為對等角色。對于待遷移的S而言，C2首先由從控制器變?yōu)閷Φ瓤刂破?。C1通過控制器間信道發(fā)送一個開始遷移消息給C2，開始交換機遷移階段。C2發(fā)送一個Role-request消息到S中，請求將角色變成過渡角色對等角色。在C2從S收到Role-reply之后，角色將變?yōu)閷Φ?。只有當C2變?yōu)閷Φ冉巧?，才可以接收到S發(fā)送的異步消息，但是此時C2忽視這些消息，不需要響應這些消息。在該階段，C1仍是唯一的主控制器，能夠處理來自S的所有消息，保證了活躍性和安全性。

第2階段：插入和刪除空流表。為了確保遷移的精確時刻，C1發(fā)送一個空的Flow-mod命令給S，用于添加一個空流表項，但是該流表項無法匹配即將到來的任何數(shù)據(jù)包。這里，假設所有的控制器都知道該空流表項。然后，C1再發(fā)送另外一個Flow-mod消息用于刪除該流表。相應的，S將會發(fā)送Flow-removed消息給C1和C2。Flow-removed事件用于確認刪除空流表項。之后，只有C2處理S的異步消息。另外，在插入和刪除空流表中間使用Barrier消息，用于確保在插入任何消息之前的所有消息都被處理完了，而不是被刪除了。

第3階段：使用Barrier消息刷新待處理請求。雖然C2在第2階段已經(jīng)接管了S，但S中可能還有正在處理的請求，C1所需要做的就是處理完所有在Flow-removed之前的消息并且下發(fā)給S。因為，交換機并沒有明確地確認信息可以確保所有的消息都被C1處理了。如果C1沒有發(fā)送一個信號給C2，則C1無法變?yōu)閺目刂破?，S也將忽略之前的所有操作。因此，為了確保所有的消息都能被處理，C1發(fā)送一個Barrier-request消息到S，并等待S回復Barrier-reply消息。此時，C1與S之間的遷移正式結(jié)束。

第4階段：C2請求修改角色為主控制器。C2發(fā)送Role-request消息給交換機將其角色改為主控制器。同時，C2更新分布式數(shù)據(jù)。S在收到Role-request消息后，返回Role-reply消息給C2，S自動將C1的角色修改為從控制器。至此，S的遷移過程正式完成，C2開始處理S的請求。

4 仿真實驗與分析

4.1 實驗環(huán)境

實驗基于Ubuntu14.04系統(tǒng)，采用Floodlight[13]控制器組成的控制器集群，在Mininet[14]仿真平臺上進行仿真驗證。

4.2 性能評價和測試

在SDN網(wǎng)絡中，控制器的性能主要體現(xiàn)在短時間內(nèi)盡可能完成流表項的制定和下發(fā)，可以采用吞吐量和響應時間兩個指標測試控制器的性能。

吞吐量評估不同的控制器在不同數(shù)量線程條件下，能夠處理交換機發(fā)過來的數(shù)據(jù)流請求的最大平均流量。響應時間主要評價控制器在被動流表安裝模式下，流表項設置過程中產(chǎn)生的最大、最小和平均時延。

(1)吞吐量。

本節(jié)測試文中提出的基于集群的部署方案和交換機遷移機制的性能，并且與傳統(tǒng)的靜態(tài)配置方案進行對比。

使用Cbench測量Floodlight控制器的性能，受到本身硬件的影響，測量時參數(shù)設置每臺交換機連接100臺主機，通過改變交換機的個數(shù)，經(jīng)過多次測量，四核CPU的單臺Floodlight控制器每秒最多大約可以處理48 600個數(shù)據(jù)包。Packet-in消息是Floodlight控制器眾多模塊處理的重點，因此，統(tǒng)計某一段時間內(nèi)Floodlight控制器處理Packet-in消息的個數(shù)反映了系統(tǒng)的處理性能。在Floodlight控制器源碼中添加了一個統(tǒng)計Packet-in消息的模塊，用于計算系統(tǒng)所處理的消息個數(shù)。

逐漸部署1到5臺Floodlight控制器，每臺控制器連接一臺交換機，每臺交換機連接一臺主機，主機用于在網(wǎng)絡中產(chǎn)生UDP數(shù)據(jù)流。流表的下發(fā)有主動和被動兩種方式。為了使到達控制器的數(shù)據(jù)流的速率最大，交換機采取被動安裝流表的策略。在控制平面，對其應用做一些修改，禁用交換機安裝流表項的功能。這意味著交換機接收到的數(shù)據(jù)包都是新的流，都要封裝成Packet-in消息發(fā)送給控制器。

圖3表明CPU是限制控制器性能的主要原因，系統(tǒng)整體的吞吐量隨著控制器個數(shù)的増加大約呈線性增加的趨勢，表明系統(tǒng)具有良好的伸縮性，可以通過增加網(wǎng)絡中控制器的個數(shù)來提高控制平面的處理能力。因此基于集群的多控制器部署方案具有良好的可擴展性。

圖3 不同控制器個數(shù)的吞吐量

為了測量遷移交換機的方式可以實現(xiàn)負載均衡，實驗中部署了5臺控制器和20臺交換機，交換機隨機連接控制器，然后模擬向不同控制器中不均勻地注入大量的數(shù)據(jù)流，分別測試遷移之前和之后每臺控制器的資源使用情況。

從圖4中可以看出，靜態(tài)配置關系中控制器1、2、3的資源使用率都超過80%，而控制器4、5的資源使用率在20%左右，說明控制器之間負載很不均衡。使用遷移機制之后，每臺控制器的資源使用率在60%左右，說明交換機遷移的機制可以較好地平衡各控制器負載。

圖4 遷移前后控制器的資源利用率

(2)響應時間。

對于交換機遷移過程中響應時間的測量，實驗環(huán)境中，集群中部署了兩臺Floodlight控制器C1和C2，8臺OpenvSwitch分別連接兩臺控制器，每臺交換機分別連接一臺主機。模擬三種不同的負載，主機使用Iperf工具發(fā)送不同速率的數(shù)據(jù)包。

為了模擬控制器之間負載失衡的情況，剛開始時，交換機S1、S2、S3和S4連接控制器C1作為主控制器和C2作為從控制器，交換機S5、S6、S7和S8連接控制器C2作為主控制器和C1作為從控制器。在交換機和控制器之間靜態(tài)映射的情況下，測量三種不同負載(見表1)下控制器的響應時間，具體結(jié)果如表2所示。

表1 三種不同的負載(數(shù)據(jù)包個數(shù))

表2 不同負載下控制器的響應時間 ms

負載A情況下，在靜態(tài)配置和遷移機制下，控制器的響應時間差別不大。對于負載B和負載C兩種情況，控制器C2的響應時間有很大差別。根據(jù)實驗可知，集群帶來的時延是可以接受的。當在重負載情況下，通過遷移交換機，集群可以使時延更低。

5 結(jié)束語

針對多控制器系統(tǒng)中負載不平衡引起的控制器性能下降的問題，提出將集群技術應用到多控制器系統(tǒng)中。為了解決多控制器負載不均衡的問題，提出了交換機資源的實時轉(zhuǎn)移。與傳統(tǒng)的靜態(tài)映射關系相比，該方案可以有效提高系統(tǒng)的處理性能以及網(wǎng)絡的吞吐量。下一步工作是考慮到交換機遷移的次數(shù)，進一步優(yōu)化負載調(diào)度算法。

[1] TOOTOONCHIAN A, GORBUNOV S, GANJALI Y,et al. On controller performance in software-defined networks[C]//USENIX conference on hot topics in management of internet,cloud,and enterprise networks and services.[s.l.]:USENIX Association,2012:10.

[2] TOOTOONCHIAN A,GANJALI Y.HyperFlow:a distributed control plane for OpenFlow[C]//Proceedings of the 2010 internet network management conference on research on enterprise networking.[s.l.]:USENIX Association,2010:3.

[3] YEGANEH S H,GANJALI Y.Kandoo:a framework for efficient and scalable offloading of control applications[C]//Proceedings of the first workshop on hot topics in software defined networks.[s.l.]:ACM,2012:19-24.

[4] KOPONEN T,CASADO M,GUDE N,et al.Onix:a distributed control platform for large-scale production networks[C]//USENIX conference on operating systems design and implementation.[s.l.]:USENIX Association,2010:351-364.

[5] DIXIT A,HAO F,MUKHERJEE S,et al.Towards an elastic distributed SDN controller[J].ACM SIGCOMM Computer Communication Review,2013,43(4):7-12.

[6] DIXIT A A,HAO F,MUKHERJEE S,et al.ElastiCon:an elastic distributed SDN controller[C]//Proceedings of the tenth ACM/IEEE symposium on architectures for networking and communications systems.[s.l.]:ACM,2014.

[7] BARI M F,ROY A R,CHOWDHURY S R, et al.Dynamic controller provisioning in software defined networks[C]//IEEE/ACM/IFIP international conference on network and service management.[s.l.]:IEEE,2013:18-25.

[8] YAZICI V,SUNAY M O,ERCAN A O.Controlling a software-defined network via distributed controllers[C]//Proceedings of the 2012 NEM summit.[s.l.]:[s.n.],2012:16-20.

[9] YAO G,BI J,LI Y,et al.On the capacitated controller placement problem in software defined networks[J].IEEE Communications Letters,2014,18(8):1339-1342.

[10] Open Networking Foundation. OpenFlow switch specification version 1.3.4[EB/OL].2014-05-27.https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-switch-v1.3.4.pdf.

[11] LIANG C,KAWASHIMA R,MATSUO H.Scalable and crash-tolerant load balancing based on switch migration for multiple open flow controllers[C]//Second international symposium on computing and networking.[s.l.]:IEEE,2014:171-177.

[12] Apache Software Foundation. Apache Zookeepr[EB/OL].2016.http://zookeeper.apache.org/.

[13] Floodlight OpenFlow Controller-Project Floodlight[EB/OL].2012.http://www.projectfloodlight.org/floodlight/.

[14] LANTZ B,HELLER B,MCKEOWN N.A network in a laptop:rapid prototyping for software-defined networks[C]//ACM workshop on hot topics in networks.Monterey,CA,USA:ACM,2010:1-6.