how to disable/enable TCP_NODELAY soket option in TCP mode?
I can`t find in haproxy documentation any information about Nagle`s algorithm or TCP_NODELAY option Thanks -- ___ С уважением, Евгений С. Татаркин
RE: Keep-alive and websocket connections
Hi, Thanks for your suggestion, Lukas. For my own understanding, are you saying that there is no difference between having http-keep-alive and having http-server-close to a backend server once websocket connection to that server is establish, and both settings allow for establishing websocket connection perfectly. Yes, thats what I'm saying. So is there any advantage of having http-keep-alive to a websocket backend? It doesn't make any difference if this is a pure websocket backend, because the session is always upgraded to tcp mode after the first transaction. If the traffic is mixed, then http-keep-alive has obvious advantages for the non-websocket traffic. Regards, Lukas
Re: how to disable/enable TCP_NODELAY soket option in TCP mode?
On 7 February 2014 08:29, Татаркин Евгений tatarkin@gmail.com wrote: I can`t find in haproxy documentation any information about Nagle`s algorithm or TCP_NODELAY option To quote http://marc.info/?l=haproxym=132173719731861w=2, which I discovered via searching http://marc.info/?l=haproxyw=2r=1s=nagleq=b: 'the http-no-delay option [...] forces TCP_NODELAY on every outgoing segment and prevents the system from merging them.' Willy warns, however: Doing so can increase load time on high latency networks due to output window being filled earlier with incomplete segments and due to the receiver having to ACK every segment, which can lead to uplink saturation on asymmetric links (ADSL, HSDPA). HTH, J
Cooperation Suggestion - haproxy
Dear Editor, My name is Jenna and I would be interested in submitting a guest post or perhaps a link to your website: http://haproxy.1wt.eu . I wasn't sure who was the best person to contact, so perhaps you could guide me to the right path. I work for Maytech https://www.maytech.net/ who provide global secure data transfer solutions. We have recently received the rare ISO 27001 security accreditation. We would be really interested in cooperation with your website. Perhaps e could provide some information related to the ISO accreditation or work together to create a post worth publishing. Does this sound like something you'd be interested in? Kindest Regards, Jenna Loman Marketing Manager cid:41C8ACCA-090F-44FA-A50A-17659490C273 Accelerated global file sharing for 800 customers worldwide The contents of the e-mail and any transmitted files are confidential and intended solely for the use of the individual or entity to whom they are addressed. Maytech Communications Ltd hereby exclude any warranty and any liability as to the quality or accuracy of the contents of this email and any attached transmitted files. If you are not the intended recipient be advised that you have received this email in error and that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. If you have received this email in error please notify supp...@maytech.net. image001.png
RE: 'packet of death' in 1.5-dev21.x86_64.el6_4
Hi, Not a problem ... our Head of IS did a detailed write up on our investigation process and findings at his blog if you are interested: http://blog.tinola.com/?e=36 Thanks, thats really interesting and very detailed. Someone from RedHat really should take a look at this. Most likely EAI_NODATA is not defined in the libc, thats why upgrading libc helps and upgrading libkrb5 doesn't. So the real problem is that getaddrinfo() returns an error code unknown to the libc (other applications than libkrb5 may suffer from problems as well; although they probably don't abort()). Looks like EAI_NODATA is deprecated, and its already removed from freebsd for example, in favor of EAI_NONAME [1]. As for the workaround: you should be able to disable the kerberos ciphers in HAproxy configuration, so that you can continue to run it in chroot. Or maybe compiling with -DEAI_NODATA=EAI_NONAME would help? What are those ciphers anyway (openssl ciphers -v 'LOW')? I don't seem to have them here on ubuntu ... [1] http://krbdev.mit.edu/rt/Ticket/History.html?id=5518
Re: 'packet of death' in 1.5-dev21.x86_64.el6_4
On Fri, Feb 07, 2014 at 07:23:42PM +0100, Lukas Tribus wrote: Hi, Not a problem ... our Head of IS did a detailed write up on our investigation process and findings at his blog if you are interested: http://blog.tinola.com/?e=36 Thanks, thats really interesting and very detailed. Indeed. Someone from RedHat really should take a look at this. Most likely EAI_NODATA is not defined in the libc, thats why upgrading libc helps and upgrading libkrb5 doesn't. So the real problem is that getaddrinfo() returns an error code unknown to the libc (other applications than libkrb5 may suffer from problems as well; although they probably don't abort()). I've passed along the information to the appropriate people. Interesting that it is fixed in Centos 6.5, would be great to know how it was fixed. I took a quick look at krb5-libs and glibc and nothing jumped out at me. Ryan Looks like EAI_NODATA is deprecated, and its already removed from freebsd for example, in favor of EAI_NONAME [1]. As for the workaround: you should be able to disable the kerberos ciphers in HAproxy configuration, so that you can continue to run it in chroot. Or maybe compiling with -DEAI_NODATA=EAI_NONAME would help? What are those ciphers anyway (openssl ciphers -v 'LOW')? I don't seem to have them here on ubuntu ... [1] http://krbdev.mit.edu/rt/Ticket/History.html?id=5518
[PATCH] MINOR Add ability to externalize health checks [Was: Externalizing health checks]
Hello, I apologize for my persistence and realize that everyone if busy with getting 1.5 out of the door. I have no expectations on that front for the patch included here. However any feedback is welcome. I went thru some of the submitted patches and saw one by Simon Horman to use an external process after I made this change and will revisit that again. I re-did my implementation, and this time I am submitting it as a patch for consideration. I am posting the commit message that explains the change. = We add new directives to the http-check keyword The server option is used to specify an external health checking server to use for health checks. Example: http-check server ipv4|ipv6 The info option is used to specify a http header to communicate information about the server being checked to the external health checking server Example: http-check info [header http-header] The default value of the header is 'X-Check-Info' This option is independent of the server directive. When used includes a http header in the health check request of the form http-header: value Finally, we add to the server directive a 'info' option. This value assigned to this option is passed to the external health checking server. Example: server id addr [info value] Putting it all togeather backend bck1 mode http # the host header works but wasn't the intent option httpchk GET /health HTTP/1.1\r\nHost:\ www.hst1.com # specify a server to use for the check http-check server chksrv1.dc.hst1.com # request for info about the server using the default host header # the following 2 lines are equivalent # http-check info http-check info X-Check-Info # pass in the info using the default # the following 2 lines are equivalent # server a1 a1.dc.hst1.com:80 weight 20 maxconn 5 check inter 2s server a1 a1.dc.hst1.com:80 weight 20 maxconn 5 check inter 2s info a1 # this is probably a better alternative server a1 a1.dc.hst1.com:80 weight 20 maxconn 5 check inter 2s info a1.dc.hst1.com = This implementation can also be used for http health checks when running in tcp mode providing a potential alternative to implementing health checks for tcp mode deployments not directly available in haproxy, also allowing for more advanced health check beyond a hello message. Following is a config that I used to test this global maxconn 10 defaults modetcp clitimeout 30m srvtimeout 30m contimeout 4s backend myblog option httpchk GET /_health.php HTTP/1.1 http-check server bhaskar-dev:80 http-check info server b1 blackmagic.tumblr.com:80 weight 20 maxconn 5 check inter 2s info blackmagic.tumblr.com frontend myblogfrontend bind *:9080 default_backend myblog Thanks Bhaskar On Thu, Feb 6, 2014 at 2:45 PM, Bhaskar Maddala madda...@gmail.com wrote: Hello, Since I did not get any responses on this, I decided to try motivating a reponse by attempting an implementation. I am attaching a patch that does this. Admittedly this patch is an iteration and I am not submitting it for anything more than receiving feedback, on the requirement, alternative ideas and the implementation. Following is an explanation I added an option httpchksrv which takes an ipv4/6 address (external health checker) and an option http header. The http header is used to communicate to the health check server the backend server to check. option httpchk GET /_health.php HTTP/1.1 option httpchksrvipv4|ipv6 [header http-header-name=X-Check-For] Next, I added a header-value specification to the server definition server a1 magic.tumblr.com:80 weight 20 maxconn 5 check inter 2s header-value magic.tumblr.com the header-value is used for the http-header-name specified in httpchksrv Here is an example of the health check request GET /_health.php HTTP/1.1 X-Check-For: magic.tumblr.com The default value of header-value is the server id, in this case 'a1' The following is a little abstract and describes how health checks can be cached using this change, please bear with my attempts to describe it, these may be in-adequate. Please take this for what it is, broad strokes of an idea. I am not in any way advocating for this deployment. Going back to my original motivation excessive health checks due to increasing proxy and web application deployment, here is a description of how I can solve it using this implementation. On haproxy I define 2 frontend, one on port 80 and one on port 6777. The httpchksrv specification is used to direct health checks back to haproxy on port 6777. With haproxy in http mode option httpchksrv127.0.0.1:6777 Each server specification
Re: [Patch V2 1/1] [MINOR] Enhancement to stats page to provide information of last session time.
Hi Bhaskar, On Wed, Feb 05, 2014 at 12:10:09PM -0500, Bhaskar Maddala wrote: Hello, Resubmitting the patch with changed to address concerns from previous attempt Updates from previous submission (a) using unsigned long for last session time stamp instead of timeval struct (b) avoiding tv_now and using now Thank you! For the CSV stats, I'd rather report the real raw number of seconds instead of the human time, since CSV is made for monitoring tools. If you have no objection, I'll make this minor change and merge it. Thanks, Willy
Re: [Patch V2 1/1] [MINOR] Enhancement to stats page to provide information of last session time.
Sorry that was my mistake. I didn't not check how some of the other stats were done. Please make the change. Thank you On Feb 7, 2014 6:52 PM, Willy Tarreau w...@1wt.eu wrote: Hi Bhaskar, On Wed, Feb 05, 2014 at 12:10:09PM -0500, Bhaskar Maddala wrote: Hello, Resubmitting the patch with changed to address concerns from previous attempt Updates from previous submission (a) using unsigned long for last session time stamp instead of timeval struct (b) avoiding tv_now and using now Thank you! For the CSV stats, I'd rather report the real raw number of seconds instead of the human time, since CSV is made for monitoring tools. If you have no objection, I'll make this minor change and merge it. Thanks, Willy
Re: [PATCH] MINOR Add ability to externalize health checks [Was: Externalizing health checks]
Hi Bhaskar, On Fri, Feb 07, 2014 at 06:33:10PM -0500, Bhaskar Maddala wrote: Hello, I apologize for my persistence and realize that everyone if busy with getting 1.5 out of the door. I have no expectations on that front for the patch included here. However any feedback is welcome. I went thru some of the submitted patches and saw one by Simon Horman to use an external process after I made this change and will revisit that again. I re-did my implementation, and this time I am submitting it as a patch for consideration. I am posting the commit message that explains the change. This is interesting. Today we had a discussion with Baptiste about how to make http checks work more like tcp checks (ie: have sequences of multiple checks) and we first spotted the need to be able to specify *some* common information (eg: some headers, etc) and some server-specific information. So between what you proposed and this discussion, we're starting to see some pieces that start to make the puzzle. In my opinion, we'd have to cover the ability to perform multiple requests to a server, by forcing or not an address (eg: http-check connect), by passing headers with a value from the server, or by passing raw headers, by passing cookies from responses to requests when using the same host header (useful to authenticate to a server), and possibly some other stuff. I think it's too early to decide on an implementation, but we could possibly first try to define a roadmap so that once we know what we want for the long term, we can start with a subset which will remain compatible with future versions (for example we don't need to support cookies right now). I think that for your current needs, we'd need at least a check-name directive on the servers to force the server name, which would default to the server's name in the configuration, and which would automatically be sent along with the Host header if some http-check directive is set (eg: http-check set-host with no argument). The other http-check rules were made to be reusable, and I think they will be. We just need to complete them. I don't think this is something we should merge before 1.5-final, but I do think that we'll quickly be able to test it in 1.6-dev and get enough feedback so that at one point if we trust the feature enough and it requires few changes, we'll be able to backport it into 1.5. = We add new directives to the http-check keyword The server option is used to specify an external health checking server to use for health checks. Example: http-check server ipv4|ipv6 Please take a look at the tcp-check connect directive in the most recent snapshot. By default it just connects. You can specify a port (reusing the server's address) and we'll soon support an address. If the directive is not there, the check is sent to normal server's addr:port. We should try to standardize these things as much as possible so that people don't confuse them as we do between tcp-request and http-request which don't use the exact same actions for the same things (eg: deny vs reject). I'm even wondering whether we should not use a special send directive for http-check to indicate when to send versus when to prepare things. But that could be a bit awkward and confusing. Just thinking loud... Cheers, Willy
Re: [Patch V2 1/1] [MINOR] Enhancement to stats page to provide information of last session time.
On Fri, Feb 07, 2014 at 07:07:46PM -0500, Bhaskar Maddala wrote: Sorry that was my mistake. I didn't not check how some of the other stats were done. Please make the change. Great. Done, pushed and deployed : http://demo.1wt.eu/ I had to add the empty field also on the listener stats which are not always enabled but which are on this page. It made me realize that we could possibly do exactly the same with them : having per-listener and per-frontend last accept could be useful to detect the ones which are never used in some environments. For example it can tell you that a DNS change was correctly propagated or that your clients have migrated to the new service you wanted them to migrate to. Thanks! Willy
Re: [PATCH] MINOR Add ability to externalize health checks [Was: Externalizing health checks]
Thanks for your reply Willy I think that for your current needs, we'd need at least a check-name directive on the servers to force the server name, which would default to the server's name in the configuration, and which would automatically be sent along with the Host header if some http-check directive is set (eg: http-check set-host with no argument). The 'info' parameter in the server directive serves this purpose for me. I left it to the user to specify any identifying information that would enable the external server to identify the host to be health checked. I came about this largely due to a quirk in the existing implementation of health checks (1.4 version in production) that we use. When using the form below option httpchk method uri version you can specify for the version field HTTP\ 1.1\r\nHost: myhost.com\r\nX-Custom-Header: blah we have used this feature/quirk to specify a common host header for all servers. The servers do not respond to health checks in the absence of a specific Host header. I would not be surprised if others have noticed this behavior and likewise exploited it, leading me to present an option to configure an info header name. There is no limitation on using Host as the header name with the info parameter, but we may not do the same. In my opinion, we'd have to cover the ability to perform multiple requests to a server, by forcing or not an address (eg: http-check connect), by passing headers with a value from the server, or by passing raw headers, by passing cookies from responses to requests when using the same host header (useful to authenticate to a server), and possibly some other stuff. Broadly I did this change as I did, to have haproxy only speak http for health checking and leaving it to a external system to do the health check. Looking ahead the external health checking implementation in my environment will query infrastructure specific information from Collins i.e. information that is not captured in any request/response from/to haproxy. Having haproxy do health checks using an external http server seemed like a viable option as it leaves me with flexibility to implement a custom health check. I don't think this is something we should merge before 1.5-final, but I do think that we'll quickly be able to test it in 1.6-dev and get enough feedback so that at one point if we trust the feature enough and it requires few changes, we'll be able to backport it into 1.5. No worries, we can certainly proceed with this patch while a more encompassing solution is implement. -Bhaskar On Fri, Feb 7, 2014 at 7:08 PM, Willy Tarreau w...@1wt.eu wrote: Hi Bhaskar, On Fri, Feb 07, 2014 at 06:33:10PM -0500, Bhaskar Maddala wrote: Hello, I apologize for my persistence and realize that everyone if busy with getting 1.5 out of the door. I have no expectations on that front for the patch included here. However any feedback is welcome. I went thru some of the submitted patches and saw one by Simon Horman to use an external process after I made this change and will revisit that again. I re-did my implementation, and this time I am submitting it as a patch for consideration. I am posting the commit message that explains the change. This is interesting. Today we had a discussion with Baptiste about how to make http checks work more like tcp checks (ie: have sequences of multiple checks) and we first spotted the need to be able to specify *some* common information (eg: some headers, etc) and some server-specific information. So between what you proposed and this discussion, we're starting to see some pieces that start to make the puzzle. In my opinion, we'd have to cover the ability to perform multiple requests to a server, by forcing or not an address (eg: http-check connect), by passing headers with a value from the server, or by passing raw headers, by passing cookies from responses to requests when using the same host header (useful to authenticate to a server), and possibly some other stuff. I think it's too early to decide on an implementation, but we could possibly first try to define a roadmap so that once we know what we want for the long term, we can start with a subset which will remain compatible with future versions (for example we don't need to support cookies right now). I think that for your current needs, we'd need at least a check-name directive on the servers to force the server name, which would default to the server's name in the configuration, and which would automatically be sent along with the Host header if some http-check directive is set (eg: http-check set-host with no argument). The other http-check rules were made to be reusable, and I think they will be. We just need to complete them. I don't think this is something we should merge before 1.5-final, but I do think that we'll quickly be able to test it in 1.6-dev and get enough feedback so that at one point if we trust the feature
