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@xxxxxxxxxx> wrote:
My LinuxHAList wrote: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?
What can I do at node2 to forcefully take over the service from node1 after node2 is contacted by node1 at kdump_pre stage ?
Gordan
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
-- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
