Re: problem with forwardfor option
On Wed, Jan 21, 2009 at 02:34:23AM +0100, Patrick Viet wrote: > On Wed, Jan 21, 2009 at 12:58 AM, Dima Brodsky wrote: > > > I am running haproxy (HA-Proxy version 1.3.15.7 2008/12/04) and I am having > > problems with the forwardfor option. > > Hi > > Please read my answer a couple days ago. > http://www.formilux.org/archives/haproxy/0901/1678.html > > Willy you might want to add that to the HAProxy FAQ if there is one. > Or at least somewhere in the documentation. Yes Patrick, I will. I have already noticed some quite common questions. I just need to find time to put them together. Regards, Willy
Re: problem with forwardfor option
On Wed, Jan 21, 2009 at 12:58 AM, Dima Brodsky wrote: > I am running haproxy (HA-Proxy version 1.3.15.7 2008/12/04) and I am having > problems with the forwardfor option. Hi Please read my answer a couple days ago. http://www.formilux.org/archives/haproxy/0901/1678.html Willy you might want to add that to the HAProxy FAQ if there is one. Or at least somewhere in the documentation. Regards, -- Patrick Viet
problem with forwardfor option
Hi, I am running haproxy (HA-Proxy version 1.3.15.7 2008/12/04) and I am having problems with the forwardfor option. In particular I am seeing about 50% of the requests leave haproxy and hit the apache server behind in without an X-Forwarded-For header. I am not sure whether the problem is a bug or a misconfiguration. Here is my config: global log 127.0.0.1 local0 maxconn 1 chroot /usr/share/haproxy pidfile /var/run/haproxy.pid user haproxy group haproxy daemon defaults mode http retries3 clitimeout 15 srvtimeout 3 contimeout 4000 option redispatch listen webproxy :80 mode http log 127.0.0.1 local0 reqidel ^X-Forwarded-For:\ reqaddX-Worio-FE:\ 10.251.163.95 optionforwardfor balance roundrobin serverfe1 10.251.163.95:8080 # HTTP response : 'HTTP/1.0 200 OK' listen http_health_check 0.0.0.0:60001 mode health option httpchk any ideas as to what could be wrong? Thanks! ttyl Dima -- d...@worio.com http://www.cs.ubc.ca/~dima "The price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich find the most hard to pay." (Sir Antony Hoare, 1980)
Re: HAProxy: listening port set up and performance
Hi, On Tue, Jan 20, 2009 at 09:45:32AM -0800, Hsin, Chih-fan wrote: > About 2) TCP testing, you are right. When I was doing the basic functional > testing, I used a 100Mbps hub. That is why. OK. > About 1), when the client browses to http://192.168.5.3, it got a "page > cannot be displayed" error. When the client browses to http://192.168.5.3:80, > it got the correct Apache default index.html page. I think that the reason is > in the HAProxy (with ip 192.168.5.3) configuration file, it listens to > 192.168.5.3:80, this specific port. I don't understand what you mean. When you send your browser to "http://192.168.5.3/";, it specifically connects to port 80. So it is normal that you configure port 80 in haproxy config file. What is not expected is that when you don't specify the port it does not work. I think that your "host:" field is different between both cases and that your apache makes a specific case for one of these. Most likely it tries to perform a redirect to a wrong address, or something like this. Also, I see that you never write the trailing "/" after your addresses above, you should make sure that you put it, as some browsers behave badly when it is not set (as it is not a valid syntax, they are fixing it for you). Once again, I really think that you have some strange virtual hosting config on your apache. Could you check the exact message that is returned to your browser ? "page cannot be displayed" is not a valid error, it's some cross-dressing performed by internet explorer to hide real errors not to scare users. Also, have you enabled the logs as I asked you to ? The response to your problem is there. If you see that you don't receive the request, you'll know that your browser is not sending it. If you see a 302 response, you'll know that apache is doing a redirect to a wrong address. If you see 4xx or 5xx, you'll know that something else goes wrong either with the request or the response. > Suppose that the client does not know what port HAProxy is > listening to. HTTP is on port 80 when unspecified. > Client usually only connects to the ip address, not the ip+port, Huh ??? What are you talking about ? TCP is a transport protocol. It implies a port. It is not possible to connect to an IP address and does not make any sense. You connect to ip+port, period. The client must select a default port when you don't set it, but every browser I have seen always use port 80. You have never seen a commercial ad asking you to connect to http://www.domain.com:80/, have you ? That's because the browser will connect to port 80 unless specified otherwise. > similar to client browsing to http://192.168.5.3. In this case, > how should I configure the listening part (only listening to ip > address?) at HAProxy? No no no. Your client connects to port 80 and haproxy will listen to an IP+port couple. If it works with http://IP:80/, it works with http://IP/ as it's the same. It would be interesting to check with tcpdump (or wireshark) on the client what is been sent on the wire, and what is received. Last, you can also test this from your client : # telnet 192.168.5.3 80 Trying 192.168.5.3... Connected to 192.168.5.3. Escape character is '^]'. GET / HTTP/1.0 HTTP/1.0 200 OK ... Connection closed. # telnet 192.168.5.3 80 Trying 192.168.5.3... Connected to 192.168.5.3. Escape character is '^]'. GET / HTTP/1.0 Host: 192.168.5.3:80 HTTP/1.0 200 OK ... Connection closed. # telnet 192.168.5.3 80 Trying 192.168.5.3... Connected to 192.168.5.3. Escape character is '^]'. GET / HTTP/1.0 Host: 192.168.5.3 HTTP/1.0 200 OK ... Connection closed. If all above work, the problem is on your client. If only the second one works, the problem is on your apache configuration (the only one to consider the Host: field). Hoping this helps, Willy > Chih-fan Hsin > -Original Message- > From: Willy Tarreau [mailto:w...@1wt.eu] > Sent: Monday, January 19, 2009 8:26 PM > To: Hsin, Chih-fan > Cc: haproxy@formilux.org > Subject: Re: HAProxy: listening port set up and performance > > Hi, > > On Mon, Jan 19, 2009 at 06:11:13PM -0800, Hsin, Chih-fan wrote: > > Hi, I am new to HAProxy and have questions about the configuration and > > performance. > > > > I downloaded HAProxy 1.3.15.7 from > > http://haproxy.1wt.eu/http://haproxy.1wt.eu/> to /home/user/Tool > > Unpacked it by "tar xopf name.tar.gz.tar" > > Run "make TARGET=linux26" > > > > 1) Apache HTTP testing > > Servers webA (192.168.5.4) and webB (192.168.5.5) have Apache server > > started. > > Client (192.168.5.1) sends http requests to webA (192.168.5.4:80) and > > webB (192.168.5.5:80), and can get valide http response (default Apache > > response). > > [client] -> [webA],[webB] > > > > Now, the HAProxy does not have Apache server and has IP address > > 192.168.5.3. > > At HAProxy, run "./haproxy -f ./haproxy1.cfg". The haproxy1.cfg is > > below > > [client] -> [HAProxy] -> [webA],[webB]. > >
RE: HAProxy: listening port set up and performance
About 2) TCP testing, you are right. When I was doing the basic functional testing, I used a 100Mbps hub. That is why. About 1), when the client browses to http://192.168.5.3, it got a "page cannot be displayed" error. When the client browses to http://192.168.5.3:80, it got the correct Apache default index.html page. I think that the reason is in the HAProxy (with ip 192.168.5.3) configuration file, it listens to 192.168.5.3:80, this specific port. Suppose that the client does not know what port HAProxy is listening to. Client usually only connects to the ip address, not the ip+port, similar to client browsing to http://192.168.5.3. In this case, how should I configure the listening part (only listening to ip address?) at HAProxy? Chih-fan Hsin -Original Message- From: Willy Tarreau [mailto:w...@1wt.eu] Sent: Monday, January 19, 2009 8:26 PM To: Hsin, Chih-fan Cc: haproxy@formilux.org Subject: Re: HAProxy: listening port set up and performance Hi, On Mon, Jan 19, 2009 at 06:11:13PM -0800, Hsin, Chih-fan wrote: > Hi, I am new to HAProxy and have questions about the configuration and > performance. > > I downloaded HAProxy 1.3.15.7 from > http://haproxy.1wt.eu/http://haproxy.1wt.eu/> to /home/user/Tool > Unpacked it by "tar xopf name.tar.gz.tar" > Run "make TARGET=linux26" > > 1) Apache HTTP testing > Servers webA (192.168.5.4) and webB (192.168.5.5) have Apache server > started. > Client (192.168.5.1) sends http requests to webA (192.168.5.4:80) and > webB (192.168.5.5:80), and can get valide http response (default Apache > response). > [client] -> [webA],[webB] > > Now, the HAProxy does not have Apache server and has IP address > 192.168.5.3. > At HAProxy, run "./haproxy -f ./haproxy1.cfg". The haproxy1.cfg is below > [client] -> [HAProxy] -> [webA],[webB]. > Client sends http request to HAProxy via IE web browing to > http://192.168.5.3. However, the client cannot get web response. By this, do you mean that no response ever comes back, or that you get an error ? > Client sends http request to HAProxy via multiple IE web browsing to > http://192.168.5.3:80. Then it works. Are you sure that your apache machines don't block access from haproxy ? Also, do you have any form of virtual hosting on those machines, which would refuse requests with a "Host:" field with a wrong IP address in it ? > haproxy1.cfg file >listen webfarm 192.168.5.3:80<- How do I decide the correct > port number to make http://192.168.5.3 work? This is the correct form. >mode http >balance roundrobin >cookie SERVERID insert indirect >stats enable >server webA 192.168.5.4:80 cookie A check >server webB 192.168.5.5:80 cookie B check I see that you have not configured timeouts. This is bad (though it should not cause you the problem you're seeing). Please add the following lines to the section above : timeout client 30s timeout server 30s timeout connect 5s Also, you should log, you would see in the logs what is wrong. For this, please add the following line : log 127.0.0.1 local0 Then ensure that your syslogd listens to the UDP socket (syslogd -r), and check the log files (you will see one line added when you start haproxy, then one line per request). > 2) TCP testing (using Iperf) > Servers webA (192.168.5.4) and webB (192,168.5.5) run Iperf TCP sink to > listen to port 5001 > Client runs 2 Iperf TCP connections and send traffic to 192.168.5.3:80 > At HAProxy, run "./haproxy -f ./haproxy2.cfg" > haproxy2.cfg > listen webfarm 192.168.5.3:80 >mode tcp >balance roundrobin >stats enable >server webA 192.168.5.4:5001 >server webB 192.168.5.5:5001 > I can achieve 36Mbps each under the following scenario. > [client] -> 36Mbps -> [webA] > |->36Mbps -> [webB] 36 Mbps ??? You definitely have something wrong in your setup ! This is the bandwidth you could expect from a saturated 100 Mbps HUB at maximal collision rate !!! Please check that all your connections are made to a switch and not a hub, and that all your hosts have negociated full duplex (with ethtool). > However, when I use HAProxy, I can only achieve 18Mbps each. The > utilization of HAProxy machine is low. > [client] -> [HAProxy] -> 18Mbps -> [webA] > |> 18Mbps -> [webB] > Is this normal? Is there any way to improve it? No it's not normal, but expected from the bad numbers above. If you are using a hub which is saturated, then making the traffic pass twice over it will half the per-host bandwidth. Right now, it does not make sense to use a hub for network testing, not even a 100 Mbps switch. Gigabit switches are very cheap, you can find a 5-p
Re: Balancing OpenLDAP
On Tue, Jan 20, 2009 at 07:43:25PM +0800, Unai Rodriguez wrote: > How about writing a bash script that checks LDAP status somehow and have > this script managed by xinetd? > > The script should return "HTTP/1.1 200 OK\r\n" if the LDAP server is > fine or something else if not (e.g. "HTTP/1.1 503 Service Unavailable\r\n"). > > Xinetd could be configured in such a way that the script is invoked upon > connecting to a defined port, let's say 9200. > > Then, we could have on the HAProxy configuration something like this: > > listen LDAP IP:389 > modetcp > option httpchk > server ldap_srv1 ip:389 check port 9200 inter 5000 rise 3 fall 3 > > What would you think of that approach? it is the usual way of performing complex checks. An alternative method consists in referencing the LDAP script itself in inetd. Willy
Re: Balancing OpenLDAP
How about writing a bash script that checks LDAP status somehow and have this script managed by xinetd? The script should return "HTTP/1.1 200 OK\r\n" if the LDAP server is fine or something else if not (e.g. "HTTP/1.1 503 Service Unavailable\r\n"). Xinetd could be configured in such a way that the script is invoked upon connecting to a defined port, let's say 9200. Then, we could have on the HAProxy configuration something like this: listen LDAP IP:389 modetcp option httpchk server ldap_srv1 ip:389 check port 9200 inter 5000 rise 3 fall 3 What would you think of that approach? unai Willy Tarreau wrote: On Mon, Jan 19, 2009 at 10:16:46PM +0100, Jordi Espasa wrote: Jordi's question got me thinking. Does haproxy support externally scripted healthchecks? If not, this would be useful for implementing a variety of healthchecks that aren't built into haproxy. Yes. It would be a very cool feature. No it does not. Yes it would be cool, but it's somewhat incompatible with chroot. The possible long-term solutions include : - shared library support, in order to load external plugins, including complex health-checks plugins ; - performing the checks in an independant process. That would be very nice since it would allow better support for multi-process usage. Another solution would be to state that chroot is incompatible with external scripts, and let the user make a choice. Maybe we can try to think about the required parameters for an external script, and see how that could be implemented. We might even reuse some parts of what I had developped for Keepalived (VRRP tracking scripts). It was quite advanced (cache of last result, etc...), and keepalived's and haproxy's architectures are quite similar. Now, speaking about the LDAP checks, I was about to implement one in the past due to a customer's need, and finally let go because the customer was not interested due to some aspects which were not covered (detection of end of replication). So right now there's no LDAP check. Regards, willy
