[rabbitmq-discuss] Guidance on Using F5 Load Balancer with RabbitMQ

Richard Raseley richard at raseley.com
Fri Mar 15 20:04:15 GMT 2013


Thank you for your reply. In regard to your comments:

The intent is to abstract all production and consumption operations via the
VIP (which itself is mapped to a pool which contains all of our RabbitMQ
nodes) so that there is a single configured endpoint. With regard to load
balancing, it will load balance across the nodes so that if (for example)
10 producer instances opened up 10 channels to the VIP, 5 would have one
node as an endpoint and 5 would have the other (assuming a 2 node cluster
and round-robin configuration).

I understand that any timeout settings would have to be tuned for the
application, but I was looking for some high level general guidelines (e.g.
"in situation x, consider y and z"). We've ensured that our timeout is
greater than the heartbeat interval.



On Fri, Mar 15, 2013 at 3:46 AM, Tim Watson <tim at rabbitmq.com> wrote:

> Hi Richard,
> On 11 Mar 2013, at 20:55, Richard Raseley wrote:
> > Is anyone able to share some "best practices" as it relates to using a
> F5 load balancer to distribute load between nodes of a RabbitMQ cluster?
> >
> Can you explain a bit more clearly what you're trying to achieve please?
> Using a load balancer to maintain connectivity to a cluster is recommended
> and quite common, but that isn't going to 'distribute load between nodes'
> per se. Are you trying to distribute the load of publishing over multiple
> nodes, or consuming, or what? There are various things to consider
> depending on your goals.
> > I am most interested in the persistence and timeout settings which we
> should be using in conjunction with RabbitMQ.
> >
> There cannot be any specific settings that will work for all deployments -
> this will be application specific I would've thought. The only advice that
> springs to mind is if you are setting AMQP heartbeats on your connections,
> then make sure the proxy timeout is aligned with (i.e., greater than) these
> to avoid disturbing connections unnecessarily - but that's pretty obvious.
> Cheers,
> Tim
> _______________________________________________
> 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/20130315/c201c8ea/attachment.htm>

More information about the rabbitmq-discuss mailing list