On Wed, Feb 10, 2016 at 09:54:27AM +0000, Grüninger, Andreas (LGL Extern) wrote:
> >> I understand that in the current implementation of haproxy ONLY the first
> >> port (8162) is used for the health-check.
>
> > There's no such "first port", there's not even any configured port when
> > you're mapping ports. There's just an offset applied to the incoming
> > connection's destination port.
>
> Please forgive me to use terms not defined in the haproxy namespace.
>
> listen activemq-works
> bind :8162,:8163
> option httpchk HEAD /
> server zd-activemq-s21 10.50.241.93:+1 check
> server zd-activemq-s22 10.50.241.94:+1 check
>
> "First port" is the first port of the ports defined in bind, here 8162.
> I observed with this configuration that a health check is made to 8162
> and only to 8162. No offset is used.
Ah I completely forgot about this antique hack dating back 1.1 or so,
when we used to have a single listening port (hence the "listen" name).
> The connection to server uses incoming port + offset as you told me.
> And the question was which port for the health check should be used and in
> this case it is easy. Just use the ports defined in bind + offset.
That's not necessarily right either due to NAT/tproxy since you declare
the port where the traffic will be redirected but it's irrelevant to the
real service port. Look for example :
listen incoming-tcp
bind :65535
server mail-srv-1 10.50.241.93:+10000 check
Then you have iptables-nat rules redirecting ports 25, 110 and 143 to
port 65535. As you can see in this case it doesn't make sense either
to consider port 65535.
> IMHO the health check with the incoming port without the offset is
> questionable.
I agree that this is the part causing the trouble. It's definitely too
late to remove support for it in stable versions, but we could emit an
error in future versions and a warning in current versions to avoid the
issue. We could even consider emitting a warning if checks are enabled
on a port-less server with multiple listening ports, as the situation is
ambiguous. This is especially true in situations where people use scripts
or APIs to build configs and they have little to no control over the bind
port ordering!
Feel free to take a look at the code and provide a patch. This part will
be either in cfgparse.c or in server.c.
Regards,
Willy
