|
Hello Ratz,
On Wed, 9 Jul 2003, Roberto Nibali wrote:
>
> Forgot one thing: As soon as IP_VS_DEST_F_OVERLOAD is removed from one RIP
> the
> overflow pool will not be taken anymore. As I have running such a setup with
> various customers I can tell you from experience that you can run into two
> problems here which I haven't solved yet:
>
> 1. Problem: RIP pool <---> overflow pool pingpong with long lasting peak load
>
> You're having a peak load which results in the pool being activated. Now,
> due
> to a lower treshold which is close to the upper treshold, one or two of
> the
> RIPs come back fast again but the peak load is not over. You will end up
> in
> a RIP pool <---> overflow pool pingpong until the peak is flattened out
> again.
>
> 2. Problem: persistency inheritance on overflow pools yields bad behaviour for
> monitoring sites.
>
> Imagine you set up a service which uses persistency. Now in the current
> case
> the overflow pool servers will inherit the persistency flag. This is of
> course extremely bad when you monitor a site. Why? Because if you monitor
> with a 1 minute interval and the session template timeout is higher than 1
> minute you will get a session overload page even though all RIPs will
> already
> be back functional. This is my biggest problem in 2.2.x righ now :)
>
> 1. Solution:
>
> We can say that we don't care and that this is a rather high hypothetical
> case and do nothing about it. Or we include a means by which you can say
> when or better starting from how many RS need to be back until we switch
> to the RIP pool again.
>
> 2. Solution:
>
> I think the only solution to this is to have no inheritance on the
> overflow
> pool servers when it comes to persistency. I would even go as far as not
> to
> allow persistency for overflow servers.
>
> Another possibility is that the persistency flag is set through
> inheritence
> but is generally discarded with some settable flag.
>
> What do you think?
>
I think that it depends on what the overflow pool is for. If the overflow
pool still provides the service as the normal server pool, we have to
consider the persistency feature for the overflow pool, because the
network services may require persistency. If the overflow pool is only to
show pages that "The system is busy, please come back later", then it is
easy to do, we don't need consider the persistency for overflow pool.
Maybe users will mostly use the second one. Anyway, we need think more
about it and make a decision.
Thanks,
Wensong
|
