<div dir="ltr">Hi,<div><br></div><div>I do this a lot and here are two cents about common issues I see. It all depends on the protocol (reconnects/retransmits/statefulness/session-based) and if you have control over the clients. The best load balancing is always on the client side. If you have control over the clients just code them to search and pick their server with your custom timeout rules and recovery. The next best thing is if the clients have SRV awareness or even a simple multiple A DNS record awareness that would be a very reasonable solution Proper SRV support from random apps is rare in my experience, even common client for protocols like SIP, HTTP and XMPP and bad with SRV. Normal DNS A dispenser is sufficient most of the time, but doesn't handle failover cases very well. There is no advantage in using a load balancer unless your protocol is stateful and requires app-level affinity or sticky sessions, however there are a few exceptions. TCP itself is stateful however if your protocol knows to reconnect and heartbeat independently you can ignore that. In the context of Erlang, you may have to consider how are you going to handle production maintenance operations such as moving nodes around and detecting cluster in bad state.  Load balancers can be reliable and do great for mid-session failover cases, but it's more expensive and difficult. If you are using a load balancer it has to be able to maintain existing TCP connections until they terminate but not send new connections to the serviced nodes. Another production operation you need to consider is IP-takeover to replace a node at some IP address, Erlang doesn't handle this very well on a running system and it has to be done with virtual adapters or redirection at the OS level. If your protocol stamps IP addresses or names inside the payload like SIP/SDP you will need application awareness of the load balancing and IP takeover operations. Many solutions for SIP or HTTP are hybrid with active/passive DNS pointing to N IP load balancers feeding M app-level load balancers to assure protocol specific sticky-ness (HTTP session/Call-ID).</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 14, 2014 at 1:09 AM, Roberto Ostinelli <span dir="ltr"><<a href="mailto:roberto@widetag.com" target="_blank">roberto@widetag.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"><div>Dear list,<br></div><div>I have many servers in a cluster that handle long-lived TCP connections with multiple clients.</div><div><br></div><div>I'd like to collect some opinions on what you'd believe to be the best options to balance the load on these servers:</div><div><br></div><div> - Implement a protocol that a client has to first ask to which server to connect to, and then go for it</div><div> - Use SRV records</div><div> - Have all traffic through some proxy like HAProxy (but then, doesn't this mean that a single box has to handle millions of connections?)</div><div><br></div><div>I do realize that this is not necessarily related to Erlang, but as we often have to deal with backend servers with long-lived TCP connections I thought there might be the correct experience here.</div><div><br></div><div>Hopefully some kind sould will provide me with some suggestions :)</div><div><br></div><div>Best,</div><div>r.</div><div><br></div></div>
<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>