vrs-development
[Top][All Lists]
Advanced

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

Fwd: Re: [Vrs-development] Cluster Management


From: Chris Smith
Subject: Fwd: Re: [Vrs-development] Cluster Management
Date: Thu, 11 Jul 2002 16:32:32 +0100

The CM is a very 'fruity' issue.

Each LDS is a Goldwater 'domain'.
Goldwater handles knowledge of what domains are available and connected to
whome.
The number of domains a single goldwater domain can know about is finite, and
set by  the person who configures the LDS for that machine.

Membership to a particular VRS is controlled by a central administrator (a
person or group of people, not a machine/server/program).  It is currently
not entirely clear how this 'membership' information is propoagated to all
LDS's, if at all.


Morphius and I then came up with a nice scheme using pseudo-mobile-agents to
walk the VRS and discover LDS availability, which also bypasses the problem
of the finite 'LDS' slot size of each LDS.  The VRS can basically grow to be
as big as the largest configured LDS (in terms of LDS slots).
It might even turn out that it is bigger than this, depending on the way the
cluster hangs together.

Refer to thread:

http://mail.freesoftware.fsf.org/pipermail/vrs-development/2002-April/000
257.html


LDS won't be forwarding requests to other LDS's for processing.
Each LDS should be capable of serving requests for any resource held by the
VRS.  _Where_ the resource is actually found is hidden by the Resource
Manager.

                T h e  V R S
  +------+--------+-------+-------+-------+

  | LDS  |   LDS  |  LDS  |  LDS  |  LDS  |

  +------+--------+-------+-------+-------+

  | RM   |   RM   |  RM   |  RM   |  RM   |

  +------+--------+-------+-------+-------+

  |D a t a   p o o l   a c r o s s   V R S|

  +---------------------------------------+


(Hmm, that's a white lie, as there may be a case where some resources
deployed at an LDS are 'private' and not sharable with other LDS's and as
such are only servable by that LDS.  How we get that LDS to service the
request has not been designed, but it is likely to be done using part of the
Goldwater messageing API, as it's a 'cluster' issue and not an LDS issue.
These types of service are rare though - things which rely on special
hardware for instance.  An atomic clock service springs to mind).

The whole point of having LDS data distributed across the VRS is for
resilience - it's not a route and forward architecture,

Chris

On Thursday 11 July 2002 04:31, you wrote:
> so i was looking at the plans for the CM. got some questions. we are
> looking for a way to allow for LDS's to join/leave/etc the vrs. now i
> dont know if this actually falls under the role of the cm, but i think
> there should be a more intelligent way to handle communications between
> LDS's. i had read in the archives that the idea was to have each LDS
> keep a list of all other LDS's that is in the vrs. that seems like it
> doesn't scale well. why does a certain LDS need to be aware of all other
> LDS's? if say it received a request for a service it doesnt have, why
> doesnt it just forward the request to another LDS. any given LDS can
> just maintain a list of LDS's that are close to it. this can be in the
> spirit of a dynamic routing protocol such as AODV. you can set up
> forward and backward paths when you try to look for a service. has
> anyone thought about doing this that way? if an LDS doesnt care about
> maintaining a list of all other LDS nodes and discovery is done
> dynamically, it will actually make things a lot easier. there are going
> to be a lot of issues regarding how you would actually maintain the list
> and what counts as an up-to-date list. for example if an LDS leaves the
> vrs, its going to take a discrete amount of time before that information
> is propagted to other LDS's. so what is considered as the current
> version of the LDS list?
>
>
> _______________________________________________
> Vrs-development mailing list
> address@hidden
> http://mail.freesoftware.fsf.org/mailman/listinfo/vrs-development

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

-------------------------------------------------------

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



reply via email to

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