Nathan, The question is: why do you want to use the VIP to get connected on your backend server?
Please give a try to the following source line, instead of your current one: source 0.0.0.0 usesrc 10.240.36.13 Baptiste On Tue, Jul 14, 2015 at 9:06 PM, Nathan Williams <nath.e.w...@gmail.com> wrote: > OK, that did not seem to work, so I think the correct interpretation of that > "addr" option must be as an override for what address/port to perform the > health-check *against* instead of from (which makes more sense in context of > it being a server option). > > i was hoping for an option like "health-check-source" or similar, if that > makes sense; I also tried removing the "source" directive and binding the > frontend to the VIP explicitly, hoping that would cause the proxied requests > to originate from the bound IP, but that didn't seem to do it either. While > the standby was then able to see the backends as "up", the proxied requests > to the backends came from the local IP instead of the VIP. > > Regards, > > Nathan W > > On Tue, Jul 14, 2015 at 8:58 AM Nathan Williams <nath.e.w...@gmail.com> > wrote: >> >> Hi Baptiste/Jarno, >> >> Thanks so much for responding. >> >> "addr" does indeed look like a promising option (though a strangely >> lacking explanation in the docs, which explains what it makes possible while >> leaving the reader to deduce what it actually does), thanks for pointing >> that out. >> >> Here's our config: https://gist.github.com/nathwill/d30f2e9cc0c97bc5fc6f >> (believe it or not this is the trimmed down version from what we used to >> have :), but backends, how they propagate in this microservice-oriented >> world of ours... ). >> >> As for addresses, the VIP is 10.240.36.13, and the active/standby local >> addresses are .11 and .12. >> >> fthe problem is basically that the way it's currently configured, when the >> .11 is active and has the .13 address, health-checks from haproxy on the .12 >> host also originate from the .13 address (guessing due to the "source" >> line), and so never return and are (rightfully) marked by haproxy as L4CON >> network timeouts. >> >> i'm going to try the "addr" config and report back; fingers crossed! >> >> cheers, >> >> Nathan W >> >> On Tue, Jul 14, 2015 at 5:21 AM Baptiste <bed...@gmail.com> wrote: >>> >>> On Mon, Jul 13, 2015 at 6:03 PM, Nathan Williams <nath.e.w...@gmail.com> >>> wrote: >>> > Hi all, >>> > >>> > I'm hoping I can get some advice on how we can improve our failover >>> > setup. >>> > >>> > At present, we have an active-standby setup. Failover works really >>> > well, but >>> > on the standby, none of the backend servers are marked as "up" since >>> > haproxy >>> > is bound to the VIP that is currently on the active member (managed >>> > with >>> > keepalived). as a result, there's an initial period of a second or two >>> > after >>> > the failover triggers and the standby claims the VIP where the backend >>> > servers have not yet passed a health-check on the new active member. >>> > >>> > It seems like the easiest way to sort it out would be if the >>> > health-checks >>> > weren't also bound to the VIP so that the standby could complete them >>> > successfully. i do still want the proxied requests bound to the VIP >>> > though, >>> > forthe benefit of our backends' real-ip configuration. >>> > >>> > is that doable? if not, is there some way to have the standby "follow" >>> > the >>> > active-member's view on the backends, or another way i haven't seen >>> > yet? >>> > >>> > Thanks! >>> > >>> > Nathan W >>> >>> Hi Nathan, >>> >>> Maybe you could share your configuration. >>> Please also let us know the real and virtual IPs configured on your >>> master and slave HAProxy servers. >>> >>> Baptiste
