一、為什么OVN會出現(xiàn)？

OpenvSwitch （OVS） 以其豐富的功能和相對優(yōu)秀的性能，成為OpenStack中廣泛使用的虛擬交換機。下圖是2年前的一個調查，時過境遷，nova-network已經被廢棄，OpenvSwitch如今的占有率肯定會更高。

OVS甚至可以說是網絡虛擬化里最重要的工業(yè)級開源產品，OVS模仿物理交換機設備的工作流程，實現(xiàn)了很多物理交換機當時才支持的許多網絡功能。OVN提供了許多原生的虛擬網絡功能，提升了OVS的工作效率和性能。
OVN是OpenvSwitch項目組為OpenvSwitch開發(fā)SDN控制器，同其他SDN產品相比，OVN對OpenvSwitch 及OpenStack有更好的兼容性和性能。
在2016年的OpenStack Austin 峰會上，OVN項目組有個演講提到了的OVN存在的意義（目標），原文是

Production-qualityStraightforward designScale to 1000s of hypervisors (each with many VMs/containers)Improved performance and stability over existing OpenStack OVS pluginBecome preferred method for OpenStack+OVS integration for the majority of use cases

中文翻譯如下：

可用于生產環(huán)境簡潔的設計支持1000臺以上的物理機環(huán)境（也支持相當數量的虛擬機/容器環(huán)境）基于已有的OpenStack OVS 插件 來提升性能和穩(wěn)定性成為OpenStack+OVS集成場景下的首選方案

已經實現(xiàn)從OVS 平滑升級到 OVN
OVN 對于運行平臺沒有額外的要求，只要能夠運行 OVS，就可以運行 OVN，所以從 OVS 升級到 OVN 是非常簡單快捷的。原有的網絡、路由等數據不會丟失，也不需要對這些數據導入導出來進行數據遷移

另外 OVN 可以和很多 CMS（Cloud Management System）集成到一起，尤其是 OpenStack Neutron，這些 CMS 只需要添加一個 plugin 來配置 OVN 即可。

二、OVN使得Neutron組件數量減少

以最新的Ocata版本中的OVN和OVS 2.6版本來看OVN帶來的變化：

OVN自帶的（時髦的說法叫"原生"）ML2 driver替換掉 OVS ML2 driver 和 Neutron的OVS agent；OVN原生支持L3和DHCP功能，這樣就不再需要Neutron 的L3 agent、 DHCP agent 和DVR。

看明白了沒有？隨著OVN不斷添加新的功能，大量的Neutron agents就被干掉了。這樣的話，組件數量將會大大減少。后面會詳細講OVN 給 Neutron帶來實現(xiàn)機制方面的變化。

三、OVN L3 對比 Neutron L3

Neutron 的三層功能主要有路由，SNAT 和 Floating IP（也叫 DNAT），它是通 Linux kernel 的namespace 來實現(xiàn)的，每個路由器對應一個 namespace，利用 Linux TCP/IP 協(xié)議棧來做路由轉發(fā)。

OVN 支持原生的三層功能，不需要借助 Linux TCP/IP stack，用OpenFlow 流表來實現(xiàn)路由查找，ARP 查找，TTL 和 MAC 地址的更改。OVN 的路由也是分布式的，路由器在每個計算節(jié)點上都有實例，有了 OVN 之后，不需要 Neutron L3 agent 了 和DVR了。

四、OVN和其它通用SDN控制器（比如OpenDayLight）的主要區(qū)別OVN專注于實現(xiàn)云計算管理平臺場景下的SDN控制器OVN專注于實現(xiàn)二層和三層網絡功能。除了在傳輸層實現(xiàn)了基于L4的ACL 外，基本上不在L4 ~ L7層實現(xiàn)某些功能。五、OVN的實現(xiàn)了哪些功能？擁有哪些特性？

最新版本OVN的高級特性，英文原文如下：

（可以和OVS的特性對比一下，就知道OVN和OVS 的側重點。見我的另一篇博文http://blog.csdn.net/zhengmx100/article/details/54729272）
Provides virtual networking abstraction for OVS, implemented using L2 and L3 overlays, but can also manage connectivity to physical networks
Supports flexible ACLs (security policies) implemented using flows that use OVS connection tracking
Native support for distributed L3 routing using OVS flows, with support for both IPv4 and IPv6
ARP and IPv6 Neighbor Discovery suppression for known IP-MAC bindings
Nativesupport for NAT and load balancing using OVS connection tracking
Native fully distributedsupport for DHCP
Works with any OVS datapath (such as the default Linux kernel datapath, DPDK, or Hyper-V) that supports all required features (namely Geneve tunnels and OVS connection tracking. See the datapath feature list in the FAQ for details.)
Supports L3 gateways from logical to physical networks
Supports software-based L2 gateways
Supports TOR (Top of Rack) based L2 gateways that implement the hardware_vtep schema
Can provide networking for both VMs and containers running inside of those VMs, without a second layer of overlay networking

選取幾個重點講一下：
Logical switches：邏輯交換機，用來做二層轉發(fā)。
L2/L3/L4 ACLs：二到四層的 ACL，可以根據報文的 MAC 地址，IP 地址，端口號來做訪問控制。
Logical routers：邏輯路由器，分布式的，用來做三層轉發(fā)。
Multiple tunnel overlays：支持多種隧道封裝技術，有 Geneve，STT 和 VXLAN。
TOR switch or software logical switch gateways：支持使用硬件 TOR switch 或者軟件邏輯 switch 當作網關來連接物理網絡和虛擬網絡。

六、OVN的架構和分析

先來一張簡單明了的架構圖

看完上圖，感覺OVN的架構很簡單是不？ 再看看我從網上找的另一張更詳細的架構圖：

OVN/CMS Plugin 是Neutron的一個插件，作為OVN 和 CMS 之間的接口 。它將CMS中的數據（存儲在Neutron DB）翻譯成一種“中間格式”。

這種中間格式就是邏輯網絡配置數據，這樣CMS中的網絡配置數據就能夠被OVN理解 （準確的說是能夠被OVN的Northbound DB 所理解）。

Northbound DB 里面存的就是上面OVN/CMS Plugin翻譯之后的邏輯網絡的相關數據。比如 logical switch，logical router，logical port和ACL。

Northbound DB 里面的幾乎所有的內容都是由 CMS 產生的

OVN-northd 類似于一個集中的控制器，監(jiān)聽Northbound DB 數據庫的內容變化，它把 Northbound DB 里面的邏輯網絡的相關數據翻譯成 Southbound DB 可以理解的格式（logical datapath flows），并傳遞給 Southbound DB 進行存儲，進而被所有的chassis 讀取和應用。 （關于chassis這個概念 ，本人會在下一篇博文中進行介紹。）

Southbound DB 處在 OVN 架構的核心，它是 OVN 中最重要的部分，它跟 OVN 的其他組件都有交互。 里面存的數據和 Northbound DB 語義完全不一樣，主要包含 3 類數據(第二類數據就是OVN-northd 從Northbound DB 翻譯過來的)：

一、物理網絡數據，比如 hypervisor的 IP 地址，hypervisor的 tunnel 封裝格式；

二、邏輯網絡數據，比如報文如何在邏輯網絡中轉發(fā)；

三、物理網絡和邏輯網絡的綁定關系，比如邏輯端口關聯(lián)到哪個 hypervisor上面。這類數據存儲在binding表中，字段有uuid,chassis, logical_datapath, logical_port, mac, parent_port, tag, tunnel_key。

如果對這里的2次翻譯不太明白的話，我舉個例子：
有四個人在一起聊天，他們分別來自不同國家。
一個英國人只會英語，
一個伊拉克人同時掌握英語和阿拉伯語，
一個伊朗人同時掌握阿拉伯語和俄羅斯語，
一個俄羅斯人只會俄羅斯語。
英國人講的話要被俄羅斯人理解是不是要先被伊拉克人翻譯為阿拉伯語，再被伊朗人翻譯俄羅斯語。 這個過程需要2個人進行翻譯。

ovn-controller 是 OVN 里面的 agent，類似于 Neutron 里面的 ovs-agent，它也是運行在每個 hypervisor和軟件網關之上。

它有下面2種功能：
（1）把物理網絡的信息寫到 Southbound DB 里面（這類信息就包括 Southbound DB中的第一類數據）；
（2）把 Southbound DB 里面存的一些數據轉化成 Openflow flow 配到本地的 OVS table 里面，來實現(xiàn)報文的轉發(fā)。

第2個功能的具體實現(xiàn)機制就是：
ovn-controller連接到到本地的ovsdb-server ，監(jiān)控、讀取、管理OpenvSwitch的配置信息；

ovn-controller作為ovs-vswitchd 的Openflow 控制器來控制流量的轉發(fā)。另外，從架構圖中就可看出ovn-controller是一種分布式SDN控制器。

ovs-vswitchd 和 ovsdb-server 是 OVS 的兩個進程：

ovs-vswitchd ：核心模塊，實現(xiàn)交換功能，和Linux內核模塊一起，實現(xiàn)基于流的交換；ovsdb-server ：是一個數據庫。其保存了整個OVS的配置信息，包括接口，流表和VLAN等；ovs-vswitchd從其查詢配置信息；小結：OVN 給 Neutron帶來實現(xiàn)機制方面的變化

從 OVN 的架構可以看出，OVN 里面數據的讀寫都是通過 OVSDB來做的，取代了 Neutron 的消息隊列機制，所以有了 OVN 之后，Neutron 里面所有的 agent 都不需要了，Neutron 變成了一個 API server 來處理用戶的 REST 請求，其他的功能都交給 OVN 來做，只需要在 Neutron 里面加一個 plugin 來調用配置 OVN。

Neutron 里面的子項目 networking-ovn 就是實現(xiàn) OVN 的 plugin。Plugin 使用 OVSDB 協(xié)議來把用戶的配置寫在 Northbound DB 里，ovn-northd 監(jiān)聽到 Northbound DB 配置發(fā)生改變，然后把配置翻譯到 Southbound DB 里面。 ovn-controller 監(jiān)控到 Southbound DB 數據的發(fā)生變化之后，進而更新本地的流表。

OVN 里面報文的處理都是通過 OVS OpenFlow 流表來實現(xiàn)的，而在 Neutron 里面二層報文處理是通過 OVS OpenFlow 流表來實現(xiàn)，三層報文處理是通過 Linux TCP/IP 協(xié)議棧來實現(xiàn)。