> Baptiste, thanks a lot for your patience and your detailed answer.

You're welcome!

> Et pour toi en francais: je suis désolé si tu es maintenant faché.

Fur disch in Deutsch: kein problem. Ich will ein Bier!


>> listen activemq-works
>>   bind :8162
>>   bind :8192
>>   bind :9400
>>   option httpchk HEAD /
>>   server zd-activemq-s21 10.50.241.93:+1 check
>>   server zd-activemq-s22 10.50.241.94:+1 check
>
>> In the case above, where do you perform your health checks???
>
> I would perform the health checks on exactly the ports which are used for the 
> server definition.
> I would use the default port and add the offset. Exactly that what is done 
> for the server definition.

There is no port in the server definition in the configuration above.
there is only an offset based on the connection used by the client.
You may want to use the "tcp-check connect" to perform a full health
check, such as:
  tcp-check connect port 8162
  tcp-check connect port 8192
  tcp-check connect port 9400


> I understand that in the current implementation of haproxy ONLY the first 
> port (8162) is used for the health-check.
> Most probably because only one health-check per listener is used (not 
> approved in source code).
> Then indeed you wonder which port should be used.
> I would use one health-check per bind port and then it is without question 
> which port should be used.
> And writing this I realized my  real misunderstanding.
> I interpreted the possibility to define multiple ports like a mathematical 
> equation "listening port" * server, e.g. do the same for each listening port 
> and each server.
> But in haproxy only the first port is checked and if available it is assumed 
> that the other ports are available too on the same server.

nope, you can check multiple ports as described above.


> Because only the first port of the three binds is used 3 listeners must be 
> defined to achieve correct health-checks in our situation.
> The instances are independently spread over the servers.
>
> listen activemq-8162
>    bind :8162
>    option httpchk HEAD /
>    server zd-activemq-s21 10.50.241.93:8163 check
>    server zd-activemq-s22 10.50.241.94:8163 check
>
> listen activemq-8192
>    bind :8192
>    option httpchk HEAD /
>    server zd-activemq-s21 10.50.241.93:8193 check
>    server zd-activemq-s22 10.50.241.94:8193 check
>
> listen activemq-9400
>    bind :9400
>    option httpchk HEAD /
>    server zd-activemq-s21 10.50.241.93:9401 check
>    server zd-activemq-s22 10.50.241.94:9401 check
>
> The offset in this case has the meaning of "add offset to this port" which 
> would be used without the offset.
> A simple listener definition like this would achieve the same:
>
> listen activemq-doesnotworkinhaproxyaswished
>    bind :8162, :8192, :9400
>    option httpchk HEAD /
>    server zd-activemq-s21 10.50.241.93:+1 check
>    server zd-activemq-s22 10.50.241.94:+1 check
>
> Which results in the same amount of listeners, health checks and server 
> definitions internal in haproxy but with muss less configuration in only one 
> listener.
>
> But don't let me be misunderstood.
> I am very content with haproxy and it works flawlessly without any problems.
> I was just happy to find the offset for the server ports and had the 
> impression that this would be a very comfortable type of configuration for 
> our situation.

So please, be happy to use the following configuration:

 listen activemq-doesnotworkinhaproxyaswished
    bind :8162, :8192, :9400
    option tcp-check
    tcp-check connect port 8163
    tcp-check send HEAD / HTTP/1.0\r\n\r\n
    tcp-check expect rstring (2..|3..)
    tcp-check connect port 8193
    tcp-check send HEAD / HTTP/1.0\r\n\r\n
    tcp-check expect rstring (2..|3..)
    tcp-check connect port 9401
    tcp-check send HEAD / HTTP/1.0\r\n\r\n
    tcp-check expect rstring (2..|3..)
    server zd-activemq-s21 10.50.241.93:+1 check
    server zd-activemq-s22 10.50.241.94:+1 check

Written out of my head, so there may be some errors :)
That way you get the best and most accurate configuration for you need.

Et non, je ne suis pas enervé :)

Baptiste

>
>
> Kind regards
>
> Andreas
>
>
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Baptiste [mailto:bed...@gmail.com]
> Gesendet: Dienstag, 9. Februar 2016 10:45
> An: Grüninger, Andreas (LGL Extern)
> Cc: haproxy@formilux.org
> Betreff: Re: Offset in server definition not usable in 1.6.3
>
>> But I don't get your point.
>
> I may have not been accurate enough.
>
>> I can't see any discrepancies.
>> Could you give me a hint what are you talking about?
>>
>>>> => bind's port is being used for health checks => If multiple bind are 
>>>> present, the first one is used.
>>
>> ------------------------------
>> listen another_example
>>   bind :1999
>>   option httpchk HEAD /
>>   server zd-activemq-s21 10.50.241.93:2000 check
>> ------------------------------
>>
>> Do you really mean that in the example above haproxy should use port 1999 
>> for the health check?
>> IMHO port 2000 should be used.
>
> In the case above, you're not using MAPPED ports, so HAProxy uses the server 
> port to send its health check.
> This is the default / expected behavior.
>
>> I copied from the documentation rom haproxy 1.6.3 for option "check" in 
>> statement "server".
>> --------------------------
>> check
>> This option enables health checks on the server. By default, a server
>> is always considered available. If "check" is set, the server is
>> available when accepting periodic TCP connections, to ensure that it
>> is really able to serve requests. The default address and port to send
>> the tests to are those of the server, and the default source is the
>> same as the one defined in the backend....
>> ---------------------------
>>
>> My example configuration contains 2 listeners, no frontend/backends.
>>
>> I do exactly what is described in the documentation.
>
> No, you did MAPPED ports... This documentation applies to the listen section 
> you wrote at the beginning of this email.
>
>> I don't define explicitly ports for the health check.
>
> Then you should.
>
>> And I sent already the pointer to the source code where the errors occur.
>
> There is no error in the code...
>
>> The 2 listeners used should demonstrate the failure. They are not used in 
>> reality.
>>
>> Backends:
>> 10.50.241.94: both instances down
>> 10.50.241.93: 2 instances up on ports 8162, 8163
>>
>> First listener:
>> listen activemq-works
>>   bind :8162
>>   option httpchk HEAD /
>>   server zd-activemq-s21 10.50.241.93:+1 check
>>   server zd-activemq-s22 10.50.241.94:+1 check
>>
>> The listener in haproxy should bind to 8162.
>> The bind to the backend server should be to 8162 + offset (+1) = 8163.
>
> No. You're using MAPPED ports.
> In such case, HAProxy uses the first binded port because you are in a 
> "listen" section.
> The same server line in a backend section would be an error.
>
> The use of the first port is purely arbitrary and is used to workaround such 
> configuration:
>  listen activemq-works
>    bind :8162
>    bind :8192
>    bind :9400
>    option httpchk HEAD /
>    server zd-activemq-s21 10.50.241.93:+1 check
>    server zd-activemq-s22 10.50.241.94:+1 check
>
> In the case above, where do you perform your health checks???
>
>
>> The health check should be done with 8163.
>
> Then force it with the "port 8163" server's option.
>
>
>> But the health check IS done with 8162 not 8163.
>
> This is expected behavior.
>
>
>> This works because there are 2 running instances of activemq with ports 8162 
>> and 8163. But the wrong instance is used for the health check.
>> The failure is demonstrated in listener 2.
>>
>> listen activemq-doesnotwork
>>   bind :18161
>>   option httpchk HEAD /
>>   server zd-activemq-s21 10.50.241.93:+1 check
>>   server zd-activemq-s22 10.50.241.94:+1 check
>>
>> The listener in haproxy should bind to 8161.
>
> no, this is 18161 in this case.
>
>> The bind to the backend server should be to 8161 + offset (+1) = 8162.
>
> no, this is not how HAProxy works. Read above.
>
>> The health check should be done with 8162
>
> no, it should be run on port 18161.
> To force it, use the "port 8162" option.
>
>> With listener activemq-doesnotwork no servers are found because port 8161 
>> for the health check is used. See the output of haproxy in my first post.
>> And that is wrong.
>>
>> Following the documentation the port for the health check should be the port 
>> for the backend service if not defined explicitly.
>
> Yes.
> your configuration examples aren't in such case, they are MAPPED.
> So simply force the port using the server's "port XXX" option.
>
> Conclusion:
> You have not hit a bug. Re-configure properly your listen sections and it 
> will work accordingly to the doc and the code.
>
> Baptiste
>
>> Andreas
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Baptiste [mailto:bed...@gmail.com]
>> Gesendet: Montag, 8. Februar 2016 08:41
>> An: Grüninger, Andreas (LGL Extern)
>> Cc: haproxy@formilux.org
>> Betreff: Re: Offset in server definition not usable in 1.6.3
>>
>> On Sun, Feb 7, 2016 at 9:43 AM, Grüninger, Andreas (LGL Extern) 
>> <andreas.gruenin...@lgl.bwl.de> wrote:
>>> Hello folks
>>>
>>>
>>>
>>> Haproxy 1.6.3.
>>>
>>> Compiled in OpenIndiana with kernel from December 2015 (illumos-cbff3ab).
>>>
>>>
>>>
>>> I would like to use an offset for the ports in the server definition.
>>>
>>>
>>>
>>> We have several pairs of message brokers in a master/slave scenario
>>> with up to three instances of the admin console listening on the
>>> ports 8161, 8162,
>>> 8163 (prod, test, dev).
>>>
>>>
>>>
>>> What I would like to use is e.g.
>>>
>>> ...
>>>
>>>   bind :28161,:28162,:28163
>>>
>>> ...
>>>
>>>   server .... <IPADDRESS OF TARGET>:-20000
>>>
>>> ...
>>>
>>>
>>>
>>> This does not work because the health checks don't respect the server
>>> flag SRV_F_MAPPORTS.
>>>
>>> This flag is set when during parsing the offset is recognized and
>>> used in backend.c (line 787).
>>>
>>> It should be used in checks.c in connect_conn_chk (line 1421).
>>>
>>> Line numbers are from version 1.6 from the sources found in github.
>>>
>>>
>>>
>>> In the following I use the scenario with 2 instances 8162 and 8163.
>>>
>>> Both instances are running on zd-activemq-s22 and are down on
>>> zd-activemq-s21.
>>>
>>> The first proxy works but the health check uses the wrong instance.
>>>
>>> The health check uses port 8162 and the connection will be made with
>>> port 8163.
>>>
>>> The second proxy does not work at all.
>>>
>>> The health check uses 8161 where no instance is listening.
>>>
>>> No target servers are found and the proxy is not usable.
>>>
>>>
>>>
>>> # cat /opt/etc/haproxy-test.cfg
>>>
>>> global
>>>
>>>   maxconn 4096
>>>
>>>
>>>
>>> defaults
>>>
>>>   log     global
>>>
>>>   mode http
>>>
>>>   option dontlog-normal
>>>
>>>   retries 3
>>>
>>>   maxconn 2000
>>>
>>>   timeout connect      5000
>>>
>>>   timeout client      50000
>>>
>>>   timeout server      50000
>>>
>>>
>>>
>>> listen statistics
>>>
>>>   bind :1935
>>>
>>>   stats enable
>>>
>>>   stats uri /haproxy?stats
>>>
>>>   stats auth admin:admin
>>>
>>>
>>>
>>> listen activmq-works
>>>
>>>   bind :8162
>>>
>>>   option httpchk HEAD /
>>>
>>>   server zd-activemq-s21 10.50.241.93:+1 check
>>>
>>>   server zd-activemq-s22 10.50.241.94:+1 check
>>>
>>>
>>>
>>> listen activmq-doesnotwork
>>>
>>>   bind :18161
>>>
>>>   option httpchk HEAD /
>>>
>>>   server zd-activemq-s21 10.50.241.93:+1 check
>>>
>>>   server zd-activemq-s22 10.50.241.94:+1 check
>>>
>>>
>>>
>>>
>>>
>>> # haproxy -f /opt/etc/haproxy-test.cfg
>>>
>>> [WARNING] 037/091117 (29237) : Server activmq-works/zd-activemq-s21
>>> is DOWN,
>>> reason: Layer4 connection problem, info: "Connection refused", check
>>> duration: 0ms. 1 active and 0 backup servers left. 0 sessions active,
>>> 0 requeued, 0 remaining in queue.
>>>
>>> [WARNING] 037/091118 (29237) : Server
>>> activmq-doesnotwork/zd-activemq-s21 is DOWN, reason: Layer4
>>> connection problem, info: "Connection refused", check
>>> duration: 0ms. 1 active and 0 backup servers left. 0 sessions active,
>>> 0 requeued, 0 remaining in queue.
>>>
>>> [WARNING] 037/091118 (29237) : Server
>>> activmq-doesnotwork/zd-activemq-s22 is DOWN, reason: Layer4
>>> connection problem, info: "Connection refused", check
>>> duration: 0ms. 0 active and 0 backup servers left. 0 sessions active,
>>> 0 requeued, 0 remaining in queue.
>>>
>>> [ALERT] 037/091118 (29237) : proxy 'activmq-doesnotwork' has no
>>> server available!
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Regards
>>>
>>>
>>>
>>> Andreas
>>
>>
>> Hi Andreas,
>>
>> First, there are some inconsistencies between your description and your 
>> configuration example.
>> Could you please check and resend your example in case I misunderstood where 
>> your problem is?
>>
>> That said, you may want to precise the port you want to check:
>>
>>  listen activmq-fix
>>    bind :18161
>>    option httpchk HEAD /
>>    server zd-activemq-s21 10.50.241.93:+1 check port 8161
>>    server zd-activemq-s22 10.50.241.94:+1 check port 8161
>>
>> Something important to note, is that HAProxy's behavior is not the same with 
>> those 2 configurations:
>>
>> 1:
>>  listen example1
>>    bind :18161
>>    option httpchk HEAD /
>>    server zd-activemq-s21 10.50.241.93:+1 check
>>    server zd-activemq-s22 10.50.241.94:+1 check
>>
>> => bind's port is being used for health checks => If multiple bind are 
>> present, the first one is used.
>>
>> 2:
>>  frontend f_example2
>>    bind :18161
>>    default_backend b_example2
>>
>>  backend b_example2
>>    option httpchk HEAD /
>>    server zd-activemq-s21 10.50.241.93:+1 check
>>    server zd-activemq-s22 10.50.241.94:+1 check
>>
>> => this configuration is invalid and an ALERT is returned because backend 
>> b_example doesn't know to which TCP port it is supposed to get connected to 
>> send the health check.
>>
>>
>> Baptiste

Reply via email to