Re: [Vrs-development] Service Manager free-style

[Bill Lance]

--- Eric Altendorf <address@hidden> wrote:
> 
> OK, I'm going to ask a dumb question here -- will
> these services be available 
> on their standard respective ports (in which case
> the services manager sounds 
> a lot like xinetd...?), or will it offer connections
> via a special services 
> manager port, with its own protocol, unwrapping each
> request and dispatching 
> it to the appropriate server?
> 

As we understand it at this point, the Service Manager
will use the standard ports for netservices and a
seperate port for Cluster Managerment Message traffic.
And, yes, an xinetd type function is seen as part of
that.

> And regarding the services/protocols supported -- do
> we intend on using 
> stand-alone independent server processes (e.g., a
> standard Apache process)?
> 

I certainly hope that we can reuse exisiting GLP'ed
system.  If not, we would have a terrably difficult
job ahead.  One of the main drivers here is to secure
the LDS host computer from activities within the LDS,
while still using these existing components.  So far,
we have talked about two possible approaches to this. 
One is using chroot to isolate the LDS elements from
the rest of the host system.  The second is the
possible use of UserLinux as a security shell.


> > There are several basic questions here I think. 
> The
> > first is how to organize the software components
> in an
> > LDS to support this function.  The second is to
> insure
> > that all Cluster LDS nodes have the same set of
> > services.
> 
> Well, this may be a minor point, but I'd argue that
> we not require each LDS 
> node to support the entire set of services.  If
> someone has a computer they 
> want to donate to an LDS cluster, but they for one
> reason or another can't or 
> don't want to run an EJB server, they shouldn't be
> prevented from joining and 
> offering the other services.  Or maybe a node has
> lots of disk space but no 
> spare CPU cycles, and it could be donated for
> storage but no services.  
> Besides, nodes may experience temporary failures of
> certain services (e.g., 
> Apache gets misconfigured and won't run) and that
> shouldn't interfere with 
> the node's operation in providing other services.
> 


This thouches on several areas.  Frist, the three
levels of trust system will restrict level III nodes
to just the memory function you suggested.  The second
is how LDS assignments can be further tuned.  When an
online node recieves a service request from the public
network, it will pass it on for action to another
cluster node.  The decision as to which node to
deligate the job to is determined by a set of tuning
factors held in the Cluster Image about each online
node, including bandwith and CPU load.  It also could
include information about actual services supported by
individual nodes.  My instinct is to keep these as
consistant as possible, however.  I guess we will have
to see how this works out.


> Probably connections to an LDS node which does not
> support (at that moment) 
> the requested protocol should simply be redirected
> to a node that does. 
> 
> 
> This suggests to me a layering separatation.  The
> VRS (as I see it) 
> accomplishes two interesting things -- providing
> distributed and secure file 
> storage, and providing services (through multiple
> LDSnode-to-Internet 
> connections) which operate based upon the contents
> of the files.
> 
> Incidentally, the former sounds temptingly like the
> Andrew File System...?  
> Anyone else familiar with that?  I wonder if there's
> any work there we could 
> use...
>

Not aware of this.  Do you have any pointers to it?
 
> Anyway...So...this is kind of how I see it.  Each
> and every LDS node on a 
> cluster runs a service manager, which (somehow)
> routes requests to an 
> appropriate server module/process (either on a local
> machine, or redirected 
> to another LDS node should it not be available on
> the local machine).  That 
> server module/process accesses files off the
> distributed file system, 
> processes them as necessary, and then 
> returns the response to the client.  (A future
> enhancement could include, for 
> services that require trivial processing like
> uncompressed ftp downloads, 
> client software that would allow multiple
> simultaneous connections to 
> multiple LDS nodes to speed file transfers...but
> that's kind of a separate 
> thing.)
>

Ya, there are several distributed files systems in
development that approach this.  Seems they are
focused on distributing very large media content file.
 
> I guess the other thing the service manager should
> do is manage the list of 
> other LDS nodes currently available.  That includes
> talking to other 
> currently-available nodes to authenticate new nodes
> when those nodes come 
> alive and attempt to join the cluster...no?
>

This all is the task of the Cluster Manger element and
the Cluster Image.  This is the 'business logic'
aspect that I mentioned earlier.





__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/