Hello Joel,
On Tue, Oct 23, 2012 at 12:54:46PM -0700, Joel Krauska wrote:
> 1. 'Stats only backend'
> I'd like to keep stats for a certain matching condition, but don't
> want to define the same backend twice.
>
> eg.
> use_backend one if { hdr_dom(host) -i one }
> use_backend two if { hdr_dom(host) -i two }
>
> backend one
> cookie SID insert indirect
> server app-01:8080 app-01:8080 cookie app1-8080 check inter 3s
> rise 2 fall 2 maxconn 255
> server app-02:8080 app-02:8080 cookie app2-8080 check inter 3s
> rise 2 fall 2 maxconn 255
> option httpchk GET /healthcheck.html
> stats admin if TRUE
>
> backend two
> # MADE UP COMMAND IS HERE
> use_backend one
>
> Not sure if stats for one should == stats for one + stats for two, or
> if it would be better for hits to two to only count on two...
> I think my preference would be that stats would only count against backend
> two.
> Obviously you need to be careful not to allow for backend looping.
Well, you see, I don't even understand what the config above is supposed
to do nor how it's supposed to work. This alone is a good reason for not
permitting this. Maybe it would be simpler to have the ability to ignore
stats for some requests based on rules ?
> 2. 'backend with backup backend'
> Fall through to a different backend if primary servers are unavailable
> (similar to backup server -- but not requiring defining groups twice
> if there's some overlap in pool definitions)
>
> use_backend one if { hdr_dom(host) -i one }
> use_backend two if { hdr_dom(host) -i two }
>
> backend one
> cookie SID insert indirect
> server app-01:8080 app-01:8080 cookie app1-8080 check inter 3s
> rise 2 fall 2 maxconn 255
> server app-02:8080 app-02:8080 cookie app2-8080 check inter 3s
> rise 2 fall 2 maxconn 255
> option httpchk GET /healthcheck.html
> stats admin if TRUE
>
> backend two
> server app-03:8080 app-03:8080 cookie app1-8080 check inter 3s
> rise 2 fall 2 maxconn 255
> server app-04:8080 app-04:8080 cookie app2-8080 check inter 3s
> rise 2 fall 2 maxconn 255
> # MADE UP COMMAND IS HERE
> backup_backend one
Similarly, here how are the backend-specific rules supposed to be handled ?
For example, one backend removes some headers and performs some redirects,
the other one does similarly but for other headers and base on other rules,
it's very difficult to say what will be done and what will not. Nowadays,
backends do more than simply host servers. The choice should be made in
the frontend.
A long time ago I wanted to separate server groups from backends, the idea
was that a backend contains all processing rules and uses a server group,
and the server group has the servers, their health checks and stats, so
we could share the same pools between backends and share the same maxconn
on servers between backends. But as time passes and based on the configs
I have seen, I'm much less convinced about this right now. I'm used to
see things as simple as having different server maxconns or weights in
different backends for various reasons, etc... So in the end most of the
supposed users of such features would end up having to continue to work
as they do today due to minor differences making it impossible to share
the servers.
> 3. 'backend macro includes'
> Similar in concept to #1, but maybe more flexible.
>
> use_backend one if { hdr_dom(host) -i one }
> use_backend two if { hdr_dom(host) -i two }
>
> backend_macro macro-one
> cookie SID insert indirect
> server app-01:8080 app-01:8080 cookie app1-8080 check inter 3s
> rise 2 fall 2 maxconn 255
> server app-02:8080 app-02:8080 cookie app2-8080 check inter 3s
> rise 2 fall 2 maxconn 255
> option httpchk GET /healthcheck.html
> stats admin if TRUE
>
> backend one
> # MADE UP COMMAND IS HERE
> include_backend_macro macro-one
>
> backend two
> # MADE UP COMMAND IS HERE
> include_backend_macro macro-one
The idea of a macro is not bad at all, because it allows one to change
settings just afterwards. It would also generate many new questions on
the mailing list, I'm sure, but that may be studied a little bit.
What problem do you have *really* that justifies trying to optimize this ?
I mean, the defaults section were introduced because some configs involving
hundreds to thousands of proxies were hard to maintain (eg: change all
timeouts using sed). Maybe there is a valid use case for you that is
shared by many others and we should probably start to think from this
point.
Willy
