|
Hello,
On Tue, 11 Jun 2013, Alexander Frolkin wrote:
> Hi,
>
> > > Is there a reason why the SH fallback behaviour shouldn't be default?
> > > That is, is there a reason why the current behaviour (client connection
> > > gets reset if it is directed to a realserver with weight 0) is
> > > desirable?
> > I don't know, the authors preferred this behaviour.
>
> Is it worth looking at changing this? Or is this going to be too
> difficult a change to push through?
I'm not sure how SH is used, may be failed
dests are removed from the list to avoid connection
failures.
> I just don't understand why rejecting a client connection when there are
> servers available is desirable behaviour.
The problem is that every move leads to problems:
- add/remove destination => mapping is changed for all dests
- set weight to 0 and allow fallback => mapping is changed for
two connections from same IP
As result, it is a bad idea to remove dests that are
failed. In such case, without fallback some clients are not
served, forever. But with fallback we can break the
implicit persistence. I see two kinds of uses:
- persistence implemented with SH => fallback is risky. Usually,
we use expire_quiescent_template for such cases when persistence
is used.
- same mapping for many directors => fallback is desired when
config is same on all directors and persistence behaviour is
not desired.
So, it really depends what are our goals when using SH.
Not sure if we can apply the expire_quiescent_template flag to
the SH scheduler to control fallback.
Regards
--
Julian Anastasov <ja@xxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|
