Contents

1. OpenAMQ Clustering
2. Cluster FAQ

1. OpenAMQ Clustering

General Principles

The OpenAMQ clustering implementation covers two main functionalities:

1. The use of high-availability pairs to create automatic failover systems in which applications can switch to a backup server if a primary server crashes.
2. The interconnection of servers or high-availability pairs into larger architectures that can support distributed request-response and pub-sub scenarios.

High-availability Cookbook

Summary

We take two brokers, running on the same or different systems. One broker is the primary, one is the backup. When the cluster starts, the primary is master and the backup is slave. If the primary dies, the backup takes over the role of master. If the primary comes back, it remains slave. To reset the cluster, restart the backup.

Application Support

For HA clustering to work, applications must connect to first the primary server, and if that fails, the backup server. Applications must use the correct order (primary, then secondary).

HA Configuration

You can share the same configuration for both brokers by specifying the key options on the command-line. In amq_server.cfg, add this section:

<cluster
    vhost = "/"
    primary_peer = "localhost:5555"
    backup_peer = "localhost:6666"
/>

Then start the two brokers as follows (you can use any legal values for the port numbers):

amq_server --port 5555 --is_primary 1
amq_server --port 6666 --is_backup 1

Alternatively you can use two separate configuration files, with the primary server using this:

<cluster
    vhost = "/"
    is_primary = "1"
    backup_peer = "localhost:6666"
/>

And the backup server using this:

<cluster
    vhost = "/"
    is_backup = "1"
    primary_peer = "localhost:5555"
/>

Virtual Host

The vhost option is used to ensure that connecting applications are using the correct cluster. This value must match the value used by applications.

Exchange Forwarding Cookbook

Summary

We connect an exchange on one broker (or HA pair of brokers) to the matching exchange on a remote broker (or HA pair of brokers).

The local exchange either sends messages to the remote exchange, or subscribes to messages from it.

There are three message transfer modes:

1. Subscriber forwarding - the local exchange requests messages from the remote exchange.
2. Full forwarding - the local exchange forwards all messages to the remote exchange.
3. Default forwarding - the local exchange forwards only unmatched messages to the remote exchange.

Subscribe Forwarding

The classic scenario is when local applications want to receive topic data published centrally.

The configuration looks like this:

<cluster_mta
    name = "exchange-name"
    vhost = "virtual-host-name"
    host = "remotehost:port"
    login = "peering"
    mode = "1"
/>

All bindings made to the specified exchange are copied to the specified remote host exchange.

Most often used with topic or headers exchanges.

Worked example:

• A set of clients in a regional office need to get market data from a central server.
• The configuration is done entirely at the regional office by defining an MTA that connects the market data exchanges on both servers.
• When data is published centrally, any messages that match requests from the regional applications are forwarded to the regional server.

Full Message Forwarding

The classic scenario is when local applications want to publish data both to local clients and remote ones.

The configuration looks like this:

<cluster_mta
    name = "exchange-name"
    vhost = "virtual-host-name"
    host = "remotehost:port"
    login = "peering"
    mode = "2"
/>

All messages published to the local exchange are automatically published to the remote exchange as well.

Most often used with topic or headers exchanges.

Default Message Forwarding

The classic scenario is when local applications want to use services that could be either local, or remote.

The configuration looks like this:

<cluster_mta
    name = "exchange-name"
    vhost = "virtual-host-name"
    host = "remotehost:port"
    login = "peering"
    mode = "3"
/>

All messages published to the local exchange are automatically published to the remote exchange only if they are not delivered locally.

Most often used with direct exchanges so that services can be placed either locally or remotely, invisibly to the applications.

2. Cluster FAQ

• When do I need to use OpenAMQ clustering? Answer: mainly if you want failover, in case your main messaging server crashes. Since OpenAMQ very rarely crashes, most people do not need this. But for those who need extreme reliability, clustering is very useful.
• Do I need clustering for performance? Answer: OpenAMQ is very fast on a multi-CPU box. It's probably cheaper and simpler to buy a faster server, if you need the performance, than to use clustering. However if you have at least three existing slower servers and you need to handle a large number of clients (thousands), you can use clustering to split the load across these servers.