Mailing List Archive

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@lists.backhand.org
> http://lists.backhand.org/mailman/listinfo/wackamole-users
>

--
Ryan W. Caudy
Center for Networking and Distributed Systems
Department of Computer Science
Johns Hopkins University