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

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

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的架构如下图所示:

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

        抛开第三方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) 负责一系列动作(更新、创建、删除)网络、子网、端口。

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

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

  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架构实现

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

  • 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如今的占有率肯定会更高。

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

        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架构

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

        在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,可以一定程度的缓解瓶颈问题。

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

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

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

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了。

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

3.3.3 OVN L2

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

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

参考链接

理解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

你可能感兴趣的:(云原生专栏,云原生,云网络,SDN,OVN,OVS)