OVN架构原理

ovn-architecture

本文最初整理在我的github上SDN-Learning-notes

本文翻译自ovs官方手册，有删减

OVN架构

OVN（即Open Virtual Network）是一款支持虚拟网络抽象的软件系统。OVN在OVS现有功能的基础上原生支持虚拟网络抽象，例如虚拟L2，L3覆盖网络以及完全组。诸如DHCP，DNS的服务也是其关注的内容。就像OVS一样，OVN的设计目标是可以大规模运行的高质量生产级实施方案。

OVN部署由以下几个组件组成：

• CMS（云管理系统）。这是OVN的最终用户（通过其用户和管理员）。与OVN集成需要安装与CMS特定的插件和相关软件（见下文）。OVN最初的目标CMS是OpenStack。我们通常会说一个CMS，但多个CMS也可以管理一个OVN的不同部分。

• 安装在一个中央位置的OVN数据库，可以是物理节点，虚拟节点，甚至是一个集群。

• 一个或多个（通常是很多）虚拟机管理程序（hypervisors）。hypervisors必须运行Open vSwitch并执行IntegrationGuide.rst在OVS源代码树中所述的接口。任何支持的OVS的hypervisor平台都是可以接受的。

• 零个或多个网关。 网关通过在隧道和物理以太网端口之间双向转发数据包，将基于隧道的逻辑网络扩展到物理网络。这允许非虚拟机器参与逻辑网络。网关可能是物理机，虚拟机或基于ASIC同时支持vtep模式的硬件交换机。

hypervisor和网关一起被称为传输节点或chassis

下图显示了OVN和相关的主要组件的软件交互:

                                         CMS
                                          |
                                          |
                              +-----------|-----------+
                              |           |           |
                              |     OVN/CMS Plugin    |
                              |           |           |
                              |           |           |
                              |   OVN Northbound DB   |
                              |           |           |
                              |           |           |
                              |       ovn-northd      |
                              |           |           |
                              +-----------|-----------+
                                          |
                                          |
                                +-------------------+
                                | OVN Southbound DB |
                                +-------------------+
                                          |
                                          |
                       +------------------+------------------+
                       |                  |                  |
         HV 1          |                  |    HV n          |
       +---------------|---------------+  .  +---------------|---------------+
       |               |               |  .  |               |               |
       |        ovn-controller         |  .  |        ovn-controller         |
       |         |          |          |  .  |         |          |          |
       |         |          |          |     |         |          |          |
       |  ovs-vswitchd   ovsdb-server  |     |  ovs-vswitchd   ovsdb-server  |
       |                               |     |                               |
       +-------------------------------+     +-------------------------------+

从图的顶部开始，依次为：

1. 首先是如上文所述的云管理系统。

2. OVN/CMS插件是连接到OVN的CMS组件。 在OpenStack中，这是一个Neutron插件。该插件的主要目的是转换CMS中的逻辑网络的配置为OVN可以理解的中间表示。这个组件是必须是CMS特定的，所以对接一个新的CMS需要开发新的插件对接到OVN。所有在这个组件下面的其他组件是与CMS无关的。

3. OVN北向数据库接收由OVN/CMS插件传递的逻辑网络配置的中间表示。数据库模式与CMS中使用的概念是“阻抗匹配的”，因此它直接支持逻辑交换机，路由器，ACL等概念。有关详细信息，请参见ovn-nb。（OVN北向数据库只有两个客户端：在它上面的OVN/CMS插件和在它下面的ovn-northd）

4. ovn-northd用于连接到它上面的OVN北行数据库和它下面的OVN南行数据库。它将传统网络概念（从OVN北行数据库中取得）的逻辑网络配置转换为其下面的OVN南行数据库中的逻辑数据路径流。

5. OVN南行数据库是系统的中心。（OVN南向数据库也只有两个客户端：它上面是ovn-northd以及在它下面的每个传输节点上的ovn-controller）。OVN南向数据库包含三种类型的数据：指定如何到达hypervisor和其他节点的物理网络（PN）表；用于描述逻辑网络的逻辑数据路径流的逻辑网络（LN）表；用于将逻辑网络组件的位置链接到物理网络的绑定表。hypervisor填充PN和Port_Binding表，而ovn-northd填充LN表。

   为了集群的可用性，OVN南行数据库性能必须随传输节点的数量而扩展。这可能需要一些ovsdb-server上的工作。

其余组件在每个hypervisor中都是一样的

1. ovn-controller是每个hypervisor和软件网关上的OVN代理。北向，它连接到OVN南行数据库以了解OVN配置和状态，并把hypervisor的状态填充绑定表中的Chassis列以及PN表。南向，它连接到ovs-vswitchd作为OpenFlow控制器用于控制网络通信，并连接到本地ovsdb-server以允许它监视和控制Open vSwitch的配置。

2. ovs-vswitchd和ovsdb-server是标准的Open vSwitch组件。

OVN中的信息流

OVN中的配置数据从北向南流动。CMS通过其OVN/CMS插件，通过北向数据库将逻辑网络配置传递给ovn-northd。反过来，ovn-northd将配置信息编译为较低级别的表单，并通过南行数据库将其传递到所有的chassis。

OVN中的状态信息从南向北流动。OVN目前仅提供以下几种形式的状态信息：

• 首先，ovn-northd在北向Logical_Switch_Port表中填充up列：如果南向Port_Binding表中逻辑端口的chassis列非空，则设置为true，否则设置为false。这使CMS能够检测虚拟机的网络连接何时可用。

• 其次，OVN向CMS提供关于其配置实现的反馈，即CMS提供的配置是否已经生效。 此功能要求CMS参与序列号协议，其工作方式如下：

  1. 当CMS更新北向数据库中的配置时，作为同一事务的一部分，它会增加NB_Global表中的nb_cfg列的值。（这只有当CMS想知道何时配置已经实现时才是必要的。）
  2. 当ovn-northd根据北向数据库的给定快照更新南行数据库时，作为同一事务的一部分，它将北向NB_Global表中的nb_cfg列复制到南行数据库SB_Global表中。（因此，监视两个数据库的观察者可以确定南行数据库何时与北向数