軟件定義網絡潛在用戶所面臨的一個關鍵挑戰是判斷特定SDN控制器的特定價值，畢竟控制器作為網絡應用和網絡基礎設施之間的橋梁發揮著關鍵性作用。但目前還沒有一個可以規范SDN的模型，也沒有一個SDN控制器必須要遵守的任何標準。

SDN控制器設計要素

顯而易見，SDN控制器是整個SDN網絡的核心，因此其設計需要綜合考慮等方面的需求，具體來說，其設計的核心要素如下圖所示：

在這些SDN控制器的核心能力中，有些是傳統網絡設備已經給與了關注的，例如擴展性、性能、安全性、集中監控及可視化、可靠性等。同時，也有一些是專門面向SDN網絡的，例如OpenFlow支持，網絡虛擬化和網絡編程能力等。

應當關注SDN控制器的核心要素

雖然Linux基金會旗下的多廠商OpenDaylight項目的出現為統一的模塊化控制器架構所需的SDN堆棧帶來了希望，但是對于控制器需要提供什么樣的特定服務，廠商當中仍然存在著許多不同的意見。用戶的壓力在于確定SDN控制器具有什么樣的能力，以及這些功能是否能夠幫助實現期望的目標。即便如此，消費者也難以購買到一個獨立的SDN控制器。實際情況是廠商常常將控制器捆綁在整個SDN套裝之中，這個套裝通常包括：應用軟件、控制器和網絡硬件。

即便你考慮從廠商那里購買一個整體解決方案，控制器的功能也可能出現麻煩。畢竟，軟件定義網絡正在迅速發展，而最初的整體解決方案會顯得陳舊。因此我們有眾多的因素需要考慮，細述如下。

原始性能

談到原始性能，我們首先需要明確SDN控制器的作用。通常，SDN控制器的功能是將網絡環境中的控制與數據平面互相分離。換句話說，控制器將告訴網絡設備如何轉發流量(控制平面)，但是它們并不真正轉發這些流量(數據平面)。這種情況在OpenFlow(OF)網絡中非常常見。在OpenFlow網絡中，SDN控制器主要用于對網絡設備中的OF表單進行編程。

在OpenFlow網絡中，OF交換機接收數據包并根據流表處理這些數據包。但是如果流表中的數據包沒有匹配的條目，將會怎樣?在這種情況下，OF交換機將把數據包發給OF控制器，這實際上相當于在問“我應該怎么處理這些數據包?”。OF控制器來決定當數據包與流匹配時交換機應當做些什么，并對交換機進行編程。這一程序被稱為“流安裝”。

由于擴展方面的需求，SDN控制器每秒的流安裝量受到了高度重視。通常，流安裝在SDN中會存在一個性能瓶頸。但是不要想當然的認為，在大量交換機和你希望控制的龐大微流數量共同作用下，它們很快就會超過控制器流安裝能力。必須牢記并不是每個流都需要與控制器聯系。只有那些還沒有被識別或編程的流才需要這一步驟，而這通常只是例外情況。

對于廠商來說，他們非常清楚OpenFlow網絡的流安裝性能所帶來的挑戰。廠商們已經制訂了許多緩解控制器瓶頸的策略。因此不要因為原始性能數據不佳就簡單地將某一控制器選擇排除在外。廠商可能有辦法優化你的網絡環境，將流安裝的需求量降到***限度。在這些緩解辦法當中，有一種名為流通配符技術。該技術允許通過一個單一的流條目處理眾多微流。

拓撲

在評估SDN控制器時另一個要考慮因素是你的網絡拓撲。讓我們先考慮一下LAN和WAN的區別。你想用軟件定義網絡中的哪一部分?盡管LAN是典型的SDN使用案例，但是如果你希望橫跨WAN部署網絡虛擬化，那會是什么情況?控制器在這一模式中將如何工作?這在很大程度上是一個有關功能性的問題。當你的SDN環境對于單個控制器來說顯得過大因而無法有效管理時，供應商會提供什么樣的選項幫助你向廣域網擴展?

采用中央控制器方式的SDN解決方案可以進行橫向擴展。換句話說，你可以增加控制器以應對額外的交換機。不過這里存在一個非常棘手的問題，這些交換機彼此之間將如何進行通信。

對此，廠商給出了許多種答案。盡管業內很早就展開了對控制器彼此對話方式進行標準化的討論，但是在大多數情況下，目前的解決方案還只是局限于特定的控制器。一個常見的技術組合是通過BGP協議實現控制器之間的信息交換。在這種方式中，控制器知道如何查找網絡中不同的軟件定義部分，并在兩個區域之間轉發流量。如果這一功能對你來說非常重要，那么你需要向備選的供應商詢問這個關鍵性問題。

雖然許多SDN解決方案能夠支持一個中央控制器，但是中央化控制器的概念仍然存在一個潛在的問題。首先是控制平面的流量(如從控制器到網絡交換機的指令)如何被傳輸。帶內通信意味著控制平面的流量將使用所有正常網絡流量所使用的路徑，帶外(OOB)通信意味著傳輸控制平面的流量需要一個獨立的物理網絡。

帶內通信受到了一些希望通過“可達性”調整網絡拓撲的廠商們的支持。這一方案的理念是，如果網絡設備不再能夠被控制器控制，那么拓撲將會發生調整，控制器能夠發現這些變化并做出相應調整。帶外通信也受到了一些廠商的支持。這部分廠商主要是希望確?？刂破髦g和交換機之間的低延遲，提升安全性，消除控制平面流量丟失所造成的數據流量風險。

第二個關于中央控制器的顧慮是這些控制器將被實現中央化控制的方式。智能化中央化控制并不一定意味只有一個物理設備或是一組冗余設備來擔當SDN控制器。許多廠商將控制平面功能分散至能夠相互通信并共享數據庫的分布式虛擬機當中。這些組件可能會向控制器軟件的核心部分反饋信息，但是也有可能是向虛擬機反饋信息。物理控制器或控制器集群，以及履行控制平臺職責的分布式虛擬機這幾種模式在目前的SDN產品當中都存在。

能力

值得注意的是，并非所有SDN控制器都具有相同的能力。這里的能力并不是指控制器流安裝等原始性能，而是指控制器對網絡的實際操控能力。大部分網絡運營者并不僅僅尋找一款OpenFlow控制器，而是希望它讓盡可能多的網絡元素配置實現自動化。此時，你需要問廠商以下一些問題，包括：

·這一控制器將與哪些設備進行對話?你需要知道，這一控制器是否除了與網絡交換機對話外，還可以與防火墻、負載均衡設備、虛擬交換機、云編排工具以及其他設備對話。

·該供應商擁有哪些合作關系?許多SDN控制器廠商都與主要的網絡廠商建立了戰略同盟關系。這些合作使得SDN控制器與合作廠商的工具之間更容易通信。不過，并非所有的SDN廠商都有著相同的合作關系。因此在評估SDN控制器時，搞清楚該廠商擁有哪些合作關系，以及這些合作關系促成了哪些合作成果非常關鍵。

·現有應用都有哪些?一些SDN控制器更像是一個空白的畫板——能夠展示任何東西，但是首先需要有人在上面作畫才行。另有一部分SDN控制器已經建立了其應用生態環境——有人已經在上面為你畫了非常漂亮的畫。搞清楚其現在都有些什么應用，對于你決定讓SDN控制器在網絡中發揮多大作用將大有幫助。

·控制器的API是否已經被明確?API是從控制器中獲取和向控制器發送信息的機制，網絡應用程序會通過北向API告訴控制器它們需要什么。API是自動化和編配的關鍵。例如，你的機構能夠以多高的效率利用控制器API?對于正在尋求整體解決方案的用戶，他們可能并不關心這個。但是對于那些希望編寫自己的網絡應用程序的用戶來說，這一點非常關鍵。

開放vs.廠商鎖定

傳統的網絡協議在廠商之間具有很大程度的互操作性。例如，一家廠商的使用BGP協議的設備也可以被其他廠商使用BGP協議的設備所理解。雖然廠商可能會在協議中增加一些私有特性，但是在基本上通用網絡設備廠商都會遵守一條底線。

在SDN方面，情況卻并非如此。目前還沒有創建SDN控制器的統一方式，也沒有一套關于SDN必須具備哪些功能的要求。接觸的控制器和架構越多，你就越會發現它們之間存在著相當大的差異。這些都是意料之中的事情。由于SDN還是一項新興技術，因此廠商都在發布能夠代表其SDN觀念的控制器，以盡可能地在市場中突出自己，從而力爭成為市場***。

對于用戶來說，由于缺乏標準，導致他們在控制器采購中遇到了許多尷尬問題。首先是這個控制器是不是將你套牢在一個特定解決方案當中?這是一個需要回答的重要問題。盡管許多SDN解決方案都具有強大的能力，但是它們可能只針對特定類型的用戶，幫助他們解決某一單一問題。雖然目前這一解決方案可能會為你帶來優勢，但是未來它們可能會成為你的包袱。例如，若干年后你可能會更換你的負載平衡設備供應商以減少運營支出，但是SDN控制器及其相關應用可能無法與其他廠商開發的負載平衡設備協同工作。廠商鎖定隱藏的風險值得我們在決策時謹慎考慮。

·用戶能夠轉而使用其他的控制器嗎?如果能，過渡應當如何進行?表面看來，這與其他的顧慮沒有太多的不同。例如，從路由器供應商A更換至供應商B需要對產品的功能和操作性進行考慮——B供應商的產品能否滿足你的要求?你的網絡團隊能否管理B供應商的路由器?但在SDN控制器方面，更換供應商的挑戰更為復雜。這需要回到控制器究竟在為你做什么這一概念上來看。標準遵從性可以極大地降低更換路由器廠商所存在的風險，但是在SDN領域中，還沒有類似的標準出臺。你的網絡應用是否能夠與不同的控制器協同工作?如果不進行適當修改，那么為某一控制器編寫的應用很可能無法在其他控制器上工作。或許OpenDaylight組織能夠改變這一現狀，但是目前網絡用戶必須要花時間了解SDN控制器，以搞清楚是否自己在某些地方被廠商鎖定了。

總之，購買SDN控制器并不是一件無關緊要的小事。此類投資不僅僅需要了解控制器的能力和性能，還需要搞清楚控制器是如何解決特定網絡問題的。在添加SDN控制器之前你必須要熟悉自己的網絡功能。花些功夫進行研究對防止大的投資失誤很有幫助。