Date: Wed, 10 Aug 2011 08:48:48 +0300 From: Mikolaj Golub <trociny@freebsd.org> To: Ferdinand Goldmann <ferdinand.goldmann@jku.at> Cc: freebsd-net@freebsd.org Subject: Re: Problem using CARP + HAST ... Message-ID: <86mxfhyfy7.fsf@in138.ua3> In-Reply-To: <A369574D-BB1B-4330-80F5-084B7D92CBD0@jku.at> (Ferdinand Goldmann's message of "Mon, 8 Aug 2011 16:54:10 %2B0200") References: <A369574D-BB1B-4330-80F5-084B7D92CBD0@jku.at>
index | next in thread | previous in thread | raw e-mail
On Mon, 8 Aug 2011 16:54:10 +0200 Ferdinand Goldmann wrote:
FG> Hi!
FG> I am trying to create a common resource pool for a certain application using
FG> CARP/HAST as described in [1]. However while testing my setup I ran into a
FG> problem which I don't know how to fix or work around:
FG> If I shut down only the carp interface on the master (ifconfig carp0 down),
FG> the slave will take note of this, make his carp interface the master and
FG> mount the HAST storage using a script called by devd. Everything fine so far. BUT:
FG> If, however, I completely shut down the masters network connection (using "shut" on
FG> the switchport), the carp interface on the slave will still switch to master.
FG> But the script for making the HAST storage primary will just hang forever:
FG> root 46841 0.0 0.6 3628 1524 ?? S 4:21PM 0:00.08 /bin/sh /opt/bin/carp-hast-switch master
FG> root 47043 0.0 2.6 42228 6580 ?? S 4:22PM 0:00.03 hastd: hast0 (secondary) (hastd)
FG> Seemingly, this is because the hastd daemons on master and slave are unable to
FG> communicate. So the script waits forever for the secondary device to go away... :
FG> # Wait for any "hastd secondary" processes to stop
FG> for disk in ${resources}; do
FG> while $( pgrep -lf "hastd: ${disk} \(secondary\)" > /dev/null 2>&1 ); do
FG> sleep 1
FG> done
What freebsd are you running on? I suppose it is release, because on STABLE
this issue should be fixed -- the secondary terminates after timeout.
FG> Im a bit puzzled. Is there a way for hastd to make himself the master in case of a timeout
FG> or such? Because in normal operation, whenever the carp interface fails, the underlying
FG> infrastructure will most likely be down as well.
On release you can just modify the script not to wait forever for hastd
secondary to stop -- it will be terminated when the role is switched to
primary.
But anyway my advise is to use STABLE :-).
--
Mikolaj Golub
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86mxfhyfy7.fsf>