Mike, Help me understand:
if haproxy 1 is just frontending haproxy 2 and 3, which each only have 1 backend.. what is the purpose of haproxy2 and 3, other than to just complicate the architecture? are they serving some other purpose that isn't being communicated? If not, I'd say follow the KISS principle. have haproxy1 utilize the 2 backends directly. and let it detect backend availability as it's designed to do. On Wed, Nov 25, 2015 at 3:00 PM, Mike Sample <[email protected]> wrote: > In a setup like this where HAProxy1 LBs over N other HAProxies (servers in a > backend of HAProxy1): > > HAProxy1 > | --> HAProxy2 -> 1 real backend server > | --> HAProxy3 -> 1 real backend server > > Is there a way to trigger a retry by HAProxy to use HAProxy3 if it tried > HAProxy2 and just its real backend server was down? i.e. HAProxy1 > successfully connected to HAProxy2 but HAProxy2 returned a 503 because its > one backend server was down. > > The goal is that the initial call into HAProxy1 succeeds by using the > HAProxy3, even though it tried HAProxy2. > > I looked at the 'observe' server option but my read of the config manual is > that it won't trigger a retry (just a failed health check). I also realize > that, in general, retrying on a 503 has idempotency issues so using a custom > 5xx code might be a better signal to indicate no-work was done. > > Thanks -- Jeff Palmer https://PalmerIT.net
