将Neutron索性看作是一种软件定义网络(SDN)应用大有帮助。更具体地说，它可以管理在OpenStack上运行的网络虚拟化，并创建一系列松散耦合的相关项目，用于开发高级云服务。这些服务每个还都是独立项目，受社区和许多捐献代码的厂商和公司的共同驱动。重要的是，OpenStack Kilo版本共有12个集成的项目。
1. Nova(计算)：为云用户按需提供虚拟服务器/虚拟机。
2. Neutron(网络)：将网络作为一项服务来提供(虚拟网络服务)。
3. Swift(对象存储)：允许存储并检索可通过API来访问的数据映像、文件和文档。
4. Cinder(块存储)：为用户虚拟机提供永久块存储。
5. Glance(映像)：为虚拟机使用的计算节点提供一系列虚拟磁盘映像。
6. Horizon(仪表板)：提供基于Web的图形化用户界面(GUI)，以便管理员或租户(用户)管理Openstack。
7. Keystone(身份)：存储用于为OpenStack提供验证和授权机制的信息。
8. Ceilometer(遥测)：监控和测量Openstack云使用情况，用于计费、基准测试和统计。
9. Heat(编排)：通过使用合适的API调用，提供用于管理云应用程序的编排服务。
10. Ironic(裸机配置)：旨在配置裸机而不是虚拟机，从Nova Baremetal驱动(driver)派生而来。
11. Sahara(大数据即服务):该项目提供了一种简单的方法，可以在OpenStack上配置数据密集型的应用集群(Hadoop或Spark)。
12. Trove(数据库即服务)：该项目旨在为关系数据库引擎和非关系数据库引擎提供云数据库即服务配置功能。
虚拟网络由租户或管理员构建，提供了OpenStack计算所管理的虚拟机之间的联网功能。Neutron是一项网络管理服务，提供了一组可扩展的API于构建和管理虚拟网络。
在Neutron之前，OpenStack有一种简单的扁平网络环境，不支持第3层或者防火墙。它包括在Nova服务器里面，因而很难适应网络方面出现的变化。
当初之所以引入Neutron，是为了将网络当作一项单独服务，并为抽象提供不同的实施方案――Neutron服务器提供抽象定义和管理，而抽象的具体实施由插件来实现。这种基于插件的多租户支持框架可以说与与技术无关、具有模块化特性。我们需要注意的是，Neutron是一项独立式服务――也就是说，它可以作为一项自主服务来运行，暴露不同厂商的API，提供实施和任何合适的扩展。
下面总结了API类别以及每个子类下面的支持操作。这些操作可以缩写为CRUD，即创建、读取、更新和删除。核心API涵盖了基本而必要的网络操作，而扩展和属性API涵盖了功能丰富的虚拟网络的必要操作。
核心API的操作
•网络(CRUD)
•子网(CRUD)
•端口(CRUD)
扩展件和属性API的操作
•配额(RUD)
•网络提供商扩展属性(CRUD)
•多个网络提供商扩展(CR)
•端口绑定扩展属性(CRU)
•安全组和规则(CRD)
•第3层网络(CRUD)
•计量标签和规则(CRD)
•负载均衡即服务(LBaaS)(CRUD)
Neutron架构
下图描述了OpenStack Neutron架构，该架构包括下列部分：
Neutron服务器
Python守护进程是OpenStack网络的主要进程，通常在控制器节点(OpenStack部署中所用的一个术语)上运行。它暴露API，以执行网络模型，并将请求传递给netron组件。
插件
插件可能是核心插件，也可能是服务插件。核心插件实施“核心”的Neutron API――第2层网络和IP地址管理。服务插件提供“额外”的服务，例如第3层路由、负载均衡、VPN、防火墙和计量。这些网络服务还可以由核心插件通过实现相关的API扩展来提供。简而言之，插件在控制器节点上运行，并实施网络API，这些API可与Neutron服务器、数据库和代理进行联系。
图一：OpenStack Neutron 架构
插件代理
这种代理是使用的Neutron插件所特有的。它们在计算节点上运行，并与Neutron插件进行联系，以管理虚拟交换机。这种代理在许多部署环境中是可选的，在每个虚拟机管理程序上执行本地虚拟交换机配置。
消息队列
OpenStack组件(包括Neutron)使用高级消息队列协议(AMQP)进行内部通信。AMQP代理者RabbitMQ位于Neutron的任何两个内部组件之间，允许它们以松散耦合的方式进行联系，也就是Neutron组件使用远程过程调用(RPC)与另一个组件进行通信。
数据库
几乎所有插件都需要数据库来维护持久网络模型;因此，数据库模式由已配置的核心插件和服务插件来定义。
DHCP代理
这种代理是Neutron的一部分，为租户网络提供了DHCP服务。它维护所需的DHCP配置，对所有插件而言都一样。
第3层代理
这种代理负责提供第3层和NAT转发功能，以便租户网络上的虚拟机获得外部访问权。
模块化第2层核心插件
模块化第2层(ML2)是Neutron的核心插件。ML2在OpenStack的Havana版本中引入，旨在取代原有的整块式插件(比如Open vSwitch和Linux Bridge――这些只是插件，而不是代理!)，从而消除冗余代码，减少开发和维护工作量。按照ML2作者的定义，“模块化第2层(ML2)插件是一种框架，允许OpenStack Neutron同时利用复杂的实际数据中心中出现的各种第2层网络技术。”
图二：ML2 插件结构
ML2通过驱动模型(driver model)来实现模块化。如图所示，它包括两类驱动：类型和机制。类型驱动(比如flat、虚拟局域网、GRE和VXLAN)定义了特定的第2层类型，其中每个可用网络类型由相应的类型驱动管理。该驱动维护针对特定类型的状态信息，并实现了租户网络之间的隔离，另外还能验证提供商网络。
另一方面，机制驱动支持网络、子网和端口等资源的创建、更新和删除，这种驱动是厂商指定的(比如OVS以及来自ODL、思科和NEC等厂商的驱动)，基于启用的类型驱动。我们应该注意到一点，厂商可能实施一种类似ML2的全新插件，或者干脆实施机制驱动。Salvatore Orlando和Armando Miliaccio的一番谈话可能帮助我们更容易做出这个决定：https://www.openstack.org/summit/openstack-summit-hong-kong-2013/session-videos/presentation/how-to-write-a-neutron-plugin-if-you-really-need-to。
#p#
OpenStack和SDN控制器的全局
软件定义网络的引入不仅是为了克服Neutron的不足，还为了支持多种网络虚拟化技术(集中式控制平面构建隔离的租户虚拟网络)和方法。由于在SDN上集成，Neutron有望支持大规模、高密度的多租户云环境具有的动态性。
OpenStack Neutron及其插件架构提供了将SDN控制器集成到OpenStack的功能。使用插件将SDN控制器集成到Neutron的这种做法提供了集中式管理，还为使用API对OpenStack网络实现网络可编程性提供了方便。
OpenDaylight、Ryu和Floodlight等SDN控制器使用特定的插件或拥有相应机制驱动的ML2插件，允许Neutron和SDN控制器之间进行通信。下图显示的全局表明了OpenStack与SDN控制器集成。
我们在介绍SDN控制器的文章中发现，Open Daylight、RYU及其他网络操作系统负责提供网络的完整视图(拓扑结构)及其当前的一致状态。我们还发现，控制器还通过将需求转变成配置(及监控)网络元素(物理元素和虚拟元素)，负责“管理”(运用、执行和确保)必要的网络变化。底层网络(及网络元素)的这些变化通常来自在SDN控制器上运行的网络应用，使用北向API(northbound API)。
由于OpenStack Neutron和SDN控制器的这种集成，还可以从OpenStack用户触发网络及网络元素的变化，这些变化可以转换成Neutron API，并由Neutron插件和SDN控制器中运行的相应代理来处理。比如说，OpenDaylight与Neutron进行通信所采取的方式是，采用Neutron网络节点上的ML2插件，并经由使用北向通信的REST API。如果OpenStack用户执行任何网络相关操作(创建/更新/删除/读取网络网络、子网和端口等资源)，典型流程将如下所示：
1. OpenStack仪表板(Horizon)上的用户操作将被转换成相应的网络API，并发送到Neutron服务器。
2. Neutron服务器收到请求后，将同一请求传递给已配置的插件(假设ML2已配置好了ODL机制驱动和VXLAN类型驱动)。
3. Neutron服务器/插件会对数据库做适应的变动。
4. 插件会调用与SDN控制器对应的REST API。
5. 一收到请求，ODL会使用任何南向插件/协议，比如OpenFlow、OVSDB或OF-Config，对网络元素做必要的变化。
图三：OpenStack和SDN控制器的全局
值得注意的是，SDN控制器和OpenStack方面存在不同的集成选项;比如说，a)可以完全消除Neutron服务器与计算节点上的代理之间的RPC通信，SDN控制器作为管理网络的唯一实体;或者 b)SDN控制器只由物理交换机管理，虚拟交换机可以从Neutron服务器直接管理。
SDN控制器部署选项和OpenStack集成
最后我们谈谈SDN面临的诸多挑战之一。
部署的SDN控制器可能具有不同的形式，如下面三张表格总结的那样。可以采用下列不同组合的选项来加以部署。比如说，我们在数据中心中可能有非虚拟化、集成的单一/冗余控制器，管理数据中心的所有网络元素。
|
选项 |
描述 |
|
非虚拟化 |
整个控制器实例在单一系统（物理机）上运行 |
|
虚拟化 |
控制器实例在虚拟化环境（虚拟机）中运行 |
|
选项 |
描述 |
|
集成式 |
所有SDN控制器功能在单一实例下运行 |
|
分布式 |
SDN控制器功能呈分布式 |
|
选项 |
描述 |
|
单一/冗余 |
面向网络的单一（或冗余）控制器 |
|
层次化 |
采用层次结构的控制器，而控制器之间可能有 |
SDN控制器虚拟化的好处包括，能够更有效地向上扩展和向外扩展――为现有的SDN控制器动态添加更多的资源(比如存储资源)。在虚拟化分布式部署环境中――SDN控制器被实施成一组协同工作的虚拟机，面对增加的工作负载，可以添加额外的虚拟机实例。
设想这种场景：SDN控制器呈虚拟化和集成化/分布式，SDN网络元素包括虚拟元素和物理元素。此外，管理数据中心环境下的这些虚拟基础设施应该适合现有的编排模型――与OpenStack等当前的VIM(虚拟化基础设施管理器)集成起来。为了做到这一点，我们必须面对克服种种挑战，比如性能和动态服务管理。鼓励读者认真考虑在这种场景下构建端到端解决方案的不同选项。
