On 2016-02-12 22:46, Willy Tarreau wrote:
On Fri, Feb 12, 2016 at 12:54:53PM -0800, Florin Andrei wrote:
I want to load balance and make sessions sticky based on the contents
of
a request header. In a nutshell, all requests with the same header
value
must go to, and stick to, the same backend server.
But here's my question. I have not one, but two HAproxy instances. Are
they going to compute the hash the same way? In other words, for the
same value of that header, is haproxy1 going to send the sessions to
the
same backend server as haproxy2?
The hash is absolutely determinist and that's mandatory for situations
like yours to work. It's also what ensures reloads continue to
distribute
the traffic similarly. What you need to keep in mind however is that
the
hash depends on the number of servers in the farm. The operation is a
32-bit
hash on the input data, divided by the number of available servers, and
the
remainder determines the server which will get the request.
- use "hash-type consistent" to change the hash algorithm. It will
- declare a peers section and reference it in your stick table so
Makes sense, and I'm going to do that. Now, more specifically, the
header I'm sticking on is X-Forwarded-For (set by ELB). I believe
headers are strings by default. But the hash is a 32-bit number. What
gets stored in the stick-table - is it the header, or the hash? If it's
the header, the stick-table should be type string, otherwise it should
be integer.
Once in a while I'm going to need to temporarily remove some backend
servers from the pool, for software upgrades and so on. I am going to
shutdown those servers on all haproxies at once (using ssh + haproxyctl,
or the haproxy Ansible module, running in parallel), and hopefully that
will reduce stickiness decoherence to a minimum.
One thing to keep in mind is that our user sessions are very short,
maybe 15 seconds or so, and users come from a wide variety of IPs
(mobile users). This should reduce any smoothness issues with the hash
function, I hope.
Should I disable avalanche? Would that increase the coherence of
stickiness, at the price of reducing smoothness?
This is the configuration I'm thinking of now - does it seem right in
the context of this discussion? I tried to put in it everything that was
discussed.
backend app_nodes
mode http
balance hdr(X-Forwarded-For)
hash-type consistent
stick on hdr(X-Forwarded-For)
stick-table type string size 5M peers api
server s1 x.x.x.x1:8080 check
server s2 x.x.x.x2:8080 check
server s3 x.x.x.x3:8080 check
server s4 x.x.x.x4:8080 check
peers api
peer haproxy1 y.y.y.y1:8989
peer haproxy2 y.y.y.y2:8989
--
Florin Andrei
http://florin.myip.org/
