OVN (Open Virtual Network)

OVN是OVS提供的原生虚拟化网络方案。

OVN是OpenvSwitch项目组为OpenvSwitch开发SDN控制器，同其他SDN产品相比，OVN对OpenvSwitch 及OpenStack有更好的兼容性和性能。

特点

1、可用于生产环境

2、简洁的设计

3、支持1000台以上的物理机环境（也支持相当数量的虚拟机/容器环境）

4、基于已有的OpenStack OVS 插件 来提升性能和稳定性

5、成为OpenStack+OVS集成场景下的首选方案

OVN主要功能

1、L2/L3虚拟网络以及逻辑交换机(logical switch)

2、L2/L3/L4 ACL：二到四层的 ACL，可以根据报文的 MAC 地址，IP 地址，端口号来做访问控制。

3、IPv4/IPv6分布式L3路由

4、Multiple tunnel overlays：支持多种隧道封装技术，有 Geneve，STT 和 VXLAN。

5、TOR switch or software logical switch gateways：支持使用硬件 TOR switch 或者软件逻辑 switch 当作网关来连接物理网络和虚拟网络。

OVN组件架构

组件介绍：

云管系统(Cloud Management System): 即最上面的部分

OVN/CMS 插件（Plugin）：插件是用作OVN接口的CMS组件。

在OpenStack中，就是一个Neutron插件。
插件的主要目的就是将CMS的逻辑网络配置概念（以CMS可识别的特定格式存储在CMS的配置数据库中），转换为OVN可以理解的中间格式。
此组件必须是CMS特定的，因此，需要为每个与OVN集成的CMS开发一个新插件。上图中此组件下面的所有组件都是独立于CMS的。

OVN北向数据库（Northbound Database）：接收OVN/CMS插件传递的逻辑网络配置的中间表示。

数据库模式与CMS中使用的概念匹配（impedance matched），因此它直接支持逻辑交换机、路由器、ACL等概念。
OVN北向数据库有两个客户端：它上面的OVN/CMS插件还有它下面的ovn-northd

ovn-northd: 它上连OVN北向数据库，下连OVN南向数据库。

它将从北向数据库中获得的传统网络概念中的逻辑网络配置，转换为它下面的南向数据库所能理解的逻辑数据路径流（logical datapath flow）。

OVN南向数据库（Southbound Database）：这是本系统的中心。

它的客户端(client)包括其上的ovn-northd，以及其下每个传输节点上的ovn-controller。

OVN南向数据库包含三种数据：
物理网络(Physical Network (PN))表：指明如何访问hypervisor和其他节点
逻辑网络(Logical Network (LN))表：用逻辑数据路径流（logical datapath flows）来描述逻辑网络，
绑定表：将逻辑网络组件的位置链接到物理网络

OVN南向数据库的性能必须随着传输节点的变化而变化。这就需要在遇到瓶颈的时候在ovsdb-server上进行一些工作，可能需要引入集群来提升可用性。

其余组件将被复制到每个虚拟机监控程序（hypervisor）上：

1、ovn-controller ：是每个hypervisor和软件网关上的agent。

北向上看ovn-controller：
它连接到南向数据库来获取OVN的配置及状态，并用hypervisor的状态填充绑定表中的PN表和Chassis列。ovn-controller 会把物理网络的信息写到 Southbound DB 里面

南向上看ovn-controller：
它作为OpenFlow controller连接到 ovs-vswitchd 来控制网络流量 ，并连接到本地ovsdb-server来监控和控制Open vSwitch的配置。
它会把 Southbound DB 里面存的一些数据转化成 Openflow flow 配到本地的 OVS table 里面，来实现报文的转发

2、ovs-vswitchd 和 ovsdb-server：Open vSwitch的传统组件。

OVN北向数据库与南向数据库

Southbound DB：

主要包含 3 类数据
一是物理网络数据，比如 HV（hypervisor）的 IP 地址，HV 的 tunnel 封装格式；
二是逻辑网络数据，比如报文如何在逻辑网络里面转发；
三是物理网络和逻辑网络的绑定关系，比如逻辑端口关联到哪个 HV 上面。

Southbound DB 处在 OVN 架构的中心，它是 OVN 中非常重要的一部分，它跟 OVN 的其他组件都有交互。

Southbound DB 里面有如下几张表：

Chassis：

Chassis是OVN新增的概念，OVS里面没有这个概念，Chassis可以是 HV，也可以是 VTEP 网关。

每一行表示一个 HV 或者 VTEP 网关，由 ovn-controller/ovn-controller-vtep 填写，
包含 chassis 的名字和 chassis 支持的封装的配置（指向表 Encap），
如果 chassis 是 VTEP 网关，VTEP 网关上和 OVN 关联的逻辑交换机也保存在这张表里。

# ovn-sbctl list Chassis
_uuid               : 3dec4aa7-8f15-493d-89f4-4a260b510bbd
encaps              : [bc324cd4-56f2-4f73-af9e-149b7401e0d2]
external_ids        : {datapath-type="", iface-types="geneve,gre,internal,lisp,patch,stt,system,tap,vxlan", ovn-bridge-mappings=""}
hostname            : "kube-node1"
name                : "c7889c47-2d18-4dd4-a3b7-446d42b79f79"
nb_cfg              : 34
vtep_logical_switches: []
...
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

Encap：

保存着tunnel的类型和 tunnel endpoint IP 地址。

# ovn-sbctl list Encap
_uuid               : bc324cd4-56f2-4f73-af9e-149b7401e0d2
chassis_name        : "c7889c47-2d18-4dd4-a3b7-446d42b79f79"
ip                  : "172.17.42.31"
options             : {csum="true"}
type                : vxlan
...
1
2
3
4
5
6
7
8
9

Logical_Flow：

每一行表示一个逻辑的流表，这张表是 ovn-northd 根据 Nourthbound DB 里面
二三层拓扑信息和 ACL 信息转换而来的，ovn-controller 把这个表里面的流表
转换成 OVS 流表，配到 HV 上的 OVS table。流表主要包含匹配的规则，匹配的方向，
优先级，table ID 和执行的动作。

# ovn-sbctl lflow-list
Datapath: "kube-node1" (2c3caa57-6a58-4416-9bd2-3e2982d83cf1)  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 == "default_sshd-2"), action=(next;)
  table=0 (ls_in_port_sec_l2  ), priority=50   , match=(inport == "k8s-kube-node1"), action=(next;)
  table=0 (ls_in_port_sec_l2  ), priority=50   , match=(inport == "stor-kube-node1"), action=(next;)
....
1
2
3
4
5
6
7
8
9
10
11
12
13

Multicast_Group

每一行代表一个组播组，组播报文和广播报文的转发由这张表决定，
它保存了组播组所属的 datapath，组播组包含的端口，
还有代表 logical egress port 的 tunnel_key。
1
2
3

Datapath_Binding

每一行代表一个 datapath 和物理网络的绑定关系，
每个 logical switch 和 logical router 对应一行。
它主要保存了 OVN 给 datapath 分配的代表 logical datapath identifier 的 tunnel_key。

示例：

# ovn-sbctl list Datapath_Binding
_uuid               : 4cfe0e4c-1bbb-406a-9d85-e7bc24c818d0
external_ids        : {logical-router="e12293ba-e61e-40bf-babc-8580d1121641", name=kube-master}
tunnel_key          : 1

_uuid               : 5ec4f962-77a8-44e8-ae01-5b7e46b6a286
external_ids        : {logical-switch="e865aa50-7510-4b7f-9df4-b82801a8e92b", name=join}
tunnel_key          : 2

_uuid               : 2c3caa57-6a58-4416-9bd2-3e2982d83cf1
external_ids        : {logical-switch="7c41601a-dcd5-4e77-b0e8-ca8692d7462b", name="kube-node1"}
tunnel_key          : 4
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

Port_Binding

这张表主要用来确定 logical port 处在哪个 chassis 上面。
每一行包含的内容主要有 logical port 的 MAC 和 IP 地址，端口类型，
端口属于哪个 datapath binding，代表 logical input/output port identifier 的 tunnel_key,
 以及端口处在哪个 chassis。端口所处的 chassis 由 ovn-controller/ovn-controller 设置，
 其余的值由 ovn-northd 设置。

示例：

# ovn-sbctl list Port_Binding    
_uuid               : 5e5746d8-3533-45a8-8abe-5a7028c97afa
chassis             : []
datapath            : 2c3caa57-6a58-4416-9bd2-3e2982d83cf1
external_ids        : {}
gateway_chassis     : []
logical_port        : "stor-kube-node1"
mac                 : ["00:00:00:18:22:18"]
nat_addresses       : []
options             : {peer="rtos-kube-node1"}
parent_port         : []
tag                 : []
tunnel_key          : 2
type                : patch
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

Southbound DB表关系总结：

表 Chassis 和表 Encap 包含的是物理网络的数据，表 Logical_Flow 和表 Multicast_Group 包含的是逻辑网络的数据，表 Datapath_Binding 和表 Port_Binding包含的是逻辑网络和物理网络绑定关系的数据。

Northbound DB：

存的都是一些逻辑的数据，大部分和物理网络没有关系，比如logical switch，logical router，ACL，logical port，和传统网络设备概念一致。
Northbound DB 是 OVN 和 CMS 之间的接口，Northbound DB 里面的几乎所有的内容都是由 CMS 产生的，ovn-northd 监听这个数据库的内容变化，然后翻译，保存到 Southbound DB 里面。

Northbound DB 里面主要有如下几张表：

Logical_Switch

每一行代表一个逻辑交换机，逻辑交换机有两种，一种是 overlay logical switches，
对应于 neutron network，每创建一个 neutron network，networking-ovn 
会在这张表里增加一行；另一种是 bridged logical switch，连接物理网络和逻辑网络，
被 VTEP gateway 使用。Logical_Switch 里面保存了它包含的 logical port
（指向 Logical_Port table）和应用在它上面的 ACL（指向 ACL table）。

ovn-nbctl list Logical_Switch可以查看Logical_Switch表中的数据：

# ovn-nbctl --db tcp:172.17.42.30:6641 list Logical_Switch
_uuid               : 707dcb98-baa0-4ac5-8955-1ce4de2f780f
acls                : []
dns_records         : []
external_ids        : {gateway_ip="192.168.1.1/24"}
load_balancer       : [4522d0fa-9d46-4165-9524-51d20a35ea0a, 5842a5a9-6c8e-4a87-be3c-c8a0bc271626]
name                : kube-master
other_config        : {subnet="192.168.1.0/24"}
ports               : [44222421-c811-4f38-8ea6-5504a35df703, ee5a5e97-c41d-4656-bd2a-8bc8ad180188]
qos_rules           : []
...
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

Logical_Switch_Port

每一行代表一个逻辑端口，每创建一个 neutron port，networking-ovn 会在这张表里增加一行，
每行保存的信息有端口的类型，比如 patch port，localnet port，端口的 IP 和 MAC 地址，
端口的状态 UP/Down。

# ovn-nbctl --db tcp:172.17.42.30:6641 list Logical_Switch_Port
_uuid               : 44222421-c811-4f38-8ea6-5504a35df703
addresses           : ["00:00:00:BF:CC:B1"]
dhcpv4_options      : []
dhcpv6_options      : []
dynamic_addresses   : []
enabled             : []
external_ids        : {}
name                : stor-kube-master
options             : {router-port=rtos-kube-master}
parent_name         : []
port_security       : []
tag                 : []
tag_request         : []
type                : router
up                  : false
...
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

ACL

每一行代表一个应用到逻辑交换机上的 ACL 规则，如果逻辑交换机上面的所有端口都没有配置
 security group，那么这个逻辑交换机上不应用 ACL。每条 ACL 规则包含匹配的内容，方向，
 还有动作。
1
2
3

Logical_Router

每一行代表一个逻辑路由器，每创建一个 neutron router，
networking-ovn 会在这张表里增加一行，每行保存了它包含的逻辑的路由器端口。

# ovn-nbctl --db tcp:172.17.42.30:6641 list Logical_Router
_uuid               : e12293ba-e61e-40bf-babc-8580d1121641
enabled             : []
external_ids        : {"k8s-cluster-router"=yes}
load_balancer       : []
name                : kube-master
nat                 : []
options             : {}
ports               : [2cbbbb8e-6b5d-44d5-9693-b4069ca9e12a, 3a046f60-161a-4fee-a1b3-d9d3043509d2, 40d3d95d-906b-483b-9b71-1fa6970de6e8, 840ab648-6436-4597-aeff-f84fbc44e3a9, b08758e5-7017-413f-b3db-ff68f49460a4]
static_routes       : []
1
2
3
4
5
6
7
8
9
10
11
12
13

Logical_Router_Port

每一行代表一个逻辑路由器端口，每创建一个 router interface，networking-ovn 会
在这张表里加一行，它主要保存了路由器端口的 IP 和 MAC。

# ovn-nbctl --db tcp:172.17.42.30:6641 list Logical_Router_Port
_uuid               : 840ab648-6436-4597-aeff-f84fbc44e3a9
enabled             : []
external_ids        : {}
gateway_chassis     : []
mac                 : "00:00:00:BF:CC:B1"
name                : rtos-kube-master
networks            : ["192.168.1.1/24"]
options             : {}
peer                : []
1
2
3
4
5
6
7
8
9
10
11
12
13

OVN tunnel

OVN 支持的 tunnel 类型有三种：

分别是 Geneve，STT 和 VXLAN。HV 与 HV 之间的流量，只能用 Geneve 和 STT 两种，HV 和 VTEP 网关之间的流量除了用 Geneve 和 STT 外，还能用 VXLAN，这是为了兼容硬件 VTEP 网关，因为大部分硬件 VTEP 网关只支持 VXLAN。

VXLAN局限性：

虽然 VXLAN 是数据中心常用的 tunnel 技术，但是 VXLAN header 是固定的，只能传递一个 VNID（VXLAN network identifier），如果想在 tunnel 里面传递更多的信息，VXLAN 实现不了。所以 OVN 选择了 Geneve 和 STT，Geneve 的头部有个 option 字段，支持 TLV 格式，用户可以根据自己的需要进行扩展，而 STT 的头部可以传递 64-bit 的数据，比 VXLAN 的 24-bit 大很多。

OVN中的信息流

配置信息：从北向南流动。

CMS使用其OVN/CMS插件，通过北向数据库来将逻辑网络配置传递给ovn-northd。
另外一边，ovn-northd将配置编译成一个较低级别的形式，并通过南向数据库将其传递给所有chassis。

状态信息：从南向北流动。

1、首先：ovn-northd填充北向Logical_Switch_Port表中的up列：
如果南向端口绑定表中的逻辑端口chassis列非空，则将其设为true，否则为false。
这让CMS可以检测VM的网络何时起来（come up）。

2、其次：OVN向CMS提供其配置实现的反馈，即CMS提供的配置是否已经生效。
该特性需要CMS参与序列号协议（sequence number protocol），其工作方式如下：

* 当CMS更新北向数据库中的配置时，作为同一事务的一部分，
  它将增加NB_Global表中的nb_cfg列的值。

* 当ovn-northd基于北向数据库的给定快照（snapshot）更新南向数据库时，
  作为同一事务的一部分，它将nb_cfg从北向数据库的NB_Global复制到南向数据库的
  SB_Global表中。
（这样一来，监视两个数据库的观察者就可以确定南向数据库何时赶上北向数据库。）

* 在ovn northd从southerbound数据库服务器收到其更改已提交的确认之后，
   它将NB_Global表中的sb_cfg更新为被已被推到下面的nb_cfg版本。
  （这样CMS或另一个观察者可以确定南向数据库何时被挂起（caught up），
   而不用与南向数据库连接）。

* 每个chassis上的ovn-controller控制器进程接收更新后的南向数据库和更新后的nb_cfg。
  该过程也会更新chassis的Open vSwitch实例上安装的物理流（physical flows）。
  当它从Open vSwitch收到物理流已更新的确认信息时，
  就会在南向数据库中更新自己的Chassis记录中的nb_cfg。

* ovn-northd 监视所有南向数据库中Chassis记录的nb_cfg列。
  它跟踪所有记录中的最小值，并将其复制到北向NB_Global表的hv_cfg列中。
（这样一来，CMS或另一个观察者就可以确定什么时候所有hypervisor都赶上了北向配置。）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

逻辑网络（Logical Network）

逻辑网络（logical network）实现了与物理网络（physical network）一样的概念，
不过他们通过通道(tunnel)或者其他封装手段，与物理网络隔离开来。
这就让逻辑网络可以拥有单独的IP和其他地址空间，如此一来，便可以与物理网络所用的IP和地址空间无冲突地重叠。
安排逻辑网络拓扑的时候，可以不用考虑它们运行所在的物理网络拓扑。

OVN里的逻辑网络概念包含：

逻辑交换机（Logical switch）：以太网交换机的逻辑版本

逻辑路由器（Logical router）：IP路由器的逻辑版本。逻辑交换机及路由器都可以接入复杂的拓扑里。

逻辑数据通路（Logical datapath）：逻辑版本的OpenFlow交换机。逻辑交换机及路由器都以逻辑数据通路形式实现。

逻辑端口（Logical port）：代表了逻辑交换机和逻辑路由器之间的连接点