【openstack】openstack中的消息队列

openstack中的消息队列

更新记录:
2013.4.28  增加版本号

版本:Essex版

1      openstack中消息队列的使用

nova中的每个组件都会连接消息服务器,一个组件可能是一个消息发送者(如API、Scheduler),也可能是一个消息接收者(如compute、volume、network)。发送消息有两种方式:同步调用rpc.call和异步调用rpc.cast

openstack内部一些对象:

l  Topic Publisher:该对象在进行rpc.call或rpc.cast时创建,每个对象都会连接同一个topic类型的交换器,消息发送完毕后对象被回收。

l  Direct Publisher:该对象在进行rpc.call调用时创建,用于向消息发送者返回响应。该对象会根据接收到的消息属性连接一个direct类型的交换器。

l  Direct Consumer:该对象在进行rpc.call调用时创建,用于接收响应消息。每一个对象都会通过一个的队列连接一个direct类型的交换器(队列和交换器以UUID命名)。

l  Topic Consumer:该对象在内部服务初始化时创建,在服务过程中一直存在。用于从队列中接收消息,调用消息属性中指定的函数。该对象通过一个共享队列或一个私有队列连接一个topic类型的交换器。每一个内部服务都有两个topic consumer,一个用于rpc.cast调用(此时连接的是binding-key为“topic”的共享队列);另一个用于rpc.call调用(此时连接的是binding-key为“topic.host”的私有队列)

l  Topic Exchange:topic类型交换器,每一个消息代理节点只有一个topic类型的交换器。

l  Direct Exchange:direct类型的交换器,存在于rpc.call调用过程中,对于每一个rpc.call的调用,都会产生该对象的一个实例。

l  Queue Element:消息队列。可以共享也可以私有。routing-key为“topic”的队列会在相同类型的服务中共享(如多个compute节点共享一个routing-key为“topic”的队列)。

 

各个对象的工作模型:

  

       openstack中默认使用kombu(实现AMQP协议的Python函数库)连接RabbitMQ服务器。消息的收/发者都需要一个Connetion对象连接RabbitMQ服务器。

2      消息队列性能影响因素

消息队列在openstack整个架构中扮演着至关重要(交通枢纽)的作用,正是因为openstack部署的灵活性、模块的松耦合、架构的扁平化,反而使openstack更加依赖于消息队列(不一定使用RabbitMQ,可以是其他的消息队列产品),所以消息队列收发消息的性能和消息队列的HA能力直接影响openstack的性能。

在openstack中的任意时间点,影响消息服务器性能的的因素如下:

l  在rpc.call调用过程中:rpc.call的调用数决定了direct类型的交换器个数,相关的私有队列个数以及监听私有队列的direct consumer的个数。

l  工作者线程(内部服务)个数:相同属性的工作者线程(如compute节点)会共享一个队列,但每一个工作者线程都有一个私有队列。相同属性的工作者线程个数也决定了在topic类型交换器上的routing key的个数。

 

在实验环境下,主机名为kong,openstack各个组件启动后,会创建:

Ø  Exchanges

1.      nova (topic exchange)

Ø  Queues

1.      compute.kong

2.      compute

3.      network.kong

4.      network

5.      volume.kong

6.      volume

7.      scheduler.kong

8.      scheduler

 

使用消息队列时有如下几个(Consumer类)属性:

Ø  Durable:该属性决定了交换器和队列是否持久化,如持久化,则交换器和队列在RabbitMQ服务重启后仍然继续工作,否则交换器和队列的信息被清空。AMQP协议规定,持久化的队列只能绑定到持久化的交换器。

Ø  Auto_delete:如果设置,则当所有队列结束后,交换器自动删除。默认为False。

Ø  Exclusive:队列是否私有,如果该属性设置,则Auto_delete属性会自动生效。默认为False。

Ø  Auto_ack:收到消息时是否自动发送回执。默认是False,要求消息接收者手动处理回执。

Ø  No_ack:如果设置会提高性能,但会降低可靠性。

Ø  Delivery_mode:消息的传输类型。目前RabbitMQ支持两种类型:

n  1或者“transient”:消息存储在内存,当服务器宕机或重启时消息丢失

n  2或者“persistent”:消息会同时在内存和硬盘保存,服务器宕机或重启时消息不丢失

默认为2。

 

在大规模部署的情况下,势必会对单节点的RabbitMQ server造成较大的负载,一旦发生单节点故障,整个openstack服务都会瘫痪。所以,部署时可以考虑使用RabbitMQ的HA等高级部署特性,具体参见RabbitMQ相关文档,在此不再赘述。

3      代码验证

3.1      服务的启动

根据以上分析可知,nova组件服务启动时会创建TopicConsumer,以“nova-compute”服务启动为例,在服务的启动过程中,会调用service::start()方法,在该方法中:

 

            3.1.1    conn是什么?

是nova.openstack.common.amqp.ConnectionContext对象,这个对象是由RPC实现类调用create_connection()方法创建。RPC在openstack中有四种实现:

   具体使用哪一种根据配置文件确定,默认的配置项是:

rpc_backend=nova.rpc.impl_kombu

ConnectionContext对象包含两个字段:

ü  connection_pool:一个Connection对象池(继承自eventlet.pools.Pool),用于生成Connection对象。

ü  connection:由connection_pool 生成。nova.openstack.common.rpc.impl_komku.Connection对象。该对象在初始化时,会根据配置的参数和策略连接RabbitMQ服务器。

3.1.2     rpc_dispatcher是什么?

RpcDispatcher对象。该对象中有属性callbacks,是一个包含ComputeManager对象的列表。用于接收到消息之后的处理。

3.1.3     三个create_consumer方法干了什么?

以第一个为例,在该函数中,创建了TopicConsumer对象。

 

3.1.4     consume_in_thread方法

在方法的实现里,又借助了evlentlet库创建超线程。在超线程主函数中调用了TopicConsumer对象的consume()方法(该类没有实现该方法,直接调用父类)。

 对消息的处理包括:从消息中获取接口名称、获取接口参数、调用ComputeManager对象相应方法。

至此,“nova-compute”服务启动完成。

3.2      消息的发送

以创建虚拟机为例,由前几篇文章可知,经过Scheduler模块的过滤后,将创建虚拟机消息发送到对应的compute节点。

  
 cast_to_compute_host
方法的实现:


 rpc.cast最终会创建一个TopicPublisher对象,并调用该对象的send方法。


 由上可知,
TopicConsumer对象会向名为“nova”的exchange上, 以 “compute.host”为routing-key发送消息。此时消息会发送到在名为“compute.host”队列上监听的TopicConsumer对象。

展开阅读全文

没有更多推荐了,返回首页