转载

SDN对OpenStack Neutron的横向扩展影响

将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服务器、数据库和代理进行联系。

SDN对OpenStack 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层网络技术。”

SDN对OpenStack Neutron的横向扩展影响

图二：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。

正文到此结束