|
abhijeet wrote:
> Well , I did suggest a mechanism for avoiding loops.
you suggested that one was needed but you didn't give one.
> Do you mean that such a mechanism is not possible?
I don't know. I haven't got one and you don't have one that's all.
I may not understand your scheme.
> 1.> In the first mail I had suggested simply what Lars had mentioned:
> i.e.
> * more than one POPs
> * each POP is a LVS
> * there is a master director(which has the VIP).This director
> does the load balancing amongst the LVS's(POPs).Hence two tier.
> The master director may or may not have realservers behind it.
Lars scheme seems to have 2 layers of directors, a master machine
and a director at each POP, which is what I was suggesting too.
> 2.> In the second one I had modified Lars's idea a bit:
> * more than one POP.
> * each POP is an LVS
> * The request is first load balanced by DNS RR or by one of the POPs
> (the one that has VIP).
If you are using VS-DR, all directors will have the VIP. I assume you
mean the master director.
> * Each POP(LVS-Director) has a redirection capability.
this is the hard bit. Do you have a scheme for this?
> This may lead to loops but here my mechanism for loop avoidance takes
> over. Lets just say that since the redirections would need IP encapsulation,
> we have some information to avoid loops in the (outer IP) packets.
> * This way , the master director
> - wouldn't be needed (DNS-RR)
> But DNS RR would simply continue directing even in case of a failure.
>
> Well that means that a master director *is* required and is unavoidable.(?)
in the scheme here yes.
> I am sorry for troubling you, I guess it was just a rush of blood.
We've all had rushes of blood here. It normal and we don't
get anywhere without them. The only way to get good ideas
is to have a lot of ideas and throw away the bad ones
(Linus Pauling).
> The pseudo request mechanism would take up a lot of time.
Not really. A request every second won't be noticed and will keep
the master director reasonably well informed of the status of the remote sites.
Heartbeats are normal in processes that need to check the health of other
processes.
> The FAQ says that no one would goto the pain of doing that because of the
> success of supersparrow.
That's just my editorial personal opinion. It's not the ultimate truth.
(ahem, I've rephrased this for the next version of the HOWTO).
What I'm trying to say is that when you have a system that does what you
want, but does it in a way that you didn't want AND you don't have
a system that does what you want in the way you want, people usually
use the system that works.
In your case you have the interest and time to do something different.
You could make supersparrow compatible with LVS (talk to Horms first
to see if he thinks it is doable or worth doing).
> But wouldn't a Load sharing algorithm based on a
> metric derived from the routing information be useful as well?
yes very
> ( I am assuming a simple two tier architecture here as in '1' above(Lars's
> idea))
> Horms, could you please tell me what you think about this?
>
> All I can say is that such a project would
> a.> interest us
> b.> be a very good learning experience
> c.> may or may not be useful commercially.
>
> As far as the availability of a BGP(or any other) router goes, we could
> configure one for ourselves in the Lab.Couldn't we?
yes. Presumably you can setup BGP to fake a multiple AS routing system,
with different distances for each AS.
Joe
--
Joseph Mack PhD, Senior Systems Engineer, Lockheed Martin
contractor to the National Environmental Supercomputer Center,
mailto:mack.joseph@xxxxxxx ph# 919-541-0007, RTP, NC, USA
|
