Thanks Jeff, The 'backend' HAProxies do have a purpose - they: * allow stripping global routing information (e.g. from the http path) * allow rate limiting at the worker node (even with many 'client haproxies') * allow for real backends of different types on one node while just having one entry host/port per node (e.g. use global routing info before stripping) * provide a highly tunable HTTP connection terminator to ensure keepalive etc work. * simplify network ACLs by sharing a host/port pair for many different real backends on a node
The configuration challenges of managing all these haproxies is avoided by another system; they would not be configured by hand. However, the one challenge is that this indirect access to the real backend confuses retry logic. /Mike On Wed, Nov 25, 2015 at 12:28 PM, Jeff Palmer <[email protected]> wrote: > 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 >
