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组件。

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

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

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

作者简介：

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)

原始链接：http://www.sdnlab.com/11926.html