軟件定義網絡多控制器平臺研究

魏明軍++張文娜

摘要：文章針對軟件定義網絡單一控制器的處理能力不能滿足需求的擴展性問題及當前分布式多控制器平臺無法根據實際情況改變服務的問題，在控制層面上提出設計服務抽象層，對抽象服務層在控制器應用中對底層的操作或者應用之間交互設計的可行性進行實驗驗證及測試。

關鍵詞：軟件定義網絡；多控制器；服務抽象層

傳統的網絡體系結構是分布式的，每個網絡設備都擁有相對獨立的操作系統和控制層面。設備與設備之間通過分布式的網絡協議交換信息和數據，導致網絡的管理和配置工作越來越繁冗和復雜。通過現有網絡，管理人員實現創新和升級部署新的網絡結構變得越來越困難。因此需要一種新的體系結構，這種結構能分類控制數據動態，實現轉發與控制。

軟件定義網絡（Software-Defined Networking）作為一個新興的網絡體系結構受到廣泛的關注。文章針對軟件定義網絡、可擴展性問題、性能評價問題及其相關部分測試方法問題，對單一控制器處理能力不足以及當前分布式解決方案無法根據實際情況改變服務架構的問題，提出了控制平臺架構模型。并對已有的架構進行分析和總結，在該模型的基礎上設計服務抽象架構控制器，并對該控制器進行了功能和性能測試。

1 傳統網絡與軟件定義網絡對比

1.1 軟件定義網絡的特點

軟件定義網絡（SoftwareDefined Networking）通過控制與轉發的分離、開放的南北向接口、集中式的控制平面獲取網絡的全局信息，并根據業務需求對網絡資源進行動態的全局調配和優化。這一舉措大大提高了網絡控制的靈活性，使可管理、可編程、可動態改變的網絡成為可能，從而實現網絡流量的靈活控制，為核心網絡及應用的創新提供了良好的平臺。

1.2 傳統網絡與軟件定義網絡對比

傳統的互聯網體系結構是分布式的，每個網絡設備都擁有相對獨立的操作系統和控制層面，設備與設備之間通過分布式的網絡協議交換信息和數據，其結構有幾點不足：①網絡設備復雜。②配置困難。

1.3 網絡特征和底層操作系統綁定，很難添加新特性。

軟件定義網絡平臺以OpenFlow為主，OpenFlow從轉發設備中分離控制邏輯的方法使數據平面具備了靈活的設備添加和升級的能力。

2 多控制器實驗平臺簡介

2.1 多控制器架構分析

多控制器SDN網絡的典型做法是將網絡劃分成多個控制區域，每個區域由1個控制器控制。現有的多控制器架構從網絡的劃分方式來看，可以分為水平式多控制器架構和層次化多控制器架構2類。

2.2 控制器放置問題分析

分布式地部署多個控制器是解決SDN網絡的性能、可擴展性以及可靠性問題的重要手段之一。然而，多個控制器的存在也面臨著其他新挑戰，其中最關鍵的問題就是如何選擇控制器的數量以及控制器的放置位置。當前的研究工作主要從幾個方面來考慮控制器的放置方案：基于傳輸延時的控制器放置方式，基于可靠性的控制器放置方式，基于其他指標的控制器放置方式。

2.3 軟件定義網絡控制平臺的可靠性分析

SDN采用邏輯上集中式的方式對網絡進行管理與控制，為了解決集中控制環境中的故障問題，在網絡部署多個控制器是解決SDN控制平面可靠性問題的重要手段。SDN控制平面中的故障可以分為控制器故障以及傳輸控制流的節點或者鏈路的故障。為了克服控制器的故障，主要通過控制器的被動或主動復制技術來提高SDN控制平面的可靠性。而在克服傳輸控制流的節點或鏈路的故障方面，則主要通過路徑保護或者路徑恢復的方式來提高SDN控制平面的可靠性。多控制器平臺涉及架構設計、控制器放置等方面問題。針對這些問題，文章結合現有研究分類，通過分析、總結，可深入了解多控制器平臺存在的問題，并提出解決方案，為之后抽象服務層的設計奠定理論基礎。

3 實驗方案

為了解決集中式控制平臺的處理能力有限、全局視圖信息的收集代價過大等問題，文章采用多控制器滿足需求。控制器應該對應用透明，即不論服務如何變化，應用的編寫方式是一致的。也就是說，當底層服務發生變化時，原有的應用無需任何修改。要做到這一點，則要求底層協議更改更為慎重，對應用也必須相對透明。

3.1 服務抽象層

設計采用服務抽象層做到這一點，可以采用如下的設計思路：服務抽象層可以動態鏈接控制器應用與南向協議提供基本的網絡服務，如使用類似拓撲管理模塊，實現拓撲構建和設備發現的功能。抽象層提供的服務由控制器基于應用或者網絡設備提供的功能為基礎構建，基于應用對服務的請求服務抽象層映射到對應的控制器插件，選取恰當的南向協議與給定的網絡設備實現通信。

服務抽象層在服務和插件間流程設計方案舉例：①當一個支持OpenFlow協議的插件接收到一個ARP請求數據包，需要分派此數據包到ARP處理程序。②協議插件將調用數據包輸出服務接口，將數據包傳輸到服務抽象層。③ARP處理程序，將登記注冊到監聽數據包服務接口，在上一步中服務抽象層接收到的數據包將被移交到ARP處理程序對應的應用中。④該應用程序現在可以處理此數據包。通過以上分析結合軟件定義網絡現狀，對軟件定義網絡多控制器平臺進行理論分析并進行設計驗證。

3.2 多控制平臺下網絡拓撲實驗驗證。

控制器為應用提供了邏輯集中的物理網絡拓撲視圖，為了網絡應用直接管理網絡規則策略，控制器支持網絡設備轉發規則的變化。和大部分控制器一樣，控制器使用LLDP報文發現的設備連接來構建網絡拓撲結構。拓撲視圖選項提供了交換機和主機拓撲的圖形視圖。在抽象服務控制的多控制器拓撲中各個管理對應控制器存儲和設備，包括設備的功能和可達性信息等。這些信息由控制器存儲并且由拓撲管理器管理。其他構件組成包括ARP處理程序、主機探索器、設備管理器、交換機管理器等協助拓撲管理器生成網絡拓撲數據庫。

3.3 多控制平臺下服務抽象實驗驗證。

①實驗環境配置。在已經安裝Mininet環境的機器中啟動Mininet，對應地配置多個主機和交換機。在控制器層啟動一個簡單的轉發包應用，它通過ARP包來探測連接到網絡的每個主機，并給交換機安裝規則，讓網包能順利轉到各個主機。通過拖動設備，形成邏輯拓撲，并保存配置。②實驗分析。因為控制器是寄存在服務器中，所以當做好類似以上的配置之后，首先要連接控制器，通過控制器應答的狀態信息來了解網絡運行情況，其中應答201表明操作成功。為了敘述直觀簡潔，文章在試驗中配置了3臺交換機，每臺交換機上使用的南向協議不同。③獲取刪除主機信息（見圖卜圖3）。

利用仿真實驗進行驗證可以得出結論：通過獲取拓撲信息，配置與獲取用戶鏈接信息，獲取、刪除主機信息等實驗操作，驗證抽象服務層在控制器應用中對底層的操作或者應用之間交互設計的可行性。真正實現了多控制器多協議支持和對應用的透明，不論服務如何變化，應用的編寫方式一致。

4 結語

文章利用實驗平臺，對軟件定義網絡以及多控制器平臺相關問題進行仿真論證，實現服務抽象架構的多控制器平臺，服務抽象層可以動態鏈接控制器應用與南向協議提供基本的網絡服務，如使用類似拓撲管理模塊，完成構建拓撲和發現設備功能。服務抽象層與控制器插件是相互獨立的并且是相耦合的，這樣就可以實現靈活升級網絡協議或應用。endprint