Many BADREQ and NOSRV entries in the log
Hello list, I'm getting some (~400 per hour) ... entries in my log file. I've tried temporarely accept-invalid-http-request with no success, also I've set the "timeout http-request" parameter to 30s, with no difference. Partial log of the BADREQ: http://pastebin.com/uHJ2qztb My haproxy.cfg file: http://pastebin.com/EJi18bqV The only error I've spotted trough the socket is: root@loadbalancer-1:/var/log# echo "show errors" | socat unix-connect:/tmp/haproxy stdio [16/Nov/2011:14:46:46.506] frontend balancer (#1): invalid request src 92.242.138.134, session #4196, backend balancer (#1), server (#-1) request length 73 bytes, error at position 14: 0 GET /s/camisa da marca reserva/15 HTTP/1.0\r\n 00044 Host: www.example.com.br\r\n 00071 \r\n I don't know if I should ignore this, or what to try. I would appreciate any hint!
Re: HA for HAProxy in Amazon Cloud
On 11/17/2011 10:55 PM, Mir Islam wrote: Hi Guys, I am wondering how people are solving the problem of HAProxy becoming SPOF. I am using HAproxy in Amazon cloud for SSL stick session and load balancing, but best solution I could come up with for making HAProxy HA is by having another exact instance as hot standby. Then monitor the active one periodically and if it goes down, move the elastic IP associated with HAP1 to HAP2. Is there some other way folks are solving this issue? Remember, on Amazon cloud instances they do not have any public IP associated with the actual interface. So can't create virtual interface/ip and move it around like in traditional "heart beat" type of systems. Thanks Mir Hi, I'm doing exactly the same. I set up an heartbeat 2 node cluster (active/passive), defined 2 custom ocf resources (the elastic ip and the haproxy daemon) and grouped them to act together. The most tricky part for me was the heartbeat monitoring function because AWS API calls are really slow and tend to time out. Anyway, haproxy is running nicely, so far we are getting ~300 r/s
Re: HA for HAProxy in Amazon Cloud
Firts, sorry HAproxy list for the OT. I would say it takes an average of 5 seconds. Also please note that Amazon _seems_ to throttle your API requests if you exceed certain number of requests, sometimes the API failed with "unable to connect to ..." (I've noticed that while performing the monitoring function of the OCF resource) On 11/18/2011 03:34 PM, Mir Islam wrote: So on avg how long it took for the AWS api call to transfer the IP to standby HA Proxy? I am wondering if it makes to go with just auto scale and define minimum 1 server. Thanks Mir On Nov 18, 2011, at 4:26 AM, Mariano Guezuraga wrote: On 11/17/2011 10:55 PM, Mir Islam wrote: Hi Guys, I am wondering how people are solving the problem of HAProxy becoming SPOF. I am using HAproxy in Amazon cloud for SSL stick session and load balancing, but best solution I could come up with for making HAProxy HA is by having another exact instance as hot standby. Then monitor the active one periodically and if it goes down, move the elastic IP associated with HAP1 to HAP2. Is there some other way folks are solving this issue? Remember, on Amazon cloud instances they do not have any public IP associated with the actual interface. So can't create virtual interface/ip and move it around like in traditional "heart beat" type of systems. Thanks Mir Hi, I'm doing exactly the same. I set up an heartbeat 2 node cluster (active/passive), defined 2 custom ocf resources (the elastic ip and the haproxy daemon) and grouped them to act together. The most tricky part for me was the heartbeat monitoring function because AWS API calls are really slow and tend to time out. Anyway, haproxy is running nicely, so far we are getting ~300 r/s
