RE: Track headers with tcp-request in listen only work with if HTTP
Hello,
I reply to myself.
I think that is because the tcp-request need a condition for doing the track.
Tranks,
Ricardo F
From: ri...@hotmail.com
To: haproxy@formilux.org
Subject: Track headers with tcp-request in listen only work with if HTTP
Date: Thu, 22 Aug 2013 13:03:32 +0200
Hello,
I have been testing the connection tracking in the frontend based on headers,
but it only work if the if HTTP option is set:
tcp-request inspect-delay 10s
tcp-request content track-sc0 hdr(x-forwarded-for,-1) if HTTP
Without this option, the table doesn't fill, the connections aren't tracked.
As is shown in the documentation, with tcp-request is possible to match layer
7 conditions, but i don't know why is neccesary the if HTTP condition.
This is a sample testing code:
global
maxconn 1000
log 127.0.0.1 local5 info err
stats socket /var/run/haproxy.sock mode 0600 level admin
pidfile /var/run/haproxy.pid
defaults
mode http
log global
retries 3
option redispatch
timeout contimeout 5000
timeout client 5000
timeout srvtimeout 5000
listen proxy-http *:80
mode http
option httplog
stats enable
option http-server-close
balance roundrobin
capture request header x-forwarded-for len 15
stick-table type ip size 200k expire 60m store gpc0
tcp-request inspect-delay 10s
tcp-request content track-sc0 hdr_ip(x-forwarded-for,1) if HTTP
http-request deny if { sc1_get_gpc0 eq 0 }
The version is HA-Proxy 1.5-dev19 2013/06/17
Thanks,
RicardoF
RE: How to redispatch a request after queue timeout
Hi Sachin, We want to maintain stickiness to a backed server based on host header so balance hdr(host) works pretty well for us, however as soon at the backend hits max connection, requests pile up in the queue eventually timeout with a 503 and –sQ in the logs. I don't think balance hdr(host) is the correct load-balancing method then. Is there a way to redispatch the requests to other servers ignoring the persistence on queue timeout? No; after a queue timeout (configurable by timeout queue), haproxy will drop the request. Think of what would happen when we redispatch on queue timeout: The request would wait seconds for a free slot on the backend and only then be redispatched to another server. This would delay many requests and hide the problem from you, while your customers furiously switch to a competitor. You should find another way to better distribute the load across your backends. Lukas
Re: How to redispatch a request after queue timeout
Thanks Lukas. Yes, I was hoping to workaround by setting a smaller maxqueue limit and queue timeout. So what other options do we have, I need to: 1. Send all requests for a host (mytest.mydomain.com) to one backend as long as it can serve. 2. If the backend is swamped, it should go to any other backend available. Thanks Sachin On 8/30/13 1:57 PM, Lukas Tribus luky...@hotmail.com wrote: Hi Sachin, We want to maintain stickiness to a backed server based on host header so balance hdr(host) works pretty well for us, however as soon at the backend hits max connection, requests pile up in the queue eventually timeout with a 503 and sQ in the logs. I don't think balance hdr(host) is the correct load-balancing method then. Is there a way to redispatch the requests to other servers ignoring the persistence on queue timeout? No; after a queue timeout (configurable by timeout queue), haproxy will drop the request. Think of what would happen when we redispatch on queue timeout: The request would wait seconds for a free slot on the backend and only then be redispatched to another server. This would delay many requests and hide the problem from you, while your customers furiously switch to a competitor. You should find another way to better distribute the load across your backends. Lukas
Issue with tcp-request content and keep alive
Hello, I have an issue when trying to track a connection based on a header, with tcp-request, and with keep alive enable in a listen section. Over the haproxy i have a cdn, which pass the ip of the client at the beginning of the X-Forwarded-For header. All the requests are pass through this cdn. This is the configuration: global maxconn 1000 log 127.0.0.1 local5 info err stats socket /var/run/haproxy.sock mode 0600 level admin pidfile /var/run/haproxy.pid defaults mode http log global retries 3 option redispatch timeout connect 5s timeout client 10s timeout server 10s timeout http-keep-alive 60s timeout http-request 5s listen proxy-http 192.168.1.100:80 mode http maxconn 1000 balance roundrobin stats enable option httplog option http-server-close #option httpclose option forwardfor stick-table type ip size 128m expire 30m store gpc0 tcp-request inspect-delay 5s tcp-request content track-sc0 req.hdr_ip(X-Forwarded-For,1) if HTTP acl rule_marked_deny sc0_get_gpc0 gt 0 use_backend back-deny if rule_marked_deny default_backend back-http backend back-deny server web-deny 192.168.1.133:80 backend back-http server web-http 192.168.1.101:80 With this conf, all the requests with the header X-Forwarded-For are tracked in the sc0 counter with the ip included in it. If the counter of one ip is update to number one, the request will be send to back-deny, this is doing by writing directly in the unix socket from other software. Like the example: # echo set table proxy-http key 88.64.32.11 data.gpc0 1 | socat stdio /var/run/haproxy.sock Since the moment that this are doing (with keep alive enable) i see that in the log of the web-deny backserver (the log are modified for register the x-forwarded-for ip instead of the real tcp connection): 88.64.32.11 - - [30/Aug/2013:09:08:22 +0200] www.server.com GET /some/url HTTP/1.1 301 208 157.55.32.236 - - [30/Aug/2013:09:08:27 +0200] www.server.com GET /some/url HTTP/1.1 301 208 88.64.32.11 - - [30/Aug/2013:09:08:27 +0200] www.server.com GET /some/url HTTP/1.1 301 208 157.55.32.236 - - [30/Aug/2013:09:08:28 +0200] www.server.com GET /some/url HTTP/1.1 301 208 88.64.32.11 - - [30/Aug/2013:09:08:29 +0200] www.server.com GET /some/url HTTP/1.1 301 208 157.56.93.186 - - [30/Aug/2013:09:08:31 +0200] www.server.com GET /some/url HTTP/1.1 301 208 157.56.93.186 - - [30/Aug/2013:09:08:31 +0200] www.server.com GET /some/url HTTP/1.1 301 208 As can see, there are other ips there and only one is with the 1 in the table of the Haproxy. This is a small piece of log, but when i try that in a server with more traffic, the problem is worse, more ips are redirected to this backend without marked for it. But, if i change the listen secion to option httpclose, all works well, only the marked ips are redirected. Problem solved, but why? The tcp inspect have problems tracking the request when these are passed through the cdn, which route more than one request of various clients in the same tcp connection? Probably the next feature (in the roadmap) http-request track-sc will solve this? Haproxy version: 1.5 dev 19 Some ips have being truncated in the examples. I hope that this help others like me. Thanks, Ricardo F.
Re: Debugging Backendforwarding and UP status
Baptiste, at first, sorry, I meant to say hi, but I had a very long night and it seems I have missed it. About the html. Thunderbird has a default html and txt message setting by default, normaly I change that, but as I said, I had a long night. The next time I'll remember that. Concerning the load balancing, I have experience with load balancing, and yes I knew it was a backend Problem. Most of the backends have been shown as down in my stats, as I already written in my last message. The only thing I thought strange was, that one was shown up and still got me that 503 error. About that debugging, that was the question. How much information does HAProxy provide to find the error concerning those backend health checks and shuting down those systems. I've set the log to debug mode but everything I got were this sort of log entries: Aug 30 09:48:49 localhost haproxy[17568]: Connect from 81.44.136.142:54570 to 192.168.48.12:80 (www.adworxs.net-merged/HTTP) So I couldn't find the reason, why all the backends have been shutdown. Obviously cause the check thought they were not availabe, but the problem is, that the same configuration has been working already. I had a network problem yesterday and had to reboot those haproxy systems, since that moment none of the websites configured did work anymore. So my question was, which log interface gives me the correct information about the checks and what would be the best way to analyze this problem. Thank you so far. Best regards Sebastian On 30.08.2013 07:38, Baptiste wrote: Sebastian, 1. when you talk to a ML, you should say 'Hi' 2. when you talk to a ML, you shouldn't send HTML mails Now, I can see you have absolutely no experience with Load-Balancing. Here are a few clues for you: - when you have a 503 error, then no need to think, it means ALL the servers from the farm are seen DOWN - the purpose of the health check is to ensure the service is UP and RUNNING on the servers - Usually, it is a good idea to enable health checking when load-balancing, to allow haproxy to know server status to avoid sending client requests to dead servers - instead of disabling health checking, you should be troubleshooting it: HAProxy logs will tell you why the health check was not working. Good luck, Baptiste On Fri, Aug 30, 2013 at 6:19 AM, Sebastian Fohleri...@far-galaxy.de wrote: Ok, I disabled the health check and it's working now, so it's definitly a problem of haproxy shuting down the backends. On 30.08.2013 05:55, Sebastian Fohler wrote: Some help, would be to disable the health check for the time being, is that possible. At least it would be a quickfix. On 30.08.2013 05:25, Sebastian Fohler wrote: Is there some simple way to find out why I get this error from my haproxy cluster? 503 Service Unavailable No server is available to handle this request. It looks like all my backend servers are down. Even in pools which are shown as up in my stats. How can I debug that sensible? Thank you in advance. Best regards Sebastian
Bénéficier d'un catalogue interactif pour vos produits et services
CRÃATION DE CATALOGUES PAPIER ET INTERACTIF B.T.I est une agence de communication globale dont l'une des compétences est la création, la réalisation ou la mise à jour de catalogues papier et interactif de vente .Le studio graphique de l'agence intègre toutes les compétences pôur la réalisation de A à Z de votre catalogue, quelqu'en soit la pagination ou le format. Du shooting/retouche, en passant par le rédactionnel, jusqu'au maquettage/exe graphique, nous veillons à la meilleure des qualité pour la réalisation et l'impression de votre catalogue.Catalogue interactifSi vous souhaitez mettre en ligne des documents dynamiques, qui comportent des adresses et des liens actifs et cliquables par ceux qui les parcourent, nous disposons dâune solution : le catalogue interactif. Ainsi, lâagence web B.T.I va prendre en charge la réalisation de vos publications - quelles quâelles soient - en PDF interactif ; des publications que vous allez pouvoir non seulement diffuser en ligne, directement sur votre site internet, mais aussi sur CD, DVD ou tout autre support numérique. Vous allez disposer dâun outil de communication redoutable au travers de ce catalogue interactif. Un catalogue feuilletable en ligne : le nec plus ultra !Au delà dâune simple prestation de rédaction et de mise en page, de très nombreuses fonctionnalités sont disponibles pour votre catalogue interactif, telles que : - La possibilité de créer une version « hors ligne », fonctionnant sous Mac et Windows- une optimisation du document selon les critères des moteurs de recherche, pour une meilleure visibilité de celui-ci, si besoin est- la possibilité de créer une version lisible sur les mobiles, mais aussi sur les tablettes tactiles- une lecture automatique du catalogueBien évidemment, ces options ne sont pas les seules ! Câest avec plaisir que nous répondrons à vos questions les concernant. Ainsi, sur la base dâun simple document au format PDF, votre catalogue interactif va permettre à vos internautes de tourner les pages à la manière dâun vrai livre. Lâeffet - professionnalisme, sérieux, qualité - est garanti ! Découvrez notre dernière réalisation : http://afrique-competences.burkinaentreprise.com/Pour tous renseignement veuillez nous contact au :Tel : 00226 71 0812 63 00226 77 08 89 30Email : cont...@burkinaentreprise.com
Re: junk at end of syslog packets in 1.5dev19
On Thu, Aug 29, 2013 at 10:50:09PM +0200, Lukas Tribus wrote:
The behavior also depends on the syslog facility; I used syslog in my tests.
With the current git tree I see the following behavior:
ntp and local7: syslog ends with \n -- correct behavior!
ftp and user: syslog ends with \n + 2 random characters
kern: syslog ends with \n + 4 random characters
It seems 2a4a44f0f9f caused the initial problem and bfb099c3b3f1 amplified it.
Regards,
Lukas
Hello Lukas,
Thanks for your analyze, the bug was indeed caused by the number of digits in
the facility.
Here's a patch with the real size to send :)
--
William Lallemand
From fcf527a2c629b696e8e2fa2993feb5be90b9ef04 Mon Sep 17 00:00:00 2001
From: William Lallemand wlallem...@exceliance.fr
Date: Fri, 30 Aug 2013 14:17:46 +0200
Subject: [PATCH] BUG/MINOR: log: junk at the end of syslog packet
With a facily of 2 or 1 digit, the send size was wrong and bytes with
unknown value were sent.
The size was calculated using the start of the buffer and not the start
of the data which varies with the number of digits of the facility.
This bug was reported by Samuel Stoller and reported by Lukas Tribus.
---
src/log.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/log.c b/src/log.c
index 369dc34..ad9fa73 100644
--- a/src/log.c
+++ b/src/log.c
@@ -847,7 +847,7 @@ void __send_log(struct proxy *p, int level, char *message, size_t size)
} while (fac_level log_ptr dataptr);
*log_ptr = '';
- sent = sendto(*plogfd, log_ptr, size + log_ptr - dataptr,
+ sent = sendto(*plogfd, log_ptr, size - (log_ptr - dataptr),
MSG_DONTWAIT | MSG_NOSIGNAL,
(struct sockaddr *)logsrv-addr, get_addr_len(logsrv-addr));
if (sent 0) {
--
1.8.1.5
RE: junk at end of syslog packets in 1.5dev19
Hello Lukas, Thanks for your analyze, the bug was indeed caused by the number of digits in the facility. Here's a patch with the real size to send :) Thanks, I confirm it fixes the problem. Regards, Lukas
