Persistence for plain TCP connections?

Greetings,

We are looking into HAProxy for load balancing and failover for non-HTTP connections. We have no prior HAProxy experience. All requests come in from the same few clients and are organized in sessions. The thing is, once a session is started, we want it to be served by the same backend server until it is terminated a couple of minutes (at most) later.

Is that supported and how?

Thanks a lot,

George

Yes, via source IP hash or stickiness.

Read:
https://cbonte.github.io/haproxy-dconv/1.6/configuration.html#4.2-balance

Are you referring to the “source” option to the “balance” setting?

All requests will be coming from a known set of just a few IP addresses, so I can’t see how it would work for us. We need HAP to differentiate (and apply stickiness) based on session id.

And which session ID would that be?

More specifically, how do you expect to set or use a session ID, if the protocol you are transporting is not HTTP? Can you tell us what the protocol is?

If the protocol is unkown/arbitrary TCP and you cannot use the source IP to hash or stick, then I wouldn’t know how to achieve persistence.

The protocol is MRCP, and includes the concept of a session. I don’t know if HAP would be capable of discovering and using that.

I have found a presentation made by Percona, a rather famous MySQL cosulting firm, where HAP is used for LB’ing MySQL, and on the issue of persistence the following is written:

* HaProxy decides where the connection will go at TCP handshake
* Once the TCP session is established sessions will stay where they are
* Be cautious with persistent connections
– Configuring connection pool properly
_– Important parameters are minimum, maximum _
connections and connection lifetime

Therefore it would seem that HAP will do what I want it to do by default. So I’m confused…

MySQL doesn’t require any persistence at all, because backend servers are synchronized with each other, so hitting a different backend is expected.

The question here is: are we talking about a single TCP connection here (1 application session == 1 TCP connection), or are their multiple TCP connections per application session)? The former (which is identical to the MySQL use case) doesn’t require anything from the load-balancer, whereas the latter requires stickiness on the load-balancer.

I’m not sure how you define “TCP connection”.

Each session in this protocol is initiated by a packet with a SETUP type message, then the backend server responds with an OK message, then the client sends a few other messages of various types and receives each time a proper response, and at some point the client sends a TEARDOWN message and receives an OK. That’s how all sessions progress. Each session lasts a couple of minutes max.

Perhaps I must also repeat that all sessions will be initiated by the same one or two or maybe three clients systems, so differentiation based on IP address is meaningless.

I know that this protocol can be load-balanced using the Octopus load balancer (a partner of ours is doing it and is happy with it), but I have trouble finding documentation about that, whereas HAP seems to be more prevalent and better supported overall.

Single source-port for the entire MRCP session (between SETUP and TEARDOWN): single TCP connection.
Multiple source-ports for the MRCP session (between SETUP and TEARDOWN): multiple TCP connections.

The question is: is this within a single TCP connection or not. Let me phrase it differently: does the client use the same exact source port for the entire application session?

Very likely it just works.

Yes, I believe that the client source port for each session remains the same throughout.

Than try it, you probably don’t need any persistence at all.