OVN简介
作者简介：郑敏先，就职于诺云系统（上海）有限公司。工作地点为南京的诺云研发中心。担任解决方案工程师。 本人博客为：http://blog.csdn.net/zhengmx100
一、为什么OVN会出现？
OpenvSwitch （OVS） 以其丰富的功能和相对优秀的性能，成为OpenStack中广泛使用的虚拟交换机。下图是2年前的一个调查，时过境迁，nova-network已经被废弃，OpenvSwitch如今的占有率肯定会更高。
OVS甚至可以说是网络虚拟化里最重要的工业级开源产品，OVS模仿物理交换机设备的工作流程，实现了很多物理交换机当时才支持的许多网络功能。OVN提供了许多原生的虚拟网络功能，提升了OVS的工作效率和性能。
OVN是OpenvSwitch项目组为OpenvSwitch开发SDN控制器，同其他SDN产品相比，OVN对OpenvSwitch 及OpenStack有更好的兼容性和性能。
在2016年的OpenStack Austin 峰会上，OVN项目组有个演讲提到了的OVN存在的意义（目标），原文是
- Production-quality
- Straightforward design
- Scale to 1000s of hypervisors (each with many VMs/containers)
- Improved performance and stability over existing OpenStack OVS plugin
- Become preferred method for OpenStack+OVS integration for the majority of use cases
中文翻译如下：
- 可用于生产环境
- 简洁的设计
- 支持1000台以上的物理机环境（也支持相当数量的虚拟机/容器环境）
- 基于已有的OpenStack OVS 插件 来提升性能和稳定性
- 成为OpenStack+OVS集成场景下的首选方案
已经实现从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带来实现机制方面的变化。
三、OVN L3 对比 Neutron L3
Neutron 的三层功能主要有路由，SNAT 和 Floating IP（也叫 DNAT），它是通 Linux kernel 的namespace 来实现的，每个路由器对应一个 namespace，利用 Linux TCP/IP 协议栈来做路由转发。
OVN 支持原生的三层功能，不需要借助 Linux TCP/IP stack，用OpenFlow 流表来实现路由查找，ARP 查找，TTL 和 MAC 地址的更改。OVN 的路由也是分布式的，路由器在每个计算节点上都有实例，有了 OVN 之后，不需要 Neutron L3 agent 了 和DVR了。
四、OVN和其它通用SDN控制器（比如OpenDayLight）的主要区别
- OVN专注于实现云计算管理平台场景下的SDN控制器
- OVN专注于实现二层和三层网络功能。除了在传输层实现了基于L4的ACL 外，基本上不在L4 ~ L7层实现某些功能。
五、OVN的实现了哪些功能？拥有哪些特性？
最新版本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：逻辑交换机，用来做二层转发。
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的架构和分析
先来一张简单明了的架构图
看完上图，感觉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 类似于一个集中的控制器，监听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 封装格式；
二、逻辑网络数据，比如报文如何在逻辑网络中转发；
三、物理网络和逻辑网络的绑定关系，比如逻辑端口关联到哪个 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 里面，来实现报文的转发。
第2个功能的具体实现机制就是：
ovn-controller连接到到本地的ovsdb-server ，监控、读取、管理OpenvSwitch的配置信息；
ovn-controller作为ovs-vswitchd 的Openflow 控制器来控制流量的转发。另外，从架构图中就可看出ovn-controller是一种分布式SDN控制器。
ovs-vswitchd 和 ovsdb-server 是 OVS 的两个进程：
- ovs-vswitchd ：核心模块，实现交换功能，和Linux内核模块一起，实现基于流的交换；
- ovsdb-server ：是一个数据库。其保存了整个OVS的配置信息，包括接口，流表和VLAN等；ovs-vswitchd从其查询配置信息；
小结：OVN 给 Neutron带来实现机制方面的变化
从 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 协议栈来实现。