[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



HI Keisuke,

Thanks for the input and ideas.
It would be nice to have the features incorporated into "standard" distros.

It seems that your solution will obviate the needs for kdump_pre script and kdump_post script.
My initial reaction is to use kdump_pre scripts and post scripts to broadcast out which node is kdumping and when they are finished kdump'ing.

More things to consider...

Thanks


On Thu, Apr 15, 2010 at 7:05 AM, Keisuke MORI <keisuke mori+ha gmail com> wrote:
Hi,

My LinuxHAList <mylinuxhalist gmail com> writes:
> 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)

I have once developed the exactly same function before,
although it was on Pacemaker/Heartbeat cluster.

Please find the tool and the discussion at the archive here:
http://www.gossamer-threads.com/lists/linuxha/dev/51968

The tool consists of two parts:
 1) a fencing agent which checks whether if the other node is
   kdumping or not, and if it is, return success to continue the fail-over.
 2) a customization for the 2nd kernel to allow to be checked remotely
   from the other node.

The former one might be Pacemaker/Heartbeat specific, but the
latter one should be usable regardless of the cluster stack.

I would be glad if it helps you, and also it would be great if
the customization of the 2nd kernel would be incorporated into
the standard RedHat distribution so that everybody can easily
use this feature.

Regards,

Keisuke MORI


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