On Thu, Nov 05, 2009 at 10:00:19AM +0000, Matt wrote: (...) > > Yes this makes sense and is a very common setup in fact. > > You just have to wonder why you want your haproxy to sit between > > two networks. Maybe you're bypassing a firewall, which is not good > > security-wise. I think that's why Michael asked you if your haproxy > > machine was going to be the gateway for the servers, because it > > could have made sense that this machine was the router/fw between > > the two LANs. > > > > Also, when building HA clusters, it's a good idea to set > > /proc/sys/net/ipv4/ip_non_local_bind to 1. It will allow a process > > from one machine to bind to a service address it doesn't yet own > > (typically the backup server). At the beginning you don't need this > > because you use *:80, but quite soon you may support multiple > > service addresses on the same port and you will need this. > > So if I was to have a route for the 10.x network on the backend > servers that used the haproxy servers as a gateway, I guess this would > cause issues?
Not particularly, provided that your haproxy machines have IP forwarding enabled. > I could get around this however by having the backend > servers on the 10.x network, all requests would still go through > haproxy though as the backend server sees the VIP as the source IP > right? They would not see the VIP but the machine's own IP address as the source. But yes, you're right, you can have your servers on the same LAN as your load balancer (and it's a lot easier to manage that way). > So the /proc/sys/net/ipv4/ip_non_local_bind option would enable me to > have the VIP:80 in the config file even though the VIP is not yet > assigned to that server? Yes. However if you have a "listen" section dedicated to stats, I recommend that you leave it on 0.0.0.0:XXXX so that you can consult both LB's views of your servers' status at any time. Regards, Willy
