[rabbitmq-discuss] HA between data centers

Bill Moseley moseley at hank.org
Wed Jan 12 03:57:19 GMT 2011


The High Availablity docs at http://www.rabbitmq.com/pacemaker.html seem
pretty thorough.  Are there any other approaches commonly used for HA? What
about for syncing between data centers? Can anyone discuss their HA approach
if it differs from the link above?

We are evaluating messaging systems and the question of HA has come up
frequently.  The concern is that some items, once entered onto the queue,
should never be lost -- even if the entire data center goes down.

We are comparing RabbitMQ with writing a system in-house.  The in-house
queue system would use a Postgresql table for the queue with replication
(currently via Slony) for hot-backup (it's not really HA).  We also
replicate to a secondary data center with the eventual goal of reasonably
fast tip-over between data centers.  We are not in the financial or medical
industry so nobody's life is at risk if we drop a few jobs.  I suspect we
only need to handle three to five million message a day -- nothing too big.
 (Oddly, one argument against using RabbitMQ was it was overkill for our
needs.)

Postgresql and replication is what we use for application data currently, so
it is a familiar technology for us.  Another reason we are considering
building a custom message queue system is to put more functionality into the
broker -- such as scheduling and job routing that would be specific to our
business.  And there's fear that nobody knows Erlang if something broke and
we needed to try and resolve.

My opinion is AMQP is very flexible and we should be able to make it meet
our needs.  We are not doing anything that unusual.  And I suspect building
something as reliable as RabbitMQ is no easy task -- especially if the point
is to make a system more complex than what RabbitMQ provides.  Scheduling,
for example, seems like something a simple database table and cron could
solve easily with RabbitMQ.

Another argument for a custom broker was to make better use of workers --
i.e. the broker would look at load and other factors when determining where
to send jobs.  My feeling here is resources are limited so it's a matter of
balancing the number and type of consumers with queue load -- and an
external process can manage starting and stopping consumers easily as demand
profile changes (by looking at queue sizes and rates) without having to be
part of the broker.  Are there common approaches for dynamically adjusting
workers?

Anyone go through this kind of discussion in your own organization?

Thanks,

-- 
Bill Moseley
moseley at hank.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20110111/4f794bf5/attachment.htm>


More information about the rabbitmq-discuss mailing list