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

[Bill Lance]

--- Chris Smith <address@hidden> wrote:


  GWDomains then handle 
> the whole network thing for you.  All you do in the
> LDS implementation is 
> call Goldwater Services (from now on called
> GWServices....)  You don't need 
> to know 'where they are' - GWDomains take care of
> the routing for you - you 
> don't even need know there is a network involved
> anywhere!!
> 

OK, I think I got your Domain meaning now  :)

This all meashes right in with what I'm pounding on
right now.  I've started thinking more about the
Cluster Management job and I'm getting the following
abstraction sorted out.

A running Virtual Remote Server Cluster reacts and
responds as a single entity, no matter where it is
touched.  All of the active LDS nodes listen to the
assigned Cluster Management port for Cluster
Management Messages.  Level I and II nodes also listen
to port :80 for Webservice requests.  A request to any
of these ports results in the same response.

A single server acomplishes this by being under the
control of a single Operating System, resting on a
more or less fixed file system.  Traditional server
farm cluster designs extend this by delegating high
level task to similar free standing servers  In both
cases, the integrity of the Servers behavior relys on
a continuiously running process, somewhere.  In the
single computer case, it's the kernel itself.  In a
cluster farm, it's the core monitor or the queue
manager.  During its operation, these root processes
use in-memory variable and tables it's host computer,
and perhaps used disk files to add persistance.  But
the variables directly support a continuously running
process. In a server farm, communication is
exclusively between processes.  All data variables and
files directly support a host process.


 _______          ________
| proc  | <----->| proc   |
|-------|        |--------|
| data  |        | data   |
|_______|        |________|

I'm suggesting a little different approach with the
Cluster Image Object.  Instead of the depending on a
persistant process for it's integraty, a VRS cluster
depends on a persistant and common set of data.

  _______          ________
 | proc  | <----->| proc   | 
 |_______|        |________| 
     ^                ^
     |                |
 ____|________________|_____
|  __V___           __V___  |
| | data |<------->| data | |
| |______|         |______| |
|___________________________|

A process uses a data set local it itself, but that
local data set is a mirror immage shared by all I and
II LDS's.  When a process access data, it is confident
that the data represents the current state of the
cluster.  If a process changes the data locally, then
it is also confident that the changes will be
automatically propogated to the other mirror images on
other LDS's.

The effect of this is that a running Cluster depends
on no single continuously running process.  A Cluster
Management related module in any of the LDS's can
awaken to a request, act on the Cluster, then safely
go to sleep when finished.  It may be a some point,
none of the Cluster Management modules are active. But
the data that defines the Cluster remains alive and
coherent.

Does this make sense?  And, if so, how does it relate
to GWservices?


> 
> We really need to talk about dotGNU service
> discovery too.  Some banter has 
> passed through dotGNU developers list, but we need
> to work towards something, 
> as the VRS (and its access points) will only be
> locatable via the discovery 
> server.  Maybe assign this as a specific task.
> 

Do you mean externally, as in UDDI or internally as in
the Registery?

If the former, I was frankly assuming that we would
just end up using whatever ends up as functioning
standards.  To the outside, a VRS server looks like
any other Webserver, supporting standard protocols. 
Since we don't know what those are going to be yet, we
let that fall into place a part of the Service
Modules.



 

> I'm not trying to sell Phoenix - but we need some
> sort of 'server', and a web 
> server is no good, so we'll probably have to write
> one.  Phoenix is a generic 
> engine that handles all network comms and passes
> data to 'modules' via 'read' 
> and 'event' function hooks.  What the module does is
> up to your design 
> talents!
> 
> A web server is fine for client access to the LDS
> (VRS).
> 
>

This sounds excellant to me!


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