Don't worry, I'm definitely the confused one :)<br><br>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?<div>
<br>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.</div>
<div><br></div><div>What do you think? �Thank you for any feedback.</div><div><br></div><div>Adam<br><br><div><div class="gmail_quote">On Wed, Oct 19, 2011 at 1:38 PM, Jerry Kuch <span dir="ltr"><<a href="mailto:jerryk@vmware.com">jerryk@vmware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi, Adam...<br>
<br>
I'm perhaps a bit confused. �I assume your goal is tolerating the failure of<br>
individual nodes?<br>
<br>
Have you looked at the new active/active HA that debuted in RabbitMQ 2.6.x?<br>
It allows for queues to be replicated automatically across the nodes of a<br>
cluster with a user-selectable number of replicas.<br>
<br>
Older Rabbits also support an active/passive HA using shared storage.<br>
<br>
As you suggest, you might find building the sort of logic you're talking about<br>
entirely outside of the broker daunting and surprisingly difficult to get<br>
quite what you want out of, as well as being difficult to administer.<br>
<br>
Best regards,<br>
Jerry<br>
<div><div></div><div class="h5"><br>
----- Original Message -----<br>
From: "Adam Rabung" <<a href="mailto:adamrabung@gmail.com">adamrabung@gmail.com</a>><br>
To: <a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
Sent: Wednesday, October 19, 2011 6:39:54 AM<br>
Subject: [rabbitmq-discuss] Possible clustering layout<br>
<br>
<br>
<br>
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.<br>
<br>
<br>
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.<br>
<br>
<br>
One downside I see is the maintenance of these nodes: changing a binding means changing it in n places.<br>
<br>
<br>
Is this an acceptable approach, or am I barking up the wrong tree?<br>
<br>
<br>
Thanks,<br>
Adam<br>
</div></div>_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
</blockquote></div><br></div></div>