2009/2/20 Glory Smith <xx2gl...@gmail.com>: > Thanks Lar for reply, >> >> The SBD mechanism provides a way to fence errant nodes. The cluster >> manager itself ensures that it does not activate the resource several >> times. > > my concern is suppose SBD resource is running on say node1 even then node2 > who is member of cluster will be able to access SBD device. or i think a > node who is not even member of cluster will be able to access the SBD > device. SBD does not provide exclusive access. am i wrong. > Both SBD and SFEX requires a properly configured pacemaker cluster. They don't need hardware support from lower level. It can be considered both pros and cons.
> > other most important thing for me is, does scsi2reservation calls > sg_persist in background?? or can we configure it to do so some how. please > do confirm. scsi2reservation doesn't call sg_persist. It's a scsi-2 reservation based solution, as the name implies. You can search the archive of this maillist for scsi-3 reservation based RA. The RA itself is a bit tricky, as resource can be restarted. So we do need some workaround to prevent the fenced node from re-joining the cluster without rebooting. >> >> >> >> Mit freundlichen Grüßen, >> Lars >> >> -- >> Teamlead Kernel, SuSE Labs, Research and Development >> SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) >> "Experience is the name everyone gives to their mistakes." -- Oscar Wilde >> >> >> _______________________________________________ >> Pacemaker mailing list >> Pacemaker@oss.clusterlabs.org >> http://oss.clusterlabs.org/mailman/listinfo/pacemaker > > > _______________________________________________ > Pacemaker mailing list > Pacemaker@oss.clusterlabs.org > http://oss.clusterlabs.org/mailman/listinfo/pacemaker > > _______________________________________________ Pacemaker mailing list Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker
