
caudy at jhu
Jul 23, 2003, 7:06 AM
Post #2 of 2
(844 views)
Permalink
|
Hi Gerald, How long are you waiting for the other node to get a vip when you bring it NIC back up? I would give it as long as 30 seconds, because it requires the Spread membership to complete, and a balance timeout as well. You can watch the Spread daemon membership take place by looking at the tail on your spread log. If you are waiting that long, I think the source of your problem is in the last paragraph of my email, but I answered your questions first. At this stage, administrative control to grab/release IPs is not implemented in Wackamole, though it has been discussed and likely will happen whenever we decide to do a bit of an overhaul. Balance timeout is relevant to you: if the vips become allocated unevenly (due to the "minimum disruption" strategy, as you're seeing in your system), vips should be moved to restore a "balanced" allocation based on the notion that any given machine should have at most one more vip than any other. The timeout is the length of time between rounds of balancing, and the AquisitionsPerRound is the number of vips that can be moved during a given round of balancing. Depending on how stable your network is, you might wish to change these parameters from the default. Maturity timeout is what you might call a setup period. It specifies a time interval during which a newly started Wackamole daemon will not actually aquire or release IP addresses, unless it hears from another daemon that the cluster is already mature. So, if you start 5 daemons, the first daemon started will "turn mature" after his maturity timeout is up, and notify all other daemons to start moving vips for real. This is just there to avoid disrupting a network too much when you bring a cluster up. The time of 5 seconds specified in the sample config is really way too short, it is an artifact of our testing. Also, from looking at your spread.conf, I noticed you have a line: Spread_Segment 127.0.0.255:4803 { localhost 127.0.0.1 } You shouldn't include a localhost segment if you have more than 1 Spread daemon or more than 1 Spread segment. Its a common misconfiguration that stems from the sample.spread.conf (which is designed to let someone run a single Spread daemon without doing any work at all). This seems to me to be the likely reason that IP addresses aren't being balanced in your cluster. Cheers, Ryan Gerald Leier wrote: > hi again, > > i want to build a vpn-"fullcluster" where i got 2 nodes and 2 vips > which get shared between them. if i set one nodes networkinterface > down. the other node sets the 2nd vip up. > now... when i put the first nodes nic up again it doesnt get another > vip. the second node keeps both vips. well thats nice behavior. > for example if one node is flapping he shouldnt get any new connections. > > is there a way to tell wackamole that it should move one vip to a node ? > (yeah i know, i could stop and start wackamole on that node and the vips > get rescheduled) > > also i would like to know what mature and balance intervals are for. > > > thanx in advance > gerald > > > p.s.: i included my configs below > > > > #[wackamole.conf] > Spread = 4803 > SpreadRetryInterval = 5s > Group = my-vpn > Control = /var/run/my-vpn.it > VirtualInterfaces { > { eth0:192.168.1.50/24 } > { eth0:192.168.1.51/24 } > } > Arp-Cache = 90s > Notify { > eth0:192.168.1.100/24 > } > balance { > AcquisitionsPerRound = all > interval = 4s > } > mature = 5s > #[wackamole.conf] > > > #[spread.conf] > Spread_Segment 127.0.0.255:4803 { > > localhost 127.0.0.1 > } > > Spread_Segment 192.168.1.255:4803 { > vpn-uno 192.168.1.99 > vpn-due 192.168.1.98 > } > DebugFlags = { PRINT EXIT } > EventLogFile = /var/log/spread.log > EventTimeStamp = "[%a %d %b %Y %H:%M:%S]" > RequiredAuthMethods = "NULL" > AllowedAuthMethods = "NULL" > #[spread.conf] > > > _______________________________________________ > wackamole-users mailing list > wackamole-users [at] lists > http://lists.backhand.org/mailman/listinfo/wackamole-users > -- Ryan W. Caudy Center for Networking and Distributed Systems Department of Computer Science Johns Hopkins University
|