[Vrs-development] Re: Overview

[Bill Lance]

--- Chris Smith <address@hidden> wrote:
> 
> "The only way in and out of the LDS is through a
> network connection and 
> read/write access to a single, highly encrypted disk
> file used for the 
> Repository storage and configuration files."
> 
> Probably a bit specific to say that all data and
> configs are stored in a 
> single disc file st this stage......... 'cos we
> don't quite know do we? :o)
> 
> 

Yup.  Your right there.  Some initialization
configuration files are probably going to be needed.

I was hoping, however, that we could keep all running
cluster configuration data off any disk at any time. 
It should stay mirrored in running trusted nodes.

> I'm glad you make the point of mentioning that
> before a cluster may be 
> promoted as a cluster, it requires at least two
> machines.  Orchistrating this 
> is going to be tricky - I suppose the two owners of
> the two LDS that are 
> going to form the VRS 'core' need to agree
> specifics.   Or could we just 
> leave it that a single LDS is made available on the
> internet, and another LDS 
> decides to join it, and gets a share of the data.


This points to several issues.

One is the 'bootstrap' process.  Like a physical
computer, the VRS must come to life from the dead.  

All LDS's have three startup modes when they execute
on their host computers;

1) Cluster Bootstrap
2) Subscribe to Cluster
3) Defalt Login

The Bootstrap mode is closely associated with the
Cluster Administrator role. In fact, when you run the
'bootstarp' mode, you are by definition the
Administrator for the Cluster you are about to create.
When it first starts, new VRS has no datasets
registered and only itself on the subscription list. 
It then listens to the net for a subscription request.

Next, the second LDS starts in the 'Subscribe to
Cluster' mode.  It asks for the IP of the first LDS,
calls in and signs up (there is an interactive session
with the new user here to collect id data as needed.)

Now we have two machines in the young CLuster.  Now
Dataset can be registered, stored and services can
begin.  Presumably, the Cluster grows from here.


The second issue is running a total VRS on a single
machine, just one LDS.  Any one LDS contains all the
functionality to do this.  The question may be 'Why do
this?'

There is one time where it becomes a serious question.
 That's the reverse of the bootstrap process at the
end of a Cluster's life cycle.  What happens if a
Cluster shrink to only two LDS's, and one of them
drops.  The Cluster could die right then and there, or
it could try to hold everything alive on the one
surviving machine. Technically, either should be
possible.

Putting everything on one machine violates some of the
data distribution privacy and security rules.  But it
does allow for a final emergancy backup mechanism.  It
becomes an administrative configuration question then.


 

> 
> 
> The rest is okay I think.  I'm sure it'll get
> refined as soon as we start 
> knocking stuff together.
> 
> 
> BTW As of this morning I'm in a position to get back
> to kicking Goldwater out 
> of the door... Hurrah... Watch this space - I'm sure
> you're waiting to see 
> hwo the hell you work with it?? :o)
> 


indeed I am.  

I'm still thinking about that perl prototyping and
conversion to C as a overall project framwork too.


__________________________________________________
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com