[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