<div dir="ltr">Ditto on Ron. Some things to be aware of:<div><br></div><div>Most load balancers have monitors that check the status. This half-opens a connection to the rabbit ports, so rabbit will log all of these as info and warning level messages. It tends to flood the logs. Also, watch your heartbeats. We hit an issue initially with our F5's where we had a short TCP/IP timeout and rabbit's heartbeat was longer, so we were getting disconnects every 5 minutes. But, this config has worked well for us for at least two years now :) We back clusters with this, and individual non clustered nodes as well.</div>
<div><br></div><div>Jason</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 24, 2014 at 2:48 PM, Ron Cordell <span dir="ltr"><<a href="mailto:ron.cordell@gmail.com" target="_blank">ron.cordell@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">We have a similar setup with our F5 LB - exposing a VIP to the application and checking the health of the nodes from the F5 by querying the api.<div>
<br></div><div>Cheers,</div><div><br></div><div>-ronc</div>
</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 24, 2014 at 11:52 AM, Arun Rao <span dir="ltr"><<a href="mailto:arunrao.seattle@gmail.com" target="_blank">arunrao.seattle@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I am using Load Balancer (F5). I am using Producer VIP separately from Consumer VIP. This gives me a lot of flexibility when doing maintenance. For Producer VIP, I am using a API health http://<hostname>:15672/api/aliveness-test/<vhost> and looking for "status":"ok" result. <div>
<br></div><div>For consumer VIP, I am just using TCP Half-open.</div><div><br></div><div>HTH,</div><div>-arun.</div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 24, 2014 at 10:01 AM, vish.ramachandran <span dir="ltr"><<a href="mailto:vish.ramachandran@gmail.com" target="_blank">vish.ramachandran@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello RabbitMq Team,<br>
<br>
We are caught in a decision point on whether to choose a load balancer in<br>
front of cluster members or to choose a setup where the list of cluster<br>
members is baked into client configuration.<br>
<br>
Data points:<br>
<br>
1. We are using clustered rmqs mainly for high availability. Our queues are<br>
set up for HA in this setup.<br>
<br>
2. Scalability is not a concern yet. We don't expect to add new members to<br>
the cluster dynamically. Dynamic DNS is a possibility for recovering any<br>
failed nodes.<br>
<br>
3. We are using libraries like Spring AMQP and SStone that provide for<br>
automatic reconnect/failover. This takes care of consumption. We also plan<br>
to design clients to retry publishing upon failure.<br>
<br>
<br>
Questions:<br>
<br>
1. We would like to detect failed connections quickly on the client side. We<br>
wonder whether TCP load balancers do a good job of detecting failed<br>
connections or sit on a bad connection till a real problem is seen.<br>
<br>
2. If clients deal with the cluster members directly, is it any better? Can<br>
the RMQ client library (like sstone or spring amqp) do a better job at<br>
detecting failures quicker than load balancers?<br>
<br>
3. Can the actual consumers and publishers (clients of the RMQ libraries)<br>
take any special action to detect and recover from failures quickly?<br>
<br>
<br>
Thanks<br>
Vish<br>
<br>
<br>
Thanks<br>
Vish<br>
<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://rabbitmq.1065348.n5.nabble.com/High-Availability-and-Load-Balancers-tp35058.html" target="_blank">http://rabbitmq.1065348.n5.nabble.com/High-Availability-and-Load-Balancers-tp35058.html</a><br>
Sent from the RabbitMQ mailing list archive at Nabble.com.<br>
_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">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></div><br>_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">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>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<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>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Jason McIntosh<br><a href="https://github.com/jasonmcintosh/" target="_blank">https://github.com/jasonmcintosh/</a><br>573-424-7612</div>
</div>