Persistence for plain TCP connections?


#1

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


#2

Yes, via source IP hash or stickiness.

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


#3

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.


#4

And which session ID would that be?


#5

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.


#6

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…


#7

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.


#8

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.


#9

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.


#10

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


#11

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