[Cohesive Networks] HA Proxy - Expiration notice

2016-06-10 Thread Cohesive Networks
Your listing "HA Proxy" in category VNS3 Plug-in System Partners expired on June 10, 2016. To renew your listing click the link below.
http://cohesive-networks.com/directory?action="">



Re: HTTP Keep Alive : Limit number of sessions in a connection

2016-06-10 Thread Manas Gupta
I found that this article
http://www.ateam-oracle.com/long-lived-tcp-connections-and-load-balancers/
explains the problem of 'rebalancing' long-lived tcp connections.

This ties in to when I first brought up the issue of intentionally
terminating valid http keep alive connections after a "X" number of
requests or time

I want the clients to re-establish the connection even if HAProxy was
not terminating.

Thanks


On Thu, Jun 9, 2016 at 8:15 AM, Manas Gupta  wrote:
> On Wed, Jun 8, 2016 at 10:44 PM, Willy Tarreau  wrote:
>> On Wed, Jun 08, 2016 at 10:00:04PM -0700, Manas Gupta wrote:
>>> >> So I have a component which issues a lot of requests over a keep-alive
>>> >> connection to HAProxy. In the middle there is a TCP Load Balancer
>>> >> (hardware) which only intercepts new tcp connection requests. Once the
>>> >> tcp connection is established, the client can send as many HTTP
>>> >> requests as it wants. For lack of a better term, it becomes sticky.
>>> >
>>> > What do you mean by "it becomes sticky" ? Just the fact that it sticks
>>> > to *this* haproxy server ? This seems logical if it works at the TCP
>>> > level. I'm seeing that you want to "fix" this, but how is it a problem
>>> > at all ? Most users would instead find this normal, and even desired.
>>> >
>>>
>>> You are correct, its not a problem.
>>>
>>> I am simply trying to figure out the best way for this :-
>>> Say I have an HAProxy server with several long running http-keep-alive
>>> connections. I want to send traffic away from this HAProxy server, but
>>> without dropping any connections.
>>
>> OK, initially I thought you meant "from this process" (during a process
>> replacement). But now I get it. But you normally also need to manipulate
>> health check results so that your HW load balancer stops sending new
>> connections to haproxy.
>>
>> At the moment, haproxy checks the frontend's stopped state to decide if it
>> needs to force to disable keep-alive on client connections. By the way that
>> makes me realize that we should also check for the "full" state to optimize
>> early release of client connections when the frontend is full. But we could
>> imagine having an extra "stopping" state that could be turned from the CLI
>> to have the exact same effect.
>>
>
> I am not sure I understand your last comment.
>
> As a side, is there some doc which explains everything I see when I
> run 'show sess'
>
> for example
>
> 0xfdf780: proto=tcpv4 src=10.193.248.156:51384 fe=ingress be=webs
> srv=web2 ts=08 age=2s calls=2
> rq[f=8848080h,i=0,an=2000h,rx=,wx=,ax=]
> rp[f=8040h,i=0,an=6h,rx=4m57s,wx=,ax=] s0=[7,8h,fd=1997,ex=]
> s1=[7,118h,fd=1998,ex=]exp=4m57s
>
>
>
>>> I can live with what's there for now. I was just wondering if
>>> keep-alive max HTTP directive could be implemented (it not already
>>> done) using a combination of settings or some stick table fudgery.
>>
>> I didn't think about stick tables but that makes me think that we have
>> variables (per-session and per-request). The per-session variables could
>> hold a request count. The only thing we're missing is an action to force
>> to disable keep-alive on the client side. I think the actions will be
>> taken too late after the decision was already taken during the request
>> but we could do it when processing the response.
>>
>> I think a few more thoughts should be given on this.
>>
>> Willy



Re: SNI healthcheck on backend?

2016-06-10 Thread Ray Cote
On Fri, Jun 10, 2016 at 12:50 PM, Willy Tarreau  wrote:

> Hi Ray,
>
> On Thu, Jun 09, 2016 at 01:49:02PM -0400, Ray Cote wrote:
> > On Thu, Jun 9, 2016 at 12:10 PM,  wrote:
> >
> > > http://discourse.haproxy.org/t/can-1-6-do-sni-on-backend/278/12
> > >
> >
> > I???ve been looking for an official place to post a request ticket for
> this
> > (I???m the originator of that thread).
> > Yes, it does seem that HAProxy 1.6 does not send the SNI header during
> the
> > health check.
> > Will make it a formal request if someone could point me towards the
> proper
> > channel for enhancement requests.
> > ???Ray
>
> This is the right place. There is no technical difficulty to implement
> this, it's more a problem of configuration : how do we want to configure
> this ? We have the same problem with the host header sent with HTTP checks,
> except that in HTTP it's easy to cheat. I think we'd need a check directive
> to specify the host name to send to the server (eg: check-host) that could
> be used for HTTP and for SNI. This is just an idea, maybe someone has a
> better idea.
>

Hi Willy:

Can the Health Check be driven by the SNI parameter in the server line?

When configuring several backend servers, you’d likely need a
different SNI for each server, and also have servers for which SNI is not
configured.

If SNI is declared for the server itself, I’d want to use the same SNI value
for the health check. Don’t think there would be a situation where a
different SNI would be used for the health check since technically it
would be checking a different service.

—Ray
(not an HAProxy expert by any stretch of the imagination—simply loving how
many problems it solves)


-- 
Raymond Cote, President
voice: +1.603.924.6079 email: rgac...@appropriatesolutions.com skype:
ray.cote


Re: Invalid 301 redirect target URL on haproxy.org

2016-06-10 Thread Willy Tarreau
Hi Holger,

On Thu, Jun 09, 2016 at 02:38:38PM +0200, Holger Just wrote:
> Hi,
> 
> when navigating to a directory of the downloads section on haproxy.org
> while omitting the trailing slash, e.g.
> 
> http://www.haproxy.org/download/1.5
> 
> the response is a 301 redirect to
> 
> http://www.haproxy.org:81/download/1.5/
> 
> which I assume is generated by the backend Apache by adding its internal
> port to the generated URL. This could potentially be solved by adding
> this config rule in the frontend HAproxy to drop any explicit port
> number from the redirects (or any other way you see fit :)
> 
> http-response replace-header Location ^(https?://[^:]*):\d+/(.*) \1/\2

Ah thanks, indeed a fe times in the past some people have reported
this anomaly but I didn't know where it originated from. I'm going
to apply your rule as is, it looks fine!

Thanks,
Willy



Re: possible minor memory leak in ssl_get_dh_1024

2016-06-10 Thread Willy Tarreau
Hi Roberto,

On Wed, Jun 08, 2016 at 09:22:52PM +, Roberto Guimaraes wrote:
> Roberto Guimaraes  writes:
> 
> > 
> > seems like set_tmp_dh() performs its own allocation. So, it should be 
> > OK to dh_free immediately after calling the setter.
> > Not sure the intention was to reuse the allocated local_dh_1024, 
> > but that's not being done either.
> > 
> > index 5200069..7c17c9a 100644
> > --- a/src/ssl_sock.c
> > +++ b/src/ssl_sock.c
> >  -1639,6 +1639,8  int ssl_sock_load_dh_params
> (SSL_CTX *ctx,
> > const char *file
> > )
> > goto end;
> > 
> > SSL_CTX_set_tmp_dh(ctx, local_dh_1024);
> > +   free(local_dh_1024);
> > +   local_dh_1024 = NULL;
> > }
> > else {
> > SSL_CTX_set_tmp_dh_callback(ctx, ssl_get_tmp_dh);
> > 
> > thanks,
> > roberto
> > 
> > 
> 
> darn, make it DH_free()...
> 
> index 5200069..37471b6 100644
> --- a/src/ssl_sock.c
> +++ b/src/ssl_sock.c
> @@ -1639,6 +1639,8 @@ int ssl_sock_load_dh_params(SSL_CTX *ctx,
> const char *file
> )
>   goto end;
> 
>   SSL_CTX_set_tmp_dh(ctx, local_dh_1024);
> + DH_free(local_dh_1024);
> + local_dh_1024 = NULL;
>   }
>   else {
>   SSL_CTX_set_tmp_dh_callback(ctx, ssl_get_tmp_dh);

Thanks. You're using git, so please check the CONTRIBUTING file to see
how to send your patch, you'll make both your work and ours easier :-)

Cheers,
Willy



Re: SNI healthcheck on backend?

2016-06-10 Thread Willy Tarreau
Hi Ray,

On Thu, Jun 09, 2016 at 01:49:02PM -0400, Ray Cote wrote:
> On Thu, Jun 9, 2016 at 12:10 PM,  wrote:
> 
> > http://discourse.haproxy.org/t/can-1-6-do-sni-on-backend/278/12
> >
> 
> I???ve been looking for an official place to post a request ticket for this
> (I???m the originator of that thread).
> Yes, it does seem that HAProxy 1.6 does not send the SNI header during the
> health check.
> Will make it a formal request if someone could point me towards the proper
> channel for enhancement requests.
> ???Ray

This is the right place. There is no technical difficulty to implement
this, it's more a problem of configuration : how do we want to configure
this ? We have the same problem with the host header sent with HTTP checks,
except that in HTTP it's easy to cheat. I think we'd need a check directive
to specify the host name to send to the server (eg: check-host) that could
be used for HTTP and for SNI. This is just an idea, maybe someone has a
better idea.

Regards,
Willy



unsubscribe

2016-06-10 Thread bala bhaskar




Re: 100% cpu , epoll_wait()

2016-06-10 Thread Willy Tarreau
Hi Holger,

On Fri, Jun 10, 2016 at 04:32:55PM +0200, Holger Just wrote:
> Hi Willy et al.,
> 
> > Thank you for this report, it helps. How often does it happen, and/or after
> > how long on average after you start it ? What's your workload ? Do you use
> > SSL, compression, TCP and/or HTTP mode, peers synchronization, etc ?
> 
> Yesterday, we upgraded from 1.5.14 to 1.5.18 and now observed exactly
> this issue in production. After rolling back to 1.5.14, it didn't occur
> anymore.
> 
> We have mostly http traffic, little TCP with about 100-200 req/s, about
> 2000 concurrent connections over all. About all traffic is SSL
> terminated. We use no peer synchronization and no compression.
> 
> An strace on the process reveals this (with most of the calls being
> epoll_wait):
> 
> [...]
> epoll_wait(0, {}, 200, 0)   = 0
> epoll_wait(0, {}, 200, 0)   = 0
> epoll_wait(0, {}, 200, 0)   = 0
> epoll_wait(0, {}, 200, 0)   = 0
> epoll_wait(0, {}, 200, 0)   = 0
> epoll_wait(0, {}, 200, 0)   = 0
> epoll_wait(0, {}, 200, 0)   = 0
> epoll_wait(0, {{EPOLLIN, {u32=796, u64=796}}}, 200, 0) = 1
> read(796, "
> \357\275Y\231\275'b\5\216#\33\220\337'\370\312\215sG4\316\275\277y-%\v\v\211\331\342"...,
> 5872) = 1452
> read(796, 0x9fa26ec, 4420)  = -1 EAGAIN (Resource
> temporarily unavailable)
> epoll_wait(0, {}, 200, 0)   = 0
> epoll_wait(0, {}, 200, 0)   = 0
> epoll_wait(0, {}, 200, 0)   = 0
> epoll_wait(0, {}, 200, 0)   = 0
> [...]

Thank you for the report. I'll inspect the SSL part just in case I'd
miss something. Don't take risks in your production of course.

Best regards,
Willy




Re: 100% cpu , epoll_wait()

2016-06-10 Thread Holger Just
Hi Willy et al.,

> Thank you for this report, it helps. How often does it happen, and/or after
> how long on average after you start it ? What's your workload ? Do you use
> SSL, compression, TCP and/or HTTP mode, peers synchronization, etc ?

Yesterday, we upgraded from 1.5.14 to 1.5.18 and now observed exactly
this issue in production. After rolling back to 1.5.14, it didn't occur
anymore.

We have mostly http traffic, little TCP with about 100-200 req/s, about
2000 concurrent connections over all. About all traffic is SSL
terminated. We use no peer synchronization and no compression.

An strace on the process reveals this (with most of the calls being
epoll_wait):

[...]
epoll_wait(0, {}, 200, 0)   = 0
epoll_wait(0, {}, 200, 0)   = 0
epoll_wait(0, {}, 200, 0)   = 0
epoll_wait(0, {}, 200, 0)   = 0
epoll_wait(0, {}, 200, 0)   = 0
epoll_wait(0, {}, 200, 0)   = 0
epoll_wait(0, {}, 200, 0)   = 0
epoll_wait(0, {{EPOLLIN, {u32=796, u64=796}}}, 200, 0) = 1
read(796, "
\357\275Y\231\275'b\5\216#\33\220\337'\370\312\215sG4\316\275\277y-%\v\v\211\331\342"...,
5872) = 1452
read(796, 0x9fa26ec, 4420)  = -1 EAGAIN (Resource
temporarily unavailable)
epoll_wait(0, {}, 200, 0)   = 0
epoll_wait(0, {}, 200, 0)   = 0
epoll_wait(0, {}, 200, 0)   = 0
epoll_wait(0, {}, 200, 0)   = 0
[...]

The strace was done after reloading using -sf. However, the process was
at 100% load even before the reload.

Since we kept the process running after the reload (it still holds some
connections), I was able to run a second strace, about half an hour
later which now show a different behavior:

[...]
epoll_wait(0, {}, 200, 4)   = 0
epoll_wait(0, {}, 200, 7)   = 0
epoll_wait(0, {}, 200, 3)   = 0
epoll_wait(0, {}, 200, 6)   = 0
epoll_wait(0, {}, 200, 3)   = 0
epoll_wait(0, {}, 200, 3)   = 0
epoll_wait(0, {}, 200, 10)  = 0
epoll_wait(0, {}, 200, 3)   = 0
epoll_wait(0, {}, 200, 27)  = 0
epoll_wait(0, {}, 200, 6)   = 0
epoll_wait(0, {}, 200, 4)   = 0
[...]

The CPU load taken by the process is now back to more or less idle load,
without further intervention on the process.

`haproxy -vv` of the process running into the busy-loop shows

HA-Proxy version 1.5.18 2016/05/10
Copyright 2000-2016 Willy Tarreau 

Build options :
  TARGET  = linux2628
  CPU = generic
  CC  = gcc
  CFLAGS  = -m64 -march=x86-64 -O2 -g -fno-strict-aliasing
  OPTIONS = USE_GETADDRINFO=1 USE_ZLIB=1 USE_OPENSSL=1 USE_PCRE=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.1t  3 May 2016
Running on OpenSSL version : OpenSSL 1.0.1t  3 May 2016
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports prefer-server-ciphers : yes
Built with PCRE version : 8.35 2014-04-04
PCRE library supports JIT : no (USE_PCRE_JIT not set)
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.

Unfortunately, since we have rolled back production to 1.5.14, we have
now little possibility to reproduce this anymore. The process which
shows the behavior is still running for the time being though.

Regards,
Holger



Re: ACL & frontend : random behavior / haproxy 1.5.18-1ppp1

2016-06-10 Thread Kevin Maziere
2016-06-10 12:50 GMT+02:00 Igor Cicimov :

>
>
> On Fri, Jun 10, 2016 at 7:39 PM, Kevin Maziere 
> wrote:
>
>> Hi
>> (in english this time,sorry for the noise)
>>
>> I can't explain a strange behavior of haproxy when using simple acl which
>> redirect to a specific backend.
>> The frontend in which the ACL and the specific backend is set has also a
>> default frontend.
>>
>> If I curl/wget/chrome/firefox/opera... on the frontend IP with a hostname
>> which match the ACL, sometime the reply is made by the wanted backend,
>> sometime by the default one,randomly.
>>
>
> And the request you are testing with is???
>
>
>> No error logs
>> If I remove the default backend line, all request are sent to the
>> specific backend.
>>
>> Any help ?
>>
>> Tanks
>>
>> Kévin
>>
>>
>> Here is my conf :
>>
>>  global
>> log 127.0.0.1   local0
>> log 127.0.0.1   local1 notice
>> maxconn x
>> #debug
>> #quiet
>> #spread-checks
>> user haproxy
>> group haproxy
>> defaults
>> log global
>> modehttp
>> #option  dontlognull
>> maxconn 
>> timeout server  xxm
>> timeout connect xxm
>> timeout client  xxm
>> option redispatch
>> retries 5
>> option  httplog
>> option forwardfor
>> timeout http-keep-alive xm
>> timeout http-request xm
>>
>>
>> frontend 10.0.01-80
>> bind 10.0.0.1:80
>> reqadd X-Forwarded-Proto:\ http
>> option http-server-close
>>
>> acl host_beg_ttfr  hdr_beg(Host) tt-fra29-2-france
>> use_backend tt-france-fra29-2 if host_beg_ttfr
>>
>> default_backend ipv4-fr
>>
>> backend tt-france-fra29-2
>> reqirep ^Host:\  tt-france-fra29-2-france.subd.fr.mondomainamoi.fr
>> Host:\ fra29-2-fra.md.bbb.loca
>> server labas 192.168.21.5:80
>>
>> backend ipv4-fr
>> balance roundrobin
>> option httpchk GET /
>> server fr-icietla 192.168.22.4:8080 weight 1 check inter 5000 rise 2
>> fall 5
>>
>
>
>
> --
> Igor Cicimov | DevOps
>
>
> p. +61 (0) 433 078 728
> e. ig...@encompasscorporation.com 
> w*.* www.encompasscorporation.com
> a. Level 4, 65 York Street, Sydney 2000
>

curl -v  tt-france-fra29-2-france.subd.fr.mondomainamoi.fr where
tt-france-fra29-2-france.subd.fr.mondomainamoi.fr point to 10.0.0.1


balance url_param (when encoded)

2016-06-10 Thread Evgeniy Sudyr
Hi all,

we do have API which we need to load balance between two servers

I want balance by url_param value as described there in documentation
https://cbonte.github.io/haproxy-dconv/configuration-1.7.html#4.2-balance%20url_param

but want ask how to deal if param name can be encoded example:

http://myserver.com/test?[myparam]=1
http://myserver.com/test?%5Bmyparam%5D=1

Can I make it working somehow with one backend?

acl api -i url_dec [myparam]=

use backend api if api

backend api
balance url_param [myparam]
server  server0 10.0.0.1:80 check weight 100 maxconn 500
server  server1 10.0.0.2:80 check weight 100 maxconn 500


-- 
--
With regards,
Eugene Sudyr



Re: ACL & frontend : random behavior / haproxy 1.5.18-1ppp1

2016-06-10 Thread Igor Cicimov
On Fri, Jun 10, 2016 at 7:39 PM, Kevin Maziere 
wrote:

> Hi
> (in english this time,sorry for the noise)
>
> I can't explain a strange behavior of haproxy when using simple acl which
> redirect to a specific backend.
> The frontend in which the ACL and the specific backend is set has also a
> default frontend.
>
> If I curl/wget/chrome/firefox/opera... on the frontend IP with a hostname
> which match the ACL, sometime the reply is made by the wanted backend,
> sometime by the default one,randomly.
>

And the request you are testing with is???


> No error logs
> If I remove the default backend line, all request are sent to the specific
> backend.
>
> Any help ?
>
> Tanks
>
> Kévin
>
>
> Here is my conf :
>
>  global
> log 127.0.0.1   local0
> log 127.0.0.1   local1 notice
> maxconn x
> #debug
> #quiet
> #spread-checks
> user haproxy
> group haproxy
> defaults
> log global
> modehttp
> #option  dontlognull
> maxconn 
> timeout server  xxm
> timeout connect xxm
> timeout client  xxm
> option redispatch
> retries 5
> option  httplog
> option forwardfor
> timeout http-keep-alive xm
> timeout http-request xm
>
>
> frontend 10.0.01-80
> bind 10.0.0.1:80
> reqadd X-Forwarded-Proto:\ http
> option http-server-close
>
> acl host_beg_ttfr  hdr_beg(Host) tt-fra29-2-france
> use_backend tt-france-fra29-2 if host_beg_ttfr
>
> default_backend ipv4-fr
>
> backend tt-france-fra29-2
> reqirep ^Host:\  tt-france-fra29-2-france.subd.fr.mondomainamoi.fr
> Host:\ fra29-2-fra.md.bbb.loca
> server labas 192.168.21.5:80
>
> backend ipv4-fr
> balance roundrobin
> option httpchk GET /
> server fr-icietla 192.168.22.4:8080 weight 1 check inter 5000 rise 2
> fall 5
>



-- 
Igor Cicimov | DevOps


p. +61 (0) 433 078 728
e. ig...@encompasscorporation.com 
w*.* www.encompasscorporation.com
a. Level 4, 65 York Street, Sydney 2000


unsubscribe

2016-06-10 Thread Mike MacCana



ACL & frontend : random behavior / haproxy 1.5.18-1ppp1

2016-06-10 Thread Kevin Maziere
Hi
(in english this time,sorry for the noise)

I can't explain a strange behavior of haproxy when using simple acl which
redirect to a specific backend.
The frontend in which the ACL and the specific backend is set has also a
default frontend.

If I curl/wget/chrome/firefox/opera... on the frontend IP with a hostname
which match the ACL, sometime the reply is made by the wanted backend,
sometime by the default one,randomly.
No error logs
If I remove the default backend line, all request are sent to the specific
backend.

Any help ?

Tanks

Kévin


Here is my conf :

 global
log 127.0.0.1   local0
log 127.0.0.1   local1 notice
maxconn x
#debug
#quiet
#spread-checks
user haproxy
group haproxy
defaults
log global
modehttp
#option  dontlognull
maxconn 
timeout server  xxm
timeout connect xxm
timeout client  xxm
option redispatch
retries 5
option  httplog
option forwardfor
timeout http-keep-alive xm
timeout http-request xm


frontend 10.0.01-80
bind 10.0.0.1:80
reqadd X-Forwarded-Proto:\ http
option http-server-close

acl host_beg_ttfr  hdr_beg(Host) tt-fra29-2-france
use_backend tt-france-fra29-2 if host_beg_ttfr

default_backend ipv4-fr

backend tt-france-fra29-2
reqirep ^Host:\  tt-france-fra29-2-france.subd.fr.mondomainamoi.fr
Host:\ fra29-2-fra.md.bbb.loca
server labas 192.168.21.5:80

backend ipv4-fr
balance roundrobin
option httpchk GET /
server fr-icietla 192.168.22.4:8080 weight 1 check inter 5000 rise 2
fall 5


Regarding settingup HAProxy for Jmeter servers

2016-06-10 Thread Rakesh Shetty
Hi,

Could you please let me know whether it is possible to set up HAProxy Load
balancer for two Jmeter servers?.

Please share if you have relevant documents/links.

Thanks,
Rakesh