【重识云原生】第四章云网络4.8.4节——OpenStack与SDN的集成

江中散人_Jun

发布于 2022-07-12 16:48:12

9820

发布于 2022-07-12 16:48:12

文章被收录于专栏：云原生布道专栏云原生布道专栏

1 Neutron项目简介

1.1 项目简介

OpenStack自己官方的网络项目是Neutron，Neutron有着自己的一套网络实现方案：基于linux namespace，构建一个个相对独立的虚拟网络功能单元。通过这些网络功能单元提供OpenStack所需要的网络服务。Neutron在自己的实现之外，也考虑了第三方功能的兼容，例如2层的功能被抽象到了ML2的mechanism driver，各个网络功能被抽象到了对应的service plugin。第三方SDN只需要实现相应的mechanism driver和service plugins，就能接入到OpenStack Neutron。进而在整个OpenStack环境下使用。Neutron的架构如下图所示：

抛开第三方SDN接入实现不说，单看Neutron的实现。Neutron大体上可以分成两个部分，Neutron server和agents。

1.2 Neutron server

Neutron的北向（northbound）接口，DB接口。Neutron server实现了网络数据模型的抽象，和基于这些抽象模型的业务逻辑。Neutron server有整个OpenStack的虚拟网络信息，有关网络的可达信息和统计数据的计算都将在Neutron server进行。Neutron server可以部署多个，以达到HA的效果，并达到水平扩展的目的。从划分Controller nodes，Network nodes和Compute nodes的角度来说，Neutron server属于Controller nodes。

1.3 Agents

Neutron的南向（southbound）接口。这里的agents指的是各种agents，例如DHCP agent，L3 agent，ovs-agent，metadata-agent，l2gw-agent等等。可以看出来，Neutron的具体网络功能是由一个个agent完成。Agents可以是Network nodes的一部分，也可以是Compute nodes的一部分，具体要看是什么agent，并且网络是集中式的还是分布式的。

ML2 的plugin都是属于core。分为type和mechanism两种。Type drivers (如flat, VLAN, GRE 和VXLAN) 定义 L2 type。 mechanism drivers (如OVS, adrivers from ODL, Cisco, NEC, etc) 负责一系列动作（更新、创建、删除）网络、子网、端口。

整个过程可以分为下面几个步骤：

用户通过OpenStack的界面（horizon）输入消息给networking API，再发送给Neutron server
Neutron server接受信息发送给plugin
Neutron server/plugin 更新DB
Plugin通过REST API发送消息给SDN控制器
SDN控制器接受消息然后通过南向的plugins/protocols, 如OpenFlow, OVSDB or OF-Config.

1.4 RPC（Remote Procedure Call）

Neutron server与agents之间通过双向的RPC进行数据交互。也就是上面图中的message queue。

1.5 DB（Database）

Neutron通常与OpenStack其他项目共用一种SQL数据库。Neutron server是Neutron中唯一与DB有交互的进程或者服务。

2 SDN架构实现

Application & Orchestration Tier

传统的SDN架构里面没有这一层，在SDN platform里面新增了这一层。而OpenStack也在这一层。SDN想要接入到OpenStack，必须要在这一层完成适配，将OpenStack的请求转换成SDN的请求。在这一层不需要关心SDN底层的具体实现，因为SDN已经将底层网络抽象成纯软件的概念。

Northbound Interface

Northbound Interface是SDN将底层网络抽象成软件概念，并暴露出来的接口。

Application & Orchestration Tier通过Northbound Interface接入SDN Controller。这个接口通常是，但不局限于是RESTful API。像ODL还提供了OSGI接口，而OVN和Dragonflow直接提供DB读写的接口。

换一个角度，不论底层的SDN是什么，单看OpenStack提供的networking服务，Neutron server也可以看成是一个Northbound Interface。因为它提供了相应的网络数据模型的RESTful API。

Control Plane Tier

SDN的最核心部分。又分成了几个部分：

Database

SDN自己是一个集群内运行的软件。有自己的状态和数据，因此必须要有一个Database来存储相关的数据。而SDN主要是进行网络运算，网络运算的要求就是高速，低延时。因此对Database的性能要求也比较高。基于内存的NoSQL数据库通常具有更好的性能，更快的响应速度。在这类数据库中，Cassandra是选用最多的数据库，OpenContrail，Midonet，Dragonflow都支持Cassandra。并且有报告表明，Cassandra的性能的确优于同类的其他数据库。

鉴于Database的重要性，通常会将Database部署在独立的节点，并且考虑到HA和水平扩展，Database节点也会部署成一个集群。

Message

由于SDN是一个集群内运行的软件，因此SDN需要定义自己的消息通讯机制，以供集群内的各个节点之间通讯。像ODL和Midonet采用的是RPC作为消息机制，OpenContrail则是参考MPLS V**自己制定的消息通讯机制，OVN和Dragonflow则是简单的消息发布订阅机制。

SDN Controller

终于到了SDN Controller，根据ONF（Open Networking Foundation）的定义，SDN Controller是一个逻辑集中的控制器。逻辑集中的控制器，那物理上就不一定集中了。实际上哪怕是集中式SDN控制器，出于HA和水平扩展的考虑，也不会部署成物理集中。而SDN控制器也朝着分布式的方向发展。像OpenContrail，Midonet，OVN，Dragonflow都有不同程度的分布式。

SDN控制器包含了各个网络功能的实现。也就是一个个Network service。具体的来说，Network service就是将Northbound的抽象数据和Southbound的具体网络协议做了适当的转换和翻译。也就是这样，原本生硬晦涩的network element，经过Network Service可以灵活的通过软件来定义。

SDN Controller还包括了数据层面（Data plane）的接口，当然，这个接口一般不会太具体。

Southbound Protocol

各类控制协议和网络协议。虽然感觉上很多，但是最常见的还是OpenFlow和NetConf。这是network elements暴露出来的接口，只有支持相应协议的网络设备才有可能成为SDN的一部分。

Data Plane Tier

这一层就是实际的网络设备层，包含各种网络设备。网络设备本身也分为physical device和virtual device。Physical device就是支持OpenFlow或者NetConf或者其他控制协议的交换机，路由器和其他的网络设备。这些硬件设备目前占据SDN市场的最大份额，也是各大传统网络设备厂商的地盘。Virtual device，就是支持OpenFlow或者其他控制协议的虚拟网络设备。像OVS，OpenContrail的vRouter。Virtual device被认为是最有发展前景的，并且在成本上也优于physical device。

3 为OpenStack而生的SDN控制器——OVN

3.1 为什么OVN会出现？

OpenvSwitch （OVS）以其丰富的功能和相对优秀的性能，成为OpenStack中广泛使用的虚拟交换机。在内核部分合并进入Linux主干之后，Open Vswitch几乎成为了开源虚拟交换机的事实标准。

下图是2014年的一个调查，时过境迁，nova-network已经被废弃，OpenvSwitch如今的占有率肯定会更高。

OVS甚至可以说是网络虚拟化里最重要的工业级开源产品，OVS模仿物理交换机设备的工作流程，实现了很多物理交换机当时才支持的许多网络功能。OVN提供了许多原生的虚拟网络功能，提升了OVS的工作效率和性能。

OVN是OpenvSwitch项目组为OpenvSwitch开发SDN控制器，基于这个出发点，OVN在创立之初只关注2-3层的虚拟网络，这是区别于其他全功能的SDN控制器或者平台。OVN可以看成是OVS的补充，因此OVN可以运行在任何OVS兼容的环境下。虽然两者在一个项目下，OVN与OVS的连接采用的是OVS的通用接口，因此ovs-vswitchd和ovsdb-server不会因为OVN而受到影响。另一方面，就算不使用OVN，对OVS本身也没有什么影响。

随着OVS 2.6的发布，OVN的第一个版本也随着发布（包含在OVS中），OVN从创立之初就考虑了与OpenStack的集成。OVN通过networking-ovn项目与OpenStack集成。

OVN是一个厂商中立的开源项目，背后并没有一个大的厂商在操纵，项目的发起是VMware的工程师，项目的推进有Redhat和IBM等其他公司的参与。相比ODL、ONOS其架构也较为简单。OVN在创立之初就考虑了与OpenStack的集成，因此OVN在OpenStack环境下工作的较好，一些OpenStack Neutron已知的问题，在OVN中都有较好的解决，例如DVR，Security Group的性能问题。对于已有的OpenStack + OVS环境，升级到OVN也是一个不错的选择。据说OVN已经在数百个物理节点上进行了部署测试，并且用ovn-scale-test项目进行了数千个节点的模拟测试。

其现在的主要问题就在于Database node的瓶颈问题，相信后继的改进能够解决这个问题。其他问题在于项目的定位不是一个全功能的SDN，因此只有2-3层的virtual networking。不过这个倒是契合OpenStack Neutron的定位。其他的advanced 功能可以通过OpenStack Neutron的各个子项目弥补。

3.2 OVN架构

在OVS的基础上，OVN新增了两个进程：ovn-northd和ovn-controller，两个数据库：Northbound DB和Southbound DB。下面来分别看看：

3.2.1 Northbound DB

存储virtual networking data model，例如 Switch，Router，Port等。Northbound DB是由CMS（OpenStack）写入，也就是说与之前说过的SDN不太一样，OVN北向不提供RESTful接口，而是直接由CMS写入数据库内容。举个例子，在OpenStack Neutron的场景下，对应的在Neutron中创建一个Network，需要通过networking-ovn在Northbound DB中创建一个LogicalSwitch。

3.2.2 Ovn-northd

监听Northbound DB的变化，将Northbound DB的内容翻译成LogicalFlow，存储在Southbound DB。Ovn-northd是一个集中的进程，在OVN环境下一般运行在独立的Database node上，在下面会再提到Database node。

3.2.3 Southbound DB

存储LogicalFlow，Chassis和其他的一些信息。Southbound DB存储ovn-controller的数据。传统的集中式SDN控制器会根据已有的配置和数据计算OpenFlow规则，并下发到各个节点。而OVN将这个过程分解成了两部分：

先通过ovn-northd将配置和数据计算成LogicalFlow。一个LogicalSwitch下的LogicalFlow是一样的。
将LogicalFlow分发到各个ovn-controller，再由ovn-controller将计算出相应的OpenFlow规则下发。这样做的好处是一些全局的运算只需要做一次。

3.2.4 Ovn-controller

分布在各个计算节点（OVN中叫做chassis）的SDN controller。Ovn-controller向上读取Southbound DB的数据，应用在本地；并且读取本地的VIF和Chassis信息，向上更新。

3.2.5 OVN部署框架

OVN对于网络功能的实现，秉承的是分布式思想。因此网络功能都分布在计算节点，并且没有一个专门的网络节点。但是OVN需要独立的Database node。这是因为OVN目前采用ovsdb-server作为其DB，一方面，这对于OVN的部署很方便，因为OVN本身就基于OVS，采用ovsdb-server可以避免新增依赖。但是另一方面，ovsdb-server之前的主要应用场景是给OVS存储hypervisor本地的虚拟网络设备信息，而OVN是一个集群内运行的软件，ovsdb-server明显不能胜任这种大规模的数据读写。同时，前面说过ovn-northd是一个集中式进程，因此用一个独立的Database node来运行ovn-northd并存储Northbound DB和Southbound DB，可以一定程度的缓解瓶颈问题。

OVN与OpenStack集成之后的运行框架如下图所示：

3.3 实现原理

3.3.1安全组

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 这些连接状态。

3.3.2 OVN L3

Neutron 的三层功能主要有路由，SNAT 和 Floating IP（也叫 DNAT），它是通 Linux kernel 的namespace 来实现的，每个路由器对应一个 namespace，利用 Linux TCP/IP 协议栈来做路由转发。OVN 支持原生的三层功能，不需要借助 Linux TCP/IP stack，用OpenFlow 流表来实现路由查找，ARP 查找，TTL 和 MAC 地址的更改。OVN 的路由也是分布式的，路由器在每个计算节点上都有实例，有了 OVN 之后，不需要 Neutron L3 agent 了和DVR了。