[Pacemaker] resource stickiness and preventing stonith on failback

Brian J. Murrell brian at interlinx.bc.ca
Mon Sep 19 23:58:31 EDT 2011


On 11-09-19 11:02 PM, Andrew Beekhof wrote:
> On Wed, Aug 24, 2011 at 6:56 AM, Brian J. Murrell <brian-SquOHqY54CVWr29BmMi2cA at public.gmane.org> wrote:
>>
>> 2. preventing the active node from being STONITHed when the resource
>>   is moved back to it's failed-and-restored node after a failover.
>>   IOW: BAR1 is available on foo1, which fails and the resource is moved
>>   to foo2.  foo1 returns and the resource is failed back to foo1, but
>>   in doing that foo2 is STONITHed.
>>
>> As for #2, the issue with STONITHing foo2 when failing back to foo1 is
>> that foo1 and foo2 are an active/active pair of servers.  STONITHing
>> foo2 just to restore foo1's services puts foo2's services out of service,
>>
>> I do want a node that is believed to be dead to be STONITHed before it's
>> resource(s) are failed over though.
> 
> Thats a great way to ensure your data gets trashed.

What's that?

> If the "node that is believed to be dead" isn't /actually/ dead,
> you'll have two nodes running the same resources and writing to the
> same files.

Where did I say I wanted a node that was believed to be dead not to be
STONITHed before another node takes over the resource?  I actually said
(I left it in the quoted portion above if you want to go back and read
it) "I do want a node that is believed to be dead to be STONITHed before
it's resource(s) are failed over though."

The node I don't want STONITHed is the failover node that is alive and
well and can be told to release the resource cleanly and can confirm its
release.  This is the node in the active/active pair (i.e. a pair that
each serve half of the resources) that is currently running all of the
resources due to it's partner having failed.  Of course I don't want
this node's resources to have to be interrupted just because the failed
node has come back.

And it all does seem to work that way, FWIW.  I'm not sure why my
earlier experiments didn't bear that out.

Cheers,
b.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20110919/ddf949df/attachment-0003.sig>


More information about the Pacemaker mailing list