Hi, On Tue, Feb 26, 2008 at 08:04:58PM +0900, Keisuke MORI wrote: > Hi, > > Dejan Muhamedagic <[EMAIL PROTECTED]> writes: > > > Hi, > > > > On Tue, Feb 26, 2008 at 11:52:16AM +0900, Keisuke MORI wrote: > >> Hi, > >> > >> Johan Hoeke <[EMAIL PROTECTED]> writes: > >> > Dejan Muhamedagic wrote: > >> >> Hi, > >> >> > >> >> On Fri, Feb 22, 2008 at 05:59:23PM +0100, Johan Hoeke wrote: > >> >>> LS, > >> >>> > >> >>> Anybody here using some kind of brocade fencing with heartbeat like > >> >>> RedHat offers in its cluster software? I found this reference: > >> >>> http://linux.die.net/man/8/fence_brocade > >> >>> > >> >>> It turns out to be the attached perl script. Got it from > >> >>> http://mirror.centos.org/centos/4/csgfs/i386/RPMS/fence-1.32.50-2.el4.centos.1.i686.rpm > >> >>> > >> >>> Would it be possible to use this as an external stonith script? > >> >> > >> >> No, because stonith is about fencing nodes and this would be > >> >> fencing resources. > >> > > >> > Point taken! > >> > >> Fencing nodes by isolating I/O is very interesting idea though. > > > > It's a bit of a terminology problem, but it boils to the same > > thing. Fencing a resource means building a fence around it as > > your sf-ex does. Fencing a node is done by bringing it down so > > that it can't connect to any resource anymore. Stonith is used > > only on the node level. > > I believe that fence_brocade is the node level fencing, but am I wrong?
It could be, but it is more like resource level. Depends on the number of f/o switch ports used. > In my understanding, fence_brocade does fencing by bringing all > the Fibre connections of the node down to protect the data instead > of turning the power off. > > It's a different approach from the SF-EX to avoid the data corruption > but I think it's an interesting alternative. Well, actually it could work, but it would be an exception in terms of behaviour. I guess that one could use the poweroff command to mean detach a SAN port. Looking at the man page of fence_brocade it would be easy to implement a stonith external plugin to use it. > >> > > I think that right now the only way would be to implement an RA > >> >> which would fence resource. That's what Junko Ikeda and NTT > >> >> people did: > >> >> > >> >> http://lists.linux-ha.org/pipermail/linux-ha/2007-October/028388.html > >> > > >> > Good stuff, thanks you for pointing it out. And mr Ikeda and NTT for > >> > sharing! > >> > > >> >> > >> >> I don't know why their code was not included in Heartbeat. This > >> >> is an important issue, so it should get more attention. > >> > > >> > Agreed! > >> > >> What can I do to make it included in Heartbeat? (we call it as "SF-EX") > >> > >> I and my colleagues would be really happy if it is included > >> as a standard component in Heartbeat and available for everyone. > > > > I'll try to test it and take a look at the code. There was also > > some longish discussion on the list about it, which I didn't > > follow very closely. Were there any technical issues unresolved? > > I remember that the discussion point was that such functionality > should be implemented as a quorum plugin from the Heartbeat design. > > But as far as we studied, SF-EX can not be implemented as a > quorum plugin because the quorum plugin is not resource-aware > and therefore it can not guarantee to avoid a duplicate invocation > of resources. Maybe we have just short knowledge of quorum though... Not sure if I follow. You're worried about the plugin being executed in parallel? > So we believe that SF-EX can be included as it is > as one of the options for protecting the data of resources. Yes. Having it as quorum plugin would be great though. > > Does anybody use sf-ex? > > > > There's another big contribution of yours in the queue: procd. > > Since it depends on both the CRM and heartbeat and since the two > > are not anymore in the same development tree we'll have to fix > > the Makefile and most probably the include statements. > > Thank you for remembering it. > Actually we're just working on updating procd now to adapt to > Pacemaker and I'll post it very soon. Thanks a lot. Cheers, Dejan > > > Regards, > > Keisuke MORI > NTT DATA Intellilink Corporation > > _______________________________________________ > Linux-HA mailing list > [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha > See also: http://linux-ha.org/ReportingProblems _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
