[Pacemaker] SFEX resource agent

Takenaka Kazuhiro takenaka.kazuhiro at oss.ntt.co.jp
Fri Feb 27 13:12:03 UTC 2009


Hi, Priyanka

 > I understand your point but if we have SCSI3 protection other node will have
 > to perform few extra steps before accessing the disk. it will have to remove
 > to the present key, put it's new registration key , then put it's own
 > reservation then only it can go ahead and access the disk. this way SCSI3
 > provide extra security unlike sfex or LVM.

The advantages you wrote seem to be quite attractive from a
certain ponint of view. Any stupid operater hardly to break
scsi-locked devices by makeing double-mounts and so on.
This looks something fine while anything goes well.

But any cluster can't be so reliable that it never need any
operation by hand.

What have to be done if something aweful strikes the clusters
using SCSI3 protection, and it lefts some vicious malfunction
related to SCSI3 protection, and it compels the administrators
of the broken clusters to repair the malfunction by hand?

These poor administrators can't help but run some commands
they don't usually run to unlock protected devices in particular
order under such situations.

Then they have to make sure if the data on the unlocked
devices are safe or not after such severe accidents.
So they must try to run check commands from nodes that have
had no lock of the devices, but these commands might fail in
some cases because of SCSI3 protection.

The chosen node may not know any partition data of the
unlocked devices. If the node were rebooted after one
of others locked the devices, it should be so. In this
case they must use the sfdisk command, this command is
also usually unused. they'd better to reboot the node
instead of using such a unfamiliar command.

Can these messes be solved if somebody wise adds a fine
section about them to documents of recovering clusters?
I don't think so. If documents get longer and commands
to recover get increased, possibility of misoperations
gets more. It's a inevitable providence.

There is a way to avoid misoperations. Making scripts
for recovering is it. I can imagine what follows afterword.
Somebody stupid will use the scripts instead of the mount
command durring the cluster runs.

Priyanka Ranjan wrote:
ainst malicious applications from
>> other cluster nodes. sfex, LVM exclusive activation, and SCSI2/SCSI3
>> reservations likewise can be broken - they must be able to be broken, or
>> else the cluster could never orchestrate a fail-over.
> 
> 
> I understand your point but if we have SCSI3 protection other node will have
> to perform few extra steps before accessing the disk. it will have to remove
> to the present key, put it's new registration key , then put it's own
> reservation then only it can go ahead and access the disk. this way SCSI3
> provide extra security unlike sfex or LVM.
> 
> can we configure present scsi2reservation R.A  to use sg_persist command .
> 
> Thanks & Regards,
> Priyanka.
> 
>>
>> Regards,
>>    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 at oss.clusterlabs.org
>> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Pacemaker mailing list
> Pacemaker at oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
> 

-- 
Takenaka Kazuhiro <takenaka.kazuhiro at oss.ntt.co.jp>




More information about the Pacemaker mailing list