參考鏈接
一、爲什麼OVN會出現？
衆所周知，OpenvSwitch 以其豐富的功能和不錯的性能，已經成爲 Openstack 部署中最受歡迎的虛擬交換機。由於 Openstack Neutron 的架構引入了一些性能問題，比如 neutron-server 要與非常多的 agent 通信，RPC 就是一個性能瓶頸，還有 neutron 裏面用到非常多的 namespace，namespace 資源有限而且系統開銷比較大，這也是一個性能瓶頸。OVS 社區覺得從長遠來看，Neutron 應該讓一個其它的項目來做虛擬網絡的控制平面，Neutron 只需要提供 API 的處理，於是 OVS 社區推出了 OVN（Open Virtual Switch）這個項目，OVN 是 OVS 的控制平面，它給 OVS 增加了對虛擬網絡的原生支持，大大提高了 OVS 在實際應用環境中的性能和規模。
OpenvSwitch （OVS） 以其豐富的功能和相對優秀的性能，成爲OpenStack中廣泛使用的虛擬交換機。下圖是2年前的一個調查，時過境遷，nova-network已經被廢棄，OpenvSwitch如今的佔有率肯定會更高。
OVS甚至可以說是網絡虛擬化裏最重要的工業級開源產品，OVS模仿物理交換機設備的工作流程，實現了很多物理交換機當時才支持的許多網絡功能。OVN提供了許多原生的虛擬網絡功能，提升了OVS的工作效率和性能。
1.1、OVS和OVN網絡方案的能力
OVS 只是一個單機軟件，它並沒有集羣的信息，自己無法瞭解整個集羣的虛擬網絡狀況，也就無法只通過自己來構建集羣規模的虛擬網絡。這就好比是單機的 Docker，而 OVN 就相當於是 OVS 的k8s，它提供了一個集中式的 OVS 控制器。這樣可以從集羣角度對整個網絡設施進行編排。同時 OVN 也是新版 OpenStack 中 Neutron 的後端實現，基本可以認爲未來的 OpenStack 網絡都是通過OVN 來進行控制的。
OVN是OpenvSwitch項目組爲OpenvSwitch開發SDN控制器，同其他SDN產品相比，OVN對OpenvSwitch 及OpenStack有更好的兼容性和性能
open-vswitch非常適合作爲虛擬機環境中的虛擬交換機。除了向虛擬網絡層公開標準控制和可見性接口外，它還設計爲支持跨多個物理服務器的分發。open-vswitch支持多種基於Linux的虛擬化技術，包括Xen/XenServer、KVM和VirtualBox。
1.2、已經實現從OVS 平滑升級到 OVN
OVN 對於運行平臺沒有額外的要求，只要能夠運行 OVS，就可以運行 OVN，所以從 OVS 升級到 OVN 是非常簡單快捷的。原有的網絡、路由等數據不會丟失，也不需要對這些數據導入導出來進行數據遷移
另外 OVN 可以和很多 CMS（Cloud Management System）集成到一起，尤其是OpenStack Neutron，這些 CMS 只需要添加一個 plugin 來配置 OVN 即可。
1.3、OVN社區
1.3.1、VMware
OVS是Nicira發佈的開源虛擬交換機。OVS從發佈到現在一直是業界最流行的虛擬交換機。2012年VMware以12.6億美元收購Nicira 。VMware在OVS上繼續投入更多的資源，是目前OVS/OVN社區的最大貢獻者。
1.3.2、Ebay
GO OVN 是 eBay 開源一個 GO 庫，使用原生 OVSDB 協議訪問 OVN Northbound DB，基於 OVSDB 庫 但使用自己的分支。
1.3.3、靈雀雲
二、OVN的實現了哪些功能？擁有哪些特性？
- Logical switches：邏輯交換機，用來做二層轉發。
- L2/L3/L4 ACLs：二到四層的 ACL，可以根據報文的 MAC 地址，IP 地址，端口號來做訪問控制。
- Logical routers：邏輯路由器，分佈式的，用來做三層轉發。
- Multiple tunnel overlays：支持多種隧道封裝技術，有 Geneve，STT 和 VXLAN。
- TOR switch or software logical switch gateways：支持使用硬件 TOR switch 或者軟件邏輯 switch 當作網關來連接物理網絡和虛擬網絡。
- 小結：OVN 給 Neutron帶來實現機制方面的變化
三、系統架構
首先講一下OVN工作機制中的2種角色：
- OVN Central ——目前只能有一臺主機承擔這個角色。該主機將成爲和外部資源（比如雲管理平臺）集成的API中心節點。中心節點運行着OVN 北向數據庫和OVN南向數據庫。OVN北向數據庫，用於描述上層的邏輯網絡組件，比如邏輯交換機/邏輯端口。南向數據庫，其將北向數據庫的邏輯網絡數據格式轉換爲物理網絡數據格式並進行存儲。
- OVN Host ——所有提供虛擬機或虛擬網絡的節點。OVN Host 運行着 “chassis controller” ，它上連OVN南向數據庫並作爲其記錄的物理網絡信息授權來源，下接OVS 併成爲其openflow 控制器。
Openstack/CMS plugin 是 CMS 和 OVN 的接口，它把 CMS 的配置轉化成 OVN 的格式寫到 Nnorthbound DB 裏面。
OVN由以下組件構成：
### 3.1、CMS（雲管理系統）
這是OVN的最終用戶（通過其用戶和管理員）。與OVN集成需要安裝與CMS特定的插件和相關軟件（見下文）。OVN最初的目標CMS是OpenStack。我們通常會說一個CMS，但多個CMS也可以管理一個OVN的不同部分。
3.2、OVN/CMS插件
是連接到OVN的CMS組件。在OpenStack中，這是一個Neutron插件。該插件的主要目的是轉換CMS中的邏輯網絡的配置爲OVN可以理解的中間表示。這個組件是必須是CMS特定的，所以對接一個新的CMS需要開發新的插件對接到OVN。所有在這個組件下面的其他組件是與CMS無關的。
3.3、northbound database
存儲邏輯交換機、路由器、ACL、端口等的信息，目前基於ovsdb-server，未來可能會支持etcd v3。類似 apiserver，提供了一組高層次的網絡抽象，這樣在真正創建網絡資源時無需關心負責的邏輯規則，只需要通過 Northoboud DB 的接口創建對應實體即可。
Northbound DB 裏面存的都是一些邏輯的數據，大部分和物理網絡沒有關係，比如 logical switch，logical router，ACL，logical port，和傳統網絡設備概念一致。
開放虛擬交換機數據庫（OpenvSwitch Database,OVSDB）是開放虛擬交換機中保存的各種配置信息（如網橋、端口）的數據庫，是針對OpenvSwitch開發的輕量級數據庫。
OVSDB是一個輕量級的數據庫，其實它只是一個JSON文件，默認路徑爲/etc/openvswitch/conf.db。記錄的網橋、端口、QOS等網絡配置信息是以JSON格式（schema）保存的，通常schema在/usr/share/openvswitch/vswitch.ovsschema中。
- ovn-northd: 集中式控制器，負責把northbound database數據分發到各個ovn-controller
OVN-northd 類似於一個集中的控制器，它把 Northbound DB 裏面的數據翻譯一下，寫到 Southbound DB 裏面。
3.4、southbound database
類似於etcd(不太準確)，存儲集羣視角下的邏輯規則。
基於ovsdb-server（未來可能會支持etcd v3），包含三類數據
- 物理網絡數據，比如VM的IP地址和隧道封裝格式
- 邏輯網絡數據，比如報文轉發方式
- 物理網絡和邏輯網絡的綁定關係，比如邏輯端口關聯到哪個 HV 上面。
3.5、ovn-controller
運行在每臺機器上的本地SDN控制器，類似於kubelet，負責和中心控制節點通信獲取整個集羣的網絡信息，並更新本機的流量規則。ovs-vswitchd 和 ovsdb-server 可以理解爲單機的docker 負責單機虛擬網絡的真實操作。
ovn-controller 是 OVN 裏面的 agent，類似於 neutron 裏面的 ovs-agent，它也是運行在每個 HV 上面，北向，ovn-controller 會把物理網絡的信息寫到 Southbound DB 裏面，南向，它會把 Southbound DB 裏面存的一些數據轉化成 Openflow flow 配到本地的 OVS table 裏面，來實現報文的轉發。
ovn-controller是每個hypervisor和軟件網關上的OVN代理。
- 北向，它連接到OVN南行數據庫以瞭解OVN配置和狀態，並把hypervisor的狀態填充綁定表中的Chassis列以及PN表。
- 南向，它連接到ovs-vswitchd作爲OpenFlow控制器用於控制網絡通信，並連接到本地ovsdb-server以允許它監視和控制Open vSwitch的配置。
四、OVN 給 Neutron帶來實現機制方面的變化
4.1、架構的改變
從 OVN 的架構可以看出，OVN 裏面數據的讀寫都是通過OVSDB來做的，取代了 Neutron 的消息隊列機制，所以有了 OVN 之後，Neutron 裏面所有的 agent 都不需要了，Neutron 變成了一個 API server 來處理用戶的 REST 請求，其他的功能都交給 OVN 來做，只需要在 Neutron 裏面加一個 plugin 來調用配置 OVN。
Neutron 裏面的子項目networking-ovn就是實現 OVN 的 plugin。Plugin 使用 OVSDB 協議來把用戶的配置寫在 Northbound DB 裏，ovn-northd 監聽到 Northbound DB 配置發生改變，然後把配置翻譯到 Southbound DB 裏面。 ovn-controller 監控到 Southbound DB 數據的發生變化之後，進而更新本地的流表。
OVN 裏面報文的處理都是通過 OVS OpenFlow 流表來實現的，而在 Neutron 裏面二層報文處理是通過 OVS OpenFlow 流表來實現，三層報文處理是通過 Linux TCP/IP 協議棧來實現
OVN L3 對比 Neutron L3
Neutron 的三層功能主要有路由，SNAT 和 Floating IP（也叫 DNAT），它是通過 Linux kernel 的 namespace 來實現的，每個路由器對應一個 namespace，利用 Linux TCP/IP 協議棧來做路由轉發。
在支持 DVR（分佈式虛擬路由器，在 Juno 版本增加的一個功能）之前，Neutron 的三層功能是在網絡節點做的，所有東西向跨網段的流量都需要經過網絡節點做路由，這使得網絡節點成爲瓶頸。有了 DVR 之後，路由變成了分佈式，每個計算節點上面都可以做路由，東西向流量直接通過計算節點路由而不需要經過網絡節點，Floating IP 也是在計算節點上面實現的，對於有 floating IP 的 VM 訪問公網，直接走計算節點上面的路由器出去，對於沒有 floating IP 的 VM 訪問公網纔會從網絡節點的路由器 SNAT 出去。DVR 減輕了網絡節點的負擔，但是也引入了一些問題，DVR 需要每個計算節點佔用 2 個公網 IP，並且 DVR 還不能和 FWaaS，VPNaaS 和 LBaaS 集成起來。
OVN 支持原生的三層功能，不需要藉助 Linux TCP/IP stack，用 OpenFlow 流表來實現路由查找，ARP 查找，TTL 和 MAC 地址的更改。OVN 的路由也是分佈式的，路由器在每個計算節點上都有實例，和 DVR 一樣。有了 OVN 之後，不需要 neutron l3 agent 了。
不過目前 OVN 三層功能只能做東西向路由，Floating IP 的設計和 DVR 一樣，方案還在 review 過程中，SNAT 的實現方法還沒有確定。所以如果需要所有的三層功能，暫時還是要使用 neutron l3 agent。
南北流量:
客戶端和服務器之間的流量被稱爲南北流量。簡而言之，南北流量是server-client流量。
東西流量:
第二種流量即不同服務器之間的流量與數據中心或不同數據中心之間的網絡流被稱爲東西流量。簡而言之，東西流量是server-server流量。
五、OVN和其它通用SDN控制器的主要區別
- OVN專注於實現雲計算管理平臺場景下的SDN控制器
- OVN專注於實現二層和三層網絡功能。除了在傳輸層實現了基於L4的ACL 外，基本上不在L4 ~ L7層實現某些功能。
5.1、OVS 和 Open Day Light區別
這兩個都叫SDN，用的場景不一樣，現在雲計算火了，各路神仙都想賺錢，搞得各種概念一坨一坨的，我個人理解在下面，不見得對，不喜勿噴
OpenVSwith 最開始是仿照VMware的DVS做出來的，主要用於虛擬機的二層網絡包交換，由於一部分Nicira的人是從VMW過去的，對DVS的弱點做了補充，加入了OpenFlow的內容，原來的DVS是控制不了物理的交換機和路由器的，但Nicira的openflow controller可以控制虛擬交換機以外的物理交換機和路由器。
OpenDayLight，從一開始就是按照Openflow的想法，用於物理交換機和路由器的，這局缺少了對虛擬機的支持。
所以最大的區別就是，opendaylight不是爲虛擬化環境用的，而只是用於物理的交換機和路由器的。