《軟體定義網絡：基于OpenFlow的SDN》一一3.1 SDN控制器

本節書摘來自華章計算機《軟體定義網絡：基于openflow的sdn》一書中的第3章，第3.1節,作者：siamak azodolmolky，更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視。

如後面的圖3-1所描繪的那樣，在軟體定義網絡（sdn）中，特别是openflow中，控制平面和資料平面是分離的，我們可以把兩者類比作作業系統和計算機硬體，openflow控制器（就好比作業系統）提供一個openflow交換機（就好比計算機硬體）的程式設計接口，利用這個程式設計接口，就可以開發網絡應用，完成控制和管理任務，并提供新的功能。sdn中的控制平面，特别是openflow的控制平面，在邏輯上是集中化的，是以在開發網絡應用的時候，可以把網絡視為一個系統。

由于采用應變式的（reactive）控制模型，每當需要做出決策時，openflow交換機都必須詢問openflow控制器，比如，當一個新的資料包流到達openflow交換機（即發生packet_in事件）時。由于采用基于流的控制粒度，每當把一個新的流的第一個資料包轉發給控制器進行決策（例如，詢問轉發還是丢棄）時，都會由于延遲帶來性能上的些微下降，而該流中的後續資料包流量将會以交換機硬體的線速轉發。盡管在很多情況下，第一個資料包的延時是可以忽略不計的，但是，如果中心控制器在地理上相距較遠，大多數流的持續時間又比較短暫的話（譬如，僅由一個資料包所構成的流），就有可能是一個值得關注的問題。在openflow中，還可以采取另一種主動式的（proactive）解決方案，就是将決策的政策規則從控制器推送到交換機中。

圖3-1　sdn解決方案中控制器的作用

在部署openflow（以及sdn）時，可以采用多控制器來降低延時，提高可擴充性和容錯性。openflow允許将多個控制器與一個交換機相連接配接，這樣，當發生失效事件時，後備控制器可以進行切換。在這個方面，onix和hyperflow作了進一步的嘗試，其解決方案維持了一個邏輯上集中而實體上分布的控制平面。通過啟動本地控制器之間的互相通信，降低查表的開銷，而對應用程式寫入時，依然能夠維持一個簡化的、集中式的網絡視圖。這種方案主要存在這樣一個潛在問題，即需要在整個分布式系統中維持一緻的狀态，一旦不能維持全局網絡狀态的一緻性，而網絡應用仍以為自己的網絡視圖是正确的，它就會對目前網絡狀态作出不正确的反應。