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

[Chris Smith]

On Tuesday 19 February 2002 16:32, Bill Lance wrote:

> OK, I think I got your Domain meaning now  :)
>
> 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.

Okay.  VRS clusters cannot funtion like this if you use
GWDomains.  The Cluster Management Messages travel
between the LDSs that are clustered, thus holding the
cluster together.  Now, each LDS is actually a GWDomain,
and the message that pass between them are GWService
calls.  The fact that the service call has had to leave
one GWDomain, travel across the network and invokes a
GWService in another GWDomain is hidden from the
application layer (the LDS application).  The 'remote'
GWDomain could be running on the same server for all
the application cares.  As long as its GWService call
gets satisfied, it doesn't care what happened along the
way.  View GWServices requests as traditional function
calls.  When you call a 'function' it might actual be
a function that exists in a different application on a
different server on a different network.  Doesn't matter.
Thats what Goldwater does - helps you build distributed
scalable applications.

Make sense?

So, the Cluster Managment Messages are just GWService
calls between LDSs.  You would never see these kind of
messages coming in through the LDS client access port
(be it port 80 or whatever).  So I would say that "a
request to any of these ports results in the same
response" is false.  Each port supports different
traffic.

(That isn't to say that we can't piggy back GWService
request messages over HTTP and thus through the client
access node...... but lets play with those toys later!!)

> 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.

Right - so a VRS consists of a distributed, segmented
and mirrored data space, with equaly distributed redundant
access servers.  The availability of one or more access
servers means that you can access the data space.

>  When a process access data, it is confident
> that the data represents the current state of the
> cluster. 

Nice ideal.  But in practice one has to accept that there
will be some synchronisation lag.  How you manage updates
to a resource within the data set is tricky.  If you can
guarantee integrity, it'll be fine.

For example, an LDS might be recovering a resource, and
one of the segments of data it requires is on another
LDS.  However, this LDS has received an update for this
resource (a head of the LDS requesting it) and so the
segment of data it has DOES NOT belong to the data chain
the requesting LDS is trying to construct.  So the 'more
up to date' LDS must keep hold of the previous cluster
until all LDS's have been updated, then the cluster can
be expired.  Phew.  Nasty.  And there needs to be locking
too (one part of the LDS is serving a webService request
whilst another part of the LDS is updating that very data
chain required in satisfying the webservice request).
This is getting bonkers!  I like it!  :o)

> 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?

Hopefully the bit at the top answers this.

> 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.

Ah.  But the VRS is just a distributed data set with
several access servers.  Any one of these access severs
is able to satisfy requests for data within the dataset.
So clients need to know about the existence of these
LDSs.  I see it that a lookup for a single webservice
would resolve to one of these LDSs.
But this is inter linked to cluster management.  If
one LDS in the cluster discovers that one of the other
LDSs has gone away, it can update it's internal tables
and try and tell all the other LDSs in the cluster of
this fact (or not - I think GWDomains sort themselves
out so you don't need to propogate anything.....).
But it should also update the UDDI thingy too so
clients don't try and contact it.

As LDSs join the cluster, the cluser managment sort
out the cluster, but the new LDS needs to be added to
the UDDI thingy.

It's got to be Dynamic - and I don't know very much
(detail) about the operation of UDDI/LDAP servers etc.
I can do DNS..........

Food for thought.
-- 
Chris Smith
  Technical Architect - netFluid Technology Limited.
  "Internet Technologies, Distributed Systems and Tuxedo Consultancy"
  E: address@hidden  W: http://www.nfluid.co.uk