一种基于OpenStack控制平面的虚拟网络性能的优化方法与流程

本发明涉及云网络中虚拟网络性能领域，特别涉及一种基于openstack控制平面的虚拟网络性能的优化方法。

背景技术：

近年来，在技术发展、市场需求、商业模式转变的驱动下云计算迅猛发展，它将分散的网络、计算、存储资源整合在一起，结合虚拟化技术，以资源租用的方式创建虚拟网络向租户提供虚拟资源和服务。相比于传统依赖物理服务器搭建的网络环境，云环境成本较低、可扩展性高、管理便捷高效、资源利用率高、迁移容灾备份方案完善，可以实现智能资源调度和统一灵活的管理，厂商也能基于云环境实现更加安全、可靠、个性化的的解决方案。

随着云计算的发展，涌现了很多云平台，其中，openstack是一个遵循apache2.0协议的开源云平台，被大量的厂商广泛应用，用于构建实施简单、标准统一、可大规模扩展的云环境，该平台提供了一个用于管理基础设施中计算、存储、网络等资源的框架，可以为用户提供租户隔离的网络隔离的网络环境。openstack由包括计算服务、对象存储、镜像服务、身份服务、网络服务、部署编排、数据库服务在内的核心项目及负载均衡、消息队列在内的14个社区项目组成。在openstack中，网络组件neutron是核心组件之一，它提供了网络服务；在openstack发展初期，虚拟网络服务的相关功能由nova-network项目提供，它提供了简单的网络拓扑和二层网络服务；在openstack迅速发展的过程中，社区为网络服务单独孵化了quantum项目以解决nova-network项目无法满足云计算环境对网络更加高级复杂的需求的问题，而后quantum项目改名为neutron，目前neutron提供了从二层到七层的基于北向编程接口和可拔插式的插件架构的虚拟网络；openstack一直在其不断更新的轨迹中对neutron组件进行优化，为云计算环境提供更完善的网络服务和更高的网络性能，为openstack项目的服务运作提供坚实的网络基础。

现有技术公开了在openstack环境中通常存在一个控制节点、一个网络节点和多个计算节点；网络节点和控制节点作为所有节点的网络中枢，控制着整个云环境的流量方向，计算节点则为租户提供虚拟机资源及相关服务。neutron组件的实现中主要包括neutronserver和neutronagent两个部分；neutronserver是运行在控制节点上的python守护进程，它实现了网络数据模型的抽象，负责接收请求并与数据库进行交互；neutronagent实现网络的具体功能，部署于计算节点或网络节点中；neutronserver与neutronagent通过消息队列交互，neutronplugins负责在传递请求，在neutron网络架构中，消息队列作为网络通信中枢，承担了组件间的通信任务。

openstack使用消息队列进行组件间的通信和服务状态的协调，openstack支持rabbitmq、zeromq等多种消息队列，rabbitmq由大多数发行版本支持，也是openstack中广泛使用的消息队列。rabbitmq的实现是基于amqp(advancedmessagequeuingprotocol)通信协议模型，以降低组件内部的耦合；amqp是面向消息中间件的用于异步消息通讯的协议标准，在amqp协议模型中，存在四个角色：(1)路由关键词，交换机用路由关键词判断哪些消息需要发送到对应的消息队列；(2)交换机，根据路由关键词转发消息到对应的队列，具体又分为点对点消息模式(directexchange)、发布-订阅模式(topicexchange)、广播消息模式(fanoutexchange)三种，点对点消息模式是根据路由关键词进行精确匹配；发布-订阅模式是根据路由关键词进行模式匹配，符合匹配规则的消息队列都会收到消息；而在广播消息模式中，所有与之绑定的队列都会收到消息；(3)消息发送者，在生产者-消费者模式中充当消息生产者的角色，发送消息时需指定路由关键词；(4)消息接收者，充当消息消费者的角色，从队列中消费信息；zeromq是独立于amqp协议的面向网络编程的异步消息库，可以在线程间、进程间等多种协议中传输消息，完成异步消息的处理任务；与基于中间代理的rabbitmq不同，zeromq是去中心化的轻量级通讯库，具有更灵活的功能和更高性能。

neutron虚拟二层网络通过广播通信，为限制广播域出现了vlan和vxlan，但在云计算的大规模网络中，vxlan节点数量庞大，广播风暴问题仍然难以避免，影响了网络的可扩展性。在此背景下，neutronl2population机制的出现避免了云环境下的广播风暴问题。启用l2population后，neutron数据库记录ip地址到mac地址的映射，当有记录更新时，通过消息队列的方式将更新记录通过调用rpc发布给网络中所有节点的代理。

l2population机制通过在vtep(vxlantunnelendpoint)提供本地转发表功能，即vtep可以获得网络中ip与mac地址的映射关系及vm与vtep的映射关系，其实现原理是：neutron数据库中保存了每个端口的信息，包括ip地址、mac地址；虚拟机启动时，虚拟机端口状态经历从关闭到构建到活跃的三个状态；当某个端口状态变更时，虚拟机所在计算节点的l2代理会扫描此端口的状态变更并通过rabbitmq以rpc方式更新端口状态，neutronserver收到消息后通知l2population驱动，l2population驱动通过rabbitmq的l2-fanout-agent将信息扇出给所有计算节点的l2代理，因此l2代理可以更新本地转发表。

虚拟机的端口状态变化被l2代理扫描到并通过rabbitmq上报update_port_status信息，l2pop驱动把fdb_entries消息扇出给所有计算节点的l2代理，在网络规模略大时，rabbitmq需要承载并处理大量的扇出消息；rpc消息过多会造成消息堆积，严重情况下，过多的rpc消息导致的rpc消息风暴甚至让消息队列崩溃，消息队列成为虚拟网络通信的性能瓶颈，严重影响openstack环境的性能和可扩展性；二层通信开启l2population机制后，虽然缓解了广播风暴，但rpc消息的发布依赖消息队列，给消息队列带来了巨大的压力；当网络规模增大时消息队列成为虚拟网络的性能瓶颈，严重影响网络性能和可扩展性。

基于现有技术的现状，本申请的发明人拟提供一种基于openstack控制平面的虚拟网络性能的优化方法

技术实现要素：

本发明的目的在于克服现有openstack环境中控制平面rpc发送机制的缺陷和不足，提供一种基于openstack控制平面的虚拟网络性能的优化方法，尤其涉及一种rpc的发送机制和消息队列的有效方法，本发明方法将提高虚拟网络中消息队列侧的吞吐率，减少rpc的消息发送时延，缓解虚拟网络通信在消息队列上的性能瓶颈。

为了解决上述技术问题，本发明提供了一种基于openstack控制平面的虚拟网络性能的优化方法，该方法包括：从消息产生者的角度改进rpc的发送机制，将rpc消息只发往同一子网下的l2代理，减少了rpc发送数量；从消息处理者的角度采用混合式消息队列方式，可以利用rabbitmq持久化、高可用的特性来保证通知类消息的持久化需求，还可利用zeromq快速、低延迟的特性，以直接通信的模式快速处理大量的rpc消息，减少rpc消息堆积。本方法能在不影响原有网络功能的前提下，将rpc消息独立出来使用zeromq处理，不经过中间代理，发布更快速，从两个角度提高租户网络通信性能，进而提高虚拟网络的性能。

具体的，本发明提出了在openstack环境中一种rpc发送机制的优化和混合式消息队列方法，所述方法包括：

优化现有架构中利用rabbitmq通信的rpc消息发送机制；当网络中虚拟机的端口状态更新时，不将相关消息通知发送给所有计算节点，只将fdb_entries消息发送给同一子网下的l2代理，避免不同子网的l2代理收到无用消息，从而减少rpc消息的发送数量；

采用混合式消息队列，实现更高性能的消息传递；针对openstack环境中的虚拟网络的消息类型及其特性，对不同的消息类型用不同的消息队列处理，其中，rpc消息使用zeromq处理，notification类消息使用基于amqp的rabbitmq处理，使rpc消息以快速、低延迟的方式传递，同时又保证通知消息的持久化需求，以发挥消息队列的最大性能；

rpc消息发送机制优化的处理逻辑如下，将消息队列的主题增加与网络uuid绑定，主题中包含的内容为特定uuid所代表的子网下端口更新的l2population消息；对于消息发布者而言，通过判断端口状态变化的虚拟机所属子网的uuid来决定消息转发到哪一个主题；对于消息订阅者而言，只订阅其所属子网对应的uuid下l2pop_update主题；由此保证当某个虚拟机端口状态发生变化时，消息队列只会将rpc消息推送至属于同一子网下的l2代理，从而减少rpc消息的发送数量，缓解消息队列侧的压力；

本发明中，openstack中消息类型分为notification类消息和rpc消息；通知类消息用于通知用户，rpc消息用于实现组件间的异步消息通讯；从消息特征上看，通知类消息属于持久化消息，只有当处理结果满足某种状态时才会返回，而rpc消息属于瞬时消息，需要立即返回，与通知类消息相比，rpc消息最大的特性是需要低延迟且无需持久化支持；

本发明中，混合式消息队列结构的处理逻辑如下，针对neutron项目中使用到的rpc和通知类消息两种消息类型，在oslo.messaging层进行抽象，底层使用两种类型的消息驱动，其中，rpc消息使用directmessaging(直接通信)处理，通知类消息使用使用基于broker的消息队列处理，在直接通信模式中使用zeromq，而在基于broker的消息队列的通信模式中使用rabbitmq，因此，rpc消息全部由zeromq承载，通知类消息仍由rabbitmq承载。

更具体的，本发明的基于openstack控制平面的虚拟网络性能的优化方法，其包括：

在消息传输方式中，从消息生产者角度对rpc消息发送机制进行优化，将其只发送到处于同一子网下的l2代理，从而减少rpc发送数量；

从消息处理者角度，根据消息的特性使用混合式的底层驱动，rpc消息使用directmessaging(直接通信)处理，以获得高吞吐和低延迟，notification消息使用基于broker的消息队列处理，以保证消息持久性。

本发明中，所述rpc消息发送机制优化方法，其包括：

将消息队列的主题增加与网络uuid绑定，主题中包含的内容为特定uuid所代表的子网下端口更新的l2pop消息；

对于消息发布者而言，通过判断端口状态变化的虚拟机所属子网的uuid决定消息转发到哪一个主题；对于消息订阅者而言，只会订阅其所属子网对应的uuid下l2pop_update主题，由此保证当某个虚拟机端口状态发生变化时，消息队列只会将rpc消息推送至属于同一子网下的l2代理，因而可以减少rpc消息的发送数量；

本发明中，所述根据消息的特性使用混合式的底层驱动，其包括：

openstack中消息类型分为notification消息(通知类消息)和rpc消息两种，针对neutron项目中使用到的rpc和通知类消息两种消息类型，在oslo.messaging层进行抽象，底层使用两种类型的消息驱动，与neutron原生消息机制方案对比，本发明将rpc消息的处理由基于broker的通信模式切换到直接通信模式，而通知类消息仍由基于broker的通信模式承载；

本发明中，所述rpc消息发送方法优化后的发送流程，其包括：

在openstack网络初始化阶段，收集l2代理上报的网络信息，根据neutronserver维护的网络信息，为所有vxlan网络分配相应的uuid，在neutronserver中维护vni->uuid的映射；

对于每个uuid，都为之创建update，add，remove三种主题交换器，之后，当虚拟机端口状态变更时，l2代理上报此信息给neutronserver，neutronserver根据其此信息获取虚拟机所属vxlan网络对应的uuid，判断此uuid是否存在于已有的映射中，若无，则为此子网创建l2pop主题交换器，然后将此信息发布到与此uuid绑定的update主题中；若已存在于现有映射表，则跳过创建环节，直接将消息发布到update主题；

本发明中，所述消息队列改进方案中的消息传输模块，其包括：

消息队列的改进方案中消息传输模块具体可分为rpc消息传输模块和notification消息传输模块，由于两个模块的区别主要在于驱动加载阶段，其余流程类似，本申请中以rpc消息传输模块为例进行介绍：首先对配置中的rpc消息传输服务的url进行合法性检查，若合法，则根据配置中指定的服务进行驱动加载，rpc消息发送和监听方法的实现是直接调用底层驱动的发送和监听方法。

与neutron原生消息机制方案对比，本发明将rpc消息的处理由基于broker的通信模式切换到直接通信模式。

本发明的技术效果在于：本方法从消息产生者的角度改进rpc的发送机制，将rpc消息只发往同一子网下的l2代理，减少了rpc发送数量；本方法从消息处理者的角度采用混合式消息队列方式，一方面可以利用rabbitmq持久化、高可用的特性来保证通知类消息的持久化需求，另一方面可利用zeromq快速、低延迟的特性，以直接通信的模式快速处理大量的rpc消息，减少rpc消息堆积，在不影响原有网络功能的前提下，将rpc消息独立出来使用zeromq处理，不经过中间代理，发布更快速，从两个角度提高租户网络通信性能，进而提高虚拟网络的性能。

下面结合附图和具体实施例对本发明做进一步的说明。

附图说明

为了更加清楚的理解本发明的处理流程和优点，下面将对本发明中所使用的附图作简单的介绍，附图是示意性的而不应理解为对本发明进行任何限制，在附图中：

图1示出了本发明基于openstack控制平面在rpc消息发送机制优化形成新的rpc消息发送流程示意图；

图2示出了本发明中基于openstackneutron组件的混合式消息队列新架构示意图；

图3示出了本发明中基于直接通信模式的rpc通信的流程示意图；

图4示出了本发明从两方面优化的消息交互过程示意图。

具体实施方式

实施例1

如图1所示，本发明在rpc消息发送机制上，将消息队列的主题增加与网络uuid绑定，newtopic＝topic+uuid，主题中包含的内容为特定uuid所代表的子网下端口更新的l2population消息；对于消息发布者而言，通过判断端口状态变化的虚拟机所属子网的uuid来决定消息转发到哪一个主题；对于消息订阅者而言，只订阅其所属子网对应的uuid下l2pop_update主题，由此保证当某个虚拟机端口状态发生变化时，消息队列只会将rpc消息推送至属于同一子网下的l2代理，从而减少rpc消息的发送数量，缓解消息队列侧的压力；

本实施例中，以vxlan组网模式为例，工作流程包括：

首先在openstack网络初始化阶段，收集l2代理上报的网络信息；

根据neutronserver维护的网络信息，为所有vxlan网络分配相应的uuid，即在neutronserver中维护vni->uuid的映射；

对于每个uuid，都为之创建update，add，remove三种主题交换器；

当虚拟机端口状态变更时，l2代理上报此信息给neutronserver；

neutronserver根据其此信息获取虚拟机所属vxlan网络对应的uuid，判断此uuid是否存在于已有的映射中：

若无，则为此子网创建l2pop主题交换器，然后将此信息发布到与此uuid绑定的update主题中；

若已存在于现有映射表，则跳过创建环节，直接将消息发布到update主题。

如图2所示，本方法在消息队列的改进方案中消息传输模块具体可分为rpc消息传输模块和notification消息传输模块；

以rpc消息传输模块为例：

在rpc消息传输模块中，首先对配置中的rpc服务的url进行合法性检查：

若合法，则根据配置中指定的服务(zeromq)进行驱动加载；

如图3所示，rpc消息发送和监听方法，其实现是直接调用底层驱动的发送和监听方法；

在消息发送方法中，需要指定消息发送目标、上下文环境、rpc消息结构、超时时间、超时重试次数等参数；

在消息监听方法中，同样要指定消息发送目标和超时时间；

由于监听时为了保证消息处理速率而进行批处理，因此需要指定每次批处理消息的消息条数。

优化后的方案的消息发送过程如图4所示，显示了rpc消息只会发往同一子网下的l2代理，减少了rpc发送数量，且rpc消息不经过中间代理，发布更快速。