|
On Tuesday 08 October 2002 17:39, Roberto Nibali wrote:
> Ok, now I understand. You want to equalize the let's call it fictive load
> imbalance caused by 'cached' session IDs?
And now _I_ am not sure if I understand this...
> > as all servers are available and have a similar load that LVS keeps
> > redirecting you to the same realserver and only reassigns when needed to
> > restore the balance or handle a failover condition.
>
> Why do you want to do this? If all server have similar load and you keep on
> redirecting a session to the same RS, this RS will be overloaded while the
> others start idling. If you distribute the load according to your scheme (if
> I understand it correctly) then you wouldn't send a new incoming connection
> request to a new server.
Sure I would - if either of the following is true: 1) the client's IP address
is new 2) the realserver that would be picked otherwise (e.g. when using true
persistence) is overloaded compared to the others 3) the realserver that
would be picked otherwise is down.
Case 1 is already handled with the normal persistence setting and WLC. Case 3
can be enabled using the sysctl setting in the new LVS.
Case 2 remains then. Suppose you have 9 clients and 3 realservers (all clients
have a different IP).
In case of true persistency each realserver will serve 3 of these clients, ad
infinitum. In case of non-persistency the HTTP requests are spread more or
less randomly over the realservers. This is extremely bad for session state,
since in the end each realserver has to track (and fetch) session data from
all 9 clients, instead of having a balanced set of 3 clients per realserver.
As long as this status quo is there persistency works ok and performs better
than non-persistent connections.
Persistency however is not a 'hard' requirement as it is for e.g. HTTPS, it's
only a 'soft' requirement because it performs better.
Thus, if client 1 turns out to be a masquerading gateway for a NAT-ed network
it will send realserver 1's load much higher than realservers 2 and 3 if we
use the 'normal' persistence.
Therefore it would be nice if LVS could detect that we're only using 'soft
persistency' and reassign two clients to the other realservers. Now RS1 has
the one NAT-ed network, and RS2 and RS3 both serve four other clients,
resulting in both a good balance (almost as good as non-persistency) and ALSO
a strong preference for a single realserver per IP to avoid hitting the
penalty for re-fetching session data.
Another advantage is that changing the weighting to 0 for maintenance will
almost instantly reassign the clients because it's not a technical problem.
Since the reassign is done only once per IP the performance hit is rather
minimal.
> (snip ascii-art)
>
> Does it make sense? Warning: This is one possibility of how the load
> balancer would redirect the incoming requests. I have not taken into account
> the timing and the packet size, but nevertheless it should show you what I
> intended to explain in words before.
Actually it only confused me a bit :/
> That's why you will need persistency. Persistency will assure you that you
> get back to that RS once the session ID is in RAM for that specific client.
That's what we're using now and it works fine during normal operation, but
when pulling a machine down for maintenance it's a PITA, it takes at least
half an hour before all clients are gone from the web sites, and often
longer.
> I say you start using persistency with WLC and if you experience extremely
> load imbalance, I will assure you that we will fix the problem withing 96
> hours.
No, you misunderstood me. It's working fine over longer periods of time. But
not as good as non-persistency works, and especially for maintenance it's
sheer overkill for us.
> Aha, and what number of requests/s + amount of bytes/s and RS machines are
> we talking about?
Three realservers, and currently about 13 Gb/day traffic, but we've had
another site until 2 months ago that pulled 20 Gb/day alone and we expect it
to return shortly. So I better anticipate for that now I still have the time
:-)
The current 13 Gb are made almost entirely between 11:00 am and 11:00 pm, with
the peak in the ~4 hours after dinner. The realservers can handle the load,
it's the database that's getting troubles and moving the session state
storage there doesn't sound like a good idea...
--
Martijn
|
