OVN总结

￡神魔★判官ぃ 2022-05-27 02:55 376阅读 0赞

![20180410144819789][]

#     #

参考：https://www.sdnlab.com/18600.html

# 三、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的架构和分析 #

先来一张简单明了的架构图  
![OpenStack-SDN-controller-OVN-fig-2.png][]  
看完上图，感觉OVN的架构很简单是不？ 再看看我从网上找的另一张更详细的架构图：  
![OpenStack-SDN-controller-OVN-fig-3.jpg][]  
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 协议栈来实现。

# OVN实验： #

https://blog.csdn.net/zhengmx100/article/details/71698641

## *OVN部署框架* ##

OVN对于网络功能的实现，秉承的是分布式思想。因此网络功能都分布在计算节点，并且没有一个专门的网络节点。但是OVN需要独立的Database node。这是因为OVN目前采用ovsdb-server作为其DB，一方面，这对于OVN的部署很方便，因为OVN本身就基于OVS，采用ovsdb-server可以避免新增依赖。但是另一方面，ovsdb-server之前的主要应用场景是给OVS存储hypervisor本地的虚拟网络设备信息，而OVN是一个集群内运行的软件，ovsdb-server明显不能胜任这种大规模的数据读写。同时，前面说过ovn-northd是一个集中式进程，因此用一个独立的Database node来运行ovn-northd并存储Northbound DB和Southbound DB，可以一定程度的缓解瓶颈问题。

![v2-c466aba8793905421f2b9b22efe43a56_hd.jpg][] OVN与OpenStack集成之后的运行框架如下图所示 ：

![20180410152406161][]

[20180410144819789]: /images/20220527/0770033f37bf4c2e922775633dd01b00.png
[OpenStack-SDN-controller-OVN-fig-2.png]: /images/20220527/bc804108be9a4d14ad2e0457e020178d.png
[OpenStack-SDN-controller-OVN-fig-3.jpg]: /images/20220527/98650c012a1840919a0163ea62d894b2.png
[v2-c466aba8793905421f2b9b22efe43a56_hd.jpg]: /images/20220527/0b1c9592f41f433ab2a7bb2f35b2d86b.png
[20180410152406161]: /images/20220527/73f1438ee58d482aa7a9be08b314d63c.png