OVN入门

参考链接

如何借助 OVN 来提高 OVS 在云计算环境中的性能

OVN简介

Open vSwitch Documentation

OVSDB介绍及在OpenDaylight中的调用

OpenDaylight即将迈入“七年之痒”？

一、为什么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、灵雀云

再谈自研开源Kube-OVN， 设计思路及实现原理

二、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不是为虚拟化环境用的，而只是用于物理的交换机和路由器的。