I have a standard erlang application build upon otp principles. I plan to place my erlang nodes in production as explained below:
- receive all traffic on a public ip (haproxy)
- haproxy them to one of the available backend erlang node
All this works very well however in case of session based http transactions, chances are one of the erlang node receives a request, who's session related processes resides on another erlang node.
My questions are related to best strategy for handling such cases:
- first option is to configure haproxy to balance based upon source (i.e. ip address), this will always guarantee all requests for a session from a single ip goes to same backend erlang node
- second option is to configure haproxy to balance based on some session related cookie parameter (which basically gives me same as case 1))
- finally, since my erlang nodes can very well communicate with each other, it is also possible to simply configure haproxy to balance in roundrobin fashion, and when an erlang node receives a request, whose session processes reside on another erlang node, it can internally communicate with the erlang node using rpc:call() and serve the request.
1),2) are pretty much straighforward to use and setup, however I read and tested that source/cookie/url_param based balancing doesn't ensure equal balancing among backends.
3) is achievable using mnesia replication power inside erlang. With 3) I will probably end up with a case where one erlang node communicates internally to another erlang node before it finally serves response to a request.
I would like to know what is preferable and why? Will 3) be a better choice in long run considering my otp application handles a lot of real-time data (xmpp protocol).