[rabbitmq-discuss] Possible clustering layout

[Adam Rabung]

Don't worry, I'm definitely the confused one :)

I'm having a hard time finding info on the Active/Active HA in 2.6.  The FAQ
and Clustering Guide led me to believe this feature didn't exist yet.  Do
you know where I can find good info on this new feature?

I'd say our main goal is horizontal scalability for performance sake.  We've
come to the conclusion that we can RAID disks, and if a queue node goes
down, we can bring up a new node with the old disk in human-scale times.

What do you think?  Thank you for any feedback.

Adam

On Wed, Oct 19, 2011 at 1:38 PM, Jerry Kuch <jerryk at vmware.com> wrote:

> Hi, Adam...
>
> I'm perhaps a bit confused.  I assume your goal is tolerating the failure
> of
> individual nodes?
>
> Have you looked at the new active/active HA that debuted in RabbitMQ 2.6.x?
> It allows for queues to be replicated automatically across the nodes of a
> cluster with a user-selectable number of replicas.
>
> Older Rabbits also support an active/passive HA using shared storage.
>
> As you suggest, you might find building the sort of logic you're talking
> about
> entirely outside of the broker daunting and surprisingly difficult to get
> quite what you want out of, as well as being difficult to administer.
>
> Best regards,
> Jerry
>
> ----- Original Message -----
> From: "Adam Rabung" <adamrabung at gmail.com>
> To: rabbitmq-discuss at lists.rabbitmq.com
> Sent: Wednesday, October 19, 2011 6:39:54 AM
> Subject: [rabbitmq-discuss] Possible clustering layout
>
>
>
> Hello, I am thinking through how to lay out a rabbit cluster. One possible
> clustering approach would be have all exchanges/queues duplicated across
> each node in the cluster. Publishers load balance which node they publish
> to, and consumers subscribe to their applicable queues on all nodes. Each
> node is completely independent.
>
>
> This approach seems to have the benefit of avoiding unforeseen hops when a
> publisher or consumer connects to a node that does not hold the queue. It
> also seems beneficial from a fault tolerance standpoint to have messages for
> a logical queue spread evenly across n nodes.
>
>
> One downside I see is the maintenance of these nodes: changing a binding
> means changing it in n places.
>
>
> Is this an acceptable approach, or am I barking up the wrong tree?
>
>
> Thanks,
> Adam
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20111019/90310b3b/attachment.htm>