OpenStack中SDN泛談4 (SDN發展與架構)

現實世界的SDN遠多於這個系列的介紹，這個系列只是選取了開源的，並且與OpenStack相關的SDN做介紹。還有各種沒有與OpenStack做集成的，或者是廠商閉源的SDN。一個個去分析似乎也不太現實，我們這次來看看SDN的共性。畢竟掌握了本質再來看個體更有效。

SDN的發展

有關軟體控制網路的想法很早就提出了，在上世紀90年代，網路可編程（programmable network）的概念就在ActivenNetworking中提出。而控制層面（control plane）的分離在2004年也由IETF ForCES Working Group提出。但是在OpenFlow提出之前，這些都只是小範圍的研究討論，發展並不快。雖然說OpenFlow不能代表SDN，但是不可否認，OpenFlow的出現了加速了SDN的發展。現在的SDN體系也是由早期的OpenFlow Controller發展而來。之後發展成SDN Controller，也就是說SDN的範圍不再局限於OpenFlow。近期的SDN發展，更多提的是SDN platform和SDN operating system，講的都是基於SDN構建平台，構建生態。這兩者有什麼區別，目前我也很難從字面上給出解釋。不過這兩者都更進一步，不再局限於網路，而是以網路為中心，做更多的事情。

SDN的發展時間與OpenStack的發展時間有一定的重合。而Cloud Networking是SDN的主要場景之一，兩者的碰撞不可避免。一方面，OpenStack的流行能帶動SDN的發展，另一方面，SDN的演進可以提升OpenStack集群的規模。以後一定能看到更多的OpenStack + SDN的應用。

SDN架構

這個系列之前介紹了幾種SDN，細心的朋友估計也能看出SDN的架構大致來了，下面我來總結一下吧。

Application & Orchestration Tier

傳統的SDN架構裡面沒有這一層，在SDN platform裡面新增了這一層。而OpenStack也在這一層。SDN想要接入到OpenStack，必須要在這一層完成適配，將OpenStack的請求轉換成SDN的請求。在這一層不需要關心SDN底層的具體實現，因為SDN已經將底層網路抽象成純軟體的概念。

Northbound Interface

Northbound Interface是SDN將底層網路抽象成軟體概念，並暴露出來的介面。

Application & Orchestration Tier通過Northbound Interface接入SDN Controller。這個介面通常是，但不局限於是RESTful API。像ODL還提供了OSGI介面，而OVN和Dragonflow直接提供DB讀寫的介面。

換一個角度，不論底層的SDN是什麼，單看OpenStack提供的networking服務，Neutron server也可以看成是一個Northbound Interface。因為它提供了相應的網路數據模型的RESTful API。

Control Plane Tier

SDN的最核心部分。又分成了幾個部分：

Database

SDN自己是一個集群內運行的軟體。有自己的狀態和數據，因此必須要有一個Database來存儲相關的數據。而SDN主要是進行網路運算，網路運算的要求就是高速，低延時。因此對Database的性能要求也比較高。基於內存的NoSQL資料庫通常具有更好的性能，更快的響應速度，這個系列前面介紹的幾乎所有的SDN都是採用的這類資料庫。在這類資料庫中，Cassandra是選用最多的資料庫，OpenContrail，Midonet，Dragonflow都支持Cassandra。並且有報告表明，Cassandra的性能的確優於同類的其他資料庫。

鑒於Database的重要性，通常會將Database部署在獨立的節點，並且考慮到HA和水平擴展，Database節點也會部署成一個集群。

Message

由於SDN是一個集群內運行的軟體，因此SDN需要定義自己的消息通訊機制，以供集群內的各個節點之間通訊。像ODL和Midonet採用的是RPC作為消息機制，OpenContrail則是參考MPLS VPN自己制定的消息通訊機制，OVN和Dragonflow則是簡單的消息發布訂閱機制。

SDN Controller

終於到了SDN Controller，根據ONF（Open Networking Foundation）的定義，SDN Controller是一個邏輯集中的控制器。邏輯集中的控制器，那物理上就不一定集中了。實際上哪怕是集中式SDN控制器，出於HA和水平擴展的考慮，也不會部署成物理集中。而SDN控制器也朝著分散式的方向發展。像OpenContrail，Midonet，OVN，Dragonflow都有不同程度的分散式。有關集中式，分散式控制器的特點，我在之前的SDN閑聊中有過介紹，這邊就不再多說。

SDN控制器包含了各個網路功能的實現。也就是一個個Network service。具體的來說，Network service就是將Northbound的抽象數據和Southbound的具體網路協議做了適當的轉換和翻譯。也就是這樣，原本生硬晦澀的network element，經過Network Service可以靈活的通過軟體來定義。

nnnnnnnnnnnnnnnnnnnnnnnSDNnController還包括了數據層面（Data plane）的介面，當然，這個介面一般不會太具體。

Southbound Protocol

nnnnnnnnnnnnnnnnnnn各類控制協議和網路協議。雖然感覺上很多，但是最常見的還是OpenFlow和NetConf。這是networknelements暴露出來的介面，只有支持相應協議的網路設備才有可能成為SDN的一部分。

Data Plane Tier

這一層就是實際的網路設備層，包含各種網路設備。網路設備本身也分為physicalndevice和virtual device。Physicalndevice就是支持OpenFlow或者NetConf或者其他控制協議的交換機，路由器和其他的網路設備。這些硬體設備目前佔據SDN市場的最大份額，也是各大傳統網路設備廠商的地盤。Virtual device，就是支持OpenFlow或者其他控制協議的虛擬網路設備。像OVS，OpenContrail的vRouter。Virtual device被認為是最有發展前景的，並且在成本上也優於physicalndevice。

SDN的功能

雖然Cloud computing對SDN的意義非常大，但是SDN並非是為了Cloud computing而誕生的。SDN的提出是為了簡化日趨複雜的網路架構，降低網路管理的難度和成本。隨著SDN和Cloud computing的發展，數據中心趨於虛擬化。SDN的初衷倒也是契合Cloud networking的目的。從發展趨勢上看，SDN具備了以下功能才能算是功能完善。

• Cloud Networking：為數據中心和雲提供虛擬化的網路服務。這是所有SDN的標配，要是沒有這個功能，都不好意思跟別人說自己是SDN。

• NFV： 作為虛擬網路界的另一股發展力量。NFV在電信運營商場景非常受歡迎。藉助SDN可以更好的實現NFV。像ODL和OpenContrail明確表示了支持NFV場景，而ONOS主打SP場景，在NFV領域也當仁不讓。在OpenStack環境下，還可以藉助networking-sfc項目實現NFV，Dragonflow目前在這方面有所動作。

• Container Network：容器這幾年的發展是如火如荼，容器網路作為容器技術的一部分，也是各個SDN發展的重點。在OpenStack環境下，可以藉助kuryr項目實現容器網路和SDN的結合。Midokura和Huawei作為kuryr項目的發起者和最大貢獻者，對應的Midonet和Dragonflow自然藉助kuryr項目實現容器網路與SDN的集成。OVN自己也在做一些容器網路集成的嘗試ovn-kubernetes。OpenContrail自己實現了容器網路的集成。從容器的發展來看，基於CNI的kubernetes網路模型接受程度更高。
• Physical provider Network：SDN雖然管理的是虛擬網路，但是有些應用場景也要求與物理網路的連通。

SDN與開源

開源只是技術的開發手段，與SDN並非強相關。一些閉源的SDN市場和口碑都不錯，例如VMware的NSX。但是從OpenStack的發展來看，SDN的開源之路似乎是趨勢。OpenStack通過開源，統一了IaaS層面的標準，為整個雲計算帶來了新的發展。現在SDN仍然沒有一個壓到一切的方案，雖然ODL和ONOS背景強大，但是似乎也並沒有讓其他SDN臣服。開源SDN仍然是一條漫漫長路。

SDN未來

SDN被認為是Next generation networking。傳統的IT、BFSI（銀行金融服務）、電信等領域，都在積極探索SDN。在移動服務和大數據分析場景下，對SDN也有一定的訴求。根據Allied Market Research的研究，在2022年，SDN的市場將達到1.3億美金。過段時間專門分析一下這個研究報告。

就像隨著數據中心的發展，Cloud computing也隨著發展一樣，隨著網路技術的發展，SDN的發展只會越來越成熟，應用越來越廣。