Hi Norman,
Le 23/07/2018 à 18:36, Norman Branitsky a écrit :
My client’s environment had 3 HAProxy servers.
Due to a routing issue, my client’s users could only see the old HAProxy
1.5 server when connecting from their data center.
They could not see the 2 new HAProxy 1.7 servers.
The routing issue was resolved last week and they could now see the 2
new HAProxy servers, as well the old server.
They started getting quick disconnects from their Java application –
the SEVERE error indicated that they had arrived at the wrong server and
had no current session.
[...]
New HAProxy servers configuration:
backend ssl_backend-vr
balance roundrobin
stick-table type ip size 20k peers mypeers
stick on src
Here you are using stick tables for session persistence.
[...]
cookie SRV insert indirect nocache httponly secure
server i-067c94ded1c8e212c 10.241.1.138:9001 check cookie
i-067c94ded1c8e212c
server i-07035eca525e56235 10.241.1.133:9001 check cookie
i-07035eca525e56235
But here, you are using cookies for the same purpose.
I realized that the cookie mechanism was different so I shut down the
old HAProxy server and the problem appeared to be resolved.
This morning that client is complaining that the problem has returned –
disconnects resulting in the user being kicked out to the login screen.
Checking with multiple browsers, I can see both the old JSESSIONID
cookie (with the machine name appended) and the new SRV cookie.
Checking with multiple browsers, my colleagues can *NOT* see the new SRV
cookie from any browser in this office –
but they can see the SRV cookie when browsing from a virtual PC in our
Atlanta data center!
Even more puzzling, though my client cannot see the SRV cookie (either
in the F12 cookies sent list, or in the browser’s cookies folder)
he *never* experiences an unexpected disconnect.
Suggestions, please?
You have to make a choice, either you use stick tables, either you use
cookies, but don't mix both otherwise you'll have the situation you are
describing.
--
Cyril Bonté
