[Spread-users] Implementing node-driven ip aliasing in

[David Turland]

On Friday 03 May 2002 17:00, spread-users-admin at lists.spread.org wrote:
> Subject: Re: [Spread-users] Implementing node-driven ip aliasing in
> Spread/Wackamole
>
> Hi David,
>
> I have to agree with Theo. If you want wackamole to allocate the
> single ip to the active master, then have only masters be part of
> the game and arrange them according to their "priority" in your
>   config. And that is it. Wackamole will do exactly what you want
> if you set it exactly as Theo suggested.
>
> Beyond that, I would suggest playing with Spread a bit to understand
> how it works.
>
>         Cheers,
>
>         :) Yair.
>
> David Turland wrote:

Hi All,
This has now become a 'How I did it' rather than a 'Will this work?' but hey...

Maybe I should reiterate my original problem.

for (int i=1;i<10;i++){ //;-)

I have a cluster of 32 slave nodes and initially 1 but now 2 (but potentially >2) master nodes . My application(essentially a distributed voting algorithm) 
has successfuly been using Spread for the last 2 months to manage the reliability and the messaging for the cluster. 

The master nodes use what I think is quite a neat way of creating one 'active' master node and 'n' reserve 'master' nodes; All master nodes 
try to connect as 'master';the (n-1) nodes that fail connect as a reserve. All master nodes join the 'master' group.
 If a master has connected as a reserve then, on a node exiting from the master group, the master node again tries 
to connect as 'master'. No voting, no Bully; spread does it all... excellent. And another indispensible benefit of 
using this method is that the slave nodes always deal with the 'master', fantastic..

I always want the current active master to handle the 'single vip address' as seen by the client.

If I use Wackamole as it stands then the problems are:
1- If just my spread-joined-process dies on a master node then the wackamole process obv. 
     continues unaware and no vip release/aquire takes place. 
2- Wackamole does not know which master node to allocate the ip address to.

> then have only masters be part of
> the game and arrange them according to their "priority" in your
>   config. And that is

Indeed, only masters are 'part of the game', but the 'active' master isn't decided by priority 
(I presume by priority you mean 'line number' in the config file) it's decided by whoever gets the 'master' name first, a N.D. thing.




Now to my solution:
-------------------------

In my app when a master node has discovered if it is the active master:

#ifdef WACKAMOLE
  if (amActiveMaster){
        gRet = SP_join(mMailbox, "wackamole");
  }else{
        // unlikely to be called!!!!!!!!!!
        gRet = SP_leave(mMailbox, "wackamole");
  }
#endif


In the apps 'message receive' method I ignore "wackamole" messages
(remember the active master has joined the 'wackamole' group) 
.
.
          if( Is_regular_mess( gServiceType ) ){
#ifdef WACKAMOLE
            // should use SP_equal_group_ids
            if( strcmp(gTargetGroups[0],"wackamole")==0){
            } else
#endif
.
.
          else if( Is_membership_mess( gServiceType )){
#ifdef WACKAMOLE
            // we ignore membership messages from the 'wackamole' group
            // actually only regular memberships are received but this is neater
            if( strcmp( gSender, "wackamole" ) == 0 ){
            } else
#endif
.
.

In wackamole.c, approx line 295, I remove the wackamole join of the 'wackamole'
group; my app is doing the joining.

#ifndef EXTERNAL_JOIN
  ret = SP_join( Mbox, "wackamole" );
  if( ret < 0 )
    {
      SP_error( ret );
      Spread_reconnect(ret);
    }
#endif


sorted..................
As a master becomes active it joins the wackamole group and wackamole aquires the vip for it.
As a master dies, it impicitly leaves the group, wackamole releases the vip for that node.
The masters ignore wackamole membership and regular messages.


>I think 
>it would be silly to incorporate the wackamole "technology" into your 
>app.
hmm, one 'ifdef' in wackamole.c, 11 lines in my app and I have  a vip controlled just they way I want it; 
maybe not so silly after all :-o


Thanks for your  time, a problem shared......
cheers all,

David Turland


To experience my initial problem
-----------------------------------------
1/
start spread
start up wackamole on two nodes; indeed - one nodes aquires the vip.
start up a simple spread app, spuser(?), on the same two nodes'; 
kill the spuser process which is on the node which has the vip (consult /var/log/messages for which one)
wait...........wackamole does nothing.

2/
modify spuser so that one process knows it is the master and the other process
knows it is not (command line option would be fine). How would this configuration be passed
to wackamole so that it allocates the vip to the node with the 'master' spuser process?
I know this isn't how I decide on the active master but it is representative insofar as it isn't related
to the the priority or array index of  the spread-process
}