一種基于多SDN控制器的交換機遷移機制

李 婉，沈蘇彬，吳振宇

(1.南京郵電大學 計算機學院，江蘇 南京 210003；2.南京郵電大學 物聯網學院，江蘇 南京 210003)

0 引 言

軟件定義聯網(Software Defined Networking，SDN)是一種新型的網絡架構，實現了控制平面和數據平面的分離，能夠更好地管理網絡流量，為網絡及其應用提供了良好的平臺。

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

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

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

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

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

1 相關技術分析

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

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

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

2 方案設計

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

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

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

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

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

2.1 負載監測

負載監測主要用于周期性監測控制器的負載，設置閾值，判斷控制器的負載狀態。文獻[11]主要考慮兩個負載信息：交換機指標和控制器指標。交換機指標包括與控制器連接的活躍交換機的個數和與控制器相連的所有交換機的Packet-in消息請求速率。控制器指標是控制器收集到的所有負載信息，包括當前的CPU使用率和內存使用率。使用具體的負載值表示控制器真實的負載信息，但是對于不同的網絡狀況，可能會有不同的負載信息。所以，在實際網絡中，為了表示不同的負載信息，可以引入系數，指示了綜合負載計算中不同負載信息的權重。由文獻[5]可以看出，CPU是控制器的主要限制。因此，控制器的負載主要監測主機的CPU使用率、內存使用率和控制器每秒處理Packet-in的消息個數。

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

2.2 負載調度

負載調度算法根據負載信息表決定是添加控制器、減少控制器還是執行交換機遷移。遷移交換機過程中哪個控制器應選為主控制器實施負載轉移，以及哪個交換機執行遷移。

算法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)是否增加/減少控制器。

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

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

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

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

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

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

if (Ldifi>C) then

Sort_ Descending(S1,…,Sm) to Migrate

根據式(1)計算函數值

MigrateSjtoCi

End if

UpdateCiSjmapping

end while

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

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

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

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

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

(1)

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

2.3 交換機遷移

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

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

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

3 系統實現

3.1 控制器部署

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

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

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

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

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

圖1 多控制器部署方式

3.2 負載均衡的實現

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

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

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

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

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

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

4 仿真實驗與分析

4.1 實驗環境

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

4.2 性能評價和測試

在SDN網絡中，控制器的性能主要體現在短時間內盡可能完成流表項的制定和下發，可以采用吞吐量和響應時間兩個指標測試控制器的性能。

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

(1)吞吐量。

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

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

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

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

圖3 不同控制器個數的吞吐量

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

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

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

(2)響應時間。

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

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

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

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

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

5 結束語

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

[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.