作者：李晓辉

联系方式：

1. 微信：Lxh_Chat

2. 邮箱：939958092@qq.com

OVN 简介

OVN是Open Virtual Network的缩写，它是一种开源的网络虚拟化解决方案，主要是为了解决虚拟机（VM）之间、容器之间以及它们与外部网络之间的通信问题。它就像是一个虚拟的“网络管理员”，帮你搞定虚拟网络里的各种事儿。

它是一个开源项目，由Open vSwitch团队发起，目的是创建一个中立的虚拟交换协议。OVN特别厉害，它不仅能实现安全组，还自带DHCP服务、三层路由（L3 routing）和网络地址转换（NAT）。而且，它同时支持二层（L2）和三层（L3）网络，这在很多软件定义网络（SDN）解决方案里是很少见的，因为很多方案只支持其中一种。

在Red Hat OpenStack Platform里，OVN是默认的SDN解决方案，它完全替换了原来的OVS ML2驱动和Neutron代理，用的是OVN ML2驱动。这个转变很自然，也很无缝，因为它和OpenStack里已经用的Open vSwitch技术很搭。而且，OVN的可扩展性比其他SDN解决方案更强，因为它不依赖Neutron代理，而是用ovn-controller和OVS流来实现所有功能。它还能直接连接虚拟机和容器，不需要配置物理网络资源，这样性能就更高了。

OVN为啥这么牛

分布式架构：OVN采用分布式架构，这意味着它可以在多个节点上运行，每个节点都负责管理一部分虚拟网络。这种架构的好处是，即使某个节点坏了，整个网络也不会瘫痪，因为它会自动把任务分配到其他节点上。
与OpenStack无缝集成：OpenStack是一个开源的云计算平台，OVN和它配合得非常好。它可以直接和OpenStack的网络服务（比如Neutron）对接，让管理员能够通过OpenStack的界面来管理虚拟网络，就像在管理物理网络一样简单。
安全性和隔离性：OVN支持虚拟网络之间的隔离，确保不同租户的网络流量互不干扰。它还提供了安全组功能，可以对虚拟机的流量进行细粒度的控制，比如允许或拒绝某些IP地址的访问，这就好比给虚拟网络加了一把锁，让网络更安全。

OVN怎么工作的

逻辑网络构建：OVN会根据你的需求创建逻辑网络，这些网络是虚拟的，就像在物理网络上画了一张虚拟的网络图。它会定义逻辑交换机、逻辑路由器等组件，这些组件虽然看不见摸不着，但它们的作用和物理网络里的交换机、路由器是一样的。
数据包转发：当虚拟机之间需要通信时，OVN会根据预先定义的规则来转发数据包。它会检查数据包的源地址、目的地址等信息，然后决定是直接转发给目标虚拟机，还是通过逻辑路由器转发到其他网络。这个过程是自动完成的，你只需要设置好规则就行。
网络状态同步：OVN的各个节点之间会不断地同步网络状态信息。比如，当一个虚拟机的IP地址发生变化时，所有节点都会立刻知道这个变化，这样就能保证整个网络的通信不会出错。

OVN的使用场景

云计算环境：在云计算平台中，OVN可以为每个租户创建独立的虚拟网络，让租户能够安全地运行自己的虚拟机和容器。
企业数据中心：企业可以用OVN来管理内部的虚拟网络，实现不同业务部门之间的网络隔离，同时还能方便地进行网络扩展和调整。
容器网络：随着容器技术的流行，OVN也可以用来管理容器之间的网络通信，为容器提供高性能、高安全性的网络环境。

OVN的架构

OVN的架构听起来可能有点复杂，但其实就像一个分工明确的团队，每个部分都有自己的职责，协同工作来管理虚拟网络。

1. OVN ML2 插件

想象一下，OpenStack的网络配置就像是一张设计图纸，OVN ML2 插件就像是一个翻译官，它把这张图纸翻译成OVN能理解的逻辑网络配置。这个插件运行在控制器节点上，监听TCP端口6641，专门负责接收和传递这些配置信息。

2. 北向数据库（Northbound，NB）

北向数据库就像是一个“存储柜”，用来保存OVN的逻辑网络配置。这些配置是从OVN ML2插件那里来的。北向数据库的作用是把配置信息整理好，方便后续的处理。

3. ovn-northd 服务

这个服务就像是一个“翻译员”，它把北向数据库里的逻辑网络配置转换成具体的“行动指南”，也就是逻辑路径流（logical path flows）。然后，它把这些“行动指南”存到南向数据库里。这个服务也运行在控制器节点上。

4. 南向数据库（Southbound，SB）

南向数据库就像是一个“任务分配中心”，它监听端口6642。ovn-controller会连接到这里，获取任务指令，然后去控制和监控网络流量。这个服务运行在所有计算节点和网关节点上，只要定义了OS::Tripleo::Services::OVNController。

5. OVN 元数据代理（metadata agent）

这个代理就像是一个“管理员”，它会启动HAProxy实例。这些实例就像是“小助手”，用来管理OVS接口、网络命名空间和HAProxy进程。元数据代理运行在所有计算节点和网关节点上，只要定义了OS::TripleO::Services::OVNMetadataAgent。

用一个比喻来总结

如果把OVN的架构比作一个工厂：

OVN ML2 插件就像是工厂的“订单接收员”，接收OpenStack的网络配置订单。
北向数据库就像是“订单存储柜”，把订单保存好。
ovn-northd 服务就像是“订单翻译员”，把订单翻译成具体的生产任务。
南向数据库就像是“任务分配中心”，把任务分配给各个生产线。
ovn-controller就像是“生产线上的工人”，根据任务指令完成工作。
OVN 元数据代理就像是“车间管理员”，启动和管理各种工具（HAProxy实例）来完成任务。

这样一来，整个工厂（OVN架构）就能高效地运转啦！

OVN 数据库

OVN数据库就像是一个“指挥中心”，它放在一个中心位置，可以是物理服务器、虚拟机，甚至可以是一个集群。具体放在哪儿，得看你的云环境有多大、分布在多广的区域、流量有多少，还有你需要多高的性能。反正，只要能撑得起你的需求就行。不过有一点，你的虚拟机管理程序（hypervisors）必须得运行Open vSwitch，这样OVN才能工作。

OVN数据库分成两部分：北向数据库（Northbound）和南向数据库（Southbound）。这两个数据库就像是两个不同的“部门”，各有各的职责。

北向数据库

北向数据库就像是一个“信息接收站”，它从Neutron插件那儿接收关于逻辑网络配置的信息。比如，你设置了一个虚拟网络，Neutron插件就会把这些信息告诉北向数据库。这个数据库有两个“客户”：一个是Neutron插件，另一个是ovn-northd服务。

ovn-northd服务就像是一个“翻译员”，它连接到北向数据库，把逻辑网络配置翻译成具体的“行动指南”，也就是逻辑数据路径流（logical data path flows）。然后，它把这些“行动指南”存到南向数据库里。

南向数据库

南向数据库是整个系统的“核心”。它也有两个“客户”：ovn-northd服务和ovn-controller服务。每个虚拟机管理程序（hypervisor）都有自己的ovn-controller，它们都得从南向数据库这儿获取指令。

南向数据库里有三种数据：

1. 物理网络表（Physical Network tables）

这些表就像是“导航地图”，告诉系统怎么找到云环境里的物理节点。比如，你的虚拟机运行在哪个物理服务器上，这些信息都得记录下来。这些表是由虚拟机管理程序（hypervisors）填进去的。每个虚拟机管理程序都知道自己管理的虚拟机在哪个物理网络上，所以它会把这些信息告诉南向数据库。

2. 逻辑网络表（Logical Network tables）

这些表就像是“交通规则”，规定了虚拟网络里的数据该怎么流动。比如，虚拟机A要和虚拟机B通信，数据包该怎么走，这些规则都写在这里。这些表是由ovn-northd服务填进去的。ovn-northd会根据北向数据库里的配置信息，生成具体的“行动指南”，然后存到南向数据库里。

3. 绑定表（Binding tables）

这些表就像是“地址簿”，把逻辑网络组件的位置和物理网络联系起来。比如，某个虚拟机的虚拟网络接口在哪个物理网卡上，这些信息也得记录下来。这些表同样是由虚拟机管理程序（hypervisors）填进去的。

举个例子

假设你有一个云环境，里面有三台物理服务器，每台服务器上都运行了一些虚拟机。你用OVN来管理这些虚拟机的网络。

物理网络表：
- 物理服务器1上有一个虚拟机A，它的虚拟网络接口连接到物理网卡eth0。
- 物理服务器2上有一个虚拟机B，它的虚拟网络接口连接到物理网卡eth1。
- 物理服务器3上有一个虚拟机C，它的虚拟网络接口连接到物理网卡eth2。
- 这些信息由每个物理服务器上的虚拟机管理程序（hypervisors）填到南向数据库里。
逻辑网络表：
- 你通过OpenStack的Neutron插件创建了一个虚拟网络，设置了虚拟机A和虚拟机B之间的通信规则。比如，虚拟机A可以访问虚拟机B的IP地址192.168.1.10。
- ovn-northd服务会把这些规则翻译成具体的“行动指南”，比如数据包该怎么从虚拟机A传到虚拟机B。
- 这些“行动指南”被存到南向数据库的逻辑网络表里。
绑定表：
- 绑定表会记录虚拟机A的虚拟网络接口在物理服务器1的物理网卡eth0上。
- 绑定表还会记录虚拟机B的虚拟网络接口在物理服务器2的物理网卡eth1上。
- 这些信息同样由每个物理服务器上的虚拟机管理程序（hypervisors）填到南向数据库里。

简单来说，OVN数据库就是整个网络的“大脑”。北向数据库接收配置信息，ovn-northd服务翻译这些信息，然后存到南向数据库里。南向数据库再把这些信息发给每个虚拟机管理程序，每个虚拟机管理程序（hypervisor）都有自己的ovn-controller，它会从南向数据库里获取这些信息，然后控制虚拟机的网络流量。这样一来，整个虚拟网络就能高效、安全地运行啦！

OVN、OpenFlow和OVN逻辑流

在Red Hat OpenStack Platform里，OVN是用OpenFlow协议来管理的。OpenFlow就像是一个“指挥官”，它告诉Open vSwitch（一个虚拟交换机）该怎么处理网络流量。想象一下，你有一个交通系统，OpenFlow就像是交通信号灯，它决定哪些车（数据包）可以通行，哪些需要停下来。

OpenFlow是怎么工作的？

OpenFlow用一系列的“流表”（flow tables）来管理流量。每个流表都有三个关键部分：

优先级（Priority）：就像交通规则里的“优先通行权”。优先级高的流表会先被执行。
匹配条件（Match）：这个流表适用于哪些车（数据包）。比如，匹配特定的IP地址、端口号等。
动作（Actions）：匹配到的车（数据包）该怎么处理。比如，是直接放行、修改路径，还是丢弃。

OpenFlow很灵活，可以根据需要动态修改流表，比如添加新的规则或者删除旧的规则。这就像是可以根据交通流量调整信号灯的时间。

手动配置OpenFlow有多麻烦？

手动配置OpenFlow流表简直是个噩梦！在OpenStack这种复杂的环境里，手动配置不仅耗时耗力，而且很容易出错。想象一下，你要手动设置每一个交通信号灯，还得考虑所有可能的交通情况，这得多麻烦啊！

这就是为什么我们需要SDN控制器，比如OVN。OVN会自动创建和管理这些流表，把管理员从繁琐的手动配置中解放出来。而且，OVN还能自动实现安全策略，比如阻止某些恶意流量。

OVN逻辑流（Logical Flows）

OVN逻辑流和OpenFlow很像，也有优先级、匹配条件和动作。不过，逻辑流更像是“蓝图”，它描述了整个网络的行为。OVN用逻辑流来构建整个虚拟网络，然后把这些逻辑流分发到每个虚拟机管理程序（hypervisor）上的ovn-controller。

每个ovn-controller就像是一个“翻译员”，它把逻辑流翻译成具体的OpenFlow流表，告诉本地的Open vSwitch该怎么处理流量。这就像是把蓝图变成具体的施工图纸。

举个例子

假设你有一个虚拟网络，里面有两台虚拟机：虚拟机A和虚拟机B。它们分别运行在两个不同的物理服务器上。

逻辑流的创建：
- OVN根据你的网络配置（比如虚拟机A和虚拟机B之间的通信规则）创建逻辑流。
- 这些逻辑流包含了虚拟机A怎么和虚拟机B通信的详细规则，比如数据包的路径和安全策略。
逻辑流的分发：
- OVN把逻辑流分发到每个物理服务器上的ovn-controller。
- 比如，物理服务器1上的ovn-controller收到了关于虚拟机A的逻辑流，物理服务器2上的ovn-controller收到了关于虚拟机B的逻辑流。
逻辑流的翻译：
- 每个ovn-controller把逻辑流翻译成具体的OpenFlow流表。
- 比如，物理服务器1上的ovn-controller会告诉本地的Open vSwitch：“如果收到一个来自虚拟机A的数据包，目的地是虚拟机B，那么通过GENEVE隧道发送到物理服务器2。”
数据包的处理：

假设我们有两个虚拟机：虚拟机A和虚拟机B，它们分别运行在两台不同的物理服务器上（物理服务器1和物理服务器2）。现在虚拟机A要发送一个数据包给虚拟机B，这个过程是怎么发生的呢？

1. 入口（Ingress）管道处理

当虚拟机A发送一个数据包时，这个数据包首先会到达它所在的物理服务器1上的入口（ingress）管道。入口管道的作用是检查这个数据包，看看它是否符合某些规则（比如安全策略、是否允许发送等）。如果一切正常，数据包就会继续下一步。

2. 判断目的地

接下来，系统会检查数据包的目的地。如果目的地是同一个物理服务器上的另一个虚拟机，那么数据包会直接进入出口（egress）管道，然后被发送到目标虚拟机。

但如果目的地是另一个物理服务器上的虚拟机B（就像我们这个例子），那么数据包就需要跨服务器传输。

3. 通过GENEVE隧道传输

因为虚拟机B在另一台物理服务器2上，所以数据包需要通过一个GENEVE隧道发送到物理服务器2。GENEVE隧道是一种虚拟网络隧道技术，它可以让数据包在虚拟网络中安全地传输，就好像数据包在一条“虚拟高速公路”上行驶。

4. 在目标服务器上执行出口（Egress）管道

当数据包通过GENEVE隧道到达物理服务器2后，它会进入物理服务器2上的入口（ingress）管道。这里的入口管道会再次检查数据包，确保它符合安全策略等规则。

如果检查通过，数据包就会进入出口（egress）管道。出口管道的作用是把数据包发送到最终目的地——虚拟机B。

要查找ovn-remote参数的IP地址，可以使用ovs-vsctl list open命令。在执行ovn相关命令之前，需要设置OVN_SB_DC环境变量，以便指定南向数据库（SB）的连接地址。设置好环境变量后，可以使用ovn-sbctl lflow-list命令查看逻辑流（logical flows）。

[root@controller0 ~]# ovs-vsctl list open
_uuid               : da52b817-899b-459f-b486-b529fcbd9275
bridges             : [0ce60995-b5f2-4c22-abac-da6d377907a4, 34d70e04-f451-4429-8a5e-cb1071e5a604, 4fbb076a-cfdd-4959-bd40-c4447c75470c, 8bcd9c65-a895-4a9b-887a-50df37335ea8, 935000a3-772b-46ab-b862-a3dc7f254713]
cur_cfg             : 168
datapath_types      : [netdev, system]
datapaths           : {}
db_version          : "8.2.0"
dpdk_initialized    : false
dpdk_version        : "DPDK 19.11.1"
external_ids        : {hostname=controller0.overcloud.example.com, ovn-bridge=br-int, ovn-bridge-mappings="datacentre:br-ex,vlanprovider1:br-prov1,vlanprovider2:br-prov2,storage:br-trunk", ovn-cms-options=enable-chassis-as-gw, ovn-encap-ip="172.24.2.1", ovn-encap-type=geneve, ovn-openflow-probe-interval="60", ovn-remote="tcp:172.24.1.52:6642", ovn-remote-probe-interval="60000", rundir="/var/run/openvswitch", system-id="daeaae52-3df0-4531-a07d-0111be0edb42"}
iface_types         : [erspan, geneve, gre, internal, ip6erspan, ip6gre, lisp, patch, stt, system, tap, vxlan]
manager_options     : []
next_cfg            : 168
other_config        : {}
ovs_version         : "2.13.0"
ssl                 : []
statistics          : {}
system_type         : rhel
system_version      : "8.2"

[root@controller0 ~]# podman exec -ti ovn_controller ovn-sbctl lflow-list
Datapath: "neutron-d71997c1-1670-4ebe-b6f7-2c4aa8dcbc7b" aka "lb-mgmt-net" (4aa0552d-8627-4136-8530-f1c28ce417f1)  Pipeline: ingress
  table=0 (ls_in_port_sec_l2  ), priority=100  , match=(eth.src[40]), action=(drop;)
  table=0 (ls_in_port_sec_l2  ), priority=100  , match=(vlan.present), action=(drop;)
  table=0 (ls_in_port_sec_l2  ), priority=50   , match=(inport == "79ad0f7e-f219-4c5f-8799-ed75fdde5b5f"), action=(next;)
  table=0 (ls_in_port_sec_l2  ), priority=50   , match=(inport == "c2d0d0f4-8185-4cc4-a9f4-21008e49192c"), action=(next;)
  table=0 (ls_in_port_sec_l2  ), priority=50   , match=(inport == "e6117623-8f6b-4bfd-a0d5-1498a99589bf" && eth.src == {fa:16:3e:33:f1:05}), action=(next;)
  table=1 (ls_in_port_sec_ip  ), priority=90   , match=(inport == "e6117623-8f6b-4bfd-a0d5-1498a99589bf" && eth.src == fa:16:3e:33:f1:05 && ip4.src == 0.0.0.0 && ip4.dst == 255.255.255.255 && udp.src == 68 && udp.dst == 67), action=(next;)
  table=1 (ls_in_port_sec_ip  ), priority=90   , match=(inport == "e6117623-8f6b-4bfd-a0d5-1498a99589bf" && eth.src == fa:16:3e:33:f1:05 && ip4.src == {172.23.0.125}), action=(next;)
  table=1 (ls_in_port_sec_ip  ), priority=80   , match=(inport == "e6117623-8f6b-4bfd-a0d5-1498a99589bf" && eth.src == fa:16:3e:33:f1:05 && ip), action=(drop;)
  table=1 (ls_in_port_sec_ip  ), priority=0    , match=(1), action=(next;)
  table=2 (ls_in_port_sec_nd  ), priority=90   , match=(inport == "e6117623-8f6b-4bfd-a0d5-1498a99589bf" && eth.src == fa:16:3e:33:f1:05 && arp.sha == fa:16:3e:33:f1:05 && arp.spa == {172.23.0.125}), action=(next;)

ML2中的OVS和OVN

ML2用OVS和用OVN，差别可大了！这些差别在日常运维中影响挺大，尤其是在排查问题的时候。

以前用OVS的时候，网络流量的进出、安全策略的实施、DHCP和NAT这些功能，都是靠OpenFlow规则直接管理的。换句话说，管理员得直接和OpenFlow规则打交道，规则数量也相对少一些。

现在用OVN就不一样了。OVN引入了“逻辑流”这个概念，它就像是一个更高层次的“指挥官”。逻辑流会告诉系统怎么处理网络流量、怎么执行安全策略等，然后OVN再把这些逻辑流翻译成具体的OpenFlow规则去执行。这样一来，虽然功能更强大了，但OpenFlow规则的数量也大大增加了，因为OVN需要把逻辑流拆解成更细致的规则来实现。

简单来说，OVS是直接用OpenFlow规则干活，而OVN是先用逻辑流规划好，再翻译成OpenFlow规则去执行。这就好比以前是直接用手搬砖，现在是先设计好图纸，再按图纸施工，虽然复杂了点，但更灵活、更强大。

组件	ML2搭配OVS	ML2搭配OVN
通信方式	使用RabbitMQ消息队列进行通信。	使用ovsdb协议进行通信。
三层高可用（L3HA）数据平面	通过创建qrouter命名空间来实现。	由ovn-controller配置OpenFlow规则来实现。
分布式虚拟路由器（DVR）API	管理员可以手动修改“分布式”标志。	所有流量都是分布式处理。
DVR数据平面	由命名空间、虚拟以太网对（veth pairs）和iptables规则组成。	由计算节点上的OpenFlow规则组成。
东西向流量	当DVR关闭时，流量通过网络节点路由。	在所有情况下，流量都是分布式处理的。
元数据服务	在控制器节点上通过DHCP命名空间支持。	在所有计算节点上的ovnmeta-xxx命名空间中运行。
DHCP服务	由dhcp-xxx命名空间提供，每个命名空间内运行一个dnsmasq进程。	使用由ovn-controller解释的OpenFlow规则实现，并在所有计算节点上分布。