|
hi
I'm sorry to reply after a long time.
But thanks a lot for your suggestions.
Well I did think a lot about supersparrow.
Though it does attempt geographic load balancing,
it suffers from the drawback of people not being ready to
share routing information(according to Joseph Mack).
Secondly I believe that Network Latency + Server Load is the real
problem.Even though a Server is closer, it might be loaded
and thus might take a longer time to reply a request than possibly
a server that's farther away from it.(Please correct me if I am wrong)
And what we aim is to see to it that a request gets handled as soon as
possible.(Again please correct me)
Therefore what one really needs to do is to design a metric based
on network latency + server load which would be used for load balancing.
I found the following suggestion very interesting:
> Wouldn't it be nice if you had hierarchial load balancing - if a servers
> weight didn't only include itself, but also all servers behind it. (Think
> "tree" and "aggregrated weight" in complex server topologies)
>
> And if the node value you computed did not only take the pure machine load
> into account, but also network latency to the remote server, so it would scale
> nicely to distributed environments.
>
What I suggest is that latency is computed using *pseudo requests* to each
lower tier LVS from a *master* director (which would be required in this
architecture.) and measuring their response time.
> A side aspect of this would be to roll out the uptodate configuration
> seamlessly to all nodes from a master node.
Another side aspect would be that the master director would be a critical
point in the architecture in terms of failure.
This can be overcome either:
* by using a redundant master director
* or/and configuring the system such that in case of
such a failure, the LVS's function independently.
How do you pple feel about this idea?(pseudo requests being the central
point)
Has anybody done it before?
ciao
abhijeet
|
