SDN的横向扩展对OpenStack Neutron的影响

问题导读

1.OpenStack的Kilo版本集成了哪些项目？
2.Neutron所暴露的API分类与其子分类下支持的操作有哪些？
3.OpenStack和SDN控制器勾勒出怎么样的伟大的蓝图？
4.SDN控制器部署选项与OpenStack的集成带来哪些好处？

Neutron管理着运行于Openstack之上的虚拟化网络，并且为开发高级云服务创建了一系列松耦合及其相关的项目，如果把Neutron作为软件定义网络(SDN)的一个可扩展性应用是非常方便使用的。

每项服务属于一个单独的项目，这些项目由社区驱动，或者来自很多供应商和公司的贡献。重要的是，OpenStack的Kilo版本包含了12个集成项目：

• Nova（计算）：为云用户按需提供虚拟服务器/虚拟机。
• Neutron(网络)：将网络作为一项服务提供(虚拟网络服务)。
• Swift(目标存储)：允许API可访问的数据镜像、文件和文档的存储和调回。
• Cinder（块存储）：为用户虚拟机提供永久块存储。
• Glance(映像)：为计算节点提供一系列的硬盘镜像，这些镜像被虚拟机使用，
• Horizon(仪表板)：为管理员或者租户(用户)管理Openstack提供基于web的图形化用户界面(GUI)。
• Keystone(验证)：存储OpenStack服务认证和授权信息。
• Ceilometer(遥测)：监控和测量Openstack云使用信息，为计费、基准测试和统计提供依据。
• Heat(调度):通过合适的API调用为管理云应用提供调度服务。
• Ironic(Baremetal配置):旨在配置裸机代替虚拟机，从Nova的Baremetal驱动分支出来。
• Sahara(大数据作为服务):该项目提供一个简单的方法来配置一个运行于OpenStack之上以数据为目的的应用集群(Hadoop或者Spark)。
• Trove(数据库作为服务):该项目旨在提供云数据库服务，配置相关以及无关的数据库引擎功能。
  

虚拟网络是由租户或者管理员创建，为OpenStack计算所管理的虚拟机之间提供网络功能。Neutron是一项网络管理服务，提供一系列可扩展的API用来创建和管理虚拟网络。

在Neutron之前，OpenStack有一个简单、扁平的网络环境，不支持三层或者防火墙。这种网络服务内嵌于Nova服务器中，使得网络发生改变时很难适应。

Neutron的引入是用来将网络作为一项单独的服务，为网络抽象提供不同的解决方案，Neutron服务器提供抽象定义和管理，网络抽象的具体实施是由组件来实现。这种支持多租户的基于组件的架构，被认为是与技术无关和模块化的。我们需要注意Neutron是一项独立的服务，也就是说，Neutron可以运行为一项自主的服务，暴露API给不同的供应商，提供解决方案或者其他合适的扩展。

Neutron所暴露的API分类与其子分类下支持的操作总结如下。那些操作可以缩写为CRUD，即创建(C)、阅读(R)、更新(U)和删除(D)。核心API涵盖了基本和必须的网络操作，而扩展和属性API的功能是用来构建多功能虚拟网络。

核心API的操作

• 网络(CRUD)
• 子网(CRUD)
• 端口(CRUD)
  

扩展和属性API的操作

• 配额(RUD)
• 网络提供商可扩展属性(CRUD)
• 多个网络提供商可扩展(CR)
• 绑定扩展属性的端口(CRU)
• 安全组与规则(CRD)
• 三层网络功能(CRUD)
• 计费标签和规则(CRD)
• 负载均衡作为服务(LBaaS)(CRUD)
  

Neutron架构

软件定义网络技术的发展与成熟，基于SDN 技术的网络虚拟化发展，使得网络虚拟化可以不再基于物理网络设备实现，使网络虚拟化成为云计算网络技术的核心之一，越来越多的厂商关注网络虚拟化，并纷纷发布他们关于网络虚拟化方面的方案。

图一描述了OpenStack Neutron架构，由以下组件构成：

Neutron服务器

python后台服务是OpenStack网络的主要进程，一般运行于控制器节点(openstack部署中的一个术语)。它暴露API来加强网络模型，并且传递请求给netron组件。

插件

插件可以是核心组件也可以是一项服务。核心插件实现“核心”的Neutron API——二层网络和IP地址管理。服务插件提供“额外”的服务，例如三层路由、负载均衡、VPN、防火墙和计费。核心组件也可以通过相关的API扩展提供这些网络服务。简而言之，组件运行在控制节点上，并且调用网络API，这些API会同Neutron服务器、数据库和代理进行交互。

图一：OpenStack Neutron 架构

插件代理

插件代理指定正在被使用的Neutron插件。他们运行于计算节点之上，并且会同Neutron插件进行交互来管理虚拟交换机。这些代理在许多部署中是可选的，而且在每个虚拟机管理程序上可执行本地虚拟交换机配置。

消息队列

OpenStack组件，包括Neutron，使用高级消息队列协议(AMQP)进行内部通信。AMQP代理，RabbitMQ,位于Neutron的任何两个内部组件之间，允许它们通过松耦合的方式交互，例如，Neutron组件使用远程过程调用协议（RPC）与另外一个组件通信。

数据库

几乎所有组件都需要用数据库来维护一个持续的网络模型；因此,数据库的语法是由已配置的核心插件和服务插件来定义。

DHCP代理

这个代理是Neutron的一部分，给租户网络提供DHCP服务。它维护所需的DHCP配置，且在所有插件中，DHCP代理是相同的（它维护所有组件中相同的DHCP配置）。

三层代理

三层代理负责提供三层和NAT转发功能，目的是为租户网络中的虚拟机提供外网接入。

二层模块化核心插件

二层模块化（ML2）是Neutron的核心插件。ML2的引入(从OpenStack的Havana版本开始)是为了替代原有的统一插件(如，Open vSwitch和Linux桥接-它们仅仅是插件，而不是代理)消除冗余代码，降低开发和维护成本。根据ML2作者所定义的，模块化二层组件（ML2）组件是一个允许OpenStack Neutron同时利用二层网络多样性技术的架构，该二层网络技术来源于实际的复杂数据中心。

图二：ML2 组件结构

ML2通过驱动模型实现模块化。如图二所示，它包含了两类驱动：类型驱动和机制驱动。类型驱动(比如flat、虚拟局域网、GRE和VXLAN等) 定义了一个特殊的二层类型，每个可用网络类型由对应的类型驱动管理。该驱动维护了类型驱动具体的状态信息，实现了租户网络之间的隔离，这种隔离是由供应商网络验证过的。

另一方面，机制驱动是由厂商指定的（比如说OVS，还有来自ODL、Cisco、NEC等厂家的驱动），基于功能性的类型驱动——支持创建、更新和删除网络、子网和端口资源。我们应该注意到供应商有可能执行一整套新的类似于ML2的组件，或者仅仅实现一个机制驱动组件。Salvatore Orlando和Armando Miliaccio的对话使这个决定更容易实现。

OpenStack和SDN控制器：伟大的蓝图

软件定义网络的引入不仅是为了克服Neutron的缺陷，而且是为了提供支持多网络虚拟化技术(一个集中控制平面创建分隔的租户虚拟网络)和方法（来自F5 网络的Christian Koenning所说的软件定义网络和OpenStack）。有了SDN的集成，Neutron极有可能去支持大容量、高密度和多租户云环境的动态特性。

OpenStack Neutron连同它的插件架构，提供集成SDN控制器到OpenStack的能力。这种SDN控制器使用插件集成Neutron技术提供集中式管理，并且促进OpenStack网络利用API实现可编程性。

SDN控制器，诸如OpenDaylight、Ryu和Floodlight，运用对应的机制驱动，使用指定的插件或者使用ML2插件，实现Neutron和SDN控制器之间的通信。OpenStack与SDN控制器的融合，如下图三所示。

在关于SDN控制器的文章里，网络操作系统如Open Daylight、RYU，或者其他网络操作系统，负责提供一个完整的网络(拓扑)视图，也负责管理（应用、实行和保证）对网络必要的更新，通过转换需求去配置（和监控）网络元素（物理的和虚拟的）。典型地，这些对下层网络（和网络元素）的更新来自运行于SDN控制器上的网络应用，SDN控制器通过北向API调用。

随着OpenStack Neutron和SDN控制器的集成，对于网络和网络节点的改变也由OpenStack用户所触发，被转换成Neutron API，由Neutron插件和对应的SDN控制器上的代理来处理。例如，OpenDaylight通过Neutron网络节点上的ML2插件使用北向通信的RestAPI与Neutron交互。当一个OpenStack用户执行任何与网络有关的操作时（创建/更新/删除/阅读 关于网络、子网和端口资源），典型流程如下：

1. 在OpenStack面板(Horizon)的用户操作将会被转换成对应的网络API，并且发往Neutron服务器。

2. Neutron服务器收到请求，然后传递请求给配置好的插件（假设ML2配置了一个ODL机制驱动和一个VXLAN类型驱动）。

3. Neutron服务器/插件将会对DB做相应的改变。

4. 插件将从SDN控制器(假设是一个ODL)调用对应的RestAPI。

5. ODL，一旦收到请求，将使用任意的南向插件/协议，例如OpenFlow，OVSDB或者OF-Config，对网络节点执行必要的改变。

图三：OpenStack和SDN控制器

在SDN控制器和OpenStack之间仍然存在不同的集成选项，例如，a)SDN控制器作为唯一的控制实体管理网络，能完全消除计算节点上Neutron服务器与代理之间的RPC通信，或者 b)SDN控制器仅仅管理物理交换机，虚拟交换机由Neutron服务器直接管理。

引人深思的是：SDN控制器部署选项与OpenStack的集成

SDN控制器部署可以采取不同的形式，如下面三个表格的总结，部署不同排列组合的下列选项是有可能的，例如，我们可以让非虚拟化的、集成的、单一/冗余的控制器在一个数据中心管理数据中心所有的网络节点。

表1

选项	描述
非虚拟化	运行于单个系统上的完整控制器实例（一个物理机器）
虚拟化	控制器实例运行于虚拟环境（作为虚拟机）

表2

选项	描述
集成式	所有的SDN控制器功能运行在一个单个实例上
分布式	SDN控制器功能是分布式的

表3

选项	描述
单个/冗余	网络中单个（或者有冗余）控制器
层次化	一系列的控制器，可能存在客户机/服务器关系

SDN控制器虚拟化的好处是，更好的可扩展性——在现有的SDN控制器动态添加更多的资源（比如存储资源）。在一个虚拟化分布式部署中——SDN控制器由一系列协同工作的虚拟机实现-可以添加额外的虚拟机实例来增加工作负载。

考虑到SDN控制器被虚拟化和集成化/分布式的场景，SDN网络元素从虚拟到物理实体的变化。此外，数据中心环境下虚拟设施的管理应该适应目前VIM（虚拟化基础设施管理员）如OpenStack的编配模型。为了达到这一点，我们面对克服各种各样的挑战，诸如性能和动态服务管理。并鼓励读者思考在这种场景下创建端到端的解决方案的不同选项。

谢谢搂住，学习了