Amazon EC2

Using RabbitMQ on EC2 is no more complex than running it on other platforms. Although we don't provide our own AMI images, we make sure that RabbitMQ does work on current Ubuntu AMIs.

This guide is mean to be used together with the general clustering guide.

Choose instance type

First, you need to choose what instance type to run. RabbitMQ will work on every instance type, but there are a few considerations worth bearing in mind:

  • RabbitMQ will work on 32-bit operating system, but for production usage we recommend 64-bit instances.
  • RabbitMQ by default will take advantage of all the processors in the system. However a single strong CPU configuration might behave slightly better than a collection of weak processors.
  • In some cases RabbitMQ requires substantial amounts of memory. Make sure that your host does have enough RAM and always have at least a few gigabytes of swap space enabled.

Choose operating system

Although RabbitMQ is tested with most major Linux distributions, Ubuntu support for Amazon EC2 seems to be strongest. You can get the list of Ubuntu AMI images here:

      http://uec-images.ubuntu.com/releases/
You may find more information in Ubuntu EC2 Starters Guide.

Install RabbitMQ

Ubuntu ships with RabbitMQ but it's often not the latest version. If you want the recent version, you may use our Debian repository. Here is a shell script rabbitmq-user-data.sh that automates RabbitMQ installation on Ubuntu:

#!/bin/sh
cat <<EOF > /etc/apt/sources.list.d/rabbitmq.list
deb http://www.rabbitmq.com/debian/ testing main
EOF

curl http://www.rabbitmq.com/rabbitmq-signing-key-public.asc -o /tmp/rabbitmq-signing-key-public.asc
apt-key add /tmp/rabbitmq-signing-key-public.asc
rm /tmp/rabbitmq-signing-key-public.asc

apt-get -qy update
apt-get -qy install rabbitmq-server

Instead of running it manually, you can tell the instance to run this script automatically during the first start. You can do it using the user-data-file command line option for the ec2-run-instances command. For example:

$ ec2-run-instances ami-XXX \
    --key ${EC2_KEYPAIR} \
    --instance-type m1.large \
    --region eu-west-1 \
    --user-data-file rabbitmq-user-data.sh
Put your chosen AMI id in the place of ami-XXX. The string ${EC2_KEYPAIR} should be replaced with the public ssh keypair name that is going to be used to log in to the instance. You can find more information about ec2-run-instances command in EC2 Getting Started Guide.

Persistent data on EBS device

RabbitMQ writes data to the following directories on Ubuntu:

  • /var/lib/rabbitmq/ to store persistent data like the messages or queues
  • /var/log/rabbitmq/ to store logs

If you want to use EBS block device to store RabbitMQ data, just link these directories to your EBS device. Stop RabbitMQ before making any changes to the data directory:

$ /etc/init.d/rabbitmq-server stop

Default user access

The broker creates a user guest with password guest. Unconfigured clients will in general use these credentials. By default, these credentials can only be used when connecting to the broker as localhost so you will need to take action before connecting fromn any other machine.

See the documentation on access control for information on how to create more users, delete the guest user, or allow remote access to the guest user.

Issues with hostname

RabbitMQ names the database directory using the current hostname of the system. If the hostname changes, a new empty database is created. To avoid data loss it's crucial to set up a fixed and resolvable hostname. For example:

sudo -s # become root
echo "rabbit" > /etc/hostname
echo "127.0.0.1 rabbit" >> /etc/hosts
hostname -F /etc/hostname
    
Whenever the hostname changes you should restart RabbitMQ:
$ /etc/init.d/rabbitmq-server restart

A similar effect can be achieved by using rabbit@localhost as the broker nodename.

The impact of this solution is that clustering will not work, because the chosen hostname will not resolve to a routable address from remote hosts. The rabbitmqctl command will similarly fail when invoked from a remote host. A more sophisticated solution that does not suffer from this weakness is to use DNS, e.g. Amazon Route 53 if running on EC2.

Firewalled nodes

The case for firewalled clustered nodes exists when nodes are in a data center or on a reliable network, but separated by firewalls. Again, clustering is not recommended over a WAN or when network links between nodes are unreliable.

In the most common configuration you will need to open ports 4369 and 25672 for clustering to work.

Erlang makes use of a Port Mapper Daemon (epmd) for resolution of node names in a cluster. The default epmd port is 4369, but this can be changed using the ERL_EPMD_PORT environment variable. All nodes must use the same port. For further details see the Erlang epmd manpage.

Once a distributed Erlang node address has been resolved via epmd, other nodes will attempt to communicate directly with that address using the Erlang distributed node protocol. The default port for this traffic in RabbitMQ is 20000 higher than RABBITMQ_NODE_PORT (i.e. 25672 by default). This can be explicitly configured using the RABBITMQ_DIST_PORT variable - see the configuration guide.

Erlang Versions Across the Cluster

All nodes in a cluster must run the same version of Erlang.

Testing RabbitMQ

Once RabbitMQ has been started, confirm that it actually works. You can do this by installing the RabbitMQ Java client and running the test scripts that come with it. Use the following instructions to install the required packages on the instance:

apt-get install openjdk-6-jre
curl http://www.rabbitmq.com/releases/rabbitmq-java-client/v3.4.1/rabbitmq-java-client-bin-3.4.1.tar.gz \
    -o rabbitmq-java-client-bin-3.4.1.tar.gz
tar xzf rabbitmq-java-client-bin-3.4.1.tar.gz
cd rabbitmq-java-client-bin-3.4.1

When the dependencies are available, you can run the test:

rabbitmq:~/rabbitmq-java-client-3.4.1$ sh ./runjava.sh com.rabbitmq.examples.MulticastMain

On the screen you should see output similar to this:

starting consumer #0
starting producer #0
recving rate: 2920 msg/s, min/avg/max latency: 13431/137515/349586 microseconds
sending rate: 7182 msg/s
recving rate: 4513 msg/s, min/avg/max latency: 352244/535973/715864 microseconds
sending rate: 4897 msg/s
recving rate: 4119 msg/s, min/avg/max latency: 654393/829167/1021911 microseconds
sending rate: 4989 msg/s

If you have any comments please let us know.