[[ha-aa-rabbitmq]]
=== RabbitMQ

RabbitMQ is the default AMQP server used by many OpenStack services. Making the RabbitMQ service
highly available involves:

* Install RabbitMQ
* Configure RabbitMQ for HA queues
* Configure OpenStack services to use Rabbit HA queues


==== Install RabbitMQ

This setup has been tested with RabbitMQ 2.7.1.

===== On Ubuntu / Debian

RabbitMQ is packaged on both distros:
----
apt-get install rabbitmq-server rabbitmq-plugins
----

http://www.rabbitmq.com/install-debian.html[Official manual for installing RabbitMQ on Ubuntu / Debian]

===== On Fedora / RHEL

RabbitMQ is packaged on both distros:
----
yum install erlang
----

http://www.rabbitmq.com/install-rpm.html[Official manual for installing RabbitMQ on Fedora / RHEL]


==== Configure RabbitMQ

Here we are building a cluster of RabbitMQ nodes to construct a RabbitMQ broker.
Mirrored queues in RabbitMQ improve the availability of service since it will be resilient to failures,
but we have to consider that while exchanges and bindings will survive the loss of individual nodes, queues
and their messages will no because a queue and its contents is located on one node. So if we lose this node,
we also lose the queue.

We consider that we run (at least) two RabbitMQ servers. To build a broker, we need to ensure that all nodes
have the same erlang cookie file. To do so, stop RabbitMQ everywhere and copy the cookie from rabbit1 server
to other server(s):
----
scp /var/lib/rabbitmq/.erlang.cookie \
root@rabbit2:/var/lib/rabbitmq/.erlang.cookie
----

Then, start RabbitMQ on nodes.
If RabbitMQ fails to start, you can’t continue to the next step.

Now, we are building the HA cluster. From rabbit2, run these commands:
----
rabbitmqctl stop_app
rabbitmqctl cluster rabbit@rabbit1
rabbitmqctl start_app
----

To verify the cluster status :
----
rabbitmqctl cluster_status

Cluster status of node rabbit@rabbit2 ...
[{nodes,[{disc,[rabbit@rabbit1]},{ram,[rabbit@rabbit2]}]},{running_nodes,[rabbit@rabbit2,rabbit@rabbit1]}]
----

If the cluster is working, you can now proceed to creating users and password for queues.


*Note for RabbitMQ version 3*

Queue mirroring is no longer controlled by the _x-ha-policy_ argument when declaring a queue. OpenStack can
continue to declare this argument, but it won't cause queues to be mirrored.
We need to make sure that all queues (except those with auto-generated names) are mirrored across all nodes in running:
----
rabbitmqctl set_policy HA '^(?!amq\.).*' '{"ha-mode": "all"}'
----

http://www.rabbitmq.com/ha.html[More informations about High availability in RabbitMQ]


==== Configure OpenStack Services to use RabbitMQ

Since Grizzly Release, most of OpenStack components using queuing has been supported the feature,
we have to configure them to use at least two RabbitMQ nodes.

Do this configuration on all services using RabbitMQ:

RabbitMQ HA cluster host:port pairs:
----
rabbit_hosts=rabbit1:5672,rabbit2:5672
----

How frequently to retry connecting with RabbitMQ:
----
rabbit_retry_interval=1
----

How long to backoff for between retries when connecting to RabbitMQ:
----
rabbit_retry_backoff=2
----

Maximum retries with trying to connect to RabbitMQ (infinite by default):
----
rabbit_max_retries=0
----

Use durable queues in RabbitMQ:
----
rabbit_durable_queues=false
----

Use H/A queues in RabbitMQ (x-ha-policy: all):
----
rabbit_ha_queues=true
----

If you change the configuration from an old setup which did not use HA queues, you should interrupt the service :
----
rabbitmqctl stop_app
rabbitmqctl reset
rabbitmqctl start_app
----

Services currently working with HA queues : OpenStack Compute, Cinder, OpenStack Networking, Ceilometer.