vrs-development
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Vrs-development] Cluster Management Message (was CVS)


From: Bill Lance
Subject: Re: [Vrs-development] Cluster Management Message (was CVS)
Date: Thu, 21 Feb 2002 06:04:19 -0800 (PST)

--- Chris Smith <address@hidden> wrote:
> 
>> 
> Chemical systems are a good analogy!!!!
> 

Or more specifically, biochemical.  Probably, the most
important feature of these systems is hemeostasis. 
THey spend a great deal of activity findiing and
correcting errors.  This is not that common is SC. but
certain not unheard of.  In fact, the CRC method is
perhaps the granddaaaddy of them all.

If we are going to pursue this line of thought,
perhaps we should start thinkin of all the possible
feedback loops we can find.  And remember that a
Cluster shares another characteristic with biology,
it's massively parellel.  We got lots of cycles.


> 
> Ah, but how does a client that wants to invoke a
> particular net service find an LDS to satisfy the
> request?  There might be one, there maight be many.
> If the repository is truly distributed, then any
> LDS's
> in the cluster should be able to satisfy a request
> for
> data within the repository.
>

I had in the back of my mind that this would be a
function of the Directory service in the Repository. 
When an LSD recalls a file for a request fulfillment,
a pointer is set in the Directory that that particular
LDS has loaded that file.  Since the Directory is a
Cluster Image table, that info is propogated. The next
time the Directory is asked for the file by any LDS,
the Directory can inform the requestory that LDS X
already has the files loaded and recomend a
deligation.

This sort of leads into a array of tunning methods
that are possible, that I have barely thouched yet. 
 
> 
> > > As LDSs join the cluster, the cluser managment
> sort
> > > out the cluster, but the new LDS needs to be
> added
> > > to the UDDI thingy.
> >
> > There shouldn't be any relationship between what
> LDS's
> > are online with what Net services that the Cluster
> > offers.
> 

>As more 'yes I will be public' LDSs come online, then
>they too need to be added to the Directory Service.
>If the VRS is designed to be dynamic, then the
>Directory Service too needs to be dynamic to keep
>up with the VRS.

Yup.  Sounds good.  I think this question of outside
visibility and access is primarily a matter of
Administration.  In addition to willingness to server
as a public access point, persistance and bandwitdh
also should figure in.  I can think of many uses of a
VRS that would NOT want a publicly known entry point. 
But absolutly, one or more LDS's can be tagged as the
primary published IP, hopefull including backups.  At
this point, however, I don't see that we need to be
concerned with it other than recognizing it as an
administrative factor.


>I've got a feeling that you've been just talking
about
>LDSs accessing the other LDSs within the cluster.

Yes, I have been.


>Perhaps setup an IRC chat soon?


Indeed!  Todays kind of racked for me.  I am generally
readily availabe between, oh say, Greenwich time  1PM
to 11PM.



__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com



reply via email to

[Prev in Thread] Current Thread [Next in Thread]