[Pacemaker] [patch] Seeking suggestions for cluster configuration of HA iSCSI target and initiators]

[Phil Frost]

On 07/16/2012 01:34 PM, Phil Frost wrote:
> I've been doing some study of the iscsi RA since my first post, and it 
> seems to me now that the "failure" in the monitor action isn't 
> actually in the monitor action at all. Rather, it appears that for 
> *all* actions, the RA does a "discovery" step, and that's what is 
> failing. I'm not really sure what this is, or why I need it. Is it 
> simply to find an unspecified portal for a given IQN? Is it therefore 
> useless in my case, since I've explicitly specified the portal in the 
> resource parameters?
>
> If I were to disable the "discovery" step, what are people's thoughts 
> on the case where the target is operational, but the initiator for 
> some reason (network failure) can't reach it? In this case, assume 
> Pacemaker knows the target is up; is there a way to encourage it to 
> decide to attempt migrating the initiator to another node?

Well, after reading through the iscsi RA a dozen times, I could not 
formulate any reasonable idea of why the discovery step might be 
necessary. The portal parameter is required, so it couldn't be to locate 
the portal. And, there is logic in the discovery function to handle the 
case when a target returns multiple portals for the same target -- by 
finding the one that was specified in the portal parameter. So it can't 
really be discovering anything. It does raise an error in this case if 
the portal parameter isn't specified, but then the portal parameter 
isn't optional, so that case could never occur. It smelled like rotten 
code to me.

So, given all that, and given how it introduces a nasty race condition 
in the case that the target isn't running (or is just in the process of 
migrating to another node), I decided it was better to just get rid of 
it. Patch attached. I suppose I've introduced a different failure in 
that an initiator that can't contact a running target won't be migrated, 
but I'd rather have one of my VMs trying to run, unsuccessfully, and 
able to automatically recover when the fault is cleared, than have an 
entire VM host shot in the head on the basis of a race condition in 
non-failure situations.

One minor nastiness was observed with my patch: if the portal isn't 
specified exactly as udev will format it, then the RA will wait forever 
for the device node to appear, expecting the wrong device filename. 
Maybe canonicalizing the portal was one useful function of the discovery 
function, but in my opinion, not worth the other problems.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: iscsi.patch
Type: text/x-patch
Size: 5584 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20120716/2d59ef6d/attachment-0004.bin>