On 2009-02-19T10:09:55, Glory Smith <xx2gl...@gmail.com> wrote:
> yes i understand this. i want something like , a node should be able to
> reserve a share disk to do any IO . while this node is holding the
> reservation other nodes should not be able to write any thing to that shared
> disk. if a node who has the reservation becomes errant , any other node
> from cluster should come forward and remove the key of this errant node and
> put it's own key to hold reservation. like this, we can prevent data
> intigrity issue in better way.
> i dont think i can achieve this through SBD . am i wrong??
The SBD mechanism provides a way to fence errant nodes. The cluster
manager itself ensures that it does not activate the resource several
times.
> so it means for sfex and scsi2reservation i need to set stonith-enable
> =false and for sbd i need to set stonith_enable= true. The reason why i
> want both is ,if we have both resource fencing and node fencing our soultion
> will be more reliable.
If you want both, of course you shouldn't set stonith-enabled=false, but
use it with for example regular fencing and sfex.
Most people seem to want either resource fencing xor node fencing; both
basically only makes "sense" if you distrust the cluster manager, and if
you do that, you can of course also assume that the cluster manager
ignores the resource fencing mechanism - as soon as you start
distrusting the CRM/Pacemaker or your node-level fencing devices, you
have reached a level of paranoia for which clustering does not provide a
cure ;-)
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
