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的编配模型。为了达到这一点，我们面对克服各种各样的挑战，诸如性能和动态服务管理。并鼓励读者思考在这种场景下创建端到端的解决方案的不同选项。
原文链接：http://thenewstack.io/sdn-controllers-and-openstack-part1/
作者简介：
Sridhar，2007年新加坡国立大学取得计算机科学博士学位，2000年印度苏拉卡KREC大学获得计算机科学硕士学位，1997年印度杜姆吉尔的班加罗尔大学SIT取得仪器与电子本科学位。曾在印度SRM研究院从事研发组长；在新加坡信息通信研发中心（I2R）任职研发员。他曾工作于各种部署方案和部署项目包括ZigBee、WiFi和WiMax。Sridhar目前是NEC印度技术有限公司的技术专家，研发方向主要是下一代有线和无线网络领域，诸如OpenFlow、软件定义网络、软件定义无线系统为认知网络、HotSpot 2.0和物联网。
译者简介：
黄雅楠（huangyanan_2006@126.com），爱立信上海研发中心，主要专攻电信核心网、IP多媒体子系统(IMS)以及基于LTE的语音传输(VoLTE)