global vision of the system

[carlos manzanedo <cvsrep@wanadoo.es>]

	CARLOS AND WEWE

it's difficult to me to have a global vision of the system at the actual
phase of development.correct me if i'm wrong please.
we have got two behaviours ,we are searching the things that join those
parts of the system and at now we have got that:

 layer 1:
	heartbeat: i don't know a lot about it just begin to read about
	it this week, but as long as i have seen it is perfect to this
	layer.
	It will send keepalive messages (HA and HP) and it will manage
	the transmission of data to do whatever you want (dfs, HA HP..)
	i think this is correct because of its capacities in :
	membership, authentication
	very customable and simple.

	must be several servers that have to manage the variable's
	packets sent in a broadcast net (as Orcero said), for example a
	server for HP other one for HA, and maybe one to a new
	distributed fs that someone will develop ( it will manage info
	about files not the files themselves).
This layer must be capable of change latencies , variable's type ,very
well designed to be  24x7, even (maybe) QoS.it should also be associated
with a unique
net interface,in that way we can have 2 clusters (in the same nodes,each
node with two net interfaces) one ha, other hp without affecting the
latencies of the beats.
Works that the layer will do:
	include nodes to the system (authentication )
	be aware when a node is shut down.
	membership

This layer is common to HA and HP.

¿what's the best way to do this user lever or kernel level , i think it
will be good leave it at user lever (we could have several servers in
each node, maybe configured by text files XML?)(in mosix that logical
layer hang up the kernel when you do an nmap to one node of the cluster)
?

layer 2:
	API that give to the upper layer the structures and hooks and
	functions necessaries to make a customable cluster.
	This will be general functions as way the processes migrate (HA
	surely won't need that, that's why it will be also customable),
	migratable sockets, maybe virtual shared memory , and every
	function a cluster may need, this layer will be in kernel level,
	the functions must be selected in compilation time (virtual
	shared memory and all these things). In that way we can make a
	consistent layer over which everyone can develop an application
	over it in a way that it can change the algorithms that decide
	the policy of migration , policy of location or whatever other
	policy.

Layer 3:
Distributed application layer.


section of ascii art.

     |----------------------------|
     |         APLICATION                            |
     | Algorithms to manage                     |
     | migrations or whatever...                 |
     |                                                        |
     |---------------------------------------------|
     |   API that provides
general                                                 |
     |   resource
managment                                                       |
     |                                                                                          |
     |---------------------------------------------|-|- - - - - - - - -
- -
     |     HEARTBEAT                               | |a way to
custom                                             |
     |                                             | | Heartbeat
behavior                                                |
     |_____________________________________________|_|_ _ _ _ _ _ _ _ _
_ _|

here i've got a confusion about the reletionship between the resource
management layer and the heartbeat layer.there are to ways they can
interact ,first is
the proposal i've told, other one is :

the distributed aplication would recive all the information of the
hertbeat
packages and take care with it,it aplicate the algorithms that these
especific
aplication need to solve it's problem and then use the resource
managment api.
in that way ,an especific aplication may not need the heartbeat
layer,only must
migrate the proccess that the administrator said in a gui enviroment ...

other ascii section

                      |--------------|
                      | APLICATION         |
                      |______________|
                      /                           \
                    /                               \
                  /                                   \
      |--------------|                  |--------------------|
      | HEARTBEAT          |                 | RESOURCE MANAGMENT  |
      |______________|                  |____________________|



I've already think about the name of the hp proyect...  may it be ANT M?
(have you seen the film ANT Z ?) as stallman said,the better part of
developing gnu is the program names ,i also thik that mosix is the
better aproach to HP cluster , but it should be better designed or
coded so why not to call it ANT M (Ant m is Not  True Mosix) ,it also
have other meanings , (the work that a group of ants can manage ...)

sugestions are wellcome.



Linux-cluster: generic cluster infrastructure for Linux
Archive:       http://mail.nl.linux.org/linux-cluster/