|
Hello,
On Fri, 5 Jul 2002, Benoit Gaussen wrote:
> Hi,
>
> While digging around LVS code, I saw this is_overloaded() function, that
> is present in many schedulers (dh, sh, lblc, lblcr) :
>
> static inline int is_overloaded(struct ip_vs_dest *dest)
> {
> if (atomic_read(&dest->activeconns) >
> atomic_read(&dest->weight)*2) {
> return 1;
> }
> return 0;
> }
>
>
> This code seems to prevent scheduling to a real server if it has
> more than twice its weight of active connections.
Looking into the sources it seems it does not prevent
scheduling, at least, for LBLC*. LBLC* use this event to start
to reschedule and by this way to break locality awareness (first
2 letters from the scheduler name :)). SH and DH simply give up
and recommend the bypass feature. It seems all these schedulers
have a special policy for using big weights in the range of the
active conns.
> I see two problems here :
> - it is an implicit limitation of connections (ok it's why
> the function is here). There is no information about that in man...
> Moreover an attacker could open a lot of connections and disable a
> real server.
You are almost right for the attacks but note that no
traffic is stopped/dropped.
> - there is a comparison of two values that I think are not
> equivalent and can't be compared.
You are again right. But is there a better solution?
In such cases the clients are "internal" and the bypass feature
is enabled.
> Is this function really needed ?
It seems so. The recommendation is to use weights
high enough to compare with the load and not to serve attackers :)
> If ratz per real server limitation threshold get to LVS (and I hope
> so...), this function will be redondant.
The mentioned schedulers are not in the authorized list
of schedulers provided from Ratz, I see only wlc and wrr. So,
as always the problem is what better can be done.
> Regards,
>
> Ben.
Regards
--
Julian Anastasov <ja@xxxxxx>
|
