@dsouza_jude wrote:
Hi,
With reference to this post [1] and with my own experience of the exact same thing in the past, i’m wondering if you have any suggestions or best practices how to deal with it.
The problem, in summary is that, in a dynamic environment where there are many deploys happening every hour from a bunch of services in a microservices platform, HAProxy configurations needed to be reloaded quite often. Usually there are many REST based services that communicate via the HTTP protocol, but at times (as in my case), there are also a couple of services that require long-lived TCP connections. In such a case, during reloads, you end up with more than the usual number of HAProxy processes running on the host because there are still active connections to those long lived TCP connections (as they might be sending constant heartbeats). I understand this is by design if i’m not mistaken.
As a result, the old process is left with an outdated version of backend configurations. For some reason, due to this state, we’ve observed HTTP 503s being returned from HAProxy.
I’d basically like your thoughts and recommendations around this, in particular with respect to the newest version (1.8) of HAProxy and if we can expect any side-effects. Also i’m wondering if it would be better to run two HAProxy instances, one dedicated to just HTTP connections and the other for just TCP connections.
Please advise.
References:
[1] https://medium.com/@x_cray/don-t-balance-tcp-traffic-with-haproxy-d7923a6e379e
Posts: 1
Participants: 1