<br><br><div class="gmail_quote">On Fri, Jan 14, 2011 at 6:58 AM, Mark J. Reed <span dir="ltr"><<a href="mailto:markjreed@gmail.com">markjreed@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
What do you all do to distribute activity across a cluster? That is,<br>
given a cluster of rabbitmq brokers and a group of client applications<br>
that each expect to be configured to talk to a single broker, what do<br>
I do?<br>
<br>
1. Stand up TCP load-balancer in front of the cluster?<br>
2. Assign a cluster node to each client pseudo-randomly?<br>
3. Set up each client host as an additional rabbitmq broker and point<br>
the applications at localhost?<br></blockquote><div><br></div><div>I've been spending a lot of time looking for the same answers. Is there documentation on actual hardware configuration and management of servers in a production environment?</div>
<div><br></div><div>To me, it is important that producers (web processes in my case) can always talk to a broker. So, I've been looking at #1 with two HAProxy servers (one as fail-over with Heartbeat) in front of a cluster of nodes. Only partial success with that so far.</div>
<div><br></div><div>On the same topic, I'm also curious how clients are suppose to behave. If I have workers listening on a queue how should they handle a network failure? Do any of the clients manage reconnecting on error?</div>
<div><br></div><div>BTW -- I also looked at the HA docs at <a href="http://www.rabbitmq.com/pacemaker.html">http://www.rabbitmq.com/pacemaker.html</a> -- but that's replicating queue data, correct? Is there a need for DRDB if willing to accept loss of messages?</div>
<meta http-equiv="content-type" content="text/html; charset=utf-8"><div><br></div><div><br></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>