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

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) 负责一系列动作（更新、创建、删除）网络、子网、端口。

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

1. 用户通过OpenStack的界面（horizon）输入消息给networking API，再发送给Neutron server
2. Neutron server接受信息发送给plugin
3. Neutron server/plugin 更新DB
4. Plugin通过REST API发送消息给SDN控制器
5. 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 VPN自己制定的消息通讯机制，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了。

3.3.3 OVN L2

        OVN的L2功能都是基于OpenFlow流表实现的，包括Port Security、Egress ACL、ARP Responder、DHCP、Destiniation Lookup、Ingress ACL等。

参考链接

理解OpenStack与SDN控制器的集成_筋斗云计算的博客-CSDN博客_openstack sdn

OpenStack与SDN控制器的集成 | SDNLAB | 专注网络创新技术

为OpenStack而生的SDN控制器——OVN_筋斗云计算的博客-CSDN博客_openstack sdn控制器

openstack架构详解图_大规模SDN云计算数据中心组网的架构设计_weixin_39804523的博客-CSDN博客

开源SDN控制器和商用SDN控制器一览_weixin_33714884的博客-CSDN博客

OVN – OVN OpenStack(二)_cuibin1991的博客-CSDN博客

OpenStack中SDN泛谈1 (Neutron&ODL&ONOS) - 知乎

OpenStack中SDN泛谈3 (OVN&Dragonflow) - 知乎

OpenStack中SDN泛谈4 (SDN发展与架构) - 简书

 《重识云原生系列》专题索引： 

1. 第一章——不谋全局不足以谋一域
2. 第二章计算第1节——计算虚拟化技术总述
3. 第三章云存储第1节——分布式云存储总述
4. 第四章云网络第一节——云网络技术发展简述
5. 第四章云网络4.2节——相关基础知识准备
6. 第四章云网络4.3节——重要网络协议
7. 第四章云网络4.3.1节——路由技术简述
8. 第四章云网络4.3.2节——VLAN技术
9. 第四章云网络4.3.3节——RIP协议
10. 第四章云网络4.3.4节——OSPF协议
11. 第四章云网络4.3.5节——EIGRP协议
12. 第四章云网络4.3.6节——IS-IS协议
13. 第四章云网络4.3.7节——BGP协议
14. 第四章云网络4.3.7.2节——BGP协议概述
15. 第四章云网络4.3.7.3节——BGP协议实现原理
16. 第四章云网络4.3.7.4节——高级特性
17. 第四章云网络4.3.7.5节——实操
18. 第四章云网络4.3.7.6节——MP-BGP协议
19. 第四章云网络4.3.8节——策略路由
20. 第四章云网络4.3.9节——Graceful Restart(平滑重启)技术
21. 第四章云网络4.3.10节——VXLAN技术
22. 第四章云网络4.3.10.2节——VXLAN Overlay网络方案设计
23. 第四章云网络4.3.10.3节——VXLAN隧道机制
24. 第四章云网络4.3.10.4节——VXLAN报文转发过程
25. 第四章云网络4.3.10.5节——VXlan组网架构
26. 第四章云网络4.3.10.6节——VXLAN应用部署方案
27. 第四章云网络4.4节——Spine-Leaf网络架构
28. 第四章云网络4.5节——大二层网络
29. 第四章云网络4.6节——Underlay 和 Overlay概念
30. 第四章云网络4.7.1节——网络虚拟化与卸载加速技术的演进简述
31. 第四章云网络4.7.2节——virtio网络半虚拟化简介
32. 第四章云网络4.7.3节——Vhost-net方案
33. 第四章云网络4.7.4节vhost-user方案——virtio的DPDK卸载方案
34. 第四章云网络4.7.5节vDPA方案——virtio的半硬件虚拟化实现
35. 第四章云网络4.7.6节——virtio-blk存储虚拟化方案
36. 第四章云网络4.7.8节——SR-IOV方案
37. 第四章云网络4.7.9节——NFV
38. 第四章云网络4.8.1节——SDN总述
39. 第四章云网络4.8.2.1节——OpenFlow概述
40. 第四章云网络4.8.2.2节——OpenFlow协议详解
41. 第四章云网络4.8.2.3节——OpenFlow运行机制
42. 第四章云网络4.8.3.1节——Open vSwitch简介
43. 第四章云网络4.8.3.2节——Open vSwitch工作原理详解
44. 第四章云网络4.8.4节——OpenStack与SDN的集成
45. 第四章云网络4.8.5节——OpenDayLight
46. 第四章云网络4.8.6节——Dragonflow