Re: Question about TCP balancing
On Thu, Aug 06, 2009 at 12:33:02PM +0400, Dmitry Sivachenko wrote: So I should stick with 1.4 for that purpose, right? exactly. However, keep in mind that 1.4 is development, and if you upgrade frequently, it may break some day. So you must be careful. Okay, what is the estimated release date of 1.4 branch? around december if everything goes well. Willy
Re: Question about TCP balancing
On Thu, Aug 06, 2009 at 12:03:25AM +0200, Willy Tarreau wrote: On Wed, Aug 05, 2009 at 12:01:34PM +0400, Dmitry Sivachenko wrote: On Wed, Aug 05, 2009 at 06:30:39AM +0200, Willy Tarreau wrote: frontend my_front acl near_usable nbsrv(near) ge 2 acl far_usable nbsrv(far) ge 2 use_backend near if near_usable use_backend far if far_usable # otherwise error backend near balance roundrobin server near1 1.1.1.1 check server near2 1.1.1.2 check server near3 1.1.1.3 check backend far balance roundrobin server far1 2.1.1.1 check server far2 2.1.1.2 check server far3 2.1.1.3 check Aha, I already came to such a solution and noticed it works only in HTTP mode. Since I actually do not want to parse HTTP-specific information, I want to stay in TCP mode (but still use ACL with nbsrv). So I should stick with 1.4 for that purpose, right? exactly. However, keep in mind that 1.4 is development, and if you upgrade frequently, it may break some day. So you must be careful. Okay, what is the estimated release date of 1.4 branch?
Re: Question about TCP balancing
On Wed, Aug 05, 2009 at 06:30:39AM +0200, Willy Tarreau wrote: frontend my_front acl near_usable nbsrv(near) ge 2 acl far_usable nbsrv(far) ge 2 use_backend near if near_usable use_backend far if far_usable # otherwise error backend near balance roundrobin server near1 1.1.1.1 check server near2 1.1.1.2 check server near3 1.1.1.3 check backend far balance roundrobin server far1 2.1.1.1 check server far2 2.1.1.2 check server far3 2.1.1.3 check Aha, I already came to such a solution and noticed it works only in HTTP mode. Since I actually do not want to parse HTTP-specific information, I want to stay in TCP mode (but still use ACL with nbsrv). So I should stick with 1.4 for that purpose, right? Or does HTTP mode acts like TCP mode unless I actually use something HTTP-specific? In other words, will the above configuration (used in HTTP mode) actually try to parse HTTP headers (and waste cpu cycles for that)? Thanks.
Re: Question about TCP balancing
Hello! Thanks for clarification. I have another question then (trying to solve my problem in a different way). I want to setup the following configuration. I have 2 sets of servers (backends): let call one set NEAR (n1, n2, n3) and another set FAR (f1, f2, f3). I want to spread incoming requests between NEAR servers only when they are alive, and move load to FAR servers in case NEAR set is down. Is it possible to setup such configuration? I read the manual but did not find such a solution... Thanks in advance! On Mon, Aug 03, 2009 at 09:46:47PM +0200, Willy Tarreau wrote: No it's not, and it's not only a configuration issue, it's an OS limitation. The only way to achieve this is to stop listening to the port then listen again to re-enable the port. On some OSes, it is possible. On other ones, you have to rebind (and sometimes close then recreate a new socket). But once your process has dropped privileges, you can't always rebind if the port is 1024 for instance. So instead of having various behaviours for various OSes, it's better to make them behave similarly. I have already thought about adding an OS-specific option to do that, but I have another problem with that. Imagine that your servers are down. You stop listening to the port. At the same time, someone else starts listening (eg: you start a new haproxy without checking the first one, or an FTP transfer uses this port, ...). What should be done when the servers are up again ? Haproxy will not be able to get its port back because someone else owns it. So, by lack of a clean and robust solution, I prefer not to experiment in this area.
Question about TCP balancing
Hello! I am trying to setup haproxy 1.3.19 to use it as TCP load balancer. Relevant portion of config looks like: listen test 0.0.0.0:17000 mode tcp balance roundrobin server srv1 srv1:17100 check inter 2 server srv2 srv2:17100 check inter 2 server srv3 srv3:17100 check inter 2 Now imagine the situation that all 3 backends are down (no program listen on 17100 port, OS responds with Connection Refused). In that situation haproxy still listens port 17100 and closes connection immediately: telnet localhost 17101 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Connection closed by foreign host. Is it possible to configure haproxy so it will stop listening the port when all backends are down? So clients will receive Connection Refused as if none listens TCP port at all? Thanks in advance!
Re: Question about TCP balancing
Hello Dmitry, On Mon, Aug 03, 2009 at 02:24:47PM +0400, Dmitry Sivachenko wrote: Hello! I am trying to setup haproxy 1.3.19 to use it as TCP load balancer. Relevant portion of config looks like: listen test 0.0.0.0:17000 mode tcp balance roundrobin server srv1 srv1:17100 check inter 2 server srv2 srv2:17100 check inter 2 server srv3 srv3:17100 check inter 2 Now imagine the situation that all 3 backends are down (no program listen on 17100 port, OS responds with Connection Refused). In that situation haproxy still listens port 17100 and closes connection immediately: telnet localhost 17101 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Connection closed by foreign host. Is it possible to configure haproxy so it will stop listening the port when all backends are down? So clients will receive Connection Refused as if none listens TCP port at all? No it's not, and it's not only a configuration issue, it's an OS limitation. The only way to achieve this is to stop listening to the port then listen again to re-enable the port. On some OSes, it is possible. On other ones, you have to rebind (and sometimes close then recreate a new socket). But once your process has dropped privileges, you can't always rebind if the port is 1024 for instance. So instead of having various behaviours for various OSes, it's better to make them behave similarly. I have already thought about adding an OS-specific option to do that, but I have another problem with that. Imagine that your servers are down. You stop listening to the port. At the same time, someone else starts listening (eg: you start a new haproxy without checking the first one, or an FTP transfer uses this port, ...). What should be done when the servers are up again ? Haproxy will not be able to get its port back because someone else owns it. So, by lack of a clean and robust solution, I prefer not to experiment in this area. Regards, Willy
