On Fri, Jan 14, 2011 at 9:08 AM, Matthew Sackman <span dir="ltr"><<a href="mailto:matthew@rabbitmq.com">matthew@rabbitmq.com</a>></span> wrote:<div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">Entirely up to you - resources are visible throughout the cluster and so</div>
any sane load balancing should be just fine. If they all connect to the<br>
same node then you'll likely find that all resources exist solely on<br>
that node and thus the other nodes are not being used at all. Thus<br>
really, you want to make sure that the clients which create resources<br>
(queues in particular) are connected across all the nodes.<br>
<br>
The other thing to consider is the inter-node hops required to route<br>
messages. Thus you may wish to make sure that if client 1 is<br>
predominantly sending messages to or consuming messages from queue 1,<br>
that client 1 is connected to the same node on which queue 1 resides.<br></blockquote><div><br></div><div>Hum. �There's always trade-offs. �</div><div><br></div><div>The top concern is that a producer (and consumer) can connect to a node. �What looks like a good choice is HAProxy in front of a set of RabbitMQ nodes. �And maybe a pair of HAProxy machines with Heartbeat to avoid the single point of failure. �Configuration is easier because workers just talk to one HAProxy.</div>
<div><br></div><div>But, then there's no control over which node a producer or consumer connects to. �So, then there's going to be be some (probably half) cross-node messages.</div><div><br></div><div>Perhaps if the point of the second node is for HA then should just configure HAProxy to only use the second node as a hot-backup and make both nodes disk nodes. �The nature of a backup is that it must be able to handle all traffic, anyway.</div>
<div><br></div><div>If we design with the idea messages might get dropped, and always declare exchanges, queues, and bindings on every connection then maybe there's no need for a cluster or using the Pacemaker HA example and just run independent RabbitMQ instances with a method of fail-over.</div>
<div><br></div><div><br></div><div>Thanks very much for the help, Matthew.</div><div><br></div><div><br></div><div>Would I be wrong to assume that these configuration issues have been solved by many people already?</div>
<div>
<br></div><div><br></div></div>-- <br>Bill Moseley<br><a href="mailto:moseley@hank.org" target="_blank">moseley@hank.org</a><br>
</div>