Hi, On Mon, May 23, 2011 at 04:26:22PM +0200, Ulrich Windl wrote: > >>> Lars Marowsky-Bree <l...@suse.de> schrieb am 23.05.2011 um 13:06 in > >>> Nachricht > <20110523110652.gb29...@suse.de>: > > On 2011-05-20T08:16:23, Ulrich Windl <ulrich.wi...@rz.uni-regensburg.de> > > wrote: > > > > > > Well, yes. I'm not quite sure why you'd want to use sfex though if you > > > > have sbd fencing anyway. > > > SBD is for node fencing only. If I need to ensure exclusive assignment of > > shared storage resources (well you never know what the cluster stuff tries > > to > > do) to avoid data corruption (e.g. through MD-RAID), I feel the need for > > cluster-wise mutex-locks. > > > > This is not quite correct. > > > > SBD is fencing "only", but fencing already ensures that no node will > > acquire resources unless possible competitors have been fenced. > > > > If you doubt that this - very fundamental and heavily tested - part of > > the cluster logic doesn't work, it is much more reasonable to assume > > that sfex generates a false positive or that a sfex dependency is > > ignored. > > > > Neither will protect you against admins fumbling and accidentally > > corrupting the data. > > > > Combining sfex and sbd does not create any real benefit, it just > > complicates your configuration, making it more likely to fail. > > Hi Lars, > > so you are saying that the CRM/LRM will never try to start a resource on more > than one node concurrently, and they will never try to start a resource on a > node of the cluster when it cannot be guaranteed that the resource is > definitely down on every other cluster node (all if stonith/fencing works)? > That would be good.
Yes. Otherwise, there'll be quite a few clusters with shared filesystems killed. Thanks, Dejan P.S. LRM is stupid, for the most part it would do whatever CRM orders it to do. > Unfortunately the documentation on all of that is not very clear, and my > belief is better to check twice rather than loose data... > > Regards, > ulrich > > > > > > > > Regards, > > Lars > > > > > > _______________________________________________ > Linux-HA mailing list > Linux-HA@lists.linux-ha.org > http://lists.linux-ha.org/mailman/listinfo/linux-ha > See also: http://linux-ha.org/ReportingProblems _______________________________________________ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
