RE: Problem with health checking

[John Lanigan]

Thanks Cyril,

I'll try that, and also have the app server team compare their settings across 
the servers.

Kind Regards,
 
John Lanigan
CORE |   +353 (0)25 41400   |  ||john.lani...@coresoftware.ie    |     
www.coresoftware.ie

-Original Message-
From: Cyril Bonté [mailto:cyril.bo...@free.fr] 
Sent: Sunday 7 August 2016 20:28
To: John Lanigan
Cc: haproxy@formilux.org
Subject: Re: Problem with health checking

Hi John,


Le 07/08/2016 à 21:17, John Lanigan a écrit :
> [...]
> http-check expect status 200
> http-check disable-on-404
>
> server hostingapp2_5041 172.17.2.40:5041  check
> server hostingapp3_5041 172.17.2.50:5041  check
>
> [...]
>
> If I access all four of those URLs with lynx to show the headers from 
> the command line on the haproxy server I get the same result from each 
> server, instantaneous response and HTTP 200 status.
>
> [...]
>
> But the haproxy stats page reports L7 timeout if we add in a check on 
> the new app setup.
>
>
>
> Any ideas what I need to check next?
>
> [...]
>
> I’ve been running  haproxy 1.4.24 on centos 6.5 for over 2 years, load 
> balancing a pair of Oracle 11g app servers on Windows 2008r2.


Did you upgrade to the latest 1.4 to see if the issue remains ?
After reviewing the changelog with the configuration you have provided, I think 
it comes from your http-check rules, due to a bug that has been fixed in 1.4.26 
(about HTTP keep-alived connections with http-check) :
http://www.haproxy.org/git?p=haproxy-1.4.git;a=commit;h=98739cba6281adeaf1db26be188970e4423b51fc

As a quick test, maybe you can disable keep-alive on your servers to verify 
this.


-- 
Cyril Bonté

[#GKN-729648]: ?完大奶人妻?穴俯身口爆射其一嘴

[Жалобы , сообщения о спаме]

zjf,

Ваша заявка была получена и один из наших консультантов работает над ответом на 
Ваш вопрос. Внизу указаны данные Вашей заявки. Пожалуйста, не стирайте номер 
заявки в строке темы.

Ticket ID: GKN-729648
Тема:?完大奶人妻?穴俯身口爆射其一嘴
Department: Жалобы, сообщения о спаме
Priority: Высокий
Status: Открыт

Вы можете проверить статус или ответить на эту заявку онлайн на: 
https://support.ukrnames.com/index.php?_m=tickets&_a=viewticket=289646
Пожалуйста, дайте нам знать, если Вам опять потребуется помощь, 

Ukrnames - служба поддержки клиентов

Re: Problem with health checking

[Cyril Bonté]

Hi John,


Le 07/08/2016 à 21:17, John Lanigan a écrit :

[...]
http-check expect status 200
http-check disable-on-404

server hostingapp2_5041 172.17.2.40:5041  check
server hostingapp3_5041 172.17.2.50:5041  check

[...]

If I access all four of those URLs with lynx to show the headers from
the command line on the haproxy server I get the same result from each
server, instantaneous response and HTTP 200 status.

[...]

But the haproxy stats page reports L7 timeout if we add in a check on
the new app setup.



Any ideas what I need to check next?

[...]

I’ve been running  haproxy 1.4.24 on centos 6.5 for over 2 years, load
balancing a pair of Oracle 11g app servers on Windows 2008r2.



Did you upgrade to the latest 1.4 to see if the issue remains ?
After reviewing the changelog with the configuration you have provided, 
I think it comes from your http-check rules, due to a bug that has been 
fixed in 1.4.26 (about HTTP keep-alived connections with http-check) :

http://www.haproxy.org/git?p=haproxy-1.4.git;a=commit;h=98739cba6281adeaf1db26be188970e4423b51fc

As a quick test, maybe you can disable keep-alive on your servers to 
verify this.



--
Cyril Bonté

RE: Problem with health checking

[John Lanigan]

Hi,

Some further info.

The two configs are below, old and new, the differences are minor:

listen Load-Balancer-oldapp
bind *:5041
mode http
balance roundrobin

stats enable
stats hide-version
stats refresh 20s
stats show-node
stats admin if TRUE


stick-table type ip size 1m expire 1h
stick on src

option httpclose
option forwardfor

option httpchk GET /forms/frmservlet?config=oldapp

http-check expect status 200
http-check disable-on-404

   server hostingapp2_5041 172.17.2.40:5041  check
server hostingapp3_5041 172.17.2.50:5041  check
option redispatch



listen Load-Balancer-newapp
bind *:5051
mode http
balance roundrobin

stats enable
stats hide-version
stats refresh 20s
stats show-node
stats admin if TRUE


stick-table type ip size 1m expire 1h
stick on src

option httpclose
option forwardfor

option httpchk GET /forms/frmservlet?config=newapp

http-check expect status 200
http-check disable-on-404

server sh1hostingapp4_5051 172.17.2.60:5051
server sh1hostingapp5_5051 172.17.2.70:5051

option redispatch


When I take the IP, port and path from those configs and combine them for 
testing I end up with four URLS

http://172.17.2.40:5041/forms/frmservlet?config=oldapp
http://172.17.2.50:5041/forms/frmservlet?config=oldapp
http://172.17.2.60:5051/forms/frmservlet?config=newapp
http://172.17.2.70:5051/forms/frmservlet?config=newapp

If I access all four of those URLs with lynx to show the headers from the 
command line on the haproxy server I get the same result from each server, 
instantaneous response and HTTP 200 status.


[root@HAProxy1 ~]# lynx -head -dump 
http://172.17.2.40:5041/forms/frmservlet?config=oldapp
HTTP/1.1 200 OK
Date: Sun, 07 Aug 2016 19:01:32 GMT
Server: Oracle-Application-Server-11g
Cache-Control: no-cache,no-store
Content-Length: 5496
X-ORACLE-DMS-ECID: 00ia1Oq3joKFw00Fzzw0w1Co001zZk
X-Powered-By: Servlet/2.5 JSP/2.1
Connection: close
Content-Type: text/html
Content-Language: en

[root@HAProxy1 ~]# lynx -head -dump 
http://172.17.2.70:5051/forms/frmservlet?config=newapp
HTTP/1.1 200 OK
Date: Sun, 07 Aug 2016 18:59:29 GMT
Server: Oracle-Application-Server-11g
Cache-Control: no-cache,no-store
Content-Length: 5505
X-ORACLE-DMS-ECID: 00ia1OihrRjDsXH6yvnZ6G0001mS004H^5
X-Powered-By: Servlet/2.5 JSP/2.1
Connection: close
Content-Type: text/html
Content-Language: en



But the haproxy stats page reports L7 timeout if we add in a check on the new 
app setup.

Any ideas what I need to check next?


Kind Regards,

John Lanigan
CORE | * +353 (0)25 41400   |  * 
john.lani...@coresoftware.ie|  ?   
www.coresoftware.ie

From: John Lanigan [mailto:john.lani...@coresoftware.ie]
Sent: Thursday 4 August 2016 22:55
To: haproxy@formilux.org
Subject: Problem with health checking

Hi,

I've been running  haproxy 1.4.24 on centos 6.5 for over 2 years, load 
balancing a pair of Oracle 11g app servers on Windows 2008r2.

It's worked perfectly the entire time.  We have recently built two new app 
servers, same version of Oracle 11g on Windows 2012R2.

For health checking we check for http status 200 on the homepage of the 
application.

For the new servers the health checking is failing.  We are getting a layer 7 
timeout.  However when I try and access the page using either curl or lynx it 
downloads instantly with status 200.

Any tips as to where I go from here in troubleshooting would be great.  I've 
checked and double checked the config and the only difference for this load 
balancer over the existing ones is the IP and port numbers.

Right now we are load balancing without health checking, but obviously that's 
not a solution.

Any suggestions would be great, thanks in advance

John

Re: Inform backend about https for http2 connections

[Lukas Tribus]

Hi,


Am 07.08.2016 um 13:35 schrieb Matthias Fechner:


I think the only possibilty whould then to define several backends on
different ports and define there the h2c or h2 in the frontend
configuration of nginx.


Yes, because otherwise you have a problem on the nginx configuration as 
well:
you can either configure a port with ssl/tls or not. HTTP/2 or not, the 
port is either encrypted or it isn't.






To check if for the TLS connection it is a h2 enabled client I can use:

acl http2 ssl_fc_alpn -i h2


This only works if you terminate SSL on haproxy itself. It doesn't work 
for a transparent TLS setup [1] . We don't have a ALPN fetcher for tcp 
mode currently (but it would be badly needed, imho).


But, I'm not sure why this would be necessary in your case. If the 
request comes in on port 443, you know its encrypted. If the request 
come in on port 80, the request is not encrypted. Just use the same 
logic on the backends as well.





Is there a similar check for the not TLS connection I can use?


h2c is not TLS, so the client doesn't connect to port 443, but port 80. 
So you have that information already on the proxy. But really no browser 
does this anyway.




Regards,
Lukas

[1] 
http://cbonte.github.io/haproxy-dconv/configuration-1.6.html#7.3.4-ssl_fc_alpn

Re: Inform backend about https for http2 connections

[Matthias Fechner]

Am 06.08.2016 um 15:12 schrieb Neil - HAProxy List:
>
> if you can have the app not specify the scheme for the css etc.  just use
>
> //site.com/path 
> or
> /path if it is on the same site
>

as I do not develop the apps I cannot do it.

The configuration how the return these paths are defined by the fastcgi
parameters passed.

I think the only possibilty whould then to define several backends on
different ports and define there the h2c or h2 in the frontend
configuration of nginx.

To check if for the TLS connection it is a h2 enabled client I can use:

acl http2 ssl_fc_alpn -i h2


Is there a similar check for the not TLS connection I can use?


Gruß
Matthias

-- 

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook

Re: Inform backend about https for http2 connections

[Matthias Fechner]

Am 06.08.2016 um 05:31 schrieb Igor Cicimov:
> Afaik, since http2 is by default tls encrypted just by specifying h2
> as protocol to the backend should be enough i guess.

this is not completely true. There is h2c which uses http2 without TLS.


Gruß
Matthias

-- 

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook

Re: [PATCH] DOC: minor typo fixes to improve HTML parsing by haproxy-dconv

[Willy Tarreau]

On Fri, Aug 05, 2016 at 05:15:20PM +0200, Olivier Doucet wrote:
> This must be backported to 1.6 and 1.5

applied to 1.7 for now (will backport later), thanks Olivier.

Willy