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

[Richard Raseley]

Tim,

Thank you for that information - I hadn't realized that was the case with
HA queues. So, in our situation we may be better off configuring the load
balanced pool to be Active / Passive so that messages will always be
flowing directly to the node that is running the master queue process
(thereby eliminating the intra-node network overhead)?

Regards,

Richard


On Mon, Mar 18, 2013 at 10:47 AM, Tim Watson <watson.timothy at gmail.com>wrote:

> Richard,
>
> On 18 Mar 2013, at 16:55, Richard Raseley <richard at raseley.com> wrote:
>
> Tim,
>
> With regard to your comment:
>
> "Ok, but you do realise that a single queue will reside on only one node,
> and therefore messages sent to other nodes in the cluster will still have
> to be routed/forwarded to the node on which the queue resides?"
>
> We are using highly available queues, so this wouldn't be the case
> (right?).
>
>
> Even with HA the master queue process still resides on just one node an
> all messages will be sent to it.
>
> Cheers,
> Tim
>
> I understand that there is intra-node communication required to support
> this.
>
> Regards,
>
> Richard
>
>
> On Sat, Mar 16, 2013 at 8:27 AM, Tim Watson <tim at rabbitmq.com> wrote:
>
>> Hi Richard,
>>
>> On 15 Mar 2013, at 20:04, Richard Raseley wrote:
>> > 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).
>> >
>>
>> Ok, but you do realise that a single queue will reside on only one node,
>> and therefore messages sent to other nodes in the cluster will still have
>> to be routed/forwarded to the node on which the queue resides?
>>
>> > 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.
>> >
>>
>> I think heartbeats are the main (general) thing to be considered. Perhaps
>> other users who're more familiar with production configurations such as
>> these will have more to add though.
>>
>> Cheers,
>> Tim
>>
>> > Regards,
>> >
>> > Richard
>> >
>> >
>> > 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
>> >
>> > _______________________________________________
>> > rabbitmq-discuss mailing list
>> > rabbitmq-discuss at lists.rabbitmq.com
>> > https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>>
>> _______________________________________________
>> rabbitmq-discuss mailing list
>> rabbitmq-discuss at lists.rabbitmq.com
>> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
>
> _______________________________________________
> 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/20130318/add4026c/attachment.htm>