Le 24/04/2018 à 23:07, Shawn Heisey a écrit :
I sent this query to the list previously nine days ago. I got no
response. Trying again.
Next time reply to the thread you created, it's better to track which
ones had responses.
======
Kernel info:
root@lb1:/etc/haproxy# uname -a
Linux lb1 3.13.0-52-generic #86-Ubuntu SMP Mon May 4 04:32:59 UTC 2015
x86_64 x86_64 x86_64 GNU/Linux
Here's the haproxy version output:
root@lb1:/etc/haproxy# haproxy -vv
HA-Proxy version 1.5.12 2015/05/02
Copyright 2000-2015 Willy Tarreau <w...@1wt.eu>
Build options :
TARGET = linux2628
CPU = native
CC = gcc
CFLAGS = -O2 -march=native -g -fno-strict-aliasing
OPTIONS = USE_ZLIB=1 USE_OPENSSL=1 USE_PCRE= USE_PCRE_JIT=1
Default settings :
maxconn = 2000, bufsize = 16384, maxrewrite = 8192, maxpollevents = 200
Encrypted password support via crypt(3): yes
Built with zlib version : 1.2.8
Compression algorithms supported : identity, deflate, gzip
Built with OpenSSL version : OpenSSL 1.0.2j 26 Sep 2016
Running on OpenSSL version : OpenSSL 1.0.2j 26 Sep 2016
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports prefer-server-ciphers : yes
Built with PCRE version : 8.31 2012-07-06
PCRE library supports JIT : no (libpcre build without JIT?)
Built with transparent proxy support using: IP_TRANSPARENT
IPV6_TRANSPARENT IP_FREEBIND
Available polling systems :
epoll : pref=300, test result OK
poll : pref=200, test result OK
select : pref=150, test result OK
Total: 3 (3 usable), will use epoll.
The configuration I had is with a backend that has two servers, one of
them tagged as backup. This is the actual config that I had active when
I saw the problem:
backend be-cdn-9000
description Back end for the thumbs CDN
cookie MSDSRVHA insert indirect nocache
server planet 10.100.2.123:9000 weight 100 cookie planet track
chk-cdn-9000/planet
server hollywood 10.100.2.124:9000 weight 100 backup cookie
hollywood track chk-cdn-9000/hollywood
Well, you don't provide any information about the tracked servers
chk-cdn-9000/planet and chk-cdn-9000/hollywood.
My check interval is ten seconds and the check timeout is 9990 milliseconds.
==============
If I shut down the primary server, eventually haproxy notices this. No
problem so far.
The problem is that about ten seconds pass between the time haproxy
notices the primary going down and the time that the backup server
changes to active. During that time, clients get "no server available"
errors.
It is my expectation that as soon as the primary server goes down,
haproxy will promote the backup server(s) with the highest weight to
active and send requests there.
Without any information about the 2 tracked server, I'd say the
behaviour is expected. A backup server is promoted only if it is UP
itself. What is the state of chk-cdn-9000/hollywood during that time ?
It looks like it's not UP yet.
I know that I'm running an out of date version and can't expect any
changes in 1.5.x. I have not yet tried this with a newer version of
haproxy.
As a workaround, I have removed the "backup" keyword. For this backend
that's an acceptable solution, but I am using that configuration
elsewhere in cases where I only want the traffic to go to one server as
long as that server is up, and I need the backup server to take over
quickly when the primary fails.
Thanks,
Shawn
--
Cyril Bonté
