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

David Turland david.turland at shazamteam.com
Thu May 16 05:41:02 EDT 2002


This seems to have been lost in the ether so.......

Subject: Re: [Spread-users] Implementing node-driven ip aliasing in
Date: Sat, 4 May 2002 18:06:45 +0100
From: David Turland <david.turland at shazamteam.com>
To: spread-users at lists.spread.org

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
}

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






More information about the Spread-users mailing list