Re: force rewrite of cookie
It's a violation of proper layer insulation, but you can always have server 1 do it instead. Could be a maintenance problem but if it works, could be very reasonable, especially if the server can make the determination as to whether or not a client needs to be sticky. -Richard On Jan 29, 2013, at 5:30 AM, Runozo run...@gmail.com wrote: Greeetings and thanks for Haproxy I have the following backends configured and working with correct ACLs: backend back1 description balanced server apps mode http cookie SRV insert nocache indirect balance roundrobin option forwardfor option redispatch option http-server-close option tcp-smart-connect option httpchk HEAD /httpcheck.asp server www01-sia 192.168.41.235:80 cookie 1 maxconn 200 slowstart 30s weight 1 check server www02-sia 192.168.41.236:80 cookie 2 maxconn 200 slowstart 30s weight 1 check backend back2 description single server apps mode http # reqadd Cookie:\ SRV=1 # reqidel ^Cookie:.*SRV=.* # cookie SRV insert nocache option forwardfor server www01-sia 192.168.41.235:80 maxconn 500 slowstart 1m check Now, i wish that when the client is on back2, the SRV client cookie be always rewritten with value 1 so, when client come back to back1 will be sticked to server 1 Is it possible? I think yes, but cannot figure out how Thank you all again, Runozo
Re: issues with very long URLs.
We regularly get individual REST GET requests significantly over that length; the only tuning parameter we've done in that regard is: tune.bufsize 128000 I don't actually recall if this was mandatory to address the issue, but I'm thinking that it was. -Richard Richard Stanford CTO | KIMBIA 512-474-4447 x777 On Sep 10, 2012, at 12:24 PM, Lange, Kevin M. (GSFC-423.0)[RAYTHEON COMPANY] wrote: Hi, Our public-facing service provides a REST api to search for products (geospatial science data), which requires in many cases very long URLs to craft the search. We seem to be hitting a limit of around 8K before we receive a 400 Bad request from lighttpd. We're trying to determine if lighttpd is causing this, or haproxy. We have a dev/test stack (lighttpd/haproxy on Linux) and an OPS stack of the same. Our OPS stack we thought we had test results of the URL length maximum, but after we upgraded haproxy to the latest on our OPS stack, we noticed that people began complaining about the URL length issue (maximum 8k). Is there a configurable item in haproxy which would limit a URL length to ~8k? Suggestions from searches show that tune.bufsize might control this. We'd like to offer our customers a 10k length for REST api calls. - Kevin Kevin Lange kevin.m.la...@nasa.gov kla...@raytheon.com W: +1 (301) 851-8450 Raytheon | NASA | ECS Evolution Development Program https://www.echo.nasa.gov | https://www.raytheon.com
Re: Backend redirection issue - log interpretation help please
Cyril, thanks for your response. On Jul 26, 2012, at 4:46 PM, Cyril Bonté wrote: Please add log global in your backend sections (or in your defaults), this explains why your log files didn't give you any indication. After adding this line everywhere (not only in the frontend), you'll see when servers go UP and DOWN, and why. This will also probably help us to know what happens. Done. That helps - we tend to be a bit minimal on most logging for compliance reasons but that's certainly going to help. From this previous log line, it looks like something becomes slow (your haproxy server or your backend servers). That's the odd piece, because the server logs don't seem to indicate any issues (and this was last seen shortly after a restart). Hopefully the logging will shed more light on the subject. Wow, are you sure you really want to use such a big buffer size ? Also, ensure you're running the last stable version of HAProxy (currently 1.4.21), which fixes a major bug when using a larger buffer size (it doesn't explain what you observe but it's an advise for more stability). Unfortunately yes; we are supporting some rare but critical very large HTTP GET requests over a REST API. I'll look into upgrading shortly. For more details : http://haproxy.1wt.eu/git?p=haproxy-1.4.git;a=commit;h=30297cb17147a8d339eb160226bcc08c91d9530b Good to know! As said at the beginning, please add : log global Added. Is there a useful log level configuration that outputs exactly what the defaults are without the stats connection lines? If using cookies is not an issue for your clients, I'd recommend you not to use appsession but cookie insert or cookie prefix instead. http://cbonte.github.com/haproxy-dconv/configuration-1.4.html#4-cookie We'll probably leave this one just because I don't believe its giving us any issues at the moment; the client problem definitely coincided with the backend being marked as DOWN rather than a cookie issue (the cookie issue was my first guess to be honest). server gui1 172.25.200.53:8080 check maxconn 2000 server gui2 172.25.200.54:8080 check maxconn 2000 You didn't provide any timeout check nor inter value. The default will be 2 seconds, which is maybe too low for your case. It shouldn't be - our healthcheck page is fairly simple and just basically makes sure that our webapp is responding to requests (barely more than a static file) - I've upped timeout check to 1 though, so we'll see if that makes a difference. Hope this helps. It did, and thank you for looking at this. I've learned an awful lot about haproxy configuration setups (good and bad) from this list! -Richard
Backend redirection issue - log interpretation help please
I'm having some trouble interpreting an HAProxy log file line - it doesn't seem to make much sense to me, so I'm fairly certain that I'm reading it incorrectly. My full configuration file is at the end of this email. Symptomatically, I've been seeing situations in which people are briefly redirected unexpectedly onto a different 'gui' backend server. Its rare, but when it happens it often appears at the same point in the GUI use flow. This may be a red herring however. This morning I was able to reproduce it even after restarting our appserver proceses and our haproxy process (which had been up for an extended period of time - thanks!). When it reproduced, I noticed that the backend appserver was marked as DOWN in the statistics report even though the logfiles gave no indication that there were any problems. From the user's experience, the system hung waiting for a response for some 40 seconds and then showed a login screen, which was served when the incorrect backend received a page request. Simply re-requesting the previous page was successful, as the previously authenticated backend was shown as UP by that point. In the logfile we see the following entry at the appropriate time: Jul 26 06:21:09 localhost haproxy[3853]: 172.25.200.177:3124 [26/Jul/2012:06:21:01.826] secure gui/gui2 4993/0/0/-1/7992 -1 0 - - CH-- 40/40/1/1/0 0/0 HEAD /panel/healthcheck.html HTTP/1.1 This file - while similar to the HAProxy healthcheck URL (and in fact produced the same way on the backend server) - is actually the one being requested by our hardware LBs (we use existing hardware LBs to distribute between machines, and a single haproxy daemon on each box to distribute to appservers within each machine). It appears that it saw some sort of timeout, but I'm not sure why that would have caused haproxy to mark the backend as DOWN. We add backend server markers to our generated pages, so I'm confident that the hardware LB kept us on the same physical system the entire time. Needless to say I'm a little confused as to what I'm seeing. If anyone can shed a little more light on the subject it would be very much appreciated! Other than this recurrent issue, everything's been working incredibly well. Configuration file below in full in case there's something odd: global maxconn 2 tune.bufsize 128000 tune.maxrewrite 8192 ulimit-n 6 stats socket /tmp/haproxy mode 0777 level admin log 127.0.0.1 local0 defaults mode http timeout connect 5s timeout client 1m timeout server 10m option srvtcpka option http-server-close option http-pretend-keepalive option redispatch option abortonclose option httpchk HEAD /panel/healthcheck.txt HTTP/1.0 backend gui balance source appsession JSESSIONID len 64 timeout 3h server gui1 172.25.200.53:8080 check maxconn 2000 server gui2 172.25.200.54:8080 check maxconn 2000 backend platform balance roundrobin server platform1 172.25.200.50:8080 check maxconn 2000 server platform2 172.25.200.51:8080 check maxconn 2000 server platform3 172.25.200.52:8080 check maxconn 2000 frontend secure bind 172.25.200.70:8080 maxconn 2 option forwardfor option clitcpka acl javascript url_beg /js acl widgetsurl_beg /widgets acl reportsurl_beg /datafeed acl deny url_beg /server-status /balancer-manager /jmx-console /web-console /invoker block if deny default_backend gui use_backend platform if javascript or widgets or reports log global option httplog option dontlognull option dontlog-normal listen stats :7583 mode http stats uri /
Re: HAProxy in High Availability
With this approach you really want 1 fewer public IP than you have public facing servers. With 2 servers this means 1 IP. DNS is used to distribute the load around, and keepalived is used to move traffic when a server fails. But you always want at least 1 servers worth of spare capacity in your HA environment, otherwise after you fail over the server getting 2X traffic will also die. Actually that's an oversimplified example, since to distribute the load correctly you'd need n-1 public addresses on each of n servers (with diminishing returns). Thankfully few LB scenarios require more than 1X1 machines. -Richard On Jun 28, 2012, at 6:17 AM, David Coulson da...@davidcoulson.net wrote: Multiple IP addresses are used, and managed by keepalived. On 6/28/12 7:11 AM, Thomas Manson wrote: Ok, but then, I don't get where is used DNS Round Robin, if only one IP is used. (it may be obvious, sorry ;);) Regards, Thomas. On Thu, Jun 28, 2012 at 1:08 PM, Türker Sezer turkerse...@tsdesign.info wrote: On Thu, Jun 28, 2012 at 11:59 AM, Manson Thomas m...@mansonthomas.com wrote: usually a client will cache the IP served by the DNS server, in order to not query each time the DNS system. So how can the client switch to another server once it has resolved one. Clients dont switch ip address. They connect same ip address. But we move ip address to backup or another active instance using keepalived so they connect another server using same ip address. -- Türker Sezer TS Design Informatics LTD. http://www.tsdesign.info/
Re: redirect prefix, use variable host
That would actually help us out a lot also. I'd dug into the code to see if there was a simple way to add the functionality we need but its obviously been too long since I've written system-level C code for me to make a confident patch. We currently use an instance of Apache purely to redirect any plain http traffic to https no matter what the domain/URL is (but we also support wildcard domains). This would certainly do the trick since we always want to keep the request URL same, just force it to https. That would allow us to completely remove Apache from our software chain, which would be great from a security certification standpoint. Richard Stanford CTO | KIMBIA 512-474-4447 x777 On May 17, 2012, at 7:41 AM, Willy Tarreau wrote: Hi, On Wed, May 16, 2012 at 05:05:05PM +0200, hapr...@serverphorums.com wrote: I think I am in this exact same boat. I have a site with wildcard subdomains as well. Is there an ETA on this this pattern extraction? I browsed the changelogs up through 5/14/2012 and it looks like there could be some possible headway on this. Can someone please confirm? A lot of progress has indeed been made, but we still don't have such ability and it will take some time to implement. Are there any other creative solutions for this? I need to redirect any subdomain to https unless it is www. No idea right now. From what I understand you'd like to take the host header and put it into your redirects, prepended by http://; or https://; depending on the type of redirection, that's it ? Maybe it should not be too hard to implement some http-host and https-host options to the redirect statement, as alternatives to prefix, and which would automatically concatenate a scheme (http://; or https://;) with the extract of the Host header and the current URI. I must say I have not much studied the idea, but it should be doable without too much effort. Regards, Willy
HTTP - HTTPS redirects
I've seen some discussion of this before, but couldn't find a resolution; I'll
apologize in advance if this is duplicated somewhere in the archives.
We've been using HAProxy (very happily, I might add) for a while to load
balance between appserver instances on physical hardware. We're also currently
using Apache purely to issue 302 redirects when HTTP traffic comes in
(everything we do - other than the redirects - is HTTPS). It seems as if we
should be able to use HAProxy for these since the connections are going through
it anyway.
Our challenge is that our servers accept connections on a wildcard hostname (
*.domain.com ) and we need to maintain the host identity during the
redirection, so hardcoding the host portion won't work in our case. Would
somebody be able to help me out with the correct syntax, if its even possible?
Thanks!
FWIW, the equiv. Apache redirect rule we're trying to eliminate is:
# SSL Redirect from external port 80
VirtualHost 172.25.200.70:80
RewriteEngine On
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
/VirtualHost
Richard Stanford
CTO, KIMBIA
512-474-4447
