[Linux-cluster] forcefully taking over a service from another node, kdump

[My LinuxHAList]

In this case, node1 which is kdumping executes a kdump_pre script that tells
node2 that it is kdumping.
Upon this notification, node2 then tries to take over the service.

I hate my current work-around because:
1) It assumes how much time it takes to do kdump
2) If the machine dies (say power completely unplugged), I would still have
post_fail_delay to wait for (unnecessary wait).

My guess is custom-fencing will allow me to react differently:
1) While the other node is kdumping, return success (and thus, the rgmanager
will go ahead and take over the rsources)
2) If the node is not kdumping, do the usual fencing and return the code for
the usual fencing

It sounds do-able; it does add another layer of complexity to what I already
have (with pre_dump, post_dump scripts, services listening on both ends to
know the other node is kdumping)

Thanks again for input.

On Wed, Apr 14, 2010 at 3:32 PM, Gordan Bobic <gordan at bobich.net> wrote:

> My LinuxHAList wrote:
>
>  What can I do at node2 to forcefully take over the service from node1
>> after node2 is contacted by node1 at kdump_pre stage ?
>>
>
>
> Sounds like you need to write your own fencing script that will return
> successfully fenced status when it knows node2 is down and dumping, and only
> reboot it some time later. How can you remotely check that the failed node
> is actually kdumping?
>
> Gordan
>
> --
> Linux-cluster mailing list
> Linux-cluster at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-cluster
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-cluster/attachments/20100414/bdea03a5/attachment.htm>