[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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 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?


Linux-cluster mailing list
Linux-cluster redhat com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]