Re: route !HTTP connections to tcp backend instead of dropping in HTTP mode
Hi Lukasz, You must use stunnel in front of haproxy in order to be able to inspect pure clear HTTP traffic. Concerning your HAProxy configuration, it's not fully accurate. Please give a try to the configuration below: frontend mode tcp tcp-request inspect-delay 1s use_backend nodejs_flashpolicy_http if HTTP default_backend nodejs_flashpolicy backend nodejs_flashpolicy mode tcp server node1 localhost:10843 maxconn 2000 check backend nodejs_flashpolicy_http mode http option httplog server node1 localhost:10843 maxconn 2000 check cheers On Mon, Dec 12, 2011 at 8:10 AM, Lukasz Michalski l...@zork.pl wrote: On 12/10/2011 04:29 PM, Baptiste wrote: Hi, There is an ACL for that: req_proto_http (and an alias exists: HTTP) you can choose you backend based on it's return: tcp-request content inspect-delay 1s use_backend bk_http if HTTP use_backend bk_xml if !HTTP I am not sure how this should be configured. I added to my conf file: tcp-request content accept if !HTTP tcp-request inspect-delay 1s use_backend nodejs_flashpolicy_http if !HTTP backend nodejs_flashpolicy mode tcp server node1 localhost:10843 maxconn 2000 check backend nodejs_flashpolicy_http mode http option httplog server node1 localhost:10843 maxconn 2000 check haproxy does not let me use_backend nodejs_flashpolicy in my frontend: [ALERT] 345/074250 (26349) : Unable to use proxy 'nodejs_flashpolicy' with wrong mode, required: http, has: tcp. But now I realized that the connection is dropped by stunnel and does not even get to haproxy. It seems that the best way would be to inspect the data on ports 80 and 443 and if I get xml string (which is always the same) then connect to appropriate service, otherwise use stunnel/haproxy. The problem is that I cannot find any software for linux that is capable of doing so. If you know any please share. Many thanks, Łukasz
Re: route !HTTP connections to tcp backend instead of dropping in HTTP mode
On 12/12/2011 09:52 AM, Baptiste wrote: Hi Lukasz, You must use stunnel in front of haproxy in order to be able to inspect pure clear HTTP traffic. Concerning your HAProxy configuration, it's not fully accurate. Please give a try to the configuration below: frontend mode tcp tcp-request inspect-delay 1s use_backend nodejs_flashpolicy_http if HTTP default_backend nodejs_flashpolicy backend nodejs_flashpolicy mode tcp server node1 localhost:10843 maxconn 2000 check backend nodejs_flashpolicy_http mode http option httplog server node1 localhost:10843 maxconn 2000 check cheers Thanks for quick reply. I tried mode tcp on frontend but then I cannot route HTTP requests to my backends. This my current config: # Flash plugin will not send send policy-file-request/ # on client connection if policy file can be requested # from the same host on port 843. # We cannot use different port here. frontend flash_policy bind 0.0.0.0:843 mode tcp default_backend nodejs_flashpolicy # Main frontend frontend proxy bind 0.0.0.0:80 bind 0.0.0.0:8443 mode http option httplog maxconn 20 timeout client 8640 default_backend webapp tcp-request content accept if !HTTP tcp-request inspect-delay 1s use_backend nodejs_flashpolicy_http if !HTTP #use_backend nodejs_flashpolicy if !HTTP #websockets acl is_websocket path_beg /socket.io acl is_websocket hdr(Upgrade) -i WebSocket acl is_websocket hdr_beg(Host) -i ws use_backend websocket if is_websocket backend webapp mode http option httplog option httpclose server cherrypy1 localhost:7000 check backend websocket mode http option httplog timeout server 8640 timeout queue 5000 timeout connect 8640 option forwardfor no option httpclose option http-server-close option forceclose server node1 localhost:12000 maxconn 2000 check backend nodejs_flashpolicy mode tcp server node1 localhost:10843 maxconn 2000 check backend nodejs_flashpolicy_http mode http option httplog server node1 localhost:10843 maxconn 2000 check I have to route http traffic to this two backends based on request path, host and HTTP headers. Additionally if !HTTP traffic is detected on proxy frontend I would like to route it to nodejs_flashpolicy. I tried tcp mode on frontend but it caused a random backend to be selected when valid HTTP request came in. Is it true that my acl's are ignored in tcp mode? Anyway, my websocket traffic is over SSL and I have to make this decision before SSL connection is terminated by stunnel, because flash plugin sends unencrypted xml data to port 443 if port 843 is not available. Thanks for your help, Łukasz
haproxy and interaction with VRRP
Hi! When haproxy is bound to an IP address managed by VRRP, this IP address may be absent when haproxy starts. What is the best way to handle this? 1. Start haproxy only when the host is master. 2. Use transparent mode. 3. Patch haproxy to use IP_FREEBIND option.
Re: haproxy and interaction with VRRP
Le lundi 12 décembre 2011 10:18:33, Vincent Bernat a écrit : Hi! When haproxy is bound to an IP address managed by VRRP, this IP address may be absent when haproxy starts. What is the best way to handle this? 1. Start haproxy only when the host is master. 2. Use transparent mode. 3. Patch haproxy to use IP_FREEBIND option. What about a 4: - Add net.ipv4.ip_nonlocal_bind=1 to your sysctl.conf settings. No need to patch anything -- Guillaume Castagnino ca...@xwing.info / guilla...@castagnino.org
Re: haproxy and interaction with VRRP
On 12 December 2011 11:18, Vincent Bernat ber...@luffy.cx wrote: Hi! When haproxy is bound to an IP address managed by VRRP, this IP address may be absent when haproxy starts. What is the best way to handle this? 1. Start haproxy only when the host is master. 2. Use transparent mode. 3. Patch haproxy to use IP_FREEBIND option. On Linux it's possible to enable binding to an address which isn't associated with a device on your system. This is what we do on our HAproxy boxes and we've never had a problem with it in 2 years. This works for Debian/Ubuntu, adjust as needed for whichever distro you're using: echo net.ipv4.ip_nonlocal_bind=1 | sudo tee -a /etc/sysctl.conf sudo sysctl -p Once that's done, HAproxy (and any other app actually) can bind to your VRRP addresses even when the server doesn't currently have the addresses associated with any network interfaces. HTH, Graeme.
Re: haproxy and interaction with VRRP
On Mon, 12 Dec 2011 11:28:21 +0200, Graeme Donaldson wrote: When haproxy is bound to an IP address managed by VRRP, this IP address may be absent when haproxy starts. What is the best way to handle this? 1. Start haproxy only when the host is master. 2. Use transparent mode. 3. Patch haproxy to use IP_FREEBIND option. On Linux it's possible to enable binding to an address which isn't associated with a device on your system. This is what we do on our HAproxy boxes and we've never had a problem with it in 2 years. This works for Debian/Ubuntu, adjust as needed for whichever distro you're using: echo net.ipv4.ip_nonlocal_bind=1 | sudo tee -a /etc/sysctl.conf sudo sysctl -p Once that's done, HAproxy (and any other app actually) can bind to your VRRP addresses even when the server doesn't currently have the addresses associated with any network interfaces. Thanks to you and Guillaume for your quick answer!
Re: haproxy and interaction with VRRP
On 12.12.2011 10:28, Guillaume Castagnino wrote: Le lundi 12 décembre 2011 10:18:33, Vincent Bernat a écrit : Hi! When haproxy is bound to an IP address managed by VRRP, this IP address may be absent when haproxy starts. What is the best way to handle this? 1. Start haproxy only when the host is master. 2. Use transparent mode. 3. Patch haproxy to use IP_FREEBIND option. What about a 4: - Add net.ipv4.ip_nonlocal_bind=1 to your sysctl.conf settings. No need to patch anything I use a 5: I bind the vrrp addresses to a dummy interface. For example: ip addr add 192.168.1.1/32 dev dummy0 ip addr add 2001:dead:beef::1/128 dev dummy0 Keepalived has this nice static address option for it. I started doing this because there is no nonlocal_bind option for IPv6 (or I didn't search well enough (-: ) Greets, Sander
Re: haproxy and interaction with VRRP
On Mon, 12 Dec 2011 13:04:22 +0100, Sander Klein wrote: I started doing this because there is no nonlocal_bind option for IPv6 (or I didn't search well enough (-: ) From the source code, it seems that IPv4 non local bind sysctl also applies to IPv6. Since 2.6.30. Hmmm, then I'm going to look into it again. I'm running 2.6.39 and it doesn't seem to work. Could be a problem on my side. You are right. It only applies to v4-mapped addresses.
Re: haproxy and interaction with VRRP
On 12.12.2011 13:10, Vincent Bernat wrote: On Mon, 12 Dec 2011 13:04:22 +0100, Sander Klein wrote: I started doing this because there is no nonlocal_bind option for IPv6 (or I didn't search well enough (-: ) From the source code, it seems that IPv4 non local bind sysctl also applies to IPv6. Since 2.6.30. Hmmm, then I'm going to look into it again. I'm running 2.6.39 and it doesn't seem to work. Could be a problem on my side. You are right. It only applies to v4-mapped addresses. It would have been nice if it did work though... It's one of those features I'm missing. Binding ip's to the dummy interface works, but it always feels a bit hacky and brings up a lot of administration if you have lots of vrrp addresses. Greets, Sander
Re: haproxy and interaction with VRRP
On Mon, 12 Dec 2011 13:23:11 +0100, Sander Klein wrote: I started doing this because there is no nonlocal_bind option for IPv6 (or I didn't search well enough (-: ) From the source code, it seems that IPv4 non local bind sysctl also applies to IPv6. Since 2.6.30. Hmmm, then I'm going to look into it again. I'm running 2.6.39 and it doesn't seem to work. Could be a problem on my side. You are right. It only applies to v4-mapped addresses. It would have been nice if it did work though... It's one of those features I'm missing. Binding ip's to the dummy interface works, but it always feels a bit hacky and brings up a lot of administration if you have lots of vrrp addresses. Here is a patch for this (only slightly tested): http://marc.info/?l=linux-netdevm=132369656811468w=2 It is targeted at the net-next branch and will not apply cleanly on a vanilla kernel: you just need to remove the check on inet-freebind which is not yet present in vanilla kernels.
Re: balance by selecting host with lowest latency?
Hi Wout, On Mon, Dec 12, 2011 at 08:41:37AM +0100, Wout Mertens wrote: Hi Willy, On Dec 9, 2011, at 19:03 , Willy Tarreau wrote: Then I realized that setting a low maxconn on the servers was already doing exactly what we want : once the maxconn is reached, connections get queued, and the faster servers get more connections than the slower ones, following a ratio which is *exactly* their response time ratio. So if one wants to ensure fair response times between servers, a little bit of queuing is all what's needed. This is very interesting. It would be a great addition to the configuration manual :-) It's more suited to the architecture manual which is completely out of date. Two vaguely related questions now that I have your attention: - Would it be possible to add the average response time for a server in the statistics page? It would be interesting to monitor that number. I too would like to report this one, as well as a few other basic information. It's just a matter of time or of who steps in first :-) - When you have the same server in multiple backends, does each backend do checking separately, or does it share the info once you enable it? I have some backends with just the one server and I don't enable checking on it because I don't want to burden the server with extra connections. All are individually checked, but you can use the track keyword to ensure that only one really sends the checks and that other ones only report the same state. Willy
Re: balance by selecting host with lowest latency?
On Mon, Dec 12, 2011 at 12:14:09PM +0100, Wout Mertens wrote: I did come up with a different feature request: Please provide an average queue time for the connections in a backend. You already have the total queue time in the logs. This is very useful to detect sudden slowdowns, and I know some people who monitor this one much more than the response time because of its threshold effect which is much more noticeable. It would be nice if an option could be set to log errors if the queue time exceeds x seconds too. If the queue time exceeds timeout queue, you have flags sQ in the logs. I just had a configuration change result in a 30s queue time and I didn't realize it until someone complained :-( A configuration change alone cannot increase the queue time that much, it really means that your servers are overloaded, because whatever you do to send the traffic there, they apparently need 30 seconds to process all the requests before the one you noticed. Regards, Willy
Disabling logging of stats page requests
Hi all - We have a monitoring/stats-collecting service curling a /haproxy?stats URI rather frequently. In order to stop these requests from spamming the logs, I tried a few different approaches, and I think that their failure to achieve what I needed point towards some possible enhancements that others may find useful. Here's what I tried, with the change I'd like to propose: 1) Declare monitor-net $stats-server/32. This resulted in the only respond with a 200/5xx behaviour of monitor-net taking precedence over the stats uri setting. Any chance of changing this ordering for the single stats-uri only? It would seem to make more sense -- especially as stats is only a single path whereas monitor-net requests can hit any other path -- but I totally appreciate it may not be that simple behind the scenes. 2) Set up a dedicated stats-listener listen stanza with option dontlog-normal. This didn't have any effect - even though 200s are returned, their logs aren't silenced by this setting. I suggest they should be. 3) Use a dedicated stats-listener with no logging configured. This ultimately worked, but I encountered some global/default interactions which forced me to change more of the configuration than I had hoped. The config included: global log 127.0.0.1 local0 info defaults log global ... which is, I believe, a commonly recommended pattern to ensure that logging isn't forgotten for any front-/back-end. Unfortunately I then couldn't *disable* logging from the dedicated stats listener. I had to remove log global from defaults, and add it to every listener individually *except* the stats listener. I could still use the common logging config pattern if log global, or perhaps individual log server etc etc lines could be negated at the listener level when inherited from the defaults section. Any chance of this being possible? In an unrelated question, could I ask if there's any plan to increase the number of subnets passable to monitor-net; or perhaps just an increase in the number of times it can be specified incrementally without overriding the last setting? Many thanks, Jonathan -- Jonathan Matthews London, UK http://www.jpluscplusm.com/contact.html
Re: route !HTTP connections to tcp backend instead of dropping in HTTP mode
well, if your websocket traffic is encrypted, how do you want haproxy to read the headers Your last chance is to try to use dst_port acl to match websocket port or to use two separated frontend.. cheers On Mon, Dec 12, 2011 at 10:10 AM, Lukasz Michalski l...@zork.pl wrote: On 12/12/2011 09:52 AM, Baptiste wrote: Hi Lukasz, You must use stunnel in front of haproxy in order to be able to inspect pure clear HTTP traffic. Concerning your HAProxy configuration, it's not fully accurate. Please give a try to the configuration below: frontend mode tcp tcp-request inspect-delay 1s use_backend nodejs_flashpolicy_http if HTTP default_backend nodejs_flashpolicy backend nodejs_flashpolicy mode tcp server node1 localhost:10843 maxconn 2000 check backend nodejs_flashpolicy_http mode http option httplog server node1 localhost:10843 maxconn 2000 check cheers Thanks for quick reply. I tried mode tcp on frontend but then I cannot route HTTP requests to my backends. This my current config: # Flash plugin will not send send policy-file-request/ # on client connection if policy file can be requested # from the same host on port 843. # We cannot use different port here. frontend flash_policy bind 0.0.0.0:843 mode tcp default_backend nodejs_flashpolicy # Main frontend frontend proxy bind 0.0.0.0:80 bind 0.0.0.0:8443 mode http option httplog maxconn 20 timeout client 8640 default_backend webapp tcp-request content accept if !HTTP tcp-request inspect-delay 1s use_backend nodejs_flashpolicy_http if !HTTP #use_backend nodejs_flashpolicy if !HTTP #websockets acl is_websocket path_beg /socket.io acl is_websocket hdr(Upgrade) -i WebSocket acl is_websocket hdr_beg(Host) -i ws use_backend websocket if is_websocket backend webapp mode http option httplog option httpclose server cherrypy1 localhost:7000 check backend websocket mode http option httplog timeout server 8640 timeout queue 5000 timeout connect 8640 option forwardfor no option httpclose option http-server-close option forceclose server node1 localhost:12000 maxconn 2000 check backend nodejs_flashpolicy mode tcp server node1 localhost:10843 maxconn 2000 check backend nodejs_flashpolicy_http mode http option httplog server node1 localhost:10843 maxconn 2000 check I have to route http traffic to this two backends based on request path, host and HTTP headers. Additionally if !HTTP traffic is detected on proxy frontend I would like to route it to nodejs_flashpolicy. I tried tcp mode on frontend but it caused a random backend to be selected when valid HTTP request came in. Is it true that my acl's are ignored in tcp mode? Anyway, my websocket traffic is over SSL and I have to make this decision before SSL connection is terminated by stunnel, because flash plugin sends unencrypted xml data to port 443 if port 843 is not available. Thanks for your help, Łukasz
Unable to perform routing using HA Proxy on Linux machine post reboot
Hi, We have a Linux machine on which are installed 2 servers (tomcat @ 8080, lighthttpd @ 8081). I am using HAProxy ( @ 80 ) to perform domain base routing to these servers. After a reboot, we restarted the apps(haproxy, lighthttpd, tomcat) and found that haproxy is no longer able to perform routing. Before reboot things were working fine and we did not perform any config/software changes from our end. Here are our haproxy settings : - frontend http_proxy - bind 10.211.154.49:80 http://10.211.154.49/ - option forwardfor - acl is_resource hdr_dom(host) -i resource.qureka.com - acl is_app hdr_dom(host) -i www.qureka.com - use_backend resource_cluster if is_resource - use_backend app_cluster if is_app backend resource_cluster server server1 127.0.0.1:8081 backend app_cluster server server1 127.0.0.1:8080 Here are the logs on haproxy start : Dec 11 12:56:43 localhost haproxy6655 https://forums.aws.amazon.com/: Proxy http_proxy started. Dec 11 12:56:43 localhost haproxy6655 https://forums.aws.amazon.com/: Proxy resource_cluster started. Dec 11 12:56:43 localhost haproxy6655 https://forums.aws.amazon.com/: Proxy app_cluster started. Example url : standalone lighthttp url : http://resource.qureka.com:8081/qureka/static/1331/qRev/images/Processing.gif working https://forums.aws.amazon.com/ lighthttpd through proxy : http://resource.qureka.com/qureka/static/1331/qRev/images/Processing.gif not working https://forums.aws.amazon.com/ For reference, - HAProxy is on port 80. - LightHttpd Server is on port 8081. HAproxy is supposed to forward request to light httpd if request contains resource.qureka.com. But that is not happening. It worked before the reboot with the same config. Also since logging isn't happening, we are clueless and are unable to move further to solve this issue. It would be great if we could get some help on how to troubleshoot this issue further.
Re: Unable to perform routing using HA Proxy on Linux machine post reboot
Hi, You definitively need to enable logs in your HAProxy configuration! How do you want to troubleshoot without it??? Are you sure haproxy is running and has bound port 80? I mean, maybe an other process has bound this port and is handling traffic instead of HAProxy. good luck On Mon, Dec 12, 2011 at 7:57 PM, Avinash avinash.anan...@gmail.com wrote: Hi, We have a Linux machine on which are installed 2 servers (tomcat @ 8080, lighthttpd @ 8081). I am using HAProxy ( @ 80 ) to perform domain base routing to these servers. After a reboot, we restarted the apps(haproxy, lighthttpd, tomcat) and found that haproxy is no longer able to perform routing. Before reboot things were working fine and we did not perform any config/software changes from our end. Here are our haproxy settings : frontend http_proxy bind 10.211.154.49:80 option forwardfor acl is_resource hdr_dom(host) -i resource.qureka.com acl is_app hdr_dom(host) -i www.qureka.com use_backend resource_cluster if is_resource use_backend app_cluster if is_app backend resource_cluster server server1 127.0.0.1:8081 backend app_cluster server server1 127.0.0.1:8080 Here are the logs on haproxy start : Dec 11 12:56:43 localhost haproxy6655: Proxy http_proxy started. Dec 11 12:56:43 localhost haproxy6655: Proxy resource_cluster started. Dec 11 12:56:43 localhost haproxy6655: Proxy app_cluster started. Example url : standalone lighthttp url : http://resource.qureka.com:8081/qureka/static/1331/qRev/images/Processing.gifworking lighthttpd through proxy : http://resource.qureka.com/qureka/static/1331/qRev/images/Processing.gif not working For reference, HAProxy is on port 80. LightHttpd Server is on port 8081. HAproxy is supposed to forward request to light httpd if request contains resource.qureka.com. But that is not happening. It worked before the reboot with the same config. Also since logging isn't happening, we are clueless and are unable to move further to solve this issue. It would be great if we could get some help on how to troubleshoot this issue further.
Re: Slowness in establishing connections from ruby to Haproxy after upgrading from 1.4.8 to 1.4.18
Hi Tim, On Mon, Dec 12, 2011 at 02:33:53PM -0500, Timothy Garnett wrote: Hi all, We've been using Haproxy for a couple of years now to load balance our external traffic and our internal backend services. We recently upgraded from version 1.4.8 to 1.4.18 and we noticed some connection initialization performance issues when connecting from Ruby's standard net::http library, specifically it takes about 200ms longer for the connection to establish then it used to. It's unclear if the issue comes from Ruby or Haproxy. We're interested if anyone has run into similar problems and if there are things we can do to help identify the issue for fixing. Not specifically this one but 200ms sounds like a missing TCP_NODELAY on the client side. What I *suspect* (tcpdump on loopback could confirm) is that ruby sends HTTP request in small writes (eg: one write per line) and for this, disables TCP_NODELAY instead of sending many packets, but fails to enable it on the last packet. Alternatively, something else is possible. Maybe it's not the connection time which is huge but the total response time due to similar issues the other way around. Please add option http-server-close to your defaults section to see if it changes anything. Right now your config is in tunnel mode which is not very good, although it should not cause this. Another possibility that comes to mind, since you're sending data, is that ruby sends multiple small packets. Due to TCP, it needs an ACK every two packet. During a POST, haproxy does a bulk forward of data, which sends blocks as large as possible, without TCP_NODELAY, to save network resources. It's possible that this results in ACKs being delayed for incomplete packets then. Really, a tcpdump between ruby and haproxy would immensely help. You can also test with option http-no-delay which is mainly used for chunked-encoding transfers, when either direction is sensible to the framing (which is a direct violation of HTTP spec). If you happen to take a network capture, please use tcpdump -s0 to capture full packets and save them to a file using -w file.cap. Regards, Willy
Re: route !HTTP connections to tcp backend instead of dropping in HTTP mode
Hi,
On Mon, Dec 12, 2011 at 09:20:28PM +0100, ??ukasz Michalski wrote:
W dniu 2011-12-12 19:17, Baptiste pisze:
well, if your websocket traffic is encrypted, how do you want haproxy
to read the headers
It works this way:
1. From flash plugin I open socket connection to port 443 to make HTTP
requests.
2. Flash connects to port 843 and sends string policy-file-request/
and expects xml reply with info where it is allowed to connect.
3. If port 843 is not available then flash plugin sends string
policy-file-request using connection opened at (1).
4. If flash plugin receives valid reply from(3) then it opens new
connection to port 443 where I am allowed to make my encrypted HTTP
requests.
Points 2 and 3 are outside my control - it is done by flash plugin
behind the scenes. On server side I have to detect string
policy-file-request/ and route that connection to the backend that
will send valid xml reply - note that this string is sent to port meant
to be used for HTTP data exchange - it could be encrypted (443) or not (80).
SSL adds more complexity because in this case all this is happening on
stunnel and stunnel at point (3) resets my connection as invalid SSL
handshake.
I think that have to setup some tcp content analyzer that will be able
to read first 15 bytes from traffic and then route connection to stunnel
or haproxy only if this is not a policy file request.
Yes, then you can proceed that way :
- have haproxy in TCP mode in front of stunnel so that it detects
either a valid and complete SSL message, or at least 22 bytes
of non-SSL traffic (the XML request) ;
- make it route to the appropriate server when the request is not SSL.
It would look like this :
frontend port443
bind :443
tcp-request inspect-delay 5s
acl traffic_is_ssl req_ssl_ver -gt 0
acl enough_non_ssl_bytes req_len -ge 22
tcp-request content accept if traffic_is_ssl # accept SSL
tcp-request content accept if enough_non_ssl_bytes # accept non-SSL
# at this point we have something valid in the buffer
use_backend ssl_backend if traffic_is_ssl
default_backend xml_backend
backend ssl_backend
server stunnel 127.0.0.1:4443
backend xml_backend
server xml-server 127.0.0.1:8883
You can even proceed that way for HTTP too and even have them all on the
same port if you want :
frontend port443
bind :443
tcp-request inspect-delay 5s
acl traffic_is_ssl req_ssl_ver-gt 0
acl traffic_is_http req_proto_http
acl enough_non_ssl_bytes req_len-ge 22
tcp-request content accept if traffic_is_ssl # accept SSL
tcp-request content accept if traffic_is_http # accept HTTP
tcp-request content accept if enough_non_ssl_bytes # accept
non-{SSL|HTTP}
# at this point we have something valid in the buffer
use_backend ssl_backend if traffic_is_ssl
use_backend http_backend if traffic_is_http
default_backend xml_backend
Or you can have ssl+xml checks on port 443 and http+xml checks on port 80.
The HTTP backend should have mode http in it so that it completely analyses
the HTTP request.
Maybe I can setup second haproxy in tcp mode with this patch:
https://github.com/dvv/farm/blob/master/flash-policy.diff
I did not know about this patch. If this way of requesting flash policy files
is well defined and standard, then we should merge this patch as it may ease
some setups.
as my tcp content analyzer? Will this patch work in tcp mode?
In theory it should. However with what is above, you don't need it,
which saves you from maintaining a patch.
Regards,
Willy
Re: Unable to perform routing using HA Proxy on Linux machine post reboot
Hi Willy, My default section is = defaults log global modehttp option httplog option dontlognull retries 3 option redispatch maxconn 2000 contimeout 5000 clitimeout 5 srvtimeout 5 My iptable rules = sudo iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination netstat status = netstat --tcp --listening -n -p (Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.) Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp0 0 127.0.0.1:8005 0.0.0.0:* LISTEN 12303/java tcp0 0 0.0.0.0:80090.0.0.0:* LISTEN 12303/java tcp0 0 0.0.0.0:33060.0.0.0:* LISTEN - tcp0 0 0.0.0.0:63790.0.0.0:* LISTEN 1646/redis-server tcp0 0 10.211.154.49:80 http://10.211.154.49/0.0.0.0:* LISTEN - tcp0 0 0.0.0.0:80800.0.0.0:* LISTEN 12303/java tcp0 0 0.0.0.0:22 0.0.0.0:* LISTEN - tcp6 0 0 :::8081 :::*LISTEN - tcp6 0 0 :::22 :::*LISTEN - Firewall status =sudo ufw status Status: inactive Problem is even after shutting down haproxy, req for 80 getting forwarded to 8080, that means request is getting diverted before it reaches to haproxy. But in actual no one listening to port 80 except haproxy. My tomcat is running on 8080 (server.xml) On Tue, Dec 13, 2011 at 11:58 AM, Willy Tarreau w...@1wt.eu wrote: Hi, On Tue, Dec 13, 2011 at 12:27:25AM +0530, Avinash wrote: Hi, We have a Linux machine on which are installed 2 servers (tomcat @ 8080, lighthttpd @ 8081). I am using HAProxy ( @ 80 ) to perform domain base routing to these servers. After a reboot, we restarted the apps(haproxy, lighthttpd, tomcat) and found that haproxy is no longer able to perform routing. Before reboot things were working fine and we did not perform any config/software changes from our end. Here are our haproxy settings : - frontend http_proxy - bind 10.211.154.49:80 http://10.211.154.49/ - option forwardfor - acl is_resource hdr_dom(host) -i resource.qureka.com - acl is_app hdr_dom(host) -i www.qureka.com - use_backend resource_cluster if is_resource - use_backend app_cluster if is_app backend resource_cluster server server1 127.0.0.1:8081 backend app_cluster server server1 127.0.0.1:8080 What does your defaults section look like ? Maybe you accidentely removed a line and are not running in HTTP mode anymore ? Also, one thing which often starts at boot is the firewall. Maybe you were running a firewall on the machine which you manually disabled and forgot to remove it from startup. So after a reboot it starts again and prevents haproxy from connecting to your servers. Those are just a few guesses of course, as it's not very clear what changed during the reboot. Regards, Willy
