openstack-notes

OVN https://www.ovn.org/en/

架构

安装

apt-get update

apt-get -y install build-essential fakeroot

sudo apt-get install python-six openssl -y

sudo apt-get install openvswitch-switch openvswitch-common -y

sudo apt-get install ovn-central ovn-common ovn-host -y

sudo apt-get install ovn-host ovn-common -y

启动

/etc/init.d/openvswitch-switch start

/etc/init.d/ovn-central start

ovs-vsctl add-br br-int – set Bridge br-int fail-mode=secure

配置

ovn-nbctl set-connection ptcp:6641:172.18.22.197

ovn-sbctl set-connection ptcp:6642:172.18.22.197

ovs-vsctl set open . external-ids:ovn-remote=tcp:172.18.22.197:6642

ovs-vsctl set open . external-ids:ovn-encap-type=geneve

ovs-vsctl set open . external-ids:ovn-encap-ip=172.18.22.197

ovs-vsctl set open . external-ids:ovn-remote=tcp:172.18.22.197:6642

ovs-vsctl set open . external-ids:ovn-encap-type=geneve

ovs-vsctl set open . external-ids:ovn-encap-ip=172.18.22.198

OVN Northbound DB

Northbound DB 是 OVN 和 CMS 之间的接口，Northbound DB 保存CMS 产生的数据，ovn-northd 监听数据库的内容变化，然后翻译并保存到 Southbound DB 里面。Northbound DB 里面主要有如下几张表：

OVN Southbound DB

Southbound DB 处在 OVN 架构的中心，它是 OVN 中非常重要的一部分，它跟 OVN 的其他组件都有交互。 Southbound DB 里面有如下几张表：

OVN Chassis

Chassis 是 OVN 新增的概念，Chassis 是HV/VTEP 网关。Chassis 的信息保存在 Southbound DB 里面，由 ovn-controller/ovn-controller-vtep 来维护。以 ovn-controller 为例，当 ovn-controller 启动的时候，它去本地的数据库 Open_vSwitch 表里面读取external_ids:system_id，external_ids:ovn-remote，external_ids:ovn-encap-ip 和external_ids:ovn-encap-type的值，然后它把这些值写到 Southbound DB 里面的表 Chassis 和表 Encap 里面。external_ids:system_id表示 Chassis 名字。external_ids:ovn-remote表示 Sounthbound DB 的 IP 地址。external_ids:ovn-encap-ip表示 tunnel endpoint IP 地址，可以是 HV 的某个接口的 IP 地址。external_ids:ovn-encap-type表示 tunnel 封装类型，可以是 VXLAN/Geneve/STT。external_ids:ovn-encap-ip和external_ids:ovn-encap-type是一对，每个 tunnel IP 地址对应一个 tunnel 封装类型，如果 HV 有多个接口可以建立 tunnel，可以在 ovn-controller 启动之前，把每对值填在 table Open_vSwitch 里面。

OVN tunnel

OVN 支持的 tunnel 类型有三种，分别是 Geneve，STT 和 VXLAN。HV 与 HV 之间的流量，只能用 Geneve 和 STT 两种，HV 和 VTEP 网关之间的流量除了用 Geneve 和 STT 外，还能用 VXLAN，这是为了兼容硬件 VTEP 网关，因为大部分硬件 VTEP 网关只支持 VXLAN。虽然 VXLAN 是数据中心常用的 tunnel 技术，但是 VXLAN header 是固定的，只能传递一个 VNID（VXLAN network identifier），如果想在 tunnel 里面传递更多的信息，VXLAN 实现不了。所以 OVN 选择了 Geneve 和 STT，Geneve 的头部有个 option 字段，支持 TLV 格式，用户可以根据自己的需要进行扩展，而 STT 的头部可以传递 64-bit 的数据，比 VXLAN 的 24-bit 大很多。

OVN tunnel 封装时使用了三种数据：

如果 tunnel 类型是 Geneve，Geneve header 里面的 VNI 字段填 logical datapath identifier，Option 字段填 logical input port identifier 和 logical output port identifier，TLV 的 class 为 0xffff，type 为 0，value 为 1-bit 0 + 15-bit logical input port identifier + 16-bit logical output port identifier。如果 tunnel 类型是 STT，上面三个值填在 Context ID 字段，格式为 9-bit 0 + 15-bit logical input port identifier + 16-bit logical output port identifier + 24-bit logical datapath identifier。OVS 的 tunnel 封装是由 Openflow 流表来做的，所以 ovn-controller 需要把这三个标识符写到本地 HV 的 Openflow flow table 里面，对于每个进入 br-int 的报文，都会有这三个属性，logical datapath identifier 和 logical input port identifier 在入口方向被赋值，分别存在 openflow metadata 字段和 Nicira 扩展寄存器 reg14 里面。报文经过 OVS 的 pipeline 处理后，如果需要从指定端口发出去，只需要把 Logical output port identifier 写在 Nicira 扩展寄存器 reg15 里面。

OVN tunnel 里面所携带的 logical input port identifier 和 logical output port identifier 可以提高流表的查找效率，OVS 流表可以通过这两个值来处理报文，不需要解析报文的字段。 OVN 里面的 tunnel 类型是由 HV 上面的 ovn-controller 来设置的，并不是由 CMS 指定的，并且 OVN 里面的 tunnel ID 又由 OVN 自己分配的，所以用 neutron 创建 network 时指定 tunnel 类型和 tunnel ID（比如 vnid）是无用的，OVN 不做处理。

OVN中的信息流

配置数据

OVN中的配置数据从北向南流动。

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

状态信息

OVN中的状态信息从南向北流动。

OVN目前只提供几种形式的状态信息。

逻辑网络（Logical Network）

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

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

VIF的生命周期

单独呈现表（Table）和其模式的话会很难理解。这里有一个例子。

虚拟机监控程序（hypervisor）上的VIF是一个虚拟网络接口，他们要么连接到VM上要么连接到容器上（容器直接在该hypervisor上运行）。这与在VM中运行的容器的接口不同:

本例中的步骤通常涉及到OVN和OVN Northbound database模式的详细信息。想了解这些数据库的完整信息，请分别参阅ovn-sb和ovn-nb。

VM内部容器接口的生命周期

OVN通过将写在OVN_NB数据库中的信息，转换成每个hypervisor中的OpenFlow流表来提供虚拟网络抽象。

如果想要为多租户提供安全的虚拟网络连接，那么OVN控制器便应该是唯一可以修改Open vSwitch中的流的实体时候。当Open vSwitch集成网桥驻留在虚拟机管理程序中时，虚拟机内运行的租户工作负载（ tenant workloads ）是无法对Open vSwitch流进行任何更改的。

如果基础架构provider相信容器内的应用程序不会中断和修改Open vSwitch流，则可以在hypervisors中运行容器。当容器在虚拟机中运行时也是如此，此时需要有一个驻留在同一个VM中并由OVN控制器控制的Open vSwitch集成网桥。
对于上述两种情况，工作流程与上一节（“VIF的生命周期”）中的示例所解释的相同。

本节讨论在虚拟机中创建容器并将Open vSwitch集成网桥驻留在虚拟机管理程序中时，容器接口（CIF）的生命周期。
在这种情况下，即使容器应用程序发生故障，其他租户也不会受到影响，因为运行在VM内的容器无法修改Open vSwitch集成网桥中的流。

在虚拟机内创建多个容器时，会有多个CIF关联。为了便于OVN支持虚拟网络抽象，与这些CIF关联的网络流量需要到达hypervisor中运行的Open vSwitch集成网桥。OVN还应能够区分来自不同CIF的网络流量。

区分CIP网络流量的方法

有两种方法可以区分CIF的网络流量：

1:1

第一种方法是为每个CIF都提供一个VIF（1:1）：

这意味着hypervisor中可能有很多网络设备。由于管理所有VIF会造成额外的CPU消耗，这会使OVS变慢。这也意味着在VM中创建容器的实体也应该能够在hypervisor中创建相应的VIF。

1:2

第二种方法是为所有CIF只提供一个VIF（1:n）。然后，OVN可以通过每个数据包中写入的标签来区分来自不同CIF的网络流量。
OVN使用这种机制并使用VLAN作为标记机制。

数据包的物理处理生命周期

本节介绍数据包如何通过OVN从一个虚拟机或容器传输到另一个。

这个描述着重于数据包的物理处理。有关数据包逻辑生命周期的描述，请参考ovn-sb中的Logical_Flow表。

为了清楚起见，本节提到了一些数据和元数据字段，总结如下：

涉及的数据和元数据字段

详细的生命周期

首先，hypervisor上的VM或容器通过连接到OVN集成网桥的端口上,来发送数据包。详细的生命周期如下：

源自嵌套在虚拟机内的容器的数据包有稍微不同的方式处理。可以根据VIF特定的VLAN ID来区分始发容器，因此物理到逻辑的转换流程将在VLAN ID字段上需要匹配，且在VLAN header剥离时也会进行匹配。在这一步之后，OVN像处理其他数据包一样处理来自容器的数据包。

流表0还处理从其他chassis到达的数据包。它通过入口端口（这是一个隧道）将它们与其他数据包区分开来。与刚刚进入OVN流水线的数据包一样，这些操作使用逻辑数据路径和逻辑入口端元数据来注释这些数据包。另外，设置逻辑输出端口字段的操作也是可用的，因为在OVN中，隧道发生在逻辑输出端口已知之后。这三个信息是从隧道封装元数据中获取的（请参阅隧道封装了解编码细节）。然后操作重新提交到表33以进入逻辑出口管道。

出口管道不能改变逻辑输出端口或进行进一步的隧道封装。

逻辑路由器和逻辑patch端口

通常，逻辑路由器和逻辑patch端口不都具有物理位置，并且实际上是驻留在hypervisor的。逻辑路由器和这些逻辑路由器后面的逻辑交换机之间的逻辑patch端口就是这种情况，VM（和VIF）连接到这些逻辑交换机。

考虑这样的情况：一个虚拟机或容器发送数据包到位于不同子网上的另一个VM或容器。数据包将按照前面“数据包的物理生命周期”部分所述，使用表示发送者所连接的逻辑交换机的logical datapath，遍历表0至65。在表32中，数据包本地重新提交到hypervisor上的表33的fallback flow。在这种情况下，从表0到表65的所有处理都在数据包发送者所在的hypervisor上进行。

当数据包到达表65时，逻辑出口端口是逻辑patch端口。表65中的实现取决于OVS版本，虽然观察到的行为意图是相同的：

包重新进入入口流水线（ingress pipeline）以便再次遍历表8至65，这次使用表示逻辑路由器的逻辑数据路径。

处理过程继续，如前一部分“数据包的物理生命周期”部分所述。当数据包到达表65时，逻辑输出端口将再次成为逻辑patch端口。
使用与上述相同的方式，这个逻辑patch端口将使得数据包被重新提交给OpenFlow表8至65，这次使用目标VM或容器所连接的逻辑交换机的逻辑数据路径。

该分组第三次也是最后一次遍历表8至65。如果目标VM或容器驻留在远程hypervisor中，则表32将在隧道端口上将该分组从发送者的hypervisor发送到远程hypervisor。最后，表65将直接将数据包输出到目标VM或容器。

以下部分描述了两个例外情况：逻辑路由器或逻辑patch端口与物理位置相关联。

网关路由器

网关路由器是绑定到物理位置的逻辑路由器。这包括逻辑路由器的所有逻辑patch端口以及逻辑交换机上的所有对等逻辑patch端口。
在OVN Southbound数据库中，这些逻辑patch端口的Port_Binding条目使用l3gateway类型而不是patch类型，以便区分这些逻辑patch端口绑定到chassis。

当hypervisor在代表逻辑交换机的逻辑数据路径上处理数据包，并且逻辑出口端口是表示与网关路由器连接的l3gateway时，该包将匹配表32中的流表，通过隧道端口将数据包发送给网关路由器所在的chassis。表32中的处理过程与VIF相同。

网关路由器通常用于分布式逻辑路由器和物理网络之间。分布式逻辑路由器及其后面的逻辑交换机（虚拟机和容器附加到的逻辑交换机）实际上驻留在每个hypervisor中。分布式路由器和网关路由器通过另一个逻辑交换机连接，有时也称为连接逻辑交换机。另一方面，网关路由器连接到另一个具有连接到物理网络的localnet端口的逻辑交换机。

当使用网关路由器时，DNAT和SNAT规则与网关路由器相关联，网关路由器提供可处理一对多SNAT（又名IP伪装）的中央位置。

分布式网关端口

分布式网关端口是逻辑路由器patch端口，可以将分布式逻辑路由器和具有本地网络端口的逻辑交换机连接起来。

分布式网关端口的主要设计目标，是尽可能多的在VM或容器所在的hypervisor上本地处理流量。只要有可能，就应该在该虚拟机或容器的hypervisor上，完全处理从该虚拟机或容器到外部世界的数据包，最终遍历该hypervisor上到物理网络的所有localnet端口实例。
只要有可能，从外部到虚拟机或容器的数据包，就应该通过物理网络直接导向虚拟机或容器的hypervisor，数据包将通过localnet端口进入集成网桥。

为了允许上面段落中描述的分组分布式处理，分布式网关端口应该是有效地驻留在每个hypervisor上的逻辑patch端口，而不是绑定到特定chassis的l3gateway端口。但是，与分布式网关端口相关的流量通常需要与物理位置相关联，原因如下：

ovn-northd文档中描述了对特定chassis的流量限制的详细信息。

虽然分布式网关端口的大多数依赖于物理位置的地方，都可以通过将某些流限制到特定chassis来处理，但还是需要一个附加的机制。
当数据包离开入口管道，且逻辑出口端口是分布式网关端口时，需要表32中两个不同的动作集中的一个：

为了触发第二组动作，已经添加了chassisredirect类型的南向数据库的Port_Binding表。将逻辑出口端口设为chassisredirect类型的逻辑端口只是一种方式，表明虽然该数据包是指向分布式网关端口的，但需要将其重定向到不同的chassis。
在表32中，具有该逻辑输出端口的分组被发送到特定的chassis，与表32将逻辑输出端口是VIF或者类型为13的网关端口的分组指向不同的chassis的方式相同。一旦分组到达该chassis，表33将逻辑出口端口重置为代表分布式网关端口的值。对于每个分布式网关端口，除了表示分布式网关端口的分布式逻辑patch端口外，还有一个chassisredirect类型的端口。

分布式网关端口的高可用性

OVN允许您为分布式网关端口指定chassis的优先级列表。这是通过将多个Gateway_Chassis行与OVN_Northbound数据库中的Logical_Router_Port关联来完成的。当为网关指定了多个chassis时，所有可能向该网关发送数据包的chassis都将启用通道上的BFD，这些隧道通往所有配置的网关chassis。当前网关的主chassis是当前最高优先级的网关chassis，该chassis根据BFD状态被当做主chassis。

连接到逻辑路由器的多个LocalNet逻辑交换机 {#9连接到逻辑路由器的多个localnet逻辑交换机}

可以有多个逻辑交换机，每个交换机都有一个本地网络端口（代表物理网络）连接到逻辑路由器，其中一个localnet逻辑交换机可以通过分布式网关端口提供外部连接，其余的localnet逻辑交换机在物理网络中使用VLAN标记。需要为所有这些localnet网络在chassis上正确配置ovn网桥映射（ovn-bridge-mappings）。

东西向路由 {#91东西向路由}

这些带有localnet VLAN标记的逻辑交换机之间的东西路由工作方式，与普通逻辑交换机几乎相同。当虚拟机发送这样的数据包时，则：

外部流量 {#92外部流量}

当虚拟机发送外部流量（需要NATting），并且承载虚拟机的chassis没有分布式网关端口时，会发生以下情况：

尽管这样做有效，但当从计算chassis发送到网关chassis时，VM通信量将被隧道化。为了使其正常工作，必须降低localnet逻辑交换机的MTU，以考虑隧道封装

连接到逻辑路由器的带有localnet VLAN标记的逻辑交换机的集中路由

为了克服上一节中描述的隧道封装(tunnel encapsulation)问题，OVN支持为带有localnet VLAN标记的逻辑交换机，启用集中路由的选项。

CMS可以配置选项：将所有连接到相应逻辑交换机（带有localnet vlan标记）logical_router_port的reside-on-redirect-chassis选项设为true ，这会导致网关chassis（承载分布式网关端口）处理这些网络的所有路由，使其集中化。它将回复对逻辑路由器端口IP的ARP请求。

如果逻辑路由器没有连接到提供外部连接的localnet逻辑交换机的分布式网关端口，则OVN将忽略此选项。当VM发送需要路由的东西向流量时，会发生以下情况：

当vm发送需要NATting的外部流量时，会发生以下情况：

对于反向外部流量，将发生以下情况：

VTEP网关的生命周期

网关其实是一种chassis，用于在逻辑网络的OVN管理部分和物理VLAN之间转发流量，将基于隧道的逻辑网络扩展到物理网络。

以下步骤通常涉及OVN和VTEP数据库模式的详细信息。请分别参阅ovn-sb，ovn-nb和vtep，了解关于这些数据库的详细信息。

请注意，VTEP逻辑交换机的tunnel_key列在创建时未被填充。当相应的vtep逻辑交换机绑定到OVN逻辑网络时，ovn-controller-vtep才将设置列内容。

禁止将同一个VTEP逻辑交换机绑定到不同的OVN逻辑网络，否则会在日志中产生警告。

12 安全

12.1、针对南向数据库的基于角色的访问控制

为了提供额外的安全性以防止OVN chassis受到攻击，从而防止流氓软件对南向数据库状态进行任意修改，从而中断OVN网络，
从而有了针对南向数据库的基于角色的访问控制策略（请参阅ovsdb-server部分以获取更多详细信息）。

基于角色的访问控制（RBAC）的实现需要在OVSDB模式中添加两个表：RBAC_Role表，该表由角色名称进行索引，并将可以对给定角色进行修改的各个表的名称映射到权限表中的单个行，其中包含该角色的详细权限信息，权限表本身由包含以下信息的行组成：

要为ovn-controller连接到南向数据库启用RBAC，需要以下步骤：

12.2、使用IPsec加密隧道通信

OVN隧道流量需流经物理路由器和交换机，而这些物理设备可能不受信任（公共网络中的设备），或者可能受到危害。对隧道流量启用加密可以防止对流量数据进行监视和操作。

隧道流量是用IPsec加密的。CMS设置北向NB_Global表中的IPsec列，以启用或禁用IPsec加密。如果ipsec为true，则所有OVN隧道都将加密。如果ipsec为false，则不会加密OVN隧道。

当CMS更新北向NB_Global表中的ipsec列时，ovn-northd将该值复制到南向SB_Global表中的ipsec列。每个chassis中的ovn-controller监视南向数据库，并相应地设置OVS隧道接口的选项。OVS隧道接口选项由ovs-monitor-ipsec守护程序监视，该守护程序通过配置IKE守护程序来启动ipsec连接。

Chassis使用证书相互验证。如果隧道中的另一端提供由受信任的CA签名的证书，并且公用名（CN）与预期的Chassis名匹配，则验证成功。

基于角色的访问控制（RBAC）中使用的SSL证书可以在IPsec中使用。也可以使用ovs-pki创建不同的证书。证书要求是x.509 version 3，并且将CN字段和SubjectAltName字段设置为Chassis名称。

在启用IPsec之前，需要在每个Chassis中安装CA证书、Chassis证书和私钥。
请参阅ovs vswitchd.conf.db来设置基于CA的IPsec身份验证。

13 设计决策

13.1、隧道（tunnel）封装

OVN标注从一个hypervisor发送到另一个的逻辑网络包，这些包包含以下三个元数据，他们以encapsulation-specific的方式编码：

对于hypervisor到hypervisor的流量，OVN仅支持Geneve和STT封装，原因如下：

由于其灵活性，hypervisor之间的首选封装方案是Geneve。对于Geneve封装，OVN在Geneve VNI中传输逻辑数据路径标识符。
OVN将类别为0x0102，类型为0x80的TLV中的逻辑入口端口和逻辑出口端口从MSB传输到LSB，其编码为32位，如下所示：

1
15
16

+---+------------+-----------+
|rsv|ingress port|egress port|
+---+------------+-----------+

0

不支持Geneve的网卡环境，因为性能的原因，可能更偏向STT封装。对于STT封装，OVN将STT 64位隧道ID中所有三个逻辑元数据编码如下，从MSB到LSB分别是：

9
15
16
24

+--------+------------+-----------+--------+
|reserved|ingress port|egress port|datapath|
+--------+------------+-----------+--------+

0

为了连接到网关，除了Geneve和STT之外，OVN还支持VXLAN，因为在top-of-rack (ToR)交换机上，只有VXLAN是普遍支持的。、
目前，网关具有与由VTEP模式定义的能力匹配的特征集，因此元数据的比特数是必需的。将来，不支持封装大量元数据的网关可能会继续减少功能集。

VTEP 网关

Neutron 子项目networking-l2gw 支持L2Gateway，仅支持连接物理网络的 VLAN 到逻辑网络的 VXLAN.

OVN 可以通过 VTEP 网关把物理网络和逻辑网络连接起来，VTEP 网关可以是 TOR（Top of Rack）switch，目前很多硬件厂商都支持，比如 Arista，Juniper，HP 等等；也可以是软件做的逻辑 switch，OVS 社区就做了一个简单的VTEP 模拟器。VTEP网关需要遵守 VTEP OVSDB schema，它里面定义了 VTEP 网关需要支持的数据表项和内容，VTEP 通过 OVSDB 协议与 OVN 通信，通信的流程 OVN 也有相关标准，VTEP 上需要一个 ovn-controller-vtep 来做 ovn-controller 所做的事情。VTEP 网关和 HV 之间常用 VXLAN 封装技术。

如图上图所示，PH1 和 PH2 是连在物理网络里面的 2 个服务器，VM1 到 VM3 是 OVN 里面的 3 个虚拟机，通过 VTEP 网关把物理网络和逻辑网络连接起来，从逻辑上看，PH1，PH2，VM1-VM3 就像在一个物理网络里面，彼此之间可以互通。

VTEP OVSDB schema 里面定义了三层的表项，但是目前没有硬件厂商支持，VTEP 模拟器也不支持，所以 VTEP 网络只支持二层的功能，也就是说只能连接物理网络的 VLAN 到逻辑网络的 VXLAN，如果 VTEP 上不同 VLAN 之间要做路由，需要 OVN 里面的路由器来做。

###