声明：本站文章皆基于公开来源信息，仅代表作者个人观点，与作者所在公司无关！

OVN 架构分析

 

     OVN 是 Open vSwitch 社区在 2015 年 1 月份才宣布的一个子项目，OVN 使用 Open vSwitch功能提供一个网络虚拟化方案， 不同于一般的SDN Controller，它主要专注于L2/L3和Security Group，利用轻量级控制平面提高当前网络环境下Open vSwitch的工作效率。OVN代码被放在Open vSwitch代码库，作为Open vSwitch的功能部分发布，2016.9.28随着Open vSwitch版本2.6.0发布第一个非实验版本。

  目前为止 OVN 已经支持很多功能：

  • Logical switches：逻辑交换机，用来做二层转发。
  • L2/L3/L4 ACLs：二到四层的 ACL，根据报文的 MAC 地址，IP 地址，端口号做访问控制。
  • Logical routers：逻辑路由器，分布式的，用来做三层转发。
  • NAT/LB： OVS + Conntrack支持NAT/LB。
  • Multiple tunnel overlays：支持多种隧道封装技术，有 Geneve，STT 和 VXLAN。
  • TOR switch or software logical switch gateways：支持使用硬件 TOR switch 或者软件逻辑 switch 当作网关来连接物理网络和虚拟网络。
  • Container：为虚机和虚机内的Container提供网络。

       OVN 运行平台仅要求能够运行 Open vSwitch，OVN 可以和 Linux，Docker，DPDK 还有 Hyper-V 兼容。 OVN 可以和很多 CMS（Cloud Management System）集成到一起，比如 Openstack Neutron

架构设计

  • Openstack/CMS plugin 是 CMS 和 OVN 的接口，将CMS 的配置转化成 OVN 的格式写到 Nnorthbound DB 。
  • Northbound DB 存储逻辑数据，与传统网络设备概念一致，比如 logical switch，logical router，ACL，logical port。
  • ovn-northd 类似于一个集中式控制器，把Northbound DB 里面的数据翻译后写到 Southbound DB 。
  • Southbound DB 保存的数据和 Northbound DB 语义完全不一样，主要包含 3 类数据，一是物理网络数据，比如 HV（hypervisor）的 IP 地址，HV 的 tunnel 封装格式；二是逻辑网络数据，比如报文如何在逻辑网络里面转发；三是物理网络和逻辑网络的绑定关系，比如逻辑端口关联到哪个 HV 上面。
  • ovn-controller 是 OVN 里面的 agent，类似于 neutron 里面的 ovs-agent，运行在每个 HV 上面，北向，ovn-controller 会把物理网络的信息写到 Southbound DB，南向，把 Southbound DB 保存的数据转化成 Openflow flow 配到本地的 OVS table 里面，来实现报文的转发。 
  • ovs-vswitchd 和 ovsdb-server 是 OVS 的两个进程。

OVN Northbound DB

   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）。
  • Logical_Port：每一行代表一个逻辑端口，每创建一个 neutron port，networking-ovn 会在这张表里增加一行，每行保存的信息有端口的类型，比如 patch port，localnet port，端口的 IP 和 MAC 地址，端口的状态 UP/Down。
  • ACL：每一行代表一个应用到逻辑交换机上的 ACL 规则，如果逻辑交换机上面的所有端口都没有配置 security group，那么这个逻辑交换机上不应用 ACL。每条 ACL 规则包含匹配的内容，方向，还有动作。
  • Logical_Router：每一行代表一个逻辑路由器，每创建一个 neutron router，networking-ovn 会在这张表里增加一行，每行保存了它包含的逻辑的路由器端口。
  • Logical_Router_Port：每一行代表一个逻辑路由器端口，每创建一个 router interface，networking-ovn 会在这张表里加一行，它主要保存了路由器端口的 IP 和 MAC。

OVN Southbound DB

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

  • Chassis：每一行表示一个 HV 或者 VTEP 网关，由 ovn-controller/ovn-controller-vtep 填写，包含 chassis 的名字和 chassis 支持的封装的配置（指向表 Encap），如果 chassis 是 VTEP 网关，VTEP 网关上和 OVN 关联的逻辑交换机也保存在这张表里。
  • Encap：保存着 tunnel 的类型和 tunnel endpoint IP 地址。
  • Logical_Flow：每一行表示一个逻辑的流表，这张表是 ovn-northd 根据 Nourthbound DB 里面二三层拓扑信息和 ACL 信息转换而来的，ovn-controller 把这个表里面的流表转换成 OVS 流表，配到 HV 上的 OVS table。流表主要包含匹配的规则，匹配的方向，优先级，table ID 和执行的动作。
  • Multicast_Group：每一行代表一个组播组，组播报文和广播报文的转发由这张表决定，它保存了组播组所属的 datapath，组播组包含的端口，还有代表 logical egress port 的 tunnel_key。
  • Datapath_Binding：每一行代表一个 datapath 和物理网络的绑定关系，每个 logical switch 和 logical router 对应一行。它主要保存了 OVN 给 datapath 分配的代表 logical datapath identifier 的 tunnel_key。
  • Port_Binding：每一行包含的内容主要有 logical port 的 MAC 和 IP 地址，端口类型，端口属于哪个 datapath binding，代表 logical input/output port identifier 的 tunnel_key, 以及端口处在哪个 chassis。端口所处的 chassis 由 ovn-controller/ovn-controller 设置，其余的值由 ovn-northd 设置。

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

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 封装时使用了三种数据：

  • Logical datapath identifier（逻辑的数据通道标识符）：datapath 是 OVS 里面的概念，报文需要送到 datapath 进行处理，一个 datapath 对应一个 OVN 里面的逻辑交换机或者逻辑路由器，类似于 tunnel ID。这个标识符有 24-bit，由 ovn-northd 分配的，全局唯一，保存在 Southbound DB 里面的表 Datapath_Binding 的列 tunnel_key 里。
  • Logical input port identifier（逻辑的入端口标识符）：进入 logical datapath 的端口标识符，15-bit 长，由 ovn-northd 分配的，在每个 datapath 里面唯一。它可用范围是 1-32767，0 预留给内部使用。保存在 Southbound DB 里面的表 Port_Binding 的列 tunnel_key 里。
  • Logical output port identifier（逻辑的出端口标识符）：出 logical datapath 的端口标识符，16-bit 长，范围 0-32767 和 logical input port identifier 含义一样，范围 32768-65535 给组播组使用。对于每个 logical port，input port identifier 和 output port identifier 相同。

      如果 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 不做处理。

Neutron VS OVN

       Neutron 二层报文处理是通过 OVS OpenFlow 流表来实现，三层报文处理是通过 Linux TCP/IP 协议栈来实现。

      OVN 里面数据的读写都是通过 OVSDB 协议来做的，取代了 neutron 里面的消息队列机制，使用 OVN 之后，neutron 里面所有的 agent 都不需要了，neutron 变成了一个 API server 来处理用户的 REST 请求，其他的功能都交给 OVN 来做，只需要在 neutron 里面加一个 plugin 来调用配置 OVN。Plugin 使用 OVSDB 协议来把用户的配置写在 Northbound DB 里面，ovn-northd 监听到 Northbound DB 配置发生改变，然后把配置翻译到 Southbound DB 里面，ovn-controller 注意到 Southbound DB 数据的变化，然后更新本地的流表。OVN 里面报文的处理都是通过 OVS OpenFlow 流表来实现.。

SecurityGroup

                      Neutron security group

    Neutron 里面的 security group 是作用在 VM 对应的 neutron port 上面，因为 OVS internal port 不能经过 Linux 协议栈，所以不能直接通过 iptables 来做 security group，加上 OVS 2.4.0 以前都不支持 conntrack（Linux kernel netfiler 的一个功能，可以记录连接状态，是有状态访问控制和 NAT 的必备条件），如果单独通过匹配报文字段来做，有些访问控制实现不了并且性能会受到影响，所以 neutron 给每个应用了 security group 的 port 创建一个 linux bridge，neutron tap port 连到 linux bridge，然后创建一对 veth pair，一端连接 linux bridge，另一端连接 OVS bridge（默认是 br-int）。Security group 里面的 rule 通过 iptables 配到 netfilter 里面，作用在 neutron tap port 上面，创建 linux bridge 的目的就是为了利用 iptables 来做 security group。

                OVN security group

   OVN 的 security group 每创建一个 neutron port，只需要把 tap port 连到 OVS bridge（默认是 br-int），不用像现在 Neutron 那样创建那么多 network device，大大减少了跳数。更重要的是，OVN 的 security group 是用到了 OVS 的 conntrack 功能，可以直接根据连接状态进行匹配，而不是匹配报文的字段，提高了流表的查找效率，还可以做有状态的防火墙和 NAT。OVS 的 conntrack 是用 Linux kernel 的 netfilter 来做的，调用 netfiler userspace netlink API 把来报文送给 Linux kernel 的 netfiler connection tracker 模块进行处理，这个模块给每个连接维护一个连接状态表，记录这个连接的状态，OVS 获取连接状态，Openflow flow 可以 match 这些连接状态。

L3 Forwarding

      Neutron 的三层功能主要有路由，SNAT 和 Floating IP（也叫 DNAT），它是通过 Linux kernel 的 namespace 来实现的，每个路由器对应一个 namespace，利用 Linux TCP/IP 协议栈来做路由转发。在支持 DVR（分布式虚拟路由器，在 Juno 版本增加的一个功能）之前，Neutron 的三层功能是在网络节点做的，所有东西向跨网段的流量都需要经过网络节点做路由，这使得网络节点成为瓶颈。有了 DVR 之后，路由变成了分布式，每个计算节点上面都可以做路由，东西向流量直接通过计算节点路由而不需要经过网络节点，Floating IP 也是在计算节点上面实现的，对于有 floating IP 的 VM 访问公网，直接走计算节点上面的路由器出去，对于没有 floating IP 的 VM 访问公网才会从网络节点的路由器 SNAT 出去。DVR 减轻了网络节点的负担，但是也引入了一些问题，DVR 需要每个计算节点占用 1个公网 IP，并且 DVR 还不能和 FWaaS，VPNaaS 和 LBaaS 集成起来。

     OVN 支持原生的三层功能，不需要借助 Linux TCP/IP stack，用 OpenFlow 流表来实现路由查找，ARP 查找，TTL 和 MAC 地址的更改。OVN 的路由也是分布式的，路由器在每个计算节点上都有实例，和 DVR 一样。有了 OVN 之后，不需要 neutron l3 agent 了。(目前 OVN 三层功能只能做东西向路由，Floating IP 的设计和 DVR 一样，方案还在 review 过程中，SNAT 的实现方法还没有确定。所以如果需要所有的三层功能，暂时还是要使用 neutron l3 agent。)

VTEP 网关 

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

参考文档：

    https://github.com/openstack/networking-l2gw/blob/master/doc/source/usage.rst

    http://kimizhang.com/neutron-l2-gateway-hp-5930-switch-ovsdb-integration/

        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 里面的路由器来做。

 

OVN Scale Test

     https://github.com/openvswitch/ovn-scale-test

posted @ 2017-06-30 17:35  Hi，云计算！  阅读(3590)  评论(1)  编辑  收藏  举报