OpenStack RabbitMQ集群

OpenStack有非常良好的结构设计，各模块之间相互独立，通过API和消息队列来传递信息，这种结构能够很方便的实现规模和功能的扩展，这是云计算平台功能设计的基本出发点。

消息队列是OpenStack体系结构重要的组成部分，承载了各模块之间通信的重要功能，OpenStack默认选用的消息队列是基于erlang的RabbitMQ，RabbitMQ实现了AMQP协议，提供消息的持久化存储，支持镜像队列(Mirrored Queue)等特性。本文介绍如何利用RabbitMQ镜像队列模式以及HAProxy搭建高可用消息队列集群。

为什么需要RabbitMQ集群？

对于典型的私有云部署规模：50台物理服务器，500台虚机。消息队列的主要负载来自于OpenStack各模块之间传递的信息，负载不算很大，因此单节点的RabbitMQ即可以搞定。而G版本发布之后，OpenStack引入了Ceilometer模块来负责提供云平台的监控功能，此模块使用消息队列进行监控数据的传递，下图展示了消息队列Ceilometer中的位置。

在Ceilometer模块中，Compute Agent负责采集虚拟机实例的监控信息(Sample)，经过转换(Transform)之后发布(Publish)到消息队列，Central Agent负责将服务相关的信息包装、转换并发布到消息队列，扮演了生产者的角色。而在消息队列的另一侧，作为消费者的Collector负责将相关监控信息以及各服务的通知信息(Notification)收集起来并持久化存储在数据库中。

由于业务需要，我们对Ceilometer模块做了功能扩展，将物理服务器运行的监控信息以及底层共享存储(GlusterFS)产生的监控信息也一并通过Compute Agent发布到消息总线上。为了达到细粒度的监控效果，我们将ceilometer监控的轮询间隔时间设置为10秒。假设在刚刚列举的典型私有云部署环境中，约有50台左右的物理服务器，日常活跃虚拟机约为500台，共享一个10个节点的GlusterFS集群。

每次监控任务轮询，总共大约会产生10000条左右的监控数据，这些监控数据形式各不相同，但基本都封装了监控项名称、监控值、时间等要素以及实例id、ip地址等元信息，如果一个集群每10秒都有这么多的数据产生并发布到消息队列，可想而知会对消息队列产生巨大的压力。同时，由于前端horizon等模块接收的用户操作也需要在消息队列上流转，这样的话一旦监控系统产生的数据阻塞了消息队列，则会对整个云平台造成毁灭性的打击。

 

由于云平台处在运行阶段，直接调整RabbitMQ的配置并不是一个很好的选择。于是我们折衷了一下，原有的RabbitMQ依旧运行，转而为Ceilometer另外搭建一套高可用的RabbitMQ集群，使用HAProxy做负载均衡。

   

转http://www.tuicool.com/articles/bQ3iu2r