I'm building a system that sits in two datacenters for resiliancy, using a live / standby model. The system requires a message queue that delivers messages for processing by the system backend. My design at the moment calls for that message queue (and exchanges etc) to be shared across both datacenters as a single virtual queue. That way, failover can be achieved by shutting down the queue consumers in site A and starting them in site B - the consumers will simply subscribe to their local broker and bind to the single global exchange and start to receive messages sent there, including those that were queued while the failover occurred.
I've used RabbitMQ in the past, and am aware that it can do clustering and that the clustering is not suitable for WAN connections - it's very intolerant of packet loss / network partitioning. I've read about the rMQ federation plugin, which seems to imply that two federated brokers can allow their exchanges to be bound to by clients connecting on each other.
I'm not sure if I can use this to achieve exactly what I need, it would seem that I'd need each DC broker to define an exchange, federate the two brokers and then the clients on each site would need to bind to both the exchange hosted by their local broker, and that hosted on the remote broker. Each individual exchange would still be local to a particular broker. Have I understood that correctly?
Second question - presumably the federation plugin works with separate rMQ clusters? If I had a cluster of rMQ brokers in site A, and a similar cluster in site B, could I federate them together?
