[rabbitmq-discuss] Pulling RabbitMQ out of service

[Chris Chew]

On Feb 4, 2011, at 8:00 AM, Bill Moseley wrote:

The story from our IT department is we don't like DRBD and NAS/SAN is too expensive. ;)  But, they want to be able to yank the plug on a RabbitMQ box and have the application continue with no disruption.  Basically, no message is ever lost.


For what it's worth...

We're currently in production with an active/passive Rabbit writing to a shared volume attached via NFS.  That's working fine for now but in all likelihood will be our first performance bottleneck.  Consequently we're testing performance of an Active/Passive Rabbit writing to a GlusterFS share via the native gluster filesystem driver.  Initial results are looking much better (and cheaper) than what we saw with the more traditional NAS.

Of course the longer term goal is to a) have a better story for A/B/C Rabbit warrens (essentially RAID) and b) add a comfortable amount of failure tolerance into our application workflows, but for now Gluster is looking like a promising next step.

I mention all of this because maybe your IT department will be more comfortable with something like Gluster than DRBD or NAS/SAN.

Good luck!

Chris Chew

P.S. One problem we've seen with the Pacemaker stack and NFS is that sometimes the filesystem isn't unlocked when migrating the resource from the active to the passive server.  A native, fstab'd Gluster volume removes the filesystem from the Pacemaker equation and consequently appears to be more reliable.